JP4916432B2 - アップデートの配布システムにおいてソフトウェアアップデートの配布を管理するためのアプリケーションプログラミングインターフェース - Google Patents

Description

本発明は、ソフトウェアおよびコンピュータネットワークに関し、詳しくは、本発明は、アップデート配布システムにおいてソフトウェアアップデートの配布を管理するアプリケーションプログラミングインターフェースに関する。

ほぼすべての市販のソフトウェア製品は、ソフトウェアの機能を補修したりアップデートしたりする改訂プロセスを頻繁に受ける。ソフトウェア製品の各改訂は、新しいファイルの追加をすること、既存のファイルの新しい改訂版の置き換えをすること、もう使用されていないファイルの削除をすること、またはこれらを処理することの様々な組み合わせをしばしば必要とする。ソフトウェア製品の古いファイルの置き換え、新しいファイルの追加、もう使用されていないファイルの削除をするこのプロセスは、以下、「製品アップデート」と呼び、製品アップデートに使用される、バイナリファイル、データファイル、アップデート命令、メタデータ、データベースデータ、システムレジストリ設定、セキュリティ設定などを含むデータの集まりは、以下、より簡単に「アップデート」と呼ぶ。

ソフトウェアプロバイダは、問題を修正するか、セキュリティを高めるか、または新しい機能を追加するソフトウェア製品のアップデートを作成すると、ソフトウェアプロバイダは、アップデートがその顧客ベースに広く利用可能となることを望むだろう。とてもよくあることだが、アップデートが製品の不具合の修正、または重大なセキュリティ問題の対応に取り組んでいるときなど、ソフトウェアプロバイダは、そのアップデートが、できるだけ早く顧客のコンピュータ上にインストールされることを望むだろう。実際に、ほとんどのソフトウェアプロバイダには、ソフトウェアアップデートを、彼らの顧客にできるだけ迅速に、できるだけ問題なく配布する業務上の動機がある。

コンピュータ業界は、ネットワーク、特にインターネットに接続されたコンピュータ数の爆発的な成長を経験している。この爆発的な増加、およびインターネットへの接続を通して利用可能な通信能力のために、インターネットは、ソフトウェアプロバイダにとって、彼らの顧客にアップデートを配布するための重要かつ不可欠な経路になってきた。実際に、インターネットは、多くのソフトウェアプロバイダにとって、彼らの顧客にソフトウェアアップデートを提供するために主要な配布経路になってきた。インターネット上でソフトウェアアップデートを配布することが、ソフトウェアプロバイダに最も利益があることはしばしばである。なぜなら、インターネットを介したアップデートの電子配布は、全体コストを低減し、ソフトウェアアップデートが利用可能になるとすぐに顧客はそれらを取得することができるからである。ますます頻繁に、これらのソフトウェアアップデートは、ユーザの介入無しに、インターネット上で自動的に行われる。

インターネットは、現在、ソフトウェアプロバイダからソフトウェアアップデートを配布するルートとして一般に使用されているが、さまざまな問題がしばしば生じる。そのような２つの問題は、（１）アップデート配布のインフラストラクチャ／リソースに関する効率、および（２）ソフトウェアアップデートの配布およびインストール上の管理統制を含む。

配布リソースの効率に関しては、インターネットを含むネットワークは、しばしば帯域幅と呼ばれる限られた量の通信リソースしか所有していない。特に、オペレーティングシステムのマイクロソフト社のＷｉｎｄｏｗｓ（登録商標）ファミリや関連の生産性向上製品のような、多く出回っているソフトウェア製品のソフトウェアアップデートに関して、限られた量の通信帯域幅は、頻繁に障害（ボトルネック）をもたらす。ソフトウェアアップデートが、インターネット上に分散された複数のダウンロード場所で利用可能とされた場合でさえ、そのような障害は存在する。そのような障害が起こる１つの理由は、インターネットによって利用可能とされる体系化されていない接続モデルである。例えば、もしコンピュータＡでの第１のユーザが、あるソフトウェア製品の最新のダウンロードを要求すると、ダウンロードは、第１のユーザのＩＳＰ（独立サービスプロバイダ）を通り抜ける。さらに、その要求は、単一の個別アクセスとして扱われる。つまり、その要求は、他の任意のネットワークトラフィックおよび／または要求から独立していて、関係ないものとして扱われることを意味する。したがって、偶然に同じＩＳＰを有するコンピュータＢでの第２のユーザが第１のユーザと同じダウンロードを要求した場合、第２のユーザからの要求も単一の個別アクセスとして扱われる。この例において、各要求は独立して扱われるので、同じダウンロードが、同じインフラストラクチャ上に二度送信されるだろう。明らかに、ユーザ数が大幅に増えると、限られた通信帯域幅はボトルネックとなる。とても一般的なこの例では、ダウンロードをある局所的な場所でキャッシュし、各ユーザの要求を局所的なキャッシュから満たすことができれば、はるかに効率的だったであろう。

配布の制御に関して、多くの組織、特に大きな組織は、それらのコンピュータへのアップデートの配布を制御する合理的な理由がある。例えば、残念ながらいくつかのアップデートは、ソフトウェア製品の機能を「破壊する」、しばしばバグと呼ばれる欠陥を有すか、または不具合をもたらしたりする。これらの破壊された機能は、重要でないかもしれないが、たいていは、企業の極めて重要な機能を中断させる可能性がある。企業は、その極めて重要な機能を失うことはできないので、責任のある企業は、そのコンピュータの残りにアップデートをリリースするのに前もって、ある時間期間で、制御された環境内で各ソフトウェアアップデートを評価し、テストする。この評価期間は、組織がアップデートが極めて重要な機能に悪影響を与えるかどうかを検証することができるようにする。アップデートが極めて重要な機能を破壊しないであろうことが十分に確定された後にのみ、アップデートが組織のコンピュータの残りに配布されることを許可される。明らかに、ほとんどの組織は、それらのコンピュータへのソフトウェアアップデートのインストールの制御を行わなければならない。

企業または組織がしばしばソフトウェアアップデートの配布を制御する必要がある別の理由は、組織内のコンピュータ間の整合性を確保するためである。情報サービス部にとって、ワードプロセッサ用であろうと、オペレーティングシステム用であろうと、すべてのコンピュータが動作する標準化されたターゲットプラットフォームがあることが非常に重要である。標準なしでは、ソフトウェアおよびコンピュータのメンテナンスは、不必要に複雑で難しくなり得る。

ローカル制御が重要であるさらに別の理由は、課金のターゲットのためである。大きな組織では、コンピュータ上に個人的にソフトウェアをインストールしたり、組織の各コンピュータに特定のソフトウェア製品のライセンスを個人的に保持したりするのは、しばしば非効率である。代わりに、単一のサイトライセンスは、組織が多数のコンピュータ上でソフトウェア製品を実行することができるようにする。このように、組織は、サイトライセンス下で製品を実行させるコンピュータ数を報告することを要求されるかもしれない、またはサイトライセンス下で製品を実行させるコンピュータの数を制限したりする必要があるかもしれない。これらのすべての理由は、しばしばソフトウェアアップデートの配布のローカル制御を必要とする。

米国特許仮出願第６０／５５３，０４２号明細書

ソフトウェアアップデートの配布に関する様々な上記で特定した問題に照らして、必要なものは、ソフトウェアアップデートの配布に対する制御を提供すると同時に、それらの配布の効率を向上させる拡張可能なソフトウェアアップデート配布アーキテクチャである。本発明は、これらの問題、および当分野で見つけられる他の問題に対応する。

本発明の態様によれば、アップデートサービスノード上でソフトウェアアップデートの配布を管理するためのアプリケーションプログラミングインターフェースを有するアップデートサービスノードが示される。アップデートサービスノードは、ソフトウェアアップデートを格納するためのアップデートストアを含む。アップデートサービスノードは、アップデートサービスノードが通信ネットワーク上で親アップデートサービスノードからソフトウェアアップデートを取得し、アップデートサービスノードが通信ネットワーク上でソフトウェアアップデートを子アップデートサービスノードに配布するアップデートＷｅｂサービスも含む。さらに、アップデートサービスノードは、管理者が子アップデートサービスノードおよびクライアントコンピュータへのソフトウェアアップデートの配布の制御を規定する管理ＡＰＩ（アプリケーションプログラミングインターフェース）を含んでおり、管理ＡＰＩは、管理者が前記ルールを規定する複数のインターフェース呼び出しを公開するオブジェクトである。

