WO2023201360A2

WO2023201360A2 - Method, controller, and computer-readable medium for replacement of a cancelled repeating transfer data structure on a distributed transfer network

Info

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

Abstract

A method, controller, and computer-readable medium for replacement of a cancelled repeating transfer data structure on the distributed transfer network, including receiving a plurality of transfer data structures corresponding to a repeating transfer data structure, initiating generation of a plurality of unique cryptographic identifiers corresponding to the plurality of transfer data structures on a distributed file system based at least in part on the repeating transfer data structure, generating a self-executing code corresponding to the repeating transfer data structure based at least in part on the one or more transfer parameters, executing an exchange transfer corresponding to the repeating transfer data structure, detecting cancellation of the repeating transfer data structure, and replacing one or more unique cryptographic identifiers in the plurality of unique cryptographic identifiers that are not designated as expired with one or more substitute unique cryptographic identifiers.

Description

METHOD, CONTROLLER, AND COMPUTER-READABLE MEDIUM FOR REPLACEMENT OF A CANCELLED REPEATING TRANSFER DATA STRUCTURE 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 repeating 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. There is also a lack of standardization of transfers, meaning that obligations and requirements stemming from transfers are not transferrable to other parties. Additionally, no technological platform or infrastructure exists to facilitate bundling of groups of repeating transfers. Even if such a bundling were possible, the failure or cancellation of any one repeating transfer in any group of repeating transfers would cause the entire group to fail.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Fig. 1 illustrates a flowchart for replacement of a cancelled repeating transfer data structure according to an exemplary embodiment.

[0004] Fig. 2 illustrates a flowchart for detecting subsequent transfers and designating the unique cryptographic identifier as expired according to an exemplary embodiment.

[0005] Fig. 3 illustrates a flowchart for generation of substitute unique cryptographic identifiers according to an exemplary embodiment. [0006] Fig. 4 illustrates a flowchart for replacement of unexpired unique cryptographic identifiers with substitute unique cryptographic identifiers according to an exemplary embodiment.

[0007] Fig. 5 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.

[0008] Fig. 6A 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.

[0009] Fig. 6B 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.

[0010] Fig. 6C 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. 7A 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.

[0012] Fig. 7B 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. [0013] Figs. 8A-8D illustrate an example of tokenized recurring revenue receivables financing according to an exemplary embodiment.

[0014] Fig. 9 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.

[0015] Fig. 10 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.

[0016] Fig. 11 illustrates a system diagram of an onboarding process according to an exemplary embodiment.

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

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

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

[0020] Fig. 15 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.

[0021] Fig. 16 illustrates the components of the specialized computing environment configured to perform the specialized method for replacement of a cancelled repeating transfer data structure described herein.

DETAILED DESCRIPTION

[0022] 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.

[0023] Applicant has discovered a method, controller, and computer-readable medium for replacement of a cancelled repeating transfer data structure on a distributed transfer network.

[0024] The present system and related techniques can be applied to a variety of contexts. For example, the present system can be utilized in a recurring invoice or recurring receivable transfer context, in which a group of recurring invoices or recurring receivables are 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 recurring receivables financing platform with non-fungible tokens (NFT) corresponding to the recurring receivables contracts (referred to herein as “recurring revenue receivables,” “recurring receivable contracts,” “recurring receivables,” and “recurring invoices”).

[0025] 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.

[0026] Additionally, as used herein, the term receivable includes invoices and the terms recurring receivables, recurring revenue receivables (RRR), recurring receivables contracts, and recurring revenue receivables contracts refer to periodic (e.g., monthly) bills due on a services or product contracts.

[0027] 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. [0028] 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.

[0029] Another difficulty in implementing invoice-based financing relates specifically to recurring receivables contracts. Individual businesses/sellers frequently receive revenue over a period of time (e.g., weekly, bi-weekly, monthly, bi-monthly, quarterly, etc.). Many of these businesses and sellers receive recurring revenue in small dollar amounts, making the invoices and recurring receivables unsuitable for invoice financing from funders who typically seeking returns on larger funding amounts.

[0030] Additionally, any attempt to bundle or group recurring receivables for financing would also raise significant technical challenges. No technological platform or infrastructure exists to facilitate such bundling, pricing, and financing of groups of recurring receivables contracts. Additionally, even if such a bundling were possible, the failure or cancellation of any one contract in any group of bundled recurring receivables contracts would cause the entire group of bundled contracts to fall below expected returns or otherwise fail.

[0031] 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 for recurring revenue receivable contracts (referred to herein as “RRR contracts”). 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.

[0032] 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.

[0033] When applied in the recurring receivables context, the disclosed method, controller, and computer-readable medium facilitates a funding transaction on a receivable financing platform with a non-fungible token (NFT) corresponding to a recurring revenue receivable contract that includes a plurality of receivables (referred to herein as “receivable contracts,” “receivables,” and “invoices”).

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

[0035] -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.

[0036] -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.

[0037] -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).

[0038] -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.

[0039] -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. [0040] - Automatic replacement of any outstanding receivables and corresponding NFTs in a RRR contract in the event of cancellation or default of obligations corresponding to one or more receivables in the RRR contract.

[0041] - Automatic minting of new NFTs to substitute for outstanding obligations/receivables in the event of cancellation or default on a RRR contract.

