DETAILED ACTION
This final office action is in response to claims 1-12 and 15-22 filed on 03/23/2026 for examination. Claims 1-12 and 15-22 are being examined and are pending.
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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Response to Amendment
The amendment filed March 23, 2026 has been entered. Claims 1-12 and 15-16 remain pending in the application. Claims 17-22 are new. The claims have been amended. Applicant’s arguments and amendments to the claims have overcome each and every claim objection, 35 U.S.C. 112 rejection, and 35 U.S.C. 101 rejection previously set forth in the Non-Final Office Action mailed September 23, 2025. Claims 1-12 and 15-16 have been amended and have necessitated a new ground(s) of rejection in this Office Action. Further, Applicant’s arguments regarding claims 1-12 and 15-22 have been fully considered but are not persuasive to differentiate over the prior art. Particularly:
First: Applicant opines Abera et al. (NPL: “C-FLAT: Control-Flow Attestation for Embedded Systems Software; August 17, 2016) fails to disclose “receiving by the network client a copy of the computer program”. Remarks, pg. 7. Applicant notes Abera teaches installing the computer program on the remote system <i.e., network client>. Id. Applicant appears to argue that a remote device running an installed computer program did not receive said computer program. Id. Applicant argues the computer program may have been received and installed at an earlier time. Id. Examiner notes that what Applicant appears to be arguing also constitutes “receiving by the network client a copy of the computer program”. For at least this reason, Applicant’s associated remarks are unpersuasive. Further: One of ordinary skill in the art before the effective filing date of the claimed invention would clearly recognize that the remote devices of Abera have received (and execute) the computer program (e.g., the syringe control program). See, e.g., Abera at § 5.1 and 6.1. In reviewing the cited reference, Applicant should note that a reference may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. MPEP 2123. In view of the foregoing, Applicant’s associated remarks are unpersuasive.
Next, Applicant opines Abera fails to teach “generating by the network a digital signature of at least a final state of the computer program”. Remarks, pgs. 7-8. Applicant remarks that Applicant’s “final state” includes specific types of data values in the program, which is allegedly different than Abera’s “final state” (which Applicant opines does not include the specific types of data values). Id. However, no such limitation is present in the claim. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., final state including non-program execution ancillary data) 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 In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). In Abera, the final execution stage is a “final state”. See, e.g., Abera at § 4.1, 1, and 3-3.1. In detail: Each prior hash is a result of measurements representing the computer program’s execution at different stages <i.e., states> on the device. Id. A digital signature of the final hash <i.e., final state> is generated using the most recent output of an execution path chain. Id. E.g., the final state N5 takes as input/is based on the prior executions H(H2, N4), which took as input H(H1, N2), etc. Id. In other words: Aberu teaches wherein the final state <N5> comprises a memory snapshot or a collection of values of program variables at conclusion of the execution of the computer program <as the value of N5 represents a snapshot of the program’s execution path through N4, N2, etc.>. Accordingly, Abera teaches “generating by the network client a digital signature of at least a final state of the computer program with the client private key, wherein the final state comprises at least a memory snapshot or a collection of values of program variables at conclusion of the computer program.” Applicant’s associated remarks are unpersuasive.
Further: Applicant opines Abera fails to teach “transmitting by the network client the digital signature of the final state for validation of the execution of the computer program”. Remarks, pgs. 8-9. Applicant opines that Applicant’s verification step is different than the verification step of Abera, and opines different uses can be achieved with their system (e.g., preventing non-control data attacks). Id. However, no such limitation is present in the claim. In response to Applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., limiting the verification to preventing non-control data attacks, etc.) 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 In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). In Abera, the final execution stage is a “final state”. See, e.g., Abera at § 4.1, 1, and 3-3.1. In detail: Hashes are generated during execution of a computer program by the remote device <i.e., network client>. Id. The hashes are a result of measurements representing the computer program’s execution at different stages <i.e., states> on the device. Id. A digital signature of the final hash <i.e., final state> is generated using the remote system’s secret <i.e., private> key. Id. The signature is sent <i.e., transmitted> to the verifying authority. Id. The verifying authority then verifies the signature to verify execution of the computer program. Id. Accordingly, Abera teaches “transmitting by the network client the digital signature of the final state for validation of the execution of the computer program”. Applicant’s associated remarks are unpersuasive.
Regarding claim 16: Applicant opines there is no motivation to combine Abera and Sel. Remarks, pgs. 10-11. Applicant opines Abera provides a method for runtime control-flow attestation, while Sel teaches a system for integrity testing – and therefore, Applicant opines, there is no motivation to combine. Id. Examiner disagrees. Abera teaches a technique for ensuring proper of a computer program. Abera at § 4.1, 1, and 3-3.1. Sel also teaches a technique for ensuring proper execution of a computer program. Sel at abstract, [0025-027]. The known technique of Sel is applicable to the system of Abera as they both share similar characteristics and capabilities, namely, they are both directed to improving security/integrity of computer programs. See, e.g., Abera at § 4.1, 1, and 3-3.1; with Sel at abstract, [0025-027]. E.g., Sel teaches a system for auditing execution of a computer program (see, e.g., abstract), receiving by the network client a genesis hash ([0079-081], [0025-026], and [0059]), characterized in that the method comprises: determining by the network client the first state hash from at least the corresponding state and the received genesis hash ([0079-081], [0025-026], and [0059]). See as detailed further hereinbelow with regards to 35 U.S.C. 103. One of ordinary skill in the art would have recognized that applying the known token technique of Sel to the system of Abera would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Sel to the system of Abera would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references shows the ability to incorporate random seeds to solve the problem of freshness. In view of the foregoing, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Abera with the teachings of Sel to receive the genesis hash. Particularly comprising: receiving by the network client a genesis hash, characterised in that the method comprises: determining by the network client the first state hash from at least the corresponding intermediary state and the received genesis hash, to improve reliability of the integrity tests (see, e.g., Sel at [0025-026] and [0079-081]). Applicant’s associated remarks are unpersuasive.
Additionally: Applicant opines the “seed value” of Applicant’s claim 16/disclosure serves a different technical purpose than the “seed value” of Sel. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., the seed value’s specific opined “reproducibility” benefits that differ from Sel) 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 In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Applicant’s associated remarks are unpersuasive.
In view of the foregoing, as well as hereinbelow with regards to 35 U.S.C. 103, applicant’s arguments regarding claims 1-12 and 15-22 have been fully considered but are not persuasive to differentiate over the prior art.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-3 and 15 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Abera et al. (NPL: “C-FLAT: Control-Flow Attestation for Embedded Systems Software”; August 17, 2016; hereinafter “Abera”).
Regarding claim 1, Abera teaches a method for provable remote execution of a computer program by a network client having a client private key (§ 1 and 4.1 – a remote system <i.e., network client> attests to an execution flow of a computer program. The remote system has a remote system secret <i.e., private> key), the method comprising the steps of:
receiving by the network client a copy of the computer program (§ 5.1 and 6.1 – the remote system comprises a computer program <i.e., received a copy of a computer program>. E.g., syringe pumps may have a syringe control program installed <i.e., received a copy of a computer program>),
executing by the network client the computer program (§ 5.1 and 6.1 – the computer program is executed. E.g., a syringe control program is executed),
generating by the network client a digital signature of at least a final state of the computer program with the client private key (§ 4.1, 1, and 3-3.1 – Hashes are generated during execution of a computer program by the remote device <i.e., network client>. The hashes are a result of measurements representing the computer program’s execution at different stages <i.e., states> on the device. A digital signature of the final hash <i.e., final state> is generated using the remote system’s secret <i.e., private> key. The signature is sent <i.e., transmitted> to the verifying authority), wherein the final state comprises at least a memory snapshot or a collection of values of program variables at conclusion of the execution of the computer program (§ 4.1, 1, and 3-3.1. Each prior hash is a result of measurements representing the computer program’s execution at different stages <i.e., states> on the device. A digital signature of the final hash <i.e., final state> is generated using the most recent output of an execution path chain. E.g., the final state N5 takes as input/is based on the prior executions H(H2, N4), which took as input H(H1, N2), etc. I.e., Aberu teaches wherein the final state <N5> comprises a memory snapshot or a collection of values of program variables at conclusion of the execution of the computer program <as the value of N5 represents a snapshot of the program’s execution path through N4, N2, etc.>),
transmitting by the network client the digital signature of the final state for validation of the execution of the computer program (§ 4.1, 1, and 3-3.1. Hashes are generated during execution of a computer program by the remote device <i.e., network client>. Id. The hashes are a result of measurements representing the computer program’s execution at different stages <i.e., states> on the device. A digital signature of the final hash <i.e., final state> is generated using the remote system’s secret <i.e., private> key. The signature is sent <i.e., transmitted> to the verifying authority. The verifying authority then verifies the signature to verify execution of the computer program).
Regarding claim 2, Abera teaches the method according to claim 1, characterised in that executing the computer program comprises the step of determining by the network client a state hash of at least one intermediary state of the computer program (§ 4.1-4.2, 5.1, and 3-3.1 – A plurality of hashes <e.g., H1, H2/intermediary hash, H3/intermediary hash, H4> are generated during execution of a computer program by the remote device <i.e., network client>. Generated hashes are a result of measurements representing the computer program’s execution at different stages <i.e., states> in combination with a previously preceding hash <i.e., intermediate hashes> in the chain. A final hash is generated based on measurements representing the computer program’s final stage of execution and the previously preceding hash in the chain <i.e., intermediate hash>. A digital signature of the final hash <i.e., final state> is generated), wherein the digital signature generated by the network client is based on the final state and the state hash of the intermediary state (§ 4.1-4.2, 5.1, and 3-3.1 – A plurality of hashes <e.g., H1, H2, H3, H4> are generated during execution of a computer program by the remote device <i.e., network client>. Generated hashes are a result of measurements representing the computer program’s execution at different stages <i.e., states> in combination with a previously preceding hash <i.e., intermediate hashes> in the chain. A final hash is generated based on measurements representing the computer program’s final stage of execution and the previously preceding hash in the chain <i.e., intermediate hash>. A digital signature of the final hash <i.e., final state> is generated).
Regarding claim 3, Abera teaches the the method according to claim 1, characterised in that the method comprises determining by the network client state hashes of at least two sequential intermediary states of the computer program, wherein a second state hash and every later state hash is computed from at least corresponding intermediary state and previous state hash (§ 4.1-4.2, 5.1, and 3-3.1 – A plurality of hashes <e.g., H1, H2/intermediaryhash1, H3/intermediaryhash2, H4> are generated during execution of a computer program by the remote device <i.e., network client>. Generated hashes are a result of sequential measurements representing the computer program’s execution at different stages <i.e., states> in combination with a previously preceding hash <i.e., intermediate hashes> in the chain. A final hash is generated based on measurements representing the computer program’s final stage of execution and the previously preceding hash in the chain <i.e., intermediate hash>. A digital signature of the final hash <i.e., final state> is generated).
Regarding claim 15, Abera teaches a a client device for provable remote execution of a computer program, the client device having a client private key (§ 1 and 4.1 – a remote system <i.e., network client> securely attests to an execution flow of a computer program. The remote system has a remote system secret <i.e., private> key), the client device configured to:
receive a copy of the computer program over a computer network (§ 5.1 and 6.1 – the remote system comprises a computer program <i.e., received a copy of a computer program>. E.g., syringe pumps may have a syringe control program installed <i.e., received a copy of a computer program>);
execute the computer program (§ 5.1 and 6.1 – the computer program is executed. E.g., a syringe control program is executed);
generate a digital signature of at least a final state of the computer program with the client private key (§ 4.1, 1, and 3-3.1 – Hashes are generated during execution of a computer program by the remote device <i.e., network client>. The hashes are a result of measurements representing the computer program’s execution at different stages <i.e., states> on the device. A digital signature of the final hash <i.e., final state> is generated using the remote system’s secret <i.e., private> key. The signature is sent <i.e., transmitted> to the verifying authority); and
transmit the digital signature of the final state for validation of the execution of the computer program over the computer network (§ 4.1, 1, and 3-3.1 – Hashes are generated during execution of a computer program by the remote device <i.e., network client>. The hashes are a result of measurements representing the computer program’s execution at different stages <i.e., states> on the device. A digital signature of the final hash <i.e., final state> is generated using the remote system’s secret <i.e., private> key. The signature is sent <i.e., transmitted> to the verifying authority. The verifying authority verifies the signature).
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.
Claim(s) 4, 6-12, 16, 18-19, and 21-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Abera in view of Sel (EP3525126A1; hereinafter “Sel”).
Regarding claim 4, Abera teaches the method according to claim 3, characterised in that the method comprises: determining by the network client the first state hash from at least the corresponding intermediary state and the [[received]] genesis hash (§ 4.1-4.2 – the first hash is a combination of a value 0 <i.e., genesis hash> and the first node stage N1 <i.e., state>. The node N1 is calculated as result of measurements representing the computer program’s execution; Note: Applicant’s specification provides “the “genesis hash” need not be an actual hash value and may be any value that can be used to initialize or “seed” the hash chain” at pg. 4. In Abera, “0” is a value used to initiate the hash chain, and therefore fits “genesis hash” as defined by Applicant).
Yet, Abera fails to specifically disclose receiving by the network client the genesis hash.
However, Sel teaches a similar system for auditing execution of a computer program (see, e.g., abstract), receiving by the network client a genesis hash ([0079-081], [0025-026], and [0059] – a seed value <i.e., genesis hash> may be produced on a server. The seed value may be provided to the remote device <i.e., network client receives a genesis hash>. The remote device uses the seed value <i.e., genesis hash> as input to the firmware <i.e., the computer program uses randomly generated data>, and a hash is generated based on the of the firmware execution and the seed value; Note: Applicant’s specification at pg. 4 providing “the “genesis hash” need not be an actual hash value and may be any value that can be used to initialize or “seed” the hash chain), characterised in that the method comprises: determining by the network client the first state hash from at least the corresponding state and the received genesis hash ([0079-081], [0025-026], and [0059] – The remote device <i.e., network client> uses the seed value <i.e., genesis hash> as input to the firmware <i.e., the computer program uses randomly generated data>. A hash is generated based on the of the firmware <i.e., computer program> execution and the seed value <i.e., the hash is a state hash of the execution>; Note: Applicant’s specification at pg. 4 providing “the “genesis hash” need not be an actual hash value and may be any value that can be used to initialize or “seed” the hash chain).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Abera with the teachings of Sel to receive the genesis hash. Particularly comprising: receiving by the network client a genesis hash, characterised in that the method comprises: determining by the network client the first state hash from at least the corresponding intermediary state and the received genesis hash, to improve reliability of the integrity tests (see, e.g., Sel at [0025-026] and [0079-081]).
Regarding claim 6, Abera teaches the method according to claim 1, characterised in that the computer program is configured to receive input data locally available at the network client during executing the computer program (Abera at § 6.1, 4.1-4.2, and 5.1 – A computer program may accept inputs during its runtime. E.g., the computer program may be a soldering iron temperature controller program on a soldering iron temperature controller <i.e., network client> that continuously reads the current temperature and uses the temperature as input to the program. The computer program responds to detected changes in temperature during the runtime), as well as provides the digital signature (Abera at § 4.1-4.2, and 3-3.1 – digital signature is provided to a verifier). Yet, Abera appears to fail to specifically disclose wherein the network client records the input data received and provides the recorded input data together with the digital signature.
However, Sel teaches a similar system for auditing execution of a computer program (see, e.g., abstract), wherein the computer program receives a locally available input (see, e.g., [0025], [0063], and [0079-081] – a locally available seed value is input to the firmware <i.e., computer program>), wherein the network client records the input data received and provides the recorded input data together with the digital fingerprint ([0025], [0063], and [0079-081] – a seed value is determined locally on a second device <i.e., network client> and subsequently utilized <i.e., seed value is recorded>. The seed value is used as input to firmware <i.e., seed value is an input to a computer program>. The seed value is then provided to a first device <e.g., a server> from the second device <i.e., network client> together with a verification fingerprint).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Abera with the teachings of Sel, wherein the network client records the input data received and provides the recorded input data together with the digital signature, so the verification authority may efficiently verify the program’s execution by recreating the execution flow at the verification authority (Sel at [0025], [0063-066], and [0079-085]).
Regarding claim 7, the combination of Abera and Sel teach the method according to claim 1, characterised in that the network client receives input data affecting the final state from a network during executing the computer program (Abera at § 6.4, 4.1-4.2, and 5.1 – A computer program may accept inputs during its runtime. E.g., the computer program may be a soldering iron temperature controller program that continuously reads the current temperature and uses the temperature as input to the program. The computer program responds to detected changes in temperature during the runtime. Hashes are generated during the runtime of the computer program based on the flow path <i.e., state> of the executing software <i.e., inputs affecting the flow path, such as needing to calculate temperature adjustments based on received input, are reflected in the verified hash values>; § 6.1 – input may be received, e.g., over a serial connection <i.e., network>; additionally see, e.g., Sel at [0079-085], and [0063] and [0025] – the seed/input data could be received from a first device at the second device over a network. The second device uses the input/seed as input to the firmware/computer program).
Regarding claim 8, the combination of Abera and Sel teach the method according to claim 7, characterised in that the network client expects to receive the input data affecting the final state from the network at one or more instances during executing the computer program, wherein said one or more instances are predefined or defined by the computer program (Abera at § 6.4, 4.1-4.2, and 5.1 – A computer program may read inputs during its runtime. E.g., the computer program may be a soldering iron temperature controller program that reads current temperatures during runtime and uses the temperatures as input to the computer program <i.e., computer program checks for the current temperature value at coded/predefined instances>. The computer program responds to detected changes in temperature during the runtime. Hashes are generated during the runtime of the computer program based on the flow path <i.e., state> of the executing software <i.e., inputs affecting the flow path, such as needing to calculate temperature adjustments based on received input>. A final hash is calculated and verified; § 6.1 – input may be received, e.g., over a serial connection <i.e., network>).
Regarding claim 9, the combination of Abera and Sel teach the method according to claim 8, characterised in that the expected input data is unpredictable during each execution of the computer program (Abera at § 6.4, 4.1-4.2, and 5.1 – A computer program may read inputs during its runtime. E.g., the computer program may be a soldering iron temperature controller program that reads current temperatures during runtime of the soldering iron and uses the temperatures as input to the computer program <i.e., the temperatures read are unpredictable/unique to each execution>. The computer program responds to detected changes in temperature during the runtime. Hashes are generated during the runtime of the computer program based on the flow path <i.e., state> of the executing software <i.e., inputs affecting the flow path, such as needing to calculate temperature adjustments based on received input, are reflected in the chained hash values>; § 6.1 – input may be received, e.g., over a serial connection <i.e., network>).
Regarding claim 10, Abera teaches the method according to claim 1. Yet, Abera appears to fail to specifically disclose wherein the method is characterised in that the computer program uses randomly generated data, wherein the randomly generated data is generated locally by the network client
However, Sel teaches a similar system for auditing execution of a computer program (see, e.g., abstract), characterised in that the computer program uses randomly generated data, wherein the randomly generated data is generated locally by the network client ([0079-081], [0025-026], and [0059] – a seed value <i.e., genesis seed> is produced based on, e.g., the time. At least part of the seed value may be randomized to produce a randomized seed. The remote device may locally produce the randomized seed value. The remote device uses the randomized seed as input to the firmware <i.e., the computer program uses the randomly generated data>. A hash is output by the remote device based on the firmware and the randomized seed <i.e., pseudorandomly generating more data locally, as the hash has a randomized input>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Abera with the teachings of Sel, characterised in that the computer program uses randomly generated data, wherein the randomly generated data is generated locally by the network client, to improve reliability of the integrity tests (see, e.g., Sel at [0025-026] and [0079-081]).
Regarding claim 11, the combination of Abera and Sel teaches the method according to claim 10, characterised in that the method comprises: receiving by the network client a genesis seed, generating by the network client the randomly generated data based on the received genesis seed (Sel at [0079-081], [0025-026], and [0059] – a randomized seed value <i.e., genesis seed> is produced based on, e.g., the time. A server may produce the seed value and send it to the remote device <i.e., network client receives the genesis seed>. The remote device uses the seed value as input to the firmware <i.e., the computer program uses the randomly generated data as input>. A hash is output by the remote device based on the firmware execution and randomized seed <i.e., pseudorandomly generating data based on the genesis seed>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Abera and Sel with the teachings of Sel, characterised in that the method comprises: receiving by the network client a genesis seed, generating by the network client the randomly generated data based on the received genesis seed, to improve reliability of the integrity tests (see, e.g., Sel at [0025-026] and [0079-081]).
Regarding claim 12, the combination of Abera and Sel teaches the method according to claim 11, characterised in that the method comprises: generating by a network server the genesis seed based on the computer program, a current time stamp and/or a server private key, and transmitting the generated genesis seed from the network server to the network client (Sel at [0079-081], [0025-026], and [0059] – a randomized seed value <i.e., genesis seed> is produced based on, e.g., the time. A server may produce the seed value and send it to the remote device <i.e., network client receives the genesis seed>. The remote device uses the seed value as input to the firmware <i.e., the computer program uses the randomly generated data as input>. A hash is output by the remote device based on the firmware execution and randomized seed <i.e., pseudorandomly generating data based on the genesis seed>; Note: While not presently relied upon, for additional information on the basics of generating a seed based on the time, see, e.g., w3schools (NPL: “Python Random seed() Method”; Feb. 27, 2021)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Abera and Sel with the teachings of Sel, characterised in that the method comprises: generating by a network server a genesis seed based on the computer program, a current time stamp and/or a server private key, transmitting the generated genesis seed from the network server to the network client, to improve reliability of the integrity tests (see, e.g., Sel at [0025-026] and [0079-081]).
Regarding claim 16, Abera teaches a system for provable remote execution of a computer program, the system comprising a network server and a network client, the network client having a client private key (§ 1 and 4.1 – a remote system <i.e., network client> attests to an execution flow of a computer program. The remote system has a remote system secret <i.e., private> key), the network client configured to:
receive a copy of the computer program over a computer network (§ 5.1 and 6.1 – the remote system comprises a computer program <i.e., received a copy of a computer program>. E.g., syringe pumps may have a syringe control program installed <i.e., received a copy of a computer program>),
execute the computer program (§ 5.1 and 6.1 – the computer program is executed. E.g., a syringe control program is executed),
generate a digital signature of at least a final state of the computer program with the client private key (§ 4.1, 1, and 3-3.1 – Hashes are generated during execution of a computer program by the remote device <i.e., network client>. The hashes are a result of measurements representing the computer program’s execution at different stages <i.e., states> on the device. A digital signature of the final hash <i.e., final state> is generated using the remote system’s secret <i.e., private> key. The signature is sent <i.e., transmitted> to the verifying authority), and
transmit the digital signature of the final state for validation of the execution of the computer program over the computer network (§ 4.1, 1, and 3-3.1 – Hashes are generated during execution of a computer program by the remote device <i.e., network client>. The hashes are a result of measurements representing the computer program’s execution at different stages <i.e., states> on the device. A digital signature of the final hash <i.e., final state> is generated using the remote system’s secret <i.e., private> key. The signature is sent <i.e., transmitted> to the verifying authority).
Yet, Abera appears to fail to specifically disclose wherein the computer program uses randomly generated data, wherein the randomly generated data is (i) generated locally by the network client by receiving a genesis seed and generating the randomly generated data based on the received genesis seed or (ii) received from a network server that generates a genesis seed based on one or more of the computer program, a current time stamp or a server private key.
However, Sel teaches a similar system for auditing execution of a computer program (see, e.g., abstract), wherein the computer program uses randomly generated data ([0079-081] and [0025-026] – a seed value is produced based on, e.g., a time. At least part of the seed value may be randomized <i.e., randomly generated data>. The randomized seed <i.e., randomly generated data> may be provided to the remote device. Alternatively, the remote device may produce the randomized seed value. The remote device uses the randomized seed <i.e., randomly generated data> as input to the firmware <i.e., the computer program uses randomly generated data>),
wherein the randomly generated data is (i) generated locally by the network client by receiving a genesis seed and generating the randomly generated data based on the received genesis seed or (ii) received from a network server that generates a genesis seed based on one or more of the computer program, a current time stamp or a server private key ([0079-081], [0025-026], and [0059] – a seed value <i.e., genesis seed> is produced based on, e.g., the time. At least part of the seed value may be randomized to produce a randomized seed <i.e., randomly generated data>. The randomized seed <i.e., randomly generated data> may be provided to the remote device from a server <i.e., received from network server>. Alternatively, the remote device may locally produce the randomized seed value. The remote device uses the randomized seed <i.e., randomly generated data> as input to the firmware <i.e., the computer program uses randomly generated data>; Note: While not presently relied upon, for additional information on the basics of generating a seed based on the time, see, e.g., w3schools (NPL: “Python Random seed() Method”; Feb. 27, 2021)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Abera with the teachings of Sel, wherein the computer program uses randomly generated data, wherein the randomly generated data is (i) generated locally by the network client by receiving a genesis seed and generating the randomly generated data based on the received genesis seed or (ii) received from a network server that generates a genesis seed based on one or more of the computer program, a current time stamp or a server private key, to improve reliability of the integrity tests (see, e.g., Sel at [0025-026] and [0079-081]).
Regarding claim 18, the combination of Abera and Sel teach the system according to claim 16, wherein executing the computer program comprises determining by the network client a state hash of an intermediary state of the computer program (Abera at § 4.1-4.2, 5.1, and 3-3.1 – A plurality of hashes <e.g., H1, H2/intermediary hash, H3/intermediary hash, H4> are generated during execution of a computer program by the remote device <i.e., network client>. Generated hashes are a result of measurements representing the computer program’s execution at different stages <i.e., states> in combination with a previously preceding hash <i.e., intermediate hashes> in the chain. A final hash is generated based on measurements representing the computer program’s final stage of execution and the previously preceding hash in the chain <i.e., intermediate hash>. A digital signature of the final hash <i.e., final state> is generated), wherein the digital signature generated by the network client is based on the final state and the state hash of the intermediary state (Abera at § 4.1-4.2, 5.1, and 3-3.1 – A plurality of hashes <e.g., H1, H2, H3, H4> are generated during execution of a computer program by the remote device <i.e., network client>. Generated hashes are a result of measurements representing the computer program’s execution at different stages <i.e., states> in combination with a previously preceding hash <i.e., intermediate hashes> in the chain. A final hash is generated based on measurements representing the computer program’s final stage of execution and the previously preceding hash in the chain <i.e., intermediate hash>. A digital signature of the final hash <i.e., final state> is generated).
Regarding claim 19, the combination of Abera and Sel teach the system according to claim 16, wherein executing the computer program comprises determining by the network client state hashes of at least two sequential intermediary states of the computer program, wherein a second state hash and every later state hash is computed from at least a corresponding intermediary state and a previous state hash (Abera at § 4.1-4.2, 5.1, and 3-3.1 – A plurality of hashes <e.g., H1, H2/intermediaryhash1, H3/intermediaryhash2, H4> are generated during execution of a computer program by the remote device <i.e., network client>. Generated hashes are a result of sequential measurements representing the computer program’s execution at different stages <i.e., states> in combination with a previously preceding hash <i.e., intermediate hashes> in the chain. A final hash is generated based on measurements representing the computer program’s final stage of execution and the previously preceding hash in the chain <i.e., intermediate hash>. A digital signature of the final hash <i.e., final state> is generated).
Regarding claim 21, the combination of Abera and Sel teach the system according to claim 16, wherein the computer program is configured to receive input data locally available at the network client during executing the computer program (Abera at § 6.1, 4.1-4.2, and 5.1 – A computer program may accept inputs during its runtime. E.g., the computer program may be a soldering iron temperature controller program on a soldering iron temperature controller <i.e., network client> that continuously reads the current temperature and uses the temperature as input to the program. The computer program responds to detected changes in temperature during the runtime).
Regarding claim 22, the combination of Abera and Sel teach the system according to claim 21, wherein the network client records the input data received and provides the recorded input data together with the digital signature (Sel at [0025], [0063], and [0079-081] – a seed value is determined locally on a second device <i.e., network client> and subsequently utilized <i.e., seed value is recorded>. The seed value is used as input to firmware <i.e., seed value is an input to a computer program>. The seed value is then provided to a first device <e.g., a server> from the second device <i.e., network client> together with a verification fingerprint; with Abera at § 4.1-4.2, and 3-3.1 – the digital signature is provided to a verifier).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Abera with the teachings of Sel, wherein the network client records the input data received and provides the recorded input data together with the digital signature, so the verification authority may efficiently verify the program’s execution by recreating the execution flow at the verification authority (Sel at [0025], [0063-066], and [0079-085]).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Abera in view of CASC (NPL: “Code Signing Whitepaper”; July 5, 2021; hereinafter “CASC”).
Regarding claim 5, Abera teaches the method according to claim 1. Yet, Abera appears to fail to specifically disclose the method characterised in that the copy of the computer program received by the network client is digitally signed and the method comprising the steps of: before executing the computer program, verifying by the network client that the digital signature of the computer program is by a trusted authority.
However, CASC teaches a method of securely receiving a copy of a computer program (see, e.g., pgs. 4-6), characterised in that the copy of the computer program received by the network client is digitally signed (pgs. 4-6 – a computer <i.e., network client> receives a copy of a computer program. The received copy of the computer program is digitally signed) and the method comprising the steps of: before executing the computer program, verifying by the network client that the digital signature of the computer program is by a trusted authority (pgs. 4-6 – a computer <i.e., network client> receives a copy of a computer program. The received computer program is digitally signed. Before using/trusting the computer program, the computer <i.e., network client> verifies that the digital signature of the computer program is valid. Particularly, verifying that the code signing certificate was signed by a trusted certificate authority and that the publisher’s private key was used to generate the digital signature. When validated, the computer program may be utilized by the computer <i.e., network client>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Abera with the teachings of CASC, characterised in that the copy of the computer program received by the network client is digitally signed and the method comprising the steps of: before executing the computer program, verifying by the network client that the digital signature of the computer program is by a trusted authority, to ensure a legitimate and unaltered copy of the computer program was received on the network client (see, e.g., CASC at pgs. 4-6).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Abera in view of Sel, further in view of Mondello (US20200313877; hereinafter “Mondello”).
Regarding claim 17, the combination of Abera and Sel teach the method according to claim 4, as well as using a genesis hash (see, e.g., Abera at § 4.1-4.2; with Sel at [0079-081], [0025-026], and [0059]). Yet the combination of Abera and Sel appear to fail to specifically disclose wherein the genesis hash is derived from a hash of the computer program combined with an identifier or identity of the network client.
However, Mondello teaches a similar system for ensuring integrity (see, e.g., abstract, [0066-071]), wherein the genesis hash is derived from a hash of the computer program combined with an identifier or identity of the network client (Mondello at [0066-068] – a compound device identifier “CDI” <i.e., genesis hash> is generated. The CDI is generated using a measurement of program code in combination with a unique identifier of the device <i.e., identifier or identity of the network client>; [0069-072] – The CDI is then used as input to integrity checks).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the genesis hash of combination of Abera and Sel with the teachings of Mondello, wherein the genesis hash is derived from a hash of the computer program combined with an identifier or identity of the network client, to bind the execution attestation to the specific software and device, thereby improving authenticity/integrity and reducing replace or device substitution attacks (see, e.g., Abera at § 4.1-4.2; with Mondello at [0066-072]).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Abera in view of Sel, further in view of CASC (NPL: “Code Signing Whitepaper”; July 5, 2021; hereinafter “CASC”).
Regarding claim 20, the combination of Abera and Sel teach the system according to claim 16. Yet, Abera appears to fail to specifically disclose the method characterised in that the copy of the computer program received by the network client is digitally signed and the method comprising the steps of: before executing the computer program, verifying by the network client that the digital signature of the computer program is by a trusted authority.
However, CASC teaches a method of securely receiving a copy of a computer program (see, e.g., pgs. 4-6), characterised in that the copy of the computer program received by the network client is digitally signed (pgs. 4-6 – a computer <i.e., network client> receives a copy of a computer program. The received copy of the computer program is digitally signed) and the network client is configured to, before executing the computer program, verify by the network client that the digital signature of the computer program is by a trusted authority (pgs. 4-6 – a computer <i.e., network client> receives a copy of a computer program. The received computer program is digitally signed. Before using/trusting the computer program, the computer <i.e., network client> verifies that the digital signature of the computer program is valid. Particularly, verifying that the code signing certificate was signed by a trusted certificate authority and that the publisher’s private key was used to generate the digital signature. When validated, the computer program may be utilized by the computer <i.e., network client>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Abera with the teachings of CASC, characterised in that the copy of the computer program received by the network client is digitally signed and the method comprising the steps of: before executing the computer program, verifying by the network client that the digital signature of the computer program is by a trusted authority, to ensure a legitimate and unaltered copy of the computer program was received on the network client (see, e.g., CASC at pgs. 4-6).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. w3schools (NPL: “Python Random seed() Method”; Feb. 27, 2021) teaches a system for using the current system time stamp as input to a function to pseudo-randomly generate a randomized value. Aktas (NPL: “Authenticating Executions for Trusted Systems”; 2013) teaches a system for collecting a plurality of hashes during a runtime of software and authenticating the hashes to confirm correct execution of the software (see, e.g., Aktas at pgs. 87-91). Fu et a. (US20210271751A1) teaches a system for remote attestation that collects a plurality of tags during a program’s execution and compares the tags against expected results to verify execution integrity (see, e.g., Fu at abstract). Ghose (US20160119148A1) teaches a hardware-assisted runtime validation that computes a hash over each control-flow segment of executed instructions and compares it to a securely stored reference signature (see, e.g., Fu at abstract).
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 JOSHUA RAYMOND WHITE whose telephone number is (571)272-4365. The examiner can normally be reached Monday-Thursday, & Alternate Fridays.
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, Taghi Arani can be reached at 5712723787. 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.
/J.R.W./Examiner, Art Unit 2438 /TAGHI T ARANI/Supervisory Patent Examiner, Art Unit 2438
Prosecution Insights