Method and apparatus for real-time, dynamic management of real estate financing, servicing, and reporting

Abstract

Real-time dynamic management of real estate financing, services, and reporting, maintaining a website accessible to homeowners and investors that displays the terms, parameters, and upcoming actions under a housing financing program; storing housing instruments in a blockchain; implementing adjustments under a balancing mechanism; receiving, at regular intervals, messages from an administrative entity initiating balancing entries on the housing instrument; transmitting queries to the blockchain for data related to balance calculations; receiving the data; determining an updated balance; writing the updated account balance and calculation details of the housing instrument to the blockchain, modifying the website accessible to homeowners and investors to display the updated account balance, and notifying homeowners and investors of the updated account balance via mobile devices.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application s / n 62 / 614,720, filed January 8, 2018, and U.S. Patent Application s / n 16 / 241,820, filed January 7, 2019, which are incorporated herein by reference in their entirety. Technical Field

[0003] The present invention relates to data processing and, more particularly, to a method and apparatus for real-time, dynamic management of real estate financing, servicing, and reporting. Background Art

[0004] Computer technology has enabled an integrated, low-cost experience for consumers and providers of many goods and services. For example, a consumer of investment services can access a brokerage website where they can buy and sell collateral, track their account in real time, receive monthly settlement statements, receive collateral price quotes, engage in margin borrowing to purchase collateral, borrow collateral for short selling, and move between more expensive and less expensive service levels with varying functionality. Computer technology links other service providers into the operation in real time, including trading venues, margin lenders, collateral settlement services, quote providers, and others. The result is a seamless, comprehensive, and low-cost presentation and execution for consumers of investment services and multiple service providers. In particular, consumers can typically access all the services they need on a single website at a low cost through a few page-based GUIs, and multiple service providers can interact efficiently with consumers through the same website.

[0005] In contrast to many other industries, current computer technology in residential real estate services and financing has resulted in fragmented and costly services for consumers who purchase and own homes, as well as for investors who provide mortgages or equity financing. Many functions and services are available online, but these functions and services are not integrated. Current computer technology does not adequately facilitate coordination among the multiple parties involved in financing, resulting in high costs for all parties. The resulting consumer experience stands in stark contrast to that of an investment service where service providers are coordinated and operate seamlessly, eliminating any need for consumers to engage with them individually or at all. The following description illustrates the inherent fragmentation and lack of coordination inherent in current technology in residential real estate services and financing.

[0006] The purchase, financing, and sale of a home involve multiple participants and transactions. Some of the key parties involved are: (1) the homeowner; (2) the investor who provides the mortgage or equity financing; (3) the originator who interacts with the consumer to originate or refinance the mortgage or equity financing; (4) the mortgage servicer, who performs functions such as collecting payments from the homeowner, transferring the funds to the investor, and providing information to both parties; (5) the mortgage insurance company, which, for a fee, insures the investor in the mortgage against nonpayment; (6) the investment pools of mortgages or rental properties; and (7) the real estate agent and others involved in the sale or purchase of a home.

[0007] Fragmentation is particularly pronounced at the homeowner level. Homeowners must visit separate websites for different purposes. Homeowners can apply for mortgage financing or refinancing on one set of websites, such as Rocket Mortgage. Homeowners can access separate portals provided by servicers to receive information about their mortgages and make payments. Homebuyers or sellers can access other websites, such as Zillow and Redfin, that provide valuations and confirm listed properties. Real estate agents, such as Coldwell Banker, have websites that offer buying and selling services.

[0008] This fragmentation makes some services very expensive because they are performed on a one-off, individual basis rather than integrated into comprehensive, ongoing services through computer technology. For example, refinancing a mortgage typically costs 2-3% of the loan principal. This situation stands in stark contrast to many other consumer services, where there is an ongoing ability to change the terms of service online at little or no cost.

[0009] This fragmentation, coupled with a lack of coordination, increases costs for homeowners and the various service providers involved. The processing of mortgages is a prime example. Mortgages are often packaged into pools and sold to investors. When interest rates fall, homeowners prepay their mortgages and refinance, reducing the existing mortgage pools. This prepayment risk for investors causes them to demand a premium (usually in the form of a higher interest rate paid by the homeowner) to lend. A refinance is a de novo transaction, not an adjustment to an existing mortgage, and homeowners typically conduct this transaction online, separate from their current mortgage servicer's website, or entirely offline, at a financing institution or in person with a mortgage broker.

[0010] Fragmentation and a lack of coordination not only increase costs for home equity and mortgage investors but also eliminate key investment opportunities. Most notably, it is very difficult to fully invest in owner-occupied homes. Mortgages as part of debt are the primary investment vehicle. It is also possible to invest in growth-shares either as part of a growth-share mortgage or directly (e.g., through Unison).

[0011] Currently, there's no way to fully capture the hidden rents and capital gains from owner-occupied homes. Currently, no vehicle is involved in this hidden rent. The inability of third parties to fully invest in owner-occupied homes is a significant loss. Residential real estate is a major asset class. For example, in the United States, it was valued at $31.8 trillion in 2017, exceeding the total market capitalization of the U.S. stock market. The majority of this is owner-occupied.

[0012] It is possible to invest in a portfolio of rental homes, such as American Homes 4 Rent, but these properties tend to have lower yields than owner-occupied homes because owners take better care of the homes than tenants.

[0013] Fragmentation also exists at the service provider level. Discrete functions (e.g., underwriting and marketing mortgages to mortgage pools or investors) are performed by separate websites or portals. These functions cannot be coordinated dynamically with consumers. They are separate steps that require manual updates when a homeowner's status or desired mortgage transaction changes.

[0014] Behind this fragmented and uncoordinated environment lies a simple reality. Current computer technology often takes individual business methods or operations, each uncoordinated, and applies them separately online. For example, filling out a mortgage application online on a website primarily serves the purpose of eliminating the need to complete a paper application. There is no integrated, low-cost computer implementation. Summary of the Invention

[0015] According to this embodiment, a computer technology system for real-time, dynamic management of real estate financing, servicing, and reporting includes:

[0016] Maintaining a display of the terms, parameter values, and actions to be taken under the home financing program on a website controlled by the managing entity and accessible to at least homeowners and investors;

[0017] storing in at least one blockchain system comprising at least one housing instrument data blockchain, the system comprising at least: contract information specifying at least one housing financing arrangement between at least one homeowner and at least one investor financing a particular housing unit, a time series of economic parameters relevant to the dynamic management of the at least one housing financing arrangement, a record of current and past ownership of the financing debt or equity, a record of transactions comprising at least payments from the homeowner to the investor, a record of any adjustments or changes to the housing financing arrangement, specifications for at least one balancing mechanism designed to track the net contributions of at least the homeowner and the investor and treat the housing financing arrangement between them as a joint venture and to adjust at least one residual account to reflect the net contributions of each party, a record of data and calculations of a balancing engine that operates continuously based on the one or more balancing mechanisms and resulting adjustments to the at least one residual account, an access protocol defining various levels of access to data in the blockchain system and levels of authority to write new data to the blockchain system, and data describing the housing unit involved in the housing financing arrangement;

[0018] maintaining a balancing engine embodied in at least one processing unit, at least one receiving unit, and at least one transmitting unit on at least one processing server controlled by the management entity to implement adjustments under the balancing mechanism;

[0019] Periodically receiving messages from the management entity or an artificial intelligence entity representing it through the receiving unit of the balancing engine to initiate a balancing entry on the housing tool data blockchain; querying the blockchain system for data related to the balance calculation through the transmitting unit of the balancing engine; and receiving the data through the receiving unit of the balancing engine;

[0020] In a direct approach, the processing unit of the balancing engine determines an updated balance in at least one remaining account; the transmitting unit of the balancing engine writes the updated remaining account balance and details of the calculation to the property instrument data blockchain; the processing unit and the transmitting unit of the balancing engine modify at least a website accessible to the homeowner and investor to display the updated remaining account balance; and the transmitting unit of the balancing engine then notifies at least one homeowner and investor, who may be offline, of the updated remaining account balance via a mobile phone or other receiving device.

[0021] Alternatively, in a non-direct scenario, determining, by the processing unit of the balancing engine, an updated unscheduled outcome and associated quantities using the unscheduled outcome as input; writing, by the transmission unit of the balancing engine, the updated unscheduled outcome and associated quantities and details of the calculation to the housing instrument data blockchain; modifying, by the processing unit and transmission unit of the balancing engine, a website accessible to at least the homeowner, investor, and remaining balance position holder to display the updated unscheduled outcome and associated quantities; and then, notifying, by the transmission unit of the balancing engine, at least one homeowner, investor, and remaining balance position holder who may be offline of the updated unscheduled outcome and associated quantities via a mobile phone or other receiving device.

[0022] maintaining, on at least one processing server controlled by the management entity, at least one data engine embodied in at least one processing unit, at least one receiving unit, at least one transmitting unit, and at least one database to create, aggregate, update, process, store, and communicate at least one time series of at least one data parameter;

[0023] At a receiving unit of at least one data engine, third-party data is received, the third-party data comprising input data for calculating at least one data parameter generated by the data engine; the added data is formatted by a processing unit of the data engine, and then a database is modified by the same processing unit of the data engine to incorporate the added data; if desired, at least one non-third-party version of the data parameter is calculated by the processing unit of the data engine; a single operational estimate of the data parameter is calculated by the processing unit of the data engine using the third-party and non-third-party estimates; and the updated estimate of the data parameter is transmitted by the transmitting unit of the data engine to the receiving unit. writing the operational valuation along with a record of the calculation, the record including at least a time and date stamp of the calculation, the third-party and non-third-party values, and a method for calculating the operational valuation on the property instrument data blockchain; modifying, via the processing unit and the transmission unit of the data engine, a website accessible by at least the homeowner and investor to display the updated operational valuation for the data parameters, and then, via the transmission unit of the data engine, notifying at least one of the homeowner and investor, who may be offline, of the updated operational valuation via a mobile phone or other receiving device if either party generally requests an update to the operational valuation or when certain values of the data parameters are implemented;

[0024] maintaining, on at least one processing server controlled by the management entity, at least one third-party data engine embodied in at least one processing unit, at least one receiving unit, at least one transmitting unit, and at least one database for creating, aggregating, updating, processing, storing, and communicating at least one time series of at least one data parameter generated from at least one third-party financing scheme;

[0025] receiving data related to at least one third-party financing scheme at a receiving unit of at least one third-party data engine running on a processing server controlled by the administrative entity; identifying, by the processing unit of the third-party data engine, elements of the data that need to be recorded on the house instrument data blockchain; and modifying the data to be recorded into a suitable format; writing, by the transmitting unit of the third-party data engine, a record of the required data elements and any related calculations on the house instrument data blockchain; extracting, by the receiving unit of the third-party data engine, data that adequately describes the current status and relevant history of the third-party financing scheme from the house instrument data blockchain; organizing, by the processing unit of the third-party data engine, the data into a form suitable for display on a website; modifying, by the processing unit and transmitting unit of the third-party data engine, a website accessible to at least one homeowner and investor to display the updated data for the third-party financing scheme; and then, by the transmitting unit of the third-party data engine, notifying at least one homeowner and investor, who may be offline, of the updated data via a mobile phone or other receiving device if either party requests such updated data generally or when certain values of certain data parameters are achieved;

[0026] Maintaining, on at least one processing server controlled by the management entity, a contract engine embodied in at least one processing unit, at least one receiving unit, and at least one transmitting unit to initiate, implement, execute, and update said home financing arrangement between at least a homeowner and an investor;

[0027] The contract engine receives initial contract data describing a housing financing plan through a receiving unit of the contract engine running on a processing server controlled by the management entity; the processing unit confirms elements of the initial contract data that need to be recorded on the housing instrument data blockchain; the processing unit of the contract engine organizes and modifies the data to be recorded into a suitable format; and the transmission unit of the contract engine writes necessary data elements on the housing instrument data blockchain;

[0028] receiving, on a website or other input device controlled by the management entity, a request from the homeowner to change at least one term in a housing financing plan, the at least one term specifying at least one option for the new term; transmitting, via a transmitting unit of a server controlled by the management entity, the request to a receiving unit of a contract engine operated by a processing unit controlled by the management entity;

[0029] In the case of a direct solution, the necessary contract provisions are extracted from the housing instrument data blockchain by the receiving unit of the contract engine to manage the requested term changes and other relevant data for each option; the processing unit of the contract engine is used to determine whether the housing financing solution contract allows the requested term changes for each option, and if so, whether any approval of parties other than the homeowner is required; if the term changes for at least one option are allowed in other cases, the transmission unit of the contract engine is used to remind at least one relevant party through at least one receiving device of at least one relevant party that it needs to agree or deny approval for each option requiring approval to seek any required approval for each option; after receiving a response or after a deadline for a response has passed, the processing unit of the contract engine is used to determine whether each option proposed by the homeowner is approved or denied; the transmission unit of the contract engine is used to modify the website accessible to the homeowner to notify the homeowner whether each option is authorized or denied, and after at least one option is authorized In this case, the homeowner is requested to confirm that he accepts one of the options or rejects all the options; and then, through the transmission unit of the data engine, at least one of the homeowners who may be in an offline state is reminded of the options that have been authorized or rejected through a mobile phone or other receiving device. If at least one option is authorized, one option needs to be confirmed or all options need to be rejected; if the homeowner confirms the option, the transmission unit of the contract engine writes the relevant data of the accepted option including at least the changes to the terms and the effective date and time of the changes to the terms into the housing instrument data blockchain; through the processing unit and transmission unit of the contract engine, at least a website accessible to the homeowner and the investor is modified to confirm that the changes have taken effect, to display the effective time and date of the changes, and to display the new housing financing plan terms; and then, through the transmission unit of the contract engine, at least one of the homeowners and the investor who may be in an offline state is reminded that the changes have taken effect and the effective time and date of the changes through a mobile phone or other receiving device;

[0030] Alternatively, in an indirect approach, the receiving unit of the third-party data engine extracts necessary contract provisions from the housing instrument data blockchain, the provisions governing the requested term changes and other relevant data, including at least data sufficient to generate an offer to the homeowner for each option, the offer including a term change of the housing financing option that is different from the requested term; the processing unit of the contract engine calculates at least one offer for each term change option specified by the homeowner; the transmitting unit of the contract engine modifies a website accessible to the homeowner to notify the homeowner of the offers and request the homeowner to confirm acceptance of one of the offers or to confirm rejection of all of the offers; and then, The transmission unit of the contract engine reminds at least one homeowner who may be offline of the offer and the need to accept one or reject all of them through a mobile phone or other receiving device; creates an offer data set through the processing unit of the contract engine, the offer data set at least including the content of the offer and the value of the governing data parameter at the time of the offer, and the value of the governing offer terms; writes the offer data set into the house tool data blockchain through the transmission unit of the contract engine; if the homeowner accepts the offer, extracts the offer data set from the house tool data blockchain through the receiving unit of the contract engine; calculates the required terms using the offer data set through the processing unit of the contract engine. the steps required to complete the existing home financing plan and replace it with a new one embodying the terms specified in the accepted offer; transmitting a message through the transmitting unit of the contract engine notifying the parties of the required steps; receiving verification through the receiving unit of the contract engine that the required steps have been completed, including any payments requested between the parties; compiling a transition data packet through the processing unit of the contract engine, wherein the transition data packet includes at least the adjustments made to close the existing home financing plan, the terms of the new home financing plan and the starting remaining account positions of the parties, and the date and time when the new plan takes effect; The transmission unit of the engine writes the transition data to the housing instrument data blockchain, thereby realizing the transition to the new housing financing plan; the processing unit of the contract engine creates a separate displayable version of the transition data suitable for each relevant party; the processing unit and the transmission unit of the contract engine modify the website accessible to the relevant parties to display the transition data in a separate version to each separate party on a separate part of the website and display the new plan in a commonly accessible area of the website; and the transmission unit of the contract engine reminds each relevant party who may be offline of the transition data related to the party and the public data describing the new housing financing plan;

[0031] Receiving a request from a homeowner to sell remaining account positions to at least one investor or to purchase remaining account positions from at least one investor on a website or other input device controlled by the management entity; transmitting the sale or purchase request via a transmitting unit of a server controlled by the management entity to a receiving unit of a contract engine executed by a processing unit controlled by the management entity;

[0032] In the case of a direct solution, the necessary contractual provisions and other relevant data governing the requested sale or purchase, including at least data required to determine the terms of the sale or purchase, are extracted from the housing instrument data blockchain by the receiving unit of the contract engine; the processing unit of the contract engine determines whether the housing financing solution contract permits the requested sale or purchase; and if so, determines whether approval of the investor on the other side of the transaction is required; the processing unit of the contract engine determines the applicable terms of the purchase or sale; if the sale or purchase is otherwise permitted, the investors are reminded of the terms and the need for approval or rejection of approval based on the calculated terms through at least one receiving device of each of the investors, and the approval of the investors, if required, is sought through the transmitting unit of the contract engine; after receiving a response or after a deadline for a response has passed, the processing unit of the contract engine determines whether the sale or purchase based on the calculated terms is authorized or rejected; the transmitting unit of the contract engine modifies the website accessible to the homeowner to notify the homeowner of the authorization or rejection and, in the case of authorization, requests the homeowner to confirm acceptance or rejection based on the calculated terms; and then, the transmitting unit of the contract engine transmits the homeowner's consent to the transaction via a mobile the mobile phone or other receiving device to remind the homeowner, who may be offline, of the authorization or rejection; and, in the case of authorization, requesting the homeowner to confirm acceptance or rejection of the transaction based on the calculated terms; if the homeowner confirms the transaction, a message is transmitted through the transmission unit of the contract engine, which notifies the relevant party or parties of the requested step; the step of receiving the request includes verification that any payment required between the two parties has been completed through the receiving unit of the contract engine; the processing unit of the contract engine compiles a transaction data packet, the transaction data packet including at least the confirmation of the transaction, the terms of the transaction, the date and time when the transaction takes effect, and the new remaining account positions of the parties at that date and time; the transmission unit of the contract engine writes the transaction data to the property instrument data blockchain after being appropriately formatted by the processing unit of the contract engine; the processing unit and transmission unit of the contract engine modify at least a website accessible to homeowners and investors to display the relevant portion of the transaction data; and then, the transmission unit of the contract engine reminds at least one homeowner and investor, who may be offline, of the relevant portion of the transaction data via the mobile phone or other receiving device;

[0033] Alternatively, in an indirect solution, the receiving unit of the third-party data engine extracts from the housing instrument data blockchain necessary contractual provisions and other relevant data governing the requested sale or purchase, including at least data sufficient to generate an offer to the homeowner in connection with the proposed sale or purchase, including each offer to change the terms of the housing financing solution accompanying the proposed sale or purchase; the processing unit of the contract engine calculates at least one offer for sale or purchase proposed by the homeowner; the processing unit of the contract engine determines whether the housing financing solution contract permits the requested sale or purchase; and if so, determines whether approval of the investor on the other side of the transaction is required; and the processing unit of the contract engine processes the transaction. the processing unit of the contract engine determining the applicable terms of the purchase or sale and the terms of each offer; if the sale or purchase is otherwise permitted, alerting the investors, via at least one receiving device of each of the investors, of the offers and the need to approve or deny approval of each offer, according to the calculated terms, seeking approval from the investors, if required, for each offer, via the transmission unit; determining, via the processing unit of the contract engine, whether each offer is authorized or denied after a response is received or after a deadline for responding has passed; modifying, via the transmission unit of the contract engine, a website accessible to the homeowner to notify the homeowner of the authorization or denial of each offer; and in the event of authorization of at least one offer , requesting the homeowner to confirm acceptance of an offer and sales or purchase terms, or reject all offers; and then, through the transmission unit of the contract engine, reminding the homeowner who may be offline of the authorization or rejection of each offer through a mobile phone or other receiving device; and, in the case of authorizing at least one offer, requesting the homeowner to confirm acceptance of an offer and the sales or purchase terms, or reject all offers; creating an offer data set through the processing unit of the contract engine, the offer data set including at least the content of the offer, sales or purchase terms, and the value of the control data parameter at the time of the offer, which governs the value of the offer terms; through the transmission unit of the contract engine, writing the offer data set to the house instrument data blockchain; if the homeowner accepts the offer and the sale or purchase terms, extracting the offer data set from the house instrument data blockchain via the receiving unit of the contract engine; using the offer data set, via the processing unit of the contract engine, calculating the required adjustments among at least the homeowner, the investor, and the remaining balance position holder to close the existing house financing plan and replace it with a new one containing the terms specified in the accepted offer; transmitting a message, via the transmitting unit of the contract engine, notifying the relevant parties of the required steps; receiving, via the receiving unit of the contract engine, verification that the required steps, including any required payments between the parties, have been completed;The contract engine's processing unit compiles a transition data package, which includes at least the adjustments to close the existing home financing plan, the terms of the sale or purchase, the terms of the new home financing plan, and the starting remaining account positions of the multiple parties, as well as the date and time when the new plan takes effect; the contract engine's delivery unit writes the transition data to the home instrument data blockchain to implement the transition to the new home financing plan; the contract engine's processing unit creates a separate displayable version of the transition data for each relevant party; the contract engine's processing unit and delivery unit modify a website accessible to the relevant parties to display the transition data in a separate version for each separate party on a separate portion of the website and to display the new plan in a commonly accessible area of the website; and the contract engine's delivery unit then issues a reminder to each relevant party, who may be offline, of the transition data and public data describing the new home financing plan. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 is a block diagram illustrating a macro system architecture according to an exemplary embodiment for integrating centralized and decentralized computer systems to create an optimized dynamic data structure that accurately reflects housing market conditions to facilitate housing financing transactions and produce a consistent user experience.

[0035] Figure 2 It shows Figure 1 A block diagram of a balancing engine that manages data structures, distributes home equity to remaining accounts, and authorizes equity rebalancing according to an exemplary embodiment.

[0036] Figure 3 yes Figure 1 A block diagram of a blockchain system that receives, processes, and transmits data to and from a blockchain database according to an exemplary embodiment.

[0037] Figure 4 It shows Figure 1 A block diagram of the application layer of an application, which, according to an exemplary embodiment, processes data, accesses centralized and decentralized databases, and provides a computer architecture to support a user interface for the multiple parties involved.

[0038] Figure 5 Is shown using Figure 4 Flowchart of a process for a processing server to authorize a net asset value rebalance request and publish a transaction message according to an exemplary embodiment.

[0039] Figure 6 It shows Figure 1A block diagram of an exemplary embodiment of a data engine that creates, updates, and communicates one or more parameter values for a system according to an exemplary embodiment, wherein the exemplary embodiment includes a valuation engine that transforms data structures using a series of algorithms to calculate home equity and related data structures in centralized and decentralized databases.

[0040] Figure 7 is a diagram illustrating an example of authorizing a net asset value valuation request using Figure 6 Flowchart of the process by which a processing server performs net asset value valuation and publishes transaction messages.

[0041] Figure 8 It shows Figure 1 A block diagram of a contract engine for managing, processing, and executing contractual solutions between parties according to an exemplary embodiment.

[0042] Figure 9 is a flow chart illustrating a process of authorizing a homeowner's request according to an exemplary embodiment.

[0043] Figure 10 is a flow chart illustrating a process for selling cryptocurrency and writing a transaction to a blockchain related to the homeowner selling equity, according to an exemplary embodiment.

[0044] Figure 11 is a block diagram illustrating a cryptocurrency buying and selling engine or a cryptocurrency combination engine according to an exemplary embodiment.

[0045] Figure 12 is a flow chart illustrating a process for writing to a cryptocurrency portfolio blockchain according to an exemplary embodiment.

[0046] Figure 13 is a diagram showing a method of Figure 1 A flowchart of the process of organizing a data set in a data blockchain system, recording the data set in the data blockchain system, and transmitting data messages.

[0047] Figure 14 is a flow chart illustrating a process for writing payment data to a blockchain system and extracting update data from the blockchain system according to an exemplary embodiment.

[0048] Figure 15 is a flow chart illustrating a process for requesting a valuation from a blockchain system and recording a paydown amount to the blockchain, according to an exemplary embodiment.

[0049] Figure 16is a flow chart illustrating a process for recording payment data to a blockchain system or confirming investor contacts using a blockchain system to deliver an insufficient funding message, according to an exemplary embodiment.

[0050] Figure 17 is a flow chart for processing received default notices using data obtained from a blockchain and determining and recording investor changes in a blockchain system according to an exemplary embodiment.

[0051] Figure 18 is a flow chart illustrating a process for extracting contractual data from a blockchain system and for causing a payment engine to activate to generate and write payment data to the blockchain system, according to an exemplary embodiment.

[0052] Figure 19 is a flow chart illustrating a process of updating a blockchain system with respect to an initiated EBP scheme according to an exemplary embodiment.

[0053] Figure 20 is a flow chart illustrating a process for adding balancing entry data related to unplanned outcomes to a blockchain system, according to an exemplary embodiment.

[0054] Figure 21 is a flow chart illustrating a process for extracting contract data from a blockchain system, calculating an offer data set, and writing the offer data set to the blockchain system in connection with a payment change request, according to an exemplary embodiment.

[0055] Figure 22 is a flow chart illustrating a process for calculating a required allocation, causing a bank transfer to be executed, and updating a blockchain system with respect to an accepted payment offer, according to an exemplary embodiment.

[0056] Figure 23 is a block diagram illustrating a transaction engine according to an exemplary embodiment.

[0057] Figure 24 is a flow chart illustrating a purchase offer process and updates to a blockchain system associated with an accepted purchase offer, according to an exemplary embodiment.

[0058] Figure 25 is a block diagram of a computer system that can be used to implement certain features of some embodiments. DETAILED DESCRIPTION

[0059] Dynamic housing data structure

