BRPI0508244B1 - Update service node having an application programming interface - Google Patents

Abstract

interface e progrmação e aplicação para adminsitrar a distribuição de atualizações de software em um sistema de distribuição de atualização trata-se de uma interface de programação de aplicação (api) para administrar a distribuição de atualizações de software em um nó de serviço de atualização.a api proporciona uma pluralidade de chamadas de interface através das quais um administrador pode estabelecer regras pelas quais as atualizações de software disponíveis para o nó de serviço de atualização são distribuídas.

Description

Relatório Descritivo da Patente de Invenção para "NÓ DE SERVIÇO DE ATUALIZAÇÃO POSSUINDO UMA INTERFACE DE PROGRAMAÇÃO DE APLICAÇÃO".

CAMPO DA INVENÇÃO

[001] A presente invenção relaciona-se com software e redes de computadores e em particular, a presente Invenção relaciona-se com uma interface de programação de aplicação para administrar a distribuição de atualizações de software em um sistema de distribuição de atualização.

FUNDAMENTO DA INVENÇÃO

[002] Aproximadamente todos os produtos de software comercial mente disponíveis passam por um processo de revisão contínuo para reparar ou atualizar aspectos do software. Cada revisão de um produto de software requer adicionar novos arquivos, substituir arquivos existentes por revisões mais recentes, apagar arquivos obsoletos, ou várias combinações destas ações. Este processo de substituir arquivos mais antigos, adicionar novos arquivos e apagar arquivos obsoletos de um produto de software será referido posteriormente neste documento como ‘atualizar um produto” e a coleção de dados, incluindo arquivos binários, arquivos de dados, instruções de atualização, metadados, dados da base de dados, parâmetros de registro de sistema, parâmetros de segurança e coisas parecidas, utilizados ao atualizar o produto, será referida posteriormente neste documento mais simplesmente como uma ‘atualização’.

[003] Uma vez que um provedor de software tenha criado uma atualização para um produto de software, para consertar um problema, aperfeiçoar a segurança, ou adicionar novos aspectos, o provedor de software irá desejar tornar esta atualização amplamente disponível para sua base de clientes. Muito freqüentemente, tal como quando a atualização é direcionada para corrigir uma falha no produto ou ende- reçando ma questão crítica de segurança, o provedor de software irá desejar a atualização instalada nos computadores dos clientes o mais rápido possível. Na verdade, a maioria dos provedores de software possui um incentivo comercial para distribuir atualizações de software para seus clientes os mais rapidamente e livre de problemas quanto possível.

[004] A industria de computadores tem experimentado um crescimento explosivo no número de computadores conectados com redes e em particular, com a internet. Devido a este crescimento explosivo, e devido às habilidades de comunicação disponíveis através de uma conexão com a Internet, a Internet tornou-se um canal importante e integral para provedores de software distribuírem atualizações para seus clientes. Na verdade, a Internet tornou-se o canal principal de distribuição para vários provedores de software para proporcionar atualizações de software para seus clientes. É freqüente no melhor interesse dos provedores de software distribuir atualizações de software através da Internet, à medida que a distribuição eletrônica de atualização através da Internet reduz seus custos gerais e permite aos clientes obter as atualizações de software assim que elas estão disponíveis. Mais e mais freqüentemente, estas atualizações de software são conduzidas automaticamente através da Internet, sem qualquer intervenção do usuário.

[005] Enquanto a Internet é agora normalmente utilizada como um conduto para distribuir atualizações de software a partir dos provedores de software, freqüentemente surgem várias questões. Duas questões incluem (1) a eficiência relacionando-se com a infraestrutura / recursos da distribuição da atualização e (2) o controle administrativo em relação à distribuição e à instalação das atualizações de software.

[006] Com respeito à eficiência dos recursos de distribuição, as redes, incluindo a Internet, possuem somente uma quantidade finita de recursos de comunicação, freqüentemente referidos como largura de banda. Uma quantidade finita de largura de banda de comunicação freqüentemente resulta em gargalos, especialmente com respeito às atualizações de software para produtos de software populares, tal como a família Windows® da Microsoft Corporation de sistemas operacionais e produtos de produtividade relacionados. Tais gargalos existem mesmo quando as atualizações de software são feitas disponíveis em várias localizações de transferência distribuídas através de toda a Internet. Uma razão pela qual tais gargalos ocorrem é o modelo de acesso não estruturado feito disponível pela Internet. Por exemplo, se um primeiro usuário no computador A requisitar a transferência mais recente de um produto de software, a transferência passa através do provedor de serviço independente (ISP) do primeiro usuário. Adicionalmente, a requisição é tratada como um acesso único individualizado, significando que a requisição é tratada independente e não relacionada com qualquer outro tráfego e/ou requisição da rede. Como tal, se um segundo usuário no computador B, o qual também acontece de ter o mesmo ISP, requisita a mesma transferência como o primeiro usuário, a requisição a partir do segundo usuário também é tratada como um acesso único individualizado. Neste exemplo, a mesma transferência será transmitida através da mesma infraestrutura duas vezes, devido ao fato de que cada requisição foi tratada isoladamente. Claramente, se o número de usuários aumentar substancialmente, a largura de banda de comunicação finita irá tornar-se um gargalo. Neste exemplo, o qual é muito comum, teria sido muito mais eficiente se a transferência pudesse ter sido colocada em memória cache em uma localização local e cada requisição de usuário satisfeita a partir da cache local.

[007] Com respeito ao controle de distribuição, várias organizações, especialmente grandes organizações, possuem razões para controlar a distribuição de atualizações para seus computadores. Por exemplo, infelizmente, algumas atualizações possuem ou introduzem falhas, freqüentemente referidas como defeito no código de um programa (“bugs”), os quais “quebram” aspectos de um produto de software. Estes aspectos rompidos podem ser insignificantes, mas muito freqüentemente eles podem interromper aspectos críticos da missão de uma empresa. À medida que uma empresa não pode arcar com perda de seus aspectos críticos de missão, uma empresa responsável primeiro irá avaliar e testar cada atualização de software dentro de um ambiente controlado durante algum período de tempo antes de liberar a atualização para o restante de seus computadores. Este período de avaliação permite à organização validar se uma atualização irá afetar de forma adversa um aspecto crítico de missão. Somente após ter sido satisfatoriamente determinado que uma atualização não irá derrubar qualquer aspecto crítico de missão, a atualização é permitida de ser distribuída para o restante dos computadores da organização. Claramente, a maioria das organizações deve exercer controle sobre a instalação de atualizações de software em seus computadores.

[008] Outra razão pela qual uma empresa ou uma organização freqüentemente precisa controlar a distribuição de atualizações de software é para garantir consistência entre os computadores na organização. É muito importante para os departamentos de serviço de informação terem uma plataforma alvo padronizada sobre a qual todos os computadores operam, quer ela seja para um processador de texto ou para um sistema operacional. Sem um padrão, a manutenção de software e de computador pode ser desnecessariamente complexa e difícil.

[009] Ainda outra razão pela qual o controle local é importante é para propósito de faturamento. Em grandes organizações, é freqüentemente ineficiente individualmente instalar software em um computador, ou individualmente manter licenças para um produto de software particular para cada computador na organização. Ao ínvés disso, uma única licença de local permite a uma organização executar um produto de software em vários computadores. Assim, uma organização pode ser requerida de reportar o número de computadores executando um produto sob a licença de local, ou pode precisar limitar o número de computadores executando um produto sob uma licença de local. Todas estas razões freqüentemente exigem controle local sobre a distribuição de atualização de software.

[0010] À luz das várias questões identificadas acima se relacionando com a distribuição de atualização de software, o que é necessário é uma arquitetura de distribuição de atualização de software extensível para proporcionar controle sobre a distribuição de atualizações de software, bem como aumentar sua eficiência de distribuição. A presente invenção endereça estas e outras questões encontradas na técnica anterior.

SUMÁRIO DA INVENÇÃO

[0011] De acordo com aspectos da presente invenção, é apresentado um nó de serviço de atualização possuindo uma interface de programação de aplicação para administrar a distribuição de atualizações de software no nó de serviço de atualização. O nó de serviço de atualização inclui uma memória de atualização par armazenar atualizações de software. O nó de serviço de atualização também incluí um serviço de rede de atualização através do qual o nó de serviço de atualização obtém atualizações de software a partir de um nó pai de serviço de atualização através de uma rede de comunicação e através do qual o nó de serviço de atualização distribui atualizações de software para nós filhos de serviço de atualização através da rede de comunicação. Ainda adicional mente, o nó de serviço de atualização inclui uma interface de programação de aplicação (API) de administração através da qual um administrador estabelece controles de distribuição de atualiza- ções de software para nós filhos de serviço de atualização e para computadores cliente, onde a API de administração é um objeto expondo uma pluralidade de células de interface através das quais o administrador estabelece as ditas regras.

[0012] De acordo com aspectos adicionais da presente invenção,é apresentada uma interface de programação de aplicação (API) para administrar a distribuição de atualizações de software em um nó de serviço de atualização. A API compreende uma chamada de interface que obtém configuração que retorna um objeto de interface de configuração para leitura e gravação de valores de configuração de administração de atualização de software junto ao nó de serviço de atualização. A API adicionalmente compreende uma chamada de interface que obtém subscrição que retorna um objeto de interface de subscrição definido no nó de serviço de atualização. A API ainda adicionalmente compreende uma chamada de interface que obtém atualização que retorna um objeto de interface de atualização correspondendo a um identificador de atualização passado na chamada de interface que obtém atualização, bem como uma chamada de interface de obtém atualizações que retorna um objeto de coleção de atualizações contendo objetos de interface de atualização correspondendo aos valores passados na chamada de interface que obtém atualizações. A API também compreende uma chamada de interface que obtém computador que retorna um objeto computador cliente correspondendo ao computador cliente associado com o nó de serviço de atualização e que foi identificado na chamada de interface que obtém computador e uma chamada de interface que obtém computadores que retorna um objeto coleção de computadores incluindo objetos computador cliente correspondendo aos computadores cliente associados com o nó de serviço de atualização. Adicionalmente, a API compreende uma chamada de interface que obtém grupo que retorna um objeto grupo alvo que foi identificado na chamada de interface que obtém grupo e uma chamada de interface que obtém grupos que retorna um objeto coleção de grupos alvo incluindo objetos grupo alvo correspondendo aos grupos alvo no nó de serviço de atualização.

