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.
DETAILED ACTION
Remarks
This action is in response to communications filed on 10/01/2025, claim 1, 2, 11 and 17 are amended per Applicant's request. Therefore, claims 1-20 are presently pending in the application and have been considered as follows.
Response to Arguments
Applicant's arguments filed 10/01/2025 have been fully considered but they are not persuasive.
-The applicants’ remarks on 6-8 with respect to:
“The Office Action relies on Forristal rather than DSP2058 to teach "wherein the circuitry is a sole generator of the measurements for software attestation for the device." (Office Action, pages 5-6.)”
“Forristal teaches integrity measurement logic 214 performs an integrity check on firmware and/or other code of the device and stores a result of the integrity check. Forristal does not teach circuitry is a sole generator of the measurements used for software attestation for the device and the circuitry is to transmit the measurements to a circuitry that is to perform software attestation.”
“Applicants do not concede that teachings of DSP2058 and Forristal are properly combinable..”
“Claim 17 is rejected for similar reasons as pertain to claim 1. (Office Action, page 14- 15.) While claims 1 and 17 are different and distinct from each other, at least for similar reasons as pertain to claim 1, withdrawal of the rejection of claim 17 is requested.”
Have been carefully considered but are non-persuasive;
The examiner respectfully disagrees and notes after careful reconsideration Forristal discloses the following with regards circuitry is a sole generator of the measurements used for software attestation for the device and the circuitry is to transmit the measurements to a circuitry that is to perform software attestation:
Circuitry – Para. 0021 – “an integrity measurement logic 214 is present, which can include hardware to perform integrity checks on the firmware and/or other code of the device... In general, the integrity measurement logic can be an embedded fixed function hardware unit configured to perform integrity analysis in accordance with an embodiment of the present invention. “
Sole Generator – Para. 0029 – “In various embodiments, the integrity checking performed responsive to an external software request can be entirely implemented and serviced by hardware, and in no way be influenced in operation or have the result directly affected by the firmware executing in the hardware device's microcontroller. In this way, a malicious firmware can be prevented from affecting the reported measure of itself ...”
Transmit the measurements to a circuitry that is to perform software attestation -Para. 0026 – “ it is the responsibility of the external software to, upon receipt of the measurement information, analyze the measurement information received”
At Boot – Para. 0025 – “ Further, note that the integrity analysis can be performed on device initialization”
Thus, Forristal discloses embedded hardware logic that at boot generates the measurement for the integrity of firmware to be analyzed by a different entity and the generation of the measurements are performed solely by this embedded hardware logic. While it is noted that Forristal does additionally disclose that the microcontroller may also generate measurements of the contents in SRAM it is noted that Forristal distinguishes this as being performed in a different embodiment. Thus, the applicant argument is considered non-persuasive. Additional arguments are also considered to be non-persuasive for the reasons indicated above.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/01/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1-20 the claims now indicate that a circuitry performs software attestation, however this creates ambiguity as it is unclear if the circuity is the same or different, as they are labeled with the same name creating further in each claims (independent and dependent) that refers back to “the circuitry” rendering the scope of the claim unclear.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5-10 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over NPL Security Protocol and Data Model (SPDM) Architecture White Paper v 1.0.0 (DSP2058) hereinafter “DSP2058” in view of US 20130263262 to Forristal
Claim 1
DSP2058 teaches an apparatus comprising:
an input/output (I/O) interface and circuitry, communicatively coupled to the interface, wherein the circuitry is to, at boot of a device, generate measurements for software attestation of the device and transmit the measurements to circuitry that is to perform software attestation wherein the [e.g. DSP2058; Page 10 Sec 5.2 “Authentication:, Page 10 Sec 5.3 “Security Platform and Data Model (SPDM) architecture” Page 17-23 Sec 7-7.5.2“Certificates (entirety)” Page 24-29 Sec 8-8.2.2 (“SPDM message “entirety”), Page 30-32 Sec 9-9.4 “Attestation and security policies (entirety)” – herein DSP2058 discloses a platform management subsystem in a modern enterprise computer platform is comprised of a set of components which is comprised of one or more mutable elements, such as firmware or software, wherein components comprises various device types (such as CPUs, PCIe adapters, etc.) and for providing a mechanisms to authenticate a component thru the retrieval of a signed measurement payload of mutable components from a component that represents a signed hashed value. Page 33 of DSP2058 references the SPDM specification 1.0.0 (DSP0274 which is incorporated by reference) and the examiner points to pages Sec 4.6.3 of DSP0274 that defines measurement as calculating the cryptographic hash value of a piece of firmware/ software or configuration data and Sec 4.10.1-4.10.1.5 of DSP0274 that discloses the measurement process.]
While DSP2058 teaches the apparatus of claim 1 DSP2058 fails to explicitly teach that the sole generator of measurements is a particular circuit. More specifically DSP2058 fails to teach the claimed limitations of however, Forristal teaches:
“wherein the circuitry is a sole generator of the measurements used for software attestation for the device” [e.g. Forristal; Para. 0002, 0009, 0012, 0020, 0021, 0026, 0025, 0029, 0030 – discloses a system for verifying the integrity of firmware/code of individual components (e.g. devices) using an integrity measurement logic 214 is present, which can include hardware to perform integrity checks on the firmware and/or other code of the device responsive to a trigger received from an external entity. In general, the integrity measurement logic can be an embedded fixed function hardware unit configured to perform integrity analysis which is entirely implemented and serviced by hardware. This has been interpreted to mean this hardware logic is isolated and capable of generating measurements for the attestation process being the sole entity. The measurements are provided to an external entity separate from the integrity measurement logic.]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include, the above limitations in the invention as disclosed by DSP2058 in order to prevent malicious firmware from affecting the reported measure of itself as disclosed in paragraph 0029 of Forristal.
Claim 2:
The Combination of DSP2058 and Forristal teaches the apparatus of claim 1, wherein the measurements are based on a firmware image file, a software executable binary, and one or more of: device state, and/or fuse measurements. [e.g. DSP2058; Page 10 Sec 5.2 “Authentication:, Page 10 Sec 5.3 “Security Platform and Data Model (SPDM) architecture” Page 17-23 Sec 7-7.5.2“Certificates (entirety)” Page 24-29 Sec 8-8.2.2 (“SPDM message “entirety”), Page 30-32 Sec 9-9.4 “Attestation and security policies (entirety)” – herein DSP2058 discloses a platform management subsystem in a modern enterprise computer platform is comprised of a set of components which is comprised of one or more mutable elements, such as firmware or software, wherein components comprises various device types (such as CPUs, PCIe adapters, etc.) and for providing a mechanisms to authenticate a component thru the retrieval of a signed measurement payload of mutable components from a component that represents a signed hashed value. Page 33 of DSP2058 references the SPDM specification 1.0.0 (DSP0274 which is incorporated by reference) and the examiner points to pages Sec 4.6.3 of DSP0274 that defines measurement as calculating the cryptographic hash value of a piece of firmware (firmware image)/ software or configuration data (executable binary and device state) and Sec 4.10.1-4.10.1.5 of DSP0274 that discloses the measurement process.] [e.g. Forristal; Para. 0002, 0009, 0012, 0020, 0021, 0026, 0025, 0029, 0030 – discloses a system for verifying the integrity of firmware/code of individual components (e.g. devices) using an integrity measurement logic 214 is present, which can include hardware to perform integrity checks on the firmware and/or other code of the device responsive to a trigger received from an external entity. In general, the integrity measurement logic can be an embedded fixed function hardware unit configured to perform integrity analysis which is entirely implemented and serviced by hardware. This has been interpreted to mean this hardware logic is isolated and capable of generating measurements for the attestation process being the sole entity. The measurements are provided to an external entity separate from the integrity measurement logic.]
Claim 3:
The Combination of DSP2058 and Forristal teaches the apparatus of claim 1, wherein to generate measurements for software attestation of the device, the circuitry is to perform a cryptographic hash over one or more of: firmware image file, software executable binary, device state, and/or fuse measurements. [e.g. DSP2058; Page 10 Sec 5.2 “Authentication:, Page 10 Sec 5.3 “Security Platform and Data Model (SPDM) architecture” Page 17-23 Sec 7-7.5.2“Certificates (entirety)” Page 24-29 Sec 8-8.2.2 (“SPDM message “entirety”), Page 30-32 Sec 9-9.4 “Attestation and security policies (entirety)” – herein DSP2058 discloses a platform management subsystem in a modern enterprise computer platform is comprised of a set of components which is comprised of one or more mutable elements, such as firmware or software, wherein components comprises various device types (such as CPUs, PCIe adapters, etc.) and for providing a mechanisms to authenticate a component thru the retrieval of a signed measurement payload of mutable components from a component that represents a signed hashed value. Page 33 of DSP2058 references the SPDM specification 1.0.0 (DSP0274 which is incorporated by reference) and the examiner points to pages Sec 4.6.3 of DSP0274 that defines measurement as calculating the cryptographic hash value of a piece of firmware/ software or configuration data and Sec 4.10.1-4.10.1.5 of DSP0274 that discloses the measurement process.] [e.g. Forristal; Para. 0002, 0009, 0012, 0020, 0021, 0026, 0025, 0029, 0030 – discloses a system for verifying the integrity of firmware/code of individual components (e.g. devices) using an integrity measurement logic 214 is present, which can include hardware to perform integrity checks on the firmware and/or other code of the device responsive to a trigger received from an external entity. In general, the integrity measurement logic can be an embedded fixed function hardware unit configured to perform integrity analysis which is entirely implemented and serviced by hardware. This has been interpreted to mean this hardware logic is isolated and capable of generating measurements for the attestation process being the sole entity. The measurements are provided to an external entity separate from the integrity measurement logic.]
Claim 5:
DSP2058 teaches the apparatus of claim 1, wherein the circuitry is to: create a key pair comprising a private key and a public key and provide the public key to a certificate authority. [e.g. DSP2058; Page 17-23 Sec 7-7.5.2“Certificates (entirety) – DSP2058 discloses internal key generation and the CA is in possession of the public key backed by a root certificate.]
Claim 6:
The Combination of DSP2058 and Forristal teaches the apparatus of claim 5, wherein the circuitry is to: insert the measurements into one or more messages, and sign the one or more messages based on the private key generated by the circuitry. [e.g. DSP2058; Page 10 Sec 5.2 “Authentication:, Page 10 Sec 5.3 “Security Platform and Data Model (SPDM) architecture” Page 17-23 Sec 7-7.5.2“Certificates (entirety)” Page 24-29 Sec 8-8.2.2 (“SPDM message “entirety”), Page 30-32 Sec 9-9.4 “Attestation and security policies (entirety)” – herein DSP2058 discloses a platform management subsystem in a modern enterprise computer platform is comprised of a set of components which is comprised of one or more mutable elements, such as firmware or software, wherein components comprises various device types (such as CPUs, PCIe adapters, etc.) and for providing a mechanisms to authenticate a component thru the retrieval of a signed measurement payload of mutable components from a component that represents a signed hashed value. Page 33 of DSP2058 references the SPDM specification 1.0.0 (DSP0274 which is incorporated by reference) and the examiner points to pages Sec 4.6.3 of DSP0274 that defines measurement as calculating the cryptographic hash value of a piece of firmware/ software or configuration data and Sec 4.10.1-4.10.1.5 of DSP0274 that discloses the measurement process including inserting the measurements and signing with a private key.] [e.g. Forristal; Para. 0002, 0009, 0012, 0020, 0021, 0026, 0025, 0029, 0030 – discloses a system for verifying the integrity of firmware/code of individual components (e.g. devices) using an integrity measurement logic 214 is present, which can include hardware to perform integrity checks on the firmware and/or other code of the device responsive to a trigger received from an external entity. In general, the integrity measurement logic can be an embedded fixed function hardware unit configured to perform integrity analysis which is entirely implemented and serviced by hardware. This has been interpreted to mean this hardware logic is isolated and capable of generating measurements for the attestation process being the sole entity. The measurements are provided to an external entity separate from the integrity measurement logic.]
Claim 7:
While DSP2058 teaches the apparatus of claim 6 and inserting measurements into messages DSP2058 fails to teach dedicated circuitry for attestation, however, Forristal teaches:
“wherein the circuitry is a sole inserter of the measurements into the one or more messages” [e.g. Forristal; Para. 0002, 0009, 0012, 0020, 0021, 0026, 0025, 0029, 0030 – discloses a system for verifying the integrity of firmware/code of individual components (e.g. devices) using an integrity measurement logic 214 is present, which can include hardware to perform integrity checks on the firmware and/or other code of the device responsive to a trigger received from an external entity. In general, the integrity measurement logic can be an embedded fixed function hardware unit configured to perform integrity analysis which is entirely implemented and serviced by hardware. This has been interpreted to mean this hardware logic is isolated and capable of generating measurements for the attestation process being the sole entity. The measurements are provided to an external entity separate from the integrity measurement logic.]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include, the above limitations in the invention as disclosed by DSP2058 in order to prevent malicious firmware from affecting the reported measure of itself as disclosed in paragraph 0029 of Forristal.
Claim 8:
While DSP2058 teaches the apparatus of claim 6 and signing measurements into messages DSP2058 fails to teach dedicated circuitry for attestation, however, Forristal teaches:
“wherein the circuitry is a sole signer of the one or more messages” [e.g. Forristal; Para. 0002, 0009, 0012, 0020, 0021, 0026, 0025, 0029, 0030 – discloses a system for verifying the integrity of firmware/code of individual components (e.g. devices) using an integrity measurement logic 214 is present, which can include hardware to perform integrity checks on the firmware and/or other code of the device responsive to a trigger received from an external entity. In general, the integrity measurement logic can be an embedded fixed function hardware unit configured to perform integrity analysis which is entirely implemented and serviced by hardware. This has been interpreted to mean this hardware logic is isolated and capable of generating measurements for the attestation process being the sole entity. The measurements are provided to an external entity separate from the integrity measurement logic.]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include, the above limitations in the invention as disclosed by DSP2058 in order to prevent malicious firmware from affecting the reported measure of itself as disclosed in paragraph 0029 of Forristal.
Claim 9:
DSP2058 teaches the apparatus of claim 6, wherein the one or more messages are based on a Security Protocol and Data Model (SPDM) protocol. [e.g. DSP2058; Page 10 Sec 5.2 “Authentication:, Page 10 Sec 5.3 “Security Platform and Data Model (SPDM) architecture” Page 17-23 Sec 7-7.5.2“Certificates (entirety)” Page 24-29 Sec 8-8.2.2 (“SPDM message “entirety”), Page 30-32 Sec 9-9.4 “Attestation and security policies (entirety)” – herein DSP2058 discloses a platform management subsystem in a modern enterprise computer platform is comprised of a set of components which is comprised of one or more mutable elements, such as firmware or software, wherein components comprises various device types (such as CPUs, PCIe adapters, etc.) and for providing a mechanisms to authenticate a component thru the retrieval of a signed measurement payload of mutable components from a component that represents a signed hashed value. Page 33 of DSP2058 references the SPDM specification 1.0.0 (DSP0274 which is incorporated by reference) and the examiner points to pages Sec 4.6.3 of DSP0274 that defines measurement as calculating the cryptographic hash value of a piece of firmware/ software or configuration data and Sec 4.10.1-4.10.1.5 of DSP0274 that discloses the measurement process.]
Claim 10:
The Combination of DSP2058 and Forristal teaches the apparatus of claim 6, wherein the device comprises one or more of: microcontroller, central processing unit (CPU), graphics processing unit (GPU), network interface device, accelerator, storage device, memory device, graphics processing unit, audio or sound processing device. [e.g. DSP2058; Page 10 Sec 5.2 “Authentication:, Page 10 Sec 5.3 “Security Platform and Data Model (SPDM) architecture” Page 17-23 Sec 7-7.5.2“Certificates (entirety)” Page 24-29 Sec 8-8.2.2 (“SPDM message “entirety”), Page 30-32 Sec 9-9.4 “Attestation and security policies (entirety)” – herein DSP2058 discloses a platform management subsystem in a modern enterprise computer platform is comprised of a set of components which is comprised of one or more mutable elements, such as firmware or software, wherein components comprises various device types (such as CPUs, PCIe adapters, etc.) and for providing a mechanisms to authenticate a component thru the retrieval of a signed measurement payload of mutable components from a component that represents a signed hashed value. Page 33 of DSP2058 references the SPDM specification 1.0.0 (DSP0274 which is incorporated by reference) and the examiner points to pages Sec 4.6.3 of DSP0274 that defines measurement as calculating the cryptographic hash value of a piece of firmware/ software or configuration data and Sec 4.10.1-4.10.1.5 of DSP0274 that discloses the measurement process.] [e.g. Forristal; Para. 0002, 0009, 0012, 0020, 0021, 0026, 0025, 0029, 0030 – discloses a system for verifying the integrity of firmware/code of individual components (e.g. devices) using an integrity measurement logic 214 is present, which can include hardware to perform integrity checks on the firmware and/or other code of the device responsive to a trigger received from an external entity. In general, the integrity measurement logic can be an embedded fixed function hardware unit configured to perform integrity analysis which is entirely implemented and serviced by hardware. This has been interpreted to mean this hardware logic is isolated and capable of generating measurements for the attestation process being the sole entity. The measurements are provided to an external entity separate from the integrity measurement logic.]
Claim 17
DSP2058 teaches at least one non-transitory computer-readable medium comprising instructions stored thereon, that if executed by one or more processors, cause the one or more processors to: request a circuitry to provide measurements of configurations of a device, wherein the configurations of the device are based on a cryptographic hash of firmware image file, software executable binary, device state, and/or fuse measurements, [e.g. DSP2058; Page 10 Sec 5.2 “Authentication:, Page 10 Sec 5.3 “Security Platform and Data Model (SPDM) architecture” Page 17-23 Sec 7-7.5.2“Certificates (entirety)” Page 24-29 Sec 8-8.2.2 (“SPDM message “entirety”), Page 30-32 Sec 9-9.4 “Attestation and security policies (entirety)” – herein DSP2058 discloses a platform management subsystem in a modern enterprise computer platform is comprised of a set of components which is comprised of one or more mutable elements, such as firmware or software, wherein components comprises various device types (such as CPUs, PCIe adapters, etc.) and for providing a mechanisms to authenticate a component thru the retrieval of a signed measurement payload of mutable components from a component that represents a signed hashed value. Page 33 of DSP2058 references the SPDM specification 1.0.0 (DSP0274 which is incorporated by reference) and the examiner points to pages Sec 4.6.3 of DSP0274 that defines measurement as calculating the cryptographic hash value of a piece of firmware/ software or configuration data and Sec 4.10.1-4.10.1.5 of DSP0274 that discloses the measurement process.]
While DSP2058 teaches the computer readable medium of claim 1 DSP2058 fails to explicitly teach that the request it to a sole provider of measurements is a particular circuit. More specifically DSP2058 fails to teach the claimed limitations of however, Forristal teaches:
“wherein the circuitry is a sole provider of the measurements” [e.g. Forristal; Para. 0002, 0009, 0012, 0020, 0021, 0026, 0025, 0029, 0030 – discloses a system for verifying the integrity of firmware/code of individual components (e.g. devices) using an integrity measurement logic 214 is present, which can include hardware to perform integrity checks on the firmware and/or other code of the device responsive to a trigger received from an external entity. In general, the integrity measurement logic can be an embedded fixed function hardware unit configured to perform integrity analysis which is entirely implemented and serviced by hardware. This has been interpreted to mean this hardware logic is isolated and capable of generating measurements for the attestation process being the sole entity. The measurements are provided to an external entity separate from the integrity measurement logic.]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include, the above limitations in the invention as disclosed by DSP2058 in order to prevent malicious firmware from affecting the reported measure of itself as disclosed in paragraph 0029 of Forristal.
Claim 18:
The Combination of DSP2058 and Forristal teaches the computer-readable medium of claim 17, comprising instructions stored thereon, that if executed by one or more processors, cause the one or more processors to: request the circuitry to sign the measurements and request the circuitry to provide the signed measurements in one or more messages.. [e.g. DSP2058; Page 10 Sec 5.2 “Authentication:, Page 10 Sec 5.3 “Security Platform and Data Model (SPDM) architecture” Page 17-23 Sec 7-7.5.2“Certificates (entirety)” Page 24-29 Sec 8-8.2.2 (“SPDM message “entirety”), Page 30-32 Sec 9-9.4 “Attestation and security policies (entirety)” – herein DSP2058 discloses a platform management subsystem in a modern enterprise computer platform is comprised of a set of components which is comprised of one or more mutable elements, such as firmware or software, wherein components comprises various device types (such as CPUs, PCIe adapters, etc.) and for providing a mechanisms to authenticate a component thru the retrieval of a signed measurement payload of mutable components from a component that represents a signed hashed value. Page 33 of DSP2058 references the SPDM specification 1.0.0 (DSP0274 which is incorporated by reference) and the examiner points to pages Sec 4.6.3 of DSP0274 that defines measurement as calculating the cryptographic hash value of a piece of firmware/ software or configuration data and Sec 4.10.1-4.10.1.5 of DSP0274 that discloses the measurement process including inserting the measurements and signing with a private key.] [e.g. Forristal; Para. 0002, 0009, 0012, 0020, 0021, 0026, 0025, 0029, 0030 – discloses a system for verifying the integrity of firmware/code of individual components (e.g. devices) using an integrity measurement logic 214 is present, which can include hardware to perform integrity checks on the firmware and/or other code of the device responsive to a trigger received from an external entity. In general, the integrity measurement logic can be an embedded fixed function hardware unit configured to perform integrity analysis which is entirely implemented and serviced by hardware. This has been interpreted to mean this hardware logic is isolated and capable of generating measurements for the attestation process being the sole entity. The measurements are provided to an external entity separate from the integrity measurement logic.]
Claim 19:
The Combination of DSP2058 and Forristal teaches the computer-readable medium of claim 17, comprising instructions stored thereon, that if executed by one or more processors, cause the one or more processors to: request the circuitry to generate a key pair comprising a private key and a public key and request the circuitry to sign the one or more messages based on the private key. [e.g. DSP2058; Page 10 Sec 5.2 “Authentication:, Page 10 Sec 5.3 “Security Platform and Data Model (SPDM) architecture” Page 17-23 Sec 7-7.5.2“Certificates (entirety)” Page 24-29 Sec 8-8.2.2 (“SPDM message “entirety”), Page 30-32 Sec 9-9.4 “Attestation and security policies (entirety)” – herein DSP2058 discloses a platform management subsystem in a modern enterprise computer platform is comprised of a set of components which is comprised of one or more mutable elements, such as firmware or software, wherein components comprises various device types (such as CPUs, PCIe adapters, etc.) and for providing a mechanisms to authenticate a component thru the retrieval of a signed measurement payload of mutable components from a component that represents a signed hashed value. Page 33 of DSP2058 references the SPDM specification 1.0.0 (DSP0274 which is incorporated by reference) and the examiner points to pages Sec 4.6.3 of DSP0274 that defines measurement as calculating the cryptographic hash value of a piece of firmware/ software or configuration data and Sec 4.10.1-4.10.1.5 of DSP0274 that discloses the measurement process including inserting the measurements and signing with a private key.] [e.g. Forristal; Para. 0002, 0009, 0012, 0020, 0021, 0026, 0025, 0029, 0030 – discloses a system for verifying the integrity of firmware/code of individual components (e.g. devices) using an integrity measurement logic 214 is present, which can include hardware to perform integrity checks on the firmware and/or other code of the device responsive to a trigger received from an external entity. In general, the integrity measurement logic can be an embedded fixed function hardware unit configured to perform integrity analysis which is entirely implemented and serviced by hardware. This has been interpreted to mean this hardware logic is isolated and capable of generating measurements for the attestation process being the sole entity. The measurements are provided to an external entity separate from the integrity measurement logic.]
Claim 20:
DSP2058 teaches the computer-readable medium of claim 19, wherein the one or more messages are based on a Security Protocol and Data Model (SPDM) protocol. [e.g. DSP2058; Page 10 Sec 5.2 “Authentication:, Page 10 Sec 5.3 “Security Platform and Data Model (SPDM) architecture” Page 17-23 Sec 7-7.5.2“Certificates (entirety)” Page 24-29 Sec 8-8.2.2 (“SPDM message “entirety”), Page 30-32 Sec 9-9.4 “Attestation and security policies (entirety)” – herein DSP2058 discloses a platform management subsystem in a modern enterprise computer platform is comprised of a set of components which is comprised of one or more mutable elements, such as firmware or software, wherein components comprises various device types (such as CPUs, PCIe adapters, etc.) and for providing a mechanisms to authenticate a component thru the retrieval of a signed measurement payload of mutable components from a component that represents a signed hashed value. Page 33 of DSP2058 references the SPDM specification 1.0.0 (DSP0274 which is incorporated by reference) and the examiner points to pages Sec 4.6.3 of DSP0274 that defines measurement as calculating the cryptographic hash value of a piece of firmware/ software or configuration data and Sec 4.10.1-4.10.1.5 of DSP0274 that discloses the measurement process.]
Claims 4 and 11-16 are rejected under 35 U.S.C. 103 as being unpatentable over NPL Security Protocol and Data Model (SPDM) Architecture White Paper v 1.0.0 (DSP2058) hereinafter “DSP2058” in view of US 20130263262 to Forristal and further in view of US 20200344265 to Kelly
Claim 4:
While the combination teaches the apparatus of claim 1 the combination fails to explicitly teach verifying the measurements based on a key retrieved from an one-time programmable memory. More specifically the combination fails to teach the claimed limitations of however, Kelly teaches:
“wherein the circuitry is to: verify the generated measurements based on a key retrieved from a one-time programmable memory” [e.g. Kelly; Para. 0022-0028 – Kelly discloses verification of measurements based on a public key retrieved from a one-time programmable memory using a root of trust system that attest firmware images for components/devices t]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include, the above limitations in the invention as disclosed by DSP2058 and Forristal ensuring security of the hardware platform as disclosed in paragraph 0002 of Kelly.
Claim 11
DSP2058 teaches a method comprising:
receiving, at circuitry, a request to generate measurements for attestation of software executed by a device; generating the measurements, at the circuitry; and
signing the measurements, at the circuitry, and outputting the signed measurements, from the circuitry, to a circuitry that is to perform software attestation. [e.g. DSP2058; Page 10 Sec 5.2 “Authentication:, Page 10 Sec 5.3 “Security Platform and Data Model (SPDM) architecture” Page 17-23 Sec 7-7.5.2“Certificates (entirety)” Page 24-29 Sec 8-8.2.2 (“SPDM message “entirety”), Page 30-32 Sec 9-9.4 “Attestation and security policies (entirety)” – herein DSP2058 discloses a platform management subsystem in a modern enterprise computer platform is comprised of a set of components which is comprised of one or more mutable elements, such as firmware or software, wherein components comprises various device types (such as CPUs, PCIe adapters, etc.) and for providing a mechanisms to authenticate a component thru the retrieval of a signed measurement payload of mutable components from a component that represents a signed hashed value. Page 33 of DSP2058 references the SPDM specification 1.0.0 (DSP0274 which is incorporated by reference) and the examiner points to pages Sec 4.6.3 of DSP0274 that defines measurement as calculating the cryptographic hash value of a piece of firmware (firmware image)/ software or configuration data (executable binary and device state) and Sec 4.10.1-4.10.1.5 of DSP0274 that discloses the measurement process.]
While DSP2058 teaches the apparatus of claim 1 DSP2058 fails to explicitly teach that the sole generator of measurements is a particular circuit. More specifically DSP2058 fails to teach the claimed limitations of however, Forristal teaches:
“wherein the circuitry is a sole generator of the measurements” [e.g. Forristal; Para. 0002, 0009, 0012, 0020, 0021, 0026, 0025, 0029, 0030 – discloses a system for verifying the integrity of firmware/code of individual components (e.g. devices) using an integrity measurement logic 214 is present, which can include hardware to perform integrity checks on the firmware and/or other code of the device responsive to a trigger received from an external entity. In general, the integrity measurement logic can be an embedded fixed function hardware unit configured to perform integrity analysis which is entirely implemented and serviced by hardware. This has been interpreted to mean this hardware logic is isolated and capable of generating measurements for the attestation process being the sole entity. The measurements are provided to an external entity separate from the integrity measurement logic.]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include, the above limitations in the invention as disclosed by DSP2058 in order to prevent malicious firmware from affecting the reported measure of itself as disclosed in paragraph 0029 of Forristal.
While the combination teaches the method of claim 11 the combination fails to explicitly teach verifying the measurements. More specifically the combination fails to teach the claimed limitations of however, Kelly teaches:
“verifying the measurements, at the circuitry” [e.g. Kelly; Para. 0022-0028 – Kelly discloses verification of measurements based on a fused public key retrieved from a one-time programmable memory using a root of trust system that attest firmware images for components/devices.]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include, the above limitations in the invention as disclosed by DSP2058 and Forristal ensuring security of the hardware platform as disclosed in paragraph 0002 of Kelly.
Claim 12:
The Combination of DSP2058 and Forristal teaches the method of claim 11, wherein the measurements are based on one or more of: firmware image file, software executable binary, device state, and/or fuse measurements. [e.g. DSP2058; Page 10 Sec 5.2 “Authentication:, Page 10 Sec 5.3 “Security Platform and Data Model (SPDM) architecture” Page 17-23 Sec 7-7.5.2“Certificates (entirety)” Page 24-29 Sec 8-8.2.2 (“SPDM message “entirety”), Page 30-32 Sec 9-9.4 “Attestation and security policies (entirety)” – herein DSP2058 discloses a platform management subsystem in a modern enterprise computer platform is comprised of a set of components which is comprised of one or more mutable elements, such as firmware or software, wherein components comprises various device types (such as CPUs, PCIe adapters, etc.) and for providing a mechanisms to authenticate a component thru the retrieval of a signed measurement payload of mutable components from a component that represents a signed hashed value. Page 33 of DSP2058 references the SPDM specification 1.0.0 (DSP0274 which is incorporated by reference) and the examiner points to pages Sec 4.6.3 of DSP0274 that defines measurement as calculating the cryptographic hash value of a piece of firmware/ software or configuration data and Sec 4.10.1-4.10.1.5 of DSP0274 that discloses the measurement process.] [e.g. Forristal; Para. 0002, 0009, 0012, 0020, 0021, 0026, 0025, 0029, 0030 – discloses a system for verifying the integrity of firmware/code of individual components (e.g. devices) using an integrity measurement logic 214 is present, which can include hardware to perform integrity checks on the firmware and/or other code of the device responsive to a trigger received from an external entity. In general, the integrity measurement logic can be an embedded fixed function hardware unit configured to perform integrity analysis which is entirely implemented and serviced by hardware. This has been interpreted to mean this hardware logic is isolated and capable of generating measurements for the attestation process being the sole entity. The measurements are provided to an external entity separate from the integrity measurement logic.]
Claim 13:
The Combination of DSP2058 and Forristal teaches the method of claim 11, wherein generating measurements comprises performing a cryptographic hash over one or more of: firmware image file, software executable binary, device state, and/or fuse measurements. [e.g. DSP2058; Page 10 Sec 5.2 “Authentication:, Page 10 Sec 5.3 “Security Platform and Data Model (SPDM) architecture” Page 17-23 Sec 7-7.5.2“Certificates (entirety)” Page 24-29 Sec 8-8.2.2 (“SPDM message “entirety”), Page 30-32 Sec 9-9.4 “Attestation and security policies (entirety)” – herein DSP2058 discloses a platform management subsystem in a modern enterprise computer platform is comprised of a set of components which is comprised of one or more mutable elements, such as firmware or software, wherein components comprises various device types (such as CPUs, PCIe adapters, etc.) and for providing a mechanisms to authenticate a component thru the retrieval of a signed measurement payload of mutable components from a component that represents a signed hashed value. Page 33 of DSP2058 references the SPDM specification 1.0.0 (DSP0274 which is incorporated by reference) and the examiner points to pages Sec 4.6.3 of DSP0274 that defines measurement as calculating the cryptographic hash value of a piece of firmware/ software or configuration data and Sec 4.10.1-4.10.1.5 of DSP0274 that discloses the measurement process.] [e.g. Forristal; Para. 0002, 0009, 0012, 0020, 0021, 0026, 0025, 0029, 0030 – discloses a system for verifying the integrity of firmware/code of individual components (e.g. devices) using an integrity measurement logic 214 is present, which can include hardware to perform integrity checks on the firmware and/or other code of the device responsive to a trigger received from an external entity. In general, the integrity measurement logic can be an embedded fixed function hardware unit configured to perform integrity analysis which is entirely implemented and serviced by hardware. This has been interpreted to mean this hardware logic is isolated and capable of generating measurements for the attestation process being the sole entity. The measurements are provided to an external entity separate from the integrity measurement logic.]
Claim 14:
DSP2058 teaches the method of claim 11, comprising: creating, by the circuitry, a key pair comprising a private key and a public key. [e.g. DSP2058; Page 17-23 Sec 7-7.5.2“Certificates (entirety) – DSP2058 discloses internal key generation and the CA is in possession of the public key backed by a root certificate.]
Claim 15:
The Combination of DSP2058 and Forristal teaches the method of claim 14, wherein the outputting the signed measurements comprises: providing the signed measurements in one or more messages, and signing the one or more messages based on the private key generated by the circuitry. [e.g. DSP2058; Page 10 Sec 5.2 “Authentication:, Page 10 Sec 5.3 “Security Platform and Data Model (SPDM) architecture” Page 17-23 Sec 7-7.5.2“Certificates (entirety)” Page 24-29 Sec 8-8.2.2 (“SPDM message “entirety”), Page 30-32 Sec 9-9.4 “Attestation and security policies (entirety)” – herein DSP2058 discloses a platform management subsystem in a modern enterprise computer platform is comprised of a set of components which is comprised of one or more mutable elements, such as firmware or software, wherein components comprises various device types (such as CPUs, PCIe adapters, etc.) and for providing a mechanisms to authenticate a component thru the retrieval of a signed measurement payload of mutable components from a component that represents a signed hashed value. Page 33 of DSP2058 references the SPDM specification 1.0.0 (DSP0274 which is incorporated by reference) and the examiner points to pages Sec 4.6.3 of DSP0274 that defines measurement as calculating the cryptographic hash value of a piece of firmware/ software or configuration data and Sec 4.10.1-4.10.1.5 of DSP0274 that discloses the measurement process including inserting the measurements and signing with a private key.] [e.g. Forristal; Para. 0002, 0009, 0012, 0020, 0021, 0026, 0025, 0029, 0030 – discloses a system for verifying the integrity of firmware/code of individual components (e.g. devices) using an integrity measurement logic 214 is present, which can include hardware to perform integrity checks on the firmware and/or other code of the device responsive to a trigger received from an external entity. In general, the integrity measurement logic can be an embedded fixed function hardware unit configured to perform integrity analysis which is entirely implemented and serviced by hardware. This has been interpreted to mean this hardware logic is isolated and capable of generating measurements for the attestation process being the sole entity. The measurements are provided to an external entity separate from the integrity measurement logic.]
Claim 16:
DSP2058 teaches the method of claim 15, wherein the one or more messages are based on a Security Protocol and Data Model (SPDM) protocol.. [e.g. DSP2058; Page 10 Sec 5.2 “Authentication:, Page 10 Sec 5.3 “Security Platform and Data Model (SPDM) architecture” Page 17-23 Sec 7-7.5.2“Certificates (entirety)” Page 24-29 Sec 8-8.2.2 (“SPDM message “entirety”), Page 30-32 Sec 9-9.4 “Attestation and security policies (entirety)” – herein DSP2058 discloses a platform management subsystem in a modern enterprise computer platform is comprised of a set of components which is comprised of one or more mutable elements, such as firmware or software, wherein components comprises various device types (such as CPUs, PCIe adapters, etc.) and for providing a mechanisms to authenticate a component thru the retrieval of a signed measurement payload of mutable components from a component that represents a signed hashed value. Page 33 of DSP2058 references the SPDM specification 1.0.0 (DSP0274 which is incorporated by reference) and the examiner points to pages Sec 4.6.3 of DSP0274 that defines measurement as calculating the cryptographic hash value of a piece of firmware/ software or configuration data and Sec 4.10.1-4.10.1.5 of DSP0274 that discloses the measurement process.]
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 CHRISTOPHER C HARRIS whose telephone number is (571)270-7841. The examiner can normally be reached Monday through Friday between 8:00 AM to 4:00 PM CST.
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, Jeffrey L Nickerson can be reached on (469) 295-9235. 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.
/CHRISTOPHER C HARRIS/Primary Examiner, Art Unit 2432