`Kirouac et al.
`
`[54]
`
`[75]
`
`[73]
`
`[21]
`[22]
`[51]
`
`[52]
`
`(38)
`
`[56]
`
`METHOD AND APPARATUS FOR
`UPDATING SOFTWARE AT REMOTE
`LOCATIONS
`
`Inventors: Donald L. Kirouac, Thornhill;
`William A. Porrett, Unionville;
`Marek J. Czerwinski, Scarborough,
`all of Canada
`
`Assignee: Minicom Data Corporation,
`Markham, Canada
`
`Appl. No.: 227,799
`Filed:
`Aug. 3, 1988
`Tint, C15 oo... ceceeeeererees GO6F 7/00; GO6F 9/00;
`GO06F 13/00
`UF A spe score reescrces 395/600; 395/650;
`395/200; 364/DIG. 1; 364/DIG. 2
`Field of Search ................ 364/300, 200 MS File,
`364/900 MS File; 395/600, 650, 200
`References Cited
`U.S. PATENT DOCUMENTS
`4,558,413 12/1985 Schmidt et al. ...........0-.. 364/300
`s 364/900
`4,630,234 12/1986 Holly.......
`
`we 364/900
`4,641,274 2/1987 Swank .........
`» 364/300
`:
`4,714,996 12/1987 Gladney etal. .
`
`w+. 364/300
`4,748,561
`5/1988 Brown ............
`+» 364/200
`.
`4,794,519 12/1988 Koizumi et al.
`
`ws» 364/200
`4,827,399 5/1989 Shibayama .......
`364/900
`4,845,665 7/1989 Heath etal. .
`
`364/200
`4,849,879
`7/1989 Chinnaswamy e
`-» 364/200
`4,858,114
`8/1989 Heath et al.
`.........
`
`... 364/900
`4,866,611 9/1989 Cree etal. ........
`5,019,963
`5/1991 Alderson etal. ........000..... 364/200
`
`Primary Examiner—Stuart N. Hecker
`Assistant Examiner—Michael A. Whitfield
`Attorney, Agent, or Firm—Nixon & Vanderhye
`
`CACOAAA AA
`
`US005 1558474
`(11) Patent Number:
`(45) Date of Patent:
`
`5,155,847
`Oct. 13, 1992
`
`[57]
`ABSTRACT
`A method and system are provided for updating the
`software used in remote computer systems from a cen-
`tral computer system. The method includes storing in
`the central computer system, copies of the software
`executable used in each remote computer system. When
`the copies of the software in the central computer sys-
`tem are upgraded, for example, to correct the software,
`to add newfacilities, to change user interfaces, to make
`cosmetic changes, to improve performance, etc., each
`change made to the software is monitored and stored.
`The remote computer systems are permitted access to
`the central computer system via communication links
`and the software in the remote computer systems and
`the corresponding software in the central computer
`system are compared. All of the changes that have been
`made to the software at the central computer system
`which have not been made to the corresponding soft-
`ware at the remote computer system accessing the cen-
`tral computer are detected. The detected changes are
`then transmitted to the remote computer system and
`applied to the software therein in order to upgrade the
`software in the remote computer system. The upgraded
`software in the remote computer system is examined to
`ensure that the software has been changed correctly.
`The method allows the software at the remote com-
`puter systems to be upgraded even while the software at
`the remote site is being used. The system and method
`also allow the software used in the remote computer
`systems to be upgraded when the remote computer
`systems use different versions of the software and allow
`the software to be upgraded in a variety of hardware
`environments and operating systems.
`
`32 Claims, 7 Drawing Sheets
`
`Petitioner Microsoft Corporation - Ex.1007, p.1
`Petitioner Microsoft Corporation - Ex.1007, p.1
`
`
`
`U.S. Patent
`
`Oct. 13, 1992
`
`Sheet 1 of 7
`
`5,155,847
`
`
`
`Figure 1
`
`Petitioner Microsoft Corporation - Ex.1007, p.2
`Petitioner Microsoft Corporation - Ex.1007, p.2
`
`
`
`U.S. Patent
`
`Oct. 13, 1992
`
`Sheet 2 of 7
`
`5,155,847
`
`(RAO Ae ee ee eee eee eee eee eee esses cee eee ee eeee nent een en eee cee eee eens tees eee eereneeseeees,
`
`aee|ee|
`
`
`MP1 [Cko | OP1 | Cko ||MP2Cko|OP2|Ckol|MPa: Cko Lora {cko
`lea Pe|GX
`
`ps
`|Gcu
`
`Gq! 28 Cki
`
`Ge
`
`Ce
`od
`
`ca
`Ck4
`
`|
`
`50
`
`a
`
`R
`Patch
`Function
`
`“i
`
`i
`i
`
`Processor
`Function
`
`Upgrades
`Detect
`Function
`
` |
`
`|
`
`|
`|
`
`Patch and
`Checksum
`
`Assign Version Assign|~“4
`Function
`Function
`
`w
`
`puter
`‘erminal
`
`6
`
`To §
`nee Paice
`a
`
`Threshold
`Memory
`
`Figure 2a
`
`Petitioner Microsoft Corporation - Ex.1007, p.3
`Petitioner Microsoft Corporation - Ex.1007, p.3
`
`
`
`U.S. Patent
`
`Oct. 13, 1992
`
`Sheet 3 of 7
`
`5,155,847
`
`to Program History
`
`32
`
`Function
`
`Section
`
` Validation
`
` Verification
`
`7
`
`from Remote Computers
`
`to Remote Computers
`
`12
`
`1 co4
`
`.
`Figure 2b
`
`Petitioner Microsoft Corporation - Ex.1007, p.4
`Petitioner Microsoft Corporation - Ex.1007, p.4
`
`
`
`U.S. Patent
`
`Oct. 13, 1992
`
`Sheet 4 of 7
`
`5,155,847
`
`Figure 3a
`
`Programmer
`makes copy
`
`202
`
`
`
` System
`
`extracts differences
`
`between old and
`
`204
`
`Petitioner Microsoft Corporation - Ex.1007, p.5
`Petitioner Microsoft Corporation - Ex.1007, p.5
`
`Programmer
`applies changes
`manually to
`Module
`
`
`
`
`
`
`
`
`of Module
`new Module
` Record version #|210
`
`
`
`U.S. Patent
`
`Oct. 13, 1992
`
`Sheet 5 of 7
`
`5,155,847
`
`Figure 3b
`
`Petitioner Microsoft Corporation - Ex.1007, p.6
`Petitioner Microsoft Corporation - Ex.1007, p.6
`
`
`
`U.S. Patent
`
`Oct. 13, 1992
`
`Sheet 6 of 7
`
`5,155,847
`
`Yes
`
`ND SESSION
`
`|
`
`308
`
`No
`
`Any
`Priority
`Patches 7
`
`307
`
`No
`
`O)
`
`Yes
`
`
`
`
`vs
`
`Out of
`changes
`
`No
`
`Figure 4a
`
`(®)
`
`Petitioner Microsoft Corporation - Ex.1007, p.7
`Petitioner Microsoft Corporation - Ex.1007, p.7
`
`
`
`U.S. Patent
`
`Oct. 13, 1992
`
`Sheet 7 of 7
`
`5,155,847
`
`
`
`Transmits
`changes
`line-by-line
`with verity
`
`
`
`
`Figure 4b
`
`Petitioner Microsoft Corporation - Ex.1007, p.8
`Petitioner Microsoft Corporation - Ex.1007, p.8
`
`
`
`METHOD AND APPARATUS FOR UPDATING
`SOFTWARE AT REMOTE LOCATIONS
`
`BACKGROUND OF THE INVENTION
`
`Thepresent inventionrelates 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 methods are used by software
`suppliers to upgrade the existing software that is used
`by their customers. These methods include 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-
`sionsof their software on floppy disks and distribute the
`disks via an appropriate service to all of its customers.
`However, a number of problemsexist in this type of
`software support method in that an upgraded floppy
`disk version of the softwareis 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 4
`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.
`
`5
`
`5
`
`20
`
`tw LA
`
`40
`
`50
`
`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 ofsaid 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;
`
`35
`
`65
`
`1
`
`5,155,847
`
`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 made to the corre-
`sponding software that have not been madeto the soft-
`ware in said remote computer systems;
`transmitting the identified changes to said remote
`computer system and applying the changes to 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 upgrading soft-
`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;
`input
`terminals at
`the central computer system
`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 made to 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 changes to the software therein to upgrade the soft-
`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
`Temote 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 checksums to 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 same time.
`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
`
`Petitioner Microsoft Corporation - Ex.1007, p.9
`Petitioner Microsoft Corporation - Ex.1007, p.9
`
`
`
`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
`
`An embodiment ofthe 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. 3¢ is a portion of a flowchart illustrating the
`operation of the portion illustrated in FIG. 2a;
`FIG. 3¢ is another portion of a flow chart illustrating
`the operation of the portion illustrated in FIG. 2a.
`FIG. 4a is a portion of a flowchart illustrating the
`operation of the portion illustrated in FIG. 24; and
`FIG. 44 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
`shown for 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 computer system 14 is connected to
`the remote computer systems 12 via communication
`links 16, the links typically being a packet switching
`network to allow the changes that have been made to
`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 madeto 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 group distri-
`bution number than the other group of remote com-
`puter systems positioned between concentric circles 205
`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
`
`15
`
`25
`
`30
`
`40
`
`45
`
`350
`
`55
`
`60
`
`65
`
`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 “‘y” denoting the numberof the
`optional program since a variety of optional 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
`OP),. Whenever a remote computer system 12 is receiv-
`ing the mandatory programs MP, and optional pro-
`grams OPx,, 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 copy ofthe first 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 newpurchaser
`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 made to the origi-
`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 made to
`the first version of the programs, so that the new pur-
`chasers areinitially 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 MP; and optional programs OP2y are stored in
`the data store 28 so that upgrades can be madeto 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 byits
`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 includes at Jeast 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.
`Each time a user accesses the data store 28 to upgrade
`one or more of the mandatory or optional programs
`
`Petitioner Microsoft Corporation - Ex.1007, p.10
`Petitioner Microsoft Corporation - Ex.1007, p.10
`
`
`
`5
`stored therein, all of the changes made to a program
`during that session are categorized as a patch Pa{V=i
`to z), wherein '‘N"is the numberof the patch and “V”
`is equal to the numbers oftheall of the versions of the
`same program to which that the patch is applicable and
`to which it 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, thefirst 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 upgraded is
`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 made to 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 centra] computer sys-
`tem 14 are transmitted to the correct remote computer
`systems 12 and applied to the corresponding software
`therein. The system patcher section S4 also ensures that
`the software in the remote computer systems 12 is the
`same as 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 which is 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 made to 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 made tothe first version
`ofone of the mandatory programs MP) andtherearesix
`different versions of the mandatory programs MP} to
`MPs that have beenreleased by the vendorthat are used
`in the remote computer systems 12, the value of the
`counter 29 is examined and its 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 made to the programs
`in the data store 28. Thus, if a total of six patches have
`been previously made, the above-mentioned patch P
`madeto thefirst version of the one mandatory program
`will be assigned patch number 7 (N=7).
`Thereafter, the other versions of the mandatory pro-
`grams MP2 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 numbers of 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
`
`10
`
`25
`
`40
`
`50
`
`55
`
`60
`
`5,155,847
`
`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 al] 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 Cka and Cka41 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 changes to 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 madeto another program in the
`same version of programs. When the 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 which it 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 Pyis
`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 OPs) of the optional program
`OP}; will be examined to determine if the patch Pyis
`applicable thereto. The process of detecting related
`patchesis 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 withoutintroducing errors. For example,if the
`threshold value is 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 made for the 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 34 the operation of the
`program history section 32 will now be described. Ini-
`
`Petitioner Microsoft Corporation - Ex.1007, p.11
`Petitioner Microsoft Corporation - Ex.1007, p.11
`
`
`
`5,155,847
`
`7
`tially as mentioned previously, when the different ver-
`sions of the mandatory programs MP;
`to MPa»and
`associated optional programs OP),to OPy;,are supplied
`to the remote computers systems 12, copies of the pro-
`gramsare storedin 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 imageof 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 passwords to prevent the
`occurrence of unauthorized access to the programs.
`After access has been accomplished, the user chooses
`the programthatis to be changed inthis case, one of the
`mandatory programs MP. The copy function 38 in turn
`creates a copy of the one program MP havingall ofthe
`previous patches P that have been madeto the program
`applied thereto as indicated at block 202. The checksum
`assign function 46 examines the copied program and
`recalculates a checksum Ckx for the copied program
`which represents an image of the program. The check-
`sum CK,is 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 user is 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 programs are grouped
`as a patch P. The codeassign function 44 examines the
`counter 29 and in turn assigns the patch P, a patch
`numberN, 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 number N, the checksum assign func-
`tion 46 assigns the patch, a second checksum Cky-+) as
`indicated at block 210, the second checksum represent-
`ing an image of the program with the patch applied to
`it.
`
`40
`
`gramsthat have not been tested by the quality assurance
`process. Thelist of patches maybe 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 thelist, the quality assurance process tests the pro-
`gram 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 valueis 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 havealso 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 determineifit is applicable to different versions
`of the same program as indicated 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 whetherthe patch P
`should be applied to the applicable versions of the same
`program. Ifit is desired to apply the patch to the other
`versions of the program,thefirst checksum of the patch
`P is examined and compared with the second checksum
`of the last patch made to the applicable versions to
`determine if the checksumsare identical as indicated at
`block 216. If the first checksum of the patch P is the
`sameas 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 and the 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 not identical, 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 patched first 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.
`
`When the 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 Pjy41 has been made to the same program in the
`above-mentioned manner, the checksum assign function
`46 will recalculate the first checksum CKjy+1 for the
`next patch Py; and will assign the patch Py +i, a
`second checksum Cky+2. As should be noted, each
`If the resulting differences between the programsare
`successive patch P made to a program is assigned a
`not equivalent to the patch that is being applied to the
`checksum that is also assigned to the previous patch.
`applicable version of the same program, then manual
`The above described process is performed regardless of
`intervention must be used if the patch P is to be applied
`which version of the mandatory programs or optional
`to the program as indicated at block 226. The patch may
`programs is being updated.
`be entered to the applicable version under the same
`After the checksums have been assigned to the patch,
`patch number or as a new patch having a new patch
`the patchPis stored in the data store 28 along with the
`number.
`assigned patch numberand the assigned checksums as
`65
`Once the patch has been madetoall of the applicable
`also indicated at block 210. The patch P is also for-
`versions of the same program,the user is prompted to
`warded to the quality assurance process as shown by
`indicate whether the patch Pyis related to any of the
`block 201 whereinit