[0013] Ainda de acordo com aspectos adicionais da presente invenção, um sistema de distribuição de atualização de software para distribuir atualizações de software é apresentado. O sistema de distribuição de atualização de software compreende um nó de serviço de atualização e uma interface de programação de aplicação (API) de administração associada com o nó de serviço de atualização. A API de administração é um objeto interface expondo uma pluralidade de células de interface para controlar a distribuição de atualizações de software. A API de administração inclui uma chamada de interface que obtém configuração que retorna um objeto interface de configuração para ler e gravar valores de configuração de administração de atualização de software junto ao nó de serviço de atualização. A API adicionalmente inclui uma chamada de interface que obtém subscrição que retorna um objeto de interface subscrição definido no nó de serviço de atualização. A API ainda adicionalmente inclui uma chamada de interface que obtém atualização que retorna um objeto de interface atualização correspondendo a um identificador de atualização passado na chamada de interface que obtém atualização, bem como uma chamada de interface que obtém atualizações que retorna um objeto coleção de atualizações contendo objetos de interface atualização correspondendo aos valores passados na chamada de interface que obtém atualizações. A API também inclui uma chamada de interface que obtém computador que retorna um objeto computador cliente correspondendo a um computador cliente associado com o nó de serviço de atualização e que foi identificado na chamada de interface que obtém computador e uma chamada de interface que obtém computadores que retorna um objeto coleção de computadores incluindo objetos computador cliente correspondendo aos computadores clientes associados com o nó de serviço de atualização, Adicionalmente, a API inclui uma chamada de interface que obtém grupo que retorna um objeto grupo alvo que foi identificado na chamada de interface que obtém grupo e uma chamada de interface que obtém grupos que retorna um objeto coleção de grupos alvo incluindo objetos grupo alvo correspondendo aos grupos alvo no nó de serviço de atualização.

BREVE DESCRICÃO DOS DESENHOS

[0014] Os aspectos anteriores, e várias das vantagens acompanhantes desta invenção irão se tornar pronta mente apreciados à medida que os mesmos se tornem mais bem entendidos por referência à descrição detalhada seguinte, quando feita em conjunto com os desenhos acompanhantes, onde: A Figura 1 é um diagrama ilustrado de um sistema de distribuição de atualização ilustrativo formado de acordo com aspectos da presente invenção; A Figura 2 é um diagrama de blocos ilustrando componentes lógicos ilustrativos de um nó de serviço de atualização formado de acordo com aspectos da presente invenção; A Figura 3 é um diagrama de blocos ilustrando componentes lógicos ilustrativos de um nó raiz de serviço de atualização formado de acordo com aspectos da presente invenção; A Figura 4 é um diagrama de blocos ilustrando uma troca ilustrativa entre um nó pai de serviço de atualização e um nó filho de serviço de atualização ao proporcionar uma atualização de software a partir do nó pai de serviço de atualização para o nó filho de serviço de atualização de acordo com aspectos da presente invenção; A Figura 5 é um fluxograma ilustrando uma rotina ilustrativa executada em um nó filho de serviço de atualização para periódica- mente obter atualizações a partir de seu nó paí de serviço de atualização; A Figura 6 é um fluxograma de uma sub-rotina ilustrativa adequada para uso na rotina ilustrativa da Figura 5 para obter um catálogo de atualizações a partir de um nó pai de serviço de atualização; A Figura 7 é um fluxograma de uma sub-rotina ilustrativa adequada para uso na rotina ilustrativa da Figura 5 para obter uma atualização de software a partir de um nó pai de serviço de atualização; A Figura 8 é um fluxograma de uma rotina ilustrativa para processar uma requisição de atualização a partir de um nó filho de serviço de atualização; A Figura 9 é um diagrama ilustrado para ilustrar como a API de administração é utilizada com respeito a configurar um nó de serviço de atualização para distribuir atualizações de software para computadores cliente; e A Figura 10 é um diagrama de blocos ilustrando certas chamadas da API de administração para administrar a distribuição de atualizações de software em um nó de serviço de atualização, DESCRIÇÃO DETALHADA DAS MODALIDADES PREFERIDAS

[0015] De acordo com aspectos da presente invenção, um sistema de distribuição de atualização, organizado de um modo hierárquico, para distribuir atualizações de software, é apresentado. Â Figura 1 é um diagrama ilustrado de um sistema de distribuição de atualização ilustrativo 100, formado de acordo com aspectos da presente invenção. De acordo com a presente invenção, na “parte de cima’1 de um sistema de distribuição de atualização, tal como o sistema ilustrativo ode distribuição de atualização 100, está um nó raiz de serviço de atualização 102. Provedores de software, tal como o provedor de software 110, distribui suas atualizações de software através do sistema de distribuí- ção de atualização 100 por submeter as atualizações para o nó raiz de serviço de atualização 102. De acordo com aspectos da presente invenção, provedores de software, tal como o provedor de software 110, pode submeter suas atualizações de software para o nó raiz de serviço de atualização 102 através de uma rede, tal como a Internet 108.

[0016] Um sistema hierárquico de distribuição de atualização, tal como o sistema ilustrativo de distribuição de atualização 100, provavelmente irá incluir pelo menos um outro nó de serviço de atualização em adição ao nó raiz de serviço de atualização 102. Como ilustrado na Figura 1, o sistema ilustrativo de distribuição de atualização 100 inclui o nó de serviço de atualização raiz 102 e dois nós de serviço de atualização adicionais: o nó de serviço de atualização 104 e o nó de serviço de atualização 106. De acordo com a presente invenção, cada sistema hierárquico de distribuição de atualização é organizado em uma estrutura tipo árvore embaixo do nó de serviço de atualização raiz 102. Em outras palavras, cada nó de serviço de atualização em um sistema de distribuição de atualização possui zero ou mais nós de serviço de atualização filhos. Assim, enquanto o sistema ilustrativo de distribuição de atualização 100 apresenta que cada nó de serviço de atualização pai, isto é, o nó de serviço de atualização raiz 102 e o nó de serviço de atualização 104 possuem somente um filho, isto é somente para propósitos ilustrativos e não deve ser construído como limitação em relação à presente invenção. Adicionalmente, com exceção do nó de serviço de atualização raiz 102, cada nó de serviço de atualização em um sistema de distribuição de atualização possui um nó de serviço de atualização pai. Por conseqüência, como apresentado na Figura 1, o nó de serviço de atualização 104 é um nó filho para o nó de serviço de atualização raiz 102 e o nó de serviço de atualização 106 é um nó filho para o nó de serviço de atualização 104. Como pode ser visto, cada nó de serviço de atualização, com a exceção do nó de serviço de atuali- zação raiz 102, pode ser tanto um nó de serviço de atualização filho como um nó de serviço de atualização pai.

[0017] Como ilustrado no sistema ilustrativo de distribuição de atualização 100, o nó de serviço de atualização raiz 102 comunica-se com o nó de serviço de atualização 104 através da Internet 108. Entretanto, deve ser entendido que isto é somente ilustrativo e não deve ser construído como limitativo em relação a presente invenção. Cada nó de serviço de atualização em um sistema de distribuição de atualização precisa somente estar apto a comunicar-se com seu pai e/ou filho através de alguma rede de comunicação. Assim, enquanto o nó de serviço de atualização 104 comunica-se com seu pai, o nó de serviço de atualização raiz 102, através da Internet 108, ele pode alternativamente comunicar-se com seus nós de serviço de atualização filhos, tal como o nó de serviço de atualização 106, via uma rede de área local 124.

[0018] Também apresentado na Figura 1, o nó de serviço de atualização 106 reside dentro de uma sub-rede 126 da rede de área local 124. Como um exemplo, a rede de área local 124 pode corresponder a uma rede coorporativa geral da organização e o nó de serviço de atualização 104 representar a ligação da corporação com o sistema de distribuição de atualização 100, via sua conexão com seu pai, o nó de serviço de atualização raiz 102. Adicionalmente, a sub-rede 126 pode corresponder a um grupo identificável de computadores dentro da rede coorporativa, tal como um grupo de teste / avaliação, um escritório remotamente localizado, ou um grupo de missão crítica. Como será descrito em maiores detalhes abaixo, de acordo com aspectos da presente invenção, um administrador no nó de serviço de atualização 104 está apto a controlar a distribuição de atualizações para o nó de serviço de atualização 106 e finalmente para os computadores cliente.

[0019] Deve ser apreciado que cada nó de serviço de atualização, incluindo tanto o nó de serviço de atualização 102 como os nós de ser- viço de atualização 104 e 106, são configurados para distribuir atualizações de software tanto para os nós de serviço de atualização filhos como para os computadores cliente. Como apresentado na Figura 1, o sistema ilustrativo de distribuição de atualização 100 inclui os computadores cliente 112 a 122. Cada nó de serviço de atualização, incluindo o nó de serviço de atualização raiz 102, distribui atualizações para nós de serviço de atualização filhos e para computadores clientes de acordo com a informação de configuração local. De acordo com uma modalidade, um administrador define grupos de associa regras de distribuição de atualização para estes grupos. Cada nó de serviço de atualização possui pelo menos um grupo de distribuição.

[0020] Como um exemplo para ilustrar como o sistema de distribuição de atualização opera, assuma que a rede de área local 124 corresponde a uma rede coorporativa da organização empresarial. De acordo com uma modalidade da presente invenção, um administrador, no nó de serviço de atualização 104, pode definir vários grupos de distribuição para a rede coorporativa 124, incluindo um grupo de avaliação, correspondendo à sub-rede 126 incluindo o nó de serviço de atualização 106 e os computadores cliente 120 e 122, para avaliar a capacidade de adequação de uma atualização para rede coorporativa geral 124, bem como um grupo coorporativo geral incluindo o nó de serviço de atualização 104 e os computadores cliente 114 a 118.

[0021] Com respeito ao grupo de avaliação, o administrador inclui o nó de serviço de atualização 106 como um membro e associa regras para este grupo de modo que as atualizações sejam imediatamente distribuídas para os membros do grupo de avaliação a medida que elas tornem-se disponíveis. Alternativamente, com respeito ao grupo coorporativo geral, o administrador adiciona os computadores cliente 114 a 118 e associa uma regra de modo que as atualizações sejam somente distribuídas para os membros do grupo coorporativo geral se especificamente autorizado pelo administrador. Assuma também que um administrador para o nó de serviço de atualização 106 cria um grupo preestabelecido consistindo dos computadores cliente 120 e 122 na sub-rede de avaliação 126, para o qual qualquer nova atualização de software pode ser imediatamente distribuída.

[0022] Continuando o exemplo acima, um provedor de software 110 submete uma atualização de software para o nó de serviço de atualização raiz 102. De acordo com regras estabelecidas no nó de serviço de atualização raiz 102, a atualização é eventualmente distribuída para o nó coorporativo de serviço de atualização 104. Quando do recebimento da atualização, pelas regras estabelecidas pelo administrador, o nó coorporativo de serviço de atualização 104 distribui a atualização para os membros do grupo de avaliação (definidos como somente o nó de serviço de atualização filho 106), mas retém a atualização do grupo coorporativo geral pendendo de autorização específica para distribuir a atualização para este grupo.

