CA2494475A1 - Update distribution system architecture and method for distributing software - Google Patents

Update distribution system architecture and method for distributing software Download PDF

Info

Publication number
CA2494475A1
CA2494475A1 CA002494475A CA2494475A CA2494475A1 CA 2494475 A1 CA2494475 A1 CA 2494475A1 CA 002494475 A CA002494475 A CA 002494475A CA 2494475 A CA2494475 A CA 2494475A CA 2494475 A1 CA2494475 A1 CA 2494475A1
Authority
CA
Canada
Prior art keywords
update
service node
software
update service
child
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
CA002494475A
Other languages
French (fr)
Inventor
David B. Dehghan
David C. Hennessey
Edward F. Reus
Jason J. Roberts
Jianbo Hou
Lie Charles Ma
Marc Shepard
Mazhar N. Mohammed
Nirmal R. Soy
Thottam R. Sriram
Varadarajan S. Thiruvillamalai
Vidyasankar Raman
Xiang He
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of CA2494475A1 publication Critical patent/CA2494475A1/en
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26Power supply means, e.g. regulation thereof
    • G06F1/266Arrangements to supply power to external peripherals either directly from the computer or under computer control, e.g. supply of power through the communication port, computer controlled power-strips
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38Information transfer, e.g. on bus
    • G06F13/382Information transfer, e.g. on bus using universal interface adapter
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/0042Universal serial bus [USB]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99942Manipulating data structure, e.g. compression, compaction, compilation

Abstract

A hierarchical software update distribution system and method for distributing software updates is presented. The update distribution system includes a root update service node and at least one update service node. In an update distribution system, each update service node, except the root update service node, has one parent update service node. Each update service node may function as a parent update service node to child update service nodes.

Description

UPDATE DISTRIBUTION SYSTEM ARCHITECTURE
AND METHOD FOR DISTRIBUTING SOFTWARE
FIELD OF THE INVENTION
The present invention relates to software and computer networks, and, in particular, the present invention relates to an update distribution system architecture and method for distributing software updates.
BACKGROUND OF THE INVENTION
Nearly all commercially available software products undergo a continual revision process to repair or update features of the software. Each revision of a software product frequently requires adding new files, replacing existing files with newer revisions, deleting obsolete files, or various combinations of these actions. This process of replacing older files, adding new files, deleting obsolete files of a software product, changing the software product's configuration and behavior by adding and/or removing functionality, will be referred to hereafter as "updating the product," and the data collection, including binary files, data files, update instructions, metadata, and the like, used in updating the product will be referred to hereafter more simply as an "update."
Once a software provider has created an update for a software product, either to fix a problem, enhance security, or add new features, the software provider will want to make that update widely available to its customer base. Quite often, such as when the update is directed at correcting a flaw in the product or addressing a critical security issue, the software provider will want that update installed on the customers' computers as soon as possible.
Indeed, most software providers have a business incentive to distribute software updates to their customers as quickly and as trouble-free as possible.
The computer industry has experienced an explosive growth in the number of computers connected to networks, and in particular, to the Internet. Due to this explosive growth, and due to the communication abilities available through a connection to the Internet, the Internet has become an important and integral channel for software providers to distribute updates to their customers. In fact, the Internet has become the primary distribution channel for many software providers to provide software updates to their customers. It is often in the best interest of software providers to distribute software updates over the Internet, as electronic update distribution over the Internet reduces their overall costs and enables customers to obtain the software updates as soon as they are available. More and more frequently, these software updates are conducted automatically over the Internet, without any user intervention.
While the Internet is now commonly used as a conduit for distributing software updates from software providers, several issues frequently arise. Two such issues include ( 1 ) efficiency relating to the update distribution infrastructure/resources, and (2) administrative control over the distribution and installation of software updates.
In regard to efficiency of the distribution resources, networks, including the Internet, possess only a finite amount of communication resources, often referred to as bandwidth. A
finite amount of communication bandwidth frequently results in bottlenecks, especially in regard to software updates for popular software products, such as Microsoft Corporation's Windows~ family of operating systems and related productivity products. Such bottlenecks exist even when software updates are made available on multiple download locations distributed throughout the Internet. One reason that such bottlenecks occur is the unstructured access model made available by the Internet. For example, if a first user at computer A requests the latest download of a software product, the download passes through the first user's independent service provider (ISP). Furthermore, the request is treated as a single, individualized access, meaning that the request is treated independent of, and unrelated to, any other network traffic and/or request. As such, if a second user at computer B, who also happens to have the same ISP, requests the same download as the first user, the request from the second user is also treated as a single, individualized access. In this example, the same download will be transmitted over the same infrastructure twice, because each request was treated in isolation. Clearly, if the number of users increases substantially, the finite communication bandwidth will become a bottleneck. In this example, which is quite common, it would have been much more efficient if the download could have been cached at a local location, and each user request satisfied from the local cache.
With regard to control of distribution, many organizations, especially large organizations, have legitimate reasons to control the distribution of updates to their computers. For example, unfortunately some updates have or introduce flaws, frequently referred to as bugs, that "break" features of a software product. These broken features may be insignificant, but all too often they can disrupt a business's mission-critical features.
Alternatively, mission-critical features may be "broken" if they are removed or their behaviors substantially altered by a particular software update. As a business cannot afford to lose its mission-critical features, a responsible business will first evaluate and test each software update within a controlled environment for some period of time prior to releasing the update to the remainder of their computers. This evaluation period permits the organization to validate whether an update will adversely affect a mission-critical feature.
Only after it has been satisfactorily determined that an update will not bring down any mission critical feature is the update permitted to be distributed to the remainder of the organization's computers. Clearly, most organizations must exercise control over the installation of software updates on their computers.
Another reason that a business or an organization often needs to control distribution of software updates is to ensure consistency among the computers in the organization. It is very important for information service departments to have a standardized, target platform upon which all computers operate, whether it is for a word processor or an operating system.
Without a standard, software and computer maintenance may be unnecessarily complex and difficult.
Still another reason that local control is important is for billing purposes.
In large organizations, it is often inefficient to individually install software on a computer, or to individually maintain licenses for a particular software product for each computer in the organization. Instead, a single site license permits an organization to run a software product on numerous computers. Thus, an organization may be required to report the number of computers running a product under the site license, or may need to limit the number of computers running a product under a site license. All of these reasons often require local control over software update distribution.
In light of the various above-identified issues relating to software update distribution, what is needed is an extensible software update distribution architecture for providing control over the distribution of software updates, as well as increasing their distribution efficiency.
The present invention addresses these and other issues found in the prior art.
SUMMARY OF THE INVENTION
In accordance with the present invention, a software update distribution system for distributing a software update over a communication network is presented. The software update distribution system includes a root update service node and at least one child update service node. According to aspects of the present invention, the root update service node and the at least one child update service node are organized in a hierarchical manner. The root update service node is the parent update service node of at least one child update service node. Each update service node, except the root update service node, has a parent update service node. Each child update service node may also be a parent update service node to at least one other update service node in the software update distribution system hierarchy.
Additionally, the root update service node obtains a software update from a software provider. Each of the at least one child update service nodes obtains the software update from its parent update service node.
In accordance with additional aspects of the present invention, an update service node for distributing a software update to client computers and child update service nodes is presented. An update service node includes an update store for storing software updates.
The update service node also includes a web service interface through which the update service node obtains software updates from its parent update service node, and through which the update service node distributes software updates to child update service nodes.
The update service node further includes an administration application programming interface (API) through which an administrator, using an administration user interface, establishes rules for distributing software updates to child update service nodes. The update service node still further includes a child update module for determining which software updates are available to be distributed to the child update service nodes according to the established rules.
In accordance with further aspects of the present invention, a method for a child update service node in a software update distribution system to obtain a software update from its parent update service node is presented. The child update service node obtains a list of software products from its parent update service node. The list of software products identifies those software products for which the parent update service node distributes software updates. The child update service node selects a software product for which software updates are sought. The child update service node then submits a request to the parent update service node identifying those software products for which updates are sought.
In response, the child update service node receives an update list identifying software updates for the selected software products available to the child update service node. The child update service node then obtains each software update in the software update list from the parent update service node.
In accordance with yet further aspects of the present invention, a method for distributing software updates to a child update service node, executed on a parent update service node, is presented. A request is received from the child update service node requesting a software update catalog. A software update catalog, identifying software products for which the parent update service node distributes software updates, is returned to the child update service node. A request is then received for a list of software updates for a selected software product. In response, the parent update service node determines whether any software updates for the selected software product are available for the child update service node. An update list identifying those software updates for the selected software product determined to be available for the child update service node are returned to the child update service node. The update list identifies available software updates according to a unique update identifier. A update request is received requesting metadata corresponding to an available software update identified in the update list, the update request identifying the available software update by its unique identifier. In response, the update metadata is returned to the client update service node. The update metadata includes information corresponding to a software update including a reference for obtaining the corresponding update payload.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same become better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:
FIGURE 1 is a pictorial diagram of an exemplary update distribution system formed in accordance with aspects of the present invention;
FIGURE 2 is a block diagram illustrating exemplary logical components of an update service node formed in accordance with aspects of the present invention;
FIGURE 3 is a block diagram illustrating exemplary logical components of a root update service node formed in accordance with aspects of the present invention;
FIGURE 4 is a block diagram illustrating an exemplary exchange between a parent update service node and a child update service node in providing a software update from the parent update service node to the child update service node in accordance with aspects of the present invention;
FIGURE 5 is a flow diagram illustrating an exemplary routine executed on a child update service node to periodically obtain updates from its parent update service node;
FIGURE 6 is a flow diagram of an exemplary subroutine suitable for use in the exemplary routine of FIGURE 5 for obtaining an update catalog from a parent update service node;
FIGURE 7 is a flow diagram of an exemplary subroutine suitable for use in the exemplary routine of FIGURE 5 for obtaining a software update from a parent update service node; and FIGURE 8 is a flow diagram of an exemplary routine for processing an update request from a child update service node.
DETAILED DESCRIPTION
According to aspects of the present invention, an update distribution system, organized in a hierarchical fashion, for distributing software updates is presented. For purposes of the present invention, as already mentioned, a software update may involve replacing or removing older and/or obsolete files, adding additional files, altering a software product's configuration, and the like. Additionally, while not specifically directed to a software update of a software product in the technical and literal sense, aspects of the present invention may be advantageously utilized to distribute software products.
Accordingly, while the following discussion is made in terms of distributing software updates in an update distribution system, it is for illustration purposes only, and should not be construed as limiting upon the present invention.
FIGURE 1 is a pictorial diagram of an exemplary update distribution system 100 formed in accordance with aspects of the present invention. According to the present invention, at the "top" of an update distribution system, such as the illustrated update distribution system 100, is a root update service node 102. Software providers, such as software provider 110, distribute their software updates through the update distribution system 100 by submitting the updates to the root update service node 102.
According to aspects of the present invention, software providers, such as software provider 110, may submit their software updates to the root update service node 102 through a network, such as the Internet 108.
A hierarchical update distribution system, such as the exemplary update distribution system 100, will likely include at least one other update service node in addition to the root update service node 102. As illustrated in FIGURE l, the exemplary update distribution system 100 includes root update service node 102 and two additional update service nodes:
update service node 104 and update service node 106. According to the present invention, each hierarchical update distribution system is organized in a tree-like structure underneath the root update service node 102. In other words, each update service node in an update distribution system has zero or more child update service nodes. Thus, while the exemplary update distribution system 100 shows that each parent update service node, i.e., the root update service node 102 and update service node 104, have only one child, it is for illustration purposes only, and should not be construed as limiting upon the present invention. Furthermore, with the exception of the root update service node 102, according to one embodiment of the present invention, each update service node in an update distribution system has one parent update service node. Accordingly, as shown in FIGURE 1, update service node 104 is a child node to the root update service node 102, and update service node 106 is a child node to update service node 104. In an alternative embodiment, a child update service node may receive updates from multiple parent update service nodes (not shown.) As can be seen, each update service node, with the exception of the root update service node 102, can be both a child update service node and a parent update service node.

