(57)【要約】ネットワークの中のクライアントを最近状態に維持するために、Ｐ２Ｐレメディエーションが提供される。ネットワーク・クライアントは、Ｐ２Ｐの接続を確立するときに、状態情報を交換する。この状態情報により、１つのクライアントが別のものよりも古いかどうかを相互に識別することが可能になる。より新しいクライアントは、より古いクライアントに更新情報を提供する。更新プロセスの保全性を保存するために、更新は、符号付きバイナリ・ファイルとして提供され、バイナリ・ファイルが受信者によって認証可能である場合にだけ、更新を受け取るクライアントによって適用される。
2009520252.tif 000002
【特許請求の範囲】
【請求項１】
第１のクライアントと第２のクライアントとを有するコンピュータ・システムの動作方法であって、
ａ）前記第１のクライアントと前記第２のクライアントとの間の通信を開始するステップであって、前記第１のクライアントにおいて前記第２のクライアントから更新状態を受信するステップを含む、ステップと、
ｂ）前記第１のクライアントと前記第２のクライアントとの間の相対的な更新状態を確認するステップと、
ｃ）前記相対的な更新状態に基づいて、前記第１のクライアントから前記第２のクライアントへ更新情報を通信するステップと、
を含むことを特徴とする方法。
【請求項２】
請求項１記載の方法において、更新情報を通信する前記ステップは、符号付きファイルを送信するステップを含むことを特徴とする方法。
【請求項３】
請求項２記載の方法において、前記符号付きファイルは、前記第２のクライアントにおいて動作するソフトウェアのためのパッチを含むことを特徴とする方法。
【請求項４】
請求項１記載の方法において、更新情報を通信する前記ステップは、前記第２のコンピュータが用いることができる情報を送信するステップを含むことを特徴とする方法。
【請求項５】
請求項１記載の方法において、更新情報を通信する前記ステップは、第２のクライアントが前記第１のクライアントと比較して古いという指示を送信するステップを含むことを特徴とする方法。
【請求項６】
請求項１記載の方法において、前記第１のクライアントと前記第２のクライアントとの間の通信を開始する前記ステップは、ＩＰｓｅｃセッションを開始するステップを含むことを特徴とする方法。
【請求項７】
請求項１記載の方法において、
ｄ）前記第１のクライアントにおいて動作しているソフトウェアにインストールされているパッチに関する状態情報を決定するステップを更に含んでおり、
ｉ）前記第２のクライアントから前記更新状態を受信する前記ステップは、前記第２のクライアントにインストールされているパッチを識別する第２の状態情報を受信するステップを含み、
ｉｉ）前記第２のクライアントが古いかどうかを確認する前記ステップは、前記更新状態情報と前記第２の更新状態情報とを比較するステップを含むことを特徴とする方法。
【請求項８】
請求項７記載の方法において、通信を開始する前に更新サーバから前記第１のクライアントにパッチをダウンロードするステップを更に含むことを特徴とする方法。
【請求項９】
第１のクライアントと第２のクライアントとを有するコンピュータ・システムの動作方法であって、
ａ）前記第１のクライアントと前記第２のクライアントとの間の通信を開始するステップであって、前記第２のクライアントに対する更新状態を前記第２のクライアントから送るステップを含む、ステップと、
ｂ）前記第２のクライアントにおいて、更新情報を前記第１のクライアントから受信するステップと、
を更に含むことを特徴とする方法。
【請求項１０】
請求項９記載の方法において、更新情報を受信する前記ステップは、符号付きファイルを受信するステップを含むことを特徴とする方法。
【請求項１１】
請求項１０記載の方法において、第２のクライアントにおいて、
ｄ）前記符号付きファイルは信頼できるかどうかをチェックするステップと、
ｅ）前記符号付きファイルが信頼できる場合には、前記符号付きファイルを用いて更新を前記第２のクライアントにインストールするステップと、
を更に含むことを特徴とする方法。
【請求項１２】
請求項１０記載の方法において、第２のクライアントにおいて、
ｄ）前記符号付きファイルは信頼できるかどうかをチェックするステップと、
ｅ）前記符号付きファイルが信頼できない場合には、更新を前記第２のクライアントに更新サーバからダウンロードするステップと、
を更に含むことを特徴とする方法。
【請求項１３】
請求項９記載の方法において、
ｄ）前記第１のクライアントにおいて動作しているソフトウェアにインストールされたパッチに関する前記第１のクライアントの状態情報を決定するステップと、
ｅ）前記第２のクライアントに対する前記更新状態と前記第１のクライアントの状態情報とに基づいて、前記第２のクライアントは前記第１のクライアントと比較して古いという指示を前記第１のクライアントから前記第２のクライアントに送信するステップと、
を更に含むことを特徴とする方法。
【請求項１４】
請求項１３記載の方法において、通信を開始する前に更新サーバから前記第１のクライアントを更新するステップを更に含むことを特徴とする方法。
【請求項１５】
コンピュータ実行可能な命令を有するコンピュータ可読媒体であって、前記コンピュータ実行可能な命令は、
ａ）前記コンピュータ実行可能な命令が実行される第１のクライアント・コンピュータの更新状態を確認するステップと、
ｂ）更新状態を第２のクライアント・コンピュータから受信するステップと、
ｃ）前記第１のクライアント・コンピュータと比較して前記第２のクライアント・コンピュータが古いかどうかを判断するステップと、
ｄ）更新を前記第２のクライアント・コンピュータに通信するステップと、
を実行するためのものであることを特徴とするコンピュータ可読媒体。
【請求項１６】
請求項１５記載のコンピュータ可読媒体において、更新ファイルに記憶された更新情報を更に有しており、更新を通信する前記ステップは更新ファイルを送信するステップを含むことを特徴とするコンピュータ可読媒体。
【請求項１７】
請求項１６記載のコンピュータ可読媒体において、前記更新ファイルはウイルス署名を含むことを特徴とするコンピュータ可読媒体。
【請求項１８】
請求項１６記載のコンピュータ可読媒体において、
ｅ）前記第２のクライアント・コンピュータから第２の更新を受信するステップと、
ｆ）前記第２の更新ファイルの真正性を確認するステップと、
を含むステップを実行するコンピュータ実行可能な命令を更に有していることを特徴とするコンピュータ可読媒体。
【請求項１９】
請求項１８記載のコンピュータ可読媒体において、真正性を確認する前記ステップは、鍵を前記第２の更新ファイルに適用するステップを更に含むことを特徴とするコンピュータ可読媒体。
【請求項２０】
請求項１９記載のコンピュータ可読媒体において、前記第２の更新ファイルは、前記コンピュータ可読媒体に記憶されているオペレーティング・システム・ソフトウェアのためのパッチを含むことを特徴とするコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野及び背景技術】
【０００１】
現代の生活のすべての面においてコンピュータ・システムの役割が拡大するにつれて、コンピュータ・システムの保全性（integrity）の維持は、ますます重要な機能になってきている。同時に、コンピュータ・システムに対する脅威は高まっている。ネットワーク化された複数のコンピュータ・システムは、情報を盗む又はコンピュータ・システムの動作を妨げる意図を有する「ウイルス」、「スパイウェア」及び「ハッカー」によってもたらされる脅威に対して特に脆弱である。
【０００２】
ネットワーク化された複数のコンピュータ・システムの保全性を向上させるためのアプローチの１つとして、防護ソフトウェアの使用によるものがある。ネットワークに接続するクライアントは、それぞれが、ネットワーク化されたコンピュータ・システムに対する脅威を検出し妨害することが可能なソフトウェアを備えている。ファイアウォール、アンチウイルス・ソフトウェア及びアンチスパイウェア・ソフトウェアなどが、ネットワーク・クライアントにおいて広く用いられている防護ソフトウェアの例である。これらの防護ソフトウェアの欠点は、完全に有効となるためには、脅威が作成されるのと同時に、そのような新しい脅威に対処するようにソフトウェアを更新しなければならないということである。
【０００３】
容易な更新を促進するために、防護ソフトウェアは、ソフトウェアが検出する又は防ぐことができる脅威の仕様を保持するデータ・ファイルを含むことが多い。これらのデータ・ファイルは、サーバから、新しい脅威について記述している新しいファイルをダウンロードすることなどによって、容易な更新が可能である。それにもかかわらず、ネットワークに接続されているそれぞれのクライアントのオペレータは、クライアントを最新にしておくために処置を講じなければならない。オペレータは、周期的に新しいデータファイルをダウンロードするなど、明確な処置を講じる。あるいは、オペレータは、自動的に新しいデータファイルをダウンロードするように防護ソフトウェアを構成することができる。ときには、オペレータは、防護ソフトウェアを適切に更新、操作又は構成しないことにより、脆弱性を放置してしまうことがある。
【０００４】
防護ソフトウェアの不適切な使用によって生じる脆弱性は、「検疫」アプローチを通じて、対処がなされることがある。ネットワークにアクセスしようとするクライアントは、最新の防護ソフトウェアを有していない場合には、アクセスを拒否されるか、又は、「検疫」がなされる。検疫がなされたクライアントは、サーバから当該防護ソフトウェアに更新をダウンロードするなどによってコンピュータを「修正（remediate、レメディエート）」することが可能である程度に、ネットワークへの制限付きのあるアクセスを与えられる。
【発明の概要】
【０００５】
本発明は、ネットワークの中にある複数のクライアント・コンピュータの間での更新情報の共有に関する。
【０００６】
ある側面では、本発明は、第１のクライアントと第２のクライアントとの間の通信を開始することに関する。第１のクライアントと第２のクライアントとの間の相対的な更新状態が判断される。この相対的な更新状態に基づいて、第１のクライアントは、第２のクライアントに更新情報を送る。
【０００７】
別の側面では、本発明は、コンピュータ・システムの動作方法に関するものであり、このコンピュータ・システムでは、第２のクライアントの更新状態に関する情報が第２のクライアントから第１のクライアントへ送られる。第２のクライアントが第１のクライアントと比較して古い場合には、第２のクライアントは、第２のクライアントにインストール可能な更新情報を第１のクライアントから受け取る。
【０００８】
更に別の側面では、本発明は、コンピュータ実行可能な命令を有するコンピュータ可読媒体に関する。当該コンピュータ実行可能な命令は、これらの命令が実行されるクライアントを制御する。このクライアントは、第２のクライアントから更新状態を受け取る。第２のクライアントが第１のクライアントと比較して古い（out-of-date）である場合には、第１のクライアントは更新情報を通信する。
【０００９】
以上は、本発明を限定することは意味しない概要である。本発明の外延は、特許請求の範囲の記載によって決定される。
【発明を実施するための最良の形態】
【００１０】
最新のソフトウェアを含んでおらず使用しないためにシステムの能力をそれらがネットワークに危険をもたらす治療上のクライアントに増加させることによって、ネットワーク化されたコンピュータ・システムの保全性を増加させることが望ましい。しかし、保護のレベルのどのように増加させても不合理なほどにネットワーク又はネットワーク・ユーザに負担させることになるから、容易に処理されるべきである。後述するように、改善された検疫管理システムが提供され、このシステムでは、クライアント・コンピュータは、ピアツーピア通信の一部として状態及び改善情報を比較される。
【００１１】
ここに用いている検疫実施方針とは、クライアントが当該クライアントにおけるソフトウェアの状態（これは、クライアントの「健康」と呼ばれる）に基づいて、ネットワークへのアクセスを与えられるかどうかを判断するロジックを意味する。この方針は、クライアントがネットワーク・アクセスを与えられために満足しなければならない基準又は規則の組として、データ構造に格納される。しかし、検疫実施方針を定義するものであれば、どんな適切な方法も使用されてもよい。更に、検疫実施方針は、より大きなアクセス制御方針の一部でもありうる。従って、検疫実施方針に基づいたネットワーク・アクセスの許可又は否認の基準は、クライアントが他の理由でアクセスを与えられないか与えられる可能性を排除しない。
【００１２】
図１は、コンピュータ・システム１００のスケッチを示す。このシステムは、従来のコンピュータ・システムズの中で用いられるデバイスから構築可能である。しかし、コンピュータ・システム１００は、コンピュータ・システム１００内のデバイスが、クライアントが「Ｐ２Ｐ」コミュニケーションでの改善情報を交換することがある改善された検疫マネジメントシステムをインプリメントするようにプログラムされている点で、従来のコンピュータ・システムと異なる。
【００１３】
ここに用いられている「Ｐ２Ｐ」通信とは、ネットワーク内の２つのクライアントの間での通信を指す。その通信は、これらのクライアントの間で直接になされることがあるし、又は、他のネットワーク・デバイスを通過してルーティングされることもある。更に、ネットワーク中で接続しているデバイスが異なる時に異なる機能を行なうようにプログラムされることがあるので、ネットワークの「ピア（仲間）」は、どのような特定のハードウェア構成にも制限されていない。いくつかの例では、ハードウェアは、サーバとして機能することがあるし、ネットワークにおいて別の役割を有する場合があるし、ネットワーク・ピアとして機能することがある。
【００１４】
コンピュータ・システム１００は、管理されたネットワーク１２０を含む。この例においては、管理されたネットワーク１２０とは、会社又は企業内のネットワークであることがある。あるいは、管理されたネットワーク１２０は、ドメインであったり、より大きなネットワークの別の部分であることがある。管理されたネットワーク１２０は、ネットワークのためにアクセス方針を提供する個人か企業によって管理される。これらのネットワーク管理機能を提供する人や企業は、一般に、「ネットワーク・アドミニストレータ」と呼ばれる。ネットワーク化されたコンピュータ・システムでは、ネットワーク管理機能を提供する複数の人間又は企業が存在する場合があり、これらのすべてが、広く、ネットワーク・アドミニストレータと呼ばれることがある。
【００１５】
図１に示されるように、管理されたネットワーク１２０は、サーバ１２４及びクライアント１１０Ｂ及び１１０Ｃのようなネットワーク・デバイスを含む。ここで、ワイド・エリア・ネットワーク（ＷＡＮ）１２２は、ネットワーク・デバイスを相互に連結させた状態で示される。この構成は、図面の簡潔性を意図したものである。管理されたネットワークは、図１で示されたよりも多くのデバイスを含むことがある。同様に、単一のＷＡＮ１２２が示されているが、管理されたネットワークは、別の追加的な相互接続アーキテクチャを含むことがある。
【００１６】
デバイスは、アクセス・ポイント１１６を経由して管理されたネットワーク１２０に接続することがある。クライアント１１０Ｂ及び１１０Ｃの各々は、管理されたネットワーク１２０におけるアクセス・ポイント１１６又は他の同様のアクセス・ポイントを通って同様に接続されることがある。図１の例では、クライアント１１０Ｂ及び１１０Ｃが管理されたネットワーク１２０へのアクセスを既に与えられていることを示している。従って、アクセス・ポイントによるそれらの接続は明らかに示されていない。クライアント１１０Ｂ及び１１０Ｃは、ネットワーク１２０において相互にピア（仲間）である。
【００１７】
図１は、アクセス・ポイント１１６を通って管理されたネットワーク１２０に接続しようとしているクライアント１１０Ａを示す。アクセス・ポイント１１６は、ワイヤレス・アクセス・ポイント、ハードワイアード・アクセス・ポイント又は他のアクセスのタイプポイントなど、従来型又は今後開発されるものである。図１の例では、アクセス・ポイント１１６は、スイッチ素子１１８及びサーバ１１２を含む。
【００１８】
スイッチ素子１１８は、アクセス・ポイントに統合されることがあるスイッチ素子の多くのタイプのうちのいずれかを表わす。スイッチ素子１１８は、ルータ、スイッチ、ハブ、ゲートウエイ又は他の適切なスイッチ素子などのデバイスである。
【００１９】
動作においては、サーバ１１２は、アクセス・コントロール・サーバとして働く。サーバ１１２Ａは、「ＲＡＤＩＵＳ」サーバ、「ＩＡＳ」サーバ、又は、レベル２のアクセス・コントロール・サーバと習慣的に呼ばれるなサーバである。しかし、適切にプログラムされていれば、どんなサーバも使用できる。サーバ１１２は、検疫実施方針に従ってネットワーク・アクセスを与えるか否定するように、プログラムされる。クライアント１１０Ａのようなクライアントが管理されたネットワーク１２０へのアクセスを求めると、サーバ１１２は、クライアント１１０Ａが管理されたネットワーク１２０へのアクセスを与えられるべきかどうかを判断する。
【００２０】
アクセス・ポイント１１６は、ここで管理されたネットワーク１２０へのアクセスを与えられなかったとしても、ネットワーク又は管理されたネットワーク１２０の外側のデバイスにクライアント１１０Ａが接続することが可能であることが示される（つまり、クライアントは「検疫」される）。図１で示された実施例では、スイッチ素子１１８は、クライアント１１０Ａがインターネット１３０にアクセスすることを可能にする。インターネット１３０によって、クライアント１１０Ａは、サーバ１５０のようなデバイスに達することができる。
【００２１】
サーバ１５０は更新サーバとして働く。図解されている実施例では、サーバ１５０はデータベース１５２につながれる。データベース１５２は、クライアント１１０Ａの上で実行するソフトウェア用ソフトウェア・アップデートを含む。データベース１５２に格納された更新は、クライアント１１０Ａの「健康」を変更することがあるアンチウイルスソフトウェア、反スパイウェア・ソフトウェア又は他のソフトウェアへの更新を含む。その防護ソフトウェアが古くてクライアント１１０Ａが管理されたネットワーク１２０へのアクセスを与えられない場合、クライアント１１０Ａは、それにもかかわらず更新サーバ１５０に接続し、その防護ソフトウェアへの更新を得ることができる。
【００２２】
データベース１５２は、ソフトウェア・アップデートをクライアント１１０Ａ上で防護ソフトウェアで動作するためにダウンロードされるデータ・ファイルの形で含むことがある。例えば、ウィルス署名又は他の脅威的な署名を含むデータファイルは、アンチウイルスのプログラム又はアンチスパイウェア・プログラムと協力する使用のためにダウンロードされることがある。あるいは、データベース１５２は、クライアント１１０Ａの上で実行する防護ソフトウェアのためのパッチを含むことがある。パッチは通常圧縮形での最新のソフトウェアの表現であり、ソフトウェア・プログラム及び後のバージョンの１つのバージョン間の違いのエンコードにより作られることが多い。
【００２３】
更に、データベース１５２は、クライアント１１０Ａの上で実行するオペレーティング・システム又は他の汎用ソフトウェアのためのパッチを含むことがある。オペレーティング・システム・ソフトウェアは一般に防護ソフトウェアと見なされないが、オペレーティング・システム・ソフトウェアの状態は、クライアント・コンピュータ１１０Ａの健康に深刻な影響を及ぼすことがある。例えば、ハッカーは、オペレーティング・システム・ソフトウェア中の弱点を発見し、開発を行うことがある。これを受けて、汎用ソフトウェア中の脆弱性が識別されるとともに、ソフトウェアのベンダはそのような脆弱性を削除するためにソフトウェアを修正するパッチ又は他の更新を出す。従って、クライアントがパッチをインストールした範囲（特に脆弱性の削除に向けられたパッチの場合）は、クライアントの健康の指示と見なされることがある。いくつかの実施例では、アクセス・サーバ１１２は、検疫実施方針を実行するようにプログラムされる。その場合、管理されたネットワーク１２０にアクセスする、汎用ソフトウェア中の脆弱性に向けられたパッチがクライアントにインストールされたかどうかが、少なくとも一部分は基づいて、与えられるか否定される。次の例では、オペレーティング・システム・ソフトウェアへのパッチは、クライアントの健康を増進するためにクライアントに適用されることがあるソフトウェア・アップデートの例として用いられる。しかし、更新は、ソフトウェアの実行可能な部分又はそのソフトウェアによって用いられるデータに提供されることがある。
【００２４】
クライアント１１０Ａは、クライアント１１０Ａを操作するユーザからのコマンドに応じて、更新サーバ１５０からのソフトウェア・アップデートをアクセスする。あるいは、クライアント１１０Ａは、管理されたネットワーク１２０へのアクセスを与えられないことに応じて、自動的に更新サーバ１５０にアクセスするようにプログラムされることがある。このように、管理されたネットワーク１２０へのアクセスのための資格を得るように、管理されたネットワーク１２０に認められる十分な健康を欠くクライアントは、それにもかかわらず「修正（レメディエート）」される。
【００２５】
図２を参照すると、クライアント１１０Ａとアクセスサーバ１１２との中のソフトウェアのソフトウェア・ブロック図が示されている。図解されている実施例中で、ソフトウェアは複合成分としてインプリメントされる。多数のコンピュータ実行可能命令がコンピューティング・デバイスにアクセス可能なコンピュータ可読媒体に格納されたり、コンポーネントは、それぞれインプリメントされることがある。コンポーネントは任意の適切な言語でインプリメントされることがあり、任意の適切なコンピューティング装置上で動作可能である。伝統的なプログラミング技術を用いて、より非常に詳しくここに記述された機能をインプリメントすることができる。
【００２６】
ソフトウェアが、検疫実施方針（それはネットワーク・アドミニストレータによって指定されることがある）に従って動作するネットワーク中のデバイスを制御する。クライアント・ソフトウェアの更新状態は、与えられた例（クライアントが方針に従ってネットワークへのアクセスを保証するかどうか判断する際に熟慮した少なくとも１つの要因）においてある。クライアント１１０Ａの中のソフトウェアの最新状況が検疫実施方針に応じないことをアクセスサーバ１１２が決めれば、サーバ１１２はクライアント１１０Ａへのアクセスを否定する。その後、検疫実施方針にそれ自体を対応させるために、クライアント１１０Ａは更新サーバ１５０からパッチをダウンロードする。クライアント１１０Ａは、パッチを得るための更新エージェント２１４を含む。
【００２７】
アップデート・エージェント２１４は、クライアント１１０Ａの中のオペレーティングシステム・ソフトウェアのためにパッチを得てインストールするために更新サーバ１５０にアクセスするソフトウエアコンポーネントである。更新エージェント２１４は、周期的に例えば、クライアント１１０Ａにまだインストールされていない新しいパッチをチェックする更新サーバ１５０にアクセスすることが許容されたクライアント１１０Ａのユーザを刺激することがある。あるいは、更新エージェント２１４は、更新処理を始めるどんな処置も講ずることはクライアント１１０Ａのユーザーに要求せず、周期的にパッチを袖手して自動的な方法で動作することがある。
【００２８】
図解されている実施例では、クライアント１１０Ａは、検疫エージェント２１０Ａを含む。検疫エージェント２１０Ａは、クライアント１１０Ａの状態に関する情報を集め、健康声明２３０としてアクセス・サーバ１１２において動作する検疫エージェント２１０Ｂにこの状態情報を提供する。健康声明２３０は、クライアント１１０Ａが検疫実施方針に従って管理されたネットワーク１２０にアクセスする権利を与える健康を持っているかどうか判断するために、検疫エージェント２１０Ｂに必要か望ましいどんな情報も含むことがある。
【００２９】
図解されている実施例では、健康声明２３０に反映されていた状態情報は、クライアント１１０Ａのオペレーティング・システムにソフトウェアの最新状況を定義する。典型的な実施例では、健康声明２３０の情報の一部は、クライアント１１０Ａのオペレーティング・システムにインストールされたパッチについて説明している。しかし、検疫実施方針は要因を考慮する代わりに、オペレーティング・システム・ソフトウェアの更新状態を追加することがある。従って、健康声明２３０は、多数のタイプの情報を定義する多数のフィールドを含むことがある。簡単な例として、ソフトウェアのパッチ状態だけが健康声明２３０の更新情報の１つの例として述べられている。
【００３０】
図２に示される例では、モジュール方式が用いられる。複数のシステム健康エージェント（ＳＨＡ）２１６Ａ、２１６Ｂ及び２１６Ｃが図解されている。ＳＨＡは、それぞれが、特定のタイプの状態情報を得る。例えば、１つのＳＨＡは、ファイアウォール・ソフトウェアに関する（別のＳＨＡがアンチスパイウェア・ソフトウェアに関する情報を得ることがあるのに対して）状態情報を得ることがある。しかし、別のＳＨＡは、クライアント１１０Ａの中のオペレーティング・システム・ソフトウェアのパッチ状態に関する情報を得る。
【００３１】
それぞれのＳＨＡによって得られた状態情報は、セキュリティ・センタ２１２を通って送られる。セキュリティ・センタ２１２は、状態情報を集め、エージェント２１０Ａを検疫するためにそれを提供する。このように、状態情報は、その防護ソフトウェアから又はその防護ソフトウェアに関して状態情報を得ることを目指したＳＨＡを組込むことにより、クライアント１１０Ａの中の任意の防護ソフトウェアに関して得られる。
【００３２】
少なくとも１つのＳＨＡは、クライアント１１０Ａの中のオペレーティング・システム・ソフトウェアに関するパッチ状態情報を得る。そのようなＳＨＡは、更新エージェント２１４によって生成された情報に基づいたパッチの状態を決定する。パッチを決定する任意の適切な方法として、クライアントの状態が使用されてもよい。図２の例では、パッチ・レジストリ２２２が用いられる。パッチ・レジストリ２２２は、クライアント１１０Ａの中のデータ構造として実行されることがある。パッチをインストールする際には、更新エージェント２１４は、パッチ・レジストリ２２２に記入する。パッチ・レジストリ２２２は、更新エージェント２１４によって適用されたパッチの指示の格納に加え、パッチが作られたか、得られたか、インストールされた時のようなクライアント１１０Ａのパッチ状態を追跡するのに役立つ他の情報を格納することがある。
【００３３】
クライアント１１０Ａにインストールされたパッチに関する情報の入手可能性は、それがパッチをインストールする時、更新エージェント２１４によって格納された情報を読むことにより、ＳＨＡがパッチ状態情報を生成することを可能にする。従って、インストールされたパッチに関する情報は、クライアント１１０Ａからアクセス・サーバ１１２にクライアント１１０Ａが管理されたネットワーク１２０へのアクセスを求める対話（相互作用、インタラクション）の一部として送信された健康声明２３０に含まれていることがある。
【００３４】
アップデート・エージェント２１４は、インストールする前にパッチを認証するように構成されることがある。図解されている例では、更新エージェント２１４は、符号付き
バイナリ・ファイル２２０としてパッチをダウンロードする。署名は、認証機関によって出された「秘密鍵」を用いてデジタル・ファイルがエンコードされる従来のプロセスである。認証機関は利用可能な「公開鍵」を作る。公開鍵は、更に符号付きファイルを生成するために十分な情報を提供しない。しかし、符号付きファイルが特定の秘密鍵で生成されそれが生成されて以来変更されていないと判断するために、公開鍵の持ち主は、符号付きファイルに公開鍵を適用することができる。
【００３５】
クライアント１１０Ａは、１又は複数の認証機関に関連付けられた複数の公開鍵２２４を有することがある。そのような鍵は、機関の認定からそれらをダウンロードするような任意の適切なソースから得ることができる。あるいは、多数の認証機関からの公開鍵には、オペレーティング・システム・ソフトウェアがしばしば提供されている。
【００３６】
更新エージェント２１４が非業付き２進数ファイル２２０をダウンロードするとともに、それはファイルに公開鍵を適用する。
更新エージェント２１４が符号付きバイナリ・ファイル２２０に成功裡に公開鍵２２４を適用すれば、ファイルの確実性が確認される。符号付きバイナリ・ファイル２２０の検証に際して、更新エージェント２１４が、符号付きバイナリ・ファイル２２０の内に含まれていたパッチをインストールすることがある。いくつかの実施例では、公開鍵２２４はクライアント１１０Ａのユーザによって信頼されたソースから得られる。対応する秘密鍵で署名された更新に信頼された公開鍵を適用することによって、更新エージェント２１４は、信頼されたソースから得たことと、それ以降は修正されていないので、それがその更新を「信頼するべきである」と判断できる。
【００３７】
いったん更新エージェント２１４がパッチをインストールすれば、それは将来の使用のために符号付きバイナリ・ファイルを格納することがある。
【００３８】
サーバ１１２は、アクセス用のリクエストに応えるのに適した同様のモジュール方式を含む。サーバ１１２は、クライアント１１０Ａから健康声明２３０を受け取る検疫エージェント２１０Ｂを含む。サーバ１１２は、健康確認手段（ＳＨＶ）（健康声明２３０内に含まれていた情報の一部を各々処理して）の１又は複数の声明を含むことがある。いくつかの実施例では、サーバ１１２は、クライアント１１０Ａの中の各ＳＨＡに相当するＳＨＶを含む。図２の例では、ＳＨＶ２２６Ａ、２２６Ｂ及び２２６Ｃが示されている。この例において、サーバ１１２中の１つのＳＨＶは、クライアント１１０Ａの中のＳＨＡに相当する。しかし、クライアント１１０Ａ及びサーバ１１２Ｂの中のソフトウェアは任意の適切な方法でモジュール化されることがある。また、ＳＨＶがそれぞれＳＨＡに相当するという要求はない。
【００３９】
この例において、サーバ１１２内のＳＨＶは、クライアント１１０Ａの中のオペレーティング・システム・ソフトウェアのパッチ状態を定義する健康声明２３０から、情報を得る。このＳＨＶはパッチ状態に基づいて、クライアント１１０Ａが検疫実施方針に応じるかどうかを判断する。ＳＨＶによってなされた判断は、エージェント２１０Ｂを検疫するために提供される。検疫エージェント２１０Ｂは、ＳＨＶの万物からの出力を集めて、クライアント１１０Ａが検疫実施方針に従ってアクセスのための資格を得るかどうか示す応答を生成する。その決定は、従来のアクセス・コントロール・テクニックによる管理されたネットワーク１２０へのアクセスを管理するアクセスサーバ１１２内の他のソフトウェアに検疫エージェント２１０Ｂによって提供されることがある。
【００４０】
更に、検疫エージェント２１０Ｂは、クライアント１１０Ａの中のエージェント２１０Ａを検疫するために送られる健康応答声明２３２を生成する。クライアント１１０Ａがアクセスを得る権利を与えられないことを検疫エージェント２１０Ｂが決める場合、健康応答声明２３２はクライアント１１０Ａが検疫実施方針に応じない理由を示すことがある。
【００４１】
クライアント１１０Ａが検疫されることを示す健康応答声明２３２を受け取る際、検疫エージェント２１０Ａは改善を始める。クライアント１１０Ａがそのオペレーティング・システム・ソフトウェアのパッチ状態のために検疫される場合、２１０Ａが引き起こすことがあるエージェントを検疫し、更新エージェント２１４は、検疫実施方針にクライアント１１０Ａを対応させる更新サーバ１５０からパッチを得る。
【００４２】
クライアントが当初は管理されたネットワーク１２０へのアクセスを求めた時には、クライアントが旧式だった場合にのみ、図２に描写されたソフトウエアコンポーネントは、最も現在のソフトウェアを欠いているクライアント（「旧式のクライアント」と呼ばれる）を検出するのに役立つ。図２で示されたアプローチは、ネットワーク１２０に接続した後で更新が利用可能になったので旧式のクライアントを検出するのには役立たない。更に、図解されているアプローチでは、サーバからそれぞれのクライアントにダウンロード情報へのネットワークへのアクセスを求める。サーバから更新を得ることをすべてのクライアントに要求することは、かえってネットワークトラフィックを増加させる可能性がある。もしクライアントがそれぞれゲートウエイ又は他のネットワーク・ボトルネックを通って更新サーバ１５０にアクセスすれば、ダウンロードによるネットワーク・トラフィックが増加し、これは特に不適当である。図２によって図解されている旧式のクライアントの検波及び改善のためのアプローチは、Ｐ２Ｐ更新の許可により改善される。
【００４３】
図３は、更新マネジメントシステムの別の実施例を示す。管理されたネットワーク１２０へのアクセスを求めることに加えてソフトウェアを更新することをクライアントに強いる代わりに、又は強いることに加えて、旧式のクライアントの検波及び改善が確立する貴族の一部として、管理されたネットワーク１２０へのアクセスを既に与えられていた仲間（ピア）クライアント間でのコミュニケーションが生じることがある。例えば、クライアント１１０Ｂ及び１１０Ｃは、管理されたネットワーク１２０へのアクセスを与えられた図１に示されている。クライアント１１０Ｂ及び１１０Ｃが管理されたネットワーク１２０へのアクセスを与えられるときには、それぞれが、検疫実施方針に有効に応じる。しかし、アクセスが一方の検疫実施方針が変更したネットワーク１２０を管理することをクライアント１１０Ｂ又は１１０Ｃが認められたか、追加の更新が利用可能になった時の後に続く場合には、クライアント１１０Ｂ又は１１０Ｃのうちの１つは旧式のソフトウェアを含むことがある。クライアント１１０Ｂと１１０Ｃの間の接続を確立する部分として、クライアントがそれぞれ別のクライアントがより最新かどうか判断することを可能にして、健康情報を交換することがある。あるクライアントが他方よりも新しいとわかる場合、より新しいクライアントは、より旧式のクライアントにそれが受け取った更新を提供することがある。ネットワーク中の１つのクライアントがそれを得ると共に、更新サーバ又は他のソースからの更新、ネットワーク中のクライアントがピアツーピア通信を実行するにつれて、更新は、クライアントからクライアントへ繁殖するだろう。このように、クライアントは、当初は管理されたネットワーク１２０へのアクセスを求める場合以外に、時々である更新を受け取ることがある。
【００４４】
更に、管理されたネットワーク１２０内のＰ２Ｐから通過することによって、より少ないロードは更新サーバ１５０に置かれる。更新を展開させることは管理されたネットワーク１２０と更新サーバ１５０の間の通信にボトルネックを作成しない。
【００４５】
Ｐ２Ｐ更新は、クライアント１１０Ｂと１１０Ｃとの間の通信に用いられた特定のプロトコルにかかわらず使用されてもよい。説明している実施例では、クライアント１１０Ｂ及び１１０Ｃは、ハンドシェーキング・メッセージによって最初に接続を確立することにより通信する。異なるプロトコルは、異なる方法で接続を確立する。例えば、ＴＣＰプロトコルを用いる通信は、「セッション」と呼ばれる接続を確立する。あるいは、ＵＤＰプロトコルを用いて通信しているクライアントは、通信の中でその後用いられるポートを割り当てる。他のプロトコル及びソフトウェア・システムは、異なる方法で接続を確立し、異なる用語とのそれらの接続について記述する。接続は、例えば、「パイプ」又は「ソケット」と記述されることがある。接続が確立されるネットワーク階層中の接続又はレイヤの特定の名称又はフォーマットとは関係なく、健康声明の交換は接続を確立する過程に組み入れられることがある。
【００４６】
次に図３を参照する。図３には、Ｐ２Ｐ更新を容易にするのに用いられるソフトウェア・アーキテクチャの例が示されている。図解されている実施例では、それぞれのクライアントが同じソフトウェアを含む。任意の与えられた時点において、クライアントは、更新を提供する又は受け取ることができる。従って、両方のクライアントにおけるソフトウェアは、Ｐ２Ｐ更新の一部として、更新を提供するか又は受け取るように構成されている。
【００４７】
図３に図解されているように、クライアント１１０Ｂは、健康声明（statement of health、ＳｏＨ）３３０Ｂを生成する検疫エージェント３１０Ｂを含む。健康声明３３０Ｂは、接続を確立するプロセスの一部としてクライアント１１０Ｃに送信される。同様に、クライアント１１０Ｃは、クライアント１１０Ｂの中の検疫エージェント３１０Ｂに送信される健康声明３３０Ｃを生成する検疫エージェント３１０Ｃを含む。
【００４８】
図２に関して一般論として上述したように、検疫エージェント３１０Ｂ及び３１０Ｃは、それぞれが、健康声明を生成する。図解されている例では、クライアント１１０Ｂは、クライアント１１０Ｂにインストールされたパッチに関するパッチ・レジストリ２２０Ｂからデータを得るＳＨＡ３１６Ｂを含む。この情報は、健康声明３３０Ｂの生成の際に用いられる検疫エージェント３１０Ｂに、セキュリティ・センタ３１２Ｂを介して提供される。同様に、クライアント１１０Ｃは、クライアント１１０Ｃにおけるパッチ・レジストリ２２２Ｃからデータを取得するＳＨＡ３１６Ｃを含む。この情報は、健康声明３３０Ｃを生成する際に用いるために、セキュリティ・センタ３１２Ｃを介して検疫エージェント３１０Ｃに送られる。
【００４９】
この実施例では、健康声明３３０Ｂと健康声明３３０Ｃとは、同一のフォーマットを含む。これは、健康声明２３０Ｂ（図２）と同じフォーマットでありうる。しかし、Ｐ２Ｐ通信を開始することとの関係でなされた更新状態の判断は、図２に関して上述した検疫実施方針を適用する一部として検査される場合と比較して、クライアント１１０Ｂ及び１１０Ｃのそれぞれの動作に関してより少数の要素の状態をチェックすることを含む。それぞれのクライアントのオペレーティングシステムのパッチ状態だけがＰ２Ｐ更新の一部と見なされる実施例では、健康声明３３０Ｂ及び３００Ｃは、パッチ状態に関するデータだけを含むことがある。
【００５０】
健康声明を生成する際に、検疫エージェント３１０Ｂ及び３１０Ｃは、それぞれが、クライアント１１０Ａ（図２）における検疫エージェント２１０Ａの場合に匹敵する機能を実行する。従って、クライアント３１０Ｂ及び３１０Ｃは、それぞれが、当該クライアントに関する状態情報を得るために、少なくとも１つのＳＨＡを含む。これは、ＳＨＡ３１６Ｂ及び３１６Ｃとして図解されている。
【００５１】
更に、検疫エージェント３１０Ｂ及び３１０Ｃは、それぞれが、受け取る健康声明を処理して応答を生成する。従って、検疫エージェント３１０Ｂ及び３１０Ｃは、それぞれが、サーバ１１２内に含まれている検疫エージェント２１０Ｂと似た機能を実行する。図２の実施例でのように、検疫エージェントによって生成された応答のための情報は、ＳＨＶから得られる。従って、クライアント１１０Ｂ及び１１０Ｃは、ＳＨＶ３２６Ｂ及びＳＨＶ３２６Ｃをそれぞれ含む。健康声明３３０Ｂを受け取ると、検疫エージェント３１０Ｃは、ＳＨＶに健康声明３３０Ｂからの状態情報をＳＨＶ３２６Ｃに提供する。図２についてＳＨＶとの関係で上述したように、ＳＨＶ３２６Ｃは、健康声明における状態情報と、健康声明３３０Ｂを送るクライアントが更新を必要とするかどうかをＳＨＶ３２６Ｃが判断することを３２６Ｃ可能にする基準と比較する。
【００５２】
ＳＨＶ３２６Ｃは、図２におけるＳＨＶによって適用されるものに匹敵するアルゴリズムを適用して、クライアント１１０Ｂが検疫実施方針に従うかどうかを判断する。あるいは、ＳＨＶ３２６は、クライアント１１０Ｂ又はクライアント１１０Ｃのどちらか一方が他方によって更新されるべきかどうか判断するＰ２Ｐ更新方針に従ってアルゴリズムを適用することがある。いくつかの実施例では、Ｐ２Ｐ更新方針は、相対的に古い方のクライアントが相対的に新しい方のクライアントから更新を受け取るように、命令する。
【００５３】
例えば、健康声明３３０Ｂがクライアント１１０Ｂの中のソフトウェアの直近（時間的に最も近い）の更新時刻を識別するフィールドを含む場合に、そのような方針が適用されることがある。そのような情報を得ると、ＳＨＶ３２６Ｃは、クライアント１１０Ｂの直近の更新時刻と、パッチ・レジストリ２２２Ｃに記憶されている直近の更新時刻とを比較する。しかし、他の適切な処理をＳＨＶ３２６Ｃが実行して、検疫エージェント３１０Ｃによって用いられた状態情報を生成し、Ｐ２Ｐ更新方針を実装することがある。
【００５４】
ＳＨＶ３２６Ｃによって検疫エージェント３１０Ｃに返された状態に基づいて、検疫エージェント３１０Ｃは、応答３３２Ｃを生成する。健康応答声明３３２Ｃは、クライアント１１０Ｂの更新状態に関する情報を検疫エージェント３１０Ｂに通信する。ここで説明している実施例では、健康応答声明３３２Ｃは、クライアント１１０Ｂに、クライアント１１０Ｂにおけるソフトウェアがクライアント１１０Ｃにおけるソフトウェア１１０Ｃよりも古いかどうかを示す。
【００５５】
クライアント１１０Ｂの中の検疫エージェント３１０Ｂは、検疫エージェント３１０Ｃと似た機能を実行する。特に、検疫エージェント３１０Ｂは、クライアント１１０Ｃの更新状態を記述している健康声明３３０Ｃを受け取る。健康声明３３０Ｃに含まれている情報とパッチ・レジストリ２２２Ｂの中の情報とに基づいて、ＳＨＶ３３６Ｂはクライアント１１０Ｃの最新状況に関する情報を、検疫エージェント３１０Ｂに返送する。検疫エージェント３１０Ｂは、この情報を用いて健康応答声明３３２Ｂを生成し、この声明は検疫エージェント３１０Ｃに送信される。健康応答声明３３２Ｂは、クライアント１１０Ｃに、そのソフトウェアがクライアント１１０Ｄの中のソフトウェアよりも古いかどうかを示す。
【００５６】
状態情報の交換の結果、クライアント１１０Ｂ及び１１０Ｃが一方のクライアントは他方のクライアントよりも古いソフトウェアを含むと判断する場合には、より新しいソフトウェアを含む方のクライアントが、より古い方のクライアントが必要としている更新を含む記憶されているバイナリ・ファイルを送信する。例えば、クライアント１１０Ｂがクライアント１１０Ｃよりも新しい場合には、ＳＨＶ３２６Ｂは、パッチ・レジストリ２２２Ｂを読み、クライアント１１０Ｃが最後に更新された後でクライアント１１０Ｂにインストールされたパッチを識別する。次に、ＳＨＶ３２６Ｂは、これらのパッチと対応する符号付きのバイナリ・ファイル（singed binary files）のリストを備えた検疫エージェントを提供する。検疫エージェント３１０Ｂは、エージェント３１０Ｂを更新するためのパッチのリストを提供する。
【００５７】
更新エージェント３１４Ｂは、更新サーバ１５０とソース・バイナリ・ファイルとにおける更新エージェントと似た態様で、動作する。この構成では、更新エージェント３１４Ｂは、更新エージェント３１４Ｃに対するバイナリ・ファイルを供給する。更新エージェント３１４Ｃは、バイナリー・ファイルを受け取り、あたかもそれらがサーバ１５０からダウンロードされたかのように、同じ方法でクライアント１１０Ｃにおけるソフトウェアへの更新をインストールする。
【００５８】
更新ファイルがＰ２Ｐから送信される場合であっても、更新プロセスの保全性を保存するような認証が可能である。クライアント１１０Ｂ及び１１０Ｃは、それぞれが、２２４Ｂ及び２２４Ｃのように公開鍵を含むので、どちらのクライアントも符号付きバイナリ・ファイルを認証することができる。更新エージェント３１４Ｃは、バイナリー・ファイルの出所の両方を確認することができるし、生成されて以来バイナリー・ファイルが変更されていないことを確認することができる。クライアントが信頼できる公開鍵を用いて形成されている場合には、更新エージェント３１４Ｃは、当該更新を信頼すべきかどうかを判断できる。
【００５９】
更新エージェント３１４Ｃは、それらのファイルが信頼できる場合にだけ、別のクライアントから受け取られたバイナリ・ファイルからの更新をインストールするように構成されている。
【００６０】
クライアント１１０Ｃがクライアント１１０Ｂよりも新しいソフトウェアを含む場合には、更新を含むバイナリー・ファイルを提供するプロセスは、逆に実行することが可能である。このシナリオでは、更新エージェント３１４Ｃは、エージェント３１４Ｂを更新するソースとして機能する。更新エージェント３１４Ｂは、ファイルを受け取り、それを認証し、当該ファイルに含まれている更新を適用する。
【００６１】
図３に示されているシステムは、任意の適切なＰ２Ｐ更新方針によって動作する。例えば、あるクライアントが旧式のソフトウェアを含むと判断されるときには、この方針は、限定型の検疫を要求する。具体的には、クライアントは、旧式のソフトウェアを含む別のクライアントとの接続を確立することを拒絶する。しかし、他の方針も可能であり、クライアント一方が他方ほど最新でないソフトウェアを含むと判断される場合であってもきゅうし気のクライアントの更新を強制する検疫が生じるという結果には必ずしもならない。旧式のクライアントによる更新は任意であって、第１のクライアントと第２のクライアントとの間の接続は、より古い方のクライアントがそのソフトウェアを更新するかどうかとは関係なく、進行する。代替的な方針の更なる例として、より古いクライアントにおいて欠けている更新の性質によって、検疫を介して更新が強制されるのか任意であるのかが決定される。例えば、いくつかの更新は、そのような更新を提供するソフトウェア・ベンダによって「クリティカル（重大）」なものと分類される。最新のクライアントは、重大な更新を欠いている旧式のクライアントとの接続の確立を拒絶するが、そうでなければ接続を確立する。
【００６２】
どんなＰ２Ｐ更新方針が用いられるかにかかわらず、より新しいクライアントがより古いクライアントにバイナリ・ファイルを供給する必要はない。しかし、通信を確立しつつあるクライアントよりもそのクライアント自体の方がより古いことを当該クライアントに示す健康応答声明が、古いクライアントがその更新エージェントを付勢して更新サーバから更新をダウンロードするトリガとなることもある。別の実施例では、入手可能であるならば、より最新のクライアントが、更新のためのバイナリ・ファイルを提供することがある。しかし、入手不可能である場合には、旧式のクライアントに向かって、当該旧式のクライアントは更新サーバからの更新を行うべきであるという健康応答声明を送ることもある。更に別の場合には、入手可能な場合には、より旧式のクライアントが、より最新のクライアントから、バイナリ・ファイルを受け取りインストールする。しかし、より旧式のクライアントがバイナリ・ファイルを受け取らないか認証できない場合には、より新しい方のクライアントが、自ら、更新サーバからの更新のダウンロードを始める。
【００６３】
次に図４を参照すると、図３で示されたように、クライアントが動作する例示的なプロセスが示される。プロセスは、ブロック４１０で始まる。このブロックでは、クライアント１及びクライアント２がＰ２ＰのＩＰｓｅｃ接続を始める。図４に描かれたプロセスは任意のフォーマットでの通信と共に用いられてもよいが、ＩＰｓｅｃ接続を備えた使用が有利である。ＩＰｓｅｃプロトコルは、接続を確立する前にピア（仲間）の認証を要求する。Ｐ２Ｐ通信を開始するクライアントは管理のなされたネットワーク１２０の重要な一部であるという確認により、更新管理プロセスの保全性が向上する。更に、ＩＰｓｅｃプロトコルは、状態情報の交換が容易に提供される認証フェーズを特定する。
【００６４】
用いられる特定の通信プロトコルとは関係なく、プロセスはブロック４１２に移動する。ブロック４１２では、健康情報声明が、クライアントの少なくとも一方から他方に送信される。図３に示されるように、クライアントは、それぞれが、健康情報声明のソース又は受信者のいずれかでありえる。これらのクライアントが健康情報声明を交換する場合には、どちらのクライアントも、どちらのクライアントがより新しいのかを決めることができる。あるいは、健康情報声明がたった一方のクライアントだけから他方のクライアントに送られる場合には、健康情報声明の受信者が、クライアントのどちらがより最新であるのかを識別することがある。どちらのクライアントがより新しいのかという判断が一方のクライアントによってなされる場合には、その判断は健康応答声明において、他方のクライアントに伝えられる。
【００６５】
クライアントのどちらが健康情報声明を処理するかとは関係なく、２つのクライアントのパッチ状態が、決定ブロック４１４で比較される。それぞれのクライアントが同じパッチ状態を有する場合には、処理はブロック４３０に進む。ブロック４３０では、クライアントは、いずれのクライアントを更新するそれ以上の努力をすることなく、通信することができる。
【００６６】
あるいは、決定ブロック４１６における処理により、クライアントのうちの一方が他方よりも最新であることが判断される場合には、処理は、決定ブロック４１６に移る。決定ブロック４１６では、プロセスは、クライアントのどちらがより旧式であるかに応じて分岐する。クライアント１の方が旧式でない場合、処理はブロック４１８に進む。ブロック４１８では、クライアント２がクライアント１と同じ更新状態に到達するように、クライアント１はクライアント２にパッチ情報を送る。
【００６７】
クライアント１からパッチを受け取ると、クライアント２は、パッチを確認しようとする。検証は、当該のパッチの元のソースと、当該パッチが生成されて以来修正されているかどうかとを決定することを含む。検証は、認証機関によって配分された公開鍵の使用など、任意の適切なプロセスも含む。クライアント２がパッチを確認することができる場合には、処理はブロック４２４に進む。ブロック４２４では、パッチがクライアント２にインストールされる。次に、クライアント２は、クライアント１と同じ更新状態を獲得し、プロセスはブロック４３０に進み、そこで、クライアント１とクライアント２との間の通信が生じる。
【００６８】
あるいは、クライアント２で受け取られたパッチの確認ができない場合には、処理は、ブロック４２２に進む。図４で示されているプロセスでは、クライアント２は、何らかの理由でクライアント１によって提供されるパッチを確認することができない場合には、ダウンロード・サーバからパッチをダウンロードする。ブロック４２２での処理の一部として、クライアント２は、ダウンロードされたパッチをインストールする。次に、処理はブロック４３０に進み、そこで、クライアント１及びクライアント２が通信する。
【００６９】
あるいは、クライアント１がクライアント２と比較して古いと決定ブロック４１６の処理が判断する場合には、処理はブロック４４０に進む。ブロック４４０では、クライアント２がクライアント１にパッチを送り、クライアント１はクライアント２と同じ更新状態を得る。決定ブロック４４２では、クライアント１は、クライアント２によって提供されるパッチを確認することを試みる。決定ブロック４２０に関して上述したように、クライアント１は、パッチの確認に関して任意の適切な方法でも用いることがある。クライアント１がパッチを確認することができる場合、プロセスはブロック４４６に進み、パッチがクライアント１にインストールされる。あるいは、クライアント１がパッチを確認することができない場合、プロセスは決定ブロック４４２からブロック４４４に進む。ブロック４４４では、クライアント１は、更新サーバからパッチをダウンロードしインストールする。
【００７０】
クライアント１がクライアント２又はダウンロード・サーバからパッチを受け取るかどうかにかかわらず、プロセスはブロック４３０に進み、クライアント１とクライアント２とが通信する。
【００７１】
本発明の１つの実施例に関する複数の側面について述べてきたが、当業者であれば、様々な変更、修正及び改善を容易に想到できるはずである。
【００７２】
例えば、Ｐ２Ｐ更新方針が定義されるのであるが、この方針においては、更新が１つのコンピュータから別のコンピュータに提供される。オペレーティング・システム・ソフトウェアへのパッチを、提供されることがある１つのタイプの更新の例として説明した。どんな更新情報も、Ｐ２Ｐ更新処理の一部として提供される。ウィルス署名を含むもののような、他のソフトウェア、まったく新しいソフトウェア又はデータファイルへのパッチは、あるクライアントから別のクライアントまで提供される。
【００７３】
更に、代替的なＰ２Ｐ更新方針の例が提供された。ソフトウェアは、これらの方針のうちのいずれか１つに従って動作するように構成することができる。あるいは、ソフトウェアは、ネットワーク・アドミニストレータによって環境設定が可能であるように構成可能であり、それにより、ネットワーク・アドミニストレータは、これらの方針の中の任意の１つ又は組合せを選択することができる。
【００７４】
更に、接続を確立するクライアントが、状態情報の交換に基づいて一方のクライアントが他方のクライアントを比較して古いと判断することについても説明される。任意の他の方法を用いて、一方のクライアントが別のクライアントによって提供することができる更新を欠いていると判断することができる。例えば、クライアントのどちらか又は両方が、利用可能な更新について、更新サーバのような外部情報源の意見を求めることもできる。
【００７５】
更に、２つのクライアントが接続を始める場合に、Ｐ２Ｐ更新方針が適用されることが説明される。２つ以上のクライアントが対話する場合、どの時点でも更新方針を適用することができる。更に、クライアントにＰ２Ｐ方針を適用させる対話を強制することも可能である。そのような接続は、それぞれのクライアントに周期的にネットワーク中の他のクライアントと連絡をとらせることにより強要することができる。ネットワークの中のクライアントにおいて背景的なプロセスとして実行されるのであれば、そのようなアプローチが望ましいこともある。
【００７６】
このような変更、修正及び改善は、この出願における開示の一部であることが意図されており、本発明の精神及び範囲に含まれることが意図される。従って、以上の説明及び図面は、単なる例示である。
【００７７】
本発明の上記実施例は、多数の方法のうちのどれを用いても実現可能である。例えば、これらの実施例は、ハードウェア、ソフトウェア又はそれらの組合せを用いて実現できる。ソフトウェアにおいて実現されるときには、単一のコンピュータにおいて提供されるのか、複数のコンピュータの間で分配されるのかにかかわらず、ソフトウェア・コードを任意の適切な単独のプロセッサにおいて、又は、プロセッサ集合において実行することができる。
【００７８】
更に、ここで説明された様々な方法又はプロセスは、様々なオペレーティングシステム又はプラットホームのうちのいずれか１つを用いる１つ以上のプロセッサ上で実行可能なソフトウェアとしてコード化されることがある。更に、そのようなソフトウェアは、多数の適切なプログラミング言語及び／又は伝統的プログラミング又はスクリプト用のツールをどれを用いても書かれることができ、フレーム・ワーク又は仮想的なマシンにおいて実行される実行可能な機械語コード又は中間コードとしてコンパイルされる。
【００７９】
この点で、本発明は、１つのコンピュータ可読媒体（又は、複数のコンピュータ可読媒体）としても実現可能である（例えば、コンピュータ・メモリ、１又は複数のフロッピ・ディスク（登録商標）、コンパクト・ディスク、光ディスク、磁気テープなど）。これらの媒体の上には、１又は複数のコンピュータ又はそれ以外のプロセッサにおいて実行されると、上述した本発明の様々な実施例を実現する方法を実行する１又は複数のプログラムが記憶されている。これらの１又は複数のコンピュータ可読媒体は、転送可能であり、記憶されている１又は複数のプログラムは、１又は複数の異なるコンピュータ又はそれ以外のプロセッサにロードされて、上述した本発明の様々な側面が実現される。
【００８０】
ここで用いている「プログラム」又は「ソフトウェア」という用語は、コンピュータ又は他のプロセッサを上述した本発明の様々な側面を実現するようにプログラムするのに用いられる任意のタイプのコンピュータ・コード又はコンピュータ実行可能な命令セットを一般的に意味する。更に、この実施例の１つの特徴によると、実行されると本発明の方法を実現する１又は複数のコンピュータ・プログラムは単一のコンピュータ又はプロセッサに存在することは必要ではなく、多数の異なるコンピュータ又はプロセッサの間にモジュールとして存在して本発明の様々な側面を実現することが可能である。
【００８１】
コンピュータ実行可能命令は、プログラムモジュールのように、１又は複数のコンピュータ又は他のデバイスによって実行される多くの形式で存在しうる。一般に、プログラムモジュールは、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含み、それは特別のタスクを実行する、又は、特定の抽象的なデータ・タイプを実現する。典型的には、様々な実施例において望まれるように、プログラム・モジュールの機能性を組み合わせることができるし、分配されることもある。
【００８２】
本発明の様々な側面は、単独で、組み合せて、又は、上述した実施例では特に議論されていない様々な構成として使用されてもあり、従って、以上の説明及び図面において述べられたコンポーネントの詳細及び構成には限定されない。例えば、１つの実施例において説明される側面は、任意の方法で、他の実施例に述べられていた側面と組み合わせることができる。
【００８３】
特許請求の範囲において用いられている「第１」、「第２」、「第３」などのような用語は、優先順位や先後や時間的順序などを意味しない。単に、ある１つの請求項における構成要素を別の構成要素と区別するためだけに用いられている。
【００８４】
更に、ここで用いられる語法及び用語は、説明のためであり、制限を意味しない。「含む」、「包含する」、「有する」、「含む」などの用語は、列挙されている事項とそれ以外の均等物との両方を含むことが意図されている。
【図面の簡単な説明】
【００８５】
添付の図面は、寸法通りであることを意図してはいない。これらの図面では、複数の図面に図解されている同一の又はほぼ同一の構成要素は、それぞれが、同じ参照番号によって表されている。見やすくするために、すべての図面におけるすべての構成要素にラベルが付されているとは限らない。
【図１】本発明のある実施例によるネットワークのスケッチである。
【図２】図１のネットワークにおける検疫執行方針を実現するソフトウェアのソフトウェア・ブロック図である。
【図３】本発明のある実施例に従って、２つのクライアント・コンピュータにおいて用いられＰ２Ｐ治療を実行することができるソフトウェアのソフトウェア・ブロック図である。
【図４】図３に図解されているクライアント・コンピュータが通信を確立するプロセスを図解する流れ図である。
【図１】
2009520252.tif 000003
【図２】
2009520252.tif 000004
【図３】
2009520252.tif 000005
【図４】
2009520252.tif 000006
【国際調査報告】
2009520252.tif 000007
2009520252.tif 000008