本発明の追加の態様によれば、アップデートサービスノード上でソフトウェアアップデートの配布を管理するためのＡＰＩ（アプリケーションプログラミングインターフェース）が示される。ＡＰＩは、ソフトウェアアップデート管理構成値を読み取り、書き込むための構成インターフェースオブジェクトをアップデートサービスノードに返す構成取得のインターフェース呼び出し（ｇｅｔ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｉｎｔｅｒｆａｃｅ ｃａｌｌ）を含む。ＡＰＩはさらに、アップデートサービスノード上で定義されたサブスクリプションインターフェースオブジェクトを返すサブスクリプション取得のインターフェース呼び出し（ｇｅｔ ｓｕｂｓｃｒｉｐｔｉｏｎ ｉｎｔｅｒｆａｃｅ ｃａｌｌ）を含む。ＡＰＩはさらに、アップデート取得のインターフェース呼び出しで渡されたアップデート識別子に対応するアップデートインターフェースオブジェクトを返すアップデート取得のインターフェース呼び出し（ｇｅｔ ｕｐｄａｔｅ ｉｎｔｅｒｆａｃｅ ｃａｌｌ）ならびに、アップデート取得のインターフェース呼び出しで渡された値に対応するアップデートインターフェースオブジェクトを含むアップデート収集オブジェクトを返すアップデート取得のインターフェース呼び出しを含む。ＡＰＩは、アップデートサービスノードに関連付けられているクライアントコンピュータに対応し、コンピュータ取得のインターフェース呼び出しで識別されたクライアントコンピュータオブジェクトを返すコンピュータ取得のインターフェース呼び出し（ｇｅｔ ｃｏｍｐｕｔｅｒ ｉｎｔｅｒｆａｃｅ ｃａｌｌ）、およびアップデートサービスノードに関連付けられているクライアントコンピュータに対応するクライアントコンピュータオブジェクトを含むコンピュータ収集オブジェクトを返すコンピュータ取得のインターフェース呼び出しも含む。さらに、ＡＰＩは、グループ取得のインターフェース呼び出しで識別されたターゲットグループオブジェクトを返すグループ取得のインターフェース呼び出し（ｇｅｔ ｇｒｏｕｐ ｉｎｔｅｒｆａｃｅ ｃａｌｌ）、およびアップデートサービスノード上のターゲットグループに対応するターゲットグループオブジェクトを含むターゲットグループ収集オブジェクトを返すグループ取得のインターフェース呼び出しを含む。

本発明のさらに別の態様によれば、ソフトウェアアップデートを配布するソフトウェアアップデート配布システムが示される。ソフトウェアアップデート配布システムは、アップデートサービスノード、およびアップデートサービスノードに関連付けられている管理ＡＰＩ（アプリケーションプログラミングインターフェース）を含む。管理ＡＰＩは、ソフトウェアアップデートの配布を制御する複数のインターフェース呼び出しを公開するインターフェースオブジェクトである。管理ＡＰＩは、ソフトウェアアップデート管理構成値を読み取り、書き込むための構成インターフェースオブジェクトをアップデートサービスノードに返す構成取得のインターフェース呼び出しを含む。ＡＰＩはさらに、アップデートサービスノード上で定義されたサブスクリプションインターフェースオブジェクトを返すサブスクリプション取得のインターフェース呼び出しを含む。ＡＰＩはまださらに、アップデート取得のインターフェース呼び出しで渡されたアップデート識別子に対応するアップデートインターフェースオブジェクトを返すアップデート取得のインターフェース呼び出しならびに、アップデート取得のインターフェース呼び出しで渡された値に対応するアップデートインターフェースオブジェクトを含むアップデート収集オブジェクトを返すアップデート取得のインターフェース呼び出しを含む。ＡＰＩは、アップデートサービスノードに関連付けられているクライアントコンピュータに対応し、コンピュータ取得のインターフェース呼び出しで識別されたクライアントコンピュータオブジェクトを返すコンピュータ取得のインターフェース呼び出し、およびアップデートサービスノードに関連付けられているクライアントコンピュータに対応するクライアントコンピュータオブジェクトを含むコンピュータ収集オブジェクトを返すコンピュータ取得のインターフェース呼び出しも含む。さらに、ＡＰＩは、グループ取得のインターフェース呼び出しで識別されたターゲットグループオブジェクトを返すグループ取得のインターフェース呼び出し、およびアップデートサービスノード上のターゲットグループに対応するターゲットグループオブジェクトを含むターゲットグループ収集オブジェクトを返すグループ取得のインターフェース呼び出しを含む。

上記の態様、および多くの付随する本発明の利点は、添付の図面と併せて、以下の詳細な説明を参照することによって、より迅速に理解されるのと同時に、よりよく理解されるだろう。

本発明の態様によれば、階層状に組織化された、ソフトウェアアップデートを配布するためのアップデート配布システムが示される。図１は、本発明の態様に従って形成されたアップデート配布システム例１００の絵図である。本発明によれば、図示されているアップデート配布システム１００のような、アップデート配布システムの「最上部」は、ルートアップデートサービスノード１０２である。ソフトウェアプロバイダ１１０のようなソフトウェアプロバイダは、アップデートをルートアップデートサービスノード１０２に送信することによって、アップデート配布システム１００を通してそれらのソフトウェアアップデートを配布する。本発明の態様によれば、ソフトウェアプロバイダ１１０のようなソフトウェアプロバイダは、インターネット１０８のようなネットワークを通して、それらのソフトウェアアップデートをルートアップデートサービスノード１０２に送信してもよい。

アップデート配布システム例１００のような階層状のアップデート配布システムは、ルートアップデートサービスノード１０２に加えて、少なくとも１つの他のアップデートサービスノードを含む可能性が高い。図１に示すように、アップデート配布システム例１００は、ルートアップデートサービスノード１０２、および２つの追加のアップデートサービスノード、すなわちアップデートサービスノード１０４およびアップデートサービスノード１０６を含む。本発明によれば、各階層アップデート配布システムは、ルートアップデートサービスノード１０２の下に、ツリーのような構造で組織化される。言い換えると、アップデート配布システム内の各アップデートサービスノードは、０つまたは１つ以上の子アップデートサービスノードを有する。このように、アップデート配布システム例１００は、各親アップデートサービスノード、すなわちルートアップデートサービスノード１０２およびアップデートサービスノード１０４が１つだけ子を有していることを示すが、これは例示のターゲットにすぎず、本発明上の制限と解釈されるべきではない。さらに、ルートアップデートサービスノード１０２を除いて、アップデート配布システム内の各アップデートサービスノードは、１つの親アップデートサービスノードを有する。したがって、図１に示したように、アップデートサービスノード１０４は、ルートアップデートサービスノード１０２の子ノードであり、アップデートサービスノード１０６は、アップデートサービスノード１０４の子ノードである。理解できるように、各アップデートサービスノードは、ルートアップデートサービスノード１０２を除いて、子アップデートサービスノードおよび親アップデートサービスノードの両方であり得る。

アップデート配布システム例１００に示されるように、ルートアップデートサービスノード１０２は、インターネット１０８を通してアップデートサービスノード１０４と通信する。しかし、これは例示にすぎず、本発明への制限と解釈されるべきではないことを理解されたい。アップデート配布システム内の各アップデートサービスノードは、何らかの通信ネットワークを通してその親および／子と通信することができるだけでよい。このように、アップデートサービスノード１０４は、インターネット１０８を通してその親のルートアップデートサービスノード１０２と通信するが、代わりに、ローカルエリアネットワーク１２４を通って、アップデートサービスノード１０６など、その子アップデートサービスノードと通信してもよい。

また、図１に示されているように、アップデートサービスノード１０６は、ローカルエリアネットワーク１２４のサブネットワーク１２６内に存在する。一例として、ローカルエリアネットワーク１２４は、組織の一般の企業ネットワークに相当し、アップデートサービスノード１０４は、その親であるルートアップデートサービスノード１０２への接続を通ってアップデート配布システム１００への企業のリンクを表す。さらに、サブネットワーク１２６は、テスト／評価グループ、遠隔地にある事務所、極めて重要なグループのような、企業ネットワーク内のコンピュータの識別可能なグループに相当し得る。以下でより詳しく説明するように、本発明の態様によれば、アップデートサービスノード１０４の管理者は、アップデートサービスノード１０６、および最終的にはクライアントコンピュータへのアップデートの配布を制御することができる。

ルートアップデートサービスノード１０２およびアップデートサービスノード１０４および１０６の両方を含む各アップデートサービスノードは、クライアントコンピュータと同様に子アップデートサービスノードにもソフトウェアアップデートを配布するように構成されていることを理解されたい。図１に示されているように、アップデート配布システム例１００は、クライアントコンピュータ１１２〜１２２を含む。ルートアップデートサービスノード１０２を含む各アップデートサービスノードは、ローカル構成情報に従って、子アップデートサービスノードおよびクライアントコンピュータへアップデートを配布する。一実施形態によれば、管理者は、グループを定義し、アップデート配布ルールをこれらのグループに関連付ける。各アップデートサービスノードには、少なくとも１つの配布グループを有する。

アップデート配布システムがどのように動作するかを示す一例として、ローカルエリアネットワーク１２４は、組織の企業ネットワークに相当すると仮定する。本発明の一実施形態によれば、アップデートサービスノード１０４上の管理者は、アップデートサービスノード１０４およびクライアントコンピュータ１１４〜１１８を含む一般の企業グループと同様に、一般の企業ネットワーク１２４のためにアップデートの適応性を評価するための、アップデートサービスノード１０６およびクライアントコンピュータ１２０および１２２を含むサブネットワーク１２６に相当する評価グループを含めて、企業ネットワーク１２４のための複数の配布グループを定義してもよい。

