FIELD OF THE INVENTION

The present invention relates generally to fund distribution. More specifically, the present invention is a tokenized micro-draw process for funds distribution between contractors and subcontractors.

BACKGROUND OF THE INVENTION

Current financial draw processes used to distribute funds for complex contracting jobs are inefficient and slow. A single contract between two parties will frequently contain multiple stages of performance, or tasks, which need to be manually subdivided by a human reading the contract to establish clearer objectives. While notice of a completed task should lead directly to approval of the completed task and the release of funds allocated for that task, the existing processes result in the notice of a completed task being passed to a managing party or communication liaison, who then passes this information to the party responsible for approving the task, who then passes the approval back to the managing party or liaison. Lag time between communication leads to higher costs and time for a project’s completion. The current process often places a heavy burden on the accounts receivable department, which must actively scramble to collect funds after each individual task is completed. This is very costly. In addition, the current financial draw processes rely on manual processes, which are subject to human error, to maintain business ledgers and keep track of all transactions.

SUMMARY OF THE INVENTION

The object of the present invention is to address previous issues with fund distribution by providing users with a tokenized micro-draw process for contract funds distribution that facilitates the contract funds draw process after completion of discrete subtasks. But utilizing the blockchain, which holds a ledger of all past transactions, the present invention allows for much more granular payments and increases transparency, governance, and control over the distribution of funds with less friction and costs.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. l is a flowchart showing the overall process of contract fund tokenization.

FIG. 2 is a flowchart showing the task approval process when multiple approvals are required.

FIG. 3 is a continuation of the FIG. 2 flowchart, showing the task approval process when multiple approvals are required.

FIG. 4 is a flowchart showing geo-fencing limitations that may be imposed on task approval.

FIG. 5 is a flowchart showing a task dependency system for approving a task and validating payments.

FIG. 6 is a flowchart showing geo-fencing coupled with task dependency, requiring both a viable task and correct location to approve a task.

FIG. 7 is a class diagram showing the Token (or Smart Contract) object.

DETAILED DESCRIPTION OF THE INVENTION

All illustrations of the drawings are for the purpose of describing selected versions of the present invention and are not intended to limit the scope of the present invention.

The present invention is a tokenized micro-draw process for contract funds distribution.

The present invention tokenizes contract funds as a digital twin, assigning properties and state, and distribute those tokens, also known as “smart contracts,” to project participants as a guarantee of immediate payment upon completion and approval of project task or a product delivery. Once payment is approved, digital funds are immediately converted into fiat currency and deposited directly into the vendors checking account via ACH transfer.

The present invention replaces the current financial draw process used to distribute funds during contracted jobs with an entirely new computer-based process that utilizes “enterprise” blockchain technology and immutable “asset tokenization” in a way that could not be emulated previously. The strength of the blockchain is that a digital ledger is kept of all data and transactions that occur. While the transactions themselves can be easily viewed and audited, certain information, such as personal bank information, must be decrypted by the private key held by relevant parties to the transaction. This allows the information to be stored securely and validated by multiple parties without being directly accessed or viewed by the multiple parties.

The present invention works by creating a digital twin of the funds using tokenization on a blockchain, along with the assignment of project identifier property to the token, and the initial setting of state for the token to a “committed” status. The following depicts how the present invention works:

1. The process starts with the tokens being “minted” with the “project” identifier property being assigned to the token when the funds are in escrowed or secured in some other fashion using a smart contract. Often contracts will be parsed and converted from traditional long-form contracts, with multiple tasks described, into smart contracts that subdivide the work into discrete tasks that may be more simply completed, monitored, and paid out.

2. The tokens are then passed forward to the general contractor or project manager to be distributed upon contract award to the subcontractors (or vendors) using a smart contract.

3. Tokens awarded to vendors will then have the Vendor ID, Task ID, and Purchase order number properties assigned, in addition to the negotiated value of the contract, as the Token value. Optionally, a variable in one Token may be set that points to a second Token to establish a dependency, so that the tasks associated with the second token must be approved before the first token may be approved. 4. When a project task is complete and approved, or a product is delivered and verified, then the appropriate number of tokens associated with that event has the Status ID changed from the “committed” status to the “approved” status using a smart contract.

5. The vendor can then elect to have the tokens that are now have the Status ID in the “approved” state, converted into the fiat currency of their choice, and deposited into a traditional checking account (see FIG. 1).

