MXPA06010207A - Application programming interface for administering the distribution of software updates in an update distribution system - Google Patents

Abstract

An application programming interface (API) for administering the distribution of software updates on an update service node is presented. The API provides a plurality of interface calls through which an administrator can establish rules by which software updates available to the update service node are distributed.

Description

APPLICATION PROGRAMMING INTERFACE FOR MANAGE THE DISTRIBUTION OF UPDATES OF SOFTWARE IN A DISTRIBUTION SYSTEM UPGRADE FIELD OF THE INVENTION The present invention relates to software and computer networks, and, in particular, the present invention relates to an application programming interface for managing the distribution of software updates in an update distribution system.

BACKGROUND OF THE INVENTION Almost all commercially available software products undergo a continuous review procedure to repair or update software features. Each revision of a software product often requires adding new files, replacing existing files with newer revisions, deleting obsolete files, or various combinations of these actions. This procedure of replacing older files, adding new files, and deleting obsolete files from a software product can be referred to hereinafter as "updating the product", and the collection of data, which includes binary files, data files, instructions update, metadata, database data, system registry settings, security settings, and the like, used when updating the product will be referred to here later more simply as an "update". Once a software vendor has created an update for a software product, whether to fix a problem, improve security, or add new features, the software vendor will want to make that update more widely available to its customer base. Frequently, such as when the update is aimed at correcting a defect in the product or addressing a critical security issue, the software provider will want that update installed on the clients' computers as soon as possible. In fact, most software vendors have a business incentive to distribute software updates to their customers as quickly and as easily as possible. The computer industry has experienced 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 capabilities available through the Internet connection, 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. Frequently, software vendors' increased interest in distributing software updates on the Internet, such as electronic update distribution on the Internet, reduces their total costs and allows customers to obtain software updates as soon as they become available. More and more frequently, these software updates are automatically conducted on the Internet, without any user intervention. While the Internet is now commonly used as a driver to distribute software updates from software vendors, several issues frequently arise. Two such issues include (1) efficiency that relates to infrastructure / distribution distribution resources, and (2) administrative control over distribution and installation of software updates. With respect to the efficiency of distribution resources, networks, which include the Internet, possess only a finite amount of communication resources, often referred to as bandwidth. A cynical amount of communication bandwidth frequently results in bottlenecks, especially with respect to software updates for popular software products, such as the Microsoft Corporation's Windows® family of operating systems and related productivity products. Such bottlenecks exist even when software updates are made available in multiple download locations distributed over the Internet. One reason such bottlenecks occur is the unstructured access model made available on the Internet. For example, if a first user on computer A requests the last download of a software product, the download will pass through the independent service provider (ISP) of the first user. In addition, the request was treated as a single individualized access which means that the request is treated separately from, and not related to, any other traffic and / or network request. As such, if a second user on computer B, which also has the same ISP, requests the same download as the first user, the request of the second user is also treated as a single individualized access. In this example, the same download will be transmitted on 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 rare, it would be much more efficient and the download would have been trapped in a local location, and the user request from the local cache would have been fulfilled. With respect to distribution control, 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, often called insects, that "break" features of a software product. These broken features may be insignificant, but they can very often interrupt mission critical business features. As a business can not bear to lose its mission critical characteristics, a responsible business will first evaluate and test each software update within a controlled environment for some period of time before releasing the update to the rest of its computers. This evaluation period allows the organization to validate whether an update will adversely accept a mission critical characteristic. Right after it was successfully determined that an update did not collapse any mission-critical feature, the update is allowed to be distributed to the rest of the organization's computers. Clearly, most organizations should exercise control over the installation of software updates on their computers. Another reason that a business or organization frequently needs to control distribution of software updates is to ensure consistency between the computers in the organization. It is very important for information service departments to have a standardized objective platform on which all computers operate, whether for a word processor or an operating system. Without standard software and computer maintenance it can be unnecessarily complex and difficult.

Even another reason why 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, an individual site license allows an organization to run a software product on numerous computers. That way, an organization may be required to report the number of computers that run a product under the site license, or may need to limit the number of computers that run a product under a site license. All of these reasons often require local control over software update distribution. In view of the several issues identified above that relate to software update distribution, what is needed is an extensible software update distribution architecture to provide control over the distribution of software updates, as well as increase its distribution efficiency . The present mention addresses these and other matters found in the prior art.

BRIEF DESCRIPTION OF THE INVENTION In accordance with aspects of the present and reference, an update service node is presented having an application programming interface for managing the distribution of software updates in the update service node. The update service node includes an update storage to store software updates. The update service node also includes 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 service node update distributes software updates to child update service nodes over the communication network. In addition, the update service node includes an administration application programming interface (API) through which an administrator establishes controls for the distribution of software updates to child update service nodes and client computers, in where the administration API is an object that exposes a plurality of interface calls through which the administrator establishes said rules. In accordance with additional aspects of the present invention, an application programming interface (API) is presented to manage the distribution of software updates in an update service node. The API comprises an interface call to obtain configuration that returns a configuration interface object to read and write software update management configuration settings to the update service node. The API further comprises a subscription-obtaining interface call that returns a subscription interface object defined in the update service node. The API further comprises an interface call to obtain update that returns an update interface object corresponding to a refresh identifier passed in the update interface call, as well as an interface call to obtain updates that returns an object of update. update collection that contains an update interface object that corresponds to values passed in the call to obtain updates. The API also comprises an interface call obtaining a computer that returns a client computer object corresponding to the client computer associated with the update service node and which was identified in the computer interface obtaining call, and a call interface for obtaining computers that returns a computer collection object that includes client computer objects that correspond to client computers associated with the update service node. Additionally, the API comprises a get group interface call that returns a target group object that was identified in the group get interface call, and a group get interface call that returns a target group collection object that includes Target group objects that correspond to target groups in the update service node.

