JP2008521094A - プロビジョニングパケットを配信するためのシステムおよび方法 - Google Patents

Abstract

ソフトウェアを提供する方法および装置は、データベースと、配信サービスと、確認サービスとを有するプロビジョニングパケット配信メカニズムを使用して、コンピュータへのプロビジョニングパケットの配信を受信し、待ち行列に入れ、確認する。確認応答のない配信要求の数が、ある限度を超えると、配信サービスは、たとえばサービス拒否の攻撃を制限するために、そのプロビジョニングパケットをデータベースから削除することができる。

Description

本特許は、一般にコンピュータに関し、より詳細にはコンピュータ管理システムに関する。

世界の人口の大きな割合は、コンピュータ、および／またはそのコンピュータを効率よく使用できるようにするさまざまなソフトウェアを所有するだけの経済的な余裕がない。発展途上国の人々にコンピューティングへの手ごろな価格のアクセスを提供したいというニーズがある。これは、ソフトウェアライセンスが一般に永久のライセンスを基準として販売されているソフトウェア業界の伝統的な構造に照らしても真実である。人々はまた、さまざまなソフトウェアのための永久のライセンスを購入するための十分な資金を持っていない結果として、そのようなソフトウェアをトレーニングの目的などのために短期間使用することさえも禁じられている。さらに先進国においてさえ、コンピュータユーザは、特定のソフトウェアを一定の時間だけ使用する必要がある場合に、その特定のソフトウェアのための永久のライセンスを購入する必要性によって意欲をそがれる。

永久のライセンスを購入する必要なくソフトウェアを使用できるようにするための、既存のものに取って代わるソリューションを提供するために、さまざまなビジネスモデルが試されてきた。たとえば、さまざまな企業が、ＡＳＰ（ａｐｐｌｉｃａｔｉｏｎ ｓｅｒｖｉｃｅ ｐｒｏｖｉｄｅｒ）モデルに基づくソフトウェアを提供しており、このモデルでは、ユーザは、インターネットなどのネットワークのサーバ上に常駐しているソフトウェアに、そのサーバへログインすることによってアクセスすることができる。しかしこの方法では、ユーザは、インターネットを介してサーバに絶え間なく接続している必要がある。これは、インターネットへのアクセスが高価で信頼できないさまざまな発展途上国において発展できるソリューションではない。あるいは、ソフトウェアプロバイダは、ユーザがソフトウェアを一定の時間だけダウンロードできるようにしている場合が多いが、これは一般に試用のためであり、その後ユーザは、そのソフトウェアのための永久のライセンスを購入しなければならない。しかし、そのような試用版のソフトウェアを使用するための時間は、通常は固定されており、ユーザは、自分自身の選択のために時間を購入することや、固定された時間を追加するために試用版ソフトウェアのユーザを更新することを選択することができない。容易に理解できるように、ユーザがさまざまな異なる方法でソフトウェアサービスを購入できるような方法でユーザにそれらのサービスを提供したいというニーズがある。

動的なソフトウェアプロビジョニングシステム（ｓｏｆｔｗａｒｅ ｐｒｏｖｉｓｉｏｎｉｎｇ ｓｙｓｔｅｍ）は、所望のビジネスプロセスに基づいて複数の異なるコンピューティングデバイス上にソフトウェアを提供することを可能にする。この動的なソフトウェアプロビジョニングシステムによって、ユーザは、オペレーティングシステムやその他のアプリケーションおよびツールを、特定の時間だけ、特定の使用量だけ、あるいはその他の任意の所望の方法で使用することを、インターネットサービスプロバイダ、システムプロバイダ、あるいはサードパーティーに要求することができる。このプロビジョニングサービス（ｐｒｏｖｉｓｉｏｎｉｎｇ ｓｅｒｖｉｃｅ）は、ソフトウェアおよび使用許諾メッセージ（プロビジョニングパケットと呼ばれる場合もある）の実際の配信を管理するための配信環境を使用する。この配信環境は、対象のコンピュータに関連付けられている識別子を有するプロビジョニングパケットを受信し、そのプロビジョニングパケットを配信のために待ち行列に入れる。プロビジョニングパケットを求める要求が着信すると、その要求内の識別子が、プロビジョニングパケット内の識別子と照合される。そして、正しいプロビジョニングパケットがコンピュータに配信される。この配信環境においては、配信のために複数のパケットを待ち行列に入れることができる。

以降の文章は、多くの異なる実施形態の詳細な説明を記載しているが、この説明の法的な範囲は、本特許に添付されている特許請求の範囲の文言によって定義されるという点を理解されたい。この詳細な説明は、例示的なものにすぎないと解釈されるべきであり、可能な実施形態をすべて説明しているわけではない。というのも、可能な実施形態をすべて説明することは、不可能ではないにしても、非現実的と思われるためである。本発明を定義する特許請求の範囲内に今後とも収まるであろう現在の技術または本特許の出願日以降に開発される技術を使用して、多くの代替実施形態を実施することができる。

また用語については、「本明細書で使用する際、「 」という用語は、．．．を意味するものと定義する」という文や類似の文を使用して本特許内で明確に定義されていない限り、その用語の意味を、明示的にも暗示的にも、その率直な意味すなわち通常の意味を越えて限定する意図はまったくなく、またそのような用語は、本特許のいずれかのセクションにおいて行われているいずれかの記述（特許請求の範囲の言葉は除く）に基づく範囲に限定されるものと解釈すべきではないという点を理解されたい。本特許に添付されている特許請求の範囲に記載されているいずれかの用語が、ある単一の意味と一致した方法で本特許内で言及されている限りにおいては、それは、もっぱら読者を混乱させないように明確にする目的で行われているものであり、そのような特許請求の範囲の用語を、暗示などによって、その単一の意味に限定することを意図するものではない。最後に、請求項の要素が、いかなる構造についても記載せずに「手段」という言葉と機能とを記載することによって定義されているのでない限り、いかなる請求項の要素の範囲も、３５ Ｕ．Ｓ．Ｃ．セクション１１２、第６パラグラフの適用に基づいて解釈されることを意図するものではない。

（ネットワーク）
図１は、動的なソフトウェアプロビジョニングシステムを実装するために使用することができるネットワーク１０を示している。ネットワーク１０は、インターネット、ＶＰＮ（ｖｉｒｔｕａｌ ｐｒｉｖａｔｅ ｎｅｔｗｏｒｋ）、あるいは１つまたは複数のコンピュータ、通信デバイス、データベースなどが相互に通信可能に接続されることを可能にするその他の任意のネットワークとすることができる。ネットワーク１０は、イーサネット（登録商標）１６、およびルータ１８、ならびに地上通信線２０を介してパーソナルコンピュータ１２およびコンピュータ端末１４に接続することができる。その一方で、ネットワーク１０は、無線通信局２６および無線リンク２８を介してラップトップコンピュータ２２およびパーソナルデータアシスタント（ｐｅｒｓｏｎａｌ ｄａｔａ ａｓｓｉｓｔａｎｔ）２４に無線で接続することができる。同様に、サーバ３０は、通信リンク３２を使用してネットワーク１０に接続することができ、メインフレーム３４は、別の通信リンク３６を使用してネットワーク１０に接続することができる。以降でさらに詳しく説明するように、この動的なソフトウェアプロビジョニングシステムの１つまたは複数のコンポーネントは、ネットワーク１０に接続されるさまざまなデバイスのいずれに格納して機能させることもできる。

（コンピュータ）
図２は、動的なソフトウェアプロビジョニングシステムの１つまたは複数のコンポーネントを実装するためにネットワーク１０に接続して使用することができるコンピュータ１１０の形態のコンピューティングデバイスを示している。コンピュータ１１０のコンポーネントは、処理装置１２０と、システムメモリ１３０と、システムメモリを含むさまざまなシステムコンポーネントを処理装置１２０に結合するシステムバス１２１とを含むことができるが、これらには限定されない。システムバス１２１は、メモリバスまたはメモリコントローラと、ペリフェラルバスと、さまざまなバスアーキテクチャーのいずれかを使用するローカルバスとを含む複数のタイプのバス構造のいずれにすることもできる。たとえばこのようなアーキテクチャーは、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとしても知られているＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスを含むが、これらには限定されない。

コンピュータ１１０は通常、さまざまなコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０によってアクセスできる利用可能な任意のメディアとすることができ、揮発性メディアおよび不揮発性メディア、ならびに取り外し可能メディアおよび固定式メディアの双方を含む。たとえばコンピュータ可読媒体は、コンピュータストレージメディアおよび通信メディアを含むことができるが、これらには限定されない。コンピュータストレージメディアは、コンピュータ可読命令、データ構造、プログラムモジュール、その他のデータなどの情報を記憶するための任意の方法または技術において実装される揮発性メディアおよび不揮発性メディア、ならびに取り外し可能メディアおよび固定式メディアを含む。コンピュータストレージメディアは、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、またはその他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）、またはその他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、またはその他の磁気ストレージデバイス、あるいは所望の情報を保存するために使用可能で、コンピュータ１１０によってアクセス可能なその他の任意のメディアを含むが、これらには限定されない。通信メディアは通常、搬送波やその他の伝送メカニズムなどの変調されたデータ信号内のコンピュータ可読命令、データ構造、プログラムモジュール、あるいはその他のデータを具体化し、任意の情報伝達メディアを含む。「変調されたデータ信号」という用語は、情報をその信号内でコード化するような方法で設定または変更されたその特性のうちの１つまたは複数を有する信号を意味する。たとえば通信メディアは、有線ネットワークや直接有線接続などの有線メディアと、音波メディア、無線周波数メディア、赤外線メディア、その他の無線メディアなどの無線メディアとを含むが、これらには限定されない。また上記のいずれの組合せも、コンピュータ可読媒体の範囲内に含まれるものである。

システムメモリ１３０は、コンピュータストレージメディアを、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）１３１およびＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）１３２などの揮発性メモリおよび／または不揮発性メモリの形態で含む。ＢＩＯＳ（ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）１３３は、起動中などにコンピュータ１１０内の要素どうしの間における情報伝達を補助する基本ルーチンを含み、通常はＲＯＭ１３１内に格納されている。ＲＡＭ１３２は通常、処理装置１２０がすぐにアクセスできるか、および／または処理装置１２０によってその時点で操作されているデータモジュールおよび／またはプログラムモジュールを含む。図１は、例としてオペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７を示しているが、これらには限定されない。

またコンピュータ１１０は、その他の取り外し可能／固定式、揮発性／不揮発性コンピュータストレージメディアを含むこともできる。図１は、例示のみを目的として、固定式の不揮発性の磁気メディアとの間で読み取りや書き込みを行うハードディスクドライブ１４１と、着脱式不揮発性の磁気ディスク１５２との間で読み取りや書き込みを行う磁気ディスクドライブ１５１と、ＣＤ−ＲＯＭやその他の光メディアなどの着脱式不揮発性の光ディスク１５６との間で読み取りや書き込みを行う光ディスクドライブ１５５とを示している。典型的な動作環境において使用できるその他の取り外し可能／固定式、揮発性／不揮発性コンピュータストレージメディアとしては、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどがあるが、これらには限定されない。ハードディスクドライブ１４１は通常、インターフェース１４０などの固定式のメモリインターフェースを介してシステムバス１２１に接続されており、磁気ディスクドライブ１５１および光ディスクドライブ１５５は通常、インターフェース１５０などの着脱式メモリインターフェースによってシステムバス１２１に接続されている。

