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 § 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.
Claim(s) 1-5, 7-11, 13-17 are rejected under 35 U.S.C. 103 as being unpatentable over SURYANARAYANA et al. (United States Patent Application Publication US 2021/0049071), hereinafter SURYANARAYANA, hereinafter CHEN et al. (United States Patent Application Publication US 2016/0188345), hereinafter CHEN, and further in view of Rothman et al. (United States Patent Application Publication US 2005/0071624), hereinafter Rothman.
Regarding claim 1, SURYANARAYANA teaches a computer-implementable method for performing a firmware management operation, comprising:
providing an information handling system with a distributed BIOS (FIG. 1 “information handling system 102” “BIOS 105”);
identifying a processor environment installed on an information handling system from a plurality of processor environments ([0043] “A boot service executed by processor 203 during the PEI phase may initialize GPU 209 and enumerate the device path of GPU 209 as available for UEFI event-based "Independent Similar Task Execution" (ISTE).” During a booting process, processor and GPU are initialized. Furthermore, a device path of GPU, which includes processing cores of the GPU, is enumerated, which establishes or recognizes the GPU.);
performing a multi-processing unit type adaptive memory diagnostic acceleration operation, the multi-processing unit type adaptive memory diagnostic acceleration operation managing a memory diagnostic operation on system memory of the information handling system based upon the processor environment installed on the information handling system ([0044] “The ISTE discussed above may be implemented via two (or more) modules. The first module, a Dynamic Memory Region Creation module, may implement a Memory Initialization Table (MIT), read the available system memory size and number of banks in the system from memory device properties, and populate the MIT.” [0050] “Thus processing cores of the GPU may run diagnostics on each memory region independently of the regular BIOS pre-boot phase that is being concurrently executed by the main CPU. When the BIOS is ready to boot, but before an operating system has been initialized, the BIOS may determine whether any failures have occurred (e.g., by investigating the MIT queue for any memory failures).” Based on the processor environment installed on the information handling system, such as the CPU and the GPU, memory diagnostics to test the memory and ISTE are performed.),
the distributed BIOS performing a pre-boot portion of the multi-processing unit type adaptive memory diagnostic acceleration operation ([0050] “Thus processing cores of the GPU may run diagnostics on each memory region independently of the regular BIOS pre-boot phase that is being concurrently executed by the main CPU. When the BIOS is ready to boot, but before an operating system has been initialized, the BIOS may determine whether any failures have occurred (e.g., by investigating the MIT queue for any memory failures).”).
However, SURYANARAYANA does not explicitly teach the distributed BIOS including a plurality of BIOS components and a plurality of BIOS variables, 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.
CHEN teaches the distributed BIOS including a plurality of BIOS components and a plurality of BIOS variables (FIG. 4 “UIFI firmware 422” “Instructions 424” “Configuration Data 426”, FIG. 6A & 6B, [0006] “With the adoption of UEFI standards, BIOS companies were able to produce UEFI firmware for computing systems” [0039] “Returning to the dual Operating System of 32-bit and 64 bit example, the instructions I1 could correspond to the 32-bit instruction set and the instructions 12 could correspond to the 64-bit instruction set.”), 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 ([0037] “the variables in the respective configuration tables for the 32-bit firmware image and the 64-bit firmware image are compared and classified as being common data or distinct data. Any variables that are common to both firmware images are classified as common… When compiling into a single firmware image, the common variables are grouped into a table of common configuration data 427 and the distinct variables are grouped into a table of distinct configuration data 428.” CHEN suggests that the UEFI firmware is adapted to a BIOS, which includes instructions and configuration data for various instruction set for processor. The UEFI firmware functions with various processor architectures.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified SURYANARAYANA in view of CHEN of he 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. They are all directed toward booting process. As recognized by CHEN, separate boot up images for different computing architectures need to be complied and installed on the computing system, which require added storage ([0006]). By having the BIOS, which can boot into and function with different processor architecture, the complexity with multiple boots-up firmwares can be reduced. Therefore, it would be advantageous to incorporate the teaching of CHEN of he 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 to reduce storage requirement and the complexities of the BIOS.
However, SURYANARAYANA in view of Chen does not explicitly teach wherein the multi-processing unit type adaptive memory diagnostic acceleration operation includes a pre-boot memory healing operation, the pre-boot memory healing operation being dynamically initiated to heal failing memory regions during a pre-boot phase of operation.
Rothman teaches wherein the multi-processing unit type adaptive memory diagnostic acceleration operation includes a pre-boot memory healing operation, the pre-boot memory healing operation being dynamically initiated to heal failing memory regions during a pre-boot phase of operation ([0026] “if a hard disk of computer system 102 has become corrupted, the firmware may use the pre-boot recovery utility 204 to restore the hard disk. The operating system boot target stored on the hard disk may not be executable, but self-describing media 104 may have a snap shot image of the hard disk located in the media data 206. The firmware may use the pre-boot recovery utility 204 during the pre-boot phase to recover the hard disk from the media data 206.” A pre-boot recovery utility during the pre-boot phase recovers the corrupted hard disk. Thus, the recovery to heal the corrupted memory regions is initiated during the pre-boot phase of operation.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified SURYANARAYANA in view of CHEN by incorporating the teaching of Rothman of the multi-processing unit type adaptive memory diagnostic acceleration operation includes a pre-boot memory healing operation, the pre-boot memory healing operation being dynamically initiated to heal failing memory regions during a pre-boot phase of operation. They are all directed toward booting process. As recognized by Rothman, by recovering the corrupted memory regions during the pre-boot phase using a memory that provides snapshot images, the resources that are inaccessible are not necessary for the recovery ([0026]), which allows the system to recover from a crisis recovery scenario. Therefore, it would be advantageous to incorporate the teaching of Rothman of the multi-processing unit type adaptive memory diagnostic acceleration operation includes a pre-boot memory healing operation, the pre-boot memory healing operation being dynamically initiated to heal failing memory regions during a pre-boot phase of operation in order to improve the stability of the system and recovering ability from the crisis recovery scenario.
Regarding claim 2, SURYANARAYANA in view of CHEN and further in view of Rothman teaches all the limitations of the method of claim 1, as discussed above.
SURYANARAYANA, as modified above, further teaches wherein: the information handling system includes a multi-processing unit, the multi-processing unit corresponds to a particular multi-processing unit type; and, the multi-processing unit type adaptive memory diagnostic acceleration operation is performed by the multi-processing unit ([0050] “Thus processing cores of the GPU may run diagnostics on each memory region independently of the regular BIOS pre-boot phase that is being concurrently executed by the main CPU. When the BIOS is ready to boot, but before an operating system has been initialized, the BIOS may determine whether any failures have occurred (e.g., by investigating the MIT queue for any memory failures).” The information handling system includes processing cores of the GPU to run memory diagnostics.).
Regarding claim 3, SURYANARAYANA in view of CHEN and further in view of Rothman teaches all the limitations of the method of claim 2, as discussed above.
SURYANARAYANA, as modified above, further teaches the particular multi-processing unit type comprises a graphic processing unit type multi-processing unit ([0050] “Thus processing cores of the GPU may run diagnostics on each memory region independently of the regular BIOS pre-boot phase that is being concurrently executed by the main CPU. When the BIOS is ready to boot, but before an operating system has been initialized, the BIOS may determine whether any failures have occurred (e.g., by investigating the MIT queue for any memory failures).”).
Regarding claim 4, SURYANARAYANA in view of CHEN and further in view of Rothman teaches all the limitations of the method of claim 3, as discussed above.
SURYANARAYANA, as modified above, further teaches the multi-processing unit type adaptive memory diagnostic acceleration operation includes a graphics processing unit management protocol, the graphics processing unit management protocol communicating between graphic processing unit type multi-processing unit and another type of multi-processing unit (FIG. 2, [0042] “In operation, processor 203 (which may be a CPU or a core of a CPU) coordinates with GPU 209 (or individual cores of GPU 209) to perform memory diagnostics.” [0043] “A boot service executed by processor 203 during the PEI phase may initialize GPU 209 and enumerate the device path of GPU 209 as available for UEFI event-based "Independent Similar Task Execution" (ISTE).” A protocol is interpreted as a set of rules. Thus, based on ISTE and BIOS, which includes various rules, the CPU communicates with the GPU since the processor initializes GPU and enumerates the device path of the GPU and “the processor collects the results of the various tasks executed by GPU.” Thus, the processor communicates to the GPU and manages the GPU based on the rules.).
Regarding claim 5, SURYANARAYANA in view of CHEN and further in view of Rothman teaches all the limitations of the method of claim 4, as discussed above.
SURYANARAYANA, as modified above, further teaches the graphics processing unit management protocol creates a firmware memory mapping of the system memory (FIG. 2, [0039] “This memory diagnostics module may dynamically create memory regions and share these memory regions between a CPU and a GPU to perform memory diagnostics independently.” [0044] “The ISTE discussed above may be implemented via two (or more) modules. The first module, a Dynamic Memory Region Creation module, may implement a Memory Initialization Table (MIT), read the available system memory size and number of banks in the system from memory device properties, and populate the MIT.” [0050] “Thus processing cores of the GPU may run diagnostics on each memory region independently of the regular BIOS pre-boot phase that is being concurrently executed by the main CPU. When the BIOS is ready to boot, but before an operating system has been initialized, the BIOS may determine whether any failures have occurred (e.g., by investigating the MIT queue for any memory failures).”).
Regarding claim(s) 7-11, the claim(s) 7-11 are the apparatus claims of the method claim(s) 1-5. The claim(s) 7-11 do not further teach or define the limitation over the limitations recited in the rejected claims above. Therefore, SURYANARAYANA in view of CHEN and further in view of Rothman teaches all the limitations of the claim(s) 7-11.
Regarding claim(s) 13-17, the claim(s) 13-17 are a non-transitory, computer-readable storage medium embodying computer program code, the computer program code comprising computer executable instructions of the method claim(s) 1-5. SURYANARAYANA teaches a non-transitory, computer-readable storage medium embodying computer program code, the computer program code comprising computer executable instructions ([0025] “the term "computer-readable medium" (e.g., transitory or non-transitory computer-readable medium) may include any instrumentality or aggregation of instrumentalities that may retain data and/or instructions for a period of time.”). The claim(s) 13-18 do not further teach or define the limitation over the limitations recited in the rejected claims above. Therefore, SURYANARAYANA in view of CHEN and further in view of Rothman teaches all the limitations of the claim(s) 13-17.
Claim(s) 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over SURYANARAYANA in view of CHEN and further in view of Rothman, as applied to claim 13 above, and further in view of Azzarello et al. (United States Patent US 7673131), hereinafter Azzarello.
Regarding claim 19, SURYANARAYANA in view of CHEN and further in view of Rothman teaches all the limitations of the non-transitory, computer readable storage medium of claim 13, as discussed above.
However, SURYANARAYANA in view of CHEN and further in view of Rothman does not teach the computer executable instructions are deployable to a client system from a server system at a remote location.
Azzarello teaches the computer executable instructions are deployable to a client system from a server system at a remote location (FIG. 1 “Server 34” “Computer 100” Col. 4 Lines 25-29 “During the PXE Phase 320, the device requests and receives the PXE boot information and downloads the network bootstrap and the operating system loader, such as OS Loader. Other boot configuration data and information may also be obtained.” Col. 4 Lines 52-56 “The primary boot image provides more functionality before the complete operating system is loaded. According to one embodiment, the primary boot image components include: RAM disk management; Multicast client; Device Identity Application; and State application.” A server, which is remotely located, provides or deploys bootstrap, OS loader, boot configuration data and information to a client through a network.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified SURYANARAYANA in view of CHEN and further in view of Rothman by incorporating the teaching of Azzarello of the computer executable instructions deployable to a client system from a server system at a remote location. As recognized by Azzarello, many embedded devices do not include hard drives as they are expensive and are many times the first major component to fail, which is costly for replacement (Background). By downloading boot image to perform various booting process from the server, expensive hard drives on the system can be avoided, which reduces cost and provides flexibility with a network boot mechanism. Therefore, it would be advantageous to incorporate the teaching of Azzarello of the computer executable instructions deployable to a client system from a server system at a remote location in order to reduce cost and provide flexibility.
Regarding claim 20, SURYANARAYANA in view of CHEN and further in view of Rothman teaches all the limitations of the non-transitory, computer-readable storage medium of claim 13, as discussed above.
Azzarello teaches wherein: the computer executable instructions are provided by a service provider to a user on an on-demand basis (Col. 4 Lines 25-29 “During the PXE Phase 320, the device requests and receives the PXE boot information and downloads the network bootstrap and the operating system loader, such as OS Loader. Other boot configuration data and information may also be obtained.” A device of a user requests the PXE information to the server to download the network bootstrap, the operating system loader, such as OS Loader, and boot configuration data and information. Since the download is performed when the user or the device requests, the download is provided on an on-demand basis.).
Claim(s) 6, 12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over SURYANARAYANA in view of CHEN and further in view of Rothman as applied to claims 5, 11, and 17 above, and further in view of Esposito et al. (United States Patent Application Publication US 2021/0055982), hereinafter Esposito.
Regarding claim 6, SURYANARAYANA in view of CHEN and further in view of Rothman teaches all the limitations of the method of claim 5, as discussed above.
SURYANARAYANA, as modified above, further teaches the graphics processing unit management protocol distributes memory diagnostic payloads within the graphics processing unit based upon the firmware memory mapping of the system memory ([0039] “This memory diagnostics module may dynamically create memory regions and share these memory regions between a CPU and a GPU to perform memory diagnostics independently.” [0046]-[0048], [0053] “At step 304, the BIOS may carry out failure testing of the selected portions of memory. This step may be carried out via a plurality of parallel tasks executing concurrently on various processing cores of a GPU.”).
However, SURYANARAYANA does not explicitly teach wherein a workload is associated with each distributed memory diagnostics payload of the plurality of memory diagnostic payloads.
Esposito teaches wherein a workload is associated with each distributed memory diagnostics payload of the plurality of memory diagnostic payloads ([0021] “Diagnostic information generated from the diagnostic procedures can be transmitted to the host as payload in a response to the host request that corresponded to the unrecoverable error.” [0037] “the memory controller 115 is configured to query the component that performed the diagnostic to retrieve the diagnostic information, or the memory controller 115 is configured to accept the diagnostic information from the component when it is complete.” [0050] “The memory device, in response to the fatal error, responds to the read operation with the corrupt data as payload along with an error code (e.g., error signal, error indication, etc.).” A diagnostic information about memory device is responded as a payload, which is operation or a workload of the error logging in a memory device.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified SURYANARAYANA in view of CHEN and further in view of Rothman by incorporating the teaching of Esposito of a workload being associated with each distributed memory diagnostics payload of the plurality of memory diagnostic payloads. As recognized by Esposito, an error code indicating that an error occurred is retrieved by a host ([0019]). However, to find why the error occurred, generally an advanced diagnostic is needed involving obtaining and running vendor specific diagnostic routines or disassembling the memory device to perform additional investigations ([0020]). By transmitting diagnostic information as payload in response to the host request that corresponded to the unrecoverable error, the host can have access to the diagnostic information without invoking an additional debugging protocol that might not even be available ([0021]). Therefore, it would be advantageous to incorporate the teaching of Esposito of a workload being associated with each distributed memory diagnostics payload of the plurality of memory diagnostic payloads in order to access to the diagnostic information without invoking an additional debugging protocol that might not even be available.
Regarding claim(s) 12, the claim(s) 12 is the apparatus claim of the method claim(s) 6. The claim(s) 12 does not further teach or define the limitation over the limitations recited in the rejected claims above. Therefore, SURYANARAYANA in view of CHEN and further in view of Rothman and further in view of Esposito teaches all the limitations of the claim(s) 12.
Regarding claim(s) 18, the claim(s) 18 are a non-transitory, computer-readable storage medium embodying computer program code, the computer program code comprising computer executable instructions of the method claim(s) 6. SURYANARAYANA teaches a non-transitory, computer-readable storage medium embodying computer program code, the computer program code comprising computer executable instructions ([0025] “the term "computer-readable medium" (e.g., transitory or non-transitory computer-readable medium) may include any instrumentality or aggregation of instrumentalities that may retain data and/or instructions for a period of time.”). The claim(s) 18 do not further teach or define the limitation over the limitations recited in the rejected claims above. Therefore, SURYANARAYANA in view of CHEN and further in view of Rothman and further in view of Esposito teaches all the limitations of the claim(s) 18.
Response to Arguments
Applicant’s arguments, see Remarks, filed 1/26/2026, with respect to the rejection(s) of claim(s) 1-20 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Rothman and Esposito.
Rothman teaches a pre-boot recovery utility to recovers a corrupted hard disk during the pre-boot phase.
Esposito teaches transmitting a diagnostic information of errors on memory device as a payload.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
GHETIE et al. (United States Patent Application Publication US 2018/0096151) teaches a hardware processor and a security circuitry to perform pre-boot operations including signature verification of a portion of firmware in a firmware storage hardware ad initiating recovery upon a signature verification failure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HYUN SOO KIM whose telephone number is (571)270-1768. The examiner can normally be reached Monday - Friday 8:30 am - 5:30 pm.
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, Jaweed Abbaszadeh can be reached at (571)270-1640. 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.
/HYUN SOO KIM/Examiner, Art Unit 2176