As illustrated in the exemplary update distribution system 100, the root update service node 102 communicates with update service node 104 through the Internet 108.
However, it should be understood that this is illustrative only, and should not be construed as limiting upon the present invention. Each update service node in an update distribution system need only be able to communicate with its parent and/or children through some communication network. Thus, while update service node 104 communicates with its parent, root update service node 102, through the Internet 108, it may alternatively communicate with its child update service nodes, such as update service node 106, via a local area network 124.
Also shown in FIGURE l, update service node 106 resides within a sub-network of the local area network 124. As an example, local area network 124 may correspond to an organization's general corporate network, and update service node 104 represents the corporation's link to the update distribution system 100, via its connection to its parent, root update service node 102. Further, sub-network 126 may correspond to an identifiable group of computers within the corporate network, such as a test/evaluation group, a remotely located office, or a mission critical group. As will be described in greater detail below, according to aspects of the present invention, an administrator on update service node 104 is able to control the distribution of updates to update service node 106, and ultimately to client computers.
It should be appreciated that each update service node, including both the root update service node 102 and update service nodes 104 and 106, is configured to distribute software updates to both child update service nodes as well as client computers. As shown in FIGURE 1, the exemplary update distribution system 100 includes client computers 112-122.
Each update service node, including the root update service node 102, distributes updates to child update service nodes and client computers according to local configuration information.
According to one embodiment, an administrator defines groups and associates update distribution rules with those groups. Each update service node has at least one distribution group.
As an example to illustrate how the update distribution system operates, assume that local area network 124 corresponds to a business organization's corporate network.
_g_ According to one embodiment of the present invention, an administrator, on update service node 104, may define multiple distribution groups for the corporate network 124, including an evaluation group, corresponding to the sub-network 126 including update service node 106 and client computers 120 and 122, for evaluating the suitability of an update for the general corporate network 124, as well as a general corporate group including the update service node 104 and client computers 114-118.
With regard to the evaluation group, the administrator includes the update service node 106 as a member, and associates rules with that group such that updates are immediately distributed to the evaluation group's members as they become available.
Alternatively, with regard to the general corporate group, the administrator adds client computers 114-118, and associates a rule such that updates are only distributed to the general corporate group members if specifically authorized by the administrator.
Assume also that an administrator for child update service node 106 creates a default group consisting of the client computers 120 and 122 in the evaluation sub-network 126, to which any new software update may be immediately distributed.
Continuing the above example, a software provider 110 submits a software update to the root update service node 102. According to rules established at the root update service node 102, the update is eventually distributed to the corporate update service node 104.
Upon receiving the update, per the rules established by the administrator, the corporate update service node 104 distributes the update to the members of the evaluation group (defined as only the child update service node 106), but withholds the update from the general corporate group pending specific authorization to distribute the update to that group.
Continuing the above example, upon receiving the update, the evaluation update service node 106 processes the update with respect to each defined group. In this example, the evaluation update service node 106 has only one group. However, as previously mentioned, in an actual implementation, there may be multiple groups defined, each with a unique set of associated distribution rules. For this example, the evaluation update service node 106 immediately makes the update available for distribution to client computers 120 and 122. Client computers 120 and 122 may now be updated and the evaluation period/process rnay begin.

Still continuing the above example, when the administrator on the corporate update service node 104 is sufficiently satisfied that the update is suitable for distribution over the entire corporate network 124, the administrator then explicitly authorizes the update to be distributed to the members of the general corporate group. The corporate update service node 104 correspondingly makes the update available to client computers 114-118. It should be understood that the evaluation update service node 106 may also be included in the general corporate group. However, because the evaluation update service node 106 has already been updated, no additional update-related action is needed for distributing the update to the evaluation sub-network 126.
As can be seen by the above example, the present invention offers significant benefits in terms of local distribution control and download efficiency. In addition to the above-described aspects of local distribution control, significant savings in communication bandwidth are also realized. For example, while the exemplary corporate network 124 illustrated in FIGURE 1 includes five client computers, the software provider's update was downloaded from the root update service node 102 to the corporate update service node 104 only one time. Clearly then, as the number of client computers serviced by an update service node increases, the communication bandwidth usage between a parent update service node and a client update service node remains constant, thereby substantially reducing the amount of communication bandwidth that would otherwise be used. Additionally, the update distribution system is both extensible and scalable. The update distribution system is extensible in at least two ways: any number of child update service nodes may be added to a parent update service node, and child update service nodes may also be a parent update service node. Each sub-tree of the update distribution system may therefore be tailored to meet individual needs.
Yet another benefit realized by the present invention is the ease in which an administrator establishes and enforces a consistent software platform over the client computers and network for which the administrator is responsible. For example, the current process that an administrator ensures a consistent software platform over client computers is generally the following: make a determination as to what the software platform is to be, i.e., which updates should be installed and which should not; determine the status of the software platforms on each client computer; and push the appropriate software updates down to the client computers for installation. Even after the initial effort, an administrator must frequently repeat the process in order to ensure that the software platform remains consistent.
In contrast to these prior art approaches, by utilizing the update distribution system described above, as well as the infrastructure support for grouping of clients machines into different target groups and the ability to target different updates at different target groups (described below), an administrator can specify the desired state for software update installation of the networks and or client computers for which the administrator is responsible.
An administrator specifies the desired state through an Administration API (also described below) for any number of client computers and/or groups of client computers.
Once the desire update state is established/specified, the administrator can then rely on the update distribution system to enforce the distribution of the updates throughout the update distribution system. The update distribution system works to make sure that the clients in the system conform to the desired state dictated by the administrator. Through periodic actions, the update distribution system constantly tries to bring those client computers that do not conform with the desired state into conformance. Additionally, by associating specific installation attributes with the software updates, such as a mandatory installation attribute or a install-by deadline installation attribute, the update distribution system relieves the administrator of a substantial portion of the implementation details associated with maintaining a consistent software platform. A more detailed description of associating installation attributes with a software update to control installation behaviors on a client computing device is set forth in copending and commonly assigned U.S. Patent Application entitled "Controlling Installation Update Behaviors On a Client Computer,"
filed March 12, 2004, attorney docket no. MSFT-1-22459, which is incorporated herein by reference.
FIGURE 2 is a block diagram illustrating exemplary logical components of an update service node 200, such as the corporate update service node 104 (FIGURE 1 ) or the evaluation update service node 106 (FIGURE 1), formed in accordance with aspects of the present invention. As shown in FIGURE 2, an update service node 200 includes an update web service 202, a client update module 204, a child update module 206, and a reporting module 208. The exemplary update service node 200 also includes an authentication/

authorization module 210, an administration application programming interface (API) 212, an update content store 214, an administration user interface 218, and an update information store 216.
The update web service 202 provides a common set of Web services through which S client computers, child update service nodes, and a parent update service node can communicate with an update service node. For example, with reference to FIGURE
1, in order for the child/evaluation update service node 106 to obtain a software update from the parent/corporate update service node 104, the client communicates through the parent's update web service 202. Similarly, when a parent update service node, such as root update service node 102, has information, including updates, to communicate to its child update service node 104, the parent update service node communicates through the child's update web service 202.
The client update module 204 handles communications between a client computer and the update service node 200 in regard to updates and update information stored on the update service node. The update-related communications include, but are not limited to, distributing updates in response to client requests and providing a list of available software products and associated updates for the client computer. The client update module 204 is also responsible for determining whether a client computer is authorized to obtain a particular update according to associated distribution rules, and responds to a client computer with the update-related information that the client computer is authorized to access.
The child update module 206 handles update-related communications between a parent update service node and its child update service nodes. The update-related communications include, but are not limited to, identifying lists of software products and associated updates available to a child update service node, as well as responding to update requests from a child update service node. The downstream update module 206 is responsible for determining whether a child update service node is authorized to obtain a particular update according to associated distribution rules, and responds to a child update service node with the update-related information that the child update service node is authorized to access.

