|llllllllllllllllllllllllllllllllllllllllilllllllllllllllllllllllllllllllll
`Usm5155847A
`.
`5,155,847
`[11] Patent Number:
`[19]
`United States Patent
`Kirouac et a1.
`[45] Date of Patent:
`Oct. 13, 1992
`
`
`[54] NIETHOD AND APPARATUS FOR
`anfigggssm I I ARE AT REMOTE
`
`[75]
`
`Inventors: Donald L. Kirouac, Thomhill;
`WWII!!! A. Porrett, Unionville;
`March 1 Curwinski, Scarborough,
`all Of Canada
`[73] Assignee: Minicom Data Corporation,
`Markham, Canada
`[21] Appl. No.: 227:,”
`[22] Filed:
`Aug. 3, 1988
`'
`[5]]
`Int. Cl.5 .......................... G061“ 7/00;GG&6;193//00%
`[52] us. a. .................................... 395/600; 395/650;
`395/2w; 364/131G 1; 364/010 2
`[53] Field of Search ................ 364/300, 200 MS File,
`364/900 MS File; 395/600, 650, 200
`
`[56]
`
`References Cited
`US. PATENT DOCUMENTS
`4,558,413 12/1985 Schmidt et a1.
`..................... 364/300
`4,630,234 12/1986 Holly ..............
`_____ 364/900
`
`4,641,274 2/1987 Swank ............
`..... 364/900
`
`4,714,996 12/1987 Gladney et :11.
`
`----- 364/300
`4,748,561
`5/1988 Brown ................
`----- 364/300
`
`4,794,519 12/1988 Koizumi et a1.
`""" 322/1270“;
`
`4,827,399
`5/1989 Shibayama .............
`7/1989 Heath et a1. .................... 364/900
`4,845,665
`
`4,349,379
`7/1939 Chinnaswamy ct n. ..
`364/200
`
`4,858,114
`8/1989 Heath et a1. .................... 364/200
`4.366.611
`9/1989 Cree et a].
`..... 364/900
`5,019,963
`5/1991 Alderson et a1.
`................... 364/200
`Primary Examiner—Stuart N. Hecker
`Assistant Examiner—Michael A. Whitfield
`
`[57]
`ABSI'RACI'
`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 newhicmties, to change “3:; interfaces, to malt;
`cosmetic c
`ges, to improve pe ormance, etc, eac
`change made to the software is monitored and stored.
`The remote computer systems are permitted access to
`the central computer system via communication hnks'
`and the software in the ”moss computer 3
`and
`‘he °°"“P°“dm8 ”mm m the mm“ “mm“
`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 ‘0 the ”hm“ therein in ”‘1“ ‘° “FEW!“ 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
`.
`.
`.
`‘he "m0“? 5““ ‘5 hemg “uh The ”Shem “‘3 meal“
`also allow the software used in the remote oOlmputer
`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 311d operating systems.
`
`Attorney, Agent, or Firm—Nixon & Vanderhye
`
`32 Claims, 7 Drawing Sheets
`
`
`
`Page 1 0f 17
`
`'
`
`SAMSUNG EXHIBIT 1012
`
`Page 1 of 17
`
`SAMSUNG EXHIBIT 1012
`
`

`

`PS.
`
`n
`
`29913s1tc0
`
`7fo1aehS
`
`5,155,847
`
`tm
`m.m.
`aF
`
`
`1e
`
`Page 2 of 17
`
`Page 2 of 17
`
`

`

`US. Patent
`
`Oct. 13, 1992
`
`Sheet 2 of 7
`
`5,155,847
`
`MIMI-m-
`m 2cm . om MII—Ilm
`P1
`
`3 lI0
`
`P2
`
`P3
`
`
`
`
`
`
`
`
`
`. W. .W
`
`pume‘r
`ormunll
`
`:
`:
`E
`:
`;
`_
`;
`;
`;
`r
`_
`E
`"
`I
`2
`;
`r
`;
`E
`_
`;
`,
`;
`E
`:
`:
`_
`z
`;
`2
`’
`
`Vmion Anion
`Function
`
`
`
`To 5mm
`Pitch.
`
`.
`
`.
`
`‘
`
`‘
`‘
`‘
`‘
`‘
`‘
`.
`.
`.
`.
`A
`.
`‘
`I
`.
`'
`.
`.
`‘
`.
`.
`. 30
`‘
`!
`.
`‘
`‘
`.
`.
`.
`.
`.
`l
`'
`,
`.
`.
`.
`...
`l
`I
`I
`‘
`
`‘
`r
`:
`.
`:
`
`‘
`:
`:
`;
`l
`1
`;
`;
`:
`I
`1
`:
`1
`1
`:
`;
`1
`1
`E
`.
`1
`:
`=
`1
`:
`:
`§
`;
`1
`1
`j
`1
`1
`1
`1
`5
`:
`=
`:
`=
`
`l
`t
`I
`,
`.
`’
`|
`'
`~
`,
`,
`I
`,
`’
`I
`.
`I
`,
`v
`,
`,
`.
`‘
`‘
`‘
`'
`:
`.
`I
`'
`I
`I
`I
`I
`|
`:
`I
`I
`I
`I
`i
`.
`.
`
`mime-m
`
`Figure 2a
`
`Page 3 of 17
`
`Page 3 of 17
`
`

`

`US. Patent
`
`Oct. 13, 1992
`
`Sheet 3 of 7
`
`5,155,847
`
`r
`...........................................................................................................
`
`to Program History
`
`32
`
`,
`
`65
`
`
`Validation
`
`Function
`
`
`
`
`
`Detection
`And
`Examination
`Section
`
`66
`
`Verification
`Section
`
`
`
`E
`
`trorn Remote Computers
`
`to Remote Computers
`
`12
`
`14
`
`Figure 2b
`
`Page 4 of 17
`
`Page 4 of 17
`
`

`

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

`

`US. Patent
`
`Oct. 13, 1992
`
`Sheet 5 of 7
`
`5,155,847
`
`
`
`
`Em diff-mucus
`“Mean old Ind
`new modulo: for
`this version
`
`Figure 3b
`
`Page 6 of 17
`
`Page 6 of 17
`
`

`

`US. Patent
`
`Oct. 13, 1992
`
`Sheet 6 of 7
`
`5,155,847
`
`START
`
`Guam
`Connect:
`
`302
`
`o
`
`Y's
`
`lnlthl handshak-
`
`butwun ESP
`machlnu
`a cllem computer
`on SYIJD. Patch
`
`LIVI(LOGIN)
`
`-
`ND SESSION
`
`No
`
`
`
`Any
`
`Prcomy
`Any chance: to
`
`Patches 7
`and?
`
`
`308
`
`307
`
`tat nan chanp
`
`
`
`
`Changes applies
`
`
`
`Figure 4a
`
`0
`
`Page 7 of 17
`
`Page 7 of 17
`
`

`

`US. Patent
`
`Oct. 13, 1992
`
`Sheet 7 of 7
`
`5,155,847
`
`Transmit:
`
`changes
`line-by-llne
`
`with verily
`
`
`New
`
`Chocksum
`
`consistent
`
`
`
`
`Appiv chance
`on client’s
`
`mm
`
`
`
`Figure 4b
`
`Page 8 of 17
`
`Page 8 of 17
`
`

`

`1
`
`5,155,847
`
`METHOD AND APPARATUS FOR UPDATING
`SOFTWARE AT REMOTE LOCATIONS
`
`BACKGROUND OF THE INVENTION
`
`The present 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 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—
`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 damage to 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.
`
`Modern 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 prone to error, since
`the method involves manual,processes. Accordingly,
`there is a need for an improved method of upgrading
`software.
`
`SUMMARY OF 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 software at 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
`
`10
`
`IS
`
`20
`
`25
`
`3O
`
`35
`
`4O
`
`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 made to the corre-
`sponding software that have not been made to 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;
`system
`input
`terminals at
`the central computer
`through which the corresponding software may be
`upgraded, with the changes made for 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
`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 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
`
`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 “y" denoting the number of 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 1y. Whenever a remote computer system 12 is receiv-
`ing the mandatory programs MP, and optional pro-
`grams Ony, the mandatory programs and the optional
`programs are 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 of the first version of the
`mandatory programs MP1 and all of the available op-
`tional programs 0P1y 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 made to either the mandatory programs MP1 or to
`any of the optional programs OPly, 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 Ony 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 programs is released to
`new purchasers of the software via tape distribution, the
`second version of the programs including some or all of
`the changes and any additions that have been made to
`the first version of the programs, so that the new pur-
`chasers are 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 MP: and optional programs Osz 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 includes at 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 Ony 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
`
`An embodiment of 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. 3a is a portion of a flow chart illustrating the
`operation of the portion illustrated in FIG. 2a;
`FIG. 3b 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. 2b; and
`FIG. 4b is another portion of a flow chart illustrating
`the operation of the portion illustrated in FIG. 2b.
`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 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 200 and 2% are assigned a different group distri-
`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. 20 and 2b, the central com-
`puter system 14 which is 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
`
`l0
`
`IS
`
`20
`
`25
`
`30
`
`35
`
`45
`
`55
`
`65
`
`Page 10 of 17
`
`Page 10 of 17
`
`

`

`5,155,847
`
`5
`stored therein, all of the changes made to a program
`during that session are categorized as a patch PN(V=i
`to 2), wherein “N” is the number of the patch and “V”
`is equal to the numbers of the all 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, the first patch P made to any pro-
`gram regardless of its version will be assigned patch
`number 1 (N=l), the second patch made to any pro-
`gram will be assigned patch number 2 (N22), etc.
`The control software used in the central computer
`system 14 for allowing the programs in 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 patcher section
`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 made to 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 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.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`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 which it 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 CkN and Clue“. The
`checksums City and CkN+1 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 made to 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 PN is
`made to the optional program 0PM and there are six
`released versions of the software, the patch PN will be
`assigned the next available patch number “N” as deter-
`mined by the value of the counter 29. Similarly, the
`other versions 0P2; to 0P6] of the optional program
`OP” will be examined to determine if the patch PN is
`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 and is
`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 value is set at 10, only patches P. to Plocan 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 number greater 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 3b the operation of the
`program history section 32 will now be described. Ini-
`
`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 records all 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 to the first version
`of one of the mandatory programs MP1 and there are six
`different versions of the mandatory programs MP1 to
`MP6 that have been released by the vendor that 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
`number of 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
`made to 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 MP2 to MP6 are examined to detect if 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 the user is requested to
`confirm whether the patch P7 should be applied to the
`
`45
`
`50
`
`55
`
`Page 11 0f17
`
`Page 11 of 17
`
`

`

`5,155,847
`
`7
`tially as mentioned previously, when the different ver-
`sions of the mandatory programs MP1 to MPN and
`associated optional programs CPU. to 0PMare supplied
`to the remote computers systems 12, copies of the pro-
`grams are 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 Clo, rep-
`resenting an image of the original program which is 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 program that is to be changed in this case, one of the
`mandatory programs MP1. The copy function 38 in turn
`creates a copy of the one program MP1 having all of the
`previous patches P that have been made to the program
`applied thereto as indicated at block 202. The checksum
`assign function 46 examines the copied program and
`recalculates a checksum Ck); for the copied program
`which represents an image of the program. The check
`sum CKN is compared with the second checksum as-
`signed to the last patch made to the same program to
`ensure that the copied program has in 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 manner that 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 MP1 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 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 number N, the checksum assign func-
`tion 46 assigns the patch, a second checksum CkA-H as
`indicated at block 210, the second checksum represent-
`ing an image of the program with the patch applied to
`it.
`
`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 PNH has been made to the same program in the
`above-mentioned manner. the checksum assign function
`4-6 will recalculate the first checksum CKN.“ for the
`next patch PN+1 and will assign the patch PNH, a
`second checksum Clown. 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
`programs is 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 checksums as
`also indicated at block 210. The patch P is also for-
`warded to the quality assurance process as shown by
`block 201 wherein it is given a number and is placed on
`a list including other patches made to any of the pro-
`
`Page 12 0f17
`
`8
`grams that have not been tested by the quality assurance
`process. The list of patches may be placed in the order
`of patch number or may be 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-
`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 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 determine if it 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 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
`determine if the checksums are 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
`made to the applicable versions, the patch P is automati-
`cally applied to the applicable versions of the same
`program along with the patch number N 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 two sets of differences are compared and if
`equivalent, the patch is applied to the applicable ver-
`man.
`
`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.
`
`Once the patch has been made to all of the applicable
`versions o