(12) United States Patent
`Larkin
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 7,003,767 B2
`Feb. 21, 2006
`
`USOO7003767B2
`
`(*) Notice:
`
`(54) SYSTEM AND METHOD FOR REMOTELY
`UPDATING SOFTWARE APPLICATIONS
`N
`N
`(75) Inventor: Michael K. Larkin, San Jose, CA (US)
`(73) Assignee: International Business Machines
`Corp., Armonk, NY (US)
`Subject to any disclaimer, the term of this
`p liS". sisted under 35
`a --
`y
`yS.
`(21) Appl. No.: 09/969,286
`(22) Filed:
`Oct. 2, 2001
`65
`Prior Publication D
`rior Publication Data
`US 2003/0066065 A1
`Apr. 3, 2003
`(51) Int. Cl
`Goor 5f44
`(52) U.S. Cl
`
`(2006.01)
`717,172. 717/169; 717/175,
`
`Oa -
`
`1 - O
`
`- - - - - - - - - - - - - - - - - - - - - -
`
`s
`
`s 71717s
`
`(58) Field Elisation Searth - - - - - - - - - R168-178
`ee application file for complete Search history.
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`5,920,725 A 7/1999 Ma et al. .................... sos,
`5,923,885 A * 7/1999 Johnson et al. ............. 717/176
`6,003,065. A 12/1999 Yan et al. ................... 709/201
`
`6,035,423 A * 3/2000 Hodges et al. ................ 714/38
`OTHER PUBLICATIONS
`Jing et al., “Client-Server Computing in Mobile Environ
`ments”, ACM, pp. 117-157, Jun. 1999.*
`Hauswirth et al., “A Component and Communication Model
`for Push Systems”, ACM, pp. 20-38, Oct. 1999.*
`* cited by examiner
`Primary Examiner Ted T. Vo
`(74) Attorney, Agent, or Firm-Kunzler & Associates
`(57)
`ABSTRACT
`
`request from a registered client to have the new Software
`
`A System and method are disclosed for remotely updating a
`f
`licati
`both thin cli
`d
`hin cli
`Software application on both thin client and non-thin client
`WorkStations while the Software application is open on the
`client WorkStation. The System includes a Server-side mod
`ule and a client-side module. The method involves the server
`receiving the new Software application and then either
`automatically pushing it onto each client or receiving a
`program installed. The State of the user's application may
`optionally be Saved during the install and restored after the
`automatic upgrading and installing of the Segment of the
`Software application. After the new Software application has
`been Successfully installed, the cache from the previous
`application is invalidated. Control is then transferred back to
`the client.
`
`29 Claims, 6 Drawing Sheets
`
`
`
`
`
`
`
`
`
`40
`
`46
`
`42
`
`Application
`
`
`
`New
`Application
`
`
`
`48
`
`12
`
`48
`
`12
`
`Curgislate
`Workstation
`Client Side
`Module
`
`Current State
`Workstation
`Cient Side
`Module
`
`52
`
`
`
`
`
`Application
`Update
`
`Server-Side
`Module
`
`12
`
`Current State
`Workstation
`Client Side
`Module
`
`Instacart, Ex. 1040
`
`1
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 1 of 6
`
`US 7,003,767 B2
`
`18
`1N 12
`
`10
`A1
`
`Storage O
`
`16
`
`
`
`Net
`Card
`
`input
`Devices
`
`CPU
`
`Output
`Devices
`
`
`
`
`
`14
`
`42
`
`44
`
`12
`
`38
`
`40
`
`Fig. 1
`
`2
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 2 of 6
`
`US 7,003,767 B2
`
`Application Host
`
`
`
`45
`
`
`
`40
`
`42
`
`Server
`
`'N
`
`12
`
`12
`
`12
`
`Workstation
`
`Workstation
`
`Fig. 2
`
`3
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 3 of 6
`
`US 7,003,767 B2
`
`
`
`Application
`
`New
`Application
`
`Application
`Update
`
`Server-Side
`Module
`
`Client Side
`Module
`
`Client Side
`Module
`
`Client Side
`Module
`
`Fig. 3
`
`4
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 4 of 6
`
`US 7,003,767 B2
`
`
`
`Server-Side Update Module
`50
`
`Server Register
`Module
`54
`
`Generate List of
`Objects Module
`60
`
`Server Current
`State Transfer
`Module
`66
`
`Client Location
`Module
`56
`
`New Object
`Location Module
`58
`
`Current State
`Receiver Module
`62
`
`Install New Object
`Module
`64
`
`Server Side
`interface
`68
`
`Transfer Control
`Module
`70
`
`Client-Side Update Module
`52
`
`Server
`Communication
`Module
`72
`
`Client-Side interface
`Module
`74
`
`Client Register Module
`76
`
`Location information
`Module
`78
`
`Current State Transfer
`Module
`80
`
`Receive New Object
`Module
`82
`
`Cache invalidation
`Module
`84
`
`Client Current State
`Receiver Module
`86
`
`Data Version Change
`Module
`88
`
`Fig. 4
`
`5
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 5 of 6
`
`US 7,003,767 B2
`
`/
`
`Cal Server from Client
`
`Register For Push
`
`Register Client Location
`
`Make Server Aware of New
`Application
`
`Generate List of Objects to
`Update
`
`Store Current State
`
`install New Application onto
`Client
`
`invalidate Cache
`
`Return Current State to Client
`
`ReConcile Data Versions
`
`Reurn Control to Client
`
`124
`
`126
`
`128
`
`130
`
`132
`
`134
`
`136
`
`138
`
`140
`
`142
`
`144
`
`146
`
`End
`
`6
`
`

