JP2006520975A

JP2006520975A - 非侵入な自動オフサイト・パッチ・フィンガプリンティングおよびアップデーティングシステム、および方法

Info

Publication number: JP2006520975A
Application number: JP2006508993A
Authority: JP
Inventors: ショーンモシャー，; クリストファーエー．エイチ．アンドリュー，; ジョナサンエム．ゴードン，; マイケルベーコン，
Original assignee: パッチリンクコーポレーション
Priority date: 2003-03-20
Filing date: 2004-03-02
Publication date: 2006-09-14
Also published as: ZA200506830B; BRPI0408425A; WO2004086168A3; US20040003266A1; EP1611509A4; CA2517223A1; CN1894661A; AU2004222883A1; KR20050120643A; EA200501486A1; WO2004086168A2; MXPA05009990A; EP1611509A2

Abstract

ソフトウェア・アップデート（２３２）を発見し、所与のコンピュータ（２０２）が当該ソフトウェア・アップデートを使用可能であるか否かを見出し、必要に応じて当該コンピュータを当該ソフトウェア・アップデートでネットワーク（２００）を介して自動的にアップデートするための方法、システム、および構成された記憶媒体が提供される。さらに、障害が検出された（３１６）とき、配布が停止（３１８）させられ、ソフトウェアがすでにアップデートされたコンピュータから自動的に除去（３２２）される。ネットワークの一部ではないがファイアウォールを通ってパッケージ・コンピュータ（２３０）へとアクセスできるアップデート・コンピュータにソフトウェア・アップデートを中間的にアップロードすることによって、ソフトウェア・アップデートの源をネットワーク・ファイアウォールによってアクセスすることができないアドレスに保存することができる。

Description

（著作権について）
この特許文書の開示の一部には、著作権の保護の対象となる材料が含まれている。著作権者は、特許商標局の特許ファイルまたは記録に現れる限りにおいて、何人も特許文献または特許の開示をファクシミリ複製することについて異論はないが、それ以外の場合については、何であれすべての著作権を留保する。著作権者は、米国特許商標著作権法施行規則（３７Ｃ．Ｆ．Ｒ）のセクション１．１４によるすべての権利を含め、この特許文書を秘密に保つ権利をいささかも放棄しない。

本発明は、リモート・ネットワークを介して既存のソフトウェアをアップデートするシステムおよび方法に関する。さらに具体的には、本発明は、アップデートの必要性の確認、および必要とされるソフトウェアについてのクライアント‐サーバ・システムを介して介してのアップデートに関係し、人間による監視の必要がなく、かつターゲット・ネットワークの管理者装置にソフトウェア・パッチのコピーを保持する必要がない。

コンピュータ・ソフトウェア業界の「現在の技術水準」では、依然として、所望の挙動においてさまざまな異常を有するソフトウェアを配布することがしばしばである。そのような異常な挙動は、「バグ」と呼ばれている。

最初のコンピュータ・バグは、今やスミソニアン博物館（Ｓｍｉｔｈｓｏｎｉａｎ）に保存されているハーバード大学（ＨａｒｖａｒｄＵｎｉｖｅｒｓｉｔｙ）のマーク・ツー・アイケン・リレー計算器（Ｍａｒｋ II ＡｉｋｅｎＲｅｌａｙＣａｌｃｕｌａｔｏｒ）の動作ログに存在する。操作者が、このコンピュータのリレー・スイッチの間に挟まれた蛾を取り除き、エントリに「バグが実際に見つかった最初のケースである」と記述した。このとき以来、コンピュータのハードウェアおよびソフトウェアにおける問題は「バグ」と呼ばれるようになり、問題を取り除くためのプロセスを「デバグ」と呼ぶようになった。

ソフトウェアが「デバグ」されるたびに、ソフトウェアの該当部分についての変更が生成され、このような変更が、「パッチ」または「フィクス」と呼ばれるソフトウェアの追加の一部をもたらすこともある。この業界のソフトウェア・ベンダは、これらパッチをより格式張った「サービス・パック」や「サポート・パック」などという名称で呼ぶことが多い。

このプロセスはこの業界において広く行なわれており、ソフトウェア・ベンダは、利用可能な「サポート・パック」の履歴を保持するためにさまざまな呼称および採番の仕組みを使用している。これら「サポート・パック」の継続的な維持は、ベンダが標準的な呼称および採番の仕組みに合意しない場合に、ますます困難になる。

例えば、マイクロソフト社（Ｍｉｃｒｏｓｏｆｔ）は、彼らのオペレーティング・システム・ソフトウェア製品であるＷｉｎｄｏｗｓＮＴ（登録商標）一族について、彼らの顧客が遭遇しうる問題を解決すべく適用するため、利用可能な少なくとも６つの主要な「サービス・パック」を有している。より一般的に言えば、所与の任意のオペレーティング・システムについて、パッチ、フィクス、ソリューション、および／またはサービス・パックの総数が、莫大なものになりうる。

アプリケーションがインストールされるとき、標準的なコンピュータ・ファイルとともに、１つ以上のこれらオペレーティング・システム・ファイル・パッチが含まれていることがある。これらのパッチは、アプリケーションのベンダがオペレーティング・システム・ファイルの１つ以上において或る異常な挙動を発見し、それら問題のあるファイルの１つの異なるバージョンのかたちで「フィクス」を送信するため、一般的に含まれている。これは、このようなサービスをただ１つのアプリケーション・ベンダが実行しており、あるいはアプリケーション・ベンダによって修正されたファイルが当該ベンダのアプリケーションのみによって使用されるならば、引き起こされる困難は比較的少ない。しかしながら、そのようでない場合がしばしばである。

他のアプリケーションがインストールされるとき、そのアプリケーションが、共有に係るコードの一部についてより最近のバージョンを含んでいるかもしれない。これらの共有に係るオペレーティング・システム・ファイルの１つの部分集合は、別の名前でも呼ばれるが、ＤＬＬ（ｄｙｎａｍｉｃａｌｌｙｌｉｎｋｅｄｌｉｂｒａｒｉｅｓ）と呼ばれる。これらの共有に係るオペレーティング・システム・ファイルは実行可能であることがしばしばであり、或る決まった数のパラメータ、および或る特定の種類のパラメータなどを予定している。共有に係るファイルの性質が変わってしまう（例えば、パラメータ一式が異なる、名前が異なる、関数が異なる、など）と、呼び出し元のアプリケーションが、もはや正しく振る舞うことができなくなる。「プリント」などのコンピュータの共通機能の多くは、このようなやり方で参照されている。

多くのソフトウェア・ベンダは、「最新」バージョンのオペレーティング・システム・ファイルを提供しようと試みている。しかしながら、別のアプリケーションがコンピュータにロードされるとき、元のアプリケーションが計画どおりに機能するために必要とするオペレーティング・システム・ファイルが、上書きされたり、微妙に（あるいは微妙ではなく）変更されたりするかもしれない。

或る組織の管理者が、１００台ものサーバを運用状態に保ちつつ、これらのサーバに接続する３，０００のユーザのサポートを担当しているとする。さらに、この管理者は、ユーザの要求によるアプリケーションや管理上必要なアプリケーションについて、それがシュリンクラップに包まれた購入品であっても、内部で開発したアプリケーションであってもよいが、インストールを担当している。さらに管理者は、時間に注意を払うべき文書について、ローカルまたはリモートでの時宜を得た配布の責任を負っている。

ここで、６つのサービス・パックをネットワークにインストールし、すべてのクライアントに配布しなければならない場面を想像されたい。６つのサービス・パックを適用するということは、１００台のサーバのすべてのそれぞれを７回訪問し、合計すると７００回の訪問につながる。この数字は、サービス・パックのうちの１つのアプリケーションが、フィクスをするよりもさらなる問題を生じさせかねず、元に戻さなければならないがために、各装置について１回の追加の訪問があると仮定している。

３，０００のクライアントが、すべて同じワークステーション・オペレーティング・システムを動作させているならば、それは、パッチを適用するためにさらに２１，０００回の訪問があるということを意味する。これらすべてが、内部で開発したアプリケーションおよびシュリンクラップ製品のインストールおよびパッチ適用の際に達成されなければならない点を忘れてはいけない。ソフトウェア・パッチおよびファイルの配布、ならびにその後の適用が、いわゆる「管理者の苦悩」の最初の表われである。

すべてのインストールが生じているとき、個々のサーバは、依然として監視されなければならない。サーバが注目を必要としているとき、他の者がサーバが停止しており修理が必要であると必死に訴えて、管理者へと連絡してくることがしばしばある。管理者が、これらの装置を監視するための何らかの方法を有しているならば、より応答がしやすくなり、問題の影響をさらに軽減できるかもしれない。監視の必要性は、「管理者の苦悩」の第２の表われである。管理者の仕事は、離職率が高いことが多く、それらのシステムのユーザは、低い生産性に悩まされるであろう。

従来、管理者は、追加のスタッフを与えられることによって補佐されてきた。当然ながら、この救済策は問題なしというわけにはいかない。人員の追加は、彼らの間の通信チャネルの数を増加させる。インストールおよびアップデートに関与する人員は、同じ単位の作業を実行したり、あるいは実行を試みたりすることがないよう、追跡装置またはシステムを必要とする。チームのメンバー間でこのような協調を欠くことが、「管理者の苦悩」の第３の表われである。

いくつかのソリューションが提案され、さまざまな形態、実装、および範囲または完全性にて現在利用可能である。典型的には、これら提案されているソリューションは、管理者の環境にローカルにインストール（例えばパッチをあてる）できるシュリンクラップの製品として入手可能である。いくつかの最近の製品は有用であるが、従来からの多くのソリューションは、管理者環境の大幅な変更を必要するという点で、侵襲的である。シュリンクラップのソリューションでは、管理者のネットワークに製品全体を追加でインストールする必要があって侵襲的であり、これによって問題が増えるうえに、サポートおよび配布のプランを協調させるための中央の「指令センター」を欠いている。最近のソリューションは侵襲の度合いがいくぶん少ないかもしれないが、それでもなお管理者とソリューションとの間の特別な接続を必要とし、多くの場合、協調された作業のためのセンターを提供していない。

さらに、ソフトウェアの所与の部分がパッチを受け取ったのか、あるいはどのパッチを受け取ったのかが、常に正確に知られているわけではない。アップデートは、その存在を常に明白に告知しているわけではない。したがって、或る特定のコンピュータが或る特定のパッチをすでに受け取ったか否かが、常に明らかなわけではない。したがって、ネットワークを介してコンピュータをアップデートするための優れたツールおよび技法へのニーズが存在する。ここでは、そのようなツールおよび技法について説明し、特許請求の範囲として請求する。

（発明の要約）
本発明は、人間の管理者の必要性を減らしつつ、ソフトウェアがアップデートを必要としているか否かを判断して、必要としている場合に、ネットワークを横断して当該ソフトウェアをアップデートするための方法、物品、信号、およびシステムに関する。アップデートに失敗したとき、アップデート・ソフトウェアがインストールされたコンピュータを、未アップデートの状態に復帰させることができる。本発明は、添付の特許請求の範囲によって定められ、特許請求の範囲がここに記載する発明の概要よりも優先する。

種々の実施の形態において、本発明は、ネットワークを横断し、複数のオペレーティング・システムにまたがるソフトウェアおよびパッチのフィンガプリントにもとづき、ソフトウェアの配布、ソフトウェアのインストール、ソフトウェアのアップデート、およびファイルの配布を容易にする。ネットワーク接続を有し、かつアップデート・エージェントを動作させている任意のコンピュータを、アップデート・サーバに接続し、管理者が当該エージェントについて指定したあらゆるタスクを処理することができる。

図２が、そのようなシステムの１つについて概要を示している。説明を分かりやすくするために２台のターゲット・コンピュータと１台のアップデート・コンピュータしか示されていないが、ネットワーク２００が、ファイアウォール２１４によってインターネットから保護されている。ネットワークのターゲット・コンピュータ２０２、２０８をアップデートするために必要なソフトウェアが、パッケージ・コンピュータ２３０、２３４に位置しているが、パッケージ・コンピュータ２３０、２３４は、ファイアウォールの内側または外側に位置し、ファイアウォール２１４によってターゲット・コンピュータ２０２、２０８との直接通信を禁じられている。しかしながら、アップデート・サーバ２２０が、おそらくは内部のファイアウォールを通過するネットワーク２００へのアクセス２１６を持ち、さらにファイアウォール２１４を通過してアクセスすることができる。システムは、オンサイトの買い取りのソリューションおよび完全にオフサイトでホストされるソリューションの両者として動作するように設計され、イントラネット／エクストラネットのインフラストラクチャのあらゆるレベルのファイアウォールおよびプロキシ回路を通って動作することができる。

パッチ・フィンガプリント９０２が、集積所コンポーネントにて所与のソフトウェア・パッケージ（パッチ・フィンガプリントに関連付けられている）、パッチ、ドライバ、などをシステム内のコンピュータへとロードすべきか否かを判断できるよう、レシピを与える。これらのフィンガプリントは、ファイアウォール２１４の内側または外側であってよいパッチ・コンポーネント・データベース場所９００に保存される。これは、別個の場所にあってもよく、あるいはアップデート・サーバ５２８にインストールされてもよい。さらに、集積所コンポーネントは、ネットワークのターゲット・コンピュータ２０２、２０８のそれぞれについて基本的なハードウェアおよびソフトウェア情報を含んでいる目録ライブラリ・データベース９１８を備えている。システムは、パッチ・フィンガプリント内の情報、目録ライブラリ、およびネットワークの各ターゲット・コンピュータから収集された特定の情報を使用し、所与のコンピュータについてどのパッチおよびドライバが必要であるかを、知的に推奨することができる。

図５に示すように、本発明の好ましい実施の形態は、発見エージェント５４８として知られる追加のエージェントを、ターゲット・コンピュータ５００にインストールして使用し、この発見エージェント５４８が、当該装置上のハードウェアおよびソフトウェアを定期的に見つけ出す。次いで、この目録情報が、集積所コンポーネントのどこかに位置する目録ライブラリ９１８へと報告される。コンピュータの目録に加え、発見エージェントは、各パッチ・フィンガプリントに関連付けられた特定のパッチをインストールすることが適切であるか否かを示すパッチ・フィンガプリントについての走査結果を返す。

このように、目録データベースは、ネットワーク内の任意の特定のターゲット・コンピュータにインストールされたソフトウェア、ハードウェア、および現在のパッチ・フィンガプリントの完全な目録を収集する。この情報によって、アップデート・サーバ５２８は、ネットワーク内のすべてのコンピュータの現在のパッチ状態についての詳細レポートを、ユーザに提示することができる。これは、当該パッチを必要としているコンピュータの数、ならびに当該パッチがすでにインストールされたコンピュータを示している。

さらに、フィンガプリント定義９０６は、通常はシステムによる配布に適したアップデート・パッケージにも関連付けられる。特定のパッチの必要性が、ネットワーク内のすべてまたは任意のコンピュータについてその署名を走査することによって確認されると、それを、単に日時を選択することにより管理者によって素早く配布することができる。

幾つかの実施の形態においては、フィンガプリント定義９０６を、パッチについて議論するベンダの公報、本発明の実施の形態によって用意された管理者のためのレポート、ターゲット・コンピュータ５００の署名、および配布パッケージのうちの１つ以上と組み合わせて、持ち運び可能なパッチ定義ファイルを形成できる。このパッチ定義ファイルは、他のネットワークのアップデートに使用できる情報を提供する。このパッチ定義ファイル（「パッチ・メタファイル」として知られる）は、異なるネットワークのアップデート・サーバ５２８の間でパッチを移動または複製するために本発明の実施の形態によって使用することができる持ち運び可能な一様なデータ表現を提供する。適切なネットワーク１００には、これらに限られるわけではないが、より高いセキュリティをもたらすべく絶縁されている軍用のネットワークなど、インターネットに接続されておらず、かつ／あるいは互いに接続されていないネットワークが含まれる。移動／複製は、電子メール、テープの書き込み／読み出し、および／または他の通常のデータ伝送手段によって行なうことができる。さらに、パッチ・メタファイルは、異なるベンダによって供給される本発明の実施の形態の間でのパッチの交流および相互運用を助けることができる。

特定のターゲット・コンピュータへとロードされる必要があるパッチは、アップデート・エージェント２０４、２１０に関連付けられたアップデート・リスト２２２にて、アップデート・サーバ２２０に列挙されている。図では、リスト２２４がターゲット１（２０２）に関連付けられ、リスト２２６がターゲット２（２０８）に関連付けられている。アップデート・リストは、パッチを見つけることができる場所を（ユニバーサル・リソース・ロケータすなわちＵＲＬなどの手段によって）少なくとも１つ指定しており、随意により、当該ソフトウェアがインストール可能になる最先の日にちを含んでいる。

動作において、ターゲット１（２０２）のアップデート・エージェント２０４が、オンサイトまたはオフサイトのアップデート・サーバ２２０にて自身のアップデート・リスト２２４をチェックし、新規パッケージをインストールすべきか否かを調べる。そのようなパッケージが存在する場合、アップデート・エージェント２０４は、当該パッケージがすでにアップデート・サーバ２２０のメモリ内に存在するか否かをチェックする。存在する場合、アップデート・エージェント２０４は、アップデート・サーバ２２０から直接、ソフトウェア・パッチのインストールを試みる。存在しない場合、アップデート・エージェント２０４は、パッケージ・コンピュータ場所２３２から直接、ソフトウェア・パッチのインストールを試みる。幾つかの場合にはこれが成功し、その場合にはアップデート・リスト２２４が更新される。

他の場合には、ダウンロード２１８がファイアウォール２１４によって阻止される。これが生じた場合、アップデート・エージェント２１０がアップデート・サーバ２２０に通知し、アップデート・サーバ２２０自身が、パッケージを引き出してメモリ２２８に置くように試みる。このアップデート・サーバのメモリから、ソフトウェアが直接ターゲット・コンピュータへとインストールされる。

モニタが、ターゲット２０２、２０８にソフトウェアが適切にインストールされることをチェックし、アップデートされたソフトウェアが正しく動作すること、および無関係と思われる領域においてターゲット・コンピュータそのものがいかなる問題にも遭遇しないことを確認するため、チェックを続ける（あるいは通知されることができる）。パッケージが適切にインストールされず、パッチ対象のソフトウェア・プログラムに問題を引き起こし、あるいはターゲット・コンピュータに他の問題を引き起こした場合、パッケージを自動的に除去して、コンピュータをインストール前の状態、またはアップデートが除去または無効にされている他の認容可能な状態に復帰させることができ、ターゲット・コンピュータが動作可能な状態になる。パッケージが１つ以上のコンピュータにインストールされた場合には、それらをすべて取り除くことができる。多数のコンピュータへの配布の途中でエラーが生じた場合には、配布を中断して、当該ソフトウェアを除去または無効化することができる。モニタは、アップデート・サーバ２２０に配置でき、集積所サイト６００に配置でき、少なくとも部分的にアップデート・エージェント２０４、２１０に配置でき、さらに／またはこのような位置の組み合わせに配置することができる。

インストールに問題がある場合、またはインストールに成功した場合、電子メール、ポケットベル、または他の何らかの通知手段で管理者に知らせることができる。

さらに、アップデート・エージェント２０４、２１０を、それら自身のターゲット・コンピュータを調査すべく使用することができ、この情報をオフサイトまたは他の場所のデータベースに保存することができる。次いでこの情報を、所与のターゲット・コンピュータが最も適切な構成をとるためにどのアップデートを必要とするのか判断するために、使用することができる。新規ソフトウェア・パッチが利用可能になったとき、保存されているこの情報を、特定のターゲット・コンピュータが当該パッチを必要とするかどうか判断するために、使用することができる。

ターゲット・コンピュータが、オペレーティング・システムやインストール済みのソフトウェアにかかわらず、あらゆる種類のサーバまたはワークステーションを含むことができる点に、注意すべきである。さらに、本発明の技術的範囲は、無線装置（携帯電話、携帯情報端末、ポケット・コンピュータ、など）、インテリジェント・スイッチ装置、ハブ、ルータ、および他のあらゆる種類のインターネット接続可能な装置など、他の多くの装置にも適用可能である。

本発明の他の態様および利点は、以下の説明を通じてさらに充分に明らかになるであろう。

本発明は、ネットワークを介しての既存のアプリケーションのアップデートを容易にするシステム、方法、物品、および信号を提供する。さらに具体的には、本発明は、クライアント‐サーバ・システムを介してのソフトウェアのアップデートであって、人間による監視の必要がわずかまたは不要であり、アップデート対象のクライアントを抱えるネットワーク上の管理者装置にソフトウェア・パッチのコピーを必要としないアップデートに関する。このアップデートは自動であり、特定のアップデートにおけるエラーを検出でき、ネットワークを使用可能な状態に保つため、不完全なアップデートを自動的に撃退できる。

ここで説明する別個の図面は、本発明の種々の実施の形態を示しているが、所与の図についての説明は、必ずしも特定の種類の実施の形態に限定されない。例えば、当業者であれば、本発明の方法を、本発明による構成された記憶媒体および／またはコンピュータ・システムの実装において使用できることを、理解できるであろう。無用な繰り返しを避けるため、方法についての説明が、そのようでないと示されない限りは物品およびシステムにも当てはまり、逆もまた然りである。また、請求項を適切に解釈したときに特定のステップまたはコンポーネントが必要とされておらず、かつ／または特定の実行順序が必要とされていない限りにおいて、方法の各ステップおよびシステムの各コンポーネントを、名称変更でき、再編でき、繰り返すことができ、あるいは省略できること、および方法の各ステップを異なる順序にすることができ、さらに／あるいは重なり合うように実行できることも、理解できるであろう。

