JP2005259115A - 更新配信システム中で更新メタデータを配信するためのタグベースのスキーマ - Google Patents

Abstract

【課題】 ソフトウェア更新メタデータ情報をクライアントコンピュータおよび更新サービスノードに通信するためのタグベースの構造を提供すること。
【解決手段】 更新メタデータファイルは、ソフトウェア更新を一意に識別する識別子を含む識別タグと、ソフトウェア更新をインストールするためのソフトウェアハンドラに向けた情報を伝えるハンドラ特有データタグと、０個またはそれ以上の、ソフトウェア更新に関係する情報を伝える一般プロパティタグと、言語に従ったローカライズプロパティ情報を伝えるローカライズプロパティタグと、更新メタデータ中に記述された現ソフトウェア更新が他のソフトウェア更新に対して有する依存関係を識別する関係タグと、クライアントコンピュータに対するソフトウェア更新の適用性を決定する情報を伝える適用性規則タグと、ソフトウェア更新のペイロードファイルに関係する情報を伝えるファイルタグとを備える。
【選択図】 図１

Description

本発明はソフトウェアおよびコンピュータネットワークに関し、より詳細には、本発明は、更新配信システム中で更新メタデータを配信するためのタグベースのスキーマに関する。

ほぼすべての市販ソフトウェア製品は、ソフトウェアの機能を修復または更新するための継続的な改訂プロセスを受ける。ソフトウェア製品の各改訂はしばしば、新しいファイルを追加すること、既存のファイルをより新しい改訂で置換すること、旧ファイルを削除すること、またはこれらの動作の様々な組合せを必要とする。この、ソフトウェア製品の古いファイルの置換、新しいファイルの追加、旧ファイルの削除や、機能を追加および／または削除することによってソフトウェア製品の構成および挙動を変更するといったプロセスを、以下では「製品を更新する」と言い、バイナリファイル、データファイル、更新命令、メタデータなどを含めた、製品を更新するのに使用されるデータ集合を、以下ではより単純に「更新（アップデート）」と言う。

ソフトウェアプロバイダは、問題の修復、セキュリティ強化、または新機能の追加のためにソフトウェア製品の更新を作成すると、この更新をその顧客ベースに対して広く利用可能にしたいと思うことになる。更新が、製品中の欠陥を補正することやクリティカルなセキュリティ問題に対処することに向けられているときなど、ソフトウェアプロバイダがこの更新をできるだけ早く顧客のコンピュータにインストールさせたいと思うことは非常に多い。実際、ほとんどのソフトウェアプロバイダは、ソフトウェア更新をその顧客にできるだけ早く、またできるだけトラブルなく配信するというビジネス上の動機を有する。

コンピュータ産業は、ネットワークに、特にインターネットに接続されたコンピュータの数の爆発的な増加を体験している。この爆発的な増加により、またインターネット接続を介して利用可能な通信能力により、インターネットは、ソフトウェアプロバイダがその顧客に更新を配信するための重要かつ不可欠なチャネルになった。実際、インターネットは、多くのソフトウェアプロバイダがその顧客にソフトウェア更新を配信するための主要な配信チャネルになっている。インターネットを介した電子更新配信は、ソフトウェアプロバイダのコスト全体を削減するので、またソフトウェア更新が入手可能になればすぐに顧客がそれを入手することができるので、インターネットを介してソフトウェア更新を配信するのが最もソフトウェアプロバイダの利益になることが多い。これらのソフトウェア更新がどんなユーザ介入もなしに自動的にインターネットを介して実施されることは、ますます多くなっている。

インターネットは現在、ソフトウェアプロバイダからソフトウェア更新を配信するためのパイプとして一般的に使用されているが、いくつかの問題が頻繁に生じる。このような問題のうちの２つとして、（１）更新配信インフラストラクチャ／リソースに関係する効率と、（２）ソフトウェア更新の配信およびインストールに対する管理制御がある。

配信リソースの効率に関しては、インターネットを含めてネットワークは、帯域幅としばしば呼ばれる通信リソースを、限りある量しか保有しない。限りある量の通信帯域幅は頻繁にボトルネックを生じ、特に、Ｍｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎのＷｉｎｄｏｗｓ（登録商標）ファミリのオペレーティングシステムおよび関連する生産性製品など、一般的なソフトウェア製品のソフトウェア更新に関してはそうである。このようなボトルネックは、インターネット全体に分散した複数のダウンロード位置でソフトウェア更新を入手可能にするときにも存在する。このようなボトルネックが生じる理由の１つは、インターネットによって利用可能になる体系化されていないアクセスモデルである。例えば、コンピュータＡにおける第１ユーザがソフトウェア製品の最新ダウンロードを要求した場合、このダウンロードは、第１ユーザのＩＳＰ（ｉｎｄｅｐｅｎｄｅｎｔ ｓｅｒｖｉｃｅ ｐｒｏｖｉｄｅｒ）を経由する。さらに、要求は単一の個別化されたアクセスとして扱われ、このことは、要求が他のどんなネットワークトラフィックおよび／または要求からも独立し無関係であるものとして扱われることを意味する。したがって、やはり同じＩＳＰをたまたま有するコンピュータＢにおける第２ユーザが、第１ユーザと同じダウンロードを要求した場合、第２ユーザからの要求も単一の個別化されたアクセスとして扱われる。この例では、各要求が別々に扱われたため、同じダウンロードが同じインフラストラクチャを介して２度にわたって送信されることになる。明らかに、ユーザの数が著しく増加した場合、限りある通信帯域幅はボトルネックになる。この例は非常によくみられるが、この場合に、ダウンロードをローカル位置でキャッシュすることができて、各ユーザ要求をローカルキャッシュから満たすことができていれば、はるかに効率的であっただろう。

配信の制御に関しては、多くの組織、特に大規模な組織は、そのコンピュータへの更新配信を制御することに対する正当な理由を有する。例えば、残念ながら更新の中には、ソフトウェア製品の機能を「破壊」する欠陥を有するかまたは招くものがあり、これらの欠陥はしばしばバグと呼ばれる。これらの破壊された機能は、重要でない場合もあるが、ビジネスのミッションクリティカル（ｍｉｓｓｉｏｎ ｃｒｉｔｉｃａｌ）な機能を混乱させる可能性が非常に多い。ビジネスはそのミッションクリティカルな機能を失うわけにはいかないので、責任あるビジネスはまず、制御された環境内でいくらかの期間にわたって各ソフトウェア更新を評価およびテストし、その後、その残りのコンピュータに更新を公開することになる。この評価期間で、組織は、更新がミッションクリティカルな機能に悪影響を及ぼすかどうか妥当性検査することができる。更新がどんなミッションクリティカルな機能も低下させないことが十分に決定された後でのみ、更新を組織の残りのコンピュータに配信することが許可される。明らかに、ほとんどの組織は、そのコンピュータへのソフトウェア更新のインストールに対して制御を実施しなければならない。

ビジネスまたは組織がしばしばソフトウェア更新を制御する必要があることの別の理由は、組織内のコンピュータ間の一貫性を保証することである。ワードプロセッサ用であろうとオペレーティングシステム用であろうと、すべてのコンピュータが動作する基盤となる標準化されたターゲットプラットフォームを有することは、情報サービス部門にとって非常に重要である。標準がなければ、ソフトウェアおよびコンピュータの保守は不要に複雑で困難になるであろう。

ローカル制御が重要であることの別の理由は、課金のためである。大規模な組織では、ソフトウェアを個別にコンピュータにインストールすること、または特定のソフトウェア製品のライセンスを組織内の各コンピュータごとに個別に維持することは、非効率的であることが多い。そうではなく、単一のサイトライセンスが、組織がソフトウェア製品を多くのコンピュータ上で実行することを許可する。したがって組織は、サイトライセンスの下で製品を実行するコンピュータの数を報告する必要があるか、あるいはサイトライセンスの下で製品を実行するコンピュータの数を制限する必要がある場合がある。これらの理由はすべて、ソフトウェア更新配信に対するローカル制御をしばしば必要とする。

上に識別した、ソフトウェア更新配信に関する様々な問題に鑑みて、ソフトウェア更新の配信に対する制御を提供するため、およびソフトウェア更新の配信効率を高めるための、拡張可能なソフトウェア更新配信アーキテクチャが必要とされている。本発明は、従来技術にみられるこれらおよびその他の問題に対処するものである。