`

`U.S. Patent
`
`Feb. 21, 2006
`
`Sheet 6 of 6
`
`US 7,003,767 B2
`
`/
`
`Client Calls Server
`
`Client Requests Update
`
`Generate List of Objects to
`Update
`
`Store Current State
`
`instal New Application onto
`Client
`
`invalidate Cache
`
`Return Current State to Cient
`
`ReConcile Data Versions
`
`Return Control to Client
`
`154
`
`156
`
`160
`
`162
`
`164
`
`166
`
`168
`
`170
`
`172
`
`174
`
`End
`
`7
`
`

`

`1
`SYSTEMAND METHOD FOR REMOTELY
`UPDATING SOFTWARE APPLICATIONS
`
`BACKGROUND OF THE INVENTION
`
`1. The Field of the Invention
`The present invention relates to Systems and methods for
`upgrading Software in distributed computer Systems. More
`Specifically, the present invention relates to Systems and
`methods for automatically updating Software acroSS a net
`work.
`2. The Relevant Art
`Large entities Such as businesses and educational institu
`tions often connect user computer Stations with a network
`which is in turn connected to a local Server. This allows users
`of the computer Stations to share files, programs, Software,
`and the like. Under this arrangement, a network adminis
`trator may centrally install and manage Software applica
`tions on the Server to allow each Station that is connected to
`the Server to access the Software application from the Server.
`This arrangement relieves the network administrator of
`having to download the new Software application onto each
`individual computer. The Stations running the Software
`application remotely from the Server are referred to as thin
`clients. Thin clients generally Store user data centrally on the
`Server and Store little or no application code and data locally.
`Non-thin clients, on the other hand, generally run the entire
`application and Store all data locally.
`When managing distributed client environments, System
`administrators are often required to centrally manage Soft
`ware deployment. With thin clients, updated versions of
`software are easily updated and made available to the client
`upon the next reuse. The application is generally updated
`directly on the Server, typically by installing the new version
`upgrade from a CD-ROM or by download from a specific
`location on the Internet or other network. Portions of the
`application that reside on the client can be downloaded from
`the Server or otherwise installed while the application is not
`in use. With non-thin clients, the administrator is generally
`required to install the updated version of an application
`manually on each client Station. This typically disrupts the
`work of many users for Sustained periods of time. Even if
`conducted at night, Software installations can be trouble
`Some, as many users keep applications open when not at
`their desks, which can prevent upgrades from being Suc
`cessfully conducted.
`Keeping the versions of the application Straight in net
`Works that have both thin clients and non-thin clients can
`also be quite troublesome. AS is often the case, when a new
`version of Software is developed, the System administrator
`must distribute the new version or otherwise verify that each
`client on the same network has the new version.
`Computer Systems operating in a distributed environment
`may acceSS and install new versions of Software using one
`of two methods. In a “pull' method, the client requests the
`new software from the server. In a “push” method, the server
`decides when to install the software and may install the
`Software automatically onto the client.
`The downtime that is involved with installing new ver
`Sions of Software onto remote clients can create problems.
`With either thin clients or non-thin clients, once installation
`of the new Software is completed, the application may need
`to be restarted on the client and possibly even the entire
`workstation may have to be restarted before the new version
`of the Software application is accessible. When a new
`version of a Software application is pushed upon the client
`while the Software application is executing, the user is likely
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 7,003,767 B2
`
`2
`to temporarily or permanently lose data. Even when users
`are alerted and Save their data, work is interrupted, and after
`the installation of the Software application update, the user
`is generally required to restart the application, and in Some
`cases the entire machine. The user is thus left waiting while
`the machine reboots, the application restarts, the installation
`process is completed, and the document is found again and
`reopened.
`Providing the client with the new version of a software
`application is also burdensome on System administrators.
`For example, when a new or updated version of an appli
`cation is available for download from the Internet, the
`System administrator is typically required to Verify that each
`thin client is aware of the updated version of the application
`and to Verify that the updated version is properly installed on
`each thin client. For non-thin clients, the System adminis
`trator must assure that each non-thin client has the updated
`version of the application by installing the new version one
`machine at a time. Thus, the System administrator often finds
`him or herself charged with managing both thin and non-thin
`clients. Since most users of non-thin clients either admin
`ister their own machines or retain the Services of a Separate
`group to manage their environments, a method is needed to
`deploy and Synchronize Software packages for these users.
`In accordance with the above discussion, it should be
`readily appreciated that a need exists for a System and
`method to automatically update and Synchronize versions of
`Software applications in both non-thin and thin client envi
`ronments. What is similarly needed is a manner of allowing
`users of both thin and non-thin clients to avoid having to
`restart application and/or the entire WorkStation once the
`new version of the application is downloaded and installed.
`
`OBJECTS AND BRIEF SUMMARY OF THE
`INVENTION
`
`The present invention has been developed in response to
`the present State of the art, and in particular, in response to
`the problems and needs in the art that have not yet been fully
`Solved by currently available programs. Accordingly, the
`present invention Solves the foregoing problems by provid
`ing a System and a method for remotely updating and
`Synchronizing a Software application within both thin and
`non-thin client WorkStations and for restoring the Software
`application to a uSeable State without restarting the Software
`application.
`In one aspect of the invention, the Server is configured to
`automatically upgrade or update and push each new version
`of an application onto the thin client. The thin client may be
`configured to register with the Server for push-type updates,
`making the Server aware of the client's location.
`The Server may be configured to monitor a remote System
`that may contain a catalog of available updates to determine
`whether new versions of an application are available for
`download to the client. When new versions of the applica
`tion are available, the Server may automatically initiate the
`installation of the Software application updates. Alterna
`tively, the clients, either automatically or in response to a
`user, may request a pull-type installation of new Software
`application or new Software application updates.
`In both push and pull cases, the Server contacts the client
`and prepares to install the application update. The user may
`have the application open-that is, executing or otherwise in
`an operational State-when the Server attempts to push the
`new application onto the client. An option may be provided
`to Save the current State of the client's target Software
`application. If the option is Selected, the System determines
`
`8
`
`

