DETAILED ACTION
Claims 1-20 are presented for examination.
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 .
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by
Grabowski et al. (US 2008/0120350).
[Claim 1] Grabowski discloses a method, comprising:
receiving a reimaging package, wherein the reimaging package includes an identical storage image of optical media (ISO) file (fig. 1; ¶¶ 103, 107-108; ¶ 13 – “The preferred embodiment of the invention is an intelligent desktop management solution, which is hereinafter referred to as "IDMS").”; ¶ 18 – “DMS accomplishes all of this by creating and maintaining a "persistent image" on the client device. The concept of a persistent image means that the computer is able to automatically repair itself and return to a stable operating environment after something disrupts, deletes or damages key files that control the essential functions that the user depends upon.”; ¶ 19 – “While IDMS is focused on providing auto-repair functionality as its core purpose, it also offers broader management capabilities. For instance, because it uses its own method for system imaging and software deployment, it eliminates the need for other products.”; ¶ 23 -- “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”);
loading the reimaging package to a non-volatile memory of a computing system that stores a first disk in the volatile memory based on the reimaging package (¶ 23 -- “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”; ¶¶ 97-98 – “[0097] Hardware detection: IDMS can detect ISA PnP and PCI devices, and provides full access to DM1 (SMBIOS) and CMOS through Rembo-C functions; and [0098] CD-Rom and Floppy mode: IDMS can be started from a floppy disk or a CD-Rom in places where PXE remote-boot is not available (The CD-Rom image can be customized to contain specific partition images or IDMS scripts).”);
adjusting a firmware of the computing system based on the preparation script (¶¶ 22-23 – “[0022] IDMS provides two client product types. The first client product type is a Single O/S, which allows a user to manage one operating system or one image per client. The second client product type is a Multi-O/S, which allows up to four different operating systems or images per client. The Multi-O/S allows the user to switch from one operating system to another with a simple reboot. It also allows multiple images of the same O/S on one client where more than one person might use a single machine (e.g., schools or other training environments). This version is also a huge time-saver in a QA environment where technicians are testing software against several operating systems and require a stable image for each test. [0023] During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.“);
performing a first power cycle of the computing system based on the reimaging package (¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”);
loading the reimaging package to a volatile memory of the computing system after the power cycle (¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”);
reimaging the computing system based on the ISO file loaded to the volatile memory of the computing system (¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”);
adjusting the firmware of the computing system based on ISO file, subsequent to reimaging the computing system (¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”; ¶ 24 – “This is accomplished by comparing each file of the O/S and applications to the files in the "perfect image". If there is a corrupted file, a missing file or an entire set of missing files, those damaged or missing files are simply replaced as the system is loading. The result is that when systems become unstable, the users need only to reboot their PCs. This ensures that every time the PC is rebooted it has a healthy 0/S and application set available so that the user can be productive. Often, a user won't even realize there was a problem because his system always reboots to a healthy environment.”); and
performing a second power cycle of the computing system (¶ 109 – “An exemplary embodiment for capturing usage-pattern data is illustrated in FIG. 3A and FIG. 3B. Usage data related to heterogeneous hardware is captured in process 208 using a hardware differential detection method, in which the client script 207 replaces the target operating systems shell with a program. The program then functions as a timer to run for a set period of time. When the timer expires, the program triggers a reboot or restart of the target operating system. In one embodiment, a timed interval allows the target operating system to run plug-and-play and hardware/software configuration routines for the individual target computer. After a reboot or restart, these changes are detected and stored as part of the target machine's unique profile on server 400 and/or a server surrogate (not shown) (such as a hidden cache of executable instructions and data on a target machine's hard drive).”; ¶ 110 – “Another example of capturing usage-pattern data related to heterogeneous hardware in process 208 uses a hardware differential detection method. Here, client script 207 replaces the target operating system shell with a program that runs after process 216. Client script 207 can be configured to function as the timeout. Alternatively, the program can do the following: (1) scan the operating system's process table and memory structures to detect, for example, the signatures associated with a running plug-and-play or hardware configuration process; (2) store the changes associated with the plug-and-play and hardware configuration process in a local or networked repository; and (3) reboot or restart the system once the process is complete.”; ¶ 125 – “Another method for capturing usage-pattern data related to heterogeneous hardware in process 208 can be embodied in a hardware differential detection method where the client script 207 replaces the target operating system shell with a program. This program runs concurrently and continuously with the target operating system, after process 216. The program can actually scan the operating system's process table and memory structures to detect the signatures associated with a running plug-and-play or hardware configuration process. If changes are detected, the program can store the changes associated with the plug-and-play and hardware configuration process in a local or networked repository. An example of such repositories includes the operating system vendor's database of configuration data. Once storage operations are complete, the program can trigger a reboot or restart or re-initialization of the system.”).
[Claim 2] Grabowski discloses wherein loading the reimaging package to the non-volatile memory of the computing system comprises:
determining a portion of the non-volatile memory to allocate to the reimaging package (¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”); and
loading the ISO file to the portion of the non-volatile memory (fig. 1; ¶¶ 103, 107-108; ¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”).
[Claim 3] Grabowski discloses communicating with an additional computing system based on the reimaging package of the computing system (fig. 1; ¶¶ 103, 107-108; ¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”).
[Claim 4] Grabowski discloses performing an integrity check of the reimaging package loaded to the non-volatile memory of the computing system before performing the power cycle (¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”).
[Claim 5] Grabowski discloses wherein performing the integrity check comprises performing a check sum operation (¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”).
[Claim 6] Grabowski discloses transmitting an alert based on the integrity check (¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.” Recordation of the checksum is an example of an alert, i.e., notification, based on the integrity check.).
[Claim 7] Grabowski discloses wherein the firmware is a basic input/output system (BIOS) of the computing system, wherein adjusting the firmware of the computing system comprises modifying a boot order of the BIOS (¶¶ 107-109 – “[0107] FIG. 2 is a schematic diagram showing an exemplary architecture of client-resident components 104 of system 100. Examples of the sequence of client-resident components 104 are as follows: Upon each reboot or restart of client 500, a client script is transmitted from server 400 via network 200. The client script becomes run client script process 207 as a pre-boot program, where client profile data 110 is loaded from server 400 to direct the decisions and actions of run client script process 207. [0108] Run client script process 207 initiates the capture of usage pattern information process 208, which references client profile data store 210. Run client script process 207 preferably captures usage-pattern data from a target machine's secondary storage device 211, or alternatively, other storage media. [0109] An exemplary embodiment for capturing usage-pattern data is illustrated in FIG. 3A and FIG. 3B. Usage data related to heterogeneous hardware is captured in process 208 using a hardware differential detection method, in which the client script 207 replaces the target operating systems shell with a program. The program then functions as a timer to run for a set period of time. When the timer expires, the program triggers a reboot or restart of the target operating system. In one embodiment, a timed interval allows the target operating system to run plug-and-play and hardware/software configuration routines for the individual target computer. After a reboot or restart, these changes are detected and stored as part of the target machine's unique profile on server 400 and/or a server surrogate (not shown) (such as a hidden cache of executable instructions and data on a target machine's hard drive).”; ¶ 139 – “If all repair or maintenance activities are complete, reapply client information process 215 initiates a boot to the target machine's main operating system process 216, terminating all control and influence of the system from the target machine. In this way the target machine is rendered in a usable state that corresponds to its actual dynamic uses.”; By replacing the target operation systems shell with client scripts and then triggering a reboot or restart, including for a set period of time, the client scripts (in effect) adjust a boot order of partitions. As seen in ¶¶ 23 and 33, the client scripts are run from local cache partitions. Further explained in that the IDMS “[u]tilizes the capability of performing file operation on un-partitioned space on the local hard disk to store local copies of files and IDMS data sets transferred from the server, in order to speed-up subsequent accesses to the same file (This feature dramatically improves performance when restoring the same operating system disk image several times on the same computer. Leaving some un partitions space on the hard disk for the local cache partition is strongly recommended when IDMS is used to restore an operating system every day, or at every boot (OS failure prevention by preemptive OS restoration)).” (¶ 54) In other words, running a partition with IDMS client script for a set period of time means that, at least temporarily, the partition with the IDMS client script is prioritized over certain pre-existing software that would often otherwise be used, but for possible issues (like file corruption). This is further discussed in ¶¶ 17-23.; ¶ 97 – “Hardware detection: IDMS can detect ISA PnP and PCI devices, and provides full access to DM1 (SMBIOS) and CMOS through Rembo-C functions”).
[Claim 8] Grabowski discloses wherein loading the ISO file to the non-volatile memory of the computing system that stores the first disk in the volatile memory comprises:
identifying an additional disk of a plurality of disks to load the reimaging package (fig. 1; ¶¶ 103, 107-108; ¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”; ¶¶ 97-98 – “[0097] Hardware detection: IDMS can detect ISA PnP and PCI devices, and provides full access to DM1 (SMBIOS) and CMOS through Rembo-C functions; and [0098] CD-Rom and Floppy mode: IDMS can be started from a floppy disk or a CD-Rom in places where PXE remote-boot is not available (The CD-Rom image can be customized to contain specific partition images or IDMS scripts).”); and
loading the reimaging package to the identified additional disk (fig. 1; ¶¶ 103, 107-108; ¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”; ¶¶ 97-98 – “[0097] Hardware detection: IDMS can detect ISA PnP and PCI devices, and provides full access to DM1 (SMBIOS) and CMOS through Rembo-C functions; and [0098] CD-Rom and Floppy mode: IDMS can be started from a floppy disk or a CD-Rom in places where PXE remote-boot is not available (The CD-Rom image can be customized to contain specific partition images or IDMS scripts).”).
[Claim 9] Grabowski discloses wherein the reimaging package includes a preparation script that is configured to adjust the firmware of the computing system (¶¶ 22-23 – “[0022] IDMS provides two client product types. The first client product type is a Single O/S, which allows a user to manage one operating system or one image per client. The second client product type is a Multi-O/S, which allows up to four different operating systems or images per client. The Multi-O/S allows the user to switch from one operating system to another with a simple reboot. It also allows multiple images of the same O/S on one client where more than one person might use a single machine (e.g., schools or other training environments). This version is also a huge time-saver in a QA environment where technicians are testing software against several operating systems and require a stable image for each test. [0023] During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.“; ¶¶ 107-108 – “[0107] FIG. 2 is a schematic diagram showing an exemplary architecture of client-resident components 104 of system 100. Examples of the sequence of client-resident components 104 are as follows: Upon each reboot or restart of client 500, a client script is transmitted from server 400 via network 200. The client script becomes run client script process 207 as a pre-boot program, where client profile data 110 is loaded from server 400 to direct the decisions and actions of run client script process 207. [0108] Run client script process 207 initiates the capture of usage pattern information process 208, which references client profile data store 210. Run client script process 207 preferably captures usage-pattern data from a target machine's secondary storage device 211, or alternatively, other storage media.”).
[Claim 10] Grabowski discloses a system comprising:
a first computing system configured to transmit a reimaging package (fig. 1; ¶¶ 103, 107);
a second computing system comprising a processor (fig. 1; ¶¶ 103, 107-108), wherein the second computing system is configured to:
receive a reimaging package, wherein the reimaging package includes an identical storage image of optical media (ISO) file (fig. 1; ¶¶ 103, 107-108; ¶ 13 – “The preferred embodiment of the invention is an intelligent desktop management solution, which is hereinafter referred to as "IDMS").”; ¶ 18 – “DMS accomplishes all of this by creating and maintaining a "persistent image" on the client device. The concept of a persistent image means that the computer is able to automatically repair itself and return to a stable operating environment after something disrupts, deletes or damages key files that control the essential functions that the user depends upon.”; ¶ 19 – “While IDMS is focused on providing auto-repair functionality as its core purpose, it also offers broader management capabilities. For instance, because it uses its own method for system imaging and software deployment, it eliminates the need for other products.”; ¶ 23 -- “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”);
load the reimaging package to a non-volatile memory of a computing system that stores a first disk in the volatile memory based on the reimaging package (¶ 23 -- “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”; ¶¶ 97-98 – “[0097] Hardware detection: IDMS can detect ISA PnP and PCI devices, and provides full access to DM1 (SMBIOS) and CMOS through Rembo-C functions; and [0098] CD-Rom and Floppy mode: IDMS can be started from a floppy disk or a CD-Rom in places where PXE remote-boot is not available (The CD-Rom image can be customized to contain specific partition images or IDMS scripts).”);
adjust a firmware of the computing system based on the preparation script (¶¶ 22-23 – “[0022] IDMS provides two client product types. The first client product type is a Single O/S, which allows a user to manage one operating system or one image per client. The second client product type is a Multi-O/S, which allows up to four different operating systems or images per client. The Multi-O/S allows the user to switch from one operating system to another with a simple reboot. It also allows multiple images of the same O/S on one client where more than one person might use a single machine (e.g., schools or other training environments). This version is also a huge time-saver in a QA environment where technicians are testing software against several operating systems and require a stable image for each test. [0023] During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.“);
perform a first power cycle of the computing system based on the reimaging package (¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”);
load the reimaging package to a volatile memory of the computing system after the power cycle (¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”);
reimage the computing system based on the ISO file loaded to the volatile memory of the computing system (¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”);
adjust the firmware of the computing system based on ISO file, subsequent to reimaging the computing system (¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”; ¶ 24 – “This is accomplished by comparing each file of the O/S and applications to the files in the "perfect image". If there is a corrupted file, a missing file or an entire set of missing files, those damaged or missing files are simply replaced as the system is loading. The result is that when systems become unstable, the users need only to reboot their PCs. This ensures that every time the PC is rebooted it has a healthy 0/S and application set available so that the user can be productive. Often, a user won't even realize there was a problem because his system always reboots to a healthy environment.”); and
perform a second power cycle of the computing system (¶ 109 – “An exemplary embodiment for capturing usage-pattern data is illustrated in FIG. 3A and FIG. 3B. Usage data related to heterogeneous hardware is captured in process 208 using a hardware differential detection method, in which the client script 207 replaces the target operating systems shell with a program. The program then functions as a timer to run for a set period of time. When the timer expires, the program triggers a reboot or restart of the target operating system. In one embodiment, a timed interval allows the target operating system to run plug-and-play and hardware/software configuration routines for the individual target computer. After a reboot or restart, these changes are detected and stored as part of the target machine's unique profile on server 400 and/or a server surrogate (not shown) (such as a hidden cache of executable instructions and data on a target machine's hard drive).”; ¶ 110 – “Another example of capturing usage-pattern data related to heterogeneous hardware in process 208 uses a hardware differential detection method. Here, client script 207 replaces the target operating system shell with a program that runs after process 216. Client script 207 can be configured to function as the timeout. Alternatively, the program can do the following: (1) scan the operating system's process table and memory structures to detect, for example, the signatures associated with a running plug-and-play or hardware configuration process; (2) store the changes associated with the plug-and-play and hardware configuration process in a local or networked repository; and (3) reboot or restart the system once the process is complete.”; ¶ 125 – “Another method for capturing usage-pattern data related to heterogeneous hardware in process 208 can be embodied in a hardware differential detection method where the client script 207 replaces the target operating system shell with a program. This program runs concurrently and continuously with the target operating system, after process 216. The program can actually scan the operating system's process table and memory structures to detect the signatures associated with a running plug-and-play or hardware configuration process. If changes are detected, the program can store the changes associated with the plug-and-play and hardware configuration process in a local or networked repository. An example of such repositories includes the operating system vendor's database of configuration data. Once storage operations are complete, the program can trigger a reboot or restart or re-initialization of the system.”).
[Claim 11] Grabowski discloses wherein the second computing system is configured to load the ISO file to the non-volatile memory by generating a new partition in the non-volatile memory (¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”; ¶ 54 – “Utilizes the capability of performing file operation on un-partitioned space on the local hard disk to store local copies of files and IDMS data sets transferred from the server, in order to speed-up subsequent accesses to the same file (This feature dramatically improves performance when restoring the same operating system disk image several times on the same computer. Leaving some un partitions space on the hard disk for the local cache partition is strongly recommended when IDMS is used to restore an operating system every day, or at every boot (OS failure prevention by preemptive OS restoration)).”; ¶ 64 – “On the fly partitioning Rembo-C functions”; ¶ 98 – “CD-Rom and Floppy mode: IDMS can be started from a floppy disk or a CD-Rom in places where PXE remote-boot is not available (The CD-Rom image can be customized to contain specific partition images or IDMS scripts).”).
[Claim 12] Grabowski discloses wherein the second computing system is configured to adjust the firmware by adjusting a boot order of partitions that causes the new partition to run before an existing partition of the computing system (¶¶ 107-109 – “[0107] FIG. 2 is a schematic diagram showing an exemplary architecture of client-resident components 104 of system 100. Examples of the sequence of client-resident components 104 are as follows: Upon each reboot or restart of client 500, a client script is transmitted from server 400 via network 200. The client script becomes run client script process 207 as a pre-boot program, where client profile data 110 is loaded from server 400 to direct the decisions and actions of run client script process 207. [0108] Run client script process 207 initiates the capture of usage pattern information process 208, which references client profile data store 210. Run client script process 207 preferably captures usage-pattern data from a target machine's secondary storage device 211, or alternatively, other storage media. [0109] An exemplary embodiment for capturing usage-pattern data is illustrated in FIG. 3A and FIG. 3B. Usage data related to heterogeneous hardware is captured in process 208 using a hardware differential detection method, in which the client script 207 replaces the target operating systems shell with a program. The program then functions as a timer to run for a set period of time. When the timer expires, the program triggers a reboot or restart of the target operating system. In one embodiment, a timed interval allows the target operating system to run plug-and-play and hardware/software configuration routines for the individual target computer. After a reboot or restart, these changes are detected and stored as part of the target machine's unique profile on server 400 and/or a server surrogate (not shown) (such as a hidden cache of executable instructions and data on a target machine's hard drive).”; ¶ 139 – “If all repair or maintenance activities are complete, reapply client information process 215 initiates a boot to the target machine's main operating system process 216, terminating all control and influence of the system from the target machine. In this way the target machine is rendered in a usable state that corresponds to its actual dynamic uses.”; By replacing the target operation systems shell with client scripts and then triggering a reboot or restart, including for a set period of time, the client scripts (in effect) adjust a boot order of partitions. As seen in ¶¶ 23 and 33, the client scripts are run from local cache partitions. Further explained in that the IDMS “[u]tilizes the capability of performing file operation on un-partitioned space on the local hard disk to store local copies of files and IDMS data sets transferred from the server, in order to speed-up subsequent accesses to the same file (This feature dramatically improves performance when restoring the same operating system disk image several times on the same computer. Leaving some un partitions space on the hard disk for the local cache partition is strongly recommended when IDMS is used to restore an operating system every day, or at every boot (OS failure prevention by preemptive OS restoration)).” (¶ 54) In other words, running a partition with IDMS client script for a set period of time means that, at least temporarily, the partition with the IDMS client script is prioritized over certain pre-existing software that would often otherwise be used, but for possible issues (like file corruption). This is further discussed in ¶¶ 17-23.).
[Claim 13] Grabowski discloses wherein the ISO file comprises an ISO preparation script configured to cause the ISO file to be loaded to the non-volatile memory (¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”).
[Claim 14] Grabowski discloses wherein the ISO file comprises an ISO boot script configured to cause the computing system to perform the second power cycle (¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”).
[Claim 15] Grabowski discloses wherein the second computing system is configured to communicate with an additional computing system after updating the reimaging package (fig. 1; ¶¶ 103, 107-108; ¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”).
[Claim 16] Grabowski discloses a method, comprising:
generating an ISO file comprising an ISO preparation script, a new system content, and an ISO boot script (¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”);
generating a preparation script, wherein the preparation script is configured to modify a boot order of a computing system, and wherein the preparation script is configured to cause the computing system to load the ISO file to a non-volatile memory of the computing system (fig. 1; ¶¶ 103, 107-108; ¶ 23 -- “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”; ¶¶ 97-98 – “[0097] Hardware detection: IDMS can detect ISA PnP and PCI devices, and provides full access to DM1 (SMBIOS) and CMOS through Rembo-C functions; and [0098] CD-Rom and Floppy mode: IDMS can be started from a floppy disk or a CD-Rom in places where PXE remote-boot is not available (The CD-Rom image can be customized to contain specific partition images or IDMS scripts).”; ¶¶ 107-109 – “[0107] FIG. 2 is a schematic diagram showing an exemplary architecture of client-resident components 104 of system 100. Examples of the sequence of client-resident components 104 are as follows: Upon each reboot or restart of client 500, a client script is transmitted from server 400 via network 200. The client script becomes run client script process 207 as a pre-boot program, where client profile data 110 is loaded from server 400 to direct the decisions and actions of run client script process 207. [0108] Run client script process 207 initiates the capture of usage pattern information process 208, which references client profile data store 210. Run client script process 207 preferably captures usage-pattern data from a target machine's secondary storage device 211, or alternatively, other storage media. [0109] An exemplary embodiment for capturing usage-pattern data is illustrated in FIG. 3A and FIG. 3B. Usage data related to heterogeneous hardware is captured in process 208 using a hardware differential detection method, in which the client script 207 replaces the target operating systems shell with a program. The program then functions as a timer to run for a set period of time. When the timer expires, the program triggers a reboot or restart of the target operating system. In one embodiment, a timed interval allows the target operating system to run plug-and-play and hardware/software configuration routines for the individual target computer. After a reboot or restart, these changes are detected and stored as part of the target machine's unique profile on server 400 and/or a server surrogate (not shown) (such as a hidden cache of executable instructions and data on a target machine's hard drive).”; ¶ 139 – “If all repair or maintenance activities are complete, reapply client information process 215 initiates a boot to the target machine's main operating system process 216, terminating all control and influence of the system from the target machine. In this way the target machine is rendered in a usable state that corresponds to its actual dynamic uses.”; By replacing the target operation systems shell with client scripts and then triggering a reboot or restart, including for a set period of time, the client scripts (in effect) adjust a boot order of partitions. As seen in ¶¶ 23 and 33, the client scripts are run from local cache partitions. Further explained in that the IDMS “[u]tilizes the capability of performing file operation on un-partitioned space on the local hard disk to store local copies of files and IDMS data sets transferred from the server, in order to speed-up subsequent accesses to the same file (This feature dramatically improves performance when restoring the same operating system disk image several times on the same computer. Leaving some un partitions space on the hard disk for the local cache partition is strongly recommended when IDMS is used to restore an operating system every day, or at every boot (OS failure prevention by preemptive OS restoration)).” (¶ 54) In other words, running a partition with IDMS client script for a set period of time means that, at least temporarily, the partition with the IDMS client script is prioritized over certain pre-existing software that would often otherwise be used, but for possible issues (like file corruption). This is further discussed in ¶¶ 17-23.); and
assembling the ISO file and the preparation script to form a reimaging package (¶¶ 22-23 – “[0022] IDMS provides two client product types. The first client product type is a Single O/S, which allows a user to manage one operating system or one image per client. The second client product type is a Multi-O/S, which allows up to four different operating systems or images per client. The Multi-O/S allows the user to switch from one operating system to another with a simple reboot. It also allows multiple images of the same O/S on one client where more than one person might use a single machine (e.g., schools or other training environments). This version is also a huge time-saver in a QA environment where technicians are testing software against several operating systems and require a stable image for each test. [0023] During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.“; ¶¶ 107-108 – “[0107] FIG. 2 is a schematic diagram showing an exemplary architecture of client-resident components 104 of system 100. Examples of the sequence of client-resident components 104 are as follows: Upon each reboot or restart of client 500, a client script is transmitted from server 400 via network 200. The client script becomes run client script process 207 as a pre-boot program, where client profile data 110 is loaded from server 400 to direct the decisions and actions of run client script process 207. [0108] Run client script process 207 initiates the capture of usage pattern information process 208, which references client profile data store 210. Run client script process 207 preferably captures usage-pattern data from a target machine's secondary storage device 211, or alternatively, other storage media.”).
[Claim 17] Grabowski discloses transmitting the reimaging package to the computing system (fig. 1; ¶¶ 103, 107-108; ¶ 13 – “The preferred embodiment of the invention is an intelligent desktop management solution, which is hereinafter referred to as "IDMS").”; ¶ 18 – “DMS accomplishes all of this by creating and maintaining a "persistent image" on the client device. The concept of a persistent image means that the computer is able to automatically repair itself and return to a stable operating environment after something disrupts, deletes or damages key files that control the essential functions that the user depends upon.”; ¶ 19 – “While IDMS is focused on providing auto-repair functionality as its core purpose, it also offers broader management capabilities. For instance, because it uses its own method for system imaging and software deployment, it eliminates the need for other products.”; ¶ 23 -- “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”).
[Claim 18] Grabowski discloses receiving an indication that the computing system is ready for reimaging, and triggering the reimaging based on the indication (¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”; ¶ 109 – “When the timer expires, the program triggers a reboot or restart of the target operating system. In one embodiment, a timed interval allows the target operating system to run plug-and-play and hardware/software configuration routines for the individual target computer. After a reboot or restart, these changes are detected and stored as part of the target machine's unique profile on server 400 and/or a server surrogate (not shown) (such as a hidden cache of executable instructions and data on a target machine's hard drive).”; ¶ 125 – “If changes are detected, the program can store the changes associated with the plug-and-play and hardware configuration process in a local or networked repository. An example of such repositories includes the operating system vendor's database of configuration data. Once storage operations are complete, the program can trigger a reboot or restart or re-initialization of the system.”; ¶ 134 – “The hash represents specific second or tick when an application is to be disabled and removed from the healing or repair function in process 215. During subsequent reboot or restarts or maintenance cycles, the hash is compared to the system time and triggered actions are taken. The specific actions taken may depend selection of modes and methods to restore usage-pattern data.”).
[Claim 19] Grabowski discloses receiving an indication that the computing has been reimaged subsequent to receiving the indication (¶ 125 – “Another method for capturing usage-pattern data related to heterogeneous hardware in process 208 can be embodied in a hardware differential detn method where the client script 207 replaces the target operating system shell with a program. This program runs concurrently and continuously with the target operating system, after process 216. The program can actually scan the operating system's process table and memory structures to detect the signatures associated with a running plug-and-play or hardware configuration process. If changes are detected, the program can store the changes associated with the plug-and-play and hardware configuration process in a local or networked repository. An example of such repositories includes the operating system vendor's database of configuration data. Once storage operations are complete, the program can trigger a reboot or restart or re-initialization of the system.”; ¶ 139 – “If all repair or maintenance activities are complete, reapply client information process 215 initiates a boot to the target machine's main operating system process 216, terminating all control and influence of the system from the target machine. In this way the target machine is rendered in a usable state that corresponds to its actual dynamic uses.”).
[Claim 20] Grabowski discloses wherein ISO preparation script is configured to cause the ISO file to be loaded to the non-volatile memory (¶ 23 – “During pre-boot, IDMS detects and self-repairs problem files or registry settings. This means that, by simply rebooting the PC, an end-user can automatically resolve O/S or application file corruption, thereby eliminating calls to the helpdesk. To implement this capability, an IT administrator creates a "perfect image" of the 0/S and application files to be automatically self-repaired and supported by IDMS. This image is then compressed with a reversible algorithm and a MD5 hash is generated for the entire compressed image. The image and associated checksum are then stored on both a server and in a local cache (hidden partition) on the local client disk drive. Each time the client device is rebooted, the automatic self-repair of files is done by comparing the hard disk content with the content of an image stored on the local cache partition (or the server), and then restoring only the files that need to be restored. Most importantly, the "perfect image" and the unique profile of the machine type automatically adapt over time to conditions unknown or unforeseen by the IT administrator, creating not only a self-repair capability, but a self-managing feature as well.”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Cheng et al. (US 2024/0338452) – Discusses changing the sequence in which BIOS modules are provided if an error condition is detected (¶ 4).
Childs et al. (US 2009/0217024) – Explains that BIOS settings may be altered while the computer system is performing pre-boot operations.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUSANNA M DIAZ whose telephone number is (571)272-6733. The examiner can normally be reached M-F, 8 am-4:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Brian Epstein can be reached at (571) 270-5389. 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.
/SUSANNA M. DIAZ/
Primary Examiner
Art Unit 3625A
Prosecution Insights