[0060] Various aspects of embodiments of the present disclosure relate to dynamically updating a data structure that defines logical relationships between multiple entities to adapt to real-time fluctuations in conditions defined by multiple data streams that affect the logical relationships (e.g., relationships between parties to a dynamic home instrument). More specifically, embodiments of the present invention relate to data structures in the form of DOOR instruments. DOOR stands for "dynamic homeowner-occupied real estate." By creating an appropriate underlying dynamic data structure, i.e., by selecting an appropriate DOOR instrument, storing the relevant data on a traditional database and one or more publicly verifiable blockchains, and using a blockchain-based approach to house key transaction components, embodiments of the present invention enable computers to dynamically modify web pages and create graphical user interfaces in real time, enabling an integrated, transparent, and low-cost experience for homeowners and service providers.

[0061] A class of DOOR instruments offers homeowners, mortgagees, and equity investors new ways to reside in and invest in real estate for their own use. Embodiments of the present invention focus on a specific balancing engine that monitors various factors that influence the criteria defining rights and obligations regarding the real estate and dynamically adjusts those rights and obligations in real time. The balancing engine is only one aspect of a DOOR instrument. Other aspects include, but are not limited to, various data engines that support the dynamic data structures that comprise the DOOR instrument.

[0062] Some DOOR instrument balancing engines translate directly into commercially viable solutions between the homeowner and the investor financing the homeowner. Several variations of these "direct solutions" are described below to provide easy-to-understand examples. However, the present invention is more general. It utilizes a collection of balancing engines that address the fragmentation and lack of coordination that currently characterizes computer technology in the field of residential real estate services and financing. In many such cases, the solutions implicit in the balancing engine are not available home solutions to the homeowner and the investor financing the ownership. The balancing engine sits in the background, creating a computer technology that can fully provide an integrated, transparent, low-cost experience for homeowners and service providers across different solutions.

[0063] Before discussing the more general levels of the invention, it is helpful to consider, by way of example and for purposes of explanation, some straightforward scenarios in which a DOOR instrument may be implemented and how the present invention operates with respect to those scenarios.

[0064] DOOR Implementation Methods for Housing Financing Solutions

[0065] A DOOR instrument is a data structure that allows allocations between homeowners and equity investors and is preferably nonlinear and dynamic. In a preferred embodiment of a DOOR instrument, the sharing rules can be more general than linear plans over a range of home values and can be dynamic. That is, the rules themselves are a data structure that can change due to economic conditions or home values. This approach allows the sharing rules to address many problems that are not addressable under piecewise linear, static approaches. These problems include, but are not limited to: (1) suboptimal homeowner incentives to maintain their homes; (2) unwise homeowner financial strategies, such as effectively investing a large amount of wealth in a single leveraged asset that is correlated with life outcomes so that home values and overall wealth tend to decline sharply when income declines or unemployment occurs; (3) the inability of investors to obtain the benefits of their own homes in a clean and transparent manner; (4) the inability to increase borrowing on the home without expensive refinancing of the equity instrument; (5) the inability to easily establish or accept new investment in a syndicate to value the instrument; and (6) the existence of incentives to strategically refinance the equity instrument when home prices decline. Some of these problems are the lack of coordination between housing finance and servicing functions and the fragmentation that characterizes current computer technologies for real estate financing and servicing.

[0066] Importantly, under a static approach, as time passes and economic conditions change, the program becomes more favorable to the homeowner or investor. To make this program work, the homeowner's refinancing opportunities must be restricted, or terms must be set in favor of the investor. The dynamic nature of the DOOR instrument makes it possible, in certain embodiments, to eliminate these restrictions, thereby obtaining a better deal for the homeowner, preserving at least the market rate of return for the investor, and protecting the investor from losses due to prepayments. DOOR programs are also typically extended to include attached mortgages, which, in some variations, eliminate the impact of prepayments on the mortgage lender / investor and allow features such as automatic, nearly costless, and online refinancing of mortgages when mortgage rates decline.

[0067] Embodiments of the present invention involve using a class of nonlinear algorithms to create a DOOR instrument that continuously and dynamically maintains an economic equilibrium between the homeowner and the investor. At each moment in time, the DOOR balancing engine acts as an analytical engine, calculating the change in equity shares or other accounts to accurately capture the net contribution of each party to the venture. Because of the continuous economic equilibrium, the scheme is neutral in the sense that it does not shift in favor of one party over another and results in each party receiving a market rate of return after adjusting for the benefits received from the scheme and the investment made in the scheme. Subsidies or preferential rates of return relative to the market can also be added, but any such feature is clearly useful, for example, when the investor is a government or private entity wishing to provide subsidized housing to citizens or employees.

[0068] In a DOOR scheme designed to implement economic balance, one or more residual accounts are required to maintain balance. These residual accounts may include equity shares, interest on mortgage or similar debt, fluctuating payments between parties, cash or investment accounts, cryptocurrency balances, or other vehicles. Any scheme may use more than one residual account.

[0069] discuss

[0070] Embodiments of the present invention create computer technology in the form of appropriate underlying dynamic data structures that enable a computer to modify a web page and create a graphical user interface that can provide integrated, transparent, low-cost home financing solutions to homeowners and service providers.

[0071] The following discussion includes several examples that first describe a particular housing scenario and a qualitative representation of how DOOR instruments work in that scenario, and then illustrate embodiments of the present invention.The description of the housing financing scenario allows for the definition of key terms.

[0072] The two home financing scenarios, MM-0 and MM-1, described as initial examples, can be implemented as direct scenarios using a suitable DOOR instrument balancing engine. Subsequent examples include instances of implementation of non-direct scenarios. Overall, the home financing scenario examples provide important context for describing other embodiments of the invention disclosed herein. The embodiments are drawn from a class of generally claimed DOOR instrument variants that includes ANZIE-DOOR (see WO 2010 / 085481 A1). It is important to remember that some of the DOOR instrument variants in this class implement a balancing engine that enables a computer to modify web pages and create a graphical user interface, thereby providing an integrated, transparent, low-cost experience for homeowners and service providers, even if the real estate scenario differs from the direct scenario inherent in the balancing engine.

[0073] The following discussion of embodiments of the present invention begins with a section that provides a description of certain aspects of the required technical environment and a list of some of the relevant parties to the relevant home financing scheme and transaction. The sections that follow include:

[0074] (i) A description of the MM-0 home financing scenario, which has only two parties: the homeowner and the investor providing the home financing;

[0075] (ii) a description of one embodiment of how the present invention implements MM-0, illustrating how computer technology including the present invention addresses the problems of fragmentation and lack of coordination inherent in current computer technology for straightforward solutions;

[0076] (iii) describe the claimed class of data structures (DOOR instruments) and the theory behind them using a specific residual account, earned equity, and focusing on the associated balancing engine;

[0077] (iv) indicate the scope of the disclosed class by describing applications involving: residual accounts other than earned equity; multiple homeowners, investors, or mortgagees; accruals under residual accounts to parties other than the homeowner; and the ability to seamlessly switch between neutral DOOR instruments;

[0078] (v) a description of the MM-1 home financing program, which differs from MM-0 because it involves multiple independent service providers in addition to the homeowner and the investor providing the home financing;

[0079] (vi) an explanation of how the present invention implements an embodiment of MM-1, which illustrates how computer technology including the present invention solves the problems of fragmentation and lack of coordination inherent in current computer technology for this more complex direct solution;

[0080] (vii) a description of earned equity home financing options for programs that cannot be implemented as direct programs;

[0081] (viii) An illustration of one embodiment of how the present invention implements a planned earned equity financing scheme, illustrating how computer technology, including the present invention, addresses the inherent fragmentation and lack of coordination of current computer technology for schemes that are not direct schemes.

[0082] These sections are followed by other sections that describe other embodiments and aspects of the invention.

[0083] Multiple parties involved and technical environment

[0084] For a particular home and homeowner, there are multiple parties involved at the time of purchase, sale, and throughout the ownership period. During ownership, there is typically at least one homeowner and one financier ("investor"). If the financier is a mortgagee, there may be a mortgage guarantor, mortgage insurance company, mortgage servicer, and other parties involved in the mortgage loan. The home may have a maintenance contract with a party that provides maintenance services. A maintenance service provider or appraiser may periodically provide an estimate of the home's value based on its current condition. A management entity oversees the operation of the ownership program and related computer technology.

[0085] In some embodiments, the investor may be a portfolio fund, which holds a portfolio of equity in a home or interest on a bond, represented by a "portfolio investor" who owns shares of the fund. In further embodiments, the portfolio may be represented by a tradable cryptocurrency, in which case the investor is a "cryptocurrency portfolio fund." Regardless of whether cryptocurrency is involved, a portfolio fund operates as an investment fund, collecting investments from portfolio fund investors, who may, from time to time, invest additional funds into the portfolio held by the portfolio fund, or withdraw funds from the portfolio, thereby increasing or decreasing the portfolio.

[0086] In addition to the homeowner and investor, there may be multiple third parties. A "third-party financing entity" may provide "third-party home financing" to supplement the home financing provided by the investor. Additionally, and potentially distinct from, the third-party financing entity may be at least one "third-party service provider" that provides services related to the financing provided by the investor, the financing provided by the third-party financing entity, or both. For example, if the third-party home financing is a mortgage loan, the third-party financing entity is the mortgagee, and separate from the mortgagee, there may be two third-party service providers: the mortgage servicer and the mortgage insurance company.

[0087] The present invention requires and enables a deep computing and communications environment. Each tool continuously updates the value of the remaining accounts and the shares of multiple parties in such accounts and the associated home equity. Therefore, the center of the present invention is a dynamic data structure that continuously updates the values and shares based on fluctuating economic variants that interact with the real-time decision-making of the parties, and dynamically generates a corresponding user experience. Various events such as mortgage refinancing, changing the payment amount, or even changing the applicable DOOR variant itself require the actions or approvals of multiple parties. Such events include the sale or purchase of the subject property. These events require an added layer of communication equipment and software to enable or improve the functionality of the computing or other devices dedicated to the task.

[0088] While there are other ways to implement the present invention, we illustrate it here by considering an implementation that relies on a blockchain approach and requires the use of certain DOOR purchase parity variants, which are defined and described in later sections. Blockchain provides a way to make data immutable and verifiable, and thus may be key to making the technical solution embodied in this invention credible to the multiple parties involved in the underlying housing solution.

[0089] The blockchain ledger stores data in an immutable and transparent manner. There are many possible ways to implement and use blockchains consistent with our innovations, including at least: (1) centralized systems where data is anchored to the blockchain using a third-party method that provides an application layer between users and the blockchain; (2) using smart contracts to organize data and facilitate transactions by saving smart contract states to a public blockchain, with much of the work performed off-chain for greater efficiency; and (3) developing customized private blockchains. In the following examples, we refer to a "blockchain system" to mean both the blockchain and the implementation method. It should be understood that the details of the implementation methods are merely exemplary and are in no way limiting.

[0090] In the following embodiments, one or more blockchain systems are used for the following purposes:

[0091] (1) Home Instrument Data and History. One or more "home instrument data blockchains" contain, in immutable form, the data and history of each home instrument and the current value of the associated economic variant. The associated blockchain system provides a transparent basis for investors, homeowners, service entities, other blockchain systems, or other parties using various computing or communication devices to query information regarding the current DOOR instrument shares, values, or other elements.

[0092] (2) Transaction Data. One or more “transaction blockchain systems” may be used to complete some or all of certain transactions, including at least refinancing a mortgage loan based on a DOOR instrument, changing a payment rate, converting between neutral DOOR instruments, or the purchase or sale of a subject property associated with the creation or exit of a related DOOR instrument.

[0093] (3) Cryptocurrency Operations. One or more "cryptocurrency blockchains" may contain data on housing interests held over time in multiple cryptocurrencies that represent a combination of these interests. Using a purchase parity variant that allows the property to be spread across multiple DOOR instruments that use different residual accounts and differ in other ways, the investor continuously receives a financial return on the underlying housing. These instruments can be combined to create a pure housing yield portfolio that can be used as the basis for a cryptocurrency operated through a blockchain system. National, regional, or global housing yields can be simulated through a base pool, thereby generating a hard currency backed by some type of housing yield. A soft fiat currency such as the US dollar may continue to fluctuate relative to this hard currency.

[0094] Implementing dynamic data structures, including DOOR instruments, requires an excellent, coordinated communications and computing environment in which the various devices, software, and blockchain systems that are part of the present invention can implement or enhance the technical operations of the underlying devices. To make this more concrete, consider a narrative example.

[0095] Assume an embodiment involving purposes (1) and (2) for a variety of DOOR instruments, some of which exist in the form of purchase parity and are otherwise suitable for inclusion in a cryptocurrency pool, i.e., purpose (3). A homeowner purchases a home and finances it through a DOOR purchase parity embodiment that involves mortgage payments, additional payments, and the accrual of earned equity in favor of the homeowner. The homeowner then wishes to reduce the rate of additional payments.

[0096] Consider first a purchase transaction. To complete the purchase, it is necessary to identify potential investors and potential mortgagees, then perform multiple operations and obtain approvals from multiple parties. For dynamic instruments, as embodied in the present invention, the instrument terms change in real time, aligning with relevant market conditions. Therefore, time is of the essence, lest the originally cited terms of the instrument become inconsistent with current market conditions. Multiple communication devices and software, such as mobile phone applications, are required to provide notifications and obtain approvals from the relevant parties. Otherwise, the basic computing and communication devices essential to the DOOR system will not function effectively.

[0097] Now consider the homeowner's subsequent request to reduce the ratio, which would have resulted in additional payments. As with home purchases, ratio changes require a complex series of interdependent actions and approvals. The homeowner must initiate the request to change the ratio. Approval is typically required based on the terms of the instrument, as the payment ratio impacts the accumulation of earned equity, and the instrument may require a minimum level of earned equity or accrual to ensure the homeowner has an appropriately strong incentive to maintain the home. Furthermore, approval of the payment ratio change by one or more of the instrument's investors may be required. Again, timing is critical, as the changed payment ratio can dynamically impact the accrual of earned equity and the homeowner's cash flow in a manner that depends on market conditions. Various communication devices and software, such as mobile phone applications, require notification and approval from the relevant parties, and whether the change is permitted depends on the terms of the instrument.

[0098] Finally, on top of the structure that implements objectives (1) and (2) is the cryptocurrency. If the cryptocurrency is based on an index concept, such as a balanced set of homes across the country, it will need to be constantly adjusted and interact with homeowners, investors, and other blockchains. For example, consider a cryptocurrency that is backed by a set of DOOR instruments covering a representative set of homes across the United States, effectively creating a portfolio of home returns that constitutes or replicates the underlying pool of homes in the U.S. Home Sales Index. If the DOOR instruments are the purchase-at-par MM-0 variant, the net asset value position based on the cryptocurrency continues to shrink and offsets the cash flows accruing to the cryptocurrency. In addition, some of the underlying homes are sold, converting the underlying DOOR instrument position into cash. Because the cryptocurrency aims to replicate the returns of a balanced set of homes across the United States, it is necessary to use the accumulated cash to find new DOOR instrument investments that not only bring the cryptocurrency close to the full investment in homes, but also do so in a balanced manner. For example, at any time, more investment in homes in Northeastern cities may be needed to reestablish equilibrium. Balancing may require selling DOOR investment shares, as well as purchasing. Cryptocurrency managers, or AI entities acting on their behalf, may query one or more other real estate asset data blockchain systems for suitable purchase targets and then make offers to relevant investors. They may also offer properties for sale through blockchain systems or other means. These inquiries may be extended to real estate agents or other parties to inform them of the existence of an immediately interested and liquid buyer or seller. Because cryptocurrencies are used in real time, time is of the essence, requiring various communication devices and software, such as mobile phone applications, to make purchase or sale offers, complete the required transactions, and obtain approval from the relevant parties.

[0099] This narrative example and the further technical examples described below are intended to be illustrative and not exhaustive of the technical aspects of the present invention.

[0100] MM-0 Housing Financing Program

[0101] A home financing scheme for a single owner-occupied property implemented using a DOOR instrument may include multiple investors, multiple homeowners, and multiple mortgagees holding the same or different debt interests secured by the mortgage on the property. One or more investors or homeowners may also be mortgagees. In addition, there may be debt-like instruments that do not involve interest payments but rather equivalent credits that enter into the balance calculation.

[0102] We start with a very simple housing financing scenario, MM-0:

[0103] (i) there is at most one mortgage loan and no debt-like instruments;

[0104] (ii) when there is a mortgage loan, the investor is also the mortgagee and provides all of the housing financing by contributing equity as an investor and also lending the money secured by the home;

[0105] (iii) the mortgage loan is non-recourse to the homeowner and, after any required payments have been made to the homeowner, there is no recourse to the homeowner if the sale proceeds are insufficient to pay the principal due on the mortgage loan. Therefore, if there is a funding shortfall, the investor, as the mortgagee, bears the loss; and

[0106] (iv) DOOR instrument variants are applicable to the direct implementation of MM-0, i.e., the "MM-0 variant" of DOOR.

[0107] MM-0 home financing is characterized by the following actionable features:

[0108] (1) The conventional equity position held by the DOOR investor. The DOOR instrument investor provides funding for the conventional equity position in the home, which can also be financed through a mortgage loan. If there is a mortgage loan, the mortgage loan financing is provided by the DOOR investor. If there is no mortgage loan, the DOOR investor provides all the equity investment.

[0109] (2) Homeowner Responsibilities. The homeowner is responsible for any mortgage loan payments (including principal and interest), property taxes, maintaining the home, and other responsibilities, which may include, at least in part, periodic payments that accrue in favor of the DOOR investor. In the absence of a mortgage loan, there are usually periodic payments, but periodic payments may also supplement mortgage loan payments.

[0110] (3) Earned equity held by the homeowner. The homeowner accrues earned equity, which is a percentage of the home's value that the DOOR investor is obligated to pay to the homeowner upon the sale of the home or other termination of the DOOR instrument. Earned equity accumulates based on the homeowner's net contribution to the venture, as specified by the dynamic algorithm that creates the core of the economic balancing engine. The primary positive factors in net contribution are loan payments, property tax payments, periodic payments (if any), and home maintenance. The primary negative factor is the imputed rental value of living in the home. If the homeowner has a down payment, it directly increases the earned equity as a percentage of the home's value. Earned equity is the unleveraged equity interest in the home, as a percentage of the total home's value at any given point in time. Earned equity takes precedence over debt and equity interest held by the investor upon sale.

[0111] (4) Robust maintenance incentives. The contract terms provide that failure to maintain the home in a condition at least as good as when purchased will result in a substantial reduction in the earned equity paid to the homeowner upon termination. Because the earned equity position includes unleveraged equity in the home, the homeowner's maintenance incentives remain robust in the event that the home's value falls below the outstanding mortgage debt.

[0112] (5) Implement periodic adjustments to the economic balance. The DOOR balancing engine is an analytical engine that continuously adjusts the residual account to compensate the party with the net contribution. In the MM-0 case, the residual account is the homeowner's earned equity, and the balancing mechanism is based on the purchase parity accumulation algorithm described below. The balancing engine converts the homeowner's net contribution in each period into an appropriate increase in earned equity, that is, an increase that exactly compensates the expectations of both parties from the current period.

[0113] The terms of DOOR instruments (including MM-0) vary with market conditions. A fully dynamic instrument incorporates the current values of all relevant parameters, such as interest rates, underlying home values, home rental rates, home depreciation rates, property tax rates, and other variables. Making the instrument fully dynamic eliminates certain options associated with it. For example, a fully dynamic DOOR instrument would be unprofitable to refinance because the terms of the new instrument would be the same as the old one, reflecting current market values. The refinancing option would be worthless. In contrast, such an option would have value under conventional mortgage contracts, where mortgage lenders have an incentive to prepay their mortgages and refinance when mortgage rates decline. This has the consequence of: a higher initial price to borrow, a dilemma for homeowners regarding when to exercise the option, and greater difficulty in valuing the mortgage due to its reliance on prepayment behavior.

[0114] Some DOOR implementations use approximations: DOOR contracts adjust based on precise, real-time market values for only a subset of relevant parameters, while using approximations for the remaining parameters. The result is an instrument that only approximates the value of a zero-adjustment option, rather than one with more predictable outcomes, such as the amount of equity earned. In other DOOR implementations, the goal is to get as close as possible to a fully dynamic version of the instrument.

[0115] Please note that MM-0 home financing options can be offered with or without a mortgage. In the absence of a mortgage, payments are typically required from the homeowner to a speculator or directly to the investor in order to generate sufficient net capital contribution from the homeowner to generate a significant amount of earned equity. These periodic payments can be a function of the home's value, fluctuate to achieve and maintain a target level of earned equity, or vary in other ways depending on the nature of the option.

[0116] The dynamic nature of DOOR instruments allows for the addition of numerous other features. Some additional features that may be particularly attractive in MM-0 or other variations include:

[0117] (A) Payment reduction as an option or as a basis for assistance to financially distressed homeowners. If a homeowner experiences financial hardship, the provisions of a DOOR program may allow them to skip regular payments or mortgage payments for a period or a total amount. This has no impact on the investor, as the payment reduction is fully offset by a slower increase in earned equity or an actual decrease in earned equity. In variations involving a third-party mortgage loan, that is, when the investor is not the mortgagee, the investor steps in and pays the mortgage payments that the homeowner has not made. Furthermore, the investor is compensated by reducing the earned equity liability upon sale. The possibility of payment reduction is universal, not limited to hardship situations, and can be included as an option for the homeowner.

[0118] (B) Partial Mortgage Loan Repayments to Limit the Loan-to-Value (LTV) Ratio or an Equivalent Reduction in Periodic Payments. A DOOR contract may require the investor to partially repay or reduce the homeowner's mortgage debt to limit the LTV. If there is a third-party mortgage loan that has priority over the earned equity, LTV levels can be set to ensure that the investor's regular equity exceeds the earned equity at the time of sale. Under the MM-0 model, a desirable repayment approach is to cancel part of the loan, reducing the payments but leaving other terms unchanged, effectively creating a scaled-down version of the original loan. Without an LTV cap, earned equity can accumulate very quickly at low values, potentially completely consuming any remaining available home equity. The DOOR mechanism provides DOOR investors with precise economic compensation for any repayments, as reducing loan payments reduces the base rate at which earned equity accrues in an exactly compensating manner. Without a mortgage loan, but with periodic payments under MM-0, payments can be reduced in an equivalent manner at low values, with a compensating reduction in accrued earned equity.

[0119] (C) Additional Homeowner Payments. A DOOR contract may permit the homeowner to make additional optional or regularly scheduled payments for the benefit of the investor. These payments increase the accrual of earned equity by precisely compensating the homeowner for the payments.

[0120] (D) Targeted Earned Equity. A DOOR plan may include accruing earned equity to a target level and then adjusting payments to zero out the homeowner's future net contributions, thereby preventing any additional accrual. The homeowner may be permitted to move the target amount of earned equity up or down within a certain range by adjusting ongoing payments to achieve the target over time or by making an immediate adjustment through a lump sum payment.

[0121] Because the DOOR balancing engine is an analytical mechanism that fully compensates the parties for any changes in their contributions to a scheme that is considered a joint venture, it is easy to add these and many other features. Many of the possible features require that the parties to the scheme be informed and make interrelated and interdependent decisions on a real-time basis.

[0122] The next section will explain how the present invention creates computer technology that enables representative embodiments of MM-0 to be implemented in a manner that enables computers to modify web pages and create graphical user interfaces that can provide an integrated, low-cost experience for homeowners and service providers, which is not currently available in the technology.

[0123] Implementation of an Example of the MM-0 Housing Financing Scheme

[0124] Figure 1A system 100 is shown that includes a macro-system architecture for integrating centralized and decentralized computer systems to create an optimized dynamic data structure that accurately reflects housing market conditions to facilitate home financing transactions and produce a consistent user experience.

[0125] In system 100, transactions can occur between the computing devices of homeowners 102 and investors 104, embodied in housing financing instruments, and facilitated by an administrative entity 106 and associated computer interfaces. The administrative entity can oversee multiple computer systems, including one or more balancing engines 108, a data engine 110, and a contract engine 112. Third parties 114 and associated computer interfaces can also be involved in the transactions. The system can also include an application layer 116, which receives, processes, and transmits data and provides the necessary computer infrastructure to manage user interfaces for the various parties involved in a particular transaction. The application layer can also interact with one or more buying and selling engines 118 and / or one or more blockchain systems 120.

[0126] To describe how system 100 works, consider an implementation of an embodiment of the MM-0 housing scenario. We focus on the ownership period and begin with a simple case involving homeowner 102, a single investor 104, and 100% equity financing—that is, no mortgage. The core of the invention is a balancing engine 108 embodied by a processing unit 206 operated by a management entity on a processing server, at least one receiving unit 202, and at least one transmitting unit 204.

[0127] Figure 2 1 shows an embodiment of the balancing engine 108 of the system 100. The balancing engine 102 may include a database 208, a receiving unit 202 configured to receive data over one or more networks, a processing unit 206 that performs the functions of the balancing engine 108 described herein, and a transmitting unit 204 configured to transmit data over one or more networks.

[0128] Balancing engine 108 then evaluates the ongoing contributions of homeowner 102 and investor 104 and treats the housing scheme between them as a joint venture. In one embodiment, investor 104 initially finances the entire home through equity financing, i.e., without a mortgage, and homeowner 102 pays investor 104, who pays property taxes, maintains the home, and resides in the home. In this embodiment, homeowner 102's net contribution equals (i) payments to investor 104, (ii) property taxes, (iii) maintenance fees, and (iv) other liabilities such as insurance, minus (v) fees charged as rent ("implicit rent"), i.e., the value of living in the home. The balancing mechanism requires a residual account stored on centralized database 208 or decentralized database 120 to reconcile the interests of homeowner 102 and investor 104. In this embodiment, the remaining account includes the unleveraged interest on the home, which investor 104 must pay to homeowner 102 upon the sale of the home or termination of the financing arrangement, and the payments are arranged so that the net contribution of homeowner 102 is positive. Because unleveraged equity accrues based on the net contribution of homeowner 102, we refer to this as "earned equity."

