CA2501499A1 - System and method for a software distribution service - Google Patents

Abstract

The invention is directed to a system and method for managing software updates. More specifically, the present invention is directed to a system and method for facilitating the selection and implementation of software updates while minimizing the bandwidth and processing resources required to select and implement the software updates. In accordance with an aspect of the present invention, a software update service controls access to software updates stored on servers. In accordance with another aspect, the software update service synchronizes with client machines to identify applicable updates.

Description

' .. ., SYSTEM AND METHOD FOR A SOFTWARE DISTRIBUTION SERVICE
FIND OF THE INVENTION
The pras~t invention relates to soft~weae and ~ networks and, in S particular, the px~t invention relates to a system and method for managing acct communicating softwam updates.

Most commercially available software products undergo a continual revision process to repair or upgrade fand/or functions. Each revision of a soRware product or component may raluine the addition of new files and/or the rcplacemart of acisdng files with files of newer versions. Once a vendor has isolated a software product problem acct created a sohrtion for the problem, it would want to put that fac into as update and make the update widely available to the customers. Soflvvare vendors have a business in~ive to distn'bute software upd~ to customers as quickty and trouble-free as possible.
The Internet provides an importaQt channel for customers to obtain the latest updates for software produces. The explosive growth of Internet usage has a common exp~on by customers that software prodwcts and updates be provided online for downloading. It is also in the iaterast of software vendors to promote the use of the Internet to distn'bute updates, because it ratuces their costs cad allows customers to obtain the fix for as idc~od problem as soon as ttu fix is made available for downloading. The vendor sifts on the Internet can be designed to melee it very simple to discover and locate update files for as applicaiioa. The technical aspects of file download have mostly dish from the use's view, anti arc now typically handled by the opting system.
In a conventional approach, a software vendor constructs a soflrovare update as a "package" for do~cvvnlaad... This package is typically a self-exfiracting executab,~e file with the setup program and each of the product's updated files anbedded and compressed to make tb~e package smaller. The size of the package is gmeFally the sum of the compressed sizes of each changed file, plus the size of the extraction code itself. Upon execution, the package extracts each of the contained ides to a temporary location, then starts the setup program to install each file to a proper location in the system's directory.
F'~les that are shipped in a compressed form are decompressod as they are iaaeoilcd. Any existing f~le of the same name in the same location would simply be overwrittea~ by the replaa~ent file.
Even though the makes wide and quick distn'bunon of software updates possible,13x limited bandwidth of network traasmissioa has caused problems.
The sheer sins of common softwam applications have caused tl~ download sins of updates to ba~me unraasoi~ably large. UsuaDy a multitude of 5xes for a variety of problems of a product will be grouped into an update. If a veraiar t~pdat~ a software product on a regular basis, the download size of the updaroe package will continue to grow, the vendor cannot omit files under the ssst~nption that the uses already has those files from earlier updatos. Because the update package combines a number of whole files, it may be quite largo, even when the files are cod. Sometimes, even on the fastest modi~n coons, the bandwidth e~cieacy of the download is de~ssed.
The time-consuming aspect of the comrentional downloading pt~ocess is, of course, undesirable. In some cases, customers pay long-distencx or colon time charges during these file downloads. Any reductions in c~an~ion time will reduce the direct monetary cost for these customers. The va~dors typically also have some distinguishable costs relating to flue sizes of downloads they provide, so reducing the sizes may give them direct monetary benefits as wall. Reducing the sizes of downloads will increase their available network t~adwidti~, allowing than to serve more customers with existing network server equipment.
The long tame it takes to download a large update also makes the downloading mare vulnerable to various network c~anection problems. There are a number of reasons why an Internet session might be disconnected pram~u~ely, inch>ding telephone line noise, call-waiting signals, and tmional coma~aads. Some Internet service providers enforce a con~ction time limit, limiting the amount of time the user can be on-line in a single session. If the user is downloading a large file when the network connection is cut o$ he or she may have to start over. Most common operating systems and file transfea pmtoools do not allow the file transfer to be resumed, so any interim progress would be lost, and the transfer would have to be x~ted. The oppomn~ies for failure are so n~s that many users fend it nearly impossible to obtain the update online. If the size of an update pacacage is too large, users may never be able to completely download it,

-2-One attempt bo reduce the size of software updates and increase bandwidth e~ciency relates to the use of delta , or binary patches. One skilled in the relevant art will ale that a delta patch ~sponds to specialized software code that modifies as existing file when exccutal by a computing device. Because the delta patch includes specisliud sot3ware code, a unique delta patch is required for each unique version of a file. As applied to soflwarc updates, a soltwate update servnce can tra~nnit a smaller sized update dolts patch instead of transmitting a complete, updated file. The updated dolts patch is then udilizcd to modify the existing file into the updated file.
Although the update delta patchr~s can potentially the amount of data requirod to update flea, cement approaches to cklta patching acre deficient in managing the selection of applicable delta fibs in situations where a Large number of versions of a file exist. Because a unique delta patch is required for each version of a file, typical software update systems can often requite hundreds, if not thousands, of unique delta to corn~pond to each ~miqun version of a file. In one approach, some update I S services supporting delta patching transmit all poss~'ble delta patches to a cliert computing device. Howavar, this approach typically increases the amount of data rcqirired to implement the saftwarc update as the ninmber of possible update delta patches incn~sc. Accordingly, the number of pot~ially applicable delta patches crate quickly grow to the same size as the complete updated file. In another approach, a nuctwozked update software service scans a client machine to select which delta patch may be applicable far each client machine. Although this roduc~ ttx amount of delta patch information that is transmitted, it roqt>iras ~lditional logic on the software update service to scan the client machine and select an applicable delta patch. T1u use of the additional logic increases the system rtso~a~cxs that must be provided by the service.
F~uthar, this approach typically pn~ the trfilization of network caching, such as is typically achieved by traditional Web savors.
In addition to the above described sbor't~omings, existing systems are unable to deliver certain types of software updates, such as hardwa:e drivers. As known in the art, specialized software updates, such as those that apply to hardware drivers, are difficult to provide to users on a large-scale distribution bearuse most specialized software update will only work on client computers with specific hazvdvvare. In most cps, for example, if a client computer obtains an incompah'ble hardware driver upgrade, the installation of the driver upgrade may cause a fatal error, or even prevent the computer from operating.

-3-~_~
As will Ix readily uaderatood from the foregoing, thane is a need for a system and method having improved asamunic~tion of software updates bdv~n a servo and a number of clients. In addition, there exists a need for a soflwvare update system and method having impzovai mxhaaisms for allowing update services to target specific types of clients when delivering specialized updates.
SUMMAZtY OF TIC INV»ITION
The present invention is directed to a system and nnethOd for managiag software updates. More specifically, the present invention is directed to a system and method for facilitating the selection awd implon of software while minimizing the IO bandwidth and processing resources reduirr~ to select and implement the software update, In aecordaaae with an aspect of the pt~ent invention, a software update service co~rols acs to software stored on servers. In accordance with another aspect, the software update service synchronizes with client machines to identify applicable Tn accordance with as aspect of the present invcation, a method of communic~ing between a client com~utnOg device process and a server process in a distributed processing system is provided. In accord$nce with the method a client pmxss issues a synchronization The synchronization request includes an identifier of an installed software update if the client computing device stns the installed software.
update. A server process recxives , the synchronization request and selexts sn additional software update if the synchm~on rat co~is~ as ideatifer of at least one software update. The seloctian of the additional softovare update is dcpendeat on the fulfillment of a preroquisite defnuxl in the additional software update. The prerequisite raquiz~es the sync~hro~ation request to include an identifier for at least one specific software update. The carver process selocts a first level soflwere update having a null valve as a prerequia~ts if it determines that the synchronization rest does not comp~rse an identifier of at least one soflvvare update. The server process issues an instruction component of the selected software update. The client process receives the instruction component of the selected software update and skores the instruction components of the selected software update in the client computing devicx as as installed software update if the client computipg device contains at least one component that fu?»ls a condition of an applicability rule stored in the selectod software update.

