ARTEAAA
`US005 1558474
`[11] Patent Number:
`5,155,847
`[45] Date of Patent:
`Oct. 13, 1992
`
` :
`
`United States Patent
`Kirouacet al.
`
`[19]
`
`[75]
`
`.
`
`[54] METHOD AND APPARATUS FOR
`[57]
`ABSTRACT
`vocarione TWARE AT REMOTE
`A method and system are provided for updating the —
`software used in remote computer systems from a cen-
`Inventors: Donald L. Kirouac, Thornhill;
`tral computer system. The method includes storing in
`William A. Porrett, Unionville,
`the central computer system, copies of the software
`Marek J. Czerwinski, Scarborough,
`executable used in each remote computer system. When
`all of Canada
`the copies of the software in the central computer sys-
`[73] Assignee: Minicom Data Corporation,
`tem are upgraded, for example, to correct the software,
`Markham, Canada
`to add newfacilities, to change user interfaces, to make
`cosmetic changes, to improve performance, etc., each
`[21] Appl. No.: 227,799
`change made to the software is monitored and stored.
`(22] Filed:
`Aug. 3, 1988
`The remote computer systems are permitted access to
`the central computer system via communication links
`(51) Unt. C13 ooeee GO6F 7/00;Gerpaw and the software in the remote computers
`and
`[52] US. Ch oecccscccssssscsssesesssesenen 395/600; 395/650,
`the corresponding software in the central computer
`395/200. 364/DIG. 1- 364/DIG. 2
`system are compared. All of the changes that have been
`[58] Field of Search...........".. 364/300, 200 MS File,
`ade to the software at the central computer system
`364/900 MSFile; 395/600, 650,200|Which have not been made to the corresponding soft-
`ware at the remote computer system accessing the cen-
`[56]
`References Cited
`tral computer are detected. The detected changes are
`U.S. PATENT DOCUMENTS
`then transmitted to the remote computer system and
`4,558,413 12/1985 Schmidt et al. ..cccccasenn 364/300
`8pplied to the software therein in order to upgrade the
`eens 364/900—«-Software in the remote computer system. The upgraded
`4,630,234 12/1986 Holly ..........
`
`4,641,274 2/1987 Swank ............
`seen 364/900
`software in the remote computer system is examined to
`
`4,714,996 12/1987 Gladneyet al.
`teeee 364/300
`ensure that the software has been changed correctly.
`
`4,748,561
`5/1988 Brown........00..,
`ve 364/300=The method allows the software at the remote com-
`
`4,794,519 12/1988 Koizumiet al.
`...
`we ser
`puter systems to be upgraded even while the software at
`
`4,827,399
`5/1989 Shibayama .............
`364/900
`‘the remote site is being used. The system and method
`4,845,665
`7/1989 Heathet al. ou...
`
`... 364/200
`also allow the software used in the remote computer
`4,849,879
`7/1989 Chinnaswamyetal. ..
`
`8/1989 Heath et al. o......seen 364/200
`systems to be upgraded when the remote computer
`4,858,114
`9/1989 Cree et al. ececcnescssseneeene 364/900
`4,866,611
`systems use different versions of the software and allow
`5,019,963
`5/1991 Alderson et al. ou... 364/200
`the software to be upgraded in a variety of hardware
`Primary Examiner—Stuart N. Hecker
`environments and operating systems.
`Assistant Examiner—Michael A. Whitfield
`Attorney, Agent, or Firm—Nixon & Vanderhye
`
`32 Claims, 7 Drawing Sheets
`
`Page | of 17
`
`|
`
`GOOGLEEXHIBIT 1012
`
`Page 1 of 17
`
`GOOGLE EXHIBIT 1012
`
`

`

`U.S. Patent
`
`Oct. 13, 1992
`
`Sheet 1 of 7
`
`5,155,847
`
`
`
`Figure 1
`
`Page 2 of 17
`
`Page 2 of 17
`
`

`

`U.S. Patent
`
`Oct. 13, 1992
`
`Sheet 2 of 7
`
`5,155,847
`
`
`
`
`
`
` zFP8 £8BRRY
`
`Function
`
`
` Copy
`
`Version Assign|“44
`:
`Function
`
`i)
`|
`
`f
`
`Semen
`
`|
`
`46
`
`To System
`
`ag
`
`Threshold
`Memory
`
`rorrereeeeme
`
`“)
`
`Figure 2a
`
`Page 3 of 17
`
`Page 3 of 17
`
`

