DETAILED ACTION
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
This Office action is in response to correspondence received July 25, 2025.
Claims 1, 4, 6, 7, 8, 12, and 15 are amended. Claims 9 and 10 are canceled. Claims 1-8 and 11-15 are pending and have been examined.
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-8 and 11-15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s):
Claim 1:
A method of designing a charging station to charge electric vehicles at a selected site, comprising: receiving a compiled set of engineering rules, wherein each engineering rule implements a predetermined design decision applicable to multiple charging station sites; storing non site specific information in a [data store], the non-site specific information comprising information obtained from suppliers and manufacturers; storing site specific information for the selected site received via a user interface to the [data store] , the site specific information comprising information that physically defines the selected site; conveying at least some of the non-site specific information and site specific information from the [data store] to the processor; generating deliverables by implementing design decisions using at least the set of engineering rules, the non-site specific information, and the site specific information, wherein the deliverables comprise engineering designs for the selected site; and sending the deliverables to an end user.
Claim 8:
evaluating and developing a prospective site for a charging station for electric vehicles, comprising: receive site specific information, the site specific information comprising information that physically defines the prospective site and physical characteristics of the charging station; a [data store] configured to store at least non site specific information and site specific information received , wherein the non-site specific information defines at least one common feature of at least two charging station sites; and a set of engineering rules, each engineering rule configured to implement a predetermined design decision applicable to multiple charging station sites, the access the [data store] and generate at least one deliverable by implementing design decisions using at least the set of engineering rules, the non-site specific information, and the site specific information, wherein the deliverables comprise engineering designs for the selected site .
Claims 1 and 8 recite an abstract idea that is a mental process because the steps are of making observation (receiving information) or judgments (making determinations/decisions) and then sending information which can be done with pen and paper. The steps are for designing a charging station and they describe the mental steps one would go through in order to do this. Each step one could perform mentally. Therefore, the claims recite an abstract idea (as identified above).
This judicial exception is not integrated into a practical application. The additional elements of a processor, database, user interface are generic computing components and here they are recited as applied to the abstract idea. The elements in combination amounts to a generic computer wherein in some manner the abstract idea steps are performed. See MPEP 2106.05(f)(2). Therefore there is not a practical application of the abstract idea.
The additional elements in claim 1 are:
by a processor encoding instructions for/by the processor
database
The additional elements in claim 8 are:
A system for
a user interface configured to/from the user interface
a processor encoded with; processor further configured to
database
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the rational is carried over from Step 2B above (practical application). For the same reason that there is not a practical application, there is not significantly more recited.
Per the dependent claims 2, 4, 11, 12, and 15, the abstract idea is further defined with elements that were previously analyzed (like databases) in the independent claims.
Per claims 6, 7, 13, and 14, the limitation of blockchain is apply it as it is used to store or deliver information, or “automatically execute contract conditions” which is a smart contract. In all of these cases the steps are apply it as they are using blockchain/smart contracts in their ordinary capacity to be applied to the abstract idea.
Per claim 3, the limitation of constructing the station is a field of use limitation, see MPEP 2106.05(h) because it is limiting the abstract idea to the field of construction.
Therefore, claims 1-8 and 11-15 are rejected under 35 USC 101.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-5, 8, 11, 12, and 15 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Brier et al., US PGPUB 20130061198 A1 (“Brier”).
Per claim 1, Brier teaches A method of designing a charging station to charge electric vehicles at a selected site, comprising: in par 034: “Described herein are techniques for performing mobile design automation. The apparatuses, methods, and techniques described below may be implemented as a computer program (software) executing on one or more mobile computing devices, such as a laptop computer, a tablet computer with a touch screen input, or handheld mobile computer, for example. The computer program may further be stored on a computer readable storage medium or reside on a remote server that may be connected to by a mobile device.” This teaches designing, as in engineering. Charging vehicles is taught in par 052: “As further example energy projects, some embodiments of the present invention may be used in electric vehicle charging projects,” Therefore designing a charging station to charge electric vehicles is taught in these two paragraphs. At a selected site is taught in par 052 where information is entered for a “particular” which teaches selected site: “In a solar power installation project application, a field technician, for example, may load a mobile device with data for a particular installation project at a particular installation site and use the mobile device to execute software performing at least some of the features described above to obtain the information required to install a solar power system at the site.”
Brier then teaches receiving by a processor encoding instructions for a compiled set of engineering rules, wherein each engineering rule implements a predetermined design decision applicable to multiple charging station sites in par 053: “For example, in one embodiment the user may load a schematic site file onto the mobile device, such as a Precigeo file, where solar and roof schematics are obtained through the analysis of aerial imagery, for example. The user may further load information pertaining to an authority having jurisdiction ("AHJ") as mentioned above. Typical AHJs include state, county, or city governments or utility companies, for example. AHJ files may include specific requirements for physically locating certain objects on a property or how equipment is to be installed or configured, for example. Appendices A and B illustrate two example metadata files loaded to the mobile device. Appendix A illustrates AHJ metadata for electrical and Appendix B illustrates AHJ metadata for mounting planes. As illustrated in Appendix A and B, data loaded from a main office computer may include AHJ data, project specific data, and financial data, for example. AHJ requirements applicable to a particular project are listed between "AHJAuditNotes_Key" followed by a value marked as TRUE or FALSE. If an AHJ requirement is followed by a value set to TRUE, then the particular AHJ requirement is applicable to the particular project. A value of FALSE indicates that the particular AHJ requirement is not applicable to the particular project. Other data imported into the mobile device is illustrated in Appendix A and B. Names of the example variables in the attached appendices are representative of each variables use within the system.” See also par 068: “In one embodiment, data for the project may include an AHJ filed used to limit the placement of the solar modules. For instance, the AHJ may be used to determine a fire setback, for example. The system may further determine invalid module placements based on physical and electrical rules limiting placement and connectivity. For example, an AHJ may prohibit putting panels over bathroom plumbing vents.” The AHJ rules teach complied sets of engineering rules. These rules are, as explained in the above paragraphs, particular to jurisdictions and therefore are not particular to sites (and are therefore applicable to many sites). Loading information teaches receiving by the processor.
Brier then teaches storing non site specific information in a database, the non-site specific information comprising information obtained from suppliers and manufacturers; in par 049: “‘Design requirements may be stored on 3 computer : i system, such as in a database 710, for example’” See also par 067: “‘Referring again to FIG. 13, the data for a particular project may include : ‘ information about the type of system sold io & particular customer... The system may pre-store a plurality of module types available for : ‘ selection by a user. When module selection button 1420 is selected, the prestored module types (e.g., module models and manufacturers} : i are displayed to a user and the user may select the module type that was sold to the particular customer.’)”
Brier then teaches storing site specific information for the selected site received via a user interface to the database, the site specific information comprising information that physically defines the selected site in par 044: “In some embodiments, engineering escalations may occur if certain pre-defined scenarios are met (e.g. a certain type of panel or roof type is encountered, or where more detailed structural calculations may be required to determine the best way to safely install a system). If the user's input triggers an engineering escalation, an entry may be generated for the escalation at 508. For example, a new field of a database or new line of a text document may be generated describing the nature of the engineering escalation.” The user is inputting, so this teaches received via the user interface, and it creates a new field of a database, and it is site specific information because something specific is encountered at a site. in item 710, Figs 6 & 7. See also in par 039: “At 502, the software system may access design automation data stored on the mobile device, such as customized data for a particular project the user is working on (e.g., entered by others into the database earlier in the conversation with the customer) and preloaded data corresponding to different user specified options in the software, for example. At 503, process steps for the project are displayed to the user.” See also in par 040: “In some embodiments, the software can step a person in the field (e.g., an auditor) through the design process (e.g., an audit) in the most efficient way possible depending on the context of what the user observes on site. The user enters data into the system about the design constraints obtained on site, and the data constrains the design process steps that the user can execute. For example, in one embodiment, the remote design process may be structured as a decision tree to step the user through only the steps or questions relevant to a particular project for a particular customer (e.g., as determined by responses to earlier questions and data loaded into the system for a particular job). See also in par 043: “As a particular example, accessing process step 1 icon 610 may cause the system to retrieve a basic schematic (e.g., engineering drawing) of a particular project. Each of icons 621-623 may invoke a particular feature of a CAD program for manipulating the schematic one feature at a time to allow a user to adjust the schematic and enter data available at the remote project site. By limiting features and data entry to parameters only available at the remote project site, for example, the system guides the user through the process without requiring (or in some cases allowing) the user to manipulate a broader range of parameters more thoroughly understood by an expert at the main office. The user acts to enter and verify data available at the remote project site without being required to perform a full and complete analysis traditionally performed by highly trained experts in the main office, for example.” See also par 049: “Design requirements may be stored on a computer system, such as in a database 710, for example. Design requirements may include rules to determine if a particular block from the master template is to be removed or if a project specific block is to be added to the custom template. In one embodiment, attributes of a particular job are analyzed using such rules to determine particular blocks to be added to or deleted from the master template. Design requirements may pertain to information about a particular authority having jurisdiction (AHJ). For example, a particular city may require a particular size of paper for the design plans, setbacks, notes, or other particularities. Project specific blocks may be stored in database 710 or at a specified location on the computer system, for example.”
Brier then teaches conveying at least some of the non-site specific information and site specific information from the database to the processor in pars 049-050: “Design requirements may be stored on a computer system, such as in a database 710, for example. Design requirements may include rules to determine if a particular block from the master template is to be removed or if a project specific block is to be added to the custom template. In one embodiment, attributes of a particular job are analyzed using such rules to determine particular blocks to be added to or deleted from the master template. Design requirements may pertain to information about a particular authority having jurisdiction (AHJ). For example, a particular city may require a particular size of paper for the design plans, setbacks, notes, or other particularities. Project specific blocks may be stored in database 710 or at a specified location on the computer system, for example.
One example process for customizing a template is shown in FIG. 7B. At 750, the master template is accessed. At 751, design requirements and information for a particular job are retrieved. At 752, rules are applied to link design requirements to particular jobs. For example, the system may use a job ID to determine a State in which the job is being performed. A particular rule may indicate that if a job is in California, then a particular text field should be included in a particular notes section of the plan documents. In this case, the system may access a block including the particular text used for California jobs. At 753, blocks are added to or deleted from the master template. Continuing the example above, the system inserts the project specific block into the custom template at a specified location. Once all the design requirements have been processed, the system outputs a custom template, which may be loaded into mobile design automation software 715 for use on the particular job.” The database has site specific and jurisdiction specific information. Jurisdiction specific is not site specific as it is specific to a state, for example, and teaches non-site information. The manufacturer and supplier information does not teach the whole or the extent of non-site specific information and non-site specific information includes more than manufacturer supplier information in the scope of Applicant’s claims (Applicant stated that the non-site specific information comprised, which means that there may be more information than just manufacturer/supplier information. See comprise, MPEP).
Brier then teaches generating, by the processor, deliverables by implementing design decisions using at least the set of engineering rules, the non-site specific information, and the site specific information, wherein the deliverables comprise engineering designs for the selected site in pars 0101-0103 and Fig 24-25: “As another example, FIGS. 24-25 illustrate two mounting hardware block templates for mounting hardware for Spanish Tile with a 6 inch standoff and another template for mounting hardware for Spanish Tile with and 8 inch standoff. In this example, the system automatically selects blocks based on whether or not the auditor places solar panel modules over a vent on the roof, for example. These two templates may be used for all Spanish Tile roofs, for example. Bill of Material (BOM) blocks may be embedded in these templates, and their quantities may be updated by the program prior to the job being uploaded to computers (e.g., servers) at the main office.
Accordingly, the mobile system may include numerous CAD blocks for physical components (e.g., all available mounting hardware) and electrical components. The user may provide simple limited user interface actions to specify the solar design and the system may translate the limited user inputs into multiple CAD functions that result in a complete electrical model that represents the electrical properties of the system. A full plan set may be generated automatically by accessing and compiling numerous blocks based on the generated CAD functions, for example.
The Bill of Materials (BOM) may be contained within a CAD drawing. The metadata may be stored in CAD blocks. As mentioned above, a block is an entity within the CAD database, which may have a unique string identifier for its name. When the audit project is completed and uploaded back to the main office servers, the software may populate the BOM on the main office servers. Blocks are useful both for their storage of the BOM metadata, but also for their ability to be viewed easily by the end user in the output PDF, for example. BOM blocks may be embedded throughout the CAD files, and upon uploading the audit, the mobile design automation software may recursively search the CAD database, collects all the part numbers, and sends them to a database at the main office. For example, part numbers may be loaded into a supply chain management database, where the part numbers may be viewed and ordered by a user in a warehouse through the supply chain management software.” Non site specific is taught by templates that are used for all Spanish tile roofs. Site specific is taught by whether the auditor places solar panel modules over a vent in the roof, for example. Engineering rules is taught by CAD blocks for physical hardware. The full plan set being generated is generating the deliverables, as the plan set is the plans for constructing the specific PV element, see Fig 24, 25.
Brier then teaches and sending the deliverables to an end user in par 092: “The installation documentation may be generated in the form of one or more PDF documents that include a permit set (e.g., permit information provided to a building department having jurisdiction over the project location), single line drawings (e.g., electrical drawings provided to a utility having jurisdiction over the project location), and construction documents that may comprise a set of instructions for the installation crews.” PDF for the installation crews teaches sending deliverables to an end user. See where par 093 refers to the modified CAD drawings, and pars 093-0105 which further describe how the CAD template/drawings/designs/blocks are modified to produce the PDF documents.
Per claim 2, Brier teaches the limitations of claim 1, above. Brier further teaches developing a design feasibility package using the deliverables in Figs 4A and 7A. See also par 038: “At 405, output data for the design project is completed. For example, the user may enter data at each process step, an algorithm operates on the input data and validates the process step, and when all the process steps are completed, the system generates a project output (e.g., design documents). At 406, the data for the project, and generated project outputs, may be loaded into a backend system at the office. For example, in one embodiment data for a particular project may be loaded into multiple backend systems to create a physical manifestation of the design, order required materials from third parties, schedule personnel, tools, and other resources, and create entries in a finance and accounting system to account for the costs and potential revenues of the project, for example.” See also par 071: “Features and advantages of some embodiments may include evaluation and confirmation of design parameters. For example, in one embodiment a process step may include an algorithm that provides feedback to a user to indicate whether or not the design the user has entered is feasible, and may evaluate an optimum design if multiple design options exists. In one embodiment, the system may receive inputs from the user on the physical attributes of the design, attempt to disprove that a solution exists, and then determine a best solution from existing solutions. In this example, the system performs an automated calculation of electrical stringing of the modules and notifies the user if the module design is not feasible (e.g., if no stringing solution exists). If multiple possible stringing solutions exist, the system may output the optimum stringing solution for the particular physical attributes of the project.” See also par 072: “Next, at 1421, the system may evaluate feasibility of the design. For example, a recursive check may be performed against the total number of modules in the system to make sure the system level is solvable (e.g., if the user has drawn 13 modules, but the module string lengths are {7 . . . 12}, then no summation of a set of these numbers will get 13). At 1422 the system checks for invalid solutions and the user may be notified of an invalid configuration at 1423.”
Per claim 3, Brier teaches the limitations of claim 1, above. Brier further teaches constructing the charging station using the deliverables in par 052: “Features and advantages of the present invention include using a mobile device loaded with data and specialized software to allow a technician to perform a job site audit to generate a complete set of installation documentation (e.g., construction documents) with engineering involvement reduced or entirely eliminated. While the following example illustrates an application in the context of a residential solar energy system project (or photovoltaic "PV" system), it is to be understood that other embodiments may be used in a wide range of applications. As further example energy projects, some embodiments of the present invention may be used in electric vehicle charging projects, energy storage projects, energy efficiency project, solar hot water projects, metering/monitoring projects, or building controls and automation projects to name just a few.” See also par 092: “Referring again to FIG. 10, when a user has completed each of the process steps displayed in interface 1201, a user may select the generating installation documentation icon 1228. In this example, icon 1228 triggers the mobile device to generate installation documentation for the solar power installation project based on the input data. The installation documentation may be generated in the form of one or more PDF documents that include a permit set (e.g., permit information provided to a building department having jurisdiction over the project location), single line drawings (e.g., electrical drawings provided to a utility having jurisdiction over the project location), and construction documents that may comprise a set of instructions for the installation crews.”
Per claims 4 and 15, which are similar in scope, Brier teaches the limitations of claim 1, above, and claim 8, below. Brier further teaches receiving and storing secondary information in a database, wherein the secondary information is also used to generate the deliverables see Fig 7A Item 710 (database); in par 038: “FIG. 4 illustrates another embodiment of the present invention. At 401, design automation data is stored on a mobile computing device. The user may load a wide variety of data specific for a particular type of project on the mobile device before visiting the remote site, for example. In one embodiment, metadata specifying project requirements may be uploaded to the software system. In a construction context, metadata specifying project requirements may include a list of requirements for a type of project (e.g., requirements of an authority having jurisdiction (AHJ) for a solar project as described in more detail below, or a list of common building stock in that area, or snow, wind, or seismic load data) with a Boolean value or a quantitative value associated with each requirement to specify whether the requirement applies to the particular project being worked on or to what degree. For example, the mobile device may determine that one or more projects are in a particular jurisdiction and apply one more applicable AHJ rules to all projects in the particular jurisdiction. At 402, the user may activate the mobile design automation software on the mobile device and the design automation process steps are displayed to the user. At 403, design automation input data is received from the user. The input data may be received in response to specific algorithms for process steps for a particular type of project. At 404, a data processing algorithm for particular process steps may be executed to process the received data and possibly prestored data, for example. At 405, output data for the design project is completed. For example, the user may enter data at each process step, an algorithm operates on the input data and validates the process step, and when all the process steps are completed, the system generates a project output (e.g., design documents). At 406, the data for the project, and generated project outputs, may be loaded into a backend system at the office. For example, in one embodiment data for a particular project may be loaded into multiple backend systems to create a physical manifestation of the design, order required materials from third parties, schedule personnel, tools, and other resources, and create entries in a finance and accounting system to account for the costs and potential revenues of the project, for example.” See also par 092: “Referring again to FIG. 10, when a user has completed each of the process steps displayed in interface 1201, a user may select the generating installation documentation icon 1228. In this example, icon 1228 triggers the mobile device to generate installation documentation for the solar power installation project based on the input data. The installation documentation may be generated in the form of one or more PDF documents that include a permit set (e.g., permit information provided to a building department having jurisdiction over the project location), single line drawings (e.g., electrical drawings provided to a utility having jurisdiction over the project location), and construction documents that may comprise a set of instructions for the installation crews.”
Per claim 5, Brier teaches the limitations of claim 4, above. Brier further teaches the secondary information includes at least one of: marketing requirements, branding appearance, jurisdiction standards, and regulatory standards in par 038: “FIG. 4 illustrates another embodiment of the present invention. At 401, design automation data is stored on a mobile computing device. The user may load a wide variety of data specific for a particular type of project on the mobile device before visiting the remote site, for example. In one embodiment, metadata specifying project requirements may be uploaded to the software system. In a construction context, metadata specifying project requirements may include a list of requirements for a type of project (e.g., requirements of an authority having jurisdiction (AHJ) for a solar project as described in more detail below, or a list of common building stock in that area, or snow, wind, or seismic load data) with a Boolean value or a quantitative value associated with each requirement to specify whether the requirement applies to the particular project being worked on or to what degree. For example, the mobile device may determine that one or more projects are in a particular jurisdiction and apply one more applicable AHJ rules to all projects in the particular jurisdiction.” See also par 049: “In one embodiment, design requirements for a particular project are accessed and used to modify the custom template. Design requirements may be stored on a computer system, such as in a database 710, for example. Design requirements may include rules to determine if a particular block from the master template is to be removed or if a project specific block is to be added to the custom template. In one embodiment, attributes of a particular job are analyzed using such rules to determine particular blocks to be added to or deleted from the master template. Design requirements may pertain to information about a particular authority having jurisdiction (AHJ). For example, a particular city may require a particular size of paper for the design plans, setbacks, notes, or other particularities. Project specific blocks may be stored in database 710 or at a specified location on the computer system, for example.“ See also par 092: “The installation documentation may be generated in the form of one or more PDF documents that include a permit set (e.g., permit information provided to a building department having jurisdiction over the project location), single line drawings (e.g., electrical drawings provided to a utility having jurisdiction over the project location), and construction documents that may comprise a set of instructions for the installation crews.”
Per claim 8, Brier teaches a system for evaluating and developing a prospective site for a charging station for electric vehicles, comprising in par 034: “Described herein are techniques for performing mobile design automation. The apparatuses, methods, and techniques described below may be implemented as a computer program (software) executing on one or more mobile computing devices, such as a laptop computer, a tablet computer with a touch screen input, or handheld mobile computer, for example.” Then see par 052: “As further example energy projects, some embodiments of the present invention may be used in electric vehicle charging projects, energy storage projects, energy efficiency project, solar hot water projects, metering/monitoring projects, or building controls and automation projects to name just a few.” See also par 040: “In some embodiments, the software can step a person in the field (e.g., an auditor) through the design process (e.g., an audit) in the most efficient way possible depending on the context of what the user observes on site. The user enters data into the system about the design constraints obtained on site, and the data constrains the design process steps that the user can execute. For example, in one embodiment, the remote design process may be structured as a decision tree to step the user through only the steps or questions relevant to a particular project for a particular customer (e.g., as determined by responses to earlier questions and data loaded into the system for a particular job).”
Then, Brier teaches a user interface configured to receive site specific information, the site specific information comprising information that physically defines the prospective site and physical characteristics of the charging station in par 052: “FIG. 9 illustrates a process for using a mobile computing device to perform a solar power installation project. In a solar power installation project application, a field technician, for example, may load a mobile device with data for a particular installation project at a particular installation site and use the mobile device to execute software performing at least some of the features described above to obtain the information required to install a solar power system at the site. In particular, a technician may audit the job site and enter in a variety of data about physical attributes of a solar power installation at a particular installation site. The data may be used to tailor the solar power system to the physical attributes of a particular installation site and to generate installation documentation for designing, permitting and installing the solar power system, for example. Features and advantages of the present invention include using a mobile device loaded with data and specialized software to allow a technician to perform a job site audit to generate a complete set of installation documentation (e.g., construction documents) with engineering involvement reduced or entirely eliminated. While the following example illustrates an application in the context of a residential solar energy system project (or photovoltaic "PV" system), it is to be understood that other embodiments may be used in a wide range of applications. As further example energy projects, some embodiments of the present invention may be used in electric vehicle charging projects, energy storage projects, energy efficiency project, solar hot water projects, metering/monitoring projects, or building controls and automation projects to name just a few.” See also par 043: “At 511 in FIG. 5, data inputs from the user specific to the first process step may be received. For example, UI 603A may include data entry fields or data creation mechanisms. Alternatively, different icons 621-623 may invoke different sub-processes including data entry fields or invoking different specific data creation mechanisms associated with a particular process step specific icon (e.g., specific CAD functions). Further, at 512 in FIG. 5, one or more data processing algorithms for the first process step 610 may be executed at 512. Referring to FIG. 6, invoking UI 603A may invoke a particular algorithm for processing data, or invoking one of icons 621-623 may invoke different sub-process algorithms for processing data. For example, in one embodiment design area 602 may include a computer aided design (CAD) program and accessing process step 610 may activate limited features of the CAD program, and icons 621-623 may invoke different specific features of the CAD program for simplifying creation of a design according to a simplified step-by-step/function-by-function approach for manipulating data. As a particular example, accessing process step 1 icon 610 may cause the system to retrieve a basic schematic (e.g., engineering drawing) of a particular project. Each of icons 621-623 may invoke a particular feature of a CAD program for manipulating the schematic one feature at a time to allow a user to adjust the schematic and enter data available at the remote project site. By limiting features and data entry to parameters only available at the remote project site, for example, the system guides the user through the process without requiring (or in some cases allowing) the user to manipulate a broader range of parameters more thoroughly understood by an expert at the main office. The user acts to enter and verify data available at the remote project site without being required to perform a full and complete analysis traditionally performed by highly trained experts in the main office, for example.” See also par 049: “Design requirements may be stored on a computer system, such as in a database 710, for example. Design requirements may include rules to determine if a particular block from the master template is to be removed or if a project specific block is to be added to the custom template. In one embodiment, attributes of a particular job are analyzed using such rules to determine particular blocks to be added to or deleted from the master template. Design requirements may pertain to information about a particular authority having jurisdiction (AHJ). For example, a particular city may require a particular size of paper for the design plans, setbacks, notes, or other particularities. Project specific blocks may be stored in database 710 or at a specified location on the computer system, for example.”
Then, Brier teaches a database configured to store at least non site specific information and site specific information received from the user interface in par 049: “ ‘Design requirements may be stored on a computer i : system, such as in a database 710, for example’” See in particular (database 710; Fig. 7). See also par 067: “‘Referring again io FIG. 13, the data for a particular project may include information about the type of system sold to a particular customer... The system may pre-store 9 plurality of module types available for i selection by a user, When module selection button 1420 is selected, the prestored module types (2.g., module models and manufacturers) are displayed to a user and the user may select the module type that was sold to the particular customer.’)”
Then, Brier teaches wherein the non-site specific information defines at least one common feature of at least two charging station sites in par 038: “FIG. 4 illustrates another embodiment of the present invention. At 401, design automation data is stored on a mobile computing device. The user may load a wide variety of data specific for a particular type of project on the mobile device before visiting the remote site, for example. In one embodiment, metadata specifying project requirements may be uploaded to the software system. In a construction context, metadata specifying project requirements may include a list of requirements for a type of project (e.g., requirements of an authority having jurisdiction (AHJ) for a solar project as described in more detail below, or a list of common building stock in that area, or snow, wind, or seismic load data) with a Boolean value or a quantitative value associated with each requirement to specify whether the requirement applies to the particular project being worked on or to what degree.” See also par 052: “Features and advantages of the present invention include using a mobile device loaded with data and specialized software to allow a technician to perform a job site audit to generate a complete set of installation documentation (e.g., construction documents) with engineering involvement reduced or entirely eliminated. While the following example illustrates an application in the context of a residential solar energy system project (or photovoltaic "PV" system), it is to be understood that other embodiments may be used in a wide range of applications. As further example energy projects, some embodiments of the present invention may be used in electric vehicle charging projects, energy storage projects, energy efficiency project, solar hot water projects, metering/monitoring projects, or building controls and automation projects to name just a few.” See also par 059: “FIG. 11 illustrates a process to add obstructions according to one example embodiment. In this example, a user may audit the roof of a home and identify certain obstructions in the roof, such as a chimney, a skylight, ventilation pipe, antenna/dish, etc. . . . using interface 1300. In this example, when a user selects the add obstruction button 1221, an interface 1301 for adding obstructions is displayed. A user may first select an "insert origin" button 1310 to set an origin 1312 ("X1, Y1") in the design area. Positions of obstructions added to the design area may be specified relative to origin 1312. In this example, two origins 1312 and 1314 are added for two different structures at the site. A user may add obstructions for each structure by selecting the relevant origin and entering information about the obstruction. For example, a first obstruction 1324 may be identified as a chimney by selecting radio button 1350. Once the data for chimney 1324 is entered, a user may select the Insert button 1320 (for new obstructions) or the Update button 1321 to update data for an existing obstruction. The chimney is shown as obstruction "A" in the menu 1324.” Here two different structures are taught and something is added for each which taches the limitation.
Then, Brier teaches and a processor encoded with a set of engineering rules, each engineering rule configured to implement a predetermined design decision applicable to multiple charging station sites, in par 053: “For example, in one embodiment the user may load a schematic site file onto the mobile device, such as a Precigeo file, where solar and roof schematics are obtained through the analysis of aerial imagery, for example. The user may further load information pertaining to an authority having jurisdiction ("AHJ") as mentioned above. Typical AHJs include state, county, or city governments or utility companies, for example. AHJ files may include specific requirements for physically locating certain objects on a property or how equipment is to be installed or configured, for example. Appendices A and B illustrate two example metadata files loaded to the mobile device. Appendix A illustrates AHJ metadata for electrical and Appendix B illustrates AHJ metadata for mounting planes. As illustrated in Appendix A and B, data loaded from a main office computer may include AHJ data, project specific data, and financial data, for example. AHJ requirements applicable to a particular project are listed between "AHJAuditNotes_Key" followed by a value marked as TRUE or FALSE. If an AHJ requirement is followed by a value set to TRUE, then the particular AHJ requirement is applicable to the particular project. A value of FALSE indicates that the particular AHJ requirement is not applicable to the particular project. Other data imported into the mobile device is illustrated in Appendix A and B. Names of the example variables in the attached appendices are representative of each variables use within the system.” See also par 068: “In one embodiment, data for the project may include an AHJ filed used to limit the placement of the solar modules. For instance, the AHJ may be used to determine a fire setback, for example. The system may further determine invalid module placements based on physical and electrical rules limiting placement and connectivity. For example, an AHJ may prohibit putting panels over bathroom plumbing vents.” The AHJ rules teach complied sets of engineering rules. These rules are, as explained in the above paragraphs, particular to jurisdictions and therefore are not particular to sites (and are therefore applicable to many sites). Loading information teaches receiving by the processor.
Then, Brier teaches the processor further configured to access the database and generate at least one deliverable by implementing design decisions using at least the set of engineering rules, the non-site specific information, and the site specific information, wherein the deliverables comprise engineering designs for the selected site in pars 0101-0103 and Fig 24-25: “As another example, FIGS. 24-25 illustrate two mounting hardware block templates for mounting hardware for Spanish Tile with a 6 inch standoff and another template for mounting hardware for Spanish Tile with and 8 inch standoff. In this example, the system automatically selects blocks based on whether or not the auditor places solar panel modules over a vent on the roof, for example. These two templates may be used for all Spanish Tile roofs, for example. Bill of Material (BOM) blocks may be embedded in these templates, and their quantities may be updated by the program prior to the job being uploaded to computers (e.g., servers) at the main office.
Accordingly, the mobile system may include numerous CAD blocks for physical components (e.g., all available mounting hardware) and electrical components. The user may provide simple limited user interface actions to specify the solar design and the system may translate the limited user inputs into multiple CAD functions that result in a complete electrical model that represents the electrical properties of the system. A full plan set may be generated automatically by accessing and compiling numerous blocks based on the generated CAD functions, for example.
The Bill of Materials (BOM) may be contained within a CAD drawing. The metadata may be stored in CAD blocks. As mentioned above, a block is an entity within the CAD database, which may have a unique string identifier for its name. When the audit project is completed and uploaded back to the main office servers, the software may populate the BOM on the main office servers. Blocks are useful both for their storage of the BOM metadata, but also for their ability to be viewed easily by the end user in the output PDF, for example. BOM blocks may be embedded throughout the CAD files, and upon uploading the audit, the mobile design automation software may recursively search the CAD database, collects all the part numbers, and sends them to a database at the main office. For example, part numbers may be loaded into a supply chain management database, where the part numbers may be viewed and ordered by a user in a warehouse through the supply chain management software.” Non site specific is taught by templates that are used for all Spanish tile roofs. Site specific is taught by whether the auditor places solar panel modules over a vent in the roof, for example. Engineering rules is taught by CAD blocks for physical hardware. The full plan set being generated is generating the deliverables, as the plan set is the plans for constructing the specific PV element, see Fig 24, 25.
See also for delivering said deliverables: par 092: “The installation documentation may be generated in the form of one or more PDF documents that include a permit set (e.g., permit information provided to a building department having jurisdiction over the project location), single line drawings (e.g., electrical drawings provided to a utility having jurisdiction over the project location), and construction documents that may comprise a set of instructions for the installation crews.” PDF for the installation crews teaches sending deliverables to an end user. See where par 093 refers to the modified CAD drawings, and pars 093-0105 which further describe how the CAD template/drawings/designs/blocks are modified to produce the PDF documents.
Per claim 11, Brier teaches the limitations of claim 8, above. Brier further teaches the at least one deliverable includes: Material Take Off (MTO), a cable and fault calculation, a construction drawing, an overall layout drawing, a cost estimate, a 2D drawing, and a 3D model in par 038: “At 406, the data for the project, and generated project outputs, may be loaded into a backend system at the office. For example, in one embodiment data for a particular project may be loaded into multiple backend systems to create a physical manifestation of the design, order required materials from third parties, schedule personnel, tools, and other resources, and create entries in a finance and accounting system to account for the costs and potential revenues of the project, for example.” In par 0103: “The Bill of Materials (BOM) may be contained within a CAD drawing. The metadata may be stored in CAD blocks. As mentioned above, a block is an entity within the CAD database, which may have a unique string identifier for its name. When the audit project is completed and uploaded back to the main office servers, the software may populate the BOM on the main office servers. Blocks are useful both for their storage of the BOM metadata, but also for their ability to be viewed easily by the end user in the output PDF, for example. BOM blocks may be embedded throughout the CAD files, and upon uploading the audit, the mobile design automation software may recursively search the CAD database, collects all the part numbers, and sends them to a database at the main office. For example, part numbers may be loaded into a supply chain management database, where the part numbers may be viewed and ordered by a user in a warehouse through the supply chain management software.”
Per claim 12, Brier teaches the limitations of claim 8, above. Brier further teaches the engineering rules include at least one of: a rule defining a number of bays for a given plot area, a rule defining locations for individual chargers, assigning chargers to bays, and a rule defining available cable routes in par 049: “In one embodiment, design requirements for a particular project are accessed and used to modify the custom template.