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 6/11/26.
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 Objections
Claims 8-14 are objected to because of the following informalities: Claim 8 recites “the process device” in line 7, which should be changed to –the processing device—according to line 3.
Claims 9-14 depend on claim 8 and incorporate the informalities by virtue of dependency.
Appropriate correction is required.
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-5, 8, 10-12, 15, 17-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Phelan et al (US Patent Application Publication 2015/0220348) in view of Ohashi (US Patent Application Publication 2014/0137245).
For claim 1, Phelan et al teach the following limitations: A method comprising: in response to powering on or rebooting a computing device (discrete machine shown in Fig 3, Fig 5 – Fig 8; [0021]-[0026] – PXE provides booting environment, thus the machine is powered on and rebooted) performing a pre-boot process (sending PXE request to 520 and receiving PXE response with boot configuration data from 520 shown in Fig 5) comprising loading an Operating System (OS) installer into storage of the computing device ([0073] – configuration data is transferred to initiated computing devices; data is stored in memory; boot configuration data includes files and other necessary elements to be installed [0023]; [0035][0060][0065] – boot configuration data includes OS to be installed; [0068]; thus, the boot configuration data sent to the new discrete machine 510 includes the OS installer files) and executing the OS installer ([0060] – pause the installation process; [0054][0055]); entering, by a processing device executing the OS installer, a standby state after performing the 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; [0054] – hold the installation; [0060] – pause the installation to wait; thus after performing the PXE, the installer enters a waiting state or standby state; applicant’s disclosure [0014], standby state is the waiting state), wherein the OS installer receives a command to enter the standby state from a boot orchestrator ([0053] and [0060] – discrete machine will pause/hold the installation process; thus the discrete machine, acting as a boot orchestrator, provides the command to the OS installer to enter the standby state); and in response to receiving an activation instruction (boot command shown in Fig 5; [0055][0060]), exiting the standby state and installing an operating system of the computing device ([0054]-[0055][0057][0060] – the boot command authorizes OS installation).
For the limitations “OS installer receives a command to enter the standby state from a boot orchestrator”, Phelan et al teach “discrete machine 710 pause the installation process” in [0060]. Claim does not require boot orchestrator to be a separate element. Therefore, Phelan sufficiently teaches the limitations. Ohashi teaches the separate orchestrator that communicates with the installer. Ohashi teaches the following:
an installer (Fig 2, installer 23) receives a command to enter the standby state from a boot orchestrator (10 in Fig 2 is the boot orchestrator, 10 is access control module, modules can be implemented in hardware and/or software [0092]; [0045] mentions that 101 causes the installation module 23 to suspend the execution of installation processing) and in response to receiving an activation instruction, exiting the standby state ([0048] – with the permission of installation, 101 executes installation processing in cooperation with 23).
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to have an orchestrator module that works with the installer to provide suspension command. In Phelan, the device is configured to provide the command ([0060] – discrete machine pause). However, Ohashi provides the implementation of installer and the controller clearly in Fig 2 to suspend the installation process. With the implementation shown in Ohashi, Phelan will be able to implement the standby command by the orchestrator. This simplified implementation provides simplicity and modularity in the system.
For claim 3, Phelan teaches wherein performing the pre-boot process comprises initializing the OS installer (PXE response shown in Fig 5 [0054][0059][0060] – PXE response comprises boot configuration data including necessary files for installation; installation process is paused; thus the pre-boot initializes the installer).
For claim 4, Phelan teaches during the standby state, requesting OS configuration information for installing the operating system ([0054][0055] – 520 gathers preferences from a user; thus, user is requested to provide the configuration information; [0064]).
For claim 5, Phelan teaches wherein receiving the activation instruction comprises receiving a configuration file describing information used by the OS installer to install the operating system ([0054][0055][0064] – boot command is based on the user preferences and thus, includes further information).
For claim 8, Phelan teaches A computing device (discrete machine shown in Fig 3, Fig 5 – Fig 8; [0028]) comprising: a memory; and a processing device, operatively coupled to the memory ([0028]), the processing device to: perform a pre-boot process in response to power on or reboot of the computing device ([0021]-[0026] – PXE provides booting environment, thus the machine is powered on and rebooted, sending PXE request to 520 and receiving PXE response with boot configuration data from 520 shown in Fig 5) wherein to perform the pre-boot process comprises to load an Operating System (OS) installer into storage of the computing device ([0073] – configuration data is transferred to initiated computing devices; data is stored in memory; boot configuration data includes files and other necessary elements to be installed [0023]; [0035][0060][0065] – boot configuration data includes OS to be installed; [0068]; thus, the boot configuration data sent to the new discrete machine 510 includes the OS installer files) and execute the OS installer ([0060] – pause the installation process; [0054][0055]); enter, by the process device executing the OS installer, a standby state after performance of the 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; [0054] – hold the installation; [0060] – pause the installation to wait; thus after performing the PXE, the installer enters a waiting state or standby state; applicant’s disclosure [0014], standby state is the waiting state), wherein the OS installer receives a command to enter the standby state transmitted from a boot orchestrator ([0053] and [0060] – discrete machine will pause/hold the installation process; thus the discrete machine, acting as a boot orchestrator, provides the command to the OS installer to enter the standby state); and in response to receiving an activation instruction (boot command shown in Fig 5; [0055][0060]), exit the standby state and install an operating system of the computing device ([0054]-[0055][0057][0060] – the boot command authorizes OS installation).
For the limitations “OS installer receives a command to enter the standby state from a boot orchestrator”, Phelan et al teach “discrete machine 710 pause the installation process” in [0060]. Claim does not require boot orchestrator to be a separate element. Therefore, Phelan sufficiently teaches the limitations. Ohashi teaches the separate orchestrator that communicates with the installer. Ohashi teaches the following:
an installer (Fig 2, installer 23) receives a command to enter the standby state from a boot orchestrator (10 in Fig 2 is the boot orchestrator, 10 is access control module, modules can be implemented in hardware and/or software [0092]; [0045] mentions that 101 causes the installation module 23 to suspend the execution of installation processing) and in response to receiving an activation instruction, exiting the standby state ([0048] – with the permission of installation, 101 executes installation processing in cooperation with 23).
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to have an orchestrator module that works with the installer to provide suspension command. In Phelan, the device is configured to provide the command ([0060] – discrete machine pause). However, Ohashi provides the implementation of installer and the controller clearly in Fig 2 to suspend the installation process. With the implementation shown in Ohashi, Phelan will be able to implement the standby command by the orchestrator. This simplified implementation provides simplicity and modularity in the system.
For claim 10, Phelan teaches wherein to perform the pre-boot process comprises initializing the OS installer (PXE response shown in Fig 5 [0054][0059][0060] – PXE response comprises boot configuration data including necessary files for installation; installation process is paused; thus the pre-boot initializes the installer).
For claim 11, Phelan teaches during the standby state, requesting OS configuration information for installing the operating system ([0054][0055] – 520 gathers preferences from a user; thus, user is requested to provide the configuration information; [0064]).
For claim 12, Phelan teaches wherein receive the activation instruction comprises receiving a configuration file describing information used by the OS installer to install the operating system ([0054][0055][0064] – boot command is based on the user preferences and thus, includes further information).
For claim 15, Phelan 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 ([0006]): perform a pre-boot process in response to power on or reboot of the computing device ([0021]-[0026] – PXE provides booting environment, thus the machine is powered on and rebooted, sending PXE request to 520 and receiving PXE response with boot configuration data from 520 shown in Fig 5) wherein to perform the pre-boot process comprises to load an Operating System (OS) installer into storage of the computing device ([0073] – configuration data is transferred to initiated computing devices; data is stored in memory; boot configuration data includes files and other necessary elements to be installed [0023]; [0035][0060][0065] – boot configuration data includes OS to be installed; [0068]; thus, the boot configuration data sent to the new discrete machine 510 includes the OS installer files) and execute the OS installer ([0060] – pause the installation process; [0054][0055]); enter, by the process device executing the OS installer, a standby state after performance of the 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; [0054] – hold the installation; [0060] – pause the installation to wait; thus after performing the PXE, the installer enters a waiting state or standby state; applicant’s disclosure [0014], standby state is the waiting state), wherein the OS installer receives a command to enter the standby state transmitted from a boot orchestrator ([0053] and [0060] – discrete machine will pause/hold the installation process; thus the discrete machine, acting as a boot orchestrator, provides the command to the OS installer to enter the standby state); and in response to receiving an activation instruction (boot command shown in Fig 5; [0055][0060]), exit the standby state and install an operating system of the computing device ([0054]-[0055][0057][0060] – the boot command authorizes OS installation).
For the limitations “OS installer receives a command to enter the standby state from a boot orchestrator”, Phelan et al teach “discrete machine 710 pause the installation process” in [0060]. Claim does not require boot orchestrator to be a separate element. Therefore, Phelan sufficiently teaches the limitations. Ohashi teaches the separate orchestrator that communicates with the installer. Ohashi teaches the following:
an installer (Fig 2, installer 23) receives a command to enter the standby state from a boot orchestrator (10 in Fig 2 is the boot orchestrator, 10 is access control module, modules can be implemented in hardware and/or software [0092]; [0045] mentions that 101 causes the installation module 23 to suspend the execution of installation processing) and in response to receiving an activation instruction, exiting the standby state ([0048] – with the permission of installation, 101 executes installation processing in cooperation with 23).
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to have an orchestrator module that works with the installer to provide suspension command. In Phelan, the device is configured to provide the command ([0060] – discrete machine pause). However, Ohashi provides the implementation of installer and the controller clearly in Fig 2 to suspend the installation process. With the implementation shown in Ohashi, Phelan will be able to implement the standby command by the orchestrator. This simplified implementation provides simplicity and modularity in the system.
For claim 17, Phelan teaches wherein to perform the pre-boot process comprises initializing the OS installer (PXE response shown in Fig 5 [0054][0059][0060] – PXE response comprises boot configuration data including necessary files for installation; installation process is paused; thus the pre-boot initializes the installer).
For claim 18, Phelan teaches during the standby state, requesting OS configuration information for installing the operating system ([0054][0055] – 520 gathers preferences from a user; thus, user is requested to provide the configuration information; [0064]).
For claim 19, Phelan teaches wherein receive the activation instruction comprises receiving a configuration file that describes information used by the OS installer to install the operating system ([0054][0055][0064] – boot command is based on the user preferences and thus, includes further information).
Claim(s) 2, 9 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Phelan et al (US Patent Application Publication 2015/0220348) in view of Ohashi (US Patent Application Publication 2014/0137245), further in view of Hsu et al (US Patent Application Publication 20200278873).
For claims 2, 9, and 16, Phelan teaches wherein performing the pre-boot process comprises initializing ([0022] – DHCP server is contacted). Phelan does not mention testing hardware of the computing device. However, testing is performed when a device is powered on ([0038] Hsu POST). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to perform the POST operation before booting, since this ensures correctness of hardware.
Claim(s) 6, 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Phelan et al (US Patent Application Publication 2015/0220348) in view of Ohashi (US Patent Application Publication 2014/0137245), further in view of Sato (US Patent Application Publication 20160231971).
For claims 6 and 13, wherein the activation instruction is received from the boot orchestrator configured to maintain the computing device in the standby state while waiting to activate the computing device (Phelan as modified by Ohashi has the boot orchestrator (10 shown in Ohashi) that maintains the device in standby state while waiting to activate the computing device ([0046]-[0048] Ohashi and [0054][0060] in Phelan)). Phelan in view of Ohashi does not explicitly mention in response to a resource request generated by the computing device. Sato teaches waiting to activate the computing device in response to a resource request generated by the computing device ([0108][0120][0151]Fig 8B mention that the installation process is suspended for performing manual settings and operations; Fig 9 904 mentions the suspend command for manual operation; the request for manual operation is a resource request generated by the 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 Phelan, Ohashi and Sato to keep the device in standby state while waiting to activate the device in response to a resource request generated by the device, since the device might need to perform additional processing for the installation (as disclosed in Sato) and wait in the standby state for performing the additional processing corresponding to the resource request. That way installation can be accurately performed.
Claim(s) 7, 14, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Phelan et al (US Patent Application Publication 2015/0220348) in view of Ohashi (US Patent Application Publication 2014/0137245), further in view of Sato (US Patent Application Publication 20160231971), further in view of Shu (US Patent Application Publication 2024/0192964).
For claims 7 and 14, Phelan teaches wherein the computing device powers on or reboots in response to a power-on command or reboot command ([0056] – discrete machine initiated) prior to receiving the resource request (the powering on is the first step before any other step [0056]Fig 2). Phelan in view of Ohashi in view of Sato does not explicitly mention power on or reboot command is received from boot orchestrator. However, claim does not require orchestrator to be separate from the device. For further clarification, Examiner cites Shu et al that teaches receiving powering on command from a remote entity ([0108] Fig 3 [0101] server 20 issues command to turn on node 30). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to provide power command from the orchestrator, since that way the device can be controlled remotely for powering. This eases user operation.
For claim 20, Phelan teaches wherein the computing device powers on or reboots in response to a power-on command or reboot command ([0056] – discrete machine initiated). Phelan in view of Ohashi further mentions wherein the activation instruction is received from the boot orchestrator configured to maintain the computing device in the standby state while waiting to activate the computing device (Phelan as modified by Ohashi has the boot orchestrator (10 shown in Ohashi) that maintains the device in standby state while waiting to activate the computing device ([0046]-[0048] Ohashi and [0054][0060] in Phelan)). Phelan in view of Ohashi does not explicitly mention power on or reboot command is received from boot orchestrator and waiting to activate in response to a resource request generated by the computing device. Sato teaches waiting to activate the computing device in response to a resource request generated by the computing device ([0108][0120][0151]Fig 8B mention that the installation process is suspended for performing manual settings and operations; Fig 9 904 mentions the suspend command for manual operation; the request for manual operation is a resource request generated by the 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 Phelan, Ohashi and Sato to keep the device in standby state while waiting to activate the device in response to a resource request generated by the device, since the device might need to perform additional processing for the installation (as disclosed in Sato) and wait in the standby state for performing the additional processing corresponding to the resource request. That way installation can be accurately performed.
Phelan in view of Ohashi in view of Sato does not explicitly mention power on or reboot command is received from boot orchestrator. However, claim does not require orchestrator to be separate from the device. For further clarification, Examiner cites Shu et al that teaches receiving powering on command from a remote entity ([0108] Fig 3 [0101] server 20 issues command to turn on node 30). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to provide power command from the orchestrator, since that way the device can be controlled remotely for powering. This eases user operation.
Response to Arguments
Applicant’s arguments have been considered but are moot because of the new ground of rejection. However, Phelan is relied upon for rejection and Examiner is addressing arguments regarding Phelan.
Applicant argues that Phelan does not teach receiving a command to enter the standby state transmitted from a boot orchestrator.
Examiner disagrees. Applicant agreed that Phelan’s discrete machine pauses upon receiving the configuration data but disagrees that the discrete machine receives any command to enter the standby state transmitted from a boot orchestrator. In response, Examiner cites [0060] Phelan, which mentions “discrete machine will then pause the installation process” and therefore, the command to enter the standby state is received as “pausing a process” requires receiving an instruction from the machine. However, Phelan does not fully disclose the circuitries of installer and the boot orchestrator. Examiner cites new reference Ohashi that clearly teaches the installer and the orchestrator separately in Fig 2 (10 and 23 in Fig 2).
Conclusion
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