United States Patent (19)
`Heath et al.
`
`US006006034A
`Patent Number:
`11
`(45) Date of Patent:
`
`6,006,034
`Dec. 21, 1999
`
`54 SYSTEMS AND METHODS FOR
`AUTOMATIC APPLICATION VERSION
`UPGRADING AND MAINTENANCE
`
`75 Inventors: E. ...MyNet of
`s
`s
`Australia; Steven Klos, Nashua;
`Graeme Greenhill, Londonderry, both
`of N.H.
`
`73 Assignee: Open Software Associates, Ltd.,
`Kingwood, Australia
`
`5,581,764 12/1996 Fitzgerald et al. ...................... 395/703
`5,586,304 12/1996 Stupek, Jr. et al. .................... 395/712
`5,721,911 2/1998 Ha et al. ................................. 707/100
`5,724,345 3/1998 Guarneri et al. ........................ 370/316
`5,732,266 3/1998 Moore et al. ........................... 395/651
`5,732.275 3/1998 Kullicket al...
`395/712
`5,734,898 3/1998 He ........................................... 707/203
`5,737,533 4/1998 De Hond .
`395/200.49
`5,752,042 5/1998 Cole et al. .............................. 395/712
`5,754,830 5/1998 Butts et al. ..
`395/500
`5,758.342 5/1998 Gregerson ............................... 280/602
`5,768,511
`6/1998 Galvin ......
`395/200.33
`5,794,259 4/1998 Kikinis .................................... 707/507
`5,848,421 12/1998 Brichta et al. .......................... 707/200
`OTHER PUBLICATIONS
`Kirtland, Mary, “Safe Web Surfing with the Internet Com
`ponent Download Service,” Microsoft Systems Journal, Jul.
`1996, 7 pages.
`Primary Examiner Tod R. Swann
`Assistant Examiner-Matthew Smithers
`Attorney, Agent, or Firm-Hamilton, Brook, Smith &
`Reynolds, P.C.
`57
`ABSTRACT
`References Cited
`The present invention relates to methods and Systems for
`U.S. PATENT DOCUMENTS
`maintaining application programs on a client computer in a
`4,714,992 12/1987 Gladney et al. ........................ 364/200
`client-Server network environment. The task of dynamically
`5,005,122 4/1991 Griffin et al. .....
`... 364/200
`upgrading components in the application program running
`5,008,814 4/1991 Mathur .................................... 364/200
`on a client is greatly simplified by rendering control to the
`5,019,963
`5/1991 Alderson et al. ....................... 364/200
`individual client rather than to a central server. The version
`55. 10/1992 R et s - - -
`- - - S.600
`SE t
`et al. ...
`- - - 3C updating procedures of the present invention further pro
`5. 440,723 8/1995 Arnold etal- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -395f181
`vides Steps to ensure Speedy and error-free transfer of the
`5.448,727 9/1995 Annevelink.
`... 395/600
`required files and components through an open network
`5,495,610 2/1996 Shing et al. ..
`... 395/600
`environment, Such as the Internet.
`5,555,416 9/1996 Owens et al. .....
`... 395/700
`5,577,244 11/1996 Killebrew et al. ...................... 395/703
`96 Claims, 13 Drawing Sheets
`
`21 Appl. No.: 08/707,622
`22 Filed:
`Sep. 5, 1996
`6
`51) Int. Cl. ........................................................ G06F 9/06
`52 U.S. Cl. .............................................................. 395/712
`58 Field of Search ............................... 395/712, 20051,
`395/2005, 20047, 20049,500, 181: 707/203,
`507, 200; 380/4; 370/316
`
`56)
`
`Specify application info:
`-Cient directory location
`-xecution command.
`Store in catalog file (CF).
`
`For each component.
`
`specify component info:
`--Nafie & network address
`-version identification.
`Stre is CF.
`
`322
`
`Cornpite cryptographic
`digest for component and
`stein CF.
`- - -
`
`320
`
`324
`
`328
`
`Specify directory location for
`storage of component on
`client computet, store in CF,
`
`328
`
`--
`Specify components
`330
`previously required but now
`absolete and store in CF.
`
`Specify environment variable
`holding client directory
`location store in CF
`
`340
`
`Specify network address(es)
`for obtainingfuture versions
`of catalog file, store in C.
`
`342
`
`Specify procedures to be
`executed after retiawai of
`each component or before
`of after the application.
`
`
`
`344
`
`Instacart, Ex. 1007
`
`1
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 1 of 13
`
`6,006,034
`
`14
`
`14
`
`14. 1
`
`14
`
`
`
`Central
`System
`
`14
`
`14 -1 | 14 N 14
`
`Figure 1
`
`2
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 2 of 13
`
`6,006,034
`
`24
`
`24
`
`24
`
`Figure 2A
`
`
`
`29
`
`Components
`
`can ie n t
`
`2 2
`
`22a
`
`22b
`
`22C
`
`22d
`
`Figure 2B
`
`23
`
`
`
`.
`
`3
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 3 of 13
`
`6,006,034
`
`START
`
`Compose downloadable catalog file
`and store On Server
`
`Retrieve catalog file from server using Launcher
`
`Launcher processes catalog file
`
`300
`
`302
`
`304
`
`Launcher unpacks catalog file to initiate
`application version check
`
`306
`
`Launcher downloads required application
`components
`
`308
`
`310
`
`312
`
`314
`
`316
`
`317
`
`Launcher authenticates components
`
`Pre-launch execution
`
`Execute application
`
`
`
`
`
`Launcher stores catalog file information in
`persistent cache on client
`
`ENO
`
`Figure 3A
`
`4
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 4 of 13
`
`6,006,034
`
`START
`
`
`
`
`
`Specify application info.
`- Client directory location
`- Execution Command.
`Store in catalog file (CF).
`
`320
`
`For each component
`
`
`
`
`
`
`
`
`
`
`
`322
`
`
`
`
`
`
`
`
`
`Specify component info:
`-Name & network address
`- Version identification.
`Store in CF.
`
`324
`
`Compute Cryptographic
`digest for component and
`store in CF.
`
`Specify directory location for
`storage of component on
`client computer, store in CF.
`
`326
`
`328
`
`Specify components
`previously required but now
`obsolete and store in CF.
`
`330
`
`Specify environment variable
`holding client directory
`location, store in CF
`
`340
`
`Specify network address(es)
`for obtaining future versions
`of catalog file; store in CF.
`
`342
`
`Specify procedures to be
`executed after retrieval of
`each component or before
`or after the application.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Figure 38
`
`5
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 5 of 13
`
`6,006,034
`
`346
`
`350
`
`Figure 3C
`
`
`
`24
`
`
`
`
`
`22a
`
`
`
`S-I- 352
`
`Current catalog
`representation
`
`!-354
`
`6
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 6 of 13
`
`6,006,034
`
`
`
`
`
`
`
`User runs Launcher
`program explicitly
`
`400
`
`User selects application
`in cache on client
`
`
`
`Userspec
`ifies network
`address of catalog for new
`application
`
`Launcher retrieves catalog
`file from specified network
`address or from local disk.
`
`403
`
`Figure 4A
`
`START
`
`
`
`Specify that application
`icon is to ?un Launcher
`instead of application
`program.
`
`404
`
`Specify network address of
`catalog file as a parameter
`for launcher program.
`
`405
`
`END
`
`Figure 48
`
`
`
`
`
`
`
`
`
`START
`
`User invokes
`application con
`
`User explicitly runs
`Launcher program
`or function.
`
`Launcher executes with a
`reference to the catalog file
`as a parameter.
`
`launcher retrieves catalog
`file from specified network
`address or from local disk.
`
`
`
`
`
`408
`
`409
`
`Figure 4C
`
`7
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 7 of 13
`
`6,006,034
`
`
`
`
`
`
`
`
`
`Read application info in
`catalog file
`
`410
`
`Examine directory or
`environment variable if
`specified in catalog file
`
`412
`
`Set specified directory or 414
`relative directory for storage
`of components on client
`For each component
`
`Read component file name
`and version number
`
`416
`
`
`
`
`
`
`
`
`
`
`
`
`
`426
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`ls
`component
`With same version
`number present
`On client?
`
`419
`Does
`component
`On client have
`same cryptographic
`digest?
`
`Yes
`
`Retrieve component from
`specified network address
`and store on client
`
`Compute cryptographic
`digest on retrieved
`component
`
`cryptographic
`digest correct
`for retrieved
`component?
`
`Run procedure specified 424
`for execution after retrieving
`each component
`
`
`
`Figure 4D
`
`8
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 8 of 13
`
`6,006,034
`
`Delete components
`previously required but
`now obsolete
`
`Store a representation of
`the retrieved catalog file on
`the client computer
`
`Run procedure specified
`for execution prior to
`running application
`
`Execute specified
`application module(s)
`
`
`
`430
`
`432
`
`434
`
`436
`
`Run procedure Specified 436
`for execution after
`running application
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Figure 4E
`
`9
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 9 of 13
`
`6,006,034
`
`Launch application
`
`
`
`Tinner on
`
`Retrieve catalog
`
`
`
`502
`
`504
`
`506
`
`Time limit
`exceeded?
`
`
`
`
`
`
`
`510
`
`Select another server
`
`
`
`
`
`Continue retrieving catalog
`
`512
`
`
`
`Catalog retrieval
`finished?
`
`Yes
`
`Process catalog
`
`516
`
`Figure 5
`
`10
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 10 of 13
`
`6,006,034
`
`
`
`
`
`
`
`
`
`START
`
`Period-driven
`?
`
`608
`
`Within period
`
`Retrieve catalog and
`perform update process
`
`610
`
`Execute application
`
`Figure 6A
`
`
`
`
`
`
`
`System boot-up
`
`611
`
`Yes
`
`Boot-driven
`?
`
`614
`Retrieve catalog and
`perform update process
`
`END
`
`No
`
`Figure 6B
`
`11
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 11 of 13
`
`6,006,034
`
`702
`
`704
`
`7O6
`
`708
`
`710
`
`712
`
`START
`
`Open Web page with Web
`browser
`
`User selects link to catalog
`
`Web browser executes
`Launcher plug-in or
`Launcher browser Control
`
`Launcher processes
`catalog
`
`Update
`
`
`
`Execute application
`
`END
`
`Figure 7A
`
`12
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 12 of 13
`
`6,006,034
`
`714.
`
`716
`
`718
`
`720
`
`722
`
`724
`
`726
`
`START
`
`
`
`Open Web page with Web
`browser
`
`User selects link to catalog
`
`Web browser invokes
`Launcher helper
`application
`
`Launcher processes
`catalog
`
`Exit Web browser
`
`Execute application
`
`END
`
`Figure 7B
`
`13
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 13 of 13
`
`6,006,034
`
`
`
`
`
`
`
`
`
`User uses standard Web 728
`browser to display a Web
`page containing application
`catalog reference.
`
`User selects the reference
`(hotlink) to the catalog file.
`
`Web broWSer retrieves the
`catalog file.
`
`730
`
`732
`
`
`
`s
`Launcher program
`of function
`installed?
`
`Yes
`
`Retrieve Launcher program 736
`or function from Server,
`install and register with
`browser.
`
`Web browser invokes the
`Launcher and passes it the
`catalog file for processing.
`
`
`
`END
`
`Figure 7C
`
`14
`
`

`

