CN1777867B - 使用增量压缩打补丁更新文件的系统和方法 - Google Patents

Abstract

提供了用于更新计算装置上的一个或多个文件的系统和方法。客户机计算装置获取包括标识具有已安装文件的特定版本的特定增量补丁的索引的更新信息。在选择将实现哪一个可适用更新以后，客户机计算装置上的更新代理执行清查，以标识文件要更新的哪一版本已安装在机器上。更新代理选择对应的增量补丁，并向更新服务发送请求。

Description

使用增量压缩打补丁更新文件的系统和方法

发明领域

本发明涉及软件和计算机网络，尤其涉及管理和传递软件更新的系统和方法。

发明背景

市场上最常见的软件产品要经受连续的修订过程，以修补或升级特征和/或功能。软件产品或组件的每一次修订可能需要添加新的文件和/或用更加新版本的文件替换现有的文件。一旦销售商隔离了软件产品问题并创建了该问题的解决方案，他可能希望将该修补放入更新中，并令更新对顾客广泛地可用。软件销售商具有尽可能快和无故障地向顾客分发软件更新的商业动机。

因特网为顾客提供了一种获得软件产品的最近更新的重要渠道。因特网使用率的蓬勃发展造成了顾客对软件产品和更新在线提供用于下载的常见期望。促进因特网的使用来分发更新也是软件销售商所感兴趣的，因为它减少了他们的成本，并允许顾客在修补可用于下载后立即可获得所确定问题的修补。因特网上的销售商站点可被设计成令发现和查找应用程序的更新文件是非常简单的。文件下载的技术方面大多数已从用户的观点中消失，并且它现在通常由操作系统来处理。

在常规的方法中，软件销售商将软件更新构造为“包”用于下载。包通常是自提取的可执行文件，它具有设置程序，并且产品的更新文件的每一个被嵌入并被压缩以使包更小。包的大小通常是每一改变的文件的压缩后大小的总和，加上提取代码本身的大小。在执行时，包将所包含的每一文件提取到一临时位置，然后开始设置程序以将每一文件安装到系统目录中一正确的位置。以压缩形式发货的文件在它们被安装时被解压。同一位置中名字相同的任一现有文件将简单地被替换文件所覆盖。

即使因特网令软件更新的广泛和快速分发成为可能，然而网络传输的有限带宽导致了问题。常见软件应用程序的绝对大小导致了更新的下载大小变得不合理的大。通常，用于产品的各种问题的多个修补将被组合成一个更新。如果销售商以常规的基础更新软件产品，则更新包的下载大小将继续增长，这是因为销售商无法在假设用户已经具有来自较早更新的那些文件的假设上省略这些文件。由于更新包组合了若干的完整文件，即使文件被压缩，它也可能相当大。有时，即使在最快的调制解调器连接上，下载的带宽效率也被降低。

常规下载过程的耗时方面当然是不合需要的。在某些情况下，顾客在下载这些文件的过程中支付了长距离或连接时间的费用。连接时间的任何减少将减少这些顾客的直接金钱成本。销售商通常也具有关于他们所提供的下载大小的可辨识成本，因此减小尺寸也可给予他们直接的金钱收益。减小下载的尺寸将增加他们的可用网络带宽，从而允许他们用现有的网络服务器设备来服务更多的顾客。

下载大的更新所花费的长时间也令下载过程变得更易受各种网络连接问题的攻击。对于为什么因特网话路可能会被过早地断开连接有多个原因，包括电话线噪声、呼叫等待信号以及无意的命令。某些因特网服务供应商实施了连接时间限制，限制了用户可以在单个话路中在线的时间量。如果当网络连接被切断时用户正在下载大文件，则他或她可能必须从头开始。最常见的操作系统和文件传输协议不允许文件传输的再继续，因此任何中间的进度将会丢失，并且传输必须重新开始。失败的几率如此之大，以致于许多用户发现在线获取更新几乎是不可能的。如果更新包的尺寸太大，则用户可能永远也无法完整地下载它。

减小软件更新的尺寸并提高带宽效率的一种尝试涉及增量补丁，或二进制补丁的使用。本领域的技术人员可以理解，增量补丁对应于当由计算装置执行时修改现有文件的专用软件代码。由于增量补丁包括专用软件代码，因此对文件的每一唯一版本需要唯一的增量补丁。当应用于软件更新时，软件更新服务可发送较小尺寸的更新增量补丁，而非发送完整的更新文件。已更新的增量补丁然后用于将现有文件修改成已更新的文件。

尽管更新增量补丁可潜在地减少更新文件所需的数据量，然而现有的增量打补丁方法在存在大量的文件版本的情况下管理可适用的增量文件的选择时是不够的。由于对文件的每一版本需要唯一的增量补丁，因此典型的软件更新系统通常会要求上百(如果不是上千)个对应于文件的每一唯一版本的唯一增量补丁。在一种方法中，支持增量打补丁的某些更新服务将所有可能的增量补丁发送到客户机计算装置。然而，这一方法通常在可能更新增量补丁的数量增加时也增加了实现软件更新所需的数据量。因此，潜在可适用的增量补丁的数量可迅速增长为与完整的更新文件相同的大小。在另一种方法中，网络化更新软件服务扫描客户机机器以选择对每一客户机机器可应用哪一增量补丁。尽管这减少了所发送的增量补丁信息量，然而它需要软件更新服务上的附加逻辑来扫描客户机机器并选择可适用的增量补丁。附加逻辑的使用增加了必须由服务提供的系统资源。此外，该方法通常阻止如通常由传统的web服务器所实现的网络高速缓存的使用。

除上述缺点之外，现有的系统无法传送某些类型的软件更新，如硬件驱动程序。如本领域中所已知的，专用软件更新，如应用于硬件驱动程序的软件更新，难以在大规模分发的基础上提供给用户，因为大多数专用软件更新仅在具有特殊硬件的客户计算机上起作用。例如，在大多数情况下，如果客户计算机获得了不兼容的硬件驱动程序升级，则该驱动程序升级的安装会导致致命的错误，或甚至会阻止计算机运行。

如可以从上述内容容易地理解的，需要一种具有服务器和多个客户机之间的软件更新的改进通信的系统和方法。另外，对具有允许更新服务在传送专用更新时以特定类型的客户机为目标的改进机制的软件更新系统和方法有需求。

发明概述

提供了一种更新计算装置上一个或多个文件的系统和方法。客户机计算装置获取更新信息，包括标识具有已安装文件的特定版本的特定增量补丁的索引。在选择将实现哪一可适用更新之后，客户机计算装置上的更新代理执行清查(inventory)来识别在机器上安装了文件要更新的哪一版本。更新代理选择对应的增量补丁，并将请求发送给更新服务。

依照本发明的一个方面，提供了一种更新客户机计算装置上的数据的方法。该方法可以在包括与软件更新服务通信的至少一个客户机计算装置的计算机系统中实现。依照该方法，计算装置获取用于更新安装在客户机计算装置上的一个或多个文件的一个或多个可用软件更新的选择。计算装置然后获取标识多个增量补丁的索引。每一增量补丁对应于已安装文件的至少一个版本。计算装置获取安装在客户机计算装置上的一个或多个文件的详细目录。计算装置选择一个或多个可适用的增量补丁来实现所选择的软件更新。一个或多个可适用补丁的选择对应于将标识多个增量补丁的索引映射到安装在客户机计算装置上的一个或多个文件的详细目录。计算装置然后请求一个或多个所选择的增量补丁。

依照本发明的另一方面，提供了一种更新客户机计算装置上的数据的方法。该方法可以在包括与软件更新服务通信的至少一个客户机计算装置的计算机系统中实现。依照本发明，计算装置获取用于更新安装在客户机计算装置上的一个或多个文件的一个或多个可用软件更新的选择，以及标识用于更新已安装文件的至少一个版本的多个可用增量补丁的包。计算装置获取安装在客户机计算装置上的一个或多个文件的详细目录，并选择一个或多个可适用的增量补丁来实现所选择的软件更新。一个或多个可适用补丁的选择对应于将标识多个可用增量补丁的包映射到安装在客户机计算装置上的一个或多个文件的详细目录。计算装置然后发送对一个或多个所选择增量补丁的请求。

依照本发明的又一方面，提供了一种更新客户机计算装置上的数据的方法。该方法可以在包括与软件更新服务通信的至少一个客户机计算装置的计算机系统中实现。依照该方法，计算装置获取用于更新安装在客户机计算装置上的一个或多个文件的一个或多个可用软件更新的选择，以及标识多个增量补丁的索引，其中每一增量补丁对应于已安装文件的至少一个版本。计算装置然后获取安装在客户机计算装置上的一个或多个文件的详细目录，然后选择一个或多个可适用的增量补丁来实现所选择的软件更新。一个或多个可适用补丁的选择对应于将标识多个增量补丁的索引映射到安装在客户机计算装置上的一个或多个文件的详细目录。计算装置请求一个或多个所选择的增量补丁并获取所请求的增量补丁。计算装置将增量补丁与对应的已安装文件合并，以生成更新文件并安装该更新文件。

