DETAILED ACTION
This is the initial Office action based on the application filed on April 5, 2024.
Claims 1-20 are pending.
In the interest of facilitating compact prosecution, the Examiner kindly asks the Applicant’s representative to authorize Internet communications with the Examiner by submitting Form PTO/SB/439 using Patent Center.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 1-4, 6, 8, 10-16, and 18-20 are objected to because of the following informalities:
Claims 1-3, 6, 11-13, and 18-20 recite “the respective IDE interfaces.” It should read -- the IDE interfaces --.
Claim 3 recites “the client devices.” It should read -- the respective client devices --.
Claims 4, 10, and 14 recite “the end user entities.” It should read -- the respective end user entities --.
Claim 8 recites “the industrial automation control projects.” It should read -- the respective industrial automation control projects --.
Claims 13 and 20 recite “the individual customizations.” It should read -- the individual customizations of the IDE interfaces --.
Claims 15 and 16 recite “the industrial control and monitoring projects.” It should read -- the respective industrial control and monitoring projects --.
Appropriate correction is required.
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 obviousness-type 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); and 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 a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 1-20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over Claims 1-20 of U.S. Patent No. 11,048,483 (hereinafter “‘483”) in view of US 2006/0136863 (hereinafter “Szpak”).
Examiner respectfully submits the relevant sections of MPEP §§ 804(II)(B)(1) and 804(II)(B)(1)(a) with emphasis added for purposes of convenience in discussion and illustration:
MPEP § 804(II)(B)(1) Obviousness-Type
>A nonstatutory obviousness-type 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); and In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985).<
Any obviousness-type double patenting rejection should make clear:
(A) The differences between the inventions defined by the conflicting claims — a claim in the patent compared to a claim in the application; and
(B) The reasons why a person of ordinary skill in the art would conclude that the invention defined in the claim at issue >is anticipated by, or< would have been an obvious variation of >,< the invention defined in a claim in the patent.
MPEP § 804(II)(B)(1)(a) One-Way Obviousness
If the application at issue is the later filed application or both are filed on the same day, only a one-way determination of obviousness is needed in resolving the issue of double patenting, i.e., whether the invention defined in a claim in the application would have been >anticipated by, or< an obvious variation of >,< the invention defined in a claim in the patent. See, e.g., In re Berg, 140 F.3d 1438, 46 USPQ2d 1226 (Fed. Cir. 1998) (the court applied a one-way test where both applications were filed the same day). If a claimed invention in the application would have been obvious over a claimed invention in the patent, there would be an unjustified timewise extension of the patent and an obvious-type double patenting rejection is proper. Unless a claimed invention in the application would have been >anticipated by, or< obvious over a claimed invention in the patent, no double patenting rejection of the obvious-type should be made, but this does not necessarily preclude a rejection based on another type of nonstatutory double patenting (see MPEP § 804, paragraph II.B.2. below).
Similarly, even if the application at issue is the earlier filed application, only a one-way determination of obviousness is needed to support a double patenting rejection in the absence of a finding: (A) of administrative delay on the part of the Office causing delay in prosecution of the earlier filed application; and (B) that applicant could not have filed the conflicting claims in a single (i.e., the earlier filed) application. See MPEP § 804, paragraph II.B.1.(b) below.
It is noted that the instant application is a later-filed continuation of a series of continuations of ‘483. It is also noted that both ‘483 and the instant application were filed by the same inventive entity and by a common assignee/owner. Claims 1-20 of ‘483 recite almost all the limitations of Claims 1-20 of the instant application, while also recite further limitations. However, Claim 1 of the instant application, for example, recites the further limitations “wherein the IDE editor is configured to individually customize, for an IDE interface associated with an industrial enterprise, a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor, the IDE editor is configured to execute the programming guardrail template against industrial control code imported into an industrial automation control project via the IDE interface, and the user interface component is configured to display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards.”
As per Claim 1 of the instant application, for example, Szpak discloses:
wherein
an IDE editor is configured to individually customize, for an IDE interface associated with an industrial enterprise (paragraph [0002], “MISRA-C has been developed to provide guidelines for the use of the C language in critical systems. MISRA-C is becoming more important for real-time embedded applications within the automotive and aerospace industries [an industrial enterprise].”; paragraph [0043], “The user interfaces 310 [an IDE editor] allow users to perform such actions as draw, edit, annotate, save, and print out block diagram representations of systems. The block diagram environment 300 may provide a graphical user interface (GUI) component that allows drafting of the block diagram by the users [an IDE interface associated with an industrial enterprise].”), a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor (paragraph [0057], “[…] a customized coding standard can be included in the block diagram environment 300. Users can customize the existing coding standards or their own coding standards using the application program interface (API) 370 [individually customize {…} a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor].”),
the IDE editor is configured to execute the programming guardrail template against industrial control code imported into an industrial automation control project via the IDE interface (paragraph [0064], “Referring back to FIGS. 3 and 4, when the block diagram is created or loaded in the block diagram environment 300, the checker 320 applies the selected coding standards to the block diagram (step 420) and finds any violations of the applied coding standard in the block diagram (step 430) [execute the programming guardrail template].”; paragraph [0072], “After linking has been performed, the code generator 340 may generate code for the block diagram (step 470) [industrial control code imported into an industrial automation control project via the IDE interface].”), and
a user interface component is configured to display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards (paragraph [0065], “If the checker 320 applies the selected coding standard to the block diagram and finds the violations of the coding standard, the checker 320 may generate a coding standard violation report for the block diagram. The block diagram environment 300 may provide a user interface 310 for displaying the violation report to the users. FIG. 10 depicts an exemplary user interface 1000 that displays MISRA-C violation report for the Simulink® model 500 [display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards].”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of ‘483 to incorporate the teaching of Szpak into ‘483 to include “wherein the IDE editor is configured to individually customize, for an IDE interface associated with an industrial enterprise, a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor, the IDE editor is configured to execute the programming guardrail template against industrial control code imported into an industrial automation control project via the IDE interface, and the user interface component is configured to display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards.” The modification would be obvious because one of ordinary skill in the art would be motivated to detect violations of a selected coding standard and report such violations to users (Szpak, paragraph [0036]).
Thus, Claims 1-20 of the instant application are obvious over Claims 1-20 of ‘483 and as such are unpatentable for obviousness-type double patenting.
Claim 1 of ‘483 as shown in the table below recites almost all the limitations of Claim 1 of the instant application. The further limitations recited in Claim 1 of ‘483 and Claim 1 of the instant application are boldfaced for the Applicant’s convenience. Claims 2-20 of ‘483 are not shown with Claims 2-20 of the instant application for the purpose of brevity.
U.S. Patent No. 11,048,483
Instant Application No. 18/628,283
1. A system for developing industrial applications, comprising:
1. A system for developing industrial applications, comprising:
a memory that stores executable components; and
a memory that stores executable components; and
a processor, operatively coupled to the memory, that executes the executable components, the executable components comprising:
a processor, operatively coupled to the memory, that executes the executable components, the executable components comprising:
a user interface component configured to render integrated development environment (IDE) interfaces and to receive, via interaction with the IDE interfaces, industrial design input that defines control design aspects of an industrial automation control project, wherein functionality of the IDE interfaces is controlled by an IDE editor;
a user interface component configured to render integrated development environment (IDE) interfaces on respective client devices associated with respective end user entities and to receive, via interaction with the IDE interfaces, design input that defines aspects of respective industrial automation control projects, wherein functionalities of the respective IDE interfaces is controlled by an IDE editor; and
a project generation component configured to generate system project data based on the industrial design input; and an editor definition component configured to receive, via interaction with the user interface component, interface definition data that specifies a customization of an IDE interface, of the IDE interfaces, and to reconfigure the IDE editor to implement the customization of the IDE interface,
a project generation component configured to generate the respective industrial automation control projects based on the design input; and
wherein the customization of the IDE interface specified by the interface definition data comprises at least a definition of a form of programming feedback to be rendered by the IDE interface and a condition under which the form of programming feedback is to be rendered by the IDE interface.
wherein the IDE editor is configured to individually customize, for an IDE interface associated with an industrial enterprise, a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor,
the IDE editor is configured to execute the programming guardrail template against industrial control code imported into an industrial automation control project via the IDE interface, and
the user interface component is configured to display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards.
Claims 1-20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over Claims 1-20 of U.S. Patent No. 11,669,309 (hereinafter “‘309”) in view of US 2006/0136863 (hereinafter “Szpak”).
Examiner respectfully submits the relevant sections of MPEP §§ 804(II)(B)(1) and 804(II)(B)(1)(a) with emphasis added for purposes of convenience in discussion and illustration:
MPEP § 804(II)(B)(1) Obviousness-Type
>A nonstatutory obviousness-type 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); and In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985).<
Any obviousness-type double patenting rejection should make clear:
(A) The differences between the inventions defined by the conflicting claims — a claim in the patent compared to a claim in the application; and
(B) The reasons why a person of ordinary skill in the art would conclude that the invention defined in the claim at issue >is anticipated by, or< would have been an obvious variation of >,< the invention defined in a claim in the patent.
MPEP § 804(II)(B)(1)(a) One-Way Obviousness
If the application at issue is the later filed application or both are filed on the same day, only a one-way determination of obviousness is needed in resolving the issue of double patenting, i.e., whether the invention defined in a claim in the application would have been >anticipated by, or< an obvious variation of >,< the invention defined in a claim in the patent. See, e.g., In re Berg, 140 F.3d 1438, 46 USPQ2d 1226 (Fed. Cir. 1998) (the court applied a one-way test where both applications were filed the same day). If a claimed invention in the application would have been obvious over a claimed invention in the patent, there would be an unjustified timewise extension of the patent and an obvious-type double patenting rejection is proper. Unless a claimed invention in the application would have been >anticipated by, or< obvious over a claimed invention in the patent, no double patenting rejection of the obvious-type should be made, but this does not necessarily preclude a rejection based on another type of nonstatutory double patenting (see MPEP § 804, paragraph II.B.2. below).
Similarly, even if the application at issue is the earlier filed application, only a one-way determination of obviousness is needed to support a double patenting rejection in the absence of a finding: (A) of administrative delay on the part of the Office causing delay in prosecution of the earlier filed application; and (B) that applicant could not have filed the conflicting claims in a single (i.e., the earlier filed) application. See MPEP § 804, paragraph II.B.1.(b) below.
It is noted that the instant application is a later-filed continuation of a continuation of ‘309. It is also noted that both ‘309 and the instant application were filed by the same inventive entity and by a common assignee/owner. Claims 1-20 of ‘309 recite almost all the limitations of Claims 1-20 of the instant application, while also recite further limitations. However, Claim 1 of the instant application, for example, recites the further limitations “wherein the IDE editor is configured to individually customize, for an IDE interface associated with an industrial enterprise, a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor, the IDE editor is configured to execute the programming guardrail template against industrial control code imported into an industrial automation control project via the IDE interface, and the user interface component is configured to display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards.”
As per Claim 1 of the instant application, for example, Szpak discloses:
wherein
an IDE editor is configured to individually customize, for an IDE interface associated with an industrial enterprise (paragraph [0002], “MISRA-C has been developed to provide guidelines for the use of the C language in critical systems. MISRA-C is becoming more important for real-time embedded applications within the automotive and aerospace industries [an industrial enterprise].”; paragraph [0043], “The user interfaces 310 [an IDE editor] allow users to perform such actions as draw, edit, annotate, save, and print out block diagram representations of systems. The block diagram environment 300 may provide a graphical user interface (GUI) component that allows drafting of the block diagram by the users [an IDE interface associated with an industrial enterprise].”), a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor (paragraph [0057], “[…] a customized coding standard can be included in the block diagram environment 300. Users can customize the existing coding standards or their own coding standards using the application program interface (API) 370 [individually customize {…} a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor].”),
the IDE editor is configured to execute the programming guardrail template against industrial control code imported into an industrial automation control project via the IDE interface (paragraph [0064], “Referring back to FIGS. 3 and 4, when the block diagram is created or loaded in the block diagram environment 300, the checker 320 applies the selected coding standards to the block diagram (step 420) and finds any violations of the applied coding standard in the block diagram (step 430) [execute the programming guardrail template].”; paragraph [0072], “After linking has been performed, the code generator 340 may generate code for the block diagram (step 470) [industrial control code imported into an industrial automation control project via the IDE interface].”), and
a user interface component is configured to display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards (paragraph [0065], “If the checker 320 applies the selected coding standard to the block diagram and finds the violations of the coding standard, the checker 320 may generate a coding standard violation report for the block diagram. The block diagram environment 300 may provide a user interface 310 for displaying the violation report to the users. FIG. 10 depicts an exemplary user interface 1000 that displays MISRA-C violation report for the Simulink® model 500 [display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards].”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of ‘309 to incorporate the teaching of Szpak into ‘309 to include “wherein the IDE editor is configured to individually customize, for an IDE interface associated with an industrial enterprise, a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor, the IDE editor is configured to execute the programming guardrail template against industrial control code imported into an industrial automation control project via the IDE interface, and the user interface component is configured to display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards.” The modification would be obvious because one of ordinary skill in the art would be motivated to detect violations of a selected coding standard and report such violations to users (Szpak, paragraph [0036]).
Thus, Claims 1-20 of the instant application are obvious over Claims 1-20 of ‘309 and as such are unpatentable for obviousness-type double patenting.
Claim 1 of ‘309 as shown in the table below recites almost all the limitations of Claim 1 of the instant application. The further limitations recited in Claim 1 of ‘309 and Claim 1 of the instant application are boldfaced for the Applicant’s convenience. Claims 2-20 of ‘309 are not shown with Claims 2-20 of the instant application for the purpose of brevity.
U.S. Patent No. 11,669,309
Instant Application No. 18/628,283
1. A system for developing industrial applications, comprising:
1. A system for developing industrial applications, comprising:
a memory that stores executable components; and
a memory that stores executable components; and
a processor, operatively coupled to the memory, that executes the executable components, the executable components comprising:
a processor, operatively coupled to the memory, that executes the executable components, the executable components comprising:
a user interface component configured to render integrated development environment (IDE) interfaces on respective client devices associated with respective end user entities and to receive, via interaction with the IDE interfaces, design input that defines control design aspects of respective industrial automation control projects, wherein functionalities of the IDE interfaces are controlled by an IDE editor;
a user interface component configured to render integrated development environment (IDE) interfaces on respective client devices associated with respective end user entities and to receive, via interaction with the IDE interfaces, design input that defines aspects of respective industrial automation control projects, wherein functionalities of the respective IDE interfaces is controlled by an IDE editor; and
a project generation component configured to generate the industrial automation control projects based on the design input; and
a project generation component configured to generate the respective industrial automation control projects based on the design input; and
an editor definition component configured to receive, from the respective client devices via the interaction with the IDE interfaces, interface definition data that specifies individual customizations of the IDE interfaces, and to instruct the IDE editor to implement the individual customizations of the IDE interfaces,
wherein the IDE editor permits a client device associated with an end user entity, of the respective end user entities, to access and render an industrial automation control project associated with the end user entity via an IDE interface of the IDE interfaces, and prevents the client device from accessing and rendering other industrial automation control projects associated with other end user entities via the IDE interface of the IDE interfaces.
wherein the IDE editor is configured to individually customize, for an IDE interface associated with an industrial enterprise, a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor,
the IDE editor is configured to execute the programming guardrail template against industrial control code imported into an industrial automation control project via the IDE interface, and
the user interface component is configured to display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards.
Claims 1-20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over Claims 1-20 of U.S. Patent No. 12,001,818 (hereinafter “‘818”) in view of US 2006/0136863 (hereinafter “Szpak”).
Examiner respectfully submits the relevant sections of MPEP §§ 804(II)(B)(1) and 804(II)(B)(1)(a) with emphasis added for purposes of convenience in discussion and illustration:
MPEP § 804(II)(B)(1) Obviousness-Type
>A nonstatutory obviousness-type 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); and In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985).<
Any obviousness-type double patenting rejection should make clear:
(A) The differences between the inventions defined by the conflicting claims — a claim in the patent compared to a claim in the application; and
(B) The reasons why a person of ordinary skill in the art would conclude that the invention defined in the claim at issue >is anticipated by, or< would have been an obvious variation of >,< the invention defined in a claim in the patent.
MPEP § 804(II)(B)(1)(a) One-Way Obviousness
If the application at issue is the later filed application or both are filed on the same day, only a one-way determination of obviousness is needed in resolving the issue of double patenting, i.e., whether the invention defined in a claim in the application would have been >anticipated by, or< an obvious variation of >,< the invention defined in a claim in the patent. See, e.g., In re Berg, 140 F.3d 1438, 46 USPQ2d 1226 (Fed. Cir. 1998) (the court applied a one-way test where both applications were filed the same day). If a claimed invention in the application would have been obvious over a claimed invention in the patent, there would be an unjustified timewise extension of the patent and an obvious-type double patenting rejection is proper. Unless a claimed invention in the application would have been >anticipated by, or< obvious over a claimed invention in the patent, no double patenting rejection of the obvious-type should be made, but this does not necessarily preclude a rejection based on another type of nonstatutory double patenting (see MPEP § 804, paragraph II.B.2. below).
Similarly, even if the application at issue is the earlier filed application, only a one-way determination of obviousness is needed to support a double patenting rejection in the absence of a finding: (A) of administrative delay on the part of the Office causing delay in prosecution of the earlier filed application; and (B) that applicant could not have filed the conflicting claims in a single (i.e., the earlier filed) application. See MPEP § 804, paragraph II.B.1.(b) below.
It is noted that the instant application is a later-filed continuation of ‘818. It is also noted that both ‘818 and the instant application were filed by the same inventive entity and by a common assignee/owner. Claims 1-20 of ‘818 recite almost all the limitations of Claims 1-20 of the instant application, while also recite further limitations. However, Claim 1 of the instant application, for example, recites the further limitations “wherein the IDE editor is configured to individually customize, for an IDE interface associated with an industrial enterprise, a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor, the IDE editor is configured to execute the programming guardrail template against industrial control code imported into an industrial automation control project via the IDE interface, and the user interface component is configured to display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards.”
As per Claim 1 of the instant application, for example, Szpak discloses:
wherein
an IDE editor is configured to individually customize, for an IDE interface associated with an industrial enterprise (paragraph [0002], “MISRA-C has been developed to provide guidelines for the use of the C language in critical systems. MISRA-C is becoming more important for real-time embedded applications within the automotive and aerospace industries [an industrial enterprise].”; paragraph [0043], “The user interfaces 310 [an IDE editor] allow users to perform such actions as draw, edit, annotate, save, and print out block diagram representations of systems. The block diagram environment 300 may provide a graphical user interface (GUI) component that allows drafting of the block diagram by the users [an IDE interface associated with an industrial enterprise].”), a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor (paragraph [0057], “[…] a customized coding standard can be included in the block diagram environment 300. Users can customize the existing coding standards or their own coding standards using the application program interface (API) 370 [individually customize {…} a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor].”),
the IDE editor is configured to execute the programming guardrail template against industrial control code imported into an industrial automation control project via the IDE interface (paragraph [0064], “Referring back to FIGS. 3 and 4, when the block diagram is created or loaded in the block diagram environment 300, the checker 320 applies the selected coding standards to the block diagram (step 420) and finds any violations of the applied coding standard in the block diagram (step 430) [execute the programming guardrail template].”; paragraph [0072], “After linking has been performed, the code generator 340 may generate code for the block diagram (step 470) [industrial control code imported into an industrial automation control project via the IDE interface].”), and
a user interface component is configured to display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards (paragraph [0065], “If the checker 320 applies the selected coding standard to the block diagram and finds the violations of the coding standard, the checker 320 may generate a coding standard violation report for the block diagram. The block diagram environment 300 may provide a user interface 310 for displaying the violation report to the users. FIG. 10 depicts an exemplary user interface 1000 that displays MISRA-C violation report for the Simulink® model 500 [display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards].”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of ‘818 to incorporate the teaching of Szpak into ‘818 to include “wherein the IDE editor is configured to individually customize, for an IDE interface associated with an industrial enterprise, a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor, the IDE editor is configured to execute the programming guardrail template against industrial control code imported into an industrial automation control project via the IDE interface, and the user interface component is configured to display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards.” The modification would be obvious because one of ordinary skill in the art would be motivated to detect violations of a selected coding standard and report such violations to users (Szpak, paragraph [0036]).
Thus, Claims 1-20 of the instant application are obvious over Claims 1-20 of ‘818 and as such are unpatentable for obviousness-type double patenting.
Claim 1 of ‘818 as shown in the table below recites almost all the limitations of Claim 1 of the instant application. The further limitations recited in Claim 1 of ‘818 and Claim 1 of the instant application are boldfaced for the Applicant’s convenience. Claims 2-20 of ‘818 are not shown with Claims 2-20 of the instant application for the purpose of brevity.
U.S. Patent No. 12,001,818
Instant Application No. 18/628,283
1. A system for developing industrial applications, comprising:
1. A system for developing industrial applications, comprising:
a memory that stores executable components; and
a memory that stores executable components; and
a processor, operatively coupled to the memory, that executes the executable components, the executable components comprising:
a processor, operatively coupled to the memory, that executes the executable components, the executable components comprising:
a user interface component configured to render integrated development environment (IDE) interfaces on respective client devices associated with respective end user entities and to receive, via interaction with the IDE interfaces, de sign input that defines control design aspects of respective industrial automation control projects, wherein functionalities of the IDE interfaces are controlled by an IDE editor;
a user interface component configured to render integrated development environment (IDE) interfaces on respective client devices associated with respective end user entities and to receive, via interaction with the IDE interfaces, design input that defines aspects of respective industrial automation control projects, wherein functionalities of the respective IDE interfaces is controlled by an IDE editor; and
a project generation component configured to generate the respective industrial automation control projects based on the design input; and
a project generation component configured to generate the respective industrial automation control projects based on the design input; and
an editor definition component configured to receive, from the respective client devices via the interaction with the IDE interfaces, interface definition data that specifies individual customizations of the IDE interfaces, and to instruct the IDE editor to implement the individual customizations of the IDE interfaces,
wherein the IDE editor comprises one or more open application programming interfaces (APIs) that allow the respective client devices to programmatically access a subset of the IDE editor's low-level services and data models to facilitate the individual customizations of the IDE interfaces.
wherein the IDE editor is configured to individually customize, for an IDE interface associated with an industrial enterprise, a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor,
the IDE editor is configured to execute the programming guardrail template against industrial control code imported into an industrial automation control project via the IDE interface, and
the user interface component is configured to display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards.
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.
Claims 6 and 7 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claim 6 recites the limitation “the interface definition data.” There is insufficient antecedent basis for this limitation in the claim. In the interest of compact prosecution, the Examiner subsequently interprets this limitation as reading “interface definition data” for the purpose of further examination.
Claim 7 recites the limitation “the industrial automation system projects respectively.” There is insufficient antecedent basis for this limitation in the claim. In the interest of compact prosecution, the Examiner subsequently interprets this limitation as reading “the respective industrial automation control projects” for the purpose of further examination.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 6-13, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 2010/0082133 (hereinafter “Chouinard”) (cited in the IDS submitted on 04/08/2024) in view of US 2006/0136863 (hereinafter “Szpak”).
[Examiner’s Remarks: In order for a reference to be proper for use in an obviousness rejection under 35 U.S.C. 103, the reference must be analogous art to the claimed invention. In re Bigio, 381 F.3d 1320, 1325, 72 USPQ2d 1209, 1212 (Fed. Cir. 2004). A reference is analogous art to the claimed invention if: (1) the reference is from the same field of endeavor as the claimed invention (even if it addresses a different problem); or (2) the reference is reasonably pertinent to the problem faced by the inventor (even if it is not in the same field of endeavor as the claimed invention).
Note that the claimed invention is generally directed to industrial programming development platforms (specification, paragraph [0002]). As for the “same field of endeavor” test, Chouinard is generally directed to a development tool that employs language independent models to facilitate automation software design (Chouinard, paragraph [0001]). And Szpak is generally directed to applying coding standards in graphical programming or modeling environments (Szpak, paragraph [0001]). Thus, Chouinard and Szpak are both analogous art to the claimed invention (even if they address different problems). See MPEP § 2141.01(a)(I).]
As per Claim 1, Chouinard discloses:
A system (paragraph [0023], “In one aspect, a control system development platform is provided.”) for developing industrial applications, comprising:
[Examiner’s Remarks: Note that the limitation “developing industrial applications” in the preamble of the claim is not given any patentable weight because it is merely a statement of purpose or intended use of the claimed invention. See MPEP § 2111.02.]
a memory that stores executable components (paragraph [0026]1, “A design shell 100 is adapted to support rapid software development for a control and industrial automation platform. Such shell 100 can be adapted from available Windows technologies but substantially any type of shell could be similarly constructed such as from UNIX, Java, Linux, and so forth.”); and
[1Examiner’s Remarks: Note that Chouinard discloses that the design shell can be adapted from, for example, Windows technologies. Thus, one of ordinary skill in the art would readily comprehend that the design shell constructed from Windows technologies would be run in a computer which includes a memory.]
a processor, operatively coupled to the memory, that executes the executable components (paragraph [0026]2, “A design shell 100 is adapted to support rapid software development for a control and industrial automation platform. Such shell 100 can be adapted from available Windows technologies but substantially any type of shell could be similarly constructed such as from UNIX, Java, Linux, and so forth.”), the executable components comprising:
[2Examiner’s Remarks: Note that Chouinard discloses that the design shell can be adapted from, for example, Windows technologies. Thus, one of ordinary skill in the art would readily comprehend that the design shell constructed from Windows technologies would be run in a computer which includes a processor executing components.]
a user interface component configured to render integrated development environment (IDE) interfaces on respective client devices associated with respective end user entities and to receive, via interaction with the IDE interfaces, design input that defines aspects of respective industrial automation control projects (paragraph [0025], “[…] a shell interface 100 is provided that employs abstract automation models to facilitate software development in a controls environment [render integrated development environment (IDE) interfaces on respective client devices associated with respective end user entities]. As shown, the shell 100 is adapted for various features that facilitate rapid development, debug, and deployment of control systems solutions.”; paragraph [0027], “The development platform and shell 100 employs abstract programming models that enable developers to design control solutions in an abstract setting [receive, via interaction with the IDE interfaces, design input that defines aspects of respective industrial automation control projects] while facilitating code deployment and execution on substantially any type of end hardware platform.”; paragraph [0028], “It is noted that components associated with the interface 100 can include support for various computer or network components such as […] clients [respective client devices associated with respective end user entities] […]”; paragraph [0074], “A Document Generator 650 produces a formatted document according to user’s preferences and choice of chapters [respective end user entities].”), wherein functionalities of the respective IDE interfaces is controlled by an IDE editor (paragraph [0025], “[…] a shell interface 100 is provided that employs abstract automation models to facilitate software development in a controls environment. As shown, the shell 100 is adapted for various features that facilitate rapid development, debug, and deployment of control systems solutions. Such features include version control components 110 to allow revision control of software. Human machine interface (HMI) support is provided at 114 along with a language dictionary 118. Various editors 122-130 are provided [wherein functionalities of the respective IDE interfaces is controlled by an IDE editor] and are described in more detail below.”); and
a project generation component configured to generate the respective industrial automation control projects based on the design input (paragraph [0027], “The development platform and shell 100 employs abstract programming models that enable developers to design control solutions in an abstract setting while facilitating code deployment and execution on substantially any type of end hardware platform. In one aspect, an Abstract Automation Model (AAM) is derived from common base model solutions or standards such as IEC 61131 and 61499, for example. Although any programming standard can be utilized for the underlying model, 61131 and 61499 support a majority of known automation languages in the world today. The AAM defines control structures that represent abstract data objects having properties of a configuration, resource, program, and so forth [generate the respective industrial automation control projects based on the design input].”).
Chouinard does not explicitly disclose:
wherein
the IDE editor is configured to individually customize, for an IDE interface associated with an industrial enterprise, a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor,
the IDE editor is configured to execute the programming guardrail template against industrial control code imported into an industrial automation control project via the IDE interface, and
the user interface component is configured to display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards.
However, Szpak discloses:
wherein
an IDE editor is configured to individually customize, for an IDE interface associated with an industrial enterprise (paragraph [0002], “MISRA-C has been developed to provide guidelines for the use of the C language in critical systems. MISRA-C is becoming more important for real-time embedded applications within the automotive and aerospace industries [an industrial enterprise].”; paragraph [0043], “The user interfaces 310 [an IDE editor] allow users to perform such actions as draw, edit, annotate, save, and print out block diagram representations of systems. The block diagram environment 300 may provide a graphical user interface (GUI) component that allows drafting of the block diagram by the users [an IDE interface associated with an industrial enterprise].”), a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor (paragraph [0057], “[…] a customized coding standard can be included in the block diagram environment 300. Users can customize the existing coding standards or their own coding standards using the application program interface (API) 370 [individually customize {…} a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor].”),
the IDE editor is configured to execute the programming guardrail template against industrial control code imported into an industrial automation control project via the IDE interface (paragraph [0064], “Referring back to FIGS. 3 and 4, when the block diagram is created or loaded in the block diagram environment 300, the checker 320 applies the selected coding standards to the block diagram (step 420) and finds any violations of the applied coding standard in the block diagram (step 430) [execute the programming guardrail template].”; paragraph [0072], “After linking has been performed, the code generator 340 may generate code for the block diagram (step 470) [industrial control code imported into an industrial automation control project via the IDE interface].”), and
a user interface component is configured to display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards (paragraph [0065], “If the checker 320 applies the selected coding standard to the block diagram and finds the violations of the coding standard, the checker 320 may generate a coding standard violation report for the block diagram. The block diagram environment 300 may provide a user interface 310 for displaying the violation report to the users. FIG. 10 depicts an exemplary user interface 1000 that displays MISRA-C violation report for the Simulink® model 500 [display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards].”).
As pointed out hereinabove, Chouinard and Szpak are both analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Szpak into the teaching of Chouinard to include “wherein the IDE editor is configured to individually customize, for an IDE interface associated with an industrial enterprise, a programming guardrail template defining internal programming standards for the industrial enterprise to be enforced by the IDE editor, the IDE editor is configured to execute the programming guardrail template against industrial control code imported into an industrial automation control project via the IDE interface, and the user interface component is configured to display, on the IDE interface based on execution of the programming guardrail template against the industrial control code, notifications that identify portions of the industrial control code that do not comply with the internal programming standards.” The modification would be obvious because one of ordinary skill in the art would be motivated to detect violations of a selected coding standard and report such violations to users (Szpak, paragraph [0036]).
As per Claim 2, the rejection of Claim 1 is incorporated; and Chouinard further discloses:
an editor definition component configured to receive, from the respective client devices via interaction with the IDE interfaces, interface definition data that specifies individual customizations of the respective IDE interfaces, and to instruct the IDE editor to implement the individual customizations on the respective IDE interfaces (paragraph [0027], “The development platform and shell 100 employs abstract programming models that enable developers to design control solutions in an abstract setting while facilitating code deployment and execution on substantially any type of end hardware platform. In one aspect, an Abstract Automation Model (AAM) is derived from common base model solutions or standards such as IEC 61131 and 61499, for example. Although any programming standard can be utilized for the underlying model, 61131 and 61499 support a majority of known automation languages in the world today. The AAM defines control structures that represent abstract data objects having properties of a configuration, resource, program, and so forth. As part of a larger framework or development environment, a Concrete Automation Model (CAM) provides data interfaces associated with the generic data objects and according to a designated project format of differing development environments. For instance, various versions of a development program may have associated CAMs that link or map the respective versions to the underlying abstraction of the AAM.”).
As per Claim 6, the rejection of Claim 1 is incorporated; and Chouinard further discloses:
wherein the IDE editor is configured to individually customize, for the respective IDE interfaces based on interface definition data, at least one of
forms of programming feedback to be rendered by the respective IDE interfaces and conditions under which the programming feedback is to be rendered by the respective IDE interfaces,
control programming syntax supported by the respective IDE interfaces,
editing functionalities supported by the respective IDE interfaces (paragraph [0030], “The Application Builder 200 also provides generalizations editors 250 (e.g., Visual Studio adapted for controls) to perform an easier inter-connection of project format files and the common views.”),
programming guardrails to be enforced by the IDE editor for the respective IDE interfaces,
visual characteristics of the respective IDE interfaces, or
audio characteristics of the respective IDE interfaces.
As per Claim 7, the rejection of Claim 1 is incorporated; and Chouinard further discloses:
wherein the respective industrial automation control projects comprise at least one of an executable industrial control program, an industrial visualization application, industrial device configuration data configured to set a configuration parameter of an industrial device, an engineering drawing, or a bill of materials (paragraph [0025], “[…] the shell 100 is adapted for various features that facilitate rapid development, debug, and deployment of control systems solutions.”).
As per Claim 8, the rejection of Claim 1 is incorporated; and Chouinard further discloses:
wherein the IDE editor supports instantiation of automation objects within an industrial control program that is part of one of the industrial automation control projects, the automation objects representing respective industrial assets including at least one of an industrial process, a controller, a control program, a tag within the control program, a machine, a motor, a motor drive, a telemetry device, a tank, a valve, a pump, an industrial safety device, an industrial robot, or an actuator (paragraph [0028], “It is noted that components associated with the interface 100 can include support for various computer or network components such as servers, clients, controllers, industrial controllers, programmable logic controllers (PLCs), batch controllers or servers, distributed control systems (DCS), communications modules, mobile computers, wireless components, control components and so forth that are capable of interacting across a network.”).
As per Claim 9, the rejection of Claim 8 is incorporated; and Chouinard further discloses:
wherein an automation object, of the automation objects, has associated therewith at least one of an input, an output, an analytic routine, an alarm, a security feature, or a graphical representation of an associated industrial asset (paragraph [0028], “The controller can also communicate to and control various other devices such as Input/Output modules including Analog, Digital, Programmed/Intelligent I/O modules, other programmable controllers, communications modules, sensors, output devices, and the like.”).
As per Claim 10, the rejection of Claim 1 is incorporated; and Chouinard further discloses:
wherein the end user entities comprise at least one of a plant asset owner, an industrial enterprise, an original equipment manufacturer, or a system integrator (paragraph [0074], “A Document Generator 650 produces a formatted document according to user’s preferences and choice of chapters.”; paragraph [0106], “FIG. 14 is a flow diagram illustrating a method 1400 for adapting a shell with abstract models for industrial control software development.”).
Claims 11-13 and 15-17 are method claims corresponding to the system claims hereinabove (Claims 1, 2, and 6-9, respectively). Therefore, Claims 11-13 and 15-17 are rejected for the same reasons set forth in the rejections of Claims 1, 2, and 6-9, respectively.
Claims 18-20 are non-transitory computer-readable medium claims corresponding to the system claims hereinabove (Claims 1, 2, and 6, respectively). Therefore, Claims 18-20 are rejected for the same reasons set forth in the rejections of Claims 1, 2, and 6, respectively.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Chouinard in view of Szpak as applied to Claim 1 above, and further in view of US 2017/0075719 (hereinafter “Scallan”).
As per Claim 5, the rejection of Claim 1 is incorporated; and the combination of Chouinard and Szpak does not explicitly disclose:
wherein
the system executes as a set of cloud-based services, and
the respective end user entities are assigned a portion of a virtual private cloud through which to access the set of cloud-based services.
However, Scallan discloses:
wherein
a system executes as a set of cloud-based services (paragraph [0065], “[…] systems that provide a cloud resource may be utilized exclusively by their owners, such as Google™ or Yahoo!™, or such systems may be accessible to outside users who deploy applications within the computing infrastructure to obtain the benefit of large computational or storage resources.”), and
respective end user entities are assigned a portion of a virtual private cloud through which to access the set of cloud-based services (paragraph [0177], “Next, the method includes a step 4906 of preparing the virtual private cloud by establishing the virtual machines using the restore points and the computing device configurations in the runbook. This process includes using any known dependencies between VMs.”; paragraph [0178], “The method also includes a step 4908 of providing access to the virtual private cloud to a user.”).
As pointed out hereinabove, Scallan is an analogous art to the claimed invention. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Scallan into the combined teachings of Chouinard and Szpak to include “wherein the system executes as a set of cloud-based services, and the respective end user entities are assigned a portion of a virtual private cloud through which to access the set of cloud-based services.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize a secure, isolated private cloud for extra performance and security.
Allowable Subject Matter
Claims 3, 4, and 14 are objected to as being dependent upon a rejected base claim under 35 U.S.C. § 103, but would be allowable over the cited prior art if rewritten in independent form including all of the limitations of the base claim and any intervening claims, and overcome any corresponding objections and/or rejections set forth hereinabove.
Conclusion
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Qing Chen whose telephone number is 571-270-1071. The Examiner can normally be reached on Monday through Friday from 9:00 AM to 5:00 PM ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, the Applicant is encouraged to use the USPTO Automated Interview Request (AIR) at https://www.uspto.gov/ interviewpractice.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner’s supervisor, Wei Mui, can be reached at 571-272-3708. 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 more 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.
/Qing Chen/
Primary Examiner, Art Unit 2191