`6,006,034
`
`1
`SYSTEMS AND METHODS FOR
`AUTOMATIC APPLICATION VERSION
`UPGRADING AND MAINTENANCE
`
`BACKGROUND OF THE INVENTION
`The present invention relates to methods and Systems for
`maintaining components of application programs in a client/
`Server network environment. A client is a personal computer
`or a WorkStation that operates on a network to execute
`various application programs. A Server is typically a larger,
`centralized computer on the network which Services the
`clients by providing programs, files and data, and by con
`trolling hardware devices shared by the clients.
`An application program typically comprises a number of
`components each of which exists as a separately addressable
`file, and where each component is identified by a version
`number, perhaps indicating its creation date. An application
`program may typically undergo numerous revisions and
`updates throughout the course of its operational existence on
`the client. In the network environment, an application pro
`gram on the client can be kept current by replacing one or
`more of Such components, or by adding or deleting compo
`nents. The components having the latest version numbers
`can be maintained on the central Server and distributed from
`the Server to each individual client as needed through a
`Standard file transfer protocol.
`In the prior art Systems, the version upgrading or com
`ponent upgrading procedures are driven by the central Server
`through complex interactions between the Server and client
`Systems.
`
`15
`
`25
`
`SUMMARY OF THE INVENTION
`Server-driven methods, however, are inherently unsuited
`for applications running on open-architecture networks,
`Such as the Internet or intranet Settings, in which the
`individual clients are difficult to access and control. The
`methods and Systems of the present invention significantly
`improve the version updating process in a client-server
`environment in which Such updating requires frequent and
`efficient deployment of the application components. In
`particular, the present invention shifts the version updating
`control to the individual client rather than the server, not
`only to reduce processing burden on the Server but also to
`enable version updating in an open network environment,
`Such as the Internet, where the Source providing Servers
`generally cannot control the remote clients. The methods of
`the present invention further adds Security and protection
`from potential file corruption and undue delays during file
`transfer from a Server to a client. By intelligently and
`automatically Selecting to download and update only the
`needed and changed components of an application program,
`the present method alleviates the concerns of time and
`efficiency in any client-server network environment which
`requires highly dynamic application updates.
`In the preferred embodiment, the present invention
`involves maintaining on a Server the components of an
`application program, each having a version identification,
`and maintaining a catalog of components with the version
`identifications. The components may include executable
`codes, library files, parameter files, and data files of the
`application program. The application program is further
`maintained at a client. In response to a call to the Server from
`the client, the Server is caused to download the catalog to the
`client and the client compares the version identifications
`between the components maintained on the Server as indi
`cated in the downloaded catalog and the components main
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`tained on the client. The application program on the client is
`updated by downloading from the server to the client the
`Selected components for which the version identifications do
`not match. The updated application program is then
`executed on the client.
`The above preferred method further comprises updating
`the application program on the client by downloading from
`the Server to the client the Selected components Specified in
`the catalog which are new and, therefore, not present on the
`client. This also makes possible the initial installation of the
`application on the client. Similarly, the catalog file can
`Specify and cause to delete from the client any components
`previously included in the application program which are no
`longer needed to execute in the updated version.
`In the preferred embodiment, the catalog is used to
`specify: network addresses of other servers from which the
`catalog or component modules can be retrieved in Subse
`quent updates, directory locations on the client for Storing
`the downloaded components for proper execution of the
`application program on the client; and procedures for
`executing programs on the client, Such as virus Scanning
`code, after each component is downloaded as well as prior
`to and following the execution of the updated application
`program.
`In the preferred embodiment, the catalog file retained on
`the client Specifies a maximum wait-time interval to limit
`any delay associated with updating the application program,
`and a list of further Servers on the network, each including
`a copy of the catalog file. When, in response to the call to the
`server from the client, the server fails to download the
`catalog within the maximum wait-time interval, the client
`cancels the download and routes the call to one of the further
`Servers to engage a new download and So on until the catalog
`has been downloaded within the Specified maximum wait
`time interval.
`In the preferred embodiment, the catalog file is specified
`with a cryptographic digest for each component to ensure its
`authenticity and integrity. The client updates the application
`program on the client by downloading and replacing
`Selected components for which the cryptographic digests do
`not match, and the client further computes the cryptographic
`digests on the client to ensure that each of the downloaded
`components is authentic and that each has not been cor
`rupted during the download transmission.
`In the preferred embodiment, the frequency of the updat
`ing procedure is defined on a periodic basis or on an
`event-driven basis. For example, a predefined time interval,
`Such as a day or week can be specified in the catalog, or by
`a user, and the application program is updated only on the
`first time the application is run in a specified time interval.
`In another embodiment, the application program on the
`client is automatically updated by an operating System or by
`a launcher program executed by a startup command on the
`client each time the client is booted up. In Such an
`embodiment, the application program is caused to be
`updated regardless of whether the application program is
`executed at the client. Similarly, the client can be configured
`to update the application program periodically only as
`necessary to replace either outdated or corrupted
`components, or to delete any modules no longer needed, or
`to add any new modules.
`In the preferred embodiment, the call to the server from
`the client is transmitted to the Server by a launcher program
`on the client which operates as a proxy to the application
`program. Selecting the application from the client to execute
`the program engages the launcher to communicate with the
`
`15
`
`

`