附图的简要描述

当结合附图阅读以下详细描述，可以更好地理解并更容易地明白本发明的上述方面以及许多附加的优点，附图中：

图1是依照本发明的软件更新系统的框图，包括客户机计算机以及提供更新软件的更新服务；

图2是图1的软件更新系统的框图，它依照本发明示出了向更新服务认证客户机计算装置；

图3是图1的软件更新系统的框图，它依照本发明示出了客户机计算装置和更新服务之间的可用更新的同步；

图4是图1的软件更新系统的框图，它依照本发明示出了软件更新信息从更新服务到客户机计算装置的发送；

图5是图1的软件更新系统的框图，它依照本发明示出了客户机计算装置对更新信息的处理和选择；

图6是图1的软件更新系统的框图，它依照本发明示出了客户机计算装置对增量补丁的合并和对更新文件的安装；

图7是依照本发明的软件更新例程的流程图，它示出了由客户机计算装置和更新服务实现的用于识别可用于安装在客户机计算装置上的软件更新；

图8是依照本发明提供对储存在更新服务上的更新的选择性访问的授权例程的协议图；

图9所示是依照本发明的授权例程的一组示例软件更新的框图；

图10是依照本发明将选择的一组软件更新从软件更新服务传递到客户机计算装置的同步例程的协议图；

图11所示是依照本发明用于显示对各个客户机计算装置可用的软件更新列表的图形用户界面的示例性部分的框图；

图12A和12B所示是依照本发明由客户机计算装置110实现以检索和安装请求的软件的软件更新处理子例程1200；以及

图13所示是依照本发明由客户机计算装置实现的用于更新基线安装组件的子例程的流程图。

具体实施方式

一般而言，本发明针对的是管理软件更新的系统和方法。更具体地，本发明针对的是便于软件更新的选择和实现，同时最小化选择和实现软件更新所需的带宽和处理资源的系统和方法。依照本发明，软件更新可对应于用于特定软件应用程序或操作系统的更新。此外，软件更新可包括软件驱动程序或对固件的更新，如系统BIOS。依照本发明的一个方面，提供了一种处理软件更新的系统和组件体系结构。依照本发明的另一方面，提供了一种便于向更新服务授权和同步客户机机器的更新协议和接口。依照本发明的又一方面，提供了一种适用增量补丁更新安装组件和各种已安装文件的方法。然而，本领域的技术人员可以理解，本申请中也可提供本发明的其它方面。此外，相关领域的技术人员可以理解，每一所标识的方面可被个别或作为公共的发明性方面的一部分来考虑。

图1的软件更新系统100所示是依照本发明的软件更新系统100的框图。一般而言，软件更新系统100可包括一个或多个客户机计算装置110、更新服务120以及外部更新提供者130。一般而言，更新服务120储存并管理传递到并安装在客户机计算装置110上的软件更新的分发。软件更新可由更新服务120或任意数量的外部更新提供者130来提供。

客户机计算装置110、更新服务120和外部更新提供者130通过网络101电子地通信。网络可以是局域网(LAN)或更大的网络，如广域网(WAN)或因特网。通过使用一般已知的软件，软件更新系统100可被配置成在客户机计算装置110和更新服务120的服务器121、122、123和124之间交换文档、命令和其它已知类型的信息。本领域和其他领域的技术人员可以理解，图1所示的软件更新系统100是用于实现本发明的一个合适的系统的简化示例，本发明并非局限于此示例。

如后文更详细地描述的，更新服务120的一个实施例包括若干服务器。如图1所示，更新服务120包括更新服务器121，用于管理更新服务120的全过程并协调更新服务120的服务器121、122、123和124的处理。授权服务器122生成客户机请求的授权cookie，这些授权cookie进而用于生成允许客户机计算机访问更新服务120提供的更新的服务器cookie。元数据服务器123提供关于更新服务120提供的更新的一般信息。元数据服务器123允许本发明的系统识别用于特定类型的客户机计算机或特定的客户机计算机组的特定更新。下载服务器124提供了用于传送与由更新服务120提供的软件更新相关联的数据文件的一个或多个软件组件。

外部更新提供者130可包括分发软件更新的一个或多个服务器。外部更新提供者130可与提供软件、软件更新或要分发到客户机计算机组的其他数据的实体相关联。例如，外部更新服务器130可以与期望使用更新服务120来分发一个或多个软件应用程序的更新的第三方软件开发者相关联。在另一示例中，外部更新提供者130可以与软件更新系统120相关联。

客户机计算装置110可以是储存并执行软件应用程序114的任何计算装置。客户机计算装置110可以从多个不同的计算机产品的任一个形成，包括但不限于，个人计算机(PC)、个人数字助理(PDA)、移动电话、双向寻呼机等等。如本领域或其他领域的普通技术人员所理解的，客户机计算装置110的体系结构可以采用任一合适的形式。例如，客户机计算装置110可包括用于提供与网络101的通信的网络接口。网络接口可以被配置成用于任何有线或无线网络连接，并用于任一合适的通信协议，如TCP/IP协议。另外客户机计算装置110可包括处理单元、显示器和存储器单元。存储器单元可储存操作客户机计算装置110所必须的程序代码，如操作系统116。另外，存储器单元储存用于控制和执行本发明的过程的更新管理组件112。

软件更新系统100储存软件程序，当被执行时，它们实现本发明。当被执行时，软件更新系统100储存、管理并选择性地传递软件更新。如下文更完整地描述的，除其它益处之外，本发明提供了用于定义和选择有资格接收软件更新的客户机计算装置的目标组的机制。本发明也提供了用于下载与软件更新相关联的数据文件的改进的机制。

为说明本发明的目的，提供了本发明的工作示例的详细描述。在描述该工作示例时，参考软件更新，它指的是软件应用程序的特定升级，例如，将媒体播放器版本6.0升级到媒体播放器版本7.0。如本领域的普通技术人员所理解的，这一软件更新可包括与软件更新相关联的多个数据文件的传递和安装。由此，为说明本发明的目的，在软件更新和包含软件更新的个别数据文件之间作出区分。

现在参考图2-6，描述更新客户机计算装置110上的一个或多个文件的软件更新系统100的组件之间的说明性交互。参考图2，软件更新服务通过由一个或多个外部更新提供者130发送软件更新信息来启动。如上所述，外部更新提供者130可以与软件更新系统100相关联。或者，软件更新信息可以由第三方外部更新提供者130发送。在本发明的一个说明性实施例中，软件更新信息可包括用于更新文件的软件代码、用于替换文件的软件代码、用于确定软件更新的可适用性的各种规则、和/或描述软件更新的显示信息。软件更新信息的发送可在任一时刻完成，并且不必要与其它所示的软件更新组件交互同时发生。

在从外部更新提供者130接收了软件更新信息之后，更新服务120生成一段或多段数据，以便于发送更新信息。数据可包括对应于用于更新文件的不同版本的软件增量补丁集的补丁存储文件。数据也可包括对应于将特定的文件版本映射到补丁存储文件中找到的对应增量的索引的补丁存储清单。数据还可包括对应于更新代理将用于请求和安装特定软件更新数据的信息的自提取文件，如后文更详细地描述的。相关领域的技术人员可以理解，补丁存储文件、补丁存储清单和自提取文件的生成可以在任一时刻完成，并不必要与其它所示的组件交互同时发生。

为启动对客户机的软件更新信息发送，客户机计算装置110启动对更新服务120的认证请求。在本发明的一个说明性实施例中，认证请求对应于客户机计算装置110和更新服务120之间的更新协议交互，这将在后文更详细描述。在完成了认证之后，更新服务120将认证cookie发送到客户机计算装置120。现在参考图3，已认证的客户机计算装置120然后启动与更新服务器120的可用更新的同步。在本发明的一个说明性实施例中，同步请求也对应于客户机计算装置110和更新服务120之间的更新协议交互，这将在后文更详细地描述。在完成了同步之后，客户机计算装置110接收所有可适用的软件更新的信息和描述更新的信息。然而，在本发明的一个说明性实施例中，没有下载任何启动更新的软件代码。

继续参考图3，在更新过程期间的某一时刻，接收到要安装的更新的选择。在本发明的一个说明性实施例中，可向用户呈现在同步期间接收到的软件更新信息，并要求选择一个适当的更新。或者，客户机计算装置110可以配备自动选择所有可适用的软件更新的方式。此外，客户机计算装置110也可具有允许它自动选择可用软件更新的一个子集的某些规则。再者，用户可通过诸如经由互联网网页与更新服务120通信来启动更新的选择。