[0042] Fig. 1 illustrates a flowchart for replacement of a cancelled repeating transfer data structure 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.

[0043] In the invoice and receivables financing context, this flowchart can correspond to facilitating a recurring revenue receivable funding transaction on a receivable financing platform with a plurality of NFTs corresponding to a recurring revenue receivable contract according to an exemplary embodiment. 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 (e.g, via web portal).

[0044] A recurring revenue receivable contract (a.k.a. a RRR or a RRR contract) represents the recurring payments owed to a business, e.g., a seller, for products or services provided to a buyer (a.k.a. an obligor). Commonly, payment terms and information about the goods or services provided are captured in a series of seller-issued invoices. The RRR contract includes a plurality of receivables, each of which can have associated amounts, condition, terms, etc. For example, the RRR contract can include 12 invoices (i.e., receivables) corresponding to each month indicating an amount due to the seller from the buyer each month (e.g., for service s/products provided by the seller to the buyer).

[0045] At step 101, a plurality of transfer data structures corresponding to a repeating transfer data structure are received, the repeating transfer data structure identifying a first entity having requirements associated with a plurality of transfers to a second entity, the second entity having collection authority to receive the plurality of transfers from the first entity, and one or more transfer parameters governing the plurality of transfers.

[0046] In the invoice and receivables financing context, this step can include a plurality of receivables (plurality of transfer data structures) corresponding to a recurring revenue receivable contract (repeating transfer data structure) being received by the financing platform. The recurring revenue 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, a term of the contract, a billing period, etc.

[0047] Receiving a plurality of receivables corresponding to a recurring revenue receivable contract can include assessing the validity of the recurring revenue receivable contract and the constituent receivables. The RRR 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 RRR contract or the individual receivables, 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.

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

[0049] In the invoice and receivables financing context, this step can include minting of a plurality of non-fungible tokens (NFTs) (plurality of unique cryptographic identifiers) corresponding to the plurality of receivables (plurality of transfer data structures) on a distributed ledger (distributed file system) and based at least in part on the recurring revenue receivable contract (repeating transfer data structure) being initiated. A private key corresponding to the seller is used to sign the minting transactions and as a result of the minting, the seller is recorded as the owner of the plurality of NFTs on the distributed ledger (collection authority for the repeating transfer data structure is linked to the current owner).

[0050] The NFTs can be minted by the financing platform. Alternatively, the financing platform can coordinate the minting of the NFTs 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 digital transactions on the distributed ledger associated with minting the NFTs. 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 transactions.

[0051] 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 each 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.

[0052] 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 NFTs 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.

[0053] The NFTs can be minted based at least in part on digital files of the receivable contracts or the RRR contract, such as a jpeg, pdf, doc, or other file format. The NFTs can also 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 associated with the RRR contract or the constituent receivables, including the “SuRF Score” (a.k.a. the “Smart Score”). In conjunction with the minting process, the financing platform can write the RRR contract or the constitutuent receivables to a smart contract on the distributed ledger that reflects the entire receivable factoring lifecycle. When minting the NFTs, a seller can be identified by a key that corresponds to the seller and is used to sign a transaction corresponding to each NFT being minted. When the key is used to sign the transaction, the NFTs are created on the blockchain and list 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).

[0054] As an alternative to the above scenario, the NFTs 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 NFTs can then be automatically transferred to the seller corresponding to the RRR contract, with the transactions being recorded on the blockchain/distributed ledger.

[0055] Metadata corresponding to the repeating transfer data structure can be stored in a private database separate from the distributed database, the metadata being linked to the plurality of unique cryptographic identifiers. [0056] In the invoice and receivables financing context, metadata associated with the RRR contract and the NFTs can further 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 corresponding NFTs 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 RRR contract, e.g. a PDF. The NFTs can store a limited amount of information associated with each receivable and/or the RRR contract, such as, for example, an seller ID, a buyer ID, a date, a URL to the IPFS, an address of the NFTs, and an identifier corresponding to the receivable. The NFTs can also include one or more of the one or more contract parameters and one or more risk scores associated with the RRR contract or constituent receivables. Private metadata relating to the receivable contract, the seller, the funder, and/or the buyer can be stored in a secure, nonpublic 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.

[0057] Once the NFTs are minted, the seller of the corresponding RRR contract is listed as the owner on the blockchain (i.e., the NFTs are linked with the electronic wallet of the seller). The NFTs are then made available for purchase on the financing platform. The NFTs can be available for purchase on primary and secondary marketplaces. The NFTs corresponding to an RRR contract can be transferred/purchased in a single batch or can be individually transferrable. Optionally, an initial funder can take possession of a batch of NFTs corresponding to a RRR contract and then resell one or more NFTs in the batch subsequent to the funding transaction.

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

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

[0060] At step 104, an exchange transfer corresponding to the repeating transfer data structure is executed, the exchange transfer resulting in a network-client being registered as the current owner of the plurality of unique cryptographic identifiers in exchange for a transfer from the network-client to the second entity. Each unique cryptographic identifier in the plurality of unique cryptographic identifiers corresponds to a reverse transfer in a plurality of reverse transfers associated with the exchange transfer. The self-executing code can be configured to designate as expired each unique cryptographic identifier for which a reverse transfer is detected. The self-executing code can further be configured to route each reverse transfer from the second entity to a current owner of each unique cryptographic identifiers corresponding to that reverse transfer.