[0129] In the system 100 , data used to input the balancing engine 108 is located in the house instrument data blockchain system 120 . Figure 3 An embodiment of a data blockchain system 120 of system 100 is shown. The data includes a time series of all contribution elements, including at least payments from homeowner 102 to investor 104. The housing utility data blockchain system 120 includes a receiving unit 302 configured to receive data via one or more networks and a database 308 for storing user data. The blockchain system 120 also includes a processing unit 306, which has an access protocol and is protected and anonymized using methods familiar to those skilled in the art, such as encryption, state channels, and public and private keys. The access protocol defines various levels of access to data on the blockchain system 120, as well as the level of permission to write new data to the blockchain system 120. A person or entity seeking access to the blockchain system 120 submits access authorization data, which determines the level of access to the data and the extent of the ability to write to the blockchain granted to the person or entity, according to the access protocol. The housing utility data blockchain system 120 includes a transmitting unit 304 configured to transmit data via one or more networks.

[0130] Figure 4An embodiment of the application layer 116 of the system 100 is shown, wherein a receiving unit 402 is designed to receive data via one or more networks, a transmitting unit 404 is used to broadcast data on one or more networks, a processing unit 406 having a computer architecture to support a user interface for stakeholders, and a database 408 for storing data. The management entity computer system 106 controls the balancing engine 108, which transmits data to the blockchain system 120 via the application layer 116.

[0131] You can refer to Figure 5 To understand one embodiment, a flow chart (500) illustrates the use of Figure 4 The processing server of the balancing engine executes the equity rebalancing request and issues the transaction message. The management entity or the artificial intelligence entity on its behalf periodically sends a message to the receiving unit of the balancing engine to initiate a balancing entry on the home instrument data blockchain (502). The balancing engine transmits a query and access authorization data to the home instrument data blockchain system via the transmitting unit to extract relevant data about the contribution and other elements, including the governing algorithm for calculating the earned equity under the contract covering the housing financing scheme, which is itself encoded on the home instrument data blockchain (504). The home instrument data blockchain system implements its access protocol to determine whether the balancing engine can access the requested data. After verifying that access is allowed, the balancing engine receives the data via the receiving unit, and the processing unit associated with the balancing engine updates the homeowner's (506) earned equity balance (remaining account). The balancing engine transmits the updated balance along with the details of the calculation to the transmitting unit, which writes it along with the details of the calculation itself to the home instrument data blockchain (508). The balancing engine transmits the updated earned equity value via the transmitting unit to a website accessible to homeowners and investors, where the new value is reported (510). The balancing engine via the transmitting unit alerts the homeowner and the investor (or an artificial intelligence entity representing the investor), who may be offline, via email or SMS message via a mobile phone or other receiving device of the updated earned equity value (512).

[0132] In the system 100, input data for the balancing engine 108 is located on a house instrument data blockchain 120 and is generated by a plurality of data engines 110 located on one or more servers controlled by the administrative entity 106. Each data engine 110 is configured to create, aggregate, update, process, store, and communicate at least one time series of at least one data parameter.

[0133] Figure 6A valuation engine is shown, which provides an exemplary embodiment of the data engine 110 of the system 100 and operates on a processing server controlled by the administrative entity 106. The valuation engine 110 creates and updates a time series of home values for homes to be financed by writing to the home instrument data blockchain 120. An exemplary embodiment of the valuation engine 110 includes a receiving unit 602 for receiving data via one or more networks, a transmitting unit 604 for transmitting data via one or more networks, a processing unit 606 having a computer architecture for executing the exemplary embodiment, and a database 608 for storing data.

[0134] You can refer to Figure 7 To understand one embodiment, a flow chart (700) illustrates receiving a request for a net asset value valuation, using Figure 6 The processing server performs the process of valuing the net asset value and issuing transaction messages. The valuation engine receives a data request (702) corresponding to the net asset value valuation request. The valuation engine collects third-party valuations (704) via a query through one or more receiving units. The valuation engine records these valuations in a database (706). When applicable (708), the valuation engine generates one or more non-third-party valuations (710) through the processing unit and combines the third-party valuations and non-third-party valuations using one or more statistical programs (712) into an operational valuation for use by the balancing engine. Through the transmission unit, the valuation engine writes the operational valuation along with a timestamp and a calculation record to the home instrument data blockchain (714), including the third-party and non-third-party valuations, the method for calculating the non-third-party valuation, and the method for calculating the operational valuation (716). The valuation engine generates a data message (718) and sends the new operational valuation along with the third-party and non-third-party valuations to a website accessible to homeowners and investors through the transmission unit (720), where these valuations are reported. If the homeowner and investor (or the artificial intelligence entity representing the investor) have requested an update to the operational valuation generally or when certain values are implemented, the valuation engine alerts the homeowner and investor (or the artificial intelligence entity representing the investor) who are offline via an email or SMS message via a transmitting unit through a mobile phone or other receiving device.

[0135] To calculate a non-third-party valuation, the valuation engine requires data from third-party sources, including at least housing transaction data. The valuation engine's receiving unit automatically receives data from third-party providers, either automatically or upon prompting by the management entity. The valuation engine appropriately formats this data and, after processing, adds it to the housing database, aligning it with the existing data structure. This data may include an estimate of the value of the financed home or other housing.

[0136] Other data elements, including at least implicit rent, depreciation, and property tax obligations, are subject to other data engines that operate in a similar manner to the valuation engine.

[0137] The management entity 106 maintains a contract engine 112 embodied in at least one processing unit 806, at least one receiving unit 802, and at least one transmitting unit 804 on at least one processing server controlled by the management entity to initiate, implement, execute, and update a home financing arrangement between at least the homeowner 102 and the investor 104. Input data for the contract engine 112 is located in the home instrument data blockchain system 120.

[0138] Figure 8 An exemplary embodiment of the contract engine 112 of the system 100 is shown, wherein a receiving unit 802 is designed to receive data via one or more networks, a transmitting unit 804 is used to broadcast data on one or more networks, a processing unit 806 having a computer architecture for performing the exemplary functions of the embodiment, and a database 808 for storing data.

[0139] Figure 9 is a flow chart illustrating the process of processing a homeowner's request according to an exemplary embodiment (900). A homeowner may want to change the payment level to an investor, effectively refinancing the home financing option.

[0140] The homeowner accesses a website operated by the management entity and requests a change in payment level, generates a transmission message, and transmits the transmission message via a transmission unit to a receiving unit of a contract engine controlled by the management entity (902). The contract engine processing unit sends a query to the house instrument data blockchain system and access authorization data via the transmission unit to extract relevant information including necessary contract information and other data including at least the earned equity level (904). The house instrument data blockchain system implements its access protocol to determine whether the contract engine can access the requested data. After verifying that access is allowed, the contract engine receives the data via the receiving unit, and the processing unit associated with the contract engine determines whether the payment change under the contract is allowed without further approval from the investor (906). If the change is not allowed, the contract engine generates a rejection message (908) and sends it to a website that displays the message (910). The contract engine simultaneously notifies the homeowner, who may be offline, via a mobile phone or other receiving device via an email or SMS message to inform the homeowner whether the change in payment level has been approved or rejected, and if approved, asks the homeowner to confirm the change (912). If the change is confirmed, a confirmation message is generated and sent to a receiving unit associated with the contract engine via a transmitting unit associated with the website. The contract engine transmits the query and access authorization data of the property tool data blockchain system via the transmitting unit to ensure permission to write the change to the property tool data blockchain, the change including at least the change in payment level and the date and time when the change takes effect (914). The property tool data blockchain system implements its access protocol to verify that the contract engine has the necessary permissions. After receiving the permission verification via the receiving unit, the contract engine writes the change data to the blockchain via the transmitting unit, thereby creating a record of the payment level change on the blockchain (916).

[0141] The contract engine, via the transmission unit, generates (918) and sends (920) a second confirmation message to the web page, and the web page visible to the homeowner and investor reports that the change is effective as of the specified date and time. The contract engine, via the transmission unit, simultaneously alerts the homeowner and investor, who may be offline, via email or via an SMS message accessible by a mobile phone or other receiving device, that the change is effective as of the specified date and time. This configuration allows the homeowner to track payments made and accumulated earned equity via the same website, resulting in almost instant, low-cost changes to the terms of the financing plan. In future iterations of earned equity accumulation, the balancing engine takes into account the different payment levels and adjusts the accumulated amounts accordingly, so that the economic impact is just right for the homeowner and investor. The investor will not be net affected by the change in financing terms because the adjustment in the earned equity accumulation rate offsets any change in payment levels.

[0142] In a different embodiment, the financing package includes both a mortgage and an equity component, with the investor holding both positions simultaneously, and some or all of the homeowner's payments to the investor are mortgage payments. In this embodiment, the same mechanism as just described can be used, with the same result: refinancing can be low-cost, nearly instantaneous, and without any net financial consequences for the investor.

[0143] You can refer to Figure 10 To understand an embodiment, Figure 10 1 is a flow chart illustrating a process for approving an equity adjustment and issuing a transaction message requesting authorization and / or issuing a transaction message confirming a transaction according to an exemplary embodiment. Furthermore, with reference to the previous embodiment, the homeowner may wish to sell a portion of the homeowner's earned equity back to the investor in exchange for proceeds in fiat currency as specified in the contractual rights, without further approval from the investor, wherein, in a particular embodiment, the investor is a cryptocurrency portfolio affiliated with a management entity and the cryptocurrency portfolio holds the investor's interest in the home equity in a particular home.

[0144] A homeowner accesses a "management entity website" controlled by the management entity and initiates a request to buy or sell equity, generating a transmission message that is transmitted via a transmission unit to a receiving unit of a contract engine controlled by the management entity (1002). The data input to the contract engine is located in the home instrument data blockchain. The contract engine transmits a query to the home instrument data blockchain system along with access authorization data via the transmission unit to retrieve relevant data stored on the blockchain, the relevant data including applicable contract terms and at least the current values of relevant parameters of the current operational home valuation (1004). The home instrument data blockchain system implements its access protocol to determine whether the contract engine can access the requested data. After verifying that access is permitted, the contract engine receives data via the receiving unit, including contract data related to whether the transaction is permitted, and a processing unit associated with the contract engine determines whether the requested transaction is permitted under the contract without further approval from the investor, given the current values of the relevant parameters extracted from the home instrument data blockchain (1008). If the requested transaction is not allowed, a processing unit associated with the contract engine generates a rejection message (1010) and transmits the rejection message to the homeowner and the investor (or an artificial intelligence entity representing the investor) via email, SMS message, or other means.

[0145] The valuation includes a task that includes at least determining whether the homeowner will retain a minimum level of earned equity after the sale of the earned equity sufficient to support the homeowner's maintenance responsibilities. As part of the valuation, the contract engine calculates the equity amount and the corresponding dollar amount in percentage terms (of the home value) based on the home value extracted from the home instrument data blockchain for the equity value requested by the homeowner to be sold (1014). The contract engine generates a result message (1016) and sends the message via a transmission unit to an administrative entity website (1018) accessible to the homeowner and the investor. The request result message contains request result data, which includes at least: (i) the percentage and dollar value of the earned equity that the homeowner intends to sell to the investor; (ii) whether the request is approved or denied; (iii) in the case of denial, the applicable reason for the denial; and (iv) in the case of approval, the homeowner's confirmation and the time limit for the homeowner's confirmation request and payment receipt instructions.

[0146] The management entity website reports the approval or rejection and other applicable request result data through a graphical user interface or other accessible display option. The contract engine notifies the homeowner and investor (or artificial intelligence entity representing the investor), who may be in an offline state, via an email, SMS message, or other means, whether the request is approved and the request result data related to each party. If the request is approved, the notification to the homeowner includes a confirmation request (1020) requesting the homeowner to confirm the sales transaction. If the contract engine does not receive a confirmation from the homeowner within a certain period of time, the contract engine periodically sends a further confirmation request message to the management entity website accessible to the homeowner through the transmission unit, and the confirmation request message has confirmation request data including at least: (i) the percentage and dollar value of the net asset value earned that the homeowner intends to sell to the investor; and (ii) the time limit for the homeowner to confirm and pay, along with the homeowner's confirmation request and payment receipt instructions.

[0147] The contract engine notifies the homeowner, who may be offline, of the confirmation request along with the relevant confirmation request data via the transmission unit via email, SMS message, or other means. If the homeowner refuses to confirm or the confirmation time has expired, the contract engine will send a message to the management entity website accessible by the transmission unit, reporting that the homeowner has refused to confirm the transaction or that the confirmation period has expired (1022). The management entity website reports the refusal of confirmation or the expiration of the confirmation period through a graphical user interface or other accessible display options. The contract engine notifies the homeowner and investor (or artificial intelligence entity representing the investor), who may be offline, via the transmission unit via email, SMS message, or other means, that the confirmation has been refused or the confirmation period has expired.

[0148] If the homeowner confirms the transaction on the management entity's website, a transmission unit associated with the website sends a message indicating confirmation, along with the homeowner's payment indication, to a receiving unit associated with the contract engine. The contract engine, via the transmission unit, sends payment data, including at least the homeowner's due amount and a payment receipt indication, to a receiving unit for the cryptocurrency portfolio funds 104. In this embodiment, the cryptocurrency portfolio is designed to hold only real estate positions, not cash. Based on this design, the cryptocurrency portfolio funds processing unit determines that the cryptocurrency portfolio has no cash available to purchase the equity provided by the homeowner. Since no cash was paid to the homeowner in the sale transaction, the cryptocurrency portfolio funding processing unit sends a funding request message (1024) to the cryptocurrency trading engine operated by the management entity via the transmission unit.

[0149] You can refer to Figure 11 Understanding an embodiment of the cryptocurrency trading engine 118. A funding request message contains funding request data, which includes at least: (i) the cryptocurrency to be disbursed; (ii) the disbursement amount; (iii) the designated fiat currency of the proceeds; and (iv) payment receipt instructions for the homeowner. The cryptocurrency trading engine includes an embedded payment network and blockchain-based transaction mechanism (1102, 1104, 1106, and 1108) that allows the engine to initiate sales or purchases of the cryptocurrency it oversees in market transactions almost instantly, with verified credits or debits in the appropriate fiat currency to a "managed entity bank account," or "MEBA," which is a bank account or other repository controlled by the management entity. The MEBA is held at a third party or proprietary bank and is fully authorized to conduct electronic deposits and transfers.

[0150] Those skilled in the art will appreciate the various ways to operate such a payment network and blockchain-based transaction mechanism to execute cryptocurrency transactions almost instantly using appropriate verification methods. See, for example, US Pat. No. 9,870,562 B2. The cryptocurrency trading engine sends a command via a transmission unit 1104 to sell the newly issued relevant cryptocurrency units to one or more third parties or a receiving unit of a proprietary exchange to conduct a cryptocurrency transaction. Upon execution (1026), the exchange confirms the sale and transmits the funding of the relevant fiat currency to MEBA, possibly after one or more intervening transactions to convert the intermediate cryptocurrency used in the transaction into the required fiat currency. The exchange generates a transaction confirmation message and sends it to the receiving unit 1102 of the cryptocurrency trading engine. The cryptocurrency trading engine sends a payment request to MEBA via the transmission unit, which includes a payment receipt instruction submitted by the homeowner and received by the cryptocurrency trading engine from the contract engine as part of the funding request, requesting the release of the funding to the homeowner. After the funding is released (1028) and any required banking system confirmation, MEBA sends a payment completion message to the receiving unit of the cryptocurrency trading engine. The data of the cryptocurrency transaction is recorded on the cryptocurrency transaction blockchain 1108. After obtaining the required permissions from the cryptocurrency blockchain system, the cryptocurrency trading engine writes the data of the sales transaction to the cryptocurrency transaction blockchain through the transmission unit (1030).

[0151] Methods for operating cryptocurrencies via one or more such blockchain systems will be readily apparent to those skilled in the art. The cryptocurrency trading engine calculates completion data (1032) via processing unit 1106 and transmits a transaction completion message to the contract engine's receiving unit via a transmission unit. The transaction completion message includes completion data including at least (i) confirmation that the transaction is complete and payment has been made; (ii) the percentage and dollar value of the equity earned by the homeowner from the sale to the investor; (iii) the home valuation used to set the terms of the sale; and (iv) the date and time the sale was completed. The contract engine transmits a query and access authorization data to the property instrument data blockchain system via the transmission unit to obtain permission to write the completion data to the blockchain. The property instrument data blockchain system implements its access protocol to verify that the contract engine has the necessary permissions. After verification, the contract engine writes the completion data to the blockchain via the transmission unit, creating a record of the equity earned by the homeowner from the sale to the investor on the blockchain (1034). The contract engine generates a transaction confirmation message (1036) and sends the transaction confirmation message (1038) including at least completion data to the management entity's webpage via the transmission unit. The management entity's webpage, which is visible to the homeowner and the investor, reports the transaction confirmation and the relevant completion data. The contract engine also notifies the homeowner and the investor, who may be offline, of the transaction completion and the relevant completion data via an email or SMS message accessible by a mobile phone or other receiving device.

[0152] This configuration allows for nearly instant, low-cost financing increases through the same website that allows homeowners to track payments made and accumulated earned equity. In future iterations of earned equity accumulation, the balancing engine accounts for reductions in the homeowner's earned equity resulting from the sale of a portion of their earned equity to an investor. This instant execution and low cost contrasts sharply with financing increases through conventional mortgage loan options, which require refinancing an existing mortgage or borrowing a new loan subordinate to an existing mortgage, steps that typically take months or weeks and often involve offline transactions and visits to different websites.

[0153] The data of the cryptocurrency portfolio is located on the cryptocurrency portfolio blockchain. Figure 12 To understand one embodiment, a flowchart (1200) illustrates a process for updating a cryptocurrency portfolio blockchain system 1108 and transmitting transaction messages related to the portfolio's valuation according to an exemplary embodiment.

[0154] The portfolio engine 118 is embodied in a processing unit 1106, at least one receiving unit 1102, and at least one transmitting unit 1104, operated by the cryptocurrency portfolio fund on a processing server. In this embodiment, the cryptocurrency portfolio fund, which is affiliated with a management entity or an artificial intelligence entity representing the cryptocurrency portfolio fund, periodically sends queries and access authorization data to the housing instrument data blockchain system via the portfolio engine's transmitting unit to retrieve data related to its net asset value positions, the latest valuation data for the homes in the portfolio, and other information (1202). The housing instrument data blockchain system 120 implements its access protocol to determine whether the portfolio engine can access the requested data. After verifying that access is permitted, the portfolio engine 110 receives the relevant data via the receiving unit. The processing unit associated with the portfolio engine updates information about the cryptocurrency portfolio (1204), and after obtaining the required permissions from the cryptocurrency blockchain system, the portfolio engine writes the updated information to the cryptocurrency portfolio blockchain (1206) via the transmitting unit. The portfolio engine generates a portfolio update message (1208) and sends the updated portfolio information via the transmitting unit to a website accessible to investors in the cryptocurrency portfolio, where the updated information is reported. This information includes, at a minimum, a valuation of the portfolio according to one or more specified valuation methodologies and the corresponding value per unit of the cryptocurrency.

[0155] In one or more embodiments, additional features such as an investor approval step may be added to the process of a homeowner selling earned equity to an investor, and a similar process may apply where a homeowner purchases equity from an investor rather than selling equity to an investor.

[0156] You can refer to Figure 13 To understand one embodiment, according to an exemplary embodiment, the flowchart (1300) illustrates the process of Figure 1 The housing instrument data blockchain system extracts and organizes a data set, records this data set to the housing instrument data blockchain system, and publishes a data report message. The management entity or an artificial intelligence entity acting on its behalf periodically sends a message to the receiving unit of the contract engine to initiate a data set update entry on the housing instrument data blockchain. The contract engine transmits a query and access authorization data of the housing instrument data blockchain system via the transmitting unit to extract relevant data, characterized by at least the current status of each housing instrument including payment ratios and terms, the next payment date and amount, the current level of equity earned on the property, the current level of key parameters including at least implicit rent and property value, and other data characterized by the current status of the housing instrument (1302). The housing instrument data blockchain system implements its access protocol to determine whether the contract engine is allowed to access the requested data. After verification that access is allowed, the contract engine receives this data via the receiving unit, and the processing unit associated with the contract engine updates the housing instrument data set (1304). The contract engine sends this updated data set to the transmitting unit, which writes it to the housing instrument data blockchain (1306). The contract engine generates a report message containing the updated data set (1308) and sends the report message via the delivery engine to a website accessible to the homeowner and investor, where the updated data set is reported (1310).

[0157] A homeowner or investor can visit the management entity's website at any time and observe the payment ratio and terms, including the next payment date and amount, the current level of equity earned by the homeowner, the current levels of key parameters (including at least implicit rent and housing value), and other data representing the current status of the housing instrument. Behind this capability is the website network that continuously updates the website information by reading the housing instrument data blockchain, which is itself continuously updated by various data and process engines including at least the valuation engine and contract engine maintained by the management entity.

[0158] The embodiments thus far describe a system in which homeowners can access a single website and multiple GUI-based pages to perform a wide range of functions in a low-cost and nearly instantaneous manner, including at least: monitoring earned equity levels and current data regarding the instruments governing the home, making payments to investors, refinancing by changing payment levels or repaying equity held by investors, and increasing financing levels at current market terms by selling earned equity back to investors. This system addresses the fragmentation, high costs, and lack of coordination inherent in current home financing technology. At the core of the system is a unique balancing mechanism.

[0159] Balancing mechanism based on DOOR housing instruments

[0160] Each DOOR balancing engine is characterized by a specific balancing mechanism. The examples of DOOR tools described above involve the following situations:

[0161] (i) Single homeowner;

[0162] (ii) individual investors;

[0163] (iii) the homeowner is making a positive net contribution when the housing scheme is analyzed as a joint venture; and

[0164] (iv) The homeowner receives earned equity in exchange for the net capital contribution during the life of the instrument, i.e., the unleveraged share upon sale of the home or termination of the DOOR contract.

[0165] DOOR schemes can involve multiple homeowners, multiple investors, positive net contributions from investors other than homeowners, and the use of surplus accounts beyond earned equity to offset net contributions. Starting with the basic scenario where limitations (i)-(iv) above hold, the DOOR balancing mechanism can be quickly explained. After demonstrating how the DOOR balancing mechanism operates in this scenario, according to one or more embodiments, it will become clear to those skilled in the art how the innovation can be applied more generally. The following sections further illustrate the application through additional discussion and illustrative examples.

[0166] This section first describes a class of accumulation algorithms for earned equity disclosed for the base case, specifies the "Buy Parity" variant of this class that has received significant attention, and then discusses the theoretical basis for this class of algorithms and the Buy Parity variants. The Buy Parity accumulation algorithm is the basis for the balancing mechanism of the previously described MM-0 embodiment. This embodiment is a direct solution, as the associated balancing mechanism implements the MM-0 housing solution itself. As will become clear from the embodiments of the present invention described later, the same balancing mechanism built around the Buy Parity accumulation algorithm is useful in many situations where the embodiments are not direct solutions. Other accumulation algorithms in this class form the basis for other balancing mechanisms applicable to other embodiments of the present invention.

[0167] Let's start with the homeowner's net equity contribution. As mentioned above, the major positive elements include mortgage payments or other payments to the investor, property tax payments, and maintenance expenses. The major negative element is the implicit rental value of living in the home. All of these elements are ongoing flows, accruing over time. Visible liquidity is evident in the standard practice of daily prorated mortgage payments and property tax obligations when properties are bought or sold.

[0168] We will calculate the net rent turnover rate n r Defined as: the turnover rate r of gross rent, which is the homeowner's occupancy value; the depreciation rate d of the structure; the accrual rate p of property tax obligations; and the turnover rate f of other non-financing expenses. For simplicity, it is assumed that the homeowner's maintenance responsibilities include all depreciation expenses. Net rent does not include any mortgage or other debt-like service charges. Therefore, net rent is the return stream accruing to the unlevered owner of the property.

[0169] n r (t) = r(t) - p(t) - d(t) - f(t)

[0170] Where t represents time in years, indicating that each current element in the equation will change over time. Dividing by the value of the home at time t, H(t), gives the ratio of accrued net rent to home value:

[0171]

[0172] With respect to the financing element, the homeowner is making mortgage contributions and / or regular payments at the following interest rates:

[0173] m(t)=m p (t)+m i (t)+s p (t)

[0174] Among them, in the case of mortgage loan payment, m p(t) is the ratio of capital contribution, and m i (t) is the interest contribution ratio. p (t) is the rate of periodic payments, if any. We use the term "contributions" rather than "payments" because some financing may be implicitly provided by the homeowner, such as committed equity discussed below, for which interest contributions are estimated rather than paid. Normalizing these financing contributions by the home's value yields the accrued financing charges as a percentage of the home's value:

[0175]

[0176] The current annual net contribution ratio of the homeowner to the value of the home is:

[0177] γ(t)=μ(t)-v(t) (2)

[0178] Assume that the earned equity ratio at time t is E(t). Then define the homeowner's total earned net contribution ratio as:

[0179]

[0180] Now we can define a class of accumulation algorithms for the net asset value earned in the claims. Suppose the instrument is held for a period of time T. Divide this period T into n equal-length Consider the following discrete approximations of the proportion of equity earned:

[0181]

[0182] Among them, t i-1 is the time when period i starts, t i is the time at the end of period i, and ω(t) is the weighting function. After removing the approximation, we get the exact, continuous-time proportion of net asset value earned:

[0183]

[0184] Equations (4) and (5) define a class of accumulation algorithms with different weighting functions ω(t) 1 For example, ANZIE-DOOR, an example of a DOOR variant, is defined by the following weighting function:

[0185]

[0186] where i f (t) is a suitable long-term risk-free rate, α(t) is the expected appreciation rate of the house, and v(t) is defined as shown in the above equation (1).

[0187] Applying a specific weighting function, ω(t) = 1, yields a purchase-parity DOOR variant defined by the following earned equity accumulation algorithm:

[0188]

[0189] in

[0190]

[0191] This variant has the characteristic that the accumulation of equity earned is the same as the net contribution flow at each instant in time used to purchase additional house value at the house value at that instant in time. To see this, note that for time dt:

[0192]

