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 .
Information Disclosure Statement
The listing of references in the specification is not a proper information disclosure statement. 37 CFR 1.98(b) requires a list of all patents, publications, or other information submitted for consideration by the Office, and MPEP § 609.04(a) states, "the list may not be incorporated into the specification but must be submitted in a separate paper." Therefore, unless the references have been cited by the examiner on form PTO-892, they have not been considered.
Drawings
The drawings are objected to because Figures 3 and 4 are currently very difficult to read and ascertain the text. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
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, the claim recites the following instances that will be interpreted under 112 (f) : “means for buyers to input or upload search parameters and financial verification documents; means for scrubbing real estate websites to find matching properties; means for coordinating property viewings and notifying buyers of confirmed appointments; means for generating offers, including comparable price opinions and repair cost estimates; means for generating and electronically signing contracts and associated forms; means for managing the transaction process and providing milestone reminders; means for post-purchase document access.” Therefore the Examiner is interpreting the means to be provided by the Specification. (See paragraphs 24, 34, 37, 39, 43-44, 47, and 50 discussing the respective functions of the means).
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Referring to claim 1, the claim recites: “means for buyers to input or upload search parameters and financial verification documents; means for scrubbing real estate websites to find matching properties; means for coordinating property viewings and notifying buyers of confirmed appointments; means for generating offers, including comparable price opinions and repair cost estimates; means for generating and electronically signing contracts and associated forms; means for managing the transaction process and providing milestone reminders; means for post-purchase document access”
While the Specification discusses each of the functions performed there is no disclosure regarding the actual means used for performing each of the functions. (See paragraphs 24, 34, 37, 39, 43-44, 47, and 50).
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-20 are rejected under 35 U.S.C. 112(b) as being indefinite. Referring to claim 1, the claim limitations “means for buyers to input or upload search parameters and financial verification documents; means for scrubbing real estate websites to find matching properties; means for coordinating property viewings and notifying buyers of confirmed appointments; means for generating offers, including comparable price opinions and repair cost estimates; means for generating and electronically signing contracts and associated forms; means for managing the transaction process and providing milestone reminders; means for post-purchase document access” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. (See paragraphs 24, 34, 37, 39, 43-44, 47, 50). Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
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-20 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-20 recite a system (machine) and therefore fall into a statutory category.
Step 2A – Prong 1 (Is a Judicial Exception Recited?):
Referring to claims 1-20, the claims are directed to a manner of managing real estate processes for a user, 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:
[A virtual real estate assistant (VRA) system comprising: a fine-tuned Large Language Model (LLM) designed to] process real estate data and buyer preferences; [a Retrieval-Augmented Generation (RAG) module for dynamic data retrieval; means for] buyers to input or upload search parameters and financial verification documents; [means for scrubbing real estate websites to] find matching properties; [means for] coordinating property viewings and notifying buyers of confirmed appointments; [means for] generating offers, including comparable price opinions and repair cost estimates; [means for] generating and electronically signing contracts and associated forms; [means for] managing the transaction process and providing milestone reminders; [means for] post-purchase document access.
Where the portions not bracketed recite the abstract idea.
Here the claims recite concepts performed in Certain Methods of Organizing Human Activity in particular managing personal behavior or relationships or interactions between people (including following rules or instructions), but for the recitation of generic computer components. In the present application concepts recite a manner of organizing the reporting of building metrics (See paragraphs 3 and 6-10).
If a claim limitation, under its broadest reasonable interpretation, covers concepts capable of being performed in managing personal behavior or relationships or interactions between people (including following rules or instructions), 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 virtual real estate assistant (VRA) system. (See paragraph 32)
A fine-tuned Large Language Model (LLM). (See paragraph 32)
A Retrieval-Augmented Generation (RAG) module. (See paragraph 33)
Means for, facilitating each corresponding function. (See paragraphs 24, 34, 37, 39, 43-44, 47, 50).
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))
Regarding “a Retrieval-Augmented Generation (RAG) module for dynamic data retrieval” the Examiner views as a results-oriented solution step and is therefore viewed as equivalent to mere instructions to apply the abstract ide using generic computing components and does not integrate the abstract idea into a practical application. Id.
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. Id. 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 claim 2 further defines the abstract idea as identified. Additionally, the claim recites the results-oriented solution steps of “wherein the LLM is fine-tuned on real estate terminology and contractual language to offer clear explanations to buyers” (See paragraph 33) and are therefore viewed as equivalent 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 results-oriented solution steps of “wherein the RAG module dynamically augments information retrieval from multiple sources, including real-time market data feeds, geospatial data, public records, and community-sourced information” (See paragraph 33) and are therefore viewed as equivalent 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 claims 3 and 20, further defines the abstract idea as identified. Additionally, the claim recites the generic one or more digital wallets (See paragraph 63) 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 3 and 20 are considered to be patent ineligible.
Dependent claims 4-15, and 17-20 further define the abstract idea as identified. Additionally, the claim recites the generic system (See paragraph 32) 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-15, and 17-20 are considered to be patent ineligible.
Dependent claim 16 further defines the abstract idea as identified. Additionally, the claim recites the generic system (See paragraph 32) and AI-driven (See paragraphs 36 and 38 )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 16 is 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.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 6-15, 17 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Malanga et al. (US 20240411982) in view of Arriaga (US 20250054068), Vaynshteyn (US 20170337647), and Alongi (US 20200074513).
Referring to claim 1,
Malanga, which is directed to managing document compliance in real estate transactions, teaches
A virtual real estate assistant (VRA) system comprising: a fine-tuned Large Language Model (LLM) designed to process real estate data and buyer preferences; (Malanga paragraph 63 teaching for example, in some embodiments, the compliance review system 100 may include various AI components such as a Document Automation AI 110, a Risk Analysis AI 112, and/or a Chatbot AI 114. These AI components may utilize one or more AI or data processing techniques 116, such as machine learning (ML), large language models (LLMs), optical character recognition (OCR), natural language processing (NLP), and so forth. These AI or data processing techniques may be integrated into one or more particular applications associated with the system. For example, NLP and/or an LLM can be used to summarize a freeform document such as an inspection report. These AI components or models may be trained on, or fine-tuned based on, data specific to real estate transactions. In some embodiments, AI components can utilize retrieval augmented generation (RAG) techniques to improve the performance, accuracy, etc., of AI components. In some embodiments, these AI components may be used together or integrated. Malanga paragraph 67 teaching in some embodiments, large language models (LLM) calibrated to perform particular tasks may be used. An LLM fine-tuned on real estate transactions may be integrated, along with the Document Automation AI 110 and/or the Risk Analysis AI 112 into a conversational AI such as Chatbot AI 114, which can be used to carry out various tasks associated with the compliance review workflow. For instance, an auditor 152 may be able to converse with the Chatbot AI 114 and request that it check to see if a set of documents are properly signed.)
a Retrieval-Augmented Generation (RAG) module for dynamic data retrieval; (Malanga paragraphs 152-153 teaching some implementations herein can make use of retrieval augmented generation (RAG). RAG is a technique used in natural language processing and other machine learning tasks to enhance the quality and relevance of the outputs of a model (e.g., a summary, an explanation, etc.). In RAG, a retrieval model is first used to retrieve relevant information or context from a large corpus of text. This retrieved information can be used as an input to another model, for example, a generative large language model. The output of this model can be based at least in part on the retrieved contextual information. By incorporating a retrieval step, a generative model can provide more accurate and contextually appropriate outputs. RAG can be particularly useful in tasks such as answering questions, summarizing text, and engaging in dialogs, where contextual information can be critical. RAG can help overcome some limitations of pure generative models, which can be susceptible to generating irrelevant or nonsensical responses (colloquially referred to as hallucinations).)
means for buyers to input or upload search parameters and financial verification documents; (Malanga paragraph 56 teaching for example, there may be an upload function for the TCs 154 to send documents from their local hard drive to the compliance review system 100 or an attachment function that allows TCs 154 to associate uploaded documents with specific checklist items. In some embodiments, these documents can be stored in the Transaction Database 130 along with any other relevant information about that transaction. However, it should be noted that these documents do not necessarily need to be furnished by the TCs 154 or the auditors 152. For instance, in some embodiments, the system 100 can provide the documents (e.g., templates) to the TCs 154 to fill out instead of requiring that the documents be prepared and uploaded by the TCs 154. Malanga paragraph 70 teaching in some embodiments, the compliance review system 100 may include a Rules Database 132 that contains sets of rules for various jurisdictions that transactions may take place in. A particular jurisdiction may be associated with one or more sets of rules, and the specific ruleset that is utilized by the compliance review system 100 may depend on the nature of the transaction and the property. In some embodiments, the compliance review system 100 may include a Rules Engine 120 that may be used to generate and determine the checklists that are stored in the Checklist Database 134. The Rules Engine 120 may evaluate certain data points about a property or transaction and, if present, automatically change certain checklist items from “optional” to “required.” Thus, the transactions for a particular jurisdiction may be further subject to different checklists and checklist items. In some embodiments, the compliance review system 100 can receive property information and can automatically determine, for example, a specific ruleset to use based on the property location, property type (e.g., condominium, apartment, co-op, single family home, single family home in a planned development, etc.), and/or any other relevant information. Malanga paragraph 87 At operation 350, a system can receive a property selection from a user. At operation 352, the system can receive an indication to cancel or remove a checklist item of a checklist. At operation 354, the system can receive a cancelation reason. For example, the system may provide a GUI with radio buttons, checkboxes, a dropdown, a freeform text field, etc., that the user can use to provide a reason for the cancelation. At operation 356, the system can receive documentation relating to the cancelation. The documentation may provide additional context for why the checklist item is being canceled. At operation 358, the user can submit the cancelation request for approval. In some cases, cancelations can be automatically approved. For example, if a checklist item is identified as optional, the system may be configured to cancel the item without further approval. In some cases, a checklist item may require approval (e.g., approval following human review) to cancel the checklist item. For example, if a checklist item is identified as required, a greater level of review may be required by the system before the checklist item is canceled.)
means for generating and electronically signing contracts and associated forms; (Malanga paragraph 56 teaching in some embodiments, these documents can be stored in the Transaction Database 130 along with any other relevant information about that transaction. However, it should be noted that these documents do not necessarily need to be furnished by the TCs 154 or the auditors 152. For instance, in some embodiments, the system 100 can provide the documents (e.g., templates) to the TCs 154 to fill out instead of requiring that the documents be prepared and uploaded by the TCs 154. Malanga paragraph 89 teaching at operation 369, once the TC has finished entering information, the system can send one or more documents for signature to parties who need to sign. At operation 370, the system can receive an audit entry selection, for example, indicating that another user is ready to perform an audit of one or more documents. At operation 371, the system can receive a checklist selection. In response, the system can provide the checklist and outstanding audit items. At operation 372, the system can receive audit feedback, which can indicate that one or more items in a checklist require revision, are missing, etc. In some embodiments, the audit feedback may indicate that the checklist is complete. At operation 373, the system can receive a signoff indicating that the audit is complete. It will be appreciated that the audit being complete does not necessarily mean that the checklist is complete or that the documents are in condition to move forward. Malanga paragraph 92 teaching in some embodiments, the system can receive documents other than completed electronic documents, such as documents prepared by a bank, another agent, etc. In some embodiments, received documents can include documents that were printed and later scanned. In some embodiments, received documents can include documents with electronic signatures. In some embodiments, received documents can include documents with wet ink signatures. At operation 396, the system can automatically review the received completed documents, for example, to check for consistency, completeness, compliance with signature requirements, etc., for example, as described herein. At operation 398, the system can notify respective parties (e.g., agents, lenders, etc.) that one or more documents were rejected. The system may reject a document for a variety of reasons, such as inability to parse the document (e.g., due to poor scan quality), missing information, incorrect information, a document being an incorrect document (e.g., the wrong form was submitted), etc. The respective parties can receive notification of a rejected document and take action to correct the issue.)
means for managing the transaction process and providing milestone reminders; (Malanga paragraph 89 teaching at operation 369, once the TC has finished entering information, the system can send one or more documents for signature to parties who need to sign. At operation 370, the system can receive an audit entry selection, for example, indicating that another user is ready to perform an audit of one or more documents. At operation 371, the system can receive a checklist selection. In response, the system can provide the checklist and outstanding audit items. At operation 372, the system can receive audit feedback, which can indicate that one or more items in a checklist require revision, are missing, etc. In some embodiments, the audit feedback may indicate that the checklist is complete. At operation 373, the system can receive a signoff indicating that the audit is complete. It will be appreciated that the audit being complete does not necessarily mean that the checklist is complete or that the documents are in condition to move forward. Malanga paragraph 92 teaching in some embodiments, the system can receive documents other than completed electronic documents, such as documents prepared by a bank, another agent, etc. In some embodiments, received documents can include documents that were printed and later scanned. In some embodiments, received documents can include documents with electronic signatures. In some embodiments, received documents can include documents with wet ink signatures. At operation 396, the system can automatically review the received completed documents, for example, to check for consistency, completeness, compliance with signature requirements, etc., for example, as described herein. At operation 398, the system can notify respective parties (e.g., agents, lenders, etc.) that one or more documents were rejected. The system may reject a document for a variety of reasons, such as inability to parse the document (e.g., due to poor scan quality), missing information, incorrect information, a document being an incorrect document (e.g., the wrong form was submitted), etc. The respective parties can receive notification of a rejected document and take action to correct the issue.)
means for post-purchase document access. (Malanga paragraph 69 teaching in some embodiments, the compliance review system 100 may include a Transaction Database 130 that is used to store data associated with each transaction. For example, all the documents uploaded to the compliance review system 100 in the course of performing the compliance workflow on a transaction may be stored in the Transaction Database 130. Data for a transaction may, additionally or alternatively, be stored with a transactional email address along with any communication and attachments sent to the address, which can be made available to the TCs 154 and the auditors 152. In some embodiments, documents may not be stored in the transaction database 130. For example, in some embodiments, document files can be stored on a disk, in cloud storage (e.g., a cloud storage bucket), etc. In some embodiments, the transaction database 130 can include information about files, metadata, etc. For example, in some embodiments, the transaction database 130 can store information indicating where a corresponding file can be found. Malanga paragraph 148 teaching in some cases, there may be a need to provide data for an external audit. For example, a state agency, auditing firm, law firm, etc., may need or want to conduct a review of transactions. In some embodiments, a system can be configured to make all transactions, documents, automated checks, auditor checks, etc., available for external review by an auditor. In some embodiments, the system can be configured to provide access to data from a certain time period, for example as specified by a user. In some embodiments, the system can generate a read-only copy of the data. In some embodiments, the system can provide read-only access to data on the platform. In some embodiments, the platform can make the data available via download, via a user interface (e.g., an application or website), etc.)
Malanga does not teach or suggest means for scrubbing real estate websites to find matching properties;
However, Arriaga, which is directed to customization and utilization of target profiles, teaches means for scrubbing real estate websites to find matching properties; (Arriaga paragraph 40 teaching with continued reference to FIG. 1, dataset 120 may be retrieved using a web crawler. A “web crawler,” as used herein, is a program that systematically browses the internet for the purpose of Web indexing. The web crawler may be seeded with platform URLs, wherein the crawler may then visit the next related URL, retrieve the content, index the content, and/or measures the relevance of the content to the topic of interest. In some embodiments, computing device 104 may generate a web crawler to compile dataset 120. The web crawler may be seeded and/or trained with a reputable website, such as government websites. A web crawler may be generated by computing device 104. In some embodiments, the web crawler may be trained with information received from a user through a user interface. In some embodiments, the web crawler may be configured to generate a web query. A web query may include search criteria received from a user. For example, a user may submit a plurality of websites for the web crawler to search to extract any data suitable for dataset 120. Arriaga paragraph 133 teaching with continued reference to FIG. 1, the unified dashboard and/or content hub may include a personalized content feed. As used in this disclosure, a “personalized content feed” is a dynamic feature of a digital platform that curates and displays content tailored to an individual user's preferences, behaviors, and/or interests. In a non-limiting example, the personalized content feed may be accessed from within a client portal and/or a mobile app. In a non-limiting example, the personalized content feed may be configured to deliver tailored articles, videos, and educational resources based on each client's specific needs, interests, and risk profile. Continuing the non-limiting example, the personalized content feed previously mentioned may assist the client in making informed decisions about the client's insurance and risk management strategies. For example, without limitation, apparatus 100 may utilize a web crawler to collect content for the personalized content feed. As used in this disclosure, a “web crawler” is a program that systematically browses the internet for the purpose of Web indexing. In a non-limiting example, the web crawler may be seeded with platform URLs, wherein the web crawler may then visit the next related URL, retrieve the content, index the content, and/or measures the relevance of the content to the topic of interest. In some embodiments, processor 108 may generate the web crawler to compile the training data with uploaded data. In a non-limiting example, the web crawler may be seeded and/or trained with a reputable website to begin the search. In another non-limiting example, the web crawler may be trained using a list of target websites and courses that provide relevant and high-quality content such as financial news websites, insurance blogs, real estate platforms, educational portals, and the like. In another non-limiting example, the web crawler may be generated by a processor 108. In some embodiments, the web crawler may be trained with information received from a user through a graphical user interface. In some embodiments, the web crawler may be configured to generate a web query. For example, without limitation, a web query may include search criteria received from a user. For example, a user may submit a plurality of websites for the web crawler to search to extract entity records, inventory records, pricing records, product records, customer records, financial transaction records, customer feedback and review records, and the like. Arriaga paragraph 153 in some cases, gap finder module 156 may receive elements within modified dataset 144 and/or target data 124 and make calculations using an arithmetic logic unit within computing device 104. In some cases, gap finder module 156 may calculate the value of a user's assets, the total policy limits, the protection of the limits and the like. In some cases, gap finder module 156 may further calculate insurance coverages associated with the asset and make determinations as a function of the calculations. For example, processor 108 may calculate or determine that a particular asset is worth 10,000$ but the insurance coverage on the asset only covers 8,000$. In some cases gap finder module 156 may include web crawlers, wherein the web crawler may be configured to parse the internet for pricing of assets indicated within target data 124. For example, web crawler may be configured to retrieve an estimate of the target's property using estimates from one or more property websites. Similarly, web crawler may be configured to search the web for the price of the target's vehicles, assets, and the like. Gap finder module 156 may then be configured to compare the price of the assets to the current insurance coverage on the asset. In some cases, gap finder module 156 may determine that a particular asset within target data 124 does not contain any insurance coverage based on a lack of coverage indicated within target data 124, wherein gap finder module 156 may output a protection gap 152 indicating a lack of coverage. The Examiner is interpreting that Arriaga suggests the use of user’s criteria/preferences for identifying properties of interest for display to the user through the use of a web-crawler.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the coordination of a real estate transaction as taught in Malanga to incorporate means for scrubbing real estate websites to find matching properties as taught in Arriaga with the motivation of identifying properties meeting a user’s criteria based on the determined relevancy. (Arriaga paragraphs 133 and 153)
Malanga in view of Arriaga does not teach or suggest means for coordinating property viewings and notifying buyers of confirmed appointments;
However, Vaynshteyn, which is directed to performing peer to peer real estate transactions, teaches means for coordinating property viewings and notifying buyers of confirmed appointments; (Vaynshteyn paragraphs 40-42 teaching if a buyer is interested in the listed property by seller 201, information regarding the buyer is presented to the seller. The information presented to the seller 201 may be the profile of the buyer, which may comprise: contact details and financial information. In the preferred embodiment, the seller is presented with a profile comprising of the name, email address, and credit score of each interested buyer. The buyer may be presented with an option to send the property profile to a third party, such as a friend or another party interested in purchasing a property. If the third party does not already have an existing account, they may be prompted to sign up to an account to access the contact information of the seller. Upon presentation of the profiles of the interested parties to the property, the seller 201 may then decide if they are interested in any parties presented 206. If the seller 201 is interested in a buyer, the two parties are connected by providing both parties with the seller and buyer profiles. The seller 201 is able to select multiple buyers to engage with. If the seller is not interested in the buyer, they are able to reject the buyer or ignore the buyer. If the seller is not interested in any presented buyers, the seller is able to return to process 204, which will present any new interested parties. Additionally, a time limit on decision 206 may be applied, on the action of the buyer or seller, after which the offer to connect is considered to be rejected. The seller 201 and buyer may be connected 207, in one embodiment through an email system. Whilst, in another embodiment, the method of contact is through direct messaging. In a further embodiment, the method of contact is through telephone. During the first contact between a seller and buyer, the two parties may set up a date and time to view the property 208. The decision for a time and date to view the property in one embodiment may be facilitated though the use of a calendar scheduling service provided through the interface. The number of visits a property gains may be stored in the system and displayed to potential buyers through the profile of the property. The Examiner is interpreting that Vaynshteyn provides for a system that coordinates communications between a buyer and seller and suggests the buyer’s receiving a notification regarding the confirmation of scheduling a viewing appointment.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the coordination of a real estate transaction as taught in Malanga in view of Arriaga to incorporate means for coordinating property viewings and notifying buyers of confirmed appointments; as taught in Vaynshteyn with the motivation of coordinating communication between a buyer and seller for facilitating engaging in a real estate transaction. (Vaynshteyn paragraphs 40-41)
Malanga in view of Arriaga and Vaynshteyn does not teach or suggest means for generating offers, including comparable price opinions and repair cost estimates;
However, Alongi, which is directed to automated generation of a property value, teaches means for generating offers, including comparable price opinions and repair cost estimates; (Alongi paragraph 8 teaching application programming interface (API) integrations 18 can include, for example, SendGrid e-mail delivery service, Twilio cloud communications platform and/or other API integrations services. A management platform 19 can be implemented using VueJS progressive web apps (PWA), Sassy cascading style sheets and a webpack module bundler and/or other similar technology. API integrations 18 allows access of a database that includes property information and property sale information that can be used to calculate property values based on comparable properties and differences in comparable properties that result in adjustments of property values calculated using comparable properties. Alongi paragraphs 15-16 teaching in a block 37, algorithms within API integrations 18 (shown in FIG. 1), calculates a property value based on comparable properties and taking into account itemized priced adjustments based on the user information provided by the user in block 33. In a block 38, machine learning algorithms 20 (shown in FIG. 1), analyzes the photos uploaded in block 36. Machine learning algorithms 20 extracts information about the condition of the subject property from the photos and uses the information extracted from the photos along with the user information provided by the user in block 33 to produce recommendations for repairs and upgrades that will bring a user return upon the investment. Alongi paragraphs 23-28 teaching once the deep learning has been utilized to detect current materials, styles and conditions of materials for flooring, countertops, cabinets and so on, a database is accessed to determine, for the geographic location, for the price range of property and so on, how repairs or upgrades (i.e., changes in materials/styles/conditions) will affect the value of the property. The database also includes estimated costs for each repair or upgrade. For any possible change or upgrade, when the improvement in value of the property exceeds the cost to make the improvement by a predetermined threshold, a recommendation for repair or upgrade is made. In a block 39, a unique uniform resource locator (URL) is created to display information about the subject property including comparable properties with itemized adjustments in value between the subject property and each comparable property. Also displayed are recommendations for repairs and/or upgrades based on the recommendations produced in block 38. The recommendations for repairs and/or upgrades include, for example, estimates on how much increase in potential value of the subject property would result from the recommended repairs and/or upgrades. In a block 40, the process is complete. FIGS. 5A through 5G illustrates results of automated housing value generation being presented to a user in accordance with an implementation. The results can be provided on a single web page, or multiple web pages. In FIG. 5A, a section 51 provides information about the subject property and information about an associated agent. A section 52 provides information about market trends. In FIG. 5B, a section 53 provides information about features of the subject property. A section 54 introduces comparable properties. In FIG. 5C, a section 55 provides mapping and photo information about comparable properties. A section 56 provides information about a specific comparable property. In FIG. 5D, a section 57 provides additional information about the specific comparable property. In FIG. 5E, a section 58 provides additional information about the specific comparable property including other amenities and upgrades. A section 59 shows comparison made between the subject property and the comparable property or properties. The comparison includes adjusted values for such things as condition, square footage, street location and time since sale. In FIG. 5F, a section 60 displays an estimated value of the subject property as well as upgrade recommendations and a potential added value for each upgrade recommendation.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the coordination of a real estate transaction including creation of templates of documents related to offers to buy that can be populated as taught in Malanga (Malanga paragraphs 49, 56, and 92) in view of Arriaga and Vaynshteyn to incorporate means for generating offers, including comparable price opinions and repair cost estimates as taught in Alongi with the motivation of incorporating assessment of the valuation of the property in view of comparables and possible repairs for facilitating decision making of user related to a purchase of a property. (Alongi paragraphs 1, 8, and 24-25)
Referring to claim 2,
Malanga further teaches wherein the LLM is fine-tuned on real estate terminology and contractual language to offer clear explanations to buyers. (Malanga paragraph 63 teaching In some embodiments, depending on the stages of the workflow, the Event Driven Workflow module 108 may invoke one or more corresponding components of the system 100 as needed by the workflow. For example, in some embodiments, the compliance review system 100 may include various AI components such as a Document Automation AI 110, a Risk Analysis AI 112, and/or a Chatbot AI 114. These AI components may utilize one or more AI or data processing techniques 116, such as machine learning (ML), large language models (LLMs), optical character recognition (OCR), natural language processing (NLP), and so forth. These AI or data processing techniques may be integrated into one or more particular applications associated with the system. For example, NLP and/or an LLM can be used to summarize a freeform document such as an inspection report. These AI components or models may be trained on, or fine-tuned based on, data specific to real estate transactions. In some embodiments, AI components can utilize retrieval augmented generation (RAG) techniques to improve the performance, accuracy, etc., of AI components. In some embodiments, these AI components may be used together or integrated. Malanga paragraph 105 teaching In some embodiments, once the TC has uploaded at least one document, the compliance review system may scan the document to determine whether the document can be approved by the system or the document needs to be reviewed by a human Auditor. In some embodiments, the system may utilize optical character recognition (OCR), machine learning (ML), artificial intelligence (AI), large language models (LLMs), and/or natural language processing (NLP) techniques to scan, determine the contents of, and/or identify certain features (e.g., signatures) in the document. One or more of these techniques may be used together in order to automate the reading and processing of documents. For instance, AI may be used in order to determine if a particular document has the right information (e.g., the appropriate fields are filled in and those fields are filled in correctly), that the proper signatures are provided (e.g., the signatures correspond to the correct person, the signatures are in the proper format such as electronic/wet in compliance with jurisdictional rules, and so forth), and that any changes to the form are accounted for. Malanga paragraph 107 teaching in some embodiments, the document processing AI may be able to perform OCR on scanned documents. The AI may be able to process the contents of those documents using NLP, an LLM, etc., and identify the content within those documents that is needed for auditing, extract data from that content, and present that data where/when auditors may need it within the workflows described herein. The document processing AI may also be able to process content within communications (such as email, chat, comments, audit summaries, canned responses), extract any relevant data, and then present that data where/when auditors may need it within the workflow described herein. For example, the system may provide to auditors a dashboard that displays notifications and alerts for missing or incorrect documents or missing/incorrect data within a particular document.)
Referring to claim 3,
Malanga further teaches wherein the RAG module dynamically augments information retrieval from multiple sources, including real-time market data feeds, geospatial data, public records, and community-sourced information. (Malanga paragraph 63 teaching these AI components or models may be trained on, or fine-tuned based on, data specific to real estate transactions. In some embodiments, AI components can utilize retrieval augmented generation (RAG) techniques to improve the performance, accuracy, etc., of AI components. In some embodiments, these AI components may be used together or integrated. Some implementations herein can make use of retrieval augmented generation (RAG). RAG is a technique used in natural language processing and other machine learning tasks to enhance the quality and relevance of the outputs of a model (e.g., a summary, an explanation, etc.). In RAG, a retrieval model is first used to retrieve relevant information or context from a large corpus of text. This retrieved information can be used as an input to another model, for example, a generative large language model. The output of this model can be based at least in part on the retrieved contextual information. By incorporating a retrieval step, a generative model can provide more accurate and contextually appropriate outputs. Malanga paragraphs 153-154 teaching RAG can be particularly useful in tasks such as answering questions, summarizing text, and engaging in dialogs, where contextual information can be critical. RAG can help overcome some limitations of pure generative models, which can be susceptible to generating irrelevant or nonsensical responses (colloquially referred to as hallucinations). As an example, language used in real estate transactions can have specific meanings within the context of real estate. For example, a term such as “zone” can have various meanings, but in the context of real estate, generally refers to the types of uses for which a piece of land can be used. As another example, the term “title” can refer to a title bestowed on an individual, a name or heading of a document or movie, etc. However, in the context of real estate transactions, title has a specific meaning as a legal instrument. These are merely examples. It will be appreciated that there can be many terms that have specific meanings in the context of real estate transactions. RAG is not limited to merely addressing differences in the meaning of terms. RAG can provide broader contextual information, providing important cues, background information, references, and so forth.)
Referring to claim 4,
Malanga further teaches, wherein the system provides hyper-personalized property analysis by combining MLS data, buyer preferences, and historical search patterns to generate property insights and market trend assessments. (Malanga paragraph 73 teaching in some embodiments, the compliance review system 100 may include an Activity Logging module 124 that tracks and keeps a historical log of all activity performed by the TCs 154, the Auditors 152, the system itself, and/or other actors during the compliance review process. In some embodiments, the Activity Logging module 124 may track product metrics in order to improve understanding of how TCs, Auditors, and other users interact with the system. Malanga paragraphs 91-92 teaching many of the operations described with respect to FIGS. 3A-3H can be automated, for example using machine learning models, natural language processing, optical character recognition, etc. Some operations can be partially or fully automated by pulling data from authoritative sources such as property records, postal records, MLS data, and so forth. In some embodiments, automated review systems can identify potential errors, omissions, and so forth. FIG. 3I is a flowchart that illustrates an example process flow that uses automated data population and automated compliance review according to some embodiments. At operation 380, a system can recent property information from an agent. For example, an agent can submit information about a new property that is for sale. At operation 382, the system can receive a selection of a TC team. In some embodiments, the agent can select a TC team. In some embodiments, a TC team can be selected by the system, for example as described herein. At operation 384, the system can populate coversheet information, which can include basic information about the listing (e.g., property address, listing price, square footage, number of bedrooms, number of bathrooms, school district, etc.). In some embodiments, the system can populate the coversheet information based on information supplied by an agent of TC. In some embodiments, the system can advantageously automatically populate the coversheet information based on, for example, data retrieved from one or more data sources, such as MLS listings. In some embodiments, information can be automatically populated based on, for example, the property location (which can indicate, for example, school district), previous transactions, or any other source of information. At operation 386, the system can determine a closing timeline. For example, the system can determine a closing timeline with various events based on, for example, the location of the property. In some embodiments, a user may be able to modify the timeline. At operation 388, the system can send the closing timeline to a client. In some embodiments, the system can send calendar invitations, reminders, and/or the like to the client, which can help reduce the likelihood of important dates being missed, which could delay closing. At operation 390, the system can schedule the sending of documents. For example, the system can automatically send electronic documents for signature based on the closing timeline.)
Referring to claim 6,
Malanga further teaches wherein the system performs advanced document understanding by parsing inspection reports, counteroffers, and addendums, summarizing critical findings, translating jargon, and flagging potential red flags. (Malanga paragraph 91 teaching many of the operations described with respect to FIGS. 3A-3H can be automated, for example using machine learning models, natural language processing, optical character recognition, etc. Some operations can be partially or fully automated by pulling data from authoritative sources such as property records, postal records, MLS data, and so forth. In some embodiments, automated review systems can identify potential errors, omissions, and so forth. Malanga paragraph 139 teaching Ensuring compliance can be a daunting task, and it can be economically infeasible to engage in human review of all documents related to a real estate listing or transaction. Moreover, human reviewers can be prone to errors, especially when confronted with large volumes of documents where errors may be hard to find and/or easy to overlook. However, the presence of errors in documents can compromise a listing or transaction, result in legal risk, and so forth. Thus, it is important to identify errors in documents relating to real estate listings and transactions. Malanga paragraphs 144-145 teaching in some embodiments, some documents can be routed for manual review. For example, as described herein, in some embodiments, documents can be routed for manual review when an automatic system review fails or achieves an indeterminate result (e.g., confidence below a threshold amount). In some embodiments, certain documents can be automatically routed for human review without regard to the results of an automatic system review and, in some cases, without the occurrence of an automatic system review. For example, if there is a simple exception (e.g., confirming an address or verifying a signature), a system can route a document for human review after performing automatic system review. In some embodiments, the human reviewer can modify extracted values or accept extracted values. Human review without automatic system review or regardless of the automatic system review can be indicated when, for example, a document contains an unusual addendum, free text, etc., in which case a human may review the document and determine any actions to be taken based on the contents of the document. Automated review can have many benefits. For example, automated review can save substantial time and expense, reduce errors, and so forth. However, automated systems can be prone to errors. For example, when an LLM is used for summarizing freeform text, the LLM may inaccurately summarize the text, omit important information, and so forth. OCR methods may make errors when extracting values, for example mixing up the letter “O” and the number “0,” the letter “I” and the number “1,” and so forth. In some cases, such issues may be especially pronounced when a document is handwritten or written in a font that lacks consistent spacing, well-defined, and differentiated letterforms, etc. Accordingly, it can be important to conduct reviews of automated review processes to ensure that the results are reliable and correct. Malanga paragraphs 152-154 teaching some implementations herein can make use of retrieval augmented generation (RAG). RAG is a technique used in natural language processing and other machine learning tasks to enhance the quality and relevance of the outputs of a model (e.g., a summary, an explanation, etc.). In RAG, a retrieval model is first used to retrieve relevant information or context from a large corpus of text. This retrieved information can be used as an input to another model, for example, a generative large language model. The output of this model can be based at least in part on the retrieved contextual information. By incorporating a retrieval step, a generative model can provide more accurate and contextually appropriate outputs. RAG can be particularly useful in tasks such as answering questions, summarizing text, and engaging in dialogs, where contextual information can be critical. RAG can help overcome some limitations of pure generative models, which can be susceptible to generating irrelevant or nonsensical responses (colloquially referred to as hallucinations). As an example, language used in real estate transactions can have specific meanings within the context of real estate. For example, a term such as “zone” can have various meanings, but in the context of real estate, generally refers to the types of uses for which a piece of land can be used. As another example, the term “title” can refer to a title bestowed on an individual, a name or heading of a document or movie, etc. However, in the context of real estate transactions, title has a specific meaning as a legal instrument. These are merely examples. It will be appreciated that there can be many terms that have specific meanings in the context of real estate transactions. RAG is not limited to merely addressing differences in the meaning of terms. RAG can provide broader contextual information, providing important cues, background information, references, and so forth.)
Referring to claim 7,
Malanga further teaches wherein the system provides proactive, context-sensitive communication by generating polished correspondence templates, maintaining communication trails, and suggesting context-aware questions and reminders for various transaction stages. (Malanga paragraph 56 teaching in some embodiments, these documents can be stored in the Transaction Database 130 along with any other relevant information about that transaction. However, it should be noted that these documents do not necessarily need to be furnished by the TCs 154 or the auditors 152. For instance, in some embodiments, the system 100 can provide the documents (e.g., templates) to the TCs 154 to fill out instead of requiring that the documents be prepared and uploaded by the TCs 154. Malanga paragraphs 67-69 teaching in some embodiments, large language models (LLM) calibrated to perform particular tasks may be used. An LLM fine-tuned on real estate transactions may be integrated, along with the Document Automation AI 110 and/or the Risk Analysis AI 112 into a conversational AI such as Chatbot AI 114, which can be used to carry out various tasks associated with the compliance review workflow. For instance, an auditor 152 may be able to converse with the Chatbot AI 114 and request that it check to see if a set of documents are properly signed. The system 100 may be able to retrieve the set of documents from the Transaction Database 134 and apply the Document Automation AI 110 and/or the Risk Analysis AI 112 to verify that the documents are properly signed, and then the Chatbot AI 114 may be able to accurately convey that information back to the auditor 152 in the conversation. In some embodiments, the compliance review system 100 may include an AI Feedback module 118 that serves to implement a feedback loop for honing, training, and fine-tuning the various AI components of the compliance review system 100 that enable automation of the compliance review process. In some embodiments, the updating of these various AI components may be based on observed human decision-making and/or data collected by the Activity Logging module 124. In some embodiments, the compliance review system 100 may include a Transaction Database 130 that is used to store data associated with each transaction. For example, all the documents uploaded to the compliance review system 100 in the course of performing the compliance workflow on a transaction may be stored in the Transaction Database 130. Data for a transaction may, additionally or alternatively, be stored with a transactional email address along with any communication and attachments sent to the address, which can be made available to the TCs 154 and the auditors 152. In some embodiments, documents may not be stored in the transaction database 130. For example, in some embodiments, document files can be stored on a disk, in cloud storage (e.g., a cloud storage bucket), etc. In some embodiments, the transaction database 130 can include information about files, metadata, etc. For example, in some embodiments, the transaction database 130 can store information indicating where a corresponding file can be found. In some embodiments, the compliance review system 100 may include a Rules Database 132 that contains sets of rules for various jurisdictions that transactions may take place in. A particular jurisdiction may be associated with one or more sets of rules, and the specific ruleset that is utilized by the compliance review system 100 may depend on the nature of the transaction and the property. In some embodiments, the compliance review system 100 may include a Rules Engine 120 that may be used to generate and determine the checklists that are stored in the Checklist Database 134. The Rules Engine 120 may evaluate certain data points about a property or transaction and, if present, automatically change certain checklist items from “optional” to “required.” Thus, the transactions for a particular jurisdiction may be further subject to different checklists and checklist items. In some embodiments, the compliance review system 100 can receive property information and can automatically determine, for example, a specific ruleset to use based on the property location, property type (e.g., condominium, apartment, co-op, single family home, single family home in a planned development, etc.), and/or any other relevant information. Malanga paragraph 76 teaching in a requirements review flow, the system can receive from the auditor an indication of whether or not a particular checklist is a correct checklist. If, at operation 248, the checklist is not correct (or there is no checklist attached to the transaction), the system can receive an indication or selection of a correct checklist at operation 250. The system can, at operation 252, update a list of required documents for the checklist. For example, a checklist may be a correct checklist, but the auditor may wish to modify the checklist to require certain documents or to not require certain other documents. If, at operation 248, the checklist is the correct checklist, the system can proceed to operation 252. At operation 254, the system can provide a notification to a TC, which can indicate that a checklist has been reviewed and/or modified, for example by adding or removing a required and/or optional document. Malanga paragraph 86 teaching the action items can indicate outstanding items on a checklist. At operation 348, the system can update the checklist based on the uploaded document. For example, if a lead paint disclosure was missing and the user submitted a lead paint disclosure, the system can mark the lead paint disclosure checklist item as complete, pending review, etc. The status can depend upon whether or not the document was automatically accepted or will only potentially be accepted after at least partially manual review. For example, in some embodiments, as described herein, a document can be automatically accepted if the document is associated with a risk level below a threshold amount. Malanga paragraphs 92-93 teaching at operation 386, the system can determine a closing timeline. For example, the system can determine a closing timeline with various events based on, for example, the location of the property. In some embodiments, a user may be able to modify the timeline. At operation 388, the system can send the closing timeline to a client. In some embodiments, the system can send calendar invitations, reminders, and/or the like to the client, which can help reduce the likelihood of important dates being missed, which could delay closing. At operation 390, the system can schedule the sending of documents. For example, the system can automatically send electronic documents for signature based on the closing timeline. At operation 392, the system can automatically review the coversheet information to determine the completeness, correctness, or both of the coversheet information. FIGS. 4A and 4B show transaction coordinator-side user interfaces 400 of a compliance review system according to some embodiments. FIG. 4A shows a user interface view showing a checklist with associated checklist items. Each checklist item can have an icon indicating if a document has been uploaded, an icon indicating if a comment has been added, a status, and/or functionality to access one or more options, such as changing an item from required to optional, removing an item, etc. The user interface can include various tabs that can display, for example, action items, unassigned documents (e.g., documents not assigned to a specific checklist item), and/or an audit log. Malanga paragraphs 153-154 teaching RAG can be particularly useful in tasks such as answering questions, summarizing text, and engaging in dialogs, where contextual information can be critical. RAG can help overcome some limitations of pure generative models, which can be susceptible to generating irrelevant or nonsensical responses (colloquially referred to as hallucinations). As an example, language used in real estate transactions can have specific meanings within the context of real estate. For example, a term such as “zone” can have various meanings, but in the context of real estate, generally refers to the types of uses for which a piece of land can be used. As another example, the term “title” can refer to a title bestowed on an individual, a name or heading of a document or movie, etc. However, in the context of real estate transactions, title has a specific meaning as a legal instrument. These are merely examples. It will be appreciated that there can be many terms that have specific meanings in the context of real estate transactions. RAG is not limited to merely addressing differences in the meaning of terms. RAG can provide broader contextual information, providing important cues, background information, references, and so forth.)
Referring to claim 8,
Malanga further teaches wherein the system allows buyers to upload or enter search parameters such as property type, location, number of bedrooms, and other preferences. (Malanga paragraphs 79-80 teaching in some embodiments, the system requests preliminary information (“cover sheet information”) about the property to be listed from the TC, such as the year the property was built, if there will be tenants, the type of deal, the commission to be offered (e.g., as a percentage), and any HOA options. In some embodiments, the system gives the TC the option to select one or more applicable jurisdictions. In some embodiments, the system automatically selects one or more applicable jurisdictions based on, for example, the location of the property (e.g., per the address input by the TC) and/or any special features of the property (e.g., includes solar panels). In some embodiments, the system displays the checklist of compliance requirements. In some embodiments, the system may also display, under each checklist item, a list of acceptable types of documents that may satisfy any given compliance requirement. In some embodiments, the system provides the TC with the option to filter the checklist based on the locality of the transaction property, property type, and/or other factors. Malanga paragraph 92 teaching at operation 384, the system can populate coversheet information, which can include basic information about the listing (e.g., property address, listing price, square footage, number of bedrooms, number of bathrooms, school district, etc.). In some embodiments, the system can populate the coversheet information based on information supplied by an agent of TC. In some embodiments, the system can advantageously automatically populate the coversheet information based on, for example, data retrieved from one or more data sources, such as MLS listings. In some embodiments, information can be automatically populated based on, for example, the property location (which can indicate, for example, school district), previous transactions, or any other source of information.)
Referring to claim 9,
Vaynshteyn further teaches wherein the system prompts buyers to upload a bank pre-qualification letter or proof of funds and provides options for preferred lenders if needed.
(Vaynshteyn paragraph 29 teaching an interface may be used to prompt users 101(a) and 101(b) to transmit information from computing unit through a distributed computer network 103 to a server 104. In one embodiment, the interface provided is in the form of a webpage accessed from a remotely located server, through a browser. In another embodiment, the interface is in the form of a locally accessed software application, stored in the memory of the computing unit. The user may be prompted by either interface to create an account, that requires a flat fee. The account may store information that comprised of: seller data, buyer data, vendor data, contact information, financial data, property information, or any combination thereof. The system may further require users to create a profile, that is displayed to other users of the system. An account must be made to provide access of users 101(a) and 101(b) to server 104 via the distributed computer network 103. The distributed computer network 103 may comprise of multiple computing devices connected through any system including a LAN, WAN, intranet system or through the internet. Vaynshteyn paragraph 31 teaching a database of all input information from potential clients 101(a), 101(b) and real estate related professionals 105 may be stored on server 104 (or multiple servers as the case may be). There may be at least three distinct databases, containing offer data, buyer data and real estate related data. Server 104 may additionally have a set of programmed instructions to extract key information into the data deposited by users 101(a), 101(b), and 105 in the database. Vaynshteyn paragraph 44 teaching the negotiations may also include other terms such as specific requirements from either buyer or seller 201. For example, a seller may require proof of funds or a pre-qualification letter to further negotiations. A buyer, may for example require a home inspection or any other structural work to be carried out first prior to advancing negotiations. As such the seller and buyer may continue negotiating until a both parties are sufficiently satisfied 210. Vaynshteyn paragraphs 46-47 teaching in one embodiment, the buyer or seller may request a specific real estate related professional from the database 209, to be used as a part of the initial terms of transaction. In an alternate embodiment, an external real estate related professional (one not found in database 209) may be designated to perform the work set forth in the initial terms of transaction, provided that both parties agree to an external service provider being used to conduct the work. Upon fulfilling the requirements of the initial terms of transaction, the buyer or seller may deposit the information into their accounts through the webpage interface. The results of the actions may be reviewed by the other party and further negotiations 213 may take place. For example, if the home inspection requested by the buyer, shows that there are deficiencies that must be fixed, the buyer may then request that the seller 201 fix the identified issues before further negotiations are held.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the coordination of a real estate transaction as taught in Malanga in view of Arriaga and Alongi to incorporate wherein the system prompts buyers to upload a bank pre-qualification letter or proof of funds and provides options for preferred lenders if needed as taught in Vaynshteyn with the motivation of facilitating transactions by providing financial information regarding the buyer. (Vaynshteyn paragraphs 29 and 44)
Referring to claim 10,
Arriaga further teaches wherein the system scrubs multiple real estate websites to find properties matching the buyer’s criteria and presents potential matches for review. (Arriaga paragraph 40 teaching with continued reference to FIG. 1, dataset 120 may be retrieved using a web crawler. A “web crawler,” as used herein, is a program that systematically browses the internet for the purpose of Web indexing. The web crawler may be seeded with platform URLs, wherein the crawler may then visit the next related URL, retrieve the content, index the content, and/or measures the relevance of the content to the topic of interest. In some embodiments, computing device 104 may generate a web crawler to compile dataset 120. The web crawler may be seeded and/or trained with a reputable website, such as government websites. A web crawler may be generated by computing device 104. In some embodiments, the web crawler may be trained with information received from a user through a user interface. In some embodiments, the web crawler may be configured to generate a web query. A web query may include search criteria received from a user. For example, a user may submit a plurality of websites for the web crawler to search to extract any data suitable for dataset 120. Arriaga paragraph 133 teaching with continued reference to FIG. 1, the unified dashboard and/or content hub may include a personalized content feed. As used in this disclosure, a “personalized content feed” is a dynamic feature of a digital platform that curates and displays content tailored to an individual user's preferences, behaviors, and/or interests. In a non-limiting example, the personalized content feed may be accessed from within a client portal and/or a mobile app. In a non-limiting example, the personalized content feed may be configured to deliver tailored articles, videos, and educational resources based on each client's specific needs, interests, and risk profile. Continuing the non-limiting example, the personalized content feed previously mentioned may assist the client in making informed decisions about the client's insurance and risk management strategies. For example, without limitation, apparatus 100 may utilize a web crawler to collect content for the personalized content feed. As used in this disclosure, a “web crawler” is a program that systematically browses the internet for the purpose of Web indexing. In a non-limiting example, the web crawler may be seeded with platform URLs, wherein the web crawler may then visit the next related URL, retrieve the content, index the content, and/or measures the relevance of the content to the topic of interest. In some embodiments, processor 108 may generate the web crawler to compile the training data with uploaded data. In a non-limiting example, the web crawler may be seeded and/or trained with a reputable website to begin the search. In another non-limiting example, the web crawler may be trained using a list of target websites and courses that provide relevant and high-quality content such as financial news websites, insurance blogs, real estate platforms, educational portals, and the like. In another non-limiting example, the web crawler may be generated by a processor 108. In some embodiments, the web crawler may be trained with information received from a user through a graphical user interface. In some embodiments, the web crawler may be configured to generate a web query. For example, without limitation, a web query may include search criteria received from a user. For example, a user may submit a plurality of websites for the web crawler to search to extract entity records, inventory records, pricing records, product records, customer records, financial transaction records, customer feedback and review records, and the like. Arriaga paragraph 153 in some cases, gap finder module 156 may receive elements within modified dataset 144 and/or target data 124 and make calculations using an arithmetic logic unit within computing device 104. In some cases, gap finder module 156 may calculate the value of a user's assets, the total policy limits, the protection of the limits and the like. In some cases, gap finder module 156 may further calculate insurance coverages associated with the asset and make determinations as a function of the calculations. For example, processor 108 may calculate or determine that a particular asset is worth 10,000$ but the insurance coverage on the asset only covers 8,000$. In some cases gap finder module 156 may include web crawlers, wherein the web crawler may be configured to parse the internet for pricing of assets indicated within target data 124. For example, web crawler may be configured to retrieve an estimate of the target's property using estimates from one or more property websites. Similarly, web crawler may be configured to search the web for the price of the target's vehicles, assets, and the like. Gap finder module 156 may then be configured to compare the price of the assets to the current insurance coverage on the asset. In some cases, gap finder module 156 may determine that a particular asset within target data 124 does not contain any insurance coverage based on a lack of coverage indicated within target data 124, wherein gap finder module 156 may output a protection gap 152 indicating a lack of coverage. The Examiner is interpreting that Arriaga suggests the use of user’s criteria/preferences for identifying properties of interest for display to the user through the use of a web-crawler.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the coordination of a real estate transaction as taught in Malanga in view of Vaynshteyn and Alongi to incorporate wherein the system scrubs multiple real estate websites to find properties matching the buyer’s criteria and presents potential matches for review as taught in Arriaga with the motivation of identifying properties meeting a user’s criteria based on the determined relevancy. (Arriaga paragraphs 133 and 153)
Referring to claim 11,
Vaynshteyn further teaches wherein the system coordinates property viewings by contacting sellers/sellers' agents and notifying buyers of confirmed appointments. (Vaynshteyn paragraphs 40-42 teaching if a buyer is interested in the listed property by seller 201, information regarding the buyer is presented to the seller. The information presented to the seller 201 may be the profile of the buyer, which may comprise: contact details and financial information. In the preferred embodiment, the seller is presented with a profile comprising of the name, email address, and credit score of each interested buyer. The buyer may be presented with an option to send the property profile to a third party, such as a friend or another party interested in purchasing a property. If the third party does not already have an existing account, they may be prompted to sign up to an account to access the contact information of the seller. Upon presentation of the profiles of the interested parties to the property, the seller 201 may then decide if they are interested in any parties presented 206. If the seller 201 is interested in a buyer, the two parties are connected by providing both parties with the seller and buyer profiles. The seller 201 is able to select multiple buyers to engage with. If the seller is not interested in the buyer, they are able to reject the buyer or ignore the buyer. If the seller is not interested in any presented buyers, the seller is able to return to process 204, which will present any new interested parties. Additionally, a time limit on decision 206 may be applied, on the action of the buyer or seller, after which the offer to connect is considered to be rejected. The seller 201 and buyer may be connected 207, in one embodiment through an email system. Whilst, in another embodiment, the method of contact is through direct messaging. In a further embodiment, the method of contact is through telephone. During the first contact between a seller and buyer, the two parties may set up a date and time to view the property 208. The decision for a time and date to view the property in one embodiment may be facilitated though the use of a calendar scheduling service provided through the interface. The number of visits a property gains may be stored in the system and displayed to potential buyers through the profile of the property. The Examiner is interpreting that Vaynshteyn provides for a system that coordinates communications between a buyer and seller and suggests the buyer’s receiving a notification regarding the confirmation of scheduling a viewing appointment.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the coordination of a real estate transaction as taught in Malanga in view of Arriaga and Alongi to incorporate wherein the system coordinates property viewings by contacting sellers/sellers' agents and notifying buyers of confirmed appointments as taught in Vaynshteyn with the motivation of coordinating communication between a buyer and seller for facilitating engaging in a real estate transaction. (Vaynshteyn paragraphs 40-41)
Referring to claim 12,
Alongi further teaches wherein the system provides a comparable price opinion based on recent sales data and highlights potential property issues with estimated repair costs. (Alongi paragraph 8 teaching application programming interface (API) integrations 18 can include, for example, SendGrid e-mail delivery service, Twilio cloud communications platform and/or other API integrations services. A management platform 19 can be implemented using VueJS progressive web apps (PWA), Sassy cascading style sheets and a webpack module bundler and/or other similar technology. API integrations 18 allows access of a database that includes property information and property sale information that can be used to calculate property values based on comparable properties and differences in comparable properties that result in adjustments of property values calculated using comparable properties. Alongi paragraphs 15-16 teaching in a block 37, algorithms within API integrations 18 (shown in FIG. 1), calculates a property value based on comparable properties and taking into account itemized priced adjustments based on the user information provided by the user in block 33. In a block 38, machine learning algorithms 20 (shown in FIG. 1), analyzes the photos uploaded in block 36. Machine learning algorithms 20 extracts information about the condition of the subject property from the photos and uses the information extracted from the photos along with the user information provided by the user in block 33 to produce recommendations for repairs and upgrades that will bring a user return upon the investment. Alongi paragraphs 23-28 teaching once the deep learning has been utilized to detect current materials, styles and conditions of materials for flooring, countertops, cabinets and so on, a database is accessed to determine, for the geographic location, for the price range of property and so on, how repairs or upgrades (i.e., changes in materials/styles/conditions) will affect the value of the property. The database also includes estimated costs for each repair or upgrade. For any possible change or upgrade, when the improvement in value of the property exceeds the cost to make the improvement by a predetermined threshold, a recommendation for repair or upgrade is made. In a block 39, a unique uniform resource locator (URL) is created to display information about the subject property including comparable properties with itemized adjustments in value between the subject property and each comparable property. Also displayed are recommendations for repairs and/or upgrades based on the recommendations produced in block 38. The recommendations for repairs and/or upgrades include, for example, estimates on how much increase in potential value of the subject property would result from the recommended repairs and/or upgrades. In a block 40, the process is complete. FIGS. 5A through 5G illustrates results of automated housing value generation being presented to a user in accordance with an implementation. The results can be provided on a single web page, or multiple web pages. In FIG. 5A, a section 51 provides information about the subject property and information about an associated agent. A section 52 provides information about market trends. In FIG. 5B, a section 53 provides information about features of the subject property. A section 54 introduces comparable properties. In FIG. 5C, a section 55 provides mapping and photo information about comparable properties. A section 56 provides information about a specific comparable property. In FIG. 5D, a section 57 provides additional information about the specific comparable property. In FIG. 5E, a section 58 provides additional information about the specific comparable property including other amenities and upgrades. A section 59 shows comparison made between the subject property and the comparable property or properties. The comparison includes adjusted values for such things as condition, square footage, street location and time since sale. In FIG. 5F, a section 60 displays an estimated value of the subject property as well as upgrade recommendations and a potential added value for each upgrade recommendation.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the coordination of a real estate transaction as taught in Malanga in view of Arriaga and Vaynshteyn to incorporate wherein the system provides a comparable price opinion based on recent sales data and highlights potential property issues with estimated repair costs as taught in Alongi with the motivation of incorporating assessment of the valuation of the property in view of comparables and possible repairs for facilitating decision making of user related to a purchase of a property. (Alongi paragraphs 1, 8, and 24-25)
Referring to claim 13,
Vaynshteyn further teaches, wherein the system allows buyers to input offer details, including price, deposit, inspection requirements, and attorney information, and recommends local professionals if needed. (Vaynshteyn paragraph 12 teaching the invention in one embodiment is a computer network implemented method for performing real estate transactions in a peer to peer manner comprising of: receiving and storing data, wherein the data is comprised of information related to an offer to sell or lease a real estate property (offer data). Preferably the data received and stored may comprise of, personal information, financial information, nature of transaction, location of property, listing price of property, photographs of property, and structural information on property; receiving and storing data, wherein the data is comprised of information related to an interest in buying or renting a real estate property (buyer data); wherein data received and stored may comprise of: personal information, financial information, nature of transaction, location of a desired property, price range of a desired property, structural information on a desired property, and local information on a desired property; compiling a list, comprising of potential matches between sellers and buyers, or lessors and lessees ranked by the information extracted from offer data and buyer data; connecting a perspective buyer and seller, or lessor and lessee; providing a database of real estate related professionals to seller and buyer, or lessor and lessee; and connecting the interested parties. The methods of connecting interested parties may be through email, mail, instant messages, short messaging service (SMS), or phone calls. In another embodiment, the method may also contain a step which comprises of contacting third parties to confirm accuracy of data input from seller, buyer, tenant, or landlord. In another embodiment, a step comprising of confirming the financial status of a buyer or tenant with a third party prior to connection of two interested parties is also present. Vaynshteyn paragraphs 30-32 teaching in environment 100, only a single server is illustrated, however, multiple servers may be used for storage and processing needs. Real estate related professionals 105 comprising of legal service providers, escrow service providers, interior designers, contractors, architects, moving companies, furniture providers, and property managers, may also input data to be stored in the memory of server 104. The data is communicated to the server using a computing device 106 via the computer network 103. In one embodiment, the interface for input of a service provider data may be in the form of a website. In another embodiment in the form of a locally accessed software application, stored in the memory of the computing unit. The interface used by real estate related professionals 105 may take a different from to that provided to users 101(a) and 101(b). A database of all input information from potential clients 101(a), 101(b) and real estate related professionals 105 may be stored on server 104 (or multiple servers as the case may be). There may be at least three distinct databases, containing offer data, buyer data and real estate related data. Server 104 may additionally have a set of programmed instructions to extract key information into the data deposited by users 101(a), 101(b), and 105 in the database. Limited access to each database may be provided by the server, dependent on where the query originates. If the query is from a buyer 101(b), only information submitted by a seller 101(a) or service provider 105 is provided. If the query is from a seller 101(a), only buyer 101(b) or service provider 105 information is provided. Queries to the database from a service provider may not be answered unless permission from either seller 101(a) or buyer 101(b) is first obtained. The server may also contain instructions to analyse data to match perspective parties based on information extracted from input data. In one embodiment, matches may be limited using location as the primary parameter, followed by price. Vaynshteyn paragraphs 44-47 teaching the negotiations may also include other terms such as specific requirements from either buyer or seller 201. For example, a seller may require proof of funds or a pre-qualification letter to further negotiations. A buyer, may for example require a home inspection or any other structural work to be carried out first prior to advancing negotiations. As such the seller and buyer may continue negotiating until a both parties are sufficiently satisfied 210. If a preliminary terms of transaction is not reached and a party does not wish to continue, the seller and buyer may be directed back to process 204. Any negotiations performed through a traceable medium, such as messenger or email may be stored, in the database associated with the buyer and seller, and may be accessed any time by either party. If a preliminary terms of transaction is reached 211, these terms are set and both parties must complete the required tasks to advance negotiations 212. Upon acceptance of the initial terms of the transaction 211, the property may be removed from the database of property listings. A time limit on performing these set of actions may be set by either seller 201 or buyer, after which if the actions have not been satisfactorily achieved, the negotiations may be cancelled. The seller is able to access and hire the real estate related professionals stored in database 209, to fulfil any requirements set forth in the initial terms of transaction. The real estate related professionals may include: contractors, home inspectors and attorneys. In one embodiment, the buyer or seller may request a specific real estate related professional from the database 209, to be used as a part of the initial terms of transaction. In an alternate embodiment, an external real estate related professional (one not found in database 209) may be designated to perform the work set forth in the initial terms of transaction, provided that both parties agree to an external service provider being used to conduct the work. Upon fulfilling the requirements of the initial terms of transaction, the buyer or seller may deposit the information into their accounts through the webpage interface. The results of the actions may be reviewed by the other party and further negotiations 213 may take place. For example, if the home inspection requested by the buyer, shows that there are deficiencies that must be fixed, the buyer may then request that the seller 201 fix the identified issues before further negotiations are held. The seller 201 may decide to fix the issues, offer a reduction in the price, offer a warranty for work on the house, or any other option. This negotiation 213 may lead to further actions being required, as in the provided example, and as such would lead back to process 212. The database 209 may be used to identify and hire a real estate related professional to carry out any required work (e.g an attorney to draft or review an agreement between the parties). The process may loop between 212 and 213 until both parties are satisfied leading to a refined terms of transaction being set 215, or one party withdraws from negotiations, leading the process to return to 204.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the coordination of a real estate transaction as taught in Malanga in view of Arriaga and Alongi to incorporate wherein the system allows buyers to input offer details, including price, deposit, inspection requirements, and attorney information, and recommends local professionals if needed as taught in Vaynshteyn with the motivation of allowing buyers to submit various information in facilitating engaging in a real estate transaction. (Vaynshteyn paragraphs 12 and 40-41)
Referring to claim 14,
Malanga further teaches wherein the system generates a contract and associated forms, enabling electronic signatures and email notifications to relevant parties.
(Malanga paragraph 56 teaching in some embodiments, these documents can be stored in the Transaction Database 130 along with any other relevant information about that transaction. However, it should be noted that these documents do not necessarily need to be furnished by the TCs 154 or the auditors 152. For instance, in some embodiments, the system 100 can provide the documents (e.g., templates) to the TCs 154 to fill out instead of requiring that the documents be prepared and uploaded by the TCs 154. Malanga paragraph 89 teaching at operation 369, once the TC has finished entering information, the system can send one or more documents for signature to parties who need to sign. At operation 370, the system can receive an audit entry selection, for example, indicating that another user is ready to perform an audit of one or more documents. At operation 371, the system can receive a checklist selection. In response, the system can provide the checklist and outstanding audit items. At operation 372, the system can receive audit feedback, which can indicate that one or more items in a checklist require revision, are missing, etc. In some embodiments, the audit feedback may indicate that the checklist is complete. At operation 373, the system can receive a signoff indicating that the audit is complete. It will be appreciated that the audit being complete does not necessarily mean that the checklist is complete or that the documents are in condition to move forward. Malanga paragraph 92 teaching at operation 386, the system can determine a closing timeline. For example, the system can determine a closing timeline with various events based on, for example, the location of the property. In some embodiments, a user may be able to modify the timeline. At operation 388, the system can send the closing timeline to a client. In some embodiments, the system can send calendar invitations, reminders, and/or the like to the client, which can help reduce the likelihood of important dates being missed, which could delay closing. At operation 390, the system can schedule the sending of documents. For example, the system can automatically send electronic documents for signature based on the closing timeline. At operation 392, the system can automatically review the coversheet information to determine the completeness, correctness, or both of the coversheet information. At operation 392, the system can receive completed documents. For example, in some embodiments, the system can receive documents other than completed electronic documents, such as documents prepared by a bank, another agent, etc. In some embodiments, received documents can include documents that were printed and later scanned. In some embodiments, received documents can include documents with electronic signatures. In some embodiments, received documents can include documents with wet ink signatures. At operation 396, the system can automatically review the received completed documents, for example, to check for consistency, completeness, compliance with signature requirements, etc., for example, as described herein. At operation 398, the system can notify respective parties (e.g., agents, lenders, etc.) that one or more documents were rejected. The system may reject a document for a variety of reasons, such as inability to parse the document (e.g., due to poor scan quality), missing information, incorrect information, a document being an incorrect document (e.g., the wrong form was submitted), etc. The respective parties can receive notification of a rejected document and take action to correct the issue.)
Referring to claim 15,
Malanga further teaches wherein the system tracks transaction milestones with a built-in calendar and sends reminders one week before critical dates. (Malanga paragraph 92 teaching at operation 388, the system can send the closing timeline to a client. In some embodiments, the system can send calendar invitations, reminders, and/or the like to the client, which can help reduce the likelihood of important dates being missed, which could delay closing. At operation 390, the system can schedule the sending of documents. For example, the system can automatically send electronic documents for signature based on the closing timeline.)
Referring to claim 17,
Vaynshteyn further teaches wherein the system schedules the final walkthrough and notifies the buyer upon clearance for closing. (Vaynshteyn paragraph 42 teaching the seller 201 and buyer may be connected 207, in one embodiment through an email system. Whilst, in another embodiment, the method of contact is through direct messaging. In a further embodiment, the method of contact is through telephone. During the first contact between a seller and buyer, the two parties may set up a date and time to view the property 208. The decision for a time and date to view the property in one embodiment may be facilitated though the use of a calendar scheduling service provided through the interface. The number of visits a property gains may be stored in the system and displayed to potential buyers through the profile of the property. Vaynshteyn paragraphs 47-48 teaching upon fulfilling the requirements of the initial terms of transaction, the buyer or seller may deposit the information into their accounts through the webpage interface. The results of the actions may be reviewed by the other party and further negotiations 213 may take place. For example, if the home inspection requested by the buyer, shows that there are deficiencies that must be fixed, the buyer may then request that the seller 201 fix the identified issues before further negotiations are held. The seller 201 may decide to fix the issues, offer a reduction in the price, offer a warranty for work on the house, or any other option. This negotiation 213 may lead to further actions being required, as in the provided example, and as such would lead back to process 212. The database 209 may be used to identify and hire a real estate related professional to carry out any required work (e.g an attorney to draft or review an agreement between the parties). The process may loop between 212 and 213 until both parties are satisfied leading to a refined terms of transaction being set 215, or one party withdraws from negotiations, leading the process to return to 204. During process 213, a legal representative may be chosen from database 209 to review and draw up a legally binding contract for the transfer of the deed from seller to buyer. Additionally, a holding company or escrow company may be selected from database 209 to conduct the closing of the sale. Once both parties meet the requirements of the contract, the deed is transferred and the transaction is complete 217.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the coordination of a real estate transaction as taught in Malanga in view of Arriaga and Alongi to incorporate wherein the system schedules the final walkthrough and notifies the buyer upon clearance for closing as taught in Vaynshteyn with the motivation of coordinating communication between a buyer and seller for facilitating the completion of a real estate transaction. (Vaynshteyn paragraphs 40-41)
Referring to claim 19,
Malanga further teaches wherein the system emphasizes the importance of professional legal advice during critical transaction stages. (Malanga paragraph 134 teaching As described herein, real estate transactions, as well as other complex transactions, often have many forms, laws, regulations, etc., associated therewith. Legal requirements may vary from state to state, county to county, city to city, and so forth. The legal requirements may change over time. For example, there may be new disclosure requirements, new, changed, or eliminated forms, and so forth. Thus, it can be important to keep track of the requirements in different locations. However, doing so can be a daunting task. For example, there are thousands of counties in the United States, each of which may have different legal requirements, required forms, and so forth. Malanga paragraphs 152-154 teaching some implementations herein can make use of retrieval augmented generation (RAG). RAG is a technique used in natural language processing and other machine learning tasks to enhance the quality and relevance of the outputs of a model (e.g., a summary, an explanation, etc.). In RAG, a retrieval model is first used to retrieve relevant information or context from a large corpus of text. This retrieved information can be used as an input to another model, for example, a generative large language model. The output of this model can be based at least in part on the retrieved contextual information. By incorporating a retrieval step, a generative model can provide more accurate and contextually appropriate outputs. RAG can be particularly useful in tasks such as answering questions, summarizing text, and engaging in dialogs, where contextual information can be critical. RAG can help overcome some limitations of pure generative models, which can be susceptible to generating irrelevant or nonsensical responses (colloquially referred to as hallucinations). As an example, language used in real estate transactions can have specific meanings within the context of real estate. For example, a term such as “zone” can have various meanings, but in the context of real estate, generally refers to the types of uses for which a piece of land can be used. As another example, the term “title” can refer to a title bestowed on an individual, a name or heading of a document or movie, etc. However, in the context of real estate transactions, title has a specific meaning as a legal instrument. These are merely examples. It will be appreciated that there can be many terms that have specific meanings in the context of real estate transactions. RAG is not limited to merely addressing differences in the meaning of terms. RAG can provide broader contextual information, providing important cues, background information, references, and so forth.)
Referring to claim 20,
Malanga further teaches wherein the system ensures buyers are informed and supported throughout the home buying process, promoting transparency and efficiency. (Malanga paragraph 62 teaching in some embodiments, the system 100 may automatically forward any communication and/or attachments detected to the TCs 154 and Auditors 152, such as by auto-populating a transactional email address as a recipient to all communications made on the system 100. In some embodiments, the system 100 provides additional filters to accommodate a Closing Email program to increase retention of partners' clientele. In some embodiments, these functions may be handled by the Event Driven Workflow module 108. Malanga paragraph 92 teaching at operation 386, the system can determine a closing timeline. For example, the system can determine a closing timeline with various events based on, for example, the location of the property. In some embodiments, a user may be able to modify the timeline. At operation 388, the system can send the closing timeline to a client. In some embodiments, the system can send calendar invitations, reminders, and/or the like to the client, which can help reduce the likelihood of important dates being missed, which could delay closing. At operation 390, the system can schedule the sending of documents. For example, the system can automatically send electronic documents for signature based on the closing timeline.)
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Malanga et al. (US 20240411982), in view of Arriaga (US 20250054068), Vaynshteyn (US 20170337647), Alongi (US 20200074513), and Chen et al. (US 20210390647).
Referring to claim 5,
Malanga in view of Arriaga, Vaynshteyn, and Alongi does not teach or suggest wherein the system offers intelligent negotiation support by analyzing buyer’s risk tolerance, financial constraints, market conditions, and property specifics, and suggesting negotiation strategies based on recent successful transactions.
However Chen which is directed to wherein the system offers intelligent negotiation support by analyzing buyer’s risk tolerance, financial constraints, market conditions, and property specifics, and suggesting negotiation strategies based on recent successful transactions. (Chen paragraph 25 teaching client devices 102, 104, and 106 may be configured to receive and transmit proposals and counter-proposals related to a negotiation. Additionally, client devices 102, 104, and 106 may be configured to receive outside data related to transaction histories, market data, financial trends, etc. to train at least one machine learning algorithm. The client devices 102, 104, and 106 may then receive intelligent deal-term suggestions based on the trained machine learning algorithm(s) related to the proposals/counter-proposals. In aspects, a client device, such as client devices 102, 104, and 106, may have access to one or more data sources and/or databases comprising third-party market data, asset information (e.g., comparable property valuations, most current lease rate, etc.), past deal-flow history of the other negotiating party (e.g., time to respond to new proposal, terms most likely to negotiate, terms most likely to not negotiate, etc.) Chen paragraphs 27-28 teaching in some example aspects, the intelligent negotiation suggestion software running on client device(s) 102, 104, and/or 106 may be configured to receive updated data from various sources via network(s) 108 and/or satellite 122. For example, the intelligent negotiation suggestion software may comprise at least one machine learning or predictive analytics algorithm/model. The negotiation suggestion software may be configured to consistently receive updated market data, comparable asset information, transaction history related to negotiating parties, and previously rendered intelligent suggestions (and user decisions to approve or reject the intelligent suggestions), among other sources of data. The received data may be compiled into at least one dataset used to train the at least one machine learning or predictive analytics algorithm. The at least one machine-learning or predictive analytics algorithms (and models) may be stored locally at databases 110, 112, and/or 114 and/or externally at databases 116, 118, and/or 120. Client devices 102, 104, and/or 106 may be equipped to access these machine learning and predictive analytics algorithms and receive intelligent suggestions regarding real-time negotiations based on at least one machine-learning or predictive analytics model that is trained on a plurality of data, including but not limited to, past transaction history related to a negotiating party, asset valuation data (e.g., based on comparable and/or similarly-situated assets), current market conditions, predicted market conditions, etc. For example, if a first negotiating party frequently exchanges 1 month of free rent for an increase of 1 year in the length of a lease term, that first negotiating party's preferences may be captured and collected to train a machine-learning and/or predictive analytics model(s). The machine-learning and/or predictive analytics model(s) may then be used to automatically suggest similar terms for a counter-proposal that the second negotiating party may be preparing to send back to the first negotiating party. Such intelligent contract suggestions may allow the negotiating parties to reach agreement quicker, use less resources, and waste less time overall. In other example aspects, a certain customer that may be looking to lease commercial property may demonstrate a preference for certain amenities, geographies, office layouts, proximities to certain points-of-interest (e.g., distance from an international airport), term length, floor area, etc. The intelligent contract suggestion systems and methods described herein may implement at least one machine-learning or predictive analytics algorithm that is trained on a dataset reflecting a customer's preferences regarding amenities, geographies, office layouts, proximities, term duration, and size, among other factors. The systems and methods described herein may then automatically propose intelligent suggestions to negotiating parties based on the at least one machine learning or predictive analytics model trained on these various sets of data. Based on an aggregation of data from, e.g., a customer's preferences, a broker's negotiating strategy, history, current market trends, comparable asset valuations, etc., at least one ML model may be trained and subsequently deployed to automatically suggest intelligent contract terms to include in a proposal/counter-proposal during a negotiation cycle, which may aid in reaching mutual agreement faster than otherwise. Chen paragraph 32 teaching in other example aspects, the request for proposal form may not be tied to a certain property location but instead allow the user to enter specific criteria that the system may then receive, analyze, and use to provide an intelligent suggestion to the user regarding an available property. For instance, a user may input certain criteria regarding geographic location, floor area, amenities, proximity to points-of-interest (e.g., distance from major metropolitan area, distance from nearest international airport), term length, price, etc. The intelligent contract system described herein may receive these criteria and provide intelligent suggestions regarding candidate property locations. The property location candidates may be displayed to the user before the submission of the request for proposal, or, in some instances, the property location candidates may be displayed simultaneously with the submission of the request for proposal. Chen paragraph 50 teaching the method then proceeds to auto-generate potential proposal suggestions (i.e., intelligent suggestions) based on predictive analytics and/or the trained machine learning model that is trained on e.g., past transaction/deal-flow history related to the first party, similarly situated asset valuations, standard terms given the deal characteristics, current market conditions, future market predictors, etc. The proposals may be provided to the second party, where the second party may either approve or disapprove of the suggestions. Chen paragraph 57 teaching in another example aspect, a certain user preference may relate to a contract provision and the contract provision's associated risk level. For instance, the ranking of proposals may be based on the level of risk of certain contract provisions (e.g., indemnification, delivery date deadlines, liquidated damages, penalties, force majeure, etc.). The intelligent contract system may analyze the proposed contract terms, compare the proposed contract terms among other terms from the multiple offers and/or against standard contract terms (e.g., stored in databases 614, 616, etc.), and subsequently provide a risk assessment to the user related to a specific contract provision/proposed term.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the coordination of a real estate transaction as taught in Malanga in view of Arriaga, Vaynshteyn, and Alongi to incorporate wherein the system offers intelligent negotiation support by analyzing buyer’s risk tolerance, financial constraints, market conditions, and property specifics, and suggesting negotiation strategies based on recent successful transactions as taught in Chen with the motivation of the generation of recommendation for incorporations into a proposal for facilitating the completion of a negotiation taking into account user preferences, prior transactions, and market conditions. (Chen paragraphs 25, 27-28, and 50)
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Malanga et al. (US 20240411982), in view of Arriaga (US 20250054068), Vaynshteyn (US 20170337647), Alongi (US 20200074513), and Swartz et al. (US 20250139590).
Referring to claim 16,
Malanga in view of Arriaga, Vaynshteyn, and Alongi does not teach or suggest wherein the system provides AI-driven cost estimates for repairs and answers related questions during the inspection phase.
However Swartz, which is directed to generative AI for home maintenance alerts and repairs teaches wherein the system provides AI-driven cost estimates for repairs and answers related questions during the inspection phase. (Swartz paragraph 35 teaching in some cases, the master controller unit may use a ChatGPT type AI system to help provide information to the stakeholder as part of the DIY project. The system may ask questions to the stakeholder, and based upon the answers received, may provide certain information to the stakeholder based upon the determined experience level of the stakeholder to perform this particular project. The information provided will aid the stakeholder in performing the project and will be tailored for the stakeholder and their level of experience. Similar to described above, the master controller unit may form a query (for example, a free form text query or a natural language process query) and transmit to the server using the communication interface to collect one or more videos, one or more blogs, manufacturer websites, and/or any instructions that may be available online and may be useful to the user in fixing the problem as a DIY project. The master controller unit may save the sourced one or more videos, one or more blogs, manufacturer websites, and/or instructions in a specific location (for example, a local database and/or a database in cloud) to provide easy access to the sourced content. Swartz paragraph 42 teaching as described herein in greater detail, some embodiments include a computing device that may be referred to as an AI home unit having one or more processors that is in communication with different machines or appliances or devices (collectively appliances) (including smart appliances and smart devices) within or outside the home. In some cases, the appliance (a smart appliance) may (i) identify that there is a problem or that there is beginning to be an issue, and (ii) prompt a master AI home unit to inform the owner that maintenance on the appliance is needed. The AI home unit may (iii) determine the cause of the problem using AI tools and other data; (iv) locate the part number or elements to be inspected, repaired, and/or replaced and provides user details of the problem and how it may be resolved; (v) source parts online to fix the problem and sources costs of best quality lowest cost or other attributes the user may set; (vi) ask users with verbal prompts (chatbot) or text prompts on a user device if the home unit should order the parts required to fix the problem; and/or (vii) initiate ordering the parts and automatically applies source of payment set by the user. Swartz paragraph 130-131 teaching If the method selected for repairing is through a professional service provider, the AI home unit may compare professional service providers based on their availability and capability to complete the repair work based upon online ratings, feedback, reviews, and/or other publicly available online information about the professional service providers. The AI home unit may then provide a list of vendor choices for the owner (or user) to select from and provide a recommendation of a preferred vendor. The owner (or user) may select one or more vendors, and the AI home unit may then automatically contact the selected one or more vendors to provide a summary of the issue or problem, and/or defective parts for receiving a cost estimate for the repair. The AI home unit may provide the owner the received quotes from the one or more vendors to decide and select a vendor for performing the repair work. Based upon the selection of the vendor by the owner, the AI home unit may automatically begin scheduling of the repair work using the owner's digital calendar or based upon the owner's input regarding available dates and may coordinate with the selected vendor for the repair work. upon completion of the repair work by the selected vendor (or as the DIY project or mix), the machine, system, or appliance may validate the repair work and communicate to the AI home unit to report that the issue or problem is resolved. Additionally, or alternatively, details of the repair work and/or the service provider may be provided to the AI home unit for warranty claims. The machine, system, or appliance may also provide diagnostic data and/or ongoing assessment data to the AI home unit, and the AI home unit may provide the owner (or user) maintenance instructions for the replaced part and/or overall maintenance guidance through prompts regularly.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the coordination of a real estate transaction as taihjt in Malanga in view of Arriaga and Vaynshteyn to incorporate wherein the system provides AI-driven cost estimates for repairs and answers related questions during the inspection phase as taught in Swartz with the motivation of facilitating the coordination of a property repair requests. (Swartz paragraphs 42 and 130-131)
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Malanga et al. (US 20240411982) in view of Arriaga (US 20250054068), Vaynshteyn (US 20170337647), Alongi (US 20200074513) and Roach et al. (US 20200042964).
Referring to claim 18,
While Malanga teaches making documents available for external review of conducted transactions (Malanga paragraph 148), Malanga in view of Arriaga, Vaynsteyn, and Alongi, does not teach or suggest wherein the system enables post-purchase access to transaction documentation for up to seven years.
However Roach, which is directed to collecting taxes from commerce, teaches wherein the system enables post-purchase access to transaction documentation for up to seven years. (Roach paragraphs 36-38 teaching the transaction data store 34 includes one or more servers or other computers and a data store 38 that can include one or more relational databases, which may be shards. The transaction data store 34 is configured to receive transaction records for executed transactions from the transaction control system 30 via an API, web service, or similar. Each transaction record stores a merchant identifier, a transaction date, a transaction amount, a tax amount, a tax jurisdiction, a currency, a payment type (e.g., credit card, debit, etc.) and may further store a list of the good(s)/service(s) sold. The transaction data store 34 is further configured to report transaction records to one or more taxation authority systems 40. The transaction data store 34 is configured to store transaction record for a predetermined time, such as seven years. A taxation authority system 40 is operated by the tax jurisdiction for a particular location (e.g., a country). The transaction data store 34 is configured to provide reports of the transaction records collected for the particular location for each taxation authority system 40 by executing queries on transaction records with reference to tax jurisdiction. Transaction data can include an authority code, which may be a unique code that identifies a country, state, province, region, county, city, or other location where tax is payable. Roach paragraph 65 teaching FIG. 4 shows a database structure suitable for efficiently storing a multitude (millions) of transaction records at the transaction data store 34 for an appropriate retention period of, for example, seven years. A merchant table 302 stores a unique identifier of each merchant operating one or more merchant systems 14 in association with particulars about the merchant. A tax collected table 304 stores transaction records for items, where each row corresponds to one item. Because a particular transaction may include multiple items, a transaction number/identifier field is provided to allow each row to be assigned to an actual transaction. The tax collected table 304 stores other data concerning the transaction, such as the identifier of the merchant, value/amount, tax rate, tax amount, date, payment type, and a description of the item.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the coordination of a real estate in as taught in Malanga in view of Arriaga, Vaynshteyn, and Alongi to incorporate wherein the system enables post-purchase access to transaction documentation for up to seven years as taught in Roach with the motivation of storing documents for a requisite length of time in compliance with law. (Roach paragraph 65)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Martin et al. (US 20250200680) – directed to aggregating and transfer of property data.
Cook (US 20240126794) -directed to generating a digital assistant.
Williams et al. (US 20240289596) -directed to analysis of home telematics using generative AI.
Vasylyev (US 20240412720) -directed to providing a contextualized response to a user using AI.
Madisetti (US 20240370476) - directed to AI and LLMs for generative AI applications.
Wu et al. (US 20240087063) -directed to document transformation and recordation.
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