[0061] In the invoice and receivables financing context, this step can include a funding transaction (exchange transfer) corresponding to the RRR contract (repeating transfer data structure) being executed. The funding transaction results in a first quantity of funds being transferred from a funder (network-client) to the seller (second entity) and ownership of the plurality of NFTs (plurality of unique cryptographic identifiers) being transferred from the seller to the funder.

[0062] When the financing platform receives a request from the funder to purchase the NFTs, the financing platform can provide instructions to the funder to transfer funds, e.g., 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 NFTs to the funder. Alternatively, the financing platform can coordinate the transfer using the private key of the seller (as custodian). The transactions can be recorded on the distributed ledger and signed with an electronic wallet private key corresponding to the seller, resulting in the NFTs 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

NFTs to reflect that the NFTs are active and that the current owner is the funder.

[0063] 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 NFTs 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 NFTs for purchase and provide instructions to the funder to transfer funds to the seller.

[0064] Each NFT in the plurality of NFTs corresponds to a repayment in a plurality of repayments due on the funding transaction and corresponds to a receivable in the plurality of receivables in the RRR contract. As repayments corresponding to receivables are received from the seller, the financing platform is configured to designate each NFT for which a corresponding repayment is detected as expired.

[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. In the invoice and receivables financing context, this flowchart can correspond to detecting repayments and designating NFTs as expired.

[0066] At step 201 a reverse transfer from the second entity corresponding to a reverse transfer in the plurality of reverse transfers associated with the exchange transfer is detected.

The reverse can be directed to a current owner of a unique cryptographic identifier corresponding to the reverse transfer.

[0067] In the invoice and receivables financing context, a repayment from the seller corresponding to a repayment in the plurality of repayments due on the funding transaction is detected. The repayment is directed to a current owner of an NFT corresponding to the repayment, as indicated on the distributed ledger and/or the private metadata. 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.

[0068] 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.

[0069] 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.

[0070] At step 202, the unique cryptographic identifier is designated as expired based at least in part on detection of the reverse transfer. In the invoice and receivables financing context, the NFT corresponding to the repayment is designated as expired based at least in part on detection of the repayment.

[0071] At sub-step 202A, metadata corresponding to the unique cryptographic identifier stored in the private database is updated. 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.

[0072] Optionally, at sub-step 202B, a NULL value can be registered as current owner of the unique cryptographic identifier. 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, rendering the NFT subsequently unusable/un-transferrable. Optionally and/or alternatively, the NFT can be designated as expired by being transferred back to the seller in response to the current owner of the NFT receiving the repayment.

[0073] Optionally, at sub-step 202C, instructions can be transmitted to the current owner to transfer the NFT to an expired wallet corresponding to the financing platform. In the invoice and receivables financing context, instructions can be transmitted to the current owner to transfer the NFT to an “expired” wallet corresponding to the financing platform. The NFT can therefore 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).

[0074] Returning to Fig. 1, at step 105 cancellation of the repeating transfer data structure is detected. Detecting cancellation of the repeating transfer data structure can include detecting an absence of a reverse transfer in the plurality of reverse transfers over a time period defined by the one or more transfer parameters. Detecting cancellation of the repeating transfer data structure can alternatively or additionally include receiving a notification of cancellation of the repeating transfer data structure from the second entity.

[0075] In the invoice and receivables financing context, this step can include cancellation of the recurring revenue receivable contract (repeating transfer data structure) being detected by the financing platform. Generally, detecting cancellation of the recurring revenue receivable contract can include one or more of: detecting a default of at least one repayment in the plurality of repayments or receiving a notification of cancellation of the recurring revenue receivable contract from the seller.

[0076] More specifically, the detection of cancellation of the RRR contract can be accomplished in a number of ways. For example, the seller can transmit a notification to the financing platform indicating the RRR contract has been canceled (e.g., if a buyer on the RRR contract cancels or defaults). The seller can also transmit a notification to the funder indicating that the RRR contract has been canceled and the funder can then notify the financing platform. In another example, cancellation of the RRR contract can be detected based at least in part on a default on an upcoming repayment corresponding to an NFT. For example, if the current owner of an NFT does not receive an expected repayment within a certain time frame, this default can be reported to the funding platform, which can then designate the RRR contract as canceled.

[0077] At step 106 of Fig. 1, one or more unique cryptographic identifiers in the plurality of unique cryptographic identifiers that are not designated as expired are replaced with one or more substitute unique cryptographic identifiers corresponding to one or more substitute transfer data structures of one or more substitute repeating transfer data structures.

[0078] In the invoice and receivables financing context, this step can include one or more NFTs in the plurality of NFTs (unique cryptographic identifiers) that are not designated as expired being replaced with one or more substitute NFTs corresponding to one or more substitute receivables of one or more substitute recurring revenue receivable contracts (substitute repeating transfer data structures).

[0079] Fig. 3 illustrates a flowchart for replacing one or more unique cryptographic identifiers in the plurality of unique cryptographic identifiers that are not designated as expired with one or more substitute unique cryptographic identifiers corresponding to one or more substitute transfer data structures of one or more substitute repeating transfer data structures according to an exemplary embodiment.