本発明の態様によれば、更新メタデータを更新サービスノードから子更新サービスノードまたはクライアントコンピュータに通信するための、タグベースの構造が提示される。タグベースの構造は、ソフトウェア更新を一意に識別するソフトウェア更新識別子を含む識別子タグと、ソフトウェア更新に関係する一般プロパティ情報を伝える０個またはそれ以上の一般プロパティタグと、言語に従って構成されたローカライズプロパティ情報を伝える０個またはそれ以上のローカライズプロパティタグと、更新メタデータ中に記述された現ソフトウェア更新が他のソフトウェア更新に対して有する依存関係を識別する０個またはそれ以上の関係タグと、クライアントコンピュータに対するソフトウェア更新の適用性を決定するための情報を伝える０個またはそれ以上の適用性規則タグと、ソフトウェア更新のペイロードファイルに関係する情報を伝える０個またはそれ以上のファイルタグと、ソフトウェア更新をインストールするためのソフトウェアハンドラに向けた情報を伝えるハンドラ特有データタグとを備える。

本発明の追加の態様によれば、更新メタデータを更新サービスノードから子更新サービスノードまたはクライアントコンピュータに通信するための、タグベースの構造が提示される。タグベースの構造は、ソフトウェア更新を一意に識別するソフトウェア更新識別子を含む識別子タグと、更新メタデータ中に記述された現ソフトウェア更新が他のソフトウェア更新に対して有する依存関係を識別する０個またはそれ以上の関係タグと、ソフトウェア更新のペイロードファイルに関係する情報を伝える０個またはそれ以上のファイルタグとを備える。

本発明に関する前述の態様および付随する多くの利益は、以下の詳細な説明を添付の図面と共に参照することによってよりよく理解されるようになるので、より容易に認識されるようになるであろう。

本発明の態様によれば、階層方式で構成された、ソフトウェア更新を配信するための更新配信システムが提示される。図１は、本発明の態様により形成された例示的な更新配信システム１００を示す図である。本発明によれば、図示の更新配信システム１００などの更新配信システムの「最上部」には、ルート更新サービスノード１０２がある。ソフトウェアプロバイダ１１０などのソフトウェアプロバイダが、ルート更新サービスノード１０２に更新をサブミットすることによって、更新配信システム１００を介してそのソフトウェア更新を配信する。本発明の態様によれば、ソフトウェアプロバイダ１１０などのソフトウェアプロバイダは、インターネット１０８などのネットワークを介して、そのソフトウェア更新をルート更新サービスノード１０２にサブミットすることができる。

この例示的な更新配信システム１００などの階層型更新配信システムは、ルート更新サービスノード１０２に加えて、少なくとも１つの他の更新サービスノードをおそらく含むことになる。図１に示すように、例示的な更新配信システム１００は、ルート更新サービスノード１０２と２つの追加の更新サービスノード、すなわち更新サービスノード１０４および更新サービスノード１０６を含む。本発明によれば、各階層型更新配信システムは、ルート更新サービスノード１０２の下でツリー状の構造に構成される。言い換えれば、更新配信システム中の各更新サービスノードは、０個またはそれ以上の子更新サービスノードを有する。したがって、例示的な更新配信システム１００では、各親更新サービスノードすなわちルート更新サービスノード１０２および更新サービスノード１０４が１つの子しか有さないように示されているが、これは例示のためにすぎず、本発明を限定するものと解釈すべきではない。さらに、ルート更新サービスノード１０２を除いて、更新配信システム中の各更新サービスノードは、１つの親更新サービスノードを有する。したがって図１に示すように、更新サービスノード１０４はルート更新サービスノード１０２の子ノードであり、更新サービスノード１０６は更新サービスノード１０４の子ノードである。図からわかるように、ルート更新サービスノード１０２を除いて、各更新サービスノードは、子更新サービスノードと親更新サービスノードの両方になることができる。

例示的な更新配信システム１００に示すように、ルート更新サービスノード１０２は、インターネット１０８を介して更新サービスノード１０４と通信する。ただし、これは例示にすぎず、本発明を限定するものと解釈すべきではないことを理解されたい。更新配信システム中の各更新サービスノードは、何らかの通信ネットワークを介してその親および／または子と通信できればよい。したがって、更新サービスノード１０４は、インターネット１０８を介してその親であるルート更新サービスノード１０２と通信するが、別法として、ローカルエリアネットワーク１２４を介して、更新サービスノード１０６などのその子更新サービスノードと通信することもできる。

図１にはまた、更新サービスノード１０６がローカルエリアネットワーク１２４のサブネットワーク１２６内にあるのも示す。例として、ローカルエリアネットワーク１２４は、組織の一般的な企業ネットワークに対応するものとすることができ、更新サービスノード１０４は、その親であるルート更新サービスノード１０２への接続を介した、企業から更新配信システム１００へのリンクを表す。さらに、サブネットワーク１２６は、テスト／評価グループや、リモートに位置するオフィスや、ミッションクリティカルなグループなど、企業ネットワーク内のコンピュータの識別可能グループに対応するものとすることができる。後でより詳細に述べるが、本発明の態様によれば、更新サービスノード１０４上の管理者は、更新を更新サービスノード１０６に、最終的にはクライアントコンピュータに配信するのを制御することができる。

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

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

評価グループに関して管理者は、更新サービスノード１０６をメンバとして含め、更新が入手可能になればすぐに評価グループのメンバに更新が配信されるように、このグループに規則を関連付ける。あるいは、全般的企業グループに関して管理者は、クライアントコンピュータ１１４〜１１８を加え、管理者によって特に許可された場合にのみ更新が全般的企業グループのメンバに配信されるように規則を関連付ける。また、子更新サービスノード１０６に対する管理者が、評価サブネットワーク１２６中のクライアントコンピュータ１２０および１２２からなるデフォルトグループを生み出すとも仮定する。新しいソフトウェア更新があれば、すぐにこのグループに配信することができる。

上の例を続けるが、ソフトウェアプロバイダ１１０が、ソフトウェア更新をルート更新サービスノード１０２にサブミットする。ルート更新サービスノード１０２において確立された規則に従って、更新は最終的に企業更新サービスノード１０４に配信される。企業更新サービスノード１０４は、更新を受け取ると、管理者によって確立された規則により、更新を評価グループのメンバ（子更新サービスノード１０６としてのみ定義されている）に配信するが、全般的企業グループに更新を配信する許可が特に下りるまでは、全般的企業グループには更新を提供しないでおく。

上の例を続けるが、評価更新サービスノード１０６は、更新を受け取ると、各定義グループごとに更新を処理する。この例では、評価更新サービスノード１０６は１つのグループだけを有する。ただし前述のように、実際の実装形態では、複数の定義グループがあって、各グループが配信規則に関連した固有のセットに関連していてもよい。この例では、評価更新サービスノード１０６はすぐに、更新をクライアントコンピュータ１２０および１２２への配信に利用可能にする。今やクライアントコンピュータ１２０および１２２を更新することができ、評価期間／プロセスを開始することができる。

上の例を続けるが、企業更新サービスノード１０４上の管理者は、更新が企業ネットワーク１２４全体への配信に適することに十分納得すると、更新が全般的企業グループのメンバに配信されるのを明示的に許可する。企業更新サービスノード１０４は、これに対応して、更新をクライアントコンピュータ１１４〜１１８に入手可能にする。評価更新サービスノード１０６は全般的企業グループにも含まれてよいことを理解されたい。しかし、評価更新サービスノード１０６はすでに更新されているので、更新を評価サブネットワーク１２６に配信するための追加の更新関連動作は必要ない。

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

図２は、本発明の態様により形成された、企業更新サービスノード１０４（図１）や評価更新サービスノード１０６（図１）などの更新サービスノード２００の例示的な論理コンポーネントを示すブロック図である。図２に示すように、更新サービスノード２００は、更新ウェブサービス２０２、クライアント更新モジュール２０４、子更新モジュール２０６、報告モジュール２０８を備える。例示的な更新サービスノード２００はまた、認証／許可モジュール２１０、管理アプリケーションプログラミングインタフェース（ＡＰＩ）２１２、更新内容ストア２１４、管理ユーザインタフェース２１８、更新情報ストア２１６も備える。

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

クライアント更新モジュール２０４は、更新サービスノードに記憶された更新および更新情報に関する、クライアントコンピュータと更新サービスノード２００との間の通信を扱う。限定しないが、これらの更新関連の通信には、クライアント要求に応答して更新を配信すること、入手可能なソフトウェア製品および関連する更新のリストをクライアントコンピュータに提供することが含まれる。クライアント更新モジュール２０４はまた、クライアントコンピュータが特定の更新を入手することが許可されているかどうかを関連の配信規則に従って判定することも担い、クライアントコンピュータによるアクセスが許可されている更新関連の情報でクライアントコンピュータに応答する。

