DETAILED ACTION
Response to Amendment
Applicant’s amendment, filed 04/22/26, for application number 18/417,753 has been received and entered into record. Claims 1, 4, 6, 7, 11, 13, 14, and 18 have been amended, and Claim 2 was previously cancelled. Therefore, Claims 1 and 3-21 are presented for examination.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-6, 8, 9, 13-15, 18, 19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Lu et al., US 11,263,083 B1, in view of Nulkar et al., US 2010/0121908 A1, and further in view of Higuchi, US 9,921,876 B2.
Regarding Claim 1, Lu discloses a method [Fig. 5, 6] comprising:
executing a booting operation comprising booting of an operating system of a host device [Fig. 5 results in successful execution of POST routine; and in Fig. 6, if system can power on at step 626, then POST ends at step 628, and OS is run at step 630];
detecting a failure of at least the booting of the first operating system of the host device [detecting broken components in step 516 as part of the process; (equivalent to step 616), col. 7, ll. 41-43];
pausing the executing of the booting operation in response to the detecting;
collecting data corresponding to the failure [if a broken component is found in step 516, booting is paused, as the data relating to the broken component is sent to the BIOS at step 520, col. 7, ll. 41-45];
identifying at least one function associated with the data processing unit that is contributing to the failure based at least in part on the collected data; providing a basic input/output system of the host device with access to identifying information for the at least one function [the BMC 130 then uses OEM IPMI remote commands to send data relating to broken component to the BIOS 134 (520). The stored remote command includes the appropriate data for the faulty hardware components such as CPU, DIMM, or add-on card. The BMC 130 also sets the GPIO pin 162 to send an assert signal to the PCH 116 (522); i.e. faulty functions associated with CPU, DIMM, or add-on card (associated with data processing unit but part of the host), col. 7, ll. 43-49]; and
re-executing the booting operation, wherein the basic input/output system excludes the at least one function from being configured by the first operating system of the host device based at least in part on the identifying information [the routine then initiates the power cycle with the POST routine with the modified BIOS that disables the faulty hardware component based on the stored data in the NVRAM block 156. The routine then checks whether the computer system 100 can power-on properly after the power cycle (528). If the power-on routine is successful, the routine reaches the end of the POST routine (530), col. 7, ll. 54-60];
wherein the steps of the method are executed by at least one processing device operatively coupled to a memory [FIG. 2 is a block diagram of the components of a computer system 100 that runs a routine that allows the computer system 100 to be powered up despite having a faulty hardware component; CPU 110, 112, Fig. 2; col. 5, ll. 4-7].
However, Lu does not explicitly teach the function associated with the data processing unit being a virtual function; booting of a first operating system of a data processing unit running on the host device; wherein the second operating system of the data processing unit is different from the first operating system of the host device.
In the analogous art of servers and connected devices, Nulkar teaches booting of a first operating system of a data processing unit running on the host device; wherein the second operating system of the data processing unit is different from the first operating system of the host device; wherein the operating system of the data processing unit is different from an operating system of the host device [the system enables aggregate management of connected devices independent from the operating system by incorporating a secondary processor into the server, referred to as a service processor. The service processor communicates directly with the connected devices and manages the connected devices independent of the operating system; i.e. secondary processor has its own operating system, par 10].
It would have been obvious to one of ordinary skill in the art, having the teachings of Lu and Nulkar before him before the effective filing date of the claimed invention, to incorporate the independent operating systems as taught by Nulkar into the method as disclosed by Lu, to allow for continued system operation regardless of failure of the server operating system [Nulkar, par 10].
However, the combination of references does not explicitly teach a function associated with the data processing unit being a virtual function.
In the analogous art of identifying errors in system operation, Higuchi teaches a function associated with the data processing unit being a virtual function and identifying a virtual function associated with the data processing unit that is contributing to a boot failure [as part of the boot process, the system will go into a boot test mode to test virtual components until the boot test is successful, and then reboot using the successful settings, Fig. 14; col. 13, ll. 1-29].
It would have been obvious to one of ordinary skill in the art, having the teachings of Lu, Nulkar, and Higuchi before him before the effective filing date of the claimed invention, to incorporate the identification of virtual components contributing to the failure of a boot process as taught by Higuchi into the method as disclosed by Lu and Nulkar, to ensure appropriate allocation of resources to system device groups [Higuchi, col. 1, ll. 59-67; col. 2, ll. 1-2].
Regarding Claim 3, Lu, Nulkar, and Higuchi disclose the method of Claim 1. Lu further discloses wherein the data processing unit comprises a network interface controller [other hardware components such as PCIe devices 126 may be directly accessed by the CPUs 110 or 112 through expansion slots (not shown). The additional PCIe devices 126 may include network interface cards (NIC), col. 5, ll. 27-29].
Regarding Claim 4, Lu, Nulkar, and Higuchi disclose the method of Claim 1. Lu further discloses wherein the at least one function comprises a peripheral component interconnect express (PCIe) function [FIG. 4 shows a flow diagram of the example routine that allows the computer system 100 to complete the power-on self-test (POST) routine even if a hardware component, such as the SATA devices, PCIe devices, DIMMs, or the CPUs are faulty; (i.e. PCIe may be among the faulty functions), col. 6, ll. 26-30], and Higuchi teaches a virtual function [testing virtual components during boot test, Fig. 14].
Regarding Claim 5, Lu, Nulkar, and Higuchi discloses the method of Claim 1. Lu further discloses wherein the failure further comprises a crash of the second operating system of the data processing unit and the data corresponding to the failure comprises one or more crash dump logs [detection of the faulty hardware component relies on classification in the system error log 136 managed by the BMC 130. For example, processor damage usually causes a processor internal error (IERR) or catastrophic error (CATERR) to be logged, while memory damage causes uncorrectable error, training failure or MCA errors to be logged, col. 6, ll. 52-68].
Regarding Claim 6, Lu, Nulkar, and Higuchi disclose the method of Claim 1. Lu further discloses wherein the identifying information for the at least one function comprises at least one of a bus identifier for the at least one function, a name of the at least one function and a driver version associated with the at least one function [the BMC 130 then uses OEM IPMI remote commands to send data relating to broken component to the BIOS 134 (520). The stored remote command includes the appropriate data for the faulty hardware components such as CPU, DIMM, or add-on card. The BMC 130 also sets the GPIO pin 162 to send an assert signal to the PCH 116 (522); i.e. the name of the function being CPU, DIMM, etc., col. 7, ll. 43-49], and Higuchi teaches a virtual function [testing virtual components during boot test, Fig. 14].
Regarding Claim 8, Lu, Nulkar, and Higuchi disclose the method of Claim 1. Lu further discloses wherein the collecting of the data corresponding to the failure is performed by a baseboard management controller [if a broken component is found in step 516, POST process is paused, as the data relating to the broken component is sent to the BIOS at step 520; the BMC 130 then uses OEM IPMI remote commands to send data relating to broken component to the BIOS 134 (520). The stored remote command includes the appropriate data for the faulty hardware components such as CPU, DIMM, or add-on card. The BMC 130 also sets the GPIO pin 162 to send an assert signal to the PCH 116 (522), col. 7, ll. 41-49].
Regarding Claim 9, Lu, Nulkar, and Higuchi disclose the method of Claim 1. Lu further discloses further comprising: generating a data processing unit failure state signal in response to the failure of the booting of the second operating system of the data processing unit; and sending the data processing unit failure state signal to the basic input/output system [if a broken component is found (516), the BMC 130 stores the current BIOS settings in the BMC self-storage constituting the BMC memory device 132 (518). The BMC 130 then uses OEM IPMI remote commands to send data relating to broken component to the BIOS 134 (520); (the remote command being a failure state signal), col. 7, ll. 41-45].
Regarding Claim 13, Lu, Nulkar, and Higuchi disclose the method of Claim 1. Lu further discloses further comprising generating one or more logs corresponding to the re-executing of the booting operation and to excluding the at least one function from being configured by the operating system of the host device [BMC sends OEM IPMI commands to disable broken components at step 632, BMC stores modified setup options at step 634, Fig. 6], and Higuchi teaches a virtual function [testing virtual components during boot test, Fig. 14].
Regarding Claim 14, Lu discloses an apparatus comprising: a processing device operatively coupled to a memory [computer system 100 containing CPU1 and CPU0 and hard disk drives 120 and DIMMs 114, Fig. 2]. The remainder of Claim 14 repeats the same limitations as recited in Claim 1, and is rejected accordingly.
Regarding Claim 15, Lu, Nulkar, and Higuchi disclose the apparatus of Claim 14. Claim 15 repeats the same limitations as recited in Claim 9, and is rejected accordingly.
Regarding Claim 18, Lu discloses an article of manufacture comprising a non-transitory processor-readable storage medium having stored therein program code of one or more software programs [computer system 100 containing CPU1 and CPU0 and hard disk drives 120 and DIMMs 114, Fig. 2]. The remainder of Claim 14 repeats the same limitations as recited in Claim 1, and is rejected accordingly.
Regarding Claim 19, Lu, Nulkar, and Higuchi disclose the article of manufacture of Claim 18. Claim 19 repeats the same limitations as recited in Claim 9, and is rejected accordingly.
Regarding Claim 21, Lu, Nulkar, and Higuchi disclose the article of manufacture of Claim 19. Claim 21 repeats the same limitations as recited in Claim 3, and is rejected accordingly.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Lu, Nulkar, and Higuchi, and further in view of Hayashida, US 2019/0073285 A1.
Regarding Claim 7, Lu, Nulkar, and Higuchi discloses the method of Claim 1. Lu further discloses wherein the identifying information for the at least one function is stored in a non-volatile memory of the basic input/output system [the BIOS memory device 134 then writes the data of the faulty hardware components from the BMC 130 to the NVRAM block 156 of the BIOS memory device 134 (526), col. 7, ll. 51-53], and Higuchi teaches a virtual function [testing virtual components during boot test, Fig. 14].
However, Lu, Nulkar, and Higuchi do not explicitly teach the method further comprises generating one or more intelligent platform management interface commands to cause transmission of the identifying information for the at least one function to the non-volatile memory of the basic input/output system.
In the analogous art of information processing management, Hayashida teaches the method further comprises generating one or more intelligent platform management interface commands to cause transmission of the identifying information for the at least one function to the non-volatile memory of the basic input/output system [the BIOS of the server 1 is able to acquire pieces of information of the hardware of each unit of the server 1 that have been collected by the BMC 20 using a command compliant with the IPMI specification; BIOS acquiring the information, par 38].
It would have been obvious to one of ordinary skill in the art, having the teachings of Lu, Nulkar, Higuchi, and Hayashida before him before the effective filing date of the claimed invention, to incorporate the IPMI commands as taught by Hayashida into the method as disclosed by Lu, Nulkar, and Higuchi, to improve system management related to I/O devices through the use of a BIOS [Hayashida, par 4, 5].
Claims 10-12, 16, 17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lu, Nulkar, and Higuchi, and further in view of Cagle et al., 2004/0078679 A1.
Regarding Claim 10, Lu, Nulkar, and Higuchi disclose the method of Claim 9. However, the combination of references does not explicitly teach wherein the pausing of the executing of the booting operation is performed in response to receipt of the data processing unit failure state signal by the basic input/output system.
In the analogous art of boot failure detection, Cagle teaches wherein the pausing of the executing of the booting operation is performed in response to receipt of the data processing unit failure state signal by the basic input/output system [if the boot attempt is not successful (decision 308), the system BIOS determines if the device that just attempted to boot was the last device in the standard boot order list 205 (FIG. 2). If the last device from which a boot was attempted is the last device in the standard boot order list 205, the BIOS 202 (FIG. 2) delays for a predetermined time at 314. The BIOS 202 (FIG. 2) may optionally display a message that a boot sequence has just failed and that a new boot sequence will be tried; i.e. BIOS receiving failure signal at step 308, Fig. 2, 3; par 36].
It would have been obvious to one of ordinary skill in the art, having the teachings of Lu, Nulkar, Higuchi, and Cagle before him before the effective filing date of the claimed invention, to incorporate the pausing of the booting operation as taught by Cagle into the method as disclosed by Lu, Nulkar, and Higuchi, to allow for automatic reboot attempts to avoid user intervention [Cagle, par 15].
Regarding Claim 11, Lu, Nulkar, and Higuchi discloses the method of Claim 9. However, while Higuchi teaches a virtual function [testing virtual components during boot test, Fig. 14], the combination of references does not explicitly teach generating a data processing unit ready state signal following the identifying of the at least one function; and sending the data processing unit ready state signal to the basic input/output system.
In the analogous art of boot failure detection, Cagle teaches generating a data processing unit ready state signal following the identifying of the at least one function [attempt boot from identified device at step 306, Fig. 3]; and sending the data processing unit ready state signal to the basic input/output system [the BIOS attempts to boot from the identified device at 306. If the boot is successful (decision 308), then normal operation of the computer begins at 310 and the boot process terminates at 316; i.e. boot attempt successful being a ready state signal, par 35].
It would have been obvious to one of ordinary skill in the art, having the teachings of Lu, Nulkar, Higuchi, and Cagle before him before the effective filing date of the claimed invention, to incorporate the indication of being ready to continue the booting operation as taught by Cagle into the method as disclosed by Lu, Nulkar, and Higuchi, to allow for automatic reboot attempts to avoid user intervention [Cagle, par 15].
Regarding Claim 12, Lu, Nulkar, Higuchi, and Cagle disclose the method of Claim 11. Cagle further teaches wherein the re-executing of the booting operation is performed in response to receipt of the data processing unit ready state signal by the basic input/output system [the BIOS attempts to boot from the identified device at 306. If the boot is successful (decision 308), then normal operation of the computer begins at 310 and the boot process terminates at 316; i.e. boot attempt successful being a ready state signal, par 35].
Regarding Claims 16 and 17, Lu, Nulkar, and Higuchi disclose the apparatus of Claim 15. Claims 16 and 17 repeat the same limitations as recited in Claims 10 and 11, respectively, and are rejected accordingly.
Regarding Claim 20, Lu, Nulkar, and Higuchi disclose the article of manufacture of Claim 19. Claim 20 repeats the same limitation as recited in Claim 10, and is rejected accordingly.
Response to Arguments
Applicant’s arguments filed 04/22/26 have been considered but are moot due to the new rejection based on the references cited above.
Additionally, Applicant's arguments as to Lu have been fully considered but they are not persuasive.
Applicant argues Lu fails to disclose the booting operating comprises booting the first operating system of the host device and booting the second operating system of the data processing unit.
Examiner notes the rejection previously presented, and repeated above, relies upon the combination of Lu and Nulkar in addressing the first and second operating systems. As such, Applicant appears to be arguing against Lu individually. However, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Lu is relied upon for the operating system of the host device, while Nulkar teaches a service processor having its own operating system (i.e. a second operating system different from the main device). Thus, it is the combination of references that is relied upon in addressing the limitation at issue.
No additional arguments were made as to the remaining limitations of Claim 1 nor the remaining claims, and as such, the rejection is maintained.
Conclusion
Applicant is reminded that in amending a response to a rejection of claims, the patentable novelty must be clearly shown in view of the state of the art disclosed by the references cited and the objections made. Applicant must also show how the amendments avoid such references and objections. See 37 CFR §1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PAUL J YEN whose telephone number is (571)270-5047. The examiner can normally be reached M-F 8-5 PT.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Andrew J Jung can be reached at (571) 270-3779. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Paul Yen/Primary Examiner, Art Unit 2175
Prosecution Insights