DETAILED ACTION
Response to Amendment
Claims 21-42 are pending. Claims 1-20 have been canceled.
Response to Arguments
Applicant’s arguments filed 12/03/2025 have been fully considered.
Regarding the rejection of claim 21 under 35 U.S.C. 103 as being unpatentable over Samuel et al. (US20190109877A1) in view of Gulati et al. (US20170048070A1), Applicant argues on pages 9-10 that Samuel's edge device does not generate data prior to program code being provided to the device for execution and that includes a security attribute that specifies at least one of a cryptographic protection capability or an isolation protection capability to be made available to the program code.
Applicant’s arguments are not persuasive. Samuel discloses:
“the first attester [hardware encryption device 306 (root 308-1)] to measure and sign first data [sign the application binary hash] prior to program code [application binary] being provided to the first device for execution”: para [0107] shows the accreditation information may include hash of the application binary cryptographically signed with a cryptographic key; para [0109] shows the modular application manager 506 may determine whether the modular application has been tampered based on the accreditation results; a static portion of the application binary data may be measured and saved before it is loaded into memory (e.g., prior to execution); para [0113] shows if no security breach is detected, the method 800 may proceed to where resource utilization by the modular application may be metered (e.g., during execution),
“the first data indicative of one or more attributes including a security attribute [memory integrity] that specifies at least one of a cryptographic protection capability [protected and encrypted memory] or an isolation protection capability [isolated memory] to be made available to the program code by the first hardware”: para [0055] shows a secure enclave may create a protection region such that all memory used in performing the instructions is encrypted; para [0059] shows the secure enclaves use a specialized hardware to isolate the memory; para [0068] shows the secure enclaves may allow data segregation between modular applications, between a modular application and the operating system, for code, memory and/or both (e.g., isolation protection to be made available to application code); para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory; para [0063] shows the hashes allow an integrity measurement of the edge device; para [0082] shows the hardware encryption device 306 may sign the hash with its attestation identity key; para [0082] shows the hardware encryption device 306 may generate a certification including the hash and sign the hash.
Samuel discloses the language of the claim.
Regarding claim 27, Applicant argues on pages 10-11 the Samuel/Gulati combination does not teach or suggest "obtain first data from first hardware of a first device prior to program code being provided to the first device for execution, the first hardware including first attester circuitry ... to measure and sign the first data, the first data indicative of ... a security attribute that specifies a cryptographic protection capability to be made available to the program code by the first hardware."
Applicant’s arguments are not persuasive. Samuel discloses:
“obtain first data [memory hash] from first hardware [first enclave] of a first device [edge device] prior to program code being provided to the first device for execution”: Fig 3 and para [0058] show the first secure enclave may include a hardware encryption device 306 used to generate a root of trust 308-1. The root of trust 308-1 may be one or more cryptographic signing keys; para [0107] shows the accreditation information may include hash of the application binary cryptographically signed with a cryptographic key; para [0109] shows the modular application manager 506 may determine whether the modular application has been tampered based on the accreditation results; a static portion of the application binary data may be measured and saved before it is loaded into memory (e.g., prior to execution); para [0113] shows if no security breach is detected, the method 800 may proceed to where resource utilization by the modular application may be metered (e.g., during execution),
“the first hardware including first attester [hardware encryption device 306 (root 308-1)], the first attester to measure and sign the first data [sign the hash], the first data indicative of one or more attributes including a security attribute [memory integrity] that specifies a cryptographic protection capability [protected and encrypted memory] provided to be made available to the program code by the first hardware”: Fig 3 and para [0058] show the first secure enclave may include a hardware encryption device 306 used to generate a root of trust 308-1. The root of trust 308-1 may be one or more cryptographic signing keys; para [0055] shows a secure enclave may create a protection region such that all operations are performed in a protected region, and all memory used in performing the instructions is encrypted; para [0059] shows the secure enclaves use a specialized hardware to isolate the memory; para [0068] shows the secure enclaves may allow data segregation between modular applications, between a modular application and the operating system, for code, memory and/or both (e.g., cryptographic protection to be made available to application code); para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory; para [0063] shows the hashes allow an integrity measurement of the edge device; para [0082] shows the hardware encryption device 306 may sign the hash with its attestation identity key; para [0082] shows the hardware encryption device 306 may generate a certification including the hash and sign the hash.
Samuel discloses the language of the claim.
Regarding claim 33, Applicant argues on page 11 the Samuel/Gulati combination does not teach or suggest "obtaining first data from
first hardware of a first device prior to program code being provided to the first device for execution, the first hardware including first attester circuitry ... to measure and sign the first data, the first data indicative of ... a security attribute that specifies an isolation protection capability to be made available to the program code by the first hardware."
Applicant’s arguments are not persuasive. Samuel discloses:
“obtaining first data [memory hash] from first hardware [first enclave] of a first device [edge device] prior to program code being provided to the first device for execution”: Fig 3 and para [0058] show the first secure enclave may include a hardware encryption device 306 used to generate a root of trust 308-1. The root of trust 308-1 may be one or more cryptographic signing keys; para [0107] shows the accreditation information may include hash of the application binary cryptographically signed with a cryptographic key; para [0109] shows the modular application manager 506 may determine whether the modular application has been tampered based on the accreditation results; a static portion of the application binary data may be measured and saved before it is loaded into memory (e.g., prior to execution); para [0113] shows if no security breach is detected, the method 800 may proceed to where resource utilization by the modular application may be metered (e.g., during execution),
“the first hardware including first attester [hardware encryption device 306 (root 308-1)], the first attester circuitry to measure and sign the first data [sign the hash], the first data indicative of one or more attributes including a security attribute [memory integrity] that specifies an isolation protection capability [isolated memory] to be made available to the program code or program data”: Fig 3 and para [0058] show the first secure enclave may include a hardware encryption device 306 used to generate a root of trust 308-1. The root of trust 308-1 may be one or more cryptographic signing keys; para [0055] shows a secure enclave may create a protection region such that all operations are performed in a protected region, and all memory used in performing the instructions is encrypted; para [0059] shows the secure enclaves use a specialized hardware to isolate the memory; para [0068] shows the secure enclaves may allow data segregation between modular applications, between a modular application and the operating system, for code, memory and/or both (e.g., isolation protection to be made available to application code); para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory; para [0063] shows the hashes allow an integrity measurement of the edge device; para [0082] shows the hardware encryption device 306 may sign the hash with its attestation identity key; para [0082] shows the hardware encryption device 306 may generate a certification including the hash and sign the hash.
Samuel discloses the language of the claim.
As to any argument not specifically addressed, they are the same as those discussed above.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 21-40 are rejected under 35 U.S.C. 103 as being unpatentable over Samuel et al. (US20190109877A1) in view of Gulati et al. (US20170048070A1).
Regarding claim 21, Samuel discloses a first device comprising (para [0054] shows an edge device):
first hardware [first enclave] and second hardware [second enclave] (para [0022] shows the system can execute the modular application on a secure enclave on a local device. A secure enclave may be a hardware enclave; Fig 3 and para [0055] show the modular application 302 are shown separated in secure enclaves (e.g., separated by vertical lines); para [0059] shows the secure enclaves that are isolated and use specialized hardware may be accorded the highest level of trust),
the first hardware [first enclave] including first attester [hardware encryption device 306 (root 308-1)] (Fig 3 and para [0058] show the first secure enclave may include a hardware encryption device 306 used to generate a root of trust 308-1. The root of trust 308-1 may be one or more cryptographic signing keys),
the first attester [hardware encryption device 306 (root 308-1)] to measure and sign first data [sign the memory hash] prior to program code [application binary] being provided to the first device for execution (para [0107] shows the accreditation information may include hash of the application binary cryptographically signed with a cryptographic key; para [0109] shows the modular application manager 506 may determine whether the modular application has been tampered based on the accreditation results; a static portion of the application binary data may be measured and saved before it is loaded into memory (e.g., prior to execution); para [0113] shows if no security breach is detected, the method 800 may proceed to where resource utilization by the modular application may be metered (e.g., during execution)),
the first data indicative of one or more attributes including a security attribute [memory integrity] that specifies at least one of a cryptographic protection capability [protected and encrypted memory] or an isolation protection capability [isolated memory] to be made available to the program code by the first hardware (para [0055] shows a secure enclave may create a protection region such that all memory used in performing the instructions is encrypted; para [0059] shows the secure enclaves use a specialized hardware to isolate the memory; para [0068] shows the secure enclaves may allow data segregation between modular applications, between a modular application and the operating system, for code, memory and/or both (e.g., isolation protection to be made available to application code); para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory; para [0063] shows the hashes allow an integrity measurement of the edge device; para [0082] shows the hardware encryption device 306 may sign the hash with its attestation identity key; para [0082] shows the hardware encryption device 306 may generate a certification including the hash and sign the hash),
the first attester to associate the first data [memory hash] with a first certificate (para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory; para [0082] shows the hardware encryption device 306 may generate a certification including the hash and the public key and sign the hash with its attestation identity key),
the second hardware [second enclave] including second attester [hardware encryption device 306 (root 308-2)] (Fig 3 and para [0058] show the second secure enclave may include a hardware encryption device 306 used to generate other root of trust 308-2. The root of trust 308-2 may be one or more cryptographic signing keys),
the second attester circuitry [hardware encryption device 306 (root 308-2)] to measure and sign second data [sign the memory hash] prior to the program code [application binary] being provided to the first device for execution (para [0107] shows the accreditation information may include hash of the application binary cryptographically signed with a cryptographic key; para [0109] shows a static portion of the application binary data may be measured and saved before it is loaded into memory (e.g., prior to execution); para [0113] shows if no security breach is detected, the method 800 may proceed to where resource utilization by the modular application may be metered (e.g., during execution),
the second data indicative of one or more attributes including a security attribute [memory integrity] that specifies at least one of a cryptographic protection capability [protected and encrypted memory or an isolation protection capability [isolated memory] to be made available to the program code by the second hardware (para [0055] shows a secure enclave may create a protection region such that all memory used in performing the instructions is encrypted; para [0059] shows the secure enclaves use a specialized hardware to isolate the memory; para [0068] shows the secure enclaves may allow data segregation between modular applications, between a modular application and the operating system, for code, memory and/or both (e.g., isolation protection to be made available to application code); para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory; para [0063] shows the hashes allow an integrity measurement of the edge device; para [0082] shows the hardware encryption device 306 may sign the hash with its attestation identity key; para [0082] shows the hardware encryption device 306 may generate a certification including the hash and sign the hash),
the second attester [hardware encryption device 306 (root 308-2)] different from the first attester [hardware encryption device 306 (root 308-1)] (Fig 3),
the second attester [hardware encryption device 306 (root 308-2)] to associate the second data [memory hash] with a second certificate (para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory; para [0082] shows the hardware encryption device 306 may generate a certification including the hash and the public key and sign the hash with its attestation identity key); and
device circuitry to [security manager 510] (Fig 5):
obtain the first data [memory hash] associated with the first certificate from the first hardware (para [0068] shows the secure enclaves may allow data segregation between modular applications, between a modular application and the operating system, for code, memory and/or both; para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory; para [0082] shows the hardware encryption device 306 (root 308-1) may generate a certification including the hash and the public key and sign the hash with its attestation identity key);
obtain the second data [memory hash] associated with the second certificate from the second hardware (para [0068] shows the secure enclaves may allow data segregation between modular applications, between a modular application and the operating system, for code, memory and/or both; para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory; para [0082] shows the hardware encryption device 306 (root 308-2) may generate a certification including the hash and the public key and sign the hash with its attestation identity key);
combine the first certificate [confirmation that there is no modification of the firmware] and the second certificate [confirmation that the operating system has not been modified] to generate third data [confirmation that the edge device has not been tampered] based on the first data and the second data, the third data to attest to a configuration of the first device (para [0056] shows the external entities may receive confirmation that the edge device has not been tampered. This may mean that there is no modification of the firmware, that the operating system running on the device has not been modified and the like; para [0063] shows the hashes allow the modular application manager to determine an integrity measurement of the edge device; para [0081] shows the hardware encryption device 306 may include hashes of system utilization logs, system security policies, system state information, system memory hashes and the like; para [0095] shows the smart contract 612 may include logic to authenticate the hashes signed by the hardware encryption device 306 from the edge device 502); and
cause the third data [platform attestation] to be communicated to a second device (para [0056] shows the external entities may receive confirmation that the edge device has not been tampered; para [0085] shows the security manager 510 may use the hardware encryption device to perform platform attestation to external entities.)
Samuel shows the first attester [hardware encryption device 306 (root 308-1)] (Fig 3) and the second attester [hardware encryption device 306 (root 308-2)] but fails to teach the first attester circuitry, the second attester circuitry, the second attester circuitry different from the first attester circuitry.
However, Gulati discloses the first attester circuitry, the second attester circuitry, the second attester circuitry different from the first attester circuitry (Fig 1 and para [0041] show hardware configured to implement the first security module 116, the second security module 118; para [0058] shows each of the security modules can provide a specific security functionality such as identification, authentication, encryption, decryption, validation, code signing, data extraction, or a combination thereof.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teaching of Samuel with the teaching of Gulati in order to improve verification speeds (Gulati; para [0081]).
Regarding claim 27, Samuel discloses at least one machine readable storage medium including at least one memory, disc or data storage device, the machine readable storage medium comprising instructions to cause at least one processor circuitry circuit to at least (para [0098-0099]):
obtain first data [memory hash] from first hardware [first enclave] of a first device [edge device] prior to program code being provided to the first device for execution (Fig 3 and para [0058] show the first secure enclave may include a hardware encryption device 306 used to generate a root of trust 308-1. The root of trust 308-1 may be one or more cryptographic signing keys; para [0107] shows the accreditation information may include hash of the application binary cryptographically signed with a cryptographic key; para [0109] shows the modular application manager 506 may determine whether the modular application has been tampered based on the accreditation results; a static portion of the application binary data may be measured and saved before it is loaded into memory (e.g., prior to execution); para [0113] shows if no security breach is detected, the method 800 may proceed to where resource utilization by the modular application may be metered (e.g., during execution)),
the first hardware including first attester [hardware encryption device 306 (root 308-1)], the first attester to measure and sign the first data [sign the hash], the first data indicative of one or more attributes including a security attribute [memory integrity] that specifies a cryptographic protection capability [protected and encrypted memory] provided to be made available to the program code by the first hardware (Fig 3 and para [0058] show the first secure enclave may include a hardware encryption device 306 used to generate a root of trust 308-1. The root of trust 308-1 may be one or more cryptographic signing keys; para [0055] shows a secure enclave may create a protection region such that all operations are performed in a protected region, and all memory used in performing the instructions is encrypted; para [0059] shows the secure enclaves use a specialized hardware to isolate the memory; para [0068] shows the secure enclaves may allow data segregation between modular applications, between a modular application and the operating system, for code, memory and/or both (e.g., cryptographic protection to be made available to application code); para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory; para [0063] shows the hashes allow an integrity measurement of the edge device; para [0082] shows the hardware encryption device 306 may sign the hash with its attestation identity key; para [0082] shows the hardware encryption device 306 may generate a certification including the hash and sign the hash),
the first attester to associate the first data [memory hash] with a first certificate (para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory; para [0082] shows the hardware encryption device 306 may generate a certification including the hash and the public key and sign the hash with its attestation identity key);
obtain second data [memory hash] from second hardware [second enclave] of the first device [edge device] prior to the program code being provided to the first device for execution (Fig 3 and para [0058] show the first secure enclave may include a hardware encryption device 306 used to generate a root of trust 308-1. The root of trust 308-1 may be one or more cryptographic signing keys; para [0107] shows the accreditation information may include hash of the application binary cryptographically signed with a cryptographic key; para [0109] shows a static portion of the application binary data may be measured and saved before it is loaded into memory (e.g., prior to execution); para [0113] shows if no security breach is detected, the method 800 may proceed to where resource utilization by the modular application may be metered (e.g., during execution)),
the second hardware including second attester [hardware encryption device 306 (root 308-2)], the second attester to measure and sign the second data [sign the hash], the second data indicative of one or more attributes [memory integrity] including a security attribute that specifies a cryptographic protection capability [protected and encrypted memory] provided to be made available to the program code by the second hardware (Fig 3 and para [0058] show the first secure enclave may include a hardware encryption device 306 used to generate a root of trust 308-2. The root of trust 308-2 may be one or more cryptographic signing keys; para [0055] shows a secure enclave may create a protection region such that all operations are performed in a protected region, and all memory used in performing the instructions is encrypted; para [0059] shows the secure enclaves use a specialized hardware to isolate the memory; para [0068] shows the secure enclaves may allow data segregation between modular applications, between a modular application and the operating system, for code, memory and/or both; para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory (e.g., cryptographic protection to be made available to application code); para [0063] shows the hashes allow an integrity measurement of the edge device; para [0082] shows the hardware encryption device 306 may sign the hash with its attestation identity key; para [0082] shows the hardware encryption device 306 may generate a certification including the hash and sign the hash),
the second attester [hardware encryption device 306 (root 308-2)] different from the first attester [hardware encryption device 306 (root 308-1)] (Fig 3),
the second attester [hardware encryption device 306 (root 308-2)] to associate the second data [memory hash] with a second certificate (para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory; para [0082] shows the hardware encryption device 306 may generate a certification including the hash and the public key and sign the hash with its attestation identity key);
combine the first certificate [confirmation that there is no modification of the firmware] and the second certificate [confirmation that the operating system has not been modified] to generate third data [confirmation that the edge device has not been tampered] based on the first data and the second data, the third data to attest to a configuration of the first device (para [0056] shows the external entities may receive confirmation that the edge device has not been tampered. This may mean that there is no modification of the firmware, that the operating system running on the device has not been modified and the like; para [0063] shows the hashes allow the modular application manager to determine an integrity measurement of the edge device; para [0081] shows the hardware encryption device 306 may include hashes of system utilization logs, system security policies, system state information, system memory hashes and the like; para [0095] shows the smart contract 612 may include logic to authenticate the hashes signed by the hardware encryption device 306 from the edge device 502); and
cause the third data [platform attestation] to be communicated to a second device (para [0056] shows the external entities may receive confirmation that the edge device has not been tampered; para [0085] shows the security manager 510 may use the hardware encryption device to perform platform attestation to external entities.)
Samuel shows the first attester [hardware encryption device 306 (root 308-1)] (Fig 3) and the second attester [hardware encryption device 306 (root 308-2)] but fails to teach the first attester circuitry, the second attester circuitry, the second attester circuitry different from the first attester circuitry.
However, Gulati discloses the first attester circuitry, the second attester circuitry, the second attester circuitry different from the first attester circuitry (Fig 1 and para [0041] show hardware configured to implement the first security module 116, the second security module 118; para [0058] shows each of the security modules can provide a specific security functionality such as identification, authentication, encryption, decryption, validation, code signing, data extraction, or a combination thereof.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teaching of Samuel with the teaching of Gulati in order to improve verification speeds (Gulati; para [0081]).
Regarding claim 33, Samuel discloses a method comprising:
obtaining first data [memory hash] from first hardware [first enclave] of a first device [edge device] prior to program code being provided to the first device for execution (Fig 3 and para [0058] show the first secure enclave may include a hardware encryption device 306 used to generate a root of trust 308-1. The root of trust 308-1 may be one or more cryptographic signing keys; para [0107] shows the accreditation information may include hash of the application binary cryptographically signed with a cryptographic key; para [0109] shows the modular application manager 506 may determine whether the modular application has been tampered based on the accreditation results; a static portion of the application binary data may be measured and saved before it is loaded into memory (e.g., prior to execution); para [0113] shows if no security breach is detected, the method 800 may proceed to where resource utilization by the modular application may be metered (e.g., during execution)),
the first hardware including first attester [hardware encryption device 306 (root 308-1)], the first attester circuitry to measure and sign the first data [sign the hash], the first data indicative of one or more attributes including a security attribute [memory integrity] that specifies an isolation protection capability [isolated memory] to be made available to the program code or program data (Fig 3 and para [0058] show the first secure enclave may include a hardware encryption device 306 used to generate a root of trust 308-1. The root of trust 308-1 may be one or more cryptographic signing keys; para [0055] shows a secure enclave may create a protection region such that all operations are performed in a protected region, and all memory used in performing the instructions is encrypted; para [0059] shows the secure enclaves use a specialized hardware to isolate the memory; para [0068] shows the secure enclaves may allow data segregation between modular applications, between a modular application and the operating system, for code, memory and/or both (e.g., isolation protection to be made available to application code); para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory; para [0063] shows the hashes allow an integrity measurement of the edge device; para [0082] shows the hardware encryption device 306 may sign the hash with its attestation identity key; para [0082] shows the hardware encryption device 306 may generate a certification including the hash and sign the hash),
the first attester to associate the first data [memory hash] with a first certificate (para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory; para [0082] shows the hardware encryption device 306 may generate a certification including the hash and the public key and sign the hash with its attestation identity key);
obtaining second data [second enclave] from second hardware [second enclave] of the first device [edge device] prior to the program code being provided to the first device for execution (Fig 3 and para [0058] show the first secure enclave may include a hardware encryption device 306 used to generate a root of trust 308-1. The root of trust 308-1 may be one or more cryptographic signing keys; para [0107] shows the accreditation information may include hash of the application binary cryptographically signed with a cryptographic key; para [0109] shows a static portion of the application binary data may be measured and saved before it is loaded into memory (e.g., prior to execution); para [0113] shows if no security breach is detected, the method 800 may proceed to where resource utilization by the modular application may be metered (e.g., during execution)),
the second hardware including second attester [hardware encryption device 306 (root 308-2)], the second attester to measure and sign the second data [sign the hash], the second data indicative of one or more attributes [memory integrity] including a security attribute that specifies an isolation protection capability [isolated memory] to be made available to the program code by the second hardware (Fig 3 and para [0058] show the first secure enclave may include a hardware encryption device 306 used to generate a root of trust 308-2. The root of trust 308-2 may be one or more cryptographic signing keys; para [0055] shows a secure enclave may create a protection region such that all operations are performed in a protected region, and all memory used in performing the instructions is encrypted; para [0059] shows the secure enclaves use a specialized hardware to isolate the memory; para [0068] shows the secure enclaves may allow data segregation between modular applications, between a modular application and the operating system, for code, memory and/or both; para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory (e.g., cryptographic protection to be made available to application code);; para [0063] shows the hashes allow an integrity measurement of the edge device; para [0082] shows the hardware encryption device 306 may sign the hash with its attestation identity key; para [0082] shows the hardware encryption device 306 may generate a certification including the hash and sign the hash),
the second attester [hardware encryption device 306 (root 308-2)] different from the first attester [hardware encryption device 306 (root 308-1)] (Fig 3),
the second attester [hardware encryption device 306 (root 308-2)] to associate the second data [memory hash] with a second certificate (para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory; para [0082] shows the hardware encryption device 306 may generate a certification including the hash and the public key and sign the hash with its attestation identity key);
combining, with device circuitry of the first device, the first certificate [confirmation that there is no modification of the firmware] and the second certificate [confirmation that the operating system has not been modified] to generate third data [confirmation that the edge device has not been tampered] based on the first data and the second data, the third data to attest to a configuration of the first device (Fig 3 and para [0058] show the first secure enclave may include a hardware encryption device 306 used to generate a root of trust 308-2. The root of trust 308-2 may be one or more cryptographic signing keys; para [0055] shows a secure enclave may create a protection region such that all operations are performed in a protected region, and all memory used in performing the instructions is encrypted; para [0059] shows the secure enclaves use a specialized hardware to isolate the memory; para [0068] shows the secure enclaves may allow data segregation between modular applications, between a modular application and the operating system, for code, memory and/or both; para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory; para [0063] shows the hashes allow an integrity measurement of the edge device; para [0082] shows the hardware encryption device 306 may sign the hash with its attestation identity key; para [0082] shows the hardware encryption device 306 may generate a certification including the hash and sign the hash); and
communicating the third data [platform attestation] to a second device (para [0056] shows the external entities may receive confirmation that the edge device has not been tampered; para [0085] shows the security manager 510 may use the hardware encryption device to perform platform attestation to external entities.)
Samuel shows the first attester [hardware encryption device 306 (root 308-1)] (Fig 3) and the second attester [hardware encryption device 306 (root 308-2)] but fails to teach the first attester circuitry, the second attester circuitry, the second attester circuitry different from the first attester circuitry.
However, Gulati discloses the first attester circuitry, the second attester circuitry, the second attester circuitry different from the first attester circuitry (Fig 1 and para [0041] show hardware configured to implement the first security module 116, the second security module 118; para [0058] shows each of the security modules can provide a specific security functionality such as identification, authentication, encryption, decryption, validation, code signing, data extraction, or a combination thereof.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teaching of Samuel with the teaching of Gulati in order to improve verification speeds (Gulati; para [0081]).
Regarding claims 23, 29 and 35, Samuel-Gulati as applied to claims 21, 26 and 33 discloses the security attribute [memory integrity] of the first hardware is a first attribute (Samuel; para [0059] shows the secure enclaves use a specialized hardware to isolate the memory; para [0086] shows the hardware encryption device 306 may generate a hash value of the contents of the memory during execution of the modular application; para [0081] shows the hardware encryption device 306 may include memory hashes; para [0082] shows the hardware encryption device 306 may sign the hash with its attestation identity key; para [0110] shows the modular application manager 506 may receive information about the integrity of the memory utilized during execution of the application; para [0118] shows the hardware encryption device of the edge device 502 may be used the security manager 510 to determine the system utilization in the secure enclave), and
a second attribute of the one or more attributes of the first hardware corresponds to telemetry of the first hardware (Samuel; para [0012] shows tampering detection and/or metering of the modular applications on an edge device; para [0128] shows metering the modular applications on different devices may be performed).
Regarding claims 24, 30 and 36, Samuel-Gulati as applied to claims 21, 26 and 33 discloses the second device corresponds to a relying party (Samuel; para [0056] shows the external entities may receive confirmation that the edge device has not been tampered. This may enhance reliability of the modular applications 302, which may otherwise not be trusted by a consumer.)
Regarding claims 25, 31 and 37, and Samuel-Gulati as applied to claims 21, 26 and 33 discloses the first hardware provides a trusted execution environment (Samuel; para [0084] shows the firmware hardware encryption device may be run in a protected execution environment called trusted execution environment (TEE).)
Regarding claims 26, 32 and 38, Samuel-Gulati as applied to claims 25, 31 and 37 discloses the trusted execution environment is a first trusted execution environment, and the second hardware provides a second trusted execution environment (Samuel; [Abstract] shows one or more secure enclaves for executing the modular applications may be generated; para [0056] shows secure enclaves using root of trust and a hardware encryption device 306 such as a trusted platform module (TPM); para [0084] shows the firmware hardware encryption device may be run in a protected execution environment called trusted execution environment (TEE).)
Regarding claim 39, and Samuel-Gulati as applied to claim 21 discloses the first device is a router (Samuel; para [0054] shows an edge device, such as an IoT device 210; para [0044] shows the system 200 may include an IoT hub 214, one or more IoT devices, one or more gateway devices).
Regarding claim 40, and Samuel-Gulati as applied to claim 21 discloses the first device is a single integrated circuit (Samuel; para [0054] shows integrated devices. Gulati; para [0201] shows application-specific integrated circuits (ASICs).)
Regarding claim 41, and Samuel-Gulati as applied to claim 21 discloses the third data includes a third certificate [platform attestation that the edge device has not been tampered] (Samuel; para [0056] shows the external entities may receive confirmation that the edge device has not been tampered. This may mean that there is no modification of the firmware, that the operating system running on the device has not been modified and the like; the external entities may receive confirmation that the edge device has not been tampered; para [0085] shows the security manager 510 may use the hardware encryption device to perform platform attestation to external entities.)
Regarding claim 42, and Samuel-Gulati as applied to claim 41 discloses the device circuitry is to generate the third certificate platform attestation that the edge device has not been tampered] based on a concatenation of the first certificate [confirmation that there is no modification of the firmware] and the second certificate [confirmation that the operating system has not been modified] (Samuel; para [0056] shows the external entities may receive confirmation that the edge device has not been tampered. This may mean that there is no modification of the firmware, that the operating system running on the device has not been modified and the like; para [0063] shows the hashes allow the modular application manager to determine an integrity measurement of the edge device; para [0081] shows the hardware encryption device 306 may include hashes of system utilization logs, system security policies, system state information, system memory hashes and the like; para [0095] shows the smart contract 612 may include logic to authenticate the hashes signed by the hardware encryption device 306 from the edge device 502.)
Conclusion
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 TAN DOAN whose telephone number is (571)270-0162. The examiner can normally be reached Monday - Friday 8am - 5pm ET.
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, Oscar Louie, can be reached at (571) 270-1684. 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.
/TAN DOAN/Primary Examiner, Art Unit 2445
Prosecution Insights