子更新モジュール２０６は、親更新サービスノードとその子更新サービスノードとの間の更新関連の通信を扱う。限定しないが、これらの更新関連の通信には、子更新サービスノードに入手可能なソフトウェア製品および関連する更新のリストを識別すること、ならびに、子更新サービスノードからの更新要求に応答することが含まれる。子更新モジュール２０６は、子更新サービスノードが特定の更新を入手することが許可されているかどうかを関連の配信規則に従って判定することを担い、子更新サービスノードによるアクセスが許可されている更新関連の情報で子更新サービスノードに応答する。

報告モジュール２０８は、どのグループが特定の更新を受け取ったかまたは受け取っていないか、どのクライアントコンピュータが更新をダウンロード／インストールしたかまたはしていないか、どの更新が更新サービスノード上で入手可能かなど、更新関連の報告を生成する。これらの報告は、管理者などによって内部で使用することもでき、また、親の更新サービスインタフェース２０２を介して親更新サービスノードにサブミットすることもできる。前述のように、課金や保守の目的で、特定の更新がどのクライアントコンピュータにインストールされているかを企業が決定する必要がしばしばある。報告モジュール２０８によって生成された情報／報告を、これらの報告の基礎にすることができる。

認証／許可モジュール２１０は、認証を担う。すなわち、特定のクライアントコンピュータまたは子更新サービスノードの識別を決定すること、および、更新サービスノード２００における入手可能な更新へのアクセスがクライアントコンピュータまたは子更新サービスノードに許可されているかどうかを判定することを担う。更新サービスノード上の更新へのアクセスを認証および許可されているクライアントコンピュータおよび子更新サービスノードに対しては、認証／許可モジュール２１０は許可トークンを発行する。許可トークンは、更新の入手に関連して使用しなければならないものである。許可トークンの発行および使用については、後で図４Ａおよび４Ｂに関してより詳細に述べる。

管理ＡＰＩ２１２は、更新サービスノード２００の制御を実施するため、および更新を最終的に記憶し配信するためのアプリケーションインタフェースを表す。更新ウェブサービス２０２がクライアントコンピュータおよび子更新サービスノードから様々な更新関連の要求を受け取ると、最終的にこれらの要求は、直接に、またはクライアント更新モジュール２０４および子更新モジュール２０６を介して間接的に、管理ＡＰＩ２１２への呼び出しに分割される。管理ユーザインタフェース２１８と共に、または更新サービスノード２００にインストールされた他の何らかのプログラムであって管理ＡＰＩ２１２を使用するように適切に構成されたプログラムと共に、管理者は最終的に、この更新サービスノード、ならびに任意の子更新サービスノードおよびクライアントコンピュータのための更新プロセスのすべての面を制御する。

管理ユーザインタフェース２１８を介して、管理者は、更新サービスノード２００を管理ＡＰＩ２１２によって構成および維持することができる。したがって、管理ユーザインタフェース２１８を介して、管理者は、グループを作成、修正、削除し、また各グループに対する規則を関連付ける。さらに管理者は、管理ユーザインタフェース２１８を使用して、クライアントコンピュータまたは子更新サービスノードがどのグループに属するかを確立する。管理者はまた、管理ユーザインタフェース２１８を介して、クライアントコンピュータまたは子更新サービスノードへの更新の配信を明示的に許可すること、新しい更新があるかどうか定期的にその親更新サービスノードに照会するよう更新サービスノード２００を構成すること、報告パラメータを構成し内部報告を見ることなどを行うことができる。前述のように、管理ユーザインタフェース２１８は、管理者が更新サービスノード２００の各面に対する制御を実施できるようにするが、管理ユーザインタフェース２１８の代わりに、更新サービスノード２００上にある、管理ＡＰＩ２１２と共に動作するように適切に適合された別のアプリケーションを使用してもよい。

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

本発明の態様によれば、ソフトウェア更新が物理的に更新内容ストア２１４に記憶されていなくても、更新を更新サービスノード２００上で「入手可能」なものとしてクライアントコンピュータおよび子更新サービスノードに対して提示することができる。より具体的には、実際の更新ファイルをすぐに更新サービスノード２００にダウンロードして記憶するのではなく、親更新サービスノードまたは他のどこかにある更新ファイルを参照するリンクを、代わりに更新サービスノードに記憶することができる。したがって、クライアントコンピュータが更新を要求した場合、または子更新サービスノードが実際の更新を要求した場合に、更新は親更新サービスノードから提供され、クライアントコンピュータまたは子更新サービスノードへの送達に備えて更新内容ストア２１４に記憶される。このタイプの更新アクセスがジャストインタイム（ｊｕｓｔ−ｉｎ−ｔｉｍｅ）ダウンロードと呼ばれることは、当業者なら理解するであろう。このようにすれば、「入手可能」な更新は、それが実際に要求されるまでは、様々なネットワークチャネルを介して配信する必要はない。本発明の態様によれば、更新サービスノード２００の管理者は、ソフトウェア更新をジャストインタイム方式で入手するかどうかを選択的に決定することができる。

上の図２の記述では、例示的な更新サービスノード２００の様々なコンポーネントを例示しているが、更新サービスノードのその他のコンポーネントが存在してもよいことを理解されたい。さらに、前述のコンポーネントは、必ずしも実際のコンポーネントではなく論理コンポーネントとして理解されたい。実際の実装形態では、実装決定に従って、上に識別したコンポーネントを共に組み合わせることもでき、かつ／または他のコンポーネントと組み合わせることもできる。加えて、更新サービスノード２００はネットワーク上のサーバコンピュータと見なすことができるが、実際の実装形態では、更新サービスノードは任意の数のタイプのコンピューティングデバイス上で実現することができることを理解されたい。例えば、各更新サービスノード２００は、単一のスタンドアロンコンピュータシステム上で、あるいは複数のコンピューティングデバイスを含む分散コンピューティングシステム上で実施および／またはインストールすることができる。

図３は、本発明の態様により形成された、図１に示したルート更新サービスノード１０２などのルート更新サービスノード３００の例示的な論理コンポーネントを示すブロック図である。更新サービスノード２００のコンポーネント（図２）と同様、ルート更新サービスノード３００は、更新ウェブサービス２０２、子更新モジュール２０６、認証／許可モジュール２１０を備える。加えて、例示的なルート更新サービスノード３００は、管理ＡＰＩ２１２、更新内容ストア２１４、更新情報ストア２１６も備える。任意選択で、ルート更新サービスノード３００はまた、クライアント更新モジュール２０４、報告モジュール２０８、管理ユーザインタフェース２１８を備えることもできる。

クライアント更新モジュール２０４は、ルート更新サービスノードがソフトウェア更新をクライアントコンピュータに直接提供するかどうかに応じた、ルート更新サービスノード３００のためのオプションのコンポーネントである。例えば図１を参照すると、ルート更新サービスノード１０２は、クライアントコンピュータ１１２に直接にサービスするルート更新サービスノードとして、オプションのクライアント更新モジュール２０４を備えることになる。しかし、ルート更新サービスノード３００がクライアントコンピュータに直接にサービスしない場合は、クライアント更新モジュール２０４は省くことができる。

報告モジュール２０８は、ルート更新サービスノード３００に対してはオプションである。というのは、ルート更新サービスノード３００には、更新報告を提供する対象となる親更新サービスノードがないからである。しかし、ルート更新サービスノードの管理者にとって更新報告が望ましい場合は、任意選択で報告モジュール２０８を含めることができる。

更新サービスノード２００（図２）に含まれる論理コンポーネントを備えることに加えて、ルート更新サービスノード３００は、ソフトウェアプロバイダインタフェース３０２も備える。ソフトウェアプロバイダインタフェース３０２は、ソフトウェアプロバイダ１１０（図１）がソフトウェア更新を直接にルート更新サービスノード３００にサブミットするため、および間接的に例示的な更新配信システム１００にサブミットするための通信インタフェースを提供する。