評価グループに関して、管理者は、アップデートサービスノード１０６をメンバーとして含み、アップデートが利用可能として評価グループのメンバーにすぐに配布されるように、ルールをそのグループに関連付ける。一方、一般の企業グループに関して、管理者は、クライアントコンピュータ１１４〜１１８を追加し、管理者によって特に許可されているならば、アップデートが一般の企業グループのメンバーのみに配布されるように、ルールを関連付ける。また、子アップデートサービスノード１０６のために管理者は、任意の新しいソフトウェアアップデートがすぐに配布される評価サブネットワーク１２６内に、クライアントコンピュータ１２０および１２２から成るデフォルトのグループを作成すると仮定する。

引き続き上記の例で、ソフトウェアプロバイダ１１０は、ソフトウェアアップデートをルートアップデートサービスノード１０２に送信する。ルートアップデートサービスノード１０２で規定されたルールに従って、アップデートは、最終的に企業アップデートサービスノード１０４に配布される。管理者によって規定されたルール通りにアップデートを受信すると、企業アップデートサービスノード１０４は、アップデートを（子アップデートサービスノード１０６のみとして定義された）評価グループのメンバーに配布するが、そのグループにアップデートを配布するための特定の許可を待つ間、一般の企業グループからのアップデートを保留する。

引き続き上記の例で、アップデートを受信すると、評価アップデートサービスノード１０６は、定義された各グループについて、アップデートを処理する。この例では、評価アップデートサービスノード１０６には、１つのグループしか有さない。しかし、前述したように、実際の実装では、それぞれが関連配布ルールの一意のセットをもつ、複数の定義されたグループがあってもよい。この例の場合、評価アップデートサービスノード１０６は、クライアントコンピュータ１２０および１２２への配布のために、アップデートをすぐに利用可能にする。クライアントコンピュータ１２０および１２２は、ここでアップデートされてもよく、評価期間／プロセスは開始してもよい。

依然として引き続き上記の例で、アップデートが企業ネットワーク１２４全体への配布に適応可能であることに企業アップデートサービスノード１０４の管理者が十分に満足するとき、管理者は次に、一般の企業グループのメンバーにアップデートが配布されることを明示的に許可する。企業アップデートサービスノード１０４は、それに応じて、クライアントコンピュータ１１４〜１１８がアップデートを利用できるようにする。評価アップデートサービスノード１０６もまた、一般の企業グループに含まれてもよいことを理解されたい。しかし、評価アップデートサービスノード１０６は、すでにアップデートされているため、評価サブネットワーク１２６にアップデートを配布するために追加のアップデート関連の動作は必要ない。

上記の例によってみられるように、本発明は、ローカル配布制御およびダウンロードの効率に関して、重要な利益を提供する。上述したローカル配布制御の態様に加えて、通信帯域幅のかなりの節約も実現される。例えば、図１に示されている企業ネットワーク例１２４は、５つのクライアントコンピュータを含むが、ソフトウェアプロバイダのアップデートがルートアップデートサービスノード１０２から企業アップデートサービスノード１０４にダウンロードされたのは一度だけである。それから明らかなように、１つのアップデートサービスノードによってサービスが提供されるクライアントコンピュータの数が増加するにつれて、親アップデートサービスノードとクライアントアップデートサービスノードとの間の通信帯域幅の使用は、一定を保ち、それによって、そうでなければ使用されることになる通信帯域幅の量が大幅に減る。さらに、アップデート配布システムは、増築可能で拡張可能である。アップデート配布システムは、次の少なくとも２つの方法で増築可能である。任意の数の子アップデートサービスノードを親アップデートサービスノードに追加してもよく、子アップデートサービスノードは、親アップデートサービスノードとなることもできる。したがって、アップデート配布システムの各サブツリーは、個々の必要性に合うように調整してもよい。

図２は、本発明の態様に従って形成される、企業アップデートサービスノード１０４（図１）または評価アップデートサービスノード１０６（図１）などのアップデートサービスノード２００の論理的な構成要素例を示すブロック図である。図２に示すように、アップデートサービスノード２００は、アップデートＷｅｂサービス２０２、クライアントアップデートモジュール２０４、子アップデートモジュール２０６、および報告モジュール２０８を含む。アップデートサービスノード例２００は、認証／許可モジュール２１０、管理ＡＰＩ（アプリケーションプログラミングインターフェース）２１２、アップデート内容格納２１４、管理ユーザインターフェース２１８、およびアップデート情報格納２１６も含む。

アップデートＷｅｂサービス２０２は、クライアントコンピュータ、子アップデートサービスノード、および親アップデートサービスノードがアップデートサービスノードと通信できる共通のＷｅｂサービスのセットを提供する。例えば、図１を参照すると、子／評価アップデートサービスノード１０６が親／企業アップデートサービスノード１０４からソフトウェアアップデートを取得するために、クライアントは、親のアップデートＷｅｂサービス２０２を通して通信する。同様に、ルートアップデートサービスノード１０２などの親アップデートサービスノードが、その子アップデートサービスノード１０４と通信するために、アップデートを含めて情報を有しているとき、親アップデートサービスノードは、子のアップデートＷｅｂサービス２０２を通して通信する。

本発明の実際の一実施形態では、一般にＷｅｂサービスインターフェースと呼ばれるアップデートＷｅｂサービス２０２によって提供される共通のＷｅｂサービスのセットは、以下の呼び出し、すなわち親アップデートサービスノードから認証構成情報を取得するためのＧｅｔＳｅｒｖｅｒＡｕｔｈＣｏｎｆｉｇ、親アップデートサーバノード構成情報および属性を取得するためのＧｅｔＣｏｎｆｉｇＤａｔａおよびＧｅｔＳｅｒｖｅｒＣｏｎｆｉｇＤａｔａ、親アップデートサービスノードから許可トークンを取得するためのＧｅｔＳｅｒｖｅｒＣｏｏｋｉｅ、親アップデートサービスノードからアップデートリストを取得するためのＧｅｔＲｅｖｉｓｉｏｎＩｄＬｉｓｔ、親アップデートサービスノードからアップデートメタデータおよびアップデートペイロードを取得するためのＧｅｔＵｐｄａｔｅＤａｔａ、およびアップデートサービスノード上で発生したアップデートアクティビティをその親アップデートサービスノードに報告するためのＲｅｐｏｒｔＥｖｅｎｔｓを含む。

クライアントアップデートモジュール２０４は、アップデートサービスノードに格納されているアップデートおよびアップデート情報に関して、クライアントコンピュータとアップデートサービスノード２００との間の通信を扱う。アップデート関連の通信は、クライアント要求に応答してアップデートを配布すること、および利用可能なソフトウェア製品のリストおよびクライアントコンピュータのための関連アップデートを提供することを含むが、それに制限されない。クライアントアップデートモジュール２０４は、クライアントコンピュータが関連の配布ルールに従って特定のアップデートを取得することを許可されるかどうかを決定する責任も負い、クライアントコンピュータがアクセスすることを許可されているアップデート関連の情報でクライアントコンピュータに応答する。

子アップデートモジュール２０６は、親アップデートサービスノードとその子アップデートサービスノードとの間のアップデート関連の通信を扱う。アップデート関連の通信は、子アップデートサービスノードに利用可能なソフトウェア製品および関連のアップデートのリストを識別すること、ならびに子アップデートサービスノードからのアップデート要求に応答することを含み、それに限られない。ダウンリンクアップデートモジュール２０６は、子アップデートサービスノードが関連の配布ルールに従って特定のアップデートを取得することを許可されるかどうかを決定する責任を負い、子アップデートサービスノードがアクセスを許可されているアップデート関連の情報で子アップデートサービスノードに応答する。

報告モジュール２０８は、どのグループが特定のアップデートを受信し、または受信していないか、どのクライアントコンピュータがアップデートをダウンロード／インストールし、またはしていないか、どのアップデートがアップデートサービスノード上で利用可能かなどのアップデート関連のレポートを生成する。これらのレポートは、例えば管理者によってなど内部で使用したり、親のアップデートサービスインターフェース２０２を介して親アップデートサービスノードに送信したりもできる。上述したように、課金のターゲット、またはメンテナンスのターゲットなど、どのクライアントコンピュータに特定のアップデートをインストールさせたかを企業が決定することはしばしば必要である。レポートモジュール２０８によって生成された情報／レポートは、これらのレポートの基礎となり得る。

認証／許可モジュール２１０は、認証に責任を負う。つまり、特定のクライアントコンピュータまたは子アップデートサービスノードの識別を決定すること、クライアントコンピュータまたは子アップデートサービスノードがアップデートサービスノード２００で利用可能なアップデートにアクセスすることを許可されるかどうかを決定することである。アップデートサービスノード上のアップデートにアクセスすることが認証され許可されたクライアントコンピュータおよび子アップデートサービスノードに対して、認証／許可モジュール２１０は、アップデート取得の併せて使用する必要がある許可トークンを発行する。許可トークンの発行および使用は、以下で図４Ａおよび４Ｂに対してより詳しく説明する。