`

`U.S. Patent
`
`Oct. 13, 1992
`
`Sheet 3 of 7
`
`5,155,847
`
`i
`Prt rrr re reten cnn ree terre tenner nem mreree nen mena na ete eeens we teenncere meen ene ne eee eene w eeees,
`
`to Program History
`
`32
`
`
`
`Examination
`65
`Saction
`
`Validation
`Function
`
`
`
`
`
`
`Set-Up
`Access
`Request
`Section
`
`
`
`Detect
`Verification
`
`
`Function
`Section
`
`
`
`
`from Remote Computers
`
`to Remote Computers
`
`12
`
`14
`
`Figure 2b
`
`Page 4 of 17
`
`Page 4 of 17
`
`

`

`U.S. Patent
`
`Oct. 13, 1992
`
`Sheet 4 of 7
`
`5,155,847
`
`Figure 3a
`
`makes copy
`of Module
`
`
`Programmer
`
`epplies changes
`manually to
`
`Module
`
`
`
`
` Programmer
`202
`204
`206
`208 Record version #|210
`
`
`System
`extracts differences
`
`between old and
`
`new Module
`
`
`
` Assign
`
`Change Sequence
`
`Number
`
`Page 5 of 17
`
`Page 5 of 17
`
`

`

`U.S. Patent
`
`Oct. 13, 1992
`
`Sheet 5 of 7
`
`5,155,847
`
`Apply changes
`to Module
`
`
`
`
`
`
` Figure 3b
`
`
`
`Extract differences
`between old and
`new modules for
`this version
`
`Page 6 of 17
`
`Page 6 of 17
`
`

`

`U.S. Patent
`
`Oct. 13, 1992
`
`Sheet 6 of 7
`
`5,155,847
`
`START
`
`Client
`Connects
`
`[502
`
`@)
`
`Yes
`
`Initialhandshake
`
`Lave(LOGIN)
`
`between ESP
`machine
`& client computer
`eg Sys.,ID, Patch
`
`:
`ND SESSION!
`
`No
`
`
`
`
`Any
`
`
`Priority
`Patches 7
`
`Any changes to
`
`308
`
`307
`
`changes
`
`
`
`Figure 4a
`
`(8)
`
`Page 7 of 17
`
`Page 7 of 17
`
`

`

`U.S. Patent
`
`Oct. 13, 1992
`
`Sheet 7 of 7
`
`5,155,847
`
`
`
`
`
`
`Checksum
`consistent
`
`Transmits
`changes
`line-by-line
`with verity
`
`
`
`New
`Checksum
`consistent
`
`
`
`Apply change
`on client’s
`system
`
`
`
`Figure 4b
`
`Page 8 of 17
`
`Page 8 of 17
`
`