In accordance with even other aspects of the present invention, a software update distribution system for distributing software updates is presented. The software update distribution system comprises an update service node and an administration application programming (API) interface associated with the update service node. The administration API is an interface object that exposes a plurality of interface calls to control the distribution of software updates. The administration API includes a get configuration interface call that returns a configuration interface object to read and write software update management configuration settings to the update service node. The API also includes a call to obtain a subscription that returns a subscription interface object defined in the update service node. The API also includes an update interface call that returns an update interface object that corresponds to an update identifier passed in the update interface call, as well as an interface call to obtain updates that returns an object from the update interface. update collection that contains update interface objects that correspond to values passed in the interface call to obtain updates. The API also includes a call to obtain a computer that returns a client computer object that corresponds to a client computer associated with the update service node and that was identified in the call to obtain a computer, and an interface call to obtain computers that returns a computer collection object that includes client computer objects that correspond to client computers associated with the update service nodes. Additionally, the API includes a group get interface call that returns a target group object that was identified in the group get interface call, and a group get call request that returns a target group collection object which includes target group objects that correspond to target groups in the update service node.

BRIEF DESCRIPTION OF THE DRAWINGS The above aspects and many of the pending advantages of this invention will be more fully appreciated while they are 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 illustrative update distribution system formed in accordance with aspects of the present invention; Figure 2 is a block diagram illustrating illustrative logical components of an update service node formed in accordance with aspects of the present invention; Figure 3 is a block diagram illustrating illustrative 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 illustrative exchange between a parent update service node and a child update service node when providing a software update of the parent update service node to the child update service node of according to aspects of the present invention; Figure 5 is a flow chart illustrating an exemplary routine executed at a child update service node to periodically obtain updates from its parent update service node; Figure 6 is a flow chart of an illustrative subroutine suitable for use in the illustrative routine of Figure 5 to obtain an update catalog of a parent update service node; Figure 7 is a flowchart of an illustrative subroutine for use in the illustrative routine of Figure 5 to obtain a software update of a parent update service node; Figure 8 is a flowchart of an illustrative routine for processing an update request from a child update service node; Figure 9 is a pictorial diagram to illustrate how the administration API is used with respect to configuring an update service node to distribute software updates to client computers; and Figure 10 is a block diagram illustrating certain management API calls to manage the distribution of software updates at an update service node.

DETAILED DESCRIPTION OF THE PREFERRED MODALITY In accordance with aspects of the present invention, an update distribution system, organized in a hierarchical manner, for distributing software updates is presented. Figure 1 is a pictorial diagram of an illustrative 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 provider software 110, distribute their software updates through the update distribution system 100 by sending the updates to the root update service node 102. In accordance with aspects of the present invention, software providers, such as software vendor 110, they can send their software updates to the root update service node 102 through a network, such as Internet 108. A hierarchical update distribution system, such as the illustrative update 100 distribution system, will likely include the minus another update service node in addition to the root update service node 102. As illustrated in Figure 1, the illustrative update distribution system 100 includes the root update service node 102 and two additional update service nodes: update service node 104 and update service node 106. In accordance with the present invention, each hierarchical update distribution system is organized into a structure as a tree under 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 exery update distribution system 100 shows that each parent update service node, i.e. the root update service node 102 and update service node 104, has only one child, it is only for purposes of illustration, and should not be construed as limiting the present invention. In addition, with the exception of the root update service node 102, each update service node in an update distribution system has a parent update service node. Accordingly, as shown in Figure 1, the update service node 104 is a child node for the root update service node 102, and update service node 106 is a child node for the service node 104. As can be seen, each update service node, with the exception of the root update service node 102, can be either a child update service node or a parent update service node. As illustrated in the illustrative update distribution system 100, the root update service node 102 communicates with the update service node 104 via Internet 108. However, it should be understood that this is illustrative only, and it should not be construed as limiting the present invention. Each update service node in an update distribution system only needs to be able to communicate with its parent and / or child through some communication network. Thus, while the update service node 104 communicates with its parent, root update service node 102, through Internet 108, it can alternatively communicate with its child update service nodes, such as service node. update 106, through a local network area 124. Also as shown in Figure 1, the update service node 106 resides within a sub-network 126 of the local area network 124. As an exa, the local area network 124 may correspond to a general organizational corporation network, and the update service node 104 represents the corporation link to the update distribution system 100, through its connection to its parent, node of root update service 102. In addition, sub-network 126 may correspond to an identifiable group of computers within the corporation network, such as a test / evaluation group, a remotely located office, or a mission critical group. As will be described in more detail below, in accordance with aspects of the present invention, an administrator in update service node 104 is able to control the distribution of updates for update service node 106, and finally to client computers. It should be appreciated that each update service node, which includes both the root update service node 102 and the update service nodes 104 and 106, is configured to distribute software updates to both child update service nodes as well. as to client computers. As shown in Figure 1, the illustrative update distribution system 100 includes client computers 112-122. Each update service node, which includes the root update service node 102, distributes updates to child update service nodes and client computers in accordance with local configuration information. According to a modality, an administrator defines groups and associates update distribution rules with these groups. Each update service node has at least one distribution group. As an example to illustrate how the update distribution system operates, it is assumed that the local area network 124 corresponds to a business organization corporation network. According to one embodiment of the present invention, an administrator, an update service node 104, can define multiple distribution groups for the corporation network 124, which includes an evaluation group, which corresponds to the sub-network 126 that includes update service node 106 and client computers 120 and 122, to evaluate the adequate capacity of an update for the general corporation network 124, as well as a general corporation group that includes the update service node 104 and client computers 114-118.