図１に示されている上述のドライブおよびそれらに関連するコンピュータストレージメディアは、コンピュータ１１０用のコンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの記憶を提供する。たとえば図１において、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７を記憶するものとして示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７と同一とするか、または異なっていてもよいという点に留意されたい。ここでは、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７が最低限異なるコピーであることを示すために、異なる番号を割り当てている。ユーザは、キーボード１６２や、通常はマウス、トラックボール、あるいはタッチパッドと呼ばれるポインティングデバイス１６１などの入力デバイスを介してコンピュータ１１０にコマンドおよび情報を入力することができる。その他の入力デバイス（図示せず）は、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信用アンテナ、スキャナなどを含むことができる。これらおよびその他の入力デバイスは、システムバスに結合されているユーザ入力インターフェース１６０を介して処理装置１２０に接続される場合が多いが、パラレルポート、ゲームポート、またはＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）などのその他のインターフェース構造およびバス構造によって接続することもできる。またモニタ１９１やその他のタイプのディスプレイデバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。コンピュータは、モニタに加えて、スピーカ１９７やプリンタ１９６などのその他の周辺出力デバイスを含むこともでき、これらは、周辺出力インターフェース１９５を介して接続することができる。

コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境内で機能することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、あるいはその他の一般的なネットワークノードとすることができ、図１にはメモリストレージデバイス１８１しか示されていないが、通常はコンピュータ１１０に関連する上述の要素の多くまたはすべてを含む。図１に示されている論理接続は、ＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）１７１およびＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）１７３を含むが、その他のネットワークを含むこともできる。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットにおいてよく見受けられる。

ＬＡＮネットワーキング環境において使用する場合には、コンピュータ１１０は、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境において使用する場合には、コンピュータ１１０は通常、モデム１７２や、インターネットなどのＷＡＮ１７３上で通信を確立するためのその他の手段を含む。モデム１７２は、内蔵型または外付け型とすることができ、ユーザ入力インターフェース１６０やその他の適切なメカニズムを介してシステムバス１２１に接続することができる。ネットワーク化された環境においては、コンピュータ１１０に関連して示されているプログラムモジュール、またはその一部をリモートメモリストレージデバイス内に格納することができる。図１は、例としてリモートアプリケーションプログラム１８５をメモリデバイス１８１上に常駐するものとして示しているが、この形態には限定されない。示されているネットワーク接続は例示的なものであり、コンピュータどうしの間に通信リンクを確立するその他の手段も使用することができるということが理解できるであろう。

（ソフトウェアプロビジョニングシステム）
図３は、コンピューティングデバイス２０２上でのオペレーティングシステムの使用を提供するための動的なソフトウェアプロビジョニングシステム２００を示しており、ここでは、コンピューティングデバイス２０２は、デスクトップコンピュータ１２、ラップトップコンピュータ２２、ＰＤＡ２４、携帯電話、あるいは任意の類似のデバイスなど、一般に知られているコンピューティングデバイスのいずれにすることもできる。ソフトウェアプロビジョニングシステム２００は、オペレーティングシステムの使用を提供するために実装されるものとして示されているが、ある代替実装形態においては、ソフトウェア、ファームウェア、コンピューティングデバイスの一機能など、その他のリソースの使用を提供するために使用することもできる。同様に、ソフトウェアプロビジョニングシステム２００は、ネットワーク１０に通信可能に接続されているコンピューティングデバイス２０２上でのリソースの使用を提供するものとして示されているが、ネットワーク１０に接続できない、あるいはネットワーク１０に一時的にしか接続できないコンピューティングデバイス上でのそのような使用を実装するために使用することもできる。

ソフトウェアプロビジョニングシステム２００は、コアプロビジョニングサービスモジュール２０６と、確認サービス２０９を有する配信サービスモジュール２０８と、証明書サービスモジュール２１０と、コアデータベース２１２と、配信データベース２１４とを有するプロビジョニングサービスモジュール２０４を含むことができる。プロビジョニングシステム２０４は、課金アダプタ２１８を介して課金システム２１６と通信することができ、その一方でコアプロビジョニングサービスモジュール２０６は、データベースライタ（ｄａｔａｂａｓｅ ｗｒｉｔｅｒ）２２０を介して配信データベース２１４と通信することができ、配信データベース２１４は、データベースリーダ２２２を介して配信サービス２０８と通信する。コンピューティングデバイス２０２は、ローカルプロビジョニングモジュール（ＬＰＭ）２２４を含むことができ、このＬＰＭ２２４は、配信ウェブサービスモジュール２２６を介して配信サービスモジュール２０８と通信し、課金ウェブサービスモジュール２２８を介して課金システム２１６と通信する。

プロビジョニングサービスモジュール２０４は、サーバ３０などのサーバシステム上や、ネットワーク１０に通信可能に接続されているその他のシステム上に配置することができる。同様に、課金システム２１６も、サーバ３０などのサーバシステム上や、ネットワーク１０に通信可能に接続されているその他のシステム上に配置することができる。さらに、プロビジョニングサービスモジュール２０４のさまざまなコンポーネントのうちの１つまたは複数は、同一のサーバ上や、別々の場所に配置されている複数の異なるサーバ上に配置することができる。たとえばコアデータベース２１２は、別々の場所に配置されてそれぞれネットワーク１０に通信可能に接続されている複数の異なるデータベースサーバ上に配置することができる。プロビジョニングサービスモジュール２０４およびそのさまざまなコンポーネントモジュールの機能については、以降でさらに詳しく説明する。

さらに図３においては、コンピューティングデバイス２０２は、ウェブサービスモジュール２２６を介して配信サービスモジュール２０８と、およびウェブサービスモジュール２２８を介して課金システム２１６と通信するものとして示されている。状況によっては、ウェブサービスモジュール２２６は、望ましいレベルを超えるアクティビティーの増加を認識することができる。代替実施形態における負荷管理サービス２３０、コンピューティングデバイス２０２のユーザは、電話などの代替モードの通信を介して配信サービスモジュール２０８および課金システム２１６と通信することができる。たとえば、コンピューティングデバイス２０２にとってネットワーク１０に接続することが不可能な状況においては、コンピューティングデバイス２０２のユーザは、配信サービスモジュール２０８に取り付けられている電話および音声認識対応型のユーザインターフェースを介して、あるいは配信サービスモジュール２０８と通信できる顧客サービス担当者などを介して通信することができる。

コンピューティングデバイス２０２が、コンピュータ１１０などのコンピュータである場合には、ＬＰＭ２２４は、システムメモリ１３０の一部として、処理装置１２０を含むコンピュータ１１０のさまざまなハードウェアコンポーネントの一部として、あるいはこれらの任意の組合せとして、固定式の不揮発性メモリ１４０上に配置することができる。ＬＰＭ２２４の機能については、以降でさらに詳しく説明する。

（プロビジョニングシステムのフローチャート）
次いで図４を参照すると、プロビジョニングプログラム２５０が、ソフトウェアプロビジョニングシステム２００の一般的な機能を示している。ブロック２５１においては、コンピューティングデバイス２０２上でオペレーティングシステムを使用するための登録キーをユーザに提供することができる。オペレーティングシステムなどを使用するためのさらなる時間をユーザが購入した結果として、コンピューティングデバイス２０２の新たな購入に伴って登録キーをユーザに提供することができる。複数の異なるエンティティーが、登録キーをユーザに提供することができ、たとえば、コンピューティングデバイス２０２を販売しているコンピュータストアは、キーをユーザに提供することができ、コンピューティングデバイス２０２用のオペレーティングシステムの使用を含む一式のサービスを販売しているインターネットサービスプロバイダは、登録キーをユーザに提供することができる、といった具合である。

登録キーは、以降でさらに詳しく説明するように、プロビジョニングサービスモジュール２０４によって証明書サービス２１０を用いて作成して、登録キーのプロバイダに安全な方法で送信することができる。あるいは、登録キーのプロバイダが、プロビジョニングサービスモジュール２０４と合意した方法で登録キーを作成することもできる。登録キーは、その登録キーを使用してコンピューティングデバイス２０２を識別するハードウェアやその他のコンポーネントに固有の情報を含むこともでき、あるいは含まなくてもよい。ソフトウェアプロビジョニングシステム２００の一実装形態においては、それぞれの登録キーは、コンピューティングデバイス２０２のＨＷＩＤ（ｈａｒｄｗａｒｅ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）によって、コンピューティングデバイス２０２を一意に識別する。さらに別の実装形態においては、登録キーは、オペレーティングシステムのプロダクトキーなどの製造識別番号（ｐｒｏｄｕｃｔｉｏｎ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｎｕｍｂｅｒ）とすることができ、オペレーティングシステムの開発者や、そのオペレーティングシステムを使用するコンピューティングデバイスの製造業者など、プロビジョニングサービス以外のエンティティーによって作成することができる。この登録キーは、ＩｎｉｔＫｅｙ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ ｋｅｙ）とも呼ばれ、一連の英数字の形式、ＲＦＩＤ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）タグの形式、あるいはその他の任意の合意されたフォーマットとすることができる。

登録キーをユーザに提供した後、ブロック２５２において、プロビジョニングプログラム２５０は、その登録キーをプロビジョニングサービスモジュール２０４に登録することが必要かどうかを判定することができる。ＩｎｉｔＫｅｙが、はじめにプロビジョニングサービスモジュール２０４によって作成されたものである場合には、そのＩｎｉｔＫｅｙは、プロビジョニングサービスモジュール２０４のデータベース内に既に保存されている可能性があるため、そのＩｎｉｔＫｅｙを登録することは必要でないかもしれない。あるいは、合意されたプロシージャーに基づいてサードパーティーのベンダがＩｎｉｔＫｅｙを作成できるような方法でソフトウェアプロビジョニングシステム２００がセットアップされている場合には、そのようなベンダは、そのＩｎｉｔＫｅｙを、作成した際に、あるいは少なくともユーザへ提供した際に、登録する必要があるかもしれない。

ＩｎｉｔＫｅｙを登録することが必要であると判定された場合には、ベンダは、ブロック２５４において、ＩｎｉｔＫｅｙをプロビジョニングサービスモジュール２０４に登録することができる。ＩｎｉｔＫｅｙの登録については、以降の図９においてさらに詳しく説明する。

ＩｎｉｔＫｅｙの登録後、ブロック２５６において、プロビジョニングプログラム２５０は、コンピューティングデバイス２０２のためのプロビジョニングパケット（「パケット」とも呼ばれる）を作成する。コンピューティングデバイス２０２は、プロビジョニングパケットを使用して、指定された時間だけ、指定された期間だけ、あるいはその他の任意の合意された方法でユーザがオペレーティングシステムを使用できるようにすることができる。ある代替実装形態においては、プロビジョニングパケットを使用して、指定された期間だけソフトウェアやアプリケーションなどのその他の任意のリソースをユーザが使用できるようにすることができる。プロビジョニングサービスモジュール２０４によって作成されるプロビジョニングパケットは、そのパケットのユーザに関する情報や、そのパケットによって認められる使用量などを含むことができる。たとえばベンダが、コンピューティングデバイス２０２を、そのコンピューティングデバイス２０２上でのオペレーティングシステムの１カ月間の前払いの使用権と共に販売している場合には、ブロック２５６において、プロビジョニングサービスモジュール２０４は、コンピューティングデバイス２０２がそのオペレーティングシステムを１カ月間だけ使用できるようにするコンピューティングデバイス２０２用のプロビジョニングパケットを作成することができる。しかしプロビジョニングパケットは、コンピューティングデバイス２０２のみがその特定のプロビジョニングパケットを使用できるような方法で作成することができる。プロビジョニングパケットの作成については、以降の図１０においてさらに詳しく説明する。

ユーザが、コンピューティングデバイス２０２の電源をオンにすることによって、あるいはその他の任意の方法で、コンピューティングデバイス２０２上のオペレーティングシステムをアクティブ化しようと試みるとき、ＬＰＭ２２４は、オペレーティングシステムのアクティブ化をコントロールすることができる。これは、プログラム２５０のブロック２５８によって示されている。そのユーザがこのオペレーティングシステムの使用を試みるのは、これが初めてであるとＬＰＭ２２４が検知した場合には、ＬＰＭ２２４は、ＩｎｉｔＫｅｙを入力するようユーザに要求することができる。ある代替実装形態においては、ＬＰＭ２２４は、コンピューティングデバイス２０２をスキャンして、コンピューティングデバイス２０２がＩｎｉｔＫｅｙを既に投入されているかどうかを判定することができ、投入されている場合には、ＬＰＭ２２４は、ＩｎｉｔＫｅｙをコンピューティングデバイス２０２から自動的に検索する。ＩｎｉｔＫｅｙをユーザから受け取った後、ＬＰＭ２２４は、プロビジョニングサービスモジュール２０４と接続して、コンピューティングデバイス２０２のための証明書を要求することができ、この場合には、証明書を求める要求は、数ある情報の中でも、コンピューティングデバイス２０２のＩｎｉｔＫｅｙおよびＨＷＩＤを含む。ＬＰＭ２２４の設計およびオペレーションについては、以降で図７においてさらに詳しく説明する。