`3
`Server, to cause the Server to download the catalog file, and
`to update the application program on the client and execute
`the updated application program on the client. In Such an
`embodiment, the launcher can be implemented as a Separate
`utility program or as a functional component of an operating
`System of the client and run invisibly in the background.
`Once the catalog file has been retrieved and processed in
`accordance with the method of the present invention, the
`Status of each updating of the application program, including
`names of the components replaced, deleted or added on the
`client and related procedures, can be recorded in a file on the
`client for tracking and reporting the program usage and
`updates. Information in the downloaded catalog file, which
`at least includes the list of names and version identifications
`of the components for the updated application program, is
`Stored on the client to be used in a Subsequent update. The
`catalog file can also be specified to include a procedure to
`delete the components following the execution of the
`updated application program to free up disk space on the
`client.
`With the method of the present invention, controlling a
`version upgrade at the client through an open network
`environment, Such as the Internet, can be easily imple
`mented. In the Internet environment, for example, the call to
`a Server for updating the application program can be made
`through a hypertext link on a Web browser directed to the
`catalog on the Server. The launcher program can be inte
`grated into the browser as a helper application, a plug-in
`module, or as a browser control. When the link is selected
`from the client browser, the launcher is executed to update
`the corresponding application components on the client. The
`downloading chores of the update can be accomplished
`through Standard file transfer methods Such as the file
`transfer protocol or the hypertext transfer protocol. The
`catalog file can also be specified to include a procedure to
`install on the client desktop an icon or a shortcut which
`enables the end user to run the application without accessing
`the Web page in Subsequent updates.
`The above and other features of the invention including
`various novel details of construction and combinations of
`parts will now be more particularly described with reference
`to the accompanying drawings and pointed out in the claims.
`These features are described with reference to installing and
`maintaining complete applications, but can also be used for
`individual components Such as data files. It will be under
`stood that the particular devices and methods embodying the
`invention are shown by way of illustration only and not as
`limitations of the invention. The principles and features of
`this invention may be employed in varied and numerous
`embodiments without departing from the Scope of the inven
`tion.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 is a graphical illustration of a closed network
`environment including a central distribution Server.
`FIGS. 2A and 2B illustrate generally the client-controlled
`network environment of the present invention.
`FIG. 3A illustrates the general framework in which the
`launcher program on a client controls a version update in
`conjunction with the procedure Specified in the catalog file.
`FIG. 3B illustrates the process involved in composing the
`preferred catalog file within the process as described in FIG.
`3A.
`FIG. 3C is a graphical illustration of the user perspective
`of the launcher driven client.
`FIG. 3D is a graphical illustration of the version check
`proceSS on the client.
`
`1O
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6,006,034
`
`4
`FIG. 4A illustrates one embodiment of the launcher
`configuration.
`FIGS. 4B to 4E illustrate the preferred embodiment of the
`launcher configuration and the detailed preferred updating
`process of the present invention.
`FIG. 5 illustrates another aspect of the present invention
`relating to minimizing download wait time.
`FIGS. 6A and 6B illustrate a further aspect of the present
`invention relating to client configuration.
`FIGS. 7A through 7C illustrate preferred implementations
`of the methods of the present invention in the Internet
`environment.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`Referring to the drawings, FIG. 1 illustrates a closed
`network 10 Such as a local area network in which a central
`distribution server 12 controls the distribution of application
`Software running on each of the multiple clients 14 within
`the network 10. In such an environment, the version updat
`ing typically requires the Server 12 to undergo a complex
`task of updating each client 14 individually. Such procedure
`requires significant processor power particularly if the cli
`ents must be updated at the same time. Further, a client
`program may be updated unnecessarily when the program is
`not routinely accessed at the client.
`In an open network architecture, Such as the Internet and
`intranets, the centralized program updating is difficult due to
`the fact that the individual clients are not necessarily con
`trolled by the server. In the Internet, for example, a Web
`Server communicates with a remote client on an anonymous
`basis and cannot easily control the parameters of the client.
`FIG. 2A illustrates a preferred method of the present inven
`tion wherein a client 22 controls the process of a Software
`upgrade in the client utilizing one or more Servers 24 on a
`network. More particularly, in FIG. 2B, a software version
`upgrade can be initiated through executing an application
`program on the client 22. The execution command transmits
`a request signal 23 to the server 24 which holds the latest
`application components. In the preferred embodiment, the
`Server responds by downloading a catalog of a list of the
`application components, each identified with the latest Ver
`Sion number. Here, the Server includes either a single
`computer or multiple computers or other Servers networked
`together. The catalog file is processed by the client 22 to
`Selectively identify and retrieve required components of the
`application program from the Server 24.
`A persistent cache directory 22a on the client 22 Stores a
`representation of the catalog file 26, which at least includes
`the updated list of components and version numbers on the
`client, for a comparison in a Subsequent version check. The
`components may either be Stored in cache 22a or in program
`directories, Such as 22b to 22d, Specified in the catalog file
`26, for proper execution. It can be seen that only the
`components which require updating are downloaded, and
`they are only downloaded when there is a need because the
`program is being accessed at the client.
`FIG. 3A is a preferred flow Sequence of a version updating
`process of the present invention. The process first involves
`packaging a catalog file 300 in the Server. The catalog file is
`downloadable from the Server to a client using Standard
`network transfer protocol, Such as the file transfer protocol
`or the hypertext transfer protocol. In the preferred
`embodiment, as described in FIG. 3B, a catalog file is
`prepared to include application information 320 which
`includes the client download directory location(s) and the
`
`16
`
`