[0023] Continuando o exemplo acima, quando do recebimento da atualização, o nó de serviço de atualização de avaliação 106 processa a atualização com respeito a cada grupo definido. Neste exemplo, o nó de serviço de atualização de avaliação 106 possui somente um grupo. Entretanto, como anteriormente mencionado, em uma implementação real, podem existir vários grupos definidos, cada um com um único conjunto de regras de distribuição associadas. Para este exemplo, o nó de serviço de atualização de avaliação 106 imediatamente torna a atualização disponível para distribuição para os computadores cliente 120 e 122. Os computadores cliente 120 e 122 podem agora ser atualizados e o período / processo de avaliação pode começar.

[0024] Ainda continuando o exemplo acima, quando o administrador no nó coorporativo de serviço de atualização 104 está suficientemente satisfeito em relação a atualização ser adequada para distribui- ção através de toda a rede coorporativa 124, o administrador então explicitamente autoriza a atualização de ser distribuída para os membros do grupo coorporativo geral. O nó coorporativo de serviço de atualização 104 de forma correspondente torna a atualização disponível para os computadores cliente 114 a 118. Deve ser entendido que o nó de serviço de atualização de avaliação 106 também pode estar incluído no grupo coorporativo geral. Entretanto, devido ao nó de serviço de atualização de avaliação 106 já ter sido atualizado, nenhuma ação adicional relacionada com atualização é necessária para distribuir a atualização para ao sub-rede de avaliação 126.

[0025] Como pode ser visto pelo exemplo acima, a presente invenção oferece benefícios significativos em termos de controle de distribuição local e de eficiência de transferência. Em adição aos aspectos descritos acima, também são constatadas economias significativas na largura de banda de comunicação. Por exemplo, enquanto a rede coorporativa ilustrativa 124 ilustrada na Figura 1 inclui cinco computadores cliente, a atualização do provedor de software foi transferida a partir do nó de serviço de atualização raiz 102 para o nó coorporativo de serviço de atualização 104 somente uma vez. Então, claramente, a medida que o número de computadores cliente servidos por um nó de serviço de atualização aumenta, a utilização da largura de banda de comunicação entre um nó de serviço de atualização pai e um nó de serviço de atualização cliente permanece constante, desse modo substancialmente reduzindo a quantidade de largura de banda de comunicação que de outro modo seria utilizada. Adicionalmente, o sistema de distribuição de atualização é tanto extensível como escalável. O sistema de distribuição de atualização é extensível de pelo menos dois modos: qualquer número de nós de serviço de atualização filhos pode ser adicionado para um nó de serviço de atualização pai e os nós de serviço de atualização filhos também podem ser um nó de serviço de atuali- zação pai. Portanto, cada sub-árvore do sistema de distribuição de atualização pode ser construída para satisfazer necessidades individuais.

[0026] A Figura 2 é um diagrama de blocos ilustrando componentes lógicos ilustrativos de um nó de serviço de atualização 200, tal como o nó coorporativo de serviço de atualização 104 (Figura 1) ou oi nó de serviço de atualização de avaliação 106 (Figura 1), formados de acordo com aspectos da presente invenção. Como apresentado na Figura 2, um nó de serviço de atualização 200 inclui um serviço de rede de atualização 202, um módulo de atualização de cliente 204, um módulo de atualização de filho 206 e um módulo de relatório 208. O nó ilustrativo de serviço de atualização 200 também inclui um módulo de autenticação / autorização 210, uma interface de programação de aplicação (API) de administração 212, uma memória de conteúdo de atualização 214, uma interface com o usuário de administração 218 e uma memória de informação de atualização 216.

[0027] O serviço de rede de atualização 202 proporciona um conjunto comum de serviços da Rede através dos quais os computadores cliente, os nós de serviço de atualização filhos e um nó de serviço de atualização pai podem comunicar-se com um nó de serviço de atualização. Por exemplo, com referência à Figura 1, de modo que o nó de serviço de atualização filho / de avaliação 106 obtenha uma atualização de software a partir do nó de serviço de atualização pai / coorporativo 104, o cliente comunica-se através do serviço de rede de atualização do pai 202. De forma similar, quando um nó de serviço de atualização pai, tal como o nó de serviço de atualização raiz 102, possui informação, incluindo atualizações, para comunicar para seu nó de serviço de atualização filho 104, o nó de serviço de atualização pai comu-nica-se através do serviço de rede de atualização do filho 202.

[0028] Em uma modalidade real da presente invenção, o conjunto comum de serviços da Rede proporcionados pelo serviço de rede de atualização 202, geralmente referido como interface de serviços da rede, inclui as seguintes chamadas: GetServerAuthConfig para obter informação de configuração de autenticação a partir de um nó de serviço de atualização pai; GetConfigData e GetServerConfigData para obter informação de configuração e propriedades do nó de serviço de atualização pai; GetServerCookie para obter uma indicação de autorização a partir de um nó de serviço de atualização pai; GetRevisionldList para obter uma lista de atualizações a partir de um nó de serviço de atualização pai; GetUpdateData para obter metadados de atualização e cargas úteis de atualização a partir de um nó de serviço de atualização pai; e ReportEvents para relatar a atividade de atualização que ocorreu em um nó de serviço de atualização para seu nó de serviço de atualização pai.

[0029] O módulo de atualização de cliente 204 manipula as comunicações entre um computador cliente e o nó de serviço de atualização 200 com respeito às atualizações e à informação de atualização armazenada no nó de serviço de atualização. As comunicações relacionadas com a atualização incluem, mas não estão limitadas a distribuir atualizações em resposta às requisições dos clientes e proporcionar uma lista de produtos de software disponíveis e atualizações associadas para o computador cliente. O módulo de atualização de cliente 204 também é responsável por determinar se um computador cliente está autorizado a obter uma atualização particular de acordo com as regras de distribuição associadas e responde a um computador cliente com a informação relacionada com a atualização que o computador cliente está autorizado a acessar.

[0030] O módulo de atualização de cliente 206 manipula comunicações relacionadas com a atualização entre um nó de serviço de atualização pai e seus nós de serviço de atualização filhos. As comuni- cações relacionadas com a atualização incluem, mas não estão limitadas a identificar listas de produtos de software e de atualizações associadas disponíveis para o nó de serviço de atualização filho, bem como responder às requisições de atualização a partir de um nó de serviço de atualização folho. O módulo de atualização à jusante 206 é responsável por determinar se um nó de serviço de atualização filho está autorizado a obter uma atualização particular de acordo com as regras de distribuição associadas e responde a um nó de serviço de atualização filho com a informação relacionada com atualização que o nó de serviço de atualização filho está autorizado a acessar.

[0031] O módulo de relatório 208 gera relatórios relacionados com atualização, tal como, quais grupos receberam ou não receberam uma atualização particular, quais computadores cliente tiveram ou não uma atualização transferida / instalada, quais atualizações estão disponíveis no nó de serviço de atualização e coisas parecidas. Estes relatórios podem ser utilizados internamente, tal como por um administrador e também submetidos para o nó de serviço de atualização pai, via a interface de serviço de atualização do pai 202. Como descrito acima, freqüentemente é necessário paras as corporações determinarem quais computadores clientes possuem uma atualização particular instalada, tal como para propósitos de faturamento ou para propósitos de manutenção. As informações / relatórios gerados pelo módulo de relatório 208 podem ser a base destes relatórios.

[0032] O módulo de autenticação / autorização 210 é responsável por autenticar, isto é, determinar a identidade de um computador cliente particular ou de um nó de serviço de atualização filho e determinar se um computador cliente ou nó de serviço de atualização filho está autorizado a acessar atualizações disponíveis no nó de serviço de atualização 200. Para estes computadores cliente e nós de serviço de atualização filhos que são autenticados e autorizados a acessar as atualizações em um nó de serviço de atualização, o módulo de autenticação / autorização 210 emite uma indicação de autorização que deve ser utilizada em conjunto com obter atualizações. A emissão e uso de uma indicação de autorização são descritos em maiores detalhes abaixo com respeito às Figuras 4A e 4B.

[0033] A API de administração 212 representa a interface de aplicação através da qual o controle do nó de serviço de atualização 200 é exercido e através da qual as atualizações em última análise são armazenadas e distribuídas. Quando o serviço de rede de atualização 202 recebe várias requisições relacionadas com atualização a partir de computadores cliente e de nós de serviço de atualização filhos, estas requisições são finalmente partidas em chamadas dentro da API de administração 121, diretamente ou indiretamente através do módulo de atualização de cliente 204 e do módulo de atualização de filho 206. Em conjunto com a interface com o usuário de administração 218 ou com algum outro programa instalado no nó de serviço de atualização 200 de forma adequado configurado para utilizar a API de administração 212, um administrador em última análise controla todos os aspectos do processo de atualização para este nó de serviço de atualização, bem como quaisquer nós de serviço filhos e computadores clientes. Uma modalidade real de uma API de administração está ligada como um anexo a este relatório descritivo e descrita em maiores detalhes abaixo com respeito às Figuras 9 a XX.

[0034] Através da interface com o usuário de administração 218, os administradores podem configurar e manter um nó de serviço de atualização 200, via a API de administração 212. Assim, através da interface com o usuário de administração 218, um administrador cria, modifica e apaga grupos, bem como as regras associadas para cada grupo. Adicionalmente, utilizando a interface com o usuário de administração 218, um administrador estabelece a qual grupo um computador cliente ou nó de serviço de atualização pertence. Através da interface com o usuário de administração 218, um administrador também pode explicitamente autorizar a distribuição de atualizações para computadores cliente ou nós de serviço de atualização filhos, configurar o nó de serviço de atualização 200 para periodicamente consultar seu nó de serviço de atualização pai em relação a novas atualizações, configurar parâmetros de relatório e ver relatórios internos e coisas parecidas. Como mencionado acima, enquanto a interface com o usuário de administração 218 permite a um administrador exercer controle sobre aspectos do nó de serviço de atualização 200, outra aplicação residindo no nó de serviço de atualização 200, de forma adequada adaptada para operar com a API de administração 212, pode ser utilizada ao invés da interface com o usuário de administração 218.

