SYSTEM AND METHOD FOR MANAGING SYSTEM

I

SYSTEM AND METHOD FOR MANAGING SYSTEM CONFIGURATION ACROSS A NETWORK

Related Application

This applicationisacontinuation-in-part claiming thebenefitof U.S.

Patent Application Serial

Number

08/814,771, filed

on March

7,

1997

andtobe issuedas U.S. PatentNo. 6,074,434,

which

^{is itself}acontinuation-in-part

of

U.S. Patent

Application Serial

Number

08/659,841, filed on June 7, 1996, and issued asU.S. Patent

No.

5,752,042.

FieldoftheInvention

The

present inventionrelates generallyto

computer

systems and,

more

specifically, to systemconfiguration

management

foraplurality

of

computers connected via anetwork.

Background

oftheInvention

The

use

of

theclient-server distributed

computing model

in localarea networks and enterprise-wide systems has

become

ubiquitousinbusiness, academic, and personal

computing

environments.

With

increasingfrequency, fixed function display terminals havebeen replaced

by

desktop andlaptop computerscapable ofexecuting software programs independently and asynchronously

from

thecentralized

mainframe

or enterprise serverprocessor.

As

the

number

of desktop and laptop computers inalocal(or enterprise- wide)

network

increases, the complexityofmaintaining the software configuration in

each

computer

increases. Softwaredevelopers frequently distributeupdatedversions or releases oftheirsoftware products, referredto as"updates" in this document,tocorrect software errors or to

enhance

functionality, compatibility, andportability.

Of

course, software developers also distribute

new

softwareproducts designed to improve

performance, typicallywith anincrease inthecomplexity ofinstalling and configuring such

new

software products.

END9-1997-0019-US2

Thereare various

known

techniquesfora servertoprovide aclientwitha code updateora userwith

new

data. In

one

technique, clients registerwiththe server for updatesto aparticular

program

and users registerwith the serverforupdatesor

new

data.

Whenever

the serverobtains a

new

update for that

program

or

new

dataofthe specified type, the serverautomatically sendsthe code update or

new

dataofthe specifiedtypeto every client/user

on

the list. Unfortunately,

some

users

may

notwishtoobtain a

particularupdateor particular

new

dataofthe specified typebecauseofcost,

download

time, or otherreason. Alternately, ausercanperiodically requestall

code

updatesor

new

dataofspecifiedtypes

and

the server will respondaccordingly. Unfortunatelyagain, the user

may

notneed every

code

updateor dataofthe specified typebut, nevertheless, endures the costand

download

time. Ingeneral, because ofthelarge

number

and complexity ofsoftware applications

on

auser's system, andthelarge

number

and complexity ofthecorrespondingupdatesfor that system, itisvery difficultforusersto

know what

updates areappropriateforthem. Likewise, there isso

much new

data generated everydaythat itis difficultto

know what new

datais appropriatefor particular users.'

Thus,

network

operatorshave beenfacedwiththechallenge ofbalancing theirdesire toprovidetheir clients with the

most

currentsoftwareupdatesandproducts against theirrequirement

of

minimizing disruptionstothe clients. Softwareconfiguration

management

tools have

been

developed to assistnetworkoperators inthis endeavor.

U.S. Patent

No.

5,752,042 issuedtoCole etal. disclosesa server

computer

and a

method

performed

by

a server

computer

for selectingcodeupdatesto

download

to aclientcomputer.

The

server computeridentifiescode updates

which

areconsistentwith basic systemcharacteristics

of

the clientcomputer. Then, the server

computer

sendsto the clienta "recognizer"

program which

executes inthe clientcomputerto determineif the clientcomputerhas a version of codethatis not current.

The

server

may

then

generate a list,ofcode updates based

upon

theresultofexecutingthe recognizerprogram.

A

userattheclient

computer

endcan selectfromthelist.

Based on

the selections

made

bytheuser, the server

computer

sends addressesofthe selected code updatesto the client computer.

The

client

computer may

then

download

the selectedupdates

from

aserver computer.

END9-1

997-00

19-US2 -2-

U.S. Patent

No.

5,581,764issuedto Fitzgerald etal. disclosesan automated

method

of

managing

changes in a distributed

computing

environment.

The

resourceneeds

of

individual distributedcomputers are determined based

upon

aShould

Have (SH)

listschema.

The SH

list

schema

isused toproduce

SH

^listsforindividual distributed computers. Individual Already

Have (AH)

lists

may

bestored orproduced at configuration timefor individual distributedcomputers.

A

differencing processisusedto locate differences

between SH

^lists and

AH

lists.

The

differences

between SH

listsand

AH

^lists forthe individual distributedcomputers areusedto determine

what

items

must

be updated ormodified inordertoupdateindividualdesktops.

Inpriorartconfiguration

management

systems, information describing the software configurationattributes

of

eachclientprocessor

was

provided toacentral server processor.

The

centralserverprocessor

would

determine

which

updates and

new

productstoprovide toeachclient, basedonthe software configuration of eachclient.

There remains a need,therefore, for a

more

flexibleand robustsoftware and hardware configuration

management

system.

Summary

oftheInvention

To meet

this

and

otherneeds, and in

view

ofits purposes, thepresent invention provides asystem

and method

fordetermining whetherto provide a software

program

updatetoaclientprocessor.

A

configuration receiving

mechanism

receivesand storesasetof hardware, software, or bothhardware and software(or"system")

configuration attributes

from

theclientprocessor.

The

systemconfigurationattributes indicatewhethera

copy

ofaclient software

program may

be storedintheclient processor.

A

configuration transmitting

mechanism

transmits the set ofsystem

configuration attributestoa serverprocessor.

An

update-receiving

mechanism

receives an updaterecognizer

program and

a software

program

update

from

theserver processor.

The

updaterecognizer program andthe software

program

update are associatedwiththeclient software program.

An

update recognizertransmitting

mechanism

transmits theupdaterecognizer program to theclient processor.

The

client processor executes theupdate recognizerprogram to issue a notification indicating