`

`6,006,034
`
`15
`
`25
`
`35
`
`40
`
`S
`execution command to the application program. For each
`component that is now required, the catalog file includes at
`324 a version identification, code or data size, and the
`network address(es) where the latest version of the compo
`nent is Stored. The components themselves may also be
`included within the catalog file in certain updating situa
`tions. For each component, a cryptographic digest is com
`puted and Specified in the catalog at 326. Such an encryption
`is used later to Verify authenticity and integrity of the
`component following the completion of a download in the
`client. The catalog further includes at 328 for each compo
`nent directory or Subdirectory locations on the client where
`the component must reside in order to allow proper execu
`tion of the application program.
`Additionally, the catalog includes at 330 identifications of
`components previously required in the application program
`that are now obsolete in the new version. At 340, the catalog
`file can also include the client's System environment vari
`ables relative to the installation requirements in different
`client directory locations. An environment variable is a
`System wide parameter commonly used to Store Small items
`of information to be shared between multiple programs. In
`one embodiment of the invention, certain environment vari
`ables hold references to directories in which application
`components are Stored on the client. The catalog can also
`include at 342, network locations Storing future versions of
`the catalog file and/or the associated application compo
`nents. The catalog file can further include at 344 procedures
`necessary for executing codes after retrieval of each com
`ponent or prior to and/or following the execution of the
`updated application program.
`Returning to FIG. 3A, the catalog file is retrieved at 302
`from the Server in response to a call from the client. In a
`preferred embodiment, as illustrated in FIG. 3C, the client
`22 of the present invention includes a launcher program 348
`which is automatically activated when a user Selects to run
`the application underlying icon 350 on a desktop window
`346 of the client system 22. The launcher 348 serves as a
`proxy to the application program and communicates with the
`Server 24 over a network to request a download of the
`catalog file.
`In FIG. 3A, the launcher processes the downloaded cata
`log file at 304 and begins to unpack the catalog file to initiate
`a version check at 306. The version comparison in these
`Steps involves comparing the contents of a new catalog file
`352 downloaded from the server, as shown in FIG. 3D, with
`the existing representation of the catalog file 354 Stored in
`persistent cache 22a of the client 22. The contents of the new
`catalog 352 reflect the latest component versions, and the
`catalog 354 in cache 22a lists the component versions
`presently installed on the client. The comparison described
`in these Steps is only a basic requirement in an updating
`procedure. Other Steps, as will be discussed later, can be
`Specified in the catalog file and executed by the launcher on
`the client.
`Further referring to FIG. 3A, the launcher at 308 engages
`the Server to download the required components for a proper
`update as defined in the catalog file in 306. The encrypted
`components are authenticated at 310 through the crypto
`graphic digests Specified in the catalog file. The pre-launch
`code prescribed in the catalog file, Such as a virus Scan, is
`executed at 312. The updated and Verified application pro
`gram is launched and executed at 314 followed by any
`post-launch activities at 316 also defined in the catalog file.
`Information in the catalog file, which at least includes the
`updated list of components and version numbers on the
`client, is stored at 317 in cache on the client until the
`Subsequent version update.
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`The launcher program can be configured in different ways
`to accommodate users with different options to control and
`update the application program. In one embodiment, as
`shown in FIG. 4A, the launcher is a Stand-alone program
`which can be executed through a desktop icon 400 on a
`client window. Selecting the icon executes the launcher
`program which provides a user with a dialog window to
`either Select an existing application program to update at 401
`or Specify the network address of the catalog file for a new
`application at 402. Through the launcher dialog window(s),
`a user can Select any application program either to execute,
`or to update and execute, or Simply to update the compo
`nents therein. In another embodiment, as shown in FIG. 4B,
`an icon directed to the application program can be installed
`on the client desktop window at 404. Selecting the icon
`automatically launches the launcher program in the back
`ground to begin an updating process. At 405, the launcher
`program in this embodiment is pre-configured with network
`address(es) of the catalog file as a parameter of the program.
`FIGS. 4C through 4E further illustrate the preferred
`process of the present invention. In the preferred
`embodiment, a user may either invoke at 406 an icon
`directly associated with the application program or run the
`launcher program at 407 to Select a particular application
`program to update. In either option, the launcher program,
`executes with the address of the catalog file to initiate
`program update at 408. At 409, the launcher retrieves the
`catalog file from the Specified Server address or from a local
`disk, and, at 410, the launcher reads the application infor
`mation in the retrieved catalog file. The application infor
`mation is as described in FIG. 3B and includes the client
`download directory location(s) and the execution command
`and procedure relative to the application program. The
`catalog file is further examined for any environment variable
`pertaining to the client System which instructs the launcher
`as to how the components are installed on the client. At 414,
`the launcher designates appropriate directories on the client
`where the components should be Stored.
`The process for identifying the individual component files
`to download from the server begins at 416. At 416, the
`launcher reads the next component file name and version
`number or identification from the retrieved catalog file of the
`latest component versions made available on the Server.
`Each component version number is compared at 418 with
`the current component version numbers listed in a previous
`catalog file representation Stored in cache on the client. If the
`version number is correct, the cryptographic digest is
`checked at 419. Any component not on the client or showing
`different version numbers or different cryptographic digest
`are Selected and retrieved from the Specified Server location
`420. The cryptographic digest is computed on a retrieved
`component at 421 and confirmed at 422. An incorrect or a
`corrupted component is similarly replaced at 420. At 424,
`the launcher program executes any procedure Such as virus
`Scan decryption or expansion of encrypted or compressed
`component files Specified in the catalog file after retrieving
`each component.
`Once the components have downloaded, any existing
`components on the client that are not no longer needed as a
`result of the version update are deleted at 430. At 432,
`information in the catalog file, which at least includes the list
`of the components of updated application program, is Stored
`in cache on the client for use in a Subsequent update. The
`launcher then executes at 434 the pre-launch procedures
`Specified in the catalog, Such as virus Scan, prior to executing
`the application program at 436. The process completes by
`running the post-launch procedures at 438.
`
`17
`
`

`

`7
`The catalog file can also be specified to include a proce
`dure to delete the co