[0035] Como mencionado acima, de acordo com uma modalidade da presente invenção, um nó de serviço de atualização 200 inclui tanto uma memória de conteúdo de atualização 214 como uma memória de informação de atualização 216. A memória de conteúdo de atualização 214 armazena os arquivos reais representando as atualizações de software, tal como arquivos binários e de correção. Em contraste, a memória de informação de atualização 216 armazena informação e meta-dados correspondendo às atualizações disponíveis no nó de serviço de atualização 200, incluindo os arquivos de atualização armazenados na memória de conteúdo de atualização 214. De acordo com uma modalidade, a memória de conteúdo de atualização 214 e a memória de informação de atualização 216 são ambas bases de dados relacionais. Enquanto o nó ilustrativo de serviço de atualização 200 é apresentado como possuindo duas memórias de dados, a presente invenção não deve ser limitada desse modo. Em uma modalidade alternativa, ambas memória de conteúdo de atualização 214 e memória de informação de atualização 216 podem ser combinadas em uma única memória de in- formação.

[0036] De acordo com aspectos da presente invenção, uma atualização de software pode ser apresentada como estando “disponível” em um nó de serviço de atualização 200 para computadores clientes e nós de serviço de atualização filhos mesmo que no entanto a atualização não seja armazenada fisicamente na memória de conteúdo de atualização 214. Mais particularmente, ao invés de imediatamente transferir e armazenar os arquivos reais de atualização em um nó de serviço de atualização 200, uma ligação referenciando os arquivos de atualização no nó de serviço de atualização pai ou em qualquer outro lugar, pode ao invés disso ser armazenada no nó de serviço de atualização. Assim, se um computador cliente requisitar a atualização, ou um nó de serviço de atualização filho requisitar a atualização real, a atualização é então abaixada do nó de serviço de atualização pai e armazenada na memória de conteúdo de atualização 214, em preparação a distribuir a mesma para o computador cliente ou para o nó de serviço de atualização filho. Os com conhecimento na técnica irão reconhecer que este tipo de acesso de atualização é referido como transferência no momento certo (“just-in-time”). Desta maneira, uma atualização “disponível”, não precisa ser distribuída através de vários canais de rede até que ela seja realmente requisitada. De acordo com aspectos da presente invenção, um administrador de um nó de serviço de atualização 200 pode seletivamente determinar se obtém atualizações de software de uma maneira no momento certo.

[0037] Enquanto a descrição acima da Figura 2 ilustra vários componentes de um módulo de serviço de atualização ilustrativo 200, deve ser apreciado que outros componentes de um módulo de serviço de atualização também podem existir. Adicionalmente, os componentes descritos acima devem ser entendidos como sendo componentes lógicos, não necessariamente componentes reais. Em uma implementação real, os componentes identificados acima podem ser combinados juntos e/ou com outros componentes de acordo com as determinações da implementação. Adicionalmente, deve ser apreciado que enquanto um nó de serviço de atualização 200 pode ser visto como um computador servidor em uma rede, em uma implementação real, um nó de serviço de atualização pode ser implementado em qualquer número de tipos de dispositivos de computação. Por exemplo, cada nó de serviço de atualização 200 pode ser implementado e/ou instalado em um único sistema de computador independente ou, alternativamente, em um sistema de computação distribuído compreendendo vários dispositivos de computação.

[0038] A Figura 3 é um diagrama de blocos ilustrando componentes lógicos ilustrativos de um nó de serviço de atualização raiz 300, tal como o nó de serviço de atualização raiz 102 ilustrado na Figura 1, formado de acordo com aspectos da presente invenção. Similar aos componentes lógicos de um nó de serviço de atualização 200 (Figura 2), um nó de serviço de atualização raiz 300 inclui um serviço de rede de atualização 202, um módulo de atualização filho 206 e um módulo de autenticação / autorização 210. Adicionalmente, um nó de serviço de atualização raiz ilustrativo 300 também inclui uma API de administração 212, uma memória de conteúdo de atualização 214 e uma memória de informação de atualização 216. Opcionalmente, o nó de serviço de atualização raiz 300 também pode incluir um módulo de atualização de cliente 204, um módulo de relatório 208 e uma interface com o usuário de administração 218.

[0039] O módulo de atualização de cliente 204 é um componente opcional para um nó de serviço de atualização raiz 300 dependendo de se o nó de serviço de atualização raiz proporciona atualizações de software diretamente para os computadores clientes. Por exemplo, com referência à Figura 1, o nó de serviço de atualização raiz 102 incluiria o módulo opcional de atualização de cliente 204 como o nó de serviço de atualização raiz que diretamente serve ao computador cliente 112. Entretanto, se um nó de serviço de atualização raiz 300 não fosse para servir diretamente os computadores cliente, o módulo de atualização de cliente 204 poderia ser omitido.

[0040] O módulo de relatório 208 é opcional para um nó de serviço de atualização raiz 300 porque um nó de serviço de atualização raiz não possui nó de serviço de atualização pai para quem os relatórios de atualização são proporcionados. Entretanto, até a extensão em que os relatórios de atualização são desejáveis para o administrador do nó de serviço de atualização raiz, o módulo de relatório 208 pode ser opcionalmente incluído.

[0041] Em adição a compreender os componentes lógicos incluídos em um nó de serviço de atualização 200 (Figura 2), o nó de serviço de atualização raiz 300 também inclui uma interface com o provedor de software 302. A interface com o provedor de software 302 proporciona a interface de comunicação pela qual um provedor de software 110 (Figura 1) submete atualizações de software diretamente para o nó de serviço de atualização raiz 300 e indiretamente para o sistema ilustrativo de distribuição de atualização 100.

[0042] Similar ao nó de serviço de atualização 200 da Figura 2, a descrição acima da Figura 3 ilustra vários componentes de um módulo de serviço de atualização raiz ilustrativo 300. Entretanto, deve ser apreciado que outros componentes de um módulo de serviço de atualização raiz também podem existir. Adicionalmente, os componentes descritos acima devem ser entendidos como sendo componentes lógicos, não necessariamente componentes reais. Em uma implementação real, os componentes identificados acima podem ser combinados juntos e/ou com outros componentes de acordo com as determinações da implementação. Adicionalmente, deve ser apreciado que enquanto um nó de serviço de atualização raiz 200 pode ser visto como um computador servidor em uma rede, em uma implementação real, um nó de serviço de atualização pode ser implementado em qualquer número de dispositivos de computação. Por exemplo, o nó de serviço de atualização raiz 300 pode ser implementado e/ou instalado em um único sistema de computação independente ou, alternativamente, em um sistema de computação distribuído compreendendo vários dispositivos de computação.

[0043] De modo a melhor entender como uma atualização é distribuída a partir do nó de serviço de atualização raiz para todo um sistema de distribuição de atualização 100, é autorizada uma ilustração de uma troca ilustrativa entre um nó de serviço de atualização pai e um nó de serviço de atualização filho. A Figura 4 é um diagrama de blocos ilustrando uma troca ilustrativa 400 entre um nó de serviço de atualização pai 402 e um nó de serviço de atualização filho 404 ao propagar uma atualização de software a partir do nó de serviço de atualização pai para o nó de serviço de atualização filho, de acordo com aspectos da presente invenção. Como pode ser visto, o diagrama ilustrativo 400 é dividido na metade, cuja metade esquerda corresponde às ações e eventos do nó de serviço de atualização pai 402 e a metade direita correspondendo às ações e eventos do nó de serviço de atualização filho 404.

[0044] Para propósitos de discussão com respeito à Figura 4, deve ser adicionalmente entendido que o nó de serviço de atualização pai 402 pode ou não ser o nó de serviço de atualização raiz no sistema de distribuição de atualização 100. Adicionalmente, para propósitos desta discussão, é assumido que o nó de serviço de atualização pai 402 foi configurado por administrador de modo que o nó de serviço de atualização filho 404 possa não receber atualizações de software a não ser que explicitamente autorizado a fazer isto pelo administrador.

[0045] Como apresentado na troca ilustrativa 400, começando no evento 406, o nó de serviço de atualização pai 402 recebe uma atualização de software a partir de um provedor de software 110, diretamente, se o nó de serviço de atualização pai for o nó de serviço de atualização raiz 102, ou indiretamente, através do sistema de distribuição de atualização 100. Em algum ponto após o nó de serviço de atualização pai 402 receber a atualização de software a partir do provedor de software 110, o nó de serviço de atualização filho 404 começa um processo para obter atualizações de software a partir do nó de serviço de atualização pai.

[0046] De acordo com uma modalidade, um nó de serviço de atualização filho 404 pode ser configurado para automaticamente obter atualizações de software disponíveis a partir de um nó de serviço de atualização pai 202 em uma base periódica. Mais particularmente, um administrador, via a interface com o usuário de administração 218, pode seletivamente configurar o nó de serviço de atualização filho 404 para automaticamente obter as últimas atualizações de software disponíveis no nó de serviço de atualização pai 402 em uma base periódica. Como um exemplo, um administrador pode configurar o nó de serviço de atualização filho 404 para obter as últimas atualizações de software a partir de seu nó de serviço de atualização pai 402 e uma base diária e/ou de hora em hora, bem como especificar a hora do dia em que o processo de atualização automático é para começar. Outras programações periódicas e critérios podem também ser utilizados. De forma similar, um administrador pode manualmente iniciar o processo de atualização através da interface com o usuário de administração 218.

[0047] Para começar o processo de atualização, no evento 408, o nó de serviço de atualização filho 404 autentica e autoriza a si próprio com o nó de serviço de atualização pai 402. A autenticação e a autori- zação com o nó de serviço de atualização pai 402 proporciona um elemento de controle em relação à distribuição das atualizações de software, limitando a distribuição de atualização aos nós de serviço de atualização autorizados. As técnicas de autenticação e de autorização são bem conhecidas na técnica, e qualquer número das mesmas pode ser empregado para autenticar e autorizar um nó de serviço de atualização filho 404 com o nó de serviço de atualização pai 402. A presente invenção não está restrita a qualquer técnica.

[0048] Após de forma apropriada autenticar e autorizar com o nó de serviço de atualização pai 402, no evento 410, o nó de serviço de atualização pai 402 retorna uma indicação de autorização para o nó de serviço de atualização filho 404. De acordo com uma modalidade, uma indicação de autorização é uma indicação sensível ao tempo proporcionando ao nó de serviço de atualização filho 404 autorização para conduzir atividades adicionais de atualização com o nó de serviço de atualização pai durante uma quantidade de tempo limitada. Assim, se o nó de serviço de atualização filho 404 não for apropriadamente autenticado e autorizado com o nó de serviço de atualização pai, nenhuma indicação de autorização é retornada e o nó de serviço de atualização filho fica inapto a executar quaisquer outras atividades relacionadas com atualização, exceto autenticação e autorização. De forma similar, após a indicação de atualização ter expirado, o nó de serviço de atualização filho 404 fica inapto a executar quaisquer atividades adicionais relacionadas com atualização com o nó de serviço de atualização pai, exceto nova autenticação e nova autorização.