証明書を求める要求に応答して、ブロック２６０において、プロビジョニングサービスモジュール２０４は、証明書サービスモジュール２１０から証明書を受け取ることができ、その証明書を、配信サービスモジュール２０８を介してコンピューティングデバイス２０２へ送信する。証明書サービスモジュール２１０から証明書を作成して、その証明書をクライアントデバイスへ送信するプロセスについては、以降で図１０においてさらに詳しく説明する。

プロビジョニングサービスモジュール２０４から証明書を受け取ると、ブロック２６２において、ＬＰＭ２２４は、コンピューティングデバイス２０２上でオペレーティングシステムを使用するためにさらなるプロビジョニングパケットを入手することが必要かどうかを判定することができる。ＬＰＭ２２４は、それまでコンピューティングデバイス２０２が使用された時間、現在の時間周期（ｃｕｒｒｅｎｔ ｔｉｍｅ ｐｅｒｉｏｄ）、あるいは任意の類似のビジネスルールなどのビジネスルールに基づいて、プロビジョニングサービスモジュール２０４から受け取ったプロビジョニングパケットを消費することができる。以降でさらに説明するように、ＬＰＭ２２４は、以前にプロビジョニングサービスモジュール２０４から受け取ったプロビジョニングパケットを含むローカルプロビジョニングパケットストレージモジュール（ｌｏｃａｌ ｐｒｏｖｉｓｉｏｎｉｎｇ ｐａｃｋｅｔ ｓｔｏｒａｇｅ ｍｏｄｕｌｅ）を有することができる。ＬＰＭ２２４は、そのようなローカルパケットストア（ｌｏｃａｌ ｐａｃｋｅｔ ｓｔｏｒｅ）から１つのプロビジョニングパケットを選択し、その中身を分析して、プロビジョニングサービスモジュール２０４にさらなるパケットを要求する必要があるかどうかを判定することができる。プロビジョニングパケットの選択、および選択されたプロビジョニングパケットの分析については、以降の図７においてさらに詳しく説明する。

さらなるプロビジョニングパケットを要求することが必要であると判定された場合には、ブロック２６４において、ＬＰＭ２２４は、さらなるプロビジョニングパケットを受け取るためにプロビジョニングサービスモジュール２０４へ要求を送信することができる。ＬＰＭ２２４は、配信サービスモジュール２０８のウェブサービスモジュール２２６に接続することによって、プロビジョニングサービスモジュール２０４の顧客サービス担当者に連絡を取るようコンピューティングデバイス２０２のユーザに要求することによって、あるいはその他の任意の所望の方法を含む複数の異なる方法で、そのような要求をＰＳＭへ送信することができる。プロビジョニングパケットを求める要求は、クライアントデバイス、そのクライアントデバイスによって使用されるオペレーティングシステムなどを識別する情報を含むことができる。

プロビジョニングパケットを求める要求をコンピューティングデバイス２０２から受信すると、ブロック２６６において、プロビジョニングサービスモジュール２０４は、プロビジョニングパケットを作成して、ＬＰＭ２２４へ配信することができる。ＬＰＭ２２４に提供されるそれぞれのプロビジョニングパケットは、コンピューティングデバイス２０２、そのコンピューティングデバイス２０２によって使用されるオペレーティングシステム、パケットのタイプ、パケットのシーケンス番号、コンピューティングデバイス２０２がオペレーティングシステムを使用できる時間、あるいはオペレーティングシステムの使用期限が切れる日にちなどを識別するさまざまな情報を含むことができる。プロビジョニングパケット内の情報をＬＰＭ２２４が認証できるようにする電子署名を、そのプロビジョニングパケット内に含めることもできる。あるいは、別のセキュリティープロトコルのもとでは、プロビジョニングパケット内の情報をＬＰＭ２２４が認証できるようにする電子署名を、別途ＬＰＭ２２４へ送信することもできる。プロビジョニングパケットの作成および配信については、以降の図１２においてさらに詳しく説明する。

プロビジョニングパケットを受け取ると、ＬＰＭ２２４は、ブロック２６８において、そのプロビジョニングパケットを処理することができ、これについては、以降の図７においてさらに詳しく説明する。プロビジョニングパケットの中身を分析した後に、そのプロビジョニングパケットがコンピューティングデバイス２０２上でのオペレーティングシステムの使用を可能にすることができるとＬＰＭ２２４が判定した場合には、ブロック２７０において、コンピューティングデバイス２０２は、そのコンピューティングデバイス２０２上でオペレーティングシステムを起動することができる。

（コアプロビジョニングシステム）
図５は、図３のコアプロビジョニングサービスモジュール２０６の詳細なブロック図を示している。コアプロビジョニングサービスモジュール２０６は、サーバ３０、メインフレーム３４、あるいはネットワーク１０に通信可能に接続されているその他の任意の適切なデバイス上に実装することができる。コアプロビジョニングサービスモジュール２０６は、証明書サービスモジュール２１０、課金アダプタ２１８、コアＤＢ ２１２、および配信サービスモジュール２０８と通信することができる。コアプロビジョニングサービス２０６は、課金アダプタと通信する課金インターフェース２８０と、証明書サービスモジュール２１０と通信するための証明書サービスインターフェース２８２と、配信サービスモジュール２０８と通信するための配信サービスインターフェース２８８と、アカウント更新モジュール２８４と、パケットジェネレータ（ｐａｃｋｅｔ ｇｅｎｅｒａｔｏｒ）２８６と、コアデータベース２１２および配信データベース２１４と通信するデータアクセスモジュール２９０とを含むことができる。

課金インターフェース２８０は、ウェブインターフェース、課金アダプタ２１８へのＶＰＮ、あるいは当業者によく知られているその他の任意の所望の方法を使用して実装することができる。ある特定の実装形態においては、課金インターフェース２８０は、ＭＳＭＱ（Ｍｉｃｒｏｓｏｆｔ ｍｅｓｓａｇｅ ｑｕｅｕｅ）（商標）インターフェースを使用して実装することができる。あるいは、ＥＡＩ（ｅｎｔｅｒｐｒｉｓｅ ａｐｐｌｉｃａｔｉｏｎ ｉｎｔｅｒｆａｃｅ）プロトコルを使用して設計されているＭｉｃｒｏｓｏｆｔ Ｂｉｚｔａｌｋ（商標）など、別の業界プロトコル（ｉｎｄｕｓｔｒｙ ｐｒｏｔｏｃｏｌ）を使用して設計されているインターフェースを使用して、課金インターフェース２８０を実装することもできる。ＭＳＭＱ（商標）テクノロジーを使用して、配信サービスインターフェース２８８およびデータアクセスモジュール２９０を実装することもできる。

課金インターフェースモジュール２８０は、コンピューティングデバイスのためのＩｎｉｔＫｅｙの登録を求める要求を課金アダプタ２１８から受け取り、アカウント更新と通信して、アカウント更新情報を提供し、さまざまなコンピューティングデバイスをブートストラップし、コンピューティングデバイスのためのクライアント証明書を証明書サービスモジュール２１０に要求することなどができる。

アカウント更新モジュール２８４は、コンピューティングデバイス２０２のためのアカウントの作成、保持、および更新を担当することができる。アカウント更新モジュール２８４は、コンピューティングデバイス２０２のためのアカウントのセットアップおよび更新に関する課金アダプタ２１８からの情報を受信することができ、またパケットジェネレータ２８６と通信して、コンピューティングデバイス２０２のためのプロビジョニングパケットを作成および保存することができる。たとえば、引受会社（ｕｎｄｅｒｗｒｉｔｅｒ）、電気通信業者等は、コンピューティングデバイス２０２上でのオペレーティングシステムの一定の使用時間を販売し、課金アダプタ２１８を使用して、コンピューティングデバイス２０２のアカウントをしかるべく更新するためのアカウント更新要求をコアプロビジョニングサービス２０６へ送信することができる。課金アダプタ２１８からのアカウント更新要求を受信すると、アカウント更新モジュール２８４は、データアクセスモジュール２９０を使用してコアデータベース２１２への必要な入力を行い、パケットジェネレータと通信して、必要なプロビジョニングパケットを作成することができる。別の場合には、配信サービスモジュール２０８が、コンピューティングデバイス２０２のためのプロビジョニングパケットを購入したいというコンピューティングデバイス２０２からの要求を受け取ることができる。

一方、コンピューティングデバイス２０２が、証明書を求める、またはプロビジョニングパケットを求める要求をコアプロビジョニングサービス２０６へ送信すると、アカウント更新モジュール２８４は、コアデータベース２１２からプロビジョニングパケットを検索し、コンピューティングデバイス２０２のためのアカウント情報を更新し、配信サービスモジュール２０８と通信して、そのプロビジョニングパケットをコンピューティングデバイス２０２へ送信することができる。

コアプロビジョニングサービス２０６は、証明書を求める、またはプロビジョニングパケットを求める要求をコンピューティングデバイス２０２から受信すると、証明書サービスインターフェース２８２を使用して証明書サービスモジュール２１０と通信して、証明書を受け取ることや、証明書を確認することができる。証明書サービスモジュール２１０は、暗号化された証明書の作成および管理を可能にする標準的な証明書技術のうちのいずれかを使用して実装することができる。たとえば、証明書サービスモジュール２１０は、ＰＫＩ（ｐｕｂｌｉｃ ｋｅｙ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）に準拠する認証局を使用して実装することができる。証明書サービスモジュール２１０は、キーマネージャー２９２を含むことができ、このキーマネージャー２９２は、暗号化された非対称的なツインキー（ａｓｙｍｍｅｔｒｉｃａｌ ｔｗｉｎ ｋｅｙｓ）の作成や、キーの購入者（ｋｅｙ ｓｕｂｓｃｒｉｂｅｒ）の識別および認証などを担当する。証明書サービスモジュール２１０は、証明書ジェネレータ（ｃｅｒｔｉｆｉｃａｔｅ ｇｅｎｅｒａｔｏｒ）を含むこともでき、この証明書ジェネレータは、デジタル証明書を用いて、そのような証明書の発行、保持、管理、取り消し、一時停止、復活、および更新のために、ならびに公開キーリポジトリ（ｐｕｂｌｉｃ ｋｅｙ ｒｅｐｏｓｉｔｏｒｙ）の作成および管理のために、公開キーをクライアントアカウントに結び付ける。クライアントのための証明書の作成および管理については、以降の図１１においてさらに詳しく説明する。

証明書サービスインターフェース２８２は、パケットジェネレータ２８６によって作成されたプロビジョニングパケットがコンピューティングデバイス２０２へ送信される前に、証明書サービスモジュール２１０によって作成された証明書を使用することによって、そのプロビジョニングパケットに署名することができる。証明書サービスインターフェース２８２は、パケット要求などのクライアント署名を確認するために証明書サービスモジュール２１０と通信することもできる。

コアプロビジョニングサービス２０６は、プロビジョニングパケット、およびクライアントデバイス証明書などのその他のクライアントデバイスのブートストラップ関連情報（ｏｔｈｅｒ ｃｌｉｅｎｔ ｄｅｖｉｃｅ ｂｏｏｔｓｔｒａｐｐｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ）を配信データベース２１４内に発行することを担当することができる。配信サービスモジュール２０８には、配信データベース２１４から情報を読み取ることを認めることができるが、アカウント情報の整合性を維持するために、配信サービスモジュール２０８には、一般に配信データベース２１４内への発行を行うことは認められないという点に留意されたい。