図２の更新サービスノード２００と同様、上の図３の記述では、例示的なルート更新サービスノード３００の様々なコンポーネントを例示している。しかし、ルート更新サービスノードのその他のコンポーネントが存在してもよいことを理解されたい。さらに、前述のコンポーネントは、必ずしも実際のコンポーネントではなく論理コンポーネントとして理解されたい。実際の実装形態では、実装決定に従って、上に識別したコンポーネントを共に組み合わせることもでき、かつ／または他のコンポーネントと組み合わせることもできる。加えて、更新サービスノード２００はネットワーク上のサーバコンピュータと見なすことができるが、実際の実装形態では、更新サービスノードは任意の数のタイプのコンピューティングデバイス上で実現することができることを理解されたい。例えば、ルート更新サービスノード３００は、単一のスタンドアロンコンピュータシステム上で、あるいは複数のコンピューティングデバイスを含む分散コンピューティングシステム上で実施および／またはインストールすることができる。

更新がどのようにルート更新サービスノードから更新配信システム１００全体に配信されるかをよりよく理解するために、親更新サービスノードと子更新サービスノードとの間の例示的なやりとりは例示するに値する。図４は、本発明の態様による、ソフトウェア更新を親更新サービスノードから子更新サービスノードに伝搬する際の、親更新サービスノード４０２と子更新サービスノード４０４との間の例示的なやりとり４００を示すブロック図である。図からわかるように、例示的な図４００は半分に分かれており、左半分は親更新サービスノード４０２の動作およびイベントに対応し、右半分は子更新サービスノード４０４の動作およびイベントに対応する。

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

例示的なやりとり４００に示すように、イベント４０６で開始し、親更新サービスノード４０２は、ソフトウェアプロバイダ１１０からソフトウェア更新を受け取る。これは、親更新サービスノードがルート更新サービスノード１０２である場合は直接に受け取り、そうでない場合は更新配信システム１００を介して間接的に受け取る。親更新サービスノード４０２がソフトウェアプロバイダ１１０からソフトウェア更新を受け取ってからいくらか後の時点で、子更新サービスノード４０４は、親更新サービスノードからソフトウェア更新を入手するプロセスを開始する。

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

更新プロセスを開始するために、イベント４０８で、子更新サービスノード４０４は、親更新サービスノード４０２から認証および許可を受ける。親更新サービスノード４０２から認証および許可を受けることは、ソフトウェア更新の配信に対する制御の一要素をもたらし、許可された更新サービスノードだけに更新配信を制限する。認証および許可の技術は当技術分野で周知であり、任意の数の技術を使用して、親更新サービスノード４０２によって子更新サービスノード４０４を認証および許可することができる。本発明はいずれか１つの技術に限定されない。

親更新サービスノード４０２による正しい認証および許可の後、イベント４１０で、親更新サービスノード４０２は、許可トークンを子更新サービスノード４０４に返す。一実施形態によれば、許可トークンは、限られた時間量にわたって親更新サービスノードと更新活動をさらに実施する許可を子更新サービスノード４０４に与える、時間に影響されるトークンである。したがって、子更新サービスノード４０４が親更新サービスノード４０２によって正しく認証および許可されない場合は、許可トークンは返されず、子更新サービスノードは、認証および許可を除く他のどんな更新関連の活動も実施することができない。同様に、更新トークンが失効した後は、子更新サービスノード４０４は、再認証および再許可を除くそれ以上のどんな更新関連の活動も親更新サービスノード４０２と実施することができない。

許可トークンを受け取った後、イベント４１２で、子更新サービスノード４０４は、製品更新カタログを求める要求を許可トークンと共に親更新サービスノードにサブミットする。製品更新カタログは、親更新サービスノード４０２がソフトウェア更新を配信するソフトウェア製品のリストまたは目録を表す。

本発明の態様によれば、子更新サービスノード４０４は、その親更新サービスノード４０２上で入手可能なすべてのソフトウェア更新を伝搬する必要はない。例えば、図１の例示的な更新配信システムを参照すると、企業更新サービスノード１０４は、ルート更新サービスノード１０２上で入手可能なソフトウェア製品の一部だけに対するサイトライセンスしか有さない場合がある。このため、企業更新サービスノード１０４は、ルート更新サービスノード１０２で入手可能なソフトウェア更新のほとんどは使用しないので、これらすべてを入手する必要はない。したがって、更新サービスノード上の管理者は、どのソフトウェア製品更新が更新サービスノード上で入手可能かを選択的に確立することができる。

本発明の一態様によれば、親更新サービスノード４０２から入手する更新製品カタログは、子更新サービスノード４０４が各製品の更新を配信するように構成されていてもいなくても、更新が入手可能であるソフトウェア製品すべてを識別する。しかし、本発明の代替の一態様によれば、親更新サービスノード４０２から入手する更新製品カタログは、要求元である子更新サービスノードが更新を配信するように構成されているソフトウェア製品だけを識別する。例えば、どのソフトウェア製品が製品更新カタログにリストされるかを制限することは、子更新サービスノード４０４が属する１つまたは複数のグループに従って決定することができる。

イベント４１４で、親更新サービスノード４０２は、製品更新カタログを子更新サービスノード４０４に返す。イベント４１６で、子更新サービスノード４０４は、最新の更新が現在望まれる製品を製品更新カタログから選択する。製品更新カタログは、子更新サービスノード４０４が配信するソフトウェア製品だけをリストしたものとすることができるものの、子更新サービスノードは、異なるソフトウェア製品を異なる時にまたは異なる定期的スケジュールで入手するように構成できることに留意されたい。

イベント４１８で、子更新サービスノード４０４は、子更新サービスノード４０４が現在更新を求めている選択された製品を識別する更新同期要求を、許可トークンと共にサブミットする。同期要求には、子更新サービスノード４０４上の製品に対して入手可能な最新の更新を識別する情報が含まれる。製品に対する最新の更新を識別する情報を、以下では「更新アンカー」と呼ぶ。各ソフトウェア製品についての更新アンカーは、通常は更新情報ストア２１６（図２）に記憶される。一実施形態では、更新アンカーは、改訂番号と改訂番号に関連する日付とを含む。

更新同期要求に応答して、イベント４２０で、親更新サービスノード４０２は、子更新サービスノード４０４に入手可能な新しい更新があればどれが入手可能かを決定する。前述のようにこの決定は、特定のソフトウェア更新に関連する具体的な規則、子更新サービスノード４０４がメンバである１つまたは複数のグループ、ならびに更新アンカーに基づく。この例では、前述のように、前に受け取ったソフトウェア更新は子更新サービスノード４０４に対して明示的に許可されていない。このため、イベント４０６で受け取ったソフトウェア更新は、子更新サービスノード４０４に「入手可能」であると判定されない。したがって、イベント４２２で、イベント４０６で受け取ったソフトウェア更新を識別せずに更新リストを子更新サービスノード４０４に返す。本発明の態様によれば、更新リストは、同期要求に従って、親更新サービスノード４０２上で「入手可能な」すべての更新を識別する。一実施形態では、更新リストは、「入手可能な」各更新情報を、更新に関連する固有識別子で識別する。

イベント４２４で、更新リストが空なので、すなわち親更新サービスノード４０２上で現在入手可能な更新がないので、子更新サービスノード４０４の更新プロセスは、単に所定時間量にわたって遅延するかスリープ状態になる。この例では、この遅延期間中にイベント４２６で、親更新サービスノード４０２における管理者は、イベント４０６で受け取ったソフトウェア更新が子更新サービスノード４０４に配信されるのを許可する。

イベント４２８（図４Ｂ）で、子更新サービスノード４０４は再び自動更新プロセスを開始して、親更新サービスノード４０２から認証および許可を受ける。これに応答して、イベント４３０で、親更新サービスノード４０２は、許可トークンを子更新サービスノード４０４に返す。

イベント４３２で、子更新サービスノード４０４は、製品更新カタログを求める要求を許可トークンと共に親更新サービスノード４０２にサブミットする。イベント４３４で、親更新サービスノード４０２は、製品更新カタログを子更新サービスノード４０４に返す。イベント４３６で、子更新サービスノード４０４は、更新が望まれる製品を更新カタログから選択する。イベント４３８で、子更新サービスノード４０４は、選択した製品を識別する更新同期要求を、許可トークンと共にサブミットする。

前にイベント４０６で受け取ったソフトウェア更新を入手することが子更新サービスノード４０４に許可されているので、イベント４４０で、親更新サービスノード４０２は、ソフトウェア更新が子更新サービスノードに「入手可能」であると判定し、対応する更新情報を更新リストに含める。したがってイベント４４２で、親更新サービスノード４０２は、イベント４０６で受け取ったソフトウェア更新を今や識別する更新リストを、子更新サービスノード４０４に返す。

