DETAILED ACTION
This action is in response to the claims filed 8/5/2026. Claims 1-18 are pending. Claims 7 and 10 have been amended.
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 .
Response to Amendment
In response to the amendment filed 8/5/2026: Applicant has submitted replacement drawings, and the corresponding objections are withdrawn. Applicant has amended the specification, and the corresponding objections have been withdrawn. Applicant has amended the claims, and the objections have been withdrawn.
Applicant has amended the claims, and the corresponding rejections have been altered to address the amended language.
Response to Arguments
Applicant's arguments filed 8/5/2026 have been fully considered but they are not persuasive.
Applicant argues with regards to claim 1:
“Independent claim 1 recites, inter alia, the step of "generating a load memory checksum during a startup of the control software in the runtime environment via the program code of the security program, which is stored in the load memory". Independent claim 10 recites a corresponding limitation. The combination of cited references fails to teach or suggest at least this limitation. The Office (at pg. 5) acknowledges Easttom fails to teach or suggest "operating control software to control a process, the control software being executed within a runtime environment on a computer system, having a program executing in the control software" as recited in independent claim 1, and cites Dyakin for this subject matter. Applicants disagree, however, that the combination of Easttom and Dyakin teaches or suggests independent claim 1.”
Examiner respectfully disagrees. Easttom is relied upon for verifying the integrity of an executable by generating a hash value of the executable when the executable is launched, comparing the generated hash value with a previously stored hash value, and terminating operation when the values do not match. Dyakin is relied upon for the PLC/control-software runtime environment and expressly discloses a security module associate with that environment. The rejection applies the executable-integrity verification of Easttom to the security module of Dyakin during initialization and prior to use.
Further, claim 1 does not recite any particular functionality that the “security program” must perform apart from the treatment of its program code. The claim does not require the more particular safety-program architecture as argued by Applicant. The security module of Dyakin reasonably corresponds to the broadly claimed security program, and Easttom discloses verifying executable program code by generating and comparing a hash upon launch.
Applicant further argues with regards to claim 1:
“Easttom teaches the generic concept of checksum comparison. However, independent claim 10 is directed to more than merely comparing checksums. Independent claim 10 requires the generation of a load memory checksum during startup via the program code of a security program that is stored in load memory. The instant published application consistently describes a safety- controller architecture in which the firmware/runtime environment forms a checksum over the entire safety program in the load memory and compares that value against a previously stored checksum. The Office currently relies on the executable integrity checking disclosed in Easttom, but has failed to provide an adequate explanation of how Easttom teaches or suggests the claimed load memory checksum of the security program stored in the load memory.”
Examiner respectfully disagrees. The claims do not define a “load memory checksum” as a particular type of checksum, nor do they require that the checksum encompass the entire security program or be generated according to the particular architecture in the specification. Claim 1 broadly recites generating a load memory checksum “via the program code of the security program.” Easttom teaches generating a hash value from the executable program code upon launch and comparing the generated value with a previously stored hash value (Easttom col. 4 ll. 16-26). In the combination, this process is applied to the security module of Dyakin.
Furthermore, Claims 1 and 10 do not require that the “firmware/runtime environment forms a checksum over the entire safety program in the load memory”. There is no requirement that the checksum is for the entire security program, nor the firmware or runtime environment performing the checksum operation.
Applicant further argues with regards to claim 1:
“The Office relies on Easttom for the checksum functionality. However, applicants believe Easttom fails to teach or suggest storing hash values remotely, comparing hash values, and stopping operation when a mismatch is detected. In particular, the Office cites Easttom's disclosure that, "when any executable is launched", a hash value of the current executable is sent to a hash value server for comparison (see col. 4, lines 16-26), and that a hash may also be compared upon installation (see col. 4, lines 38-39). Notwithstanding the teachings of Easttom, independent claim 1 is directed to more than merely comparing checksums. Rather, independent claim 1 requires "generating a load memory checksum during a startup of the control software in the runtime environment via the program code of the security program, which is stored in the load memory". Under the proffered analysis, the "hash value of the current executable" as disclosed in Easttom appears to corresponds to applicants' claimed "load memory checksum", but the Office has failed to explain why the skilled person would regard these as the same thing.”
Examiner respectfully disagrees. Claim 1 does not define “load memory checksum” as a checksum having characteristics distinct from a hash generated from executable program code. Easttom teaches generating a hash from the executable being launched and comparing that value with a stored hash value. In the combination of Easttom and Dyakin, the verification of Easttom is applied to the security module of Dyakin. As such, the generated hash of Easttom reasonably reads upon the broadly recited load memory checksum.
Applicant argues with regards to claim 10:
“The Office has failed to adequately show where the cited references teach applicants' claimed relationship among the security program, the load memory, the control software, and the runtime environment. Independent claim 10 requires the generation of a load memory checksum via the program code of the security program that is stored in the load memory during startup of the control software. In contrast, the cited portion of Easttom concerns the generation and comparison of a hash value for a launched executable (see, e.g., col. 4, lines 16-26). Applicants believe the Office has failed to identify where Easttom discloses a load memory checksum generated from the program code of the security program stored in the load memory, nor has the Office explained how the executable integrity checking of Easttom corresponds to applicants' claimed startup verification process.”
Examiner respectfully disagrees. The rejection of Claim 10 relies on Dyakin for the PLC/control-software runtime environment and security module, and on Easttom for verifying executable program code upon launch by generating and comparing a hash value. In the proposed combination presented in the rejection, the integrity-verification method of Easttom is applied to the security module of Dyakin within the PLC runtime environment. The claim does not require the more specific architectural presented by the Applicant in these arguments.
All other arguments presented by Applicant either repeat or rely upon the issues addressed above, and are also not persuasive for the reasons given above.
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 of this title, 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, 7-11 and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Easttom (US 8,819,827 B1), issued Aug. 26, 2014, in view of Dyakin et al. (US 10,599,120 B2), issued Mar. 24, 2020.
As to claim 1, Easttom substantially discloses a method for operating control software (Easttom Fig. 5 software module), and a security program being loaded into a load memory to execute (Easttom col. 1 ll. 15-54 ensuring data files are installed and verified for security measures), the method comprising: storing a checksum of program code of the security program in a network subscriber which is connected to the computer system via a communication network (Easttom col. 3 ll. 60-66 storing hash data values at hash value server on network); generating a load memory checksum during a startup in the runtime environment via the program code of the security program, which is stored in the load memory (Easttom col. 4 ll. 16-26 when any executable is launched send hash value of current executable to hash server for comparison; col. 4 ll. 38-39 hash is also compared upon initial installation); querying the previously stored checksum by the network subscriber and comparing the previously stored checksum with the load memory checksum (Easttom col. 4 ll. 16-26 query issued to hash value server with hash value of current executable, hash value server compares received hash to pre-stored hash value); and terminating execution of the security program in the control software in an event of a discrepancy between the previously stored checksum and the load memory checksum (Easttom col. 4 ll. 16-26 if values do not match indicate that integrity is compromised and system should abort; col. 4 l. 67 - col. 5 l. 4 if hashes do not match issue stop message). Easttom fails to explicitly disclose operating control software to control a process, the control software being executed within a runtime environment on a computer system, having a program executing in the control software. Dyakin describes a method of monitoring the execution system of a programmable logic controller. With this in mind, Dyakin discloses operating control software to control a process (Dyakin col. 4 ll. 36-45 PLC of industrial controller), the control software being executed within a runtime environment on a computer system (Dyakin col. 4 ll. 36-45 PLC with runtime environment), having a program executing in the control software (Dyakin Fig. 2 PLC modules; col. 6 ll. 19-44 security module). It would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains to combine the integrity verification of Easttom with the PLC execution system monitoring of Dyakin, such that the security module of the PLC environment is validated during initialization and prior to use, as it would advantageously ensure the security module is proper and verified for preventing malicious use/security reasons (Easttom col. 1 ll. 15-32).
As to claim 2, Easttom and Dyakin disclose the invention as claimed as described in claim 1, including wherein instances are generated by the runtime environment on one of the computer system and further computer systems, on which control software for controlling a process is executed in each case, and a security program is loaded in each case into a load memory (Dyakin col. 4 ll. 36-45 PLC with runtime environment; Fig. 2 PLC modules; col. 6 ll. 19-44 security module), which is allocated to a respective instance, so as to execute in the respective control software (Easttom col. 3 l. 60 – col. 4 l. 6 hash value server is secure server on organizational network used for managing multiple executable hashes (similarly to digital certificates) for multiple executables on multiple environments); wherein a utility is operated, which manages a storage of respective checksums of respective program codes of respective security programs (Easttom col. 3 l. 60 – col. 4 l. 6 hash value server is secure server on organizational network used for managing multiple executable hashes (similarly to digital certificates) for multiple executables on multiple environments); wherein, during a startup of the respective control software, the respective checksum is requested in the respective instance via the utility, a load memory checksum is generated in the respective instance via program code of the respective security program, which is stored in the associated load memory, and is compared with the checksums which are queried via the utility (Easttom col. 4 ll. 16-26 when any executable is launched send hash value of current executable to hash server for comparison; col. 4 ll. 38-39 hash is also compared upon initial installation; col. 4 ll. 16-26 query issued to hash value server with hash value of current executable, hash value server compares received hash to pre-stored hash value); and wherein execution of the respective security program in the respective control software is terminated in an event of a discrepancy between the load memory checksum generated in the respective instance and the checksums which are queried via the utility (Easttom col. 4 ll. 16-26 if values do not match indicate that integrity is compromised and system should abort; col. 4 l. 67 - col. 5 l. 4 if hashes do not match issue stop message).
As to claim 7, Easttom and Dyakin disclose the invention as claimed as described in claim 1, including wherein the computer system is operated as one of a multifunctional control platform, an industrial personal computer (PC) (Dyakin col. 4 ll. 36-45 PLC of industrial controller with runtime environment), an edge computing platform and a cloud computing platform.
As to claim 8, Easttom and Dyakin disclose the invention as claimed as described in claim 1, including wherein an engineering system for downloading the security program is connected to the computer system, and the checksum of the program code of the security program is stored by one of the engineering system and the runtime environment (Easttom col. 3 ll. 44-59 downloading of software and hash is stored in secured location; col. 5 ll. 26-31 stored in secured folder).
As to claim 9, Easttom and Dyakin disclose the invention as claimed as described in claim 1, including wherein the control software is operated with the security program to control a process as a controller which is established for functional security, and security modules are operated in the control software having the security program to ensure processes that are required by the control software for functional security (Dyakin col. 3 ll. 4-12 security module in PLC for detecting anomalies in PLC).
As to claim 10, Easttom substantially discloses an arrangement (Easttom Fig. 3 showing user computer and hash value server) comprising: a computer system (Easttom Fig. 2 user computer 104 and hash value server 106); a load memory storing a security program for execution (Easttom col. 5 l. 63 – col. 6 l. 8 memory storing programs); a network subscriber connected to the computer system via a communication network, the network subscriber including a storage area in which a checksum of the program code of the security program is stored (Easttom col. 3 ll. 60-66 storing hash data values at hash value server on network); and a program identifier (Easttom col. 3 ll. 44-59 user computer processes executable to produce hash value) which is configured to generate a load memory checksum during a startup via the program code of the security program, which is stored in the load memory (Easttom col. 4 ll. 16-26 when any executable is launched send hash value of current executable to hash server for comparison; col. 4 ll. 38-39 hash is also compared upon initial installation), and to query the checksum which is previously stored in the network subscriber and to compare the checksum with the load memory checksum (Easttom col. 4 ll. 16-26 query issued to hash value server with hash value of current executable, hash value server compares received hash to pre-stored hash value), and furthermore configured to output an error signal which terminates the security program from being executed in the control software in an event of a discrepancy between the checksum with the load memory checksum (Easttom col. 4 ll. 16-26 if values do not match indicate that integrity is compromised and system should abort; col. 4 l. 67 - col. 5 l. 4 if hashes do not match issue stop message). Easttom fails to explicitly disclose a computer system comprising a runtime environment which is configured to execute run control software to control a process, having a program executing in the control software. Dyakin discloses a computer system comprising a runtime environment which is configured to execute run control software to control a process (Dyakin col. 4 ll. 36-45 PLC of industrial controller with runtime environment), having a program executing in the control software (Dyakin Fig. 2 PLC modules; col. 6 ll. 19-44 security module). It would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains to combine the integrity verification of Easttom with the PLC execution system monitoring of Dyakin, such that the security module of the PLC environment is validated during initialization and prior to use, as it would advantageously ensure the security module is proper and verified for preventing malicious use/security reasons (Easttom col. 1 ll. 15-32).
As to claim 11, Easttom and Dyakin disclose the invention as claimed as described in claim 10, including further comprising: a first instance of the runtime environment on the computer system and a second instance of the runtime environment on one of the computer system and a further computer system, the first and second instances being configured to hold control software for controlling a process, in which a security program is loadable (Easttom col. 3 l. 60 – col. 4 l. 6 hash value server is secure server on organizational network used for managing multiple executable hashes (similarly to digital certificates) for multiple executables on multiple environments); a first load memory and a second load memory in which the respective control software is loaded, one of the runtime environment and instances of the runtime environment being configured to load the security programs into the control software during a startup (Dyakin col. 4 ll. 36-45 PLC with runtime environment; Fig. 2 PLC modules; col. 6 ll. 19-44 security module; Easttom col. 4 ll. 16-26 when any executable is launched); and a utility which is configured to manage a storage of the respective checksums of the respective program codes of the respective security programs, and configured to request the respective checksum during a startup of the respective control software in the respective instance (Easttom col. 3 l. 60 – col. 4 l. 6 hash value server is secure server on organizational network used for managing multiple executable hashes (similarly to digital certificates) for multiple executables on multiple environments; col. 4 ll. 16-26 when any executable is launched send hash value of current executable to hash server for comparison); wherein the respective instances are configured to generate a load memory checksum via the program code of the respective security program, which is stored in the associated load memory (Easttom col. 4 ll. 16-26 when any executable is launched send hash value of current executable to hash server for comparison; col. 4 ll. 38-39 hash is also compared upon initial installation), and to compare the load memory checksum with the checksum which is queried via the utility (Easttom col. 4 ll. 16-26 query issued to hash value server with hash value of current executable, hash value server compares received hash to pre-stored hash value); and wherein execution of the respective security program in the respective control software is terminated in an event of a discrepancy between the load memory checksum with the checksum (Easttom col. 4 ll. 16-26 if values do not match indicate that integrity is compromised and system should abort; col. 4 l. 67 - col. 5 l. 4 if hashes do not match issue stop message).
As to claim 16, Easttom and Dyakin disclose the invention as claimed as described in claim 10, including wherein the computer system is configured as one of a multifunctional control platform, an industrial PC (Dyakin col. 4 ll. 36-45 PLC of industrial controller with runtime environment), an edge computing platform and a cloud computing platform.
As to claim 17, Easttom and Dyakin disclose the invention as claimed as described in claim 10, including, further comprising: an engineering system which is configured to at least one of download the security program and create the first and second instances (Easttom col. 3 ll. 44-59 downloading of software at user computer; col. 2 ll. 65-66 modules are isolated using virtualization).
As to claim 18, Easttom and Dyakin disclose the invention as claimed as described in claim 10, including wherein the control software is configured with the security program to control a process as a controller that is configured for functional security, and security modules are present in the control software having the security program to ensure processes that are required by the control software for functional security (Dyakin col. 3 ll. 4-12 security module in PLC for detecting anomalies in PLC).
Claims 3, 6, 12 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Easttom (US 8,819,827 B1), issued Aug. 26, 2014, in view of Dyakin et al. (US 10,599,120 B2), issued Mar. 24, 2020, in view of Bercovici et al. (US 2022/0141034 A1), published May 5, 2022.
As to claim 3, Easttom and Dyakin substantially disclose the invention as claimed as described in claim 2, including wherein a utility managing checksums of a plurality of program codes of the respective security programs for the respective control software (Easttom col. 3 l. 60 – col. 4 l. 6 hash value server is secure server on organizational network used for managing multiple executable hashes (similarly to digital certificates) for multiple executables on multiple environments; col. 4 ll. 16-26 when any executable is launched send hash value of current executable to hash server for comparison). Easttom and Dyakin fail to explicitly disclose wherein a unique identification number is utilized to manage checksums. Bercovici describes a method of tracking provenance of digital data. With this in mind, Bercovici discloses wherein a unique identification number is utilized to manage checksums (Bercovici [0010] data fingerprint stored on blockchain accessed using identifier; [0041] data identifier uniquely identifying the fingerprint). It would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains to combine the fingerprint identifier of Bercovici with the hash value network storage of Easttom and Dyakin, such that the managed hash values are accessed using a unique identifier, as it would advantageously allow for accessing the reference data to be used for verification (Bercovici [0009]).
As to claim 6, Easttom, Dyakin and Bercovici disclose the invention as claimed as described in claim 3, including wherein the checksum of the program code of the security program is copied and a redundant storage is set up, and the checksum or a checksum copy is stored on different network subscribers via the communication network (Bercovici [0010] data fingerprint stored on blockchain accessed using identifier; [0022] blockchain is distributed ledger maintained by plurality of computing devices – in blockchain data is replicated to devices that belong to blockchain).
As to claim 12, Easttom and Dyakin disclose the invention as claimed as described in claim 11, including wherein the utility managing checksums of a plurality of program codes for the respective security programs for the respective control software (see rejection of claim 11 above). Easttom and Dyakin fail to explicitly disclose allocating a unique identification number. Bercovici discloses allocating a unique identification number (Bercovici [0010] data fingerprint stored on blockchain accessed using identifier; [0041] data identifier uniquely identifying the fingerprint is generated). It would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains to combine the fingerprint identifier of Bercovici with the hash value network storage of Easttom and Dyakin, such that the managed hash values are accessed using a unique identifier, as it would advantageously allow for accessing the reference data to be used for verification (Bercovici [0009]).
As to claim 15, Easttom, Dyakin and Bercovici disclose the invention as claimed as described in claim 12, including further comprising: a redundant storage in which a checksum copy of the checksum of the program code of the security program is storable (Bercovici [0010] data fingerprint stored on blockchain accessed using identifier; [0022] blockchain is distributed ledger maintained by plurality of computing devices – in blockchain data is replicated to devices that belong to blockchain).
Claims 4-5 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Easttom (US 8,819,827 B1), issued Aug. 26, 2014, in view of Dyakin et al. (US 10,599,120 B2), issued Mar. 24, 2020, in further view of Yanai et al. (US 5,544,347), issued Aug. 6, 1996.
As to claims 4 and 5, Easttom and Dyakin disclose the invention as claimed as described in claims 1 and 2, respectively, including wherein the checksum of the program code of the security program is stored on a network subscriber via the communication network (Easttom col. 3 ll. 60-66 storing hash data values at hash value server on network). Easttom and Dyakin fail to explicitly disclose wherein the checksum is copied and a redundant storage is set up, and the checksum or a checksum copy is stored on different network subscribers via the communication network. Yanai describes data storage system controlled remote data mirroring with respectively maintained data indices. With this in mind, Yanai discloses wherein the primary data is copied and a redundant storage is set up, and the primary data or a secondary data is stored on different network subscribers via the communication network (Yanai col. 6 ll. 38-51 primary data storage automatically controls duplication or copying of data to secondary data storage). It would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains to combine the mirroring of Yanai with the hash value network storage of Easttom and Dyakin, such that the hash values are mirrored to a secondary storage as backup, as it would advantageously “insure continued data processing operations” should “data become lost, damaged, or unavailable” (Yanai col. 1 ll. 35-38).
As to claims 13 and 14, Easttom and Dyakin disclose the invention as claimed as described in claims 10 and 11, respectively, including storing a checksum of the program code of the security program (Easttom col. 3 ll. 60-66 storing hash data values at hash value server on network). Easttom and Dyakin fail to explicitly disclose a redundant storage in which a checksum copy is storable. Yanai discloses a redundant storage in which a checksum copy is storable (Yanai col. 6 ll. 38-51 primary data storage automatically controls duplication or copying of data to secondary data storage). It would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains to combine the mirroring of Yanai with the hash value network storage of Easttom and Dyakin, such that the hash values are mirrored to a secondary storage as backup, as it would advantageously “insure continued data processing operations” should “data become lost, damaged, or unavailable” (Yanai col. 1 ll. 35-38).
Conclusion
No new prior art is made of record.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ERIC W SHEPPERD whose telephone number is (571)270-5654. The examiner can normally be reached Monday - Thursday, Alt. Friday, 7:30AM - 5:00PM, EST.
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, Rupal Dharia can be reached at (571)272-3880. 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.
/ERIC W SHEPPERD/Primary Examiner, Art Unit 2492
ERIC W. SHEPPERD
Primary Examiner
Art Unit 2492
Prosecution Insights