The reporting module 208 generates update-related reports, such as which groups have or have not received a particular update, which client computers have or have not downloaded/installed an update, what updates are available on the update service node, and the like. These reports may be used internally, such as by an administrator, and also submitted to the parent update service node, via the parent's update service interface 202. As described above, it is often necessary for corporations to determine which client computers have a particular update installed, such as for billing purposes or for maintenance purposes.
Information/reports generated by the reporting module 208 may be the basis of these reports.
The authentication/authorization module 210 is responsible for authenticating, i.e., determining the identity of, a particular client computer or child update service node, and determining whether a client computer or child update service node is authorized to access available updates at the update service node 200. To those client computers and child update service nodes that are authenticated and authorized to access updates on an update service node, the authentication/authorization module 210 issues an authorization token that must be 1 S used in conjunction with obtaining updates. The issuance and use of an authorization token is described in greater detail below in regard to FIGURES 4A and 4B.
The administration API212 represents the application interface through which control of the update service node 200 is exercised, and through which updates ultimately are stored and distributed. When the update web service 202 receives various update-related requests from client computers and child update service nodes, these requests are ultimately broken into calls into the administration API 212, either directly or indirectly through the client update module 204 and the child update module 206. In conjunction with the administration user interface 218 or some other program installed on the update service node 200 suitably configured to use the administration API 212, an administrator ultimately controls all aspects of the update process for that update service node, as well as any child update service nodes and client computers.
Through the administration user interface 218, administrators may configure and maintain an update service node 200, via the administration API 212. Thus, through the administration user interface 218, an administrator creates, modifies, and deletes groups, as well as associating rules for each group. Furthermore, using the administration user interface 218, an administrator establishes to which group a client computer or child update service node belongs. Through the administration user interface 218, an administrator may also explicitly authorize the distribution of updates to client computers or child update service nodes, configure the update service node 200 to periodically query its parent update service node for new updates, configure reporting parameters and view internal reports, and the like. As mentioned above, while the administration user interface 218 permits an administrator to exercise control over aspects of the update service node 200, another application residing on the update service node 200, suitably adapted to operate with the administration API 212, may be used instead of the administration user interface 218.
As mentioned above, according to one embodiment of the present invention, an update service node 200 includes both an update content store 214 and an update information store 216. The update content store 214 stores the actual files representing the software updates, such as binaries and patch files. In contrast, the update information store 216 stores information and metadata corresponding to the updates available on the update service node 200, including the update files stored in the update content store 214.
According to one embodiment, the update content store 214 and the update information store 216 are both relational databases. While the exemplary update service node 200 is shown as having two data stores, the present invention should not be so limited. In an alternative embodiment, both the update content store 214 and the update information store 216 may be combined in a single information store.
In accordance with aspects of the present invention, a software update may be presented as being "available" on an update service node 200 to client computers and child update service nodes even though the update is not stored physically in the update content store 214. More particularly, rather than immediately downloading and storing the actual update files on an update service node 200, a link referencing the update files on the parent update service node or elsewhere, may instead be stored on the update service node. Thus, if a client computer requests the update, or a child update service node requests the actual update, the update is then brought down from the parent update service node and stored in the update content store 214, in preparation for delivering it to the client computer or child update service node. Those skilled in the art will recognize this type of update access is referred to as just-in-time downloading. In this manner, an "available"
update, need not be distributed over the various network channels until it is actually requested.
According to aspects of the present invention, an administrator of an update service node 200 may selectively determine whether to obtain software updates in a just-in-time manner.
While the above description of FIGURE 2 illustrates various components of an exemplary update service module 200, it should be appreciated that other components of an update service module may also exist. Furthermore, the above described components should be understood to be logical components, not necessarily actual components. In an actual implementation, the above identified components may be combined together and/or with other components according to implementation determinations. Additionally, it should be appreciated that while an update service node 200 may be viewed as a server computer on a network, in an actual implementation, an update service node may be implemented on any number of types of computing devices. For example, each update service node 200 may be implemented and/or installed on a single stand-alone computer system or, alternatively, on a distributed computing system comprising multiple computing devices.
FIGURE 3 is a block diagram illustrating exemplary logical components of a root update service node 300, such as the root update service node 102 illustrated in FIGURE 1, formed in accordance with aspects of the present invention. Similar to the logical components of an update service node 200 (FIGURE 2), a root update service node 300 includes an update web service 202, a child update module 206, and an authentication/authorization module 210. Additionally, an exemplary root update service node 300 also includes an administration API 212, an update content store 214, and an update information store 216. Optionally, the root update service node 300 may also include a client update module 204, a reporting module 208, and an administration user interface 218.
The client update module 204 is an optional component for a root update service node 300 depending on whether the root update service node provides software updates directly to client computers. For example, with reference to FIGURE 1, root update service node 102 would include the optional client update module 204 as the root update service node that directly services client computer 112. However, if a root update service node 300 were not to directly service client computers, the client update module 204 could be omitted.
The reporting module 208 is optional for a root update service node 300 because a root update service node has no parent update service node to whom update reports are provided. However, to the extent that update reports are desirable to the root update service node's administrator, the reporting module 208 may be optionally included.
In addition to comprising the logical components included in an update service node 200 (FIGURE 2), the root update service node 300 also includes a software provider interface 302. The software provider interface 302 provides the communication interface by which a software provider 110 (FIGURE 1 ) submits software updates directly to the root update service node 300, and indirectly to the exemplary update distribution system 100.
Similar to the update service node 200 of FIGURE 2, the above description of FIGURE 3 illustrates various components of an exemplary root update service module 300.
However, it should be appreciated that other components of a root update service module may also exist. Furthermore, the above described components should be understood to be logical components, not necessarily actual components. In an actual implementation, the above identified components may be combined together and/or with other components according to implementation determinations. Additionally, it should be appreciated that while a root update service node 200 may be viewed as a server computer on a network, in an actual implementation, an update service node may be implemented on any number of computing devices. For example, the root update service node 300 may be implemented and/or installed on a single stand-alone computer system or, alternatively, on a distributed computing system comprising multiple computing devices.
In order to better understand how an update is distributed from the root update service node throughout an update distribution system 100, an illustration of an exemplary exchange between a parent update service node and a child update service node is warranted.
FIGURE 4 is a block diagram illustrating an exemplary exchange 400 between a parent update service node 402 and a child update service node 404 in propagating a software update from the parent update service node to the child update service node, in accordance with aspects of the present invention. As can be seen, the exemplary diagram 400 is divided in half, the left half of which corresponds to actions and events of the parent update service node 402, and the right half corresponding to actions and events of the child update service node 404.
For purposes of discussion with regard to FIGURE 4, it should be further understood that the parent update service node 402 may or may not be the root update service node in the update distribution system 100. Additionally, for purposes of this discussion, it is assumed that the parent update service node 402 has been configured by an administrator such that the child update service node 404 may not receive software updates unless explicitly authorized to do so by the administrator.
As shown in the exemplary exchange 400, beginning at event 406, the parent update service node 402 receives a software update from a software provider 110, either directly, if the parent update service node is the root update service node 102, or indirectly through the update distribution system 100. At some point after the parent update service node 402 receives the software update from the software provider 110, the child update service node 404 begins a process for obtaining software updates from the parent update service node.
According to one embodiment, a child update service node 404 can be configured to automatically obtain the software updates available from a parent update service node 202 on a periodic basis. More particularly, an administrator, via the administration user interface 218, may selectively configure the child update service node 404 to automatically obtain the latest software updates available on the parent update service node 402 on a periodic basis. As one example, an administrator may configure the child update service node 404 to obtain the latest software updates from its parent update service node 402 on a daily and/or hourly basis, as well as specify the time-of day that the automatic update process is to commence. Other periodic schedules and criteria may also be utilized.
Similarly, an administrator may manually initiate the update process through the administration user interface 218.
To begin the updating process, at event 408 the child update service node 404 authenticates and authorizes itself with the parent update service node 402.
Authenticating and authorizing with the parent update service node 402 provides an element of control over the distribution of software updates, limiting update distribution to authorized update service nodes. Authenticating and authorizing techniques are well known in the art, any number of which may be employed to authenticate and authorize a child update service node 404 with the parent update service node 402. The present invention is not restricted to any one S technique.
After properly authenticating and authorizing with the parent update service node 402, at event 410 the parent update service node 402 returns an authorization token to the child update service node 404. According to one embodiment, an authorization token is a time sensitive token providing the child update service node 404 authorization to conduct further update activities with the parent update service node for a limited amount of time.
Thus, if the child update service node 404 is not properly authenticated and authorized with the parent update service node, no authorization token is returned and the child update service node is unable to perform any other update-related activities except authentication and authorization. Similarly, after the update token has expired, the child update service node 404 is unable to perform any further update-related activities with the parent update service node 402 except reauthentication and reauthorization.
After receiving the authorization token, at event 412 the child update service node 404 submits a request to the parent update service node for a product update catalog along with the authorization token. A product update catalog represents a listing, or table of contents, of software products for which the parent update service node 402 distributes software updates.
According to aspects of the present invention, a child update service node 404 is not required to propagate all software updates available on its parent update service node 402.
For example, with reference to the exemplary update distribution system of FIGURE 1, the corporate update service node 104 may have site licenses to only a fraction of software products available on the root update service node 102. Accordingly, it would be unnecessary for the corporate update service node 104 to obtain all software updates available at the root update service node 102, as most would never be used.
Accordingly, an administrator on an update service node may selectively establish which software product updates will be available on the update service node. In addition to selecting a software product, an administrator may also selectively identify additional, more specific, aspects relating to the software product in order to minimize the amount of network bandwidth consumed in the update process. For example, in addition to selecting a software product, an administrator may selectively specify that only English versions of software updates for the selected software product are requested. Similarly, an administrator may selectively specify that only software updates having a specific attribute are download. As an example of these specific attributes, an administrator may request, for the selected software product, only security-related software updates, or those that the software provider 110 considers to be critical. In sum, according to aspects of the present invention, an administrator may request a list of software updates for a selected software product according to any identifiable attribute or aspect of a software update.
According to one aspect of the present invention, the update product catalog, obtained from a parent update service node 402, identifies all software products for which updates are available, whether or not the child update service node 404 is configured to distribute updates for each product. However, according to an alternative aspect of the present invention, the update product catalog, obtained from a parent update service node 402, identifies only those software products for which the requesting child update service node is configured to distribute updates. For example, limiting which software products are listed in the product update catalog may be determined according to the group or groups to which the child update service node 404 belongs.
At event 414, the parent update service node 402 returns a product update catalog to the child update service node 404. At event 416, the child update service node 404 selects those products from the product update catalog for which the latest updates are currently desired. It should be noted that even though the product update catalog may list only those software products that the child update service node 404 distributes, the child update service node may be configured to obtain updates for different software products at different times or on different periodic schedules.
At event 418, the child update service node 404 submits an update synchronization request, along with the authorization token, identifying the selected products for whose updates the child update service node is currently seeking. Included in the synchronization request is information identifying the latest update available for a product on the child update service node 404. Information identifying the latest update for a product is hereafter referred to as an "update anchor." Update anchors for each software product are typically stored in the update information store 216 (FIGURE 2). In one embodiment, an update anchor includes a revision number and a date associated with the revision number.
In response to the update synchronization request, at event 420 the parent update service node 402 determines which, if any, new updates are available for the child update service node 404. As mentioned above, this determination is based on the specific rules associated with particular software updates and the group or groups of which a child update service node 404 is a member, as well as the update anchor. For this example, as previously mentioned, the previously received software update was explicitly not authorized for the child update service node 404. Therefore, the software update received at event 406 is not determined to be "available" to the child update service node 404.
Accordingly, at event 422 an update list is returned to the child update service node 404 without identifying the software update received at event 406. According to aspects of the present invention, the update list identifies all of the updates "available" on the parent update service node 402 according to the synchronization request. In one embodiment, the update list identifies each "available" update information by a unique identifier associated with an update.
At event 424, because the update list is empty, i.e., no updates are currently "available" on the parent update service node 402, the update process of the child update service node 404 simply delays, or sleeps, for a predetermined amount of time.
According to the current example, during this delay period, at event 426, an administrator at the parent update service node 402 authorizes the software update, received at event 406, to be distributed to the child update service node 404.
At event 428 (FIGURE 4B), the child update service node 404 again begins the automatic update process by authenticating and authorizing itself with the parent update service node 402. In response, at event 430, the parent update service node 402 returns an authorization token to the child update service node 404.
At event 432, the child update service node 404 submits a request, along with the authorization token, to the parent update service node 402 for a product update catalog. At event 434, the parent update service node 402 returns the product update catalog to the child update service node 404. At event 436, the child update service node 404 selects the products for the update catalog for which updates are desired. At event 438, the child update service node 404 submits the update synchronization request identifying those selected products with the authorization token.
Because the child update service node 404 has been authorized to obtain the software update previously received at event 406, at event 440 the parent update service node 402 determines that the software update is "available" for the child update service node and includes corresponding update information in the update list. Thereafter, at event 442, the parent update service node 402 returns the update list, now identifying the software update received at event 406, to the child update service node 404.
With an update list identifying an "available" update on the parent update service node 402, the child update service node 404 now has the information necessary to obtain the software update. According to one embodiment of the present invention, a child update service node 404 obtains the software update from the parent update service node 402 in two parts: obtaining update metadata, and obtaining the update content or file, hereafter referred to as the update payload. According to additional aspects of the present invention, the update metadata describes pertinent aspects of the software update, including, but not limited to: an update identifier that uniquely identifies the update, revision number information associated with the software update, whether the software update should be considered a priority, language specific information, relationships to other software updates, location of the update payload for downloading purposes, installation handler routines, and the like.
Some of the reasons that it is often beneficial to download the entire software update in two parts, i.e., the update metadata and the update payload, is that the update payload is often substantially larger than the update metadata, and the update payload is not always immediately needed, i.e., needed for installation on a client computer, if it is ever needed.
Thus, according to one embodiment of the present invention, the update payload is downloaded separately from the update metadata, and only when needed. Those skilled in the art will recognize this downloading technique as lazy downloading, or alternatively as just-in-time downloading. According to aspects of the present invention, an administrator may configure an update service node to obtain the update payload in a just-in-time fashion, or immediately upon obtaining the update metadata. Furthermore, in an alternative embodiment, both update metadata and the update payload may be downloaded jointly.
As shown in FIGURE 4B, with an update identified in the update list, at event 444, the child update service node 404 requests the update metadata for the "available" software update according to its unique identifier in the update list. As with most other communication exchanges with the parent update service node 402, the update request is submitted with the authorization token. It should be noted that while in the illustrated example, all update metadata is downloaded in one access, according to alternative aspects of the present invention (not shown), the update metadata may be downloaded in more than one access. For example, in a first access, only elements of the update metadata to are necessary to determine whether a software update is applicable and/or desirable is first downloaded, such as applicability rules and dependencies upon other software updates.
Then, after it is determined that an update is applicable and/or desirable, the remainder of the update metadata may be obtained. In response, at event 446 the parent update service node 402 returns the update metadata for the software update child update service node 404, which in turn stores the update metadata into the update information store 216.
Optionally, at event 448, the child update service node 404 submits a request to download the update payload from the parent update service node 402. In response, at event 450, the parent update service node 402 returns the update payload to the child update service node 404, which in turn stores it in the update content store 214. In an alternative embodiment, the child update service node 404 downloads the update payload from a storage location, which may not be the parent update service node 402, from a location specified in the update metadata.
Because update activity has now occurred on the child update service node 404, at event 452, the child update service node generates and submits an update report to the parent update service node 402 outlining the update activities that have just recently occurred.
Thereafter, the child update service node 404 again delays until the next time that the update process is scheduled to run (not shown).