読者に都合がよいよう、ネットワークおよびファイアウォールなどの関連技術についての幾らかの関連情報を、以下に提供する。本発明は、すでに公知の技術を超えるものであるが、コンピューティングおよびネットワーキングにおけるこれまでの進化を部分的に含み、あるいはコンピューティングおよびネットワーキングにおけるこれまでの進化に部分的に依拠することができ、さらに／またはそのようなこれまでの進化とともに使用することができる。

（システムの概要）
図１に示すように、セキュア・コンピュータ・ネットワーク１０２、１０４などのコンピュータ・ネットワーク１００を、本発明によって構成することができる。例として、適当なコンピュータ・ネットワーク１００、１０２、１０４には、ローカル・ネットワーク、広域ネットワーク、および／またはインターネットの一部分が含まれる。ここで使用されるとき、「インターネット」は、プライベート・インターネット、セキュア・インターネット、付加価値通信網、仮想プライベート・ネットワーク、またはイントラネットなどのさまざまなバリエーションを含む。セキュア・ネットワークは、ファイアウォール・ソフトウェア１１６、１１８、ルーティングの制限、暗号化、仮想プライベート・ネットワーキング、および／または他の手段によって定められるセキュリティ境界によって保護することができる。さらに、ネットワーク１００、１０２、１０４は、内部でＴＣＰ／ＩＰおよび／またはＨＴＴＰプロトコルを使用するローカル・エリア・ネットワークなどのセキュア・ネットワークであるセキュア・イントラネットを含んでもよく、セキュア・イントラネットで構成されてもよい。本発明によって動作すべくネットワークによって接続されるコンピュータ１１０は、ワークステーション１１４、ラップトップ・コンピュータ１１２、切り離しが可能な携帯型のコンピュータ（ＰＤＡや他の無線装置など）、サーバ、コンピューティング・クラスタ、メインフレーム、またはこれらの組み合わせであってよい。コンピュータのハードウェアは、汎用、専用、スタンドアロン、および／または組み込み式であってよい。ネットワーク１００は、１つ以上のＬＡＮ、広域通信網、無線ネットワーク（赤外線ネットワークを含む）、インターネット・サーバおよびクライアント、イントラネット・サーバおよびクライアント、またはこれらの組み合わせなど、それら自身のファイアウォールによって保護されうる他のネットワークを含むことができる。

所与のネットワーク１００は、例えば、ＮｏｖｅｌｌＮｅｔｗａｒｅ（登録商標）ネットワーク・オペレーティング・システム・ソフトウェア（ＮＥＴＷＡＲＥはＮｏｖｅｌｌ社の登録商標である）、ＮｅｔＷａｒｅコネクト・サービス、ＶＩＮＥＳ、ＷｉｎｄｏｗｓＮＴ（登録商標）、Ｗｉｎｄｏｗｓ９５（登録商標）、Ｗｉｎｄｏｗｓ９８（登録商標）、Ｗｉｎｄｏｗｓ２０００（登録商標）、ＷｉｎｄｏｗｓＭＥ（登録商標）、ＷｉｎｄｏｗｓＸＰ（登録商標）、Ｗｉｎｄｏｗｓ２Ｋ３（登録商標）、ＬＡＮマネージャ、またはＬＡＮｔａｓｔｉｃネットワーク・オペレーティング・システム・ソフトウェア、ＵＮＩＸ（登録商標）、ＴＣＰ／ＩＰ、ＡｐｐｌｅＴａｌｋおよびＮＦＳベースのシステム、分散コンピューティング環境ソフトウェア、および／またはＳＡＡソフトウェアを含みうる（ＶＩＮＥＳは、Ｂａｎｙａｎシステムズ社の商標であり、ＮＴ、Ｗｉｎｄｏｗｓ９５（登録商標）、Ｗｉｎｄｏｗｓ９８（登録商標）、Ｗｉｎｄｏｗｓ２０００（登録商標）、ＷｉｎｄｏｗｓＭＥ（登録商標）、ＷｉｎｄｏｗｓＸＰ（登録商標）およびＬＡＮマネージャは、マイクロソフト社の商標であり、ＬＡＮＴＡＳＴＩＣは、Ａｒｔｉｓｏｆｔ社の商標であり、ＳＡＡはＩＢＭ社の標章である）。ネットワークは、ゲートウェイまたは同種の機構を通じて他のネットワークに接続できるローカル・エリア・ネットワークを含むことができる。

本発明による１つのシステムは、ネットワーク信号線１０８で１つ以上のネットワーク・クライアント１１０に接続される１つ以上のサーバ１０６を備えている。サーバおよびネットワーク・クライアントは、当業者であれば、本発明に従って動作するように幅広いさまざまなやり方で構成できる。サーバは、インターネット・サーバとして、イントラネット・サーバとして、ディレクトリ・サービス・プロバイダまたはネーム・サーバとして、ソフトウェア・コンポーネント・サーバとして、ファイル・サーバとして、あるいはこれらおよび他の機能の組み合わせとして、構成することができる。サーバは、単一プロセッサ機であってもよく、マルチ・プロセッサ機であってもよい。サーバ１０６およびクライアント１１０はそれぞれ、ランダム・アクセス・メモリなどのアドレス可能な記憶媒体、および／または磁気ディスクや光ディスクなどの不揮発性の記憶媒体を備えている。信号線１０８は、ツイストペア、同軸、または光ファイバ・ケーブル、電話線、衛星、マイクロ波リレー、変調ＡＣ電力線、および無線接続を含む当業者にとって公知の他のデータ伝送「線」を含むことができる。本発明による信号は、そのような「線」および／またはアドレス可能な記憶媒体に具現化できる。

ネットワーク・クライアント・コンピュータに加え、プリンタ、ディスクのアレイ、および他の周辺機器を、特定のシステムに接続することができる。所与のコンピュータが、クライアント１１０およびサーバ１０６の両者として機能でき、これは、例えばマイクロソフト社のＷｉｎｄｏｗｓＮＴ（登録商標）ソフトウェアを実行しているコンピュータ上で生じうる。特定の個体およびネットワーク・コンピュータ・システムならびにコンポーネントについて言及したが、当業者であれば、本発明が他のさまざまなネットワークおよびコンピュータにおいても機能することを、理解できるであろう。

本発明の適切なソフトウェアおよび／またはハードウェアの実装は、本明細書に示す教示を使用し、さらにＪａｖａ（登録商標）、Ｐａｓｃａｌ、Ｃ＋＋、Ｃ、Ｐｅｒｌ、シェル・スクリプト、アセンブリ、ファームウェア、マイクロコード、論理アレイ、ＰＡＬ、ＡＳＩＣ、ＰＲＯＭ、および／または他の言語、回路、またはツールなどのプログラミング言語およびツールを使用して、当業者によって容易にもたらされる。
（構成された媒体の概要）
サーバ１０６およびネットワーク・クライアント１１０ならびに個々のコンピュータ１１０、１１４は、記憶媒体を読み出すためにフロッピー（登録商標）・ドライブ、テープ・ドライブ、光学ドライブ、または他の手段を使用することができる。適切な記憶媒体には、磁気、光学、または他のコンピュータで読み出し可能な記憶装置が含まれる。適切な記憶装置には、フロッピー（登録商標）・ディスク、ハード・ディスク、テープ、ＣＤ−ＲＯＭ、ＰＲＯＭ、ＲＡＭ、および他のコンピュータ・システム記憶装置が含まれる。基礎構成が、コンピュータ・システムを本明細書に記載するとおりの特定の予め定められたやり方で動作させるデータおよびインストラクションを提示する。このように、媒体は、本明細書に事実上記載するとおりに本発明のアップデート、監視、管理、および／または他のステップを実行するため、サーバおよび／またはネットワーク・クライアント・コンピュータおよび／または個々のコンピュータで実行できるプログラム、機能、および／またはインストラクションを、実体として具現化する。

（ファイアウォール）
ネットワーク管理者は、一般に、彼らのシステムに手当たり次第に情報が入ることを許さない。彼らは、むしろ、ネットワークを保護するためにファイアウォール１１６、１１８を使用する。ファイアウォールは、入ってくるメッセージを（内容、起源、または要求の性質にもとづくことがしばしばであるが）選別するハードウェア装置および／またはソフトウェア装置であり、安全であると判断されるメッセージについてのみ通過を許容する。ファイアウォールの主な３つの種類は、スクリーニング・ルータ（パケット・フィルタとも呼ばれる）、プロキシ・サーバ回路レベル・ゲートウェイ、およびプロキシ・サーバ・アプリケーション・レベル・ゲートウェイである。スクリーニング・ルータは、ドメイン名やＩＰアドレスなどのネットワーク・パケットについての外部情報の判定にもとづくことができ、条件に合うドメイン名およびＩＰアドレスからのメッセージの通過１２０、１２４を許すことができる一方で、他の場所１２２からのメッセージを拒絶する。プロキシ・サーバ回路レベル・ゲートウェイは、情報が外部のシステムへと渡されるとき、内部システムに関する情報を隠す。通常は、内部のコンピュータのＩＰアドレスが、プロキシのＩＰアドレスで置き換えられる。このレベルにおいて、認証を要求することができる。プロキシ・サーバ・アプリケーション・レベル・ゲートウェイは、スクリーニング・ルータおよび回路レベル・ゲートウェイの特徴のすべてを提供しつつ、さらにパケットそのものの中身の評価を可能にする。メッセージを、中身ならびにセキュリティ違反に関して拒絶することができる。

（ソフトウェアのインストール）
システム管理者が、特定の装置上のソフトウェアを変更しなければならない場合がしばしばある。新しいアプリケーションを装置に追加する場合など、まず新しいソフトウェアがインストールされなければならない。特定の装置に既存のソフトウェアの新しいバージョンがインストールされるときなど、すでにインストールされているソフトウェアをアップデートでき、これはソフトウェアの「置き換え」とも称される。経理プログラムにおいて税率表がアップデートされる場合や、ウイルス対策ソフトウェア・ファイルがアップデートされる場合など、ソフトウェアの構成を変えることなく、既存のソフトウェアのデータ・ファイルをアップデートすることができる。既存のソフトウェアに問題が見つかった場合には、フィクスまたはパッチをインストールすることができる。特定の装置の状態についてのこれらの変更のいずれかまたはすべてが、この特許において「インストール」と称される。同様に、「パッケージ」、「パッチ」、および「アップデート」といった用語には、可能な限り広い意味が与えられるべきである。例えば、パッケージは、必要なすべてのファイルを含むプログラム全体、１つ以上のデータ・ファイル、既存のファイルへのソフトウェア・パッチ、構成ファイルの変更、＊．ｄｌｌファイル、ならびにコンピュータおよび／またはコンピュータ・ネットワークに取り付けられた特定のハードウェアのためのドライバ・ファイルなどを指すことができる。「アップデート」は、少なくともコンピュータにパッケージをインストールしようと試みることを指す。

（方法の概要）
図３、４、および５を参照すると、本発明に従って動作する方法の一実施の形態は、アップデート前状態にあるターゲット・コンピュータ５００を含んでいる。ターゲット・コンピュータ５００は、本発明が少なくともアップデートを試みようとするコンピュータであり、本発明のすべての実施の形態がアップデートの成功を必要とするわけではない。アップデート・サーバ５２８が、ネットワーク５２４を介してターゲット・コンピュータへと接続されている。いくつかの実装例においては、ターゲット・コンピュータが、ｗｉｎｓｏｃｋ層を通じての接続などのネットワーク接続を有している。通常は、ターゲット・コンピュータは、すでに述べたようにファイアウォール５２６によって保護されているが、アップデート・サーバは、ファイアウォールを通過してターゲット・コンピュータにアクセスすることができる。

既存の多くの事業用ソフトウェア管理ツールは、エージェントを使用している。例としては、マイクロソフト社のＳＭＳソフトウェア、マイクロソフト社のＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙソフトウェア、ＩＢＭ社のＴｉｖｏｌｉという製品、シマンテック社（Ｓｙｍａｎｔｅｃ）のウイルス対策ソフトウェア、マカフィー社（ＭｃＡｆｅｅ）のウイルス対策ソフトウェア、およびＮｏｖｅｌｌ社のＺＥＮｗｏｒｋｓソフトウェアが含まれる（いずれも各社の標章である）。巨大なネットワークにおいて、エージェントは、報告すべき情報を有しているとき、目を覚まして並列にサーバへと報告することができる。対照的に、エージェントを使用しないツールは、サーバによって継続的にポーリングされるリモートＡＰＩコールに依存し、好ましい実施の形態に見られるように、並列処理よりもむしろ、それらを性能について線形に拡大可能にしている。

本発明の実施の形態におけるエージェントは、ネットワークの帯域幅を節約するため圧縮されたファイルを受け取ることができる。圧縮は、解凍エラーがパッチが改竄されていることを知らせてくれる可能性があるため、セキュリティも向上させる。

エージェントを使用しないパッチ管理ツールと異なり、本発明のエージェントは、当該エージェントが載せられている携帯可能なターゲットがネットワークから切り離され、他の場所で再度接続されたとき、ダウンロードを再開することができ、したがって中断後にサービス・パックまたはファイルの全体をダウンロードすることができる。さらに、エージェントを使用しないツールは、パッチが展開されるときに帯域幅の利用に制御不能な急増を生み出す可能性があるが、本発明のいくつかの実施の形態によれば、アップデート・サーバを管理者によって制御し、サーバが各エージェントとの接続に所定の量の帯域幅しか使用しないようにすることができる（帯域幅の絞り）。

恒久的なＬＡＮ／ドメイン接続に依存しクライアント・エージェントを備えない従来のパッチ・ツールは、リモート・コンピュータにレジストリ情報を提供するリモート・レジストリ・サービスに依存するかもしれない。リモート・レジストリ・サービスは、Ｗｉｎｄｏｗｓ（登録商標）９５、Ｗｉｎｄｏｗｓ（登録商標）９８、またはＷｉｎｄｏｗｓ（登録商標）ＭＥといったプラットフォームでは利用することができない。このようなサービスは、リモート・コンピュータがクライアントのレジストリを読み出すことを許し、したがって侵入またはクライアントのセキュリティに対する他の攻撃を案内するために使用できる情報を提供することになるため、クライアント・コンピュータがインターネット上にある組織において、セキュリティ上のリスクとなりうる。本発明の実施の形態は、このセキュリティ上のリスクゆえ、好ましくはリモート・レジストリ・サービスの使用を回避する。

アップデート・エージェント５０８は、アップデートされるべきコンピュータのそれぞれに位置している。アップデート・エージェントは、従来からの手法または本発明を使用し、ワークステーションおよび／またはサーバなどのネットワーク・ターゲット装置に最初にインストールされるソフトウェア・コンポーネント（それほど大きくない）である。アップデート・エージェントは、人間の管理者の指示において人間の管理者の代わりに働き、人間の管理者が実際に当該装置に存在する場合に行われるものと同様のやり方で、作業を実行することができる。アップデート・エージェントは、４つの基本的タスクを如何に実行するのか、すなわち１）タスクのリストを取り出すべくどのようにアップデート・サーバ５２８に連絡するのか、２）受け取ったタスク・リスト内のタスクをどのように開始するのか、３）動作等の時間のためにポリシー情報をどのように処理するのか、および４）どのようにアップデート・サーバに登録するのかを、了解している。

アップデート・エージェントは、最初のインストールののち、手動の介在を必要とすることなく自身をアップデートし、設定し、あるいは置き換えることができる。通常は、小さなブートストラップ・エージェントが最初にインストールされるが、管理者の指示するとおり、あるいは管理者の要求を満足するために必要なとおり、能力が成長するであろう。オフサイトの管理者コンピュータ、サーバ・コンピュータ、およびクライアント装置など、異なる種類のターゲット・コンピュータ５００のアップデート・エージェントは、すべて同じバージョンのただ１つのエージェントから出発することができる。所与のネットワーク内の装置が、すべて同じエージェントをインストールして有することができ、あるいは各装置が固有のエージェントをインストールして備えることができる。２つ以上のクライアントが存在する場合、管理者によって選択されるとおり、あるいは初期設定として設定されるとおり、それぞれが最初に異なるアップデート・エージェントを有することができ、あるいはエージェントの混合を異なるクライアント装置にインストールすることができる。同様に、複数のサーバおよび管理者が、異なるエージェントの混合を最初にインストールして備えてもよい。個々のターゲット・コンピュータのエージェントが変化するとき、それらはすべて一斉に変化してもよく、それらが異なってもよい。いくつかの実施の形態においては、エージェントがすべて異なって出発し、次いで機能において収束してもよい。

アップデート・サーバ５２８のオフサイト位置は、ターゲット・コンピュータとは異なる位置である。この位置は、完全に別のベンダにおいてオフサイトであってよく、ターゲット・コンピュータ５００と物理的に異なる位置であるが同じ物理的位置の同じ団体によって管理される位置においてオフサイトであってもよい。下請け契約者の位置などターゲット・コンピュータ５００から異なって表われる位置にあってもよく、あるいは他のいくつかの別個に表われる位置にあってもよい。重要なのは、個々のターゲット・コンピュータ・オペレーティング・システムに関する限り、作業がオフサイトであるように見えるという点である。一実施の形態では、アップデート・サーバがターゲット・コンピュータ５００に置かれるが、オフサイトに見えるようなやり方で（例えば別のパーティションなどに）配置される。

ターゲット・コンピュータにインストールされるべき実際のアップデート材料は、アップデート・サーバおよびターゲット・コンピュータから離れて、別の場所（パッケージ・コンピュータとして知られている）に保存されることが多い。ソフトウェア・アップデートそのものは、ソフトウェア差分パッチ、ターゲット・コンピュータに未だインストールされていない新規なソフトウェア・プログラム、古いプログラムのアップデート、ソフトウェア・スクリプト、データ・ファイル、あるいはアップデート・エージェントのアップデートなど、ネットワークを横断してアップデートされうる幅広い種類の任意のソフトウェアであってよい。

公知の条件が満足されると、配置ステップ３００において、タスクＩＤがアップデート・タスク・リスト２２２に置かれる。公知の条件とは、パッチがコンピュータ上に現在ないこと、管理者が同意を与えたこと、ターゲット・コンピュータ５００の所有者がパッケージの所有者からの許可を有していること、配置特権を明確に否定する者が存在しないこと、あるいは他の公知または新規の条件でありうる。アップデート・サーバに位置するアップデート・タスク・リストは、特定のターゲット・コンピュータ５００に関連付けられており、ソフトウェア・アップデートを見つけることができる少なくとも１つのダウンロード・アドレスを指定している。このダウンロード・アドレスは、コンピュータにとって理解できる任意の形式であってよい。本発明は、決して特定のアドレス指定の約束事には依存しない。現在一般的に使用されている２つのアドレス指定フォーマットは、「ＵＲＬ（ＵｎｉｖｅｒｓａｌＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）」および「ＥＱＤＮ（ｆｕｌｌｙｑｕａｌｉｆｉｅｄｄｏｍａｉｎｎａｍｅ）」フォーマットである。他のフォーマットは、ＰＵＲＬ（ＰｅｒｓｉｓｔｅｎｔＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）およびＵＲＮ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＮａｍｅｓ）、および将来において公知になるであろう他の呼称の仕組みである。タスク識別子に含まれるであろう他の情報は、最初にダウンロードが試みられる日付などである。それぞれがソフトウェア・アップデートを見つけることができる場所を指定している複数のダウンロード・アドレスを、すべて特定のソフト・アップデートに関連付けることができる。

タスク開始ステップ３０４において、パッケージ・コンピュータ５６７からアップデート・サーバ５２８へのソフトウェア・アップデートのアップロードが、少なくとも試みられる。２つ以上のダウンロード場所がタスクＩＤリスト２２６に存在するならば、随意によるパッケージ・コンピュータ選択ステップ３０６において、どの場所からソフトウェア・アップデートをダウンロードするかが選択される。この選択は、リスト上の最初の場所を利用する、テスト用のメッセージが最も素早く返送されてくる場所を利用する、最初に利用できる装置を使用するなど、公知または新規の任意の方法によって行なうことができる。

ひとたびアップデートのための場所が知られると、パッケージ・コンピュータ５４８の場所からアップデート・サーバ５２８のメモリ５３０へと、ソフトウェア・ダウンロードが試みられる。ダウンロードが成功しなかった場合、本発明の一方法においては、タスク・アップデート・リスト内の可能性のある場所のリストから他の場所が選択され、ソフトウェア・アップデートのダウンロードが再度試みられる。いくつかの実装例においては、何らかの理由でダウンロードを完了できなかった場合、アップデート・サーバ５２８は、或る時間待機し、再度パッケージ・コンピュータ５６７からのダウンロードを試みる。ダウンロードが成功した場合、次いでアップデート・サーバ５２８は、当該ソフトウェア・アップデートのターゲット・コンピュータ５００へのダウンロード３１２を試みる。