END9-1997-0019-US2 -3-

whether

thesoftware

program

updateis applicableto the

copy of

the clientsoftware

program which may be

storedinthe clientprocessor.

Itisto be understoodthatboththe foregoing general descriptionand the followingdetailed description areexemplary, butare notrestrictive, oftheinvention.

BriefDescription ofthe

Drawing

The

inventionis bestunderstood

from

thefollowingdetaileddescription

when

read in connection withthe

accompanying

drawing. Itis

emphasized

that,

accordingto

common

^practice, the various features

of

the drawingare notto scale.

On

the contrary, the dimensions

of

the various features arearbitrarily

expanded

orreduced for clarity. Included inthe

drawing

are thefolloAyingfigures:

Fig. 1 illustrates a

computer

networkincludingclients, aselection server,

and

a content server;

Fig.

2

is a block

diagram

illustrating

more

^detail

of

a selection server, content server, and aclient inthe

network

ofFig. 1;

Figs.

3a

and

3b form

aflowchartillustratingoperation

of

the clientand serverofFig. _2;

Fig.

4

isa flow chartillustrating a

program

sent

from

the servertothe clientofFig. 2todetermineneeds

of

the clientfor a particular

code

update;

Fig. 5 is anotherflowchartillustrating a

program

sent

from

the serverto the clientofFig. 2 to determine needs oftheclientfor anotherparticular codeupdate;

Fig. 6 illustratesanother

embodiment

ofa

computer

network;

Fig. 7 isa block diagram illustrating

more

^detail

of

a selection server, contentserver, and aclient inthe network ofFig. 6;

END9-1

997-00

19-US2 -4-

Figs. 8a

and

8b

form

aflowchartillustratingoperationoftheclientand serverofFig. 7;

Fig. 9 isaflowchartillustrating a

program

sent

from

the server to the client ofFig. 7to determine needs

of

theclientforaparticularsetof

new

data;

5 Fig. 10 isanother flowchartillustrating a

program

sent

from

the serverto theclientofFig. 7to determine needs oftheclientforanotherparticularset

of new

data;

Fig. 1 1 is ablock diagram of an exemplary systemin accordancewiththe presentinvention;

and

Fig. 12is ablock diagram ofthe exemplaryadministration server

shown

10 inFIG. 11.

Detailed DescriptionoftheInvention

Referring

now

^tothe figuresin detail, in

which

likereference

numbers

indicatelike elementsthroughout, Fig. 1 illustrates a computer

network

generally designated 10 includingclients, aselectionserver, and acontent server.

Network

10

15 comprises aselectionserver 12witha data base 13, a content server 17, clients 14-16,

and an

Internet

20

tointerconnectthe servers andclients.

By way

of example, the

selectionserver 12comprises a

computer

workstationwithassociated

programming

anda

modem,

thecontent server 17 comprisesa computerworkstationwithassociated

programming and

a

modem,

and each oftheclients 14-16 comprises apersonal

computer

20 withassociated

programming and

a

modem. The

Internet20 comprisesa

communication medium

suchastelephonewires

between

theclients 14-16, the selection server 12, and thecontent server 17 and

programming

to

manage

the communications.

Communications between

the clients 14-16 andtheselectionserver 12 use hypertexttransportprotocol

(HTTP)

and communications

between

the clients 14-16 and

25 the contentserver 17usefiletransport protocol(FTP). Althoughnot shown,there are

many

other servers fortheInternet. Selection server 12 is dedicated to automating selectionofcodeupdates, the contentserver 17 includesthe actual code updates (stored

END9-1

997-00

19-US2

on

disk_21), ancl database 13 includes

meta

dataforthe code updates and

FTP

addressing informationto locatethe

code

updates in content server 17.

The meta

dataprovides descriptive information aboutthe respectivecode updates such asbasic inputoutput system

(BIOS)

level, pre-load level, motherboard ID, andthelike.

The FTP

addressing informationindicatesthe address oridentification

of

the content server

which

storesthe respectivecode update(content server 17 inthe illustrated example), a user

ID and password

tolog-ontothecontent server, a

name

ofthe

code

update, alistoffiles

which

comprisethe code updateandthe size, checksum,

and

directory

of

eachfile.

According

to

one

process for storingthe updatesinthecontent server 17 andthe

meta

data inthe selection server 12, apersonwritesthe

code

updateand

meta

data andloads

them

inthe content server 17, eithervia the Internetor

by manual

loading.

The code

updatesremain storedinthe contentserver, but the

meta

dataiswrittentothe selection server, eithervia theInternetor

by manual

loading.

As

illustrated inFig. _2, theselection server 12is an

HTTP

^serverwith an associated

"CGI" program manager

31 and includes

an

updateselection

program

30.

The

client 14 includes an update

manager program 32

