Patent Application 17714357 - SYSTEMS AND METHODS FOR MAINTENANCE CALENDARING - Rejection
Appearance
Patent Application 17714357 - SYSTEMS AND METHODS FOR MAINTENANCE CALENDARING
Title: SYSTEMS AND METHODS FOR MAINTENANCE CALENDARING
Application Information
- Invention Title: SYSTEMS AND METHODS FOR MAINTENANCE CALENDARING
- Application Number: 17714357
- Submission Date: 2025-05-13T00:00:00.000Z
- Effective Filing Date: 2022-04-06T00:00:00.000Z
- Filing Date: 2022-04-06T00:00:00.000Z
- National Class: 705
- National Sub-Class: 007210
- Examiner Employee Number: 88378
- Art Unit: 3625
- Tech Center: 3600
Rejection Summary
- 102 Rejections: 0
- 103 Rejections: 5
Cited Patents
The following patents were cited in the rejection:
- US 0182924đ
- US 0344703đ
- US 0210965đ
- US 0342421đ
- US 0197442đ
Office Action Text
DETAILED ACTION This communication is a Final Rejection Office Action in response to the 1/24/2025 filling of Application 17/714,357. Claim 1 and 11 are amended. Claims 1-17 are now presented. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Response to Arguments Applicantâs arguments filed 1/24/2025 with respect to the prior art have been considered but are moot because the new grounds of rejection does not apply to the new grounds of rejection that was necessitated by amendment. Applicant's remaining arguments have been fully considered but they are not persuasive. Regarding the rejections under 101, the Applicant argues â Applicant respectfully traverses the rejection because the Applicant's claims, as amended, are directed to an invention that offers a solution to the problem of allowing homeowners and property managers to manage properties on an ongoing basis by generating a profile of the property and a maintenance calendar that automatically updates based on updates to the profileâ The Examiner respectfully disagrees that allowing homeowners and property managers to manage properties on an ongoing basis is an improvement to a technology or a technical field. Instead this is an improvement to an abstract business practice which is not eligible under 191. The Applicant further argues âThe Office Action asserts that claim 1 recites abstract ideas in the form of methods of organizing human activity and mental processes. Applicant respectfully disagrees and submits that the amended claim 1 does not merely recite abstract concepts. Instead, the claim is directed to specific technological solutions to problems rooted in property management systems.â The Examiner respectfully disagrees. The 2019 PEG states certain method of organizing human activity including managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) and commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations) are abstract. The instant claims are directed to business interactions as they involve identifying maintenance tasks, scheduling tasks, facilitating bidding, invoicing, and paying for tasks. Further, the claim recites mental processes including observation, evaluation, judgment, opinion. For example, the comparing step, the updating step, the generating a profile; the generating a calendar; and updating step are drawn are drawn to observation and evaluation. As such, the claim recites at least one abstract idea. The Applicant further argues âThe claim recites the following elements that reflect integration into a practical application: a) Use of Machine Learning: The claim explicitly recites the use of a machine-learning algorithm to resolve conflicts in property data inputs. This goes beyond mere data comparison or manual resolution and provides a concrete technological solution to the problem of reconciling inconsistent or conflicting property data across multiple databases. The Examiner respectfully disagrees that the use of machine learning reflects an integration into a practical application. In the instant case, the additional elements of the broadly recited machine learning attempt to cover any solution to the identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, which does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words "apply itâ. The claims do not state how the machine learning works to resolve any conflicts. As such, the broadly recited ML algorithm does not integrate a judicial exception into a practical application or provide significantly more. b) Interactive GUI with Real-Time Updates: The claim recites a graphical user interface (GUI) that not only displays maintenance schedules but also provides interactive functionality, allowing users to add, modify, or delete tasks. Additionally, the system automatically updates the calendar in real-time and notifies users of significant changes through integrated push notifications. This level of interactivity and real-time operation demonstrates meaningful application of the system in the technological field of property management. The Examiner respectfully disagrees that the interactive GUI with real-time updates reflects an integration into a practical application. The instant claims are directed to business interaction as they involve the real-time identifying maintenance tasks, scheduling tasks, facilitating bidding, invoicing, and paying for tasks. The fact that these updates occur in real-time does not save the claim. Updating users in real-time to changes that impact their schedules remains an abstract method of organizing human activity. c) Organized Data Structures: The claim leverages distinct databases (a master database and a rule database) to handle data storage and rules in a structured manner, enabling scalability and flexibility in generating tailored property maintenance schedules. The Examiner respectfully disagrees that the organized data structures reflect an integration into a practical application. The claim recites ârules stored in a rule database that is separate from the master databaseâ. However, this limitations is recited broadly. Storing information in 2 databases does not represent an improvement to the technology or technical field. It merely represent conventional data storage which amounts to insignificant extra solution activity. The Applicant further argues âThese features collectively integrate the claimed invention into a practical application that improves property management technology and extends beyond a mere abstract idea.â The Examiner respectfully disagrees. When viewing the generic database, GUI and machine learning in combination with the generic computer does not add more than when viewing the elements individually. Accordingly, the additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. 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. Claim 1 is 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. Claim 1 has been amended to recite: âusing a machine-learning algorithm to resolve any conflictsâ However, the specification does not disclose the use of a machine learning algorithm. âretrieve property data inputs from multiple public databases, wherein the property data inputs include at least property dimensions, geographic location, and property ownership details;â However, the specification does not disclose the inputs include at least property dimensions, geographic location, and property ownership details. âstore the mastered data in a master databaseâ However, the specification does not disclose a master database. The specification does disclose storing mastered data, but does not disclose it is stored in a mastered database. âthe rule database containing customizable property-specific maintenance parametersâ However, the specification does not disclose customizable property-specific maintenance parameters. âgenerate a unique property profile applying the dynamically updated rules to the mastered data;â However, the specification does not disclose generating a unique property profile or applying the dynamically updated rules to the mastered data. âwherein the system notifies users of significant changes in maintenance schedules through a push notification system integrated with GUIâ However, the specification does not disclose notifying users of significant changes in maintenance schedules through a push notification system integrated with GUI 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. Claim 1 recites the limitation âthe calendar interfaceâ. There is insufficient antecedent basis for this limitation in the claim. 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-17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. When considering subject matter eligibility under 35 U.S.C. 101, in step 1 it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. If the claim does fall within one of the statutory categories, in step 2A prong 1 it must then be determined whether the claim recites a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea). If the claim recites a judicial exception, under step 2A prong 2 it must additionally be determined whether the recites additional elements that integrate the judicial exception into a practical application. If a claim does not integrate the Abstract idea into a practical application, under step 2B it must then be determined if the claim provides an inventive concept. In the Instant case Claims 1-10, 13 are directed toward a system for calendaring property maintenance tasks. Claims 11-12 are directed toward a method to for calendaring maintenance tasks. Claims 14-15 are directed to a method for bidding on the execution of a task. Claims 16-17 are directed to a method of invoicing a property owner following the execution of a maintenance task. As such, each of the Claims is directed to one of the four statutory categories of invention. The 2019 Preliminary Examination Guidance (2019 PEG), explains that in step 2A prong 1 examiners are to evaluate claims to determine if they recite an abstract idea. The guidance explains that claims that recite mathematical concepts, mental processes, and methods of organizing human activity recite abstract ideas. As per step 2A prong 1 of the eligibility analysis, claim 1 recites the abstract idea of generating a calendar or maintenance tasks which falls into the abstract idea categories of certain methods of organizing human activity and mental processes. The elements of Claim 1 that represent the Abstract idea include: A system for calendaring property maintenance tasks, the system comprising: analyze the property data inputs to resolve any conflicts therebetween, thereby generating mastered data from the public databases representing characteristics of the property; dynamically update rules customizable, property-specific maintenance parameters based on the mastered data and manual user inputs generate a unique property profile of the property based on the updated rules by applying the dynamically updated rules to the mastered data, wherein the property profile includes specific maintenance schedules tailored to the property's characteristics and geographic conditions; generate a calendar of maintenance tasks for the property for display allowing a user to add, modify, or delete maintenance tasks directly within the calendar interface; automatically update the calendar of maintenance tasks based on updates to the profile in real time in response to changes to the property profile or updates from the public databases, wherein the system notifies users of significant changes in maintenance schedules through a push notification system integrated with the GUI The elements of Claim 11 that represent the Abstract idea include: viewing calendar of maintenance tasks selecting a maintenance task; and taking an action selected from the group consisting of marking the maintenance task as completed, rescheduling the maintenance task or deleting the maintenance task. The elements of Claim 14 that represent the Abstract idea include: A method of bidding on the execution of a maintenance task, the method comprising: providing a vendor portal according to claim 7; and bidding on the execution of a maintenance task through the vendor portal. The elements of Claim 16 that represent the Abstract idea include: A method of invoicing a property manager or owner following the execution of a maintenance task, the method comprising: transmitting an invoice to the property manager or owner, wherein the property manager or owner was responsible for hiring a vendor according to claim 15. The 2019 PEG states certain method of organizing human activity including managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) and commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations) are abstract. The instant claims are directed to business interaction as they involve the real-time identifying maintenance tasks, scheduling tasks, facilitating bidding, invoicing, and paying for tasks. Further, a notification system to notify users of changes also amounts to organizing human activity. Further, the claim recites mental processes including observation, evaluation, judgment, opinion. For example, the comparing step, the updating step, the generating a profile; the generating a calendar; and updating step are drawn are drawn to observation and evaluation. As such, the claim recites at least one abstract idea. Under step 2A prong 2 the examiner must then determine if the recited abstract idea is integrated into a practical application. The 2019 PEG states that additional elements that are indicative of integration into a practical application include: Improvements to the functioning of a computer, or to any other technology or technical field - see MPEP 2106.05(a) Applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition â see Vanda Memo Applying the judicial exception with, or by use of, a particular machine - see MPEP 2106.05(b) Effecting a transformation or reduction of a particular article to a different state or thing - see MPEP 2106.05(c) Applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception - see MPEP 2106.05(e) and Vanda Memo Limitations that are not indicative of integration into a practical application: Adding the words âapply itâ (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f) Adding insignificant extra-solution activity to the judicial exception - see MPEP 2106.05(g) Generally linking the use of the judicial exception to a particular technological environment or field of use â see MPEP 2106.05(h) In the instant case, this judicial exception is not integrated into a practical application. In particular, Claim 1 recites the additional elements of: a software module tangibly stored on a non-transitory computer readable medium in communication with public databases containing property data inputs specific to a property, the software module comprising instructions which when executed by a connected microprocessor cause the processor to: retrieve property data inputs from multiple public databases, wherein the property data inputs include at least property dimensions, geographic location, and property ownership details; using a machine-learning algorithm; store the mastered data in a master database; rules stored in a rule database that is separate from the master database, the rule database associated with the scheduling of maintenance tasks for the property containing; displaying a calendar on a graphical user interface (GUI) wherein the GUI provides interactive functionality allowing a user to add, modify, or delete maintenance tasks; However, the microprocessor and computer elements are recited at a high-level of generality (i.e., as a generic processor performing a generic computer functions) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Further MPEP 2105.05(g) explains that data gathering and data output can be considered pre-solution activity and post-solution activity. As such, the retrieval of property data inputs is insignificant pre-solution activity and the displaying a calendar is considered post-solution activity. Further, see MPEP 2106.05(g) an example of insignificant activity includes adding a final step of storing data to a process that only recites computing the area of a space (a mathematical relationship) does not add a meaningful limitation to the process of computing the area. In the instant case, storing data in a database in a conventional manner places no meaningful limits on the claim. Further, the use of separated databases does not meaningful limits on the claims and still amounts to insignificant data storage. Further, displaying information on a GUI is also insignificant extra-solution activity. MPEP 2105.05(g) explains that an example of post-solution activity is an element that is not integrated into the claim as a whole, e.g., a printer that is used to output a report of fraudulent transactions, which is recited in a claim to a computer programmed to analyze and manipulate information about credit card transactions in order to detect whether the transactions were fraudulent. The broadly recited GUI to display information is not meaningfully different from the printer used to output information. Further, the use of a machine learning algorithm is indicative of adding the words âapply itâ (or an equivalent) with the judicial exception. MPEP 2106.05(f) states: When determining whether a claim simply recites a judicial exception with the words "apply it" (or an equivalent), such as mere instructions to implement an abstract idea on a computer, examiners may consider the following: (1) Whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished. The recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words "apply it". See Electric Power Group, LLC v. Alstom, S.A., 830 F.3d 1350, 1356, 119 USPQ2d 1739, 1743-44 (Fed. Cir. 2016); Intellectual Ventures I v. Symantec, 838 F.3d 1307, 1327, 120 USPQ2d 1353, 1366 (Fed. Cir. 2016); Internet Patents Corp. v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1417 (Fed. Cir. 2015). In contrast, claiming a particular solution to a problem or a particular way to achieve a desired outcome may integrate the judicial exception into a practical application or provide significantly more. See Electric Power, 830 F.3d at 1356, 119 USPQ2d at 1743. By way of example, in Intellectual Ventures I v. Capital One Fin. Corp., 850 F.3d 1332, 121 USPQ2d 1940 (Fed. Cir. 2017), the steps in the claims described "the creation of a dynamic document based upon âmanagement record typesâ and âprimary record types.â" 850 F.3d at 1339-40; 121 USPQ2d at 1945-46. The claims were found to be directed to the abstract idea of "collecting, displaying, and manipulating data." 850 F.3d at 1340; 121 USPQ2d at 1946. In addition to the abstract idea, the claims also recited the additional element of modifying the underlying XML document in response to modifications made in the dynamic document. 850 F.3d at 1342; 121 USPQ2d at 1947-48. Although the claims purported to modify the underlying XML document in response to modifications made in the dynamic document, nothing in the claims indicated what specific steps were undertaken other than merely using the abstract idea in the context of XML documents. The court thus held the claims ineligible, because the additional limitations provided only a result-oriented solution and lacked details as to how the computer performed the modifications, which was equivalent to the words "apply it". 850 F.3d at 1341-42; 121 USPQ2d at 1947-48 (citing Electric Power Group., 830 F.3d at 1356, 1356, USPQ2d at 1743-44 (cautioning against claims "so result focused, so functional, as to effectively cover any solution to an identified problem")). In the instant case, the additional elements of the broadly recited machine learning attempt to cover any solution to the identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, which does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words "apply itâ. The claims do not state how the machine learning works to resolve any conflicts. As such, the broadly recited ML algorithm does not integrate a judicial exception into a practical application or provide significantly more. When viewing the generic database, GUI and machine learning in combination with the generic computer does not add more than when viewing the elements individually. Accordingly, the additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. In step 2B, the examiner must determine whether the claim adds a specific limitation other than what is well-understood, routine, conventional activity in the field - see MPEP 2106.05(d). As discussed with respect to Step 2A Prong Two, the additional elements in the claim amount to no more than mere instructions to apply the exception using a generic computer component. The same analysis applies here in 2B, i.e., mere instructions to apply an exception on a generic computer cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Further, the separate database to store data is recited broadly in the claims. MPEP 2106.05(d) states storing and retrieving information in memory, is conventional when claimed generically (see Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-9)). As such, the broadly claimed receipt of data is considered well-known and conventional as established by the MPEP and relevant case law. Further, the Examiner takes official notice that displaying information on interactive GUI is well-known and conventional. Further, similar to the analysis with respect to step 2A prong 2 recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished cannot provide an inventive concept under step 2B of the eligibility analysis. When viewing the generic database, GUI and machine learning in combination with the generic computer does not add more than when viewing the elements individually. Accordingly, the additional elements do not provide an inventive concept. Further Claims 2-11 further limit the mental processes and commercial interactions recited in the parent claim, but fail to remedy the deficiencies of the parent claim as they do not impose any additional elements that amount to significantly more than the abstract idea itself. Further, claims 4, 5 recite the system operated via the internet from a computer in communication with a software module and the use of an API. However, this amounts to merely applying the abstract idea via a well-known technological environment and is not sufficient to integrate the abstract idea into a practical application. Accordingly, the Examiner concludes that there are no meaningful limitations in claims 1-17 that transform the judicial exception into a patent eligible application such that the claim amounts to significantly more than the judicial exception itself. Claim Rejections - 35 USC § 103 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. Claim(s) 1, 2, 3, 4, 7, 8, 11, 12, 14, 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wohlstadter US 20120265633 A1 in view of Luciani US 20220245290 A1 in view of Settino US 20130290052 A1 in view of Ansari US 2017/0344703 A1 in view of Lu US 2019/0197442 A1. As per Claim 1 Wohlstadter teaches a system for calendaring property maintenance tasks, the system comprising: a software module tangibly stored on a non-transitory computer readable medium in communication with public databases containing property data inputs specific to a property, the first software module comprising instructions which when executed by a connected microprocessor cause the processor to: Wohlstadter para. 77 teaches the invention includes a system, a method and an apparatus for defining, managing and transferring, through either sale or lease, one or more properties, particularly real property and related personal property. The invention also relates to systems for maintaining, trading, selling, and/or leasing property. In one embodiment, a computer network system and software structure and information processing method are provided that enable a plurality of users to maintain, trade, sell, or lease a property or properties and/or transfer the history of a property or properties. Further, Wohlstadter para. 23 teaches n one aspect of the invention, capturing property information includes capturing information about a property at different times over a span of time. In another aspect of the invention, capturing property information includes receiving input from the record owner. Yet, in another aspect of the invention, capturing property information includes obtaining at least some of the property information from publicly accessible records. 98 In step 425, a selected Property from Property Table 305 is displayed, pulling from all relevant data sources. Since homes are a matter of public record, by default a basic description of the home could be provided for general public consumption which shows only basic information about the home, but does not display private files or details of rooms and/or other areas. This basic information could include the city, state and zip code of the property, the property features, the rooms and other areas of the home but no ability to see the particulars of the various rooms and other areas nor any information which specifically ties the property to a specific address. For the User in Table 303 all the details of the Property from Table 305 and the associated data containers are visible and editable. For the user's Trusted Communities Table 315 only the details which are generally public or marked as viewable by the community are visible to the Trusted Member 316, but no data is editable by anyone or anything other than the owning User in Table 303. retrieve property data inputs from multiple public databases, wherein the property data inputs include at least property dimensions, geographic location, and property ownership details; store the mastered data in a master database; Wohlstadter para. 85 teaches according to some embodiments, as in FIG. 3, Property Table 305 is at the core of Database subsystem 208. Property Table 305 contains all attributes relevant to a particular physical property (the "Property"). Associated with Property Table 305 is a User Table 303 that identifies the person or entity claiming or just documenting a property listed in Property Table 305. Also associated with a Property in Table 305 is the Inventory Table 306 identified as being located with the Property Table 305, either physically located on the Property listed in Table 305 or organized logically with the Property listed in Table 305. Property Table 305 also has associated with it the layout of the rooms and various other areas on the underlying property record as depicted with the relationship between Property Table 305 and Property Area Table 308; such that, a Property can have zero or more rooms and/or zero or more other areas. Property Area Table 308 represents a generalization of all rooms and other areas of the Property; where, room could be a kitchen, dining room, bedroom, bathroom, living room, or whatever other room typically makes up a Property while also providing for a room not pre-defined, i.e., "other," which could be named whatever the user desires to name it, for example, other area could be a front yard, back yard, patio, deck, garden, or whatever other area either in the home or on the Property that the user desires to describe. While providing for a non pre-defined area, "other" which could be named whatever the user desires to name it. Property Table 305 also has associated with it a File List 314 which contains all Files 304 uploaded to a property record or referenced by a Property Table 305. Such files could be images, video, audio, documents or any other electronic form of supplemental information about a Property. Property Area Table 308 also has associated with it a File List 314 so as to provide for organizing Files 304 with the relevant room or other area. Property Table 305 also is associated with Tax Assessments Table 318 which provides for a historical rundown of all the tax assessments provided by a county for a Property. Property Table 305 also is associated with Property Transfer Table 301 which provides for a historical rundown of all the sales transactions conducted on a Property. And finally, Property Table 305 has associated with it in Projects Table 310 information on projects executed on a Property. Para. 74 teaches "Property Information" may include, but it is not limited to information about real property and personal property associated with real property, for example, address, home type, price, number of bedrooms or bathrooms, lot size, architectural style, square footage, age of home, type of air conditioning, closets, driveways, fireplace, garden, plumbing, roof, exterior, floor, heat, parking, pool, sewer, personal property inventory and other information. Para. 24 teaches In one aspect of the invention, transferring record ownership of the property from a first user to a second user comprises changing record owner information pertaining to the property in a database. In another aspect of the invention, transferring record ownership of the property does not transfer ownership of information marked as private. update rules stored in a rule database, the rule database containing customizable property-specific maintenance parameters based on the mastered data and manual user inputs; Wohlstadter para. 116 teaches the ability to document and execute projects on the property is another aspect of the invention, illustrated in a non-limiting example of FIGS. 22 and 23A-C. Home projects could include but are not limited to home improvements, repairs, extensions, one-time maintenance, periodic maintenance and the like. These projects could be associated with the property, on the home exterior, interior, one or more rooms in the home, one or more areas of the property, and/or some combination of same. These projects could be just a description by the user for historical purposes not meant to be executed by a service provider or to be posted to service providers for ultimate execution. FIG. 22 shows an example of a user interface screen 2200 to display from a database of projects associated with Property 2201 an overview of those projects. The user/homeowner has previously created the project entries shown in this example (e.g., Gutters Project 2202, Fix Railing project 2204, etc.). Projects may be created in any convenient way depending on the underlying database. For example, a click on a New Project icon 2206 may bring up a project input screen. On screen 2200, the user may be provided, for example, with a selection box 2208 that may be checked to delete a project and a status pull-down selection box 2210 to permit status updates; entry fields 2212 and 2214 for project start and end data entries, and a check box 2216 where the user may choose to publish the project (e.g., to receive bids). More detailed per project information may be input, for example, on one or more "Edit Project" screens such as screens 2302, 2304 and 2306 of FIGS. 23A-23C, which together provide a "snap shot" of one project. These screens capture typical information that might be used to publish a project to receive bids from service provider such as contractors, for example. The fields and organization shown are intended to be exemplary and not limiting. On other screens, actual project results may be entered/captured. Para. 117 teaches in FIG. 8A, the user would, for example, first select a project category, at step 805, and then, in step 806, create the Project Table or entry in Project Table 310, as illustrated in a non-limiting example of FIG. 23A. From here the user would specify in Step 809 (e.g., on screen 2302) an overview of the project that could include but need not be limited to, for example, a name, a description, entries to the affected Project Areas Table 309 (i.e., rooms and/or areas of the home being involved), desired start date, desired completion date, approximate budget, and/or contact information including but not limited to email, phone, cell phone, and/or private message. The user would then set the privacy she desires on the project, at 808, e.g., either private (no one but the user having access), public (everyone, including the user having access) or semi-private (only the user and his/her Trusted Community having access). If the type of project selected requires supplemental questions to be answered, determined at test 809, the user would answer one or more questions that are specific to the project, step 810. Each question could require an answer of a predetermined type. Next, the user could upload or reference one or more files to help describe the project 600, such as video, audio, picture, text or other files, as illustrated in a non-limiting example of FIG. 23B. The information on the project may be input by the user at various times, thereby allowing the history of a project to be recorded in increments. Optionally (and not shown), the system may automatically populate a routine maintenance calendar for the user's review and approval, e.g., scheduling gardening, gutter cleaning, heating oil delivery, air conditioning maintenance and other routine services and record the completion of each routine maintenance event (in some instances, automatically or semi-automatically), with or without verification by a user. Yet in other embodiments, the user may manually populate a routine maintenance calendar. Yet in another embodiment, the system may contain a `reminder` module which populates reminders to the user to schedule desired or recommended maintenance tasks. The Examiner considers a database of projects associated with a property that is used to create projects including automatically populate a routine maintenance calendar to be a rules databased that is updated depending on the requirement for the property. Wohlstadter does not teach the rules database is separate from the master database, However, Settino Abstract teaches a policy database is queried to determine an applicable policy based on the received instructions, and the renovation task is identified based on the received instructions and/or the applicable policy. A schedule is generated for the renovation task, by identifying a preferred time period for carrying out at least a portion of the renovation task, based on the applicable policy, and prioritizing performance of at least that portion during the preferred time period. Para. 132 teaches he property database(s) 225 may store information pertaining to one or more properties (e.g., address, current tenant, size, age, type and history of a property). The property database may also store the jurisdictional location of the building, for the purpose of determining what building, electrical and plumbing codes apply to the site, and what landlord/tenant rules apply. Para. 131 teaches in the system 200, the memory(ies) 220 may store information in one or more property databases 225, one or more policy databases 230, one or more personnel databases 235, one or more report databases 240 and one or more deviation databases 245. These may be separate databases or may be combined databases. Different databases may be stored in different memories 220. Different memories 220 may also store duplicates of the same database or may store portions of the same database. The databases may be accessible by the processor(s) 205. Both Wohlstadter and Settino are directed to property management. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicantâs invention to modify the teachings of Wohlstadter to include the rules database is separate from the master database because by applying the known technique of Settino would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Settino to the teachings of Wohlstadter would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate the use of separate databases into similar systems. Further, incorporating the separate databases taught by Settino to the system taught by Wohlstadter would result in an improved system that provides improves flexibility and reliability. Wohlstadter does not teach dynamically update rules Luciani 112 teaches Consulting a table of systems and their respective vulnerabilities such as Table 1, maintenance notification module 370 generates and conveys information about a modified status of maintenance (e.g., a more urgent maintenance timeline) or additional maintenance needs (e.g., a specific upgrade to counteract the location-specific risks) in view of the indication of increased risks from location-specific risk query generator engine 382 or risk evaluation resources 308. This generated information is represented by update 610 to report of maintenance and risk alerts 385. Wohlstadter does not teach generate a unique property profile applying the dynamically updated rules to the mastered data, wherein the property profile includes specific maintenance schedules tailored to the property's characteristics and geographic conditions; Luciani 100 baseline age determination engine 362 detects the indication of an upgrade to the electrical system of the home received through records submission interface 304. As a result, the baseline age of the electrical system of the home is modified to generate a corrected age that is lower than the objective baseline age of the electrical system as determined from the objective baseline data received from public/government data sources of data server 112. In some embodiments, home and system age adjustment engine 366 may perform the adjustment of the objective baseline age to the corrected age when smart home sensors in smart devices 110 report the upgrade of the electric box (e.g., when smart device 110 such as a smart electric utility monitor produces sensor readouts or outputs indicating an upgrade to the electric box of smart home 108). Para. 101 teaches 101 as a result of the objective baseline age of the electric system of the home being modified to a corrected age (sometimes referred to as an âeffective ageâ), corrected age model 368 generated by age modeling module 350 reflects a lowered effective age 510 of the electrical system of the home being modeled by smart home modeling system 120. The corrected age model 368 with a lowered effective age of the electrical system is then conveyed to risk analysis module 370. Para. 102 when requesting risk data from risk evaluation resources 308, risk analysis module requests risk data for an electrical system having the lowered effective age of the system reported by age modeling module 350 in age model 368. As a result, the system risk model 372 generated by risk analysis module 370 indicates a lowered risk 512 of electrical system failure based on the lowered effective age of the system. In this way, data from private data sources 301 impacts both the effective age of the electrical system through the lowered age of the electrical system in age model 368, as well as the risk model 372 of the home through the lowered risk associated with the electrical system. Additionally, maintenance schedule and risk alerts 585 are generated by maintenance notification module 380. Para. 106 teaches FIG. 6 illustrates a schematic block diagram of the smart home modeling system 120 shown in FIG. 2, further showing example operations for generating dynamic pricing information for home services on a dashboard responsive to location-specific weather risks. In this example, a smart home modeling system 120 may be set up for a home that has with any number of smart devices 110 as shown in FIG. 1. Para. 112 teaches in response to receiving a system risk model 372 containing indicators of increased risk to the plumbing, electric, and insulation systems due to dynamic flood risk evaluations, maintenance notification module 380 commences the operation of engines of risk analysis module engines 381. Location-specific risk query generator engine 382 (pictured in FIG. 3B) confirms and corroborates the dynamic flood risks provided by risk evaluation resources 308. Maintenance schedule reporting engine 384 then prescribes changes to the report of maintenance schedule and risk alerts 385 for systems affected by the increased risk due to flooding. Consulting a table of systems and their respective vulnerabilities such as Table 1, maintenance notification module 370 generates and conveys information about a modified status of maintenance (e.g., a more urgent maintenance timeline) or additional maintenance needs (e.g., a specific upgrade to counteract the location-specific risks) in view of the indication of increased risks from location-specific risk query generator engine 382 or risk evaluation resources 308. This generated information is represented by update 610 to report of maintenance and risk alerts 385. Wohlstadter does not teach generate a calendar of maintenance tasks for the property for display on a graphical user interface (GUI); and However, Luciani para. 72 teaches maintenance schedule reporting engine 384 may then convey information about a modified status of maintenance (e.g., a more urgent maintenance timeline) or additional maintenance needs (e.g., a specific upgrade to counteract the location-specific risks discovered by location-specific risk query generator engine 382) in view of the indication of increased risks from results of the query to risk evaluation resource 308 generated by location-specific risk query generator engine 382, using maintenance schedule reporting engine 384. In certain embodiments, maintenance schedule reporting engine 384 may convey a modified status of maintenance or additional maintenance needs directly to a user (via client devices or dashboard 399), or these reports may be conveyed to dashboard module 390. Additionally, in such embodiments, maintenance schedule reporting engine 384 can also convey the modified status of maintenance or additional needs to a provider of home services (e.g., an insurance provider or agent). As noted above, a modified status of maintenance could indicate a more urgent, or accelerated, maintenance timeline for services to a home system. When maintenance schedule reporting engine 384 reports a modified status of maintenance to a home services provider, additional flags corresponding to highlighted or elevated risk levels for certain home systems are also conveyed along with the modified status to alert the home services provider to the highlighted or elevated risk levels. Such flags could indicate that the highlighted or elevated risk levels for certain home systems require immediate attention (e.g., adjustment to the price of the home services) or automatic termination of home services (e.g., automatic termination of home insurance due to violation of terms). and automatically update the calendar of maintenance tasks in real time in response to changes to the property profile or updates from the public databases, wherein the system notifies users of significant changes in maintenance schedules through a push notification system integrated with GUI. Luciani para. 94 teaches similarly, risk analysis module 370 requests risk data from risk evaluation resources 308 and does not alter the risk data for systems of the home, due to the absence of indications of performance or maintenance variations (e.g., indications from private data sources 301 that any system has a higher likelihood of failure relative to risk data from the risk evaluation resources 308). When the risk model 372 generated by risk analysis module 370 is conveyed to maintenance notification module 380, location-specific risk query generator engine 382 searches for any location-specific risks to systems of the home. Para. 95 teaches 95 location-specific risk query generator engine 382 generates a query that requests information from public data sources about risks to homes in the geographic region of the home being modeled by system 120. In this example, location-specific risk query generator engine 382 discovers a location-specific risk factor 483 that indicates increased rates of plumbing failure associated with homes in the geographic region of the home being modeled by system 120 (e.g., news feeds and permit requests from the local town the home is located in). Accordingly, risk model 372 is upgraded to reflect the location-specific risk factor 483 that indicates an elevated risk of failure in the plumbing system. Additionally, maintenance schedule and risk alerts 485 are generated by maintenance notification module 380. Luciani para. 112 teaches in response to receiving a system risk model 372 containing indicators of increased risk to the plumbing, electric, and insulation systems due to dynamic flood risk evaluations, maintenance notification module 380 commences the operation of engines of risk analysis module engines 381. Location-specific risk query generator engine 382 (pictured in FIG. 3B) confirms and corroborates the dynamic flood risks provided by risk evaluation resources 308. Maintenance schedule reporting engine 384 then prescribes changes to the report of maintenance schedule and risk alerts 385 for systems affected by the increased risk due to flooding. Consulting a table of systems and their respective vulnerabilities such as Table 1, maintenance notification module 370 generates and conveys information about a modified status of maintenance (e.g., a more urgent maintenance timeline) or additional maintenance needs (e.g., a specific upgrade to counteract the location-specific risks) in view of the indication of increased risks from location-specific risk query generator engine 382 or risk evaluation resources 308. This generated information is represented by update 610 to report of maintenance and risk alerts 385. Para. 78 teaches model intervention notifications engine 397 provides notifications regarding specific interventions that can be undertaken by a homeowner to reduce the cost of home services displayed on dashboard 399 via pricing display 386 for the home model. For systems that have an alert indicating risk exceeding a pre-determined threshold value of risk (e.g., systems with a corresponding alert on alert display 388 for home and home system models of dashboard 399), model intervention notifications engine 397 displays notifications relating to maintenance and other services that can reduce the excessive system risk of failure to levels below the pre-determined threshold of risk. As an example, if the model alert generation engine 396 generates an alert for the roofing system of a smart home 108 exceeding a pre-determined threshold value of risk, model intervention notifications engine 397 generates a notification indicating specific intervention services/upgrades that would reduce the risk of failure to the roofing system (e.g., notifications for intervention by performing maintenance for the roofing, or replacing the roofing). Additionally, model intervention notifications engine 397 projects costs to provide home services such as insurance using age- and risk-based price adjustment engine 394 to display projected savings resulting from the prescribed intervention services/upgrades being performed (e.g., savings when the roof receives a maintenance service, or when the roof is replaced). Para. 131 teaches the system continues to monitor the data from private data sources 301, risk evaluation resources 308, and location-specific risk query generator engine 382, in real-time, to dynamically update the pricing information, alerts, and notifications provided on dashboard 399. In this fashion, the system continuously updates the home model by updating the age model 368 and downstream system risk models. Wohlstadter does not explicitly disclose analyze the property data inputs to resolve any conflicts there between, thereby generating mastered data from the public databases representing characteristics of the property; However, Luciani para. 99 teaches age modeling module 350 of smart home modeling system 120 begins by receiving baseline data about the age of the home and its systems from public/government records of data server 112 associated with the home being modeled. In this example, data from public/government records of data server 112 does not include any indication that the electric box of the home has been upgraded (e.g., public/government data records of data server 112 are outdated and do not accurately reflect the current state of the house). Instead, age modeling module 350 receives records indicating the upgraded smart electric box from private data sources 301. Specifically, a user or homeowner submits an upgrade record for the smart electric box through records submission interface 304. Alternatively, smart device 110 (e.g., a smart electric utility monitor) can detect the upgraded electric box it is coupled to and report the upgrade information as sensor data from a sensor from the smart device. After receiving the upgrade records associated with the electric box through records submission interface 304, age modeling module 350 commences operation of the age modeling module engines 360. Both Wohlstadter and Luciani are directed to property maintenance. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date to modify the teachings of Wohlstadter to include dynamically update rules; generate a unique property profile applying the dynamically updated rules to the mastered data, wherein the property profile includes specific maintenance schedules tailored to the property's characteristics and geographic conditions; generate a calendar of maintenance tasks for the property for display on a graphical user interface (GUI); analyze the property data inputs to resolve any conflicts there between, thereby generating mastered data from the public databases representing characteristics of the property; and automatically update the calendar of maintenance tasks in real time in response to changes to the property profile or updates from the public databases, wherein the system notifies users of significant changes in maintenance schedules through a push notification system integrated with GUI as taught by Luciani to most accurately represent the current state of a property which results in a more reliable system (see paras. 2-3). Wohlstadter does not teach wherein the GUI provides interactive functionality allowing a user to add, modify, or delete maintenance tasks directly within the calendar interface Ansari para. 234 teaches when the user sets a schedule on any of the home automation devices, the schedule will be integrated on a calendar application. For example, if the user has scheduled housekeeping tasks at specified times, then the calendar automatically reflects those tasks. In each user's calendar, only the tasks assigned by that user are reflected. Similarly, if the user has utilized the scene builder to generate a ânight sceneâ that is initiated at 8 p.m. everyday, then the calendar shows the scheduling of the ânight sceneâ everyday at 8 p.m. The user is then able to click on the scheduled tasks and modify the task. When the tasks are displayed on the calendar, the user may click on the task and make any changes on the task. The calendar is updated to reflect the changes. Thus, if the time of the scheduled task was moved from 8 p.m. to 9 p.m., then the calendar automatically refreshes to show the new scheduled time. Both Wohlstadter in view Luciani and Ansari are directed to property management. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date to modify the teachings of Wohlstadter in view Luciani to include wherein the GUI provides interactive functionality allowing a user to add, modify, or delete maintenance tasks directly within the calendar interface as taught by Ansari to provide a user with added flexibility to update a calendar based on their needs. Wohlstadter in view of Luciani in view of Settino does not teach using a machine learning algorithm to resolve any conflicts. However, Lu para. 91-94 teaches In FIG. 4, it illustrates an example of the underlying AI techniques of knowledge discovery and policy understanding, which serve as the technical foundations in the areas of such as policy and contracts renewal, upgrades, and promotions, according to an example of the present disclosure. As illustrated, at block 400, entity extraction 410 may be performed from a database 405, such as the risk control and knowledge management database 115, which is to identify the entities across the documents including, for instance, metadata of the entity, such as entity type and entity ID, and metadata of the users. At block 415, after recognizing the entities and identifying their values, entity resolution is applied across the documents to resolve the entity conflicts or multiple names that refer to the same entity. In an example, the extracted entities, such as âAppleâ and âApple Inc.â, âBananaâ and âBanana Republicâ, can be distinguished as âApple is a fruit nameâ, âApple Inc. is a company nameâ, âBanana is a fruit nameâ, âBanana Republic is a company nameâ by entity resolution techniques. In another example, the extracted entities, such as âDonald Trumpâ, âDonald J. Trumpâ, âPresident Trumpâ, can be recognized as the same entity in a resolved form, Donald Trump. At block 420, the extracted entities are processed by entity categorizers or configurations, which are to categorize the entities into corresponding categories (including location, person name, organization name, etc.). A category may be descriptive of an entity type. The entity categorization may include classification or cluster of entities in various categories. At block 425, entity relationship extraction may be performed, where the entities relations may be identified by phrases, such as âis insured byâ, âIs a subcategory ofâ, etc. In an example, Natural Language Processing techniques and Information retrieval techniques, including supervised learning, unsupervised learning, and semi-supervised learning, such as conditional random fields, may be used for entity extraction, entity resolution, entity categorization, and entity relationship extraction. After entity relationship extraction at block 425, the entities and the entity values that are extracted are categorized can be stored in one or more data structures, which enable to construct knowledge storage (including knowledge graphs, rules, and models) and sit in risk control and knowledge management database 115. At block 430, artificial intelligence and machine learning techniques, such as inference techniques, causality reasoning, and hidden knowledge refinery, may be implemented to the identified relationships to understand the policies and contracts, to obtain the hidden rules and govern the policies and contracts renewal, upgrades, and promotions by underlying risk control models and recognized hidden management rules. The updated policies and contracts may be in turn to provide feedbacks to enrich the knowledge storage in the form of, such as knowledge graphs, rules, and models by reinforcement learning. The rules may be updated and renewed by techniques, such as random forest, decision trees, and other rule learning methods. Further, the specific number in the contract, for example, the coverage under a specific condition is predicted by Lasso regression techniques or other AI techniques. For instance, upon the analysis of property history and customer values, certain terms and conditions of the risk control and knowledge management policies/contracts may be revised, premium may be changed, and the risk control models for a user may be upgraded, and a related coverage may be promoted to the user. As an output that shown at block 435, a renewed risk control and knowledge management document may be provided. Moreover, new or related products may be recommended to users based on using AI techniques, such as, pagerank, matrix factorization, and deep neural networks. Both Wohlstadter in view of Luciani in view of Settino and Lu are directed to property maintenance. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date to modify the teachings of Wohlstadter in view of Luciani in view of Settino to include teach using a machine learning algorithm to resolve any conflicts as taught by Lu improve the accuracy of the analysis. As per Claim 2 Wohlstadter teaches the system of claim 1, wherein the one or more property data inputs are selected from the group consisting of local assessment records, real estate listings, construction permit records, neighboring homes data, homeowner input data, prior homeowner data, appliance maintenance schedules, material data, appliance and parts expected life data and anticipated replacement dates, survey data, weather databases and combinations thereof. Wohlstadter para. 96 teaches in some embodiments for practicing aspects of the invention, the property owner may register property on a system using User Controls 100, as illustrated in a non-limiting example of FIGS. 21A-D. An example of a process of creating a property in the system is defined in FIG. 4A. In step 400, the user creates a Property Table 305 along with a default empty Inventory Table 306, for example, through an interface illustrated in a non-limiting example of FIG. 21A. The Property Table 305 could have a type of property information, e.g., commercial or residential property, or the property could be land only. Each of these types of property may be further characterized. For example, a residential property could be described in a free-form text style or by selecting from a list such as single-family homes, town homes, condos, apartments, lofts, mobile homes, trailers and so forth, as illustrated in a non-limiting example of FIG. 21C. In step 401, the user is prompted to enter property information, also as illustrated in a non-limiting example of FIG. 21C. This information may include, for example, address, property features, emergency contact information, preferred payment methods, etc. The property owner may provide such information as building details, such as construction date, type of construction materials used, gross area, real estate tax, liens on the property, restrictive property covenants and easements appurtenant to the property, year-to date vacancy rate and whether or not pets and children are allowed for rental properties, as illustrated in a non-limiting example of FIG. 21D. This description could also include the systems in the home; such as, air conditioning, heating, electrical, plumbing, cable, telephone, network, and the like, also as illustrated in a non-limiting example of FIG. 21D. As part of the home description, the user could specify what information from this description should be made public about the home. The description can be provided as user-supplied text, as picks on a menu(s), or as some combination. The system may advantageously provide for password protection of the accounts. Para. 86 teaches according to one aspect of the invention, Database subsystem 208 initially may be populated using a Populater subsystem (unmarked) which captures the property history information directly or indirectly from publicly accessible data. Capturing directly or indirectly includes, but is not limited to, receiving information from websites, such as county websites, or electronic feeds in either electronic form that can be imported into the system according to an algorithm, or in a form of a printout. As used herein, publicly accessible data includes public and private records accessible to the system such as, for example, freely accessible records and records accessible on a fee-for-service or subscription basis. Alternatively, or before or after capturing the property history information directly or indirectly from publicly accessible data, Database system 208 may be populated by the record owner, or a user whom the record owner delegates the authorization to update property information. For example, such a delegate might be a service provider who executed a project on a property; that person would enter information about one or more properties--e.g., at different times over a span of time.) As per Claim 3 Wohlstadter teaches the system of claim 1, wherein the manual user inputs are from an owner or manager of the property. (Wohlstadter para. 93 teaches one aspect of the present invention is the ability for a property owner, manager or renter, herein referred to as "user", to describe one or more properties to be published on a public online forum, for example, at a site on the world-wide web. Prior to publication, a person or entity preferably is required to join the system using a process such as the process defined in FIG. 10. When a user executes step 1001 to "Join", the system creates an entry in User Table 303, or creates a new User Table. If the user is not a service provider, as checked in step 1002, the user is given an opportunity to define his information in step 1003, storing the information in User Table 303. Next, in step 1004, the user, optionally, defines account information for integration with various third-party marketplaces, and the information is stored in External Market Info Table 317. If, in step 1008, the user, optionally, decides to create a trusted community, the processing is continued through step 500 in FIG. 5A to create the community and the processing continues through step 503 in FIG. 5B to add members to the community. Editing user and provider information is provided through steps 1013 and 1014. Step 1015 enables a user to add members to an existing community and step 1010 checks to only initiate the activation process in step 1011 if the user is new. Once complete and activated, the user may begin defining his property or properties.) As per Claim 4 Wohlstadter teaches the system of claim 1, wherein the GUI is displayed on a website in response to a user request made to a web server over the Internet from a computer in network communication with the software module. (Para. 57 teaches FIG. 16 is an illustration of one example of an initial user system interface through a World Wide Web homepage. Further, Para. 79 teaches the User Controls component 100 represents a mechanism by means of which someone or something may be operatively connected to the Home Management System component 101 to command the application to perform certain tasks. The User Controls component 100 could be operating on a personal computer or a server using a Windows, Linux, Mac OS, UNIX, or other operating system, or a web-enabled cell phone, wireless communication device or other personal digital assistant, and/or any other computer. The User Controls component 100 may be operatively connected to the internet and/or some other private and/or public network(s) via one or more communication devices.) As per Claim 7 Wohlstadter teaches the system of claim 1, further comprising a vendor portal in network communication with the system, wherein a vendor may bid on the execution of a maintenance task through the vendor portal. (Wohlstadter para. 115 teaches Another aspect of the invention is the data structures and computer-implemented procedures which provide the ability to document and execute home projects. Such procedures include, for example, tracking changes to the homeowner's tax basis in the home based on past and present project work. They may also include submitting entered projects for bid to service providers participating in the public forum, such as, for example, by communicating this information via the World Wide Web or a public or private network.) As per Claim 8 Wohlstadter the system of claim 7, wherein a user may hire the vendor for the completion of the maintenance task. (Para. 118 teaches the system may then collect bids and allow the user to review bids and select a service provider. The selection may be assisted by using computer algorithms based on bid price, rank ordering or combination thereof.) As per Claim 11 Wohlstadter teaches a method for scheduling and managing property maintenance tasks using the system of claim 1, the method comprising: viewing calendar of maintenance tasks generated on the GUI according to claim 1; selecting a maintenance task; and . (Wohlstadter Para. 117 teaches the information on the project may be input by the user at various times, thereby allowing the history of a project to be recorded in increments. Optionally (and not shown), the system may automatically populate a routine maintenance calendar for the user's review and approval, e.g., scheduling gardening, gutter cleaning, heating oil delivery, air conditioning maintenance and other routine services and record the completion of each routine maintenance event (in some instances, automatically or semi-automatically), with or without verification by a user. Yet in other embodiments, the user may manually populate a routine maintenance calendar. Yet in another embodiment, the system may contain a `reminder` module which populates reminders to the user to schedule desired or recommended maintenance tasks.) taking an action selected from the group consisting of marking the maintenance task as completed, rescheduling the maintenance task or deleting the maintenance task. Wohlstadter para. 116 teaches the information on the project may be input by the user at various times, thereby allowing the history of a project to be recorded in increments. Optionally (and not shown), the system may automatically populate a routine maintenance calendar for the user's review and approval, e.g., scheduling gardening, gutter cleaning, heating oil delivery, air conditioning maintenance and other routine services and record the completion of each routine maintenance event (in some instances, automatically or semi-automatically), with or without verification by a user. Yet in other embodiments, the user may manually populate a routine maintenance calendar. Yet in another embodiment, the system may contain a `reminder` module which populates reminders to the user to schedule desired or recommended maintenance tasks. As per Claim 12 Wohlstadter teaches The method of claim 11, wherein the GUI is displayed on a website in response to a user request made to a web server over the Internet from a computer in network communication with the software module, the maintenance task is selected using the website, and the action is taken using the website. (Para. 57 teaches FIG. 16 is an illustration of one example of an initial user system interface through a World Wide Web homepage. Further, Para. 79 teaches the User Controls component 100 represents a mechanism by means of which someone or something may be operatively connected to the Home Management System component 101 to command the application to perform certain tasks. The User Controls component 100 could be operating on a personal computer or a server using a Windows, Linux, Mac OS, UNIX, or other operating system, or a web-enabled cell phone, wireless communication device or other personal digital assistant, and/or any other computer. The User Controls component 100 may be operatively connected to the internet and/or some other private and/or public network(s) via one or more communication devices.) As per Claim 14 Wohlstadter teaches a method of bidding on the execution of a maintenance task, the method comprising: providing a vendor portal according to claim 7; and bidding on the execution of a maintenance task through the vendor portal. Wohlstadter para. 115 teaches another aspect of the invention is the data structures and computer-implemented procedures which provide the ability to document and execute home projects. Such procedures include, for example, tracking changes to the homeowner's tax basis in the home based on past and present project work. They may also include submitting entered projects for bid to service providers participating in the public forum, such as, for example, by communicating this information via the World Wide Web or a public or private network. As per Claim 15 Wohlstadter teaches a method of hiring a vendor for the execution of a maintenance task, the method comprising accepting a bid for execution of the maintenance task made according to claim 14. (Para. 118 teaches the system may then collect bids and allow the user to review bids and select a service provider. The selection may be assisted by using computer algorithms based on bid price, rank ordering or combination thereof.) Claim(s) 5, 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wohlstadter US 20120265633 A1 in view of Luciani US 20220245290 A1 in view of Settino US 20130290052 A1 in view of Ansari US 2017/0344703 A1 in view of Lu US 2019/0197442 A1 as applied to claim 1 and in further view of Ramer US 2020/0342421 A1. As per Claim 5 Wohlstadter teaches the system of claim 1, wherein the GUI is displayed on a device comprising a mobile application in network communication with the software module. (Para. 57 teaches FIG. 16 is an illustration of one example of an initial user system interface through a World Wide Web homepage. Further, Para. 79 teaches the User Controls component 100 represents a mechanism by means of which someone or something may be operatively connected to the Home Management System component 101 to command the application to perform certain tasks. The User Controls component 100 could be operating on a personal computer or a server using a Windows, Linux, Mac OS, UNIX, or other operating system, or a web-enabled cell phone, wireless communication device or other personal digital assistant, and/or any other computer. The User Controls component 100 may be operatively connected to the internet and/or some other private and/or public network(s) via one or more communication devices.) Wohlstadter does not teach a mobile application configured with an application programming interface (API) However, Ramer para. 24 teaches the connections may be achieved by software or middleware interfaces, by the use of application programming interfaces (APIs), by data integration systems (such as for extraction, transformation, transport and loading of information between systems having distinct data types and using distinct protocols), and by the use of services, such as in services oriented architectures.) Both Wohlstadter and Ramer are directed to property maintenance. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicantâs invention to modify the teachings of Wohlstadter to include a mobile application configured with an application programming interface (API) as taught by Ramer to more reliably ensure that a single service provider to perform the kinds of analysis required to ensure effective matching of service providers to homeowners, to ensure consistent and efficient repairs and to perform accurate cost estimation and pricing analysis (see para. 24). As per Claim 13 Wohlstadter teaches the system of claim 1, wherein the GUI is displayed on a device comprising a mobile application in network communication with the software module, the maintenance task is selected using the website, (Para. 57 teaches FIG. 16 is an illustration of one example of an initial user system interface through a World Wide Web homepage. Further, Para. 79 teaches the User Controls component 100 represents a mechanism by means of which someone or something may be operatively connected to the Home Management System component 101 to command the application to perform certain tasks. The User Controls component 100 could be operating on a personal computer or a server using a Windows, Linux, Mac OS, UNIX, or other operating system, or a web-enabled cell phone, wireless communication device or other personal digital assistant, and/or any other computer. The User Controls component 100 may be operatively connected to the internet and/or some other private and/or public network(s) via one or more communication devices.) Wohlstadter does not teach configured with an application programming interface (API). However, Ramer para. 24 teaches the connections may be achieved by software or middleware interfaces, by the use of application programming interfaces (APIs), by data integration systems (such as for extraction, transformation, transport and loading of information between systems having distinct data types and using distinct protocols), and by the use of services, such as in services oriented architectures.) Both Wohlstadter and Ramer are directed to property maintenance. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicantâs invention to modify the teachings of Wohlstadter to include a mobile application configured with an application programming interface (API) as taught by Ramer to more reliably ensure that a single service provider to perform the kinds of analysis required to ensure effective matching of service providers to homeowners, to ensure consistent and efficient repairs and to perform accurate cost estimation and pricing analysis (see para. 24). Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wohlstadter US 20120265633 A1 in view of Luciani US 20220245290 A1 in view of Settino US 20130290052 A1 in view of Ansari US 2017/0344703 A1 in view of Lu US 2019/0197442 A1 as applied to claim 1 and in further view of Garber US 2020/0210965 A1. As per Claim 6 Wohlstadter does not teach the system of claim 1, wherein a user may change the calendar of maintenance tasks by rescheduling or deleting the maintenance tasks from the calendar. However, Garber para. 456 teaches with reference to the lower schedule in FIG. 35, the task identified as being scheduled in an unoptimized manner was task 3514 and the schedule change may include rescheduling task 3514 to a different time. In a related embodiment, rescheduling the identified task to a different time may include suggesting a user one or more alterative times selected by the updated native scheduling engine. Both Wohlstadter and Garber are directed to scheduling tasks. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicantâs invention to modify the teachings of Wohlstadter to include wherein a user may change the calendar of maintenance tasks by rescheduling or deleting the maintenance tasks from the calendar as taught by Garber to more provide users with the ability to reschedule tasks which results in a more customer friendly system. Claim(s) 9, 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wohlstadter US 20120265633 A1 in view of Luciani US 20220245290 A1 in view of Settino US 20130290052 A1 in view of Ansari US 2017/0344703 A1 in view of Lu US 2019/0197442 A1 as applied to Claim 8 and in further view of Reed US 2021/0182924 A1. As per Claim 9 Wohlstadter teaches collecting bids and hiring service providers, but does not explicitly disclose the system of claim 8, wherein the vendor may invoice the user for completion of the maintenance task. However, Reed para. 1 teaches This invention relates to the class of data processing systems or methods, specially adapted for administrative, commercial, financial, managerial, supervisory or forecasting purposes; and to one or more sub-classes related to forecasting or optimization; commerce; or systems or methods specially adapted for specific business sectors. Specifically, this invention relates to systems and methods to match property owners with property maintenance service providers. Para. 48 teaches after the billing session has ended, the User 213 receives an invoice from the Intermediating Process 3, which is automatically charged to the User's 213 payment method listed as a Payment Preference 35. The User 213 provides feedback 31 on the Provider 113 and the quality of work provided, if desired, and the work session ends 32. Feedback 31 can be a numerical rating, a letter grade, answers to survey questions, or selection of appropriate feedback from a list of possible feedback. Both Wohlstadter and Reed are directed to scheduling and performing tasks. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicantâs invention to modify the teachings of Wohlstadter to include wherein the vendor may invoice the user for completion of the maintenance task as taught by Reed to provide a more efficient way for providers and requestors to facilitate transactions (as suggested by para. 4). As per Claim 10 Wohlstadter teaches collecting bds and hiring service providers, but does not explicitly disclose the system of claim 9, pay the vendor for the completion of the maintenance task electronically. However, Reed para. 1 teaches This invention relates to the class of data processing systems or methods, specially adapted for administrative, commercial, financial, managerial, supervisory or forecasting purposes; and to one or more sub-classes related to forecasting or optimization; commerce; or systems or methods specially adapted for specific business sectors. Specifically, this invention relates to systems and methods to match property owners with property maintenance service providers. Para. 48 teaches after the billing session has ended, the User 213 receives an invoice from the Intermediating Process 3, which is automatically charged to the User's 213 payment method listed as a Payment Preference 35. The User 213 provides feedback 31 on the Provider 113 and the quality of work provided, if desired, and the work session ends 32. Feedback 31 can be a numerical rating, a letter grade, answers to survey questions, or selection of appropriate feedback from a list of possible feedback. Both Wohlstadter and Reed are directed to scheduling and performing tasks. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicantâs invention to modify the teachings of Wohlstadter to include pay the vendor for the completion of the maintenance task electronically as taught by Reed to provide a more efficient way for providers and requestors to facilitate transactions (as suggested by para. 4). Claim(s) 16, 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wohlstadter US 20120265633 A1 in view of Luciani US 20220245290 A1 in view of Settino US 20130290052 A1 in view of Ansari US 2017/0344703 A1 in view of Lu US 2019/0197442 A1 as applied to Claim 15 and in further view of Reed US 2021/0182924 A1. As per Claim 16 Wohlstadter teaches collecting bids and hiring service providers, but does not explicitly disclose a method of invoicing a property manager or owner following the execution of a maintenance task, the method comprising: transmitting an invoice to the property manager or owner, wherein the property manager or owner was responsible for hiring a vendor according to claim 15. However, Reed para. 1 teaches This invention relates to the class of data processing systems or methods, specially adapted for administrative, commercial, financial, managerial, supervisory or forecasting purposes; and to one or more sub-classes related to forecasting or optimization; commerce; or systems or methods specially adapted for specific business sectors. Specifically, this invention relates to systems and methods to match property owners with property maintenance service providers. Para. 48 teaches after the billing session has ended, the User 213 receives an invoice from the Intermediating Process 3, which is automatically charged to the User's 213 payment method listed as a Payment Preference 35. The User 213 provides feedback 31 on the Provider 113 and the quality of work provided, if desired, and the work session ends 32. Feedback 31 can be a numerical rating, a letter grade, answers to survey questions, or selection of appropriate feedback from a list of possible feedback. Both Wohlstadter and Reed are directed to scheduling and performing tasks. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicantâs invention to modify the teachings of Wohlstadter to include transmitting an invoice to the property manager or owner, wherein the property manager or owner was responsible for hiring a vendor according to claim 15 as taught by Reed to provide a more efficient way for providers and requestors to facilitate transactions (as suggested by para. 4). As per Claim 17 Wohlstadter teaches collecting bids and hiring service providers, but does not explicitly disclose the method of claim 16, further comprising the step of the property managing or owner paying the vendor for completion of the property maintenance task. However, Reed para. 1 teaches This invention relates to the class of data processing systems or methods, specially adapted for administrative, commercial, financial, managerial, supervisory or forecasting purposes; and to one or more sub-classes related to forecasting or optimization; commerce; or systems or methods specially adapted for specific business sectors. Specifically, this invention relates to systems and methods to match property owners with property maintenance service providers. Para. 48 teaches after the billing session has ended, the User 213 receives an invoice from the Intermediating Process 3, which is automatically charged to the User's 213 payment method listed as a Payment Preference 35. The User 213 provides feedback 31 on the Provider 113 and the quality of work provided, if desired, and the work session ends 32. Feedback 31 can be a numerical rating, a letter grade, answers to survey questions, or selection of appropriate feedback from a list of possible feedback. Both Wohlstadter and Reed are directed to scheduling and performing tasks. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicantâs invention to modify the teachings of Wohlstadter to include the property managing or owner paying the vendor for completion of the property maintenance task as taught by Reed to provide a more efficient way for providers and requestors to facilitate transactions (as suggested by para. 4). Conclusion Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEIRDRE D HATCHER whose telephone number is (571)270-5321. The examiner can normally be reached Monday-Friday 8-4:30. 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, Brian Epstein can be reached at 571-270-5389. 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. /DEIRDRE D HATCHER/Primary Examiner, Art Unit 3625