`

`1
`
`5,155,847
`
`METHOD AND APPARATUS FOR UPDATING
`SOFTWARE AT REMOTE LOCATIONS
`
`BACKGROUNDOF THE INVENTION
`
`5
`
`Thepresent invention relates to software support and
`in particular to a method and system for upgrading
`software used in remote computer systems from a cen-
`tral computer system.
`Presently, a plurality of methodsare used by software
`suppliers to upgrade the existing software that is used
`by their customers. These methodsinclude floppy disk
`distribution, tape distribution and modem support. For
`example, Lotus Development Corporation typically
`uses floppy disk distribution to supply its users with
`Lotus 1-2-3 (trademark) software. This method requires
`Lotus Development Corp. to write the upgraded ver-
`sions of their software on floppy disks and distribute the
`disks via an appropriate service to all of its customers.
`However, a number of problems exist in this type of
`software support method in that an upgraded floppy
`disk version of the software is typically released once a
`year. Thus, a user must use the existing software even
`after faults have been recognized, until the new disk
`version of the software is received, since there is no
`immediate software support for individual users. Fur-
`thermore, since the upgrading process often results in
`the addition of new program errors, the user must cope
`with the program faults of the new version until yet
`another version of the software is released. Moreover,
`further time delays exist in obtaining upgraded versions
`of the software, since the floppy disks are typically
`distributed via the postal service.
`A similar manner of software support has been at-
`tempted using tape distribution to supply new versions
`of software to consumers. Although this method re-
`duces the occurrence of damageto the physical medium
`containing the software, the process is still time con-
`suming, since the tapes must be forwarded to each of
`the software users.
`Modem support has also been attempted as a method
`of upgrading existing software. In this method, an oper-
`ator at the software supplier links with the consumer's
`remote computer system and manually upgrades the
`software. However, this method of upgrading software
`is time consuming, expensive and proneto error, since
`the method involves manual. processes. Accordingly,
`there is a need for an improved method of upgrading
`software.
`
`SUMMARYOF THE INVENTION
`
`It is therefore an object of the present invention to
`obviate or mitigate the above disadvantages.
`According to the present invention there is provided
`a method of upgrading software used in remote com-
`puter systems from a central computer system compris-
`ing the steps of:
`storing in said central computer system, software
`corresponding to the software used in each of said re-
`mote computer systems;
`upgrading the corresponding softwareat said central
`computer system;
`recording the changes made to said corresponding
`software;
`allowing access of said remote computer systems to
`said central computer system via communication links;
`
`5
`
`20
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`65
`
`Page 9 of 17
`
`2
`identifying said remote computer systems accessing
`said central computer system and the software used
`therein;
`comparing the software in said remote computer
`system with the corresponding software in said central
`computer system;
`identifying changes that have been madeto the corre-
`sponding software that have not been madeto thesoft-
`ware in said remote computer systems;
`transmitting the identified changes to said remote
`computer system and applying the changesto the soft-
`ware therein; and
`verifying transmission of the changes and examining
`the upgraded software in said remote computer systems
`to ensure that the software has been properly upgraded.
`In another aspect of the present invention there is
`provided a software support system for upgradingsoft-
`ware used in remote computer systems from a central
`computer system comprising:
`a central computer system including data storage for
`storing software corresponding to the software used in
`said remote computer systems;
`system
`input
`terminals at
`the central computer
`through which the corresponding software may be
`upgraded, with the changes madefor the upgrade being
`recorded by the central computer system;
`communication links allowing the remote computer
`system to access the central computer system;
`a comparator for comparing the software at a remote
`computer system with the corresponding software at
`the central computer
`system and identifying the
`changes made to the corresponding software which
`have not been madeto the software at the remote com-
`puter system,
`a data transmission device to transmit the identified
`changes to the remote computer system and to apply
`the changesto the software therein to upgradethesoft-
`ware, the central computer system and the remote com-
`puter system verifying the correct transmission of the
`changes and proper upgrading of the software in the
`remote computer system.
`Preferably, at least one conventional computer termi-
`nal is provided for allowing a user to apply changes to
`the corresponding software stored in the central com-
`puter system. It is also preferred that the data transmis-
`sion device implement ‘“‘handshaking” between the cen-
`tral computer system and each remote computer system
`accessing the central computer system.
`Preferably, the central and remote computer systems
`implement checksumsto verify the correct transmission
`of the software changes sent to the remote computer
`systems and to ensure that the software at the remote
`computer systems has been properly upgraded.
`Preferably, the central computer system is capable of
`upgrading the software used in the remote computer
`systems at any time and has multi-tasking capabilities to
`allow a plurality of remote computer systems to gain
`access to the central computer system at the sametime.
`Furthermore, it is preferred that the system provides
`software support for all remote computer systems when
`the remote computer systems are using different ver-
`sions of the software.
`The present system and method provide the advan-
`tages of allowing the software used in the remote com-
`puter systems to be upgraded from a central system at
`any time regardless of the magnitude of the upgrade.
`Furthermore, the system can operate on various soft-
`ware and hardware environments thereby allowing
`
`Page 9 of 17
`
`

`

