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 .
Herein after “it would have been obvious” should be read as “it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention”.
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-3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al PN 2005/0060531 in view of Lee et al PN 7,765,393.
In regards to claim 1: Davis et al teaches an Information Handling System (IHS) (figure 2), comprising: a processor (management processor 210); and a memory (207) coupled to the processor, the memory having program instructions stored thereon ([0015] “Firmware executable at system boot typically includes boot loader functions for loading operating system software, as well as basic input/output system (BIOS) functions. In a heterogeneous cellular computer system, firmware executable at system boot includes these boot loader and BIOS functions, as well as firmware for performing rendezvous.”) that, upon execution, cause the IHS to, when the IHS is being booted: detect a Central Processing Unit (CPU) architecture type ([0017] “The identification register is read during system startup to identify a processor type, which may include an instruction set architecture (ISA), associated with the cell. The processor type is used by a system management subsystem to ensure that a compatible boot image is provided to processors of the cell.”) of the IHS; using a boot loader ([0015] “Firmware executable at system boot typically includes boot loader functions for loading operating system software, as well as basic input/output system (BIOS) functions. In a heterogeneous cellular computer system, firmware executable at system boot includes these boot loader and BIOS functions, as well as firmware for performing rendezvous.”) comprising a plurality of executable images each associated with a different CPU architecture type ([0036] “Management processor 210 then reads 306 boot-image information 402 from the boot EEPROM 207, and determines an appropriate boot image 404 of one or more boot images 404, 406 in boot EEPROM 207. A boot image is appropriate only if the boot image contains machine readable code compiled to execute on processors of the same processor type as processors of the cell.”.. “an appropriate boot image is the boot image having the most recent version number or compilation date of all boot images for that processor type that are present in boot EEPROM 207”); and using the boot loader, boot one of the executable images corresponding to the detected CPU architecture type on the HIS ([0036] “Finally, the processor 202 is allowed 310 to boot from the appropriate boot image 404 of the boot EEPROM 207”). Davis et al uses a boot loader to load the boot image but never mentions how the boot loader is obtained. Lee et al teaches loading a boot loader from a bootable utility (the boot media consisting of 305-309). (Abstract “During a boot process of the processing system, the BIOS loads a boot loader from one of the boot media, i.e., hard drives, floppy disks, CDs, USB flash memories, taps, etc. and passes control of the boot loader, the boot loader then loads an OS from the boot media.”). It would have been obvious to load a boot loader from a unified bootable utility because this would have given a source for the boot loader.
In regards to claim 2: Davis et al teaches the boot utility including an application (the operating system ([0015] “Firmware executable at system boot typically includes boot loader functions for loading operating system software”) Lee et al teaches “These external storage media may also be called "boot media" because they may store Operating Systems (OSs) 113 and boot loaders (or bootstrap loaders) 112.”
In regards to claim 3: Lee et al teaches a setup program (start-up program “Upon booting up, at block 201, the processors 101 run the instructions of the BIOS start-up program stored in ROM 103.”)
Claim(s) 4-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al PN 2005/0060531 in view of Lee et al PN 7,765,393 as applied to claim 1 above, and further in view of Warkentin et al PN 2021/0026648.
In regards to claim 4: Davis et al teaches booting including detecting architecture type. Davis et al does not mention either Multiple APIC Description Table (MADT) or Unified Extensible Firmware Interface (UEFI) module. Warkentin et al teaches booting taking into account both Multiple APIC Description Table (MADT) ([0031] “ACPI tables are of two types, one type being statically-defined system boot tables that follow straight structure definitions (e.g., RSDP, FADT, MADT, GTDT, CSRT, DBG2), and the other type being non-statically defined system boot tables,”) and Unified Extensible Firmware Interface (UEFI) module ([0004] “SBBR regulates how an OS/hypervisor boots and discovers hardware, bringing it in line with the way it is done for x86-based computer platforms that use the Unified Extensible Firmware Interface (UEFI) standard that incorporates a computer system boot information standard such as Advanced Configuration and Power Interface (ACPI), which uses ACPI tables when booting a computer platform.”). It would have been obvious to take into account both MADT and UEFI because these are common features addressed in booting.
In regards to claim 5: Warkentin et al teaches x86 ([0004] “ a wide range of devices (servers, workstations, etc.) and central processing units (CPUs), such as x86_64, ARM64®, x86, etc.”) and APCI. ([0043] “a Multiple APIC Description Table (MADT),”).
In regards to claim 6: Warkentin et al teaches ARM (ARM stands for advanced RISC machine [0004] “and central processing units (CPUs), such as x86_64, ARM64®, x86, etc. ACPI tables are a set of data structures, passed from firmware to the OS/hypervisor by the boot code”) and GIC ([0043] “Multiple APIC Description Table (MADT), GIC Distributor Table, Local GIC(0) Table, Local GIC(1) Table, and DSDT “devices” Table (comprising AML byte-code)”).
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al PN 2005/0060531 in view of Lee et al PN 7,765,393 as applied to claim 1 above, and further in view of Liu et al PN 2021/0326126.
In regards to claim 7: Davis et al teaches reading the type of the processor hardware but does not state the data form. Liu et al teaches UEFI capsules ([0015] “One distribution framework that may be used is a firmware update interface, such as the one defined by Unified Extensible Firmware Interface (UEFI) capsule update.”) that include hardware identification ([0046] “Computer system 700 may receive a second update capsule with a second payload, as discussed in reference to FIG. 8 below. The second update capsule may include a device identifier that identifies hardware resource 750.”). It would have been obvious to store the processor identifier in a UEFI capsule because this is one of the functions of a UEFI capsule.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al PN 2005/0060531 in view of Lee et al PN 7,765,393 as applied to claim 1 above, and further in view of Condra et al PN 9,195,831.
In regards to claim 8: Davis et al teaches identifying the processor/hardware type. Lee et al teaches loading a boot loader. Neither expressly teaches the boot loader is associated with the processor/hardware type. Condra et al teaches (Column 1 line 5 et seq. “The boot loader may be specific to the hardware of the computing device.”). It would have been obvious to have the boot loader be associated with the processor hardware because this would have allowed the proper boot loader for the different processor based upon type.
Claim(s) 9, 14-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al PN 2005/0060531 in view of Lee et al PN 7,765,393 as applied to claim 1 above, and further in view of Samuel et al PN 2014/0281466.
In regards to claims 9, 14: Davis et al teaches an Information Handling System (IHS) (figure 2), comprising: a processor (management processor 210); and a memory (207) coupled to the processor, the memory having program instructions stored thereon ([0015] “Firmware executable at system boot typically includes boot loader functions for loading operating system software, as well as basic input/output system (BIOS) functions. In a heterogeneous cellular computer system, firmware executable at system boot includes these boot loader and BIOS functions, as well as firmware for performing rendezvous.”) that, upon execution, cause the IHS to, when the IHS is being booted: detect a Central Processing Unit (CPU) architecture type ([0017] “The identification register is read during system startup to identify a processor type, which may include an instruction set architecture (ISA), associated with the cell. The processor type is used by a system management subsystem to ensure that a compatible boot image is provided to processors of the cell.”) of the IHS; using a boot loader ([0015] “Firmware executable at system boot typically includes boot loader functions for loading operating system software, as well as basic input/output system (BIOS) functions. In a heterogeneous cellular computer system, firmware executable at system boot includes these boot loader and BIOS functions, as well as firmware for performing rendezvous.”) comprising a plurality of executable images each associated with a different CPU architecture type ([0036] “Management processor 210 then reads 306 boot-image information 402 from the boot EEPROM 207, and determines an appropriate boot image 404 of one or more boot images 404, 406 in boot EEPROM 207. A boot image is appropriate only if the boot image contains machine readable code compiled to execute on processors of the same processor type as processors of the cell.”.. “an appropriate boot image is the boot image having the most recent version number or compilation date of all boot images for that processor type that are present in boot EEPROM 207”); and using the boot loader, boot one of the executable images corresponding to the detected CPU architecture type on the HIS ([0036] “Finally, the processor 202 is allowed 310 to boot from the appropriate boot image 404 of the boot EEPROM 207”). Davis et al uses a boot loader to load the boot image but never mentions how the boot loader is obtained. Lee et al teaches loading a boot loader from a bootable utility (the boot media consisting of 305-309). (Abstract “During a boot process of the processing system, the BIOS loads a boot loader from one of the boot media, i.e., hard drives, floppy disks, CDs, USB flash memories, taps, etc. and passes control of the boot loader, the boot loader then loads an OS from the boot media.”). It would have been obvious to load a boot loader from a unified bootable utility because this would have given a source for the boot loader.
Davis et al teaches multiple different boot images thus a multi-boot method (more than just dual). Davis et al, however, does not expressly use the words dual booting. Samuel et al teaches ([0007] “Conventional dual-booting approaches require substantial reconfiguration in order to change the selected boot image and provide no ability to update boot images in a fail-safe manner. Hence, there is a need for configurable dual-booting solution that allows boot determinations to be made in hardware and provides for seamless updating of boot images.”). It would have been obvious to use the boot images for dual booting because dual booting is used for separate selected configurations.
In regards to claim 15: Davis et al teaches the boot utility including an application (the operating system ([0015] “Firmware executable at system boot typically includes boot loader functions for loading operating system software”) Lee et al teaches “These external storage media may also be called "boot media" because they may store Operating Systems (OSs) 113 and boot loaders (or bootstrap loaders) 112.”
In regards to claim 16: Lee et al teaches a setup program (start-up program “Upon booting up, at block 201, the processors 101 run the instructions of the BIOS start-up program stored in ROM 103.”)
Claim(s) 10-12, 17-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al PN 2005/0060531 in view of Lee et al PN 7,765,393 and Samuel et al PN 2014/0281466 as applied to claim 9 above, and further in view of Warkentin et al PN 2021/0026648.
In regards to claim 10, 17: Davis et al teaches booting including detecting architecture type. Davis et al does not mention either Multiple APIC Description Table (MADT) or Unified Extensible Firmware Interface (UEFI) module. Warkentin et al teaches booting taking into account both Multiple APIC Description Table (MADT) ([0031] “ACPI tables are of two types, one type being statically-defined system boot tables that follow straight structure definitions (e.g., RSDP, FADT, MADT, GTDT, CSRT, DBG2), and the other type being non-statically defined system boot tables,”) and Unified Extensible Firmware Interface (UEFI) module ([0004] “SBBR regulates how an OS/hypervisor boots and discovers hardware, bringing it in line with the way it is done for x86-based computer platforms that use the Unified Extensible Firmware Interface (UEFI) standard that incorporates a computer system boot information standard such as Advanced Configuration and Power Interface (ACPI), which uses ACPI tables when booting a computer platform.”). It would have been obvious to take into account both MADT and UEFI because these are common features addressed in booting.
In regards to claims 11, 18: Warkentin et al teaches x86 ([0004] “ a wide range of devices (servers, workstations, etc.) and central processing units (CPUs), such as x86_64, ARM64®, x86, etc.”) and APCI. ([0043] “a Multiple APIC Description Table (MADT),”).
In regards to claims 12, 19: Warkentin et al teaches ARM (ARM stands for advanced RISC machine [0004] “and central processing units (CPUs), such as x86_64, ARM64®, x86, etc. ACPI tables are a set of data structures, passed from firmware to the OS/hypervisor by the boot code”) and GIC ([0043] “Multiple APIC Description Table (MADT), GIC Distributor Table, Local GIC(0) Table, Local GIC(1) Table, and DSDT “devices” Table (comprising AML byte-code)”).
Claim(s) 13, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al PN 2005/0060531 in view of Lee et al PN 7,765,393 and Samuel et al PN 2014/0281466 as applied to claim 9 above, and further in view of Liu et al PN 2021/0326126.
In regards to claims 13, 20: Davis et al teaches reading the type of the processor hardware but does not state the data form. Liu et al teaches UEFI capsules ([0015] “One distribution framework that may be used is a firmware update interface, such as the one defined by Unified Extensible Firmware Interface (UEFI) capsule update.”) that include hardware identification ([0046] “Computer system 700 may receive a second update capsule with a second payload, as discussed in reference to FIG. 8 below. The second update capsule may include a device identifier that identifies hardware resource 750.”). It would have been obvious to store the processor identifier in a UEFI capsule because this is one of the functions of a UEFI capsule.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PAUL R MYERS whose telephone number is (571)272-3639. The examiner can normally be reached telework M-F start 7-8 leave 4-5.
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.
/Paul R. MYERS/ Primary Examiner, Art Unit 2176