(including a graphical userinterfaceor

"GUT'), a scout routine 33, a service applicationroutine 34, and a

download

routine39.

The

functionsofthe serverandclient

programming and

atypical client-server sessionfor selectingand

downloading

updatesareillustrated inFigs.

3a

and3b.

A

^{userat client}

computer

14 selects an icon to invoke update

manager

32. In response, theupdate

manager

contacts the general

manager

31 in server 12 tobegin a session andsupplies the current level of update

manager

32, scout33, serviceapplication 34, and

download

routine 39withinclient 14 (step 104). Inresponse, the general

manager

31 determinesif the client'supdate

manager

32, scout33, serviceapplication34, and

download

routine

39

arethe latest version(step 106). This determinationis performed

by comparing

the client level information supplied

by

the client 14to the datain selection server 12 forthe latest version oftheclient's update

manager

32, scout 33, service application _34, and

download

routine39 storedinthe content server 17.

Ifthe client'supdate

manager

32, scout 33, service application 34, and

download

routine

39

arenot the latestversion, the server 12 sends the

FTP

addressing informationtotheclient 14to allowthe client to retrievethe latest versions

from

a

END9-1

997-00

19-US2 -6-

content server 17.

Along

withthe

FTP

addressingfortheclientupdate manager, scout, service application, and

download

routine, the server 12 sends

FTP

addressing

informationtothe client 14 fora basic systeminformation recognizer

program

41 stored in content server 17 (step 107). Next,the client 14

downloads

and installsthe latest versionofthe clientupdate

manager

32, scout33, service application34, and

download

routine

39 from

thecontent server 17ifthe

FTP

addressing

was

provided (step 108).

The

furnishing ofthe

FTP

addressing informationforthe basicsystem information recognizer

program

begins the selection process.

The

client 14 next

downloads

the basic

system

information recognizer

program

41

from

the content server 17and executesit(step 109).

The

basic systeminformation recognizer

program

41 then obtains basicsysteminformation, using scout APIs, aboutclient 14(step 109).

The

basic systeminformation comprises system model, pre-load softwarelevel,

BIOS

level,

and

informationthatis notlikely to change often suchastype ofoperating system.

For

example, the basic

system

information

of

client 14is

BIOS

level 123,

BIOS

date 1/1/96, and

mother

board

ID XYZ. The

update

manager 32

then sends the basicsystem

information, obtained

by

the basic systeminformation recognizer

program

41, tothe selectionserver 12 (step 110).

This initiatesthe selectionupdate

program

30 (step 112).

The

selection update

program

30 within server 12 then determines

which

code updatesareconsistent withthe basic systeminformation

of

the clientand

which code

updates are inconsistent, thereby eliminating the vast majority

of

the code updates storedincontent server 17(and other content servers, ifany)

from

furtherconsideration(step 114). In theillustrated

embodiment,

this determinationis

made

by correlatingthe

meta

dataindatabase 13 to thebasic system informationobtained

from

client 14.

Matches between

the

meta

data andthe basicsystem information indicatethatthe corresponding

code

updatesare potentiallyappropriatefor client 14. (Inpractice, the

meta

datacan

be

arrangedin a relationaldatabase tofacilitatethecorrelation.)

The two columns

ofthe followingtable

list

code

updates available incontent server 17and the

meta

dataforthesecodeupdates.

The two columns

ofthistable areused for the initial correlation

of

the basic system information obtained

from

client 14tothe metadata(column 2) storedⁱⁿ selection server

12.

END9-1997-0019-US2 -7-

Code Updates Device

Driver

ABCDE.DRV

Netcomber

2.0

Device

Driver

FGHU.DRV

Basic

System

Information/Meta

Data BIOS

Level 123

BIOS

date 1/1/96

Mother Board ID

XYZ

BIOS

Level 123

BIOS

date 1/1/96

Mother Board ID

XYZ

BIOS

Level

456 BIOS

date2/1/96

Mother Board ID

XYZ

Inthis example,the

BIOS

level 123,

BIOS

date 1/1/96,

and motherboard ID XYZ

basic system information obtained fromclient 14 isconsistentwith adevice driverfile

named ABCDE.DRV.

and

Netcomber

(trademark

of

InternationalBusiness

Machines

Corporation) version2.0.

Device

driverfile

named FGHIJ.DRV

requires

BIOS

level456, however, soisinconsistent withthebasicsystem information obtained

from

client 14 and iseliminated

from

further consideration.

For

each

code

update, suchasdevice driverfile

named ABCDE.DRV.

and

Netcomber program

version2.0,

which

isconsistentwiththebasic

system

informationof

client 14,the selectionupdate

program 30

sendstotheclient 14 the

FTP

addressing informationofacorrespondingrecognizerprogram, suchasrecognizer

programs 40 and

42, respectively(step 116).

The FTP

addressing informationisnot provided (and

no

recognizer

program

is fetched)to client 14 for thedevicedriver file

named FGHIJ.DRV,

however, because file

FGHIJ.DRV

isnot consistentwith the basic systeminformationof

client 14.

From

the

FTP

addressing information, the client 14

downloads

the actual recognizerprograms

from

thecontent server 17 (step 118).

Each

recognizer

program

is executableand small, typically2,000 ^- 3,000 bytes. Consequently, eachrecognizer

program

can be

downloaded from

content server

17totheclient 14ⁱⁿseconds (whereasthecorresponding code updateis

much

largerand

may

take hourstodownload).

END9-1997-0019-US2 -8-

Itshould benotedthat, based

on

the basicsysteminformationalone, the update selection

program 30

within server 12 ^is not sure

which of

thecode updatesthat areconsistentwiththe basic systeminformation are actually

needed by

the client.

For

example,the client 14

may

alreadyhave the latestversion.

5 Next, the client 14 executes each recognizer

program 40

and

42

with assistance

from

the scout33 (step 118).

The

scout 33 assiststherecognizer

programs by

providing subroutines thatcanbe ^called bytherecognizerprograms.

For

files required

by

the recognizerprograms, these callablesubroutines canlocatethe^files, determinethe version ofthefiles, determine^{the length}ofthe file, identifya directory

which

lists the 10 files, obtain time stamps for thefiles, obtain data

from

inside thefiles, and obtaindata

from

a

program

registry. Thisfurtherreducesthe requisitelength of eachrecognizer

program and

therefore shortens the

download

time.

When

executed, eachrecognizer 7£

program

further investigates the hardware, software, and^other

components

ofthe client

M

14 forinformationto determine whetherthecorresponding code updateis appropriatefor

yj ¹⁵ the client 14.

For

example, thisinvestigation revealswhethertheclient 14 alreadyhas

«p these codeupdates.

A

recognizer

program

could also determineifthe corresponding

L,

code

updateisconsistentwithaspects ofthe clientotherthanthebasic system

m

information, such asotherprogramswithinthe client.

ru

Recognizer

program 40

determines

from

the routine

of

scout33 in client 20 14ifthesize offile

ABCDE.DRV.

^storedbythe client 14isthe

same

as the size

of

file

ABCDE.DRV.

storedinthe database 13. Ifso, then client 14has the latestupdate. If not, thenclient 14likelyhasan old version

which

could

be

updated.

Fig. 4 illustratesrecognizer

program 40

in

more

detail. Instep 200, recognizer

program 40

calls scout 33 to scanthe hard diskofclient 14 forfile

25

ABCDE.DRV

todetermine if file

ABCDE.DRV

exists inclient 14. Ifnot, therecognizer

program

provides an indication thatfile

ABCDE.DRV

^isnot appropriatefor client 14 (step 202). Iffile

ABCDE.DRV

exists in client 14, however, then recognizer

program

40

calls scout33 to retrievethe^size offile

ABCDE.DRV

^{in client} 14 (step 204),

and

then

compares

the^file sizetothe size ofthe latestversion storedinthe contentserver 30 (decision 206). (The recognizer

program

includes anindication ofthe size ofthe

correspondingupdateinthe content ^{server.) Ifthe}

two

sizes are the same, then there ^is

END9-1

997-00

19-US2

(

fefz

no needto

download

file

ABCDE.DRV from

thecontent server 17; client 14 alreadyhas the latestversion. Ifthe

two

sizes arenot the same, then recognizer

program 40 makes

a recordthatthe^file

ABCDE.DRV

storedinthe content server 17^isappropriate for client

14 (step 208).

5 Recognizer

program 42 compares

a version

number of

the

Netcomber program

intheclientto the version

number

ofthe

Netcomber program

ofthe code update, andifthe version

number

ofthe

Netcomber program

installed inclient 14 isless, then theclientlikely has an oldversion. Fig. 5 illustratesrecognizer

program 42

in

more

detail. Instep 300, recognizer

program 42

calls scout33 toread a databasein client 14

10 todetermineifthe

Netcomber program

exists in client 14. Ifitdoes, recognizer

program

n

^{42 calls scout33 to}obtain the version

number

ofthe

Netcomber program from

^the data

LJ3 base (step 302). Ifthe version

number

storedinthedatabaseisequal to orgreaterthan theversion

number

inthe recognizerprogram, thenclient 14 doesnot

need

the version storedin the content server 17(decision

304

and step 306). Iftheversion

number

stored 15 inthedatabaseis lessthanthe version

number

^inthe recognizer program, however,then the recognizer

program

recordsthatclient 14 needsthe

copy

ofthe

Netcomber program

stored inthe content server 17 ^(decision

304

and step308).

The

results

of

the recognizerprograms includeyes/no answersto the question

of

whethereach respectivecode updateis appropriatefortheclient, i.e. not 20 currently residentinclient 14 andconsistentwiththe clientbasic system information as

determinedpreviously(in step 114).

The

recognizer

programs

can also assign a"critical"

levelto each code update based

on

theneed oftheclient for theupdate.

For

example, if another

program

inthe clientneedsthis codeupdateto function, thenthis

code

update

would be

assignedahigh level ofcriticality. Afterthe recognizer

programs

are executed 25 in client 14, client 14sends to selection server 12 alist ofthecode updates

which

are

appropriatefortheclient (step 120).

Based on

the information gatheredby the recognizer programs, theupdate selection

program

determines thelevel ofcriticality

of

the respective code updates and builds aselection

form

for display attheclient (step 122).

The

selection

form

comprises 30 a listofthe code updatesthat are consistentwiththebasic systeminformationand

END9-1997-0019-US2

^-

^10-

appropriateforthe client 14,

and

adisplay

of

the following three selectionchoices (step 124):

1.

minimum number

of codeupdates ^-

code

updates

which

are necessaryfortheclienttoensure compatibility

between

programs within the clientand fixa significant"bug" ina

program

within the client,

and

those otherupdatesthatthe authorofthe

code

update

deemed

criticalsuch asreplacementof unsupported programs;

2.

maximum number

of codeupdates- all

code

updates

which

are consistent withthe basicsysteminformationandappropriatefor the client; and

3. clientselection ofspecificcode updates ^-userselectsparticular

code

updates fromthelist ofall

code

updates

which

are consistent withthe basicsysteminformation and appropriateforthe client.

Next, the client

makes

^aselection, eitherselection ofthe first orsecond categories oranitemized list

of

codeupdates pursuanttothe third category(step 130), andsends the selection tothe server(step 131). In response, theserver 12 sendsto the client 14the

FTP

addressinginformation forthe selected

code

updates (step 132).

Using

this

FTP

addressing information, the

download

routine

39

oftheclient

downloads

the

code

updates

from

thecontent server 17(step 133). Ina preferred

embodiment,

the

FTP

addressing informationforall codeupdates representedinthe selection

form

arepassed withtheselection

form

tothe client 14 (instep 124).

As

thecode updates arebeingdownloaded, the

download

routinealso recordsstatus information (suchas the

FTP

addresses)

of

the codeupdates incaseof interruption tothe

communication

line. Ifthereis such

an

interruption, the

downloading

cancontinue later

where

it left off. Becausethe interruptioncould belengthy

and

the systemcharacteristicscould

have

beenaltered, immediately beforethe selected code updates are actually installedthe update

manager

32 invokes thecorresponding

recognizer

programs

againto ensurethatthecodeupdates are still required; itis possible thatchanges could have occurred tothe clientsince the recognizerprograms

were

END9-1997-0019-US2

^{- 11 -}

previously executed. Ifthe

code

updates arestillappropriate, theserviceapplication routineofclient 14 installs thecodeupdatesinthe client 14as follows (step 134).

For

every code updatefile

whose

staleversion isnotcurrentlyinuse by client 14,theservice applicationroutinereplaces the stale filewiththeupdated file.

The

update

manager

also 5 listseach

code

updatefile

whose

staleversion iscurrently inuse. Then, the client is

requestedto re-boot, andthe operatingsysteminstalls thelisted

code

updates duringthe re-boot.

For

allcode updates selectedbythe userthatrepresent

one

or

more

bytes ofa

file, the service applicationroutine replacesjusttheone or

more

bytes ofthe file.

For

suchfiles that arenot currentlyinuse, thisoccurswithout requesting the userto re-boot.

10

For

suchfilesthat are currentlyin use, theuserisrequested tore-boot,

and

the operating systeminstallstheone or

more

bytesduring there-boot.

Pi

Fig. 6illustrates another

embodiment

ofa

computer network

generally designated410.

Network 410

comprises aselection server

412

withadatabase 413, a

^

content server 417, clients414-416, andInternet20tointerconnect the servers and

15 clients.

By way

of example, the selectionserver

412

comprises a

computer

workstation withassociated

programming

and a

modem,

thecontent server

417

comprises a

computer

a workstationwithassociated

programming

anda

modem,

and each oftheclients

414-416

D

P

^{comprisesa personal}

^computer

with associated

programming

and a

modem.

M Communications between

the clients andthe selectionserver

412

usehypertexttransport lr 20 protocol

(HTTP)

and

communications

betweenthe clients

and

the content server

417

use

Q

^{filetransportprotocol (FTP). Althoughnotshown, thereare}

^many

^other servers for the Internet.

Selectionserver

412

is dedicatedto automatingselection ofdataupdates and additionaldata, collectively called

"new

data."

The

contentserver

417

includesthe 25 actual,

new

data(stored

on

disk421), and database413 includes

meta

datafor the

new

data and

FTP

addressing informationto locate the

new

datain content server 417.

The meta

dataprovides descriptive information abouttherespective

new

datasuch asthose userattributesfor

which

the

new

data^isappropriate (assumingtheuserdoes not already havethe

new

^data).

The FTP

addressing information indicates theaddress or

30 identificationofthe content server

which

stores therespective

new

data (content^server

417

inthe illustrated example), a user

ID

and passwordto log-ontothe content server, a

END9-1

997-00

19-US2

^-

12-

name

ofthe

new

data, alist

of

files

which

comprisethe

new

data andthesize, checksum, and directory

of

eachfile.

According

to

one

process for storingthe

new

dataⁱⁿthe content server

417

andthe

meta

datainthe selectionserver412, a personwrites the

new

dataand

meta

5 dataand loads

them

into the content^server417, eitherviatheInternetor

by manual

loading.

The new

dataremains storedinthe contentserver, but the

meta

dataiswritten totheselectionserver412, either via the Internetor

by manual

loading.

As

illustrated inFig. 7, the selection server

412

is an

HTTP

serverwith an associated

"CGI" program manager

431 and includes a dataselection

program

430.

The

G

^{10 client}

⁴¹⁴

^{includesan update}

manager program 432

(including aGUI), a scoutroutine

tfj 433, aservice application routine 434, and a

download

routine439.

The

functions ofthe serverand client

programming

and atypical client-serversessionfor selecting

and

H

downloading

new

dataareillustrated inFigs. 8a and 8b.

£ A

user at client computer

414

selects aniconto invoke update

manager

JL 15 432. In response, theupdate

manager

contactsthe general

manager

431 in server

412

to

L..J

fS begina sessionand supplies thecurrent level of update

manager

432, scout 433, ^service

M

application434, and

download

routine

439

withinclient

414

(step 504). In response, the

.14 general

manager

431 determines ifthe client'supdate

manager

432, scout 433, ^service

0

application434, and

download

^routine

439

are thelatestversion(step 506). This 20 determinationisperformed

by

comparing theclientlevel information supplied

by

the

client

414

tothedatain selection server

412

forthelatestversionoftheclient'supdate

manager

432, scout 433, service application434, and

download

routine

439

stored inthe contentserver417.

Ifthe client'supdate manager, scout, service application, and

download

25 routine arenot the latestversion, the server sendsthe

FTP

addressing informationto the clienttoallowtheclientto retrieve the latestversions from acontent server.

Along

with the

FTP

addressingforthe clientupdate manager, scout, service application, and

download

routine, the serversends

FTP

addressing informationtotheclient for aserial

number

recognizer

program 441

stored in content server

417 which

will query client

414

30 forthe serial

number

ofclient

414

(step 507). Next,the client

downloads

and installsthe

END9-1

997-00

19-US2

^{- 13-}

latest version

of

theclientupdate manager, scout, service application, and

download

routine

from

the content server^ifthe

FTP

addressing

was

^{provided (step 508).}

The

furnishing ofthe

FTP

addressing informationforthe recognizer

program

441 beginsthe

new

data selection process.

The

clientnext

downloads

the

5 recognizer

program

441

from

the content serverand executes^it(step 509).

The

recognizer

program

441 then obtains the serial

number

ofthe client

414 from

the basic input outputsystem

(BIOS)

firmware, using scout

APIs

(step 509).

The

update

manager

routine

432

thensends the serial

number

ofthe client414, obtained

by

the recognizer

program

441, tothe selection server

412

(step 510).

10 This initiatesthe selectionupdate

program 430

(step 5 12).

The

selection update

program 430

within server

412

then determines,

from

atable435, the

employee number

or

name

ofthe user^that

owns

the

machine

comprisingclient414. Alternately,

when

^{there is}

more

than

one

userofclient 414, theuserssendtheir

names

orserial

s

~7

numbers

tothe server

412

(in step 510). Inthis scenario, selection server

412

doesnot lc ¹⁵ sendthe

FTP

ofrecognizer

program

441 to client414 instep

507

and ^client

414

does not

!L fetchor execute recognizer

program

441. Thereisnoneed.

; b

Hse?

Oⁱ

Once

selectionserver

412 knows

the

employee number

or

name

ofthe

f^i userof^client414, either

from

recognizer

program

441 and table

435

ordirectly

from

the

Q

^{user, theselectionupdate}

^program

^candetermine

^which

^dataisappropriateforthe user 20

and which

datais not appropriatefortheuser. This eliminates thevastmajorityofthe

datastored in content server

417

(and othercontent servers, ifany)

from

further consideration (step 514). In the illustratedembodiment,this determination ^is

made by

havingthe selectionupdate

program

firstreadfrom table

435

theuserattributes

correspondingtotheuser's serial

number

orname. Theseuser attributes

may

include the 25 user'sjobtitle, department, profession, age, income, orinterests previously expressed

by

theuserand forwarded^{tothe server. Then, the selection}update

program

correlates the

meta

dataindata base 413 to theuser's attributes.

Matches between

the

meta

dataand theuser's serial

number

or other ^{attributesindicatethatthe} corresponding

new

data

may

be appropriate forclient414. Inpractice, the

meta

data andtable

435

canbe arranged in 30 a relationaldata baseto facilitatethecorrelation function.

END9-1

997-00

19-US2

^{- 14-}

For

example, the followingtable listsdataavailable in content server

417

andtheuserattributes-

meta

datathatmatches each

of

the

new

data.

r³^

New Data User

Attributes-Meta

Data

Customer

List Marketing person

5 PriceList Marketing person

Salary Chart

Manager

Company

Rules All

Employees

Golf Ad #

1 (news) Golfer

Golf Ad #2

(equipment) Golfer

10

Bowling Ad

#1

Bowler

Bowling Ad

^#2

Bowler

Inthis example, users

who

are marketing

employees

are entitledto receive only

"Customer

List,""PriceList," and

"Company

Rules" data. Users

who

are

management employees

are entitled toreceive only "Salary Chart"and

"Company

Rules"

15 data. Users

who

aregolfers, but not employees, aretargetedto receiveonly

"Golf Ad

#1" and

"Golf Ad

^#2" data. Users

who

are bowlers, butnotemployees, are targetedto receiveonly

"Bowling Ad ^#1"

and

"Bowling Ad

^#2" data.

For

each

new

data

which

isconsistentwiththeuser's attribute(s),the selectionupdate

program 430

sendsto the client

414

the

FTP

addressinginformationof a 20 correspondingrecognizer

program

andthecorresponding

meta

data(step 516).

For

example, fora userhavingthe attribute ofgolfer, the selectionupdate

program 430

sends the

FTP

addressing forrecognizerprograms

440

and442, respectively for

"Golf Ad

^#1"

and "Golf

Ad

^#2."

The FTP

addressing informationis not providedtoclient414,

however, forthe recognizer

programs

forthe other

new

data

which

^is not consistentwith 25 theuser's attribute(s).

From

the

FTP

addressing information, the client

414 downloads

the actualrecognizer

programs from

the content server

417

(step 518).

Each

recognizer

program

is executable and small, typically2,000 ^- 3,000 bytes. Consequently, each recognizer

program

can be

downloaded from

content server

417

totheclient

414

in seconds (whereas the corresponding

new

data

may

be

much

30 largerand takeminutes oreven hourstodownload).

END9-1

997-00

19-US2

^-

15-

Itshould be noted^that, based

on

the userattribute(s) alone, the selection update

program 430

within server

412

is not sure

which

ofthe

new

datathatisconsistent withthe user's attribute(s)is actuallyneeded

by

theclient.

For

example,the client

may

alreadyhave

some

orall

of

the

new

data.

5 Next, the client

414

executes recognizerprograms

440

and

442

with assistance

from

the scout 433 (step 518).

The

scout433 assiststhe recognizer

programs by

providing subroutinesthat canbecalled bythe recognizerprograms.

For

files required

by

the recognizerprograms,these callable subroutinescan locatethe files,

determinetheversionofthefiles, determinethe lengthofthe file, identifya directory 10

which

^liststhe^files, obtaintime stamps forthe^files, obtain data

from

insidethe files, and

n

^{obtain data}

^from

^a

^program

^{registry. Thisfurtherreduces}the requisite length

of

each J3 recognizer

program

andtherefore shortens the

download

time.

When

executed, each

iff

*Lj recognizer

program

further investigates storageofthe client

computer 414

to determine if

M

^theuser already hasthe

new

dataavailable

from

theclientcomputer. Optionally, the

^

^{15 recognizer}

^{program may}

investigate auserprofile

437

storedinthe client

computer 414

V

to determine whetherthe

new

data isconsistentwith otheruserattributes storedinuser

^

^profile437.

m

H> Recognizer

program 440

is illustrated in

more

detail inFig. 9

and

!i! investigatestheuser'sstorageas follows. Inthis example,the soleuserattribute (stored

g

^{20 intable435 intheselection server412) is} "golfer." First, recognizer

program 440

determines

from

the scout routine433 inclient

414

ifclient

414

already has a

copy

ofthe

Golf Ad

^#1 available forthe user(decision 600). Ifnot,then recognizer

program 440

determinesthat, so far,

"Golf Ad

^{#1" is}

deemed

appropriateforthe user(step 602). If client

414

stores afilecalled

"Golf Ad

#1," however, then recognizer

program 440

25 optionally will

check

ifthis isthe

same

file astheone currentlystored

on

^the serverwith the

same

name. Accordingly, recognizer

program 440 compares

the size ofthe

"Golf Ad

#1" file stored in client

computer 414

tothe sizeofthe "Golf

Ad ^#1"

^file storedinthe contentserver

417

(step

604 and

decision 606). (Thesizeof

Golf Ad

#1 stored in content server

417 was

included inthe

meta

datathat

was

sentalongwiththe

FTP

address ofthe 30 recognizerprogram.) Ifthe sizes are different, then recognizer

program 440

concludes

thattheyare different files

and

thatthis file is

deemed

appropriatefor

downloading from

thecontentserver to the client

computer

414 (step 602). Ifthe sizes are thesame, then

END9-1

997-00

19-US2

^{- 16-}

recognizer

program 440

concludesthattheyare the

same

^file, and another

copy of "Golf

Ad ^#1"

^isnot appropriate for

downloading

totheclientcomputer(step 608). Recognizer

program 442

performsthe

same

^{analysis for}"Golf

Ad

^#2."

For new

datathat arelengthy, arespectiverecognizer

program

could also determine ifthe client

computer

has sufficient

memory

forthe

new

data

by

usingthe appropriate scout function.

A

^recognizer

^program

^{could also}

compare

the

meta

datafor

new

datatouserprofile

437

maintainedin client

computer

414.to furtherdetermine whetherthe

new

datais appropriatefor theuser. Forexample, the userprofile

437 may

qualifythat the user's interests ingolfare limited to golf

news

but not golfequipment. In sucha case,the recognizer

program would

determine that"Golf

Ad

^#1" relating to

"news" would

beappropriate forthe user but"Golf

Ad

^#2" relating to "equipment"

would

notbeappropriatefortheuser.

Assume

that another recognizer

program 442

illustratedinFig. 10 correspondstothe

"Customer

List" data. Recognizer

program

442,

when

executing in client computer414, will determine ifthe user already has afilecalled

"Customer

List"

(decision700). If not, then the recognizer

program 442

determinesthatthis datais

appropriatefor

downloading

tothe client(step 706). Iftheclientalready has afile called

"Customer

List," however,then recognizer

program 442

will

compare

(step 704)the date associatedwiththe creationofthe

"Customer

List" filestoredinthe server (and fetched withrecognizer

program

442) ^tothe date associatedwiththe creation

of

the

"Customer

List"file stored inclient

414

(and obtained in step 702). Ifthe datestoredinthe serveris later, thenthe

"Customer

List" data storedinthe serveris appropriatefortheuser(step 706). Otherwise, it is not appropriatefortheuser(step 708).

The

results oftherecognizerprograms include yes/no answersto the 25 question of whether each respective

new

dataisappropriatefortheuser, i.e., not

currently available in client

414

forthe userand, optionally, consistentwith theuser's .

profile, ifany, storedin table

435

inthe ^client computer. (The selectionupdate

program

previouslydetermined thatthe

new

data

were

consistentwiththe user's attributes^,stored intable

435

in the server computer.)

The

recognizerprograms canalso assigna"critical"

30 level toeach

new

databased

on

the need oftheuserforthe

new

data.

For

example, ifthe dataare especially important such as the

"Customer

List" or the"Salary Chart," andthe

u

10

15

20

END9-1997-0019-US2

^-

^17-

userhas

no

versionoravery old^version, thenthis data

would be

assigned ahighlevel of

criticality. After the recognizer

programs

are executed in client414, client

414

sendsto selectionserver

412

alist ofthe

new

data

which

is appropriateforthe user (step 520).

Based on

the information gathered

by

the recognizerprograms, the 5 selectionupdate

program

determinesthelevelofcriticality

of

the respective data and

builds aselection

form

fordisplay attheclient(step 522).

The

selection

form

comprises alistofthe

new

datathatisconsistent withthe user's attributes

and

appropriateforthe client414, and a display ofthe followingthree selectionchoices (step 524):

1. critical data(to minimizethe

download

time);

2. all

new

datathatareappropriateforthe user; and

3. client selectionofappropriate

new

data^-user selects particular

new

data

from

the listof^all

new

data

which

areappropriateforthe user.

Next, the user

makes

a selection, either selection

of

the^first or second

15 categoriesoranitemized list of

new

data pursuanttothe thirdcategory (step 530), and sends theselectionto the server(step 531). In response, the server

412

sends to the client

414

the

FTP

addressing informationforthe selected

new

data(step 532). Usingthis

FTP

addressing information, the

download

routine

439

oftheclient

downloads

the

new

data

from

the content server

417

(step 533). In a preferred

embodiment,

the

FTP

addressing 20 informationforall

new

data representedⁱⁿthe selection

form

are passed withthe

selection

form

tothe client

414

(instep 524).

As

the

new

data arebeingdownloaded, the

download

routine also records statusinformation (such asthe

FTP

addresses) ofthe

new

dataincase ofinterruption to the

communication

line. Ifthere is such aninterruption, the

downloading

cancontinue 25 later

where

itleft off.

Upon

completion ofthedownload,the serviceapplication routine

ofclient

414

installs the

new

datainthe client

414

foraccess by theuserasfollows (step 534).

For

all filesconstitutingthe

new

^data, except those

which

representupdatesto existing datastoredinthe client

computer

for

which

the stale versionis currently inuse

END9-1997-0019-US2

^{- 18-}

by client414, the service application routine replaces the^{existing filesin client}

414

with the

new

file.

The

update

manager

^{also listseach data file}

whose

staleversionis currently inuse. Then, theuseris requestedto re-boot, andthe operatingsystem installsthe listed data during the re-boot

For

allappropriate

new

data selectedbythe userthatrepresents 5 one or

more

bytesofa^file, the service applicationroutine replacesjustthe

one

or

more

bytes

of

the^file.

For

such filesthat arenotcurrently in use, thisoccurs without requesting the userto re-boot.

For

such filesthat are currentlyinuse, the useris

requestedto re-boot,

and

the operating system^installsthe oneor

more

bytes duringthe re-boot.

Techniquesforselecting and transferringcode updates and

new

datato a client

computer

have

been

disclosed.

Numerous

modifications andsubstitutions

can be

made, however, without deviating

from

the scopeofthepresentinvention.

For

example, therecan bemultiple content servers, orthe selection server functions andcontent server function can

be merged

into oneserver. If desired, protocols other than

HTTP

and

FTP

can beused. Further, athree-tiered architecture fordetermining

whether

toprovidea softwareupdate

may

be implemented.

Figs. 11 and 12 areblock diagrams

showing

anotherexemplary

embodiment of

asystem

and method

in accordance withthe presentinvention.

The

present invention determines whetherto provide a software

program

update

820

(ora

new

software program)to

one

ofa pluralityofclientprocessors

860A-860N,

eachclient processor

860A-860N

requiring

one of

aplurality ofsoftware

program

updates. Fig. 1

1

shows

an exemplary systemin accordancewiththis

embodiment

oftheinvention.

The embodiment

includes athree-tiered architecture for determiningthe need for, andcontrollingthe application orremoval (installation

and

uninstallation) of, 25

computer

readable binary data^(referredto as"updates")

from

a centrallyadministered

location.

The

third (or highest)tier includes aselection serverprocessor

850

(which

may

also bethe content server providing

mass

storage forsoftware and data).

The

second ^(or middle) tierincludesan administration serverprocessor

800A which may

include a

GUI.

Administration serverprocessor

800A communicates

withselection server processor

850

30

on

behalfofthe client processors

860A-860N,

the first (orbottom) tierprocessors.

The

administration server processor

800A

controls

which

updates are installed anduninstalled

END9-

^1997-001

9-US2 -19-

20

on

theclientprocessors

860A-860N. The

client processors

860A-860N

eachinclude a

"client agent/' a

program

executed

by

each ^clientprocessor

which

accepts

commands from

administration server processor

800A,

processes the

commands, and

returns status information 870, 871 (described in detail below)to administration server processor

800A.

Inthe

exemplary

system, at leastone selection serverprocessor

850

provides a sourceofsoftware

program

updates 820forclientsoftwareprograms

and

system configuration

management

tools,

which

aredescribed in detailbelow.

The

selectionserverprocessor

850 may

be, forexample, anenterpriseserver

which

servesan

entirebusiness oruniversity, or adivision orsubsetofalargerentity. Alternatively, the selectionserver processor

850 may

be a server processorfor a software vendor; a plurality

of

administration server processors

860A-860N may communicate

withthe selectionserverprocessor

850

viaa

worldwide

telecommunications network, suchas the Internet.

At

^least

one

administration serverprocessor

800A

isprovided.

Administration serverprocessor

800A

provides the tools

and

resourcesfor

managing

the system configuration intheclient processors

860A-860N

served byadministration server processor

800A. The

administration server processor

800A

andclientprocessors

860A- 860N may,

forexample, allbe connected ina localarea

network (LAN) 860

within an

office, afloor ofa building, or alocal campus.

On

^the other hand, the administration server

may

serve apluralityofclientprocessorsthatare related bybusinessfunction;the clientprocessors

860A-86ON

and administrativeserverprocessor

800A

need notall be co-located.

The

administration serverprocessor

800A

and its

GUI ^have

thefollowing general features:

1)