親更新サービスノード４０２上の「入手可能」な更新を識別する更新リストによって、子更新サービスノード４０４は今や、ソフトウェア更新を入手するのに必要な情報を有する。本発明の一実施形態によれば、子更新サービスノード４０４は、２つの部分でソフトウェア更新を親更新サービスノード４０２から入手する。すなわち、更新メタデータの入手と、更新内容またはファイル（以下では更新ペイロードと呼ぶ）の入手である。以下でより詳細に説明するように、更新メタデータは、ソフトウェア更新の関連特徴を記述する。限定しないがこれらの特徴には、更新を一意に識別する更新識別子、ソフトウェア更新に関連する改訂番号情報、ソフトウェア更新を優先事項と見なすべきかどうか、言語特有の情報、他のソフトウェア更新との関係、ダウンロードのための更新ペイロード位置、インストールハンドラルーチンなどが含まれる。

ソフトウェア更新全体を２つの部分で、すなわち更新メタデータと更新ペイロードでダウンロードすることがしばしば有益である理由のいくつかには、更新ペイロードが更新メタデータよりもかなり大きい場合が多いこと、および、更新ペイロードが常にすぐ必要とされるとは限らないこと、すなわち必要とされるとしてもクライアントコンピュータへのインストールのためにすぐ必要とされるとは限らないことがある。したがって、本発明の一実施形態によれば、更新ペイロードは更新メタデータと別に、必要なときだけダウンロードする。当業者はこのダウンロード技法をレイジー（ｌａｚｙ）ダウンロード、あるいはジャストインタイムダウンロードとして理解するであろう。本発明の態様によれば、管理者は、更新ペイロードをジャストインタイム方式で入手するように、または更新メタデータを入手した後すぐに入手するように、更新サービスノードを構成することができる。さらに、代替の一実施形態では、更新メタデータと更新ペイロードの両方を一緒にダウンロードすることもできる。

図４Ｂに示すように、更新リスト中で更新が識別されると、イベント４４４で、子更新サービスノード４０４は、「入手可能」なソフトウェア更新の更新メタデータを、更新リスト中のその固有識別子に従って要求する。親更新サービスノード４０２との他のほとんどの通信やりとりと同様、更新要求は許可トークンと共にサブミットする。図示の例ではすべての更新メタデータを１つのアクセスでダウンロードしているが、本発明の代替の態様（図示せず）では、更新メタデータを複数のアクセスでダウンロードすることもできることに留意されたい。例えば、第１のアクセスではまず、適用可能性規則（ａｐｐｌｉｃａｂｉｌｉｔｙ ｒｕｌｅ）や他のソフトウェア更新に対する依存性など、ソフトウェア更新が適用可能かどうかおよび／または望ましいかどうかを判定するのに必要な更新メタデータの要素だけをまずダウンロードする。次いで、更新が適用可能および／または望ましいと判定された後で、残りの更新メタデータを入手することができる。これに応答して、イベント４４６で、親更新サービスノード４０２は、ソフトウェア更新の更新メタデータを子更新サービスノード４０４に返し、子更新サービスノード４０４は、この更新メタデータを更新情報ストア２１６に記憶する。

任意選択で、イベント４４８で、子更新サービスノード４０４は、更新ペイロードを親更新サービスノード４０２からダウンロードする要求をサブミットする。これに応答して、イベント４５０で、親更新サービスノード４０２は、更新ペイロードを子更新サービスノード４０４に返し、子更新サービスノード４０４は、これを更新内容ストア２１４に記憶する。代替の一実施形態では、子更新サービスノード４０４は、更新メタデータ中で指定された、親更新サービスノード４０２ではない場合のある記憶位置から更新ペイロードをダウンロードする。

今や子更新サービスノード４０４上で更新活動が行われたので、イベント４５２で、子更新サービスノードは、たった今行った更新活動を概説する更新報告を生成して、親更新サービスノード４０２にサブミットする。その後、子更新サービスノード４０４は、更新プロセスの実行が次に計画されるまで（図示せず）、再び遅延する。

当業者なら理解するであろうが、前述のイベントは例示のためにすぎず、イベントおよび状況の例示的なセットの特定の１つを反映するものである。明らかだが、具体的な詳細および状況に従ってその他のイベントが行われ、それが前述のイベントの何らかの変形を引き起こす場合もある。加えて、子更新サービスノード４０４が最新の「入手可能」なソフトウェア更新を親更新サービスノード４０２から入手している間、子更新サービスノードは同時にその子更新サービスノードからの更新要求を処理している場合もあることを理解されたい。したがって、上の一連のイベントは例示にすぎず、本発明を限定するものではないと見なすべきである。

図５は、図１の企業更新サービスノード１０４などの子更新サービスノード上で実行される、その親更新サービスノードから定期的に更新を入手するための例示的なルーチン５００を示す流れ図である。ブロック５０２で開始し、子更新サービスノードは、「入手可能」な更新の同期済み更新リストを親更新サービスノードから入手する。「入手可能」な更新の同期済み更新リストを親更新サービスノードから入手することについて、図６に関して以下に述べる。

図６は、図５の例示的なルーチン５００で使用するのに適した、「入手可能」な更新の同期済み更新リストを親更新サービスノードから入手するための例示的なサブルーチン６００の流れ図である。ブロック６０２で開始し、前に図４Ａおよび４Ｂに関して論じたように、子更新サービスノードは親更新サービスノードから認証および許可を受け、正しい認証および許可に応答して、許可トークンを受け取る。ブロック６０４で、子更新サービスノードは、許可トークンと共に、親更新サービスノードとの通信パラメータを確立する。通信パラメータを確立することにより、親と子の更新サービスノードは、親と子の両方が理解する共通基盤を正しく確立することができる。限定しないが通信パラメータには、通信更新プロトコルまたはバージョンや、製品分類などが含まれる。

親更新サービスノードとの通信パラメータを確立した後、ブロック６０６で、子更新サービスノードは、親更新サービスノードが更新を提供／配信するソフトウェア製品を記述する製品更新カタログを入手する。ブロック６０８で、子更新サービスノードは、更新が現在求められているソフトウェア製品更新を選択する。ブロック６１０で、子更新サービスノードは、許可トークンと、選択したソフトウェア製品に関連し現在の改訂およびすでに子更新サービスノード上にある更新を識別する「アンカー」との両方を含む、更新同期要求を親更新サービスノードにサブミットする。

更新同期要求に応答して、ブロック６１２で、子更新サービスノードは、子更新サービスノードに現在何が記憶されているかに応じて親更新サービスノード上の「入手可能」なソフトウェア更新に従って同期がとられた更新リストを、親更新サービスノードから入手する。前述のように更新リストは、子更新サービスノードに「入手可能」な親更新サービスノード４０２上のソフトウェア更新を、固有識別子で識別する。その後、例示的なサブルーチン６００は終了する。

再び図５を参照すると、同期済み更新リストを親更新サービスノードから入手した後、判定ブロック５０４で、いずれかのソフトウェア更新が現在、親更新サービスノードからダウンロードするのに「入手可能」かどうかを判定する。この判定は、同期済み更新リスト中にいずれかの更新識別子がリストされているかどうかに従って行う。ダウンロードするのに現在「入手可能」なソフトウェア更新がない場合は、例示的なルーチン５００は遅延ブロック５１０に進み、次の更新期間が発生するまで遅延／スリープ状態になる。あるいは、親更新サービスノードからダウンロードするのに「入手可能」な更新がある場合は、ブロック５０６で、子更新サービスノードは親更新サービスノードから更新を入手する。「入手可能」な更新を親更新サービスノードから入手することについて、図７に関して以下に述べる。

図７は、図５の例示的なルーチン５００で使用するのに適した、「入手可能」な更新を親更新サービスノードから入手するための例示的なサブルーチン７００の流れ図である。ブロック７０２で開始し、更新リスト中の第１の更新識別子を選択する。ブロック７０４で、子更新サービスノードは、選択した更新識別子に対応する更新メタデータを親更新サービスノードから入手し、更新情報ストア２１６に記憶する。

一実施形態によれば、ブロック７０６で、子更新サービスノードは、選択した更新識別子に対応する更新ペイロードを親更新サービスノードから入手して、更新内容ストア２１２に記憶する。任意選択で、更新内容はすぐに子更新サービスノードにダウンロードしなくてもよい。前述のように、子更新サービスノードは選択的に、更新を親更新サービスノードからジャストインタイム方式でダウンロードするように構成することができる。このオプション処理によれば、図７に示すように、例示的なサブルーチン７００はブロック７０４からブロック７０６に進むのではなく、任意選択でブロック７０４から判定ブロック７０８に進む。