ひとたびダウンロードがアップデート・コンピュータのキャッシュまたは他のメモリに入ると、当該ソフトウェア・パッケージをアップデート・サーバからターゲット・コンピュータへとダウンロードするため、第２のダウンロード３１２が試みられる。この方法のいくつかの実施の形態では、第２のダウンロード３１２が、或る所定の条件によって遅延３１０させられる。この遅延は、第１のダウンロードの開始からであってよく、遅延期間は、パッケージ・コンピュータからアップデート・サーバへとソフトウェア・アップデートをダウンロードするために要する時間の推定にもとづくことができる。第２のダウンロードを、その日の業務が終了した後など、一日のうちでターゲット・コンピュータ５００が使用されている機会が少ない特定の時間まで、遅延させてもよい。他の公知または新規の遅延条件を使用することも可能である。

モニタ３０２が、通常は管理者によって行われる役割を実行してインストールを確認し、インストールの結果の判断３１４を行なう。ひとたび結果が知られると、管理者に通知３２８を行なうことができる。通知は、電子メールの送信３３０によることができ、誰かをポケットベルで呼び出すことによることができ、あらかじめ録音された電話メッセージの送信によることができ、あるいは他の任意の公知または新規の方法および手段によることができる。

モニタ・ステップにおいて失敗３１６が検出されたとき、失敗に終わったタスクは一時的に保留３１８される。アップデート・サーバ５２８への第１のダウンロード３０８が失敗しうるのと同様、アップデート・サーバ５２８からターゲット・コンピュータ５００への第２のダウンロードも失敗しうる。ソフトウェア・アップデートがインストールされるターゲット・コンピュータが複数存在する場合、Ｎ番目のインストールが失敗する可能性があり、以下同様である。結果の判断は、ソフトウェア・アップデートが適切にインストールされたと見られることの単なる確認を越えると好ましく、本発明のいくつかの実施の形態においては、インストールを越える時間にわたって広がる。例えば、モニタの一実施の形態は、パッチ・アプリケーションをただ１つのターゲット・コンピュータにのみインストールし、それが適切にダウンロードされ、インストールされることを確認し、次いで時間遅延を設定する管理者が当該パッチについてその他のターゲット・コンピュータへの適用を許してもよいという充分な確証を得るまで或る時間間隔にわたって監視することによって、パッチ・アプリケーションをテストする。このパッチの適用が、ソフトウェアの変更がなされたプログラムまたはコンピュータのどこかにおける望ましくない挙動によって知らされるとおり異常な動作を生じさせる場合、その問題が解決されるまで広範な適用を自動的に差し止めることができる。

さらに、失敗が検出された幾つかの場合においては、ソフトウェア・アップデートが無効にされ、あるいはターゲット・コンピュータから除去３２４され、当該装置が事実上アップデート前の状態に戻され、あるいは他の認容可能な（動作する）非アップデート状態に戻される。これは、インストールされたソフトウェアをターゲット装置から除去３２２することを意味し、あるいはソフトウェアを取り除くだけでなく、すべての付属ファイル（．ｄｌｌ、．ｅｘｅ、など）がそれぞれアップデート前の状態に戻されることを意味しうる。他の場合には、ターゲット・コンピュータまたはその或る部分が、ソフトウェア・アップデートがインストールされる前にバックアップされ、このバックアップそのものが当該装置に戻されることを意味しうる。

複数のターゲット・コンピュータ５００が存在する場合、ソフトウェアが１つ以上の装置にインストールされたのちに、モニタが失敗を検出するかもしれない。この場合、ソフトウェア・アップデートを、失敗が観測されたターゲット・コンピュータ５００から除去３２２するだけでなく、当該ソフトウェアがすでにインストールされた他のすべてのターゲット・コンピュータ５００からも除去３２６することができる。除去の要求は、管理者からもたらされてもよく、あるいは失敗が検出３１６された後に除去を自動的に実行してもよい。

モニタ３０２が、単にソフトウェア・パッケージのインストールが成功したか否かの報告を待つ以上のタスクを実行してもよい。例えば、幾つかの場合には、モニタがインストール後に或る時間間隔４００にわたって待機し、否定の連絡を受け取らなかった場合に、インストールが成功したと判断してもよい。

管理者および管理者の補佐人は、彼らが進入してヘルプの要求に関する情報を引き出すことができる中央の集積所から、大きな利益を受け取ることができる。そのような方法の１つは、ヘルプ・デスク「発券」である。発券は、要求者、要求の種類、ヘルプが要求された時、要求への応答が完了した時、および他の有用な情報を記録する。ＰａｔｃｈＬｉｎｋＨｅｌｐＤｅｓｋサービスが、管理者に、彼らのネットワーク要求および人的資源およびコンピュータ資源の両者のネットワーク資源を、中央の集積所を介して管理するための機能を提供する。ＰａｔｃｈＬｉｎｋＨｅｌｐＤｅｓｋソフトウェアは、これらの機能を、管理者のネットワークに管理、バックアップ、およびアップデートしなければならないさらなる資源を導入する侵襲的なアプリケーションをインストールすることなく、インターネットを介して提供し、これはオフサイトの管理センターにおいてユーザに気づかれることなく処理される。

標準的なウェブ・ブラウザあるいは他の公知または新規なネットワーク接続によって到達できるウェブサイトが、ヘルプ・デスク・サービスを利用するための機能をもたらす。好ましい実装例は、現在ＰａｔｃｈＬｉｎｋ社のウェブサイトにあり、ｗｗｗ．ｐａｔｃｈｌｉｎｋ．ｃｏｍで到達できる。簡潔なウェブ形式が、登録プロセスを開始するために必要なデータ採取をサポートする。ひとたび登録プロセスが完了すると、管理者は、繰り返しの申し込みにもとづいて１つ以上のサービスをライセンスすることができる。

登録プロセスは、管理者がサインアップして所望の参加レベルを指定することによってプロセスを開始させるときに開始される。本発明の好ましい実施の形態は、ゲスト、レギュラー、およびエグゼクティブという３つの異なるユーザ・レベルを有している。ゲストは、ウェブサイトの閲覧を許され、ユーザ・フォーラムを読むことができるが、フォーラムへと投稿することはできない。レギュラー・メンバは、ゲストの機能を実行でき、さらにチャット・ルームでチャットを行なうことができ、フォーラムに投稿することができる。エグゼクティブ・メンバは、サイトへの会費を有している。エグゼクティブ・メンバは、レギュラー・メンバの機能を実行することができ、さらにオフサイトの自動パッケージ・アップデート（例えば、ＰａｔｃｈＬｉｎｋＵｐｄａｔｅサービス）、オフサイト監視（例えば、ＰａｔｃｈＬｉｎｋＭｏｎｉｔｏｒサービス）およびオフサイトのヘルプ・デスク機能（例えば、ＰａｔｃｈＬｉｎｋＨｅｌｐＤｅｓｋサービス）など、サイトのより進んだ特徴を使用することができる。

この方法の一実施の形態は、顧客の電話加入区域コードに割り当てられた顧客ケア・エージェントへと、電子メールが送信されることを必要とする。顧客ケア・エージェントが、登録プロセスを完了するため係属中のユーザへと電話する。顧客ケア・エージェントが、必要な識別情報および支払い情報を収集し、次いで継続中のユーザのアカウントを、当該アカウントの使用を許可するように更新し、係属中のユーザを管理者／ユーザにする。管理者／ユーザの参加または利用できる範囲は、アップデート・ホストのデータベースのライセンスされた製品の表のエントリによって制御される。これらのエントリは、登録プロセスの際に顧客ケア・エージェントによって生成される。

これらのサービスのすべてが、管理者にとって、ブラウザまたはインターネットを横断する他のネットワーク接続を介して利用可能であることを、思い出すべきである。モニタがヘルプ・デスクにチケットを入力し、本発明の方法の幾つかの実証において頒布を開始したとき、次にモニタは、失敗が発生３１６、４０６したか否かを判断する。判断のため、モニタは、どのソフトウェア・アップデートが最近インストールされたのか、そのインストールがどのくらい前に行われたのか、現在のハードウェアおよびソフトウェア構成はどのようであるか、などを調べる。どのような出来事が失敗と考えられるかについては、制限はないが、管理者によって設定することができ、初期設定を使用でき、ヘルプ・デスク職員の判断を考慮に入れることができる。

アップデート・サーバからターゲット・コンピュータへのダウンロードが成功裏に完了したのち、成功検出ステップ４０８において、ターゲット・コンピュータ５００が、アップデート・サーバにメッセージ４１０を送信する。モニタは、失敗に気付かない場合、または失敗を知らされることなく指定の時間期間が経過した場合に、成功４０４したものと推定することができる。

他のやり方３１６、４０６で失敗を検出することもできる。例えば、ターゲット・コンピュータが、失敗が生じたことをモニタに知らせることができる。ユーザが、ヘルプ・デスクまたは直接リンクを通じて、失敗が生じたことをモニタに知らせることができる。ターゲット・コンピュータがターゲット装置への第２のダウンロード３１２の開始から指定の時間内にモニタに連絡をしないとき、人間である管理者が失敗が生じたことを宣言できる。モニタがダウンロードの結果が成功であると宣言したのちであっても、ヘルプ・デスクからの失敗の知らせなどの後のイベントが、モニタにダウンロード失敗の宣言を行なわせることができる。

本発明の一実施の形態においては、アップデート・サーバ５２８が、次のターゲット・コンピュータ５００がアップデート・リスト２２２に置かれたソフトウェア・アップデートを有する前に、インストール成功の確認（モニタ、あるいは他の公知または新規な連絡方法による）を待つ。アップデート・サーバが、当該ソフトウェア・アップデートについて適格であるが当該ソフトウェア・アップデートを未だ受け取っていないターゲット・コンピュータ５００をチェック４１２する。それが発見４１４された場合、当該ターゲット装置、ソフトウェア・アップデート、および場所を指定する適切なタスク識別子が、アップデート・サーバ５２８のタスク・アップデート・リストに追加４１６される。このようにして、適格なコンピュータのすべてに一斉にソフトウェアがインストールされるマス・アップデートではなく、頒布が一度に１台のコンピュータにて進められ、初期設定またはユーザ設定数のインストールが成功したのち、頒布は成功したものと判断され、その場合にソフトウェア・アップデートが２つ以上のターゲット・コンピュータにとって同時に利用可能になる。

どのソフトウェア・パッケージまたはパッチがインストールされているのか、特定のターゲット・コンピュータ５００を調べることによって常に明らかになるわけではない。本発明は、本発明によって所与のパッチのインストールを試みる前に、ターゲット・コンピュータ５００を分析して、当該パッチがコンピュータ５００に未だインストールされてないことを確認する方法を含んでいる。以下の説明では、図８および９を参照するとともに、引き続き図５も参照する。

特定のソフトウェア・アップデートを定めるパッチ・フィンガプリントについて、以下で詳しく説明する。パッチ・フィンガプリントは、新規パッチ・フィンガプリント９０２についてのパッチ・コンポーネント・データベース位置９００を監視することによって所在確認８００される。ここで「新規」という用語は、当該パッチが未だ集積所コンポーネント６００へとダウンロードされておらず、あるいはすでにダウンロードされたにもかかわらず、何らかの理由で集積所コンポーネントへと再度ダウンロードされる必要があることを示している。１つ以上のパッチ・コンポーネント位置が存在してもよく、それらの位置は、ネットワーク・リンクによってシステムに接続された別のコンピュータ上、アップデート・サーバ５２８上、ターゲット・コンピュータ５９９上、パッケージ・コンピュータ５６７上、またはＣＤ、テープ、フロッピー（登録商標）・ディスクなどのネットワークではない位置、あるいは何か他の公知または新規な位置にあってよい。

ひとたびパッチ・フィンガプリント９０６が所在確認８００されると、それは集積所コンポーネント６００へと配置８０２される。通常の配置方法は、パッチ・フィンガプリント９０６を集積所コンポーネントへとダウンロード８０４することであるが、幾つかの実施の形態においては、フィンガプリント９０６が同じファイル・システム上にあり、パッチ・フィンガプリントが、パーティション間のコピーなど、ネットワークを使用せずにコピーされる。

図示のパッチ・フィンガプリントは、装置に特定のパッチをインストールできるか否かを調べるための高レベルの調査に使用することができる１つ以上の一般備品インストール依存関係９１２を含んでいる。さらに、ターゲット・コンピュータ５００からの特定の情報を要求するために使用できる署名ブロック９１０、および装置に特定のパッチがロードされているか否かを判断するために署名ブロック情報を使用できる存在テスト９０８も含まれている。

本発明の幾つかのバージョンにおいては、備品インストール依存関係９１２が、ターゲット・コンピュータ５００にインストールされていなければならない必要なソフトウェアおよびハードウェアの少なくとも幾つかを記載している。これらの依存関係９１２は、目録ライブラリ９１８に前もって保存されているターゲット・コンピュータ８０６についての情報と比較８０８される。インストール情報と目録情報が一致しない場合、パッチはインストールされていない。本発明の幾つかのバージョンにおいては、少なくとも１人の管理者にインストールのために必要とされるコンポーネント（必要なハードウェアおよびソフトウェアなど）のリストを含んでいるメッセージが送信される。

必要な目録情報がターゲット・コンピュータ５００上にある場合、あるいは目録情報が使用されていない場合、署名ブロックが集積所コンピュータ６００からターゲット・コンピュータ５００へと送信８１０される。署名ブロック８１４にて要求された情報は、より詳細なインストール情報で構成されてもよいが、発見エージェント５４８によって収集８１２され、次いで集積所コンポーネント８１８へと送り返される。本発明の幾つかのバージョンにおいては、発見エージェントが、利用統計、インストール済みのハードウェアおよびソフトウェア、ならびに設定など、ターゲット・コンピュータについての他の情報も収集する。次いでこの情報を、目録ライブラリ９１８を豊かにすべく使用することができる。

ひとたび署名情報９１０が集積所コンポーネント６００へと送信されると、評価器９１４が、署名ブロックによって要求された特定のインストール情報の少なくとも一部分を、存在テスト９０８および幾つかの場合には備品インストール情報９１２を使用して評価し、ターゲット・コンピュータ５００上にパッチが存在しない８２２かどうか判断する。

随意によるステップとして、パッチが存在しないかどうかを判断したのちに、管理者に関連付けられた少なくとも１つのアドレスにメッセージが送信８２４される。このメッセージは、電子メール、ポケットベル、ファクシミリ、ボイスメール、インスタント・メッセージング、ＳＮＭＰ通知、などを含むさまざまな方法を使用して送信することができる。

（パッチ・フィンガプリント）
引き続き図５、８、および９を参照すると、本システムの一実施の形態は、インストールを試みる前に、所与のターゲット・コンピュータ５００についてソフトウェア・パッケージをインストールできること、またはインストールすべきであることを検証する。そのようにするため、例えばクライアント上のエージェントによってパッチ・フィンガプリント９０６が使用される。パッチ・フィンガプリントは、所与のソフトウェア・パッケージ／差分パッチがすでにインストールされているか否かをどのように判断するのかを定めている。また、パッチ・フィンガプリントが、パッチのインストールに必要な最小のハードウェア／ソフトウェア構成を定めてもよい。これらのパッチ・フィンガプリント９０６は、フィンガプリント・ライブラリ９０４に保存される。フィンガプリント・ライブラリ９０４は、集積所コンポーネント６００に位置している。この集積所コンポーネント６００は、アップデート・サーバ５２８に位置することができ、あるいはアップデート・サーバ５２８およびターゲット・コンピュータ５００にとってアクセス可能な別の位置に位置することができる。さらに、本発明の幾つかのバーションは、ターゲット目録を含む目録ライブラリ９１８を備えている。ターゲット目録９２０のそれぞれは、ターゲット・コンピュータ５００の所定の組についてのハードウェアおよびソフトウェア情報を含んでいる。この所定の組は、最も少なくは１台のコンピュータを含み、最も多くは所与のネットワーク内のすべてのコンピュータを含み、あるいは両者の間の或る数のコンピュータを含むことができる。

フィンガプリント・ライブラリ９０４は、自動的に補充できる。幾つかの実施の形態においては、おそらくは複数であるが少なくとも１つのパッチ・コンポーネント・データベース位置９００が、新規パッチ９０２について監視８００される。本発明の幾つかの実施の形態においては、位置９００からの信号が、新規パッチ９０２が利用可能８００であることを集積所コンポーネント６００に知らせる。好ましい実装例においては、フィンガプリント・ライブラリ９０４が、特定の時間間隔で新規パッチ・フィンガプリントについて更新される。集積所コンポーネント６００が新規パッチ・フィンガプリントを知らされたのち、当該パッチ・フィンガプリントが、通常は当該パッチ・フィンガプリントをダウンロードすべくダウンロードローダ９２４を使用することによって、集積所コンポーネント８０２に配置される。しかしながら、パッチ・フィンガプリントは、他の方法にて集積所コンポーネントに入れられてもよい。例えば、１つ以上のパッチ・フィンガプリントを、管理者によって手動でフィンガプリント・ライブラリにインストールしてもよい。

（目録ライブラリ）
集積所コンポーネント６００は、さらに目録ライブラリ９１８を含んでいる。発見エージェント５４８が、幾つかの実施の形態においては当初よりアップデート・サーバ５２８上に存在するが、アップデート・サーバ５２８からターゲット・コンピュータ５００へと公知または新規な方法を使用してインストールされる。この発見エージェント５４８は、以下でさらに詳しく説明するが、少なくとも幾つかのターゲット・コンピュータ５００のソフトウェア情報６０６、インストール済みの特定のソフトウェア・アップデートおよびパッチを含むハードウェア情報６０８、利用情報６０４、レジストリ情報６１２、ウェブ情報６１０、設定情報６１４、サービス６１８、ファイル情報、利用されているパッチ署名、などを目録にしている。

次いで、この情報あるいはその部分集合または上位集合が、目録ライブラリ９１８内のターゲット・コンピュータ目録９２０へと、幾つかの実施の形態においては圧縮された形式で送信される。結果情報は、かなりかさばる可能性があるため、効率的なアップロードおよび顧客ネットワークの帯域幅の使用を最小にするため、圧縮することができる。好ましい実装例では、このデータをＸＭＬデータ転送を使用して送信するが、他の任意の公知または新規のデータ転送方法も使用可能である。さらに、目録情報の転送は、望ましくないシステム構成情報のワイヤ・レベルの詮索を防止するため、顧客のネットワーク内で暗号化することができる。

（レポート生成器）
この情報によって、レポート生成器９２２が、ネットワーク内のすべてのコンピュータの現在のパッチ状態についての詳細なレポートを、パッチを必要とするコンピュータの数、すでにパッチがインストールされているコンピュータ、およびハードウェアまたはソフトウェアがアップグレードされるまではパッチを受け取ることができないコンピュータ、などを示しつつ、ユーザに提示することができる。さらに、レポート生成器９２２は、ネットワークに接続されたコンピュータの部分的または完全な目録を提供することができる。幾つかの実施の形態においては、レポート生成器９２２が、ハードウェアの位置の追跡およびソフトウェア・ライセンス遵守の確保の両者のため、管理者による分析のために目録についてのグラフィック表示を提供する。一方で、集積所コンポーネント６００も、関連の署名９１０をパッチ・フィンガプリント９０６から発見エージェント５４８へと配布して、ターゲット・コンピュータ５００における不必要な走査作業を除くことによってパッチ発見プロセスを大幅に最適化するため、目録ライブラリ９１８の情報ならびに検出されたフィンガプリント情報を使用する。
（発見エージェント）
所与のソフトウェア・プログラムまたはパッチがインストール可能であるか否かを判断する最適な１つのステップは、該当する場合に必要なハードウェアが存在すること、および／または必要なソフトウェアが存在することの検証による。例えば、或るプログラムが特定のオペレーティング・システムを必要とするかもしれないし、或るプログラムは或るプロセッサを必要とするかもしれない。一例として、マイクロソフト社のＷｏｒｄソフトウェアのアップデートをインストールする場合、マイクロソフト社のＷｏｒｄソフトウェアが装置上に存在する必要がある。この高レベルの依存関係が、幾つかのバージョンにおいてはパッチ・フィンガプリント内の備品インストール・ブロック９１２に保存される。備品インストール・ブロックの情報は、一般に、目録ライブラリ９１８に保存された特定のターゲット・コンピュータ５００のターゲット目録９２０から引き出されることができるよう、充分に高レベルである。

本発明のいくつかの実装例においては、パッチ・フィンガプリント９０６が、インストール依存関係情報９１２をさらに含んでいる。これは、すでに説明したとおり、目録ライブラリにおいて発見が期待でき、したがってターゲット・コンピュータ５００を照会することなくチェックできるターゲット・コンピュータ５００についての情報である。これは、存在するであろうソフトウェア（特定のバージョンのプログラム、パッチ、データ・ファイル、またはドライバ）、存在するであろうハードウェア・コンポーネント、または存在しないであろう特定のハードウェアおよび／またはソフトウェアを含んでいる。

目録ライブラリがターゲット・コンピュータ５００について最新の目録を有していない場合、発見エージェントを、目録情報を求めてターゲット・コンピュータ５００を走査するために使用できるが、同時に署名情報を求めて走査を行なう必要は必ずしもない。好ましい実装例においては、発見エージェント５４８は、所与のターゲット・コンピュータについて最初に動作するとき、目録情報についてのみ走査を行い、次いでその情報を目録ライブラリ９１８へとロードし、パッチ・フィンガプリント情報は無視する。発見エージェント５４８が動作する他のとき、発見エージェントは、目録情報を無視することができ、むしろ特定のパッチの存在をテストするため特定の署名情報９１０を調べるために使用されることができる。署名ブロック情報が捜索されるとき、レジストリのエントリおよびＩＮＩファイル値などの値を存在について調べることができ、あるいは実際の値を集積所コンポーネント６００へと返すことができる。

