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 .
DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on March 30, 2026 has been entered.
This Office Action is in response to Applicant’s Amendment filed on March 30, 2026, for U.S. patent application 18340064 filed on June 23, 2023.
Original claims 1-17 are pending, with claims 1, 6, 11 and 14 being independent claims, and with claims 1, 6, 11 and 14 having been amended. No claims have been cancelled or added. Accordingly, claims 1-17 remain and have been examined in this application.
Response to Arguments
The Examiner continues to acknowledge Applicant’s comments regarding claim interpretation under 35 U.S.C. § 112(f) (or 35 U.S.C. § 112, sixth paragraph.
Applicants’ arguments in the instant Amendment, filed on March 30, 2026, with respect to limitations listed below, have been fully considered but they are not persuasive as follows.
Applicant’s argument: As shown above, the cited disclosure of Preschern distributes the features cited as disclosing the features of claim 1 across two separate computer systems that communicate over a network. As best understood by Applicant, the Office Action appears to contend that the PLC software alone accounts for all of the features of previously presented claim 1. Applicant respectfully disagrees and maintains the same arguments previously presented.
The Examiner disagrees with the Applicants for a number of reasons. First, it is respectfully noted that the “disclosing the features of claim 1 across two separate computer systems that communicate over a network” limitations argued by Applicant, are NOT recited within Applicant’s claims. More particularly, at best, Applicant’s March 30, 2026, claims recite only a single “first computing device” or a “computing device”. Further, it is respectfully noted that “network” is nowhere mentioned within Applicant’s claims. In short, it is noted that the features upon which Applicant relies are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See 7.37.08 Unpersuasive Argument, and In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Second, the Examiner respectfully submits that Preschern distributes the features as claimed across at least two separate computer systems, i.e., a “PLC engineering software” equipped computer, and a “PLC” equipped computer …see, for example, Preschern’s FIG 4. To the extent that the Office’s previously-presented arguments apply to the presently-amended claims, such arguments are repeated herein.
Applicant’s argument: Applicant also notes that the PLC software does not perform the act of accessing using the secure program component a previously-calculated CHF digest of said at least the portion of the executable program contained in a white-box data structure of the executable program. Notably the claimed secure program component is part of the claimed executable program. In contrast, the alleged previously-calculated CHF digest of Preschern is contained in a separate openSAFETY frame that is sent via a secured black channel separately from the alleged executable program. This is a significant technical difference because, inter alia, it. requires use of a secured black channel and transmission frame rather than including the secure program component in the executable program as per claim 1.
The Examiner disagrees with the Applicants. The Examiner respectfully submits that Preschern disclosed (Preschern page 10, left column, first paragraph of Section F): “We implemented a prototype using openSAFETY as a black channel protocol of the communication between the engineering software and the PLC. openSAFETY is a safety certified open source protocol (implementation provided by IZZAT1) that fullfills the requirements for black channel communication. Our security layer uses a simple SHA-1 algorithm to hash the program memory of the safety layer and the PLC engineering application. A timestamp is appended to the hash value in order to counter replay attacks. The hash, the timestamp, and any application data (PLC commands, PLC program updates) are encrypted using the White-Box AES Project2 implementation, which uses the algorithms described in [6]. The encrypted data is embedded into the openSAFETY payload as shown in Figure 3.” Accordingly, Applicant’s statement that “…the alleged previously-calculated CHF digest of Preschern is contained in a separate openSAFETY frame that is sent via a secured black channel separately from the alleged executable program”, appears to be incorrect.
Applicant’s argument: Applicant further submits that amended claim 1 further distinguishes over Preschern. For example, claim 1 recites launching an executable program, the executable program including a secure program component stored in an executable program memory of a first computing device and one or more system-accessible components stored in the executable program memory of the first computing device. In contrast, the cited operations performed by Preschern' s PLC software are performed by a security layer of the PLC stack that is separate from its executable program memory. (See, e.g., Fig. 4. And related description:). This is done in order to protect the PLC from malicious commands sent to it by the PLC engineering tool. This is essential to Preschern's intended operation. The cited attestation features of Preschern are necessary prerequisites to launching the alleged executable program (the command or update sent to the PLC from the PLC engineering tool). They are also not stored in executable program memory along with system accessible components as per claim 1. Furthermore, Preschern cannot be modified or combined with other art to account for these features without compromising its security features, rendering it inoperative for its intended operations.
The Examiner disagrees with the Applicants. Preschern disclosed (Preschern page 10, left column, first paragraph of Section F): “We implemented a prototype using openSAFETY as a black channel protocol of the communication between the engineering software and the PLC. openSAFETY is a safety certified open source protocol (implementation provided by IZZAT1) that fullfills the requirements for black channel communication. Our security layer uses a simple SHA-1 algorithm to hash the program memory of the safety layer and the PLC engineering application. A timestamp is appended to the hash value in order to counter replay attacks. The hash, the timestamp, and any application data (PLC commands, PLC program updates) are encrypted using the White-Box AES Project2 implementation, which uses the algorithms described in [6]. The encrypted data is embedded into the openSAFETY payload as shown in Figure 3.” Accordingly, Applicant’s statement that “…the alleged previously-calculated CHF digest of Preschern is contained in a separate openSAFETY frame that is sent via a secured black channel separately from the alleged executable program”, appears to be incorrect.
The Examiner respectfully suggests that the claim be further amended; details in the specification be incorporated, to distinguish the claimed invention over prior art of record. Should the Applicant desire an interview to further clarify the claim interpretation/rejections, please contact the Examiner at (571) 272-2642 to schedule an interview.
Claim Interpretation - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as "configured to" or "so that"; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “cryptographic hash function (CHF) calculator configured to calculate,” “white-box component (WBC) generator configured to create” and “CLA package generator configured to provide” recited in claim 14.
Because these claim limitation(s) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 14-17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Independent claim 14 is directed to a system, and while the claim properly recites embodiments performing corresponding functions (i.e., “CHF calculator configured to calculate …;” “WBC generator configured to create …” and “CLA package generator configured to provide…”), the claim also recites active steps of a method claim (i.e., storing the CLA package…; launching the CLA package … and calculating CHF digest). Dependent claims 15-17 inherit such deficiencies via their dependencies.
A claim is considered indefinite under 35 U.S.C. 112(b) or 35 U.S.C. § 112 (pre-AIA ), second paragraph, if it does not reasonably apprise those skilled in the art of its scope. See MPEP 2173.05(p) and IPXL Holdings, 430 F.3d at 1384; See also In re Katz Interactive Call Processing Patent Litig., 639 F.3d 1303 (Fed. Cir. 2011) and Ex Parte Lyell, 17 USPQ2d 1548 (BPAI 1990) at 1550-51.") for details.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-17 are rejected under 35 U.S.C. 103 as being unpatentable over by Preschern et al. (“Preschern,” "Software-based remote attestation for safety-critical systems." In 2013 IEEE Sixth International Conference on Software Testing, Verification and Validation Workshops, pp. 8-12. IEEE, 2013), in view of Schweiker et al. (“Schweiker”; US20210278816A1).
Per claim 1: Preschern disclosed a process for certificateless securely authenticating an executable program (Preschern page 11, left column, FIG. 5), the process comprising:
launching an executable program, the executable program including a secure program component (Preschern page 11, left column, FIG. 5, “A user invokes a PLC command with the PLC engineering software”) ;
in response to a post-launch authentication trigger (Preschern page 11, left column, FIG. 5, “A user invokes a PLC command with the PLC engineering software”; Preschern page 8, right column, last paragraph, “the integrity and functionality of the PLC program is checked on the PLC after the program is deployed”), calculating using the secure program component a cryptographic hash function (CHF) digest of at least a portion of the executable program (Preschern page 9, right column, second last paragraph, “implement a simple hash algorithm which checks the application integrity by hashing the program code of the software running above the security layer”; Preschern page 10, left column, second last paragraph, “Our security layer uses a simple SHA-1 algorithm to hash the program memory of the safety layer and the PLC engineering application. A timestamp is appended to the hash value in order to counter”);
accessing using the secure program component a previously-calculated CHF digest of said at least the portion of the executable program contained in a white-box data structure of the executable program (Preschern page 10, left column, “For our attestation …” paragraph, “PLC is now equipped with a cryptographic key to be able to ensure the authenticity of the integrity measure. The same key is used with white-box cryptography by the PLC engineering software to encrypt the integrity measure before sending it to the PLC.”); comparing using the secure program component the CHF digest and the previously-calculated CHF digest (Preschern page 11, left column, FIG. 5, “Check the hash value against a pre-known reference value”); and
in response to the comparing indicating equality of the CHF digest and the previously-calculated CHF digest, authorizing an operation of the executable program (Preschern page 9, right column, “If a user…” paragraph, “If the PLC can successfully verify the attestation message, it carries out the user action.”).
Preschen appears to (i.e., may) disclose the secure program component stored in an executable program memory of a first computing device (Preschern page 10, right column, within the “If a user wants …” paragraph, “program memory”) and one or more system-accessible components stored in the executable program memory of the first computing device (Preschern page 10, right column, within the “If the user wants…” paragraph, “If a user wants to trigger an action (e.g., PLC program update, or control command) on the PLC by using the PLC engineering software, an attestation message is composed by the PLC engineering software and checked by the PLC. The attestation message is embedded in the open SAGETY frame and contains the SHA-1 hash of the program memory and a timestamp.” [Note: Applicant’s Original Drawings FIG. 2, disclosed an “Authentication Trigger”, “Calling Component” and “Other Components” as “System-Accessible Components 220”. Accordingly, Preschern’s “trigger” and “attestation message” appear to (i.e., may) be interpretable as the claimed “Authentication Trigger” and/or “Calling Component”.)
However, in an analogous art, Schweiker definitively disclosed a secure program component stored in an executable program memory of a first computing device and one or more system-accessible components stored in the executable program memory of the first computing device (Schweiker para. [0070], “Fail-safety of the communication may be ensured by the interaction of the local safety instance 38 of the automation system 10 and the second safety instance 41 of the external security device via Black-Channel-Principal.”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify Preschern to include, as taught by Schweiker, a secure program component stored in an executable program memory of a first computing device and one or more system-accessible components stored in the executable program memory of the first computing device. Motivation for modifying would have been to provide an intra-network distribution of a safety-oriented program on two device components, in order to provide increased safety, and increased attractiveness and broadened adoption of the Preschern/Schweiker combination within the security field.
Per claim 2: The Preschern/Schweiker combination disclosed the process of claim 1. Preschern further disclosed an arrangement wherein the post-launch authentication trigger (Preschern page 11, left column, FIG. 5, “A user invokes a PLC command with the PLC engineering software”; Preschern page 8, right column, last paragraph, “the integrity and functionality of the PLC program is checked on the PLC after the program is deployed”) initiates an authentication procedure including the calculating as one of an immediate post-launch operation, and an immediate and exclusive post-launch operation (Preschern page 11, left column, FIG. 5, aggregation of the steps performed by the “PLC engineering software” and “PLC”).
Per claim 3: The Preschern/Schweiker combination disclosed the process of claim 1. Preschern further disclosed an arrangement wherein the calculating includes calculating the CHF digest of the entirety of the executable program (Preschern page 9, right column, second last paragraph, “implement a simple hash algorithm which checks the application integrity by hashing the program code of the software running above the security layer”; Preschern page 10, left column, second last paragraph, “Our security layer uses a simple SHA-1 algorithm to hash the program memory of the safety layer and the PLC engineering application. A timestamp is appended to the hash value in order to counter”).
Per claim 4: The Preschern/Schweiker combination disclosed the process of claim 1. Preschern further disclosed an arrangement wherein the accessing includes using a key to access the previously- calculated CHF digest contained in the white-box data structure (Preschern page 10, right column, “If a user…” paragraph, “Intel Centrino2 2x2.53GHz processor”; Preschern page 11, left column, FIG. 5, “Decrypt payload using the pre-known AES key” and “Check the hash value against a pre-known reference value” ).
Per claim 5: The Preschern/Schweiker combination disclosed the process of claim 1. Preschern further disclosed an arrangement wherein the authorizing comprises at least one of: permitting continued execution of the executable program, and permitting the executable program to one of access and utilize a secure resource (Preschern page 9, right column, “If a user…” paragraph, “If the PLC can successfully verify the attestation message, it carries out the user action.”).
Per claim 6: The Preschern/Schweiker combination disclosed an apparatus comprising a non-transitory memory medium configured to store a program executable by one or more processors to:
launch an executable program, the executable program including a secure program component (Preschern page 11, left column, FIG. 5, “A user invokes a PLC command with the PLC engineering software”) ;
in response to a post-launch authentication trigger, calculate using a secure component a cryptographic hash function (CHF) digest of at least a portion of the program (Preschern page 9, right column, second last paragraph, “implement a simple hash algorithm which checks the application integrity by hashing the program code of the software running above the security layer”; Preschern page 10, left column, second last paragraph, “Our security layer uses a simple SHA-1 algorithm to hash the program memory of the safety layer and the PLC engineering application. A timestamp is appended to the hash value in order to counter”);
access using the secure component a previously-calculated CHF digest of said at least the portion of the program contained in a white-box data structure of the program (Preschern page 10, left column, “For our attestation …” paragraph, “PLC is now equipped with a cryptographic key to be able to ensure the authenticity of the integrity measure. The same key is used with white-box cryptography by the PLC engineering software to encrypt the integrity measure before sending it to the PLC.”);
compare using the secure component the CHF digest and the previously-calculated CHF digest (Preschern page 11, left column, FIG. 5, “Check the hash value against a pre-known reference value”); and
if the CHF digest and the previously-calculated CHF digest compare as equal, authorize an operation of the executable program (Preschern page 9, right column, “If a user…” paragraph, “If the PLC can successfully verify the attestation message, it carries out the user action.”).
Preschen appears to (i.e., may) disclose the secure program component stored in an executable program memory of a first computing device (Preschern page 10, right column, within the “If a user wants …” paragraph, “program memory”) and one or more system-accessible components stored in the executable program memory of the first computing device (Preschern page 10, right column, within the “If the user wants…” paragraph, “If a user wants to trigger an action (e.g., PLC program update, or control command) on the PLC by using the PLC engineering software, an attestation message is composed by the PLC engineering software and checked by the PLC. The attestation message is embedded in the open SAGETY frame and contains the SHA-1 hash of the program memory and a timestamp.” [Note: Applicant’s Original Drawings FIG. 2, disclosed an “Authentication Trigger”, “Calling Component” and “Other Components” as “System-Accessible Components 220”. Preschern’s “trigger” and “attestation message” are being interpreted as the claimed “Authentication Trigger” and/or “Calling Component”.).
However, in an analogous art, Schweiker definitively disclosed a secure program component stored in an executable program memory of a first computing device and one or more system-accessible components stored in the executable program memory of the first computing device (Schweiker para. [0070], “Fail-safety of the communication may be ensured by the interaction of the local safety instance 38 of the automation system 10 and the second safety instance 41 of the external security device via Black-Channel-Principal.”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify Preschern to include, as taught by Schweiker, a secure program component stored in an executable program memory of a first computing device and one or more system-accessible components stored in the executable program memory of the first computing device. Motivation for modifying would have been to provide an intra-network distribution of a safety-oriented program on two device components, in order to provide increased safety, and increased attractiveness and broadened adoption of the Preschern/Schweiker combination within the security field.
Per claim 7: The Preschern/Schweiker combination disclosed the apparatus of claim 6. Preschern further disclosed an arrangement wherein the program is executable by the one or more processors to calculate the CHF digest in response to the program being launched (Preschern page 11, left column, FIG. 5, “A user invokes a PLC command with the PLC engineering software”; Preschern page 8, right column, last paragraph, “the integrity and functionality of the PLC program is checked on the PLC after the program is deployed”; Preschern page 9, right column, second last paragraph, “implement a simple hash algorithm which checks the application integrity by hashing the program code of the software running above the security layer”; Preschern page 10, left column, second last paragraph, “Our security layer uses a simple SHA-1 algorithm to hash the program memory of the safety layer and the PLC engineering application. A timestamp is appended to the hash value in order to counter”).
Per claim 8: The Preschern/Schweiker combination disclosed the apparatus of claim 6. Preschern further disclosed an arrangement wherein the program is executable by one or more processors to calculate the CHF digest of the entirety of the program (Preschern page 9, right column, second last paragraph, “implement a simple hash algorithm which checks the application integrity by hashing the program code of the software running above the security layer”; Preschern page 10, left column, second last paragraph, “Our security layer uses a simple SHA-1 algorithm to hash the program memory of the safety layer and the PLC engineering application. A timestamp is appended to the hash value in order to counter”).
Per claim 9: The Preschern/Schweiker combination disclosed the apparatus of claim 8. Preschern further disclosed an arrangement wherein the program is executable by one or more processors to access the previously-calculated CHF digest using a key contained in the secure component (Preschern page 10, right column, “If a user…” paragraph, “Intel Centrino2 2x2.53GHz processor”; Preschern page 11, left column, FIG. 5, “Decrypt payload using the pre-known AES key” and “Check the hash value against a pre-known reference value”).
Per claim 10: The Preschern/Schweiker combination disclosed the apparatus of claim 9. Preschern further disclosed an arrangement wherein the program is executable by one or more processors to authorize comprises at least one of: the program being executable by one or more processors to permit continued execution of the executable program, and the program being executable by one or more processors to permit the executable program to one of access and utilize a secure resource (Preschern page 9, right column, “If a user…” paragraph, “If the PLC can successfully verify the attestation message, it carries out the user action.”).
Per claim 11: Preschern disclosed a process for creating an executable program package capable of certificateless authentication (CLA package) (Preschern page 11, left column, FIG. 5), the process comprising:
calculating a cryptographic hash function (CHF) digest at least a portion of the CLA package (Preschern page 9, right column, second last paragraph, “implement a simple hash algorithm which checks the application integrity by hashing the program code of the software running above the security layer”; Preschern page 10, left column, second last paragraph, “Our security layer uses a simple SHA-1 algorithm to hash the program memory of the safety layer and the PLC engineering application. A timestamp is appended to the hash value in order to counter”);
creating a white-box data structure including the CHF digest cryptographically associated with the at least the portion of the CLA package via a white-box cryptography technique (Preschern page 10, left column, “For our attestation …” paragraph, “PLC is now equipped with a cryptographic key to be able to ensure the authenticity of the integrity measure. The same key is used with white-box cryptography by the PLC engineering software to encrypt the integrity measure before sending it to the PLC.”); and
providing the CLA package including the CHF digest cryptographically associated with the at least the portion of the CLA package (Preschern page 9, the first paragraph within the “B. Attack Scenario” section, “The PLC just accepts commands and PLC program updates sent over a secure channel by an authenticated PLC engineering software”; Preschern page 10, right column, first full paragraph, “If a user wants to trigger an action (e.g. PLC program update, or control command) on the PLC by using the PLC engineering software, an attestation message is composed by the PLC engineering software and checked by the PLC.”) including communicating the CLA package to a registrar and receiving a token or tokened claim generated by the registrar Preschern page 10, left column, first full para., “PLC is now equipped with a cryptographic key to be able to ensure the authenticity of the integrity measure”; [NOTE: Preschern’s “PLA” is being interpreted as a “registrar”.]; Preschern’s page 10, left column, first full paragraph, “For our attestation concept, the PLC is now equipped with a cryptographic key to be able to ensure the authenticity of the integrity measure. The same key is used with white-box cryptography by the PLC engineering software to encrypt the integrity measure before sending it to the PLC.”; [NOTE: Same hash keys are used by sender/recipeints in order to confirm security/authentication via hash comparison. Further, Applicant’s August 25, 2025’s page 7 Response comment admits, “vii) the PLC checks the decrypted hash value against a ‘pre-known reference value’ “. Still further, Applicant’s original specification at paragraph [0017], states, “It shall be appreciated that the term digest refers to data output in response to input provided to a cryptographic hash function (CHF) which that maps an input of arbitrary size to an output of fixed size (i.e., the digest, sometimes also referred to as the hash or hash value) in a deterministic manner.”]; Preschern’s page 10, right column, last paragraph, “If the application integrity is tampered with and the attestation procedure fails, the PLC security layer does not shut down the PLC programs, but just indicates that the integrity check failed.”; [NOTE: Preschern’s PLC’s “indication that the integrity check failed” is being interpreted as a “tokened claim generated by the registrar”].);
launching the CLA package (Preschern page 11, left column, FIG. 5, “A user invokes a PLC command with the PLC engineering software”); and
in response to a post-launching authentication trigger, calculating using the secure program component a cryptographic hash function (CHF) digest of at least a portion of the executable program (Preschern page 10, right column, within the “If a user wants …” paragraph, “program memory”) and one or more system-accessible components stored in the executable program memory of the first computing device (Preschern page 10, right column, within the “If the user wants…” paragraph, “If a user wants to trigger an action (e.g., PLC program update, or control command) on the PLC by using the PLC engineering software, an attestation message is composed by the PLC engineering software and checked by the PLC. The attestation message is embedded in the open SAGETY frame and contains the SHA-1 hash of the program memory and a timestamp.” [Note: Applicant’s Original Drawings FIG. 2, disclosed an “Authentication Trigger”, “Calling Component” and “Other Components” as “System-Accessible Components 220”. Preschern’s “trigger” and “attestation message” are being interpreted as the claimed “Authentication Trigger” and/or “Calling Component”.; Preschern FIG. 5, second and third operation of the “PLC” column, “Decrypt payload using the pre-known AES key” and “Check the hash value against a pre-known reference value”.).
Preschen appears to (i.e., may) disclose storing the CLA package in an executable program memory (Preschern page 10, right column, within the “If a user wants …” paragraph, “program memory”) of a computing device in combination with one or more system-accessible components stored in the executable program memory of the first computing device (Preschern page 10, right column, within the “If the user wants…” paragraph, “If a user wants to trigger an action (e.g., PLC program update, or control command) on the PLC by using the PLC engineering software, an attestation message is composed by the PLC engineering software and checked by the PLC. The attestation message is embedded in the open SAGETY frame and contains the SHA-1 hash of the program memory and a timestamp.” [Note: Applicant’s Original Drawings FIG. 2, disclosed an “Authentication Trigger”, “Calling Component” and “Other Components” as “System-Accessible Components 220”. Preschern’s “trigger” and “attestation message” are being interpreted as the claimed “Authentication Trigger” and/or “Calling Component”.).
However, in an analogous art, Schweiker definitively disclosed storing the CLA package in an executable program memory of a computing device in combination with one or more system-accessible components stored in the executable program memory of the first computing device (Schweiker para. [0070], “Fail-safety of the communication may be ensured by the interaction of the local safety instance 38 of the automation system 10 and the second safety instance 41 of the external security device via Black-Channel-Principal.”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify Preschern to include, as taught by Schweiker, storing the CLA package in an executable program memory of a computing device in combination with one or more system-accessible components stored in the executable program memory of the first computing device. Motivation for modifying would have been to provide an intra-network distribution of a safety-oriented program on two device components, in order to provide increased safety, and increased attractiveness and broadened adoption of the Preschern/Schweiker combination within the security field.
Per claim 12: The Preschern/Schweiker combination disclosed the process of claim 11. Preschern further disclosed an arrangement wherein said at least the portion of the CLA package includes the entirety of the CLA package (Preschern page 9, right column, second last paragraph, “implement a simple hash algorithm which checks the application integrity by hashing the program code of the software running above the security layer”; Preschern page 10, left column, second last paragraph, “Our security layer uses a simple SHA-1 algorithm to hash the program memory of the safety layer and the PLC engineering application. A timestamp is appended to the hash value in order to counter”).
Per claim 13: The Preschern/Schweiker combination disclosed the process of claim 11. Preschern further disclosed an arrangement wherein the calculating is performed on a secure development and the creating the white-box data structure is performed on a white-box cryptography in operative communication with the secure development (Preschern page 11, FIG. 4; Preschern page 9, right column, second last paragraph, “black channel safety layer”; Preschern page 10, left column, “We implemented …” paragraph, “openSAFETY as a black channel protocol”; Preschern page 11, right column, last paragraph, “We presented a software-based remote attestation concept using a black channel protocol, white-box cryptography,”.
Preschern does not explicitly disclose an arrangement wherein the calculating is performed on a secure development platform, and the white-box cryptography platform is in operative communication with the secure development platform.
However, in an analogous art, Schweiker disclosed an arrangement wherein calculating is performed on a secure development platform, which provides operative communication with an external device (Schweiker para. [0017], “The platform can be a software, a hardware or a virtual platform that serves as the basis for the development and execution of user programs”; Schweiker para. [0070], “Fail-safety of the communication may be ensured by the interaction of the local safety instance 38 of the automation system 10 and the second safety instance 41 of the external security device via Black-Channel-Principal”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify Preschern to include, as taught by Schweiker, an arrangement wherein calculating is performed on a secure development platform, which provides operative communication with an external device. Motivation for modifying would have been to increase security of the arrangement, and thus broadened adoption of the Preschern/ Schweiker combination within the communications security field.
Per claim 14: Preschern disclosed a system (Preschern page 11, left column, FIG. 5) for creating an executable program package capable of certificateless authentication (CLA package), the system comprising:
a cryptographic hash function (CHF) calculator configured to calculate a CHF digest of at least a portion of the CLA package (Preschern page 9, right column, second last paragraph, “implement a simple hash algorithm which checks the application integrity by hashing the program code of the software running above the security layer”; Preschern page 10, left column, second last paragraph, “Our security layer uses a simple SHA-1 algorithm to hash the program memory of the safety layer and the PLC engineering application. A timestamp is appended to the hash value in order to counter”);
a white-box component (WBC) generator configured to create a white-box data structure including the CHF digest cryptographically associated with the at least the portion of CLA package using a white-box cryptography technique (Preschern page 10, left column, “For our attestation …” paragraph, “PLC is now equipped with a cryptographic key to be able to ensure the authenticity of the integrity measure. The same key is used with white-box cryptography by the PLC engineering software to encrypt the integrity measure before sending it to the PLC.”); and
a CLA package generator configured to provide the CLA package including the CHF digest cryptographically associated with the at least the portion of the CLA package (Preschern page 9, the first paragraph within the “B. Attack Scenario” section, “The PLC just accepts commands and PLC program updates sent over a secure channel by an authenticated PLC engineering software”; Preschern page 10, right column, first full paragraph, “If a user wants to trigger an action (e.g. PLC program update, or control command) on the PLC by using the PLC engineering software, an attestation message is composed by the PLC engineering software and checked by the PLC.”; Preschern page 11, left column, FIG. 5, “Construct an openSAFETY frame containing the encrypted hash and timestamp and the user command.”) including to provide the CLA package to a registrar and to receive a token or tokened claim generated by the registrar (Preschern page 10, left column, first full para., “PLC is now equipped with a cryptographic key to be able to ensure the authenticity of the integrity measure”; [NOTE: Preschern’s “PLA” is being interpreted as a “registrar”.]; Preschern’s page 10, left column, first full paragraph, “For our attestation concept, the PLC is now equipped with a cryptographic key to be able to ensure the authenticity of the integrity measure. The same key is used with white-box cryptography by the PLC engineering software to encrypt the integrity measure before sending it to the PLC.”; [NOTE: Same hash keys are used by sender/recipeints in order to confirm security/authentication via hash comparison. Further, Applicant’s August 25, 2025’s page 7 Response comment admits, “vii) the PLC checks the decrypted hash value against a ‘pre-known reference value’ “. Still further, Applicant’s original specification at paragraph [0017], states, “It shall be appreciated that the term digest refers to data output in response to input provided to a cryptographic hash function (CHF) which that maps an input of arbitrary size to an output of fixed size (i.e., the digest, sometimes also referred to as the hash or hash value) in a deterministic manner.”]; Preschern’s page 10, right column, last paragraph, “If the application integrity is tampered with and the attestation procedure fails, the PLC security layer does not shut down the PLC programs, but just indicates that the integrity check failed.”; [NOTE: Preschern’s PLC’s “indication that the integrity check failed” is being interpreted as a “tokened claim generated by the registrar”].); and
launching the CLA package (Preschern page 11, left column, FIG. 5, “A user invokes a PLC command with the PLC engineering software”); and
in response to a post-launching authentication trigger, calculating using the secure program component a cryptographic hash function (CHF) digest of at least a portion of the executable program (Preschern page 10, right column, within the “If a user wants …” paragraph, “program memory”) and one or more system-accessible components stored in the executable program memory of the first computing device (Preschern page 10, right column, within the “If the user wants…” paragraph, “If a user wants to trigger an action (e.g., PLC program update, or control command) on the PLC by using the PLC engineering software, an attestation message is composed by the PLC engineering software and checked by the PLC. The attestation message is embedded in the open SAGETY frame and contains the SHA-1 hash of the program memory and a timestamp.” [Note: Applicant’s Original Drawings FIG. 2, disclosed an “Authentication Trigger”, “Calling Component” and “Other Components” as “System-Accessible Components 220”. Preschern’s “trigger” and “attestation message” are being interpreted as the claimed “Authentication Trigger” and/or “Calling Component”.; Preschern FIG. 5, second and third operation of the “PLC” column, “Decrypt payload using the pre-known AES key” and “Check the hash value against a pre-known reference value”.).
Preschen appears to (i.e., may) disclose storing the CLA package in an executable program memory (Preschern page 10, right column, within the “If a user wants …” paragraph, “program memory”) of a computing device in combination with one or more system-accessible components stored in the executable program memory of the first computing device (Preschern page 10, right column, within the “If the user wants…” paragraph, “If a user wants to trigger an action (e.g., PLC program update, or control command) on the PLC by using the PLC engineering software, an attestation message is composed by the PLC engineering software and checked by the PLC. The attestation message is embedded in the open SAGETY frame and contains the SHA-1 hash of the program memory and a timestamp.” [Note: Applicant’s Original Drawings FIG. 2, disclosed an “Authentication Trigger”, “Calling Component” and “Other Components” as “System-Accessible Components 220”. Preschern’s “trigger” and “attestation message” are being interpreted as the claimed “Authentication Trigger” and/or “Calling Component”.).
However, in an analogous art, Schweiker definitively disclosed storing the CLA package in an executable program memory of a computing device in combination with one or more system-accessible components stored in the executable program memory of the first computing device (Schweiker para. [0070], “Fail-safety of the communication may be ensured by the interaction of the local safety instance 38 of the automation system 10 and the second safety instance 41 of the external security device via Black-Channel-Principal.”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify Preschern to include, as taught by Schweiker, storing the CLA package in an executable program memory of a computing device in combination with one or more system-accessible components stored in the executable program memory of the first computing device. Motivation for modifying would have been to provide an intra-network distribution of a safety-oriented program on two device components, in order to provide increased safety, and increased attractiveness and broadened adoption of the Preschern/Schweiker combination within the security field.
Per claim 15: The Preschern/Schweiker combination disclosed the system of claim 14. Preschern further disclosed an arrangement wherein wherein said at least the portion of the CLA package includes the entirety of the CLA package (Preschern page 9, right column, second last paragraph, “implement a simple hash algorithm which checks the application integrity by hashing the program code of the software running above the security layer”; Preschern page 10, left column, second last paragraph, “Our security layer uses a simple SHA-1 algorithm to hash the program memory of the safety layer and the PLC engineering application. A timestamp is appended to the hash value in order to counter”).
Per claim 16: The Preschern/Schweiker combination disclosed the system of claim 14. Preschern further disclosed an arrangement wherein the cryptographic hash function (CHF) calculator is provided as a component of the CLA package generator (Preschern page 11, FIG. 4, “Safety Layer (openSAFETY)” and “Security Layer white-box AES SHA-1”; Preschern page 11, FIG. 5, “Calculate SHA-1 hash of the PLC engineering application”, “Encrypt the hash value and a timestamp by using white-box AES” and “Construct an openSAFETY frame containing the encrypted hash and timestamp and the user command”).
Per claim 17: The Preschern/Schweiker combination disclosed the system of claim 14. Preschern further disclosed an arrangement wherein the CLA package generator is provided on a secure development platform and the WBC generator is provided on a white-box cryptography platform in operative communication with the secure development platform (Preschern page 11, FIG. 4; Preschern page 9, right column, second last paragraph, “black channel safety layer”; Preschern page 10, left column, “We implemented …” paragraph, “openSAFETY as a black channel protocol”; Preschern page 11, right column, last paragraph, “We presented a software-based remote attestation concept using a black channel protocol, white-box cryptography,”; [It is the PTO’s position that a “platform” may be software and/or virtual (Schweiker para. 0017, “The platform can be a software, a hardware or a virtual platform”; see also para. 0070]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Paul J Skwierawski whose telephone number is (571)272-2642. The examiner can normally be reached 6:00am-3:30pm weekdays.
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 supervisory primary examiner (SPE) Luu Pham can be reached on (571) 270-5002. 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.
/Paul Skwierawski/
Patent Examiner, Art Unit 2439
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights