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 .
Claims 1-22, 24-27 are pending.
This is in response to communications filed on 6/24/26.
Claim Rejections - 35 USC § 112
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.
Claim 27 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 27 recites “an Extensible Firmware Interface (EFI) partition” in line 2. It is not clear whether the EFI is same or different from the EFI recited in line 5 of claim 1. It is necessary to establish a relationship between the recitations. For the rest of the action, it is taken that the same relationship is intended.
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) 21-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chien (US Patent Application Publication 20210286692), in view of Lou et al (CN 112114850; the translation provides the page and paragraphs), in view of Mehta (US Patent Application Publication 20170140146).
For claim 21, Chien teaches the following limitations: A method of booting/rebooting a client device (Fig 1 -Fig 9 , Fig 2 shows OS boot; [0005] booting a remote computing device; 106 in Fig 1 is the client device; Fig 5; 140 sends signal to BMC; client device receives the signal; [0023] [0025] [0036] mentions set the boot path policy through an out of band boot; thus the instruction is to boot/reboot) operable in a client/server network (Fig 1 shows the client server network between 102 and 106), in which a custom bootloader issues one or more instructions (120 in Fig 1 is the custom boot loader; [0005] mentions that the UEFI BIOS includes multiple POST routines and [0030] mentions several options of the POST boot path; thus the custom boot loader can issue the instruction to select a particular boot path; [0039] and Fig 5 shows the custom UEFI BIOS for the system; the bootloader is customized for the system) that supersedes one or more instructions of a standard bootloader (normal boot option mentions in [0035] [0037][0038]; this is the standard boot option as [0038] mentions normal boot option is performed for first time boot, hardware configuration change; [0039]-[0040] mention that the POST routine is selected from normal, fast boot, safety boot, factory provision, diagnostic boot as shown in Fig 4; therefore the custom boot loader can select other POST for other boot to supersede the standard boot loader; [0034][0048]-[0050] embedded Linux OS), the method comprising: receiving a manual interruption of a boot sequence (Fig 1 shows the operator set a boot path policy; [0023] [0039] and [0042][0054]; [0039] [0042] mentions “operator can read the option of POST routine” “until a new POST option of boot path is issued by operator”; thus operator can interrupt a boot sequence); executing a process (Fig 2; Fig 5 – Fig 9) to determine whether: a desirable boot sequence involves a separate bootable image present on the client device (the correct/desirable boot sequence is shown in Fig 9 when the security flag presents for the hardware diagnostic; step 938 and step 940 in Fig 9 mention about separate bootable image on the server 106; ISO image is the separate bootable image); or to connect to a server and receive a desirable playbook for execution (the limitation is recited alternatively, BRI does not include both alternatives), and executing one of the separate bootable image or the desirable playbook (step 942 of Fig 9) to boot the client device into an operating state ([0034][0048]-[0050] embedded Linux OS is booted and later other boot path can be adopted to boot OS [0005]-[0007][0025][0029]).
For the limitations “both the custom bootloader and the standard bootloader are executed from the same EFI partition of a bootable storage device resident on the client device”, Chien appears to teach that the same UEFI includes multiple routines ([0005] – UEFI BIOS includes multiple POST routines). However, Chien does not explicitly mention the same EFI partition for the two bootloaders. Thus, Chien does not explicitly mention the following limitations:
standard bootloader installed at the client device at factory
the custom bootloader is installed separate from and subsequent to installation of the standard bootloader
both the custom bootloader and the standard bootloader are executed from the same EFI partition of a bootable storage device resident on the client device
Lou teaches the following limitations:
standard bootloader installed at the client device at factory (page 5, last para; “step a: compiling custom Bootloader program; STM32 series single chip has recorded the preset Bootloader program when leaving factory and cannot be modified; Page 6, step c, (1) mentions STM32 processor executes the factory preset bootloader program if level is set high)
the custom bootloader is installed separate from and subsequent to installation of the standard bootloader (page 5, last para it is necessary to compile the custom bootloader program; page 6 step c – loading the custom boot loader program; STM32 processor executes the self-defined Bootloader program when the level is not set high; Page 7 second para – pin level is low processor executes self-defined bootloader program).
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to combine the teachings of Chien and Lou to provide the custom bootloader later after the standard boot loader that is installed at the factory, since that way the system can have the multiple options to boot from different bootloader as disclosed in both Chien and Lou. Such would provide the flexibility of enhancing the boot functionality later based on user preference. Chien allows multiple boot loaders to choose from ([0007] – multiple POST routines; Fig 4 – various boot paths) including the standard boot loader ([0038] – normal boot that is performed the first time in the [0038]). All boot loaders have separate paths and separate routines as shown in Fig 4 and Fig 6 – Fig 9. Chien is silent about the installation time of the Standard and Custom boot loader; the custom bootloader can be installed later in the system separately with the teachings of Lou. This increases functionality of the system at the customer site.
Chien in view of Lou does not explicitly mention the following limitations:
both the custom bootloader and the standard bootloader are executed from a same EFI partition of a bootable storage device resident on the client device
Mehta et al teach the following limitations:
both the custom bootloader and the standard bootloader are executed from a same EFI partition of a bootable storage device resident on the client device (partition 120 in Fig 1; 224 in Fig 2; boot loader firmware 226, 228 and 230 are stored in partition 224; [0033] [0048] mentions that EFI partition 224 stores boot loader 226, 228 and 230)
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to include a EFI partition to store the custom and standard bootloader since that will facilitate the recovery operation quickly. Mehta [0033] mentions the storage of multiple bootloaders in the EFI partition to facilitate the recovery mode ([0033]). With the teaching from Mehta, Chien, in view of Lou will be able to store the standard and custom bootloaders in the same EFI partition. That way, system operation will be simplified as one partition is storing the bootloaders.
For claim 22, Chien teaches wherein, after executing one of the separate bootable image or the desirable playbook to boot the operating system, the method further comprises one of setting one or more UEFI variables for a next boot ((Fig 2 shows the reading of boot path during power on, which sets the UEFI variable to a new value [0029][0031][0042]- operator knows the last status and sets the POST routine).
Claim(s) 1-6, 13-16, 18, 20, 24-25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chien (US Patent Application Publication 20210286692) in view of Samuel et al (US Patent Application Publication 20230067647), further in view of Lou et al (CN 112114850; the translation provides the page and paragraphs), in view of Mehta (US Patent Application Publication 20170140146).
For claim 1, Chien teaches the following limitations: A method of booting/rebooting a client device (Fig 1 -Fig 9 , Fig 2 shows OS boot; [0005] booting a remote computing device; 106 in Fig 1 is the client device) in which a custom bootloader configured to issue one or more instructions (120 in Fig 1 includes the custom boot loader as [0005] mentions that UEFI BIOS includes multiple POST routines; the BIOS UEFI can read policy of boot path from BMC 110 shown in Fig 1; [0039] and Fig 5 shows the custom UEFI BIOS for the system; the bootloader is customized for the system to select a desired POST routine) that supersede one or more instructions issued by a standard boot loader (the multiple POST routine includes the standard POST routine or boot loader), the method comprising: receiving a signal instructing the client device to update unified extensible firmware interface (UEFI) (Fig 5; 140 sends signal to BMC; client device receives the signal; [0023] [0025] [0036] mentions set the boot path policy through an out of band boot; thus the instruction is to boot/reboot; [0039] mentions about setting the UEFI variable); writing one or more UEFI variables based on the received signal ([0029] mentions that UEFI BIOS uses the command to retrieve the demand issued by the remote data center operator and sets the UEFI variable for the selected boot option; [0042] setting is communicated UEFI BIOS saves it as a UEFI variable); executing the custom bootloader to evaluate the one or more UEFI variables to identify if a security flag has been set ([0055]; based on the UEFI boot variable; the routine determines whether the selected boot path is the normal boot; thus the UEFI variable is evaluated and “normal boot” flag is found; normal boot is when UEFI variables do not identify security flag for other boots; Fig 6 shows the normal boot; Fig 4), and provided a security flag has been set ([0048] and Fig 9 shows the flag is set for hardware diagnostic; the UEFI variable indicates the hardware diagnostic option; this is a security flag since the data is used to perform the hardware fault analysis and identify root causes, collect debugging messages of sate test, error log of server- these are related to security operation of the boot), the custom bootloader executes a process to determine whether: a desirable boot sequence uses a separate bootable image stored on the client device (the correct boot sequence is shown in Fig 9 when the security flag presents for the hardware diagnostic; step 938 and step 940 in Fig 9 mention about separate bootable image on the server 106; ISO image is the separate bootable image); or to connect to a deterministic network endpoint and receive a desirable playbook for execution at the client device (the limitation is recited alternatively, BRI does not include both alternatives) and executing one of the separate bootable image or the desirable playbook (step 942 of Fig 9) to boot the client device into an operational state ([0034][0048]-[0050] embedded Linux OS is booted and later other boot path can be adopted to boot OS [0005]-[0007][0025][0029]).
Chien does not explicitly mention about updating multiple UEFI variables. Samuel et al teach UEFI variables updating ([0026] – setting UEFI variables; [0034][0064] Fig 4). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to update UEFI variables, since configuration changes need requires variables updating. That way, system can be updated for new configuration. As Chien teaches various way to update the UEFI variable ([0039]), multiple variables can be updated too.
Chien appears to teach that the same UEFI includes multiple routines ([0005] – UEFI BIOS includes multiple POST routines). However, Chien or Samuel does not explicitly mention the same EFI partition for the two bootloaders. Thus, Chien in view of Samuel does not explicitly mention the following limitations:
standard bootloader installed at the client device at factory
the custom bootloader is installed separate from and subsequent to installation of the standard bootloader
both the custom bootloader and the standard bootloader are executed from the same EFI partition of a bootable storage device resident on the client device
Lou teaches the following limitations:
standard bootloader installed at the client device at factory (page 5, last para; “step a: compiling custom Bootloader program; STM32 series single chip has recorded the preset Bootloader program when leaving factory and cannot be modified; Page 6, step c, (1) mentions STM32 processor executes the factory preset bootloader program if level is set high)
the custom bootloader is installed separate from and subsequent to installation of the standard bootloader (page 5, last para it is necessary to compile the custom bootloader program; page 6 step c – loading the custom boot loader program; STM32 processor executes the self-defined Bootloader program when the level is not set high; Page 7 second para – pin level is low processor executes self-defined bootloader program), the custom boot loader supersede one or more instructions issued by a standard boot loader currently installed at the client device
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to combine the teachings of Chien, Samuel and Lou to provide the custom bootloader later after the standard boot loader that is installed at the factory, since that way the system can have the multiple options to boot from different bootloader as disclosed in both Chien and Lou. Such would provide the flexibility of enhancing the boot functionality later based on user preference. Chien allows multiple boot loaders to choose from ([0007] – multiple POST routines; Fig 4 – various boot paths) including the standard boot loader ([0038] – normal boot that is performed the first time in the [0038]). All boot loaders have separate paths and separate routines as shown in Fig 4 and Fig 6 – Fig 9. Chien or Samuel is silent about the installation time of the Standard and Custom boot loader; the custom bootloader can be installed later in the system separately with the teachings of Lou. This increases functionality of the system at the customer site.
Chien in view of Samuel in view of Lou does not explicitly mention the following limitations:
both the custom bootloader and the standard bootloader are executed from a same EFI partition of a bootable storage device resident on the client device
Mehta et al teach the following limitations:
both the custom bootloader and the standard bootloader are executed from a same EFI partition of a bootable storage device resident on the client device (partition 120 in Fig 1; 224 in Fig 2; boot loader firmware 226, 228 and 230 are stored in partition 224; [0033] [0048] mentions that EFI partition 224 stores boot loader 226, 228 and 230)
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to include a EFI partition to store the custom and standard bootloader (as taught in Mehta) since that will facilitate the recovery operation quickly. Mehta [0033] mentions the storage of multiple bootloaders in the EFI partition to facilitate the recovery mode ([0033]). With the teaching from Mehta, Chien, in view of Samuel, in view of Lou will be able to store the standard and custom bootloaders in the same EFI partition. That way, system operation will be simplified as one partition is storing the bootloaders.
For claim 2, Chien teaches wherein the signal originates as a message from the network or deterministic network endpoint (Fig 1, 102 sends the message). Chien does not explicitly mention about secure format of the message. However, Chien considers security via cryptography (Fig 8, step 824 [0065]). Therefore, secure message can facilitate more security. It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to have the secure message as it enhances the security.
For claim 3, Chien teaches wherein the signal originates as a message from the network (Fig 1, 102 sends the message). Chien does not explicitly mention about secure format of the message and sender is authentic. Securing message and trusted sender through cryptographic keys and digital certificates are known in the art. Chien considers security via cryptography (Fig 8, step 824 [0065]). Therefore, secure message and authenticated sender can facilitate more security. It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to have the secure message and sender authentication as it enhances the further security in the system.
For claim 4, Chien teaches wherein the signal originates as a message from the network (Fig 1, 102 sends the message). Chien does not explicitly mention that variables are written in secure message format. However, Chien considers security via cryptography and UEFI BIOS using the key (Fig 8, step 824 [0065]). Therefore, secure message can facilitate more security. It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to have the UEFI variables written in secure message format as it enhances the security.
For claim 5, wherein the device connects to the server at a pre-OS level and, upon connecting to the server, the client device is authenticated to the server (Chien Fig 1; operator connects the remote station with the device 106 in pre-boot; [0023] mentions about data center operator and therefore, a defined particular entity; 102’s operator is authenticated because operator has password to log on; this limitation emphasizes the alternative embodiment of claim 1 and BRI does not include the alternative embodiment).
For claim 6, Chien Fig 2 shows 102 and 106 are exchanging information and thus, one is authenticated to another ([0023]) and operator perform remote diagnostics and therefore, shares data about a current state of the client device.
For claim 13, wherein the server 102 or the deterministic network endpoint is the sender of the signal (Fig 1; 102 sends the signal to 106, Chien) instructing client device to update the UEFI variable (Fig 6 618; [0039] – 102 sets UEFI variable) and reboot ([0039]).
For claim 14, wherein the server and client connect via one of a pre-OS level networking (pre-OS level networking; Fig 1 of Chien, [0023], [0039][0042] of Chien).
For claim 15, wherein an extensible firmware interface (EFI) system partition on the client is modified ([0039] modified UEFI can accept other commands; UEFI BIOS exchanges commands for out-of-band communications Chien), the custom bootloader is installed on client bootable storage device ([0024] storing the BIOS, Chien), and a boot order is updated inserting a preloader as a first boot entry (Fig 5; 120 receives the POST of boot path as 2).
For claim 16, Chien teaches wherein, after executing one of the separate bootable image or the correct playbook to boot the operating system, the method further comprises one of unsetting the security flag or setting the UEFI variables to cause the device to enter a different playbook on a next boot (Fig 2 shows the reading of boot path during power on, which sets the UEFI variable to a new value and unsetting the security flag and have a different playbook such as loading a different OS as mentioned in [0029][0031]).
For claim 18, Chien teaches the following limitations: A client device (106 is the client) in a client/server network (Fig 1), comprising: a processor ([0024]); one or more storage devices comprising an operating system, a standard bootloader for the operating system and a custom bootloader (Fig 1 shows OS 140; 120 is the custom bootloader; custom boot loader has the provisions for standard boot loader as explained in [0035] – normal POST routine; memory and storage are shown in Fig 1 and mentioned in [0024]), the one or more storage devices including an extensible firmware interface (EFI) system partition ([0024] – persistent storage stores UEFI BIOS; thus, the storage has partition for storing UEFI, or has EFI partition) with boot device select unified extensible firmware interface (UEFI) (Fig 5 shows that UEFI BIOS (including the partition) sets UEFI variable; [0039][0042]) pointing to the custom bootloader (the variable points to the respective POST routine [0005]-[0008] and [0042]), whereby the one or more instructions issued by custom bootloader (120 in Fig 1 includes the custom boot loader as [0005] mentions that UEFI BIOS includes multiple POST routines; the BIOS UEFI can read policy of boot path from BMC 110 shown in Fig 1; [0039] and Fig 5 shows the custom UEFI BIOS for the system; the bootloader is customized for the system to select a desired POST routine) supersede one or more instructions issued by a standard boot loader (the multiple POST routine includes the standard POST routine or boot loader) and computer readable instructions, which, when executed by the processor cause the processor ([0069] [0053]) to: receive a signal instructing the client device to reboot ( Fig 5; 140 sends signal to BMC; client device receives the signal; [0023] [0025] [0036] mentions set the boot path policy through an out of band boot; thus the instruction is to boot/reboot; [0039] mentions about setting the UEFI variable); write one or more UEFI variables based on the received signal on the device ([0029] mentions that UEFI BIOS uses the command to retrieve the demand issued by the remote data center operator and sets the UEFI variable for the selected boot option; [0042] setting is communicated UEFI BIOS saves it as a UEFI variable); evaluate the one or more UEFI variables [0055]; based on the UEFI boot variable; the routine determines whether the selected boot path is the normal boot or other boot; Fig 4; Fig 6 and other Figures mention reading the UEFI variable to device the boot path), wherein, when a security flag has not been set (Fig 4 identifies the flag; the flag can be set to one of five values – “normal boot”, “fast boot”, “safety boot”, “factory provision” and “hardware diagnostic”; thus the UEFI variable is evaluated to find the value of the flag; when “normal boot” flag is found, the flag is not set to “safety boot flag” or “secure boot” or “hardware diagnostic” shown in Fig 4; Fig 6 shows the normal boot; thus the secure flag is not set to safety boot/hardware diagnostic), the custom bootloader performs a direct boot to the operating system ([0055] mentions the normal boot option; the UEFI boot service seek the bootable partition from hard drive and bootable image from a network drive; [0035] mentions loading the OS during normal boot option; the flag value for normal boot has not been set to “safety boot” flag or hardware diagnostic flag) and wherein, when the security flag has been set ([0048][0049] and Fig 9; the UEFI variable indicates the hardware diagnostic option; this is where a security flag has been set to “hardware diagnostic” as shown in Fig 4), the custom bootloader executes a process to determine whether: a desirable boot sequence uses a separate bootable image present on the client device (the correct boot sequence is shown in Fig 9 when the security flag presents for the hardware diagnostic; step 938 and step 940 in Fig 9 mention about separate bootable image on the server 106; ISO image is the separate bootable image) to execute the separate bootable image (step 942 of Fig 9) to boot into an operating state ([0034][0048]-[0050] embedded Linux OS is booted and later other boot path can be adopted to boot OS [0005]-[0007][0025][0029]); or to connect to a deterministic network endpoint and receive a desirable playbook for execution and to execute the desirable playbook to boot into an operational state (the limitation is recited alternatively, BRI does not include alternative)
Chien does not explicitly mention about updating multiple UEFI variables. Samuel et al teach UEFI variables updating ([0026] – setting UEFI variables; [0034][0064] Fig 4).
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to update UEFI variables, since configuration changes need requires variables updating. That way, system can be updated for new configuration. As Chien teaches various way to update the UEFI variable ([0039]), multiple variables can be updated too.
Chien appears to teach that the same UEFI includes multiple routines ([0005] – UEFI BIOS includes multiple POST routines). However, Chien or Samuel does not explicitly mention the same EFI partition for the two bootloaders. Chien in view of Samuel does not explicitly mention the following limitations:
standard bootloader installed at the client device at factory
the custom bootloader is installed separate from and subsequent to installation of the standard bootloader
both the custom bootloader and the standard bootloader are executed from the same EFI partition of a bootable storage device resident on the client device
Lou teaches the following limitations:
standard bootloader installed at the client device at factory (page 5, last para; “step a: compiling custom Bootloader program; STM32 series single chip has recorded the preset Bootloader program when leaving factory and cannot be modified; Page 6, step c, (1) mentions STM32 processor executes the factory preset bootloader program if level is set high)
the custom bootloader is installed separate from and subsequent to installation of the standard bootloader (page 5, last para it is necessary to compile the custom bootloader program; page 6 step c – loading the custom boot loader program; STM32 processor executes the self-defined Bootloader program when the level is not set high; Page 7 second para – pin level is low processor executes self-defined bootloader program).
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to combine the teachings of Chien, Samuel and Lou to provide the custom bootloader later after the standard boot loader that is installed at the factory, since that way the system can have the multiple options to boot from different bootloader as disclosed in both Chien and Lou. Such would provide the flexibility of enhancing the boot functionality later based on user preference. Chien allows multiple boot loaders to choose from ([0007] – multiple POST routines; Fig 4 – various boot paths) including the standard boot loader ([0038] – normal boot that is performed the first time in the [0038]). All boot loaders have separate paths and separate routines as shown in Fig 4 and Fig 6 – Fig 9. Chien or Samuel is silent about the installation time of the Standard and Custom boot loader; the custom bootloader can be installed later in the system separately with the teachings of Lou. This increases functionality of the system at the customer site.
Chien in view of Samuel in view of Lou does not explicitly mention the following limitations:
both the custom bootloader and the standard bootloader are executed from a same EFI partition of a bootable storage device resident on the client device
Mehta et al teach the following limitations:
both the custom bootloader and the standard bootloader are executed from a same EFI partition of a bootable storage device resident on the client device (partition 120 in Fig 1; 224 in Fig 2; boot loader firmware 226, 228 and 230 are stored in partition 224; [0033] [0048] mentions that EFI partition 224 stores boot loader 226, 228 and 230)
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to include a EFI partition to store the custom and standard bootloader since that will facilitate the recovery operation quickly. Mehta [0033] mentions the storage of multiple bootloaders in the EFI partition to facilitate the recovery mode ([0033]). With the teaching from Mehta, Chien, in view of Samuel, in view of Lou will be able to store the standard and custom bootloaders in the same EFI partition. That way, system operation will be simplified as one partition is storing the bootloaders.
For claim 20, Chien teaches wherein the signal instructing reboot the client device originates as a message from the network (Fig 1, 102 sends the message). Chien or Samuel or Lou does not explicitly mention about secure format of the message. Secure message is known in the art. However, Chien considers security via cryptography (Fig 8, step 824 [0065]). Therefore, secure message can facilitate more security. It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to have the secure message as it enhances the security.
For claim 24, Chien [0045] [0046] mentions that safety boot is based on hard faults of server 106. [0052] mentions hardware diagnostic options allows the analysis of fault information when fault happens. Thus, the Fig 7 -Fig 9 shows the safety boot/diagnostic path based on setting the UEFI variable corresponding to the safety boot/diagnostic boot based on fault.
For claim 25, Chien [0030] [0036] [0041] mention that the option is controllable through in-band mechanism that occurs through an interface of the host system and may exchange commands from operating system to BMC. Thus, the security flag setting can be performed without remote operator 102. The setting can be performed via in-band control via interface to the host system of the server.
Claim(s) 7-12, 17, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chien (US Patent Application Publication 20210286692) in view of Samuel et al (US Patent Application Publication 20230067647), in view of Lou (CN 112114850; the translation provides the page and paragraphs) in view of Mehta (US Patent Application Publication 20170140146), further in view of Mujtaba et al (US Patent 8589667).
For claim 7, the operator sets the boot path policy ([0023] – data; Chien) which includes values of UEFI variables ([0039] Chien), which are shared between the two devices server and client device. Based on the shared values of the variable, a desired OS is determined (ISO image in Fig 9). The correct playback is optional in alternative embodiment in claim 1 (appears that claims 7-12 reciting playbook that is for alternate embodiment in claim 1); however, for compact prosecution Examiner is addressing that. Chien in view of Samuel, in view of Lou in view of Mehta does not explicitly about downloading from server for execution of software. Mujtaba et al teach downloading a correct software from a trusted server for boot (lines 55-60 of col 6). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to connect to a network endpoint and to receive a correct playbook so that the system can boot the OS correctly. The operator provides command for the UEFI variable for the POST routine in Chien ([0039] [0042]). Therefore, the routine is based on the shared data.
For claim 8, the correct playbook comprises at least one of a correct boot sequence and a correct bootable disk image ((lines 55-60 of col 6 Mujtaba; such a software is the disk image).
For claim 9, wherein the correct playbook further comprises a set of variables or instructions evaluated by the correct playbook in executing the correct playbook ((lines 55-67 of col 6 Mujtaba; such a software includes certificates for indicating trustiness).
For claim 10, server is the remote station 102 in Chien. Mujtaba et al teach downloading a correct software from a trusted server for boot (lines 55-60 of col 6). With the teaching, the server 102 in Chien can initiate a download of the playbook to the client device so that sending playbook to the network device 106 is performed. It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to download the playbook and transmit it to the client device, since that way client device can get the necessary file.
For claim 11, server is the remote station 102 in Chien. Mujtaba et al teach downloading a correct software from a trusted server for boot (lines 55-60 of col 6). With the teaching, the server 102 in Chien can initiate a download of the playbook to the client device so that sending playbook to the network device 106 is performed. It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to download the playbook and transmit it to the client device, since that way client device can get the necessary file.
For claim 12, lines 24-58 of col 6 of Mujtaba – the software components are downloaded are the files of OS.
For claim 17, client device connecting to the server (or deterministic end point), the client device is authenticated to the server, the operator in Chien need to use password to logon and client is authenticated to the server (Fig 1; Chien [0023]). Chien in view of Samuel, in view of Lou, in view of Mehta does not teach wherein the device connects to the server via Bluetooth. However, connecting via Bluetooth is known in the art (Mujtaba Fig 9). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to connect via Bluetooth as Bluetooth can connect wirelessly which provides user convenience.
For claim 19, Chien in view of Samuel, in view of Lou in view of Mehta does not explicitly mention processor evaluating sender and content to be trusted, although Chien considers security via cryptography (Fig 8, step 824 [0065]). Mujtaba teaches evaluating whether a sender and content of the signal is trusted (lines 24-60 of col 9; code is authenticated and server is trusted). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to have the trusted sender and content as it enhances the security in the system.
Claim(s) 26-27 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chien (US Patent Application Publication 20210286692) in view of Samuel et al (US Patent Application Publication 20230067647), in view of Lou (CN 112114850; the translation provides the page and paragraphs) in view of Mehta (US Patent Application Publication 20170140146), further in view of Bilal et al (US Patent Application Publication 2020/0034155)
For claim 26, Chien mention that the UEFI BIOS is stored in persistent storage ([0024]) and can seek bootable partition from hard disk drive ([0055]), but the cited art does not explicitly mention that UEFI BIOS is stored in hard drive. As known in the art, persistent storage can be a hard drive where the UEFI can be stored ([0029] Bilal). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to use a hard drive to store the UEFI BIOS, since hard drive is reliable and easily available.
For claim 27, Chien mention that the UEFI BIOS is stored in persistent storage ([0024]) and can seek bootable partition from hard disk drive ([0055]) and Mehta teaches the EFI partition for the bootloader ([0033][0048]), but cited art does not explicitly mention that UEFI BIOS is stored in hard drive. As known in the art, persistent storage can be a hard drive where the UEFI can be stored and UEFI can be stored on the EFI partition of the hard drive ([0029] Bilal). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to use a hard drive partition to store the UEFI BIOS, since hard drive is reliable and easily available.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-22, 24-27 for 35 USC 103 rejections have been considered but are moot because of the new ground of rejection. As Chien, Lou, Mujtaba and Bilal are still relied upon for rejection, Examiner is addressing relevant arguments regarding these references.
Regarding the combination of Chien and Lou, Applicant argues that the combination of Chien and Lou is improper because these references focus on different technical fields and address different problems. The system of Chien can’t simply add Lou’s bootloader because it would require replacing one hardware platform with the other.
Examiner disagrees. Chien uses various multiple bootloaders as explained above (Fig 4 further mention normal boot, factory provision boot and other boots). Thus, Chien provides the booting related to factory set. Chien does not mention the timing relation between the standard boot and the custom boot – the standard boot is installed at factory. Lou clearly shows the two boot loaders (custom and standard boot loaders) where standard bootloader is installed at the factory. This is related to timeline of installation, not related to hardware. Chien already teaches necessary hardware and bootloaders for the system.
Regarding claim 7, Applicant further argues that Mujtaba is directed to downloading software from a trusted server and Chien is directed to selection of a POST routine for boot up. According to the applicant, this teaching does not suggest modifying Chien’s method of selecting a POST routing.
Examiner disagrees. The “desired playback” limitation is recited alternatively in claim 1 as mentioned above. However, for compact prosecution, Mujtaba is introduced for the teachings of downloading software for boot, which can be incorporated into Chien in view of Samuel in view of Lou in view of Mehta to continue booting. Both are related to booting and therefore, Mujtaba’s teachings can be incorporated into Chien so that playbook can be downloaded from server to client. Chien teaches the boot path and deriving the OS based on the boot path that is further based on shared values of UEFI variable (Fig 5 – Fig 9) and the desired playbook can be downloaded from a trusted server with the teaching of Mujtaba. Such a desired download will allow Chien to boot with the desired OS. The booting of desired OS provides a better user choice.
Conclusion
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 FAHMIDA RAHMAN whose telephone number is (571)272-8159. The examiner can normally be reached Monday - Friday 10 AM - 7 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, Andrew Jung can be reached at 571-270-3779. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. 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.
/FAHMIDA RAHMAN/Primary Examiner, Art Unit 2175
Prosecution Insights