各パッチ・フィンガプリントは、署名ブロック９１０および存在テスト９０８を含んでいる。パッチ署名ブロックは情報要求の組であり、情報そのものはターゲット・コンピュータ５００から集められ、必要なすべてのバグ・フィクスおよびセキュリティ・パッチがインストールされているか否かを判断するために使用される。パッチ署名ブロック情報の例としては、これらに限られるわけではないが、ファイル、ハードウェア、レジストリ、および設定情報、特定のファイル名およびディレクトリ名、ファイルが発見されると予想されるパスのすべてまたは一部、ファイルの特定のバージョン番号、ファイルの生成日、ファイルの特定のファイル・バージョン、ならびに特定のレジストリ値が含まれる。

一実装例においては、フィンガプリント・ライブラリ９０４はＳＱＬデータベースである。パッチ署名９１０が、ＳＱＬフィンガプリント・ライブラリから取り出され、備品インストール情報９１２に指定されているオペレーティング・システムおよびインストール済みソフトウェアについての依存関係条件に合致するすべてのターゲット・コンピュータへと送信される。

好ましい実装例は、ＸＭＬベースの要求入力ファイルを使用する。アップデート・サーバ５２８へと返送される結果ファイルも、やはりＸＭＬフォーマットを使用する。この結果ファイルは、ターゲット・コンピュータについての署名情報を含んでおり、さらにソフトウェアおよびハードウェア目録更新を含んでもよい。アップデート・サーバに送られる目録および署名情報は、かなりかさばる可能性があるため圧縮され、好ましい実施の形態においては、さらに暗号化されてもよい。下記は、マイクロソフト社のＯｕｔｌｏｏｋについてのレジストリ情報、ならびにＥＸＥの日時、およびレジストリ内の情報を集めるパッチ署名の一例である。

ひとたびターゲット・コンピュータ上の発見エージェントが署名についての走査結果を返すと、特定のコンピュータが実際にパッチを有しているか否かを推測するため、存在テスト９０８のロジックが評価器９１４によって使用される。このアルゴリズムは、その唯一の職務が集積所コンポーネント６００そのものによるデータ分析の実行を可能にするため情報を発見することにある評価器について、評価器によって行なわれなければならないテストの数を最小限にする。このようなやり方で作業負荷を分散することにより、莫大な数のワークステーションおよびサーバの走査および分析について、より良好な実行がもたらされる。

存在テストはそれぞれ、所与のパッチに特有である。存在テストの一例は、次のようなものであろう。すなわち、レジストリＱＱが値ＺＦＩＬＥＶＡＬを含んでいる場合、または（ファイル＿Ｚ１２３．ｂａｔが２０００年１２月１２日のＰＭ１１：５２に変更され、ファイルＺのサイズがＺＦＩＬＥＳＩＺＥである）場合、パッチＺＰＡＴＣＨが存在する。パッチ・フィンガプリント・ライブラリの好ましい実施の形態は、ＳＱＬデータベースであるが、他の公知または新規なデータベースも使用可能である。

パッチ・フィンガプリントが、さらに他のフィンガプリント定義への依存性を含んでもよいことに注目すべきである。例えば、仮に、「ＭＳ‐０２３ＩＩＳＶｕｌｎｅｒａｂｉｌｉｔｙＦｉｘ」というパッチが「ＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓＳｅｒｖｉｃｅＰａｃｋ２」の存在を必要とすることができる。これは、パッチ署名が実際に送信される場所をさらに最適化するために使用される。これらは、ときには状況に応じて、インストール依存関係情報９１２および署名ブロック９１０内の他の時点において、使用されてもよい。

さらに、フィンガプリント定義９０６は、通常はシステムによる展開に適したソフトウェア・パッケージ５５４に関連付けられる。ひとたびコンピュータまたはネットワーク内のすべてのコンピュータ上の署名を走査することによって特定のパッチの必要性が確認されると、それを管理者によって、単に日時を選択することによって迅速に展開することができる。

さらに、フィンガプリント定義９０６は、パッチ署名内の他の要素を真（パッチされた）または偽（パッチされていない）と判断すべきか否か評価するために評価されるべき論理表現を含んでもよい。表現は、（ＡＡＮＤＢ）│Ｃなどの簡潔な論理記述であり、ここでＡ、Ｂ、およびＣは、パッチ署名内の他のフィンガプリント定義を指している。

幾つかの実装例においては、ダウンローダ９２４が、新規パッチ・フィンガプリントがについてパッチ・コンポーネント・データベースを定期的にチェックする。新規パッチ・フィンガプリントの所在が確認されたとき、それは集積所コンポーネントへとダウンロードされる。評価器が、インストール情報９１２に挙げられた特定のパッチ実行に必要な依存関係を、目録ライブラリに挙げられたターゲット・コンピュータ５００の詳細のそれぞれと比較する。次いで、パッチを必要とするすべてのターゲット・コンピュータ５００、パッチを所有していないすべてのターゲット・コンピュータ、必要な依存関係を有しておりパッチを受け取ることができるすべてのターゲット・コンピュータ、および／またはパッチをすでに受け取ったすべてのターゲット・コンピュータ５００を特定できるアップデート・リストが生成される。今やこのアップデート・リストを、ターゲット・コンピュータをアップデートするために使用することができ、さらに／または通知器９１６によって管理者に送信することができる。

本発明のいくつかの例においては、パッチ・コンポーネント・データベースが、ターゲット・コンピュータ５００の所有者以外の何者かによって所有されている。このパッチ・アップデート・ホストが、ターゲット・コンピュータ５００の所有者への所与の許可を有している場合にのみ、ダウンローダが、新規パッチ・フィンガプリントの集積所コンポーネントへのダウンロードを許される。この許可は、購入契約、ライセンス契約、ダウンロード許可の申し込み、および評価契約を含むことができる。

管理者にとって興味の対象でありうるあらゆる変更が行われた場合、通知器９１６が、利用可能になった新規パッチ・アップデート、または管理者のネットワークの構成において生じたパッチ関連の状態変化を含んでいる通知メッセージを送信する。通知は、電子メール。ポケットベル、電話、ＳＮＭＰブロードキャスト、またはインスタント・メッセージによって送ることができる。

（ターゲット・コンピュータ）
一実施の形態において、本発明のシステムは、ターゲット・コンピュータ５００、アップデート・サーバ５２８、およびパッケージング・コンピュータ５４８という３つの部分からなる。ターゲット・コンピュータ５００は、メモリ５０２、および本発明の少なくとも１つの実装例においてはｗｉｎｓｏｃｋ層であるネットワーク接続５０４を有している。ソケット無しのプロトコルを実装することが可能であり、あるいは他の任意の公知または新規のネットワーク接続を使用することができる。アップデート・サーバ５２８は、随意によりバックアップ記憶装置５３４を含んでもよいメモリ５３０、およびネットワーク接続５３２を有している。パッケージ・コンピュータ５６７は、メモリ５５０、およびネットワーク接続５５２を有している。図５には、便宜上１台のターゲット・コンピュータ５００が示されているが、所与の実施の形態においてははるかに多くのターゲット・コンピュータが存在するであろう。同様に、便宜上１台のアップデート・サーバ５２８および１台のパッケージ・コンピュータ５６７が示されているが、本発明は、ただ１台を必要とするかもしれないが、２台以上もサポートする。好ましい実施の形態においては、これらの部分がすべて別個のコンピュータであるが、これらが別個であると見ることができる同じコンピュータの仮想の部分であってもよい。例えば、「パッケージ・コンピュータ」に部分が、アップデート・サーバの別のパーティションに存在してもよく、同じパーティションに存在してもよい。

ターゲット・コンピュータは、ネットワーク接続５４４を含んでいるが、これは、すでに説明したとおり、ファイアウォール５２６によって外部から保護されることができる。例えば何台かがＷｉｎｄｏｗｓ（登録商標）機であって何台かがＵｎｉｘ（登録商標）機であるなど、１つのネットワーク内の別個のターゲット・コンピュータが、別のプラットフォームで動作してもよい。すべてのプラットフォームについて同じアップデート・サーバ５２８を使用でき、あるいはプラットフォームの種類によって異なるアップデート・サーバ５２８を指定することができ、あるいは別の仕組みを使用してアップデート・サーバ５２８をターゲット・コンピュータ５００に割り当てることができる。

ターゲット・コンピュータ５００は、さらにアップデート・エージェント５０８を含んでいる。アップデート・エージェントは、本発明の方法を使用して複数の装置に同時にインストールできるソフトウェア・コンポーネントであり、あるいは本システムの幾つかの実施の形態においては、従来からのやり方でターゲット・コンピュータ５００にインストールできる。ひとたび登録されると、アップデート・エージェント５０８は、３つの基本的タスクを如何に実行するのか、すなわち１）自身のアップデート・リスト５３６から自身のタスクのリストを取り出すべくどのようにアップデート・サーバ５２８に連絡するのか、２）受け取ったタスク・リスト内のタスクをどのように開始するのか、および３）アップデート・サーバ５２８から受信されポーリング間隔および動作時間などを制御するポリシー情報をどのように取り出すのかを、了解している。

（アップデート・エージェント）
ターゲット・コンピュータ５００のアップデート・エージェントが、エージェント５０８のすべき作業が存在するか否かを判断するため、アップデート・サーバ５２８に連絡する。アップデート・サーバ５２８は、これをエージェントのアップデート・リスト・キュー５３６を分析することによって判断する。このアップデート・リスト５３６は、少なくともソフトウェア場所参照５３８を含んでいるが、さらにソフトウェア・パッケージ５５４をインストールすることができる再選の日付を示す日付５４０を含むことができ、同じソフトウェア・パッケージを複数の場所から入手できる場合には、複数のソフトウェア場所参照を含むことができる。アップデートできるソフトウェア５５４の種類には、これらに限られるわけではないが、現在ターゲット・コンピュータにインストールされているソフトウェア・アプリケーションをアップデートするパッチ・ファイル５５６、データ・ファイル５５８、スクリプト・ファイル５６２、新規アプリケーション・ファイル５６４、実行可能ファイル５６０、ドライバ・アップデート、新規ソフトウェア・バージョン、およびアップデート・エージェント・ファイル５６６そのもののアップデートが含まれる。

アップデート・エージェントが、関連のアップデート・リスト５３６に適切な日付５４０（該当する場合）を有するエントリを発見したとき、インストーラ５１０は、まずソフトウェア・パッケージのコピーがアップデート・サーバ５２８のメモリ５３０にすでに存在するか否かをチェックする。見つかった場合、インストーラは、当該ソフトウェア・パッケージをアップデート・サーバから直接ダウンロードする。この状況は、先のターゲット・コンピュータ５００が当該ソフトウェア・パッケージ５５４をアップデート・サーバ５２８に要求していた場合に生じうる。

ソフトウェア・パッケージが見つからなかった場合、インストーラ５１０は、ネットワーク接続を使用し、アップデートをソフトウェア場所参照５３８にて与えられたパッケージ・コンピュータ場所からターゲット・コンピュータ・メモリ５０２へと直接ダウンロードしようと試みる。これは、ファイアウォール５２６が存在しない場合に可能であり、あるいはアップデート・サーバがパッケージ・コンピュータ場所５４８へと接続できる場合に可能である。

管理者が、パッケージ・コンピュータ５６７などの「非認証」の供給源からファイルを取り出すようにアップデート・エージェント５０８に指示するパッケージを構築したとき、インストーラ５１０は、そのようなリソースを直接取り出すことができないであろう。しかしながら、アップデート・エージェントは、当該パッケージを取り出すようにアップデート・サーバ５２８に依頼することができる。いくつかの実装例では、複数のアップデート・サーバが存在し、アップデート・エージェント５０８が、そのうちのどれにアクセスするかを或る所定の条件を使用して決定する。例としては、利用できる最初のアップデート・サーバ５２８を選択する、もっとも多忙でないアップデート・サーバを選択する、ネットワーキングの点で「最も近い」アップデート・サーバを選択する、などがある。

本発明の一実装例においては、アップデート・サーバ５２８がオフサイトのパッケージ・コンピュータ５６７に到達できるとき、自身がリソースに到達できる旨をアップデート・エージェント５０８に報告し、取り出しに要する時間を推定する。この推定が、要求に係るリソースが利用可能になるまでにどれだけ長く待つべきかを、エージェントに知らせる。可能性は低いが、インターネット・トラフィックの変動およびサーバ応答時間のばらつきによって計算による推定が正確でない場合、エージェントが再度リソースを要求するならば、アップデート・サーバがさらなる待ち時間長さを提供し、エージェントは再び待機する。このサイクルが、アップデート・サーバ５２８がメモリ内にリソースを利用可能に有し、次の要求によってエージェントに届けることができるまで、繰り返される。

異なるエージェント５０８によって特定のソフトウェア・パッケージが複数回要求される可能性があるため、本発明の一実装例においては、アップデート・サーバ５２８がこのリソースをローカル・キャッシュ５３０に保存し、そこから追加の取り出し要求に応えることができる。アップデート・サーバ５２８の利用可能なメモリがすべて古いソフトウェア・パッケージで埋められてしまうことがないよう、一実施の形態では、保存したソフトウェア・パッケージについてパッケージがアクセスされた回数および最後のアクセスの時刻を記憶し、当該リソースをキャッシュ内に置いておく時間である「有効期間」を評価する。アップデート・サーバ５２８において動作している別のタスクが、時間とともに有用性を「失った」リソースについて周期的にチェックし、保存されているソフトウェア・パッケージ・アップデートをキャッシュ５３０から削除することによって、アップデート・ホストの保存用のリソースを回復させる。

一実施の形態においては、アップデート・サーバが、エージェントのリストにとって一度に１つずつパッケージを利用可能にする。エージェント５０８または結果探知器５１２が、パッチの適用に失敗したことを報告した場合、あるいはパッチによってエージェントのターゲット・コンピュータ５００がもはやアップデート・サーバと通信できない状態に置かれた場合、アップデート・サーバは、管理者の代理として頒布を自動的に中止する。このとき、管理者または他の指定された人物に、結果を通知５１６することができる。

結果探知器５１２は、ソフトウェア・パッケージのインストールが成功したか否かを判断し、その判断をアップデート・サーバ５２８に通信する。すでに述べたように、結果が失敗である場合、回復器５１４がターゲット・コンピュータを受忍可能な未アップデート状態に置く。結果探知器５１２は、必ずしもソフトウェアの実際のインストールのみを監視するだけでなく、むしろパッチ適用後のソフトウェアの使用、ターゲット・コンピュータの全体、および／または当該ターゲット・コンピュータへとネットワーク接続されたコンピュータを、或る指定された時間期間にわたって監視するように設定できる。さらに結果探知器が、種々のレベルの成功を有していてもよい。例えば、インストールそのもの（ファイルのコピー）を低いレベルの成功と考えることができ、その後のある時間期間にわたってターゲット・コンピュータに誤挙動がないことを、高いレベルの成功と考えることができ、成功のレベルに応じて異なる行動をとることができる。このように、すでに述べたとおり成功または失敗を監視し、必要に応じてインストールの再試行や中断などが行なわれる。

幾つかの実施の形態は、ターゲット・コンピュータ５００にソフトウェア・パッケージをインストールする前に、ターゲット・コンピュータ５００またはその一部のバックアップ５０６、５３４を保存する。バックアップは、ときにはアップデート・サーバに保存５３４され、ときにはソフトウェアがアップデートされようとするターゲット・コンピュータ５０６、５００に保存され、ときには集積所サイト６００でオフサイトに保存される。結果探知器５１２がソフトウェアのインストールに関して問題を報告したとき、回復器５１４が、バックアップ５３４を使用してターゲット・コンピュータをアップデートされていない状態に戻すことができる。

本発明の一実施の形態においては、アップデート・サーバ５２８が、次のターゲット・コンピュータ５００がアップデート・サーバ５２８において自身のアップデート・リスト５３６に置かれたパッケージへのソフトウェア場所参照５３８を有するまで、インストールの成功の確認（結果探知器５１２により、あるいは他の公知または新規な連絡方法による）を待つ。好ましい実施の形態においては、インストールが終了したとき、管理者は電子メール５１８、ポケットベル５２０、ボイスメール５２２、ＳＮＭＰ通知５６８、インスタント・メッセージング５７０、ファクシミリ、または何らかの他の手段によって、結果を通知５１６される。インストールが失敗した場合、インストールが失敗した特定の装置を特定することができる。幾つかの実施の形態においては、初期設定またはユーザ設定数のインストールが成功したのち、当該パッケージが同時に２以上のユーザによって利用できるようにされる。

これらのアップデート・リスト５３６は、ここでターゲット・コンピュータ５００と称しているワークステーション・クライアントまたはサーバを管理するために配達または頒布される前もって構築されたパッケージまたはカスタム・ビルドのパッケージの管理者の管理者の指定を容易にする。これらのパッケージが利用可能にされるとき、アップデートが本発明によって実行されるべく管理者によって計画され、これは、パッチまたはサービス・パックをインストールすべく管理者がクライアントを訪問しなければならない以前のタスクを自動化することができる。

アップデート・エージェント５０８は、動作するプラットフォームを知ることができ、管理者の代理として動作を実行すべくプログラム可能またはスクリプト可能であってよい。一実装例においては、これらの特徴がＰａｃｋａｇｅＢｕｉｌｄｅｒウィザードを通じて管理者に公開される。「ソフトウェア・パッケージ」は、ファイル、サービス・パック、ホット・フィクス（ｈｏｔｆｉｘ）、ソフトウェア・インストールおよびスクリプトの任意の組み合わせであることができる。これは、リモート装置で実行できるほぼすべてを管理者の代理として動作するエージェントを介して達成できるため、リモート装置の管理の機会をもたらす。

本発明の一実装例は、パッケージのインストールの前（インストール前）および後（インストール後）に、スクリプト５６２の実行を可能にする。インストール前スクリプトの例は、次のようなものであってよい（擬似コードによる）。

利用可能なディスク空間をチェック。

利用可能なディスク空間がＶａｌｕｅＸ（ここで、ＶａｌｕｅＸ＝インストールに必要な余地＋バッファ）よりも大きい場合、インストールを続行。

そうでない場合、外部の管理者にエラー発生を警報し、終了；
インストール後スクリプトの例は、次のようである（やはり擬似コードによる）；
インストールが成功した場合、外部の供給元にインストール成功を通知；
インストールが成功しなかった場合、外部の供給元にインストール失敗を通知。

次に図６および７を参照すると、ネットワーク２００が、多数の異なる種類のターゲット・コンピュータを含んでおり、そのそれぞれが、特定のターゲットのプラットフォームにあわせて特別に作ることができるエージェントを備えている。例えば、マイクロソフト（登録商標）Ｗｉｎｄｏｗｓ（登録商標）ＰＣ、アップル社のＭａｃｉｎｔｏｓｈ（登録商標）コンピュータ、およびＵＮＩＸ（登録商標）コンピュータが動作しているネットワークは、３種類のエージェントを有することができる。これは、エージェントが自身のターゲット・コンピュータを調査して、このコンピュータ情報６０２をアップデート・サーバ５２８および／または別個の集積所サイト６００へと保存のために報告できるという利点をもたらす。このシステムのいくつかの例では、他で説明するとおり走査を実行する発見エージェント５４８が設けられる。他の例では、走査が、アップデート・エージェント５０８またはダウンロードされたスクリプト・ファイル５６２によって実行される。ハードウェア構成６０８、ソフトウェア構成６０６、さまざまなハードウェアおよびソフトウェア・コンポーネントの使用についての情報６０４、訪問したウェブサイト、および送受信した電子メール６１０を、すべてオフサイトの場所６００へと送信することができる。ひとたびこの情報がアップデート・サーバで利用可能になると、管理者は、１箇所から管理対象ネットワークの全体を眺めることができる。

本発明のシステムが既存のネットワークに実装されるとき、発見エージェント５４８が、少なくともターゲット・コンピュータ５００に存在するソフトウェアの調査を実行でき、既存のソフトウェア構成７００が検出されて、集積所サイト６００のメモリ内に保存される。幾つかのシステムは、ネットワーク２００の全体を調査してもよい。アップデートが要求されたとき、システムは、ネットワークの装置をそれらの現在の状態をチェックすべく再調査する必要なく、どれが必要とされているかを知っている。

ターゲット・コンピュータ５００についての推奨構成７０４が、アップデート・サーバ５２８または集積所サイト６００に置かれている。推奨構成は、例えばハードウェア構成、ソフトウェア構成、コンピュータの種類、および最後のパッケージ・アップデートによるなど、新規またはデータベースの技術分野に精通したものにとって公知の多くのやり方で決定することができる。したがって、発見エージェント５４８が、現在の構成７００と推奨構成７０４とを比較し、ターゲット・コンピュータ５００について提案されるアップデートのリスト７０８を用意する。このアップデート・リストは、インストール済みソフトウェアのサービス・パック、先にアンインストールされたソフトウェア、および更新されたデータ・ファイルなどを含むことができる。この提案リストを用意するプロセスにおいては、現在のソフトウェア構成を考慮するだけでなく、ハードウェア構成６０８、特定のプログラムやデータ・ファイルなどのアクセス頻度６０４などの情報、ならびに当業者にとって公知の他の情報も考慮することができる。このアップデート・リストを、自動的に管理者に知らせることができる。