[0049] Após receber aa indicação de autorização, no evento 412, o nó de serviço de atualização filho 404 submete uma requisição para o nó de serviço de atualização pai por um catálogo de atualização de produto junto com a indicação de autorização. Um catálogo de atualização de produto representa uma listagem, ou tabela de conteúdos, de produtos de software para os quais o nó de serviço de atualização pai 402 distribui atualizações de software.

[0050] De acordo com aspectos da presente invenção, o nó de serviço de atualização filho 404 não é requerido de propagar todas as atualizações de software disponíveis em seu nó de serviço de atualização pai 402. Por exemplo, com referência ao sistema ilustrativo de distribuição de atualização da Figura 1, o nó coorporativo de serviço de atualização 104 pode ter licenças locais para somente uma fração dos produtos de software disponíveis no nó de serviço de atualização raiz 102. Por conseqüência, seria desnecessário para o nó coorporativo de serviço de atualização 104 obter todas as atualizações de software disponíveis no nó de serviço de atualização raiz 102, a medida que a maioria nunca seria utilizada. Por conseqüência, um administrador em um nó de serviço de atualização pode seletivamente estabelecer quais atualizações de produto de software estarão disponíveis no nó de serviço de atualização.

[0051] De acordo com um aspecto da presente invenção, o catálogo de atualização de produto, obtido a partir de um nó de serviço de atualização pai 402, identifica todos os produtos de software para os quais atualizações estão disponíveis, quer ou não o nó de serviço de atualização filho 404 esteja configurado para distribuir atualizações para cada produto. Entretanto, de acordo com um aspecto alternativo da presente invenção, o catálogo de atualização de produto, obtido a partir de um nó de serviço de atualização pai 402, identifica somente estes produtos de software para os quais o nó de serviço de atualização filho requisitante está configurado para distribuir atualizações. Por exemplo, limitar quais produtos de software estão listados no catálogo de atualização de produto pode ser determinado de acordo com o grupo ou grupos aos quais o nó de serviço de atualização filho 404 pertence.

[0052] No evento 414, o nó de serviço de atualização pai 402 re- torna um catálogo de atualização de produto para o nó de serviço de atualização filho 404. No evento 416, o nó de serviço de atualização filho 404 seleciona estes produtos a partir do catálogo de atualização de produto para os quais as últimas atualizações são atualmente desejadas. Deve ser observado que mesmo que no entanto o catálogo de atualização de produto possa listar somente estes produtos de software que o nó de serviço de atualização filho 404 distribui, o nó de serviço de atualização filho pode ser configurado para obter atualizações para produtos de software diferentes em momentos diferentes ou em programações periódicas diferentes.

[0053] No evento 418, o nó de serviço de atualização filho 404 submete uma requisição de sincronização de atualização, junto com a identificação de autorização, identificando os produtos selecionados para cujas atualizações o nó de serviço de atualização filho está atualmente buscando. Incluída na requisição de sincronização está a informação identificando a última atualização disponível para um produto no nó de serviço de atualização filho 404. A informação identificando a última atualização para um produto é depois disso referida como uma “âncora de atualização”. As âncoras de atualização para cada produto de software são tipicamente armazenadas na memória de informação de atualização 216 (Figura 2). Em uma modalidade, uma âncora de atualização inclui um número de revisão e uma data associada com o número de revisão.

[0054] Em resposta à requisição de sincronização de atualização, no evento 420, o nó de serviço de atualização pai 402 determina quais, se houverem, novas atualizações estão disponíveis para o nó de serviço de atualização filho 404. Como mencionado acima, esta determinação é baseada nas regras específicas associadas com atualizações de software particulares e com o grupo ou grupos dos quais um nó de serviço de atualização filho 404 é um membro, bem como na âncora de atualização. Para este exemplo, como anteriormente mencionado, a atualização de software anteriormente recebida foi explicitamente não autorizada para o nó de serviço de atualização filho 404. Portanto, a atualização de software recebida no evento 406 não é determinada como estando “disponível” para o nó de serviço de atualização filho 404. Por conseqüência, no evento 422, uma lista de atualizações é retornada para o nó de serviço de atualização filho 404 sem identificar a atualização de software recebida no evento 406. De acordo com aspectos da presente invenção, a lista de atualizações identifica todas as atualizações “disponíveis” no nó de serviço de atualização pai 402 de acordo com a requisição de sincronização. Em uma modalidade, a lista de atualizações identifica cada informação de atualização “disponível” por um identificador único associado com uma atualização.

[0055] No evento 424, devido à lista de atualizações estar vazia, isto é, nenhuma atualização está atualmente “disponível” no nó de serviço de atualização pai 402, o processo de atualização do nó de serviço de atualização filho 404 simplesmente protela, ou adormece, durante um período de tempo predeterminado. De acordo com o exemplo atual, durante este período de protelação, no evento 426, um administrador no nó de serviço de atualização pai 402 autoriza a atualização de software, recebida no evento 406, de ser distribuída para o nó de serviço de atualização filho 404.

[0056] No evento 428 (Figura 4B), o nó de serviço de atualização filho 404 novamente começa o processo de atualização automático por autenticar e autorizar a si próprio com o nó de serviço de atualização pai 402. Em resposta, no evento 430, o nó de serviço de atualização pai 402 retorna uma indicação de autorização para o nó de serviço de atualização filho 404.

[0057] No evento 432, o nó de serviço de atualização filho 404 submete uma requisição, junto com a indicação de autorização, para o nó de serviço de atualização pai 402 em relação a um catálogo de atualização de produto. No evento 434, o nó de serviço de atualização pai 402 retorna o catálogo de atualização de produto para o nó de serviço de atualização filho 404. No evento 436, o nó de serviço de atualização filho 404 seleciona os produtos para o catálogo de atualização para os quais atualizações são desejadas. No evento 438, o nó de serviço de atualização filho 404 submete a requisição de sincronização de atualização identificando estes produtos selecionados com a indicação de autorização.

[0058] Devido ao nó de serviço de atualização filho 404 ter sido autorizado a obter a atualização de software anteriormente recebida no evento 406, no evento 440, o nó de serviço de atualização pai 402 determina que a atualização de software está “disponível” para o nó de serviço de atualização filho e inclui a informação de atualização correspondente na lista de atualizações. Depois disso, no evento 442, o nó de serviço de atualização pai 402 retorna a lista de atualizações, agora identificando a atualização de software recebida no evento 406, para o nó de serviço de atualização filho 404.

[0059] Com uma lista de atualizações identificando uma atualização “disponível” no nó de serviço de atualização pai 402, o nó de serviço de atualização filho 404 agora possui a informação necessária para obter a atualização de software. De acordo com uma modalidade da presente invenção, um nó de serviço de atualização filho 404 obtém a atualização de software a partir do nó de serviço de atualização pai 402 em duas partes: obtendo os metadados da atualização e obtendo o conteúdo ou arquivo de atualização, daqui por diante referido como a carga útil de atualização. De acordo com aspectos adicionais da presente invenção, os metadados de atualização descrevem aspectos pertinentes da atualização de software, incluindo, mas não limitado a: um identificador de atualização que de forma única identifica a atuali- zação, informação de número de revisão associada com a atualização de software, se a atualização de software deve ser considerada uma prioridade, informação específica do idioma, relações com outras atualizações de software, localização da carga útil da atualização para propósitos de transferência, rotinas manipuladoras da instalação e coisas parecidas.

[0060] Algumas das razões pelas quais é sempre benéfico transferir toda a atualização de software em duas partes, isto é, os metadados da atualização e a carga útil da atualização, é que a carga útil da atualização freqüentemente é substancialmente maior do que os metadados da atualização e a carga útil da atualização nem sempre é imediatamente necessária, isto é, necessária para instalação em um computador cliente, se ela for realmente necessária. Assim, de acordo com uma modalidade da presente invenção, a carga útil da atualização é transferida separadamente dos metadados da atualização e somente quando necessária. Os com conhecimento na técnica irão reconhecer esta técnica de transferência como transferência preguiçosa, ou alternativamente, como transferência no momento certo. De acordo com aspectos da presente invenção, um administrador pode configurar um nó de serviço de atualização para obter a carga útil da atualização de um modo no momento certo, ou imediatamente quando obtendo os metadados da atualização. Adicionalmente, em uma modalidade alternativa, tanto os metadados da atualização como a carga útil da atualização podem ser transferidos juntamente.

[0061] Como apresentado na Figura 4B, com uma atualização identificada na lista de atualizações, no evento 444, o nó de serviço de atualização 404 requisita os metadados da atualização para a atualização de software “disponível” de acordo com seu identificador único na lista de atualizações. Como com a maioria das outras trocas de comunicação com o nó de serviço de atualização pai 402, a requisição de atualização é submetida com a indicação de autorização. Deve ser observado que enquanto no exemplo ilustrado todos os metadados de atualização são transferidos em um acesso, de acordo com aspectos alternativos da presente invenção (não apresentados), os metadados da atualização podem ser transferidos em mais do que um acesso. Por exemplo, em um primeiro acesso, somente elementos dos metadados da atualização para.....são necessários para determinar se uma atua- lização de software é aplicável e/ou desejável, são primeiro transferidos, tal como regras de aplicabilidade e dependências em relação a outras atualizações de software. Então, após ser determinado que uma atualização é aplicável e/ou desejável, a restante dos metadados da atualização podem ser obtidos. Em resposta, no evento 446, o nó de serviço de atualização pai 402 retorna os metadados da atualização para a atualização de software para o nó de serviço de atualização filho 404, o qual por sua vez armazena os metadados da atualização na memória de informação de atualização 216.

[0062] Em uma modalidade, os metadados da atualização incluem, mas não estão limitados a: um identificador único associado com uma atualização particular; uma descrição da atualização, tal como tamanho da atualização, problemas endereçados pela atualização, informação de revisão / âncora e coisas parecidas; regras de aplicabilidade da atualização, tal como se a atualização requer que uma atualização prévia seja instalada, se a atualização deve ser instalada separadamente, se a atualização substitui outras atualizações disponíveis e coisas parecidas; dados de acordo de licença de usuário final; e informação de URL para localizar e/ou acessar a carga útil da atualização se ela não estiver armazenada no nó de serviço de atualização pai 402.

[0063] Opcionalmente, no evento 448, o nó de serviço de atualização filho 404 submete uma requisição para transferir a carga útil da atualização a partir do nó de serviço de atualização pai 402. Em res- posta, no evento 450, o nó de serviço de atualização pai 402 retorna a carga útil da atualização para o nó de serviço de atualização filho 404, o qual por sua vez armazena a mesma na memória de conteúdo de atualização 214.