選択した更新識別子に対する更新メタデータ、および任意選択で更新ペイロードを入手した後、判定ブロック７０８で、更新リスト中に追加の更新識別子があるかどうかを判定する。追加の更新識別子がある場合は、ブロック７１０で、更新リスト中の次の更新識別子を選択し、サブルーチン７００は追加の処理のためにブロック７０４に戻る。ルーチン７００は、判定ブロック７０８で更新リスト中に更新識別子がこれ以上ないと判定されるまで継続する。更新識別子がこれ以上ないと判定されると、例示的なサブルーチン７００は終了する。

再び図５に戻ると、子更新サービスノードは、「入手可能」な更新を親更新サービスノードから入手した後、ブロック５０８で、更新活動を親更新サービスノードに報告する。その後、遅延ブロック５１０で、例示的なルーチン５００は、次の更新期間まで所定時間量にわたって遅延／スリープ状態になり、次いでブロック５０２に進み、上に識別した更新手順を繰り返す。

図５に示すように、判定ブロック５０４で、親更新サービスノード上に「入手可能」な更新がないときでも、子更新サービスノードは任意選択で、その更新活動を親更新サービスノード報告するように構成することができる。この代替構成によれば、入手可能な更新がないとき、例示的なルーチン５００はブロック５０８に進んで更新活動を報告することができる。

図８は、親更新サービスノード上で実施される、子更新サービスノードからの更新同期要求に応答して「入手可能」な更新を識別する同期済み更新リストを生成するための例示的なルーチン８００の流れ図である。ブロック８０２で開始し、親更新サービスノードは、「入手可能」な更新を識別する更新リストを求める更新同期要求を、子更新サービスノードから受け取る。ブロック８０４で、更新同期要求中で識別される第１のソフトウェア製品を選択する。

判定ブロック８０６で、識別されるソフトウェア製品に対する入手可能な更新があるかどうかを判定する。この判定は、更新情報ストア２１６に記憶されたソフトウェア製品に関するメタデータに従って、また、子更新サービスノードから提供された更新アンカーに従って、また、子更新サービスノードが属するグループに関連する配信規則に従って行う。この判定に従って、「入手可能」な更新がある場合は、ブロック８０８で、「入手可能」な更新に関連する固有の更新識別子を更新リストに書き込む。「入手可能」な更新の固有の更新識別子を更新リストに書き込んだ後、判定ブロック８１０で、更新同期要求中で識別される追加のソフトウェア製品がまだあるかどうかを判定する。更新同期要求中に追加のソフトウェア製品がある場合は、ブロック８１４で、親更新サービスノードは、更新同期要求中で識別される次のソフトウェア製品を選択し、判定ブロック８０６に戻って、選択したソフトウェア製品に対する「入手可能」な更新があるかどうかを判定する。あるいは、更新同期要求中で識別されるソフトウェア製品がそれ以上ない場合は、ブロック８１４で、更新リストを子更新サービスノードに返す。その後、例示的なサブルーチン８００は終了する。

前述のように、更新メタデータは、ソフトウェア更新の関連特徴を記述する。実際、これらの特徴の多くは、更新ペイロード自体と同じくらいソフトウェア更新にとって重要である。例えば、前のソフトウェア更新があらかじめインストールされている必要があるが現時点では管理者決定によりインストールされていないことを、第１のソフトウェア更新の更新メタデータが示す場合は、第１のソフトウェア更新の更新ペイロードをダウンロードする価値はないことになる。したがって、第１のソフトウェア更新の更新ペイロードをダウンロードしないことによって、かなりの通信帯域幅を節約することができる。当然これは、更新メタデータがどのようにしてソフトウェア更新に関係する重要かつ適切な情報を提供するかについての一例にすぎないことは、当業者なら理解するであろう。

更新メタデータは任意のフォーマットのファイルで送信することができるが、本発明の態様によれば、ソフトウェア更新に対応する更新メタデータは、拡張可能マークアップ言語（ＸＭＬ）ファイルなど、タグベースのファイルに記述され収録される。データを記述し収録するカスタマイズ可能なタグを実現するものなら、任意の適したタグベースのファイルフォーマットを使用することができる。ＸＭＬやハイパーテキストマークアップ言語（ＨＴＭＬ）に基づくファイルなど、情報を記述し収録するためのタグベースのファイルは、当技術分野で周知である。当技術分野でさらに知られているように、タグベースのＸＭＬファイルの内容はしばしば、スキーマと呼ばれる定義ファイルに従って決定される。この更新メタデータは、子更新サービスノードとクライアントコンピュータの両方によって使用される。

本発明の実際の一実施形態では、ソフトウェア更新の更新メタデータは、更新メタデータスキーマに準拠するＸＭＬベースのファイルに収録される。図９は、更新メタデータファイルの内容を定義する例示的なＸＭＬベースの更新メタデータスキーマ９００の一部を示すブロック図である。具体的には、例示的な更新メタデータスキーマ９００は、以下の要素を含むＵｐｄａｔｅ９０２を定義する。すなわち、ＵｐｄａｔｅＩｄｅｎｔｉｔｙ要素９０４、Ｐｒｏｐｅｒｔｉｅｓ要素９０６、ＬｏｃａｌｉｚｅｄＰｒｏｐｅｒｔｉｅｓＣｏｌｌｅｃｔｉｏｎ要素９０８、Ｒｅｌａｔｉｏｎｓｈｉｐｓ要素９１０、ＡｐｐｌｉｃａｂｉｌｉｔｙＲｕｌｅｓ要素９１２、Ｆｉｌｅｓ要素９１４、ＨａｎｄｌｅｒＳｐｅｃｉｆｉｃＤａｔａ要素９１６である。要素９０６〜９１６に関しては、タグ修飾子「ｍｉｎＯｃｃｕｒｓ＝”０”」９１８により、適した更新メタデータファイルはこれらの要素を０個またはそれ以上含むことができる。対照的に、更新メタデータファイルはＵｐｄａｔｅＩｄｅｎｔｉｔｙ要素９０４を１つ含まなければならない。図示のメタデータスキーマ９００によれば、更新メタデータファイル中の各更新要素は、もしあれば前述の順序で現れなければならない。

前述のように、各ソフトウェア更新には固有識別子が割り当てられる。本発明の態様によれば、ＵｐｄａｔｅＩｄｅｎｔｉｔｙ要素９０４がこの固有識別子を含み、また、同じくソフトウェア更新に関連する改訂番号など、ソフトウェア更新を識別するための他の情報も含む。

Ｐｒｏｐｅｒｔｉｅｓ要素９０６は、ソフトウェア更新に関係する情報を提供するものであり、限定しないがこの情報には次のものが含まれる。ソフトウェア更新がローカライズされた言語、すなわち英語、スペイン語、フランス語など；インストール中に更新がコンピューティングシステムに及ぼす可能性の高い影響を示唆する情報、例えば最小限の影響や高い影響がコンピューティングシステムのリブートを必要とする場合があるかまたは必要とすることになるなど；システムドライバやソフトウェアアプリケーションなど、ソフトウェア更新によって更新されるソフトウェアのタイプ；ソフトウェアプロバイダに対するソフトウェア更新の重要性に対応する重要度；ソフトウェアプロバイダからの関連セキュリティ公示（ｂｕｌｌｅｔｉｎ）；ソフトウェア更新に対する更新ハンドラを識別するための更新ハンドラ識別などである。上に挙げた様々なタイプのプロパティからわかるように、０個またはそれ以上のＰｒｏｐｅｒｔｉｅｓ要素９０６が更新メタデータファイル中にあってよい。

ＬｏｃａｌｉｚｅｄＰｒｏｐｅｒｔｉｅｓＣｏｌｌｅｃｔｉｏｎ要素９０８は、ソフトウェア更新に関係する言語特有の情報を提供する。限定しないがこの情報としては、更新タイトル、コンピュータユーザに対して表示されるように意図されたソフトウェア更新の記述、ソフトウェアプロバイダからのリリース注記、エンドユーザライセンス同意および関連情報、ソフトウェア更新をアンインストールするためのユーザ指示などがある。本発明の態様によれば、ローカライズ済みプロパティは言語によって分類される。例えば、ＬｏｃａｌｉｚｅｄＰｒｏｐｅｒｔｉｅｓＣｏｌｌｅｃｔｉｏｎ要素９０８は複数の情報を含む場合があるが、上記の情報の英語バージョンが共に分類され、同様にスペイン語バージョンが分類されることになる。上のＰｒｏｐｅｒｔｉｅｓ要素９０６と同様、０個またはそれ以上のＬｏｃａｌｉｚｅｄＰｒｏｐｅｒｔｉｅｓＣｏｌｌｅｃｔｉｏｎ要素９０８が更新メタデータファイル中にあってよい。

