WO2023201359A2

WO2023201359A2 - Method, controller, and computer readable medium for detecting expiration of a unique cryptographic identifier on a distributed transfer network

Info

Publication number: WO2023201359A2
Application number: PCT/US2023/065809
Authority: WO
Inventors: Marc Meyer; Tomasz CZERNUSZENKO; Kevin Hopkins
Original assignee: Agora Intelligence Inc
Current assignee: Agora Intelligence Inc
Priority date: 2022-04-14
Filing date: 2023-04-14
Publication date: 2023-10-19
Anticipated expiration: 2024-10-14
Also published as: WO2023201360A2; WO2023201360A3; WO2023201359A3

Abstract

A method, controller, and computer-readable medium for executing an exchange transfer including receiving a transfer data structure, initiating generation of a unique cryptographic identifier corresponding to the transfer data structure on a distributed file system, generating a self-executing code corresponding to the transfer data structure, executing an exchange transfer corresponding to the transfer data structure, detecting one or more subsequent transfers from the second entity to the current owner of the unique cryptographic identifier on the distributed file system, and designating the unique cryptographic identifier as expired based at least in part on detection of the one or more subsequent transfers.

Description

METHOD, CONTROLLER, AND COMPUTER READABLE MEDIUM FOR DETECTING EXPIRATION OF A UNIQUE CRYPTOGRAPHIC IDENTIFIER ON A DISTRIBUTED TRANSFER NETWORK

RELATED APPLICATION DATA

[0001] This application claims priority to U.S. Provisional Application No. 63/331,150, filed April 14, 2022 and U.S. Provisional Application No. 63/331,156, filed April 14, 2022, the disclosures of which are hereby incorporated by reference in their entirety.

BACKGROUND

[0002] There are a number of drawbacks associated with transfers between entities on a transfer network. These drawbacks include difficulties in verification of the identities of the relevant entities, verification of parameters governing transfers, inefficient processing procedures, high costs associated with data management, and difficulties detecting and preventing fraud. Furthermore, there is a lack of standardization of transfers, meaning that obligations and requirements stemming from transfers are not transferrable to other parties.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Fig. 1 illustrates a flowchart for detecting expiration of a unique cryptographic identifier on a distributed transfer network according to an exemplary embodiment.

[0004] Fig. 2 illustrates a flowchart for detecting one or more subsequent transfers from the second entity to the current owner of the unique cryptographic identifier on the distributed file system and designating the unique cryptographic identifier as expired according to an exemplary embodiment.

[0005] Fig. 3 illustrates a system chart of the system for facilitating a receivable funding transaction with an NFT corresponding to a receivable contract according to an exemplary embodiment. [0006] Fig. 4A illustrates a system chart of a system for facilitating a receivable funding transaction with an NFT corresponding to a receivable contract showing the seller as current owner of the NFT after minting.

[0007] Fig. 4B illustrates a system chart of a system for facilitating a receivable funding transaction with an NFT corresponding to a receivable contract showing the transfer of the NFT from the seller to the funder in exchange for payment from the funder to the seller according to an exemplary embodiment.

[0008] Fig. 4C illustrates a system chart of a system for facilitating a receivable funding transaction with an NFT corresponding to a receivable contract showing the designation of the NFT as expired in response to detecting a repayment from the seller to the purchaser corresponding to the amount due on the transaction according to an exemplary embodiment.

[0009] Fig. 5A illustrates a system chart of a system for facilitating a receivable funding transaction with an NFT corresponding to a receivable contract showing a funder transferring ownership of the NFT to a purchaser, the transfer being recorded on the distributed ledger, according to an exemplary embodiment.

[0010] Fig. 5B illustrates a system chart of a system for facilitating a receivable funding transaction with an NFT corresponding to a receivable contract showing the designation of the NFT as expired in response to detecting a repayment from the seller to the purchaser corresponding to the amount due on the transaction according to an exemplary embodiment.

[0011] Fig. 6 illustrates a diagram of the funding of a receivables funding process using a method and system for facilitating a receivables funding transaction according to an exemplary embodiment.

[0012] Fig. 7 illustrates a diagram of repayment of the receivables funding process using a method and system for facilitating a receivables funding transaction according to an exemplary embodiment. [0013] Fig. 8 illustrates a system diagram of an onboarding process according to an exemplary embodiment.

[0014] Fig. 9 illustrates a system diagram of a funding and repayment process according to an exemplary embodiment.

[0015] Fig. 10 illustrates a system diagram of a funding process according to an exemplary embodiment.

[0016] Fig. 11 illustrates a system diagram of the architecture of receivables data from the receivable contract according to an embodiment.

[0017] Fig. 12 illustrates a system diagram of a financing platform implementing one or more recovery mechanisms when the receivable is not paid in full or when repayment is late.

[0018] Fig. 13 illustrates the components of the specialized computing environment configured to perform the specialized method for detecting expiration of a unique cryptographic identifier on a distributed transfer network described herein.

DETAILED DESCRIPTION

[0019] It is to be understood that at least some of the figures and descriptions of the invention have been simplified to illustrate elements that are relevant for a clear understanding of the invention, while eliminating, for purposes of clarity, other elements that those of ordinary skill in the art will appreciate also comprise a portion of the invention. However, because such elements do not facilitate a better understanding of the invention, a description of such elements is not provided herein.

[0020] Applicant has discovered a method, controller, and computer-readable medium for detecting expiration of a unique cryptographic identifier on a distributed transfer network in an exchange transfer.