现在参考图4，如果尚不存在更新代理，则更新管理组件112例示客户机计算装置110上的更新代理118。更新代理118然后请求诸如自提取文件等软件更新信息包的发送。更新代理118接收自提取文件并执行对安装程序的任何更新，如后文更详细地描述的。此外，更新代理118可向更新服务120请求任何丢失或被破坏的信息。

现在参考图5，一旦更新代理118接收到了软件更新信息包，更新代理118执行安装在客户机计算装置110上的文件的清查。基于清查和软件更新信息包的比较，更新代理118确定需要哪一增量补丁或其它更新信息来完成所选择的更新。更新代理118然后发送对特定增量更新的请求。在本发明的一个实施例中，对软件更新的请求可对应于通过直接网络连接发送的直接请求，被称为手动更新。在本发明的另一实施例中，对软件更新的请求可以是不需要明显的用户行动而发送的后台请求。这一实施例被称为自动更新。

在本发明的一个说明性实施例中，如果软件更新对应于增量补丁，则更新代理118向更新服务120发送标识由包存储清单标识的特定增量补丁的请求。或者，在增量补丁不可用或者若干增量补丁失败的情况下，更新代理118可启动一后退过程。后退过程可包括对来自包存储文件的整个更新文件的完整副本的发送的请求。后退过程也可包括对自主式包内的整个更新文件的完整副本的发送的请求。

在本发明的一个说明性实施例中，更新服务120的下载服务器124可直接处理来自更新代理118的软件更新请求。或者，请求也可由任意数量的附加外部下载服务器来处理，如从更新服务120接收所请求的更新增量补丁的传统web服务器。例如，企业可使用内部服务器来更新客户机机器。另外，请求可由外部下载服务器来处理，其中，在处理先前的请求时高速缓存某些或所有更新增量补丁。另外，在此实施例中，下载可以被分发到能够服务超文本传输协议(“HTTP”)数据请求的若干另外的下载服务器。

参考图6，一旦接收到了软件更新信息，更新代理118将增量补丁与已安装文件合并，以生成更新文件。另外，更新代理118可确认合并程序是否成功地更新了适当的文件。如上所述，如果增量补丁不能被确认，则更新代理118可再次请求增量补丁或在若干次失败之后请求整个更新文件。一旦更新代理118获取了已被确认和更新文件，该文件被安装在客户机计算装置110上。

图7依照本发明的软件更新处理例程700的流程图，它示出了客户机计算装置110和软件更新服务120之间的交互。在框702，软件更新服务120授予对客户机计算机110的访问权限。在本发明的一个说明性实施例中，授予对客户机计算机的访问权限的过程可包括生成允许访问与特定的计算机组相关联的软件更新的服务器签发的cookie。授权过程的更详细解释将参考图8来描述。

在框704，客户机计算机110和软件更新服务120同步更新信息。在本发明的一个说明性实施例中，软件更新服务120向客户机计算装置110发送描述特定软件更新的元数据。元数据包含描述可用软件更新的信息，以允许用户选择一个或多个更新来安装。同步过程的更详细描述将在下文参考图9和10来描述。在框706，客户机计算装置110获取对要下载的可适用更新的选择。在本发明的一个说明性实施例中，对可适用更新的选择可对应于适用多个唯一用户界面以便于用户选择。用户界面的选择将在下文参考图11来更详细描述。

在框708，客户机计算装置110处理对可适用软件更新的用户选择，并与软件更新服务120接口以请求特定的更新信息。在本发明的一个说明性实施例中，客户机计算装置110选择并请求一个或多个可适用更新增量补丁。客户机计算装置110上的更新代理118然后可处理所请求的数据以实现所选择的软件更新。在框710，例程700终止。

参考图8，现在描述授予对客户机计算装置110的访问权限并对应于框702(图7)的协议图800。在本发明的一个说明性实施例中，软件更新服务120使用可扩充定目标机制，以控制客户机计算机110对更新和其它软件的访问。软件更新服务120结合了将特定软件更新与客户机计算装置110的一个或多个目标组相关联的机制。例如，软件更新服务120可限制特定的硬件驱动程序更新对具有特定硬件设备的特定品牌的客户机计算装置110的访问。在这一示例中，软件更新服务120可定义具有特定品牌名和特定硬件设备的客户机计算装置110的目标组，并限制特定软件下载向该目标组的发送。

在本发明的一个说明性实施例中，可扩充定目标机制可通过使用定义客户机计算装置到一个或多个目标组的成员资格的软件组件(“授权插件”)来促进。授权插件在客户机计算装置110上的存在定义了客户机计算装置是否属于授权插件的特定目标组。例如，目标组可包括具有特定软件应用程序的有效产品标识(“PID”)号的所有计算机。在这一示例中，如下文参考图8更详细地描述的，授权插件826可安装在客户机中，以从客户机计算装置的存储器模块中读取PID，并将所获取的PID传递到对应的PID服务器插件829。对应的PID插件此处也被称为PID确认程序829，使用了一种或多种方法来确定接收到的PID是否有效。一旦确定了储存在客户机计算装置110上的PID有效，则服务器生成指示客户机计算装置110是具有有效PID的目标组的成员的服务器cookie。在另一示例中，目标组可包括被指定为β测试(测试第二版)计算机的客户机计算装置。

在本发明的一个说明性实施例中，软件更新服务120的授权服务器122包含多个服务器授权插件，它们定义了授权服务器将识别的一组客户机计算装置目标组。每一服务器授权插件包含与储存在客户机计算装置110上的对应客户机授权插件传递数据的组件。以类似的方式，每一客户机计算装置110包括标识客户机所属的目标组的一个或多个授权插件。在本发明的一个说明性实施例中，客户机授权插件可在安装或升级软件应用程序期间，如安装或升级操作系统期间，被安装在每一客户机计算装置中。另外，服务器授权插件可以由期望控制对软件更新的访问的管理员动态地安装或移除。储存在客户机计算装置110和授权服务器122上的授权插件可以是实际的软件插件，或者授权插件可以被硬编码(hard code)成动态链接库。

如图8所示，授权服务器122包含三个示例服务器授权插件：(1)第一服务器授权插件828，它定义了包括所有计算机的目标组(后文称为“所有计算机目标组”)；(2)第二服务器授权插件829，它定义了包括具有有效PID的计算机的目标组(后文称为“PID目标组”)；以及(3)第三服务器授权插件830，它定义了包括β测试计算机的目标组(后文称为“β测试目标组”)。同样如图8所示，客户机计算装置110包含两个客户机授权插件：(1)第一客户机授权插件825，它指示客户机计算装置110是“所有计算机目标组”的成员；以及(2)第二客户机授权插件826，它指示客户机装置110是“PID目标组”的成员。在此示例中，客户机计算装置110不包含指示它是“β测试目标组”的成员的授权插件。如本领域的普通技术人员所理解的，每一客户机授权插件825和826可被配置成执行客户机计算装置110上的一个或多个功能，以协助确认过程。例如，第二客户机授权插件826可被配置成检查客户机计算装置110的存储器，以验证或获得已安装软件应用程序的PID。

如图8所示，授权子例程702在客户机计算装置110将配置请求803传递到授权服务器122时开始。在本发明的一个说明性实施例中，配置请求803是从被配置成获取描述储存在授权服务器122上的授权插件的信息的任一合适的软件组件形成的。如本领域的技术人员所理解的，配置请求803可使用一种被称为“GetConfig(获取配置)”的已知方法。响应于接收配置请求803，授权服务器122传递配置响应804，它包括标识储存在授权服务器122上的所有授权插件的信息。在一个实施例中，配置响应804包括串数组，它标识并描述了储存在授权服务器122上的所有授权插件。在本示例中，配置响应804包括标识第一服务器授权插件828、第二服务器授权插件829以及第三服务器授权插件830的信息。

在框805，客户机计算装置110响应于接收配置响应804生成一个或多个授权cookie。在框805的处理中，客户机计算装置110对每一对匹配的客户机和服务器授权插件生成授权cookie。由此，在本示例中，第一客户机授权插件825生成与“所有计算机目标组”相关联的第一授权cookie，因为第一客户机授权插件825和第一服务器授权插件828都与“所有计算机目标组”相关联。另外，第二客户机授权插件826生成与“PID目标组”相关联的第二授权cookie，因为第二客户机授权插件826和第二服务器授权插件829都与“PID目标组”相关联。未生成第三授权cookie，因为客户机计算装置110不具有指示它是“β测试目标组”的成员的授权插件。