[0080] In the invoice and receivables financing context, this flowchart can correspond to replacing one or more NFTs in the plurality of NFTs that are not designated as expired with one or more substitute NFTs corresponding to one or more substitute receivables of one or more substitute recurring revenue receivable contracts according to an exemplary embodiment.

[0081] At step 301 the one or more unique cryptographic identifiers in the plurality of unique cryptographic identifiers that are not designated as expired are identified based at least in part on metadata corresponding to the plurality of unique cryptographic identifiers.

[0082] In the invoice and receivables financing context, this step can include identifying the one or more NFTs in the plurality of NFTs that are not designated as expired based at least in part on metadata corresponding to the plurality of NFTs stored by the financing platform. The financing platform tracks the status of each NFT, but can also poll the distributed ledger/block chain to determine the status of the NFTs (e.g., in the scenario where the NFTs are assigned to a NULL address upon repayment or transferred to an expired wallet/null address).

[0083] At step 302 the one or more substitute transfer data structures in the one or more substitute repeating transfer data structures are identified based at least in part on the one or more transfer parameters.

[0084] In the invoice and receivables financing context, this step can include identifying one or more substitute receivables of the one or more substitute recurring revenue receivable contracts based at least in part on the one or more contract parameters of the original RRR contract which was canceled. The substitute receivables and the substitute RRR contracts can be identified based at least in part on a comparison of RRR contract parameters of the original RRR contract and one or more potential replacement RRR contracts. The contract parameters can include receivable amounts, periods, rates, risk scores, buyers, sellers, or other metrics. The process of identifying substitute RRR contracts/receivables is described in greater detail in U.S. Provisional Application No. 63/299,801, filed January 14, 2022 and titled “METHOD, APPARATUS, AND COMPUTER READABLE MEDIUM FOR DYNAMIC SUBSTITUTION OF RECURRING RECEIVABLES CONTRACTS USING A LINKED QUEUE,” the disclosure of which is hereby incorporated by reference. As explained in that application, a “back-up” queue of receivables and RRR contracts can be associated with each RRR contract that receives funding, so that substitutes can be quickly identified in the event of cancellation of the funded RRR contract.

[0085] At step 303 generation of the one or more substitute unique cryptographic identifiers corresponding to the one or more substitute transfer data structures on the distributed file system is initiated based at least in part on the one or more substitute repeating transfer data structures, the one or more substitute unique cryptographic identifiers corresponding to the one or more substitute unique cryptographic identifiers.

[0086] In the invoice and receivables financing context, this step can include initiating minting of the one or more substitute NFTs corresponding to the one or more substitute receivables on the distributed ledger based at least in part on the one or more substitute recurring revenue receivable contracts, the one or more substitute NFTs corresponding to the one or more substitute receivables. This minting process is similar to the minting step 102 described with respect to Fig. 1, and can be performed/signed using the private keys of the seller (or sellers) associated with the substitute RRR contracts (e.g., with the financing platform acting as custodian).

[0087] At step 304 the one or more unique cryptographic identifiers that are not designated as expired are replaced with the one or more substitute unique cryptographic identifiers

[0088] In the invoice and receivables financing context, this step can include replacing the one or more NFTs that are not designated as expired with the one or more substitute NFTs. As discussed in greater detail below, this “replacement” designates NFTs corresponding to canceled receivables as canceled or expired and coordinates the transfer of the substitute NFTs to the current owners of canceled NFTs.

[0089] Fig. 4 illustrates a flowchart for replacing the one or more unique cryptographic identifiers that are not designated as expired with the one or more substitute unique cryptographic identifiers according to an exemplary embodiment.

[0090] In the invoice and receivables financing context, this flowchart can correspond to replacing the one or more NFTs that are not designated as expired with the one or more substitute NFTs according to an exemplary embodiment.

[0091] At step 401 one or more current owners of the one or more unique cryptographic identifiers that are not designated as expired are identified.

[0092] In the invoice and receivables financing context, this step can include identifying one or more current owners of the one or more NFTs that are not designated as expired. This step can include polling the distributed ledger to determine ownership and/or querying internal metadata storing ownership data. [0093] At step 402 a transfer of the one or more substitute unique cryptographic identifiers to the one or more current owners of the one or more unique cryptographic identifiers that are not designated as expired is initiated.

[0094] In the invoice and receivables financing context, this step can include initiating a transfer of the one or more substitute NFTs to the one or more current owners of the one or more NFTs that are not designated as expired. This step can include the financing platform initiating transactions on the distributed ledger to transfer the substitute NFTs from the seller to the one or more current owners of the one or more NFTs (e.g., using the private key/electronic wallet of the seller). Alternatively, the financing platform can prompt the seller to initiate the transfer or can otherwise facilitate the transfer of the substitute NFTs from the seller to the current owners of the canceled NFTs.

[0095] Optionally, at step 403 a designation of the one or more unique cryptographic identifiers that are not designated as expired are changed from active to canceled in the metadata corresponding to the plurality of unique cryptographic identifiers.