-4-Ia aoCOrdance with another aspect of the present invention, a mof commamicabag bavvem a client oampuaag device procxas and a sower pin a dish3bu#ed processing systan is provided In accordan~x with tlu method, a cheat pros issues an authoz~iaa Ttte authorizatioa request coatains an id~tificr S of a client atrthOrl~ion module associated with a target group. A servez pracess receives the authorisation request and issues a server cookie idontifynag the target group if the server.process dexects the pie of a leaver soaware module asked with the target group. The client process receives the sewer cookie identifying the target group and issues an update r~eqnest for at least one softarare t~pde~e, whceeia tt~e raqtr~t comtains the server cookie. The server process receives the update request and issues a software update if the soflwan update is associated wig the target groag identified. in the leaver cookie. The client pmac~ss reeuives the software update if the software update is as~o~d with the target gmug ids in the serve cookie.
Ia acoordanae with a (aspect of the presemt ioa, a system for commuaicati~ and maaegiag software updaxes is provided. The system includes a first database storing a plurality of updates. An individual sofhvart update shored in the database cea include as instruction data field cont~nining an applicability rule defining at Ieast ooue ion, iacludiag a mlll value. The instruction conopon~t co~aias a ~t of perquisites that identify ane ar more software updax~ that are requited for iastailation of the individual software updafie, includiag a null values The individual softvvane update stored in the database caa also include a tocalixod data field containing text data dessn'bing ge~rsl information rotated to the individual soflwa~ update.
Additionally, the individual software update stored in the database can include a data componcat that identifies ai least one date strram, file assoasted with the individual software update.
Tlx system can also include as authorization ae<vrx fns rizang mess to software updates stored in the f~u~st database. The authorization servtr issues a server cootie for allowing a clitnt computing device to aroe ttLO individual sofl~vart update if the client co~mput~g device coa~ins an authorization module indicating that the client computing device is assocdated with a target group. The saver cookie contains as identifier for the target group. Additionally, the server cookie is communicated to the client computing device for storage of the server cookie.
The system can fwr~r include a metadata leaver for p~rovidu~g updates to the client computing devicx. A software update is commuaicated to the client computing

-5-23~1PGT ~ ' deVi(x if the S0~9VatC Zipd~ 1S a39oc18led Wlth tlbC taT~C't $'r011~1, WbChCm tile met8d8ta server is communicatively coupled to said first database. The metsdata server can obtain a synclu~Onizatioa request. The syncon request includes sa identifier of an installed software update if the client computing dcvicx stores the installed software update. The synchronization request includes the nave cookie. The mete data server can also select an additional soRvvare update for communication to the client computing device if the synchronization request comprises an identifier of at Ieast one installed sofli~re update. Tine selection of the addnionat saRwarc update is dependent on the fnlfillmant of a prerequisite define in tire additional software update. The prerequisite raquines the synchronization raqurst to include an identifier for at keast one installed software update. The additional software update is associated with the target group identified in the server cookie. The metadata server also selects a first level software update for communication to the client computing device if the synchronization request does net comprise an identifier of at least one installed software update, The first kevel soRwan updates do not i~lude a prerequisite. The metadata server can communicate an instruction of the selected software update to the client computing device for storage and obtain a request far localized data associated with the selected software update. Still fmrtbGr, mserver cam communicate kocaliz~l data associated with the selected softvvart update to the chart computing device. The localized data allows the client computing device to generate a download roqu~t for receipt of a data component of the selected software update.
The system can fiuther include a download server communicatively coupled to the fast datsbe~se. The downkoad setva~ can obtain the download request from the client computing device. The download request idemttfies the data component of the selected software update. The download server can communicate the data component of the selected software update to the client computing device.
In accordance with anoxher aspect of the present invention, a system for dating data on a client computing device is provided. The system includes a first database storing a plurality of delta patches. The system also includes a server computer communicatively coupled to said fast database and to the client computing devicx. The serves can obtain a selection of one ar more available software updates for upc>ating one or more files installed on the client .computing device, a self-extr~ecting file identifying a plurality of available delta patches for updating at least one version of as installed file

-6-and an inve~ory of the one or more fills installed on the client computing device. The server can also select one or mom applicable delta patches to implement the selected software updates. The selection of the o~ or more applicable corresponds to a mapping of the self-~act~acting file identifying the plurality of available delta patches to the inventory of the o~ or more files installed on the client armpubng davix.
The server cea fiatber tra~nit a request for one or more selected delta patches.
In accordance with still a further aspect of the present invention, a system for communicating software updates to a client campuaung device is provided. The system includes a fast component storing a plurality of a server sutlmrization modules. The individual servo authorization modute ideumifies a target group. The system further includes a server computar commuaic~tively coupled to the first component. The server can obtain an authorization request from the client computing device. The authorization request contains as identifier of a client authorization module stored on the client computing device. The saver can further determine if the client computing devicx is associataJ with the target group if the client authorization module iadic~tes that the client computing device is associated with the targd group. The server can fiudur communicate a server cookie from the soflvsrare update service to the client computing devicx if the client computing device is associated with the target group. The server cookie identifies the targex group. The can also obtain a request for at least one soflwane update stared on the software update service, wherein the request contains the server cookie. In response to obtaining the request, the servex csa detcnoai";e if a softv~
update is associated with the target group idteabfiod in flu server cookie.
Additionally, if the software update is associated with the target group identified in the server cookie, the server can communicate the software update from the software update service to the client computing device.
In accordance with still another aspect of the present invention, a computer-readable medium having stored tlxmon a data stzvchn~e of as individual sod update is provided. The computea~readablc medium includes an instruction data field containing an applicability rule defining at least one condition, i~luding a null value. The instruction component cxazrains a set of praoqirisites that identify one or more software updates that are r~irai for installation of the individual software update, including a null value. The computer-readably medium can also include a localized data field containing text data describing general infonbation related to the individual softvvarc ..
tlpd~C. ~ COm~Cr-rt8d8b1E mCdliml: CSn f~f InCltidt 8 d8~a COln~01'EC~ $1aI
identifies at least one data s~sm file as,~ociaLed with flat individual soflvvare update.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing aspects and many of the aunt advantages of this iaventiaa will bocome more readily appre~d as the same become better understood by reference to the following detailed de,RCription, when taken in conjunction with the accompanying drawings, wherein:
FIGURE 1 is a block diagram of a softwasre update system, including a client computer and an update service providing update softvvaxe in accordance with the present invention;
FIGURE 2 is a block diagram of the sod update sysEam of FIGURE 1 illushating the authentication of a client coaoputing device with the update service in accordance with the present ikon;
FIGURE 3 is a block diagram of flit software update sysGam of FIGURE 1 I S illustrating the synchronization of available betvvten a client computing device and the update service is acxordance with the present invention;
FIGURE 4 is a block diagram of the software update system of FIGURE 1 fllustrating the traasoaissioa of software update information to a client computing device from the update service is accordance with the prESent invention;
FIGURE 5 is a block diagram of the soRvvare update system of FIGURE 1 illustrating the procGSxing and selection of update infom~ation by a client computing device in accordance with the present invention;
FIGURE 6 is a block diagram of the software update system of FIGURE 1 illustrating the merging of delta patches and installation of updated files by a client co~ng device in accordance with the pry invt~ivn;
FIGURE 7 is a flow diagiam illustrative of a sofli~re update routine implemented by a client computing ,device and an update, service for identifying software updates available for installation on the client computing device, in accordance with the pct invention;
FIGURE 8 is a protocol dia~am of as authorization routine for providing selxtive access to updates stored on the update scxvice, in accordance with tlx present iavr~tion;
_g_ 232?iPGT
FIGURE 9 is a block diagram of an example set of software updates dlust~ing as authorization routine, is accordance with, the present invention;
FIGURE 10 is a protocol diagram of a synchronization routine for cxunmunicating a select group of softvva~re updatts from a soflwatx update service to a client computing device, in accordance with the present inveertion;
FIGURE 11 is s bloctc diagram iZhistrs2ing an exemplary section of a graphical user iaterfax for displaying a list of soflwam upda~ea that arc available to as individual cfieat computing device, is acco:dsace with the pry ir~vendoa;
FIGURES 12A and 12B are illustrative of a software update pmc~sing sub-routine 1200 imply by the client computing device 110 to retrieve and insdaIl requested software in accordance with the present inveantion; and FIGURE 13 is a Sow diagram illustrative of a sub-routine implemented by a client computing device for updarjng a baselinue installation component in arxoxdmnce with tlu prat invention.
DETAILED DESCRIPTION OF Tip PRF.~TRRED EMBODIMENT
Generally describal, the present invention is directed to a system anal method for managing soflmmre updates. More speafically, the present invention is d;rxted to a system and method for facilitating the selection sad implementation of sof3vvare updates while minimizuig fta; bandwidth and procxssing resources required to select and implemea~t the software updates. Ia ascardana with the present invention software rzpdata$ asn carrapond to updates for specific software applic;etians or operating systems.
Further, software updates can include software drivers or update to fiaaware, such as system BIOS. In aa;ordanc;e with as aspect of the present inve~ion, a system and component architfor processing the software updates is provided. In accordance with another aspect of the presoat invention, ~ update protocol and interface to facilitate the autbarizatian and syachronizarion of client ma~chiaes with an update service is provided. Ta accordaacx .with a further aspect of the present invention, a method for updating an installation component sad various installed files utilizing delta patches is provided. One skilled in the relevant art will appreciate, however, that additional aspects of the present invention may aLao be provided in the present application.
Further, one skilled in the relevant art will apprxiste that each identified aspect may be considered individually or as part of common invective aspect.

a ~27iFCf .
FIGURE 1 sod updates systca~ 100 is a block diagram illustrative of software update system 100 in accordance with the present invention. Generally described, the software update system 100 may comprise one or more client computing devices I
10, an update service 120 sad as extanal updats pcavider 130. C,enaally descn'bed, the update service 120 stores and manages the distribution of software updates that are communicated to and installed on the client computing devise 110. The software updates may be provided by the update servicx 120 ar by any number of extain$1 update providers 130.
The client computing device 110, the update services 120, sad the external update provider 130 el~tronically communicate via a network 101. The network may be a local area network .(LA1V) or a larger network, such as a wide area network (WAIF or the Internet. By the use of generally known soflvvare, the soflvme update system 100 may be configured to excdrange documents, commands, and other known types of information betuvecn the client computing device 110 and the sorvas 121, 122, 123 and 124 of the update service 120. As will be appreciated by those skilled is the art and others, the softw~ update system 100 shawa in FIGURE 1 is a simplified example of one suitable system for implem~ting the press invention and that the print invention is not limited to this ex~nple.
As will be descn'bed in mars detail below, one embodiment tire update service 120 comprises a number of servers. As shown in FIGURE 1, the update servicx 120 includes an update server 121 for managing the overall prop of the update service 120 arid coordinating processes of the servers 121,122, 123 and 124 of the update cervix 120. The authorization server 122 generates authorization cookies as rued by flue client and, in turn, the authorization cookies are used to generate server cookies, that allow client co~utera to access updates provided by the update services 120. The metadaia server 123 provides gsneral infonuration regarding the updates provided by the update service 120. The metadata saver 123 allows the system of the present inve~on to identify specific updates for a specific type of client computer or a spxific group of client computers. The download server 124 provides one err more software compane~s for delivering data files associated with soRw~re updates provided by the update service 120.
The exteraaF update provider 130 may inchuie one or more servers that distn'bute software update. The external update provider 130 may be associated with an entity that ....
provides softv~re, software updates, or other data that ie to be distributed to groups of chart comp~rt~rs. For example, the external update provider 130 may be associated with a third party software developer desiring to use the update service 120 to distribute updates far one ar more software applicabioas. In another example, the ~ttemal update provider 130 may be associated with soflararx update system 120.
The client crnoaputing device 110 may be any aomputing device that stores and executes soflvvare applications 114. The client computing devicx 110 may be formed from eny one of a number of different computer prod~ts including, but not limited to, personal computers (PCs), personal digital assistants (PDAs), mobile telephones, two-way pagers, etc. As will be appreciated by those of ordinary skill in the art or others, the architectta~e of the client ~ device 110 may take on eny suitable foxm. For example, the client computing devix 110 may include a network interface for providing commuaic~tion with the netvrark 101. The network iuttrfruce may be configured for use with any wired or wireless nctvvork connection, and may be used with any suitable communication protocol, such as the TCP/ll' protocrol. In addition, the client computing device 110 may include a prong unit, a display, and a memory unit. The memory unit may store the program code nary for operating the client computing device 110, such as an operating system 116. In addition, the memory wait stores an update manage component 112 far a~rolling and cx~ting proof the present invention.
The software update sysuem I00 stores software programs that, when executed, implement the prat izrvention. When executed, the software update system 100 stores, manages, and selectively communicates software update. As descn'bed more fully below, among many other banefita, the present invention provides a mfor defining. and selecting target groups of client computing devices that are eligible to receive software . The presrat invention also provides as improved mechanism for downloading data files associated with sod updates.
For purposes of illustrating the present invention, a detailed description of a working cxannple of the prestot invention is provided. In describing the working example, reference is mad to software updates that may refer to a specific upgrade of a software appliartion, e.g., sa upgrade of a media player version 6.0 to media player version 7Ø As will be appmCiated by those of ordinary skill in the art, such a software update may include the commuuiartion and ion of a number of data files -il-..., assoeiabed with tbc so~.vuare update. Thos, f~ of illustrating the present invention, a distinction is made betv~xn a software update a~ as individual data file containing a software update.
With reference now to FIGURES 2-6, as illustradive interaction betvveen the campoa~s of the software update system 100 to update one or more files oa the client computing device 110 will be descn'bed, With referee to FIGURE 2, the soflvvare update service is initiated by the tlaasmission of software update information by one or more external updatt providers 130. As descn'bed above, the external update providers 130 may be associated with software update system 100.
Alternatively, the software update information may Ix fitted by third-party external update providers 130. In an illustrative erabodim~,t of the present invecaron; the software update infcnrnostion can include software code utilized to update a file, software code utilized to replace a file, various rules for detorminin~g the applicability of the soflvrate and/or display information describing the aoflware update. The transmission of the software update information may be c~nopletad at any time and does not have to be eon~temporaneous with the initiation of the other illustr'a~d software update component interactions.
Upon receipt of the sot3ware update information firm the exienoal update provider 130, the update service 120 genaratas one err mare pierces of data to facilitate the transmission of update information. Tlx data can include a patch storage file tbat con~ponds to set of softvvan delta patches for updating different versions of a file. The data can also include a patch storage m~mifest that oonesponds to as index mapping particular filb versions to a eorrespanding delta found in the patch storage file. The data cxai furtlur include a self-extracting file that conrsponds to information the update agen#
will utilize to request and install specific soi~v~e update data, as will be described in greater detail below. One skilled in the rclevani art will appreciate that the generation of the patch storage file, hatch storage , manifest, and the self-aicrracting fibs may be , c~mplttod at any time and does not have to be contsxaporaneously with the other ~lustrafied component interactions.
To initiate the transmission of so8ware update information to clients, a client computing device 110 initiates an authenfication request to the update servicx 120. Ia an illustratlvt embodiment of the present invention, the authentication request avnasponds to en update protocol iatm~action be2w~a the client com~ag device 110 and the update ?3278PGT
sexviae 120, which will be dea~bod in grartac detail below. Upon eampletion of the auduatication, the update service 120 >seasmits an authentication cookie to the client computing device 120. With rrferarce now to FIGURE 3, the autharticated client computing device I20 than the synchronization of the available updates with the update server 120. In an illustrative embodiment of the prey inve~ion, the synchronisation rexiuest also corresponds to the update protacot interaction bctv~n the client coa~pudng device 110 and the update service I20, which will be descn'bed in greater detail below. Upon the completion of the synchronization, the client computing device 110 receives the information of all applicable software and infarnoarion describing t~ updatts. However, in ea illustrative embodiment of the present invention, no software code to instantiata the update has been dowaioadod.
With continued reference to FIGURE 3, at sometime during the update process, a selxtion of the updates to be installed is rxeived. In an illustrative embodiment of the praxnt invention, a user may be prated with software update information xareived IS during synchronization and asked to select an appropriate update.
Altansiively, the client computing device I I0 may be configured in a manner to automatically select all applicable updates. Further, the client computing devicx 110 may also have soma rules that allow it to automatically select a subset of the available soflvva~rc updates.
Still further, a user may initiate a selection of an update by communicating with the update service 120, such as via an intaxnet Web page.
With reference now to FIGURE 4, the update management component I 12 instaatiates an update agent 118 on the client computing device I I0, if an update agent is not a>ready presart The update agent 118 than requests the transmission of a software update information package, such as self-ea~racting file. The update agent 118 receives the self-exacting file a~ performs any updates to the installer, as will be described below. Furth~x, the update agent 118 can request any missing or comrp~d information from the update servicx 120.
With r~cfcrence now to FIGURE 5, once the update agent I 18 r~eeeives the software update information package, the update agent 118 performs an invartory of the files that are installexl on the chart computing device 110. Based on a comparison of the inventory and the software update information package, the update agent 118 determines which de.tta patch, or other update in~ormatian, will be rexluuxd to complete the selextad updates. The update agent 118 then transmits a request for specific delta updates. In one C~ibOdim~t Of the pICSCnt IilVCatiOn, the TCQI~St for SO~V8rC 2lpdatC6 may COn'QSpOnd t0 a duct request tram~miited Via a direct netvwrk connection, which will be referral to as a m8nU81 lrpdatC. In BnOthCr embOdlmeDt Of the plC9Cnt InVC~iOn, the rC~ll~St fof 90~Wat'C
1may bC a baCkgt'Oltnd T~OqIICSt th8t i5 llBaSmittCd wlthOttt lCI~111T1~ig oVCrt IlSCI
aCtloll. ~liS. CmbOdlmCat wlll bC rCfGIl'Gd to aS an 811tOmatlC llpd8'tC.
In 8n 111VC dnbOdimCat Of the pIC$Cnt InVC~IOn, If the SOflw8rC updatC
can~sponds to 8 dClta patch, the update agent 118 transmits a request t0 the update sarvict 120 that identifies the ~icular delta patch identiflcd by tl~ patch storage manifest. Alternatively, in the event that a delta patch is unavailable or if several delta 10 patchc~ have failed, tire updatr agent 118 can initiate a fallback prods, The fatiback use cea incltule a request for the transmission of a complete copy of the ire updated file from tlic patch storage file. The fallback pro~c can aL~o include a request for the transmission of a complete copy of the entire updated file from in self-contained package.
15 In an illustrative embodiment of the present invention" the download server 124 of the update service 120 can dirnetly process the sofriware u~pdata rfrom the update agent 118. Alternatively, the reqrust can also be praeesaed by any number of additional eactecnal download savers such as tc~titional Web servers that have either received the requestfld update delta p$tchas from the update service 120. For example, a corporation 20 may utilize an internal servo to update client machines. Additionally, the request cam be proxssod by external download savers in which some, or all, of tlx update delta patches are cashed in proccasiag previous requests. Accordingly, in this embodiment, the download can be distn'buted to a nunnba~ of additional download servers capable of servicing hyper text transfer protocol ("lfI"TP") data requ~.
25 With reference to FIGURE 6, once the soRware update information is received, the update agent 118 merges the delta patch with tbc iastsIled file to generate an updated file. Additionally, the update agent 118 csa validate w>retha the merger successfully updated the appropriate file. As descn'bed above, if a delta patch cannot be validated, the update agent 118 may request the delta patch again or rcquast an entire updated file after 30 a number of failrucs. Dace the update agent 118 obtains the validated and update file, the file is installed on tile r,Iieat computing device 1 I0.
FFGURE 7 is a flow diagram of a software update processing routine ?00 illustrating the interaction between a client computing device 110 snd the softwaz~e update ~rvice 120 is accordance with the pcas~t inventions. At block 702, the software update service 120 autbarizes access to the client computer 110. In as illustrative embodiment of tlu paesent inve~ion, the aut~ation of access to the cheat com~rtar cs3n inchtde the gtner~on of a server-isswed cookie for allowing access to soilvvare that are asaoasted with a particular group of ~, A more d~iled of ~
authori~ion piss will be described with regard to FIGURE 8.
At block 704, the client 110 and fete soflwazz update sexvioe 120 synchronic update information. In an illustrative embodiment of the pnteat invention, tine soflvusre npdame service 120 transmits descn'bing specific software IO to the client aumputiag device 110. The metaldata contains in~armation descn'bing the available software to allow a user to solect one or more u~pda~s for installation.
A more detsilad daeription of the syncluoni~atioa process will be desadbed blow with regard to FIGURES 9 sad 10. At block 706, the client computing device 110 obtains a selearon of a~licable updates to download. In as ille Beat of the t invention, the selection of applicable updates can caxmspond to the ion of a number of unique user into uset selectiams. Tb~e selection of near ink will lx described in gresb~x detail with to FIGURE 11.
At block 708, the caonpuimg deviex 110 prop the user seloction of applicable soflvvaro updates and inters with the software update service 120 to request specific update infoanation. 1n ~ illustrative embodiment of the pinvention, the client computing device 110 selects and reque~ one or more applicable update delta pats. The update agent 118 on the client imputing device 110 can then process the requested data to implem~ the selected sotlware update. At block 710, the routine 700 With nfenmCC to FIGURE 8, a pxotoool diagrann 800 for authoriang access to client compuimg devices 110 and canrspondir~g to block 702 (FIGURE 7) will now be daacn'bed. In an Elusttative embodiment of the pre~at i~tia~n, the software update sexvix 120 utilizss an able targeting meclupnis~m to co~rol client compntiag device 110 axess to t~pdamas and other soRvv~ae. The svRarare update service incorporates a mthat associates specific software updates with one yr morn target geau~ of client computing devices 110. For example, the software update servicx 120 may limit acs of a specific hardware driver update to n particular bread of chart compnmng devices 110 having a specif c hardware device. In such an example, the software update aervicx I20 may define a target group of client computing devices 110 having a particular bread name and a specific hardware device and limit the transmission of the particular softwart download to the target gcnttp.
In an illustrative ~bodiment of the p~re~nt invemion, true extensible targeting mis facilitated by the use of software components ("authorization plug-ins") theot define a client computing dcviae's membership to one or more targrx groups. The presence of sa autiwrization plug-in on a client computing device I IO defines vvlu~her the client computing device belongs to the specific target group of the authorization plug-in. A target group, for example, may iacinde all computers having a valid product idertification ("PII?") number for a particular software application. In such as example, , as described in more detail lxlow with rest to FIGURE 8, an authorization plug-in 826 may be installed in the cli~t to read a P1D from a memory module of the client computing device and pass the obtained PID to a canrespondiag FB? server plug-in 829.
The corresponding P>;D plug in, also referred to herein as PID validator 829, utilizes one or more methods to determine if the received P1D is valid: Oncx it is determined that the P1D stored va the client computing device 110 is valid, the server generates a server cookie which indicates that the client computing device 110 is a member of a target group having a valid Pin. In another example, a target group may includo clieart computing devices that are designated as bets test computa~s.
In an illustrative embodiment of the prs~ot invention, the authorization server IZZ of the software update service I20 contains a number of server authorization plug-ins that define a set of target groups of client computing devices that the autlrorizatian server will xe~niu, Each server authorization plug-in ins componernts for communicating data with a corresponding client autimrization plug-in stored on a client computing device I I0. 1n a similar manner, each client computing device 110 ir~ludes ono or more client authorization plug-ins that identifies the target _ groups to which the client belongs In an illustrative.. anbodiment of the present ikon, the client authorization plug-ins can be installed in each client computing device during the insrtallation or upgrade of a software application, such as the installation yr upgrade of as operating system. Additionally, the server authorization plug-ins may be dynamically installed or reanoved by an administrator desiring to comroi the access to software updates. The authorization plug-ins storod on the client computing device 1 I0 i~2liPCf and the az~tho~tiOa sever 122 Can be as acta~al soflwan plug-in, Or the authorization plug ins can be hard coded into dynamically linkad libraries.
As shown in FIGURE 8, tla~ authorization server 122 contains three example server authorization plug-ins: (1) a first server authorization plug-in 828 defining a target group that includas all computers (haeiaefta~ the "All Computers target group"); (2} a second server autiwzi~ion plugin 829 defining a target group that inchuies computers having a valid P1D (hereinafter the "P1D target 8roup'~> and (3) a third server authorization plug-in 830 def ning a target group that inchules beta test computers (hereinafter the "beta ,target group'. Also shovva is FIGURE 8, the client comptrtia~g device I i 0 contains two client authorization plug-ins: (1} a first client authorization plug-in 825 indicating that the client comparing device I 10 is a member of the All Computers target group; and (2) a second client authorization plug-in 826 indicating that the client computing devicx 110 is a member of the P1D target group. In this example, the client computing device 110 does not contain as autborization plug-in indicating that it is a member of the beta target group. As will be appreciatod by those of oniinary skill in the art, each client soon plug-in 825 and 826 may be configm~d to execute one or more functions on the client computing device I 10 to assist the validation process. Fox instance, the sacond .client aeon plug-is 826 may be configured to examine the memory of the client computing device 110 to verify or obtain a P>D for an installed softvvare appliartion.
As shown is FIGURE 8, the authorization sub-routine 702 begins when the cheat computing device 110 conu~nic~Les a configuration request 803 to the autho3rizatioa server 122. In an illustrative embodiment of the present invention, the configuration request 803 is formed from any suitable software component configured to obtann information describing the authorization phig ins storal on the suthorizatioa server 122.
As will be appreciated by those skilled in the art, the configuration request 803 may utrhze 8 known method referred t0 as "GetConfig." In response t0 receiving the configuration request 803, the authorization server 122 communicates a configuration response 804, which includes iafannation identifying all of the authorization plug-ins stared on the auction server 122. In one embodiment, the configuration response 804 includes an axray of strings that idearifies and descn'bes all aathorizatioa ping-i~ stared on the authorization server 122. In the present example, the configuration response 804 includes information that identifies the first server authorization ..
plug-in 828, the second seawcr authorization plug-in 829, and the third saves autharixstion plug-in 830:
At block 805, the client computing device I 10 g~erat~ one or more authorization cookies in response to receiving the configuration response 804.
In the prods of block 805, tht client computing devicx 110 gan authorizebon cookie for each pair of mrsLc~iag client and server auton plug-ins. Thus, in the preset example, the first client autbozizntion plug-in 825 geoaata a first authorization coolie associated with the All Computers target group bcxausc the first chart authorization phrg-in 825 and the first server authorizzatton plug-in 828 are both associated with the All Computers target group~ In addition, tire second client authorizanion plug-in genaatcs a second authorization Gnokic sssociabed. vrith the PID target group because the second client aut>rorizatian plug-in 826 and tire second server authorization plug-in 829 era both associated with the PID target group. A third authorizatibn cookie is not gene~ed since the client computing devicx 110 does not have an authorization plug-is indicating that it is a member of tlm bola target group.
As will also be appreciated by those skilled in the art, one implementation of the pmces$ of block 805 may include the use of a gareraliy known software method reftrnd to is the art as "GetAuthCookie." It will also be appreciated that the generation of each aeithorizanon coolie may involve additional processing. For instance, the second client authorization plug in 826 may be coa~f gm~ad to exa~niae infornnation stared in the chart's system registry to retrieve a P1D and include the PiD in tho authorization cookie. In other examples, the proxss of block 805 may include for communicating with other computers or devices. Far 'rostance, a client arrthorization plug in may communicate with a device, such as a sound card, scanner, video card, etc., to obtain the make and model of the device. In other non limiting examples, a client authorization plug in may communicate with a secumity device, such as a fingerprint reader, to obtain information describing a user.
In general, a cheat autlwrization plugin may read configuration ion from any anent of the client computing device 110 or any otla'r computing device communiartively comnx~d to the client compuEing device 110. In other examples, a chart authorization plug-in may be cod to utilize one or more public or private application programming int~fsc~s (APIs) to gatl~ and encxypt information from the client that will be validated by the aarnspoadiag server plug in. 1a such examples, PID

a 1327iPCf' validatar plug is $26 uses a private API to eoaypt the client's PID to peas the m P1D m the servo far dccxyption end validation. 1a other embodiments, othta client authorization plug-ins may utiliaa biometric moasurcments, such as fingerprint readers or voice prints, to consbnux as authoookic to be passed to tbc far validation.
S Ia yet another example, a ciiatt aeon plug-in may call a Web service or any other service to communicate autl~rization c~tials or any other type of data to the suth~oeization servo 122.
In an ilh~strative embodiment of t6~e prea~t ikon, each authorization cookie includes a string that ider~tifiea an associataa target gtmtp. For atample, a string may indicate that a particulaur iron cookie is associated with the PID target group.
Each autta'rizatioa cookie also includes a dais section for communicating data bcriveen a client and a server. For example, sa authorization cookie associated with the PID target group may have a data section that contain ea acd~al P1D. As will by ~ by those of ordinary skill in the art, the data suction a~n contain any type of data that is stored in any format, such as a byte array. For example, if plug-ins on the client and the server require the oommimication of public and keys, sucdi data cam be in the data section of one or more authorizstioa cookies.
Once tba elieat computing devicx 110 gan authorization cookie for each pair of ~aponding client and server authanizabon plugans, the ctimt eomputmg devise communicates the generated aeon cookies to the authorization server 122.
As shown in FIQrURE 8, the client rung device 110 comma the authorization cookies in a cookie regnant 806. The cookie request 806 includes any suitable fomaat for a~mmunicating an array of the aeon cookies gin the procxss of block 805. One implema~ion of this part of the suthoriz~iwn method 702 may include the use of a generally lmown soRwaxre method refen~d to in the art as "GetCookie."
In one embodiment, the cookie request 806 also includes other authorization saver oooldes stored in the memory of the client compiroting device 110. As will become more readily undersLavd fmm the following desaiption, the memory of the client computing device I10 may story old autbarization server cookies that were ard~tod in previous cxecurions of the authorization routine 700. By providing the stored authox~on server cookies in the cookie request 80G, the client computing device 110 will be able to maintain its access privileges that were granted in the previous executlvns of the authorization sub-routine 702. In tl~ print example, since thane era no av#hori~tiOn server cookica stored is the cliemt, the COOkiC 806 incltrd~es tine first 81~1~t10~ COOkle aSIOCwith the ~ talgCt grOtip ~ the SCCOnd airtltorization cookie aasociabed with the Pm target group.
Next, as shown in block 807, in zespoase to raxiving the cookie request 806, the aut>mtization server I2Z ga server cookie. In one embodiment, for each of the recaved suthat~i~ caolaes, a call is made to an ~e server authorization plug in to generate aava oootcie data, The serve ~e data gby each server authorization plug-is includes an identifier for each target group identified in the received aut~wrizetion cookies. In the present ex$mplo, since the cookie reqveat 806 includes the x 0 first autham cvolae associated with the All C,onnpufias target group and the so~ad authorizaxion cookie associated with the P1D target group, the autboz~on server 122 gds server cookie data containing an identifier for these respective target groups.
On the aartb~arization server 122, tip server cookie data is than combined with data of old cookies, if an old server cookie is received in the cookie z806, to ga new server cookie. In one embodiment, the new server cookie is encrypted by the use of a publicalty available encryption method, such as Triple DES.
In an illustrative embodiment of the peasant invention, the server cAOkie can include ~xypted ion that ione ar mama atargd gron~. In addition, the server cookie can include expiration data, which is stoxed in both a clear text format and an fonaat. The eon data stored in the clear text format is used by the client oomputrng device I I O for maait~ring frn the cxpir~ioa of the server cookie. The expi~ion data stared is ~e encrypted format is used by soavuare update servicx 120 to determine if the client computing device 110 is authorized to receive updatrs associated with a particular target gmup. In one embodiment, the expiration data of the saver cookie applies to all target groups in the server cookie.
Aheananvely, or in a~iriOn to the acpii~on tip that applies to t~ ~er~ server cookie, the server cookie may include a plurality of expiration data, each of which may apply to individual target groups. As~.will be appreciated by those of ordinary skill in the art, each server cookie can iaclmte additional data. For iasranx, a server cockle may be configured to store client state ion, such as a time stamp of the last execution of the authorization sub~~outine 702.
Once g, the anthoriz~on server cookie 809 is con~unicated from the aeon server 122 to the cliark cam~ag device 110. Next, as shown in 23278M.?
block 811, the server cookie is then stored in the memory of the chant computing device 110. OVhen the client computing devicx 110 detetmanes that at least one component of the server cookie bas acpirad, the client computing device can re-eacscuta the authosi~tion method 702 to obtain a new s~ cookie. As mentioned above, in S each ~t execution of the authorization method 702, the client computing devicx 110 may oommurucato its stored server cookies to the authorization server 122 in the cookie rcquc~t 806. In one embodiment, the clie~tt does not have to send the request 803 unless the server informs the client that the server configuration has changed, i.e., a new authorization plug-in bas been addod.
In accordance with snothar aspect of the presant invartian, the soRvvaxe update service 120 may pmvide a syncbzonization sub-roudine for synchronizing update information bdv~en the meradata scrvtr 123 sad the client computing device 110. By the use of a unique soflvvare update hierarchy, the synchronization sub-routine can e~cier~tIy identify specific updates that apply to a particular ciie~
computing devicx. 1n addition, by the use of the server cookie genen~ in the authorization sub-routine 702, the synchronization sub-routine can selectively grant access to updates associated with o ~~ 8~~~
In accordance with an illustrative embodi~mtnt of the present invention, each soifiware update includes three components: {l.) an insdruction campone~ (2) a localized, daxa compon~ and (3) a data component. As will be appreciated by ono of ordinary skill in the ant, each update may have ono ar mare of the abovc~descn'lxd components.
For rac$mpte, an update rnay contain an instruction component, a localized data component, and a data stmam component. la saofiher example, an update may only contain an instruction compon~ for testing one or more conditions of a client computing device. The various components of the software updates are descn'bed in mare detail below.
Generally descn'bed, the instruction component contains two sub-components:
(1) an applicability rule that defines one ar more conditions to be tested by a client computing device 1l~ and (Z) a set of prerequisites that identifies one or more updates that art required for proper installation of an individual update. As described below, the applicability rule can define a number of conditions a computer, and each of the conditions can be associated with other conditions by the use of any logical operators.
For example, the instruction component may include as applicability rule to detcrnnine if 23271YCf a computer has a particular version of Wmdowsm installed. As also described below, the sat of prerequisites can idartify one or more updates that arc required to have been previously installed. For example, as desaibod in more detail below with ~ to FIGURE 9, as individual update may contain a prerequisite that lists other updates rfor the proper installation of the individual updats. In other examples, ss is also shown in FIGURE 9, the set of prerequisites can include the use of logical operators to d~fmc more complex pra~quisites ivlas.
The instrucflon component also gains code, such as a Boolean flag, that indicates if there are othesr updexes that depend from a particular update.
For illustrative l0 purposes, an update is considered to be a LEAF update if ~ are no other updates that depend from a partiailar update. The Boolean flag that is need to indicate if an update is a LEAF is dynamically updated by the metedata server 123 as relatexi updates are addexl or rrmovexl.
The loeatized data component of each update includes general information describing the updax. For instancx, the localized data componeazt may i~lude information deaan'bing the fend benefits of tin updats. The 1~ data compone=nt may also include a tenet description of the instaIIatJion procxdures of the u~te. In addition, the localized data componcrit may include say other data or information re=lated to the update. Far instance:, the; localized data may indicate that an update is a high priority update. Ia another example, the localized data may lurovide special ion messages, such as a mt~sage that indicates that an update cannot be installed with other software upd~s. The localized infoanation may be in a format that allows for the display of its contained informatiion to a user.
The data component of cacti, update includes one or more binary data streams of the . In ane eanbodi~nt, the dare component of each update may be associated with o~ or more data files, such as an wcecutabk file, a document, a linked li'bra~y, e~tc.
As dacabed is move de=tail below, each update may be associaGad with a combination of data files, each of whieb facilitates the aduat upgrade, installation, or modification of software used by the clieztt. For instance, the ion of sa update may lx facilitated by tlx use of a single CAB file including all tin information r~ire~ to complete a selexted update. Alternatively, the installation of the update may be facilitated by use of a number of individual used to update one or more files stored oa a client computizeg device.

In as Olustrativr e~nbodimeat of the pre~t invention, soflwarc updates c~a be azraaged in a hierarchy that allows for controlled distribution of the soflvvare updates.
G~erally dasaibed, the hierarchy of updates defines relationships bavveen the updates and specifically indicates which ~ are d4pcn~ant oa other updates. For illustrative purposes, an example set of updates is provided and shown in FIGURE 9. As shown, a hi~rchy of sample updates 900 includes a base set of updates 901, a second set of updates 902, and a third set of updates 903. Ia general, each update in the base set of updates 901 does not have a praeroquisito that requiz~ the installation of other updates.
However, the sixth updates 921 contains a prerequisite that reqiaras the installation of the first update 911, the second update 912, and the third update 913. The seventh .
update 922 contains a prerequisite that requires the instalta~ion of the fourth update 914.
The eighth update 93I contains a ~ that requires the installation of the sixth update 921 and the fifth update 915. Hence, the eighth update 931 also requires the installation of the first update 911, the second update 912, and the third update 913. For purposes of illustrating the pze$ent invention, it is ;given that all of the updates of the sample set of u~pdatcs 900 are all associated with the All Computers target group and the PID target group.
Also shown in FIGURE 9, end as described is more deta~ below, each update caatains an applicability rule that spxifios conditions for the installation of the update.
For example, the first update 911 requires the installation of an English version of an oper~ng system. The second updates 912 rthe installation of Windowsm XP
version SP1. In another example, the sixth updaxe 921 the insrgllation of a sof3wmz patch rcfe~d to as the XP PATCH1. Accordingly, the client computing devix 110 will not install the updatGS if tlae applicability rules lava not been satisfied.
FIGURE 9 also shows the section of the fan compon~t that indicates if there are other updates that depend fmnn a particular update. This section is referred to as a LEAF, which may lre in the form of a Boolean value.iadicating that a software update is the last update of a series of related updatGS. For purposes of illustc~ing the invention, a particular update is a LEAF update if no other updates list that particular update as a prerequisite. As shown in FIGURE 9, the update 922 and the eighth update 931 are the only two LEAF updates.
FIGURE 10 ilIush~s a protocol diagram of a synchronization sub-mutiny 704 (FIGURE ~ formed in accordance with the pnes~t invention. Generally described, the _2,3_ synchronization sub-route 704 selectively communicates the instruction components of certain between the cfiert oomputiag device 110 and a servo, such as the metadata server 123, to idartify upda>n$ that can be applied to tile client computing device 110. As shown in FIGURE 10, to initiate an update, the client computing device l I0 fast pray installed updates and communicates a synchronization request 1051 to the metadata sa vet 123 requesting onn or more updates available to the client. Tn response to nxeiving the synchronization request 1051, the metadata server 123 retinas a numbex of updst~ to the client computing device 110. As will be more readily understood from the following description, the client computing device 110 processes locally-stored data ~ for to the communication of the synchronization request 1051.
The client computing device I10 pzoc~es the ins6n~ction components of each received update to determine if the condition defined in the applicab0ity rules can be met.
If the condition defined in an individual update is met, for purposes of illustrating the synchronization sub-routino 1050, flee individual update is "installed," and the installed update is saved in a E~rst component of the client's update cache. On the other hand, if the condition defined in an individual update is not mot, individual update is considered to be "failod," and the failed update is saved in a seornnd compone~ of the client's update cache. In this de~ription of the synchroniz&tiaa sub-routine 1050, if an update is installed it can lx that the prerequisites and tl~ c~aditions of the applicability rules have been met Installation of an update for purposes of describing this sub-matins does not necessarily mean that the data files associated with the update arc actually installed in the client compatxng device 110.
In one embodiment; the two eomponents of the chart's update cache can be used to categoric flu receivod c~da~.a. The first component is used for storing installed, non-LEAF upd; and a second component is used for storing all other updates received by the client, i.e., the uthat were not installed. The second component of the update cache also includes the storage of all LEAF updates. As des~'bed in more detail below, updates stored in the update cache can be communicated to and proved by the metads~ server 123 to identify other related upda#es that are available for ion on the client compuxing device 110.
Returning now to FIGURE 10, details of the synchronization request, which are illustrated es items 1051,1055, and 1060, will now lx described. As will be appre~ded 2327~GT
by those of ordinary skill in the art, the synchronization request may be initiated by one of a number of different devices, processes, applications, user-init;etod commands, reqtuatiag as update. The syachrnnization request may be initiated by a user mquesting a list of updates, an automatic update initiated by the client agent, or any other software component requesting information from the ~ server 123 ar the update service 120. In one embodiment, the synchronization request inclu~s an authorization server cookie, such as the auflmtization cookie generated from the authorization routine 702. The use of the server c~olde allows the server to de~te~mina if the client is a member of one or more target groups.
Each synchronization request may also inclu~ id~fiers for each update stored is the client's update cache. More specifically, if one or more updates are seared in the update cache, the synchronizanioa req~ust includes a first component having identifiers for installed, non-LEAF updates; and s second compo~at having identifiers for all other u~pda~, such as LEAF updates, failed updates, and other updates that are not installed.
The update identifiers may be in nay format including, but not limited to, an array of integers. Altemarivcly, if there are no stoned in the client's updates cache, the synchronization request is not configured with an update id~ifier. When a syncbroaization request is nest oonfigiuod with an updates identifier, the synchronization request provides as indic~tioa that the clicrn computing device 110 does not have any cached updates.
As shown in FIf~URE 10, a first synchronization request 1051 is communicated from the client computing device 110 to the metadata saver I23. In the present exempla, the client's update cache will not contain any updates, given that this is the first cxacudon of the method Thus, the first syachroni~ioa request 1051 does not contain an idernifier 2S for a cached update. 1n response to receiving a synchronization request, as shown in block 1052, the mctadata server 123 dcteimines if the synchconizalion request contains at least one update identifier. If it is determined that the synchronization request does not include an update identifier, the matadata server 123 responds by selecting first level updates for communication to the client computing device 110. As described above, first level updates may include any updates that do zmt have a prerequisite identifying other Atte~natively, if it is determined that a synchronizafion request contains at least one update identifier, the metadata x123 examines the pn,~tquisites of the server's StOrCd updat'IC.S t0 &CICCt 8dd1t10~ ltpdateS faT dCllVeIy t0 the Client. In One embOdimCnt, the metsdeta server I23 selects updates having fulfilled prerequisites. In the examination of the prerequisites, the server uses the updaroas of the first component of the synchmaization reqwest, which includes identif era of the ran-LEAF updates that are installed on the client.
In addition to selecting updates having fulfilled perquisites, the server also uses the updates identified in the second component of the synchronization request to filter the selected upde~tes. Mvre specifically, uainst~led updates, LEAF updates and failed identified in the second component of the synchronization request are used to filter one or more selected updates. This feature of the present invention allows the system and method of the present invetttiion. to avoid multiple transmissions of updates stored on flit metadata server 123.
Retauning to the pre~t example, since the fast syncbmnization request 1051 does not include an update identifier, the metadata servex 123 selects the base level of updates 901 for communication to the client computing device 1 I 0. With reference to the sample set of uepdafes shown in FICitJItE 9, the base level of updates 901 includes the updates refs as 911, 912, 913, 914, and 915.
In the processing of block 1052, the meradata servat 123 also examines the autharizatian server cookie contained is the synon xeque~t 1051 to identify the ZO target groups that are assowith the chart computing device I 10. The metadata server 123 also examines the target groups of the updates selected in the praass of block 1052. The process of block 1052 then .filters vat all selected updates that are not associated with a target group identified in tl~ received authorization server cookie. In the presort example, since all of tl~ sela~ed updates 911, 912, 913, 914, and 915 are associated with the P~7 and Alt Computer target groips, all of the selected, updates are sent to the client camputtng device 110.
The metadata server 123 . then communicates the selected updates in a synchronization response 1453 to the client computing device 110. In general, each sy»chmnization response includes the instruction canaponent of each update sent by the server 120. Thus, in the present example, the first synchronization response includes the a~cdon componextts for the updates referenced as 911, 912, 913, 9I4, and 915. In one embodiment, each synchronization response does not includt the localized data componart err the data component of each update.

Nmct, as shown in block 1054, the client computing device I 10 process the instruction components of each received update to determine if the condition defined in the applicability rubs can be met. With again to FIGURE 9, the client computing device l I0 processes the inst<vdion components of the roceived updates 911-915. For pcnpoacs of illnshradng the present iavex~tion, it is given is this example that the operating system of the client computing device 1 i0 is au English installation of Windowsm version XP SP 1. It is also given that the client computing device 110 is a Dell PC and is running a 32-bit, X86 proxssor. Thus, in the processing of the instruction components of the sample set of update, the client computing device 110 would detezmine that the cxlndztian dn&nod in the first update 91 I
would be neat bcce the canzputcr c~ias an Epglish.OS. The condition defined in the second update 912 would be met bocause the opa~ing system is Windowsm version XP
SI'i.
The condition defined is the third update 913 would be met because the client computing device 110 is rvaning an X86 processor. Tlbe condition defined is the fifth update 9I5 would be met because the client computing device 110 is a Dell PC. As a result, the fast update 911, second update 912, third t~pdaie 913, and fifth update 915 are all save in the fast component of the client's update cache. The condition defintd is the fourth update 914 would sot be met ba~use the client computing device 110 is not nmning a 64-bit X86 processor. Thus, the fourth update 914 is considered to be a failed update and saved in the second component of the client's update c~c~he, Returning to FIGURE 10, in the processing of block 1054, the client computing davicx 110 also determines if a subs~oquaat synchronization request is required. Ice one embodiment, it is de~min~~d that a subsequent syachmnizatton request is required if at least one of the received t~pdat~ indicates that it is not a LEAF update. In the present example it is determined that a ~ syncbannization request is r~irad bc~ause all of the received updates are not LEAF updatGS. Thus, the client computing device 110 communicate a subsequent synchronization reQ~ 1055 to the metadata server 123.
As summari. ed above, a synchronization request includes id~tificrs for each update stored in the client's update cache. Thus, in the pre~nt example, the subsequent synchmni~ion raluest 855 includes a fast data camponcat iadicatrng that the first update 7I 1, second update 712, third update 713, a~ad fifth update 7I5 are installed on the cliem. In addition, the subs s3mcluanizatioa request 855 i~ludes a second dais compo~ut indicating that the fourth update 711 is not successfully installed on the clienx.

Zi27tPG'1' In response to receiving the subs synchronization r~u~t 1055, as summarized above, the metadata server 123 determines if tha Subsequent synChroni~i0a request 1055 contains at least o~ update identifies. If it is debetmined that subsequent syachranization request contains at least one update identifier, the raetadsta server 123 examines the prenequisi#es of ell stored updates to select additional updates for delivery to the client With refc,Kence again to the present example, in the priag of block 856, the I
m~ta server 123 would select the sixth update 921 because its prerequisites arc met.
More specifically, as shown in FIGURE 9, the sixth update 92I is selected far commuaicatian to flaw cliemt computing devicx 110 ba~use its pnnahusite, which requires installation of tip first update 7I 1, second update 9I2, and third update 913, is fulfilled. The seventh update 922 and eighth update 931 would not be selecxed for vommuaicatioa to the client bzeausc their praoquisites are not fulfilled. More specifically, the synchma~tioa request 1055 did not contain as identifier for the frnath update 914, which is a prerequisite for the seventh update 922. In addition, the synchm~nization request 855 did not contain an identifier for the sixth update 92I, which is a prerequisite for the eighth update 931.
Rcha~nin~g to FIGURE 10, the synchtvnizetion sub-znutine 1050 continues by commuaic~lin$ the selected updates is a Subsequent response 1057 from the metadata saver 123 to the client Wing device 110. With reference again to the paes~t eiuunple, the subsequent response 1057 would include information related to the sixth update 72I, is c~ommto the alieflt 110 in a subsequent response 1057.
Upon receiving the Subsequent response 1057, the client computing davice 110 proves the instruction components of the subs~rt 857. Similar to the pmc~s of block 854, the client coming device 110 ~ the instruction componeat9 of each received update to determine if the condition define in the applicability rules is met. In the pz'es~t example, if it is given that the XP
PATCHl is installed in the client cxnmputjng device, the sixth update 92 i is considered to be installed sad the update is written to the update cache of tl~ client computing device 110. Since the sixth update 921 is not a LEAF update, the client computing device 110 sends another synchronization roqtnest 1060 that includes all of the updates stared in the first and second component of the client's update cache. The synchronization request 1060 also includes the authorization server caolde.
~28~

la the print example, by use of the above-descn'bed processing of the metadata server 123, the syachroaizahan request 1060 is pat block 1061 where the server selects the eighth 731 update. The eighth 93I update is selected because the synchronizatiaa request 1060 indicates that the fifth and the sixth updates 915 arxl 921 are installed in the client computing device 110. Given that the eighth update 931 is associated with the same groups identif ed in the authorization server cookie, the instruction component of the eighth update 931 is communicated to the client computing device 110 in another xeaponse 1062. The eighth update 931 is than processed in block 1063 in a manner similar to the process of blocks 1054 and 1059. Since all of the received updates of the response I062 are LEAF updates, a subsequent synchmnizatioa rat is not sent back to the metsdaxa server 123.
At the client computing device 110, after it is determined that all of the rexived updates are LEAF updates, or if no updates are rxeived in the response 1062, the synchronization sub-routine 1050 communicates a driver synchronization request from the client computing device I 10 to the metadata server 123. As will be apprxiated by one of asdinazy skill is the art, the driver syachmnizatton request 1064 may include information describing all of the hardware installed in the client computing device 110 and information describing the installed software. Similar to the prior software synchronization requests (1051,1055 and f060), the. driver synchronisation request 1064 may communicate the installed updates to the server. In addition, all of the driver updates cwre~tly c~chOd on the client, if any, era communicated to the server.
In response to receiving the driver synchronization request 1064, the mdadata server 123 responds by sending aU of the driver updates that apply to the client Wing device 1 I O that era not ah~eady cac~d on the client. A driver update is sent to the client computing device 110 is a response 1065 if its prerequisites and conditions are met. The response 1065 commuai~ting the driver updates preferably communicates the instruction c~nnponent of each update. The driver updates are than written.to the update cache of the client coming device.
After the receiving the response 1065 cantai~ing the driver upda#es, the synchronization sub-routine 1050 scads a request 1066 for the laCalizsd data of each of the rrceived software sad hardware updates. As slammarized above, tl~
localized data component of each update includes general information descn'bing the update.
For ire, the laca3ized data component may include information dexcn'bing the fees " ...
and b~ Of the update. The loaali~ed data may also include a text des~iption of the installation p~oafiu~ea of the update. In addition, the localized data.
oannpoooaat may include any ot3~a data or iafnnmation rte the update.
Thus, upon receiving request 1066 for the localized data of each of the received updates and hardware t~pdatas, the metadata server 123 responds by sending all of the localized data for ali of the received soRwate updates and hardware saved in the npdatie of the client, Once received, flu Localized data can be pa~oassad by a softvva~re application to ~tetminc which of the updates needs to be installed.
Alternatively, 'the received localized data can be displayed to a user to inform the uses of all updates that are available to the client coaaputing device 110. In one exabodiment, the roceirerl localized data can be displayed on a Web page. Ia the present example, localized data may be raxived by the client for tht sixth and eighth updates 921 sad 931.
if localized data is stored in the base updates 911, 912, 913 and 915, tla;
localized data for those update would also be received by the client.
FIGURE 11 ~ one example of a web page I 140 displaying an example of localized data associated with. the updates that are available to the client.
For illustrative pmpoaes, the web page 1100 comprises a first deteRod de'saiption 1105 of an update and a second detailed description 1106 of another update. Also shown, each update is raspa~ively associat4d with sdedion mechanisms 1103 and 1104 for receiving a user zo selection of the updates. Also shown, she web page 1 I o0 is canfigurcd with a control button I I OI for allowing a user to control the communic~tian of the selection of to a server, such as the metadata server 123 or download server I24.
In one aspect of the present invention, ~e client pmforms a mbar of processes to enhance the display of the Web page 1100. For instance, the client caging device 110 acamines 13~a localized data of each update to dex~~ if a particular update is of high priority. Such a feature can be facilitated by locating text in the localized data, or in other oompona~t of a pmticutar update, that indicates thax the patticul8r update i~ a high Priority or emergency update. If the client comptrting d~.wice 110 detects a high P~~'8~y~~~~~.a visible section of the web page 1100, stxrh as the top section of the page. In addition, the client may gate a visual indicator, such as a sp~slized ttxt message 1 I20, indicadag that the update is a high priority update.

The client computing aevice I I o may also acamine aye localized seta of each t~pdato to ddermiiu if a pmiicxilar update ran exclusive ion, ieh an upd~e having as installation file that ca~ot be simultaneously installed with an installation file of another update. Such a fcan be facilitated by locating text in the localized data, or in ether comcponeat of a penticular update, that indicattes that the parricnlar update reqaires am exclusive inatallatian. If the client computing device 110 debocta such an update, the client displays a visual indicator, such as the text message I I2Z
shown is FIGURE 11, with the description of the updates that require an exclusive insmllaaioa Re4uming to FIGURE 7, the Software update mu#» 700 crnxtimxs at block 708 where the client cod devicx 110 receives a selection of the updams. As noted above, in response to actuation of the eontml button 1101, the solection of the ono or more updade~s can be obtainai by the m~data saver 123 or the download server i24.
Once the selection of one or more update is raxived tta~ soflvvere update r~dne 700 oonat block 708 where the selected soflrovare upas~ are prod.
In accordsaee wish st'sll another aspect of the present invention, the software update service 120 may ~ovide a method for selecting and transmitting information betvu~ the software update , service and the client armpntimg aeviae 110.
FIGURES 12A and 12B arc illusaativc of a aoflvvara update ptoeessing sub-routine 1200 implemented by tlu cheat computing device 110 to retrieve and install requested soflivare in accordsmx with the present invention. As descn'bed above, the soflvvart update ping sub-routine 1200 may be implonce a xle~on of software has been g~erated or received. With refe~ce to FIGURE 12A, at block 1202, the update maa~componaot i l l instaatiaixs an u~pdade agent 118. In an illustrative embodiment of the present invention, the update agent I 18 is a speciaIizad software 23 oornponent for dxtem~ng what soflvvare update in8rnis required to completed a requested soilwaxe update, to gesurate a required version of an in~alladon component of the update agent, to generate updated f~les by merging existing files with delta patches, .
andlor to initiate the installation of files. In the ev~t that an update agent 118 is alieady instanbat~od, block 1202 may be omitted.
At block 1204, tire update agent 118 obtains soRv~O update information frame the update service 120. In an illustrative embodiment of the prat invention, the software update iafonrration transmitted by the update service I20 is in the form of a package, such ass a self-cxtradiag file, that iacluaes a varidy of data that may be trtiliud by the (r update agent. 1a one aspen, the package can include a list Of all the files that corireaponul to a soRware update. Additionally, the package c~ include copy of ax least a portion of the patch storage manifest that maps specific varaions of files to be to a connsponding software update delta patch stored in the patch storage file oa the update 5 service 120. 'Ibe paokag~e aan also include i,~alladon infonmatiom for each Sle to be that can include an idcmafic~tion of a version of an installation component required to complete tlx installation. Fm~t>~er, the package c~a also include an installation con~onent for the update agent 1 I 8 or a delta patch to update a version of an installation cod ah~eady stored on the client compuda~g device 110. Still fvrthcr, the package can include vai~ation information to allow the update agent to dcbaminc whether a software update was succxssfut. For example, the verificaxion information can include ro~ranae hash values for updated files for oomparisen. The update agept 118 may also veri$r the contents of .
At decision block 1205, a test is condudad to determine whether the update IS agraAt 118 needs to update a version of the installation eompon~ to implement the update. One skilled in the relevant art will ~ that the ion of a complete copy of an inflation in the self-e~etcsc~g file c~a increase the amount of data treasnnitted. by the update service 120 for each so$ware update.
Accordingly, in an illustrative cmbodirnent of the present invention, a baseline version of as installation component may be stared is the client oompuang device and updatal spocitically for the inquiren~eats of the currant software update by way of as installation component delta path. Accordingly, the installation information in the self-fag file ins~ucts the update agent 118 whether or not say included instillation cod updates need to be with the baseline version of the installation component on the client computing device 110. If an update is rr~quired, at block 1208; the update agent 118 updates tlx baseline insteilaixon component, as will be explained in greater detail below with regard to FIGURE 13. .
Once the update agent the installation component or if the instavation component does not require as update, at block 1210, the update agent 1 I8 perfontLS an inventory of files installed aai the client computing devicx 110 sad the specific version of the 51e. In an illustrative embodiment of the pms~t invention, the update agent 118 may quay the client c~mputiag device 110 file system for all files identified in the pac~gt as corresponding to the selected update. AIvely, if the update agent 1 I8 has r~ece~ly coned an inventory, a caches version of the iavoatory may be utilized. At block 1212, the update agent 118 idemifies what soflyvare update information is requirod to complete the requested update. In an iilustradve embodiment of the present invention, the patch storage manifert includes a mapping of versions of sa installed file to a required s delta patch. Accordingly, if delta patching is available, the update agent 118 will utilize the mapping to identify a particular delta patch and its offset location within the patch storage file. Alternatively, if delta patch is not available or cannot implemented, the update aged 118 may identify an file for download.
With rcfnow to FIGURE 12B, at block 1214, tile updaxe date agent transmits a request for the identified software update information. In an illustrative embodiment of the present invention, the update agent 118 can transmit a request for specific delta patchas by indicating a specific range of patches required from the patch storage file to the download server 124 of the update service 120. As descxibcd above, the patch storage file includes a large of nimnber of applicable delta patches, in which 1 s each delta patch is identified by its location with the patch storage file. Because the patch storage file may be rather large in some implementations, the update agent 118 c~a utilize a request that only rfor data fmm~ specific locations in the patch storage file as indicated ~rom the patch storage manifest. In an alternate eazbodimeat of the p inve~ion, the update agent 118 may t,t sa entire copy of as update file and/or a complete copy of the patch ston3ge file.
1a as altemaxe embodiment of the present im~tion, $rwther download server that may not be exclusively associated with the update service 120 can process the updaxe agent 118 rerluest In this embodiment, the request patch storage file may be transmiited, in whole or in part, to any number of additional download servers on a actwot~lc. The 2s additional download servers may be part of a private natwork u~dlizod to update clients on the private nerivork. Further, the additional download server may be part of public . network. In a private network arvironment, the download servers may obtain a complete .
copy of the patch storage file for processing client requests. Alten~atively, the download savers may also cache portions of the patch storage file in processing previous data requests from other clients and utilize the cache data to satisfy the download.
Accordingly, the additional download servers can reduee the communications strain on the download server 124 of the update service 120.

.:
At block 1216, the update agent 118 receives ttrc ~ update information.
In an illustrative embodiment of the present invention, the requested update i~'ormarion may be transmitted in two caches. In a first approach, ~ to as manuat update, the update request is scat to the update service 120 with a request for a direct HTT1' data S delivery response. In this approach, tlu update service 120 may utilize all of the entire bandwidth avajlable to transmit the tnqtuexted data to tine update ag~t 118.
In a second approach, rtferred to as as automatic update, the update request is sent to the update service 120 with a request for an indinrxt HTFP data delivery response. In this response, the update servicx I20 txaaosarits the requested data as a background pn~s.
The background process may be implemented is a manner to utilize a minimal amount of available bandwidth. Further, the background process may be intt~ru~d during the download proocss sad rested at the next available time. A description of a system and method for transmitting requatod data via a background process is described in commonly assigned and copeading U.S. Patent Application No. 09/505,735, e~itled 1 S System sad Method for Traasfearing Data Over a Network, and filed on February 16, 2000, which is hereby incorporated by reference. One skilled in the relevant art will appreciate that foregretnnd or backg~r~ound data delivery is not necessarily reflective of a priority of the selected software update, tux rather how bandwidth is allocated to obtain tbc update info:Tnation.
Oncx the requested in formation is received from the update servicx, at block 1218, the update agent 118 ranges the delta patch with the corresponding installed files. In an illustrative embodiment of the present invention, the update agent 118 may cache the original version of the installed file to ~sia~e that the selected file does not change during the download and merging process. Further, tlu: original version of the i~talled file may be used to uninstall the selected update.
At decision block 1220, a tort is conducted to detcamine whether the updated file is valid. In an illustrative embodiment of the pFesart invention, the update agent 118 may utt'Iize a hashing algorithm to compare a reference hash value obtained from the update information package and coarsponding to a valid file update with a hash from the current modified file. if the hashes do not match, the currant modified file is not valid. One skilled in. the relevant art will appreciate that say one of a number of alternative validation algorithms may also be utilized. If the updated file is not valid, the sub-routine 1200 rvfinns to block 1214, where the update agent may request the update 2327iP(.T ~ . ( .
information again. Altemadvely, if the update agent 118 has unsuccessfully ~onptod to i I
gene~tc the update file several times, the update agerrt may iatplemeat one of several fallback proc~urs. In one embodiment of the present invention, the update agent 118 may request a completed copy of the file stored. in the patch storage file and identified from the patch storage manifest fmm the update service 120. In another embodiment of the prat invention, the updats agent 118 may request a copy of the updated file in a self-crontainad file from tIu update servicx 120. In still another embodiment of the prat invention, the sub-routine 1200 may otherwise fail.
Once the selected file is valid, at decision block 1222, a test is cod to dek~mint whether any additional downloads are required. In an illustra#ive embodiment of tire prcs~~ invention, the sub-routine 1200 arters into an iterative loop that continuously checks for additional downloads after the completion of a previously sal«~ed download. ff the state of a file changes during the download, the update agent 118 would conctinue to request additional downloads for the new change of state. If additional downloads are required, at black 1224, the update agent 118 performs another inventory and identifies alI applicable delta . The sub-routine 1200 then returns to block 1214.
Once all t~ requested update downloads are ca~rplcte, at decision block 1226, a test is coaduct~ to dcte<mine wh~tar the state of the client machine has changed. In an ilhrstrative ~nbodiment of the prr~ent invertion, time may elapse betvc~n the downloading and merging of update infam>~on and the actual installation of the updated frle. Accordingly, prior to instaiiing the updated file, the update agent determines wh~ha the clierif computing device state has cheaged. If t~ state has caged, the file update may not be valid and the update fails at block 1228. Alvely, if no state 25 change has occmted, the update agent 118 installs the uQdatcd file at block 1230 and the i i sub-mutine 1200 nclzuns at block 1232.
With reference now to FIGURE 13, a sub-routine 1300 implemarted by the cIirnt compu:ing device 110 for updating a baseline in~allation component corresponding to block 1208 (FIGURE 12A) will be descrr'bea. At decision block 1302, a test is conducted to dcGermine whether a new baseline installation ~On~cnt is iachrded in the #
self-rartracbng file transmitted to the update agent 118 from the update servicx 120. In an illustrative embodiment of the parsent invention, if the delta patches required to update the baseline installer era computable in size to the transmission of an updat~od installation COniponent, 8 nLWV bi9~C IZ~lIatLO~ Wl~il hC h8~~ltttii. ~f an UpdabOd instBilstiaun compv~,ent is iaciuded, at blocdc 1304, the update agent installs the updated baseline iastalL~ion ~mponeat as the xw ion component, A~dditioually, the acw inscallahon component may be saved in the cli~t eonnguting device 110 memory to serve as a baseline installer for additional updates. At block 1306, the sub-routine If an updated baseline installation component is mt included in the self-actra~ag file, at block 1308, the updadbe went 118 obtains s baseline insrat>gtion dolts patch from the self-attracting ftlc. In an ~lusdn~ive embodime~ of the present iavcntiou, the baseline ion component delta patch cocr~ds to aoflvvare code that can be merged with the baseline installation component to genaete an upd~d baseline iastallahon cod Accordi~y, at block 1310, the agent merges the basc~ine inatall~ion component ~lta patch with the baseline installa~toa camponern. At block 1312, the update agent 118 then designates the baseline installation component as the out ion oampon~t. In an iilu~rativ~e embodiment of tlu present iavartion, the updated inatallahon component will not be saved after the ins is Mete. In accordance with this embodiment, the update agent I 18 only maintains a limited number of baseline ins~llation components in the client computing device 110 any. Accordingly, the update agent gees a ~orary, upd~~
installation component at each installation. Because each client computing device 110 can only correspoa~d to a limited numbca of baseline ins~llation campon~s, the update savrcx 120 is only to fit a single baseline bnsre~on compone~ delta patch for each chart computing device. At block 1314, the sub-routine 1300 rednns.
QV>rile the preib~ embodimtnt of the invendon has: been illn;~trated and described, it will be appreciated that various changes can be made tlxsein without dtp~ting fmm dbe spirit and scope of the iuvartiom. For in~e, although the illustrative examples described Ixrein apply to softwarr mss, the scope of the preset.
invention includes othea uses btyond the distribution sad ~mmunication of information related to software updates. Accordingly, unless spectate subject mattier is expressly excluded in this disclos~ae, it is to be agpa~eciatod that the scope of the prat invention applies to distn'butioa and communication of any type of data, other than, or in addition to software updates.

Claims (25)

The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:

1. A method of communicating between a client computing device process and a server process, in a distributed processing system, the method comprising:
(a) issuing, by the client process, a synchronization request, wherein the synchronization request includes an identifier of an installed software update if the client computing device stores the installed software update;
(b) receiving by the server process, the synchronization request;
(c) selecting, by the server process, an additional software update if the synchronization request comprises as identifier of at least one software update, wherein the selection of the additional software update is dependent on the fulfillment of a prerequisite defined in the additional software update, wherein the prerequisite requires the synchronization request to include as identifier for at least one specific software update (d) selecting, by the server process, a first level software update having a null value as a prerequisite if it is determined that the synchronization request does not comprise as identifier of at least one software update;
(e) issuing, by the server process, an instruction component of the selected software update;
(f) receiving, by the client process, the instruction component of the selected software update; and (g) storing, by the client process, the instruction components of the selected software update in the client computing device as an installed software update if the client computing device contains at least one component that fulfills a condition of an applicability rule stored in the selected software update.

2. The method as recited in Claim 1, wherein the method further comprises, by the client process, repeating elements (a) - (g) if the instruction component of the selected software update provides an indication that there are additional software updates for processing by the client process.

3. The method as recited in Claim 1, wherein the method further comprise:

issuing, by the server process, a localized data component of the selected software update; and receiving, by the client process, the localized data component of the selected software update, wherein the client process invokes an application to generate a display of the localized data component of the software update on a display upon receiving the localized data component.

4. The method as recited in Claim 3, wherein the method further comprises:
receiving, by the client process, a command for invoking the communication of a data file associated with the selected software update; and issuing, by the client process, a command for communicating the data file associated with the selected software update;
receiving, by the server process, command for communicating the data file associated with the selected software update, and invoking an application to download the data file.

5. The method as recited in Claim 1, wherein the method further comprises:
integrating, by the client process, an identifier of the installed software update into the synchronization, request if a memory read by the client process stores the installed software update,

6. The method as recited in Claim 1, wherein the method further comprises:
storing, by the client process, the instruction components of the selected software update in the client device as a failed software update if the client process determines that at least one condition of an applicability rule stored in the selected software update is not fulfilled.

7. The method as recited in Claim 7, wherein the method further comprises:
integrating, by the client process, an identifier of the failed software update in the synchronization request;
restricting, by the server process, the issuance of the selected software update if the selected software update is related to the failed software update.

8. A method of communicating between a client computing device process and a server process, in a distributed processing system, the method comprising:

(a) issuing, by the client process, an authorization request, wherein the authorization request contains an identifier of a client authorization module associated with a target group;
(b) receiving, by the server process, the authorization request;
(c) issuing, by the server process, a server cookie identifying the target group if the server process detects the presence of a server software module associated with the target group;
(d) receiving, by the client process, the server cookie identifying the target group;
(e) issuing, by the client process, an update request for at least one software update, wherein the request contains the server cookie;
(f) receiving, by the server process, the update request;
(g) issuing, by the server process, a software update if the software update is associated with the target group identified in the server cookie;
and (h) receiving, by the client process, the software update if the software update is associated with the target group identified is the server cookie.

9. The method as recited in Claim 8, wherein the authorization request includes data of a previously stored server cookie, and wherein the server cookie issued by the server process includes the data the of the previously stored server cookie.

10. The method as recited in Claim 8, wherein it is determined that the client computing device is associated with a target group if a server authorization module in communication with the server process identifies the same target group associated with the client authorization module.

11. The method as recited in Claim 8, wherein the server cookie comprises an expiration time, wherein the method further comprises, by the server process, not issuing the software update if the expiration time of the server cookie has passed.

12. The method as recited in Claim 8, wherein the server cookie stores the expiration time in a clear text format and in an encrypted format, and wherein the server cookie contains encrypted data identifying at least one target group, wherein the method further comprises:

obtaining, by the client process, the expiration time from the server cookie, wherein the client process obtains the expiration time from the expiration time stored in the clear text format; and issuing, by the client process, the request for at least one software update, wherein the request includes the server cookie.

13. The method as recited is Claim 8, wherein issuing of the software update includes issuing as instruction component of the software update, and if the instruction component of the software update indicates that there are additional software updates, the method further comprises:
issuing, by the client process, a request for localized data;
receiving, by the server process, request for localized data;
issuing, by the server process, a localized data component of the software update;
receiving, by the client process, the localized data; and processing, by the client process, the localized data component for the selection of at least one update file.

14. A system for communicating and managing software updates, the system comprising:
(a) a first database storing a plurality of software updates, wherein an individual software update stored in the comprises:
(i) an instruction data field containing an applicability rule defining at least one condition, wherein the applicability rule can include a null value, wherein the instruction component contains a set of prerequisites that identify one or more software that are required for installation of the individual software update, and wherein the set of prerequisites can include a null value;
(ii) a localized data field containing text data describing general information related to the individual software update; and (iii) a data component that identifies at least one data stream file associated with the individual software update;
(b) as authorization server for authorizing access to software updates stored in the first database, wherein the authorization server issues a server cookie for allowing a client computing device to access to the individual software update if the client computing device contains an authorization module indicating that the client computing device is associated with a target group, wherein the server cookie contains an identifier for the target group, and wherein the server cookie is communicated to the client computing device for storage of the server cookie;
(c) a metadata server for providing updates to the client computing device, wherein a software update is communicated to the client computing device if the software update is associated with the target group, wherein the metadata server is communicatively coupled to said first database, and wherein the metadata server is operable to:
(i) obtain a synchronization request, wherein the synchronization request includes an identifier of an installed software update if the client computing device stores the installed software update, wherein the synchronization request includes the server cookie;
(ii) select an additional software update for communication to the client computing device if the synchronization request comprises an identifier of at least one installed software update, wherein the selection of the additional software update is dependent on the fulfillment of a prerequisite defined in the additional software update, wherein the prerequisite requires the synchronization request to include an identifier for at least one installed software update, wherein the additional software update is associated with the target group identified in the server cookie;
(iii) selected a first level software update for communication to the client computing device if the synchronization request does not comprise an identifier of at least one installed software update, wherein the first level software updates do not include a prerequisite;
(iv) communicate an instruction component of the selected software update to the client computing device for storage;
(v) obtain a request for localized data associated with the selected software update;
(vi) communicating localized data associated with the selected software update to the client computing device, wherein localized data allows the client computing device to generate a download request for receipt of a data component of the selected software update;

(d) a download server communicatively coupled to said first database, and the download server is operable to:
(i) obtain the download request from the client computing device, wherein the download request identifies the data component of the selected software update; and (ii) communicate the data component of the selected software update to the client computing device.

15. The system as recited in Claim 1, wherein the server cookie contains an identifier for the target group if a server authorization module identifies the target group.

16. The system as recited in Claim 1, wherein the server cookie comprises an expiration time, and wherein the metadata server is operable to:
determine if the expiration time of the server cookie has passed;
restrict the communication of the selected software update if it is determined that the expiration time of the server cookie has passed.

17. The system as recited in Claim 1, wherein the metadata server is operable to:
obtain an identifier of a failed software update in the synchronization request if the client computing device stores the failed software update;
restrict the communication of selected software updates related to the failed software update, if it is determined that the synchronization request comprises an identifier of the failed software update.

18. The system as recited in Claim 1, wherein the download server is operable to:
obtain a selection of one or more available software updates for updating one or more files installed on the client computing device;
obtain a self-extracting file identifying a plurality of available delta patches for updating at least one version of an installed file;
obtain an inventory of the one or more files installed on the client computing device;

select one or more applicable delta patches to implement the selected software updates, wherein selecting the one or more applicable patches corresponds to a mapping of the self-attracting file identifying the plurality of available delta patches to the inventory of the one or mine files installed on the client computing device;
and transmit a request for one or more selected delta patches.

19. A system for updating data on a client computing device, the system a first database storing a plurality of delta patches;
a server computer communicatively coupled to said first database and to the client computing device, said server computer operable to:
obtain a selection of one or more available software updates for updating one or more files installed on the client computing device;
obtain a self-extracting file identifying a plurality of available delta patches for updating at least one version of an installed file;
obtain an inventory of the one or more files installed on the client computing device;
select one or more applicable delta patches to implement the selected software updates, wherein selecting the one or more applicable patches corresponds to a mapping of the self-extracting file identifying the plurality of available delta patches to the inventory of the one or more files installed on the client computing device;
and transmit a request for one or more selected delta patches.

20. A system for communicating software updates to a client computing device, the system comprising:
a first component storing a plurality of a server authorization modules, wherein an individual server authorization module identifies a target group;
a server computer communicatively coupled to said first component, said server computer operable to:
obtain an authorization request from the client computing device, wherein the authorization request contains an identifier of a client authorization module stored on the client computing device;

determine if the client computing device is associated with the target group, wherein it is determined that the client computing device is associated with the target group if the client authorization module indicates that the client computing device is associated with the target group;
communicate a server cookie from the software update service to the client computing device if it is determined that the client computing device is associated with the target group, wherein the server cookie identifies the target group;
obtain a request for at least one software update stored on the software update service, wherein the request contains the server cookie;
in response to obtaining the request, determine if a software update is associated with the target group identified in the server cookie; and if it is determined that the software update is associated with the target group identified in the server cookie, communicate the software update from the software update service to the client computing device.

21. A computer-readable medium having stored thereon a data structure of an individual software update, comprising:
an instruction data field containing an applicability rule defining at least one condition, wherein the applicability rule can be a null value, wherein the instruction component contains a set of prerequisites that identify one or more software updates that are required for installation of the individual software update, and wherein the set of prerequisites can be a null value;
a localized data field containing text data describing general information related to the individual software update; and a data component that identifies at least one data stream file associated with the individual software update.

22. The computer-readable medium of Claim 8, wherein the instruction component contains a data value that indicates if there are other updates that depend from the individual software update.

23. The computer-readable medium of Claim 8, wherein the instruction component contains a data value that indicates if the individual software update requires the installation of at least one other software update.

24. The computer-readable medium of Claim 8, wherein the localized data field provides an indication that the individual software update is a high priority update.

25. The computer-readable medium of Claim 8, wherein the localized data field provides an indication that the individual software update requires an exclusive installation.