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-2, 4-5, 7-12, 14, 16-19, 21-25 have been presented for examination based on the amendment filed on 6/4/2026.
Claims 3, 6, 13, 15 and 20 are cancelled.
Claims 21-25 are new.
Claims 1, 2, 4-5, 7, 9-12, 14, 16-19 are amended.
Claims 1, 3, 4, 12, 13, 19 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1, 2, 11, and 19 as mapped of U.S. Patent No. 12,566,426.
Claims 1, 12, and 19 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 6, 15 and 19 as mapped of U.S. Patent No. 12,461,500.
Claim 1, 12 and 19 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1, 11 and 19 of copending Application No. 18/614,956 (US 20250298585 A1) (reference application).
Claims 1-5, 11-14, and 19-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US PGPUB No. US 20210096704 A1 by Ericsson; Matthew R. et al.
Claim(s) 7-10, and 16-18, 22-23 are rejected under 35 U.S.C. 103 as being unpatentable over US PGPUB No. US 20210096704 A1 by Ericsson; Matthew R. et al., in view of US PGPUB No. US 20160327925 A1 by Leonelli; Jean-Baptiste et al.
This action is made Final.
---- This page is left blank after this line ----
Response to Arguments
Applicant has mapped teachings of Ericsson to ¶[0044], [0051], [0052], [0059]-[0062] merely alleged the amended limitation as not being taught by Ericsson. Examiner has performed mapping in updated claim rejection in view of arguments presented.
Pertinent additional arguments pertaining to Leonelli are addressed below:
(Argument ) Applicant has argued in Remarks Pg.:
PNG
media_image1.png
520
646
media_image1.png
Greyscale
(Response 1) Leonelli clearly states:
Leonelli: [0017] "... The code deployed on the controller-based device (a “first code”) includes a call for executing a function (a “second code”) on a remote device, e.g. a server. Code deployed on the controller-based device (the first code) and the remote function (the second code) together form the code for, or associated with, the controller-based device. Profiles are associated with and used for implementing such code for the controller-based device(s) (e.g., devices having a controller, such as microcontrollers, microprocessors, SoC, MCU, among others) ..." [0029] "... The code generator 162 creates the first code for controller-based device, and the first code includes a call from a controller-based device to the code virtualization server 114 for executing the second 159 using a profile associated with the controller-based device....").
Here the two programs (first code and second code) are executed together on the one controller therefore are bound to each other. Leonelli teaches that reference to second by the first program make the second program not completely reside on controller, but still associated (bound) to the first program and executed as one on the controller. Applicants arguments that first and second code not being bound is therefore not persuasive without more definition of how applicant’s binding (associating and executing first and second code) is any different. Also The first and second code are considered as two separate programs (like automated (smart) objects AO’s of Ericsson) executed by the controller. Ericsson Fig.19b shows two separate AO1.Prog for controller 1 and AO2.Prog for controller 2. Therefore applicant’s argument are also not found to be persuasive without showing how applicants define each program. Examiner respectfully maintains the rejection with updated mapping.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 3, 4, 12, 13, 19 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1, 2, 11, and 19 as mapped of U.S. Patent No. 12,566,426. Although the claims at issue are not identical, they are not patentably distinct from each other because as explained in the mapping below.
Instant Application Claims
US Patent No. 12,566,426
(Issued 2/18/2026 for Application No. 18/060,100)
Mapping
1. A system, comprising: a memory that stores executable components; and
a processor, operatively coupled to the memory, that executes the executable components, the executable components comprising:
a user interface component configured to render a project development interface and to receive, via interaction with the project development interface, design input that defines an industrial control program and a controller definition as part of an industrial control project [C1]; and
a project generation component configured to create, based on the design input,
a smart object definition that represents the industrial control program, and
in response to receipt, via interaction with the project development interface, of an instruction to allocate an instance of the smart object definition to the controller definition,
record a binding between the instance of the smart object definition and the controller definition, wherein the binding configures the industrial control project to assign a copy of the industrial control program defined by the smart object definition to an industrial controller represented by the controller definition [A1], and
a project deployment component configured to, in response to receipt of an instruction to export executable content associated with the controller definition, export, based on the bindings, the two of the industrial control programs defined by the instances of the two of the smart object definitions to the industrial controller represented by the controller definition in a format capable of execution on the industrial controller.
1. A system, comprising:a memory that stores executable components; and
a processor, operatively coupled to the memory, that executes the executable components, the executable components comprising:
a user interface component configured to render a project development interface and to receive, via interaction with the project development interface, design input that defines an industrial control program and controller definitions as part of an industrial control project, wherein the controller definitions represent respective industrial controllers;
a project generation component configured to create, based on the design input as part of the industrial control project,
a smart object definition that represents the industrial control program, and
allocate, in accordance with smart object allocation input received via interaction with the project development interface, multiple instances of the smart object definition to respective multiple controller definitions of the controller definitions; and
a project deployment component configured to, in response to receipt of an instruction to export executable content associated with a controller definition, of the multiple controller definitions, translate [B1] an instance, of the multiple instances, allocated to the controller definition to a project file capable of being opened, viewed, and edited in a controller configuration application specific to a type of industrial controller defined by the controller definition ([B1]),
wherein execution of the project file on an industrial controller corresponding to the type configures the industrial controller to monitor and control an automation system in accordance with the industrial control program represented by the smart object definition [A1].
Instant application performs 1 to 1 mapping between the control program and controller and the Patent performs 1 program to many controller mapping (e.g. copying same program to many controller. The instant claim is therefore a simpler case of the Patented case and therefore obvious.
The difference is additional limitation in the patented case which is just disclosing field of use. The as part of an industrial control project is also declared in the previous instant claim limitation [C1].
Here the allocation is also a simpler 1-to-1 allocation in the instant claim for one controller as compared to many 1-to-1 in Patented claim.
In the instant claim the recording of binding ([A1]) between smart object definition and the controller definition means the assigning of smart object definition to the actual controller (which was represented by controller definition) for execution and therefore the Patent discloses similar limitation as instant claim.
Additional limitations in the Patented (“…controller definition to a project file capable of being opened, viewed, and edited in a controller configuration application…”) makes the current claim broader and obvious variant of the instant claim.
See [B1] and [A1]
Claim 4
Claim 2
Claim 12 (Method claim paralleling System claim 1) and now incorporating limitations of claim 13.
Claim 11 (Method claim paralleling System claim 1)
This is mapped and rejected in similar manner as claim 1s above. The mapping is made as claim 1 mapping limitations of claim 3/13.
Claim 19 (A non-transitory computer-readable medium claim paralleling System claim 1)
Claim 19 (A non-transitory computer-readable medium claim paralleling System claim 1)
This is mapped and rejected in similar manner as claim 1s above.
---- This page is left blank after this line ----
Claims 1, 12, and 19 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 6, 15 and 19 as mapped of U.S. Patent No. 12,461,500. Although the claims at issue are not identical, they are not patentably distinct from each other because as explained in the mapping below.
Instant Application Claims
US Patent No. 12,461,500
(Issued 11/4/2025 for Application No. 18/060,031)
Mapping
1. A system, comprising: a memory that stores executable components; and
a processor, operatively coupled to the memory, that executes the executable components, the executable components comprising:
a user interface component configured to render a project development interface and to receive, via interaction with the project development interface,
design input that defines an industrial control program and a controller definition as part of an industrial control project; and
a project generation component configured to create, based on the design input, a smart object definition that represents the industrial control program, and in response to receipt, via interaction with the project development interface, of an instruction to allocate an instance of the smart object definition to the controller definition [A1],
record a binding between the instance of the smart object definition and the controller definition,
wherein the binding configures the industrial control project to assign a copy of the industrial control program defined by the smart object definition to an industrial controller represented by the controller definition; and
a project deployment component configured to, in response to receipt of an instruction to export executable content associated with the controller definition, export, based on the bindings, the two of the industrial control programs defined by the instances of the two of the smart object definitions to the industrial controller represented by the controller definition in a format capable of execution on the industrial controller.
(Claim 6) 1. A system, comprising:
a memory that stores executable components; and
a processor, operatively coupled to the memory, that executes the executable components, the executable components comprising:
a user interface component configured to render a project development interface and to receive, via interaction with the project development interface, programming input that defines an industrial control program as part of an industrial control project, wherein the industrial control program is initially unassigned to an industrial controller;
a project generation component configured to, in response to receipt, via interaction with the project development interface, of an instruction to assign a portion of the industrial control program to a controller definition [A1] representing an industrial controller, define, as part of the industrial control project,
a binding between the portion of the industrial control program and the controller definition;
and a project deployment component configured to, in response to receipt of an instruction to export executable content associated with the controller definition, export, based on the binding, the portion of the industrial control program in a format capable of execution on the industrial controller represented by the controller definition, wherein the portion of the industrial control program is a selected subset of control routines of the industrial control program less than an entirety of the control routines, exporting of the portion of the industrial control program to the industrial controller configures the industrial controller to monitor and control an automation system in accordance with the selected subset of the control routines [B1], and
the binding configures the industrial control project to assign a copy of the portion of the industrial control program to the industrial controller represented by the controller definition.
6. (Currently Amended) The system of claim 1, wherein the project generation component is configured to create a smart object definition that represents the industrial control program based on the programming input, and in response to receipt of the instruction to assign the portion of the industrial control program to the controller definition, bind an instance of an aspect of the smart object definition corresponding to the portion of the industrial control program to the controller definition.
The is no processing happening to the industrial control program after the design input or programming input before it is assigned to a controller definition.
The additional limitation of mapping industrial control program to a smart object definition is also claimed in Patent claim 6
Recording binding vs binding is same in the computer domain of application.
The additional limitation of mapping industrial control program to a smart object definition is also claimed in Patent claim 6.
Claim 6, inheriting from claim1, showing the creation of smart object definition from input.
See [B1] above.
Claim 12 (Method claim paralleling System claim 1)
Claim 15 incorporating claim 11 (Method claim paralleling System claim 1/6)
This is mapped and rejected in similar manner as claim 1 of instant application and claim 6 of Patent above.
Claim 19 (A non-transitory computer-readable medium claim paralleling System claim 1)
Claim 19 (A non-transitory computer-readable medium claim paralleling System claim 1/6)
This is mapped and rejected in similar manner as claim 1 of instant application and claim 6 of Patent above.
---- This page is left blank after this line ----
Claim 1, 12 and 19 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1, 11 and 19 of copending Application No. 18/614,956 (US 20250298585 A1) (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because the instant application is a broader version of the more narrower co-pending application which further uses generative artificial intelligence to process design input. The mapping of the steps is shown below.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Instant Application Claims
Co-pending US Application No. 18/614,956 (US 20250298585 A1)
Mapping
1. A system, comprising: a memory that stores executable components; and
a processor, operatively coupled to the memory, that executes the executable components, the executable components comprising:
a user interface component configured to render a project development interface and to receive, via interaction with the project development interface,
design input that defines an industrial control program [A1] and a controller definition [B1] as part of an industrial control project; and
a project generation component configured to create, based on the design input, a smart object definition that represents the industrial control program, and in response to receipt, via interaction with the project development interface, of an instruction
to allocate an instance of the smart object definition to the controller definition [C1],
record a binding between the instance of the smart object definition and the controller definition,
wherein the binding configures the industrial control project to assign a copy of the industrial control program defined by the smart object definition [D1] to an industrial controller represented by the controller definition; and
and a project deployment component configured to, in response to receipt of an instruction to export executable content associated with the controller definition, export, based on the bindings, the two of the industrial control programs defined by the instances of the two of the smart object definitions to the industrial controller represented by the controller definition in a format capable of execution on the industrial controller.
1. A system, comprising:a memory that stores executable components and one or more custom models; and a processor, operatively coupled to the memory, that executes the executable components, the executable components comprising:a user interface component configured to render a project development interface and to receive, via interaction with the project development interface, design input that defines aspects of an industrial system project, wherein the design input comprises natural language requests received via a chat interface; a generative artificial intelligence (AI) component configured to, in response to receipt of a first natural language request, of the natural language requests, describing one or more requirements of control code to be created as part of the industrial system project [A1],
generate control code inferred to satisfy the one or more requirements and create a smart object definition representing the control code [D1], wherein the generative AI component is configured to generate the control code based on based on analysis of the first natural language request, industry-specific information encoded in the one or more custom models, and a response prompted from a generative AI model, and in response to receipt of a second natural language request, of the natural language requests,
to allocate an instance of the smart object definition to a controller definition [C1] defined in the industrial system project and representing an industrial controller,
record a binding between the instance of the smart object definition and the controller definition,
wherein the binding configures the industrial system project to assign a copy of the control code associated with the smart object definition [D1] to the industrial controller represented by the controller definition; and a project generation component configured to generate, based on the design input, an executable control program file that, in response to execution on the industrial controller represented by the controller definition, configures the industrial controller in accordance with the controller definition and causes the industrial controller to monitor and control an industrial automation system in accordance with the control code.
The claim receives design input and generates (industrial) control code (program) as in [A1]. The Copending application is narrower as it further defines how the input is processed to generate the control code.
The controller definition, as in [B1], is assigned in copending application further down in the claim.
Mapping for [C1] shows assignment of smart object definition to a controller definition
As per [D1] the smart object definition represents control code/ industrial control program (See [A1]).
See mapping as done for project generation component.
Claim 12 (Method claim paralleling System claim 1)
Claim 11 (Method claim paralleling System claim 1)
This is mapped and rejected in similar manner as claim 1 of instant application and claim 1 of copending above.
Claim 19 (A non-transitory computer-readable medium claim paralleling System claim 1)
Claim 19 (A non-transitory computer-readable medium claim paralleling System claim 1)
This is mapped and rejected in similar manner as claim 1 of instant application and claim 1 of copending above.
---- This page is left blank after this line ----
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 6 & 15 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 & dependent claim 6 recite:
Claim 1: …
a user interface component configured to render a project development interface and to receive, via interaction with the project development interface, design input that defines an industrial control program and a controller definition as part of an industrial control project;…
6. The system of claim 1, wherein the design input defines multiple industrial control programs, and the project generation component is configured to: create, based on the design input, multiple smart object definitions that represent the multiple industrial control programs, and in response to receipt of instructions to allocate instances of two of the multiple smart object definitions to the controller definition, record bindings between the instances of the two of the multiple smart object definitions and the controller definition, wherein the bindings configure the industrial control project to assign copies of two of the multiple industrial control programs defined by the two of the multiple smart object definitions to the industrial controller.
A broad range or limitation together with a narrow range or limitation that falls within the broad range or limitation (in the same claim) may be considered indefinite if the resulting claim does not clearly set forth the metes and bounds of the patent protection desired. See MPEP § 2173.05(c). In the present instance, claim 1 recites the broad recitation design input that defines an industrial control program, and the claim also recites 6 which is the narrower statement of the range/limitation. The claim(s) are considered indefinite because there is a question or doubt as to whether the feature introduced by such narrower language is (a) merely exemplary of the remainder of the claim, and therefore not required, or (b) a required feature of the claims. The assignment of many multiple industrial control program (in claim 6), overwrites the limitation of claim 1, which shows assignment of design input from an (one) industrial control program to one controller (claim 1). In other words design input only has one industrial control program initially but now in claim 6 suddenly has multiple industrial control programs. Therefore claim 6 causes indefiniteness as to what design input contains.
The way to rectify this is to include open ended language in claim 1 (similar to “design input that defines at least one [[an]] industrial control program and a controller definition as part of an industrial control project;”).
Claim 15 suffers from similar deficiency and is rejected likewise.
---- This page is left blank after this line ----
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-2, 4-5, 11-14, 19-21, 24-25 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US PGPUB No. US 20210096704 A1 by Ericsson; Matthew R. et al.
Regarding Claim 1 (Updated 8/24/26)
Ericsson teaches A system (Ericsson: Fig.2 as IDE system) , comprising: a memory (Ericsson: Fig.2 element 220; [0087][0090]) that stores executable components; and a processor (Ericsson: Fig.2 element 218, [0087][0090]) , operatively coupled to the memory, that executes the executable components, the executable components (Ericsson: [0087][0090]) comprising:
a user interface (Ericsson: Fig.2 & 5 elements 204) component configured to render a project development interface (Ericsson: Fig.5 IDE editor interface 224; Fig. 9; [0088]) and to receive, via interaction with the project development interface (Ericsson: [0088] "... User interface component 204 can be configured to receive user input..."), design input that defines multiple industrial control program (Ericsson: identifies multiple industrial control programs as control or visualization code that is later mapped to automation objects (plural) as mapped in [0097] "...[0097] In addition to control programming and visualization definitions, some embodiments of IDE system 202 can be configured to receive digital engineering drawings (e.g., computer-aided design (CAD) files) as design input 512. In such embodiments, project generation component 206 can generate portions of the system project 302—e.g., by automatically generating control and/or visualization code—based on analysis of existing design drawings..... Project generation component 206 can associate or map elements identified in the drawings with appropriate automation objects 222 corresponding to these elements (e.g., tanks, pumps, etc.) and add these automation objects 222 to the system project 302. " [0089] "...[0089] Project generation component 206 can be configured to create a system project comprising one or more project files based on design input received via the user interface component 204, as well as industrial knowledge, predefined code modules and visualizations, and automation objects 222 maintained by the IDE system 202. ..." [0088] "... Input data that can be received via various embodiments of user interface component 204 can include, but is not limited to, programming code, industrial design specifications or goals, engineering drawings, AR/VR input, DSL definitions, video or image data, or other such input...."; [0091]) and a controller definition as part of an industrial control project (Ericsson: [0115]-[0116]; [0089] "... To this end, project deployment component 208 can identify the appropriate target devices to which respective portions of the system project should be sent for execution, translate these respective portions to formats understandable by the target devices, and deploy the translated project components to their corresponding devices....");
a project generation component (Ericsson: Fig.5 element 206) configured to create, based on the design input, a smart object definition that represent multiple the industrial control program (Ericsson: smart object definition as automation objects 222 (plural); as described in Fig.2 [0089] and Fig.6 & [0112]-[0113] at least; also see [0095] "... [0095] An automation object 222 for a given type of industrial asset can encode such aspects as 2D or 3D visualizations, alarms, control coding (e.g., logic or other type of control programming),..."; [0113] "... [0113] At least some of the attributes of each automation object 222 are default properties defined by the IDE system 202 based on encoded industry expertise pertaining to the asset represented by the objects. Other properties can be modified or added by the developer as needed (via design input 512) to customize the object 222 for the particular asset and/or industrial application for which the system projects 302 is being developed. This can include, for example, associating customized control code, HMI screens, AR presentations, or help files associated with selected automation objects 222. In this way, automation objects 222 can be created and augmented as needed during design for consumption or execution by target control devices during runtime...."), and
in response to receipt, via interaction with the project development interface, of an instruction to allocate instances of two of the smart object definitions to the controller definition (Ericsson: [0094] "...Automation objects 222 can represent elements at substantially any level of an industrial enterprise, including individual devices, machines made up of many industrial devices and components (some of which may be associated with their own automation objects 222), and entire production lines or process control systems...." ; Fig.6 as example showing having at least 2 automation objects (AO) 222; Fig.19a; [0115] "... Once project development is complete and system project 302 is ready for commissioning, the user can specify (via user interface component 204) target devices on which respective aspects of the system project 302 are to be executed. In response, an allocation engine of the project deployment component 208 will translate aspects of the system project 302 to respective executable files formatted for storage and execution on their respective target devices....") , record bindings between the instance of the smart object definition and the controller definition, wherein the binding configure the industrial control project to assign copies of two of the multiple industrial control programs defined by the two of the smart object definitions to an industrial controller represented by the controller definition (Ericsson: Fig.19a-19b showing the binding as assignment of automation object (AO) such as AO1.prog to Controller 1 in hierarchy; [0115]-[0116]; Also see Fig.19a & 27 representing various objects; Fig.6 shows “Process AO” being assigned plurality of AO under it (“Pump AO”, “Valve AO”, “Tank AO”; Fig.3 & 4 [0035]-[0050]; multiple smart objects aspect in view of IDE is taught by Ericsson e.g. Fig.20) and
a project deployment component configured to, in response to receipt of an instruction to export executable content associated with the controller definition, export, based on the bindings, the two of the industrial control programs defined by the instances of the two of the smart object definitions to the industrial controller represented by the controller definition in a format capable of execution on the industrial controller (Ericsson: Fig. 6 shows plurality of automation objects in hierarchy of parent automation object (e.g. “Process AO”) can be assigned to the top level program “Process AO”. Further each of these top level programs (such process AO/AO1.Prog /AO2.Prog) can be assigned to two of more controllers (as shown in Fig.19b & Fig.6), where AO.1 assigned to controller 1. Similarly another industrial control program AO.2 assigned to controller 2.
PNG
media_image2.png
1123
1668
media_image2.png
Greyscale
[0112] showing association of process automation (Process.AO) to industrial controller, [0115] "... In response, an allocation engine of the project deployment component 208 will translate aspects of the system project 302 to respective executable files formatted for storage and execution on their respective target devices...."; [0116] "... Project deployment component 208 can then translate the controller code defined by the system project 302 to a control program file 702 formatted for execution on the specified industrial controller 118 and send this control program file 702 to the controller 118 (e.g., via plant network 116)....").
Regarding Claim 2 (Updated 8/24/26)
Ericsson teaches the system of claim 1, wherein the project development interface permits the two of the multiple industrial control program to be written 1 prior to allocation of the instance of the two of the smart object definition to the controller definition (Ericsson: See Fig. 19a showing industrial control program AO1.Prog, and AO2.Prog; [0115]-[0117]; [0117] "... This also allows the same system project 302 to be commissioned at different plant facilities having different sets of control equipment. That is, some embodiments of the IDE system 202 can allocate project code to different target devices as a function of the particular devices found on-site. ..."; [0094] "... Automation objects 222 can represent elements at substantially any level of an industrial enterprise, including individual devices, machines made up of many industrial devices and components (some of which may be associated with their own automation objects 222), and entire production lines or process control systems....") .
Regarding Claim 3 (Cancelled)
Regarding Claim 4 (Updated 8/24/26)
Ericsson teaches system of claim 1, wherein the two of the smart object definitions comprise the two industrial control program (Ericsson teaches : [0132] " ... Example types of project content that can be associated with a dedicated set of content panels (and associated visibility icons) can include, but are not limited to, a ladder logic routine, a function block diagram routine, a structured text routine, a sequential function chart routine, a tag database...") and associated data tag definitions (Ericsson: [0140] "... In general, the canvas area 930 contains the one or more workspace canvases 940 on which the user interface component 204 renders components of the system project, such as ladder logic or other types of control code, program routines, controller tag definitions..." [0132] "... Example types of project content that can be associated with a dedicated set of content panels (and associated visibility icons) can include, but are not limited to, a ladder logic routine, a function block diagram routine, a structured text routine, a sequential function chart routine, a tag database..."; Fig.17c [0149] "... This configuration allows the user to view content of both canvases 940 simultaneously (e.g., a control program and a tag database, a control program and a device view, etc.)...") .
Regarding Claim 5 (Updated 8/24/26)
Ericsson teaches system of claim 1, wherein the user interface component is further configured to render a navigation tree that comprises browsable smart object nodes representing multiple smart object definitions, and receive the instruction to allocate the instance of the two of the smart object definition via interaction with the navigation tree (Ericsson: Fig.19a-19b [0154]-[0158]; Fig.19b shows allocation of smart object code as AO1.Prog, AO2.Prog to controller1 and controller2 respectively in the navigation tree; each of the AO1.Prog /AO2.Prog is shown in controller which may be in form of Fig.6
PNG
media_image3.png
1123
1668
media_image3.png
Greyscale
) .
Regarding Claim 11(Updated 8/24/26)
Ericsson teaches the system of claim 1, wherein the project generation component is further configured to, in response to receipt of the instruction to allocate the instance of the two of the smart object definition to the industrial control definition, determine whether a function defined by the either of the two smart object definition is not supported by the industrial controller represented by the controller definition, and the user interface component is configured to, in response to a determination by the project generation component that the function is not supported by the industrial controller, render, on the project development interface, a warning that function is not supportable by the industrial controller (Ericsson: [0119] "... For target devices that do not perfectly match the expected asset, project deployment component 208 can calculate the estimated impact of running the system project 302 on non-optimal target equipment and generate warnings or recommendations for mitigating expected deviations from optimal project execution...." ; Fig.6 and 19a showing multiple smart object as automation objects) .
Regarding Claims 12 & 19(Updated 8/24/26)
Ericsson teaches (Claim 12) A method (Ericsson: Figs. 32a-35b showing various aspects of IDE based smart object assignment (controller program) to controller representation in graphical manner; See Fig.19a-19b ) , /
(Claim 19) A non-transitory computer-readable medium (Ericsson : Fig.36 elements 3614 & 3606; [0212]-[0218]) having stored thereon instructions that, in response to execution, cause a system comprising a processor to perform operations, the operations comprising:
receiving, by a system comprising a processor via interaction with a project development interface (Ericsson : Fig.2 elements IDE 202 as project development interface, processor 218; Fig.5 IDE editor interface 224; Fig. 9; [0088]) , control programming input that defines multiple industrial control program (Ericsson: identifies multiple industrial control programs as control or visualization code that is later mapped to automation objects (plural) as mapped in [0097] "...[0097] In addition to control programming and visualization definitions, some embodiments of IDE system 202 can be configured to receive digital engineering drawings (e.g., computer-aided design (CAD) files) as design input 512. In such embodiments, project generation component 206 can generate portions of the system project 302—e.g., by automatically generating control and/or visualization code—based on analysis of existing design drawings..... Project generation component 206 can associate or map elements identified in the drawings with appropriate automation objects 222 corresponding to these elements (e.g., tanks, pumps, etc.) and add these automation objects 222 to the system project 302. " [0089] "...[0089] Project generation component 206 can be configured to create a system project comprising one or more project files based on design input received via the user interface component 204, as well as industrial knowledge, predefined code modules and visualizations, and automation objects 222 maintained by the IDE system 202. ..." [0088] "... Input data that can be received via various embodiments of user interface component 204 can include, but is not limited to, programming code, industrial design specifications or goals, engineering drawings, AR/VR input, DSL definitions, video or image data, or other such input...."; [0091]);
defining, by the system as part of an industrial control project, smart object definitions representing the multiple industrial control programs respectively, based on the control programming input (Ericsson: [0097], [0087] as above, also see Fig.19b; smart object definition as automation object 222 as described in [0095] "... [0095] An automation object 222 for a given type of industrial asset can encode such aspects as 2D or 3D visualizations, alarms, control coding (e.g., logic or other type of control programming),..."; [0113] "... [0113] At least some of the attributes of each automation object 222 are default properties defined by the IDE system 202 based on encoded industry expertise pertaining to the asset represented by the objects. Other properties can be modified or added by the developer as needed (via design input 512) to customize the object 222 for the particular asset and/or industrial application for which the system projects 302 is being developed. This can include, for example, associating customized control code, HMI screens, AR presentations, or help files associated with selected automation objects 222. In this way, automation objects 222 can be created and augmented as needed during design for consumption or execution by target control devices during runtime....");
receiving, by the system via interaction with the project development interface, controller definition input that defines properties of an industrial controller (Ericsson: [0115]-[0116]; [0089] "... To this end, project deployment component 208 can identify the appropriate target devices to which respective portions of the system project should be sent for execution, translate these respective portions to formats understandable by the target devices, and deploy the translated project components to their corresponding devices....");
storing, by the system as part of the industrial control project, the controller definition input as a controller definition (Ericsson: [0087] as data stored with user interface component 204 including an IDE editor 224, a project generation component 206, a project deployment component 208; [0094] "... These automation objects 222 provide a common data structure across the IDE system 202 and can be stored in an object library (e.g., part of memory 220) for reuse...." );
in response to receiving, via interaction with the project development interface, an instruction to assign instances of two of the smart object definitions to the controller definition, binding, by the system, the instance of the instances of two of the smart object definition to the controller definition (Ericsson: Fig.6 showing main program or smart automation object (AO), viz. “Process AO” having at least two instances of sub automation objects (AO) (e.g. Pump AO, Valve AO) where the main process AO would be assigned to controller as shown in Fig.19a-19b showing the binding as assignment of AO1.prog to Controller 1 in hierarchy; [0115]-[0116]; Also see Fig.19a & 27 representing various objects), wherein the binding configures the industrial control project to designate assign copies of two of the multiple industrial control programs defined by the two of the smart object definition to the industrial controller represented by the controller definition (Ericsson: Fig.19a-19b showing the binding; [0115]-[0116] show assignment in format executable by controller; Also see Fig.19a & 27 representing various objects); and in response to receiving an instruction to export control programming associated with the controller definition: translating, by the system based on the binding, the two of the multiple industrial control programs to executable control code having a format capable of execution on the industrial controller represented by the controller definition; and exporting, by the system, the executable control code to the industrial controller (Ericsson: Fig. 6 shows plurality of automation objects in hierarchy of parent automation object (e.g. “Process AO”) can be assigned to the top level program “Process AO”. Further each of these top level programs (such process AO/AO1.Prog /AO2.Prog) can be assigned to two of more controllers (as shown in Fig.19b & Fig.6), where AO.1 assigned to controller 1. Similarly another industrial control program AO.2 assigned to controller 2.
PNG
media_image2.png
1123
1668
media_image2.png
Greyscale
[0112] showing association of process automation (Process.AO) to industrial controller, [0115] "... In response, an allocation engine of the project deployment component 208 will translate aspects of the system project 302 to respective executable files formatted for storage and execution on their respective target devices...."; [0116] "... Project deployment component 208 can then translate the controller code defined by the system project 302 to a control program file 702 formatted for execution on the specified industrial controller 118 and send this control program file 702 to the controller 118 (e.g., via plant network 116)....").
Regarding Claims 13 & 20 (Cancelled)
Regarding Claim 14 (Updated 8/24/26)
Ericsson teaches the method of claim 12, further comprising displaying, by the system on the project development interface, a navigation tree comprising browsable smart object nodes representing the smart object definitions, that are defined for the industrial control project, wherein the receiving of the instruction to assign the instance of the two of the smart object definition to the controller definition comprises receiving the instruction via interaction with the navigation tree (Ericsson: Fig.6 plurality of AO, Fig.19a-19b [0154]-[0158]; Fig.19b shows allocation of smart object code as AO1.Prog, AO2.Prog to controller1 and controller2 respectively in the navigation tree initially created using process described in Fig.33a-33b, see specifically 3304 & [0189]).
Regarding Claim 21 (New)
Ericsson teaches The non-transitory computer-readable medium of claim 19, wherein the receiving of the instruction to allocate the instances of the two of the smart object definition to the controller definition comprises: displaying, on the project development interface, a navigation tree comprising browsable smart object nodes representing the smart object definitions that are defined for the industrial control project; and receiving the instruction to allocate the instances of the two of the smart object definition to the controller definition via interaction with the navigation tree (Ericsson: Fig.6 plurality of AO, Fig.19a-19b [0154]-[0158]; Fig.19b shows allocation of smart object code as AO1.Prog, AO2.Prog to controller1 and controller2 respectively in the navigation tree initially created using process described in Fig.33a-33b, see specifically 3304 & [0189]).
Regarding Claim 24, 25 (new)
Ericsson teaches 24. The system of claim 1, or the The method of claim 12, wherein I/O tags of an industrial control program wherein I/O tags of an industrial control program, of the two of the multiple industrial control programs, are written to be agnostic with regard to controller I/O addresses, and the project generation component is further configured to, in response to the receipt of the instruction to allocate the instances of the two of the smart object definitions to the controller definition, map the I/O tags of the industrial control program to available I/O addresses of the industrial controller represented by the controller definition (Ericsson: [0077] "... HMIs 114 can also be configured to allow operators to submit data to specified data tags or memory addresses of the industrial controllers 118, thereby providing a means for operators to issue commands to the controlled systems (e.g., cycle start commands, device actuation commands, etc.), to modify setpoint values, etc...." – here tags represent a memory address on actual controller to which I/O like issuing commands can be written).
---- This page is left blank after this line ----
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) 7-10, and 16-18, 22-23 are rejected under 35 U.S.C. 103 as being unpatentable over US PGPUB No. US 20210096704 A1 by Ericsson; Matthew R. et al., in view of US PGPUB No. US 20160327925 A1 by Leonelli; Jean-Baptiste et al.
Regarding Claims 6 & 15 (Cancelled)
Regarding Claims 7 & 16, (Updated 8/24/26) and 22 (New)
Teachings of Ericsson are shown in the parent claims 1/ 12/ 19.
Ericsson does not specifically each wherein the project generation component is further configured to, in response to receipt, via interaction with the project development interface, of an instruction to allocate an instance of a portion of the smart object definition less than an entirety of the smart object definition to the controller definition, record a binding between the instance of the portion of the smart object definition and the controller definition .
Leonelli teaches the system of claim 1/12, wherein the project generation component is further configured to, in response to receipt, via interaction with the project development interface (Leonelli: [0026]) , of an instruction to allocate an instance of a portion of the smart object definition less than an entirety of the smart object definition to the controller definition (Leonelli: [0029] Figs.2-4 where the second code for execution does not reside on the controller, only reference to second code resides on the controller therefore it is less than all code in the controller ) , record a binding between the instance of the portion of the smart object definition and the controller definition (Leonelli: [0029] "... The SDK generator 160 generates an SDK for supporting execution of the first code, the second code or both, for example, by providing necessary code libraries according to the hardware, software platform, communication infrastructure and other code execution parameters....") , and the binding between the instance of the portion of the smart object definition assigns a subset of the industrial control program corresponding to the portion of the smart object definition to the industrial controller (Leonelli: [0029] "... The code generator 162 creates the first code for controller-based device, and the first code includes a call from a controller-based device to the code virtualization server 114 for executing the second 159 using a profile associated with the controller-based device....").
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 Leonelli to Ericsson to advantageously allows for modifying the profile (assignment and binding of code) & modify the code behavior without requiring to modify the code itself, and without requiring to re-execute the steps of development, testing and deployment (Leonelli: [0046]). Further motivation to combine would have been that Leonelli and Ericsson are analogous art to the instant claim in the field of integrated development environment (IDE) based controller design (Leonelli: [0026] and Ericsson: Abstract).
Regarding Claim 8
Leonelli teaches the system of claim 7, wherein the portion of the smart object definition comprises a subset of control routines less than a total of all control routines of the industrial control program (Leonelli: [0029] Figs.2-4 where the second code for execution does not reside on the controller, only reference to second code resides on the controller therefore it is less than all code in the controller).
Regarding Claims 9 & 17 (Updated 8/24/26)
Ericsson and Leonelli teaches the system of claim 1/12, wherein a smart object definition, of the multiple smart object definitions, includes an indication of another smart object definition that is designated as a child smart object definition of the smart object definition, and the other smart object definition defines another industrial control program (Ericsson: Fig.6 showing multiple smart object as automation objects (AO) in heirarchy; Leonelli: [0029] "... The code generator 162 creates the first code for controller-based device, and the first code includes a call from a controller-based device to the code virtualization server 114 for executing the second [code] 159 using a profile associated with the controller-based device...." - this call from first code to second code is understood as parent (first code) – child (second code) relationship; further Ericsson also teaches child objects can be graphically defined in similar manner in IDE – [0112]). Regarding Claims 10 & 18 (Updated 8/24/26)
Leonelli teaches the system of claim 9/17, wherein allocation of an instance of the smart object definition to the controller definition causes an instance of the child smart object definition to also be allocated to the controller definition (Leonelli: Fig.2-4 show allocation as process of updating the profile assigned to a controller, which assigns a second code as child (as it is invoked from first code) to be executed by the controller; See Fig.4 assignment of “Profile 2” to controller and Fig.2-3 execution of Profile 2 with first code (on controller) and second code called from first code on controller; further Ericsson also teaches child objects can be graphically defined in similar manner in IDE – [0112]) .
Regarding Claim 22 (New)
Leonelli teaches The non-transitory computer-readable medium of claim 19, wherein the operations further comprise: in response to receiving an instruction to assign an instance of a portion of a smart object definition, of the multiple smart object definitions, that is less than an entirety of the smart object definition to the controller definition (Leonelli: [0029] Figs.2-4 where the second code for execution does not reside on the controller, only reference to second code resides on the controller therefore it is less than all code in the controller; [0017] ), binding the instance of the portion of the smart object definition to the controller definition, wherein the binding of the instance of the portion of the smart object definition to the controller definition configures the industrial control project to designate a subset of the industrial control program corresponding to the portion of the smart object definition to the industrial controller (Leonelli: [0017] "... The code deployed on the controller-based device (a “first code”) includes a call for executing a function (a “second code”) on a remote device, e.g. a server. Code deployed on the controller-based device (the first code) and the remote function (the second code) together form the code for, or associated with, the controller-based device. Profiles are associated with and used for implementing such code for the controller-based device(s) (e.g., devices having a controller, such as microcontrollers, microprocessors, SoC, MCU, among others) ..." [0029] "... The code generator 162 creates the first code for controller-based device, and the first code includes a call from a controller-based device to the code virtualization server 114 for executing the second 159 using a profile associated with the controller-based device....").
Regarding Claim 23 (New)
Ericsson and Leonelli teaches The non-transitory computer-readable medium of claim 19, wherein the defining of the smart object definitions comprises designating a first smart object definition as a child smart object definition of a second smart object definition, the first smart object definition defining another industrial control program (Ericsson: Fig.6 showing multiple smart object as automation objects (AO) in heirarchy; Leonelli: [0029] "... The code generator 162 creates the first code for controller-based device, and the first code includes a call from a controller-based device to the code virtualization server 114 for executing the second [code] 159 using a profile associated with the controller-based device...." - this call from first code to second code is understood as parent (first code) – child (second code) relationship; further Ericsson also teaches child objects can be graphically defined in similar manner in IDE – [0112]). , and the operations further comprise :in response to receiving an instruction to assign an instance of the second smart object definition to the controller definition, binding instances of the second smart object definition and the first smart object definition to the controller definition (Leonelli: [0029] "... The code generator 162 creates the first code for controller-based device, and the first code includes a call from a controller-based device to the code virtualization server 114 for executing the second 159 using a profile associated with the controller-based device...." – execution of second code 159 based on call from first code would require binding).
---- This page is left blank after this line ----
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 Tuesday, August 25, 2026
1 See Leonelli et al (US 20160327925 A1) as teaching partial program as second code, which is not on the controller. The claim has a “OR” clause, otherwise it would be rejected additionally with Leonelli et al.
