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 .
This is in response to communications filed on 11/26/25.
Claims 1-20 are pending.
Claim Interpretation
The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent is not met. If the condition for performing a contingent step is not satisfied, the performance recited by the step need not be carried out in order for the claimed method to be performed. See Ex Parte Schulhauser. For example, assume a method claim requires step A if a first condition happens and step Bif a second condition happens. If the claimed invention may be practiced without either the first or second condition happening, then neither step A or B is required by the broadest reasonable interpretation of the claim. If the claimed invention requires the first condition to occur, then the broadest reasonable interpretation of the claim requires step A. If the claimed invention requires both the first and second conditions to occur, then the broadest reasonable interpretation of the claim requires both steps A and B (MPEP 2111.04).
Claims 1, 5-6 recite the limitations “in response to receiving an activation instruction, exiting …”. The BRI does not include the conditions and associated functions based on the conditions when method can be practiced without conditions being met. BRI does not include “in response to receiving an activation instruction, exiting …” because method can be practiced without receiving the activation instruction. For compact prosecution, Examiner addressed the conditional limitations as described below. However, BRI includes the conditions “in response to powering on or rebooting …” as this step is required for the method to take place.
The broadest reasonable interpretation of a system (or apparatus or product) claim having structure that performs a function, which only needs to occur if a condition precedent is met, requires structure for performing the function should the condition occur. The system claim interpretation differs from a method claim interpretation because the claimed structure must be present in the system regardless of whether the condition is met and the function is actually performed. Claims 8-20 recite the system claim and the BRI includes structures corresponding to conditions “in response to receiving an activation instruction, exiting …”.
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.
Claims 1-20 are 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.
For claim 1, 8 and 15, the recited limitations “a request to maintain the standby state is transmitted periodically to a boot orchestrator” is unclear because the claims do not provide a discernable boundary on what performs the functions. It is unclear how the request is transmitted – it merely states a function without providing any indication how the function is performed. See MPEP 2173.05(g) for more information. Claims 2-7. 9-14 and 16-20 depend on the respective independent claims and incorporate the ambiguity.
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-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim Young (KR 101535153; the rejection refers to English translation from Espacenet) and further in view of Subbaiah (US Patent Application Publication 20240303059), further in view of Phelan et al (US Patent Application Publication 2015/0220348).
For claim 1, Kim Young teaches the following limitations: A method comprising: in response to powering on or rebooting a computing device ([0007] [0046] client host 20 is powered on; client host 20 in Fig 1 and client host 200 in Fig 2 is the computing device), performing a pre-boot process (Fig 1 shows the PXE boot 21) comprising loading an Operating System (OS) installer into storage of the computing device ([0028]; management host completes connection with client host and kernel image and kickstart configuration file may be transmitted to the client host to install the OS) and executing the OS installer ([0021][0029] – process of installing the OS through kickstart setting file); entering, by a processing device ([0047] [0055] [0056] [0058] [0062] mention about standby mode entry in step 203 of Fig 3; the standby state is where client is not assigned IP [0056]) during performing the pre-boot process ([0046] [0053]-[0054] is the pre-boot process; [0055]-[0056] describes the standby mode entry in step 203 of Fig 3); and in response to receiving an activation instruction ([0057]-[0058] the manager host determines that the installation is required, go back to installation control step (i.e., standby state waiting loop is over) to allow allocating IP to client host – that is the activation), exiting the standby state ([0064][0065][0028] IP allocation to client host is performed; thus exiting the standby mode) and installing an operating system of the computing device ([0065]).
Kim Young does not explicitly mention that the processing device executes the OS installer during entry of the standby mode. In other words, Kim Yung teaches standby or waiting during pre-booting state before downloading the installer image into the client.
Subbaiah teaches the following limitations: entering, by a processing device executing the OS installer, a standby state (Fig 1 and Fig 5; step 530 of Fig 5 mentions about the waiting loop or standby state that is entered through execution of the installer “option”; [0012]-[0013] the device receives an option to wait for confirmation; according to application’s specification [0014], standby state is the waiting state; “option” is to enable a user interface for a confirmed timeout – the installer).
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 Kim and Subbaiah to provide the installer to the network device and put the network device into the standby state when device is executing the installer (as taught in Subbaiah). Kim’s system is to allow the management host to put the device into standby mode before sending the various installation files ([0065] of Kim). However, Kim’s system can be modified to place the system into standby state after providing the installer into the device as taught in Subbaiah Fig 1 and Fig 5; [0051]-[0052] so as to confirm the installation. In such a case, pre-boot process comprises the steps till loading the installer (i.e., before the enablement of standby state) and entry into standby state is after the pre-boot process. That way user has more control over the system. When system is placed into standby mode for user confirmation, it ensures that user affirmation is required for any installation. This provides a flexible and well-maintained system.
Kim in view of Subbaiah does not explicitly mention a request to maintain the standby state is transmitted periodically to a boot orchestrator. In Subbaiah, the roll back or installation is performed after timed out ([0013]). Thus, it appears that no further request to maintain the standby state is made to the boot orchestrator.
Phelan et al teach the following limitations:
entering a standby state after performing a pre-boot process (Fig 7; 710 is in a hold state; [0060] mentions that 710 pause and wait for the user preferences at administrative system 720; thus 710 enters standby state after configuration data is received from 720), wherein a request to maintain the standby state is transmitted periodically to a boot orchestrator (boot orchestrator is 720; 710 made the request to 720 Fig 7; [0061] mentions that 710 waits again by transferring a second PXE request; thus, second PXE request is a request to maintain the standby state; the request to maintain the standby state is transmitted periodically until approval is received).
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 Kim, Subbaiah and Phelan et al to transmit a request to maintain the standby state periodically to a boot orchestrator, since that provides a chance to install with repeated user verification. Subbaiah provides the option for confirmation, but the option is not periodic. With the teachings from Phelan, Kim in view of Subbaiah will provide repeated verification and keep the system in standby state until the confirmation is received. That way, system can install the operating system with confirmed user verification.
For claim 2, Kim Young teaches wherein performing the pre-boot process comprises initializing and testing hardware of the computing device (Fig 2 step 1 through step 6 includes setting IP of the client host 200, requires initializing of testing hardware; [0057]) .
For claim 3, Kim Young teaches wherein performing the pre-boot process comprises initializing the OS installer ([0057] and [0065]; management host initializes OS installer for sending that to client host).
For claim 4, Kim Young or Subbaiah does not explicitly mention requesting OS configuration information for installing the operating system during standby state. Kim Young mentions about checks to determine whether new operating system is backward compatible with active configuration of the device ([0010]). Thus, the user can check and determine the backward compatibility with the OS configuration. Phelan teaches requesting configuration information for installing OS during standby state (Fig 7; PXE response includes configuration; thus PXE request represents both standby state maintain request and configuration request; [0060] mention installing OS).
For claim 5, Kim Young and Subbaiah teaches wherein receiving the activation instruction comprises receiving a configuration file describing information used by the OS installer to install the operating system ([0050] Kim – rebooting process to install the OS; [0058] Subbaiah – storing information with failed attempt).
For claim 6, Subbaiah teaches wherein the activation instruction is received from a boot orchestrator (step 510-520 of Fig 5 [0016] received from another device) configured to maintain the computing device in the standby state (step 520 and 530 of Fig 5) while waiting to activate the computing device in response to a resource request generated by the computing device (user confirmation through user interface; [0013]).
For claim 7, Kim Young teaches wherein the computing device powers on or reboots in response to a power-on command or reboot command received from the boot orchestrator ([0046] [0007][0023] mention power on process). This must happen before any resource request.
For claim 8, Kim Young teaches the following limitations: A computing device comprising: a memory; and a processing device, operatively coupled to the memory, the processing device to (page 1, title of the invention and [0001]-[0003]): perform a pre-boot process (Fig 1 shows the PXE boot 21) in response to powering on or rebooting a computing device ([0007] [0046] client host 20 is powered on; client host 20 in Fig 1 and client host 200 in Fig 2 is the computing device),wherein to perform a pre-boot process comprising loading an Operating System (OS) installer into storage of the computing device ([0028]; management host completes connection with client host and kernel image and kickstart configuration file may be transmitted to the client host to install the OS) and executing the OS installer ([0021][0029] – process of installing the OS through kickstart setting file); enter, by a processing device ([0047] [0055] [0056] [0058] [0062] mention about standby mode entry in step 203 of Fig 3; the standby state is where client is not assigned IP [0056]) during performing the pre-boot process ([0046] [0053]-[0054] is the pre-boot process; [0055]-[0056] describes the standby mode entry in step 203 of Fig 3); and in response to receiving an activation instruction ([0057]-[0058] the manager host determines that the installation is required, go back to installation control step (i.e., standby state waiting loop is over) to allow allocating IP to client host – that is the activation), exit the standby state ([0064][0065][0028] IP allocation to client host is performed; thus exiting the standby mode) and install an operating system of the computing device ([0065]).
Kim Young does not explicitly mention that the processing device executes the OS installer during entry of the standby mode. In other words, Kim Yung teaches standby or waiting during pre-booting state before downloading the installer.
Subbaiah teaches the following limitations: entering, by a processing device executing the OS installer, a standby state (Fig 1 and Fig 5; step 530 of Fig 5 mentions about the waiting loop or standby state that is entered through execution of the installer “option”; [0012]-[0013] the device receives an option to wait for confirmation; according to application’s specification [0014], standby state is the waiting state; “option” is to enable a user interface for a confirmed timeout).
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 Kim and Subbaiah to provide the installer to the network device and put the network device into the standby state when device is executing the installer (as taught in Subbaiah). Kim’s system is to allow the management host to put the device into standby mode before sending the various installation files ([0065] of Kim). However, Kim’s system can be modified to place the system into standby state after providing the installer into the device as taught in Subbaiah Fig 1 and Fig 5; [0051]-[0052] so as to confirm the installation. In such a case, pre-boot process comprises the steps till loading the installer (i.e., before the enablement of standby state) and entry into standby state is after the pre-boot process. That way user has more control over the system. When system is placed into standby mode for user confirmation, it ensures that user affirmation is required for any installation. This provides a flexible and well-maintained system.
Kim in view of Subbaiah does not explicitly mention a request to maintain the standby state is transmitted periodically to a boot orchestrator. In Subbaiah, the roll back or installation is performed after timed out ([0013]). Thus, it appears that no further request to maintain the standby state is made to the boot orchestrator.
Phelan et al teach the following limitations:
entering a standby state after performing a pre-boot process (Fig 7; 710 is in a hold state; [0060] mentions that 710 pause and wait for the user preferences at administrative system 720; thus 710 enters standby state after configuration data is received from 720), wherein a request to maintain the standby state is transmitted periodically to a boot orchestrator (boot orchestrator is 720; 710 made the request to 720 Fig 7; [0061] mentions that 710 waits again by transferring a second PXE request; thus, second PXE request is a request to maintain the standby state; the request to maintain the standby state is transmitted periodically until approval is received).
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 Kim, Subbaiah and Phelan et al to transmit a request to maintain the standby state periodically to a boot orchestrator, since that provides a chance to install with repeated user verification. Subbaiah provides the option for confirmation, but the option is not periodic. With the teachings from Phelan, Kim in view of Subbaiah will provide repeated verification and keep the system in standby state until the confirmation is received. That way, system can install the operating system with confirmed user verification.
For claim 9, Kim Young teaches wherein performing the pre-boot process comprises initializing and testing hardware of the computing device (Fig 2 step 1 through step 6 includes setting IP of the client host 200, requires initializing of testing hardware; [0057]) .
For claim 10, Kim Young teaches wherein performing the pre-boot process comprises initializing the OS installer ([0057] and [0065]; management host initializes OS installer for sending that to client host).
For claim 11, Kim Young or Subbaiah does not explicitly mention requesting OS configuration information for installing the operating system during standby state. Kim Young mentions about checks to determine whether new operating system is backward compatible with active configuration of the device ([0010]). Thus, the user can check and determine the backward compatibility with the OS configuration. Phelan teaches requesting configuration information for installing OS during standby state (Fig 7; PXE response includes configuration; thus PXE request represents both standby state maintain request and configuration request; [0060] mention installing OS).
For claim 12, Kim Young and Subbaiah teaches wherein receiving the activation instruction comprises receiving a configuration file describing information used by the OS installer to install the operating system ([0050] Kim – rebooting process to install the OS; [0058] Subbaiah – storing information with failed attempt).
For claim 13, Subbaiah teaches wherein the activation instruction is received from a boot orchestrator (step 510-520 of Fig 5 [0016] received from another device) configured to maintain the computing device in the standby state (step 520 and 530 of Fig 5) while waiting to activate the computing device in response to a resource request generated by the computing device (user confirmation request through user interface; [0013]).
For claim 14, Kim Young teaches wherein the computing device powers on or reboots in response to a power-on command or reboot command received from the boot orchestrator ([0046] [0007][0023] mention power on process). This must happen before any resource request.
For claim 15, Kim Young teaches the following limitations: A non-transitory computer-readable storage medium including instructions that, when executed by a processing device, cause the processing device to (page 1, title of the invention and [0001]-[0003]): perform a pre-boot process (Fig 1 shows the PXE boot 21) in response to powering on or rebooting a computing device ([0007] [0046] client host 20 is powered on; client host 20 in Fig 1 and client host 200 in Fig 2 is the computing device),wherein to perform a pre-boot process comprising loading an Operating System (OS) installer into storage of the computing device ([0028]; management host completes connection with client host and kernel image and kickstart configuration file may be transmitted to the client host to install the OS) and executing the OS installer ([0021][0029] – process of installing the OS through kickstart setting file); enter, by a processing device ([0047] [0055] [0056] [0058] [0062] mention about standby mode entry in step 203 of Fig 3; the standby state is where client is not assigned IP [0056]) during performing the pre-boot process ([0046] [0053]-[0054] is the pre-boot process; [0055]-[0056] describes the standby mode entry in step 203 of Fig 3); and in response to receiving an activation instruction ([0057]-[0058] the manager host determines that the installation is required, go back to installation control step (i.e., standby state waiting loop is over) to allow allocating IP to client host – that is the activation), exit the standby state ([0064][0065][0028] IP allocation to client host is performed; thus exiting the standby mode) and install an operating system of the computing device ([0065]).
Kim Young does not explicitly mention that the processing device executes the OS installer during entry of the standby mode. In other words, Kim Yung teaches standby or waiting during pre-booting state before downloading the installer.
Subbaiah teaches the following limitations: entering, by a processing device executing the OS installer, a standby state (Fig 1 and Fig 5; step 530 of Fig 5 mentions about the waiting loop or standby state that is entered through execution of the installer “option”; [0012]-[0013] the device receives an option to wait for confirmation; according to application’s specification [0014], standby state is the waiting state; “option” is to enable a user interface for a confirmed timeout).
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 Kim and Subbaiah to provide the installer to the network device and put the network device into the standby state when device is executing the installer (as taught in Subbaiah). Kim’s system is to allow the management host to put the device into standby mode before sending the various installation files ([0065] of Kim). However, Kim’s system can be modified to place the system into standby state after providing the installer into the device as taught in Subbaiah Fig 1 and Fig 5; [0051]-[0052] so as to confirm the installation. In such a case, pre-boot process comprises the steps till loading the installer (i.e., before the enablement of standby state) and entry into standby state is after the pre-boot process. That way user has more control over the system. When system is placed into standby mode for user confirmation, it ensures that user affirmation is required for any installation. This provides a flexible and well-maintained system.
Kim in view of Subbaiah does not explicitly mention a request to maintain the standby state is transmitted periodically to a boot orchestrator. In Subbaiah, the roll back or installation is performed after timed out ([0013]). Thus, it appears that no further request to maintain the standby state is made to the boot orchestrator.
Phelan et al teach the following limitations:
entering a standby state after performing a pre-boot process (Fig 7; 710 is in a hold state; [0060] mentions that 710 pause and wait for the user preferences at administrative system 720; thus 710 enters standby state after configuration data is received from 720), wherein a request to maintain the standby state is transmitted periodically to a boot orchestrator (boot orchestrator is 720; 710 made the request to 720 Fig 7; [0061] mentions that 710 waits again by transferring a second PXE request; thus, second PXE request is a request to maintain the standby state; the request to maintain the standby state is transmitted periodically until approval is received).
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 Kim, Subbaiah and Phelan et al to transmit a request to maintain the standby state periodically to a boot orchestrator, since that provides a chance to install with repeated user verification. Subbaiah provides the option for confirmation, but the option is not periodic. With the teachings from Phelan, Kim in view of Subbaiah will provide repeated verification and keep the system in standby state until the confirmation is received. That way, system can install the operating system with confirmed user verification.
For claim 16, Kim Young teaches wherein performing the pre-boot process comprises initializing and testing hardware of the computing device (Fig 2 step 1 through step 6 includes setting IP of the client host 200, requires initializing of testing hardware; [0057]) .
For claim 17, Kim Young teaches wherein performing the pre-boot process comprises initializing the OS installer ([0057] and [0065]; management host initializes OS installer for sending that to client host).
For claim 18, Kim Young or Subbaiah does not explicitly mention requesting OS configuration information for installing the operating system during standby state. Kim Young mentions about checks to determine whether new operating system is backward compatible with active configuration of the device ([0010]). Thus, the user can check and determine the backward compatibility with the OS configuration. Phelan teaches requesting configuration information for installing OS during standby state (Fig 7; PXE response includes configuration; thus PXE request represents both standby state maintain request and configuration request; [0060] mention installing OS).
For claim 19, Kim Young and Subbaiah teaches wherein receiving the activation instruction comprises receiving a configuration file describing information used by the OS installer to install the operating system ([0050] Kim – rebooting process to install the OS; [0058] Subbaiah – storing information with failed attempt).
For claim 20, Kim Young teaches wherein the computing device powers on or reboots in response to a power-on command or reboot command received from the boot orchestrator ([0046] [0007][0023] mention power on process). This must happen before any resource request. Subbaiah teaches wherein the activation instruction is received from a boot orchestrator (step 510-520 of Fig 5 [0016] received from another device) configured to maintain the computing device in the standby state (step 520 and 530 of Fig 5) while waiting to activate the computing device in response to a resource request generated by the computing device (user confirmation through user interface; [0013]). Thus, the combination provides the sufficient teachings for the claim limitations.
Response to Arguments
Applicant’s arguments have been considered but are moot because of the new ground of rejection. However, Subbaiah is relied upon for rejection and Examiner is addressing arguments regarding Subbaiah.
Applicant argues that Subbaiah does not teach entering the standby state.
Examiner disagrees. Subbaiah teaches entering the waiting loop (Fig 5 step 520 and 530). According to Applicant’s disclosure, standby state is the waiting state. The applicant’s disclosure [0014] mentions
[0014] During the standby state, the OS installer enters a waiting loop and waits for a command from the boot orchestrator to continue with the OS installation. When a user or other computer system requests OS installation, the boot orchestrator returns an installation configuration to the computing device and the OS installation process begins and continues normally.
Therefore, Subbaiah’s waiting loop to wait for a command to continue installation is the standby state according to applicant’s specification.
The newly cited reference Phelan teaches maintaining the waiting state (or standby state) by transmitting periodic request to the boot orchestrator as explained above.
Examiner suggested allowable subject matter:
Examiner is suggesting the following limitations as the allowable subject matter for independent claims 8 and 15 (i.e., appending the suggested limitations to claims 8 and 15; claim 1 should recite the conditional limitations positively so that BRI includes the limitations):
wherein the computing device transmits the request to the boot orchestrator and wherein computing device powers on or reboots in response to a power-on command or reboot command and wherein the activation instruction and the power-on command or reboot command are received from the boot orchestrator configured to power on or reboot the computing device and maintain the computing device in the standby state while waiting to activate the computing device in response to a resource request generated by the computing device, wherein the resource request is generated according to an increased workload demand and is received by the boot orchestrator.
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, Kim Huynh can be reached at 571-272-4147. 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