ターゲット・コンピュータの現在構成７００が提案されるアップデート・リスト７０６を生み、管理者が自動通知７０８を受け取ることができると仮定する。この点で、新しいターゲット・コンピュータが少なくとも部分的にアップデートされるまで、または管理者が許可を与えるまで、あるいは何か他の新規または公知の条件が満足されるまで、コンピュータの使用を規制することができる。この提案されたアップデート・リスト７０６は、他で説明するとおり、コンピュータを実際にアップデートするために使用されるアップデート・リスト５３６を定めるためにも使用できる。

パッケージは、例えばソフトウェア・ファイルまたはデータ・ファイルなどのファイル表わしているモジュール、およびパッケージ内のファイルに対してとられる一連の動作であるスクリプトで構成される。代案として、１つ以上のスクリプト・ファイルをパッケージの中身に含むことができ、パッチをインストールするためエージェントによって実行できる。本発明の幾つかの実施の形態においては、人間である管理者が、新規ソフトウェア・パッチが利用可能である旨の通知を受け取る。他の実施の形態では、通知がオフサイトのアップデート・サーバ５２８に直接送られ、アップデート・サーバ５２８が、それらをいつ頒布するかを決定する。オフサイトのアップデート・サーバは、すでに各ターゲット・コンピュータに保存されたパッケージを恒久的なメモリに保存するように構成できる。新規パッケージが利用可能になるとき、または既存のパッケージのインストールの際、インストールされる必要があるソフトウェア・パッケージの存在の証拠、ならびに以前のインストールについての情報が、幾つかの実施の形態においてはオフサイトのアップデート・サーバ５２８にて、他の場合には集積所サイト６００にて、利用可能である。

アップデートされるパッケージは、必ずしもそこへのアクセスを受け取るターゲット・コンピュータ５００のユーザによって所有されている必要はない。このシステムの一実施の形態では、ソフトウェア・パッケージが、当該ソフトウェアをユーザに貸し出している第３者によって所有されている。他の実施の形態では、ソフトウェア・パッケージがアップデート・サーバのユーザによって所有されており、アップデート・サーバのユーザが、ターゲット・コンピュータ５００のユーザにソフトウェア・パッケージを貸し出し、アクセスを提供する。

（セキュリティおよび重要パッチの管理、特徴）
本発明は、種々のオペレーティング・システムにおいて既知のセキュリティ脆弱性および他の安定性の問題または向上を解決する重要パッチの管理および配布のためのツールおよび技法を提供する。適当なオペレーティング・システムには、これらに限られるわけではないが、マイクロソフト社のすべてのオペレーティング・システム（例えば、９５、９８、ＭＥ、ＮＴ、Ｗ２Ｋ、ＸＰ、Ｗ２Ｋ３）、ＵＮＩＸ（登録商標）オペレーティング・システム（例えば、Ｌｉｎｕｘ、Ｓｏｌａｒｉｓ、ＡＩＸ、ＨＰ‐ＵＸ、ＳＣＯ、など）、およびＮｏｖｅｌｌ社のＮｅｔＷａｒｅオペレーティング・システムが含まれる。オペレーティング・システム製品の名称は、それらの所有者の商標である。

過去において、セキュリティその他の重要なパッチを管理するために、企業および他のコンピュータ・ユーザは、ベンダのウェブサイトを頻繁にチェックし、例えばワールド・ワイド・ウェブを巡って投稿されたニュース・レポートや文書による警報を読むことによって、あるいは電子メール購読またはニュースグループによって送信される通知を送られることによって、新規パッチを見つけている。企業が使用しているソフトウェアに関し、そのベンダがアプリケーション・ソフトウェア、ドライバ・ソフトウェア、および／またはハードウェアの修正または機能向上のための新しいパッチを公開したことを知ったとき、当該企業のソフトウェア管理担当者は、通常は、該当する最新パッチを手動でダウンロードし、それらをさまざまな配置および構成にある当該企業の装置との互換性についてテストし、その後に手動または従来からのソフトウェア配布ツールを使用して当該パッチを配布しなければならない。

対照的に、本発明は、インターネット・アクセスを有しているか否かにかかわらず、重要なアップデートの通知８２４を事前的なやり方でコンピュータに提供できる。本発明は、管理者が各ダウンロードの指示を表明することなくパッチのダウンロードを実行することによって、事前的に動作することができる。さらに本発明は、ネットワーク上のデスクトップ、サーバ、携帯型のコンピュータ、および他のコンピュータへのソフトウェア・アップデート、ソフトウェア・パッケージ、および他のデータの配布およびインストールを容易にすることができる。

本発明の一実施の形態は、パッケージ・コンピュータ５６７などのマスタ書庫から最新の重要アップデートを取り出すアップデート・サーバ５２８を通じての中身の複製を含んでいる。取出しには、安全な伝送のため、１２８ビットＳＳＬまたは類似のプロトコルを使用できる。マスタ書庫に新規アップデートが追加されたとき、当該アップデートのメタデータが、アップデート・サーバおよび／またはフィンガプリント・ライブラリ９０４へと自動的にダウンロードされる。メタデータが、パッチが重要なものであることを示している場合、当該パッチをアップデート・サーバへとダウンロードし、迅速な展開のためにキャッシュしておくことができる。各パッチは、関連のインストーラ９１２、あらかじめ必要な署名９１０、および他のフィンガプリント識別子９０６を有している。

幾つかの実施の形態においては、情報が１方向、すなわちマスタ書庫からアップデート・サーバにのみ送信され、これによってマスタ書庫のセキュリティを高めている。さらに、幾つかの実施の形態においては、伝送される情報がすべて暗号化され、ＣＲＣ（巡回冗長符号）がチェックされ、圧縮され、デジタル署名され、１２８ビットＳＳＬ接続によってダウンロード３０８される。ＳＳＬ接続は、パッチ供給元としてのマスタ書庫の正当性を確認するセキュア・ネットワーク・プロトコルを使用する。他のセキュア・ネットワーク・プロトコルを使用することも可能である。他の実施の形態においては、これらの要素の幾つかが省略され、例えばＣＲＣチェックが行なわれず、さらに／またはデジタル署名が使用されない。

アップデート・サーバ５２８が、クライアント・ターゲット・コンピュータ５００のためのパッチ供給元として機能する。複製サービスならびにアップデートおよびソフトウェア・パッケージを管理するための管理ツールを含んでいるアップデート・サーバが、クライアント５００を走査し、ＨＴＴＰ、ＨＴＴＰＳ、およびＸＭＬなどのプロトコルを使用してそれらへのパッチ配布を計画できる。幾つかの実施の形態では、アップデート・サーバが、マイクロソフト社のＩｎｔｅｒｎｅｔＩｎｆｏｒｍａｔｉｏｎＳｅｒｖｉｃｅｓを使用する。アップデート・サーバは、マスタ書庫から受け取った重要なアップデートを自動的にキャッシュするように構成できる。幾つかの実施の形態においては、管理者が複製計画を設定でき、手動で複製を起動させることができ、あるいはアップデート・サーバ内の複製ソフトウェアにソフトウェアの複製および配布を、ネットワークの不活発状態を予想または測定して自動的に行なわせることができる。

幾つかの実施の形態においては、管理者がソフトウェア・パッケージ５５４を製作でき、次いで他のあらゆるパッチと同様に配布することができる。すなわち、広い意味での「パッチ」は、密接に関連する修正対象のソフトウェアが前もってインストールされていることを前提とする必要はなく、ターゲットにとって新規なソフトウェアであればよい。例えば、マイクロソフト社のＯｆｆｉｃｅ２０００を含んでいるパッケージを、すべてのデスクトップに配備することができる。特注アプリケーションの管理者も、同様に、特注アプリケーションとそのパッチを配布するためのパッケージを製作できる。幾つかの実施の形態の管理者は、あらゆるソフトウェア・パッケージをあらゆるターゲット・コンピュータへと配布するため、作り付けのソフトウェア配布の特徴を利用することもできる。

幾つかの実施の形態においては、アップデート・サーバ５２８が、企業レポート・マトリクスまたは企業または他の団体の装置のパッチ状態について他の概要を表示するソフトウェアおよび／またはハードウェアを備えて構成される。レポートは、ネットワーク管理者および／または企業のコンピュータ機能の維持を担当する他の職員に示される。管理者は、アップデート・サーバからのアップデートまたはパッケージのどれをクライアント５００へと送るかを、ポリシーを設定し、グループを定義し、警報に応答し、さらに／または本明細書で説明され、あるいは既に知られている他のステップをとることによって、支配（或る場合には、完全に制御）する。幾つかの実施の形態においては、管理者が、再起動の制御およびクライアント・エージェントのポリシーを設定および変更する権限を含め、パッチの配布について全面的な管理を有している。

所与のパッチが異なる企業において異なる挙動を示す可能性があるため、パッチを、企業にわたって広く配布する前に、内部でテストすることができる。パッチ管理のための市販ソフトウェアおよびサービスを提供しており、本件出願およびその始祖の譲受人であるＰａｔｃｈＬｉｎｋ．ｃｏｍＣｏｒｐｏｒａｔｉｏｎ（「パッチリンク社」）が、パッチをパッチリンク社による公開に先立って、継続的に研究し、テストし、承認している。例えば、マイクロソフト社のＷ２Ｋ（Ｗｉｎｄｏｗｓ２０００（登録商標））オペレーティング・システムのためのホット・フィクスがマイクロソフト社によって公開されたとき、パッチリンク社によって、例えば標準のＷ２Ｋ、ＳＱＬサーバを備えるＷ２Ｋ、Ｏｆｆｉｃｅを備えるＷ２Ｋ、およびＥｘｃｈａｎｇｅ（マイクロソフト社の商標）を備えるＷ２Ｋなど、２００を超える異なるＷ２Ｋ構成について種々のサービス・パックおよび他のホット・フィクスとの組み合わせにおいてインストールおよびテストが行なわれ、その後に、パッチリンク社によってマスタ書庫５６７へと公開される。

幾つかの実施の形態においては、クライアント・エージェント５０８が、どのアップデートが当該クライアントにおいて必要であるかを判断するため、イントラネットでホストされたアップデート・サーバをチェック３３２する。クライアント・エージェント５０８が、現在の構成７００など収集した情報をアップデート・サーバに報告し、アップデート・サーバが、管理者のためにレポート・マトリクスを生成する。幾つかの実施の形態においては、管理者が配布ウィザードを使用してパッチの配布を指定および承認する。管理者によって承認されたアップデートおよびパッケージがバックグラウンドでダウンロード３１２され、ダウンロードを受け取るコンピュータのユーザにとっての不便を少なくし、次いで管理者によって設定された計画に従って自動インストールされる。管理者によって定められるルールによって、パッチ・インストール・プロセスの振る舞いを制御することができる。

本発明の一実施の形態によれば、重要なオペレーティング・システム・フィクスおよびセキュリティ・パッチなどのソフトウェア・パッケージおよびアップデートを自動的にダウンロード３０８、３１２およびインストール５１０する実施の形態を管理者にもたらす事前的なサービスが提供される。

本発明の幾つかの実施の形態に作り付けのセキュリティの特徴は、デジタル・セキュリティ識別を使用する。この特徴が、ダウンロードされたアップデートをターゲット５００にインストール５２０する前に、各ファイルまたはパッケージについてデジタル証明、ＣＲＣチェック、圧縮、および暗号化を検証する。アップデート・サーバ５２８において、管理関連ページおよび他の制御へのアクセスは、認証された管理者にのみ限定される。幾つかの実施の形態においては、アップデートの複製（ダウンロード）にＳＳＬが使用され、アップデート・サーバへのダウンロードの有効性がチェックされ、ＳＳＬ証明が認識された供給元（例えば、ＰａｔｃｈＬｉｎｋ．ｃｏｍ）を適切に識別できない場合には、ダウンロードに失敗し、サーバが管理者に電子メールの警報を送信する。幾つかの実施の形態においては、すべてのダウンロード（マスタ書庫からアップデート・サーバへ、アップデート・サーバからターゲットへ）のすべての情報が、暗号化され、ＣＲＣチェックされ、圧縮され、デジタル署名され、１２８ビットＳＬＬ接続のみによって送信される。他の実施の形態においては、これらの要素が変更（例えば、４０ビットの暗号化など）され、さらに／あるいは省略される。

パッチ署名９１０という特徴が、例えばエージェントにターゲット上の適切なソフトウェア・バージョンおよび適切なハードウェア・ドライバをチェックさせることによって、ターゲット５００を走査して各パッチについての必要条件が満足されているか否かを判断する実施の形態を可能にする。パッチ署名およびパッチ・フィンガプリントという特徴は、それぞれ、企業のレポート・マトリクスにおいて閲覧することができる検出レポートの作成に使用することができる。ワークステーションの目録という特徴が、ターゲット・コンピュータに必要なソフトウェアおよびハードウェア・ドライバを特定するため、発見エージェント５０８を使用する。さらに、発見エージェントは、フィンガプリントに必要な署名についてターゲットを走査できる。ＰａｔｃｈＬｉｎｋ．ｃｏｍが、今や世界で最も大きい自動化されたパッチのフィンガプリントされた集積を収容しているマスタ書庫を有している。

幾つかの実施の形態において、バックグラウンドでのダウンロード３１２という特徴が、作り付けの帯域幅制限を備える安全なバックグラウンド転送サービスを提供し、大規模な配布においてネットワーク管理者が、如何に帯域幅を利用すべきかを決定できる。幾つかの実施の形態は、設定可能なエージェント５０８のポリシーを管理者に提供し、管理者がエージェントの通信間隔および動作時間を決定できるようにする。例えば、管理者は、生産用のサーバへのパッチの頒布を真夜中とＡＭ２：００との間にのみ行なうようにポリシーを設定できる。幾つかの場合には、エージェントが、所与の時点について有効なポリシーを２つ以上有してもよい。

連鎖化されたインストールという特徴により、管理者は、マイクロソフト社のＱｃｈａｉｎ．ｅｘｅというツールを使用することによって、繰り返しの再起動を低減または最小化することができる。複数回の再起動を必要とする複数のアップデートがインストール５１０される場合に、管理者は、より少ない再起動でアップデートを配布するため、本発明の能力をＱｃｈａｉｎと組み合わせて使用することができ、幾つかの場合には、ただ１回の再起動しか必要としなくなるであろう。この再起動の低減は、重大任務のコンピュータ５００がアップデートされるとき、使用可能時間を長くすることができる。Ｑｃｈａｉｎは、最新のアップデートは有効になるような順序にＤＬＬを再配置する。

ダウンロード再開という特徴を使用し、一実施の形態は、例えばサービス機能休止によってダウンロードの中断３１６を検出する。ターゲット５００が携帯型のワークステーションである場合、ユーザは、それを単純に切り離し、サービス外でない他の場所で再度接続することができる。アップデート・サーバへとアクセス（例えばＴＣＰ／ＩＰによって）可能である場合、この実施の形態は、全パッケージを再伝送すべく始めから再出発する代わりに、ダウンロード中で中断された点またはその付近からダウンロード３１２を再開する。

移動ユーザをサポートするという特徴ゆえ、管理者は、パッチおよびソフトウェアを配布開始時にネットワークに接続されていないターゲット・コンピュータ５００にも配布することができる。移動中のターゲットが後にネットワークに接続したとき、この実施の形態は、当該ターゲットを自動的に走査し、当該ターゲットをアップデートするために必要な作業を実行する。

実施の形態は、安全なダウンロード３１２のためにアップデート・サーバ５２８と通信するクライアント・エージェント５０８を特徴としている。さらにエージェントの使用によって、性能の向上および企業全体にわたる実施の形態への拡大可能性がもたらされ、ただ１つのアップデート・サーバによって数千のクライアントをサポートできる。エージェントは、ファイアウォール１１６、２１４を横断して機能でき、企業のネットワークへのＴＣＰ／ＩＰ（あるいは他の）接続を有しているあらゆるコンピュータ５００上で動作できる。

幾つかの実施の形態は、「包括的パッチ走査」とも称されるが、複数のベンダのパッチ５５４についてのサポートを特徴としている。アップデート・サーバ５２８は、ただ１つのベンダ片のパッチに限られず、複数のベンダからのパッチについての新規な管理をサポートする。例えば、アップデート・サーバがターゲット・エージェントと協働し、マイクロソフト社、ＩＢＭ社、Ａｄｏｂｅ社、Ｃｏｒｅｌ社、Ｓｙｍａｎｔｅｃ社、ＭｃＡｆｅｅ社、Ｃｏｍｐａｑ社、ＷｉｎＺｉｐ社、Ｃｉｔｒｉｘ社、Ｎｏｖｅｌｌ社、および他の多くのベンダ（各社の標章）からのソフトウェアにおけるパッチ関連のセキュリティ脆弱性について、ターゲット５００を走査する。

幾つかの実施の形態においては、グループ化という特徴によって、管理者が、選択されたターゲット・コンピュータ５００を例えば「コンテナ」または「グループ」と呼ばれる組へとグループ化できる。このようにして、個々のターゲット・コンピュータに適用される作業を、考えられるターゲット・コンピュータの適切な部分集合を保持しているコンテナ／グループ、すなわち特定のコンテナに属するすべてのターゲット・コンピュータ５００（あるいは、パッチ署名およびフィンガプリントに照らして適切であるすべてのターゲット・コンピュータ）にも適用できる。この特徴は、実施の形態に応じ、配布、フィンガプリント・レポート、目録レポート、不可欠のパッチ最低線ポリシー、および／またはクライアント・エージェント・ポリシーについて、管理者の管理を容易にする。例えば、各コンテナが、当該コンテナのメンバー、当該コンテナのクライアント・エージェント５０８ポリシー、および当該コンテナの不可欠のパッチ最低線ポリシーを特定する属性を有することができる。管理者は、配布のために、個々のクライアント５００、前もって定められたクライアント・グループ、および／またはユーザ定義のグループを選択することができる。幾つかの実施の形態においては、コンピュータをそれらが要求するパッチに従って自動的にグループ化することができる。

幾つかの実施の形態では、管理者がグループ・マネージャ（ＧｒｏｕｐＭａｎａｇｅｒ）を指定でき、管理の制御の限られた部分を委譲できる。グループ・マネージャの観点からは、本発明の実施の形態の監視および制御は、管理者によって管理対象グループに割り当てられ、好ましくはすべてが同じアップデート・サーバ５２８を使用するコンピュータ５００のみをカバーするように狭められている。管理者は、単に特定のグループのコンピュータではなく、依然としてネットワーク内のすべてのコンピュータを監視し、さもなければ制御できる。

幾つかの実施の形態においては、不可欠パッチ最低線ポリシーという特徴によって、管理者が、ネットワークの１つ以上のコンピュータについて最小（最低線）構成を指定できる。この実施の形態は、最低線ポリシーによって定められた組織の標準へと、オペレーティング・システムおよび／またはアプリケーションを前向きにパッチすることができる。企業においてパッチ・ポリシーをサポートすることで、本発明の実施の形態における管理者は、当該管理者の企業のためのパッチ・ポリシーを設定でき、これにより、例えば企業内のすべての装置５００が最小のパッチ・レベルを下回ることがないようにできる。例えば、Ｗ２Ｋグループについての不可欠のパッチ最低線ポリシーが、マイクロソフト社のＯｆｆｉｃｅ２０００、Ａｄｏｂｅ社のＡｃｒｏｂａｔＲｅａｄｅｒ５．０、およびＳｅｒｖｉｃｅＰａｃｋ２を含んでいる場合、このグループに配置された（最初にグループ定義の際に配置され、あるいは後に配置された）すべてのコンピュータに、少なくともこれらのソフトウェアがインストールされるであろう。

パッチについての最低線は、グループ（例えば、ユーザ定義のグループ、または管理者定義のグループ）によって定められたコンピュータ５００の組、特定のオペレーティング・システムを使用するコンピュータ５００の組（例えば、ユーザまたは管理者定義のグループと無関係にすべてのＷ２Ｋコンピュータ）、あるいは特定のアプリケーションを使用するコンピュータ５００の組（例えば、マイクロソフト社のＯｆｆｉｃｅＸＰを使用するすべてのコンピュータ）に関連付けることができる。例えば、幾つかの実施の形態においては、管理者が、マイクロソフト社のＯｆｆｉｃｅＸＰがインストールされているならばシステムが自動的にＯｆｆｉｃｅＸＰＳｅｒｖｉｃｅＲｅｌｅａｓｅ１をパッチしなければならないと宣言する最低線ポリシー・ルールを設定することができる。

不可欠のパッチ最低線ポリシーが使用される場合、テープのバックアップや鏡像イメージなどからソフトウェアを復旧させることによってターゲット５００から欠落する（取り除かれる）パッチ５５４は、エージェント５０８が新しい構成を割り出し、当該構成をポリシーの要求する最低線と比較８２２（クライアント・エージェントおよび／またはアップデート・サーバによる）したのちに、自動的に再インストールされる。このようにして、最低線の完全性がこれらの実施の形態によって維持される。

