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 .
Detailed action
1. Status of Claims:
Claims 1-20 are pending in this Office Action.
Information Disclosure Statement
2. The information disclosure statement (IDS) submitted on 03/07/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 § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
3. Claims 1-9 and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over US 2025/0245306 issued to Kollarapu et al. (Kollarapu) in view of US 2022/0171851 issued to Tsirkin et al. (Tsirkin).
As per claim 1, Kollarapu teaches a computer system comprising: a processor set; one or more computer-readable storage media (Kollarapu: Fig. 4); and program instructions stored on the one or more computer-readable storage media to cause the processor set to perform operations (Kollarapu: ¶ 0119 - execution of the instructions may cause the digital processors to initiate performance of the processes) comprising: obtaining, by an operating system service and from a program running on a device, a call indicative of a target central processor assist cryptographic facility (CPACF) instruction associated with the device (Kollarapu: Claim 16, Claim 10 - obtaining, by a management controller of the data processing system, component data for components of the hardware resources; performing, by the management controller, a validation of the components using the component data and a certificate to identify a validation state of the components; wherein the certificate is a cryptographically verifiable data structure, and the data structure comprises information usable to identify the components of the hardware resources) and an instruction firmware code level (IFCL) hash associated with the target CPACF instruction (Kollarapu: ¶ 0084 - Certificate may include, for example, signatures (e.g., hashes of firmware code or other readable data));
Kollarapu however does not explicitly teach performing, by the operating system service and based on the call, a query of a cryptographic certification library to generate a query result; and providing, based on the query, the query result to the program.
Tsirkin however explicitly teaches performing, by the operating system service and based on the call, a query of a cryptographic certification library to generate a query result; and providing, based on the query, the query result to the program (Tsirkin: ¶ 0025, ¶ 0026 - compare the current firmware version 335 to the one or more certified versions of firmware associated with the peripheral device 330 the firmware validation module 140 may compare a hash of the current firmware version 335 to the one or more certified versions of firmware associated with the peripheral device 330. Alternatively, the firmware validation module 140 may compare a signature included in the current firmware version 335 to known signatures of one or more versions of firmware associated with the peripheral device 330 trusted by the computer system and in response to determining that the current firmware version 335 is trusted by the computer system 300, the firmware validation module 140 may write a trusted signature to the current firmware version).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Kollarapu in view of Tsirkin to teach performing, by the operating system service and based on the call, a query of a cryptographic certification library to generate a query result; and providing, based on the query, the query result to the program. One would be motivated to do so as the current firmware version to the one or more certified versions of firmware associated with the peripheral device the firmware validation module may compare a hash of the current firmware version to the one or more certified versions of firmware associated with the peripheral device. Alternatively, the firmware validation module may compare a signature included in the current firmware version to known signatures of one or more versions of firmware associated with the peripheral device trusted by the computer system and in response to determining that the current firmware version is trusted by the computer system, the firmware validation module may write a trusted signature to the current firmware version (Tsirkin: ¶ 0025, ¶ 0026).
As per claim 2, the modified teaching of Kollarapu teaches the computer system of claim 1, wherein the query result indicates that the IFCL hash associated with the target CPACF instruction is not a certified IFCL hash (Tsirkin: ¶ 0019, Fig. 5 - the firmware validation module 140 may use any method for validating the firmware 115 such as comparing a hash of the firmware 115 to certified firmware or comparing a firmware signature with signatures of certified firmware).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Kollarapu in view of Tsirkin to teach wherein the query result indicates that the IFCL hash associated with the target CPACF instruction is not a certified IFCL hash. One would be motivated to do so as the firmware validation module may use any method for validating the firmware such as comparing a hash of the firmware to certified firmware or comparing a firmware signature with signatures of certified firmware (Tsirkin: ¶ 0019, Fig. 5).
As per claim 3, the modified teaching of Kollarapu teaches the computer system of claim 1, wherein the query result indicates that the IFCL hash associated with the target CPACF instruction is a certified IFCL hash (Tsirkin: ¶ 0019, Fig. 5 - the firmware validation module 140 may use any method for validating the firmware 115 such as comparing a hash of the firmware 115 to certified firmware or comparing a firmware signature with signatures of certified firmware).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Kollarapu in view of Tsirkin to teach wherein the query result indicates that the IFCL hash associated with the target CPACF instruction is a certified IFCL hash. One would be motivated to do so as the firmware validation module may use any method for validating the firmware such as comparing a hash of the firmware to certified firmware or comparing a firmware signature with signatures of certified firmware (Tsirkin: ¶ 0019, Fig. 5).
As per claim 4, the modified teaching of Kollarapu teaches the computer system of claim 1, wherein performing the query comprises querying a set of certified IFCL hash lists for a match between the IFCL hash associated with the target CPACF instruction and a certified IFCL hash (Tsirkin: ¶ 0021 - the firmware validation module 140 may apply a hash to the firmware 235 and compare the hash to the trusted firmware versions).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Kollarapu in view of Tsirkin to teach wherein performing the query comprises querying a set of certified IFCL hash lists for a match between the IFCL hash associated with the target CPACF instruction and a certified IFCL hash. One would be motivated to do so as the firmware validation module may apply a hash to the firmware and compare the hash to the trusted firmware versions (Tsirkin: ¶ 0021).
As per claim 5, the modified teaching of Kollarapu teaches the computer system of claim 4, further comprising: obtaining, by the operating system and from a certificate authority, a plurality of certified IFCL hashes; and generating, in the cryptographic certification library, the set of certified IFCL hash lists, each IFCL hash list of the set of certified IFCL hash lists corresponding to a respective CPACF instruction of a set of CPACF instructions (Tsirkin: ¶ 0037 - to validate the firmware, the processing logic may compare a hash of the entire firmware code to firmware versions that are certified and trusted by the computer system. For example, the processing logic may determine whether the current firmware version is trusted by a hypervisor of the computer system and the processing logic may then compare the identified signature with a list of certified and trusted firmware version signatures).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Kollarapu in view of Tsirkin to teach obtaining, by the operating system and from a certificate authority, a plurality of certified IFCL hashes; and generating, in the cryptographic certification library, the set of certified IFCL hash lists, each IFCL hash list of the set of certified IFCL hash lists corresponding to a respective CPACF instruction of a set of CPACF instructions. One would be motivated to do so as to validate the firmware, the processing logic may compare a hash of the entire firmware code to firmware versions that are certified and trusted by the computer system. For example, the processing logic may determine whether the current firmware version is trusted by a hypervisor of the computer system and the processing logic may then compare the identified signature with a list of certified and trusted firmware version signatures (Tsirkin: ¶ 0037).
As per claim 6, the claim resembles claim 1 and is rejected under the same rationale.
As per claim 7, the modified teaching of Kollarapu teaches the computer-implemented method of claim 6, wherein the action comprises: refraining from using the target CPACF instruction if the query result indicates that the IFCL hash is not a certified IFCL hash (Tsirkin: ¶ 0011 - If the firmware's signature does not match the device vendor's signature, the smart device may prevent the download of the firmware).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Kollarapu in view of Tsirkin to teach wherein the action comprises: refraining from using the target CPACF instruction if the query result indicates that the IFCL hash is not a certified IFCL hash. One would be motivated to do so as if the firmware's signature does not match the device vendor's signature, the smart device may prevent the download of the firmware (Tsirkin: ¶ 0011).
As per claim 8, the modified teaching of Kollarapu teaches the computer-implemented method of claim 7, further comprising: reporting that the target CPACF instruction will not be used (Kollarapu: ¶ 0144 - the validation failure may be reported by sending (e.g., by the management controller)).
As per claim 9, the modified teaching of Kollarapu teaches the computer-implemented method of claim 6, wherein the action comprises: using the target CPACF instruction if the query result indicates that the IFCL hash is a certified IFCL hash (Tsirkin: ¶ 0019, Fig. 5 - the firmware validation module 140 may use any method for validating the firmware 115 such as comparing a hash of the firmware 115 to certified firmware or comparing a firmware signature with signatures of certified firmware).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Kollarapu in view of Tsirkin to teach wherein the query result indicates that the IFCL hash associated with the target CPACF instruction is a certified IFCL hash. One would be motivated to do so as the firmware validation module may use any method for validating the firmware such as comparing a hash of the firmware to certified firmware or comparing a firmware signature with signatures of certified firmware (Tsirkin: ¶ 0019, Fig. 5).
As per claim 15, the claim resembles claim 1 and is rejected under the same rationale while Kollarapu also teaches one or more computer-readable storage media; and program instructions stored on the one or more computer-readable storage media to perform operations (Kollarapu: claim 16 - a non-transitory machine-readable medium having instructions stored therein, which when executed by a processor, cause the processor to perform operations).
As per claim 16, the claim resembles claim 7 and is rejected under the same rationale.
As per claim 17, the claim resembles claim 9 and is rejected under the same rationale.
4. Claims 10-14 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 2025/0245306 issued to Kollarapu et al. (Kollarapu) in view of US 2022/0171851 issued to Tsirkin et al. (Tsirkin) and further in view of US 2021/0406376 issued to Sayapin et al. (Sayapin).
As per claim 10, the modified teaching of Kollarapu teaches the computer-implemented method of claim 6 however does not explicitly teach further comprising: determining that an IFCL version number associated with the IFCL hash has changed.
Sayapin however explicitly teaches determining that an IFCL version number associated with the IFCL hash has changed (Sayapin: ¶ 0034 - a TPM (Trusted Platform Module) module or other subsystem of the client device 106 can maintain a hash code or version number associated with the state of the firmware 139. When any value or setting in the firmware 139 is changed or updated, the hash code or version number can also change. Accordingly, the management agent 146 can detect such a change by communicating with the TPM).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the modified teaching of Kollarapu in view of Sayapin to teach determining that an IFCL version number associated with the IFCL hash has changed. One would be motivated to do so as a TPM (Trusted Platform Module) module or other subsystem of the client device can maintain a hash code or version number associated with the state of the firmware. When any value or setting in the firmware is changed or updated, the hash code or version number can also change. Accordingly, the management agent can detect such a change by communicating with the TPM (Sayapin: ¶ 0034).
As per claim 11, the modified teaching of Kollarapu in view of Sayapin teaches the computer-implemented method of claim 10, further comprising: reporting that the IFCL version number has changed (Sayapin: ¶ 0034 - the management agent 146 can detect such a change by communicating with the TPM or other module of the client device 106 that reflects the state of the BIOS. The management agent 146 can then notify the management service 111 of the change, which can cause the management service 111 to generate a request to update the password 141 of the firmware).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the modified teaching of Kollarapu in view of Sayapin to teach reporting that the IFCL version number has changed. One would be motivated to do so as the management agent can detect such a change by communicating with the TPM or other module of the client device that reflects the state of the BIOS. The management agent can then notify the management service of the change, which can cause the management service to generate a request to update the password of the firmware (Sayapin: ¶ 0034).
As per claim 12, the modified teaching of Kollarapu in view of Sayapin teaches the computer-implemented method of claim 11, wherein reporting that the IFCL version number has changed comprises: reporting that the IFCL version number has changed while the program is running (Sayapin: ¶ 0052 - teaches upon detecting that a setting has been changed, the management agent 146 can inform the management service 111 that a setting in the firmware 139 has been changed. The communication from the management agent 146 that a BIOS setting has changed can operate as a request to update the password 141 of the firmware; while ¶ 0061 - teaches the management agent 146 running on a client device 106 that is a managed device can update a password 141 in the firmware 139, such as in the BIOS of the client device).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the modified teaching of Kollarapu in view of Sayapin to teach wherein reporting that the IFCL version number has changed comprises: reporting that the IFCL version number has changed while the program is running. One would be motivated to do so as upon detecting that a setting has been changed, the management agent can inform the management service that a setting in the firmware has been changed. The communication from the management agent that a BIOS setting has changed can operate as a request to update the password of the firmware; while ¶ 0061 - teaches the management agent running on a client device that is a managed device can update a password in the firmware, such as in the BIOS of the client device (Sayapin: ¶ 0052, ¶ 0061).
As per claim 13, the modified teaching of Kollarapu in view of Sayapin teaches the computer-implemented method of claim 10, further comprising: stopping, based on determining that the IFCL version number has changed, use of the target CPACF instruction (Sayapin: ¶ 0049 - if no reset confirmation is received, the process can proceed to completion (stopping the process)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the modified teaching of Kollarapu in view of Sayapin to teach stopping, based on determining that the IFCL version number has changed, use of the target CPACF instruction. One would be motivated to do so as if no reset confirmation is received, the process can proceed to completion (stopping the process) (Sayapin: ¶ 0049).
As per claim 14, the modified teaching of Kollarapu teaches the computer-implemented method of claim 6 however does not explicitly teach further comprising: providing, in accordance with a periodicity, at least one additional call to the operating system service.
Sayapin however explicitly teaches providing, in accordance with a periodicity, at least one additional call to the operating system service (Sayapin: ¶ 0022 - commands relating to a firmware profile 126 or other firmware settings for a client device can be stored in the command queue 123 and at periodic intervals, the client device 106 can retrieve instructions from the respective command queue 123 for the client device).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the modified teaching of Kollarapu in view of Sayapin to teach providing, in accordance with a periodicity, at least one additional call to the operating system service. One would be motivated to do so as commands relating to a firmware profile or other firmware settings for a client device can be stored in the command queue and at periodic intervals, the client device can retrieve instructions from the respective command queue for the client device (Sayapin: ¶ 0022).
As per claim 18, the claim resembles claim 10 and is rejected under the same rationale.
As per claim 19, the claim resembles claim 11 and is rejected under the same rationale.
As per claim 20, the claim resembles claim 13 and is rejected under the same rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SM AZIZUR RAHMAN whose telephone number is (571) 270-7360. The examiner can normally be reached on M-F Telework;
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ali Shayanfar can be reached on 571-270-1050. 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.
/SM A RAHMAN/Primary Examiner, Art Unit 2434
Prosecution Insights