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 .
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 (i.e., changing from AIA to pre-AIA ) 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.
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 8/19/2025 has been entered.
Response to Arguments
The amendment filed 3/13/2025 has been entered. Claims 1-20 remain pending in the application. Regarding the 35 U.S.C. 101 rejection, Applicant argues:
Applicant has further amended the claims to recite creating a human machine interface (HMI) based on the data table for the flow graphs and the nodes and the edges in the flow graphs, wherein the HMI is configured to dynamically render control elements corresponding to the assets and their functional connections, and wherein the HMI enables real-time monitoring and control of the assets in the industrial plant based on the relationships thereof. Applicant submits this limitation does not recite a judicial exception because an HMI is an actual, real- world monitoring and control tool with control screens that cannot be practically performed in the human mind.
(Response filed 8/19/2025 [page 8 paragraph 3 lines 1-8]).
Examiner agrees. The additional element integrates the abstract idea into a practical application under step 2A prong two because creating an HMI that enables real-time monitoring and control of the assets in the industrial plant based on the relationships thereof cannot be performed in the human mind, and the limitation is not an “apply it” limitation because the result is an “actual, real- world monitoring and control tool”, as argued by Applicant.
Regarding the prior art rejections, Applicant argues:
In the final Office Action, the Office appears to allege that Fig. 4 of Koltun discloses the claimed flow graph insofar as the circles and boxes in the figure depict equipment and instruments and the Y's and lines in the figure depict connectors and lines. Office Action, p. 28. However, as the label for Fig. 4 of Koltun explicitly states, what is depicted in that figure are the results of processing on an SVG-based P&ID, not a flow graph. A person skilled in the art looking at the Fig. 4 and reading the figure label would not consider the figure to be a flow graph, and certainly not a flow graph containing nodes and edges as recited in the claims.
(Response filed 8/19/2025 [page 11 paragraph 5]-[page 12 paragraph 1 line 3]).
Examiner disagrees. Applicant’s specification permissively defines a flow graph with examples:
FIG. 16A illustrates an exemplary Pl&D flow graph 1602 resulting from a merger of the various line connectivity graphs generated for a given Pl&D by the ML-based asset relationship building process 508. This Pl&D flow graph 1602, unlike its constituent graphs, contains all the connectors, devices or instruments, and equipment in the Pl&D along with the connections there between. The Pl&D flow graph 1602 thus captures the relationship between all the assets that were extracted from the given Pl&D.
(Specification [0120]).
PNG
media_image1.png
390
630
media_image1.png
Greyscale
FIG. 4 in Koltun overlays the flow graph on top of the P&ID diagram: “Fig. 4. Results of processing on the sample SVG-based P&ID (connections are redrawn, whereas matched P&ID objects framed with green bounding boxes)”, (Koltun [page 6]).
PNG
media_image2.png
490
802
media_image2.png
Greyscale
The green bounding boxes are the nodes, and the pink connections are the edges. The term flow in “flow graph” refers to the subject matter of what is being modeled by the graph:
P&IDs are in widespread use during the detailed engineering phases of process-industry plants. They contain substantial information, such as process flows and the associated instrumentation and control devices. The meaning of these devices is indicated by so-called PCEs (Process Control Engineering), which capture information about measuring, positioning, and processing physical variables such as pressure or flow rate within a pipeline.
(see Koltun [page 1 col 2 paragraph 5]).
Applicant further argues:
However, the SQLite database of Koltun does not read on the data table as recited in the claims. To arrive at the recited data table from the SQLite database of Koltun, the Office again would have had to improperly broadly generalize the disclosure of Koltun beyond the four corners of the reference.
(Response filed 8/19/2025 [page 12 paragraph 2 lines 5-8]).
Examiner disagrees. With both the flow graph and the data table, Applicant may be confusing the visualization with the logical concept. A data table often refers to collection of tuples stored and accessed using a relational model. A relational database management system such as the SQLite3 database engine stores and accesses data using a relational model. Creating a data table is referring to this process. Examiner will provide the following definitions from IEEE for background:
PNG
media_image3.png
444
394
media_image3.png
Greyscale
([page 951]).
PNG
media_image4.png
616
392
media_image4.png
Greyscale
([page 486]).
This is common, definitional knowledge known in the art. To be clear, a data table is a logical model that allows the user to not need to understand the inner workings of the database itself. If data is being stored and access using a SQL engine, then it necessarily is storing and accessing the data in a logical table.
Applicant may not know how one matches a query against database. Here, is an example:
PNG
media_image5.png
712
774
media_image5.png
Greyscale
(2015-Feiler [page 27]). The top shows how one can use a GUI to query the data using the where clause to return a data table in GUI format, and the bottom shows how one can use a command line to get the same information on the terminal in table format “2|lief|Iceland”. In a programming language such as C++, the query would be embedded in the code using variables and Boolean logic for the where clause to match the necessary data.
As applied to the claim, the limitation is “perform a process that creates a data table... including constituent graphs...”. Koltun teaches “the module-recognition process involves the
need to synchronize connections and member P&ID objects with the process module library in accord with the ISA-88 standard’s module-relevant specifications. If a match is thereby detected, then the analyzed connection and associated P&ID object indicates an interface between two modules”, [page 4 col 1 paragraph 2 lines 6-11]. FIG. 1, shows that the “match” is referring to querying a database:
PNG
media_image6.png
140
124
media_image6.png
Greyscale
, (FIG. 1 [page 4]),
which Koltun discloses is an SQLite database engine, [page 4 col 2 paragraph 5 line 4]. Koltun visualizes the results that were returned in table format, showing the four modules/sub-graphs that are returned by the database engine.
PNG
media_image7.png
508
726
media_image7.png
Greyscale
(FIG. 5 of Koltun [page 6]).
Applicant’s additional arguments are directed to amendments. These amendments had not yet been considered, and therefore the arguments are moot. Updated rejections are provided below. Note, Examiner provided the Siemens documentation as part of the advisory action on 7/30/2025.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-4, 7-8, 10-14, 17-18 and 20 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 “TIA Portal STEP 7 Basic V10.5” (2009-Siemens)
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]), 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. Therefore, it would have been obvious to combine Koltun with Siemens to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 2, Koltun in view of Siemens 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, Koltun in view of Siemens 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, Koltun in view of Siemens 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, Koltun in view of Siemens 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, Koltun in view of Siemens 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, Koltun in view of Siemens 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 claim 11, Koltun teaches A method of controlling an industrial plant, comprising (see FIG. 1, generating PLC control software from P&IDs, [page 4]).
Regarding the rest of claim 11, incorporating the rejection of claim 1, claim 11 is rejected for substantially similar rational.
With respect to claim 12, incorporating the rejections of claim 2 and claim 11, claim 12 is rejected as discussed above for substantially similar rationale.
With respect to claim 13, incorporating the rejections of claim 3 and claim 11, claim 13 is rejected as discussed above for substantially similar rationale.
With respect to claim 14, incorporating the rejections of claim 4 and claim 11, claim 14 is rejected as discussed above for substantially similar rationale.
With respect to claim 17, incorporating the rejections of claim 7 and claim 11, claim 17 is rejected as discussed above for substantially similar rationale.
With respect to claim 18, incorporating the rejections of claim 8 and claim 17, claim 18 is rejected as discussed above for substantially similar rationale.
With respect to claim 20, incorporating the rejections of claim 10 and claim 11, claim 20 is rejected as discussed above for substantially similar rationale.
Claim(s) 5 and 15 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-Siemens) in still further view of “Information Extraction from Scanned Engineering Drawings” (2009-Ondrejcek)
With respect to claim 5, Koltun in view of Siemens 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]).
Koltun and Siemens 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_image8.png
278
698
media_image8.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 Koltun in view of Siemens 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. Koltun in view of Siemens 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 in view of Siemens by modifying Koltun in view of Siemens 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, incorporating the rejections of claim 5 and claim 11, claim 15 is rejected as discussed above for substantially similar rationale.
Claim(s) 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-Siemens) in still further view of “Control Loop Foundation-Batch and Continuous Processes” (2011-Blevins)
With respect to claim 6, Koltun in view of Siemens 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 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]).
Koltun and Siemens 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 Koltun in view of Siemens 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. Koltun in view of Siemens 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 Koltun in view of Siemens 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, incorporating the rejections of claim 4 and claim 14, claim 16 is rejected as discussed above for substantially similar rationale.
Claim(s) 9 and 19 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-Siemens) is still further view of “Integration, Navigation and Exploration of Plant Topology Networks Using the Property-Graph Model” (2014-Romero)
With respect to claim 9, Koltun in view of Siemens teaches all of the limitations of claim 1, as noted above. Koltun and Siemens 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 Koltun in view of Siemens 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. Koltun in view of Siemens 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 Koltun in view of Siemens 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.
With respect to claim 19, incorporating the rejections of claim 9 and claim 17, claim 19 is rejected as discussed above for substantially similar rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 8,065,131 B2 (McDonald) – FIG. 2.
US 2009/0282067 (Bendigeri) - A second feature described herein relates to generating process visualization (human-machine interface) displays in a destination application format (e.g., INVENSYS SYSTEMS, INC. FOXVIEW) from an intermediate descriptive (e.g., XML) format. The intermediate version is, in turn, derived from, for example, generic process graphics objects (e.g., SMART PLANT Piping and Instrumentation Diagram drawings—SP P&ID drawings). The conversions from Source to target representations of control system graphics are driven by sets of rules applied by a graphics generator to render a description in either the intermediate (XML) or target (FOXVIEW) form, [0021].
US 2016/0140265 A1 (Hoernicke) - A method for generating model data of a plant having at least one sub-part involves: providing at least one respective diagram of an HMI interface for a respective sub-part, which contains topology information thereof; transferring the respective diagram, if necessary, into a computer readable form; importing the respective transferred diagram into a data storage of a computer and preferably automatically extracting model data of the respective sub-part therefrom, wherein the model data describe at least in part the topology of the respective sub-part; and providing the model data to an interface of the computer, wherein extracting model data from a diagram involves: detection of plant objects; and detection of plant object connections, [abstract].
Breitfelder, Kim, and Don Messina. "IEEE 100: the authoritative dictionary of IEEE standards terms." Standards Information Network IEEE Press. v879 (2000): [pages 486 and 951].
Feiler, Jesse. Introducing SQLite for mobile developers. Apress, 2015. ISBN-13 978-1-4842-1765-8, [page 27].
Arroyo, Esteban, Xuan Luu Hoang, and Alexander Fay. "Automatic detection and recognition of structural and connectivity objects in SVG-coded engineering documents." In 2015 IEEE 20th Conference on Emerging Technologies & Factory Automation (ETFA), pp. 1-8. IEEE, 2015.
Esquivel, Esteban Arroyo. "Capturing and Exploiting Plant Topology and Process Information as a Basis to Support Engineering and Operational Activities in Process Plants." PhD diss., Helmut-Schmidt-Universität, Bibliothek, 2017.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL MILLER whose telephone number is (408) 918-7548. The examiner can normally be reached on Monday-Friday from 11am to 5pm (PT).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emerson Puente, can be reached at telephone number (571) 272-3652. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/D.M./Examiner, Art Unit 2187
/EMERSON C PUENTE/ Supervisory Patent Examiner, Art Unit 2187
Prosecution Insights