Selection of code updates, data updates or new data for client6074434Abstract A server computer selects code updates to download to a client computer as follows. The server computer identifies code updates which are consistent with basic system characteristics of the client computer. Then, the server computer sends to the client computer one or more "recognizer" programs which execute in the client computer to determine whether the client computer has a version other than a current version of the consistent code updates. The client sends the results to the server computer which generates a list of those code updates which are consistent with the basic system characteristics, and represent programs that exist on the client computer for which an update would be appropriate. The server computer also identifies new data which is consistent with attributes of a user of the client computer. Then, the server computer sends to the client computer one or more recognizer programs which execute in the client computer to determine whether the client computer already has the consistent new data. The client sends the results to the server computer which generates a list of that new data which is consistent with the user attributes and not currently resident in the client computer. Claims We claim: Description BACKGROUND OF THE INVENTION
______________________________________
Code Updates Basic System
Information/
Meta Data
Device Driver BIOS Level 123
ABCDE.DRV BIOS date 1/1/96
Mother Board ID
XYZ
Netcomber 2.0 BIOS Level 123
BIOS date 1/1/96
Mother Board ID
XYZ
Device Driver BIOS Level 456
FGHIJ.DRV BIOS date 2/1/96
Mother Board ID
XYZ
______________________________________
In this example, the BIOS level 123, BIOS date Jan. 1, 1996 and mother board ID XYZ basic system information obtained from client 14 is consistent with a device driver file named ABCDE.DRV. and Netcomber (trademark of International Business Machines Corporation) version 2.0. However, device driver file named FGHIJ.DRV requires BIOS level 456 so is inconsistent with the basic system information obtained from client 14 and is eliminated from further consideration. For each code update, such as device driver file named ABCDE.DRV. and Netcomber program version 2.0, which is consistent with the basic system information of client 14, the selection update program 30 sends to the client 14 the FTP addressing information of a corresponding recognizer program, such as recognizer programs 40 and 42, respectively (step 111). However, the FTP addressing information is not provided (and no recognizer program is fetched) to client 14 for the device driver file named FGHIJ.DRV, because file FGHIJ.DRV is not consistent with the basic system information of client 14. From the FTP addressing information, the client 14 downloads the actual recognizer programs from the content server 17 (step 118). Each recognizer program is executable and small, typically 2,000-3,000 bytes. Consequently, each recognizer program can be downloaded from content server 17 to the client 14 in seconds (whereas the corresponding code update is much larger and may take hours to download). It should be noted that based on the basic system information alone, the selection update program 30 within server 12 is not sure which of the code updates that are consistent with the basic system information are actually needed by the client; for example, the client may already have the latest version. Next, the client 14 executes each recognizer program 40 and 42 with assistance from the scout 33 (step 118). The scout 33 assists the recognizer programs by providing subroutines callable by the recognizer programs. For files required by the recognizer programs, these callable subroutines can locate the files, determine the version of the files, determine the length of the file, identify a directory which lists the files, obtain time stamps for the files, obtain data from inside the files and obtain data from a program registry. This further reduces the requisite length of each recognizer program and therefore shortens the download time. When executed, each recognizer program further investigates the hardware, software and other components of the client 14 for information to determine whether the corresponding code update is appropriate for the client 14. For example, this investigation reveals if the client 14 already has these code updates as follows. A recognizer program could also determine if the corresponding code update is consistent with aspects of the client other than the basic system information, such as other programs within the client. Recognizer program 40 determines from the scout routine 33 in client 14 if the size of file ABCDE.DRV. stored by the client 14 is the same as the size of file ABCDE.DRV. stored in the data base 13. If so, then client 14 has the latest update. If not, then client 14 likely has an old version which could be updated. FIG. 4 illustrates recognizer program 40 in more detail. In step 200, recognizer program 40 calls scout 33 to scan client 14's hard disk for file ABCDE.DRV to determine if file ABCDE.DRV exists in client 14. If not, the recognizer program provides an indication that file ABCDE.DRV is not appropriate for client 14 (step 202). However, if file ABCDE.DRV exists in client 14, then recognizer program 40 calls scout 33 to retrieve the size of file ABCDE.DRV in client 14 (step 204), and then compares the file size to the size of the latest version stored in the content server (decision 206). (The recognizer program includes an indication of the size of the corresponding update in the content server.) If the two sizes are the same, then there is no need to download file ABCDE.DRV from the content server 17; client 14 already has the latest version. However, if the two sizes are not the same, then recognizer program 40 makes a record that the file ABCDE.DRV stored in the content server 17 is appropriate for client 14 (step 208). Recognizer program 42 compares a version number of the Netcomber program in the client to the version number of the Netcomber program of the code update, and if the version number of the Netcomber program installed in client 14 is less, then the client likely has an old version. FIG. 5 illustrates recognizer program 42 in more detail. In step 300, recognizer program 42 calls scout 33 to read a data base in client 14 to determine if the Netcomber program exists in client 14. If it does, recognizer program 42 calls scout 33 to obtain the version number of the Netcomber program from the data base (step 302). If the version number stored in the data base is equal to or greater than the version number in the recognizer program, then client 14 does not need the version stored in the content server 17 (decision 304 and step 306). However, if the version number stored in the data base is less than the version number in the recognizer program, then the recognizer program records that client 14 needs the copy of the Netcomber program stored in the content server 17 (decision 304 and step 308). The results of the recognizer programs include yes/no answers whether each respective code update is appropriate for the client, i.e. not currently resident in client 14 (and consistent with the client basic system information as determined previously in step 114). The recognizer programs can also assign a "critical" level to each code update based on the need of the client for the update. For example, if another program in the client needs this code update to function, then this code update would be assigned a high level of criticality. After the recognizer programs are executed in client 14, client 14 sends to selection server 12 a list of the code updates which are appropriate for the client (step 120). Based on the information gathered by the recognizer programs, the update selection program determines the level of criticality of the respective code updates and builds a selection form for display at the client (step 122). The selection form comprises a list of the code updates that are consistent with the basic system information and appropriate for the client 14, and a display of the following three selection choices (step 124): 1. minimum number of code updates--code updates which are necessary for the client to ensure compatibility between programs within the client and fix a significant "bug" in a program within the client, and those other updates that the author of the code update deemed critical such as replacement of unsupported programs. 2. maximum number of code updates--all code updates which are consistent with the basic system information and appropriate for the client. 3. client selection of specific code updates--user selects particular code updates from the list of all code updates which are consistent with the basic system information and appropriate for the client. Next, the client makes a selection, either selection of the first or second categories or an itemized list of code updates pursuant to the third category (step 130), and sends the selection to the server (step 131). In response, the server 12 sends to the client 14 the FTP addressing information for the selected code updates (step 132). Using this FTP addressing information, the download routine 39 of the client downloads the code updates from the content server 17 (step 133). (In the preferred embodiment of the present invention, the FTP addressing information for all code updates represented in the selection form are passed with the selection form to the client 14 in step 124.) As the code updates are being downloaded, the download routine also records status information (such as the FTP addresses) of the code updates in case of interruption to the communication line. If there is such an interruption, the downloading can continue later where it left off. Since the interruption could be lengthy and the system characteristics could have been altered, immediately before the selected code updates are actually installed, the update manager 32 invokes the corresponding recognizer programs again to ensure that the code updates are still required; it is possible that changes could have occurred to the client since the recognizer programs were previously executed. If the code updates are still appropriate, the service application routine of client 14 installs the code updates in the client 14 as follows (step 134). For every code update file whose stale version is not currently in use by client 14, the service application routine replaces the stale file with the updated file. The update manager also lists each code update file whose stale version is currently in use. Then, the client is requested to re-boot, and the operating system installs the listed code updates during the re-boot. For all, code updates selected by the user which represents one or more bytes of a file, the service application routine replaces just the one or more bytes of the file. For such files which are not currently in use, this occurs without requesting the user to re-boot. For such files which are currently in use, the user is requested to re-boot, and the operating system installs the one or more bytes during the re-boot. FIG. 6 illustrates a computer network generally designated 410 according to another embodiment of the present invention. Network 410 comprises a selection server 412 with a data base 413, a content server 417, clients 414-416 and Internet 20 to interconnect the servers and clients. By way of example, the selection server 412 comprises a computer workstation, associated programming and a modem, the content server 417 comprises a computer workstation, associated programming and a modem and each of the clients 414-416 comprises a personal computer, associated programming and a modem. Communications between the clients and the selection server 412 utilize hypertext transport protocol (HTTP) and communications between the clients and the content server 417 utilize file transport protocol (FTP). Although not shown, there are many other servers for the Internet. Selection server 412 is dedicated to automating selection of data updates and additional data, collectively called "new data". The content server 417 includes the actual, new data (stored on disk 421), and data base 413 includes meta data for the new data and FTP addressing information to locate the new data in content server 417. The meta data provides descriptive information about the respective new data such as those user attributes for which the new data is appropriate (assuming the user does not already have the new data). The FTP addressing information indicates the address or identification of the content server which stores the respective new data (content server 417 in the illustrated example), a user ID and password to log-on to the content server, a name of the new data, a list of files which comprise the new data and the size, checksum and directory of each file. The process for storing the new data in the content server 417 and the meta data in the selection server 412 is not critical to the present invention. However, according to one process, a person writes the new data and meta data and loads them into the content server 417, either via the Internet or by manual loading. The new data remains stored in the content server, but the meta data is written to the selection server 412, either via the Internet or by manual loading. As illustrated in FIG. 7, the selection server 412 is an http server with an associated "CGI" program 431 and includes a data selection program 430. The client 414 includes an update manager program 432 (including a GUI), a scout routine 433, a service application routine 434 and a download routine 439. The functions of the server and client programming and a typical client/server session for selecting and downloading new data are illustrated in FIGS. 8(a,b). A user at client computer 414 selects an icon to invoke update manager 432. In response, the update manager contacts the general manager 431 in server 412 to begin a session and supplies the current level of update manager 432, scout 433, service application 434 and download routine 439 within client 414 (step 504). In response, the general manager 431 determines if the client's update manager 432, scout 433, service application 434 and download routine 439 are the latest version (step 506). This determination is performed by comparing the client level information supplied by the client 414 to the data in selection server 412 for the latest version of the client's update manager 432, scout 433, service application 434 and download routine 439 stored in the content server 417. If the client's update manager, scout, service application and download routine are not the latest version, the server sends the FTP addressing information to the client to allow the client to retrieve the latest versions from a content server. Along with the FTP addressing for the client update manager, scout, service application and download routine, the server sends FTP addressing information to the client for a serial number recognizer program 441 stored in content server 417 which will query client computer 414 for the serial number of client computer 414 (step 507). Next, the client downloads and installs the latest version of the client update manager, scout, service application and download routine from the content server if the FTP addressing was provided (step 508). The furnishing of the FTP addressing information for the recognizer program 441 begins the new data selection process according to the present invention. The client next downloads the recognizer program 441 from the content server and executes it (step 509). The recognizer program 441 then obtains the serial number of the client machine 414 from the basic input output system (BIOS) firmware, using scout APIs (step 509). The update manager routine 432 then sends the serial number of the client machine 414, obtained by the recognizer program 441, to the selection server 412 (step 510). This initiates the selection update program 430 (step 512). The selection update program 430 within server 412 then determines, from a table 431, the employee number or name of the user that owns client machine 414. Alternately, in another embodiment of the present invention or when there is more than one user of client computer 414, the user sends his or her name or serial number to the server 412 in step 510. (In this scenario, selection server 412 does not send the FTP of recognizer program 441 to client 414 in step 507 and client 414 does not fetch or execute recognizer program 441. There is no need.) Once selection server 412 knows the employee number or name of the user of client machine 414, either from recognizer program 441 and table 431 or directly from the user, the selection update program can determine which data is appropriate for the user and which data is not appropriate for the user. This eliminates the vast majority of the data stored in content server 417 (and other content servers, if any) from further consideration (step 514). In the illustrated embodiment, this determination is made by the selection update program first reading from table 431 the user attributes corresponding to the user's serial number or name. These user attributes may include the user's job title, department, profession, age, income, or interests previously expressed by the user and forwarded to the server. Then, the selection update program correlates the meta data in data base 413 to the user's attributes. Matches between the meta data and the user's serial number or other attributes indicate that the corresponding new data may be appropriate for client 414. (In practice, the meta data and table 431 can be arranged in a relational data base to facilitate the correlation function). For example, the following table lists data available in content server 417 and the user attributes/meta data that matches each of the new data.
______________________________________
New Data User Attributes/Meta Data
______________________________________
Customer List Marketing person
Price List Marketing person
Salary Chart Manager
Company Rules All Employees
Golf Ad #1 (news) Golfer
Golf Ad #2 (equipment)
Golfer
Bowling Ad #1 Bowler
Bowling Ad #2 Bowler
______________________________________
In this example, users who are marketing employees are entitled to receive only "Customer List", "Price List" and "Company Rules" data. Users who are management employees are entitled to receive only "Salary Chart" and "Company Rules" data. Users who are golfers, but not employees, are targeted to receive only "Golf Ad #1" and "Golf Ad #2" data. Users who are bowlers, but not employees, are targetted to receive only "Bowling Ad #1" and "Bowling Ad #2" data. For each new data which is consistent with the user's attribute(s), the selection update program 430 sends to the client 414 the FTP addressing information of a corresponding recognizer program and the corresponding meta data (step 516). For example, for a user having the attribute of golfer, the selection update program 430 sends the FTP addressing for recognizer programs 440 and 442, respectively for "Golf Ad #1" and "Golf Ad #2". However, the FTP addressing information is not provided to client 414 for the recognizer programs for the other new data which is not consistent with the user's attribute(s). From the FTP addressing information, the client 414 downloads the actual recognizer programs from the content server 417 (step 518). Each recognizer program is executable and small, typically 2,000-3,000 bytes. Consequently, each recognizer program can be downloaded from content server 417 to the client 414 in seconds (whereas the corresponding new data may be much larger and take minutes or even hours to download). It should be noted that based on the user attribute(s) alone, the selection update program 430 within server 412 is not sure which of the new data that is consistent with the user's attribute(s) is actually needed by the client; for example, the client may already have some or all of the new data. Next, the client 414 executes recognizer programs 440 and 442 with assistance from the scout 433 (step 518). The scout 433 assists the recognizer programs by providing subroutines callable by the recognizer programs. For files required by the recognizer programs, these callable subroutines can locate the files, determine the version of the files, determine the length of the file, identify a directory which lists the files, obtain time stamps for the files, obtain data from inside the files and obtain data from a program registry. This further reduces the requisite length of each recognizer program and therefore shortens the download time. When executed, each recognizer program further investigates storage of the client computer 414 to determine if the user already has the new data available from the client computer. Optionally, the recognizer program may investigate a user profile 439 stored in the client computer 414 to determine whether the new data is consistent with other user attributes stored in user profile 439. Recognizer program 440 is illustrated in more detail in FIG. 9 and investigates the user's storage as follows. In this example, the sole user attribute (stored in table 431 in the selection server 412) is "golfer". First, recognizer program 440 determines from the scout routine 433 in client 414 if client 414 already has a copy of the Golf Ad #1 available for the user (decision 600). If not, then recognizer program 440 determines that, so far, "Golf Ad #1" is deemed appropriate for the user (step 602). However, if client 414 stores a file called "Golf Ad #1", then recognizer program 440 optionally will check if this is the same file as the one currently stored on the server with the same name. Accordingly, recognizer program 440 compares the size of the "Golf Ad #1" file stored in client computer 414 to the size of the "Golf Ad #1" file stored in the content server 417 (step 604 and decision 606). (The size of Golf Ad #1 stored in content server 417 was included in the meta data that was sent along with the FTP address of the recognizer program) If the sizes are different, then recognizer program 440 concludes that they are different files and that this file is deemed appropriate for downloading from the content server to the client computer 414 (step 602). However, if the sizes are the same, then recognizer program 440 concludes that they are the same file, and another copy of "Golf Ad #1" is not appropriate for downloading to the client computer (step 608). Recognizer program 442 performs the same analysis for "Golf Ad #2". For new data which is lengthy, a respective recognizer program could also determine if the client computer has sufficient memory for the new data by using the appropriate scout function. A recognizer program could also compare the meta data for new data to user profile 439 maintained in client computer 414 to further determine whether the new data is appropriate for the user. For example, the user profile 439 may qualify that the user's interests in golf are limited to golf news but not golf equipment. In such a case, the recognizer program would determine that "Golf Ad #1" relating to "news" would be appropriate for the user but "Golf Ad #2" relating to "equipment" would not be appropriate for the user. Assume that another recognizer program 445 illustrated in FIG. 10 corresponds to the "Customer List" data. Recognizer program 445, when executing in client computer 414, will determine if the user alreay has a file called "Customer List" (decision 700). If not, then the recognizer program 445 determines that this data is appropriate for downloading to the client (step 706). However, if the client already has a file called "Customer List", then recognizer program 445 will compare a date associated with the creation of the "Customer List" file stored in the server (and fetched with recognizer program 445) to the date associated with the creation of the "Customer List" file stored in client 414. If the date stored in the server is later, then the "Customer List" data stored in the server is appropriate for the user (step 706). Otherwise, it is not appropriate for the user (step 708). The results of the recognizer programs include yes/no answers whether each respective new data is appropriate for the user, i.e. not currently available in client 414 for the user and optionally, consistent with the user's profile, if any, stored in table 439 in the client computer. (The selection update program previously determined that the new data was consistent with the user's attributes stored in table 431 in the server computer). The recognizer programs can also assign a "critical" level to each new data based on the need of the user for the new data. For example, if the data is especially important such as the "Customer List" or the "Salary Chart", and the user has no version or a very old version, then this data would be assigned a high level of criticality. After the recognizer programs are executed in client 414, client 414 sends to selection server 412 a list of the new data which is appropriate for the user (step 520). Based on the information gathered by the recognizer programs, the selection update program determines the level of criticality of the respective data and builds a selection form for display at the client (step 522). The selection form comprises a list of the new data that is consistent with the user's attributes and appropriate for the client 414, and a display of the following three selection choices (step 524): 1. critical data (to minimize the download time) 2. all new data which is appropriate for the user. 3. client selection of appropriate new data--user selects particular new data from the list of all new data which is appropriate for the user. Next, the user makes a selection, either selection of the first or second categories or an itemized list of new data pursuant to the third category (step 530), and sends the selection to the server (step 531). In response, the server 412 sends to the client 414 the FTP addressing information for the selected new data (step 532). Using this FTP addressing information, the download routine 439 of the client downloads the new data from the content server 417 (step 533). (In the preferred embodiment of the present invention, the FTP addressing information for all new data represented in the selection form are passed with the selection form to the client 414 in step 524.) As the new data is being downloaded, the download routine also records status information (such as the FTP addresses) of the new data in case of interruption to the communication line. If there is such an interruption, the downloading can continue later where it left off. Upon completion of the download, the service application routine of client 414 installs the new data in the client 414 for access by the user as follows (step 534). For all files constituting the new data, except those which represent updates to existing data stored in the client computer for which the stale version is currently in use by client 414, the service application routine replaces the existing files in client 414 with the new file. The update manager also lists each data file whose stale version is currently in use. Then, the user is requested to re-boot, and the operating system installs the listed data during the re-boot. For all, appropriate new data selected by the user which represents one or more bytes of a file, the service application routine replaces just the one or more bytes of the file. For such files which are not currently in use, this occurs without requesting the user to re-boot. For such files which are currently in use, the user is requested to re-boot, and the operating system installs the one or more bytes during the re-boot. Based on the foregoing, techniques for selecting and transferring code updates and new data to a client computer have been disclosed. However, numerous modifications and substitutions can be made without deviating from the scope of the present invention. For example, there can be multiple content servers, or the selection server functions and content server function can be merged into one server. If desired, protocols other than HTTP and FTP can be used. Therefore, the present invention has been disclosed by way of illustration and not limitation and reference should be made to the following claims to determine the scope of the present invention.
|
Same subclass Same class Consider this |
||||||||||