Those skilled in the art will appreciate that the above described events are for illustration purposes, and reflect one particular exemplary set of events and circumstances.
Clearly, other events may also occur according to specific details and circumstances which will cause some variation to the above described events. Additionally, it should be understood that while the child update service node 404 is obtaining the latest "available"
software updates from the parent update service node 402, the child update service node may simultaneously be processing update requests from its child update service nodes.
Accordingly, the above sequence of events should be viewed as illustrative only, and not limiting upon the present invention.
FIGURE 5 is a flow diagram illustrating an exemplary routine 500 executed on a child update service node, such as the corporate update service node 104 of FIGURE 1, for periodically obtaining updates from its parent update service node. Beginning at block 502, the child update service node obtains a synchronized update list of "available" updates from the parent update service node. Obtaining a synchronized update list of "available" updates from the parent update service node is described below with regard to FIGURE
6.
FIGURE 6 is a flow diagram of an exemplary subroutine 600, suitable for use in the exemplary routine 500 of FIGURE 5, for obtaining a synchronized update list of "available"
updates from a parent update service node. Beginning at block 602, as previously discussed with regard to FIGURES 4A and 4B, the child update service node authenticates and authorizes itself with the parent update service node and, in response to proper authentication and authorization, receives an authorization token. At block 604, in conjunction with the authorization token, the child update service node establishes communication parameters with the parent update service node. Establishing communication parameters permits the parent and child update service nodes to properly establish a common basis that both the parent and child understand. The communication parameters include, but are not limited to:
communication update protocols or versions; product groupings; and the like.
After having established communication parameters with the parent update service node, at block 606, the child update service node obtains a product update catalog describing software products for which the parent update service node provides/distributes updates. At block 608, the child update service node selects those software product updates for which updates are currently sought. At block 610, the child update service node submits an update synchronization request to the parent update service node, including both the authorization token and an "anchor" associated with the selected software products identifying the current revision and updates already on the child update service node.
In response to the update synchronization request, at block 612, the child update service node obtains an update list from the parent update service node, synchronized according to the software updates "available" on the parent update service node according to what is currently stored on the child update service node. As mentioned above, the update list identifies, by a unique identifier, those software updates on the parent update service node that are "available" to the child update service node. Thereafter, the exemplary subroutine 600 terminates.
With reference again to FIGURE 5, after having obtained a synchronized update list from the parent update service node, at decision block 504, a determination is made as to whether any software updates are currently "available" for downloading from the parent update service node. This determination is made according to whether there are any update identifiers listed in the synchronized update list. If no software updates are currently "available" for downloading, the exemplary routine 500 proceeds to delay block S 10, where the exemplary routine delays/sleeps until the next update period occurs.
Alternatively, if there are updates "available" for downloading from the parent update service node, at block 506, the child update service node obtains the updates from the parent update service node. Obtaining "available" updates from the parent update service node is described below with regard to FIGURE 7.
FIGURE 7 is a flow diagram of an exemplary subroutine 700, suitable for use in the exemplary routine 500 of FIGURE 5, for obtaining "available" software updates from a parent update service node. Beginning at block 702, a first update identifier in the update list is selected. At block 704, the child update service node obtains the update metadata corresponding to the selected update identifier from the parent update service node and stores it in the update information store 216.
According to one embodiment, at block 706, the child update service node obtains the update payload corresponding to the selected update identifier from the parent update service node, and stores the update payload in the update content store 212.
Optionally, the update content need not be immediately downloaded to the child update service node.
As previously mentioned, a child update service node may be selectively configured to download updates from a parent update service node in a just-in-time fashion.
According to this optional treatment, as illustrated in FIGURE 7, rather than proceeding from block 704 to block 706, the exemplary subroutine 700 optionally proceeds from block 704 to decision block 708.
At decision block 708, after having obtained the update metadata for the selected update identifier, and optionally the update payload, a determination is made as to whether there are any additional update identifiers in the update list. If there are additional update identifiers, at block 710, the next update identifier in the update list is selected, and the subroutine 700 returns to block 704 for additional processing. The routine 700 continues until, at decision block 708, it is determined that there are no more update identifiers in the update list, whereupon the exemplary subroutine 700 terminates.
Returning again to FIGURE 5, after having obtained the "available" updates from the parent update service node, at block 508, the child update service node reports the update activities to the parent update service node. Thereafter, at delay block 510, the exemplary routine 500 delays/sleeps for a predetermined amount of time until the next update period, and then proceeds to block 502 to repeat the above-identified update procedures.
As illustrated in FIGURE 5, at decision block 504, even when no updates are "available" on a parent update service node, a child update service node may be optionally configured to report its update activities to the parent update service node.
According to this alternative configuration, when there are no updates available, the exemplary routine 500 may proceed to block 508 to report the update activities.
FIGURE 8 is a flow diagram of an exemplary routine 800, implemented on a parent update service node, for generating a synchronized update list identifying "available" updates in response to an update synchronization request from a child update service node.
Beginning at block 802, the parent update service node receives an update synchronization request from a child update service node for an update list identifying "available" updates.