如本领域的技术人员也可以理解的，框805的过程的一个实现可包括对本领域中称为“GetAuthCookie(获取授权cookie)”的一般已知的软件方法的使用。也可以理解，每一授权cookie的生成可涉及额外的处理。例如，第二客户机授权插件826可以被配置成检查储存在客户机系统注册表中的信息，以检索PID并在授权cookie中包括该PID。在其它示例中，框805的过程可包括与其它计算机或装置通信的过程。例如，客户机授权插件可与诸如声卡、扫描仪、视频卡等设备通信，以获取设备的构造和模型。在其它非限制示例中，客户机授权插件可与诸如指纹读取器等安全设备通信，以获取描述用户的信息。

一般而言，客户机授权插件可从客户机计算装置110的任何组件或通信上耦合至客户机计算装置110的任何其它计算装置读取配置信息。在其它示例中，客户机授权插件可被配置成使用一个或多个公钥或私钥应用编程接口(API)，以收集并加密来自客户机的信息，这些信息将由对应的服务器插件来确认。在这些示例中，PID确认器插件826使用私钥API来加密客户机的PID，以将经加密的PID传递到服务器以供解密和确认。在其它实施例中，其它客户机授权插件可使用诸如指纹读取器或语音打印等生物测定措施，以构造传递到服务器供确认的授权cookie。在又一示例中，客户机授权插件可调用web服务或任一其它服务以将授权凭证或任一其它类型的数据传递到授权服务器122。

在本发明的一个说明性实施例中，每一授权cookie包括标识相关联的目标组的串。例如，串可指示特定的授权cookie与“PID目标组”相关联。每一授权cookie也包括用于在客户机和服务器之间传递数据的数据段。例如，与“PID目标组”相关联的授权cookie可具有包含实际PID的数据段。如本领域的普通技术人员所理解的，数据段可包含以诸如字节数组等任一格式储存的任何类型的数据。例如，如果客户机和服务器上的插件需要公钥和私钥的传递，则这类数据可在一个或多个授权cookie的数据段中加密。

一旦客户机计算装置110对每一对对应的客户机和服务器授权插件生成了授权cookie，客户机计算装置将所生成的授权cookie传递到授权服务器122。如图8所示，客户机计算装置110在cookie请求806中传递授权cookie。cookie请求806包括用于传递框805的处理中生成的授权cookie的数组的任一合适的格式。这一部分授权方法702的一种实现可包括对本领域中被称为“GetCookie(获取cookie)”的一般已知的软件方法的使用。

在一个实施例中，cookie请求806也包括储存在客户机计算装置110的存储器中的其它授权服务器cookie。如可以从以下描述中更容易地理解的，客户机计算装置110的存储器可储存在授权例程700的先前的执行中创建的旧授权服务器cookie。通过在cookie请求806中提供储存的授权服务器cookie，客户机计算装置110能够维护其在授权子例程702的先前的执行中被授予的访问特权。在本示例中，由于没有授权服务器cookie储存在客户机中，因此cookie请求806包括与“所有计算机目标组”相关联的第一授权cookie以及与“PID目标组”相关联的第二授权cookie。

下一步，如框807中所示，响应于接收cookie请求806，授权服务器122生成服务器cookie。在一个实施例中，对于每一接收到的授权cookie，向适当的服务器授权插件作出调用以生成服务器cookie数据。每一服务器授权插件生成的服务器cookie数据包括接收到的授权cookie中标识的每一目标组的标识符。在本示例中，由于cookie请求806包括与“所有计算机目标组”相关联的第一授权cookie，以及与“PID目标组”相关联的第二授权cookie，因此授权服务器122生成包括这些相应目标组的标识符的服务器cookie数据。在授权服务器122上，如果在cookie请求806中接收到旧服务器cookie，则将服务器cookie数据与旧服务器cookie组合，以生成新服务器cookie。在一个实施例中，新服务器cookie通过使用诸如三重DES等公众可用的加密方法来加密。

在本发明的一个说明性实施例中，服务器cookie可包括标识一个或多个相关联的目标组的经加密的信息。另外，服务器coookie可包括过期数据，它以明文格式和加密格式两者储存。以明文格式储存的过期数据由客户机计算装置110用于监视服务器cookie的过期。以加密格式储存的过期数据由软件更新服务120用于确定客户机计算装置110是否被授权来接收与特定目标组相关联的更新。在一个实施例中，服务器cookie的过期数据应用于服务器cookie中标识的所有目标组。或者，或除应用于整个服务器cookie的过期时间之外，服务器cookie可包括多个过期数据，其每一个可应用于个别的目标组。如本领域的普通技术人员所理解的，每一服务器cookie可包括附加数据。例如，服务器cookie可被配置成储存客户机状态信息，如授权子例程702的最后执行的时间标记。

一旦被生成，授权服务器cookie 809从授权服务器122传递到客户机计算装置110。下一步，如框811所示，服务器cookie然后被储存在客户机计算装置110的存储器中。当客户机计算装置110确定服务器cookie的至少一个组件过期时，客户机计算装置可重新执行授权方法702来获取新的服务器cookie。如上所述，在授权方法702的每一次随后的执行中，客户机计算装置110可在cookie请求806中将其储存的服务器cookie传递到授权服务器122。在一个实施例中，客户机不必发送请求803，除非服务器通知客户机，服务器配置已改变，即，添加了新的授权插件。

依照本发明的另一方面，软件更新服务120可提供用于在元数据服务器123和客户机计算装置110之间同步更新信息的同步子例程。通过使用唯一的软件更新层次，同步子例程可有效地标识应用于特定客户机计算装置的特定更新。另外，通过使用授权子例程702中生成的服务器cookie，同步子例程可选择性地授予对与特定目标组相关联的更新的访问权限。

依照本发明的一个说明性实施例，每一软件更新包括三个部分1)指令部分；(2)本地化的数据部分；以及(3)数据部分。如本领域的普通技术人员所理解的，每一更新可具有上述部分的一个或多个。例如，更新可包含指令部分、本地化的数据部分和数据流部分。在另一示例中，更新可仅包含用于测试客户机计算装置的一个或多个条件的指令部分。软件更新的各个部分在下文更详细地描述。

一般而言，指令部分包含两个子部分：(1)定义要由客户机计算装置110测试的一个或多个条件的适用性规则；以及(2)标识个别更新的正确安装所需要的一个或多个更新的一组先决条件。如后文所描述的，适用性规则可定义与计算机相关的多个条件，这些条件的每一个可通过使用任何逻辑操作符与其它条件相关联。例如，指令部分可包括确定计算机是否安装了Windows

的特定版本的适用性规则。同样如下所述，该组先决条件可标识要求先前已被安装的一个或多个更新。例如，如后文参考图9更详细地描述的，个别的更新可包含列出个别更新的正确安装所需要的其它更新的先决条件。在其它示例中，同样如图9所示，该组先决条件可包括对逻辑操作符的使用以定义更复杂的先决条件规则。

指令部分也包含指示是否由依赖于特定更新的其它更新的代码，如布尔标志。为说明的目的，如果没有依赖于特定更新的其它更新，则该更新被认为是LEAF更新。用于指示更新是否为LEAF的布尔标志是在当添加或移除相关更新时由元数据服务器123动态地更新的。

每一更新的本地化数据部分包括描述更新的通用信息。例如，本地化数据部分可包括描述更新的特征和益处的信息。本地化数据部分也可包括更新的安装过程的文本描述。另外，本地化数据部分可包括与更新有关的任何其它数据或信息。例如，本地化数据可指示更新是高优先级更新。在另一示例中，本地化数据可提供特殊的安装消息，如指示更新不能与其它软件更新一起安装的消息。本地化信息可以是允许向用户显示其包含的信息的格式。

每一更新的数据部分包括更新的一个或多个二进制数据流。在一个实施例中，每一更新的数据部分可以与一个或多个数据文件相关联，如可执行文件、文档、链接库等等。如下文更详细地描述的，每一更新可以与数据文件的组合相关联，其每一个促进了客户机使用的软件的实际升级、安装或修改。例如，更新的安装可以通过使用包括完成所选择的更新所需的所有信息的单个CAB文件来促进。或者，更新的安装可通过使用用于更新储存在客户机计算装置上的一个或多个文件的多个个别更新来促进。

在本发明的一个说明性实施例中，软件更新可以按允许软件更新的受控分发的分层结构来排列。一般而言，更新的层次定义了更新之间的关系，并特别地指示了哪些更新依赖于其它更新。为说明的目的，图9中提供并示出了一组示例性更新。如图所示，示例更新900的层次包括基础更新组901、第二更新组902以及第三更新组903。一般而言，基础更新集901中的每一更新不具有需要其它更新的安装的先决条件。然而，第六更新921包含需要第一更新911、第二更新912、第三更新913的安装的先决条件。第七更新922包含需要第四更新914的安装的先决条件。第八更新931包含需要第六更新921和第五更新915的先决条件。因此，第八更新931也需要第一更新911、第二更新912和第三更新913的安装。为说明本发明的目的，给定示例更新集900的所有更新都与“所有计算机目标组”和“PID目标组”相关联。

如图9所示，并且如后文更详细描述的，每一更新包含指定更新安装的条件的适用性规则。例如，第一更新911需要操作系统的英语版本的安装。第二更新912需要WindowsXP版本SP1的安装。在另一示例中，第六更新921需要被称为XP PATCH1的软件补丁的安装。因此，如果未满足适用性规则，则客户机计算装置110将不安装更新。

图9也示出了指示是否有依赖于特定更新的其它更新的指令部分段。该段被称为LEAF，它可以是指示软件更新是一系列相关更新的最后一个更新的布尔值形式。为说明本发明的目的，如果没有其它更新列出特定更新为先决条件，则该特定更新是LEAF更新。如图9所示，第七更新922和第八更新931是仅有的两个LEAF更新。

图10示出了依照本发明形成的同步子例程704(图7)的协议图。一般而言，同步子例程704选择性地在客户机计算装置110和诸如元数据服务器123等服务器之间传递某些更新的指令部分，以标识可应用于客户机计算装置110的更新。如图10所示，为启动更新，客户机计算装置110首先处理已安装的更新，并将同步请求1051传递到元数据服务器123，请求对客户机可用的一个或多个更新。响应于接收同步请求1051，元数据服务器123向客户机计算装置110返回多个更新。如可以从以下描述中更容易地理解的，客户机计算装置110在传递同步请求1051之前处理本地储存的数据。

客户机计算装置110处理每一接收到的更新的指令部分，以确定是否能满足适用性规则中定义的条件。如果满足了个别的更新中定义的条件，为说明同步子例程1050的目的，个别更新是“已安装”的，并且所安装的更新被保存在客户机更新高速缓存的第一组成部分中。另一方面，如果未满足个别更新中定义的条件，则该个别更新被认为“失败”，并且失败的更新被保存在客户机更新高速缓存的第二组成部分中。在同步子例程1050的这一描述中，如果更新被安装，则可假定满足了先决条件和适用性规则的条件。为描述该子例程的目的，更新的安装不必要意味着与更新相关联的数据文件实际上被安装到客户机计算装置110中。

在一个实施例中，客户机更新高速缓存的两个组成部分可用于归类所接收到的更新。第一组成部分用于储存已安装的、非LEAF更新；第二组成部分用于储存客户机接收的所有其它更新，即未安装的更新。更新高速缓存的第二组成部分也可包括所有LEAF更新的存储。如下文更详细地描述的，储存在更新高速缓存中的更新可以被传递到元数据服务器123并由其处理，以标识可用于在客户机计算装置110上的安装的其它相关更新。

现在回头参考图10，将描述同步请求的细节，被示出为项1051、1055和1060。如本领域的普通技术人员所理解的，同步请求可由多个不同装置、进程、应用程序、用户启动的命令之一来启动，以请求更新。同步请求可由请求更新列表的用户、由客户机代理启动的自动更新、以及向元数据服务器123或更新服务120请求信息的任何其它软件组件启动。在一个实施例中，同步请求包括授权服务器cookie，如从授权例程702生成的授权服务器cookie。服务器cookie的使用允许服务器确定客户机是否为一个或多个目标组的成员。

每一同步请求也可包括储存在客户机更新高速缓存中的每一更新的标识符。更具体地，如果一个或多个更新储存在更新高速缓存中，同步请求包括具有用于已安装、非LEAF更新的标识符的第一部分；以及具有用于诸如LEAF更新、已失败更新以及未安装的其它更新等所有其它更新的标识符的第二部分。更新标识符可以是任何格式，包括但不限于，整数数组。或者，如果没有更新储存在客户机更新高速缓存中，则同步请求不配备更新标识符。当同步请求设备配备更新标识符时，同步请求提供客户机计算装置110没有任何高速缓存的更新的指示。

如图10所示，第一同步请求1051从客户机计算装置110传递到元数据服务器123。在本示例中，如果这是方法的第一次执行，则客户机的更新高速缓存将不包含任何更新。由此，第一同步请求1051不包含用于高速缓存的更新的标识符。响应于接收同步请求，如框1052所示，元数据服务器123确定同步请求是否包含至少一个更新标识符。如果确定同步请求不包含更新标识符，则元数据服务器1123通过选择用于传递到客户机计算装置110第一级更新来响应。如上所述，第一级更新可包括没有标识其它更新的先决条件的任何更新。

或者，如果确定同步请求包含至少一个更新标识符，则元数据服务器123检查服务器的已储存更新的先决条件，以选择用于传送到客户机的额外更新。在一个实施例中，元数据服务器123选择已实现先决条件的更新。在检查先决条件时，服务器使用同步请求的第一部分的更新，它包括安装在客户机上的非LEAF更新的标识符。

除选择已实现先决条件的更新之外，服务器也使用同步请求的第二部分中标识的更新，以过滤所选择的更新。更具体地，同步请求的第二部分中标识的未安装更新、LEAF更新和已失败更新用于过滤一个或多个所选择的更新。本发明的这一特征允许本发明的系统和方法避免储存在元数据服务器123上的更新的多次发送。

返回到本示例，由于第一同步请求1051不包括更新标识符，则元数据服务器123选择更新901的基础级，以传递到客户机计算装置110。参考图9所示的示例更新集，基础集更新901包括标号为911、912、913、914和915的更新。

在框1052的处理中，元数据服务器123也检查包含在同步请求1051中的授权服务器cookie，以标识与客户机计算装置110相关联的目标组。元数据服务器123也检查在框1052的过程中选择的更新的目标组。框1052的处理然后过滤出不与接收到的授权服务器cookie中标识的目标组相关联的所有所选择的更新。在本示例中，由于所有所选择的更新911、912、913、914和915与PID和所有计算机目标组相关联，因此所有所选择的更新都被发送到客户机计算装置110。

元数据服务器123然后在同步响应1053中将所选择的更新传递到客户机计算装置110。一般而言，每一同步响应包括服务器120发送的每一更新的指令部分。由此，在本示例中，第一同步响应1053包括标号为911、912、913、914和915的更新的指令部分。在一个实施例中，每一同步响应不包括每一更新的本地化数据部分或数据部分。

下一步，如框1054中所示，客户机计算装置110处理每一接收到的更新的指令部分，以确定是否可满足适用性规则中定义的条件。再次参考图9，客户机计算装置110处理接收到的更新911-915的指令部分。为说明本发明的目的，在本示例中假定客户机计算装置110的操作系统是Windows

版本XP SP1的英语安装。也假定客户机计算装置110是Dell PC，并运行32位的X86处理器。由此，在处理示例更新集的指令部分时，客户机计算装置110可确定将满足第一更新911中定义的条件，因为计算机包含英语OS。将满足第二更新912中定义的条件，因为操作系统是Windows版本XP SP1。将满足第三更新913中定义的条件，因为客户机计算装置运行X96处理器。将满足第五更新915中定义的条件，因为客户机计算装置110是Dell PC。结果，第一更新911、第二更新912、第三更新913和第五更新915都被保存在客户机更新高速缓存的第一组成部分中。将不满足第四更新914中定义的条件，因为客户机计算装置110不运行64位的X86处理器。由此，第四更新914被认为是已失败的更新，并保存在客户机更新高速缓存的第二组成部分中。

返回到图10，在框1054的处理中，客户机计算装置110也确定是否需要后续的同步请求。在一个实施例中，如果至少一个所接收到的更新指示它不是LEAF更新，则确定需要后续的同步请求。在本发明的示例中，确定需要随后的同步请求，因为所有接收到的更新都不是LEAF更新。由此，客户机计算装置110将后续的同步请求1055传递到元数据服务器123。

如上所述，同步请求包括储存在客户机更新高速缓存中的每一更新的标识符。由此，在本示例中，后续的同步请求1055包括指示客户机上安装了第一更新911、第二更新922、第三更新913和第五更新915的第一数据部分。另外，后续的同步请求1055包括指示客户机上未成功地安装第四更新911的第二数据部分。

响应于接收后续的同步请求1055，如上所述，元数据服务器123确定后续的同步请求1055是否包含至少一个更新标识符。如果确定后续的同步请求包含至少一个更新标识符，元数据服务器123检查所有储存的更新的先决条件，以选择用于传送到客户机的额外更新。

再次参考本示例，在框1056的处理中，元数据服务器123将选择第六更新921，因为满足了它的先决条件。更具体地，如图9所示，第六更新921被选中用于传递到客户机计算装置110，因为其需要第一更新911、第二更新912和第三更新913的安装的先决条件已被实现。第七更新922和第八更新931将不被选中用于传递到客户机，因为它们的先决条件未被实现。更具体地，同步请求1055不包含第四更新914的标识符，它是第七更新922的先决条件。另外，同步请求855不包含第六更新921的标识符，它是第八更新931的先决条件。

返回到图10，同步子例程1050通过在后续响应1057中将所选择的更新从元数据服务器123传递到客户机计算装置110来继续。再次参考本示例，后续响应1057将包括与第六更新921有关的信息，它在后续响应1057中被传递到客户机110。

在接收到后续响应1057之后，客户机计算装置110处理后续响应1057的指令部分。类似于框1054的过程，客户机计算装置110处理每一接收到的更新的指令部分，以确定是否满足适用性规则中定义的条件。在本示例中，如果假设在客户机计算装置中已安装了XP PATCH1，则第六更新921被认为是已安装的，并且更新被写入客户机计算装置110的更新高速缓存中。由于第六更新921不是LEAF更新，因此客户机计算装置110发送包括储存在客户机更新高速缓存的第一和第二组成部分中的所有更新的另一同步请求1060。同步请求1060也包括授权服务器cookie。

在本示例中，通过使用上述元数据服务器123的处理，同步请求1060在框1061被处理，其中，服务器选择第八更新931。第八更新931被选中，因为同步请求1060指示第五和第六更新915和921已安装在客户机计算装置110上。假设第八更新931与授权服务器cookie中标识的相同目标组相关联，则在另一响应1062中将第八更新931的指令部分传递到客户机计算装置110。然后在框1063以类似于框1054和1059的处理的方式处理第八更新931。由于响应1062所有所接收的更新都是LEAF更新，因此不将后续请求发送回元数据服务器123。

在客户机计算装置110处，在确定了所有接收到的更新都是LEAF更新之后，或者如果在响应1062中没有接收到任何更新，则同步子例程1050将驱动程序同步请求1064从客户机计算装置110传递到元数据服务器123。如本领域的普通技术人员所理解的，驱动程序同步请求1064可包括描述安装在客户机计算装置110上的所有硬件的信息以及描述已安装软件的信息。类似于先前的软件同步请求(1051、1055和1060)，驱动程序同步请求1064可将已安装的更新传递到服务器。另外，当前在客户机上高速缓存的所有驱动程序更新(如果有的话)被传递到服务器。

响应于接收驱动程序同步请求1064，元数据服务器123通过发送应用于客户机计算装置110的尚未高速缓存到客户机上的所有驱动程序更新来响应。如果满足其先决条件和条件，则在响应1065中将驱动程序更新发送到客户机计算装置110。传递驱动程序更新的响应1065较佳地传递每一更新的指令部分。驱动程序更新然后被写入客户机计算装置的更新高速缓存中。

在接收包含驱动程序更新的响应1065之后，同步子例程1050发送对所接收的软件和硬件更新的每一个的本地化数据的请求1066。如上所述，每一更新的本地化数据部分包括描述更新的通用信息。例如，本地化数据部分可包括描述更新的特征和益处的信息。本地化数据部分也可包括更新的安装过程的文本描述。另外，本地化数据部分可包括关于更新的任何其它数据或信息。

由此，在接收了对接收到的软件更新和硬件更新的每一个的本地化数据的请求1066之后，元数据服务器123通过发送客户机更新高速缓存中保存的所有接收到的软件更新和硬件更新的所有本地化数据来响应。一旦接收到，本地化数据可由软件应用程序来处理，以确定哪些更新需要被安装。或者，接收到的本地化数据可显示给用户，以向用户通知对客户机计算装置110可用的所有更新。在一个实施例中，接收到的本地化数据可在网页上显示。在本示例中，第六和第八更新921和931的本地化数据可以由客户机接收。如果本地化数据被储存在基础更新911、912、913和915中，则那些更新的本地化数据也由客户机接收。

图11示出了网页1100的一个示例，它显示了与对客户机可用的更新相关联的本地化数据的示例。为说明的目的，网页1100包括更新的第一详细描述1105和另一更新的第二详细描述1106。如图所示，每一更新分别与用于接收更新的用户选择的选择机制1103和1104相关联。同样如图所示，网页1100配备允许用户控制更新的选择到诸如元数据服务器123或下载服务器124等服务器的传递的控制按钮1101。

在本发明的一个方面中，客户机执行多个处理以增强网页1100的显示。例如，客户机计算装置110检查每一更新的本地化数据以确定特定更新是否是高优先级。这一特征可通过在本地化数据或特定更新的其它组件中查找指示特定更新是高优先级或紧急更新的文本来促进。如果客户机计算装置110检测到高优先级更新或紧急更新，则客户机在网页1100的可视部分中，如页面的顶部显示高优先级更新。另外，客户机可生成可视指示符，如专用的文本消息1120，指示该更新是高优先级更新。

客户机计算装置110也可检查每一更新的本地化数据，以确定特定更新是否需要排他安装，即，更新具有不能与另一更新的安装文件同时安装的安装文件。这一特征可通过在本地化数据或特定更新的其它组件中查找指示特定更新需要排他安装的文本来促进。如果客户机计算装置110检测到这一更新，则客户机显示一可视指示符，例如图11所示的文本消息1122，它具有需要排他安装的更新的描述。

返回到图7，软件更新例程700在框708继续，其中客户机计算装置110接收更新的选择。如上所述，响应于控制按钮1101的激励，对一个或多个更新的选择可由元数据服务器123或下载服务器124获得。一旦接收到了一个或多个更新的选择，软件更新例程700在框708继续，处理所选择的软件更新。

依照本发明的又一方面，软件更新服务120可提供一种在软件更新服务和客户机计算装置110之间选择和发送信息的方法。图12A和12B所示是依照本发明的软件更新处理子例程1200，它由客户机计算装置110实现，用于检索和安装所请求的软件。如上所述，一旦生成或接收到了对软件更新的选择，就可以实现软件更新处理子例程1200。参考图12A，在框1202，更新管理组件112例示更新代理118。在本发明的一个说明性实施例中，更新代理118是一种专用软件组件，用于确定需要什么软件更新信息来完成请求的软件更新、生成更新代理的安装组件的所需要的版本、通过将现有文件与增量补丁合并生成更新文件、和/或启动更新文件的安装。在更新代理118已被例示的情况下，可省略框1202。

在框1204，更新代理118从更新服务120获取软件更新信息。在本发明的一个说明性实施例中，更新服务120发送的软件更新信息是包的形式，如自提取文件，它包括可由更新代理使用的各种数据。在一个方面，包可包括对应于特定软件更新的所有文件的列表。另外，包可包括补丁存储清单的至少一部分的副本，该清单将要更新的文件的特定版本映射到储存在更新服务120上的补丁存储文件中的对应软件更新增量补丁。包也可包括用于要更新的每一文件的安装信息，它可包括完成安装所需要的安装组件的版本的标识。此外，包也可包括用于更新代理118的安装组件，或更新已储存在客户机计算装置110上的安装组件的版本的增量补丁。再者，包可包括允许更新代理确定软件更新是否成功的验证信息。例如，验证信息可包括更新文件的参考散列值用于比较。更新代理118也可验证包的内容。

在判别块1206，执行测试以确定更新代理118是否需要更新安装组件的版本以实现更新。相关领域的技术人员将认识到，在自提取文件中发送安装组件的完整副本可增加更新服务120对每一软件更新发送的数据量。因此，在本发明的一个说明性实施例中，可将安装组件的基线版本储存在客户机计算装置中，并通过安装组件增量补丁对当前软件更新的需求来特别更新。因此，自提取文件中的安装信息指令更新代理118任何所包括的安全组件更新是否需要与客户机计算装置110上的安装组件的基线版本合并。如果需要更新，则在框1208，更新代理118更新基线安装组件，如后文参考图13更详细讨论的。

一旦更新代理更新了安装组件，或者安装组件不需要更新，则在框1210，更新代理118执行安装在计算装置110上的文件和文件的特定版本的清查。在本发明的一个说明性实施例中，更新代理118可向客户机计算装置110文件系统查询在包内被标识为对应于所选择的更新的所有文件。或者，如果更新代理118最近已执行了清查，则可使用详细目录的高速缓存的版本。在框1212，更新代理118标识完成所请求的更新所需要什么软件更新信息。在本发明的一个说明性实施例中，包存储清单包括已安装文件的版本到所需要的增量补丁的映射。因此，如果增量打补丁可用，则更新代理118将使用该映射来标识特定的增量补丁及其在包存储文件中的偏移位置。或者，如果增量补丁不可用或不能实现，则更新代理118可标识整个文件用于下载。

