Data processing: software development – installation – and managem – Software upgrading or updating
Reexamination Certificate
1999-05-19
2002-07-23
Khatri, Anil (Department: 2122)
Data processing: software development, installation, and managem
Software upgrading or updating
C717S170000, C707S793000
Reexamination Certificate
active
06425126
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
This invention generally relates to updating software. More specifically, this invention relates to an apparatus and method for synchronizing software between one or more computers.
2. Background Art
Computers have progressed from taking rooms full of vacuum tubes to becoming tiny, hand-held devices. Computers in some form or another control most of the products with which we come in contact during our lives. They control the anti-lock brake systems in our cars, the timing of the lights that we encounter on our way to work, where the elevator stops on the way to our offices, and temperature of our offices. Furthermore, they control and affect our primary work environment, as most people use computers every day as part of their jobs.
As computers have become ubiquitous, so has the software that is needed to run them. While computers evolved from tubes to miniature devices made of silicon, software has also developed from punch cards to sophisticated programs capable of rendering and shading three-dimensional objects, performing complex calculations on simulated loaded beams, and performing other feats that were previously impossible. Not only has the sophistication of software dramatically increased, but the pace of additions, modifications, and changes to software has quickened dramatically.
Previously, a new release of a software product occurred about two or three years after the previous release of the product. Today, a two year timetable seems to be preferred, and many timetables are shorter. Furthermore, because of the complexity of software, as soon as the software product is released, errors (commonly called “bugs”, after a famous incident where an insect shorted out a vacuum tube and caused errors) are found. These errors are generally attended to immediately by the software product's programmers, who find a “fix” or “patch” for the program. These fixes or patches are usually distributed to registered owners of the software product, or placed on an Internet website where the software product owner can download the fix. Thus, between major updates of software are numerous (and sometimes substantial) fixes to the software product.
These multiple updates and fixes have become problematic for many individuals and businesses. Due to the sheer number of fixes for all of the software products on a computer system, the individual responsible for maintaining the computer system may not even know that fixes or updates exist for the system. The individual must himself or herself ferret out the fixes and updates. In addition, there is the potentially devastating effect that one software fix may actually “break” or cause errors in another software program or even the software product that the fix is supposed to update.
These problems are particularly onerous for computers that are connected through one or more networks. In these systems, there is generally one or more system administrators that are responsible for the upkeep of a number of computer systems. For instance, a large network may have several system administrators, each of which are responsible for a number of computer systems in his or her area. The system administrator for the north-west area might put a patch that fixes a security problem on one computer in her network. She would test the patch to ensure that it causes less harm than benefit, and then manually apply the patch to each computer in her area.
Meanwhile, the system administrator (SA) in charge of the computers in the south-east area has applied a fix to an operating system component on one computer in the network. Unfortunately, this fix has had a devastating effect on one important software product. The south-east area SA decides to add an update to the software product in hopes that this will eliminate the effect caused by the operating system fix. However, the effect is still there after application of the update, but the update has solved other problems associated with the software product. The south-east area SA decides to uninstall the operating system component, but the component does not uninstall correctly, and the SA must manually uninstall the fix and reinstall part or all of the operating system.
Neither SA knows what the other SA is doing. In this example, the north-west area SA might apply the same fix to the same operating system and experience the same effects. The south-east SA might not know that a patch for the security flaw exists and may be leery of applying the patch after the destruction caused by the operating system fix. Each SA might rediscover the problems or benefits caused by a fix or patch that the other has already discovered.
These system administrators have other administration duties that are also inefficient. It is very hard to determine the fix level of any computer without actually visiting that computer. Thus, one computer may have a patch or fix installed, but the computer immediately next to it may not have the same patch or fix. This can lead to level mismatches in the enterprise, where some computers are at one fix level and other computers are at another fix level.
Level mismatches can sometimes create problems. For instance, a patch may be developed that fixes a problem with a database that, in certain cases, could cause a non-obvious error. If this patch is applied to some but not all of the computers in a network, a person accessing more than one database (on multiple computers) may get different, anomalous results. Even if the person sees the anomaly, he or she might give the database the benefit of the doubt and use the erroneous information regardless. If all databases on all computers had the same patch, the non-obvious error would not occur.
Even if the SA can remotely determine the software fixes that are applied on one computer, additional or different software fixes for that computer must be manually installed. A significant quantity of time can be invested in just updating computers, as each computer must be accessed to determine the software fixes that are installed, and then additional or different software fixes must be applied to each computer. In small networks this process can take quite a bit of time, and in large networks this process can take weeks or months.
Without a method and apparatus for synchronizing software in a network, system administrators will continue to rediscover software problems, will have more computers that are at different software fix levels, will have to keep track of the software fix level of each computer in the network, and will have to manually update each computer in the network.
BRIEF SUMMARY OF INVENTION
The preferred embodiments of the present invention provide a method and apparatus for synchronizing software between computers. A software fix manager compares a preferred software inventory with a software inventory from a computer that is to be synchronized. The software fix manager generates a number of synchronizations from this comparison, preferably packaging these synchronizations into a fix list. An update manager uses the software fix list to apply software product synchronizations to the computer. Preferably, the computer can be brought to the same fix level or product level, if desired, as the preferred software inventory through this process.
The fix list is a list of software product synchronizations. There can be multiple software product synchronizations per software product, and the synchronizations can be applied to a computer by removing a software product fix or installing a product software fix. The current invention may also be applied to software products themselves, by installing or removing software products.
The present invention potentially has its best application in networks, as numerous target computers or groups of target computers may be synchronized with a preferred software inventory of a model system.
The foregoing and other features and advantages of the present invention will be apparent in the preferred embodiments of the invention, as illustrated in the accompanying drawings
Branson Michael John
DeStefano George Francis
Haugen Ronald Joseph
Hintermeister Gregory Richard
Hurlebaus Gregory Scott
Khatri Anil
Schmieser, Olsen & Watts
LandOfFree
Apparatus and method for synchronizing software between... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Apparatus and method for synchronizing software between..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Apparatus and method for synchronizing software between... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2870175