WO2021139391A1 - Methods and devices for mitigating invoice financing fraud - Google Patents

Methods and devices for mitigating invoice financing fraud Download PDF

Info

Publication number
WO2021139391A1
WO2021139391A1 PCT/CN2020/128040 CN2020128040W WO2021139391A1 WO 2021139391 A1 WO2021139391 A1 WO 2021139391A1 CN 2020128040 W CN2020128040 W CN 2020128040W WO 2021139391 A1 WO2021139391 A1 WO 2021139391A1
Authority
WO
WIPO (PCT)
Prior art keywords
invoice
user
proof
token
commitment
Prior art date
Application number
PCT/CN2020/128040
Other languages
English (en)
French (fr)
Inventor
Shengjiao CAO
Yuan Yuan
Hui Fang
Weitao YANG
Original Assignee
Alipay Labs (singapore) Pte. Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alipay Labs (singapore) Pte. Ltd. filed Critical Alipay Labs (singapore) Pte. Ltd.
Priority to CN202080091457.1A priority Critical patent/CN114945931A/zh
Publication of WO2021139391A1 publication Critical patent/WO2021139391A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/108—Remote banking, e.g. home banking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/14—Payment architectures specially adapted for billing systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance

Definitions

  • the specification relates generally to computer technologies, and more particularly, to methods and devices for mitigating invoice financing fraud.
  • Invoice financing is a way for businesses to borrow money against accounts receivable, including, e.g., the amounts due from customers. Invoice financing helps businesses improve cash flow, pay employees and suppliers, and reinvest in operations and growth earlier than they could if they had to wait until their customers paid their balances in full.
  • One of the risks associated with invoice financing is fraud. For example, some businesses may commit fraud by unilaterally producing fake invoices and attempt to borrow money using such invoices. Some businesses may commit fraud by borrowing against the same invoice multiple times from multiple fund providers or financiers. Fraudulent activities as such are difficult to detect and mitigate.
  • a computer-implemented method for mitigating invoice financing fraud includes: receiving a first transaction from a first user, the first transaction comprising a first commitment of an invoice and a first proof for proving the first user is an issuer of the invoice, the first commitment 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 comprising the first token corresponding to the first user, a second commitment of the invoice, and a second proof for proving the second user is a receiver of the invoice, the second commitment 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 comprising the second token corresponding to the second user and a third proof generated by the third user; and determining that the second token is valid and verifying the third proof, to determine no invoice financing fraud.
  • a device for mitigating invoice financing fraud includes: one or more processors; and 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: receive a first transaction from a first user, the first transaction comprising a first commitment of an invoice and a first proof for proving the first user is an issuer of the invoice, the first commitment 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 comprising the first token corresponding to the first user, a second commitment of the invoice, and a second proof for proving the second user is a receiver of the invoice, the second commitment 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 comprising the second token corresponding to the second user and a third proof generated by the third user; and determine that the second token is valid and verify the
  • a non-transitory computer-readable medium have stored therein instructions that, when executed by a processor of a device, cause the device to perform a method for mitigating invoice financing fraud.
  • the method includes: receiving a first transaction from a first user, the first transaction comprising a first commitment of an invoice and a first proof for proving the first user is an issuer of the invoice, the first commitment 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 comprising the first token corresponding to the first user, a second commitment of the invoice, and a second proof for proving the second user is a receiver of the invoice, the second commitment 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 comprising the second token corresponding to the second user and a third proof generated by the third user; and determining that the second token is valid and verify verify
  • 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 chart of a method for mitigating invoice financing fraud, according an embodiment.
  • FIG. 4 is a flow chart of a method for mitigating invoice financing fraud, according an embodiment.
  • FIG. 5 is a block diagram of an apparatus for mitigating invoice financing fraud, according to an embodiment.
  • Embodiments of the specification provide methods and devices for mitigating invoice financing fraud.
  • the methods and devices may utilize blockchain systems to validate invoices submitted by users. Fake invoices can be detected and fraudulent attempts to borrow money using such invoices can be prevented.
  • the methods and devices may also implement a protocol that can determine whether an invoice has already been used for invoice financing. If it is determined that the invoice has already been used for invoice financing, the methods and devices can prevent additional attempts to finance using the same invoice.
  • the methods and devices may further implement the protocol to protect user privacy. In this manner, the methods and devices can validate the invoices using the blockchain system without revealing the details of the invoices to the public.
  • the methods and devices require users to submit proof in order to validate invoices submitted by the users. This allows the methods and devices to detect fake invoices and prevent fraudulent attempts to borrow money using fake invoices.
  • the methods and devices support validation of invoices using a blockchain system. This allows the methods and devices to store invoices in a data structure that can prevent tampering and manipulation by malicious parties.
  • the methods and devices further support a protocol that can calculate commitment values for the invoices to be validated using the blockchain system.
  • a commitment value calculated for an invoice may be associated with a token and a random value. The token may be used to nullify the commitment after it is revealed by a user. This allows the methods and devices to prevent double financing using the same invoice.
  • the random value may be used to introduce additional randomness to further protect user privacy. This allows the methods and devices to utilize the blockchain system to validate invoices without revealing any private information to the public.
  • Blockchain systems also known as distributed ledger systems (DLSs) or consensus systems, may enable participating parties to store data securely and immutably.
  • Blockchain systems may include any DLSs, without referencing any particular use case, and may be used for public, private, and consortium blockchain networks.
  • a public blockchain network is open for all entities to use the system and participate in the consensus process.
  • a private blockchain network is provided for a particular entity, which centrally controls read and write permissions.
  • a consortium blockchain network is provided for a select group of entities, which control the consensus process, and includes an access control layer.
  • a blockchain system is implemented using a peer-to-peer (P2P) network, in which the nodes communicate directly with each other, e.g., without the need of a fixed, central server. Each node in the P2P network may initiate communication with another node in the P2P network.
  • P2P peer-to-peer
  • a blockchain system maintains one or more blockchains.
  • a blockchain is a data structure that stores data, e.g., transactions, in a way that may prevent tampering and manipulation of the data by malicious parties. The transactions stored in this manner may be immutable and subsequently verified.
  • a blockchain includes one or more blocks. Each block is linked to a previous block immediately before it in the blockchain by including a cryptographic hash of the previous block. Each block also may include a timestamp, its own cryptographic hash, and one or more transactions.
  • the transactions which generally have already been verified by the nodes of the blockchain system, may be hashed and encoded into a data structure, such as a Merkle tree.
  • a Merkle tree In a Merkle tree, data at leaf nodes of the tree is hashed, and all hashes in each branch of the tree may be concatenated at a root of the branch. This process continues up the tree to the root of the entire tree, which stores a hash that is representative of all data in the tree. A hash purporting to be of a transaction stored in the tree can be quickly verified by determining whether it is consistent with the structure of the tree.
  • a 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 consortium blockchain network.
  • numerous entities such as hundreds, thousands, or even millions of entities, can operate in a public blockchain network, and each of the entities operates at least one node in the public blockchain network.
  • the public blockchain network can be considered a public network with respect to the participating entities.
  • a majority of entities (nodes) must sign every block for the block to be valid and added to the blockchain of the blockchain network.
  • Examples of public blockchain networks include particular peer-to-peer payment networks that leverage a distributed ledger, referred to as blockchain.
  • a public blockchain network may support public transactions.
  • a public transaction is shared with all of the nodes in the public blockchain network, and is stored in a global blockchain.
  • a global blockchain is a blockchain replicated across all nodes, and all nodes are in perfect state consensus with respect to the global blockchain.
  • consensus protocols include proof-of-work (POW) (e.g., implemented in the some crypto-currency networks) , proof-of-stake (POS) , and proof-of-authority (POA) .
  • PW proof-of-work
  • POS proof-of-stake
  • POA proof-of-authority
  • a private blockchain network may be provided for a particular entity, which centrally controls read and write permissions.
  • the entity controls which nodes are able to participate in the blockchain network.
  • private blockchain networks are generally referred to as permissioned networks that place restrictions on who is allowed to participate in the network, and on their level of participation (e.g., only in certain transactions) .
  • Various types of access control mechanisms can be used (e.g., existing participants vote on adding new entities, a regulatory authority can control admission) .
  • a consortium blockchain network may be private among the participating entities.
  • the consensus process is controlled by an authorized set of nodes, one or more nodes being operated by a respective entity (e.g., a financial institution, insurance company) .
  • a consortium of ten (10) entities e.g., financial institutions, insurance companies
  • the consortium blockchain network can be considered a private network with respect to the participating entities.
  • each entity (node) must sign every block in order for the block to be valid, and added to the blockchain.
  • at least a sub-set of entities (nodes) e.g., at least 7 entities
  • FIG. 1 illustrates a schematic diagram of a blockchain system 100, according to an embodiment.
  • the blockchain system 100 may include a plurality of nodes, e.g., nodes 102-110, configured to operate on a blockchain 120.
  • the nodes 102-110 may form a network 112, such as a peer-to-peer (P2P) network.
  • P2P peer-to-peer
  • Each of the nodes 102-110 may be a computing device, such as a computer or a computer system, configured to store a copy of the blockchain 120, or may be software running on the computing device, such as a process or an application.
  • Each of the nodes 102-110 may have a unique identifier.
  • the blockchain 120 may include a growing list of records in the form of data blocks, such as blocks B1-B5 in FIG. 1.
  • Each of the blocks B1-B5 may include a timestamp, a cryptographic hash of a previous block, and data of the present block, which may be transactions such as monetary transactions.
  • block B5 may include a timestamp, a cryptographic hash of block B4, and transaction data of block B5.
  • a hashing operation may be performed on the previous block to generate the cryptographic hash of the previous block.
  • the hashing operation may convert inputs of various lengths into cryptographic outputs of a fixed length through a hash algorithm, such as SHA-256.
  • the nodes 102-110 may be configured to perform an operation on the blockchain 120. For example, when a node, e.g., the node 102, wants to store new data onto the blockchain 120, that node may generate a new block to be added to the blockchain 120 and broadcast the new block to other nodes, e.g., the nodes 104-110, in the network 112. Based on legitimacy of the new block, e.g., validity of its signature and transactions, the other nodes may determine to accept the new block, such that the node 102 and the other nodes may add the new block to their respective copies of the blockchain 120. As this process repeats, more and more blocks of data may be added to the blockchain 120.
  • a node e.g., the node 102
  • that node may generate a new block to be added to the blockchain 120 and broadcast the new block to other nodes, e.g., the nodes 104-110, in the network 112.
  • the other nodes may determine to accept the new block, such that the
  • FIG. 2 illustrates a schematic diagram of a computing device 200 for implementing a node, e.g., the node 102 (FIG. 1) , in a blockchain system, according to an embodiment.
  • the computing device 200 may include a communication interface 202, a processor 204, and a memory 206.
  • the communication interface 202 may facilitate communications between the computing device 200 and devices implementing other nodes, e.g., nodes 104-110 (FIG. 1) , in the network.
  • 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, etc.
  • the communication interface 202 may include one or more of 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 communications.
  • the communication interface 202 may be based on public cloud infrastructure, private cloud infrastructure, hybrid public/private cloud infrastructure.
  • the 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.
  • the processor 204 is coupled with the memory 206 and is configured to execute instructions stored in the memory 206.
  • the memory 206 may store processor-executable instructions and data, such as a copy of the blockchain 120 (FIG. 1) .
  • the memory 206 may include any type of volatile or non-volatile memory devices, or a combination thereof, such as a static random-access memory (SRAM) , an electrically erasable programmable read-only memory (EEPROM) , an erasable programmable read-only memory (EPROM) , a programmable read-only memory (PROM) , a read-only memory (ROM) , a magnetic memory, a flash memory, or a magnetic or optical disk.
  • SRAM static random-access memory
  • EEPROM electrically erasable programmable read-only memory
  • EPROM erasable programmable read-only memory
  • PROM programmable read-only memory
  • ROM read-only memory
  • magnetic memory a magnetic memory
  • flash memory or a magnetic or optical disk.
  • FIG. 3 illustrates a flow chart of a method 300 for mitigating invoice financing fraud according to an embodiment.
  • multiple users may have accounts on a Blockchain, e.g., the blockchain 120 (FIG. 1) .
  • the Blockchain may be implemented to support various types of users, or parties, including, e.g., individuals, businesses, banks, financial institutions, hospitals, as well as other types of companies, organizations, and the like.
  • FIG. 3 For illustrative purposes, three users are depicted in FIG. 3, which includes a Seller, a Buyer, and a Bank.
  • the Seller may attempt to secure this financing by claiming to have an outstanding invoice issued to the Buyer.
  • the invoice may be issued by the Seller for various reasons, including, e.g., past or future services rendered or products sold to the Buyer.
  • the Bank may be willing to provide invoice financing to the Seller if the Seller agrees to secure the financing using the outstanding invoice.
  • the Bank may want to make sure that the invoice indeed exists and has not been used to secure financing from other institutions already. The Bank may therefore require the Seller to prove the validity of the invoice before the Bank agrees to provide invoice financing to the Seller.
  • the Bank may be willing to accept the validity of the invoice if the Seller and the Buyer can confirm the validity of the invoice based on the method 300 described in detail below.
  • the Seller may generate a digital invoice.
  • the digital invoice may be generated in various formats, including, e.g., a standardized format that users of the Blockchain have agreed to.
  • the digital invoice may contain data fields including, e.g., Seller’s identity or identifier, Buyer’s identity or identifier, description of product (s) or service (s) rendered, amount (s) due, payment terms, and the like.
  • the Seller may also generate a commitment value at step 302 for recordation on the Blockchain.
  • the Seller may calculate the commitment value CM_INVOICE by taking into consideration information regarding the Seller, the Buyer, and at least a portion of the invoice itself.
  • CM_INVOICE may be calculated based on a one-way function.
  • Hash functions such as SHA 256 and the like, are examples of one-way functions.
  • CM_INVOICE may be calculated as a 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 the Buyer, respectively, and INVOICE_DIGEST represents a hash value of the digital invoice, or a hash value of one or more portions of the digital invoice.
  • TN may represent a token generated by the Seller that can be used to prevent the Seller from using the digital invoice to obtain financing more than once (i.e., prevent double financing) .
  • TN may include a random number.
  • TN may also include alphanumeric values, and in some embodiments, TN may include a serial number.
  • R may represent a random factor generated by the Seller to further protect information contained in PK_SELLER, PK_BUYER, and INVOICE_DIGEST. In some embodiments, R may be a random number or a random alphanumeric value.
  • the Seller may also generate a zero-knowledge proof, denoted as SELLER’S_PROOF, at step 302.
  • Zero-knowledge proof refers to techniques that allow a prover to prove to a verifier that a statement is true without revealing any information beyond the validity of the statement itself.
  • the Seller is the prover, who may prove to the Blockchain, or a smart contract executing on the Blockchain, which serves as the verifier, that the Seller is the true issuer of the invoice in question.
  • the Seller may attempt to prove this by indicating that: (1) CM_INVOICE is well formed and (2) the Seller is indeed the Seller itself.
  • the Seller may prove to the Blockchain that the commitment value of (PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN, R) is CM_INVOICE.
  • the Seller and the Blockchain may agree to implement zero-knowledge proof techniques such as Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARK) or the like.
  • the Seller may prove to the Blockchain that the Seller knows a secret input w such that for a public input x, a certain relationship between x and w holds true.
  • the relationship may be defined as an arithmetic circuit.
  • the arithmetic circuit may be defined based on an equation of polynomials that can be evaluated based on x and w.
  • a proving key and a verification key may be generated in a setup phase based on the arithmetic circuit and one or more security parameters established for the zero-knowledge proof.
  • the setup phase may be executed by a trusted party, or by multiple independent parties collaboratively using a multi-party computation.
  • the Seller may set x to CM_INVOICE and set w to a value generated based on PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN, R, and SK_SELLER.
  • w may be generated by concatenating PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN, R, and SK_SELLER together.
  • the Seller may generate SELLER’S_PROOF using the secret and public inputs as well as the proving key to prove to the Blockchain that the Seller is in possession of the secret input w.
  • the Blockchain may verify SELLER’S_PROOF using the public input and the verification key generated in the setup phase.
  • the Blockchain may accept the Seller’s statements as true.
  • the Seller may submit a transaction to the Blockchain with payload containing ⁇ CM_INVOICE, SELLER’S_PROOF ⁇ .
  • this transaction may be referred to as an “ISSUE_INVOICE” transaction.
  • the Blockchain may check SELLER’S_PROOF to determine whether the Seller is in possession of the secret input w.
  • the Blockchain may utilize one or more smart contracts executing on the Blockchain to provide the determination.
  • Smart contracts are computer protocols implemented in the form of computer code that are incorporated into the Blockchain, to facilitate, verify, or enforce the negotiation or performance of contracts.
  • users of the Blockchain may program agreed terms into a smart contract using a programming language, such as C++, Java, Solidity, Python, etc., and when the terms are met, the smart contract may be automatically executed on the Blockchain, e.g., to perform a transaction.
  • the smart contract may include a plurality of subroutines or functions, each of which may be a sequence of program instructions that performs a specific task.
  • the smart contract may be operational code that is fully or partially executed without human interaction.
  • a smart contract may be incorporated into the Blockchain to determine whether SELLER’S_PROOF is acceptable.
  • the smart contract may verify SELLER’S_PROOF using the public input and the verification key. If SELLER’S_PROOF cannot be verified, the smart contract may refuse to allow the Seller to proceed further. On the other hand, if SELLER’S_PROOF can be verified, then the smart contract may determine that SELLER’S_PROOF is acceptable and proceed to record CM_INVOICE in a seller-submitted invoice pool.
  • the seller-submitted invoice pool may be structured as a Merkle tree T_INVOICE and CM_INVOICE may be recorded on a leaf node of the Merkle tree T_INVOICE.
  • the Seller may proceed to ask the Buyer to validate the digital invoice generated by the Seller.
  • the Seller may send the digital invoice and the values of TN and R privately to the Buyer through an off-chain communication channel.
  • the Seller may also send CM_INVOICE to the Buyer.
  • the Buyer may reconstruct CM_INVOICE based on the digital invoice and the values of TN and R received from the Seller.
  • the Buyer may examine the digital invoice to determine whether the digital invoice is valid.
  • the Buyer may invalidate the digital invoice if, e.g., the Seller misstated the outstanding amount or falsified the invoice.
  • the Buyer may also invalidate the digital invoice if the Buyer determines that CM_INVOICE is not recorded in the seller-submitted invoice pool, or that the recorded CM_INVOICE does not match the commitment value of (PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN, R) .
  • the Seller attempts to bypass steps 304-306, or attempts to change the digital invoice or the values of TN or R, such attempts can be detected by the Buyer, who can then invalidate the digital invoice and prevent fraud.
  • the Buyer may proceed to generate a buyer-verified commitment value for recordation on the Blockchain.
  • the Buyer may calculate the buyer-validated commitment value CM_BV_INVOICE as:
  • CM_BV_INVOICE may be calculated based on the same one-way function used by the Seller to calculate CM_INVOICE. It is noted that while the values of PK_SELLER, PK_BUYER, and INVOICE_DIGEST may be the same, the Buyer may be responsible for generating 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 an unrelated user from linking the two commitment values together, which in turn prevents the unrelated user from linking the Seller and the Buyer together.
  • the Buyer may also generate a zero-knowledge proof, denoted as BUYER’S_PROOF, at step 310.
  • the Buyer may generate BUYER’S_PROOF to prove to the Blockchain that the Buyer is the true receiver of the invoice.
  • the Buyer may attempt to prove this by indicating that: (1) CM_INVOICE is well formed, (2) CM_INVOICE is recorded in the seller-submitted invoice pool, (3) CM_BV_INVOICE is well formed, and (4) the Buyer is indeed the Buyer itself.
  • the Buyer may prove to the Blockchain that the Buyer knows the values of PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN, and R and that the commitment value of (PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN, R) is CM_INVOICE.
  • the Buyer may prove to the Blockchain that CM_INVOICE is a valid leaf node in the Merkle tree T_INVOICE.
  • the Buyer may prove to the Blockchain that the commitment value of (PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN’, R’) is CM_BV_INVOICE.
  • the Buyer and the Blockchain may agree to implement the zero-knowledge proof techniques described above.
  • the Buyer may prove to the Blockchain that the Buyer knows a secret input w such that for a public input x, a certain relationship between x and w holds true.
  • the relationship may be defined as an arithmetic circuit, which may be defined based on an equation of polynomials that can be evaluated based on x and w.
  • a proving key and a verification key may be generated in a setup phase based on the arithmetic circuit and one or more security parameters established for the zero-knowledge proof.
  • the Buyer may 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 may be able to generate BUYER’S_PROOF to prove to the Blockchain that the Buyer is in possession of the secret input w. In some embodiments, if the Blockchain accepts the Buyer’s proof that the Buyer is in possession of the secret input w, the Blockchain may accept the Buyer’s statements as true.
  • the Buyer may send the values of TN’ and R’ to the Seller so that the Seller can later use the buyer-validated invoice to obtain financing from the Bank.
  • the Buyer may submit a transaction to the Blockchain with payload containing ⁇ TN, CM_BV_INVOICE, BUYER’S_PROOF ⁇ .
  • this transaction may be referred to as a “BUYER_VALIDATED_INVOICE” transaction.
  • the Blockchain may utilize a smart contract to check whether TN contained in the payload has been used or spent already.
  • the smart contract may maintain a used token list on the Blockchain to record used tokens. If TN contained in the payload is listed in the used token list, the smart contract may refuse to proceed further because the Seller is attempting to use the same digital invoice to obtain financing more than once. On the other hand, if TN contained in the payload is not listed in the used token list, the smart contract may proceed to verify whether BUYER’S_PROOF is acceptable. The smart contract may verify BUYER’S_PROOF using the public input and the verification key.
  • the smart contract may determine that BUYER’S_PROOF is acceptable and proceed to record CM_BV_INVOICE in a buyer-validated invoice pool.
  • the buyer-validated invoice pool may be structured as a Merkle tree T_BV_INVOICE and CM_BV_INVOICE may be recorded on a leaf node of the Merkle tree T_BV_INVOICE.
  • the smart contract may also add TN to the used token list to indicate that TN has been used, thereby invalidating TN for future use.
  • the Seller may proceed to request for invoice financing from the Bank.
  • the Seller may send the digital invoice and the values of TN’ and R’ privately to the Bank through an off-chain communication channel.
  • the Seller may also calculate the value of CM_BV_INVOICE and send CM_BV_INVOICE to the Bank.
  • the Bank may reconstruct CM_BV_INVOICE based on the digital invoice and the values of TN’ and R’ received from the Seller.
  • the Bank may determine whether the digital invoice is valid.
  • the Bank may invalidate the digital invoice if, e.g., the digital invoice has not been validated by the Buyer.
  • the Bank may make this determination by determining whether CM_BV_INVOICE is recorded in the buyer-validated invoice pool (e.g., in the Merkle tree T_BV_INVOICE) . If CM_BV_INVOICE is not recorded in the buyer-validated invoice pool, the Bank may determine that the digital invoice is invalid and refuse to allow the Seller to proceed further. On the other hand, if CM_BV_INVOICE is recorded in the buyer-validated invoice pool, the Bank may determine that the digital invoice is valid. The Bank may then proceed to decide whether to provide invoice financing to the Seller.
  • the Bank may also determine whether TN’ provided by the Seller has been used already. In some embodiments, the Bank may call a smart contract executing on the Blockchain to check whether TN’ is listed in the used token list. If TN’ is listed in the used token list, the Bank may refuse to proceed further because the Seller is attempting to use the same digital invoice to obtain financing more than once. If TN’ is not listed in the used token list, the Bank may proceed to decide whether to provide invoice financing to the Seller.
  • the Bank may take various factors into consideration in determining whether to provide invoice financing to the Seller. Such factors may include, e.g., the size of the invoice, the Seller’s credit score and credit history, the Bank’s prior dealings with the Seller, and the like. Additional factors may include, e.g., the Buyer’s credit score and the Bank’s prior dealings with the Buyer.
  • the Bank may communicate that decision to the Seller privately through an off-chain communication channel, in which case the Seller may choose to repeat step 318 and request for invoice financing from a different fund provider.
  • the Bank may proceed to generate a zero-knowledge proof, denoted as BANK’S_PROOF, at step 320, to prove to the Blockchain that the Bank has verified the validity of the Seller’s request to provide invoice financing.
  • the Bank may attempt to prove this by indicating that: (1) CM_BV_INVOICE is well formed and (2) CM_BV_INVOICE is recorded in the buyer-validated invoice pool.
  • the Bank may prove to the Blockchain that the Bank knows the values of PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN’, and R’ and that the commitment value of (PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN’, R’) is CM_BV_INVOICE.
  • the Bank may prove to the Blockchain that CM_BV_INVOICE is a valid leaf node in the Merkle tree T_BV_INVOICE.
  • the Bank and the Blockchain may agree to implement the zero-knowledge proof techniques described above.
  • the Bank may prove to the Blockchain that the Bank knows a secret input w such that for a public input x, a certain relationship between x and w holds true.
  • the relationship may be defined as an arithmetic circuit, which may be defined based on an equation of polynomials that can be evaluated based on x and w.
  • a proving key and a verification key may be generated in a setup phase based on the arithmetic circuit and one or more security parameters established for the zero-knowledge proof.
  • the Bank may set x to TN’ and set w to a value generated based on PK_SELLER, PK_BUYER, INVOICE_DIGEST, R’, and CM_BV_INVOICE. In this manner, the Bank may be able to generate BANK’S_PROOF to prove to the Blockchain that the Bank is in possession of the secret input w. In some embodiments, if the Blockchain accepts the Bank’s proof that the Bank is in possession of the secret input w, the Blockchain may accept the Bank’s statements as true.
  • the Bank may submit a transaction to the Blockchain with payload containing ⁇ TN’, BANK’S_PROOF ⁇ .
  • this transaction may be referred to as an “ISSUE_FINANCING” transaction.
  • the Blockchain may utilize a smart contract to check whether TN’ contained in the payload has been used already.
  • 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 further because the Seller is attempting to use the same digital invoice to obtain financing more than once. If TN’ is not listed in the used token list, the smart contract may proceed to verify whether BANK’S_PROOF is acceptable. The smart contract may verify BANK’S_PROOF using the public input and the verification key.
  • the smart contract may determine that BANK’S_PROOF is acceptable and proceed to invalidate TN’ (e.g., by adding TN’ to the used token list) and report to the Bank at step 326 that no fraud is detected based on the transactions received so that the Bank can proceed to issue invoice financing to the Seller.
  • one used token list may be utilized to record used tokens generated by the Seller and a separate used token list may be utilized to record used tokens generated by the Buyer. It is to be understood that other types of data structures may also be utilized to record used tokens. Furthermore, it is to be understood that the declarations of the functions, variables, and transactions described above are merely presented as examples and are not meant to be limiting.
  • the method 300 can avoid double financing an invalidated invoice.
  • the method 300 can also mitigate fraudulent activities where the Seller may produce fake invoices and attempt to borrow money using such invoices.
  • the method 300 may further protect privacy by hiding user identities, amounts due, payment terms, and other invoice-related information using commitment values.
  • the method 300 may also ensure that the transactions recorded on the Blockchain are unlinkable by unrelated users, thereby preventing unrelated users from knowing the users related to these transactions.
  • ISSUE_INVOICE if a user wants to further conceal the number of “ISSUE_INVOICE” transactions, “BUYER_VALIDATED_INVOICE” transactions, or “ISSUE_FINANCING” transactions the user submits to the Blockchain, the user may choose to use one-time anonymous blockchain identities to submit such transactions.
  • FIG. 4 illustrates a flow chart of a method 400 for mitigating invoice financing fraud, according to an embodiment.
  • the method 400 may be performed by one or more nodes in a blockchain system, e.g., the nodes 102-110 in the blockchain system 100 (FIG. 1) .
  • the nodes 102-110 in the blockchain system 100 may perform operations on a blockchain, e.g., the blockchain 120 (FIG. 1) .
  • the blockchain 120 may be implemented as the Blockchain in the examples described above.
  • a node may receive a first transaction submitted by a first user.
  • the first user may be, e.g., the Seller (FIG. 3) , who is the issuer of an invoice and is attempting to secure financing using the invoice.
  • the first transaction may include the “ISSUE_INVOICE” transaction (FIG. 3) described above, which may include a first commitment of the invoice, e.g., CM_INVOICE, and a first proof, e.g., SELLER’S_PROOF.
  • the node 102 may determine whether the first proof is acceptable and report a detection of fraud in response to a determination that the first proof is unacceptable.
  • the first proof may be a zero-knowledge proof generated by the first user to prove that the first user is the true issuer of the invoice.
  • the first user may attempt to prove to the node 102 that the first commitment of the invoice is well formed and that the first user is indeed the first user itself.
  • the node 102 may accept the first proof if the first user can prove to the node 102 that the first user is in possession of certain secret information described above.
  • the node 102 may report a detection of suspected fraud.
  • the node 102 may, at step 406, record the first commitment in a first invoice pool, which was referred to as the seller-submitted invoice pool in the examples described above.
  • the first invoice pool may include a first Merkle tree, e.g., T_INVOICE, and recording the first commitment in the first invoice pool may include recording the first commitment on a leaf node of the first Merkle tree T_INVOICE.
  • the node 102 may receive a second transaction submitted by a second user.
  • the second user may be, e.g., the Buyer (FIG. 3) , who is the receiver of the invoice.
  • the second transaction may include the “BUYER_VALIDATED_INVOICE” transaction (FIG. 3) described above, which may include a first token, e.g., TN, generated by the first user, a second commitment of the invoice, e.g., CM_BV_INVOICE, and a second proof, e.g., BUYER’S_PROOF.
  • the node 102 may determine whether the first token is valid and whether the second proof is acceptable. The node 102 may report a detection of fraud in response to a determination that the first token is invalid or the second proof is unacceptable. In some embodiments, the node 102 may determine whether the first token is valid by determining whether the first token is listed in a used token list. 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 receiver of the invoice. In some embodiments, the second user may attempt to prove to the node 102 that the first commitment is well formed and is recorded in first invoice pool. The second user may also attempt to prove to the node 102 that the second commitment is well formed and that the second user is indeed the second user itself. In some embodiments, the node 102 may accept the second proof if the second user can prove to the node 102 that the second user is in possession of certain secret information described above.
  • the node 102 may report a detection of suspected fraud.
  • the node 102 may, at step 412, record the second commitment in a second invoice pool, which was referred to as the buyer-validated invoice pool in the examples described above.
  • the second invoice pool may include a second Merkle tree, e.g., T_BV_INVOICE, and recording the second commitment in the second invoice pool may include recording the second commitment on a leaf node of the second Merkle tree T_BV_INVOICE.
  • the node 102 may also invalidate the first token.
  • the node 102 may invalidate the first token by adding the first token to a used token list.
  • the node 102 may receive a third transaction submitted by a third user.
  • the third user may be, e.g., the Bank (FIG. 3) , who is a fund provider having received a request to provide invoice financing to the first user.
  • the third transaction may include the “ISSUE_FINANCING” transaction (FIG. 3) described above, which may include a second token, e.g., TN’, generated by the second user, and a third proof, e.g., BANK’S_PROOF, generated by the third user.
  • the node 102 may determine whether the second token is valid and whether the third proof is acceptable.
  • the node 102 may report a detection of fraud in response to a determination that the second token is invalid or the third proof is unacceptable.
  • the node 102 may determine whether the second token is valid by determining whether the second token is listed in a used token list.
  • the third proof may be a zero-knowledge proof generated by the third user to prove that the third user has verified validity of the request to provide invoice financing to the first user.
  • the third user may attempt to prove to the node 102 that the second commitment of the invoice is well formed and is recorded in second invoice pool.
  • the node 102 may accept the third proof if the third user can prove to the node 102 that the third user is in possession of certain secret information described above.
  • the node 102 may report a detection of suspected fraud.
  • the node 102 may, at step 418, invalidate the second token and report to the third user that no fraud is detected based on the transactions received.
  • the node 102 may invalidate the second token by adding the second token to a used token list. The third user may proceed to issue invoice financing to the first user.
  • FIG. 5 is a block diagram of an invoice financing fraud mitigation apparatus 500, according to an embodiment.
  • the apparatus 500 may be an implementation of a software process, and may correspond to the method 400 (FIG. 4) .
  • the apparatus 500 may include a receiving module 502, a determination module 504, a recording module 506, and a reporting module 508.
  • the receiving module 502 may receive a first transaction submitted by a first user.
  • the first transaction may include the “ISSUE_INVOICE” transaction (FIG. 3) described above, which may include a first commitment of an invoice, e.g., CM_INVOICE, generated by the first user and a first proof, e.g., SELLER’S_PROOF, generated by the first user.
  • the receiving module 502 may provide the received transaction to the determining module 504.
  • the determining module 504 may determine whether the first proof is acceptable. In response to a determination that the first proof is unacceptable, the determining module 504 may request the reporting module 510 to report a detection of fraud. Otherwise, the determining module 504 may provide the first commitment to the recording module 508, which may record the first commitment in a first invoice pool.
  • the receiving module 502 may receive a second transaction submitted by a second user.
  • the second transaction may include the “BUYER_VALIDATED_INVOICE” transaction (FIG. 3) described above, which may include a first token, e.g., TN, generated by the first user, a second commitment of the invoice, e.g., CM_BV_INVOICE, generated by the second user, and a second proof, e.g., BUYER’S_PROOF, generated by the second user.
  • the receiving module 502 may provide the received transaction to the determining module 504.
  • the determining module 504 may determine whether the first token is valid and whether the second proof is acceptable. In response to a determination that the first token is invalid or that the second proof is unacceptable, the determining module 504 may request the reporting module 510 to report a detection of fraud. Otherwise, the determining module 504 may provide the second commitment to the recording module 508, which may record the second commitment in a second invoice pool and record the first token as been used, thereby invalidating the first token.
  • the receiving module 502 may receive a third transaction submitted by a third user.
  • the third transaction may include the “ISSUE_FINANCING” transaction (FIG. 3) described above, which may include a second token, e.g., TN’, generated by the second user, and a third proof, e.g., BANK’S_PROOF, generated by the third user.
  • the receiving module 502 may provide the received transaction to the determining module 504.
  • the determining module 504 may determine whether the second token is valid and whether the third proof is acceptable. In response to a determination that the second token is invalid or that the third proof is unacceptable, the determining module 504 may request the reporting module 510 to report a detection of fraud. Otherwise, the determining module 504 may request the recording module 508 to record the second token as been used, thereby invalidating the second token. The determining module 504 may also request the reporting module 510 to report to the third user that no fraud is detected based on the transactions received so that the third user can proceed to issue invoice financing to the first user.
  • each of the above described modules may be implemented as software, or hardware, or a combination of software and hardware.
  • each of the above described modules may be implemented using a processor executing instructions stored in a memory.
  • each the above described modules may be implemented with 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, for performing the described methods.
  • ASICs application specific integrated circuits
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGAs field programmable gate arrays
  • controllers micro-controllers, microprocessors, or other electronic components, for performing the described methods.
  • each of the above described modules may be implemented by using a computer chip or an entity, or implemented by using a product having
  • the apparatus 500 may be a computer, and the computer may be a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, a game console, a tablet computer, a wearable device, or any combination of these devices.
  • a computer program product may include a non-transitory computer-readable storage medium having computer-readable program instructions thereon for causing a processor to carry out the above-described methods.
  • the 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 is 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 disk (DVD) , a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing.
  • RAM random access memory
  • ROM read-only memory
  • EPROM erasable programmable read-only memory
  • SRAM static random access memory
  • CD-ROM compact disc read-only memory
  • DVD digital versatile disk
  • memory stick a floppy disk
  • a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon
  • the computer-readable program instructions for carrying out the above-described methods may be assembler 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 an object oriented programming language, and conventional procedural programming languages.
  • the computer-readable program instructions may execute entirely on a computing device as a stand-alone software package, or partly on a first computing device and partly on a second computing device remote from the first computing device. In the latter scenario, the second, remote computing device may be connected to the first computing device through any type of network, including a local area network (LAN) or a wide area network (WAN) .
  • LAN local area network
  • WAN wide area network
  • 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 above-described methods.
  • a block in the flow charts or diagrams may represent a software program, segment, or portion of code, which comprises one or more executable instructions for implementing specific functions.
  • the functions noted in the blocks 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.
  • each block of the diagrams and/or flow charts, and combinations of blocks in the diagrams and flow charts may be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Storage Device Security (AREA)
