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 . 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.
Response to Arguments
Applicant’s arguments, see page 7 filed 02/05/2026, with respect to 1-20 have been fully considered and are persuasive. The Claim Rejections under 35 USC § 101 abstract idea of 11/05/2026 has been withdrawn.
Applicant’s arguments, filed 02/05/2026, with respect to 1,7, 13 have been fully considered and are persuasive. The Claim Rejections under 35 USC §112(a) of 11/05/2026 has been withdrawn.
Applicant’s arguments, filed 02/05/2026, with respect to 1, 3, 7, 13, 4-5, 10-11, 16-17 have been fully considered and are persuasive. The Claim Rejections under 35 USC §112(b) of 11/05/2026 has been withdrawn.
Applicant's arguments filed 02/05/2026 with respect to claims 3, 4, 6, 9-10, 15-16 rejected under 35 U.S.C. 112(a) have been fully considered but they are not persuasive.
Claim 3, recites “implementing a device path based authorization”. Claim 3 and/or specification does not clearly provide enough clarity for how the “a device path authentication” is being implemented? It is important to understand how “implementing a device path based authorization” is being applied or processed.
Claim 4 recites, “generating a simulated non-volatile memory variable storage location”. Specification does not provide enough clarity for how “simulated non-volatile memory variable storage location” is getting generated. It is important to understand how “generating a simulated non-volatile memory variable storage location” is being applied or processed.
Claim 6, recites “the processor exception handling protocol dynamically re initializing an interrupt vector table”. It is described as a result-oriented action (“dynamically re-initializes an interrupt vector table”) without implementation.
Therefore, Claims 3, 4, 6, 9-10, 15-16 are rejection under 35 U.S.C. 112(a) is maintained.
Applicant's arguments filed 02/05/2026 with respect to claims 3, 9 and 15 are rejected under 35 U.S.C. 112(b) have been fully considered but they are not persuasive.
Claims 3, 9, and 15 recites “Trusted shadowing protocol implementing device path based authorization”, specification does not have sufficient written description of what is “device path based authorization” and how “device path authentication is being implemented. Appropriate changes required.
Therefore, Claims rejection under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as being indefinite is maintained.
Applicant’s argument with respect to the amended limitation of “performing a firmware variable transaction via a firmware variable management operation, the firmware management operation managing a firmware variable”; and, “authenticating, via a secure authenticated BIOS interface, the firmware variable transaction, the secure authenticated BIOS interface being provided via an embedded controller for analysis of firmware variable transactions.” is moot in view of a new ground of rejection”.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 3, 4, 6, 9-10, 15-16 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement.
Regarding claim 3:
Claim 3 recites, “implementing a device path based authorization”. The specification fails to provide written description for “implementing a device path based authorization”. It is important to understand how “implementing a device path based authorization” is being applied or processed. Appropriate changes are needed.
Claims 9 and 15 are rejected under same rationale as claim 3 above.
Regarding claim 4:
Furthermore, Claim 4 recites, “generating a simulated non-volatile memory variable storage location”. The specification fails to provide written description for “generating a simulated non-volatile memory variable storage location”. It is important to understand how “generating a simulated non-volatile memory variable storage location” is being applied or processed. The description remains conceptual.
Claims 10 and 16 are rejected under same rationale as claim 4 above.
Regarding claim 6:
Claim 6, recites “the processor exception handling protocol dynamically re initializing an interrupt vector table” The disclosure mentions this protocol briefly, but gives no technical detail on how reinitialization is performed, how exceptions are handled, or how it interacts with BIOS or OS components. It is described as a result-oriented action (“dynamically re-initializes an interrupt vector table”) without implementation.
Therefore, Claims 3, 4, 6, 9-10, 15-16 rejection under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement is maintained.
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 3, 9, and 15 recites “Trusted shadowing protocol implementing device path based authorization”, specification does not have sufficient written description of what is “device path based authorization” and how “device path authentication is being implemented. Appropriate changes required.
Therefore, Claims rejection under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as being indefinite is maintained.
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.
Claim(s) 1, 6, 7, 13, 12, 18 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Vidyadhara et al. (U. S. PGPub. No. 2023/0267044 A1) (hereinafter “Vidyadhara”) in view of Zimmer et al. (U. S. Pat. No. 9,785,801 B2) (hereinafter “Zimmer”)
Regarding Claim 1, Vidyadhara teaches:
A computer-implementable method for performing a firmware management operation, comprising (Vidhyadhara: [0022] BMC 190 is connected to multiple elements of information handling system 100 via one or more management interface 192 to provide out-of-band monitoring (=a firmware management operation), maintenance, and control of the elements of the information handling system):
providing an information handling system with a distributed BIOS (Vidyadhara: [0014] FIG. 1 illustrates an embodiment of an information handling system 100 including processors 102 and 104, a chipset 110, a memory 120, a graphics adapter 130 connected to a video display 134, a non-volatile RAM (NV-RAM) 140 that includes a basic input and output system/extensible firmware interface (BIOS/EFI) module 142, a disk controller 150, a hard disk drive (HDD) 154, an optical disk drive 156, a disk emulator 160 connected to a solid-state drive (SSD) 164, an input/output (I/O) interface 170 connected to an add-on resource 174 and a trusted platform module (TPM) 176, a network interface 180, and a baseboard management controller (BMC) 190), the distributed BIOS being implemented to function with any of a plurality of processor environments, each of the plurality of processing environments implementing a respective processor architecture (Vidyadhara: [0014], FIG. 1 illustrates an embodiment of an information handling system 100 including processors 102 and 104… In a particular embodiment, processors 102 and 104 are connected together via a high-capacity coherent fabric, such as a HyperTransport link, a QuickPath Interconnect, or the like. [0015], one or more of processors 102 and 104 include a memory interface that provides a dedicated memory for the processors),
the distributed BIOS including a BIOS component (Vidhyadhara: [0037], BIOS firmware (=BIOS component) exists in both NV-RAM 140 and NVMe boot partition 345) and a BIOS variable (Vidhyadhara: [0037], BIOS data area 360 may include data (=the BIOS variable) that ROM BIOS 355 may use during the boot process.) the BIOS variable being stored within a firmware variable non-volatile memory store (Vidhyadhara: [0038] NVMe boot partition 345 (=firmware variable non-volatile memory store) includes an exception handler 350, a ROM BIOS 355, a BIOS data area 360, a BIOS data area 360…);
Vidyadhara does not explicitly disclose:
performing a firmware variable transaction via a firmware variable management operation,the firmware management operation managing a firmware variable; and, authenticating, via a secure authenticated BIOS interface, the firmware variable transaction, the secure authenticated BIOS interface being provided via an embedded controller for analysis of firmware variable transactions.
However, in an analogous art, Zimmer teaches:
Performing a firmware variable transaction via a firmware variable management operation (Zimmer: [Col 4, lines 2-10], UEFI specifications define an application programming interface (API) for variable access (e.g., SetVariable to write/delete a variable, GetVariable to read a variable), which may be used by embodiments to manipulate variables signed by a cryptoprocessor. In an embodiment UEFI variables are accessible during SMM runtime as well as during boottime. [Col 4, lines 27-31], The OS then calls the SetVariable runtime service to enroll an authenticated variable in the firmware (e.g., using a signed blob that is transferred to the UEFI client to do the actual SetVariable( ) action). [Col 4, lines 48-50], An SMM driver may call those commands, along with the SetVariable and GetVariable (=firmware variable transaction) UEFI runtime services), the firmware management operation managing a firmware variable (Simmer: [Col 2, lines 50-56], UEFI variables are susceptible to malicious activities. [Col 3, lines 25-32], The TPM also has mechanisms to govern access/manipulation of the signed variables. For example, the TPM has strong access controls (e.g., read-lock to prevent reading the variable and write-lock to prevent writing to the variable). Thus, the TPM can, for example, implement READ_LOCK protection (for confidentiality) and WRITE_LOCK protection (for integrity) for the variables.)
and, authenticating, via a secure authenticated BIOS interface, the firmware variable transaction (Zimmer: [Col 3, lines 7-14], (11) To better secure these variables, an embodiment cryptographically binds UEFI variables (and analogous containers or mechanisms for storing configuration information and the like) to the platform by using the cryptographic processor to sign and verify those variables or keep a cryptographic checksum, such as a SHA256 hash of the variable in the TPM NVData.), the secure authenticated BIOS interface being provided via an embedded controller for analysis of firmware variable transactions. (Zimmer: [Col 2, lines 15-19], (8) An embodiment provides runtime access to a cryptoprocessor (e.g., TPM 2.0) and the cryptoprocessor's signature services so firmware can use the cryptoprocessor (=embedded controller) to create a key internal to the cryptoprocessor, use the key to sign an object (e.g., a UEFI variable), and then verify that signature).
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Vidyadhara’s method of providing information handling system having BIOS components and BIOS variable by applying Zimmer’s method of signature verification of UEFI variable using cryptoprocessor in order to prevent variables from read and/or write operations and protect confidentiality and integrity of the variables. The motivation is to prevent unauthorized access to a computing node. (Zimmer: [Col 1, lines 33-34])
Regarding Claim 6, Vidyadhara in view of Zimmer teaches:
The method of claim 1 (see rejection of claim 1 above),
wherein: the secure authenticated BIOS interface includes a processor exception handler protocol (Vidyadhara: [0031] In one embodiment, information handling system (=BIOS interface) 200 may be configured to enable dynamic detection of an NVMe boot partition as part of the system memory, wherein the NVMe boot partition may hold exception handlers even before the system memory is installed. As used herein, the exception handler includes an interrupt service routine also referred to as an interrupt handler. In particular, the NVMe and a memory controller may be initialized and loaded in the pre-EFI initialization (PEI) phase of the boot process when an exception or interrupt occurs),
the processor exception handling protocol dynamically reinitializing an interrupt vector table (Vidyadhara: [0031], information handling system 200 may be configured to enable dynamic detection of an NVMe boot partition as part of the system memory, wherein the NVMe boot partition may hold exception handlers even before the system memory is installed. [0039] Exception hand-off block 375 may be generated during PEI phase 315 or DXE phase 320 and includes information associated with the detected exception or interrupt. The information in exception hand-off block 375 may also be used in re-initializing exception vector table (=dynamically re-initializing vector table) 365 once memory 120 is detected, which is the system memory, in DXE phase 320. [0043], The exception vector table 365 may be re-initialized during the copy which can update the address of the exception handler associated with the vector ).
Regarding Claim 7, Vidyadhara teaches:
A system comprising: a processor (Vidyadhara: [0027], information handling system 100 can include multiple processor cores, audio devices, and the like. While a particular arrangement of bus technologies and interconnections is illustrated for the purpose of example, one of skill will appreciate that the techniques disclosed herein are applicable to other system architectures. Information handling system 100 can include multiple central processing units (CPUs) and redundant bus controllers. One or more components can be integrated together. Information handling system 100 can include additional buses and bus protocols, for example, I2C and the like);
a data bus coupled to the processor (Vidyadhara: [0023] Management interface 192 represents one or more out-of-band communication interfaces between BMC 190 and the elements of information handling system 100, and can include an Inter-Integrated Circuit (I2C) bus, a System Management Bus (SMBUS), a Power Management Bus (PMBUS), a Low Pin Count (LPC) interface, a serial bus such as a Universal Serial Bus (USB) or a Serial Peripheral Interface (SPI), a network interface such as an Ethernet interface, a high-speed serial data link such as a PCIe interface, a Network Controller Sideband Interface (NC-SI), or the like);
and a non-transitory, computer-readable storage medium embodying computer program code, the non-transitory, computer-readable storage medium being coupled to the data bus, the computer program code interacting with a plurality of computer operations and comprising instructions executable by the processor and configured for (Vidyadhara: [0068] While the computer-readable medium is shown to be a single medium, the term “computer-readable medium” includes a single medium or multiple media, such as a centralized or distributed database, and/or associated caches and servers that store one or more sets of instructions. The term “computer-readable medium” shall also include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by a processor or that cause a computer system to perform any one or more of the methods or operations disclosed herein):
This claim contains identical limitations found within that of claim 1 above albeit directed to a different statutory category (non-transitory medium). For this reason the same grounds of rejection are applied to claim 7.
Regarding Claim 13, Vidyadhara teaches:
A non-transitory, computer-readable storage medium embodying computer program code, the computer program code comprising computer executable instructions configured for (Vidyadhara: [0067] The present disclosure contemplates a computer-readable medium that includes instructions or receives and executes instructions responsive to a propagated signal; so that a device connected to a network can communicate voice, video, or data over the network. Further, the instructions may be transmitted or received over the network via the network interface device):
This claim contains identical limitations found within that of claim 1 above albeit directed to a different statutory category (non-transitory medium). For this reason the same grounds of rejection are applied to claim 13.
Regarding claim 12, this claim contains identical limitations found within that of claim 6 above albeit directed to a different statutory category (system medium). For this reason the same grounds of rejection are applied to claim 12.
Regarding claim 18, this claim contains identical limitations found within that of claim 6 above albeit directed to a different statutory category (non-transitory medium). For this reason the same grounds of rejection are applied to claim 18.
Regarding Claim 19, Vidyadhara in view of Zimmer teaches:
The non-transitory, computer-readable storage medium of claim 13 (see rejection of claim 13 above),
wherein: the computer executable instructions are deployable to a client system from a server system at a remote location (Vidhyadhar: [0024], In particular, BMC 190 includes a network interface 194 that can be connected to a remote management system to receive firmware updates, as needed or desired. [0029], In particular, the present disclosure includes a system and method for dynamic analysis of the exceptions during the early phase of the boot process even before the system memory has been initialized. Information associated with the exceptions may also be stored at a remote telemetry server for later analysis.).
Regarding Claim 20, Vidyadhara in view of Zimmer teaches:
The non-transitory, computer-readable storage medium of claim 13 (see rejection of claim 13 above),
wherein: the computer executable instructions are provided by a service provider to a user on an on-demand basis (Vidhydhar: [0024] BMC 190 operates to monitor and maintain system firmware, such as code stored in BIOS/EFI module 142, option ROMs for graphics adapter 130, disk controller 150, add-on resource 174, network interface 180, or other elements of information handling system 100, as needed or desired. In particular, BMC 190 includes a network interface 194 that can be connected to a remote management system to receive firmware updates, as needed or desired).
Claim(s) 2-5, 8-11, 14-17 are rejected under 35 U.S.C. 103 as being unpatentable over Vidyadhara et al. (U. S. PGPub. No. 2023/0267044 A1) (hereinafter “Vidyadhara”) in view of Zimmer et al. (U. S. Pat. No. 9,785,801 B2) (hereinafter “Zimmer”); and further in view of Hsu et al. (U. S. PGPub. No. 2021/0240567 A1) (hereinafter “Hsu”) and Kloth (U. S. PGPub. No. 2021/0312057 A1) (hereinafter “Kloth”)
Regarding Claim 2, Vidyadhara in view of Zimmer teaches:
The method of claim 1 (see rejection of claim 1 above),
The Vidyadhara in view of Zimmer does not explicitly disclose:
the authenticating is performed by the embedded controller, the embedded controller providing the information handing system with a root of trust for the firmware variable transaction.
However in analogous art, Hsu teach:
wherein: the authenticating is performed by the embedded controller (Hsu: [0049] The embedded controller may also be referred to as a service processor or BMC may provide cryptography services to authenticate the BIOS firmware prior to storing the BIOS firmware at the boot partition of the non-volatile memory-express device. For example, the embedded controller can be used to verify a cryptographic signature associated with a BIOS firmware or with other encapsulated information prior to storing and/or using the BIOS firmware during the initialization process),
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Vidyadhara in view of Zimmer by applying the well-known technique as disclosed by Hsu of authenticating the BIOS firmware by embedded controller. The motivation is to detect a failure during a boot process switch a first SPI of a chipset from the SPI ROM to the embedded controller, and execute the second BIOS firmware from the non-volatile memory device via a sideband access of the non-volatile memory device. (Hsu: [0003]).
Vidyadhara in view of Zimmer and Hsu does not explicitly disclose:
the embedded controller providing the information handing system with a root of trust for the firmware variable transaction.
However in an analogous art, Kloth teaches:
the embedded controller providing the information handing system with a root of trust for the firmware variable transaction (Kloth: [0029] Some processors use a Trusted Platform Module (TPM) to provide security for booting, but these approaches generally rely on having a Core Root of Trust Module (CRTM), such as the bootblock of the BIOS, which is assumed to be trustworthy. Booting a processor using a TPM is typically a multi-step process involving successive checking of each additional software component (e.g., the BIOS, each driver, the operating system) to ensure that they have not been tampered with. This process is both time consuming and is only as trustworthy as the CRTM and the TPM. [0031] Systems sometimes provide a Root of Trust (RoT), and this is often associated with or part of a TPM and/or an HSM. The RoT provides the cornerstone around which all security is built, and frequently contains cryptographic keys and/or implements cryptographic functions (such as encryption, decryption, or authentication). For example, a piece of software can be trusted because it is authenticated by the RoT. [0032] What is needed is a unified solution that provides techniques for quickly and securely booting processors as well as the features of one or more of a TPM, an HSM and a RoT, and with a higher degree of security than available today).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Vidyadhara in view of Zimmer, Hsu by applying the well-known technique as disclosed by Kloth of providing root of trust by the system. The motivation is to secure boot of a system, are needed to provide improvements in factors such as one or more of intrusion and/or virus/malware prevention, performance, cost, and efficiency (Kloth: [0007]).
Regarding Claim 3, Vidyadhara in view of Zimmer teach:
The method of claim 1 (see rejection of claim 1 above),
Vidyadhara in view of Zimmer does not explicitly disclose:
the secure authenticated BIOS interface includes a trusted shadowing protocol, the trusted shadowing protocol implementing a device path based authorization for the firmware variable transaction.
However Kloth teaches:
wherein: the secure authenticated BIOS interface includes a trusted shadowing protocol (Kloth: [0460], processing chip 100 includes circuitry to copy (=shadowing) contents of boot flash chip 160 into one of external memory chip(s) 170 (such as a DRAM chip)… the copying is performed by enabling the H/W boot sequence to control a DMA engine (not illustrated in FIG. 1, but illustrated in FIG. 2) that is also usable by the run-time programmable CPUs once they are out of a reset state. [0531] Secure Boot Process 500 continues with Copy 550 (=shadowing)... In some embodiments, Copy 550 also caches a portion of the some or all of the contents of the boot flash chip in a cache, such as an L3 cache, of the UMC. In further embodiments, the portion in the cache is optionally and/or selectively decrypted. This advantageously provides faster access at a boot time of the processing chip to the portion of the some or all of the contents of the boot flash chip),
the trusted shadowing protocol implementing a device path based authorization for the firmware variable transaction (Kloth: [0472] As illustrated in FIG. 3, IOPC 300 has a hierarchical interconnection scheme where some units, such as CPU(s) 306 and I/O 118, are on a lower-level interconnect than interconnect 102, which serves as a highest-level interconnect in IOPC 300.
[0742] This operation enables hardware paths (=a device path) for the transfer of the executable code update from an I/O interface (e.g., a NIC) to DRAM. [0519], enabling at least one of the CPUs to access the external memory via a path that decrypts data read from the external memory, such as with one of the KMU initial keys (e.g., the default key); and other operations generally performed during boot. In further embodiments, one or more of these operations are performed in immutable hardware, such as part of the H/W boot sequence. [0687] In various embodiments, Parser 1190 is able to route data among one or more of the sub-units of UMC 104 via interconnect 1102. In further embodiments, Parser 1190 includes one or more dedicated paths for routing some or all of the data, such as a dedicated path to DMA 1120 and/or a dedicated path to UMC CE 1110).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Vidyadhara in view of Zimmer by applying the well-known technique as disclosed by Kloth of identifying hardware device path to move data on I/O pins. The motivation is to secure boot of a system, are needed to provide improvements in factors such as one or more of intrusion and/or virus/malware prevention, performance, cost, and efficiency (Kloth: [0007]).
Regarding Claim 4, Vidyadhara in view of Zimmer teach:
The method of claim 1 (see rejection of claim 1 above),
Vidyadhara in view of Zimmer does not explicitly disclose:
generating a simulated non-volatile memory variable storage location.
However, Hsu teaches:
further comprising: generating a simulated non-volatile memory variable storage location (Hsu: [0039] Flash memory 235 includes a non-volatile memory device capable of being electrically erased and re-programmed. Flash memory 235 may include any number of partitions; each partition may hold instructions or data for different components of information handling system 200 such as BIOS/EFI 240 that is used during a boot process. Flash memory 235 may also be referred to as SPI flash or SPI ROM and is similar to NVRAM 140 of FIG. 1. [0040] BIOS/UEFI (=UEFI is a specification that uses simulated non-volatile memory (NVM) variable storage locations to store its data) firmware such as BIOS/EFI 240 is typically stored in a flash memory device such as flash memory 235 of information handling system 200. Flash memory devices have the benefit that the data stored thereon is non-volatile, and so the data is retained when the information handling system 200 is powered off).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Vidyadhara in view of Zimmer by applying the well-known technique as disclosed by Hsu of using BIOS/UEFI (=UEFI is a specification that uses simulated non-volatile memory (NVM) variable storage locations to store its data) firmware such as BIOS/EFI 240 is typically stored in a flash memory 235 of information handling system. The motivation is to the data stored thereon is non-volatile, and so the data is retained when the information handling system 200 is powered off (Hsu: [0023]).
Regarding Claim 5. Vidyadhara in view of Zimmer and Hsu teach:
The method of claim 4 (see rejection of claim 4 above),
further comprising: using the simulated non-volatile memory variable storage location to categorize the BIOS variable (HSU: [0040] BIOS/UEFI firmware (=UEFI is a specification that uses simulated non-volatile memory (NVM) variable storage locations to store its data), such as BIOS/EFI 240 is typically stored in a flash memory device such as flash memory 235 of information handling system 200. Flash memory devices have the benefit that the data stored thereon is non-volatile, and so the data is retained when the information handling system 200 is powered off).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Vidyadhara in view of Zimmer by applying the well-known technique as disclosed by Hsu of using BIOS/UEFI (=UEFI is a specification that uses simulated non-volatile memory (NVM) variable storage locations to store its data) firmware such as BIOS/EFI 240 is typically stored in a flash memory 235 of information handling system. The motivation is to the data stored thereon is non-volatile, and so the data is retained when the information handling system 200 is powered off (Hsu: [0023]).
Regarding Claim 8, this claim contains identical limitations found within that of claim 2 above albeit directed to a different statutory category (system medium). For this reason the same grounds of rejection are applied to claim 8.
Regarding Claim 9, this claim contains identical limitations found within that of claim 3 above albeit directed to a different statutory category (system medium). For this reason the same grounds of rejection are applied to claim 9.
Regarding Claim 10, this claim contains identical limitations found within that of claim 4 above albeit directed to a different statutory category (system medium). For this reason the same grounds of rejection are applied to claim 10.
Regarding Claim 11, this claim contains identical limitations found within that of claim 5 above albeit directed to a different statutory category (system medium). For this reason the same grounds of rejection are applied to claim 11.
Regarding Claim 14, this claim contains identical limitations found within that of claim 2 above albeit directed to a different statutory category (non-transitory computer-readable storage medium). For this reason the same grounds of rejection are applied to claim 14.
Regarding Claim 15, this claim contains identical limitations found within that of claim 3 above albeit directed to a different statutory category (non-transitory computer-readable storage medium). For this reason the same grounds of rejection are applied to claim 15.
Regarding Claim 16, this claim contains identical limitations found within that of claim 4 above albeit directed to a different statutory category (non-transitory computer-readable storage medium). For this reason the same grounds of rejection are applied to claim 16.
Regarding Claim 17, this claim contains identical limitations found within that of claim 5 above albeit directed to a different statutory category (non-transitory computer-readable storage medium). For this reason the same grounds of rejection are applied to claim 17.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
Narasimhan et al. (U. S. 2020/0356357 A1): An operating system (OS) may communicate with a basic input/output system (BIOS) at OS runtime to inform the BIOS of a firmware update storage location. A method may begin with receiving, by an OS, an update for a firmware of an information handling system. The OS may select a memory for storage of the firmware update and may store the firmware update in the selected memory. The OS may then store a location of the firmware update in a portion of a memory accessible by both the OS and the BIOS.
POORNACHANDRAN et al. (U. S. 2024/0143341 A1): It is provided an apparatus comprising interface circuitry, machine-readable instructions, and processing circuitry to execute the machine-readable instructions. The machine-readable instructions comprise instructions to determine one or more configurable firmware variables of a computing system based on performance analysis data of the computing system executing a workload. The machine-readable instructions further comprise instructions to set the determined one or more configurable firmware variables of the computing system based on reference data. The machine-readable instructions further comprise instructions to control the computing system to apply the set firmware variables during run-time.
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 RUPALI DHAKAD whose telephone number is (571)270-3743. The examiner can normally be reached M-F 8:30-5:30.
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, Alexander Lagor can be reached at 5712705143. 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.
/R.D./Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437
Prosecution Insights