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 .
Response to Amendment
The amendment filed 12/31/2025 has been entered. Claims 1-18 and 22-23 are presented for examination.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 7-8, 10-14, 17-18 and 22-23 are rejected under 35 U.S.C. 103 as being unpatentable over "Automated Generation of Modular PLC Control Software from P&ID Diagrams in Process Industry" (Koltun) in view of “TIA Portal STEP 7 Basic V10.5” (2009-Siemens), and further in view of IYUN, "Plant-Wide Diagnosis: Cause-and-Effect Analysis Using Process Connectivity and Directionality Information", Imperial College of Science, Technology and Medicine, London, October 2011.
Koltun and Siemens were cited in the previous office action.
With respect to claim 1, Koltun teaches a control system for an industrial plant, comprising (see FIG. 1, generating PLC control software from P&IDs, [page 4]; where the system is both the computer generating in FIG. 1 and the PLC executing the software):
one or more processors (prototype software written in c++, which is a high level computer programming language written to execute on a processor, [page 4 col 2 paragraph 5]; the boxes in FIG. 1 can be considered processes that are executing on a processor, [page 4]; an actual control system is deployed for “production process fabricating mass customized yoghurt” [page 5 col 1 paragraph 2]; where the generated code runs on a PLC, [see Title], which is a hardware device having a processor operatively connected to memory); and
a storage unit communicatively coupled to the one or more processors and storing processor-executable instructions thereon that, when executed by the one or more processors, cause the control system to (prototype software written in SQLite database engine, which is an application written to store data in computer memory or on a hard drive, [page 4 col 2 paragraph 5]; the cylinders in FIG. 1 are storage units that interact with the processes in boxes running on the processors, [page 4]; additionally, the generated code is run on a PLC, [see Title], which is a hardware device having a processor operatively connected to memory):
perform a process that inputs an engineering diagram for a unit of the industrial plant (see the arrow pointing down on the left in FIG. 1 of inputting a P&I diagram into the box labeled "engineering document processing", [page 4]), the engineering diagram including symbols representing assets of the industrial plant (the P&I diagram in FIG. 1, [page 4], has symbols representing assets of an industrial plant such as “production process fabricating mass customized yoghurt” [page 5 col 1 paragraph 2]; "in detailed engineering phases, piping and instrumentation diagrams (P&IDs according to DIN EN 62424) are used to design a process plant", [page 1 col 1 paragraph 2 lines 7-9]);
perform a process that extracts one or more assets from the engineering diagram using a trained machine learning model configured to recognize domain entities (box labeled "P&ID Object recognition" in FIG. 1, [page 4], further described in section IV. A. 2) P&ID object recognition, [page 3]; PM entries are matched with the vector-based model and synchronized with the trained database; the database is consequently queried about potential P&ID-object matches, [page 3 col 2 paragraph 2 lines 2-5]; note, the term "trained" refers to using a trained database which is a type of trained machine learning model, in this case configured to recognize ten object types/domain entities , [page 5 col 2 paragraph 2]) representing equipment, instruments, connectors, and lines (requirement 1 includes identifying piping and instrumentation objects, [page 1 col 2 paragraph 4 lines 1-2]; objects are symbols, text, connections, and PCEs according to the DIN EN ISO 10628 [8] and DIN EN 62424 [9], [page 2 col 1 paragraph 1 lines 6-8]; the connections are the lines, and the symbols are equipment, instruments, and connectors; for example looking at FIG. 2(a), the excerpt has four components labeled C1, C2, C3, and C4, where C1 is a symbol for a pump, C2 is a symbol for a motor, C3 is a symbol for a flow indicator control, and C4 is a connector connecting two lines, C1 and C2 are equipment, C3 is an instrument that requires measurement; and C4 is a connector), the lines relating the equipment, instruments, and connectors to one another (lines indicate connections within a P&ID, [page 3 col 2 paragraph 3 lines 1-3]);
perform a process that determines one or more relationships between the equipment, instruments, connectors, and lines using a trained machine learning model configured to identify functional connections based on semantic features of the engineering diagram (box labeled "Connection Analysis" in FIG. 1, [page 4], further described in section IV. A. 3) “connection analysis”, [page 3]; connections between the P&ID objects are identified, i.e. lines tangent to characteristic points on P&ID objects are searched for ... The resulting matrix, containing connected piping and instrumentation objects, can finally be exported into various standardized exchange formats such as XML, [page 3 col 2 paragraph 3 lines 10-16]; machine learning happens to remove all other lines, and remaining lines indicate connections, [page 3 col 2 paragraph 3 lines 1-2]; see FIGS. 2(b)-(c), analysis is determining tangency by comparing the characteristic points from 2(b) with the lines from 2(c), [page 5]; the P&ID objects that were previously identified are the semantic features);
perform a process that creates a flow graph from the equipment, instruments, connectors, and lines and the relationships between the equipment, instruments, connectors, and lines (the output of "Engineering Document Processing" in FIG. 1, [page 4], see FIG. 4, [page 6]; Figure 4 depicts the results obtained after processing the SVG-based P&ID. In the process, all of the trained objects were identified (indicated by green bounding boxes). Furthermore, all of the connections were detected – even those with branches (redrawn as magenta colored lines), [page 5 col 2 paragraph 2 lines 5-10]; in FIG. 4, box labeled M is a motor which is equipment; boxes labeled LIC or TIC are level indicator control and temperature indicator control, which are instruments; connectors are Y’s and lines are lines), the flow graph representing the assets and their relationships to other assets using nodes and edges, wherein the nodes in the flow graph represent the assets and the edges in the flow graph represent relationships of the assets with other assets (FIG. 4, where the overlaid green boxes are the nodes, and the overlaid pink lines are the edges); and
perform a process that creates a data table for the flow graph (see FIG. 1, box labeled "module recognition", [page 4]; the table is created by results returned from the process module library, [page 4 col 1 paragraph 2 lines 3-11], see specifically “match is thereby detected, then the analyzed connection and associated P&ID object indicates an interface between two modules” which is a particular application of the SQLite Database Engine, [page 4 col 2 paragraph 5 line 3]; query results of the "process module library" creates a data table of the flow graph), the data table including constituent graphs (recognize modules using the process module library, [page 4 col 1 paragraph 2 lines 1-11]; where recognizing modules in a library refers to querying using the SQLite Database Engine, [page 4 col 2 paragraph 5 line 3]) that make up the flow graph (see FIG. 5, the constituent graphs are called modules labeled 1-4, and the flow graph is called the SVG-based P&ID [page 6]) and further includes nodes (member P&ID objects, [page 4 col 1 paragraph 2 line 7]) and edges (synchronize connections, [page 4 col 1 paragraph 2 line 7]) that make up each constituent graph ( “If a match is thereby detected”, meaning all of the synchronized connections and member objects are found necessary to make up a module, [page 4 col 1 paragraph 2 lines 8-10]); and
perform a process that creates a human machine interface (HMI) based on the data table for the flow graphs and the nodes and the edges in the flow graphs (see arrows leading to box in FIG. 1 labeled "control software", [page 4]; The Control Software Library contains design patterns designed using the industrial PLC control software IDE called CODESYS, [page 5 col 1 paragraph 1 lines 2-4]; The PLC control software was generated based on these results and the predefined software patterns. The XML-based PLCopen CODESYS7 files were thereby successfully imported into the Portal8 and TIA industrial PLC control software IDEs, [page 5 col 2 paragraph 4 lines 5-9]).
Koltun does not teach wherein the HMI is configured to dynamically render control elements corresponding to the assets and their functional connections, and where the HMI enables real-time monitoring and control of the assets in the industrial plan based on the relationships thereof.
However, Siemens teaches wherein the HMI is configured to dynamically render control elements corresponding to the assets and their functional connections, and where the HMI enables real-time monitoring and control of the assets in the industrial plan based on the relationships thereof ([page 17] shows how to load the project created from Koltun, [pages 29-30] show how to configure a PLC; [pages 65-73] show a tutorial of setting a graphic “dynamic object”, which has an on/off switch for control and flashes a red LED when off and a green LED when on for monitoring).
It would have been obvious to one skilled in the art before the effective filing date to combine Koltun with Siemens because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Koltun discloses a system and method that teaches exporting the relationships into an HMI creator called Tia Portal. Siemens is the documentation for Tia Portal (Koltun [page 4 col 2 paragraph 3] and [page 5 col 2 paragraph 4]). A person having skill in the art would have a reasonable expectation of successfully The control software generated in FIG. 1 to Tia Portal to have the actual code monitoring and controlling the PLCs of the plant.
The combination of Koltun and Siemens does not teach HMI displays alarms corresponding to the assets and to dynamically display one or more assets that are potential root causes for an alarm.
However, IYUN teaches HMI displays alarms corresponding to the assets and to dynamically display one or more assets that are potential root causes for an alarm (fig. 66, pages 139-143).
It would have been obvious to one of an ordinary skill in the art before the effective filling date of the claimed invention to have incorporated the concept of having a HMI displays alarms corresponding to the assets and to dynamically display one or more assets that are potential root causes for an alarm as suggested in IYUN into the combination of Koltun and Siemens since all of these system are directed towards displaying plant assets in a HMI based on data. By incorporating the teaching of IYUN into the combination of Koltun and Siemens would provide the added advantage of allowing a user to gain insight about the alarms by viewing root-cause analysis (IYUN, fig. 66, pages 141-143).
With respect to claim 2, the combination of Koltun, Siemens and IYUN teaches all of the limitations of claim 1, as noted above. Koltun further teaches wherein the process that extracts one or more assets from the engineering diagram includes a geometry-based extraction process (extract relevant information from SVG-based P&ID objects, [page 3 col 1 paragraph 3 line 2]) and a machine learning-based classification process (To recognize P&ID objects, we designed a vector-based model and linked it to a trained database, [page 3 col 1 paragraph 6 lines 1-2], where “trained” refers to machine learning).
With respect to claim 3, the combination of Koltun, Siemens and IYUN teaches all of the limitations of claim 1, as noted above. Koltun further teaches wherein the processor-executable instructions further cause the control system to perform a process that extracts one or more control loops from the engineering diagram based on one or more of the equipment, instruments, connectors, and lines (part of module recognition, specifically is reference to ISA 88, which describes batch control through “units”, where a unit is a combination of one or more equipment modules and control modules [page 3 col 2 paragraph 5 line 1]-[page 4 col 1 paragraph 1 line 3], where a control loop may be open or closed (see Specification [0057] line 9); in FIG. 5, module 2 has control loop of a motor 9, which is equipment, FIC/flow indicator control labeled 85, which is an instrument, connectors symbolized as a Y, and lines which are the connections between the devices in the module, [page 6]).
With respect to claim 4, the combination of Koltun, Siemens and IYUN teaches all of the limitations of claim 1, as noted above. Koltun further teaches wherein the processor-executable instructions further cause the control system to perform a process that extracts a unit identifier from the engineering diagram, wherein the unit identifier uniquely identifies a particular unit from among multiple units in the industrial plant (The P&ID consists of four different ISA-88-compliant units: pumping station, filling station, heating station, and mixing unit. Figure 5 shows the results of module recognition, [page 5 col 2 paragraph 4 liens 1-3]; See the resulting FIG. 5, where the units have identifiers 1-4 in FIG. 5, [page 6]).
With respect to claim 7, the combination of Koltun, Siemens and IYUN teaches all of the limitations of claim 1, as noted above. Koltun further teaches wherein the process that determines one or more relationships between the equipment, instruments, connectors, and lines includes a process that generates a line-line graph, a process that generates an equipment-line graph, a process that generates a connector-line graph, and a process that generates an instrument-line graph (i.e. lines tangent to characteristic points on P&ID objects are searched for. The matrix is furthermore analyzed with respect to further multiple entries. If one is found, a branch is identified (see fig. 2c)., [page 3 col 2 paragraph 3 lines 11-16]; note, the resulting matrix is a set of cells that can be defined as x1...xn,y1...yn as shown in Fig. 2(c), [page 5], so any cell that contains two lines is a line-line graph, such as (x5,y8), any cell that contains a line and a component that may be defined as equipment is an equipment-line graph such as (x3,y5), any cell that contains a line and a component that may be defined as an instrument is an instrument-line graph such as (x5,y3); any cell that contains a line and a component that may be defined as an connector is a connector-line graph, where FIG. 2 does not contain a connector, but FIG. 5 shows connectors as valves that separate the units from one another, [page 6], and valve is one of the object types of P&ID objects that has lines tangent to be searched for, [page5 col 2 paragraph 2 lines 1-2]).
With respect to claim 8, the combination of Koltun, Siemens and IYUN teaches all of the limitations of claim 7, as noted above. Koltun further teaches wherein the processor- executable instructions further cause the control system to create the flow graph for the engineering diagram by performing a process that merges the line-line graph, the equipment-line graph, the connector-line graph, and the instrument-line graph with one another (The resulting matrix, containing connected piping and instrumentation objects, can finally be exported into various standardized exchange formats such as XML, [page 3 col 2 paragraph 3 lines 11-16], where the “resulting matrix” represents each cell of subgraphs merged into a single data structure).
With respect to claim 10, the combination of Koltun, Siemens and IYUN teaches all of the limitations of claim 1, as noted above. Koltun further teaches processor-executable instructions further cause the control system to perform a process that displays the equipment, instruments, connectors and lines and the relationships between the equipment, instruments, connectors and lines in an asset hierarchy (FIG. 4, [page 6], shows all of the recognized objects (where M is equipment, FIC is instrument, ‘Y’ is connector, and lines are lines), where these are exported in XML, [page 3 col 2 paragraph 3 lines 15-16], which is a tree-based format; these components are used to create a tree-based model according to the hierarchy defined by ISA-88 standard, see [page 3 col 2 paragraph 5] for a description of the hierarchy, and [page 4 col 1 paragraph 3] for description of the output; finally, the XML based model creates the framework for generating the control software output shown in FIG. 1 using Model-To-Text, [page 4]).
With respect to claims 11, 12-14 and 17-18, they are method claims that correspond to system claims 1-4 and 7-8. Therefore, they are rejected for the same reason as system claims 1-4 and 7-8 above.
With respect to claim 22, the combination of Koltun, Siemens and IYUN teaches all of the limitations of claim 1, as noted above. IYUN further teaches wherein the HMI is further configured to display the one or more assets of the asset hierarchy that are potential root causes for the alarm in response to receiving a user selection of an asset corresponding to one of the alarms (figs. 63-65, pages 139-140).
With respect to claim 23, the combination of Koltun, Siemens and IYUN teaches all of the limitations of claim 1, as noted above. IYUN further teaches wherein the asset hierarchy is associated with a plurality of levels of equipment, and wherein the one or more assets that are potential root causes for the alarm comprise one or more assets that are at the lowest level of the plurality of levels associated with at least one asset that has an alarm, and wherein the one or more assets are connected to the selected asset (figs. 63-65, pages 139-140).
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over "Automated Generation of Modular PLC Control Software from P&ID Diagrams in Process Industry" (Koltun) in view of in view of “TIA Portal STEP 7 Basic V10.5” (2009-Siemens) in view of IYUN, "Plant-Wide Diagnosis: Cause-and-Effect Analysis Using Process Connectivity and Directionality Information", Imperial College of Science, Technology and Medicine, London, October 2011), as applied in claims 1 and 11 above, and further view of “Information Extraction from Scanned Engineering Drawings” (2009-Ondrejcek).
Koltun, Siemens and Ondricek were cited in the previous office action.
With respect to claim 5, the combination of Koltun, Siemens and IYUN teaches all of the limitations of claim 1, as noted above. Koltun further teaches wherein the processor-executable instructions further cause the control system to perform a process that extracts ... for the industrial plant (engineering document processing, [page 3 col 1 paragraph 3 heading]; with an initial step/preprocessing of distinguishing ... text, [page 3 col 1 paragraph 4 lines 7-8]; applied to a P&ID document, which is for an industrial plant, where an excerpt is shown in FIG. 2(a), [page 5]).
The combination of Koltun, Siemens and IYUN do not teach a drawing number and a revision number from the engineering diagram, the drawing number uniquely identifying the engineering diagram from among multiple engineering diagrams ...and the revision number indicating a revision of the engineering diagram which is incremented whenever there are changes in the engineering diagram.
However, Ondrejcek teaches wherein the processor-executable instructions further cause the control system to perform a process that extracts a drawing number and a revision number from the engineering diagram (1. Detect the information (title) block in an image and crop the image area; 2. Identify the type of information block template and crop areas for each information sub-field; 3. Apply OCR software to each sub-field and associate it with text strings resulting from OCR, [page 5 paragraph 3 bullets 1-3]; for applying process on page 5, See Appendix A for layouts of blocks of interest, [page 6 paragraph 2 line 2]; sufficient information to identify the type of drawing, vendor name and information about the versions, authors and other creators. A title block is divided into several areas (sub-fields) including the drawing title and the drawing number, [page 13 paragraph 1 lines 7-10]; drawing made by supporting engineering application according to ISO 7200, [page 13 paragraph 2]), the drawing number uniquely identifying the engineering diagram from among multiple engineering diagrams ... and the revision number indicating a revision of the engineering diagram which is incremented whenever there are changes in the engineering diagram (These are definitions of drawing number and revision index which are provided by the ISO 7200 standard; the ISO 7200 standard is included as NPL in the pertinent art below for definitional purposes; to understand the standard, see the example FIG. A1 of Ondrejcek, a computer generated title block according to ISO 7200 standard, where {id} means the software inserts a drawing ID in that place for “identification” of the drawing, and {rev} means the software inserts a revision ID in that place according to the ISO 7200 standard
PNG
media_image1.png
278
698
media_image1.png
Greyscale
[page 13]; note in all computer software, all characters are stored as binary numbers, so even letter characters in an ID would be considered “numbers” to a person having skill in the art; in FIG. A6, the revision block is incremented sequentially using characters “-“, “A”, “B”, and “C”, respectively, [page 16]).
It would have been obvious to one skilled in the art before the effective filing date to combine the combination of Koltun, Siemens and IYUN with Ondrejcek because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. The combination of Koltun, Siemens and IYUN discloses a system that teaches all of the claimed features except for extracting the title block. Ondrejcek teaches a process for extracting the title block, (see section 1.2, Ondrejcek [page 5]) and a how an ISO rule may be used to generate a standard title block that can later be extracted by that process (see FIG. A1, Ondrejcek [page 13]). Koltun provides a motivation for combining processes that rely on multiple standard because “information is not always adequately exchanged”, (see Koltun [page 1 col 1 paragraph 2 lines 1-12]). Thus, A person having skill in the art would have a reasonable expectation of better exchanging information between different engineers using multiple documents in the system and method of Koltun, Siemens and IYUN by modifying the combination of Koltun, Siemens and IYUN with the title block extraction of Ondrejcek. Therefore, it would have been obvious to combine Koltun in view of Siemens with Ondrejcek to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 15, it is a method claim that corresponds to system claim 5. Therefore it is rejected for the same reason as system claim 5 above.
Claims 6 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over "Automated Generation of Modular PLC Control Software from P&ID Diagrams in Process Industry" (Koltun) in view of in view of “TIA Portal STEP 7 Basic V10.5” (2009-Siemensin view of IYUN, "Plant-Wide Diagnosis: Cause-and-Effect Analysis Using Process Connectivity and Directionality Information", Imperial College of Science, Technology and Medicine, London, October 2011), as applied in claims 4 and 14 above, and further view of “Control Loop Foundation-Batch and Continuous Processes” (2011-Blevins).
Koltun, Siemens and Blevins were cited in the previous office action.
With respect to claim 6, the combination of Koltun, Siemens and IYUN teaches all of the limitations of claim 4, as noted above. Koltun further teaches wherein the processor-executable instructions further cause the control system to perform a process that assigns a unique identifier to each equipment, instrument, connector, and line of the engineering diagram (we first analyzed each graphical object’s ID, [page 3 col 1 paragraph 4 lines 13-14], and preserve information in PM, [page 3 col 1 paragraph 4 lines 17-18]).
The combination of Koltun, Siemens and IYUN do not teach using the unit identifier from the engineering diagram.
However, 2011-Blevins teaches using the unit identifier from the engineering diagram (ISA 5.1: The letters that make up the first few characters of a typical tag number (the “leading letters”) are used to identify the function performed by the field device or by the control system. Following these leading letters is a number. The number that appears on the tag is known as the loop number. The loop number is used to uniquely identify one or more field devices that are used to perform a specific function. This combination of function letter and loop number allows a field device in a process area to be precisely identified, see section 7.5 tagging conventions, [pages 99-105], but specifically, [page 103 paragraph 4]).
It would have been obvious to one skilled in the art before the effective filing date to combine the combination of Koltun, Siemens and IYUN with Blevins because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. The combination of Koltun, Siemens and IYUN discloses a system and method that teaches all of the claimed features except for tagging conventions that are used prior to the IDs being extracted. Blevins teaches that the ISA-5.1 tagging convention, using a loop number that uniquely identifies the field devices that are used to perform a specific function (Blevins [page 103 paragraph 4]). Blevins gives example P&ID loop diagrams that show how this convention is carried out, (see Blevins [pages 100-102]). Koltun in view of Siemens provides a motivation for combining processes that rely on multiple standards because “information is not always adequately exchanged”, (see Koltun [page 1 col 1 paragraph 2 lines 1-12]). Thus, a person having skill in the art would have a reasonable expectation of better exchanging information between different engineers using multiple documents in the system and method of Koltun in view of Siemens by modifying the combination of Koltun, Siemens and IYUN with the ISA-5.1 standard of Blevins. Therefore, it would have been obvious to combine Koltun in view of Siemens with Blevins to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 16, it is a method claim that corresponds to system claim 6. Therefore it is rejected for the same reason as system claim 6 above.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over "Automated Generation of Modular PLC Control Software from P&ID Diagrams in Process Industry" (Koltun) in view of in view of “TIA Portal STEP 7 Basic V10.5” (2009-Siemens) ) in view of in view of “TIA Portal STEP 7 Basic V10.5” (2009-Siemensin view of IYUN, "Plant-Wide Diagnosis: Cause-and-Effect Analysis Using Process Connectivity and Directionality Information", Imperial College of Science, Technology and Medicine, London, October 2011), as applied in claim 7 above, and further view of “Integration, Navigation and Exploration of Plant Topology Networks Using the Property-Graph Model” (2014-Romero).
Koltun, Siemens and Romero were cited in the previous office action.
With respect to claim 9, the combination of Koltun, Siemens and IYUN teaches all of the limitations of claim 7, as noted above. The combination of Koltun, Siemens and IYUN do not teach wherein the processor-executable instructions further cause the control system to perform a process that merges flow graphs from multiple engineering diagrams for the industrial plant to create a flow graph for the industrial plant.
However, Romero teaches wherein the processor-executable instructions further cause the control system to perform a process that merges flow graphs from multiple engineering diagrams for the industrial plant to create a flow graph for the industrial plant (Graph theory and its extensions are mature and well understood and suitable for direct application to the problems described in this paper. Figure 2 represents the overall methodology behind the Topoviz™ tool. The dots inside the bubbles represent process equipment and variables contained inside a data source (process schematic, electrical drawing, first-principles models, and cause and effect logic, among others), and the lines indicate the connections between them. An integrated graph would mean that all links can be stored and classified inside the same model so that the interactions between process-mechanical-electrical interfaces can be simply visualized, [page 745 col 1 paragraph 1 lines 5-16]; note, the authors use the term “process schematic” for P&ID sheet, where Fig. 2 shows four data source inputs, and one integrated graph output, [page 745]; an example of one input is a smart P&ID shown in FIG. 5, and the resulting plant topology network corresponding to the P&ID is shown in FIG. 4, [page 746]).
It would have been obvious to one skilled in the art before the effective filing date to combine the combination of Koltun, Siemens and IYUN with Romero because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. The combination of Koltun, Siemens and IYUN discloses a system and method that teaches all of the claimed features except for integrating multiple diagrams. Romero teaches understanding the way different units are connected and the causality between them has various applications, (Romero [page 743 col 1 paragraph 3 lines 1-2]), and goes on to give one of the applications as control structure design (Romero [page 743 col 1 paragraph 3 line 11]). A person having skill in the art would have a reasonable expectation of successfully mining the data knowledge about plant topology using The combination of Koltun, Siemens and IYUN and then integrating the resulting graphs using the teachings of Romero. Therefore, it would have been obvious to combine Koltun in view of Siemens with Romero to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-18 and 22-23 have been considered but are moot because the new ground of rejection (see rejection above).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sayyarrodsari et al (US Publication No. 2021/0397171 A1) disclose a human interface (HMI) development platform simplifies generation of an industrial visualization application by generating at least a portion of the visualization application based on analysis of digital engineering drawings of an automation system to be monitored and controlled.
Grewal (US Publication No. 2015/0242286 A1) discloses a system and process that facilitates employing a GUI to monitor and manage assets within an industrial environment.
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 replying to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JENNIFER N WELCH whose telephone number is (571)272-7212. The examiner can normally be reached M-T 5:30AM - 4:00PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, David Wiley, can be reached at (571) 272-4150. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
JENNIFER N. WELCH
Supervisory Patent Examiner
Art Unit 2143
/JENNIFER N WELCH/Supervisory Patent Examiner, Art Unit 2143
Prosecution Insights