DETAILED ACTION
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 .
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 11-15 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.
Claim 11 recites “performing” using the startup security measurement and the runtime security measurements, a third partial evaluation result. “The first two clauses recite performing an “evaluation process to obtain” a partial evaluation result. The third clause has no such process, and one does not “perform” a result. The scope of the third partial evaluation is therefore unclear to the examiner. For examination, the clause is interpreted as “performing, using the startup security third partial evaluation result.” Appropriate correction is required.
Claims 12-15, which depend on claim 11, are also rejected for being depended upon claim 11.
Allowable Subject Matter
Claims 2, 8-10, 16, 18 and 20 objected to as being dependent upon a rejected base claim but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claims 11-15 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1,3-7,17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Universal Scalable Firmware (USF) (published in October 2021) in view of Tianocore (Understanding the Trusted Boot Chain implementation)
Regarding Claim 1 USF teaches a method for managing operation of a data processing system, the method comprising: after a startup of the data processing system [5.2.4.2, firmware indicates the firmware loaded,]: making an identification that a hardware component of the data processing system is to be used to evaluate a security posture of the data processing system; [5.2.4.2 A firmware is classified by type (e.g., NIC, NVMe, graphics card)]
based on the identification: obtaining, based at least in part on a security protocol and data model (SPDM) security standard, a set of dynamic measurements, the set of dynamic measurements comprising [5.1.3.3 and 5.2.4.2, the platform follows the DMTF SPDM spec to record device measurements, and firmware obtains device measurement over SPDM at runtime and put them into TPM PCR, Fig.15 and Fig.16]:
first measurements that indicate a first security state of the data processing system during the startup,
second measurements that indicate a second security state of the data processing system after the startup, [5.2.4.2, At runtime, the system firmware may use a standard way - SPDM protocol - to obtain the measurement from the device and put it into TPM PCR according to TCG PC Client Specific Platform Firmware Profile Specification. ] and
at least one reference measurement obtained from a trusted entity; [5.2.4.2, the component provider supplies a RIM or device firmware manifest]
evaluating, using the set of dynamic measurements, the security posture; and managing operation of the data processing system based on the security posture to reduce a likelihood of the data processing system being compromised. [5.2.4.2, the verifier can get the runtime value from the TCG event log and compare it with the reference value in the device RIM. Figure 16 shows the Type-II firmware component RIM concept.]
Regarding Claim 1 USF does not teach first measurements that indicate a first security state of the data processing system during the startup,
However, Tianocore teaches first measurements that indicate a first security state of the data processing system during the startup, [PCR 2, PCR 3, during boot, device firmware (immutable ROM and mutable firmware) and its configuration are measured into PCR 2 and PCR 3]
Therefore, it would have been obvious to one of the ordinary skilled in the art to which this invention pertains before the effective filing date of the invention to implement USF’s SPDM device-measurement scheme using TianoCore’s EDK II boot time SPDM measurement and event log flow to allows the host or baseboard management controller (BMC) to cryptographically verify the firmware integrity and identity of connected hardware components before granting system access.
Regarding Claim 3 Tianocore teaches the first measurements comprise startup security measurements obtained, based on the SPDM security standard, from the hardware component during the startup, the startup security measurements being usable to validate authenticity and/or integrity of software hosted by the hardware component. [PCR 2, device firmware measurements (immutable ROM and mutable firmware) are recorded at boot]
Regarding Claim 4 Tianocore teaches the first measurements are stored as part of a platform configuration register (PCR) of a trusted platform module (TPM) of the data processing system and/or in an entry of a TPM event log. [General Guideline and PCR 2/3, PCR extend plus event-log entries that can reproduce the PCR value]
Regarding Claim 5 USF teaches the second measurements comprise runtime security measurements obtained, based on the SPDM security standard, from the hardware component after the startup, the runtime security measurements being usable to validate the authenticity and/or the integrity of the software hosted by the hardware component. [5.2.4.2. Runtime SPDM measurement compared against the device RIM]
Regarding Claim 6 USF teaches the at least one reference measurement comprises: a reference integrity manifest (RIM) corresponding to the hardware component, and a RIM corresponding to the data processing system. [5.2.4.2. component-level RIM plus a platform-level RIM and certificate.]
Regarding Claim 7 Tianocore teaches obtaining the set of dynamic measurements comprises: obtaining, via at least an interaction with a trusted platform module (TPM) of the data processing system and using a TPM event log, the first measurements. [“Remote Attestation” A TPM quote and event log are obtained and passed to a verifier]
Regarding Claim 17 SUF teaches: A non-transitory machine-readable medium having instructions stored therein, [1.4 USF layer,] which when executed by a processor, [SoC (System on Chip) corresponds to processor] cause the processor to perform operations [Fig.1, as shown in Fig1. IP FW is loaded from the memory to SCO to execute task in Platform Orchestration Layer]
for managing operation of a data processing system, the operations comprising: after a startup of the data processing system: making an identification that a hardware component of the data processing system is to be used to evaluate a security posture of the data processing system; based on the identification: obtaining, based at least in part on a security protocol and data model (SPDM) security standard, a set of dynamic measurements, the set of dynamic measurements comprising: first measurements that indicate a first security state of the data processing system during the startup, second measurements that indicate a second security state of the data processing system after the startup, and at least one reference measurement obtained from a trusted entity; evaluating, using the set of dynamic measurements, the security posture; and managing operation of the data processing system based on the security posture to reduce a likelihood of the data processing system being compromised. [operation of claim 1 on a medium and rejected on the same gourd of rejection as claim 1 above.]
Regarding Claim 19 SUF teaches: A data processing system, [1.4 USF layer] comprising: a processor; [SoC (System on Chip) corresponds to processor] and a memory coupled to the processor to store instructions,[Fig.1, Memory] which when executed by the processor, cause the processor to perform operations for managing operation of a data processing system, [Fig.1, as shown in Fig1. IP FW is loaded from the memory to SCO to execute task in Platform Orchestration Layer]
the operations comprising: after a startup of the data processing system: making an identification that a hardware component of the data processing system is to be used to evaluate a security posture of the data processing system; based on the identification: obtaining, based at least in part on a security protocol and data model (SPDM) security standard, a set of dynamic measurements, the set of dynamic measurements comprising: first measurements that indicate a first security state of the data processing system during the startup, second measurements that indicate a second security state of the data processing system after the startup, and at least one reference measurement obtained from a trusted entity; evaluating, using the set of dynamic measurements, the security posture; and managing operation of the data processing system based on the security posture to reduce a likelihood of the data processing system being compromised. [operation of claim 1 on a medium and rejected on the same gourd of rejection as claim 1 above.]
Citation of Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Vajravel et al. (Patent No. US 12,406,064) teaches determining, by a processor, a pre-boot security posture of an information handling system by capturing state of a basic input/output system (BIOS) security indicator during a boot device selection phase of a boot process. wherein the pre-boot security posture indicates a pre-boot security status of an external device associated with the information handling system; updating an advanced configuration and power interface mitigation table based on the pre-boot security posture according to the state of the BIOS security indicator; receiving a security mitigation policy; updating a security mitigation table based on the security mitigation policy; determining a security mitigation corresponding to the pre-boot security posture captured during the boot device selection phase of the boot process, wherein the security mitigation is based on a protection flag in the advanced configuration and power interface mitigation table and the security mitigation table; and applying the security mitigation by an operating system to mitigate the pre-boot security status of the external device.
Ponnuru et al. (Pub No. US 2024/0313983) teaches the security protocol and data model (SPDM)-enabled device has a processor coupled to a memory (110), where the memory contains program instructions that cause the device to receive a request to provision a certificate chain on the device. The device sends an event notification message to a baseboard management controller (BMC) (104), where the event notification message indicates receipt of a slot provisioning request. The device receives a validation message from the BMC indicating either that the certificate chain is valid or not. The device enters a quarantine state until the chain is successfully validated by the BMC.
Potlapally et al. (Patent No. US 10,409,985) teaches a trusted computing host is described that provides various security computations and other functions in a distributed multitenant and/or virtualized computing environment. The trusted host computing device can communicate with one or more host computing devices that host virtual machines to provide a number of security-related functions, including but not limited to boot firmware measurement, cryptographic key management, remote attestation, as well as security and forensics management. The trusted computing host maintains an isolated partition for each host computing device in the environment and communicates with peripheral cards on host computing devices in order to provide one or more security functions.
Thankappan et al. (Pub No. US 2024/0281515) teaches he Information Handling System (IHS) (420)comprises a Security Protocol and Data Model (SPDM)-enabled device conforming to a SPDM specification, a processor, and a memory coupled to the processor. The memory has program instructions stored on it, which upon execution, cause the IHS to obtain a SPDM-based measurement of a license associated with the SPDM-enabled device. The measurement is compared against a Reference Integrity Measurement (RIM) (406) initially generated for the SPDM-enabled device. When the measurement and the RIM do not match, an alert message indicating that the license is invalid, is generated.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZAHID CHOUDHURY whose telephone number is (571)270-5153. The examiner can normally be reached Monday-Friday.
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, Andrew J Jung can be reached at 571-270-3779. 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.
/ZAHID CHOUDHURY/ Primary Examiner, Art Unit 2175
Prosecution Insights