EA015056B1 - Construction payment management system and method with document tracking features - Google Patents

Abstract

A system and method of managing a construction payment process involving a plurality of participants associated with the construction project and at least one document to be transferred between at least two participants of the plurality participants during the course of the construction project. One method can include assigning at least one enforcement action to the at least one document wherein the enforcement action is automatically effected if the document is not transferred between the at least two participants.

Description

The application for this invention is a partially ongoing application for an application with serial number 11/032699 for the grant of a US patent, filed January 10, 2005, which claims the priority of provisional application with serial number 60/583782, filed June 29, 2004, the contents of both these applications are incorporated herein by reference. A patent application also claims the priority of a provisional application with serial number 60/785411 for patent grant, filed March 23, 2006, the entire contents of which are also incorporated into these materials by reference.

State of the art

Residential and commercial construction projects require several organizations to interact with each other to distribute payments. The usual process of managing payments in construction begins with an oral notice that funds will be allocated from the construction loan or the account of the property owner. The general contractor (GP) of the construction project shall notify by telephone, fax or at a meeting of subcontractors (or any other persons, company or corporation involved by the GP, such as suppliers of materials) the allocation of funds. Subcontractors prepare invoices and send them to SOEs by mail, fax, courier delivery or transmit them at a meeting with SOEs. SOEs and subcontractors often need to negotiate the dollar amount of the final bill by phone or at meetings. The SOE confirms the accounts, enters the details into the accounting system of the SOE project and prepares its own account.

Once the accounts are finalized, the SOE also manually prepares a sworn statement. In a sworn statement, the SOE confirms that the subcontractors involved in the SOE have performed specific services for the construction or repair of property. In a sworn statement, the SOE also confirms the dollar amount to which each subcontractor is entitled.

The SOE sends an oath to the title company and the lender (lender of a construction loan (loan)) and / or property owner. The lender, owner of the property or title company notifies the inspector that the property should be inspected and sends an oath to the inspector. The inspector collects previous inspection reports for the property. The inspector conducts a new inspection and manually prepares an inspection report. The inspector transmits the inspection report, the report to the lender, owner of the property and / or title company by fax, mail or courier delivery.

The lender, property owner and / or title company receive a sworn statement and inspection report by mail, fax, courier delivery or at a meeting with the GP and / or inspector. The lender, owner of the property and / or title company should refer to the previous allocation of funds and design documentation. The lender, the owner of the property and / or the title company often must agree on the amount of payment and details of the project with the SOE by telephone, fax or meeting. The lender, property owner and / or title company approves the affidavit and passes the approval by phone, fax or meeting. The lender or owner of the property then approves the spending of the dollar amount specified in the sworn statement.

A home loan lender or property owner’s bank usually transfers the funds needed to pay all subcontractors to the escrow account. Often, the title company then pays SO funds from the escrow account. SOEs and / or title companies prepare checks for subcontractors. At this time, subcontractors mainly carry out refusals to withhold on the previous allocation of funds from a construction loan or for work completed during the previous month. As a result, refusals to withhold on the current allocation of funds or the current month are not actually removed until a subsequent allocation of funds from the construction loan or until the next month. In addition, subcontractors may have their own subcontractors, which they must pay after receiving payment from the SOE.

The normal payment process in construction can take 90 days or longer from the date of the oral notification of the allocation of funds to the date on which the subcontractors actually receive the payment. The usual payment process in construction usually involves unreliable oral notification of events on which the course of the process depends. For example, if one subcontractor is unavailable to prepare an invoice or to submit a refusal to hold, the payment process for all other subcontractors may be delayed. In addition, if one of the subcontractors is unable to provide the proper documents required by the SOE, the SOE (or other participants above the line and / or below the line) often threatens to suspend payment to the subcontractor in order to force the subcontractor to comply with legal standards. For example, a GP can inform a subcontractor that it will not be paid if it does not return a signed copy of its subcontract.

The usual payment process in construction also involves massive amounts of data entry. For example, for one large construction project, a SOE often needs to enter hundreds of accounts into its accounting system every month. In addition, the SOE must collect hundreds of retention failures every month. Additionally, the SOE must prepare, approve, sign, and distribute hundreds of checks to subcontractors every month. Next, the SOE must retain all paper documents collected during

- 1 015056 of each disbursement process. Reconciling notifications of disbursements, approvals, and withholding denial exchanges for payment requires hundreds of faxes, phone calls, and meetings every month.

SUMMARY OF THE INVENTION

Embodiments of the invention provide a system and method for controlling a payment process in construction involving a plurality of participants associated with a construction project and at least one document to be transmitted between at least two participants from the plurality of participants during the construction project. One method embodying the invention may include assigning at least one enforcement action to at least one document, the enforcement action being performed automatically if the document is not transferred between at least two participants.

One payment management system in construction embodying the invention may include a document tracking module for assigning at least one enforcement action to at least one document, and at least one enforcement action being performed automatically if the document is not transferred between at least two participants .

One graphical user interface for a construction payment management system embodying the invention includes a separate document status page accessible by at least two participants, a document status summary page displaying at least one law enforcement action assigned to at least one document, and to be automatically executed if at least one document has not been transmitted between at least two participants.

Brief Description of the Drawings

FIG. 1 is a schematic illustration of a payment management system in construction in accordance with one embodiment of the invention.

FIG. 2 is a schematic illustration of payment management processes in construction that can be performed using the system of FIG. one.

FIG. 3 is a schematic illustration of a project management process.

FIG. 4 is a schematic illustration of an organization management process.

FIG. 5 is a schematic illustration of a disbursement management process.

FIG. 6 is a schematic illustration of a change order management process.

FIG. 7 is a schematic illustration of the tasks of managing the system environment.

FIG. 8 is a schematic illustration of an organization creation process.

FIG. 9 is an illustration of creating an organization form.

FIG. 10 is an illustration of a user system update notification.

FIG. 11 is an illustration of a system notification.

FIG. 12 is an illustration of an organization editing form.

FIG. 13 is an illustration of an organization activation notification.

FIG. 14 is an illustration of an organization activation form.

FIG. 15 is an illustration of a notification of an activated organization.

FIG. 16 is an illustration of an organization deactivation notification.

FIG. 17 is a schematic illustration of an organization maintenance process.

FIG. 18 is an illustration of an organization presentation screen.

FIG. 19 is an illustration of an organization view screen.

FIG. 20 is an illustration of an organization editing form.

FIG. 21 is an illustration of a notification about an updated organization profile.

FIG. 22 is a schematic illustration of a user creation process.

FIG. 23 is an illustration of a user creation form.

FIG. 24 is an illustration of a user profile update notification.

FIG. 25 is a schematic illustration of a user maintenance process.

FIG. 26 is an illustration of a user presentation screen.

FIG. 27 is an illustration of a user viewing screen.

FIG. 28 is an illustration of a user editing form.

FIG. 29 is an illustration of a notification about an updated user profile.

FIG. 30 is a schematic illustration of a project creation process.

FIG. 31 and 32 are illustrations of the project creation form.

FIG. 33 is an illustration of a notification about a created project.

FIG. 34 is an illustration of a user access screen for a project.

FIG. 35 is an illustration of a project responsibilities notice.

FIG. 36 is a schematic illustration of a budget maintenance process.

FIG. 37 is an illustration of a high level budget entry form.

FIG. 38 is an illustration of a form for inputting funds allocation dates.

- 2 015056

FIG. 39 is an illustration of an account code setting form.

FIG. 40 is an illustration of an account code assignment form.

FIG. 41 is an illustration of a project acceptance notice.

FIG. 42 is an illustration of a project acceptance form.

FIG. 43 is an illustration of a notification of a rejected project.

FIG. 44 is an illustration of a notification of an accepted project.

FIG. 45 is an illustration of a screen of a project home page.

FIG. 46 is an illustration of a user add notification.

FIG. 47 is an illustration of a user access form for a project.

FIG. 48 is an illustration of a project responsibilities notice.

FIG. 49 is an illustration of a screen for presenting a project budget.

FIG. 50 is an illustration of a budget entry form.

FIG. 51 is a schematic illustration of a process for terminating a budget item.

FIG. 52A is an illustration of a high level budget entry form.

FIG. 52B, 52C are illustrations of a budget editing form.

FIG. 52Ό - illustration of the project home page.

FIG. 53 is an illustration of a budget termination screen.

FIG. 54 is a schematic illustration of a disbursement process.

FIG. 55 is an illustration of a notification about the creation of a planned allocation of funds.

FIG. 56A-56C are illustrations of a form for initiating a disbursement of funds.

FIG. 56Ό - illustration of the project home page.

FIG. 56E is an illustration of participants included in a disbursement notice.

FIG. 57 A, 57B are illustrations of an account entry notification.

FIG. 57C is an illustration of a screen for presenting all messages.

FIG. 58A, 58B are illustrations of an invoice entry form.

FIG. 58C is an illustration of a notification of a submitted invoice.

FIG. 59 is an illustration of an account signature notification.

FIG. 60A is an illustration of a presentation screen of a pending allocation request.

FIG. 60B is an illustration of a document signature screen.

FIG. 60С, 60Ό - illustrations of the form of an automatically generated account.

FIG. 60E is an illustration of a signed invoice.

FIG. 60E is an illustration of a signature audit report.

FIG. 600 is an illustration of a notification of a signed document.

FIG. 61 is an illustration of a notification of updated invoice details.

FIG. 62 is an illustration of a screen for presenting a pending allocation request.

FIG. 63 is an illustration of a notification of rejected invoice details.

FIG. 64A is an illustration of an account not included in a disbursement notice.

FIG. 64B is an illustration of an invoice entry form.

FIG. 64C is an illustration of the project home page.

FIG. 64Ό - illustration of a notification of a submitted invoice.

FIG. 64E is an illustration of an invoice approval form.

FIG. 64E is an illustration of a presentation screen.

FIG. 640 is an illustration of the notification of approved accounts.

FIG. 65 is an illustration of an automatically generated invoice form.

FIG. 66A is an illustration of a form of automatically generated affidavit statement.

FIG. 66B is an illustration of a sending signer screen.

FIG. 66C is an illustration of a notification of a sent signing account.

FIG. 66Ό - illustration of the project home page.

FIG. 66E is an illustration of a document signature screen.

FIG. 66E is an illustration of a form of automatically generated non-retention failure.

FIG. 660, 66H - illustration of a signed waiver of deduction,

FIG. 661 is an illustration of a notification of a signed invoice.

FIG. 661 is an illustration of a document signature screen.

FIG. 66K is an illustration of a form of automatically generated non-retention failure.

FIG. 66b is an illustration of a signed waiver of retention.

FIG. 66M - illustration of a document signature screen.

FIG. 66Ν - illustration of a form of notarization of a signed waiver of deduction.

FIG. 660 is an illustration of a notarized refusal to withhold.

FIG. 66P is an illustration of a notification of a signed document.

FIG. 67 is an illustration of a notice of completion of funds available.

- 3 015056

FIG. 68A is an illustration of a disbursement request presentation screen.

FIG. 68B is an illustration of a hold rejection request screen.

FIG. 68C - illustration of the project home page.

FIG. 68Ό is an illustration of a notification of requested waiver refusals.

FIG. 69A is an illustration of a non-deduction signature notification.

FIG. 69B is an illustration of a project homepage.

FIG. 69C is an illustration of a document signature screen.

FIG. 70A and 70B are illustrations of a form of automatically generated hold refusal.

FIG. 70C is an illustration of a signed waiver of retention.

FIG. 70Ό - illustration of a document signature screen.

FIG. 70E is an illustration of a notarization form of a signed waiver of retention.

FIG. 70E is an illustration of a notarized refusal to withhold.

FIG. 700 is an illustration of a notification of a signed document.

FIG. 71 is an illustration of a notification of a signed waiver of withholding.

FIG. 72 is an illustration of a screen for presenting a request for disbursement of funds.

FIG. 73A is an illustration of a signature notification of all withholding waivers.

FIG. 73B is an illustration of a presentation screen of all messages.

FIG. 74A and 74B illustrate a presentation form for a disbursement request.

FIG. 75A and 75B are illustrations of a payment notification.

FIG. 75C - illustration of the project home page.

FIG. 75Ό - illustration of a page for receiving a payment for a disbursement of funds.

FIG. 76 is a schematic illustration of the tasks of maintaining system screens.

FIG. 77 is an illustration of a form for maintaining phase codes.

FIG. 78 is an illustration of a user login administration screen.

FIG. 79 is an illustration of a form for adding / editing a selection list.

FIG. 80 is an illustration of a form for adding / editing an organization role.

FIG. 81 is an illustration of a default job form / configuration settings.

FIG. 82 is an illustration of a notification editing form.

FIG. 83 is an illustration of a default job / process configuration form.

FIG. 84 is an illustration of a form for adding / editing a user role.

FIG. 85 is a schematic illustration of inspection processes and related tasks.

FIG. 86 is an illustration of a notice of preparation for an inspection.

FIG. 87 is an illustration of an inspection requirement notification.

FIG. 88 is an illustration of the screen of the required inspection.

FIG. 89 is an illustration of an inspection report input notification.

FIG. 90 is an illustration of an inspection report entry form.

FIG. 91 is an illustration of an inspection report input screen.

FIG. 92 is an illustration of a notification of an unsuccessful inspection report.

FIG. 93 is an illustration of a display screen of previous inspections.

FIG. 94 is a schematic illustration of an approval process for a disbursement request.

FIG. 95 is an illustration of the One Allocation Request Authorization form.

FIG. 96 is an illustration of a denial of Authorization Allocation Request Denial notification.

FIG. 97 is an illustration of a confirmed inspection notification.

FIG. 98 is an illustration of a notification of modified payment details.

FIG. 99 is an illustration of an authorized inspection notice.

FIG. 100 is an illustration of a Disbursement Request Authorization notification Two.

FIG. 101 is an illustration of an Authorization Allocation Request Form Two.

FIG. 102 is an illustration of a notification of a rejected Fund Allocation Request Authorization Two.

FIG. 103 is an illustration of a notification of authorized Disbursement Request for Authorization of Funds Two.

FIG. 104 is an illustration of a notice of refusal of withholding.

FIG. 105 is a schematic illustration of a change request process.

FIG. 106 is an illustration of a change request form.

FIG. 107 is an illustration of a notification of a change request issued.

FIG. 108 is an illustration of a change request authorization notification.

FIG. 109 is a schematic illustration of a change request processing process.

FIG. 110 is an illustration of a display screen of a pending change request.

FIG. 111 is an illustration of a change request authorization form.

FIG. 112 is an illustration of a notification of a rejected change request.

FIG. 113 is an illustration of a notification of an approved change request.

FIG. 114 is a schematic illustration of a project participant changing process.

FIG. 115 is an illustration of a member change screen.

FIG. 116 is an illustration of a member deletion verification screen.

- 4 015056

FIG. 117 is an illustration of an affidavit change screen (affidavit).

FIG. 118 is a schematic illustration of the tasks of maintaining project screens.

FIG. 119 is an illustration of a project profile form.

FIG. 120 is an illustration of a project contact information screen.

FIG. 121 is an illustration of a project information screen.

FIG. 122 is an illustration of a project closing screen.

FIG. 123 is a schematic illustration of access screen control tasks.

FIG. 124 is an illustration of a login screen.

FIG. 125 is an illustration of an exit screen.

FIG. 126 is an illustration of a screen of a project home page.

FIG. 127 is an illustration of a password reset screen.

FIG. 128 is an illustration of a main screen for a specific user.

FIG. 129 is an illustration of a project view screen.

FIG. 130 is an illustration of a forgotten password screen.

FIG. 131 - Illustration of a notification about your password.

FIG. 132 is a schematic illustration of a message screen management process.

FIG. 133 is an illustration of a message presentation screen.

FIG. 134 is an illustration of a particular message displayed by the user.

FIG. 135 is an illustration of a message creation / sending screen.

FIG. 136 is an illustration of a status message screen.

FIG. 137-153 are flowcharts illustrating a method of controlling a payment process in construction, in accordance with another embodiment of the invention.

FIG. 154-179 input / output diagrams illustrating a method for controlling a payment process in construction, in accordance with yet another embodiment of the invention.

FIG. 180 is a schematic illustration of a construction payment management system in accordance with another embodiment of the invention.

FIG. 181 is a schematic illustration of data managed by a payment management system in construction of FIG. 180 for document tracking in accordance with one embodiment of the invention.

FIG. 182A is an illustration of a document request page.

FIG. 182B is an illustration of a document claim notification.

FIG. 182C is an illustration of a notification of a modification to a document requirement.

FIG. 183 is an illustration of a project homepage.

FIG. 184 is an illustration of a document status summary page.

FIG. 185A is an illustration of a single document status page.

FIG. 185B is an illustration of a version for viewing only a single document status page.

FIG. 185C - illustration of the project home page.

FIG. 186A, B — illustrations of the document submission pages.

FIG. 187 is an illustration of a notification of a filed document.

FIG. 188 is an illustration of a project homepage.

FIG. 189 is an illustration of a document receipt notification.

FIG. 190 is an illustration of a notification of updated document information.

FIG. 191 is a flowchart illustrating a method for identifying expired documents in accordance with one embodiment of the invention.

FIG. 192 is an illustration of an expiration warning notice.

FIG. 193 is an illustration of a notice of expiration.

FIG. 194 is an illustration of a notification of the need for an updated document.

FIG. 195A is an illustration of a late payment notification.

FIG. 195B is an illustration of a screen for presenting all messages.

FIG. 196 is an illustration of a notice of payment to be detained.

FIG. 197A, B are illustrations of a payment management page.

FIG. 198A, B are illustrations of a payment management page.

FIG. 198C is an illustration of a payment page.

FIG. 199 is an illustration of a project homepage.

FIG. 200 is an illustration of a payment management page.

FIG. 201 is an illustration of a notice of spent funds.

Before proceeding to a detailed description of embodiments of the invention, it should be noted that it is recognized that the invention is not limited to the structural details and arrangement of the components disclosed in this description or presented in the respective figures of the drawings. The invention can be made in accordance with other variants of implementation and can ensure the achievement of the result in various ways. In addition, it is obvious that the phraseology and terminology used in these materials are for description purposes and cannot be

- 5 015056 gut to be construed as limitations.

The use of expressions including, containing or having and their varieties in these materials is intended to cover the elements listed after them, as well as their equivalents and additional elements.

The terms established, connected and connected are used in a broad sense and cover both direct and indirect installation, connection and communication. Furthermore, connected and connected are not limited to physical or mechanical connections or connections, and may include electrical connections and connections, direct and indirect. In addition, electronic communications and notifications can be performed using any known means, including direct connections, wireless connections, etc.

It should be noted that for the implementation of the invention, you can use many hardware and software-controlled devices, as well as many different structural components. In addition, as described below, the specific configurations presented in the figures of the drawings are intended to illustrate embodiments of the invention, and other alternative configurations are possible.

In FIG. 1 is a schematic illustration of a building payment management system (EMS) 10 in accordance with one embodiment of the invention. SPMS 10 may include an application server 12, a database server 14, an application logic module 16, a web server 18, a network 20 (such as the Internet or other networks separately or in conjunction with the Internet), a verification service 22, participating organizations or individuals 24 (hereinafter referred to as a participant or organization) and payment system 26. Payment system 26 may include an automated clearing house (ATM) system, a bank transfer system, a debit card system, a credit card system, a check generation system that can generate checks, drafts, bills of exchange, promissory notes, promissory notes, debit notes or other negotiable instruments or any other suitable system of electronic transfer of funds (EPF).