[0096] In the invoice and receivables financing context, this step can include changing a designation of the one or more NFTs that are not designated as expired from active to canceled in the metadata corresponding to the plurality of NFTs stored by the financing platform. These NFTs correspond to the receivables in the original RRR contract that is detected as canceled. Since the RRR is canceled and substitute NFTs corresponding to substitute receivables are minted, the remaining NFTs corresponding to the original RRR contract no longer indicate a repayment obligation. Optionally, the metadata can be updated to designate the canceled NFTs as “expired,” similar to NFTs for which repayment has been made.

[0097] Optionally, at step 404 one or more instructions are transmitted to the one or more current owners of the one or more unique cryptographic identifiers that are not designated as expired to void the one or more unique cryptographic identifiers that are not designated as expired. [0098] In the invoice and receivables financing context, this step can include transmitting one or more instructions to the one or more current owners of the one or more NFTs that are not designated as expired to burn the one or more NFTs that are not designated as expired by transferring them to a NULL address on the distributed ledger. This step effectively disables the canceled NFTs, making them non-transferrable. This step can be useful in preventing misuse or fraud relating to NFTs that are canceled and can no longer be redeemed for repayment from a seller. Alternatively, one or more instructions can be transmitted to the one or more current owners of the one or more NFTs that are not designated as expired to transfer the canceled NFTs to an “expired” wallet of the financing platform, as discussed earlier.

[0099] Figs. 5-7B illustrate various components and functionalities of the present system and method with respect to the use-case of a single NFT and funding based upon a single receivable. Subsequent figures illustrate examples of the recurring revenue receivables contract tokenization and funding processes described herein.

[0100] Fig. 5 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 502 can interface with the financing platform 501, allowing the seller to provide a receivable contract to the financing platform 501. The system can include a financing platform 501, a computing device of a seller 502, a computing device of a funder 503, a distributed ledger 504, and an IPFS 505. The financing platform 501 can interface with the electronic wallet of the seller, the distributed ledger 504, and the IPFS 505. Optionally, the financing platform 501 can interface with the electronic wallet of the funder. The computing device of the funder 503 can interface with the financing platform 501, allowing the funder to select an NFTr for purchase.

[0101] 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. [0102] Blockchain/distributed ledger 504 can be on an Ethereum sidechain. While illustrated in Fig. 5 as a single blockchain, it should be appreciated that distributed ledger 504 can be more than one distributed ledgers on more than one blockchain.

[0103] A blockchain environment corresponding to blockchain/distributed ledger 504 according to an exemplary embodiment is illustrated in Fig. 5. Cross-chain communication can occur between blockchain/distributed ledger 504 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.

[0104] Interplanetary File System (IPFS) 505 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.

[0105] Fig. 6A 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.

[0106] Fig. 6B 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. [0107] Fig. 6C 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.

[0108] Fig. 7A 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

[0109] While Fig. 7A 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 .

[0110] Fig. 7B 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 501 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.

[0111] Figs. 8A-8C illustrate an example of tokenized recurring revenue receivables financing according to an exemplary embodiment. As shown in Fig. 8A, funding has been provided to a seller A 802 for a RRR contract having six receivables. Six NFTs have been minted on the distributed ledger 804 corresponding to the six receivables.

[0112] As indicated in the metadata 801 A on the financing platform 801, the first three NFTs are expired, indicating that repayment has occurred from the seller A 802 to the current holder of those NFTs at the time repayment was due. As additionally indicated in the metadata

801 A, the fourth and fifth NFTs are owned by funder A 802, and the sixth NFT is owned by purchaser A 803 (e.g., who acquired the NFT from the funder A 812).

[0113] Bidirectional solid arrows indicate bidirectional communication between seller A

802 and the financing platform 801 and funder A 812 and the financing platform. Additionally, dashed bidirectional arrow indicates that purchaser A 803 can also optionally have bidirectional communications with the financing platform. Furthermore, the financing platform 801 can read from or write to the distributed ledger/blockchain 804.

[0114] Ownership of the three remaining active NFTs (NFT 4, NFT 5, and NFT 6) is indicated in metadata 801A and by unidirectional dashed arrows. For example, dashed arrows point from NFT 4 and NFT 5 to funder A 812 and a dashed arrow points from NFT 6 to purchaser A 803.

[0115] Fig. 8B illustrates examples of cancellation/default of the RRR contract. As shown in Fig. 8B, a cancellation notification 805 can be sent from seller A 802 to financing platform 801. Additionally or alternatively, a default notification 806 can also be sent from funder A 812 to the financing platform 801. Additionally or alternatively, the smart contract on the distributed ledger 804 can notify the financing platform 801 of a default via default notification 807 or the financing platform can query/poll the distributed ledger 804 to determine a default status relating to repayment due to an NFT holder. [0116] Fig. 8C illustrates the creation of substitute NFTs. Specifically, as shown in metadata 801A and on the distributed ledger 804, three substitute NFTs are created from substitute receivables, as described earlier in this application. The current owner of these substitute receivables is initially the seller, since their private key is used to mint the NFTs/sign the minting transaction. The financing platform also designates NFT 4, NFT 5, and NFT 6 as canceled, since the original RRR contract has been detected as being canceled.

[0117] The financing platform 801 can optionally also instruct funder A 812 to cancel their owned NFTs via an NFT cancel message 808 and instruct Purchaser A 803 to cancel their owned NFT via NFT cancel message 809.