[0193] Ignore insignificant terms in higher powers of dt. Equation (8) indicates that at a small time instant dt, the portion of equity earned that increases is simply the ratio of the annualized net contribution rate to the home's value multiplied by dt. The homeowner has effectively purchased additional home equity for the exact dollar amount of the homeowner's net contribution. Hence the name of this variant, "buy parity."

[0194] This variant has attractive properties. Because the homeowner effectively purchases the home equity from the investor at the market value of that equity, both parties receive the exact economic return on the home from their unleveraged positions. If either party is leveraged, that party receives the same leveraged return. In the case of a "single" DOOR instrument, all financing is provided by the investor, so the investor is effectively unleveraged, earning the exact economic return on the home from their combined position. Thus, by combining the single DOOR investments into a portfolio, a vehicle for obtaining a composite exact economic return on the underlying home is obtained. This property makes a single DOOR instrument an ideal tool for creating a portfolio that can replicate home returns across different regions, countries, or the world, effectively replicating the return on a home index approximated or created by the collection of underlying homes in the combined instrument.

[0195] While the purchase parity variant is highly attractive and a central aspect of the present invention, other variants defined by different weighting functions are also relevant for commercial application. Weighting functions greater than 1 produce higher earned equity amounts compared to purchase parity, while weighting functions less than 1 produce lower earned equity amounts compared to purchase parity. These weighting functions are a means of creating allowances or adjustments for risk or other aspects that are not reflected in the calculation of the contribution or the accumulated position of the contributing party. Under the purchase parity variant, the purchaser obtains the economic return inherent in a particular position after purchasing the position. Thus far, the only position considered is earned equity, i.e., the unleveraged interest in the home. However, as described in the next section, many other positions or adjustments may serve as residual accounts in addition to or in lieu of earned equity, depending on the claimed method.

[0196] So far, the proposed DOOR variant has been described as a continuous stream of quantities consisting of at least implicit rent, depreciation, property taxes, and mortgage payments. When a particular payment of P at time t is discrete rather than part of a stream, the increase in net worth earned, ΔE, is:

[0197]

[0198] The discrete element can be added to the current element by adding the discrete element governed by equation (9) to the continuous element described by equations (4) and (5). In the case of a purchase at par, the equity earned from an outright purchase at the current home price can be used to calculate both the discrete and current components.

[0199] Approximations can be used. For example, for some values of n, E n (t) instead of Alternatively, in the case of purchase parity, the total net contribution can be calculated by summing the contributions for each period using the midpoint of the flow period and then dividing by the home price at the midpoint of that period. The present invention encompasses the use of approximations. However, it must be noted that in some cases, approximations are inappropriate unless they are very close to the exact answer. For example, the purchase parity variant has the property that, if calculated accurately, investors and homeowners receive the exact ex post return on the home for each incremental investment. This property is crucial for creating a portfolio of DOOR instruments that is equivalent to a home return index or that accurately captures the home return. Even convincing approximations, such as using the midpoint of each period, can produce cumulative returns that differ significantly from actual returns, especially for short holding periods.

[0200] There is an analogy between the problem of strategic buying and selling in capital gains taxation and the problem of balancing housing options between investors and homeowners. In the case of capital gains, an ideal accrual tax would tax gains and allow losses to occur. An equivalent approach would be to value gains and losses as they occur and then accumulate them with interest to be paid when the asset is sold. In contrast, there is a problem if only the gross gains or losses on the sale are valued and taxed, without taking into account the history of gains and losses during the holding period. Taxpayers have an incentive to defer gains by not selling the asset ("locking in") or to sell the asset to realize losses (strategic losses). In both cases, the government loses revenue, and investor behavior is distorted because investors hold or sell assets based on the tax impact rather than the expected pre-tax return on the asset. Alan Auerbach (see AJ Auerbach, Retrospective Capital Gains Taxation, American Economic Review, vol. 81, pp. 167-178 (March 1991)) shows that there is a unique solution to the tax treatment of sales that eliminates distorted incentives and restores the economic equilibrium in which investors hold or sell assets solely based on their economic returns relative to other assets. For an asset purchased at time 0 and sold at time s, the tax at that time, i.e., a fraction of the asset's value, is A. s for:

[0201]

[0202] Among them, τ is the tax rate, r f is the appropriate risk-free rate.

[0203] The housing scheme problem presents a similar problem. The net contributor can be compensated through a sales tax imposed on the other party. Without loss of generality, consider the homeowner as the net contributor in the scheme, and the other party as the investor. Under the tax scenario, the investor assumes the role of the asset owner, while the homeowner assumes the role of the government. The homeowner's net contribution creates a tax liability for the investor. Similar to the tax setting, there are at least three ways to pay off the tax liability:

[0204] (1) The investor immediately pays the offset to the homeowner and pays the tax on the spot;

[0205] (2) note the taxes due, allow them to accumulate at an appropriate interest rate, and then have the investor pay the accumulated amount to the homeowner upon sale; and

[0206] (3) Taxing the asset upon sale by retaining a certain percentage of the equity for the homeowner.

[0207] The third solution is similar to the earned equity approach discussed above. In the case of the housing scenario, the only solution that does not interfere with incentives has the same form as the solution represented by equation (10). If the housing scenario is more or less favorable to the homeowner than the market transaction, problematic incentives will arise for the homeowner to improperly persist in the transaction when it turns against the investor, or to refinance when the transaction reverses and becomes unfavorable to the homeowner. This problem requires enabling the homeowner to obtain more favorable terms in the housing market to offset the situation where market conditions cause the homeowner to refinance at the expense of the investor. The problem with the static housing scenario is the same as that mentioned earlier in this application.

[0208] To transform Equation (10) into a unique solution for the accumulated net worth earned in the housing scenario, one element is missing: the tax rate. Clearly, one factor in the tax rate is the positive net contribution of the taxing party, represented by the ratio in Equation (10). However, the net contribution rate needs to be normalized by the rate of return, which reflects the proportion of the return on the taxing party's contribution. That is, after taking into account total income (a factor discussed later), the tax rate will take the following form:

[0209]

[0210] where ρ(t) is the rate of return. Now transform Equation (10) into Equations (4) and (5) with the following weighting function:

[0211]

[0212] where i f Equal to r f , which are different signs for the same appropriate risk-free rate. As mentioned above, the choice of ρ(t) and ω(t) is open, depending on the objectives of the housing program. If there is no need to adjust for risk or other factors not captured in the calculation, and no need to use ω(t) to create subsidies, then choosing ω(t) = 1 is very convincing: the choice of purchasing affordable properties creates a market return for the benefits gained or retained by both parties.

[0213] The basic principle of total net investment is to use γ * (t) instead of γ(t) is clear in Auerbach's scheme, as is also evident from the mathematics of equation (8) above. In Auerbach's scheme, the proportion of the distribution E(t) to the asset holder at time t belongs to the government because this is the proportion that would be taxed if the asset were sold at time t. Similarly, the government's capital contribution C to the asset holder is equal to its capital contribution to the joint venture Then immediately Thus, when a loan is made to the government under the Auerbach scheme, or to a net contributor under the Housing scheme, the contribution to the joint venture should be included in the total.

[0214] Scope of public categories

[0215] The previous section detailed the treatment of DOOR housing solutions, in which earned equity is the residual account used to maintain economic balance. A party's net contribution to the solution will receive an accrual of earned equity in its favor. The previous section described appropriate accrual rates for a class of accrual algorithms, each of which defines a balancing mechanism.

[0216] There are numerous other possible residual accounts, and any given scenario may have multiple accounts. Extending the analysis in the previous sections to scenarios involving residual accounts other than or in addition to earned net worth is particularly straightforward for the purchase-at-par variant. This innovation involves extending from the purchase-at-par variant to variants with other accrual scenarios, but we will treat the purchase-at-par property as the norm to keep it simple and straightforward.

[0217] Committed equity. Committed equity is a position similar to a second mortgage, except that the holder accrues interest as a credit in the net contribution scheme rather than receiving interest payments. An ANZIE-DOOR variant includes committed equity. In this variant, the homeowner's net contribution, based on all items except the down payment or mortgage principal payments, is converted into earned equity. In contrast, any down payment or mortgage principal payment made by the homeowner becomes actual committed equity. For example, assume an ANZIE-DOOR plan is used to purchase a home for $200,000. The DOOR investor contributes $40,000 in equity, the homeowner makes no down payment, and has a $160,000 amortizing mortgage loan, on which the homeowner pays interest and principal. Suppose that after a few years, the homeowner has paid a total of $10,000 in principal, leaving the mortgage loan balance at $150,000. The homeowner now has $10,000 in committed equity, and this $10,000 position has accrued interest at the appropriate imputed rate, which counts as part of the homeowner's ongoing net contribution. 2 Under ANZIE-DOOR, down payments and mortgage payments are converted into committed equity, a method of accruing committed equity comparable to the purchase parity method described above. The homeowner separately accrues earned equity to compensate for net contributions from mortgage interest payments, property taxes, home maintenance, and other sources. Thus, ANZIE-DOOR is an example of a door instrument with multiple residual accounts: committed equity and earned equity.

[0218] Random Payments. In some applications, it is desirable to fix or limit the accumulation of earned equity. One obvious approach is to vary the payments from the homeowner, the investor, or both. If the payments vary with economic conditions, such that the net contribution rate remains at zero, the proportion of earned equity will remain constant. In this case, the random payment is the residual account.

[0219] Leveraged Equity. In the MM-0 scenario described above and the MM-1 scenario described below, the homeowner accumulates earned equity, an unleveraged interest in the home. Rather than using earned equity as a residual account, some form of leveraged equity may be employed. This leveraged equity may be used to pay down the existing mortgage, in which case the investor and the homeowner share the conventional equity in the home. As the homeowner's position accrues, it is important to understand what happens to the mortgage debt, whether the liability is owed to the investor as the mortgagee or to a third party. In one embodiment, the investor is the mortgagee and transfers the liability for the corresponding portion of the mortgage and the conventional equity portion as part of the accrual in favor of the homeowner. The transferred portion of the mortgage is a recourse claim against the homeowner. In another embodiment, if the investor holds a mortgage that reflects the non-recourse nature of the mortgage with respect to the homeowner, the homeowner effectively purchases conventional equity from the investor through appropriate interest rate adjustments on the mortgage. In another embodiment, the homeowner accrues an American call option position in exchange for a net capital contribution. Other embodiments are contemplated where leveraged equity, rather than earned equity, is the remaining account and the relevant accrual algorithm for the instrument class being considered is used to create the leveraged equity accrual.

[0220] Separate Accumulation Account. Net contributions can be accumulated in a separate account, rather than in debt or equity shares in the home. This account can earn a predetermined interest rate or a rate derived from market rates, or can be invested in mortgages, index funds, or other assets, including cryptocurrencies backed by a real estate portfolio. Rules regarding distributions determine whether and to what extent the party who made the net contribution can withdraw or liquidate a portion of the account before the home is sold. Restricting this ability to do so may be desirable, for example, to ensure that the party holding the account fulfills its maintenance responsibilities for the property. Saving-Door is an example of using a separate accumulation account as a residual account.

[0221] Many other residual accounts. This innovation encompasses a wide variety of other residual accounts that could be used for housing balancing scenarios. This includes, but is not limited to, virtually any type of debt or equity position in a home, as well as scenarios such as allocating residence time shares between parties. The present invention encompasses all possible residual accounts designed to implement economic balancing.

[0222] It's worth reiterating the importance of the dynamic elements of the instrument. For example, if the homeowner's earned equity position is fixed at a specific value, and the homeowner's payment is another element of the scheme, then the homeowner's payment must vary to maintain a zero net contribution rate. Otherwise, the scheme begins to favor either the homeowner or the investor, no longer being neutral, and it becomes impossible to ensure that both parties receive a market rate of return on their respective positions.

[0223] In addition to using residual accounts other than earned equity, it is worth noting that there are other approaches to the claimed class that are broader than the various examples described above and below. Among other approaches, two of particular importance are those where a party other than the homeowner makes a positive net contribution, and those where more parties are involved than a single homeowner, a single investor, or a single mortgagee.

[0224] In many implementations, the investor, rather than the homeowner, accrues earned equity or some other residual account. A prominent example is COZIE-DOOR, an instrument in which the homeowner receives ongoing or lump-sum payments from the investor in exchange for an earned equity or committed equity position in the home. In one version of COZIE-DOOR, the investor pays the homeowner an annuity, and earned equity accrues as the annuity payments accrue. Property taxes, homeowner insurance, or other payments may be added to the plan to compensate for the larger amount or faster accrual of earned equity.

[0225] In other embodiments, there may be multiple investors, multiple homeowners, or multiple mortgagees. In some cases, these circumstances may necessitate accruing earned equity or other residual accounts to multiple parties. Each such party may contribute a different type or amount of capital than the other parties. As the value of the economic variable changes, the relative capital contributions of the parties may also change.

[0226] Another feature of neutral DOOR instruments is that they allow for seamless transitions between them by freezing the terminal value of one instrument and then instantly inserting the balance into a new, different instrument. For example, a homeowner might move from an instrument like MM-0 involving earned equity to a variant involving a leveraged equity position. Such changes in either direction can be accomplished almost instantly online if investors and / or potential mortgagees agree to a scheme that allows this flexibility. Such a scheme is IS-A-DOOR.

[0227] MM-1 Home Financing Program

[0228] The MM-0 home financing scheme is embodied in a single instrument. No third party provides a mortgage or any other type of financing. In contrast, the MM-1 home financing scheme requires multiple instruments. The third party provides the mortgage financing, and the DOOR investor provides conventional equity financing. Therefore, MM-1 introduces the need to coordinate the mortgage with the equity instrument and the homeowner, not only for traditional reasons such as the homeowner or investor's right to make additional principal payments, but also because MM-1 tightly links the mortgage and equity instruments.

[0229] The MM-1 variant adds several features to the MM-0:

[0230] (1) Mortgages secured by DOOR investors. Third-party mortgages are a recourse against DOOR investors, providing insurance-like security for the mortgagee's mortgage balance. DOOR investors are compensated on an ongoing basis through the slow accrual of equity earned by the homeowner.

[0231] (2) Mortgage repayment limits the loan-to-value ratio. The DOOR investor is obligated to repay the mortgage loan at a low value, creating a cap on the loan-to-value ratio. The cap is set to ensure that the equity the DOOR investor is selling exceeds the earned equity payment the DOOR investor must pay to the homeowner, thereby ensuring that this obligation is met. The DOOR mechanism provides the DOOR investor with accurate financial compensation for any repayments, creating an incentive for the investor to stay in the program when repayments become necessary. This compensation comes in the form of an increase in the traditional equity position and a reduction in the total mortgage payment, which means that the investor accrues less earned equity that he must pay to the homeowner at the time of sale.

[0232] (3) Mortgage / Equity Insurance Protection. For all but the most reputable DOOR investors, insurance companies will back the DOOR investor's mortgage guarantees, mortgage repayments, and earned equity obligations. A DOOR investor's failure to make a required mortgage payment triggers a penalty from the insurance company on the DOOR instrument. The insurance company receives compensatory value for making the payment, and such measures are needed to create incentives at this time.

[0233] The MM-1 scheme has considerable commercial potential. Homeowners acquire homes with little or no down payment, and the unleveraged nature of their equity can, if the terms are set appropriately, represent a significant portion of the home's value over several years, meaning they remain a solid market even if prices decline. Investors who choose to rent out their homes are also more likely to benefit, as the return on investment increases due to the fact that the equity owner is currently occupying the home.

[0234] The MM-1 program significantly reduces the business risks for mortgage lenders, mortgage originators, the GSEs that guarantee mortgages, and buyers of bonded mortgage obligations by creating a powerful layered mortgage credit enhancement mechanism:

[0235] (i) When values are low, homeowners have a strong incentive to maintain their homes because their unleveraged equity is real;

[0236] (ii) Similarly, in the low-value scenario, the homeowner's incentive to continue paying the mortgage remains strong because payments result in compensating accruals in the equity earned;

[0237] (iii) the mortgage loan is secured by the DOOR investor;

[0238] (iv) DOOR investors are responsible for making down payments on mortgages to maintain a cap on LTV, eliminating the problem of an "underwater" home that is worth less than the underlying mortgage obligation; and

[0239] (v) The insurance company provides mortgage loan guarantees and repayment responsibilities to DOOR investors.

[0240] These layered credit enhancement mechanisms, the last three of which were added by MM-1, significantly reduced the risk of default and foreclosure on mortgage loans. This approach maintained LTV levels below 100% and created strong incentives for homeowners to maintain their homes and continue to make mortgage payments, even if home values declined significantly. Mortgage lenders were much less dependent on the homeowner's ability to repay because DOOR investors provided mortgage security and were themselves backed by mortgage insurance.

[0241] MM-1 was a game changer for mortgage insurers. A condition of the insurance contract stipulated that a DOOR investor's failure to make a required mortgage payment resulted in the investor forfeiting the DOOR investment in favor of the insurer. The insurer stepped in, replacing the DOOR investor as a party to the DOOR contract and paying the required mortgage payments under the contract. This payment superficially resembled paying a mortgage insurance claim. However, there was a key difference: rather than simply absorbing the loss, the insurer now owned the asset and paid the required mortgage payments, resulting in a precise increase in the value of the asset. The balance sheet impact was positive because the asset had value before the repayment, and the repayment was fully compensated. Furthermore, due to the widespread decline in home values nationwide, the insurer faced a significant amount of defaulted payments due to its leveraged equity position in a broad housing portfolio. When the economy recovered, the insurer's accumulated assets rebounded sharply. If the insurer did not want to assume this portfolio investment role and the associated volatility, it could sell the DOOR instrument to a willing third party and simultaneously write an insurance contract on the instrument. The net effect was to transfer the instrument from the non-performing party to the performing party while retaining the associated insurance business.

[0242] These features of the MM-1 scheme, which ties the mortgage loan to the equity instrument, require intensive and time-sensitive communication to implement the necessary chain of decisions between the homeowner, the DOOR investor, the mortgagee, and the mortgage insurer. For example, a decline in home prices can trigger a repayment feature that requires notification to the investor, a request for action from the investor, and, if the investor fails to act, the transfer of the instrument. Repayment can result in the homeowner choosing between payment alternatives for a reduced mortgage loan, which throws the homeowner into a loop. Time is crucial to maintaining creditworthiness, ensuring that the payment of the homeowner's earned equity is guaranteed. The present invention provides all of these features.

[0243] Implementing the MM-1 housing financing program

[0244] To describe a specific embodiment of how the present invention implements an MM-1 home financing solution, we'll focus on the ownership period and begin with a simple case: a homeowner, an investor, a mortgage loan with a single mortgagee, and a single mortgage / equity insurance company. Thus, the mortgage loan is third-party home financing provided by the mortgagee, a third-party financing entity, and the mortgage / equity insurance company is a third-party service provider. In this embodiment, the mortgagee also services the mortgage loan, collects payments, and provides information to the mortgage lender.

[0245] At the core of an embodiment of the present invention is a balancing engine, embodied in a processing unit, at least one receiving unit, and at least one sending unit, operated by a management entity on a processing server. The balancing engine evaluates the ongoing contributions of homeowners and investors over time, treating the housing proposal between them as a joint venture. In one embodiment, the investor and mortgagee initially finance the entire home with traditional leveraged equity and a mortgage loan, respectively, the homeowner pays the mortgage loan principal and interest to the mortgagee, the homeowner pays property taxes, the homeowner maintains the home, and the homeowner lives in the home. In this embodiment, the homeowner's net contribution is equal to (i) the mortgage loan principal and interest paid to the mortgagee, (ii) property taxes paid, (iii) maintenance fees, and (iv) other liabilities such as insurance, minus (v) fees collected as rent ("implicit rent"), which is the value of living in the home. The balancing mechanism requires a residual account to align the interests of the homeowner and investor. In this embodiment, the remaining account includes earned equity, the unleveraged equity of the home, which the investor must pay to the homeowner upon sale of the home or termination of the financing plan, and the payments are arranged so that the homeowner's net contribution is positive.

[0246] In this embodiment, the data used to input the balancing engine is located in the housing instrument data blockchain. The data includes all time series, and the capital contribution element includes at least the mortgage loan paid by the homeowner to the investor. Figure 5 The management entity, or an artificial intelligence entity acting on its behalf, periodically sends a message to a receiving unit of a balancing engine to initiate a balancing entry to the home instrument data blockchain (502). The balancing engine transmits a query to the home instrument data blockchain system, along with access authorization data, via a transmitting unit, to obtain relevant data regarding contributions and other elements, including a control algorithm for calculating the earned equity under a contract covering a housing financing solution, which is itself encoded on the home instrument data blockchain (504). The home instrument data blockchain system implements its access protocol to determine whether the balancing engine can access the requested data. After access rights are verified, the balancing engine receives this data via the receiving unit, and a processing unit associated with the balancing engine updates the homeowner's earned equity balance (506). The balancing engine sends the updated balance along with details of the calculation to the transmitting unit, which writes it along with details of the calculation itself to the home instrument data blockchain (508). The balancing engine transmits the updated earned equity value via the transmitting unit to a website accessible to homeowners and investors, where the new value is reported (510). The balancing engine alerts the homeowner and the investor (or an artificial intelligence representing the investor), who may be offline, of the updated earned equity data (512) via an email or SMS message sent by the transmitting unit via a mobile phone or other receiving device.

[0247] An example can refer to Figure 14 To understand, Figure 14 A flow chart (1400) is shown for a process of writing payment data to a blockchain system and obtaining update data from the blockchain system according to an exemplary embodiment.

[0248] Input data for balancing operations is located on a housing instrument data blockchain and is generated and updated by multiple data engines located on one or more servers controlled by a management entity, each data engine comprising at least one processing unit, at least one receiving unit, at least one transmitting unit, and at least one database. Each data engine is operable to create, aggregate, update, process, store, and communicate at least one time series of at least one data parameter. When implementing the MM-1 housing financing scheme, the data engines include at least one third-party data engine: a mortgage loan data engine residing on one or more servers controlled by the management entity, embodied in at least one processing unit, at least one receiving unit, at least one transmitting unit, and at least one database, the mortgage loan data engine being operable to aggregate, store, process, and communicate data related to third-party mortgage loans. When a homeowner makes a mortgage loan payment, the transmitting unit of the mortgagee's processing server sends a payment message (1402) to the receiving unit of the mortgage loan data engine operating on the processing server controlled by the management entity. The payment message contains payment data including at least: (i) the payment amount; (ii) the breakdown between principal and interest; and (iii) the time and date of the payment. The processing unit of the mortgage loan data engine converts the data into a form suitable for the home instrument data blockchain (1404) and transmits a query and access authorization data to the home instrument data blockchain system via the transmission unit to ensure permission to write the payment data to the blockchain. The home instrument data blockchain system implements its access protocol to verify that the mortgage loan data engine has the necessary permissions. After receiving the verification confirmation via the receiving unit, the mortgage loan data engine writes the payment data to the home instrument data blockchain via the transmission unit (1406). The mortgage loan data engine transmits a query and access authorization data to the home instrument data blockchain system via the transmission unit to obtain data sufficient to update the status of the mortgage loan, including at least the payment history, the current principal balance after the most recent payment, and the loan-to-value ratio based on the most recent operational valuation of the home located on the home instrument data blockchain (1408).

[0249] The housing tool data blockchain system implements its access protocol to ensure that the mortgage data engine has access to the requested data. After verifying access rights, the mortgage data engine receives the relevant data via a receiving unit (1410), and the processing unit of the mortgage data engine organizes the mortgage-related data into a format suitable for website display, ultimately forming a displayable mortgage-related data package (1412). Through a transmitting unit, the mortgage data engine transmits the displayable mortgage-related data to a website accessible to homeowners, investors, and mortgage / equity insurance companies. The website updates the mortgage-related data using the received displayable mortgage-related data (1414). The mortgage data engine notifies the homeowner, investor (or an artificial intelligence entity representing the investor), and mortgage / equity insurance company (or an artificial intelligence entity representing the mortgage / equity insurance company) of the updated mortgage-related information, which may be offline, via an email or SMS message sent by the transmitting unit via a mobile phone or other receiving device.

[0250] refer to Figure 7The valuation engine is a data engine operating on a processing server controlled by a management entity that creates and updates a time series of home values for a home to be financed by writing to a home instrument data blockchain. The valuation engine receives a data request corresponding to a home valuation request (702). The valuation engine, through one or more receiving units, collects third-party valuations through queries (704). The valuation engine records these valuations in a database (706) through a transmission unit. When applicable (708), the valuation engine generates one or more non-third-party valuations (710) through a processing unit and uses one or more statistical processes to combine the third-party valuations and non-third-party valuations into an operational valuation (712) for use by the balancing engine and the contract engine. The valuation engine transmits queries to the home instrument data blockchain system and access authorization data through the transmission unit to ensure permission to write valuation data to the blockchain. The home instrument data blockchain system implements its access protocol to verify that the valuation engine has the necessary permissions. After receiving the verification confirmation via the receiving unit, the valuation engine writes the operational valuation along with a timestamp and calculation record to the home instrument data blockchain (714) via the transmitting unit, including at least the third-party and non-third-party valuations, the method for calculating the non-third-party valuation, and the method for calculating the operational valuation (716). The valuation engine generates a data message (718) and sends at least the new operational valuation along with the third-party and non-third-party valuations to a website accessible to the homeowner and investor via the transmitting unit (720), where these valuations are reported. If the homeowner and investor (or the artificial intelligence entity representing the investor) have requested an update to the operational valuation generally or when certain values are achieved, the valuation engine notifies the homeowner and investor (or the artificial intelligence entity representing the investor) who may be offline of the new operational valuation via the transmitting unit via email or SMS message via a mobile phone or other receiving device.

[0251] Other data elements (including, at a minimum, implicit rent, depreciation, and property tax liabilities) are subject to other data engines that operate in a similar manner to the valuation engine.

[0252] The management entity maintains a contract engine embodied in at least one processing unit, at least one receiving unit, and at least one transmitting unit on at least one processing server controlled by the management entity for initiating, implementing, executing, and updating a home financing arrangement between at least one homeowner and an investor. Input data for the contract engine is located in a home instrument data blockchain.