The application server 12 can save the project module 28, the form management module 30, the permissions and authorization device 32, the database management system 34, the budget module 36, the access manager 38, the notification manager 40, the organization module 42, the funds allocation module 44, the contract module 46 , change order module 48, user module 50, system environment administrator 52, and an electronic intermediate hopper / escrow facility 54. The disbursement module 44 may include a main module 56, an inspection module 58, and a disbursement approval module 60. The system environment administrator 52 may include a message (report) generator 62, a help module 64, and a system maintenance module 66. The electronic intermediate hopper / escrow facility 54 may store one or more hold failures 68. It is obvious that the components of the application server 12 can be combined in a different way than shown and described with reference to FIG. 1. The software used to encode the various modules, dispatchers, and devices of the application server 12 may be combined or distributed in any suitable manner, it may be stored, and access may be made to it in any suitable manner.

Application server 12 may be connected to database server 14, application logic module 16, and verification service 22. However, in some embodiments, the verification service 22 can only be connected to the network 20. The application logic module 16 can be connected to the web server 18 or, in some embodiments, directly to the network 20. The web server 18 can be connected to the network 20.

Participants 24 may include the owner of the property 70 (and / or the representative of the 72 owner), the general contractor (GP) 74, the inspector 76, one or more subcontractors (subcontractor A 78, subcontractor B 80, etc.), one or more suppliers of 82 materials, one or more lenders 84 (and / or one or more officers 86 of the lender), one or more title companies 87 and one or more architects 88. Participants 24 may also include one or more interior designers (and / or made Itel furniture), one or more real estate owners (ie. e. the land owner who sells construction site owner property 70) or one or more engineers. Participants 24 may include organizations and / or individuals who are considered above the line (i.e., higher during construction than GP) or below the line (i.e. hired by the GP). Participants 24 above the line may include lenders, architects, interior designers, property owners, representatives of property owners, title companies and real estate owners. Participants 24 below the line may include subcontractors and material suppliers. EMSS 10 can be used to facilitate the payment process in construction between any of these types of participants 24, above or below the GP line. EMS 10 is often described in these materials as being used to facilitate payment between SOEs and subcontractors. However, it is obvious that EMSS 10 can be used to facilitate payment between any types of participants, and not just between SOEs and subcontractors.

- 6 015056

In addition to classifying participants as being above or below the GP line, the costs associated with the construction process can be classified as soft costs or hard costs. Soft costs may include paying an inspector, paying an architect, paying for an interior plan, paying a title company, paying permission, utility bills for the property during the construction process, furniture, audio / visual equipment, computers, etc. Solid costs may include all costs incurred by organizations or individuals hired by SOEs, including all costs of subcontractors and suppliers of materials hired by SOEs. Each construction project may include a full budget (from the point of view of the owner), which includes all soft and hard costs. Each construction project may also include a GP budget. EMS 10 can be used to facilitate all payments made within the full budget and the budget of the SOE. However, in some embodiments of the invention, the EMS can only be used to facilitate payment of the fixed costs regulated by the SOE (i.e., only by the SOE budget). It is obvious to the average person that EMSS 10 can be used to facilitate payment only at the fixed costs of SOEs, only at soft costs by participants above the SOE line or a combination of hard and soft costs by participants above and below the SOE line. EMS 10 is often described in these materials with respect to hard costs, but can also be used for soft costs or a combination of hard and soft costs.

Each participant 24 may be associated with a payment system 26; however, some of the participants 24 may not be associated with the payment system 26 in some embodiments of the invention. In some embodiments, the payment system 26 may include an ATM system with one or more initiating depository financial institutions (IDFs) and one or more receiving depository financial institutions (IDFs).

Participants 24 can access the application server 12 to use various modules, administrators, and blocks to implement payment management methods in construction in accordance with several embodiments of the invention.

In some embodiments, the EMS 10 can connect all project participants with a substantially homogeneous real-time network system; can organize budgeting for a construction project; can facilitate the submission and approval of invoices electronically; and can automate and simplify the process of payment and issuance of a denial of deduction by using electronic payments and electronically issuing the corresponding denial of deduction.

Although there may be changes in the details (for example, in a publicly funded project, the initiation of the project and the supervision of it can be performed by the issuer of the guarantee, and not by the bank), one of the options for implementing the EMS can be used as follows. A loan (loan) officer can access the Internet and access the EMS system. After checking for permission, the loan officer can enter the portfolio of the lender and gain access to a number of screens to create a new project by entering all the details of the project. Project details may include details on the participants for each project, for example, by owner, architect, general contractor and title insurance company. Each participant can receive an email notification of their involvement in the project and can check the details of their profile. GP can add subcontractors and material suppliers. Subcontractors and material suppliers may be notified that they have been added to the project and may go through the verification and access process. The SOE can choose the amount of funds allocated and the dates of funds allocated for the project. The SMSS 10 may notify participants in real time of an upcoming allocation date. Each of the participants can fill out its request for allocation of funds by entering the details of their accounts for materials and labor. The SOE may consider requests for allocation of funds and resolve them, and EMS 10 may work out a sworn statement. Then a series of inspections of the construction site, approvals, withdrawals of refusals from withholding, development of applications, etc., which can be made reminders to EMS 10 through real-time email notifications, can follow. Once all forms are completed and verified, EMS 10 can ensure that payments are made. Payments can be deposited directly to a member’s bank account through an electronic payment system. This process can be repeated for all disbursements. The project budget can be maintained in balance by making payments, collecting refusals to withhold, and approving inspections. Project progress can be monitored using EMS 10 through graphical progress indicators.

EMS 10 may have the following features: one-time registration of participating organizations in EMS 10; real-time notification of the allocation of funds; automated bill generation; automated sworn statement; automated generation of non-retention; coordinated payment / resolution of non-retention and direct allocation of funds to participating organizations.

- 7 015056

Single registration of participating organizations in EMS 10 can lower the cost of participation in the service, because the participant must register only once. One-time registration also reduces the number of potential errors, since the registration information should be entered only once. This makes it more likely that potential participants will actually participate and when they do participate, they will get a good (error free) result. A one-time registration allows you to ensure that the party who wants to be a participant in the process and the online community using the process need to register once in order to be able to participate in any of the projects that are paid through SMS 10. SMS 10 can improve registration efficiency participating organizations in the payment process in construction by creating a sustainable community that facilitates the process of participation over time in numerous projects, through a single collection of information Information about the organization and personal information. The method allows organizations to be registered as a potential participant in any project that is initiated by a member of the community of business entities using EMSS 10. In addition to its importance when participating in numerous projects, one-time registration is also valuable for participants when accessing information regarding numerous SOE owners, lenders subcontractors etc. For example, one-time registration gives owners, lenders and SOEs the opportunity to learn about new subcontractors through EMS 10.

In some embodiments, the implementation of the SPMS user 10 may use the SPMS 10 to search for organizations available to contract for a specific project. For example, EMS 10 can generate messages that contain a list of organizations related to specific project tasks related to specific geographical areas, etc. EMS 10 can also provide information (for example, ratings, experience, contact information, etc.) for organizations registered in the system, which the user can use to make an informed decision about the organizations involved under contracts for the implementation of the project. EMS 10 may also provide a list of preferred or recommended organizations based on the history of the organization managed by EMS 10 and / or reviews or comments submitted by other organizations in EMS 10.

In some embodiments, participants can also develop their own list of preferred organizations, which can only be accessed by the participant who created the list, or made available to other participants using EMS 10 and / or used EMS 10 when creating ratings or ranking for registered organizations. In addition, an owner with several projects to be completed, each with a different SOE, can access information about each individual SOE.

A real-time notification of the allocation of funds allows us to ensure that all participants in the allocation of funds: 1) are notified in a timely and uniform manner and 2) are provided with a template for providing the information necessary for payment. EMS 10 helps to eliminate errors (without notice or confusion about which project the request came from) that delay the payment process. The EMSS 10 improves the efficiency of real-time notification of the process of allocating funds, giving the SOE the ability to maintain a schedule for allocating funds to the EMSS 10 by reducing the effort spent on notifying the participants in the allocation of funds, by automating the process of building a list of participants for the allocation of funds, by automatically notifying the allocation participants disbursement funds, as soon as it was announced, by providing easily accessible links so that subcontractors can receive have access to the EMS 10 to present the documentation required for the allocation of funds. The EMSS 10 notifies participants in real time, in the sense that timeliness is an essential aspect of its correct behavior. Therefore, EMS 10 works in real time to the extent that it meets its time requirements (for example, deadlines). In other words, the EMS 10 makes the notification available to all participants as quickly as possible after the allocation of funds is initiated. Although the participant may not have access to the notification as soon as it becomes available (for example, it may not have access to the SMS 10), through SMS 10 the allocation information is made available to all participants. The real-time notification provides each participant with timely access to disbursement information as soon as the information becomes available. It should be understood that a real-time action is not the same as an online action, or visible through a web page, or a really fast action. Time issues embodied in deadline, time frame or time limit requirements are typically application dependent. They are not just a function of bureaucratic delays, network bandwidths, processor speeds, or which browser, server, or network programming language they use to create a human-machine interface or user interface. Although these things can influence the time factor in the process, they do not provide ways to actually manage the resources needed to meet the time requirements.

- 8 015056

EMS 10 can be used by the owner, representative of the owner, lender, SOE or title company to create and maintain the project budget. As noted above, the project budget may include soft costs above the SOE line, solid costs below the SOE line, or a combination of hard and soft costs. In some embodiments, participants may also use the EMS of 10 to approve the budget. For example, the owner can approve the budget created by the subcontractor, the GP can approve the budget created by the subcontractor, and / or the subcontractor can approve the budget created by the subcontractor with which the subcontractor has a contract, etc. Some of the SPMS 10 implementations can also be used to create and manage change orders that change the budget (usually expanding the budget), and the changed budget is approved by the relevant participants. The budget may include the total cost for the construction project, along with the costs of the articles for each phase or work that must be completed to complete the construction project. EMS 10 can structure the budget to facilitate subcontractor payments to enable efficient tracking of progress and automated billing.

EMS 10 can create automated accounts that exactly correspond to the full project budget and also exactly correspond to refusals of withholding and affidavits. The EMSS 10 automatically creates invoices, which in time are snapshots of activities that have already taken place in relation to the full project budget. EMS 10 can be used to create accounts in an automated way that exactly match the items in the full budget. This leads to the formation of accounts and messages that are consistent with the way in which the construction project is presented for financial purposes, for tracking purposes, etc. When using EMS 10, the account screen can be used to enter the information necessary to create an account; however, not all of the information necessary to create an account must be re-entered, because the information can be collected by referring to the full project budget. This also ensures that the accounts (and documents 0702/703) are aligned with the full project budget and agreed between the disbursements or any other time periods (unless the participant, such as the owner, wants the accounts to change). EMS 10 can also be used to set up automatically prepared (automated) accounts (or documents 0702/703) in accordance with the requirements of the lender, owner, representative of the owner, SOE, etc.

Budget and automated accounts can be used to uniformly collect and continuously provide links to information that will be used throughout the payment management process in construction. The collected information does not need to be re-entered during the payment process, which ensures that no errors will be made (due to incorrect keystrokes or incorrect interpretation of data). Typically, participants are provided with visibility in the payment process using SMSS 10. This helps to reduce the effort required to determine the status of the project and understand what work each participant should do to facilitate the payment process. It also helps highlight organizations or personalities that can usually introduce delays or errors in the process, making it easier to correct the behavior or eliminate the participant. Accurate invoicing minimizes efforts to permit review and billing, helps to make complete and accurate affidavits, minimizes inconsistencies between affidavits and inspections, and enables timely payments. EMS 10 can increase the effectiveness of several actions later in the payment process in construction by ensuring the timely input of complete and consistent account information.

EMS 10 can be used to automatically generate (automated) affidavits and automatically (automated) refusals to withhold. Using SMSS 10, the GP knows who has been notified of the allocation of funds and who responded by providing an invoice. Once the accounts are approved by the SOE (and by any other party above the SOE line, such as the owner, owner’s representative, lender, title company, etc., who must approve the accounts), EMS 10 can use the approved accounts to automatically generate a sworn statement and refusals to hold, as well as other documents under other names that provide the same functionality (for example, statutory declarations). The EMSS 10 can automatically generate a sworn statement and refusal to withhold bills submitted by subcontractors and material suppliers, ensuring that no typos are made and that a sworn statement and refusal to withhold will include only articles submitted by subcontractors and material suppliers. The EMSS 10 may reduce the risk of oversight in the application under oath and refusals of withholding by involving account details already stored in the system to automatically create the contents of the application under oath and withholding refusals. This processing helps to eliminate errors that are possible due to non-standard, inconsistent and untimely accounts and typos that may occur during rewriting or reprinting. In general, this lowers the risk profile of the payment process in construction by increasing the accuracy and timeliness of critical information for a construction project. EMS 10 allows you to create automated rejection of udder

- 9 015056 building in accordance with the current legal standards of the places where the construction site is located.

EMS 10 allows you to generate affidavit statements that exactly match the accounts. Accounts are often broken down by type of work being performed (e.g., electrician, plumbing, etc.), while affidavits are often broken down by job participants (e.g., GPs, subcontractors, and material suppliers). EMS 10 can be used to ensure that the sum of the values in the account is equal to the total amount upon application under oath. In addition, SPMS 10 can also be used to ensure equality of values for non-deduction of deductions from account amounts, since information for automated non-deduction of deductions is collected from approved accounts, which are stored in SPSS 10. Additionally, denial of deductions will be compatible with the sworn statement since the sworn statement was also developed by the EMS 10 using the information on the approved accounts. This is especially valuable when SOEs and subcontractors (or owners, the lender and SOEs) disputed the invoice amount and agreed on the final amount after a period of time. The final value will be reflected in the automated and approved account, which is stored in the EMS 10 and is used to generate refusals of deduction and a sworn statement. The EMSS 10 guarantees that only the approved value of the invoice will be reflected in the documents of the affidavit and refusal of deduction. Also using the saved budget as the framework for all automated documents, EMS 10 further ensures that accounts, refusals of deduction and affidavits are accurate and consistent. SPMS 10 can also be used to set up accounts, affidavits and refusals to withhold based on the requirements of the lender, owner, representative of the owner, SOE, etc. In some embodiments, a participant may use EMSS 10 to add text to a non-hold. For example, the SOE may add additional safeguards to non-retention for projects where specific laws (for example, as required by the region or state with which the project is associated) make retention retention unconditional by law. In some embodiments, participants can also use EMSS 10 to identify and / or manage additional types of documents or information, such as affidavit, which include a table of suppliers and parties associated with the project. In addition, participants can introduce or define for the EMS 10 forms of ownership that participants can use for specific projects, organizations, etc.

The EMSS 10 also helps to increase the efficiency of the development of affidavits and refusals of deduction by migrating the saving of invoice documents, the affidavits and refusal of deduction in an electronic environment with the reduction of time and effort required to maintain and provide access to them. This increases the overall efficiency of the payment process in construction by fulfilling these documents available to authorized parties who need them to fulfill their responsibilities. The EMSS database 10 may store a library of electronically signed accounts, affidavits, and withholding denials. If necessary, participants can use EMS 10 to obtain copies of documents for any of the electronically signed documents.

In one embodiment, the EMS can create automated accounts, a sworn statement, and waivers of deduction once all information has been entered and all aspects have been taken into account. In other embodiments, the SMSS 10 may, firstly, create automated accounts, ensure the approval of accounts, secondly, create an automated affidavit, ensure that the affidavit is signed, and thirdly, create automated denial refusals.

As soon as all information (invoices, inspection reports, banking information, etc.) has been entered and all aspects have been taken into account, the owner, representative of the owner, lender, title company or SOE can pay the participants for the allocation of funds.

In some embodiments, payment to participants may be made directly by the owner, representative of the owner, lender, title company or SOE.

In other embodiments, payment to each member may be made indirectly through the member who directly employed each member. For example, if a first-level subcontractor was hired by a GP and a first-level subcontractor hired a second-level subcontractor, a GP can pay a first-level subcontractor for work performed by a first-level subcontractor and a second-level subcontractor, and a first-level subcontractor can pay a second-level contractor.

Subcontractors, material suppliers, or any other parties may secure their waivers of deduction in exchange for payment. The EMSS 10 can organize this process and can automatically execute the exchange without the risk that either side will fulfill its part and the others will not fulfill theirs. EMS 10 also helps to eliminate the need for expensive and time-consuming meetings to facilitate the exchange of withholding denials. EMS 10 (which strictly monitors documents) also helps ensure that all retention refusals are collected. This reduces the risk that the bad

- 10 015056 record keeping will lead to the absence of withdrawal of refusals from withholding at the completion of the construction project, EMS 10 can increase the efficiency of the process of making payments / resolving refusals from withholding by implementing the method in a network computer system. This allows all parties to reliably prepare both the payment and the resolution of the refusal to withhold in a confidentially implemented environment. EMS 10 provides an effective exchange of payment for waiver of deduction, because SMS 10 allows for multi-stage preparation of payment and waiver of deduction for automated exchange, thereby reducing the risk associated with the project. The SOE can be sure that it will receive the corresponding refusals of withholding, which coincide with the payment, and that the subcontractors will not take risks, due to long delays in the payment.

EMS 10 can facilitate the exchange of withholding denials and payment orders. In some embodiments, the implementation of the EMSS 10 may remove the refusal (s) to withhold substantially simultaneously with the confirmation from the payment system 26 that the participant (s) has received the payment (s). The term is essentially simultaneous, in the sense as used in the present description and claims, includes any period of time shorter than the time required to request, process and transfer funds when paid by an automated clearing house (ATM) (which may take up to approximately 72 hours). For example, essentially simultaneously withdrawing waivers from holdings may include immediately withdrawing waivers from holding, removing a package of waivers from holding at the end of a business day, or removing waivers from hold after a typical period of time required to transfer funds through the ATM system.

In one embodiment, the EMS can 10 receive and save the denial of retention in the electronic intermediate hopper / escrow facility 54 until all retention denials from the disbursement participants are received. Once all lien waivers have been received, EMSS 10 may send instructions to payment system 26 for transferring funds to each disbursement participant. For example, as soon as all subcontractors have electronically signed and submitted their refusals to withhold SMS 10, SMS 10 may instruct payment system 26 to pay each subcontractor. The SMSS 10 can withdraw the refusals of withholding either when the payment order has been transferred to the payment system 26, or only after receiving confirmation that the participants actually received the capital.

If payment system 26 includes an ATM system, payment orders are usually processed in batches so that participants do not receive funds immediately. In the ARP system, a payment order can usually be returned to PFDU within a 48-hour period. During this 48-hour period, PFDU can notify EMSS 10 and IDFU that funds cannot be transferred (for example, due to insufficient funds, invalid account numbers, etc.). After this 48-hour period, the SMSS 10 may assume that the PDFS has processed the payment order, unless the SMSS 10 is notified otherwise. IDFU usually has a 24-hour border for collecting payment orders from PFDU and making payments on the accounts of participants in the allocation of funds. As a result, approximately 72 hours may elapse from the time when the SMSS 10 transfer payment orders until the transfer of the IDFU of the funds to the accounts of the participants.

In some embodiments, the implementation of the SMSS 10 may retain hold refusals even after receiving confirmation from the payment system 26 that the participant (s) has received (s) a payment. For example, EMSS 10 may retain hold refusals until the 31st day or until the next disbursement is initiated.