管理ＡＰＩ２１２は、アップデートサービスノード２００の制御が遂行され、最終的にアップデートが格納され、配布されるアプリケーションインターフェースを表す。アップデートＷｅｂサービス２０２がクライアントコンピュータおよび子アップデートサービスノードから様々なアップデート関連の要求を受信するとき、これらの要求は、直接的または間接的にクライアントアップデートモジュール２０４および子アップデートモジュール２０６を通って、最終的に管理ＡＰＩ２１２への呼び出しに割り込む。管理ユーザインターフェース２１８、または管理ＡＰＩ２１２を使用するように適切に構成されているアップデートサービスノード２００にインストールされている他の何らかのプログラムに併せて、管理者は、そのアップデートサービスノードのためのアップデート処理のすべての態様を最終的に制御し、任意の子アップデートサービスノードおよびクライアントコンピュータについても同様である。管理ＡＰＩの実際の実施形態は、この明細書の付録として添付され、以下で図９−ＸＸとの関連でより詳しく記載される。

管理ユーザインターフェース２１８を通して、管理者は、管理ＡＰＩ２１２を介してアップデートサービスノード２００を構成し、維持するかもしれない。このように、管理ユーザインターフェース２１８を通して、管理者は、グループを生成し、修正し、削除だけでなく各グループにルールを関連付ける。さらに、管理ユーザインターフェース２１８を使用して、管理者は、クライアントコンピュータまたは子アップデートサービスノードがどのグループに属するかを設定する。管理ユーザインターフェース２１８によって、管理者は、クライアントコンピュータまたは子アップデートサービスノードへのアップデートの配布を明示的に許可してもよく、親アップデートサービスノードに、新しいアップデートを定期的に照会するためにアップデートサービスノード２００を構成してもよく、報告パラメータを構成してもよく、内部レポート等を表示してもよい。上述したように、管理ユーザインターフェース２１８は、管理者がアップデートサービスノード２００の態様への制御を行使することができるようにするが、管理ＡＰＩ２１２と動作するように適切に適応されているアップデートサービスノード２００上にある別のアプリケーションを、管理ユーザインターフェース２１８の代わりに使用してもよい。

上述したように、本発明の一実施形態によれば、アップデートサービスノード２００は、アップデート内容格納２１４およびアップデート情報格納２１６を含む。アップデート内容格納２１４は、バイナリやパッチファイルなどのソフトウェアアップデートを表す実際のファイルを格納する。それに対して、アップデート情報格納２１６は、アップデート内容格納２１４に格納されているアップデートファイルを含む、アップデートサービスノード２００上で利用可能なアップデートに対応する情報およびメタデータを格納する。一実施形態によれば、アップデート内容格納２１４およびアップデート情報格納２１６は、両方ともリレーショナルデータベースである。アップデートサービスノード例２００が２つのデータストアを有するものとして示されているが、本発明はそのように限定されるべきではない。代替の実施形態において、アップデート内容格納２１４およびアップデート情報格納２１６の両方が、単一の情報ストア内に結合されてもよい。

本発明の態様によれば、たとえアップデートがアップデート内容格納２１４に物理的に格納されていないとしても、クライアントコンピュータおよび子アップデートサービスノードに対して、ソフトウェアアップデートがアップデートサービスノード２００上で「利用可能」であるとして提示してもよい。より詳しくは、アップデートサービスノード２００上に実際のアップデートファイルをすぐにダウンロードし、格納するより、親アップデートサービスノード上またはその他の場所にあるアップデートファイルを参照するリンクを代わりにアップデートサービスノード上に格納してもよい。このようにクライアントコンピュータがアップデートを要求した場合、または子アップデートサービスノードが実際のアップデートを要求した場合、それをクライアントコンピュータまたは子アップデートサービスノードへ配信するのに備えて、アップデートは親アップデートサービスノードから運ばれ、アップデート内容ストアに格納される。この種のアップデートアクセスがジャストインタイムのダウンロード（ｊｕｓｔ−ｉｎ−ｔｉｍｅ ｄｏｗｎｌｏａｄｉｎｇ）と呼ばれることを当業者は認識するだろう。このように、「利用可能な」アップデートは、それが実際に要求されるまで、様々なネットワークチャネル上に配布される必要はない。本発明の態様によれば、アップデートサービスノード２００の管理者は、ジャストインタイムのやり方でソフトウェアアップデートを取得するかどうかを選択的に決定してよい。

図２の上記の説明は、アップデートサービスモジュール例２００の様々な構成要素を示しているが、アップデートサービスモジュールの他の構成要素も存在し得ることを理解されたい。さらに、上述した構成要素は、論理的な構成要素と理解されるべきで、必ずしも実際の構成要素である必要性はない。実際の実装において、上記で識別された構成要素は、実装の決定に従ってともに、かつ／または他の構成要素と結合されてもよい。さらに、アップデートサービスノード２００は、ネットワーク上のサーバコンピュータと見なすことができるが、実際の実装形態では、アップデートサービスノードは任意の数のタイプのコンピューティング装置上に実装してもよいことを理解されたい。例えば、各アップデートサービスノード２００は、単一のスタンドアロンコンピュータシステム、あるいは代わりに、複数のコンピューティング装置を含む分散コンピューティングシステム上に実装および／またはインストールされてもよい。

図３は、本発明の態様に従って形成された、図１に示されているルートアップデートサービスノード１０２のようなルートアップデートサービスノード３００の論理的な構成要素例を示すブロック図である。アップデートサービスノード２００の論理的な構成要素（図２）と同様に、ルートアップデートサービスノード３００は、アップデートＷｅｂサービス２０２、子アップデートモジュール２０６、認証／許可モジュール２１０を含む。さらに、ルートアップデートサービスノード例３００は、管理ＡＰＩ２１２、アップデート内容格納２１４、およびアップデート情報格納２１６も含む。任意で、ルートアップデートサービスノード３００は、クライアントアップデートモジュール２０４、報告モジュール２０８、および管理ユーザインターフェース２１８を含んでもよい。

クライアントアップデートモジュール２０４は、ルートアップデートサービスノードがソフトウェアアップデートをクライアントコンピュータに直接提供するかどうかによる、ルートアップデートサービスノード３００のオプションの任意の構成要素である。例えば、図１を参照すると、ルートアップデートサービスノード１０２は、クライアントコンピュータ１１２に直接サービスを提供するルートアップデートサービスノードとして、任意のクライアントアップデートモジュール２０４を含むことになる。しかし、ルートアップデートサービスノード３００がクライアントコンピュータに直接サービスを提供しない場合、クライアントアップデートモジュール２０４は省略することができる。

報告モジュール２０８は、ルートアップデートサービスノード３００で任意である。なぜなら、ルートアップデートサービスノードには、そのアップデートレポートが提供される親アップデートサービスノードを有さないからである。しかし、アップデートレポートがルートアップデートサービスノードの管理者にとって望ましい範囲で、報告モジュール２０８が任意で含まれてよい。

アップデートサービスノード２００（図２）に含まれる論理的な構成要素を含むことに加えて、ルートアップデートサービスノード３００は、ソフトウェアプロバイダインターフェース３０２も含む。ソフトウェアプロバイダインターフェース３０２は、ソフトウェアプロバイダ１１０（図１）がソフトウェアアップデートをルートアップデートサービスノード３００に直接的に出し、アップデート配布システム例１００に間接的に出す通信インターフェースを提供する。

図２のアップデートサービスノード２００と同様に、図３の上記の説明は、ルートアップデートサービスモジュール例３００の様々な構成要素を示している。しかし、ルートアップデートサービスモジュールの他の構成要素が存在してもよいことを理解されたい。さらに、上述した構成要素は、論理的な構成要素と理解されるべきであり、実際の構成要素である必要はない。実際の実装において、上記で識別された構成要素は、実装の決定に従ってともに、かつ／または他の構成要素と結合されてもよい。さらに、ルートアップデートサービスノード２００は、ネットワーク上のサーバコンピュータと見なすことができる一方で、実際の実装では、アップデートサービスノードは任意の数のコンピューティング装置上に実装してもよいことを理解されたい。例えば、ルートアップデートサービスノード３００は、単一のスタンドアロンコンピュータシステム、あるいは代わりに、複数のコンピューティング装置を含む分散コンピューティングシステム上に実装および／またはインストールされてもよい。

アップデート配布システム１００を通じて、アップデートがルートアップデートサービスノードからどのように配布されるかをよりよく理解するために、親アップデートサービスノードと子アップデートサービスノードとの間の交換例の説明が必要である。図４は、本発明の態様による、親アップデートサービスノードから子アップデートサービスノードにソフトウェアアップデートを伝える際の親アップデートサービスノード４０２と子アップデートサービスノード４０４との間の交換例４００を示すブロック図である。理解できるように、例示図４００は、半分に分割されていて、親アップデートサービスノード４０２のアクションおよびイベントに対応する左半分と、子アップデートサービスノード４０４のアクションおよびイベントに対応する右半分である。

図４に関しての説明のために、親アップデートサービスノード４０２は、アップデート配布システム１００のルートアップデートサービスノードであっても、そうでなくてもよいことをさらに理解されたい。さらに、この説明のため管理者によってソフトウェアアップデートの受信が明示的に許可されていない限り、親アップデートサービスノード４０２は、子アップデートサービスノード４０４がソフトウェアアップデートを受信しないよう、管理者によって構成されていると仮定する。