[0021] The present system and related techniques can be applied to a variety of contexts. For example, the present system can be utilized in an invoice or receivable transfer context, in which an invoice or receivable is sold by a seller in exchange for funds provided by a funder. In this context, the present method, controller, and computer-readable medium can be used for facilitating a funding transaction on a receivable financing platform with a non-fungible token (NFT) corresponding to a receivable contract (referred to herein as “receivable contracts,” “receivables,” and “invoices”).

[0022] In the context of receivable contracts, e.g., invoices, a seller is the party that sells goods or services. A buyer is the party named on the receivable contract that owes an outstanding balance to the seller, e.g., a customer of the seller. A funder refers to a party that provides funding to the seller on the basis of the outstanding receivable contract.

[0023] Invoice financing involves funders providing funding to sellers on the basis of invoices owed to the sellers from buyers. While many companies would benefit from invoicebased financing, it is difficult for many sellers to find funders and for many funders to find sellers. Interfacing with financial institutions to facilitate invoice financing adds administrative complexity, making it more difficult for all parties to ensure payment and funding.

[0024] Additionally, there exist issues with verifying the invoice and the parties involved, inefficient processing procedures, high costs associated with data management, and difficulties detecting and preventing fraud. Furthermore, invoices have no standard form or input and repayment obligations stemming from invoice-based financing are not transferrable to other funders or purchasers or tradeable on any kind of exchange.

[0025] The present application discloses a system and method that utilizes decentralized finance (DeFi), and blockchain to disrupt traditional models and offers the ability for participants to efficiently access and provide financing. Furthermore, by utilizing trustless networks like Ethereum, the present system supports the ability to tokenize real world assets like receivables, and subsequently group these tokenized assets together to be offered as a lending pool or to securely exchange them on a marketplace.

[0026] As blockchain technologies gain more popularity, representation of a receivable using a Non-Fungible Token (NFT) on a blockchain has potential for unlocking opportunities for new data representation of a new asset class (receivables) as well as structured securitization and trading of those assets. Finally, this solution allows for tapping into a liquidity pool of distributed assets stored on the blockchain technology, e.g., stable coins, crypto currencies.

[0027] The present system offers many advantages. Specifically:

[0028] -Tokenizing the receivable contract as a non-fungible token leverages the immutability, transparency, and decentralization of a blockchain to reduce risk and capital costs while making receivable funding more widely accessible.

[0029] -A tokenized receivable contract is easily tradeable through the distributed ledgers, can be instantly verified and checked for authenticity, and drastically improves the syndication process.

[0030] -Building on an Ethereum sidechain provides greater scalability, reduces transaction costs, supports fast transactions, and reduces energy consumption while leveraging Ethereum’ s core features and compatibility with the Ethereum Virtual Machine (EVM).

[0031] -Storing metadata associated with the receivable contract on a decentralized file network, such as the Interplanetary File System (IPFS) separate from the distributed ledger reduces costs on-chain and prevents data from being blocked, censored, or changed by a central entity such as a traditional server-storage solution.

[0032] -Automating investment with the financing platform allows for receivable NFTs to be purchased immediately and automatically rather than requiring human intervention or long processing time.

[0033] Fig. 1 illustrates a flowchart for detecting expiration of a unique cryptographic identifier on a distributed transfer network according to an exemplary embodiment. Each of the steps shown in Fig. 1 can be executed by one or more computing devices of a controller of a distributed transfer network. The distributed transfer network can be hosted on one or more servers of a computer network and can include a network-host, network-clients, and other entities connected to the network. [0034] In the invoice and receivables financing context, this flowchart can correspond to facilitating a receivable funding transaction on a receivable financing platform with an NFT corresponding to a receivable contract. The receivable financing platform can be hosted on one or more servers of a computer network and is accessible to funders, sellers, and buyers through the computer network ( .g., via web portal).

[0035] A receivable contract (a.k.a. a receivable) represents the money owed to a business, e.g., a seller, after it sells products or services to a buyer (a.k.a. an obligor).

Commonly, payment terms and information about the goods or services provided are captured in a seller-issued invoice.

[0036] At step 101, a transfer data structure is received. The transfer data structure identifies a first entity having requirements associated with a transfer to a second entity, the second entity having collection authority to receive the transfer from the first entity, and one or more transfer parameters governing the transfer.

[0037] In the invoice and receivables financing context, this step can include receiving a receivable contract (transfer data structure). A receivable contract can include information about a buyer (first entity), a seller (second entity), and one or more contract parameters (transfer parameters). One or more contract parameters can be, for example, an invoice amount, an administrator fee, a fee period, etc. (first entity having requirements associated with a transfer to a second entity).

[0038] The receivable contract can be received by a financing platform. For example, referring to Fig. 3, a financing platform, e.g. 301, receives a receivable contract from a user, such as a seller.

[0039] Returning to Fig. 1, in the invoice and receivables financing context, step 101 can include assessing the validity of the receivable contract. The receivable contract can go through an invoice validation tool and be assessed for risk (e.g., risk of default, delayed repayment, etc.). One or more risk scores can be assigned to the receivable contract, where one or more risk scores is determined based at least in part on one or more of a seller profile associated with the seller, a buyer profile associated with the buyer, or the one or more contract parameters. The risk scores can also be based upon various funder parameters associated with funders that utilize the financing platform and/or administrator parameters associated with the administrator of the financing platform. The risk scores can include, for example, the Crowdz SuRF Score (also referred to as the “Smart Score”), described in greater detail in U.S. Nonprovisional Application No. 17/469,510, filed September 8, 2021 and titled “METHOD, APPARATUS, AND COMPUTER READABLE MEDIUM FOR GENERATING A REAL-TIME RISK SCORE ASSOCIATED WITH FINANCING OF AN INVOICE BASED ON REAL-TIME TRANSACTION DATA,” the disclosure of which is hereby incorporated by reference in its entirety.