`

`3
`that the current State is persistent and Selects where the State
`will be Stored, i.e., on the Server, locally, on a diskette, etc.
`In one embodiment, the client State is transmitted from the
`client to the server to be stored on the server temporarily
`during the upgrading of the application onto the client. The
`Server, accordingly, receives the current State from the client
`and Stores it in a designated location.
`Upon Storing the current State on the Server, the updated
`version of the application is pushed onto the client. In
`addition, in one embodiment, once the client has received
`the updated version, it invalidates the application cache from
`the previous version of the application.
`The current State Stored on the Server is then pushed back
`onto the client and control is returned to the client. The client
`may then reconcile any data version changes from the
`previous version of the application and the newly down
`loaded version.
`In one embodiment the user is presented with the option
`of resuming with the State that was open at the time of the
`push, restarting the application, and/or restarting the entire
`client WorkStation. New application installation may also be
`conducted using the System and method of the present
`invention.
`The server may thus update both thin and non-thin clients
`automatically and remotely when the Server becomes aware
`of new versions of the Software application. The update
`proceSS may also be transparent to the client, making the
`updated version available with minimal or no disruption to
`the user of the client.
`These and other objects, features, and advantages of the
`present invention will become more fully apparent from the
`following description and appended claims, or may be
`learned by the practice of the invention as Set forth herein
`after.
`
`5
`
`15
`
`25
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`35
`
`40
`
`45
`
`In order that the manner in which the advantages and
`objects of the invention are obtained will be readily under
`stood, a more particular description of the invention briefly
`described above will be rendered by reference to specific
`embodiments thereof which are illustrated in the appended
`drawings. Understanding that these drawings depict only
`typical embodiments of the invention and are not therefore
`to be considered to be limiting of its Scope, the invention will
`be described and explained with additional Specificity and
`detail through the use of the accompanying drawings in
`which:
`FIG. 1 is a Schematic block diagram illustrating a com
`puter System Suitable for implementing the Software update
`50
`System and method of the present invention.
`FIG. 2 is a Schematic block diagram illustrating one
`embodiment of a System for upgrading a new application to
`a newer version over a network.
`FIG. 3 is a Schematic block diagram illustrating a new
`application being transferred to a server, a current State of
`the workstation, and embodiments of both a client-side
`module and Server-side module.
`FIG. 4 is a Schematic block diagram illustrating one
`embodiment of the client-side module and the server-side
`module of FIG. 3.
`FIG. 5 is a flow chart block diagram illustrating one
`embodiment of a push method of the present invention for
`remotely updating Software applications.
`FIG. 6 is a flow chart block diagram illustrating one
`embodiment of a pull method of the present invention for
`remotely updating Software applications.
`
`55
`
`60
`
`65
`
`US 7,003,767 B2
`
`4
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`
`The presently preferred embodiments of the present
`invention will be best understood by reference to the draw
`ings, wherein like parts are designated by like numerals
`throughout. It will be readily understood that the compo
`nents of the present invention, as generally described and
`illustrated in the figures herein, may be arranged and
`designed in a wide variety of different configurations. Thus,
`the following more detailed description of the embodiments
`of the System, and method of the present invention, as
`represented in the figures, is not intended to limit the Scope
`of the invention, as claimed, but is merely representative of
`presently preferred embodiments of the invention.
`FIG. 1 is a Schematic block diagram illustrating one
`example of a computer System 10 Suitable for employing the
`system and method of the present invention. In FIG. 1, one
`or more computer Stations 12 may be hosted on a network
`14. Typical networkS 14 generally comprise wide area
`networks (WANs), local networks (LANs) or interconnected
`Systems of networks, one particular example of which is the
`Internet and the World Wide Web supported on the Internet.
`A typical computer Station 12 may include a processor or
`CPU 16. The CPU 16 may be operably connected to one or
`more memory devices 18. The memory devices 18 are
`depicted as including a non-volatile Storage device 20 Such
`as a hard disk drive or CD-ROM drive, a read-only memory
`(ROM) 22, and a random access volatile memory (RAM)
`24. Preferably, the computer station 12 operates under the
`control of an operating system (OS) 25, such as MVS(R),
`OS/390R, AIX(R), OS/2(R), WINDOWS NT(R), WIN
`DOWSCR, UNIX(R), and the like.
`The computer Station 12 of System 10 in general may also
`include one or more input devices 26, Such as a mouse or
`keyboard, for receiving inputs from a user or from another
`device. Similarly, one or more output devices 28, Such as a
`monitor or printer, may be provided within or be accessible
`from the computer System 10. A network port Such as a
`network interface card 30 may be provided for connecting to
`outside devices through the network 14. In the case where
`the network 14 is remote from the computer Station, the
`network interface card 30 may comprise a modem, and may
`connect to the network 14 through a local acceSS line Such
`as a telephone line.
`Within any given station 12, a system bus 32 may
`operably interconnect the CPU 16, the memory devices 18,
`the input devices 26, the output devices 28, the network card
`30, and one or more additional ports 34. The system bus 32
`and a network backbone 36 may be regarded as data carriers.
`As such, the system bus 32 and the network backbone 36
`may be embodied in numerous configurations. For instance,
`wire, fiber optic line, wireleSS electromagnetic communica
`tions by visible light, infrared, and ratio frequencies may be
`implemented as appropriate.
`In general, the network 14 may comprise a single local
`area network (LAN), a wide area network (WAN), several
`adjoining networks, an intranet, or as in the manner
`depicted, a System of interconnected networkS Such as the
`Internet 40. The individual stations 12 communicate with
`each other over the backbone 36 and/or over the Internet 40
`with varying degrees and types of communication capabili
`ties and logic capability. The individual Stations 12 may
`include a mainframe computer on which the modules of the
`present invention may be hosted.
`Different communication protocols, e.g., ISO/OSI, IPX,
`TCP/IP, may be used on the network. In the case of the
`
`9
`
`