コアプロビジョニングサービス２０６内のさまざまなモジュールは、上述のさまざまなタスクを実行する別々のモジュールとして示されているが、この描写は、例示のみを目的としたものであり、実際には、これらの別々のモジュールのすべてを別々の方法で実装することができ、それによって、これらのモジュールのうちの１つまたは複数が結合されたり、これらのモジュールのすべてが別々の方法でお互いに対話することができたり、といった具合になるという点を理解されたい。

（コアデータベーススキーマ）
図６は、コアデータベース２１２の実装のために使用できるコアデータベーススキーマ３１０を示している。コアデータベーススキーマ３１０は、ブートストラップテーブル３１２、コンピューティングデバイステーブル３１４、ジョブテーブル３１６、パケットテーブル３１８、構成テーブル３２０、コンピューティングデバイスログテーブル３２２、タイプテーブル３２４、ジョブログテーブル３２６、およびステータステーブル３２８を含むことができる。コアデータベーススキーマ３１０は、よく知られているリレーショナルデータベースソフトウェアのうちのいずれかを使用して実装することができ、コアデータベーススキーマ３１０のさまざまなテーブルは、単一のデータベースサーバ上に、あるいはネットワーク１０などのネットワークを介して相互に接続されている別々のデータベースサーバ上に格納することができる。

ブートストラップテーブル３１２は、ソフトウェアプロビジョニングシステム２００を使用して提供することができるコンピューティングデバイス２０２などのコンピューティングデバイスのためのブートストラップデータを保存することができ、そのようなデータは、引受会社から課金アダプタ２１８を介して受信される。ブートストラップテーブル３１２内のそれぞれのレコードは、レコードＩＤフィールドと、コンピューティングデバイス用のＩＤと、コンピューティングデバイスのユーザに提供されたＩｎｉｔＫｅｙと、パケットがコンピューティングデバイスに配信された回数を識別する配信回数と、コンピューティングデバイスのブートストラップステータスとを含む情報を含むことができる。

コンピューティングデバイステーブル３１４は、ソフトウェアプロビジョニングシステム２００を使用して提供することができるコンピューティングデバイス２０２などのコンピューティングデバイスに関連したデータを保存することができる。コンピューティングデバイステーブル３１４は、コンピューティングデバイスへ送信される登録パケットやプロビジョニングパケットに追加されるコンピューティングデバイスに関連したさまざまなデータを保存することができる。コンピューティングデバイステーブル３１４は、コンピューティングデバイスを識別して、そのコンピューティングデバイスのステータスを追跡把握するために使用することができる。コンピューティングデバイステーブル３１４内のそれぞれのレコードは、レコードＩＤフィールド、コンピューティングデバイスのハードウェア構成を指定するハードウェアＩＤ、コンピューティングデバイスへ送信された前回のプロビジョニングパケットのシーケンス番号を表す直近のシーケンス番号などを含む情報を含むことができる。

ジョブテーブル３１６は、プロビジョニングサービスモジュール２０４へのさまざまなプロビジョニング要求（ｐｒｏｖｉｓｉｏｎｉｎｇ ｒｅｑｕｅｓｔ）に基づいて作成できるデータを保存し、それぞれのプロビジョニング要求は、ジョブテーブル３１６内に新たなレコードを作成する。ジョブテーブル３１６内のレコードは、さまざまなプロビジョニング要求のプロビジョニングジョブステータス（ｐｒｏｖｉｓｉｏｎｉｎｇ ｊｏｂ ｓｔａｔｕｓ）を追跡把握するために使用することができる。ジョブテーブル３１６内のそれぞれのレコードは、レコードＩＤフィールド、コンピューティングデバイスＩＤ、ジョブタイプＩＤ、ジョブトラッキングＩＤ、プロビジョニング要求のためのトークン、プロビジョニング要求を行っているコンピューティングデバイスのためのアカウントＩＤ、プロビジョニング要求の日付および時間、プロビジョニング要求の処理のステータスなどを含む情報を含む。

パケットテーブル３１８は、ジョブデータに基づいて作成できるパケットデータを保存し、この場合には、１つのジョブが、１つまたは複数のパケットを作成することができる。パケットテーブルは、配信サービスモジュール２０８から、または課金アダプタ２１８から受信されるプロビジョニング要求に応答して作成されるさまざまなプロビジョニングパケットの配信ステータスを追跡把握するために使用される。パケットテーブル内のそれぞれのレコードは、レコードＩＤ、パケットが作成されるようにするジョブを表すジョブＩＤ、パケット内に含まれているさまざまなデータ、特定のコンピューティングデバイスから最後のパケットダウンロード確認応答を受信してからその特定のコンピューティングデバイスにパケットが何回配信されたかを示す配信回数、およびパケットの処理の段階を示すステータスに関する情報を含むことができる。

構成テーブル３２０は、コアデータベース２１２を実装するために使用されているサーバについて記述するサーバ構成データの名前−値のペア（ｎａｍｅ−ｖａｌｕｅ ｐａｉｒ）のすべてを表すデータを保存することができる。構成テーブル３２０内のそれぞれのレコードは、サーバのネームスペースや、サーバの名前−値のペアの名前および設定に関する情報を含むことができる。

コンピューティングデバイスログテーブル３２２は、コンピューティングデバイスに関連した（そのコンピューティングデバイスに関連したジョブ以外の）さまざまなアクティビティーを記録することができる。コンピューティングデバイスログテーブル３２２内のそれぞれのレコードは、レコードＩＤ、コンピューティングデバイスＩＤ、コンピューティングデバイスのタイプ、コンピューティングデバイスについて記述するデータ、およびコンピューティングデバイスがプロビジョニングサービスモジュール２０４を用いてログインされた時間に関する情報を含むことができる。たとえばコンピューティングデバイスのタイプは、ブートストラップレコードが作成済みのタイプ、ブートストラップが進行中のタイプ、ブートストラップが完了したタイプ、（指定された数を超える証明書がコンピューティングデバイスへ配信され、そのコンピューティングデバイスから確認応答が受信されていないことを示す）ブートストラップが制限を超えたタイプ、証明書が要求されたタイプ、パケットが要求されたタイプなどのうちのいずれか１つとすることができる。

タイプテーブル３２４は、ジョブテーブル３１６、コンピューティングデバイスログテーブル３２２、およびジョブログテーブル３２６によって使用されるさまざまな列挙可能な（ｅｎｕｍｅｒａｂｌｅ）タイプを事前に定義するために使用することができる。

ジョブログテーブル３２６は、ジョブやパケットに関連するさまざまなアクティビティーを記録するために使用することができ、この場合には、それぞれのレコードは、レコードＩＤ、ジョブＩＤ、ジョブのタイプ、ジョブの説明、ジョブが記録された時間などを含む情報を含むことができる。

ステータステーブル３２８は、ブートストラップテーブル３１２、コンピューティングデバイステーブル３１４、ジョブテーブル３１６、およびパケットテーブル３１８内で使用されるさまざまな列挙可能なステータスを事前に定義するために使用することができる。

（配信データベーススキーマ）
図７は、配信データベース２１４の実装のために使用できる配信データベーススキーマ３４０を示している。配信データベーススキーマ３４０は、配信ブートストラップテーブル３４２および配信パケットテーブル３４４を含むことができる。配信データベーススキーマ３４０は、よく知られているリレーショナルデータベースソフトウェアのうちのいずれかを使用して実装することができ、配信データベーススキーマ３４０のさまざまなテーブルは、単一のデータベースサーバ上に、あるいはネットワーク１０などのネットワークを介して相互に接続されている別々のデータベースサーバ上に格納することができる。

配信ブートストラップテーブル３４２は、コンピューティングデバイスの登録中にコアプロビジョニングサービス２０６によって発行されるブートストラップデータを保存することができる。配信ブートストラップテーブル３４２のそれぞれのレコードは、レコードＩＤと、特定のコンピューティングデバイスに関連したＩｎｉｔＫｅｙと、その特定のコンピューティングデバイスのハードウェアＩＤとを含む情報を含むことができ、配信ブートストラップテーブル３４２内のレコードは、その特定のコンピューティングデバイスのためのブートストラップが完了したときに、コアプロビジョニングサービス２０６によって削除することができる。

配信パケットテーブル３４４は、コアプロビジョニングサービス２０６によって作成されたパケットを保存することができる。配信パケットテーブル３４４のそれぞれのレコードは、特定のパケットに対応することができ、レコードＩＤと、その特定のパケットを使用することになるコンピューティングデバイスについて記述するハードウェアＩＤと、その特定のパケットのパケットシーケンス番号と、その特定のパケットの中身と、確認応答が受信されない状態でその特定のパケットがクライアントデバイスへ何回送信されたかを指定する配信回数と、配信サービスモジュール２０８がその特定のパケットをクライアントデバイスへ配信しようと試みることができる回数を指定する最大配信回数とを含む情報を含む。特定のパケットが、クライアントコンピューティングデバイスによって首尾よくダウンロードされると、その特定のパケットに関連したレコードを配信パケットテーブル３４４から削除することができる。また、特定のパケットの配信回数が最大配信回数を超えた場合には、その特定のパケットに関連したレコードを配信パケットテーブル３４４から削除することもできる。

（ローカルプロビジョニングモジュール）
図８は、ＬＰＭ２２４のさらに詳細なブロック図を示している。ＬＰＭ２２４は、コンピューティングデバイス２０２などのコンピューティングデバイス上に常駐しているソフトウェアプロビジョニングシステム２００のクライアントサイドのコンポーネントである。ＬＰＭ２２４は、ソフトウェアプロビジョニングシステム２００によって提供されるサービスを使用してコンピューティングデバイスのユーザと対話することや、ネットワーク１０を介して配信サービスモジュール２０８と対話することなどを含むさまざまな機能を実行することができる。

ＬＰＭ２２４は、クライアントコンピューティングデバイス２０２によって使用される特定のログインプログラムと対話することによって、クライアントコンピューティングデバイス２０２上での特定の状態を強制する機能を実行することができる。クライアントデバイスが、ログインロジックとしてＷＰＡ（Ｗｉｎｄｏｗｓ（登録商標） ｐｒｏｄｕｃｔ ａｃｔｉｖａｔｉｏｎ）システムを使用している特定の実装形態においては、ＬＰＭ２２４は、ＷＰＡと対話して、クライアントコンピューティングデバイス２０２上での特定の状態を強制することができる。しかし、ある代替実装形態においては、ＬＰＭ２２４は、その他の任意の適切なオペレーティングシステムログインプログラムと対話することができる。ＬＰＭ２２４の実装形態は、ソフトウェア内に実装され、かつＷＰＡによって使用されるログインプログラムへとリンクされるライブラリとして構成されているさまざまな論理コンポーネントをグループ化したものとして、図８に記載されている。しかし、ＬＰＭ２２４の代替実装形態においては、ＬＰＭ２２４のさまざまな論理コンポーネントのうちの１つまたは複数をハードウェア内に実装することができる。

具体的には、ＬＰＭ２２４は、特定の状態で機能することをコンピューティングデバイス２０２に強制するための強制アドオンモジュール（ｅｎｆｏｒｃｅｍｅｎｔ ａｄｄ−ｏｎ ｍｏｄｕｌｅ）３５２と、ソフトウェアプロビジョニングシステム２００によって提供されるリソースの使用状況を測定するための測定モジュール（ｍｅｔｅｒｉｎｇ ｍｏｄｕｌｅ）３５４と、コアプロビジョニングサービス２０６によって提供されるプロビジョニングパケットを使用して処理を行うためのトランザクションエンジン３５６と、プロビジョニングパケット用の安全なストレージを提供するためのセキュアストレージマネージャー（ｓｅｃｕｒｅ ｓｔｏｒａｇｅ ｍａｎａｇｅｒ）３５８と、コアプロビジョニングサービス２０６と通信するための通信モジュール３６０と、ユーザと対話するためのユーザ経験モジュール（ｕｓｅｒ ｅｘｐｅｒｉｅｎｃｅ ｍｏｄｕｌｅ）３６２とを含むことができる。