Ｒｅｌａｔｉｏｎｓｈｉｐｓ要素９１０は、現ソフトウェア更新が他のソフトウェア更新に対して有する関係についての情報を提供する。限定しないがこれらの関係の例には、あらかじめ必要なソフトウェア更新、取って代わる（ｓｕｐｅｒｃｅｄｅｎｃｅ）ソフトウェア更新、バンドルされるソフトウェア更新が含まれる。あらかじめ必要なソフトウェア更新の関係は、現ソフトウェア更新をインストールする前に、固有の更新識別子で識別される別のソフトウェア更新がクライアントコンピュータシステムにインストールされていなければならないことを示す。複数のあらかじめ必要なソフトウェア更新を論理演算子ＡＮＤやＯＲなどのブール演算子で論理ステートメントに結合することができ、したがってこの論理ステートメントの評価が、ソフトウェア更新がクライアントコンピュータへのインストールに適するかどうかを判定する。

バンドルされるソフトウェア更新は、共にインストールすべき複数のソフトウェア更新を識別する。一例として、バンドルされるアプリケーションは、現ソフトウェア更新と他のソフトウェア更新との相互依存性を示すことができ、したがって、バンドル中で識別される、固有の更新識別子で識別される更新がコンピュータシステムにインストールされるのであれば、それらはすべてインストールされなければならない。上のあらかじめ必要なソフトウェア更新と同様、バンドルされるソフトウェア更新の要素もブール演算子で結合して、バンドルされるソフトウェア更新がクライアントコンピュータへのインストールに適するかどうかを評価するための論理ステートメントを形成することができる。対照的に、取って代わるソフトウェア更新は、現ソフトウェア更新によって取って代わられた他のソフトウェア更新を識別する。上のＰｒｏｐｅｒｔｉｅｓ要素９０６と同様、０個またはそれ以上のＲｅｌａｔｉｏｎｓｈｉｐｓ要素９１０が更新メタデータファイル中にあってよい。

ＡｐｐｌｉｃａｂｉｌｉｔｙＲｕｌｅｓ要素９１２は、ソフトウェア更新がコンピュータシステムへのインストールに適用可能および／または適切かどうかを判定するための規則またはテストを提供する。Ｒｅｌａｔｉｏｎｓｈｉｐｓ要素９１０の関係にいくつかの点で似ているが、ＡｐｐｌｉｃａｂｉｌｉｔｙＲｕｌｅｓ要素９１２は、他のソフトウェア更新に特に関係する場合とそうでない場合のある、コンピューティングシステムに対する条件をテストするものである。上に識別した他のほとんどの要素と同様、０個またはそれ以上のＡｐｐｌｉｃａｂｉｌｉｔｙＲｕｌｅｓ要素９１２が更新メタデータファイル中にあってよい。

Ｆｉｌｅｓ要素９１４は、ソフトウェア更新に関連するファイルすなわち更新ペイロード、ならびにこれらのファイルに関係する情報を識別する。限定しないがこの追加情報には、更新ペイロード中に１つのファイルがあるか多くのファイルがあるか、ファイルを入手できる場所、ファイルのサイズ、ファイル名、ファイル作成日時などが含まれる。単一のソフトウェア更新を複数の方法でクライアントコンピュータにインストールできることは、当業者なら容易に理解するであろう。一例として、同じソフトウェア更新を、既存のファイルの一部をパッチで修正することによってインストールすることもでき、あるいは単に既存のファイルを新しいバージョンで置換することによってインストールすることもできる。したがって本発明の態様によれば、Ｆｉｌｅｓ要素９１４の更新ペイロードは、既存のファイルのためのパッチ、置換ファイル、またはパッチと置換ファイルの両方を含むか参照することができる。０個またはそれ以上のＦｉｌｅｓ要素９１４が更新メタデータファイル中にあってよい。

更新は、差分（ｄｅｌｔａ）パッチ情報で書き換えるべきファイル領域を記述する差分パッチや、実行ファイルや、置換ファイルなど、様々なフォーマットで提供することができる。これらのタイプの更新はそれぞれ、コンピューティングシステム上でソフトウェア更新を実行するための特定の更新ハンドラを必要とする。したがって、ＨａｎｄｌｅｒＳｐｅｃｉｆｉｃＤａｔａ要素９１６が、ハンドラ特有データ／情報を含めるための更新メタデータファイル中の位置を提供する。例えば、限定しないがこの情報には、ハンドラが実行されるべきディレクトリ、ハンドラに対するコマンドライン引数、インストールの何らかの局面が失敗した場合にとる動作、インストールが成功した場合にとる動作などを含めることができる。更新メタデータファイルは、０個またはそれ以上のＨａｎｄｌｅｒＳｐｅｃｉｆｉｃＤａｔａ要素９１６を含むことができる。

好ましい実施形態を含めて、本発明の様々な実施形態および態様を図示および記述したが、本発明の趣旨および範囲を逸脱することなく様々な変更をこれに加えることができることを理解されたい。例えば、通信ネットワークを介した更新配信システムを通してソフトウェア更新を配信するものとして本発明を述べたが、更新メタデータならびに更新ペイロードは、コンパクトディスクやフロッピー（登録商標）ディスクなどのコンピュータ可読媒体上で更新サービスノードからクライアントコンピュータに送達してもよい。

本発明の態様により形成された例示的な更新配信システムの絵図である。 本発明の態様により形成された更新サービスノードの例示的な論理コンポーネントを示すブロック図である。 本発明の態様により形成されたルート更新サービスノードの例示的な論理コンポーネントを示すブロック図である。 本発明の態様による、ソフトウェア更新を親更新サービスノードから子更新サービスノードに提供する際の、親更新サービスノードと子更新サービスノードとの間の例示的なやりとりを示すブロック図である。 本発明の態様による、ソフトウェア更新を親更新サービスノードから子更新サービスノードに提供する際の、親更新サービスノードと子更新サービスノードとの間の例示的なやりとりを示すブロック図である。 子更新サービスノード上で実行される、その親更新サービスノードから定期的に更新を入手するための例示的なルーチンを示す流れ図である。 図５の例示的なルーチンで使用するのに適した、更新カタログを親更新サービスノードから入手するための例示的なサブルーチンの流れ図である。 図５の例示的なルーチンで使用するのに適した、ソフトウェア更新を親更新サービスノードから入手するための例示的なサブルーチンの流れ図である。 子更新サービスノードからの更新要求を処理するための例示的なルーチンの流れ図である。 更新メタデータファイルの内容を定義する例示的なＸＭＬベースの更新メタデータスキーマの一部を示すブロック図である。

符号の説明

１０２ ルート更新サービスノード
１０４ 更新サービスノード
１０６ 更新サービスノード
１０８ インターネット
１１０ ソフトウェアプロバイダ
２０２ 更新ウェブサービス
２０４ クライアント更新モジュール
２０６ 子更新モジュール
２０８ 報告モジュール
２１０ 認証／許可モジュール
２１２ 管理ＡＰＩ
２１４ 更新内容
２１６ 更新情報
２１８ 管理ユーザインタフェース
３０２ ソフトウェアプロバイダインタフェース

Claims (25)

1. ソフトウェア更新に対応する更新メタデータを更新サービスノードまたはクライアントコンピュータに通信するためのタグベースのデータ構造に構成されたコンピュータ可読データを記憶したコンピュータ可読媒体であって、前記データ構造は、
   前記ソフトウェア更新を一意に識別するのに使用されるＵｐｄａｔｅＩｄｅｎｔｉｔｙ要素と、
   前記ソフトウェア更新に関係する一般プロパティを記憶するための０個またはそれ以上のＰｒｏｐｅｒｔｉｅｓ要素と、
   前記ソフトウェア更新に関係するコンピュータユーザに向けた内容を記憶するための０個またはそれ以上のＬｏｃａｌｉｚｅｄＰｒｏｐｅｒｔｉｅｓＣｏｌｌｅｃｔｉｏｎ要素と、
   前記ソフトウェア更新が他のソフトウェア更新に対して有する関係を記憶するための０個またはそれ以上のＲｅｌａｔｉｏｎｓｈｉｐｓ要素と、
   クライアントコンピュータに対する前記ソフトウェア更新の適用性を決定するための規則を記憶するための０個またはそれ以上のＡｐｐｌｉｃａｂｉｌｉｔｙＲｕｌｅｓ要素と、
   前記ソフトウェア更新のペイロードに関係する情報を記述する情報を記憶するための０個またはそれ以上のＦｉｌｅｓ要素と、
   前記ソフトウェア更新の特定のタイプをインストールするための更新ハンドラに関する情報を記憶するための０個またはそれ以上のＨａｎｄｌｅｒＳｐｅｃｉｆｉｃＤａｔａタグと
   を備えることを特徴とするコンピュータ可読媒体。