In some embodiments, the SMSS 10 may mark certain participants to remove these participants from the batch processing of the ATM system and may pay these participants separately in another way, such as direct transfer of funds, or using another type of instant electronic transfer of funds.

In other embodiments, for most participants, payment can be made by the type of instant electronic transfer of funds (such as direct transfer), and some participants can be combined for one or more package transfers of ATMs.

In other embodiments, the SMSS 10 may transmit each payment order to the payment system 26, as soon as the SMSS 10 receives each refusal to withhold from each participant, and the funds can be immediately transferred to the participant from whom the refusal to withhold was received. Typically, SMSS 10 can group payment orders in any suitable manner and can use any suitable type of payment method.

In each embodiment of the invention, the SUMS 10 may establish a relationship between the current denial of deduction and the current payment corresponding to the current allocation of funds instead of exchanging the previous denial of deduction for the current payment of the current allocation of funds. For example, EMSS 10 may remove a deduction from deduction for the current month for the current allocation of funds instead of allowing denying deduction from deduction for the previous month for the current allocation of funds. Thus, the subcontractor is not liable if the EMSS 10 removes his refusal to withhold payment, and the owner (or SOE, title company, lender, etc.) is not liable if EMSS 10 makes the payment before like hold refusals

- 11 015056 removed.

Instead of making payments to SOEs that pay their subcontractors, who then pay their subcontractors, EMSS 10 participants can pay directly using the electronic distribution of funds (for example, any suitable type of EPF, ARP or bank transfer of funds). This speeds up the payment process (reducing costs) and reduces the risk of non-payment to parties (hierarchy). Direct distribution of funds is made possible by the EMS 10, used to collect all the information that is necessary to make payments. Information collected using EMS 10 can be trusted due to the rigor with which the methods can be implemented by software. As a result, the direct distribution of funds can be efficient (no alterations or re-entry of the necessary information is necessary) and free from errors.

EMS 10 can improve the efficiency of the subcontractor / material supplier payment process, reducing the time required to complete the payment process;

reduce operating costs by replacing the hierarchical process of payment with direct payments, while improving financial and administrative management;

replace the use of checks by electronic transfer of funds, reducing communication costs and improving the visibility of payment status, as well as reducing the risk of late or incomplete payment to all parties involved in the construction process (especially grassroots for supply purposes).

In FIG. Figures 2-7 provide a brief overview of payment management processes in construction that can be performed by participants 24 using various modules, administrators, and machines stored on application server 12.

In FIG. 2 illustrates a project management process 94 (which may be performed by a project module 28 and / or a budget module 36), a disbursement management process 96 (which may be performed by a disbursement module 44), a change order management process 98 (which may be performed by a module 48 of the change order management), organization management process 100 (which may be performed by organization module 42 and / or user module 50), system environment management process 102 (which may be performed administratively access rum 38, administrator 40 notifications and / or administrator 52 system environment).

In FIG. 3 illustrates a project management process 94, which may include a project creation task 104, a project maintenance task 106, and a budget creation task 108.

In FIG. 4 illustrates an organization management process 100, which may include an organization creation task 112, an organization maintenance task 114, a user creation task 116, and a user maintenance task 118.

In FIG. 5 illustrates a disbursement management process 96, which may include a disbursement initiation task 120, a disbursement request creation task 122, a fund spending task 124, an inspection task 126, and a disbursement request approval task 128.

In FIG. 6 shows a change order management process 98, which may include a change request creation task 130, a change request processing task 132, and a participant change task 134.

In FIG. 7 illustrates system environment management tasks 102, which may include access control task 136, message management task 138, report generation task 140, assistance task 142, and system maintenance task 144. Reporting task 140 can be performed by any participant above or below the GP line in order to create specially formed messages regarding the progress of the construction project, including the ability to control parts of the construction project, specific participants, a complete draft of documents submitted by the participants, etc.

In FIG. 8-136 and 182A-201 illustrate payment management methods in construction in accordance with several embodiments of the invention.

In FIG. 8 illustrates an organization creation process 146, which may be included in an organization management process 100. The organization creation process 146 may be performed by any of the participants 24 using the organization module 42. The organization creation process 146 may include an organization creation task 148, an organization profile update task 150, an organization editing task 152, an organization notification activation task 154, an organization activation task 156, and either an organization rejection task 158 or an activated organization task 160. The user profile update task 162 can also be performed as described below with reference to FIG. 22.

- 12 015056

In FIG. 9 shows a form of creating an organization that can be associated with task 148 of creating an organization. Each participant 24 can access the organization creation form through the organization module 42. Member 24 may enter in the required information, such as business information, primary contact information, tax information and banking information.

In some embodiments, the first user of the participating organization 24, who enters their information as primary contact information, can be considered an administrator for that participant 24 and can be given more access to the information for the participant than subsequent users. EMS 10 can use comprehensive role security so that project participants see only information that matches their specific project needs. As soon as an organization is registered in EMS 10, this organization can receive payments for any projects managed by EMS 10.

In FIG. 10, a notification is provided that may be transmitted during a user profile update task 162. The terms system notification or notification, or system message, as used in the present description and claims, refer to any form of communication with the participant 24, such as email, screen notification, text message, voice message, etc. in FIG. 10 may include a username and a temporary password for the first user of member 24.

In FIG. 11, a notification is provided that may be transmitted during task 150 of updating an organization profile. The notification of FIG. 11 may be sent to the administrator for participant 24. The notification may include a statement requiring the recipient to update the organization profile, add users before participating in the project, and provide information about the bank.

In FIG. 12 shows an organization editing form that may be associated with an organization editing task 152. Each participant 24 can access the organization editing form through organization module 42. Member 24 may modify existing information such as business information, primary contact information, tax information, and banking information. In some embodiments, the first user of the participating organization 24, who entered his information as primary contact information, is the only user who has access to the editing form of the organization.

In FIG. 13 provides an organization activation notification, which may be transmitted during an organization activation notification task 156. The notification of FIG. 13 may include a statement that the details of the organization have been updated, and a request for confirmation and activation of the organization.

In FIG. Figure 14 shows an organization activation form that may be associated with organization activation task 156. The form of FIG. 14 may include a list of participants 24 (for example, including the name of the organization, its role in the construction process, the ability to select participants 24, and the ability to view information for participants 24). The form of FIG. 14 may also include the Find feature, the ability to determine the type of participant 24, and the ability to reject / deactivate selected organizations and provide a reason for rejection / deactivation.

In FIG. 15 provides a notification of an activated organization that can be transmitted during task 160 of the activated organization.

Similarly, in FIG. 16, a notification of the rejected organization is presented, which may be transmitted during the organization rejection task 158.

In FIG. 17 shows an organization maintenance process 162 that may be included in an organization management process 100. The process of maintaining the organization 162 can be used directly by organizations or other participants to maintain the accuracy of contact information, bank account information or any other type of information necessary for the payment process in construction. Organization maintenance process 162 may be performed by any of the participants using organization module 42. An organization maintenance process 162 may include an organization review task 164, an organization editing task 166, an updated organization task 168, and an organization presentation task 170.

In FIG. 18 shows an organization presentation screen, which may be associated with an organization presentation task 170. The organization presentation screen may include business information and primary contact information for the organization.

In FIG. 19 shows an organization view screen, which may be associated with an organization view task 164. The organization’s browsing screen may include a list of participants containing the name of the organization, the role of the organization in the construction process, primary contact and phone number. The organization’s browsing screen may include Find and Link functionality to provide additional information about each member. In one embodiment, the organization’s viewing screen may be used by the GP to display its preferred subcontractors or material suppliers.

- 13 015056

In FIG. 20 shows an organization editing form that may be associated with an organization editing task 166. The participant can edit existing information such as business information, primary contact information, tax information and banking information. In some embodiments, the first user of the organization who has entered his information as primary contact information is the only user who is granted access to the editing form of the organization.

In FIG. 21, a notification is presented of an updated organization profile that may be transmitted during task 168 of the updated organization. The notification of FIG. 21 may include information regarding an updated profile for a member along with the name of the primary user or administrator for the member. In some embodiments, notification of an updated organization profile may be sent to all organizations associated with an organization that has updated its profile. For example, if an organization updates its address or Federal Employer Identification Number, EMSS 10 may send a notification about the updated profile of the organization to other organizations associated with system 10. In some embodiments, SMSS 10 sends a notification only to organizations associated with or working with an organization that has updated its information. EMS 10 can send notifications in approximately real time.

In FIG. 22 illustrates a user creation process 172, which may include an organization management process 100.

The user creation process 172 can be used each time a new user is created in an existing organization to provide the new user with appropriate access to the EMS 10 (for example, appropriate security levels with user identification and password). The user creation process 172 can also be used to update user profiles. The user creation process 172 may be performed by any of the participants 24 using the organization module 42. The user creation process 172 may include a user creation task 174 and a user profile update task 176.

In FIG. 23 shows a user creation form, which may be associated with a user creation task 174. In some embodiments, a user creation form may be used to add users after a primary user or administrator has already been created for a member. The new user can enter personal information, security information (for example, username and password), preferences regarding email notification and access authorization levels (for example, whether the user can manage projects and / or sign documents).

In FIG. 24, a user profile update notification is provided that may be transmitted during a user profile update task 176. The notification of FIG. 24 may include a statement that the user has been added as a member of the organization, as well as user security information (e.g., username and temporary password).

In FIG. 25 depicts a user maintenance process 178 that may be included in an organization management process 100 and may continue from FIG. 22. The user maintenance process 178 can be used to view users in each organization and to present, edit, and update users in each organization. The user maintenance process 178 may be performed by any of the participants using the organization module 42. The user maintenance process 178 may include a user viewing task 180 and a user editing task 182, an updated user profile task 184, and a user presentation task 186.

In FIG. 26 shows a user presentation screen, which may be associated with a user presentation task 186. The user presentation screen of FIG. 26 may include user personal information, a preference for email notification, and an access permission check level.

In FIG. 27 shows a user viewing screen, which may be associated with a user viewing task 180. The user viewing screen of FIG. 27 may include a list of one or more users for each member, and may include user names, email addresses, and phone numbers. The user viewing screen may also include links for editing information for each user.

In FIG. 28 is a user editing form that may be associated with a user editing task 182. The user may provide personal information, preferences regarding email notification and access authorization levels.

In FIG. 29, a notification about an updated user profile is presented, which may be transmitted during task 184 of the updated user profile.

In FIG. 30 shows a project creation process 188 that may be included in project management process 94. The project creation process 188 may be performed by the GP, lender, owner or owner’s representative, using the project module 28 to initiate a new project

- 14 015056 that in the EMSS 10. The project creation process 188 may include a project creation task 190, a created project task 192, a user access task for the project 194, and a project responsibilities task 196.

In FIG. 31 and 32, a project creation form is provided that may be associated with a project creation task 190. The SOE, lender, owner or owner’s representative can provide project identification information, project financing information, project owner information, project architect information and site information. In some embodiments, the GP, the lender, the owner, or the owner’s representative can also use the project creation form to specify other options for the project, such as determining whether subcontractors can view the project information and determining document settings (for example, non-retention text, non-retention settings, payment methods, etc.). For example, a SOE, lender, owner or owner’s representative can use the project creation form to define non-retention settings that define the settings for each type of non-retention that will be managed for a particular project (for example, partial non-retention and final non-retention ), such as the withdrawal time for holding bounce. For example, system 10 may remove hold refusals when signing is done, when funds are paid, when subsequent disbursements are initiated, etc. In addition, the GP can use the project creation form or other configuration forms provided by the EMS 10 to configure routes for approving the various stages of the project. For example, a GP can set account limits and / or signature requirements for a specific project.

In addition, the SOE, lender, owner or owner’s representative may use the project creation form or other forms provided by the EMS 10 to define the project as being an open book project or a closed book project. In a GP open book project, the lender, owner, or owner’s representative (e.g., participants above the line) can view details of parts of the project managed by subcontractors and material suppliers (e.g., participants below the line) included in the project. For example, in an open book project, if a subcontractor holding a contract with a SOE creates a secondary budget for one or more retention items attributed to the subcontractor, the SOE can view details of the secondary budget, such as quantities, secondary subcontractors having a contract with the subcontractor, etc. d. In some embodiments, in a GP open book project, the lender, owner, or owner’s representative may require contracts and documents (eg, withholding refusals, contracts, affidavits, etc.) from sub-contractors and suppliers of materials at each level .

In a closed book project, the SOE, the lender, owner or owner’s representative can see only one level down to the first level of subcontractors and suppliers of project materials. For example, in a GP private book project, a lender, owner or owner’s representative can only apply to their own budgets, subcontractors, material suppliers, etc., and first-level subcontractors and material suppliers provide only public sizes and information for a lump sum since the SOE is not authorized to view details of contracts, budgets, accounts, etc. by subcontractors and suppliers of materials.

In some embodiments, participants at each level of the project can determine whether the part of the project they are managing is considered an open book project or a closed book project. In this regard, each participant at each level of the project can view the details of each level of the project below the participant, as long as each level is set as an open book project. If, however, one level of the project is set as a closed book project, the participant can only view details below with respect to the closed book project level and cannot view details beyond the following levels. Based on the project settings set by users, EMS 10 can control and regulate access to information within the project.

In some embodiments, in addition to creating a project, a SOE, lender, owner, owner’s representative, subcontractor, or material supplier can create one or more subprojects within a specific project. For example, in a complex construction project for multiple buildings, a GP can create a subproject for each building. Each subproject may include a separate budget; Separate accounts, affidavits, and waivers; individual project settings; individual participants, etc.

In FIG. 33, a notification about the created project is presented, which can be transmitted during task 192 of the created project. The notification of FIG. 33 may include a statement that the SOE, lender, owner or owner’s representative created a new project, as well as a link to a screen that allows users from the participants to be assigned to the project.

In FIG. 34 shows a project user access screen, which may be associated with a project user access task 194. The user access screen for a project may include a project name, a project number, a GP name, and a list of users for a specific project and / or specific organization. Users can be identified by username and username and can be considered a project manager or signer.

- 15 015056

In FIG. 35, a notice of project responsibilities is presented, which may be transferred during task 196 of the project responsibilities. The notification of FIG. 35 may include a statement that the user's responsibilities regarding the project have been changed.

In FIG. 36 illustrates a budget support process 198 that may be included in a project management process 94. The budget maintenance process 198 can be used to create and present a high-level budget for a construction project, assigning articles to participants, and assigning responsibilities to participants. In some embodiments, the implementation of the PSMS 10 may also allow a user to assign an article to one or more participants or contracts. For example, if a SOE has contracted with three organizations for a specific budget line item, the SOE may designate part of the line item for each organization. In addition, if the SOE or subcontractor requests additional details or sub-tasks within a specific article, the SOE or subcontractor can use EMSS 10 to break the article into multiple articles. SOEs or subcontractors can use EMS 10 to allocate part of the budget, retention, amount or percentage of completed work, payment, etc. from the original article to the new article.

Using the budget module 36, the budget maintenance process 198 can be performed by a GP for subcontractors or by a subcontractor for a second level subcontractor or material supplier. The budget maintenance process 198 may include a high-level budget input task 200, a project adoption task 202, a budget adoption form task 204, a rejected budget task 206, adding users task 208, an accepted project task 210, a project homepage task 211, access task 212 the project user, task 214 of the project responsibilities and task 216 of presenting the project budget. If the project is rejected, the budget maintenance process 198 may include a budget entry task 218 and may return to the project approval task 202. After the high-level budget entry task 200, the budget maintenance process 198 may include an account code setting task 220, an input date allocation task 222, and an account code assignment task 224.

In FIG. 37, a high-level budget input form is presented that may be associated with a high-level budget input task 200. The high-level budget entry form may include the name of the project, the project number and the cost of the contract. SOEs or subcontractors can provide retention percentages, phase codes, descriptions of phase codes, company names, budget values, and bank account codes. The SOE or subcontractor can determine if the organization is only providing materials. The high-level budget entry form may also include links to screens / forms for setting the allocation dates and setting the account code. Phase codes and descriptions of phase codes can be used to determine contractual requirements for each specific work that must be completed to complete a project. Phase codes and phase descriptions can be provided, for example, by the American Institute of Architects (AIA, ΑΙΑ), the Institute for Building Specifications (ISS, C81), or they can be obtained by altering the phase codes and phase descriptions of the AIA or ISS. In some embodiments, phase codes and phase descriptions may be completely redone by participants. Under a high-level budget, you can also understand the list of costs, required costs (after the SOE received proposals from subcontractors) or project evaluation.

In some embodiments, phase codes included in the high-level budget provide a basis for disbursement requests, in which each disbursement request includes specific items related to specific phase codes. In some embodiments, the GP may use an external program to generate a budget, and budget module 36 may interact with an external program to import the budget into application server 12 or database server 14. In some embodiments, a participant can, using EMS 10, create or import a budget template that a user can use when creating a budget for projects.

In FIG. 38 shows a form for inputting funds allocation dates, which may be associated with a task 222 for entering funds allocation dates. The SOE or subcontractor can enter the day of the month on which the allocation of funds should take place, as well as certain dates for the allocation of funds (for example, every month on a particular day). The form for entering the funds allocation dates may also include the Ca1сн1а1с Ога \ у Эа1с5 button (Calculate Fund Allocation Dates) for automatically calculating the fund allocation dates and / or the Αάά Ога \ у Эа1с button (Add Fund Allocation Date) for manually entering the fund allotment dates. In some embodiments, a GP or subcontractor may also use EMSS 10 to provide an open billing environment for a particular project, which allows project participants to submit an invoice at any time during the project.

In FIG. 39 shows an account code setting form, which may be associated with an account code setting task 220. A GP or subcontractor can select an account code (for example, building codes - building 1, 2, or 3), enter a new account code, create an account code, enter a preference for displaying budget lines (for example, phase codes) and enter preference for options printouts. The account code setup form allows you to facilitate the automated generation of bills and affidavits by EMSS 10. Account codes can be used for specially configured messages or

- 16 015056 for interaction with other types of existing software. Account codes can allow participants to sort budget items based on the requirements of the architect, owner, etc. SPMS 10 can also use bank account codes in the budget to interact with existing accounting systems. Bank account codes can be used to maintain a budget, record the results of disbursements, and facilitate billing and payment.

In FIG. 40 provides an account code assignment form that may be associated with an account code assignment task 224. The SOE or subcontractor can provide an account code (for example, building 1, 2, or 3) and can use links to access sub-budgets for each phase code. The account code assignment form may include the project name, project address, phase codes, descriptions of phase codes, the organization with which there is a contract for work, and the size of the budget. The account code assignment form can also facilitate the automated generation of accounts and sworn statements through EMS 10.

In FIG. 41, a project acceptance notice is provided that may be associated with a project acceptance task 202. The notification of FIG. 41 may include a statement that a subcontractor or material supplier has been added as a project participant, a description of the project, and details of the participation of the subcontractor or material supplier. A subcontractor or material supplier can use the link to refer to the project acceptance form, as shown in FIG. 42, for accepting or rejecting the project.

In FIG. 42 shows a project adoption form, which may be associated with task 204 of the budget adoption form. The project acceptance form may include the GP project number, project system number, GP name, project name, project address and budget item. The project acceptance form allows you to provide a subcontractor or material supplier with project information and a budget line item. A subcontractor or material supplier can use Asser buttons! (Accept) or Yes (Decline) to accept or reject the project related to the budget item. A subcontractor or material supplier may also provide a reason for the rejection of the project. Articles from project acceptance forms can also be used to facilitate the automated generation of accounts and sworn statements through EMS 10.