交換例４００で示したように、イベント４０６で始まり、親アップデートサービスノード４０２は、親アップデートサービスノードがルートアップデートサービスノード１０２である場合は直接、またはアップデート配布システム１００を介して間接的に、ソフトウェアプロバイダ１１０からソフトウェアアップデートを受信する。親アップデートサービスノード４０２がソフトウェアアップデートをソフトウェアプロバイダ１１０から受信した後のある時点で、子アップデートサービスノード４０４は、親アップデートサービスノードからソフトウェアアップデートを取得するプロセスを開始する。

一実施形態によれば、子アップデートサービスノード４０４は、定期的に親アップデートサービスノード２０２から利用可能なソフトウェアアップデートを自動的に取得するように構成することができる。さらに詳しくは、管理ユーザインターフェース２１８を介して、管理者は、定期的に親アップデートサービスノード４０２上で利用可能な最新のソフトウェアアップデートを自動的に取得するように、子アップデートサービスノード４０４を選択的に構成することができる。一例として、管理者は、毎日および／または１時間単位でその親アップデートサービスノード４０２から最新のソフトウェアアップデートを取得する、ならびに、自動アップデート処理が開始する時刻を指定するように子アップデートサービスノード４０４を構成することができる。他の定期的なスケジュールおよび基準を利用できる。同様に、管理者は、管理ユーザインターフェース２１８を介してアップデート処理を手動で開始することができる。

アップデート処理を開始するために、イベント４０８にて、子アップデートサービスノード４０４は、親アップデートサービスノード４０２で、それ自身を認証し、許可する。親アップデートサービスノード４０２での認証および許可は、ソフトウェアアップデートの配布に対する制御の要素に、許可されたアップデートサービスノードにアップデート配布を制限することを提供する。認証技術および許可技術は、当分野ではよく知られており、その任意数を、子アップデートサービスノード４０４を親アップデートサービスノード４０２により認証し、許可するのに採用することができる。本発明は、どの１つの技術にも制限されない。

親アップデートサービスノード４０２で適切に認証と許可した後、イベント４１０で、親アップデートサービスノード４０２は、子アップデートサービスノード４０４に、許可トークンを返す。一実施形態によれば、許可トークンは、限られた時間で親アップデートサービスノードとのアップデートアクティビティをさらに行うための許可を子アップデートサービスノード４０４に提供する時間依存のトークン（ｔｉｍｅ ｓｅｎｓｉｔｉｖｅ ｔｏｋｅｎ）である。このように、子アップデートサービスノード４０４が親アップデートサービスノードで適切に認証、許可されていない場合、許可トークンは返されず、子アップデートサービスノードは、認証および許可を除く他のどんなアップデート関連の動作を実行することができない。同様に、アップデートトークンが期限切れになった後、子アップデートサービスノード４０４は、再認証および再許可を除く親アップデートサービスノード４０２でさらなるアップデート関連の動作を実行することができない。

許可トークンを受信した後、イベント４１２で、子アップデートサービスノード４０４は、許可トークンと共に製品アップデートカタログの要求を親アップデートサービスノードに出す。製品アップデートカタログとは、親アップデートサービスノード４０２がソフトウェアアップデートを配布するソフトウェア製品の内容の一覧表または表を表す。

本発明の態様によれば、子アップデートサービスノード４０４は、その親アップデートサービスノード４０２上で利用可能なすべてのソフトウェアアップデートを広めることを求められない。例えば、図１のアップデート配布システム例を参照して、企業アップデートサービスノード１０４は、ルートアップデートサービスノード１０２上で利用可能なソフトウェア製品のごく一部分のみのサイトライセンスを有しているかもしれない。したがって、企業アップデートサービスノード１０４にとって、ほとんどは決して使用されないので、ルートアップデートサービスノード１０２で利用可能なすべてのソフトウェアアップデートを取得する必要はないだろう。したがって、アップデートサービスノードの管理者は、どのソフトウェア製品アップデートがアップデートサービスノードで利用可能であるかを選択的に規定することができる。

本発明の一態様によれば、親アップデートサービスノード４０２から取得されたアップデート製品カタログは、子アップデートサービスノード４０４が各製品にアップデートを配布するように構成されているかどうかに関わらず、アップデートを利用可能なすべてのソフトウェア製品を識別する。しかし、本発明の代替の態様によれば、親アップデートサービスノード４０２から取得されるアップデート製品カタログは、要求している子アップデートサービスノードがアップデートを配布するように構成されているこれらのソフトウェア製品のみを識別する。例えば、どのソフトウェア製品が製品アップデートカタログに列挙されるかの制限は、子アップデートサービスノード４０４が属するグループまたはグループ群に従って決定されるかもしれない。

イベント４１４で、親アップデートサービスノード４０２は、製品アップデートカタログを子アップデートサービスノード４０４へ返す。イベント４１６で、子アップデートサービスノード４０４は、最新のアップデートが現在望まれている製品を、製品アップデートカタログから選択する。製品アップデートカタログが、子アップデートサービスノード４０４が配布するこれらのソフトウェア製品のみを列挙することができるにも関わらず、異なる時間、異なる期間スケジュールで、異なるソフトウェア製品のアップデートを取得するよう構成されてもよいことに留意されたい。

イベント４１８で、子アップデートサービスノード４０４は、子アップデートサービスノードが現在探している選択された製品を識別するアップデート同期要求を、許可トークンと共に出す。同期要求に含まれるものは、子アップデートサービスノード４０４上の製品に利用可能な最新のアップデートを識別する情報である。製品の最新のアップデートを識別する情報は、以下「アップデートアンカー」と呼ばれる。各ソフトウェア製品のアップデートアンカーは、一般に、アップデート情報格納２１６（図２）に格納される。一実施形態において、アップデートアンカーは、改訂番号および改訂番号に関連付けられている日付を含む。

アップデート同期要求に応答して、イベント４２０で、親アップデートサービスノード４０２は、もしあれば、どの新しいアップデートが子アップデートサービスノード４０４に利用可能であるか、決定する。上述したように、この決定は、特定のソフトウェアアップデート、および子アップデートサービスノード４０４がメンバーであるグループまたはグループ群に関連付けられている特定のルール、ならびにアップデートアンカーに基づいている。例えば、前述したように、前に受信したソフトウェアアップデートは、子アップデートサービスノード４０４に明示的に許可されていない。したがって、イベント４０６で受信されたソフトウェアアップデートは、子アップデートサービスノード４０４には「利用可能」とは決定されない。したがって、イベント４２２で、イベント４０６で受信されたソフトウェアアップデートの識別無しに、アップデートリストが子アップデートサービスノード４０４へ返される。本発明の態様によれば、アップデートリストは、同期要求に従って親アップデートサービスノード４０２で「利用可能な」アップデートのすべてを識別する。一実施形態において、アップデートリストは、アップデートに関連付けられている一意の識別子によって「利用可能な」各アップデート情報を識別する。

イベント４２４で、アップデートリストが空、すなわち、現在親アップデートサービスノード４０２で「利用可能」なアップデートがないため、子アップデートサービスノード４０４のアップデート処理は、単に、予め定められた時間の間遅延または休止する。現在の例によれば、この遅延期間の間、イベント４２６で、親アップデートサービスノード４０２の管理者は、イベント４０６で受信されたソフトウェアアップデートが子アップデートサービスノード４０４に配布されるのを許可する。

イベント４２８（図４Ｂ）で、子アップデートサービスノード４０４は、親アップデートサービスノード４０２でそれ自身を認証し、許可することによって、自動アップデート処理を再開する。これに応答して、イベント４３０で、親アップデートサービスノード４０２は、子アップデートサービスノード４０４に、許可トークンを返す。

イベント４３２で、子アップデートサービスノード４０４は、許可トークンとともに、製品アップデートカタログの要求を、親アップデートサービスノード４０２に出す。イベント４３４で、親アップデートサービスノード４０２は、製品アップデートカタログを子アップデートサービスノード４０４に返す。イベント４３６で、子アップデートサービスノード４０４は、アップデートが望まれているアップデートカタログの製品を選択する。イベント４３８で、子アップデートサービスノード４０４は、これらの選択された製品を識別するアップデート同期要求を、許可トークンとともに出す。

子アップデートサービスノード４０４がイベント４０６で前に受信されたソフトウェアアップデートを取得することを許可されていたため、イベント４４０で、親アップデートサービスノード４０２は、ソフトウェアアップデートが子アップデートサービスノードに「利用可能」であることを決定し、アップデートリストの対応するアップデート情報を含む。その後、イベント４４２で、親アップデートサービスノード４０２は、イベント４０６で受信されたソフトウェアアップデートを識別するようになったアップデートリストを子アップデートサービスノード４０４に返す。