[0253] You can refer to Figure 15 To understand an embodiment, Figure 15A flowchart (1500) illustrates a process for requesting a valuation from a blockchain system and recording a repayment amount on the blockchain, according to an exemplary embodiment. The valuation engine sends a message to a receiving unit of a contract engine via a transmitting unit, indicating that the operational valuation has been updated with data including at least the new operational valuation (1502). The contract engine transmits a query and access authorization data to the property instrument data blockchain system via the transmitting unit to obtain data related to the current mortgage loan principal balance and other elements, including the governing algorithm used to determine whether the investor is required to repay the mortgage loan, and the required repayment amount (1504). The property instrument data blockchain system implements its access protocol to determine whether the contract engine can access the requested data. After verifying access rights, the contract engine receives the data via the receiving unit, and a processing unit associated with the contract engine determines whether the investor is required to repay the mortgage loan (1506) and, if so, the required amount (1508). If the processing unit determines that repayment is required, the contract engine transmits a query and access authorization data to the property instrument data blockchain system via the transmitting unit to ensure permission to write the repayment data to the blockchain. The property instrument data blockchain system implements its access protocol to verify that the contract engine has the necessary permissions. After receiving the verification confirmation via the receiving unit, the contract engine records its determination of whether the investor repayment is required and the associated calculated information on the housing instrument data blockchain via the transmitting unit (1510). The contract engine sends the mortgage loan repayment data, including at least the required repayment amount and payment deadline, to the receiving unit of the investor's processing server (1512, 1514). The investor's processing server sends a query to the housing instrument data blockchain system via the transmitting unit, along with the access authorization data, to obtain relevant data to verify the need for repayment and the amount.

[0254] The housing utility data blockchain system implements its access protocol to determine whether the investor has access to the requested data. After verifying access rights, the investor's processing server receives the requested data via a receiving unit and verifies, via the processing unit, whether repayment is due. Following verification, in one embodiment, the investor's processing server sends a payment request message via a transmitting unit to the receiving unit of the mortgagee's processing server. This message includes at least the source of the investor's funds, the payment amount, and payment instructions for the mortgage loan to be applied as an additional payment on the principal. In a second embodiment, an intermediate step, namely, investor approval, occurs. The investor's processing server accesses a database to determine the appropriate person or AI representative of the investor authorized to grant or deny approval. The investor's processing server sends the approval or denial request via the transmitting unit to the receiving unit of a designated processing server associated with that person or AI representative. If the person has decision-making authority, the transmitting unit also sends the approval or denial request to that person, who may be offline with respect to the designated processing server, via email, SMS message, or other means. The approval or rejection request includes at least: (i) the requested repayment amount; and (ii) a website link protected by a password or other protection measures and operated by a designated processing server, where a person with decision-making authority can indicate approval or rejection on the website. The designated processing server sends a message indicating approval or rejection to the receiving unit of the investor's processing server via a transmission unit. In the case of approval, the investor's processing server sends a payment request message to the receiving unit of the mortgagee's processing server via a transmission unit, the message including at least the designated investor fund source, the payment amount, and payment instructions for the mortgage loan to which it applies as an additional payment of the principal. In the case of rejection, the investor's processing server sends a rejection notification message to the receiving unit of the contract engine via the transmission unit.

[0255] An example can refer to Figure 16 To understand, Figure 161600 is a flowchart illustrating a process for recording payment data to a blockchain system or using a blockchain system to identify contract terms, according to an exemplary embodiment. In the case of the first or second embodiment, when a person or artificial intelligence representative authorized to approve a repayment indicates approval, the mortgagee's processing server receives a payment request message (1602) and attempts to collect funds from the investor's bank account specified in the payment instruction (1604) using methods apparent to those skilled in the art. If funds are sufficient (1606) to cover the entire payment and the entire payment is collected, the mortgagee's processing server's processing unit, after appropriately updating the mortgagee's record in the database or receiving the necessary permissions to write to the blockchain, sends a repayment message to a receiving unit of a mortgage loan data engine operating on a processing server controlled by an administrative entity. The repayment message contains repayment execution data, including at least: (i) the repayment amount; (ii) the payment time and date; and (iii) the monthly payment amount after repayment. The processing unit of the mortgage loan data engine changes the repayment execution data into a form suitable for the house instrument data blockchain, and the mortgage loan data engine transmits a query and access authorization data to the house instrument data blockchain system through the transmission unit to ensure the authority to write the repayment execution data into the blockchain (1608).

[0256] The housing instrument data blockchain system implements its access protocol to verify that the contract engine has the necessary permissions. After receiving verification confirmation via the receiving unit, the mortgage loan data engine writes the repayment execution data to the housing instrument data blockchain via the transmitting unit (1610). The mortgage loan data engine transmits a query and access authorization data to the housing instrument data blockchain system via the transmitting unit to obtain data sufficient to update the status of the mortgage loan, including at least payment history, current principal balance and monthly payment amount after repayment, and a loan-to-value ratio based on the most recent operational valuation of the home located on the housing instrument data blockchain. The housing instrument data blockchain system implements its access protocol to determine whether the mortgage loan data engine can access the requested data. After verifying access permissions, the mortgage loan data engine receives the mortgage loan-related data via the receiving unit, and the mortgage loan data engine's processing unit organizes the mortgage loan-related data into a format suitable for website display, thereby forming a displayable mortgage loan-related data package (1612). The mortgage data engine transmits the displayable mortgage-related data to a website accessible to homeowners, investors, and mortgage / equity insurance companies via the transmission unit. The website then updates the mortgage-related data using the received displayable mortgage-related data (1614). The mortgage data engine notifies the homeowner, investor (or an AI entity representing the investor), and mortgage / equity insurance company (or an AI entity representing the mortgage / equity insurance company), who may be offline, of the updated mortgage-related information via email or SMS messages sent via mobile phones or other receiving devices via the transmission unit. The balancing mechanism embodied in the balancing engine ensures that investors receive full financial compensation for repayments on a risk-adjusted basis. Furthermore, investors avoid position losses that would occur if the investor failed to repay. These two aspects promote repayment transactions by creating a strong incentive for investors to repay.

[0257] If the mortgagee's processing server is unable to collect the repayment amount from the investor's bank account specified in the repayment instruction due to insufficient funds in the account to cover the full repayment or for any other reason (1606), the mortgagee's processing server sends an insufficient funds notification to the contract engine's receiving unit via the transmitting unit. The contract engine transmits a query to the housing instrument data blockchain system and access authorization data via the transmitting unit to obtain relevant data regarding the contract clause covering the insufficient funds situation, including the time limit for the investor to rectify the situation (1616).

[0258] The property instrument data blockchain system implements its access protocol to determine whether the contract engine can access the requested data. After verifying access rights, the contract engine receives the data via a receiving unit, and a processing unit associated with the contract engine accesses a database to determine the investor's designated personnel to receive the insufficient funds notification (1618). The contract engine generates an insufficient funds notification (1620) and transmits the insufficient funds notification to the receiving unit of the investor's processing server via a transmitting unit. The insufficient funds notification is also sent by the transmitting unit via SMS or other means to designated personnel of the investor, who may be offline with respect to the investor's processing server (1622). The insufficient funds notification includes at least: (i) the amount due; (ii) the amount of available funds; (iii) any other issues that prevent the collection of repayment; and (iv) the deadline for increasing the balance or designating another source of funds. The contract engine periodically sends the same notification to the same party, including the investor's processing server, within the time period set by the contract terms encoded and accessed by the property instrument data blockchain until: (i) the contract engine receives the repayment notification; or (ii) the deadline for remediating the insufficient funds issue expires (1624, 1626).

[0259] You can refer to Figure 17 To understand one embodiment, a flowchart (1700) of processing a received default notice (1702) using data obtained from a blockchain and determining and recording changes to an investor in a blockchain system according to an exemplary embodiment is provided. If the investor refuses to approve the repayment or the rectification period for insufficient funds expires, the contract engine then sends a query to the property instrument data blockchain system and access authorization data via a transmission unit to obtain relevant contract data regarding the steps to be taken if the investor defaults on the repayment obligation (1704).

[0260] The home instrument data blockchain system executes its access protocol to determine whether the contract engine can access the requested data. After access rights are verified, the contract engine receives the data via a receiving unit, and the contract engine sends a default notice (1706) via a transmitting unit to a receiving unit of a processing server operated by a mortgage / equity insurance company. The default notice contains default data, including at least: (i) the identity of the defaulting investor; (ii) the amount of the required repayment; (iii) notification that the repayment is now the responsibility of the mortgage / equity insurance company; (iv) the payment request and instructions on how to pay it; (v) notification that the investor's DOOR instrument position will be transferred to the mortgage / equity insurance company; (vi) access to the mortgage / equity insurance company's authorization data to obtain appropriate data on the home instrument data blockchain related to the position; and (vii) access to the administrative entity's website that displays information for investors. The contract engine enables the payment engine (1708) to monitor the status of the mortgage / equity insurance company's repayment obligations using methods readily apparent to one skilled in the art, send appropriate periodic notifications to the insurance company until payment is made, and verify payment (1710) thereafter, and then generate (1712) and send (1714) a payment completion message via a transmitting unit to a receiving unit of the contract engine. The payment message contains data including at least: (i) the fact of payment; (ii) any relevant verification data; (iii) the amount of the payment; (iv) the date and time of payment; (v) any changes to the monthly mortgage payment level, if any; and (vi) identification information of the mortgage / equity insurance company required to add the insurance company as an investor on the home instrument data blockchain. Upon receipt of the payment message, the contract engine transmits, via the transmitting unit, a query to the home instrument data blockchain system along with access authorization data for changing the permissions of investors in the instrument covered by the blockchain. The home instrument data blockchain system implements its access protocol to verify that the contract engine has the required permission level to make such changes. After verification, the contract engine writes to the blockchain that the mortgage / equity insurance company replaces the defaulting investor as the owner of the applicable investment equity in the applicable instrument (1716). The contract engine generates a replacement message (1718) and sends the replacement message via the transmission unit to the receiving unit of the processing server of the mortgage / equity insurance company, indicating that the ownership exchange has been completed (1720).

[0261] Now refer to Figure 14The contract engine sends a repayment message (1420) to the receiving unit of the mortgage loan data engine via the transmission unit. The repayment message includes repayment execution data, including at least: (i) the amount of repayment; (ii) the time and date of payment; and (iii) the amount of monthly payments after repayment. The processing unit of the mortgage loan data engine changes the repayment execution data into a form suitable for the housing instrument data blockchain (1404), and the mortgage loan data engine transmits a query and access authorization data to the housing instrument data blockchain system via the transmission unit to ensure permission to write the repayment execution data to the blockchain.

[0262] The housing instrument data blockchain system implements its access protocol to verify that the contract engine has the necessary permissions. After receiving the verification confirmation via the receiving unit, the mortgage loan data engine writes the repayment execution data to the housing instrument data blockchain via the transmitting unit (1406). The mortgage loan data engine transmits a query and access authorization data to the housing instrument data blockchain system via the transmitting unit to obtain data sufficient to update the status of the mortgage loan, including at least the payment history, the current principal balance and the monthly payment amount after repayment, and the loan-to-value ratio based on the most recent operational valuation of the home located on the housing instrument data blockchain (1408). The housing instrument data blockchain system implements its access protocol to determine whether the mortgage loan data engine can access the requested data. After verifying the access rights, the mortgage loan data engine receives the mortgage loan-related data via the receiving unit (1410), and the processing unit of the mortgage loan data engine organizes the mortgage loan-related data into a format suitable for website display, thereby forming a displayable mortgage loan-related data package (1412). The mortgage data engine transmits the displayable mortgage data to a website accessible to homeowners, investors, and mortgage / equity insurance companies via the transmission unit. The website updates the mortgage data using the received displayable mortgage data (1414). The mortgage data engine notifies the homeowner, investor (or an AI entity representing the investor), and mortgage / equity insurance company (or an AI entity representing the mortgage / equity insurance company), who may be offline, of the updated mortgage-related information via an email or SMS message sent by the transmission unit via a mobile phone or other receiving device. The balancing mechanism embodied in the balancing engine ensures that the mortgage / equity insurance company receives full financial compensation for repayments on a risk-adjusted basis. In addition, the mortgage / equity insurance company receives all investment interest from defaulting investors as a reward. These two elements promote repayment transactions by providing a strong incentive for the mortgage / equity insurance company to repay.

[0263] refer to Figure 18, a flowchart (1800) is shown for obtaining contract term data from a blockchain system and activating a payment engine to generate payment data and write the payment data to the blockchain system. In one embodiment, if a homeowner fails to make a mortgage loan payment, the investor is obligated to make the payment in their place, provided that certain conditions are met, including at least that the homeowner's profitable equity position is sufficient to secure the homeowner's maintenance obligations. When a mortgage loan payment is overdue, the mortgagee's processing server sends a past due payment notification (1802) via a transmission unit to a receiving unit of a processing server operated by an administrative entity where the contract engine resides. Upon receipt of the notification, the contract engine transmits a query to the housing instrument data blockchain system and access authorization data via the transmission unit to obtain relevant data regarding the contract terms, which cover the investor's responsibilities in the event of a past due payment, including the time limit within which the investor will rectify the situation (1804).

[0264] The housing instrument data blockchain system implements its access protocol to determine whether the contract engine can access the requested data. After confirming that access is permitted, the contract engine receives the data via the receiving unit (1806). The contract engine uses this data to verify that the investor is responsible for making mortgage payments and the terms, conditions, and timing of this responsibility (1808). The contract engine transmits a query to the housing instrument data blockchain system along with the access authorization data via the transmitting unit to obtain relevant data regarding the reduction in the homeowner's profitable equity position that would result if the investor, rather than the homeowner, immediately completed the mortgage payment (1810). The housing instrument data blockchain system implements its access protocol to determine whether the contract engine can access the requested data. After confirming that access is permitted, the contract engine receives the data via the receiving unit. If the investor makes the payment directly rather than the homeowner, the processing unit of the contract engine calculates the earned equity impact and then formulates a past due payment procedure message (1814) that includes at least the following: (i) the amount of the mortgage payment; (ii) the fact that it is past due; (iii) the investor's obligation to pay if the homeowner does not pay; (iv) the reduction in the homeowner's earning equity position that would result if the investor, rather than the homeowner, made the payment immediately; (v) the time within which the homeowner would make the payment before the investor must pay; (vi) the fact that the homeowner may make additional future payments to offset the reduction in earning equity that would result from not making the payment; and (vii) the fact that the future additional payment is likely to be may be paid on different terms and, therefore, the amount required to restore the homeowner’s earned equity position to the level it would have been had the homeowner made all mortgage payments in the first place may be greater or less than the missed mortgage payment; (viii) require the homeowner to notify the management entity and the investors if the homeowner intends not to make a payment within the due date, which will eliminate any future correspondence; and (ix) invite the homeowner to discuss with the management entity whether the homeowner’s financial situation will make it difficult for the homeowner to make mortgage payments after the due date, thereby enabling the management entity, the investors, and the homeowner to develop a plan to address the situation, which may include the investor making mortgage payments rather than the homeowner making mortgage payments over an extended period of time.

[0265] The processing unit further develops three web-displayable versions of the overdue payment process data, respectively, for the homeowner, the investor, and the mortgage / equity insurance company (1814). The contract engine, via the delivery unit, transmits the three web-displayable versions to a website operated by the administrative entity, making each version accessible to the corresponding party: the homeowner, the investor, and the mortgage / equity insurance company (1816). The contract engine, via the delivery unit, alerts the homeowner, the investor (or an artificial intelligence entity representing the investor), and the mortgage / equity insurance company (or an artificial intelligence entity representing the mortgage / equity insurance company), who may be offline, of the data in the version appropriate to each party via an email or SMS message sent by a mobile phone or other receiving device.

[0266] The contract engine enables the payment engine (1818) to monitor the status of overdue mortgage loan payments using methods readily apparent to one skilled in the art, notify the investor if the homeowner indicates that they do not intend to pay within the due date, and send appropriate periodic notifications to the homeowner and investor until one of them makes a payment (1820). The contract engine then generates a payment completion message (1822), which is sent via the transmission unit to the contract engine's receiving unit. The payment completion message includes payment data including at least: (i) the payment fact; (ii) any relevant verification data; (iii) the payment amount; (iv) the payment date and time; and (v) the identity of the payee. Upon receiving the payment message, the contract engine transmits, via the transmission unit, a query to the housing utility data blockchain system and access authorization data to allow the payment data to be written to the blockchain.

[0267] The housing instrument data blockchain system implements its access protocol to verify that the contract engine has the required level of permission to write such data to the blockchain. Upon verification, the contract engine's processing unit reformats the relevant payment data and writes it to the housing instrument data blockchain via the transmission unit (1824). The contract engine transmits a query and access authorization data to the housing instrument data blockchain system via the transmission unit to retrieve data related to the impact of the investor's payments relative to the homeowner's mortgage loan payments on the homeowner's earned equity position (1826). The housing instrument data blockchain system implements its access protocol to determine whether the contract engine can access the requested data. Upon verification that access is permitted, the contract engine receives the data via the receiving unit, and the processing unit associated with the contract engine calculates the impact of the investor's payments relative to the homeowner's mortgage loan payments on the homeowner's earned equity position (1828). After completing this calculation, the contract engine, through the processing unit, formulates payment completion data that includes at least the following: (i) the amount of the mortgage payment; (ii) the identity of the person making the payment; (iii) the effect of the homeowner's payment or waiver of the payment on the homeowner's earned equity; (iv) if the homeowner does not make the payment, the homeowner may make future additional payments to offset the reduction in earned equity resulting from the missed payment; and (v) the fact that such future additional payments are likely to be made on different terms, such that the amount required to restore the homeowner's earned equity position to the level it would have been if the homeowner had made the mortgage payment may be more or less than the amount of the missed mortgage payment (1830). The processing unit further formulates three web-displayable versions of the payment completion data, one for the homeowner, one for the investor, and one for the mortgage / equity insurer. The contract engine, through the transmission unit, transmits the three displayable versions to a website operated by the administrative entity, making each version accessible to the respective parties: the homeowner, the investor, and the mortgage / equity insurer (1832). The contract engine of the transmission unit alerts the homeowner, investor (or artificial intelligence entity representing the investor), and mortgage / equity insurance company (or artificial intelligence entity representing the mortgage / equity insurance company), who may be offline, via email or SMS message via a mobile phone or other receiving device, of the data in the appropriate versions transmitted to each party.

[0268] Now refer to Figure 14The contract engine sends a payment completion message to the receiving unit of the mortgage loan data engine via the transmitting unit, the message including that the contract engine has written the mortgage loan payment data to the housing instrument data blockchain. The mortgage loan data engine transmits a query and access authorization data to the housing instrument data blockchain system via the transmitting unit to extract data sufficient to update the status of the mortgage loan, including at least payment history, current principal balance and monthly payment amount after the mortgage loan is paid, and loan-to-value ratio based on the latest operational valuation of the housing located on the housing instrument data blockchain (1408).

[0269] The housing tool data blockchain system implements its access protocol to determine whether the mortgage data engine is able to access the requested data. After verifying that access is permitted, the mortgage data engine receives the data via a receiving unit (1410), and the processing unit of the mortgage data engine organizes the mortgage-related data into a format suitable for website display, thereby forming a displayable mortgage-related data package (1412). The mortgage data engine transmits the displayable mortgage-related data to a website accessible to the homeowner, investor, and mortgage / equity insurance company via a transmitting unit, where the website updates the mortgage-related data using the received displayable mortgage-related data (1414). The mortgage data engine notifies the homeowner, investor (or an artificial intelligence entity representing the investor), and mortgage / equity insurance company (or an artificial intelligence entity representing the mortgage / equity insurance company), who may be offline, of the updated mortgage-related information via the transmitting unit via email or SMS message via a mobile phone or other receiving device. The balancing mechanism embodied in the balancing engine ensures that if an investor is responsible for a missed mortgage payment by a homeowner, the investor will be fully financially compensated because the equity position earned by the homeowner, who is the investor's future liability, will be reduced by the appropriate amount. This element promotes mortgage payments by providing investors with the appropriate incentives.

[0270] The embodiment of the MM-1 housing solution just described illustrates that, even in an environment where multiple third parties (relative to the homeowner and investor) are involved in a complex transaction, computer technology including the present invention enables the homeowner to access a single website and a variety of GUI-based pages to perform a wide range of functions at low cost and almost instantaneously: monitor the level of equity earned and current data regarding the instruments governing the home, monitor the status of the underlying mortgage loan, resolve nonpayment issues, and more generally obtain relief from payments during periods of financial hardship and flexibility. The embodiment illustrates how computer technology including the present invention can facilitate complex interactions involving third parties (in the specific example above, the mortgage / equity insurance company and the mortgagee) as well as the homeowner and investor, while implementing a low-cost integrated presentation on a single website. The present invention implements a web page presentation to the homeowner that is parallel to the scope of presentation on the investment services website, in which the complex auxiliary functions involving the third parties operate effectively but invisibly.

[0271] It should be appreciated that the present invention enables many other tasks for the MM-1 scheme and other schemes involving third parties beyond those described in the above examples. For example, in the case of the MM-1 scheme, according to one or more embodiments, computer technology incorporating the present invention can ensure a low-cost, integrated website presentation while enabling the implementation of the tasks described above with respect to MM-0, including at least: (i) "refinancing" by changing the payment level; (ii) reducing the financing level by repaying the equity held by investors; and (iii) increasing the financing level under current market terms by selling the earned equity back to investors. In the case of the MM-1 housing scheme and similar schemes involving third parties, as well as MM-0, the system addresses the fragmentation, high cost, and lack of coordination currently applicable to housing financing technologies. Both MM-0 and MM-1 schemes are direct schemes that can be implemented directly from the output of a balancing engine that includes an implementation-neutral balancing mechanism. However, as illustrated in the following two sections, the present invention is more general.

[0272] Planned Earned Equity Home Financing Options

[0273] Both the MM-0 and MM-1 scenarios introduce uncertainty for the homeowner. For example, it is clear from equations (1), (2), (4), and (5) that if the implicit rent of the home increases relative to the home's value, the homeowner accrues a lower amount of earned equity in percentage terms. An alternative approach is to pre-fix the earned equity plan. However, unless another residual account (such as payments) captures the uncertainty, for example by varying the homeowner's payments to the investor to produce a plan with expected earned equity, the home financing scenario will be non-neutral. For example, assume that a fixed accrual plan for earned equity is based on assumed values of the net contribution elements, and that all elements except the rent-to-price ratio meet the assumptions over time. If the rent-to-price ratio is higher than the assumed ratio, then the scenario favors the homeowner. If the rent-to-price ratio is lower than the assumed ratio, then the scenario favors the investor. In the first scenario, the homeowner has an incentive to stay in the home and maintain a better deal than the market currently offers. In the second scenario, the homeowner has an incentive to refinance, for example, to obtain a new fixed earned equity plan that is more favorable.

[0274] This asymmetry caused by the homeowner's prepayment option means that investors must charge an upfront premium or exit fee to account for the homeowner's incentive to abandon the plan if it favors the investor, but to retain it if it favors the homeowner. The homeowner must monitor the situation and refinance when conditions favor the investor. Neutrality is lost as market fluctuations can cause the plan to favor either the homeowner or the investor, making the prepayment option a significant factor. Nevertheless, for some risk-averse homeowners, the benefits of reducing risk through a plan that fixes the accrual of earned equity may outweigh the added complexity and any associated restrictions or fees required to address the asymmetry.

[0275] Because this scheme is not neutral, it cannot be implemented as a direct scheme that uses a neutral balancing engine to generate scheme results, like direct schemes such as MM-0 or MM-1. However, computer technology including the present invention can use an appropriate neutral balancing mechanism to create a low-cost, integrated website presentation similar to the MM-0 and MM-1 home financing schemes.

[0276] Consider a specific home financing plan that meets all the criteria of a MM-0 home financing plan, but the earned equity accrual received by the homeowner is planned and fixed in advance. When the home is sold and the plan terminates, the results of this plan will almost always deviate from the homeowner's unplanned results under MM-0. Suppose that the plan includes a third party that agrees to take a position with a return equal to the unplanned amount the homeowner would have received minus the planned amount the homeowner actually received. Generally speaking, this position might be called the "residual balance position," or "RBP," because it covers the difference between the homeowner's unplanned residual amount and the planned fixed amount. Here, we call it the "equity balance position," or "EBP," because the residual account in this plan is earned equity, the unleveraged equity of the home. The third party holding the EBP absorbs the risk in the residual earned equity account that would otherwise be borne by the homeowner. Therefore, we refer to this plan as an "EBP plan."

[0277] To illustrate the EBP scenario, assume that a homeowner sells their home for $100,000 after seven years. At this point, the homeowner's accrued equity is credited to the planned amount at 25%, while the unplanned amount is 30%. The EBP credits the 5% difference. The homeowner has $25,000, the investor has $70,000, and the third party holding the EBP has $5,000. If the unplanned amount were 23% instead of 30%, the homeowner would contribute $25,000, the investor would receive $75,000 from the sale proceeds, and the third party holding the EBP would pay the investor an additional $2,000, bringing the investor's total to $77,000. In this scenario, the third party holding the EBP would suffer a $2,000 loss.

[0278] An EBP scheme is defined by the following properties:

[0279] (1) Unintended Equity Results are MM-0 Results. Unintended Equity Results are the results that would have occurred under the MM-0 housing financing plan.

[0280] (2) The homeowner's earned equity outcome is planned. The homeowner receives a percentage of the earned equity according to a plan based on the holding period. The plan determines the outcome in the absence of any changes, such as a change in the payment level between the homeowner and the investor, the homeowner purchasing additional equity from the investor, or the homeowner selling earned equity to the investor.

[0281] (3) The EBP result is the hypothetical homeowner's net worth earned from the unplanned result minus the actual planned result. If the unplanned result is U percentage points and the planned result is S percentage points, the result for the third party holding the EBP is US percentage points. If the result is negative, the third party holding the EBP pays the selling investor a corresponding percentage of the home's value. If the result is positive, the third party holding the EBP receives a corresponding percentage of the sale proceeds.