In FIG. 43, a notification of a rejected project is shown which may be transmitted during task 206 of the rejected project. The notification of FIG. 43 may include the name of the subcontractor or material supplier who rejected the project, the rejected budget item, and the reason for the rejection. The notification of FIG. 43 may provide an opportunity to appoint another member to an organizational role.

In FIG. 44, a notification of the accepted project is presented, which can be transmitted during task 210 of the adopted project. The notification of FIG. 44 may include the name of the subcontractor or material supplier who accepted the draft and the adopted budget line. The notification of FIG. 43 allows you to provide access to project details.

In FIG. 45 is a project homepage that may be associated with a project homepage task 211. The project home page may include the name of the project, information on completed disbursements of funds, and information on disbursements of funds under consideration. The project home page may include a project overview with an indicator of the progress of the project schedule, an indicator of the progress of spending the funds, and an indicator of the progress of completion in percent. The project home page may include one or more links with specific actions that can be performed in relation to the project (e.g., project profile, project budget, introducing project participants, setting account codes, managing project users, initiating unplanned disbursements, etc.) d.).

In FIG. 46 shows a user add notification that may be transmitted during the user add task 208. The notification of FIG. 46 may include a statement confirming that the subcontractor or material supplier has joined the project. The notification of FIG. 46 may include a request for a subcontractor or material supplier to add users (eg, members of an organization) to the system.

In FIG. 47 shows a user access form for a project, which may be associated with a user access task 212 for a project. A subcontractor or material supplier may choose to check access for each user (for example, a project manager or signatory). The user access form for the project may include the name of the project, the name of the SOE and a list of users in the organization of the material supplier or subcontractor.

In FIG. 48 provides a notice of project responsibilities that may be related to task 214 of the project responsibilities. The notification of FIG. 48 may include a statement that the user's responsibilities have been changed, as well as new access authorization checks. The notification of FIG. 48 may include communications for accessing a project budget.

In FIG. 49 shows a screen for presenting a project budget, which may be associated with a task 216 for presenting a project budget. The SOE or subcontractor may access the project budget presentation screen through the budget module 36. The project budget presentation screen may include the name of the project, the name of the SOE, the address of the project, and a list of budget items. List of articles

- 17 015056 the jeta may include phase codes, descriptions of phase codes, of a subcontractor or supplier of materials with which there is a contract under the budget line item, budget amount, payments, withholding, balance sheet and communication with any of the sub-budgets.

In FIG. 50 shows a budget entry form that may be associated with a budget entry task 218. The SOE or subcontractor may refer to the budget entry form through budget module 36. A GP or a subcontractor can enter in the required information, such as phase codes, descriptions of phase codes and budget amount. SOEs or subcontractors may change the organization associated with a specific budget item. The SOE or subcontractor can choose whether the organization is only providing materials.

In FIG. 51, a process for terminating a budget item 226 that may be included in a project management process 94 is presented. The termination process 226 of the budget item may be performed by the SOE or subcontractor. The process 226 of terminating the budget item may include task 228 of entering a high-level budget and task 230 of terminating the budget.

In FIG. 52A presents a high-level budget input form that can be associated with a high-level budget input task 228. The SOE or subcontractor may refer to the high-level budget input form through budget module 36. The high-level budget entry form may include the name of the project, project number, contract value, and list of organizations. The SOE or subcontractor can enter the required information, such as retention percent, phase codes, descriptions of phase codes, bank account code, and whether the organization is only a supplier of materials. The SOE or subcontractor may also choose to add new articles or terminate a specific article. The high-level budget input form may include links to the form for setting the allocation dates and / or the form for setting the account codes.

In FIG. 52B, 52C, a form for editing a budget or a schedule of quantities is presented. The SOE and / or subcontractor or material supplier can use the budget editing form to edit the budget information for the project. In some embodiments, a user can access the budget edit form from the project home page, as shown in FIG. 52Ό.

In FIG. 53, a budget termination screen is presented, which may be associated with budget termination task 226. After the SOE or subcontractor selects an item for termination, the budget termination screen provides confirmation and a statement that any unpaid balance can be made available for reassignment.

In FIG. 54 depicts a disbursement process 232 that may be included in a disbursement management process 96. The allocation process 232 may be used to create a schedule for the allocation of project funds; to initiate each allocation of funds; for entering and signing bills; To view pending allocation of funds to work out bills, affidavits and refusals to withhold; to determine if funds are available; and spending funds. The disbursement process 232 may be performed by several of the participants using the disbursement module 44. The process of allocation of funds 232 may include task 234 of creating a schedule of funds allocation, task 236 of initiating the allocation of funds, task 238 of entering an account, task 240 of entering an account form, task 242 of signing an account, task 244 of updating account details, task 246 of viewing pending requests for funds , task 248 of developing an account, task 250 of forming an affidavit statement, task 252 of available funds, task 254 of viewing a request for allocation of funds, task 256 of signing a refusal to withhold, task 258 of forming a refusal of withholding, task 260 of signing all refusals of deduction, task 262 of the button for viewing the request for allocation of funds with expendable funds, task 264 of signing refusal of deduction, task 266 of viewing the request for allocation of funds. The process of allocating funds may also include task 270 of accepting payment details, task 272 of an account not included in the allocation of funds, and task 274 of not accepting payment details. The disbursement process 232 may be performed so that withholding waivers are withdrawn for the current disbursement of funds, and not for the previous disbursement of funds.

In FIG. 55, a notification of the creation of a planned disbursement of funds is presented, which may be transmitted during task 234 of creating a disbursement schedule. The notification of FIG. 55 may be transmitted in real time to all disbursement participants and may include a statement that a planned disbursement of funds is pending and that participants have not yet been selected for disbursement.

In FIG. 56A, 56B illustrate disbursement initiation forms that may be associated with a disbursement initiation task 236. The SOE may refer to forms for initiating disbursements through the disbursement module 44. In some embodiments, a GP may refer to forms for initiating a disbursement by linking to a project home page, as shown in FIG. 56Ό. The form for initiating the allocation of funds may include the name of the project, project number, project address, allocation number of funds, date of allocation of funds and a list of potential participants for allocation of funds. The list of potential participants may include phase codes, descriptions of phase codes, organization name, budget amount, amount

- 18 015056 tezha, obstacle, accumulated deductions and residual balance. The GP can choose each participant to allocate funds. The SOE may select a subset of potential participants for allocation of funds (for example, at least one potential participant) or may select all potential participants for allocation of funds.

In some embodiments, a disbursement initiation form may include a selection mechanism to select once all potential participants for disbursement. In other embodiments, the SUMS 10 may automatically select all or a subset of potential participants to allocate funds without requiring the GP to select individual participants. After the SOE selects one or more participants to be included in the allocation of funds, the EMSS 10 may generate a notification of participants included in the allocation of funds, as shown in FIG. 56E, and may display the participants included in the GP funds allocation notice.

In some embodiments, the GP may also use a disbursement initiation form to close a processed disbursement. In addition, the SOE may use the disbursement initiation form or other forms provided by the EMSS 10 to open overlapping disbursements. The SMSS 10, however, may make rules or recommendations for opening overlapping disbursements in order to manage multiple disbursements at one time, such as preventing the signing of a new allocation of funds (for example, approved for spending) before signing the previous allocation of funds, or preventing the payment of allocations funds out of sequence.

In FIG. 57A, 57B provide invoice entry notifications that may be transmitted during invoice entry task 238. The notifications of FIG. 57 may include a statement that funds are planned for the project and that the subcontractor or material supplier can enter details of the related payments. Notifications may also include the role of the organization and a specific budget line item for a subcontractor or material supplier. Notifications can be transmitted in real time to all participants in the allocation of funds. In some embodiments, a subcontractor or material supplier may refer to an invoice entry notification from the presentation screen of all messages, as shown in FIG. 57C.

In FIG. 58 A, 58B show invoice entry forms that may be associated with task 240 of the invoice entry form. A subcontractor or material supplier may use invoice entry forms to provide invoice amounts for disbursement of funds. The invoice entry form may also include the name of the project, project number, project address, allocation number, date of allocation of funds, and a specific article for this subcontractor or material supplier. After the subcontractor or material supplier provides invoice information, the EMS can 10 generate a notification of the invoice submitted, as shown in FIG. 58C, and may display a notification of the invoice submitted to the subcontractor or material supplier.

In some embodiments, the GP or the project manager may determine the values from the invoices to be entered by the subcontractor. For example, using EMS 10, the GP can determine the value of the invoice (for example, a percentage of the total amount) for a particular subcontractor. The subcontractor may review and submit the invoice value thus determined using the EMS, 10, but may not change the amount in some embodiments.

In FIG. 59, an invoice signature notification is provided that may be transferred to a subcontractor or material supplier during invoice signing task 242. The notification of FIG. 59 may include a statement that the SOE or project manager approved the account for a specific allocation of funds and that the affidavit must be signed. EMS 10 can be used to assign security / authorization roles to each user, such as managing, accounting, or having the authority to sign. The SMSS 10 may notify the user with the authority to sign the affidavit so that the organization official signs the affidavit, if necessary. The SMSS 10 can be used to change the security roles / authority that are necessary to sign a sworn statement (for example, a lender may require a sworn statement to be signed by an official rather than an administrator for the organization).

In FIG. 60A, 60B show document signing screens or account signature forms that may be associated with an account signing task 242. A subcontractor or material supplier can access invoice signing forms through a disbursement module 44. Using invoice signing forms, a subcontractor or material supplier can view invoice details, such as a specific organization, requested amount, budget amount, payment amount, accumulated deduction and residual balance. The subcontractor or material supplier may then choose to sign the invoice. The invoice signing form may include a link to submit an automatically generated invoice form or a sworn automatically generated application form.

- 19 015056

In some embodiments, to electronically sign the invoice, the subcontractor or material supplier may select an invoice signing application selection mechanism included in the document signing screen or invoice signing form, as shown in FIG. 60A, 60V. After a subcontractor or material supplier selects a mechanism for selecting an application for signing an invoice, EMS 10 can generate and display an automatically generated invoice form, as shown in FIG. 60С, 60Ό. To sign the invoice form, the subcontractor or material supplier may select the mechanism for selecting the signature of the document included in the form. After a subcontractor or material supplier electronically signs an automatically generated invoice form, system 10 can create and display a legally binding signed invoice form, as shown in FIG. 60P. In some embodiments, the EMS 10 may generate a verification message, such as a signature verification message screen, as shown in FIG. 60P, each time a user electronically signs a document using EMS 10.

After a subcontractor or material supplier signs an automatically generated invoice form, EMS 10 can generate a notification of the signed document, as shown in FIG. 600, and may display a notification of a signed document to a subcontractor or material supplier. In some embodiments, when the subcontractor or material supplier provides a signed invoice, EMSS 10 may also require the subcontractor or material supplier to provide a signed prior deduction notice.

FIG. 61 provides a notification of updated invoice details that may be transmitted to the SO during task 244 of updated invoice details. The notification of FIG. 61 may include a statement that the subcontractor or material supplier has updated payment details to allocate funds for a specific date for a particular project. A notice may provide a link in order to provide invoice details.

In FIG. 62, a screen is presented for presenting a pending request for a disbursement of funds, which may be associated with a task 246 for presenting a pending request for disbursement of funds. The GP can access the presentation screen of the pending allocation request using the allocation unit 44. The GP can choose each participant to be included in the allocation of funds, confirm the allocation of funds and send a real-time notification to the signatory of each organization. However, the GP can also reject the pending request for funds allocation, notify selected participants of the need to re-enter the account and inform the reason for rejecting the request for funds allocation. The screen for presenting a pending request for allocation of funds may include the name of the project, project number, project address, allocation number, date of allocation of funds, a list of participants who submitted invoices, and a list of participants who did not submit invoices. Participants can be organized by phase codes. For each phase code, the screen for presenting pending allocation requests may include the required amount, budget amount, payment amount, accumulated deduction and residual balance. In some embodiments, a presentation screen of a pending allocation request (or project home page) may also provide one or more graphical progress indicators for a specific allocation of funds, such as a progress (progress) indicator. The project manager can determine which participants can view promotion metrics. In addition, in some embodiments, the SUMS 10 may automatically transmit notifications (for example, approximately in real time) to participants who inform the participants of the status of a particular allocation of funds.

In FIG. 63, notification of rejected invoice details is presented, which may be transmitted during task 274 of the unaccepted payment details. The notification of FIG. 63 may include a statement that payment details and invoices entered by a particular user for the allocation of funds, which is carried out on a certain date for a particular project, were not accepted and the reasons for rejection. The notification may include a request to a subcontractor or material supplier to re-enter payment details before the disbursement closes.

In FIG. 64, an account is presented that is not included in the allocation notification, which may be transferred in the course of task 272 of the account not included in the allocation of funds. The notification of FIG. 64 may include a statement that the participant did not submit an approved affidavit to allocate funds for the project, and that the participant and all of its subcontractors would not be included in the allocation of funds. A notice may state that all affidavits submitted and accounts have been destroyed.

After subcontractors or suppliers of materials submit invoices for a specific allocation of funds, EMS 10 can generate a combined account based on the received invoices. SPMS 10 may also include invoice details provided by the SOE.

In FIG. 64B presents an invoice entry form that a GP can use to enter invoice details for a specific allocation of funds.

In some embodiments, the GP can access the invoice entry form from the project home page, as shown in FIG. 64C.

- 20 015056

As shown in FIG. 64B, the GP can enter the invoice value for self-completed work. The invoice entry form may also display invoice amounts received from subcontractors or suppliers of materials included in the allocation of funds. In some embodiments, the GP or the project manager may bill by subcontractor or material supplier. For example, a SOE may bill for one or more facilities or work periods for which the SOE has not yet received an invoice from a subcontractor or material supplier. By presenting an invoice, a GP can obtain a retention amount for facilities or work periods.

After the GP enters the invoice details using the invoice entry form shown in FIG. 64B, the EMSS 10 may generate a notification of the submitted invoice, as shown in FIG. 64Ό, and may display a notification of the submitted GP account.

The SOE can also approve or reject invoices that the SOE receives from subcontractors and material suppliers using the invoice approval form, as shown in FIG. 64E. Using the account approval form, the SO can select one or more accounts to reject and / or one or more accounts to accept. In some embodiments, if the SOE declines the invoice, the SOE may use the approval form to submit reasons or comments that indicate why the SOE declined the invoice.

As shown in FIG. 64E, for each invoice received, the invoice approval form may include a link to the submission of the invoice. The SOE may choose a relationship with the submission of the invoice relating to a particular subcontractor or supplier of materials to represent the invoice received from the subcontractor or supplier of materials. For example, if the SOE selects an invoice submission relationship related to a particular subcontractor or material supplier, EMS 10 may display an invoice submission screen, as shown in FIG. 64E, which displays an invoice submitted by a subcontractor or material supplier. After the SOE approves one or more accounts, EMS 10 may generate a notification of approved accounts, as shown in FIG. 64C. and may display a notification of approved SOE accounts.

After the SOE has approved one or more invoices received from subcontractors or material suppliers and / or entered invoice details using the invoice entry form shown in FIG. 64B, EMSS 10 may generate an invoice based on invoice information received from subcontractors or suppliers of materials and SOEs.

In FIG. 65 shows a form of automatically generated invoice (for example, a form that is compatible with industrial practice, such as form 0702/703), which may be associated with task 248 generating an invoice (marked 0702/703 in Fig. 54). SOEs, subcontractors, and material suppliers can access invoice forms through a disbursement module 44. Subcontractors, suppliers of materials and / or an architect can sign the invoice form electronically (for example, using products from an electronic signature software provider such as L1ryaTgi8! SogrogaEoi).

In FIG. 66A shows a form of automatically generated affidavit that may be associated with task 250 of the affidavit. The SOE may refer to the affidavit form through the disbursement module 44. The SOE may sign the affidavit form electronically (for example, using products from an electronic signature software provider such as A1pNaTgi51 SogrogEoi).

After the SMSS 10 has been worked out, the invoice and / or affidavit based on the approved invoices from subcontractors and suppliers of materials and invoice details entered by the SOE, the SOE can view electronic documents using the sign-up screen, as shown in FIG. 66B. After the SOE reviews the automatically generated documents, the SOE can use the sending screen to the signatory to present the invoice and / or affidavit to a user associated with the SOE who is authorized by the EMS 10 to sign the documents (hereinafter referred to as the signatory). After the GP submits the documents for signature, the EMS 10 may generate a notification of the invoice sent to the signatory, as shown in FIG. 66C, and may display a notification of a GP account sent to the signatory.

When one or more documents are submitted by the SOE for signature, the EMS can 10 notify the signatory that one or more documents are awaiting signature. For example, EMS 10 may display a notification on the homepage of the signatory project, as shown in FIG. 66Ό. In order to sign the document, the signatory may refer to the document signing screen, as shown in FIG. 66E. Using the document signature screen shown in FIG. 66E, the signatory may also reject the document and may introduce reasons or comments that indicate why the signatory rejected the document.

The signatory can sign the document by choosing the account signature selection mechanism (for example, signature 0702) included in the document signing screen. If the signatory chooses an account signature selection mechanism, EMSS 10 may display an automatically generated invoice form, as shown in FIG. 66E. To electronically sign the displayed invoice form, the signatory can select the document signature selection mechanism included in the invoice form, as shown

- 21 015056 in FIG. 66E. After the signatory selects the mechanism for selecting the signature of the document, EMS 10 generates and displays the signed invoice, as shown in FIG. 660, 66H. After the signatory signs the invoice, EMS 10 may generate a notification of the signed invoice, as shown in FIG. 661, and may display a notification of a signed invoice to a signatory.

After the signatory signs the account and / or sworn statement, EMS 10 can prompt the signatory (for example, the same user who signed the bill and / or sworn statement or another user associated with the GP and authorized to sign the documents) to sign the refusal deduction associated with the invoice and / or affidavit using the document signature screen, as shown in FIG. 661. To sign a refusal of deduction, the signatory may choose the mechanism for selecting the signature of the refusal of deduction included in the document signature screen. If the signatory chooses an account signature selection mechanism, EMSS 10 displays an automatically generated non-deduction form, as shown in FIG. 66K. In order to electronically sign the displayed refusal of deduction, the signatory may select a document signature selection mechanism included in the refusal of deduction form, as shown in FIG. 66K. After the signatory selects the mechanism for selecting the signature of the document, EMS 10 generates and displays the signed waiver of deduction, as shown in FIG. 66b.

Similarly, EMSS 10 may remind a notary associated with a GP to notarize a signed refusal of deduction using the document signature screen, as shown in FIG. 66M. In some embodiments, each organization registered in system 10 may designate at least one user as a notary for the organization. A notary can use SMSS 10 to establish a password or personal identification number (LIN, ΡΙΝ) of a notary. The notary may be asked to enter the LIN of the notary when registering in system 10 and / or when signing a specific document. To prevent the unauthorized use of a NOTary LIN, a notary session in SMSS 10 may be limited in time and SMSS 10 may require a notary to re-enter a NOTary LIN. In addition, in some embodiments, the SMSS 10 may create a test footprint each time a notary notarizes a document. To refer to the control trail for a specific notarization, the user can access the notarized document through EMS 10 and can select or click on the electronic notarization displayed in the document. The SMSS 10 may then display a checkmark associated with the selected notarization. EMS 10 can provide a similar traceability functionality for all types of electronic signatures and authorizations recorded by system 10.