[0040] At step 102, generation of a unique cryptographic identifier corresponding to the transfer data structure is initiated on a distributed file system based at least in part on the transfer data structure, the second entity being registered as a current owner of the unique cryptographic identifier on the distributed file system, collection authority for the transfer data structure being linked to the current owner

[0041] In the invoice and receivables financing context, this step can include initiating a minting of a non-fungible token (“NFT”) (unique cryptographic identifier) corresponding to the receivable contract (transfer data structure) on a distributed ledger (distributed file system) and based at least in part on the receivable contract. A private key corresponding to the seller is used to sign the minting transaction and as a result of the minting, the seller is recorded as the owner of the NFT on the distributed ledger (second entity being registered as a current owner).

[0042] The NFT can be minted by the financing platform. Alternatively, the financing platform can coordinate the minting of the NFT by a third party platform. The financing platform can serve as custodian of a private key corresponding to the seller and can use the private key of the seller to sign a digital transaction on the distributed ledger associated with minting the NFT. Alternatively, the financing platform can request that the seller provide approval to access their private key or to enter private key details or information in order to sign the minting transaction. [0043] Non-fungible tokens are unique tokens that represent a good or asset, such as an item of digital content (e.g., an image or file). Non-fungible tokens are generated from an underlying digital content item and then recorded on a blockchain (a.k.a. the distributed ledger). The transaction on the blockchain will list an owner for the NFT and can include metadata about the digital content item, the creation of the NFT, and other information based upon or derived from the digital content item.

[0044] Receivable NFTs (a.k.a. NFTr) can be based on the ERC-721 standard and can be linked (e.g., via a unique NFT/token identifier) to a smart contract that encapsulates information pertaining to the receivable factoring lifecycle, e.g., financing, repayment, collection, and writeoff. The smart contract can also be stored on the blockchain and the NFT can optionally be embedded in, or otherwise be part of, the smart contract. Optionally, the smart contract can be omitted and computer-program instructions corresponding to the functions of the smart contract can be stored off-chain on the financing platform, which can interface with the seller computer systems, funder computer systems, and the blockchain, in order to coordinate the steps of the receivable factoring lifecycle.

[0045] The unique cryptographic identifier can be generated based at least in part on a digital file corresponding to the transfer data structure and at least one transfer parameter in the one or more transfer parameters.

[0046] In the invoice and receivables financing context, the NFT can be minted based at least in part on a digital file of the receivable contract, such as a jpeg, pdf, doc, or other file format.

[0047] The unique cryptographic identifier can be generated using the transfer data structure and one or more risk parameters corresponding to the transfer data structure, the one or more risk parameters being determined based at least in part on one or more entity parameters associated with one or more of the first entity, the second entity, or the network-client.

[0048] In the invoice and receivables financing context, the NFT can be minted based at least in part on at least one contract parameter of the one or more contract parameters and/or one or more risk scores (risk parameters) associated with the receivable contract, including the “SuRF Score” (a.k.a. the “Smart Score”). As discussed earlier, risk scores can be determined based on parameters associated with buyers (first entities), sellers (second entities), or networkclients (funders). In conjunction with the minting process, the financing platform can write the receivable contract to a smart contract on the distributed ledger that reflects the entire receivable factoring lifecycle. When minting the NFT, a seller can be identified by a key that corresponds to the seller and is used to sign a transaction corresponding the NFT being minted. When the key is used to sign the transaction, the NFT is created on the blockchain and lists the seller as the owner. The seller or financing platform (acting as custodian) can then access/transfer the NFT using the private key. As discussed earlier, the private key of the seller can be a key to which the seller provides access or which the seller provides when prompted by the platform.

Alternatively, the financing platform can store private keys corresponding to various sellers, each private key being accessible by the corresponding seller and the financing platform (as custodian).

[0049] As an alternative to the above scenario, the NFT can be minted using a private key corresponding to the financing platform, in which case the financing platform would be considered the original owner/creator. The NFT can then be automatically transferred to the seller corresponding to the receivable contract, with the transaction being recorded on the blockchain/distributed ledger.

[0050] Metadata corresponding to the transfer data structure can be stored in a private database separate from the distributed database, the metadata being linked to the unique cryptographic identifier.

[0051] In the invoice and receivables financing context, metadata associated with the receivable contract and the NFT can be stored on a decentralized file network separate from the distributed ledger, such as an Interplanetary File System (IPFS). As each NFT has a unique identifier, the metadata can be linked to a corresponding NFT via the unique identifier of the NFT. This metadata can include, but is not limited to, information about the buyer and the seller, the one or more contract parameters, the one or more risk scores, and a readable version of the receivable contract, e.g. a PDF. The NFT can store a limited amount of information associated with the receivable contract, such as, for example, an seller ID, a buyer ID, a date, a URL to the IPFS, an address of the NFT, and an identifier corresponding to the receivable contract. The NFT can also include one or more of the one or more contract parameters and one or more risk scores associated with the receivable contract. Private metadata relating to the receivable contract, the seller, the funder, and/or the buyer can be stored in a secure, non-public database. Generally, private data includes data that is not relevant for making an investment decision. Private data can be stored according to relevant domestic legal requirements for auditing, such as the requirements set out in the European Union’s General Data Protection Regulation.

[0052] Once the NFT is minted, the seller of the corresponding receivable is listed as the owner on the blockchain (i.e., it is linked with the electronic wallet of the seller). The NFT is then made available for purchase on the financing platform. The NFT can be available for purchase on primary and secondary marketplaces.