At block 804, the first software product identified in the update synchronization request is selected.
At decision block 806, a determination is made as to whether there are any available updates for the identified software product. This determination is made according to metadata for the software product stored in the update information store 216, according to the update anchor provided by the child update service node, and according to distribution rules associated with the group to which the child update service node belongs. According to this determination, if there are updates "available," at block 808, unique update identifiers associated with the "available" updates are written into an update list. After having written unique update identifiers for "available" updates into the update list, at decision block 810, a determination is made as to whether there are any more additional software products identified in the update synchronization request. If there are additional update software products in the update synchronization request, at block 814, the parent update service node selects the next software product identified in the update synchronization request, and returns to decision block 806 for determining whether there are "available" updates for the selected software product. Alternatively, if there are not more software products identified in the update synchronization request, at block 814, the update list is returned to the child update service node. Thereafter, the exemplary subroutine 800 terminates.
While various embodiments of the present the invention have been illustrated and described, including the preferred embodiment, it will be appreciated that various changes can be made therein without departing from the spirit and scope of the invention.

Claims (29)

The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:
1. ~A software update distribution system for distributing a software update over a communication network for distribution to client computers, comprising:
a root update service node; and at least one child update service node;
wherein the root update service node and the at least one child update service node are organized in a hierarchical manner such that the root update service node is a parent update service node to at least one child update service node, wherein each update service node, except the root update service node, has a parent update service node, and wherein each of the at least one child update service nodes may also be a parent update service node to at least one other child update service node; and wherein the root update service node obtains a software update from a software provider, and wherein each of the at least one child update service nodes obtains the software update for distribution to client computers by obtaining the software update from its parent software update node.
2. ~The software update distribution system of Claim 1, wherein the root update service node comprises:
an update store for storing software updates;
an update web service through which the root update service node distributes software updates to its child update service nodes over the communication network; and a software provider interface through which a software provider submits its software update over the communication network to the root update distribution node.
3. ~The software update distribution system of Claim 2, wherein each of the at least one child update service nodes comprises:
an update store for storing software updates;
an update web service through which the child update service node obtains software updates from its parent update service node over the communication network, and through which the child update service node distributes software updates to its child update service nodes over the communication network;
an administration application programming interface (API) through which an administrator, using an administration user interface, establishes rules for distributing software updates to its child update service nodes; and a child update module for determining which software updates are available to be distributed to its child update service nodes according to the established rules.
4. ~The software update distribution system of Claim 3, wherein each of the at least one child update service nodes further comprises:
a reporting module for generating and sending update activity reports to the parent update service node;
an authentication and authorization module for determining whether an update service node is authorized to obtain software updates from the child update service node; and a client update module for distributing software updates to client computers.
5. ~The software update distribution system of Claim 4, wherein the update store comprises an update content store in which the update payload for the software update is stored, and an update information store in which update metadata for the software update is stored.
6. ~The software update distribution system of Claim 5, wherein the child update service node obtains the software update from the parent update service by obtaining update metadata for the software update from the parent update service node, and separately obtaining the update payload for the software update from the parent update service node.
7. ~The software update distribution system of Claim 6, wherein the child update service node obtains the update payload for the software update from the parent update service node in a just-in-time fashion.
8. ~The software update distribution system of Claim 4, wherein the client update module distributes software updates to client computers according to rules established by an administrator via the administration API using the administration user interface.
9. ~The software update distribution system of Claim 8, wherein the root update service node further comprises a client update module for distributing software updates to client computers.
10. ~The software update distribution system of Claim 3, wherein the child update service node may be selectively configured to periodically obtain available software updates from the parent update service node.
11. ~An update service node for distributing software updates to client computers and to child update service nodes, comprising:
an update store for storing software updates;
an update web service through which the update service node obtains software updates from a parent update service node over a communication network, and through which the update service node distributes software updates to child update service nodes over the communication network;
an administration application programming interface (API) through which an administrator, using an administration user interface, establishes rules for distributing software updates to the child update service nodes; and a child update module for determining which software updates are available to be distributed to the child update service nodes according to the established rules.
12. ~The update service node of Claim 11, further comprising:
a reporting module for generating update activity reports to the parent update service node;
an authentication and authorization module for determining whether a child update service node is authorized to obtain software updates from the update service node; and a client update module for distributing software updates to client computers.
13. ~The update service node of Claim 12, wherein the update store comprises an update content store in which the update payload for the software update is stored, and an update information store in which update metadata for the software update is stored.
14. ~The update service node of Claim 13, wherein the update service node obtains the software update from the parent update service by obtaining update metadata for the software update from the parent update service node, and separately obtaining the update payload for the software update from the parent update service node.
15. ~The update service node of Claim 14, wherein the update service node obtains the update payload for the software update from the parent update service node in a just-in-time fashion.
16. ~The update service node of Claim 12, wherein the update module distributes software updates to client computers according to rules established by an administrator via the administration API using the administration user interface.
17. ~The update service node of Claim 11, wherein the child update service node may be selectively configured to periodically obtain available software updates from the parent update service node.
18. ~A method for a child update service node to obtain a software update from a parent update service node in a software update distribution system over a communication network, the method comprising the steps of:
(a) obtaining a list of software products from the parent update service node for which the parent update service node provides software updates;
(b) selecting a software product from the list of software products;
(c) submitting a request to the parent update service node for available software updates corresponding to the selected software product;
(d) obtaining a software update list identifying software updates for the selected software product available to the child update service node;

(e) obtaining each software update in the software update list from the parent update service node.
19. ~The method of Claim 18, wherein obtaining each software update in the software update list from the parent update service node comprises:
obtaining metadata corresponding to the software update from the parent update service node; and obtaining the update payload.
20. ~The method of Claim 19, wherein obtaining the update payload comprises obtaining the update payload in a just-in-time fashion when needed by a child update service node or a client update service node.
21. ~The method of Claim 20, wherein the request to the parent update service node for available software updates corresponding to the selected software product includes an update anchor, the update anchor identifying the latest revisions and updates for the selected software product currently available at the update service node.
22. ~The method of Claim 21 further comprising the step of first submitting an authentication and authorization request to the parent update service node, and obtaining an authorization token in response to the authentication and authorization request;
and wherein each subsequent communication from the child update service node to the parent update service node is made with the authorization token.
23. ~The method of Claim 18, wherein steps (a)-(e) are performed on a periodic basis.
24. ~A computer-readable medium bearing computer-executable instructions which, when executed on an update service computer, carry out the method comprising the steps of:
(a) obtaining a list of software products from the parent update service node for which the parent update service node provides software updates;
(b) selecting a software product from the list of software products;

(c) submitting a request to the parent update service node for available software updates corresponding to the selected software product;
(d) obtaining a software update list identifying software updates for the selected software product available to the child update service node;
(e) obtaining each software update in the software update list from the parent update service node.
25. ~A method for distributing software updates to a child update service node, executed on a parent update service node in a software update distribution system over a communication network, the method comprising:
(a) receiving a request for a software update catalog from a child update service node, the software update catalog identifying software products for which the parent update service node provides software updates;
(b) returning a software update catalog to the child update service node;
(c) receiving a request for a list of software updates for a selected software product available for the child update service node;
(d) determining whether any software updates for the selected software product are available for the child update service node;
(e) returning a software update list identifying those software updates for the selected software product determined to be available for the child update service node to the child update service node, the software update list identifies available software updates according to a unique update identifier;
(f) receiving an update request for metadata corresponding to an available software update from the child update service node, the update request identifying the available software update by its unique update identifier; and (g) returning update metadata corresponding to the software update identified in the update request, the update metadata including information corresponding to the software update including a reference for obtaining the corresponding update payload.
26. ~The method of Claim 25 further comprising:
prior to steps (a)-(g):

receiving an authentication and authorization request from the child update service node;
determining whether the child update service node is authorized to obtain software updates from the parent update service node; and if the child update service node is authorized to obtain software updates from the parent update service node, returning an authorization token to the child update service node; and ~~
wherein each subsequent communication from the child update service node to the parent update service node is made with the authorization token.
27. The method of Claim 26 further comprising:
receiving an update request for the update payload corresponding to the software update identified in the update request; and returning the update payload corresponding to the software update identified in the update request.
28. The method of Claim 25, wherein the request for a list of software updates for a selected software product includes an update anchor identifying the latest update information on the child update service node corresponding to the selected software product;
and wherein determining whether any software updates for the selected software product are available for the child update service node comprises determining whether there are any updates available to the child update service node according to the update anchor and according to rules associated with the distribution of software updates to the child update service node.
29. A computer-readable medium bearing computer-executable instructions which, when executed on a parent update service computer, carry out the method comprising the steps of:

(a) receiving a request for a software update catalog from a child update service node, the software update catalog identifying software products for which the parent update service node provides software updates;
(b) returning a software update catalog to the child update service node;
(c) receiving a request for a list of software updates for a selected software product available for the child update service node;
(d) determining whether any software updates for the selected software product are available for the child update service node;
(e) returning a software update list identifying those software updates for the selected software product determined to be available for the child update service node to the child update service node, the software update list identifies available software updates according to a unique update identifier;
(f) receiving an update request for metadata corresponding to an available software update from the child update service node, the update request identifying the available software update by its unique update identifier; and (g) returning update metadata corresponding to the software update identified in the update request, the update metadata including information corresponding to the software update including a reference for obtaining the corresponding update payload.
CA002494475A 2004-03-12 2005-01-27 Update distribution system architecture and method for distributing software Withdrawn CA2494475A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/799,351 US7853609B2 (en) 2004-03-12 2004-03-12 Update distribution system architecture and method for distributing software
US10/799,351 2004-03-12

