DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This communication is in response to the amendments filed on 02/12/2026. Claims 1-3, 5-9, and 11-22 are currently pending. It is noted that claims 4 and 10 remain cancelled by the applicant.
Response to Arguments
Applicant’s arguments 02/12/2026 with respect to claim 1 have been considered but are moot in view of a new reference that addressed applicant’s concern regarding the use of hashes of active partitions.
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, 6, 8, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. PGPub. No. 20150160936 to Morgan et al. (hereinafter Morgan) in view of U.S. Pat. No. 8819330 to Spangler et al. (hereinafter Spangler) and further in view of U.S. PGPub. No. 20090124375 to Patel; Pravinkumar (hereinafter Patel).
Regarding claim 1, Morgan discloses a method comprising:
generating a first operating system (OS) image associated with a
first type of machine (¶0051, “the installation tool 290 can generate the migrated operating system image 296 based on the extracted installation resources, and/or other configuration data. In 716, the installation tool 290 can transmit and/or install the migrated operating system image 296 to the selected one or more target clouds in the set of target clouds 234.”),
generating a second OS image associated with a second type of machine (¶0052, “…The
installation tool 290 can generate an updated migrated operating system image 296 based on changes to the set of configuration requirements 298 in one or more clouds in the set of target clouds 234 to which the migrated operating system image 296 has been transferred and instantiated.”, wherein updated migrated operating
system image is interpreted as the second operating system),
providing, the first OS image to a first machine and the second OS image to a second
machine, the first machine being associated with the first type of machine and the second machine being associated with the second type of machine (claims 7-8, “…generating a first image of the operating system in view of the first set of configuration requirements; and causing, by the processor, the operating system to be installed on the first target cloud using the first image of the operating system… generating a second image of the operating system in view of the second set of configuration requirements; and causing, by the processor, the operating system to be installed on the second target cloud using the second image of the operating system.”, wherein the processor causing this operation is a computing device.);
However, even though it is inherent that most operating systems are stored on root files, and the installation tool 290 generating the operating systems is associated with set of virtual machines 228 which are computing devices in FIG. 4, Morgan does not explicitly disclose the limitation of:
the first OS image including a first root file system and a first cryptographic key;
the second OS image including a second root file system and a second cryptographic key;
first standby partition and second standby partition of first machine and second machine respectively.
based at least the first standby partition successfully updating using the first OS image to become a first active partition and the second standby partition successfully updating using the second OS image to become a second active partition;
receiving one or more first hashes associated with the first cryptographic key from the first machine and one or more second hashes associated with the second cryptographic key from the second machine;
verifying the one or more first hashes using the first cryptographic key, and the one or more second hashes using the second cryptographic key; and
and based on a successful verification, causing the first machine that causes the first machine to update one or more first previous hashes associated with a previous active partition with the one or more first hashes, and to the second machine to update one or more second previous hashes associated with a second previous partition with the one or more second hashes.
Spangler discloses the first OS image including a first root file system and a first cryptographic key (Coln.3, lines 58-67 -Coln.4, lines 1-14, “…As shown in FIG. 1, the main memory device may contain a root file system that includes an instance of an operating system 140 for the computer system 100.”), (Coln.4, lines 55-67 -Coln.5, lines 1-13, “…As shown in FIG. 2, the recovery data 240 may also include a digital signature 280 that may be used by a computing device to verify that the recovery image stored on the secondary storage device 200 is from a trusted or reliable source. For instance, a cryptographic key stored in a boot stub of the computing device may be used to verify the digital signature 280 based on a message digest (e.g., hash) of one or more portions of the recovery data 240.”);
the second OS image including a second root file system and a second cryptographic key (Coln.7, lines 45-63, “…In some aspects, before the recovery image 445 is updated using the recovery image update, the recovery image update may be verified. For example, the system may use a cryptographic key stored in a boot stub of the computing device to verify a digital signature associated with the recovery image update. If the recovery image update is verified, the system may then update the recovery image with the recovery image update.”);
receiving one or more first hashes associated with the first cryptographic key from the first machine and one or more second hashes associated with the second cryptographic key from the second machine, (Coln.2, lines 16-24, “…The method may include receiving an image update over a network, updating an operating image of the system using the image update, determining whether the image update is stable by performing at least one test on the updated operating image, setting a recovery image update indication if the image update is stable, and rebooting the system.”), (Coln.4, lines 55-67-Coln.5, lines 1-6, “…As shown in FIG. 2, the recovery data 240 may also include a digital signature 280 that may be used by a computing device to verify that the recovery image stored on the secondary storage device 200 is from a trusted or reliable source. For instance, a cryptographic key stored in a boot stub of the computing device may be used to verify the digital signature 280 based on a message digest (e.g., hash) of one or more portions of the recovery data 240…”);
verifying the one or more first hashes using the first cryptographic key, and the one or more second hashes using the second cryptographic key (Coln.4, lines 55-67-Coln.5, lines 1-6, “…As shown in FIG. 2, the recovery data 240 may also include a digital signature 280 that may be used by a computing device to verify that the recovery image stored on the secondary storage device 200 is from a trusted or reliable source. For instance, a cryptographic key stored in a boot stub of the computing device may be used to verify the digital signature 280 based on a message digest (e.g., hash) of one or more portions of the recovery data 240…”),
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Morgan to include using cryptographic key to verify hashes of the operating system image as disclosed by Spangler and be motivated in doing so in order for the system to update the recovery image with the recovery image update-Spangler Coln.5, line 57-63 in parts.
However, Morgan in view of Spangler does not explicitly disclose the following limitation:
first standby partition and second standby partition of first machine and second machine respectively.
based at least the first standby partition successfully updating using the first OS image to become a first active partition and the second standby partition successfully updating using the second OS image to become a second active partition;
and based on a successful verification, causing the first machine that causes the first machine to update one or more first previous hashes associated with a previous active partition with the one or more first hashes, and to the second machine to update one or more second previous hashes associated with a second previous partition with the one or more second hashes.
Patel discloses first standby partition and second standby partition of first machine and second machine respectively (¶0596, “Referring to FIG. 15, a block diagram of an EGM OS manifest partition together with a game manifest partition is shown. The configuration directory within the manifest partition contains 2 files. The boot.id file contains the information as to which partition was used to start the system, OS1 or OS2, and which partition is the backup partition used for recovery purposes. The second file is the public key file which is used when the public key information is not available on the BIOS. The OS1 and OS2 partitions contain all the Manifest files and the Linux kernel and the initial RAM disk partition image. One of the partitions will be the currently active game environment, and the other will be a backup in case the active partition becomes corrupted and can not be run. The boot.id file mentioned above tells which partition is active and which is the backup.”), (¶0004, “ This invention pertains generally to gaming machine systems and methods. More particularly, the present invention relates to a gaming machine operating systems, gaming machines, and methods that include downloadable and/or configurable capabilities.”), (¶0909-¶0910, “… the Operator may have many configuration standards between machines. By configuration one machine and than exporting the machines device setup and accounting protocol setup, the operator would have a starting template for every machine on the casino floor…”, wherein any of the machines could be labelled as the first, second, third or fourth, etc and each of which will have both active and backup partitions ),
based at least the first standby partition successfully updating using the first OS image to become a first active partition and the second standby partition successfully updating using the second OS image to become a second active partition (¶0599, “An example method for installing a package may include the following steps: (1) Turn off all file and memory validation. (2) If an OS partition is to be updated, backup the currently running active partition into the backup partition. (3) Update the boot.id file to indicate which partition is to be started when the system is powered on. (4) Zero and delete the old Manifest file(s). (5) Copy in the new Manifest file(s). (6) If the file to be installed is an image, then copy the new image onto the partition or device”), (¶0630, “… One of the partitions will contain all the files for the active running game environment while the other contains a backup copy of the files used to successfully run the game environment. The backup exists for future use when dynamic updates will be made to the system. If the updates cause the gaming system not to run, then the gaming machine can be restarted from the back partition, which contains a copy of the last good running environment.”, wherein once the backup partition is updated, it becomes an active partition, and note that this is happening across plurality of machines in the system.), (¶0744, “Whenever a module is installed or updated on a system that has sufficient storage to maintain a backup copy of the operating environment, the following steps may be performed: (1) Reset the partition access permissions to allow writing to the partitions. (2) Copy the production environment into the backup environment. This may be done via a background task when an environment is activated and while the game is running. (3) Apply the changes to the production environment. (4) ensure that the boot.id file is set to boot the production environment and that a backup environment exists. (5) Reboot the system according to jurisdictional requirements.”);
and based on a successful verification, causing the first machine that causes the first machine to update one or more first previous hashes associated with a previous active partition with the one or more first hashes, and to the second machine to update one or more second previous hashes associated with a second previous partition with the one or more second hashes (¶0628, (¶0649-¶0651, “…The VMFs are created by a utility which uses the binary reproducible image of the partition where the files are located. It extracts all of the file names contained in the binary image, opens each file and calculates a SHA-1 hash value for the contents of the file. The VMF file header is generated to reflect the contents of the Manifest file. A detail entry for each file is created and stored in the VMF. After all the detail file entries are placed in the VMF, a SHA-1 hash is calculated for all the information from the control flag to the last detailed file entry in the VMF. The SHA-1 hash is then stored in the VMF header and is digitally signed with a private/public key pair. This digital signature is the saved in the VMF header.”), see also ¶0637-¶0641.
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Morgan and Spangler to include standby partition (backup partition) as disclosed by Patel and be motivated in doing so in order for the system to continue operating in case the active partition is corrupted and cannot be run-Patel ¶0596 in parts.
Regarding claim 6, Morgan in view of Spangler and further in view of Patel discloses the method of claim 1.
Spangler further discloses wherein the verifying the one or more first hashes comprises verifying, using the first cryptographic key, at least one of a first OS or the first root file system on the first standby partition based at least on the one or more first hashes received from the first machine (Coln.4, lines 55-67-Coln. 5, lines 1-13, “…As shown in FIG. 2, the recovery data 240 may also include a digital signature 280 that may be used by a computing device to verify that the recovery image stored on the secondary storage device 200 is from a trusted or reliable source. For instance, a cryptographic key stored in a boot stub of the computing device may be used to verify the digital signature 280 based on a message digest (e.g., hash) of one or more portions of the recovery data 240.When a recovery mode procedure is to be executed, the computer system 100 may verify that the recovery image containing the recovery data 240 is from a trustworthy source (e.g., the digital signature 280 matches the message digest) and if verified, the system 100 may then continue to execute the recovery mode procedure using the recovery data 240 to repair or replace a current operating image of the system 100.”, wherein hash of one or more portions of the recovery data is interpreted as one or more hashes of portions of the recovery data), (Coln.3, lines 58-67, “…As shown in FIG. 1, the main memory device may contain a root file system that includes an instance of an operating system 140 for the computer system 100.”); and
the verifying the one or more second hashes comprises verifying, using the second cryptographic key, at least one of a second OS or the second root file system on the second standby partition based at least on the one or more second hashes received from the second machine (Coln.4, lines 55-67-Coln. 5, lines 1-13, “…As shown in FIG. 2, the recovery data 240 may also include a digital signature 280 that may be used by a computing device to verify that the recovery image stored on the secondary storage device 200 is from a trusted or reliable source. For instance, a cryptographic key stored in a boot stub of the computing device may be used to verify the digital signature 280 based on a message digest (e.g., hash) of one or more portions of the recovery data 240…”), (Coln.7, lines 56-63, “In some aspects, before the recovery image 445 is updated using the recovery image update, the recovery image update may be verified. For example, the system may use a cryptographic key stored in a boot stub of the computing device to verify a digital signature associated with the recovery image update. If the recovery image update is verified, the system may then update the recovery image with the recovery image update.”), (Coln.7, lines 11-26, “Once the recovery image update is obtained, at operation 510 the operating system 440 may set a flag or some other recovery image update indication in the writable portion of the firmware code module 415 indicating that an update to the recovery image is available. In some aspects, as described above, an update module may confirm that the update is functional before the indication is set.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Morgan, Spangler, and Patel to include verification of hashes with cryptographic keys as disclosed by Spangler and be motivated in doing so to include standby partition (backup partition) as disclosed by Patel and be motivated in doing so in order to ensure both data integrity and authenticity.
Regarding claim 8, Morgan in view of Spangler and further in view of Patel discloses the method of claim 1.
Patel further discloses receiving an indication that the update using the first OS image failed on the first machine (¶0601, “The system is rebooted and BIOS validates all of the manifests and starts the new system environment. If this fails, the OS faults…”); and
based at least on the receiving of the indication: initiate another attempt to provide the first OS image to the first machine (¶0601, “…an operator must reboot the system. Upon reboot, BIOS will switch back to the backup copy and restart the system….”); and
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Morgan, Spangler, and Patel to include making another attempt to update a machine if the first attempt fails as disclosed Patel and be motivated in doing so in order to enable the BIOS to switch back to the backup copy and restart the system-Patel ¶0601 in parts.
Regarding claim 19, Morgan discloses a system comprising:
one or more processors to (¶0004, “Techniques are provided (e.g., a method, a system,
non-transitory computer-readable medium storing code or instructions executable by one or more processors) for updating an edge device (e.g., a computing device configured to
deliver computing…”);
generate a first operating system (OS) image associated with a
first type of machine (¶0051, “the installation tool 290 can generate the migrated operating system image 296 based on the extracted installation resources, and/or other configuration data. In 716, the installation tool 290 can transmit and/or install the migrated operating system image 296 to the selected one or more target clouds in the set of target clouds 234.”),
generate a second OS image associated with a second type of machine (¶0052, “…The
installation tool 290 can generate an updated migrated operating system image 296 based on changes to the set of configuration requirements 298 in one or more clouds in the set of target clouds 234 to which the migrated operating system image 296 has been transferred and instantiated.”, wherein updated migrated operating
system image is interpreted as the second operating system),
provide, the first OS image to a first machine and the second OS image to a second
machine, the first machine being associated with the first type of machine and the second machine being associated with the second type of machine (claims 7-8, “…generating a first image of the operating system in view of the first set of configuration requirements; and causing, by the processor, the operating system to be installed on the first target cloud using the first image of the operating system… generating a second image of the operating system in view of the second set of configuration requirements; and causing, by the processor, the operating system to be installed on the second target cloud using the second image of the operating system.”, wherein the processor causing this operation is a computing device.);
However, even though it is inherent that most operating systems are stored on root files, and the installation tool 290 generating the operating systems is associated with set of virtual machines 228 which are computing devices in FIG. 4, Morgan does not explicitly disclose the limitation of:
the first OS image includes a first cryptographic key
the second OS image includes a second cryptographic key;
provide the first OS image to a first standby partition of a first machine and the second OS image to a second standby partition of a second machine;
based at least the first standby partition successfully updating using the first OS image to become a first active partition and the second standby partition successfully updating using the second OS image to become a second active partition;
receive one or more first hashes associated with the first cryptographic key from the first machine and one or more second hashes associated with the second cryptographic key from the second machine;
verify the one or more first hashes using the first cryptographic key, and the one or more second hashes using the second cryptographic key; and
based on a successful verification, causing the first machine that causes the first machine to update one or more first previous hashes associated with a previous active partition with the one or more first hashes, and to the second machine to update one or more second previous hashes associated with a second previous partition with the one or more second hashes.
Spangler discloses the first OS image includes a first root file system and a first cryptographic key (Coln.3, lines 58-67 -Coln.4, lines 1-14, “…As shown in FIG. 1, the main memory device may contain a root file system that includes an instance of an operating system 140 for the computer system 100.”), (Coln.4, lines 55-67 -Coln.5, lines 1-13, “…As shown in FIG. 2, the recovery data 240 may also include a digital signature 280 that may be used by a computing device to verify that the recovery image stored on the secondary storage device 200 is from a trusted or reliable source. For instance, a cryptographic key stored in a boot stub of the computing device may be used to verify the digital signature 280 based on a message digest (e.g., hash) of one or more portions of the recovery data 240.”);
the second OS image including a second root file system and a second cryptographic key (Coln.7, lines 45-63, “…In some aspects, before the recovery image 445 is updated using the recovery image update, the recovery image update may be verified. For example, the system may use a cryptographic key stored in a boot stub of the computing device to verify a digital signature associated with the recovery image update. If the recovery image update is verified, the system may then update the recovery image with the recovery image update.”);
receive one or more first hashes associated with the first cryptographic key from the first machine and one or more second hashes associated with the second cryptographic key from the second machine, (Coln.2, lines 16-24, “…The method may include receiving an image update over a network, updating an operating image of the system using the image update, determining whether the image update is stable by performing at least one test on the updated operating image, setting a recovery image update indication if the image update is stable, and rebooting the system.”), (Coln.4, lines 55-67-Coln.5, lines 1-6, “…As shown in FIG. 2, the recovery data 240 may also include a digital signature 280 that may be used by a computing device to verify that the recovery image stored on the secondary storage device 200 is from a trusted or reliable source. For instance, a cryptographic key stored in a boot stub of the computing device may be used to verify the digital signature 280 based on a message digest (e.g., hash) of one or more portions of the recovery data 240…”);
verify the one or more first hashes using the first cryptographic key, and the one or more second hashes using the second cryptographic key (Coln.4, lines 55-67-Coln.5, lines 1-6, “…As shown in FIG. 2, the recovery data 240 may also include a digital signature 280 that may be used by a computing device to verify that the recovery image stored on the secondary storage device 200 is from a trusted or reliable source. For instance, a cryptographic key stored in a boot stub of the computing device may be used to verify the digital signature 280 based on a message digest (e.g., hash) of one or more portions of the recovery data 240…”),
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Morgan to include using cryptographic key to verify hashes of the operating system image as disclosed by Spangler and be motivated in doing so in order for the system to update the recovery image with the recovery image update-Spangler Coln.5, line 57-63 in parts.
However, Morgan in view of Spangler does not explicitly disclose the following limitation:
provide the first OS image to a first standby partition of a first machine and the second OS image to a second standby partition of a second machine;
based at least the first standby partition successfully updating using the first OS image to become a first active partition and the second standby partition successfully updating using the second OS image to become a second active partition; and
based on a successful verification, send data that allows the first machine to update one or more first previous hashes associated with a previous active partition with the one or more first hashes, and second machine to update one or more second previous hashes associated with a second previous partition with the one or more second hashes.
Patel discloses provide the first OS image to a first standby partition of a first machine and the second OS image to a second standby partition of a second machine (¶0596, “Referring to FIG. 15, a block diagram of an EGM OS manifest partition together with a game manifest partition is shown. The configuration directory within the manifest partition contains 2 files. The boot.id file contains the information as to which partition was used to start the system, OS1 or OS2, and which partition is the backup partition used for recovery purposes. The second file is the public key file which is used when the public key information is not available on the BIOS. The OS1 and OS2 partitions contain all the Manifest files and the Linux kernel and the initial RAM disk partition image. One of the partitions will be the currently active game environment, and the other will be a backup in case the active partition becomes corrupted and can not be run. The boot.id file mentioned above tells which partition is active and which is the backup.”), (¶0004, “This invention pertains generally to gaming machine systems and methods. More particularly, the present invention relates to a gaming machine operating systems, gaming machines, and methods that include downloadable and/or configurable capabilities.”), (¶0599, “ An example method for installing a package may include the following steps: (1) Turn off all file and memory validation. (2) If an OS partition is to be updated, backup the currently running active partition into the backup partition. (3) Update the boot.id file to indicate which partition is to be started when the system is powered on. (4) Zero and delete the old Manifest file(s). (5) Copy in the new Manifest file(s). (6) If the file to be installed is an image, then copy the new image onto the partition or device…”), (¶0630, “… One of the partitions will contain all the files for the active running game environment while the other contains a backup copy of the files used to successfully run the game environment. The backup exists for future use when dynamic updates will be made to the system. If the updates cause the gaming system not to run, then the gaming machine can be restarted from the back partition, which contains a copy of the last good running environment.”, wherein once the backup partition is updated, it becomes an active partition, and note that this is happening across plurality of machines in the system.), (¶0909-¶0910, “… the Operator may have many configuration standards between machines. By configuration one machine and than exporting the machines device setup and accounting protocol setup, the operator would have a starting template for every machine on the casino floor…”, wherein any of the machines could be labelled as the first, second, third or fourth, etc and each of which will have both active and backup partitions ),
based at least the first standby partition successfully updating using the first OS image to become a first active partition and the second standby partition successfully updating using the second OS image to become a second active partition (¶0599, “An example method for installing a package may include the following steps: (1) Turn off all file and memory validation. (2) If an OS partition is to be updated, backup the currently running active partition into the backup partition. (3) Update the boot.id file to indicate which partition is to be started when the system is powered on. (4) Zero and delete the old Manifest file(s). (5) Copy in the new Manifest file(s). (6) If the file to be installed is an image, then copy the new image onto the partition or device”), (¶0630, “… One of the partitions will contain all the files for the active running game environment while the other contains a backup copy of the files used to successfully run the game environment. The backup exists for future use when dynamic updates will be made to the system. If the updates cause the gaming system not to run, then the gaming machine can be restarted from the back partition, which contains a copy of the last good running environment.”, wherein once the backup partition is updated, it becomes an active partition, and note that this is happening across plurality of machines in the system.), (¶0744, “Whenever a module is installed or updated on a system that has sufficient storage to maintain a backup copy of the operating environment, the following steps may be performed: (1) Reset the partition access permissions to allow writing to the partitions. (2) Copy the production environment into the backup environment. This may be done via a background task when an environment is activated and while the game is running. (3) Apply the changes to the production environment. (4) ensure that the boot.id file is set to boot the production environment and that a backup environment exists. (5) Reboot the system according to jurisdictional requirements.”);
and based on a successful verification, causing the first machine that causes the first machine to update one or more first previous hashes associated with a previous active partition with the one or more first hashes, and to the second machine to update one or more second previous hashes associated with a second previous partition with the one or more second hashes (¶0628, (¶0649-¶0651, “…The VMFs are created by a utility which uses the binary reproducible image of the partition where the files are located. It extracts all of the file names contained in the binary image, opens each file and calculates a SHA-1 hash value for the contents of the file. The VMF file header is generated to reflect the contents of the Manifest file. A detail entry for each file is created and stored in the VMF. After all the detail file entries are placed in the VMF, a SHA-1 hash is calculated for all the information from the control flag to the last detailed file entry in the VMF. The SHA-1 hash is then stored in the VMF header and is digitally signed with a private/public key pair. This digital signature is the saved in the VMF header.”), see also ¶0637-¶0641.
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Morgan and Spangler to include standby partition (backup partition) as disclosed by Patel and be motivated in doing so in order for the system to continue operating in case the active partition is corrupted and cannot be run-Patel ¶0596 in parts.
Regarding claim 20, Morgan in view of Spangler and further in view of Patel discloses the processor of claim 19.
Morgan further discloses wherein the processor is comprised in at least one of: a control system for an autonomous or semi-autonomous machine; a perception system for an autonomous or semi-autonomous machine; a system for performing simulation operations; a system for performing digital twin operations; a system for performing light transport simulation; a system for performing collaborative content creation for 3D assets; a system for performing deep learning operations; a system for performing real-time streaming; a system for generating at least one of virtual reality (VR) content, augmented reality (AR) content, or mixed reality (MR) content; a system for presenting at least one of VR content, AR content, or MR content; a system implemented using an edge device; a system implemented using a robot; a system for performing conversational AI operations; a system for generating synthetic data; a system incorporating one or more virtual machines (VMs) (¶0003, “… a cloud-based architecture deploys a set of hosted resources such as processors, operating systems, software and other components that can be combined together to form virtual machines. A user or customer can request the instantiation of a virtual machine or set of machines from those resources from a central server or cloud management system to perform intended tasks…”); a system implemented at least partially in a data center; or a system implemented at least partially using cloud computing resources (¶0004, “… the user must track the cloud processes to ensure that the correct cloud processes have been instantiated, that the cloud processes are functioning properly and/or efficiently, that the cloud is providing sufficient resources to the cloud processes, and so forth…”).
Claims 9, 11-12, 15-18, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. PGPub. No. 20220326941 to Nelson et al. (hereinafter Nelson) in view of US. Pat. No. 12210895 to Kaimal et al. (hereinafter Kailmal).
Regarding claim 9, Nelson discloses a machine (¶0033, FIG. 1, “edge device 100”) comprising:
one or more processors (¶0004, “Techniques are provided (e.g., a method, a system, non-transitory computer-readable medium storing code or instructions executable by one or more processors) for updating an edge device (e.g., a computing device configured to deliver computing…”) to:
execute a first system partition of the machine (¶0076, “the volume manager 807 may obtain a snapshot of the existing root file system by accessing boot disk 808. The boot disk 808 may be a data store or partition of the edge device that is configured to store any suitable number of root file systems (e.g., root file system volume snapshots), the first system partition including a first version of an operating system (OS) (¶0077, “… Root file system volume snapshot 902 may store references (and/or data structures such as inode data structures) to any suitable OS image file and/or references to one or more containers (e.g., Docker containers, etc.) and/or references to one or more applications, images corresponding to one or more services, or the like. As depicted in FIG. 9, the root file system volume snapshot 902 may store a snapshot including references to an existing operating system (OS version 1 (“OS v1”)) and/or references to images of a set of services with which a device is currently configured (e.g., an image for Service A version 1 (“Service A v1”))…”);
install an OS image associated with a second version of the OS on a second system partition of the machine (¶0077, “… Root file system volume snapshot 904 may store references to a different operating system (e.g., OS v2) and/or references to images corresponding to a different set of services (e.g., Service A v1, Service B version 1 (“Service B v1”)…”), (¶0080, “the volume manager 807 may be configured to create a separate partition within boot disk 808 within which it may store a new root file system volume snapshot (e.g., root file system volume snapshot 904)…”);
update, using the OS image, the second system partition to the second version of the OS (¶0086, FIG. 10, “FIG. 10 illustrates an example method 1000 for performing a first update of an edge device, in accordance with at least one embodiment. Prior to executing the operations of method 1000, the edge device on which volume manager 1002 operates may be configured with a current operating system and an update request to update the device to a different operating system may be received. In the example provided herein, the current operating system (referred to as “OS1”) may correspond to files 1 and 2 and a requested operating system (e.g., “OS2,” corresponding to a received request to update the edge device to a different operating system) may correspond to the files 1′, 2, 3, and 4. File 1′ may be a different version of file 1. Snapshot 1004 may previously exist and may include snapshots of (e.g., references to) files 1 and 2 stored in data store 1006. These references are depicted at 1005. Data store 1006 may be part of boot disk 808 of FIG. 8. Prior to execution of method 1000, snapshot 1004 (e.g., a volume generated by the volume manager 1002) may be mounted or otherwise identified as the active root file system from which a particular edge device is booted. Any of the snapshots discussed in connection with FIG. 10 may be mountable volumes from which an edge device may be booted. In some embodiments, these snapshots/volumes may exist in separate partitions, or the same partition, in memory of the edge device…”);
and cause the machine to reboot into the second system partition based at least on the second system partition being updated (¶0005, “…The method may further comprise modifying a booting order of the edge device to configure the edge device to execute the second operating system”), (¶0083, “… the update manager 804 (or volume manager 807) may execute any suitable operations to update a boot order to indicate that the edge device is first to boot from the updated file system volume snapshot (e.g., root file system volume snapshot 904)…”), (¶0114, “a booting order of the edge device may be modified (e.g., by the volume manager) to configure the edge device to utilize the second operating system”).
However, Nelson even though discloses clusters of edge devices and separate partitions in some paragraphs such as ¶0070, ¶0010, ¶0059, to mention a few, does not explicitly disclose the following limitation:
store, in the first system partition, data representing one or more configurations for connecting with one or more second machines from a cluster of machines that includes the machine;
generate, using the first system partition, and based at least on the second system partition being updated, a copy of the data representing the one or more configurations for connecting with the one or more second machines;
store, using the first system partition, the copy of the data representing the one or more configurations for connecting with the one or more second machines in the second system partition;
Kaimal discloses store, in the first system partition, data representing one or more configurations for connecting with one or more second machines from a cluster of machines that includes the machine (Col. 1, lines 29-59, “… providing a network appliance configured in a cluster of nodes, each node of the network appliance similarly configured to support network functions and each node of the network appliance including a bootable partition executing an update agent and an update partition configured to store a different version of the node; providing a notification to a network administrator of an update available for the network appliance from a user interface of a threat management facility for an enterprise network, the notification including an indication of whether the update is a full update to each node or an incremental update to each node; receiving an update request from the network administrator to perform the update to the cluster of nodes;…”, wherein on or more nodes in the cluster of nodes is interpreted as the claimed one or more second machines), (Col. 34, lines 9-32, “…when the update is a full update, copying the update to an update partition and rebooting the node from the update partition. In order to support management of partial and full updates, each network appliance may include two partitions or other logically separated storage sections on a hard disk, virtual hard disk, or other storage device for the network appliance…”), (Col. 20, lines 4-36, “…A gateway registration storage facility 222 (or optionally an extension of the image data store 220) may store gateway-specific configuration and/or registration images or portions thereof for use by an instantiated gateway 210 during threat management configuration, registration as a ZTNA gateway, and the like…”), (Col. 22, lines 55-64, “…Upon receiving configuration data, the cloud agent module 234 may store the configuration data and send notifications for any related modules to reload the stored configuration data…”), (Col. 41, lines 27-47, “…In the normal mode, network configuration settings are stored, and then applied when suitable conditions are present within the cluster such as favorable cluster load and cluster stability, along with good network connectivity…”);
generate, using the first system partition, and based at least on the second system partition being updated, a copy of the data representing the one or more configurations for connecting with the one or more second machines (Col. 34, lines 9-32, “…when the update is a full update, copying the update to an update partition and rebooting the node from the update partition. In order to support management of partial and full updates, each network appliance may include two partitions or other logically separated storage sections on a hard disk, virtual hard disk, or other storage device for the network appliance. The first partition may serve as a current partition from which the network appliance is currently executing. The second partition may serve as an update partition where a new image can be loaded when a full update is required. During a full update, the new image for the network appliance may be downloaded to the update partition, and may also be verified by the network appliance. The device may then be booted from the update partition (which, if the boot is successful, becomes the current partition). The current partition then becomes the update partition…”, this is in accordance with applicant disclosure in ¶0020, wherein one or more configurations are copied from one partition to another), (Col. 10, lines 29-55, “the threat management facility 100 may provide configuration management as an aspect of the policy management facility 112, the security management facility 122, or some combination. Configuration management may define acceptable or required configurations for the compute instances 10-26, applications, operating systems, hardware, or other assets, and manage changes to these configurations…”), (Col. 37, lines 58-67-Coln.38, lines 1-11, “…A variety of consensus protocols are known in the art and suitable for maintaining consistency among compute instances 1506 in the cluster 1504. By way of non-limiting example, the Raft consensus protocol can be used to maintain synchronization among nodes in a cluster by electing a leader or “primary instance” that replicates a log outward to conform other nodes to the leader's configuration.”);
store, using the first system partition, the copy of the data representing the one or more configurations for connecting with the one or more second machines in the second system partition (Col. 34, lines 9-32, “…when the update is a full update, copying the update to an update partition and rebooting the node from the update partition. In order to support management of partial and full updates, each network appliance may include two partitions or other logically separated storage sections on a hard disk, virtual hard disk, or other storage device for the network appliance…”), (Col. 20, lines 4-36, “…A gateway registration storage facility 222 (or optionally an extension of the image data store 220) may store gateway-specific configuration and/or registration images or portions thereof for use by an instantiated gateway 210 during threat management configuration, registration as a ZTNA gateway, and the like…”), (Col. 22, lines 55-64, “…Upon receiving configuration data, the cloud agent module 234 may store the configuration data and send notifications for any related modules to reload the stored configuration data…”), (Col. 41, lines 27-47, “…In the normal mode, network configuration settings are stored, and then applied when suitable conditions are present within the cluster such as favorable cluster load and cluster stability, along with good network connectivity…”);
Thus, one of ordinary skill would have found it obvious before the effective filing date of applicant’s claimed invention to modify the machine of Nelson to include using system partitions to store configurations associated with cluster of machines as disclosed by Kaimal and be motivated in doing so in order to maintain availability and performance of the network appliance during the update-Kaimal abstract in parts.
Regarding claim 11, Nelson in view of Kaimal discloses the machine of claim 9.
Nelson further discloses wherein the one or more processors are further to:
determine that the error occurred with at least one of the second system partition being updated (¶0079, “… if no differences are found, the volume manager 807 can send an indication of the same to the update manager 804 which in turn can provide the computing device 810 an indication that the update was unsuccessful and/or unnecessary…”) or the reboot into the second system partition (¶0085, “the rollback option is automatically executed when an indication (e.g., user input) that the second operating system is approved has not been received within a threshold period of time (e.g., one hour, 24 hours, etc.) since the second operating system has been in use. In some embodiments, the user of the edge device can select which file system volume snapshot to use each time the device is rebooted. In some embodiments, some aspect of the updated root file system volume snapshot may be faulty or otherwise undesirable. Thus, utilizing the techniques described herein enables the user to roll back to a previous version of the operating system (e.g., using root file system volume snapshot 902) at any suitable time.”);
and cause, based at least on a determination that an error occurred, the machine to reboot into the first system partition (¶0085, “…the rollback option is automatically executed when an indication (e.g., user input) that the second operating system is approved has not been received within a threshold period of time (e.g., one hour, 24 hours, etc.) since the second operating system has been in use. In some embodiments, the user of the edge device can select which file system volume snapshot to use each time the device is rebooted. In some embodiments, some aspect of the updated root file system volume snapshot may be faulty or otherwise undesirable. Thus, utilizing the techniques described herein enables the user to roll back to a previous version of the operating system (e.g., using root file system volume snapshot 902) at any suitable time.”). See also Col. 38, lines 12-29 of Kaimal for rebooting on a rollback partition.
Regarding claim 12, Nelson in view of Kaimal discloses the machine of claim 11.
Nelson further discloses wherein the one or more processors are further to:
attempt to install the OS image associated with the second version of the OS on the second system partition of the machine (¶0080-¶0081, “At 822, the volume manager 807 may be configured to create a separate partition within boot disk 808 within which it may store a new root file system volume snapshot (e.g., root file system volume snapshot 904). A partition refers to a section of the boot disk that is separate and isolated from other partitions of the boot disk…Root file system volume snapshot 904 may include reference to the files corresponding to OS v2, Service A v1, and Service B v1.”);
attempt to update, using the OS image, the second system partition to the second version of the OS (¶0082, “At 826, the volume manager 807 may provide an indication that the requested update has been applied. In some embodiments, the volume manager 807 may provide any suitable identifier and/or location of the updated file system volume snapshot (e.g., root file system volume snapshot 904, wherein Root file system volume snapshot 904 includes reference to the files corresponding to OS v2 as disclosed in ¶0081).; and
based at least on the second system partition again being updated (¶0095-¶0101, “FIG. 11 illustrates another example method 1100 for performing a second update of an edge device, in accordance with at least one embodiment…. At 1124, the volume manager 1102 may update the snapshot 1118 with references to files 5 and 6… The resulting references of snapshot 1118 are depicted at 1126”), cause the machine to again reboot into the second system partition (¶0005, “…The method may further comprise modifying a booting order of the edge device to configure the edge device to execute the second operating system”), (¶0083, “… the update manager 804 (or volume manager 807) may execute any suitable operations to update a boot order to indicate that the edge device is first to boot from the updated file system volume snapshot (e.g., root file system volume snapshot 904)…”), (¶0114, “a booting order of the edge device may be modified (e.g., by the volume manager) to configure the edge device to utilize the second operating system”).
Regarding claim 15, Nelson in view of Kaimal discloses the machine of claim 9.
Nelson further discloses wherein the one or more processors are further to receive second data that causes the second system partition to be updated using the SO image (¶0005, “The method may further comprise receiving, by the edge device, a request for a second operating system to be provisioned to the edge device. In some embodiments, the request may include one or more files of the second operating system and/or a manifest that identifies one or more files of the second operating system…”), (¶0080, “At 822, the volume manager 807 may be configured to create a separate partition within boot disk 808 within which it may store a new root file system volume snapshot (e.g., root file system volume snapshot 904). A partition refers to a section of the boot disk that is separate and isolated from other partitions of the boot disk”, wherein a separate partition within boot disk 808 is interpreted as the second system partition and root file system volume snapshot 904 may store references to a different operating system (e.g., OS v2) and/or references to images corresponding to a different set of services (e.g., Service A v1, Service B version 1 (“Service B v1”), ¶0077).
Regarding claim 16, Nelson in view of Kaimal discloses the machine of claim 15.
Nelson further discloses wherein the second data represents a container that triggers a post install script associated with the OS image (¶0034, “the edge device 100 may include containerization engine 102 (e.g., Docker, Kubernetes, etc.) configured to implement one or more containers (e.g., corresponding to container(s) 104A, 104B, 104C, to 104N, collectively referred to as “container(s) 104”). A containerization engine (e.g., the containerization engine 102) may be container-orchestration system for automating computer application deployment, scaling, and management. In some embodiments, the containerization engine may be configured to provide OS-level virtualization to deliver software in packages called containers…”), (¶0074, “…In some embodiments, the volume manager may create a new volume snapshot of the current file system (e.g., implemented by an existing volume snapshot that implements the current version of the OS, applications, and/or services with which the edge device is set to boot) to obtain references to all the files of the current file system…”), the post install script causing one or more steps associated with the second system partition being updated using system partitioning (¶0079-¶0083, “…. the volume manager 807 may be configured to create a separate partition within boot disk 808 within which it may store a new root file system volume snapshot (e.g., root file system volume snapshot 904). A partition refers to a section of the boot disk that is separate and isolated from other partitions of the boot disk…in response to receiving such an indication, the update manager 804 may be configured to execute any suitable operations to update the default location from which the edge device is booted...”, wherein a post install script is interpreted as command/instruction to perform specified task which in this instance is a configuration to execute using partitioning to update the second system partition)
Regarding claim 17, Nelson in view of Kaimal discloses the machine of claim 9.
Nelson further discloses wherein the one or more processors are further to:
receive, from a system, an indication that the OS image is available for updating the machine (¶0069-¶0072, “the method 800 may begin at 802, where a request to execute a system update is received by the control plane API 802. The request may be received from computing device 810. Computing device 810 may be an example of a cloud computing device of a cloud computing environment (e.g., a device running an update manager in the cloud)…the request may include an OS image and/or one or more containers (e.g., Docker containers, etc.) and/or images corresponding to one or more services. In some embodiments, the OS image may include the one or more containers and/or images…”, wherein including the OS image in the request is an indication that the OS image is available for updating); and
based at least on the indication, receive the OS image from a datastore associated with the system (¶0073, “the update manager 804 may be configured to obtain the OS image and/or the one or more containers and/or images corresponding to the one or more services from data store 806. In some embodiments, the data store 806 is located in local memory at the edge device and the OS image and/or containers and/or images have been previously copied to the data store 806”).
Regarding claim 18, Nelson in view of Kaimal discloses the machine of claim 9. Nelson further discloses wherein the machine is comprised in at least one of: a control
system for an autonomous or semi-autonomous machine; a perception system for an autonomous or semi-autonomous machine; a system for performing simulation operations; a system for performing digital twin operations; a system for performing light transport simulation; a system for performing collaborative content creation for 3D assets; a system for performing deep learning operations (¶0028, “…The device can also be used for machine learning, with models trained in the cloud and running in disconnected locations to improve efficiency…”); a system for performing real-time streaming; a system for generating at least one of virtual reality (VR) content, augmented reality (AR) content, or mixed reality (MR) content; a system for presenting at least one of VR content, AR content, or MR content; a system implemented using an edge device (¶0005, “… One embodiment is directed to a method for updating an edge device. The method may comprise executing, by an edge device, a first operating system, the edge device being configured to selectively execute within an isolated computing environment…”); a system implemented using a robot; a system for performing conversational AI operations; a system for generating synthetic data; a system incorporating one or more virtual machines (VMs) (¶0034, “…The edge device 100 may further include a hypervisor 106 configured to implement one or more virtual machines (e.g., virtual machines 108A, 108B, 108C, to 108N, collectively referred to as “virtual machine(s) 108” or “VMs 108”).”); a system implemented at least partially in a data center; or a system implemented at least partially using cloud computing resources.
Regarding claim 21, Nelson in view of Kaimal discloses the machine of claim 9.
Nelson further discloses wherein the data further represents one or more second configurations, the one or more second configurations indicating at least at least one of:
one or more locations associated with the one or more second machines (¶0042, “FIG. 4 illustrates an exploded view of the cloud infrastructure edge computing device described herein (e.g., edge device 400, an example of the edge device 100 of FIG. 1), in accordance with at least one embodiment. The various components described with respect to FIGS. 1 and 2 can be communicatively attached to one or more motherboards and/or interface cards within the edge device 400. The illustrated configuration of components is but just one implementation. The specific locations of components shown is not intended to be limiting, and as noted, any configuration that is capable of implementing the functionality described herein is acceptable. Once the components are installed, the entire box can be closed, sealed, and locked with tamper-evident components.”);
or
one or more types associated with the one or more second machines (¶0035, “…The OS 112 may be configured to support a specific deployment type (e.g., a single edge device deployment, or a specific edge device cluster configuration)…”)
Claims 3 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. PGPub. No. 20150160936 to Morgan et al. (hereinafter Morgan) in view of U.S. Pat. No. 8819330 to Spangler et al. (hereinafter Spangler) and further in view of U.S. PGPub. No. 20090124375 to Patel; Pravinkumar (hereinafter Patel) and further in view of in view of U.S. PGPub. No. 20200097276 to Jacobson et al. (hereinafter Jacobson).
Regarding claim 3, Morgan in view of Spangler and further in view of Patel discloses the method of claim 1.
However, Morgan in view of Spangler and Patel does not explicitly disclose wherein:
the providing the first OS image to the first standby partition of the first machine comprises storing the first OS image on a datastore accessible to the first machine; and
the providing the second OS image to the second standby partition of the second machine comprises storing the second OS image on the datastore accessible to the second machine.
Jacobson discloses the providing the first OS image to the first machine comprises storing the first OS image on a datastore accessible to the first machine (¶0022, “the user may initiate creation of the OS image on the head node 102 by providing a list of packages and/or files to be installed to create the OS image. The packages and/or files may be stored in the repository 108 and accessed by the head node 102 and/or secondary node 104 during the OS image creation. The process of the image creation may be started in the head node 102 by way of a package or file list. The files and/or packages are retrieved from the repository 108 to be used for the OS image creation on the secondary node 104 when the OS image is for an end node 106 with a different architecture.”); and
the providing the second OS image to the second machine comprises storing the second OS image on the datastore accessible to the second machine (claim 10, “The method of claim 9, further comprising: storing, by the head node, the first OS image and the second OS image in an OS image repository containing OS images for end nodes of different architectures.”) (¶0050, “…the head node may store the OS image in an OS image repository. As a result, the head node may transmit and install the OS image from the OS image repository to other end nodes having the second architecture.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Morgan, Spangler, and Patel to include storing plurality of OS images in a database as disclosed Jacobson and be motivated in doing so in order to create and install OS images for new end nodes having different architectures- Jacobson ¶0017 in parts.
Claims 5 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. PGPub. No. 20150160936 to Morgan et al. (hereinafter Morgan) in view of U.S. Pat. No. 8819330 to Spangler et al. (hereinafter Spangler) and further in view of U.S. PGPub. No. 20090124375 to Patel; Pravinkumar (hereinafter Patel) and further in view of U.S. PGPub. No 20180091298 to SAURAV et al. (hereinafter SAURAV).
Regarding claim 5, Morgan in view of Spangler and further in view of Patel discloses the method of claim 1.
Although, Spangler discloses using cryptographic key to verify digital signature in Coln.7, lines 56-63, Morgan in view of Spangler and Patel does not explicitly disclose the limitation of
further comprising: generating the first cryptographic key; embedding the first cryptographic key in the first OS image; generating the second cryptographic key; embedding the second cryptographic key in the second OS image.
SAURAV discloses generating a first cryptographic key; embedding the first cryptographic key in the first OS image; generating a second cryptographic key; embedding the second cryptographic key in the second OS image (¶0032, FIG. 2A, “…SEP 112 may generate a root key and use the root key to generate keys at a first level of the tree. SEP 112 may use the first level keys to generate keys for a second level of the tree, and so on…”), (¶0034-¶0036, Fig. 2A, wherein plurality of keys are embedded in various operating systems such as OS1, OS2, and OS3 respectively), (¶0026, “… SEP 112 may run an operating system such as iOS, watchOS, a real time operating system, an operating system for embedded systems”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Morgan, Spangler, and Patel to include the generation of cryptographic keys as disclosed by SAURAV and be motivated in doing so in order to safeguard the stored data against unauthorized access-SAURAV ¶0002 in parts.
This motivation is also applicable to claim 7.
Regarding claim 7, Morgan in view of Spangler and further in view of Patel discloses the method of claim 1.
However, Morgan in view of Spangler and Patel does not explicitly disclose wherein the first cryptographic key is associated with a first time window;
and the second cryptographic key is associated with a second time window.
SAURAV discloses wherein: the first cryptographic key is associated with a first time window; and the second cryptographic key is associated with a second time window (¶0023, “a computing device may include a plurality of operating system (OS) partitions, with each partition requiring a different key to access. Each OS partition may include a plurality of device services and/or applications, each of which may require a different key to access. Each service and/or application may in turn include a plurality of user accounts, each of which may require a different key to access”, wherein each OS partition of the plurality of partitions represents first time window, second time window, third time window, etc respectively. This is in consonant with applicant’s disclosure in ¶0038, ¶0039, and Figure 1, wherein time windows are represented by partitions), (¶0024, “…When a user wishes to access data secured by a key, the user may supply a credential to the SEP. If the credential is correct, the SEP can decrypt the key. The SEP can use secure, encrypted memory that is isolated from other computing device systems. Accordingly, the SEP can provide security for each partition, service, and/or user separately without allowing a user only authorized for one OS partition to gain access to another OS partition…”), (¶0034, “The OS level may include one or more keys for one or more OS instances for device 100. For example, OS 1 key 220 may be a key for an OS instance installed on a first partition of an SSD in file system 106. OS 2 key 240 may be a key for an OS instance installed on a second partition of the SSD in file system 106. OS 3 key 230 may be a key for an OS instance installed on an external hard drive in file system 106.”, wherein one or more Operating System instances are updates associated with the Operating Systems).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Morgan, Spangler, and Patel to include associating cryptographic keys to different operating systems partitions (time windows) as disclosed by SAURAV and be motivated in doing so in order to safeguard the stored data against unauthorized access-SAURAV ¶0002 in parts.
Claims 13-14 are rejected under 35 U.S.C. 103 as being unpatentable U.S. PGPub. No. 20220326941 to Nelson et al. (hereinafter Nelson) in view of US. Pat. No. 12210895 to Kaimal et al. (hereinafter Kailmal) and further in view of WO 2023005371 to WANG et al. (hereinafter WANG) NOTE: PDF of WANG reference is attached to this OC set documents.
Regarding claim 13, Nelson in view of Kaimal discloses the machine of claim 9.
However, Nelson in view of Kaimal does not explicitly disclose wherein the one or more processors are further to:
generate, based at least on the second system partition being updated, a hash associated with the second version of the OS; and
verify the second version of the OS based at least on the hash and a cryptographic key embedded within the OS image.
WANG discloses:
generate, based at least on the second system partition being updated, a hash associated with the second version of the OS (page 16, paragraph from paragraph 1, “the system upgrade installation package from version 1.1 to version 1.2 includes the full data of the static partition of version 1.2 and the hash value of the full data of the static partition of version 1.2. The device overwrites the full amount of data in the static partition of version 1.2 to the static partition (B). After the data is written, the device calculates the hash value of the data in the static partition (B), and checks the hash value of the data in the static partition (B) with the static partition of version 1.2 in the system upgrade installation package from version 1.1 to version 1.2 Whether the hash value of the full amount of data is consistent. If they are consistent, it means that the data is written successfully, and the subsequent operating system upgrade operation can be performed”); and
verify the second version of the OS based at least on the hash (page 16, paragraph from paragraph 1, “…After the data is written, the device calculates the hash value of the data in the static partition (B), and checks the hash value of the data in the static partition (B) with the static partition of version 1.2 in the system upgrade installation package from version 1.1 to version 1.2 Whether the hash value of the full amount of data is consistent. If they are consistent, it means that the data is written successfully, and the subsequent operating system upgrade operation can be performed”) and a cryptographic key embedded within the OS image (page 35, paragraphs 5 and 6, “In the upgrade process, the update engine executes S1420 to verify the operating system upgrade package. Specifically, verify whether the digital signature of the operating system upgrade package is legal, and confirm whether the operating system upgrade package is a legal upgrade package. After the operating system upgrade package passes the verification, the update engine executes S1421, and updates the data of the static partition (B) and the dynamic partition according to the operating system upgrade package, and modifies the device startup sequence. For details, refer to S520, S530, and S531”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s invention to modify the machine of Nelson and Kaimal to include verification of Operating System based on the hash as disclosed by WANG and be motivated in doing so in order to configure the operating system standard and ensure the integrity of the root file system-WANG page 2, paragraph 2 in parts.
The above motivation is also applicable to claim 14.
Regarding claim 14, Nelson in view of Kaimal and further in view of WANG discloses the machine of claim 13.
WANG further discloses wherein the verification of the second version of the OS comprises at least one of:
sending, to a system that verifies the second version of the OS, the hash and the cryptographic key, (page 34, paragraph 2, “The update package acquisition tool (update apk clent) obtains the status of the update engine (update engine) through binder communication. clent) transmits upgrade parameters to the update engine (for example, whether the current upgrade operation is a file update operation or a file storage operation), and triggers the update engine to enter the upgrade process. For the specific upgrade process, refer to S520-S551”), (page 16, paragraph from paragraph 1, “…After the data is written, the device calculates the hash value of the data in the static partition (B), and checks the hash value of the data in the static partition (B) with the static partition of version 1.2 in the system upgrade installation package from version 1.1 to version 1.2 Whether the hash value of the full amount of data is consistent. If they are consistent, it means that the data is written successfully, and the subsequent operating system upgrade operation can be performed”), (page 35, paragraphs 5 and 6, “In the upgrade process, the update engine executes S1420 to verify the operating system upgrade package. Specifically, verify whether the digital signature of the operating system upgrade package is legal, and confirm whether the operating system upgrade package is a legal upgrade package. After the operating system upgrade package passes the verification, the update engine executes S1421, and updates the data of the static partition (B) and the dynamic partition according to the operating system upgrade package, and modifies the device startup sequence. For details, refer to S520, S530, and S531”);
or sending, to the system, the hash signed using the cryptographic key
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s invention to modify the machine of Nelson, Kaimal, and WANG to include sending, to a system that verifies the second version of the OS, the hash and the cryptographic key as disclosed by WANG and be motivated in doing so in order to configure the operating system standard and ensure the integrity of the root file system-WANG page 2, paragraph 2 in parts.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. PGPub. No. 20150160936 to Morgan et al. (hereinafter Morgan) in view of U.S. Pat. No. 8819330 to Spangler et al. (hereinafter Spangler) and further in view of U.S. PGPub. No. 20220326941 to Nelson et al. (hereinafter Nelson) and further in view of U.S. PGPub. No. 20090124375 to Patel; Pravinkumar (hereinafter Patel) and further in view of US. Pat. No. 11720338 to Kludy; Thomas (hereinafter Kludy).
Regarding claim 2, Morgan in view of Spangler and further in view of Patel discloses the method of claim 1.
Morgan further discloses wherein: the first machine and the second machine are included in a cluster of machines (¶0051-¶0052, “…the installation tool 290 can transmit and/or install the migrated operating system image 296 to the selected one or more target clouds in the set of target clouds 234.”); and
However, Morgan in view of Spangler and Patel does not explicitly disclose the following limitations:
the first machine is caused to update using the first OS image within a threshold period of time from the second machine being caused to update using the second OS image;
updating the first machine after a threshold of time after the second machine is updated;
Nelson discloses the first machine is caused to update using the first OS image within a threshold period of time from the second machine being caused to update using the second OS image (¶0009, “The rollback option may be automatically executed when an indication that the second operating system is approved has not been received in a threshold period of time since the second operating system has been in use.”), (¶0085, “In some embodiments, the rollback option is automatically executed when an indication (e.g., user input) that the second operating system is approved has not been received within a threshold period of time (e.g., one hour, 24 hours, etc.) since the second operating system has been in use…”, this is an indication that the update should be carried out within a threshold of time).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Morgan, Spangler, and Patel to include causing updating of machines to occur within a threshold of time as disclosed by Nelson and be motivated in doing so in order to roll back to a previous version of the operating system at any suitable time if some aspect of the updated root file system volume snapshot is faulty-Nelson ¶0085 in parts.
However, Morgan in view of Spangler. Patel and Nelson does not explicitly disclose updating the first machine after a threshold of time after the second machine is updated as claimed.
Kludy discloses updating of another set machines within a threshold of time after updating a first set of machines (Col. 28, lines 60-67 – Col. 29, lines 1-25, “the orchestrate upgrade service may cause to deploy the sealed master image to a pool of machines or deployments—for example, to rollout to 10% of machines or users initially, and wait for a predetermined period of time that the machines or users report an error rate not exceeding a predetermined threshold. As such, the orchestrate upgrade service may cause to deploy the sealed master image to the remaining machines in the pool. In some embodiments, the rollout mechanism may be controlled by image update orchestrator 710, where image update orchestrator 710 may deploy the sealed master image to the machines…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Morgan, Spangler, Patel, and Nelson to include causing updating of the second machines to occur within a threshold of time after the first machines are updated as disclosed by Kludy and be motivated in doing so in order to make sure the error rate does not exceed a predetermined threshold-Kludy Col. 28, lines 60-67 – Col. 29, lines 1-25, in parts.
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. PGPub. No. 20150160936 to Morgan et al. (hereinafter Morgan) in view of U.S. Pat. No. 8819330 to Spangler et al. (hereinafter Spangler) and further in view of U.S. PGPub. No. 20090124375 to Patel; Pravinkumar (hereinafter Patel) and further in view of US.PGPub. No 20110087872 to Shah et al (hereinafter Shah).
Regarding claim 22, Morgan in view of Spangler and further in view of Patel discloses the processor of claim 19.
However, the combination of Morgan, Spangler, and Patel does not explicitly disclose the following limitation:
wherein the one or more processors are further to verify the one or more first hashes using the first cryptographic key and the one or more second hashes using the second cryptographic key comprises:
verifying, using the first cryptographic key, at least one of a first OS or a first root file system on the first standby partition based at least on the one or more first hashes received from the first machine; and verifying, using the second cryptographic key, at least one of a second OS or a second root file system on the second standby partition based at least on the one or more second hashes received from the second machine.
Shah discloses verifying, using the first cryptographic key, at least one of a first OS or a first root file system on the first standby partition based at least on the one or more first hashes received from the first machine; and verifying, using the second cryptographic key, at least one of a second OS or a second root file system on the second standby partition based at least on the one or more second hashes received from the second machine (¶0072-¶0073, “At block 640, the method 600 includes verifying an encrypted signature corresponding with a first portion of an operating-system kernel. The verification at block 640 may be accomplished using, for example, the second public-key and the second cryptographic hash algorithm. If the verification at block 640 is successful, the method 600 continues to block 650… At block 650, the method 600 includes verifying an encrypted signature corresponding with a second portion of the operating-system kernel. The verification at block 650 may be accomplished using, for example, a third public-key and a third cryptographic hash algorithm. The third public-key and the third cryptographic hash algorithm may be provided or indicated in the first portion of the operating-system kernel, which may be included in kernel information, such at the kernel information 510, as discussed above with respect to FIGS. 5A and 5B…”). See also ¶0010, ¶0013, ¶0014 to mention a few.
Thus, one of ordinary skill would have found it obvious before the effective filing date of applicant’s claimed invention to modify the processor of Morgan, Spangler, and Patel to include using system cryptographic key to verify operating systems as disclosed by Shah and be motivated in doing so in order to complete the boot process and transferred the control of a computing system implementing the verified boot process to an operating system-Shah ¶0073 in parts.
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 MUDASIRU K OLAEGBE whose telephone number is (571)272-2082. The examiner can normally be reached MON-FRI. 7.30AM-5.30PM.
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, Farid Homayounmehr can be reached at 5712723739. 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.
/MUDASIRU K OLAEGBE/Examiner, Art Unit 2495
/FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495
Prosecution Insights