[0053] At step 103 a self-executing code corresponding to the transfer data structure is generated based at least in part on the one or more transfer parameters, the self-executing code corresponding to the unique cryptographic identifier and being stored on the distributed file system.

[0054] In the invoice and receivables financing context, this step can include generating a smart contract (self-executing code) corresponding to the receivable contract (transfer data structure) based at least in part on the one or more contract parameters (transfer parameters), the smart contract being linked to the NFT (unique cryptographic identifier) and stored on the distributed ledger (distributed file system). The smart contract functionality is described further in this specification.

[0055] At step 104, an exchange transfer corresponding to the transfer data structure is executed, the exchange transfer resulting in a network-client being registered as the current owner of the unique cryptographic identifier in exchange for a transfer from the network-client to the second entity. The self-executing code can be configured to register the network-client as the current owner in response to detecting the transfer from the network-client to the second entity. [0056] In the invoice and receivables financing context, this step can include executing a funding transaction (exchange transfer) corresponding to the receivable contract (transfer data structure). The funding transaction results in a first quantity of funds being transferred from a funder (network client) to the seller (second entity) and the transfer of ownership of the NFT (unique cryptographic identifier) from the seller to the funder. When the financing platform receives a request from the funder to purchase the NFT, the financing platform can provide instructions to the funder to transfer funds, e. , fiat money, stable coin, or cryptocurrency, to the seller. If the financing platform is given permission to access the funding sources of the funder, then the financing platform can initiate the transfer of funds from the funder to the seller. The seller can also receive instructions from the financing platform to transfer the NFT to the funder. The transaction can be recorded on the distributed ledger and signed with an electronic wallet private key corresponding to the seller, resulting in the NFT being transferred to the funder and being linked to the electronic wallet of the funder. The financing platform can update metadata data corresponding to the NFT to reflect that the NFT is still active and that the current owner is the funder.

[0057] Optionally, a funder can automate their funding transactions. A financing platform can receive an instruction to automate the transactions of the funder. The financing platform will then make investment decisions on behalf of the funder and based at least in part on a funding limit and risk profile provided by the funder on the financing platform. The financing platform can execute a funding transaction by selecting an NFT for purchase and automatically cause the funds to be transferred from the electronic wallet of the funder to the electronic wallet of the seller. Optionally, the financing platform can automatically select an NFT for purchase and provide instructions to the funder to transfer funds to the seller.

[0058] At step 105, one or more subsequent transfers from the second entity to the current owner of the unique cryptographic identifier on the distributed file system are detected, the one or more subsequent transfers matching a quantity transferred to the second entity in the exchange transfer. The current owner can be the network-client or a second network-client that has received the unique cryptographic identifier from the network-client. [0059] The self-executing code can be configured to identify the transfer data structure for use in the exchange transfer based at least in part on one or more network-client parameters associated with the network-client and route the one or more subsequent transfers from the second entity to the current owner of the unique cryptographic identifier.

[0060] In the invoice and receivables financing context, this step can include detecting one or more repayments (one or more subsequent transfers) from the seller (second entity) to the current owner (current owner of the unique cryptographic identifier) corresponding to an amount due on the funding transaction (matching a quantity transferred to the second entity in the exchange transfer). The repayment is directed to a current owner of the NFT indicated on the distributed ledger. A current owner can be, for example, the funder, or another party who has received the NFT from the funder. If the funder has transferred the NFT to another party, e.g. a purchaser, then the transaction will be recorded on the distributed ledger and metadata corresponding to the NFT will be updated on the financing platform.

[0061] Detecting a repayment can include receiving a notification that repayment was received by the current owner of the NFT. The notification can be provided by, for example, a payment partner or the current owner of the NFT. The notification can be received in the form of a webhook.

[0062] When a receivable is not paid in full or when repayment is late, the financing platform can provide recovery mechanisms to facilitate the repayment. The financing platform can, for example, send one or more notifications to the seller to remind the seller of the failure to make repayment, automatically transfer collateral posted by the seller to the funder, or cause to be commenced a formal collections process. The financing platform can detect that the repayment is past due by, for example, polling the NFT metadata or tracking the due date of the repayment internally.

[0063] At step 106, the unique cryptographic identifier is designated as expired based at least in part on detection of the one or more subsequent transfers [0064] In the invoice and receivables financing context, this step can include designating the NFT (unique cryptographic identifier) as expired based at least in part on detection of the one or more repayments (detection of the one or more subsequent transfers). Metadata on the financing platform and corresponding to the NFT can be updated to designate the NFT as expired. Optionally, the NFT can be designated as expired by being transferred to an “expired” wallet of the financing platform (i.e., an electronic wallet linked only to NFTs that are expired). Optionally, the NFT can be designated as expired by being assigned to a null address (i.e., the NFT is “burned”). Optionally, the NFT can be designated as expired by being transferred back to the seller in response to the current owner receiving the repayment.

[0065] Fig. 2 illustrates a flowchart for detecting one or more subsequent transfers from the second entity to the current owner of the unique cryptographic identifier on the distributed file system and designating the unique cryptographic identifier as expired according to an exemplary embodiment.

[0066] In the invoice and receivables financing context, this flowchart can correspond to detecting one or more repayments (one or more subsequent transfers) and designating the NFT (unique cryptographic identifier) as expired.

[0067] At step 201, one or more subsequent transfers from the second entity to the current owner of the unique cryptographic identifier on the distributed file system are detected.

[0068] In the invoice and receivables financing context, this step can correspond to receiving a notification that the funder has received the repayment from the seller. The notification can be provided by, for example, a payment partner or the current owner. The notification can be received in the form of a webhook.

[0069] At step 202, metadata corresponding to the unique cryptographic identifier stored in the private database is updated.

[0070] In the invoice and receivables financing context, this step can include updating metadata corresponding to the NFT to indicate repayment. The updated metadata can designate the NFT as expired. [0071] Optionally, at step 203a, an expired entity can be registered as a current owner of the unique cryptographic identifier.

[0072] In the invoice and receivables financing context, this step can include transmitting instructions to the current owner of the NFT instructing the current owner to transfer the NFT to an expired wallet corresponding to the financing platform. The financing platform can update medadata corresponding to the NFT in response to detecting the NFT in the expired wallet on the financing platform. The transfer of the NFT from the electronic wallet of the current owner to the expired wallet can be recorded on the distributed ledger.

[0073] Optionally, at step 203b, a NULL value can be registered as current owner of the unique cryptographic identifier.

[0074] In the invoice and receivables financing context, this step can include transmitting instructions to the current owner of the NFT instructing the current owner to assign the NFT to a null address. The financing platform can update metadata corresponding to the NFT in response to a detection that the NFT has been assigned to the null address. The assignment of the NFT to the null address is recorded on the distributed ledger.

[0075] Fig. 3 illustrates a system chart of the system for facilitating a receivable funding transaction with an NFT corresponding to a receivable contract according to an exemplary embodiment. The computing device of the seller 302 can interface with the financing platform 301, allowing the seller to provide a receivable contract to the financing platform 301. The system can include a financing platform 301, a computing device of a seller 302, a computing device of a funder 303, a distributed ledger 304, and an IPFS 305. The financing platform 301 can interface with the electronic wallet of the seller, the distributed ledger 304, and the IPFS 305. Optionally, the financing platform 301 can interface with the electronic wallet of the funder. The computing device of the funder 303 can interface with the financing platform 301, allowing the funder to select an NFTr for purchase.

[0076] The financing platform can store metadata corresponding to, for example, the NFT, the seller, the funder, and the purchaser. A financing platform can have NFT minting software capable of minting an NFT corresponding to the receivable contract. A financing platform can have a smart contract generation software configured to create smart contracts corresponding to the NFT.

[0077] Blockchain/distributed ledger 304 can be on an Ethereum sidechain. While illustrated in Fig. 3 as a single blockchain, it should be appreciated that distributed ledger 304 can be more than one distributed ledgers on more than one blockchain.

[0078] A blockchain environment corresponding to blockchain/distributed ledger 304 according to an exemplary embodiment is illustrated in Fig. 3. Cross-chain communication can occur between blockchain/distributed ledger 304 and other blockchains that interface with the financing platform. On the blockchain, invoices can be tokenized (a.k.a. minted) as NFTs. The blockchain supports both primary markets and secondary markets for the receivable NFTs on the financing platform. The transfer of fiat or stable coins in exchange for the NFT can occur outside of the blockchain environment.

[0079] Interplanetary File System (IPFS) 305 or any other distributed, centralized, or other file storage system can store public metadata corresponding to the receivable contract. Because the metadata will exist off-chain, Merkle Proofs can be used as a certificate to ensure the authenticity of the metadata.

[0080] Fig. 4A illustrates a system chart of a system for facilitating a receivable funding transaction with an NFT corresponding to a receivable contract showing the seller as current owner of the NFT after minting. As shown in the figure, the minted NFT lists the seller as the owner on the distributed ledger and is consequently stored in, and accessible to, the electronic wallet of the seller. The private metadata corresponding to the NFT on the financing platform can indicate “Awaiting Funding” or something similar, to indicate that the NFT has been minted but not yet funded.

[0081] Fig. 4B illustrates a system chart of a system for facilitating a receivable funding transaction with an NFT corresponding to a receivable contract showing the transfer of the NFT from the seller to the funder in exchange for payment from the funder to the seller according to an exemplary embodiment. A transaction can be recorded on the distributed ledger indicating a transfer of ownership of the NFT from the seller to the funder. The private metadata corresponding to the NFT can be updated on the financing platform to, for example, identify the NFT as active and show the current owner as the funder.

[0082] Fig. 4C illustrates a system chart of a system for facilitating a receivable funding transaction with an NFT corresponding to a receivable contract showing the designation of the NFT as expired in response to detecting a repayment from the seller to the purchaser corresponding to the amount due on the transaction according to an exemplary embodiment. A transaction can be recorded on the distributed ledger indicating a transfer of ownership of the NFT from the funder to an expired electronic wallet. The metadata corresponding to the NFT can be updated on the financing platform to, for example, identify the NFT as expired.

[0083] Fig. 5A illustrates a system chart of a system for facilitating a receivable funding transaction with an NFT corresponding to a receivable contract showing a funder transferring ownership of the NFT to a purchaser, the transfer being recorded on the distributed ledger, according to an exemplary embodiment. A transaction can be recorded on the distributed ledger indicating a transfer of ownership of the NFT from the electronic wallet of the funder to an electronic wallet of the purchaser. Private metadata corresponding to the NFT can be updated on the financing platform to, for example, identify the NFT as active and designate the current owner as the purchaser in response to the financing platform receiving a notification that the NFT has been transferred to the purchaser, the financing platform polling the blockchain/distributed ledger to determine that the NFT has been transferred, and/or functionality encoded in the smart contract to notify the financing platform of a transfer of the NFT.

[0084] While Fig. 5A illustrates an exemplary embodiment in which ownership of the NFT is transferred from the funder to a third party purchaser, it should be appreciated that subsequently, the NFT can be transferred to second purchaser, a third purchaser, etc .

