U.S. patent application number 12/023425 was filed with the patent office on 2008-05-22 for system and method for management of end user computing devices.
This patent application is currently assigned to Persystent Technology Corporation. Invention is credited to Joseph D. Grabowski, Dhaval Patel, Thomas A. Sturgeon.
Application Number | 20080120350 12/023425 |
Document ID | / |
Family ID | 39418175 |
Filed Date | 2008-05-22 |
United States Patent
Application |
20080120350 |
Kind Code |
A1 |
Grabowski; Joseph D. ; et
al. |
May 22, 2008 |
System and Method for Management of End User Computing Devices
Abstract
A system and method is provided for the repair of operating
system and application binary files and configuration data files at
pre-operating system boot stage by comparing attributes of the
files against a reference collection of such files stored on a
server during each reboot or restart cycle while creating and
restoring a collection of dynamic operating system binary files,
configuration data files, file system structures and hardware
system attributes unique to the configuration and use of the system
on a server for subsequent pre-operating system repair
operations.
Inventors: |
Grabowski; Joseph D.;
(Sanford, FL) ; Patel; Dhaval; (Lake Mary, FL)
; Sturgeon; Thomas A.; (Sorrento, FL) |
Correspondence
Address: |
PILLSBURY WINTHROP SHAW PITTMAN, LLP
P.O. BOX 10500
MCLEAN
VA
22102
US
|
Assignee: |
Persystent Technology
Corporation
Tampa
FL
|
Family ID: |
39418175 |
Appl. No.: |
12/023425 |
Filed: |
January 31, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10290240 |
Nov 8, 2002 |
|
|
|
12023425 |
Jan 31, 2008 |
|
|
|
60331192 |
Nov 9, 2001 |
|
|
|
Current U.S.
Class: |
1/1 ;
707/999.202; 707/E17.001; 707/E17.01 |
Current CPC
Class: |
G06F 16/10 20190101 |
Class at
Publication: |
707/202 ;
707/E17.001 |
International
Class: |
G06F 17/30 20060101
G06F017/30 |
Claims
1. A method for repairing a client having a damaged usage
collection of files, the damaged usage collection of files
comprising operating system files, application binary files, and
configuration data files, at a pre-operating system boot stage of
the client, comprising: generating a repaired usage collection of
files based on a dynamic reference collection of files that was
generated during a previous boot stage, wherein the dynamic
reference collection of files accounts for actual dynamic uses of
the operating system corresponding to the previous boot stage;
repairing the damaged usage collection of files based on the
repaired usage collection of files; whereby the repaired usage
collection of files restores the operating system to an actual
dynamic use of the operating system corresponding to the damaged
usage collection of files before damage occurred.
2. The method of claim 1, wherein generating the repaired usage
collection of files based on a dynamic reference collection of
files comprises using the dynamic reference collection of files as
the repaired usage collection of files.
3. The method of claim 1, wherein generating a repaired usage
collection of files further comprises comparing a reference
collection of files stored on a server against the dynamic
reference collection of files, wherein the static reference
collection of files corresponds to a state of the client before
actual dynamic uses of the operating system.
4. The method of claim 3, wherein the reference collection of files
is stored on one or both of a hidden cache of the client and a
server in communication with the client.
5. A computer readable medium storing computer executable
instructions for repairing a client having a damaged usage
collection of files, the damaged usage collection of files
comprising operating system files, application binary files, and
configuration data files, at a pre-operating system boot stage of
the client, the instructions operable when executed to: generate a
repaired usage collection of files based on a dynamic reference
collection of files that was generated during a previous boot
stage, wherein the dynamic reference collection of files accounts
for actual dynamic uses of the operating system corresponding to
the previous boot stage; repair the damaged usage collection of
files based on the repaired usage collection of files; whereby the
repaired usage collection of files restores the operating system to
an actual dynamic use of the operating system corresponding to the
damaged usage collection of files before damage occurred.
6. The computer readable medium of claim 5, further operable use
the dynamic reference collection of files as the repaired usage
collection of files to generate the repaired usage collection of
files based on a dynamic reference collection of files.
7. The computer readable medium of claim 5, further operable to
compare a reference collection of files stored on a server against
the dynamic reference collection of files, wherein the static
reference collection of files corresponds to a state of the client
before actual dynamic uses of the operating system to generate a
repaired usage collection of files further comprises.
8. The computer readable medium of claim 7, wherein the reference
collection of files is stored on one or both of a hidden cache of
the client and a server in communication with the client.
9. A system for repairing a client having a damaged usage
collection of files, the damaged usage collection of files
comprising operating system files, application binary files, and
configuration data files, at a pre-operating system boot stage of
the client, the system comprising one or more processing devices
collectively operable to: generate a repaired usage collection of
files based on a dynamic reference collection of files that was
generated during a previous boot stage, wherein the dynamic
reference collection of files accounts for actual dynamic uses of
the operating system corresponding to the previous boot stage;
repair the damaged usage collection of files based on the repaired
usage collection of files; whereby the repaired usage collection of
files restores the operating system to an actual dynamic use of the
operating system corresponding to the damaged usage collection of
files before damage occurred.
10. The system of claim 9, further operable use the dynamic
reference collection of files as the repaired usage collection of
files to generate the repaired usage collection of files based on a
dynamic reference collection of files.
11. The system of claim 9, further operable to compare a reference
collection of files stored on a server against the dynamic
reference collection of files, wherein the static reference
collection of files corresponds to a state of the client before
actual dynamic uses of the operating system to generate a repaired
usage collection of files further comprises.
12. The system of claim 11, wherein the reference collection of
files is stored on one or both of a hidden cache of the client and
a server in communication with the client.
Description
CROSS REFERENCE TO RELATED APPLICATION
[0001] This application is a divisional application of co-pending
U.S. patent application Ser. No. 10/290,240, filed Nov. 8, 2002,
which claims the benefit of U.S. Provisional Patent Application No.
60/331,192, filed Nov. 9, 2001, both of which are incorporated by
reference in their entirety.
FIELD OF INVENTION
[0002] The present invention relates generally to systems and
methods for providing improved maintenance of computing systems.
More particularly, the present invention relates to a system and
method for providing improved support and maintenance functions for
end user computer systems.
BACKGROUND OF INVENTION
[0003] There are many tasks associated with managing a computer
system. Such tasks are required regardless of whether the computer
system is a network of interconnected computers or a standalone
computing system. Moreover, such tasks are required regardless of
whether the computer system includes equipment associated with
remote and wireless applications.
[0004] One of these tasks relates to repairs of lost, damaged, or
modified files, which render the computer system in a state where
it cannot achieve its purpose in the context of the organization
for which it exists. Such repairs often require the application of
additional software, a knowledgeable technician, or even a group of
technicians to work on the computer system. Repairs and maintenance
consume valuable resources, including time, office resources, and
human resources.
[0005] Alternative means for implementing repairs on computer
systems, other than allocating technicians to the repair system,
are often difficult to implement, costly and potentially
destructive to user data. Known support and maintenance systems do
not take into account changes to the computer system since its
initial installation, its last period of maintenance, or changes to
the system due to user, network, or peripheral initiated
events.
[0006] Moreover, known software-based techniques for providing
maintenance and repairs typically require the target operating
system to be functioning, which may be impossible if, as is often
the case, the target operating system is not functioning. In that
situation, effecting repairs is very difficult. Also, if the target
operating system was running when a problem occurred, files or data
that needed to be repaired or updated might be locked, thus
preventing maintenance. Another problem occurs when the target
operating system requires the use of non-optimized methods of
network and storage access. This would slow activities related to
deployment, update, and repair.
[0007] Accordingly, there is a need for a product to address both
existing and emerging challenges in the management of end user
computing devices. More specifically, there is a need for a system
and method that restores (self-repairs) a computer system in the
event of software failure due to user error, introduction of virus,
system crash, or other problem. The product should provide dramatic
improvements for IT managers in terms of cost reduction and user
satisfaction while allowing them to apply their efforts to more
strategic and value-added initiatives by minimizing support calls
and stabilizing their environment.
SUMMARY OF THE INVENTION
[0008] The present invention provides a method that satisfies a
need of many computer users to better manage their computing
devices. A preferred embodiment of the invention is a method for
managing end user computing devices. The method includes the
following steps. First, a reference collection of files associated
with an operating system of a client is created. Preferably, the
reference collection of files includes application binary files and
configuration data files. Second, the reference collection is
stored on a server, which is in communication with the client. The
reference collection may also be stored on a hidden cache of the
client. Third, attributes of application binary files and
configuration data files of the client are compared against the
reference collection during a reboot cycle of the client. Fourth,
stored instructions and files are ensured that they are capable of
bringing the operating system of the client to a usable state.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] FIG. 1 is a schematic diagram showing an exemplary
architecture of an embodiment of the invention.
[0010] FIG. 2 is a schematic diagram showing an exemplary
architecture of client-resident components of a system according to
an embodiment of the invention.
[0011] FIGS. 3A and 3B are collectively a schematic diagram showing
examples of the capture of plug-and-play or hardware usage-pattern
data using a hardware differential data countdown according to one
embodiment of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0012] Preferred embodiments of the invention is described below
and schematically illustrated in the drawings. The description and
drawings are only for the purpose of illustration and as an aid to
understanding the invention. The description and drawings provided
herein are not intended as a definition of the limits of the
invention.
[0013] The preferred embodiment of the invention is an intelligent
desktop management solution, which is hereinafter referred to as
"IDMS"). IDMS provides a simple, transparent, and non-disruptive
approach to user support.
[0014] IDMS delivers the following functions. First, IDMS recovers
client computers which have crashed. The client computers could
crash due to a number of reasons. For example, client computers
could crash due to operating system failure, application crashes,
or crashes due to viruses or hacking. To recover his system, all a
user needs to do is reboot his computer. IDMS takes care of the
repair and does it automatically and transparently. No other action
on the part of the user or from technical support is required.
[0015] Second, IDMS works on networked computers (clients) that
become standalone. For example, IDMS can work on notebook computers
that are taken on business trips. When a networked client computer
is not connected to a network and a problem is experienced, the
auto-repair process does not require any type of network connection
or access to any other system. All that is required is a reboot of
the computer. IDMS provides the only known method that can resolve
problems of this type without any involvement of the support line,
technical support personnel, or the end-user (other than initiating
a reboot on the device).
[0016] Third, IDMS helps quarantine and minimize damage from
viruses and hacker attacks. IDMS provides an easy way for users to
rapidly recover from viruses or damage from hacker attacks while
enabling the organization to prevent broader impacts to shared
computing resources. Common viruses that attack operating system
and application files can be easily contained by simply asking
users to reboot and immediately run their anti-virus software
and/or delete the offending e-mail/file.
[0017] Fourth, IDMS provides advanced deployment of applications,
operating systems and update capabilities over the network, from
the server to the client. For example, a migration from Windows
2000 to Windows XP can be executed in fewer than 10 minutes. It is
noted that IDMS deploys software in a way that it does not diminish
the system's workings in the context of the organization,
structure, or operating environment in which it exists. There are a
number of existing products that can deploy an operating, but do so
in a manner that ignores context and the ramifications of future
maintenance and self-repairing. An architecture of IDMS enables
network administrators to add incremental items to software images
previously built and deployed to clients. This eliminates the need
to create an entirely new image for each combination or permutation
of the device's context (as is required by many competitor's
deployment solutions).
[0018] IDMS 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. A disruption often
occurs due to user error. Sometimes it can result from addition of
new software that causes conflicts with the pre-existing software.
And, increasingly, the disruption can come from malicious actions
by computer hackers and the effects of computer viruses. Having a
persistent image means that a PC--or any other computer device--can
be restored to normal operation immediately by simply powering off
and back on. Every time the device boots, IDMS executes a pre-boot
sequence that automatically repairs any damage that has occurred
since the previous boot.
[0019] 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.
[0020] Moreover, IDMS offers important assistance in the security
and disaster recovery arenas. IDMS ensures that no permanent harm
is done when key system operations are temporarily disrupted,
whether by natural disaster, hardware failure, software crashes,
viruses, or hacker attacks.
[0021] IDMS has been successfully adapted to work on desktop and
portable PCs running Windows 9x, NT4.0, Windows 2000, Windows XP,
and Linux. In addition, IDMS can be adapted to work on a Windows CE
version to support the Compaq iPAQ and other CE-based systems,
including CE-based embedded systems.
[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.
[0024] 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.
[0025] IDMS has the following feature/function capabilities: [0026]
Enable Server-Based Image Multicasting by using mTFTP to push
software images from the IDMS server to the workstation, reducing
the demand on network bandwidth and eliminating visits to the
desktop or other user device; [0027] Compress image files by 50% on
average to further reduce network traffic; [0028] Streamline the
deployment of operating systems, application updates, and user
settings to desktop and mobile workforces; [0029] Allow IT managers
to remotely image any Windows workstation. The central console can
also be used to quickly deploy whole application packages or
specific PC changes such as registry changes or desktop settings;
[0030] Accelerate migration to Windows 2000 and Windows XP.TM.;
[0031] Enable customized deployment of software or operating
systems to a specific department or groups; [0032] Allow three
levels of O/S and application management and security; [0033]
Support multiple partitions, with up to four Operating Systems on
the same unit; [0034] Self-repair the most critical
files--including NTDetect, NTLDR, and NT Registry settings, or any
other corrupted system or application file; [0035] Maintain user
data and custom settings after an automatic self-repair operation;
[0036] Fully Support laptop users with intelligent capabilities
while they are disconnected from the network; and [0037] Take full
advantage of Intel's pre-boot execution environment (PXE)
technology to further automate the deployment of 0/S and
application images. [0038] A preferred IDMS server of has the
following minimum requirements: [0039] Pentium III (minimum)
processor, 5 12 MB RAM (If more than 250 concurrent users, scale as
appropriate); [0040] Disk Storage requirements are based on the
number of base images and packages; [0041] Network Operating System
Windows NT, Windows 2000 Server, or Linux; and [0042] DHCP Server
installed locally or on another server available on the network
remotely. [0043] A preferred IDMS client has the following minimum
requirements: [0044] Personal computer 300 MHz, 6 GB hard disk, 64
MB RAM; [0045] PXE-enabled network adapter or PXE boot diskette;
and [0046] A DHCP server installed on the network is required.
[0047] In addition, IDMS is adapted to offer the following core
features: [0048] The IDMS management platform includes a virtual
machine (VM) for executing compiled programs (i.e. scripts), a
graphical interface to interact with the user, utilization of
low-level hard disk access for
imaging/restoring/auto-repairing/customizing operating systems and
finally a network interface through the PXE boot-rom; [0049]
Management tasks can be performed either interactively (with GUI
wizards, or by entering commands at the interactive prompt), or in
scripts containing command line statements; [0050] Powerful but
easy-to-use programming language (e.g., Rembo-C, the syntax of
which is similar to JavaScript and PHP); [0051] Virtual machine
(VM) executing Rembo-C compiled epodes (RBX), e.g., the Virtual
Machine is multi-threaded, and supports structured exception
handlers; [0052] On-the-fly compiler to interactively compile
Rembo-C statements into VM opcodes; [0053] Hard-disk buffering
engine (like smartdrive); and [0054] 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)). [0055]
Preferably, IDMS provides the following graphical interface
features: [0056] Hypertext-based graphical user interface, with a
visual programming language-like event handlers for executing IDMS
statements when an action is triggered by the user; [0057] 16 bits
display (32768 colors) or 256 colors video mode, all standard VESA
modes supported; [0058] Pointing devices, including, but not
limited to Serial, USB, PS/2 mice supported (including wheel mice);
[0059] All the graphical interface objects are mapped to abstract
variables/objects or Document Object Model Constructs or interface
element object hierarchy, so that any object on the screen can be
modified interactively or in scripts; and [0060] 256 colors PCX
image format support. A variety of graphics formats can be used to
create display elements, including PCX, JPEG, PNG or future formats
as available. [0061] Preferably, IDMS offers the following file
system features: [0062] File-based support for FAT12, FAT16,
BIGDOS, FAT32, EXT2FS, LINUXSWAP, NTFS (NT4.0) and NTFS (Win2K);
[0063] NTFS limitations (1 DMS cannot decrypt files encrypted with
Win2K encryption keys, and cannot access NTFS compressed files);
[0064] On the fly partitioning Rembo-C functions; [0065] File-based
functions (to read, write, copy, delete, rename, move files and
directories); [0066] Auto-repairing; [0067] Guaranteed application
availability on every desktop that proactively corrects file and
configuration related issues before the end user knows there's a
problem; and [0068] Repair of deleted files, overwritten DLL's,
incorrect file versions, corrupted registries and more
(Auto-repairing runs during pre-boot so even critical boot files
are protected. Unlike similar auto-repairing technologies, IDMS
replaces the necessary files, without overwriting the entire
application or user data). [0069] Preferably, IDMS offers the
following OS deployment: [0070] Utilization of Image Creation and
Image restoration of operating system disk images (An image
corresponds to a collection of files, with no requirement on the
source used to build the image, i.e., a user can create an image
containing 50% of NTFS files and 50% of FAT16 files); [0071]
Compressed partition images (Images can be browsed directly from
the IDMS client); [0072] Support for partition image size of 100
GB; [0073] Utilization of Virtual images (A Virtual lineage is an
exact copy of a file system's structure, but without copying the
files content. A user can remove a directory in a virtual image
without actually removing the directory on the disk. Virtual images
are useful for pruning unwanted files/directories on image
creation, and for merging images together on restoration (e.g. to
restore a base image+a software image)); [0074] Unlimited
differential imaging (create a differential of images, and restore
combinations of base+differential images); [0075] File based
cloning, allowing auto-repairing operations (Auto-repairing is done
by comparing the hard-disk content with the content of an image
stored on the server (or the local cache partition), and restore
only the files that need to be restored. In auto-repairing mode, a
NT workstation can be restored to a safe state in less than 10
seconds); and [0076] Unlimited post-configuration (The low-level
file system access implemented in IDMS, combined with the Rembo-C
programming language makes OS configuration very easy).
[0077] Preferably, IDMS offers the following OS Specific features:
[0078] Utilization of Low-level access to NT registry files
(Windows NT4.0 & 2000) from IDMS (The Windows Registry is
handled as a file system, thus making possible to create basic
images and differential images of the registry as for hard disk
images. This is a very useful feature for software deployment);
[0079] Compatible with Microsoft's System Preparation Tool
(SysPrep); [0080] SD (NT's system identifier) re-generation
functions; and [0081] Linux kernel boot module (like LILO),
including support for large initial ram disk.
[0082] Preferably, IDMS offers the following network features:
[0083] Proprietary IP implementation, designed for performance,
with UDP based proprietary protocols; [0084] NETfs, unicast file
transfer protocol used to transfer files from and to the IDMS
server; [0085] Utilization of MCAST, multicast file transfer
protocol (server to clients), using adaptive timeouts and windows
(about 5-10 times faster than MTFTP, a standard protocol for
multicast file transfers) or any type of broadcast protocol; [0086]
The MCAST protocol does not require any kind of synchronization
between the clients--soft synchronization (Therefore, no manual
intervention is required to rollout hundreds of PCs if MCAST is
combined with Wake-On Lan (power-on computers remotely)); [0087]
The FAST protocol, unicast window-based protocol, used to send
files to the server; [0088] Communications between the server and
the client are encrypted using strong encryption standards; [0089]
All protocols are failure-prone: they will reconnect to a server
even if the server was restarted; [0090] Backup servers are
supported: the clients can switch to the backup server in the
middle of a transfer if the primary 1 DMS server has failed; [0091]
Access to TCP services through a special tunneling mechanism;
[0092] SMTP support (send emails with IDMS); and [0093] Complete
(read and write) database access, using ODBC.
[0094] Preferably, IDMS offers the following miscellaneous
features: [0095] Remote Console: IDMS client display can be
controlled from a remote location with an IDMS Remote Console
application (Communications between the IDMS client and the Remote
Console are compressed and encrypted); [0096] Authentication:
Windows NT, Unix (passwd), NIS/NIS+, and RADIUS (for any other
server) authentication protocols are supported by IDMS to
authenticate a user (e.g. to grant access to the computer based on
the identity of the user); [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).
[0099] Preferably, during pre-boot, IDMS automatically restores the
client's machine based on one of the following selectable lock down
modes: [0100] Mode 1--Full Lock-Down--Restore base image and
incremental(s) but do not preserve user's desktop settings, data in
My Documents, or any applications that are not installed with IDMS.
Note: During the auto-heal process data located in private folders
(i.e. c:\work) remains intact. [0101] Mode 2--No Lock-Down--Restore
base image and incremental(s) but preserve user's desktop settings,
data in My Documents, and any applications that are not installed
with TDMS. [0102] Mode 3--Semi Lock-Down--Restore base image and
incremental(s) but preserve user's desktop settings, data in My
Documents and do not preserve any applications that are not
installed with IDMS.
[0103] FIG. 1 is a schematic diagram showing an exemplary
architecture of an embodiment of IDMS. System 100 of the invention
includes server-resident components 102 and client-resident
components 104 (see FIG. 2). As shown in FIG. 1, server-resident
components 102, which resides at server 400, include client profile
data 110, client usage pattern data 120, and reference collection
data 130. Client-resident components 104 residing at client 500,
which is one of clients 101, 103, 105, 107, 109, and 111, are
illustrated in FIG. 2 and is discussed below.
[0104] Server 400 stores or indexes the storage of client profile
data 110. Server 400 also includes client usage pattern data 120,
which is coupled to each client profile data 110.
[0105] Client usage pattern data 120 is also coupled to reference
collection data 130. Via network 200, server 400 is in
communication with one or more target machines 101, 103, 105, 107,
109, and nth target machine 111 (collectively client 500). Client
500 receives from or transmits to server 400 instructions and
usage-pattern data. The instructions and usage-pattern data are
exchanged according to the instructions given to client-resident
components 104.
[0106] Client-resident components 104 include code in the native
instruction set of server 400, which is loaded into a client
machine's memory. The memory can be a physical memory, a paged
memory on a secondary storage, or scripts interpreted into machine
instructions by another client-resident component. Although only
one server is depicted in FIG. 1, two or more servers may represent
server 400.
[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).
[0110] 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.
[0111] The following is a representation of the code to substitute
the countdown timer as the operating system shell, according to one
embodiment of client script 207. TABLE-US-00001 /******
invention/reboot * NAME * reboot.c -- Program to insert reboot or
restart code into Windows NT/2000 * * INPUTS * None * BUGS * None
****** */ /****v* reboot /msgs * NAME * msgs * DESCRIPTION *
Displays what is being done on the user desktop * NOTES * None
****** */ str msgs; /****f* reboot/message * NAME * message *
DESCRIPTION * Displays the messages on the user desktop * SYNOPSIS
* message(str msg) * INPUTS * msg - a string which contains what is
being done * RETURN VALUE * None ****** */ void message(str msg){
// Output a message to the user printf("%s",msg); } /****f*
reboot/ForceReboot * NAME * ForceReboot or restart * DESCRIPTION *
Makes Computer reboot or restart again if it is w2k or win nt
writes shutdown.exe into registry * SYNOPSIS * ForceReboot (void) *
INPUTS * None * RETURN VALUE * None ****** */ void ForceReboot
(void) { if(TestFile("c:/WINNT")) {
Copy("server//global/plugins/shutdown.exe", "c: /");
if(TestFile("c://WINNT/system32/config/SOFTWARE")) { OpenHive
("reg", "c:/WINNT/system32/config/SOFTWARE"); str msgs = "Creating
Unicode File of shutdown.exe"; message (msgs); WriteUniToReg
("_reg/Microsoft/Windows NT/CurrentVersion/Winlogon/Shell.unicode",
"c:\\shutdown.exe /R /T:60 \"Completing invention Operations\"
/L"); CloseHive ("_reg"); } else { //Halt on failure and issue a
message CriticalError("Cannot open or modify the registry");
for(;;) { ) } } else if(TestFile ("c:/WINDOWS")) {
if(TestFile("server//utilities/shutdown.exe")){ Log("\nCopying
shutdown.exe to the Win9x workstation.\n"); Copy
("server//utilities /shutdown.exe", "c:/"); } else {
CriticalError("\nCannot find shutdown.exe file...Contact your
system administrator! \n"); for(;;) { } } } } /****f*
reboot/ResetReboot * NAME * ResetReboot * DESCRIPTION * Removes
shutdown.exe from registry registry * SYNOPSIS * ResetReboot (void)
* INPUTS * None * RETURN VALUE * None ****** */ void ResetReboot
(void) { if(TestFile("c:/WINNT")) { if(TestFile("c:/shutdown.exe"))
{ Delete("c:/shutdown.exe"); if(TestFile("c:
/WINNT/system32/config/SOFTWARE")) { OpenHive("_reg", "C:
/WINNT/system32/config/SOFTWARE"); WriteuniToReg ( "reg:
//reg/Microsoft/Windows NT/Current Version/Winlogon/Shell.unicode",
"Explorer.exe"); CloseHive ("_reg"); } } } else
if(TestFile("c:/WINDOWS")) { Log("\nCleaning up all of IDMS files
in Win9x \n"); if (TestFile ("c: /autoexec.bat")) { Delete("c:
/autoexec.bat"); } if(TestFile("c:/invention.bat")) { Delete ("c:
/invention.bat"); } if(TestFile("c:/shutdown.exe")) { Delete ("c:
/shutdown.exe"); } Touch("c:/autoexec.bat",""); } } / *******/
[0112] Another example of the means for capturing usage-pattern
data is by implementing the following pseudo-code [p-code]
algorithm in process 208: [0113] If the first time flag is TRUE,
record the count of directories in the user profile by performing
steps 1-4 below, then reboot or restart. [0114] Step 1 Let Integer
1=0 (I is a generic counter variable); [0115] Step 2 Loop While the
function to get the next directory does not return a value
equivalent to the no more directories flag, incrementing I by 1
each iteration through the loop. [0116] Step 3 Output I to the
profile store for the client. [0117] Step 4 Store the initial user
profiles directory structure and configuration data to the server.
[0118] Reboot or restart [0119] If the first time flag is FALSE,
probe the target machine's user profile archive to detect if a new
user has logged into the same machine and a new profile has been
added. [0120] Step 1 Let Count=f(x) where x is the retrieved value
of the last count of directories [0121] Step 2 Let Integer I=0
[0122] Step 3 Loop While the function to get the next directory
does not return a value equivalent to the no more directories flag,
incrementing I by 1 each iteration through the loop. [0123] Step 4
If Count is greater than 1, re-archive the entire set of
directories that store user profile information.
[0124] The following is a representation of the code used to
implement a rule to detect new users of a system in process 208:
TABLE-US-00002 /****y* selfheal/user_count * NAME * user_count *
DESCRIPTION * a counter which is used to determine how many users
are there in Documents and Settings Folder * NOTES * if a change in
this count is detected, the registry will be set for recapture for
mode 1 only ****** */ int user_count; [CODE ABRIDGED HERE] /* If
this is the first time after initial deployment, record the
baseline count of user directories */ if(TestFile("c:/Docurnents
and Settings")) { dir = GetDirlnfo("c:/Documents and Settings");
int new_user_count = sizeof (dir); WriteKeyValue (new_user_count,
"user_count", "host"); } DelKeyValue("reboot", "host"); [CODE
ABRIDGED HERE] /* Compare the directory count each time to see if
the recapture of data is necessary */ if(os=="winnt") {
if(TestFile("c:/Documents and Settings")){ CObject dir =
GetDirlnfo("c:/Documents and Settings"); int new_user_count =
sizeof (dir); if (user_count < new_user_count) { recapture =
true; WriteKeyValue (new_user_count, "user_count", "host"); } }
[0125] 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.
[0126] In another embodiment, usage-pattern data can be captured
(to ensure that the system will be restored in a usable state
consistent with its actual uses) when client script 207 replaces or
extends the target operating system's shell to capture and restore
the operating system's native emergency recovery data and stores
this data in a local or networked repository.
[0127] In another embodiment, client script 207 replaces or extends
the target operating system's shell or environment to include
executable instructions. The instructions enable the capture and
analysis in process 208 of, for example, a human interface device
(e.g., keyboard, handwriting recognition device, voice-recognition
device, a moue or another pointing device) and video information.
Then client script 207 can monitor, for example, user actions. In
addition, client script 207 can capture signature data files that
indicate the tasks and activities occurring on the system. The
analysis can include detection of user activities and, preferably,
automatically schedule the installation of tools to make user tasks
more efficient.
[0128] In another embodiment, run client script process 207 can
control process 208. The control can be done through a filter
configuration file or database, indicating data or structures to be
added, removed, or omitted from control during the usage-pattern
data capture process 208.
[0129] Preferably, the usage-pattern data is passed from capture
usage pattern information process 208 to parse stored usage-pattern
information process 209, which analyzes, sorts and packages
usage-pattern data for storage and/or sets flags or passes the data
through a network of rules to generate a list of actions.
[0130] In one embodiment, parse stored usage-pattern information
process 209 passes parsed usage-pattern data to store usage-pattern
data process 213. For example, the size and configuration of the
secondary storage device is stored upon the initial deployment of
the target system, and then subsequently compared at each reboot or
restart to detect a hard drive reconfiguration or malfunction.
Parse usage pattern information 209 preferably includes functions
that compare information from the target machine against previous
trend information and against rules to distinguish data indicating
significant events or changes to the target operating system.
[0131] Preferably, store usage-pattern data process 213 stores the
parsed usage-pattern data in the usage-pattern data repository
store 212. Store usage-pattern data process 213 also initiates
repair target machine process 214.
[0132] Repair target machine process 214 reads and applies
reference data from reference collection data store 130 (FIG. 1) to
the target machine's secondary storage device 211, rendering the
target machine's secondary storage device 211 to a known clean
state without usage-pattern data.
[0133] Preferably, repair target machine process 214 then initiates
reapply usage pattern information process 215. Reapply usage
pattern information process 215 recalls usage pattern data for the
target machine from the usage-pattern data repository store 212,
then applies the usage pattern to the target machine's secondary
storage device 211, thus rendering the target machine's secondary
storage device 211 to a state where all reference data and
usage-pattern data on the target machine's secondary storage media
211 are ensured to be in a usable state which corresponds to the
target machine's actual uses.
[0134] A specific example of how script 207 can control process 215
by reading client profile data 210 related to the use of
configuration data that controls the repair or restoration
applications through the use of a timeout function is described
below. First, a hash is computed from the number of seconds since
the Unix epoch (Jan. 1, 1970). 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.
[0135] Examples of defined modes in the preferred embodiment can be
defined according to this code comment section: TABLE-US-00003
/****v* selfheal/mode * NAME * preconfigured * DESCRIPTION * mode
that determines how is a machine to be restored * mode = 1 - backup
DAS and Registry only if there is a new software detected
(lockdown) * mode = 2 - backup DAS and Registry every reboot or
restart * mode = 3 - backup DAS every reboot or restart but
registry only if there is a new software detected * NOTES * This
value is read in from the file * DAS is an acronym for Documents
and Settings ****** */
[0136] Process 215 includes a selection of restoration modes for
usage-pattern data. Such modes include a mode where all
usage-pattern data is omitted and process 216 is activated without
restoring usage-pattern data. In another mode, some usage-pattern
data is reapplied and other data is omitted. In another mode, all
usage-pattern data is reapplied during process 215, the mode being
set by reading client profile data 210.
[0137] Another embodiment of process 215 includes a method of
statistically sampling a selection of usage-pattern data as
compared against target machine's secondary storage device 211 to
ascertain a confidence interval (set by client profile 210) that
the target machine's secondary storage device 211 is in a state
consistent with its actual uses. This occurs without performing a
one-to-one check of all tuples containing usage-pattern data
checkpoints.
[0138] Another embodiment of process 215 includes a method of
recording the time/date stamp of several passes of control to
process 216. If greater than n control passes occur within a set
time interval (both n and the interval provided by client profile
210), a signal is sent to the server 100 indicating abnormal
operation or user action.
[0139] 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.
[0140] One embodiment of the invention is a method for the
automated repair of static operating system, application binary
files, and configuration data files at pre-operating system boot
stage. The method includes the following steps. First, attributes
of the files against a reference collection of such files
accessible on a server are compared. The reference collection can
be stored on the server in a hard drive or a data schema. The
comparison can be performed during at least one reboot or restart
cycle. Second, a collection of dynamic operating system binary
files, configuration data files, file system structures, and
hardware system attributes unique to the configuration and use of
the system on the server are created and restored for subsequent
pre-operating system repair operations. This ensures the system's
stored instructions and flies are capable of bringing the system to
a usable state which corresponds to its normal (i.e., actual)
uses.
[0141] Another embodiment of the invention provides a system that
executes the method described above. The system includes an
automatic client process component. The client process component is
loaded dynamically from a server. This client process can be
dependent or independent on the target operating system. The client
process can be read from a network or from a local server
emulation. The client process component is executable on one or
more of the set of client computer systems. The client process
component includes a process or set of processes for determining
the state of the machine via execution script data from the system
server component. The client process script also compares the state
of the client against the known good state of the reference
collection, detecting and storing usage pattern information data
and structures and the merging of the known good state and the
usage pattern information to render the client capable of bringing
the system to the desired state.
[0142] In another embodiment, a system of the invention includes a
component that provides a graphical user interface for use by the
user to create the ideal reference collection of data. The
component also monitors the client processes' automated actions and
provides the user with configurable options to set the behavior of
the system.
[0143] In another embodiment of the invention, the graphical user
interface is replaced with a text interface. Alternatively, the
graphical user interface may interact with the user through the use
of natural language or speech processing or via changes in the
physiological state of the user.
[0144] In another embodiment, a system of the invention includes a
parser component. The parser component parse ASCII format, Unicode
or encoded or raw Binary data structures representing captured
reference collection information or usage pattern information
stored as user profiles, filesystem folders or directories, text
configuration files, configuration databases or registry data.
Parsing activities include packing and unpacking data, compressing
or decompressing data, decomposing data into smaller units,
composing larger units of data, comparing the meaning, parameters
or magnitude of the data, evaluating conditional relations between
the data, aggregating data, or separating data. Parsing prepares
the data for interpretation.
[0145] In another embodiment, a system of the invention includes a
repository of the reference collection and usage pattern
information as archives of files, filesystem structures, text
configuration files, configuration databases or registry data.
[0146] In another embodiments, the invention provides methods for
modifying the behavior of the system. For example, configuration
data specific to system behavior can be modified.
[0147] Another embodiment of the invention provides a system that
operates a DOS-compatible client system with one or more computers
running either a non-DOS or DOS-based operating system or a system
configured to receive boot instructions from sources including but
not limited to, removable media, fixed media, virtual media,
network sources or affixed in any other way by any other
device.
[0148] In another embodiment, the present invention provides a
system having a central processing unit and random access memory.
The system includes a computer-usable medium having
computer-readable code means embodied in the medium for software
for the automated repair of static operating system and application
binary files and configuration data files at pre-operating system
boot or re-initialization stage. The central processing unit and
the random access memory are used to compare attributes of the
files against a reference collection. The reference collection
includes such files stored on a server during each reboot or
restart cycle while creating and restoring a collection of dynamic
operating system binary files, configuration data files, file
system structures and hardware system attributes unique to the
configuration and use of the system. The files and attributes are
stored on a server for subsequent pre-operating system repair or
maintenance, operations ensuring the system's stored instructions
and files are capable of bringing the system to a usable state
which corresponds to its actual dynamic uses.
[0149] An embodiment of the invention includes means for causing a
computer to establish communication to the server process and
managing the creation, manipulation, storage and restoration of the
collection of dynamic operating system binary files, configuration
data files, file system structures and hardware system attributes
unique to the configuration and use of the system on a server for
subsequent pre-operating system repair operations ensuring the
system's stored instructions and files are capable of bringing the
system to a usable state which corresponds to its actual dynamic
uses.
[0150] Another embodiment of the invention includes a
computer-readable program code as a means for causing a computer to
modify server and system configuration data to control the
collection of dynamic operating system binary files, configuration
data files, file system structures and hardware system attributes
unique to the configuration and use of the system on a server for
subsequent pre-operating system repair operations ensuring the
system's stored instructions and files are capable of bringing the
system to a usable state which corresponds to its actual dynamic
uses.
[0151] The foregoing disclosure of the preferred embodiments of the
present invention has been presented for purposes of illustration
and description. It is not intended to be exhaustive or to limit
the invention to the precise forms disclosed. Many variations and
modifications of the embodiments described herein will be apparent
to one of ordinary skill in the art in light of the above
disclosure. The scope of the invention is to be defined only by the
claims appended hereto, and by their equivalents.
[0152] Further, in describing representative embodiments of the
present invention, the specification may have presented the method
and/or process of the present invention as a particular sequence of
steps. However, to the extent that the method or process does not
rely on the particular order of steps set forth herein, the method
or process should not be limited to the particular sequence of
steps described. As one of ordinary skill in the art would
appreciate, other sequences of steps may be possible. Therefore,
the particular order of the steps set forth in the specification
should not be construed as limitations on the claims. In addition,
the claims directed to the method and/or process of the present
invention should not be limited to the performance of their steps
in the order written, and one skilled in the art can readily
appreciate that the sequences may be varied and still remain within
the spirit and scope of the present invention.
* * * * *