[0118] As shown in Fig. 8D, the substitute NFTs are then transferred from seller A 802 to funder A 812 and from seller A 802 to purchaser A 803. The substitute NFTs replace the canceled NFTs previously owned by funder A 812 and purchaser A 803. Specifically, substitute NFT 1 and substitute NFT 2 replace cancelled NFT 4 and NFT 5, previously owned by funder A 812. Additionally, substitute NFT 3 replaces cancelled NFT 6, previously owned by purchaser A 803.

[0119] The metadata 801 A reflects the ownership transfer from seller A 802 to funder A 812 and purchaser A 803. The actual transfer can be initiated by seller A 802 (e.g., at the prompting of the financing platform 801) or by financing platform 801 as custodian, using the private key/electronic wallet of seller A 802. As a result of the transfer, the distributed ledger 804 is updated to indicate the new ownership.

[0120] Optionally, funder A 812 can initiate a transaction to “burn” the canceled NFTs, NFT 4 and NFT 5, and purchaser A 803 can initiate a transaction to “bum” the canceled NFT 6. These transactions transfer ownership from funder A 812 and purchaser 803 to a NULL address, rendering the NFTs non-transferrable. Alternatively, transactions can also be used to transfer the canceled NFTs to an “expired” wallet of the financing platform 801.

[0121] Fig. 9 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.

[0122] Fig. 10 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.

[0123] Fig. 11 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.

[0124] 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

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

[0126] Fig. 13 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.

[0127] 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.

[0128] Fig. 14 illustrates a system diagram of the architecture of receivables data from the receivable contract according to an 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.

[0129] Fig. 15 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.

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

[0131] As shown in Fig. 16, memory 1601 can include transfer data structure database 1601A, cryptographic identifier generation software 1601B, metadata database 1601C, networkclient communication software 1601D, entity communication software 1601E, transfer tracking software 160 IF, self-executing code generation software 1601G, transfer data structure scoring software 1601H, and cryptographic identifier substitution software 16011, as well as any other components required to perform the methods described herein. Each of the software components in memory 1601 store specialized instructions and data structures configured to perform the corresponding functionality and techniques described herein.

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

[0133] Processor(s) 1602 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.

[0134] Specialized computing environment 1600 additionally includes a communication interface 1603, 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.

[0135] Specialized computing environment 1600 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 1601, or to perform other administrative functions.

[0136] An interconnection mechanism (shown as a solid line in Fig. 16), such as a bus, controller, or network interconnects the components of the specialized computing environment 1300.

[0137] Input and output interfaces 1604 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 1600.

[0138] Specialized computing environment 1600 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 1600.

Claims

CLAIMS We claim:

1. A method executed by one or more computing devices of a controller of a distributed transfer network for replacement of a cancelled repeating transfer data structure, the method comprising: receiving, by the controller, a plurality of transfer data structures corresponding to a repeating transfer data structure, the repeating transfer data structure identifying a first entity having requirements associated with a plurality of transfers to a second entity, the second entity having collection authority to receive the plurality of transfers from the first entity, and one or more transfer parameters governing the plurality of transfers; initiating, by the controller, generation of a plurality of unique cryptographic identifiers corresponding to the plurality of transfer data structures on a distributed file system based at least in part on the repeating transfer data structure, the second entity being registered as a current owner of the plurality of unique cryptographic identifiers on the distributed file system, wherein collection authority for the repeating transfer data structure is linked to the current owner; generating, by the controller, a self-executing code corresponding to the repeating transfer data structure based at least in part on the one or more transfer parameters, the selfexecuting code corresponding to the plurality of unique cryptographic identifiers and being stored on the distributed file system; executing, by the controller, an exchange transfer corresponding to the repeating transfer data structure, the exchange transfer resulting in a network-client being registered as the current owner of the plurality of unique cryptographic identifiers in exchange for a transfer from the network-client to the second entity, wherein each unique cryptographic identifier in the plurality of unique cryptographic identifiers corresponds to a reverse transfer in a plurality of reverse transfers associated with the exchange transfer and wherein the self-executing code is configured to designate each unique cryptographic identifier for which a reverse transfer is detected as expired; detecting, by the controller, cancellation of the repeating transfer data structure; and replacing, by the controller, one or more unique cryptographic identifiers in the plurality of unique cryptographic identifiers that are not designated as expired with one or more substitute unique cryptographic identifiers corresponding to one or more substitute transfer data structures of one or more substitute repeating transfer data structures.

2. The method of claim 1, further comprising: detecting, by the controller, a reverse transfer from the second entity corresponding to a reverse transfer in the plurality of reverse transfers associated with the exchange transfer, the reverse being directed to a current owner of a unique cryptographic identifier corresponding to the reverse transfer; and designating, by the controller, the unique cryptographic identifier as expired based at least in part on detection of the reverse transfer.

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

4. The method of claim 1, wherein the self-executing code is further configured to route each reverse transfer from the second entity to a current owner of each unique cryptographic identifiers corresponding to that reverse transfer.

5. The method of claim 1, wherein detecting cancellation of the repeating transfer data structure comprises one or more of: detecting an absence of a reverse transfer in the plurality of reverse transfers over a time period defined by the one or more transfer parameters; or receiving a notification of cancellation of the repeating transfer data structure from the second entity.

