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 X are canceled.
Claims X are new.
Claims 1-20 are pending and have been examined.
This action is in reply to the papers filed on 03/28/2025 (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 xxx.
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 xxx are allowed. The closest prior art (See PTO-892, Notice of References Cited) does not teach the claimed:
The closest prior-art (xxx) teach the features as disclosed in Non-final Rejection (xxxx), however, these cited references do not teach and the prior-art does not teach at least the following combination of features and/or elements:
determining, at a second time after associating the information corresponding to the first loyalty card with the logged location, that a second user computing device is located within a specified distance of the logged location using a second positioning system of the second user computing device; in response to determining that the second user computing device is located within the specified distance of the logged location of the first user computing device at the first time of detecting: retrieving information corresponding to a second loyalty card, the second loyalty card being associated with the merchant and the second user computing device; and displaying, by the second user computing device, data describing the second loyalty card.
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-20 are 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-20 are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter because the claimed invention is directed to an abstract idea without significantly more. These claims recite a method, system, and computer readable medium for automated building code conformance.
Claim 1 recites [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; 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; performing, using at least one hardware processor, verification reporting based on input provided from the code checking modules; and performing, using at least one hardware processor, results reporting based on findings of the verification reporting.
The claims are being rejected according to the 2019 Revised Patent Subject Matter Eligibility Guidance (Federal Register, Vol. 84, No. 5, p. 50-57 (Jan. 7, 2019)).
Step 1: Does the Claim Fall within a Statutory Category?
Yes. Claims 1-7 recite a method and, therefore, are directed to the statutory class of a process. Claims 8-14 recite a system/apparatus and, therefore, are directed to the statutory class of machine. Claims 15-20 recite a non-transitory computer readable medium/computer product and, therefore, are directed to the statutory class of a manufacture.
Step 2A, Prong One: Is a Judicial Exception Recited?
Yes. The following tables identify the specific limitations that recite an abstract idea. The column that identifies the additional elements will be relevant to the analysis in step 2A, prong two, and step 2B.
Claim 1: Identification of Abstract Idea and Additional Elements, using Broadest Reasonable Interpretation
Claim Limitation
Abstract Idea
Additional Element
1. A method comprising:
No additional elements are positively claimed.
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;
This limitation includes the step(s) of: 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.
But for the hardware processor, this limitation is directed to processing and/or communicating known information to facilitate automated building code conformance which may be categorized as any of the following:
mental process – concepts performed in the human mind (including an observation, evaluation, judgment, opinion)
and/or
certain method of organizing human activity –
fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
performing, using at least one hardware processor, design model validation…
performing, using the at least one hardware processor, exchange model code checking, wherein exchange model code checking comprises using a plurality of exchange models;
This limitation includes the step(s) of: performing, using the at least one hardware processor, exchange model code checking, wherein exchange model code checking comprises using a plurality of exchange models.
But for the hardware processor, this limitation is directed to processing and/or communicating known information to facilitate automated building code conformance which may be categorized as any of the following:
mental process – concepts performed in the human mind (including an observation, evaluation, judgment, opinion)
and/or
certain method of organizing human activity –
fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
performing, using the at least one hardware processor, exchange model code checking…
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;
This limitation includes the step(s) of: 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.
But for the hardware processor, this limitation is directed to processing and/or communicating known information to facilitate automated building code conformance which may be categorized as any of the following:
mental process – concepts performed in the human mind (including an observation, evaluation, judgment, opinion)
and/or
certain method of organizing human activity –
fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
performing, using the at least one hardware processor, code conformance checking…
performing, using at least one hardware processor, verification reporting based on input provided from the code checking modules; and
This limitation includes the step(s) of: performing, using at least one hardware processor, verification reporting based on input provided from the code checking modules.
But for the hardware processor, this limitation is directed to processing and/or communicating known information to facilitate automated building code conformance which may be categorized as any of the following:
mental process – concepts performed in the human mind (including an observation, evaluation, judgment, opinion)
and/or
certain method of organizing human activity –
fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
performing, using at least one hardware processor, verification reporting…
performing, using at least one hardware processor, results reporting based on findings of the verification reporting.
This limitation includes the step(s) of: performing, using at least one hardware processor, results reporting based on findings of the verification reporting.
But for the hardware processor, this limitation is directed to processing and/or communicating known information to facilitate automated building code conformance which may be categorized as any of the following:
mental process – concepts performed in the human mind (including an observation, evaluation, judgment, opinion)
and/or
certain method of organizing human activity –
fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
performing, using at least one hardware processor, results reporting…
As shown above, under Step 2A, Prong One, the claims recite a judicial exception (an abstract idea). The claims are directed to the abstract idea of automating building code conformance, which, pursuant to MPEP 2106.04, is aptly categorized as a mental process and/or a method of organizing human activity. Therefore, under Step 2A, Prong One, the claims recite a judicial exception.
Next, the aforementioned claims recite additional functional elements that are associated with the judicial exception, including: a processor for processing and communicating information. Examiner understands these limitations to be insignificant extrasolution activity. (See Accenture, 728 F.3d 1336, 108 U.S.P.Q.2d 1173 (Fed. Cir. 2013), citing Cf. Diamond v. Diehr, 450 U.S. 175, 191-192 (1981) ("[I]nsignificant post-solution activity will not transform an unpatentable principle in to a patentable process.”).
The aforementioned claims also recite additional technical elements including: a “processor” to execute the method and system and a “non-transitory computer-readable medium” for storing executable instructions. These limitations are recited at a high level of generality and appear to be nothing more than generic computer components. Claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible. Alice Corp., 134 S. Ct. at 2358, 110 USPQ2d at 1983. See also 134 S. Ct. at 2389, 110 USPQ2d at 1984.
Step 2A, Prong Two: Is the Abstract Idea Integrated into a Practical Application?
No. The judicial exception is not integrated into a practical application. The additional elements listed above that relate to computing components are recited at a high level of generality (i.e., as generic components performing generic computer functions such as communicating, receiving, processing, analyzing, and outputting/displaying data) such that they amount to no more than mere instructions to apply the exception using generic computing components. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Additionally, the claims do not purport to improve the functioning of the computer itself. There is no technological problem that the claimed invention solves. Rather, the computer system is invoked merely as a tool. Accordingly, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, these claims are directed to an abstract idea.
Furthermore, looking at the elements individually and in combination, under Step 2A, Prong Two, the claims as a whole do not integrate the judicial exception into a practical application because they fail to: improve the functioning of a computer or a technical field, apply the judicial exception in the treatment or prophylaxis of a disease, apply the judicial exception with a particular machine, effect a transformation or reduction of a particular article to a different state or thing, or apply the judicial exception beyond generally linking the use of the judicial exception to a particular technological environment. Rather, the claims merely use a computer as a tool to perform the abstract idea(s), and/or add insignificant extra-solution activity to the judicial exception, and/or generally link the use of the judicial exception to a particular technological environment.
Step 2B: Does the Claim Provide an Inventive Concept?
Next, under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements, when considered both individually and as an ordered combination, do not amount to significantly more than the abstract idea. Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. Simply put, as noted above, there is no indication that the combination of elements improves the functioning of a computer (or any other technology), and their collective functions merely provide conventional computer implementation. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements relating to computing components amount to no more than applying the exception using a generic computing components. Mere instructions to apply an exception using a generic computing component cannot provide an inventive concept. Furthermore, the broadest reasonable interpretation of the claimed computer components (i.e., additional elements) includes any generic computing components that are capable of being programmed to communicate, receive, send, process, analyze, output, or display data. Furthermore, Applicant’s Specification (PGPub. 2025/0225599 [0026; 0045]) refers to a general computer system, but they do not include any technically-specific computer algorithm or code.
Additionally, pursuant to the requirement under Berkheimer, the following citations are provided to demonstrate that the additional elements, identified as extra-solution activity, amount to activities that are well-understood, routine, and conventional. See MPEP 2106.05(d).
Capturing an image (code) with an RFID reader. Ritter, US Patent No. 7734507 (Col. 3, Lines 56-67); “RFID: Riding on the Chip” by Pat Russo. Frozen Food Age. New York: Dec. 2003, vol. 52, Issue 5; page S22.
Receiving or transmitting data over a network. Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362; OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014).
Storing and retrieving information in memory. Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93.
Outputting/Presenting data to a user. Mayo, 566 U.S. at 79, 101 USPQ2d at 1968; OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1092-93 (Fed. Cir. 2015); MPEP 2106.05(g)(3).
Using a machine learning model to determine user segment characteristics for an ad campaign. https://whites.agency/blog/how-to-use-machine-learning-for-customer-segmentation/.
Thus, taken alone and in combination, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea), and are ineligible under 35 USC 101.
Independent system claim 8 and CRM claim 15 also contains the identified abstract ideas, with the additional elements of a processor and storage medium, which are a generic computer components, and thus not significantly more for the same reasons and rationale above.
Dependent claims 2-7, 9-14, and 16-20 further describe the abstract idea. The additional elements of the dependent claims fail to integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea. Thus, as the dependent claims remain directed to a judicial exception, and as the additional elements of the claims do not amount to significantly more, the dependent claims are not patent eligible.
As such, the claims are not patent eligible.
Invention Could be Performed Manually
It is conceivable that the invention could be performed manually without the aid of machine and/or computer. For example, Applicant claims performing a model validation, performing model code checking, performing code conformance checking, reporting, etc… Each of these features could be performed manually and/or with the aid of a simple generic computer to facilitate the transmission of data.
See also Leapfrog Enterprises, Inc. v. Fisher-Price, Inc., and In re Venner, which stand for the concept that automating manual activity and/or applying modern electronics to older mechanical devices to accomplish the same result is not sufficient to distinguish over the prior art. Here, applicant is merely claiming computers to facilitate and/or automate functions which used to be commonly performed by a human.
Leapfrog Enterprises, Inc. v. Fisher-Price, Inc., 485 F.3d 1157, 82 USPQ2d 1687 (Fed. Cir. 2007) "[a]pplying modern electronics to older mechanical devices has been commonplace in recent years…"). The combination is thus the adaptation of an old idea or invention using newer technology that is commonly available and understood in the art.
In In re Venner, 262 F.2d 91, 95, 120 USPQ 193, 194 (CCPA 1958), the court held that broadly providing an automatic or mechanical means to replace manual activity which accomplished the same result is not sufficient to distinguish over the prior art. MPEP 2144.04, III Automating a Manual Activity.
MPEP 2144.04 III - Automating a Manual Activity and In re Venner, 262 F.2d 91, 95, 120 USPQ 193, 194 (CCPA 1958) further stand for and provide motivation for using technology, hardware, computer, or server to automate a manual activity.
Therefore, the Office finds no improvements to another technology or field, no improvements to the function of the computer itself, and no meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. Therefore, based on the two-part Alice Corp. analysis, there are no limitations in any of the claims that transform the exception (i.e., the abstract idea) into a patent eligible application.
Claim Rejections - Not an Ordered Combination
None of the limitations, considered as an ordered combination provide eligibility, because taken as a whole, the claims simply instruct the practitioner to implement the abstract idea with routine, conventional activity.
Claim Rejections - Preemption
Allowing the claims, as presently claimed, would preempt others from automating building code conformance. Furthermore, the claim language only recites the abstract idea of performing this method, there are no concrete steps articulating a particular way in which this idea is being implemented or describing how it is being performed.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
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 §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:
Examiner’s Response: Claim Rejections – 35 USC § 102 / § 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.
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 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 mailing date of this final action.
THIS ACTION IS MADE FINAL
Applicant’s amendment necessitated new grounds of rejection and FINAL Rejection.
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