Prosecution Insights
Last updated: April 19, 2026
Application No. 18/199,818

SYSTEM, METHOD, AND PROGRAM FOR SUPPORTING PURCHASE AND SALE OF REAL ESTATE

Non-Final OA §101§112
Filed
May 19, 2023
Examiner
MONAGHAN, MICHAEL J
Art Unit
3629
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Kwc G K
OA Round
1 (Non-Final)
36%
Grant Probability
At Risk
1-2
OA Rounds
3y 1m
To Grant
92%
With Interview

Examiner Intelligence

Grants only 36% of cases
36%
Career Allow Rate
46 granted / 126 resolved
-15.5% vs TC avg
Strong +56% interview lift
Without
With
+55.9%
Interview Lift
resolved cases with interview
Typical timeline
3y 1m
Avg Prosecution
37 currently pending
Career history
163
Total Applications
across all art units

Statute-Specific Performance

§101
39.3%
-0.7% vs TC avg
§103
32.7%
-7.3% vs TC avg
§102
11.0%
-29.0% vs TC avg
§112
14.3%
-25.7% vs TC avg
Black line = Tech Center average estimate • Based on career data from 126 resolved cases

Office Action

§101 §112
Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Claim Objections Claims 2-3 and 6-7 are objected to because of the following informalities: Claim 2 recites “the system further comprises: second rewriting system for automatically rewriting”. Dependent claim 3 references “the second rewriting means”. Please amend “second rewriting system” to “second rewriting means” in claim 2. Appropriate correction is required. Claim Interpretation The following is a quotation of 35 U.S.C. 112(f): (f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph: An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked. As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph: (A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function; (B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and (C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function. Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function. Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Referring to claim 1, such limitations are: storage means, receiving means, rewriting means, and notification means. (See paragraphs 124, 132, 134-136, 139-140, 142, 155-156, 162, 164-165 and 167) Referring to claim 2, such limitation is: rewriting means and second rewriting system. (See paragraphs 134, 139-140, 155-156, and 164-165). The Examiner notes they view the second rewriting system to be a second rewriting means. Referring to claim 3, such limitations are: storage means, second rewriting means, and rewriting means. (See paragraphs 124, 132, 134, 139-140, 155-156, and 164-165) Referring to claim 4, such limitations are: receiving means, determining means, judging means, and rewriting means. (See paragraphs 134-137, 139-140, 162, 155-156, 164-165) Referring to claims 5-8, 9 and 10, such limitation is: storage means. (See paragraphs 124 and 132) Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claims 1-10 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Referring to independent claims 1, 9, and 10 and dependent claims 3 and 5-8, each of the claims recite “storage means” that invoked 112 (f); however, the storage means in the specification is discussed in the context as a memory unit (See paragraph 124) or as a blockchain network (See paragraph 132). Therefore it is unclear to the examiner whether the storage means as claimed is a memory unit or a blockchain network. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-10 are rejected under 35 U.S.C 101 because the claimed invention is directed to an abstract idea without significantly more. Step 1: Claims 1-8 recite a system (machine), Claim 9 recites a method (process), and Claim 10 recites a non-transitory computer readable storage medium (manufacture) and therefore fall into a statutory category. Step 2A – Prong 1 (Is a Judicial Exception Recited?): Referring to claims 1-10, the claims recite a manner of organizing a real estate transaction, which under its broadest reasonable interpretation covers concepts covered under the Certain Methods of Organizing Human Activity grouping of abstract ideas. The abstract idea portion of the claims is as follows: Claim 1 [A system for] supporting purchase and sale of real estate, comprising: Claim 9 A method for supporting purchase and sale of real estate, Claim 10 [A non-transitory computer-readable storage medium storing a program for] supporting purchase and sale of real estate, [wherein the program is executed in a computer system comprising a processor unit and storage means], [storage means for] storing information indicating real estate on sale, [the storage means] storing, while associating, information indicating a true owner of the real estate, information indicating a contract signed for the real estate, and information indicating a revolving mortgage on the real state; [receiving means for] receiving a request to purchase the real estate from a user; [rewriting means for] rewriting the true owner of the real estate indicated by the information indicating the true owner to the user without changing real estate registration of the real estate, without changing the contract, and without changing a mortgagor of the revolving mortgage; and [notification means for] notifying the user that purchase of the real estate has been completed. Where the portions not bracketed recite the abstract idea. Here the claims recite concepts capable performed in Certain Methods of Organizing Human Activity in particular managing personal interactions between people (including teaching and following rules), but for the recitation of generic computer components. In the present application concepts reciting a manner of organizing a real estate transaction (See paragraphs 2-3, and 52). If a claim limitation, under its broadest reasonable interpretation, covers concepts capable of being performed in managing personal interactions between people (including teaching and following rules), it falls under the Certain Methods of Organizing Human Activity grouping of abstract ideas. See MPEP 2106.04. Step 2A-Prong 2 (Is the Exception Integrated into a Practical Application?): The Examiner views the following as the additional elements: A system. (See paragraph 115 and Figures 2-3) Storage means. (See paragraphs 124 and 132) Receiving means. (See paragraphs 134-136 and 162) Rewriting means. (See paragraphs 134, 139-140, and 164-165) Notification means. (See paragraph 134, 142, and 167) A non-transitory computer-readable storage medium. (See paragraphs 119-120 and 124) A program. (See paragraphs 123-124) A computer system. (See paragraph 115) A processor unit. (See paragraph 123)) These additional elements are recited at a high-level of generality such that they act to merely “apply” the abstract idea using generic computing components and do not integrate the abstract idea into a practical application. (See MPEP 2106.05 (f)) The combination of these additional elements and/or results oriented steps are no more than mere instructions to apply the exception using generic computing components. (See MPEP 2106.05 (f)). Accordingly, even in combination these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, the claim is directed to an abstract idea. Step 2B (Does the claim recite additional elements that amount to Significantly More than the Judicial Exception?): As noted above, the claims as a whole merely describes a method that generally “apply” the concepts discussed in prong 1 above. (See MPEP 2106.05 f (II)) In particular applicant has recited the computing components at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components. As the court stated in TLI Communications v. LLC v. AV Automotive LLC, 823 F.3d 607, 613 (Fed. Cir. 2016) merely invoking generic computing components or machinery that perform their functions in their ordinary capacity to facilitate the abstract idea are mere instructions to implement the abstract idea within a computing environment and does not add significantly more to the abstract idea. Accordingly, these additional computer components do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea and as a result the claim is not patent eligible. Dependent claims 2 further defines the abstract idea as identified. Additionally, the claim recites the generic system (See paragraph 115 and Figures 2-3) and second rewriting system (See paragraphs 144-147 and 155-156), and rewriting means (See paragraphs 134, 139-140, 155-156, 164-165) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claim 2 is considered to be patent ineligible. Dependent claim 3 further defines the abstract idea as identified. Additionally, the claim recites the generic storage means (See paragraphs 124 and 132), the second rewriting means (See paragraphs 144-147 and 155-156), and rewriting means (See paragraphs 134, 139-140, 155-156, and 164-165) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claim 3 is considered to be patent ineligible. Dependent claim 4 further defines the abstract idea as identified. Additionally, the claim recites the generic receiving means (See paragraphs 134-136, 155-156, and 162), the system (See paragraph 115 and Figures 2-3), determining means (See paragraphs 138 and 155-156), judging means (See paragraph 138 and 155-156), and rewriting means (See paragraphs 134, 139-140, 155-156, and 164-165) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claim 4 is considered to be patent ineligible. Dependent claims 5-8 further define the abstract idea as identified. Additionally, the claim recites the generic storage means (See paragraphs 124 and 132) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claims 5-8 are considered to be patent ineligible. In conclusion the claims do not provide an inventive concept, because the claims do not recite additional elements or a combination of elements that amount to significantly more than the judicial exception of the claims. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and the collective functions merely provide conventional computer implementation. Therefore, whether taken individually or as an order combination, the claims are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter. No Prior Art Applied The prior art of record fails to at least explicitly disclose or teach at least the following limitations of the independent claims: (Claim 1) rewriting means for rewriting the true owner of the real estate indicated by the information indicating the true owner to the user without changing real estate registration of the real estate, without changing the contract, and without changing a mortgagor of the revolving mortgage (Claim 9) rewriting the true owner of the real estate indicated by the information indicating the true owner to the user without changing real estate registration of the real estate, without changing the contract, and without changing a mortgagor of the revolving mortgage (Claim 10) rewriting the true owner of the real estate indicated by the information indicating the true owner to the user without changing real estate registration of the real estate, without changing the contract, and without changing a mortgagor of the revolving mortgage The closest identified prior art is the following: Strnad (US 20200394714) – directed to real time dynamic management of real estate finances and services. Strnad paragraph 311 teaching the flexibility of neutral DOOR instruments allows many tasks that currently are cumbersome to be accomplished easily and at low cost. For example, a home equity line of credit (“HELOC”) currently requires a separate formal loan. If a home increases substantially in value, an upward adjustment in the credit line is not automatic. It may require the homeowner to refinance. In contrast, a feature permitting the homeowner to create a HELOC type of loan as a virtually costless option is compatible with many DOOR variants. Furthermore, the available credit can vary in real time along with the value of the home and market conditions. Consider the ANZIE-DOOR framework. The homeowner can borrow up to the full amount of the priority block if desired. Absent a cash contribution, there are two ways in which the homeowner might expand the priority block: (i) by incurring more mortgage borrowing; (ii) by shifting insured equity to committed equity. Strnad paragraphs 546-550 teaching blockchain ledgers store data in an immutable and transparent way. There are many possible ways to implement and use blockchains consistent with our innovation including at least: (1) a centralized system in which data is anchored to the blockchain using a third-party method that provides the application layer between the user and the blockchain; (2) the use of smart contracts to organize data and facilitate transactions by saving smart contract states to a public blockchain with much of the work occurring off chain to increase efficiency; and (3) developing a custom private blockchain. In the embodiments below, we refer to a “blockchain system” to mean both a blockchain and a method of implementation. It should be appreciated that the details of implementation are by way of example only and are not in any way meant to be limiting. In the embodiments that follow, one or more blockchain systems are used for the following purposes: (1) Housing Instrument Data and History. One or more “housing instrument data blockchains” contain the data and history of each housing instrument in an immutable form along with the current value of relevant economic variables. The associated blockchain systems form a transparent basis for queries by investors, homeowners, servicing entities, other blockchain systems, or other parties concerning current DOOR instrument shares, values, or other elements using various computing or communication devices. (2) Transaction Data. One or more “transaction blockchain systems” might be used to complete part or all of certain transactions including at least refinancing the mortgage underlying a DOOR instrument, changing payment rates, shifting among neutral DOOR instruments, or buying or selling the underlying home with the concomitant creation or retirement of the associated DOOR instrument. (3) Cryptocurrency Operation. One or more “cryptocurrency blockchains” might include data over time on the housing interests held by various cryptocurrencies that embody portfolios of such interests. Using purchase parity variants results in the property that, across a wide variety of DOOR instruments that use different residual accounts and differ in other ways, the investor continuously earns precisely the economic return on the underlying home. These instruments can be pooled, creating a portfolio of pure housing returns that can serve as the basis of a cryptocurrency operated through a blockchain system. National, regional, or world housing returns can be simulated through the underlying pool, resulting in a hard currency backed by housing returns of a certain type. Soft fiat currencies, such as the dollar would fluctuate continuously relative to this hard currency. Strnad paragraphs 591-594 teaching the managing entity 106 maintains, on a least one processing server controlled by a managing entity, 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 for purposes of initiating, implementing, enforcing, and updating the housing finance arrangement between at least a homeowner 102 and an investor 104. Input data for the contract engine 112 resides in a housing instrument data blockchain system 120. FIG. 30 illustrates an exemplary embodiment of the contract engine 112 of system 100 with a receiving unit 802 designed to receive data over one or more networks, a transmitting unit 804 to broadcast data over one or more networks, a processing unit 806 with the computer architecture to execute the exemplary function of the embodiment described, and a database 808 for storing data. FIG. 31 is a flow diagram illustrating the process of addressing a homeowner's request in accordance with exemplary embodiments (900). The homeowner may want to change the level of payments to the investor, effectively refinancing the home finance arrangement. The homeowner accesses the website operated by the managing entity and requests a change in the level of the payment, generating a transmission message sent through a transmitting unit to the receiving unit of a contract engine controlled by the managing entity (902). The contract engine processing unit sends through a transmitting unit a query of the housing instrument data blockchain system along with access authorization data to extract relevant information including necessary contract information and other data including at least the level of earned equity (904). The housing instrument data blockchain system implements its access protocol to determine if the contract engine has access to the requested data. Strnad paragraphs 598-600 teaching the homeowner accesses a “managing entity website” controlled by the managing entity and initiates a request to buy or sell equity, generating a transmission message sent through a transmitting unit to the receiving unit of a contract engine controlled by the managing entity (1002). The data for input into the contract engine resides in a housing instrument data blockchain. The contract engine transmits through a transmitting unit a query of the housing instrument data blockchain system along with access authorization data to extract relevant data including the applicable contract terms and the current values of relevant parameters, including at least the current operative home valuation, stored on the blockchain (1004). The housing instrument data blockchain system implements its access protocol to determine if the contract engine has access to the requested data. After verification that access is permitted, the contract engine receives the data via a receiving unit, including contract data pertinent to the question of whether the transaction is permissible (1006), and the processing unit associated with the contract engine determines whether the requested transaction is permissible under the contract without further investor approval given the current value of the relevant parameters extracted from the housing instrument data blockchain (1008). If the requested transaction is not permissible, the processing unit associated with the contract engine generates a denial message (1010) and transmits the denial message to the homeowner and investor (or an artificial intelligence entity representing the investor), who may be offline, by email, SMS message, or otherwise (1012). The assessment comprises tasks including at least determining whether a minimum level of earned equity will remain after the requested sale of earned equity by the homeowner is carried out, a level sufficient to support the homeowner's maintenance obligation. As part of the assessment, the contract engine computes the amount of equity in percentage (of home value) terms and the corresponding dollar amount based on the house value extracted from the housing instrument data blockchain for the requested sale of equity by the homeowner (1014). The contract engine generates an outcome message (1016) and sends the message through a transmitting unit to the managing entity website accessible to the homeowner and investor (1018). The request outcome message contains request outcome data that includes at least: (i) the percentage and dollar value of the earned equity that the homeowner proposes to sell to the investor; (ii) whether the request was approved or denied; (iii) in the case of denial, the applicable reasons for denial; and (iv) in the case of approval, the time limits for confirmation by the homeowner along with a request for confirmation and payment receipt instructions from the homeowner. The managing entity website reports through a graphical user interface or other accessible display option the approval or denial along with the other applicable request outcome data. The contract engine via a transmitting unit notifies the homeowner and investor (or an artificial intelligence entity representing the investor), who may be offline, by email, SMS message, or otherwise whether the request was approved or not along with the request outcome data relevant to each party. If the request was approved, then the notification to the homeowner includes a confirmation request asking the homeowner to confirm the sales transaction (1020). If the contract engine does not receive confirmation from the homeowner within a certain amount of time, then the contract engine periodically sends through a transmitting unit to the managing entity website accessible to the homeowner further confirmation request messages with confirmation request data that include at least: (i) the percentage and dollar value of the earned equity that the homeowner proposes to sell to the investor; and (ii) the time limits for confirmation and payment by the homeowner along with a request for confirmation and payment receipt instructions from the homeowner. Strnad paragraph 694 teaching referring now to FIG. 36, through a transmitting unit, the contract engine sends a payment completion message to a receiving unit of a mortgage data engine, the message including the fact that the contract engine already wrote the mortgage payment data onto the housing instrument data blockchain. The mortgage data engine transmits through a transmitting unit a query of the housing instrument data blockchain system along with access authorization data to extract data adequate to update the status of the mortgage including at least the payment history, the current principal balance and monthly payment amount following the mortgage payment, and the loan-to-value ratio based on the most recent operative valuation of the home residing on the housing instrument data blockchain (1408). Martinho (US 20190019250) – directed to making a loan real property. Martinho paragraphs 58-62 teaching a reverse mortgage is a government secured loan that pays out either a lump sum of money or the ability to draw on a fixed sum using a primary residence as collateral. The amount loaned on a reverse mortgage is based on borrower's age (all people on title must be a minimum of 62 years of age) and the value of the owner's residence. The borrower does not have to make mortgage payments, but interest does accrue on the loan until it is fully repaid. A reverse mortgage does not have to be repaid until the borrower either stops living at the property or passes away. Then the reverse mortgage must typically be fully repaid within 3-6 months, depending on the mortgage product and individual lender requirements. Reverse mortgages by their nature are almost designed to force seniors who must vacate their residence to sell the property to repay the reverse mortgage. The elderly are frequently amongst the list of people unable to obtain new loans because other than their personal residence, they often possess few other significant assets or sufficient income to qualify for a loan to repay a reverse mortgage. If the senior had other significant assets or income, it is unlikely they would have needed a reverse mortgage in the first place. So, when a senior with a reverse mortgage vacates their home, either voluntarily or unexpectedly, that triggers the acceleration clause in the reverse mortgage demanding that the loan be fully repaid within 3-6 months. However, such seniors are typically unable to repay the reverse mortgage unless they sell their home because there are no affordable loan products in the market that will enable such seniors to fully repay the balance owed on their reverse mortgage and continue owning the property. One embodiment of the present invention specifically offers a solution to seniors with reverse mortgages that either have moved out of their home, or are about to move out, but do not desire to sell the property despite not having the assets to repay the reverse mortgage. In accordance with the embodiments of the invention, the invention provides property owners financing without the typical qualifications of good credit, sufficient income, or property management experience. The core requirements to qualify for the loan in this invention are that the debt does not exceed a specified ratio when compared to the value of the property, that the property is either currently rented or may be put up for rent soon, and that the rent is sufficient to pay for the mortgage payments, operating expenses, and build up reasonable cash reserves. In an embodiment, the present invention allows a senior with a reverse mortgage to move out of their primary residence and not have to sell their property if they qualify for this innovative loan. While the process of determining whether a property is qualified for the innovative loan is complicated, it is fairly invisible to the client requesting the loan. The client merely allows the broker and inspectors access to the home so the property can be assessed plus grants the broker permission to investigate debts attached to the property. If the property qualifies for a loan, then in one embodiment, the client merely follows an application process simpler than applying for a conventional loan. The loan qualification process focuses on whether the borrower's property is capable of being rented out for a sufficient amount, such that it can meet the new debt obligation, operating expenses, and build up cash reserves. The property must also have a loan to value ratio low enough for the loan to be considered relatively safe for the lender. If the property meets these qualifications, then the owner is free to vacate their home without having to sell it. The new loan provided by this innovation pays off all debt, including the reverse mortgage, plus it includes funds to update/repair the property to make it safe, desirable to renters, and address future property maintenance issues. With this innovative loan in place and the reverse mortgage fully repaid, the property can be repaired/upgraded so that it may rented out. Once rented, the property will generate the income necessary to sustain itself and potentially even provide the owner some positive cash flow. Cameron et al. (US 20220284524) -directed to a blockchain based real estate registry. Cameron paragraph 7 teaching the present invention provides systems and methods relating to a real estate registry and monitoring system. The blockchain based registry maintains records on each individual property within the jurisdiction that the real estate registry and monitoring system operates. The system will record changes to the property thereby creating a chronological record of a property's evolution. The blockchain based registry only adds new data records after the new data records have been vetted and approved by specific stakeholder users. These new data records are only added once a consensus from the specific stakeholder users has been received. Data records are added whenever an event that affects the property occurs, such as a sale of the property or a court order or the taking out of a building permit. Whenever new data records are added to the blockchain, all stakeholder users are notified based on the nature of the change recorded. Each data record may contain a link that points to one or more supporting documentation for the change evidenced by the data record. Cameron paragraph 22 teaching in addition to the above, the system operates by ensuring that any new records that reflect changes affecting the property are only created after specific stakeholder users have approved these changes. Of course, different changes would mean that different users (for example, users whose interests in the property may be affected by the changes) would need to approve the records for those changes. As an example, a record that details and evidences the sale of the property would need to be approved by the lawyer/notary/legal professional representing the current owner of the property, and the lawyer/notary/legal professional representing the buyer in the transaction. Similarly, a record evidencing a mortgage registered against the property would need to be approved by the lawyer/notary/legal professional representing the owner of the property, the lawyer/notary/legal professional representing the bank or lending institution registering mortgage, and any other lawyers/notaries/legal professionals involved in the transaction. The system operates by only creating the necessary record or records after the necessary stakeholder users have approved of the record/records. For some implementations, all the necessary stakeholder users have to approve the record (unanimity amongst the relevant users) while in others, approval of only a majority or some other predefined subset of relevant stakeholder users is necessary. Thus, as an example for one implementation, for a building permit record to be recorded against a property, the relevant stakeholder users (i.e., the property owner and the municipality issuing the permit) would all need to approve the building permit record before the record generates a transaction to the blockchain which is then committed to a block in the blockchain. For some implementations, multiple series of interconnected events are executed in parallel after being triggered by one or more predecessor events, and each of these events require specific relevant stakeholder users to approve of the details of the specific data record for the individual event within the series of interconnected events, and all of the interconnected events must be approved by the specific relevant stakeholders unique to the each event prior to each event being committed as a block to the blockchain. An example of a series of interconnected events that are executed in parallel is the sale of a newly constructed home to a buyer who is registering a government guaranteed mortgage, a homeowner's insurance policy, and a new home warranty. For each event of the relevant stakeholder users, the buyer's lawyer and the lender's lawyer and the representative for the government guarantee program, the new property owner and the representative of the insurance company issuing the insurance policy, and the new property owner and the new home warranty program representative must all approve the details of the individual records specific to each individual interconnected event prior the predecessor event which is the transfer of ownership in the specific property from the seller to the buyer being able to be approved by the lawyer for the seller and the lawyer for the buyer. Once all relevant stakeholders to each event have approved of the records for their individual events, then the transfer of ownership record can be committed as a block to the blockchain, simultaneously the blocks representing the registered mortgage, the government guarantee, the property insurance registration, and the new home warranty registration can be committed as blocks to the blockchain. It should be clear that without the approval for each of the individual events in the series of parallel interconnected events, the predecessor event, in this case being the transfer of ownership, cannot be approved of or committed to the blockchain. It should be clear that each and every significant event that affects the property generates a transaction and that transaction is recorded in a block in the blockchain. Any such event is recorded in the block. Cameron paragraph 25 teaching for better clarity, it should be noted that, in keeping with the blockchain structure used in the system of the present invention, each record stored in the blockchain is immutable and unchangeable. Thus, any changes affecting the property would need to be evidenced by a new record detailing that change. Thus, a sale of the property and an identification of the new owner would be in one record. Similarly, a mortgage on that property would need a new record and a discharge of that mortgage would require another new record. Similarly, it should be clear that the stakeholder users whose approval for the changes to be recorded against the property would change depending on that change. Thus, to record a mortgage against the property, the owner, the lender, and at least one custodian would need to be involved. All of these users would need to approve the record detailing the mortgage before that record is committed to the blockchain. Tarmann et al. (US 20210350456) – directed to continuously updating information about one or more of a customer approved for a mortgage and a property identified as mortgage ready. Tarmann paragraph 47 teaching generally, the present disclosure and exemplary aspects relate to, inter alia, systems and methods for utilizing blockchain technology to approve a dynamic mortgage application. For example, a blockchain may be used to approve a customer for a mortgage amount, determine and identify a real estate property as mortgage ready (e.g., having a calculated appraisal value using information about the real estate property accessed from the blockchain that meets, or exceeds, a list price of the real estate property), approve a dynamic mortgage application, monitor and update the mortgage ready data relative to both the customer and the real estate property, and identify multiple mortgage ready properties based upon customer input, and incentivize and rate insurance agents based upon the customer and real estate property mortgage ready data received from the agent. In one example, the systems and methods described herein allow for using a private blockchain of an insurance entity, which gives the option for private information and permissioned participants in the blockchain. Tarmann paragraphs 108-109 teaching after it is determined the customer is approved for a mortgage and the real estate property is mortgage ready, the method 800 may further include comparing, via the one or more processors, such as the one or more processors of the insurance entity 14, a calculated amount the customer is approved for a mortgage with the calculated appraisal value of the real estate property (block 806). More specifically, the one or more processors determine if the amount the customer is approved for a mortgage is equal to, or exceeds, the calculated appraisal value of the real estate property (block 808). If yes, the one or more processors approve a mortgage application of the customer for the requested real estate property that is mortgage ready (block 810). The method may then further include updating, at the memory, one or more of a block for the blockchain or the memory storage location to indicate the customer mortgage application for the requested real estate property is approved (block 812). However, if the amount the customer is approved for a mortgage does not equal, or exceed, the calculated appraisal value of the real estate property, the one or more processors may indicate the mortgage application of the customer for the requested real estate property is not approved (block 814). In one example, the method may further include updating, at the memory, a block for the blockchain to indicate the customer mortgage application for the requested property is not approved. Tarmann paragraph 157 teaching in one aspect, a computer-implemented method of matching a mortgage ready customer with a mortgage ready property may be provided. The method may include, via one or more processors, servers, networks, and/or transceivers: (1) retrieving from a memory unit, or receiving (such as via wireless communication or data transmission over one or more radio frequency links) customer income and/or asset information; (2) verifying an identity of a customer that is currently online, such as via a secure network connection; (3) verifying that the customer's income and/or asset information is up-to-date or current, or receiving up-to-date income and/or asset information for the customer via a secure network connection; (4) pre-approving the customer up to a maximum loan amount based upon the current or up-to-date customer income and/or asset information; (5) asking or inquiring of the customer if they are ready to search available (and/or mortgage ready) properties, or otherwise receiving an indication from the customer's mobile device that the customer is actively shopping properties or wants to see available properties; and/or (6) if so, causing a virtual map of available properties for sale to be graphically depicted on the customer's mobile device, the properties graphically depicted being color coded to indicate whether (i) they have list prices below the maximum loan amount that the customer is currently pre-approved for, and/or (ii) are mortgage ready (e.g., pre-vetted to indicate that an appraisal indicates that the house is valued at or near the asking price). The map depicted may be centered about or around a current GPS location retrieved or received from the customer's mobile device. The method may include additional, less, or alternate actions, including those discussed elsewhere herein. Kleinberg (US 20190005145) – directed to managing contact information. Kleinberg paragraphs teaching the owner can transfer ownership of the informational record and corresponding unique identifier to other users. A transfer may occur, for example, when a company sells assets/contracts or when a service firm creates an informational record for a client and transfers control of the informational record to the client. In an example, if an owner is transferring a contract, the informational record (including the unique identifier) associated with the contract can be transferred to another entity. When an informational record is transferred, electronic contact card(s) stay associated with the owner but is disassociated with the informational record. New electronic contact card(s) are automatically created for the new owner and associated with the transferred informational record. In some embodiments, new electronic contact card(s) include the same contact information from the original electronic contact card(s) until the new owner changes the new electronic contact card(s). In some embodiments, before ownership of the informational record is transferred, acceptance of the transferred informational record must be received. Thus, the system allows contact information and party information in a contract to be updated easily without modifying the contract itself. The system can save (for the owner and users to see) “activity” for each informational record associated with the unique identifier. “Activity” may include when the informational record was created, when the electronic contact card was changed, previous contact information, when the document was transferred to a different owner, and previous owners. Kleinberg paragraph 40 teaching contact update and transfer module 350 receives requests to update contact information or ownership information from the owner of an informational record. In some implementations, the owner can provide login credentials to change the informational record, contact information, or ownership information associated with an informational record. The updates can be stored in a database such that when a link with the unique identifier is accessed, the new contact information is displayed. Fields stored for each informational record can include versions of each informational record and dates the versions were created, archived, and transferred. Kleinberg paragraph 42 teaching the owner may further provide updates regarding documents associated with the unique identifier (e.g., document name and/or version, parties, creation date). Thus, new contact information for many informational records can effectively be updated with minimal interactions. Informational records are stored in a database on a server and mapped to unique identifiers and electronic contact cards, which are also stored in a database in a server. Other information that can be stored include contract data (e.g., title, parties, dates), how many informational records are owned by an entity, transferred informational records, and account data of owners (e.g., email addresses). While the prior art may teach concepts covering storing information regarding real estate available for purchase (Tarmann paragraphs 47 and 157), storing information including prior contracts as part of transactions for the real estate (Strnad paragraphs 546-550 and 594 and Cameron paragraph 7), different mechanisms a user may utilize as a buyer or homeowner for facilitating a transaction (Strnad paragraph 311, Martinho paragraphs 58-62), notifying users regarding the outcome of transactions (Strnad paragraph 600 and Tarmann paragraphs 108-109), utilizing a blockchain for storing information (Strnad paragraphs 546-550, and 598, Cameron paragraphs 7, 22, and 25, and Tarman paragraphs 47 and 157), and updating ownership information without updating the corresponding contract (Kleinberg paragraphs 15 and 42) the prior art fails to disclose or teach or suggest the particular manner of rewriting the true owner of the real estate indicated by the information indicating the true owner to the user without changing real estate registration, without changing the contract, and without changing a mortgagor of the revolving mortgage as claimed by Applicant. Therefore, there is no current art rejection applied for claims 1-10; however, the Examiner notes the outstanding claim rejection under 35 USC § 101 for claims 1-10 and under 35 USC § 112 (b) for claims 1-10 and claim objections for claims 2-3 and 6-7. Therefore, the claims are not indicated as allowable at this time. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Howie (US 20200175623) – directed to a distributed ledger based system for the settlement and transfer of title to real estate. High (US 20210103997) – directed to a real estate platform for transferring fractional ownership interests. Cook (US 20180211340) -directed to database management of transaction information and payment instruction data. Brynes et al. (US 20220156861) -directed to blockchain-based data-driven property management. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J MONAGHAN whose telephone number is (571)270-5523. The examiner can normally be reached on Monday- Friday 8:30 am - 5:30 pm. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sarah Monfeldt can be reached on (571) 270-1833. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /Michael J. Monaghan/Examiner, Art Unit 3629
Read full office action

Prosecution Timeline

May 19, 2023
Application Filed
Sep 30, 2025
Non-Final Rejection — §101, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12596966
Automated Property Access Control Involving Sequential Call Prompt Interactions Using Multiple Computing Devices
2y 5m to grant Granted Apr 07, 2026
Patent 12591859
Method and system for vehicle service session
2y 5m to grant Granted Mar 31, 2026
Patent 12482046
SYSTEMS AND METHODS FOR DETERMINING LAND USE DEVELOPMENT POTENTIAL
2y 5m to grant Granted Nov 25, 2025
Patent 12462263
BATTERY DIGITAL ASSETS, AND ACCOUNTABILITY
2y 5m to grant Granted Nov 04, 2025
Patent 12437308
System, Method and Process for Product Authentication and Verification
2y 5m to grant Granted Oct 07, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
36%
Grant Probability
92%
With Interview (+55.9%)
3y 1m
Median Time to Grant
Low
PTA Risk
Based on 126 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month