プロビジョニングパケットを配信するためのシステムおよび方法
動的なソフトウェアプロビジョニングシステムは、所望のビジネスプロセスに基づいて複数の異なるコンピューティングデバイス上にソフトウェアを提供することを可能にする。この動的なソフトウェアプロビジョニングシステムによって、ユーザは、オペレーティングシステムを、特定の時間だけ、特定の使用量だけ、あるいはその他の任意の所望の方法で使用することを、オペレーティングシステムプロビジョニングサービスに、あるいはサードパーティーに要求することができる。このプロビジョニングサービスは、オペレーティングシステムの使用を提供してほしいというユーザからの、あるいはサードパーティーからの要求を処理し、その要求に応答して、その要求によって指定された特定のデバイスのためのオペレーティングシステムの使用を提供する。この動的なソフトウェアアクティブ化システムはまた、オペレーティングシステムを使用するデバイス上に配置されたローカルプロビジョニングモジュールを含み、このローカルプロビジョニングモジュールは、プロビジョニングサービスから受信した命令に基づいてオペレーティングシステムをアクティブ化したり、非アクティブ化したりする。
【発明の詳細な説明】
【技術分野】
【0001】
本特許は、一般にコンピュータに関し、より詳細にはコンピュータ管理システムに関する。
【背景技術】
【0002】
世界の人口の大きな割合は、コンピュータ、および/またはそのコンピュータを効率よく使用できるようにするさまざまなソフトウェアを所有するだけの経済的な余裕がない。発展途上国の人々にコンピューティングへの手ごろな価格のアクセスを提供したいというニーズがある。これは、ソフトウェアライセンスが一般に永久のライセンスを基準として販売されているソフトウェア業界の伝統的な構造に照らしても真実である。人々はまた、さまざまなソフトウェアのための永久のライセンスを購入するための十分な資金を持っていない結果として、そのようなソフトウェアをトレーニングの目的などのために短期間使用することさえ禁じられている。さらに先進国においてさえ、コンピュータユーザは、特定のソフトウェアを一定の時間だけ使用する必要がある場合に、その特定のソフトウェアのための永久のライセンスを購入する必要性によって意欲をそがれる。
【0003】
これは、コンピュータ用のオペレーティングシステムの場合に特に当てはまる。技術的に進んだコンピュータの計算能力、およびインターネットを通じて利用可能なリソースを使用する際には、コンピュータ、ならびにそのコンピュータとインターネットおよびその他のリソースとの通信を操作するために高性能なオペレーティングシステムを使用することが必要である。しかしソフトウェアの場合と同様に、オペレーティングシステムも、一般に永久のライセンスと共に販売されており、そのような永久のライセンスの価格は通常、第3世界のさまざまな国々の人々の購買力に比べて非常に高額である。
【発明の開示】
【発明が解決しようとする課題】
【0004】
永久のライセンスを購入する必要なくソフトウェアを使用できるようにするための、既存のものに取って代わるソリューションを提供するために、さまざまなビジネスモデルが試されてきた。たとえば、さまざまな企業が、ASP(application service provider)モデルに基づくソフトウェアを提供しており、このモデルでは、ユーザは、インターネットなどのネットワークのサーバ上に常駐しているソフトウェアに、そのサーバへログインすることによってアクセスすることができる。しかしこの方法では、ユーザは、インターネットを介してサーバに絶え間なく接続している必要がある。これは、インターネットへのアクセスが高価で信頼できないさまざまな発展途上国において発展できるソリューションではない。あるいは、ソフトウェアプロバイダは、ユーザがソフトウェアを一定の時間だけダウンロードできるようにしている場合が多いが、これは一般に試用のためであり、その後ユーザは、そのソフトウェアのための永久のライセンスを購入しなければならない。しかし、そのような試用版のソフトウェアを使用するための時間は、通常は固定されており、ユーザは、自分自身の選択のために時間を購入することや、固定された時間を追加するために試用版ソフトウェアのユーザを更新することを選択することができない。容易に理解できるように、ユーザがさまざまな異なる方法でソフトウェアサービスを購入できるような方法でユーザにそれらのサービスを提供したいというニーズがある。
【課題を解決するための手段】
【0005】
動的なソフトウェアプロビジョニングシステムは、所望のビジネスプロセスに基づいて複数の異なるコンピューティングデバイス上にソフトウェアを提供することを可能にする。この動的なソフトウェアプロビジョニングシステムによって、ユーザは、オペレーティングシステムを、特定の時間だけ、特定の使用量だけ、あるいはその他の任意の所望の方法で使用することを、オペレーティングシステムプロビジョニングサービス(operating system provisioning service)に、あるいはサードパーティーに要求することができる。このプロビジョニングサービスは、オペレーティングシステムの使用を提供してほしいというユーザからの、あるいはサードパーティーからの要求を処理し、その要求に応答して、その要求によって指定された特定のデバイスのためのオペレーティングシステムの使用を提供する。この動的なソフトウェアアクティブ化システムはまた、オペレーティングシステムを使用するデバイス上に配置されたローカルプロビジョニングモジュールを含み、このローカルプロビジョニングモジュールは、プロビジョニングサービスから受信した命令に基づいてオペレーティングシステムをアクティブ化したり、非アクティブ化したりする。
【0006】
ある代替実装形態においては、動的なソフトウェアプロビジョニングシステムは、ユーザが、プリペイドカードを購入することによってソフトウェアの使用権を購入できるようにする。そのプリペイドカードを使用して、ユーザは、プロビジョニングパケットをダウンロードすることができ、このプロビジョニングパケットによって、ユーザは、指定された時間だけソフトウェアを使用することができる。さらに別の実装形態においては、動的なソフトウェアシステムは、引受会社が、ソフトウェア付きのコンピュータと、そのソフトウェアを使用するための指定された量の時間とを販売できるようにする。
【0007】
さらに別の代替実装形態においては、動的なソフトウェアプロビジョニングシステムは、ユーザが、プリペイドカードを購入することによってオペレーティングシステムの使用権を購入できるようにする。そのプリペイドカードを使用して、ユーザは、プロビジョニングパケットをダウンロードすることができ、このプロビジョニングパケットによって、ユーザは、指定された時間だけオペレーティングシステムを使用することができる。さらに別の実装形態においては、動的なソフトウェアシステムは、引受会社が、オペレーティングシステム付きのコンピュータと、そのオペレーティングシステムを使用するための指定された量の時間とを販売できるようにする。
【0008】
さらに別の実装形態においては、動的なソフトウェアプロビジョニングシステムは、提供されたデバイスを登録することを求める登録要求を受信するステップであって、その登録要求は、提供されたデバイスのハードウェアIDを含むステップと、提供されたデバイスの証明書を作成するステップと、提供されたデバイスのパケットを作成することを求めるパケット作成要求を受信するステップであって、そのパケット作成要求は、提供されたデバイスの初期設定キーを含むステップと、提供されたデバイスのパケットを作成するステップであって、その提供されたデバイスのパケットは、その提供されたデバイス上でのサービスの第1の使用量を承認する情報を含むステップとを含む方法を実行するためのコンピュータ実行可能命令を有するコンピュータ可読媒体を含む。
【発明を実施するための最良の形態】
【0009】
以降の文章は、多くの異なる実施形態の詳細な説明を記載しているが、この説明の法的な範囲は、本特許に添付されている特許請求の範囲の文言によって定義されるという点を理解されたい。この詳細な説明は、例示的なものにすぎないと解釈されるべきであり、可能な実施形態をすべて説明しているわけではない。というのも、可能な実施形態をすべて説明することは、不可能ではないにしても、非現実的と思われるためである。本発明を定義する特許請求の範囲内に今後とも収まるであろう現在の技術または本特許の出願日以降に開発される技術を使用して、多くの代替実施形態を実施することができる。
【0010】
また用語については、「本明細書で使用する際、「 」という用語は、...を意味するものと定義する」という文や類似の文を使用して本特許内で明確に定義されていない限り、その用語の意味を、明示的にも暗示的にも、その率直な意味すなわち通常の意味を越えて限定する意図はまったくなく、またそのような用語は、本特許のいずれかのセクションにおいて行われているいずれかの記述(特許請求の範囲の言葉は除く)に基づく範囲に限定されるものと解釈すべきではないという点を理解されたい。本特許に添付されている特許請求の範囲に記載されているいずれかの用語が、ある単一の意味と一致した方法で本特許内で言及されている限りにおいては、それは、もっぱら読者を混乱させないように明確にする目的で行われているものであり、そのような特許請求の範囲の用語を、暗示などによって、その単一の意味に限定することを意図するものではない。最後に、請求項の要素が、いかなる構造についても記載せずに「手段」という言葉と機能とを記載することによって定義されているのでない限り、いかなる請求項の要素の範囲も、35 U.S.C.セクション112、第6パラグラフの適用に基づいて解釈されることを意図するものではない。
【0011】
(ネットワーク)
図1は、動的なソフトウェアプロビジョニングシステムを実装するために使用することができるネットワーク10を示している。ネットワーク10は、インターネット、VPN(virtual private network)、あるいは1つまたは複数のコンピュータ、通信デバイス、データベースなどが相互に通信可能に接続されることを可能にするその他の任意のネットワークとすることができる。ネットワーク10は、イーサネット(登録商標)16、およびルータ18、ならびに地上通信線20を介してパーソナルコンピュータ12およびコンピュータ端末14に接続することができる。その一方で、ネットワーク10は、無線通信局26および無線リンク28を介してラップトップコンピュータ22およびパーソナルデータアシスタント(personal data assistant)24に無線で接続することができる。同様に、サーバ30は、通信リンク32を使用してネットワーク10に接続することができ、メインフレーム34は、別の通信リンク36を使用してネットワーク10に接続することができる。以降でさらに詳しく説明するように、この動的なソフトウェアプロビジョニングシステムの1つまたは複数のコンポーネントは、ネットワーク10に接続されるさまざまなデバイスのいずれに格納して機能させることもできる。
【0012】
(コンピュータ)
図2は、動的なソフトウェアプロビジョニングシステムの1つまたは複数のコンポーネントを実装するためにネットワーク10に接続して使用することができるコンピュータ110の形態のコンピューティングデバイスを示している。コンピュータ110のコンポーネントは、処理装置120と、システムメモリ130と、システムメモリを含むさまざまなシステムコンポーネントを処理装置120に結合するシステムバス121とを含むことができるが、これらには限定されない。システムバス121は、メモリバスまたはメモリコントローラと、ペリフェラルバスと、さまざまなバスアーキテクチャーのいずれかを使用するローカルバスとを含む複数のタイプのバス構造のいずれにすることもできる。たとえばこのようなアーキテクチャーは、ISA(Industry Standard Architecture)バス、MCA(Micro Channel Architecture)バス、EISA(Enhanced ISA)バス、VESA(Video Electronics Standards Association)ローカルバス、およびメザニンバスとしても知られているPCI(Peripheral Component Interconnect)バスを含むが、これらには限定されない。
【0013】
コンピュータ110は通常、さまざまなコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ110によってアクセスできる利用可能な任意のメディアとすることができ、揮発性メディアおよび不揮発性メディア、ならびに取り外し可能メディアおよび固定式メディアの双方を含む。たとえばコンピュータ可読媒体は、コンピュータストレージメディアおよび通信メディアを含むことができるが、これらには限定されない。コンピュータストレージメディアは、コンピュータ可読命令、データ構造、プログラムモジュール、その他のデータなどの情報を記憶するための任意の方法または技術において実装される揮発性メディアおよび不揮発性メディア、ならびに取り外し可能メディアおよび固定式メディアを含む。コンピュータストレージメディアは、RAM、ROM、EEPROM、フラッシュメモリ、またはその他のメモリ技術、CD−ROM、DVD(digital versatile disk)、またはその他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、またはその他の磁気ストレージデバイス、あるいは所望の情報を保存するために使用可能で、コンピュータ110によってアクセス可能なその他の任意のメディアを含むが、これらには限定されない。通信メディアは通常、搬送波やその他の伝送メカニズムなどの変調されたデータ信号内のコンピュータ可読命令、データ構造、プログラムモジュール、あるいはその他のデータを具体化し、任意の情報伝達メディアを含む。「変調されたデータ信号」という用語は、情報をその信号内でコード化するような方法で設定または変更されたその特性のうちの1つまたは複数を有する信号を意味する。たとえば通信メディアは、有線ネットワークや直接有線接続などの有線メディアと、音波メディア、無線周波数メディア、赤外線メディア、その他の無線メディアなどの無線メディアとを含むが、これらには限定されない。また上記のいずれの組合せも、コンピュータ可読媒体の範囲内に含まれるものである。
【0014】
システムメモリ130は、コンピュータストレージメディアを、ROM(read only memory)131およびRAM(random access memory)132などの揮発性メモリおよび/または不揮発性メモリの形態で含む。BIOS(basic input/output system)133は、起動中などにコンピュータ110内の要素どうしの間における情報伝達を補助する基本ルーチンを含み、通常はROM131内に格納されている。RAM132は通常、処理装置120がすぐにアクセスできるか、および/または処理装置120によってその時点で操作されているデータモジュールおよび/またはプログラムモジュールを含む。図1は、例としてオペレーティングシステム134、アプリケーションプログラム135、その他のプログラムモジュール136、およびプログラムデータ137を示しているが、これらには限定されない。
【0015】
またコンピュータ110は、その他の取り外し可能/固定式、揮発性/不揮発性コンピュータストレージメディアを含むこともできる。図1は、例示のみを目的として、固定式の不揮発性の磁気メディアとの間で読み取りや書き込みを行うハードディスクドライブ141と、着脱式不揮発性の磁気ディスク152との間で読み取りや書き込みを行う磁気ディスクドライブ151と、CD−ROMやその他の光メディアなどの着脱式不揮発性の光ディスク156との間で読み取りや書き込みを行う光ディスクドライブ155とを示している。典型的な動作環境において使用できるその他の取り外し可能/固定式、揮発性/不揮発性コンピュータストレージメディアとしては、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートRAM、ソリッドステートROMなどがあるが、これらには限定されない。ハードディスクドライブ141は通常、インターフェース140などの固定式のメモリインターフェースを介してシステムバス121に接続されており、磁気ディスクドライブ151および光ディスクドライブ155は通常、インターフェース150などの着脱式メモリインターフェースによってシステムバス121に接続されている。
【0016】
図1に示されている上述のドライブおよびそれらに関連するコンピュータストレージメディアは、コンピュータ110用のコンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの記憶を提供する。たとえば図1において、ハードディスクドライブ141は、オペレーティングシステム144、アプリケーションプログラム145、その他のプログラムモジュール146、およびプログラムデータ147を記憶するものとして示されている。これらのコンポーネントは、オペレーティングシステム134、アプリケーションプログラム135、その他のプログラムモジュール136、およびプログラムデータ137と同一とするか、または異なっていてもよいという点に留意されたい。ここでは、オペレーティングシステム144、アプリケーションプログラム145、その他のプログラムモジュール146、およびプログラムデータ147が最低限異なるコピーであることを示すために、異なる番号を割り当てている。ユーザは、キーボード162や、通常はマウス、トラックボール、あるいはタッチパッドと呼ばれるポインティングデバイス161などの入力デバイスを介してコンピュータ110にコマンドおよび情報を入力することができる。その他の入力デバイス(図示せず)は、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信用アンテナ、スキャナなどを含むことができる。これらおよびその他の入力デバイスは、システムバスに結合されているユーザ入力インターフェース160を介して処理装置120に接続される場合が多いが、パラレルポート、ゲームポート、またはUSB(universal serial bus)などのその他のインターフェース構造およびバス構造によって接続することもできる。またモニタ191やその他のタイプのディスプレイデバイスも、ビデオインターフェース190などのインターフェースを介してシステムバス121に接続される。コンピュータは、モニタに加えて、スピーカ197やプリンタ196などのその他の周辺出力デバイスを含むこともでき、これらは、周辺出力インターフェース195を介して接続することができる。
【0017】
コンピュータ110は、リモートコンピュータ180などの1つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境内で機能することができる。リモートコンピュータ180は、パーソナルコンピュータ、サーバ、ルータ、ネットワークPC、ピアデバイス、あるいはその他の一般的なネットワークノードとすることができ、図1にはメモリストレージデバイス181しか示されていないが、通常はコンピュータ110に関連する上述の要素の多くまたはすべてを含む。図1に示されている論理接続は、LAN(local area network)171およびWAN(wide area network)173を含むが、その他のネットワークを含むこともできる。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットにおいてよく見受けられる。
【0018】
LANネットワーキング環境において使用する場合には、コンピュータ110は、ネットワークインターフェースまたはアダプタ170を介してLAN171に接続される。WANネットワーキング環境において使用する場合には、コンピュータ110は通常、モデム172や、インターネットなどのWAN173上で通信を確立するためのその他の手段を含む。モデム172は、内蔵型または外付け型とすることができ、ユーザ入力インターフェース160やその他の適切なメカニズムを介してシステムバス121に接続することができる。ネットワーク化された環境においては、コンピュータ110に関連して示されているプログラムモジュール、またはその一部をリモートメモリストレージデバイス内に格納することができる。図1は、例としてリモートアプリケーションプログラム185をメモリデバイス181上に常駐するものとして示しているが、この形態には限定されない。示されているネットワーク接続は例示的なものであり、コンピュータどうしの間に通信リンクを確立するその他の手段も使用することができるということが理解できるであろう。
【0019】
(ソフトウェアプロビジョニングシステム)
図3は、コンピューティングデバイス202上でのオペレーティングシステムの使用を提供するための動的なソフトウェアプロビジョニングシステム200を示しており、ここでは、コンピューティングデバイス202は、デスクトップコンピュータ12、ラップトップコンピュータ22、PDA24、携帯電話、あるいは任意の類似のデバイスなど、一般に知られているコンピューティングデバイスのいずれにすることもできる。ソフトウェアプロビジョニングシステム200は、オペレーティングシステムの使用を提供するために実装されるものとして示されているが、ある代替実装形態においては、ソフトウェア、ファームウェア、コンピューティングデバイスの一機能など、その他のリソースの使用を提供するために使用することもできる。同様に、ソフトウェアプロビジョニングシステム200は、ネットワーク10に通信可能に接続されているコンピューティングデバイス202上でのリソースの使用を提供するものとして示されているが、ネットワーク10に接続できない、あるいはネットワーク10に一時的にしか接続できないコンピューティングデバイス上でのそのような使用を実装するために使用することもできる。
【0020】
ソフトウェアプロビジョニングシステム200は、コアプロビジョニングサービスモジュール206と、配信サービスモジュール208と、証明書サービスモジュール210と、コアデータベース212と、配信データベース214とを有するプロビジョニングサービスモジュール204を含むことができる。プロビジョニングシステム204は、課金アダプタ218を介して課金システム216と通信することができ、その一方でコアプロビジョニングサービスモジュール206は、データベースライタ(database writer)220を介して配信データベース214と通信することができ、配信データベース214は、データベースリーダ222を介して配信サービス208と通信する。コンピューティングデバイス202は、ローカルプロビジョニングモジュール(LPM)224を含むことができ、このLPM224は、配信ウェブサービスモジュール226を介して配信サービスモジュール208と通信し、課金ウェブサービスモジュール228を介して課金システム216と通信する。
【0021】
プロビジョニングサービスモジュール204は、サーバ30などのサーバシステム上や、ネットワーク10に通信可能に接続されているその他のシステム上に配置することができる。同様に、課金システム216も、サーバ30などのサーバシステム上や、ネットワーク10に通信可能に接続されているその他のシステム上に配置することができる。さらに、プロビジョニングサービスモジュール204のさまざまなコンポーネントのうちの1つまたは複数は、同一のサーバ上や、別々の場所に配置されている複数の異なるサーバ上に配置することができる。たとえばコアデータベース212は、別々の場所に配置されてそれぞれネットワーク10に通信可能に接続されている複数の異なるデータベースサーバ上に配置することができる。プロビジョニングサービスモジュール204およびそのさまざまなコンポーネントモジュールの機能については、以降でさらに詳しく説明する。
【0022】
さらに図3においては、コンピューティングデバイス202は、ウェブサービスモジュール226を介して配信サービスモジュール208と、およびウェブサービスモジュール228を介して課金システム216と通信するものとして示されている。状況によっては、ウェブサービスモジュール226は、望ましいレベルを超えるアクティビティーの増加を認識することができる。代替実施形態における負荷管理サービス230、コンピューティングデバイス202のユーザは、電話などの代替モードの通信を介して配信サービスモジュール208および課金システム216と通信することができる。たとえば、コンピューティングデバイス202にとってネットワーク10に接続することが不可能な状況においては、コンピューティングデバイス202のユーザは、配信サービスモジュール208に取り付けられている電話および音声認識対応型のユーザインターフェースを介して、あるいは配信サービスモジュール208と通信できる顧客サービス担当者などを介して通信することができる。
【0023】
コンピューティングデバイス202が、コンピュータ110などのコンピュータである場合には、LPM224は、システムメモリ130の一部として、処理装置120を含むコンピュータ110のさまざまなハードウェアコンポーネントの一部として、あるいはこれらの任意の組合せとして、固定式の不揮発性メモリ140上に配置することができる。LPM224の機能については、以降でさらに詳しく説明する。
【0024】
(プロビジョニングシステムのフローチャート)
次いで図4を参照すると、プロビジョニングプログラム250が、ソフトウェアプロビジョニングシステム200の一般的な機能を示している。ブロック251においては、コンピューティングデバイス202上でオペレーティングシステムを使用するための登録キーをユーザに提供することができる。オペレーティングシステムなどを使用するためのさらなる時間をユーザが購入した結果として、コンピューティングデバイス202の新たな購入に伴って登録キーをユーザに提供することができる。複数の異なるエンティティーが、登録キーをユーザに提供することができ、たとえば、コンピューティングデバイス202を販売しているコンピュータストアは、キーをユーザに提供することができ、コンピューティングデバイス202用のオペレーティングシステムの使用を含む一式のサービスを販売しているインターネットサービスプロバイダは、登録キーをユーザに提供することができる、といった具合である。
【0025】
登録キーは、以降でさらに詳しく説明するように、プロビジョニングサービスモジュール204によって証明書サービス210を用いて作成して、登録キーのプロバイダに安全な方法で送信することができる。あるいは、登録キーのプロバイダが、プロビジョニングサービスモジュール204と合意した方法で登録キーを作成することもできる。登録キーは、その登録キーを使用してコンピューティングデバイス202を識別するハードウェアやその他のコンポーネントに固有の情報を含むこともでき、あるいは含まなくてもよい。ソフトウェアプロビジョニングシステム200の一実装形態においては、それぞれの登録キーは、コンピューティングデバイス202のHWID(hardware identification)によって、コンピューティングデバイス202を一意に識別する。さらに別の実装形態においては、登録キーは、オペレーティングシステムのプロダクトキーなどの製造識別番号(production identification number)とすることができ、オペレーティングシステムの開発者や、そのオペレーティングシステムを使用するコンピューティングデバイスの製造業者など、プロビジョニングサービス以外のエンティティーによって作成することができる。この登録キーは、InitKey(Initialization key)とも呼ばれ、一連の英数字の形式、RFID(radio frequency identification)タグの形式、あるいはその他の任意の合意されたフォーマットとすることができる。
【0026】
登録キーをユーザに提供した後、ブロック252において、プロビジョニングプログラム250は、その登録キーをプロビジョニングサービスモジュール204に登録することが必要かどうかを判定することができる。InitKeyが、はじめにプロビジョニングサービスモジュール204によって作成されたものである場合には、そのInitKeyは、プロビジョニングサービスモジュール204のデータベース内に既に保存されている可能性があるため、そのInitKeyを登録することは必要でないかもしれない。あるいは、合意されたプロシージャーに基づいてサードパーティーのベンダがInitKeyを作成できるような方法でソフトウェアプロビジョニングシステム200がセットアップされている場合には、そのようなベンダは、そのInitKeyを、作成した際に、あるいは少なくともユーザへ提供した際に、登録する必要があるかもしれない。
【0027】
InitKeyを登録することが必要であると判定された場合には、ベンダは、ブロック254において、InitKeyをプロビジョニングサービスモジュール204に登録することができる。InitKeyの登録については、以降の図9においてさらに詳しく説明する。
【0028】
InitKeyの登録後、ブロック256において、プロビジョニングプログラム250は、コンピューティングデバイス202のためのプロビジョニングパケット(「パケット」とも呼ばれる)を作成する。コンピューティングデバイス202は、プロビジョニングパケットを使用して、指定された時間だけ、指定された期間だけ、あるいはその他の任意の合意された方法でユーザがオペレーティングシステムを使用できるようにすることができる。ある代替実装形態においては、プロビジョニングパケットを使用して、指定された期間だけソフトウェアやアプリケーションなどのその他の任意のリソースをユーザが使用できるようにすることができる。プロビジョニングサービスモジュール204によって作成されるプロビジョニングパケットは、そのパケットのユーザに関する情報や、そのパケットによって認められる使用量などを含むことができる。たとえばベンダが、コンピューティングデバイス202を、そのコンピューティングデバイス202上でのオペレーティングシステムの1カ月間の前払いの使用権と共に販売している場合には、ブロック256において、プロビジョニングサービスモジュール204は、コンピューティングデバイス202がそのオペレーティングシステムを1カ月間だけ使用できるようにするコンピューティングデバイス202用のプロビジョニングパケットを作成することができる。しかしプロビジョニングパケットは、コンピューティングデバイス202のみがその特定のプロビジョニングパケットを使用できるような方法で作成することができる。プロビジョニングパケットの作成については、以降の図10においてさらに詳しく説明する。
【0029】
ユーザが、コンピューティングデバイス202の電源をオンにすることによって、あるいはその他の任意の方法で、コンピューティングデバイス202上のオペレーティングシステムをアクティブ化しようと試みるとき、LPM224は、オペレーティングシステムのアクティブ化をコントロールすることができる。これは、プログラム250のブロック258によって示されている。そのユーザがこのオペレーティングシステムの使用を試みるのは、これが初めてであるとLPM224が検知した場合には、LPM224は、InitKeyを入力するようユーザに要求することができる。ある代替実装形態においては、LPM224は、コンピューティングデバイス202をスキャンして、コンピューティングデバイス202がInitKeyを既に投入されているかどうかを判定することができ、投入されている場合には、LPM224は、InitKeyをコンピューティングデバイス202から自動的に検索する。InitKeyをユーザから受け取った後、LPM224は、プロビジョニングサービスモジュール204と接続して、コンピューティングデバイス202のための証明書を要求することができ、この場合には、証明書を求める要求は、数ある情報の中でも、コンピューティングデバイス202のInitKeyおよびHWIDを含む。LPM224の設計およびオペレーションについては、以降で図7においてさらに詳しく説明する。
【0030】
証明書を求める要求に応答して、ブロック260において、プロビジョニングサービスモジュール204は、証明書サービスモジュール210から証明書を受け取ることができ、その証明書を、配信サービスモジュール208を介してコンピューティングデバイス202へ送信する。証明書サービスモジュール210から証明書を作成して、その証明書をクライアントデバイスへ送信するプロセスについては、以降で図10においてさらに詳しく説明する。
【0031】
プロビジョニングサービスモジュール204から証明書を受け取ると、ブロック262において、LPM224は、コンピューティングデバイス202上でオペレーティングシステムを使用するためにさらなるプロビジョニングパケットを入手することが必要かどうかを判定することができる。LPM224は、それまでコンピューティングデバイス202が使用された時間、現在の時間周期(current time period)、あるいは任意の類似のビジネスルールなどのビジネスルールに基づいて、プロビジョニングサービスモジュール204から受け取ったプロビジョニングパケットを消費することができる。以降でさらに説明するように、LPM224は、以前にプロビジョニングサービスモジュール204から受け取ったプロビジョニングパケットを含むローカルプロビジョニングパケットストレージモジュール(local provisioning packet storage module)を有することができる。LPM224は、そのようなローカルパケットストア(local packet store)から1つのプロビジョニングパケットを選択し、その中身を分析して、プロビジョニングサービスモジュール204にさらなるパケットを要求する必要があるかどうかを判定することができる。プロビジョニングパケットの選択、および選択されたプロビジョニングパケットの分析については、以降の図7においてさらに詳しく説明する。
【0032】
さらなるプロビジョニングパケットを要求することが必要であると判定された場合には、ブロック264において、LPM224は、さらなるプロビジョニングパケットを受け取るためにプロビジョニングサービスモジュール204へ要求を送信することができる。LPM224は、配信サービスモジュール208のウェブサービスモジュール226に接続することによって、プロビジョニングサービスモジュール204の顧客サービス担当者に連絡を取るようコンピューティングデバイス202のユーザに要求することによって、あるいはその他の任意の所望の方法を含む複数の異なる方法で、そのような要求をPSMへ送信することができる。プロビジョニングパケットを求める要求は、クライアントデバイス、そのクライアントデバイスによって使用されるオペレーティングシステムなどを識別する情報を含むことができる。
【0033】
プロビジョニングパケットを求める要求をコンピューティングデバイス202から受信すると、ブロック266において、プロビジョニングサービスモジュール204は、プロビジョニングパケットを作成して、LPM224へ配信することができる。LPM224に提供されるそれぞれのプロビジョニングパケットは、コンピューティングデバイス202、そのコンピューティングデバイス202によって使用されるオペレーティングシステム、パケットのタイプ、パケットのシーケンス番号、コンピューティングデバイス202がオペレーティングシステムを使用できる時間、あるいはオペレーティングシステムの使用期限が切れる日にちなどを識別するさまざまな情報を含むことができる。プロビジョニングパケット内の情報をLPM224が認証できるようにする電子署名を、そのプロビジョニングパケット内に含めることもできる。あるいは、別のセキュリティープロトコルのもとでは、プロビジョニングパケット内の情報をLPM224が認証できるようにする電子署名を、別途LPM224へ送信することもできる。プロビジョニングパケットの作成および配信については、以降の図12においてさらに詳しく説明する。
【0034】
プロビジョニングパケットを受け取ると、LPM224は、ブロック268において、そのプロビジョニングパケットを処理することができ、これについては、以降の図7においてさらに詳しく説明する。プロビジョニングパケットの中身を分析した後に、そのプロビジョニングパケットがコンピューティングデバイス202上でのオペレーティングシステムの使用を可能にすることができるとLPM224が判定した場合には、ブロック270において、コンピューティングデバイス202は、そのコンピューティングデバイス202上でオペレーティングシステムを起動することができる。
【0035】
(コアプロビジョニングシステム)
図5は、図3のコアプロビジョニングサービスモジュール206の詳細なブロック図を示している。コアプロビジョニングサービスモジュール206は、サーバ30、メインフレーム34、あるいはネットワーク10に通信可能に接続されているその他の任意の適切なデバイス上に実装することができる。コアプロビジョニングサービスモジュール206は、証明書サービスモジュール210、課金アダプタ218、コアDB212、および配信サービスモジュール208と通信することができる。コアプロビジョニングサービス206は、課金アダプタと通信する課金インターフェース280と、証明書サービスモジュール210と通信するための証明書サービスインターフェース282と、配信サービスモジュール208と通信するための配信サービスインターフェース288と、アカウント更新モジュール284と、パケットジェネレータ(packet generator)286と、コアデータベース212および配信データベース214と通信するデータアクセスモジュール290とを含むことができる。
【0036】
課金インターフェース280は、ウェブインターフェース、課金アダプタ218へのVPN、あるいは当業者によく知られているその他の任意の所望の方法を使用して実装することができる。ある特定の実装形態においては、課金インターフェース280は、MSMQ(Microsoft message queue)(商標)インターフェースを使用して実装することができる。あるいは、EAI(enterprise application interface)プロトコルを使用して設計されているMicrosoft Biztalk(商標)など、別の業界プロトコル(industry protocol)を使用して設計されているインターフェースを使用して、課金インターフェース280を実装することもできる。MSMQ(商標)テクノロジーを使用して、配信サービスインターフェース288およびデータアクセスモジュール290を実装することもできる。
【0037】
課金インターフェースモジュール280は、コンピューティングデバイスのためのInitKeyの登録を求める要求を課金アダプタ218から受け取り、アカウント更新と通信して、アカウント更新情報を提供し、さまざまなコンピューティングデバイスをブートストラップし、コンピューティングデバイスのためのクライアント証明書を証明書サービスモジュール210に要求することなどができる。
【0038】
アカウント更新モジュール284は、コンピューティングデバイス202のためのアカウントの作成、保持、および更新を担当することができる。アカウント更新モジュール284は、コンピューティングデバイス202のためのアカウントのセットアップおよび更新に関する課金アダプタ218からの情報を受信することができ、またパケットジェネレータ286と通信して、コンピューティングデバイス202のためのプロビジョニングパケットを作成および保存することができる。たとえば、引受会社(underwriter)、電気通信業者等は、コンピューティングデバイス202上でのオペレーティングシステムの一定の使用時間を販売し、課金アダプタ218を使用して、コンピューティングデバイス202のアカウントをしかるべく更新するためのアカウント更新要求をコアプロビジョニングサービス206へ送信することができる。課金アダプタ218からのアカウント更新要求を受信すると、アカウント更新モジュール284は、データアクセスモジュール290を使用してコアデータベース212への必要な入力を行い、パケットジェネレータと通信して、必要なプロビジョニングパケットを作成することができる。別の場合には、配信サービスモジュール208が、コンピューティングデバイス202のためのプロビジョニングパケットを購入したいというコンピューティングデバイス202からの要求を受け取ることができる。
【0039】
一方、コンピューティングデバイス202が、証明書を求める、またはプロビジョニングパケットを求める要求をコアプロビジョニングサービス206へ送信すると、アカウント更新モジュール284は、コアデータベース212からプロビジョニングパケットを検索し、コンピューティングデバイス202のためのアカウント情報を更新し、配信サービスモジュール208と通信して、そのプロビジョニングパケットをコンピューティングデバイス202へ送信することができる。
【0040】
コアプロビジョニングサービス206は、証明書を求める、またはプロビジョニングパケットを求める要求をコンピューティングデバイス202から受信すると、証明書サービスインターフェース282を使用して証明書サービスモジュール210と通信して、証明書を受け取ることや、証明書を確認することができる。証明書サービスモジュール210は、暗号化された証明書の作成および管理を可能にする標準的な証明書技術のうちのいずれかを使用して実装することができる。たとえば、証明書サービスモジュール210は、PKI(public key infrastructure)に準拠する認証局を使用して実装することができる。証明書サービスモジュール210は、キーマネージャー292を含むことができ、このキーマネージャー292は、暗号化された非対称的なツインキー(asymmetrical twin keys)の作成や、キーの購入者(key subscriber)の識別および認証などを担当する。証明書サービスモジュール210は、証明書ジェネレータ(certificate generator)を含むこともでき、この証明書ジェネレータは、デジタル証明書を用いて、そのような証明書の発行、保持、管理、取り消し、一時停止、復活、および更新のために、ならびに公開キーリポジトリ(public key repository)の作成および管理のために、公開キーをクライアントアカウントに結び付ける。クライアントのための証明書の作成および管理については、以降の図11においてさらに詳しく説明する。
【0041】
証明書サービスインターフェース282は、パケットジェネレータ286によって作成されたプロビジョニングパケットがコンピューティングデバイス202へ送信される前に、証明書サービスモジュール210によって作成された証明書を使用することによって、そのプロビジョニングパケットに署名することができる。証明書サービスインターフェース282は、パケット要求などのクライアント署名を確認するために証明書サービスモジュール210と通信することもできる。
【0042】
コアプロビジョニングサービス206は、プロビジョニングパケット、およびクライアントデバイス証明書などのその他のクライアントデバイスのブートストラップ関連情報(other client device bootstrapping information)を配信データベース214内に発行することを担当することができる。配信サービスモジュール208には、配信データベース214から情報を読み取ることを認めることができるが、アカウント情報の整合性を維持するために、配信サービスモジュール208には、一般に配信データベース214内への発行を行うことは認められないという点に留意されたい。
【0043】
コアプロビジョニングサービス206内のさまざまなモジュールは、上述のさまざまなタスクを実行する別々のモジュールとして示されているが、この描写は、例示のみを目的としたものであり、実際には、これらの別々のモジュールのすべてを別々の方法で実装することができ、それによって、これらのモジュールのうちの1つまたは複数が結合されたり、これらのモジュールのすべてが別々の方法でお互いに対話することができたり、といった具合になるという点を理解されたい。
【0044】
(コアデータベーススキーマ)
図6は、コアデータベース212の実装のために使用できるコアデータベーススキーマ310を示している。コアデータベーススキーマ310は、ブートストラップテーブル312、コンピューティングデバイステーブル314、ジョブテーブル316、パケットテーブル318、構成テーブル320、コンピューティングデバイスログテーブル322、タイプテーブル324、ジョブログテーブル326、およびステータステーブル328を含むことができる。コアデータベーススキーマ310は、よく知られているリレーショナルデータベースソフトウェアのうちのいずれかを使用して実装することができ、コアデータベーススキーマ310のさまざまなテーブルは、単一のデータベースサーバ上に、あるいはネットワーク10などのネットワークを介して相互に接続されている別々のデータベースサーバ上に格納することができる。
【0045】
ブートストラップテーブル312は、ソフトウェアプロビジョニングシステム200を使用して提供することができるコンピューティングデバイス202などのコンピューティングデバイスのためのブートストラップデータを保存することができ、そのようなデータは、引受会社から課金アダプタ218を介して受信される。ブートストラップテーブル312内のそれぞれのレコードは、レコードIDフィールドと、コンピューティングデバイス用のIDと、コンピューティングデバイスのユーザに提供されたInitKeyと、パケットがコンピューティングデバイスに配信された回数を識別する配信回数と、コンピューティングデバイスのブートストラップステータスとを含む情報を含むことができる。
【0046】
コンピューティングデバイステーブル314は、ソフトウェアプロビジョニングシステム200を使用して提供することができるコンピューティングデバイス202などのコンピューティングデバイスに関連したデータを保存することができる。コンピューティングデバイステーブル314は、コンピューティングデバイスへ送信される登録パケットやプロビジョニングパケットに追加されるコンピューティングデバイスに関連したさまざまなデータを保存することができる。コンピューティングデバイステーブル314は、コンピューティングデバイスを識別して、そのコンピューティングデバイスのステータスを追跡把握するために使用することができる。コンピューティングデバイステーブル314内のそれぞれのレコードは、レコードIDフィールド、コンピューティングデバイスのハードウェア構成を指定するハードウェアID、コンピューティングデバイスへ送信された前回のプロビジョニングパケットのシーケンス番号を表す直近のシーケンス番号などを含む情報を含むことができる。
【0047】
ジョブテーブル316は、プロビジョニングサービスモジュール204へのさまざまなプロビジョニング要求(provisioning request)に基づいて作成できるデータを保存し、それぞれのプロビジョニング要求は、ジョブテーブル316内に新たなレコードを作成する。ジョブテーブル316内のレコードは、さまざまなプロビジョニング要求のプロビジョニングジョブステータス(provisioning job status)を追跡把握するために使用することができる。ジョブテーブル316内のそれぞれのレコードは、レコードIDフィールド、コンピューティングデバイスID、ジョブタイプID、ジョブトラッキングID、プロビジョニング要求のためのトークン、プロビジョニング要求を行っているコンピューティングデバイスのためのアカウントID、プロビジョニング要求の日付および時間、プロビジョニング要求の処理のステータスなどを含む情報を含む。
【0048】
パケットテーブル318は、ジョブデータに基づいて作成できるパケットデータを保存し、この場合には、1つのジョブが、1つまたは複数のパケットを作成することができる。パケットテーブルは、配信サービスモジュール208から、または課金アダプタ218から受信されるプロビジョニング要求に応答して作成されるさまざまなプロビジョニングパケットの配信ステータスを追跡把握するために使用される。パケットテーブル内のそれぞれのレコードは、レコードID、パケットが作成されるようにするジョブを表すジョブID、パケット内に含まれているさまざまなデータ、特定のコンピューティングデバイスから最後のパケットダウンロード確認応答を受信してからその特定のコンピューティングデバイスにパケットが何回配信されたかを示す配信回数、およびパケットの処理の段階を示すステータスに関する情報を含むことができる。
【0049】
構成テーブル320は、コアデータベース212を実装するために使用されているサーバについて記述するサーバ構成データの名前−値のペア(name−value pair)のすべてを表すデータを保存することができる。構成テーブル320内のそれぞれのレコードは、サーバのネームスペースや、サーバの名前−値のペアの名前および設定に関する情報を含むことができる。
【0050】
コンピューティングデバイスログテーブル322は、コンピューティングデバイスに関連した(そのコンピューティングデバイスに関連したジョブ以外の)さまざまなアクティビティーを記録することができる。コンピューティングデバイスログテーブル322内のそれぞれのレコードは、レコードID、コンピューティングデバイスID、コンピューティングデバイスのタイプ、コンピューティングデバイスについて記述するデータ、およびコンピューティングデバイスがプロビジョニングサービスモジュール204を用いてログインされた時間に関する情報を含むことができる。たとえばコンピューティングデバイスのタイプは、ブートストラップレコードが作成済みのタイプ、ブートストラップが進行中のタイプ、ブートストラップが完了したタイプ、(指定された数を超える証明書がコンピューティングデバイスへ配信され、そのコンピューティングデバイスから確認応答が受信されていないことを示す)ブートストラップが制限を超えたタイプ、証明書が要求されたタイプ、パケットが要求されたタイプなどのうちのいずれか1つとすることができる。
【0051】
タイプテーブル324は、ジョブテーブル316、コンピューティングデバイスログテーブル322、およびジョブログテーブル326によって使用されるさまざまな列挙可能な(enumerable)タイプを事前に定義するために使用することができる。
【0052】
ジョブログテーブル326は、ジョブやパケットに関連するさまざまなアクティビティーを記録するために使用することができ、この場合には、それぞれのレコードは、レコードID、ジョブID、ジョブのタイプ、ジョブの説明、ジョブが記録された時間などを含む情報を含むことができる。
【0053】
ステータステーブル328は、ブートストラップテーブル312、コンピューティングデバイステーブル314、ジョブテーブル316、およびパケットテーブル318内で使用されるさまざまな列挙可能なステータスを事前に定義するために使用することができる。
【0054】
(配信データベーススキーマ)
図7は、配信データベース214の実装のために使用できる配信データベーススキーマ340を示している。配信データベーススキーマ340は、配信ブートストラップテーブル342および配信パケットテーブル344を含むことができる。配信データベーススキーマ340は、よく知られているリレーショナルデータベースソフトウェアのうちのいずれかを使用して実装することができ、配信データベーススキーマ340のさまざまなテーブルは、単一のデータベースサーバ上に、あるいはネットワーク10などのネットワークを介して相互に接続されている別々のデータベースサーバ上に格納することができる。
【0055】
配信ブートストラップテーブル342は、コンピューティングデバイスの登録中にコアプロビジョニングサービス206によって発行されるブートストラップデータを保存することができる。配信ブートストラップテーブル342のそれぞれのレコードは、レコードIDと、特定のコンピューティングデバイスに関連したInitKeyと、その特定のコンピューティングデバイスのハードウェアIDとを含む情報を含むことができ、配信ブートストラップテーブル342内のレコードは、その特定のコンピューティングデバイスのためのブートストラップが完了したときに、コアプロビジョニングサービス206によって削除することができる。
【0056】
配信パケットテーブル344は、コアプロビジョニングサービス206によって作成されたパケットを保存することができる。配信パケットテーブル344のそれぞれのレコードは、特定のパケットに対応することができ、レコードIDと、その特定のパケットを使用することになるコンピューティングデバイスについて記述するハードウェアIDと、その特定のパケットのパケットシーケンス番号と、その特定のパケットの中身と、確認応答が受信されない状態でその特定のパケットがクライアントデバイスへ何回送信されたかを指定する配信回数と、配信サービスモジュール208がその特定のパケットをクライアントデバイスへ配信しようと試みることができる回数を指定する最大配信回数とを含む情報を含む。特定のパケットが、クライアントコンピューティングデバイスによって首尾よくダウンロードされると、その特定のパケットに関連したレコードを配信パケットテーブル344から削除することができる。また、特定のパケットの配信回数が最大配信回数を超えた場合には、その特定のパケットに関連したレコードを配信パケットテーブル344から削除することもできる。
【0057】
(ローカルプロビジョニングモジュール)
図8は、LPM224のさらに詳細なブロック図を示している。LPM224は、コンピューティングデバイス202などのコンピューティングデバイス上に常駐しているソフトウェアプロビジョニングシステム200のクライアントサイドのコンポーネントである。LPM224は、ソフトウェアプロビジョニングシステム200によって提供されるサービスを使用してコンピューティングデバイスのユーザと対話することや、ネットワーク10を介して配信サービスモジュール208と対話することなどを含むさまざまな機能を実行することができる。
【0058】
LPM224は、クライアントコンピューティングデバイス202によって使用される特定のログインプログラムと対話することによって、クライアントコンピューティングデバイス202上での特定の状態を強制する機能を実行することができる。クライアントデバイスが、ログインロジックとしてWPA(Windows(登録商標) product activation)システムを使用している特定の実装形態においては、LPM224は、WPAと対話して、クライアントコンピューティングデバイス202上での特定の状態を強制することができる。しかし、ある代替実装形態においては、LPM224は、その他の任意の適切なオペレーティングシステムログインプログラムと対話することができる。LPM224の実装形態は、ソフトウェア内に実装され、かつWPAによって使用されるログインプログラムへとリンクされるライブラリとして構成されているさまざまな論理コンポーネントをグループ化したものとして、図8に記載されている。しかし、LPM224の代替実装形態においては、LPM224のさまざまな論理コンポーネントのうちの1つまたは複数をハードウェア内に実装することができる。
【0059】
具体的には、LPM224は、特定の状態で機能することをコンピューティングデバイス202に強制するための強制アドオンモジュール(enforcement add−on module)352と、ソフトウェアプロビジョニングシステム200によって提供されるリソースの使用状況を測定するための測定モジュール(metering module)354と、コアプロビジョニングサービス206によって提供されるプロビジョニングパケットを使用して処理を行うためのトランザクションエンジン356と、プロビジョニングパケット用の安全なストレージを提供するためのセキュアストレージマネージャー(secure storage manager)358と、コアプロビジョニングサービス206と通信するための通信モジュール360と、ユーザと対話するためのユーザ経験モジュール(user experience module)362とを含むことができる。
【0060】
強制アドオンモジュール352は、コンピューティングデバイス202のログインロジック364内に挿入することができる。ユーザが、ログインロジック364を使用してコンピューティングデバイス202にログオンしたときに、ログインロジック364内の強制アドオンモジュール352は、プロビジョニングパケットの残量情報を求めて測定モジュール354にクエリーを行うことができる。強制アドオンモジュール352は、コンピューティングデバイス202が十分なプロビジョニングパケットを有していると判定した場合には、ログインロジック364がその通常のルーチン内で機能できるようにすることができ、またユーザがコンピューティングデバイス202にログオンできるようにすることができる。しかし、強制アドオンモジュール352は、コンピューティングデバイス202が十分なプロビジョニングパケットを有していないと判定した場合には、非アクティブな状態に入るようコンピューティングデバイス202に強制する。そのような非アクティブな状態においては、コンピューティングデバイス202を起動するのにちょうど必要なだけの限られたユーザインターフェースが、コンピューティングデバイス202のユーザに提供される。
【0061】
測定モジュール354は、残量マネージャー(balance manager)366を含むことができ、この残量マネージャー366は、提供されたリソースを使用するために利用可能な現在の残量を読み取って確認し、現在の残量を更新し、プロビジョニングパケットを処理する。測定モジュール354は、構成マネージャー368と、常に増進するタイマを維持するためのリライアブルクロックマネージャー(reliable clock manager)370とを含むこともできる。リライアブルクロックマネージャー370は、常に増進するタイマを維持するという課題を達成するために、リライアブルハードウェアクロック(reliable hardware clock)372を使用することができる。残量マネージャー366およびリライアブルクロックマネージャー370は、LPM224の安全なオペレーションにとって非常に敏感かつ重要であり、したがって、LPM224のオペレーション中にさまざまなセキュリティー上の攻撃にさらされる可能性が高い。
【0062】
強制アドオンモジュール352および測定モジュール354は、コンピューティングデバイス202上で提供されたリソースのアクティブ化および非アクティブ化を実施するために連携することができる。強制アドオンモジュール352は、特定のイベントに基づいて残量マネージャー366を呼び出すログインロジック364内のイベントディスパッチャーとして機能することができ、その一方で、残量マネージャー366は、イベントに応答して呼び出された際にどのアクションを取るべきかを判断することができる。強制アドオンモジュール352に残量マネージャー366をアクティブ化させることができるさまざまなイベントの例は、(1)ログオンイベント、(2)システムアンロックイベント、(3)ハイバネーションイベントからの復旧、(4)スタンバイイベントからの起動、(5)ユーザによってトリガーされたイベント、(6)ログオフイベント、(7)パケットのダウンロード、(8)タイマチック(timer tick)、(10)システムロックイベント、(11)スクリーンセーバの始動イベント、(12)スクリーンセーバの停止イベントなどである。残量マネージャー366は、そのイベントを入力として受け取り、結果としてのアクションを強制アドオンモジュール352に返すことができる。
【0063】
たとえば、ユーザがログオンしているときに、強制アドオンモジュール352は、ユーザログオンイベントを残量マネージャー366へ送信することができる。そのユーザログオンイベントに応答して、残量マネージャー366は、提供されたリソースを使用するために利用可能な現在の残量を問い合わせることができ、残量が十分である場合には、残量マネージャー366は、ログオンアクションを強制アドオンモジュール352に返すことができる。しかし、残量が十分でない場合には、強制アドオンモジュール352は、ログインロジック364に通知ユーザインターフェース(UI)398を返させることができ、この場合には、この通知UIによって、ユーザは、プロビジョニングサービスモジュール204からさらなるプロビジョニングパケットを購入することによって残量を増やし、したがってコンピューティングデバイス202をアクティブ化することができる。
【0064】
トランザクションエンジン356は、残量マネージャー366内の残量およびパケット消費カウンタを更新するためにプロビジョニングパケットを処理することができる。トランザクションエンジン356は、残量を更新するために、いかなるプロビジョニングパケットも必ず1回だけ消費されるようにすることができる。トランザクションエンジン356は、残量およびパケット消費カウンタを一緒に更新するように、したがって、残量およびパケット消費カウンタの双方が更新されるか、または残量およびパケット消費カウンタのどちらも更新されないかのいずれかになるように設計することができる。あるいは、トランザクションエンジン356は、何らかの予期せぬイベントによって残量データが駄目になることのないように残量データの一貫性を維持するために使用することもできる。トランザクションエンジン356の機能の一例を以降で提供する。
【0065】
この例では、ユーザが、提供されたリソースのための使用時間を購入するために2枚のプリペイドカードを使用し、第1のカードは10時間用で、第2のカードは20時間用であると仮定する。プロビジョニングサービスモジュール204は、合計の残量を保持していないため、10時間用および20時間用という2つの別々のセットのライセンス情報が、プロビジョニングサービスモジュール204において作成される。ユーザが、プロビジョニングサービスモジュール204に連絡を取って、プロビジョニングパケットをコンピューティングデバイス202上にダウンロードする場合には、コンピューティングデバイス202上にダウンロードされるプロビジョニングパケットのそれぞれは、一意のプロビジョニングパケット番号を有する。トランザクションエンジン356は、第1のパケットを処理する際に、パケット消費カウンタを進めて、残量を10時間増やし、次いで第2のパケットを処理する際に、再びパケット消費カウンタを進めて、残量をさらに20時間増やす。
【0066】
セキュアードストレージマネージャー(secured storage manager)358は、残量データをユーザが改ざんできないように、および残量データにLPM224のみがアクセスできるように、保護された方法でLPM224が残量データを保存できるようにすることができる。プロビジョニングパケットは、LPM224によってダウンロードされた後、セキュアードストレージマネージャー358内に保存することができる。同様に、残量カウンタおよびパケット消費カウンタも、セキュアードストレージマネージャー358内に保存することができる。図示されている実装形態においては、セキュアードストレージマネージャー358は、dll(dynamic link library)として実装され、それによって、ユーザ経験モジュール362は、セキュアードストレージマネージャー358にアクセスすることができる。
【0067】
セキュアードストレージマネージャー358内に保存されているデータの安全を確保するために、データ暗号化キーを使用して、データをセキュアードストレージマネージャー358内に保存することができ、データ暗号化キーを有するモジュールのみが、セキュアードストレージマネージャー358からデータを読み取ることができる。セキュアードストレージマネージャー358は、LSAデータベース376と通信するためのローカルセキュリティーオーソリティー(LSA)サブシステム(local security authority (LSA) subsystem)374、セキュアハードウェアストレージ(secure hardware storage)380と通信するためのストレージドライバ378、およびコンピューティングデバイス202上のファイル384と通信するためのファイルシステムドライバ382と通信することができる。さらなるセキュリティーのために、セキュアードストレージマネージャー358の代替実装形態は、セキュアードストレージマネージャー358内に保存されているデータの複数のコピーを使用することもでき、それによって、それぞれのコピーを相互参照して、データのどの単一のコピーにも改ざんがまったくないようにすることができる。ここで論じているLPM224の実装形態では、セキュアードストレージマネージャー358はソフトウェア内に実装されているが、ある代替実装形態においては、セキュアードストレージマネージャー358をハードウェア内に実装することもできる。
【0068】
通信モジュール360は、プロビジョニングパケットおよび/または証明書をプロビジョニングサービスモジュール204に要求するためのパケット/証明書要求マネージャー386と、さらなるプロビジョニングパケットを課金システム216から、および/またはプロビジョニングサービスモジュール204から購入するための購入マネージャー388と、LPM224がネットワーク10と通信できるようにするウェブサービス通信マネージャー390とを含むことができる。
【0069】
パケット/証明書要求マネージャー386は、ユーザ経験モジュール362からの要求を受信して、パケットまたは証明書をプロビジョニングサービスモジュール204に要求することができる。たとえば、ユーザがInitKeyをUIに入力することによってクライアントデバイスに初めてログオンしている場合には、ユーザ経験モジュール362は、そのInitKeyをパケット/証明書要求マネージャー386に渡すことができ、パケット/証明書要求マネージャー386は、プロビジョニングサービスモジュール204と通信して、プロビジョニングサービスモジュール204から証明書を受け取ることができる。パケット/証明書要求マネージャー386は、証明書またはプロビジョニングパケットが首尾よくダウンロードされたらプロビジョニングサービスモジュール204に確認応答を行うことを担当することもできる。パケット/証明書要求マネージャー386は、プロビジョニングプロトコルを使用して、プロビジョニングサービスモジュール204と通信することができる。パケット/証明書要求マネージャー386によってダウンロードされたパケットは、セキュアードストレージマネージャー358内に保存することができる。
【0070】
購入マネージャー388は、コンピューティングデバイス202のユーザから支払情報を受信して、その支払情報を課金システム216へ、またはプロビジョニングサービスモジュール204へ伝達することによって、そのユーザがさらなるプロビジョニングパケットを購入できるようにすることができる。パケット/証明書要求マネージャー386および購入マネージャー388の双方は、ウェブサービス通信マネージャー390を使用して、ネットワーク10と通信することができる。ウェブサービス通信マネージャーは、ネットワークサービスマネージャー392およびネットワークインターフェースカード(NIC)394を使用して、ネットワーク10と通信することができる。この実装形態においては、ネットワーク10と通信するために、ウェブサービス通信マネージャー390が使用されているが、代替実装形態においては、ネットワーク10と通信するために、FTP(file transfer protocol)ドライバなどのその他の通信ツールを使用することができるという点に留意されたい。
【0071】
ユーザ経験モジュール362は、パケット/証明書要求マネージャー386がプロビジョニングサービスモジュール204から証明書をダウンロードできるようにするInitKeyを入力するようユーザに要求するためのアクティブ化ユーザインターフェース(UI)396と、LPM224がユーザと対話できるようにする通知UI398とを含むことができる。たとえばユーザが、提供されたリソースを使用するためのプリペイドカードを購入している場合には、アクティブ化UI396は、そのプリペイドカードによって提供される番号を入力するようユーザに要求し、パケット/証明書要求マネージャー386を呼び出して、そのプリペイドカード番号に対応する最新のプロビジョニングパケットをダウンロードすることができる。アクティブ化UI396は、購入マネージャー388を呼び出して、ユーザがさらなるプロビジョニングパケットを購入できるようにすることもでき、また購入の完了時にパケット/証明書要求マネージャー386を自動的に呼び出して、その購入に対応するプロビジョニングパケットをダウンロードできるように設計することができる。
【0072】
通知UI398は、ユーザが現在の残量情報や使用履歴などを問い合わせることができるようにするさまざまなユーザインターフェースを含むことができる。通知UI398は、ユーザによって、またはログインロジック364によって呼び出すことができる。提供されたリソースを使用するために利用可能な残量が少ない状況では、ログインロジック364は、通知UI398を呼び出して、さらなる購入が必要であることをユーザに知らせることができる。通知UIは、絶え間なくアクティブであることができ、タスクバーアイコン、コントロールパネルアプレット、バルーンポップアップ(balloon pop−up)を介して、またはその他の任意の一般に知られているUIの方法を使用することによって、通知サービスをユーザに提供することができる。
【0073】
ソフトウェアプロビジョニングシステム200のさまざまなコンポーネントについて説明したが、以降の図9〜図12では、ソフトウェアプロビジョニングシステム200のオペレーションについてさらに詳しく説明する。
【0074】
(InitKeyの登録)
図9は、InitKeyをコアプロビジョニングサービス206に登録するために使用できる登録プログラム430のフローチャートを示している。ブロック432において、InitKeyのプロバイダは、InitKey登録要求をコアプロビジョニングサービス206へ送信する。前述のように、このプロバイダは、コンピューティングデバイス202のベンダ、コンピューティングデバイス202のオペレーティングシステム用の使用権のベンダ、ソフトウェアプロビジョニングシステム200の顧客サービス担当者(CSR、customer service representative)など、サードパーティーによって管理できる課金システム216とすることができる。
【0075】
InitKey登録要求は、コアプロビジョニングサービス206のメッセージ待ち行列内で受信することができる。コアプロビジョニングサービス206は、そのメッセージ待ち行列内でInitKey登録要求を認識すると、ブロック434において、登録プロセスを開始することができる。
【0076】
ブロック436においては、InitKeyをコアデータベース212のブートストラップテーブル312に追加することができ、登録プログラム430は、ブートストラップステータスを「Created」に設定することができる。
【0077】
その後、ブロック438において、コアプロビジョニングサービス206は、「Bootstrap Created」のメッセージをコンピューティングデバイスログテーブル322内に記録することができる。
【0078】
最後に、ブロック440において、コアプロビジョニングサービス206は、「Bootstrap Publish」のメッセージを配信データベース214のメッセージ待ち行列へ送信することができる。
【0079】
(パケットの作成)
図10は、コンピューティングデバイス202のLPM224によって使用されるプロビジョニングパケットを作成するために使用できるパケット作成プログラム450のフローチャートを示している。
【0080】
ブロック452において、課金アダプタ218は、プロビジョニングパケットを求めるプロビジョニング要求メッセージをコアプロビジョニングサービス206へ送信することができる。コアプロビジョニングサービス206は、複数の引受会社に接続することができるため、このようなプロビジョニング要求メッセージは、課金アダプタ218をコアプロビジョニングサービス206へ接続するMSMQインターフェース内で待ち行列に入れられる。
【0081】
プロビジョニング要求メッセージを課金アダプタ218から検索すると、ブロック454において、コアプロビジョニングサービス206は、パケット作成トランザクションを開始することができる。
【0082】
ブロック456において、コアプロビジョニングサービス206は、プロビジョニング要求メッセージからのハードウェアIDを使用して、新たなコンピューティングデバイスレコードをコンピューティングデバイステーブル314に追加することができる。しかし、そのハードウェアIDを含むレコードが、コンピューティングデバイステーブル314内に既に存在する場合には、新たなコンピューティングデバイスレコードを追加することは必要でないかもしれない。
【0083】
その後、ブロック458において、コアプロビジョニングサービス206は、新たなジョブレコードをジョブテーブル316に追加して、プロビジョニングパケットを求める新たなジョブ要求を記録することができる。コアプロビジョニングサービス206は、新たに追加されたジョブレコードのステータスを「Created」に設定することができる。ブロック460において、コアプロビジョニングサービス206は、プロビジョニング要求メッセージの日付および時間と共に、新たなレコードをジョブログテーブル326内に追加することができる。
【0084】
ブロック462において、コアプロビジョニングサービス206は、プロビジョニング要求メッセージに基づいてプロビジョニングパケットを作成することができる。パケットの作成は、プロビジョニング要求メッセージ内で提供される証明書を確認すること、プロビジョニングパケットの使用時間の量を追加することなどを含むことができる。
【0085】
ブロック464において、コアプロビジョニングサービス206は、キーマネージャー292と通信して、安全なキーを用いてプロビジョニングパケットに署名し、XMLベースのプロビジョニングパケットを作成することができる。
【0086】
プロビジョニングパケットが作成されると、ブロック466において、コアプロビジョニングサービス206は、コンピューティングデバイステーブル314内の最後のシーケンス番号を1つ増やすことができる。
【0087】
ブロック468において、コアプロビジョニングサービス206は、新たに作成されたプロビジョニングパケットをパケットテーブル318内に挿入し、パケットテーブル318内のプロビジョニングパケットのステータスを「packet created」に設定することができる。
【0088】
その後、ブロック370において、コアプロビジョニングサービス206は、「packet created」のメッセージをジョブログテーブル326内に記録することができる。そして最後に、ブロック372において、コアプロビジョニングサービス206は、「packet publish」のメッセージを配信データベースライタ220へのメッセージ待ち行列内に送信して、そのパケットを配信データベース214内に追加することができる。
【0089】
(ブートストラッピング)
図11は、証明書を証明書サービスモジュール210に要求して、その証明書をコンピューティングデバイス202へ送信するために使用できるブートストラッピングプログラム500のフローチャートを示している。
【0090】
ブロック502において、配信サービスモジュール208は、コンピューティングデバイス202などのコンピューティングデバイスからの証明書要求を受信することができる。この証明書要求は、パケット/証明書要求マネージャー386によって作成し、InitKeyなどのコンピューティングデバイス202用のハードウェアIDを含む情報を含むことができる。
【0091】
ブロック504において、コアプロビジョニングサービス206は、ブートストラップテーブル312内でInitKeyを探すことができる。ブロック506において、コアプロビジョニングサービス206は、コンピューティングデバイステーブル314をチェックして、証明書要求内で提供されているハードウェアIDに関するレコードが含まれているかどうかを確認することができる。コンピューティングデバイステーブル314内に何のレコードも存在しない場合には、コアプロビジョニングサービス206は、レコードをコンピューティングデバイステーブル314内に追加することができる。
【0092】
ブロック508において、コアプロビジョニングサービス206は、「computing device created」のメッセージをコンピューティングデバイスログテーブル322内に記録することができる。その後、ブロック510において、コアプロビジョニングサービス206は、証明書要求トランザクションの処理を開始することができる。
【0093】
ブロック512において、コアプロビジョニングサービス206は、ブートストラップテーブル312をチェックして、配信回数が、構成テーブル320によって指定された最大配信回数よりも多いかどうかを確認することができ、そうである場合には、コントロールをブロック524に移すことができる。
【0094】
配信回数が最大配信回数よりも多くない場合には、ブロック514において、コアプロビジョニングサービス206は、ブートストラップテーブル312内のブートストラップステータスをチェックすることができる。ブートストラップステータスが、「created」または「In Progress」に相当しない場合には、コントロールをブロック524に移すことができる。
【0095】
しかしブートストラップステータスが、「created」または「In Progress」のいずれかに相当する場合には、ブロック516において、コアプロビジョニングサービス206は、ブートストラップテーブル312内のブートストラップステータスを「In Progress」に更新することができる。
【0096】
その後、ブロック518において、コアプロビジョニングサービス206は、「bootstrap in progress」のメッセージをコンピューティングデバイスログテーブル322内に記録することができる。
【0097】
ブロック520において、コアプロビジョニングサービス206は、証明書ユーティリティーを呼び出して、新たなクライアント証明書を作成することができる。新たな証明書を証明書ユーティリティーから受け取ると、ブロック522において、コアプロビジョニングサービス206は、そのクライアント証明書を配信サービスモジュール208のメッセージ待ち行列内に送信することができ、コントロールをブロック530に移すことができる。
【0098】
ブロック524において、コアプロビジョニングサービス206は、ブートストラップテーブル内の配信回数が最大配信回数を超えたことによって、ブートストラップテーブル312内のブートストラップステータスを「over limit」に更新することができる。この「over limit」のステータスは、コアプロビジョニングサービス206が、コンピューティングデバイス202のための証明書を発行したことに応答してLPM224から適切な確認応答を受信していないということを意味する。したがって、ブロック526において、コアプロビジョニングサービス206は、証明書を要求しているコンピューティングデバイスから確認応答がまったく受信されていないということを示す「bootstrap over limit」のメッセージをコンピューティングデバイスログテーブル322内に記録することができる。
【0099】
ブロック528において、コアプロビジョニングサービス206は、「remove bootstrap」のメッセージを配信データベースライタ220のメッセージ待ち行列内に送信して、ブートストラップレコードを配信データベース214から削除することができる。
【0100】
ブロック530は、証明書がクライアントへ送信されると、ブロック522からコントロールを受け取ることができ、したがって、証明書要求の処理の終了を表している。
【0101】
証明書要求が処理されると、ブロック532において、コアプロビジョニングサービス206は、配信サービスモジュール208のメッセージ待ち行列内の証明書ダウンロード完了メッセージを受信することができる。このような証明書ダウンロード完了メッセージは、証明書が首尾よくダウンロードされた後に、LPM224のパケット/証明書要求マネージャー386によって送信することができる。
【0102】
証明書ダウンロード完了メッセージを受信すると、ブロック534において、コアプロビジョニングサービス206は、ブートストラップ完了トランザクション(bootstrap completed transaction)を開始することができる。ブロック536において、コアプロビジョニングサービス206は、ブートストラップテーブル312内のブートストラップステータスを「completed」に更新することができる。その後、ブロック538において、コアプロビジョニングサービス206は、証明書要求を送信しているコンピューティングデバイスのためのブートストラッププロセスが完了したということを示す「bootstrap completed」のメッセージをコンピューティングデバイスログテーブル322内に記録することができる。
【0103】
最後に、ブロック540において、コアプロビジョニングサービス206は、「remove bootstrap」のメッセージを配信データベースライタ220のメッセージ待ち行列内に送信して、ブートストラップレコードを配信データベース214のブートストラップテーブル342から削除することができる。
【0104】
(パケットの配信)
図12は、プロビジョニングパケットをコアプロビジョニングサービス206からコンピューティングデバイス202などのさまざまなコンピューティングデバイスへ配信するために使用できるパケット配信プログラム550のためのフローチャートを示している。パケット配信プログラム550は、パケット/証明書要求マネージャー386によって、コンピューティングデバイスのユーザを補助する顧客サービス担当者によって、あるいはその他の類似の方法で開始することができる。
【0105】
ブロック552において、コアプロビジョニングサービス206は、配信サービスモジュール208のメッセージ待ち行列内のパケットダウンロードメッセージを受信することができる。このようなメッセージは、たとえばコンピューティングデバイス202のパケット/証明書要求マネージャー386によって送信することができる。パケットダウンロードメッセージを受信すると、ブロック554において、コアプロビジョニングサービス206は、パケット要求トランザクションを開始することができる。
【0106】
パケット要求トランザクションのはじめに、ブロック556において、確認サービス209は、パケットテーブル318内のステータスが、パケットダウンロードメッセージを送信しているコンピューティングデバイスがコアプロビジョニングサービス206による以前のパケット送信に対して確認応答を行っていないということを指定する「packet over limit」であるかどうかを判定することができ、コントロールは、ブロック564に移される。
【0107】
パケットテーブル318内のステータスが「packet over limit」ではないと判定された場合には、ブロック558において、コアプロビジョニングサービス206は、パケットテーブル318内のステータスを「delivery in progress」に更新することができる。
【0108】
その後、ブロック560において、コアプロビジョニングサービス206は、パケットテーブル318内の配信回数を、パケットダウンロードメッセージ内で指定されている値に更新することができる。たとえば、パケットダウンロードメッセージが、2つのパケットをコアプロビジョニングサービス206に要求している場合には、パケットテーブル318内の配信回数は、2だけ増加される。ブロック562において、コアプロビジョニングサービス206は、「packet delivery in progress」のメッセージをジョブログテーブル326内に記録することができる。
【0109】
ブロック564は、コンピューティングデバイスからの確認応答がないことによってコントロールを受け取ることができ、したがってブロック564において、コアプロビジョニングサービス206は、パケットテーブル318内のステータスを「over limit」に更新することができる。
【0110】
ブロック566において、コアプロビジョニングサービス206は、パケットテーブル318内の配信回数を、パケットダウンロードメッセージ内で指定されている値に更新することができ、ブロック568において、CPSは、ジョブテーブル316のステータスを「error」に更新する。最後に、ブロック570において、コアプロビジョニングサービス206は、「packet over limit」のメッセージをジョブログテーブル326内に記録することができる。
【0111】
ブロック572において、コアプロビジョニングサービス206は、パケット要求トランザクションの処理を終了することができ、パケットを要求しているコンピューティングデバイスからの確認応答を待つことができる。ブロック574において、コアプロビジョニングサービス206は、配信サービスモジュール208のメッセージ待ち行列内へのパケットダウンロード完了メッセージを受信することができる。このパケットダウンロード完了メッセージは、要求されているパッケージが首尾よくダウンロードされた際に、パケット/証明書要求マネージャー386によって送信することができる。
【0112】
パケットダウンロード完了メッセージを受信すると、ブロック576において、コアプロビジョニングサービス206は、パケットダウンロード完了トランザクションを開始することができる。パケットダウンロード完了トランザクションの一環として、ブロック578において、確認サービスは、パケットテーブル318内のステータスを「completed」に更新し、ブロック580において、ジョブテーブル内のステータスも「completed」に更新することができる。
【0113】
さらに、ブロック580において、コアプロビジョニングサービス206は、「job completed」のメッセージをジョブログテーブル326内に記録し、ブロック582において、パケットダウンロード完了トランザクションを終了することができる。
【0114】
ソフトウェアプロビジョニングシステム200のさまざまなコンポーネントのオペレーションについて説明してきたが、以降の図13〜図16では、さまざまな状況のもとでのユーザの経験を示すさまざまな例示的なシナリオについて説明する。
【0115】
(シナリオ1−ログイン中の残量の確認)
図13は、LPM224のオペレーション中の第1のシナリオを示すフローチャート600を示している。具体的には、フローチャート600は、ユーザがコンピュータにログオンしている場合のシナリオを示している。図13に示されているように、ブロック602において、ユーザがコンピューティングデバイス202へのログオンを試みているときに、強制アドオンモジュール352は、ログオンイベントを残量マネージャー366に送信することができる。このログオンイベントに応答して、ブロック604において、残量マネージャー366は、コンピューティングデバイス202上でオペレーティングシステムを使用するために利用可能な残量を確認することができる。残量が十分である場合には、ブロック606において、残量マネージャー366は、オペレーティングシステムを通常の方法でアクティブ化するようログインロジック364に通知することができる。
【0116】
しかし、残量が十分でないと残量マネージャー366が判定した場合には、ブロック608において、残量マネージャー366は、アクティブ化UI396をアクティブ化することができる。アクティブ化UIをアクティブ化する目的は、ユーザがさらなる使用時間を購入できるようにすることである。
【0117】
ブロック610において、アクティブ化UI396は、購入マネージャー388をアクティブ化することができ、ユーザは、購入を行うことができる。ユーザは、課金システム216に接続することによって、顧客サービス担当者に電話をかけることによって、あるいはその他の任意の所望の方法で、購入を行うことができる。その後、ブロック612において、証明書/パケット要求マネージャー386は、プロビジョニングパケットをダウンロードすることができる。
【0118】
証明書/パケット要求マネージャー386は、ダウンロードされたプロビジョニングパケットを安全なストレージのためのセキュアストアマネージャ358に提供することができる。ブロック614において、残量マネージャー366は、ダウンロードされたプロビジョニングパケットを分析することができ、ブロック616において、コンピューティングデバイス202にとって利用可能なプロビジョニング残量(provisioning balance)をしかるべく増やすことができる。
【0119】
(シナリオ2−ログオン後の使用権の購入)
図14は、LPM224のオペレーション中の第2のシナリオを示すフローチャート620を示している。具体的には、フローチャート620は、ユーザがコンピューティングデバイス202に既にログオンしていて、コントロールパネルアプレットまたはタスクバーアイコンを選択して、残量マネージャー366をアクティブ化する場合のシナリオを示している。
【0120】
ブロック622において、ユーザは、イベントを残量マネージャー366に送信するコントロールパネルアプレットをアクティブ化することができる。残量マネージャー366は、現在の残量情報をユーザに表示して、アクティブ化UI396を呼び出し、それによって購入マネージャー388をアクティブ化することができる。ユーザがさらなる時間の購入を行うと、証明書/パケット要求マネージャー386は、プロビジョニングパケットをダウンロードすることができる。
【0121】
証明書/パケット要求マネージャー386は、ダウンロードされたプロビジョニングパケットを安全なストレージのためのセキュアストアマネージャ358に提供することができる。ブロック628において、残量マネージャー366は、ダウンロードされたプロビジョニングパケットを分析することができ、ブロック630において、コンピューティングデバイス202にとって利用可能なプロビジョニング残量をしかるべく増やすことができる。
【0122】
(シナリオ3−ログオン後の残量の更新および通知)
図15は、LPM224のオペレーション中の第3のシナリオを示すフローチャート640を示している。具体的には、フローチャート640は、ユーザがコンピューティングデバイス202に既にログオンしていて、ログインロジック364がリライアブルクロックマネージャー370からのタイムチックの結果としてのイベントを受信する場合のシナリオを示している。
【0123】
ブロック642において、ログインロジック364は、リライアブルクロックマネージャー370からタイムチックイベントを受信することができる。結果として、ログインロジック364は、タイムチックイベントを残量マネージャー366へ送信することができる。
【0124】
そのタイムチックイベントに応答して、ブロック644において、残量マネージャー366は、コンピューティングデバイス202上でオペレーティングシステムを使用するために利用可能な残量を更新することができる。その後、ブロック646において、残量マネージャー366は、利用可能な残量をチェックする。その評価の結果に基づいて、ブロック648において、残量マネージャー366は、適切なアクションを取ることができ、このアクションは、たとえば、アクティブ化UI396をアクティブ化すること、ユーザをログオフさせること、その他の適切なアクションを継続することとすることができる。
【0125】
(シナリオ4−コンピューティングデバイスの非アクティブ化)
図16は、LPM224のオペレーション中の第4のシナリオを示すフローチャート660を示している。具体的には、フローチャート660は、ユーザがコンピューティングデバイス202に既にログオンしていて、ログインロジック364がリライアブルクロックマネージャー370からのタイムチックの結果としてのイベントを受信する場合のシナリオを示している。
【0126】
ブロック662において、ログインロジック364は、リライアブルクロックマネージャー370からタイムチックイベントを受信することができる。結果として、ログインロジック364は、タイムチックイベントを残量マネージャー366へ送信することができる。
【0127】
そのタイムチックイベントに応答して、ブロック664において、残量マネージャー366は、コンピューティングデバイス202上でオペレーティングシステムを使用するために利用可能な残量を更新することができる。その後、ブロック666において、残量マネージャー366は、利用可能な残量をチェックすることができる。その評価の結果に基づいて、ブロック668において、残量マネージャー366は、適切なアクションを取ることができ、このアクションは、たとえば、アクティブ化UI396をアクティブ化すること、ユーザをログオフさせること、その他の適切なアクションを継続することとすることができる。
【0128】
この場合には、たとえば、残量マネージャー366は、コンピューティングデバイス202にとって利用可能な残量が、しきい値にあるか、またはゼロなど、しきい値を下回っていることを検知する。結果として、ブロック668において、残量マネージャー366は、通知UI398にログオフメッセージを表示させることができ、最終的には、コンピューティングデバイス202上でオペレーティングシステムを使用している状態からユーザをログオフさせる。別の場合には、通知UI398は、購入マネージャー388をアクティブ化して、ユーザがさらなる使用時間を購入できるようにすることもできる。
【0129】
(シナリオ5−ログオン後の前払いの入力)
図17は、LPM224のオペレーション中の第5のシナリオを示すフローチャート680を示している。具体的には、フローチャート680は、ユーザがコンピューティングデバイス202に既にログオンしていて、コントロールパネルアプレットまたはタスクバーアイコンを選択して、プリペイドカードから情報を入力するためにアクティブ化ウィザードをアクティブ化する場合のシナリオを示している。これは、ユーザがプリペイドカードを以前に購入していて、そのプリペイドカードによって入手できる使用時間を自分のアカウントに追加しようと決めた場合に当てはまるかもしれない。
【0130】
ブロック682において、ユーザは、アクティブ化ウィザードを表示するためのアクティブ化UI396へイベントを送信するコントロールパネルアプレットをアクティブ化することができる。ユーザに表示できるGUIウィンドウの一例について、図18の追加時間ウィンドウ684によって説明する。ユーザは、追加時間ウィンドウ684から追加時間ボタンを選択して、プリペイドカードからの情報を入力することができる。
【0131】
その後、ブロック686において、アクティブ化UI396は、ユーザがアクティブ化ウィザードを使用できるようにする上で必要となるかもしれないさまざまな情報をユーザに通知することができ、このアクティブ化ウィザードは、図19のGUI688によって示されている。
【0132】
ブロック690において、アクティブ化UI396は、図20に示されているようなネットワーク接続GUI692を提示することができ、このネットワーク接続GUI692は、ウェブサービス通信マネージャー390がコアプロビジョニングサービス206にアクセスするためにインターネットに接続していることをユーザに通知する。
【0133】
その後、ブロック694において、アクティブ化UI396は、プリペイド使用権カード(pre−paid usage card)から受け取ったキーを入力するようユーザに促すことができる。プリペイドカード上のキーは、英数字やその他の文字の文字列を含むことができる。この場合には、キーは、図21のGUI696へ入力するものとして示されているように、25文字の長さの英数字のキーである。
【0134】
プリペイドカードからのキーを受信すると、ブロック698において、アクティブ化UI396は、図22のGUI700によって示されているように、.NET(登録商標)システムにログインするようユーザに促すことができる。ユーザが.NET(登録商標)システムにログインすることが常に必要というわけではないかもしれないという点に留意されたい。
【0135】
その後、ブロック702において、アクティブ化UI396は、プリペイドカードからのユーザのキーが受け入れられたこと、および対応する時間だけユーザのアカウントが増えるはずであることの確認をコアプロビジョニングサービス206から受信することができる。首尾よく時間が追加されたことを通知するメッセージは、図23のGUI704によって示されている。
【0136】
最後に、ブロック706において、アクティブ化UI396は、図24のGUI708によって示されているように、ユーザがプリペイドカードを使用することによって今しがた追加した時間が数分でコンピューティングデバイス202の貸方に記入される旨をユーザに通知することができる。
【0137】
上述の文章は、本発明の多くの異なる実施形態の詳細な説明を記載しているが、本発明の範囲は、本特許に添付されている特許請求の範囲の文言によって定義されるという点を理解されたい。この詳細な説明は、例示的なものにすぎないと解釈されるべきであり、本発明の可能な実施形態をすべて説明しているわけではない。というのも、可能な実施形態をすべて説明することは、不可能ではないにしても、非現実的と思われるためである。本発明を定義する特許請求の範囲内に今後とも収まるであろう現在の技術または本特許の出願日以降に開発される技術を使用して、多くの代替実施形態を実施することができる。
【0138】
したがって、本発明の趣旨および範囲から逸脱することなく、本明細書で説明および例示されている技術および構造において、多くの修正形態および変形形態を作成することができる。したがって、本明細書に記載されている方法および装置は、例示的なものにすぎず、本発明の範囲を限定するものではないという点を理解されたい。
【図面の簡単な説明】
【0139】
【図1】複数のコンピューティングリソースを相互接続するネットワークを示すブロック図である。
【図2】図1のネットワークに接続することができるコンピュータを示すブロック図である。
【図3】図1のネットワークのコンピュータ上にオペレーティングシステムを提供するためのソフトウェアプロビジョニングシステムを示すブロック図である。
【図4】図3のソフトウェアプロビジョニングシステム上でのコンピュータの登録を示すフローチャートである。
【図5】図3のソフトウェアプロビジョニングシステムのコアプロビジョニングシステム(core provisioning system)を示すブロック図である。
【図6】図5のコアプロビジョニングシステムによって使用されるコアデータベースを示すブロック図である。
【図7】図3のコアソフトウェアプロビジョニングシステムによって使用される配信データベースを示すブロック図である。
【図8】図3のソフトウェアプロビジョニングシステムのローカルプロビジョニングモジュール(local provisioning module)を示すブロック図である。
【図9】図3のソフトウェアプロビジョニングシステムによって使用されるキー登録プログラムを示すフローチャートである。
【図10】図3のソフトウェアプロビジョニングシステムによって使用されるパケット作成プログラムを示すフローチャートである。
【図11】図3のソフトウェアプロビジョニングシステムによって使用されるブートストラッピングプログラム(bootstrapping program)を示すフローチャートである。
【図12】図3のソフトウェアプロビジョニングシステムによって使用されるパケット配信プログラムを示すフローチャートである。
【図13】図8のローカルプロビジョニングモジュールのためのオペレーティングシナリオ(operating scenario)を示すフローチャートである。
【図14】図8のローカルプロビジョニングモジュールのためのオペレーティングシナリオを示す別のフローチャートである。
【図15】図8のローカルプロビジョニングモジュールのためのオペレーティングシナリオを示す別のフローチャートである。
【図16】図8のローカルプロビジョニングモジュールのためのオペレーティングシナリオを示す別のフローチャートである。
【図17】図8のローカルプロビジョニングモジュールのためのオペレーティングシナリオを示すさらに別のフローチャートである。
【図18】図17のオペレーティングシナリオの最中にユーザに提示される例示的なGUIを示す図である。
【図19】図17のオペレーティングシナリオの最中にユーザに提示される別の例示的なGUIを示す図である。
【図20】図17のオペレーティングシナリオの最中にユーザに提示される別の例示的なGUIを示す図である。
【図21】図17のオペレーティングシナリオの最中にユーザに提示される別の例示的なGUIを示す図である。
【図22】図17のオペレーティングシナリオの最中にユーザに提示される別の例示的なGUIを示す図である。
【図23】図17のオペレーティングシナリオの最中にユーザに提示される別の例示的なGUIを示す図である。
【図24】図17のオペレーティングシナリオの最中にユーザに提示される別の例示的なGUIを示す図である。
【技術分野】
【0001】
本特許は、一般にコンピュータに関し、より詳細にはコンピュータ管理システムに関する。
【背景技術】
【0002】
世界の人口の大きな割合は、コンピュータ、および/またはそのコンピュータを効率よく使用できるようにするさまざまなソフトウェアを所有するだけの経済的な余裕がない。発展途上国の人々にコンピューティングへの手ごろな価格のアクセスを提供したいというニーズがある。これは、ソフトウェアライセンスが一般に永久のライセンスを基準として販売されているソフトウェア業界の伝統的な構造に照らしても真実である。人々はまた、さまざまなソフトウェアのための永久のライセンスを購入するための十分な資金を持っていない結果として、そのようなソフトウェアをトレーニングの目的などのために短期間使用することさえ禁じられている。さらに先進国においてさえ、コンピュータユーザは、特定のソフトウェアを一定の時間だけ使用する必要がある場合に、その特定のソフトウェアのための永久のライセンスを購入する必要性によって意欲をそがれる。
【0003】
これは、コンピュータ用のオペレーティングシステムの場合に特に当てはまる。技術的に進んだコンピュータの計算能力、およびインターネットを通じて利用可能なリソースを使用する際には、コンピュータ、ならびにそのコンピュータとインターネットおよびその他のリソースとの通信を操作するために高性能なオペレーティングシステムを使用することが必要である。しかしソフトウェアの場合と同様に、オペレーティングシステムも、一般に永久のライセンスと共に販売されており、そのような永久のライセンスの価格は通常、第3世界のさまざまな国々の人々の購買力に比べて非常に高額である。
【発明の開示】
【発明が解決しようとする課題】
【0004】
永久のライセンスを購入する必要なくソフトウェアを使用できるようにするための、既存のものに取って代わるソリューションを提供するために、さまざまなビジネスモデルが試されてきた。たとえば、さまざまな企業が、ASP(application service provider)モデルに基づくソフトウェアを提供しており、このモデルでは、ユーザは、インターネットなどのネットワークのサーバ上に常駐しているソフトウェアに、そのサーバへログインすることによってアクセスすることができる。しかしこの方法では、ユーザは、インターネットを介してサーバに絶え間なく接続している必要がある。これは、インターネットへのアクセスが高価で信頼できないさまざまな発展途上国において発展できるソリューションではない。あるいは、ソフトウェアプロバイダは、ユーザがソフトウェアを一定の時間だけダウンロードできるようにしている場合が多いが、これは一般に試用のためであり、その後ユーザは、そのソフトウェアのための永久のライセンスを購入しなければならない。しかし、そのような試用版のソフトウェアを使用するための時間は、通常は固定されており、ユーザは、自分自身の選択のために時間を購入することや、固定された時間を追加するために試用版ソフトウェアのユーザを更新することを選択することができない。容易に理解できるように、ユーザがさまざまな異なる方法でソフトウェアサービスを購入できるような方法でユーザにそれらのサービスを提供したいというニーズがある。
【課題を解決するための手段】
【0005】
動的なソフトウェアプロビジョニングシステムは、所望のビジネスプロセスに基づいて複数の異なるコンピューティングデバイス上にソフトウェアを提供することを可能にする。この動的なソフトウェアプロビジョニングシステムによって、ユーザは、オペレーティングシステムを、特定の時間だけ、特定の使用量だけ、あるいはその他の任意の所望の方法で使用することを、オペレーティングシステムプロビジョニングサービス(operating system provisioning service)に、あるいはサードパーティーに要求することができる。このプロビジョニングサービスは、オペレーティングシステムの使用を提供してほしいというユーザからの、あるいはサードパーティーからの要求を処理し、その要求に応答して、その要求によって指定された特定のデバイスのためのオペレーティングシステムの使用を提供する。この動的なソフトウェアアクティブ化システムはまた、オペレーティングシステムを使用するデバイス上に配置されたローカルプロビジョニングモジュールを含み、このローカルプロビジョニングモジュールは、プロビジョニングサービスから受信した命令に基づいてオペレーティングシステムをアクティブ化したり、非アクティブ化したりする。
【0006】
ある代替実装形態においては、動的なソフトウェアプロビジョニングシステムは、ユーザが、プリペイドカードを購入することによってソフトウェアの使用権を購入できるようにする。そのプリペイドカードを使用して、ユーザは、プロビジョニングパケットをダウンロードすることができ、このプロビジョニングパケットによって、ユーザは、指定された時間だけソフトウェアを使用することができる。さらに別の実装形態においては、動的なソフトウェアシステムは、引受会社が、ソフトウェア付きのコンピュータと、そのソフトウェアを使用するための指定された量の時間とを販売できるようにする。
【0007】
さらに別の代替実装形態においては、動的なソフトウェアプロビジョニングシステムは、ユーザが、プリペイドカードを購入することによってオペレーティングシステムの使用権を購入できるようにする。そのプリペイドカードを使用して、ユーザは、プロビジョニングパケットをダウンロードすることができ、このプロビジョニングパケットによって、ユーザは、指定された時間だけオペレーティングシステムを使用することができる。さらに別の実装形態においては、動的なソフトウェアシステムは、引受会社が、オペレーティングシステム付きのコンピュータと、そのオペレーティングシステムを使用するための指定された量の時間とを販売できるようにする。
【0008】
さらに別の実装形態においては、動的なソフトウェアプロビジョニングシステムは、提供されたデバイスを登録することを求める登録要求を受信するステップであって、その登録要求は、提供されたデバイスのハードウェアIDを含むステップと、提供されたデバイスの証明書を作成するステップと、提供されたデバイスのパケットを作成することを求めるパケット作成要求を受信するステップであって、そのパケット作成要求は、提供されたデバイスの初期設定キーを含むステップと、提供されたデバイスのパケットを作成するステップであって、その提供されたデバイスのパケットは、その提供されたデバイス上でのサービスの第1の使用量を承認する情報を含むステップとを含む方法を実行するためのコンピュータ実行可能命令を有するコンピュータ可読媒体を含む。
【発明を実施するための最良の形態】
【0009】
以降の文章は、多くの異なる実施形態の詳細な説明を記載しているが、この説明の法的な範囲は、本特許に添付されている特許請求の範囲の文言によって定義されるという点を理解されたい。この詳細な説明は、例示的なものにすぎないと解釈されるべきであり、可能な実施形態をすべて説明しているわけではない。というのも、可能な実施形態をすべて説明することは、不可能ではないにしても、非現実的と思われるためである。本発明を定義する特許請求の範囲内に今後とも収まるであろう現在の技術または本特許の出願日以降に開発される技術を使用して、多くの代替実施形態を実施することができる。
【0010】
また用語については、「本明細書で使用する際、「 」という用語は、...を意味するものと定義する」という文や類似の文を使用して本特許内で明確に定義されていない限り、その用語の意味を、明示的にも暗示的にも、その率直な意味すなわち通常の意味を越えて限定する意図はまったくなく、またそのような用語は、本特許のいずれかのセクションにおいて行われているいずれかの記述(特許請求の範囲の言葉は除く)に基づく範囲に限定されるものと解釈すべきではないという点を理解されたい。本特許に添付されている特許請求の範囲に記載されているいずれかの用語が、ある単一の意味と一致した方法で本特許内で言及されている限りにおいては、それは、もっぱら読者を混乱させないように明確にする目的で行われているものであり、そのような特許請求の範囲の用語を、暗示などによって、その単一の意味に限定することを意図するものではない。最後に、請求項の要素が、いかなる構造についても記載せずに「手段」という言葉と機能とを記載することによって定義されているのでない限り、いかなる請求項の要素の範囲も、35 U.S.C.セクション112、第6パラグラフの適用に基づいて解釈されることを意図するものではない。
【0011】
(ネットワーク)
図1は、動的なソフトウェアプロビジョニングシステムを実装するために使用することができるネットワーク10を示している。ネットワーク10は、インターネット、VPN(virtual private network)、あるいは1つまたは複数のコンピュータ、通信デバイス、データベースなどが相互に通信可能に接続されることを可能にするその他の任意のネットワークとすることができる。ネットワーク10は、イーサネット(登録商標)16、およびルータ18、ならびに地上通信線20を介してパーソナルコンピュータ12およびコンピュータ端末14に接続することができる。その一方で、ネットワーク10は、無線通信局26および無線リンク28を介してラップトップコンピュータ22およびパーソナルデータアシスタント(personal data assistant)24に無線で接続することができる。同様に、サーバ30は、通信リンク32を使用してネットワーク10に接続することができ、メインフレーム34は、別の通信リンク36を使用してネットワーク10に接続することができる。以降でさらに詳しく説明するように、この動的なソフトウェアプロビジョニングシステムの1つまたは複数のコンポーネントは、ネットワーク10に接続されるさまざまなデバイスのいずれに格納して機能させることもできる。
【0012】
(コンピュータ)
図2は、動的なソフトウェアプロビジョニングシステムの1つまたは複数のコンポーネントを実装するためにネットワーク10に接続して使用することができるコンピュータ110の形態のコンピューティングデバイスを示している。コンピュータ110のコンポーネントは、処理装置120と、システムメモリ130と、システムメモリを含むさまざまなシステムコンポーネントを処理装置120に結合するシステムバス121とを含むことができるが、これらには限定されない。システムバス121は、メモリバスまたはメモリコントローラと、ペリフェラルバスと、さまざまなバスアーキテクチャーのいずれかを使用するローカルバスとを含む複数のタイプのバス構造のいずれにすることもできる。たとえばこのようなアーキテクチャーは、ISA(Industry Standard Architecture)バス、MCA(Micro Channel Architecture)バス、EISA(Enhanced ISA)バス、VESA(Video Electronics Standards Association)ローカルバス、およびメザニンバスとしても知られているPCI(Peripheral Component Interconnect)バスを含むが、これらには限定されない。
【0013】
コンピュータ110は通常、さまざまなコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ110によってアクセスできる利用可能な任意のメディアとすることができ、揮発性メディアおよび不揮発性メディア、ならびに取り外し可能メディアおよび固定式メディアの双方を含む。たとえばコンピュータ可読媒体は、コンピュータストレージメディアおよび通信メディアを含むことができるが、これらには限定されない。コンピュータストレージメディアは、コンピュータ可読命令、データ構造、プログラムモジュール、その他のデータなどの情報を記憶するための任意の方法または技術において実装される揮発性メディアおよび不揮発性メディア、ならびに取り外し可能メディアおよび固定式メディアを含む。コンピュータストレージメディアは、RAM、ROM、EEPROM、フラッシュメモリ、またはその他のメモリ技術、CD−ROM、DVD(digital versatile disk)、またはその他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、またはその他の磁気ストレージデバイス、あるいは所望の情報を保存するために使用可能で、コンピュータ110によってアクセス可能なその他の任意のメディアを含むが、これらには限定されない。通信メディアは通常、搬送波やその他の伝送メカニズムなどの変調されたデータ信号内のコンピュータ可読命令、データ構造、プログラムモジュール、あるいはその他のデータを具体化し、任意の情報伝達メディアを含む。「変調されたデータ信号」という用語は、情報をその信号内でコード化するような方法で設定または変更されたその特性のうちの1つまたは複数を有する信号を意味する。たとえば通信メディアは、有線ネットワークや直接有線接続などの有線メディアと、音波メディア、無線周波数メディア、赤外線メディア、その他の無線メディアなどの無線メディアとを含むが、これらには限定されない。また上記のいずれの組合せも、コンピュータ可読媒体の範囲内に含まれるものである。
【0014】
システムメモリ130は、コンピュータストレージメディアを、ROM(read only memory)131およびRAM(random access memory)132などの揮発性メモリおよび/または不揮発性メモリの形態で含む。BIOS(basic input/output system)133は、起動中などにコンピュータ110内の要素どうしの間における情報伝達を補助する基本ルーチンを含み、通常はROM131内に格納されている。RAM132は通常、処理装置120がすぐにアクセスできるか、および/または処理装置120によってその時点で操作されているデータモジュールおよび/またはプログラムモジュールを含む。図1は、例としてオペレーティングシステム134、アプリケーションプログラム135、その他のプログラムモジュール136、およびプログラムデータ137を示しているが、これらには限定されない。
【0015】
またコンピュータ110は、その他の取り外し可能/固定式、揮発性/不揮発性コンピュータストレージメディアを含むこともできる。図1は、例示のみを目的として、固定式の不揮発性の磁気メディアとの間で読み取りや書き込みを行うハードディスクドライブ141と、着脱式不揮発性の磁気ディスク152との間で読み取りや書き込みを行う磁気ディスクドライブ151と、CD−ROMやその他の光メディアなどの着脱式不揮発性の光ディスク156との間で読み取りや書き込みを行う光ディスクドライブ155とを示している。典型的な動作環境において使用できるその他の取り外し可能/固定式、揮発性/不揮発性コンピュータストレージメディアとしては、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートRAM、ソリッドステートROMなどがあるが、これらには限定されない。ハードディスクドライブ141は通常、インターフェース140などの固定式のメモリインターフェースを介してシステムバス121に接続されており、磁気ディスクドライブ151および光ディスクドライブ155は通常、インターフェース150などの着脱式メモリインターフェースによってシステムバス121に接続されている。
【0016】
図1に示されている上述のドライブおよびそれらに関連するコンピュータストレージメディアは、コンピュータ110用のコンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの記憶を提供する。たとえば図1において、ハードディスクドライブ141は、オペレーティングシステム144、アプリケーションプログラム145、その他のプログラムモジュール146、およびプログラムデータ147を記憶するものとして示されている。これらのコンポーネントは、オペレーティングシステム134、アプリケーションプログラム135、その他のプログラムモジュール136、およびプログラムデータ137と同一とするか、または異なっていてもよいという点に留意されたい。ここでは、オペレーティングシステム144、アプリケーションプログラム145、その他のプログラムモジュール146、およびプログラムデータ147が最低限異なるコピーであることを示すために、異なる番号を割り当てている。ユーザは、キーボード162や、通常はマウス、トラックボール、あるいはタッチパッドと呼ばれるポインティングデバイス161などの入力デバイスを介してコンピュータ110にコマンドおよび情報を入力することができる。その他の入力デバイス(図示せず)は、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信用アンテナ、スキャナなどを含むことができる。これらおよびその他の入力デバイスは、システムバスに結合されているユーザ入力インターフェース160を介して処理装置120に接続される場合が多いが、パラレルポート、ゲームポート、またはUSB(universal serial bus)などのその他のインターフェース構造およびバス構造によって接続することもできる。またモニタ191やその他のタイプのディスプレイデバイスも、ビデオインターフェース190などのインターフェースを介してシステムバス121に接続される。コンピュータは、モニタに加えて、スピーカ197やプリンタ196などのその他の周辺出力デバイスを含むこともでき、これらは、周辺出力インターフェース195を介して接続することができる。
【0017】
コンピュータ110は、リモートコンピュータ180などの1つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境内で機能することができる。リモートコンピュータ180は、パーソナルコンピュータ、サーバ、ルータ、ネットワークPC、ピアデバイス、あるいはその他の一般的なネットワークノードとすることができ、図1にはメモリストレージデバイス181しか示されていないが、通常はコンピュータ110に関連する上述の要素の多くまたはすべてを含む。図1に示されている論理接続は、LAN(local area network)171およびWAN(wide area network)173を含むが、その他のネットワークを含むこともできる。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットにおいてよく見受けられる。
【0018】
LANネットワーキング環境において使用する場合には、コンピュータ110は、ネットワークインターフェースまたはアダプタ170を介してLAN171に接続される。WANネットワーキング環境において使用する場合には、コンピュータ110は通常、モデム172や、インターネットなどのWAN173上で通信を確立するためのその他の手段を含む。モデム172は、内蔵型または外付け型とすることができ、ユーザ入力インターフェース160やその他の適切なメカニズムを介してシステムバス121に接続することができる。ネットワーク化された環境においては、コンピュータ110に関連して示されているプログラムモジュール、またはその一部をリモートメモリストレージデバイス内に格納することができる。図1は、例としてリモートアプリケーションプログラム185をメモリデバイス181上に常駐するものとして示しているが、この形態には限定されない。示されているネットワーク接続は例示的なものであり、コンピュータどうしの間に通信リンクを確立するその他の手段も使用することができるということが理解できるであろう。
【0019】
(ソフトウェアプロビジョニングシステム)
図3は、コンピューティングデバイス202上でのオペレーティングシステムの使用を提供するための動的なソフトウェアプロビジョニングシステム200を示しており、ここでは、コンピューティングデバイス202は、デスクトップコンピュータ12、ラップトップコンピュータ22、PDA24、携帯電話、あるいは任意の類似のデバイスなど、一般に知られているコンピューティングデバイスのいずれにすることもできる。ソフトウェアプロビジョニングシステム200は、オペレーティングシステムの使用を提供するために実装されるものとして示されているが、ある代替実装形態においては、ソフトウェア、ファームウェア、コンピューティングデバイスの一機能など、その他のリソースの使用を提供するために使用することもできる。同様に、ソフトウェアプロビジョニングシステム200は、ネットワーク10に通信可能に接続されているコンピューティングデバイス202上でのリソースの使用を提供するものとして示されているが、ネットワーク10に接続できない、あるいはネットワーク10に一時的にしか接続できないコンピューティングデバイス上でのそのような使用を実装するために使用することもできる。
【0020】
ソフトウェアプロビジョニングシステム200は、コアプロビジョニングサービスモジュール206と、配信サービスモジュール208と、証明書サービスモジュール210と、コアデータベース212と、配信データベース214とを有するプロビジョニングサービスモジュール204を含むことができる。プロビジョニングシステム204は、課金アダプタ218を介して課金システム216と通信することができ、その一方でコアプロビジョニングサービスモジュール206は、データベースライタ(database writer)220を介して配信データベース214と通信することができ、配信データベース214は、データベースリーダ222を介して配信サービス208と通信する。コンピューティングデバイス202は、ローカルプロビジョニングモジュール(LPM)224を含むことができ、このLPM224は、配信ウェブサービスモジュール226を介して配信サービスモジュール208と通信し、課金ウェブサービスモジュール228を介して課金システム216と通信する。
【0021】
プロビジョニングサービスモジュール204は、サーバ30などのサーバシステム上や、ネットワーク10に通信可能に接続されているその他のシステム上に配置することができる。同様に、課金システム216も、サーバ30などのサーバシステム上や、ネットワーク10に通信可能に接続されているその他のシステム上に配置することができる。さらに、プロビジョニングサービスモジュール204のさまざまなコンポーネントのうちの1つまたは複数は、同一のサーバ上や、別々の場所に配置されている複数の異なるサーバ上に配置することができる。たとえばコアデータベース212は、別々の場所に配置されてそれぞれネットワーク10に通信可能に接続されている複数の異なるデータベースサーバ上に配置することができる。プロビジョニングサービスモジュール204およびそのさまざまなコンポーネントモジュールの機能については、以降でさらに詳しく説明する。
【0022】
さらに図3においては、コンピューティングデバイス202は、ウェブサービスモジュール226を介して配信サービスモジュール208と、およびウェブサービスモジュール228を介して課金システム216と通信するものとして示されている。状況によっては、ウェブサービスモジュール226は、望ましいレベルを超えるアクティビティーの増加を認識することができる。代替実施形態における負荷管理サービス230、コンピューティングデバイス202のユーザは、電話などの代替モードの通信を介して配信サービスモジュール208および課金システム216と通信することができる。たとえば、コンピューティングデバイス202にとってネットワーク10に接続することが不可能な状況においては、コンピューティングデバイス202のユーザは、配信サービスモジュール208に取り付けられている電話および音声認識対応型のユーザインターフェースを介して、あるいは配信サービスモジュール208と通信できる顧客サービス担当者などを介して通信することができる。
【0023】
コンピューティングデバイス202が、コンピュータ110などのコンピュータである場合には、LPM224は、システムメモリ130の一部として、処理装置120を含むコンピュータ110のさまざまなハードウェアコンポーネントの一部として、あるいはこれらの任意の組合せとして、固定式の不揮発性メモリ140上に配置することができる。LPM224の機能については、以降でさらに詳しく説明する。
【0024】
(プロビジョニングシステムのフローチャート)
次いで図4を参照すると、プロビジョニングプログラム250が、ソフトウェアプロビジョニングシステム200の一般的な機能を示している。ブロック251においては、コンピューティングデバイス202上でオペレーティングシステムを使用するための登録キーをユーザに提供することができる。オペレーティングシステムなどを使用するためのさらなる時間をユーザが購入した結果として、コンピューティングデバイス202の新たな購入に伴って登録キーをユーザに提供することができる。複数の異なるエンティティーが、登録キーをユーザに提供することができ、たとえば、コンピューティングデバイス202を販売しているコンピュータストアは、キーをユーザに提供することができ、コンピューティングデバイス202用のオペレーティングシステムの使用を含む一式のサービスを販売しているインターネットサービスプロバイダは、登録キーをユーザに提供することができる、といった具合である。
【0025】
登録キーは、以降でさらに詳しく説明するように、プロビジョニングサービスモジュール204によって証明書サービス210を用いて作成して、登録キーのプロバイダに安全な方法で送信することができる。あるいは、登録キーのプロバイダが、プロビジョニングサービスモジュール204と合意した方法で登録キーを作成することもできる。登録キーは、その登録キーを使用してコンピューティングデバイス202を識別するハードウェアやその他のコンポーネントに固有の情報を含むこともでき、あるいは含まなくてもよい。ソフトウェアプロビジョニングシステム200の一実装形態においては、それぞれの登録キーは、コンピューティングデバイス202のHWID(hardware identification)によって、コンピューティングデバイス202を一意に識別する。さらに別の実装形態においては、登録キーは、オペレーティングシステムのプロダクトキーなどの製造識別番号(production identification number)とすることができ、オペレーティングシステムの開発者や、そのオペレーティングシステムを使用するコンピューティングデバイスの製造業者など、プロビジョニングサービス以外のエンティティーによって作成することができる。この登録キーは、InitKey(Initialization key)とも呼ばれ、一連の英数字の形式、RFID(radio frequency identification)タグの形式、あるいはその他の任意の合意されたフォーマットとすることができる。
【0026】
登録キーをユーザに提供した後、ブロック252において、プロビジョニングプログラム250は、その登録キーをプロビジョニングサービスモジュール204に登録することが必要かどうかを判定することができる。InitKeyが、はじめにプロビジョニングサービスモジュール204によって作成されたものである場合には、そのInitKeyは、プロビジョニングサービスモジュール204のデータベース内に既に保存されている可能性があるため、そのInitKeyを登録することは必要でないかもしれない。あるいは、合意されたプロシージャーに基づいてサードパーティーのベンダがInitKeyを作成できるような方法でソフトウェアプロビジョニングシステム200がセットアップされている場合には、そのようなベンダは、そのInitKeyを、作成した際に、あるいは少なくともユーザへ提供した際に、登録する必要があるかもしれない。
【0027】
InitKeyを登録することが必要であると判定された場合には、ベンダは、ブロック254において、InitKeyをプロビジョニングサービスモジュール204に登録することができる。InitKeyの登録については、以降の図9においてさらに詳しく説明する。
【0028】
InitKeyの登録後、ブロック256において、プロビジョニングプログラム250は、コンピューティングデバイス202のためのプロビジョニングパケット(「パケット」とも呼ばれる)を作成する。コンピューティングデバイス202は、プロビジョニングパケットを使用して、指定された時間だけ、指定された期間だけ、あるいはその他の任意の合意された方法でユーザがオペレーティングシステムを使用できるようにすることができる。ある代替実装形態においては、プロビジョニングパケットを使用して、指定された期間だけソフトウェアやアプリケーションなどのその他の任意のリソースをユーザが使用できるようにすることができる。プロビジョニングサービスモジュール204によって作成されるプロビジョニングパケットは、そのパケットのユーザに関する情報や、そのパケットによって認められる使用量などを含むことができる。たとえばベンダが、コンピューティングデバイス202を、そのコンピューティングデバイス202上でのオペレーティングシステムの1カ月間の前払いの使用権と共に販売している場合には、ブロック256において、プロビジョニングサービスモジュール204は、コンピューティングデバイス202がそのオペレーティングシステムを1カ月間だけ使用できるようにするコンピューティングデバイス202用のプロビジョニングパケットを作成することができる。しかしプロビジョニングパケットは、コンピューティングデバイス202のみがその特定のプロビジョニングパケットを使用できるような方法で作成することができる。プロビジョニングパケットの作成については、以降の図10においてさらに詳しく説明する。
【0029】
ユーザが、コンピューティングデバイス202の電源をオンにすることによって、あるいはその他の任意の方法で、コンピューティングデバイス202上のオペレーティングシステムをアクティブ化しようと試みるとき、LPM224は、オペレーティングシステムのアクティブ化をコントロールすることができる。これは、プログラム250のブロック258によって示されている。そのユーザがこのオペレーティングシステムの使用を試みるのは、これが初めてであるとLPM224が検知した場合には、LPM224は、InitKeyを入力するようユーザに要求することができる。ある代替実装形態においては、LPM224は、コンピューティングデバイス202をスキャンして、コンピューティングデバイス202がInitKeyを既に投入されているかどうかを判定することができ、投入されている場合には、LPM224は、InitKeyをコンピューティングデバイス202から自動的に検索する。InitKeyをユーザから受け取った後、LPM224は、プロビジョニングサービスモジュール204と接続して、コンピューティングデバイス202のための証明書を要求することができ、この場合には、証明書を求める要求は、数ある情報の中でも、コンピューティングデバイス202のInitKeyおよびHWIDを含む。LPM224の設計およびオペレーションについては、以降で図7においてさらに詳しく説明する。
【0030】
証明書を求める要求に応答して、ブロック260において、プロビジョニングサービスモジュール204は、証明書サービスモジュール210から証明書を受け取ることができ、その証明書を、配信サービスモジュール208を介してコンピューティングデバイス202へ送信する。証明書サービスモジュール210から証明書を作成して、その証明書をクライアントデバイスへ送信するプロセスについては、以降で図10においてさらに詳しく説明する。
【0031】
プロビジョニングサービスモジュール204から証明書を受け取ると、ブロック262において、LPM224は、コンピューティングデバイス202上でオペレーティングシステムを使用するためにさらなるプロビジョニングパケットを入手することが必要かどうかを判定することができる。LPM224は、それまでコンピューティングデバイス202が使用された時間、現在の時間周期(current time period)、あるいは任意の類似のビジネスルールなどのビジネスルールに基づいて、プロビジョニングサービスモジュール204から受け取ったプロビジョニングパケットを消費することができる。以降でさらに説明するように、LPM224は、以前にプロビジョニングサービスモジュール204から受け取ったプロビジョニングパケットを含むローカルプロビジョニングパケットストレージモジュール(local provisioning packet storage module)を有することができる。LPM224は、そのようなローカルパケットストア(local packet store)から1つのプロビジョニングパケットを選択し、その中身を分析して、プロビジョニングサービスモジュール204にさらなるパケットを要求する必要があるかどうかを判定することができる。プロビジョニングパケットの選択、および選択されたプロビジョニングパケットの分析については、以降の図7においてさらに詳しく説明する。
【0032】
さらなるプロビジョニングパケットを要求することが必要であると判定された場合には、ブロック264において、LPM224は、さらなるプロビジョニングパケットを受け取るためにプロビジョニングサービスモジュール204へ要求を送信することができる。LPM224は、配信サービスモジュール208のウェブサービスモジュール226に接続することによって、プロビジョニングサービスモジュール204の顧客サービス担当者に連絡を取るようコンピューティングデバイス202のユーザに要求することによって、あるいはその他の任意の所望の方法を含む複数の異なる方法で、そのような要求をPSMへ送信することができる。プロビジョニングパケットを求める要求は、クライアントデバイス、そのクライアントデバイスによって使用されるオペレーティングシステムなどを識別する情報を含むことができる。
【0033】
プロビジョニングパケットを求める要求をコンピューティングデバイス202から受信すると、ブロック266において、プロビジョニングサービスモジュール204は、プロビジョニングパケットを作成して、LPM224へ配信することができる。LPM224に提供されるそれぞれのプロビジョニングパケットは、コンピューティングデバイス202、そのコンピューティングデバイス202によって使用されるオペレーティングシステム、パケットのタイプ、パケットのシーケンス番号、コンピューティングデバイス202がオペレーティングシステムを使用できる時間、あるいはオペレーティングシステムの使用期限が切れる日にちなどを識別するさまざまな情報を含むことができる。プロビジョニングパケット内の情報をLPM224が認証できるようにする電子署名を、そのプロビジョニングパケット内に含めることもできる。あるいは、別のセキュリティープロトコルのもとでは、プロビジョニングパケット内の情報をLPM224が認証できるようにする電子署名を、別途LPM224へ送信することもできる。プロビジョニングパケットの作成および配信については、以降の図12においてさらに詳しく説明する。
【0034】
プロビジョニングパケットを受け取ると、LPM224は、ブロック268において、そのプロビジョニングパケットを処理することができ、これについては、以降の図7においてさらに詳しく説明する。プロビジョニングパケットの中身を分析した後に、そのプロビジョニングパケットがコンピューティングデバイス202上でのオペレーティングシステムの使用を可能にすることができるとLPM224が判定した場合には、ブロック270において、コンピューティングデバイス202は、そのコンピューティングデバイス202上でオペレーティングシステムを起動することができる。
【0035】
(コアプロビジョニングシステム)
図5は、図3のコアプロビジョニングサービスモジュール206の詳細なブロック図を示している。コアプロビジョニングサービスモジュール206は、サーバ30、メインフレーム34、あるいはネットワーク10に通信可能に接続されているその他の任意の適切なデバイス上に実装することができる。コアプロビジョニングサービスモジュール206は、証明書サービスモジュール210、課金アダプタ218、コアDB212、および配信サービスモジュール208と通信することができる。コアプロビジョニングサービス206は、課金アダプタと通信する課金インターフェース280と、証明書サービスモジュール210と通信するための証明書サービスインターフェース282と、配信サービスモジュール208と通信するための配信サービスインターフェース288と、アカウント更新モジュール284と、パケットジェネレータ(packet generator)286と、コアデータベース212および配信データベース214と通信するデータアクセスモジュール290とを含むことができる。
【0036】
課金インターフェース280は、ウェブインターフェース、課金アダプタ218へのVPN、あるいは当業者によく知られているその他の任意の所望の方法を使用して実装することができる。ある特定の実装形態においては、課金インターフェース280は、MSMQ(Microsoft message queue)(商標)インターフェースを使用して実装することができる。あるいは、EAI(enterprise application interface)プロトコルを使用して設計されているMicrosoft Biztalk(商標)など、別の業界プロトコル(industry protocol)を使用して設計されているインターフェースを使用して、課金インターフェース280を実装することもできる。MSMQ(商標)テクノロジーを使用して、配信サービスインターフェース288およびデータアクセスモジュール290を実装することもできる。
【0037】
課金インターフェースモジュール280は、コンピューティングデバイスのためのInitKeyの登録を求める要求を課金アダプタ218から受け取り、アカウント更新と通信して、アカウント更新情報を提供し、さまざまなコンピューティングデバイスをブートストラップし、コンピューティングデバイスのためのクライアント証明書を証明書サービスモジュール210に要求することなどができる。
【0038】
アカウント更新モジュール284は、コンピューティングデバイス202のためのアカウントの作成、保持、および更新を担当することができる。アカウント更新モジュール284は、コンピューティングデバイス202のためのアカウントのセットアップおよび更新に関する課金アダプタ218からの情報を受信することができ、またパケットジェネレータ286と通信して、コンピューティングデバイス202のためのプロビジョニングパケットを作成および保存することができる。たとえば、引受会社(underwriter)、電気通信業者等は、コンピューティングデバイス202上でのオペレーティングシステムの一定の使用時間を販売し、課金アダプタ218を使用して、コンピューティングデバイス202のアカウントをしかるべく更新するためのアカウント更新要求をコアプロビジョニングサービス206へ送信することができる。課金アダプタ218からのアカウント更新要求を受信すると、アカウント更新モジュール284は、データアクセスモジュール290を使用してコアデータベース212への必要な入力を行い、パケットジェネレータと通信して、必要なプロビジョニングパケットを作成することができる。別の場合には、配信サービスモジュール208が、コンピューティングデバイス202のためのプロビジョニングパケットを購入したいというコンピューティングデバイス202からの要求を受け取ることができる。
【0039】
一方、コンピューティングデバイス202が、証明書を求める、またはプロビジョニングパケットを求める要求をコアプロビジョニングサービス206へ送信すると、アカウント更新モジュール284は、コアデータベース212からプロビジョニングパケットを検索し、コンピューティングデバイス202のためのアカウント情報を更新し、配信サービスモジュール208と通信して、そのプロビジョニングパケットをコンピューティングデバイス202へ送信することができる。
【0040】
コアプロビジョニングサービス206は、証明書を求める、またはプロビジョニングパケットを求める要求をコンピューティングデバイス202から受信すると、証明書サービスインターフェース282を使用して証明書サービスモジュール210と通信して、証明書を受け取ることや、証明書を確認することができる。証明書サービスモジュール210は、暗号化された証明書の作成および管理を可能にする標準的な証明書技術のうちのいずれかを使用して実装することができる。たとえば、証明書サービスモジュール210は、PKI(public key infrastructure)に準拠する認証局を使用して実装することができる。証明書サービスモジュール210は、キーマネージャー292を含むことができ、このキーマネージャー292は、暗号化された非対称的なツインキー(asymmetrical twin keys)の作成や、キーの購入者(key subscriber)の識別および認証などを担当する。証明書サービスモジュール210は、証明書ジェネレータ(certificate generator)を含むこともでき、この証明書ジェネレータは、デジタル証明書を用いて、そのような証明書の発行、保持、管理、取り消し、一時停止、復活、および更新のために、ならびに公開キーリポジトリ(public key repository)の作成および管理のために、公開キーをクライアントアカウントに結び付ける。クライアントのための証明書の作成および管理については、以降の図11においてさらに詳しく説明する。
【0041】
証明書サービスインターフェース282は、パケットジェネレータ286によって作成されたプロビジョニングパケットがコンピューティングデバイス202へ送信される前に、証明書サービスモジュール210によって作成された証明書を使用することによって、そのプロビジョニングパケットに署名することができる。証明書サービスインターフェース282は、パケット要求などのクライアント署名を確認するために証明書サービスモジュール210と通信することもできる。
【0042】
コアプロビジョニングサービス206は、プロビジョニングパケット、およびクライアントデバイス証明書などのその他のクライアントデバイスのブートストラップ関連情報(other client device bootstrapping information)を配信データベース214内に発行することを担当することができる。配信サービスモジュール208には、配信データベース214から情報を読み取ることを認めることができるが、アカウント情報の整合性を維持するために、配信サービスモジュール208には、一般に配信データベース214内への発行を行うことは認められないという点に留意されたい。
【0043】
コアプロビジョニングサービス206内のさまざまなモジュールは、上述のさまざまなタスクを実行する別々のモジュールとして示されているが、この描写は、例示のみを目的としたものであり、実際には、これらの別々のモジュールのすべてを別々の方法で実装することができ、それによって、これらのモジュールのうちの1つまたは複数が結合されたり、これらのモジュールのすべてが別々の方法でお互いに対話することができたり、といった具合になるという点を理解されたい。
【0044】
(コアデータベーススキーマ)
図6は、コアデータベース212の実装のために使用できるコアデータベーススキーマ310を示している。コアデータベーススキーマ310は、ブートストラップテーブル312、コンピューティングデバイステーブル314、ジョブテーブル316、パケットテーブル318、構成テーブル320、コンピューティングデバイスログテーブル322、タイプテーブル324、ジョブログテーブル326、およびステータステーブル328を含むことができる。コアデータベーススキーマ310は、よく知られているリレーショナルデータベースソフトウェアのうちのいずれかを使用して実装することができ、コアデータベーススキーマ310のさまざまなテーブルは、単一のデータベースサーバ上に、あるいはネットワーク10などのネットワークを介して相互に接続されている別々のデータベースサーバ上に格納することができる。
【0045】
ブートストラップテーブル312は、ソフトウェアプロビジョニングシステム200を使用して提供することができるコンピューティングデバイス202などのコンピューティングデバイスのためのブートストラップデータを保存することができ、そのようなデータは、引受会社から課金アダプタ218を介して受信される。ブートストラップテーブル312内のそれぞれのレコードは、レコードIDフィールドと、コンピューティングデバイス用のIDと、コンピューティングデバイスのユーザに提供されたInitKeyと、パケットがコンピューティングデバイスに配信された回数を識別する配信回数と、コンピューティングデバイスのブートストラップステータスとを含む情報を含むことができる。
【0046】
コンピューティングデバイステーブル314は、ソフトウェアプロビジョニングシステム200を使用して提供することができるコンピューティングデバイス202などのコンピューティングデバイスに関連したデータを保存することができる。コンピューティングデバイステーブル314は、コンピューティングデバイスへ送信される登録パケットやプロビジョニングパケットに追加されるコンピューティングデバイスに関連したさまざまなデータを保存することができる。コンピューティングデバイステーブル314は、コンピューティングデバイスを識別して、そのコンピューティングデバイスのステータスを追跡把握するために使用することができる。コンピューティングデバイステーブル314内のそれぞれのレコードは、レコードIDフィールド、コンピューティングデバイスのハードウェア構成を指定するハードウェアID、コンピューティングデバイスへ送信された前回のプロビジョニングパケットのシーケンス番号を表す直近のシーケンス番号などを含む情報を含むことができる。
【0047】
ジョブテーブル316は、プロビジョニングサービスモジュール204へのさまざまなプロビジョニング要求(provisioning request)に基づいて作成できるデータを保存し、それぞれのプロビジョニング要求は、ジョブテーブル316内に新たなレコードを作成する。ジョブテーブル316内のレコードは、さまざまなプロビジョニング要求のプロビジョニングジョブステータス(provisioning job status)を追跡把握するために使用することができる。ジョブテーブル316内のそれぞれのレコードは、レコードIDフィールド、コンピューティングデバイスID、ジョブタイプID、ジョブトラッキングID、プロビジョニング要求のためのトークン、プロビジョニング要求を行っているコンピューティングデバイスのためのアカウントID、プロビジョニング要求の日付および時間、プロビジョニング要求の処理のステータスなどを含む情報を含む。
【0048】
パケットテーブル318は、ジョブデータに基づいて作成できるパケットデータを保存し、この場合には、1つのジョブが、1つまたは複数のパケットを作成することができる。パケットテーブルは、配信サービスモジュール208から、または課金アダプタ218から受信されるプロビジョニング要求に応答して作成されるさまざまなプロビジョニングパケットの配信ステータスを追跡把握するために使用される。パケットテーブル内のそれぞれのレコードは、レコードID、パケットが作成されるようにするジョブを表すジョブID、パケット内に含まれているさまざまなデータ、特定のコンピューティングデバイスから最後のパケットダウンロード確認応答を受信してからその特定のコンピューティングデバイスにパケットが何回配信されたかを示す配信回数、およびパケットの処理の段階を示すステータスに関する情報を含むことができる。
【0049】
構成テーブル320は、コアデータベース212を実装するために使用されているサーバについて記述するサーバ構成データの名前−値のペア(name−value pair)のすべてを表すデータを保存することができる。構成テーブル320内のそれぞれのレコードは、サーバのネームスペースや、サーバの名前−値のペアの名前および設定に関する情報を含むことができる。
【0050】
コンピューティングデバイスログテーブル322は、コンピューティングデバイスに関連した(そのコンピューティングデバイスに関連したジョブ以外の)さまざまなアクティビティーを記録することができる。コンピューティングデバイスログテーブル322内のそれぞれのレコードは、レコードID、コンピューティングデバイスID、コンピューティングデバイスのタイプ、コンピューティングデバイスについて記述するデータ、およびコンピューティングデバイスがプロビジョニングサービスモジュール204を用いてログインされた時間に関する情報を含むことができる。たとえばコンピューティングデバイスのタイプは、ブートストラップレコードが作成済みのタイプ、ブートストラップが進行中のタイプ、ブートストラップが完了したタイプ、(指定された数を超える証明書がコンピューティングデバイスへ配信され、そのコンピューティングデバイスから確認応答が受信されていないことを示す)ブートストラップが制限を超えたタイプ、証明書が要求されたタイプ、パケットが要求されたタイプなどのうちのいずれか1つとすることができる。
【0051】
タイプテーブル324は、ジョブテーブル316、コンピューティングデバイスログテーブル322、およびジョブログテーブル326によって使用されるさまざまな列挙可能な(enumerable)タイプを事前に定義するために使用することができる。
【0052】
ジョブログテーブル326は、ジョブやパケットに関連するさまざまなアクティビティーを記録するために使用することができ、この場合には、それぞれのレコードは、レコードID、ジョブID、ジョブのタイプ、ジョブの説明、ジョブが記録された時間などを含む情報を含むことができる。
【0053】
ステータステーブル328は、ブートストラップテーブル312、コンピューティングデバイステーブル314、ジョブテーブル316、およびパケットテーブル318内で使用されるさまざまな列挙可能なステータスを事前に定義するために使用することができる。
【0054】
(配信データベーススキーマ)
図7は、配信データベース214の実装のために使用できる配信データベーススキーマ340を示している。配信データベーススキーマ340は、配信ブートストラップテーブル342および配信パケットテーブル344を含むことができる。配信データベーススキーマ340は、よく知られているリレーショナルデータベースソフトウェアのうちのいずれかを使用して実装することができ、配信データベーススキーマ340のさまざまなテーブルは、単一のデータベースサーバ上に、あるいはネットワーク10などのネットワークを介して相互に接続されている別々のデータベースサーバ上に格納することができる。
【0055】
配信ブートストラップテーブル342は、コンピューティングデバイスの登録中にコアプロビジョニングサービス206によって発行されるブートストラップデータを保存することができる。配信ブートストラップテーブル342のそれぞれのレコードは、レコードIDと、特定のコンピューティングデバイスに関連したInitKeyと、その特定のコンピューティングデバイスのハードウェアIDとを含む情報を含むことができ、配信ブートストラップテーブル342内のレコードは、その特定のコンピューティングデバイスのためのブートストラップが完了したときに、コアプロビジョニングサービス206によって削除することができる。
【0056】
配信パケットテーブル344は、コアプロビジョニングサービス206によって作成されたパケットを保存することができる。配信パケットテーブル344のそれぞれのレコードは、特定のパケットに対応することができ、レコードIDと、その特定のパケットを使用することになるコンピューティングデバイスについて記述するハードウェアIDと、その特定のパケットのパケットシーケンス番号と、その特定のパケットの中身と、確認応答が受信されない状態でその特定のパケットがクライアントデバイスへ何回送信されたかを指定する配信回数と、配信サービスモジュール208がその特定のパケットをクライアントデバイスへ配信しようと試みることができる回数を指定する最大配信回数とを含む情報を含む。特定のパケットが、クライアントコンピューティングデバイスによって首尾よくダウンロードされると、その特定のパケットに関連したレコードを配信パケットテーブル344から削除することができる。また、特定のパケットの配信回数が最大配信回数を超えた場合には、その特定のパケットに関連したレコードを配信パケットテーブル344から削除することもできる。
【0057】
(ローカルプロビジョニングモジュール)
図8は、LPM224のさらに詳細なブロック図を示している。LPM224は、コンピューティングデバイス202などのコンピューティングデバイス上に常駐しているソフトウェアプロビジョニングシステム200のクライアントサイドのコンポーネントである。LPM224は、ソフトウェアプロビジョニングシステム200によって提供されるサービスを使用してコンピューティングデバイスのユーザと対話することや、ネットワーク10を介して配信サービスモジュール208と対話することなどを含むさまざまな機能を実行することができる。
【0058】
LPM224は、クライアントコンピューティングデバイス202によって使用される特定のログインプログラムと対話することによって、クライアントコンピューティングデバイス202上での特定の状態を強制する機能を実行することができる。クライアントデバイスが、ログインロジックとしてWPA(Windows(登録商標) product activation)システムを使用している特定の実装形態においては、LPM224は、WPAと対話して、クライアントコンピューティングデバイス202上での特定の状態を強制することができる。しかし、ある代替実装形態においては、LPM224は、その他の任意の適切なオペレーティングシステムログインプログラムと対話することができる。LPM224の実装形態は、ソフトウェア内に実装され、かつWPAによって使用されるログインプログラムへとリンクされるライブラリとして構成されているさまざまな論理コンポーネントをグループ化したものとして、図8に記載されている。しかし、LPM224の代替実装形態においては、LPM224のさまざまな論理コンポーネントのうちの1つまたは複数をハードウェア内に実装することができる。
【0059】
具体的には、LPM224は、特定の状態で機能することをコンピューティングデバイス202に強制するための強制アドオンモジュール(enforcement add−on module)352と、ソフトウェアプロビジョニングシステム200によって提供されるリソースの使用状況を測定するための測定モジュール(metering module)354と、コアプロビジョニングサービス206によって提供されるプロビジョニングパケットを使用して処理を行うためのトランザクションエンジン356と、プロビジョニングパケット用の安全なストレージを提供するためのセキュアストレージマネージャー(secure storage manager)358と、コアプロビジョニングサービス206と通信するための通信モジュール360と、ユーザと対話するためのユーザ経験モジュール(user experience module)362とを含むことができる。
【0060】
強制アドオンモジュール352は、コンピューティングデバイス202のログインロジック364内に挿入することができる。ユーザが、ログインロジック364を使用してコンピューティングデバイス202にログオンしたときに、ログインロジック364内の強制アドオンモジュール352は、プロビジョニングパケットの残量情報を求めて測定モジュール354にクエリーを行うことができる。強制アドオンモジュール352は、コンピューティングデバイス202が十分なプロビジョニングパケットを有していると判定した場合には、ログインロジック364がその通常のルーチン内で機能できるようにすることができ、またユーザがコンピューティングデバイス202にログオンできるようにすることができる。しかし、強制アドオンモジュール352は、コンピューティングデバイス202が十分なプロビジョニングパケットを有していないと判定した場合には、非アクティブな状態に入るようコンピューティングデバイス202に強制する。そのような非アクティブな状態においては、コンピューティングデバイス202を起動するのにちょうど必要なだけの限られたユーザインターフェースが、コンピューティングデバイス202のユーザに提供される。
【0061】
測定モジュール354は、残量マネージャー(balance manager)366を含むことができ、この残量マネージャー366は、提供されたリソースを使用するために利用可能な現在の残量を読み取って確認し、現在の残量を更新し、プロビジョニングパケットを処理する。測定モジュール354は、構成マネージャー368と、常に増進するタイマを維持するためのリライアブルクロックマネージャー(reliable clock manager)370とを含むこともできる。リライアブルクロックマネージャー370は、常に増進するタイマを維持するという課題を達成するために、リライアブルハードウェアクロック(reliable hardware clock)372を使用することができる。残量マネージャー366およびリライアブルクロックマネージャー370は、LPM224の安全なオペレーションにとって非常に敏感かつ重要であり、したがって、LPM224のオペレーション中にさまざまなセキュリティー上の攻撃にさらされる可能性が高い。
【0062】
強制アドオンモジュール352および測定モジュール354は、コンピューティングデバイス202上で提供されたリソースのアクティブ化および非アクティブ化を実施するために連携することができる。強制アドオンモジュール352は、特定のイベントに基づいて残量マネージャー366を呼び出すログインロジック364内のイベントディスパッチャーとして機能することができ、その一方で、残量マネージャー366は、イベントに応答して呼び出された際にどのアクションを取るべきかを判断することができる。強制アドオンモジュール352に残量マネージャー366をアクティブ化させることができるさまざまなイベントの例は、(1)ログオンイベント、(2)システムアンロックイベント、(3)ハイバネーションイベントからの復旧、(4)スタンバイイベントからの起動、(5)ユーザによってトリガーされたイベント、(6)ログオフイベント、(7)パケットのダウンロード、(8)タイマチック(timer tick)、(10)システムロックイベント、(11)スクリーンセーバの始動イベント、(12)スクリーンセーバの停止イベントなどである。残量マネージャー366は、そのイベントを入力として受け取り、結果としてのアクションを強制アドオンモジュール352に返すことができる。
【0063】
たとえば、ユーザがログオンしているときに、強制アドオンモジュール352は、ユーザログオンイベントを残量マネージャー366へ送信することができる。そのユーザログオンイベントに応答して、残量マネージャー366は、提供されたリソースを使用するために利用可能な現在の残量を問い合わせることができ、残量が十分である場合には、残量マネージャー366は、ログオンアクションを強制アドオンモジュール352に返すことができる。しかし、残量が十分でない場合には、強制アドオンモジュール352は、ログインロジック364に通知ユーザインターフェース(UI)398を返させることができ、この場合には、この通知UIによって、ユーザは、プロビジョニングサービスモジュール204からさらなるプロビジョニングパケットを購入することによって残量を増やし、したがってコンピューティングデバイス202をアクティブ化することができる。
【0064】
トランザクションエンジン356は、残量マネージャー366内の残量およびパケット消費カウンタを更新するためにプロビジョニングパケットを処理することができる。トランザクションエンジン356は、残量を更新するために、いかなるプロビジョニングパケットも必ず1回だけ消費されるようにすることができる。トランザクションエンジン356は、残量およびパケット消費カウンタを一緒に更新するように、したがって、残量およびパケット消費カウンタの双方が更新されるか、または残量およびパケット消費カウンタのどちらも更新されないかのいずれかになるように設計することができる。あるいは、トランザクションエンジン356は、何らかの予期せぬイベントによって残量データが駄目になることのないように残量データの一貫性を維持するために使用することもできる。トランザクションエンジン356の機能の一例を以降で提供する。
【0065】
この例では、ユーザが、提供されたリソースのための使用時間を購入するために2枚のプリペイドカードを使用し、第1のカードは10時間用で、第2のカードは20時間用であると仮定する。プロビジョニングサービスモジュール204は、合計の残量を保持していないため、10時間用および20時間用という2つの別々のセットのライセンス情報が、プロビジョニングサービスモジュール204において作成される。ユーザが、プロビジョニングサービスモジュール204に連絡を取って、プロビジョニングパケットをコンピューティングデバイス202上にダウンロードする場合には、コンピューティングデバイス202上にダウンロードされるプロビジョニングパケットのそれぞれは、一意のプロビジョニングパケット番号を有する。トランザクションエンジン356は、第1のパケットを処理する際に、パケット消費カウンタを進めて、残量を10時間増やし、次いで第2のパケットを処理する際に、再びパケット消費カウンタを進めて、残量をさらに20時間増やす。
【0066】
セキュアードストレージマネージャー(secured storage manager)358は、残量データをユーザが改ざんできないように、および残量データにLPM224のみがアクセスできるように、保護された方法でLPM224が残量データを保存できるようにすることができる。プロビジョニングパケットは、LPM224によってダウンロードされた後、セキュアードストレージマネージャー358内に保存することができる。同様に、残量カウンタおよびパケット消費カウンタも、セキュアードストレージマネージャー358内に保存することができる。図示されている実装形態においては、セキュアードストレージマネージャー358は、dll(dynamic link library)として実装され、それによって、ユーザ経験モジュール362は、セキュアードストレージマネージャー358にアクセスすることができる。
【0067】
セキュアードストレージマネージャー358内に保存されているデータの安全を確保するために、データ暗号化キーを使用して、データをセキュアードストレージマネージャー358内に保存することができ、データ暗号化キーを有するモジュールのみが、セキュアードストレージマネージャー358からデータを読み取ることができる。セキュアードストレージマネージャー358は、LSAデータベース376と通信するためのローカルセキュリティーオーソリティー(LSA)サブシステム(local security authority (LSA) subsystem)374、セキュアハードウェアストレージ(secure hardware storage)380と通信するためのストレージドライバ378、およびコンピューティングデバイス202上のファイル384と通信するためのファイルシステムドライバ382と通信することができる。さらなるセキュリティーのために、セキュアードストレージマネージャー358の代替実装形態は、セキュアードストレージマネージャー358内に保存されているデータの複数のコピーを使用することもでき、それによって、それぞれのコピーを相互参照して、データのどの単一のコピーにも改ざんがまったくないようにすることができる。ここで論じているLPM224の実装形態では、セキュアードストレージマネージャー358はソフトウェア内に実装されているが、ある代替実装形態においては、セキュアードストレージマネージャー358をハードウェア内に実装することもできる。
【0068】
通信モジュール360は、プロビジョニングパケットおよび/または証明書をプロビジョニングサービスモジュール204に要求するためのパケット/証明書要求マネージャー386と、さらなるプロビジョニングパケットを課金システム216から、および/またはプロビジョニングサービスモジュール204から購入するための購入マネージャー388と、LPM224がネットワーク10と通信できるようにするウェブサービス通信マネージャー390とを含むことができる。
【0069】
パケット/証明書要求マネージャー386は、ユーザ経験モジュール362からの要求を受信して、パケットまたは証明書をプロビジョニングサービスモジュール204に要求することができる。たとえば、ユーザがInitKeyをUIに入力することによってクライアントデバイスに初めてログオンしている場合には、ユーザ経験モジュール362は、そのInitKeyをパケット/証明書要求マネージャー386に渡すことができ、パケット/証明書要求マネージャー386は、プロビジョニングサービスモジュール204と通信して、プロビジョニングサービスモジュール204から証明書を受け取ることができる。パケット/証明書要求マネージャー386は、証明書またはプロビジョニングパケットが首尾よくダウンロードされたらプロビジョニングサービスモジュール204に確認応答を行うことを担当することもできる。パケット/証明書要求マネージャー386は、プロビジョニングプロトコルを使用して、プロビジョニングサービスモジュール204と通信することができる。パケット/証明書要求マネージャー386によってダウンロードされたパケットは、セキュアードストレージマネージャー358内に保存することができる。
【0070】
購入マネージャー388は、コンピューティングデバイス202のユーザから支払情報を受信して、その支払情報を課金システム216へ、またはプロビジョニングサービスモジュール204へ伝達することによって、そのユーザがさらなるプロビジョニングパケットを購入できるようにすることができる。パケット/証明書要求マネージャー386および購入マネージャー388の双方は、ウェブサービス通信マネージャー390を使用して、ネットワーク10と通信することができる。ウェブサービス通信マネージャーは、ネットワークサービスマネージャー392およびネットワークインターフェースカード(NIC)394を使用して、ネットワーク10と通信することができる。この実装形態においては、ネットワーク10と通信するために、ウェブサービス通信マネージャー390が使用されているが、代替実装形態においては、ネットワーク10と通信するために、FTP(file transfer protocol)ドライバなどのその他の通信ツールを使用することができるという点に留意されたい。
【0071】
ユーザ経験モジュール362は、パケット/証明書要求マネージャー386がプロビジョニングサービスモジュール204から証明書をダウンロードできるようにするInitKeyを入力するようユーザに要求するためのアクティブ化ユーザインターフェース(UI)396と、LPM224がユーザと対話できるようにする通知UI398とを含むことができる。たとえばユーザが、提供されたリソースを使用するためのプリペイドカードを購入している場合には、アクティブ化UI396は、そのプリペイドカードによって提供される番号を入力するようユーザに要求し、パケット/証明書要求マネージャー386を呼び出して、そのプリペイドカード番号に対応する最新のプロビジョニングパケットをダウンロードすることができる。アクティブ化UI396は、購入マネージャー388を呼び出して、ユーザがさらなるプロビジョニングパケットを購入できるようにすることもでき、また購入の完了時にパケット/証明書要求マネージャー386を自動的に呼び出して、その購入に対応するプロビジョニングパケットをダウンロードできるように設計することができる。
【0072】
通知UI398は、ユーザが現在の残量情報や使用履歴などを問い合わせることができるようにするさまざまなユーザインターフェースを含むことができる。通知UI398は、ユーザによって、またはログインロジック364によって呼び出すことができる。提供されたリソースを使用するために利用可能な残量が少ない状況では、ログインロジック364は、通知UI398を呼び出して、さらなる購入が必要であることをユーザに知らせることができる。通知UIは、絶え間なくアクティブであることができ、タスクバーアイコン、コントロールパネルアプレット、バルーンポップアップ(balloon pop−up)を介して、またはその他の任意の一般に知られているUIの方法を使用することによって、通知サービスをユーザに提供することができる。
【0073】
ソフトウェアプロビジョニングシステム200のさまざまなコンポーネントについて説明したが、以降の図9〜図12では、ソフトウェアプロビジョニングシステム200のオペレーションについてさらに詳しく説明する。
【0074】
(InitKeyの登録)
図9は、InitKeyをコアプロビジョニングサービス206に登録するために使用できる登録プログラム430のフローチャートを示している。ブロック432において、InitKeyのプロバイダは、InitKey登録要求をコアプロビジョニングサービス206へ送信する。前述のように、このプロバイダは、コンピューティングデバイス202のベンダ、コンピューティングデバイス202のオペレーティングシステム用の使用権のベンダ、ソフトウェアプロビジョニングシステム200の顧客サービス担当者(CSR、customer service representative)など、サードパーティーによって管理できる課金システム216とすることができる。
【0075】
InitKey登録要求は、コアプロビジョニングサービス206のメッセージ待ち行列内で受信することができる。コアプロビジョニングサービス206は、そのメッセージ待ち行列内でInitKey登録要求を認識すると、ブロック434において、登録プロセスを開始することができる。
【0076】
ブロック436においては、InitKeyをコアデータベース212のブートストラップテーブル312に追加することができ、登録プログラム430は、ブートストラップステータスを「Created」に設定することができる。
【0077】
その後、ブロック438において、コアプロビジョニングサービス206は、「Bootstrap Created」のメッセージをコンピューティングデバイスログテーブル322内に記録することができる。
【0078】
最後に、ブロック440において、コアプロビジョニングサービス206は、「Bootstrap Publish」のメッセージを配信データベース214のメッセージ待ち行列へ送信することができる。
【0079】
(パケットの作成)
図10は、コンピューティングデバイス202のLPM224によって使用されるプロビジョニングパケットを作成するために使用できるパケット作成プログラム450のフローチャートを示している。
【0080】
ブロック452において、課金アダプタ218は、プロビジョニングパケットを求めるプロビジョニング要求メッセージをコアプロビジョニングサービス206へ送信することができる。コアプロビジョニングサービス206は、複数の引受会社に接続することができるため、このようなプロビジョニング要求メッセージは、課金アダプタ218をコアプロビジョニングサービス206へ接続するMSMQインターフェース内で待ち行列に入れられる。
【0081】
プロビジョニング要求メッセージを課金アダプタ218から検索すると、ブロック454において、コアプロビジョニングサービス206は、パケット作成トランザクションを開始することができる。
【0082】
ブロック456において、コアプロビジョニングサービス206は、プロビジョニング要求メッセージからのハードウェアIDを使用して、新たなコンピューティングデバイスレコードをコンピューティングデバイステーブル314に追加することができる。しかし、そのハードウェアIDを含むレコードが、コンピューティングデバイステーブル314内に既に存在する場合には、新たなコンピューティングデバイスレコードを追加することは必要でないかもしれない。
【0083】
その後、ブロック458において、コアプロビジョニングサービス206は、新たなジョブレコードをジョブテーブル316に追加して、プロビジョニングパケットを求める新たなジョブ要求を記録することができる。コアプロビジョニングサービス206は、新たに追加されたジョブレコードのステータスを「Created」に設定することができる。ブロック460において、コアプロビジョニングサービス206は、プロビジョニング要求メッセージの日付および時間と共に、新たなレコードをジョブログテーブル326内に追加することができる。
【0084】
ブロック462において、コアプロビジョニングサービス206は、プロビジョニング要求メッセージに基づいてプロビジョニングパケットを作成することができる。パケットの作成は、プロビジョニング要求メッセージ内で提供される証明書を確認すること、プロビジョニングパケットの使用時間の量を追加することなどを含むことができる。
【0085】
ブロック464において、コアプロビジョニングサービス206は、キーマネージャー292と通信して、安全なキーを用いてプロビジョニングパケットに署名し、XMLベースのプロビジョニングパケットを作成することができる。
【0086】
プロビジョニングパケットが作成されると、ブロック466において、コアプロビジョニングサービス206は、コンピューティングデバイステーブル314内の最後のシーケンス番号を1つ増やすことができる。
【0087】
ブロック468において、コアプロビジョニングサービス206は、新たに作成されたプロビジョニングパケットをパケットテーブル318内に挿入し、パケットテーブル318内のプロビジョニングパケットのステータスを「packet created」に設定することができる。
【0088】
その後、ブロック370において、コアプロビジョニングサービス206は、「packet created」のメッセージをジョブログテーブル326内に記録することができる。そして最後に、ブロック372において、コアプロビジョニングサービス206は、「packet publish」のメッセージを配信データベースライタ220へのメッセージ待ち行列内に送信して、そのパケットを配信データベース214内に追加することができる。
【0089】
(ブートストラッピング)
図11は、証明書を証明書サービスモジュール210に要求して、その証明書をコンピューティングデバイス202へ送信するために使用できるブートストラッピングプログラム500のフローチャートを示している。
【0090】
ブロック502において、配信サービスモジュール208は、コンピューティングデバイス202などのコンピューティングデバイスからの証明書要求を受信することができる。この証明書要求は、パケット/証明書要求マネージャー386によって作成し、InitKeyなどのコンピューティングデバイス202用のハードウェアIDを含む情報を含むことができる。
【0091】
ブロック504において、コアプロビジョニングサービス206は、ブートストラップテーブル312内でInitKeyを探すことができる。ブロック506において、コアプロビジョニングサービス206は、コンピューティングデバイステーブル314をチェックして、証明書要求内で提供されているハードウェアIDに関するレコードが含まれているかどうかを確認することができる。コンピューティングデバイステーブル314内に何のレコードも存在しない場合には、コアプロビジョニングサービス206は、レコードをコンピューティングデバイステーブル314内に追加することができる。
【0092】
ブロック508において、コアプロビジョニングサービス206は、「computing device created」のメッセージをコンピューティングデバイスログテーブル322内に記録することができる。その後、ブロック510において、コアプロビジョニングサービス206は、証明書要求トランザクションの処理を開始することができる。
【0093】
ブロック512において、コアプロビジョニングサービス206は、ブートストラップテーブル312をチェックして、配信回数が、構成テーブル320によって指定された最大配信回数よりも多いかどうかを確認することができ、そうである場合には、コントロールをブロック524に移すことができる。
【0094】
配信回数が最大配信回数よりも多くない場合には、ブロック514において、コアプロビジョニングサービス206は、ブートストラップテーブル312内のブートストラップステータスをチェックすることができる。ブートストラップステータスが、「created」または「In Progress」に相当しない場合には、コントロールをブロック524に移すことができる。
【0095】
しかしブートストラップステータスが、「created」または「In Progress」のいずれかに相当する場合には、ブロック516において、コアプロビジョニングサービス206は、ブートストラップテーブル312内のブートストラップステータスを「In Progress」に更新することができる。
【0096】
その後、ブロック518において、コアプロビジョニングサービス206は、「bootstrap in progress」のメッセージをコンピューティングデバイスログテーブル322内に記録することができる。
【0097】
ブロック520において、コアプロビジョニングサービス206は、証明書ユーティリティーを呼び出して、新たなクライアント証明書を作成することができる。新たな証明書を証明書ユーティリティーから受け取ると、ブロック522において、コアプロビジョニングサービス206は、そのクライアント証明書を配信サービスモジュール208のメッセージ待ち行列内に送信することができ、コントロールをブロック530に移すことができる。
【0098】
ブロック524において、コアプロビジョニングサービス206は、ブートストラップテーブル内の配信回数が最大配信回数を超えたことによって、ブートストラップテーブル312内のブートストラップステータスを「over limit」に更新することができる。この「over limit」のステータスは、コアプロビジョニングサービス206が、コンピューティングデバイス202のための証明書を発行したことに応答してLPM224から適切な確認応答を受信していないということを意味する。したがって、ブロック526において、コアプロビジョニングサービス206は、証明書を要求しているコンピューティングデバイスから確認応答がまったく受信されていないということを示す「bootstrap over limit」のメッセージをコンピューティングデバイスログテーブル322内に記録することができる。
【0099】
ブロック528において、コアプロビジョニングサービス206は、「remove bootstrap」のメッセージを配信データベースライタ220のメッセージ待ち行列内に送信して、ブートストラップレコードを配信データベース214から削除することができる。
【0100】
ブロック530は、証明書がクライアントへ送信されると、ブロック522からコントロールを受け取ることができ、したがって、証明書要求の処理の終了を表している。
【0101】
証明書要求が処理されると、ブロック532において、コアプロビジョニングサービス206は、配信サービスモジュール208のメッセージ待ち行列内の証明書ダウンロード完了メッセージを受信することができる。このような証明書ダウンロード完了メッセージは、証明書が首尾よくダウンロードされた後に、LPM224のパケット/証明書要求マネージャー386によって送信することができる。
【0102】
証明書ダウンロード完了メッセージを受信すると、ブロック534において、コアプロビジョニングサービス206は、ブートストラップ完了トランザクション(bootstrap completed transaction)を開始することができる。ブロック536において、コアプロビジョニングサービス206は、ブートストラップテーブル312内のブートストラップステータスを「completed」に更新することができる。その後、ブロック538において、コアプロビジョニングサービス206は、証明書要求を送信しているコンピューティングデバイスのためのブートストラッププロセスが完了したということを示す「bootstrap completed」のメッセージをコンピューティングデバイスログテーブル322内に記録することができる。
【0103】
最後に、ブロック540において、コアプロビジョニングサービス206は、「remove bootstrap」のメッセージを配信データベースライタ220のメッセージ待ち行列内に送信して、ブートストラップレコードを配信データベース214のブートストラップテーブル342から削除することができる。
【0104】
(パケットの配信)
図12は、プロビジョニングパケットをコアプロビジョニングサービス206からコンピューティングデバイス202などのさまざまなコンピューティングデバイスへ配信するために使用できるパケット配信プログラム550のためのフローチャートを示している。パケット配信プログラム550は、パケット/証明書要求マネージャー386によって、コンピューティングデバイスのユーザを補助する顧客サービス担当者によって、あるいはその他の類似の方法で開始することができる。
【0105】
ブロック552において、コアプロビジョニングサービス206は、配信サービスモジュール208のメッセージ待ち行列内のパケットダウンロードメッセージを受信することができる。このようなメッセージは、たとえばコンピューティングデバイス202のパケット/証明書要求マネージャー386によって送信することができる。パケットダウンロードメッセージを受信すると、ブロック554において、コアプロビジョニングサービス206は、パケット要求トランザクションを開始することができる。
【0106】
パケット要求トランザクションのはじめに、ブロック556において、確認サービス209は、パケットテーブル318内のステータスが、パケットダウンロードメッセージを送信しているコンピューティングデバイスがコアプロビジョニングサービス206による以前のパケット送信に対して確認応答を行っていないということを指定する「packet over limit」であるかどうかを判定することができ、コントロールは、ブロック564に移される。
【0107】
パケットテーブル318内のステータスが「packet over limit」ではないと判定された場合には、ブロック558において、コアプロビジョニングサービス206は、パケットテーブル318内のステータスを「delivery in progress」に更新することができる。
【0108】
その後、ブロック560において、コアプロビジョニングサービス206は、パケットテーブル318内の配信回数を、パケットダウンロードメッセージ内で指定されている値に更新することができる。たとえば、パケットダウンロードメッセージが、2つのパケットをコアプロビジョニングサービス206に要求している場合には、パケットテーブル318内の配信回数は、2だけ増加される。ブロック562において、コアプロビジョニングサービス206は、「packet delivery in progress」のメッセージをジョブログテーブル326内に記録することができる。
【0109】
ブロック564は、コンピューティングデバイスからの確認応答がないことによってコントロールを受け取ることができ、したがってブロック564において、コアプロビジョニングサービス206は、パケットテーブル318内のステータスを「over limit」に更新することができる。
【0110】
ブロック566において、コアプロビジョニングサービス206は、パケットテーブル318内の配信回数を、パケットダウンロードメッセージ内で指定されている値に更新することができ、ブロック568において、CPSは、ジョブテーブル316のステータスを「error」に更新する。最後に、ブロック570において、コアプロビジョニングサービス206は、「packet over limit」のメッセージをジョブログテーブル326内に記録することができる。
【0111】
ブロック572において、コアプロビジョニングサービス206は、パケット要求トランザクションの処理を終了することができ、パケットを要求しているコンピューティングデバイスからの確認応答を待つことができる。ブロック574において、コアプロビジョニングサービス206は、配信サービスモジュール208のメッセージ待ち行列内へのパケットダウンロード完了メッセージを受信することができる。このパケットダウンロード完了メッセージは、要求されているパッケージが首尾よくダウンロードされた際に、パケット/証明書要求マネージャー386によって送信することができる。
【0112】
パケットダウンロード完了メッセージを受信すると、ブロック576において、コアプロビジョニングサービス206は、パケットダウンロード完了トランザクションを開始することができる。パケットダウンロード完了トランザクションの一環として、ブロック578において、確認サービスは、パケットテーブル318内のステータスを「completed」に更新し、ブロック580において、ジョブテーブル内のステータスも「completed」に更新することができる。
【0113】
さらに、ブロック580において、コアプロビジョニングサービス206は、「job completed」のメッセージをジョブログテーブル326内に記録し、ブロック582において、パケットダウンロード完了トランザクションを終了することができる。
【0114】
ソフトウェアプロビジョニングシステム200のさまざまなコンポーネントのオペレーションについて説明してきたが、以降の図13〜図16では、さまざまな状況のもとでのユーザの経験を示すさまざまな例示的なシナリオについて説明する。
【0115】
(シナリオ1−ログイン中の残量の確認)
図13は、LPM224のオペレーション中の第1のシナリオを示すフローチャート600を示している。具体的には、フローチャート600は、ユーザがコンピュータにログオンしている場合のシナリオを示している。図13に示されているように、ブロック602において、ユーザがコンピューティングデバイス202へのログオンを試みているときに、強制アドオンモジュール352は、ログオンイベントを残量マネージャー366に送信することができる。このログオンイベントに応答して、ブロック604において、残量マネージャー366は、コンピューティングデバイス202上でオペレーティングシステムを使用するために利用可能な残量を確認することができる。残量が十分である場合には、ブロック606において、残量マネージャー366は、オペレーティングシステムを通常の方法でアクティブ化するようログインロジック364に通知することができる。
【0116】
しかし、残量が十分でないと残量マネージャー366が判定した場合には、ブロック608において、残量マネージャー366は、アクティブ化UI396をアクティブ化することができる。アクティブ化UIをアクティブ化する目的は、ユーザがさらなる使用時間を購入できるようにすることである。
【0117】
ブロック610において、アクティブ化UI396は、購入マネージャー388をアクティブ化することができ、ユーザは、購入を行うことができる。ユーザは、課金システム216に接続することによって、顧客サービス担当者に電話をかけることによって、あるいはその他の任意の所望の方法で、購入を行うことができる。その後、ブロック612において、証明書/パケット要求マネージャー386は、プロビジョニングパケットをダウンロードすることができる。
【0118】
証明書/パケット要求マネージャー386は、ダウンロードされたプロビジョニングパケットを安全なストレージのためのセキュアストアマネージャ358に提供することができる。ブロック614において、残量マネージャー366は、ダウンロードされたプロビジョニングパケットを分析することができ、ブロック616において、コンピューティングデバイス202にとって利用可能なプロビジョニング残量(provisioning balance)をしかるべく増やすことができる。
【0119】
(シナリオ2−ログオン後の使用権の購入)
図14は、LPM224のオペレーション中の第2のシナリオを示すフローチャート620を示している。具体的には、フローチャート620は、ユーザがコンピューティングデバイス202に既にログオンしていて、コントロールパネルアプレットまたはタスクバーアイコンを選択して、残量マネージャー366をアクティブ化する場合のシナリオを示している。
【0120】
ブロック622において、ユーザは、イベントを残量マネージャー366に送信するコントロールパネルアプレットをアクティブ化することができる。残量マネージャー366は、現在の残量情報をユーザに表示して、アクティブ化UI396を呼び出し、それによって購入マネージャー388をアクティブ化することができる。ユーザがさらなる時間の購入を行うと、証明書/パケット要求マネージャー386は、プロビジョニングパケットをダウンロードすることができる。
【0121】
証明書/パケット要求マネージャー386は、ダウンロードされたプロビジョニングパケットを安全なストレージのためのセキュアストアマネージャ358に提供することができる。ブロック628において、残量マネージャー366は、ダウンロードされたプロビジョニングパケットを分析することができ、ブロック630において、コンピューティングデバイス202にとって利用可能なプロビジョニング残量をしかるべく増やすことができる。
【0122】
(シナリオ3−ログオン後の残量の更新および通知)
図15は、LPM224のオペレーション中の第3のシナリオを示すフローチャート640を示している。具体的には、フローチャート640は、ユーザがコンピューティングデバイス202に既にログオンしていて、ログインロジック364がリライアブルクロックマネージャー370からのタイムチックの結果としてのイベントを受信する場合のシナリオを示している。
【0123】
ブロック642において、ログインロジック364は、リライアブルクロックマネージャー370からタイムチックイベントを受信することができる。結果として、ログインロジック364は、タイムチックイベントを残量マネージャー366へ送信することができる。
【0124】
そのタイムチックイベントに応答して、ブロック644において、残量マネージャー366は、コンピューティングデバイス202上でオペレーティングシステムを使用するために利用可能な残量を更新することができる。その後、ブロック646において、残量マネージャー366は、利用可能な残量をチェックする。その評価の結果に基づいて、ブロック648において、残量マネージャー366は、適切なアクションを取ることができ、このアクションは、たとえば、アクティブ化UI396をアクティブ化すること、ユーザをログオフさせること、その他の適切なアクションを継続することとすることができる。
【0125】
(シナリオ4−コンピューティングデバイスの非アクティブ化)
図16は、LPM224のオペレーション中の第4のシナリオを示すフローチャート660を示している。具体的には、フローチャート660は、ユーザがコンピューティングデバイス202に既にログオンしていて、ログインロジック364がリライアブルクロックマネージャー370からのタイムチックの結果としてのイベントを受信する場合のシナリオを示している。
【0126】
ブロック662において、ログインロジック364は、リライアブルクロックマネージャー370からタイムチックイベントを受信することができる。結果として、ログインロジック364は、タイムチックイベントを残量マネージャー366へ送信することができる。
【0127】
そのタイムチックイベントに応答して、ブロック664において、残量マネージャー366は、コンピューティングデバイス202上でオペレーティングシステムを使用するために利用可能な残量を更新することができる。その後、ブロック666において、残量マネージャー366は、利用可能な残量をチェックすることができる。その評価の結果に基づいて、ブロック668において、残量マネージャー366は、適切なアクションを取ることができ、このアクションは、たとえば、アクティブ化UI396をアクティブ化すること、ユーザをログオフさせること、その他の適切なアクションを継続することとすることができる。
【0128】
この場合には、たとえば、残量マネージャー366は、コンピューティングデバイス202にとって利用可能な残量が、しきい値にあるか、またはゼロなど、しきい値を下回っていることを検知する。結果として、ブロック668において、残量マネージャー366は、通知UI398にログオフメッセージを表示させることができ、最終的には、コンピューティングデバイス202上でオペレーティングシステムを使用している状態からユーザをログオフさせる。別の場合には、通知UI398は、購入マネージャー388をアクティブ化して、ユーザがさらなる使用時間を購入できるようにすることもできる。
【0129】
(シナリオ5−ログオン後の前払いの入力)
図17は、LPM224のオペレーション中の第5のシナリオを示すフローチャート680を示している。具体的には、フローチャート680は、ユーザがコンピューティングデバイス202に既にログオンしていて、コントロールパネルアプレットまたはタスクバーアイコンを選択して、プリペイドカードから情報を入力するためにアクティブ化ウィザードをアクティブ化する場合のシナリオを示している。これは、ユーザがプリペイドカードを以前に購入していて、そのプリペイドカードによって入手できる使用時間を自分のアカウントに追加しようと決めた場合に当てはまるかもしれない。
【0130】
ブロック682において、ユーザは、アクティブ化ウィザードを表示するためのアクティブ化UI396へイベントを送信するコントロールパネルアプレットをアクティブ化することができる。ユーザに表示できるGUIウィンドウの一例について、図18の追加時間ウィンドウ684によって説明する。ユーザは、追加時間ウィンドウ684から追加時間ボタンを選択して、プリペイドカードからの情報を入力することができる。
【0131】
その後、ブロック686において、アクティブ化UI396は、ユーザがアクティブ化ウィザードを使用できるようにする上で必要となるかもしれないさまざまな情報をユーザに通知することができ、このアクティブ化ウィザードは、図19のGUI688によって示されている。
【0132】
ブロック690において、アクティブ化UI396は、図20に示されているようなネットワーク接続GUI692を提示することができ、このネットワーク接続GUI692は、ウェブサービス通信マネージャー390がコアプロビジョニングサービス206にアクセスするためにインターネットに接続していることをユーザに通知する。
【0133】
その後、ブロック694において、アクティブ化UI396は、プリペイド使用権カード(pre−paid usage card)から受け取ったキーを入力するようユーザに促すことができる。プリペイドカード上のキーは、英数字やその他の文字の文字列を含むことができる。この場合には、キーは、図21のGUI696へ入力するものとして示されているように、25文字の長さの英数字のキーである。
【0134】
プリペイドカードからのキーを受信すると、ブロック698において、アクティブ化UI396は、図22のGUI700によって示されているように、.NET(登録商標)システムにログインするようユーザに促すことができる。ユーザが.NET(登録商標)システムにログインすることが常に必要というわけではないかもしれないという点に留意されたい。
【0135】
その後、ブロック702において、アクティブ化UI396は、プリペイドカードからのユーザのキーが受け入れられたこと、および対応する時間だけユーザのアカウントが増えるはずであることの確認をコアプロビジョニングサービス206から受信することができる。首尾よく時間が追加されたことを通知するメッセージは、図23のGUI704によって示されている。
【0136】
最後に、ブロック706において、アクティブ化UI396は、図24のGUI708によって示されているように、ユーザがプリペイドカードを使用することによって今しがた追加した時間が数分でコンピューティングデバイス202の貸方に記入される旨をユーザに通知することができる。
【0137】
上述の文章は、本発明の多くの異なる実施形態の詳細な説明を記載しているが、本発明の範囲は、本特許に添付されている特許請求の範囲の文言によって定義されるという点を理解されたい。この詳細な説明は、例示的なものにすぎないと解釈されるべきであり、本発明の可能な実施形態をすべて説明しているわけではない。というのも、可能な実施形態をすべて説明することは、不可能ではないにしても、非現実的と思われるためである。本発明を定義する特許請求の範囲内に今後とも収まるであろう現在の技術または本特許の出願日以降に開発される技術を使用して、多くの代替実施形態を実施することができる。
【0138】
したがって、本発明の趣旨および範囲から逸脱することなく、本明細書で説明および例示されている技術および構造において、多くの修正形態および変形形態を作成することができる。したがって、本明細書に記載されている方法および装置は、例示的なものにすぎず、本発明の範囲を限定するものではないという点を理解されたい。
【図面の簡単な説明】
【0139】
【図1】複数のコンピューティングリソースを相互接続するネットワークを示すブロック図である。
【図2】図1のネットワークに接続することができるコンピュータを示すブロック図である。
【図3】図1のネットワークのコンピュータ上にオペレーティングシステムを提供するためのソフトウェアプロビジョニングシステムを示すブロック図である。
【図4】図3のソフトウェアプロビジョニングシステム上でのコンピュータの登録を示すフローチャートである。
【図5】図3のソフトウェアプロビジョニングシステムのコアプロビジョニングシステム(core provisioning system)を示すブロック図である。
【図6】図5のコアプロビジョニングシステムによって使用されるコアデータベースを示すブロック図である。
【図7】図3のコアソフトウェアプロビジョニングシステムによって使用される配信データベースを示すブロック図である。
【図8】図3のソフトウェアプロビジョニングシステムのローカルプロビジョニングモジュール(local provisioning module)を示すブロック図である。
【図9】図3のソフトウェアプロビジョニングシステムによって使用されるキー登録プログラムを示すフローチャートである。
【図10】図3のソフトウェアプロビジョニングシステムによって使用されるパケット作成プログラムを示すフローチャートである。
【図11】図3のソフトウェアプロビジョニングシステムによって使用されるブートストラッピングプログラム(bootstrapping program)を示すフローチャートである。
【図12】図3のソフトウェアプロビジョニングシステムによって使用されるパケット配信プログラムを示すフローチャートである。
【図13】図8のローカルプロビジョニングモジュールのためのオペレーティングシナリオ(operating scenario)を示すフローチャートである。
【図14】図8のローカルプロビジョニングモジュールのためのオペレーティングシナリオを示す別のフローチャートである。
【図15】図8のローカルプロビジョニングモジュールのためのオペレーティングシナリオを示す別のフローチャートである。
【図16】図8のローカルプロビジョニングモジュールのためのオペレーティングシナリオを示す別のフローチャートである。
【図17】図8のローカルプロビジョニングモジュールのためのオペレーティングシナリオを示すさらに別のフローチャートである。
【図18】図17のオペレーティングシナリオの最中にユーザに提示される例示的なGUIを示す図である。
【図19】図17のオペレーティングシナリオの最中にユーザに提示される別の例示的なGUIを示す図である。
【図20】図17のオペレーティングシナリオの最中にユーザに提示される別の例示的なGUIを示す図である。
【図21】図17のオペレーティングシナリオの最中にユーザに提示される別の例示的なGUIを示す図である。
【図22】図17のオペレーティングシナリオの最中にユーザに提示される別の例示的なGUIを示す図である。
【図23】図17のオペレーティングシナリオの最中にユーザに提示される別の例示的なGUIを示す図である。
【図24】図17のオペレーティングシナリオの最中にユーザに提示される別の例示的なGUIを示す図である。
【特許請求の範囲】
【請求項1】
提供されたデバイス上でサービスを提供する方法であって、
前記提供されたデバイスを登録することを求める登録要求を受信することであって、前記登録要求は、提供されたデバイスのハードウェアIDを含むこと、
提供されたデバイスの証明書を作成すること、
提供されたデバイスのパケットを作成することを求めるパケット作成要求を受信することであって、前記パケット作成要求は、提供されたデバイスの初期設定キーを含むこと、
前記提供されたデバイスのパケットを作成することであって、前記提供されたデバイスのパケットは、前記提供されたデバイス上での前記サービスの第1の使用量を承認する情報を含むこと、
前記提供されたデバイスのパケットおよび前記提供されたデバイスの証明書を保存すること
を含むことを特徴とする方法。
【請求項2】
前記提供されたデバイスのパケットは、前記提供されたデバイスの初期設定キーと、前記提供されたデバイスの証明書と、前記提供されたデバイスのハードウェアIDとをさらに含むことを特徴とする請求項1に記載の方法。
【請求項3】
前記提供されたデバイスのハードウェアIDは、(1)パーソナルコンピュータ用のID、(2)前記パーソナルコンピュータのハードウェア構成、および(3)携帯電話のIDカードのうちの少なくとも1つを含むことを特徴とする請求項1に記載の方法。
【請求項4】
前記サービスは、(1)コンピュータソフトウェア、(2)コンピュータオペレーティングシステム、および(3)デジタル式に記録されたメディアのうちの1つであることを特徴とする請求項1に記載の方法。
【請求項5】
前記提供されたデバイスの証明書を作成することは、
公開鍵基盤から秘密キーを受信すること、
前記秘密キーを用いて前記提供されたデバイスの証明書をコード化することをさらに含むことを特徴とする請求項1に記載の方法。
【請求項6】
前記提供されたデバイス上での前記サービスの前記第1の使用量は、(1)前記サービスを使用するための時間、および(2)前記サービスを使用するための有効期限が切れる時間のうちの少なくとも1つを含むことを特徴とする請求項1に記載の方法。
【請求項7】
前記提供されたデバイスの証明書を求めるクライアント証明書要求をクライアントデバイスから受信することであって、前記クライアント証明書要求は、クライアントデバイスのハードウェアIDを含むこと、
前記クライアントデバイスのハードウェアIDが前記提供されたデバイスのハードウェアIDと一致していると判定された場合に、前記提供されたデバイスの証明書を検索すること、
前記提供されたデバイスの証明書を前記クライアントデバイスへ送信することをさらに含むことを特徴とする請求項1に記載の方法。
【請求項8】
前記提供されたデバイスのパケットを求めるクライアントパケット要求をクライアントデバイスから受信することであって、前記クライアントパケット要求は、(a)クライアントデバイスのハードウェアID、(b)クライアントデバイスの初期設定キー、および(3)クライアントデバイスの署名を含むこと、
前記クライアントデバイスの署名を確認すること、
(1)前記クライアントデバイスのハードウェアIDが前記提供されたデバイスのハードウェアIDと一致していると判定された場合に、および(2)前記クライアントデバイスの初期設定キーが前記提供されたデバイスの初期設定キーと一致していると判定された場合に、前記提供されたデバイスのパケットを検索すること、
前記提供されたデバイスのパケットを前記クライアントデバイスへ送信することをさらに含むことを特徴とする請求項1に記載の方法。
【請求項9】
前記提供されたデバイスのパケットを送信することは、
クライアント配信回数を増やすこと、
前記クライアント配信回数が最大クライアント配信回数未満である場合に、前記提供されたデバイスのパケットを送信すること、
前記クライアント配信回数が最大クライアント配信回数以上である場合に、提供されたデバイスのステータスをエラーステータスに設定すること、
前記クライアントデバイスから確認応答を受信すること、
前記確認応答が受信された場合に、前記クライアント配信回数をリセットすることをさらに含むことを特徴とする請求項8に記載の方法。
【請求項10】
前記サービスの前記第1の使用量によってクライアントの使用アカウントを更新することをさらに含むことを特徴とする請求項8に記載の方法。
【請求項11】
前記クライアントの署名は、公開鍵基盤によって作成されて、前記提供されたデバイスの証明書をコード化するために使用される秘密キーを含むことを特徴とする請求項8に記載の方法。
【請求項12】
前記クライアントパケット要求は、インターネットを介して受信されることを特徴とする請求項8に記載の方法。
【請求項13】
前記提供されたデバイスのパケットは、XMLベースのプロビジョニングパケットであることを特徴とする請求項1に記載の方法。
【請求項14】
提供されたデバイス上でサービスを提供するためのプロビジョニングパケットであって、
提供されたデバイスのハードウェアIDと、
提供されたデバイスの初期設定キーと、
前記提供されたデバイス上での前記サービスの第1の使用量を承認する情報を含むことを特徴とするプロビジョニングパケット。
【請求項15】
XMLベースのパケットであることを特徴とする請求項14に記載のプロビジョニングパケット。
【請求項16】
公開鍵基盤からの秘密キーを使用してコード化されることを特徴とする請求項14に記載のプロビジョニングパケット。
【請求項17】
請求項14に記載のプロビジョニングパケットを作成するためのプロビジョニングシステムであって、
前記提供されたデバイスを登録することを求める登録要求を受信するように適合されている第1のモジュールであって、前記登録要求は、提供されたデバイスのハードウェアIDを含む第1のモジュールと、
提供されたデバイスの証明書を作成するように適合されている第2のモジュールと、
前記プロビジョニングパケットを作成することを求めるパケット作成要求を受信するように適合されている第3のモジュールであって、前記パケット作成要求は、提供されたデバイスの初期設定キーを含む第3のモジュールと、
前記プロビジョニングパケットを作成するように適合されている第4のモジュールを含むことを特徴とするプロビジョニングシステム。
【請求項18】
前記サービスは、(1)コンピュータソフトウェア、(2)コンピュータオペレーティングシステム、および(3)デジタル式に記録されたメディアのうちの1つであることを特徴とする請求項17に記載のプロビジョニングシステム。
【請求項19】
公開鍵基盤から秘密キーを受信するように、および前記秘密キーを用いて前記プロビジョニングパケットをコード化するように適合されているさらなるモジュールをさらに含むことを特徴とする請求項17に記載のプロビジョニングシステム。
【請求項20】
前記プロビジョニングパケットを求めるクライアントパケット要求をクライアントデバイスから受信するように適合されているさらなるモジュールであって、前記クライアントパケット要求は、(a)クライアントデバイスのハードウェアID、(b)クライアントデバイスの初期設定キー、および(3)クライアントデバイスの署名を含むさらなるモジュールと、
前記クライアントデバイスの署名を確認するように適合されているさらなるモジュールと、
(1)前記クライアントデバイスのハードウェアIDが前記提供されたデバイスのハードウェアIDと同じである場合に、および(2)前記クライアントデバイスの初期設定キーが前記提供されたデバイスの初期設定キーと同じである場合に、前記プロビジョニングパケットを検索するように適合されているさらなるモジュールと、
前記プロビジョニングパケットを前記クライアントデバイスへ送信するように適合されているさらなるモジュールをさらに含むことを特徴とする請求項17に記載のプロビジョニングシステム。
【請求項21】
(1)提供されたデバイスを登録することを求める登録要求を受信することであって、前記登録要求は、提供されたデバイスのハードウェアIDを含むこと、
(2)提供されたデバイスの証明書を作成すること、
(3)提供されたデバイスのパケットを作成することを求めるパケット作成要求を受信することであって、前記パケット作成要求は、提供されたデバイスの初期設定キーを含むこと、
(4)前記提供されたデバイスのパケットを作成することであって、前記提供されたデバイスのパケットは、前記提供されたデバイス上でのサービスの第1の使用量を承認する情報を含むことを含む方法を実行するためのコンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。
【請求項22】
(1)前記提供されたデバイスの証明書を求めるクライアント証明書要求をクライアントデバイスから受信することであって、前記クライアント証明書要求は、クライアントデバイスのハードウェアIDを含むこと、
(2)前記クライアントデバイスのハードウェアIDが前記提供されたデバイスのハードウェアIDと同じである場合に、前記提供されたデバイスの証明書を検索すること、
(3)前記提供されたデバイスの証明書を前記クライアントデバイスへ送信することを含む方法を実行するためのさらなるコンピュータ実行可能命令を有することを特徴とする請求項21に記載のコンピュータ可読媒体。
【請求項23】
前記サービスは、(1)コンピュータソフトウェア、および(2)コンピュータオペレーティングシステムのうちの1つであることを特徴とする請求項21に記載のコンピュータ可読媒体。
【請求項24】
複数のコンピューティングデバイスと通信するネットワークであって、前記複数のコンピューティングデバイスは、
提供されたデバイス上でのサービスに関する使用量を販売するように適合されている課金システムと、
前記提供されたデバイス上での前記サービスに関する前記使用量を提供するように適合されているプロビジョニングシステムを含み、前記プロビジョニングシステムは、
前記提供されたデバイスを登録することを求める登録要求を前記課金システムから受信するように適合されている登録モジュールであって、前記登録要求は、提供されたデバイスのハードウェアIDを含む登録モジュールと、
提供されたデバイスの証明書を作成するように適合されている証明書モジュールと、
前記プロビジョニングパケットを作成することを求めるパケット作成要求を受信するように適合されている配信モジュールであって、前記パケット作成要求は、提供されたデバイスの初期設定キーを含む配信モジュールと、
前記プロビジョニングパケットを作成するように適合されているパケット作成モジュールを含み、
前記配信モジュールは、前記プロビジョニングパケットを前記提供されたデバイスへ送信するようにさらに適合されており、
前記提供されたデバイスは、前記サービスを使用するように適合されており、前記提供されたデバイスは、
前記パケット作成要求を前記プロビジョニングシステムへ送信するように、および前記プロビジョニングパケットをダウンロードするように適合されているパケット要求モジュールと、
前記プロビジョニングパケットを安全に保存するように適合されているストレージモジュールと、
前記プロビジョニングパケットを分析して、残量値を生成するように適合されている残量モジュールと、
(1)前記残量値がしきい値を上回っている場合には、前記提供されたデバイス上で前記サービスをアクティブ化するように、および(2)前記残量値が前記しきい値以下である場合には、前記提供されたデバイス上で前記サービスを非アクティブ化するように適合されている強制モジュールを含むことを特徴とするネットワーク。
【請求項25】
前記プロビジョニングシステムは、前記提供されたデバイスのための秘密キーを要求するように、および前記秘密キーを用いて前記証明書をコード化するようにさらに適合されていることを特徴とする請求項24に記載のネットワーク。
【請求項26】
前記課金システムは、(1)前記初期設定キーを伴って印刷されたプリペイドカードを作成するように、および(2)小売店を介してユーザに前記プリペイドカードを販売するようにさらに適合されていることを特徴とする請求項24に記載のネットワーク。
【請求項27】
前記提供されたデバイスは、
前記ユーザから前記初期設定キーを受信するように適合されているアクティブ化モジュールをさらに含み、
前記要求モジュールは、前記初期設定キーを用いて前記パケット作成要求を作成するようにさらに適合されていることを特徴とする請求項26に記載のネットワーク。
【請求項28】
前記提供されたデバイスは、(1)パーソナルコンピュータ、(2)携帯電話、(3)ゲーミングデバイス、および(4)メディアプレーヤのうちの1つであることを特徴とする請求項24に記載のネットワーク。
【請求項29】
前記プロビジョニングパケットは、XMLベースのプロビジョニングパケットであることを特徴とする請求項24に記載のネットワーク。
【請求項30】
前記提供されたデバイスは、インターネットを使用して前記ネットワークと通信することを特徴とする請求項24に記載のネットワーク。
【請求項1】
提供されたデバイス上でサービスを提供する方法であって、
前記提供されたデバイスを登録することを求める登録要求を受信することであって、前記登録要求は、提供されたデバイスのハードウェアIDを含むこと、
提供されたデバイスの証明書を作成すること、
提供されたデバイスのパケットを作成することを求めるパケット作成要求を受信することであって、前記パケット作成要求は、提供されたデバイスの初期設定キーを含むこと、
前記提供されたデバイスのパケットを作成することであって、前記提供されたデバイスのパケットは、前記提供されたデバイス上での前記サービスの第1の使用量を承認する情報を含むこと、
前記提供されたデバイスのパケットおよび前記提供されたデバイスの証明書を保存すること
を含むことを特徴とする方法。
【請求項2】
前記提供されたデバイスのパケットは、前記提供されたデバイスの初期設定キーと、前記提供されたデバイスの証明書と、前記提供されたデバイスのハードウェアIDとをさらに含むことを特徴とする請求項1に記載の方法。
【請求項3】
前記提供されたデバイスのハードウェアIDは、(1)パーソナルコンピュータ用のID、(2)前記パーソナルコンピュータのハードウェア構成、および(3)携帯電話のIDカードのうちの少なくとも1つを含むことを特徴とする請求項1に記載の方法。
【請求項4】
前記サービスは、(1)コンピュータソフトウェア、(2)コンピュータオペレーティングシステム、および(3)デジタル式に記録されたメディアのうちの1つであることを特徴とする請求項1に記載の方法。
【請求項5】
前記提供されたデバイスの証明書を作成することは、
公開鍵基盤から秘密キーを受信すること、
前記秘密キーを用いて前記提供されたデバイスの証明書をコード化することをさらに含むことを特徴とする請求項1に記載の方法。
【請求項6】
前記提供されたデバイス上での前記サービスの前記第1の使用量は、(1)前記サービスを使用するための時間、および(2)前記サービスを使用するための有効期限が切れる時間のうちの少なくとも1つを含むことを特徴とする請求項1に記載の方法。
【請求項7】
前記提供されたデバイスの証明書を求めるクライアント証明書要求をクライアントデバイスから受信することであって、前記クライアント証明書要求は、クライアントデバイスのハードウェアIDを含むこと、
前記クライアントデバイスのハードウェアIDが前記提供されたデバイスのハードウェアIDと一致していると判定された場合に、前記提供されたデバイスの証明書を検索すること、
前記提供されたデバイスの証明書を前記クライアントデバイスへ送信することをさらに含むことを特徴とする請求項1に記載の方法。
【請求項8】
前記提供されたデバイスのパケットを求めるクライアントパケット要求をクライアントデバイスから受信することであって、前記クライアントパケット要求は、(a)クライアントデバイスのハードウェアID、(b)クライアントデバイスの初期設定キー、および(3)クライアントデバイスの署名を含むこと、
前記クライアントデバイスの署名を確認すること、
(1)前記クライアントデバイスのハードウェアIDが前記提供されたデバイスのハードウェアIDと一致していると判定された場合に、および(2)前記クライアントデバイスの初期設定キーが前記提供されたデバイスの初期設定キーと一致していると判定された場合に、前記提供されたデバイスのパケットを検索すること、
前記提供されたデバイスのパケットを前記クライアントデバイスへ送信することをさらに含むことを特徴とする請求項1に記載の方法。
【請求項9】
前記提供されたデバイスのパケットを送信することは、
クライアント配信回数を増やすこと、
前記クライアント配信回数が最大クライアント配信回数未満である場合に、前記提供されたデバイスのパケットを送信すること、
前記クライアント配信回数が最大クライアント配信回数以上である場合に、提供されたデバイスのステータスをエラーステータスに設定すること、
前記クライアントデバイスから確認応答を受信すること、
前記確認応答が受信された場合に、前記クライアント配信回数をリセットすることをさらに含むことを特徴とする請求項8に記載の方法。
【請求項10】
前記サービスの前記第1の使用量によってクライアントの使用アカウントを更新することをさらに含むことを特徴とする請求項8に記載の方法。
【請求項11】
前記クライアントの署名は、公開鍵基盤によって作成されて、前記提供されたデバイスの証明書をコード化するために使用される秘密キーを含むことを特徴とする請求項8に記載の方法。
【請求項12】
前記クライアントパケット要求は、インターネットを介して受信されることを特徴とする請求項8に記載の方法。
【請求項13】
前記提供されたデバイスのパケットは、XMLベースのプロビジョニングパケットであることを特徴とする請求項1に記載の方法。
【請求項14】
提供されたデバイス上でサービスを提供するためのプロビジョニングパケットであって、
提供されたデバイスのハードウェアIDと、
提供されたデバイスの初期設定キーと、
前記提供されたデバイス上での前記サービスの第1の使用量を承認する情報を含むことを特徴とするプロビジョニングパケット。
【請求項15】
XMLベースのパケットであることを特徴とする請求項14に記載のプロビジョニングパケット。
【請求項16】
公開鍵基盤からの秘密キーを使用してコード化されることを特徴とする請求項14に記載のプロビジョニングパケット。
【請求項17】
請求項14に記載のプロビジョニングパケットを作成するためのプロビジョニングシステムであって、
前記提供されたデバイスを登録することを求める登録要求を受信するように適合されている第1のモジュールであって、前記登録要求は、提供されたデバイスのハードウェアIDを含む第1のモジュールと、
提供されたデバイスの証明書を作成するように適合されている第2のモジュールと、
前記プロビジョニングパケットを作成することを求めるパケット作成要求を受信するように適合されている第3のモジュールであって、前記パケット作成要求は、提供されたデバイスの初期設定キーを含む第3のモジュールと、
前記プロビジョニングパケットを作成するように適合されている第4のモジュールを含むことを特徴とするプロビジョニングシステム。
【請求項18】
前記サービスは、(1)コンピュータソフトウェア、(2)コンピュータオペレーティングシステム、および(3)デジタル式に記録されたメディアのうちの1つであることを特徴とする請求項17に記載のプロビジョニングシステム。
【請求項19】
公開鍵基盤から秘密キーを受信するように、および前記秘密キーを用いて前記プロビジョニングパケットをコード化するように適合されているさらなるモジュールをさらに含むことを特徴とする請求項17に記載のプロビジョニングシステム。
【請求項20】
前記プロビジョニングパケットを求めるクライアントパケット要求をクライアントデバイスから受信するように適合されているさらなるモジュールであって、前記クライアントパケット要求は、(a)クライアントデバイスのハードウェアID、(b)クライアントデバイスの初期設定キー、および(3)クライアントデバイスの署名を含むさらなるモジュールと、
前記クライアントデバイスの署名を確認するように適合されているさらなるモジュールと、
(1)前記クライアントデバイスのハードウェアIDが前記提供されたデバイスのハードウェアIDと同じである場合に、および(2)前記クライアントデバイスの初期設定キーが前記提供されたデバイスの初期設定キーと同じである場合に、前記プロビジョニングパケットを検索するように適合されているさらなるモジュールと、
前記プロビジョニングパケットを前記クライアントデバイスへ送信するように適合されているさらなるモジュールをさらに含むことを特徴とする請求項17に記載のプロビジョニングシステム。
【請求項21】
(1)提供されたデバイスを登録することを求める登録要求を受信することであって、前記登録要求は、提供されたデバイスのハードウェアIDを含むこと、
(2)提供されたデバイスの証明書を作成すること、
(3)提供されたデバイスのパケットを作成することを求めるパケット作成要求を受信することであって、前記パケット作成要求は、提供されたデバイスの初期設定キーを含むこと、
(4)前記提供されたデバイスのパケットを作成することであって、前記提供されたデバイスのパケットは、前記提供されたデバイス上でのサービスの第1の使用量を承認する情報を含むことを含む方法を実行するためのコンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。
【請求項22】
(1)前記提供されたデバイスの証明書を求めるクライアント証明書要求をクライアントデバイスから受信することであって、前記クライアント証明書要求は、クライアントデバイスのハードウェアIDを含むこと、
(2)前記クライアントデバイスのハードウェアIDが前記提供されたデバイスのハードウェアIDと同じである場合に、前記提供されたデバイスの証明書を検索すること、
(3)前記提供されたデバイスの証明書を前記クライアントデバイスへ送信することを含む方法を実行するためのさらなるコンピュータ実行可能命令を有することを特徴とする請求項21に記載のコンピュータ可読媒体。
【請求項23】
前記サービスは、(1)コンピュータソフトウェア、および(2)コンピュータオペレーティングシステムのうちの1つであることを特徴とする請求項21に記載のコンピュータ可読媒体。
【請求項24】
複数のコンピューティングデバイスと通信するネットワークであって、前記複数のコンピューティングデバイスは、
提供されたデバイス上でのサービスに関する使用量を販売するように適合されている課金システムと、
前記提供されたデバイス上での前記サービスに関する前記使用量を提供するように適合されているプロビジョニングシステムを含み、前記プロビジョニングシステムは、
前記提供されたデバイスを登録することを求める登録要求を前記課金システムから受信するように適合されている登録モジュールであって、前記登録要求は、提供されたデバイスのハードウェアIDを含む登録モジュールと、
提供されたデバイスの証明書を作成するように適合されている証明書モジュールと、
前記プロビジョニングパケットを作成することを求めるパケット作成要求を受信するように適合されている配信モジュールであって、前記パケット作成要求は、提供されたデバイスの初期設定キーを含む配信モジュールと、
前記プロビジョニングパケットを作成するように適合されているパケット作成モジュールを含み、
前記配信モジュールは、前記プロビジョニングパケットを前記提供されたデバイスへ送信するようにさらに適合されており、
前記提供されたデバイスは、前記サービスを使用するように適合されており、前記提供されたデバイスは、
前記パケット作成要求を前記プロビジョニングシステムへ送信するように、および前記プロビジョニングパケットをダウンロードするように適合されているパケット要求モジュールと、
前記プロビジョニングパケットを安全に保存するように適合されているストレージモジュールと、
前記プロビジョニングパケットを分析して、残量値を生成するように適合されている残量モジュールと、
(1)前記残量値がしきい値を上回っている場合には、前記提供されたデバイス上で前記サービスをアクティブ化するように、および(2)前記残量値が前記しきい値以下である場合には、前記提供されたデバイス上で前記サービスを非アクティブ化するように適合されている強制モジュールを含むことを特徴とするネットワーク。
【請求項25】
前記プロビジョニングシステムは、前記提供されたデバイスのための秘密キーを要求するように、および前記秘密キーを用いて前記証明書をコード化するようにさらに適合されていることを特徴とする請求項24に記載のネットワーク。
【請求項26】
前記課金システムは、(1)前記初期設定キーを伴って印刷されたプリペイドカードを作成するように、および(2)小売店を介してユーザに前記プリペイドカードを販売するようにさらに適合されていることを特徴とする請求項24に記載のネットワーク。
【請求項27】
前記提供されたデバイスは、
前記ユーザから前記初期設定キーを受信するように適合されているアクティブ化モジュールをさらに含み、
前記要求モジュールは、前記初期設定キーを用いて前記パケット作成要求を作成するようにさらに適合されていることを特徴とする請求項26に記載のネットワーク。
【請求項28】
前記提供されたデバイスは、(1)パーソナルコンピュータ、(2)携帯電話、(3)ゲーミングデバイス、および(4)メディアプレーヤのうちの1つであることを特徴とする請求項24に記載のネットワーク。
【請求項29】
前記プロビジョニングパケットは、XMLベースのプロビジョニングパケットであることを特徴とする請求項24に記載のネットワーク。
【請求項30】
前記提供されたデバイスは、インターネットを使用して前記ネットワークと通信することを特徴とする請求項24に記載のネットワーク。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【公表番号】特表2008−521090(P2008−521090A)
【公表日】平成20年6月19日(2008.6.19)
【国際特許分類】
【出願番号】特願2007−541352(P2007−541352)
【出願日】平成17年11月12日(2005.11.12)
【国際出願番号】PCT/US2005/040942
【国際公開番号】WO2006/055421
【国際公開日】平成18年5月26日(2006.5.26)
【出願人】(500046438)マイクロソフト コーポレーション (3,165)
【Fターム(参考)】
【公表日】平成20年6月19日(2008.6.19)
【国際特許分類】
【出願日】平成17年11月12日(2005.11.12)
【国際出願番号】PCT/US2005/040942
【国際公開番号】WO2006/055421
【国際公開日】平成18年5月26日(2006.5.26)
【出願人】(500046438)マイクロソフト コーポレーション (3,165)
【Fターム(参考)】
[ Back to top ]