強制アドオンモジュール３５２は、コンピューティングデバイス２０２のログインロジック３６４内に挿入することができる。ユーザが、ログインロジック３６４を使用してコンピューティングデバイス２０２にログオンしたときに、ログインロジック３６４内の強制アドオンモジュール３５２は、プロビジョニングパケットの残量情報を求めて測定モジュール３５４にクエリーを行うことができる。強制アドオンモジュール３５２は、コンピューティングデバイス２０２が十分なプロビジョニングパケットを有していると判定した場合には、ログインロジック３６４がその通常のルーチン内で機能できるようにすることができ、またユーザがコンピューティングデバイス２０２にログオンできるようにすることができる。しかし、強制アドオンモジュール３５２は、コンピューティングデバイス２０２が十分なプロビジョニングパケットを有していないと判定した場合には、非アクティブな状態に入るようコンピューティングデバイス２０２に強制する。そのような非アクティブな状態においては、コンピューティングデバイス２０２を起動するのにちょうど必要なだけの限られたユーザインターフェースが、コンピューティングデバイス２０２のユーザに提供される。

測定モジュール３５４は、残量マネージャー（ｂａｌａｎｃｅ ｍａｎａｇｅｒ）３６６を含むことができ、この残量マネージャー３６６は、提供されたリソースを使用するために利用可能な現在の残量を読み取って確認し、現在の残量を更新し、プロビジョニングパケットを処理する。測定モジュール３５４は、構成マネージャー３６８と、常に増進するタイマを維持するためのリライアブルクロックマネージャー（ｒｅｌｉａｂｌｅ ｃｌｏｃｋ ｍａｎａｇｅｒ）３７０とを含むこともできる。リライアブルクロックマネージャー３７０は、常に増進するタイマを維持するという課題を達成するために、リライアブルハードウェアクロック（ｒｅｌｉａｂｌｅ ｈａｒｄｗａｒｅ ｃｌｏｃｋ）３７２を使用することができる。残量マネージャー３６６およびリライアブルクロックマネージャー３７０は、ＬＰＭ２２４の安全なオペレーションにとって非常に敏感かつ重要であり、したがって、ＬＰＭ２２４のオペレーション中にさまざまなセキュリティー上の攻撃にさらされる可能性が高い。

強制アドオンモジュール３５２および測定モジュール３５４は、コンピューティングデバイス２０２上で提供されたリソースのアクティブ化および非アクティブ化を実施するために連携することができる。強制アドオンモジュール３５２は、特定のイベントに基づいて残量マネージャー３６６を呼び出すログインロジック３６４内のイベントディスパッチャーとして機能することができ、その一方で、残量マネージャー３６６は、イベントに応答して呼び出された際にどのアクションを取るべきかを判断することができる。強制アドオンモジュール３５２に残量マネージャー３６６をアクティブ化させることができるさまざまなイベントの例は、（１）ログオンイベント、（２）システムアンロックイベント、（３）ハイバネーションイベントからの復旧、（４）スタンバイイベントからの起動、（５）ユーザによってトリガーされたイベント、（６）ログオフイベント、（７）パケットのダウンロード、（８）タイマチック（ｔｉｍｅｒ ｔｉｃｋ）、（１０）システムロックイベント、（１１）スクリーンセーバの始動イベント、（１２）スクリーンセーバの停止イベントなどである。残量マネージャー３６６は、そのイベントを入力として受け取り、結果としてのアクションを強制アドオンモジュール３５２に返すことができる。

たとえば、ユーザがログオンしているときに、強制アドオンモジュール３５２は、ユーザログオンイベントを残量マネージャー３６６へ送信することができる。そのユーザログオンイベントに応答して、残量マネージャー３６６は、提供されたリソースを使用するために利用可能な現在の残量を問い合わせることができ、残量が十分である場合には、残量マネージャー３６６は、ログオンアクションを強制アドオンモジュール３５２に返すことができる。しかし、残量が十分でない場合には、強制アドオンモジュール３５２は、ログインロジック３６４に通知ユーザインターフェース（ＵＩ）３９８を返させることができ、この場合には、この通知ＵＩによって、ユーザは、プロビジョニングサービスモジュール２０４からさらなるプロビジョニングパケットを購入することによって残量を増やし、したがってコンピューティングデバイス２０２をアクティブ化することができる。

トランザクションエンジン３５６は、残量マネージャー３６６内の残量およびパケット消費カウンタを更新するためにプロビジョニングパケットを処理することができる。トランザクションエンジン３５６は、残量を更新するために、いかなるプロビジョニングパケットも必ず１回だけ消費されるようにすることができる。トランザクションエンジン３５６は、残量およびパケット消費カウンタを一緒に更新するように、したがって、残量およびパケット消費カウンタの双方が更新されるか、または残量およびパケット消費カウンタのどちらも更新されないかのいずれかになるように設計することができる。あるいは、トランザクションエンジン３５６は、何らかの予期せぬイベントによって残量データが駄目になることのないように残量データの一貫性を維持するために使用することもできる。トランザクションエンジン３５６の機能の一例を以降で提供する。

この例では、ユーザが、提供されたリソースのための使用時間を購入するために２枚のプリペイドカードを使用し、第１のカードは１０時間用で、第２のカードは２０時間用であると仮定する。プロビジョニングサービスモジュール２０４は、合計の残量を保持していないため、１０時間用および２０時間用という２つの別々のセットのライセンス情報が、プロビジョニングサービスモジュール２０４において作成される。ユーザが、プロビジョニングサービスモジュール２０４に連絡を取って、プロビジョニングパケットをコンピューティングデバイス２０２上にダウンロードする場合には、コンピューティングデバイス２０２上にダウンロードされるプロビジョニングパケットのそれぞれは、一意のプロビジョニングパケット番号を有する。トランザクションエンジン３５６は、第１のパケットを処理する際に、パケット消費カウンタを進めて、残量を１０時間増やし、次いで第２のパケットを処理する際に、再びパケット消費カウンタを進めて、残量をさらに２０時間増やす。

セキュアードストレージマネージャー（ｓｅｃｕｒｅｄ ｓｔｏｒａｇｅ ｍａｎａｇｅｒ）３５８は、残量データをユーザが改ざんできないように、および残量データにＬＰＭ２２４のみがアクセスできるように、保護された方法でＬＰＭ２２４が残量データを保存できるようにすることができる。プロビジョニングパケットは、ＬＰＭ２２４によってダウンロードされた後、セキュアードストレージマネージャー３５８内に保存することができる。同様に、残量カウンタおよびパケット消費カウンタも、セキュアードストレージマネージャー３５８内に保存することができる。図示されている実装形態においては、セキュアードストレージマネージャー３５８は、ｄｌｌ（ｄｙｎａｍｉｃ ｌｉｎｋ ｌｉｂｒａｒｙ）として実装され、それによって、ユーザ経験モジュール３６２は、セキュアードストレージマネージャー３５８にアクセスすることができる。

セキュアードストレージマネージャー３５８内に保存されているデータの安全を確保するために、データ暗号化キーを使用して、データをセキュアードストレージマネージャー３５８内に保存することができ、データ暗号化キーを有するモジュールのみが、セキュアードストレージマネージャー３５８からデータを読み取ることができる。セキュアードストレージマネージャー３５８は、ＬＳＡデータベース３７６と通信するためのローカルセキュリティーオーソリティー（ＬＳＡ）サブシステム（ｌｏｃａｌ ｓｅｃｕｒｉｔｙ ａｕｔｈｏｒｉｔｙ （ＬＳＡ） ｓｕｂｓｙｓｔｅｍ）３７４、セキュアハードウェアストレージ（ｓｅｃｕｒｅ ｈａｒｄｗａｒｅ ｓｔｏｒａｇｅ）３８０と通信するためのストレージドライバ３７８、およびコンピューティングデバイス２０２上のファイル３８４と通信するためのファイルシステムドライバ３８２と通信することができる。さらなるセキュリティーのために、セキュアードストレージマネージャー３５８の代替実装形態は、セキュアードストレージマネージャー３５８内に保存されているデータの複数のコピーを使用することもでき、それによって、それぞれのコピーを相互参照して、データのどの単一のコピーにも改ざんがまったくないようにすることができる。ここで論じているＬＰＭ２２４の実装形態では、セキュアードストレージマネージャー３５８はソフトウェア内に実装されているが、ある代替実装形態においては、セキュアードストレージマネージャー３５８をハードウェア内に実装することもできる。

通信モジュール３６０は、プロビジョニングパケットおよび／または証明書をプロビジョニングサービスモジュール２０４に要求するためのパケット／証明書要求マネージャー３８６と、さらなるプロビジョニングパケットを課金システム２１６から、および／またはプロビジョニングサービスモジュール２０４から購入するための購入マネージャー３８８と、ＬＰＭ２２４がネットワーク１０と通信できるようにするウェブサービス通信マネージャー３９０とを含むことができる。

パケット／証明書要求マネージャー３８６は、ユーザ経験モジュール３６２からの要求を受信して、パケットまたは証明書をプロビジョニングサービスモジュール２０４に要求することができる。たとえば、ユーザがＩｎｉｔＫｅｙをＵＩに入力することによってクライアントデバイスに初めてログオンしている場合には、ユーザ経験モジュール３６２は、そのＩｎｉｔＫｅｙをパケット／証明書要求マネージャー３８６に渡すことができ、パケット／証明書要求マネージャー３８６は、プロビジョニングサービスモジュール２０４と通信して、プロビジョニングサービスモジュール２０４から証明書を受け取ることができる。パケット／証明書要求マネージャー３８６は、証明書またはプロビジョニングパケットが首尾よくダウンロードされたらプロビジョニングサービスモジュール２０４に確認応答を行うことを担当することもできる。パケット／証明書要求マネージャー３８６は、プロビジョニングプロトコルを使用して、プロビジョニングサービスモジュール２０４と通信することができる。パケット／証明書要求マネージャー３８６によってダウンロードされたパケットは、セキュアードストレージマネージャー３５８内に保存することができる。

購入マネージャー３８８は、コンピューティングデバイス２０２のユーザから支払情報を受信して、その支払情報を課金システム２１６へ、またはプロビジョニングサービスモジュール２０４へ伝達することによって、そのユーザがさらなるプロビジョニングパケットを購入できるようにすることができる。パケット／証明書要求マネージャー３８６および購入マネージャー３８８の双方は、ウェブサービス通信マネージャー３９０を使用して、ネットワーク１０と通信することができる。ウェブサービス通信マネージャーは、ネットワークサービスマネージャー３９２およびネットワークインターフェースカード（ＮＩＣ）３９４を使用して、ネットワーク１０と通信することができる。この実装形態においては、ネットワーク１０と通信するために、ウェブサービス通信マネージャー３９０が使用されているが、代替実装形態においては、ネットワーク１０と通信するために、ＦＴＰ（ｆｉｌｅ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）ドライバなどのその他の通信ツールを使用することができるという点に留意されたい。

ユーザ経験モジュール３６２は、パケット／証明書要求マネージャー３８６がプロビジョニングサービスモジュール２０４から証明書をダウンロードできるようにするＩｎｉｔＫｅｙを入力するようユーザに要求するためのアクティブ化ユーザインターフェース（ＵＩ）３９６と、ＬＰＭ２２４がユーザと対話できるようにする通知ＵＩ３９８とを含むことができる。たとえばユーザが、提供されたリソースを使用するためのプリペイドカードを購入している場合には、アクティブ化ＵＩ３９６は、そのプリペイドカードによって提供される番号を入力するようユーザに要求し、パケット／証明書要求マネージャー３８６を呼び出して、そのプリペイドカード番号に対応する最新のプロビジョニングパケットをダウンロードすることができる。アクティブ化ＵＩ３９６は、購入マネージャー３８８を呼び出して、ユーザがさらなるプロビジョニングパケットを購入できるようにすることもでき、また購入の完了時にパケット／証明書要求マネージャー３８６を自動的に呼び出して、その購入に対応するプロビジョニングパケットをダウンロードできるように設計することができる。