With respect to the evaluation group, the administrator includes the update service node 106 as a member, and associates rules with that group so that the updates are immediately distributed to the members of the evaluation group as long as they become available. Alternatively, with respect to the general corporation group, the administrator adds client computers 114-118, and associates a rule so that updates are only distributed to members of the general corporation group if specifically authorized by the administrator. It is also assumed that an administrator for child update service node 106 creates a predetermined group consisting of client computers 120 and 122 in evaluation sub-network 126, so that they are immediately distributed to any new software update. Continuing with the previous example, a software provider 110 sends a software update to the root update service node 102. According to the rules set in the root update service node 102, the update is eventually distributed to the service node of updating of corporation 104. Upon receiving the update, by the rules established by the administrator, the corporation update service node 104 distributes the update to the members of the evaluation group (defined only as the child update service node 106 ), but supports the update of the general corporation group that depends on specific authorization to distribute the update to that group. Continuing with the previous 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 a real implementation, there may be multiple defined groups, each with a unique group 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. The client computers 120 and 122 can now be updated and the evaluation period / procedure can begin. Even continuing with the previous example, when the administrator in the corporation update service node 104 is sufficiently satisfied that the update is suitable for distribution over the entire corporation network 124, then the administrator explicitly authorizes the update to be distributed to the members of the general corporation group. The corporation update service node 104 correspondingly makes the update available to the client computers 114-118. It should be understood that evaluation update service nodes 106 can also be included in the general corporation group. However, because the evaluation update service node 106 has already been updated, no action related to additional update is needed to distribute the update to evaluation sub-network 126. As can be seen from the previous example, the present invention offers significant benefits in terms of local distribution control and discharge efficiency. In addition to the above-described aspects of local distribution control, significant savings in communication bandwidth are also realized. For example, while the illustrative corporation network 124 illustrated in Figure 1 includes five client computers, the software vendor update was downloaded from the root update service node 102 to the corporation update service node 104 only once. After clearly, while the number of client computers provided with service by an update service node increases, the use of communication bandwidth between a parent update service node and a client update service node remains constant, thereby substantially reduces the amount of communication bandwidth that would otherwise be used. Additionally, the update distribution system is both extensible and classifiable. The update distribution system is extensible in at least two ways: any member of the child update service node can be added to a parent update service node, and child update service nodes can also be a child service node. father update. Each sub-tree of the update distribution system can therefore be configured to meet individual needs. Figure 2 is a block diagram illustrating illustrative logical components of an update service node 200, such as the corporation 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 report module 208. The service node of Illustrative update 200 also includes an authentication / authorization module 210, an administration application programming interface (API) 212, an update content storage 214, an administration user interface 218, and a storage of update information 216 The web update service 202 provides a common pool of Web services through which 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 update / evaluation service node 106 to obtain a software update from the parent / corporation update service node 104, the client communicates through the web service of the client. parent update 202. Similarly, when a parent update service node, such as root update service node 102, has information, including updates, to communicate its child update service node 104, the update service node The parent communicates through the web update service 202. In a real embodiment of the present invention, the common group of Web services provided by the web update service 202, generally referred to as a web services interface, includes the following calls : ObtainAutoConfigServer to have authentication configuration information of a parent update service node; GetConfigData and GetServerConfigDatps to obtain configuration information of parent update server nodes and properties; Obtain Cookie Server to obtain an authorization signal from a parent update service node; Obtain ListListReview to obtain an update list of a parent update service node; GetDataUpdate to obtain update metadata and update payloads from a parent update service node; and ReportEvents to report the update activity that occurred in an update service node to its parent update service node. The client update module 204 controls communications between a client computer and the update service node 200 with respect to updates and update information stored in the update service node. Communications related to updating 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's computer. The client update module 204 is also responsible for determining whether a client computer is authorized to obtain a particular update in accordance with associated distribution rules, and responds to a client computer with information related to updating the client computer is authorized to access.