不可欠のパッチ最低線ポリシーは、本発明によって、望ましくないソフトウェアの自動検出、およびネットワーク内のターゲット・コンピュータからの当該望ましくないソフトウェアの除去の実行に使用することができる。望ましくないソフトウェアが検出されたときに適用すべき不可欠な配布パッチは、望ましくない項目を「ＵＮＩＮＳＴＡＬＬ」するためのものである。例えば、そのようなパッチの１つは、ＫａＺａＡというファイル共有アプリケーションを検出して企業のネットワークから除去して、当該企業の従業員が日々の仕事の流れにおいて著作権法に違反する恐れを少なくし、あるいは娯楽目的で利用可能なネットワーク帯域幅がすべて使用されてしまう恐れを少なくする「ＵｎｉｎｓｔａｌｌＫａＺａＡ」であろう。政府関係機関および他の大企業においては、ポップアップ・ソフトウェアおよびユーザの注意を担当業務からそらしてしまう他の事物を除去することは、きわめて重要でありうる。

さらに本発明は、ネットワークにおける脆弱性を治癒するため、不可欠なパッチの論理的対照物として眺めることができる特徴を提供する。この論理的対照物は、「禁制パッチ」と称することができるが、決してインストールしてはならないサービス・パック、ホット・フィクス、または他のソフトウェアを指定するために使用される。不可欠パッチという特徴が脆弱性を自動修正するために使用されるのとちょうど同じように、禁制パッチという特徴は、ネットワーク管理者が動作している構成を破壊する可能性があるソフトウェアをインストールしてしまわないようにするために使用される。一例として、企業が、Ｗｉｎｄｏｗｓ２０００（登録商標）についての最新のマイクロソフト社のサービス・パックにおいては動作しない給与支払いシステムを有しているとする。このサービス・パック・パッチが手動または自動で給与支払いサーバに配布されてしまうと、管理者がこれを一刻も早く知る必要があり、そうでない場合、週末に誰も給与を受け取ることができない。幾つかの実施の形態は、「禁制パッチ」の存在を走査および検出でき、管理者に警告することができる。さらに、適用されるグループ・パッチ・ポリシーがそのように宣言していないか否かにかかわらず、管理者が禁制パッチを当該パッチをインストールしてはならない装置へと意図せずに配布してしまうことがないようにルールを提供することもできる。

幾つかの実施の形態においては、パッチ遵守保証という特徴が、特定のコンピュータおよびコンピュータ５００のグループについてパッチ５５４の組をロックする選択肢を、管理者に提供する。すなわち、或る特定のパッチが、不可欠最低線という前記の特徴よりも弱いやり方で必要とされる。このパッチ要件に反するやり方でターゲット５００の構成の変更が試みられた場合、管理者に電子メール警報メッセージ８２４が送信される。例えば、何台かのＷ２Ｋコンピュータが、パッチ遵守の対象である「ＩＩＳＳｅｒｖｅｒｓ」という管理者定義のグループに属するとする。この結果、この実施の形態は、安全のためにすべてのオペレーティング・システム・パッチおよびすべてのインターネット情報サーバ・パッチをロックする。後のどこかの点でそのようなパッチ（これらに限られるわけではないがＤＬＬを含む）が置き換えられたとき、この実施の形態は、コンピュータ５００の名称および／またはコンピュータ５００に対してなされた変更を特定する電子メール警報を管理者に送信する。新たに非遵守となったコンピュータおよび非遵守となった理由、すなわちそれらの構成とロックされた構成との間の乖離の概要を、特定することができる。幾つかの場合においては、この遵守の特徴が、自身の装置において新しいソフトウェア・アプリケーションのインストールまたは既存のソフトウェアの削除を行なったユーザを特定するために、管理者によって使用される。この遵守ロックの特徴を、非遵守のターゲット５００に自動でパッチを当てるため、幾つかの実施の形態において不可欠パッチ最低線の特徴と組み合わせて利用できることに、注目すべきである。ロックされたパッチまたは他のソフトウェア・コンポーネントが取り除かれたとき、それが自動的に再インストールされ、電子メールによって管理者に通知８２４される。

幾つかの実施の形態においては、サービス変更という特徴によって、管理者がクライアント・ワークステーション（グループに属し、あるいは独立している）において提供されるサービスをロックし、ユーザが管理者に直接連絡することなくサービス項目を開始または停止した場合に、管理者に通知されるようにできる。ユーザがロックされているクライアント５００においてサービスを変更し、さらに／あるいは変更を試みた場合、コンピュータおよび（試みられた）サービスの変更を特定する電子メール警報８２４が管理者へと送られる。

幾つかの実施の形態においては、ハードウェア変更という特徴によって、管理者がクライアント・ワークステーション５００（例えば、グループに属している）において提供されるハードウェア構成をロックし、ユーザが管理者に直接連絡することなくそのようなワークステーションにハードウェア項目をインストールし、あるいはハードウェア項目を取り去った場合に、管理者に通知されるようにできる。ユーザがロックされているクライアントについてハードウェア構成を変更した（あるいは変更を試みた）場合、コンピュータおよび（試みられた）ハードウェア変更を特定する電子メール警報が管理者へと送信８２４される。

インポート／エクスポートという特徴が、高度な安全が必要な軍事または政府機関のコンピュータなど、インターネットに接続されていないネットワーク上のコンピュータのアップデートを容易にする。コンテンツがマスタ書庫からターゲット・ネットワークのアップデート・サーバ５２８へと、マスタ書庫においてコンテンツ５５４がロードされたテープ、ディスク、または他の記憶媒体を、適切な物理的保安手段を講じつつ物理的に運搬するなど、インターネット以外の手段を使用して運ばれる。この媒体が安全なターゲット・ネットワークのアップデート・サーバ５２８にとってアクセス可能になると、そのコンテンツを運搬用の媒体から当該アップデート・サーバのローカル・ストレージへと転送する際には、すでに説明した備え付けの保安手段（暗号化やＣＲＣなど）を使用することができる。次いで、当該アップデート・サーバは、すでに説明したとおりに安全なネットワークのターゲット・コンピュータのアップデート３０４を終えることができる。

幾つかの実施の形態においては、繰り返し配布という特徴が、企業の従業員のディレクトリやウイルス対策定義／データ・ファイルなど、繰り返し更新されるデータまたは文書５５４の配布を容易にする。１つ以上のそのようなデータまたは文書ファイルを、例えばすべてのターゲット５００あるいは管理者の指定するグループまたはただ１つのターゲットへと、管理者によって指定される繰り返しスケジュールに従って配布することができる。幾つかの場合には、繰り返しのサーバ再起動など他のステップを指定することもできる。

幾つかの実施の形態においては、災害復旧という特徴が、ハード・ディスクのクラッシュやサーバのハードウェア故障など、システム故障からの回復に関して管理者を手助けする。アップデート・サーバ５２８が故障した場合、管理者は、同じＤＮＳ名を有する別のサーバを故障したサーバとして生成し、新しいサーバに同じアップデート・サーバ・ソフトウェアを再度（必要であれば同じシリアル番号とともに）インストールする。アーカイブされ、ミラーされ、あるいは他の方法で保存されたデータ・ファイル６００が、この実施の形態によって使用されるが、必要に応じて新しいアップデート・サーバへと戻される。次いで、ターゲット・エージェント５０８がアップデート・サーバの新しいインスタンスに自動的に接続し、ターゲット・エージェントがサーバ故障によって失われた情報（もしあれば）をもたらしたのちに、通常の動作が回復される。

幾つかの実施の形態においては、自動キャッシュという特徴によって、アップデート・サーバ５２８に、重要、高優先度、および／またはセキュリティ関連と付されているパッチ５５４を、自動的にダウンロードしてローカル・アップデート・サーバ・ストレージにキャッシュするようにさせている。アップデート・サーバは、どのパッチが重要であって、どのパッチがキャッシュされているのかについて、管理者に通知し、当該パッチを必要とするターゲット・コンピュータ５００を走査する。対照的に、重要でないパッチは、それらが最初に配布されたのちにアップデート・サーバにキャッシュされるであろう。重要なパッチおよびセキュリティ・パッチを最初の配布よりも前にキャッシュすることによって、或るベンダのソフトウェアが脆弱であって当該ベンダが殺到するパッチの要求に耐えられなくなりうる場合に、容易に利用できるパッチ供給元をターゲット・コンピュータに提供できる。例えば、ＣｏｄｅＲｅｄやＮｉｍｄａといったウイルスの攻撃の際、パッチへの需要があまりにも大きかったため、幾らかのユーザは、パッチを手に入れるべくマイクロソフト社のウェブサイトに接続するために数時間待たなければならなかった。重要なパッチおよびセキュリティ・パッチを本発明のアップデート・サーバ５２８に前もってキャッシュすることによって、そのようなパッチがないためにターゲット・コンピュータ５００の動作が中断され、あるいは損なわれるという恐れを減らすことができる。

幾つかの実施の形態は、複数パッチの知的な配布という特徴を有しており、パッチ５５４をオペレーティング・システムと一致させ、各ターゲット・コンピュータで使用されているオペレーティング・システムを明示的かつ完全に特定する必要から管理者を解放する。例えば、マイクロソフト社が、彼らのオペレーティング・システムについて、種々に異なるいくつかのオペレーティング・システム・プラットフォームについて異なるパッチ５５４を指定する公報を出したと仮定する。本発明の実施の形態を使用する管理者は、配布のために「マイクロソフト社のオペレーティング・システム」を選択するだけでよく、指定するさまざまなターゲットのオペレーティング・システム詳細の差異にかかわらず、ターゲット・コンピュータ５００を指定することができる。この実施の形態は、互換性およびパッチの必要性についてパッチとオペレーティング・システム要件とを比較８２０し、所与のターゲットに確実に適切なパッチがインストールされるようにする。このようにして、マイクロソフト社のＷｉｎｄｏｗｓ９８（登録商標）プラットフォームのためのパッチが、Ｗｉｎｄｏｗｓ９８（登録商標）オペレーティング・システムを動作させているターゲット・コンピュータにインストールされ、マイクロソフト社のＮＴプラットフォームのためのパッチが、ＮＴオペレーティング・システムを動作させているターゲット・コンピュータにインストールされ、以下同様である。この特徴は、関係するオペレーティング・システム（あるいは、以前のパッチを含むオペレーティング・システムのバージョン）に応じてパッチとターゲットとを手動で適合させる必要性から管理者を解放することによって、パッチの配布をより迅速にする。

他の特徴は、適用可能なパッチ５５４の発見およびパッチの相互依存関係の管理を手助けして、管理者が数ダース（あるいは数百でさえありうる）のおおむね無関係なパッチを手動で仕分けしなくてもよいようにする。代わりに、この実施の形態は、適用可能なパッチを、それらのメタデータ、フィンガプリント、および／または署名データを使用し、関係するオペレーティング・システム、他のパッチの存在（または非存在）、異なるパッチの相互依存関係（どのパッチが適切に動作するために他のどのパッチを必要とするかを特定する）、および不可欠パッチ最低線ポリシー（存在する場合）などの要因にもとづいて特定する。次いで、どのパッチが当該ターゲット５００に適用可能であるかが、管理者に示される。例えば、一実施の形態は、ＩＩＳパッチを、ＩＩＳがターゲット・コンピュータにインストールされている場合に限って管理者に示す。一貫して使用される場合、この特徴は、パッチがターゲットに向かって配布されたときにターゲットが該当のアプリケーションを有していてパッチが当該ターゲットにインストールされることを確実にする。

パッチの相互依存関係の例として、マイクロソフト社のＷ２Ｋプラットフォームについて一実施の形態がＳｅｒｖｉｃｅＰａｃｋ２を管理者に推奨し、ひとたびＳｅｒｖｉｃｅＰａｃｋ２がインストールされると、次にＳｅｒｖｉｃｅＰａｃｋ２に依存するＳｅｃｕｒｉｔｙＲｏｌｌｕｐパッチを推奨する。この実施の形態は、パッチ５５４の識別を有効にすべくフィンガプリントを正確に実行するため、レジストリおよびファイル情報の両者を読み出す。

幾つかの実施によれば、管理者は、最近の動作の履歴またはログを検討することが可能であり、さらにパッチ５５４またはその一部をアンインストールすることが可能であり、ネットワークへのパッチ配布の影響を巻き戻すことができる。これによって管理者は、問題を引き起こしたパッチのインストールを取り消すことができる。失われたユーザ・データは必ずしも回復されないが、ＤＬＬの削除、レジストリ・エントリの除去、およびパスまたは他のシステム変数値の回復、など、通常のアンインストーラによって行なわれる通常のステップを、復旧器５１４を使用して行なうことができる。さらに、署名、フィンガプリント、警報、およびレポートなど本発明の実施の形態に特有の構成状態が、発生した問題および／またはパッチの除去を反映させるべく更新される。さらに、除去されたパッチがパッチ依存関係中に存在し、さらに／あるいは不可欠パッチ最低線に存在する場合、管理者に通知することができる。

幾つかの実施の形態は「ディレクトリ中立」の特徴を有しており、すなわちプラットフォームに関して中立であり、動作のためにＮｏｖｅｌｌ社のＮＤＳディレクトリやマイクロソフト社のＡｃｔｉｖｅＤｉｒｅｃｔｏｒｙ製品などのディレクトリを必要としない。しかしながら、幾つかの実施の形態は、特定の組織のそのようなディレクトリと統合でき、協働できる。

幾つかの実施の形態は、選択的パッチという特徴に従って動作し、そこでは、パッチ５５４は、それらが不可欠パッチ最低線ポリシーを満足するために必要とされない限りは、自動的にはインストールされない。幾つかの実施の形態においては、重要パッチおよび／またはセキュリティ・パッチであると印されているパッチも、自動的にインストールされる。このような実施の形態においては、他のパッチは、管理者がそれらを選択して、インストールを明示的に認めない限り、インストールされない。これにより、管理者は、彼らの組織のコンピュータへとパッチをインストールする前に、それらを組織内で内部的にテストできる。ひとたびパッチが適切にテストされると、当該ターゲット５００のグループについての不可欠パッチ最低線に加えることができ、必要とされるときに自動的にインストールされるであろう。

幾つかの実施の形態は、ターゲット装置５００上でのアプリケーションの実行を防止するセキュリティ・ポリシー・パッチ５５４をサポートする。これは、ターゲット・コンピュータのファイル・システムに引っ掛かるポリシー駆動のやり方を提供し、特定のファイル（または複数のファイル）の実行を停止させる。これは、当該実行可能／ＤＬＬファイルの名称を変更し、それを何もしないコード、またはユーザにエラー・メッセージを表示するコード、および／あるいは電子メールで管理者に通知するコードで置き換えるパッチによって、実装可能である。

本発明の実施の形態の動作は、以下の例としてのシナリオを検討することによって、さらに理解されるであろう。１つのシナリオにおいては、新規パッチ５５４がそれぞれ対応するベンダによって公開されたとき、アップデート・サーバ５２８が対応するフィンガプリントをマスタ書庫５６７からダウンロードする。次いで本発明の実施の形態は、エージェント５０８による走査のために当該パッチのフィンガプリントをターゲットへと送信することによって、いずれかのターゲット・コンピュータ５００がプロファイルを満足する（当該パッチを必要とする）か否かを調べるべくチェックする。管理者に、新規パッチおよびそのネットワークへの潜在的影響が通知され、レポート・マトリクスが、どのターゲットがパッチを必要とし、どれが必要としていないかを管理者に知らせる。管理者は、個々のターゲット・コンピュータおよび／またはグループを１つ以上選択し、配布を認める。配布が、本明細書に説明するとおりに進められる。管理者は、配布の時間を設定することができ、インストール後に再起動をするか否かを決定できる。

管理されたデータ・センターのシナリオにおいては、センターの管理者が、データ・サーバの各クラスタからパッチ・グループを生成する。管理者は、マスタ書庫５６７から受け取った重要なアップデートをテストでき、次いでテスト済みのパッチを、一斉または各グループへと段階的に、ネットワークのターゲットに配布できる。エージェント・ポリシーが、管理者による各グループについての動作時間の指定を助けることができる。

実施の形態のアップデートのシナリオでは、当該実施の形態によって使用されるソフトウェアが、当該実施の形態を使用することによってアップデートされる。すなわち、ベンダ（ＰａｔｃｈＬｉｎｋ．ｃｏｍなど）がターゲット・エージェント５０８および／またはアップデート・サーバ５２８のためのソフトウェア、ならびに／あるいは実施の形態の他のソフトウェアへとパッチ５５４を提供し、それらのパッチを本明細書の説明のとおり、オペレーティング・システムまたはユーザ・アプリケーションへのパッチの配布により頻繁に使用されるであろう本発明のツールおよび技法を使用して、配布することができる。たとえば、管理者がＰａｔｃｈＬｉｎｋＨｏｔＦｉｘクライアント・パッチを選択し、クライアント・エージェント・ソフトウェアをアップデートすべく配布することができる。クライアント・エージェントは、それらをすべてのターゲット・コンピュータへと送ることによって最初に配布できる。

（実装に関する覚書）
特定の実施の形態に関するさらなる詳細を、以下に提供する。これらの実装の詳細は、含まれる情報が少なすぎるよりは、たとえ誤りが含まれる可能性があったとしてもより多くの情報を含むように提供される。このように積極的であることによって、出願人が不利益を被ることがあってはならない。とくに、詳細が含まれているからといって、それら詳細、または同様の詳細、あるいは同様のレベルの詳細が、最終的に付与される特許請求の範囲をサポートするために実際に必要であると想定したわけでも、認めたわけでもない。特定の実装の詳細を含むことを、他者によって着想された新規なアイデアを単に実装した者を発明者として扱うことによって誤って解釈してはならない。
エージェント
・マイクロソフトＷｉｎｄｏｗｓ（登録商標）エージェント
・ＮｅｔＷａｒｅエージェント
・Ｌｉｎｕｘ（登録商標）エージェント
・Ｊａｖａ（登録商標）エージェント
パッケージの構成／パッケージの保守
管理者は、指定のアップデート・エージェントによる配布のためにパッケージを生成するためにこのモジュールを使用する。このパッケージは、ディストリビューション・ファイルまたはソフトウェア・パッケージであってよく、指定の管理対象装置の全体にわたる既存のインストール済みソフトウェアのアップデート、新規ソフトウェアのインストール、およびファイルの複製などの際に、さらなる柔軟性を可能にする。

以下は、適切なパッケージ生成のためのステップである。
１．パッケージ仕様の入力
・パッケージ名‐アップデート・プロセス全体を通じてパッケージにラベルを付す。

・パッケージの種類‐ソフトウェア・パッケージ・ルーチンにおいてソフトウェア・パッケージが選択されたとき、パッケージのための供給元ファイルがそれらの適切な目的シーケンスに置かれたのち、管理者はすみやかにパッケージ生成を終了することができる（残りの選択肢についてはあらかじめ指定された初期値を使用する）。ディストリビューション・ファイルは、パッケージ生成ルーチンのすべてのすべてのステップを完了するよう管理者に要求する。

・オペレーティング・システム‐パッケージを配布できるオペレーティング・システムを選択する。現在のところ、パッケージについて１つのオペレーティング・システムを選択できる。それらには、Ｌｉｎｕｘ、ＮｅｔＷａｒｅ、Ｗｉｎｄｏｗｓ２０００（登録商標）／ＷｉｎｄｏｗｓＮＴ（登録商標）、ＷｉｎｄｏｗｓＮＴ（登録商標）、Ｗｉｎｄｏｗｓ９５（登録商標）／Ｗｉｎｄｏｗｓ９８（登録商標）／ＷｉｎｄｏｗｓＭＥ（登録商標）が含まれる。

・（随意による）インポート‐先にエクスポートされたパッケージをインポートする。この選択肢は、複数のオペレーティング・システムのために同じパッケージを生成するために有用である。
２．供給元の追加
・ファイルの追加‐ローカル・ワークステーションまたは到達可能なネットワーク位置からファイルを追加。

・ディレクトリの追加‐ローカル・ワークステーションまたは到達可能なネットワーク位置からディレクトリを追加。

・ＵＲＬを追加‐広く知られたプロトコルによってパッケージにリモート・ファイルを追加。追加することができるさまざまな種類のＵＲＬは、ローカル・ファイル‐Ｆｉｌｅ：／／、ＦＴＰ‐ｆｔｐ：／／、ＨＴＴＰ‐ｈｔｔｐ：／／、およびセキュアＨＴＴＰ‐ｈｔｔｐｓ：／／であり、エージェントが理解できる限りにおいてあらゆるプロトコルを選択できる（このフィールドは編集可能である）。

・除去‐ファイルをパッケージから除去。

・属性‐各ファイルがどのようにアップデート・サーバ内に保存されているかについての詳細を示す。さらに、１つの供給元が（例えばネット・ラグによって）ビジーまたは低速である場合に複数の供給元を可能にする。エージェントは、自動的に他の供給元を試みる。

・ファイルのインポート‐先にエクスポートされたパッケージからファイルの特定のリストをインポートする。
３．目的地の追加
・ターゲット・コンピュータ‐パッケージ・ファイル目的地の階層ツリー表示。示されている種々の初期ディレクトリは、このパッケージがターゲットとしているオペレーティング・システムに依存している。パッケージは、供給元ファイルが最初にインポート（ステップ２を参照）された同じディレクトリ・パスに常に表示される。ファイルを移動させるためには、単にディレクトリまたはファイルを強調表示させ、新しい位置へとドラッグするだけでよい。

・属性‐ファイルをインストールすべきディレクトリが表示されていない場合、ファイルを強調表示させて属性ボタンをクリックする。これにより、供給元ファイルがどこから来ているのかについての基本情報、および目的地の入力フィールドが表示される。新しい位置を打ち込んで「ＯＫ」をクリックすると、なされた変更が表示される（パッケージ・ファイル数が大きい場合、パスが再接続されるために時間がかかるかもしれない）。