通知ＵＩ３９８は、ユーザが現在の残量情報や使用履歴などを問い合わせることができるようにするさまざまなユーザインターフェースを含むことができる。通知ＵＩ３９８は、ユーザによって、またはログインロジック３６４によって呼び出すことができる。提供されたリソースを使用するために利用可能な残量が少ない状況では、ログインロジック３６４は、通知ＵＩ３９８を呼び出して、さらなる購入が必要であることをユーザに知らせることができる。通知ＵＩは、絶え間なくアクティブであることができ、タスクバーアイコン、コントロールパネルアプレット、バルーンポップアップ（ｂａｌｌｏｏｎ ｐｏｐ−ｕｐ）を介して、またはその他の任意の一般に知られているＵＩの方法を使用することによって、通知サービスをユーザに提供することができる。

ソフトウェアプロビジョニングシステム２００のさまざまなコンポーネントについて説明したが、以降の図９〜図１２では、ソフトウェアプロビジョニングシステム２００のオペレーションについてさらに詳しく説明する。

（ＩｎｉｔＫｅｙの登録）
図９は、ＩｎｉｔＫｅｙをコアプロビジョニングサービス２０６に登録するために使用できる登録プログラム４３０のフローチャートを示している。ブロック４３２において、ＩｎｉｔＫｅｙのプロバイダは、ＩｎｉｔＫｅｙ登録要求をコアプロビジョニングサービス２０６へ送信する。前述のように、このプロバイダは、コンピューティングデバイス２０２のベンダ、コンピューティングデバイス２０２のオペレーティングシステム用の使用権のベンダ、ソフトウェアプロビジョニングシステム２００の顧客サービス担当者（ＣＳＲ、ｃｕｓｔｏｍｅｒ ｓｅｒｖｉｃｅ ｒｅｐｒｅｓｅｎｔａｔｉｖｅ）など、サードパーティーによって管理できる課金システム２１６とすることができる。

ＩｎｉｔＫｅｙ登録要求は、コアプロビジョニングサービス２０６のメッセージ待ち行列内で受信することができる。コアプロビジョニングサービス２０６は、そのメッセージ待ち行列内でＩｎｉｔＫｅｙ登録要求を認識すると、ブロック４３４において、登録プロセスを開始することができる。

ブロック４３６においては、ＩｎｉｔＫｅｙをコアデータベース２１２のブートストラップテーブル３１２に追加することができ、登録プログラム４３０は、ブートストラップステータスを「Ｃｒｅａｔｅｄ」に設定することができる。

その後、ブロック４３８において、コアプロビジョニングサービス２０６は、「Ｂｏｏｔｓｔｒａｐ Ｃｒｅａｔｅｄ」のメッセージをコンピューティングデバイスログテーブル３２２内に記録することができる。

最後に、ブロック４４０において、コアプロビジョニングサービス２０６は、「Ｂｏｏｔｓｔｒａｐ Ｐｕｂｌｉｓｈ」のメッセージを配信データベース２１４のメッセージ待ち行列へ送信することができる。

（パケットの作成）
図１０は、コンピューティングデバイス２０２のＬＰＭ２２４によって使用されるプロビジョニングパケットを作成するために使用できるパケット作成プログラム４５０のフローチャートを示している。

ブロック４５２において、課金アダプタ２１８は、プロビジョニングパケットを求めるプロビジョニング要求メッセージをコアプロビジョニングサービス２０６へ送信することができる。コアプロビジョニングサービス２０６は、複数の引受会社に接続することができるため、このようなプロビジョニング要求メッセージは、課金アダプタ２１８をコアプロビジョニングサービス２０６へ接続するＭＳＭＱインターフェース内で待ち行列に入れられる。

プロビジョニング要求メッセージを課金アダプタ２１８から検索すると、ブロック４５４において、コアプロビジョニングサービス２０６は、パケット作成トランザクションを開始することができる。

ブロック４５６において、コアプロビジョニングサービス２０６は、プロビジョニング要求メッセージからのハードウェアＩＤを使用して、新たなコンピューティングデバイスレコードをコンピューティングデバイステーブル３１４に追加することができる。しかし、そのハードウェアＩＤを含むレコードが、コンピューティングデバイステーブル３１４内に既に存在する場合には、新たなコンピューティングデバイスレコードを追加することは必要でないかもしれない。

その後、ブロック４５８において、コアプロビジョニングサービス２０６は、新たなジョブレコードをジョブテーブル３１６に追加して、プロビジョニングパケットを求める新たなジョブ要求を記録することができる。コアプロビジョニングサービス２０６は、新たに追加されたジョブレコードのステータスを「Ｃｒｅａｔｅｄ」に設定することができる。ブロック４６０において、コアプロビジョニングサービス２０６は、プロビジョニング要求メッセージの日付および時間と共に、新たなレコードをジョブログテーブル３２６内に追加することができる。

ブロック４６２において、コアプロビジョニングサービス２０６は、プロビジョニング要求メッセージに基づいてプロビジョニングパケットを作成することができる。パケットの作成は、プロビジョニング要求メッセージ内で提供される証明書を確認すること、プロビジョニングパケットの使用時間の量を追加することなどを含むことができる。

ブロック４６４において、コアプロビジョニングサービス２０６は、キーマネージャー２９２と通信して、安全なキーを用いてプロビジョニングパケットに署名し、ＸＭＬベースのプロビジョニングパケットを作成することができる。

プロビジョニングパケットが作成されると、ブロック４６６において、コアプロビジョニングサービス２０６は、コンピューティングデバイステーブル３１４内の最後のシーケンス番号を１つ増やすことができる。

ブロック４６８において、コアプロビジョニングサービス２０６は、新たに作成されたプロビジョニングパケットをパケットテーブル３１８内に挿入し、パケットテーブル３１８内のプロビジョニングパケットのステータスを「ｐａｃｋｅｔ ｃｒｅａｔｅｄ」に設定することができる。

その後、ブロック３７０において、コアプロビジョニングサービス２０６は、「ｐａｃｋｅｔ ｃｒｅａｔｅｄ」のメッセージをジョブログテーブル３２６内に記録することができる。そして最後に、ブロック３７２において、コアプロビジョニングサービス２０６は、「ｐａｃｋｅｔ ｐｕｂｌｉｓｈ」のメッセージを配信データベースライタ２２０へのメッセージ待ち行列内に送信して、そのパケットを配信データベース２１４内に追加することができる。

（ブートストラッピング）
図１１は、証明書を証明書サービスモジュール２１０に要求して、その証明書をコンピューティングデバイス２０２へ送信するために使用できるブートストラッピングプログラム５００のフローチャートを示している。

ブロック５０２において、配信サービスモジュール２０８は、コンピューティングデバイス２０２などのコンピューティングデバイスからの証明書要求を受信することができる。この証明書要求は、パケット／証明書要求マネージャー３８６によって作成し、ＩｎｉｔＫｅｙなどのコンピューティングデバイス２０２用のハードウェアＩＤを含む情報を含むことができる。

ブロック５０４において、コアプロビジョニングサービス２０６は、ブートストラップテーブル３１２内でＩｎｉｔＫｅｙを探すことができる。ブロック５０６において、コアプロビジョニングサービス２０６は、コンピューティングデバイステーブル３１４をチェックして、証明書要求内で提供されているハードウェアＩＤに関するレコードが含まれているかどうかを確認することができる。コンピューティングデバイステーブル３１４内に何のレコードも存在しない場合には、コアプロビジョニングサービス２０６は、レコードをコンピューティングデバイステーブル３１４内に追加することができる。

ブロック５０８において、コアプロビジョニングサービス２０６は、「ｃｏｍｐｕｔｉｎｇ ｄｅｖｉｃｅ ｃｒｅａｔｅｄ」のメッセージをコンピューティングデバイスログテーブル３２２内に記録することができる。その後、ブロック５１０において、コアプロビジョニングサービス２０６は、証明書要求トランザクションの処理を開始することができる。

ブロック５１２において、コアプロビジョニングサービス２０６は、ブートストラップテーブル３１２をチェックして、配信回数が、構成テーブル３２０によって指定された最大配信回数よりも多いかどうかを確認することができ、そうである場合には、コントロールをブロック５２４に移すことができる。

配信回数が最大配信回数よりも多くない場合には、ブロック５１４において、コアプロビジョニングサービス２０６は、ブートストラップテーブル３１２内のブートストラップステータスをチェックすることができる。ブートストラップステータスが、「ｃｒｅａｔｅｄ」または「Ｉｎ Ｐｒｏｇｒｅｓｓ」に相当しない場合には、コントロールをブロック５２４に移すことができる。

しかしブートストラップステータスが、「ｃｒｅａｔｅｄ」または「Ｉｎ Ｐｒｏｇｒｅｓｓ」のいずれかに相当する場合には、ブロック５１６において、コアプロビジョニングサービス２０６は、ブートストラップテーブル３１２内のブートストラップステータスを「Ｉｎ Ｐｒｏｇｒｅｓｓ」に更新することができる。

その後、ブロック５１８において、コアプロビジョニングサービス２０６は、「ｂｏｏｔｓｔｒａｐ ｉｎ ｐｒｏｇｒｅｓｓ」のメッセージをコンピューティングデバイスログテーブル３２２内に記録することができる。

ブロック５２０において、コアプロビジョニングサービス２０６は、証明書ユーティリティーを呼び出して、新たなクライアント証明書を作成することができる。新たな証明書を証明書ユーティリティーから受け取ると、ブロック５２２において、コアプロビジョニングサービス２０６は、そのクライアント証明書を配信サービスモジュール２０８のメッセージ待ち行列内に送信することができ、コントロールをブロック５３０に移すことができる。

ブロック５２４において、コアプロビジョニングサービス２０６は、ブートストラップテーブル内の配信回数が最大配信回数を超えたことによって、ブートストラップテーブル３１２内のブートストラップステータスを「ｏｖｅｒ ｌｉｍｉｔ」に更新することができる。この「ｏｖｅｒ ｌｉｍｉｔ」のステータスは、コアプロビジョニングサービス２０６が、コンピューティングデバイス２０２のための証明書を発行したことに応答してＬＰＭ２２４から適切な確認応答を受信していないということを意味する。したがって、ブロック５２６において、コアプロビジョニングサービス２０６は、証明書を要求しているコンピューティングデバイスから確認応答がまったく受信されていないということを示す「ｂｏｏｔｓｔｒａｐ ｏｖｅｒ ｌｉｍｉｔ」のメッセージをコンピューティングデバイスログテーブル３２２内に記録することができる。

ブロック５２８において、コアプロビジョニングサービス２０６は、「ｒｅｍｏｖｅ ｂｏｏｔｓｔｒａｐ」のメッセージを配信データベースライタ２２０のメッセージ待ち行列内に送信して、ブートストラップレコードを配信データベース２１４から削除することができる。

ブロック５３０は、証明書がクライアントへ送信されると、ブロック５２２からコントロールを受け取ることができ、したがって、証明書要求の処理の終了を表している。

証明書要求が処理されると、ブロック５３２において、コアプロビジョニングサービス２０６は、配信サービスモジュール２０８のメッセージ待ち行列内の証明書ダウンロード完了メッセージを受信することができる。このような証明書ダウンロード完了メッセージは、証明書が首尾よくダウンロードされた後に、ＬＰＭ２２４のパケット／証明書要求マネージャー３８６によって送信することができる。

証明書ダウンロード完了メッセージを受信すると、ブロック５３４において、コアプロビジョニングサービス２０６は、ブートストラップ完了トランザクション（ｂｏｏｔｓｔｒａｐ ｃｏｍｐｌｅｔｅｄ ｔｒａｎｓａｃｔｉｏｎ）を開始することができる。ブロック５３６において、コアプロビジョニングサービス２０６は、ブートストラップテーブル３１２内のブートストラップステータスを「ｃｏｍｐｌｅｔｅｄ」に更新することができる。その後、ブロック５３８において、コアプロビジョニングサービス２０６は、証明書要求を送信しているコンピューティングデバイスのためのブートストラッププロセスが完了したということを示す「ｂｏｏｔｓｔｒａｐ ｃｏｍｐｌｅｔｅｄ」のメッセージをコンピューティングデバイスログテーブル３２２内に記録することができる。