The child update module 206 controls update related communications between a parent update service node and its child update service nodes. Communications related to updating 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 in accordance with distribution rules, and responds to a child update service node with information related to update that the child update service node is authorized to access. The report module 208 generates reports related to updating, such as which groups have received or not a particular update, which client computers have or have not downloaded / installed an update, what updates are available in the update service node, and the like . These reports can be used internally, such as by an administrator, and also sent to the parent update service node, through the parent update service interface 202. As described above, if it is frequently needed 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 208 reporting module can 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 updates available on update service node 200. For those client computers and child update service nodes that are authenticated or authorized to access updates on an update service node, the authentication / authorization module 210 issues an authorization signal that must be used in conjunction with obtaining updates. The issuance and use of an authorization signal is described in more detail below with respect to Figures 4A and 4B. Administration API 212 represents the application interface through which control of update service node 200 is exercised, and through which updates are finally stored and distributed. When update web service 202 receives several requests related to update of client computers and child update service nodes, these requests are finally decomposed into calls in administration API 212, either directly or indirectly through the update module client 204 and the child update module 206. In conjunction with the administration user interface 218 or some other program installed in the update service node 200 suitably configured to use the administration API 212, an administrator finally controls all the aspects of the update procedure for that update service node, as well as any of the child update service nodes and client computers. A real embodiment of an administration API is attached as an appendix to this specification, and is described in more detail below with respect to Figures 9-XX. Through the administration user interface 218, administrators can configure and maintain an update service node 200, through the administration API 212. In that way, through the administration user interface 218, an administrator creates, modifies, and deletes groups, as well as associates rules for each group. In addition, by 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 can explicitly authorize the distribution of updates to client computers or child update service nodes, configure the update service node 200 to periodically consult its parent update service node for new updates, configure report parameters and internal sight reports, and the like. As mentioned above, while the administration user interface 218 allows an administrator to exercise control over aspects of the update service node 200, another application that resides in the update service node 200, suitably adapted to operate with the API of administration 212 may be used instead of the administration user interface 218. As mentioned above, in accordance with one embodiment of the present invention, an update service node 200 includes both a storage of update content 214 and an update storage 216. The storage of update content 214 stores the actual files representing software updates, such as binary or patch files. In contrast, the update information store 216 stores information and metadata corresponding to the updates available in the update service node 200, which includes the update files stored in the update content storage 214. According to a mode , the storage of update content 214 and storage of update information 216 are both relationship databases. While the illustrative update service node 200 is shown having two data stores, the present invention should not be limited. In an alternative mode, ta >The storage of update content 214 and storage of update information 216 can be combined with a storage of individual information. In accordance with aspects of the present invention, a software update may be presented as being "available" at an update service node 200 for client computers and child update service nodes even though the update is not physically stored in the storage of update content 214. More particularly, rather than downloading and immediately storing the actual update files in an update service node 200, a link referring to the update files in the parent update service node or in some other place, instead it can be stored in 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 downloaded from the parent update service node and stored in the update content storage 214, in preparation for delivery to the client computer or child update service node. Those skilled in the art will recognize that this type of update access is referred to as just-in-time download. In this way, an "available" update does not need to be distributed in the various network channels until it is actually requested. In accordance with aspects of the present invention, an administrator of an update service node 200 can selectively determine if he obtains software updates in a just-in-time manner. While the above description of Figure 2 illustrates various components of an illustrative update service module 200, it should be appreciated that other components of an update service module may also exist. In addition, the components described above must be understood to be logical components, not necessarily real components. In a real implementation, the components identified above may be combined and / or together with other components according to the implementation determinations. Additionally, it should be appreciated that while an update service node 200 can be viewed as a server computer in a network, in a real implementation, an update service node can be implemented in any number of types of computing devices. For example, each update service node 200 may be implemented and / or installed in an isolated computer system or, alternatively, in a distributed computing system comprising multiple computing devices. Figure 3 is a block diagram illustrating illustrative 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 illustrative root update service node 300 also includes an administration API 212, an update content store 214, and an update information storage 216. Optionally, the root update service node 300 may also include a client update module 204, a report module 208, and an administration user interface 218. The client update module 204 is an optional component for a root update service node 300 that depends on whether the service node Root Update 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 serves the client computer 112. However, if a node of root update service 300 does not directly serve the client computers, the client update module 204 could be omitted. Report module 208 is optional from a root update service node 300 because an update service node root does not have a parent update service node for which update reports are provided. However, to the extent that update reports are desirable for the root update service node administrator, the report module 208 may optionally be included. In addition to understanding 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 through which a software provider 110 (Figure 1) sends software updates directly to the root update service node 300, and indirectly to the illustrative update distribution system 100. Similar to the update service node 200 of the Figure 2, The above description of Figure 3 illustrates various components of an illustrative root update service module 300. However, it should be appreciated that other components of a root update service module may also exist. In addition, the components described above must be understood to be logical components, not necessarily real components. In a real implementation, the components identified above may be combined together and / or with other components according to implementation determinations. Additionally, it should be appreciated that while the root update service node 200 can be viewed as a server computer in a network, in a real implementation, an update service node can be implemented in any number of computing devices. For example, the root update service node 300 may be implemented and / or installed in an individual isolated computer system or, alternatively, in a distributed computing system comprising multiple computing devices. In order to better understand how an update of the root update service node is distributed through an update distribution system 100, an illustration of an illustrative exchange between a parent update service node and a service node is guaranteed. of update son. Figure 4 is a block diagram illustrating an illustrative exchange 400 between a parent update service node 402 and a child update service node 404 when propagating a software update of the parent update service node to the service node of son update, in accordance with aspects of the present invention. As can be seen, the illustrative diagram 400 is divided in half, the left half corresponds to actions and events of the update service node, parent 402, and the right half corresponds to actions and events of the update service node In addition, it should be 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 the purposes of discussion with respect to FIG. For purposes of this discussion, it is assumed that the parent update service node 402 was configured by an administrator so that the child update node 404 can not receive software updates unless explicitly authorized to do so by the administrator. As shown in illustrative exchange 400, starting at event 406, the update service node parent 402 receives a software update from a software provider 110, either directly, if the parent update service node is the node service update is root 102, or indirectly through the update distribution system 100. At some point after the update service node parent 402 receives the software update from the software provider 110, the service node of 404 child update begins a procedure to obtain software updates from the parent update service node. According to one embodiment, a child update service node 404 can be configured to automatically obtain software updates from a parent update service node 202 on a periodic basis. More particularly, an administrator, through the administration user interface 218, can selectively configure the child update service node 404 to automatically obtain the latest software updates at the parent update service node 402 on a base periodical As an example, an administrator can configure the child update service node 404 to obtain the latest software updates from its parent update service node 402 on a daily basis and / or per hour, as well as specify the time of day in which the automatic update procedure will begin. Other schedules and periodic criteria can also be used. Similarly, an administrator can manually initiate the update procedure through the user interface 218. To begin the update procedure, in the event 408 the child update service node 404 authenticates and authorizes itself with the child update service node 402. Authenticate and authorize with the update service node parent 402 will provide a control element on the distribution of software updates , limiting the update distribution to authorized update service nodes. The authentication and authorization techniques are well known in the art, any number that can 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 technique. After authenticating and appropriately authorizing with the update service node parent 402, in the event 410 the update service node parent 402 returns an authorization signal to the child update service node 404. According to a modality, a signal The authorization is a time-sensitive signal that the child update service node 404 provides the authorization to conduct other 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 authenticated with the parent update service node, no authorization signal is returned and the child update service node is unable to perform any other the activities related to updating except authentication and authorization. Similarly, after the update signal expired, the child update service node 404 is unable to perform any other activities related to updating with the update service node parent 402 except re-authentication and re-authorization. After receiving the authorization signal, in event 412 the child update service node 404 sends a request to the parent update service node for a product update catalog together with the authorization token. A product update catalog represents a list, or table of contents, of software products for which the parent update service node 402 distributes software updates. In accordance with aspects of the present invention, a child update service node 404 is not required to propagate all software updates available in its parent update service node 402. For example, with reference to the illustrative update distribution system of Figure 1, the corporation update service node 104 may have site licenses to only a fraction of software products available in the root update service node 102. Therefore, it would be unnecessary for the update service node From corporation 104 obtain all the software updates available in the root update service node 102, it would mostly never be used. Accordingly, an administrator at an update service node would selectively establish which software product updates will be available at the update service node. In accordance with 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 the service node The update of the child 404 is or is not configured to distribute updates for each product. However, in accordance with 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, which limits which software products are listed in the product update catalog can be determined according to the group or groups to which the child update service node 404 belongs. In event 404, the update service node parent 402 returns in product update catalog to child update service node 404. In event 416, child update service node 404 selects those products from the product update catalog for which the most recent updates are currently desired. . It should be noted that even though the product update catalog can list only those software products distributed by the child update service node 404, the child update service node can be configured to obtain updates for different software products in different times or in different periodic schedules. In event 418, the child update service node 404 sends an update synchronization request, together with the authorization token, which identifies the selected products for those updates that the child update service node looks for. Included in the synchronization request is information that identifies the most recent update available for a product in the child update service node 404. Information that identifies the most recent update for a product is referred to hereinafter as an "update anchor". " The update anchors for each software product are typically stored in update information storage 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, in event 420 the update service node parent 402 determines, if there is some, which of the updates are available for the 404 child update service node. As mentioned above, the determination is based on the specific rules associated with particular software updates and the group or groups of which a service node is a member of update son 404, as well as the update anchor. For this example, as previously mentioned, the previously received software update was not explicitly authorized for the child update service node 404. Therefore, the software update received in event 406 was not determined to be "available" for the child update service node 404. Accordingly, in the event 422 an update list is returned to the child update service node 404 without identifying the software update received in the event 406. In accordance with aspects of this invention, the update list identifies all "available" updates in the 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. In event 424, because the update list is empty, that is, no update is currently "available" in the update service node parent 402, the update procedure of the update service node 404 son is simply delayed , or sleep, for a predetermined amount of time. According to the current example, during this delay period, in event 426, an administrator in the update service node parent 402 authorizes the software update, received in event 406, to be distributed to the child update service node 404. In the event 428 (Figure 4B), the child update service node 404 again starts the automatic update procedure upon authentication and authorizing itself with the parent update service node 402. In response, at event 430, the update service node parent 402 returns an authorization signal to the child update service node 404. In event 432, the child update service node 404 sends a request, along with the signal from authorization, to the update service node, parent 402 for a product update catalog. In event 434, the update service node parent 402 returns the product update catalog to the child update service node 404. In event 436, the child update service node 404 selects the products for the update catalog for which updates are desired. In event 438, the child update service node 404 sends the update synchronization request identifying those products selected with the authorization signal. Because the child update service node 404 was authorized to obtain the software update previously received in the event 406, in the 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. After that, in event 442, the update service node parent 402 returns the update list, which now identifies the software update received in event 406, to the update service node 404. With an update list which identifies an "available" update in the update service node, parent 402, the update node, child 404 now has the necessary information to obtain the software update. According to one embodiment of the present invention, a child update service node 404 obtains the software update of the parent update service node 402 in two parts: obtain update metadata, and obtain the update content or file, then of this called the update payload. In accordance with further aspects of the present invention, the update metadata describe relevant 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, if the software update should be considered a priority, language-specific information, relationships with other software updates, location of the update payload for download purposes, installation driver routines, and the like. Some of the reasons that are often beneficial to download the complete software update in two parts, namely 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 necessary immediately, that is, needed for installation on a client computer, if needed. Thus, according to one embodiment of the present invention, the update payload is downloaded separately from the update metadata, and only when it is needed. Those skilled in the art will recognize this download technique as "slow download," or "alternatively as just-in-time download." In accordance with aspects of the present invention, an administrator can configure an update service node to obtain the update payload in a just-in-time form, or immediately upon retrieving the update metadata.In addition, in an alternative mode, both the update metadata and the update payload can be downloaded together.5 As shown in Figure 4B, with an update identified in the update list, in 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 the majority of other communication exchanges with the update service node, parent 402, the update request is sent with the authorization signal.It should be noted that while in the illustrated example, all the update metadata are downloaded in an access, in accordance with alternative aspects of this invention (not shown), the update metadata can be downloaded in more than one access. For example, in a first access, only the elements of the update metadata are necessary to determine if a software update is applicable and / or desirable is downloaded first, such as rules of applicability and dependencies of other software updates. Then, after it was determined that an update is applicable and / or desirable, the rest of the update metadata can be obtained. In response, in the event 446 the update service node parent 402 returns the update metadata for the software update son update service node 404, which in turn stores the update metadata in the storage of update information 216. In a mode, the update metadata includes, but is not limited to: unique identifier associated with a particular update; a description of the update, such as size of the update, problems addressed by the update, revision / anchor information, and the like; update applicability rules, such as if the update requires a prior update to be installed, if the update must be installed separately, if the update supersedes other available updates, and the like; end user license agreement data; and URL information for locating and / or accessing the payload if it is not stored in the update service node parent 402. Optionally, in event 448, the child update service node 404 sends a request to download the payload for update of the update service node 402. In response, in event 450, the update service node parent 402 returns the update payload to the child update service node 404, which in turn stores it in the update content storage 214. Because update activity has now occurred in the child update service node 404, in event 452, the child update service node generates and sends an update report to the update service node father 402 that delineates the update activities that occurred recently. After that, the child update service node 404 is again delayed until the next time that it is scheduled to run the update procedure (not shown). Those skilled in the art will appreciate that the events described above are for purposes of illustration, and reflect a particular illustrative group of events and circumstances. Clearly, other events will also occur according to specific details and circumstances that will cause some variation to the events described above. Additionally, it should be understood that while the child update service node 404 obtains the latest "available" software updates from the parent update service node 402, the child update service node can simultaneously process refresh requests from its nodes. of child update service. Accordingly, the above sequence of events should be viewed as illustrative only, and limited by the present invention. Figure 5 is a flowchart illustrating an illustrative routine 500 executed at a child update service node, such as the corporation update service node 104 of Figure 1, to periodically obtain updates from its service node. father update. Starting 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 of the parent update service node is described below with respect to Figure 6. Figure 6 is a flow chart of an illustrative subroutine 600, suitable for use in the illustrative routine 500 of Figure 5, to obtain a synchronized update list of "available" updates of a parent update service node. Beginning in block 602, as previously discussed with respect to Figures 4A and 4B, the child update service node authenticates and authorizes itself with the parent update service node and, in response to appropriate authentication and authorization , receives an authorization signal. In block 604, in conjunction with the authorization signal, the child update service node establishes communication parameters with the parent update service node. Establishing communication parameters allows the parent and child update service nodes to appropriately establish a common base that the parent and child understand. The communication parameters include, but are not limited to: protocols or communication update versions; product groupings; and similar. After having communication parameters established with the parent update service node, in 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. In block 608, the child update service node selects those software product updates for which updates are currently sought. In block 610, the child update service node sends an update synchronization request to the parent update service node, which includes both the authorization token and an "anchor" associated with the selected software products that identify the revision and current updates that are already in the child update service node. In response to the update synchronization request, in block 612, the child update service node obtains an update list of the parent update service node, synchronized according to the software updates "available" in the node of the update node. Parent update service according to what is currently stored in the child update service node. As mentioned above, the update list identifies, by a unique identifier, those software updates in the parent update service node that are "available" to the child update service node. After that, the illustrative subroutine 600 ends. With reference again to Figure 5, after obtaining a synchronized update list of the parent update service node, in decision block 504, a determination is made as if any of the software updates are currently "available" for download from the parent update service node. This determination is made according to whether there are update identifiers listed in the synchronized update list. If none of the software updates are currently "available" for download, the illustrative routine 500 proceeds to delay block 510, where the illustrative routine is delayed / sleeps until the next update period occurs. Alternatively, if there are "available" updates to be downloaded from the parent update service node, in block 506, the child update service node obtains updates from the parent update service node. Obtaining "available" updates of the parent update service node is described below with respect to Figure 7. Figure 7 is a flowchart of an illustrative subroutine 700, suitable for use in the illustrative routine 500 of Figure 500, to obtain "available" software updates from a parent update service node. Starting in block 702, a first dentifier is selected in the update list. In block 704, the child update service node obtains the update metadata corresponding to the selected update identifier of the parent update service node and stores it in the update information store 216.

