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 .
This application has been examined. Claims 1-20 are pending.
The Group and/or Art Unit location of your application in the PTO has changed. To aid in correlating any papers for this application, all further correspondence regarding this application should be directed to Group Art Unit 2175.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
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 t which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under AIA 35 U.S.C. § 103 as being unpatentable over Nelson et al. (“Nelson”) (US No. 11,347,519) in view of Brumley et al. (“Brumley”) (US No. 8,078,865).
In order to expedite and avoid piecemeal prosecution, the following rejection is made to the extent that the claims are understood, by considering those elements which are understood and interpreting their function in a manner which is consistent with the recited goals of the claims, and then applying the best available art.
The examiner relies on the entire teachings of Nelson and Brumley references; the applicant should carefully consider the entire teachings of the above-mentioned references to better understand the examiner’s position.
In regard to claims 1, 8, 14, Nelson discloses an IHS, a method, a Basic Input/Output System (BIOS) secure boot configuration modification source reporting system, comprising: a computing device; a non-volatile memory subsystem that is housed in the computing device; and a Basic Input/Output System (BIOS) that is housed in the computing device, that is coupled to the non-volatile memory subsystem (as shown in Fig. 2, which is reproduced below for ease of reference and convenience, Nelson discloses an information handling system (computing device) comprising a processor, memory, and BIOS firmware configured to detect, record, and report changes to BIOS configuration across boot sessions. See abstract, col. 6:6-32: system architecture includes computing device with non-volatile memory (TPM NV index/crypto-processor NV memory) and BIOS program of instructions that includes direct structural correspondence to claimed system elements),
PNG
media_image1.png
1057
735
media_image1.png
Greyscale
and that includes: a BIOS database storing a secure boot configuration (in Nelson, col. 6:36-50: BIOS firmware 192 stored in BIOS NV-RAM 190 includes BIOS storage 194 which stores program code, settings, and data values including BIOS user settings, the functional equivalent of a BIOS database storing a secure boot configuration. Col. 7:4-10: BIOS is configured to maintain BIOS user settings in non-volatile memory that persist across reboots, a stored secure boot configuration database); a secure boot configuration modification source identifier storage (in Nelson, col. 6:51 thru col. 7:23: BIOS is configured to create a record of BIOS configuration changes stored in non-volatile memory, a dedicated storage for configuration change records. Claim 2: “non-volatile index of a memory integral to the crypto-processor”, a specific, protected storage for change-related records within the BIOS), and a BIOS subsystem that is coupled to the BIOS database and the secure boot configuration modification source identifier storage wherein the BIOS subsystem is configured, during a first initialization of the computing device, to: generate, using the secure boot configuration, a first initialization hash value (in Nelson, col. 6:51 thru col. 7:23: BIOS during a current boot session generates a fingerprint of the BIOS event log, a hash value generated from the BIOS configuration. Claim 10: “generating, by the BIOS, a fingerprint of a BIOS event log”, a hash-based value generated from the current boot session configuration. The BIOS configuration change detection mechanism computes an integrity indicator (fingerprint/hash) based on current BIOS configuration state during boot initialization); determine that the first initialization hash value does not match a second initialization hash value that is stored in the non-volatile memory subsystem and that was generated using the secure boot configuration during a second initialization of the computing device that was performed prior to the first initialization of the computing device (in Nelson, Claim 1: determine whether a prior BIOS configuration change was made during a prior boot session requires comparing current-session state against prior-session state, i.e., comparing two initialization hash values across boot sessions. Col. 7:11-22: BIOS determines whether a BIOS configuration change was made during a prior boot session, a mismatch detection between current and prior boot session configuration states. The comparison is between a current boot-generated value and a prior boot-stored value in non-volatile memory. Claim 3: indication of BIOS configuration change stored as an “event log change flag” in non-volatile memory that stored between sessions for cross-initialization comparison); retrieve, from the secure boot configuration modification source identifier storage in response to determining the first initialization hash value does not match the second initialization hash value (in Nelson, Claim 1: responsive to determining a configuration change was made during a prior boot session, BIOS appends new event log to prior event log, a retrieval and use of stored change records upon detecting a prior-session change. Col. 7-29-55: Upon detecting a BIOS configuration change, BIOS retrieves the stored indication (fingerprint/event log) from non-volatile memory to process the change record, a retrieval from stored change records upon mismatch detection. Claim 4: “indication of the BIOS configuration change is a BIOS event log”, the BIOS event log is retrieved and used upon change detection), at least one secure boot configuration modification source identifier; and generate, using the at least one secure boot configuration modification source identifier, at least one secure boot configuration modification source identification message (in Nelson, Claim 4: “indication of the BIOS configuration change is a BIOS event log”, the BIOS generates a change notification/log message from stored change records. Col. 7:11-55: BIOS processes detected configuration change by generating and storing an event log record communicating the change, a source identification message generated from the change record. Claim 3: “indication of the BIOS configuration change is a setting of an event log change flag”, a generated notification/message from the stored change indicator). Nelson does not expressly disclose BIOS database storing a secure boot configuration, a request log identifying modification source, the stored records include source identification, communicating configuration changes with source attribution. In the same field of endeavor, Brumley discloses BIOS database storing a secure boot configuration (as shown in Fig. 1, which is reproduced below for ease of reference and convenience, Brumley discloses BMC 110 maintains BIOS configuration data 122 in storage 114, a database of BIOS configuration settings. BIOS configuration data includes system security settings. See col. 5:27-67),
PNG
media_image2.png
742
662
media_image2.png
Greyscale
a request log identifying modification source (in Brumley, col. 6:14-40: BMC 110 stores configuration change requests from remote users in a request log, a stored identifier of the modification source (remote user via BMC) within the system's configuration infrastructure), the stored records include source identification (in Brumley, col. 6:14-60: upon coming online after receiving a BMC configuration change request, BIOS retrieves the stored request log to apply the pending configuration changes, retrieval of stored source identifier (BMC/remote user) upon initialization), communicating configuration changes with source attribution (in Brumley, col. 6:14-60: BMC provides updated configuration data copy to subsequent remote users, a generated message/report of configuration changes communicated using the source-based request record). It would have been obvious to a person of ordinary skill in the art before the effective filing date to modify Nelson’s BIOS change detection and hash-based mismatch reporting by incorporating Brumley’s source tracking and out-of-band modification logging. The motivation would be to provide administrators with visibility into who or what modified the secure boot configuration (e.g., input device, BMC, BIOS image itself), thereby improving security auditing, forensic analysis, and trust in the BIOS secure boot process.
In regard to claims 2, 9, 15, Brumley discloses wherein the BIOS subsystem is configured, during the second initialization of the computing device, to: receive, from a first secure boot configuration modification source, at least one first instruction to modify the secure boot configuration (in Brumley, Abstract & col. 2:6-36: a configuration change request may be received from a remote user at a local baseboard management controller (BMC) via a network that expressly teaches receiving a configuration modification instruction from a specific source (remote user via BMC) during a prior initialization. Col. 6:14-20: BMC receives BIOS settings change request from remote user that direct teaching of receiving modification instruction from a named source); modify, based on the at least one first instruction to modify the secure boot configuration (in Brumley, col. 6:14-45: The configuration data may be updated based on the configuration change request stored in the request log that expressly teaches modifying BIOS configuration based on the received modification instruction. Claim 16: BMC further configured to receive a BIOS settings change request and update BIOS settings data based on the received request), the secure boot configuration; and provide, in the secure boot configuration modification source identifier storage, a first secure boot configuration modification source identifier for the first secure boot configuration modification source (in Brumley, col. 6:14-45: The configuration change request may be stored in a request log that expressly teaches storing a request/record that identifies the source (remote user/BMC) of the configuration change. Claim 1: request log contains source-identifying information about who requested the configuration change that means a source identifier stored for later retrieval).
In regard to claims 3, 10, 16, Brumley discloses wherein the first secure boot configuration modification source is associated with one of: an input device connected to the computing device, a Baseboard Management Controller (BMC) device included in the computing device; or a BIOS image included in the BIOS (in Brumley, Abstract & col. 2:6-36: a configuration change request may be received from a remote user at a local baseboard management controller (BMC) via a network that expressly teaches receiving a configuration modification instruction from a specific source (remote user via BMC) during a prior initialization. Col. 6:14-20: BMC 110 receives BIOS configuration change requests from remote clients that applies BMC as specific modification source. Claim 16: BMC further configured to receive a BIOS settings change request that applies BMC as named modification source).
In regard to claims 4, 11, 17, Brumley discloses wherein the BIOS subsystem is configured, during the second initialization of the computing device, to: receive, from a second secure boot configuration modification source, at least one second instruction to modify the secure boot configuration; modify, based on the at least one second instruction to modify the secure boot configuration, the secure boot configuration; and provide, in the secure boot configuration modification source identifier storage, a second secure boot configuration modification source identifier for the second secure boot configuration modification source (in Brumley, col. 6:14-45: BMC can receive multiple BIOS configuration change requests from multiple remote users, multiple modification sources each with stored request records. Col. 6:40-60: a copy of the updated configuration data may be stored in a storage device coupled to the BMC that applies multiple configuration updates stored from multiple sources).
In regard to claims 5, 12, 18, Brumley discloses wherein the BIOS subsystem is configured, during the first initialization of the computing device, to: generate, using the first secure boot configuration modification source identifier, a first secure boot configuration modification source identification message; and generate, using the second secure boot configuration modification source identifier, a second secure boot configuration modification source identification message that is different than the first secure boot configuration source identification message (in Brumley, col. 6:46-65: BMC provides updated configuration data copy to subsequent remote users that separate reports generated for different configuration change requests from different sources).
In regard to claims 6, 13, 19, Nelson discloses wherein the at least one secure boot configuration modification source identifier is a default secure boot configuration modification source identifier (in Nelson, col. 6:42 thru col. 7:10: BIOS includes default BIOS settings that represent the baseline configuration that when no specific source has modified the configuration, a default state is implied. BIOS event log change flag in NV memory that when no change is detected, the default state/flag represents a default source identifier (system default/manufacturer). Claim 3: indication of the BIOS configuration change is a setting of an event log change flag that a default flag state exists when no modification source has acted).
In regard to claims 7, 20, Nelson discloses wherein modifications to the secure boot configuration modification source identifier storage are prevented during runtime of the computing device (in Nelson, claim 2: non-volatile index of a memory integral to the cryptoprocessor-TPM/cryptoprocessor NV memory is hardware-protected and cannot be modified during runtime without proper credentials. Col. 6:24-42: Non-volatile memory associated with cryptoprocessor (TPM NV index) is by definition only writable during authorized operations that runtime modification prevention is inherent in TPM NV memory architecture. Claim 3: indication stored as event log change flag in non-volatile memory where NV memory flags are protected against unauthorized runtime modification by standard NV memory architecture).
Examiner's note:
Examiner has cited particular columns and line numbers in the references applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passages as taught by the prior art or disclosed by the Examiner.
Conclusion
All claims are rejected.
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
Paul et al. (US Pub No. 2023/0273832) disclose a system for autonomous and proactive power management for energy efficient execution of machine learning workloads may include an apparatus such as system-on-chip (SoC) comprising an accelerator configurable to load and execute a neural network and circuitry to receive a profile of the neural network. The profile may be received from a compiler and include information regarding a plurality of layers of the neural network.
Bilal et al. (US Pub No. 2020/0034155) disclose a Firmware of the computing device can be configured to contact a network location as part of an HTTP boot and download a boot agent. The boot agent can be prioritized to execute before a primary OS boot loader. The boot agent can download an OS configuration including a package that is inserted into the primary OS. The primary OS, as configured, can then boot. The boot agent can also attest to OS health and device compliance on subsequent boots.
Fonseka et al. (US No. 10,460,123) disclose the systems and methods may include receiving, at a cloud compute service, a notification that a sensitive file comprising sensitive data has been received at a file receipt location, the sensitive file being sent by a client device; generating, by the cloud compute service, a container instance in response to the notification; retrieving, by the container instance, the sensitive file from the file receipt location; generating, by the container instance, a stripped file by stripping the sensitive data from the sensitive file based on a configuration file; transmitting, by the container instance, the stripped file to a storage location.
Martinez et al. (US No. 10,185,578) disclose a methods and systems for generating and using a BIOS security display include determining whether a change in a BIOS user setting is associated with security of an information handling system. When the BIOS user setting is associated with security, a security level for the BIOS may be calculated based on weighted security values for BIOS user settings. Security levels for boot phases may also be individually calculated.
Goodman et al. (US No. 6,993,648) disclose when a flash unlock routine unlocks the flash memory to permit updating of a BIOS image, a message is left in secure non-volatile memory, such as an EEPROM. Upon the next re-boot, the boot block code will detect the special message in the non-volatile memory and perform a signature verification of the next block of code that is to be executed during the POST process. This code block will check the remainder of the BIOS image before POST proceeds.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to examiner Raymond Phan, whose telephone number is (571) 272-3630. The examiner can normally be reached on Monday-Friday from 6:30AM- 3:00PM. The Group Fax No. (571) 273-8300.
Communications via Internet e-mail regarding this application, other than those under 35 U.S.C. 132 or which otherwise require a signature, may be used by the applicant and should be addressed to [raymond.phan@uspto.gov].
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 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.
All Internet e-mail communications will be made of record in the application file. PTO employees do not engage in Internet communications where there exists a possibility that sensitive information could be identified or exchanged unless the record includes a properly signed express waiver of the confidentiality requirements of 35 U.S.C. 122. This is more clearly set forth in the Interim Internet Usage Policy published in the Official Gazette of the Patent and Trademark on February 25, 1997 at 1195 OG 89.
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 hop://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).
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 central telephone number is (571) 272-2100.
/RAYMOND N PHAN/
Primary Examiner, Art Unit 2175
Prosecution Insights