親アップデートサービスノード４０２で「利用可能」なアップデートを識別するアップデートリストで、子アップデートサービスノード４０４は、ソフトウェアアップデートを取得するのに必要な情報を今、有している。本発明の一実施形態によれば、子アップデートサービスノード４０４は、次の２つの部分で、親アップデートサービスノード４０２からソフトウェアアップデートを取得する。それは、アップデートメタデータを取得することと、以下アップデートペイロードと呼ばれるアップデート内容またはファイルを取得することである。本発明の追加の態様によれば、アップデートメタデータは、ソフトウェアアップデートに関係する態様を記述するが、以下に限定されない。それは、アップデートを一意に識別するアップデート識別子、ソフトウェアアップデートに関連付けられている改訂番号情報、ソフトウェアアップデートが優先と考えられるべきであるかどうか、言語固有の情報、他のソフトウェアアップデートとの関係、ダウンロードのためのアップデートペイロードの場所、インストールハンドラルーチンなどである。

ソフトウェアアップデート全体を２つの部分、すなわちアップデートメタデータおよびアップデートペイロードでダウンロードすることがしばしば有益である理由の一部は、アップデートペイロードがアップデートメタデータより大幅に大きいこと、およびアップデートペイロードが常にすぐに必要ではない、すなわち、もし必要になったら、クライアントコンピュータへのインストールに必要となることである。このように、本発明の一実施形態によれば、アップデートペイロードは、アップデートメタデータとは別にダウンロードされ、それは必要なときだけである。当業者であれば、このダウンロード技術を、遅延ダウンロードとして、あるいは代わりにジャストインタイムのダウンロードとして認識されるだろう。本発明の態様によれば、管理者は、アップデートペイロードを、ジャストインタイム方法で、またはアップデートメタデータを取得するとすぐに取得するためのアップデートサービスノードを構成してもよい。さらに、代替実施形態において、アップデートメタデータおよびアップデートペイロードを共同でダウンロードしてもよい。

図４Ｂに示すように、アップデートがアップデートリストで識別された状態で、イベント４４４で、子アップデートサービスノード４０４は、アップデートメタデータに、アップデートリスト内のその一意の識別子に従って「利用可能な」ソフトウェアアップデートを要求する。親アップデートサービスノード４０２との他のほとんどの通信交換と同様に、アップデート要求は、許可トークンとともに出される。図示された例では、すべてのアップデートメタデータが一度のアクセスでダウンロードされているが、本発明の代替の態様（図示せず）によれば、アップデートメタデータは、複数回のアクセスでダウンロードされてもよいことに留意されたい。例えば、最初のアクセスで、適応可能性のルールや他のソフトウェアアップデートへの従属性のような、ソフトウェアアップデートが適用可能か、および／または望ましいかを決定するのに必要なアップデートメタデータの要素のみが最初にダウンロードされる。次いで、アップデートが適用可能であり、かつ／または望ましいことが決定された後、アップデートメタデータの残りが取得されてもよい。それに応答して、イベント４４６で、親アップデートサービスノード４０２は、ソフトウェアアップデートのアップデートメタデータを子アップデートサービスノード４０４に戻し、次いで子アップデートサービスノードは、アップデートメタデータをアップデート情報格納２１６に格納する。

一実施形態において、アップデートメタデータは、以下を含むが、以下だけには限定されない。それは、特定のアップデートに関連付けられている一意の識別子、アップデートのサイズ、アップデートによって対処される問題、改訂／アンカー情報などのアップデートの説明、そのアップデートは前のアップデートがインストールされていることを必要とするか、アップデートが分けてインストールされなければならないか、アップデートが他の利用可能なアップデートに入れ替えられるかなどのアップデート適用可能性ルール、エンドユーザライセンス同意データ、親アップデートサービスノード４０２に格納されていない場合、およびアップデートペイロードを配置し、かつ／またはそれにアクセスするためのＵＲＬ情報である。

任意に、イベント４４８で、子アップデートサービスノード４０４は、アップデートペイロードを親アップデートサービスノード４０２からダウンロードする要求を出す。それに応答して、イベント４５０で、親アップデートサービスノード４０２は、アップデートペイロードを子アップデートサービスノード４０４に返し、子アップデートサービスノードは、それを順にアップデート内容格納２１４に格納する。

子アップデートサービスノード４０４でちょうど今アップデート動作が生じたので、イベント４５２で、子アップデートサービスノードは、ちょうど最近に生じたアップデート動作を概説するアップデート報告を生成し、親アップデートサービスノード４０２に出す。その後、子アップデートサービスノード４０４は、次にアップデート処理が稼動するように予定される（図示せず）ときまで再度遅延する。

上記のイベントは例示のターゲットであり、特定のイベントセットおよび状況の例を反映していることを当業者であれば理解されよう。明らかに、何らかの変更を上述したイベントにもたらす特定の詳細および状況に従って他のイベントが生成されるかもしれない。さらに、子アップデートサービスノード４０４は、親アップデートサービスノード４０２から最新の「利用可能な」ソフトウェアアップデートを取得している間、その子アップデートサービスノードからのアップデート要求を同時に処理してもよいことを理解されたい。したがって、上記のイベントのシーケンスは、例示としてだけであり、本発明に対する制限と見なされるべきではない。

図５は、その親アップデートサービスノードからアップデートを定期的に取得するために、図１の企業アップデートサービスノード１０４などの子アップデートサービスノード上で実行されるルーチン例５００を示すフロー図である。ブロック５０２で開始し、子アップデートサービスノードは、「利用可能な」アップデートの同期済みアップデートリストを親アップデートサービスノードから取得する。「利用可能な」アップデートの同期済みアップデートリストを親アップデートサービスノードから取得するは、以下で図６との関連で説明する。

図６は、「利用可能な」アップデートの同期済みアップデートリストを親アップデートサービスノードから取得するための、図５のルーチン例５００での使用に適したサブルーチン例６００のフロー図である。ブロック６０２で開始し、図４Ａおよび図４Ｂとの関連で前述したように、子アップデートサービスノードは、親アップデートサービスノードでそれ自身を認証、許可し、適切な認証および許可に応答して、許可トークンを受信する。ブロック６０４で、許可トークンと併せて、子アップデートサービスノードは、親アップデートサービスノードとの通信パラメータを規定する。通信パラメータの規定によって、親および子のアップデートサービスノードは、親と子の両方が理解する共通基準を適切に規定することができる。通信パラメータには、通信アップデートプロトコルまたはバージョン、製品グループなどを含み、それに制限されない。

親アップデートサービスノードとの通信パラメータを規定した後、ブロック６０６で、子アップデートサービスノードは、親アップデートサービスノードがアップデートを提供／配布するソフトウェア製品を記述する製品アップデートカタログを取得する。ブロック６０８で、子アップデートサービスノードは、アップデートが現在求められているそれらのソフトウェア製品アップデートを選択する。ブロック６１０で、子アップデートサービスノードは、許可トークン、および子アップデートサービスノード上にすでにある現在のバージョンおよびアップデートを識別する選択されたソフトウェア製品に関連付けられている「アンカー」の両方を含めて、アップデート同期要求を親アップデートサービスノードに出す。

アップデート同期要求に応答して、ブロック６１２で、子アップデートサービスノードは、子アップデートサービスノードに現在何が格納されているかに従って、親アップデートサービスノード上で「利用可能な」ソフトウェアアップデートに従って同期されたアップデートリストを親アップデートサービスノードから取得する。上述したように、アップデートリストは、一意の識別子によって、子アップデートサービスノードに「利用可能な」親アップデートサービスノード上のそれらのソフトウェアアップデートを識別する。その後、サブルーチン例６００は終了する。

再度図５を参照すると、同期したアップデートリストを親アップデートサービスノードから取得した後、決定ブロック５０４で、親アップデートサービスノードからのダウンロードに現在「利用可能」なソフトウェアアップデートがあるかどうかについての決定がなされる。この決定は、同期したアップデートリストに列挙されているアップデート識別子があるかどうかに従ってなされる。現在ダウンロードに「利用可能な」ソフトウェアアップデートがない場合、ルーチン例５００は、遅延ブロック５１０に進み、そこでルーチン例は、次のアップデート期間が生じるまで遅延／休止する。あるいは、親アップデートサービスノードからのダウンロードに「利用可能な」アップデートがある場合、ブロック５０６で、子アップデートサービスノードは、親アップデートサービスノードからアップデートを取得する。「利用可能な」アップデートを親アップデートサービスノードから取得することについては、以下で図７との関連で説明する。

図７は、親アップデートサービスノードから「利用可能な」ソフトウェアアップデートを取得するための、図５のルーチン例５００での使用に適したサブルーチン例７００のフロー図である。ブロック７０２で開始し、アップデートリスト内の最初のアップデート識別子が選択される。ブロック７０４で、子アップデートサービスノードは、親アップデートサービスノードから選択されたアップデート識別子に対応するアップデートメタデータを取得し、それをアップデート情報格納２１６に格納する。

一実施形態によれば、ブロック７０６で、子アップデートサービスノードは、親アップデートサービスノードから選択されたアップデート識別子に対応するアップデートペイロードを取得し、アップデートペイロードをアップデート内容ストア２１２に格納する。任意で、アップデート内容は子アップデートサービスノードにすぐにダウンロードされる必要はない。前述したように、子アップデートサービスノードを、親アップデートサービスノードからジャストインタイム方式でアップデートをダウンロードするように選択的に構成することができる。この任意の取り扱いによれば、図７に示されているように、ブロック７０４からブロック７０６へ処理するよりむしろ、サブルーチン例７００は、ブロック７０４から決定ブロック７０８へ任意で処理される。