The

abilityto logically group multiplefirst-tierclient processors in user definable groups.

2)

The

^abilityto log (track) activity correspondingto each first-tierclient processor.

END9-1 997-00 19-US2 -20-

3)

The

abilitytoperformthe

first-tierclientprocessors.

"update discovery" taskforgroups orsingle

4)

The

abilitytoperformthe"updateapply" taskfor sets of updates onto groupsorsinglefirst-tierclient processors.

5 5)

The

abilitytoperform the"update

remove"

taskfor sets

of

updates

from

groups orsinglefirst-tier client processors.

6)

The

abilityto schedulethe "update discovery,""updateapply,"

and

"update

remove"

tasksto occuratany giventime and frequency.

7)

The

abilityto

view which

updatesare potentially applicable toeach

10 individual clientprocessor orgroup ofclientprocessors.

8)

The

abilityto

view which

clientprocessors are in

need

of

which

updates or agroup ofupdates.

Although

FIG. 11 only

shows

a single

LAN

860, eachofthe other administrationserverprocessors

800B

and

800C

has

one

or

more

clientprocessors (not shown).

The

description of exemplary administration serverprocessor

800A

andclient processors

860A-860N

also appliesto administration serverprocessors

800B

and

800C

andtheirrespectiveclient processors (not shown).