Publications (1)

Publication Number Publication Date
CA2494475A1 true CA2494475A1 (en) 2005-09-12

Family

ID=34827676

Family Applications (1)

Application Number Title Priority Date Filing Date
CA002494475A Withdrawn CA2494475A1 (en) 2004-03-12 2005-01-27 Update distribution system architecture and method for distributing software

Country Status (16)

Country Link
US (1) US7853609B2 (en)
EP (1) EP1575244A3 (en)
JP (1) JP4902120B2 (en)
KR (1) KR101159338B1 (en)
CN (1) CN1668009B (en)
AU (1) AU2005200345B2 (en)
BR (1) BRPI0500134A (en)
CA (1) CA2494475A1 (en)
MX (1) MXPA05001672A (en)
MY (1) MY150140A (en)
NO (1) NO332249B1 (en)
NZ (1) NZ538168A (en)
RU (1) RU2408063C2 (en)
SG (2) SG115728A1 (en)
TW (1) TWI370408B (en)
ZA (1) ZA200501209B (en)

Families Citing this family (106)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7478381B2 (en) * 2003-12-15 2009-01-13 Microsoft Corporation Managing software updates and a software distribution service
US7614051B2 (en) 2003-12-16 2009-11-03 Microsoft Corporation Creating file systems within a file in a storage technology-abstracted manner
US7568195B2 (en) * 2003-12-16 2009-07-28 Microsoft Corporation Determining a maximal set of dependent software updates valid for installation
US7549042B2 (en) * 2003-12-16 2009-06-16 Microsoft Corporation Applying custom software image updates to non-volatile storage in a failsafe manner
US20050132357A1 (en) * 2003-12-16 2005-06-16 Microsoft Corporation Ensuring that a software update may be installed or run only on a specific device or class of devices
US7549148B2 (en) * 2003-12-16 2009-06-16 Microsoft Corporation Self-describing software image update components
BRPI0508244B1 (en) * 2004-03-12 2017-10-10 Microsoft Technology Licensing, Llc Update service node having an application programming interface
US7526534B2 (en) * 2004-07-16 2009-04-28 Cassatt Corporation Unified system services layer for a distributed processing system
JP2006119848A (en) * 2004-10-20 2006-05-11 Fujitsu Ltd Software update program, software update device and software update method
US20060117075A1 (en) * 2004-12-01 2006-06-01 International Business Machines Corporation Prerequisite, dependent and atomic deltas
US8219807B1 (en) 2004-12-17 2012-07-10 Novell, Inc. Fine grained access control for linux services
US8151245B2 (en) 2004-12-17 2012-04-03 Computer Associates Think, Inc. Application-based specialization for computing nodes within a distributed processing system
US8271785B1 (en) 2004-12-20 2012-09-18 Novell, Inc. Synthesized root privileges
US20060153208A1 (en) * 2005-01-11 2006-07-13 Costanzo Francis P Discovery, deployment, and security systems and methods
US7818734B2 (en) * 2005-01-21 2010-10-19 Callwave, Inc. Methods and systems for transferring data over a network
US7490072B1 (en) 2005-02-16 2009-02-10 Novell, Inc. Providing access controls
TWI270789B (en) * 2005-03-03 2007-01-11 Via Tech Inc Method for automatically installing software program
US7716661B2 (en) * 2005-03-16 2010-05-11 Microsoft Corporation Embedded device update service
US20060224623A1 (en) * 2005-04-02 2006-10-05 Microsoft Corporation Computer status monitoring and support
US7634548B2 (en) * 2005-04-02 2009-12-15 Microsoft Corporation Distributed service deliver model
US8352935B2 (en) 2005-05-19 2013-01-08 Novell, Inc. System for creating a customized software distribution based on user requirements
US8074214B2 (en) * 2005-05-19 2011-12-06 Oracle International Corporation System for creating a customized software installation on demand
US8577761B1 (en) * 2005-06-30 2013-11-05 Oracle America, Inc. System and method for dynamic offering topologies
CN100407650C (en) * 2005-11-10 2008-07-30 中国工商银行股份有限公司 Software edition updating system in distributed service system and its method
WO2007067190A2 (en) * 2005-12-06 2007-06-14 Triactive, Inc. Discovery, deployment, and security systems and methods
US7716658B2 (en) * 2005-12-09 2010-05-11 Oracle America, Inc. Method and apparatus for optimizing patching of objects containing references
US7840955B1 (en) * 2005-12-30 2010-11-23 United Services Automobile Association (Usaa) Method and system for restoring software
US8046755B2 (en) * 2005-12-30 2011-10-25 Sap Ag Deploying software based on a calculated deployment risk level
EP1983425A4 (en) * 2006-02-01 2009-03-18 Fujitsu Ltd Object relation display program and object relation display method
DE102006005365A1 (en) * 2006-02-07 2007-08-16 Sick Ag Updating method for firmware of field devices e.g. measuring devices, involves connecting field devices to control unit by common data bus, where firmware is transmitted between all connected field devices by connecting one field device
JP4976021B2 (en) * 2006-02-10 2012-07-18 株式会社リコー Download system, base server and program
US8676973B2 (en) 2006-03-07 2014-03-18 Novell Intellectual Property Holdings, Inc. Light-weight multi-user browser
JP2009536395A (en) * 2006-06-19 2009-10-08 サムスン エレクトロニクス カンパニー リミテッド Information upgrade system and method of OTA-capable terminal {INFORMATIONUPGRADESYSTEMSYSTEMMETHODFORMATA-CAPABLEDEVICE}
US8775572B2 (en) * 2006-06-23 2014-07-08 Microsoft Corporation Public network distribution of software updates
WO2008029261A2 (en) 2006-09-06 2008-03-13 Network Box Corporation Limited A push update system
US8620817B2 (en) * 2006-09-14 2013-12-31 Flexera Software, Inc. Method and system for creating license management in software applications
US8224930B2 (en) * 2006-09-19 2012-07-17 The Invention Science Fund I, Llc Signaling partial service configuration changes in appnets
KR101079592B1 (en) 2006-11-03 2011-11-04 삼성전자주식회사 Display apparatus and information update method thereof
US8056070B2 (en) * 2007-01-10 2011-11-08 Goller Michael D System and method for modifying and updating a speech recognition program
US8224974B1 (en) * 2007-01-29 2012-07-17 Intuit Inc. Method and apparatus for downloading information
US8196134B2 (en) * 2007-02-08 2012-06-05 Microsoft Corporation Network service for a software change catalog
US8762984B2 (en) * 2007-05-31 2014-06-24 Microsoft Corporation Content distribution infrastructure
CN101383720B (en) * 2007-09-05 2011-05-11 大唐移动通信设备有限公司 Software updating method of controlled network element, controlled network element and operation maintaining center
US8214470B2 (en) 2007-11-02 2012-07-03 Telefonaktiebolaget L M Ericsson (Publ) Upgrading software in radio base station nodes
CN101453416A (en) * 2007-11-30 2009-06-10 国际商业机器公司 Service node, network for packet pre-fetching of remote program installation
US8521145B2 (en) * 2008-01-08 2013-08-27 Telefonaktiebolaget L M Ericsson (Publ) Software distribution between radio base stations
WO2009095461A1 (en) * 2008-01-30 2009-08-06 International Business Machines Corporation Method and system of updating a plurality of computers
US8171560B2 (en) * 2008-04-07 2012-05-01 Microsoft Corporation Secure content pre-distribution to designated systems
WO2009137365A1 (en) * 2008-05-05 2009-11-12 Sentilla Corporation, Inc. Efficient broadcast of data in a communication network
US20090288071A1 (en) * 2008-05-13 2009-11-19 Microsoft Corporation Techniques for delivering third party updates
JP5081089B2 (en) * 2008-07-17 2012-11-21 キヤノン株式会社 Broadcast receiving apparatus and control method thereof
JP4826834B2 (en) * 2008-08-07 2011-11-30 日本電気株式会社 COMMUNICATION SYSTEM, CONNECTION DEVICE, INFORMATION NOTIFICATION METHOD, PROGRAM
US8914783B2 (en) * 2008-11-25 2014-12-16 Fisher-Rosemount Systems, Inc. Software deployment manager integration within a process control system
US10387140B2 (en) 2009-07-23 2019-08-20 S3G Technology Llc Modification of terminal and service provider machines using an update server machine
CN101989208A (en) * 2009-08-04 2011-03-23 鸿富锦精密工业(深圳)有限公司 Software updating method
US8996453B2 (en) 2009-09-30 2015-03-31 Red Hat, Inc. Distribution of data in a lattice-based database via placeholder nodes
US9031987B2 (en) * 2009-09-30 2015-05-12 Red Hat, Inc. Propagation of data changes in distribution operations in hierarchical database
US8984013B2 (en) 2009-09-30 2015-03-17 Red Hat, Inc. Conditioning the distribution of data in a hierarchical database
EP2375345A1 (en) * 2010-04-08 2011-10-12 Accenture Global Services Limited System for supplying digital content
US9083762B2 (en) * 2010-05-28 2015-07-14 Greg Saunders System and method for providing hybrid on demand services to a work unit
CN102271146B (en) * 2010-06-04 2016-03-30 中兴通讯股份有限公司 The method and system that a kind of multiple people's net equipment collaboration is downloaded
US9230273B2 (en) 2010-07-28 2016-01-05 International Business Machines Corporation Creation and use of constraint templates
US9122998B2 (en) * 2010-07-28 2015-09-01 International Business Machines Corporation Catalog-based software license reconciliation
US9495710B2 (en) * 2010-09-20 2016-11-15 Sony Corporation Social networking management server
JP5574905B2 (en) * 2010-10-08 2014-08-20 株式会社野村総合研究所 Module distribution system
US9141410B2 (en) * 2011-03-08 2015-09-22 Rackspace Us, Inc. Pluggable allocation in a cloud computing system
US8910142B2 (en) 2011-04-13 2014-12-09 Xerox Corporation Method and system to regulate the electronic availability of application software updates based on information collected regarding installation, usage and support for these updates
US8671185B2 (en) * 2011-05-03 2014-03-11 Facebook, Inc. Data transmission between devices based on bandwidth availability
CA2744165A1 (en) * 2011-06-23 2012-12-23 Ibm Canada Limited - Ibm Canada Limitee Centrally controlled proximity based software installation
US8613101B2 (en) 2011-09-12 2013-12-17 Microsoft Corporation Software distribution service federation
US8959504B2 (en) 2011-10-18 2015-02-17 Microsoft Corporation Update scanning
JP5684173B2 (en) * 2012-03-05 2015-03-11 株式会社東芝 Information processing apparatus and client management method
US9152410B2 (en) * 2012-06-21 2015-10-06 Vaibhav KHANDELWAL Auto-update while running client interface with handshake
US9110755B2 (en) * 2012-08-10 2015-08-18 Microsoft Technology Licensing, Llc Aggregation of update sets
WO2014057305A1 (en) 2012-10-09 2014-04-17 Nokia Corporation Method and apparatus for disabling algorithms in a device
WO2014078992A1 (en) * 2012-11-20 2014-05-30 杭州华为数字技术有限公司 Method and node device for upgrade
CN103020180A (en) * 2012-11-28 2013-04-03 北京奇虎科技有限公司 Control node-based program deploying method and device
US9418072B2 (en) * 2013-03-04 2016-08-16 Vmware, Inc. Cross-file differential content synchronization
US9959107B2 (en) * 2013-06-28 2018-05-01 Samsung Electronics Co., Ltd. Method and apparatus for updating application
KR101491018B1 (en) * 2013-07-10 2015-02-06 에스케이플래닛 주식회사 System for internet service testing using correlation of procedure, method of internet service testing and apparatus for the same
CN103488677B (en) * 2013-07-22 2017-09-22 广州唯品会信息科技有限公司 Project configuration method and apparatus
US10489132B1 (en) * 2013-09-23 2019-11-26 Sprint Communications Company L.P. Authenticating mobile device for on board diagnostic system access
RU2571726C2 (en) * 2013-10-24 2015-12-20 Закрытое акционерное общество "Лаборатория Касперского" System and method of checking expediency of installing updates
US9971987B1 (en) * 2014-03-25 2018-05-15 Amazon Technologies, Inc. Out of order data management
CN104301383A (en) * 2014-09-05 2015-01-21 小米科技有限责任公司 Upgrading method, device and upgrading equipment
US9619244B2 (en) 2014-09-05 2017-04-11 Xiaomi Inc. Method and system for upgrading an electronic device
CN104537456A (en) * 2014-12-02 2015-04-22 成都万象天龙科技有限公司 Control system based on purchase-sale-storage system and provided with encryption control function, and control method based on purchase-sale-storage system
CN104537455A (en) * 2014-12-02 2015-04-22 成都万象天龙科技有限公司 Control system based on purchase-sale-storage system and provided with encryption function, and control method based on purchase-sale-storage system
CN104504496A (en) * 2014-12-02 2015-04-08 成都万象天龙科技有限公司 Control system and control method based on purchase-sell-stock system
CN105005487B (en) * 2015-06-29 2018-06-22 清华大学 A kind of High-Performance Computing Cluster operating system online upgrading method of continuous service
CN105204915A (en) * 2015-10-29 2015-12-30 小米科技有限责任公司 Application program updating method, device and system
US20170344355A1 (en) * 2016-05-27 2017-11-30 GM Global Technology Operations LLC Updating vehicle system modules
RU2649292C2 (en) * 2016-06-24 2018-03-30 Акционерное общество "Лаборатория Касперского" Method of generation a list of update agents
US20180018161A1 (en) * 2016-07-13 2018-01-18 Blackberry Limited Updating firmware at enterprise devices
RU2634183C1 (en) 2016-09-08 2017-10-24 Акционерное общество "Лаборатория Касперского" Method of newsletter of updates
US10089661B1 (en) * 2016-12-15 2018-10-02 Amazon Technologies, Inc. Identifying software products to test
JP6584440B2 (en) 2017-01-27 2019-10-02 キヤノン株式会社 Information processing system, information processing system control method, and program thereof
US10001986B1 (en) * 2017-02-09 2018-06-19 International Business Machines Corporation Updating software instances
FR3067149B1 (en) * 2017-05-30 2021-11-12 Electricite De France HIERARCHIZED UPDATE OF EQUIPMENT SOFTWARE OF AN ELECTRICAL DISTRIBUTION NETWORK
US10365910B2 (en) * 2017-07-06 2019-07-30 Citrix Systems, Inc. Systems and methods for uninstalling or upgrading software if package cache is removed or corrupted
CN108390914B (en) * 2018-01-23 2020-07-28 阿里巴巴集团控股有限公司 Service updating method, device and system
EP3770422A1 (en) * 2019-07-23 2021-01-27 Siemens Gamesa Renewable Energy A/S Updating software and/or firmware of a plurality of wind turbine devices
US11720372B2 (en) * 2019-12-04 2023-08-08 Vmware, Inc. Managing the creation and execution of update campaigns in an multitenancy hierarchy
US20220138352A1 (en) * 2020-11-05 2022-05-05 EMC IP Holding Company LLC Multi-Cloud Framework for Data Protection Using Threshold-Based File Reconstruction
US11507366B1 (en) 2021-06-22 2022-11-22 Microsoft Technology Licensing, Llc Dynamically controlled check-in frequency for an update management system
TWI768989B (en) * 2021-06-28 2022-06-21 神達數位股份有限公司 Data updating method and assistance system

