(57)【要約】  システムのソフトウェアを自動的に更新するためのシステムおよび方法が提供される。一例では、このソフトウェアはユーザの介入を必要とせずに更新される。さらに、ネットワーキング装置、無停電電源（ＵＰＳ）、または他のシステムといった非ＰＣシステム上でソフトウェア更新版を実行することが可能なシステムが提供される。別の例では、更新版をダウンロードし、適用する責任を担うプロキシシステムによって、システムの多数の構成要素を更新するためのシステムおよび方法が提供される。
2007510987.tif 000002
【特許請求の範囲】
【請求項１】
更新サーバを含むシステムにおいてソフトウェアを更新するための方法であって、前記更新サーバは１つ以上のソフトウェア更新版を格納するよう適合されており、前記方法は、
前記更新サーバから利用可能な更新版のカタログを、前記更新サーバから受信する行為と、
更新版の前記カタログに参照される少なくとも１つの利用可能な更新版が、少なくとも１つの管理される装置に当てはまるかどうかを判断する行為と、
当てはまる場合、前記少なくとも１つの利用可能な更新版をダウンロードして、前記少なくとも１つの利用可能な更新版を前記少なくとも１つの管理される装置に適用する行為とを含む、方法。
【請求項２】
更新版のローカルカタログを保持する行為と、
更新版の前記受信されたカタログを更新版の前記ローカルカタログと併合する行為とをさらに含む、請求項１に記載の方法。
【請求項３】
前記少なくとも１つの利用可能な更新版はオペレーティングシステム構成要素と管理構成要素とを含み、前記少なくとも１つの利用可能な更新版を適用する前記行為は、前記管理構成要素を前記少なくとも１つの管理される装置に適用する前に、前記オペレーティングシステム構成要素を前記少なくとも１つの管理される装置に適用する行為をさらに含む、請求項１に記載の方法。
【請求項４】
前記受信する行為、前記判断する行為、および前記ダウンロードして適用する行為は、二次サーバによって各々実行される、請求項１に記載の方法。
【請求項５】
前記判断する行為は、前記少なくとも１つの利用可能な更新版に関連付けられたファイルのファイル名情報を、前記少なくとも１つの管理される装置に関連付けられたソフトウェアの現在の部分のファイル名情報と比較する行為を含む、請求項１に記載の方法。
【請求項６】
前記少なくとも１つの管理される装置に少なくとも１つのファイルを送信する行為をさらに含む、請求項１に記載の方法。
【請求項７】
前記少なくとも１つの利用可能な更新版に関連付けられた少なくとも１つのファイルが壊れていないことを検証する行為をさらに含み、前記検証する行為は前記適用する行為の前に実行される、請求項１に記載の方法。
【請求項８】
前記検証する行為および前記適用する行為は、二次サーバによって各々実行される、請求項７に記載の方法。
【請求項９】
前記二次サーバは、複数の管理される装置のために、１つ以上の更新版を実行する、請求項４に記載の方法。
【請求項１０】
前記複数の管理される装置は各々、無停電電源（ＵＰＳ）システムの構成要素であり、前記二次サーバは前記１つ以上の更新版を前記ＵＰＳシステムの選択された構成要素に適用する、請求項９に記載の方法。
【請求項１１】
前記更新サーバ上に更新版が存在するかどうかを複数の装置の代わりに判断する行為をさらに含む、請求項１に記載の方法。
【請求項１２】
前記少なくとも１つの利用可能な更新版に関連付けられた前記ファイルのファイル名情報を、前記少なくとも１つの管理される装置のソフトウェアの前記現在の部分への前記ファイル名情報と比較する行為は、前記少なくとも１つの利用可能な更新版に関連付けられた前記ファイルの改訂レベル情報を、前記少なくとも１つの管理される装置のソフトウェアの前記現在の部分の更新レベル情報と比較して、前記比較に基づき、前記少なくとも１つの管理される装置が更新されるべきかどうかを判断する行為を含む、請求項５に記載の方法。
【請求項１３】
前記少なくとも１つの利用可能な更新版の改訂レベルが、前記少なくとも１つの管理される装置のソフトウェアの前記現在の部分へのファイル名情報への前記少なくとも１つの利用可能な更新版に関連付けられた改訂レベルファイルと比較して、ソフトウェアのより最近の改訂版であるかどうかを判断する行為をさらに含む、請求項１２に記載の方法。
【請求項１４】
前記少なくとも１つの利用可能な更新版はオペレーティングシステム構成要素と管理構成要素とを含み、前記少なくとも１つの利用可能な更新版を適用する前記行為は、前記オペレーティングシステム構成要素を前記少なくとも１つの管理される装置に適用し、前記管理構成要素を、前記少なくとも１つの管理される装置と前記少なくとも１つの管理される装置のマネージャとの少なくとも一方に適用する行為をさらに含む、請求項１に記載の方法。
【請求項１５】
前記少なくとも１つの管理される装置がパブリックネットワークに結合されている場合、前記管理構成要素は前記少なくとも１つの管理される装置に適用される、請求項１４に記載の方法。
【請求項１６】
前記少なくとも１つの管理される装置がプライベートネットワークに結合されている場合、前記管理構成要素は前記少なくとも１つの管理される装置の前記マネージャに適用される、請求項１４に記載の方法。
【請求項１７】
前記マネージャが前記少なくとも１つの利用可能な更新版に適用されるよう適合されている場合、前記管理構成要素は前記少なくとも１つの管理される装置の前記マネージャに適用される、請求項１４に記載の方法。
【請求項１８】
前記マネージャは、前記少なくとも１つの利用可能な更新版を前記受信する行為、前記判断する行為、および前記ダウンロードして適用する行為を実行するよう適合されている、請求項１４に記載の方法。
【請求項１９】
ソフトウェア構成要素を更新するためのシステムであって、
複数の利用可能な更新版を格納するよう設定された更新サーバと、
複数の装置を管理するよう適合された二次サーバとを含み、前記二次サーバは、前記複数の利用可能な更新版のいずれか１つが前記複数の装置の少なくとも１つに適用されるべきかどうかを判断し、適用されるべきである場合、前記複数の更新版の少なくとも１つを前記複数の装置の前記少なくとも１つに適用するよう適合されている、システム。
【請求項２０】
前記複数の更新版の前記少なくとも１つはオペレーティングシステム構成要素と管理構成要素とを含み、前記二次サーバは、前記管理構成要素を前記複数の装置の前記少なくとも１つに適用する前に、前記オペレーティングシステム構成要素を前記複数の装置の前記少なくとも１つに適用するよう適合されている、請求項１９に記載のシステム。
【請求項２１】
前記二次サーバは、少なくとも１つの利用可能な更新版に関連付けられたファイルのファイル名情報を、前記複数の装置の前記少なくとも１つのソフトウェアの現在の部分のフ
ァイル名情報と比較するよう適合されており、かつ、前記比較に基づき、前記複数の装置の前記少なくとも１つが更新されるべきかどうかを判断するよう適合されている、請求項１９に記載のシステム。
【請求項２２】
前記二次サーバは、利用可能な更新版のカタログを前記更新サーバから受信するよう適合されているインターフェイスを含む、請求項１９に記載のシステム。
【請求項２３】
前記二次サーバは、更新版のローカルカタログを格納するためのメモリを含み、前記二次サーバは、更新版の前記受信されたカタログを更新版の前記ローカルカタログと併合するよう適合されている、請求項２２に記載のシステム。
【請求項２４】
前記二次サーバは、前記複数の更新版の前記少なくとも１つに関連付けられたファイルのファイル名情報を、前記複数の装置の前記少なくとも１つに関連付けられたソフトウェアの現在の部分のファイル名情報と比較するよう適合されている、請求項１９に記載のシステム。
【請求項２５】
前記二次サーバは、前記複数の更新版の前記少なくとも１つに関連付けられた少なくとも１つのファイルを、前記複数の装置の前記少なくとも１つにロードするよう適合されている、請求項１９に記載の方法。
【請求項２６】
前記二次サーバは、前記比較に基づき、前記複数の装置の前記少なくとも１つが更新されるべきかどうかを判断するよう適合されている、請求項２４に記載のシステム。
【請求項２７】
前記複数の管理される装置は各々、無停電電源（ＵＰＳ）システムの構成要素であり、前記二次サーバは、前記ＵＰＳシステムの１つ以上の選択された構成要素に前記少なくとも１つの更新版を適用するよう適合されている、請求項１９に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
この発明はソフトウェアのインストールに関し、より特定的にはソフトウェアプログラムを更新するための方法に関する。
【背景技術】
【０００２】
背景
ＰＣなどの汎用コンピュータ上で実行されるソフトウェアプログラムを更新するための従来の方法は数多くある。より特定的には、アプリケーションプログラムおよびオペレーティングシステムプログラムの中には、そのアプリケーションプログラムまたはオペレーティングシステムプログラムの更新版（たとえばより新しいバージョン）が利用可能かどうかを判断し、（たとえばインターネットなどの通信ネットワークを通して）その更新版をダウンロードし、現在インストールされているプログラムにその更新版を適用するための機能を含むものもある。たとえば、マイクロソフト・ウィンドウズ（登録商標）ＸＰ（Microsoft Windows XP）オペレーティングシステム（ワシントン（ＷＡ）州レッドモンド（Redmond）のマイクロソフト社（Microsoft Corporation）から入手可能）は、インターネットブラウザプログラムで実行中のプログラムが、パーソナルコンピュータにインストールされた特定のウィンドウズ（登録商標）ＸＰオペレーティングシステムの構成要素を判断できるようにする、「ウィンドウズ（登録商標）アップデート」（Windows Update）と呼ばれる機能を含んでいる。
【０００３】
このプログラムは、ある特定のインターネットサイトがアクセスされると（http://windowsupdate.microsoft.com）ブラウザプログラム（たとえばマイクロソフト・エクスプローラ（Microsoft Explorer）ブラウザプログラム）でロードおよび実行され、ローカルＰＣのオペレーティングシステムに関する設定情報が、インターネット上に位置する更新サーバに送信される。更新版が利用可能である場合、利用可能な更新版のリストがブラウザにおいてユーザに返送される。これらの利用可能な更新版は、現在のＰＣのソフトウェア設定に適用可能な更新版を反映している。更新版のうちの１つ以上を適用し、更新されたソフトウェアをＰＣにインストールする更新プロセスを開始する選択肢が、ユーザに提示される。しかしながら、更新版はブラウザプログラムが動作中のＰＣに限定されており、ウィンドウズ（登録商標）アップデートプログラムは、更新版を適用するかどうかを判断するためにユーザの介入を必要とする。
【０００４】
ソフトウェアを更新するためのシステムは他にもある。たとえば、マイクロソフト・インターネット・エクスプローラ（Microsoft Internet Explorer）ブラウザアプリケーションといったアプリケーションは、利用可能な更新版があるかどうかを判断するために、更新サーバに定期的に接触している。この接触は、インターネット・エクスプローラプログラムにおいて設定オプションを選択することによって自動的に、または指定されたウェブサイトで更新版のサーチを手動で行なうことによって、実行可能である。しかしながら、実際の更新版のインストールは、ユーザが、自分が更新版をインストールしたいかどうかを選択して、更新版に関するさまざまな局面を設定することを必要とする。いずれにせよ、更新版は、上述のようなウィンドウズ（登録商標）更新プログラムと同様のユーザ介入を必要とする。利用可能なソフトウェア更新版についてチェックし、プログラムを更新するための同様の能力を含むアプリケーションプログラムは、他にも数多くある（たとえば、ワシントン（Washington）州シアトル（Seattle）のリアルネットワークス社（Real Networks, Inc.）から入手可能なリアル・ワン（Real One）メディア・プレーヤ・プログラム、およびマイクロソフト・ウィンドウズ（登録商標）メディア・プレーヤ（Microsof
t Windows Media Player）プログラムなど）。
【０００５】
ソフトウェアを多数のＰＣに配布するためにアドミニストレータによって使用可能なソフトウェアツールのタイプは他にもあり、たとえば、マイクロソフト社から入手可能なマイクロソフトシステム管理サーバ（Microsoft Systems Management Server）ソフトウェアプログラムがある。しかしながら、これらのツールも、セットするのにある程度の訓練を必要とし、手動の介入を必要とする。なぜなら、アドミニストレータは、どのソフトウェアアプリケーションを選択されたＰＣに配布するかを手動で選択しなければならないためである。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
概要
現在利用可能な更新システムおよび手順の欠点は数多くある。大抵の従来のシステムおよび手順は、更新プロセス中にユーザの介入を必要とするＰＣ用に設計されている。より特定的には、大抵の更新プロセスは、更新版をダウンロードして適用するためにユーザがさらに措置を講じる必要があるウェブサイトに、ＰＣブラウザインターフェイスを向けている。この発明の一局面によれば、ユーザの介入を必要とせずにシステムのソフトウェアを自動的に更新することが有利な場合がある。さらに、ネットワーキング装置、無停電電源（ＵＰＳ）、または他のシステムといった非ＰＣシステム上でソフトウェアの更新版を実行可能なシステムを有することが望ましい場合がある。
【０００７】
さらに、従来のソフトウェア更新システムおよび手順は一般に、単一のシステムをチェックして更新するために設計されている。この発明の一局面では、あるシステムが更新サーバからソフトウェアの更新版を受信し、それら更新版を１つ以上のシステムに適用することが、有益な場合がある。このように、そのシステムが多数のシステムに対して更新プロセスを集約的に管理し、実行する場合がある。これは、以下を含む多くの理由で有益である:
・ソフトウェアの更新を実行するのにアドミニストレータが各システムに出向くことを求める更新が、各システムにおいて行なわれる必要がない。更新は、単一のシステムから多数のシステムに対して実行され得る
・更新版は多数のシステムに対して自動的に適用可能であり、アドミニストレータの代わりにユーザの介入を必要としない
・更新版は単一のシステム上でより容易に管理されてもよい。従来、アドミニストレータは、更新版が適正に適用されたことを判断するために、各システムを検査しなければならない
・プロキシサーバが、利用可能な更新版をダウンロードしてそれらを他のシステムに配布することができる場合、更新サーバへの接触回数が少なくなる（このため、更新サーバはより頻繁に利用可能となる）。
【０００８】
この発明の別の局面では、ある単一のシステムがソフトウェア更新版を受信して適用する責任を担うことが有益な場合がある、ということが実現される。別の局面では、この単一のシステムが、更新サーバとは通信できないシステムを更新する場合がある。たとえば、更新されるべきシステムは、更新サーバから更新版をダウンロードして適用するためのインターフェイスまたは適切な制御および／またはプロトコルを持っていないネットワーク装置であるかもしれない。一般に、ネットワーク装置は、更新サーバと相互作用するユーザインターフェイスおよび他の機器インターフェイスを含んでいない。したがって、更新されるべきシステムに代わって更新版を検索し、その更新版をシステムに適用することができるプロキシシステムが提供される。このプロキシシステムは、たとえば、どのシステムがソフトウェア更新版を受信するか、それらはいつそれらを受信するか、および更新
プロセスの他の局面を制御してもよい。
【０００９】
この発明の別の局面によれば、更新版のカタログが更新サーバからダウンロードされ、サーバは、どの更新版を特定のシステムに適用する必要があるかを判断する。更新サーバにバージョン情報および他のシステム情報を送信する従来の更新方法の代わりに、更新版のカタログがダウンロードされるため、更新版はより安全に適用される。なぜなら、ユーザの機器および設定に関する情報は更新サーバに送信されないためである。
【００１０】
一実施例では、更新版のカタログは定期的にダウンロードされ、プロキシサーバは、１つ以上の利用可能な更新版を識別する情報を、１つ以上の管理されるシステムを識別する情報と比較する。ある更新版がある特定のシステムに整合する場合、その更新版はそのシステムに適用されてもよい。プロキシサーバはまた、それ自体のソフトウェアを更新することができてもよい。
【課題を解決するための手段】
【００１１】
この発明の一局面によれば、ソフトウェアを更新するための方法が提供される。この方法は、更新サーバを提供する行為を含み、更新サーバは１つ以上のソフトウェア更新版を格納するよう適合されており、この方法は、更新サーバから利用可能な更新版のカタログを、更新サーバから受信する行為と、少なくとも１つの利用可能な更新版が、少なくとも１つの管理される装置に当てはまるかどうかを判断する行為と、当てはまる場合、少なくとも１つの利用可能な更新版をダウンロードして、少なくとも１つの利用可能な更新版を少なくとも１つの管理される装置に適用する行為とを含む。
【００１２】
この発明の一局面によれば、更新サーバを含むシステムにおいてソフトウェアを更新するための方法が提供され、更新サーバは１つ以上のソフトウェア更新版を格納するよう適合されている。この方法は、更新サーバから利用可能な更新版のカタログを、更新サーバから受信する行為と、更新版のカタログに参照される少なくとも１つの利用可能な更新版が、少なくとも１つの管理される装置に当てはまるかどうかを判断する行為と、当てはまる場合、少なくとも１つの利用可能な更新版をダウンロードして、少なくとも１つの利用可能な更新版を少なくとも１つの管理される装置に適用する行為とを含む。
【００１３】
この発明の一実施例によれば、この方法は、更新版のローカルカタログを保持する行為と、更新版の受信されたカタログを更新版のローカルカタログと併合する行為とをさらに含む。別の実施例によれば、少なくとも１つの利用可能な更新版はオペレーティングシステム構成要素と管理構成要素とを含み、少なくとも１つの利用可能な更新版を適用する行為は、管理構成要素を少なくとも１つの管理される装置に適用する前に、オペレーティングシステム構成要素を少なくとも１つの管理される装置に適用する行為をさらに含む。
【００１４】
別の実施例によれば、受信する行為、判断する行為、およびダウンロードして適用する行為は、二次サーバによって各々実行される。別の実施例によれば、判断する行為は、少なくとも１つの利用可能な更新版に関連付けられたファイルのファイル名情報を、少なくとも１つの管理される装置に関連付けられたソフトウェアの現在の部分のファイル名情報と比較する行為を含む。別の実施例によれば、この方法は、少なくとも１つの管理される装置に少なくとも１つのファイルを送信する行為をさらに含む。
【００１５】
この発明の一実施例によれば、この方法は、少なくとも１つの利用可能な更新版に関連付けられた少なくとも１つのファイルが壊れていないことを検証する行為をさらに含み、検証する行為は適用する行為の前に実行される。別の実施例によれば、検証する行為および適用する行為は、二次サーバによって各々実行される。別の実施例によれば、二次サーバは、複数の管理される装置のために、１つ以上の更新版を実行する。
【００１６】
別の実施例によれば、複数の管理される装置は各々、無停電電源（ＵＰＳ）システムの構成要素であり、二次サーバは１つ以上の更新版をＵＰＳシステムの選択された構成要素に適用する。さらに別の実施例によれば、この方法は、更新サーバ上に更新版が存在するかどうかを複数の装置の代わりに判断する行為をさらに含む。
【００１７】
別の実施例によれば、少なくとも１つの利用可能な更新版に関連付けられたファイルのファイル名情報を、少なくとも１つの管理される装置のソフトウェアの現在の部分へのファイル名情報と比較する行為は、少なくとも１つの利用可能な更新版に関連付けられたファイルの改訂レベル情報を、少なくとも１つの管理される装置のソフトウェアの現在の部分の更新レベル情報と比較して、比較に基づき、少なくとも１つの管理される装置が更新されるべきかどうかを判断する行為を含む。別の実施例によれば、この方法は、少なくとも１つの利用可能な更新版の改訂レベルが、少なくとも１つの管理される装置のソフトウェアの現在の部分へのファイル名情報への少なくとも１つの利用可能な更新版に関連付けられた改訂レベルファイルと比較して、ソフトウェアのより最近の改訂版であるかどうかを判断する行為をさらに含む。
【００１８】
別の実施例によれば、少なくとも１つの利用可能な更新版はオペレーティングシステム構成要素と管理構成要素とを含み、少なくとも１つの利用可能な更新版を適用する行為は、オペレーティングシステム構成要素を少なくとも１つの管理される装置に適用し、管理構成要素を、少なくとも１つの管理される装置と少なくとも１つの管理される装置のマネージャとの少なくとも一方に適用する行為をさらに含む。別の実施例によれば、少なくとも１つの管理される装置がパブリックネットワークに結合されている場合、管理構成要素は少なくとも１つの管理される装置に適用される。別の実施例によれば、少なくとも１つの管理される装置がプライベートネットワークに結合されている場合、管理構成要素は少なくとも１つの管理される装置のマネージャに適用される。別の実施例によれば、マネージャが少なくとも１つの利用可能な更新版に適用されるよう適合されている場合、管理構成要素は少なくとも１つの管理される装置のマネージャに適用される。別の実施例によれば、マネージャは、少なくとも１つの利用可能な更新版を受信する行為、判断する行為、およびダウンロードして適用する行為を実行するよう適合されている。
【００１９】
この発明の別の局面によれば、ソフトウェア構成要素を更新するためのシステムが提供される。このシステムは、複数の利用可能な更新版を格納するよう設定された更新サーバと、複数の装置を管理するよう適合された二次サーバとを含み、二次サーバは、複数の利用可能な更新版のいずれか１つが複数の装置の少なくとも１つに適用されるべきかどうかを判断し、適用されるべきである場合、複数の更新版の少なくとも１つを複数の装置の少なくとも１つに適用するよう適合されている。この発明の一実施例によれば、複数の更新版の少なくとも１つはオペレーティングシステム構成要素と管理構成要素とを含み、二次サーバは、管理構成要素を複数の装置の少なくとも１つに適用する前に、オペレーティングシステム構成要素を複数の装置の少なくとも１つに適用するよう適合されている。
【００２０】
別の実施例によれば、二次サーバは、少なくとも１つの利用可能な更新版に関連付けられたファイルのファイル名情報を、複数の装置の少なくとも１つのソフトウェアの現在の部分のファイル名情報と比較するよう適合されており、かつ、比較に基づき、複数の装置の少なくとも１つが更新されるべきかどうかを判断するよう適合されている。別の実施例によれば、二次サーバは、利用可能な更新版のカタログを更新サーバから受信するよう適合されているインターフェイスを含む。
【００２１】
別の実施例によれば、二次サーバは、更新版のローカルカタログを格納するためのメモリを含み、二次サーバは、更新版の受信されたカタログを更新版のローカルカタログと併
合するよう適合されている。別の実施例によれば、二次サーバは、複数の更新版の少なくとも１つに関連付けられたファイルのファイル名情報を、複数の装置の少なくとも１つに関連付けられたソフトウェアの現在の部分のファイル名情報と比較するよう適合されている。別の実施例によれば、二次サーバは、複数の更新版の少なくとも１つに関連付けられた少なくとも１つのファイルを、複数の装置の少なくとも１つにロードするよう適合されている。別の実施例によれば、二次サーバは、比較に基づき、複数の装置の少なくとも１つが更新されるべきかどうかを判断するよう適合されている。別の実施例によれば、複数の管理される装置は各々、無停電電源（ＵＰＳ）システムの構成要素であり、二次サーバは、ＵＰＳシステムの１つ以上の選択された構成要素に少なくとも１つの更新版を適用するよう適合されている。
【発明を実施するための最良の形態】
【００２２】
この発明のさらに別の特徴および利点、ならびにこの発明のさまざまな実施例の構造および動作を、以下に添付図面を参照して詳細に説明する。図中、同じ参照番号は、同じまたは機能的に同様の要素を示す。加えて、参照番号の左から１桁または２桁は、参照番号が最初に現れる図面を識別している。
【００２３】
この発明は、添付の特許請求の範囲において詳細に指摘される。この発明の上述の、およびさらに別の利点は、以下の説明を添付図面とともに参照することによってより良く理解されるであろう。図中、同様の参照番号は、同じまたは同様の要素を示す。
【００２４】
詳細な説明
図１は、この発明の一実施例に従った、ソフトウェアプログラムを更新するためのシステムのブロック図を示す。システム１００は、システム１０３Ａ〜１０３Ｃに適用されるべき１つ以上のソフトウェア更新版を格納する更新サーバ１０１を含む。更新サーバ１０１は、通信ネットワークを介して他のシステムに通信する。たとえば、更新サーバ１０１は、１つ以上のパブリックまたはプライベートネットワークを介してアクセスされるインターネットサーバであってもよい。たとえば、更新サーバ１０１は、ＴＣＰ／ＩＰといった１つ以上のネットワークプロトコルを用いてソフトウェアプログラムを配信可能な従来のウェブサーバであってもよい。さらに、サーバ１０１は、ＨＴＴＰ、ＦＴＰ、または他のプロトコルといった１つ以上のアプリケーションレベルプロトコルを用いてファイルを提供可能であってもよい。
【００２５】
システム１００は、リンク１０４を介して更新サーバ１０１と通信するよう適合されているサーバ１０２も含む。リンク１０４は、たとえば、サーバ１０２を更新サーバ１０１に結合する１つ以上のネットワーク、構成要素、および／または媒体であってもよい。一実施例では、サーバ１０２は企業ネットワーク内に配置され、更新サーバ１０１はインターネットに配置されたウェブサーバである。サーバ１０２は、ソフトウェア更新版が利用可能かどうかを判断するために更新サーバ１０１と通信することができる。利用可能である場合、サーバ１０２は、どのタイプの更新版が利用可能かを示す更新サーバ１０１からの情報を取得し、サーバ１０２は、１つ以上の関連付けられたシステム（たとえばシステム１０３Ａ〜１０３Ｃ）に関する情報に基づいて、サーバ１０１の１つ以上のソフトウェア更新版がシステム１０３Ａ〜１０３Ｃに適用されるかどうかを判断する。適用される場合、サーバ１０２は、適切なプロトコル（たとえばＨＴＴＰ）を用いて更新サーバ１０１から１つ以上の適用可能な更新版をダウンロードし、そのような更新版をシステム１０３Ａ〜１０３Ｃに適宜適用してもよい。
【００２６】
サーバ１０２は、１つ以上のネットワークリンク１０５によってシステム１０３Ａ〜１０３Ｃに結合されてもよい。リンク１０５は、サーバ１０２からシステム１０３Ａ〜１０３Ｃに情報を通信するために使用される１つ以上のネットワーク、構成要素、または媒体
を含んでいてもよい。たとえば、リンクは、イーサネット（登録商標）または他のどのタイプのネットワーク接続および／またはアクティブになっている機器を含んでいてもよい。サーバ１０２は、たとえば、図２に関して以下により詳細に説明されるような汎用コンピュータシステムであってもよい。システム１０３Ａ〜１０３Ｃは、たとえば、サーバ１０２によって管理されるシステムであってもよい。サーバ１０２は、ハードウェア（たとえば物理的なサーバシステム）およびソフトウェア（たとえばサーバ１０２に対してローカルに実行されるもの、および、アドミニストレータによって遠隔クライアント上で実行される関連付けられた管理ソフトウェアアプリケーション）を含んでいてもよい。
【００２７】
この発明の一局面によれば、サーバ１０２は、システム１０３Ａ〜１０３Ｃのためにソフトウェア製品更新サービスを行なう。システム１０３Ａ〜１０３Ｃは、たとえば、ＵＰＳシステムの装置であってもよい。これらのＵＰＳシステム装置は、たとえば、環境監視ユニット、ＵＰＳシステムプロセッサ構成要素、バッテリ、空調構成要素、または他のシステム、装置、もしくは構成要素を含む、ＵＰＳのサブシステム構成要素であってもよい。
【００２８】
一実施例では、サーバ１０２は、システム１０３Ａ〜１０３Ｃと通信するための１つ以上のハードウェアプロトコルおよび／またはソフトウェアプロトコルを含んでいてもよい。一例では、システム１０３Ａは、性能および設定データをネットワーク管理システムに提供するネットワーク管理モジュールを含む。一例では、このネットワーク管理モジュールは、周知の簡易ネットワーク管理プロトコル（ＳＮＭＰ）を用いて管理可能である。このネットワーク管理モジュールはまた、ウェブベースのインターフェイスを用いて監視されてもよい。そのようなウェブベースのインターフェイスは、ＨＴＴＰプロトコルを用いてネットワークを介してブラウザプログラムにダウンロードされるソフトウェアによって提供されてもよい。サーバ１０２は、１つ以上の通信プロトコルを用いてシステム１０３Ａ〜１０３Ｃを制御し、監視するよう適合されていてもよく、この発明が特定のタイプのプロトコルに限定されないことが理解されるべきである。
【００２９】
汎用コンピュータシステム
この発明の一実施例に従ったサーバシステム２０１は、たとえば、１つ以上のコンピュータシステム上で実現されてもよい。これらのコンピュータシステムは、たとえば、インテルペンティアム（登録商標）（Intel PENTIUM）タイプのプロセッサに基づいたものといった汎用コンピュータ、特殊用途プロセッサ（たとえば、ビアテクノロジーズ社（Via Technologies, Inc.）から入手可能なＣ３プロセッサ）、または他のどのタイプのプロセッサであってもよい。この発明のさまざまな実施例に従ってソフトウェア更新版を受信し、配布するために、１つ以上のどのタイプのコンピュータシステムが使用されてもよいことが理解されるべきである。さらに、システムは単一のコンピュータ上に配置されてもよく、または、通信ネットワークによって接続された複数のコンピュータ間で分散されてもよい。
【００３０】
この発明の一実施例に従った汎用コンピュータシステムは、１つ以上の他のシステムに関連付けられたソフトウェアプログラムを更新するよう設定されている。このシステムがそれ自体のソフトウェアを更新することを含む他の機能を実行してもよいこと、または他のどの機能を実行してもよいことが理解されるべきであり、この発明は特定の機能または１組の機能を実行することに限定されない。たとえば、このシステムは、たとえばネットワーク管理システムといった既存の市販製品において実現されてもよい。他の実現化例も可能であり、この発明は特定の実現化例に限定されない。
【００３１】
たとえば、この発明のさまざまな局面は、図２に示すものなどの汎用コンピュータシステム２０１において実行中の特殊ソフトウェアとして実現されてもよい。コンピュータシ
ステム２０１は、ディスクドライブ、メモリ、またはデータを格納するための他の装置といった１つ以上のメモリ装置２０３に接続されたプロセッサ２０２を含んでいてもよい。メモリ２０３は通常、コンピュータシステム２０１の動作中にプログラムおよびデータを格納するために使用される。コンピュータシステム２０１内の装置は通信装置またはシステム２０５によって結合されてもよく、それは、たとえば、システム２０１内でデータを通信する１つ以上の通信要素（たとえばバス、ブリッジ、ルータなど）を含んでいてもよい。コンピュータシステム２０１はまた、キーボード、マウス、または印刷装置といった１つ以上の入力／出力装置２０７も含む。加えて、コンピュータシステム２０１は、コンピュータシステム２０１を１つ以上の通信ネットワーク（たとえばネットワーク２０８）に接続する１つ以上の通信装置２０４を含んでいてもよい。この発明の一実施例では、システム２０１は、パブリックネットワークまたはプライベートネットワークのいずれかに配置された装置のソフトウェアを更新する責任を担っており、したがって、このシステムは２つのネットワークインターフェイスを有する。一方はプライベートネットワークに結合され、一方はパブリックネットワークに結合されている。
【００３２】
一実施例では、この発明のさまざまな局面は、ロードアイランド（ＲＩ）州ウエストキングストン（West Kingston）のアメリカン  パワー  コンバージョン  コーポレイション（American Power Conversion Corporation：ＡＰＣ）から入手可能なインフラストラクチャ・マネージャ（InfraStrucXure Manager）サーバアプライアンス製品において実現されてもよい。このインフラストラクチャ・マネージャ製品は、ＡＰＣ装置のウェブブラウザベースの遠隔管理を提供する。
【００３３】
この発明のさまざまな局面が実践され得るコンピュータシステムの一種としてコンピュータシステム２０１が例示されているが、この発明が、図２に示すようなコンピュータシステム上で実現されるよう限定されてはいないことが理解されるべきである。この発明のさまざまな局面は、図２に示すものとは異なるアーキテクチャまたは構成要素を有する１つ以上のコンピュータ上で実践されてもよい。
【００３４】
コンピュータシステム２０１は、高レベルのコンピュータプログラミング言語を用いてプログラム可能な汎用コンピュータシステムであってもよい。コンピュータシステム２０１はまた、特別にプログラムされた特殊用途ハードウェアを用いて実現されてもよい。コンピュータシステム２０１では、プロセッサ２０２は通常、インテル社（Intel Corporation）から入手可能な周知のペンティアム（登録商標）クラスのプロセッサといった、商業的に入手可能なプロセッサである。多くの他のプロセッサが利用可能である。また、これに代えて、この発明のさまざまな局面は、（特殊用途プロセッサおよびメモリを有する）特殊用途コンピューティングシステム上で実現されてもよい。そのようなプロセッサは通常、たとえば、マイクロソフト社から入手可能なウィンドウズ（登録商標）ＣＥ（Windows CE）、ウィンドウズ（登録商標）ＮＴ（Windows NT）、ウィンドウズ（登録商標）サーバ２ＸＸＸ（Windows Server 2XXX）、ウィンドウズ（登録商標）２０００（Windows 2000）（ウィンドウズ（登録商標）ＭＥ（Windows ME））、またはウィンドウズ（登録商標）ＸＰオペレーティングシステム、もしくは、さまざまなソース（たとえばリナックス（登録商標）（Linux））から入手可能なＵＮＩＸ（登録商標）ベースのオペレーティングシステムであってもよいオペレーティングシステムを作動させる。多くの他のオペレーティングシステムが使用されてもよく、この発明は特定の実現化例に限定されない。
【００３５】
この発明のさまざまな実施例に従ってソフトウェア更新版を適用する二次サーバの例示的なハードウェア設定は、以下の構成要素を含む：
プロセッサ：ビアＣ３＠８００ＭＨｚ
ランダム・アクセス・メモリ  ２５６ＭＢ  ＰＣ１３３
ネットワークインターフェイスカード  リアルテック（RealTec）ＲＴＬ８１３９Ｃ  
２個（１つはパブリックネットワークに結合され、１つはプライベートネットワークに結合される）
シリアルポート  ＲＳ−２３２  １個、ＲＳ−４８５  １個
ユニバーサル・シリアル・バス  ２  ＵＳＢ１．１
ハードディスクドライブ  ４０ＧＢ  ５４００ＲＰＭ  ＩＤＥ
ハードウェア  ウォッチドッグ（HW WatchDog）  １〜２５５秒／１秒単位。
【００３６】
この発明のさまざまな実施例は、スモールトーク（SmallTalk）、Ｊａｖａ（登録商標）、Ｃ＋＋、エイダ（Ada）、またはＣ♯（Ｃ−シャープ）といったオブジェクト指向プログラミング言語を用いてプログラムされてもよい。他のオブジェクト指向プログラミング言語も使用されてもよい。また、これに代えて、関数プログラミング言語、スクリプトプログラミング言語、および／または論理プログラミング言語が使用されてもよい。この発明のさまざまな局面は、プログラムによらない環境で実現されてもよい（たとえば、ブラウザプログラムのウインドウに表示された場合に、グラフィカルユーザインターフェイス（ＧＵＩ）の局面を与えるか、または他の機能を実行する、ＨＴＭＬ、ＸＭＬまたは他のフォーマットで作成された文書）。この発明のさまざまな局面は、プログラムによる要素、またはプログラムによらない要素、もしくはそれらのいずれかの組合せとして実現されてもよい。
【００３７】
この発明がある特定のコンピュータシステムプラットホーム、プロセッサ、オペレーティングシステム、またはネットワークに限定されないことが理解されるべきである。また、この発明が特定されたプログラミング言語またはコンピュータシステムに限定されないことは、当業者には明らかなはずである。さらに、他の適切なプログラミング言語および他の適切なコンピュータシステムも使用可能であることが理解されるべきである。
【００３８】
このシステムの１つ以上の部分が、通信ネットワーク２０８に結合された１つ以上のコンピュータ（たとえばシステム２０９〜２１０）に分散されてもよい。これらのコンピュータシステム２０９〜２１０も、汎用のコンピュータシステム（たとえばシステム２０１に関連して機能する管理プログラムを実行するクライアントコンピュータ）であってもよい。たとえば、この発明のさまざまな局面は、１つ以上のクライアントコンピュータにサービスを提供するよう設定された（たとえばサーバ）、または分散型システムの一部としてタスク全体を実行するよう設定された１つ以上のコンピュータシステム間で分散されてもよい。たとえば、この発明のさまざまな局面は、この発明のさまざまな実施例に従ってさまざまな機能を実行する１つ以上のサーバシステム間で分散される構成要素を含むクライアント−サーバシステム上で実行されてもよい。これらの構成要素は、通信プロトコル（たとえばＴＣＰ／ＩＰ）を用いて通信ネットワーク（たとえばインターネット）を通して通信する実行可能コード、中間コード（たとえばＩＬ）または解釈コード（たとえばＪａｖａ（登録商標））であってもよい。
【００３９】
この発明が特定のシステムまたは一群のシステム上で実行されるよう限定されないことが理解されるべきである。また、この発明が特定の分散型アーキテクチャ、ネットワーク、または通信プロトコルに限定されないことも理解されるべきである。
【００４０】
この発明の一実施例に従った、ソフトウェアを更新するための１プロセスを、図３に示す。ブロック３０１で、プロセス３００が始まる。ブロック３０２で、システム（たとえばサーバ１０２）は、ファームウェア、アプリケーションソフトウェア、およびソフトウェア（たとえばアプリケーション、ＯＳ、または双方）の更新版が利用可能かどうか判断可能であってもよい。更新サーバ（たとえば更新サーバ１０１）は、更新版についてチェックを受けている各製品タイプについての利用可能な更新版の「カタログ」を返送するよう設定されていてもよい。このチェックは、たとえば、１つ以上のシステム（たとえばシ
ステム１０３Ａ〜１０３Ｃ）に更新版を適用する責任を担っているサーバ上で実行中のソフトウェアによって行なわれてもよい。
【００４１】
ブロック３０２で、システム（たとえば更新版を適用するシステム）は、１つ以上の更新版が利用可能かどうかを判断する。たとえば、ソフトウェアプログラムは、ある特定の更新版がある管理されたシステムに関しているかどうかを判断するよう設定されていてもよい。たとえば、ソフトウェアプログラムは、それ自体の製品バージョン、およびそれが管理しているソフトウェア製品（またはエンティティ）の１つ以上についての製品バージョンを、カタログと比較してもよい。（たとえばブロック３０３で）そのサーバが管理している製品のいずれかについての更新版があると判断された場合、（たとえばブロック３０４で）サーバはその更新版をダウンロードし、ユーザにその利用可能性を通知することができる。利用可能な更新版がないと判断された場合、システムは待機モードで作動してもよく、または管理されるシステムに関する他の管理機能を行なってもよい。
【００４２】
サーバはまた、ブロック３０４で、更新版を配布し、更新版を１つ以上の遠隔システムに適用するよう設定されてもよい。製品ソフトウェアタイプを一意的に定義するための、かつ更新版がいつ利用可能かを比較して判断するための機能もあってもよい。ブロック３０６で、プロセス３００が終了する。さらに、一実施例によれば、更新版を適用する責任を担うシステムは、定期的に修正されるハードウェア設定を有するモジュラーシステムの一部であってもよい。このため、サーバは、そのモジュラーシステムの構成要素のいずれかを更新する必要があるかどうかを判断するために、それらの構成要素を評価してもよい。たとえば、このシステムは、コンピュータおよび他のシステム負荷にバックアップ電力を提供するモジュール方式の無停電電源（ＵＰＳ）システムの一部であってもよい。
【００４３】
図４Ａ〜４Ｂは、ソフトウェアプログラムを更新するためのプロセス４００を示す。ブロック４０１で、プロセス４００は始まる。ブロック４０２で、サーバ上で実行中のソフトウェアプログラムが、利用可能な更新版のカタログ（たとえば、カードまたはモジュールファームウェア、管理、アプリケーションおよびオペレーティングシステムソフトウェア用プラグインプログラム）を更新サーバからダウンロードするよう設定される。一実施例では、更新サーバは、インターネットなどのパブリックネットワークを介してサーバに結合される。更新サーバは、既に消費者に流通している製品内のソフトウェアおよびファームウェアを更新するために、構成要素またはシステム製造業者（たとえばロードアイランド州ウエストキングストンのアメリカン  パワー  コンバージョン  コーポレイション）によってネットワーク上に配置されてもよい。このように、消費者は、製品を製造業者に返却したりまたは製品をすっかり取り替えたりする必要なく、たとえばエラー修正に対処し、新機能を提供するなどといった新しいソフトウェアバージョンを受取ることができる。
【００４４】
ブロック４０３で、ソフトウェアプログラムは、更新サーバからダウンロードされた利用可能な更新版のカタログを、現在のカタログと併合する（それが存在する場合）。既存のカタログが存在しない場合、それは、管理される装置の各々から取得される情報から構築されてもよい。たとえば、ブロック４０４で、ソフトウェアプログラムが、実行される際に、管理される装置の各々の上で実行中のソフトウェアのソフトウェアバージョンを検査してもよい。そのような検査は、サーバと管理される装置のうちの１つ以上との間のいずれかの通信プロトコルを用いて行なわれてもよい。ブロック４０５で、プログラムは、管理される装置の各々のためのソフトウェアに関する情報（たとえばソフトウェアバージョニング情報）をデータベースに格納する。この情報は、管理される装置に関する情報のカタログを作成するために使用されてもよい。
【００４５】
ブロック４０６で、サーバソフトウェアは、それが管理しているエンティティのソフト
ウェアバージョンをカタログの情報と比較し、その比較に基づいて、更新版が利用可能かどうかを判断する。
【００４６】
別の実施例では、サーバソフトウェアは、サーバソフトウェアが管理している装置のいずれかが利用可能な更新版を有する場合に、（たとえばグラフィカルユーザインターフェイス、Ｅメールなどで）ユーザに通知するよう設定される。この発明の一局面では、サーバソフトウェアは、遠隔装置／システムでの更新版のインストールを容易にし、更新される装置／システムを識別するステータス報告を（たとえばユーザに）提供する。ブロック４０７で、サーバソフトウェアは、利用可能な更新版のいずれかが管理される装置のいずれかに適用されるべきかどうかを判断する。更新版のいずれかが管理システムのいずれかに適用されるべきであると判断された場合、ブロック４０８で、ソフトウェアプログラムは、適用されるべき更新版を管理される装置にダウンロードしてもよい。一実施例では、ダウンロードされる更新版は、更新される必要がある管理される装置に関するものだけである。
【００４７】
ソフトウェアプログラムは、更新版の１つ以上のファイルを管理される装置に適用する前に、ブロック４０９でそれらのファイルの妥当性をオプションとして検査してもよい。この機能は、たとえば、ファイル（または複数のファイル）の１つ以上の部分のチェックサムを、ファイル（または１組のファイル）内に配置されたチェックサムと比較して判断することによって、行なわれてもよい。他の検証方法が行なわれてもよい。
【００４８】
ブロック４１０で、ソフトウェアプログラムは、適用可能な管理される装置に１つ以上のファイルをロードする。そのようなロードは、たとえば、１つ以上のファイル転送プロトコル（たとえばＴＦＴＰ、ＦＴＰなど）またはプログラムを装置にロードするための任意の他の方法を用いて行なわれてもよい。ブロック４１１で、管理装置は、（たとえばブロック４１１で）更新版が実施されるよう、リセットまたは再始動される必要があってもよい。状況に応じて、ソフトウェアプログラムはブロック４１２で、更新版のうちの１つ以上が成功していたことを検証してもよい。そのような検証は、たとえば、装置が適正に作動していることを示す管理装置上の１つ以上の機能（たとえばステータス問合せ）または他の動作を行なうことによって、実行されてもよい。ブロック４１３で、プロセス４００は終了する。
【００４９】
例示的な１システムでは、利用可能な更新版についての情報を保持する更新サーバが存在する。この更新サーバは、インターネットおよび／または他のネットワークを介して二次サーバに結合されてもよい。別の実施例では、更新サーバは、フィールドにおけるソフトウェア構成要素から（たとえば二次サーバから）要求を聴取するよう設定され、利用可能な更新版についての情報を含む応答を請求するよう設定される。この更新サーバは、たとえば、機器および／またはソフトウェア製造業者によって維持されてもよく、更新サーバは、（たとえば製造業者によって）新たにリリースされたソフトウェアが利用可能となった際に更新され得る。
【００５０】
一実施例では、二次サーバは、顧客のネットワーク上の多数の装置に管理を提供してもよい。たとえば、二次サーバは、図２に関して上述したようなネットワーク管理プロトコルを用いて装置／システムを管理してもよい。これらさまざまな装置の管理の一部として、サーバは、（たとえばＳＮＭＰといったネットワーク管理プロトコルを用いて装置をポーリングすることによって）装置上で実行中のソフトウェア／ファームウェアのバージョンを取得する能力を有する。二次サーバソフトウェアは、利用可能な更新版について更新サーバに問合せる更新構成要素を提供する。
【００５１】
利用可能な更新版を識別する情報を受取ると、更新構成要素は、それが認識しているソ
フトウェア／ファームウェアのバージョンと、更新サーバから取得されたバージョンとを突き合わせてチェックする。そのようなチェックは、たとえば、現在システムにインストールされているソフトウェアを識別するファイル名情報を、ある特定の更新版に関連付けられたファイル名情報と比較することによって行なわれてもよい。いずれかの更新版が利用可能である場合、その更新版は更新サーバから二次サーバにダウンロードされる。その後、それらの利用可能性がユーザに通知されてもよい。ユーザは、フィールドにおける装置に更新版を要望通り配布するために二次サーバを使用してもよい。さらに、二次サーバは、更新版を自動的に受信して適用するよう適合されていてもよい。
【００５２】
二次サーバを有することの１利点は、更新される必要のある各装置が更新のために更新サーバに接触する必要がないことである。また、これに代えて、更新版が利用可能かどうかを判断し、更新サーバから適切なソフトウェアを１度にダウンロードする二次サーバが提供される。従来のソフトウェア配布システムでは、同じソフトウェアが異なるクライアントによって多数回ダウンロードされる。その結果、各クライアントは更新サーバと通信する能力を持たなければならず、より有能なクライアントを必要とする。また、大多数のエンドクライアントにサービスを直接提供する従来の更新サーバには、同じファイルについての要求が多数殺到する場合がある。一実施例によれば、多数の装置用のプロキシとして作用する二次サーバが提供される。
【００５３】
さらに、一実施例によれば、どの装置が実際に更新されるか、およびいつそれらの更新版が生じるかに対する制御が、ユーザに提供される。つまり、装置のダウンロードおよび更新が連続して行なわれる必要はない。すなわち、更新版が一旦ダウンロードされると、それは適用される。むしろ、更新版がダウンロードされてしばらくしてから、予め定められたスケジュールまたは１組の規則に従ってダウンロードが適用されてもよいという点で、更新プロセスはユーザ設定可能であってもよい。ネットワーク装置または他のシステム構成要素の場合、ソフトウェアの更新版は、装置がリセットされることを必要とするかもしれず、したがって、適正な時点で、または適正なシーケンスで更新版を適用する必要があるかもしれない。
【００５４】
さらに、別の実施例によれば、ソフトウェア更新版が利用可能である場合にユーザへの通知が提供される。これは、たとえば、二次サーバによって管理されるある特定の装置に整合する更新版が利用可能である場合に起こり得る。この通知は、たとえば、装置のアドミニストレータへのｅメール、または他の通知を送信することによって行なわれてもよい。これに対し、従来のソフトウェア更新システムは、アプリケーションを使用する場合しかユーザに通知しない。
【００５５】
しかしながら、通常ユーザによって操作されない装置または他のシステム（たとえばＵＰＳシステム）については、従来の装置またはシステムでは、更新版が利用可能である場合を判断するために通知が提供されることはない。したがって、この発明の一局面によれば、アドミニストレータの制御下にある装置および他のシステムに、通知が提供される。
【００５６】
一例では、二次サーバは、装置およびそれらの識別情報（たとえばモデル番号、ファームウェア／ソフトウェア改訂版など）のリストを保持しており、この情報を更新サーバによって提供される情報と比較する。この比較に基づき、更新版が存在すると判断された場合、通知がユーザ（たとえばネットワークアドミニストレータ）に送信され、利用可能な更新版を識別する。更新版が利用可能である場合にユーザに通知することにより、アドミニストレータは、更新版について更新サーバを（たとえばウェブサイトを通して手動で）定期的にチェックしなければならない代わりに、更新版が利用可能である場合にはサーバがアドミニストレータに通知するようにすることによって、「セットして忘れる」ことができる。さらに、新製品を管理するために二次サーバが更新される際、これらの新製品を
サポートするために、これらの製品についてのファームウェア更新メカニズムが自動的に実施される。
【００５７】
要求中のサーバ（たとえば二次サーバ）が評価のために各々別個の管理される構成要素を返送するのではなく、更新サーバが、利用可能な更新版のカタログを要求中のサーバに提供する。一設定例によれば、管理される構成要素が更新サーバに返送されないため、更新サーバに返送される情報の量（ひいては、更新サーバが結合されるネットワーク）が減少する。さらに、フィールド装置およびシステムを更新するために中間サーバが提供されるため、新しい装置およびシステムをサポートするために更新サーバプロトコルを修正する必要性が減少する。
【００５８】
以下の例は、ソフトウェアを更新するためのシステムおよび方法のさまざまな実施例を説明している。この発明はこれらの特定の実施例に限定されず、むしろ、この発明は他の局面から独立した１つ以上の局面を含んでいてもよい。以下は、更新サーバ、二次サーバ、および二次サーバによって管理される装置（たとえばＵＳＰシステム構成要素）を説明している。例では、更新サーバは製品製造業者（たとえばアメリカン  パワー  コンバージョン  コーポレイション（ＡＰＣ）によって維持され、顧客の機器にソフトウェアおよびファームウェア更新版を提供するために利用可能となっている。
【００５９】
例示的なアーキテクチャおよび設計
図５は、この発明の一実施例に従った、ソフトウェアプログラムを更新するための例示的なプロセス５００を示す。より特定的には、図５は、１つ以上の管理される装置に更新版を適用する責任を担っているサーバによって行なわれ得るプロセスを示している。ブロック５０１で、サーバプログラム（たとえばアプリケーション）が、サーバ（たとえば二次サーバ）で実行される。ブロック５０２で、二次サーバは、更新サーバからの利用可能な更新版のリストを初期化する。たとえば、このリストは、更新サーバに関連付けられた格納場所からダウンロードされる利用可能な更新版のファームウェア更新版リスト（たとえばfirmware_update_avail.txt）であってもよい。ブロック５０３で、利用可能な新しいファームウェア更新版があるかどうかが判断される。
【００６０】
一実施例では、オフラインカタログ更新が行なわれるようにするインポートファイルが使用されてもよい。たとえば、シンサーバへのＦＴＰ転送を介するオフライン更新が、管理される装置に更新版を伝搬するために使用されてもよい。一例では、ユーザは、インポートカタログおよびファームウェア更新版ならびに管理構成要素を（たとえば「プラグイン」プログラムの形態で）配置し、これらの更新版の参照を更新ディレクトリに配置し、それから、次のサーバアプリケーション起動または更新版についてのチェックの最中に、インポートカタログは利用可能なカタログと併合される。より特定的には、インポートカタログ記録は、そのファイルが存在する場合には、利用可能なカタログに併合され、その他の場合には、インポートカタログ記録は破棄される。
【００６１】
ブロック５０４で、サーバアプリケーションは、新しく利用可能な更新版をファームウェア更新版リストに併合し、新しい利用可能なファームウェア更新版のリストを削除する。ブロック５０５で、係属中のファームウェア更新版リスト（たとえばテキストファイル）が存在するかどうかが判断される。更新版が更新サーバからダウンロードされる際、そのようなリストは、たとえば二次サーバによって保持されてもよい。たとえば、このファイルは、ファームウェアダウンロードの進行を追跡するために作成されてもよい。たとえば更新サーバから更新版をダウンロードするためのプロセスが成功しなかった場合、後の時点でダウンロードプロセスを続けるかまたは再試行するために、このファイルのステータスがチェックされてもよい。一例では、係属中のファームウェア更新版リストの存在は、ダウンロードプロセスが成功しなかったことを示す。
【００６２】
係属中のダウンロードリストが存在する場合、ブロック５０６で、欠落している更新版が更新サーバからダウンロードされる。たとえば、更新サーバは、更新版を装置に提供するために製造業者（たとえばＡＰＣ）によって維持されてもよい。ブロック５０７で、新しく利用可能な更新版がファームウェア更新版利用可能リストに併合され、一例では、係属中のファームウェアリストが削除される。
【００６３】
ブロック５０８で、装置上の更新されたファームウェアを管理するために、またはその他の場合にそれと通信するために使用されるいずれかの制御を更新する必要があるかどうかが判断される。つまり、更新されたソフトウェアを有する管理装置と通信するために関連したクライアントまたは管理サイドのプログラムが存在する場合がある。そのようなソフトウェア構成要素またはプログラムは、別のプログラム（たとえばインターネット・エクスプローラ・ブラウザプログラム）に追加されるプラグインプログラムの形であってもよい。
【００６４】
たとえば、異なる装置と通信するための制御を表わすプラグインプログラムのリストがあってもよい。これらの制御のリスト作成は更新サーバから利用可能であってもよく、二次サーバは関連したどの制御をロードするかどうかを判断してもよい。ブロック５０８で、たとえば、二次サーバは更新サーバからプラグイン制御のリストを取得してもよい。ブロック５０９で、ファームウェア制御のインポートリストが存在するかどうかが判断される。存在する場合、二次サーバは、新しく利用可能なプラグインを利用可能なファームウェア制御のリストに併合し、インポートリストを削除する。ブロック５１１で、二次サーバにまだダウンロードされていない更新版について、係属中の更新版のリストが保持される。ブロック５１２で、二次サーバが持っていない、更新サーバで利用可能なプラグインがあると判断された場合、ダウンロードが利用可能であることを示すイベントがサーバアプリケーションに発行されてもよい。その後、サーバアプリケーションが適切な制御をダウンロードしてもよい。
【００６５】
ファームウェアおよび制御が二次サーバにダウンロードされた後、これらの更新版が、装置およびそれらを管理するプログラムに適用されてもよい。適用されるべき新しい更新版があるかどうかを判断するために、同様の更新プロセスが再度行なわれてもよい。
【００６６】
一実施例では、更新版は更新サーバから１つ以上の二次サーバにトリガされる。たとえば、ブロック６０２で、二次サーバは、更新サーバにおけるソフトウェア更新版についてチェックするよう設定される。これは、たとえば、更新サーバにより、登録された二次サーバにイベントを送信することによって行なわれてもよい。また、これに代えて、二次サーバが更新サーバに接触することによって、更新版が定期的に判断されてもよい。一例では、二次サーバは、それがファームウェアおよび制御更新版の最も最近のリストを含むかどうかを判断してもよい。その後、図５を参照して上述したものと同様のソフトウェアを更新するために、同様のプロセスが使用されてもよい。
【００６７】
図７は、利用可能な更新版をダウンロードするためのプロセスを示す。一例では、プラグインまたはファームウェア更新版のダウンロードが失敗すると、そのダウンロードは、別のチェックが行なわれるまでは、別のダウンロードのために再度利用可能にはならない。上述のような係属中のカタログは、その対応するダウンロードセッションの後で取り除かれてもよく、成功裡にダウンロードされたファイルについての記録のみが保持されてもよい。
【００６８】
プラグインダウンロード中にサーバがシャットダウンすると、サーバが再始動したときにセッションが自動的には再開しない場合がある。一例では、ユーザは、失敗したいずれ
かのプラグインをダウンロードするためにトリガされる新しいセッションにおいて、再度許可を与えなければならない。一実施例によれば、既に成功裡にダウンロードされたどのプラグインも、再度ダウンロードされなくてもよい。なぜなら、それらの情報は（たとえば併合動作中に）カタログに保持されており、それらは装置の更新に使用するために利用可能であるためである。
【００６９】
ブロック７０１で、二次サーバは、更新サーバから係属中のファイル要求をダウンロードする。このリストは、二次サーバへのダウンロードがスケジュールされているファイルを識別する。ブロック７０２で、二次サーバは、更新サーバからプラグイン係属中リストをダウンロードしてもよい。このリストは、１つ以上の管理される装置を管理するために必要などの制御も識別することができる。ブロック７０３で、二次サーバは、新しく利用可能なプラグインを、利用可能な制御のリスト（たとえばfirmware_controls_avail.txt）に併合する。ブロック７０４で、二次サーバは、プラグイン係属中リストを消去し、制御係属中リストを削除する。とりわけ、１つ以上のプラグインをダウンロードするプロセスが成功しなかった場合、これらのファイルの存在は、プラグインのうちのいくつかまたはすべてをダウンロードする必要があることを示す場合がある。ブロック７０５で、二次サーバは、新しいダウンロードが更新サーバで利用可能であることを示すダウンロード利用可能イベントおよび状態を消去する。ブロック７０６で、二次サーバは、プラグイン整合についてチェックするよう、各装置に対して要求を発行する。たとえば、管理装置にロードされたソフトウェアに制御が整合するかどうかを判断するために各装置で行なわれる何らかのチェックがあってもよい。
【００７０】
図８Ａ〜８Ｂは、管理装置初期化の結果として行なわれるソフトウェア更新プロセスを示す。また、装置が発見されて、通信が途絶えた状態から復帰した際に、または更新ファームウェア要求が完了した後で、プロセス８００、８２０が行なわれてもよい。
【００７１】
ブロック８０１で、単一の装置に対するファームウェア更新版についてのチェックが、二次サーバによって行なわれる。ブロック８０２で、二次サーバは、管理装置によって実行中のソフトウェア用のアプリケーションファイル名および／またはファームウェアファイル名について、装置をポーリングする。ブロック８０３で、二次サーバは、管理装置に関連付けられたより新しい改訂版をファームウェア更新版リストが含んでいるかどうかを判断する。ブロック８０４で、二次サーバは、管理装置用の次のバージョンが利用可能であることを報告してもよく、実行されるべき利用可能な更新版が存在することを示すために、装置に関連付けられた更新版ステータスを変更してもよい。ブロック８０５で、二次サーバは、更新版利用可能イベントを発行し、装置にとって利用可能な更新版が存在することを示す状態変更を報告する。状態のそのような表示は、装置を管理するために使用される二次サーバによって提示されるアプリケーションでユーザに提示されてもよい。また、これに代えて、表示は、他の方法（たとえばｅメールメッセージ、ＳＮＭＰトラップなど）によってユーザまたはネットワークアドミニストレータに提示されてもよい。
【００７２】
図８Ｂは、管理装置に関連付けられた制御についてのチェックを示す。ブロック８２１で、二次サーバは、管理装置についての制御をチェックする。ブロック８２２で、二次サーバは、制御に関連付けられたアプリケーションファイル名について装置をポーリングする。ブロック８２３で、装置の特定の改訂版について更新された制御が存在するかどうかが判断されると、ブロック８２４で、新しい制御が利用可能であることが報告される。特に、二次サーバは（たとえば管理アプリケーション、ｅメール、または他の表示で）制御の名前と装置のステータスの変更とを報告してもよい。ブロック８２５で、二次サーバは、新しい制御が利用可能であることを示すイベントを発行する。
【００７３】
図９は、この発明の一実施例に従った、ソフトウェアを更新するためのプロセス９００
を示す。特に、プロセス９００は、１つ以上の管理装置を更新するためにユーザに管理インターフェイスを提示するために従われ得る手順を示している。ブロック９０１で、ユーザはコンソールにログインし、更新サーバで利用可能な更新された構成要素の利用可能性を監視することを許可される。ブロック９０２で、二次サーバは、装置を管理するために使用される管理構成要素を含む管理装置情報を取得する。ブロック９０３で、ユーザは装置上で、ユーザに提示されたステータスウインドウ内で選択する。
【００７４】
ブロック９０４で、装置は関連した構成要素を有するかどうかが判断される。有する場合、ブロック９１１で、その構成要素は管理コンソールに既にインストールされているかどうかが判断される。インストールされている場合、ブロック９１０で、どのネットワークに装置が配置されているかが判断される。たとえば、更新中の装置がパブリックネットワークに配置されている場合、ブロック９１２で、構成要素は装置にインストールされる。つまり、装置がパブリックネットワークに配置されている場合、装置を管理するために使用される構成要素は一般に装置のメモリ内に配置されており、必要に応じてクライアントにダウンロードされる。装置がプライベートネットワークに配置されている場合、ブロック９１３で、二次サーバが装置を管理できるようにするために、構成要素は二次サーバにインストールされる。
【００７５】
ある特定の装置に関連付けられた構成要素がない場合、ブロック９０５で、その装置に関連付けられた更新版に関する情報を提示する詳細スクリーンが存在するかどうかが判断される。存在する場合、ブロック９０６で、詳細スクリーンが起動される。存在しない場合、ブロック９０７で、この特定の装置にとって利用可能な詳細はないという表示がユーザに提示されてもよい。
【００７６】
ブロック９１１で、管理コンソールで利用可能な構成要素がないと判断された場合、構成要素が更新サーバからダウンロードされる。ブロック９０９でダウンロードが成功したと判断された場合、次に（たとえばブロック９０８で）構成要素が正しくインストールされたかどうか、チェックが行なわれてもよい。正しくインストールされていなかった場合、ブロック９０７で、エラーメッセージがユーザに表示されてもよい。しかしながら、構成要素が正しくインストールされていた場合、その構成要素は、ブロック９１２、９１３で、装置または二次サーバにそれぞれ適宜インストールされてもよい。
【００７７】
図１０Ａ〜１０Ｂは、更新サーバからのソフトウェアのダウンロードに関するいくつかの実施例を示す。ブロック１００１で、ユーザは（たとえば二次サーバによって提示されたように）コンソールにログインする。ブロック１００２で、更新サーバによって提供され、二次サーバには存在しない構成要素があるかどうかが判断される。ない場合、ブロック１００６で、ユーザはログインプロセスを続けることを許可される。新しい構成要素がある場合、ブロック１００３で、ユーザが新しい構成要素をダウンロードすることについて促されることを望んでいないかどうかを示すフラグが二次サーバにセットされているかどうかが判断される。たとえば、コンソールのユーザインターフェイスにセット可能な、「再度ダウンロードするか聞かないで下さい」（"Don't Ask Me To Download Again"）と呼ばれるフラグがあってもよい。このフラグがイネーブルになっている場合、１００６で、ユーザはログインプロセスを続けることを許可される。イネーブルになっていない場合、ブロック１００４で、ユーザは、更新された構成要素がダウンロードされてもよいかどうか促されるかもしれない。促される場合、ブロック１００５で、二次サーバはそれらをオフラインでダウンロードするよう命令されてもよい。促されない場合、ブロック１００６で、ユーザはログインプロセスを続けることを許可されてもよい。
【００７８】
図１０Ｂでは、ブロック１０２１で、ダウンロード利用可能イベントがサーバから受取られたと判断される。この表示は、たとえば、ダウンロードが更新サーバから利用可能で
あることを示す、更新サーバによって二次サーバに送信された表示であってもよい。ブロック１０２２で、利用可能なダウンロードに関してユーザが促されることを望んでいないことを示すフラグがセットされていると判断されると、ブロック１０２５で、管理プロセスが続けられる。フラグがセットされていない場合、ユーザはブロック１０２３で、制御が更新サーバからダウンロードされてもよいかどうかについての表示を（たとえば管理プログラムのインターフェイスで、または他の表示方法によって）提供するよう、促されてもよい。制御がダウンロードされてもよい場合、ブロック１０２４で、二次サーバは更新版をオフラインでダウンロードするよう設定される。そうでない場合、ブロック１０２５で、制御は管理コンソールに戻される。
【００７９】
一例では、インフラストラクチャは、多数の製品の要望を盛込むよう、更新可能な各アプリケーションについて別個のディレクトリに編成されてもよい。二次サーバ製品更新版アプリケーションおよびダウンロードのために、「aem」ディレクトリが確保されている。このディレクトリは、製品更新版ルート、https://autoupdatev2.apcc.com/に関連している。ソフトウェア更新版を実行する、クライアントシステム上の二次サーバ（または双方）で実行中のソフトウェアアプリケーションで、以下、二次サーバソフトウェアアプリケーションと呼ばれるものは、２つの機能的部分、すなわち、ネットワーク管理カードのファームウェア更新版と、二次サーバおよびその管理されるソフトウェア構成要素についてのソフトウェア更新版とを含んでいる。
【００８０】
ファームウェア更新版
二次サーバは、何千ものエンティティ、たとえば、管理される装置に関連付けられたネットワーク管理カード（ＮＭＣ）について、ファームウェアを管理する。ネットワークおよびアプリケーション効率については、二次サーバは、その開発ビルド番号をソフトウェアアプリケーション（たとえば、更新サーバ上に存在し、そこで実行中のプログラム）に報告し返し、そのアプリケーションは完全な１組のファームウェア更新版情報を返送する。このデータは、たとえば、利用可能な更新版を説明しているデータベースから直接読出すことによって、要求時点で生成される。開発ビルド番号は、報告中の製品のリリースステータスに基づいてデータをフィルタリングすることを可能にする。
【００８１】
一実施例によれば、二次サーバは、以下の入力および出力データフォーマットを認識してもよい。
【００８２】
入力データフォーマット
一実施例では、二次サーバはＨＴＴＰ  ＰＯＳＴを用いて、以下のデータフィールドを二次サーバソフトウェアアプリケーション（たとえば製品更新ウェブアプリケーション）に送信する。以下は、一実施例に従った例示的なデータフォーマットを示している。
【００８３】
【表１】
2007510987.tif 000003
【００８４】
出力データフォーマット
一実施例によれば、データは、コンマで区切られたＡＳＣＩＩテキストストリームで返送されてもよい。全部で９つのコンマで隔てられた１０のフィールドが更新エントリごとに存在する。二次サーバに返送された各更新エントリラインは、空白のデータフィールドにかかわらず、完全な１組のコンマを有することが保証されている。セミコロンは、各更新エントリを区切っている。二次サーバに返送された各エントリラインは、セミコロンで終わることが保証されている。
【００８５】
【表２】
2007510987.tif 000004
【００８６】
他の特徴
この発明の一実施例に従ったソフトウェア更新プロセスに関する１つ以上の追加の特徴があってもよい。たとえば、ソフトウェア更新プロセスを管理する上で有益であり得る、二次サーバおよびソフトウェア更新アプリケーションの追加の特徴があってもよい。
【００８７】
二次サーバ
・顧客環境についての情報（在庫情報、顧客登録など）を報告する。
【００８８】
ソフトウェア更新アプリケーション
・データベースデータは一般に頻繁には変わらないため、データベース要求をキャッシュする
・ダウンロードされた各到着要求について、追加の顧客固有情報をログ記録する
・別の例示的な設定では、二次サーバは完全な１組の製品更新版情報をダウンロードする。これは、二次サーバが更新版を適用するための基準を判断するため、ファームウェア更新ウェブアプリケーションから制御および柔軟性を取り去る。
【００８９】
サーバソフトウェア更新版
二次サーバのサーバソフトウェア（たとえば管理アプリケーションプログラム）は、適用可能なプラグインアプリケーションを含むそれ自体のアプリケーションのすべてまたは一部を更新可能であってもよい。二次サーバについての製品更新版要求は１対１ベース（二次サーバの各インスタンスについて１つの要求）で行なわれ得るため、二次サーバは、その現在のバージョンを説明するデータを、更新サーバ上のプログラムまたは他のエントリに報告し返してもよい。この情報により、二次サーバ製品更新アプリケーション（たとえばウェブベースのアプリケーション）は、どの更新版が、もしあれば、その二次サーバソフトウェアバージョンに当てはまるかを判断できるようになる。
【００９０】
更新可能製品バージョンについての情報は、更新サーバに配置されたデータベースに含まれていてもよい。更新版の各々についての情報は、関連したデータベースに含まれていてもよい。ウェブアプリケーションは、一例では、１つ以上の更新版が配置され得るＵＲＬ場所（たとえば安全なＨＴＴＰ  ＵＲＬ）を返送してもよい。
【００９１】
入力データフォーマット
一例では、二次サーバはＨＴＴＰ  ＰＯＳＴを用いて、以下のデータフィールドを二次サーバ製品更新アプリケーションに送信する。以下の表３は、この発明の一実施例に従った例示的な入力データフォーマットを示している。
【００９２】
【表３】
2007510987.tif 000005
【００９３】
出力データフォーマット
二次サーバ製品更新ウェブアプリケーションは、一実施例によれば、以下の３つの応答シナリオを有する：
１．必要なデータが二次サーバ製品更新ウェブアプリケーションによって受信されていない場合、アプリケーションは「不正形式の要求］を返送する
２．報告された二次サーバソフトウェアバージョン情報に適用可能な更新版がない場合、アプリケーションは「更新版利用不可」を返送する
３．報告された二次サーバソフトウェアバージョン情報に適用可能な更新版がある場合、アプリケーションは以下のデータを返送する。
【００９４】
以下の表４は、この発明の一実施例に従った例示的なデータフォーマットを示している。
【００９５】
【表４】
2007510987.tif 000006
【００９６】
他の特徴
・顧客環境についての情報（在庫情報、顧客登録など）を報告する。
【００９７】
製品更新アプリケーション
・各到着要求について追加の顧客固有情報をログ記録する。
【００９８】
一実施例によれば、二次サーバソフトウェアは、利用可能な更新版をダウンロードするために、安全なＨＴＴＰ接続またはＦＴＰ接続を使用してもよい。
【００９９】
自動更新サーバは、ウェブカード更新記録を格納するための別個の表を格納していてもよい。製品マネージャが製品更新版を（たとえば管理される装置用の）ソフトウェアキットに関連付けることができるよう、カタログが更新されてもよい。
【０１００】
一実施例に従った装置（たとえばカード）上でファームウェアを更新する際、二次サーバソフトウェアは、最初にＯＳ、次にアプリケーション層ソフトウェアを送信して、ＯＳおよびアプリケーション層の双方を送信する。カードにバイナリを送信する際はいつでも、現在のアプリケーション層が消去される、ということが理解される。したがって、ＯＳおよびアプリケーション層ソフトウェアの双方をカードにダウンロードすることが好ましい。
【０１０１】
一実施例によれば、二次サーバは、ＯＳ層更新が成功したことを確実にするために、管理される装置を検査してもよい。一例では、二次サーバは、ルートＦＴＰディレクトリの（たとえば「ｌｓ」コマンドを介した）リスト作成を行なってもよく、ＯＳ層ファイルのチェックを行なってもよい。二次サーバがログインを許可され、かつ更新が成功した場合、ＯＳファイルは新しいファイルである。二次サーバがログインを許可され、かつ更新が成功しなかった場合、ＯＳ層ファイルは以前のＯＳ層である。
【０１０２】
アプリケーションが正しく動作しているかどうかを判断するための１つの方法は、ウェブカードの予想されたＳＮＭＰ  ＯＩＤの問合せを行なうことを含んでおり、ウェブカードが応答可能である場合、ＳＮＭＰは稼動中であり、それにより、アプリケーション層が稼動中であることを示している。
【０１０３】
代替的な一方法は、ルートＦＴＰディレクトリの（たとえば「ｌｓ」コマンドを介した）リスト作成を行ない、アプリケーション層によって使用されるイベントファイル（たとえば"event.txt"）が存在するかどうかを識別することを含む。カードを更新する試みが数回行なわれた場合（たとえば２回試みて２回連続して失敗した場合）、この出来事はハードウェア障害と考えられ得る。１タイプのカードを更新するには、たとえば、二次サーバソフトウェアは、ウェブカード上でＦＴＰサーバにアクセスするためにユーザ／パスワード／ポートを必要とする場合がある。
【０１０４】
更新版ファイルフォーマットおよび命名規定
一実施例によれば、バイナリファームウェアファイルはヘッダを含む。一実施例では、ヘッダは、ファイルについての識別情報と、ファイル全体およびヘッダの双方のチェックサムとを含む。このチェックサムは、（たとえばＦＴＰを用いて）ファイルをカードに送信しようと試みる前にファイルの妥当性を検査するために使用可能である。
【０１０５】
以下の情報は、以下の例で使用されるファイルフォーマットおよび命名システムのさまざまな実現化例に関する：
制御のための実行可能なタイプ：ＤＬＬは起動用エントリポイントである（制御は、たとえば他のＤＬＬ、ヘルプのようなサポートファイルを含んでいてもよい）
制御のための命名フォーマット：apc_plugin_<app layer>_<control version>。たとえば、apc_plugin_rpdu_1.0.0.7.dll
プラグインは、他のソフトウェアと同様、バージョン化されてもよい
major.minor.point.build（たとえば、6.1.1.107）
制御のための配信コンテナ：上述の命名フォーマットを有するＣＡＢファイル。たとえば、apc_plugin_rpdu_1.0.0.7.cab
二次サーバによって使用され、制御する装置に整合する情報：バージョンを含むアプリケーション層ファイル名が、カタログエントリに整合される
サーバによってコンソールに提供され、個々の装置を起動させる制御を示す情報：拡張を有するものの経路は有さないＣＡＢファイル名。たとえばapc_plugin_rpdu_1.0.0.7.cab
サーバからコンソールへの制御のための配信方法：ＨＴＴＰ要求。たとえば、http://<server ip>/<FTP directory>/<CAB file name>
サーバ上のＣＡＢファイルの場所：ftpディレクトリ。たとえば、/apcstore1/updates
コンソール上の制御インストール場所：
【０１０６】
【数１】
2007510987.tif 000007
【０１０７】
一実施例によれば、ある装置のアプリケーション層ファイル名は、その装置に関連付けられるべき制御のために、カタログエントリに正確に整合しなければならない。バージョン情報が整合しなければならないため、ある制御を選択するために特定のファームウェア改訂版についてのカタログエントリがなければならない。多数のファームウェア改訂版が同じ制御にマッピングされてもよいが、一実施例では、各々はそれ自体のカタログエントリを必要とする。したがって、異なるファームウェア改訂版を有する装置がある場合、同じ制御の多数の改訂版が単一のシステム内でアクティブのままであってもよい。
【０１０８】
一実施例によれば、１対１の整合は、新しい制御とより古いファームウェア改訂版との互換性テストを行なう必要を避けるために使用可能である。１対１の整合のトレードオフは、制御によって消費されるディスク空間と同様、時間が経つにつれカタログがかなり大きくなり得るということである。この発明の一実施例による例示的なファイル命名規則を図１１に例示として示し、そのフォーマットの例を以下の表５に示して説明する。
【０１０９】
【表５】
2007510987.tif 000008
【０１１０】
【表６】
2007510987.tif 000009
【０１１１】
【表７】
2007510987.tif 000010
【０１１２】
上述の命名および番号付け規定は、多くのソフトウェア更新シナリオを満たすよう使用されてもよい。たとえば、一実施例では、名前は、制御が扱う装置のタイプを反映しているが、単一の制御が多数のファームウェア改訂版に関連付けられているかもしれないため、アプリケーション層バージョン情報を全く含んでいない。また、制御は、ファームウェアの対応する改訂版なしで改訂されてもよい。
【０１１３】
ＣＡＢファイルは多数のファイルを含むことができ、そのため、制御は単一のファイルである必要はない。一実施例によれば、制御は署名されなければならない。制御署名によって提供されるセキュリティは、たとえば、スタンドアローンの場合のウェブブラウザによって使用されてもよい。また、これに代えて、セキュリティは二次サーバによって使用可能である。いずれの場合も、二次サーバは、制御が修正されていないこと、およびそれが元のままの製造業者によって配信されたことを確実にするために、制御を検査すべきである。
【０１１４】
このアプローチでの主なトレードオフは、ディスク空間に対する簡潔性である。
簡潔性−サーバおよびコンソールの双方にとって、それらが制御をダウンロードする必要があるかどうか検出することは比較的容易である。バージョニング用ファイル名および制御用の別個のサブディレクトリを使用することは、（たとえば、利用可能な制御のより新しいバージョンがあるかどうか、すべてのファームウェア改訂版と後方互換性がある制御の最新バージョンがあるかどうか、より古い制御と後方互換性があるDCal dllの新しいバージョンがあるかどうか、バージョン情報のないサポートファイルがあるかどうか、などを判断する）バージョニング問題を排除する。
【０１１５】
ディスク空間−ＣＡＢ内のファイルが変わるたびに、ＣＡＢおよび制御の名前は変わらなければならない。一実施例によれば、制御の現在の改訂版は以前のものを決して上書きしない（たとえば、ＣＡＢファイルまたは制御のいずれも上書きしない）。別の実施例に
よれば、制御間で共有されるサポートファイル（たとえば、DCall dllなど）はない。一例によれば、各制御はそれ自体の完全な１組のそのすべてのサポートファイルを有する。システムは、定期的クリーニング方式（たとえば、ｘ日、月、年間使用されていなかったファイルを削除する、など）を含んでいてもよい。
【０１１６】
<control version>の例示的なフォーマットは、カードと同じ規定に従い、wxyzであり、ここでw＝major１−９、x＝minor０−９、y＝point０−９、z＝ベータａ−ｚ、Ａ−Ｚである。それは各々を１桁／文字に制限していない（１２３ａ＝１．２．３．ａ）。また、ビルド番号をベータ文字に変換することが必要な場合がある。
【０１１７】
（ウインドウズ（登録商標）ベースのコンピュータ上にあるような）プログラムファイルディレクトリは、その内容がユーザに見えるため、制御用インストール場所として使用されてもよく、コンソールがサポートするすべてのウインドウズ（登録商標）オペレーティングシステムタイプおよびローカライズドバージョン上で利用可能であり、コンソールによってＯＳから検索可能である。制御は、コンソール作業ディレクトリ（たとえば、
【０１１８】
【数２】
2007510987.tif 000011
【０１１９】
の下にはインストールされていない。なぜなら、これらのサブディレクトリおよびファイルは、コマンドプロンプトを介さなくてはユーザには見えないためである。ソフトウェアは、別の代替例では、以下の下にインストールされてもよい。
【０１２０】
【数３】
2007510987.tif 000012
【０１２１】
更新版は、３つのカテゴリに分けられてもよい。
１．装置（たとえばウェブカード）用のファームウェア更新版
一実施例によれば、ファームウェア更新版は、二次サーバがその後、管理される装置（たとえばネットワーク管理カード）に押出すいずれかの更新版に関する。これに関連付けられたファイルは、ファームウェア更新版カタログ、firmware_update_available.txtを含み、それは、利用可能なＦＷ更新版すべてのリスト、それらのバージョンが何か、および、二次サーバがそれらを更新サーバから引張ってくるためにどこを見るべきか、を含んでいる。二次サーバは、その装置にとって利用可能な更新版があるかどうかを判断するために、およびそのようなバイナリ更新版の場所を判断するために、このカタログを使用する。バイナリ更新版ファイルの一例は、apc_hw02_rPDU_220g.binである。
【０１２２】
利用可能な更新版があると二次サーバが一旦判断すると、ユーザはそれらを更新サーバからダウンロードするよう促されてもよく、ユーザがそれを選択した場合、ユーザは、更新版が利用可能であることをｅメールを介して通知される。二次サーバソフトウェアプログラムは、カタログ内のすべてのバイナリを、二次サーバに関連付けられた記憶媒体にダウンロードし、次に、更新されるべき装置をユーザが選択できるようにするダイアログが、ユーザに提示される。二次サーバは、ファームウェア更新プロセスの成功および失敗についてユーザにステータス報告を提示してもよい。
【０１２３】
２．二次サーバソフトウェアプログラム用の共通クライアントプラグイン
一実施例によれば、二次サーバソフトウェアプログラム用の共通クライアントプラグインは、特定の装置を管理するよう設計された非常に機能的なクライアントである。そのため、管理ステータススクリーンから、ユーザが装置を選択した場合、ユーザに装置の詳細およびいくつかの管理能力が提示される。装置を管理するために利用可能な共通のクライアントが存在する場合、インターフェイスは、その装置の全機能への十分なアクセスを、はるかに優れた活用性、外観および感覚とともに提供してもよい。これらの共通クライアントは装置のために時間をかけて作成されており、それらが利用可能である場合、それらは更新サーバに通知される。二次サーバが更新版についてのチェックを行なう場合、二次サーバは、共通クライアントが利用可能かどうかを検出し、それらをダウンロードする。
【０１２４】
一旦ダウンロードされると、ユーザが共通クライアントによって管理可能な装置上でダブルクリックを試みると、そのクライアントはそのユーザのクライアントマシンに分配され、起動される。共通クライアントに関連付けられたファイルは、cabファイル、apc_plugin_rpdu_1.0.0.13.cabを含む。そのcabファイルは、プラグインを実際にロードするのに必要なプラグイン・ランチャーおよび多数の.dllを含む。プラグインはそれら自体の「カタログ」ファイル、firmware_controls_available.txtを有しており、それは、それがどのバージョンのプラグインか、そのプラグインが何の装置を管理するかを記述しているという点で、ファームウェア更新版カタログとよく似ている。二次サーバは、どのプラグインがこのサーバで管理中の装置で使用されるために利用可能かどうかを判断するために、このカタログを使用してもよい。
【０１２５】
上述のようなＣＡＢファイルは、その共通クライアントのプラグイン分配を含む。一実施例によれば、唯一の制御は、二次サーバの外部のスタンドアローンアプリケーションにあり、装置を１対１で管理するために共通クライアントが使用されてもよく、次に、プラグイン（たとえば.dllフィル）を実際にロードするためにローダ制御が使用されてもよい。
【０１２６】
カタログファイルのために、以下のフォーマット／特徴が使用されてもよい：
テキストベースである
コンマで区切られている
各ラインの最後にセミコロンがある。
【０１２７】
ファームウェア更新版ファイルにおけるフィールドは、以下を含む：
ハードウェア、アプリケーション、バージョン、特殊、顧客、ビルド、アプリケーションＵＲＬ、ＯＳＵＲＬ、記述テキスト、記述ＵＲＬ。
【０１２８】
共通制御ファイルにおけるフィールドは、以下を含む：
ハードウェア、アプリケーション、バージョン、特殊、顧客、ビルド、ローカル、アプリケーションＵＲＬ。
【０１２９】
さまざまなファイルフォーマットおよび場所がここに詳細に説明されてきたが、この発明が任意の特定の実現化例に限定されないことが理解されるべきである。
【０１３０】
このようにいくつかの例示的な実施例を説明してきたが、さまざまな変更、修正および改良が当業者には容易に明らかとなるであろう。そのような変更、修正、および改良は、この発明の精神および範囲内にあるよう意図されている。したがって、前述の説明は単なる例示であり、限定的であるよう意図されてはいない。
【図面の簡単な説明】
【０１３１】
【図１】この発明の一実施例に従った、ソフトウェアプログラムを更新するためのシステムのブロック図である。
【図２】この発明のさまざまな局面を実現可能な汎用コンピュータシステムのブロック図である。
【図３】この発明の一実施例に従ったソフトウェア更新プロセスのフローチャートである。
【図４Ａ】この発明の別の実施例に従ったソフトウェア更新プロセスのフローチャートである。
【図４Ｂ】この発明の別の実施例に従ったソフトウェア更新プロセスのフローチャートである。
【図４】この発明の一実施例に従ったソフトウェア更新プロセスのフローチャートである。
【図５】この発明の一実施例に従ったソフトウェア更新プロセスのフローチャートである。
【図６】この発明の一実施例に従ったソフトウェア更新プロセスのフローチャートである。
【図７】この発明の一実施例に従ったソフトウェア更新プロセスのフローチャートである。
【図８Ａ】この発明の一実施例に従ったソフトウェア更新プロセスのフローチャートである。
【図８Ｂ】この発明の一実施例に従ったソフトウェア更新プロセスのフローチャートである。
【図９】この発明の一実施例に従ったソフトウェア更新プロセスのフローチャートである。
【図１０Ａ】この発明の一実施例に従ったソフトウェア更新プロセスのフローチャートである。
【図１０Ｂ】この発明の一実施例に従ったソフトウェア更新プロセスのフローチャートである。
【図１１】この発明の一実施例に従ったソフトウェア命名フォーマットを示すブロック図である。
【図１】
2007510987.tif 000013
【図２】
2007510987.tif 000014
【図３】
2007510987.tif 000015
【図４Ａ】
2007510987.tif 000016
【図４Ｂ】
2007510987.tif 000017
【図５】
2007510987.tif 000018
【図６】
2007510987.tif 000019
【図７】
2007510987.tif 000020
【図８Ａ】
2007510987.tif 000021
【図８Ｂ】
2007510987.tif 000022
【図９】
2007510987.tif 000023
【図１０Ａ】
2007510987.tif 000024
【図１０Ｂ】
2007510987.tif 000025
【図１１】
2007510987.tif 000026
【手続補正書】
【提出日】平成18年6月29日(2006.6.29)
【手続補正１】
【補正対象書類名】図面
【補正対象項目名】図１
【補正方法】変更
【補正の内容】
【図１】
2007510987.tif 000027
【手続補正２】
【補正対象書類名】図面
【補正対象項目名】図２
【補正方法】変更
【補正の内容】
【図２】
2007510987.tif 000028
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】図３
【補正方法】変更
【補正の内容】
【図３】
2007510987.tif 000029
【手続補正４】
【補正対象書類名】図面
【補正対象項目名】図４Ａ
【補正方法】変更
【補正の内容】
【図４Ａ】
2007510987.tif 000030
【手続補正５】
【補正対象書類名】図面
【補正対象項目名】図４Ｂ
【補正方法】変更
【補正の内容】
【図４Ｂ】
2007510987.tif 000031
【国際調査報告】
2007510987.tif 000032
2007510987.tif 000033