Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1998-09-21
2001-07-31
Black, Thomas (Department: 2171)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000, C707S793000, C707S793000
Reexamination Certificate
active
06269377
ABSTRACT:
TECHNICAL FIELD
The present invention generally relates to computer systems and computer software. More particularly, the present invention relates to computer systems and computer software that enable software components to be retrieved from a variety of sources.
BACKGROUND OF THE INVENTION
Before an application program can first be used, it must typically be installed onto a computer system. The installation procedure generally involves copying executable and data files (the “program files”) relating to the application program from a source location to an installed location on the computer. Typically, the source location is an installation disk or location on a network server accessible by the computer system. Often the program files are stored in a compressed format to conserve storage space.
Before proceeding further, a brief discussion of terminology is needed. The installer application described herein recognizes three principal elements: products, features and components. A “product” represents a single, entire application program, such as the Microsoft Office application program marketed by Microsoft Corporation of Redmond, Wash. Each product has a globally unique identifier known as a Product Code, which allows products to be distinguished. Each product is made up of one or more features. A “feature” is a module that a user may choose to install or execute. Features typically correspond roughly to the functional features of the product itself, such as a “Proofing Tools” feature or a “Word” feature. Each feature is essentially a grouping of components and may also include other features. For example, the “Word” feature may include the “Proofing Tools” feature, and the “Proofing Tools” feature may include a “Spell Check” feature. So a feature, which is a module of a product, can also have its own features. Features need not be globally unique and therefore may be identified by any appropriate means, such as with a textual feature identifier.
A “component” is a collection of files, registry keys, and other resources that are all installed or uninstalled as a unit. Components are the building blocks of the product that are not exposed to the user. A resource, such as a file or a registry key, may be part of only one component. Two components may not share the same resource, whether they are part of the same product or parts of different products. Each component has a globally unique identifier known as a Component Code. One resource within the component is designated as a “key file.” The existence of the key file is used by an installer as an expedient means of checking whether a component is correctly installed or not. The installer only verifies the existence of the key file, unless a problem arises. If a problem arises, then the installer will perform a more extensive check of the files. The key file may be any resource, such as a file or registry key, within the component. A list of sources for installing a desired component is stored in a source list key.
Application programs use a variety of installation technologies to copy the program files from the source location to the computer system. InstallShield, Seagates' WinInstall or Great Lakes Software's Wise Installation System are tools commonly used for generating application installation packages for Microsoft Corporation's Windows platforms. Web-based components such as ActiveX controls may use IExpress packages, which are selfextracting executables with a simple file copy and registry capability.
An application program will often include a special application program (the “set-up program”) for administering and performing the installation procedure. Generally, the set-up program is unique to the application program and is customized to install the program files from a predetermined source location to pre-configured locations on the computer system. Often the user is provided the option of redirecting the installation of the program files to other locations on the computer system.
The typical set-up program, such as the one currently provided by Microsoft Windows, not only installs the program files to the computer system but also creates entries in a central registration database, such as a system registration database (the “system registry”), which identify the locations of the program files on the computer system. The location may be identified by a “path” to a particular directory or folder of the computer system in which the program files reside. The system registry is typically maintained by the computer system's operating system. While executing, the application program generally queries the operating system for the path to an installed program file, the operating system looks up the path in the system registry, and the operating system returns the path to the executing application program.
This set-up program provides only a very rudimentary way for system administrators and users to know which applications they have installed on their machines and to manage these installed applications. The operating system for Microsoft Windows contains an “Add/Remove Programs” control panel, and this control panel is driven by a standard set of registry entries. Windows 95, Windows 98 and Windows NT 4.0 can uninstall a product by invoking a command line provided by this registration information. Products such as Microsoft Systems Management Server can help manage installed applications in a centrally-managed environment. However, these products are limited by the information and control that individual application setup scripts choose to provide, and they do not facilitate source management for users who are in effect their own system administrators.
A limitation of current installation technologies is that they look for the program files at a predetermined location. Current installation technologies will not perform satisfactorily if that location is not available. For example, users frequently install software over a network. The installer software will look for the needed program files at a predetermined location, usually a server. If the server goes down while a user is installing these program files from the network, the user is unable to install the desired program files and is without recourse. Similarly, if the installer software expects to find the needed program files on removable media, and the removable media is not mounted when the software installer needs these program files, the installation will fail. Even something as simple as the expected program file having been inadvertently erased from the expected location will bring the software installation process to a halt.
Typically, the Add/Remove Program control panel is used to invoke “maintenance mode” setup for a product. For example, if the user decides that he now wants to install the Spell Check feature though he chose not to do so during the original install, the user goes to the Add/Remove control panel and re-runs the setup procedure to install the Spell Check feature. Depending on the user interface of the particular program, if the original installation source is no longer available, the application will either fail or will interrupt the installation process to prompt the user to locate a valid source manually. The user would either have to find a new source, or the install would fail.
When a user installs a product, he may select all of the product's features to run from the network. If the network goes down, the user is unable to use the product's features because the “run-from-source” features could run only from the network source. Users and administrators want a system by which the installer will go to a back-up location to get the needed modules if the network server goes down. This can be done via a distributed file system (DFS). A DFS keeps track of files stored across multiple networks. It converts file names into physical locations. However, everyone does not have access to a DFS, and even where a DFS is available, the administrator must manually re-map the file system before the software installer will lo
Collie Robert C.
Delo John C.
Gonzalez David E.
Haar Malcolm S.
Black Thomas
Christensen O'Connor Johnson & Kindness
Do Thuy
Microsoft Corporation
LandOfFree
System and method for managing locations of software... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for managing locations of software..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for managing locations of software... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2437442