For notarization of a signed refusal of deduction, a notary can choose a mechanism for selecting notarization of refusal of deduction included in the document signature screen shown in FIG. 66M. If the notary selects the mechanism for selecting notarization of the refusal of deduction, the EMS can 10 display the form of notarization of the signed refusal of deduction, as shown in FIG. 66Ν. For the electronic notarization of the displayed signed refusal of deduction form, the notary can choose the mechanism for selecting notarization or signature of the document included in the form of notarization of the signed refusal of deduction, as shown in FIG. 66Ν. After the notary selects a mechanism for selecting the signature of the document, the EMSS 10 can generate and display a notarized signed refusal of deduction, as shown in FIG. 660. The EMS 10 may also generate a notification of a signed document, as shown in FIG. 66Ρ, and may display a notification of a signed document to a signatory.

In FIG. 67 submitted a statement on the availability of funds available, which can be transferred during task 252 available funds. The notification of FIG. 67 may include instructions to follow communications to request waivers of holding and releasing funds when funds are free to release funds for the project.

In FIG. 68A shows a screen for presenting a request for a disbursement, which may be associated with a task 254 for submitting a request for disbursement. The GP may refer to the screen for presenting the request for allocation of funds using the module 44 allocation of funds. The SOE can review the details of the allocation of funds, authorize the use of funds and request waivers of withholding. The screen for presenting a request for allocation of funds may include the name of the project, project number, project address, allocation number of funds, date of allocation of funds and a list of participants in the allocation of funds. The list of participants may include the name of the participant, phase code, information on whether a refusal to withhold was received, the requested amount, budget amount, payment amount, accumulated deduction and residual balance. The list of participants may also include any subcontractor and their refusals to withhold or other types of documents submitted (for example, invoices, affidavits, contracts, etc.).

- 22 015056

In FIG. 68B is a hold refusal request screen, which can be accessed through the funds allocation request presentation screen, as shown in FIG. 68A, or the project home page, as shown in FIG. 68C. Using the refusal request from deduction, GP can view the list of subcontractors and suppliers of materials related to the allocation of funds. In order to request withholding refusals from the specified subcontractors and material suppliers, the GP can select the retention rejection request selection mechanism included in the retention refusal request screen. After the GP selects a retention reject request request mechanism, the EMS 10 may generate a notification of the requested retention rejects, as shown in FIG. 68Ό, and can display for the GP a notification of requested refusals to withhold.

In FIG. 69A, a non-deduction signature notification is provided that may be transmitted during a non-deduction signature task 256. The notification of FIG. 69A may be transmitted in real time to all disbursement participants and may include a statement that the disbursement planned for the project was permitted and that the subcontractor or material supplier is required to sign their waiver refusal in order to receive disbursement payments. In some embodiments, subcontractors and material suppliers may request a non-retention signature notification via the project home page, as shown in FIG. 69B.

In some embodiments, in order to sign a waiver of deduction, subcontractors and suppliers of materials may choose the relationship included in the notice of denying deduction. If a subcontractor or material supplier selects a link included in the non-retention signature signature notification, EMS 10 can generate and display a document signature screen, as shown in FIG. 69C. To sign a waiver of deduction, the subcontractor or material supplier can select the mechanism for choosing the signature of deduction of deduction included in the document signature screen. If the subcontractor or material supplier selects a non-retention signature selection mechanism, EMSS 10 displays an automatically generated non-retention form.

In FIG. 70A, 70B, an automatically generated form of non-retention is presented, which may be associated with task 258 of the form of non-retention. Subcontractors and material suppliers can access the non-retention form through the disbursement module 44. The refusal form withholding can be automatically generated on the basis of the budget, taking into account the articles for each subcontractor or supplier of materials. Subcontractors and material suppliers can sign non-retention forms electronically (for example, using A1ryaTgi 81 electronic signature products) by selecting a signature selection mechanism included in the non-retention form, as shown in FIG. 70B. Once they are signed, hold refusals 68 can be stored in the electronic intermediate hopper / escrow facility 54. As soon as a subcontractor or material supplier signs a hold refusal, the EMS can 10 display a signed or electronically executed hold refusal, as shown in FIG. 70C.

In some embodiments, in addition to signing a waiver of deduction, the subcontractor or supplier of materials may notarize the waiver of deduction. For example, EMSS 10 may remind a notary public associated with a subcontractor or material supplier to notarize a signed refusal to withhold using the document signature screen, as shown in FIG. 70Ό. For notarization of a signed refusal of deduction, a notary can choose a mechanism for selecting notarization of refusal of deduction included in the document signature screen shown in FIG. 70Ό. If the notary selects a mechanism for selecting notarization of non-deduction, SMSS 10 may display a form of notarization of non-deduction, as shown in FIG. 70E. For electronic notarization of the displayed form of the signed refusal of deduction, the notary can choose the mechanism for selecting notarization or signature of the document included in the form of notarization of the signed refusal of deduction shown in FIG. 70E. After the notary selects the mechanism for selecting the signature of the document, the SMSS 10 generates and displays a certified notarized refusal of deduction, as shown in FIG. 70C. EMS 10 may also generate a notification of a signed document, as shown in FIG. 70H, and may display a notification of a signed document to a subcontractor or material supplier.

In FIG. 71 shows a notification of a signed withholding waiver that can be transmitted during task 266 of a signed waiver of deduction. The notification of FIG. 71 may include a statement that the subcontractor or material supplier has signed its waiver of withholding to allocate funds for the project. The notice may include access to details of the disbursements and withholding disclaimers currently received.

In FIG. 72 shows a screen for presenting a request for a disbursement, which may be associated with a task 268 for submitting a request for disbursement. The GP, subcontractor, or material supplier may access the screen for submitting the request for allocation of funds using the module 44 allocation of funds. The screen for presenting a request for disbursement may include the name of the project, but

- 23 015056 project measures, project address, allocation number, date of allocation of funds and list of participants in the allocation of funds. The list of participants may include the name of the participant, phase code, information on whether a refusal to withhold was received, the requested amount, budget amount, payment amount, accumulated deduction and residual balance. The list of participants may also include any subcontractor and its refusals to withhold.

In FIG. 73A, a notification of signing all withholding waivers is presented, which may be transmitted during task 260 of signing all waiver waivers. The notification of FIG. 73 may include a statement that all withholding waivers for the allocation of project funds have been signed. The notice may include a link to provide details of the allocation of funds and the expenditure of funds. In some embodiments, the GP may refer to a notification of signing of all refusals to hold all messages from the presentation screen, as shown in FIG. 73B.

In FIG. 74A, 74B show presentation forms of a disbursement request that may be associated with a fund spending task 262. SOEs (or an architect, owner, owner’s representative, lender or title company) can refer to the allocation request form and can approve the allocation using the allocation module 44 and / or the allocation approval module 60. Forms for submitting a request for allocation of funds may include the name of the project, project number, project address, allocation number, date of allocation of funds, and a list of participants in the allocation of funds. The list of participants may include the name of the participant, phase code, information on whether a refusal to withhold was received, the requested amount, budget amount, payment amount, accumulated deduction and residual balance. The list of participants may also include any subcontractor and its refusals to withhold. When the SOE pays funds, waivers of deduction are essentially simultaneously withdrawn, and the payment order is sent to ARPA system 26.

As shown in FIG. 74B, a submission request form may indicate a payment amount for a particular subcontractor or material supplier. The submission request form may also indicate the amount of delayed payment for a particular subcontractor or material supplier. In some embodiments, the EMS of 10 may automatically delay payment to a subcontractor or material supplier. For example, as described below, EMSS 10 may automatically delay payment to a subcontractor or material supplier who has not submitted one or more required documents, such as a contract, license, insurance document, etc. Using EMSS 10, the SOE can also manually delay payment to a specific subcontractor or material supplier for various other reasons.

As shown in FIG. 74B, the submission request form may also include links that the SO can use to view the withholding denials submitted for the disbursement, or view the status of the documents that are required from the disbursement participants.

In FIG. 75A, 75B show payment notifications that may be transmitted during task 264 of paid payments. The notifications of FIG. 75A, 75B can be transferred in real time to all participants in the disbursement of funds and may include a statement that the payments were paid on the allocation of funds scheduled for a specific date on the project. In some embodiments, the GP may refer to the payment notification via the project home page, as shown in FIG. 75C.

In addition to notifying the SO about paid payments, or instead, SMSS 10 may notify subcontractors or material suppliers receiving payment of funds for the payment of payments made using the screen for receiving payment of funds, as shown in FIG. 75Ό.

In FIG. 76, tasks 276 for maintaining system screens that may be included in a system environment management process 102 are presented. Tasks 276 to maintain system screens can be used by each user or each organization to customize the software environment in accordance with specific needs. For example, an organization might set up phase codes for its projects. Tasks 276 to maintain system screens can be performed by any of the participants using the administrator 52 of the system environment. Tasks 276 for maintaining system screens may include a task 278 for maintaining phase codes, a task 280 for administering a user login, a task 282 for adding / editing a selection list, a task 284 for adding / editing an organization role, a task 286 for default settings, a task 288 for editing notifications, a task 290 default configuration and task 292 addition / editing user roles.

In FIG. 77 shows a phase code maintenance form, which may be associated with a phase code maintenance task 278. Each participant can refer to the form of maintaining phase codes through the administrator 52 of the system environment. A participant can add a new or delete a selected budget item.

- 24 015056

In FIG. 78, a user login administration screen is presented, which may be associated with a user login admin task 280. Each participant can access the administrator’s login screen using the administrator 52 of the system environment. A user in the organization can enter into the username and use the screen to enter the system, like any user in the system.

In FIG. 79 shows an addition / editing form of a selection list that may be associated with an addition / editing selection list task 282. The EMS management system 10 can add new or delete selected entries in the selection list (for example, status lists, project types, etc.) in the various drop-down menus provided by EMS 10.

In FIG. 80 presents a form of addition / editing the role of the organization, which may be associated with task 284 addition / editing the role of the organization. The GP can access the form of addition / editing the role of the organization through the administrator 52 of the system environment. The SOE can select an access authorization check for each type of organization (for example, a bank, title company, SOE, subcontractor, or architect).

In FIG. 81 shows a form of a default job / configuration of settings, which may be associated with a task 286 default settings. The GP can access the default job / configuration form through the administrator 52 of the system environment. The GP can enter its preferred settings, such as days of reminder about the close allocation of funds, days of reminder of the beginning of the allocation of funds, minimum time to complete the request for allocation of funds, security identification, information about whether the inspector needs to pay through the ARPA system, whether all failures should be expected from withholding, information about who pays the inspector (for example, bank, title company, owner, owner’s representative or SOE).

In FIG. 82, a notification editing form is provided that may be associated with notification editing task 288. The GP can access the notification editing form through the administrator 52 of the system environment. The GP can change the notifications that are transmitted during various processes. The GP can select a specific notification and edit the default notification as necessary. The GP can also determine if specific authorizations, such as bank authorization, are needed to change the notification.

In FIG. 83 is a default job / process configuration form that may be associated with a default configuration task 290. SOE, owner, owner’s representative, lender, etc. can access the default job / process configuration form through the administrator 52 of the system environment to configure parts of the payment process in construction or change the rules for parts of the payment process in construction. For example, a GP can define and store its own phase codes. SOE, owner, owner’s representative, lender, etc. they can choose whether to activate specific tasks in each process and can contact them to edit each of the notifications associated with the tasks.

In FIG. 84 is a user role addition / editing form that may be associated with a user role addition / editing task 292. The GP can access the form of addition / editing of the user role through the administrator 52 of the system environment. The GP can select roles for a specific user, such as a system administrator, a user of the system’s help desk, local administrator, regular user, and view-only access. The GP can add new roles or remove selected roles.

In FIG. 85 presents inspection tasks 294 that may be included in disbursement management process 96. Inspection tasks 294 can be used to plan and facilitate inspections of a construction project if they are needed before each allocation. Inspection tasks 294 can be performed by the GP and the inspector using the inspection module 58 of the allocation module 94. Inspection tasks 294 may include a required inspection task 296, a required inspection task 298, an inspection preparation task 300, a previous inspection task 302, an inspection input task 304, an inspection report input task 306, an inspection report form task 308 and a task 310 unsuccessful inspection report.

In FIG. 86, an inspection preparation notice is provided, which may be transmitted during inspection preparation notification task 300.

The notification of FIG. 86 may include a statement that the allocation of funds is planned for the project at some date and that the inspector is required to prepare for an inspection to allocate funds. A notification may state that an inspection should only be carried out after receipt of confirmation.

In FIG. 87, a notification of the required inspection is provided, which may be transmitted during task 296 of the notification of the required inspection. The notification of FIG. 87 may include a statement that a planned disbursement is pending for the project, and a link to determine if an inspection is required to disburse the funds.

- 25 015056

In FIG. 88 is a screen for required inspection that may be associated with task 298 of required inspection. The SOE (or owner, owner’s representative, lender or title company) can access the required inspection screen through inspection module 58 of allocation module 44. The screen of the required inspection may include the name of the project, project number, allocation number, name of owner, date of allocation of funds, project address and list of participants. The list of participants may include the amount of the request, the name of the organization, the role of the organization, the budget item, the amount of the budget, the amount of payment, accumulated deduction and residual balance. The screen for the required inspection may also include general comments, comments to the inspector, and whether the inspection should be planned.

In FIG. 89, an inspection report input notification is provided that can be transmitted during inspection input task 304. The notification of FIG. 89 may include a statement that the allocation schedule for a certain date on the project has been authorized and that the recipient must perform an inspection. The notice may include a link to present the details of the project and develop an inspection checklist.

In FIG. 90, an inspection report input form is provided that may be associated with an inspection report input task 306. The inspector may enter inspection details in the inspection report form. The inspection report form may include the project name, project number, disbursement number, disbursement date, owner name, project address, inspection date, and general inspection comments.

In FIG. 91 is an inspection report form screen that may be associated with task 308 of the inspection report form. The SOE, owner, owner’s representative, title company or inspector can access the inspection report form screen through inspection module 58 of allocation module 44.

In FIG. 92 a notification of an unsuccessful inspection report is provided, which may be transmitted during task 310 of an unsuccessful inspection report. The notification of FIG. 92 may include a statement that there is a high level of concern about the project after an inspection conducted on a specific date. The notification may include communication to access the inspection report form.

In FIG. 93, a screen for presenting previous inspections is shown, which may be associated with task 302 for submitting previous inspections. The SOE, owner, owner’s representative, title company or inspector can access the presentation screen for previous inspections using the inspection module 58 of the disbursement module 44 and can select the inspection performed on a specific date.

In FIG. 94 shows a process 312 for approving a disbursement request, which may be included in the disbursement management process 96. The approval process for the allocation of funds request 312 can be used to confirm that the necessary inspections have been completed, to approve each allocation of funds during the construction payment process, and to issue withholding refusals. The process 312 for approving a request for disbursement of funds can be performed by the SOE and / or any participant above the line of SOEs (such as the owner, owner’s representative, title company, architect, etc.) using the allocation approval unit 60 of the funds allocation unit 44. Once the project has been initiated, EMSS 10 can be used to approve any type of payment related to the construction process. The EMSS 10 facilitates parallel approvals (for example, both the SOE and the owner must approve the allocation of funds) or the sequence of approvals (for example, the architect, then the owner, then the lender must approve the allocation of funds). EMS 10 can be used to configure the approval process for each project. The EMS can be used to approve a change order for the budget or for specific values that are defined between the parties under the contract. For example, EMS 10 can be used to obtain approval from the SOE and / or any participant above the SOE line for an order to change that exceeds a certain amount, or to approve all change orders after the limit has been exceeded. The process for approving a request for funds allocation 312 may include task 314 of authorization of funds allocation request one, task 316 of authorization of requests for funds allocation one rejected, task 318 of confirmed inspections, task 320 of authorized inspection, task 322 of modified payment details, task 324 of notification of authorization of request for funds allocation Two, task 326 of Allocation of Request for Funds Allocation Two, task 328 of rejection of Authorization of Request for Allocation of Funds Two, task 330 of authorization of Authorization of Request for Fund Allocation Two and a task 332 issuing non-retention.

In FIG. 95 presents the Form of Disbursement Request Authorization Form One or the sworn statement authorization form, which may be related to task 314 of Authorization of Disbursement Request for Funds One. The SOE, owner, owner’s representative or title company may refer to the Allocation Request Form Authorization Form One through the allocation module 44. One Allocation Request Authorization Form One may include the name of the project, project number, owner, project address, allocation number and date of allocation of funds. Authorization form

- 26 015056

Request for Allocation of Funds One may include any input data for each organization, including the amount of the request, the name of the organization, the role of the organization, budget item, budget amount, payment amount, accumulated deduction and residual balance. One Allocation Request Authorization Form One may include received authorizations, upcoming authorizations, information about whether an inspection is required, the ability to enter a password for authorization, and the ability to refuse authorization and indicate the reason.

In FIG. 96, a notification of the rejected authorization of the first disbursement of funds is presented, which may be transferred during task 316 of Authorization of the Request for Disbursement of Funds One is rejected. The notification of FIG. 96 may include a statement that authorization of the allocation of funds for the project has been refused and communication to present and / or change the details of the allocation of funds.

In FIG. 97, a notification of the confirmed inspection is submitted, which may be transmitted during task 318 of the confirmed inspections. The notification of FIG. 97 may include a statement that the disbursement planned for the project was authorized, and instructions to perform site inspections, as well as communication to present project details and develop a checklist.

In FIG. 98, a notification of modified payment details is provided, which may be transmitted during task 322 of the modified payment details. The notification of FIG. 98 may include a statement that payment details for the allocation of project funds were not accepted. The notice may list details of the project participation and payments related to the allocation of funds, the role of the organization, the budget item and the amount of payment.

In FIG. 99, an authorized inspection notice is provided that may be transmitted during an authorized inspection task 320. The notification of FIG. 99 may include a statement that the site inspection of the project has been authorized.

In FIG. 100, a Notice of Authorization of Request for Disbursement of Funds Two is submitted, which may be transmitted during task 324 of notification - Authorization of Request for Disbursement of Funds Two. The notification of FIG. 100 may include a statement that the recipient is required to verify the inspection report entered into the project, that the permission of the recipient is required before the allocation of funds can proceed to the next phase (for example, interviewing recipients of the allocation of funds regarding waivers of withholding), and a link for submitting an inspection report and granting permission to allocate funds or refuse it.

In FIG. 101 shows the form of authorization of the Request for allocation of funds Two, which may be associated with task 326 Authorization of the Request for allocation of funds Two. The SOE, owner, owner’s representative or title company can refer to the Allocation Request Request Authorization Form Two using the funds allocation approval module 60 of the funds allocation module 44. The Allocation of Funds Request Two Authorization Form may include the name of the project, project number, owner, project address, allocation number and date of allocation of funds. The Fund Allocation Request Authorization Form Two can include any input for each organization, including the request amount, organization name, organization role, budget item, budget amount, payment amount, accumulated deduction and residual balance. The Form Two Allocation Request Authorization Form may include received authorizations, upcoming authorizations, information about whether an inspection is required, the ability to enter a password for authorization, and the ability to refuse authorization and indicate the reason.