FIG. 12

shows

ⁱⁿgreaterdetailthe pertinentprocesses

and

dataflows within the exemplary system. Inparticular,the functions

and

dataflowsof

20 administration serverprocessor

800A

areemphasized inFIG. 12.

The

administration server processor

800A

includes three

major

tasks describedbelow: the"update discovery," "update apply," and "update

remove"

tasks.

Withinthe administration server processor800A, the"update discovery" task includes blocks 810-816.

The

"updateapply" task includes blocks

817

and 818.

The

"update

25

remove"

taskisnot

shown

inFIG. 12.

The

blocks

810-818

within administration server processor

800A

includeboth general purpose computer hardware and software

program

END9-1

997-00

19-US2 -21

^-

instructions inadministration server processor800A, includingconventionalintra- processorand inter-processor

communications

functions.

Update

Discovery

The

"update discovery" taskis definedasthe administration server process of determiningthe applicability of(orneedfor) a setof updates

820 on

agroup of(or single) clientprocessors

860A-860N.

Thisprocess consistsof

communicating

to selectionserver processor

850

inorderto identifytheadministration serverprocessor

800A and

itslevel

and

type. This

communication may

beperformed, forexample,

by

using

HTTP.

The

selection serverprocessor850 returns

meta

data(which

may

be

HTTP

links)directingor pointing the administrationserver processor