Family Cites Families (92)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0792744B2 (en) * 1990-08-20 1995-10-09 インターナショナル・ビジネス・マシーンズ・コーポレイション A method of installing multi-level application software on a data processing device.
SE513182C2 (en) * 1991-06-12 2000-07-24 Icl Systems Ab Procedure and system for auditing data in a distributed computer system
DE69230452T2 (en) * 1991-08-19 2000-08-24 Sun Microsystems Inc Change control method and apparatus in multiple development environments
WO1994025913A2 (en) * 1993-04-30 1994-11-10 Novadigm, Inc. Method and apparatus for enterprise desktop management
US5860012A (en) * 1993-09-30 1999-01-12 Intel Corporation Installation of application software through a network from a source computer system on to a target computer system
US5835911A (en) * 1994-02-08 1998-11-10 Fujitsu Limited Software distribution and maintenance system and method
US5845090A (en) * 1994-02-14 1998-12-01 Platinium Technology, Inc. System for software distribution in a digital computer network
GB9412553D0 (en) * 1994-06-22 1994-08-10 At & T Global Solutions Intern Method and apparatus for distributing software
US5491820A (en) * 1994-11-10 1996-02-13 At&T Corporation Distributed, intermittently connected, object-oriented database and management system
US5787153A (en) * 1995-09-29 1998-07-28 Unisys Corporation System for incremental redistribution of telephony applications computing workload
US5845077A (en) * 1995-11-27 1998-12-01 Microsoft Corporation Method and system for identifying and obtaining computer software from a remote computer
US5706431A (en) 1995-12-29 1998-01-06 At&T System and method for distributively propagating revisions through a communications network
US6049671A (en) * 1996-04-18 2000-04-11 Microsoft Corporation Method for identifying and obtaining computer software from a network computer
JPH09305675A (en) 1996-05-20 1997-11-28 Nec Corp System for distributing general-purpose application
US6151643A (en) * 1996-06-07 2000-11-21 Networks Associates, Inc. Automatic updating of diverse software products on multiple client computer systems by downloading scanning application to client computer and generating software list on client computer
US6237020B1 (en) * 1996-10-01 2001-05-22 International Business Machines Corporation Task-oriented automatic distribution of software
US5933647A (en) * 1997-01-24 1999-08-03 Cognet Corporation System and method for software distribution and desktop management in a computer network environment
JPH10269085A (en) * 1997-03-27 1998-10-09 Tec Corp Program updating method for satellite computer
US6314565B1 (en) * 1997-05-19 2001-11-06 Intervu, Inc. System and method for automated identification, retrieval, and installation of multimedia software components
US6055363A (en) * 1997-07-22 2000-04-25 International Business Machines Corporation Managing multiple versions of multiple subsystems in a distributed computing environment
AU2204699A (en) * 1997-12-24 1999-07-19 Qualcomm Incorporated Method and system for software version management in a network management system
US6035423A (en) * 1997-12-31 2000-03-07 Network Associates, Inc. Method and system for providing automated updating and upgrading of antivirus applications using a computer network
US6094679A (en) * 1998-01-16 2000-07-25 Microsoft Corporation Distribution of software in a computer network environment
US6192518B1 (en) * 1998-01-22 2001-02-20 Mis Only, Inc. Method for distributing software over network links via electronic mail
GB2333864B (en) 1998-01-28 2003-05-07 Ibm Distribution of software updates via a computer network
US6202207B1 (en) * 1998-01-28 2001-03-13 International Business Machines Corporation Method and a mechanism for synchronized updating of interoperating software
US7080371B1 (en) * 1998-03-03 2006-07-18 Siebel Systems, Inc. Method, system, apparatus and program product for distribution and instantiation of software upgrades
US6167567A (en) * 1998-05-05 2000-12-26 3Com Corporation Technique for automatically updating software stored on a client computer in a networked client-server environment
US6330715B1 (en) * 1998-05-19 2001-12-11 Nortel Networks Limited Method and apparatus for managing software in a network system
SE514762C2 (en) 1998-05-28 2001-04-23 Ericsson Telefon Ab L M Method, device and portable terminal for software download in a wireless network and such telecommunication network
US6799277B2 (en) * 1998-06-04 2004-09-28 Z4 Technologies, Inc. System and method for monitoring software
US6353926B1 (en) * 1998-07-15 2002-03-05 Microsoft Corporation Software update notification
US7073172B2 (en) * 1998-09-21 2006-07-04 Microsoft Corporation On demand patching of applications via software implementation installer mechanism
US6289511B1 (en) * 1998-09-29 2001-09-11 Telephonaktiebolaget Lm Ericsson Method and system for distributing software in a telecommunications network
US6301708B1 (en) * 1998-11-12 2001-10-09 Hewlett-Packard Company Software installation process using abstract data and program files
US6938075B1 (en) 1998-12-24 2005-08-30 Computer Associates Think, Inc. Method and apparatus for hierarchical software distribution packages including composite packages
US6408434B1 (en) * 1999-01-07 2002-06-18 Sony Corporation System and method for using a substitute directory to automatically install an update program
US6725377B1 (en) * 1999-03-12 2004-04-20 Networks Associates Technology, Inc. Method and system for updating anti-intrusion software
US6385766B1 (en) * 1999-05-20 2002-05-07 Dell Usa L.P. Method and apparatus for windows-based installation for installing software on build-to-order computer systems
AU768653B2 (en) 1999-08-16 2003-12-18 Telefonaktiebolaget Lm Ericsson (Publ) Method of distributing software updates in an event-driven network
JP3671759B2 (en) * 1999-08-26 2005-07-13 株式会社日立製作所 Software distribution method and system
US6493871B1 (en) * 1999-09-16 2002-12-10 Microsoft Corporation Method and system for downloading updates for software installation
EP1107108A1 (en) * 1999-12-09 2001-06-13 Hewlett-Packard Company, A Delaware Corporation System and method for managing the configuration of hierarchically networked data processing devices
US7191208B1 (en) * 1999-12-14 2007-03-13 International Business Machines Corporation Methods of selectively distributing data in a computer network and systems using the same
US6754678B2 (en) * 1999-12-20 2004-06-22 California Institute Of Technology Securely and autonomously synchronizing data in a distributed computing environment
FR2809839A1 (en) 1999-12-30 2001-12-07 Thomson Multimedia Sa METHOD FOR DOWNLOADING DATA PROCESSED BY ADVERTISEMENT SIGNALS
US6615405B1 (en) * 2000-01-06 2003-09-02 Power Quest Corporation Method and system for distributing and maintaining software across a computer network
JP2001222424A (en) * 2000-02-08 2001-08-17 Fujitsu Ltd Software license managing device and method, and program recording medium for managing software license
JP2001265603A (en) * 2000-03-22 2001-09-28 Nec Corp Automatic division software distribution system and method therefor
US6618857B1 (en) * 2000-03-27 2003-09-09 Microsoft Corporation Method and system for installing software on a computer system
US6549914B1 (en) * 2000-05-17 2003-04-15 Dell Products, L.P. System and method for statistical file preload for factory installed software in a computer
US6912711B1 (en) * 2000-05-25 2005-06-28 International Business Machines Corporation Method of applying an update to a contained collection of program and data files based upon versions
US6701521B1 (en) * 2000-05-25 2004-03-02 Palm Source, Inc. Modular configuration and distribution of applications customized for a requestor device
JP2002007255A (en) * 2000-06-27 2002-01-11 Nec Corp Method for managing distribution destination of downloading
KR100455566B1 (en) * 2000-06-30 2004-11-09 인터내셔널 비지네스 머신즈 코포레이션 Device and method for updating code
JP3666796B2 (en) * 2000-07-14 2005-06-29 日本電信電話株式会社 Download method in data distribution system and storage medium storing program thereof
GB0017336D0 (en) * 2000-07-15 2000-08-30 Ibm Preferable modes of software package deployment
WO2002025438A1 (en) * 2000-09-22 2002-03-28 Patchlink.Com Corporation Non-invasive automatic offsite patch fingerprinting and updating system and method
US20020075824A1 (en) * 2000-12-14 2002-06-20 Willekes Tom J. System and method for distributing files in a wireless network infrastructure
US7143406B2 (en) * 2001-01-23 2006-11-28 Wildtangent, Inc. Asynchronous software update
US7140012B2 (en) * 2001-03-09 2006-11-21 Bea Systems, Inc. Method and apparatus for multi-version updates of application services
US20040015961A1 (en) * 2001-03-19 2004-01-22 International Business Machines Corporation Method and apparatus for automatic prerequisite verification and installation of software
US6957426B2 (en) * 2001-04-05 2005-10-18 Hewlett-Packard Development Company L.P. Independent tool integration
US6976251B2 (en) * 2001-05-30 2005-12-13 International Business Machines Corporation Intelligent update agent
US6954928B2 (en) * 2001-08-08 2005-10-11 Hewlett-Packard Development Company, L.P. Method for selecting a set of patches to update a system of programs
US20030037325A1 (en) * 2001-08-17 2003-02-20 Hargrove David C. System and methods for automatically installing a correct software version from media containing multiple software versions
US6535924B1 (en) * 2001-09-05 2003-03-18 Pluris, Inc. Method and apparatus for performing a software upgrade of a router while the router is online
US7003767B2 (en) * 2001-10-02 2006-02-21 International Business Machines Corp. System and method for remotely updating software applications
DE10148877A1 (en) * 2001-10-04 2003-04-30 Siemens Ag Method for distributing data in a data network
JP2003150342A (en) * 2001-11-13 2003-05-23 Seiko Epson Corp Driver management system
JP2005510790A (en) * 2001-11-28 2005-04-21 ボウ・ストリート・ソフトウェア・インコーポレーテッド Method and apparatus for creating software objects
CN1350230A (en) 2001-12-03 2002-05-22 复旦大学 Active virus library distribution system
NO20021247D0 (en) * 2002-03-13 2002-03-13 Ericsson Telefon Ab L M Software upgrade method and system
US20030200300A1 (en) * 2002-04-23 2003-10-23 Secure Resolutions, Inc. Singularly hosted, enterprise managed, plural branded application services
US20040006586A1 (en) 2002-04-23 2004-01-08 Secure Resolutions, Inc. Distributed server software distribution
JP3810343B2 (en) * 2002-05-24 2006-08-16 三菱電機株式会社 Video system, video device, software installation method, program for executing the method, and recording medium storing the program
US20040031029A1 (en) * 2002-08-06 2004-02-12 Kyu-Woong Lee Methods and systems for automatically updating software components in a network
US7370092B2 (en) * 2002-09-12 2008-05-06 Computer Sciences Corporation System and method for enhanced software updating and revision
US20040059703A1 (en) * 2002-09-23 2004-03-25 Jerry Chappell Cascading behavior of package generation/installation based on variable parameters
JP4408033B2 (en) * 2002-09-24 2010-02-03 株式会社リコー Remote management system
US7664984B2 (en) * 2002-10-09 2010-02-16 Xpoint Technologies, Inc. Method and system for updating a software image
US20040076166A1 (en) * 2002-10-21 2004-04-22 Patenaude Jean-Marc Guy Multi-service packet network interface
US20040088700A1 (en) * 2002-10-31 2004-05-06 Chung-I Lee System and method for automatically installing software on client computers via a network
US7814476B2 (en) * 2002-10-31 2010-10-12 Oracle America, Inc. Systems and methods for updating software
US7096464B1 (en) * 2002-12-02 2006-08-22 Sap Aktiengesellschaft Software update method and apparatus
US7181739B1 (en) * 2003-03-14 2007-02-20 Novell, Inc. Installation relationship database
US20070061154A1 (en) * 2003-11-14 2007-03-15 Koninklijke Philips Electronics N.V. Product data exchange
US7546594B2 (en) * 2003-12-15 2009-06-09 Microsoft Corporation System and method for updating installation components using an installation component delta patch in a networked environment
US20050172284A1 (en) * 2004-01-30 2005-08-04 Dandekar Shree A. Method and system for automated generation of customized factory installable software
US20070180490A1 (en) * 2004-05-20 2007-08-02 Renzi Silvio J System and method for policy management
US20060130045A1 (en) * 2004-11-19 2006-06-15 Jonathan Wesley Systems and methods for dynamically updating computer systems
US7937697B2 (en) * 2005-05-19 2011-05-03 International Business Machines Corporation Method, system and computer program for distributing software patches