6. The method of claim 1, wherein replacing one or more unique cryptographic identifiers in the plurality of unique cryptographic identifiers that are not designated as expired with one or more substitute unique cryptographic identifiers corresponding to one or more substitute transfer data structures of one or more substitute repeating transfer data structures comprises: identifying the one or more unique cryptographic identifiers in the plurality of unique cryptographic identifiers that are not designated as expired based at least in part on metadata corresponding to the plurality of unique cryptographic identifiers; identifying the one or more substitute transfer data structures in the one or more substitute repeating transfer data structures based at least in part on the one or more transfer parameters; initiating generation of the one or more substitute unique cryptographic identifiers corresponding to the one or more substitute transfer data structures on the distributed file system based at least in part on the one or more substitute repeating transfer data structures, the one or more substitute unique cryptographic identifiers corresponding to the one or more substitute unique cryptographic identifiers; and replacing the one or more unique cryptographic identifiers that are not designated as expired with the one or more substitute unique cryptographic identifiers.

7. The method of claim 6, wherein replacing the one or more unique cryptographic identifiers that are not designated as expired with the one or more substitute unique cryptographic identifiers comprises one or more of: identifying one or more current owners of the one or more unique cryptographic identifiers that are not designated as expired and initiating a transfer of the one or more substitute unique cryptographic identifiers to the one or more current owners of the one or more unique cryptographic identifiers that are not designated as expired; changing a designation of the one or more unique cryptographic identifiers that are not designated as expired from active to canceled in the metadata corresponding to the plurality of unique cryptographic identifiers; or transmitting one or more instructions to the one or more current owners of the one or more unique cryptographic identifiers that are not designated as expired to void the one or more unique cryptographic identifiers that are not designated as expired.

8. A controller of a distributed transfer network for replacement of a cancelled repeating transfer data structure 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 plurality of transfer data structures corresponding to a repeating transfer data structure, the repeating transfer data structure identifying a first entity having requirements associated with a plurality of transfers to a second entity, the second entity having collection authority to receive the plurality of transfers from the first entity, and one or more transfer parameters governing the plurality of transfers; initiate generation of a plurality of unique cryptographic identifiers corresponding to the plurality of transfer data structures on a distributed file system based at least in part on the repeating transfer data structure, the second entity being registered as a current owner of the plurality of unique cryptographic identifiers on the distributed file system, wherein collection authority for the repeating transfer data structure is linked to the current owner; generate a self-executing code corresponding to the repeating transfer data structure based at least in part on the one or more transfer parameters, the self-executing code corresponding to the plurality of unique cryptographic identifiers and being stored on the distributed file system; execute an exchange transfer corresponding to the repeating transfer data structure, the exchange transfer resulting in a network-client being registered as the current owner of the plurality of unique cryptographic identifiers in exchange for a transfer from the network-client to the second entity, wherein each unique cryptographic identifier in the plurality of unique cryptographic identifiers corresponds to a reverse transfer in a plurality of reverse transfers associated with the exchange transfer and wherein the self-executing code is configured to designate each unique cryptographic identifier for which a reverse transfer is detected as expired; detect cancellation of the repeating transfer data structure; and replace one or more unique cryptographic identifiers in the plurality of unique cryptographic identifiers that are not designated as expired with one or more substitute unique cryptographic identifiers corresponding to one or more substitute transfer data structures of one or more substitute repeating transfer data structures.

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: detect a reverse transfer from the second entity corresponding to a reverse transfer in the plurality of reverse transfers associated with the exchange transfer, the reverse being directed to a current owner of a unique cryptographic identifier corresponding to the reverse transfer; and designate the unique cryptographic identifier as expired based at least in part on detection of the reverse transfer.

10. 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 repeating transfer data structure in a private database separate from the distributed database, the metadata being linked to the plurality of unique cryptographic identifiers.

11. The controller of claim 8, wherein the self-executing code is further configured to route each reverse transfer from the second entity to a current owner of each unique cryptographic identifiers corresponding to that reverse transfer.

12. The controller of claim 8, 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 detect cancellation of the repeating transfer data structure further cause at least one of the one or more processors to perform one or more of: detect an absence of a reverse transfer in the plurality of reverse transfers over a time period defined by the one or more transfer parameters; or receive a notification of cancellation of the repeating transfer data structure from the second entity.

13. The controller of claim 8, 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 replace one or more unique cryptographic identifiers in the plurality of unique cryptographic identifiers that are not designated as expired with one or more substitute unique cryptographic identifiers corresponding to one or more substitute transfer data structures of one or more substitute repeating transfer data structures further cause at least one of the one or more processors to: identify the one or more unique cryptographic identifiers in the plurality of unique cryptographic identifiers that are not designated as expired based at least in part on metadata corresponding to the plurality of unique cryptographic identifiers; identify the one or more substitute transfer data structures in the one or more substitute repeating transfer data structures based at least in part on the one or more transfer parameters; initiate generation of the one or more substitute unique cryptographic identifiers corresponding to the one or more substitute transfer data structures on the distributed file system based at least in part on the one or more substitute repeating transfer data structures, the one or more substitute unique cryptographic identifiers corresponding to the one or more substitute unique cryptographic identifiers; and replace the one or more unique cryptographic identifiers that are not designated as expired with the one or more substitute unique cryptographic identifiers.