6. Once the funds have been deposited into the vendor’s checking account, those tokens associated with the deposit now have their Status ID set to the “paid” status using a smart contract.

7. Finally, once funds associated with an approved task or product delivery have been deposited into the vendor’s checking account, an automatic “mechanic’s lien release” is generated, if applicable, and delivered to the source of funds using a smart contract (see FIG. 1).

Each step in the process, coupled with the blockchain technology being utilized in the process provides not only a new way to accelerate the payment draw process, but also allows for much more granular payments than prior methods. In addition, due to the unique functionality of “enterprise” blockchain technology, transparency, governance, and control over the distribution of funds is achieved in a significant fashion with less friction and costs when compared with prior methods.

Different types of contracts require different parties to approve final completion. While the simplest contracts may only require approval from the subcontractor (or vendor) themselves, as shown in FIG. 1, others require approval by a project manager, owner, architect, and/or engineer with expertise in the related field. FIGS. 2 and 3 show the approval process when a project manager must also approve the task (FIG. 2 only), or when multiple parties must approve the task before payment is finalized (FIGS. 2 and 3).

The present invention also makes use of “geofencing” to validate task completion, as shown in FIGS. 4 and 6. Because task approval for contracts often requires the approver to be on site and to inspect a physical object, the present invention enforces a location requirement to ensure due diligence has been taken to inspect the site and approve each individual task. In addition, often a task is dependent on a prior task, and the subsequent task cannot be completed until the prior task is completed. A common example of this in construction is excavation, followed by laying of concrete, followed by construction on a site using a crane - all using different subcontractors. Following that example, the concrete subcontractor should not be able to approve all of their tasks and receive payment until the excavation subcontractor has finished, and likewise, the crane subcontractor should not be able to approve all of their tasks and receive payment until the concrete subcontractor has finished. Another example is the movie industry or other media projects, in which certain casting and location securement tasks must be completed before filming begins. The present invention enforces task dependency, shown in FIG. 5, so that task and payment approval buttons are “grayed out,” or inactive, until all prior tasks are completed. The next task can only be approved when the next task is no longer dependent on any incomplete tasks.

Concepts of geo-fencing and claim dependence may be combined to require both location on-site and completion of prior tasks, only which the current task is dependent, for approval to be completed. This is shown in FIG. 6.

FIG. 7 shows a basic class diagram of the Token, or Smart Contract, object. A token is issued for each task to each contractor. This object comprises fields denoting the Status ID, Purchase order number, Task ID, Vendor ID, Project ID, and Token value. Optionally the Token object may further comprise a geolocation and a purchase order number for another Token on which the Token is dependent. The Status ID indicates the current progress of the task. When a task is initially created, the Status ID is set to “Committed.” Next, when money has been received in escrow for the task, the Status ID is set to “Funded.” Next, when the task has been completed and approved, the Status ID is set to “Approved.” Finally, when the subcontractor, or vendor, has received payment from escrow, the Status ID is set to “Paid.” The Purchase order number is used for record keeping and is represented by a unique alphanumeric string to represent the individual task. Like a GUID or other auto-generated alphanumeric strings, the Purchase order number is a unique string, such as “P.O.# NC005473229,” that is not necessarily decipherable but directly correlates with a single token’s purchase order. The Task ID is a simple description of the task to be performed, such as “Slab Pour.” The Vendor ID is a unique identifier of the subcontractor, or vendor, that is performing the work. Note that multiple tokens may be tied to a single Vendor ID if they complete multiple tasks on the same project. The Project ID is a unique identifier for each project completed. Notably, multiple vendors may work on the same project, so that a single Project ID may have multiple vendors sharing the same Project ID. The Token value denotes the amount to be paid for task completion. The Token value may either be represented in United States Dollars (US$), USDF Stablecoins (a cryptocurrency issued by banks), or any other currency acceptable by all parties to the transaction. The geolocation may be a specific address or simply coordinates for a position and a radius. The geolocation is used for geofencing in some embodiments to ensure that a task is approved on-site. Finally, the Token may include a pointer to another Token, using that Token’s purchase order number, so that dependency may be established. A first Token will point to a second token on which it is dependent. Only after the second Token is marked approved can the first Token be approved. Although the invention has been explained in relation to its preferred embodiment, it is to be understood that many other possible modifications and variations can be made without departing from the spirit and scope of the invention.