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-20 are presented for examination.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Bailey (US 6,963,981 B1) in view of Marinelli (US 2012/0042195 A1), further in view of Glaum (US 7,549,042 B2), and further in view of Karaginides et al. (US 2017/0308705 A1).
Regarding Claim 1, Bailey teaches
A computer implemented method, the method comprising:
sending a first data package from a central computing entity to a local computing entity, the first data package comprising first instructions comprising ... (2) partition instructions (Col. 8, ln. 8-21, "the bundles are transmitted to locations available to servers connected to the public Internet. More particularly, these bundles may be placed on an Internet World Wide Web server, or a stage server... a command is executed remotely, via a secure IP communications channel between the installer's computer and the target machine(s), to retrieve the installation bundles via HTTP from the stage-server."; Col. 12, ln. 50-58, "the network deployment routine then repartitions the second disk on the target machine, installs the LSI distribution there, and copies the Windows 2000 install tarball to the second disk.") Examiner Comments: Bailey's staging server corresponds to the central computing entity, the target machine corresponds to the local computing entity, and the installation bundles containing repartitioning commands correspond to a first data package with partition instructions.
divide a memory of the local computing entity into a first partition and a second partition separated by a logical partition boundary (Col. 2, ln. 19-45, "the copy of the source operating system may be stored in a first partition of the second bootable region of the storage, and the target operating system may be stored in a second partition of the second bootable region.") Examiner Comments: Bailey divides the target machine's storage into a first partition and a second partition, and the boundary separating the two partitions is a logical partition boundary.
move an existing operating system instruction set and user data comprising at least one of client diagnostic test results or client profile data to the first partition of the memory to isolate and maintain the user data locally on the local computing entity during a software update (Col. 8, ln. 32-36, "the parameters and settings of the computing device are recorded. These settings can include the network configuration of the target machine, including the IP networking settings, and security settings used to control access to the machine via the secure channel.") Examiner Comments: Bailey records and preserves the existing parameters, settings, and configuration of the target machine on the machine itself before installing the new operating system, which maintains the user data locally on the local computing entity during the update, and the recited data types (client diagnostic test results or client profile data) name the content of the user data without altering the recited step.
subsequent to receiving the confirmation signal, sending to the local computing entity a second data package comprising second instructions executable to install a second operating system instruction set on the local computing entity (Col. 12, ln. 50-60, "the deployment routine repartitions disk one, creating a FAT file system that will be used to host the Windows 2000 installation. The Windows 2000 OS tarball is unpacked onto this partition.") Examiner Comments: Bailey performs a staged deployment in which the repartitioning and base installation occur first and the target operating system distribution is delivered and installed in a subsequent stage, corresponding to sending the second data package after the first stage completes.
Bailey did not specifically teach
(1) software dependency check instructions ... determine software runtime dependencies of the local computing entity;
receiving a confirmation signal at the central computing entity indicative of the software runtime dependencies of the local computing entity and that the local computing entity comprises the first partition and the second partition in the memory;
monitoring, at the central computing entity, progress of installation of the second operating system instruction set on the local computing entity by passively receiving a live stream of telemetry messages over a network connection, wherein an application executing locally on the local computing entity remains an authoritative processor for determining failure recovery handling.
However, Marinelli teaches
receiving a confirmation signal at the central computing entity indicative of ... the local computing entity and that the local computing entity comprises the first partition and the second partition in the memory (Para. [0052], "the pre-OS kernel performs a hardware discovery process and sends the inventory data obtained from that process back to the operating system deployment server."; Para. [0057]-[0058], "The pre-OS kernel sends (block 500) inventory information discovered during hardware capturing to the operating system deployment server for storage. The inventory information is then received (block 502) by the server and stored thereon in the inventory information repository (e.g. 333, FIG. 3).") Examiner Comments: The target machine sends inventory information to the server, which receives and stores it and proceeds only thereafter, corresponding to a confirmation signal received at the central computing entity indicative of the state of the local computing entity.
monitoring, at the central computing entity, progress of installation of the second operating system instruction set on the local computing entity by passively receiving a live stream of telemetry messages over a network connection (Para. [0047], "the operating system deployment server (310) may be signaled and informed of the ongoing state of the operating system deployment procedure. The server (310) may also be configured to receive a notification related to the result of each phase of the operating system deployment procedure (success notification, failure notification or other type of indicators)."; Para. [0058]-[0059], "In parallel, the server waits (block 506) for a predefined amount of time until the target machine is notified test completion. When the pre-OS kernel notifies (block 506) the server of test completion, the server resets (block 507) the start test time and checks (block 508) the test results.") Examiner Comments: Marinelli's server is informed of the ongoing state of the deployment and receives a notification of the result of each phase, which corresponds to the central computing entity passively receiving a live stream of telemetry messages indicative of installation progress.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bailey with the teaching of Marinelli in order to provide administrators with automatic detection of deployment failures and the ability to take remediation actions, which is a well-recognized need when deploying operating systems to remote machines that cannot be physically accessed. Both Bailey and Marinelli are directed to remote operating system deployment from a central server to target machines, and the combination represents the use of a known technique (progress and inventory reporting taught by Marinelli) to improve a similar device (the remote deployment system of Bailey) in the same way, yielding a predictable result.
Bailey and Marinelli did not specifically teach
the first instructions comprising (1) software dependency check instructions ... determine software runtime dependencies of the local computing entity.
However, Glaum teaches
first instructions comprising (1) software dependency check instructions ... cause the processor to: determine software runtime dependencies of the local computing entity (Col. 15, ln 45-64, "Still other verification includes verifying that necessary package dependencies are satisfied. For example, if version 2.0 of package A depends on the contents of version 3.0 of package B, verification checks that the latter package already installed or is it queued and validated for install."… "Validation also verifies that the necessary versions of packages are either already installed on the system or are queued for install.") Examiner Comments: Glaum verifies, before an update is applied, that the software package dependencies of the device are satisfied by checking that required software versions and dependent packages are already installed or queued, which corresponds to software dependency check instructions that determine software runtime dependencies of the local computing entity.
It would further have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the software package dependency verification of Glaum into the remote deployment system of Bailey and Marinelli, in order to reduce failure occurrence during deployment by confirming, before an update is applied, that the software dependencies of the target are satisfied, which Glaum identifies as a means of preventing failed or partial installations. Combining Glaum's dependency verification with the deployment system of Bailey and Marinelli is the combination of prior art elements according to known methods to yield the predictable result of a deployment gated on satisfied software dependencies.
Bailey, Marinelli, and Glaum did not specifically teach
wherein an application executing locally on the local computing entity remains an authoritative processor for determining failure recovery handling.
However, Karaginides teaches
wherein an application executing locally on the local computing entity remains an authoritative processor for determining failure recovery handling (Para 0056, "The monitoring algorithm(s) determine if the processing device operational parameters pass for the trial image (e.g., no software/application crashes, driver incompatibilities, etc.)." …"In this example, if there is a failure of processing device operational parameters, the process reboots to the previous current version of the image.") Examiner Comments: Karaginides teaches that monitoring algorithms resident in the device code evaluate the trial image at the endpoint and, upon a failure of operational parameters, the device autonomously reboots to the previous image without server intervention, which corresponds to an application executing locally on the local computing entity remaining the authoritative processor for determining failure recovery handling.
It would further have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the trial-image local monitoring and autonomous rollback of Karaginides into the remote deployment system of Bailey, Marinelli, and Glaum in order to guarantee that recovery from a faulty update proceeds at the endpoint device even when outbound communications to the central server are unavailable, thereby improving update reliability. Applying Karaginides' endpoint-resident monitoring and rollback to the deployment system of Bailey, Marinelli, and Glaum is the use of a known technique to improve a similar deployment method in the same way, yielding the predictable result of an endpoint that remains authoritative for failure recovery while the central entity passively receives progress messages.
Regarding Claim 2, Bailey, Marinelli, Glaum, and Karaginides teach
The method of Claim 1.
Marinelli further teaches
wherein said monitoring of the progress of the installation of the second operating system instruction set on the local computing entity comprises: during the installation, receiving from the local computing entity at the central computing entity the telemetry messages indicative of progress of the installation (Para. [0047], "the operating system deployment server (310) may be signaled and informed of the ongoing state of the operating system deployment procedure. The server (310) may also be configured to receive a notification related to the result of each phase of the operating system deployment procedure (success notification, failure notification or other type of indicators).") Examiner Comments: Marinelli teaches the target machine sending progress notifications to the server during each phase of deployment, corresponding to receiving the telemetry messages indicative of installation progress.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bailey with the teaching of Marinelli in order to provide administrators with automatic detection of deployment failures and the ability to take remediation actions, which is a well-recognized need when deploying operating systems to remote machines that cannot be physically accessed. Both Bailey and Marinelli are directed to remote operating system deployment from a central server to target machines, and the combination represents the use of a known technique (progress and inventory reporting taught by Marinelli) to improve a similar device (the remote deployment system of Bailey) in the same way, yielding a predictable result.
Regarding Claim 3, Bailey, Marinelli, Glaum, and Karaginides teach
The method of Claim 2.
Bailey and Marinelli further teach
wherein based on receiving from the local computing entity at the central computing entity a failure message: sending a recovery instruction package from the central computing entity to the local computing entity executable by the local computing entity to return the local computing entity back to the existing operating system instruction set (Bailey, Col. 5, ln. 55-67, "If, for any reason, the operating system C is corrupted, or if the operator wishes to change the operating system C to another operating system, they may do so in a reasonable fashion... the media configured for running operating system B is designated as the boot device."; Marinelli, Para. [0029], "the error handling module automatically manages failure notifications (target and server originated) using inventory information") Examiner Comments: Bailey preserves the prior operating system on a separate bootable device enabling reversion, and Marinelli teaches automatic failure detection with remediation actions from the server, so the combination teaches sending recovery instructions upon a failure message to return to the existing operating system.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bailey with the teaching of Marinelli in order to provide administrators with automatic detection of deployment failures and the ability to take remediation actions, which is a well-recognized need when deploying operating systems to remote machines that cannot be physically accessed. Both Bailey and Marinelli are directed to remote operating system deployment from a central server to target machines, and the combination represents the use of a known technique (progress and inventory reporting taught by Marinelli) to improve a similar device (the remote deployment system of Bailey) in the same way, yielding a predictable result.
Regarding Claim 4, Bailey, Marinelli, Glaum, and Karaginides teach
The method of Claim 2.
Marinelli further teaches
wherein based on receiving from the local computing entity at the central computing entity a process execution delay message: sending a restart signal from the central computing entity to the local computing entity to restart the installation (Marinelli, Para. [0016], "These hangs can be addressed by the server detecting out-of-band communication in the network cards to force a reboot. This can allow for the automatic recovery of the operating system deployment flow.") Examiner Comments: Marinelli teaches that when a hang (process execution delay) is detected, the server forces a reboot of the target to restart the deployment flow, corresponding to sending a restart signal upon a process execution delay message.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bailey with the teaching of Marinelli in order to provide administrators with automatic detection of deployment failures and the ability to take remediation actions, which is a well-recognized need when deploying operating systems to remote machines that cannot be physically accessed. Both Bailey and Marinelli are directed to remote operating system deployment from a central server to target machines, and the combination represents the use of a known technique (progress and inventory reporting taught by Marinelli) to improve a similar device (the remote deployment system of Bailey) in the same way, yielding a predictable result.
Regarding Claim 5, Bailey, Marinelli, Glaum, and Karaginides teach
The method of Claim 2.
Marinelli further teaches
wherein in response to not receiving the telemetry messages from the local computing entity at the central computing entity within a configurable time period, sending a restart signal from the central computing entity to the local computing entity to restart the installation of the second operating (Para. [0058]-[0059], "In parallel, the server waits (block 506) for a predefined amount of time until the target machine is notified test completion. When the pre-OS kernel notifies (block 506) the server of test completion, the server resets (block 507) the start test time and checks (block 508) the test results."; Para. [0016], "These hangs can be addressed by the server detecting out-of-band communication in the network cards to force a reboot.") Examiner Comments: Marinelli teaches the server waiting a predefined (configurable) time period for responses from the target and forcing a reboot when the target fails to respond, corresponding to sending a restart signal when the telemetry messages are not received within a configurable time period.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bailey with the teaching of Marinelli in order to provide administrators with automatic detection of deployment failures and the ability to take remediation actions, which is a well-recognized need when deploying operating systems to remote machines that cannot be physically accessed. Both Bailey and Marinelli are directed to remote operating system deployment from a central server to target machines, and the combination represents the use of a known technique (progress and inventory reporting taught by Marinelli) to improve a similar device (the remote deployment system of Bailey) in the same way, yielding a predictable result.
Regarding Claim 6, Bailey, Marinelli, Glaum, and Karaginides teach
The method of Claim 1.
Bailey and Marinelli further teach
wherein the second instructions of the second data package comprise (1) installation instructions and (2) the second operating system instruction set, wherein executing, by the processor of the local computing entity, the installation instructions causes installation of the second operating system instruction set on the local computing entity, wherein the confirmation signal is further indicative of a type of the local computing entity (Bailey, Col. 13, ln. 15-25, "Autoexec.bat then starts winnt.exe, with the /wautoinst.txt argument, instructing it to process an Answer File. Winnt.exe copies files from I386 into the staging directory.") Examiner Comments: Bailey's bundle contains both the operating system distribution files and the installer executable that causes the operating system to be installed.
and the method further comprises: selecting the installation instructions from a group of installation instructions based on the type of local computing entity, wherein the selected installation instructions comprise an application programming interface (API) for basic input/output system (BIOS) of the type of the local computing entity (Bailey, Col. 13, ln. 30-40, "the ComputerType option explicitly specifies the type of HAL to be used."; Marinelli, Para. [0049], "Such parameters may include Peripheral Component Interface (PCI) codes that can be used to identify the hardware machine when a failure is detected.") Examiner Comments: Bailey customizes the installation script based on the machine type (HAL selection) and Marinelli identifies the hardware type via PCI codes, so the combination teaches selecting installation instructions based on machine type where those instructions interface with the BIOS firmware.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bailey with the teaching of Marinelli in order to provide administrators with automatic detection of deployment failures and the ability to take remediation actions, which is a well-recognized need when deploying operating systems to remote machines that cannot be physically accessed. Both Bailey and Marinelli are directed to remote operating system deployment from a central server to target machines, and the combination represents the use of a known technique (progress and inventory reporting taught by Marinelli) to improve a similar device (the remote deployment system of Bailey) in the same way, yielding a predictable result.
Regarding Claim 7, Bailey teaches
A computer implemented method, the method comprising:
receiving at a local computing entity a first data package from a central computing entity, the first data package comprising first instructions comprising ... (2) partition instructions (Col. 8, ln. 8-21, "the bundles are transmitted to locations available to servers connected to the public Internet. More particularly, these bundles may be placed on an Internet World Wide Web server, or a stage server... a command is executed remotely, via a secure IP communications channel between the installer's computer and the target machine(s), to retrieve the installation bundles via HTTP from the stage-server."; Col. 12, ln. 50-58, "the network deployment routine then repartitions the second disk on the target machine, installs the LSI distribution there, and copies the Windows 2000 install tarball to the second disk.") Examiner Comments: Bailey's target machine receives installation bundles from the staging server that include repartitioning commands, corresponding to a first data package with partition instructions received at the local computing entity.
executing the first instructions by a processor of the local computing entity to: divide a memory of the local computing entity into a first partition and a second partition separated by a logical partition boundary (Col. 2, ln. 19-45, "the copy of the source operating system may be stored in a first partition of the second bootable region of the storage, and the target operating system may be stored in a second partition of the second bootable region.") Examiner Comments: Bailey divides the target machine's storage into a first partition and a second partition, the boundary between the two partitions being a logical partition boundary.
and move an existing operating system instruction set and user data comprising at least one of client diagnostic test results or client profile data to the first partition of the memory to isolate and maintain the user data locally on the local computing entity during a software update (Col. 8, ln. 32-36, "the parameters and settings of the computing device are recorded. These settings can include the network configuration of the target machine, including the IP networking settings, and security settings used to control access to the machine via the secure channel.") Examiner Comments: Bailey records and preserves the existing parameters, settings, and configuration of the target machine on the machine itself, maintaining the user data locally during the update, and the recited data types name the content of the user data without altering the recited step.
subsequent to sending the confirmation signal, receiving at the local computing entity a second data package comprising second instructions comprising (1) installation instructions and (2) a second operating system instruction set (Col. 12, ln. 50-60, "the deployment routine repartitions disk one, creating a FAT file system that will be used to host the Windows 2000 installation. The Windows 2000 OS tarball is unpacked onto this partition.") Examiner Comments: After the first stage completes, Bailey delivers and unpacks the target operating system distribution, corresponding to receiving the second data package subsequent to the confirmation signal.
executing, by the processor of the local computing entity, the installation instructions to cause installation of the second operating system instruction set on the local computing entity (Col. 13, ln. 15-25, "Autoexec.bat then starts winnt.exe, with the /wautoinst.txt argument, instructing it to process an Answer File. Winnt.exe copies files from I386 into the staging directory.") Examiner Comments: The target machine executes the installer with the answer file to install the second operating system.
Bailey did not specifically teach (1) software dependency check instructions ... determine software runtime dependencies of the local computing entity; sending a confirmation signal to the central computing entity indicative of the software runtime dependencies of the local computing entity and that the local computing entity comprises the first partition and the second partition in the memory; during the installation of the second operating system instruction set on the local computing entity, sending from the local computing entity to the central computing entity a live stream of telemetry messages indicative of progress of the installation, wherein an application executing locally on the local computing entity remains an authoritative processor for determining failure recovery handling.
However, Marinelli teaches
sending a confirmation signal to the central computing entity indicative of ... the local computing entity and that the local computing entity comprises the first partition and the second partition in the memory (Para. [0052], "the pre-OS kernel performs a hardware discovery process and sends the inventory data obtained from that process back to the operating system deployment server."; Para. [0057]-[0058], "The pre-OS kernel sends (block 500) inventory information discovered during hardware capturing to the operating system deployment server for storage. The inventory information is then received (block 502) by the server and stored thereon in the inventory information repository (e.g. 333, FIG. 3).") Examiner Comments: The target machine sends inventory information to the server, corresponding to sending a confirmation signal to the central computing entity indicative of the state of the local computing entity.
during the installation ..., sending from the local computing entity to the central computing entity a live stream of telemetry messages indicative of progress of the installation (Para. [0047], "the operating system deployment server (310) may be signaled and informed of the ongoing state of the operating system deployment procedure. The server (310) may also be configured to receive a notification related to the result of each phase of the operating system deployment procedure (success notification, failure notification or other type of indicators)."; Para. [0058]-[0059], "In parallel, the server waits (block 506) for a predefined amount of time until the target machine is notified test completion. When the pre-OS kernel notifies (block 506) the server of test completion, the server resets (block 507) the start test time and checks (block 508) the test results.") Examiner Comments: Marinelli's target sends phase-by-phase status notifications to the server during deployment, corresponding to sending a live stream of telemetry messages indicative of installation progress.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bailey with the teaching of Marinelli in order to provide administrators with automatic detection of deployment failures and the ability to take remediation actions, which is a well-recognized need when deploying operating systems to remote machines that cannot be physically accessed. Both Bailey and Marinelli are directed to remote operating system deployment from a central server to target machines, and the combination represents the use of a known technique (progress and inventory reporting taught by Marinelli) to improve a similar device (the remote deployment system of Bailey) in the same way, yielding a predictable result.
Bailey and Marinelli did not specifically teach the first instructions comprising (1) software dependency check instructions ... determine software runtime dependencies of the local computing entity.
However, Glaum teaches
first instructions comprising (1) software dependency check instructions ... executing the first instructions by a processor of the local computing entity to: determine software runtime dependencies of the local computing entity (Col. 15, ln 45-65, "Still other verification includes verifying that necessary package dependencies are satisfied. For example, if version 2.0 of package A depends on the contents of version 3.0 of package B, verification checks that the latter package already installed or is it queued and validated for install." Col. 15, ln 45-65 "Validation also verifies that the necessary versions of packages are either already installed on the system or are queued for install.") Examiner Comments: Glaum verifies that the software package dependencies of the device are satisfied by checking that required software versions and dependent packages are already installed or queued, corresponding to software dependency check instructions that determine software runtime dependencies.
It would further have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the software package dependency verification of Glaum into the remote deployment system of Bailey and Marinelli, in order to reduce failure occurrence during deployment by confirming, before an update is applied, that the software dependencies of the target are satisfied, which Glaum identifies as a means of preventing failed or partial installations. Combining Glaum's dependency verification with the deployment system of Bailey and Marinelli is the combination of prior art elements according to known methods to yield the predictable result of a deployment gated on satisfied software dependencies.
Bailey, Marinelli, and Glaum did not specifically teach wherein an application executing locally on the local computing entity remains an authoritative processor for determining failure recovery handling.
However, Karaginides teaches
wherein an application executing locally on the local computing entity remains an authoritative processor for determining failure recovery handling (Para 0056, "The monitoring algorithm(s) determine if the processing device operational parameters pass for the trial image (e.g., no software/application crashes, driver incompatibilities, etc.)."… "In this example, if there is a failure of processing device operational parameters, the process reboots to the previous current version of the image.") Examiner Comments: Karaginides teaches that monitoring algorithms resident in the device code evaluate the trial image at the endpoint and, upon a failure of operational parameters, the device autonomously reboots to the previous image without server intervention, corresponding to an application executing locally remaining the authoritative processor for failure recovery handling.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the trial-image local monitoring and autonomous rollback of Karaginides into the remote deployment system of Bailey, Marinelli, and Glaum in order to guarantee that recovery from a faulty update proceeds at the endpoint device even when outbound communications to the central server are unavailable, thereby improving update reliability. Applying Karaginides' endpoint-resident monitoring and rollback to the deployment system of Bailey, Marinelli, and Glaum is the use of a known technique to improve a similar deployment method in the same way, yielding the predictable result of an endpoint that remains authoritative for failure recovery while the central entity passively receives progress messages.
Regarding Claim 8, Bailey, Marinelli, Glaum, and Karaginides teach
The method of Claim 7.
Marinelli further teaches
wherein the first instructions further comprising compatibility instructions, which when executed by the processor of the local computing entity, cause the processor to: assess a hardware viability of the local computing entity to identify any defects and check event logs (Para. [0051], "a test suite on the BIOS and driver interfaces may be run in the pre-operating system environment. This test suite may be run after the PXE boot and may help reduce failure occurrence during the deployment process."; Para. [0049], "Such parameters may include Peripheral Component Interface (PCI) codes that can be used to identify the hardware machine when a failure is detected.") Examiner Comments: Marinelli's BIOS and driver test suite, run in the pre-operating system environment to identify hardware defects and failures, corresponds to compatibility instructions that assess hardware viability and check for defects.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bailey with the teaching of Marinelli in order to provide administrators with automatic detection of deployment failures and the ability to take remediation actions, which is a well-recognized need when deploying operating systems to remote machines that cannot be physically accessed. Both Bailey and Marinelli are directed to remote operating system deployment from a central server to target machines, and the combination represents the use of a known technique (progress and inventory reporting taught by Marinelli) to improve a similar device (the remote deployment system of Bailey) in the same way, yielding a predictable result.
Regarding Claim 9, Bailey, Marinelli, Glaum, and Karaginides teach
The method of Claim 8.
Bailey and Marinelli further teach
wherein: based on the hardware viability of the local computing entity being acceptable, the processor of the local computing entity executing the partition instructions to: form the first partition and the second partition; and move the existing operating system instruction set and user data to the first partition (Marinelli, Para. [0053], "the server... determines whether the test was successful. If it is determined that the test was indeed successful, then the operating system deployment continues."; Bailey, Col. 6, ln. 1-8, "the storage is repartitioned") Examiner Comments: Marinelli teaches that deployment, including partitioning, proceeds only if the hardware test is successful, and Bailey performs the actual partitioning step, so the combination teaches conditioning the partitioning on acceptable hardware viability.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bailey with the teaching of Marinelli in order to provide administrators with automatic detection of deployment failures and the ability to take remediation actions, which is a well-recognized need when deploying operating systems to remote machines that cannot be physically accessed. Both Bailey and Marinelli are directed to remote operating system deployment from a central server to target machines, and the combination represents the use of a known technique (progress and inventory reporting taught by Marinelli) to improve a similar device (the remote deployment system of Bailey) in the same way, yielding a predictable result.
Regarding Claim 10, Bailey, Marinelli, Glaum, and Karaginides teach
The method of Claim 7.
Bailey and Marinelli further teach
wherein said executing of the installation instructions comprises: configuring BIOS firmware of the local computing entity to install the second operating system instruction set (Bailey, Col. 13, ln. 8-15, "the script runs lilo once with each of two configuration files. lilo adds boot entries for both Windows (the default) and Linux."; Marinelli, Para. [0054], "hardware configuration tasks such as flashing or setting the BIOS may be executed.") Examiner Comments: Bailey configures the boot loader and Marinelli teaches BIOS configuration tasks during deployment, so the combination teaches configuring BIOS firmware to install the second operating system.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bailey with the teaching of Marinelli in order to provide administrators with automatic detection of deployment failures and the ability to take remediation actions, which is a well-recognized need when deploying operating systems to remote machines that cannot be physically accessed. Both Bailey and Marinelli are directed to remote operating system deployment from a central server to target machines, and the combination represents the use of a known technique (progress and inventory reporting taught by Marinelli) to improve a similar device (the remote deployment system of Bailey) in the same way, yielding a predictable result.
Regarding Claim 11, Bailey, Marinelli, Glaum, and Karaginides teach
The method of Claim 7.
Bailey further teaches
wherein after executing the first instructions, a division of the memory of the local computing entity exists between the first partition and the second partition, and wherein said executing of the installation instructions comprises: after completion of the installation of the second operating system instruction set, moving the user data to the second partition of the memory and removing the division between the first partition and the second partition (Col. 2, ln. 55-67, "network configuration data used by the source operating system is preserved during the installation process to enable the machine (executing the target operating system) to be reached at the same network address."; Col. 13, ln. 30-35, "the ExtendOEMPartition option specified in the autoinst.txt file causes the installer to stretch the 2048 MB FAT file system to fit the size of the disk being installed.") Examiner Comments: Bailey teaches that after installation the preserved data is restored to the new operating system and the partition is extended to fill the disk, corresponding to moving the user data and removing the partition division.
Regarding Claim 12, Bailey, Marinelli, Glaum, and Karaginides teach
The method of Claim 7.
Bailey further teaches
wherein the partition instructions are further executable to move file system data to the first partition of the memory (Col. 8, ln. 32-37, "the parameters and settings of the computing device are recorded.") Examiner Comments: Bailey records and preserves file system data (parameters, settings, configurations) during the partitioning and preparation phase.
Regarding Claim 13, Bailey, Marinelli, Glaum, and Karaginides teach
The method of Claim 12.
Bailey further teaches
wherein after executing the first instructions, a division of the memory of the local computing entity exists between the first partition and the second partition, and wherein said executing of the installation instructions comprises: after completion of the installation, moving the file system data to the second partition of the memory and removing the division between the first partition and the second partition (Col. 13, ln. 30-35, "the ExtendOEMPartition option specified in the autoinst.txt file causes the installer to stretch the 2048 MB FAT file system to fit the size of the disk being installed.") Examiner Comments: As in Claim 11, Bailey teaches extending the partition after installation to reclaim space and restoring the preserved data, corresponding to moving the file system data and removing the partition division.
Regarding Claim 14, Bailey, Marinelli, Glaum, and Karaginides teach
The method of Claim 7.
Bailey further teaches
erasing the existing operating system instruction set from the memory of the local computing entity (Col. 2, ln. 19-45, "the original source operating system (from the first bootable region) is then removed.") Examiner Comments: Bailey removes the original operating system from the bootable device after the new operating system is installed.
Regarding Claim 15, Bailey, Marinelli, Glaum, and Karaginides teach
The method of Claim 7.
Bailey further teaches
upon receiving at the local computing entity the second data package, copying the second operating system instruction set to the first partition of the memory (Col. 12, ln. 50-59, "the deployment routine repartitions disk one, creating a FAT file system that will be used to host the Windows 2000 installation. The Windows 2000 OS tarball is unpacked onto this partition.") Examiner Comments: Upon receiving the operating system bundle, Bailey unpacks and copies it onto the designated partition.
Regarding Claim 16, Bailey, Marinelli, Glaum, and Karaginides teach
The method of Claim 7.
Bailey further teaches
wherein after executing the first instructions, a division of the memory of the local computing entity exists between the first partition and the second partition, and wherein executing, by the processor of the local computing entity, the installation instructions causes installation of the second operating system instruction set on the first partition of the memory on the local computing entity; and after completion of the installation ..., moving the second operating system instruction set to the second partition of the memory and removing the division between the first partition and the second partition (Col. 2, ln. 19-45, "the boot loader is re-configured to boot the target operating system from the second bootable region of the storage. The machine is then re-booted again, after which the target operating system is operational.") Examiner Comments: Bailey reconfigures the boot to the new operating system and consolidates the storage after installation, corresponding to moving the second operating system to the second partition and removing the partition division.
Regarding Claim 17, Bailey, Marinelli, Glaum, and Karaginides teach
The method of Claim 7.
Bailey further teaches
causing the local computing entity to be unavailable for use to a user during the installation of the second operating system instruction set (Col. 13, ln. 15-30, "the machine is then rebooted into DOS via lilo... the machine is then rebooted, a skeletal Windows 2000 installation is booted, and the remaining stages of the installation are executed.") Examiner Comments: During installation the machine is rebooted through non-interactive stages, making it unavailable for normal use.
Regarding Claim 18, Bailey, Marinelli, Glaum, and Karaginides teach
The method of Claim 7.
Bailey further teaches
wherein the first data package comprises an encrypted data package, and the method further comprises: decrypting the encrypted data package at the local computing entity using a first encryption technique resulting in a decrypted first data package (Col. 12, ln. 15-25, "the operating system being delivered to the target server is compressed and encrypted in an encryption wrapper... the installation process will also include the steps of decrypting the wrapper (to remove the encryption) and decompressing the file (to remove the compression).") Examiner Comments: Bailey encrypts the data packages for transmission and decrypts them at the target machine.
Bailey did not specifically teach encrypting the decrypted first data package at the local computing entity using a second encryption technique resulting a re-encrypted first data package; and storing the re-encrypted first data package in the memory.
However, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to re-encrypt the decrypted data using a second (local) encryption technique for secure storage at rest. Re-encrypting data for local storage using a different key or technique was a well-known security practice, and one skilled in the art would have been motivated to do so to protect installation data at rest on the local machine, particularly where physical security of the target machine may be uncertain. Such a modification applies a known security technique to a known deployment process to yield predictable results. See KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007) and MPEP 2143.
Regarding Claim 19, Bailey, Marinelli, Glaum, and Karaginides teach
The method of Claim 18.
Bailey further teaches
receiving from the central computing entity at the local computing entity a start signal indicating to execute the first instructions; and responsively decrypting the re-encrypted first data package for execution (Col. 8, ln. 16-21, "a command is executed remotely, via a secure IP communications channel between the installer's computer and the target machine(s).") Examiner Comments: The remote command from the central system to initiate installation corresponds to a start signal, upon receipt of which the target machine decrypts the stored data package to begin execution.
Regarding Claim 20, is a non-transitory computer readable medium claim corresponding to the method claim above (Claim 7) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 7.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the arguments do not apply to the previous cited sections of the references used in the previous office action. The current office action is now citing additional references to address the newly added claimed limitations.
Conclusion
THIS ACTION IS MADE FINAL. 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 AMIR SOLTANZADEH whose telephone number is (571)272-3451. The examiner can normally be reached M-F, 9am - 5pm ET.
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, Wei Mui can be reached at (571) 272-3708. 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.
/AMIR SOLTANZADEH/Examiner, Art Unit 2191
/WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights