专利名称：更新软件程序的系统和方法
技术领域：
本发明是关于软件安装，具体地说是关于更新软件程序的方法。
背景技术：
有很多种传统的用于更新在诸如像PC机的通用计算机上执行的软件程序的方法。具体的说，应用程序和操作系统程序包括一种工具，所述的工具用于测定应用程序或者操作系统程序的更新程序(例如，较新的版本)是否有效，下载所述的更新程序(例如，通过诸如Internet的通信网络)并且将所述的更新程序应用于当前安装的程序上。举例来说，Microsoft Windows XP操作系统(由Microsoft Corporation，Redmond，WA出产)包括一种涉及“Windows Update”的性能，所述的“Windows Update”允许执行在Internet浏览器程序上的指令测定安装在个人电脑上的特定的Windows XP操作系统部分。
当访问特定的Internet站点(http//windowsupdate.microsoft.com)时，程序就会被加载并在浏览器程序中被执行(例如，Microsoft Explorer浏览器程序)，并且关于本地PC机的操作系统的配置信息被传递到置于Internet上的更新服务器上。如果具有有效的更新程序，那么有效更新程序的对话框就会在浏览器中出现在用户的面前。所述的有效更新程序反映了这些更新程序适用于当前PC机的软件配置。用户进行选项以应用一个或多个所述的更新程序，并且开始更新进程，所述的更新进程是将更新软件安装在PC机上。然而，更新被限定在将在PC机浏览器程序正在运行的情况下，并且Windows更新程序需要用户的介入以确定是否应用更新程序。
还有其它更新软件的系统。举例来说，应用程序(诸如Microsoft Internet Explorer浏览器应用程序)周期性地联系更新服务器以测定是否存在有效的更新程序。通过选择在InternetExplorer程序中的配置选项，或者通过在指定的网站上手动进行对更新程序的搜索，所述的联系能够被自动地执行。然而，实际的更新程序安装包括用户选择是否他/她将要安装更新程序并且配置有关更新的各个不同的方面。无论如何，更新同上面所讨论的Windows更新程序相似，也需要用户的介入。还有其它的应用程序(例如，由Real Networks，Inc，Seattle，Washington出产的RealOne多媒体播放器程序和Microsoft Windows多媒体播放器程序)包括相似的用于检验有效软件更新程序并且更新程序的性能。
还有其它类型的软件工具可以被管理者使用以将软件分配到多个PC机上，举例来说，如由Microsoft Corporation出产的Microsoft系统管理服务器软件程序。然而，由于管理者必须手动地选择哪个软件应用程序将被分配到选定的PC机上，因此这些工具也需要一些顺序设置的进度并需要手动的介入。
发明内容
在当前可用的更新系统和进程中存在很多的缺点。大多数传统的系统和进程都是为PC机所设计的，这包括在更新的过程中需要用户的介入。更具体的说，大多数的更新过程都需要指引PC机浏览器界面进入网站上，在那里还需要用户进一步的进行下载和应用更新程序。根据本发明的一方面，在不需要用户的介入的情况下自动地更新系统的软件是非常有利的。进一步，期待会有能够在不是PC机系统上执行软件的更新的系统，例如网络设备，不间断供电电源(UPS)，或者其它的系统。
进一步，传统的软件更新系统和进程通常为检验并更新某个单个的系统而设计。在本发明的一方面，有利于系统可以从更新服务器上接收软件更新程序并将这些软件更新程序应用在一个或多个系统上。在这种方式下，所述的系统可以进行中心管理并在多个系统中执行更新进程。从很多方面来讲，这都是很有益的，包括·不需要在每一个系统上执行系统更新，不需要管理者进入每一个系统以执行软件更新程序——更新程序能够从单个系统被执行在多个系统上。
·更新可以被自动地应用在多个系统中，不需要用户代表管理者介入。
·更新程序在单个系统中可以更容易地被管理，而传统上，管理者需要检测每一个系统以测定更新程序是否被适当地应用。
·如果代理服务器能够下载有效更新程序并将这些有效更新程序分配到其它的系统中，则就可以更少的连接更新服务器(并且因此可以做到经常的处于可用状态)。
本发明的另一方面，可以意识到用单个的系统负责接收并应用软件更新程序是很有益处的。在另一方面，所述的单个系统可以更新不能与更新服务器相互通信的系统。举例来说，将被更新的系统可能是网络设备，所述的网络设备没有界面，或用于从更新服务器中下载和应用更新程序的适当的控制和/或协议。通常，网络设备不包括与更新服务器相结合的用户接口和其它的设备接口。因此，提供一种代理系统，所述的代理系统可以代替将被更新的系统取回更新程序并将更新程序应用到系统中。举例来说，所述的代理系统能够控制哪个系统接收软件更新程序，何时接收更新程序，以及更新进程中的其它的方面。
根据本发明的另一方面，更新程序目录从更新服务器中被下载并且服务器测定哪个更新程序需要被应用到特定的系统。因为更新目录被下载，而不是像传统的更新方法一样将版本信息和其它的系统信息都传递到更新服务器上，这样关于用户设备和配置的信息不会被传递到更新服务器上，因此更新程序就被更加安全的应用。
在一个实施方案中，更新程序的目录被周期性地下载并且代理服务器将识别一个或多个有效更新程序的信息与识别一个或多个被管理的系统的信息进行比较。如果某个更新程序与某个特定的系统相匹配，那么这个更新程序就将被应用在这个系统中。代理服务器也能够更新其自己的软件。
根据本发明的一方面，提供更新软件的方法。所述的方法包括的动作有更新服务器的准备，所述的更新服务器适合存储一个或多个软件更新程序，接收来自更新服务器上的由更新服务器所提供的更新程序目录，测定是否至少一个有效更新程序适合至少一个被管理的设备，如果是，则下载这个至少一个有效更新程序并将所述的至少一个有效更新程序应用在所述的至少一个被管理的设备中。
根据本发明的一方面，提供一种方法，该方法用于更新包括更新服务器在内的系统中的软件，所述的更新服务器适合存储一个或多个软件更新程序。所述的方法包括的动作有从更新服务器中接收由更新服务器提供的更新程序目录，测定是否由更新目录提及的至少一个有效更新程序适用于至少一个被管理的设备，以及，如果是，则下载这个至少一个有效更新程序并且将这个至少一个有效更新程序应用于所述的至少一个被管理的设备中。
根据本发明的一个实施方案，所述的方法进一步包括的动作有保留本地更新程序目录，以及将接收的更新程序目录与本地更新目录合并。根据另一个实施方案，所述的至少一个有效更新程序包括操作系统部分和管理部分，其中应用所述的至少一个有效更新程序的动作进一步包括在将管理部分应用到至少一个被管理的设备中之前，将操作系统部分应用到至少一个被管理的设备中。
根据另一个实施方案，接收、测定、下载和应用的动作中的每一个都由副服务器所执行。根据另一个实施方案，测定的动作包括将与至少一个有效更新程序相关的文件的文件名信息和与至少一个被管理的设备相关的软件的当前部分的文件名信息进行比较。根据另一个实施方案，所述的方法进一步包括的动作有将至少一个文件发送到至少一个被管理的设备中。
根据本发明的一个实施方案，所述的方法进一步包括校验的动作，所述的校验是校验与至少一个有效更新程序相关的至少一个文件没有被破坏，其中校验的动作先于应用的动作而被执行。根据另一个实施方案，校验和应用的每一个动作都由副服务器所执行。根据另一个实施方案，所述的副服务器执行用于多个被管理的设备中的一个或多个更新程序。
根据另一个实施方案，多个被管理的设备是不间断电源(UPS)系统的每个部件，其中副服务器将一个或多个更新程序应用到UPS系统中被选定的部件中。仍然根据另一个实施方案，所述的方法进一步包括测定的动作，代表多个设备，测定是否更新程序存在于更新服务器中。
根据另一个实施方案，将与至少一个有效更新程序相关的文件的文件名信息和至少一个被管理的设备的软件的当前部分的文件名信息进行比较的动作包括的动作有将与至少一个有效更新程序相关的文件的修订值信息和至少一个被管理的设备的软件的当前部分的修订值信息进行比较，并且基于这种比较测定至少一个被管理的设备是否需要被更新。根据另一个实施方案，所述的方法进一步包括的动作有测定至少一个有效更新程序的修订值是否是软件的新修订值，所述软件的新修订值与至少一个有效更新程序相关的修订值文件和至少一个被管理的设备的软件的当前部分的文件名信息进行比较。
根据另一个实施方案，至少一个有效更新程序包括操作系统部分和管理部分，并且其中应用至少一个有效更新程序的这一动作进一步包括将操作系统部分应用于至少一个被管理的设备中，以及将管理部分应用到至少一个被管理的设备和至少一个被管理的设备的管理器两者中的至少一个中。根据另一个实施方案，如果至少一个被管理的设备与公共网络相耦合，则管理部分被应用到所述的至少一个被管理的设备中。根据另一个实施方案，如果至少一个被管理的设备与私人网络相耦合，则管理部分被应用到所述的至少一个被管理的设备的管理器中。根据另一个实施方案，如果管理器适合应用至少一个有效更新程序，则管理部分被应用到至少一个被管理的设备的管理器中。根据另一个实施方案，管理器适合执行的动作有接收、测定、下载以及应用至少一个有效更新程序。
根据本发明的另一方面，提供一种用于更新软件部分的系统。所述的系统包括被配置用以存储多个有效更新程序的更新服务器，以及用于管理多个设备的副服务器，其中所述的副服务器适于测定多个有效更新程序中的任何一个是否适于被应用到多个设备中的至少一个中，并且如果可以，则将多个更新程序中的至少一个应用到多个设备中的至少一个中。根据本发明的一个实施方案，多个更新程序中的至少一个包括操作系统部分和管理部分，并且其中副服务器适于在将管理部分应用到多个设备中的至少一个中之前，将操作系统部分应用到多个设备中的至少一个中。
根据另一个实施方案，副服务器适于将与至少一个有效更新程序相关的文件的文件名信息和多个设备中的至少一个的软件的当前部分的文件名信息进行比较，并且适于根据这种比较测定多个设备中的至少一个是否应该被更新。根据另一个实施方案，副服务器包括适于从更新服务器中接收有效更新程序目录的界面。
根据另一个实施方案，副服务器包括一种用于存储本地更新程序目录的存储器，并且其中所述的副服务器适于将接收的更新程序目录与本地更新程序目录合并。根据另一个实施方案，副服务器适于将与多个更新程序中的至少一个相关的文件的文件名信息和与多个设备中的至少一个相联系的软件的当前部分的文件名信息进行比较。根据另一个实施方案，副服务器适于将与多个更新程序中的至少一个相关的至少一个文件装载到多个设备中的至少一个上。根据另一个实施方案，副服务器适于基于所述的比较测定多个设备中的至少一个是否应该被更新。根据另一个实施方案，多个被管理的设备是不间断电源(UPS)系统的每一个部件，以及其中副服务器适于将至少一个更新程序应用到UPS系统的一个或多个被选定的部件上。
本发明进一步的特点和优点以及本发明的各种不同实施方案的结构和操作都在接下来结合附图作以进一步详细的说明。在附图中，相同的参考数字代表相同的或功能上相近似的元件。另外，参考数字最左边的一个或两个阿拉伯数字指示参考数字第一次出现在附图中。
本发明通过在所附的权利要求中的特征被指出。通过结合附图和下面的说明，本发明的前面提到的和进一步的优点将会被更好的理解，在附图中，相似的参考数字代表相同或相似的元件。
在附图中图1是根据本发明一个实施方案的更新软件程序的系统的方框图；图2是可以执行本发明的各种不同方面的通用计算机系统的方框图；图3是根据本发明的一个实施方案的软件更新进程的流程图；图4A-4B是根据本发明的另一个实施方案的软件更新进程的流程图；
图4是根据本发明的一个实施方案的软件更新进程的流程图；图5是根据本发明的一个实施方案的软件更新进程的流程图；图6是根据本发明的一个实施方案的软件更新进程的流程图；图7是根据本发明的一个实施方案的软件更新进程的流程图；图8A-8B是根据本发明的一个实施方案的软件更新进程的流程图；图9是根据本发明的一个实施方案的软件更新进程的流程图；图10A-10B描述的是根据本发明的一个实施方案的软件更新进程的流程图；以及图11是根据本发明的一个实施方案的软件命名格式的方框图。
具体实施例方式
图1示出根据本发明的一个实施方案的更新软件程序的系统的方框图。系统100包括更新服务器101，所述的更新服务器存储将被应用到系统103A-103C中的一个或多个软件更新程序。更新服务器101通过通信网络连接到其它的系统上。举例来说，更新服务器101可能是一种Internet服务器，所述的Internet服务器通过一个或多个公共或私人网络被访问。举例来说，更新服务器101可能是常规的web服务器，所述的web服务器通过使用一个或多个诸如TCP/IP的网络协议能够传递软件程序。进一步，服务器101通过使用一个或多个应用层协议可以提供文件，诸如，HTTP，FTP或其它的协议。
系统100也包括服务器102，所述的服务器102适于通过线路104与更新服务器101相互通信。举例来说，线路104可能是将服务器102耦合到更新服务器101上的一个或多个网络、部件和/或媒体。在一个实施方案中，服务器102位于企业网络中，更新服务器101是位于Internet上的web服务器。服务器102能够与更新服务器101相互通信以测定软件更新程序是否有效。如果有效，则服务器102从更新服务器101中获取信息，所述的信息指示何种类型的更新程序是有效的，并且在一个或多个相关的系统的信息(例如，系统103A-103C)基础上，服务器102测定服务器101的一个或多个软件更新程序是否适用于系统103A-103C。如果是，则服务器102通过适当的协议(如，HTTP)从更新服务器101中下载一个或多个可适用的更新程序，并且适当地将这些更新程序应用到系统103A-103C中。
服务器102可能通过一个或多个网络线路105被耦合到系统103A-103C上。线路105可能包括被用来将来自服务器102中的信息传递到系统103A-103C上的一个或多个网络、部件或媒体。举例来说，线路可能包括以太网或任何其它类型的网络连接和/或活动的装置。举例来说，服务器102可能是将在下面结合图2作以进一步详细描述的通用计算机系统。举例来说，系统103A-103C可能是被服务器102所管理的系统。服务器102可能包括硬件(例如，实体服务器系统)和软件(例如，在服务器102上本地执行，以及管理者在远程用户上执行的相关管理软件的应用程序)。
根据本发明的一方面，服务器102为系统103A-103C执行软件产品更新服务。举例来说，系统103A-103C可能是不间断电源(UPS)系统的设备。所述的UPS系统的设备可能是，举例来说，包括环境监控单元的UPS的子系统部件，UPS系统处理器部件、电池、空气调节装置部件或其它的系统、设备或部件。
在一个实施方案中，服务器102可能包括一个或多个硬件和/或软件协议以连接到系统103A-103C上。在一个实例中，系统103A包括网络管理模块，所述的网络管理模块为网络管理系统提供性能和配置数据。在一个实例中，网络管理模块通过使用已知的简单的网络管理协议(SNMP)就能够被管理。所述的网络管理模块也可以通过使用基于web的界面被监控。这样的基于web的界面可以由下载的软件通过使用HTTP协议的网络被提供给浏览器程序。服务器102可能通过使用一个或多个通信协议适于控制和监控系统103A-103C，并且可以理解的是，本发明并没有限定使用任何特定类型的协议。
通用计算机系统根据本发明的一个实施方案，举例来说，服务器系统201可能在一个或多个计算机系统中被执行。举例来说，所述的这些计算机系统可能是通用计算机，诸如基于Intel PENTIUM处理器，专用处理器(例如，由Via Technologies，Inc.出产的C3处理器)，或者任何其它类型的处理器的通用计算机。人们将会理解，根据本发明的各种不同的实施方案，一个或多个任何类型的计算机系统可能被用来接收和分配软件更新程序。进一步，系统可能被置于单个计算机中或被分配于由通信网络相互连接的多个计算机中。
根据本发明的一个实施方案，一种通用计算机系统被配置用以更新与一个或多个其它系统相关的软件程序。人们将会理解，所述的系统可能执行其它的功能，包括更新其本身的软件或者执行任何其它的功能，并且本发明没有限定执行任何特定的指令或功能集合。举例来说，所述的系统可能在现存的工业品上被执行，诸如，举例来说，网络管理系统。其它的执行也是可能的，并且本发明没有限定到任何特定的执行。
举例来说，本发明的各种不同的方面可能作为执行于如附图2所示的通用计算机系统201上的专门的软件而被执行。计算机系统201可能包括处理器202，所述的处理器202被连接到一个或多个存储装置203上，诸如磁盘驱动器，存储器或者其它的用于存储数据的装置。在计算机系统201的操作期间，存储器203典型地用于存储程序和数据。在计算机系统201中的设备可能通过通信设备或系统205而相互耦合，举例来说，所述的通信设备或系统205可能包括在系统201中的相互通信数据的一个或多个通信元件(例如，总线、电桥、路由器等)。计算机系统201也包括一个或多个输入/输出设备207，诸如键盘、鼠标或画图设备)。另外，计算机系统201可能包含一个或多个通信设备204，所述的通信设备204将计算机系统201连接到一个或多个通信网络上(例如，网络208)。在本发明的一个实施方案中，系统201负责更新置于公共或私人网络上设备的软件，因此系统具有两个网络界面——一个与私人网络相耦合以及一个耦合到公共网络上。
在一个实施方案中，本发明的各种不同的方面可能在由American Power Conversion Corporation(APC)，West Kingston，RI.出产的InfraStruXure Manager服务器应用产品中被执行。所述的InfraStruXure Manager产品提供基于浏览器web的APC设备的远程管理。
尽管计算机系统201是以基于可能被实践的本发明的各种不同的方面的一种类型的计算机系统而作为实例被示出的，但是人们可以理解本发明并没有限定到在图2所示的计算机系统中被实现。本发明的各种不同的方面可以在具有不同于图2所示的结构或部件的一个或多个计算机上被执行。
计算机系统201可以是使用高级计算机编程语言的可编程的通用计算机系统。计算机系统201也可能通过使用特定程序化的，特定目的的硬件被执行。在计算机系统201中，处理器202典型是通用的商用处理器，诸如像由Intel公司出产的闻名的Pentium处理器。很多其它的处理器也是可用的。作为替代，本发明的各种不同的方面也可以在专用处理系统(带有专用处理器和存储器)中被实现。这样的处理器通常运行的操作系统可能是，举例来说，由Microsoft公司出产的Windows CE，Windows NT，Windows Server 2XXX，Windows 2000(Windows ME)或者Windows XP操作系统，或者由不同的厂商(如，Linux)出产的基于UNIX的操作系统。很多其它的操作系统也可能被使用，并且本发明没有限定使用任何特定的实施方案。
36根据本发明的各种不同的实施方案，应用软件更新程序的副服务器的硬件配置的实例包括下面的部件处理器Via C3@800MHzRAM 256MB PC133
NIC’s2 Realtek RTL8139C(一个与公共网络相耦合，一个与私人网络相耦合)端口系列1RS-2321RS-485USB2USB 1.1HDD40GB 5400RPM IDEHW WatchDog 1-255秒w/增加1秒本发明的各种不同的实施方案可能通过使用一种目标导向编程语言被编程，诸如像SmallTalk，Java，C++，Ada，或者C#(C-Sharp)。其它的目标导向编程语言也可以被使用。作为替代，功能性的，脚本和/或逻辑编程语言可能被使用。本发明的各种不同的方面可能在非编程环境下被执行(例如，当出现浏览器程序的窗口，图形用户界面的所呈现的各个方面或者执行其它的功能时，由HIML，XML或其它格式所产生的文件)。本发明的各种不同的方面可以作为程序化的或非程序化的元件，或者其任何的组合元件被执行。
人们会明白，本发明没有限定到特定的计算机系统平台、处理器、操作系统或者网络。同样，对于在这个领域内的技术人员来讲可以理解的是，本发明没有限定到专用的编程语言或者计算机系统。进一步，人们将会理解，其它合适的编程语言以及其它的合适的计算机系统也可以被使用。
系统的一个或多个部分可能被分配到与通信网络208相耦合的一个或多个计算机(例如，系统209-210)中。这些计算机系统209-210也可能是通用计算机系统(例如，一种执行管理程序的客户计算机，所述的客户计算机与系统201相关联工作)。举例来说，本发明的各种不同的方面可能被分配到一个或多个计算机系统的中，所述的计算机系统被配置为一个或多个客户计算机提供服务(例如，服务器)，或者作为被分配系统的一部分执行整个任务。举例来说，本发明的各种不同的方面可能在客户服务器系统中被执行，所述的客户服务器包括被分配到一个或多个服务器系统中的部分，所述的服务器系统根据本发明的多个不同的实施方案执行各种不同的功能。这些部分可能是可执行的，中间的(例如，IL)，或者解释的(例如，Java)编码，所述的这些编码通过使用通信协议(例如，TCP/IP)通信网络(例如，Internet)而通信。
人们将会理解，本发明没有限定到在任何特定的系统或系统组而执行。同样，人们将会理解，本发明没有限定到任何特定的分配结构、网络或者通信协议。
在图3中所示的是根据本发明的一个实施方案用于更新软件的一个进程。在方框301，进程300开始。在方框302，系统(例如，服务器102)能够测定用于固件、应用软件和软件(例如，应用程序、OS或两者)的更新程序是否是有效的。一种更新服务器(例如，更新服务器101)将被配置为每一个正在为更新而被检验的产品类型返回有效更新程序的“目录”。所述的检验，举例来说，可能通过执行在服务器中的软件被执行，所述软件负责将更新程序应用到一个或多个系统(例如，系统103A-103C)中。
在方框302，系统(例如，应用更新程序的系统)测定一个或多个更新程序是否是有效的。举例来说，软件程序将被配置以测定特定的更新程序是否相关于被管理的系统。举例来说，对照目录，软件程序可能比较它自身的产品版本，还有正在管理的软件产品(或实体)的一个或多个产品版本。如果测定存在适合服务器正在管理的任何产品的更新程序(例如，在方框303)，则服务器可以下载(例如，在方框304)更新程序并将更新程序的有效性通知给用户。如果测定不存在有效的更新程序，则系统可能操作在待命模式下或执行与管理的系统相关的其它的管理功能。
服务器也可能被配置以分配更新程序并将更新程序应用到一个或多个远程系统中(在方框304)。也可能会便于唯一地限定产品软件类型，并用于比较和测定更新程序何时有效。在方框306，进程300结束。进一步，根据一个实施方案，负责应用更新程序的系统可能是带有周期性变更的硬件配置有标准组件的系统的部分。最后，服务器可能鉴定有标准组件的系统的部件，以测定任何部件是否需要被更新。举例来说，系统可能是有标准组件的不间断电源(UPS)系统的一部分，所述的UPS用于为计算机或其它系统负载提供备用电能。系统本身也可能是整个UPS系统部件。
图4A-4B示出了更新软件程序的进程400。在方框401，进程400开始。在方框402，执行在服务器上的软件程序被配置以从更新服务器中下载有效更新程序的目录(例如，编码或模固件，用于管理的插件程序，应用程序和操作系统软件)。在一个实施方案中，更新服务器通过诸如Internet的公共网络被耦合到服务器上。所述的更新服务器可能被部件或系统制造商(例如，theAmerican Power Conversion corporation of West Kingston，RI)放置在网络上，以便更新已经销售给顾客的产品中的软件或固件。以这种方式，顾客不需要将产品返回给制造商或替换整个产品就能够接收到新的软件版本，举例来说，如地址错误调整，提供新的特征等等。
在方框403，软件程序将从更新服务器中下载的有效更新程序的目录与现有的目录(如果存在)进行合并。如果不存在现有的目录，则它可以通过从每一个被管理的设备中所获得的信息而构建。举例来说，当软件程序被执行时，软件程序可能检查执行在每一个被管理的设备中软件的软件版本，在方框404。通过在服务器和被管理的设备的一个或多个之间使用任何通信协议，都可以进行所述的检查。在方框405，程序将用于每一个被管理的设备上的软件的相关信息(例如，软件版本信息)存储在数据库中。这些信息可能被用来建立关于被管理的设备的信息目录。
在方框406，服务器软件对照目录中的信息比较软件正在管理的实体的软件版本，并且基于这种比较测定更新程序是否有效。
在另一个实施方案中，如果服务器软件正在管理的任一设备具有有效的更新程序，则服务器软件被配置以通知用户(例如，以图形用户界面，e-mail形式等)。在本发明的一方面，服务器软件易于使更新程序安装在远程设备/系统中，并提供确定被更新的设备/系统的状态报告(例如，给用户)。在方框407，服务器软件测定任一有效更新程序是否应该被应用到任一被管理的设备上。如果测定任一更新程序应该被应用到任一管理系统上，则在方框408，软件程序将下载将被应用到被管理的设备上的更新程序。在一个实施方案中，被下载的更新程序仅仅是那些与需要被更新的被管理的设备相关的更新程序。
在方框409，软件程序可能作为任选项在将更新程序的一个或多个文件应用到被管理的设备上之前，验证更新程序的一个或多个文件。举例来说，这样的功能可以通过测定将文件的一个或多个部分的校验和与置于文件(或文件组)中的校验和的比较来实现。其它的校验的方法也可以被执行。
在方框410，软件程序将一个或多个文件装载到可应用的被管理的设备中。举例来说，这样的装载可以通过使用一个或多个文件传输协议(例如，TFTP，FTP等)或者任何其它的将程序装载到设备中的方法被执行。在方框411，管理设备需要被复位或者重启，这样更新才能生效(例如，在方框411)。可选择地，在方框412，软件程序可能验证一个或多个更新是否成功。举例来说，这样的一种验证可以通过在被管理的设备上执行一个或多个指令(例如，情况查询)或者其它操作以指示设备正在适当的操作来实现。在方框413，进程400结束。
在一个实例系统中，更新服务器存在保留关于有效更新程序的信息。所述的更新服务器可能通过Internet和/或其它的网络被耦合到副服务器上。在另一个实施方案中，更新服务器被配置以等待听从来自在这个领域内的软件部分的请求(例如，来自副服务器)，并且被配置用以请求包括关于有效更新程序的信息的响应。所述的更新服务器，举例来说，可能由装备和/或软件制造商来维持，并且更新服务器可以作为新的软件解压被更新是有效的(例如，由制造商)。
在一个实施方案中，副服务器可能管理在用户网络上的大量设备。举例来说，如前面结合图2所讨论的，副服务器可能依靠使用网络管理协议管理设备/系统。作为这些各种不同设备的管理的部分，服务器有能力(例如，通过查询使用诸如SNMP的网络管理协议的设备)获得在设备上运行的软件/固件的版本。副服务器软件提供向更新服务器询问有效更新程序的更新部分。
一旦接收确认有效更新程序的信息，更新部分就会对照从更新服务器中获得的版本检验软件/固件版本。举例来说，所述的检验可以通过将确认被安装在系统中当前的软件的文件名信息和与特定的更新程序相关的文件名信息进行比较而完成。如果任一更新程序是有效的，则更新程序将从更新服务器中被下载到副服务器上。其后，更新程序的有效性将被通知给用户。用户将使用副服务器将更新程序分配到他们期望的领域内的设备上。进一步，副服务器适于自动地接收和应用更新程序。
带有副服务器的一个优点在于每一个需要被更新的设备不需要为了更新而必须连接到更新服务器上。作为替代，提供一种副服务器，可以测定更新程序是否有效，并且一次从更新服务器中下载合适的软件。在传统的软件分配系统中，相同的软件多次被不同的客户下载。这样的结果是，每一个客户必须有能力与更新服务器相连接，需要更有资格的客户。同样，直接为多个终端客户服务的传统的更新服务器可能因为对于同一个文件的多个请求而被淹没。根据一个实施方案，提供一种作为多个设备的代理而动作的副服务器。
进一步，根据本发明的一个实施方案，用户可以控制哪些设备实际上得到更新，并且这些更新发生在何时。这样，下载和设备的更新就不需要被顺序地执行，例如，一旦更新程序被下载，就被应用。而不是更新进程是用户配置的，这在于根据在更新程序被下载后一段时间的预先确定的进度表或一组规则，下载可能被应用。在网络设备或其它系统部件的情况下，软件的更新需要设备被重启，因此这需要在合适的时间或以合适的次序应用更新程序。
进一步，根据另一个实施方案，在软件更新程序有效时，提供用户通知。举例来说，当与由副服务器所管理的特定设备相匹配的更新程序有效时，就会提供所述的通知。举例来说，所述的通知可以通过向设备的管理者发送E-mail或者其它的通知来完成。相反地，传统的软件更新系统仅仅在用户使用应用程序时才通知用户。
然而，对于不是被用户所正常操作的设备或系统(例如，UPS系统)，在传统的设备或系统中，不会提供通知以测定何时更新程序是有效的。因此，根据本发明的一方面，为设备或其它系统所提供的通知会在管理者控制之下。
在一个实例中，副服务器保留设备和它们确认信息(例如，型号，固件/软件版本等)的列表，并且将所述的信息与由更新服务器所提供的信息进行比较。基于这种比较，如果更新程序被测定存在，则就向用户(例如，网络管理者)发送确认有效更新程序的通知。通过允许服务器在更新程序有效时通知管理者，在更新程序有效时用户的通知允许管理者确认或是忽略，而不是必须周期地为更新程序检验更新服务器(例如，通过网站手动地)。进一步，同副服务器被更新以管理新的产品一样，用于这些新产品的固件更新机制被自动地适合支持这些新的产品。
更新服务器为请求服务器(例如，副服务器)提供有效更新程序目录，而不是请求服务器为鉴定返回每一个独特的被管理部件。因为，根据本发明的一个实例配置，被管理部件没有被传送返回到更新服务器，因此返还到更新服务器中(以及其后，到更新服务器所耦合的网络上)的信息量就被减少。进一步，因为提供了一种用于更新领域设备和系统的中间服务器，因此减少了对修改更新服务器协议以支持新的设备和系统的需求。
下面的实例说明了用于更新软件的系统和方法的各种不同的实施方案。本发明没有限定到所述的特定实施方案中，但是当然，本发明可能包括独立于其它方面的一个或多个方面。下面将要说明的是更新服务器、副服务器和由副服务器所管理的设备(例如，UPS系统部件)。在实例中，更新服务器由产品制造商(例如，the American Power Conversion Corporation(APC))来维持并且为顾客设备提供软件和固件更新程序并使之有效。
体系结构和设计实例图5示出了根据本发明的一个实施方案用于更新软件程序的进程500的实施例。更具体的说，图5示出的进程被服务器所执行，所述的服务器负责将更新程序应用到一个或多个被管理的设备中。在方框501，服务器程序(例如，应用程序)在服务器中(例如，副服务器)被执行。在方框502，服务器初始化来自更新服务器中的有效更新程序列表。举例来说，所述的列表可能是从与更新服务器相联系的存储单元中下载的有效更新程序的固件更新列表(例如，firmware_update avail.txt)。在方框503，测定是否存在有效的新的固件更新程序。
在一个实施方案中，考虑到将执行离线目录更新而使用的输入文件可能被执行。举例来说，经过FTP传输到没有内容的服务器上的离线更新可能被使用以将更新程序传送到被管理的设备上。在一个实施例中，用户任命输入目录和固件更新程序和管理部件(例如，以插件程序的形式)，并且在更新目录中任命这些更新程序的查找，然后在下一次服务器应用程序启动或检验更新程序期间，所述的输入目录被并入有效的目录中。更具体的，如果输入目录的文件存在，则输入目录记录被并入有效的目录中；否则，输入目录记录被放弃。
在方框504，服务器应用程序将最近的有效更新程序并入固件更新列表中，并且删除新的有效固件更新程序列表。在方框505，测定是否存在未决的固件更新列表(例如，文本文件)。举例来说，在更新程序从更新服务器中被下载时，所述的列表可能由副服务器所保留。举例来说，这种文件可能被建立以追踪固件下载的进程。举例来说，如果用于从更新服务器中下载更新程序的进程不成功，则这种文件的状态就被检验出来以继续或稍后重新尝试下载进程。在一个实施例中，未决的硬件更新列表的存在表示下载进程是不成功的。
如果未决的下载列表存在，在方框506，遗漏的更新程序将从更新服务器中被下载。举例来说，更新服务器可能由制造商(例如，APC)所维持以便为设备提供更新程序。在方框507，最近的有效更新程序被并入固件更新有效列表中，并且在一个实施例中，未决的固件列表被删除。
在方框508，测定被用来管理的任一控制或者其它的与在设备中被更新的固件相连接的其它控制是否需要被更新。这样，可能会有用于与带有更新的软件的管理设备相连接的相关的客户或管理副程序。这样的软件部分或程序可能是以附加在另一个程序(例如，Internet Explorer浏览器程序)上的插件程序的形式。
举例来说，有一种代表用于与不同的设备连接的控制的插件程序列表。所述控制清单可能由更新服务器中得出，并且副服务器可能测定是否加载任何相关的控制。在方框508，举例来说，副服务器可能从更新服务器中获得插件程序控制列表。在方框509，测定是否存在固件控制输入列表。如果存在，副服务器将最近有效的插件程序并入有效固件控制列表中并删除输入列表。在方框511，用于指出任何更新程序没有被下载到副服务器上的未决的更新程序列表被保留。如果这样，在方框512，测定在更新服务器中存在有效的插件程序，而在副服务器中没有，事件将被发布给服务器应用程序以指示下载是有效的。其后，服务器应用程序将下载合适的控制。
在固件和控制已经被下载到副服务器上之后，这些更新程序可能被应用到设备和管理这些设备的程序上。相似的更新进程可能被再次的执行以测定是否有将被应用的新的更新程序。
在一个实施方案中，更新程序从更新服务器中被激发到一个或多个副服务器上。举例来说，在方框602，副服务器被配置用以检验更新服务器上的更新程序。举例来说，这一动作可以通过由更新服务器发送事件给注册的服务器上来完成。作为替代，更新程序可能被由连接到更新服务器上的副服务器周期地测定。在一个实施例中，副服务器可能测定是否其含有最新的硬件和控制更新程序的列表。此后，相似于前面参考图5的描述，类似的进程可能被适用以更新软件。
图7示出下载有效更新程序的进程。在一个实施例中，如果下载插件或固件更新程序失败，则下载程序在另一检验被执行之前对于另一下载不会有效。如前面的描述，未决的目录在它的相应的下载任务完成后就被移开，并且只有成功的文件下载的记录才被保留。
如果在下载插件程序期间服务器关闭，则当服务器重新启动时任务不会继续进行。在一个实施例中，用户必须在激发的对话中再次提供许可以下载任一失败的插件程序。根据一个实施方案，任一已经被成功下载的插件程序不需要被再次的下载，因为它们的信息已经被保留在目录中(例如，再并入操作期间)，并且它们在更新设备中的使用是有效的。
在方框701，副服务器从更新服务器中下载未决的文件请求。这个列表确认用于下载到副服务器中的文件序列。在方框702，副服务器可能从更新服务器中下载插件程序未决的列表。所述列表确认需要管理一个或多个被管理的设备的任何控制。在方框703，副服务器将最近的有效插件程序并入有效控制列表(例如，firmware_controls_avail.txt)。在方框704，副服务器清除插件程序未决列表并且删除控制未决列表。特别地，如果下载一个或多个插件程序的进程不成功，则这些文件的存在将指示一些或全部的插件程序需要被下载。在方框705，副服务器清除有效下载的事件和状态，所述的事件和状态指示在更新服务器中新的下载有效。在方框706，副服务器为每一个设备发布请求以检验插件程序匹配。举例来说，可能会有一些执行在每一个设备上的检验以测定控制是否与装载在管理设备上的软件相匹配。
图8A-8B示出作为管理设备初始化的结果而被执行的软件更新进程。同样，当设备被发现时，从通信遗失状态返还，或者在更新固件请求完成后，进程800，820被执行。
在方框801，由副服务器完成对于单个设备的固件更新的检验。在方框802，副服务器为应用程序和/或固件文件名查询设备，所述的应用程序和/或固件文件名为正在被管理设备所执行的软件。在方框803，副服务器测定固件更新列表是否包括与管理设备相关的较新的版本。在方框804，副服务器报告用于管理设备的下一个版本是有效的，并且改变与设备相关的更新状态以指示存在将被执行的有效更新程序。在方框805，副服务器发布更新有效事件并且报告状态改变，所述的状态改变指示存在用于设备上的有效更新程序。这样的状态指示被呈现给应用程序中的用户，所述的应用程序由被用来管理设备的副服务器所提供。作为替代，指示可以通过其它的方法(例如，E-mail信息，SNMP陷阱等)被呈现给用户或网络管理者。
图8B示出对与管理设备有关的控制的检验。在方框821，副服务器检验用于管理设备的控制。在方框822，副服务器为与控制有关的应用程序文件名查询设备。在方框823，如果测定存在用于设备的特定版本的更新的控制，则在方框824，报告新的控制是有效的。具体的，副服务器将报告控制的名字和设备状态的变化(例如，以管理应用程序，E-mail或其它指示的方式)。在方框825，副服务器发出指示新的控制是有效的事件。
图9示出依照本发明的一个实施方案，更新软件的进程900。具体地，进程900示出一种程序，所述的程序因为向用户提供用于更新一个或多个管理设备的管理界面而被施行。在方框901，用户进入控制台并且被允许观测在更新服务器上的有效更新的部分的有效性。在方框902，副服务器获得包括管理部分的管理设备信息，所述的管理部分被用来管理设备。在方框903，用户在呈现给用户的状态窗口内选择设备。
在方框904，测定设备是否具有关联的部分。如果是，在方框911，测定所述的部分是否已经被安装在管理控制台上。如果是，在方框910，测定设备被置于哪种网络上。举例来说，如果正在被更新的设备被置于公共网络上，则在方框912，部分被安装在设备上。就是说，如果设备被置于公共网络上，则被用来管理设备的部分通常被置于设备的存储器内，并且基于随时的需要被下载到客户。如果设备被置于私人网络，则在方框913，所述部分被安装在副服务器上以允许副服务器管理设备。
如果没有与特定的设备相关联的部分，则在方框905，测定是否存在与设备相关联的说明屏幕，所述的说明屏幕呈现关于更新的信息。如果有，在方框906，说明屏幕被发出。如果没有，在方框907，关于不存在对于特定设备的有效的说明的提示被呈现给用户。
在方框911，如果测定在管理控制台上不存在有效部分，则从更新服务器中下载所述的部分。在方框909，如果测定下载是成功的，这时将执行一种关于所述部分是否被正确地安装的检验。如果不是被正确地安装，则在方框907，一种错误信息被指示给用户。然而，如果所述部分是被正确的安装，则在方框912，913，所述部分被分别恰当的地安装到设备或副服务器上。
图10A-10B示出关于从更新服务器中下载软件的几个实施方案。在方框1001，用户进入控制台(例如，如由副服务器所提供)。在方框1002，测定是否存在由更新服务器提供的部分，而没有出现在副服务器中。如果没有，在方框1006，允许用户继续进入进程。如果存在新的部分，则在方框1003，测定在副服务器中是否设置一种标记，所述的标记指示用户是否不希望被提示下载新的部分。举例来说，会有诸如“不要再次提示下载”的标记，所述的标记可以被设置在控制台的用户界面中。如果所述的标记被选中，则在方框1006，允许用户继续进入进程。如果没有被选中，则在方框1004，用户被提示是否下载更新的部分。如果是，则在方框1005，命令副服务器下载离线部分。如果不是，在方框1006，允许用户继续进入进程。
在图10B中，在方框1021，测定从服务器接收了有效下载指示。举例来说，所述的指示可能是由更新服务器发给副服务器的以指示从更新服务器的下载是有效的。在方框1022，如果测定出现了指示用户不希望被提示注意有效下载的标记，则在方框1025，管理进程被继续进行。如果没有出现所述的标记，则在方框1023，用户被提示提供一种指示，所述的指示关于是否将从更新服务器中下载控制(例如，在管理程序的界面或是以其它指示方法)。如果是，在方框1024，副服务器被配置以下载离线的更新程序。如果不是，在方框1025，控制被返还到管理控制台。
在一个实施例中，基础设施被组织进入为每一可更新的应用程序的单独的目录中以合并多个产品的需要。为副服务器产品更新应用程序和下载的“aem”目录被保存。所述的目录相对于产品更新程序段http//autoupdatev2.apcc.com/。执行在客户系统中的副服务器上的软件应用程序(或两者)执行软件更新程序，涉及在下文中的副服务器软件应用程序，包括两个功能块网络管理卡的固件更新程序和用于副服务器和它管理的软件部分的软件更新程序。
固件更新程序副服务器为达到几千个实体管理固件，诸如，举例来说，与被管理的设备相关的网络管理卡(NMC)。对于网络和应用程序的效率，副服务器将它的扩展构造数量报告给软件应用程序(例如，从属于并执行在更新服务器中的程序)，以及应用程序回馈完整的固件更新信息组。数据在请求时间被产生，举例来说，依靠直接地从描述有效更新程序的数据库中读取。扩展构造数量基于报告产品的解压状况允许过滤数据。
根据一个实施方案，副服务器可能识别下面的输入和输出数据格式输入数据格式在一个实施方案中，副服务器使用HTTP POST将下面的数据范围发送到副服务器软件应用程序中(例如，产品更新Web应用程序)。下面描述了根据本发明的一个实施方案的数据格式实例
表I-输入数据格式示例输出数据格式根据本发明的一个实施方案，数据可以以ASCII形式，逗点隔开的文本串的形式被返还。每个更新条目被总共9个逗点分开成10个字段。确保被返还到副服务器中的每个更新条目都具有全部的逗点集合，而不考虑空白数据字段。分号隔开每个更新条目。确保每个被返还到副服务器中的更新条目都以分号作为结尾。
图II-输出数据格式示例其它特征根据本发明的一个实施方案，关于软件更新进程有一个或多个额外的特征。举例来说，副服务器和软件更新应用程序的额外的特征有益于管理软件更新进程副服务器·报告关于顾客环境信息(详细目录信息，顾客注册等)。软件更新应用程序·存储数据库请求，因为数据库数据通常不能频繁的变化。
·为每个即将到来的下载请求记录额外的顾客专用信息。
·在另一个实例配置中，副服务器下载完整的产品更新信息集合。这减损了固件应用Web应用程序的控制和灵活性，因为副服务器为应用更新程序测定标准。
服务器软件更新程序副服务器的服务器软件(例如，管理应用程序)能够更新它自身的所有或部分应用程序，包括可应用的插件应用程序。因为产品更新需要副服务器以一对一为基础进行执行(一个请求对应副服务器的每个实例)，因此副服务器将描述它当前版本的数据报告给在更新服务器上的程序或其它的实体。这些信息将允许副服务器产品更新应用程序(例如，基于web的应用程序)测定哪个更新，如果有，则应用副服务器软件版本。
关于更新的产品版本的信息被包含在置于更新服务器中的数据库中。对于每个更新程序的信息会被包含在相关的数据库中。在一个实例中，Web应用程序返还URL区域(例如，安全的HTTP URL)，一个或多个应用程序被置于其中。
输入数据格式在一个实例中，副服务器使用HTTP POST将下面的数据字段发送给副服务器产品更新应用程序。根据本发明的一个实施方案，表III示出输入数据格式的实例。
表III-输入数据格式示例输出数据格式根据一个实施方案，副服务器产品Web应用程序具有三个响应方案1.如果必要的数据没有被副服务器产品更新Web应用程序所接收，则应用程序返回“残缺请求”。
2.如果没有更新程序适合被报告的副服务器软件版本信息，则应用程序返回“没有有效更新程序”。
3.如果没有更新程序适合被报告的副服务器软件版本信息，则应用程序返回下面的数据。
根据本发明的一个实施方案，表IV在下面给出数据格式示例
表IV-数据格式示例其它特征·报告关于顾客环境的信息(详细目录信息，顾客注册等)。产品更新应用程序·为每个到来的请求记录额外的顾客专用信息。
根据本发明的一个实施方案，副服务器软件使用安全的HTTP连接或FTP连接以下载有效更新程序。
自动更新服务器可能为存储web卡升级记录储存单独的表。目录可能被更新以允许产品管理者将产品更新与软件工具包(例如，为被管理的设备)相联系。
根据一个实施方案，当更新设备上的固件时(例如，卡)，副服务器软件发送OS和应用程序层两者，其中OS首先被发送，接在其后是应用程序层软件。可以理解的是当向卡发送任何二进制时，都会清除掉当前的应用程序层。因此，下载OS和应用程序层两者到卡上是优选的。
根据一个实施方案，副服务器可能检验被管理的设备以确保OS层更新是成功的。在一个实例中，副服务器可能执行FTP目录段的列表(例如，经过“ls”指令)并执行OS层文件的检验。如果副服务器被许可进入系统并且升级成功，则OS文件是新文件。如果副服务器被许可进入系统并更新不成功，则OS层文件是先前的OS层。
用于测定应用程序是否正确的操作的一种方法包括执行web卡的预期SNMP OID的查询，以及如果web卡能够响应，则SNMP运行，从而指示应用程序层在运行。
作为替代的方法包括执行FTP目录段的列表(例如，经过“ls”指令)并且确定由应用程序层所使用的事件文件(例如，“event.txt”)是否存在。如果多次尝试升级卡(例如，两次尝试，两次连续的失败)，这种情况可能被认为是硬件的故障。举例来说，为了更新一种类型的卡，副服务器软件需要用户/密码/端口以访问在web卡上的FIP服务器。
更新文件格式和命名协定根据一个实施方案，二进制固件文件包括首部。在一个实施方案中，所述的首部包含关于文件和整个文件与首部两者检验和的确认信息。所述的检验和可以被使用在试图发送文件到卡之前使文件生效(例如，使用FTP)。
下面的信息是关于文件格式和命名在实例中所使用系统的各种不同的执行程序用于控制的可执行类型DLL是用于发动的条目点(举例来说，所述的控制包括支持文件，像其它DLL，帮助)为控制命名格式apc_plugin_<应用程序层>_<控制版本>.举例来说，apc_plugin_rpdu_1.0.0.7.dll插件程序可能版本相似于其它软件major.minor.point.build(例如，6.1.1.107)用于控制的传递箱带有上述命名格式的CAB文件。举例来说，asp_plugin_rpdu_1.0.0.7.cab
由副服务器所使用的信息以将设备相配于控制应用程序层文件名，包括版本，与目录条目相匹配。
由服务器提供给控制台的信息以指示用于单独设备的发动控制CAB文件名，带有扩展名但没有路径。举例来说，apc_plugin_rpdu_1.1.1.7.cab用于将控制从服务器传递到控制台的传递方法HTTP请求。举例来说，http//<server ip>/<FTP directory>/<CAB file name>
在服务器上CAB文件位置ftp directory.example，/apcstorel/updates在控制台上控制安装位置<SystemDrive>\Program Files\APC\CommonClients\<CAB filename>.ex c\Program Files\APC\CommonClients\apc_plugin_rpdu_1.0.0.7.cab.
根据一个实施方案，设备应用程序文件名必须准确地和与设备有关的控制的目录条目相匹配。因为版本信息必须匹配，因此应该有用于专用固件的目录条目以选择控制。多个固件版本必须被变换成相同的控制，但是在一个实施方案中，每个都请求它本身的目录条目。因此，如果存在带有不同固件版本的设备，则相同控制的多个版本可能在单个系统中保持有效。
根据一个实施方案，一对一匹配的使用可以避免必须执行新控制与旧的固件版本之间的兼容性测试。一对一匹配的交易在于由于磁盘空间被控制所消耗，因此目录能够得到相当多的时间。根据本发明的一个实施方案，常规的文件命名实例在图11中作为例子被示出，以及显示示例的格式并在表V中被解释
表V-数据格式示例使用前面的常规的命名和编号方式可以确保很多软件更新方案。举例来说，在一个实施方案中，名称反映了控制所工作的设备类型，但是不包括任何应用程序层版本信息，因为单个控制可能与多个固件修正有关。同样，在不用针对固件进行相应的修正的情况下，控制可以被修正。
CAB文件可以包含多个文件，因此控制不需要成为单个的文件。根据本发明的一个实施方案，举例来说，在独立应用的场合，由控制符号所提供的安全性可以被Web浏览器所使用。作为替代，安全性也可以被副服务器所使用。无论如何，副服务器将检验控制以确保控制没有被修改并且被没有变化的由制造商所传递。
使用这种方法的主要的交易是简化磁盘空间。
简化——对服务器和控制台两者都是相对容易地检测是否它们需要下载控制。使用版本的文件名和用于控制的独立子目录，消除版本问题(例如，测定是否存在有效控制的较新版本，是否最新的控制版本向后兼容全部固件版本，是否DCal.dll的新版本向后兼容旧的控制，是否存在没有版本信息的支持文件等)。
磁盘空间——在CAB中的文件的每一次变化，CAB的名称和控制都必需变化。根据一个实施方案，控制的当前版本不会覆盖以前的(例如，即不是CAB也不是控制)。根据另一个实施方案，没有支持文件(例如，诸如DCall.dll)共享于控制中。根据一个实例，每一控制都带有它的全部支持文件完全的集合。系统将包括周期清理配置(例如，删除在x天，月，年等没有被使用过的文件)。
<控制 版本>格式的实例遵循如同卡相同的惯例wxyz，其中w＝major 1-9，x＝minor0-9，y＝point 0-9，z＝beta a-z，A-Z.这样没有限定每个为1数字/字符(123a＝1.2.3.a).同样，必须将build数字译成beta字符。
程序文件目录(如在基于Windows的计算机)可能作为用于控制的安装位置，因为它的内容对用户是显而易见的，在所有以Windows操作系统的类型和控制台所支持的定位版本中都是有效的，以及可以由控制台从OS中取回。在工作台工作目录下(例如，c\WinNT\Downloaded Program Files\APC\CommonClients\<CAB Filename>)，控制不被安装，因为只有通过指令提示，这些子目录和文件才对用户来说是显而易见的。在另一个代替的<SystemDrive>\Documents and Settings\ALL Users，软件可能被安装。
更新程序可能被分为三个目录1.用于设备的固件更新程序(例如，Web卡)
根据一个实施方案，关于任何更新的固件更新程序，副服务器将连续地将它们发到被管理的设备上(例如，网络管理卡)。与它们有关的文件包括固件更新目录，firmware_update_available.txt，其包含所有有效固件更新程序的列表，版本是什么，并且其中副服务器需要查看以从更新服务器中下载它们。副服务器使用这些目录以测定是否有用于这些设备的有效更新程序，并测定这些二进制更新程序的位置。所述的二进制更新文件的例子是apc_hw02_rPDU_220g.bin.
一旦副服务器已经测定存在有效的更新程序，则用户被提示从更新服务器中下载有效的更新程序，并且如果用户已经这样选择，则他们将通过email被通知更新程序是有效的。副服务器软件程序下载目录中的所有二进制到与副服务器相联系的存贮介质中，并且这时用户通过对话框被提示以允许他们选择将被更新的设备。副服务器将呈现给用户关于固件更新进程成功与否的状态报告。
2.用于副服务器软件程序的公共客户插件程序根据一个实施方案，用于副服务器软件程序的公共客户插件程序是为管理专用设备所设计的高性能客户。因此，如果用户选择了设备，则在管理状况屏中，用户将被呈现设备的详细情况和一些管理性能。如果公共客户有必要管理设备，则界面将提供设备的所有特征的路径，并带有极强的可用性，和可观性与易知性。这些公共客户在整个时间中为设备而建立，当他们有效时，他们被提示给更新服务器。当副服务器为更新程序执行检验时，副服务器将检测公共客户是否有效并下载他们。
一旦被下载，当用户试图双击设备，所述的设备能够被公共客户所管理，则客户将被分配到用户的客户机器并被发送。与公共客户相关的文件包括压缩文件，apc_plugin_rpdu_1.0.0.13.cab。所述的压缩文件包括插件程序发射装置和被需要以实际装载插件程序的多个dll’s。插件程序带有它们自身的“目录”文件，firmware_control_available.txt，其相似于固件更新程序目录，在于它描述了插件程序的版本是什么，以及插件程序所管理的设备是什么。副服务器使用所述的目录以测定任一插件程序是有效的以同设备相结合使用，所述的设备被服务器管理。
前面所描述的CAB文件包含公共客户插件程序分配。根据一个实施方案，仅有的控制处于独立应用程序中，在副服务器外部，公共客户被用来一对一管理设备，加载器控制被用来实际加载插件程序(例如，dll文件)。
下面的格式/字符为目录文件而被使用基于文本逗号分隔每一段以部分分号结束在固件更新程序文件中的字段包括硬件，应用程序，版本，专用部件，顾客，构造，应用程序URL，OS URL，描述文本，描述URL在公共控制文件中的字段包括硬件，应用程序，版本，专用部件，顾客，构造，本地，应用程序URL
尽管各种不同的文件格式和位置在此已经被具体地描述，但是可以理解的是本发明并没有限定到具体的实施方案中。
因此在此描述的是说明性的实施方案，在本领域内的技术人员会理解很容易进行各种不同的替换，修改和改进。所述的替换，修改和改进都在本发明的本质和范围内。据此，前面的描述只是作为示例而不是限定于此。
权利要求
1.一种用于更新含有更新服务器的系统中软件的方法，所述的更新服务器适于存储一个或多个软件更新程序，所述的方法包括以下动作从更新服务器中接收来自更新服务器的有效更新程序目录；测定在更新程序目录中所涉及的至少一个有效更新程序是否适于应用到至少一个被管理的设备中；以及如果是，下载所述的至少一个有效更新程序并将所述的至少一个有效更新程序应用到所述的至少一个被管理的设备中。
2.根据权利要求1所述的方法，进一步包括动作保留本地更新程序目录；以及将接收到的更新程序目录并入本地更新程序目录。
3.根据权利要求1所述的方法，其中所述的至少一个有效更新程序包括操作系统部分和管理部分，并且其中应用所述的至少一个有效更新程序的动作进一步包括在将所述的管理部分应用到所述至少一个被管理的设备上之前，将所述的操作系统部分应用到所述的至少一个被管理的设备上。
4.根据权利要求1所述的方法，其中接收、测定、下载和应用的动作的每一个都由副服务器所执行。
5.根据权利要求1所述的方法，其中测定的动作包括将与所述的至少一个有效更新程序有关文件的文件名信息和与所述的被管理的设备有关的软件当前部分的文件名信息进行比较。
6.根据权利要求1所述的方法，进一步包括将至少一个文件发送到所述的至少一个被管理的设备中的动作。
7.根据权利要求1所述的方法，进一步包括校验与所述的至少一个有效更新程序相关的至少一个文件没有被破坏的动作，并且其中校验的动作先于应用的动作被执行。
8.根据权利要求7所述的方法，其中所述的校验和应用的动作均由副服务器所执行。
9.根据权利要求4所述的方法，其中副服务器为多个被管理的设备执行一个或多个更新程序。
10.根据权利要求9所述的方法，其中所述的多个被管理的设备是不间断电源(UPS)系统的每个部件，并且其中副服务器将一个或多个更新程序应用到UPS系统的被选定的部件中。
11.根据权利要求1所述的方法，进一步包括测定动作，代表多个设备测定更新程序是否存在于更新服务器中。
12.根据权利要求5所述的方法，其中将与所述的至少一个有效更新程序有关文件的文件名信息和与所述的至少一个被管理的设备有关的软件的当前部分的文件名信息进行比较的动作包括的动作有，将与所述的至少一个有效更新程序有关的文件的修订值信息和与所述的至少一个被管理的设备有关的软件的当前部分的修订值信息进行比较，并且基于这种比较测定所述的至少一个被管理的设备是否应该被更新。
13.根据权利要求12所述的方法，进一步包括的动作有测定至少一个有效更新程序的修订值是否是软件的新修订值，所述软件的新修订值与至少一个有效更新程序相关的修订值文件和至少一个被管理的设备的软件的当前部分的文件名信息进行比较。
14.根据权利要求1所述的方法，其中所述的至少一个有效更新程序包括操作系统部分和管理部分，并且其中应用所述的至少一个有效更新程序的动作进一步包括将操作系统部分应用到所述的至少一个被管理的设备上，以及将管理部分应用到至少一个被管理的设备和至少一个被管理的设备的管理器中的至少一个上。
15.根据权利要求14所述的方法，其中如果所述的至少一个被管理的设备被耦合到公共网络上，则管理部分被应用到所述的至少一个被管理的设备中。
16.根据权利要求14所述的方法，其中如果所述的至少一个被管理的设备被耦合到私人网络上，则管理部分被应用到至少一个被管理的设备中的管理器中。
17.根据权利要求14所述的方法，其中如果所述的管理器适于应用所述的至少一个有效更新程序，则管理部分被应用到至少一个被管理设备的管理器中。
18.根据权利要求14所述的方法，其中所述的管理器适于执行的动作有接收、测定、下载以及应用所述的至少一个有效更新程序。
19.一种用于更新软件部分的系统，所述的系统包括更新服务器经过配置以存储多个有效的更新程序；以及适于管理多个设备的副服务器，其中所述的副服务器适于测定多个有效更新程序的任何一个是否应该被应用到多个设备中的任何一个中，并且如果是，则将多个更新程序的至少一个应用到多个设备的至少一个中。
20.根据权利要求19所述的系统，其中多个更新程序的所述的至少一个包括操作系统部分和管理部分，并且其中所述的副服务器适于在将管理部分应用到多个设备的所述至少一个中之前，将操作系统部分应用到多个设备的所述至少一个中。
21.根据权利要求19所述的系统，其中所述的副服务器适于将与至少一个有效更新程序相关文件的文件名信息和与多个设备的至少一个的软件的当前部分的文件名信息进行比较，并且基于这种比较测定多个设备的至少一个是否应该被更新。
22.根据权利要求19所述的系统，其中所述的副服务器包括适于从更新服务器中接收有效更新程序目录的界面。
23.根据权利要求22所述的系统，其中所述的副服务器包括用于存储本地更新程序目录的存储器，并且其中所述的副服务器适于将接收的更新程序目录并入本地更新程序目录。
24.根据权利要求19所述的系统，其中所述的副服务器适于将与多个更新程序的至少一个相关文件的文件名信息和多个设备的至少一个相关软件的当前部分的文件名信息进行比较。
25.根据权利要求19所述的系统，其中所述的副服务器适于将与多个更新程序的至少一个相关的至少一个文件加载到多个设备中的至少一个上。
26.根据权利要求24所述的系统，其中所述的副服务器适于在比较的基础上测定多个设备的至少一个是否应该被更新。
27.根据权利要求19所述的系统，其中所述的多个被管理的设备是不间断电源(UPS)系统的每一个部件，并且其中所述的副服务器适于将至少一个更新程序应用到UPS系统的一个或多个被选定的部件上。
全文摘要
用于自动更新系统软件的系统和方法。在一个实例中，不需要用户的介入，软件就可以被更新。进一步，提供的系统能够在非PC机系统中执行软件的更新，诸如网络设备，不间断电源(UPS)或其它的系统。在另一个实例中，提供用代理服务器更新系统多个部分的系统和方法，所述的代理服务器负责下载和应用更新程序的。
文档编号G06F9/44GK1898643SQ200480038705
公开日2007年1月17日 申请日期2004年10月27日 优先权日2003年10月27日
发明者布拉德·T·哈蒙德, 托德·J·吉尔昆杜, 丹尼尔·J·雷德蒙, 吉姆·希金思 申请人:美国能量变换公司