[0282] (4) The investor always receives an amount equal to the MM-0 (unplanned) outcome. If the EBP is positive at the time of sale, the investor receives a share of the sales proceeds equal to the investor's share under the MM-0 plan, and the third party holding the EBP splits the homeowner's share under the MM-0 plan with the homeowner. If the EBP is negative at the time of sale, the homeowner receives more than the unplanned equity gain, and the remaining sales proceeds go to the investor. The EBP pays the investor an amount equal to the amount the homeowner receives in excess of the unplanned amount the homeowner would have received under the MM-0 plan. This payment, combined with the investor's share of the sales proceeds, results in the investor receiving a total that fully matches the investor's share under the MM-0 plan. This property is important if the investor's goal is a combination of raw owner-occupied real estate returns, home value appreciation plus net rent, as this is the investor's position return under the MM-0 plan.

[0283] Because EBPs are not neutral, their implementation typically works best with some restrictions or fees that mitigate the asymmetry problem. In effect, homeowners have an incentive to refinance if market fluctuations make the plan more favorable to investors, and to retain the plan when it benefits them, potentially longer than otherwise. Third parties holding EBPs bear two risks. First, there's "prepayment risk" arising from the asymmetry problem: if market conditions cause the fixed earned equity accrual to favor the EBP holder, the homeowner can prepay and refinance. Second, even assuming no prepayments, the EBP transfers the risk of fluctuations in the earned equity accrual rate from the homeowner to the third-party EBP holder. Under this plan, the homeowner receives a fixed plan with fixed earned equity accruals, and the EBP precisely absorbs fluctuations in the accrual rate—a kind of "investment risk." If the transferred risk is positively correlated with systemic risk in the economy, though the direction and magnitude of the correlation are unclear, this investment risk may warrant some form of premium to make the EBP viable.

[0284] The asymmetry problem raises several questions about the various actions a homeowner might take. Refinancing is an obvious option. In an EBP, refinancing amounts to buying out the investor's equity position and then financing the buyout amount with a new EBP, a conventional mortgage, or some other method. The low-cost, nearly instant refinancing offered by EBP, implemented by computer technology, exacerbates the asymmetry problem by making refinancing so easy and inexpensive that homeowners can avoid continuing in an EBP that favors the investor, even if the EBP only slightly favors the homeowner. Homeowners can also choose to replace an unfavorable EBP with another financing method other than the EBP. For example, after buying out the investor's equity, a homeowner might move to an MM-0 option or even simply hold all the equity in the home, effectively self-financing.

[0285] Refinancing isn't the only transaction affected by the asymmetry problem. Any change to the originally envisioned homeowner contribution model undermines the existing EBP program, as the fixed earned equity plan assumes that expected model. For example, if the homeowner chooses to reduce their payment level to the investor, the accrual rate on the earned equity will need to be adjusted downward. The existing fixed plan must be replaced. One approach is to simply end the existing EBP program and create a new one based on current market conditions. However, if market parameters cause the old plan to favor investors, such a shift amounts to a strategic refinancing to exit the old plan. A second example is when the homeowner purchases additional equity from the investor. This action both negates the applicability of the existing fixed earned equity plan and partially replaces the EBP program with self-financed funds, allowing the homeowner to partially escape the investor-favored EBP.

[0286] Numerous approaches to addressing the asymmetry and adjusting the terms of the EBP program to compensate EBP holders for prepayment and investment risk are readily apparent to those skilled in the art. In one embodiment, detailed in the following section, two approaches are employed, which can be applied individually or in combination. First, certain actions by the homeowner can result in an adjustment fee, which can be in the form of a certain amount of earned equity or cash. For example, liquidating, refinancing, or adjusting the EBP position before the sale of the home can result in an adjustment fee, which takes the form of a transfer of a portion of the homeowner's earned equity to the EBP holder as part of the closing. The amount of the fee can depend on factors such as the specific homeowner actions, the time since the EBP was established, and the degree to which the EBP benefits the EBP holder. Regarding the third factor, the adjustment fee can be designed so that if the homeowner's actions result in the termination of an EBP program that benefits investors, the homeowner compensates the EBP holder for some or all of the lost benefits. Setting the adjustment fee in this manner can eliminate much of the asymmetry while also introducing a corresponding amount of prepayment risk for the EBP holder.

[0287] The second approach is to adjust the plan's fixed rate of earned NAV accrual. This approach has particular value in addressing the investment risk faced by EBP holders, who, without a fixed rate, face uncertainty about the rate of earned NAV accrual. If investment risk is positively correlated with systemic risk in the economy, it is priced in by the market and requires EBP investors to pay a premium. One way to create this premium is to reduce the plan's earned NAV accrual. This reduction increases EBP holders' expected returns because they realize that the amount equals the unplanned outcome minus the planned outcome, which is now lower. The reduction in the plan's rate can be set so that the increase in expected return just covers the market price of investment risk.

[0288] It is best practice, even if not required by the rules, to disclose potential adjustment fees and how they are calculated, as well as a method for setting a fixed schedule for the homeowner's accumulated earned equity, as part of the initial contractual provisions establishing the EBP program. In the embodiments detailed below, data for these elements is recorded on a blockchain to facilitate the operation of the computer technology comprising the present invention.

[0289] Implementing a planned, earned-accrual EBP housing financing program

[0290] To describe an embodiment of how the present invention implements an EBP home financing solution, we focus on a simple case involving an owner, an investor, and a single third party holding an EBP. The core of the present invention's implementation is a balancing engine embodied in a processing unit, at least one receiving unit, and at least one transmitting unit, operated by an administrative entity on a processing server. The balancing engine evaluates the ongoing contributions of the homeowner and investor over time, treating the home solution as a joint venture between them. In one embodiment, the investor initially finances the entire home, the homeowner pays the investor, the homeowner pays the property taxes, the homeowner maintains the home, and the homeowner resides in the home.

[0291] In this embodiment, the homeowner's net contribution equals (i) the homeowner's payment to the investor, (ii) property tax payments, (iii) alimony, and (iv) other responsibilities, such as insurance, minus (v) fees charged as rent ("implicit rent"), which represents the value of living in the home. The balancing mechanism requires a residual account to coordinate the interests of the homeowner, investor, and EBP holder. This embodiment employs a balancing mechanism suitable for a MM-0 home financing plan, where the residual account includes earned equity, the unleveraged interest on the home, which the investor in the MM-0 plan will pay to the homeowner upon the sale of the home or termination of the financing plan, and is configured to ensure that the homeowner's net contribution is positive. However, this embodiment is not an MM-0 home financing plan. Instead, the homeowner accrues earned equity under a pre-determined schedule. The result for the homeowner is the "planned result," a number of percentage points representing the homeowner's share of the home sale proceeds. The result of the balancing engine is the "unplanned result," expressed in percentage points, which will be the homeowner's actual result under the MM-0 home financing plan. Unlike planned outcomes, unplanned outcomes are not known in advance but depend on the values of various economic parameters during the plan period. In this embodiment, unplanned outcomes are calculated as a percentage used to calculate the return to the EBP holder. Upon sale, the EBP holder receives proceeds from the sale of the home equal to the unplanned outcome minus the planned outcome, if the percentage is greater than or equal to zero. Conversely, if the planned outcome is greater than the unplanned outcome, the EBP pays the investor a percentage of the sales proceeds in cash equal to the planned outcome minus the unplanned outcome.

[0292] This embodiment includes a transition agreement between the homeowner, the investor, and the EBP holder. The transition agreement takes effect upon the homeowner initiating certain changes, including at least: (i) a change in the homeowner's payment level to the investor; (ii) a purchase of equity from the investor; (iii) a sale of equity to the investor; (iv) a termination of the old plan and its associated fixed schedule of homeowner earned equity accrual under market terms in favor of the new EBP plan, which includes a new and different fixed schedule of homeowner earned equity accrual; or (v) a termination of the old plan and its associated fixed schedule of homeowner earned equity accrual under the MM-0 home financing plan, in which the homeowner earned equity accrual is not fixed but is instead equal to the unplanned results under the EBP plan. These changes typically require terminating the existing EBP plan, adjusting the equity share as if selling the home, and then conducting a cash transaction to close the equity credits or debits held by the EBP holder, thereby creating corresponding equity adjustments for the investor and homeowner. If the EBP holder has an equity credit, the EBP holder sells the corresponding equity position to the investor at the operating valuation of the home. If the EBP holder has an equity debit, the EBP holder owes equity to the homeowner. In this case, the EBP holder purchases the required equity shares from the investor at the operating valuation of the home for purposes of the transition agreement and then transfers the required equity shares to the homeowner. The equity shares received by the homeowner and investor from this process become the baseline equity shares for the new EBP or MM-0 agreement, which replaces the existing EBP program. The transition agreement requires both parties to make the necessary transitional cash and equity transfers. This embodiment includes computer technology to facilitate the cash and equity transfers, with the goal of being nearly instantaneous.

[0293] refer to Figure 19, illustrates a flowchart (1900) of a blockchain system update process associated with an initiated EBP scheme. In an embodiment, a contract engine operating on a processing server controlled by an administrative entity initiates, implements, enforces, and updates housing financing schemes between at least homeowners, investors, and EBP holders, including creating, updating, and accessing contract information governing the EBP housing financing schemes. The contract engine is embodied in at least one processing unit, at least one receiving unit, and at least one transmitting unit. Input data to the contract engine resides in the housing instrument data blockchain and includes at least data encoding the contract terms governing the EBP housing financing schemes. When an EBP housing scheme is initiated (1902), the administrative entity causes initial contract data to be sent to the receiving unit of the contract engine processing server. The initial contract data includes at least: (i) the names, addresses, and contact information of the parties initiating the contract; (ii) all contract terms; and (iii) information regarding the purchase or ownership of the house, including at least proof of title and title insurance.

[0294] The contract terms include at least: (i) an initial fixed earned equity accrual schedule for the homeowner; (ii) the initial equity holdings of the homeowner and investor; and (iii) any applicable adjustment fees if the homeowner takes actions that include at least a refinancing option, changing the payment level to the investor, or purchasing a portion of the investor's equity. The contract engine, via the processing unit, formats the initial contract data into a form suitable for writing to the home instrument data blockchain (1904). The contract engine, via the transmitting unit, transmits a query and access authorization data to the home instrument data blockchain system to ensure permission is obtained to write the formatted contract data to the blockchain. The home instrument data blockchain system implements its access protocol to verify that the contract engine has the necessary permissions. After receiving verification confirmation via the receiving unit, the contract engine, via the transmitting unit, writes the initial contract data to the blockchain, creating a record of the new home financing option on the blockchain (1906).

[0295] refer to Figure 20Flowchart (2000) illustrates the process of adding balancing entry data to a blockchain system related to an unplanned outcome. In one embodiment, a balancing engine located on a processing unit controlled by an administrative entity creates and updates a time series of hypothetical unplanned outcomes, accumulating earned equity for a homeowner under a MM-0 housing scenario. The data input to the balancing engine resides in the housing instrument data blockchain. This data includes a time series of all contribution elements, including at least payments made by the homeowner to investors. The administrative entity, or an artificial intelligence entity acting on its behalf, periodically sends a message to the balancing engine's receiving unit, initiating a balancing entry of the current hypothetical unplanned outcome to the housing instrument data blockchain (2002). The balancing engine transmits a query and access authorization data to the housing instrument data blockchain system via a transmitting unit to extract relevant data regarding contributions and other elements, including a governing algorithm for calculating earned equity under a hypothetical MM-0 housing financing scenario, which is encoded in the housing instrument data blockchain (2004).

[0296] The housing instrument data blockchain system implements its access protocol to verify that the balancing engine can access the requested data. Upon verification, the balancing engine receives the requested data via a receiving unit. A processing unit associated with the balancing engine updates the unplanned results, i.e., the homeowner's hypothetical earned equity balance, and related quantities using the unplanned results as input, including at least the percentage shares and amounts that the homeowner, investor, and EBP holder would implement or pay if the home were sold at the current operating valuation recorded on the housing instrument data blockchain (2006). The balancing engine transmits the query to the housing instrument data blockchain system, along with the access authorization data, via a transmitting unit, to ensure that the updated unplanned results and related quantities are written to the blockchain.

[0297] The housing instrument data blockchain system implements its access protocol to verify that the balancing engine has the necessary permissions. Upon verification, the balancing engine, via the transmission unit, writes the updated unplanned results and associated quantities to the housing instrument data blockchain (2008). The balancing engine, via the transmission unit, transmits the updated unplanned results and associated quantities to a website controlled by the management entity, accessible to homeowners, investors, and EBP holders, where the updated values and associated quantities are reported (2010). The balancing engine, via the transmission unit, notifies homeowners, investors (or artificial intelligence entities acting on their behalf), and EBP holders (or artificial intelligence entities acting on their behalf), who may be offline, of the updated unplanned results and associated quantities via email or SMS messages sent to mobile phones or other receiving devices.

[0298] You can refer to Figure 7Understanding one embodiment. Input data for balancing operations that form the basis for creating a time series of unplanned results is located on a property instrument data blockchain and is generated and updated by a plurality of data engines located on one or more servers controlled by a management entity, each data engine comprising at least one processing unit, at least one receiving unit, at least one transmitting unit, and at least one database. Each data engine is configured to create, aggregate, update, process, store, and communicate at least one time series of at least one data parameter. A valuation engine is a data engine operating on a processing server controlled by the management entity that creates and updates a time series of home values for a home to be financed by writing to the property instrument data blockchain. The valuation engine receives a data request corresponding to a property valuation request (702). The valuation engine collects third-party valuations (704) via queries from one or more receiving units. The valuation engine encodes these valuations in a database (706) via the transmitting unit. The valuation engine, via the processing unit, generates one or more non-third-party valuations (710) when applicable (708) and combines the third-party valuations and the non-third-party valuations into an operational valuation (712) using one or more statistical processes for use by the balancing engine and the contract engine. Through the transmission unit, the valuation engine transmits the query and access authorization data of the housing tool data blockchain system to ensure that the updated operational valuation, calculation method, and other updated valuation data are allowed to be written on the blockchain.

[0299] The housing instrument data blockchain system implements its access protocol to verify that the balancing engine has the necessary permissions. After verification, the valuation engine writes the updated operational valuation along with a timestamp and calculation record (714) via the transmission unit, including at least the third-party and non-third-party valuations, the method for calculating the non-third-party valuation, and the method for calculating the latest operational valuation and other valuations (716) to the housing instrument data blockchain. The valuation engine generates a data message (718) and transmits at least the new operational valuation along with the third-party and non-third-party valuations to a website controlled by the management entity and accessible to homeowners, investors, and EBP holders via the transmission unit (720), reporting these valuations on the website. If the homeowner and investor (or the artificial intelligence entity representing the investor) have requested an update to the operational valuation or when certain values are achieved, the valuation engine notifies the homeowner and investor (or the artificial intelligence entity representing the investor) who may be offline of the new operational valuation via the transmission unit via email or SMS message via a mobile phone or other receiving device.

[0300] Other data elements include at least implicit rent, depreciation, and property tax liabilities, which are controlled by other data engines that operate in a similar manner to the valuation engine.

[0301] You can refer to Figure 21To understand an embodiment, Figure 21 2100 is a flowchart illustrating a process for extracting contract data from a blockchain system, calculating an offer data set, and writing the offer data set to the blockchain system associated with a payment change request, according to an exemplary embodiment. A homeowner may wish to change the payment level to an investor, effectively refinancing a home financing scheme. The homeowner accesses a website operated by an administrative entity and requests a payment change, specifying one or more potential new payment levels. A message is generated, including at least the request and the potential new levels, and is sent via a transmission unit to a receiving unit of a contract engine controlled by the administrative entity (2102). The contract engine processing unit sends a query to the housing instrument data blockchain system, along with access authorization data, via the transmission unit to extract relevant underlying data for generating an offer associated with each new interest payment level for the homeowner (2104). The relevant underlying data includes at least necessary contract information and the latest value of the unplanned outcome, the latest value of the planned outcome, the latest value of the operational valuation of the home, and the latest value of parameters used to update the balance calculation for the unplanned outcome. The required contract information includes, at a minimum, the rules and algorithms required to calculate the new fixed schedule for accruing equity earned by the homeowner, and the value of any adjustment fees submitted by the homeowner associated with each potential new payment level.

[0302] The housing tool data blockchain system implements its access protocol to verify that the contract engine has permission to access the requested data. Upon verification, the contract engine receives the data via a receiving unit (2106). A processing unit associated with the contract engine uses the contract rules and algorithms to calculate offer data, including: for each new payment level offered, at least the new fixed plan accrued to the homeowner's earned equity and any adjustment fees associated with the change in payment level from the current EBP plan to the MM-0 agreement (2108). The contract engine generates an offer message (2110) containing at least the offer data and a request for a response from the homeowner (2110). The offer message is sent via a transmitting unit to a website controlled by the administrative entity and accessible to the homeowner, where the offer data is displayed (2112). The response request indicates a deadline for the homeowner to respond to the terms offered. The contract engine, via the transmitting unit, reminds the homeowner, who may be offline, of the offer and the response request, including a deadline for responding via email or SMS message via a mobile phone or other receiving device. The contract engine, via the processing unit, calculates an offer data set suitable for writing to the property utility data blockchain (2114), comprising at least: (i) offer data; (ii) base data extracted from the property utility data blockchain as a first step in the process of generating the offer; (iii) a date and time indicating the initial publication of the offer; and (iv) an indication of a specified deadline for responding to the offer. The contract engine, via the transmitting unit, transmits a query and access authorization data to the property utility data blockchain system to ensure permission to write the offer data set to the blockchain. The property utility data blockchain system implements its access protocol to verify that the contract engine has the necessary permissions. Following verification, the contract engine, via the transmitting unit, writes the offer data set to the property utility data blockchain (2116).

[0303] You can refer to Figure 22 To understand one embodiment, the flowchart (2200) illustrates the process of calculating the required allocation, executing the bank transfer, and updating the blockchain system regarding the accepted payment offers, according to an exemplary embodiment. If the homeowner wishes to accept one of the offers, the homeowner accesses a website operated by the administrative entity and indicates the homeowner's selection of the required offer, undergoes a security protocol to verify the homeowner's identity, generates a message including at least an indication of acceptance of the required selection, confirmation of identity verification, and the terms of the offer, and transmits the message to the receiving unit of the contract engine via a transmitting unit (2202). The contract engine, via the processing unit, initiates a termination process for the existing EBP scheme (2204). As a first step, the contract engine processing unit sends a query to the property tool data blockchain system, along with access authorization data, via the transmitting unit to extract the offer data set from the blockchain (2206).

[0304] The property utility data blockchain system implements its access protocol to verify that the contract engine has access to the requested data. Once verified, the contract engine receives the offer data set via the receiving unit. The offer data set includes the latest values of the variables as of the time of the offer, and in this embodiment, these values determine the implementation of the accepted offer.

[0305] In this embodiment, the termination process closes the EBP plan through the contract engine, which calculates the distribution as if the home had been sold (2208). The contract engine uses the parameter values in the offer data set to calculate the EBP holder's equity credits or debits based on a hypothetical sale in several steps. First, the contract engine compares the planned and unplanned outcome values from the offer data set. If the unplanned outcome is greater than the planned outcome, the difference is the "EBP Excess," representing the percentage of the EBP holder's share of the proceeds if the home were sold. If the planned outcome is greater than the unplanned outcome, the difference (a positive number) is the "EBP Deficit," representing the percentage of the EBP holder's equity responsibility to the homeowner. There may also be an adjustment charge, which is a percentage value representing the share of equity owed to the EBP holder by the homeowner. If there is an EBP Excess, the EBP Excess plus the Adjustment Charge equals the "EBP Equity Credit." If there is an EBP Deficit, but it is less than the Adjustment Charge, the Adjustment Charge minus the EBP Deficit equals the EBP Equity Credit. If the EBP deficit exceeds the adjustment expense, then the EBP deficit less the adjustment expense equals the "EBP Net Asset Value Debit," which is a positive number.

[0306] The new starting equity position resulting from the termination process is: (i) for the homeowner, a number of percentage points equal to the planned result from the offer data set less the adjustment fee from the offer data set; and (ii) for the investor, a number of percentage points equal to 100 less the homeowner's percentage point share. To achieve this distribution, it is necessary to settle any EBP equity credits or EBP equity debits in cash.

[0307] If an EBP equity credit exists, the contract engine, through the processing unit, calculates the buyout amount that the investor needs to pay to the EBP holder to purchase the associated equity at the operational home valuation recorded in the offer data set, thereby closing the EBP equity credit (2210). The contract engine creates an investor buyout demand message containing buyout demand data, which includes at least: (i) the percentage share of the home equity that the investor is purchasing; (ii) the operational valuation at the time of the home valuation; (iii) the buyout amount; and (iv) instructions for payment to the EBP holder. The contract engine, through the transmission unit, sends the investor buyout demand message to the receiving unit of the payment engine pre-designated by the investor (2212). The payment engine creates a bank transfer from the investor to the EBP equity holder's account (2214) and, through the transmission unit, generates a payment confirmation message (2218) and sends the payment confirmation message (2220) to the receiving unit of the contract engine, the payment confirmation message including at least data sufficient for the contract engine to confirm that the payment has been made through a process familiar to those skilled in the art. The contract engine, via the processing unit, prepares a transition data packet (2216) containing at least: (i) the EBP equity credit amount and the data and method used to calculate the amount; (ii) the fact and confirmation of the investor's payment to the EBP holder; (iii) the new starting equity position of the investor and homeowner resulting from the termination process; (iv) the fact of the termination of the existing EBP plan and the initiation of the new EBP plan or new MM-0 plan; (v) the date and time of the transition; and (vi) the specifications of the new plan, including the new fixed homeowner equity accrual schedule if the new agreement is an EBP plan, the specifications of the new plan matching the corresponding offer described in the offer data set. The contract engine, via the transmitting unit, transmits the query and access authorization data to the home instrument data blockchain system to ensure that the plan transfer is permitted and writes the transition data to the blockchain.

[0308] The housing instrument data blockchain system implements its access protocol to verify that the contract engine has the necessary permissions. After verification, the contract engine writes the transition data to the housing instrument data blockchain (2222) via the transmission unit, realizing the transition to the new plan. The contract engine develops three web-displayable versions of the transition data, one for the homeowner, one for the investor, and one for the EBP holder (2224). The contract engine, via the transmission unit, sends the three displayable versions to a website operated by the administrative entity, making each version accessible to the corresponding party: the homeowner, the investor, and the EBP holder (2226). The contract engine, via the transmission unit, notifies the homeowner, the investor (or an artificial intelligence entity representing the investor), and the EBP holder (or an artificial intelligence entity representing the EBP holder), who may be offline, of the data version appropriate to each party via email or SMS message via a mobile phone or other receiving device. The contract engine sends the transition data via the transmission unit to a website controlled by the administrative entity that is accessible to homeowners, investors, and EBP holders, along with instructions for the website to update general access areas and restricted access areas of the website to display the new plan based on the details of the new plan encoded in the transition data.

[0309] If there is an EBP equity debit, then the contract engine, through the processing unit, calculates the buyout amount that the EBP holder will need to pay to the investor, purchases the relevant equity from the investor using the operational home valuation recorded in the offer data set, and transfers it to the homeowner (2210). The contract engine creates an EBP buyout request message containing buyout request data, which includes at least: (i) the percentage share of the home equity that the EBP holder is purchasing; (ii) the operational valuation at the time the home was valued; (iii) the buyout amount; and (iv) instructions for payment to the investor. The contract engine, through the transmission unit, sends the EBP buyout request message to the receiving unit of the payment engine pre-designated by the EBP holder (2212). The payment engine creates a bank transfer from the EBP holder to the investor's account (2214), generates a payment confirmation message (2218), and then sends a payment confirmation message (2220) to the receiving unit of the contract engine via the transmission unit, the payment confirmation message including at least data sufficient for the contract engine to confirm that the payment has been made through a process familiar to those skilled in the art. The contract engine, via the processing unit, prepares a transition data packet (2216) containing at least: (i) the EBP equity debit amount and the data and method used to calculate the amount; (ii) the fact and confirmation of the payment from the EBP holder to the investor; (iii) the new equity position of the investor and homeowner resulting from the termination process; (iv) the fact that the existing EBP plan is terminated and a new EBP plan or a new MM-0 plan is initiated; (v) the date and time of the transition; and (vi) the specifications of the new plan, including the new fixed homeowner earned equity accrual schedule if the new plan is an EBP plan, the specifications of the new plan matching the corresponding offer described in the offer data set. The contract engine, via the transmitting unit, transmits the query and access authorization data to the home instrument data blockchain system to ensure that the plan transfer is allowed and to write the transition data to the blockchain.

[0310] The housing instrument data blockchain system implements its access protocol to verify that the contract engine has the necessary permissions. After verification, the contract engine writes the transition data to the housing instrument data blockchain (2222) via the transmission unit, thus achieving the transition to the new plan. The contract engine creates three web-displayable versions of the transition data, one for the homeowner, one for the investor, and one for the EBP holder. The contract engine sends the three displayable versions to a website operated by the management entity via the transmission unit, making each version accessible to the corresponding party: the homeowner, the investor, and the EBP holder (2224). The contract engine notifies the homeowner, the investor (or an artificial intelligence entity representing the investor), and the EBP holder (or an artificial intelligence entity representing the EBP holder), who may be offline, of the data on the version appropriate for each party (2226) via the transmission unit via email or SMS message via a mobile phone or other receiving device. The contract engine sends the transition data via the transmission unit to a website controlled by the administrative entity that is accessible to homeowners, investors, and EBP holders, along with instructions for the website to update general access areas and restricted access areas of the website to display the new plan based on the details of the new plan encoded in the transition data.

