DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on XXXXXXXXXXXXXX has been entered.
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 .
Status of Claims
Claims 2-6, 9-13, 17-20 are canceled.
Claims 21-31 are new.
Claims 1, 7, 8, 14-16, 21-31 are pending and have been examined.
This action is in reply to the papers filed on 08/18/2026 (effective filing date 01/29/2021).
Information Disclosure Statement
No Information Disclosure Statement has been filed.
The information disclosure statement(s) submitted: xxxxxxxx, has/have been considered by the Examiner and made of record in the application file.
Amendment
The present Office Action is based upon the original patent application filed on 03/28/2025 as modified by the amendment filed on 08/18/2026.
Terminal Disclaimer
The terminal disclaimer filed on xxx disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of US Pat. No. xxxx has been reviewed and has been placed in the file.
Double Patenting - Withdrawn
The double patenting rejection is withdrawn per the filed terminal disclaimer noted above.
Reasons For Allowance
Prior-Art Rejection withdrawn
Claims 1, 7, 8, 14-16, 21-31 are allowable over the prior-art, however, subject to 35 USC §101 subject matter eligibility rejection and/or 35 USC §112 rejections noted herein. The closest prior art (See PTO-892, Notice of References Cited) does not teach the claimed: Claim 1. (Currently Amended) A method comprising: performing, using at least one hardware processor, design model validation, wherein design model validation comprises entering building permit application file information and checking the building permit application file information against relevant building codes, ordinances and regulations, with or without using a taxonomy or code logic by processing the building permit application file information against computable building requirement rules generated from translating a semantic structure of a building code, ordinance, or regulation using first-order logic, neural natural language processing, and fuzzy logic; performing, using the at least one hardware processor, exchange model code checking, wherein exchange model code checking comprises using a plurality of exchange models; performing, using the at least one hardware processor, code conformance checking, wherein the code conformance checking comprises receiving a request from the exchange models and passing the building permit application file information to code checking modules configured to check building code provisions and one or more regulations per local, state, national or international requirements, wherein the code checking modules process first object rules corresponding to objective code requirements and second object rules corresponding to uncertain code requirements against a software design model of the building permit application file information; performing, using the at least one hardware processor, verification reporting based on input provided from the code checking modules; performing, using the at least one hardware processor, results reporting based on findings of the verification reporting; and generating and outputting, by the at least one hardware processor, prediction confidence data for the code conformance checking or the verification reporting, wherein an inaccurate prediction of code conformance is fed back to a neural network to improve accuracy of building code conformance review.
The closest prior-art (Nawari, Conover 2009/0125283, Morimoto et al. 2014/0337008, Roth et al. 2008/0059220) teach the features as disclosed in Non-final Rejection (02/23/2026), however, these cited references do not teach and the prior-art does not teach at least the following combination of features and/or elements:
Claim 1. (Currently Amended) A method comprising: … processing the building permit application file information against computable building requirement rules generated from translating a semantic structure of a building code, ordinance, or regulation using first-order logic, neural natural language processing, and fuzzy logic; performing, using the at least one hardware processor, exchange model code checking, wherein exchange model code checking comprises using a plurality of exchange models; performing, using the at least one hardware processor, code conformance checking, wherein the code conformance checking comprises receiving a request from the exchange models and passing the building permit application file information to code checking modules configured to check building code provisions and one or more regulations per local, state, national or international requirements, wherein the code checking modules process first object rules corresponding to objective code requirements and second object rules corresponding to uncertain code requirements against a software design model of the building permit application file information; performing, using the at least one hardware processor, verification reporting based on input provided from the code checking modules; performing, using the at least one hardware processor, results reporting based on findings of the verification reporting; and generating and outputting, by the at least one hardware processor, prediction confidence data for the code conformance checking or the verification reporting, wherein an inaccurate prediction of code conformance is fed back to a neural network to improve accuracy of building code conformance review.
Claim Rejections - 35 USC §101 - Withdrawn
Per Applicant’s amendments and arguments and considering new guidance in the MPEP, the rejections are withdrawn. Specifically, in Applicant’s Remarks (dated 03/14/2017, pgs. 8-11), Applicant traverses the 35 USC §101 rejections arguing that the amended claims recite new limitations that are not abstract, amount to significantly more, are directed to a practical application, etc… For example, Applicant argues….
In support of their arguments, Applicant cites to the following recent Fed. Cir. court cases (i.e., Alice Corp. v. CLS Bank Int’l, SRI Int’l, Inc. v. Cisco Systems, Inc., Ultramercial, Inc. v. Hulu, LLC, Berkheimer, Core Wireless, McRO, Enfish, Bascom, DDR, etc…).
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1, 7, 8, 14-16, 21-31are rejected on the ground of anticipatory-nonstatutory double patenting as being unpatentable over claims 1-17 of U.S. Patent No. 12,020,339.
19/094,455 – Claim 1. A method comprising:
US 12,020,339 – Claim 1. A method comprising:
19/094,455 – Claim 1. performing, using at least one hardware processor, design model validation, wherein design model validation comprises entering building permit application file information and checking the building permit application file information against relevant building codes, ordinances and regulations, with or without using a taxonomy or code logic;
US 12,020,339 – Claim 1. performing, using at least one hardware processor, design model validation, wherein design model validation comprises receiving building permit application file information and checking the building permit application file information against relevant building codes, ordinances and regulations-using a taxonomy classification;
19/094,455 – Claim 1. performing, using the at least one hardware processor, exchange model code checking, wherein exchange model code checking comprises using a plurality of exchange models;
US 12,020,339 – Claim 1. performing, using the at least one hardware processor, exchange model code checking, wherein exchange model code checking comprises using a plurality of exchange models to identify a code exchange utilized in the building permit application file information;
19/094,455 – Claim 1. performing, using the at least one hardware processor, code conformance checking, wherein the code conformance checking comprises receiving a request from the exchange models and passing the building permit application file information to code checking modules configured to check building code provisions and one or more regulations per local, state, national or international requirements;
US 12,020,339 – Claim 1. performing, using the at least one hardware processor, code conformance checking, wherein the code conformance checking comprises receiving a request from the exchange models and passing the building permit application file information to code checking modules configured to check building code provisions and one or more regulations per local, state, national or international requirements against the computable model;
19/094,455 – Claim 1. performing, using at least one hardware processor, verification reporting based on input provided from the code checking modules; and
US 12,020,339 – Claim 1. performing, using at least one hardware processor, verification reporting based on input provided from the code checking modules; and
19/094,455 – Claim 1. performing, using at least one hardware processor, results reporting based on findings of the verification reporting.
US 12,020,339 – Claim 1. performing, using at least one hardware processor, results reporting based on findings of the verification reporting.
19/094,455 – Claim 2. The method of claim 1, wherein the exchange models comprise at least a building code regulations and architectural design use case exchange model, a building code regulations and structural design use case exchange model, a building code regulations and mechanical system design use case exchange model, a building code regulations and electrical design use case exchange model, a building code regulations and plumbing design use case exchange model, a building code regulations and fire protection design use case exchange model, and a building code regulations and results reporting use case exchange model.
US 12,020,339 – Claim 2. The method of claim 1, wherein the exchange models comprise at least a building code regulations and architectural design use case exchange model, a building code regulations and structural design use case exchange model, a building code regulations and mechanical system design use case exchange model, a building code regulations and electrical design use case exchange model, a building code regulations and plumbing design use case exchange model, a building code regulations and fire protection design use case exchange model, and a building code regulations and results reporting use case exchange model.
19/094,455 – Claim 3. The method of claim 1, wherein the code checking modules comprise at least an architectural design checking module, a structural design checking module, a mechanical, electrical, plumbing design checking module, or a fire protection design checking module.
US 12,020,339 – Claim 3. The method of claim 1, wherein the code checking modules comprise at least an architectural design checking module, a structural design checking module, a mechanical, electrical, plumbing design checking module, or a fire protection design checking module.
19/094,455 – Claim 4. The method of claim 1, further comprising transforming, by the hardware processor, a building code regulation into a computable record that defines a building design and/or engineering rule for the building code regulation.
US 12,020,339 – Claim 4. The method of claim 1, wherein the transforming, using the at least one hardware processor, taxonomy classifications of the relevant building codes, ordinances and regulations into the computable model comprises transforming, by the hardware processor, a building code regulation into a computable record that defines a building design and/or engineering rule for the building code regulation.
19/094,455 – Claim 5. The method of claim 4, wherein a semantic structure of the building code regulation is translated into object rules or parametric models and associated with the building permit application file information being examined.
US 12,020,339 – Claim 5. The method of claim 4, wherein a semantic structure of the building code regulation is translated into object rules or parametric models and associated with the building permit application file information being examined.
19/094,455 – Claim 6. The method of claim 4, wherein the building code regulation is transformed using a Transformation Logic Algorithm (TLA), neural Natural Language Processing (NLP) techniques, or artificial intelligence.
US 12,020,339 – Claim 6. The method of claim 4, wherein the building code regulation is transformed using a Transformation Logic Algorithm (TLA), neural Natural Language Processing (NLP) techniques, or artificial intelligence.
19/094,455 – Claim 7. The method of claim 1, further comprising graphically displaying, by the hardware processor, a semi-transparent interface embedded with one or more buttons for initiating an action of code conformance checking.
US 12,020,339 – Claim 1. graphically displaying, by the at least one hardware processor, an interface embedded with one or more buttons for initiating an action of code conformance checking;
19/094,455 – Claim 8. A system comprising: at least one hardware processor; and one or more software modules that are configured to, when executed by the at least one hardware processor: perform design model validation, wherein design model validation comprises entering building permit application file information and checking the building permit application file information against relevant codes and regulations, using a taxonomy or neural Natural Language Processing (NLP) or artificial intelligence; perform exchange model code checking, wherein exchange model code checking comprises using a plurality of exchange models; perform code conformance checking, wherein the code conformance checking comprises receiving a request from the exchange models and passing the building permit application file information to code checking modules configured to check building code provisions and one or more regulations per local, state, national or international requirements; perform verification reporting based on input provided from the code checking modules; and perform results reporting results reporting based on findings of the verification reporting.
19/094,455 – Claim 9. The system of claim 8, wherein the exchange models comprise at least a building code regulations and architectural design use case exchange model, a building code regulations and structural design use case exchange model, a building code regulations and mechanical system design use case exchange model, a building code regulations and electrical design use case exchange model, a building code regulations and plumbing design use case exchange model, a building code regulations and fire protection design use case exchange model, and a building code regulations and results reporting use case exchange model.
19/094,455 – Claim 10. The system of claim 8, wherein the code checking modules comprise at least an architectural design checking module, a structural design checking module, a mechanical, electrical, plumbing design checking module, or a fire protection design checking module.
19/094,455 – Claim 11. The system of claim 8, wherein the one or more software modules are configured to, when executed by the at least one hardware processor, to transform a building code regulation into a computable record that defines a building design and engineering rule for the building code regulation.
19/094,455 – Claim 12. The system of claim 11, wherein a semantic structure of the building code regulation is translated into object rules or parametric models and associated with the building permit application file information being examined.
19/094,455 – Claim 13. The system of claim 11, wherein the building code regulation is transformed using a Transformation Logic Algorithm (TLA), the neural Natural Language Processing (NLP) techniques, or the artificial intelligence.
19/094,455 – Claim 14. The system of claim 11, wherein the one or more software modules are configured to, when executed by the at least one hardware processor, to graphically display a semi-transparent interface embedded with one or more buttons for initiating an action of code conformance checking.
19/094,455 – Claim 15. A non-transitory computer-readable medium having instructions stored therein, wherein the instructions, when executed by a processor, cause the processor to: perform design model validation, wherein design model validation comprises entering building permit application file information and checking the building permit application file information against relevant codes and regulations, using a taxonomy; perform exchange model code checking, wherein exchange model code checking comprises using a plurality of exchange models; perform code conformance checking, wherein the code conformance checking comprises receiving a request from the exchange models and passing the building permit application file information to code checking modules configured to check building code provisions and any regulations per local, state, national or international requirements; perform verification reporting based on input provided from the code checking modules; and perform results reporting results reporting based on findings of the verification reporting.
19/094,455 – Claim 16. The non-transitory computer-readable medium of claim 15, wherein the instructions, when executed by a processor, cause the processor to graphically display a semi-transparent interface embedded with one or more buttons for initiating an action of code conformance checking.
19/094,455 – Claim 17. The non-transitory computer-readable medium of claim 15, wherein the exchange models comprise at least a building code regulations and architectural design use case exchange model, a building code regulations and structural design use case exchange model, a building code regulations and mechanical system design use case exchange model, a building code regulations and electrical design use case exchange model, a building code regulations and plumbing design use case exchange model, a building code regulations and fire protection design use case exchange model, and a building code regulations and results reporting use case exchange model.
19/094,455 – Claim 18. The non-transitory computer-readable medium of claim 15, wherein the code checking modules comprise at least an architectural design checking module, a structural design checking module, a mechanical, electrical, plumbing design checking module, or a fire protection design checking module.
19/094,455 – Claim 19. The non-transitory computer-readable medium of claim 15, wherein the instructions, when executed by a processor, cause the processor to transform a building code regulation into a computable record that defines a building design rule for the building code regulation.
19/094,455 – Claim 20. The non-transitory computer-readable medium of claim 19, wherein the building code regulation is transformed using a Transformation Logic Algorithm (TLA), neural Natural Language Processing (NLP) techniques, or artificial intelligence.
The remaining independent claims contain feature similar to that of claim 1 and are rejected accordingly. The dependent claims are further rejected for their dependency upon a rejected independent base 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, 7, 8, 14-16, and 21-31 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (an abstract idea) without significantly more, applying the framework of Alice Corp. v. CLS Bank Int'l, 573 U.S. 208 (2014) and Mayo Collaborative Servs. v. Prometheus Labs., Inc., 566 U.S. 66 (2012), as set forth in MPEP § 2106.
In plain terms: a claim is patent-eligible only if (1) it fits one of the four statutory categories (process, machine, manufacture, or composition of matter); and if it recites an abstract idea, mathematical concept, or mental process, (2) the claim as a whole must add enough beyond that idea — either by integrating it into a practical application, or by reciting an inventive concept — to be "significantly more" than the abstract idea itself. Simply asking a generic computer, a generic AI technique, or a generic module to carry out a task a human could otherwise do with a rulebook and a checklist is not enough.
Claim 1 is treated below as representative. The analysis applies equally to independent claims 8 and 15, which recite substantially the same subject matter in system and non-transitory computer-readable medium (CRM) form, respectively. Differences among claims 1, 8, and 15, and the separate dependent claims, are addressed in their own subsections.
STEP 1 — Statutory Category
Claim 1 is directed to a method (a process) performed "using at least one hardware processor" and is therefore statutory subject matter under Step 1. Claim 8 recites a system comprising "at least one hardware processor" and "one or more software modules," and is directed to a machine. Claim 15 recites "a non-transitory computer-readable medium having instructions stored therein," and is directed to an article of manufacture. All three independent claims, and their dependents, therefore, fall within a statutory category and are not rejected at Step 1 for failing to recite one of the four classes.
Electromagnetic signal per se / software per se check: Examiner has specifically considered whether any claim is directed to a signal per se (In re Nuijten, 500 F.3d 1346 (Fed. Cir. 2007)) or to software or data per se, divorced from any physical or statutory embodiment (MPEP § 2106.03). Claim 15 expressly recites a "non-transitory computer-readable medium," which by its own claim language excludes transitory propagating signals and satisfies MPEP § 2106.03. Claims 1 and 8 are each tied to a "hardware processor," and claim 8's "software modules" are recited as components of a system with hardware, not as freestanding code. Accordingly, no claim currently on file is rejected as being directed to a signal per se or to software per se. This finding is noted for the record; it does not resolve the substantive abstract-idea rejection below, and Applicant is cautioned that any future amendment broadening claim 15's medium beyond "non-transitory," or reciting the software modules of claim 8 independent of the recited hardware, could reintroduce this issue.
STEP 2A, PRONG ONE — Does the claim recite a judicial exception?
Claim 1 recites, in relevant part:
"performing... design model validation, wherein design model validation comprises entering building permit application file information and checking the building permit application file information against relevant building codes, ordinances and regulations, with or without using a taxonomy or code logic by processing the building permit application file information against computable building requirement rules generated from translating a semantic structure of a building code, ordinance, or regulation using first-order logic, neural natural language processing, and fuzzy logic";
"performing... exchange model code checking, wherein exchange model code checking comprises using a plurality of exchange models";
"performing... code conformance checking, wherein the code conformance checking comprises receiving a request from the exchange models and passing the building permit application file information to code checking modules configured to check building code provisions and one or more regulations per local, state, national or international requirements, wherein the code checking modules process first object rules corresponding to objective code requirements and second object rules corresponding to uncertain code requirements against a software design model of the building permit application file information";
"performing... verification reporting based on input provided from the code checking modules";
"performing... results reporting based on findings of the verification reporting"; and
"generating and outputting... prediction confidence data for the code conformance checking or the verification reporting, wherein an inaccurate prediction of code conformance is fed back to a neural network to improve accuracy of building code conformance review."
Stripped of the generic computer components ("hardware processor," "modules," "neural network"), claim 1 as a whole recites: collecting information about a building design; checking that information against a body of rules (building codes, ordinances, and regulations); routing the information through a series of specialized checks; comparing the design against rules that are "objective" and rules that are "uncertain"; reporting the results and findings; and outputting a confidence level in that determination, then using wrong answers to get better at the same determination over time.
This is a mental process — evaluating information and reaching a judgment or opinion about whether a design complies with a body of rules — a task that, but for the generic recitation of a computer, could be performed in the human mind or with pen, paper, and a code book by a plans examiner or building inspector applying a code checklist. See MPEP § 2106.04(a)(2)(III); SmartGene, Inc. v. Advanced Biological Labs., SA, 555 F. App'x 950 (Fed. Cir. 2014) (claims comparing patient information against a set of rules to generate treatment options directed to an unpatentable mental process); Elec. Power Grp., LLC v. Alstom S.A., 830 F.3d 1350, 1354 (Fed. Cir. 2016) ("collecting information, analyzing it, and displaying certain results of the collection and analysis" is a familiar abstract-idea category regardless of a "particular content" limitation).
Claim 1 also recites certain methods of organizing human activity, specifically managing compliance with legal and regulatory obligations — checking a building design against building codes, ordinances, and regulations is fundamentally a legal/administrative compliance determination of the kind humans (permit reviewers, code officials) have always performed. See MPEP § 2106.04(a)(2)(II); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355 (Fed. Cir. 2014) (creating a contractual relationship to satisfy a guarantee is an abstract idea).
Finally, "generating and outputting prediction confidence data" recites a mathematical concept — calculating a confidence value/probability — divorced from any specific claimed algorithm. See MPEP § 2106.04(a)(2)(I).
Because claim 1 recites limitations that fall within the mental-process, certain-methods-of-organizing-human-activity, and mathematical-concept groupings, the claim recites an abstract idea under Prong One.
Claims 8 and 15 recite the identical design-model-validation / exchange-model-code-checking / code-conformance-checking / verification-reporting / results-reporting / prediction-confidence-data framework, merely reciting it as functions performed "when executed by the at least one hardware processor" (claim 8) or "when executed by a processor" (claim 15) rather than as method steps. Reciting an abstract idea as a system or as instructions on a medium does not change the Prong One analysis; claims 8 and 15 recite the same abstract idea as claim 1 for the same reasons.
STEP 2A, PRONG TWO — Integration into a Practical Application
Having identified the abstract idea, Examiner considered whether the claim as a whole integrates that idea into a practical application. The only additional elements beyond the abstract idea itself are: "at least one hardware processor" (claim 1) / "at least one hardware processor" and "one or more software modules" (claim 8) / "a non-transitory computer-readable medium," "instructions," and "a processor" (claim 15); the recitation that translation of code text into rules uses "first-order logic, neural natural language processing, and fuzzy logic"; the recitation of "a plurality of exchange models" and "code checking modules"; and "a neural network" that receives feedback.
None of these additional elements, alone or in combination, integrates the abstract idea into a practical application:
Generic computer components performing generic computer functions. The "hardware processor," "software modules," and "non-transitory computer-readable medium" are recited at the highest level of generality — as generic tools that receive data, process it, and output a result. Simply implementing an abstract idea on a generic computer is not integration into a practical application. MPEP § 2106.05(f); Alice, 573 U.S. at 223-24.
"First-order logic, neural natural language processing, and fuzzy logic" are recited as unclaimed black-box labels, not as a specific technical improvement. The claim does not recite what the first-order logic expressions look like, what the fuzzy-logic membership functions are, or how the neural NLP model is structured or trained to perform the translation — it simply names three known AI/logic techniques and says they are used to translate code text into "computable building requirement rules." Merely invoking these technique names, without claiming the specific technical implementation, is the "apply it" version of the underlying mental process, not a claimed improvement to the technology itself. SAP Am., Inc. v. InvestPic, LLC, 898 F.3d 1161, 1163, 1170 (Fed. Cir. 2018) (claiming a result — improved statistical analysis — without the specific means of accomplishing it is not a technical improvement); Univ. of Fla. Research Found., Inc. v. Gen. Elec. Co., 916 F.3d 1363, 1367 (Fed. Cir. 2019) (claims "translating" and reformatting data using a "driver library" without reciting how the drivers work were not a technical improvement, but an improvement to the abstract idea of data collection and organization). Notably, converting text-based rules (here, building codes) into a device- or machine-usable format ("computable building requirement rules") is analogous to the ineligible translation/conversion claims in University of Florida Research Foundation — a case with particular relevance here given the similarity of the "translating a semantic structure" limitation to the data-translation limitation held ineligible there.
"Exchange models" and "code checking modules" are recited functionally, not structurally. The claim states only that exchange models are used, that a request is received "from the exchange models," and that "code checking modules" are "configured to check building code provisions." No specific architecture, data structure, or technical mechanism is claimed for how these components operate; they are results-oriented placeholders for "the part of the abstract idea that routes and compares data." Reciting a result without the specific means of achieving it does not integrate an abstract idea into a practical application. MPEP § 2106.05(f); Elec. Power Grp., 830 F.3d at 1356.
"A neural network" that receives "an inaccurate prediction... fed back... to improve accuracy" is a generic, result-based recitation of a known machine-learning feedback loop, not a claimed technical improvement to how neural networks are trained. The claim does not recite a loss function, a training architecture, a specific weight-update mechanism, or any other technical detail — it recites only the outcome ("improve accuracy") of applying generic, known supervised or unsupervised learning (see claims 21, 25, 29). Simply invoking "AI" or "a neural network" to automate a task a human otherwise performs, without more, does not confer eligibility. See MPEP § 2106.05(f); cf. SAP Am., 898 F.3d at 1170.
The claim does not solve a technology-based problem with a technology-based solution the way the claims in McRO, Inc. v. Bandai Namco Games Am. Inc., 837 F.3d 1299 (Fed. Cir. 2016), and DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245 (Fed. Cir. 2014), did. In McRO, the claims recited a specific set of rules (defined with particularity, including the structure and timing relationships of morph weights and phonemes) that changed how a computer, specifically, generated lip-synchronized 3-D animation — an inherently technological process with no real-world, non-computer analog performed the same way. Here, by contrast, the claimed process automates a task — determining whether a building design complies with legal and regulatory building-code requirements — that a human plans examiner has always performed by reading code provisions and comparing them against drawings. The problem solved (slow, inconsistent, and costly manual code review, see Applicant's Specification PGPub. 2025/0225599 [0050-0052]) is a business/administrative problem, and the purported solution is simply doing the same comparison faster and with different software tools, not changing the fundamental way a computer operates. See buySAFE, 765 F.3d at 1355; In re TLI Commc'ns LLC Patent Litig., 823 F.3d 607, 612-13 (Fed. Cir. 2016).
Insignificant extra-solution activity. "Entering building permit application file information," "receiving a request," "passing" the information to modules, and "generating and outputting" data are all pre- and post-solution data-gathering and data-output activity that does not integrate the judicial exception into a practical application. MPEP § 2106.05(g).
For these reasons, claim 1 (and claims 8 and 15 for the same reasons) does not integrate the recited abstract idea into a practical application, and the claim is directed to the abstract idea under Step 2A.
STEP 2B — Inventive Concept ("Significantly More")
Because the claims are directed to an abstract idea, Examiner considered, individually and as an ordered combination, whether the additional elements amount to significantly more than the abstract idea itself. They do not.
The "at least one hardware processor," generic "software modules," and "non-transitory computer-readable medium" are well-understood, routine, and conventional computer components performing their basic, expected functions of storing and executing instructions and processing data. MPEP § 2106.05(d); Alice, 573 U.S. at 225-26; In re TLI Commc'ns, 823 F.3d at 614.
Applying "first-order logic," "neural natural language processing," and "fuzzy logic" — all pre-existing, named technique categories — to a new subject-matter field (building codes instead of some other text) is simply applying known tools to a new data domain, which does not supply an inventive concept. SAP Am., 898 F.3d at 1163, 1170.
Using "a plurality of exchange models" and "code checking modules" to route and compare data is the ordinary, expected way multiple software components communicate (request/response), and the claims do not recite any unconventional arrangement of these generic components of the kind found eligible in BASCOM Global Internet Servs., Inc. v. AT&T Mobility LLC, 827 F.3d 1341, 1350-52 (Fed. Cir. 2016) (unconventional, specifically claimed arrangement of generic components at a specific network location) or DDR Holdings, 773 F.3d at 1257-59 (specifically claimed technical solution overriding conventional webpage behavior). Unlike those cases, claim 1 does not recite any specific, unconventional technical arrangement — the components are used in their ordinary, expected manner to carry out the abstract comparison.
Training "a neural network" using "supervised" or "unsupervised" learning (claims 21, 25, 29) is expressly claimed at the level of generic, textbook machine-learning categories; both techniques were well-understood, routine, and conventional to a person of ordinary skill in the art well before the claimed priority date. See MPEP § 2106.05(d); Berkheimer v. HP Inc., 881 F.3d 1360, 1369 (Fed. Cir. 2018) (whether an element is well-understood, routine, and conventional is a factual question, which Examiner finds resolved here by the intrinsic evidence, since the Specification itself describes supervised and unsupervised training only in generic, result-oriented terms, without describing either technique as improved or unconventional — see MPEP § 2106.07(a)).
Considered as an ordered combination, the claims simply link the abstract idea of code-conformance checking to generic computer components and generic, off-the-shelf AI/logic techniques used for their intended purpose, in an order that is itself conventional (collect data → apply rules → route to specialized checks → report results → output a confidence score → retrain on error). This ordered combination adds nothing beyond what each limitation contributes on its own, and there is no inventive concept sufficient to transform the abstract idea into a patent-eligible application of that idea.
Claims 1, 8, and 15 are therefore rejected under 35 U.S.C. § 101.
Dependent Claims
Claims 7, 14, and 16 (GUI with buttons): These claims add "graphically displaying... a graphical user interface embedded with one or more buttons for initiating an action of code conformance checking." Displaying a generic graphical user interface with generic, unclaimed "buttons" to trigger a function is a well-understood, routine, and conventional generic computer/display function and/or insignificant extra-solution (data-gathering/triggering) activity that does not add significantly more or integrate the abstract idea into a practical application. MPEP §§ 2106.05(f), 2106.05(g); Trading Techs. Int'l, Inc. v. IBG LLC, 921 F.3d 1084, 1093-94 (Fed. Cir. 2019) (generic display/GUI limitations, without a specific claimed improvement to how the GUI itself functions, do not confer eligibility). Claims 7, 14, and 16 are rejected under 35 U.S.C. § 101 for the same reasons as their respective base claims, as further evidenced by the foregoing.
Claims 21, 25, and 29 (supervised/unsupervised learning): As discussed above at Step 2B, reciting that the neural network "is trained using a supervised learning method or an unsupervised learning method" merely names generic, conventional categories of machine-learning training without any technical detail of an improved or unconventional training process. This does not add significantly more. Claims 21, 25, and 29 are rejected under 35 U.S.C. § 101.
Claims 22-24, 26-28, and 30-31 (rule subject matter — land use; mechanical, electrical, and plumbing; structural; architectural design; fire protection): These claims merely recite the particular category or subject-matter field of the "first object rules" and "second object rules" (e.g., land-use requirements, MEP requirements, structural requirements, architectural design requirements, fire-protection requirements). Narrowing an abstract idea to a particular field of use or subject-matter category, without adding any technical means for implementing that narrowed idea, does not integrate the idea into a practical application or add an inventive concept — it simply narrows which building codes are being mentally/administratively compared. MPEP § 2106.05(h); In re Marco Guldenaar Holding B.V., 911 F.3d 1157, 1162-63 (Fed. Cir. 2018) (limiting an abstract idea to a particular field or requiring a generic device for its performance does not make the idea patent eligible); buySAFE, 765 F.3d at 1355. Claims 22-24, 26-28, and 30-31 are rejected under 35 U.S.C. § 101.
Conclusion: Claims 1, 7, 8, 14-16, and 21-31, i.e., all pending claims, are rejected under 35 U.S.C. § 101 as being directed to a judicial exception (an abstract idea) without significantly more.
CLAIM REJECTIONS UNDER 35 U.S.C. § 112(b) (Indefiniteness / Antecedent Basis)
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.
Claims 1, 7, 8, 14-16, and 21-31 are rejected under 35 U.S.C. § 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter the inventor regards as the invention. MPEP § 2173.05(e).
1. "the building design" — claims 22, 23, 24 (depend from claim 1), 26, 27, 28 (depend from claim 8), and 30, 31 (depend from claim 15) — lacks antecedent basis. Each of these dependent claims recites that the first object rules and second object rules "define [land use / mechanical, electrical, and plumbing / structural / architectural design / fire protection] requirements for the building design." However, none of independent claims 1, 8, or 15 introduces "a building design" — those claims recite only "building permit application file information" and, later, "a software design model of the building permit application file information." It is unclear whether "the building design" in claims 22-24, 26-28, 30-31 is meant to refer back to the "software design model," to the "building permit application file information," or to some other, unclaimed design. Claims 22-24, 26-28, and 30-31 are indefinite for lack of antecedent basis.
2. "code checking modules" (claims 1, 8, 15) is introduced without an antecedent article ("a," "one or more," etc.) and its relationship to "the exchange models" and to the previously recited processing steps is unclear. The claims first recite "passing the building permit application file information to code checking modules configured to check..." with no antecedent basis established for "code checking modules" at that point in the claim, and it is unclear from the claim language whether "code checking modules" is the same set of components as, a subset of, or a different set of components from "the exchange models" and/or the "software design model" against which they operate. Clarification is required.
3. The relationship between "the building permit application file information" and "a software design model of the building permit application file information" is unclear. Claim 1 (and claims 8 and 15) first recite "entering building permit application file information," and later recite that the code checking modules process rules "against a software design model of the building permit application file information" — introducing a new element, "a software design model," without explaining whether this design model is generated from, is a component of, or is separate from the previously recited "building permit application file information." The metes and bounds of "software design model" relative to the "building permit application file information" are indefinite.
4. Unclear relationship between the optional/disjunctive "taxonomy" language and the "computable building requirement rules" clause (claims 1, 8, and 15). Claim 1 recites checking file information "with or without using a taxonomy or code logic," an expressly optional, disjunctive limitation, immediately followed by "by processing the building permit application file information against computable building requirement rules generated from translating... using first-order logic, neural natural language processing, and fuzzy logic," which appears to unconditionally require rules generated by all three named techniques. Claim 8 similarly recites checking "using a taxonomy, neural Natural Language Processing (NLP), or artificial intelligence" (one of three alternatives) immediately followed by the same unconditional "computable building requirement rules... using first-order logic, neural natural language processing, and fuzzy logic" clause. It is unclear (a) whether "a taxonomy or code logic"/"a taxonomy, neural NLP, or artificial intelligence" is an alternative to, or an additional, optional feature layered on top of, the "computable building requirement rules" processing; and (b) whether the "computable building requirement rules" clause is a mandatory limitation in every claim scenario or is itself conditioned on the "with or without"/disjunctive language that precedes it. Clarification is required for claims 1 and 8. (Claim 15 recites only "using a taxonomy," without disjunctive alternatives, but Applicant should confirm the intended relationship between that clause and the immediately following "computable building requirement rules" clause for consistency.)
Applicant is requested to amend the claims to resolve each antecedent-basis and clarity issue identified above, or to explain on the record why the identified claim language is definite as currently written.
CLAIM REJECTIONS UNDER 35 U.S.C. § 112(a) (Written Description)
The following is a quotation 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.
Claims 1, 8, 15, and their dependents are rejected under 35 U.S.C. § 112(a) because the Specification does not reasonably convey that the inventor had possession of the claimed invention as now claimed, as of the filing date. MPEP § 2163; Ariad Pharm., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc) (written description requires the specification to "clearly allow persons of ordinary skill in the art to recognize that [the inventor] invented what is claimed").
1. "first object rules corresponding to objective code requirements" and "second object rules corresponding to uncertain code requirements" (claims 1, 8, 15). As currently understood from the Specification, the disclosure describes translating regulatory text into "object rules or parametric models," and separately describes classifying regulatory provisions into categories such as conditional/provisory, content, ambiguous, and dependent provisions, and separately discusses handling of "objective" (bright-line, computable) versus ambiguous/subjective provisions using fuzzy logic. It is not clear that the Specification links this general framework, using the specific claimed vocabulary of a "first object rule" tied one-to-one to "objective code requirements" and a "second object rule" tied one-to-one to "uncertain code requirements," in the manner now recited. Applicant should identify with particularity (by paragraph and, if applicable, figure number) where the Specification as filed describes this precise two-category "first object rule / second object rule" framework tied to "objective" and "uncertain" code requirements, respectively, so that Examiner can confirm possession of this specific claim language.
2. The closed-loop "inaccurate prediction... fed back to a neural network to improve accuracy" limitation (claims 1, 8, 15). The Specification broadly discloses that a neural network may undergo "supervised training" or "unsupervised training" to improve accuracy of building code conformance review. Applicant should identify with particularity where the Specification as filed describes the specific mechanism recited in the claims — namely, that it is an "inaccurate prediction of code conformance," specifically, that "is fed back to" the neural network as the (or a) mechanism for improving accuracy — as opposed to the general, unspecified training process disclosed. Absent clear support, this limitation may constitute new matter or may lack written description support commensurate in scope with the claim.
3. "a software design model of the building permit application file information" (claims 1, 8, 15). Applicant should identify with particularity where the Specification as filed supports a "software design model" as an entity distinct from, or generated from, the "building permit application file information," against which the code checking modules' rules are processed, as this terminology does not appear to track the Specification's stated architecture (BIM/CAD/IFC/PDF building permit application files, exchange models, and code-checking modules) using the same vocabulary.
Applicant is invited to point to the specific supporting disclosure (by paragraph number) for each of the above limitations. If sufficient disclosure exists, Applicant should identify it for the record; if it does not, the claims should be amended to be commensurate in scope with the disclosure that was actually possessed as of the filing date.
CLAIM REJECTIONS / CLAIM INTERPRETATION UNDER 35 U.S.C. § 112(f) (Means- (or Step-) Plus-Function)
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 claim limitations invoke 35 U.S.C. § 112(f) and have been interpreted accordingly. MPEP §§ 2181-2186; Williamson v. Citrix Online, LLC, 792 F.3d 1339, 1348-49 (Fed. Cir. 2015) (en banc) (a claim term that fails to recite sufficiently definite structure, and is instead a generic, functional placeholder like "module," "mechanism," or "element," coupled with functional language, may invoke § 112(f) even without the word "means").
1. "one or more software modules that are configured to... [perform functions]" (claim 8, and by dependency claims 14, 25-28) is a nonce term ("module") that, standing alone, connotes no specific structure to a person of ordinary skill in the art; it is simply a generic substitute for "means," coupled with purely functional recitations (perform design model validation, perform exchange model code checking, etc.). This claim language has accordingly been interpreted under 35 U.S.C. § 112(f).
2. "code checking modules configured to check building code provisions..." (claims 1, 8, 15) is likewise a generic, functionally-defined term.
For a computer-implemented means- (or "module-") plus-function limitation, the corresponding structure must be an algorithm — not merely a general-purpose processor. Aristocrat Techs. Australia Pty Ltd. v. Int'l Game Tech., 521 F.3d 1328, 1333 (Fed. Cir. 2008). Applicant is invited to identify, by paragraph number, the specific algorithm(s) disclosed in the Specification that corresponds to each function recited for the "software modules" and "code checking modules." To the extent no corresponding algorithm is disclosed for a given claimed function, the claim reciting that function is indefinite under 35 U.S.C. § 112(b) for failure to disclose adequate corresponding structure and may also lack written description support under 35 U.S.C. § 112(a).
Because claim 1 is a method claim reciting "performing... using at least one hardware processor" (rather than a "step for" format), and claim 15 recites "instructions... cause the processor to" (rather than a generic "module"), Examiner has not applied 112(f) to claims 1 and 15 directly, but notes that if amended to include "module"-style nonce terms, the same analysis set forth above would apply.
----- Examiner’s Response to Arguments -----
Per Applicants’ amendments/arguments, the rejections are withdrawn.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Examiner’s Response: Claim Rejections – 35 USC §112
Per Applicants’ amendments/arguments, the rejections are withdrawn.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Examiner’s Response: Claim Rejections – 35 USC § 103
Per Applicants’ amendments/arguments, the rejections are withdrawn. See notes above for additional reasoning and rationale for dropping prior-art rejection including Applicant’s amendments and arguments and unique combination of features and elements not taught by the prior-art without hindsight reasoning.
Applicant’s arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Regarding Claim X, on page(s) 8-9 of Applicant’s Remarks / After Final Amendments (dated 07/15/2011), Applicant(s) argues that the cited reference(s) (Ellis and Vandermolen) fails to teach, describe, or suggest the amended features. Specifically, Applicant(s) argues that cited reference(s) do not teach, describe, or suggest the following: . With respect, Applicant’s arguments are deemed unpersuasive and the amended feature(s) remain rejected as follows.
With respect, Applicant’s arguments are deemed unpersuasive and the amended feature(s) remain rejected as follows.
Examiner’s Response: Claim Rejections – 35 USC §101
Per Applicants’ amendments/arguments, the rejections are withdrawn. See notes above for additional reasoning and rationale for dropping 35 USC 101 rejection including Applicant’s amendments, arguments, lack of abstract idea, and practical integration.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Regarding Claims 1-15, on page(s) 6-12 of Applicant’s Remarks (dated 12/27/2016), Applicants traverse the 35 USC §101 rejections arguing the following:
RESPONSE TO APPLICANT'S ARGUMENTS REGARDING 35 U.S.C. § 101
Applicant's remarks (08/18/2026), filed in response to the Notice of Non-Compliant Amendment, have been fully considered but are not persuasive for withdrawal of the 35 U.S.C. § 101 rejection, for the reasons below.
1. Applicant's argument that the amended claims recite "a technological improvement" because they solve the problem described in Specification ¶ 0051 (that prior approaches were costly to sustain, hard to modify, and could not handle subjective/ambiguous code language) is not persuasive.
In plain terms: making a legal/regulatory review process cheaper, easier to update, and better able to handle vague rules is an improvement to the review process itself — that is, an improvement to the abstract idea of code-compliance checking. It is not, without more, an improvement to how a computer works. The case law draws exactly this line. In SAP America v. InvestPic and in University of Florida Research Foundation v. General Electric, the Federal Circuit held that claims reciting an improved outcome (better statistical analysis; converting and organizing medical data into a more usable format) were still abstract, because the claims recited only the desired result and generic technique labels, not the specific technical means of achieving that result. The same is true here: claim 1 does not recite the actual first-order-logic rule structures, the actual fuzzy-logic membership functions, or the actual neural-NLP model architecture used to perform the translation — it recites only that these named, pre-existing techniques are used, and that the result is a "computable" rule. That is a claim to a desired outcome, not to a specific technological means, and it does not satisfy Step 2A Prong Two or Step 2B.
2. Applicant's reliance on McRO, Inc. v. Bandai Namco Games America Inc. is factually distinguishable and does not require withdrawal of the rejection.
McRO is one of the few cases finding automation of a previously-manual task eligible, but it turned on a critical fact that is absent here: the McRO claims recited the actual, specific structure of the rules used — particular relationships between phoneme sequences, timing, and morph-target weight sets — such that the claim itself described a specific new process a computer could follow that differed technologically from how animators previously (manually) produced lip-synced animation. The Federal Circuit was explicit that it was "the incorporation of the claimed rules, not use of the computer, that improved [the] existing technological process." McRO, 837 F.3d at 1314 (emphasis added).
Here, by contrast, the claims do not recite the content or structure of any specific rule. They recite that rules are "generated from translating a semantic structure of a building code... using first-order logic, neural natural language processing, and fuzzy logic" — i.e., they name the categories of technique used to produce rules, without claiming what any resulting rule looks like or how it operates differently from a rule a human reviewer would apply. This is the opposite of McRO, where the specific rule structure was the point of novelty claimed. Because the pending claims do not claim specific rule structure the way the McRO claims did, McRO does not control, and the claims remain properly rejected. See also In re TLI Communications, 823 F.3d at 612-13 (distinguishing McRO on the same basis).
Additionally, the underlying task automated in McRO (frame-by-frame 3-D character animation) has no non-computer analog performed the same way — it is an inherently technological process. Here, the underlying task (checking a building design against code requirements) is a task humans have always performed by reading a code book and a set of plans; using a computer, NLP, and fuzzy logic to do the same comparison faster is automating a human mental/administrative task, not solving a problem that is unique to computers, which is a hallmark of the McRO analysis this application's claims do not share.
3. Applicant's reliance on PTAB decisions Ex parte Garrido and Ex parte Berger is not persuasive.
As a threshold matter, PTAB decisions that are not designated "Precedential" or "Informative" do not bind Examiner and are not controlling authority; Applicant has not identified either decision as carrying such designation. More importantly, even taking those decisions at face value, they are distinguishable on their facts: in each, the Board found the claims analogous to McRO because they recited specific, detailed technical rules or a specific claimed training process for evaluating subjective criteria — not merely a label for a category of technique. Here, as explained above, the claims recite the technique categories (first-order logic, neural NLP, fuzzy logic; supervised/unsupervised learning) without the corresponding claimed specificity that made the rules or training processes in those decisions analogous to McRO's specific rule set. The general, result-oriented "improve accuracy" and "translate... using [technique names]" language here is more like the claims rejected in SAP America and Electric Power Group than the specifically-claimed rules or training processes at issue in the cited PTAB decisions.
4. Conclusion and Recommendations to Advance Prosecution.
For the foregoing reasons, Applicant's arguments are not persuasive, and the rejection of claims 1, 7, 8, 14-16, and 21-31 under 35 U.S.C. § 101 is maintained. Applicant is invited to consider amending the claims to recite the specific technical structure of the first-order-logic rules, the fuzzy-logic membership functions, or the neural-network training/architecture actually disclosed in the Specification, in a manner analogous to the specific rule structure found eligible in McRO, which may better position the claims for reconsideration. Applicant is further invited to address, in any response, the newly identified issues under 35 U.S.C. § 112(a), (b), and (f) set forth in Parts B, C, and D above, as these were necessitated by the current claim amendments and are being raised for the first time in this Office Action.
Examiner’s Response: Double Patenting Rejection
RESPONSE TO APPLICANT'S REQUEST TO HOLD THE NON-STATUTORY DOUBLE PATENTING REJECTION IN ABEYANCE
In Section I of the Remarks, Applicant requests that the rejection of claims 1, 7, 8, and 14-16 for non-statutory (obviousness-type) double patenting over claims 1-17 of U.S. Patent No. 12,020,339 be "held in abeyance until it is the only rejection outstanding," citing MPEP § 714.02 and 37 C.F.R. § 1.111(b). This request is respectfully denied, and the double patenting rejection is maintained, for the reasons below.
In plain terms: the authority Applicant cites does not support deferring a double patenting rejection. MPEP § 714.02 explains what makes a reply to an Office Action "fully responsive" — namely, that the reply must address every ground of rejection — and does not itself authorize holding any rejection in abeyance. 37 C.F.R. § 1.111(b) does permit a request that certain matters be "held in abeyance until allowable subject matter is indicated," but only for "objections or requirements as to form not necessary to further consideration of the claims." A double patenting rejection, and the terminal disclaimer (or a showing of patentable distinction) needed to overcome it, is a substantive matter necessary to further consideration of the claims, not a mere formality, and so falls outside that narrow abeyance provision.
MPEP § 804 makes this distinction explicit: "As filing a terminal disclaimer or filing a showing that the claims subject to the rejection are patentably distinct from the reference application's claims, is necessary for further consideration of the rejection of the claims, such a filing should not be held in abeyance. Only compliance with objections or requirements as to form not necessary for further consideration of the claims may be held in abeyance until allowable subject matter is indicated." MPEP § 804 further provides that "an application must not be allowed unless the required compliant terminal disclaimer(s) is/are filed and/or the withdrawal of the nonstatutory double patenting rejection(s) is made of record by the examiner."
Accordingly, Applicant's request to hold the double patenting rejection in abeyance is denied as unsupported by the cited authority. The rejection of claims 1, 7, 8, and 14-16 under the doctrine of non-statutory (obviousness-type) double patenting over claims 1-17 of U.S. Patent No. 12,020,339, set forth at pages 3-7 of the prior Office Action, is maintained for the reasons stated therein, which Applicant has not otherwise challenged on the merits. Examiner further notes that independent claim 15 and new claims 21-31 have not yet been evaluated on this ground, and that the rejection may be extended to those claims in a subsequent action to the extent they are not patentably distinct from the reference patent's claims.
To expedite prosecution, Applicant may overcome this rejection at any time by filing a terminal disclaimer, in compliance with 37 C.F.R. § 1.321(c) or (d), disclaiming the terminal portion of any patent granted on this application that would extend beyond the expiration date of U.S. Patent No. 12,020,339, or by persuasively showing that the presently claimed invention is patentably distinct from the claims of that patent. As a practical matter, Applicant is not required to file that terminal disclaimer with this response and may elect to wait until the claims are otherwise in condition for allowance before doing so; however, consistent with MPEP § 804, the rejection will remain of record in every subsequent Office Action, and the application cannot be passed to issue unless a compliant terminal disclaimer is filed or the rejection is otherwise withdrawn of record.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
----- Conclusion -----
PERTINENT PRIOR ART – Patent Literature
The prior-art made of record and considered pertinent to applicant's disclosure.
Roth et al. 2008/0059220 (a system and method using a processor for processing digital data to perform an automated plan checking process (design model validation) stored on a computer-readable medium; paragraphs [0019; 0025; 0026]) (author 105 uploads a building plan (building permit application file information) in order to initiate an automated plan checking process (design model validation) [0055; 0077]) (the system uses a compliance utility 145 that includes a plancheck module 230 to check that the building plan uploaded by the author (building permit application file information) is in compliance with the building codes, rules and regulations (relevant building codes, ordinances and regulations) for an applicable jurisdiction using a building codes rules dictionary as defined by the International Code Council "ICC" (using a taxonomy) [0019-0022; 0043; 0061; 0066-0067]) (the processor uses compliance utility 145 to process requests and execute queries against compliance database 150 and exchange data with jurisdiction 165 [0025; 0038]) (compliance utility 200 comprises any number of functions and code modules such as plancheck module 230 (code checking modules) which reads the building plan information stored in the building plan component model 220 (passing the building permit application file information) and determines whether the building plan complies with the various applicable codes and rules for a particular governing jurisdiction (per local, state, national or international requirements) [0057-0067]) (compliance utility 145 of the processor includes the plan analysis module which identifies any non-standard or unrecognized usage (input provided from the code checking modules) and the user may receive detailed information regarding the non-standard or unrecognized usage (verification reporting) [0025; 0064-0065; 0077]) (reports module 235 of the processor generates and provides reports (reporting) relating to, for example, compliance and non-compliance of building plans when a building plan passes the analysis check for non-standard or unrecognized usage (based on findings of the verification reporting) [0025; 0040-0041; 0068-0069; 0078]).
PERTINENT PRIOR ART – Non-Patent Literature (NPL)
The NPL prior-art made of record and considered pertinent to applicant's disclosure.
Towards French Smart Building Code: Compliance Checking Based on Semantic Rules, Nicolas Bus, et al. 01 October 2019.
Exchange Model and Exchange Object Concepts for Implementation of National BIM Standards, C.M. Eastman, et al., Journal of Computing in Civil Engineering / January/February 2010.
THIS ACTION IS MADE FINAL
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 extension fee 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 date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW T. SITTNER whose telephone number is (571) 270-7137 and email: matthew.sittner@uspto.gov. The examiner can normally be reached on Monday-Friday, 8:00am - 5:00pm (Mountain Time Zone). Please schedule interview requests via email: matthew.sittner@uspto.gov
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sarah M. Monfeldt can be reached on (571) 270-1833.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MATTHEW T SITTNER/
Primary Examiner, Art Unit 3629b
Claims 1-6, 8-13, 15, 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over: Nawari, Nawari O.: "A Generalized Adaptive Framework (GAF) for Automating Code Compliance Checking", Buildings, vol. 9, no. 4, 16 April 2019 (2019-04-16) (hereinafter Nawari); in view of Conover 2009/0125283.
19/094,455 – Claim 1. Nawari teaches A method comprising: performing, using at least one hardware processor (“computer environment… computer systems”, page 2), design model validation (Nawari – "automatic code compliance checking", title; page 4, Table 1, “carry out automated compliance validation”, page 8), wherein design model validation comprises entering building permit application file information and checking the building permit application file information against relevant building codes (Abstract: Building design review is the procedure of checking a design against codes and standard provisions to satisfy the accuracy of the design and identify non-compliances before construction begins.; “approvals of construction permits by building authorities”, page 4), ordinances and regulations, with or without using a taxonomy or code logic (Nawari – “Taxonomy formation, knowledge conceptualization, modification, integration, and decomposition of the design regulations and rules.”, page 5; "extract, access and link BIM and regulations data via ifc XML", page 12; "Building design regulations will be classified using the taxonomy defined earlier and can also be translated into conceptual representations that closely approximate the meaning of the building code provision", page 8, second paragraph; see page 8, last paragraph - page 11 for a translation of the Florida Building Code 2017 - Residential (FBC-R 2017) into a computable representation); performing, using the at least one hardware processor, exchange model code checking (Abstract: “automating the code compliance checking processes to achieve design efficiency…”), wherein exchange model code (“generating algorithms for the data exchanges between the components of the framework to execute the virtual review process of a building design in order to achieve design accuracy” (interpreted as exchange models), page 5) checking comprises using a plurality of exchange models (Nawari – " ... decomposition of the design regulations and rules. This includes data analysis, partitioning and classification of regulatory text into broad categories", page 5, last paragraph); performing, using the at least one hardware processor (“Recently, new developments in Artificial Intelligence (AI) research and Building Information Modeling (BIM) could offer practical concepts to resolve some of the current major problems with automating CCC. … computer systems…”, page 2), code conformance checking, wherein the code conformance checking (“a software prototype developed to demonstrate the checking of designed components as described in application program databases for conformance with design standards”, page 3) comprises receiving a request from the exchange models and passing the building permit application file information to code checking modules (Abstract: “The objectives of this study comprise … transforming the written code regulations and rules into a computable model … define the various modules required for computerizing of the code compliance verification process.”) configured to check building code provisions and one or more regulations per local, state, national or international requirements (Nawari – “degree of customization to modify the parameters of each rule to match specific local regulations”, page 3; “To provide evidence for the Proof of Concept (POC), a two-story building is considered in a typical design review process examining regulations and provisions from FBC-R 2017”, page 13); performing, using at least one hardware processor, verification reporting (“produce various output reports such as … views showing objects that are in noncompliance along with the detailed information about the regulation”, page 6) based on input provided from the code checking modules (Nawari – "examining the compliance of the areas of the spaces [of the two-storey building]. .. according to the FBC-2017', page 14, second-to-last paragraph); and performing, using at least one hardware processor, results reporting based on findings of the verification reporting (Nawari – "Figure 12: Results example of checking compliance with the space areas regulations of FBC-2017-R', Figure 12, page 15; “define the various modules required for computerizing of the code compliance verification process”, page 1).
Nawari may not expressly disclose the “code conformance checking” features, however, Conover 2009/0125283 teaches (Conover 2009/0125283 [0002 - systems, programs and methods for compliance checking with respect to building regulations (codes) … automate, with respect to building regulations, creation, storage and access to rule sets from the regulations to facilitate automated compliance checking of building plans and specifications against those regulations] The invention relates to systems, programs and methods for compliance checking with respect to building regulations (codes). More specifically, these are systems, programs and methods to automate, with respect to building regulations, creation, storage and access to rule sets from the regulations to facilitate automated compliance checking of building plans and specifications against those regulations and to do so in a secure, technically accurate and reliable manner, and to collect and utilize building and system data submitted for compliance checking for a variety of purposes. [0007 - protocol and software can also be used to create "smart" versions of Federal, state, and locally adopted versions of those codes, as well as reference standards and any other rules or regulations] A protocol and software program are provided to create tagged representations of the ICC model building construction codes, sometimes referred to herein as SMARTcodes.TM.(a trademark of the International Code Council), that have a tagging schema that reflects the logic and requirements of the ICC's codes, from "clean" xml files of the codes. The protocol and software can also be used to create "smart" versions of Federal, state, and locally adopted versions of those codes, as well as reference standards and any other rules or regulations. The SMARTcodes.TM. and embedded schema and tags are usable, when presented as a limiting rule set, by model checking software (MCS) as a limiting, or model, set of constraints when the MCS reads a building information model (BIM) that contains information about a building to check the building against the SMARTcodes.TM. and automatically assess code compliance for the building. In addition, the SMARTcodes.TM. may be accessed manually (by SMARTcodes QUERY.TM., a trademark of the International Code Council) by users through web-based interfaces to provide, in addition to information related to code compliance, output that is useful for a variety of purposes, such as answers to specific questions about the codes and code compliance, code criteria applicable to a topic, compliance checklists, product listing directories, code interpretations, etc. In addition "horizontal searches" identifying model code and Federal, state and local differences for each topic represented in codes can be conducted to facilitate assessing the impact of variation in codes on a particular material or product. The latter supports national companies that sell products that are used in multiple places with different codes and regulations. [0068 - a comprehensive database concerning all design, construction and operational aspects of a building or structure from a building regulatory standpoint from a federal, state and local vantage point] During operation, the builder 140 and protocol 150 are used to keep a database of SMARTcodes.TM., standards, etc. criteria 205 up to date with current versions of relevant model codes, Federal, state and local amendment to those codes, standards, regulations etc. Thus, the database of SMARTcodes.TM., etc. 205 is a comprehensive database concerning all design, construction and operational aspects of a building or structure from a building regulatory standpoint from a federal, state and local vantage point. While it is desirable for the database of SMARTcodes.TM., tagged language, etc. 205 to be as comprehensive as possible with respect to different codes, standards, and regulations and the scope of what may be checked within each code, it is also possible to have multiple trusted entities where each maintains a database that is more focused or targeted on other criteria (e.g. green, sustainable, provisions beyond minimums code etc.). It is also possible to have separate databases within a single trusted entity that target different codes, standards, regulations, design guides, rules, manuals, etc (e.g. criteria applicable to buildings).). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Nawari to include the features as taught by Conover 2009/0125283. One of ordinary skill in the art would have been motivated to do so to utilize well known features useful for automating building code conformance which should prove to improve user experience, maximize profits, and optimize revenue.
19/094,455 – Claim 8. Nawari further teaches A system comprising: at least one hardware processor (“computer environment… computer systems”, page 2); and one or more software modules that are configured to (“As a software application integrated with a specific design tool”, page 3), when executed by the at least one hardware processor (“computer environment… computer systems”, page 2): perform design model validation (Nawari – "automatic code compliance checking", title; page 4, Table 1, “carry out automated compliance validation”, page 8), wherein design model validation comprises entering building permit application file information and checking the building permit application file information (Abstract: Building design review is the procedure of checking a design against codes and standard provisions to satisfy the accuracy of the design and identify non-compliances before construction begins.; “approvals of construction permits by building authorities”, page 4) against relevant codes and regulations, using a taxonomy (Nawari – “Taxonomy formation, knowledge conceptualization, modification, integration, and decomposition of the design regulations and rules.”, page 5; "extract, access and link BIM and regulations data via ifc XML", page 12; "Building design regulations will be classified using the taxonomy defined earlier and can also be translated into conceptual representations that closely approximate the meaning of the building code provision", page 8, second paragraph; see page 8, last paragraph - page 11 for a translation of the Florida Building Code 2017 - Residential (FBC-R 2017) into a computable representation) or neural Natural Language Processing (NLP) (“Natural Language Processing (NLP)”, Table1., page 4) or artificial intelligence (“new developments in Artificial Intelligence (AI) research and Building Information Modeling (BIM) could offer practical concepts to resolve some of the current major problems with automating CCC.”, page 2); perform exchange model code checking (Abstract: “automating the code compliance checking processes to achieve design efficiency…”), wherein exchange model (“generating algorithms for the data exchanges between the components of the framework to execute the virtual review process of a building design in order to achieve design accuracy” (interpreted as exchange models), page 5) code checking comprises using a plurality of exchange models (Nawari – " ... decomposition of the design regulations and rules. This includes data analysis, partitioning and classification of regulatory text into broad categories", page 5, last paragraph); perform code conformance checking, wherein the code conformance checking (“a software prototype developed to demonstrate the checking of designed components as described in application program databases for conformance with design standards”, page 3) comprises receiving a request from the exchange models (“generating algorithms for the data exchanges between the components of the framework to execute the virtual review process of a building design in order to achieve design accuracy” (interpreted as exchange models), page 5) and passing the building permit application file information to code checking modules (Abstract: “The objectives of this study comprise … transforming the written code regulations and rules into a computable model … define the various modules required for computerizing of the code compliance verification process.”) configured to check building code provisions and one or more regulations per local, state, national or international requirements (Nawari – “degree of customization to modify the parameters of each rule to match specific local regulations”, page 3; “To provide evidence for the Proof of Concept (POC), a two-story building is considered in a typical design review process examining regulations and provisions from FBC-R 2017”, page 13); perform verification reporting (“produce various output reports such as … views showing objects that are in noncompliance along with the detailed information about the regulation”, page 6) based on input provided from the code checking modules (Nawari – "examining the compliance of the areas of the spaces [of the two-storey building]. .. according to the FBC-2017', page 14, second-to-last paragraph); and perform results reporting results reporting based on findings of the verification reporting (Nawari – "Figure 12: Results example of checking compliance with the space areas regulations of FBC-2017-R', Figure 12, page 15; “define the various modules required for computerizing of the code compliance verification process”, page 1).
Nawari may not expressly disclose the “code conformance checking” features, however, Conover 2009/0125283 teaches (Conover 2009/0125283 [0002 - systems, programs and methods for compliance checking with respect to building regulations (codes) … automate, with respect to building regulations, creation, storage and access to rule sets from the regulations to facilitate automated compliance checking of building plans and specifications against those regulations] The invention relates to systems, programs and methods for compliance checking with respect to building regulations (codes). More specifically, these are systems, programs and methods to automate, with respect to building regulations, creation, storage and access to rule sets from the regulations to facilitate automated compliance checking of building plans and specifications against those regulations and to do so in a secure, technically accurate and reliable manner, and to collect and utilize building and system data submitted for compliance checking for a variety of purposes. [0007 - protocol and software can also be used to create "smart" versions of Federal, state, and locally adopted versions of those codes, as well as reference standards and any other rules or regulations] A protocol and software program are provided to create tagged representations of the ICC model building construction codes, sometimes referred to herein as SMARTcodes.TM.(a trademark of the International Code Council), that have a tagging schema that reflects the logic and requirements of the ICC's codes, from "clean" xml files of the codes. The protocol and software can also be used to create "smart" versions of Federal, state, and locally adopted versions of those codes, as well as reference standards and any other rules or regulations. The SMARTcodes.TM. and embedded schema and tags are usable, when presented as a limiting rule set, by model checking software (MCS) as a limiting, or model, set of constraints when the MCS reads a building information model (BIM) that contains information about a building to check the building against the SMARTcodes.TM. and automatically assess code compliance for the building. In addition, the SMARTcodes.TM. may be accessed manually (by SMARTcodes QUERY.TM., a trademark of the International Code Council) by users through web-based interfaces to provide, in addition to information related to code compliance, output that is useful for a variety of purposes, such as answers to specific questions about the codes and code compliance, code criteria applicable to a topic, compliance checklists, product listing directories, code interpretations, etc. In addition "horizontal searches" identifying model code and Federal, state and local differences for each topic represented in codes can be conducted to facilitate assessing the impact of variation in codes on a particular material or product. The latter supports national companies that sell products that are used in multiple places with different codes and regulations. [0068 - a comprehensive database concerning all design, construction and operational aspects of a building or structure from a building regulatory standpoint from a federal, state and local vantage point] During operation, the builder 140 and protocol 150 are used to keep a database of SMARTcodes.TM., standards, etc. criteria 205 up to date with current versions of relevant model codes, Federal, state and local amendment to those codes, standards, regulations etc. Thus, the database of SMARTcodes.TM., etc. 205 is a comprehensive database concerning all design, construction and operational aspects of a building or structure from a building regulatory standpoint from a federal, state and local vantage point. While it is desirable for the database of SMARTcodes.TM., tagged language, etc. 205 to be as comprehensive as possible with respect to different codes, standards, and regulations and the scope of what may be checked within each code, it is also possible to have multiple trusted entities where each maintains a database that is more focused or targeted on other criteria (e.g. green, sustainable, provisions beyond minimums code etc.). It is also possible to have separate databases within a single trusted entity that target different codes, standards, regulations, design guides, rules, manuals, etc (e.g. criteria applicable to buildings).). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Nawari to include the features as taught by Conover 2009/0125283. One of ordinary skill in the art would have been motivated to do so to utilize well known features useful for automating building code conformance which should prove to improve user experience, maximize profits, and optimize revenue.
19/094,455 – Claim 15. A non-transitory computer-readable medium having instructions stored therein, wherein the instructions, when executed by a processor (“computer environment… computer systems”, page 2), cause the processor to: perform design model validation (Nawari – "automatic code compliance checking", title; page 4, Table 1, “carry out automated compliance validation”, page 8), wherein design model validation comprises entering building permit application file information and checking the building permit application file information (Abstract: Building design review is the procedure of checking a design against codes and standard provisions to satisfy the accuracy of the design and identify non-compliances before construction begins.; “approvals of construction permits by building authorities”, page 4) against relevant codes and regulations, using a taxonomy (Nawari – “Taxonomy formation, knowledge conceptualization, modification, integration, and decomposition of the design regulations and rules.”, page 5; "extract, access and link BIM and regulations data via ifc XML", page 12; "Building design regulations will be classified using the taxonomy defined earlier and can also be translated into conceptual representations that closely approximate the meaning of the building code provision", page 8, second paragraph; see page 8, last paragraph - page 11 for a translation of the Florida Building Code 2017 - Residential (FBC-R 2017) into a computable representation); perform exchange model code checking (Abstract: “automating the code compliance checking processes to achieve design efficiency…”), wherein exchange model (“generating algorithms for the data exchanges between the components of the framework to execute the virtual review process of a building design in order to achieve design accuracy” (interpreted as exchange models), page 5) code checking comprises using a plurality of exchange models (Nawari – " ... decomposition of the design regulations and rules. This includes data analysis, partitioning and classification of regulatory text into broad categories", page 5, last paragraph); perform code conformance checking, wherein the code conformance checking (“a software prototype developed to demonstrate the checking of designed components as described in application program databases for conformance with design standards”, page 3) comprises receiving a request from the exchange models (“generating algorithms for the data exchanges between the components of the framework to execute the virtual review process of a building design in order to achieve design accuracy” (interpreted as exchange models), page 5) and passing the building permit application file information to code checking modules (Abstract: “The objectives of this study comprise … transforming the written code regulations and rules into a computable model … define the various modules required for computerizing of the code compliance verification process.”) configured to check building code provisions and any regulations per local, state, national or international requirements (Nawari – “degree of customization to modify the parameters of each rule to match specific local regulations”, page 3; “To provide evidence for the Proof of Concept (POC), a two-story building is considered in a typical design review process examining regulations and provisions from FBC-R 2017”, page 13); perform verification reporting (“produce various output reports such as … views showing objects that are in noncompliance along with the detailed information about the regulation”, page 6) based on input provided from the code checking modules (Nawari – "examining the compliance of the areas of the spaces [of the two-storey building]. .. according to the FBC-2017', page 14, second-to-last paragraph); and perform results reporting results reporting based on findings of the verification reporting (Nawari – "Figure 12: Results example of checking compliance with the space areas regulations of FBC-2017-R', Figure 12, page 15; “define the various modules required for computerizing of the code compliance verification process”, page 1).
Nawari may not expressly disclose the “code conformance checking” and “computer-readable medium having instructions stored therein, wherein the instructions” features, however, Conover 2009/0125283 teaches (Conover 2009/0125283 [0043 - computer software instructions, residing on electronic memory and/or media, that are executed by the computer] The builder 140 receives the inputs as clean xml and with the use of the protocol 150 by someone familiar with the input (code provisions) allows them to create SMARTcodes.TM.. For example, a user of the system can specify through the protocol(s) 150 that particular codes or code sections should take precedence over others. The builder 140 is a software program that may be implemented by a general purpose computer, with a processor, memory, storage devices, network connections and input/output devices, including graphical user interface displays and printers for generating output reports. The builder 140 may receive the inputs directly from memory or a storage device or over a network. In general, the builder 140 implements a protocol 150 for creating the SMARTcodes.TM., which is generally implemented in computer software instructions, residing on electronic memory and/or media, that are executed by the computer as given by the user of the builder 140. [0002 - systems, programs and methods for compliance checking with respect to building regulations (codes) … automate, with respect to building regulations, creation, storage and access to rule sets from the regulations to facilitate automated compliance checking of building plans and specifications against those regulations] The invention relates to systems, programs and methods for compliance checking with respect to building regulations (codes). More specifically, these are systems, programs and methods to automate, with respect to building regulations, creation, storage and access to rule sets from the regulations to facilitate automated compliance checking of building plans and specifications against those regulations and to do so in a secure, technically accurate and reliable manner, and to collect and utilize building and system data submitted for compliance checking for a variety of purposes. [0007 - protocol and software can also be used to create "smart" versions of Federal, state, and locally adopted versions of those codes, as well as reference standards and any other rules or regulations] A protocol and software program are provided to create tagged representations of the ICC model building construction codes, sometimes referred to herein as SMARTcodes.TM.(a trademark of the International Code Council), that have a tagging schema that reflects the logic and requirements of the ICC's codes, from "clean" xml files of the codes. The protocol and software can also be used to create "smart" versions of Federal, state, and locally adopted versions of those codes, as well as reference standards and any other rules or regulations. The SMARTcodes.TM. and embedded schema and tags are usable, when presented as a limiting rule set, by model checking software (MCS) as a limiting, or model, set of constraints when the MCS reads a building information model (BIM) that contains information about a building to check the building against the SMARTcodes.TM. and automatically assess code compliance for the building. In addition, the SMARTcodes.TM. may be accessed manually (by SMARTcodes QUERY.TM., a trademark of the International Code Council) by users through web-based interfaces to provide, in addition to information related to code compliance, output that is useful for a variety of purposes, such as answers to specific questions about the codes and code compliance, code criteria applicable to a topic, compliance checklists, product listing directories, code interpretations, etc. In addition "horizontal searches" identifying model code and Federal, state and local differences for each topic represented in codes can be conducted to facilitate assessing the impact of variation in codes on a particular material or product. The latter supports national companies that sell products that are used in multiple places with different codes and regulations. [0068 - a comprehensive database concerning all design, construction and operational aspects of a building or structure from a building regulatory standpoint from a federal, state and local vantage point] During operation, the builder 140 and protocol 150 are used to keep a database of SMARTcodes.TM., standards, etc. criteria 205 up to date with current versions of relevant model codes, Federal, state and local amendment to those codes, standards, regulations etc. Thus, the database of SMARTcodes.TM., etc. 205 is a comprehensive database concerning all design, construction and operational aspects of a building or structure from a building regulatory standpoint from a federal, state and local vantage point. While it is desirable for the database of SMARTcodes.TM., tagged language, etc. 205 to be as comprehensive as possible with respect to different codes, standards, and regulations and the scope of what may be checked within each code, it is also possible to have multiple trusted entities where each maintains a database that is more focused or targeted on other criteria (e.g. green, sustainable, provisions beyond minimums code etc.). It is also possible to have separate databases within a single trusted entity that target different codes, standards, regulations, design guides, rules, manuals, etc (e.g. criteria applicable to buildings).). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Nawari to include the features as taught by Conover 2009/0125283. One of ordinary skill in the art would have been motivated to do so to utilize well known features useful for automating building code conformance which should prove to improve user experience, maximize profits, and optimize revenue.
19/094,455 – Claim 2. Nawari further teaches The method of claim 1, wherein the exchange models (“generating algorithms for the data exchanges between the components of the framework to execute the virtual review process of a building design in order to achieve design accuracy” (interpreted as exchange models), page 5) comprise at least a building code regulations (“The concept of automating the CCC process described in this paper focuses on building regulations compliance checking mechanisms that are defined by the relationship among various design and engineering information management systems and the Building Information Modeling (BlM) and how this computerization will assist in streamlining communication and dissemination of building design review information amongst breadth of stakeholders”, page 2; “The Transformation Reasoning Algorithm (TRA) introduces the taxonomy for the building regulations knowledge followed by the conceptualization process.”, page 7) and architectural design use case exchange model (“Computer Aided Architectural Design”, page 16), a building code regulations and structural design use case exchange model (“Building Information Modeling: Framework for Structural Design”, page 16), a building code regulations and mechanical system design use case exchange model, a building code regulations and electrical design use case exchange model (“electronic code checking for Buildings”, page 17), a building code regulations and plumbing design use case exchange model, a building code regulations and fire protection design use case exchange model (“Automated Code Compliance Checking Model for Fire”, page 17), and a building code regulations and results reporting use case exchange model (Nawari – page 6 disclosing various models).
19/094,455 – Claim 9. The system of claim 8, wherein the exchange models comprise at least a building code regulations and architectural design use case exchange model, a building code regulations and structural design use case exchange model, a building code regulations and mechanical system design use case exchange model, a building code regulations and electrical design use case exchange model, a building code regulations and plumbing design use case exchange model, a building code regulations and fire protection design use case exchange model, and a building code regulations and results reporting use case exchange model.
19/094,455 – Claim 17. The non-transitory computer-readable medium of claim 15, wherein the exchange models comprise at least a building code regulations and architectural design use case exchange model, a building code regulations and structural design use case exchange model, a building code regulations and mechanical system design use case exchange model, a building code regulations and electrical design use case exchange model, a building code regulations and plumbing design use case exchange model, a building code regulations and fire protection design use case exchange model, and a building code regulations and results reporting use case exchange model.
Claims 9 and 17, have similar limitations as of Claim 2, therefore they are REJECTED under the same rationale as Claim 2.
19/094,455 – Claim 3. Nawari further teaches The method of claim 1, wherein the code checking modules (“A BlM-based web service framework for green building energy simulation and code checking… BIM based electronic code checking for Buildings…”, page 17) comprise at least an architectural design checking module (“Computer Aided Architectural Design”, page 16), a structural design checking module (“Framework for Structural Design… decision logic for structural design… A knowledge-based standards processor for structural component design…”, page 16), a mechanical, electrical, plumbing design checking module, or a fire protection design (“Automated Code Compliance Checking Model for Fire Egress Codes”, page 17) checking module (Nawari – "examining the compliance of the areas of the spaces [of the two-storey building]. .. according to the FBC-2017', page 14, second-to-last paragraph).
19/094,455 – Claim 10. The system of claim 8, wherein the code checking modules comprise at least an architectural design checking module, a structural design checking module, a mechanical, electrical, plumbing design checking module, or a fire protection design checking module.
19/094,455 – Claim 18. The non-transitory computer-readable medium of claim 15, wherein the code checking modules comprise at least an architectural design checking module, a structural design checking module, a mechanical, electrical, plumbing design checking module, or a fire protection design checking module.
Claims 10 and 18, have similar limitations as of Claim 3, therefore they are REJECTED under the same rationale as Claim 3.
19/094,455 – Claim 4. Nawari further teaches The method of claim 1, further comprising transforming, by the hardware processor (“computer environment… computer systems”, page 2), a building code regulation into a computable record that defines a building design and/or engineering rule for the building code regulation (Nawari – “This paper offers a generalized adaptive framework (GAF) for automating or semi-automating the code compliance verification process which is based on an object-driven representation of building rules that can deal with certain and uncertain data and transform code and standards regulations into computable expressions using the Transformation Reasoning Algorithm (TRA). The framework is flexible and can adapt to various engineering design disciplines”, page 15).
19/094,455 – Claim 11. Nawari further teaches The system of claim 8, wherein the one or more software modules are configured to (“As a software application integrated with a specific design tool”, page 3), when executed by the at least one hardware processor (“computer environment… computer systems”, page 2), to transform a building code regulation into a computable record that defines a building design and engineering rule for the building code regulation (Nawari – “This paper offers a generalized adaptive framework (GAF) for automating or semi-automating the code compliance verification process which is based on an object-driven representation of building rules that can deal with certain and uncertain data and transform code and standards regulations into computable expressions using the Transformation Reasoning Algorithm (TRA). The framework is flexible and can adapt to various engineering design disciplines”, page 15).
19/094,455 – Claim 19. The non-transitory computer-readable medium of claim 15, wherein the instructions, when executed by a processor (“computer environment… computer systems”, page 2), cause the processor to transform a building code regulation into a computable record that defines a building design rule for the building code regulation (Nawari – “This paper offers a generalized adaptive framework (GAF) for automating or semi-automating the code compliance verification process which is based on an object-driven representation of building rules that can deal with certain and uncertain data and transform code and standards regulations into computable expressions using the Transformation Reasoning Algorithm (TRA). The framework is flexible and can adapt to various engineering design disciplines”, page 15).
Claims 11 and 19, have similar limitations as of Claim 4, therefore they are REJECTED under the same rationale as Claim 4.
19/094,455 – Claim 5. Nawari further teaches The method of claim 4, wherein a semantic structure of the building code regulation is translated into object rules or parametric models (“Semantic modeling for automated compliance checking”, page 16) and associated with the building permit application file information being examined (Nawari – page 4, Table 1; “the semantic structure of each rule is translated into object expressions or parametric models using the Transformation Reasoning Algorithm (TRA) that would lead to neutral data format such as the Industry Foundation Classes (IFC) data schema”, pages 6-7; “clauses of the regulations that can be transformed from the textual format into a set of object rules”, page 7).
19/094,455 – Claim 12. The system of claim 11, wherein a semantic structure of the building code regulation is translated into object rules or parametric models and associated with the building permit application file information being examined.
Claim 12, has similar limitations as of Claim 5, therefore it is REJECTED under the same rationale as Claim 5.
19/094,455 – Claim 6. Nawari further teaches The method of claim 4, wherein the building code regulation is transformed using a Transformation Logic Algorithm (TLA) (“6. Transformation Reasoning Algorithm (TRA). The TRA introduces the taxonomy for the building regulations knowledge followed by the conceptualization process. Subsequently, knowledge created will be transformed to a new fomalized form to deduce various facts to carry out automated reasoning.”, page 7), neural Natural Language Processing (NLP) techniques (“Natural Language Processing (NLP)”, Table1., page 4), or artificial intelligence (“new developments in Artificial Intelligence (AI) research and Building Information Modeling (BIM) could offer practical concepts to resolve some of the current major problems with automating CCC.”, page 2; see page 8, last paragraph - page 11 for a translation of the Florida Building Code 2017 - Residential (FBC-R 2017) into a computable representation).
19/094,455 – Claim 13. The system of claim 11, wherein the building code regulation is transformed using a Transformation Logic Algorithm (TLA), the neural Natural Language Processing (NLP) techniques, or the artificial intelligence.
19/094,455 – Claim 20. The non-transitory computer-readable medium of claim 19, wherein the building code regulation is transformed using a Transformation Logic Algorithm (TLA), neural Natural Language Processing (NLP) techniques, or artificial intelligence.
Claims 13 and 20, have similar limitations as of Claim 6, therefore they are REJECTED under the same rationale as Claim 6.
Claims 7, 14, 16 are rejected under 35 U.S.C. 103 as being unpatentable over: Nawari; in view of Conover 2009/0125283; in further view of Morimoto et al. 2014/0337008.
19/094,455 – Claim 7. Nawari further teaches The method of claim 1, further comprising graphically displaying (Figs. 1 and 9), by the hardware processor (“computer environment… computer systems”, page 2), a semi-transparent interface embedded with one or more buttons for initiating an action of code conformance checking (Nawari – “The SICAD system was a software prototype developed to demonstrate the checking of designed components as described in application program databases for conformance with design standards.” page 3;“generalized adaptive framework (GAF) for automating or semi-automating the code compliance verification process which is based on an object-driven representation of building rules that can deal with certain and uncertain data and transform code and standards regulations into computable expressions using the Transformation Reasoning Algorithm (TRA)” page 15).
Nawari may not expressly disclose the “semi-transparent” features, however, Morimoto et al. 2014/0337008 teaches these features (Morimoto et al. 2014/0337008 [Fig. 11; 0028 - display a switching button that is semi-transparent] (a) of FIG. 11 is a view illustrating a Widget annotation that is described in an image file configured to display a switching button that is semi-transparent. (b) of FIG. 11 is a view illustrating a graphics-state parameter dictionary that is described in the image file configured to display the switching button that is semi-transparent. (c) of FIG. 11 is a view illustrating a form XObject that is described in the image file configured to display the switching button that is semi-transparent.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Nawari to include the features as taught by Morimoto et al. 2014/0337008. One of ordinary skill in the art would have been motivated to do so to utilize well known features useful for automating building code conformance and graphically displaying information which should prove to improve user experience, maximize profits, and optimize revenue.
19/094,455 – Claim 14. Nawari further teaches The system of claim 11, wherein the one or more software modules are configured to (“As a software application integrated with a specific design tool”, page 3), when executed by the at least one hardware processor (“computer environment… computer systems”, page 2), to graphically display (Figs. 1 and 9) a semi-transparent interface embedded with one or more buttons for initiating an action of code conformance checking (Nawari – “The SICAD system was a software prototype developed to demonstrate the checking of designed components as described in application program databases for conformance with design standards.” page 3;“generalized adaptive framework (GAF) for automating or semi-automating the code compliance verification process which is based on an object-driven representation of building rules that can deal with certain and uncertain data and transform code and standards regulations into computable expressions using the Transformation Reasoning Algorithm (TRA)” page 15).
Nawari may not expressly disclose the “semi-transparent” features, however, Morimoto et al. 2014/0337008 teaches these features (Morimoto et al. 2014/0337008 [Fig. 11; 0028 - display a switching button that is semi-transparent] (a) of FIG. 11 is a view illustrating a Widget annotation that is described in an image file configured to display a switching button that is semi-transparent. (b) of FIG. 11 is a view illustrating a graphics-state parameter dictionary that is described in the image file configured to display the switching button that is semi-transparent. (c) of FIG. 11 is a view illustrating a form XObject that is described in the image file configured to display the switching button that is semi-transparent.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Nawari to include the features as taught by Morimoto et al. 2014/0337008. One of ordinary skill in the art would have been motivated to do so to utilize well known features useful for automating building code conformance and graphically displaying information which should prove to improve user experience, maximize profits, and optimize revenue.
19/094,455 – Claim 16. Nawari further teaches The non-transitory computer-readable medium of claim 15, wherein the instructions, when executed by a processor, cause the processor to graphically display (Figs. 1 and 9) a semi-transparent interface embedded with one or more buttons for initiating an action of code conformance checking(Nawari – “The SICAD system was a software prototype developed to demonstrate the checking of designed components as described in application program databases for conformance with design standards.” page 3;“generalized adaptive framework (GAF) for automating or semi-automating the code compliance verification process which is based on an object-driven representation of building rules that can deal with certain and uncertain data and transform code and standards regulations into computable expressions using the Transformation Reasoning Algorithm (TRA)” page 15).
Nawari may not expressly disclose the “semi-transparent” features, however, Morimoto et al. 2014/0337008 teaches these features (Morimoto et al. 2014/0337008 [Fig. 11; 0028 - display a switching button that is semi-transparent] (a) of FIG. 11 is a view illustrating a Widget annotation that is described in an image file configured to display a switching button that is semi-transparent. (b) of FIG. 11 is a view illustrating a graphics-state parameter dictionary that is described in the image file configured to display the switching button that is semi-transparent. (c) of FIG. 11 is a view illustrating a form XObject that is described in the image file configured to display the switching button that is semi-transparent.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Nawari to include the features as taught by Morimoto et al. 2014/0337008. One of ordinary skill in the art would have been motivated to do so to utilize well known features useful for automating building code conformance and graphically displaying information which should prove to improve user experience, maximize profits, and optimize revenue.
Claims 14 and 16, have similar limitations as of Claim 7, therefore they are REJECTED under the same rationale as Claim 7.
Prosecution Insights