最後に、ブロック５４０において、コアプロビジョニングサービス２０６は、「ｒｅｍｏｖｅ ｂｏｏｔｓｔｒａｐ」のメッセージを配信データベースライタ２２０のメッセージ待ち行列内に送信して、ブートストラップレコードを配信データベース２１４のブートストラップテーブル３４２から削除することができる。

（パケットの配信）
図１２は、プロビジョニングパケットをコアプロビジョニングサービス２０６からコンピューティングデバイス２０２などのさまざまなコンピューティングデバイスへ配信するために使用できるパケット配信プログラム５５０のためのフローチャートを示している。パケット配信プログラム５５０は、パケット／証明書要求マネージャー３８６によって、コンピューティングデバイスのユーザを補助する顧客サービス担当者によって、あるいはその他の類似の方法で開始することができる。

ブロック５５２において、コアプロビジョニングサービス２０６は、配信サービスモジュール２０８のメッセージ待ち行列内のパケットダウンロードメッセージを受信することができる。このようなメッセージは、たとえばコンピューティングデバイス２０２のパケット／証明書要求マネージャー３８６によって送信することができる。パケットダウンロードメッセージを受信すると、ブロック５５４において、コアプロビジョニングサービス２０６は、パケット要求トランザクションを開始することができる。

パケット要求トランザクションのはじめに、ブロック５５６において、確認サービス２０９は、パケットテーブル３１８内のステータスが、パケットダウンロードメッセージを送信しているコンピューティングデバイスがコアプロビジョニングサービス２０６による以前のパケット送信に対して確認応答を行っていないということを指定する「ｐａｃｋｅｔ ｏｖｅｒ ｌｉｍｉｔ」であるかどうかを判定することができ、コントロールは、ブロック５６４に移される。

パケットテーブル３１８内のステータスが「ｐａｃｋｅｔ ｏｖｅｒ ｌｉｍｉｔ」ではないと判定された場合には、ブロック５５８において、コアプロビジョニングサービス２０６は、パケットテーブル３１８内のステータスを「ｄｅｌｉｖｅｒｙ ｉｎ ｐｒｏｇｒｅｓｓ」に更新することができる。

その後、ブロック５６０において、コアプロビジョニングサービス２０６は、パケットテーブル３１８内の配信回数を、パケットダウンロードメッセージ内で指定されている値に更新することができる。たとえば、パケットダウンロードメッセージが、２つのパケットをコアプロビジョニングサービス２０６に要求している場合には、パケットテーブル３１８内の配信回数は、２だけ増加される。ブロック５６２において、コアプロビジョニングサービス２０６は、「ｐａｃｋｅｔ ｄｅｌｉｖｅｒｙ ｉｎ ｐｒｏｇｒｅｓｓ」のメッセージをジョブログテーブル３２６内に記録することができる。

ブロック５６４は、コンピューティングデバイスからの確認応答がないことによってコントロールを受け取ることができ、したがってブロック５６４において、コアプロビジョニングサービス２０６は、パケットテーブル３１８内のステータスを「ｏｖｅｒ ｌｉｍｉｔ」に更新することができる。

ブロック５６６において、確認サービス２０９は、パケットテーブル３１８内の配信回数を、パケットダウンロードメッセージ内で指定されている値に更新することができ、ブロック５６８において、ＣＰＳは、ジョブテーブル３１６のステータスを「ｅｒｒｏｒ」に更新する。最後に、ブロック５７０において、確認サービス２０９は、「ｐａｃｋｅｔ ｏｖｅｒ ｌｉｍｉｔ」のメッセージをジョブログテーブル３２６内に記録することができる。

ブロック５７２において、配信サービス２０８は、パケット要求トランザクションの処理を終了することができ、確認サービス２０９は、パケットを要求しているコンピューティングデバイスからの確認応答を待つことができる。ブロック５７４において、確認サービス２０９は、配信サービスモジュール２０８のメッセージ待ち行列内へのパケットダウンロード完了メッセージを受信することができる。このパケットダウンロード完了メッセージは、要求されているパッケージが首尾よくダウンロードされた際に、パケット／証明書要求マネージャー３８６によって送信することができる。

パケットダウンロード完了メッセージを受信すると、ブロック５７６において、確認サービス２０９は、パケットダウンロード完了トランザクションを開始することができる。パケットダウンロード完了トランザクションの一環として、ブロック５７８において、確認サービスは、パケットテーブル３１８内のステータスを「ｃｏｍｐｌｅｔｅｄ」に更新し、ブロック５８０において、ジョブテーブル内のステータスも「ｃｏｍｐｌｅｔｅｄ」に更新することができる。

さらに、ブロック５８０において、コアプロビジョニングサービス２０６は、「ｊｏｂ ｃｏｍｐｌｅｔｅｄ」のメッセージをジョブログテーブル３２６内に記録し、ブロック５８２において、パケットダウンロード完了トランザクションを終了することができる。

ソフトウェアプロビジョニングシステム２００のさまざまなコンポーネントのオペレーションについて説明してきたが、以降の図１３〜図１６では、さまざまな状況のもとでのユーザの経験を示すさまざまな例示的なシナリオについて説明する。

（シナリオ１−ログイン中の残量の確認）
図１３は、ＬＰＭ２２４のオペレーション中の第１のシナリオを示すフローチャート６００を示している。具体的には、フローチャート６００は、ユーザがコンピュータにログオンしている場合のシナリオを示している。図１３に示されているように、ブロック６０２において、ユーザがコンピューティングデバイス２０２へのログオンを試みているときに、強制アドオンモジュール３５２は、ログオンイベントを残量マネージャー３６６に送信することができる。このログオンイベントに応答して、ブロック６０４において、残量マネージャー３６６は、コンピューティングデバイス２０２上でオペレーティングシステムを使用するために利用可能な残量を確認することができる。残量が十分である場合には、ブロック６０６において、残量マネージャー３６６は、オペレーティングシステムを通常の方法でアクティブ化するようログインロジック３６４に通知することができる。

しかし、残量が十分でないと残量マネージャー３６６が判定した場合には、ブロック６０８において、残量マネージャー３６６は、アクティブ化ＵＩ３９６をアクティブ化することができる。アクティブ化ＵＩをアクティブ化する目的は、ユーザがさらなる使用時間を購入できるようにすることである。

ブロック６１０において、アクティブ化ＵＩ３９６は、購入マネージャー３８８をアクティブ化することができ、ユーザは、購入を行うことができる。ユーザは、課金システム２１６に接続することによって、顧客サービス担当者に電話をかけることによって、あるいはその他の任意の所望の方法で、購入を行うことができる。その後、ブロック６１２において、証明書／パケット要求マネージャー３８６は、プロビジョニングパケットをダウンロードすることができる。

証明書／パケット要求マネージャー３８６は、ダウンロードされたプロビジョニングパケットを安全なストレージのためのセキュアストアマネージャ３５８に提供することができる。ブロック６１４において、残量マネージャー３６６は、ダウンロードされたプロビジョニングパケットを分析することができ、ブロック６１６において、コンピューティングデバイス２０２にとって利用可能なプロビジョニング残量（ｐｒｏｖｉｓｉｏｎｉｎｇ ｂａｌａｎｃｅ）をしかるべく増やすことができる。

（シナリオ２−ログオン後の使用権の購入）
図１４は、ＬＰＭ２２４のオペレーション中の第２のシナリオを示すフローチャート６２０を示している。具体的には、フローチャート６２０は、ユーザがコンピューティングデバイス２０２に既にログオンしていて、コントロールパネルアプレットまたはタスクバーアイコンを選択して、残量マネージャ３６６をアクティブ化する場合のシナリオを示している。

ブロック６２２において、ユーザは、イベントを残量マネージャー３６６に送信するコントロールパネルアプレットをアクティブ化することができる。残量マネージャー３６６は、現在の残量情報をユーザに表示して、アクティブ化ＵＩ３９６を呼び出し、それによって購入マネージャー３８８をアクティブ化することができる。ユーザがさらなる時間の購入を行うと、証明書／パケット要求マネージャー３８６は、プロビジョニングパケットをダウンロードすることができる。

証明書／パケット要求マネージャー３８６は、ダウンロードされたプロビジョニングパケットを安全なストレージのためのセキュアストアマネージャ３５８に提供することができる。ブロック６２８において、残量マネージャー３６６は、ダウンロードされたプロビジョニングパケットを分析することができ、ブロック６３０において、コンピューティングデバイス２０２にとって利用可能なプロビジョニング残量をしかるべく増やすことができる。

（シナリオ３−ログオン後の残量の更新および通知）
図１５は、ＬＰＭ２２４のオペレーション中の第３のシナリオを示すフローチャート６４０を示している。具体的には、フローチャート６４０は、ユーザがコンピューティングデバイス２０２に既にログオンしていて、ログインロジック３６４がリライアブルクロックマネージャー３７０からのタイムチックの結果としてのイベントを受信する場合のシナリオを示している。

ブロック６４２において、ログインロジック３６４は、リライアブルクロックマネージャー３７０からタイムチックイベントを受信することができる。結果として、ログインロジック３６４は、タイムチックイベントを残量マネージャー３６６へ送信することができる。

そのタイムチックイベントに応答して、ブロック６４４において、残量マネージャー３６６は、コンピューティングデバイス２０２上でオペレーティングシステムを使用するために利用可能な残量を更新することができる。その後、ブロック６４６において、残量マネージャー３６６は、利用可能な残量をチェックする。その評価の結果に基づいて、ブロック６４８において、残量マネージャー３６６は、適切なアクションを取ることができ、このアクションは、たとえば、アクティブ化ＵＩ３９６をアクティブ化すること、ユーザをログオフさせること、その他の適切なアクションを継続することとすることができる。

（シナリオ４−コンピューティングデバイスの非アクティブ化）
図１６は、ＬＰＭ２２４のオペレーション中の第４のシナリオを示すフローチャート６６０を示している。具体的には、フローチャート６６０は、ユーザがコンピューティングデバイス２０２に既にログオンしていて、ログインロジック３６４がリライアブルクロックマネージャー３７０からのタイムチックの結果としてのイベントを受信する場合のシナリオを示している。

ブロック６６２において、ログインロジック３６４は、リライアブルクロックマネージャー３７０からタイムチックイベントを受信することができる。結果として、ログインロジック３６４は、タイムチックイベントを残量マネージャー３６６へ送信することができる。

そのタイムチックイベントに応答して、ブロック６６４において、残量マネージャー３６６は、コンピューティングデバイス２０２上でオペレーティングシステムを使用するために利用可能な残量を更新することができる。その後、ブロック６６６において、残量マネージャー３６６は、利用可能な残量をチェックすることができる。その評価の結果に基づいて、ブロック６６８において、残量マネージャー３６６は、適切なアクションを取ることができ、このアクションは、たとえば、アクティブ化ＵＩ３９６をアクティブ化すること、ユーザをログオフさせること、その他の適切なアクションを継続することとすることができる。

この場合には、たとえば、残量マネージャー３６６は、コンピューティングデバイス２０２にとって利用可能な残量が、しきい値にあるか、またはゼロなど、しきい値を下回っていることを検知する。結果として、ブロック６６８において、残量マネージャー３６６は、通知ＵＩ３９８にログオフメッセージを表示させることができ、最終的には、コンピューティングデバイス２０２上でオペレーティングシステムを使用している状態からユーザをログオフさせる。別の場合には、通知ＵＩ３９８は、購入マネージャー３８８をアクティブ化して、ユーザがさらなる使用時間を購入できるようにすることもできる。