`

`US 7,003,767 B2
`
`15
`
`25
`
`35
`
`40
`
`S
`Internet, a single, layered communications protocol (TCP/
`IP) generally enables communication between the differing
`networkS 14 and Stations 12. Thus, a communication link
`may exist, in general, between any of the Stations 12.
`In addition to the stations 12, other devices may be
`connected on the network 14. These devices may include
`application Servers 42, and other resources or peripherals 44,
`Such as printers and Scanners. Other networks may be in
`communication with the network 14 through a router 38
`and/or over the Internet.
`Referring now to FIG. 2, a Schematic block diagram of
`one example of an environment for implementing the
`present invention is shown including a plurality of WorkSta
`tions 12. In one embodiment, the workstations 12 are
`connected via a network 14 which operates in conjunction
`with a server 42. The server 42 is connected to the Internet
`40, where a site 45 hosting an application 46 is located. In
`one embodiment, the application is a Java" based applica
`tion, but the present invention is intended for use with any
`Suitable type of application.
`Referring now to FIG. 3, under one embodiment of the
`present invention, the Server 42 monitors the application
`host 45 (of FIG. 2) for notification of any updates to the
`application 46. When Such notice is received, the updated
`version of the application 46 is downloaded acroSS the
`Internet 40 or other Suitable communication medium to the
`Server 42. The reception of the notice and the downloading
`of the updates are preferably conducted automatically, but
`may also be conducted manually. The server 42 is preferably
`configured to Store the application update and to automati
`cally push the updated version of the application 46 onto
`registered workstations 12 using a server-side update mod
`ule 50. The updated version of the application 46 may also
`be downloaded and/or transmitted to the Stations 12 upon
`request of the stations 12. The current state 48 of the
`workstations 12 may be temporarily stored on the server 42
`during the upgrading of the application 46, and then later
`restored, as will be discussed.
`FIG. 4 illustrates one embodiment of the server-side
`update module 50 and the client-side update module 52 of
`FIG. 3. Within the server-side update module 50 are shown
`a server register module 54, a client location module 56,
`anew object location module 58, a generate list of objects
`module 60, a current state receiver module 62, an install new
`object module 64, a server current state transfer module 66,
`a server-side interface 68, and a transfer control module 70.
`In the depicted embodiment, the server-side interface 68 is
`configured to connect with the client-Side update module 52
`through a network connection 14.
`The client-side update module 52 is shown provided with
`a Server communication module 72, a client-side interface
`74, a client register module 76, a location information
`module 78, a client current state transfer module 80, a
`receive new object module 82, a invalidate cache module 84,
`a client current State receiver module 86, and a data version
`changes module 88. In the depicted embodiment, the client
`side interface 74 is configured to connect with the server
`side update module 50 through a network connection 14.
`The server communication module 72 is preferably con
`figured to communicate with the server 42 (of FIG. 2) to
`receive any updates that may be available to the System. In
`the case of the client "pulling the update, the client register
`module 76 is configured to register the client for available
`updates. The server register module 54 is preferably con
`figured to record client registration.
`The location information module 78 is preferably config
`ured to inform the server 42 of clients location. The client
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`location module 56 is preferably configured to generate a list
`of all registered clients in which the updated version of the
`application 46 of FIG. 3 is to be distributed to and to record
`the location of each of the registered clients. The new object
`location module 58 is preferably configured to identify any
`new updates that may be available to distribute to the client
`workstation 12 of FIG. 3 and also to the server 42 of FIG.
`3. The generate list of objects module 60 is preferably
`configured to generate a list of objects that are available to
`download onto both thin and non-thin clients.
`The client-side module 52 preferably consists of an
`optional current state transfer module 80 that is configured
`to transfer the current state 48 of the client of FIG. 3 to the
`server 42 for storage. The current state receiver module 62
`is preferably configured to receive and Store the current State
`48 of the client for later restoration. The current state 48 is
`Stored until the updated version of the application 46 is
`upgraded on the WorkStations 12. The upgrading of the
`application 46 of FIG. 3 is preferably conducted with an
`install new object module 64 which is configured to install
`the new application 46 on the registered clients. The receive
`new object module 82 is preferably configured to receive
`information from the install new object module 64 for use in
`installing application updates 47 on the client WorkStations
`12.
`In one embodiment, upon receiving the application update
`47, the client-side update module 52 invalidates the cache
`from the previous version of the application that is replaced
`by the updated version of the application 46. This process
`may be conducted by a cache invalidation module 84. After
`invalidating the cache, the client-Side update module 52
`receives the current state 48 that was temporarily stored on
`the server 42, preferably with a current state transfer module
`66. The current state 48 is then received by the client current
`state receiver module 86 and made accessible to the user of
`the WorkStation 12 having the newly updated application 46
`implemented. Upon receiving the current State 48, the data
`version change module 88 within the client-side module 52
`may be configured to modify the current state 48 to match
`the updates and possible changes brought about from the
`updated version of the application 46 that was recently
`implemented on the workstation 12. The transfer control
`module 70 within the server-side module 50 is configured to
`then pass control back to client module to allow the user to
`continue use of the WorkStation 12.
`FIG. 5 is a Schematic flow chart diagram illustrating one
`embodiment of a push-type method 120 of upgrading and
`installing new versions of a Software application. The
`method 120 begins at a Start Step 122 and progresses to Step
`124. At step 124, the client, which may comprise the
`workstation 12 of FIG. 1, calls a server Such as the server 42
`of FIG.2. During this call, and as indicated at a step 126, the
`client registers to have the updated version of the Software
`application 46 be pushed onto the client, preferably into the
`RAM memory 24 of FIG.1. In a step 128, the location of the
`client is registered with the server 42.
`At a step 130, the server 42 of FIG. 2 determines the
`availability of an updated version of the Software application
`46. The updated version 46 may, for example, be located on
`the Internet 40 or stored on the ROM 22 of FIG. 1. The
`determination of step 130 may be accomplished by the
`Server 42 monitoring a Site Such as a catalog Server of a
`Software vendor for the appearance of newer versions of the
`Software application 46. In addition, a vendor of the soft
`ware application 46 may periodically notify its customers of
`new versions of its Software application 46. In doing So, it
`preferably communicates directly with the server 42.
`
`10
`
`