[0311] In one or more embodiments, a similar process involving the termination of an existing EBP program and an appropriate transition agreement between the three parties (the homeowner, the investor, and the EBP holder) may be used to implement a homeowner-initiated change, rather than modifying the homeowner's payment level to the investor, including at least: (i) purchasing equity from the investor; (ii) selling equity to the investor; (iii) refinancing the EBP program by terminating the old program and the associated fixed schedule for homeowner earned equity accruals to a new EBP program on market terms that includes a new and different fixed schedule for homeowner earned equity accruals; or (iv) refinancing the EBP agreement by terminating the old program and the associated fixed schedule for homeowner earned equity accruals to support an MM-0 home financing program in which the schedule for homeowner earned equity accruals is not fixed but is equal to the non-planned outcome under the EBP program. In one embodiment, these changes would require the same steps of terminating the existing EBP program, adjusting the equity shares as if selling a home, and then conducting a cash transaction to close the equity credits or debits held by the EBP holder, thereby creating corresponding equity adjustments for the investor and homeowner. The equity shares that the homeowner and investor receive from this process will become the baseline equity shares for the new EBP or MM-0 program, which replaces the existing EBP program.

[0312] The embodiment of the EBP home program just described illustrates that, even in the case of non-neutral home financing, the computer technology comprising the present invention enables the homeowner to access a single website and a variety of GUI-based pages to perform a wide range of functions in a low-cost and nearly instantaneous manner, including at least: (i) monitoring the level of earned equity and viewing the fixed schedule governing the future accrual of earned equity; (ii) monitoring parameters such as home valuation in real time; (iii) inquiring about and viewing the terms and consequences of changing the level of payments to investors; (iv) effecting such changes when necessary; and (v) inquiring about and viewing the terms and consequences of other changes, including at least: (a) purchasing equity from investors; (b) (c) refinancing the EBP agreement by terminating the old agreement and the associated fixed schedule for homeowner earned equity accrual in favor of a new EBP agreement on market terms that includes a new and different fixed schedule for homeowner earned equity accrual; or (d) refinancing the EBP agreement by terminating the old schedule and the associated fixed schedule for homeowner earned equity accrual in favor of an MM-0 home financing option in which the schedule for homeowner earned equity accrual is not fixed but is instead equal to the unplanned outcome under the EBP option; and (vi) implementing any such changes, if necessary. The embodiments illustrate how computer technology, including the present invention, facilitates complex interactions involving at least one third party (in the specific embodiment above, the EBP holder) as well as homeowners and investors in a manner that enables a low-cost integrated presentation on a single website. The present invention implements a web page presentation for homeowners that is parallel to the presentation scope on the investment services website, where complex auxiliary functions involving third parties operate "behind the scenes." The present invention is implemented similarly to its implementation in the MM-0 and MM-1 scenarios, even though the EBP scenario is not neutral, nor is it a direct scenario where the balancing mechanism directly creates a distribution between the homeowner, the investor, and third parties participating in the housing scenario. It will be apparent to those skilled in the art that the computer technology, including the present invention, can be used to achieve the same results for a variety of other housing scenarios that are not direct and may be non-neutral.

[0313] Transactions between investors

[0314] In one embodiment, title to the subject housing is held by the homeowner, by a partnership, or in some other manner where the investor does not have ownership but rather a contractual position. In this embodiment, contractual rights can be set up so that investors can buy, sell, and exchange their positions with one another without transferring the property itself. In addition to the simple transfer of investor interests, this capability also allows certain portfolio settlement transactions between portfolio funds of investors to be more easily conducted. Regardless of whether the investors are portfolio funds or not, the computer technology comprising the present invention is able to implement low-cost and efficient transfers between investors without requiring substantial participation from the homeowner, who is not interrupted when accessing a single website and multiple GUI-based pages provided by the computer technology comprising the present invention, so that the homeowner can engage in a wide range of monitoring and behavioral functions in a low-cost and nearly instant manner.

[0315] Investor trading platform

[0316] To describe an embodiment of how the present invention implements an investor trading platform, we limit the possible home financing options for each home to MM-0 home financing options, in which there is only one homeowner and one investor, each holding an unleveraged equity interest, and no third party participation in the form of a mortgage or other form of interest. The present innovation includes one or more embodiments in which the investor trading platform is used to operate home financing options other than MM-0 options, and for which there are multiple homeowners per home, multiple investors per home, or third parties holding interests such as mortgages or EBPs.

[0317] In one embodiment, data describing a home and an applicable DOOR instrument housing solution is located in a housing tool data blockchain. This data includes at least: (i) characteristics of each home, including at least the address and a systematic description of the home's physical attributes suitable for real estate listing; (ii) the current contract terms of the DOOR instrument housing solution and the current value of a certain amount of elements governing at least the level of payments made by the homeowner to the investor; (iii) the current operating valuation of the home, the current operating estimated rental rate, and the current operating valuations of all other parameters that serve as inputs to a balancing mechanism that implements the DOOR instrument housing solution applicable to the home; (iv) the investor's current equity interest in the home; (v) a complete history of the evolution of the value and equity interest of the DOOR instrument housing solution; (vi) whether the investor is currently selling some or all of the investor's shares, in which case there is an "active sell offer"; and (vii) if there is no active sell offer, whether the investor is open to an unsolicited offer to purchase some or all of the investor's equity, in which case the investor's equity is "open for bid."

[0318] In this embodiment, the subject housing is held by the homeowner, a partnership, or in some other manner where the investor does not have ownership but has a contractual position. Contractual rights are established in the DOOR instrument home financing scheme so that investors can buy, sell, and exchange positions with each other without transferring the property itself. All DOOR instrument home financing schemes are MM-0 compatible.

[0319] The investor trading website operated by the Management Entity allows approved existing investors and pre-approved potential investors (collectively, "Approved Investors") to participate in offers to purchase or sell investor equity in DOOR instrument home financing solutions through the trading platform and, upon acceptance of the offer, complete the purchase or sale. The trading platform portion of the website and the ability to conduct transactions thereon are accessible only to Approved Investors who have been accepted and whose approval status is current, following a process familiar to those skilled in the art, which may involve both online and offline steps, the results and status of which are recorded in the home instrument data blockchain. Approved Investors access the trading platform on the website via a password or other protocol familiar to those skilled in the art. The trading platform provides access to the listings section of the website, which displays active sales offers for investor equity and detailed information about investor shares that the investor is interested in purchasing. The listings section is organized and presented similarly to a real estate listing website. If an Approved Investor is interested in a particular investor share, the trading platform facilitates online and offline communications between the Approved Investor and investors who are actively offering investment shares or are open to offers to purchase.

[0320] You can refer to Figure 24 To understand an embodiment, Figure 24 2400 is a flow chart illustrating a purchase offer process and updates to the blockchain system associated with an accepted purchase offer according to an exemplary embodiment. If an approved investor and an investor holding investor shares in a DOOR instrument (the "target investor" of the offer) reach an agreement in principle to complete the transaction, the approved investor enters the transaction platform website, identifies the investor shares of interest, and specifies the terms of the offer using an electronic form provided by the website on one or more GUI-based pages. The website sends a purchase offer message (2402) to a receiving unit of a transaction engine 118 operated by an administrative entity via a transmitting unit. Figure 23 Understand the embodiment of the transaction engine as it is Figure 1An exemplary embodiment of the trading engine 188 includes a receiving unit 2302 for receiving data via one or more networks, a transmitting unit 2304 for transmitting data via one or more networks, a processing unit 2306 having a computer architecture for executing exemplary embodiments, and a database 2308 for storing data. The purchase offer message at least: (i) identifies the investor's equity shares; (ii) specifies the terms of the purchase offer and a deadline for acceptance of the offer; and (iii) includes security information suitable for identifying the approved investor as the sender of the message. The trading engine, via the transmitting unit, sends a query to the housing instrument data blockchain system along with access authorization data to extract data related to the purchase offer message, the purchase offer message including at least data related to determining the investor's equity shares held by the investor, whether the shares are subject to an active sell offer or are open to an offer to buy, and the identity and approval status of the approved investor to send the purchase offer message (2404).

[0321] The property instrument data blockchain system implements its access protocol to determine whether the transaction engine can access the requested data. After verifying access rights, the transaction engine receives the relevant data from the property instrument data blockchain via a receiving unit. A processing unit associated with the transaction engine checks the approval status of the approved investor and matches the target investor with the investor's equity shares. If the approval status is current, the transaction engine sends a purchase offer notification (2406) to the target investor's receiving unit via a transmitting unit, containing purchase offer data including at least: (i) the identity and approval status of the approved investor making the offer; (ii) the terms of the offer; (iii) the deadline for accepting the offer, after which the offer expires; and (iv) a method for accepting or rejecting the offer by communicating the offer or rejection to the transaction engine's receiving unit. The transaction engine, via the transmitting unit, alerts the target investor (or an artificial intelligence entity representing the investor), who may be offline, of the purchase offer and purchase offer data via email or SMS message to a mobile phone or other receiving device. If the transaction engine receives a message through the receiving unit that the target investor has rejected the offer (2414), the transaction engine generates a rejection notice (2416), and sends the rejection notice to the receiving unit of the approved investor who made the offer (2418) through the transmitting unit, and notifies the approved investor, who may be offline, of the rejection via an email or SMS message via a mobile phone or other receiving device. If the offer expires due to the target investor not accepting the offer before the deadline (2408), the transaction engine generates an offer expiration notice (2410), and sends the offer expiration notice to the receiving unit of the approved investor who made the offer and the receiving unit of the target investor via the transmitting unit (2412), and also notifies the parties involved, who may be offline, via an email or SMS message via a mobile phone or other receiving device.

[0322] If the trading engine receives a message (2414) via the receiving unit that the target investor has accepted the offer, the trading engine then sends an acceptance notification to the receiving unit of the approved investor who made the offer via the transmitting unit, and notifies the approved investor, who may be offline, via email or SMS message via a mobile phone or other receiving device. The trading engine, via the processing unit, prepares a set of necessary closing documents (2420), customized for the specific approved investor, the specific target investor, and the specific investor's shares. The trading engine, via the transmitting unit, makes these forms accessible on the trading platform website, and access is limited to the investors who are buying and selling via a password protocol or other means familiar to those skilled in the art. The trading engine sends an execution procedure notification to the receiving units of the buying and selling investors via the transmitting engine, and notifies both investors, who may be offline, via email or SMS message via a mobile phone or other receiving device that the closing documents need to be completed online and the required payment plan needs to be made. After the transaction parties complete the documents online and the transaction engine, through its processing unit, verifies all aspects of the transaction and verifies the payment (2422), the transaction engine creates and organizes a transaction data package in a format suitable for writing to the property instrument data blockchain (2424). The transaction data package contains at least: (i) the transaction parties; (ii) the transaction terms; (iii) the transaction effective date and time; and (iv) a complete set of delivery documents. The transaction engine transmits a query and access authorization data to the property instrument data blockchain system through the transmission unit to ensure permission to write the transaction data package to the blockchain.

[0323] The housing instrument data blockchain system implements its access protocol to verify that the contract engine has the necessary permissions. After receiving the verification confirmation via the receiving unit, the transaction engine writes the transaction data packet to the blockchain (2426) via the transmitting unit, creating a transaction record on the blockchain and executing the transfer. The transaction engine generates a transaction message (2428) and sends the relevant portion of the transaction data packet and a notification of transaction completion to a portion of the trading platform website accessible only to the buying and selling investors (2430) via the transmitting unit. The transaction engine notifies the buying and selling investors, who may be offline, via email or SMS messages sent to mobile phones or other receiving devices that the transaction has been completed and that the relevant completion data is available on the trading platform website, along with instructions for accessing the portion of the website where the data is located.

[0324] The embodiment of the investor buying and selling platform just described illustrates that the computer technology created by the present invention allows investors to transact with respect to their shares in a DOOR-based home financing solution entirely within the context of the homeowner. Homeowners can access a single website and multiple GUI-based pages to participate in a wide range of monitoring and behavioral functions, at low cost and almost instantaneously, enabled by the computer technology encompassing the present invention. Homeowners do not even have to switch websites to make payments or receive information, for example, in some cases, where mortgagee equity is transferred from one mortgagee to another, in accordance with existing technology.

[0325] Coordinate investor transactions through combined settlement

[0326] In one embodiment, a management entity operates as an investor in one or more real estate portfolios whose objectives or goals include, at least, replicating as closely as possible a municipal, regional, or national housing index. Closing such portfolios requires the management entity, as an investor, to engage in buying and selling activities to keep the portfolios consistent with the objectives in the face of portfolio turnover, which includes, at least, home sales, accrual of equity earned by homeowners, purchases of investor equity by homeowners, or sales of equity earned by homeowners to investors pursuant to the terms of a home financing arrangement.

[0327] The several DOOR instruments that embody home financing solutions described thus far create for investors a position equivalent to an MM-0 home financing solution, where the position consists of unleveraged equity that earns a raw return on the owner-occupied home, equal to the home's appreciation plus imputed rent after expenses. While these "MM-0 investment-compatible instruments" may differ in their treatment of third parties or homeowners, they are all suitable for inclusion in portfolios designed to track or create housing indices. Therefore, these portfolios have MM-0 investment-compatible instruments available for inclusion, not just instruments that directly implement the MM-0 solution. For example, the DOOR instrument implementation of the EBP solution described above includes an MM-0 investment-compatible instrument, and because of this property, the investor's outcome is the same as under the MM-0 solution.

[0328] In one embodiment, by directly modifying the investor trading platform to at least limit its scope to MM-0 home financing options and simplifying the buying and selling steps based on the joint management of different portfolio funds, it is possible to facilitate the combined settlement purchases and sales between home index portfolio funds in a manner that does not require substantial participation by the homeowner. Therefore, when the computer technology embodying the present invention provides access to a single website and multiple GUI-based pages, there will be no interruption, allowing homeowners to participate in a wide range of monitoring and behavioral functions in a low-cost and nearly instant manner. As mentioned above, the facilitation of combined settlement purchases and sales is particularly valuable for portfolio funds represented in the form of cryptocurrency.

[0329] Integration of buying, creating, and selling elements

[0330] The above embodiments describe how computer technology, including the present invention, enables homeowners and other interested parties to access a single website and a variety of GUI-based pages to engage in a wide range of functions at low cost and almost instantaneously. The various embodiments demonstrate how computer technology, including the present invention, facilitates complex interactions involving third parties with each other and with homeowners and investors, while continuing to support a low-cost, integrated presentation on a single website. The present invention implements a web page presentation for homeowners that parallels the broad applicability of that presentation with functionality on an investment services website, where many complex ancillary tasks involving third parties are performed invisibly and without interrupting the user's use of the website's functionality.

[0331] Most of the above-described embodiments relate to functionality during ownership, such as changing the terms of the underlying home financing agreement or the positions of the parties involved. In one or more embodiments, many purchasing, origination, and selling elements can also be integrated into a single website. These integrated elements include at least: (i) online application by the homeowner for a DOOR instrument home financing program; (ii) underwriting and credit analysis associated with the application; (iii) consumer education and disclosure regarding the home financing program; (iv) issuance of documents, including closing documents; (v) escrow services; (vi) closing functions; (vii) management of functions that cannot be performed online through communication with the relevant parties; and (viii) recording transactions and archiving related documents on one or more blockchains, including at least one home instrument data blockchain. Certain investors, including at least one or more cryptocurrency-based home portfolios operated by a management entity, can offer homes on the market in conjunction with DOOR instrument home financing and can also place orders with homeowners currently enrolled in DOOR instrument home financing programs who wish to sell their homes. These "in-system" sales and purchases conducted through a single website create further opportunities for reducing sales and procurement costs and streamlining required tasks.

[0332] Exemplary embodiments

[0333] According to this embodiment, a computer technology system for real-time, dynamic management of real estate financing, servicing, and reporting includes:

[0334] Maintaining a display of the terms, parameter values, and actions to be taken under the home financing program on a website controlled by the managing entity and accessible to at least homeowners and investors;

[0335] storing in at least one blockchain system comprising at least one housing instrument data blockchain, the system comprising at least: contract information specifying at least one housing financing arrangement between at least one homeowner and at least one investor financing a particular housing unit, a time series of economic parameters relevant to the dynamic management of the at least one housing financing arrangement, a record of current and past ownership of the financing debt or equity, a record of transactions comprising at least payments from the homeowner to the investor, a record of any adjustments or changes to the housing financing arrangement, specifications for at least one balancing mechanism designed to track the net contributions of at least the homeowner and the investor and treat the housing financing arrangement between them as a joint venture and to adjust at least one residual account to reflect the net contributions of each party, a record of data and calculations of a balancing engine that operates continuously based on the one or more balancing mechanisms and resulting adjustments to the at least one residual account, an access protocol defining various levels of access to data in the blockchain system and levels of authority to write new data to the blockchain system, and data describing the housing unit involved in the housing financing arrangement;

[0336] maintaining a balancing engine embodied in at least one processing unit, at least one receiving unit, and at least one transmitting unit on at least one processing server controlled by the management entity to implement adjustments under the balancing mechanism;

[0337] Periodically receiving messages from the management entity or an artificial intelligence entity representing it through the receiving unit of the balancing engine to initiate a balancing entry on the housing tool data blockchain; querying the blockchain system for data related to the balance calculation through the transmitting unit of the balancing engine; and receiving the data through the receiving unit of the balancing engine;

[0338] In a direct approach, the processing unit of the balancing engine determines an updated balance in at least one remaining account; the transmitting unit of the balancing engine writes the updated remaining account balance and details of the calculation to the property instrument data blockchain; the processing unit and the transmitting unit of the balancing engine modify at least a website accessible to the homeowner and investor to display the updated remaining account balance; and the transmitting unit of the balancing engine then notifies at least one homeowner and investor, who may be offline, of the updated remaining account balance via a mobile phone or other receiving device.

[0339] Alternatively, in a non-direct scenario, determining, by the processing unit of the balancing engine, an updated unscheduled outcome and associated quantities using the unscheduled outcome as input; writing, by the transmission unit of the balancing engine, the updated unscheduled outcome and associated quantities and details of the calculation to the housing instrument data blockchain; modifying, by the processing unit and transmission unit of the balancing engine, a website accessible to at least the homeowner, investor, and remaining balance position holder to display the updated unscheduled outcome and associated quantities; and then, notifying, by the transmission unit of the balancing engine, at least one homeowner, investor, and remaining balance position holder who may be offline of the updated unscheduled outcome and associated quantities via a mobile phone or other receiving device.

[0340] maintaining, on at least one processing server controlled by the management entity, at least one data engine embodied in at least one processing unit, at least one receiving unit, at least one transmitting unit, and at least one database to create, aggregate, update, process, store, and communicate at least one time series of at least one data parameter;

[0341] At a receiving unit of at least one data engine, third-party data is received, the third-party data comprising input data for calculating at least one data parameter generated by the data engine; the added data is formatted by a processing unit of the data engine, and then a database is modified by the same processing unit of the data engine to incorporate the added data; if desired, at least one non-third-party version of the data parameter is calculated by the processing unit of the data engine; a single operational estimate of the data parameter is calculated by the processing unit of the data engine using the third-party and non-third-party estimates; and the updated estimate of the data parameter is transmitted by the transmitting unit of the data engine to the receiving unit. writing the operational valuation along with a record of the calculation, the record including at least a time and date stamp of the calculation, the third-party and non-third-party values, and a method for calculating the operational valuation on the property instrument data blockchain; modifying, via the processing unit and the transmission unit of the data engine, a website accessible by at least the homeowner and investor to display the updated operational valuation for the data parameters, and then, via the transmission unit of the data engine, notifying at least one of the homeowner and investor, who may be offline, of the updated operational valuation via a mobile phone or other receiving device if either party generally requests an update to the operational valuation or when certain values of the data parameters are implemented;

[0342] maintaining, on at least one processing server controlled by the management entity, at least one third-party data engine embodied in at least one processing unit, at least one receiving unit, at least one transmitting unit, and at least one database for creating, aggregating, updating, processing, storing, and communicating at least one time series of at least one data parameter generated from at least one third-party financing scheme;

[0343] receiving data related to at least one third-party financing scheme at a receiving unit of at least one third-party data engine running on a processing server controlled by the administrative entity; identifying, by the processing unit of the third-party data engine, elements of the data that need to be recorded on the house instrument data blockchain; and modifying the data to be recorded into a suitable format; writing, by the transmitting unit of the third-party data engine, a record of the required data elements and any related calculations on the house instrument data blockchain; extracting, by the receiving unit of the third-party data engine, data that adequately describes the current status and relevant history of the third-party financing scheme from the house instrument data blockchain; organizing, by the processing unit of the third-party data engine, the data into a form suitable for display on a website; modifying, by the processing unit and transmitting unit of the third-party data engine, a website accessible to at least one homeowner and investor to display the updated data for the third-party financing scheme; and then, by the transmitting unit of the third-party data engine, notifying at least one homeowner and investor, who may be offline, of the updated data via a mobile phone or other receiving device if either party requests such updated data generally or when certain values of certain data parameters are achieved;

[0344] Maintaining, on at least one processing server controlled by the management entity, a contract engine embodied in at least one processing unit, at least one receiving unit, and at least one transmitting unit to initiate, implement, execute, and update said home financing arrangement between at least a homeowner and an investor;

[0345] The contract engine receives initial contract data describing a housing financing plan through a receiving unit of the contract engine running on a processing server controlled by the management entity; the processing unit confirms elements of the initial contract data that need to be recorded on the housing instrument data blockchain; the processing unit of the contract engine organizes and modifies the data to be recorded into a suitable format; and the transmission unit of the contract engine writes necessary data elements on the housing instrument data blockchain;

[0346] receiving, on a website or other input device controlled by the management entity, a request from the homeowner to change at least one term in a housing financing plan, the at least one term specifying at least one option for the new term; transmitting, via a transmitting unit of a server controlled by the management entity, the request to a receiving unit of a contract engine operated by a processing unit controlled by the management entity;

[0347] In the case of a direct solution, the necessary contract provisions are extracted from the housing instrument data blockchain by the receiving unit of the contract engine to manage the requested term changes and other relevant data for each option; the processing unit of the contract engine is used to determine whether the housing financing solution contract allows the requested term changes for each option, and if so, whether any approval of parties other than the homeowner is required; if the term changes for at least one option are allowed in other cases, the transmission unit of the contract engine is used to remind at least one relevant party through at least one receiving device of at least one relevant party that it needs to agree or deny approval for each option requiring approval to seek any required approval for each option; after receiving a response or after a deadline for a response has passed, the processing unit of the contract engine is used to determine whether each option proposed by the homeowner is approved or denied; the transmission unit of the contract engine is used to modify the website accessible to the homeowner to notify the homeowner whether each option is authorized or denied, and after at least one option is authorized In this case, the homeowner is requested to confirm that he accepts one of the options or rejects all the options; and then, through the transmission unit of the data engine, at least one of the homeowners who may be in an offline state is reminded of the options that have been authorized or rejected through a mobile phone or other receiving device. If at least one option is authorized, one option needs to be confirmed or all options need to be rejected; if the homeowner confirms the option, the transmission unit of the contract engine writes the relevant data of the accepted option including at least the changes to the terms and the effective date and time of the changes to the terms into the housing instrument data blockchain; through the processing unit and transmission unit of the contract engine, at least a website accessible to the homeowner and the investor is modified to confirm that the changes have taken effect, to display the effective time and date of the changes, and to display the new housing financing plan terms; and then, through the transmission unit of the contract engine, at least one of the homeowners and the investor who may be in an offline state is reminded that the changes have taken effect and the effective time and date of the changes through a mobile phone or other receiving device;

[0348] Alternatively, in an indirect approach, the receiving unit of the third-party data engine extracts necessary contract provisions from the housing instrument data blockchain, the provisions governing the requested term changes and other relevant data, including at least data sufficient to generate an offer to the homeowner for each option, the offer including a term change of the housing financing option that is different from the requested term; the processing unit of the contract engine calculates at least one offer for each term change option specified by the homeowner; the transmitting unit of the contract engine modifies a website accessible to the homeowner to notify the homeowner of the offers and request the homeowner to confirm acceptance of one of the offers or to confirm rejection of all of the offers; and then, The transmission unit of the contract engine reminds at least one homeowner who may be offline of the offer and the need to accept one or reject all of them through a mobile phone or other receiving device; creates an offer data set through the processing unit of the contract engine, the offer data set at least including the content of the offer and the value of the governing data parameter at the time of the offer, and the value of the governing offer terms; writes the offer data set into the house tool data blockchain through the transmission unit of the contract engine; if the homeowner accepts the offer, extracts the offer data set from the house tool data blockchain through the receiving unit of the contract engine; calculates the required terms using the offer data set through the processing unit of the contract engine. the steps required to complete the existing home financing plan and replace it with a new one embodying the terms specified in the accepted offer; transmitting a message through the transmitting unit of the contract engine notifying the parties of the required steps; receiving verification through the receiving unit of the contract engine that the required steps have been completed, including any payments requested between the parties; compiling a transition data packet through the processing unit of the contract engine, wherein the transition data packet includes at least the adjustments made to close the existing home financing plan, the terms of the new home financing plan and the starting remaining account positions of the parties, and the date and time when the new plan takes effect; The transmission unit of the engine writes the transition data to the housing instrument data blockchain, thereby realizing the transition to the new housing financing plan; the processing unit of the contract engine creates a separate displayable version of the transition data suitable for each relevant party; the processing unit and the transmission unit of the contract engine modify the website accessible to the relevant parties to display the transition data in a separate version to each separate party on a separate part of the website and display the new plan in a commonly accessible area of the website; and the transmission unit of the contract engine reminds each relevant party who may be offline of the transition data related to the party and the public data describing the new housing financing plan;

[0349] Receiving a request from a homeowner to sell remaining account positions to at least one investor or to purchase remaining account positions from at least one investor on a website or other input device controlled by the management entity; transmitting the sale or purchase request via a transmitting unit of a server controlled by the management entity to a receiving unit of a contract engine executed by a processing unit controlled by the management entity;