[0064] Devido à atividade de atualização ter agora ocorrido no nó de serviço de atualização filho 404, no evento 452, o nó de serviço de atualização filho gera e submete um relatório de atualização para o nó de serviço de atualização pai 402 esboçando as atividades de atualização que acabaram de ter ocorrido. Depois disso, o nó de serviço de atualização filho 404 novamente protela até a próxima vez em que o processo de atualização é programado de funcionar (não apresentado).

[0065] Os com conhecimento na técnica irão apreciar que os eventos descritos acima são para propósitos de ilustração e refletem um conjunto de eventos e circunstâncias ilustrativas particulares. Claramente, outros eventos podem também ocorrer de acordo com os detalhes e circunstâncias específicas que irão causar alguma variação junto aos eventos descritos acima. Adicionalmente, deve ser entendido que enquanto o nó de serviço de atualização filho 404 está obtendo as últimas atualizações de software “disponíveis” a partir do nó de serviço de atualização pai 402, o nó de serviço de atualização filho pode simultaneamente estar processando requisições de atualização a partir de seus nós de serviço de atualização filhos. Por conseqüência, a se-qüência de eventos acima deve ser vista somente como ilustrativa e não limitando a presente invenção.

[0066] A Figura 5 é um fluxograma ilustrando uma rotina ilustrativa 500 executada em um nó de serviço de atualização filho, tal como o nó coorporativo de serviço de atualização 104 da Figura 1, para periodicamente obter atualizações a partir de seu nó de serviço de atualização pai. Começando no bloco 502, o nó de serviço de atualização filho obtém uma lista de atualizações sincronizadas de atualizações “dispo- níveis” a partir do nó de serviço de atualização pai. A obtenção de uma lista de atualizações sincronizadas de atualizações “disponíveis” a partir do nó de serviço de atualização pai é descrita abaixo com respeito à Figura 6.

[0067] A Figura 6 é um fluxograma de uma sub-rotina ilustrativa 600, adequada para uso na rotina ilustrativa 500 da Figura 5, para obter uma lista de atualizações sincronizadas de atualizações “disponíveis” a partir de um nó de serviço de atualização pai. Começando no bloco 602, como anteriormente discutido com respeito às Figuras 4A e 4B, o nó de serviço de atualização filho autentica e autoriza a si próprio com o nó de serviço de atualização pai e em resposta à autenticação e à autorização apropriadas, recebe uma indicação de autorização. No bloco 604, em conjunto com a indicação de autorização, o nó de serviço de atualização filho estabelece parâmetros de comunicação com o nó de serviço de atualização pai. Estabelecer parâmetros de comunicação permite aos nós de serviço de atualização pai e filho de forma apropriada estabelecer uma base comum que tanto o pai como o filho entende. Os parâmetros de comunicação incluem, mas não estão limitados a: protocolos ou versões de atualização de comunicação; grupamentos de produtos; e coisas parecidas.

[0068] Após ter estabelecido os parâmetros de comunicação com o nó de serviço de atualização pai, no bloco 606, o nó de serviço de atualização filho obtém um catálogo de atualização de produto descrevendo os produtos de software para os quais o nó de serviço de atualização pai proporciona / distribui atualizações. No bloco 608, o nó de serviço de atualização filho seleciona as atualizações de produto de software para as quais as atualizações são correntemente procuradas. No bloco 610, o nó de serviço de atualização filho submete a requisição de sincronização de atualização para o nó de serviço de atualização pai, incluindo tanto a indicação de autorização como uma “âncora” associada com os produtos de software selecionados identificando a revisão corrente e as atualizações já no nó de serviço de atualização filho.

[0069] Em resposta à requisição de sincronização de atualização, no bloco 612, o nó de serviço de atualização filho obtém uma lista de atualizações a partir do nó de serviço de atualização, sincronizadas de acordo com as atualizações de software “disponíveis” no nó de serviço de atualização pai de acordo com o que está correntemente armazenado no nó de serviço de atualização filho. Como mencionado acima, a lista de atualizações identifica, por um identificador único, estas atualizações de software no nó de serviço de atualização pai que estão “disponíveis” para o nó de serviço de atualização filho. Depois disso, a sub-rotina ilustrativa 600 termina.

[0070] Com referência novamente à Figura 5, após ter obtido uma lista de atualizações sincronizadas a partir do nó de serviço de atualização pai, no bloco de decisão 504, é feita uma determinação quanto a se quaisquer atualizações de software estão correntemente “disponíveis” para transferência a partir do nó de serviço de atualização pai. Esta determinação é feita de acordo com se existem quaisquer identificadores de atualização listados na lista de atualizações sincronizadas. Se nenhuma atualização de software estiver correntemente “disponível” para transferência, a rotina ilustrativa 500 continua para o bloco de protelação 510, onde a rotina ilustrativa protela / adormece até que o próximo período de atualização ocorra. Alternativamente, se existirem atualizações “disponíveis” para transferência a partir do nó de serviço de atualização pai, no bloco 506, o nó de serviço de atualização filho obtém as atualizações a partir do nó de serviço de atualização pai. Obter atualizações “disponíveis” a partir do nó de serviço de atualização pai é descrito abaixo com respeito à Figura 7.

[0071] A Figura 7 é um fluxograma de uma sub-rotina ilustrativa 700, adequada para uso na rotina ilustrativa 500 da Figura 5, para obter atualizações de software “disponíveis” a partir de um nó de serviço de atualização pai. Começando no bloco 702, um primeiro identificador de atualização na lista de atualizações é selecionado. No bloco 704, o nó de serviço de atualização filho obtém os metadados da atualização correspondendo ao identificador de atualização selecionado a partir do nó de serviço de atualização pai e armazena os mesmos na memória de informação de atualização 216.

[0072] De acordo com uma modalidade, no bloco 706, o nó de serviço de atualização filho obtém a carga útil de atualização correspondendo ao identificador de atualização selecionado a partir do nó de serviço de atualização pai e armazena a carga útil de atualização na memória de conteúdo de atualização 212. Opcionalmente, o conteúdo da atualização não precisa ser imediatamente transferido para o nó de serviço de atualização filho. Como anteriormente mencionado, um nó de serviço de atualização filho pode ser seletivamente configurado para transferir atualizações a partir de um nó de serviço de atualização pai de um modo no momento certo. De acordo com este tratamento opcional, como ilustrado na Figura 7, ao invés de continuar a partir do bloco 704 para o bloco 706, a sub-rotina ilustrativa 700 opcionalmente continua do bloco 704 para o bloco de decisão 708.

[0073] No bloco de decisão 708, após ter obtido os metadados da atualização para o identificador de atualização selecionado e opcionalmente a carga útil da atualização, é feita uma determinação quanto a se existem quaisquer identificadores de atualização adicionais na lista de atualizações. Se existirem identificadores de atualização adicionais, no bloco 710, o próximo identificador de atualização na lista de atualizações é selecionado e a sub-rotina 800 retorna para o bloco 704 para processamento adicional. A rotina 700 continua até que, no bloco de decisão 708, é determinado que não existem mais identificadores de atualização na lista de atualizações, depois do que a sub-rotina ilustrativa 700 termina.

[0074] Retornando novamente à Figura 5, após ter obtido as atualizações “disponíveis” a partir do nó de serviço de atualização pai, no bloco 508, o nó de serviço de atualização filho relata as atividades de atualização para o nó de serviço de atualização pai. Depois disso, no bloco de protelação 510, a rotina ilustrativa 500 protela / adormece durante um período de tempo predeterminado até que o próximo período de atualização e então continua para o bloco 502 para repetir os procedimentos de atualização identificados acima.

[0075] Como ilustrado na Figura 5, no bloco de decisão 504, mesmo quando nenhuma atualização está “disponível” em um nó de serviço de atualização pai, um nó de serviço de atualização filho pode ser opcionalmente configurado para relatar suas atividades de atualização para o nó de serviço de atualização pai. De acordo com esta configuração alternativa, quando não existem atualizações disponíveis, a rotina ilustrativa 500 pode continuar para o bloco 508 e relatar as atividades de atualização.

[0076] A Figura 8 é um fluxograma de uma rotina ilustrativa 800, implementada em um nó de serviço de atualização pai, para gerar uma lista de atualizações sincronizadas identificando atualizações “disponíveis” em resposta a uma requisição de sincronização de atualização a partir de um nó de serviço de atualização filho. Começando no bloco 802, o nó de serviço de atualização pai recebe uma requisição de sincronização de atualização a partir de um nó de serviço de atualização filho para uma lista de atualizações identificando atualizações “disponíveis”. No bloco 804, o primeiro produto de software identificado na requisição de sincronização de atualização é selecionado.

[0077] No bloco de decisão 806, é feita uma determinação quanto a se existem quaisquer atualizações disponíveis para o produto de sof- tware identificado. Esta determinação é feita de acordo com metada-dos para o produto de software armazenados na memória de informação de atualização 216, de acordo com a âncora de atualização proporcionada pelo nó de serviço de atualização filho e de acordo com as regras de distribuição associadas com o grupo ao qual o nó de serviço de atualização filho pertence. De acordo com esta determinação, se existirem atualizações “disponíveis”, no bloco 808, identificadores de atualização únicos associados com as atualizações “disponíveis” são gravados em uma lista de atualizações. Após ter gravado identificadores de atualização únicos para atualizações “disponíveis” na lista de atualizações, no bloco de decisão 810, é feita uma determinação quando a se existem quaisquer produtos de software adicionais identificados na requisição de sincronização de atualização. Se existirem produtos de software de atualização adicionais na requisição de sincronização de atualização, no bloco 814, o nó de serviço de atualização pai seleciona o próximo produto de software identificado na requisição de sincronização de atualização e retorna para o bloco de decisão 806 para determinar se existem atualizações “disponíveis” para o produto de software selecionado. Alternativamente, se não existirem mais produtos de software identificados na requisição de sincronização de atualização, no bloco 814, a lista de atualizações é retornada para o nó de serviço de atualização filho. Depois disso, a sub-rotina ilustrativa 800 termina.

[0078] Como mencionado acima, um nó de serviço de atualização é administrado através da API de administração 212 via a interface com o usuário de administração 218, ou via algum outro módulo de forma similar equipado. Para melhor entender como a API de administração 212 opera, a Figura 9 é um diagrama ilustrado para ilustrar como a API de administração é utilizada com respeito a configurar um nó de serviço de atualização para distribuir atualizações de software para computadores clientes.