800A

to

download

a

"systemrecognizer"

program

^851.

The

administration serverprocessor

800A downloads

(forexample, via

FTP)

thesystemrecognizer

program

851

from

the selectionserver processor 850.

The

systemrecognizer

program

851 is provided

by

selectionserver processor

850

toasystemrecognizer receiving

means 810

inadministration server processor800A.

System

recognizertransmitting

means

811 transmitsthesystem

recognizer

program

851 tothe clientprocessor860A.

At

block862, the clientprocessor 860

A

executes the systemrecognizer

program

851 todeterminethesystemconfiguration attributes.

The

administration server processor

800A communicates

a

command

and

meta

data(via

HTTP)

toeach clientprocessor

860A-860N,

as directed

by

the system administrator(user)

from

the

GUI

ofthe administration server processor

800A

^This

command and meta

datacause each affected clientprocessor

860A-860N

to

download

25 (via

HTTP)

thesystemrecognizer

program

851 and execute it.

The

systemrecognizer

program

851 isresponsiblefordetermining asetofhardwareand/or softwareattributes foreach clientprocessor

860A-860N

that executes thesystem recognizer

program

851.

The

systemrecognizer

program

851 in eachclient processor

860A-860N

thenreturnsthe 10

ry

n

15

20

END9-1 997-00 19-US2 -22-