According to one embodiment, in block 706, the child update service node obtains the update payload corresponding to the selected update identifier of the parent update service node, and stores the update payload in the storage of the update node. Update content 212. Optionally, the update content does not need to be downloaded immediately to the child update service node. As mentioned previously, a child update service node can be selectively configured to download updates from a parent update service node in a just-in-time manner. According to this optional treatment, as illustrated in Figure 7, rather than proceeding from block 704 to block 706, illustrative subroutine 700 optionally proceeds from block 704 to decision block 708. In decision block 708, after obtaining the update metadata for the selected update identifier, and optionally the update payload, a determination is made as if any of the additional update identifiers exist in the update list. If there are additional update identifiers, in block 710, the next update identifier is selected in the update list, and subroutine 700 returns to block 704 for further processing. The routine 700 continues until, in the decision block 708, it is determined that there are no longer update identifiers in the update list, thereby terminating the illustrative subroutine 700. Returning again to Figure 5, after obtaining the "available" updates of the parent update service node, in block 508, the child update service node reports the update activities to the parent update service node. After that, in the delay block 510, the illustrative routine 500 is delayed / sleeps for a predetermined amount of time until the next update period, and then proceeds to the block 502 to repeat the update procedures identified above. As illustrated in Figure 5, in decision block 504, even though no updates are "available" in a parent update service node, a child update service node may optionally be configured to report its update activities to the parent update service node. In accordance with this alternative configuration, when there are no updates available, the illustrative routine 500 may proceed to block 508 to report update activities. Figure 8 is a flowchart of an illustrative routine 800, implemented in a parent update service node, to generate a synchronized update list identifying "available" updates in response to an update synchronization request from a node son update service. Beginning in 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. In block 804, the first software product identified in the update synchronization request is selected. In decision block 806, a determination is made as to whether updates are available for the identified software product. This determination is made in accordance with metadata for the software product stored in update information storage 216, in accordance with the update anchor provided by the child update service node, and in accordance with distribution rules associated with the group to which the child update service node belongs. According to this determination, if there are "available" updates, in block 808, the unique update identifiers associated with the "available" updates are written to an update list. After writing unique update identifiers for "available" updates in the update list, in decision block 810, a determination is made as if any additional software product identified in the update synchronization request existed. If additional update software products exist in the update synchronization request, in block 814, the parent update service node selects the next software product identified in the update synchronization request, and returns to decision block 806 to determine if there are "available" updates for the selected software product. Alternatively, if there are no longer software products identified in the update synchronization request, in block 814, the update list is returned to the child update service node. After that, the illustrative subroutine 800 terminates. As mentioned above, an update service node is administered through the administration API 212 through the administration user interface 218, or some other similarly equipped module. To better understand how the administration API 212 operates, Figure 9 is a pictorial diagram to illustrate how the administration API is used with respect to configuring an update service node to distribute software updates to client computers. As shown in Figure 9, an administrator uses the administration API to generate subscriptions 904 and groups 906. The update service node, during an update procedure 908, uses the 902 updates available for that update service node, as well as subscriptions 904 and groups 906, to distribute updates to client computers, such as client computers 912-922.