・ファイルのエクスポート‐インポート機能における後の使用のため、基本パッケージをファイル（供給元および目的地情報）へとエクスポートする。
４．依存関係
・左欄‐配布の準備ができた既存のパッケージのリスト（オペレーティング・システムに依存）。例えば、多数のコンピュータへと配布しなければならないＪａｖａ（登録商標）ベースのパッケージを有している場合、依存関係として特定のＪＤＫパッケージを選択し、現在のパッケージに先立ってＪＤＫをインストールする。

・右欄‐（矢印ボタンを使用することによって）ここに置かれたパッケージが、貴方のパッケージに依存する。「＋」および「−」ボタンを使用し、依存関係を重要性の順序（最も重要なものが最初の依存関係に位置する）に配置する。依存関係は、貴方のパッケージの前に処理される。

・アセット‐依存関係が発見されない場合、パッケージのインストールは失敗する。例えば、マイクロソフトＯｆｆｉｃｅ２０００ＳＲ１パッケージが生成された場合、そのアセット依存関係はマイクロソフトＯｆｆｉｃｅ２０００であり、すでにインストールされていなければならない。

・インストール‐依存関係が発見されない場合、現在のパッケージのインストールに先立ってそれらをインストールする。上記の例を使用すると、ＭＳＯｆｆｉｃｅ２０００が発見されない場合、ＳＲ１パッケージのインストールに先立ってインストールされる。
５．パッケージ設定
・バックアップ‐目的地装置上で見つかる既存のあらゆるパッケージ・ファイルをバックアップする。編集可能なプルダウン・リストが、当該オペレーティング・システムについて最も一般的なディレクトリを含んでいる。貴方のディレクトリが見つからない場合、単にリストに打ち込むだけでよい。

・信用レベル‐すべての新規パッケージについての初期値は、「新規」である。信用レベルは、このパッケージがテストされたことを示しており、その性能がその信用レベルを決定している。

・利用可能性‐初期値は「利用可能」であり、当該パッケージが配布のために利用可能であることを示している。「利用不可」は、生成されたこのパッケージが配布用として利用できないことを示している。
６．スクリプト
・使用可能な３種類のパッケージ・スクリプトが存在する。コマンド・ライン‐このスクリプトのコンテンツは、標準のコマンド・ラインとして実行される。このスクリプトは、ファイルがそれらの目的地へとコピーされたのちに送信される。前スクリプト‐このスクリプトのコンテンツは、ファイルが装置へとコピーされる前に実行される。後スクリプト‐このスクリプトのコンテンツは、ファイルが装置へとコピーされたのちに実行される。
７．システム設定
・言語‐パッケージを利用できる言語を選択する。次いで、エージェントが当該言語が装置上にあるか確認し、インストール前にパッケージが一致するか確認する。

・プロセッサの種類‐パッケージを利用できるプロセッサを選択する。次いで、エージェントが当該プロセッサが装置上にあるか確認し、インストール前にパッケージが一致するか確認する。
８．終了‐ファイルをアップロードしてパッケージを組み立てるため、「終了」をクリックする。組み立てのプロセスが終了すると、ボタンが「終了」から「完了」に変化する。パッケージ生成機能を完了するため、「完了」をクリックする。

（グループの定義／グループの変更）
このモジュールは、管理者に装置をグループへとまとめさせ、配布の手順をより容易にし、５００の装置への配布を１つの装置への配布のように容易にする。さらに、管理者は、かれらのネットワークについて帯域幅の利用をより効率的にするため、それらの機能または位置に従って装置をグループ化できる。
１．グループ名‐グループのラベル指定。
２．装置リスト‐このグループが含むすべての装置を選択。装置は、アップデート・エージェントがインストールされ登録された後にのみ表示される。
３．終了‐装置がグループに配置されたのち、「終了」ボタンが「完了」に変化する。グループ機能を完了するため「完了」をクリックする。

（配布の計画／既存の配布の閲覧）
配布計画は、パッケージが指定の装置にとって利用可能になる日時を定めている。
１．パッケージの選択
・パッケージ選択リスト‐インストールするパッケージ（この時点では１つだけ）を選択。
２．装置の選択
・グループを追加‐このボタンは、利用可能なグループのリストを示すダイアログ・ボックスを表示する。配布対象とするグループを強調表示させ、「ＯＫ」ボタンをクリックする。

・グループを削除‐パッケージの配布を望まないグループを強調表示させ、「グループを削除」ボタンをクリック。

・装置を追加‐このボタンは、利用可能な装置（登録済みのアップデート・エージェントを備えている）のリストを示すダイアログ・ボックスを表示する。追加する装置を強調表示させ、「ＯＫ」ボタンをクリックする。

・装置を削除‐パッケージの配布を望まない装置を強調表示させ、「装置を削除」ボタンをクリック。

・巻き戻し‐インストール直後のパッケージを除去してバックアップ（指定された場合）へと復帰する。この選択肢は、「既存の配布の閲覧」を介してのみ利用可能である。

・再適用‐パッケージを再インストールする。
３．配布日時の選択
・カレンダー‐配布インストールを行なう日を選択。

・時刻‐パッケージが配布されるサーバ上の時刻。
４．帯域幅および順序の選択
・帯域幅‐このレベルは、パッケージのダウンロードにサーバの帯域幅をどれだけ使用するかを定める。最小値は３０％であり、最大は１００％である。

・順序‐「ＹＥＳ」（初期値）を選択すると、配布プロセスの全体を通じて装置ごとに配布が行なわれ、最後の装置に配布が行なわれたのちに終了する。配布プロセスのどこかでエラーが生じた場合には、配布が停止する。「ＮＯ」を選択すると、すべての装置にパッケージをインストールするよう配布が行なわれる。１つの装置でエラーが生じても、他の装置へのパッケージ配布には影響がない。
５．終了‐配布が生成または更新され、「完了」ボタンをクリックしたのちに保存される。

エージェントの要求は、ＰＯＳＴ法を使用するＨＴＭＬフォームの形式であろう。ホストの応答は、適格なＸＭＬ１．０文書であろう。返される文書の大部分はそのような簡潔な構造であり、ＤＴＤ、名前空間、またはスキーマは含まれていないが、構文的および構造的にはＸＭＬの仕様に従っているであろう。すべての日付および時刻は、協定世界時（ＧＭＴ）に標準化される。

これは、エージェントすなわち要求者と、ホストすなわちアップデート・サービスとの間のトランザクションまたはデータの流れを記述している。すべてのアップデート・トランザクションは、要求計画にかかわらずホストからの作業のリストを要求すべきであるとエージェントに効果的に「Ｐｉｎｇ」または通知するためにホストがエージェントのＩＰアドレスで同意したポートおよびプロトコルを開き、エージェントＩＤを送信し、次いで閉じる場合を除き、エージェントによって開始される。

最初のコンタクト：
アップデート・サーバ５２８のサービスとの対話を必要とするあらゆるエージェントは、常に「／ｕｐｄａｔｅ」サブディレクトリの指定のマスタ・サイトへと要求を行なう。このサブディレクトリは、「３０２オブジェクト移動」およびその「新規」の場所を返すように構成されている。

以下の例に示されるように、エージェントが、ｗｗｗ．ｐａｔｃｈｌｉｎｋ．ｃｏｍサイトの「／ｕｐｄａｔｅ」サブディレクトリ上の「ＨＥＡＤ」要求を実行する。

ＨＥＡＤ要求：
ＨＥＡＤ／ｕｐｄａｔｅｈｔｔｐ／１．１
ホストが、オブジェクトが移動したことを返答し、新規場所は、Ｌｏｃａｔｉｏｎ：ｈｅａｄｅｒによって提供されたアドレスで見つけることができる。

ＩｎｓｔａｌｌＳｈｉｅｌｄエージェント登録：
「アップデート・エージェント」の物理的なインストールの際、管理者は、エージェントがインストールされる前に幾らかの情報を入力するように求められる。管理者は、ホスト名またはＩＰアドレス、アカウント識別子、ＧＵＩＤ（グローバル一意識別子）、ならびにユーザ名および登録時に指定されたパスワードを入力するように求められるであろう。このデータが、エージェント・ソフトウェアをインストールする能力を有効にし、エージェントのＩＤを生成するため、ホストへと送信される。

（エージェント・タスクリスト）
ひとたびＩｎｓｔａｌｌＳｈｉｅｌｄがコンピュータへのＢｏｏｔＳｔｒａｐエージェント・ソフトウェアのインストールに成功すると、エージェントが動作を開始する番である。エージェントは、アップデート・サーバ５２８ホスト・サイト・アドレスを解明したのち、「タスク・リスト」要求を投稿する。「タスク・リスト」は、管理者が当該エージェントが実行するように計画した「タスク」項目の単純なリストである。

ＢｏｏｔＳｔｒａｐエージェントは、
１．初期タスク・リストを要求し、
２．初期タスク・リストを受信し、
３．初期タスク・リストを理解し、
４．完全なエージェントのインストール・ファイルをダウンロードし、
５．エージェント・インストールを実行し、
６．インストールに問題があれば報告し、指示されたとおりに継続し、
７．完全なエージェントを動作開始させ、
８．新規タスク・リストをポーリングし、
９．ソフトウェア・パッケージのＩＤおよび依存関係を理解して、それらソフトウェア・パッケージをダウンロードし、
１０．外部スクリプト・エンジンの呼び出し、またはエージェント内からのスクリプト・エンジンの呼び出しによって、「アクション・スクリプト」を記すこと
ができなければならない。

初期タスク・リスト要求を実行し、返された応答を処理するエージェントが、これを達成する。例えば：
（タスク・リスト要求）

この要求において、エージェントのバージョンは０．０である。これは、これがエージェントの新規インストールであって、ホストがこのエージェントについて適切なエージェント・ソフトウェアの最新バージョンをダウンロードする「タスク」を用意しなければならないことを、ホストに知らせている。続く応答において、これは最初の「タスク」‐タスクＩＤ＝「Ｃ１Ｄ５０１２０‐ＦＦ１３‐１１ｄ３‐９５Ｂ５‐０００６２９５２６４３８」として示されている。

エージェントのポリシーに変更があったときは常に、ホストが当該ポリシー・データを「タスク・リスト」に含める。これが当該エージェントからの最初の要求であるため、当該ポリシー・データがこの応答に含められる。

「ＬｏｃａｌＴｉｍｅ」は、局所的な時間にすぎない（ＧＭＴではない）。これにより、サーバはエージェント装置上の正確な時間を知ることができる、書式はＹＹＹＹＭＭＤＤＨＨＭＭＳＳである。

「Ｓｔａｔｕｓ」は、実行すべきタスクが存在する場合に、タスク・リスト・プロセッサに単純なｙｅｓまたはｎｏの状態のみを返すように告げる。Ｓｔａｔｕｓ＝０は、通常のタスク・リストを返すことを意味する。Ｓｔａｔｕｓ＝１は、エージェントに実行すべきタスクを有するか否かを告げることを意味する。これにより、エージェントは非ＳＳＬで参加することができ、素早くチェックを行なうことができる。

（エージェント・ソフト・パッケージ要求）
最初のタスクは、インストールすべきモジュールが存在することを示している。以下に示すとおり、エージェントは、ホストからの詳細なインストール情報を要求する。

（ソフト・パッケージ要求）

この場合に、エージェントのバージョンが０．０であることに注目すべきである。これは、エージェント・ソフトウェアをアップデートするためのパッケージがタスク・リスト応答に含まれなければならないことを、ホストに知らせている。これにより、利用できるエージェント・ソフトウェアの新規バージョンが存在するときホストが動的に判断し、エージェントを自身をアップデートするように導くことができる。

ホストは、エージェントがタスクを完了できるために必要とする情報の詳細を定めた「オープン・ソフトウェア・ディストリビューション」文書を一緒に置く。

「ソフト・パッケージ（全要素）」
ソフト・パッケージは、考えられるすべてのＸＭＬコンポーネントを示している（バックアップを示す）。

「ソフト・パッケージ状態‐成功」
返却コードＲＣおよびＳｏｆｔＰｋｇＲＣは、１０進形式である。ＳｏｆｔＰｋｇＲＣは、パッケージの全体の完了を意味している。いくつかのモジュールが成功（ＲＣ＝０）したが、他のモジュールがエラーを生じたかもしれない。すでに一度インストールされたパッケージについて配布が試みられた場合、エージェントは、それがインストールしたすべてのモジュールについて（ＲＣ＝０）を返し、（ＳｏｆｔＰｋｇＲＣ＝７２５００３）またはすでにインストールされた０ｘ０００ｂ１００ｂソフト・パッケージを返す。

タスクが完了すると、エージェントは結果でホストを更新する。
要求

「ファイル属性およびＡＣＬ」
この部分では、ＧＸ：目的地（ＧＸ：ＵＲＩ）要素に見られるＧＸ：ＡＣＬ要素を説明する。アップデートにおける属性は、以下で定めるスーパーセット形式でエージェントに供給される。

基本的なファイル属性の実行における問題は、いくつかのファイル・システムが属性とＡＣＬとの間の境界を不明確にする点にある。属性は、ファイルの基本的なＡＣＬであり、ここで定義されるものは、小さなクロス・プラットフォームなスーパーセットである。例えば、Ｗｉｎｄｏｗｓ（登録商標）ＮＴＦＳはリード・オンリー属性フラグを有しているが、さらにリードＡＣＬを有している。したがって、包括的な属性フラグを作ろうとする場合、ＡＣＬとして使用されるときに意味がいくぶん変化させられることを予想しなければならない。Ｕｎｉｘ（登録商標）プラットフォームのそれらは、他のプラットフォームと同様に貴方が理解しないフラグを貴方が無視し、あるいは定義された振る舞いがここに挙げられない点を除き、違いを見せないであろう。

＄ＯＴＨＥＲ、＄ＧＲＯＵＰ、＄ＵＳＥＲという３つの初期設定のＡＣＬが定められ、基本的なファイル属性のように機能する。

Ｕｎｉｘ（登録商標）では、ファイル・システムが、これら３つの属性ＡＣＬがすべて使用する。

しかしながら、ＮＴ、ＦＡＴおよびＮｅｔＷａｒｅは、基本的なファイル属性に＄ＯＴＨＥＲのみを使用する。ＡＣＬの要素データ内の他の名前はすべて、名前として解釈される。

ＸＭＬ構文
これは、ＵｓｅｒについてのＡＣＬを示す。

ＧｒｏｕｐについてのＡＣＬ。＄ＧＲＯＵＰが常にＧｒｏｕｐ＝を使用することに注意すべきである。

「ソフト・パッケージ‐巻き戻し」

この例は、単純なファイル・コピーをすでに示したバックアップで巻き戻す。エージェントは、ＳＯＦＴＰＫＧ要素タグの属性ＧＸ：Ｒｏｌｌｂａｃｋ＝「Ｙ」から巻き戻しを示す。ＧＸ：Ｓｏｕｒｃｅ要素タグは供給されない。

目的地は、バックアップを戻すためのファイル名を含んでいなければならない。（注：巻き戻しに先立ってバックアップ・ファイルが存在しない場合、エラーではない（パッケージが配布されたとき、目的地は存在していなかった）。しかしながら、目的地ファイルが存在し、巻き戻しに先立って削除できない場合、エラーである。）
「プロキシ取得」
時には、エージェントがファイアウォールの背後に、ホスト・サイトへのアクセスのみが許されるような構成でインストールされることがある。エージェントは、ベンダのサイトにあるパッケージのためのモジュールを取り出そうと試みたとき、この場合を検出するであろう。エージェントは、通常のＨＴＴＰ取得では接続を確立できないことを理解したとき、以下に示すとおり「プロキシ取得」要求を使用することによって、エージェントの代理としてファイルを取り出すようホストに依頼することができる。

「要求」

「プロキシ取得の状態」
「要求」

「取得要求」

「ＨＴＴＰ取得」
要求：

「帯域幅の利用」
「範囲指定取得要求」
ＨＴＴＰ／１．１によれば、クライアントは、応答エンティティの一部（或る範囲）のみを応答に含めるように要求できる。ＨＴＴＰ／１．１は、Ｒａｎｇｅヘッダ・フィールドおよびＣｏｎｔｅｎｔ‐Ｒａｎｇｅヘッダ・フィールドにレンジ単位を使用する。エンティティは、種々の構造ユニットに従ってサブレンジに分解できる。

レンジ単位＝バイト単位│他のレンジ単位
バイト単位＝「バイト」
他のレンジ単位＝トークン
ＨＴＴＰ／１．１によって定義されている唯一のレンジ単位は「バイト」である。ＨＴＴＰ／１．１の実装例は、他の単位を使用して指定されたレンジを無視するであろう。ＨＴＴＰ／１．１は、レンジの知識に依存しないアプリケーションの実装を可能にすべく設計されている。

すべてのＨＴＴＰエンティティは、ＨＴＴＰメッセージにおいてバイトのシークエンスとして表わされるため、バイト・レンジの考え方は、あらゆるＨＴＴＰエンティティによって意味がある・
ＨＴＴＰにおけるバイト・レンジの使用は、エンティティ本体（必ずしもメッセージ本体と同じではない）のバイトのシークエンスに当てはまる。バイト・レンジ操作は、ただ１つのバイトのレンジを指定でき、あるいはただ１つのエンティティ内のレンジの組を指定できる。

管理者が帯域幅利用の特徴を、それらをエージェントのポリシー・データにおいて指定することによって選択したとき、エージェントは、単純な取得要求ではなく「レンジ」指定された取得要求を行なう。

以下のエージェント・プロファイルを検討する。

以下に、Ｑ１２３４５．Ｅｘｅファイルの最初の１０２４バイトの要求、およびホストの応答を示す。

要求：

プロキシ取得要求：

「発見エージェントＸＭＬタグ」
＜ｎａｍｅ＞タグ‐これは、捜索しようとするファイルの名称である。

＜ｐａｔｈ＞タグ‐きわめて汎用的である。これは、ファイルを求めて捜索しようとするパスである。

＜Ｖｅｒｓｉｏｎ＞タグ‐これは、捜索しているファイルのバージョンである。

＜ｃｒｅａｔｅｄ＞タグ‐これは、ファイルが生成された日付である。
例＜ｖｅｒｓｉｏｎ＞＞５／３０／２００１１２：０１：０４ＰＭ＜／ｖｅｒｓｉｏｎ＞
注：この正確な日付形式が好ましい。

＜Ｓｉｚｅ＞タグ‐これは、捜索しているファイルのサイズである。注：＜ｏｒ＞することはできない。

＜ｒｏｏｔ＞タグ‐これは、レジストリ・エントリを捜索するためのルート・キーである。

＜Ｋｅｙ＞タグ‐これは、捜索しているレジストリ内のキーである。

＜ｖａｌｕｅ＞タグ‐これは、捜索しているキー内の値である。

＜Ｄａｔａ＞タグ‐これは、当該キーに見つけることが予想されているデータである。

＜ｃｌａｓｓ＞タグ‐意味を成す任意の有効なＷＭＩクラスを指定することができる。例ｗｉｎ３２＿ｓｅｒｖｉｃｅｓ。

＜ｓｅａｒｃｈｆｉｅｌｄ＞タグ‐これは、どのｗｍｉエントリを調べるべきか最もよく決定するフィールドである。

＜ｓｅａｒｃｈｖａｌｕｅ＞タグ‐これは、どのｗｍｉエントリを調べるべきか最もよく決定する値である。

＜ｃｈｅｃｋｆｉｅｌｄ＞タグ‐取得を予想している値を取得すべく調べるためのフィールドである。

＜ｃｈｅｃｋｖａｌｕｅ＞タグ‐発見を予想している値である。

入力ファイルの＜ｒｅｇｉｓｔｒｙ＞セクションの例である。

（パッチ・フィンガプリント署名の例）

上記の例は、レジストリからの見通しパスを発見し、次いでそのサイズを検証するであろう。

（まとめ）
本発明は、ソフトウェア・アップデートが必要とされ、コンピュータが必要なソフトウェアおよびハードウェア・コンポーネントを有しているとき、人間の監視をほとんどあるいはまったく必要とせず、かつクライアントをアップデート対象として有するネットワーク上の管理者装置にソフトウェア・パッチのコピーを必要とせずに、ネットワークを横断してソフトウェアを確実にアップデートし、インストールしたパッチによる問題がインストール時またはインストール後に発見された場合に、関係する装置からそれらを使用可能な状態に維持しつつアップデートを確実に取り除くためのシステム、方法、および構成された記憶媒体を提供する。

本明細書で使用されるとき、「１つの」および「当該」などの用語、ならびに「アップデート・サーバ」などの物品の指定は、示された物品を１つ以上含むことを意味する。とくに請求項において、或る物品への言及は、そのような物品が少なくとも１つ必要であることを意味している。この文書では、物品が正にただ１つであることを意図する場合には、そのようでなければならないと明示する。本発明は、本発明の本質的特徴から離れることなく他の特定の形態に具現化できる。ここに説明した実施の形態は、あらゆる点において、あくまで例示であって本発明を限定するものではないと考えられなければならない。見出しは、あくまで便宜上のものである。特許請求の範囲が、本発明を記載している明細書の一部である。したがって、本発明の技術的範囲は、以上の説明ではなく、添付の特許請求の範囲によって示される。各請求項の意味および均等の範囲内にあらわれるすべての変更は、各請求項の技術的範囲に包含される。ここに請求して特許による保護を望むものは、以下のとおりである。