決定ブロック７０８で、選択されたアップデート識別子のアップデートメタデータ、および任意のアップデートペイロードを取得した後、アップデートリストにさらに追加のアップデート識別子があるかどうかについての決定がなされる。別のアップデート識別子がある場合、ブロック７１０で、アップデートリスト内の次のアップデート識別子が選択され、サブルーチン７００は、追加の処理のためにブロック７０４に戻る。ルーチン７００は、決定ブロック７０８でアップデートリスト内にさらにアップデート識別子がないことが決定されるまで続き、その後すぐサブルーチン例７００は終了する。

再度図５に戻って、「利用可能な」アップデートを親アップデートサービスノードから取得した後、ブロック５０８で、子アップデートサービスノードは、親アップデートサービスノードへアップデートアクティビティを報告する。その後、遅延ブロック５１０で、ルーチン例５００は、次のアップデート期間まで、予め決められた時間期間、遅延／休止し、そしてそれからブロック５０２へ進んで上記のアップデート手順を繰り返す。

図５で示されるように、決定ブロック５０４で、親アップデートサービスノードで「利用可能な」アップデートがないときでさえ、子アップデートサービスノードは、そのアップデートアクティビティを親アップデートサービスノードに報告するよう、任意で構成されてもよい。この代替構成によれば、利用可能なアップデートがないとき、ルーチン例５００は、アップデートアクティビティを報告するためにブロック５０８に進むことができる。

図８は、子アップデートサービスノードからのアップデート同期要求に応答して、「利用可能な」アップデートを識別する同期済みアップデートリストを生成するために、親アップデートサービスノード上で実施されるルーチン例８００のフロー図である。ブロック８０２で始まり、親アップデートサービスノードは、子アップデートサービスノードから、「利用可能な」アップデートを識別するアップデートリストのためのアップデート同期要求を受信する。ブロック８０４で、アップデート同期要求で識別された最初のソフトウェア製品が選択される。

決定ブロック８０６で、識別されたソフトウェア製品のための利用可能なアップデートがあるかどうかについての決定がなされる。この決定は、アップデート情報格納２１６に格納されているソフトウェア製品のためのメタデータに従って、子アップデートサービスノードによって提供されたアップデートアンカーに従って、および子アップデートサービスノードが属するグループに関連付けられている配布ルールに従って行われる。この決定に従って、「利用可能な」アップデートがある場合、ブロック８０８で、「利用可能な」アップデートに関連付けられている一意のアップデート識別子はアップデートリストに書き込まれる。「利用可能な」アップデートのための一意のアップデート識別子をアップデートリストに書き込んだ後、決定ブロック８１０で、アップデート同期要求で識別されたソフトウェア製品がさらにあるかどうかについての決定がなされる。アップデート同期要求に追加のアップデートソフトウェア製品がある場合、ブロック８１４で、親アップデートサービスノードは、アップデート同期要求で識別された次のソフトウェア製品を選択し、選択されたソフトウェア製品の「利用可能な」アップデートがあるかどうかを決定するために、決定ブロック８０６に戻る。あるいは、アップデート同期要求で識別されたソフトウェア製品がそれ以上ない場合、ブロック８１４で、アップデートリストが子アップデートサービスノードに返される。その後、サブルーチン例８００は終了する。

上述したように、アップデートサービスノードは、管理ユーザインターフェース２１８または同じように装備された他の何らかのモジュールを介して、管理ＡＰＩ２１２を通して管理される。管理ＡＰＩ２１２がどのように動作するかをよりよく理解するために、図９は、ソフトウェアアップデートをクライアントコンピュータに配布するためにアップデートサービスノードを構成することに関して、管理ＡＰＩがどのように利用されるかを示す図である。

図９に示すように、管理者は、管理ＡＰＩを使用して、サブスクリプション９０４およびグループ９０６を生成する。アップデートサービスノードは、アップデート処理９０８中、そのアップデートサービスノードに利用可能なアップデート９０２、ならびに、アップデートをクライアントコンピュータ９１２〜９２２などのクライアントコンピュータに配布するためのサブスクリプション９０４およびグループ９０６を使用する。

当業者には理解できるように、管理者は、特定の製品または製品ファミリをアップデートするためのサブスクリプションと同時に、アップデートのクラスを生成する。例えば、製品は、Ｍｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎのＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ製品でもよく、サブスクリプションは、この製品を利用可能なアップデート待ちに示すことになる。同様に、製品ファミリは、一般に、多数の識別可能な製品である製品ファミリとしてのＭｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎのＯｆｆｉｃｅなど、多くの製品を示す。また、サブスクリプションは一般に、クライアントコンピュータへのダウンロードを承認されたアップデートのタイプの識別もする。例えば、アップデートのタイプは、危機的、重大、一般などとすることができる。

本発明の一実施形態によれば、クライアントコンピュータは、いくつかのグループに編成され、サブスクリプションおよびアップデートは、グループに適用される。実際の実施形態において、各クライアントコンピュータは、２つのグループ、すなわちすべてのコンピュータグループ、および他の１つのグループに属する。この実際の実施形態によれば、アップデートサービスノードは、すべてのコンピュータグループおよび他の１つの未割当のコンピュータグループを定義してきた。管理ＡＰＩ２１２を通して、管理者は、任意の数の他のグループ、およびグループに割り当てられたクライアントコンピュータを自由に定義することができる。クライアントコンピュータをグループに割り当て損ねることによって、クライアントコンピュータが未割当のグループに残される。簡単に言えば、この実施形態によれば、クライアントコンピュータは、すべてのコンピュータグループおよび他の１つのグループに属する。グループは、任意の数のクライアントコンピュータを含むことができる。ソフトウェアアップデートを適用するためのクライアントコンピュータのグループは、図９にボックス９１０、９２４、９２６として示されている。

実際の実施形態によれば、管理ＡＰＩ２１２は、Ｍｉｃｒｏｓｏｆｔ社のＷｉｎｄｏｗｓ Ｓｏｆｔｗａｒｅ Ｕｐｄａｔｅ Ｓｅｒｖｉｃｅｓが構成され、管理されることを介するインターフェースである。この実施形態において、管理ＡＰＩ２１２は、一般に、インターフェースオブジェクトＩＵｐｄａｔｅＳｅｒｖｅｒによって実施され、またはそれを介してアクセス可能である。ＩＵｐｄａｔｅＳｅｒｖｅｒインターフェースオブジェクトの実際の実施形態の説明は、表１としてこのセクションの終わりに列挙されている。このＩＵｐｄａｔｅＳｅｒｖｅｒインターフェースオブジェクトは、参照により本明細書に組み込まれている、２００４年３月１２日出願の特許文献１の一部として含まれる管理ＡＰＩ文書の一部である。しかし、表１で識別されている様々なインターフェース呼び出しは、以下で図１０との関連で概説する。

図１０は、アップデートサービスノード上のソフトウェアアップデートの配布を管理するための、ある管理ＡＰＩ呼び出しを示すブロック図である。ＩＵｐｄａｔｅＳｅｒｖｅｒ１００２オブジェクトへのアクセスで、呼び出し側は、アップデートサービスノード構成情報１００４、現在のサブスクリプション情報１００６、現在の承認ルール１００８、アップデートサービスノード状況情報１０１０、アップデート取得１０１２、クライアントコンピュータ取得１０１４、およびグループ取得１０１６を取得するためのインターフェース呼び出しを行うことができる。

構成情報インターフェース呼び出し１００４は、使用可能な言語、どれが親アップデートサービスノードであり、その親アップデートサービスノードの場所であるか、プロキシサーバおよびアドレス、アップデートサービスノードがアップデートをその親アップデートサービスノードと同期させるモードなどを含むがそれに制限されずに、アップデートサービスノードの構成可能（および読み取り可能）な値へのアクセスを提供する。実際の実施形態において、添付の付録に示されているように、構成情報インターフェース呼び出し１００４は、ＩＵｐｄａｔｅＳｅｒｖｅｒオブジェクト上での「ＧｅｔＣｏｎｆｉｇｕｒａｔｉｏｎ」インターフェース呼び出しであり、アップデートサービスノードのためのＩＣｏｎｆｉｇｕｒａｔｉｏｎインターフェースオブジェクトのインスタンスを返す。ＩＣｏｎｆｉｇｕｒａｔｉｏｎインターフェースオブジェクトは、組み込まれた仮出願のＡＰＩにより詳しく説明されている。