As those skilled in the art will appreciate, an administrator generates a subscription for updates for a particular product or product family, as well as the update class. For example, a product may be a product of Internet Explores of Microsoft Corporation, and a subscription would indicate this product waiting for available updates. Similarly, a product family would typically indicate a number of products, such as Microsoft Corporation's Office as a product family, that includes numerous identifiable products. Subscriptions also typically identify the type of update that is approved for download to client computers. For example, the type of an update can be critical, severe, general, etc. In accordance with one embodiment of the present invention, client computers are organized into groups, and subscriptions and updates are applied to groups. In a real mode, each client computer belongs to two groups; one group of all computers, and another group. According to this real mode, the updating service node has the group of all computers defined and another group of computers not assigned. Through the administration API 212, the administrator is free to define any number of other groups, and client computers assigned to a group. Failing to assign a client computer to a group leaves the client computer in the unassigned group. In summary, according to this modality, one client computer belongs to the group of all computers and another. Groups can include any number of client computers. The groups of client computers, to apply software updates, are illustrated in Figure 9 as tables 910, 924, and 926. According to a real mode, administration API 212 is the interface through which Windows Software Update Services from Microsoft Corporation are configured and managed. In this embodiment, the administration API 212 is generally implemented by or accessible through the interface object server update. The description of a real mode of the interface object of the Server Update is listed in the Finan section of this section as Table 1. This interface object of the Update Server is part of the Administration API document included as part of the Provisional Application of E.U.A. No. 60 / 553,042, filed March 12, 2004, which is hereby incorporated by reference. However, several interface calls identified in Table 1 described below are generally described with respect to Figure 10. Figure 10 is a block diagram illustrating certain administration API calls to manage the distribution of software updates in an update service node. With access to a server update object 1002, a caller can make interference calls to obtain update service node configuration information 1004, current subscription information 1006, current approval rules 1008, update service node status information 1010, get 1012 updates, get 1014 client computers, and obtain 1016 groups.