Also Published As

Publication number Publication date
SG115728A1 (en) 2005-10-28
KR101159338B1 (en) 2012-09-07
BRPI0500134A (en) 2005-11-01
AU2005200345A1 (en) 2005-09-29
NZ538168A (en) 2006-08-31
JP4902120B2 (en) 2012-03-21
MXPA05001672A (en) 2005-09-22
EP1575244A3 (en) 2006-06-21
NO332249B1 (en) 2012-08-06
NO20050547D0 (en) 2005-02-01
AU2005200345B2 (en) 2010-04-29
NO20050547L (en) 2005-09-13
RU2408063C2 (en) 2010-12-27
SG136135A1 (en) 2007-10-29
JP2005259114A (en) 2005-09-22
CN1668009A (en) 2005-09-14
TW200530847A (en) 2005-09-16
KR20050091999A (en) 2005-09-16
US20050203968A1 (en) 2005-09-15
ZA200501209B (en) 2006-10-25
EP1575244A2 (en) 2005-09-14
TWI370408B (en) 2012-08-11
RU2005101832A (en) 2006-07-10
US7853609B2 (en) 2010-12-14
MY150140A (en) 2013-11-29
CN1668009B (en) 2010-10-13

Similar Documents

Publication Publication Date Title
US7853609B2 (en) Update distribution system architecture and method for distributing software
AU2005222887B2 (en) Application programming interface for administering the distribution of software updates in an update distribution system
US7539686B2 (en) Tag-based schema for distributing update metadata in an update distribution system
IL166812A (en) Update distribution system architecture and method for distributing software
MXPA06010207A (en) Application programming interface for administering the distribution of software updates in an update distribution system

Legal Events

Date Code Title Description
EEER Examination request
AZWI Withdrawn application

Effective date: 20130123