[0350] In the case of a direct solution, the necessary contractual provisions and other relevant data governing the requested sale or purchase, including at least data required to determine the terms of the sale or purchase, are extracted from the housing instrument data blockchain by the receiving unit of the contract engine; the processing unit of the contract engine determines whether the housing financing solution contract permits the requested sale or purchase; and if so, determines whether approval of the investor on the other side of the transaction is required; the processing unit of the contract engine determines the applicable terms of the purchase or sale; if the sale or purchase is otherwise permitted, the investors are reminded of the terms and the need for approval or rejection of approval based on the calculated terms through at least one receiving device of each of the investors, and the approval of the investors, if required, is sought through the transmitting unit of the contract engine; after receiving a response or after a deadline for a response has passed, the processing unit of the contract engine determines whether the sale or purchase based on the calculated terms is authorized or rejected; the transmitting unit of the contract engine modifies the website accessible to the homeowner to notify the homeowner of the authorization or rejection and, in the case of authorization, requests the homeowner to confirm acceptance or rejection based on the calculated terms; and then, the transmitting unit of the contract engine transmits the homeowner's consent to the transaction via a mobile the mobile phone or other receiving device to remind the homeowner, who may be offline, of the authorization or rejection; and, in the case of authorization, requesting the homeowner to confirm acceptance or rejection of the transaction based on the calculated terms; if the homeowner confirms the transaction, a message is transmitted through the transmission unit of the contract engine, which notifies the relevant party or parties of the requested step; the step of receiving the request includes verification that any payment required between the two parties has been completed through the receiving unit of the contract engine; the processing unit of the contract engine compiles a transaction data packet, the transaction data packet including at least the confirmation of the transaction, the terms of the transaction, the date and time when the transaction takes effect, and the new remaining account positions of the parties at that date and time; the transmission unit of the contract engine writes the transaction data to the property instrument data blockchain after being appropriately formatted by the processing unit of the contract engine; the processing unit and transmission unit of the contract engine modify at least a website accessible to homeowners and investors to display the relevant portion of the transaction data; and then, the transmission unit of the contract engine reminds at least one homeowner and investor, who may be offline, of the relevant portion of the transaction data via the mobile phone or other receiving device;

[0351] Alternatively, in an indirect solution, the receiving unit of the third-party data engine extracts from the housing instrument data blockchain necessary contractual provisions and other relevant data governing the requested sale or purchase, including at least data sufficient to generate an offer to the homeowner in connection with the proposed sale or purchase, including each offer to change the terms of the housing financing solution accompanying the proposed sale or purchase; the processing unit of the contract engine calculates at least one offer for sale or purchase proposed by the homeowner; the processing unit of the contract engine determines whether the housing financing solution contract permits the requested sale or purchase; and if so, determines whether approval of the investor on the other side of the transaction is required; and the processing unit of the contract engine processes the transaction. the processing unit of the contract engine determining the applicable terms of the purchase or sale and the terms of each offer; if the sale or purchase is otherwise permitted, alerting the investors, via at least one receiving device of each of the investors, of the offers and the need to approve or deny approval of each offer, according to the calculated terms, seeking approval from the investors, if required, for each offer, via the transmission unit; determining, via the processing unit of the contract engine, whether each offer is authorized or denied after a response is received or after a deadline for responding has passed; modifying, via the transmission unit of the contract engine, a website accessible to the homeowner to notify the homeowner of the authorization or denial of each offer; and in the event of authorization of at least one offer , requesting the homeowner to confirm acceptance of an offer and sales or purchase terms, or reject all offers; and then, through the transmission unit of the contract engine, reminding the homeowner who may be offline of the authorization or rejection of each offer through a mobile phone or other receiving device; and, in the case of authorizing at least one offer, requesting the homeowner to confirm acceptance of an offer and the sales or purchase terms, or reject all offers; creating an offer data set through the processing unit of the contract engine, the offer data set including at least the content of the offer, sales or purchase terms, and the value of the control data parameter at the time of the offer, which governs the value of the offer terms; through the transmission unit of the contract engine, writing the offer data set to the house instrument data blockchain; if the homeowner accepts the offer and the sale or purchase terms, extracting the offer data set from the house instrument data blockchain via the receiving unit of the contract engine; using the offer data set, via the processing unit of the contract engine, calculating the required adjustments among at least the homeowner, the investor, and the remaining balance position holder to close the existing house financing plan and replace it with a new one containing the terms specified in the accepted offer; transmitting a message, via the transmitting unit of the contract engine, notifying the relevant parties of the required steps; receiving, via the receiving unit of the contract engine, verification that the required steps, including any required payments between the parties, have been completed;The contract engine's processing unit compiles a transition data package, which includes at least the adjustments to close the existing home financing plan, the terms of the sale or purchase, the terms of the new home financing plan, and the starting remaining account positions of the multiple parties, as well as the date and time when the new plan takes effect; the contract engine's delivery unit writes the transition data to the home instrument data blockchain to implement the transition to the new home financing plan; the contract engine's processing unit creates a separate displayable version of the transition data for each relevant party; the contract engine's processing unit and delivery unit modify a website accessible to the relevant parties to display the transition data in a separate version for each separate party on a separate portion of the website and to display the new plan in a commonly accessible area of the website; and the contract engine's delivery unit then issues a reminder to each relevant party, who may be offline, of the transition data and public data describing the new home financing plan.

[0352] Computing System

[0353] Figure 25 is a block diagram of a computing system that can be used to implement certain features of some embodiments. The computing system can be a server computer, a client computer, a personal computer (PC), a user device, a tablet computer, a laptop computer, a personal digital assistant (PDA), a cellular phone, an iPhone, an iPad, a Blackberry, a processor, a phone, a web application, a network router, a switch or bridge, a console, a handheld console, a (handheld) gaming device, a music player, any portable, transportable, handheld device, a wearable device, or any machine capable of executing a set of instructions (sequential or otherwise) that specify an action to be performed by the machine.

[0354] The computing system (2500) may include one or more central processing units ("processors") (2505), memory (2510), input / output devices (2525) (e.g., keyboards and pointing devices, touch devices, or display devices), storage devices (2520) (e.g., disk drives), and network adapters (2530) (e.g., network interfaces), which are connected to an interconnect (2515). The interconnect (2515) is shown as an abstract concept representing any one or more separate physical buses, point-to-point connections, or both, connected by suitable bridges, adapters, or controllers. Thus, the interconnect (2515) may include, for example, a system bus, a peripheral component interconnect (PCI) bus or PCI Express bus, a HyperTransport or Industry Standard Architecture (ISA) bus, a small computer system interface (SCSI) bus, a universal serial bus (USB), an IIC (I2C) bus, or an Institute of Electrical and Electronics Engineers (IEEE) standard 1394 bus, also known as Firewire.

[0355] The memory (2510) and storage device (2520) are computer-readable storage media that can store instructions for implementing at least a portion of various embodiments. In addition, data structures and message structures can be stored or transmitted via data transmission media (e.g., signals on a communication link). Various communication links can be used, such as the Internet, a local area network, a wide area network, or a point-to-point dial-up connection. Therefore, computer-readable media can include computer-readable storage media (e.g., non-transitory media) and computer-readable transmission media.

[0356] The instructions stored in the memory (2510) may be implemented as software and / or firmware to program the processor (2505) to perform the above-described actions. In some embodiments, the software or firmware is initially provided to the processing system (2500) by downloading it from a remote system such as a network adapter (2530) through the computing system (2500).

[0357] Various embodiments described herein may be implemented, for example, using programmable circuitry, such as one or more microprocessors, programmed with software and / or firmware, or entirely in dedicated hard-wired (non-programmable) circuitry, or a combination of these. The dedicated hard-wired circuitry may be in the form of, for example, one or more ASICs, PLDs, FPGAs, etc.

[0358] Although various exemplary embodiments of the disclosed systems and methods have been described above, it should be understood that they are presented for illustrative purposes only and are not intended to be limiting. They are not intended to be exhaustive or limited to the precise forms disclosed. Modifications and variations may be made in light of the above teachings or from practice of the present disclosure without departing from the breadth or scope of the present technology. Therefore, the present invention should be limited only by the claims included below.

Claims

1. A computer-implemented method for real-time, dynamic management of real estate financing, servicing, and reporting, comprising: providing an application layer for maintaining an interface with a processor of a management entity, with at least homeowners and investors, and with at least one blockchain system, wherein any communication between any entity controlled by the management entity and any of the homeowners or investors, or any communication between any entity and the blockchain system, is conducted through the application layer; maintaining, by the processor, a display of terms, parameter values, and actions to be taken under a home financing program on a website controlled by the administrative entity and accessible to the homeowner and the investor; storing, by the processor, at least a blockchain of house instrument data in the blockchain system; maintaining, by the processor, on at least one server controlled by the management entity, a balancing engine embodied in at least one processing unit, at least one receiving unit, and at least one transmitting unit to implement adjustments under a balancing mechanism; periodically receiving, via a receiving unit of the balancing engine, a message from the management entity or an artificial intelligence entity acting on its behalf, the message initiating a balance entry stored by the processor on the housing instrument data blockchain; querying the blockchain system, via a transmission unit of the balancing engine, for data related to a balancing calculation, the data related to the balancing calculation including contributions and data of a governing algorithm for calculating earned equity under a contract covering a housing finance solution, the balancing mechanism being based on a purchase parity accumulation algorithm, the balancing engine converting a homeowner's net contribution in each period into an appropriate increase in earned equity under the balancing mechanism; receiving the data through a receiving unit of the balancing engine; When in the direct scenario, determining, by the processing unit of the balancing engine, an updated balance in at least one remaining account; Writing the updated remaining account balance and the calculated details to the housing instrument data blockchain via the transmission unit of the balancing engine; modifying, by the processing unit and the transmission unit of the balancing engine, a website accessible to at least the homeowner and the investor to display the updated remaining account balance; and Notifying at least one offline homeowner and investor of the updated remaining account balance via a mobile phone or other receiving device via a transmitting unit of the balancing engine; and When in a non-direct scenario, determining, by a processing unit of the balancing engine, an updated unplanned outcome and a related quantity using the unplanned outcome as an input; Writing the updated unplanned results and related quantities and details of the calculations to the housing tool data blockchain via the transmission unit of the balancing engine; modifying, by the processing unit and the transmission unit of the balancing engine, a website accessible to at least the homeowner, the investor, and the remaining balancing position holder to display the updated unplanned results and associated amounts; and The transmission unit of the balancing engine notifies at least one offline homeowner, investor, and remaining balancing position holder of the updated unplanned result and related amount via a mobile phone or other receiving device.

2. The method according to claim 1, further comprising: At least one data engine embodied in at least one processing unit, at least one receiving unit, at least one transmitting unit, and at least one database is maintained on at least one processing server controlled by a management entity, said processing server creating, aggregating, updating, processing, storing, and communicating at least one time series of at least one data parameter.

3. The method according to claim 2, further comprising: receiving, at a receiving unit of at least one data engine, third-party data, the third-party data comprising input data for calculating at least one data parameter generated by the data engine; formatting the added data by a processing unit of the data engine, and then modifying the database by the same processing unit of the data engine to incorporate the added data; calculating, by a processing unit of the data engine, at least one non-third-party version of the data parameter; calculating, by a processing unit of the data engine, a single operational estimate of the data parameter using the third-party and non-third-party estimates; writing, via a transmission unit of the data engine, the updated operational valuation of the data parameter along with a record of the calculation, the record including at least a time and date stamp of the calculation, the third-party and non-third-party valuations, and a method for calculating the operational valuation on a property instrument data blockchain; and The processing unit and transmission unit of the data engine are used to modify at least a website accessible to homeowners and investors to display the updated operating valuation of the data parameter, and then the transmission unit of the data engine is used to alert at least one homeowner and investor who are in an offline state of the updated operating valuation via a mobile phone or other receiving device when either party generally requests an update to the operating valuation or when the value of the data parameter is achieved.

4. The method according to claim 1, further comprising: At least one third-party data engine embodied in at least one processing unit, at least one receiving unit, at least one transmitting unit, and at least one database is maintained on at least one processing server controlled by the management entity for creating, aggregating, updating, processing, storing, and communicating at least one time series of at least one data parameter generated from at least one third-party financing scheme.

5. The method according to claim 1, further comprising: receiving, at a receiving unit of at least one third-party data engine running on a processing server controlled by the management entity, data related to at least one third-party financing scheme; Determining, by a processing unit of the third-party data engine, elements of data to be recorded on the housing tool data blockchain; Modify the data to be recorded into a suitable format; Writing the data elements and any related calculations to the housing tool data blockchain via the third-party data engine's transfer unit; extracting, by the receiving unit of the third-party data engine, data describing the current status and relevant history of the third-party financing solution from the housing instrument data blockchain; Organizing the data for website display through the processing unit of the third-party data engine; modifying, by the processing unit and the transmission unit of the third-party data engine, a website accessible to at least homeowners and investors to display updated data for the third-party financing program; and Through the transmission unit of the third-party data engine, if any party normally requests the updated data, or based on the value of the data parameters, at least one homeowner and investor in an offline state is notified of the updated data via a mobile phone or other receiving device.

6. The method according to claim 1, further comprising: A contract engine embodied in at least one processing unit, at least one receiving unit, and at least one transmitting unit is maintained on at least one processing server controlled by the management entity to initiate, implement, execute, and update the home financing plan between at least one homeowner and an investor.

7. The method according to claim 1, further comprising: receiving, via a receiving unit of a contract engine running on a processing server controlled by an administrative entity, initial contract data describing a housing financing scheme; determining, by a processing unit, elements of the initial contract data to be recorded on the housing instrument data blockchain; Organizing and modifying the data to be recorded into a suitable format by the processing unit of the contract engine; and The necessary data elements are written into the house tool data blockchain by the transmission unit of the contract engine.

8. The method according to claim 1, further comprising: receiving, on a website or other input device controlled by the administrative entity, a request from the homeowner to change at least one term in a home financing plan, the at least one term specifying at least one option for the new term; and The request is transmitted through a transmitting unit of a server controlled by the management entity to a receiving unit of a contract engine operated by a processing unit controlled by the management entity.

9. The method according to claim 1, further comprising: In a direct scenario, the necessary contract provisions governing the requested term changes and related data for each option are extracted from the housing instrument data blockchain by a receiving unit of a contract engine running on a processing server controlled by the administrative entity; determining, by a processing unit of the contract engine, whether the contract for the housing financing plan permits the requested change in terms of each option; When permitting a change in terms, determine whether any approvals from parties other than the homeowner are required; When changes to the terms of at least one option are otherwise permitted, then issuing, by the transmission unit of the contract engine, a reminder to at least one interested party via at least one receiving device of at least one interested party that approval is required for each option to seek any required approval for each option; After receiving the response or after the deadline for responding has passed, determining, by the processing unit of the contract engine, whether each option proposed by the homeowner is accepted or rejected; modifying a website accessible to the homeowner via a delivery unit of the contract engine to notify the homeowner whether each option is authorized or denied, and, when at least one option is authorized, requesting the homeowner to confirm acceptance of one of the options or denial of all options; The transmitting unit of the data engine notifies at least one of the homeowners who is offline of the authorized or rejected options via a mobile phone or other receiving device, and when at least one option is authorized, requests the homeowner to confirm one option or reject all options; When the homeowner confirms the option, the transmission unit of the contract engine writes the term change including at least the effective date and time of the term change and relevant data containing the accepted option to the housing instrument data blockchain; modifying, by the processing unit and the transmitting unit of the contract engine, a website accessible to at least the homeowner and the investor to confirm that the change has taken effect, to display the effective time and date of the change, and to display the new home financing option terms; and The transmission unit of the contract engine notifies at least one homeowner and investor who are offline via a mobile phone or other receiving device that the change has taken effect and the time and date when the change takes effect.

10. The method according to claim 1, further comprising: In an indirect approach, extracting from the housing instrument data blockchain necessary contract provisions by a receiving unit of at least one third-party data engine running on a processing server controlled by the management entity, the contract provisions governing the requested term change and relevant data including data for generating an offer to the homeowner for at least each option including a term change to the housing financing option other than the term of the offer that is the subject of the request; calculating, by a processing unit of a contract engine running on a processing server controlled by an administrative entity, at least one offer for each term option change specified by the homeowner; modifying, via a delivery unit of the contract engine, a website accessible to the homeowner to notify the homeowner of the offer; requesting the homeowner to confirm acceptance of one of the offers or to confirm rejection of all of the offers; Sending, by the transmission unit of the contract engine, an offer and a reminder of the need to accept an offer or reject all offers to at least one homeowner who is offline via a mobile phone or other receiving device; Creating an offer data set by a processing unit of the contract engine, the offer data set including at least the content of the offer and the values of management data parameters and management offer terms at the time of the offer; Writing the offer data set into the housing tool data blockchain through the transmission unit of the contract engine; When the homeowner accepts the offer, extracting the offer data set from the house tool data blockchain through the receiving unit of the contract engine; calculating, by a processing unit of the contract engine, using the offer set data, adjustments required among at least the homeowner, the investor, and the remaining balance position holder to terminate the existing home financing arrangement and replace it with a new home financing arrangement incorporating the terms specified in the accepted offer; transmitting, by a transmission unit of the contract engine, a message informing the relevant parties of the required steps; Receiving, by the receiving unit of the contract engine, verification that the required steps have been completed, including any required payments between the parties; compiling, by a processing unit of the contract engine, a transition data package, wherein the transition data package includes at least adjustments for closing the existing home financing plan, terms of the new home financing plan and initial remaining account positions of the parties, and a date and time when the new plan takes effect; Writing the transition data packet to the housing instrument data blockchain via the transmission unit of the contract engine to implement the transition to the new housing financing plan; creating, by a processing unit of the contract engine, a separate displayable version of the transitional data package appropriate for each relevant party; modifying, by the processing unit and the transmission unit of the contract engine, a website accessible to the parties to display a separate version of the transitional data package to each separate party on a separate portion of the website and to display the new proposal on a commonly accessible area of the website; and The transmission unit of the contract engine sends a reminder of the transition data package related to the party and the public data describing the new housing financing plan to each of the relevant parties in the offline state.

11. The method according to claim 1 , further comprising: receiving, on a website or other input device controlled by the management entity, a request from the homeowner to sell remaining account positions to at least one investor or to purchase remaining account positions from at least one investor; and The sale or purchase request is transmitted through a transmission unit of a server controlled by the management entity to a reception unit of a contract engine executed by a processing unit controlled by the management entity.

12. The method according to claim 1, further comprising: for a direct scenario, extracting from said housing instrument data blockchain, by a receiving unit of a contract engine running on a processing server controlled by the administrative entity, the necessary contract provisions to govern the requested sale or purchase, and related data, including at least data necessary to determine the terms of said sale or purchase; determining, by a processing unit of the contract engine, whether a contract under the home financing solution permits the requested sale or purchase; When the contract for the home financing program permits the requested sale or purchase, determining whether approval of the investor on the other side of the transaction is required; determining, by a processing unit of the contract engine, the applicable terms of the sale or purchase; When otherwise permitted to proceed with said sale or purchase, seeking required investor approvals, via a transmitting unit of said contract engine, based on alerting said investors, via at least one receiving device of each investor, of the terms and the calculated need for consent or refusal of approval; After receiving the response or after a deadline for the response has passed, determining, by a processing unit of the contract engine, whether to authorize or deny the sale or purchase of the calculated terms; Modifying, by the transmission unit of the contract engine, a website accessible to the homeowner to notify the homeowner of authorization or refusal; For authorization, requesting the homeowner to confirm acceptance or rejection based on the calculated terms; The transmission unit of the contract engine notifies the homeowner offline of the authorization or rejection via a mobile phone or other receiving device; For authorization, requesting the homeowner to confirm acceptance or rejection of the transaction based on the calculated terms; When the homeowner confirms the transaction, a message is transmitted through the transmission unit of the contract engine, which notifies the relevant party or parties of the requested steps; The step of receiving, by the receiving unit of the contract engine, the request includes verification that any payment required between the parties has been completed; compiling, by a processing unit of the contract engine, a transaction data packet, the transaction data packet including at least the confirmation of the transaction, terms of the transaction, a date and time at which the transaction takes effect, and new remaining account positions of the parties at that date and time; Writing the transaction data packet into the housing instrument data blockchain via the transmission unit of the contract engine after being formatted by the processing unit of the contract engine; modifying, by the processing unit and the transmitting unit of the contract engine, a website accessible by at least the homeowner and the investor to display relevant portions of the transaction data packet; and The transmission unit of the contract engine notifies at least one of the homeowner and investor who are offline of the relevant part of the transaction data packet via a mobile phone or other receiving device.

13. The method according to claim 10, further comprising: In a non-direct scenario, extracting from said home instrument data blockchain, via a receiving unit of at least one third-party data engine operating on a processing server controlled by said administrative entity, the necessary contractual provisions to govern the requested sale or purchase and related data, including data sufficient to generate offers to the homeowner in connection with the proposed sale or purchase, each offer containing at least data concerning a change in terms of said home financing scenario accompanying said proposed sale or purchase; calculating, by a processing unit of the contract engine, at least one offer regarding a sale or purchase proposed by the homeowner; determining, by a processing unit of the contract engine, whether a contract under the home financing solution permits the requested sale or purchase; When the contract for the home financing program permits the requested sale or purchase, determining whether approval by the investor on the other side of the transaction is required; determining, by a processing unit of the contract engine, the applicable terms of sale or purchase and the terms of each offer; if sales or purchases are otherwise permitted, alerting said investors via at least one receiving device of each of said investors of said offers and the need to approve or deny approval of each offer, seeking approval of the investors, if required, for each offer via the transmitting unit; determining, by a processing unit of the contract engine, whether each offer is authorized or rejected after a response is received or after a deadline for a response has passed; modifying, via a delivery unit of the contract engine, a website accessible to the homeowner to notify the homeowner of the homeowner's authorization or rejection of each offer; For authorization of at least one offer, requesting said homeowner to confirm acceptance of one offer and the terms of sale or purchase, or to reject all offers; The transmission unit of the contract engine notifies the homeowner offline of the authorization or rejection of each offer via a mobile phone or other receiving device; For authorization of at least one offer, requesting said homeowner to confirm acceptance of an offer and said terms of sale or purchase, or to reject all offers; Creating an offer data set by a processing unit of the contract engine, the offer data set including at least the content of the offer, sale or purchase terms, and values of control data parameters at the time of the offer, which control the values of the offer terms; Writing the offer data set into the housing tool data blockchain through the transmission unit of the contract engine; When the homeowner accepts the offer and the sales or purchase terms, extracting the offer data set from the house instrument data blockchain via the receiving unit of the contract engine; calculating, by a processing unit of the contract engine, using the offer set data, adjustments required among at least the homeowner, the investor, and the remaining balance position holder to terminate the existing home financing arrangement and replace it with a new home financing arrangement incorporating the terms specified in the accepted offer; Sending a message via the delivery unit of the contract engine to notify the relevant parties of the required steps; The steps required for receiving, by the receiving unit of the contract engine, include verification that any required payments between the parties have been completed; compiling, by a processing unit of the contract engine, a transition data package including at least the adjustments for closing the existing home financing arrangement, the terms of the sale or purchase, the terms of the new home financing arrangement and the initial remaining account positions of the parties, and the date and time at which the new arrangement is to take effect; The transmission unit of the contract engine writes the transition data packet into the house tool data blockchain, moving to said new housing financing options; creating, by a processing unit of the contract engine, a separate displayable version of the transitional data package appropriate for each relevant party; modifying, by the processing unit and the transmission unit of the contract engine, a website accessible to the parties to display the transition package in separate versions for each separate party on separate portions of the website and to display the new proposal in a publicly accessible area of the website; and The initialization of the transition data packet related to the party and the general data describing the new house financing plan is sent to each of the relevant parties in the offline state through the transmission unit of the contract engine.

14. The method according to claim 1, wherein The blockchain system includes: Contract information specifying at least one housing financing arrangement between at least one homeowner and at least one investor financing a particular home; a time series of economic parameters relevant to the dynamic management of at least one housing financing scheme; Records of current and past ownership of financing debt or equity; Transaction records, including at least the payments made by the homeowner to the investor; Records of any adjustments or changes to the housing financing plan; specification of at least one balancing mechanism to track the net contributions of at least said homeowner and investor and to consider the home financing arrangement therebetween as a joint venture and to adjust at least one residual account to reflect said net contribution of said homeowner or said investor; Data and calculation records of the balancing engine based on the continuous operation of one or more balancing mechanisms, and the final adjustment of at least one residual account; an access protocol defining various levels of access to data in the blockchain system, and levels of authority for writing new data to the blockchain system; and Data describing homes that are the subject of home financing programs.

15. A system for facilitating transaction data, comprising a computing device of the homeowner for facilitating transaction data as a first party to said transaction; a computing device of an investor for facilitating transaction data as a second party to said transaction; A management entity device, wherein the management entity manages: at least one balancing engine device for implementing adjustments under a balancing mechanism based on the transaction data, the balancing mechanism being based on a purchase parity accumulation algorithm, the balancing engine device converting the homeowner's net capital contribution during each period into an appropriate amount of earned equity growth under the balancing mechanism; at least one data engine device for creating, aggregating, updating, processing, storing, and delivering at least one time series based on the transaction data; and at least one contract engine device for initiating, implementing, executing, and renewing a home financing arrangement between at least a homeowner and an investor based on the transaction data; a plurality of third-party devices that provide relevant third-party financing data based on the transaction data; a central buying and selling engine database for allowing the homeowner's computing device or the investor's computing device to transmit a purchase offer message based on the transaction; a distributed blockchain system for securely storing confidential data used to facilitate said transaction data; and An application layer for maintaining interfaces with the homeowner's computing device, the investor's computing device, the central trading engine database, the plurality of third-party devices, the distributed blockchain system, and the management entity device, wherein any communication between any entity controlled by the management entity and any of the homeowner, investor, and third-party device, any communication between any entity and the blockchain system, or any communication between any entity, the homeowner, or investor and the trading engine database is conducted through the application layer, so that; In response to the transaction, the management entity modifies, via the application layer, a website accessible to the homeowner and investor; and The homeowner and investor are alerted to the transaction via a mobile device.

Images