In FIG. 102, a rejected Authorization Request Request two notification is submitted, which may be transmitted during task 328 of a Denied Asset Request Request Authorization Two. The notification of FIG. 102 may include a statement that the authorization of the allocation of funds planned for the project was refused by the participant and that the allocation of funds could not occur without this authorization.

In FIG. 103, a notification of an authorized Authorization of a Request for Disbursement of Funds Two is presented, which may be transmitted during task 330 of Authorization of a Request for a Disbursement of Funds Two. The notification of FIG. 103 may include a statement that the allocation of funds for the project was authorized by the participant.

In FIG. 104, a notice of issuance (refusal) of the refusal of withholding is presented, which may be transmitted during task 332 of issuing the refusal of withholding. The notification of FIG. 104 may include a statement that the disbursement planned by the project was authorized by the participant and that the recipient is required to issue a waiver of deduction in order to receive payment of the disbursement, as well as a communication allowing the recipient to issue a waiver of deduction.

In FIG. 105 illustrates a change request process 334, which may be included in the change order management process 98. The change request process 334 can be used to change the overall budget of the project (usually to expand the budget), add new articles, split the article, change existing articles or terminate relations with subcontractors and release remaining funds for other participants. The change request process 334 may be performed by the GP, architect, owner, owner’s representative, lender or subcontractor using change order module 48. Change request process 334 may include

- 27 015056 include the task 336 of the change request, task 338 of the issued change request 340 and task 340 of authorizing the change request.

In FIG. 106 presents a change request form that may be associated with a change request task 336. The SOE or subcontractor may refer to the change request form through the change order module 48. The change request form may include the project name, project number, project address, owner name, and a list of values for the change. The list of values for the change may include the amount of change, the name of the organization, the role of the organization, budget item, budget, payment amount, and residual balance. The change request form may include a change description field. The change request form may include information whether the form of payment is a loan or the payment of the owner, and whether the payment method is borrowed, by means of a check by the owner or by credit card. The change request form may include the currently estimated completion date and a new estimated completion date.

In FIG. 107, a notification of a issued change request is submitted, which may be transmitted during task 338 of the issued change request. The notification of FIG. 107 may include a statement that a change request has been issued for the project and is awaiting authorization. The notification may include details of the change request, name of organization, budget item, current budget amount and change amount.

In FIG. 108, a change request authorization notification is provided that may be transmitted during change request authorization task 340. The notification of FIG. 108 may include a statement that a change request has been issued for the project and that approval of the recipient is required to request a change. The notification may include communication to present the details of the change request, as well as to approve or reject the change request.

In FIG. 109, a change request processing process 342 is provided that may be included in the change order management process 98. The change request processing process 342 can be used to guarantee authorization of changes made to the budget by an appropriate participant, such as an architect, lender, title company, owner, owner’s representative, or SOE. The change request processing process 342 may be performed by the GP, architect, owner, owner representative, lender, or subcontractor using change order module 48. The change request processing process 342 may include a task 344 for submitting pending change requests, a change request authorization task 346, a rejected change request task 348, and an approved change request task 350.

In FIG. 110 shows a screen for presenting a pending change request that may be associated with a task 344 for presenting a pending change request. The SOE, subcontractor, owner, owner’s representative, lender or architect can access the presentation screen of the pending change request through change order module 48. The presentation screen for the pending change request may include the project name, project number, project address, owner name, and a list of values for the change. The list of values for the change may include the amount of change, the name of the organization, the role of the organization, budget item, budget, payment amount, and residual balance. The presentation screen of the pending change request may include a change description field. The presentation screen for the pending change request may include information about whether the payment method is borrowed, by check of the holder or by credit card. The presentation screen for the pending change request may include a new estimated completion date, received authorizations, and upcoming authorizations.

In FIG. 111, a change request authorization form is provided that may be associated with a change request authorization task 346. The SOE, subcontractor, owner, owner’s representative, lender, or architect can access the change request authorization form through change order module 48. The change request authorization form may include the project name, project number, project address, owner name, and a list of values for the change. The list of values for the change may include the amount of change, the name of the organization, the role of the organization, budget item, budget, payment amount, and residual balance. The change request authorization form may include a change description field. The change request authorization form may include information about whether the payment method is borrowed, by means of a holder’s check or by credit card. The change request authorization form may include a new estimated completion date, received authorizations, and upcoming authorizations. The change request authorization form may include the ability to enter a password and authorize the change request, and the ability to refuse the change request and enter the reason for the refusal.

- 28 015056

In FIG. 112, a notification of a rejected change request is submitted, which may be transmitted during task 348 of the rejected change request. The notification of FIG. 112 may include a statement that the change request issued on a project date was rejected by the participant.

In FIG. 113, a notification of an approved change request is submitted, which may be transmitted during task 350 of the approved change request. The notification of FIG. 113 may include a statement that the change request issued at a certain date on the project was approved by the participant (e.g., lender). Only a change request can be used to change the full budget of the project (usually to expand the budget) by adding new articles, changing existing articles or terminating relations with subcontractors and releasing residual funds for other participants. EMS 10 can be used to guarantee authorization of changes made to the budget by an appropriate participant, such as an architect, lender, title company, owner, owner’s representative, or SOE. The notification of FIG. 113 may be transmitted when the relevant participant approved the change request.

In FIG. 114, a process for changing a project participant, which may be included in the change order management process 98, is presented. The process 352 of changing a project participant can be used to, for example, end a relationship with one subcontractor and make residual funds available to another participant (such as a replacement subcontractor). The process 352 of changing a project participant can be performed by a GP or subcontractor using module 48 of the change order. The project participant change process 352 may include a participant change task 354, a participant deletion verification task 356, and an affidavit change task 358.

In FIG. 115, a member change screen is presented, which may be associated with a member change task 354. The GP or subcontractor may access the member change screen through the change order module 48. The participant change screen may include the project name, project number, owner name, project address and current project status. The member change screen may include a list of organizations that are subject to change. The list of organizations may include the name of the organization, the role of the organization, the budget item, budget amount, payment amount, accumulated deduction, residual balance and communication for removal of each participant.

In FIG. 116, a participant deletion verification screen is presented, which may be associated with a participant deletion verification task 356. The SOE or subcontractor may access the screen to verify the removal of the participant through the module 48 of the change order. The participant deletion verification screen may include the project name, project number, owner name, project address and information about the participant to be deleted (for example, organization name, organization role, budget item, budget amount, payment amount, accumulated deduction and residual balance) . The participant deletion verification screen may include the ability to determine whether the participant participated in the project financially.

In FIG. 117, an affidavit change screen (affidavit statement) is presented, which may be associated with affidavit change task 358. The GP or subcontractor may access the affidavit change screen through the change order module 48. The affidavit change screen may include the project name, project number, owner name, project address, current project status, budget amount paid in advance on a certain date, amount held on a specific date, and residual budget. The affidavit change screen may include a field for entering comments and the ability to enter a password and allow the change of affidavit.

In FIG. 118 presents tasks 360 of maintaining project screens that may be included in the project management process 94. Tasks 360 to maintain project screens can be used to edit the project profile, contact information and to close the project. Tasks 360 to maintain project screens can be performed by the GP, lender, owner or owner’s representative using module 28 of the project. Tasks 360 to maintain project screens may include task 362 of the project profile, task 364 of project contact information, task 366 of project information, and task 368 of closing the project.

In FIG. 119 is a project profile form that may be associated with project profile task 362. The SOE, lender, owner or owner’s representative can access the project profile form through project module 28. The SOE, lender, owner or owner’s representative can enter the required information, such as project information, project financing information, project owner information, site information, and GP information.

In FIG. 120, a project contact information screen is provided, which may be associated with a project contact task 364. The SOE, lender, owner or owner’s representative can access the project’s contact information screen through module 28 of the project. The project contact information screen may include the name of the project, identification of the

- 29 015056 of the project, the project address and a list of contact information for project participants. The contact information list may include a participant identification number, organization name, organization role, project manager name, contact email address and contact phone number.

In FIG. 121 is a screen of contact information for a project that may be associated with task 366 of creating project information. The SOE, lender, owner or owner’s representative can access the project information screen through project module 28. The project information screen may include project information, site information, information about the project owner, and information about the SOE.

In FIG. 122, a project closure screen is presented, which may be associated with project closure task 368. The SOE, lender, owner or owner’s representative can access the project closing screen through project module 28. The project closing screen may include the project name, loan account number, owner name, and the option to close the project.

In FIG. 123, access screen management tasks 370 are presented that can be included in system environment management process 102. Access screen management tasks 370 can be used to configure various screens displayed for specific users or organizations during the payment process in construction. For example, access screen management tasks 370 may be used to include a trademark or organization logo in one or more screens displayed during a payment process in construction (for example, a lender’s trademark may be included in the upper right corner of each screen). In addition, access screen management tasks 370 can be used to change the appearance of specific forms or screens in accordance with the preferences or requirements of specific users or organizations. Access screen management tasks 370 may be performed by any of the participants using the administrator 52 of the system environment. Access screen management tasks 370 may include a login task 372, a logout task 374, a project homepage task 376, a password reset task 378, a main screen task 380, a project viewing task 382, a forgotten password task 384, and your task 386 password.

In FIG. 124, a login screen is provided, which may be associated with a login task 372. Each participant can access the login screen through the administrator 38 access. The participant can enter a username and password to log in. The login screen can provide communication if the user has forgotten his password.

In FIG. 125, a logout screen is provided, which may be associated with a logout task 374. Each participant can access the logout screen through the access administrator 38. The logout screen can confirm that the user has logged out.

In FIG. 126, a project homepage screen is provided, which may be associated with a project homepage task 376. Each participant can access the screen of the home page of the project through the administrator 38 access. The project home page screen may include the name of the project, the number of new posts, and links to read new posts. The project home page may include overview information on the project (including an indicator of the progress of the project schedule and an indicator of the progress of spending funds), information on the completed allocation of funds (including the number of allocation of funds, date of allocation of funds and links to information on allocation of funds), information on pending disbursements (including the number of disbursements and the start date). A project home page may include links to several actions, forms, or screens (e.g., project profile, project budget, presentation of project participants, setting account codes, managing project users, tracking approval of a title company, initiating unplanned disbursements, etc. )

In FIG. 127 shows a password reset screen, which may be associated with a password reset task 378. Each participant can access the password reset screen by the access administrator 38. The participant can enter a new password twice in order to change the password associated with a specific username.

In FIG. 128 is a main screen for a specific user, which may be associated with a main screen task 380. Each participant can access the main screen through the administrator 38 access. The main screen can list the projects in which the participant is involved, as well as the number of new messages associated with each project, and a link to read new messages.

In FIG. 129, a project view screen is provided that may be associated with a project view task 382. Each participant can access the screen for viewing projects through the administrator 38 access. The project view screen may include project search functionality and a list of projects. The list of projects may include the name of the project, the name of the GP, a link for editing the project, and the ability to select one or more projects to view.

- 30 015056

In FIG. 130, a forgotten password screen is presented, which may be associated with a forgotten password task 384. Each participant can access the forgotten password screen by the access administrator 38. The user can enter his username and email address, and the system can send the password to the user by e-mail.

In FIG. 131 a notification of your password is provided, which may be transmitted during task 386 of your password. The notification of FIG. 131 may include a statement that your password that you requested is emailed to you, a password, and an offer to use the password the next time you log in.

In FIG. 132 illustrates a message screen management process 388 that may be included in a system environment management process 102. The message screen management process 388 can be used to present messages, create messages, or present a system status message. The message screen management process 388 may be performed by any of the participants using the system environment administrator 52. The message screen management process 388 may include a message submission task 390, a special message submission task 392, a message creation task 394, and a status message task 396.

In FIG. 133 shows a message presentation screen that may be associated with a message presentation task 390. Each participant can address the task 390 of the message by the administrator 52 of the system environment. The message presentation screen may include a user name, the ability to determine the type of messages that are displayed (for example, unread, recent, all, sent messages or archived), and a list of messages of a specific type. The list of messages may include the ability to select specific messages, message dates, project name, subject of the message, and whether an action is required. The message presentation screen may also provide the ability to archive selected messages and move to another message screen.

In FIG. 134 shows a particular message viewed by the user. A particular message may include any of the notices shown and described in these materials.

In FIG. 135, a message creation / sending screen is provided that may be associated with message creation task 394. Each participant can access the message creation / sending screen through the administrator 52 of the system environment. The user can enter the name of the project, indicate whether to send a message to the organization or user, enter the names of organizations, user names, subject of the message and message.

In FIG. 136 is a status message screen that may be associated with a status message task 396. Each participant can access the status message screen through the administrator 52 of the system environment. On the status message screen, messages can be posted, such as a statement that the project has initiated a disbursement of funds and that all participants have been notified. The status message screen may include a link to the organization or user homepage.

In FIG. 137-153 presents a method of controlling a payment process in construction in accordance with another embodiment of the invention. Aspects of the method of FIG. 137-153 may be used in conjunction with the embodiment shown and described with reference to FIGS. 1-136 and 154-179.

In FIG. 154-179 shows input / output diagrams for a method of controlling a payment process in a building in accordance with yet another embodiment of the invention. Aspects of the method of FIG. 154-179 may be used in conjunction with the embodiments shown and described with reference to FIGS. 1-136 and 137-153.

In FIG. 155 presents the task of opening a project, the task of creating a timetable for allocating funds, and the task of identifying and assigning roles to the project, each of which can be performed by the GP. The task of entering the budget can be performed by the owner, representative of the owner, SOE, lender or title company. The task of updating parts can be performed by GP for subcontractors and / or suppliers of materials, either by the owner, lender, or title company for any type of participant. The task of closing the project can be performed by the title company, SOE or lender.

In FIG. 156 presents the task of entering project details, in which the system can assume that the project has full approval from all the necessary agencies and participating organizations before opening the project. FIG. 156 includes entering loan details, in which the lender can choose to enter only selected information for legal or business reasons. If there is no loan for the project, then no information is entered.

FIG. 157 contains the task of considering the proposed allocation schedule, in which the system can work out the proposed allocation schedule by equal allocation of the number of allocation of funds according to the proposed project schedule. FIG. 157 represents the task of accepting or rejecting the proposed allocation schedule, in which the SOE can manually declare the allocation of funds in accordance with the schedule (plan) established by the owner,

- 31 015056 by the representative of the owner, lender or SOE. An automated schedule can be rejected and a schedule can be maintained manually.

In FIG. 159 presents the input of a project budget for a participating organization where a hierarchical process can be used. At each level, a participating organization can perform a process for organizations that they use to support them.

In FIG. 160, the task of authorizing a change order is presented, in which the process of solving the problem may require the rejection of the original change order and the creation of a second change order, which is mutually agreed upon by all parties. In the decision process, only the final change order must be approved.

In FIG. 162 presents the task of adding an organization, in which the organization must be added before it can participate in the project. Organizations can add to the system by the system, title company, lender or SOE. Along with the fact that organizations can be added during the task of identifying and assigning roles to the project, the process of maintaining the payment plan for the project, organizations can be added independently of this process. In FIG. 162 presents the task of entering the details of the organization, in which the initial contact in the organization may be responsible for entering the details of his organization and additional contact information. Each organization can identify an internal system administrator who may be responsible for updating the details of their organization and contact information. In FIG. 162 presents the task of maintaining the details of an organization in which security requirements can be particularly stringent due to special requirements for financial information.

In FIG. 164 presents the task of checking the organization, which can be provided by a third party based on the requirements of the participants. The system makes it easier to verify organizations and charge a service fee.

In FIG. 166 presents the task of announcing a disbursement of funds that can be performed by the SOE. The disbursement of funds is a mechanism by which project participants can submit invoices, the owner (usually through a GP) can pay for the work done, and the parties involved can receive a payment and withdraw their respective refusals to withhold. In FIG. 166 presents the task of making a sworn statement, in which the GP can review filings online (with reference to paper documents, if necessary) and, if the filing is correct, the system can generate a sworn statement based on information that was electronically submitted parties involved in the allocation of funds. SOEs may reject submissions, and they may be reviewed and resubmitted for approval. This mechanism can be used to resolve any issues with the account. In FIG. 166 presents the task of requesting an inspection, which can usually be performed by the lender or title company. In FIG. 166 presents the task of authorizing the allocation of funds, which can usually be performed by the lender, but may require the involvement of the owner, representative of the owner or other designated project participant. A configurable permission mechanism can include any project participant in the authorization process. In FIG. 166 presents the task of introducing and resolving denial of retention, which may be required to complete the allocation of funds. Funds do not transfer invoicing parties until refusals to withhold the parties are introduced and organized. This requirement guarantees essentially the simultaneous execution of a waiver of withholding and payment. In FIG. 166 presents the task of performing a simultaneous payment / waiver of deduction, in which essentially the simultaneous exchange of the refusal of deduction for payment is automated. Such an automated exchange can eliminate the need for appointments and can eliminate time delays between issuing a hold refusal and payment. Such an automated exchange reduces the likelihood that the refusal to withhold will be lost, and allows you to accelerate the payment to all participants in the allocation of funds, eliminating intermediate organizations from the payment process.

In FIG. 167 presents the task of declaring a allocation of funds in which an electronic message can be sent essentially simultaneously to all participating and / or interested organizations.

In FIG. 168 presents the task of entering the details of the account, which can be performed by any party that wishes to receive payment through the process of allocating funds. Electronic submission may be accompanied by paper documents that accompany the submission. A service may be provided that allows parties to submit supporting information by scanning.

In FIG. 169 presents the authorization task of the account, in which the process of solving the problem may require the rejection of the initial account and the creation of a second account, which is mutually agreed by all parties. Only the final account will be approved in the decision process.

In FIG. 170 presents the task of selecting an inspector, in which more than one inspector can be associated with a project. In this case, the correct inspector must be selected to carry out the inspection.

- 32 015056

In FIG. 171 presents the task of confirming the scope of the inspection, in which the organization that requested the inspection can determine the scope of the inspection, either for the entire affidavit or for a shortened version of the affidavit. In FIG. 171 presents the task of entering the results of the inspection, in which supporting documentation may be necessary depending on the volume and nature of the inspection.

In FIG. 171 presents the task of sending supporting documentation, in which the system can allow you to attach files with digital photographs or other electronic material to electronic inspection reports.

In FIG. 173, the task of organizing a waiver of deduction is presented, in which an electronically signed waiver of deduction can be organized in a system that is protected from any changes. In one embodiment of the invention, a waiver of deduction is not issued to the title company until a substantially simultaneous exchange of payments and waivers of deduction occurs.

In FIG. 174 presents the task of confirming authorization of the allocation of funds and organized refusals of withholding, which may include an overview of all refusals of withholding to ensure that they are complete and correct.

In FIG. 178 presents the task of providing user support, which may include support for adding or modifying organizations or projects, resolving password problems, resolving projects and transactions. In FIG. 178 presents the task of administering a system, which may include administering security, financial audit, and support in case of unforeseen circumstances. In FIG. 178 presents the task of maintaining a history of actions for participants in the system, which may include a directory of sellers with a history of sellers and / or seller ratings.

In some embodiments, the EMSS 10 can help users (e.g., general contractors) track the compliance of project participants (e.g., subcontractors) with specific legal standards, such as various types of required documents. These legal standards may vary from project to project depending on the location, owner, title company, general contractor or subcontractor. In some embodiments, because of the relationship between the matching of a particular participant and the payment that is intended for the participant, EMS 10 allows you to track the documents required of the participants (for example, legal documents), provide assistance in managing such documents, offer warnings about inconsistencies, and in some cases delay payment when the documents are not in order.