サブスクリプション情報インターフェース呼び出し１００６は、最新のサブスクリプション作業の状況、次のサブスクリプション作業（特定のアップデートをクライアントコンピュータにダウンロードするなど）がいつ完了するか、サブスクリプション同期の頻度などを含み、それだけに制限されない、サブスクリプション情報へのアクセスを提供する。実際の実施形態において、サブスクリプション情報を取得するための異なるインターフェース呼び出しが少なくとも２つある。ＩＵｐｄａｔｅＳｅｒｖｅｒオブジェクト上の「ＧｅｔＳｕｂｓｃｒｉｔｉｏｎ」インターフェース呼び出しは、アップデートサービスノード上の特定のサブスクリプションに対応するＩＳｕｂｓｃｒｉｐｔｉｏｎインターフェースオブジェクトを返し、「ＧｅｔＳｕｂｓｃｒｉｐｔｉｏｎｓ」インターフェース呼び出しは、ＩＳｕｂｓｃｒｉｐｔｉｏｎインターフェースオブジェクトの集まりを返す。さらに、サブスクリプションは、アップデートサービスノード上に空のサブスクリプションを作成する「ＣｒｅａｔｅＳｕｂｓｃｒｉｐｔｉｏｎ」インターフェース呼び出しを使用して作成される。ＩＳｕｂｓｃｒｉｐｔｉｏｎインターフェースオブジェクトの詳細は、仮出願の組み込まれたＡＰＩに記載されている。

アップデートサービスノード状況インターフェース呼び出し１０１０は、現在展開されているアップデート、利用可能なアップデートなどを含み、それだけには制限されない、アップデートサービスノード状況へのアクセスを提供する。実際の実施形態において、「ＧｅｔＵｐｄａｔｅｓＳｕｍｍａｒｙ」インターフェース呼び出しは、アップデートサービスノードの全アップデートサマリー情報を記述するサマリー収集オブジェクトを返す。このインターフェース呼び出しに関する詳細は、仮出願の組み込まれたＡＰＩに記載されている。

アップデート取得のインターフェース呼び出し１０１２は、利用可能なソフトウェアアップデートに関する情報へのアクセスを提供する。さらに詳しくは、インターフェース呼び出しは、システム内のすべての利用可能なソフトウェアアップデートへのアクセスを提供する。実際の実施形態において、アップデート情報を取得するためのインターフェース呼び出しがいくつかある。「ＧｅｔＵｐｄａｔｅ」インターフェース呼び出しは、システム上の特定のアップデートに関する情報を提供するＩＵｐｄａｔｅオブジェクトを返す。加えて、「ＧｅｔＵｐｄａｔｅｓ」インターフェース呼び出しは、システムへ利用可能なＩＵｐｄａｔｅｓオブジェクトの集まりを返す。これらのインターフェース呼び出しに関する追加の詳細は、仮出願の組み込まれたＡＰＩに提供されている。

コンピュータ取得のインターフェース呼び出し１０１４は、アップデートサービスノードに関連付けられているクライアントコンピュータへのアクセスを提供する。実際の実施形態において、インターフェース呼び出しで識別されたクライアントコンピュータに対応するＩＣｏｍｐｕｔｅｒオブジェクトを返す「ＧｅｔＣｏｍｐｕｔｅｒ」インターフェース呼び出し、およびＩＣｏｍｐｕｔｅｒオブジェクトの集まりを返す「ＧｅｔＣｏｍｐｕｔｅｒｓ」インターフェース呼び出しを含みそれに制限されない、様々なクライアントコンピュータに関する情報にアクセスするためのインターフェース呼び出しが少なくとも２つあり、この集まりは、アップデートサービスノードに関連付けられているすべてのクライアントコンピュータを含む。上記のように、ＩＵｐｄａｔｅＳｅｖｅｒオブジェクト上のこのインターフェース呼び出しに関するさらなる詳細は、仮出願の組み込まれたＡＰＩに記載されている。

グループ取得のインターフェース呼び出し１０１６は、アップデートサービスノード上で定義されたグループへのアクセスを提供する。上述したように、実際の実施形態では、各クライアントコンピュータは、すべてのコンピュータグループ、および他の１つのグループに属する。クライアントコンピュータがグループに割り当てられていない場合、そのクライアントコンピュータは、未割当のグループにデフォルト設定される。少なくともこの実際の実施形態では、インターフェース呼び出しに渡されるグループ識別子に対応するＩＴａｒｇｅｔＧｒｏｕｐオブジェクトを返す「ＧｅｔＴａｒｇｅｔＧｒｏｕｐ」インターフェース呼び出し、およびアップデートサービスノード上で定義されたすべてのグループに対応するＩＴａｒｇｅｔＧｒｏｕｐオブジェクトの集まりを返す「ＧｅｔＴａｒｇｅｔＧｒｏｕｐｓ」インターフェース呼び出しを含み、それらに制限されない、多くのインターフェース呼び出しが利用可能である。

インターフェース呼び出しのいくつかを説明してきたが、それらは、インターフェース呼び出しの包括的なセットではないことを当業者は理解するだろう。実際に、添付の付録に示されているように、管理ＡＰＩの実際の実施形態は、多数のインターフェース呼び出しを含み、その大部分については特には説明していない。

次の表、表１に関して、略語ＷＵＳは、Ｗｉｎｄｏｗｓ Ｕｐｄａｔｅ Ｓｅｒｖｅｒの頭字語である。

好適な実施形態を含む、本発明の様々な実施形態について示し、説明してきたが、本発明の意図および範囲から逸脱することなく、様々な変更を加えることができることを理解されたい。

独占排他的な所有権または恩恵が請求される本発明の実施形態は、添付のように定義される。

本発明の態様に従って形成されたアップデート配布システム例の絵図である。 本発明の態様に従って形成されたアップデートサービスノードの論理的な構成要素例を示すブロック図である。 本発明の態様に従って形成されたアップデートサービスノードの論理的な構成要素例を示すブロック図である。 本発明の態様による、親アップデートサービスノードから子アップデートサービスノードへソフトウェアアップデートを提供する際に親アップデートサービスノードと子アップデートサービスノードとの間の交換例を示すブロック図である。 本発明の態様による、親アップデートサービスノードから子アップデートサービスノードへソフトウェアアップデートを提供する際に親アップデートサービスノードと子アップデートサービスノードとの間の交換例を示すブロック図である。 親アップデートサービスノードからアップデートを定期的に取得するための、子アップデートサービスノード上で実行されるルーチン例を示すフロー図である。 親アップデートサービスノードからアップデートカタログを取得するための、図５のルーチン例での使用に適したサブルーチン例のフロー図である。 親アップデートサービスノードからソフトウェアアップデートを取得するための、図５のルーチン例での使用に適したサブルーチン例のフロー図である。 子アップデートサービスノードからのアップデート要求を処理するためのルーチン例のフロー図である。 ソフトウェアアップデートがクライアントコンピュータに配布するために、アップデートサービスノードを構成するに関して、管理ＡＰＩがどのように使用されるかを示す絵図である。 アップデートサービスノード上でソフトウェアアップデートの配布を管理するためのある管理ＡＰＩ呼び出しを示すブロック図である。

Claims (7)

1. ソフトウェアアップデートの配布を管理するためのアップデートサービスノードであって、
   ソフトウェアアップデートを格納するためのアップデートストアと、
   前記アップデートサービスノードが通信ネットワークを介して親アップデートサービスノードからソフトウェアアップデートを取得し、前記アップデートサービスノードが前記通信ネットワークを介して子アップデートサービスノードにソフトウェアアップデートを配布するアップデートＷｅｂサービスであって、前記アップデートＷｅｂサービスは、ソフトウェアアップデートのカタログを生成するよう動作可能であり、特定の子アップデートサービスノードから前記カタログの要求を受信し、前記特定の子アップデートサービスノードが属する配布グループに基づいて、制限されたソフトウェアアップデートを列挙するカタログをそれぞれ提供する、アップデートＷｅｂサービスと、
   管理者が配布グループを定義し、各配布グループに関連付けられた配布ルールを確立する管理ＡＰＩ（アプリケーションプログラミングインターフェース）であって、前記配布ルールは、各配布グループに含まれる子アップデートサービスノードおよびクライアントコンピュータへソフトウェアアップデートを配布するための条件を指定する、管理ＡＰＩと
   を備えたことを特徴とするアップデートサービスノード。
2. 前記管理ＡＰＩは、少なくとも前記アップデートサービスノードの親アップデートサービスノードを示す値へのアクセスを提供することを特徴とする請求項１に記載のアップデートサービスノード。
3. 前記管理ＡＰＩは、特定の子アップデートサービスノードおよびクライアントコンピュータへのソフトウェアアップデートの配布情報へのアクセスを提供することを特徴とする請求項２に記載のアップデートサービスノード。
4. 前記配布情報は、ソフトウェアアップデートを一意に識別するアップデート識別子により特定されることを特徴とする請求項３に記載のアップデートサービスノード。
5. 前記配布情報は、配布グループを一意に識別するグループ識別子により特定されることを特徴とする請求項３に記載のアップデートサービスノード。
6. 前記管理ＡＰＩは、前記アップデートサービスノードで利用可能なソフトウェアアップデートのすべてを識別するアップデートリストを提供することを特徴とする請求項１に記載のアップデートサービスノード。
7. 前記ソフトウェアアップデートは当該ソフトウェアアップデートの内容であるアップデートペイロードと、当該ソフトウェアアップデートに関連する態様を記述するアップデートメタデータとを含み、
   前記アップデートペイロードは、前記アップデートメタデータとは別に配布されることを特徴とする請求項１に記載のアップデートサービスノード。

Images