The configuration information interface call 1004 provides access to configurable (and readable) values of the update service node, which include, but are not limited to, available languages, which is the parent update service node and location for that service node. parent update service node, proxy servers and addresses, the mode in which the update service node synchronizes updates with its parent update service node, and the like. In a real mode, as described in the appended appendix, the configuration information interface call 1004 is the "GetConfiguration" interface call in the server update object., which returns a case of an Iconfiguration interface object for the update service node. The Iconfiguration interface object is described in more detail in the built-in API of the interim application. The subscription information interface call 1006 provides access to subscription information, which includes, but is not limited to, the status of the most recent subscription efforts, when the next subscription effort will be completed (e.g., downloading an update). particular to a client computer), the frequency of subscription synchronization, and the like. In a real mode, there are at least two different interface calls to obtain subscription information. The "GetSubscription" interface call in the ServoDorUpdate object returns an ISuspcription interface object that corresponds to a specific subscription in the update service node, the "GetSubscriptions" callback returns a collection of objects from the interface of the update interface. ISuscription Additionally, a subscription is created using the "Create Subscription" interface call, which creates an empty subscription in the update service node. Details of the ISuscription interface object are described in the built-in API of the interim application. The update service node status interface call 1010 provides access to update service node status including, but not limited to, currently deployed updates, available updates, and the like. In a real mode, the "Get Summary Updates" interface call returns a summary collection object that describes the total update summary information for the update service node. The details regarding this interface call are described in the built-in API of the interim application. The interface call to obtain updates 1012 provides access to information regarding available software updates. More particularly, the interface call provides access to all software updates available in the system. In a real mode, there are several interface calls to obtain update information. The "GetUpdate" interface call returns an Update object that provides information regarding a specific update in the system. Additionally, the "GetUpdate" interface call returns a collection of available Update objects to the system. Additional details regarding these interface calls are provided in the built-in API of the interim application. The interface call to obtain computers 1014 provides access to the client computers associated with the update service node. In a real mode, there are at least two interface calls to access information about the various client computers, including, but not limited to, a "GetComputer" interface call that returns an IComputer object. which corresponds to a client computer identified in the interface call, and a "GetComputers" interface call that returns a collection of IComputer objects, the collection includes all client computers associated with the update service node. As above, additional details regarding these interface calls in the Server Update object are described in the built-in API of the interim application. The interface call to obtain groups 1016 provides access to the groups defined in the update service node. As mentioned above, in a real mode, each client computer belongs to the group of all computers and another group. If a client computer is not assigned to a group, the client computer predetermines the unassigned group. At least in this real mode, a number of interface calls is available that include, but are not limited to, an interface call of "GetGroupObject" that returns a GroupObject object that corresponds to a group identifier passed to the call of interface, and an interface call of "GetGroupObject" that returns a collection of ObjectiveObject objects that corresponds to all the groups defined in the update service node. Those skilled in the art will appreciate that while some of the interface calls are described, they are not an exhaustive group of interface calls. In fact, as illustrated in the appendix attached, a real modality of an administration API includes numerous interface calls, most of which were not specifically described. With respect to the following table, Table 1, the abbreviation WUS is an acronym for the Windows Update Server.

C UAD RO 1 lUpdate Server Use this interface to access Update Server components. The Update Server interface is derived from the System class. Object. Public Methods The interface of the Update Server has ks following public methods. Method Description Cancel All Downloads () Cancels updates that are currently being downloaded to the WUS server. CreateComputerObjectiveGroup (Row) Creates a target group that you can use to target client computers for updates.

The same (object) Determines whether the specified object is equal to the current object. GetComponentswithErrors () Retrieves a list of server components that are currently in an error state. Get Non-ConnectedComputers From Account Number of clients that do not (DateTime) reported their status to the WUS server from the specified time. GetComputerObjective (Row) Retrieves the specified client computer. GetComputerObjectiveGroup (Grid) Retrieves the specified target group.

GetComputerObjectiveGroups () Retrieves a collection of all the target groups on the WUS server. GetComputerObjectives () Retrieves a collection of all client computers that are known to the WUS server. Get Configuration () Retrieves an Update Server Configuration that you use to configure the WUS server.