`5,155,847
`
`3
`substantially all types of software to be upgraded. As
`used herein, executable code comprises data which
`represents the program of a computer system and the
`associated data for such a program.
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`4
`all of the remote computer systems. The supplier also
`makes available to the remote computer systems 12,
`optional programs OP,,(“x” denoting the version num-
`ber of the program and “ty” denoting the number of the
`optional program since a variety of optiona] programs
`are available) which are used in some of the remote
`computer systems 12 to perform additional functions
`particular to the business of the user.
`Initially,
`the software supplier distributes via tape
`distribution,
`the first version of the mandatory pro-
`grams MP; to all of its purchasers who use the software
`in their remote computer systems 12 for daily business
`operations. Some of the customers are also supplied
`with the first version of one or more optional programs
`OP1,y. Whenever a remote computer system 12 is receiv-
`ing the mandatory programs MP, and optional pro-
`grams OPxy, the mandatory programs and the optional
`programsare distributed in a package and are the same
`version “x” of software.
`After the remote computer systems 12 have been
`supplied with the first version of available software, the
`software supplier often desires to upgrade the software
`to add user facilities, to make cosmetic changes, to
`change user interfaces, to correct errors, to improve
`performance,etc. Since a copyofthefirst version of the
`mandatory programs MP; andall of the available op-
`tional programs OP, are maintained in the data store
`28, changes or patches P can easily be made to the
`software via the central computer system 14. As patches
`P are madeto either the mandatory programs MP) or to
`any of the optional programs OP,, the central com-
`puter system 14 monitors and records the changes made
`to the software and of course, changes the software in
`the remote computer systems 12,
`if the changes are
`applicable, the details of which will be described herein.
`However, after a plurality of changes have been
`made to a version of the software stored in the data
`store 28, it is uneconomical to supply a new purchaser
`of the software with an unaltered version of the manda-
`tory programs MP, and optional programs OP,, and
`afterwards transmit to the purchaser,all of the changes
`that have been made to the programs. Accordingly,
`after a number of changes have been madeto theorigi-
`nal mandatory and optional programs, another version
`of the mandatory and optional programsis released to
`new purchasers of the software via tape distribution, the
`second version of the programs including someorall of
`the changes and any additions that have been madeto
`the first version of the programs, so that the new pur-
`chasersare initially supplied with an up-to-date version
`of the available programs. When the second version of
`the software is released, a copy of the mandatory pro-
`grams MP2 and optional programs OP2y are stored in
`the data store 28 so that upgrades can be made to the
`second version of software. This process is performed
`for each new version of the mandatory and optional
`programs that is released by the supplier for use by its
`customers. This allows the system 14 to upgrade the
`software used in all of the remote computer systems 12,
`even if the computer systems 12 operate using different
`versions of the software.
`The central computer system 14 includesat least one
`computer terminal 30 comprising a conventional key-
`board and video display terminal for allowing a user to
`access the various versions of the mandatory and op-
`tional programs MP, and OP,, held in the data store 28.
`Eachtime a user accesses the data store 28 to upgrade
`one or more of the mandatory or optional programs
`
`An embodimentof the present invention will now be
`described, by way of example only, with reference to
`the accompanying drawings in which:
`FIG. 1 is a schematic diagram of a software support
`system,
`FIG. 2a is a schematic diagram of a portion of the
`system illustrated in FIG. 1;
`FIG. 26 is a schematic diagram of another portion of
`the system illustrated in FIG. 1;
`FIG. 3e is a portion of a flow chart illustrating the
`operation of the portion illustrated in FIG. 2a;
`FIG. 3d is another portion of a flow chart illustrating
`the operation of the portion illustrated in FIG. 2a.
`FIG. 4a is a portion of a flow chart illustrating the
`operation of the portion illustrated in FIG. 24; and
`FIG. 48 is another portion of a flow chart illustrating
`the operation of the portion illustrated in FIG. 2.
`DESCRIPTION OF THE PREFERRED
`EMBODIMENTS
`
`Referring to FIG. 1, a software support system 10 is
`shownfor upgrading software used in remote computer
`systems 12 from a central computer system 14. The
`central computer system 14 stores software correspond-
`ing to the software used in each of the remote systems
`12 and permits the corresponding software to be up-
`graded. The central computersystem 14 is connected to
`the remote computer systems 12 via communication
`links 16, the links typically being a packet switching
`networkto allow the changes that have been madeto
`the corresponding software to be transmitted from the
`central computer system 14 to the remote computer
`systems 12.
`The remote computer systems 12 are divided into
`groups as schematically represented by concentric cir-
`cles 20. Each group of remote computer systems 12 is
`assigned a group threshold which determines the rela-
`tive time that the remote systems of one group must
`wait to receive the changes that have been made to the
`software used at remote systems of a different group.
`For example, the remote computer systems 12 of one
`group, those positioned between the pair of concentric
`circles 20a and 200 are assigned a different groupdistri-
`bution number than the other group of remote com-
`puter systems positioned between concentric circles 20b
`and 20c thus, may receive upgrades to the software used
`therein prior to the remote computer systems in the
`other group. This feature permits staged release of the
`software upgrades and allows the operation of the up-
`graded software to be monitored on a select group of
`remote computer systems 12 prior to global release of
`the software upgrades to all of the remote computer
`systems 12.
`Referring now to FIGS. 2a and 26, the central com-
`puter system 14 whichis typically located at the head-
`quarters of the software supplier is shown. The central
`computer system 14 includes a large data store 28 for
`storing copies of the software corresponding to the
`software used in each of the remote computer systems
`12. The software supplier provides to the remote com-
`puter systems, mandatory programs MP, (“x” denoting
`the version number of the program) which are used in
`
`25
`
`40
`
`45
`
`55
`
`60
`
`65
`
`Page 10 of 17
`
`Page 10 of 17
`
`