PCT/CN2020/128040 2020-01-08 2020-11-11 Methods and devices for mitigating invoice financing fraud WO2021139391A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202080091457.1A CN114945931A (zh) 2020-01-08 2020-11-11 用于减轻票据融资欺诈的方法和设备

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SG10202000181P 2020-01-08
SG10202000181PA SG10202000181PA (en) 2020-01-08 2020-01-08 Methods And Devices For Mitigating Invoice Financing Fraud

Publications (1)

Publication Number Publication Date
WO2021139391A1 true WO2021139391A1 (en) 2021-07-15

Family

ID=72355632

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/128040 WO2021139391A1 (en) 2020-01-08 2020-11-11 Methods and devices for mitigating invoice financing fraud

Country Status (3)

Country Link
CN (1) CN114945931A (zh)
SG (1) SG10202000181PA (zh)
WO (1) WO2021139391A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SG10202000181PA (en) * 2020-01-08 2020-07-29 Alipay Labs Singapore Pte Ltd Methods And Devices For Mitigating Invoice Financing Fraud
SG10202000173WA (en) * 2020-01-08 2020-07-29 Alipay Labs Singapore Pte Ltd Methods And Devices For Mitigating Invoice Financing Fraud

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106952124A (zh) * 2017-03-16 2017-07-14 北京牛链科技有限公司 基于分布式记账的电子发票管理系统和方法
US20180082290A1 (en) * 2016-09-16 2018-03-22 Kountable, Inc. Systems and Methods that Utilize Blockchain Digital Certificates for Data Transactions
CN109345194A (zh) * 2018-09-12 2019-02-15 北京东港瑞宏科技有限公司 一种电子票据流转系统
SG10202000181PA (en) * 2020-01-08 2020-07-29 Alipay Labs Singapore Pte Ltd Methods And Devices For Mitigating Invoice Financing Fraud

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180082290A1 (en) * 2016-09-16 2018-03-22 Kountable, Inc. Systems and Methods that Utilize Blockchain Digital Certificates for Data Transactions
CN106952124A (zh) * 2017-03-16 2017-07-14 北京牛链科技有限公司 基于分布式记账的电子发票管理系统和方法
CN109345194A (zh) * 2018-09-12 2019-02-15 北京东港瑞宏科技有限公司 一种电子票据流转系统
SG10202000181PA (en) * 2020-01-08 2020-07-29 Alipay Labs Singapore Pte Ltd Methods And Devices For Mitigating Invoice Financing Fraud