GetContentDownloadProgress () Retrieves the progress of all updates that are currently downloaded. GetDatasetConfigurationO Retrieves a Databases Ibase that you use to determine the database configuration. GetCorrieneDownload Server (Row Retrieves an interface to the downstream WUS server specified. Get DownstreamServers () Retrieves a collection of downstream WUS servers that are registered with this WUS server GetMixCode Serves as a mixing function for a particular type GetMixCode for use in algorithms mix and data structures like a mix box.

GetinstallApprovalRulesO Retrieves the approval rule that is used to automatically download and install updates on target computers. GetRootUpdateCategories () Retrieves a collection of the top-level categories on the WUS server. GetRevisionApprovalReglaO Retrieves the approval rule used to automatically review the target computers to determine if the update is applicable. GetState () Retrieves statistics that summarize the current status of the WUS server, updates, and client computers.

GetSubscription () Retrieves a subscription case that you use to manage the synchronization procedure. GetSubscriptionEvent (Quad) Retrieve a subscription event that identifies changes to the subscription.

GetInfined Synchronization (CuadrícuA) Retrieves information that is related to a specific synchronization procedure. Get Type () Retrieve the Type of the current case. GetUpdate (UpdateReview) Retrieve the specified update.

GetAccuracyApproval (Grid) Retrieves the specified approval. GetUpdateCategories () Retrieves the list of all update categories that are known to the WUS server. GetUpdateCategories (DateTime, Retrieve the categories of DateTime) update that were added within the specified date range. GetUpdateCategory (Grid) Retrieves the category of updates for the given identifier. GetUpdateClassification (Grid) Retrieves the requested update classification. GetUpdatesClassifications () Retrieves a collection of update classifications that are known to the WUS server. GetUpdateClassifications (DateTime, Retrieve the classifications of DateTime) update that were added within the specified date range. GetUpdateHistorialEvent (DateTime, Retrieve all events from DateTime) installation for all clients for the specified date range. GetUpdateHistorialEvent (DateTime, Retrieve all events from DateTime, IComputerObjective) installation that was increased by the specified client for the specified date range.

GetUpdateHistorialEvent (DateTime, Retrieve all events from DateTime, Update) installation that was increased by all customers for the specified update and date range. GetUpdateHistorialEvent (DateTime, Recover events based on DateTime, Update, WusEventForce, the criteria specified.

WusEventold []) Get Updates () Retrieves a collection of the most recent revision of each update. Get Updates (Approved States, Recover a collection of DateTime, TimeTime, updates based on the Update, CategoryCollection, specified criteria. UpdateClassificationCollection) RecordMessage (Register Level, Row, paramsObject []) Registers a message to the software distribution log file. Computer Registry (Row) Registers a client computer with the WUS server.

Reestablish and Verify Content Status () Forces the synchronization of all update metadata on the WUS server and verifies that all update files on the WUS server are valid.

Summarize All Downloads () Identify the updates to download. SearchComputerObjectives (Row) Retrieves a collection of target computers whose full domain name contains the given row.

Search Updates (Row) Retrieves a collection of updates whose metadata contains the given row ParaFile () Retrieves a Row that represents the current Object. Public Properties The interface of the Update Server has the following public property Property Description PreferredCulture Retrieves or sets the language code that you want the WUS server to use when you return rows.

While several embodiments, which include the preferred embodiment, of the invention were illustrated and described, it will be appreciated that various changes can be made without departing from the spirit and scope of the invention.

Claims (18)

1. An update service node having an application programming interface for managing the distribution of software updates in the update service node, the application programming interface comprises: an update storage for storing software updates; an update web service through which the update service node obtains software updates from a parent update service node through a communication network, and through which the update service node distributes software updates to nodes of child update service through the communication network; and an administration application programming interface (API) through which an administrator establishes controls for the distribution of software updates to child update service nodes and client computers, where the administration API is an object that exposes a plurality of interface-calls to through which the administrator establishes these rules.

The update service node according to claim 1, wherein the API administration exposes a configuration interface call to get a configuration interface object returned to read and write software update management configuration settings for the update service node.

3. The update service node according to claim 2, wherein the configuration interface object is an object of the IConfiguration interface.

The update service node according to claim 2, wherein the administration API exposes a subscription getting interface call that returns a subscription interface object corresponding to a subscription identifier passed to the interface call to obtain subscription.

5. The update service node according to claim 4, wherein the subscription object object is an ISuscription interface object.

The update service node according to claim 4, wherein the administration API exposes an interface call obtaining subscriptions that returns a subscription collection interface object defined in the update service node.

7. The update service node according to claim 4, wherein the administration API exposes an update interface call that returns an update interface object corresponding to a past update identifier in the call of Try to get updated.

8. The update service node according to claim 7, wherein the refresh object object is an update interface object.

The update service node according to claim 7, wherein the administration API exposes an update interface interface that returns an update collection object containing update interface objects corresponding to values passed in the interface call to get updates.

The update service node according to claim 9, wherein the values passed to the interface call to obtain updates include an expanded status object and a Boolean value of excluding hidden updates.

The update service node according to claim 9, wherein the administration API exposes an interface call to obtain a computer that returns a client computer object corresponding to the client computer associated with the service node update and that was identified in the computer interface get call.

12. The update service node according to claim 11, where the client computer object is an IComputer object.

The update service node according to claim 11, wherein the administration API exposes an interface call to obtain computers that returns a computer collection object that includes client computer objects that correspond to client computers associated with the update service node.

14. The update service node according to claim 13, wherein the administration API exposes an interface call to obtain group that returns an object of target group that was identified in the call to obtain group.

The update service node according to claim 14, wherein the administration API exposes an interface call to obtain groups that returns a target group collection object that includes objects of the target group corresponding to target groups in the update service node.

16. The update service node according to claim 1, wherein the administration API is an interface object of the Update Server.

17. An application programming interface (API) to manage the distribution of software updates in an update service node, the API includes: a configuration interface call that returns a configuration interface object for reading and writing configuration settings for software update management to update service nodes; a subscription obtaining interface that returns a subscription interface object defined in the update service node; an interface call to obtain update that returns an update interface object corresponding to a past update identifier in the interface call to obtain update; an interface call to obtain updates that returns an update collection object that contains update interface objects that correspond to values passed in the interface call to obtain updates; a computer interface obtaining a return of a client computer object corresponding to a client computer associated with the update service node and identified in the computer obtaining interface call; an interface call to obtain computers that returns a computer collection object that includes client computer objects that correspond to client computers associated with the update service node; an interphase get group call that returns an object of the target group that was identified in the get group interface call; and an interface call to obtain groups that returns a target group collection object that includes target group objects that correspond to target groups in the update service node.

18. An update distribution system for distributing software updates, the software update distribution system comprises: an update service node; and an administration application programming interface (API) associated with the update service node, where the Management API is an interface object that exposes a plurality of interface calls to control the distribution of software updates, the administration API includes: an interface call to obtain configuration that returns a configuration interface object to read and write configuration settings for software update management to update service nodes; a subscription obtaining interface that returns a subscription interface object defined in the update service node; an interface call - to obtain update that returns an update interface object that corresponds to a last update identifier in the interface call to obtain update; an interface call to obtain updates that returns an update collection object that contains update interface objects that correspond to values passed in the interface call to obtain updates; a computer interface obtaining a return of a client computer object corresponding to a client computer associated with the update service node and identified in the computer obtaining interface call; an interface call to obtain computers that returns a computer collection object that includes client computer objects that correspond to client computers associated with the update service node; an interface call to obtain a group that returns an object from the target group that was identified in the call to obtain a group; and an interface call to obtain groups that returns a target group collection object that includes target group objects that correspond to target groups in the update service node.