`

`5,155,847
`
`15
`
`20
`
`25
`
`30
`
`35
`
`5
`stored therein, all of the changes made to a program
`during that session are categorized as a patch Py(V =i
`to z), wherein ““N” is the numberof the patch and ““V”
`is equal to the numbersof the all of the versions of the
`same program to which that the patch is applicable and
`to whichit is to be applied. The patch number “‘N” is
`determined by the value of a counter 29, the counter
`incrementing upon the creation of each patch made to
`any program. Thus, the first patch P made to any pro-
`gram regardless of its version will be assigned patch
`number | (N=1), the second patch made to any pro-
`gram will be assigned patch number 2 (N=2),etc.
`The control software used in the central computer
`system 14 for allowing the programsin the data store 28
`and in the remote computer systems to be upgradedis
`partitioned mainly into two major sections, namely a
`program history section 32 and a system patchersection
`34.
`The program history section 32 functions to monitor
`and record all of the upgrades or patches P that have
`been madeto the various versions of any of the pro-
`grams held in the data store 28. The system patcher
`section 34 functions to ensure that
`the appropriate
`changes madeto the software in central computer sys-
`tem 14 are transmitted to the correct remote computer
`systems 12 and applied to the corresponding software
`therein. The system patcher section $4 also ensures that
`the software in the remote computer systems 12 is the
`sameas the upgraded version stored in the central com-
`puter system 14, once the changes have been applied to
`the software.
`The program history section 32 includes a copy func-
`tion 38 whichis associated with the data store 28. The
`function 38 copies the version of the program stored in
`the data store 28 that the user of the terminal 30 wishes
`to upgrade. A processor function 40 receives the copied
`program and allows the user to make the desired
`changes thereto. When the user has completed making
`all of the changes, an upgrade detect function 42 moni-
`tors and recordsall of the changes madeto the program
`during that session by comparing the upgraded program
`with the program copied by the function 38. The
`changes detected by the function 42 are then grouped as
`a patch P. A patch and version assign function 44 com-
`municates with the processor function 40, the upgrade
`detect function 42 and the counter 29 and assigns the
`patch P,its patch number “N”and the version numbers
`“V" of the same program to which the patch P applies.
`For example, if a patch P is madeto the first version
`of one of the mandatory programs MP; andthereare six
`different versions of the mandatory programs MP;to
`MPthat have been released by the vendorthat are used
`in the remote computer systems 12, the value of the
`counter 29 is examined andits value is assigned to the
`patch P as its patch number N. As mentioned previ-
`ously, the value of the counter 29 indicates the total
`numberof patches that have been madeto the programs
`in the data store 28. Thus, if a total of six patches have
`been previously made, the above-mentioned patch P
`madeto the first version of the one mandatory program
`will be assigned patch number 7 (N=7).
`Thereafter, the other versions of the mandatory pro-
`grams MP; to MP¢are examined to detectif the patch
`P7 made to the program MP; is applicable to those
`versions of the same program. The version numbersof 65
`all of the programs to which the patch is applicable are
`displayed on the terminal 30 and theuser is requested to
`confirm whether the patch P7 should be applied to the
`
`45
`
`350
`
`55
`
`Page 11 of 17
`
`6
`other applicable programs as well. If the patch P7 is to
`be applied to the other detected versions of the same
`program, the patch number “N” is maintained and the
`patch is automatically applied and stored in the data
`store 28 under all of the versions of the mandatory
`program to whichit applies.
`A checksum assign function 46 also communicates
`with the processor function 40 and with the upgrade
`detect function 42 and assigns every patch made to a
`program a pair of checksums Cky and Cky41. The
`checksums Ckyand Cky41 represent an image of the
`program to which the patch is being applied before the
`patch is applied to the program and an image of the
`program after the patch has been applied to the pro-
`gram.
`A related patch detect function 50 is also provided
`for detecting when the user making the changesto the
`software, codes a patch as being related to a previous
`patch made to the same program or codes the patch as
`being related to a patch made to another program in the
`same version of programs. Whenthe related patch de-
`tect function 50 detects related patches,
`the related
`patches are coded. After the patch has been assigned a
`patch number, examined to determine the other ver-
`sions of the same program to whichit applies, assigned
`the checksums, and has been examined for any relation-
`ship with other patches, the patch, the assigned patch
`number,
`the checksums and any assigned codes are
`stored in the data store 28 for the various versions of the
`program that were upgraded.
`As should be realized,
`the same processes apply
`whether changes are made to a mandatory program or
`to an optional program. For example, if a patch Py is
`made to the optional program OP,; and there are six
`released versions of the software, the patch Pywill be
`assigned the next available patch number “‘N” as deter-
`mined by the value of the counter 29. Similarly, the
`other versions OP2; to OP¢) of the optional program
`OP}, will be examined to determine if the patch Pyis
`applicable thereto. The process of detecting related
`patches is also performed for patches made to the op-
`tional programs.
`The program history section 32 also includes a patch
`threshold valve memory 48 for storing a predetermined
`patch threshold value which is equal to the highest
`patch number with no untested patches below it. The
`patch threshold value determines the patches that can
`be transmitted to the remote computer systems 12 andis
`used to determine the value of the group thresholds.
`The patch threshold value is determined by a quality
`assurance process used by the software vendor for mon-
`itoring the operation of each patch to attempt to ensure
`that the patches operate with the programs without
`error or without introducing errors. For example, if the
`threshold valueis set at 10, only patches P; to Pigcan be
`transmitted to the remote computer systems 12, since
`those patches will have been tested by the quality assur-
`ance process and will have been determined to operate
`satisfactorily. Other patches that have been created yet
`have not passed through the quality assurance process
`which have a patch numbergreater than the threshold
`value may be transmitted to specific remote systems 12,
`if special provisions have been madeforthe systems, the
`details of which are described herein but typically will
`be maintained in the data store 28 until the patch thresh-
`old value has been raised.
`Referring to FIGS. 3a and 3d the operation of the
`program history section 32 will now be described. Ini-
`
`Page 11 of 17
`
`