现在参考图12B，在框1214，更新数据代理发送对已标识软件更新信息的请求。在本发明的一个说明性实施例中，更新代理118可通过指示特定范围的补丁，将对特定增量补丁的请求从补丁存储文件发送到更新服务120的下载服务器124。如上所述，补丁存储文件包括大量的可适用增量补丁，其中每一增量补丁由其在补丁存储文件中的位置来标识。由于补丁存储文件在某些实现中可能相当大，因此更新代理118可使用仅请求来自补丁存储文件中的特定位置的数据的请求，如补丁存储清单中所指示的。在本发明的一个替换实施例中，更新代理118可请求更新文件的整个副本和/或补丁存储文件的完整副本。

在本发明的一个替换实施例中，可能不排他地与更新服务120相关联的另一下载服务器可处理更新代理118请求。在这一实施例中，请求补丁存储文件可完整或部分地发送到网络上的任意数量的附加下载服务器。附加下载服务器可以是用于更新专用网络上的客户机的专用网络的一部分。此外，附加下载服务器可以是公共网络的一部分。在专用网络环境中，下载服务器可获取补丁存储文件的完整副本，用于处理客户机请求。或者，下载服务器也可在处理来自其它客户机的先前的数据请求时高速缓存补丁存储文件的各部分，并使用高速缓存数据来满足下载。因此，附加下载服务器可减少对更新服务120的下载服务器124的通信张力。

在框1216，更新代理118接收所请求的更新信息。在本发明的一个说明性实施例中，所请求的更新信息可以用两种方法发送。在被称为手动更新的第一种方法中，更新请求连同对直接HTTP数据传送响应的请求一起发送到更新服务120。在该方法中，更新服务120可使用可用于向更新代理118发送所请求数据的整个带宽的全部。在被称为自动更新的第二种方法中，更新请求连同对间接HTTP数据传送响应的请求一起发送到更新服务120。在这一响应中，更新服务120发送所请求的数据作为后台进程。后台进程可以用使用最小量可用带宽的方式来实现。此外，后台进程可在下载过程期间中断，并可在下一可用时刻重新开始。通过后台进程发送所请求数据的系统和方法的描述在2000年2月16日提交的，名为“System andMethod for Transferring Data Over a Network(通过网络传输数据的系统和方法)”的共同转让并共同提交的待决美国专利申请号09/505,735中有描述，该申请通过引用结合于此。相关领域的技术人员可以理解，前台和后台数据传输不必要反映所选择的软件更新的优先级，但是相反反映了如何分配带宽来获取更新信息。

一旦从更新服务接收到了所请求的信息，在框1218，更新代理118将增量补丁与对应的已安装文件合并。在本发明的一个说明性实施例中，更新代理118可高速缓存已安装文件的原始版本，以确保所选择的文件不会在下载和合并过程中改变。此外，高速缓存的已安装文件的原始版本可用于卸载所选择的更新。

在判别框1220，执行测试以确定更新文件是否有效。在本发明的一个说明性实施例中，更新代理118可使用散列算法，以将从更新信息包中获得并对应于有效文件更新的参考散列值与来自当前修改的文件的散列相比较。如果散列不匹配，则当前修改的文件不是有效的。相关领域的技术人员可以理解，可使用多种替换确认算法的任一种。如果更新文件不是有效的，则子例程1200返回到框1214，其中更新代理可再次请求更新信息。或者，如果更新代理118已若干次不成功地尝试了生成更新文件，则更新的代理可实现若干后退过程的任一种。在本发明的一个实施例中，更新代理118可向更新服务120请求储存在补丁存储文件中，并从补丁存储清单标识的更新文件的已完成副本。在本发明的另一实施例中，更新代理118可向更新服务120请求自主式文件中的更新文件的副本。在本发明的又一实施例中，另一子例程1200可以失败。

一旦所选择的文件有效，则在判别块1222，执行测试以确定是否需要任何额外的下载。在本发明的一个说明性实施例中，子例程1200进入一迭代循环，它在完成了先前选择的下载之后连续地核查额外的下载。如果文件的状态在下载期间改变，则更新代理118可继续请求对新状态改变的额外下载。如果需要额外的下载，则在框1224，更新代理118执行另一清查，并标识所有可适用的增量补丁。子例程1200然后返回到框1214。

一旦完成了所有的所请求的更新下载，在判别框1226，执行测试以确定客户机机器的状态是否改变。在本发明的一个说明性实施例中，在更新文件的更新信息和实际安装的下载和合并之间会经过某些时间。因此，在安装更新文件之前，更新代理确定客户机计算装置状态是否改变。如果状态已改变，则文件更新可能不是有效的，并且更新在框1228失败。或者，如果没有发生状态改变，则更新代理118在框1230安装更新文件，并且子例程1200返回到框1232。

现在参考图13，描述了由客户机计算装置110实现，用于更新对应于框1208(图12A)的基线安装组件的子例程1300。在判别框1302，执行测试以确定从更新服务120发送到更新代理118的自提取文件中是否包括了新的基线安装组件。在本发明的一个说明性实施例中，如果更新基线安装程序所需的增量补丁在大小上可与已更新安装组件的发送比较，则将发送新的基线安装组件。如果包括了已更新安装组件，则在框1304，更新代理安装已更新的基线安装组件作为新的安装组件。另外，新的已更新安装组件可以保存在客户机计算装置110的存储器中，以担当用于附加更新的基线安装程序。在框1306，子例程返回。

如果在自提取文件中未包括已更新的基线安装组件，则在框1308，更新代理118从自提取文件获取基线安装组件增量补丁。在本发明的一个说明性实施例中，基线安装组件增量补丁对应于可与基线安装组件合并来生成已更新基线安装组件的软件代码。因此，在框1310，更新代理将基线安装组件增量补丁与基线安装组件合并。在框1312，更新代理118然后将已更新基线安装组件制定为当前安装组件。在本发明的一个说明性实施例中，已更新安装组件在安装完成之后将不被保存。依照该实施例，更新代理118仅维护客户机计算装置110的存储器中有限数量的基线安装组件。因此，更新代理在每一次安装时生成临时的已更新安装组件。由于每一客户机计算装置110只能对应于有限数量的基线安装组件，因此仅需要更新服务120对每一客户机计算装置发送单个基线安装组件增量补丁。在框1314，子例程1300返回。

尽管示出并描述了本发明的较佳实施例，然而可以理解，可在不脱离本发明的精神和范围的情况下作出对其作出各种改变。例如，尽管此处描述的说明性示例应用于软件更新，然而本发明的范围包括除关于软件更新的信息的分发和传递之外的其它使用。因此，除非在本揭示中明确地排除了特定主题，可以理解，本发明的范围应用于不同于软件更新或除此之外的任何类型数据的分发和传递。

Claims (37)

1.在包括与软件更新服务通信的至少一个客户机计算装置的计算机系统中，一种更新客户机计算装置上的数据的方法，其特征在于，所述方法包括：

获取对用于更新所述客户机计算装置上安装的一个或多个文件的一个或多个可用软件更新的选择；

获取标识多个增量补丁的索引，其中，每一增量补丁对应于已安装文件的至少一个版本；

获取所述客户机计算装置上安装的一个或多个文件的详细目录；

选择一个或多个可适用的增量补丁来实现所选择的软件更新，其中，选择所述一个或多个可适用的补丁对应于将标识所述多个增量补丁的索引映射到所述客户机计算装置上安装的一个或多个文件的详细目录；以及

请求所述一个或多个所选择的增量补丁，

其中，在传送专用更新时以特定类型的客户机为目标。

2.如权利要求1所述的方法，其特征在于，获取对一个或多个可用软件更新的选择包括获取对一个或多个可用软件更新的手动选择。

3.如权利要求1所述的方法，其特征在于，获取对一个或多个可用软件更新的选择包括获取对一个或多个可用软件更新的自动选择。

4.如权利要求1所述的方法，其特征在于，所述软件更新服务包括具有对可用增量补丁的选择的文件，并且其中，所述索引对应于对可用增量补丁的每一选择的特定存储位置的标识。

5.如权利要求4所述的方法，其特征在于，请求所述一个或多个所选择的增量补丁包括通过标识所请求的增量补丁的特定存储位置请求来自所述文件的特定增量补丁。

6.如权利要求4所述的方法，其特征在于，请求所述一个或多个所选择的增量补丁包括通过标识每一所请求的增量补丁的特定存储位置请求来自所述文件的一组特定增量补丁。

