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-20 have been presented for examination based on the application filed on 11/30/2022.
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 6 & 15 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph.
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) 6-10, and 15-18 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 Non-Final.
---- This page is left blank after this line ----
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].
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.
Claim 3
Claim 1 See [B1] and [A1]
Here the format capable for execution (instant claim) is also capable for being opened/viewed/edited ([B1]) and then executed ([A1]) after translation.
Claim 4
Claim 2
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 1s above.
Claim 13
Claim 11 as mapped in claim 1 annotations of [B1] and [A1]
Here the format capable for execution (instant claim) is also capable for being opened/viewed/edited ([B1]) and then executed ([A1]) after translation. See claim 1 annotations.
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.
(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, 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.
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.
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]).
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-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.
Regarding Claim 1
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 an industrial control program (Ericsson: [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....") ; and
a project generation component (Ericsson: Fig.5 element 206) configured to create, based on the design input, a smart object definition that represents the industrial control program (Ericsson: 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....") , 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 (Ericsson: [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 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 (Ericsson: 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) .
Regarding Claim 2
Ericsson teaches the system of claim 1, wherein the project development interface permits the industrial control program to be written 1 prior to allocation of the instance of the smart object definition to the controller definition (Ericsson: [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
Ericsson teaches the system of claim 1, wherein the executable components further comprise a project deployment component configured to, in response to receipt of an instruction to export executable content associated with the controller definition, export the industrial control program defined by the instance of the smart object definition in a format capable of execution on the industrial controller represented by the controller definition (Ericsson: [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 4
Ericsson teaches system of claim 1, wherein the smart object definition and the instance of the smart object definition comprise the 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
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 smart object definitions, including the smart object definition, that are defined for the industrial control project, and receive the instruction to allocate the instance 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) .
Regarding Claim 11
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 smart object definition to the industrial control definition, determine whether a function defined by the 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 the industrial control program defined by the smart object definition 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...." ) .
Regarding Claims 12 & 19
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 an industrial control program (Ericsson: [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, a smart object definition representing the industrial control program based on the control programming input (Ericsson: 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...." ) ; and
in response to receiving, via interaction with the project development interface, an instruction to assign an instance of the smart object definition to the controller definition, binding, by the system, the instance of the instance of the smart object definition to the controller definition (Ericsson: 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 a copy of the industrial control program defined by 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).
Regarding Claims 13 & 20
Ericsson teaches the method of claim 12/19, further comprising, in response to receiving an instruction to export control programming associated with the controller definition: translating, by the system, the instance of the smart object definition bound to the controller definition to an executable control program having a format capable of execution on the industrial controller represented by the controller definition, and exporting, by the system, the executable control program (Ericsson: [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 14
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 smart object definitions, including the smart object definition, that are defined for the industrial control project, wherein the receiving of the instruction to assign the instance of the smart object definition to the controller definition comprises receiving the instruction 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).
---- 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) 6-10, and 15-18 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
Teachings of Ericsson are shown in the parent claim 1/12.
Ericsson teaches 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 (Ericsson: Fig.19a-19b [0154]-[0158]).
Ericsson does not specifically teach allocate instances of two of the multiple smart object definitions to the controller definition as claimed.
Leonelli teaches 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 (Leonelli: [0029] "...The process library 158 comprises code (i.e. a second code 159, also referred to as “choreographs” or “choreos”) that may be executed upon receiving a call from the controller-based device.... 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.") , and in response to receipt of instructions to allocate instances of two of the multiple smart object definitions to the controller definition (Leonelli: [0017]-[0018] as updating the profile to call first code and second code; See Fig.3 flow) , record bindings between the instances of the two of the multiple smart object definitions and the controller definition (Leonelli: Fig.2 & [0034] shows the binding process as updating the profile to include first code and second code - "... At step 204, the code virtualization server 114 receives, from the user device 112, a modified profile corresponding to a profile used for execution of code (e.g. a first code 126 and/or a second code 159) associated with a controller-based device, for example, the controller-based device 103.sub.P. In some embodiments, the profile updater 157 receives the modified profile from the GUI 138....") , 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 (Leonelli: Fig.3 & 4 [0035]-[0050]; multiple smart objects aspect in view of IDE is taught by Ericsson e.g. Fig.20).
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 Claims 7 & 16
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....").
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
Leonelli teaches the system of claim 1/12, wherein the smart object definition 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 (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
Leonelli teaches the system of claim 9/17, wherein allocation of the 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]) .
---- This page is left blank after this line ----
Conclusion
All claims are rejected.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Examiner’s Note: Examiner has cited particular columns and line numbers in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
In the case of amending the claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention.
---- 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 Saturday, March 7, 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.