Also Published As

Publication number Publication date
SG10202000181PA (en) 2020-07-29
CN114945931A (zh) 2022-08-26

Similar Documents

Publication Publication Date Title
US11004067B2 (en) Methods and devices for protecting sensitive data of transaction activity based on smart contract in blockchain
US11637709B2 (en) Split-key wallet access between blockchains
US20220084013A1 (en) Identity management, smart contract generator, and blockchain mediating system, and related methods
US11887072B2 (en) Digital currency minting in a system of network nodes implementing a distributed ledger
US20220311611A1 (en) Reputation profile propagation on blockchain networks
WO2021139391A1 (en) Methods and devices for mitigating invoice financing fraud
WO2020182233A2 (en) Methods and devices for executing cross-chain anonymous multi-swap contracts
WO2021139544A1 (en) Methods and devices for mitigating invoice financing fraud
WO2021139543A1 (en) Methods and devices for managing standby letter of credit
WO2021223653A1 (en) Methods and devices for protecting and verifying state transition of record
WO2021139605A1 (en) Methods and devices for providing decentralized identity verification
WO2021139545A1 (en) Methods and devices for facilitating split invoice financing
WO2023099357A1 (en) Compressible blockchains
US20230188353A1 (en) Multi-issuer anonymous credentials for permissioned blockchains
US20230119035A1 (en) Platform services verification
US20220399988A1 (en) Linking blockchain operations
WO2021223661A1 (en) Methods and devices for protecting and verifying state information of record
US20220036355A1 (en) Methods and devices for privacy-preserving verification of profit-sharing between users
WO2021139392A1 (en) Methods and devices for providing atomic transaction on blockchain
WO2021139542A1 (en) Methods and devices for providing atomic transaction on blockchain
US20230306412A1 (en) Docket credential insertion in non-fungible tokens
US20230252482A1 (en) Lock contracts in blockchain networks
WO2023167636A1 (en) Methods and devices for providing privacy-preserving auditable ledger for managing tokens
CN115454658A (zh) 检测实时全额结算系统中死锁的方法、设备、装置和介质
CN111580982A (zh) 检测实时全额结算系统中死锁的方法、设备、装置和介质

Legal Events

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

Ref document number: 20911334

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20911334

Country of ref document: EP

Kind code of ref document: A1