Pre-computing computer software patch solutions

Herein, related art may be discussed to put the invention in context. Related art labeled “prior art” is admitted prior art; related art not labeled “prior art” is not admitted prior art.

Regardless of the amount of pre-release testing, computer software is rarely flawless when it is released. Security issues, compatibility issues, and other problems may be discovered post release. Accordingly, software developers can release patches to update the software. In the case of some operating systems, hundreds or thousands of patches may be available, so that users often rely on the operating system developer for recommendations regarding which patches to install.

While it might seem advantageous to simply install the latest version of all patches, there are many situations in which this is not done. New patches can introduce new problems, and may not be tested on some system configurations. Some “restrictive” users do not want to “disturb” their systems any more than necessary; such users tend to address only actual problems or important security issues. Other users may be may be reluctant to install patches that have not been extensively vetted in the field.

Accordingly, a solution provider typically takes into account both the configuration of the system being patched and the user's preferences regarding patching in general. When a particular problem or security issue is identified, the solution provider can determine the configuration of the user system and determine what patches address the problem or issue. The user preferences can help select among the solution patches.

When a large number of patches are involved, some patches require other patches be installed with them. When a patch is selected to address a user issue, the patch space has to be analyzed to determine its dependencies so they can be induded in the solution. This analysis can be quite complex and must often be repeated for users with multiple systems with different configurations. The present invention addresses the problem of having to perform intensive dependency analyses every time a patch solution is required. This and other problems addressed by the invention are apparent from the description below with reference to the following FIGURE.

The following drawing is of embodiments of the invention and not of the invention itself.

FIG. 1 is a combination schematic illustration and flow chart showing a vendor system, a user system, and a method by which the vendor system offers solutions to the user system in accordance with embodiments of the invention.

The present invention provides for dependencies for certain types of solutions to be pre-computed (i.e., computed prior to a user request for the resulting solution) independent of the user system configuration. The solutions include “minimum” and “best-like-me” solutions that are likely to appeal to many restrictive and conservative users. Where these solutions are appropriate, dependency computations are minimized or avoided at the time the solution is required. This allows an issue to be addressed faster, and obviates the need to recompute dependencies for each variation in computer configuration.

The minimum solution is a solution including the earliest patch that addresses a given issue along with all patches on which that patch depends. A best-like-me solution is the best solution according to some criterion selected from a set of solutions including the respective minimum solution and modifications to that minimum solution involving replacing one or more patches with successor patches without introducing any new dependencies. Another name for a best-like-me solution is “best-like-minimum” solution.

A user system AP 1 includes multiple servers, including servers SV 1 , SV 2 , and SV 3 . Each server has a respective operating system instance OS 1 , OS 2 , and OS 3 updated with patches PT 1 , PT 2 , and PT 3 . A respective application program A 1 , A 2 , A 3 is running on respective operating systems OS 1 , OS 2 , OS 3 . More generally, the invention provides for any number of user server systems and they can be partitioned or not, partitions can be hard or virtual, and virtual machines can be run on the partitions or systems. In the present case, operating systems OS 1 -OS 3 are differently configured instances of the same base operating system, the vendor for which runs vendor system 11 .

Vendor system 11 includes a patch space 13 , a solution space 15 , an analysis engine 17 , and a request handler 19 . Request handler 19 handles requests from user system AP 1 . The requests can be for a patch to address a particular problem or issue. For example, the request can be to: 1) address a logic defect in the operating system or program; 2) address a compatibility issue with certain hardware; 3) address a compatibility issue with other software; 4) update a system to handle security threats; or 5) other issues.

Request handler 19 forwards requests to analysis engine 17 which can determine whether a completely pre-computed solution, a partially pre-computed solution, or an ad hoc solution is required. A solution that is not pre-computed can be appropriate where the request includes configuration information for the server on which an issue arose and where no pre-computed solution effectively addresses that issue for that configuration. Completely computed solutions can be used where no configuration information is available for the target user system or where a pre-computed solution optimally addresses the user's issue. Partially computed solutions can be appropriate where a partially pre-computed solution addresses a user issue, but configuration information is available to fine-tune the solution.

Where possible, pre-computed solutions are used. Pre-computed solutions require only one analysis but can be applied to different systems. Also, the analysis is done beforehand so that latency between request and solution is minimized. In the illustrated case, minimal solutions 21 and best-like-me solutions 23 are pre-computed.