As shown in FIG. 180, in some embodiments, the SUMS 10 may include a document tracking module 400. The document tracking module 400 may assign and track documents such as contracts, payment applications, affidavits, insurance documents, pre-pledge retention notices, refusal of deductions, etc., received from participants (e.g., subcontractors and / or subcontractors of subcontractors ) related to the project, and can provide warnings and suggest options for enforcing compliance through the payment process, up to and including automatic delay in payment. Documents can be associated with a specific project, a specific budget item in a project, or with a specific participant or organization. It is obvious that documents may include paper documents and electronic documents.

To identify, assign, and track documents for a project, the EMS can 10 support information objects that define one or more documents to be monitored by document tracking module 400.

Document type information objects can define standard document types and features of standard document types monitored by the EMS 10. SMS 10 can use document type information objects to recognize the standard differences in documents tracked for each project and to identify the nature of warnings and options for enforcing compliance for each type of document. For example, each information object of a document type may include a document name and a list of valid statuses (for example, Incomplete, Unsigned, Signed, Unreceived, Received, Active, Expired, etc.). Although other types of legal documents may be appropriate in different circumstances and in different jurisdictions, the three typical types of legal documents may include an agreement with the current statuses Incomplete, Unsigned and Signed; a form with valid statuses Unearned and Received and a certificate (certificate) with valid statuses Not received, Active and Expired.

EMS 10 can also provide a table of requirements for project documents, where the project manager can create a list of documents that are required from each subcontractor for a particular project. For discussion purposes, the term subcontractor is used to refer to traditional subcontractors and subcontractors for subcontractors as well as material suppliers. In addition, in some embodiments, the ability to track legal documents can be applied to both intra-system and non-system subcontractors and material suppliers.

- 33 015056

A table of requirements for project documents can identify a project identifier, type of legal document, and document name. The name of the document may be entered by the project manager and may include values such as Subcontracting, Insurance Certificate, City License, etc. For discussion purposes, the term project manager is used to indicate a participant above the line (for example, the general contractor, project owner, title company, etc.) or a participant below the line (for example, the subcontractor defining document requirements for subcontractors holding a contract with the subcontractor) .

The EMSS 10 may also use another information object to track the compliance status of each subcontractor in relation to requirements for project documents. For example, EMSS 10 may use a project subcontractor document table that includes a project identifier, a document name, a subcontractor identifier, a document status, a document identifier (e.g., optional), and a document expiration date (e.g., optional). In FIG. 181 presents a conceptual data model for data objects related to document tracking.

In some embodiments, system 10 may also allow the project manager or subcontractor to create new types of documents to meet the specific needs of the project manager or subcontractor, taking into account the nature of the project or the legal requirements of the jurisdiction, or the country of the participants, or the country of the project. Optionally, the system may provide the project manager or subcontractor with a screen or other mechanism to assist the user in creating a new type of document.

In some embodiments, instead of determining specific types of documents, system 10 determines a single type of document that is applicable to all types of documents with a single set of statuses. A single document type can define one or more data elements, such as a document identifier, document dates, and expiration dates for a specific document required from a participant (eg, subcontractor). In some embodiments, each of the data items may be optionally used. If the project manager enters an expiration date, the document tracking module assumes that the document expires on the expiration date and tracks the expiration date. Each document defined under a single document type is also associated with a status (for example, Unreceived, Received, Not Applicable). In some embodiments, the default status for each document may be set to Not Received.

Using the aforementioned single type of document, after the project manager selects one or more documents that are required from subcontractors associated with a particular construction project, system 10 can automatically view the status of the documents and dynamically determine if the document is active or has expired. For example, if a document has the status Not Received or Not Applicable, system 10 may decide that the document is neither active nor expired. Similar to images, a document with the status Received, but without an expiration date, system 10 is assumed to be active. In addition, a document with the Received status and with an expiration date, system 10 is considered active if the system or current date is earlier than the document expiration date, and is considered to have expired if the system or current date is later or equal in relation by the expiration date of the document. System 10 can dynamically evaluate whether a document is active or has expired when such information is needed for processing or display.

In FIG. 182A presents page 450 of the document requirements. The project manager can use the document requirements page 450 to select one or more documents to request or require from subcontractors related to a particular construction project. The project manager can refer to page 450 of the communication document 452 on the project home page 454, as shown in FIG. 183. In some embodiments, the EMSS 10 only addresses the project manager to page 450 of the document requirement.

Page 450 of the document requirements allows the project manager to build a table of the necessary legal documents for the project. A table can support any number of rows (for example, from zero to infinity) and can allow a project manager to add a document, select a document to delete, and / or select a document for editing. In some embodiments, the table included in the document request page 450 displays a document type column that includes a drop-down offer of document types that are predetermined by the system, and a document name column that includes an alphanumeric area for the user to enter and / or editing.

As shown in FIG. 182A, page 450 of the document requirement may display a project number, a project identifier, and a list of one or more documents that are required from subcontractors associated with the project. For each list document, the project manager may use a selection mechanism 456 (e.g., a radio button) to select at least one enforcement action. Enforcement action defines at least one action

- 34 015056, which will be automatically executed by system 10 if the subcontractor does not provide the required document. For example, an enforcement action may include a Only Notify action, which includes automatically notifying the project manager of a missing document. The enforcement action may also include the Delay Payment action, which includes the automatic delay in payment to a subcontractor that does not provide the required document.

As also shown in FIG. 182 A, the project manager may optionally track the expiration of the required document. For example, the project manager may use the expiration tracking selection mechanism 458 (e.g., a check mark) associated with a particular document to determine whether to track the expiration of a document. In some embodiments, if the project manager selects an expiration tracking selection mechanism 458 for a particular document, the project manager can determine one or more days of notification using input or selection mechanisms 460 for selecting one or more days of notification. System 10 can use notification days to determine how many days before the document expires; system 10 should alert the project manager and / or subcontractor that the document is close to expiration. In some embodiments, the project manager may determine multiple days of notification for a particular document. For example, as shown in FIG. 182A, the project manager may determine the first days of notification and the second days of notification. In some embodiments, if the project manager determines the zero days of notification, system 10 will not send any expiration alerts or notifications before the document expires. Even if the project manager determines the number of days of notification, the system 10 can notify the project manager when the deadline for the document has expired. The default value of notification days can be set to zero.

The document requirement page 450 may include a request addition selection mechanism 462. The project manager can choose the mechanism for choosing to add a requirement to add a document to the list of required documents. Additionally, the document request page 450 may include one or more document removal selection mechanisms 464 that the project manager can use to remove one or more documents from the list of selected documents. As shown in FIG. 182A, the project manager may also save or commit modifications made to documents required by the project by selecting the settings save selection mechanism 466 included in the document request page 450. In addition, the project manager can undo any modifications made to the documents listed on page 450 of the document requirement by selecting a deselection mechanism 468.

In some embodiments, system 10 may automatically select and assign one or more documents and / or document options to a particular project. For example, system 10 may automatically select withholding waivers to be monitored and assign an enforcement action to delay payment with respect to requested waiver waivers. EMS 10 can also provide one or more document requirements pages, similar to document requirements page 450, which allow the project manager to determine document requirements at levels other than the project level, such as organization level, budget level, budget line item level, contract level, etc. d. For example, EMS 10 can provide a document requirements page that allows a project manager to determine the requirements of organization level documents that define the documents required from each organization that is in charge of a project manager, regardless of the particular project the organization is associated with.

After the project manager assigns document options and / or requirements for a specific project, the EMS can 10 generate a document request notification 469a, as shown in FIG. 182B. The EMSS 10 may display a notification 469a of a document requirement to a subcontractor associated with the project, either before or after the subcontractor assumes responsibility for the assigned tasks of the project. As shown in FIG. 182B, a document requirement notification 469a may indicate each document required by a participant and the enforcement action associated with the document. If the project manager changes the document requirements for the project (for example, using the document requirements page 450), system 10 may generate a notification 469b for modifying the document requirements, as shown in FIG. 182C. System 10 may display a notification 469b to each participant (e.g., a subcontractor or material supplier) associated with the project. In some embodiments, as shown in FIG. 182C, a document requirement modification notification 469b may include a relationship 469c that a participant may select to present a separate document status page 490, as described below with respect to FIG. 185B, to represent the status of a document required from a participant.

In FIG. 184 is a document status summary page 470 in accordance with one embodiment of the invention. The project manager can use the document status page 470 to enter information about the compliance of a particular subcontractor with the document requirements for the project. In some embodiments, the project manager may move to the consolidated

- 35 015056 page 470 of the document status, selecting a link 472 included in the project home page 454 of the project manager, as shown in FIG. 183.

As shown in FIG. 184, the document status summary page 470 may display the status of one or more documents that require all subcontractors associated with the project in a single presentation or page. The document status summary page 470 can represent the project name, project number, a list of all subcontractors for the project (for example, only the first level or multiple levels) and a column for each document tracked by the project that defines the name of the required document (for example, as determined by the project manager) . For each document included in the document status summary page 470, the document status summary page may represent a status value, an expiration date (if applicable), detention status, and late payment information for each subcontractor.

In some embodiments, as shown in FIG. 184, the status of each document may be indicated by a specific color or other visual representation. For example, if a document has the status Not Received, the cell associated with the document may be colored orange, indicating that the document is missing. If the document has the status Received, the document is active and the expiration date for the document is 60 days or more from the system or current date, the cell associated with the document may be colored green, indicating that the document is considered valid. If the document has the status Received, the document is active and the expiration date of the document is within 60 days after the system date, the cell associated with the document can be colored yellow, indicating that the document is within 60 days before the expiration. If the document has the status Received and the document has expired, the cell associated with the document may be colored red, indicating that the document has expired. Similarly, if the document has the status Not Applicable, the cell associated with the document may be grayed out, indicating that the document is not applicable to the subcontractor.

As shown in FIG. 184, if the document has a status indicating that the document is within 60 days before the deadline or if the deadline has already expired, the document status summary page 470 may display the deadline for the document. In addition, if the status of the document indicates that the document was not received or the deadline has expired, and the document is assigned the enforcement value Delay Payment, the document status summary page 470 may indicate that the payment was delayed on the basis of the fact that the document was not received or the deadline for expired him. In addition, if the payment is delayed, the document status summary page 470 may display previous payments also delayed due to missing or expired documents. In some embodiments, for each delayed payment, the document status summary page 470 may display the delayed payment as long as the payment is delayed. If more than one payment to a single subcontractor is delayed in a specific allocation of funds, the document status summary page 470 may also display a list for each delayed payment. As shown in FIG. 184, the document status summary page 470 may also include a disbursement communication 471 that includes a late payment. In some embodiments, the project manager may use the disbursement relationship 471 to present the payment management page 585, as described below with respect to FIG. 197A, 197B.

In some embodiments, the document status summary page 470 may also include a link associated with each of the subcontractors listed that the project manager may select to view document information for a particular subcontractor. For example, each subcontractor listed on the document status summary page 470 may include a relationship 472 that the project manager may select to view a separate document status page 480, as described in relation to FIG. 185A.

As shown in FIG. 184, the document status summary page 470 may also include a document requirements editing link or other selection mechanism 474 that the project manager may select to access the document requirements page 450 and view and / or edit the requirements of the project document.

As also shown in FIG. 184, the document status summary page 470 may include a link 473 to the sub-contract document report and a link 475 to the document submission report. The project manager may choose to link 473 to the sub-contract document report to view a report indicating the status of all documents requested from the sub-contractor for one or more projects. Similarly, the project manager may choose to link 475 to the document report for the document to view a report indicating the status of a particular document for one or more subcontractors for one or more projects.

In some embodiments, the information displayed on the document status summary page 470 may be updated when the project manager makes changes to the documents required for a particular project (for example, makes changes to the document requirements table for the project). When such changes are made, the legal document tracking table and the document status summary page 460 are updated by either adding or

- 36 015056 deleting lines and changing the names of documents. For example, if the project manager adds a new document to the legal document requirements table for the project, new lines are added to the legal document tracking table, one row for each subcontractor that shows the document name (for example, from the legal document tracking table) and the initial status for document. In some embodiments, the initial status of the new document is automatically set as one of the valid statuses associated with the document type (for example, a new document by agreement type would have an initial default status value of Not completed). The project manager can update the table and / or the document status summary page at any time during the project.

As previously disclosed, the project manager may select the relationship 472 associated with the subcontractor indicated on the document status summary page 470 to view a separate document status page 480, as shown in FIG. 185A. As shown in FIG. 185A, a separate document status page 480 may display a table with multiple columns and one row for each document that is requested from a particular subcontractor (for example, as identified in the legal document requirements table for this project). A subcontractor (and project) associated with a single document status page 480 may be identified at the top of page 480. Columns may include a document title column, which in some embodiments is not editable; a document status column that includes a drop-down menu or other types of selection mechanisms 482 that offer valid statuses for the document based on the type of legal document associated with the documents; the column of the document identifier present, if necessary, which will be an alphanumeric field; and present, if necessary, a column of the expiration date of the document, which includes a date field. A separate document status page 480 may also include a column that indicates the enforcement action associated with a particular document.

As shown in FIG. 185A, a separate document status page 480 displays a document identifier. In some embodiments, system 10 automatically sets a document identifier based on a document received from a subcontractor. For example, system 10 may randomly assign a unique identifier to a document received from a subcontractor. The project manager or subcontractor may also assign a unique identifier to the document.

For each document presented on a separate document status page 480, page 480 displays the document date and the expiration date. In some embodiments, the project manager sets a document date and an expiration date for a particular document. For example, the project manager may set the document date to the date that the document was completed or received by the project manager. The dates entered by the project manager using a separate document status page 480 can be confirmed by system 10. In some embodiments, system 10 can also automatically set the document date and / or expiration date for a specific document.

As shown in FIG. 185A, a separate document status screen 480 also displays the enforcement actions assigned to each of the requested documents. As previously disclosed, enforcement actions determine actions automatically taken by system 10 if the subcontractor does not provide the required document.

As also shown in FIG. 185A, a single document status page 480 may include a document action column that indicates one or more actions that a project manager can perform for a given document. For example, if a subcontractor has provided a specific document, the document action column may include a presentation link 483. The project manager may select a presentation link 483 to view the submitted document. Other actions included in the document action column may include an upload link to upload the submitted document, an edit link to edit the submitted document, a delete link to delete the submitted document, and a presentation link to present the document on behalf of the subcontractor.

If the project manager makes any modifications to the data displayed on a separate document status page 480, the general contractor may select the save updates selection mechanism 484 included on page 480 to save the changes, or may select the deselect mechanism 486 included on page 480 to discard changes. In some embodiments, modifications that are stored from a separate document status page 480 are automatically reflected in the document status summary page 460.

System 10 may also provide a version of a single document status page 480 to a subcontractor that is associated with document information included in a particular separate document status page 480. The page version 480 provided to the subcontractor may include a page view version 480 only (for example, an uneditable version that is provided to the project manager). As shown in FIG. 185B, separate page 490 of the statue

- 37 015056 This document, for viewing purposes only, displays the project (for example, name or identifier) and the participant or organization (for example, name or identifier). In some embodiments, the subcontractor may refer only to viewing a separate document status page 490 using links 491 in the project homepage 500, as shown in FIG. 185C.

As shown in FIG. 185B, a view-only version of a single document status page 490 may display information similar to information displayed on an editable version of a single document status page 480. For example, a view-only separate document status page 490 may display the document name, document status, document identifier, document date, expiration date, and enforcement action for each document required by the subcontractor. In some embodiments, the EMS of 10 may prevent the subcontractor from changing any data displayed in a view-only version of the page 490.

The version of a single page 490 of the document status that allows only viewing can also include a column of actions on the document, which represents one or more actions that a subcontractor can perform for this document. For example, a document action column may include a feed link 492. The subcontractor may select the feed link 492 associated with the specific document presented on page 490 to electronically submit the desired document to the system 10. Other actions contained in the document action column may include a view link to view the submitted document, an edit link to edit the filed document and delete link to delete the filed document.

If the subcontractor selects a filing relationship 492 associated with a particular document, system 10 may display a document filing page 510, as shown in FIG. 186 A, 186V. The subcontractor may use the document submission page 510 to select one or more documents for electronic submission to the system 10. In some embodiments, the document submission page 510 may include a viewing selection mechanism 512 that the subcontractor may select to search in one or more memory devices and / or file directories for a particular document. Documents found and selected by the subcontractor when viewing the memory device and / or file directories can be displayed in the input mechanism 513. The subcontractor may also directly enter a file name (eg, full path name) for a particular document using the input mechanism 513, in addition to viewing the document or instead of viewing using the viewing selection mechanism 512.

Once the subcontractor finds and selects or enters a specific document for submission, the subcontractor may select the application add selection selector 514 included in the document submission page 510. The subcontractor may also select a cleaning selection mechanism 516 included in the document submission page 510 to clear the document or file name displayed in the input mechanism without submitting the document to the system 10.

As shown in FIG. 186B, documents added or attached by a subcontractor using the application add selection mechanism 514 may be indicated on the document submission page 510 under the heading of the Application. The subcontractor may delete or move one or more attached documents by selecting a deletion selection mechanism 518, such as a marking position associated with a particular document. After the subcontractor has selected one or more attached documents for deletion, the subcontractor may select a deletion selection mechanism 520 of the selected document included in page 510 to delete the selected documents from the list of attached documents.

Once the subcontractor has attached one or more documents, the subcontractor can select the submission mechanism 522 included in the document submission page 510 to electronically transfer the attached documents to the system 10. After the subcontractor submits the attached documents to the system 10, the system 10 may generate a notification 524 on transmitted documents, as shown in FIG. 187. System 10 may display a notification 524 of transmitted documents to a subcontractor.

After the subcontractor submits this one or more attached documents, the system 10 may also generate an action or notification of the project for viewing the submitted documents and may send the project action to the project manager who is to receive the submitted documents. In some embodiments, the system 10 represents a project action for viewing submitted documents under pending project manager actions on the project home page 526, as shown in FIG. 188. If the project manager selects the project action or the corresponding selection mechanism from the project home page 526, the system 10 may display a notification 528 about the receipt of the document, as shown in FIG. 189. Notification 528 may notify the project manager that the subcontractor has submitted an electronic copy of one or more of the required documents. In addition, notification 528 of the receipt of a document may indicate one or more documents received electronically from a subcontractor.

- 38 015056

Document receipt 528 may also notify the project manager that he or she must upload each submitted document. In some embodiments, as shown in FIG. 189, for uploading and viewing the submitted document, the project manager may select a selection mechanism 530 associated with the received document (for example, the relationship associated with the specified document) in the notification 528 on receipt of the document. If the project manager selects the selection mechanism 530, the system 10 can upload and display the filed document to the project manager.

After the project manager reviews the submitted document, the project manager can update the status of the document monitored by system 10, if necessary. For example, as shown in FIG. 189, a document receipt notification 528 may include a mechanism 532 for selecting document update information. If the project manager selects the document update selection mechanism 532, the system 10 may display a separate document status page 480, as described in relation to FIG. 185A related to the subcontractor that filed the document. As described above, the project manager can make changes to the data displayed on a separate document status page 480, and can select the update saving selection mechanism 484 included in page 480 to save the changes. In some embodiments, if the project manager changes the data displayed on a separate document status page 480, system 10 may generate a notification 540 to update the document information, as shown in FIG. 190. System 10 may display a notification 540 about updating document information to a project manager.