[0079] Como apresentado na Figura 9, um administrador utiliza a API de administração para gerar subscrições 904 e grupos 906. O nó de serviço de atualização, durante um processo de atualização 908, utiliza as atualizações 902 disponíveis para este nó de serviço de atualização, bem como as subscrições 904 e os grupos 906, para distribuir as atualizações para computadores clientes, tal como os computadores clientes 912 a 922.

[0080] Como os com conhecimento na técnica irão apreciar, um administrador gera uma subscrição para atualizações para um produto particular ou família de produtos, bem como a classe de atualização. Por exemplo, um produto pode ser o produto Internet Explorer da Microsoft Corporation e uma subscrição indicaria este produto em espera por atualizações disponíveis. De forma similar, uma família de produtos tipicamente indicaria uma série de produtos, tal como Office da Microsoft Corporation como uma família de produtos, que inclui vários produtos identificáveis. As subscrições tipicamente também identificam o tipo de atualização que é aprovada para transferência para os computadores clientes. Por exemplo, o tipo de uma atualização pode ser crítico, séria, geral, etc.

[0081] De acordo com uma modalidade da presente invenção, os computadores clientes são organizados em grupos, e as subscrições e atualizações são aplicadas junto aos grupos. Em uma modalidade real, cada computador cliente pertence a dois grupos: um grupo de todos os computadores e a um outro grupo. De acordo com esta modalidade real, o nó de serviço de atualização definiu o grupo de todos os computadores e o outro, um grupo de computadores não designados. Através da API de administração 212, o administrador está livre para definir qualquer número de outros grupos e os computadores clientes designados para um grupo. Na falta de designar um computador cliente para um grupo, deixa-se o computador cliente no grupo não designado. Em resumo, de acordo com esta modalidade, um computador cliente pertence ao grupo de todos os computadores e a um outro. Os grupos podem incluir qualquer número de computadores clientes. Os grupos de computadores clientes, para aplicação de atualizações de software, são ilustrados na Figura 9 como as caixas 910, 924 e 926.

[0082] De acordo com uma modalidade real, a API de administração 212 é a interface através da qual os Serviços de Atualização de Software Windows da Microsoft Corporation são configurados e administrados. Nesta modalidade, a API de administração 212 é geralmente implementada por ou acessada através do objeto de interface lUpda-teServer. A descrição de uma modalidade real do objeto de interface lUpdateServer é listada no fim desta seção como Tabela 1. Este objeto de interface lUpdateServer é parte do documento da API de administração incluído como parte do Pedido Provisório U.S. 60/553.042, depositado em 12 de março de 2004, o qual é incorporado neste documento por referência. Entretanto, várias chamadas de interface identificadas na Tabela 1 são descritas geralmente abaixo com respeito à Figura 10.

[0083] A Figura 10 é um diagrama de blocos ilustrando certas chamadas da API de administração para administrar a distribuição de atualizações de software em um nó de serviço de atualização. Com acesso a um objeto lUpdateServer 1002, um chamado pode fazer chamadas de interface para obter a informação de configuração do nó de serviço de atualização 1004, a informação de subscrição corrente 1006, as regras de aprovação correntes 1008, a informação de condição do nó de serviço de atualização 1010, obter as atualizações 1012, obter os computadores clientes 1014 e obter os grupos 1016.

[0084] A chamada de interface de informação de configuração 1004 proporciona acesso aos valores configuráveis (e legíveis) do nó de serviço de atualização, incluindo, mas não limitado aos idiomas disponíveis, quem é o nó de serviço de atualização pai e a localização para este nó de serviço de atualização pai, servidores auxiliares e endereços, o modo no qual o nó de serviço de atualização sincroniza as atualizações com seu nó de serviço de atualização pai e coisas parecidas. Em uma modalidade real, como descrito no apêndice anexo, a chamada de interface de informação de configuração 1004 é a chamada de interface “GetConfiguration” no objeto lUpdateServer, a qual retorna uma instâncias de um objeto de interface IConfiguration para o nó de serviço de atualização. O objeto de interface IConfiguration é descrito em maiores detalhes na API incorporada do pedido provisório.

[0085] A chamada de interface de informação de subscrição 1006 proporciona acesso à informação de subscrição, mas não limitado à condição dos esforços de subscrição mais recentes, quando o próximo esforço de subscrição (por exemplo, transferir uma atualização particular para um computador cliente) será completado, a freqüência da sincronização de subscrição e coisas parecidas. Em uma modalidade real, existem pelo menos duas chamadas de interface diferentes para obter a informação de subscrição. A chamada de interface “GetSubs-cription” no objeto lUpdateServer retorna um objeto de interface ISubs-cription correspondendo a uma subscrição específica no nó de serviço de atualização e a chamada de interface “GetSubscription” retorna uma coleção de objetos de interface ISubscription. Adicionalmente, uma subscrição é criada utilizando a chamada de interface “CreateSubscrip-tion”, a qual cria uma subscrição vazia no nó de serviço de atualização. Os detalhes do objeto de interface ISubscription são descritos na API incorporada do pedido provisório.

[0086] A chamada de interface de condição de nó de serviço de atualização 1010 proporciona acesso à condição do nó de serviço de atualização, mas não limitado às atualizações atualmente dispostas, às atualizações disponíveis e coisas parecidas. Em uma modalidade real, a chamada de interface “GetUpdatesSummary” retorna um objeto de coleção resumo descrevendo toda a informação de resumo de atualização para o nó de serviço de atualização. Os detalhes com respeito a esta interface são descritos na API incorporada do pedido provisório.

[0087] A chamada de interface que obtém atualizações 1012 proporciona acesso à informação com respeito às atualizações de software disponíveis. Mais particularmente, a chamada de interface proporciona acesso a todas as atualizações de software disponíveis no sistema. Em uma modalidade real, existem várias chamadas de interface para obter a informação de atualização. A chamada de interface “Ge-tUpdate” retorna um objeto lUpdate que proporciona informação com respeito a uma atualização específica no sistema. Adicionalmente, a chamada de interface “GetUpdates” retorna uma coleção de objetos lUpdates disponíveis para o sistema. Detalhes adicionais com respeito a estas chamadas de interface são proporcionados na API incorporada do pedido provisório.

[0088] A chamada de interface que obtém computadores 1014 proporciona acesso aos computadores clientes associados com o nó de serviço de atualização. Em uma modalidade real, existem pelo menos duas chamadas de interface para acessar informação com respeito aos vários computadores clientes, incluindo, mas não limitado à chamada de interface “GetComputer” que retorna um objeto IComputer correspondendo a um computador cliente identificado na chamada de interface e uma chamada de interface “GetComputers” que retorna uma coleção de objetos IComputer, a coleção incluindo todos os computadores cliente associados com o nó de serviço de atualização. Como acima, detalhes adicionais com respeito a estas chamadas de interface no objeto lUpdateServer são descritos na API incorporada do pedido provisório.

[0089] A chamada de interface que obtém grupos 1016 proporciona acesso aos grupos definidos no nó de serviço de atualização. Como mencionado acima, em uma modalidade real, cada computador cliente pertence ao grupo todos computadores e a um outro grupo. Se um computador cliente não estiver designado para um grupo, este computador cliente fica preestabelecido para o grupo não designado. Pelo menos nesta modalidade real, uma série de chamadas de interface estão disponíveis, incluindo, mas não limitadas a uma chamada de interface “GetTargetGroup” que retorna um objeto ITargetGroup correspondendo a um identificador de grupo passado para a chamada de interface e uma interface “GetTargetGroups” que retorna uma coleção de objetos ITargetGroup correspondendo a todos os grupos definidos no nó de serviço de atualização.

[0090] Os com conhecimento na técnica irão apreciar que enquanto algumas das chamadas de interface foram descritas, elas não são um conjunto exaustivo de chamadas de interface. Na verdade, como ilustrado no apêndice anexo, uma modalidade real de uma API de administração inclui várias chamadas de interface, cuja maioria não foi especificamente descrita.

[0091] Com respeito a tabela seguinte, a Tabela 1, a abreviatura WUS é uma acrônimo pára Servidor de Atualização Windows. TABELA 1 lUpdateServer Utilize esta interface para acessar os componentes do Servidor de Atualização A interface lUpdateServer é derivada da classe System.Object Métodos Públicos A interface lUpdateServer possui os seguintes métodos públicos Método Descrição CancelAIIDownload() Cancela atualizações que estão corren- temente sendo transferidas para o servidor WUS.

CreateComputerTar- Cria um grupo alvo que você utiliza para getGroup(String) computadores cliente alvo para atuali- zações.

Equalsobject) Determina se o Objeto especificado é igual ao Objeto corrente.

GetComponentsWithErros() Recupera uma lista de componentes do servidor que estão atualmente em um estado de erro.

GetComputersNotContac- Número de clientes que não reportaram tedSinceCount(DateTime) sua condição para o servidor WUS desde o tempo especificado.

GetComputerTarget(String) Recupera o computador cliente especificado.

GetComputerTar- Recupera o grupo alvo especificado. getGroup(Guid) GetComputerTargetGroups() Recupera uma coleção de todos os grupos alvo no servidor WUS.

GetComputerTargets() Recupera uma coleção de todos os computadores cliente que são conhecidos para o servidor WUS.

GetConfiguration() Recupera um lUpdateServerConfigura- tion que você utiliza para configurar o servidor WUS.

GetContentDownloadPro- Recupera o progresso de todas as atua- gress() lizações que estão correntemente em transferência.

GetDatabaseConfiguration() Recupera um IDatabaseConfiguration que você utiliza para determinar a configuração da base de dados.

GetDownstreamSer- Recupera uma interface para o servidor ver(String) WUS à jusante especificado.

GetDownstreamServers() Recupera uma coleção de servidores WUS à jusante que estão registrados com o servidor WUS.

GetHashCode() Serve como uma função hash para um tipo particular. GetHashCode é adequado para uso em algoritmos de função hash e para estruturas de dados como uma tabela hash.

GetlnstallApprovalRule() Recupera a regra de aprovação que é utilizada para automaticamente transferir e instalar atualizações nos computadores alvo.

GetRootUpdateCategories() Recupera uma coleção de categorias de nível mais alto do servidor WUS.

GetSeanApprovalRule() Recupera a regra aprovada utilizada para automaticamente varrer os computadores alvo para determinar se a atualização é aplicável.

GetStatus() Recupera estatísticas que resumem o estado corrente do servidor WUS, das atualizações e dos computadores cliente.

GetSubscription() Recupera uma instância de subscrição que você utiliza para gerenciar o processo de sincronização.

GetSubscriptionEvent(Guid) Recupera um evento de subscrição que identifica alterações junto à subscrição.