A “minimum” solution is one type of pre-computed solution. A solution is “minimum” if it contains only the earliest patch that addresses a problem and that patch's earliest dependencies. A best-like-me solution can be derived from a minimum solution by replacing one or more patches with successors that meet some “best” criterion but that do not introduce new dependencies. In some cases, the “best like me” and “minimum” solutions are the same—e.g., where there are no qualified successors to the patches in the minimum patch solution.

For some user system configurations, the best solution may be related to but different from a minimum or best-like-me solution. Where this “better” solution can be pre-identified, it can be presented along with the minimum or best-like-me solution. The user can then determine whether to implement the minimum or best-like-me solution or a pre-identified alternative based on the user system configuration. Where the final solution is configuration dependent, it is said to be “partially pre-computed”.

Patch space 13 includes thousands of patches; patches P 11 -P 16 , P 21 , P 22 , and P 31 are represented. Patch P 11 is the earliest patch that addresses a specific potential user issue, while patches P 12 -P 16 are successors that also address that issue, as indicated by the inter-patch arrows with solid heads. Patches P 11 requires that patch P 21 be installed as indicated by the open headed interpatch arrow between patch P 11 and patch P 21 ; alternatively, the successor patch P 22 to patch P 21 can be used instead of patch P 21 to meet the dependency requirements of patch P 11 .

Patches P 12 and P 13 have the same dependency requirements as patch P 11 . Patch P 14 requires patch P 22 , as indicated by the open headed arrow between these patches; patch P 21 does not meet the dependency requirements for patch P 14 . Patch P 15 is a successor to both patch P 14 and patch P 22 , in effect merging two patch successor lines. Patch P 15 has no dependency requirements. Its successor, patch P 16 has a new dependency requirement, patch P 31 .

For one example, if patch P 11 is the earliest patch to address a given user problem, then the minimum solution includes patch P 11 and its dependency P 21 . For the “best” solutions, there are alternatives depending on how “best” is defined and how “new dependencies” is defined.

For example, if patch P 22 is considered a new dependency, the best-like-me solution could be patch P 13 and patch P 21 , as patch P 13 is the latest patch having the same dependency as minimum patch P 11 . However, patch P 13 has been tested but not found reliable (as indicated by the “T” and blank boxes). Accordingly, if “best” is defined to require patches tested and found reliable, the best-like-me solution can be P 12 and P 21 .

If patch P 22 , as a successor to patch P 21 , is not considered to introduce a new dependency, patch P 16 would be the first patch to introduce a new dependency, i.e., patch P 31 , which is not a successor to patch P 21 . In this case, patch P 15 would qualify as the best-like-me patch solution. As it has no dependency, patch P 15 would be the complete solution.

As mentioned above, it may be apparent that solutions better than the best-like-me solution may be available depending on the configuration of the user server. For example, a successor to a best-like-me solution patch might be a better solution on systems in which the new dependency associated with the successor is already installed on the user system. Such contingencies can be stored as meta-data for the best-like-me solution patch. Such solutions are partially pre-computed as the user system may perform some computation based on the meta-data to determine whether the best-like-me or the successor patch solution is better for the target user system.

The invention provides for a method ME 1 in which patch ratings are assigned to patches at method segment M 1 . At method segment M 2 , minimum and best-like-me solutions are pre-generated. When a user request is received (e.g., by patch handler 19 , at method segment M 3 ) a minimum or best-like-me solution can be provided to the user at method segment M 4 . Finally, if the best-like-me solution indicates a better solution based on user system configuration, the better solution can be determined at the by user system AP 1 at method segment M 5 .

The invention is computationally efficient as many dependencies are computed once and used multiple times. The computations are collocated with the updated patch space on vendor system 11 , so the computations are always up to date. This contrasts with approaches in which the computations are carried out at the user system based on pre-determined algorithms that may be out of date. User privacy is protected because configuration data need not be sent to the solution provider for a solution to be generated.

The solutions provided for by the present invention comprise combinations of two or more patches. However, practical embodiments of the invention also provide solutions that consist of a single patch.

While a relatively simple example of a patch family tree is shown in FIG. 1 , the invention is scalable to vastly larger and more complex patch spaces. Patches can be rated in many different ways, and these ratings can be considered in defining “best” in a “best-like-me” solution. Solutions can be presented to the user as a single solution or as a set of solutions that the user can select from, e.g., based on preferences and server configurations. These and other variations upon and modifications to the illustrated embodiments are provided for by the present invention, the scope of which is defined by the following claims.