DETAILED ACTION
Office Action Summary
Claims 1-20 are pending in the instant application.
Claims 1-20 are rejected under 35 USC § 103.
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.
Oath/Declaration
The applicant’s oath/declaration has been reviewed by the examiner and is found to conform to the requirements prescribed in 37 C.F.R. 1.63.
Specification
The Specification filed on 01/17/2025 is accepted for examination purpose.
Drawings
The Drawings filed on 01/17/2025 are accepted for examination purpose.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 01/29/2025 was filed after the mailing date. The submission 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 § 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 may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 1-7 and 9-20 rejected under 35 U.S.C. 103 as being unpatentable over Benedict et al. (US 2026/0057060) hereinafter Benedict in view of Gupta (US 2025/0328333) hereinafter referred to as Gupta.
As per claims 1, 11, and 16, D1 teaches … during a startup of the data processing system (Benedict, Parag. [0041]; “FIG. 2 is a flow diagram of a process performed by the secure access logic 108 (a requester) and the electronic module 104 (a responder) for validated access of the electronic module 104. In some examples, the process of FIG. 2 may be performed after each power cycle of the compute platform 102, or more generally, when the compute platform 102 starts from a disabled state (e.g., power off state, low power state, or any other state in which the compute platform 102 is not operational). Messages exchanged in FIG. 2 may be according to the SPDM standard and may be transferred over the communications link 134 of FIG. 1 using the MCTP transfer protocol.”):
performing, by an entity of the data processing system and using identification data obtained from a hardware component of the data processing system using a security protocol and data model (SPDM) security standard, an analysis process to identify a level of trust for the hardware component, the identification data being usable to identify an acceptable manner of managing operation of the hardware component by the entity (Benedict, Parag. [0077]; “The extracted content includes the nonces n0 and n1 as well as the message digest M1, for example. The nonces can be used by the secure access logic 108 to confirm that data received from the electronic module 104 is not a replay of prior data, which may be performed by a replay attack. The secure access logic 108 compares the message digest M1 from the challenge response to the message digest M0 (the expected digest) generated by the secure access logic 108. If the message digests M0 and M1 match, then that indicates the electronic module 104 is an expected source and the data received from the electronic module 104 has not been modified.” … Parag. [0078]; “The secure access procedure 400 establishes that the electronic module 104 can be trusted based on authentication of the platform data 110 and the electronic components 114A to 114B of the electronic module 104. Additionally, the secure access logic 108 can confirm (based on use of the nonces n0 and n1) that accessed data from the electronic module 104 is fresh (i.e., the data is not a replay of prior data), transferred data from the electronic module 104 has not been modified (based on the secure access logic 108 being able to decrypt the signed challenge response), and the data originates from an expected source (the electronic module 104) based on a confirmation that the challenge response is signed with the private key of the electronic module 104.”);
identifying, based on the level of trust and an SPDM hardware component policy, at least one action to manage operation of the data processing system (Benedict, Parag. [0041]; “Messages exchanged in FIG. 2 may be according to the SPDM standard and may be transferred over the communications link 134 of FIG. 1 using the MCTP transfer protocol.” … Parag. [0042]; “The process of FIG. 2 includes an initialization exchange 202, a measurement exchange 204, and a communication validation exchange 206.” … Parag. [0049]; “After the initialization exchange 202, the secure access logic 108 in the electronic module 104 can perform the measurement exchange 204.”) … Parag. [0050]; “In the measurement exchange 204, the secure access logic 108 sends (at 232) a Measure Platform Data request to the electronic module 104. In response, the electronic module 104 sends (at 234) a Platform Data Measurement Response to the secure access logic 108.” … Parag. [0052]; “The secure access logic 108 sends (at 236) a Measure Component Information request to the electronic module 104. In response, the electronic module 104 sends (at 238) a Component Information Measurement Response to the secure access logic 108.”); and
Benedict does not expressly teach: performing the at least one action to reduce a likelihood of the data processing system being compromised.
However, Gupta teaches performing the at least one action to reduce a likelihood of the data processing system being compromised. (Gupta, Parag. [0043]; “The SPDM protocol facilitates the measurement of various firmware components to ensure their integrity and authenticity. These measurements can encompass a wide range of targets within the firmware. For example, measurements can be taken on the contents of the SPI flash memory, which often houses critical boot components and firmware images. Measurements can target individual partitions within the EMMC storage, verifying the integrity of specific sections of the firmware or operating system. The root file system, containing essential files and directories for system operation, can be measured to detect any unauthorized modifications or additions.” … Parag. [0047]; “Upon receiving the measurements, the requester can verify them against known good values (e.g., values obtained during a secure installation or previous measurements stored securely). This verification process can be performed locally or through a remote attestation service. If the measurements match the expected values, the integrity of the firmware is confirmed, and the system can be trusted to perform its operations securely.”);
Benedict and Gupta are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a method for executing at an startup process a method for determining if a hardware is a trusted one.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Gupta system into Benedict system, with a motivation to provide a method for determining the platform security based on obtained measurements (Gupta, Parag. [0043]).
As per claims 2, 12, and 17, D1 in view of D2 teaches … wherein performing the analysis process comprises: obtaining, by the entity and via an SPDM message exchange with the hardware component, the identification data; and identifying, by the entity and using at least the identification data and a store of trusted identification data, the level of trust for the hardware component. (Benedict, Parag. [0030]; “In some examples, the validated access of the electronic module 104 by the secure access logic 108 or any other requester can be according to the Security Protocols and Data Models (SPDM) standard promulgated by the DMTF’s SPDM Working group. The SPDM standard enables authentication, attestation, and key exchange to assist in providing infrastructure security.” … Parag. [0048]; “The secure access logic 108 further sends (at 224) a Get Digest request to the electronic module 104. In response, the electronic module 104 sends (at 226) a Digest Response that contains the attribute certificate 118. The secure access logic 108 further sends (at 228) a Get Device Certificate request to the electronic module 104. In response, the electronic module 104 sends (at 230) the public portion of the device certificate 120 (including the public key of the device certificate 120) to the secure access logic 108.”).
As per claims 3, 13, and 18, D1 in view of D2 teaches … wherein the identification data comprises a certificate for the hardware component, the certificate being cryptographically verifiable, and/or a digest of the certificate. (Benedict, Parag. [0062-0063]; “The device certificate 120 includes a public key 322 and a private key 324 of the electronic module 104. The public key 322 and the private key 324 form a public-private key pair. As shown in FIG. 3 , the private key 324 of the device certificate 120 is used by the controller 132 in the electronic module 104 to sign (at 376) a challenge response 330, such as by using a selected signature algorithm negotiated between the secure access logic 108 and the electronic module 104. The signing of the challenge response 330 produces a signature 332 that is part of the challenge response 330. The challenge response 330 is an example of the challenge response sent at 242 in FIG. 2 . The public key 322 of the device certificate 120 can be shared with the secure access logic 108 of FIG. 1 (such as at 230 in FIG. 2 ). The public key 322 can be used to decrypt the signed challenge response 330 so that the content (e.g., including the nonces and message digest M1) of the challenge response 330 can be extracted by the secure access logic 108.”).
As per claims 4, 14, and 19, D1 in view of D2 teaches … wherein the digest is obtained by applying a predetermined function to the certificate. (Benedict, Parag. [0030]; “In some examples, the validated access of the electronic module 104 by the secure access logic 108 or any other requester can be according to the Security Protocols and Data Models (SPDM) standard promulgated by the DMTF’s SPDM Working group. The SPDM standard enables authentication, attestation, and key exchange to assist in providing infrastructure security.” … Parag. [0048]; “The secure access logic 108 further sends (at 224) a Get Digest request to the electronic module 104. In response, the electronic module 104 sends (at 226) a Digest Response that contains the attribute certificate 118. The secure access logic 108 further sends (at 228) a Get Device Certificate request to the electronic module 104. In response, the electronic module 104 sends (at 230) the public portion of the device certificate 120 (including the public key of the device certificate 120) to the secure access logic 108.”).
As per claims 5, 15, and 20, D1 in view of D2 teaches … wherein the level of trust comprises at least one level of trust selected from a list consisting of: trusted; untrusted; and indeterminate. (Gupta, Parag. [0063]; “The traditional approach to SPDM measurements assumes a static firmware configuration, where the measurements remain constant. However, in a dynamic scenario where firmware components can be updated or added at runtime, the measurements will change. If there is a difference in the measurements, other devices will refuse to communicate with the BMC, as they will perceive the changes as potentially untrusted.”).
As per claim 6, D1 in view of D2 teaches … wherein the SPDM hardware component policy comprises actions keyed to levels of trust for hardware components, and the SPDM hardware component policy is obtained from a management entity of the data processing system. (Gupta, Parag. [0063]; “The traditional approach to SPDM measurements assumes a static firmware configuration, where the measurements remain constant. However, in a dynamic scenario where firmware components can be updated or added at runtime, the measurements will change. If there is a difference in the measurements, other devices will refuse to communicate with the BMC, as they will perceive the changes as potentially untrusted.”).
As per claim 7, D1 in view of D2 teaches … wherein the SPDM hardware component policy comprises the actions keyed to types of SPDM hardware components. (Benedict, Parag. [0001]; “A compute platform includes various electronic components, such as processors, memory modules, input/output (I/O) devices, management controllers, and other electronic components. The compute platform can store data used for configuring, initializing, and managing the compute platform.” … Parag. [0029]; “In some examples, a transport protocol such as a Management Component Transport Protocol (MCTP) can be used for messages exchanged over the communication link 134. MCTP is a protocol defined by the Distributed Management Task Force (DMTF) to support management-related communications between electronic components. In other examples, other types of protocols relating to management-related communications can be used, such as the Intelligent Platform Management Interface (IPMI) protocol, or another protocol.”),
As per claim 9, D1 in view of D2 teaches … wherein the SPDM security standard is a data model for hardware components of data processing systems, the SPDM security standard specifying, at least, methods of security communication between the hardware components, minimum standards of data to be made available to other hardware components, and security information to be made available to the other hardware components. (Benedict, Parag. [0030]; “In some examples, the validated access of the electronic module 104 by the secure access logic 108 or any other requester can be according to the Security Protocols and Data Models (SPDM) standard promulgated by the DMTF’s SPDM Working group. The SPDM standard enables authentication, attestation, and key exchange to assist in providing infrastructure security.”).
As per claim 10, D1 in view of D2 teaches … wherein the entity of the data processing system is a basic input-output system (BIOS). (Benedict, Parag. [0001]; “A compute platform includes various electronic components, such as processors, memory modules, input/output (I/O) devices, management controllers, and other electronic components. The compute platform can store data used for configuring, initializing, and managing the compute platform.” … Parag. [0029]; “In some examples, a transport protocol such as a Management Component Transport Protocol (MCTP) can be used for messages exchanged over the communication link 134. MCTP is a protocol defined by the Distributed Management Task Force (DMTF) to support management-related communications between electronic components. In other examples, other types of protocols relating to management-related communications can be used, such as the Intelligent Platform Management Interface (IPMI) protocol, or another protocol.”)
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Benedict et al. (US 2026/0057060) hereinafter Benedict in view of Gupta (US 2025/0328333) hereinafter referred to as Gupta and further in view of Radhakrishnan et al. (US 2024/0296227) hereinafter Radhakrishnan.
As per claim 8, D1 in view of D2 does not teach … wherein the at least one action to manage operation of the data processing system comprises at least one action selected from a list of actions consisting of: preventing the hardware component from performing at least a portion of its functionality; allowing the hardware component to perform at least a portion of its functionality; performing, by the entity, a measurement process using the SPDM security standard for the hardware component; logging information regarding the hardware component; and quarantining the hardware component. (Radhakrishnan, Parag. [0021]; “As will be described in detail herein below, embodiments of the present disclosure, systems and methods to prevent cloning of firmware with vulnerabilities are described in which a first node, such as a BMC, identifies that a second node in a certificate chain possesses a private key, and performs a performs challenge-response verification to establish proof of possession of the private key, and if the challenge-response fails, inhibits operation of the second node based upon the challenge-response verification. The solution may, for example, prevent counterfeits and damage by preventing exploits of firmware vulnerabilities.” … Parag. [0039]; “According to embodiments of the present disclosure, when a device certificate node 202 c recognizes that the alias intermediate CA node 202 d possesses a private key 204 d stored in that node, it performs a challenge-response verification to establish proof of possession of the private key, and inhibits operation of the alias intermediate CA node 202 d based upon the challenge-response verification. For example, if the device certificate node 202 c determines that the challenge-response verification passes, it continues to let the alias intermediate CA node 202 d sign the alias certificate node 202 e. In the case in which the alias certificate node 202 e is a firmware update, it is allowed to be deployed on its associated SPDM-enabled device of the IHS 100. If, however, the device certificate node 202 c determines that the challenge-response verification fails, it inhibits the alias intermediate CA node 202 d from signing the alias certificate node 202 e such that, for the example in which the alias certificate node 202 e is a firmware update, inhibits the firmware update from being deployed on its associated component of the IHS 100.”)
Benedict, Gupta and Radhakrishnan are from similar field of technology. Prior to the instant application’s effective filling date, there was a need for a method for executing at an startup process a method for determining if a hardware is a trusted one.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Radhakrishnan system into Benedict-Gupta system, with a motivation to provide a method for inhibit a hardware platform to execute operations if not trusted level has been determined (Radhakrishnan, Parag. [0021]).
Other Art of Record
Hardjono et al. (US 2007/0143629) relates to a client platform can be verified prior to being granted access to a resource or service on a network by validating individual hardware and software components of the client platform. Digests are generated for the components of the client platform. The digests can be collected into an integrity report. An authenticator entity receives the integrity report and compares the digests with digests stored in either a local signature database, a global signature database in an integrity authority, or both. Alternatively, the digests can be collected and stored on a portable digest-collector dongle. Once digests are either validated or invalidated, an overall integrity/trust score can be generated. She overall integrity/ trust score can be used to determine whether the client platform should be granted access to the resource on the network using a policy.
Keidar et al. (US 9749141) relates to a secure boot method includes: obtaining a certificate digest at a digest processor from a write-once, always-on memory; calculating a flash digest using the digest processor by cryptographically processing a sensitive information image; and comparing, using the digest processor, the flash digest with the certificate digest.
Keohane et al. (WO 2024079483) (Keohane, Abstract; “Responsive to verifying the digital certificate, a digital digest is calculated for the application to form a calculated digital digest. The calculated digital digest is compared with a set of digital digests from a trusted source.” … Summary, page 3; “Preferably, the set of digital digests is stored on the data processing system.” … Description, page 12; “Additionally, depending on the particular implementation, the digital digests from the trusted source may be stored locally at the node.”)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SIMON P KANAAN whose telephone number is (571)270-3906. The examiner can normally be reached on M-F (7AM-4PM).
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, Catherine Thiaw can be reached on (571) 272-1183. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SIMON P KANAAN/Primary Examiner, Art Unit 2407
Prosecution Insights