GetSynchronizationlnfo(Guid) Recupera informação que está relacionada com um processo de sincronização específico.

GetTypeQ Recupera o Tipo da instância corrente.

GetUpdate(UpdateRevisionld) Recupera a atualização especificada.

GetUpdateApproval(Guid) Recupera a aprovação especificada.

GetUpdateCategories() Recupera a lista de todas as categorias de atualização que são conhecidas para o servidor WUS.

GetUpdateCategori- Recupera as categorias de atualização es(DateTime, DateTime) que foram adicionadas dentro da faixa de dados especificada.

GetUpdateCategory(Guid) Recupera a categoria de atualizações para o dado identificador.

GetUpdateClassifica- Recupera a classificação da atualização tion(Guid) requisitada.

GetUpdateClassifications() Recupera uma coleção de classificações de atualização que são conhecidas para o servidor WUS.

GetUpdateClassifica- Recupera as classificações de atualiza- tions(DateTime, DateTime) ção que foram adicionadas dentro da faixa de dados especificada.

GetUpdateEventHis- Recupera todos os eventos da instala- tory(DateTime,DateTime) ção para todos os clientes para a faixa de dados especificada.

GetUpdateEventHis- Recupera todos os eventos da instala- tory(DateTime, DateTime, ção que foram promovidos pelo cliente IComputerTarget) especificado para a faixa de dados es- pecificada.

GetUpdateEventHis- Recupera todos os eventos da instala- tory(DateTime, DateTime, ção que foram promovidos por todos os lUpdate) clientes para a atualização e para a fai- xa de dados especificada.

GetUpdateEventHisto- Recupera eventos baseados nos crité- ry(DateTime, DateTime, rios especificados. lUpdate, WusEventSource, WusEventld[]) GetUpdates() Recupera uma coleção da última revi- são de cada atualização.

GetUpdates(ApprovedStates, Recupera uma coleção de atualizações DateTime, DateTime, Up- baseadas nos critérios especificados. dateCategoryCollection, Up-dateClassificationCollection) LogMessage(logLevel, String, Registra ima mensagem junto ao arqui-params Object[]) vo de registro de distribuição de softwa- re.

RegisterComputer(string) Registra computador cliente com o servidor WUS.

ResetAndVerifyContentState() Força a sincronização de todos os me- tadados de atualização no servidor WUS e verifica que todos os arquivos de atualização no servidor WUS sejam válidos.

ResumeAIIDowloadsO Identifica as atualizações para transfe- rência.

SeachComputerTar- Recupera uma coleção de computado- gets(String) res alvo cujo nome de domínio completo contenha uma dada cadeia de caracteres.

SearchUpdates(String) recupera uma coleção de atualizações cujos metadados contenham a dada cadeia de caracteres.

ToString() Recupera uma cadeia de caracteres e representa o Objeto corrente.

Propriedades Públicas A interface lUpdateServer possui a seguinte propriedade pública.

Propriedade Descrição PreferredCulture Recupera ou estabelece o código de idioma que você deseja que o servidor WUS utilize quando retornando cadeias de caracteres.

[0092] Enquanto várias modalidades, incluindo a modalidade preferida, da invenção foram ilustradas e descritas, será apreciado que várias alterações podem ser feitas nas mesmas sem afastar-se do espírito e do escopo da invenção.

REIVINDICAÇÕES

Claims (17)

1. Nó de serviço de atualização (200) possuindo uma interface de programação de aplicação para administrar a distribuição de atualizações de software no nó de serviço de atualização caracterizado pelo fato de que compreende: um armazenamento de atualização (214) para armazenar atualizações de software; um serviço de rede de atualização (202) através do qual o nó de serviço de atualização obtém atualizações de software a partir de um nó de serviço de atualização pai através de uma rede de comunicação, o nó de serviço de atualização obtendo as atualizações de software mais recentes a partir da atualização pai de hora em hora, e através do qual o nó de serviço de atualização distribui atualizações de software para nós de serviço de atualização filhos através da rede de comunicação, o nó de serviço de atualização sendo configurado para: obter, a partir do nó do serviço de atualização pai, um catálogo de produtos de software para os quais o nó do serviço de atualização distribui atualizações de software, retornar um token de autorização a um nó de serviço de atualização filho particular em resposta ao nó de serviço de atualização filho particular, e se autenticar e se autorizar com o nó de serviço de atualização, receber um pedido para o catálogo a partir do nó do serviço de atualização filho particular, o pedido incluindo o token de autorização, proporcionar responsivamente um catálogo que lista um conjunto limitado de produtos de software com base em um grupo de distribuição ao qual pertence o nó especial do serviço de atualização filho, e receber, a partir do nó do serviço de atualização filho par- ticular, uma solicitação de sincronização identificando produtos de software selecionados a partir do catálogo pelo nó de serviço de atualização filho particular, a solicitação de sincronização incluindo o token de autorização e as informações associadas aos produtos de software selecionados que identificam a revisão atual e as atualizações já iniciadas no nó especial do serviço de atualização filho; e uma interface de programação de aplicativo de administração (212), API, em que a API de administração é um objeto que expõe uma pluralidade de interfaces que são chamadas ao definir grupos de distribuição e estabelecer regras de distribuição associadas a cada grupo de distribuição, as regras de distribuição que especificam a distribuição de software atualizam os nós de serviço de atualização filho e computadores clientes incluídos nos respectivos grupos de distribuição; em que as atualizações de software compreendem meta-dados de atualização e carga útil de atualização, e a distribuição de atualizações de software para os nós de atualização filhos compreende o download (446) dos metadados de atualização para os nós de serviço de atualização filho e o download (450) da carga útil de atualização para os nós de serviço de atualização filho somente mediante solicitação dos nós de serviço de atualização filho.

2. Nó de serviço de atualização, de acordo com a reivindicação 1, caracterizado pelo fato de que a API de administração expõem uma chamada de interface que obtém configuração que retorna um objeto de interface de configuração para ler e gravar valores de configuração de administração de atualização de software junto ao nó de serviço de atualização.

3. Nó de serviço de atualização, de acordo com a reivindicação 2, caracterizado pelo fato de que o objeto de interface de configuração é um objeto de interface IConfiguration.

4. Nó de serviço de atualização, de acordo com a reivindicação 2, caracterizado pelo fato de que a API de administração expõem uma chamada de interface que obtém subscrição que retorna um objeto de interface de subscrição correspondendo a um identificador de subscrição passado para a chamada de interface que obtém subscrição.

5. Nó de serviço de atualização, de acordo com a reivindicação 4, caracterizado pelo fato de que o objeto de interface de subscrição é um objeto de interface ISubscription.

6. Nó de serviço de atualização, de acordo com a reivindicação 4, caracterizado pelo fato de que a API de administração expõem uma chamada de interface que obtém subscrições que retorna um objeto de interface de coleção de subscrições definido no nó de serviço de atualização.

7. Nó de serviço de atualização, de acordo com a reivindicação 4, caracterizado pelo fato de que a API de administração expõem uma chamada de interface que obtém atualização que retorna um objeto de interface atualização correspondendo a um identificador de atualização passado na chamada de interface que obtém atualização.

8. Nó de serviço de atualização, de acordo com a reivindicação 7, caracterizado pelo fato de que o objeto de interface atualização é um objeto de interface lUpdate.

9. Nó de serviço de atualização, de acordo com a reivindicação 7, caracterizado pelo fato de que a API de administração expõem uma chamada de interface que obtém atualizações que retorna um objeto coleção de atualizações contendo objetos de interface de atualização correspondendo aos valores passado na chamada de interface que obtém atualizações.

10. Nó de serviço de atualização, de acordo com a reivin- dicação 9, caracterizado pelo fato de que os valores passados para a chamada de interface que obtém atualizações incluem um objeto de estado disposto e um valor Boooleano de exclusão de atualizações ocultas.

11. Nó de serviço de atualização, de acordo com a reivindicação 9, caracterizado pelo fato de que a API de administração expõem uma chamada de interface que obtém computador que retorna um objeto computador cliente correspondendo a um computador cliente associado com o nó de serviço de atualização e que foi identificado na chamada de interface que obtém computador.

12. Nó de serviço de atualização, de acordo com a reivindicação 11, caracterizado pelo fato de que o objeto computador cliente é um objeto IComputer.

13. Nó de serviço de atualização, de acordo com a reivindicação 11, caracterizado pelo fato de que a API de administração expõem uma chamada de interface que obtém computadores que retorna um objeto coleção de computadores incluindo objetos de computador cliente correspondendo aos computadores cliente associados com o nó de serviço de atualização.

14. Nó de serviço de atualização, de acordo com a reivindicação 13, caracterizado pelo fato de que a API de administração expõem uma chamada de interface que obtém grupo que retorna um objeto grupo alvo que foi identificado na chamada de interface que obtém grupo.

15. Nó de serviço de atualização, de acordo com a reivindicação 14, caracterizado pelo fato de que a API de administração expõem uma chamada de interface que obtém grupos que retorna um objeto coleção de grupos alvo incluindo objetos de grupo alvo correspondendo aos grupos alvo no nó de serviço de atualização.

16. Nó de serviço de atualização, de acordo com a reivin- dicação 1, caracterizado pelo fato de que a API de administração é um objeto de interface lUpdateServer.

17. Nó de serviço de atualização, de acordo com a reivindicação 1, caracterizado pelo fato de que a API expõe: uma interface que obtém configuração que, quando chamada, retorna um objeto de interface de configuração para leitura e gravação de valores de configuração de administração de atualização de software para o nó de serviço de atualização; uma interface que obtém subscrição que, quando chamada, retorna um objeto de interface de subscrição definido no nó de serviço de atualização; uma interface que obtém atualização que, quando chamada, retorna um objeto de interface de atualização correspondendo a um identificador de atualização passado na chamada de interface que obtém atualização; uma interface que obtém atualizações que, quando chamada, retorna um objeto de coleção de atualizações contendo objetos de interface de atualização correspondendo aos valores passado na chamada de interface que obtém atualizações; uma interface que obtém computador que, quando chamada, retorna um objeto de computador cliente correspondendo a um computador cliente associado com o nó de serviço de atualização e que foi identificado na chamada de interface que obtém computador; uma interface que obtém computadores que, quando chamada, retorna um objeto de coleção de computadores incluindo objetos de computador cliente correspondendo aos computadores cliente associados com o nó de serviço de atualização; uma interface que obtém grupo que, quando chamada, retorna um objeto grupo alvo que foi identificado na chamada de interface que obtém grupo; euma interface que obtém grupos que, quando chamada, retorna um objeto de coleção de grupos alvo incluindo objetos de grupo alvo correspondendo aos grupos alvo no nó de serviço de atualização.