`

`7
`At a step 132, the Server 42 generates a list of the
`WorkStations 12 that are registered to be updated with the
`updated version of the software application 46. The updated
`version of the Software application is then automatically
`loaded and installed on these workstations 12. Below, the
`update proceSS will be described for a single workStation 12,
`but it should be appreciated that the server 42 is preferably
`configured to update all WorkStations 12 on which the
`Software application 46 to be updated is installed.
`At a step 134, the current client state 48 of the workstation
`12 is Stored temporarily during the upgrading of the Software
`application 46. The client state 48 may be stored on the
`Server 42, or may be Stored locally on non-volatile memory
`20 of the client 12. In one embodiment, the client state 48
`comprises preferences and active data of the client for the
`Software application that are stored in RAM memory 24.
`Data of the software application 46 in RAM memory 24, as
`well as in persistent memory at the time of the update may
`also be stored in a like manner. Because the client state 48
`is Saved, the updating process may be conducted while the
`client computer is in operation, and indeed, while the target
`Software application is open. The term “open' as used herein
`is intended to mean a State of current execution of the
`Software application, including being actively used by a user
`and/or merely operating passively in the background.
`In a Step 136, the Software application update 46 is pushed
`upon the registered WorkStation 12. Many applications,
`particularly Java applications, may have an application
`cache that must be invalidated in order to Successfully
`update the application. Accordingly, in one embodiment, at
`a step 138, the application cache from the previous version
`of the software application is invalidated and flushed. In
`Java applications, an application’s objects are tied to the
`class definition loaded by a class loader. The class loader
`houses the application class. In one embodiment, in order to
`clear or “invalidate' the application cache, a new class
`loader is created, forcing the old class loader's cache to be
`“forgotten.” That is, the old class loader is disassociated with
`the Software application and the previously occupied
`memory may then be automatically reclaimed by a utility
`Such as Java's System garbage collector.
`The new class loader may be created in one embodiment
`by a) creating a new instance of an upgradable Software
`component (object); b) working with this instance for a
`period of time until a new version becomes available; c)
`defining and instantiating a new class loader (or instantiating
`a class loader derived from the System class loader); d)
`instantiating anew version of the Software component using
`the new class-loader; e) casting the new version of the
`component to an identical interface accessible by both class
`loaders; and f) assigning the casted component to the handle
`of the original object.
`At a step 140, the current state 48 is passed from the
`Server back to the registered WorkStation 12. In a step 142,
`any data version changes from the newly downloaded Soft
`ware application 46 are reconciled. As an example of
`reconciling data, consider an instance in which an updated
`version of the application 46 that may be a word processor
`makes a bold lettering option unavailable. In this example,
`active data of the current State that are configured with bold
`lettering are modified. That is, the bold lettering is auto
`matically changed to a default command Such as underlining
`or plain text when the current State is passed back to the
`client. In a step 144, control is passed back to the WorkSta
`tion 12, and the newly downloaded software application 46
`can be accessed without having to reboot the WorkStation 12
`or the application 46.
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 7,003,767 B2
`
`8
`FIG. 6 is a Schematic flow chart diagram illustrating one
`embodiment of a pull-type method 150 of automatically
`upgrading and installing new versions of a Software appli
`cation. The method 150 begins at a start step 152 and
`progresses to Step 154. At Step 154, the client, Such as the
`workstation 12 of FIG. 1 calls a server, which may comprise
`the server 42 of FIG. 2. During the call, the client then
`requests an update of the Software application 46, as indi
`cated at a step 156.
`At a step 160, a list of objects or components of the
`Software application 46 that are to be updated is generated.
`The Server preferably compiles the list in response to the
`version of the update requested by the client. At a Step 162,
`the current state 48 of a client 12 is stored temporarily during
`the upgrading or updating of the Software application 46, as
`discussed for step 134. In a step 164, the software applica
`tion update 46 is automatically transmitted to and installed
`upon the client 12. After the Software application update 46
`has been automatically loaded and installed on the client 12,
`the application cache from the previous version of the
`Software application is preferably invalidated Substantially
`in the manner described above with respect to step 138 of
`FIG. 5.
`At a step 168, the current state 48 is returned to the client.
`The current state 48 is thus either returned from the server
`42, or is retrieved from no