In some embodiments, only the project manager can update the document information. In other embodiments, in addition to being manually changed by or in lieu of the project manager, system 10 can update or change document information automatically. For example, system 10 may automatically change the status of a document to Received after a subcontractor submits a document to system 10.

In some embodiments, system 10 performs a normal or periodic scan (e.g., at night) of documents to identify expired documents. For example, in batch mode, system 10 can check any document for expiration on a regular basis (for example, daily), for example during small use of the system (for example, before 5:00 in the morning). As shown in FIG. 191, the system 10 can view documents managed by the system, and for each document can determine whether the status of the document is set to Received. If the status of a particular document is not set to Received, system 10 looks at another or the next document managed by system 10.

If the document viewed by system 10 has a status that is set to Received, system 10 can determine whether the document is associated with an expiration date (for example, the expiration date attribute associated with the document is set to a specific date). If the document is not associated with an expiration date (for example, the expiration date attribute associated with the document is set to zero), system 10 can view another or the next document managed by system 10.

If the document viewed by system 10 is associated with an expiration date, system 10 can determine if the current or system date is greater than or equal to the document expiration date minus the number of days set by the project manager for the first notification. If the system date is less than the document expiration date minus the number of days of the first notification, the system 10 can determine that the document has not expired and that the expiration notice is not required, and can view another or the next document managed by system 10.

If system 10 determines that the system date is greater than or equal to the expiration date of the document minus the number of days of the first notification, system 10 can determine whether the first notification has already been sent regarding the document. In some embodiments, system 10 may monitor whether or not expiration notifications have been transmitted. If the first notification has not yet been sent, system 10 may send the first warning notification of the expiration of the term. In some embodiments, system 10 sends a first expiration warning to a subcontractor associated with the document and / or project manager. In FIG. 192, an expiration warning notice 550 is provided in accordance with one embodiment of the invention.

As shown in FIG. 191, if system 10 determines that a first notification has already been sent for a specific document, or after system 10 sends a first notification for a specific document, system 10 determines whether the current system date is greater than or equal to the document expiration date minus the number of days associated with the second notice established by the project manager. If the system date is less than the document expiration date minus the number of days associated with the second notification, system 10 may view another or the next document managed by system 10.

- 39 015056

If system 10 determines that the system date is greater than or equal to the document expiration date minus the number of days associated with the second notification, system 10 can determine whether a second notification has already been sent associated with the document. If a second notification has not yet been sent, system 10 may send a second warning expiration notification (for example, an expiration warning notification 550 shown in FIG. 192).

If system 10 determines that a second notification has already been sent for a specific document, or after system 10 sends a second warning expiration notice for a specific document, system 10 can determine if the current system date is greater than or equal to the expiration date by to the document. If the system date is less than the document expiration date, system 10 may view another or the next document managed by system 10.

As shown in FIG. 191, if system 10 determines that the current system date is greater than or equal to the expiration date for a particular document, system 10 can determine whether an expiration notice has already been sent for the document. If a notice of expiration has already been sent, system 10 may view another or the next document managed by system 10.

If an expiration notification has not yet been sent, system 10 may send an expiration notification. In some embodiments, system 10 may send an expiration notification to a subcontractor associated with an expired document and / or project manager associated with the project.

In FIG. 193, expiration notification 522 is provided in accordance with one embodiment of the invention. After sending a notice of expiration, the system 10 may view another or the next document managed by the system 10.

When a disbursement is initiated (or when a subcontractor is added or selected for disbursement), the system 10 can also check the status of all documents that are required from each subcontractor included in the disbursement, and, if necessary, generate a project action or notification on the submission of the document for each subcontractor with missing or expired documents. For example, if the status of the document that is required from the subcontractor is set to Not Received, system 10 may generate a design action for submitting the document that requires the missing document. In addition, if the status of the document that is required from the subcontractor is set to Received, and the corresponding expiration date is within a predetermined time after the date of allocation of funds (for example, 60 days), or is up to or equal to the date of allocation of funds, the system 10 may also work out a project filing action requiring a new document.

In FIG. 194 presents a design action or notification 560 of the need for an updated document in accordance with one embodiment of the invention. In some embodiments, the subcontractor may access the notification 560 through a link or selection mechanism 562 included in the subcontractor's homepage 500, as shown in FIG. 185B.

As shown in FIG. 194, notification 560 about the need for an updated document may include a selection mechanism 564 that the subcontractor can select to view the status of documents that are required from the subcontractor and / or submit the required documents (for example, using a separate document status page 490).

In cases where the project manager has selected the Delay Payment action as the enforcement value for a specific document, system 10 (for example, after the project manager has signed his account) can automatically delay the payment for any subcontractor that has missing or past due documents for which the manager The project appointed enforcement action to Delay Payment. For example, system 10 may view the status of required documents for each subcontractor included in the disbursement of funds, and may determine whether the document associated with the subcontractor has the status Not Received or is past due. If the document was not received or was overdue, system 10 can determine whether the document is associated with the enforcement action of Delay Payment. If an expired or missing document is related to the Delay Payment enforcement action, system 10 may delay the payment for a subcontractor associated with the document. In some embodiments, the system 10 requires only one document violation (for example, the subcontractor does not have one document of the three required documents) before it automatically delays the payment to the subcontractor. If the subcontractor has missing or past due documents, system 10 can only delay the payment associated with the subcontractor for the current allocation of funds and does not delay any other upcoming payments related to other allocation of funds. In other embodiments, if the subcontractor has missing or past due documents, system 10 may delay the subcontractor with all pending payments.

- 40 015056

When system 10 delays a payment, system 10 can record a delayed payment (for example, record reasons for a delay in payment indicating that the payment was delayed due to missing documents or documents with an expired deadline) and may generate one or more notifications or warning messages relevant persons about the delayed payment. As shown in FIG. 74B, described previously, a disbursement request submission form may indicate any late payments (e.g., automatically or manually delayed) that will not be included in payments spent for the disbursed funds.

If a payment is delayed for a particular subcontractor, system 10 may generate a delayed payment notification 570, as shown in FIG. 195A. System 10 may display a notification 570 of late payment to a subcontractor (for example, by a connection included in all message display screen 572, as shown in FIG. 195B). As shown in FIG. 195A, delayed payment notification 570 may inform the subcontractor that a delay has been imposed on the payment to the subcontractor. In some embodiments, the delayed payment notification 570 may also include one or more relationships or selection mechanisms that the subcontractor may choose to view the delayed payment and / or take an action to reconcile the delayed payment.

In some embodiments, if the payment to the subcontractor to be delayed is flagged as a specific payment method, system 10 may simply notify the project manager of the payment to be delayed, rather than automatically delaying the payment. For example, if a payment to a subcontractor to be detained is flagged as a payment that will be made outside the system 10 (for example, by manual verification), the system 10 may generate a payment due on the design action or the notification 580 of the delay, as shown in FIG. 196. System 10 may display a notification 580 of a payment due to be held by the project manager. Notification 580 of the payment to be detained may inform the project manager that payment to a particular subcontractor should be delayed due to missing or expired documents. The notice 580 of the payment to be detained may also indicate the payment method associated with the payment. Furthermore, as shown in FIG. 196, notification 580 may indicate that if the project manager wants to change the payment method associated with the payment (for example, change the payment method to a method managed within system 10), the project manager should put the payment on hold. Notification 580 of the payment to be withheld may also include a link or other selection mechanism 582 that the project manager may choose to view the status of documents associated with the subcontractor whose payment is to be withheld (for example, through a separate document status screen 480 associated with subcontractor).

As previously described with respect to page 450 of the document requirement, the project manager can assign an enforcement action to Notify Only on the required document. Similar to the Delay Payment enforcement action, after the project manager has signed his payment request, system 10 can send the project action or notification of viewing documents to the project manager for subcontractors who have missing or expired documents. For example, system 10 can view the status of documents that are required from subcontractors included in the disbursement of funds, and if the required document has the status Not received or is expired, system 10 can generate a project action or notification of viewing the document and can display a project action or notification to the project manager . In some embodiments, system 10 may generate a design action or notification of viewing a document for each subcontractor that has expired or missing documents. In other embodiments, system 10 may generate a single design action or document viewing notification that indicates all subcontractors that have expired or missing documents. A project activity or document view notification can include a link or selection mechanism that the project manager can select to view the status of documents that are required from one or more subcontractors associated with the project action or document view notification (e.g., a separate document status page 480 or document status summary page 470).

In some embodiments, only the project manager can release the late payment through a manual payment release using the payment management page 585, as described below with respect to FIG. 197A, 197B. In other embodiments, system 10 may automatically release a late payment. For example, as soon as the documents requested from the subcontractor become compliant, the system 10 can automatically release any of the late payments to the subcontractor.

To release late payments manually, the project manager can use the payment management page 585, as shown in FIG. 197A, 197B. As shown in FIG. 197A, 197B, page 585 of the payment management may indicate each payment delayed by a specific allocation of funds. The payment management page may also indicate each payment made for a specific allocation of funds.

- 41 015056

As shown in FIG. 197A, 197B, payment management page 585 may include a retention waiver viewing selection mechanism 586, a document tracking selection mechanism 587, and a disbursement request presentation selection mechanism 588. The project manager may select a retention of denial of hold retention mechanism 586 to view retention denial failures filed by each subcontractor associated with the allocation of funds. The project manager may select a document tracking selection mechanism 587 to view the status of documents submitted by each subcontractor related to the allocation of funds (for example, through the document status summary page 470). The project manager may select a allocation request request submission mechanism 588 to view the details of the allocation of funds (for example, through the presentation screen of a pending allocation request, as described previously with respect to FIGS. 60A, 62, 68A, 72 or 74A, 74B).

For each subcontractor (or payment) indicated on the payment management page 585, page 585 may include a selection mechanism 589 or an editing link that the project manager may choose to edit the payment information associated with a particular subcontractor. In some embodiments, if the project manager selects the edit link 598 associated with a particular subcontractor, system 10 may display a page

590 payment management, as shown in FIG. 198A, 198B. Using the payment management page 590, the project manager can change information related to the payment made to the subcontractor.

As shown in FIG. 198A, 198B, payment management page 590 may include a check execution selection mechanism 591, a payment split selection mechanism 592, and a delay removal selection mechanism 593. To change the payment method associated with the payment (for example, changing the payment method to a method that is controlled outside the system 10), the project manager can choose a mechanism

591 choices for performing verification. In some embodiments, changing the payment method associated with the payment to a method controlled from outside the system 10 can automatically release the delayed payment. If the project manager selects the check execution selection mechanism 591, system 10 may automatically update the payment method displayed on the payment management page 590, may display a separate payment method change page, or may allow the project manager to update the payment method displayed on the payment management page 590.

To split the payment into multiple sub-payments, the project manager may select a payment splitting selection mechanism 592. For example, the project manager may choose a split payment mechanism 592 if the project manager wants to pay the subcontractor through multiple sub-payments, rather than a lump sum payment. In some embodiments, if the project manager selects a payment split selection mechanism 592, system 10 may display a separate payment split form or may allow the project manager to edit the payment amount displayed on the payment management page 590.

To release a delayed payment, the project manager can select the release in the retention selection mechanism 593. In some embodiments, the project manager may also provide reasons or comments for the release of the late payment using the comment input mechanism 594, as shown in FIG. 198A, 198 B. If the project manager selects an exemption from the delay selection mechanism 593. the system 10 can change the payment status displayed on the payment management page 590 from Delayed to Required, as shown in FIG. 198B.

If the project manager makes any changes to the payment information displayed on the payment management page 590, the project manager may select the save change selection mechanism 595 included in the payment management page 590. If the project manager saves the changes made to the payment information, the system 10 may update the payment management page 590, as shown in FIG. 198C and may update the payment management screen 585 as shown in FIG. 197B. Alternatively, in order to ignore any changes made to the payment information displayed on the payment management page 590, the project manager may select a cancellation selection mechanism 595 included on page 590.

In some embodiments, the payment management page 590 may include other selection mechanisms. For example, if a payment has not been made, the payment management page 590 may include a payment delay selection mechanism that the project manager can use to manually delay the payment.

In some embodiments, the payment management page 585, which indicates all payments for a particular disbursement, may be combined with the payment management page 590, which contains payment information associated with a specific payment, and allows the project manager to modify the payment information in order to create the page 600 payments, as shown in FIG. 198p. In some embodiments, the payment page 600 may display

- 42 015056 all payments for a specific allocation of funds. In other embodiments, the payment page 600 may only display late payments for a specific allocation of funds. As shown in FIG. 198C, the project manager may use the payment page 600 to delay or release one or more disbursement payments. For example, each payment displayed on the payment page 600 may be associated with a selection mechanism 602 (for example, a check mark) that the project manager may select to select a particular payment. After the project manager has selected one or more payments, the project manager may select the payment delay payment selection mechanism 603 included in the payment page 600 in order to delay all selected payments. Alternatively, the project manager may select the selected payments release mechanism 604 to release all selected payments. In some embodiments, the project manager may also enter reasons or comments on the delay or release of a particular payment using the comment input mechanism 605 included on the payment page 600. Using the selected payment retention selection mechanism 603 and the selected payment release selection mechanism 604, the project manager can manually delay and release payments. In some embodiments, as previously disclosed, the project manager may manually delay and release payments for various reasons other than missing or expired required documents.

In some embodiments, if the project manager manually releases the late payment, system 10 may require authorization from an authorized user associated with the project manager. For example, to request authorization of the released payment from a specific user associated with the project manager, system 10 may generate a special action or notification of expenditure on the project and may indicate the action or notification of the project on the home page 610 of the authorized user, as shown in FIG. 199. A project action or notification may include a link or other selection mechanism 612 that an authorized user may select to view the payment management page 620, as shown in FIG. 200. The payment management page 620 may include information and selection mechanisms, similar to the payment management page 585, but may include a fund spending selection mechanism 622. After an authorized user views the released payment, the user can select the fund spending selection mechanism 622 to authorize the release of the delayed payment. After an authorized user selects a fund spending selection mechanism 622, system 10 may generate a payment notification 630, as shown in FIG. 201. The system 10 may display to the authorized user a notification 630 of the payment 630 paid.

It will be apparent to one of ordinary skill in the art that embodiments of the invention may be implemented using various computer devices, such as personal computers, servers, and other devices that have processors or that can execute programs or instruction sets. Generally speaking, the invention can be implemented using existing hardware or hardware that can be easily created by those of ordinary skill in the art. Thus, the architecture of the devices presented as examples is not always explained in detail, however, it is understood that devices typically contain a processor, memory (of some kind), and input and output applications. The processor may be a microprocessor, a programmable logic control device, a problem-oriented integrated circuit, or a computing device configured to retrieve and execute instructions. In some cases, devices may also have operating systems and applications that are controlled by operating systems. It is also obvious that although the components of the EMS 10 are shown to be connected to a network, no specific network configuration is implied. One or more communication networks or systems, such as the Internet, telephone systems, wireless networks, satellite networks, cable television networks, and various other private and public networks, can be used in various combinations to provide the communication lines desired or necessary to create embodiments or carrying out the invention, as will be apparent to one of ordinary skill in the art. Thus, the invention is not limited to any particular network or network combinations.

Various features and advantages of the invention are set forth in the following claims.

Claims (18)

CLAIM 1. A method of controlling a payment process in construction involving a plurality of participants associated with a construction project, including determining, using a computer system, the set of necessary documents in electronic form that must be transmitted between at least two participants from the plurality of participants during the construction project ; displaying a list of the set of necessary documents on the participant display screen; receiving from one participant from a plurality of participants by means of the participant’s device, the selection of one of the many necessary documents in electronic form; receiving from one participant from the plurality of participants by means of the participant’s device the selection of at least one law enforcement action from the list of law enforcement actions, and the law enforcement action list includes an action to suspend payment; assignment by the computer system of the selected law enforcement action to the selected document in electronic form, computer control of the status of the selected document in electronic form by the computer system and automatic execution by the computer system of one law enforcement action if the selected document is not electronically transmitted between the participants, and the automatic execution of law enforcement action includes yourself providing access to a set of computer-executable instructions from m ozhestva sets of computer-executable instructions based on the selected enforcement actions and the implementation of a set of computer-executable instructions. 2. The method according to claim 1, further comprising automatically electronically notifying at least two participants of the selected enforcement action. 3. The method according to claim 1, further comprising forming one or more electronic messages that indicate the status of the selected document in electronic form. 4. The method according to claim 1, in which the list of enforcement actions includes a notification action, wherein the selected enforcement action is a notification action, and the automatic execution of the selected enforcement action includes automatic notification of at least one of the participants if the selected document not transmitted electronically between at least two participants. 5. The method according to claim 1, in which the selected enforcement action is an action to suspend payment, and the automatic execution of the selected enforcement action includes the automatic delay of payment to at least one of the participants if the selected document is not electronically transmitted between the participants. 6. The method according to claim 5, in which the automatic execution of the enforcement action further includes an automatic electronic notification of at least one of the participants about the delayed payment. 7. The method according to claim 1, further comprising assigning an expiration date to the selected document in electronic form. 8. The method according to claim 7, in which the expiration date is set based on user input received electronically from at least one of the participants. 9. The method according to claim 7, in which the expiration date is assigned automatically. 10. The method according to claim 7, in which the automatic execution of the enforcement action further includes automatic notification of at least one of the participants about the expiration date on the expiration date. 11. Payment management system in construction for a construction project involving many participants associated with the construction project, including the device of the participant; a document tracking module connected to a computer system, wherein the document tracking module is configured to determine a plurality of necessary documents in electronic form that must be transmitted between at least two participants from a plurality of participants during a construction project; display on the screen the display of the list participant from the set of necessary documents; receiving from one participant from a plurality of participants by means of the participant’s device, the selection of one of the many necessary documents in electronic form; receiving from one participant from a plurality of participants by means of the participant’s device a choice of enforcement action from the list of enforcement actions, the list of enforcement actions including an action to suspend payment; assigning the selected enforcement action to the selected document in electronic form; monitoring the status of the selected document electronically and - 44 015056 automatic execution of a law enforcement action if the selected document is not electronically transmitted electronically between the participants, and the automatic execution of the law enforcement action includes providing access to a set of computer-executable instructions from a plurality of sets of computer-executable instructions based on the selected law enforcement action and performing a set computer executable instructions. 12. The payment management system in construction according to claim 11, in which the document tracking module automatically notifies participants electronically of the assigned enforcement action. 13. The payment management system in construction according to claim 11, in which the document tracking module generates one or more electronic messages that indicate the status of the selected document in electronic form. 14. The payment management system in construction according to claim 11, in which the list of enforcement actions includes a notification action, the document tracking module automatically performs the selected enforcement action by automatically notifying at least one of the participants if the selected document is not electronically transmitted between participants when the selected enforcement action is a notification action. 15. The payment management system in construction according to item 13, in which the document tracking module automatically performs the selected enforcement action by automatically delaying payment to at least one of the participants if the selected document is not electronically transmitted between the participants when the selected enforcement action is action to suspend payment. 16. The payment management system in construction according to Claim 15, wherein the document tracking module automatically electronically notifies at least one of the participants of the delayed payment. 17. The payment management system in construction according to claim 11, in which the document tracking module sets an expiration date for the selected document in electronic form. 18. The payment management system in construction according to claim 17, in which the document tracking module automatically notifies at least one of the participants of the expiration date on the expiration date.