14. The controller of claim 13, 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 replace the one or more unique cryptographic identifiers that are not designated as expired with the one or more substitute unique cryptographic identifiers further cause at least one of the one or more processors to perform one or more of: identify one or more current owners of the one or more unique cryptographic identifiers that are not designated as expired and initiating a transfer of the one or more substitute unique cryptographic identifiers to the one or more current owners of the one or more unique cryptographic identifiers that are not designated as expired; change a designation of the one or more unique cryptographic identifiers that are not designated as expired from active to canceled in the metadata corresponding to the plurality of unique cryptographic identifiers; or transmit one or more instructions to the one or more current owners of the one or more unique cryptographic identifiers that are not designated as expired to void the one or more unique cryptographic identifiers that are not designated as expired.

15. At least one non-transitory computer-readable medium storing computer-readable instructions for replacement of a cancelled repeating transfer data structure on the 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 plurality of transfer data structures corresponding to a repeating transfer data structure, the repeating transfer data structure identifying a first entity having requirements associated with a plurality of transfers to a second entity, the second entity having collection authority to receive the plurality of transfers from the first entity, and one or more transfer parameters governing the plurality of transfers; initiate generation of a plurality of unique cryptographic identifiers corresponding to the plurality of transfer data structures on a distributed file system based at least in part on the repeating transfer data structure, the second entity being registered as a current owner of the plurality of unique cryptographic identifiers on the distributed file system, wherein collection authority for the repeating transfer data structure is linked to the current owner; generate a self-executing code corresponding to the repeating transfer data structure based at least in part on the one or more transfer parameters, the self-executing code corresponding to the plurality of unique cryptographic identifiers and being stored on the distributed file system; execute an exchange transfer corresponding to the repeating transfer data structure, the exchange transfer resulting in a network-client being registered as the current owner of the plurality of unique cryptographic identifiers in exchange for a transfer from the network-client to the second entity, wherein each unique cryptographic identifier in the plurality of unique cryptographic identifiers corresponds to a reverse transfer in a plurality of reverse transfers associated with the exchange transfer and wherein the self-executing code is configured to designate each unique cryptographic identifier for which a reverse transfer is detected as expired; detect cancellation of the repeating transfer data structure; and replace one or more unique cryptographic identifiers in the plurality of unique cryptographic identifiers that are not designated as expired with one or more substitute unique cryptographic identifiers corresponding to one or more substitute transfer data structures of one or more substitute repeating transfer data structures.

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: detect a reverse transfer from the second entity corresponding to a reverse transfer in the plurality of reverse transfers associated with the exchange transfer, the reverse being directed to a current owner of a unique cryptographic identifier corresponding to the reverse transfer; and designate the unique cryptographic identifier as expired based at least in part on detection of the reverse transfer.

17. 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 repeating transfer data structure in a private database separate from the distributed database, the metadata being linked to the plurality of unique cryptographic identifiers.

18. The at least one non-transitory computer-readable medium of claim 15, wherein the self-executing code is further configured to route each reverse transfer from the second entity to a current owner of each unique cryptographic identifiers corresponding to that reverse transfer.

19. 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 detect cancellation of the repeating transfer data structure further cause the controller to perform one or more of: detect an absence of a reverse transfer in the plurality of reverse transfers over a time period defined by the one or more transfer parameters; or receive a notification of cancellation of the repeating transfer data structure from the second entity.

20. 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 replace one or more unique cryptographic identifiers in the plurality of unique cryptographic identifiers that are not designated as expired with one or more substitute unique cryptographic identifiers corresponding to one or more substitute transfer data structures of one or more substitute repeating transfer data structures further cause the controller to: identify the one or more unique cryptographic identifiers in the plurality of unique cryptographic identifiers that are not designated as expired based at least in part on metadata corresponding to the plurality of unique cryptographic identifiers; identify the one or more substitute transfer data structures in the one or more substitute repeating transfer data structures based at least in part on the one or more transfer parameters; initiate generation of the one or more substitute unique cryptographic identifiers corresponding to the one or more substitute transfer data structures on the distributed file system based at least in part on the one or more substitute repeating transfer data structures, the one or more substitute unique cryptographic identifiers corresponding to the one or more substitute unique cryptographic identifiers; and replace the one or more unique cryptographic identifiers that are not designated as expired with the one or more substitute unique cryptographic identifiers.

21. The at least one non-transitory computer-readable medium of claim 20, wherein the instructions that, when executed by the controller, cause the controller to replace the one or more unique cryptographic identifiers that are not designated as expired with the one or more substitute unique cryptographic identifiers further cause the controller to perform one or more of: identify one or more current owners of the one or more unique cryptographic identifiers that are not designated as expired and initiating a transfer of the one or more substitute unique cryptographic identifiers to the one or more current owners of the one or more unique cryptographic identifiers that are not designated as expired; change a designation of the one or more unique cryptographic identifiers that are not designated as expired from active to canceled in the metadata corresponding to the plurality of unique cryptographic identifiers; or transmit one or more instructions to the one or more current owners of the one or more unique cryptographic identifiers that are not designated as expired to void the one or more unique cryptographic identifiers that are not designated as expired.