Computer graphics processing and selective visual display system – Display driving control circuitry – Controlling the condition of display elements
Reexamination Certificate
2000-05-05
2004-06-01
Bayerl, Raymond J. (Department: 2173)
Computer graphics processing and selective visual display system
Display driving control circuitry
Controlling the condition of display elements
C345S215000, C345S215000, C345S960000, C717S175000, C717S174000, C717S168000
Reexamination Certificate
active
06744450
ABSTRACT:
TECHNICAL FIELD
This invention relates generally to systems and methods for installing application program suites and, more particularly, relates to the number and type of install actions, and their availability, selection, and display.
BACKGROUND OF THE INVENTION
With the continued growth and specialization of various software applications for both business and residential users, software original equipment manufacturers (OEMs) and secondary value added providers (VAPs) have begun selectively combining these applications into suites. The selection of the particular applications to include in a suite is made based on certain synergies desired to be achieved for a particular customer or group of customers. In this way a business customer, for example, may purchase a single suite that provides all of the applications to allow complete productivity for all of the functions that are normally performed in the business environment. This selection and grouping process by the OEMs and/or the VAPs greatly simplifies the decision process at the user level, and typically allows for a common user experience across applications since typically all applications will be from a particular OEM.
Another advantage provided by a suite of applications exists at the system administration level. Unlike the requirement of having to separately install and setup each individual application, entering the same user information over and over for each application, the installation of a suite is much more integrated. Most suites employ an installation wizard of some sort that installs and sets up all of the applications within the suite at one time. While this presents a distinct advantage over the individual application installation and setup, the structure and content of modem suites present problems for current installation processes that often result in confusion on the part of the user.
While many suites comprise a group of separate applications bundled together forming, in essence, an aggregation of applications as discussed above, more advanced and sophisticated suites actually comprise a multitude of inter-dependent applications. Indeed, many of the application programs themselves are actually mini-suites of related or complementary applications integrally operating as a “single” application. Unfortunately, these mini-suites present additional problems that add to the user confusion.
One problem lying at the core of the user confusion relates to the type of installation actions available through the conventional installation programs, and the presentation of these options to the user via the conventional check-box user interface (UI). Traditional setup applications, such as that illustrated in FIG.
10
and
FIG. 11
, provide a user interface that shows a set or list of the components in the suite in a window
500
or list box. Next to each of the components of the suite is a small check box
502
or area that illustrates the selection or deselection of that component. Typically, a check mark is illustrated next to each component that will be installed in the default installation scenario.
This check box UI allows a user to decide which components she wants to install, and which components she does not want to install. In this situation, a check mark next to a component represents that that component will be installed (i.e. install component), and no check mark represents that that component will not be installed (i.e. do nothing). Unfortunately, when the user wanted to remove a component that was already installed, the user would click on a component that has a check mark next to it to remove the check mark. In this situation, a check mark next to a component represents that that component is already installed (i.e. do nothing), and no check mark represents that that component will be removed (i.e. uninstall component).
While such operation of current installation applications is functionally correct, the presentation and implementation can be a bit confusing to users. This confusion becomes apparent, for example, in situations where one or more of the components or sub-components included in a new suite are already installed on the user's machine. In such a situation, when a user begins to setup and install the new suite, the installation application will detect the presence of these components and will place a check mark next to them in the UI. The installation application, however, also places check marks next to the components that are not currently installed, but that will be installed by the installation application. It is difficult, therefore, to determine from the displayed check marks which components the user will be installing and which components are already installed (in which case no action would be taken on those components). It is possible for a user to interpret the check mark as an install command, realize that she already has that component installed, believe that leaving the box checked will result in the re-installation of that component, and not wanting to re-install that component un-check the box. Unfortunately, this action will likely result in the component being removed from the user's system because a non-checked box for an installed component is interpreted by many install applications as an uninstall request as described above.
Further, the check box interface used with most current installation applications provides the ability to request only two types of install actions. That is, the check box can be checked or not. As described above for a component that is not installed, the check signifies that the component will be installed, and no check signifies that the installation application will not install the component (i.e. do nothing). Also as described above, if the component is already installed, the check signifies that the installation application will leave the component installed (do nothing), and no check signifies that the installation application will uninstall the component. Some installation applications also provide a separate selectable option for components that are already installed, to wit, reinstall. When this additional option is selected, typically a separate UI screen is displayed, such as that illustrated in
FIG. 12
, with additional selectable options, such as “remove all”
504
, “reinstall”
506
, and “add/remove”
508
. However, if only one or a few of the components need to be upgraded to a current version, the only option is to select “reinstall,” which will reinstall component that do not require any upgrade. This may require a significant amount of time to complete.
As may be apparent from the above description of the current check-box installation framework, the amount and types of install actions are limited to those described above. There is essentially no flexibility to add additional types of installation actions under this framework, or to allow a component to define particular component-specific actions to be performed. For example, components such as e-mail applications that have large data stores often place those stores on different drives than those on which the actual application is stored. In such situations, a disk failure for the application disk may leave the data stores totally intact. Since the data stores may include several hundred gigabytes of data, whereas the application may only require a few hundred megabytes, it is desirable to provide an additional install action other than reinstall all, which would not require a migration of the data stores. Unfortunately, while such programs can provide a “forklift” or recovery option that would look for the data store and only reinstall the application without requiring the user to reconfigure the machine, no such additional action of this type is allowed under the current check-box framework. Therefore, a user could only choose “reinstall all,” which action would require reconfiguration of the machine and migration of the data. Such actions typically take several days to complete for most organizations.
Therefore, there exists a need in the art to overcome these
Johnson Crista
Marino Phillip J.
Zimniewicz Jeff A.
Bayerl Raymond J.
Leydig , Voit & Mayer, Ltd.
Microsoft Corporation
LandOfFree
System and method of providing multiple installation actions 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 of providing multiple installation actions, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method of providing multiple installation actions will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3295756