（シナリオ５−ログオン後の前払いの入力）
図１７は、ＬＰＭ２２４のオペレーション中の第５のシナリオを示すフローチャート６８０を示している。具体的には、フローチャート６８０は、ユーザがコンピューティングデバイス２０２に既にログオンしていて、コントロールパネルアプレットまたはタスクバーアイコンを選択して、プリペイドカードから情報を入力するためにアクティブ化ウィザードをアクティブ化する場合のシナリオを示している。これは、ユーザがプリペイドカードを以前に購入していて、そのプリペイドカードによって入手できる使用時間を自分のアカウントに追加しようと決めた場合に当てはまるかもしれない。

ブロック６８２において、ユーザは、アクティブ化ウィザードを表示するためのアクティブ化ＵＩ３９６へイベントを送信するコントロールパネルアプレットをアクティブ化することができる。ユーザに表示できるＧＵＩウィンドウの一例について、図１８の追加時間ウィンドウ６８４によって説明する。ユーザは、追加時間ウィンドウ６８４から追加時間ボタンを選択して、プリペイドカードからの情報を入力することができる。

その後、ブロック６８６において、アクティブ化ＵＩ３９６は、ユーザがアクティブ化ウィザードを使用できるようにする上で必要となるかもしれないさまざまな情報をユーザに通知することができ、このアクティブ化ウィザードは、図１９のＧＵＩ６８８によって示されている。

ブロック６９０において、アクティブ化ＵＩ３９６は、図２０に示されているようなネットワーク接続ＧＵＩ６９２を提示することができ、このネットワーク接続ＧＵＩ６９２は、ウェブサービス通信マネージャー３９０がコアプロビジョニングサービス２０６にアクセスするためにインターネットに接続していることをユーザに通知する。

その後、ブロック６９４において、アクティブ化ＵＩ３９６は、プリペイド使用権カード（ｐｒｅ−ｐａｉｄ ｕｓａｇｅ ｃａｒｄ）から受け取ったキーを入力するようユーザに促すことができる。プリペイドカード上のキーは、英数字やその他の文字の文字列を含むことができる。この場合には、キーは、図２１のＧＵＩ６９６へ入力するものとして示されているように、２５文字の長さの英数字のキーである。

プリペイドカードからのキーを受信すると、ブロック６９８において、アクティブ化ＵＩ３９６は、図２２のＧＵＩ７００によって示されているように、．ＮＥＴ（登録商標）システムにログインするようユーザに促すことができる。ユーザが．ＮＥＴ（登録商標）システムにログインすることが常に必要というわけではないかもしれないという点に留意されたい。

その後、ブロック７０２において、アクティブ化ＵＩ３９６は、プリペイドカードからのユーザのキーが受け入れられたこと、および対応する時間だけユーザのアカウントが増えるはずであることの確認をコアプロビジョニングサービス２０６から受信することができる。首尾よく時間が追加されたことを通知するメッセージは、図２３のＧＵＩ７０４によって示されている。

最後に、ブロック７０６において、アクティブ化ＵＩ３９６は、図２４のＧＵＩ７０８によって示されているように、ユーザがプリペイドカードを使用することによって今しがた追加した時間が数分でコンピューティングデバイス２０２の貸方に記入される旨をユーザに通知することができる。

上述の文章は、本発明の多くの異なる実施形態の詳細な説明を記載しているが、本発明の範囲は、本特許に添付されている特許請求の範囲の文言によって定義されるという点を理解されたい。この詳細な説明は、例示的なものにすぎないと解釈されるべきであり、本発明の可能な実施形態をすべて説明しているわけではない。というのも、可能な実施形態をすべて説明することは、不可能ではないにしても、非現実的と思われるためである。本発明を定義する特許請求の範囲内に今後とも収まるであろう現在の技術または本特許の出願日以降に開発される技術を使用して、多くの代替実施形態を実施することができる。

したがって、本発明の趣旨および範囲から逸脱することなく、本明細書で説明および例示されている技術および構造において、多くの修正形態および変形形態を作成することができる。したがって、本明細書に記載されている方法および装置は、例示的なものにすぎず、本発明の範囲を限定するものではないという点を理解されたい。

複数のコンピューティングリソースを相互接続するネットワークを示すブロック図である。 図１のネットワークに接続することができるコンピュータを示すブロック図である。 図１のネットワークのコンピュータ上にオペレーティングシステムを提供するためのソフトウェアプロビジョニングシステムを示すブロック図である。 図３のソフトウェアプロビジョニングシステム上でのコンピュータの登録を示すフローチャートである。 図３のソフトウェアプロビジョニングシステムのコアプロビジョニングシステム（ｃｏｒｅ ｐｒｏｖｉｓｉｏｎｉｎｇ ｓｙｓｔｅｍ）を示すブロック図である。 図５のコアプロビジョニングシステムによって使用されるコアデータベースを示すブロック図である。 図３のコアソフトウェアプロビジョニングシステムによって使用される配信データベースを示すブロック図である。 図３のソフトウェアプロビジョニングシステムのローカルプロビジョニングモジュール（ｌｏｃａｌ ｐｒｏｖｉｓｉｏｎｉｎｇ ｍｏｄｕｌｅ）を示すブロック図である。 図３のソフトウェアプロビジョニングシステムによって使用されるキー登録プログラムを示すフローチャートである。 図３のソフトウェアプロビジョニングシステムによって使用されるパケット作成プログラムを示すフローチャートである。 図３のソフトウェアプロビジョニングシステムによって使用されるブートストラッピングプログラム（ｂｏｏｔｓｔｒａｐｐｉｎｇ ｐｒｏｇｒａｍ）を示すフローチャートである。 図３のソフトウェアプロビジョニングシステムによって使用されるパケット配信プログラムを示すフローチャートである。 図８のローカルプロビジョニングモジュールのためのオペレーティングシナリオ（ｏｐｅｒａｔｉｎｇ ｓｃｅｎａｒｉｏ）を示すフローチャートである。 図８のローカルプロビジョニングモジュールのためのオペレーティングシナリオを示す別のフローチャートである。 図８のローカルプロビジョニングモジュールのためのオペレーティングシナリオを示す別のフローチャートである。 図８のローカルプロビジョニングモジュールのためのオペレーティングシナリオを示す別のフローチャートである。 図８のローカルプロビジョニングモジュールのためのオペレーティングシナリオを示すさらに別のフローチャートである。 図１７のオペレーティングシナリオの最中にユーザに提示される例示的なＧＵＩを示す図である。 図１７のオペレーティングシナリオの最中にユーザに提示される別の例示的なＧＵＩを示す図である。 図１７のオペレーティングシナリオの最中にユーザに提示される別の例示的なＧＵＩを示す図である。 図１７のオペレーティングシナリオの最中にユーザに提示される別の例示的なＧＵＩを示す図である。 図１７のオペレーティングシナリオの最中にユーザに提示される別の例示的なＧＵＩを示す図である。 図１７のオペレーティングシナリオの最中にユーザに提示される別の例示的なＧＵＩを示す図である。 図１７のオペレーティングシナリオの最中にユーザに提示される別の例示的なＧＵＩを示す図である。

Claims (20)

1. プロビジョニングパケットをコンピュータに配信する方法であって、
   第１のプロビジョニングパケットを受信することであって、前記プロビジョニングパケットは、前記コンピュータに関連付けられている第１の識別子を有すること、
   前記第１のプロビジョニングパケットを待ち行列に入れること、
   第２の識別子を含むパケット要求を受信すること、
   前記第１の識別子が前記第２の識別子と一致した場合に前記プロビジョニングパケットを前記コンピュータへ送信すること
   を含むことを特徴とする方法。
2. 前記プロビジョニングパケットを前記コンピュータへ送信することを記録することをさらに含むことを特徴とする請求項１に記載の方法。
3. 前記プロビジョニングパケットの受信の確認を前記コンピュータから受け取ることをさらに含むことを特徴とする請求項１に記載の方法。
4. 前記第２の識別子を含む複数のパケット要求が、受信の確認を受け取る前に、ある限度を超えた場合に、前記プロビジョニングパケットを待ち行列から外すことをさらに含むことを特徴とする請求項１に記載の方法。
5. 前記第１の識別子を有する第２のプロビジョニングパケットを受信すること、
   前記第２のプロビジョニングパケットを待ち行列に入れることをさらに含むことを特徴とする請求項１に記載の方法。
6. 前記第１の識別子が前記第２の識別子と一致した場合に、前記パケット要求に応答して前記プロビジョニングパケットと共に前記第２のプロビジョニングパケットを送信することをさらに含むことを特徴とする請求項５に記載の方法。
7. 前記プロビジョニングパケットに署名することをさらに含むことを特徴とする請求項１に記載の方法。
8. 前記プロビジョニングパケットを暗号化することをさらに含むことを特徴とする請求項１に記載の方法。
9. プロビジョニングパケットをコンピュータに配信するために使用されるデータ構造をその上に格納しているコンピュータ可読媒体であって、
   前記コンピュータのハードウェア識別子を表すデータを含む第１のデータレコードと、
   前記プロビジョニングパケットの前記配信に関連付けられているトランザクションのシーケンス番号を表すデータを含む第２のデータレコードと、
   前記プロビジョニングパケットを表すデータを含む第３のデータレコードと、
   前記プロビジョニングパケットを前記コンピュータに配信しようとする、確認応答のない複数の試みを表すデータを含む第４のデータレコードとを含むことを特徴とするコンピュータ可読媒体。
10. 前記第３のデータレコードは、署名されたデータを含むことを特徴とする請求項７に記載のコンピュータ可読媒体。
11. 前記第３のデータレコードは、暗号化されたデータを含むことを特徴とする請求項７に記載のコンピュータ可読媒体。
12. 確認応答のない配信の試みを最大で何回許容できるかを表すデータを含む第５のデータレコードをさらに含むことを特徴とする請求項７に記載のコンピュータ可読媒体。
13. プロビジョニングパケットをコンピュータに配信するためのコンピュータで実行可能なモジュールを有するコンピュータ可読媒体であって、
    プロビジョニングパケットのソースに論理的に結合されているデータベースライタであって、プロビジョニングパケットを受信して、前記プロビジョニングパケットに関連付けられているコンピュータ識別子を確認するためのデータベースライタと、
    前記プロビジョニングパケットを配信まで保存しておくための、前記データベースライタに論理的に結合されている配信データベースと、
    パケットの配信を求める要求を処理するための、前記配信データベースに論理的に結合されている配信サービスモジュールであって、前記プロビジョニングパケットを求める要求を受信し、前記要求からのコンピュータ識別子を前記プロビジョニングパケットの前記コンピュータ識別子と照合し、前記配信データベースから前記プロビジョニングパケットを検索し、前記プロビジョニングパケットを前記コンピュータへ送信する配信サービスモジュール
    を含むことを特徴とするコンピュータ可読媒体。
14. 前記コンピュータからの確認メッセージを受信するための確認モジュールをさらに含むことを特徴とする請求項１３に記載のコンピュータ可読媒体。
15. 前記プロビジョニングパケットを求める、確認応答のない複数の要求が、ある限度を超えた場合に、前記確認モジュールは、前記プロビジョニングパケットを削除することを特徴とする請求項１４に記載のコンピュータ可読媒体。
16. 前記配信データベースは、同じコンピュータ識別子を有する複数のプロビジョニングパケットを保存することを特徴とする請求項１３に記載のコンピュータ可読媒体。
17. 前記配信サービスモジュールは、前記要求に応答して、一致するコンピュータ識別子を有するすべてのプロビジョニングパケットを前記待ち行列から検索して送信することを特徴とする請求項１３に記載のコンピュータ可読媒体。
18. 激しい使用状況においては、プロビジョニングパケットを求める要求を別の配信サービスモジュールへ回送するための負荷管理モジュールをさらに含むことを特徴とする請求項１３に記載のコンピュータ可読媒体。
19. 前記プロビジョニングパケットを暗号化するための暗号化モジュールをさらに含むことを特徴とする請求項１３に記載のコンピュータ可読媒体。
20. 前記プロビジョニングパケットの電子署名されたバージョンを入手するための署名モジュールをさらに含むことを特徴とする請求項１３に記載のコンピュータ可読媒体。

Images