DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-11 have been presented for examination based on the response filed on 12/30/2025.
Claim 10 is amended to address a typographical error in hierarchy and objection pertaining to is withdrawn.
The rejection below is maintained and the arguments responded to address the remarks.
Claim(s) 1-6, and 9-11 are rejected under 35 U.S.C. 103 as being unpatentable over EP 3121668 A1 by GUPTA, ROHIT KUMAR, in view of US 20160182309 A1 by Maturana; Francisco P. et al.
Claim(s) 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over EP 3121668 A1 by GUPTA, ROHIT KUMAR, in view of US 20160182309 A1 by Maturana; Francisco P. et al., further in view of US 6226780 B1 by Bahra; Avtar Singh et al.
This action is made Final.
---- This page is left blank after this line ----
Response to Arguments
(Argument 1) Applicant has argued in Remarks Pg.8-9:
PNG
media_image1.png
466
566
media_image1.png
Greyscale
(Response 1) The claim 1 limitation as argued is:
(Claim 1): …
generating an engineering diagram analytics model for the first engineering diagram based on the identified deviation in the one or more physical components, the physical connections and the parameter values in the first engineering diagram;
modifying the first engineering diagram based on the generated engineering diagram analytics model;
The support in the specification is from at least ¶[0057] states:
[0057] Also, in generating the engineering diagram analytics model for the first engineering diagram based on the identified deviation in the one or more physical components 108A-N, the physical connections and the parameter values in the first engineering diagram, the automation module 112 causes the processor(s) 202 to determine the parameter values associated with the deviation in the one or more physical components 108A-N and the physical connections. Further, the automation module 112 causes the processor(s) 202 to classify the parameter values associated with the deviation in the one or more physical components 108A-N and the physical connections into one or more engineering category. Each of the one or more engineering category comprises a set of defined actions to be performed. For example, the one or more engineering category comprises function block level, component level, program statement level, program logic level, domain level, syntax level, semantics level, domain or factory automation object level, object cluster level and the like. The set of defined actions comprises moving a program statements across function blocks, translating program statements from one programming language to another, inheriting program statements from one function block to another, redo or undo a program statement based on user inputs, parse program statements, compile program statements, and the like.
PNG
media_image2.png
798
496
media_image2.png
Greyscale
The specification does not disclose what is in the engineering diagram analytics model only what is it based on. Neither the claim language nor the specification shows other than a black box made by deviation information. The argument that Gupta’s comparator module 105 is not used engineering diagram analytics model because is not supported by disclosure and is mere allegation. Further argument that Gupta’s comparator module 105 does not modify an engineering diagram claimed and therefore is not engineering diagram analytics model is not supported by mapping. Gupta teaches in [0024] showing the comparison between the engineering process model and proposed process engineering variants:
The comparison leads to user selecting one of the variants to complete the design as shown in [0028] (This aspect was understood and updated in rejection):
PNG
media_image3.png
332
496
media_image3.png
Greyscale
The use of proposed variant to complete the design based on comparison is modification of the engineering model. Applicant has not claimed how the modification is made or what is modified, let alone what engineering diagram analytics model entails such that modifications can be made. This is mere allegation of patentability without claiming or showing distinction. Simply alleging the mapped comparator 105 is not engineering diagram analytics model is not sufficient. Examiner contends that their functions are the same (which lead to selection such that proposed variant is used modify/add to the current model), as shown in mapping Gupta [0027]-[0028] above.
(Argument 2) Applicant has argued in Remarks Pg.9-10:
PNG
media_image4.png
461
604
media_image4.png
Greyscale
(Response 2) The functionality of the analytics models is to modify the model based on the deviation(s). Gupta discloses similar implementation, where the comparator module 105 computes the deviations ([0024]-[0026]) and updates the model ([0027]-[0028]) based on the deviations/comparisons. Without claiming how the analytics model performs the modification and what the analytics model is, applicant’s arguments are not persuasive.
(Argument 3) Applicant has argued in Remarks Pg.10-11:
PNG
media_image5.png
362
594
media_image5.png
Greyscale
(Response 3) In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Maturana is not used to map the argued limitations. Please see Gupta’s mapping in the rejection and the Response 1-2 above. No new argument is made for the dependent claim and examiner respectfully maintains the rejection. Applicant’s are welcome to request an interview. It would be beneficial to show/claim what is the engineering diagram analytics model and how it is used to modify the model (rather than generic recitation of modification), such that it would read away from Gupta’s teachings.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-6, and 9-11 are rejected under 35 U.S.C. 103 as being unpatentable over EP 3121668 A1 by GUPTA, ROHIT KUMAR, in view of US 20160182309 A1 by Maturana; Francisco P. et al.
Regarding Claim 1
Gupta teaches (Claim 1) A method for generating engineering diagrams in an engineering system (Gupta: [0007]-[0009]) , comprising:
receiving, by a processor, specification of one or more physical components, wherein the specification of the one or more physical components correspond to an upgraded portion of a technical installation (Gupta: [0022]-[0025], Fig.1-2, here the plurality of proposed engineering variants represents the upgraded portion of technical system; [0013] discusses the proposed engineering variants are upgrades/modification made comprise, for example, changes made to the engineering based on the errors encountered during implementation of the engineering, latest technological advances in the field of the engineering, etc. ) ; obtaining, by the processor, a first engineering diagram representing a portion of the technical installation (Gupta: [0044], [0021], [0024]-[0026], Fig.2 & 4, here the engineered process model is the engineering diagram which comprises automation function with logical blocks including connections) , wherein the first engineering diagram comprises a representation of the one or more physical components in the portion of the technical installation (Gupta: [0021], [0024]-[0026], Fig.2 & 4D-F as engineering blocks of electronic components) , physical connections between the one or more physical components (Gupta: [0021], [0024]-[0026], Fig.2 & 4D-F as engineering blocks of electronic components with physical connections; [0044]-[0045]) , and a plurality of parameter values associated with the one or more physical components and the physical connections (Gupta: [0024] discussing the parameters as configuration setting/ settings of inputs) ;
identifying a deviation in the one or more physical components (Gupta: [0024]-[0027]) , the physical connections and the parameter values in the first engineering diagram based on the specification of the one or more physical components (Gupta: [0024]-[0027]) ;
generating an engineering diagram analytics model for the first engineering diagram based on the identified deviation in the one or more physical components, the physical connections and the parameter values in the first engineering diagram (Gupta: [0024], [0027] here the analystics model is mapped to the comparator module 105 which compares the engineered process model with engineering variant, to determine the deviation (see [0044]-[0045]) identifying the missing components and connection) ;
modifying the first engineering diagram based on the generated engineering diagram analytics model (Gupta: Fig.4D-F, [0024]-[0028] [0044]-[0046]);
generating a second engineering diagram representing the upgraded portion of the technical installation based on the modified engineering diagram analytics model, wherein the upgraded portion of the technical installation comprises a change in the one or more physical components, the physical connections and the parameter values in the first engineering diagram (Gupta: [0034][0039][0042]-[0046] and Figs. 4D-4F) ;
outputting the second engineering diagram representing the upgraded portion of the technical installation on a graphical user interface (Gupta: [0034][0039][0042]-[0046] and Figs. 4D-4F – graphical comparison between the engineered process model with engineering variant).
Gupta does not explicitly teach generating a simulation instance for the second engineering diagram representing the upgraded portion of the technical installation; simulating behavior of the upgraded portion of the technical installation in a simulation environment by executing the second engineering diagram on the generated simulation instance; validating the behavior of the upgraded portion of the technical installation based on results of simulation; and deploying the second engineering diagram in real-time into the upgraded portion of the technical installation based on the validation.
Maturana teaches generating a simulation instance for the second engineering diagram representing the upgraded portion of the technical installation (Maturana: [0029] "... The controller output data 106 is provided to the appropriate input points of the process simulation 104, which updates the simulated output data 108 accordingly. This simulation technique can be used to test and debug control programs without putting field equipment and machinery at risk, to simulate modifications to plant or machine operations and estimation how such modifications affect certain performance or financial metrics, or to perform other analytics....", [0071] "... The dashboards 824 can also display configurations screens that allow the user to view and modify the control program 804 executing on virtualized controller 810. ..."[0077] ) ; simulating behavior of the upgraded portion of the technical installation in a simulation environment by executing the second engineering diagram on the generated simulation instance (Maturana: [0029] as above; [0071], ) ; validating the behavior of the upgraded portion of the technical installation based on results of simulation (Maturana: [0029] "... [0029] Many system designers use simulations of a plant or industrial system to validate an industrial control program prior to deployment, to predict the effects of a change to the industrial process or control program..."); [0030], [0031], [0042], [0084]) ; and deploying the second engineering diagram in real-time into the upgraded portion of the technical installation based on the validation (Maturana: [0088] "... For example, based on the enterprise-level supervisory analysis performed on the cloud platform, the virtualized controller may send a command to an on-premise industrial controller to adjust a setpoint value, modify a control sequence, execute a different control routine, or other such operational changes....").
It would have been obvious to one (e.g. a designer) of ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Maturana to Gupta with motivation to combine being that this simulation technique can be used to test and debug control programs without putting field equipment and machinery at risk, to simulate modifications to plant or machine operations and estimation how such modifications affect certain performance or financial metrics, or to perform other analytics (Maturana: [0029]) . Further motivation to combine would have been that Maturana and Gupta are analogous art to the instant claim in field of field equipment/component model/virtualization creation, updating, validating & implementing the change (Maturana: Abstract; Fig.9-12; Gupta: Abstract; Fig.4D-F)
Regarding Claim 2
Gupta teaches method according to claim 1, wherein identifying the deviation in the one or more physical components, the physical connections and the parameter values in the first engineering diagram based on the specification related to the one or more physical components comprises: parsing the specification of the one or more physical components indicating the upgraded portion of the technical installation (Gupta: [0020]-[0028], [0042]-[0046] & see in Fig.4D element 403B showing parsed data) ; extracting the information related to the one or more physical components, the physical connections between the one or more physical components, and the plurality of parameter values associated with the one or more physical components and the physical connections (Gupta: [0020]-[0028], [0042]-[0046] & see in Fig.4D element 403B showing parsed data with components e.g. UPS 402A instances, connections between them with ports, and values); comparing the first engineering diagram representing the portion of the technical installation with the extracted information (Gupta: [0020]-[0028], [0042]-[0046] & see in Fig.4D element 403B showing comparison with 406); and identifying the deviation in the one or more physical components, the physical connections and the parameter values in the first engineering diagram based on the comparison(Gupta: [0020]-[0028], [0042]-[0046] & see in Fig.4D element 402D showing difference in component and their respective connections between 406 and 403B).
Regarding Claim 3
Gupta teaches The method according to claim 1, wherein generating the engineering diagram analytics model for the first engineering diagram based on the identified deviation in the one or more physical components, the physical connections and the parameter values in the first engineering diagram comprises: determining the parameter values associated with the deviation in the one or more physical components and the physical connections (Gupta: Fig.4D & 4E showing the deviation in physical component and connections; incorrect port parameter e.g. T_LIMIT1 as discussed in [0045]; See [0020]-[0028], [0042]-[0046] for context) ; classifying the parameter values associated with the deviation in the one or more physical components and the physical connections into one or more engineering category, wherein each of the one or more engineering category comprises a set of defined actions to be performed (Gupta: [0045] defined action being shutdown; with limits as in [0021]) ; and generating the engineering diagram analytics model for each of the classified engineering category, wherein the engineering diagram analytics model defines a set of rules corresponding to each of the one or more engineering category (Gupta: [0020]-[0028], [0042]-[0046] in context of Fig.4D - "...Once the monitored power reaches the limit specified at T_LIMIT2, the hardware shutdown begins with help of the UPS and the servers...." – as a rule) .
Regarding Claim 4
Gupta teaches The method according to claims3, wherein modifying the first engineering diagram based on the generated engineering diagram analytics model comprises: generating predictions for modifying first engineering diagram based on the engineering diagram analytics model, wherein the predictions comprises one or more changed parameter values associated with the one or more physical components and the physical connections (Gupta: See Fig.4D [0044]-[0046]) ; and modifying the first engineering diagram based on the generated predictions (Gupta: Fig.4D-F, [0024]-[0027] [0044]-[0046]) .
Regarding Claim 5
Gupta teaches The method according to claim: 3, wherein modifying the first engineering diagram based on the generated engineering diagram analytics model comprises: generating recommendations for modifying first engineering diagram based on the engineering diagram analytics model, wherein the recommendations indicate modifications to the first engineering diagram (Gupta: See Fig.4D [0044]-[0046]); and modifying the first engineering diagram based on the generated recommendations (Gupta: Fig.4D-F, [0024]-[0027] [0044]-[0046]).
Regarding Claim 6
Gupta teaches The method according to claim 1, wherein the first engineering diagram comprising the representation of the one or more physical components in the portion of the technical installation, the physical connections between the one or more physical components, and the plurality of parameter values associated with the one or more physical components and the physical connections are configured using a respective graphical program and wherein each graphical program comprises a program logic associated with each of the one or more physical components, the physical connections between the one or more physical components and the plurality of parameter values (Gupta: Fig.4D element 406 the representation of the one or more physical components with its components, connections and values as discussed in [0024]-[0027] [0044]-[0046]). .
Regarding Claim 9
Gupta teaches An engineering system (Gupta: Fig.3 [0030]-[0038]) for generating engineering diagrams in an industrial environment, wherein the engineering system comprises: one or more processor(s) (Gupta: [0030]) ; and a memory coupled to the one or more processor(s) (Gupta: [0031]) , wherein the memory comprises an automation module stored in the form of machine-readable instructions executable by the one or more processor(s) (Gupta: [0034]-[0039]) , wherein the automation module is capable of performing the method according to claim 1 (Gupta: Rejected as in claim 1 above).
Regarding Claim 10
Gupta & Maturana teaches An industrial environment (Gupta: Fig.1 & 3 & Maturana : Fig. 9 & 10) comprising: engineering system as claimed in claim 9 (See claim interpretation) (See mapping claim 9); a technical installation comprising one or more physical components (Gupta: Fig.4D) ; and one or more client devices communicatively coupled to the engineering system via a network (Gupta: Fig.1 & 3 & Maturana: Fig.10 element 1010 showing client devices coupled to the engineering system as disclosed in Fig. 9). Motivation to combine Gupta & Maturana is as in claim 9/1.
Regarding Claim 11
Gupta teaches A computer-program product, comprising a computer redable hardware storage device having computer readable program code stored therein, said program code executable by a processor of a computer system to implement a method having machine- readable instructions stored therein, that when executed by a processor(s), cause the processor(s) to perform the method steps according to claim 1 (Gupta: [039]-[0041] Fig.3; Mapped as in claim 1).
---- This page is left blank after this line ----
Claim(s) 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over EP 3121668 A1 by GUPTA, ROHIT KUMAR, in view of US 20160182309 A1 by Maturana; Francisco P. et al., further in view of US 6226780 B1 by Bahra; Avtar Singh et al.
Regarding Claim 7
Teachings of Gupta and Maturana are shown in the parent claim 1.
Gupta and Maturana teach graphical programming interface and code generation for simulation, but do not teach all the limitations of this claim. Graphical programs are shown in Fig.4D.
Bahra teaches The method according to claim 6, further comprising: identifying current programming language associated with the graphical programs of the first engineering diagram (Bahra: Fig.2 step 210; Col.3 Lines 17-27) ; determining a program logic pattern associated with the current programming language based on graphical program statements, graphical program data flow, basic graphical program data block demarcation and identifying number of jump values (Bahra : E.g. See Fig.4 520-545) in the graphical program (Bahra: Fig.2 step 230 involves parsing Col.3 Lines Lines 42-Col.4 Line 48) ; generating a modified program logic pattern associated with a desired programming language based on the determined program logic pattern associated with the current programming language (Bahra: Fig.2 step 220 Col.3 Lines 27-42) ; and transforming the current programming language associated with the graphical programs into a desired programming language based on the generated modified program logic pattern (Bahra: Fig.2 steps 240-260; Fig.8 Col.5 Lines 1-63).
It would have been obvious to one (e.g. a designer) of ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Bahra to Gupta and Maturana to graphically generate and simulate design with multiple blocks in different languages (Bahra: Fig.2). The motivation to combine would have been that Bahra, Gupta and Maturana are analogous art in the field of graphically designing and modifying the design (Bahra: Abstract; Maturana: Abstract; Fig.9-12; Gupta: Abstract; Fig.4D-F).
Regarding Claim 8
Teachings of Gupta and Maturana are shown in the parent claim 3.
Gupta and Maturana teach graphical programming interface and code generation for simulation, but do not teach all the limitations of this claim.
Bahra teaches The method according to claim 3, wherein modifying the first engineering diagram based on the generated engineering diagram analytics model comprises: classifying a first set of graphical programs of the first engineering diagram into one or more segments based on the program logic of the first set of graphical programs, wherein the first set of graphical programs corresponds to a first programming language (Bahra: Fig.2 step 210 as VHDL IP) ; determining a similar program logic associated with a second set of graphical programs stored in a database based on the classified one or more segments, wherein the second set of graphical programs corresponds to a second programming language (Bahra:: Fig.2 step 210 as Verilog IP) ; and adapting the similar program logic of the second set of graphical programs into the program logic of the first set of graphical programs (Bahra: Fig.2 steps 240-260; Fig.8 Col.5 Lines 1-63) .
It would have been obvious to one (e.g. a designer) of ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Bahra to Gupta and Maturana to graphically generate and simulate design with multiple blocks in different languages (Bahra: Fig.2). The motivation to combine would have been that Bahra, Gupta and Maturana are analogous art in the field of graphically designing and modifying the design (Bahra: Abstract; Maturana: Abstract; Fig.9-12; Gupta: Abstract; Fig.4D-F).
---- This page is left blank after this line ----
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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.
---- This page is left blank after this line ----
Communication
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AKASH SAXENA whose telephone number is (571)272-8351. The examiner can normally be reached Mon-Fri, 7AM-3:30PM.
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, RYAN PITARO can be reached on (571) 272-4071. 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.
AKASH SAXENA
Primary Examiner
Art Unit 2188
/AKASH SAXENA/Primary Examiner, Art Unit 2188 Thursday, September 25, 2025
Prosecution Insights