`

`5,155,847
`
`7
`tially as mentioned previously, when the different ver-
`sions of the mandatory programs MP;
`to MPaand
`associated optional programs OP}, to OPjyare supplied
`to the remote computers systems 12, copies of the pro-
`gramsare stored in the data store 28 of the central com-
`puter system 14. As this is done, the checksum assign
`function 46 assigns each program a checksum Ck, rep-
`resenting an image of the original program whichis also
`stored in the data store 28.
`If, for example,
`it is desired to upgrade one of the
`mandatory programs MP), the user accesses the central
`computer system 14 via the terminal 30. As should be
`realized, the user must meet certain access requirements
`such as typing in appropriate passwordsto prevent the
`occurrence of unauthorized access to the programs.
`After access has been accomplished, the user chooses
`the program thatis to be changed inthis case, one of the
`mandatory programs MP1. The copy function 38 in turn
`creates a copy of the one program MPhaving all of the
`previous patches P that have been madeto the program
`applied thereto asindicated at block 202. The checksum
`assign function 46 examines the copied program and
`recalculates a checksum Cka:for the copied program
`which represents an image of the program. The check-
`sum CKxis compared with the second checksum as-
`signed to the last patch made to the same program to
`ensure that the copied program hasin fact been copied
`correctly.
`The correctly copied program is then conveyed to
`the processor function 40 and the useris able to edit the
`program in any mannerthat is desired in order to up-
`grade the software as indicated at block 204. After the
`desired changes have been made to the program, the
`update detect function 42 compares the changed copy
`of the program with the copied program MP, as indi-
`cated at block 206 to detect any differences. All of the
`differences detected between the programsare grouped
`as a patch P. The code assign function 44 examines the
`counter 29 and in turn assigns the patch P, a patch
`number N, this number being one greater than the num-
`ber of the counter 29 and the counter 29 is incremented
`as indicated at block 208. When the patch P has been
`assigned its patch numberN, the checksum assign func-
`tion 46 assigns the patch, a second checksum Cky,+1 as
`indicated at block 210, the second checksum represent-
`ing an image of the program with the patch applied to
`it.
`
`Whenthe user wishes to make further changes to the
`same program or to another program, access can be
`gained to the central computer system 14 in the same
`manner described above. For example, after another
`patch Py) has been made to the same program in the
`above-mentioned manner, the checksum assign function
`46 will recalculate the first checksum CKj+1 for the
`next patch Py+; and will assign the patch Pyii, a
`second checksum Cky42. As should be noted, each
`successive patch P made to a program is assigned a
`checksum that is also assigned to the previous patch.
`The above described process is performed regardless of
`which version of the mandatory programs or optional
`programsis being updated.
`After the checksums have been assigned to the patch,
`the patch P is stored in the data store 28 along with the
`assigned patch number and the assigned checksumsas
`also indicated at block 210. The patch P is also for-
`warded to the quality assurance process as shown by
`block 201 whereinit is given a numberandis placed on
`a list including other patches made to any of the pro-
`
`Page 12 of 17
`
`8
`gramsthat havenot been tested by the quality assurance
`process. The list of patches may be placed in the order
`of patch number or maybe in any order depending on
`how quickly the patch needs to be processed and re-
`leased to specific remote systems 12,
`the process of
`which will be described. When a patch reaches the top
`of the list, the quality assurance process tests the pro-
`gtam with the patch applied to it to ensure that the
`patched program operates satisfactorily. After
`the
`patch has been tested by the quality assurance process
`and determined to operate satisfactorily, if the tested
`patch has a patch number one greater than the patch
`threshold value, the threshold value is incremented by
`one so that the processed patch will be available to the
`remote computer systems.
`If the processed patch has a patch number two or
`more greater than the patch threshold value, then the
`threshold value is not incremented and the tested patch
`is not released to the remote computer systems 12 until
`all of the patches having patch numbers between the
`patch threshold value and the patch number of the
`tested patch have also been tested, unless special provi-
`sions are made, the details of which will be described
`herein.
`Once a patch P has been made to a program and has
`been recorded in the data store 28, the patch is exam-
`ined to determineif it is applicable to different versions
`of the same program asindicated at blocks 212 and 214.
`When the patch P is detected as being applicable to
`other versions of the same program, the user creating
`the patch P is prompted to confirm whether the patch P
`should be applied to the applicable versions of the same
`program. If it is desired to apply the patch to the other
`versions of the program, the first checksum of the patch
`P is examined and compared with the second checksum
`of the last patch made to the applicable versions to
`determineif the checksumsare identical as indicated at
`block 216. If the first checksum of the patch P is the
`same as the second checksum assigned to the last patch
`madeto the applicable versions, the patch P is automati-
`cally applied to the applicable versions of the same
`program along with the patch numberN andthe appro-
`priate checksums and stored in the data store 28 as
`indicated at blocks 218 and 220.
`However, if the first checksum assigned to the patch
`P applied to the first version and the second checksum
`of the last patch applied to an applicable version of the
`same program are notidentical, the patch is applied to
`a copy of the applicable version of the program and the
`differences between the patched copy of the applicable
`version and the patchedfirst version are determined. In
`addition, the differences between the unpatched first
`version and the unpatched applicable version are deter-
`mined. The twosets of differences are compared and if
`equivalent, the patch is applied to the applicable ver-
`sion.
`
`If the resulting differences between the programs are
`not equivalent to the patch that is being applied to the
`applicable version of the same program, then manual
`intervention must be used if the patch P is to be applied
`to the program as indicated at block 226. The patch may
`be entered to the applicable version under the same
`patch number or as a new patch having a new patch
`number.
`Oncethe patch has been madeto all of the applicable
`versions of the same program,the user is prompted to
`indicate whether the patch Pyis related to any of the
`previous patches Pxy_; made to the same program orif
`
`20
`
`25
`
`30
`
`40
`
`45
`
`30
`
`55
`
`60
`
`65
`
`Page 12 of 17
`
`

`

`5,155,847
`
`5
`
`25
`
`35
`
`40
`
`45
`
`50
`
`20
`
`9
`10
`the patch Pais related to another program in the same
`patches which exceed the threshold value assigned to
`version of programs. If the patch Px; is related to an-
`the group that the remote system belongs.
`other patch Px_., the patches Py: made to each version
`To