本発明の利点および特徴を得るためのやり方を示すため、添付の図面を参照しつつ本発明についてさらに詳しく説明する。これらの図は、本発明について選ばれたいくつかの態様のみを示しており、本発明の技術的範囲を限定するものではない。
図１は、本発明による使用に適した多くの分散コンピューティング・システムのうちの１つを示した図である。図２は、本発明によるシステムを示した図である。図３は、本発明による方法を示した図である。図４は、本発明による方法をさらに示した図である。図５は、本発明によるシステムをさらに示した図である。図６は、本発明によるシステムをさらに示した図である。図７は、本発明によるシステムをさらに示した図である。図８は、本発明による方法をさらに示した図である。図９は、本発明によるシステムをさらに示した図である。

Claims

未アップデート状態の第１のターゲット・コンピュータをアップデート前状態のアップデート・サーバへとネットワークを介して接続して有し、かつ前記第１のターゲット・コンピュータにはアクセス不能であるかもしれないが前記アップデート・サーバにはアクセス可能であるパッケージ・コンピュータと、前記第１のターゲット・コンピュータおよび前記アップデート・サーバの両者にアクセス可能である集積所コンポーネントとを有しているシステムにおいて、ソフトウェアを自動的にアップデートするための方法であって、
特定のソフトウェア・アップデートを規定する少なくとも１つのパッチ・フィンガプリントを前記集積所コンポーネントに配置するステップ、
前記第１のターゲット・コンピュータについての情報を収集するステップ、
前記収集した情報の少なくとも一部を前記パッチ・フィンガプリントと比較し、前記特定のソフトウェア・アップデートが前記ターゲット・コンピュータに存在しないか否かを判断するステップと、
前記第１のターゲット・コンピュータを指定しており、かつ前記第１のターゲット・コンピュータのためのソフトウェア・アップデートを収容している前記パッケージ・コンピュータ上の場所を指し示す少なくとも１つのダウンロード・アドレスを指定している少なくとも１つのタスク識別子を、アップデート・タスク・リストに配置するステップ、
・前記タスク識別子に応答し、前記ソフトウェア・アップデートを前記パッケージ・コンピュータから前記アップデート・サーバへとダウンロードするステップ、および
前記アップデート・サーバから前記第１のターゲット・コンピュータへと前記ソフトウェア・アップデートの第２のダウンロードを実行するステップ
を包含する、方法。
持ち運び可能であり、複数のネットワークのアップデート・サーバ上にパッチを複製するために使用できるパッチ定義ファイルを提供するステップ
をさらに包含する、請求項１に記載の方法。
管理者の明示的な指令を必要とせずに前記ダウンロード・ステップを実行することによって事前的に動作する、請求項１に記載の方法。
重要、高優先度、およびセキュリティ関連のうちの少なくとも１つの印が付された印付きのパッチをターゲット・コンピュータへと配布する前に、前記アップデート・サーバにキャッシュすることによって事前的に動作する、請求項１に記載の方法。
パッチのダウンロードを安全にするため暗号化を使用するステップ、
パッチのダウンロードを安全にするため巡回冗長符号を使用するステップ、
パッチのダウンロードを安全にするためデジタル署名を使用するステップ、および
パッチのダウンロードを安全にするためＳＳＬなどのセキュア・ネットワーク・プロトコルを使用するステップ
からなるセキュリティ・ステップのグループから少なくとも２つのステップをさらに含んでおり、前記セキュリティ・ステップの少なくとも１つが特定の方法の実施の形態において利用可能である、請求項１に記載の方法。
前記アップデート・サーバから前記第１のターゲット・コンピュータへと前記ソフトウェア・アップデートをダウンロードするステップが、バックグラウンドのダウンロード・プロセスを使用して実行され、これにより前記第１のターゲット・コンピュータのユーザに対する不便が軽減されている、請求項１に記載の方法。
前記アップデート・サーバから前記第１のターゲット・コンピュータへと前記ソフトウェア・アップデートをダウンロードするステップが、帯域幅を絞ったダウンロードを使用して実行され、これによりネットワーク管理者が大規模な配布時にどの程度の帯域幅を使用すべきか決定できる、請求項１に記載の方法。
ダウンロードが、作業の時間を制限するポリシーのもとで実行され、当該ポリシーは、管理者によって設定され、これにより管理者がいつパッチ配布が許されるかを決定できる、請求項１に記載の方法。
前記アップデート・サーバから前記パッケージ・コンピュータへのソフトウェア・アップデートのダウンロードを防止すること
をさらに含んでおり、これによりパッケージ・コンピュータのセキュリティを高めている、請求項１に記載の方法。
連鎖化されたインストールという特徴の使用をさらに含んでおり、管理者が、そのような特徴を含んでいない場合に必要とされるよりも少ない再起動で、ダウンロードされたパッチをターゲット・コンピュータ上にインストールできる、請求項１に記載の方法。
ダウンロード・ステップの中断を検出し、次いで再接続後に当該ダウンロード・ステップを、当該ダウンロード・ステップにおいて前記中断が生じた点またはその近傍から再開するダウンロード再開という特徴の使用をさらに含んでおり、
これによりダウンロードを達成するためにダウンロード・ステップの全体を反復しなくてもよい、請求項１に記載の方法。
たとえ前記タスク識別子を配置するステップが生じるときに前記第１のターゲット・コンピュータがネットワークに接続されていなくても、管理者による前記第１のターゲット・コンピュータへのパッチの配布を可能にする移動ユーザ・サポートという特徴の使用をさらに包含する、請求項１に記載の方法。
複数のベンダから由来する複数のパッチをダウンロードすることを包含する、請求項１に記載の方法。
グループを形成すべくターゲット・コンピュータからなる適切な部分集合をグループ化するステップをさらに包含し、個々のターゲット・コンピュータへと適用できる操作が、前記グループにも適用可能である、請求項１に記載の方法。
前記グループ化するステップが、管理者によって指定されたターゲット・コンピュータを含むグループを形成する、請求項１４に記載の方法。
前記グループ化するステップが、管理者でないユーザによって指定されたターゲット・コンピュータを含むグループを形成する、請求項１４に記載の方法。
前記グループ化するステップが、オペレーティング・システムを特定することによって指定されるターゲット・コンピュータを含むグループを形成し、当該グループに配されるすべてのターゲット・コンピュータが前記オペレーティング・システムを使用している、請求項１４に記載の方法。
前記グループ化するステップが、アプリケーション・プログラムを特定することによって指定されるターゲット・コンピュータを含むグループを形成し、当該グループに配されるすべてのターゲット・コンピュータが前記アプリケーション・プログラムを使用している、請求項１４に記載の方法。
管理の制御の限られた部分をグループ・マネージャに委譲するステップをさらに含んでおり、当該グループ・マネージャが、前記グループ化ステップによってグループに配されたターゲット・コンピュータのみについての制御を引き受ける請求項１４に記載の方法。
前記第１のターゲット・コンピュータにインストールされるべきソフトウェアを少なくとも部分的に指定する不可欠パッチ最低線ポリシーの使用をさらに包含し、当該不可欠パッチ最低線ポリシーに指定されたパッチを、前記第１のターゲット・コンピュータに事前的にダウンロードおよびインストールする、請求項１に記載の方法。
前記不可欠パッチ最低線ポリシーが、特定のアプリケーションを使用するターゲット・コンピュータについて最低線を設定する、請求項２０に記載の方法。
前記不可欠パッチ最低線ポリシーが、ターゲット・コンピュータからの望ましくないソフトウェアの除去を指令する、請求項２０に記載の方法。
前記第１のターゲット・コンピュータにインストールされてはならないソフトウェアを指定する禁制パッチという特徴の使用をさらに包含し、そのようなインストールの発生を防止すべく試みる、請求項１に記載の方法。
前記不可欠パッチ最低線ポリシーに指定されているパッチのソフトウェアが、前記不可欠パッチ最低線ポリシーの対象であるターゲット・コンピュータから欠落した後、当該パッチを自動的に再インストールすることをさらに包含する、請求項２０に記載の方法。
グループを形成すべくターゲット・コンピュータからなる適切な部分集合をグループ化するステップ、および不可欠パッチ最低線ポリシーを使用して当該グループ内のターゲット・コンピュータにインストールされるべきソフトウェアを少なくとも部分的に指定するステップ、をさらに包含する、請求項１に記載の方法。
前記第１のターゲット・コンピュータ上においてロックされるソフトウェアを指定するパッチ遵守保証という特徴の使用をさらに包含し、ロックされたソフトウェアが前記第１のターゲット・コンピュータから取り除かれる場合、管理者に事前的に通知する、請求項１に記載の方法。
前記ターゲット・コンピュータ上においてロックされる少なくとも１つのアイテムを指定する変更管理という特徴の使用をさらに包含し、ロックされたアイテムが前記第ターゲット・コンピュータにおいて変更される場合、管理者に事前的に通知され、ここで前記アイテムがハードウェア・アイテム、サービス・アイテム、およびソフトウェア・アイテムのうちの少なくとも１つである、請求項１に記載の方法。
少なくとも前記アップデート・サーバから前記第１のターゲット・コンピュータへと前記ソフトウェア・アップデートをダウンロードするステップが繰り返され、これにより少なくとも前記第１のターゲット・コンピュータ上の特定のファイルを繰り返しアップデートする、請求項１に記載の方法。
災害復旧ステップからなるグループからの少なくとも１つのステップであって、システム故障後の復旧および継続動作について管理者を手助けするステップをさらに包含し、
前記災害復旧ステップからなるグループが、故障したサーバと同じドメイン名を有する他のサーバを作り出すステップ、サーバにアップデート・サーバ・ソフトウェアを再インストールするステップ、アーカイブされたデータを復帰させるステップ、およびミラーリングされたデータを復帰させるステップ、からなり、
前記災害復旧ステップの少なくとも１つが特定の方法の実施の形態において利用可能である、請求項１に記載の方法。
最近の操作の記録を保持するステップ、およびパッチの配布を巻き戻すステップ、をさらに包含し、これにより問題を引き起こしたターゲット・コンピュータへのパッチ・インストールを管理者が取り消すことができる、請求項１に記載の方法。
パッチをターゲット・コンピュータのオペレーティング・システムと照らし合わせる複数パッチの知的な配布という特徴の使用をさらに包含し、これによりターゲット・コンピュータにおいて使用されているオペレーティング・システムを明示的かつ完全に特定する必要性から管理者を解放する、請求項１に記載の方法。
前記第１のターゲット・コンピュータにセキュリティ・パッチをインストールし、これによりターゲット・コンピュータのファイル・システムに引っ掛かり、少なくとも１つの特定のファイルのターゲット・コンピュータ上での実行を停止させるポリシー駆動のやり方を管理者に提供する、請求項１に記載の方法。
未アップデート状態の第１のターゲット・コンピュータをアップデート前状態のアップデート・サーバへとネットワークを介して接続して有し、かつ前記第１のターゲット・コンピュータにはアクセス不能であるかもしれないが前記アップデート・サーバにはアクセス可能であるパッケージ・コンピュータと、前記第１のターゲット・コンピュータおよび前記アップデート・サーバの両者にアクセス可能である集積所コンポーネントとを有しているシステムについて、ソフトウェアを自動的にアップデートするための方法の各方法ステップをコンピュータ・システムの少なくとも一部分に実行させるデータおよび命令を表わす構成を有している構成されたプログラム記憶媒体であって、
該方法が、
特定のソフトウェア・アップデートを規定する少なくとも１つのパッチ・フィンガプリントを前記集積所コンポーネントに配置するステップ、
前記第１のターゲット・コンピュータについての情報を収集するステップ、
前記収集した情報の少なくとも一部を前記パッチ・フィンガプリントと比較し、前記特定のソフトウェア・アップデートが前記ターゲット・コンピュータに存在しないか否かを判断するステップ、
前記第１のターゲット・コンピュータを指定しており、かつ前記第１のターゲット・コンピュータのためのソフトウェア・アップデートを収容している前記パッケージ・コンピュータ上の場所を指し示す少なくとも１つのダウンロード・アドレスを指定している少なくとも１つのタスク識別子を、アップデート・タスク・リストに配置するステップ、
前記タスク識別子に応答し、前記ソフトウェア・アップデートを前記パッケージ・コンピュータから前記アップデート・サーバへとダウンロードするステップ、および
前記アップデート・サーバから前記第１のターゲット・コンピュータへと前記ソフトウェア・アップデートの第２のダウンロードを実行するステップ
を包含する、構成されたプログラム記憶媒体。
前記方法が、持ち運び可能であって、複数のネットワークのアップデート・サーバ上にパッチを複製するために使用できるパッチ定義ファイルを提供するステップ、をさらに包含する、請求項３３に記載の構成された記憶媒体。
前記方法が、管理者の明示的な指令を必要とせずに前記ダウンロード・ステップを実行することによって事前的に動作する、請求項３３に記載の構成された記憶媒体。
前記方法が、重要、高優先度、およびセキュリティ関連のうちの少なくとも１つの印が付された印付きのパッチをターゲット・コンピュータへと配布する前に前記アップデート・サーバにキャッシュすることによって事前的に動作する、請求項３３に記載の構成された記憶媒体。
前記方法が、
パッチのダウンロードを安全にするため暗号化を使用するステップ、
パッチのダウンロードを安全にするため巡回冗長符号を使用するステップ、
パッチのダウンロードを安全にするためデジタル署名を使用するステップ、および
パッチのダウンロードを安全にするためＳＳＬなどのセキュア・ネットワーク・プロトコルを使用するステップ
からなるセキュリティ・ステップのグループから少なくとも２つのステップをさらに包含し、前記セキュリティ・ステップの少なくとも１つが特定の方法の実施の形態において利用可能である、請求項３３に記載の構成された記憶媒体。
前記アップデート・サーバから前記第１のターゲット・コンピュータへと前記ソフトウェア・アップデートをダウンロードするステップが、バックグラウンドのダウンロード・プロセスを使用して実行され、これにより前記第１のターゲット・コンピュータのユーザに対する不便が軽減されている、請求項３３に記載の構成された記憶媒体。
前記アップデート・サーバから前記第１のターゲット・コンピュータへと前記ソフトウェア・アップデートをダウンロードするステップが、帯域幅を絞ったダウンロードを使用して実行され、これによりネットワーク管理者が大規模な配布の際にどの程度の帯域幅を使用すべきか決定できる、請求項３３に記載の構成された記憶媒体。
ダウンロードが、作業の時間を制限するポリシーのもとで実行され、当該ポリシーは管理者によって設定され、これにより管理者がいつパッチ配布が許されるかを決定できる、請求項３３に記載の構成された記憶媒体。
前記方法が、前記アップデート・サーバから前記パッケージ・コンピュータへのソフトウェア・アップデートのダウンロードを防止することをさらに包含し、これによりパッケージ・コンピュータのセキュリティを高めている、請求項３３に記載の構成された記憶媒体。
前記方法が、連鎖化されたインストールという特徴の使用をさらに包含し、管理者が、そのような特徴を含んでいない場合に必要とされるよりも少ない再起動で、ダウンロードされたパッチをターゲット・コンピュータ上にインストールできる、請求項３３に記載の構成された記憶媒体。
前記方法が、ダウンロード・ステップの中断を検出するとともに、次いで再接続後に当該ダウンロード・ステップを当該ダウンロード・ステップにおいて前記中断が生じた点またはその近傍から再開するダウンロード再開という特徴の使用をさらに包含し、これによりダウンロードを達成するためにダウンロード・ステップの全体を反復しなくてもよい、請求項３３に記載の構成された記憶媒体。
前記方法が、たとえ前記タスク識別子を配置するステップが生じるときに前記第１のターゲット・コンピュータがネットワークに接続されていなくても、管理者による前記第１のターゲット・コンピュータへのパッチの配布を可能にする移動ユーザ・サポートという特徴の使用をさらに包含する、請求項３３に記載の構成された記憶媒体。
前記方法が、複数のベンダから由来する複数のパッチをダウンロードすることを包含する、請求項３３に記載の構成された記憶媒体。
前記方法が、グループを形成すべくターゲット・コンピュータからなる適切な部分集合をグループ化するステップをさらに包含し、個々のターゲット・コンピュータへと適用できる操作が、前記グループにも適用可能である請求項３３に記載の構成された記憶媒体。
前記グループ化するステップが、管理者によって指定されたターゲット・コンピュータを含むグループを形成する、請求項４６に記載の構成された記憶媒体。
前記グループ化するステップが、管理者でないユーザによって指定されたターゲット・コンピュータを含むグループを形成する請求項４６に記載の構成された記憶媒体。
前記グループ化するステップが、オペレーティング・システムを特定することによって指定されるターゲット・コンピュータを含むグループを形成し、当該グループに配されるすべてのターゲット・コンピュータが前記オペレーティング・システムを使用している、請求項４６に記載の構成された記憶媒体。
前記グループ化するステップが、アプリケーション・プログラムを特定することによって指定されるターゲット・コンピュータを含むグループを形成し、当該グループに配されるすべてのターゲット・コンピュータが前記アプリケーション・プログラムを使用している、請求項４６に記載の構成された記憶媒体。
前記方法が、管理の制御の限られた部分をグループ・マネージャに委譲するステップをさらに包含し、当該グループ・マネージャが、前記グループ化ステップによってグループに配されたターゲット・コンピュータのみについての制御を引き受ける、請求項４６に記載の構成された記憶媒体。
前記方法が、前記第１のターゲット・コンピュータにインストールされるべきソフトウェアを少なくとも部分的に指定する不可欠パッチ最低線ポリシーの使用をさらに包含し、当該不可欠パッチ最低線ポリシーに指定されたパッチを、前記第１のターゲット・コンピュータに事前的にダウンロードおよびインストールする、請求項３３に記載の構成された記憶媒体。
前記不可欠パッチ最低線ポリシーが、特定のアプリケーションを使用するターゲット・コンピュータについて最低線を設定する、請求項５２に記載の構成された記憶媒体。
前記方法が、前記不可欠パッチ最低線ポリシーに指定されているパッチのソフトウェアが、前記不可欠パッチ最低線ポリシーの対象であるターゲット・コンピュータから欠落した後、当該パッチを自動的に再インストールすることをさらに包含する、請求項５２に記載の構成された記憶媒体。
前記方法が、グループを形成すべくターゲット・コンピュータからなる適切な部分集合をグループ化するステップ、および不可欠パッチ最低線ポリシーを使用して当該グループ内のターゲット・コンピュータにインストールされるべきソフトウェアを少なくとも部分的に指定するステップ、をさらに包含する、請求項３３に記載の構成された記憶媒体。
前記方法が、前記第１のターゲット・コンピュータ上においてロックされるソフトウェアを指定するパッチ遵守保証という特徴の使用をさらに包含し、ロックされたソフトウェアが前記第１のターゲット・コンピュータから取り除かれる場合に管理者に事前的に通知する、請求項３３に記載の構成された記憶媒体。
前記方法が、前記ターゲット・コンピュータ上においてロックされる少なくとも１つのアイテムを指定する変更管理という特徴の使用をさらに包含し、ロックされたアイテムが前記第ターゲット・コンピュータにおいて変更される場合に管理者に事前的に通知し、ここで前記アイテムがハードウェア・アイテム、サービス・アイテム、およびソフトウェア・アイテムのうちの少なくとも１つである請求項３３に記載の構成された記憶媒体。
少なくとも前記アップデート・サーバから前記第１のターゲット・コンピュータへと前記ソフトウェア・アップデートをダウンロードするステップが繰り返され、これにより少なくとも前記第１のターゲット・コンピュータ上の特定のファイルを繰り返しアップデートする、請求項３３に記載の構成された記憶媒体。
前記方法が、災害復旧ステップからなるグループからの少なくとも１つのステップであって、システム故障後の復旧および継続動作について管理者を手助けするステップをさらに包含し、
前記災害復旧ステップからなるグループが、故障したサーバと同じドメイン名を有する他のサーバを作り出すステップ、サーバにアップデート・サーバ・ソフトウェアを再インストールするステップ、アーカイブされたデータを復帰させるステップ、およびミラーリングされたデータを復帰させるステップ、からなり、
前記災害復旧ステップの少なくとも１つが特定の方法の実施の形態において利用可能である、請求項３３に記載の構成された記憶媒体。
前記方法が、最近の操作の記録を保持するステップ、およびパッチの配布を巻き戻すステップをさらに包含し、これにより問題を引き起こしたターゲット・コンピュータへのパッチ・インストールを管理者が取り消すことができる、請求項３３に記載の構成された記憶媒体。
前記方法が、パッチをターゲット・コンピュータのオペレーティング・システムと照らし合わせる複数パッチの知的な配布という特徴の使用をさらに包含し、これによりターゲット・コンピュータにおいて使用されているオペレーティング・システムを明示的かつ完全に特定する必要性から管理者を解放する、請求項３３に記載の構成された記憶媒体。
前記方法が、前記第１のターゲット・コンピュータにセキュリティ・パッチをインストールし、これによりターゲット・コンピュータのファイル・システムに引っ掛かり少なくとも１つの特定のファイルのターゲット・コンピュータ上での実行を停止させるポリシー駆動のやり方を管理者に提供する、請求項３３に記載の構成された記憶媒体。