2. ＸＭＬデータ構造であることを特徴とする請求項１に記載のタグベースのデータ構造。
3. 前記タグベースのデータ構造の前記要素は、もしあれば請求項１記載の順序で前記更新メタデータ中に含まれることを特徴とする請求項１に記載のタグベースのデータ構造。
4. 前記ＵｐｄａｔｅＩｄｅｎｔｉｔｙ要素は、前記ソフトウェア更新を一意に識別する固有識別子サブ要素と、前記ソフトウェア更新に関連する改訂番号を識別する改訂番号サブ要素とを含むことを特徴とする請求項１に記載のタグベースのデータ構造。
5. 前記Ｒｅｌａｔｉｏｎｓｈｉｐｓ要素は、前記ソフトウェア更新をインストールする前にインストールされていなければならない第２のソフトウェア更新を識別する必須サブ要素を含むことを特徴とする請求項１に記載のタグベースのデータ構造。
6. 前記Ｒｅｌａｔｉｏｎｓｈｉｐｓ要素は、ブール演算子で論理ステートメントに結合された複数のソフトウェア更新を識別する複数の必須サブ要素を含み、前記論理ステートメントの評価は、前記ソフトウェア更新がクライアントコンピュータへのインストールに適するかどうかを判定することを特徴とする請求項５に記載のタグベースのデータ構造。
7. 前記Ｒｅｌａｔｉｏｎｓｈｉｐｓ要素は、同一範囲にインストールしなければならない複数のソフトウェア更新を識別するバンドルサブ要素を含むことを特徴とする請求項１に記載のタグベースのデータ構造。
8. 前記バンドルサブ要素中の前記複数のソフトウェア更新はブール演算子で論理ステートメントに結合され、前記論理ステートメントの評価は、前記ソフトウェア更新がクライアントコンピュータへのインストールに適するかどうかを判定することを特徴とする請求項７に記載のタグベースのデータ構造。
9. 前記Ｒｅｌａｔｉｏｎｓｈｉｐｓ要素は、前記ソフトウェア更新によって取って代わられる少なくとも１つの他のソフトウェア更新を識別する取替えサブ要素を含むことを特徴とする請求項１に記載のタグベースのデータ構造。
10. 前記Ｒｅｌａｔｉｏｎｓｈｉｐｓ要素は、前記ソフトウェア更新をインストールする前にインストールされていなければならない他のソフトウェア更新を識別する必須サブ要素と、同一範囲にインストールしなければならない複数のソフトウェア更新を識別するバンドルサブ要素と、前記ソフトウェア更新によって取って代わられる少なくとも１つの他のソフトウェア更新を識別する取替えサブ要素とを、任意の数だけ含むことを特徴とする請求項１に記載のタグベースのデータ構造。
11. 前記Ｆｉｌｅｓ要素は、クライアントコンピュータ上の既存のファイルにパッチを当てるための前記ソフトウェア更新のペイロードを識別する情報を含むことを特徴とする請求項１に記載のタグベースのデータ構造。
12. 前記Ｆｉｌｅｓ要素は、クライアントコンピュータ上の既存のファイルを置換するための前記ソフトウェア更新のペイロードを識別する情報を含むことを特徴とする請求項１に記載のタグベースのデータ構造。
13. 前記Ｆｉｌｅｓ要素は、クライアントコンピュータ上の既存のファイルにパッチを当てるためとクライアントコンピュータ上の既存のファイルを置換するための両方の、前記ソフトウェア更新のペイロードを識別する情報を含むことを特徴とする請求項１２に記載のタグベースのデータ構造。
14. ソフトウェア更新に対応する更新メタデータを更新サービスノードまたはクライアントコンピュータに通信するためのタグベースのデータ構造に構成されたコンピュータ可読データを記憶したコンピュータ可読媒体であって、前記タグベースのデータ構造は、
    前記ソフトウェア更新を一意に識別するのに使用されるＵｐｄａｔｅＩｄｅｎｔｉｔｙ要素と、
    前記ソフトウェア更新が他のソフトウェア更新に対して有する関係を記憶するための０個またはそれ以上のＲｅｌａｔｉｏｎｓｈｉｐｓ要素と、
    前記ソフトウェア更新のペイロードに関係する情報を記述する情報を記憶するための０個またはそれ以上のＦｉｌｅｓ要素と
    を備えることを特徴とするコンピュータ可読媒体。
15. ＸＭＬデータ構造であることを特徴とする請求項１４に記載のタグベースのデータ構造。
16. 前記ＵｐｄａｔｅＩｄｅｎｔｉｔｙ要素は、前記ソフトウェア更新を一意に識別する固有識別子サブ要素と、前記ソフトウェア更新に関連する改訂番号を識別する改訂番号サブ要素とを含むことを特徴とする請求項１４に記載のタグベースのデータ構造。
17. 前記Ｒｅｌａｔｉｏｎｓｈｉｐｓ要素は、前記ソフトウェア更新をインストールする前にインストールされていなければならない第２のソフトウェア更新を識別する必須サブ要素を含むことを特徴とする請求項１６に記載のタグベースのデータ構造。
18. 前記Ｒｅｌａｔｉｏｎｓｈｉｐｓ要素は、ブール演算子で論理ステートメントに結合された複数のソフトウェア更新を識別する複数の必須サブ要素を含み、したがって前記論理ステートメントの評価は、前記ソフトウェア更新がクライアントコンピュータへのインストールに適するかどうかを判定することを特徴とする請求項１７に記載のタグベースのデータ構造。
19. 前記Ｒｅｌａｔｉｏｎｓｈｉｐｓ要素は、同一範囲にインストールしなければならない複数のソフトウェア更新を識別するバンドルサブ要素を含むことを特徴とする請求項１６に記載のタグベースのデータ構造。
20. 前記バンドルサブ要素中の前記複数のソフトウェア更新はブール演算子で論理ステートメントに結合され、前記論理ステートメントの評価は、前記ソフトウェア更新がクライアントコンピュータへのインストールに適するかどうかを判定することを特徴とする請求項１９に記載のタグベースのデータ構造。
21. 前記Ｒｅｌａｔｉｏｎｓｈｉｐｓ要素は、前記ソフトウェア更新によって取って代わられる少なくとも１つの他のソフトウェア更新を識別する取替えサブ要素を含むことを特徴とする請求項１６に記載のタグベースのデータ構造。
22. 前記Ｒｅｌａｔｉｏｎｓｈｉｐｓ要素は、前記ソフトウェア更新をインストールする前にインストールされていなければならない他のソフトウェア更新を識別する必須サブ要素と、同一範囲にインストールしなければならない複数のソフトウェア更新を識別するバンドルサブ要素と、前記ソフトウェア更新によって取って代わられる少なくとも１つの他のソフトウェア更新を識別する取替えサブ要素とを、任意の数だけ含むことを特徴とする請求項１６に記載のタグベースのデータ構造。
23. 前記Ｆｉｌｅｓ要素は、クライアントコンピュータ上の既存のファイルにパッチを当てるための前記ソフトウェア更新のペイロードを識別する情報を含むことを特徴とする請求項１６に記載のタグベースのデータ構造。
24. 前記Ｆｉｌｅｓ要素は、クライアントコンピュータ上の既存のファイルを置換するための前記ソフトウェア更新のペイロードを識別する情報を含むことを特徴とする請求項１６に記載のタグベースのデータ構造。
25. 前記Ｆｉｌｅｓ要素は、クライアントコンピュータ上の既存のファイルにパッチを当てるためとクライアントコンピュータ上の既存のファイルを置換するための両方の、前記ソフトウェア更新のペイロードを識別する情報を含むことを特徴とする請求項２４に記載のタグベースのデータ構造。
    

Images