7.如权利要求1所述的方法，其特征在于，还包括：

获取所请求的增量补丁；

将所述增量补丁与对应的已安装文件合并，以生成一更新文件；以及

安装所述更新文件。

8.如权利要求7所述的方法，其特征在于，还包括：

在安装所述更新文件之前确认所述更新文件；以及

如果所述更新文件不被确认，则恢复所述更新文件的前一版本。

9.如权利要求1所述的方法，其特征在于，请求所述一个或多个所选择的增量补丁包括发送对所选择的增量补丁的前台请求。

10.如权利要求1所述的方法，其特征在于，请求所述一个或多个所选择的增量补丁包括发送对所选择的增量补丁的后台请求。

11.如权利要求1所述的方法，其特征在于，获取所述客户机计算装置上安装的一个或多个文件的详细目录包括获取所述客户机计算装置上安装的一个或多个文件的高速缓存的详细目录。

12.一种计算机系统，包括：

用于获取对用于更新所述客户机计算装置上安装的一个或多个文件的一个或多个可用软件更新的选择的装置；

用于获取标识多个增量补丁的索引的装置，其中，每一增量补丁对应于已安装文件的至少一个版本；

用于获取所述客户机计算装置上安装的一个或多个文件的详细目录的装置；

用于选择一个或多个可适用的增量补丁来实现所选择的软件更新的装置，其中，选择所述一个或多个可适用的补丁对应于将标识所述多个增量补丁的索引映射到所述客户机计算装置上安装的一个或多个文件的详细目录；以及

用于请求所述一个或多个所选择的增量补丁的装置，

其中，在传送专用更新时以特定类型的客户机为目标。

13.在包括与软件更新服务通信的至少一个客户机计算装置的计算机系统中，一种用于更新所述客户机计算装置上的数据的方法，其特征在于，所述方法包括：

获取对用于更新所述客户机计算装置上安装的一个或多个文件的一个或多个可用软件更新的选择；

获取标识用于更新已安装文件的至少一个版本的多个可用增量补丁的包；

获取所述客户机计算装置上安装的一个或多个文件的详细目录；

选择一个或多个可适用的增量补丁以实现所选择的软件更新，其中，选择所述一个或多个可适用的补丁对应于将标识多个可用增量补丁的包映射到所述客户机计算装置上安装的一个或多个文件的详细目录；以及

发送对一个或多个所选择增量补丁的请求，

其中，在传送专用更新时以特定类型的客户机为目标。

14.如权利要求13所述的方法，其特征在于，获取对一个或多个可用软件更新的选择包括获取对一个或多个可用软件更新的手动选择。

15.如权利要求13所述的方法，其特征在于，获取对一个或多个可用软件更新的选择包括获取对一个或多个可用软件更新的自动选择。

16.如权利要求13所述的方法，其特征在于，所述软件更新服务包括一具有对可用增量补丁的选择的补丁存储文件，并且其中，所述包包括标识对可用增量补丁的每一选择的特定存储位置的补丁存储清单。

17.如权利要求13所述的方法，其特征在于，请求所述一个或多个所选择的增量补丁包括通过标识所请求增量补丁的特定存储位置请求来自所述补丁存储文件的特定增量补丁。

18.如权利要求17所述的方法，其特征在于，发送对一个或多个所选择增量补丁的请求包括通过标识每一所请求增量补丁的特定存储位置来发送对来自所述补丁存储文件的一组特定增量补丁的请求。

19.如权利要求13所述的方法，其特征在于，还包括：

获取所请求的增量补丁；

将所述增量补丁与对应的已安装文件合并，以生成一更新文件；以及

安装所述更新文件。

20.如权利要求19所述的方法，其特征在于，所述包包括验证信息，所述方法还包括：

在安装所述更新文件之前确认所述更新文件；以及

如果所述更新文件不被确认，则恢复所述更新文件的前一版本。

21.如权利要求13所述的方法，其特征在于，请求所述一个或多个所选择增量补丁包括发送对所选择增量补丁的前台请求。

22.如权利要求13所述的方法，其特征在于，请求所述一个或多个所选择增量补丁包括发送对所选择增量补丁的后台请求。

23.如权利要求13所述的方法，其特征在于，获取所述客户机计算装置上安装的一个或多个文件的详细目录包括获取所述客户机计算装置上安装的一个或多个文件的高速缓存的详细目录。

24.如权利要求13所述的方法，其特征在于，所述包包括一安装组件更新，所述方法还包括从所述安装组件更新来更新所述客户机计算装置上的安装组件。

25.如权利要求24所述的方法，其特征在于，所述安装组件更新是安装组件增量补丁。

26.一种计算机系统，包括：

用于获取对用于更新所述客户机计算装置上安装的一个或多个文件的一个或多个可用软件更新的选择的装置；

用于获取标识用于更新已安装文件的至少一个版本的多个可用增量补丁的包的装置；

用于获取所述客户机计算装置上安装的一个或多个文件的详细目录的装置；

用于选择一个或多个可适用的增量补丁以实现所选择的软件更新的装置，其中，选择所述一个或多个可适用的补丁对应于将标识多个可用增量补丁的包映射到所述客户机计算装置上安装的一个或多个文件的详细目录；以及

用于发送对一个或多个所选择增量补丁的请求的装置，

其中，在传送专用更新时以特定类型的客户机为目标。

27.在包括与软件更新服务通信的至少一个客户机计算装置的计算机系统中，一种用于更新所述客户机计算装置上的数据的方法，其特征在于，所述方法包括：

获取对用于更新所述客户机计算装置上安装的一个或多个文件的一个或多个可用软件更新的选择；

获取标识多个增量补丁的索引，其中，每一增量补丁对应于已安装文件的至少一个版本；

获取所述客户机计算装置上安装的一个或多个文件的详细目录；

选择一个或多个可适用的增量补丁以实现所选择的软件更新，其中，选择所述一个或多个可适用的补丁对应于将标识多个增量补丁的索引映射到所述客户机计算装置上安装的一个或多个文件的详细目录；

请求所述一个或多个所选择的增量补丁；

获取所请求的增量补丁；

将所述增量补丁与对应的已安装文件合并，以生成一更新文件；以及

安装所述更新文件，

其中，在传送专用更新时以特定类型的客户机为目标。

28.如权利要求27所述的方法，其特征在于，获取对一个或多个可用软件更新的选择包括获取对一个或多个可用软件更新的手动选择。

29.如权利要求27所述的方法，其特征在于，获取对一个或多个可用软件更新的选择包括获取对一个或多个可用软件更新的自动选择。

30.如权利要求27所述的方法，其特征在于，所述软件更新服务包括一具有对可用增量补丁的选择的文件，并且其中，所述索引对应于对可用增量补丁的每一选择的特定存储位置的标识。

31.如权利要求30所述的方法，其特征在于，请求所述一个或多个所选择的增量补丁包括通过标识所请求的增量补丁的特定存储位置请求来自所述文件的特定增量补丁。

32.如权利要求30所述的方法，其特征在于，请求所述一个或多个所选择增量补丁包括通过标识每一所请求的增量补丁的特定存储位置请求来自所述文件的一组特定增量补丁。

33.如权利要求27所述的方法，其特征在于，还包括：

在安装所述更新文件之前确认所述更新文件；以及

如果所述更新文件不被确认，则恢复所述更新文件的前一版本。

34.如权利要求27所述的方法，其特征在于，请求所述一个或多个所选择的增量补丁包括发送对所选择增量补丁的前台请求。

35.如权利要求27所述的方法，其特征在于，请求所述一个或多个所选择的增量补丁包括发送对所选择增量补丁的后台请求。

36.如权利要求27所述的方法，其特征在于，获取所述客户机计算装置上安装的一个或多个文件的详细目录包括获取所述客户机计算装置上安装的一个或多个文件的高速缓存的详细目录。

37.一种计算机系统，包括：

用于获取对用于更新所述客户机计算装置上安装的一个或多个文件的一个或多个可用软件更新的选择的装置；

用于获取标识多个增量补丁的索引的装置，其中，每一增量补丁对应于已安装文件的至少一个版本；

用于获取所述客户机计算装置上安装的一个或多个文件的详细目录的装置；

用于选择一个或多个可适用的增量补丁以实现所选择的软件更新的装置，其中，选择所述一个或多个可适用的补丁对应于将标识多个增量补丁的索引映射到所述客户机计算装置上安装的一个或多个文件的详细目录；

用于请求所述一个或多个所选择的增量补丁的装置；

用于获取所请求的增量补丁的装置；

用于将所述增量补丁与对应的已安装文件合并，以生成一更新文件的装置；以及

用于安装所述更新文件的装置，

其中，在传送专用更新时以特定类型的客户机为目标。

Images