ネットワーク環境においてインストレーションコンポーネントをアップデートするためのシステムおよび方法
【課題】
アップデートサービスから不要なアップデートデルタパッチをクライアントコンピューティングデバイスで受け取らないようにする。
【解決手段】
クライアントコンピューティングデバイス110は、ソフトウェアアップデート階層のアップデート情報901〜903を調べ、必要なアップデート情報(アップデートデルタパッチ)を取得してファイルのアップデートを行う。
アップデートサービスから不要なアップデートデルタパッチをクライアントコンピューティングデバイスで受け取らないようにする。
【解決手段】
クライアントコンピューティングデバイス110は、ソフトウェアアップデート階層のアップデート情報901〜903を調べ、必要なアップデート情報(アップデートデルタパッチ)を取得してファイルのアップデートを行う。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ソフトウェアおよびコンピュータネットワークに関し、詳細には、本発明は、ソフトウェアアップデートを管理し伝えるためのシステムおよび方法に関する。
【背景技術】
【0002】
ほとんどの市販のソフトウェア製品は、継続的なリビジョンプロセスを受けて機能および/またはファンクションを修復し、またはアップグレードする。ソフトウェア製品またはソフトウェアコンポーネントの各リビジョンは、新しいファイルの追加および/または既存ファイルを新しいバージョンのファイルと置換することを必要とすることもある。ベンダが、ソフトウェア製品の問題を分離しその問題についての解決方法を作成した後に、ベンダは、その解決方法をアップデート中へと修正し、このアップデートを顧客に広く使用可能にしたいと望むはずである。ソフトウェアベンダは、ソフトウェアアップデートをできる限り速やかに、また問題なく顧客に対して配信すべきビジネスインセンティブ(business incentive)を有する。
【0003】
インターネットは、顧客がソフトウェア製品についての最終アップデートを取得するための重要なチャネルを提供する。インターネットの使用の爆発的な増加は、ソフトウェア製品およびアップデートがオンラインでダウンロードするために提供されるという、顧客による一般的な期待を生み出してきている。インターネットを使用してアップデートを配信することを推進することは、それがソフトウェアベンダのコストを低減し、その修正版がダウンロードのために使用可能になるとすぐに顧客が識別された問題についてのその修正版を取得できるようになるので、ソフトウェアベンダのためにもなる。インターネット上のこれらのベンダサイトは、あるアプリケーションについてのアップデートファイルを見出し、その所在を突き止めることを非常に簡単にするように設計することが可能である。ファイルダウンロードの技術的側面は、ユーザの観点からはほとんど見えなくなってしまっており、今では一般にオペレーティングシステムによって処理される。
【0004】
従来のアプローチでは、ソフトウェアベンダは、ソフトウェアアップデートをダウンロードのための「パッケージ」として構築する。このパッケージは、一般にその設定プログラムおよび各製品アップデートファイルが、埋め込まれ、このパッケージをより小さなパッケージにするために圧縮された自己展開(self−extracting、自己解凍)実行可能ファイルである。このパッケージのサイズは、一般に各変更ファイルの圧縮されたサイズとその抽出コードそれ自体のサイズを加えた合計である。実行すると、このパッケージは含まれている各ファイルを一時的なロケーションへと抽出し、次いでその設定プログラムを開始して各ファイルをシステムディレクトリ中の適切なロケーションにインストールする。圧縮形式で発送されたファイルは、ファイルがインストールされるときに伸張される。同じロケーション中の同じ名前の既存ファイルはどれも、この置換ファイルによって単に上書きされるはずである。
【0005】
インターネットがソフトウェアアップデートの広範で速やかな配信を可能にしているにもかかわらず、ネットワーク伝送のその限られた帯域幅が問題を引き起こしてきている。大規模な一般のソフトウェアアプリケーションが、アップデートのダウンロードサイズを不当なほど大きくなるようにしてきている。通常は、製品の様々な問題についての多数の修正が、1つのアップデート中にグループ化されることになる。ベンダが定期的にソフトウェア製品をアップデートする場合、このアップデートパッケージのダウンロードサイズは、ユーザがすでに以前のアップデートからこれらのファイルを有しているという想定の下ではこのベンダがファイルを省略することができないので、増大し続けることになる。アップデートパッケージは、いくつかの全体ファイルを結合するので、たとえこれらのファイルが圧縮されている場合でさえ、非常に大きくなってしまうこともある。時には、最高速のモデム接続上でさえ、このダウンロードの帯域幅効率は低下する。
【0006】
従来のダウンロードプロセスの時間を浪費する側面は、もちろん望ましくない。一部の場合においては、顧客は、これらのファイルのダウンロード中に長距離料金または接続時間料金を支払うこともある。接続時間のどのような短縮も、これらの顧客にとっての直接的な金銭的コストを低下させることになる。ベンダには一般に、ベンダが提供するダウンロードのサイズに関連した何らかの区別できるコストがあり、したがって、サイズを低減することは同様にベンダにとっても直接的な金銭的な利点をもたらす。ダウンロードのサイズを低減することは、その使用可能なネットワーク帯域幅を増大させることになり、ベンダは、既存のネットワークサーバ装置を用いて、より多くの顧客を満足させることができるようになる。
【0007】
大規模なアップデートをダウンロードするためにかかる長い時間は、様々なネットワーク接続問題に対してこのダウンロードプロセスをよりぜい弱にもする。電話回線ノイズ、キャッチホン信号、および意図的ではないコマンドを含めて、インターネットセッションが時期尚早にも切断されてしまう可能性がある理由がいくつかある。一部のインターネットサービスプロバイダは、接続時間制限を強制し、ユーザが単一セッション中でオンラインとなることができる時間長が制限される。ネットワーク接続が遮断される場合にそのユーザが大規模なファイルをダウンロードしている場合には、ユーザは、初めからやり直す必要があり得る。ほとんどの一般のオペレーティングシステムおよびファイル転送プロトコルでは、このファイル転送を再開できるようにはなっておらず、したがって、任意の中間的進捗状況が失われてしまうはずであり、この転送は再開される必要がある。エラーの可能性は非常に多いので、多くのユーザには、オンラインでそのアップデートを取得することがほとんど不可能であることが分かる。アップデートパッケージのサイズがあまりにも大きすぎる場合には、ユーザが、アップデートパッケージを完全にダウンロードすることが決してできないこともある。
【0008】
ソフトウェアアップデートのサイズを低減させ、帯域幅効率を増大させる1つの試みが、デルタパッチ(delta patch)またはバイナリパッチ(binary patch)の使用に関する。デルタパッチが、コンピューティングデバイスによって実行される場合に既存のファイルを修正する専用ソフトウェアコードに対応することが当業者には理解されよう。このデルタパッチが専用ソフトウェアコードを含むので、一意のデルタパッチは、ファイルの一意のバージョンごとに必要とされる。ソフトウェアアップデートに適用するときに、ソフトウェアアップデートサービス(software update service)は、完全なアップデートされたファイルを伝送する代わりに、より小さなサイズのアップデートデルタパッチを伝送することができる。次いでこのアップデートされたデルタパッチを利用してこの既存のファイルを修正してそのアップデートされたファイルにする。
【発明の概要】
【発明が解決しようとする課題】
【0009】
このアップデートデルタパッチは、ファイルをアップデートするために必要とされるデータ量を潜在的に減少させる可能性があるが、デルタパッチング(delta patching)に対する現行のアプローチは、ファイルの多数のバージョンが存在する状況において、適用可能なデルタファイルの選択を管理する際に不十分である。一意のデルタパッチがファイルのバージョンごとに必要とされるので、典型的なソフトウェアアップデートシステムではしばしば、ファイルの一意の各バージョンに対応する、たとえ数千でないとしても数百の一意のデルタパッチを必要とする可能性がある。1つのアプローチでは、デルタパッチングをサポートする一部のアップデートサービスは、すべての可能性のあるデルタパッチをクライアントコンピューティングデバイス(client computing device)に対して伝送する。しかし、このアプローチでは、一般に可能性のあるアップデートデルタパッチの数が増すにつれて、このソフトウェアアップデートを実施するために必要とされるデータ量が増大する。したがって、適用可能な可能性のあるデルタパッチ数は、その完全なアップデートされたファイルと同じサイズへと速やかに増大してしまう可能性がある。別のアプローチでは、ネットワーク化されたアップデートソフトウェアサービスが、クライアントマシンをスキャンしてクライアントマシンごとにどのデルタパッチが適用可能となり得るかを選択する。これによって伝送されるデルタパッチ情報量が減少するが、このアプローチは、そのクライアントマシンをスキャンし適用可能なデルタパッチを選択するための、このソフトウェアアップデートサービス上の追加のロジックを必要とする。この追加のロジックの使用は、このサービスが提供する必要があるそのシステムリソースを増大させる。さらに、このアプローチは一般に、従来のウェブサーバが一般に実現するなどのネットワークキャッシング(network caching)の利用を妨げる。
【0010】
前述の短所に加えて、既存のシステムでは、ハードウェアドライバなど、ある種のタイプのソフトウェアアップデートを配信することができない。当技術分野において知られているように、ハードウェアドライバに適用されるアップデートなど専用化されたソフトウェアアップデートは、ほとんどの専用化されたソフトウェアアップデートが特定のハードウェアを有するクライアントコンピュータ上でしか機能しないことになるので、大規模配信でユーザに提供することが困難である。ほとんどの場合において、例えばクライアントコンピュータが互換性のないハードウェアドライバのアップグレードを取得する場合には、このドライバアップグレードのインストレーションは、致命的なエラーを引き起こすこともあり、あるいはそのコンピュータが動作しないようにさえすることもある。
【0011】
前述のことから簡単に理解されるように、サーバといくつかのクライアントの間でソフトウェアアップデートの改善された通信を有するシステムおよび方法が必要になっている。さらに、専用化されたアップデートを配信する場合に、アップデートサービスが特定のタイプのクライアントをターゲットにすることを可能にする改善されたメカニズムを有するソフトウェアアップデートのシステムおよび方法が必要になっている。
【課題を解決するための手段】
【0012】
コンピューティングデバイス上においてファイルのインストレーションを管理するためのシステムおよび方法が提供される。クライアントコンピューティングデバイスは、このクライアントコンピューティングデバイス上に記憶される1つのバージョンのベースラインインストレーションコンポーネントを識別するインストレーション情報を取得する。このインストレーション情報はまた、このベースラインインストレーションコンポーネントとマージされてアップデートされたインストレーションコンポーネントを生成するインストレーションコンポーネントデルタパッチを含んでいる。このアップデートされたインストレーションコンポーネントを利用してこのクライアントコンピューティングデバイス上に1つまたは複数のファイルをインストールする。このインストレーションが完了すると、このアップデートされたインストレーションコンポーネントは、削除することができる。
【0013】
本発明の一態様によれば、このクライアントコンピューティングデバイス上のファイルのインストレーションを管理するための方法が提供される。この方法によれば、コンピューティングデバイスは、このクライアントコンピューティングデバイス上に1つまたは複数のファイルをインストールするための必要なベースラインインストレーションコンポーネントを識別するインストレーション情報を取得する。このコンピューティングデバイスは、このクライアントコンピューティングデバイス上に記憶されたベースラインインストレーションコンポーネントを選択する。このコンピューティングデバイスは、このインストレーション情報からインストレーションコンポーネントデルタパッチを取得し、このインストレーション情報からのインストレーションコンポーネントデルタパッチと、この選択されたベースラインインストレーションコンポーネントとをマージする。このコンピューティングデバイスは、このマージされたインストレーションコンポーネントを利用してこのクライアントコンピューティングデバイス上に1つまたは複数のファイルをインストールする。
【0014】
本発明のさらなる一態様によれば、このクライアントコンピューティングデバイス上のファイルのインストレーションを管理するための方法が提供される。この方法によれば、コンピューティングデバイスは、このクライアントコンピューティングデバイス上の1つまたは複数のファイルをインストールするための必要なベースラインインストレーションコンポーネントを識別する情報を含むパッケージを取得する。このコンピューティングデバイスは、このクライアントコンピューティングデバイス上に記憶されたベースラインインストレーションコンポーネントを識別し、このパッケージからインストレーションコンポーネントデルタパッチを取得する。このコンピューティングデバイスは、このパッケージからのこのインストレーションコンポーネントデルタパッチとこの識別されたベースラインインストレーションコンポーネントとをマージし、このマージされたインストレーションコンポーネントを利用してこのクライアントコンピューティングデバイス上に1つまたは複数のファイルをインストールする。このコンピューティングデバイスはまた、このクライアントコンピューティングデバイス上に1つまたは複数のファイルをインストールしたとき、このマージされたインストレーションコンポーネントを削除する。
【0015】
本発明のさらなる一態様によれば、このクライアントコンピューティングデバイス上のファイルのインストレーションを管理するための方法が提供される。この方法によれば、このコンピューティングデバイスは、クライアントコンピューティングデバイス上に記憶される1組のベースラインインストレーションコンポーネントから選択する情報を含むパッケージを取得する。このコンピューティングデバイスは、このクライアントコンピューティングデバイス上に記憶されるこの1組のベースラインインストレーションコンポーネントからベースラインインストレーションコンポーネントを選択する。このコンピューティングデバイスは、このパッケージからインストレーションコンポーネントアップデートを取得し、このインストレーションコンポーネントアップデートを用いてこの選択されたインストレーションコンポーネントをアップデートする。さらに、このコンピューティングデバイスは、このマージされたインストレーションコンポーネントを利用してこのクライアントコンピューティングデバイス上に1つまたは複数のファイルをインストールする。
【0016】
本発明の前述の態様およびその多くの付随する利点については、以下の詳細なる説明を添付図面と併せて参照することによってさらに良く理解が進むにつれて、さらに簡単に認識されよう。
【図面の簡単な説明】
【0017】
【図1】本発明による、クライアントコンピュータ、およびアップデートソフトウェアを提供するアップデートサービスを含むソフトウェアアップデートシステムを示すブロック図である。
【図2】本発明による、アップデートサービスを用いたクライアントコンピューティングデバイスの認証を示す、図1のソフトウェアアップデートシステムのブロック図である。
【図3】本発明による、クライアントコンピューティングデバイスとアップデートサービスの間の使用可能なアップデートの同期化を示す、図1のソフトウェアアップデートシステムのブロック図である。
【図4】本発明による、アップデートサービスからクライアントコンピューティングデバイスへのソフトウェアアップデート情報の伝送を示す、図1のソフトウェアアップデートシステムのブロック図である。
【図5】本発明による、クライアントコンピューティングデバイスによるアップデート情報の処理および選択を示す、図1のソフトウェアアップデートシステムのブロック図である。
【図6】本発明による、クライアントコンピューティングデバイスによるデルタパッチのマージング、およびアップデートファイルのインストレーションを示す、図1のソフトウェアアップデートシステムのブロック図である。
【図7】本発明による、クライアントコンピューティングデバイス上におけるインストレーションのために使用可能なソフトウェアアップデートを識別するための、クライアントコンピューティングデバイスおよびアップデートサービスによって実施されるソフトウェアアップデートルーチンを示す流れ図である。
【図8】本発明による、アップデートサービス上に記憶されるアップデートに対する選択的なアクセスを提供するための許可ルーチンのプロトコル図である。
【図9】本発明による、許可ルーチンを示す実施例の1組のソフトウェアアップデートのブロック図である。
【図10】本発明による、選択グループのソフトウェアアップデートをソフトウェアアップデートサービスからクライアントコンピューティングデバイスへと伝えるための同期化ルーチンのプロトコル図である。
【図11】本発明による、個別のクライアントコンピューティングデバイスにとって使用可能なソフトウェアアップデートのリストを表示するためのグラフィックユーザインターフェースの例示のセクションを示すブロック図である。
【図12A】本発明による、要求されたソフトウェアを検索しインストールするためのクライアントコンピューティングデバイス110によって実施されるソフトウェアアップデート処理サブルーチン1200の一部分を示す図である。
【図12B】本発明による、要求されたソフトウェアを検索しインストールするためのクライアントコンピューティングデバイス110によって実施されるソフトウェアアップデート処理サブルーチン1200の一部分を示す図である。
【図13】本発明による、ベースラインインストレーションコンポーネントをアップデートするための、クライアントコンピューティングデバイスによって実施されるサブルーチンを示す流れ図である。
【発明を実施するための形態】
【0018】
一般的に説明すると、本発明は、ソフトウェアアップデートを管理するためのシステムおよび方法を対象としている。より詳細には、本発明は、ソフトウェアアップデートを選択し実施するために必要とされる帯域幅および処理リソースを最小にしながら、ソフトウェアアップデートの選択と実施を実行するためのシステムおよび方法を対象としている。本発明によれば、ソフトウェアアップデートは、特定のソフトウェアアプリケーションまたはオペレーティングシステムについてのアップデートに対応することが可能である。さらに、ソフトウェアアップデートは、ソフトウェアドライバ、またはシステムBIOSなどのファームウェアへのアップデートを含むこともできる。本発明の一態様によれば、これらのソフトウェアアップデートを処理するためのシステムおよびコンポーネントアーキテクチャが提供される。本発明の別の態様によれば、クライアントマシンのアップデートサービスとの許可および同期化を実施するためのアップデートプロトコルおよびインターフェースが提供される。本発明のさらなる態様によれば、インストレーションコンポーネント、およびデルタパッチを利用した様々なインストール済みのファイルをアップデートするための方法が提供される。しかし、本発明の追加の態様を本出願において提供することもできることが当業者には理解されよう。さらに、各識別された態様は、個別に、あるいは共通の発明態様の一部分として考えることができることが、当業者には理解されよう。
【0019】
図1のソフトウェアアップデートシステム100は、本発明によるソフトウェアアップデートシステム100を示すブロック図である。一般的に説明すると、このソフトウェアアップデートシステム100は、1つまたは複数のクライアントコンピューティングデバイス110、アップデートサービス120、および外部アップデートプロバイダ130を含むことができる。一般的に説明すると、このアップデートサービス120は、このクライアントコンピューティングデバイス110に伝えられそこでインストールされるソフトウェアアップデートの配信を記憶し管理する。このソフトウェアアップデートは、このアップデートサービス120によって、あるいは任意の数の外部アップデートプロバイダ130によって提供することができる。
【0020】
このクライアントコンピューティングデバイス110と、このアップデートサービス120と、この外部アップデートプロバイダ130は、ネットワーク101を介して電子的に通信する。このネットワークは、LAN(ローカルエリアネットワーク)、またはWAN(ワイドエリアネットワーク)やインターネットなどのより大規模なネットワークでもよい。一般的に知られているソフトウェアを使用することにより、ソフトウェアアップデートシステム100は、クライアントコンピューティングデバイス110とこのアップデートサービス120のサーバ121、122、123および124との間でドキュメント、コマンド、および他の知られているタイプの情報を交換するように構成することができる。当業者には理解されるように、図1に示すソフトウェアアップデートシステム100は、本発明を実施するための1つの適切なシステムの簡略化された実施例であり、本発明は、この実施例だけには限定されない。
【0021】
以下にさらに詳細に説明するように、一実施形態のアップデートサービス120は、いくつかのサーバを備えている。図1に示すように、このアップデートサービス120は、このアップデートサービス120のこれら全部のプロセスを管理し、このアップデートサービス120のサーバ121、122、123および124のプロセスを調整するためのアップデートサーバ121を含んでいる。許可サーバ122は、クライアントが要求するときに許可クッキーを生成し、次にこの許可クッキーを使用してサーバクッキーを生成し、このサーバクッキーは、クライアントコンピュータがこのアップデートサービス120によって生成されるアップデートにアクセスすることができるようにする。メタデータサーバ123は、アップデートサービス120が提供するこれらのアップデートに関する一般的な情報を提供する。このメタデータサーバ123は、本発明のシステムが特定のタイプのクライアントコンピュータまたは特定のグループのクライアントコンピュータについての特定のアップデートを識別することができるようにする。ダウンロードサーバ124は、アップデートサービス120が提供するソフトウェアアップデートに関連するデータファイルを配信するための1つまたは複数のソフトウェアコンポーネントを提供する。
【0022】
外部アップデートプロバイダ130は、ソフトウェアアップデートを配信する1つまたは複数のサーバを含むことができる。外部アップデートプロバイダ130は、ソフトウェア、ソフトウェアアップデート、またはクライアントコンピュータのグループに対して配信すべき他のデータを提供するエンティティに関連づけることができる。例えば、外部アップデートプロバイダ130は、このアップデートサービス120を使用して1つまたは複数のソフトウェアアプリケーションについてのアップデートを配信したいと希望するサードパーティソフトウェア開発業者に関連づけることができる。別の実施例では、外部アップデートプロバイダ130は、ソフトウェアアップデートシステム120に関連づけることもできる。
【0023】
クライアントコンピューティングデバイス110は、ソフトウェアアプリケーション114を記憶し実行するどのようなコンピューティングデバイスとすることもできる。このクライアントコンピューティングデバイス110は、それだけには限定されないが、PC(パーソナルコンピュータ)、PDA(携帯型個人情報端末)、移動電話、2方向ページャなどを含めていくつかの異なるコンピュータ製品のうちのどの1つからでも形成することができる。当業者または他の人々に理解されるように、このクライアントコンピューティングデバイス110のアーキテクチャは適切な任意の形態を取ることができる。例えば、クライアントコンピューティングデバイス110は、ネットワーク101との通信を提供するためのネットワークインターフェースを含むことができる。このネットワークインターフェースは、有線または無線の任意のネットワーク接続と共に使用するように構成することができ、TCP/IPプロトコルなど適切な任意の通信プロトコルを用いて使用することができる。さらに、クライアントコンピューティングデバイス110は、処理ユニット、ディスプレイ、およびメモリユニットを含むことができる。このメモリユニットは、オペレーティングシステム116などのクライアントコンピューティングデバイス110を動作させるために必要なプログラムコードを記憶することができる。さらに、このメモリユニットは、本発明のプロセスを制御し実行するためのアップデート管理コンポーネント112を記憶する。
【0024】
このソフトウェアアップデートシステム100は、実行される場合に、本発明を実施するソフトウェアプログラムを記憶する。実行される場合に、このソフトウェアアップデートシステム100は、ソフトウェアアップデートを記憶し管理し選択的に伝える。以下でさらに十分に説明するように、多くの他の利点のうちでもとりわけ、本発明は、ソフトウェアアップデートを受信する資格を有するターゲットグループのクライアントコンピューティングデバイスを定義し選択するメカニズムを提供している。本発明は、ソフトウェアアップデートに関連するデータファイルをダウンロードするための改善されたメカニズムも提供している。
【0025】
本発明を例示する目的のために、本発明の動作する実施例の詳細な説明が提供される。この動作する実施例を説明するに際して、ソフトウェアアプリケーションの特定のアップグレード、例えばメディアプレーヤバージョン6.0からメディアプレーヤバージョン7.0のアップグレードを言及することができるソフトウェアアップデートに対して言及を行う。当業者には理解されるように、かかるソフトウェアアップデートは、このソフトウェアアップデートに関連するいくつかのデータファイルの通信およびインストレーションを含むことができる。したがって、本発明を例示する目的では、ソフトウェアアップデートとソフトウェアアップデートを含む個別のデータファイルとの間で区別が行われる。
【0026】
次に図2〜6を参照して、クライアントコンピューティングデバイス110上で1つまたは複数のファイルをアップデートするためのソフトウェアアップデートシステム100のコンポーネント間の例示の相互作用について説明する。図2を参照すると、ソフトウェアアップデートサービスは、1つまたは複数の外部アップデートプロバイダ130によるソフトウェアアップデート情報の伝送によって起動される。前述のように、外部アップデートプロバイダ130は、ソフトウェアアップデートシステム100に関連づけることができる。代わりに、ソフトウェアアップデート情報は、サードパーティの外部アップデートプロバイダ130が伝送することもできる。本発明の例示の一実施形態においては、このソフトウェアアップデート情報は、ファイルをアップデートするために利用されるソフトウェアコード、ファイルを置換するために利用されるソフトウェアコード、このソフトウェアアップデートの適用性を決定するための様々な規則、および/またはこのソフトウェアアップデートを記述するディスプレイ情報を含むことが可能である。このソフトウェアアップデート情報の送信は、いつでも終了することができ、他の例示したソフトウェアアップデートコンポーネントの相互作用の開始と同時である必要はない。
【0027】
外部アップデートプロバイダ130からのソフトウェアアップデート情報を受信すると、このアップデートサービス120は、1つまたは複数のデータを生成して、アップデート情報の伝送を実施する。このデータは、ファイルの異なるバージョンをアップデートするための1組のソフトウェアデルタパッチに対応するパッチストレージファイル(patch storage file)を含むことができる。このデータはまた、このパッチストレージファイル中で見出される対応するデルタ(delta)に対して特定のファイルバージョンをマッピングするインデックスに対応するパッチストレージマニフェスト(patch storage manifest)を含むこともできる。このデータは、以下にさらに非常に詳細に説明するように、このアップデートエージェント(update agent)が特定のソフトウェアアップデートデータを要求しインストールするために利用することになる情報に対応する自己展開ファイルをさらに含むことができる。パッチストレージファイル、パッチストレージマニフェスト、および自己展開ファイルの生成は、いつでも終了することができ他の例示したコンポーネントの相互作用と同時である必要がないことが当業者には理解されよう。
【0028】
ソフトウェアアップデート情報のクライアントに対する伝送を起動するために、クライアントコンピューティングデバイス110は、このアップデートサービス120に対して認証要求を起動する。本発明の例示の一実施形態においては、この認証要求は、クライアントコンピューティングデバイス110とアップデートサービス120の間のアップデートプロトコル相互作用に対応し、これについては、以下でさらに非常に詳細に説明することにする。この認証が完了すると、アップデートサービス120は、認証クッキーをクライアントコンピューティングデバイス120に送信する。次に図3を参照すると、この認証済みのクライアントコンピューティングデバイス120は、次いでこの使用可能なアップデートのアップデートサーバ120との同期化を起動する。本発明の例示の一実施形態においては、この同期化要求は、クライアントコンピューティングデバイス110とアップデートサービス120との間のアップデートプロトコル相互作用にも対応し、これについては、以下でさらに非常に詳細に説明することにする。この同期化が完了すると、クライアントコンピューティングデバイス110は、すべての適用可能なソフトウェアアップデートの情報、およびこのアップデートを記述する情報を受信する。しかし、本発明の例示の一実施形態においては、このアップデートをインスタンス化するソフトウェアコードは、ダウンロードされていない。
【0029】
続けて図3を参照すると、このアップデートプロセス中のある時点で、インストールすべきアップデートの選択が受信される。本発明の例示の一実施形態においては、ユーザが、同期化中に受信するソフトウェアアップデート情報を提示され、適切なアップデートを選択するように求められることもある。代わりに、クライアントコンピューティングデバイス110が、すべての適用可能なソフトウェアアップデートを自動的に選択するように構成することもできる。さらに、クライアントコンピューティングデバイス110が、使用可能なソフトウェアアップデートのサブセットを自動的に選択することができるようにする何らかの規則を有することもある。さらにまた、ユーザが、インターネットのウェブページを介するなどアップデートサービス120と通信することによってアップデートの選択を開始することもできる。
【0030】
次に図4を参照すると、アップデートエージェントがまだ存在していない場合、アップデート管理コンポーネント112は、クライアントコンピューティングデバイス110上でアップデートエージェント118をインスタンス化する。次いでアップデートエージェント118は、自己展開ファイルなどのソフトウェアアップデート情報パッケージの伝送を要求する。このアップデートエージェント118は、この自己展開ファイルを受信し、以下で説明するようにそのインストーラに対して任意のアップデートを実施する。さらに、アップデートエージェント118は、アップデートサービス120から任意の欠損した、または破損した情報を要求することができる。
【0031】
次に図5を参照すると、アップデートエージェント118が、そのソフトウェアアップデート情報パッケージを受信した後に、アップデートエージェント118は、クライアントコンピューティングデバイス110上でインストールされるファイルのインベントリを実施する。このインベントリとそのソフトウェアアップデート情報パッケージの比較に基づいて、アップデートエージェント118は、どのデルタパッチまたは他のアップデート情報が、この選択されたアップデートを完了するために必要になるかを決定する。次いでアップデートエージェント118は、特定のデルタアップデートを求める要求を伝送する。本発明の一実施形態においては、ソフトウェアアップデートを求める要求は、直接ネットワーク接続を介して伝送される直接要求に対応することもあり、これは手動アップデートと呼ばれることになる。本発明の別の実施形態においては、ソフトウェアアップデートを求める要求は、顕在的なユーザアクションを必要とせずに伝送されるバックグラウンド要求である場合もある。この実施形態は、自動アップデートと呼ばれることになる。
【0032】
本発明の例示の一実施形態においては、このソフトウェアアップデートが、デルタパッチに対応する場合、アップデートエージェント118は、そのパッチストレージマニフェストによって識別される特定のデルタパッチを識別する要求をアップデートサービス120に対して伝送する。代わりに、デルタパッチが使用可能でない場合、またはいくつかのデルタパッチが失敗している場合に、アップデートエージェント118は、フォールバックプロシージャ(fallback procedure)を起動することができる。このフォールバックプロシージャは、そのパッチストレージファイルから全体のアップデートファイルの完全コピーの伝送を求める要求を含むことができる。このフォールバックプロシージャはまた、自己完結型のパッケージから全体がアップデートされたファイルの完全コピーの伝送を求める要求を含むこともできる。
【0033】
本発明の例示の一実施形態においては、アップデートサービス120のダウンロードサーバ124は、アップデートエージェント118からのこのソフトウェアアップデート要求を直接処理することができる。代わりに、この要求は、アップデートサービス120からのこの要求されたアップデートデルタパッチをいずれにしても受信している従来のウェブサーバなど任意の数の追加の外部ダウンロードサーバによって処理することもできる。例えば、ある会社では、内部サーバを利用してクライアントマシンをアップデートすることができる。さらに、この要求は、以前の要求を処理する際にそのアップデートデルタパッチの一部または全部がキャッシュされた外部ダウンロードサーバによって処理することもできる。したがって、この実施形態においては、このダウンロードは、「HTTP」(hyper text transfer protocolハイパーテキスト転送プロトコル)データ要求をサービスすることが可能ないくつかの追加のダウンロードサーバに分散することができる。
【0034】
図6を参照すると、このソフトウェアアップデート情報が受信された後に、アップデートエージェント118は、このデルタパッチをこのインストール済みのファイルとマージしてアップデートされたファイルを生成する。さらに、アップデートエージェント118は、このマージが正常にその適切なファイルをアップデートしたかどうか妥当性検査することができる。前述のように、デルタパッチを妥当性検査することができない場合には、アップデートエージェント118は、そのデルタパッチを再度要求することができ、あるいは、何回かの失敗の後に全体がアップデートされたファイルを要求することができる。アップデートエージェント118が、妥当性検査されたアップデートファイルを取得した後に、このファイルは、クライアントコンピューティングデバイス110上にインストールされる。
【0035】
図7は、本発明による、クライアントコンピューティングデバイス110とソフトウェアアップデートサービス120の間の相互作用を示すソフトウェアアップデート処理ルーチン700の流れ図である。ブロック702において、このソフトウェアアップデートサービス120は、このクライアントコンピュータ110に対してアクセスを許可する。本発明の例示の一実施形態においては、クライアントコンピュータに対するアクセスの許可は、特定のグループのコンピュータに関連するソフトウェアアップデートへのアクセスを可能にするサーバ発行クッキー(server−issued cookie)の生成を含むことが可能である。この許可プロセスのより詳細な説明は、図8に関して説明することにする。
【0036】
ブロック704において、このクライアントコンピュータ110とソフトウェアアップデートサービス120は、アップデート情報を同期化させる。本発明の例示の一実施形態においては、ソフトウェアアップデートサービス120は、このクライアントコンピューティングデバイス110に対して特定のソフトウェアアップデートを記述するメタデータを送信する。このメタデータは、ユーザがインストレーションについての1つまたは複数のアップデートを選択できるようにする使用可能なソフトウェアアップデートを記述する情報を含んでいる。この同期化プロセスのより詳細な説明については、図9および図10に関して以下で説明することにする。ブロック706において、クライアントコンピューティングデバイス110は、ダウンロードする適用可能なアップデートの選択を得る。本発明の例示の一実施形態においては、適用可能なアップデートのこの選択は、ユーザの選択を実施するいくつかの固有のユーザインターフェースの利用に対応する可能性がある。ユーザインターフェースの選択については、図11に関してさらに非常に詳細に説明することにする。
【0037】
ブロック708において、クライアントコンピューティングデバイス110は、適用可能なソフトウェアアップデートのこのユーザ選択を処理し、ソフトウェアアップデートサービス120とインターフェースして特定のアップデート情報を要求する。本発明の例示の一実施形態においては、クライアントコンピューティングデバイス110は、1つまたは複数の適用可能なアップデートデルタパッチを選択し要求する。次いでクライアントコンピューティングデバイス110上のアップデートエージェント118は、この要求されたデータを処理してこの選択されたソフトウェアアップデートを実施することができる。ブロック710において、このルーチン700は終了する。
【0038】
図8を参照して、クライアントコンピューティングデバイス110に対してアクセスを許可するための、ブロック702(図7)に対応するプロトコル図800について次に説明することにする。本発明の例示の一実施形態においては、ソフトウェアアップデートサービス120は、メカニズム(extensible targeting mechanism)を利用してクライアントコンピューティングデバイス110のアップデートおよび他のソフトウェアへのアクセスを制御する。このソフトウェアアップデートサービス120は、特定のソフトウェアアップデートを1つまたは複数のターゲットグループのクライアントコンピューティングデバイス110に関連づけるメカニズムを組み込んでいる。例えば、ソフトウェアアップデートサービス120は、特定のハードウェアデバイスを有する特定のブランドのクライアントコンピューティングデバイス110だけに特定のハードウェアドライバアップデートのアクセスを制限することができる。かかる実施例においては、このソフトウェアアップデートサービス120は、特定のブランド名および特定のハードウェアデバイスを有するクライアントコンピューティングデバイス110のターゲットグループを定義し、この特定のソフトウェアダウンロードの送信をそのターゲットグループだけに制限することができる。
【0039】
本発明の例示の一実施形態においては、拡張ターゲティングメカニズムは、1つまたは複数のターゲットグループに対するクライアントコンピューティングデバイスの会員資格を定義するソフトウェアコンポーネント(「許可プラグイン」)の使用によって実行される。クライアントコンピューティングデバイス110上の許可プラグインの存在は、そのクライアントコンピューティングデバイスがその許可プラグインの特定のターゲットグループに属するかどうかを規定する。例えばあるターゲットグループは、特定のソフトウェアアプリケーションについての有効な「PID」(product identification製品識別)番号を有するすべてのコンピュータを含むことができる。かかる実施例においては、図8に関して以下でより詳細に説明するように、許可プラグイン826をそのクライアント中でインストールしてそのクライアントコンピューティングデバイスのメモリモジュールからPIDを読み取り、この得られたPIDを対応するPIDサーバプラグイン829へと渡すことができる。本明細書中でPIDバリデータ(PID validator)829とも呼ばれるこの対応するPIDプラグインは、1つまたは複数の方法を利用してこの受信されたPIDが有効かどうかを判定する。このクライアントコンピューティングデバイス110上に記憶されているPIDが有効であると判定された後に、このサーバは、このクライアントコンピューティングデバイス110が有効なPIDを有するターゲットグループのメンバであることを示すサーバクッキーを生成する。別の実施例においては、ターゲットグループは、ベータテストコンピュータ(beta test computer)として指定されるクライアントコンピューティングデバイスを含むことができる。
【0040】
本発明の例示の一実施形態においては、ソフトウェアアップデートサービス120の許可サーバ122は、この許可サーバが認識することになるクライアントコンピューティングデバイスの1組のターゲットグループを定義するいくつかのサーバ許可プラグインを含んでいる。各サーバ許可プラグインは、クライアントコンピューティングデバイス110上に記憶された対応するクライアント許可プラグインとデータをやりとりするコンポーネントを含んでいる。同様にして、各クライアントコンピューティングデバイス110は、そのクライアントが属するターゲットグループを識別する1つまたは複数のクライアント許可プラグインを含んでいる。本発明の例示の一実施形態においては、このクライアント許可プラグインは、オペレーティングシステムのインストレーションやアップグレードなど、ソフトウェアアプリケーションのインストレーションまたはアップグレード中に各クライアントコンピューティングデバイス中にインストールすることができる。さらに、このサーバ許可プラグインは、ソフトウェアアップデートへのアクセスを制御したいと希望するアドミニストレータが動的にインストールし、または取り除くことができる。クライアントコンピューティングデバイス110および許可サーバ122上に記憶されたこの許可プラグインは、実際のソフトウェアプラグインとすることも可能であり、あるいはこの許可プラグインは、動的にリンクされたライブラリ中へとハードコード化することも可能である。
【0041】
図8に示すように、この許可サーバ122は、3つの実施例のサーバ許可プラグイン、すなわち(1)すべてのコンピュータを含むターゲットグループ(以下で、「オールコンピュータターゲットグループ(All Computer target group)」)を定義する第1のサーバ許可プラグイン828、(2)有効なPIDを有するコンピュータを含むターゲットグループ(以下で、「PIDターゲットグループ」)を定義する第2のサーバ許可プラグイン829、および(3)ベータテストコンピュータを含むターゲットグループ(以下で、「ベータターゲットグループ」)を定義する第3のサーバ許可プラグイン830を含んでいる。また図8に示すように、クライアントコンピューティングデバイス110は、2つのクライアント許可プラグイン、すなわち(1)クライアントコンピューティングデバイス110が、オールコンピュータターゲットグループのメンバであることを示す第1のクライアント許可プラグイン825、および(2)クライアントコンピューティングデバイス110が、PIDターゲットグループのメンバであることを示す第2のクライアント許可プラグイン826を含んでいる。この実施例においては、クライアントコンピューティングデバイス110は、このクライアントコンピューティングデバイス110がそのベータターゲットグループのメンバであることを示す許可プラグインを含んでいない。当業者には理解されるように、各クライアント許可プラグイン825および826は、クライアントコンピューティングデバイス110上で1つまたは複数のファンクションを実行してこの妥当性検査プロセスを支援するように構成することができる。例えば、この第2のクライアント許可プラグイン826は、クライアントコンピューティングデバイス110のメモリを検査してインストール済みのソフトウェアアプリケーションについてのPIDを検証し、または取得するように構成することができる。
【0042】
図8に示すように、許可サブルーチン702は、クライアントコンピューティングデバイス110が構成要求803を許可サーバ122に伝える場合に開始される。本発明の例示の一実施形態においては、この構成要求803は、この許可サーバ122上に記憶されたその許可プラグインを記述する情報を取得するように構成された任意の適切なソフトウェアコンポーネントから形成される。当業者には理解されるように、構成要求803は、「GetConfig」と呼ばれる、知られている方法を利用することができる。この構成要求803を受信することに応答して、許可サーバ122は、構成応答804を伝え、この構成応答は、許可サーバ122上に記憶されたすべての許可プラグインを識別する情報を含んでいる。一実施形態においては、この構成応答804は、許可サーバ122上に記憶されるすべての許可プラグインを識別し記述するストリングのアレイを含んでいる。本実施例においては、この構成応答804は、第1のサーバ許可プラグイン828、第2のサーバ許可プラグイン829、および第3のサーバ許可プラグイン830を識別する情報を含んでいる。
【0043】
ブロック805において、クライアントコンピューティングデバイス110は、この構成応答804を受信することに応答して1つまたは複数の許可クッキーを生成する。ブロック805のプロセスにおいて、クライアントコンピューティングデバイス110は、マッチングしたクライアントとサーバ許可プラグインの各対ごとに許可クッキーを生成する。したがって、本実施例においては、第1のクライアント許可プラグイン825と第1のサーバ許可プラグイン828が共にオールコンピュータターゲットグループに関連するので、第1のクライアント許可プラグイン825は、このオールコンピュータターゲットグループに関連する第1の許可クッキーを生成する。さらに、第2のクライアント許可プラグイン826と第2のサーバ許可プラグイン829が共にPIDターゲットグループに関連するので、第2のクライアント許可プラグイン826は、このPIDターゲットグループに関連する第2の許可クッキーを生成する。クライアントコンピューティングデバイス110は、それがベータターゲットグループのメンバであることを示す許可プラグインをもたないので、第3の許可クッキーは生成されない。
【0044】
当業者には理解されるように、ブロック805のプロセスの一実施形態は、当技術分野において「GetAuthCookie」と呼ばれる一般に知られているソフトウェアの方法を使用することを含んでいる。この各許可クッキーの生成は、追加の処理を含むことができることも理解されよう。例えば、第2のクライアント許可プラグイン826は、このクライアントのシステムレジストリ(system registry)に記憶された情報を検査してPIDを検索しこのPIDをこの許可クッキー中に含めるように構成することができる。他の実施例においては、ブロック805のプロセスは、他のコンピュータまたはデバイスと通信するためのプロセスを含むことができる。例えば、クライアント許可プラグインは、サウンドカード、スキャナ、ビデオカードなどのデバイスと通信してこのデバイスの型およびモデルを取得することができる。限定のない他の実施例においては、クライアント許可プラグインは、フィンガプリントリーダ(fingerprint reader)などのセキュリティデバイスと通信して、ユーザを記述する情報を取得することができる。
【0045】
一般に、クライアント許可プラグインは、クライアントコンピューティングデバイス110、またはクライアントコンピューティングデバイス110に通信可能に接続された他の任意のコンピューティングデバイスの任意のコンポーネントから構成情報を読み取ることができる。他の実施例においては、クライアント許可プラグインは、1つまたは複数のパブリックまたは専用のAPI(アプリケーションプログラミングインターフェース)を利用してこの対応するサーバプラグインによって妥当性検査されるクライアントからの情報を収集し暗号化するように構成することができる。かかる実施例においては、PIDバリデータプラグイン826は、専用のAPIを使用してこのクライアントのPIDを暗号化して、この暗号化済みのPIDを暗号解読と妥当性検査のためにサーバに渡す。他の実施形態においては、他のクライアント許可プラグインは、フィンガプリントリーダや声紋などの生物測定学の測定を利用して許可クッキーを構築して妥当性検査のためにサーバに渡すことができる。さらに他の実施例においては、クライアント許可プラグインは、ウェブサービスまたは他の任意のサービスを呼び出して許可証明書または他の任意タイプのデータをこの許可サーバ122に伝えることができる。
【0046】
本発明の例示の一実施形態においては、各許可クッキーは、関連するターゲットグループを識別するストリングを含んでいる。例えば、ストリングは、特定の許可クッキーがこのPIDターゲットグループに関連することを示すことができる。各許可クッキーは、クライアントとサーバの間でデータを伝えるためのデータセクションも含んでいる。例えば、このPIDターゲットグループに関連する許可クッキーは、実際のPIDを含むデータセクションを有することができる。当業者には理解されるように、このデータセクションは、バイトアレイなどの任意の形式で記憶される任意のタイプのデータを含むことができる。例えば、クライアントおよびサーバ上のプラグインが、パブリックキー(public key)およびプライベートキー(private key)の通信を必要とする場合には、かかるデータは、1つまたは複数の許可クッキーのデータセクション中で暗号化することができる。
【0047】
クライアントコンピューティングデバイス110が対応するクライアントおよびサーバの許可プラグインの各対ごとに許可クッキーを生成した後に、このクライアントコンピューティングデバイスは、この生成済みの許可クッキーをこの許可サーバ122に対して伝える。図8に示すように、クライアントコンピューティングデバイス110は、クッキー要求806においてこの許可クッキーを伝える。このクッキー要求806は、ブロック805のプロセス中で生成された許可クッキーのアレイを伝えるための適切な任意のフォーマットを含んでいる。この許可方法702のこの一部分の一実施形態は、当技術分野において「GetCookie」と呼ばれる一般的に知られているソフトウェアの方法の使用を含むことができる。
【0048】
一実施形態においては、クッキー要求806は、クライアントコンピューティングデバイス110のメモリに記憶された他の許可サーバクッキーも含んでいる。以下の説明からさらに簡単に理解されるように、クライアントコンピューティングデバイス110のこのメモリは、この許可ルーチン700の以前の実行において作成された以前の許可サーバクッキーを記憶していることもある。クッキー要求806においてこの記憶済みの許可サーバクッキーを提供することにより、このクライアントコンピューティングデバイス110は、許可サブルーチン702の以前の実行で認可されたそのアクセス権を維持することができるようになる。本実施例においては、このクライアント中に許可サーバクッキーが記憶されていないので、このクッキー要求806は、このオールコンピュータターゲットグループに関連する第1の許可クッキーと、このPIDターゲットグループに関連する第2の許可クッキーを含んでいる。
【0049】
次に、ブロック807に示すように、このクッキー要求806を受信することに応答して、許可サーバ122は、サーバクッキーを生成する。一実施形態においては、この受信した許可クッキーごとに適切な許可プラグインに対して呼出しを行って、サーバクッキーデータが生成される。各サーバ許可プラグインによって生成されるサーバクッキーデータは、この受信された許可クッキー中で識別されるターゲットグループごとの識別子を含んでいる。本実施例においては、クッキー要求806が、このオールコンピュータターゲットグループに関連する第1の許可クッキーと、このPIDターゲットグループに関連する第2の許可クッキーとを含んでいるので、許可サーバ122は、これらの各ターゲットグループについての識別子を含むサーバクッキーデータを生成する。許可サーバ122上において、以前のサーバクッキーがそのクッキー要求806において受信されている場合には、このサーバクッキーデータを以前のサーバクッキーのデータと組み合わせて新しいサーバクッキーを生成する。一実施形態においては、この新しいサーバクッキーは、トリプルDES(Triple DES)などのパブリックに利用可能な暗号方法の使用によって暗号化される。
【0050】
本発明の例示の一実施形態においては、このサーバクッキーは、1つまたは複数の関連するターゲットグループを識別する暗号化された情報を含むことが可能である。さらに、このサーバクッキーは、有効期限データ(expiration data)を含むことができ、これは、クリアテキストフォーマットでも暗号化フォーマットでも記憶される。クリアテキストフォーマットで記憶される有効期限データは、このサーバクッキーの有効期限切れについて監視するためにクライアントコンピューティングデバイス110によって使用される。この暗号化フォーマットで記憶される有効期限データは、ソフトウェアアップデートサービス120によって使用されて、このクライアントコンピューティングデバイス110が、特定のターゲットグループに関連するアップデートを受信することが許可されているかどうかを判定する。一実施形態においては、このサーバクッキーの有効期限データは、このサーバクッキーで識別されるすべてのターゲットグループに適用される。代わりに、またはこの全体のサーバクッキーに適用される有効期限の時間に追加して、このサーバクッキーは、それぞれ、個別のターゲットグループに適用できる複数の有効期限データを含むことができる。当業者には理解されるように、各サーバクッキーは、追加のデータを含むことができる。例えば、サーバクッキーは、この許可サブルーチン702の最後の実行のタイムスタンプなどのクライアント状態情報を記憶するように構成することができる。
【0051】
生成された後に、この許可サーバクッキー809は、許可サーバ122からクライアントコンピューティングデバイス110に伝えられる。次に、ブロック811に示すように、このサーバクッキーは、その後にクライアントコンピューティングデバイス110のメモリに記憶される。クライアントコンピューティングデバイス110が、このサーバクッキーの少なくとも1つのコンポーネントが、有効期限切れになったことを判定した場合には、このクライアントコンピューティングデバイスは、この許可方法702を再実行して新しいサーバクッキーを取得することができる。前述のように、この許可方法702の後続の各実行において、クライアントコンピューティングデバイス110は、このクッキー要求806においてその記憶されたサーバクッキーを許可サーバ122に対して伝えることができる。一実施形態においては、サーバが、クライアントにこのサーバ構成が変更されたこと、すなわち新しい許可プラグインが追加されたことを通知しない限り、このクライアントは、要求803を送信する必要がない。
【0052】
本発明の別の態様によれば、このソフトウェアアップデートサービス120は、メタデータサーバ123とクライアントコンピューティングデバイス110の間でアップデート情報を同期化させるための同期化サブルーチンを提供することができる。一意のソフトウェアアップデート階層を使用することによって、この同期化サブルーチンは、特定のクライアントコンピューティングデバイスに適用される特定のアップデートを効率的に識別することが可能である。さらに、この許可サブルーチン702において生成されるこのサーバクッキーの使用によって、この同期化サブルーチンは、特定のターゲットグループに関連するアップデートに対するアクセスを選択的に認可することが可能である。
【0053】
本発明の例示の一実施形態によれば、各ソフトウェアアップデートは3つのコンポーネント、すなわち(1)命令コンポーネント、(2)局所的データコンポーネント、および(3)データコンポーネントを含んでいる。当業者には理解されるように、各アップデートは、1つまたは複数の前述のコンポーネントを有することができる。例えば、アップデートが、命令コンポーネント、局所的データコンポーネント、およびデータストリームコンポーネントを含むこともある。別の実施例においては、アップデートは、クライアントコンピューティングデバイスの1つまたは複数の条件をテストするための1つの命令コンポーネントしか含まないこともある。このソフトウェアアップデートの様々なコンポーネントについて以下でより詳細に説明する。
【0054】
一般的に説明すると、この命令コンポーネントは、2つのサブコンポーネント、すなわち(1)クライアントコンピューティングデバイス110がテストすべき1つまたは複数の条件を定義する適用規則、および(2)個別のアップデートの適切なインストレーションのために必要とされる1つまたは複数のアップデートを識別する1組の前提条件を含んでいる。以下で説明するように、この適用規則は、1台のコンピュータに関連したいくつかの条件を定義することが可能であり、これらの各条件は、任意の論理演算子を使用することによって他の条件に関連づけることが可能である。例えば、この命令コンポーネントは、コンピュータが特定のバージョンのWindows(登録商標)をインストールしているかどうかを判定する適用規則を含むこともできる。また以下で説明するように、この1組の前提条件は、以前にインストールされている必要がある1つまたは複数のアップデートを識別することが可能である。例えば、図9を参照して以下でさらに詳細に説明するように、個別のアップデートは、個別のアップデートの適切なインストレーションのために必要とされる他のアップデートをリストにした前提条件を含むこともある。他の実施例においては、図9にも示すように、この1組の前提条件は、より複雑な前提条件の規則を定義するための論理演算子の使用を含むことも可能である。
【0055】
この命令コンポーネントはまた、特定のアップデートに依存する他のアップデートが存在するかどうかを示す、ブールフラグ(Boolean flag)などのコードも含む。図では、特定のアップデートに依存する他のアップデートが存在しない場合には、アップデートは、LEAFアップデートであると考えられる。あるアップデートがLEAFであるかどうかを示すために使用されるこのブールフラグは、関連したアップデートが追加され、または除去されるときに、メタデータサーバ123によって動的にアップデートされる。
【0056】
各アップデートの局所的データコンポーネントは、このアップデートを記述する一般的な情報を含んでいる。例えば、この局所的データコンポーネントは、このアップデートの特徴および利点を記述する情報を含むことができる。この局所的データコンポーネントはまた、このアップデートのインストレーションプロシージャのテキスト記述を含むこともできる。さらに、この局所的データコンポーネントは、このアップデートに関連した他の任意のデータまたは情報を含むこともできる。例えば、その局所的データは、アップデートが、高優先順位のアップデートであることを示すことができる。別の実施例においては、この局所的データは、アップデートが他のソフトウェアアップデートと共にインストールすることができないことを示すメッセージなど、特定のインストレーションメッセージを提供することができる。この局所的情報は、ユーザに対してその含まれる情報の表示を可能にするフォーマットにすることもできる。
【0057】
各アップデートのデータコンポーネントは、そのアップデートの1つまたは複数のバイナリデータストリーム(binary data stream)を含んでいる。一実施形態において、各アップデートのデータコンポーネントは、実行可能ファイル、ドキュメント、リンクされたライブラリなど、1つまたは複数のデータファイルに関連づけることができる。以下でさらに詳細に説明するように、各アップデートは、データファイルの組合せに関連づけることができ、これらのデータファイルのそれぞれは、クライアントが使用するソフトウェアの実際のアップグレード、インストレーション、または修正を実施する。例えば、アップデートのインストレーションは、選択されたアップデートを完了するために必要とされるすべての情報を含む1つのCABファイルの使用によって実施することができる。代わりに、このアップデートのインストレーションは、クライアントコンピューティングデバイス上に記憶される1つまたは複数のファイルをアップデートするために使用されるいくつかの個別のアップデートの使用によって実施することができる。
【0058】
本発明の例示の一実施形態においては、ソフトウェアアップデートは、このソフトウェアアップデートの制御された配信を可能にする階層の形で構成することが可能である。一般的に説明すると、アップデートのこの階層は、アップデートの間の関係を定義しており、特にどのアップデートが他のアップデートに依存しているかを示している。図示するために、実施例の1組のアップデートが、図9に提供され示されている。図に示すように、サンプルのアップデート900の階層は、ベースの組のアップデート901、第2の組のアップデート902、および第3の組のアップデート903を含んでいる。一般的に、ベースの組のアップデート901中の各アップデートは、他のアップデートのインストレーションを必要とする前提条件を有していない。しかし、第6のアップデート921は、この第1のアップデート911、第2のアップデート912、および第3のアップデート913のインストレーションを必要とする前提条件を含んでいる。第7のアップデート922は、第4のアップデート914のインストレーションを必要とする前提条件を含んでいる。第8のアップデート931は、第6のアップデート921、および第5のアップデート915のインストレーションを必要とする前提条件を含んでいる。したがって、第8のアップデート931はまた、第1のアップデート911、第2のアップデート912、および第3のアップデート913のインストレーションを必要とする。本発明を例示するために、このサンプルの1組のアップデート900のうちのすべてのアップデートが、すべてオールコンピュータターゲットグループおよびPIDターゲットグループに関連していることが想定されている。
【0059】
また図9に示すように、また以下でさらに詳細に説明するように、各アップデートは、このアップデートのインストレーションについての条件を指定する適用規則を含んでいる。例えば、第1のアップデート911は、オペレーティングシステムの英語バージョンのインストレーションを必要とする。第2のアップデート912は、Windows(登録商標)XPバージョンSP1のインストレーションを必要とする。別の実施例においては、第6のアップデート921は、XP PATCH1と呼ばれるソフトウェアパッチのインストレーションを必要とする。したがって、この適用規則が満たされていない場合には、クライアントコンピューティングデバイス110は、このアップデートをインストールしないはずである。
【0060】
図9はまた、特定のアップデートに依存する他のアップデートがあるかどうかを示す命令コンポーネントのセクションを示している。このセクションは、LEAFと呼ばれ、これは、ソフトウェアアップデートが一連の関連したアップデートの最後のアップデートであることを示すブール値(Boolean value)の形式とすることができる。本発明を例示する目的では、他のアップデートが、特定のアップデートを前提条件としてリストアップしない場合には、特定のアップデートは、LEAFアップデートになる。図9に示すように、第7のアップデート922と、第8のアップデート931が、このたった2つのLEAFアップデートである。
【0061】
図10は、本発明に従って形成される同期化サブルーチン704(図7)のプロトコル図を示している。一般的に説明すると、この同期化サブルーチン704は、クライアントコンピューティングデバイス110と、メタデータサーバ123などのサーバとの間である種のアップデートの命令コンポーネントを選択的に交信してクライアントコンピューティングデバイス110に適用することが可能なアップデートを識別する。図10に示すように、アップデートを起動するために、クライアントコンピューティングデバイス110は、まずインストール済みのアップデートを処理し、このクライアントにとって使用可能な1つまたは複数のアップデートを要求する同期化要求1051をメタデータサーバ123に対して伝える。この同期化要求1051を受信することに応答して、このメタデータサーバ123は、いくつかのアップデートをこのクライアントコンピューティングデバイス110に対して戻す。以下の説明からさらに簡単に理解されるように、クライアントコンピューティングデバイス110は、この同期化要求1051の通信に先立って局所的に記憶されたデータを処理する。
【0062】
クライアントコンピューティングデバイス110は、各受信されたアップデートの命令コンポーネントを処理してこの適用規則中で定義されるその条件を満たすことができるかどうかを判定する。個別のアップデート中で定義されるこの条件が満たされる場合、同期化サブルーチン1050を例示する目的では、個別のアップデートが「インストール済み」であり、このインストール済みのアップデートがこのクライアントのアップデートキャッシュの第1のコンポーネントに保存される。他方、個別のアップデート中で定義されるこの条件が満たされない場合には、個別のアップデートは、「失敗した」と考えられ、この失敗したアップデートが、このクライアントのアップデートキャッシュの第2のコンポーネントに保存される。この同期化サブルーチン1050のこの説明において、アップデートがインストールされる場合には、この適用規則のこれらの前提条件およびこの条件が満たされていることを仮定することができる。このサブルーチンを説明するためのアップデートのインストレーションは、このアップデートに関連するこのデータファイルが、クライアントコンピューティングデバイス110において実際にインストールされることを必ずしも意味していない。
【0063】
一実施形態においては、このクライアントのアップデートキャッシュのこれらの2つのコンポーネントを使用してこの受信済みのアップデートを分類する。第1のコンポーネントが、インストール済みの非LEAFアップデートを記憶するために使用され、第2のコンポーネントが、クライアントが受信する他のすべてのアップデート、すなわちインストールされなかったアップデートを記憶するために使用される。このアップデートキャッシュの第2のコンポーネントは、すべてのLEAFアップデートのストレージも含んでいる。以下でさらに詳細に説明するように、このアップデートキャッシュに記憶されるアップデートが、メタデータサーバ123に伝えられこれによって処理されてクライアントコンピューティングデバイス110上でインストレーションのために使用可能な他の関連したアップデートを識別することができる。
【0064】
ここで図10に戻って、アイテム1051、1055、および1060として示されている同期化要求の細部について次に説明することにする。当業者には理解されるように、この同期化要求は、アップデートを要求するいくつかの異なるデバイス、プロセス、アプリケーション、ユーザ起動されたコマンドのうちの1つによって起動することができる。この同期化要求は、アップデートのリストを要求するユーザ、クライアントエージェントが起動する自動アップデート、あるいはメタデータサーバ123またはアップデートサービス120からの情報を要求する他の任意のソフトウェアコンポーネントによって起動することができる。一実施形態においては、この同期化要求は、許可ルーチン702から生成された許可サーバクッキーなどの許可サーバクッキーを含んでいる。このサーバクッキーの使用により、このサーバは、そのクライアントが1つまたは複数のターゲットグループのメンバであるかどうかを判定できるようになる。
【0065】
各同期化要求は、このクライアントのアップデートキャッシュに記憶されたアップデートごとの識別子を含むこともできる。より詳細には、1つまたは複数のアップデートが、アップデートキャッシュに記憶されている場合、この同期化要求は、インストール済みの非LEAFアップデートについての識別子を有する第1のコンポーネントと、LEAFアップデート、失敗したアップデート、インストールされなかった他のアップデートなど、他のすべてのアップデートについての識別子を有する第2のコンポーネントとを含んでいる。このアップデート識別子は、それだけには限定されないが、整数アレイを含めて任意のフォーマットにすることができる。代わりに、このクライアントのアップデートキャッシュにアップデートが記憶されていない場合には、この同期化要求は、アップデート識別子を用いて構成されていない。同期化要求がアップデート識別子を用いて構成されていない場合に、この同期化要求は、このクライアントコンピューティングデバイス110がキャッシュされたアップデートをまったくもたないことを示す指示を提供する。
【0066】
図10に示すように、第1の同期化要求1051が、クライアントコンピューティングデバイス110からメタデータサーバ123へと伝えられる。本実施例においては、これがこの方法の最初の実行であることを考えれば、このクライアントのアップデートキャッシュは、どのようなアップデートも含んでいないことになる。したがって、この第1の同期化要求1051は、キャッシュされたアップデートについての識別子を含んでいない。この同期化要求を受信することに応答して、ブロック1052に示すように、メタデータサーバ123は、この同期化要求が少なくとも1つのアップデート識別子を含むかどうかを判定する。この同期化要求がアップデート識別子を含んでいないと判定された場合、メタデータサーバ123は、クライアントコンピューティングデバイス110に伝えるための第1のレベルのアップデートを選択することによって応答する。前述のように、第1のレベルのアップデートは、他のアップデートを識別する前提条件をもたないどのようなアップデートも含むことができる。
【0067】
代わりに、同期化要求が、少なくとも1つのアップデート識別子を含んでいると判定された場合には、メタデータサーバ123は、このサーバの記憶されたアップデートの前提条件を検査してこのクライアントに配信するための追加のアップデートを選択する。一実施形態においては、メタデータサーバ123は、条件が満たされた前提条件を有するアップデートを選択する。この前提条件の検査において、このサーバは、このクライアント上にインストールされた非LEAFアップデートの識別子を含む同期化要求の第1のコンポーネントのアップデートを使用する。
【0068】
条件が満たされた前提条件を有するアップデートを選択するのに加えて、このサーバはまた、この同期化要求の第2のコンポーネント中で識別されるアップデートを使用してこの選択されたアップデートにフィルタをかける。より詳細には、この同期化要求の第2のコンポーネント中で識別されるインストールされていないアップデート、LEAFアップデート、および失敗したアップデートを使用して1つまたは複数の選択されたアップデートにフィルタをかける。本発明のこの特徴によって、本発明のシステムおよび方法は、メタデータサーバ123上に記憶されるアップデートの複数回の伝送を回避することができるようになる。
【0069】
本実施例に戻ると、この第1の同期化要求1051は、アップデート識別子を含んでいないので、このメタデータサーバ123は、クライアントコンピューティングデバイス110に伝えるためのベースレベルのアップデート901を選択する。図9に示すアップデートのサンプルの組を参照すると、このベースレベルのアップデート901は、911、912、913、914および915と呼ばれるアップデートを含んでいる。
【0070】
ブロック1052の処理において、メタデータサーバ123はまた、この同期化要求1051に含まれる許可サーバクッキーを検査して、クライアントコンピューティングデバイス110に関連するターゲットグループを識別する。メタデータサーバ123はまた、ブロック1052のプロセスで選択されたこのアップデートのターゲットグループも検査する。次いで、ブロック1052のこのプロセスは、この受信済みの許可サーバクッキー中で識別されるターゲットグループに関連していないすべての選択されたアップデートをフィルタで取り除く。本実施例においては、選択されたアップデート911、912、913、914および915のすべてが、PIDターゲットグループおよびオールコンピュータターゲットグループに関連するので、これらの選択されたアップデートのすべてがクライアントコンピューティングデバイス110に対して送信される。
【0071】
次いでメタデータサーバ123は、同期化応答1053中でこの選択されたアップデートをクライアントコンピューティングデバイス110に伝える。一般的に、各同期化応答は、このサーバ120が送信する各アップデートの命令コンポーネントを含んでいる。したがって、本実施例においては、第1の同期化応答1053は、911、912、913、914および915と呼ばれるこれらのアップデートについての命令コンポーネントを含んでいる。一実施形態においては、各同期化応答は、各アップデートの局所的データコンポーネントまたはデータコンポーネントを含んでいない。
【0072】
次に、ブロック1054に示すように、クライアントコンピューティングデバイス110は、各受信済みのアップデートの命令コンポーネントを処理してこの適用規則で定義される条件を満たすことができるかどうかを判定する。再度図9を参照すると、このクライアントコンピューティングデバイス110は、受信されたアップデート911〜915の命令コンポーネントを処理する。本発明を例示するために、クライアントコンピューティングデバイス110のオペレーティングシステムは、Windows(登録商標)バージョンXP SP1の英語のインストレーションであることがこの実施例において想定されている。また、クライアントコンピューティングデバイス110は、DellのPCであり、32ビットのX86プロセッサを作動させていることも想定されている。したがって、このサンプルの1組のアップデートの命令コンポーネントの処理においては、このコンピュータが英語のOSを含んでいるので、クライアントコンピューティングデバイス110は、第1のアップデート911中で定義される条件が満たされるはずであると判定するはずである。このオペレーティングシステムがWindows(登録商標)バージョンXP SP1であるので、この第2のアップデート912中で定義される条件も満たされるはずである。クライアントコンピューティングデバイス110が、X86プロセッサを作動させているのでこの第3のアップデート913中で定義される条件も満たされるはずである。クライアントコンピューティングデバイス110がDellのPCであるので第5のアップデート915中で定義される条件も満たされるはずである。その結果、第1のアップデート911、第2のアップデート912、第3のアップデート913、および第5のアップデート915はすべて、このクライアントのアップデートキャッシュの第1のコンポーネントに保存される。クライアントコンピューティングデバイス110は64ビットのX86プロセッサを作動させていないので第4のアップデート914中で定義される条件は、満たされないはずである。したがって、この第4のアップデート914は、失敗したアップデートであると考えられ、このクライアントのアップデートキャッシュの第2のコンポーネントに保存される。
【0073】
図10に戻ると、ブロック1054の処理において、クライアントコンピューティングデバイス110はまた、後続の同期化要求が必要とされるかどうかを判定する。一実施形態においては、少なくとも1つのこの受信済みのアップデートが、それがLEAFアップデートではないことを示す場合、後続の同期化要求が必要であることが決定される。本実施例においては、受信済みのアップデートのすべてがLEAFアップデートではないので、後続の同期化要求が必要とされることが決定される。したがって、クライアントコンピューティングデバイス110は、後続の同期化要求1055をメタデータサーバ123に伝える。
【0074】
以上で概要を述べたように、同期化要求は、このクライアントのアップデートキャッシュに記憶されるアップデートごとの識別子を含んでいる。したがって、本実施例において、後続の同期化要求855は、第1のアップデート711、第2のアップデート712、第3のアップデート713、および第5のアップデート715が、このクライアント上にインストールされていることを示す第1のデータコンポーネントを含んでいる。さらに、後続の同期化要求855は、第4のアップデート711が、このクライアント上に正常にインストールされていないことを示す第2のデータコンポーネントを含んでいる。
【0075】
後続の同期化要求1055を受信することに応答して、以上で概要を述べたように、メタデータサーバ123は、後続の同期化要求1055が、少なくとも1つのアップデート識別子を含むかどうかを判定する。後続の同期化要求が少なくとも1つのアップデート識別子を含むと判定された場合、メタデータサーバ123はすべての記憶されているアップデートの前提条件を検査してこのクライアントに配信するための追加のアップデートを選択する。
【0076】
再度本実施例を参照すると、ブロック856の処理において、その前提条件が満たされるので、メタデータサーバ123は、第6のアップデート921を選択するはずである。より詳細には、図9に示すように、第1のアップデート711、第2のアップデート912、および第3のアップデート913のインストレーションを必要とするその前提条件が満たされるので、第6のアップデート921が、クライアントコンピューティングデバイス110に伝えるために選択される。第7のアップデート922および第8のアップデート931は、これらの前提条件が満たされないので、このクライアントに伝えるために選択されないはずである。より詳細には、この同期化要求1055は、第7のアップデート922についての前提条件である、第4のアップデート914についての識別子を含んでいない。さらに、同期化要求855は、第8のアップデート931についての前提条件である第6のアップデート921についての識別子を含んでいない。
【0077】
図10に戻ると、同期化サブルーチン1050は、後続の応答1057において選択されたアップデートをメタデータサーバ123からクライアントコンピューティングデバイス110へと伝えることによって継続される。再度本実施例を参照すると、この後続の応答1057は、第6のアップデート721に関連した情報を含むはずであり、これは後続の応答1057においてクライアント110に伝えられる。
【0078】
後続の応答1057を受信すると、クライアントコンピューティングデバイス110は、後続の応答857の命令コンポーネントを処理する。ブロック854のプロセスと同様に、クライアントコンピューティングデバイス110は、各受信されたアップデートの命令コンポーネントを処理して、この適用規則中で定義される条件が満たされるかどうかを判定する。本実施例においては、XP PATCH1がこのクライアントコンピューティングデバイス中でインストールされると想定する場合に、第6のアップデート921は、インストールすべきと考えられ、このアップデートは、クライアントコンピューティングデバイス110のこのアップデートキャッシュに書き込まれる。この第6のアップデート921がLEAFアップデートではないので、クライアントコンピューティングデバイス110は、このクライアントのアップデートキャッシュの第1および第2のコンポーネントに記憶されるすべてのアップデートを含む別の同期化要求1060を送信する。この同期化要求1060も、許可サーバクッキーを含んでいる。
【0079】
本実施例においては、メタデータサーバ123の前述の処理を使用することによって、この同期化要求1060は、ブロック1061において処理され、ここでは、このサーバは、第8のアップデート731を選択する。この同期化要求1060は、第5および第6のアップデート915および921がクライアントコンピューティングデバイス110中にインストールされることを示すので、この第8のアップデート931が選択される。この第8のアップデート931は、この許可サーバクッキー中で識別される同じターゲットグループに関連することを想定すると、第8のアップデート931の命令コンポーネントが、別の応答1062中においてクライアントコンピューティングデバイス110に対して伝えられる。次いで、第8のアップデート931が、ブロック1054および1059のプロセスと同様にしてブロック1063において処理される。この応答1062の受信済みのアップデートがすべて、LEAFアップデートであるので、後続の同期化要求が、メタデータサーバ123に対して返信されない。
【0080】
クライアントコンピューティングデバイス110において、この受信済みのアップデートのすべてがLEAFアップデートであると判定された後に、またはアップデートが応答1062中で受信されない場合には、同期化サブルーチン1050は、クライアントコンピューティングデバイス110からメタデータサーバ123へとドライバ同期化要求1064を伝える。当業者には理解されるように、このドライバ同期化要求1064は、クライアントコンピューティングデバイス110中にインストールされるハードウェアをすべて記述する情報と、このインストール済みのソフトウェアを記述する情報を含むことができる。以前のソフトウェア同期化要求(1051、1055、および1060)と同様に、このドライバ同期化要求1064は、このインストール済みのアップデートをサーバに対して伝えることができる。さらに、このクライアント上に現在キャッシュされているすべてのドライバアップデートが、もしある場合には、このサーバに対して伝えられる。
【0081】
このドライバ同期化要求1064を受信することに応答して、メタデータサーバ123は、このクライアント上にまだキャッシュされていない、クライアントコンピューティングデバイス110に適用されるすべてのドライバアップデートを送信することによって応答する。その前提条件および条件が満たされる場合には、ドライバアップデートは、応答1065においてクライアントコンピューティングデバイス110に対して送信される。このドライバアップデートを伝える応答1065は、各アップデートの命令コンポーネントを伝えることが好ましい。次いでこのドライバアップデートは、このクライアントコンピューティングデバイスのアップデートキャッシュに書き込まれる。
【0082】
このドライバアップデートを含むこの応答1065を受信した後に、この同期化サブルーチン1050は、この受信済みのソフトウェアアップデートおよびハードウェアアップデートのそれぞれの局所的データを求める要求1066を送信する。以上で概要を述べたように、各アップデートの局所的データコンポーネントは、このアップデートを記述する一般的な情報を含んでいる。例えば、この局所的データコンポーネントは、このアップデートの特徴および利点を記述する情報を含むことができる。この局所的データコンポーネントはまた、このアップデートのインストレーションプロシージャのテキスト記述を含むこともできる。さらに、この局所的データコンポーネントは、このアップデートに関連した他の任意のデータまたは情報を含むこともできる。
【0083】
したがって、この受信済みのソフトウェアアップデートおよびハードウェアアップデートのそれぞれのこの局所的データを求める要求1066を受信すると、メタデータサーバ123は、このクライアントのこのアップデートキャッシュに保存されたすべてのこの受信済みのソフトウェアアップデートおよびハードウェアアップデートについてのすべての局所的データを送信することによって応答する。受信した後に、この局所的データをソフトウェアアプリケーションによって処理して、これらのアップデートのうちのどれをインストールする必要があるかを決定することができる。代わりに、この受信済みの局所的データをユーザに対して表示して、このクライアントコンピューティングデバイス110にとって使用可能なすべてのアップデートについてそのユーザに通知することができる。一実施形態においては、この受信済みの局所的データは、ウェブページ上に表示することが可能である。本実施例においては、局所的データは、第6および第8のアップデート921および931についてこのクライアントが受信することができる。局所的データがベースアップデート911、912、913、および915に記憶されている場合には、これらのアップデートについてのこの局所的データも、このクライアントは受信するはずである。
【0084】
図11は、このクライアントにとって使用可能なこれらのアップデートに関連する局所的データの一実施例を表示するウェブページ1100の一実施例を示している。図では、ウェブページ1100は、あるアップデートの第1の詳細な記述1105と、別のアップデートの第2の詳細な記述1106とを含んでいる。また図に示すように、各アップデートは、それぞれこれらのアップデートのユーザ選択を受け取るための選択メカニズム1103および1104に関連している。また図に示すように、ウェブページ1100は、ユーザが、メタデータサーバ123やダウンロードサーバ124などのサーバに対する、アップデートの選択の通信を制御できるようにする制御ボタン1101を用いて構成されている。
【0085】
本発明の一態様において、このクライアントは、いくつかのプロセスを実施してこのウェブページ1100の表示を拡張する。例えば、クライアントコンピューティングデバイス110は、各アップデートのこの局所的データを検査して、特定のアップデートが高優先順位であるかどうかを判定する。かかる特徴は、局所的データ中に、または特定のアップデートの他のコンポーネント中に、この特定のアップデートが高優先順位アップデートまたは緊急アップデートであることを示すテキストを見つけることによって実施することができる。クライアントコンピューティングデバイス110が高優先順位アップデートまたは緊急アップデート検出する場合には、このクライアントは、このページの最上部セクションなど、ウェブページ1100の可視セクションにこの高優先順位アップデートを表示する。さらに、このクライアントは、このアップデートが高優先順位アップデートであることを示す、専用化されたテキストメッセージ1120などの視覚インジケータを生成することができる。
【0086】
クライアントコンピューティングデバイス110はまた、各アップデートの局所的データを検査して、特定のアップデートが、排他的インストレーションを必要とするかどうか、すなわち別のアップデートのインストレーションファイルと同時にはインストールすることができないインストレーションファイルを有するアップデートであるかどうかを判定することができる。かかる特徴は、局所的データ中に、または特定のアップデートの他のコンポーネント中に、この特定のアップデートが排他的インストレーションを必要とすることを示すテキストを見つけることによって実施することができる。クライアントコンピューティングデバイス110が、かかるアップデートを検出する場合には、このクライアントは、排他的インストレーションを必要とするアップデートの記述を有する、図11に示すテキストメッセージ1122などの視覚インジケータを表示する。
【0087】
図7に戻ると、このソフトウェアアップデートルーチン700は、ブロック708で継続され、ここで、クライアントコンピューティングデバイス110は、これらのアップデートの選択を受け取る。以上で指摘したように、制御ボタン1101の動作に応答して、1つまたは複数のアップデートの選択をメタデータサーバ123またはダウンロードサーバ124が取得することが可能である。1つまたは複数のアップデートの選択を受け取った後に、このソフトウェアアップデートルーチン700は、ブロック708で継続され、ここでこの選択されたソフトウェアアップデートが処理される。
【0088】
本発明のさらに他の態様によれば、ソフトウェアアップデートサービス120は、このソフトウェアアップデートサービスとクライアントコンピューティングデバイス110の間で情報を選択し伝送する方法を提供することができる。図12Aおよび12Bは、本発明による、要求されたソフトウェアを検索しインストールするための、クライアントコンピューティングデバイス110によって実施されるソフトウェアアップデート処理サブルーチン1200を示している。前述のように、このソフトウェアアップデート処理サブルーチン1200は、ソフトウェアアップデートの選択が生成され受信された後に実施することができる。図12Aを参照すると、ブロック1202において、アップデート管理コンポーネント111が、アップデートエージェント118をインスタンス化する。本発明の例示の一実施形態において、このアップデートエージェント118は、要求されたソフトウェアアップデートを完了するため、このアップデートエージェントのインストレーションコンポーネントの要求されたバージョンを生成するため、既存のファイルをデルタパッチとマージすることによってアップデートされたファイルを生成するため、および/またはアップデートされたファイルのインストレーションを開始するために、どのようなソフトウェアアップデート情報が必要とされるかを決定するための専用ソフトウェアコンポーネントである。アップデートエージェント118が、すでにインスタンス化されている場合には、ブロック1202は、省略することができる。
【0089】
ブロック1204において、アップデートエージェント118は、アップデートサービス120からソフトウェアアップデート情報を取得する。本発明の例示の一実施形態においては、アップデートサービス120が送信するこのソフトウェアアップデート情報は、このアップデートエージェントが利用することができる様々なデータを含む、自己展開ファイルなどのパッケージの形態である。一態様によれば、このパッケージは、特定のソフトウェアアップデートに対応するすべてのファイルのリストを含むことが可能である。さらに、このパッケージは、アップデートすべき特定のバージョンのファイルをアップデートサービス120上のそのパッチストレージファイルに記憶される対応するソフトウェアアップデートデルタパッチに対してマッピングするパッチストレージマニフェストの少なくとも一部分のコピーを含むことが可能である。このパッケージはまた、このインストレーションを完了するために必要とされるインストレーションコンポーネントのバージョンの識別を含むことが可能な、アップデートすべきファイルごとのインストレーション情報を含むことも可能である。さらにこのパッケージはまた、アップデートエージェント118についてのインストレーションコンポーネントまたはクライアントコンピューティングデバイス110上にすでに記憶されているインストレーションコンポーネントのバージョンをアップデートするためのデルタパッチを含むことが可能である。さらにまた、このパッケージは、このアップデートエージェントにソフトウェアアップデートが正常であったかどうかを判定できるようにする検証情報を含むことが可能である。例えば、この検証情報は、比較するためのアップデートファイルについての基準ハッシュ値を含むことが可能である。このアップデートエージェント118は、パッケージのその内容を検証することもできる。
【0090】
判断ブロック1206において、テストを実施してアップデートエージェント118がアップデートを実施するためにこのインストレーションコンポーネントのバージョンをアップデートする必要があるかどうかを判定する。この自己展開ファイル中のインストレーションコンポーネントの完全なコピーの送信により、ソフトウェアアップデートごとの、アップデートサービス120が送信するデータ量を増大させる可能性があることが当業者には理解されよう。したがって本発明の例示の一実施形態においては、インストレーションコンポーネントのベースラインバージョンは、このクライアントコンピューティングデバイスに記憶し、インストレーションコンポーネントデルタパッチを介してこの現行のソフトウェアアップデートの要件について特にアップデートすることができる。したがって、この自己展開ファイル中のこのインストレーション情報は、クライアントコンピューティングデバイス110上において、含められた任意のインストレーションコンポーネントアップデートをこのインストレーションコンポーネントのこのベースラインバージョンとマージする必要があるか否かをアップデートエージェント118に指示する。アップデートが必要とされる場合、図13に関して以下でさらに非常に詳細に説明するように、ブロック1208において、アップデートエージェント118は、このベースラインインストレーションコンポーネント(baseline installation component)をアップデートする。
【0091】
このアップデートエージェントがこのインストレーションコンポーネントをアップデートした後に、またはこのインストレーションコンポーネントが、アップデートを必要としない場合には、ブロック1210において、アップデートエージェント118は、クライアントコンピューティングデバイス110上にインストールされたファイル、およびこの特定のバージョンのファイルのインベントリを実施する。本発明の例示の一実施形態において、アップデートエージェント118は、この選択されたアップデートに対応するものとしてこのパッケージ中で識別されたすべてのファイルについてクライアントコンピューティングデバイス110のファイルシステムに照会することができる。代わりに、アップデートエージェント118が、最近インベントリを実施したことがある場合には、このインベントリのキャッシュされたバージョンを利用することができる。ブロック1212において、アップデートエージェント118は、この要求されたアップデートを完了するためにどのようなソフトウェアアップデート情報が必要とされるかを識別する。本発明の例示の一実施形態において、そのパッチストレージマニフェストは、必要とされるデルタパッチに対するインストール済みのファイルのバージョンのマッピングを含んでいる。したがって、デルタパッチングが利用可能な場合、アップデートエージェント118は、このマッピングを利用してこのパッチストレージファイル内の特定のデルタパッチおよびそのオフセットロケーションを識別することになる。代わりに、デルタパッチが利用可能でなく実施できない場合には、アップデートエージェント118は、ダウンロードするために全体のファイルを識別することができる。
【0092】
次に図12Bを参照すると、ブロック1214において、このアップデートデートエージェント(update date agent)は、識別されたソフトウェアアップデート情報を求める要求を送信する。本発明の例示の一実施形態において、アップデートエージェント118は、このアップデートサービス120のダウンロードサーバ124に対してこのパッチストレージファイルから必要とされる特定の範囲のパッチを示すことによって特定のデルタパッチを求める要求を送信することができる。前述のように、このパッチストレージファイルは、各デルタパッチがそのパッチストレージファイルに伴うそのロケーションによって識別される多数の適用可能デルタパッチを含んでいる。このパッチストレージファイルが一部の実施形態ではかなり大きいこともあるので、アップデートエージェント118は、このパッチストレージマニフェストから指示されるように、このパッチストレージファイル中の特定のロケーションからのデータだけしか求めない要求を利用することができる。本発明の代替実施形態においては、アップデートエージェント118は、アップデートファイルの全体コピーおよび/またはこのパッチストレージファイルの完全コピーを要求することができる。
【0093】
本発明の代替実施形態においては、アップデートサービス120に排他的に関連づけることができない別のダウンロードサーバが、このアップデートエージェント118の要求を処理することができる。この実施形態においては、この要求パッチストレージファイルは、全部または一部分をネットワーク上で任意の数の追加のダウンロードサーバに対して伝送することができる。この追加のダウンロードサーバは、プライベートネットワーク上でクライアントをアップデートするために利用されるプライベートネットワークの一部分とすることができる。さらに、この追加のダウンロードサーバは、パブリックネットワークの一部分とすることができる。プライベートネットワーク環境においては、これらのダウンロードサーバは、クライアント要求を処理するためのパッチストレージファイルの完全コピーを取得することができる。代わりに、ダウンロードサーバは、他のクライアントからの以前のデータ要求を処理する際にこのパッチストレージファイルの一部分をキャッシュすることもでき、このキャッシュデータを利用してこのダウンロードを履行することができる。したがって、この追加のダウンロードサーバは、アップデートサービス120のダウンロードサーバ124上における通信歪み(communication strain)を低減することが可能である。
【0094】
ブロック1216において、アップデートエージェント118は、この要求されたアップデート情報を受信する。本発明の例示の一実施形態においては、この要求されたアップデート情報は、2つのアプローチで伝送することができる。手動アップデートと呼ばれる第1のアプローチでは、このアップデート要求は、直接HTTPデータ配信応答(direct HTTP data delivery response)を求める要求と共にアップデートサービス120に対して送信される。このアプローチにおいては、アップデートサービス120は、使用可能な全帯域幅のすべてを利用してこの要求されたデータをアップデートエージェント118に対して送信することができる。自動アップデートと呼ばれる第2のアプローチでは、このアップデート要求は、間接HTTPデータ配信応答(indirect HTTP data delivery response)を求める要求と共にアップデートサービス120に対して送信される。この応答においては、アップデートサービス120は、この要求されたデータをバックグラウンドプロセス(background process)として送信する。このバックグラウンドプロセスは、使用可能な帯域幅の最小量を利用するようにして実施することができる。さらに、このバックグラウンドプロセスは、このダウンロードプロセス中に中断し、次に利用可能な時に再開することができる。バックグラウンドプロセスを介して要求されたデータを伝送するためのシステムおよび方法についての説明は、参照により本明細書中に組み込まれている、2000年2月16日に出願の「System and Method for Transferring Data Over a Network」という名称の同一出願人による同時係属の米国特許出願第09/505,735号明細書中に説明されている。フォアグラウンドまたはバックグラウンドのデータ配信は、この選択されたソフトウェアアップデートの優先順位を必ずしも反映したものではなく、代わりにこのアップデート情報を取得するためにどのようにして帯域幅が割り付けられるかを反映したものであることが当業者には理解されよう。
【0095】
要求された情報をこのアップデートサービスから受信した後に、ブロック1218において、アップデートエージェント118は、このデルタパッチをこの対応するインストール済みのファイルとマージする。本発明の例示の一実施形態においては、アップデートエージェント118は、このインストール済みのファイルの元のバージョンをキャッシュして、この選択されたファイルがこのダウンロードおよびマージングプロセス中に変化しないようにする。さらに、このインストール済みのファイルのキャッシュされた元のバージョンを使用してこの選択されたアップデートをアンインストール(uninstall)することができる。
【0096】
判断ブロック1220において、テストを実施してこのアップデートされたファイルが有効であるかどうかを判定する。本発明の例示の一実施形態においては、アップデートエージェント118は、ハッシングアルゴリズムを利用して、アップデート情報パッケージから得られ、有効なファイルアップデートに対応する基準ハッシュ値を現在の修正されたファイルからのハッシュと比較することができる。これらのハッシュがマッチングしない場合、現行の修正ファイルは有効ではない。いくつかの代替の妥当性検査アルゴリズムのうち任意の1つを利用することもできることが当業者には理解されよう。このアップデートファイルが有効でない場合には、このサブルーチン1200はブロック1214に戻り、ここでこのアップデートエージェントは、アップデート情報を再度要求することができる。代わりに、アップデートエージェント118が、このアップデートファイルを数回にわたって生成しようと試みてもうまくいかない場合には、このアップデートエージェントは、いくつかのフォールバックプロシージャ(fallback procedure)の1つを実施することができる。本発明の一実施形態において、このアップデートエージェント118は、このパッチストレージファイルに記憶されこのパッチストレージマニフェストから識別されたアップデートファイルの完全コピーをアップデートサービス120から要求することができる。本発明の他の実施形態においては、アップデートエージェント118は、アップデートサービス120から自己完結型のファイル中のこのアップデートファイルのコピーを要求することができる。本発明のさらに他の実施形態においてサブルーチン1200は、その他の場合には失敗することもある。
【0097】
この選択されたファイルが有効になった後に、判断ブロック1222において、テストを実施して追加のダウンロードが何か必要とされるかどうかを判定する。本発明の例示の一実施形態においては、サブルーチン1200は、以前に選択されたダウンロードの終了後に追加のダウンロードがあるかについて絶えずチェックする反復ループに入る。このダウンロード中にファイルの状態が変化する場合、アップデートエージェント118は、この新しい状態変化について追加のダウンロードを要求し続けるはずである。追加のダウンロードが必要とされる場合には、ブロック1224において、アップデートエージェント118は、別のインベントリを実施し、すべての適用可能なデルタパッチを識別する。次いでこのサブルーチン1200はブロック1214へと戻る。
【0098】
すべてのこの要求されたアップデートのダウンロードが完了した後に、判断ブロック1226において、テストを実施して、このクライアントマシンの状態が変化しているかどうかを判定する。本発明の例示の一実施形態においては、アップデート情報のダウンロードおよびマージングと、このアップデートされたファイルの実際のインストレーションの間で時間が経過してしまうこともある。したがってこのアップデートファイルをインストールするのに先立ってこのアップデートエージェントは、このクライアントコンピューティングデバイス状態が変化しているかどうかを判定する。この状態が変化している場合には、このファイルアップデートは有効でないこともあり、このアップデートはブロック1228において失敗する。代わりに、状態の変化が起こっていなければ、アップデートエージェント118は、ブロック1230においてこのアップデートされたファイルをインストールし、サブルーチン1200は、ブロック1232において戻る。
【0099】
次に図13を参照して、ブロック1208(図12A)に対応するベースラインインストレーションコンポーネントをアップデートするための、クライアントコンピューティングデバイス110によって実施されるサブルーチン1300について説明することにする。判断ブロック1302において、テストを実施して新しいベースラインインストレーションコンポーネントが、アップデートサービス120からアップデートエージェント118に伝送される自己展開ファイル中に含まれるかどうかを判定する。本発明の例示の一実施形態において、このベースラインインストーラ(baseline installer)をアップデートするために必要とされるデルタパッチが、アップデートされたインストレーションコンポーネントの伝送とサイズが同等である場合、新しいベースラインインストレーションコンポーネントが伝送されることになる。アップデートされたインストレーションコンポーネントが含まれる場合には、ブロック1304において、このアップデートエージェントは、このアップデートされたベースラインインストレーションコンポーネントを新しいインストレーションコンポーネントとしてインストールする。さらに、この新しいアップデートされたインストレーションコンポーネントは、クライアントコンピューティングデバイス110のメモリに保存されて追加のアップデートについてのベースラインインストーラとしての役割を果たすことができる。ブロック1306においてこのサブルーチンは戻る。
【0100】
アップデートされたベースラインインストレーションコンポーネントが、この自己展開ファイル中に含まれていない場合には、ブロック1308においてアップデートエージェント118は、この自己展開ファイルからベースラインインストレーションコンポーネントデルタパッチを取得する。本発明の例示の一実施形態において、このベースラインインストレーションコンポーネントデルタパッチは、このベースラインインストレーションコンポーネントとマージされてアップデートされたベースラインインストレーションコンポーネントを生成することができるソフトウェアコードに対応する。したがって、ブロック1310において、このアップデートエージェントは、このベースラインインストレーションコンポーネントデルタパッチをこのベースラインインストレーションコンポーネントとマージする。ブロック1312において、次いでアップデートエージェント118は、このアップデートされたベースラインインストレーションコンポーネントを現在のインストレーションコンポーネントとして指定する。本発明の例示の一実施形態において、このインストレーションが完了した後にはこのアップデートされたインストレーションコンポーネントは、保存されないことになる。この実施形態によれば、アップデートエージェント118は、クライアントコンピューティングデバイス110のメモリ中に限られた数のベースラインインストレーションコンポーネントしか保持しない。したがって、このアップデートエージェントは、インストレーションごとに、一時的なアップデートされたインストレーションコンポーネントを生成する。各クライアントコンピューティングデバイス110は、限られた数のベースラインインストレーションコンポーネントにしか対応することができないので、アップデートサービス120には、クライアントコンピューティングデバイスごとに1つのベースラインインストレーションコンポーネントデルタパッチを伝送する必要があるだけである。ブロック1314において、このサブルーチン1300は、戻る。
【0101】
本発明の好ましい実施形態について示し説明してきたが、本発明の趣旨および範囲を逸脱することなく様々な変更をここで行うことができることが理解されよう。例えば、本明細書中で説明した例示の実施例は、ソフトウェアアップデートに適用されるが、本発明の範囲は、ソフトウェアアップデートに関連した情報の配信および通信以外の他の使用を含んでいる。したがって、特定の主題がこの開示中において明確に除外されない限り、本発明の範囲が、ソフトウェアアップデート以外の、またはソフトウェアアップデートに追加の任意タイプのデータの配信および通信に適用されることを理解されたい。
【技術分野】
【0001】
本発明は、ソフトウェアおよびコンピュータネットワークに関し、詳細には、本発明は、ソフトウェアアップデートを管理し伝えるためのシステムおよび方法に関する。
【背景技術】
【0002】
ほとんどの市販のソフトウェア製品は、継続的なリビジョンプロセスを受けて機能および/またはファンクションを修復し、またはアップグレードする。ソフトウェア製品またはソフトウェアコンポーネントの各リビジョンは、新しいファイルの追加および/または既存ファイルを新しいバージョンのファイルと置換することを必要とすることもある。ベンダが、ソフトウェア製品の問題を分離しその問題についての解決方法を作成した後に、ベンダは、その解決方法をアップデート中へと修正し、このアップデートを顧客に広く使用可能にしたいと望むはずである。ソフトウェアベンダは、ソフトウェアアップデートをできる限り速やかに、また問題なく顧客に対して配信すべきビジネスインセンティブ(business incentive)を有する。
【0003】
インターネットは、顧客がソフトウェア製品についての最終アップデートを取得するための重要なチャネルを提供する。インターネットの使用の爆発的な増加は、ソフトウェア製品およびアップデートがオンラインでダウンロードするために提供されるという、顧客による一般的な期待を生み出してきている。インターネットを使用してアップデートを配信することを推進することは、それがソフトウェアベンダのコストを低減し、その修正版がダウンロードのために使用可能になるとすぐに顧客が識別された問題についてのその修正版を取得できるようになるので、ソフトウェアベンダのためにもなる。インターネット上のこれらのベンダサイトは、あるアプリケーションについてのアップデートファイルを見出し、その所在を突き止めることを非常に簡単にするように設計することが可能である。ファイルダウンロードの技術的側面は、ユーザの観点からはほとんど見えなくなってしまっており、今では一般にオペレーティングシステムによって処理される。
【0004】
従来のアプローチでは、ソフトウェアベンダは、ソフトウェアアップデートをダウンロードのための「パッケージ」として構築する。このパッケージは、一般にその設定プログラムおよび各製品アップデートファイルが、埋め込まれ、このパッケージをより小さなパッケージにするために圧縮された自己展開(self−extracting、自己解凍)実行可能ファイルである。このパッケージのサイズは、一般に各変更ファイルの圧縮されたサイズとその抽出コードそれ自体のサイズを加えた合計である。実行すると、このパッケージは含まれている各ファイルを一時的なロケーションへと抽出し、次いでその設定プログラムを開始して各ファイルをシステムディレクトリ中の適切なロケーションにインストールする。圧縮形式で発送されたファイルは、ファイルがインストールされるときに伸張される。同じロケーション中の同じ名前の既存ファイルはどれも、この置換ファイルによって単に上書きされるはずである。
【0005】
インターネットがソフトウェアアップデートの広範で速やかな配信を可能にしているにもかかわらず、ネットワーク伝送のその限られた帯域幅が問題を引き起こしてきている。大規模な一般のソフトウェアアプリケーションが、アップデートのダウンロードサイズを不当なほど大きくなるようにしてきている。通常は、製品の様々な問題についての多数の修正が、1つのアップデート中にグループ化されることになる。ベンダが定期的にソフトウェア製品をアップデートする場合、このアップデートパッケージのダウンロードサイズは、ユーザがすでに以前のアップデートからこれらのファイルを有しているという想定の下ではこのベンダがファイルを省略することができないので、増大し続けることになる。アップデートパッケージは、いくつかの全体ファイルを結合するので、たとえこれらのファイルが圧縮されている場合でさえ、非常に大きくなってしまうこともある。時には、最高速のモデム接続上でさえ、このダウンロードの帯域幅効率は低下する。
【0006】
従来のダウンロードプロセスの時間を浪費する側面は、もちろん望ましくない。一部の場合においては、顧客は、これらのファイルのダウンロード中に長距離料金または接続時間料金を支払うこともある。接続時間のどのような短縮も、これらの顧客にとっての直接的な金銭的コストを低下させることになる。ベンダには一般に、ベンダが提供するダウンロードのサイズに関連した何らかの区別できるコストがあり、したがって、サイズを低減することは同様にベンダにとっても直接的な金銭的な利点をもたらす。ダウンロードのサイズを低減することは、その使用可能なネットワーク帯域幅を増大させることになり、ベンダは、既存のネットワークサーバ装置を用いて、より多くの顧客を満足させることができるようになる。
【0007】
大規模なアップデートをダウンロードするためにかかる長い時間は、様々なネットワーク接続問題に対してこのダウンロードプロセスをよりぜい弱にもする。電話回線ノイズ、キャッチホン信号、および意図的ではないコマンドを含めて、インターネットセッションが時期尚早にも切断されてしまう可能性がある理由がいくつかある。一部のインターネットサービスプロバイダは、接続時間制限を強制し、ユーザが単一セッション中でオンラインとなることができる時間長が制限される。ネットワーク接続が遮断される場合にそのユーザが大規模なファイルをダウンロードしている場合には、ユーザは、初めからやり直す必要があり得る。ほとんどの一般のオペレーティングシステムおよびファイル転送プロトコルでは、このファイル転送を再開できるようにはなっておらず、したがって、任意の中間的進捗状況が失われてしまうはずであり、この転送は再開される必要がある。エラーの可能性は非常に多いので、多くのユーザには、オンラインでそのアップデートを取得することがほとんど不可能であることが分かる。アップデートパッケージのサイズがあまりにも大きすぎる場合には、ユーザが、アップデートパッケージを完全にダウンロードすることが決してできないこともある。
【0008】
ソフトウェアアップデートのサイズを低減させ、帯域幅効率を増大させる1つの試みが、デルタパッチ(delta patch)またはバイナリパッチ(binary patch)の使用に関する。デルタパッチが、コンピューティングデバイスによって実行される場合に既存のファイルを修正する専用ソフトウェアコードに対応することが当業者には理解されよう。このデルタパッチが専用ソフトウェアコードを含むので、一意のデルタパッチは、ファイルの一意のバージョンごとに必要とされる。ソフトウェアアップデートに適用するときに、ソフトウェアアップデートサービス(software update service)は、完全なアップデートされたファイルを伝送する代わりに、より小さなサイズのアップデートデルタパッチを伝送することができる。次いでこのアップデートされたデルタパッチを利用してこの既存のファイルを修正してそのアップデートされたファイルにする。
【発明の概要】
【発明が解決しようとする課題】
【0009】
このアップデートデルタパッチは、ファイルをアップデートするために必要とされるデータ量を潜在的に減少させる可能性があるが、デルタパッチング(delta patching)に対する現行のアプローチは、ファイルの多数のバージョンが存在する状況において、適用可能なデルタファイルの選択を管理する際に不十分である。一意のデルタパッチがファイルのバージョンごとに必要とされるので、典型的なソフトウェアアップデートシステムではしばしば、ファイルの一意の各バージョンに対応する、たとえ数千でないとしても数百の一意のデルタパッチを必要とする可能性がある。1つのアプローチでは、デルタパッチングをサポートする一部のアップデートサービスは、すべての可能性のあるデルタパッチをクライアントコンピューティングデバイス(client computing device)に対して伝送する。しかし、このアプローチでは、一般に可能性のあるアップデートデルタパッチの数が増すにつれて、このソフトウェアアップデートを実施するために必要とされるデータ量が増大する。したがって、適用可能な可能性のあるデルタパッチ数は、その完全なアップデートされたファイルと同じサイズへと速やかに増大してしまう可能性がある。別のアプローチでは、ネットワーク化されたアップデートソフトウェアサービスが、クライアントマシンをスキャンしてクライアントマシンごとにどのデルタパッチが適用可能となり得るかを選択する。これによって伝送されるデルタパッチ情報量が減少するが、このアプローチは、そのクライアントマシンをスキャンし適用可能なデルタパッチを選択するための、このソフトウェアアップデートサービス上の追加のロジックを必要とする。この追加のロジックの使用は、このサービスが提供する必要があるそのシステムリソースを増大させる。さらに、このアプローチは一般に、従来のウェブサーバが一般に実現するなどのネットワークキャッシング(network caching)の利用を妨げる。
【0010】
前述の短所に加えて、既存のシステムでは、ハードウェアドライバなど、ある種のタイプのソフトウェアアップデートを配信することができない。当技術分野において知られているように、ハードウェアドライバに適用されるアップデートなど専用化されたソフトウェアアップデートは、ほとんどの専用化されたソフトウェアアップデートが特定のハードウェアを有するクライアントコンピュータ上でしか機能しないことになるので、大規模配信でユーザに提供することが困難である。ほとんどの場合において、例えばクライアントコンピュータが互換性のないハードウェアドライバのアップグレードを取得する場合には、このドライバアップグレードのインストレーションは、致命的なエラーを引き起こすこともあり、あるいはそのコンピュータが動作しないようにさえすることもある。
【0011】
前述のことから簡単に理解されるように、サーバといくつかのクライアントの間でソフトウェアアップデートの改善された通信を有するシステムおよび方法が必要になっている。さらに、専用化されたアップデートを配信する場合に、アップデートサービスが特定のタイプのクライアントをターゲットにすることを可能にする改善されたメカニズムを有するソフトウェアアップデートのシステムおよび方法が必要になっている。
【課題を解決するための手段】
【0012】
コンピューティングデバイス上においてファイルのインストレーションを管理するためのシステムおよび方法が提供される。クライアントコンピューティングデバイスは、このクライアントコンピューティングデバイス上に記憶される1つのバージョンのベースラインインストレーションコンポーネントを識別するインストレーション情報を取得する。このインストレーション情報はまた、このベースラインインストレーションコンポーネントとマージされてアップデートされたインストレーションコンポーネントを生成するインストレーションコンポーネントデルタパッチを含んでいる。このアップデートされたインストレーションコンポーネントを利用してこのクライアントコンピューティングデバイス上に1つまたは複数のファイルをインストールする。このインストレーションが完了すると、このアップデートされたインストレーションコンポーネントは、削除することができる。
【0013】
本発明の一態様によれば、このクライアントコンピューティングデバイス上のファイルのインストレーションを管理するための方法が提供される。この方法によれば、コンピューティングデバイスは、このクライアントコンピューティングデバイス上に1つまたは複数のファイルをインストールするための必要なベースラインインストレーションコンポーネントを識別するインストレーション情報を取得する。このコンピューティングデバイスは、このクライアントコンピューティングデバイス上に記憶されたベースラインインストレーションコンポーネントを選択する。このコンピューティングデバイスは、このインストレーション情報からインストレーションコンポーネントデルタパッチを取得し、このインストレーション情報からのインストレーションコンポーネントデルタパッチと、この選択されたベースラインインストレーションコンポーネントとをマージする。このコンピューティングデバイスは、このマージされたインストレーションコンポーネントを利用してこのクライアントコンピューティングデバイス上に1つまたは複数のファイルをインストールする。
【0014】
本発明のさらなる一態様によれば、このクライアントコンピューティングデバイス上のファイルのインストレーションを管理するための方法が提供される。この方法によれば、コンピューティングデバイスは、このクライアントコンピューティングデバイス上の1つまたは複数のファイルをインストールするための必要なベースラインインストレーションコンポーネントを識別する情報を含むパッケージを取得する。このコンピューティングデバイスは、このクライアントコンピューティングデバイス上に記憶されたベースラインインストレーションコンポーネントを識別し、このパッケージからインストレーションコンポーネントデルタパッチを取得する。このコンピューティングデバイスは、このパッケージからのこのインストレーションコンポーネントデルタパッチとこの識別されたベースラインインストレーションコンポーネントとをマージし、このマージされたインストレーションコンポーネントを利用してこのクライアントコンピューティングデバイス上に1つまたは複数のファイルをインストールする。このコンピューティングデバイスはまた、このクライアントコンピューティングデバイス上に1つまたは複数のファイルをインストールしたとき、このマージされたインストレーションコンポーネントを削除する。
【0015】
本発明のさらなる一態様によれば、このクライアントコンピューティングデバイス上のファイルのインストレーションを管理するための方法が提供される。この方法によれば、このコンピューティングデバイスは、クライアントコンピューティングデバイス上に記憶される1組のベースラインインストレーションコンポーネントから選択する情報を含むパッケージを取得する。このコンピューティングデバイスは、このクライアントコンピューティングデバイス上に記憶されるこの1組のベースラインインストレーションコンポーネントからベースラインインストレーションコンポーネントを選択する。このコンピューティングデバイスは、このパッケージからインストレーションコンポーネントアップデートを取得し、このインストレーションコンポーネントアップデートを用いてこの選択されたインストレーションコンポーネントをアップデートする。さらに、このコンピューティングデバイスは、このマージされたインストレーションコンポーネントを利用してこのクライアントコンピューティングデバイス上に1つまたは複数のファイルをインストールする。
【0016】
本発明の前述の態様およびその多くの付随する利点については、以下の詳細なる説明を添付図面と併せて参照することによってさらに良く理解が進むにつれて、さらに簡単に認識されよう。
【図面の簡単な説明】
【0017】
【図1】本発明による、クライアントコンピュータ、およびアップデートソフトウェアを提供するアップデートサービスを含むソフトウェアアップデートシステムを示すブロック図である。
【図2】本発明による、アップデートサービスを用いたクライアントコンピューティングデバイスの認証を示す、図1のソフトウェアアップデートシステムのブロック図である。
【図3】本発明による、クライアントコンピューティングデバイスとアップデートサービスの間の使用可能なアップデートの同期化を示す、図1のソフトウェアアップデートシステムのブロック図である。
【図4】本発明による、アップデートサービスからクライアントコンピューティングデバイスへのソフトウェアアップデート情報の伝送を示す、図1のソフトウェアアップデートシステムのブロック図である。
【図5】本発明による、クライアントコンピューティングデバイスによるアップデート情報の処理および選択を示す、図1のソフトウェアアップデートシステムのブロック図である。
【図6】本発明による、クライアントコンピューティングデバイスによるデルタパッチのマージング、およびアップデートファイルのインストレーションを示す、図1のソフトウェアアップデートシステムのブロック図である。
【図7】本発明による、クライアントコンピューティングデバイス上におけるインストレーションのために使用可能なソフトウェアアップデートを識別するための、クライアントコンピューティングデバイスおよびアップデートサービスによって実施されるソフトウェアアップデートルーチンを示す流れ図である。
【図8】本発明による、アップデートサービス上に記憶されるアップデートに対する選択的なアクセスを提供するための許可ルーチンのプロトコル図である。
【図9】本発明による、許可ルーチンを示す実施例の1組のソフトウェアアップデートのブロック図である。
【図10】本発明による、選択グループのソフトウェアアップデートをソフトウェアアップデートサービスからクライアントコンピューティングデバイスへと伝えるための同期化ルーチンのプロトコル図である。
【図11】本発明による、個別のクライアントコンピューティングデバイスにとって使用可能なソフトウェアアップデートのリストを表示するためのグラフィックユーザインターフェースの例示のセクションを示すブロック図である。
【図12A】本発明による、要求されたソフトウェアを検索しインストールするためのクライアントコンピューティングデバイス110によって実施されるソフトウェアアップデート処理サブルーチン1200の一部分を示す図である。
【図12B】本発明による、要求されたソフトウェアを検索しインストールするためのクライアントコンピューティングデバイス110によって実施されるソフトウェアアップデート処理サブルーチン1200の一部分を示す図である。
【図13】本発明による、ベースラインインストレーションコンポーネントをアップデートするための、クライアントコンピューティングデバイスによって実施されるサブルーチンを示す流れ図である。
【発明を実施するための形態】
【0018】
一般的に説明すると、本発明は、ソフトウェアアップデートを管理するためのシステムおよび方法を対象としている。より詳細には、本発明は、ソフトウェアアップデートを選択し実施するために必要とされる帯域幅および処理リソースを最小にしながら、ソフトウェアアップデートの選択と実施を実行するためのシステムおよび方法を対象としている。本発明によれば、ソフトウェアアップデートは、特定のソフトウェアアプリケーションまたはオペレーティングシステムについてのアップデートに対応することが可能である。さらに、ソフトウェアアップデートは、ソフトウェアドライバ、またはシステムBIOSなどのファームウェアへのアップデートを含むこともできる。本発明の一態様によれば、これらのソフトウェアアップデートを処理するためのシステムおよびコンポーネントアーキテクチャが提供される。本発明の別の態様によれば、クライアントマシンのアップデートサービスとの許可および同期化を実施するためのアップデートプロトコルおよびインターフェースが提供される。本発明のさらなる態様によれば、インストレーションコンポーネント、およびデルタパッチを利用した様々なインストール済みのファイルをアップデートするための方法が提供される。しかし、本発明の追加の態様を本出願において提供することもできることが当業者には理解されよう。さらに、各識別された態様は、個別に、あるいは共通の発明態様の一部分として考えることができることが、当業者には理解されよう。
【0019】
図1のソフトウェアアップデートシステム100は、本発明によるソフトウェアアップデートシステム100を示すブロック図である。一般的に説明すると、このソフトウェアアップデートシステム100は、1つまたは複数のクライアントコンピューティングデバイス110、アップデートサービス120、および外部アップデートプロバイダ130を含むことができる。一般的に説明すると、このアップデートサービス120は、このクライアントコンピューティングデバイス110に伝えられそこでインストールされるソフトウェアアップデートの配信を記憶し管理する。このソフトウェアアップデートは、このアップデートサービス120によって、あるいは任意の数の外部アップデートプロバイダ130によって提供することができる。
【0020】
このクライアントコンピューティングデバイス110と、このアップデートサービス120と、この外部アップデートプロバイダ130は、ネットワーク101を介して電子的に通信する。このネットワークは、LAN(ローカルエリアネットワーク)、またはWAN(ワイドエリアネットワーク)やインターネットなどのより大規模なネットワークでもよい。一般的に知られているソフトウェアを使用することにより、ソフトウェアアップデートシステム100は、クライアントコンピューティングデバイス110とこのアップデートサービス120のサーバ121、122、123および124との間でドキュメント、コマンド、および他の知られているタイプの情報を交換するように構成することができる。当業者には理解されるように、図1に示すソフトウェアアップデートシステム100は、本発明を実施するための1つの適切なシステムの簡略化された実施例であり、本発明は、この実施例だけには限定されない。
【0021】
以下にさらに詳細に説明するように、一実施形態のアップデートサービス120は、いくつかのサーバを備えている。図1に示すように、このアップデートサービス120は、このアップデートサービス120のこれら全部のプロセスを管理し、このアップデートサービス120のサーバ121、122、123および124のプロセスを調整するためのアップデートサーバ121を含んでいる。許可サーバ122は、クライアントが要求するときに許可クッキーを生成し、次にこの許可クッキーを使用してサーバクッキーを生成し、このサーバクッキーは、クライアントコンピュータがこのアップデートサービス120によって生成されるアップデートにアクセスすることができるようにする。メタデータサーバ123は、アップデートサービス120が提供するこれらのアップデートに関する一般的な情報を提供する。このメタデータサーバ123は、本発明のシステムが特定のタイプのクライアントコンピュータまたは特定のグループのクライアントコンピュータについての特定のアップデートを識別することができるようにする。ダウンロードサーバ124は、アップデートサービス120が提供するソフトウェアアップデートに関連するデータファイルを配信するための1つまたは複数のソフトウェアコンポーネントを提供する。
【0022】
外部アップデートプロバイダ130は、ソフトウェアアップデートを配信する1つまたは複数のサーバを含むことができる。外部アップデートプロバイダ130は、ソフトウェア、ソフトウェアアップデート、またはクライアントコンピュータのグループに対して配信すべき他のデータを提供するエンティティに関連づけることができる。例えば、外部アップデートプロバイダ130は、このアップデートサービス120を使用して1つまたは複数のソフトウェアアプリケーションについてのアップデートを配信したいと希望するサードパーティソフトウェア開発業者に関連づけることができる。別の実施例では、外部アップデートプロバイダ130は、ソフトウェアアップデートシステム120に関連づけることもできる。
【0023】
クライアントコンピューティングデバイス110は、ソフトウェアアプリケーション114を記憶し実行するどのようなコンピューティングデバイスとすることもできる。このクライアントコンピューティングデバイス110は、それだけには限定されないが、PC(パーソナルコンピュータ)、PDA(携帯型個人情報端末)、移動電話、2方向ページャなどを含めていくつかの異なるコンピュータ製品のうちのどの1つからでも形成することができる。当業者または他の人々に理解されるように、このクライアントコンピューティングデバイス110のアーキテクチャは適切な任意の形態を取ることができる。例えば、クライアントコンピューティングデバイス110は、ネットワーク101との通信を提供するためのネットワークインターフェースを含むことができる。このネットワークインターフェースは、有線または無線の任意のネットワーク接続と共に使用するように構成することができ、TCP/IPプロトコルなど適切な任意の通信プロトコルを用いて使用することができる。さらに、クライアントコンピューティングデバイス110は、処理ユニット、ディスプレイ、およびメモリユニットを含むことができる。このメモリユニットは、オペレーティングシステム116などのクライアントコンピューティングデバイス110を動作させるために必要なプログラムコードを記憶することができる。さらに、このメモリユニットは、本発明のプロセスを制御し実行するためのアップデート管理コンポーネント112を記憶する。
【0024】
このソフトウェアアップデートシステム100は、実行される場合に、本発明を実施するソフトウェアプログラムを記憶する。実行される場合に、このソフトウェアアップデートシステム100は、ソフトウェアアップデートを記憶し管理し選択的に伝える。以下でさらに十分に説明するように、多くの他の利点のうちでもとりわけ、本発明は、ソフトウェアアップデートを受信する資格を有するターゲットグループのクライアントコンピューティングデバイスを定義し選択するメカニズムを提供している。本発明は、ソフトウェアアップデートに関連するデータファイルをダウンロードするための改善されたメカニズムも提供している。
【0025】
本発明を例示する目的のために、本発明の動作する実施例の詳細な説明が提供される。この動作する実施例を説明するに際して、ソフトウェアアプリケーションの特定のアップグレード、例えばメディアプレーヤバージョン6.0からメディアプレーヤバージョン7.0のアップグレードを言及することができるソフトウェアアップデートに対して言及を行う。当業者には理解されるように、かかるソフトウェアアップデートは、このソフトウェアアップデートに関連するいくつかのデータファイルの通信およびインストレーションを含むことができる。したがって、本発明を例示する目的では、ソフトウェアアップデートとソフトウェアアップデートを含む個別のデータファイルとの間で区別が行われる。
【0026】
次に図2〜6を参照して、クライアントコンピューティングデバイス110上で1つまたは複数のファイルをアップデートするためのソフトウェアアップデートシステム100のコンポーネント間の例示の相互作用について説明する。図2を参照すると、ソフトウェアアップデートサービスは、1つまたは複数の外部アップデートプロバイダ130によるソフトウェアアップデート情報の伝送によって起動される。前述のように、外部アップデートプロバイダ130は、ソフトウェアアップデートシステム100に関連づけることができる。代わりに、ソフトウェアアップデート情報は、サードパーティの外部アップデートプロバイダ130が伝送することもできる。本発明の例示の一実施形態においては、このソフトウェアアップデート情報は、ファイルをアップデートするために利用されるソフトウェアコード、ファイルを置換するために利用されるソフトウェアコード、このソフトウェアアップデートの適用性を決定するための様々な規則、および/またはこのソフトウェアアップデートを記述するディスプレイ情報を含むことが可能である。このソフトウェアアップデート情報の送信は、いつでも終了することができ、他の例示したソフトウェアアップデートコンポーネントの相互作用の開始と同時である必要はない。
【0027】
外部アップデートプロバイダ130からのソフトウェアアップデート情報を受信すると、このアップデートサービス120は、1つまたは複数のデータを生成して、アップデート情報の伝送を実施する。このデータは、ファイルの異なるバージョンをアップデートするための1組のソフトウェアデルタパッチに対応するパッチストレージファイル(patch storage file)を含むことができる。このデータはまた、このパッチストレージファイル中で見出される対応するデルタ(delta)に対して特定のファイルバージョンをマッピングするインデックスに対応するパッチストレージマニフェスト(patch storage manifest)を含むこともできる。このデータは、以下にさらに非常に詳細に説明するように、このアップデートエージェント(update agent)が特定のソフトウェアアップデートデータを要求しインストールするために利用することになる情報に対応する自己展開ファイルをさらに含むことができる。パッチストレージファイル、パッチストレージマニフェスト、および自己展開ファイルの生成は、いつでも終了することができ他の例示したコンポーネントの相互作用と同時である必要がないことが当業者には理解されよう。
【0028】
ソフトウェアアップデート情報のクライアントに対する伝送を起動するために、クライアントコンピューティングデバイス110は、このアップデートサービス120に対して認証要求を起動する。本発明の例示の一実施形態においては、この認証要求は、クライアントコンピューティングデバイス110とアップデートサービス120の間のアップデートプロトコル相互作用に対応し、これについては、以下でさらに非常に詳細に説明することにする。この認証が完了すると、アップデートサービス120は、認証クッキーをクライアントコンピューティングデバイス120に送信する。次に図3を参照すると、この認証済みのクライアントコンピューティングデバイス120は、次いでこの使用可能なアップデートのアップデートサーバ120との同期化を起動する。本発明の例示の一実施形態においては、この同期化要求は、クライアントコンピューティングデバイス110とアップデートサービス120との間のアップデートプロトコル相互作用にも対応し、これについては、以下でさらに非常に詳細に説明することにする。この同期化が完了すると、クライアントコンピューティングデバイス110は、すべての適用可能なソフトウェアアップデートの情報、およびこのアップデートを記述する情報を受信する。しかし、本発明の例示の一実施形態においては、このアップデートをインスタンス化するソフトウェアコードは、ダウンロードされていない。
【0029】
続けて図3を参照すると、このアップデートプロセス中のある時点で、インストールすべきアップデートの選択が受信される。本発明の例示の一実施形態においては、ユーザが、同期化中に受信するソフトウェアアップデート情報を提示され、適切なアップデートを選択するように求められることもある。代わりに、クライアントコンピューティングデバイス110が、すべての適用可能なソフトウェアアップデートを自動的に選択するように構成することもできる。さらに、クライアントコンピューティングデバイス110が、使用可能なソフトウェアアップデートのサブセットを自動的に選択することができるようにする何らかの規則を有することもある。さらにまた、ユーザが、インターネットのウェブページを介するなどアップデートサービス120と通信することによってアップデートの選択を開始することもできる。
【0030】
次に図4を参照すると、アップデートエージェントがまだ存在していない場合、アップデート管理コンポーネント112は、クライアントコンピューティングデバイス110上でアップデートエージェント118をインスタンス化する。次いでアップデートエージェント118は、自己展開ファイルなどのソフトウェアアップデート情報パッケージの伝送を要求する。このアップデートエージェント118は、この自己展開ファイルを受信し、以下で説明するようにそのインストーラに対して任意のアップデートを実施する。さらに、アップデートエージェント118は、アップデートサービス120から任意の欠損した、または破損した情報を要求することができる。
【0031】
次に図5を参照すると、アップデートエージェント118が、そのソフトウェアアップデート情報パッケージを受信した後に、アップデートエージェント118は、クライアントコンピューティングデバイス110上でインストールされるファイルのインベントリを実施する。このインベントリとそのソフトウェアアップデート情報パッケージの比較に基づいて、アップデートエージェント118は、どのデルタパッチまたは他のアップデート情報が、この選択されたアップデートを完了するために必要になるかを決定する。次いでアップデートエージェント118は、特定のデルタアップデートを求める要求を伝送する。本発明の一実施形態においては、ソフトウェアアップデートを求める要求は、直接ネットワーク接続を介して伝送される直接要求に対応することもあり、これは手動アップデートと呼ばれることになる。本発明の別の実施形態においては、ソフトウェアアップデートを求める要求は、顕在的なユーザアクションを必要とせずに伝送されるバックグラウンド要求である場合もある。この実施形態は、自動アップデートと呼ばれることになる。
【0032】
本発明の例示の一実施形態においては、このソフトウェアアップデートが、デルタパッチに対応する場合、アップデートエージェント118は、そのパッチストレージマニフェストによって識別される特定のデルタパッチを識別する要求をアップデートサービス120に対して伝送する。代わりに、デルタパッチが使用可能でない場合、またはいくつかのデルタパッチが失敗している場合に、アップデートエージェント118は、フォールバックプロシージャ(fallback procedure)を起動することができる。このフォールバックプロシージャは、そのパッチストレージファイルから全体のアップデートファイルの完全コピーの伝送を求める要求を含むことができる。このフォールバックプロシージャはまた、自己完結型のパッケージから全体がアップデートされたファイルの完全コピーの伝送を求める要求を含むこともできる。
【0033】
本発明の例示の一実施形態においては、アップデートサービス120のダウンロードサーバ124は、アップデートエージェント118からのこのソフトウェアアップデート要求を直接処理することができる。代わりに、この要求は、アップデートサービス120からのこの要求されたアップデートデルタパッチをいずれにしても受信している従来のウェブサーバなど任意の数の追加の外部ダウンロードサーバによって処理することもできる。例えば、ある会社では、内部サーバを利用してクライアントマシンをアップデートすることができる。さらに、この要求は、以前の要求を処理する際にそのアップデートデルタパッチの一部または全部がキャッシュされた外部ダウンロードサーバによって処理することもできる。したがって、この実施形態においては、このダウンロードは、「HTTP」(hyper text transfer protocolハイパーテキスト転送プロトコル)データ要求をサービスすることが可能ないくつかの追加のダウンロードサーバに分散することができる。
【0034】
図6を参照すると、このソフトウェアアップデート情報が受信された後に、アップデートエージェント118は、このデルタパッチをこのインストール済みのファイルとマージしてアップデートされたファイルを生成する。さらに、アップデートエージェント118は、このマージが正常にその適切なファイルをアップデートしたかどうか妥当性検査することができる。前述のように、デルタパッチを妥当性検査することができない場合には、アップデートエージェント118は、そのデルタパッチを再度要求することができ、あるいは、何回かの失敗の後に全体がアップデートされたファイルを要求することができる。アップデートエージェント118が、妥当性検査されたアップデートファイルを取得した後に、このファイルは、クライアントコンピューティングデバイス110上にインストールされる。
【0035】
図7は、本発明による、クライアントコンピューティングデバイス110とソフトウェアアップデートサービス120の間の相互作用を示すソフトウェアアップデート処理ルーチン700の流れ図である。ブロック702において、このソフトウェアアップデートサービス120は、このクライアントコンピュータ110に対してアクセスを許可する。本発明の例示の一実施形態においては、クライアントコンピュータに対するアクセスの許可は、特定のグループのコンピュータに関連するソフトウェアアップデートへのアクセスを可能にするサーバ発行クッキー(server−issued cookie)の生成を含むことが可能である。この許可プロセスのより詳細な説明は、図8に関して説明することにする。
【0036】
ブロック704において、このクライアントコンピュータ110とソフトウェアアップデートサービス120は、アップデート情報を同期化させる。本発明の例示の一実施形態においては、ソフトウェアアップデートサービス120は、このクライアントコンピューティングデバイス110に対して特定のソフトウェアアップデートを記述するメタデータを送信する。このメタデータは、ユーザがインストレーションについての1つまたは複数のアップデートを選択できるようにする使用可能なソフトウェアアップデートを記述する情報を含んでいる。この同期化プロセスのより詳細な説明については、図9および図10に関して以下で説明することにする。ブロック706において、クライアントコンピューティングデバイス110は、ダウンロードする適用可能なアップデートの選択を得る。本発明の例示の一実施形態においては、適用可能なアップデートのこの選択は、ユーザの選択を実施するいくつかの固有のユーザインターフェースの利用に対応する可能性がある。ユーザインターフェースの選択については、図11に関してさらに非常に詳細に説明することにする。
【0037】
ブロック708において、クライアントコンピューティングデバイス110は、適用可能なソフトウェアアップデートのこのユーザ選択を処理し、ソフトウェアアップデートサービス120とインターフェースして特定のアップデート情報を要求する。本発明の例示の一実施形態においては、クライアントコンピューティングデバイス110は、1つまたは複数の適用可能なアップデートデルタパッチを選択し要求する。次いでクライアントコンピューティングデバイス110上のアップデートエージェント118は、この要求されたデータを処理してこの選択されたソフトウェアアップデートを実施することができる。ブロック710において、このルーチン700は終了する。
【0038】
図8を参照して、クライアントコンピューティングデバイス110に対してアクセスを許可するための、ブロック702(図7)に対応するプロトコル図800について次に説明することにする。本発明の例示の一実施形態においては、ソフトウェアアップデートサービス120は、メカニズム(extensible targeting mechanism)を利用してクライアントコンピューティングデバイス110のアップデートおよび他のソフトウェアへのアクセスを制御する。このソフトウェアアップデートサービス120は、特定のソフトウェアアップデートを1つまたは複数のターゲットグループのクライアントコンピューティングデバイス110に関連づけるメカニズムを組み込んでいる。例えば、ソフトウェアアップデートサービス120は、特定のハードウェアデバイスを有する特定のブランドのクライアントコンピューティングデバイス110だけに特定のハードウェアドライバアップデートのアクセスを制限することができる。かかる実施例においては、このソフトウェアアップデートサービス120は、特定のブランド名および特定のハードウェアデバイスを有するクライアントコンピューティングデバイス110のターゲットグループを定義し、この特定のソフトウェアダウンロードの送信をそのターゲットグループだけに制限することができる。
【0039】
本発明の例示の一実施形態においては、拡張ターゲティングメカニズムは、1つまたは複数のターゲットグループに対するクライアントコンピューティングデバイスの会員資格を定義するソフトウェアコンポーネント(「許可プラグイン」)の使用によって実行される。クライアントコンピューティングデバイス110上の許可プラグインの存在は、そのクライアントコンピューティングデバイスがその許可プラグインの特定のターゲットグループに属するかどうかを規定する。例えばあるターゲットグループは、特定のソフトウェアアプリケーションについての有効な「PID」(product identification製品識別)番号を有するすべてのコンピュータを含むことができる。かかる実施例においては、図8に関して以下でより詳細に説明するように、許可プラグイン826をそのクライアント中でインストールしてそのクライアントコンピューティングデバイスのメモリモジュールからPIDを読み取り、この得られたPIDを対応するPIDサーバプラグイン829へと渡すことができる。本明細書中でPIDバリデータ(PID validator)829とも呼ばれるこの対応するPIDプラグインは、1つまたは複数の方法を利用してこの受信されたPIDが有効かどうかを判定する。このクライアントコンピューティングデバイス110上に記憶されているPIDが有効であると判定された後に、このサーバは、このクライアントコンピューティングデバイス110が有効なPIDを有するターゲットグループのメンバであることを示すサーバクッキーを生成する。別の実施例においては、ターゲットグループは、ベータテストコンピュータ(beta test computer)として指定されるクライアントコンピューティングデバイスを含むことができる。
【0040】
本発明の例示の一実施形態においては、ソフトウェアアップデートサービス120の許可サーバ122は、この許可サーバが認識することになるクライアントコンピューティングデバイスの1組のターゲットグループを定義するいくつかのサーバ許可プラグインを含んでいる。各サーバ許可プラグインは、クライアントコンピューティングデバイス110上に記憶された対応するクライアント許可プラグインとデータをやりとりするコンポーネントを含んでいる。同様にして、各クライアントコンピューティングデバイス110は、そのクライアントが属するターゲットグループを識別する1つまたは複数のクライアント許可プラグインを含んでいる。本発明の例示の一実施形態においては、このクライアント許可プラグインは、オペレーティングシステムのインストレーションやアップグレードなど、ソフトウェアアプリケーションのインストレーションまたはアップグレード中に各クライアントコンピューティングデバイス中にインストールすることができる。さらに、このサーバ許可プラグインは、ソフトウェアアップデートへのアクセスを制御したいと希望するアドミニストレータが動的にインストールし、または取り除くことができる。クライアントコンピューティングデバイス110および許可サーバ122上に記憶されたこの許可プラグインは、実際のソフトウェアプラグインとすることも可能であり、あるいはこの許可プラグインは、動的にリンクされたライブラリ中へとハードコード化することも可能である。
【0041】
図8に示すように、この許可サーバ122は、3つの実施例のサーバ許可プラグイン、すなわち(1)すべてのコンピュータを含むターゲットグループ(以下で、「オールコンピュータターゲットグループ(All Computer target group)」)を定義する第1のサーバ許可プラグイン828、(2)有効なPIDを有するコンピュータを含むターゲットグループ(以下で、「PIDターゲットグループ」)を定義する第2のサーバ許可プラグイン829、および(3)ベータテストコンピュータを含むターゲットグループ(以下で、「ベータターゲットグループ」)を定義する第3のサーバ許可プラグイン830を含んでいる。また図8に示すように、クライアントコンピューティングデバイス110は、2つのクライアント許可プラグイン、すなわち(1)クライアントコンピューティングデバイス110が、オールコンピュータターゲットグループのメンバであることを示す第1のクライアント許可プラグイン825、および(2)クライアントコンピューティングデバイス110が、PIDターゲットグループのメンバであることを示す第2のクライアント許可プラグイン826を含んでいる。この実施例においては、クライアントコンピューティングデバイス110は、このクライアントコンピューティングデバイス110がそのベータターゲットグループのメンバであることを示す許可プラグインを含んでいない。当業者には理解されるように、各クライアント許可プラグイン825および826は、クライアントコンピューティングデバイス110上で1つまたは複数のファンクションを実行してこの妥当性検査プロセスを支援するように構成することができる。例えば、この第2のクライアント許可プラグイン826は、クライアントコンピューティングデバイス110のメモリを検査してインストール済みのソフトウェアアプリケーションについてのPIDを検証し、または取得するように構成することができる。
【0042】
図8に示すように、許可サブルーチン702は、クライアントコンピューティングデバイス110が構成要求803を許可サーバ122に伝える場合に開始される。本発明の例示の一実施形態においては、この構成要求803は、この許可サーバ122上に記憶されたその許可プラグインを記述する情報を取得するように構成された任意の適切なソフトウェアコンポーネントから形成される。当業者には理解されるように、構成要求803は、「GetConfig」と呼ばれる、知られている方法を利用することができる。この構成要求803を受信することに応答して、許可サーバ122は、構成応答804を伝え、この構成応答は、許可サーバ122上に記憶されたすべての許可プラグインを識別する情報を含んでいる。一実施形態においては、この構成応答804は、許可サーバ122上に記憶されるすべての許可プラグインを識別し記述するストリングのアレイを含んでいる。本実施例においては、この構成応答804は、第1のサーバ許可プラグイン828、第2のサーバ許可プラグイン829、および第3のサーバ許可プラグイン830を識別する情報を含んでいる。
【0043】
ブロック805において、クライアントコンピューティングデバイス110は、この構成応答804を受信することに応答して1つまたは複数の許可クッキーを生成する。ブロック805のプロセスにおいて、クライアントコンピューティングデバイス110は、マッチングしたクライアントとサーバ許可プラグインの各対ごとに許可クッキーを生成する。したがって、本実施例においては、第1のクライアント許可プラグイン825と第1のサーバ許可プラグイン828が共にオールコンピュータターゲットグループに関連するので、第1のクライアント許可プラグイン825は、このオールコンピュータターゲットグループに関連する第1の許可クッキーを生成する。さらに、第2のクライアント許可プラグイン826と第2のサーバ許可プラグイン829が共にPIDターゲットグループに関連するので、第2のクライアント許可プラグイン826は、このPIDターゲットグループに関連する第2の許可クッキーを生成する。クライアントコンピューティングデバイス110は、それがベータターゲットグループのメンバであることを示す許可プラグインをもたないので、第3の許可クッキーは生成されない。
【0044】
当業者には理解されるように、ブロック805のプロセスの一実施形態は、当技術分野において「GetAuthCookie」と呼ばれる一般に知られているソフトウェアの方法を使用することを含んでいる。この各許可クッキーの生成は、追加の処理を含むことができることも理解されよう。例えば、第2のクライアント許可プラグイン826は、このクライアントのシステムレジストリ(system registry)に記憶された情報を検査してPIDを検索しこのPIDをこの許可クッキー中に含めるように構成することができる。他の実施例においては、ブロック805のプロセスは、他のコンピュータまたはデバイスと通信するためのプロセスを含むことができる。例えば、クライアント許可プラグインは、サウンドカード、スキャナ、ビデオカードなどのデバイスと通信してこのデバイスの型およびモデルを取得することができる。限定のない他の実施例においては、クライアント許可プラグインは、フィンガプリントリーダ(fingerprint reader)などのセキュリティデバイスと通信して、ユーザを記述する情報を取得することができる。
【0045】
一般に、クライアント許可プラグインは、クライアントコンピューティングデバイス110、またはクライアントコンピューティングデバイス110に通信可能に接続された他の任意のコンピューティングデバイスの任意のコンポーネントから構成情報を読み取ることができる。他の実施例においては、クライアント許可プラグインは、1つまたは複数のパブリックまたは専用のAPI(アプリケーションプログラミングインターフェース)を利用してこの対応するサーバプラグインによって妥当性検査されるクライアントからの情報を収集し暗号化するように構成することができる。かかる実施例においては、PIDバリデータプラグイン826は、専用のAPIを使用してこのクライアントのPIDを暗号化して、この暗号化済みのPIDを暗号解読と妥当性検査のためにサーバに渡す。他の実施形態においては、他のクライアント許可プラグインは、フィンガプリントリーダや声紋などの生物測定学の測定を利用して許可クッキーを構築して妥当性検査のためにサーバに渡すことができる。さらに他の実施例においては、クライアント許可プラグインは、ウェブサービスまたは他の任意のサービスを呼び出して許可証明書または他の任意タイプのデータをこの許可サーバ122に伝えることができる。
【0046】
本発明の例示の一実施形態においては、各許可クッキーは、関連するターゲットグループを識別するストリングを含んでいる。例えば、ストリングは、特定の許可クッキーがこのPIDターゲットグループに関連することを示すことができる。各許可クッキーは、クライアントとサーバの間でデータを伝えるためのデータセクションも含んでいる。例えば、このPIDターゲットグループに関連する許可クッキーは、実際のPIDを含むデータセクションを有することができる。当業者には理解されるように、このデータセクションは、バイトアレイなどの任意の形式で記憶される任意のタイプのデータを含むことができる。例えば、クライアントおよびサーバ上のプラグインが、パブリックキー(public key)およびプライベートキー(private key)の通信を必要とする場合には、かかるデータは、1つまたは複数の許可クッキーのデータセクション中で暗号化することができる。
【0047】
クライアントコンピューティングデバイス110が対応するクライアントおよびサーバの許可プラグインの各対ごとに許可クッキーを生成した後に、このクライアントコンピューティングデバイスは、この生成済みの許可クッキーをこの許可サーバ122に対して伝える。図8に示すように、クライアントコンピューティングデバイス110は、クッキー要求806においてこの許可クッキーを伝える。このクッキー要求806は、ブロック805のプロセス中で生成された許可クッキーのアレイを伝えるための適切な任意のフォーマットを含んでいる。この許可方法702のこの一部分の一実施形態は、当技術分野において「GetCookie」と呼ばれる一般的に知られているソフトウェアの方法の使用を含むことができる。
【0048】
一実施形態においては、クッキー要求806は、クライアントコンピューティングデバイス110のメモリに記憶された他の許可サーバクッキーも含んでいる。以下の説明からさらに簡単に理解されるように、クライアントコンピューティングデバイス110のこのメモリは、この許可ルーチン700の以前の実行において作成された以前の許可サーバクッキーを記憶していることもある。クッキー要求806においてこの記憶済みの許可サーバクッキーを提供することにより、このクライアントコンピューティングデバイス110は、許可サブルーチン702の以前の実行で認可されたそのアクセス権を維持することができるようになる。本実施例においては、このクライアント中に許可サーバクッキーが記憶されていないので、このクッキー要求806は、このオールコンピュータターゲットグループに関連する第1の許可クッキーと、このPIDターゲットグループに関連する第2の許可クッキーを含んでいる。
【0049】
次に、ブロック807に示すように、このクッキー要求806を受信することに応答して、許可サーバ122は、サーバクッキーを生成する。一実施形態においては、この受信した許可クッキーごとに適切な許可プラグインに対して呼出しを行って、サーバクッキーデータが生成される。各サーバ許可プラグインによって生成されるサーバクッキーデータは、この受信された許可クッキー中で識別されるターゲットグループごとの識別子を含んでいる。本実施例においては、クッキー要求806が、このオールコンピュータターゲットグループに関連する第1の許可クッキーと、このPIDターゲットグループに関連する第2の許可クッキーとを含んでいるので、許可サーバ122は、これらの各ターゲットグループについての識別子を含むサーバクッキーデータを生成する。許可サーバ122上において、以前のサーバクッキーがそのクッキー要求806において受信されている場合には、このサーバクッキーデータを以前のサーバクッキーのデータと組み合わせて新しいサーバクッキーを生成する。一実施形態においては、この新しいサーバクッキーは、トリプルDES(Triple DES)などのパブリックに利用可能な暗号方法の使用によって暗号化される。
【0050】
本発明の例示の一実施形態においては、このサーバクッキーは、1つまたは複数の関連するターゲットグループを識別する暗号化された情報を含むことが可能である。さらに、このサーバクッキーは、有効期限データ(expiration data)を含むことができ、これは、クリアテキストフォーマットでも暗号化フォーマットでも記憶される。クリアテキストフォーマットで記憶される有効期限データは、このサーバクッキーの有効期限切れについて監視するためにクライアントコンピューティングデバイス110によって使用される。この暗号化フォーマットで記憶される有効期限データは、ソフトウェアアップデートサービス120によって使用されて、このクライアントコンピューティングデバイス110が、特定のターゲットグループに関連するアップデートを受信することが許可されているかどうかを判定する。一実施形態においては、このサーバクッキーの有効期限データは、このサーバクッキーで識別されるすべてのターゲットグループに適用される。代わりに、またはこの全体のサーバクッキーに適用される有効期限の時間に追加して、このサーバクッキーは、それぞれ、個別のターゲットグループに適用できる複数の有効期限データを含むことができる。当業者には理解されるように、各サーバクッキーは、追加のデータを含むことができる。例えば、サーバクッキーは、この許可サブルーチン702の最後の実行のタイムスタンプなどのクライアント状態情報を記憶するように構成することができる。
【0051】
生成された後に、この許可サーバクッキー809は、許可サーバ122からクライアントコンピューティングデバイス110に伝えられる。次に、ブロック811に示すように、このサーバクッキーは、その後にクライアントコンピューティングデバイス110のメモリに記憶される。クライアントコンピューティングデバイス110が、このサーバクッキーの少なくとも1つのコンポーネントが、有効期限切れになったことを判定した場合には、このクライアントコンピューティングデバイスは、この許可方法702を再実行して新しいサーバクッキーを取得することができる。前述のように、この許可方法702の後続の各実行において、クライアントコンピューティングデバイス110は、このクッキー要求806においてその記憶されたサーバクッキーを許可サーバ122に対して伝えることができる。一実施形態においては、サーバが、クライアントにこのサーバ構成が変更されたこと、すなわち新しい許可プラグインが追加されたことを通知しない限り、このクライアントは、要求803を送信する必要がない。
【0052】
本発明の別の態様によれば、このソフトウェアアップデートサービス120は、メタデータサーバ123とクライアントコンピューティングデバイス110の間でアップデート情報を同期化させるための同期化サブルーチンを提供することができる。一意のソフトウェアアップデート階層を使用することによって、この同期化サブルーチンは、特定のクライアントコンピューティングデバイスに適用される特定のアップデートを効率的に識別することが可能である。さらに、この許可サブルーチン702において生成されるこのサーバクッキーの使用によって、この同期化サブルーチンは、特定のターゲットグループに関連するアップデートに対するアクセスを選択的に認可することが可能である。
【0053】
本発明の例示の一実施形態によれば、各ソフトウェアアップデートは3つのコンポーネント、すなわち(1)命令コンポーネント、(2)局所的データコンポーネント、および(3)データコンポーネントを含んでいる。当業者には理解されるように、各アップデートは、1つまたは複数の前述のコンポーネントを有することができる。例えば、アップデートが、命令コンポーネント、局所的データコンポーネント、およびデータストリームコンポーネントを含むこともある。別の実施例においては、アップデートは、クライアントコンピューティングデバイスの1つまたは複数の条件をテストするための1つの命令コンポーネントしか含まないこともある。このソフトウェアアップデートの様々なコンポーネントについて以下でより詳細に説明する。
【0054】
一般的に説明すると、この命令コンポーネントは、2つのサブコンポーネント、すなわち(1)クライアントコンピューティングデバイス110がテストすべき1つまたは複数の条件を定義する適用規則、および(2)個別のアップデートの適切なインストレーションのために必要とされる1つまたは複数のアップデートを識別する1組の前提条件を含んでいる。以下で説明するように、この適用規則は、1台のコンピュータに関連したいくつかの条件を定義することが可能であり、これらの各条件は、任意の論理演算子を使用することによって他の条件に関連づけることが可能である。例えば、この命令コンポーネントは、コンピュータが特定のバージョンのWindows(登録商標)をインストールしているかどうかを判定する適用規則を含むこともできる。また以下で説明するように、この1組の前提条件は、以前にインストールされている必要がある1つまたは複数のアップデートを識別することが可能である。例えば、図9を参照して以下でさらに詳細に説明するように、個別のアップデートは、個別のアップデートの適切なインストレーションのために必要とされる他のアップデートをリストにした前提条件を含むこともある。他の実施例においては、図9にも示すように、この1組の前提条件は、より複雑な前提条件の規則を定義するための論理演算子の使用を含むことも可能である。
【0055】
この命令コンポーネントはまた、特定のアップデートに依存する他のアップデートが存在するかどうかを示す、ブールフラグ(Boolean flag)などのコードも含む。図では、特定のアップデートに依存する他のアップデートが存在しない場合には、アップデートは、LEAFアップデートであると考えられる。あるアップデートがLEAFであるかどうかを示すために使用されるこのブールフラグは、関連したアップデートが追加され、または除去されるときに、メタデータサーバ123によって動的にアップデートされる。
【0056】
各アップデートの局所的データコンポーネントは、このアップデートを記述する一般的な情報を含んでいる。例えば、この局所的データコンポーネントは、このアップデートの特徴および利点を記述する情報を含むことができる。この局所的データコンポーネントはまた、このアップデートのインストレーションプロシージャのテキスト記述を含むこともできる。さらに、この局所的データコンポーネントは、このアップデートに関連した他の任意のデータまたは情報を含むこともできる。例えば、その局所的データは、アップデートが、高優先順位のアップデートであることを示すことができる。別の実施例においては、この局所的データは、アップデートが他のソフトウェアアップデートと共にインストールすることができないことを示すメッセージなど、特定のインストレーションメッセージを提供することができる。この局所的情報は、ユーザに対してその含まれる情報の表示を可能にするフォーマットにすることもできる。
【0057】
各アップデートのデータコンポーネントは、そのアップデートの1つまたは複数のバイナリデータストリーム(binary data stream)を含んでいる。一実施形態において、各アップデートのデータコンポーネントは、実行可能ファイル、ドキュメント、リンクされたライブラリなど、1つまたは複数のデータファイルに関連づけることができる。以下でさらに詳細に説明するように、各アップデートは、データファイルの組合せに関連づけることができ、これらのデータファイルのそれぞれは、クライアントが使用するソフトウェアの実際のアップグレード、インストレーション、または修正を実施する。例えば、アップデートのインストレーションは、選択されたアップデートを完了するために必要とされるすべての情報を含む1つのCABファイルの使用によって実施することができる。代わりに、このアップデートのインストレーションは、クライアントコンピューティングデバイス上に記憶される1つまたは複数のファイルをアップデートするために使用されるいくつかの個別のアップデートの使用によって実施することができる。
【0058】
本発明の例示の一実施形態においては、ソフトウェアアップデートは、このソフトウェアアップデートの制御された配信を可能にする階層の形で構成することが可能である。一般的に説明すると、アップデートのこの階層は、アップデートの間の関係を定義しており、特にどのアップデートが他のアップデートに依存しているかを示している。図示するために、実施例の1組のアップデートが、図9に提供され示されている。図に示すように、サンプルのアップデート900の階層は、ベースの組のアップデート901、第2の組のアップデート902、および第3の組のアップデート903を含んでいる。一般的に、ベースの組のアップデート901中の各アップデートは、他のアップデートのインストレーションを必要とする前提条件を有していない。しかし、第6のアップデート921は、この第1のアップデート911、第2のアップデート912、および第3のアップデート913のインストレーションを必要とする前提条件を含んでいる。第7のアップデート922は、第4のアップデート914のインストレーションを必要とする前提条件を含んでいる。第8のアップデート931は、第6のアップデート921、および第5のアップデート915のインストレーションを必要とする前提条件を含んでいる。したがって、第8のアップデート931はまた、第1のアップデート911、第2のアップデート912、および第3のアップデート913のインストレーションを必要とする。本発明を例示するために、このサンプルの1組のアップデート900のうちのすべてのアップデートが、すべてオールコンピュータターゲットグループおよびPIDターゲットグループに関連していることが想定されている。
【0059】
また図9に示すように、また以下でさらに詳細に説明するように、各アップデートは、このアップデートのインストレーションについての条件を指定する適用規則を含んでいる。例えば、第1のアップデート911は、オペレーティングシステムの英語バージョンのインストレーションを必要とする。第2のアップデート912は、Windows(登録商標)XPバージョンSP1のインストレーションを必要とする。別の実施例においては、第6のアップデート921は、XP PATCH1と呼ばれるソフトウェアパッチのインストレーションを必要とする。したがって、この適用規則が満たされていない場合には、クライアントコンピューティングデバイス110は、このアップデートをインストールしないはずである。
【0060】
図9はまた、特定のアップデートに依存する他のアップデートがあるかどうかを示す命令コンポーネントのセクションを示している。このセクションは、LEAFと呼ばれ、これは、ソフトウェアアップデートが一連の関連したアップデートの最後のアップデートであることを示すブール値(Boolean value)の形式とすることができる。本発明を例示する目的では、他のアップデートが、特定のアップデートを前提条件としてリストアップしない場合には、特定のアップデートは、LEAFアップデートになる。図9に示すように、第7のアップデート922と、第8のアップデート931が、このたった2つのLEAFアップデートである。
【0061】
図10は、本発明に従って形成される同期化サブルーチン704(図7)のプロトコル図を示している。一般的に説明すると、この同期化サブルーチン704は、クライアントコンピューティングデバイス110と、メタデータサーバ123などのサーバとの間である種のアップデートの命令コンポーネントを選択的に交信してクライアントコンピューティングデバイス110に適用することが可能なアップデートを識別する。図10に示すように、アップデートを起動するために、クライアントコンピューティングデバイス110は、まずインストール済みのアップデートを処理し、このクライアントにとって使用可能な1つまたは複数のアップデートを要求する同期化要求1051をメタデータサーバ123に対して伝える。この同期化要求1051を受信することに応答して、このメタデータサーバ123は、いくつかのアップデートをこのクライアントコンピューティングデバイス110に対して戻す。以下の説明からさらに簡単に理解されるように、クライアントコンピューティングデバイス110は、この同期化要求1051の通信に先立って局所的に記憶されたデータを処理する。
【0062】
クライアントコンピューティングデバイス110は、各受信されたアップデートの命令コンポーネントを処理してこの適用規則中で定義されるその条件を満たすことができるかどうかを判定する。個別のアップデート中で定義されるこの条件が満たされる場合、同期化サブルーチン1050を例示する目的では、個別のアップデートが「インストール済み」であり、このインストール済みのアップデートがこのクライアントのアップデートキャッシュの第1のコンポーネントに保存される。他方、個別のアップデート中で定義されるこの条件が満たされない場合には、個別のアップデートは、「失敗した」と考えられ、この失敗したアップデートが、このクライアントのアップデートキャッシュの第2のコンポーネントに保存される。この同期化サブルーチン1050のこの説明において、アップデートがインストールされる場合には、この適用規則のこれらの前提条件およびこの条件が満たされていることを仮定することができる。このサブルーチンを説明するためのアップデートのインストレーションは、このアップデートに関連するこのデータファイルが、クライアントコンピューティングデバイス110において実際にインストールされることを必ずしも意味していない。
【0063】
一実施形態においては、このクライアントのアップデートキャッシュのこれらの2つのコンポーネントを使用してこの受信済みのアップデートを分類する。第1のコンポーネントが、インストール済みの非LEAFアップデートを記憶するために使用され、第2のコンポーネントが、クライアントが受信する他のすべてのアップデート、すなわちインストールされなかったアップデートを記憶するために使用される。このアップデートキャッシュの第2のコンポーネントは、すべてのLEAFアップデートのストレージも含んでいる。以下でさらに詳細に説明するように、このアップデートキャッシュに記憶されるアップデートが、メタデータサーバ123に伝えられこれによって処理されてクライアントコンピューティングデバイス110上でインストレーションのために使用可能な他の関連したアップデートを識別することができる。
【0064】
ここで図10に戻って、アイテム1051、1055、および1060として示されている同期化要求の細部について次に説明することにする。当業者には理解されるように、この同期化要求は、アップデートを要求するいくつかの異なるデバイス、プロセス、アプリケーション、ユーザ起動されたコマンドのうちの1つによって起動することができる。この同期化要求は、アップデートのリストを要求するユーザ、クライアントエージェントが起動する自動アップデート、あるいはメタデータサーバ123またはアップデートサービス120からの情報を要求する他の任意のソフトウェアコンポーネントによって起動することができる。一実施形態においては、この同期化要求は、許可ルーチン702から生成された許可サーバクッキーなどの許可サーバクッキーを含んでいる。このサーバクッキーの使用により、このサーバは、そのクライアントが1つまたは複数のターゲットグループのメンバであるかどうかを判定できるようになる。
【0065】
各同期化要求は、このクライアントのアップデートキャッシュに記憶されたアップデートごとの識別子を含むこともできる。より詳細には、1つまたは複数のアップデートが、アップデートキャッシュに記憶されている場合、この同期化要求は、インストール済みの非LEAFアップデートについての識別子を有する第1のコンポーネントと、LEAFアップデート、失敗したアップデート、インストールされなかった他のアップデートなど、他のすべてのアップデートについての識別子を有する第2のコンポーネントとを含んでいる。このアップデート識別子は、それだけには限定されないが、整数アレイを含めて任意のフォーマットにすることができる。代わりに、このクライアントのアップデートキャッシュにアップデートが記憶されていない場合には、この同期化要求は、アップデート識別子を用いて構成されていない。同期化要求がアップデート識別子を用いて構成されていない場合に、この同期化要求は、このクライアントコンピューティングデバイス110がキャッシュされたアップデートをまったくもたないことを示す指示を提供する。
【0066】
図10に示すように、第1の同期化要求1051が、クライアントコンピューティングデバイス110からメタデータサーバ123へと伝えられる。本実施例においては、これがこの方法の最初の実行であることを考えれば、このクライアントのアップデートキャッシュは、どのようなアップデートも含んでいないことになる。したがって、この第1の同期化要求1051は、キャッシュされたアップデートについての識別子を含んでいない。この同期化要求を受信することに応答して、ブロック1052に示すように、メタデータサーバ123は、この同期化要求が少なくとも1つのアップデート識別子を含むかどうかを判定する。この同期化要求がアップデート識別子を含んでいないと判定された場合、メタデータサーバ123は、クライアントコンピューティングデバイス110に伝えるための第1のレベルのアップデートを選択することによって応答する。前述のように、第1のレベルのアップデートは、他のアップデートを識別する前提条件をもたないどのようなアップデートも含むことができる。
【0067】
代わりに、同期化要求が、少なくとも1つのアップデート識別子を含んでいると判定された場合には、メタデータサーバ123は、このサーバの記憶されたアップデートの前提条件を検査してこのクライアントに配信するための追加のアップデートを選択する。一実施形態においては、メタデータサーバ123は、条件が満たされた前提条件を有するアップデートを選択する。この前提条件の検査において、このサーバは、このクライアント上にインストールされた非LEAFアップデートの識別子を含む同期化要求の第1のコンポーネントのアップデートを使用する。
【0068】
条件が満たされた前提条件を有するアップデートを選択するのに加えて、このサーバはまた、この同期化要求の第2のコンポーネント中で識別されるアップデートを使用してこの選択されたアップデートにフィルタをかける。より詳細には、この同期化要求の第2のコンポーネント中で識別されるインストールされていないアップデート、LEAFアップデート、および失敗したアップデートを使用して1つまたは複数の選択されたアップデートにフィルタをかける。本発明のこの特徴によって、本発明のシステムおよび方法は、メタデータサーバ123上に記憶されるアップデートの複数回の伝送を回避することができるようになる。
【0069】
本実施例に戻ると、この第1の同期化要求1051は、アップデート識別子を含んでいないので、このメタデータサーバ123は、クライアントコンピューティングデバイス110に伝えるためのベースレベルのアップデート901を選択する。図9に示すアップデートのサンプルの組を参照すると、このベースレベルのアップデート901は、911、912、913、914および915と呼ばれるアップデートを含んでいる。
【0070】
ブロック1052の処理において、メタデータサーバ123はまた、この同期化要求1051に含まれる許可サーバクッキーを検査して、クライアントコンピューティングデバイス110に関連するターゲットグループを識別する。メタデータサーバ123はまた、ブロック1052のプロセスで選択されたこのアップデートのターゲットグループも検査する。次いで、ブロック1052のこのプロセスは、この受信済みの許可サーバクッキー中で識別されるターゲットグループに関連していないすべての選択されたアップデートをフィルタで取り除く。本実施例においては、選択されたアップデート911、912、913、914および915のすべてが、PIDターゲットグループおよびオールコンピュータターゲットグループに関連するので、これらの選択されたアップデートのすべてがクライアントコンピューティングデバイス110に対して送信される。
【0071】
次いでメタデータサーバ123は、同期化応答1053中でこの選択されたアップデートをクライアントコンピューティングデバイス110に伝える。一般的に、各同期化応答は、このサーバ120が送信する各アップデートの命令コンポーネントを含んでいる。したがって、本実施例においては、第1の同期化応答1053は、911、912、913、914および915と呼ばれるこれらのアップデートについての命令コンポーネントを含んでいる。一実施形態においては、各同期化応答は、各アップデートの局所的データコンポーネントまたはデータコンポーネントを含んでいない。
【0072】
次に、ブロック1054に示すように、クライアントコンピューティングデバイス110は、各受信済みのアップデートの命令コンポーネントを処理してこの適用規則で定義される条件を満たすことができるかどうかを判定する。再度図9を参照すると、このクライアントコンピューティングデバイス110は、受信されたアップデート911〜915の命令コンポーネントを処理する。本発明を例示するために、クライアントコンピューティングデバイス110のオペレーティングシステムは、Windows(登録商標)バージョンXP SP1の英語のインストレーションであることがこの実施例において想定されている。また、クライアントコンピューティングデバイス110は、DellのPCであり、32ビットのX86プロセッサを作動させていることも想定されている。したがって、このサンプルの1組のアップデートの命令コンポーネントの処理においては、このコンピュータが英語のOSを含んでいるので、クライアントコンピューティングデバイス110は、第1のアップデート911中で定義される条件が満たされるはずであると判定するはずである。このオペレーティングシステムがWindows(登録商標)バージョンXP SP1であるので、この第2のアップデート912中で定義される条件も満たされるはずである。クライアントコンピューティングデバイス110が、X86プロセッサを作動させているのでこの第3のアップデート913中で定義される条件も満たされるはずである。クライアントコンピューティングデバイス110がDellのPCであるので第5のアップデート915中で定義される条件も満たされるはずである。その結果、第1のアップデート911、第2のアップデート912、第3のアップデート913、および第5のアップデート915はすべて、このクライアントのアップデートキャッシュの第1のコンポーネントに保存される。クライアントコンピューティングデバイス110は64ビットのX86プロセッサを作動させていないので第4のアップデート914中で定義される条件は、満たされないはずである。したがって、この第4のアップデート914は、失敗したアップデートであると考えられ、このクライアントのアップデートキャッシュの第2のコンポーネントに保存される。
【0073】
図10に戻ると、ブロック1054の処理において、クライアントコンピューティングデバイス110はまた、後続の同期化要求が必要とされるかどうかを判定する。一実施形態においては、少なくとも1つのこの受信済みのアップデートが、それがLEAFアップデートではないことを示す場合、後続の同期化要求が必要であることが決定される。本実施例においては、受信済みのアップデートのすべてがLEAFアップデートではないので、後続の同期化要求が必要とされることが決定される。したがって、クライアントコンピューティングデバイス110は、後続の同期化要求1055をメタデータサーバ123に伝える。
【0074】
以上で概要を述べたように、同期化要求は、このクライアントのアップデートキャッシュに記憶されるアップデートごとの識別子を含んでいる。したがって、本実施例において、後続の同期化要求855は、第1のアップデート711、第2のアップデート712、第3のアップデート713、および第5のアップデート715が、このクライアント上にインストールされていることを示す第1のデータコンポーネントを含んでいる。さらに、後続の同期化要求855は、第4のアップデート711が、このクライアント上に正常にインストールされていないことを示す第2のデータコンポーネントを含んでいる。
【0075】
後続の同期化要求1055を受信することに応答して、以上で概要を述べたように、メタデータサーバ123は、後続の同期化要求1055が、少なくとも1つのアップデート識別子を含むかどうかを判定する。後続の同期化要求が少なくとも1つのアップデート識別子を含むと判定された場合、メタデータサーバ123はすべての記憶されているアップデートの前提条件を検査してこのクライアントに配信するための追加のアップデートを選択する。
【0076】
再度本実施例を参照すると、ブロック856の処理において、その前提条件が満たされるので、メタデータサーバ123は、第6のアップデート921を選択するはずである。より詳細には、図9に示すように、第1のアップデート711、第2のアップデート912、および第3のアップデート913のインストレーションを必要とするその前提条件が満たされるので、第6のアップデート921が、クライアントコンピューティングデバイス110に伝えるために選択される。第7のアップデート922および第8のアップデート931は、これらの前提条件が満たされないので、このクライアントに伝えるために選択されないはずである。より詳細には、この同期化要求1055は、第7のアップデート922についての前提条件である、第4のアップデート914についての識別子を含んでいない。さらに、同期化要求855は、第8のアップデート931についての前提条件である第6のアップデート921についての識別子を含んでいない。
【0077】
図10に戻ると、同期化サブルーチン1050は、後続の応答1057において選択されたアップデートをメタデータサーバ123からクライアントコンピューティングデバイス110へと伝えることによって継続される。再度本実施例を参照すると、この後続の応答1057は、第6のアップデート721に関連した情報を含むはずであり、これは後続の応答1057においてクライアント110に伝えられる。
【0078】
後続の応答1057を受信すると、クライアントコンピューティングデバイス110は、後続の応答857の命令コンポーネントを処理する。ブロック854のプロセスと同様に、クライアントコンピューティングデバイス110は、各受信されたアップデートの命令コンポーネントを処理して、この適用規則中で定義される条件が満たされるかどうかを判定する。本実施例においては、XP PATCH1がこのクライアントコンピューティングデバイス中でインストールされると想定する場合に、第6のアップデート921は、インストールすべきと考えられ、このアップデートは、クライアントコンピューティングデバイス110のこのアップデートキャッシュに書き込まれる。この第6のアップデート921がLEAFアップデートではないので、クライアントコンピューティングデバイス110は、このクライアントのアップデートキャッシュの第1および第2のコンポーネントに記憶されるすべてのアップデートを含む別の同期化要求1060を送信する。この同期化要求1060も、許可サーバクッキーを含んでいる。
【0079】
本実施例においては、メタデータサーバ123の前述の処理を使用することによって、この同期化要求1060は、ブロック1061において処理され、ここでは、このサーバは、第8のアップデート731を選択する。この同期化要求1060は、第5および第6のアップデート915および921がクライアントコンピューティングデバイス110中にインストールされることを示すので、この第8のアップデート931が選択される。この第8のアップデート931は、この許可サーバクッキー中で識別される同じターゲットグループに関連することを想定すると、第8のアップデート931の命令コンポーネントが、別の応答1062中においてクライアントコンピューティングデバイス110に対して伝えられる。次いで、第8のアップデート931が、ブロック1054および1059のプロセスと同様にしてブロック1063において処理される。この応答1062の受信済みのアップデートがすべて、LEAFアップデートであるので、後続の同期化要求が、メタデータサーバ123に対して返信されない。
【0080】
クライアントコンピューティングデバイス110において、この受信済みのアップデートのすべてがLEAFアップデートであると判定された後に、またはアップデートが応答1062中で受信されない場合には、同期化サブルーチン1050は、クライアントコンピューティングデバイス110からメタデータサーバ123へとドライバ同期化要求1064を伝える。当業者には理解されるように、このドライバ同期化要求1064は、クライアントコンピューティングデバイス110中にインストールされるハードウェアをすべて記述する情報と、このインストール済みのソフトウェアを記述する情報を含むことができる。以前のソフトウェア同期化要求(1051、1055、および1060)と同様に、このドライバ同期化要求1064は、このインストール済みのアップデートをサーバに対して伝えることができる。さらに、このクライアント上に現在キャッシュされているすべてのドライバアップデートが、もしある場合には、このサーバに対して伝えられる。
【0081】
このドライバ同期化要求1064を受信することに応答して、メタデータサーバ123は、このクライアント上にまだキャッシュされていない、クライアントコンピューティングデバイス110に適用されるすべてのドライバアップデートを送信することによって応答する。その前提条件および条件が満たされる場合には、ドライバアップデートは、応答1065においてクライアントコンピューティングデバイス110に対して送信される。このドライバアップデートを伝える応答1065は、各アップデートの命令コンポーネントを伝えることが好ましい。次いでこのドライバアップデートは、このクライアントコンピューティングデバイスのアップデートキャッシュに書き込まれる。
【0082】
このドライバアップデートを含むこの応答1065を受信した後に、この同期化サブルーチン1050は、この受信済みのソフトウェアアップデートおよびハードウェアアップデートのそれぞれの局所的データを求める要求1066を送信する。以上で概要を述べたように、各アップデートの局所的データコンポーネントは、このアップデートを記述する一般的な情報を含んでいる。例えば、この局所的データコンポーネントは、このアップデートの特徴および利点を記述する情報を含むことができる。この局所的データコンポーネントはまた、このアップデートのインストレーションプロシージャのテキスト記述を含むこともできる。さらに、この局所的データコンポーネントは、このアップデートに関連した他の任意のデータまたは情報を含むこともできる。
【0083】
したがって、この受信済みのソフトウェアアップデートおよびハードウェアアップデートのそれぞれのこの局所的データを求める要求1066を受信すると、メタデータサーバ123は、このクライアントのこのアップデートキャッシュに保存されたすべてのこの受信済みのソフトウェアアップデートおよびハードウェアアップデートについてのすべての局所的データを送信することによって応答する。受信した後に、この局所的データをソフトウェアアプリケーションによって処理して、これらのアップデートのうちのどれをインストールする必要があるかを決定することができる。代わりに、この受信済みの局所的データをユーザに対して表示して、このクライアントコンピューティングデバイス110にとって使用可能なすべてのアップデートについてそのユーザに通知することができる。一実施形態においては、この受信済みの局所的データは、ウェブページ上に表示することが可能である。本実施例においては、局所的データは、第6および第8のアップデート921および931についてこのクライアントが受信することができる。局所的データがベースアップデート911、912、913、および915に記憶されている場合には、これらのアップデートについてのこの局所的データも、このクライアントは受信するはずである。
【0084】
図11は、このクライアントにとって使用可能なこれらのアップデートに関連する局所的データの一実施例を表示するウェブページ1100の一実施例を示している。図では、ウェブページ1100は、あるアップデートの第1の詳細な記述1105と、別のアップデートの第2の詳細な記述1106とを含んでいる。また図に示すように、各アップデートは、それぞれこれらのアップデートのユーザ選択を受け取るための選択メカニズム1103および1104に関連している。また図に示すように、ウェブページ1100は、ユーザが、メタデータサーバ123やダウンロードサーバ124などのサーバに対する、アップデートの選択の通信を制御できるようにする制御ボタン1101を用いて構成されている。
【0085】
本発明の一態様において、このクライアントは、いくつかのプロセスを実施してこのウェブページ1100の表示を拡張する。例えば、クライアントコンピューティングデバイス110は、各アップデートのこの局所的データを検査して、特定のアップデートが高優先順位であるかどうかを判定する。かかる特徴は、局所的データ中に、または特定のアップデートの他のコンポーネント中に、この特定のアップデートが高優先順位アップデートまたは緊急アップデートであることを示すテキストを見つけることによって実施することができる。クライアントコンピューティングデバイス110が高優先順位アップデートまたは緊急アップデート検出する場合には、このクライアントは、このページの最上部セクションなど、ウェブページ1100の可視セクションにこの高優先順位アップデートを表示する。さらに、このクライアントは、このアップデートが高優先順位アップデートであることを示す、専用化されたテキストメッセージ1120などの視覚インジケータを生成することができる。
【0086】
クライアントコンピューティングデバイス110はまた、各アップデートの局所的データを検査して、特定のアップデートが、排他的インストレーションを必要とするかどうか、すなわち別のアップデートのインストレーションファイルと同時にはインストールすることができないインストレーションファイルを有するアップデートであるかどうかを判定することができる。かかる特徴は、局所的データ中に、または特定のアップデートの他のコンポーネント中に、この特定のアップデートが排他的インストレーションを必要とすることを示すテキストを見つけることによって実施することができる。クライアントコンピューティングデバイス110が、かかるアップデートを検出する場合には、このクライアントは、排他的インストレーションを必要とするアップデートの記述を有する、図11に示すテキストメッセージ1122などの視覚インジケータを表示する。
【0087】
図7に戻ると、このソフトウェアアップデートルーチン700は、ブロック708で継続され、ここで、クライアントコンピューティングデバイス110は、これらのアップデートの選択を受け取る。以上で指摘したように、制御ボタン1101の動作に応答して、1つまたは複数のアップデートの選択をメタデータサーバ123またはダウンロードサーバ124が取得することが可能である。1つまたは複数のアップデートの選択を受け取った後に、このソフトウェアアップデートルーチン700は、ブロック708で継続され、ここでこの選択されたソフトウェアアップデートが処理される。
【0088】
本発明のさらに他の態様によれば、ソフトウェアアップデートサービス120は、このソフトウェアアップデートサービスとクライアントコンピューティングデバイス110の間で情報を選択し伝送する方法を提供することができる。図12Aおよび12Bは、本発明による、要求されたソフトウェアを検索しインストールするための、クライアントコンピューティングデバイス110によって実施されるソフトウェアアップデート処理サブルーチン1200を示している。前述のように、このソフトウェアアップデート処理サブルーチン1200は、ソフトウェアアップデートの選択が生成され受信された後に実施することができる。図12Aを参照すると、ブロック1202において、アップデート管理コンポーネント111が、アップデートエージェント118をインスタンス化する。本発明の例示の一実施形態において、このアップデートエージェント118は、要求されたソフトウェアアップデートを完了するため、このアップデートエージェントのインストレーションコンポーネントの要求されたバージョンを生成するため、既存のファイルをデルタパッチとマージすることによってアップデートされたファイルを生成するため、および/またはアップデートされたファイルのインストレーションを開始するために、どのようなソフトウェアアップデート情報が必要とされるかを決定するための専用ソフトウェアコンポーネントである。アップデートエージェント118が、すでにインスタンス化されている場合には、ブロック1202は、省略することができる。
【0089】
ブロック1204において、アップデートエージェント118は、アップデートサービス120からソフトウェアアップデート情報を取得する。本発明の例示の一実施形態においては、アップデートサービス120が送信するこのソフトウェアアップデート情報は、このアップデートエージェントが利用することができる様々なデータを含む、自己展開ファイルなどのパッケージの形態である。一態様によれば、このパッケージは、特定のソフトウェアアップデートに対応するすべてのファイルのリストを含むことが可能である。さらに、このパッケージは、アップデートすべき特定のバージョンのファイルをアップデートサービス120上のそのパッチストレージファイルに記憶される対応するソフトウェアアップデートデルタパッチに対してマッピングするパッチストレージマニフェストの少なくとも一部分のコピーを含むことが可能である。このパッケージはまた、このインストレーションを完了するために必要とされるインストレーションコンポーネントのバージョンの識別を含むことが可能な、アップデートすべきファイルごとのインストレーション情報を含むことも可能である。さらにこのパッケージはまた、アップデートエージェント118についてのインストレーションコンポーネントまたはクライアントコンピューティングデバイス110上にすでに記憶されているインストレーションコンポーネントのバージョンをアップデートするためのデルタパッチを含むことが可能である。さらにまた、このパッケージは、このアップデートエージェントにソフトウェアアップデートが正常であったかどうかを判定できるようにする検証情報を含むことが可能である。例えば、この検証情報は、比較するためのアップデートファイルについての基準ハッシュ値を含むことが可能である。このアップデートエージェント118は、パッケージのその内容を検証することもできる。
【0090】
判断ブロック1206において、テストを実施してアップデートエージェント118がアップデートを実施するためにこのインストレーションコンポーネントのバージョンをアップデートする必要があるかどうかを判定する。この自己展開ファイル中のインストレーションコンポーネントの完全なコピーの送信により、ソフトウェアアップデートごとの、アップデートサービス120が送信するデータ量を増大させる可能性があることが当業者には理解されよう。したがって本発明の例示の一実施形態においては、インストレーションコンポーネントのベースラインバージョンは、このクライアントコンピューティングデバイスに記憶し、インストレーションコンポーネントデルタパッチを介してこの現行のソフトウェアアップデートの要件について特にアップデートすることができる。したがって、この自己展開ファイル中のこのインストレーション情報は、クライアントコンピューティングデバイス110上において、含められた任意のインストレーションコンポーネントアップデートをこのインストレーションコンポーネントのこのベースラインバージョンとマージする必要があるか否かをアップデートエージェント118に指示する。アップデートが必要とされる場合、図13に関して以下でさらに非常に詳細に説明するように、ブロック1208において、アップデートエージェント118は、このベースラインインストレーションコンポーネント(baseline installation component)をアップデートする。
【0091】
このアップデートエージェントがこのインストレーションコンポーネントをアップデートした後に、またはこのインストレーションコンポーネントが、アップデートを必要としない場合には、ブロック1210において、アップデートエージェント118は、クライアントコンピューティングデバイス110上にインストールされたファイル、およびこの特定のバージョンのファイルのインベントリを実施する。本発明の例示の一実施形態において、アップデートエージェント118は、この選択されたアップデートに対応するものとしてこのパッケージ中で識別されたすべてのファイルについてクライアントコンピューティングデバイス110のファイルシステムに照会することができる。代わりに、アップデートエージェント118が、最近インベントリを実施したことがある場合には、このインベントリのキャッシュされたバージョンを利用することができる。ブロック1212において、アップデートエージェント118は、この要求されたアップデートを完了するためにどのようなソフトウェアアップデート情報が必要とされるかを識別する。本発明の例示の一実施形態において、そのパッチストレージマニフェストは、必要とされるデルタパッチに対するインストール済みのファイルのバージョンのマッピングを含んでいる。したがって、デルタパッチングが利用可能な場合、アップデートエージェント118は、このマッピングを利用してこのパッチストレージファイル内の特定のデルタパッチおよびそのオフセットロケーションを識別することになる。代わりに、デルタパッチが利用可能でなく実施できない場合には、アップデートエージェント118は、ダウンロードするために全体のファイルを識別することができる。
【0092】
次に図12Bを参照すると、ブロック1214において、このアップデートデートエージェント(update date agent)は、識別されたソフトウェアアップデート情報を求める要求を送信する。本発明の例示の一実施形態において、アップデートエージェント118は、このアップデートサービス120のダウンロードサーバ124に対してこのパッチストレージファイルから必要とされる特定の範囲のパッチを示すことによって特定のデルタパッチを求める要求を送信することができる。前述のように、このパッチストレージファイルは、各デルタパッチがそのパッチストレージファイルに伴うそのロケーションによって識別される多数の適用可能デルタパッチを含んでいる。このパッチストレージファイルが一部の実施形態ではかなり大きいこともあるので、アップデートエージェント118は、このパッチストレージマニフェストから指示されるように、このパッチストレージファイル中の特定のロケーションからのデータだけしか求めない要求を利用することができる。本発明の代替実施形態においては、アップデートエージェント118は、アップデートファイルの全体コピーおよび/またはこのパッチストレージファイルの完全コピーを要求することができる。
【0093】
本発明の代替実施形態においては、アップデートサービス120に排他的に関連づけることができない別のダウンロードサーバが、このアップデートエージェント118の要求を処理することができる。この実施形態においては、この要求パッチストレージファイルは、全部または一部分をネットワーク上で任意の数の追加のダウンロードサーバに対して伝送することができる。この追加のダウンロードサーバは、プライベートネットワーク上でクライアントをアップデートするために利用されるプライベートネットワークの一部分とすることができる。さらに、この追加のダウンロードサーバは、パブリックネットワークの一部分とすることができる。プライベートネットワーク環境においては、これらのダウンロードサーバは、クライアント要求を処理するためのパッチストレージファイルの完全コピーを取得することができる。代わりに、ダウンロードサーバは、他のクライアントからの以前のデータ要求を処理する際にこのパッチストレージファイルの一部分をキャッシュすることもでき、このキャッシュデータを利用してこのダウンロードを履行することができる。したがって、この追加のダウンロードサーバは、アップデートサービス120のダウンロードサーバ124上における通信歪み(communication strain)を低減することが可能である。
【0094】
ブロック1216において、アップデートエージェント118は、この要求されたアップデート情報を受信する。本発明の例示の一実施形態においては、この要求されたアップデート情報は、2つのアプローチで伝送することができる。手動アップデートと呼ばれる第1のアプローチでは、このアップデート要求は、直接HTTPデータ配信応答(direct HTTP data delivery response)を求める要求と共にアップデートサービス120に対して送信される。このアプローチにおいては、アップデートサービス120は、使用可能な全帯域幅のすべてを利用してこの要求されたデータをアップデートエージェント118に対して送信することができる。自動アップデートと呼ばれる第2のアプローチでは、このアップデート要求は、間接HTTPデータ配信応答(indirect HTTP data delivery response)を求める要求と共にアップデートサービス120に対して送信される。この応答においては、アップデートサービス120は、この要求されたデータをバックグラウンドプロセス(background process)として送信する。このバックグラウンドプロセスは、使用可能な帯域幅の最小量を利用するようにして実施することができる。さらに、このバックグラウンドプロセスは、このダウンロードプロセス中に中断し、次に利用可能な時に再開することができる。バックグラウンドプロセスを介して要求されたデータを伝送するためのシステムおよび方法についての説明は、参照により本明細書中に組み込まれている、2000年2月16日に出願の「System and Method for Transferring Data Over a Network」という名称の同一出願人による同時係属の米国特許出願第09/505,735号明細書中に説明されている。フォアグラウンドまたはバックグラウンドのデータ配信は、この選択されたソフトウェアアップデートの優先順位を必ずしも反映したものではなく、代わりにこのアップデート情報を取得するためにどのようにして帯域幅が割り付けられるかを反映したものであることが当業者には理解されよう。
【0095】
要求された情報をこのアップデートサービスから受信した後に、ブロック1218において、アップデートエージェント118は、このデルタパッチをこの対応するインストール済みのファイルとマージする。本発明の例示の一実施形態においては、アップデートエージェント118は、このインストール済みのファイルの元のバージョンをキャッシュして、この選択されたファイルがこのダウンロードおよびマージングプロセス中に変化しないようにする。さらに、このインストール済みのファイルのキャッシュされた元のバージョンを使用してこの選択されたアップデートをアンインストール(uninstall)することができる。
【0096】
判断ブロック1220において、テストを実施してこのアップデートされたファイルが有効であるかどうかを判定する。本発明の例示の一実施形態においては、アップデートエージェント118は、ハッシングアルゴリズムを利用して、アップデート情報パッケージから得られ、有効なファイルアップデートに対応する基準ハッシュ値を現在の修正されたファイルからのハッシュと比較することができる。これらのハッシュがマッチングしない場合、現行の修正ファイルは有効ではない。いくつかの代替の妥当性検査アルゴリズムのうち任意の1つを利用することもできることが当業者には理解されよう。このアップデートファイルが有効でない場合には、このサブルーチン1200はブロック1214に戻り、ここでこのアップデートエージェントは、アップデート情報を再度要求することができる。代わりに、アップデートエージェント118が、このアップデートファイルを数回にわたって生成しようと試みてもうまくいかない場合には、このアップデートエージェントは、いくつかのフォールバックプロシージャ(fallback procedure)の1つを実施することができる。本発明の一実施形態において、このアップデートエージェント118は、このパッチストレージファイルに記憶されこのパッチストレージマニフェストから識別されたアップデートファイルの完全コピーをアップデートサービス120から要求することができる。本発明の他の実施形態においては、アップデートエージェント118は、アップデートサービス120から自己完結型のファイル中のこのアップデートファイルのコピーを要求することができる。本発明のさらに他の実施形態においてサブルーチン1200は、その他の場合には失敗することもある。
【0097】
この選択されたファイルが有効になった後に、判断ブロック1222において、テストを実施して追加のダウンロードが何か必要とされるかどうかを判定する。本発明の例示の一実施形態においては、サブルーチン1200は、以前に選択されたダウンロードの終了後に追加のダウンロードがあるかについて絶えずチェックする反復ループに入る。このダウンロード中にファイルの状態が変化する場合、アップデートエージェント118は、この新しい状態変化について追加のダウンロードを要求し続けるはずである。追加のダウンロードが必要とされる場合には、ブロック1224において、アップデートエージェント118は、別のインベントリを実施し、すべての適用可能なデルタパッチを識別する。次いでこのサブルーチン1200はブロック1214へと戻る。
【0098】
すべてのこの要求されたアップデートのダウンロードが完了した後に、判断ブロック1226において、テストを実施して、このクライアントマシンの状態が変化しているかどうかを判定する。本発明の例示の一実施形態においては、アップデート情報のダウンロードおよびマージングと、このアップデートされたファイルの実際のインストレーションの間で時間が経過してしまうこともある。したがってこのアップデートファイルをインストールするのに先立ってこのアップデートエージェントは、このクライアントコンピューティングデバイス状態が変化しているかどうかを判定する。この状態が変化している場合には、このファイルアップデートは有効でないこともあり、このアップデートはブロック1228において失敗する。代わりに、状態の変化が起こっていなければ、アップデートエージェント118は、ブロック1230においてこのアップデートされたファイルをインストールし、サブルーチン1200は、ブロック1232において戻る。
【0099】
次に図13を参照して、ブロック1208(図12A)に対応するベースラインインストレーションコンポーネントをアップデートするための、クライアントコンピューティングデバイス110によって実施されるサブルーチン1300について説明することにする。判断ブロック1302において、テストを実施して新しいベースラインインストレーションコンポーネントが、アップデートサービス120からアップデートエージェント118に伝送される自己展開ファイル中に含まれるかどうかを判定する。本発明の例示の一実施形態において、このベースラインインストーラ(baseline installer)をアップデートするために必要とされるデルタパッチが、アップデートされたインストレーションコンポーネントの伝送とサイズが同等である場合、新しいベースラインインストレーションコンポーネントが伝送されることになる。アップデートされたインストレーションコンポーネントが含まれる場合には、ブロック1304において、このアップデートエージェントは、このアップデートされたベースラインインストレーションコンポーネントを新しいインストレーションコンポーネントとしてインストールする。さらに、この新しいアップデートされたインストレーションコンポーネントは、クライアントコンピューティングデバイス110のメモリに保存されて追加のアップデートについてのベースラインインストーラとしての役割を果たすことができる。ブロック1306においてこのサブルーチンは戻る。
【0100】
アップデートされたベースラインインストレーションコンポーネントが、この自己展開ファイル中に含まれていない場合には、ブロック1308においてアップデートエージェント118は、この自己展開ファイルからベースラインインストレーションコンポーネントデルタパッチを取得する。本発明の例示の一実施形態において、このベースラインインストレーションコンポーネントデルタパッチは、このベースラインインストレーションコンポーネントとマージされてアップデートされたベースラインインストレーションコンポーネントを生成することができるソフトウェアコードに対応する。したがって、ブロック1310において、このアップデートエージェントは、このベースラインインストレーションコンポーネントデルタパッチをこのベースラインインストレーションコンポーネントとマージする。ブロック1312において、次いでアップデートエージェント118は、このアップデートされたベースラインインストレーションコンポーネントを現在のインストレーションコンポーネントとして指定する。本発明の例示の一実施形態において、このインストレーションが完了した後にはこのアップデートされたインストレーションコンポーネントは、保存されないことになる。この実施形態によれば、アップデートエージェント118は、クライアントコンピューティングデバイス110のメモリ中に限られた数のベースラインインストレーションコンポーネントしか保持しない。したがって、このアップデートエージェントは、インストレーションごとに、一時的なアップデートされたインストレーションコンポーネントを生成する。各クライアントコンピューティングデバイス110は、限られた数のベースラインインストレーションコンポーネントにしか対応することができないので、アップデートサービス120には、クライアントコンピューティングデバイスごとに1つのベースラインインストレーションコンポーネントデルタパッチを伝送する必要があるだけである。ブロック1314において、このサブルーチン1300は、戻る。
【0101】
本発明の好ましい実施形態について示し説明してきたが、本発明の趣旨および範囲を逸脱することなく様々な変更をここで行うことができることが理解されよう。例えば、本明細書中で説明した例示の実施例は、ソフトウェアアップデートに適用されるが、本発明の範囲は、ソフトウェアアップデートに関連した情報の配信および通信以外の他の使用を含んでいる。したがって、特定の主題がこの開示中において明確に除外されない限り、本発明の範囲が、ソフトウェアアップデート以外の、またはソフトウェアアップデートに追加の任意タイプのデータの配信および通信に適用されることを理解されたい。
【特許請求の範囲】
【請求項1】
クライアントコンピューティングデバイス上のファイルのアップデートを管理するための方法であって、
(a)利用可能なアップデートをアップデートサービスとコンピュータにより同期させるステップであって、該同期させるステップはソフトウェアアップデート階層を調べて前記クライアントコンピューティングデバイスに対して適用する特定のソフトウェアアップデートを識別するステップと含み、前記ソフトウェアアップデート階層は少なくとも1つまたは複数のベースのアップデートの第1のセットと、1つまたは複数の依存のアップデートの第2のセットとを含み、
(i)各ベースのアップデートは前記コンピューティングデバイスに前記ベースのアップデートを適用可能であるか否かを前記コンピューティングデバイスにおいて判定するための1つまたは複数の適用条件を含み、
(ii)前記各依存のアップデートは、
(a)前記コンピューティングデバイスに前記依存のアップデートを適用可能であるか否かを前記コンピューティングデバイスにおいて判定するための1つまたは複数の提供条件と、
(b)前記依存のアップデートを適切にインストールするために必要な1つまたは複数のベースのアップデートを示す必要条件と、
(c)前記依存のアップデートがLEAFのアップデートであるかを示す識別情報と
を含む、同期させるステップと、
(b)前記クライアントコンピューティングデバイスに対して適用可能と識別された1つまたは複数の特定のソフトウェアアップデートの中の1つまたは複数のソフトウェアアップデートの選択を前記コンピュータにより受け取るステップと、
(c)前記選択のソフトウェアアップデートおよびインストール情報を含む自己展開ファイルを前記コンピュータにより取得するステップであって、前記インストール情報は前記コンピューティングデバイスに記憶されているベースラインインストレーションコンポーネントを示し、前記ベースラインインストレーションコンポーネントは前記クライアントコンピューティングデバイス上に前記ソフトウェアアップデートをインストールするために必要なコンポーネントである、取得するステップと、
(d)前記クライアントコンピューティングデバイス上に記憶されている必要なベースラインインストレーションコンポーネントを前記コンピュータにより選択するステップと、
(e)前記クライアントコンピューティングデバイス上に記憶されている当該必要なベースラインインストレーションコンポーネントをアップデートする必要があるか否かを前記コンピュータにより判定するステップと、
(f)前記自己展開ファイルが、新しいベースラインインストレーションコンポーネントおよび前記クライアントコンピューティングデバイス上に記憶されている必要なベースラインインストレーションコンポーネントをアップデートするインストレーションコンポーネントデルタパッチを含むか否かを前記コンピュータにより判定し、
(g)前記新しいベースラインインストレーションコンポーネントが前記自己展開ファイルの中に含まれていない場合には、前記コンピューティングデバイス上に記憶されている必要なベースラインインストレーションコンポーネントをアップデートするための前記インストレーションコンポーネントデルタパッチを前記コンピュータにより取得し、当該前記インストレーションコンポーネントデルタパッチと前記必要なベースラインインストレーションコンポーネントをマージしてマージのインストレーションコンポーネントを前記コンピュータにより作成するステップと、
(h)(i)前記クライアントコンピューティングデバイス上にインストールされているファイルのインベントリを前記コンピュータにより実施し、
(ii)前記インストールのファイルをアップデートするのに必要な全てのデルタパッチを前記コンピュータにより識別し、
(iii)当該識別された全ての適用可能なデルタパッチを前記コンピュータにより取得し、
(iv)当該識別された全ての適用可能なデルタパッチと、対応のインストールのファイルとを前記コンピュータによりマージする
ことにより、前記選択のソフトウェアアップデートをクライアントコンピューティングデバイス上に前記マージのインストレーションコンポーネントを使用してインストールするステップと
を有することを特徴とする方法。
【請求項2】
前記選択のソフトウェアアップデートは前記クライアントコンピューティングデバイス上にインストールすべき1つまたは複数のファイルを含むことを特徴とする請求項1に記載の方法。
【請求項3】
前記ベースラインインストレーションコンポーネントを示すインストレーション情報は前記ベースラインインストレーションコンポーネントの特定のバージョン示す情報を含むことを特徴とする請求項1に記載の方法。
【請求項4】
前記選択のソフトウェアアップデートを前記クライアントコンピューティングデバイス上にインストールしたときに前記マージのインストレーションコンポーネントを前記コンピュータにより削除するステップをさらに有することを特徴とする請求項1に記載の方法。
【請求項5】
前記自己展開ファイルが新しいベースラインインストレーションコンポーネントを含む場合当該新しいベースラインインストレーションコンポーネントを前記コンピュータにより取得するステップと、当該新しいベースラインインストレーションコンポーネントを前記クライアントコンピューティングデバイス上に前記コンピュータによりインストールするステップをさらに有することを特徴とする請求項1に記載の方法。
【請求項6】
前記ベースラインインストレーションコンポーネントは複数のベースラインインストレーションコンポーネントのセットから前記コンピュータにより選択され、当該複数のベースラインインストレーションコンポーネントのセットはバージョンにしたがって編成され、前記選択のベースラインインストレーションコンポーネントは前記複数のベースラインインストレーションコンポーネントのセットから選択したベースラインインストレーションコンポーネントの特定のバージョンを示す情報を含むことを特徴とする請求項1に記載の方法。
【請求項7】
前記利用可能なアップデートの同期に先立って、前記コンピュータが拡張ターゲッティングメカニズムを使用して前記クライアントコンピューティングデバイスのソフトウェアの前記利用可能なアップデートに対するアクセスを制御するステップであって、利用可能なアップデートのそれぞれと関連付けられた少なくとも1つのターゲットグループ内に前記クライアントコンピューティングデバイスが含まれているかの判定を拡張ターゲッティングメカニズムにより行う制御するステップをさらに有することを特徴とする請求項1に記載の方法。
【請求項8】
クライアントコンピューティングデバイスのコンピュータにより使用され該クライアントコンピューティングデバイス上のファイルのアップデートを管理するための方法を実行するためのコンピュータプログラムであって、該コンピュータプログラムは前記コンピュータに、
(a)利用可能なアップデートをアップデートサービスとコンピュータにより同期させるステップであって、該同期させるステップはソフトウェアアップデート階層を調べて前記クライアントコンピューティングデバイスに対して適用する特定のソフトウェアアップデートを識別するステップと含み、前記ソフトウェアアップデート階層は少なくとも1つまたは複数のベースのアップデートの第1のセットと、1つまたは複数の依存のアップデートの第2のセットとを含み、
(i)各ベースのアップデートは前記コンピューティングデバイスに前記ベースのアップデートを適用可能であるか否かを前記コンピューティングデバイスにおいて判定するための1つまたは複数の適用条件を含み、
(ii)前記各依存のアップデートは、
(a)前記コンピューティングデバイスに前記依存のアップデートを適用可能であるか否かを前記コンピューティングデバイスにおいて判定するための1つまたは複数の提供条件と、
(b)前記依存のアップデートを適切にインストールするために必要な1つまたは複数のベースのアップデートを示す必要条件と、
(c)前記依存のアップデートがLEAFのアップデートであるかを示す識別情報と
を含む、同期させるステップと、
(b)前記クライアントコンピューティングデバイスに対して適用可能と識別された1つまたは複数の特定のソフトウェアアップデートの中の1つまたは複数のソフトウェアアップデートの選択を前記コンピュータにより受け取るステップと、
(c)前記選択のソフトウェアアップデートおよびインストール情報を含む自己展開ファイルを前記コンピュータにより取得するステップであって、前記インストール情報は前記コンピューティングデバイスに記憶されているベースラインインストレーションコンポーネントを示し、前記ベースラインインストレーションコンポーネントは前記クライアントコンピューティングデバイス上に前記ソフトウェアアップデートをインストールするために必要なコンポーネントである、取得するステップと、
(d)前記クライアントコンピューティングデバイス上に記憶されている必要なベースラインインストレーションコンポーネントを前記コンピュータにより選択するステップと、
(e)前記クライアントコンピューティングデバイス上に記憶されている当該必要なベースラインインストレーションコンポーネントをアップデートする必要があるか否かを前記コンピュータにより判定するステップと、
(f)前記自己展開ファイルが、新しいベースラインインストレーションコンポーネントおよび前記クライアントコンピューティングデバイス上に記憶されている必要なベースラインインストレーションコンポーネントをアップデートするインストレーションコンポーネントデルタパッチを含むか否かを前記コンピュータにより判定し、
(g)前記新しいベースラインインストレーションコンポーネントが前記自己展開ファイルの中に含まれていない場合には、前記コンピューティングデバイス上に記憶されている必要なベースラインインストレーションコンポーネントをアップデートするための前記インストレーションコンポーネントデルタパッチを前記コンピュータにより取得し、当該前記インストレーションコンポーネントデルタパッチと前記必要なベースラインインストレーションコンポーネントをマージしてマージのインストレーションコンポーネントを前記コンピュータにより作成するステップと、
(h)(i)前記クライアントコンピューティングデバイス上にインストールされているファイルのインベントリを前記コンピュータにより実施し、
(ii)前記インストールのファイルをアップデートするのに必要な全てのデルタパッチを前記コンピュータにより識別し、
(iii)当該識別された全ての適用可能なデルタパッチを前記コンピュータにより取得し、
(iv)当該識別された全ての適用可能なデルタパッチと、対応のインストールのファイルとを前記コンピュータによりマージする
ことにより、前記選択のソフトウェアアップデートをクライアントコンピューティングデバイス上に前記マージのインストレーションコンポーネントを使用してインストールするステップと
を実行させることを特徴とするコンピュータプログラム。
【請求項1】
クライアントコンピューティングデバイス上のファイルのアップデートを管理するための方法であって、
(a)利用可能なアップデートをアップデートサービスとコンピュータにより同期させるステップであって、該同期させるステップはソフトウェアアップデート階層を調べて前記クライアントコンピューティングデバイスに対して適用する特定のソフトウェアアップデートを識別するステップと含み、前記ソフトウェアアップデート階層は少なくとも1つまたは複数のベースのアップデートの第1のセットと、1つまたは複数の依存のアップデートの第2のセットとを含み、
(i)各ベースのアップデートは前記コンピューティングデバイスに前記ベースのアップデートを適用可能であるか否かを前記コンピューティングデバイスにおいて判定するための1つまたは複数の適用条件を含み、
(ii)前記各依存のアップデートは、
(a)前記コンピューティングデバイスに前記依存のアップデートを適用可能であるか否かを前記コンピューティングデバイスにおいて判定するための1つまたは複数の提供条件と、
(b)前記依存のアップデートを適切にインストールするために必要な1つまたは複数のベースのアップデートを示す必要条件と、
(c)前記依存のアップデートがLEAFのアップデートであるかを示す識別情報と
を含む、同期させるステップと、
(b)前記クライアントコンピューティングデバイスに対して適用可能と識別された1つまたは複数の特定のソフトウェアアップデートの中の1つまたは複数のソフトウェアアップデートの選択を前記コンピュータにより受け取るステップと、
(c)前記選択のソフトウェアアップデートおよびインストール情報を含む自己展開ファイルを前記コンピュータにより取得するステップであって、前記インストール情報は前記コンピューティングデバイスに記憶されているベースラインインストレーションコンポーネントを示し、前記ベースラインインストレーションコンポーネントは前記クライアントコンピューティングデバイス上に前記ソフトウェアアップデートをインストールするために必要なコンポーネントである、取得するステップと、
(d)前記クライアントコンピューティングデバイス上に記憶されている必要なベースラインインストレーションコンポーネントを前記コンピュータにより選択するステップと、
(e)前記クライアントコンピューティングデバイス上に記憶されている当該必要なベースラインインストレーションコンポーネントをアップデートする必要があるか否かを前記コンピュータにより判定するステップと、
(f)前記自己展開ファイルが、新しいベースラインインストレーションコンポーネントおよび前記クライアントコンピューティングデバイス上に記憶されている必要なベースラインインストレーションコンポーネントをアップデートするインストレーションコンポーネントデルタパッチを含むか否かを前記コンピュータにより判定し、
(g)前記新しいベースラインインストレーションコンポーネントが前記自己展開ファイルの中に含まれていない場合には、前記コンピューティングデバイス上に記憶されている必要なベースラインインストレーションコンポーネントをアップデートするための前記インストレーションコンポーネントデルタパッチを前記コンピュータにより取得し、当該前記インストレーションコンポーネントデルタパッチと前記必要なベースラインインストレーションコンポーネントをマージしてマージのインストレーションコンポーネントを前記コンピュータにより作成するステップと、
(h)(i)前記クライアントコンピューティングデバイス上にインストールされているファイルのインベントリを前記コンピュータにより実施し、
(ii)前記インストールのファイルをアップデートするのに必要な全てのデルタパッチを前記コンピュータにより識別し、
(iii)当該識別された全ての適用可能なデルタパッチを前記コンピュータにより取得し、
(iv)当該識別された全ての適用可能なデルタパッチと、対応のインストールのファイルとを前記コンピュータによりマージする
ことにより、前記選択のソフトウェアアップデートをクライアントコンピューティングデバイス上に前記マージのインストレーションコンポーネントを使用してインストールするステップと
を有することを特徴とする方法。
【請求項2】
前記選択のソフトウェアアップデートは前記クライアントコンピューティングデバイス上にインストールすべき1つまたは複数のファイルを含むことを特徴とする請求項1に記載の方法。
【請求項3】
前記ベースラインインストレーションコンポーネントを示すインストレーション情報は前記ベースラインインストレーションコンポーネントの特定のバージョン示す情報を含むことを特徴とする請求項1に記載の方法。
【請求項4】
前記選択のソフトウェアアップデートを前記クライアントコンピューティングデバイス上にインストールしたときに前記マージのインストレーションコンポーネントを前記コンピュータにより削除するステップをさらに有することを特徴とする請求項1に記載の方法。
【請求項5】
前記自己展開ファイルが新しいベースラインインストレーションコンポーネントを含む場合当該新しいベースラインインストレーションコンポーネントを前記コンピュータにより取得するステップと、当該新しいベースラインインストレーションコンポーネントを前記クライアントコンピューティングデバイス上に前記コンピュータによりインストールするステップをさらに有することを特徴とする請求項1に記載の方法。
【請求項6】
前記ベースラインインストレーションコンポーネントは複数のベースラインインストレーションコンポーネントのセットから前記コンピュータにより選択され、当該複数のベースラインインストレーションコンポーネントのセットはバージョンにしたがって編成され、前記選択のベースラインインストレーションコンポーネントは前記複数のベースラインインストレーションコンポーネントのセットから選択したベースラインインストレーションコンポーネントの特定のバージョンを示す情報を含むことを特徴とする請求項1に記載の方法。
【請求項7】
前記利用可能なアップデートの同期に先立って、前記コンピュータが拡張ターゲッティングメカニズムを使用して前記クライアントコンピューティングデバイスのソフトウェアの前記利用可能なアップデートに対するアクセスを制御するステップであって、利用可能なアップデートのそれぞれと関連付けられた少なくとも1つのターゲットグループ内に前記クライアントコンピューティングデバイスが含まれているかの判定を拡張ターゲッティングメカニズムにより行う制御するステップをさらに有することを特徴とする請求項1に記載の方法。
【請求項8】
クライアントコンピューティングデバイスのコンピュータにより使用され該クライアントコンピューティングデバイス上のファイルのアップデートを管理するための方法を実行するためのコンピュータプログラムであって、該コンピュータプログラムは前記コンピュータに、
(a)利用可能なアップデートをアップデートサービスとコンピュータにより同期させるステップであって、該同期させるステップはソフトウェアアップデート階層を調べて前記クライアントコンピューティングデバイスに対して適用する特定のソフトウェアアップデートを識別するステップと含み、前記ソフトウェアアップデート階層は少なくとも1つまたは複数のベースのアップデートの第1のセットと、1つまたは複数の依存のアップデートの第2のセットとを含み、
(i)各ベースのアップデートは前記コンピューティングデバイスに前記ベースのアップデートを適用可能であるか否かを前記コンピューティングデバイスにおいて判定するための1つまたは複数の適用条件を含み、
(ii)前記各依存のアップデートは、
(a)前記コンピューティングデバイスに前記依存のアップデートを適用可能であるか否かを前記コンピューティングデバイスにおいて判定するための1つまたは複数の提供条件と、
(b)前記依存のアップデートを適切にインストールするために必要な1つまたは複数のベースのアップデートを示す必要条件と、
(c)前記依存のアップデートがLEAFのアップデートであるかを示す識別情報と
を含む、同期させるステップと、
(b)前記クライアントコンピューティングデバイスに対して適用可能と識別された1つまたは複数の特定のソフトウェアアップデートの中の1つまたは複数のソフトウェアアップデートの選択を前記コンピュータにより受け取るステップと、
(c)前記選択のソフトウェアアップデートおよびインストール情報を含む自己展開ファイルを前記コンピュータにより取得するステップであって、前記インストール情報は前記コンピューティングデバイスに記憶されているベースラインインストレーションコンポーネントを示し、前記ベースラインインストレーションコンポーネントは前記クライアントコンピューティングデバイス上に前記ソフトウェアアップデートをインストールするために必要なコンポーネントである、取得するステップと、
(d)前記クライアントコンピューティングデバイス上に記憶されている必要なベースラインインストレーションコンポーネントを前記コンピュータにより選択するステップと、
(e)前記クライアントコンピューティングデバイス上に記憶されている当該必要なベースラインインストレーションコンポーネントをアップデートする必要があるか否かを前記コンピュータにより判定するステップと、
(f)前記自己展開ファイルが、新しいベースラインインストレーションコンポーネントおよび前記クライアントコンピューティングデバイス上に記憶されている必要なベースラインインストレーションコンポーネントをアップデートするインストレーションコンポーネントデルタパッチを含むか否かを前記コンピュータにより判定し、
(g)前記新しいベースラインインストレーションコンポーネントが前記自己展開ファイルの中に含まれていない場合には、前記コンピューティングデバイス上に記憶されている必要なベースラインインストレーションコンポーネントをアップデートするための前記インストレーションコンポーネントデルタパッチを前記コンピュータにより取得し、当該前記インストレーションコンポーネントデルタパッチと前記必要なベースラインインストレーションコンポーネントをマージしてマージのインストレーションコンポーネントを前記コンピュータにより作成するステップと、
(h)(i)前記クライアントコンピューティングデバイス上にインストールされているファイルのインベントリを前記コンピュータにより実施し、
(ii)前記インストールのファイルをアップデートするのに必要な全てのデルタパッチを前記コンピュータにより識別し、
(iii)当該識別された全ての適用可能なデルタパッチを前記コンピュータにより取得し、
(iv)当該識別された全ての適用可能なデルタパッチと、対応のインストールのファイルとを前記コンピュータによりマージする
ことにより、前記選択のソフトウェアアップデートをクライアントコンピューティングデバイス上に前記マージのインストレーションコンポーネントを使用してインストールするステップと
を実行させることを特徴とするコンピュータプログラム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12A】
【図12B】
【図13】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12A】
【図12B】
【図13】
【公開番号】特開2011−181097(P2011−181097A)
【公開日】平成23年9月15日(2011.9.15)
【国際特許分類】
【出願番号】特願2011−109922(P2011−109922)
【出願日】平成23年5月16日(2011.5.16)
【分割の表示】特願2006−543795(P2006−543795)の分割
【原出願日】平成16年7月23日(2004.7.23)
【出願人】(500046438)マイクロソフト コーポレーション (3,165)
【Fターム(参考)】
【公開日】平成23年9月15日(2011.9.15)
【国際特許分類】
【出願日】平成23年5月16日(2011.5.16)
【分割の表示】特願2006−543795(P2006−543795)の分割
【原出願日】平成16年7月23日(2004.7.23)
【出願人】(500046438)マイクロソフト コーポレーション (3,165)
【Fターム(参考)】
[ Back to top ]