[0085] Fig. 5B illustrates a system chart of a system for facilitating a receivable funding transaction with an NFT corresponding to a receivable contract showing the designation of the NFT as expired in response to detecting a repayment from the seller to the purchaser corresponding to the amount due on the transaction according to an exemplary embodiment. A transaction can be recorded on the distributed ledger indicating a transfer of ownership of the NFT from the electronic wallet of the purchaser to an expired electronic wallet. The metadata corresponding to the NFT can be updated on the financing platform to, for example, identify the NFT as expired. Financing platform 301 can detect the repayment by receiving, for example, a notification from the purchaser that repayment has been received, or by receiving a notification from a payment partner.

[0086] Fig. 6 illustrates a diagram of the funding of a receivables funding process using a method and system for facilitating a receivables funding transaction according to an exemplary embodiment. At 1, the seller issues an invoice to an obligor and uploads the invoice to the distributor (a.k.a. the financing platform). At 2, the distributor receives the invoice, assessing the validity of the invoice and assigning at least one risk score. At 3, after the invoice is validated, the invoice is minted as an NFT on a blockchain (a.k.a. the distributed ledger) and made available for purchase on the financing platform by the distributor. At 4, a purchaser purchases the NFT on the financing platform. The purchaser transfers funds to the seller, the funds being in the form of fiat money or stable coins. Ownership of the NFT is transferred from the seller to the purchaser, the transfer being recorded in a transaction on the blockchain.

[0087] Fig. 7 illustrates a diagram of repayment of the receivables funding process using a method and system for facilitating a receivables funding transaction according to an exemplary embodiment. At 1, the obligor pays the seller. At 2, the seller repays the purchaser by transferring funds in the form of fiat or stable coins to the purchaser. The seller can transfer to the purchaser an amount that is at least equal to the amount of funds received by the seller from the purchaser. Optionally, an electronic wallet of the seller can be updated to reflect transfer of funds to the purchaser. At 3, the purchaser transfers the NFT back to the seller and the transfer is recorded on the blockchain.

[0088] Fig. 8 illustrates a system diagram of an onboarding process according to an exemplary embodiment. A seller can upload a receivable to the distributor (a.k.a. financing platform) after the seller is approved by the distributor. A seller can be approved, for example, based on completing an anti-money laundering process. The distributor applies an invoice validation tool and a risk assessment tool to the receivable to validate the receivable. Once validated, the receivable is minted as an NFT. The minting process writes the invoice to a smart contract that reflects the entire receivable factoring lifecycle (i.e. funding, repayment, collection, and write-off). Metadata associated with the NFT is stored off-chain in a decentralized file system, such as the Inter Planetary File System (IPFS). Once minted, the NFT is stored on the blockchain in the electronic wallet of the seller and can be available for purchase on the financing platform.

[0089] A purchaser will undergo investor checks, such as a Know Your Customer (KYC) check. Once approved, the purchaser can connect and fund their electronic wallet and can select an NFT for purchase on the financing platform. Purchasers will have the option to personalize and automate their investment by selecting a funding limit and risk profile. This information is captured in a smart contract that links to a private address of the purchaser and acts as the governing mechanism for making investment decisions on the purchaser’s behalf.

[0090] Fig. 9 illustrates a system diagram of a funding and repayment process according to an exemplary embodiment.

[0091] Fig. 10 illustrates a system diagram of a funding process according to an exemplary embodiment. The seller creates an invoice and uploads the invoice with the distributor on the financing platform. The financing platform receives the invoice and assess it for validity. If the invoice is validated, then an NFT is minted on the blockchain and linked to a seller address corresponding to the electronic wallet of the seller. By a smart contract, the NFT can be selected and pulled from the electronic wallet of the seller and transferred to a different address corresponding to an electronic wallet. The seller can receive payment in the form of stable coins transferred to the electronic wallet of the seller.

[0092] To make repayment, a seller can cause to be transferred funds from the electronic wallet of the seller to the electronic wallet of the current owner of the NFT. After receiving repayment, the current owner of the NFT can be instructed to transfer the NFT to an expired wallet or to a null address. [0093] Fig. 11 illustrates a system diagram of the architecture of receivables data from the receivable contract according to an exemplary embodiment. To protect privacy and commercial confidentiality of the parties related to a receivable NFT, such as the seller, the funder, and subsequent purchasers of the NFT, the NFT will store minimal information on the blockchain, such as a creator ID (a.k.a. a seller ID), a debtor ID (a.k.a. an obligor ID), an invoice date, and a URL to the IPFS. Metadata corresponding to the receivable will be stored on the IPFS and can include contract parameters corresponding to the invoice. Private information relating to the seller and the obligor can be saved in a private database.

[0094] Fig. 12 illustrates a system diagram of a financing platform implementing one or more recovery mechanisms when the receivable is not paid in full or when repayment is late. If the repayment from the seller to the current owner of the NFT is late, then the financing platform can send one or more reminders to the seller to make the repayment. The seller’s failure to make a timely payment can impact the risk score associated with the seller (and optionally, a risk score associated with a buyer if the seller is waiting on payment from the buyer). The financing platform can provide a reminder to the seller. The financing platform can initiate recovery of the repayment with a debt collection partner located off the blockchain. If the seller defaults, the financing platform can trigger an insurance claim. The financing platform can trigger an insurance claim if one of the one or more contract parameters of the receivable contract corresponds to an insurance on the receivable.

[0095] Fig. 13 illustrates the components of the specialized computing environment 1300 configured to perform the specialized processes described herein. Specialized computing environment 1300 can include the controller and includes a computing device that includes a memory 1301 that is a non-transitory computer-readable medium and can be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two.

[0096] As shown in Fig. 13, memory 1301 can include transfer data structure database 1301A, identifier generation software 1301B, metadata database 1301C, network-client communication software 1301D, entity communication software 1301E, transfer tracking software 1301F, self-executing code generation software 1301G, transfer data structure scoring software 1301H, as well as any other components required to perform the methods described herein. Each of the software components in memory 1301 store specialized instructions and data structures configured to perform the corresponding functionality and techniques described herein.

[0097] All of the software stored within memory 1301 can be stored as a computer- readable instructions, that when executed by one or more processors 1302, cause the processors to perform the functionality described with respect to Figs. 1-12.

[0098] Processor(s) 1302 execute computer-executable instructions and can be a real or virtual processors. In a multi-processing system, multiple processors or multicore processors can be used to execute computer-executable instructions to increase processing power and/or to execute certain software in parallel.

[0099] Specialized computing environment 1300 additionally includes a communication interface 1303, such as a network interface, which is used to communicate with devices, applications, or processes on a computer network or computing system, collect data from devices on a network, and implement encryption/ decry ption actions on network communications within the computer network or on data stored in databases of the computer network. The communication interface conveys information such as computer-executable instructions, audio or video information, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media include wired or wireless techniques implemented with an electrical, optical, RF, infrared, acoustic, or other carrier.

[0100] Specialized computing environment 1 00 further includes input and output interfaces 1304 that allow users (such as system administrators) to provide input to the system to set parameters, to edit data stored in memory 1301, or to perform other administrative functions.

[0101] An interconnection mechanism (shown as a solid line in Fig. 13), such as a bus, controller, or network interconnects the components of the specialized computing environment 1300. [0102] Input and output interfaces 1304 can be coupled to input and output devices. For example, Universal Serial Bus (USB) ports can allow for the connection of a keyboard, mouse, pen, trackball, touch screen, or game controller, a voice input device, a scanning device, a digital camera, remote control, or another device that provides input to the specialized computing environment 1300.

[0103] Specialized computing environment 1300 can additionally utilize a removable or non-removable storage, such as magnetic disks, magnetic tapes or cassettes, CD-ROMs, CD- RWs, DVDs, USB drives, or any other medium which can be used to store information and which can be accessed within the specialized computing environment 1300.

Claims

CLAIMS We claim:

1. A method executed by one or more computing devices of a controller of a distributed transfer network for detecting expiration of a unique cryptographic identifier on the distributed transfer network, the method comprising: receiving, by the controller, a transfer data structure identifying a first entity having requirements associated with a transfer to a second entity, the second entity having collection authority to receive the transfer from the first entity, and one or more transfer parameters governing the transfer; initiating, by the controller, generation of a unique cryptographic identifier corresponding to the transfer data structure on a distributed file system based at least in part on the transfer data structure, the second entity being registered as a current owner of the unique cryptographic identifier on the distributed file system, wherein collection authority for the transfer data structure is linked to the current owner; generating, by the controller, a self-executing code corresponding to the transfer data structure based at least in part on the one or more transfer parameters, the self-executing code corresponding to the unique cryptographic identifier and being stored on the distributed file system; executing, by the controller, an exchange transfer corresponding to the transfer data structure, the exchange transfer resulting in a network-client being registered as the current owner of the unique cryptographic identifier in exchange for a transfer from the network-client to the second entity, wherein the self-executing code is configured to register the network-client as the current owner in response to detecting the transfer from the network-client to the second entity; detecting, by the controller, one or more subsequent transfers from the second entity to the current owner of the unique cryptographic identifier on the distributed file system, the one or more subsequent transfers matching a quantity transferred to the second entity in the exchange transfer; and designating, by the controller, the unique cryptographic identifier as expired based at least in part on detection of the one or more subsequent transfers.

2. The method of claim 1, further comprising: storing, by the controller, metadata corresponding to the transfer data structure in a private database separate from the distributed database, the metadata being linked to the unique cryptographic identifier.

3. The method of claim 2, wherein designating the unique cryptographic identifier as expired further comprises one or more of: updating metadata corresponding to the unique cryptographic identifier stored in the private database; registered a NULL value as current owner of the unique cryptographic identifier; or registering an expired entity as current owner of the unique cryptographic identifier.

4. The method of claim 1, wherein the current owner comprises one or more of: the network-client or a second network-client that has received the unique cryptographic identifier from the network-client.

5. The method of claim 1, wherein the unique cryptographic identifier is generated using the transfer data structure and one or more risk parameters corresponding to the transfer data structure, the one or more risk parameters being determined based at least in part on one or more entity parameters associated with one or more of the first entity, the second entity, or the network-client.

6. The method of claim 1, wherein the unique cryptographic identifier is generated based at least in part on a digital file corresponding to the transfer data structure and at least one transfer parameter in the one or more transfer parameters.

7. The method of claim 1, wherein the self-executing code is further configured to: identify the transfer data structure for use in the exchange transfer based at least in part on one or more network-client parameters associated with the network-client; and route the one or more subsequent transfers from the second entity to the current owner of the unique cryptographic identifier.

8. A controller of a distributed transfer network for detecting expiration of a unique cryptographic identifier on the distributed transfer network, the controller comprising: one or more processors; and one or more memories operatively coupled to at least one of the one or more processors and having instructions stored thereon that, when executed by at least one of the one or more processors, cause at least one of the one or more processors to: receive a transfer data structure identifying a first entity having requirements associated with a transfer to a second entity, the second entity having collection authority to receive the transfer from the first entity, and one or more transfer parameters governing the transfer; initiate generation of a unique cryptographic identifier corresponding to the transfer data structure on a distributed file system based at least in part on the transfer data structure, the second entity being registered as a current owner of the unique cryptographic identifier on the distributed file system, wherein collection authority for the transfer data structure is linked to the current owner; generate a self-executing code corresponding to the transfer data structure based at least in part on the one or more transfer parameters, the self-executing code corresponding to the unique cryptographic identifier and being stored on the distributed file system; execute an exchange transfer corresponding to the transfer data structure, the exchange transfer resulting in a network-client being registered as the current owner of the unique cryptographic identifier in exchange for a transfer from the network-client to the second entity, wherein the self-executing code is configured to register the network-client as the current owner in response to detecting the transfer from the network-client to the second entity; detect one or more subsequent transfers from the second entity to the current owner of the unique cryptographic identifier on the distributed file system, the one or more subsequent transfers matching a quantity transferred to the second entity in the exchange transfer; and designate the unique cryptographic identifier as expired based at least in part on detection of the one or more subsequent transfers.

9. The controller of claim 8, wherein at least one of the one or more memories has further instructions stored thereon that, when executed by at least one of the one or more processors, cause at least one of the one or more processors to: store metadata corresponding to the transfer data structure in a private database separate from the distributed database, the metadata being linked to the unique cryptographic identifier.

10. The controller of claim 9, wherein the instructions that, when executed by at least one of the one or more processors, cause at least one of the one or more processors to designate the unique cryptographic identifier as expired further cause at least one of the one or more processors to perform one or more of updating metadata corresponding to the unique cryptographic identifier stored in the private database; registered a NULL value as current owner of the unique cryptographic identifier; or registering an expired entity as current owner of the unique cryptographic identifier.

11. The controller of claim 8, wherein the current owner comprises one or more of: the network-client or a second network-client that has received the unique cryptographic identifier from the network-client.

12. The controller of claim 8, wherein the unique cryptographic identifier is generated using the transfer data structure and one or more risk parameters corresponding to the transfer data structure, the one or more risk parameters being determined based at least in part on one or more entity parameters associated with one or more of the first entity, the second entity, or the network-client.

13. The controller of claim 8, wherein the unique cryptographic identifier is generated based at least in part on a digital file corresponding to the transfer data structure and at least one transfer parameter in the one or more transfer parameters.

15

14. The controller of claim 8, wherein the self-executing code is further configured to: identify the transfer data structure for use in the exchange transfer based at least in part on one or more network-client parameters associated with the network-client; and route the one or more subsequent transfers from the second entity to the current owner of the unique cryptographic identifier.

15. At least one non-transitory computer-readable medium storing computer-readable instructions for detecting expiration of a unique cryptographic identifier on a distributed transfer network that, when executed by one or more computing devices of a controller of the distributed transfer network, cause the controller to: receive a transfer data structure identifying a first entity having requirements associated with a transfer to a second entity, the second entity having collection authority to receive the transfer from the first entity, and one or more transfer parameters governing the transfer; initiate generation of a unique cryptographic identifier corresponding to the transfer data structure on a distributed file system based at least in part on the transfer data structure, the second entity being registered as a current owner of the unique cryptographic identifier on the distributed file system, wherein collection authority for the transfer data structure is linked to the current owner; generate a self-executing code corresponding to the transfer data structure based at least in part on the one or more transfer parameters, the self-executing code corresponding to the unique cryptographic identifier and being stored on the distributed file system; execute an exchange transfer corresponding to the transfer data structure, the exchange transfer resulting in a network-client being registered as the current owner of the unique cryptographic identifier in exchange for a transfer from the network-client to the second entity, wherein the self-executing code is configured to register the network-client as the current owner in response to detecting the transfer from the network-client to the second entity; detect one or more subsequent transfers from the second entity to the current owner of the unique cryptographic identifier on the distributed file system, the one or more subsequent transfers matching a quantity transferred to the second entity in the exchange transfer; and designate the unique cryptographic identifier as expired based at least in part on detection of the one or more subsequent transfers.

16. The at least one non-transitory computer-readable medium of claim 15, further storing computer-readable instructions that, when executed by the controller, cause the controller to: store metadata corresponding to the transfer data structure in a private database separate from the distributed database, the metadata being linked to the unique cryptographic identifier.

17. The at least one non-transitory computer-readable medium of claim 15, wherein the instructions that, when executed by the controller, cause the controller to designate the unique cryptographic identifier as expired further cause the controller to perform one or more of: updating metadata corresponding to the unique cryptographic identifier stored in the private database; registered a NULL value as current owner of the unique cryptographic identifier; or registering an expired entity as current owner of the unique cryptographic identifier.

18. The at least one non-transitory computer-readable medium of claim 15, wherein the current owner comprises one or more of: the network-client or a second network-client that has received the unique cryptographic identifier from the network-client.

19. The at least one non-transitory computer-readable medium of claim 15, wherein the unique cryptographic identifier is generated using the transfer data structure and one or more risk parameters corresponding to the transfer data structure, the one or more risk parameters being determined based at least in part on one or more entity parameters associated with one or more of the first entity, the second entity, or the network-client.

20. The at least one non-transitory computer-readable medium of claim 15, wherein the unique cryptographic identifier is generated based at least in part on a digital file corresponding to the transfer data structure and at least one transfer parameter in the one or more transfer parameters.

21. The at least one non-transitory computer-readable medium of claim 15, wherein the self-executing code is further configured to: identify the transfer data structure for use in the exchange transfer based at least in part on one or more network-client parameters associated with the network-client; and route the one or more subsequent transfers from the second entity to the current owner of the unique cryptographic identifier.