JP2015510634A - 同期プロバイダーを使用するアプリケーション・ライセンス供与 - Google Patents

Abstract

本明細書では、同期プロバイダーを用いてアプリケーション（２２０）をライセンスするための方法、システム、およびコンピューター読み取り可能媒体を提供する。本方法は、ライセンシング・サービス（３０２）においてクライアント同期プロバイダー（３０４Ｄ）からアプリケーション（２２０）のライセンスを求める要求を受けるステップ（２５０２）と、アプリケーション（２２０）を提供するコマース・パートナーからライセンスに関する情報を、コマース・パートナーの同期プロバイダーを介して受信するステップ（２５０４）とを含む。また、この方法は、アプリケーション（２２０）のライセンスをクライアント計算デバイス（３０８）に戻すステップ（２５０６）と、クライアント同期プロバイダー（３０４Ｄ）からライセンスの状態に関する情報を受信するステップ（２５０８）と、ライセンスの状態にしたがってライセンスの条件を調整するステップ（２５１０）も含む。【選択図】図２５

Description

ライセンス、または権利は、クライアントが、例えば、文書処理アプリケーション、スプレッドシート・アプリケーション、およびプレゼンテーション・アプリケーションというような特定のアプリケーションにアクセスしてもよいやり方を制御するために一般に用いられる。通例では、各タイプのクライアント計算デバイスは別個のライセンシング・サービスを有し、クライアント計算デバイスのタイプは、例えば、クライアント計算デバイスの特定のオペレーティング・システム（ＯＳ）、またはクライアント計算デバイスの銘柄を含むことができる。しかしながら、クライアント計算デバイスのタイプ毎に、このように別個のライセンシング・サービスを用いると、様々な障害(limitation)が生ずる。例えば、クライアント計算デバイスのタイプ毎に別々のライセンシング・サービスを構築し維持することには、高いコストを伴う可能性がある。加えて、抱き合わせの提案(bundling offer)を提供することが望ましい場合もある。これは、多数のタイプのクライアント計算デバイスにおいて使用してもよい１つ以上のアプリケーションに対するライセンスを含む。しかしながら、別々のライセンシング・サービスの使用は、このような抱き合わせの提案を排除することもある。何故なら、抱き合わせが多くの異なるタイプのデバイスまたはシステム間における統合を拠り所とするからである。更に、マーケットプレース・サービス(marketplace service)が、ライセンス販売用の別々の各ライセンシング・サービスと統合することは困難であろうし、ライセンス所有権の一貫した証明を保持するも困難であろう。例えば、１つのライセンシング・サービスがプロダクト・キーを使用し、他のライセンシング・サービスがトークンを使用する場合もある。

以下に、本明細書において説明する態様の基本的な理解を得るために、本発明を簡略化した摘要を紹介する。この摘要は、特許請求する主題の広範な全体像ではない。また、特許請求する主題の鍵となるエレメントや重要なエレメントを識別することも、本発明の範囲を正確に定めることも意図していない。その唯一の目的は、後に紹介する更に詳細な説明に対する序文として、特許請求する主題の概念を簡略化した形態で紹介することである。

一実施形態は、同期プロバイダー(sync provider)を用いてアプリケーションをライセンスする方法を提供する。この方法は、ライセンシング・サービスにおいてクライアント同期プロバイダーからアプリケーションのライセンスを求める要求を受けるステップと、このライセンスに関する情報を、アプリケーションを提供するコマース・パートナー(commerce partner)からコマース・パートナー同期プロバイダーを介して受信するステップとを含む。また、この方法は、アプリケーションのライセンスをクライアント計算デバイスに戻すステップと、ライセンスの状態に関する情報をクライアント同期プロバイダーから受信するステップと、ライセンス状態にしたがってライセンスの条件を調整するステップも含む。

他の実施形態は、同期プロバイダーを用いてアプリケーションをライセンスするシステムを提供する。このシステムは、コマース・パートナーからプロビジョニング要求を、コマース・パートナー同期プロバイダーを介して受け、ライセンシング・サービスにアプリケーションのライセンスを要求するシステム・コールを送り、周期的にライセンスの状態を判定し更新するように構成されたクライアント同期プロバイダーを含む。また、このシステムは、アプリケーションのライセンスをクライアント計算デバイスに戻し、ライセンスの状態に関する情報をクライアント同期プロバイダーから受信し、ライセンスの状態にしたがってライセンスの条件を調整するように構成されたライセンシング・サービスも含む。

他の実施形態は、多数の命令を含む１つ以上のコンピューター読み取り可能記憶媒体を提供する。これらの命令は、プロセッサーによって実行されると、プロセッサーに、アプリケーションのライセンスを求める要求をクライアント同期プロバイダーから受け取らせ、このライセンスに関する情報を、アプリケーションを提供するコマース・パートナーに対応するコマース・パートナー同期プロバイダーから受信させる。また、これらの命令は、プロセッサーに、アプリケーションのライセンスをクライアント計算デバイスに戻させ、ライセンスの状態に関する情報を判定させ、このライセンスの状態にしたがってライセンスの条件を更新させる。

この摘要は、詳細な説明において以下で更に説明する概念から選択したものを、簡略化した形態で紹介するために設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を限定するために用いられることを意図するのでもない。

図１は、本明細書において説明するライセンシング・サービスを実現するために用いることができるネットワーク接続環境のブロック図である。 図２は、本明細書において説明するライセンシング・サービスを実現するために用いることができる計算環境のブロック図である。 図３Ａは、アプリケーションのライセンスを管理するために用いることができるライセンシング・システムの模式図を示す。 図３Ｂは、アプリケーションのライセンスを管理するために用いることができるライセンシング・システムの模式図を示す。 図３Ｃは、アプリケーションのライセンスを管理するために用いることができるライセンシング・システムの模式図を示す。 図４は、マーケットプレース・サービスを介してアプリケーションのライセンスを購入する方法のプロセス・フロー図である。 図５は、マーケットプレース・サービスを介したアプリケーションのライセンスの初期アクティベーション方法のプロセス・フロー図である。 図６は、アプリケーションのライセンスの再アクティベーション方法のプロセス・フロー図である。 図７は、多数の異なるマシンに対してユーザーにライセンスされた多数の権利、またはライセンスを示すブロック図である。 図８は、権利を他の提案(offer)に変換する、または権利に関する提案を更新する方法のプロセス・フロー図である。 図９は、キーレス許可(keyless authorization)をプロビジョニングしようとするユーザーの個人情報および権利の識別情報(identity)を検証する方法のプロセス・フロー図である。 図１０は、キーレス許可を適宜プロビジョニングする方法のプロセス・フロー図である。 図１１Ａは、既存登録（またはＴＢＬ）キーを引き出す方法のプロセス・フロー図である。 図１１Ｂは、新登録キーを得る方法のプロセス・フロー図である。 図１２Ａは、既存のプロダクト・キーを引き出す方法のプロセス・フロー図である。 図１２Ｂは、新たなプロダクト・キーを得る方法のプロセス・フロー図である。 図１３は、権利からマシンを引き出す方法のプロセス・フロー図である。 図１４は、権利から特定のマシンを解除する(deprovision)方法のプロセス・フロー図である。 図１５Ａは、ユーザーによる権利の初期購入方法のプロセス・フロー図である。 図１５Ｂは、権利更新方法のプロセス・フロー図である。 図１６は、ＯＬＳにおいてユーザーにプロビジョニングする、即ち、ユーザーを１つの権利から別の権利に変換する方法のプロセス・フロー図である。 図１７は、強制更新プロセスにしたがって権利を更新するか否か決定する方法のプロセス・フロー図である。 図１８Ａは、デバイス用アプリケーションの初期ライセンシング方法のプロセス・フロー図である。 図１８Ｂは、ライセンスの状態を周期的にチェックする方法のプロセス・フロー図である。 図１９は、最初にデバイスにライセンス供与する方法のプロセス・フロー図である。 図２０は、ユーザーにそのサービスへのアクセスを付与するか否かについての、パートナーによる決定方法のプロセス・フロー図である。 図２１は、マスター・データ・センターおよび多数の複製データ・センターの構成例の模式図である。 図２２は、計画ダウンタイム(planned downtime)を実行する第１ステップを示す模式図である。 図２３は、計画ダウンタイムを実行する第２ステップを示す模式図である。 図２４は、アプリケーション・ライセンシング方法のプロセス・フロー図である。 図２５は、同期プロバイダーを用いたアプリケーションのライセンシング方法のプロセス・フロー図である。 図２６は、多数のライセンシング形態を用いたアプリケーション・ライセンシング方法のプロセス・フロー図である。 図２７は、デバイスに対するアプリケーションのライセンシング方法のプロセス・フロー図である。 図２８は、ユーザーに基づいてアプリケーションのライセンシングを提供する方法のプロセス・フロー図である。

本明細書において開示する実施形態は、種々の判断基準および技法にしたがって、アプリケーションのライセンスを供与する方法およびシステムについて明記する。本明細書において用いる場合、「アプリケーション」という用語は、計算環境において実現されるアプリケーション、プログラム、またはサービスを指すことができる。本明細書において説明するライセンシング・サービスにしたがって利用することができるアプリケーションは、MICROSOFT WORD、MICROSOFT EXCEL、MICROSOFT POWERPOINT、MICROSOFT VISIO、またはMICROSOFT SHAREPOINTを含むが、これらに限定されるのではない。これらは全て、ワシントン州、RedmondのMicrosoft Corporation（マイクロソフト社）から入手可能である。アプリケーションは、マーケットプレース・サービスによって、または多数の第三者サービスのいずれによってでも、ネットワークを通じて計算デバイスに提供することができる。このようなアプリケーションに対する種々の異なるタイプのライセンスまたは権利は、種々の異なる方法によって取得することができる。

本明細書において説明するライセンシング・サービスは、別々のライセンシング・サービスに関して以上で論じた問題を、新たなクライアント計算デバイスにライセンスするための広範で一貫性のある方法を提供することによって解決する。加えて、このライセンシング・サービスは、ライセンシング・プロセスを購入プロセスから分離することによって、新たなパートナー、即ち、コマース・パートナーが容易にアプリケーションを販売することを可能にする。加えて、このライセンシング・サービスは、異なるクライアント、またはクライアント・デバイスに跨がる提案(offer)を可能にする。このライセンシング・サービスは、異なるクライアントのユーザーが、１組の信任状(credential)によってアプリケーションを使用するようにプロビジョニングされることを証明することも可能にする。更に、このライセンシング・サービスは、デバイスがオフラインになっていても、デバイスおよびサービスにわたる同期ライセンス期間を含めることも可能にする。これによって、全てのデバイスおよびサービスにおける体験が、登録が失効したときに、一貫性を維持することが可能になる。

このライセンシング・サービスは、本明細書では、「オフィス・ライセンシング・サービス」または「ＯＬＳ」と呼ぶこともできる。何故なら、先に羅列したもののように、ワシントン州、RedmondのMicrosoft Corporationから入手可能な、MICROSOFT OFFICE、即ち、「オフィス」アプリケーションをライセンスするために使用することができるからである。しかしながら、本ライセンシング・サービスは、多数のあらゆるプロバイダーから入手可能な他のあらゆる適したタイプのアプリケーションをライセンスするためにも使用できることは言うまでもない。

種々の実施形態において、ＯＬＳは、一貫性があり、拡張可能であり、明確な(well-defined)１組のプロトコルによって、多数のライセンシング方法を使用する能力を提供する。例えば、このようなライセンシング方法は、とりわけ、プロダクト・キーに基づくライセンシング、オンライン・ユーザーに基づくライセンシング、デバイスに基づくライセンシング、およびトークンに基づくライセンシングを含むことができる。

実施形態では、ＯＳＬがユーザーのライセンス状態を周期的にチェックするように構成される。これによって、製品をオフラインで使用できることと、最新のライセンシング情報、例えば、ライセンスが解除されたか否かといった情報を得られることとの間における釣り合いに対処することができる。ユーザーのライセンス情報は、「登録ハートビート」(subscription heartbeat)と呼ぶこともできる。登録ハートビートは、アプリケーションのライセンスをディスエーブルすべきか否か判断し、これによって対応するアプリケーションをディアクティベート(deactivate)するために用いることができる。

ＯＬＳは、多数のデバイスおよびサービスに跨がるユーザーのライセンス状態の同期を得ることができる。実施形態では、ＯＬＳは、オフィスを実行するデバイス、例えば、とりわけ、ＰＣ、Ｍａｃ、移動体、またはスレート、およびオフィス・サービス、例えば、ローミング設定が一貫したライセンス状態を有することを可能にする。つまり、ユーザーの登録が失効したとき、クライアントおよびサービスへのアクセスも同時に切断することができる。加えて、特定のデバイスに許可されるオフライン・ライセンス時間の量を予め設定することによって、ユーザーがオフラインになっている場合でも、ライセンス状態を同期させることができる。

更に、ＯＬＳは、オフライン・クライアントの許容限度(tolerance)、および不正行為の検出にも考慮すること(provide for)ができる。例えば、ＯＬＳは、新たなクライアントがライセンスを申請しているときと、既存のクライアントがライセンスの更新を申請しているときとを判別するロジックを含むことができる。また、ＯＬＳは、デバイスの追加および削除を行い、ある数のアクティブなデバイスを維持することをユーザーに許可しつつ、ユーザーが、過剰な数の新たなライセンスを申請するというような、不正行為を行っているときを判定するロジックも含むことができる。

種々の実施形態において、ＯＬＳはデバイスのライセンシングを提供する。例えば、ＯＬＳは、ＭＯＸデバイスのライセンシングを提供することができる。ここで、「ＭＯＸ」という用語は、一般に、全てのWindows8スレート・デバイスに言及する。ＯＬＳは、信任状およびＯＬＳライセンスを用いて、このようなライセンシングを提供することができる。ＯＬＳライセンスは、新たな形態のライセンスであり、プロダクト・キーによって付与される従前の許可とは異なる。ＯＬＳライセンスは、従前のシステム、例えば、従前のオフィス・ソフトウェア製品プラットフォーム（ＯＳＰＰ）システムの外部にあるサーバーから構成された、構成可能なライセンス・チェック期間を含むことができる。

種々の実施形態では、ＯＬＳはサービスに対してライセンシングを提供する。具体的には、ＯＬＳは、ポール・モデル(poll model)を用いて、サービスに対してライセンスを提供するスケーラブルな方法を提供することができ、サービスは適宜ＯＬＳに問い合わせる。ＯＬＳは、システムをスケーラブルにするために、サービスまたはクライアント自体にある時間量にわたってプロビジョニング／ライセンス情報をキャッシュすることができる。加えて、サービスに対するライセンシングを提供するために、プッシュ・モデルを用いることもできる。

ＯＬＳは、災害回復にも対処することができる。例えば、カスタム地理複製ロジック(custom geographical replication logic)を用いて同期が保たれる、地理的に分散されたサーバーを通じて、ゼロ・デイ接近復元ポイント(close to zero day recovery point)およびゼロ分接近復元時間 (close to zero minute recovery time) が、カスタム地理的複製ロジックを用いて同期が維持され、地理的に分散されたサーバーによって達成することができる。これは、常時同期が維持されるべき情報を、ある程度同期させることができる情報から分離し、次いで同期プロバイダーのプールによってこの情報を同期させることによって遂行することができる。加えて、上書きを回避するために、施錠メカニズムを用いることもできる。

更に、ＯＬＳはユーザーに基づくライセンシングを提供することができる。豊富なクライアント・アプリケーションを用いるためのライセンシング情報をサーバーから送ることができ、ユーザーのログイン情報に基づくことができる。このライセンシング情報は、クライアントの代わりに、サーバー上に保持することができ、このライセンシング情報は、サーバー上でユーザーと共にローミングすることができる。これは、ローミングの用途のため、またはキーに基づくライセンシングが用いられる前の初期取得のためというように、多数のシナリオで用いることができる。

前提事項として、図の一部は、機能性(functionality)、モジュール、機構(feature)、エレメント等と様々に呼ばれる、１つ以上の構造的コンポーネントのコンテキストにおいて概念を記述する。図に示す種々のコンポーネントは、いずれのやり方でも実現することができ、例えば、ソフトウェア、ハードウェア（例えば、ディスクリート論理コンポーネント等）、ファームウェア等、あるいはこれらの実施態様のあらゆる組み合わせで実現することができる。一実施形態では、種々のコンポーネントは、実際の実施態様における対応するコンポーネントの使用を反映することができる。他の実施形態では、図に示される単一エレメントはいずれも、多数の実際のコンポーネントによって実現されてもよい。図における２つ以上の別々のコンポーネントの図示はいずれも、１つの実際のコンポーネントによって行われる異なる機能を反映することができる。以下で論ずる図１は、図に示す機能を実現するために用いることができる１つのシステムに関する詳細を示す。

他の図は、フローチャート形態で概念を記述する。この形態では、ある種の動作は、ある順序で実行される別個のブロックを構成すると記述される。このような実施態様は例示的で非限定的である。本明細書において説明するあるブロックは、一緒に纏めて１つの動作において実行することができ、あるブロックは、複数のコンポーネント・ブロックに分解することができ、あるブロックは、図に示す順序とは異なる順序で実行することができ、ブロックの並列実行というやり方を含む。フローチャートに示されるブロックは、ソフトウェア、ハードウェア、ファーウェア、手動処理等、またはこれらの実施態様のあらゆる組み合わせで実現することができる。本明細書において用いる場合、ハードウェアは、コンピューター・システム、特定用途集積回路（ＡＳＩＣ）のようなディスクリート論理コンポーネント等、およびそのあらゆる組み合わせを含むことができる。

用語の使用に関して、「構成される」(configured)という句は、識別された動作を実行するようにあらゆる種類の機能性を組み立てることができるあらゆる方法を含む。機能性は、例えば、ソフトウェア、ハードウェア、ファームウェア等、またはそのあらゆる組み合わせを用いて、動作を実行するように構成することができる。

「論理」という用語は、タスクを実行するあらゆる機能性を含む(encompass)。例えば、フローチャートに示される各動作は、その動作を実行するロジックに対応する。動作は、例えば、ソフトウェア、ハードウェア、ファームウェア等、またはそのあらゆる組み合わせを用いて、実行することができる。

本明細書において用いる場合、「コンポーネント」、「システム」、「クライアント」等の用語は、ハードウェア、ソフトウェア（例えば、実行中）、および／またはファームウェア、あるいはその組み合わせのいずれかである、コンピューター関係エンティティを指すことを意図している。例えば、コンポーネントは、プロセッサー上で実行するプロセス、オブジェクト、実行可能ファイル、プログラム、機能、ライブラリ、サブルーティン、および／またはコンピューター、あるいはソフトウェアおよびハードウェアの組み合わせであることができる。

例示として、サーバー上で実行するアプリケーション、およびこのサーバーの双方がコンポーネントであることができる。１つ以上のコンポーネントがプロセス内に存在することができ、１つのコンポーネントが１つのコンピューター上に遍在されること、および／または２つ以上のコンピューター間で分散されることも可能である。「プロセッサー」という用語は、一般に、コンピューター・システムの処理ユニットのような、ハードアウェア・コンポーネントを指すように理解される。

更に、特許請求する主題は、方法、装置、あるいは開示する主題を実現するようにコンピューターを制御するためのソフトウェア、ファームウェア、ハードウェア、またはこれらのあらゆる組み合わせを生成するための、標準的なプログラミングおよび／または設計技法を用いる製造品目として実現することができる。「製造品目」という用語は、本明細書において用いられる場合、あらゆる有形コンピューター読み取り可能記憶デバイスまたは媒体からアクセス可能なコンピューター・プログラムを含むことを意図している。

コンピューター読み取り可能記憶媒体は、記憶デバイス（例えば、とりわけ、ハード・ディスク、フロッピー（登録商標）・ディスク、および磁気帯状体）、光ディスク（例えば、とりわけ、コンパクト・ディスク（ＣＤ）、およびディジタル・バーサタイル・ディスク（ＤＶＤ））、スマート・カード、およびフラッシュ・メモリ・デバイス（例えば、とりわけ、カード、スティック、およびキー・ドライブ）を含む。対照的に、コンピューター読み取り可能媒体（即ち、記憶媒体ではない）は、加えて、通信信号等のための送信媒体というような通信媒体を含むことができる。

更に、「例示の」(exemplary)という用語は、本明細書では、例(example)、実例(instance)、または例示として役割を果たすこと意味するために用いられる。本明細書において「例示の」と記述される態様または設計はいずれも、他の態様または設計よりも好ましいとも、有利であるとも必ずしも解釈される必要はない。

計算環境
特許請求する主題の種々の態様を実現するためのコンテキストを示すために、図１および図２ならびに以下の論述は、本発明(subject innovation)の種々の態様を実現することができる計算環境の端的な総合的な説明を行うことを意図している。例えば、アプリケーションのライセンスを供与する方法およびシステムは、このような計算環境において実現することができる。以上では、ローカル・コンピューターまたはリモート・コンピューター上で実行するコンピューター・プログラムのコンピューター実行可能命令という一般的なコンテキストで、特許請求する主題について説明したが、本発明は、他のプログラム・モジュールと組み合わせて実現することも可能であることは当業者には認められよう。一般に、プログラム・モジュールは、ルーチン、プログラム、コンポーネント、データ構造等を含み、特定のタスクを実行するか、または特定の抽象データ型を実装する。

更に、本発明は、単一プロセッサーまたは多重プロセッサー・コンピューター・システム、ミニコンピューター、メインフレーム・コンピューター、更にはパーソナル・コンピューター、ハンドヘルド計算デバイス、マイクロプロセッサー・ベースまたはプログラマブル消費作用電子機器というような、他のコンピューター・システム構成とでも実施できることは当業者には認められよう。これらの各々は、１つ以上の関連するデバイスと動作的に通信することができる。特許請求する主題の図示する態様は、分散型計算環境においても実施することができ、この場合、ある種のタスクは、通信ネットワークを介してリンクされるリモート処理デバイスによって実行される。しかしながら、本発明の態様は、全てでないにしろその一部は、単体コンピューター上でも実施することができる。分散型計算環境では、プログラム・モジュールはローカルまたはリモート・メモリ記憶デバイスに配置されてもよい。

図１は、本明細書において説明するライセンシング・サービスを実現するために用いることができるネットワーキング環境１００のブロック図である。ネットワーキング環境１００は、１つ以上のクライアント１０２を含む。クライアント１０２は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、または計算デバイス）とすることができる。また、ネットワーキング環境１００は、1つ以上のサーバー１０４も含む。サーバー（１つまたは複数）１０４は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、または計算デバイス）とすることができる。サーバー１０４は、例えば、本発明を採用することによって、検索動作を実行するためのスレッドを収容することができる。

クライアント１０２とサーバー１０４との間における可能な通信の１つは、２つ以上のコンピューター・プロセス間で送信されるように構成されたデータ・パケットの形態にすることができる。ネットワーキング環境１００は、クライアント（１つまたは複数）１０２とサーバー（１つまたは複数）１０４との間における通信を容易にするために採用することができる通信フレームワーク１０８を含む。クライアント（１つまたは複数）１０２は、１つ以上のクライアント・データ・ストア（１つまたは複数）１１０に動作可能に接続される。クライアント・データ・ストア１１０は、クライアント（１つまたは複数）１０２にローカルな情報を格納するために採用することができる。クライアント・データ・ストア（１つまたは複数）１１０は、クライアント（１つまたは複数）１０２内に格納することができ、クラウド・サーバー内にというように、離れて配置させてもよい。同様に、サーバー（１つまたは複数）１０４は、１つ以上のサーバー・データ・ストア（１つまたは複数）１０６に動作可能に接続される。サーバー・データ・ストア１０６は、サーバー１０４にローカルな情報を格納するために採用することができる。

図２は、本明細書において説明するライセンシング・サービスを実現するために用いることができる計算環境のブロック図である。計算環境２００は、コンピューター２０２を含む。コンピューター２０２は、処理ユニット２０４、システム・メモリ２０６，およびシステム・バス２０８を含む。システム・バス２０８は、システム・メモリ２０６から処理ユニット２０４までを含むがこれらに限定されないシステム・コンポーネントを結合する。処理ユニット２０４は、種々の入手可能なプロセッサーの内いずれでも可能である。デュアル・マイクロプロセッサーおよび他のマルチプロセッサー・アーキテクチャーも、処理ユニット２０４として採用することができる。

システム・バス２０８は、様々なタイプのバス構造の内いずれでも可能であり、メモリ・バスまたはメモリー・コントローラー、周辺バスまたは外部バス、あるいは当業者には知られている種々の入手可能なバス・アーキテクチャーの内いずれでも含まれる。システム・メモリ２０６は、揮発性メモリ２１０および不揮発性メモリ２１２を含む、コンピューター読み取り可能記憶媒体である。起動中のように、コンピューター２０２内部でエレメント間で情報を転送するための基本的なルーチンを収容する基本入力／出力システム（ＢＩＯＳ）が、不揮発性メモリ２１２に格納される。例示として、そして限定ではなく、不揮発性メモリ２１２は、リード・オンリー・メモリ（ＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、電気的プログラマブルＲＯＭ（ＥＰＲＯＭ）、電気的消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ）、またはフラッシュ・メモリを含むことができる。

揮発性メモリ２１０は、外部キャッシュ・メモリとして機能する、ランダム・アクセス・メモリ（ＲＡＭ）を含む。一例としてそして限定ではなく、ＲＡＭは、スタティックＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、同期ＤＲＡＭ（ＳＤＲＡＭ）、データ倍速ＳＤＲＡＭ（ＤＤＲＳＤＲＡＭ）、拡張ＳＤＲＡＭ（ＥＳＤＲＡＭ）、シンクリンク(SynchLink（登録商標）)DRAM(SLDRAM)、ランバス（Rambus（登録商標）直接ＲＡＭ（ＲＤＲＡＭ）、直接ランバス（登録商標）ダイナミックＲＡＭ（ＤＲＤＲＡＭ）、およびランバス（登録商標）ダイナミックＲＡＭ（ＲＤＲＡＭ）というような、多くの形態で入手可能である。

また、コンピューター２０２は、リムーバブル／非リムーバブル、揮発性／不揮発性コンピューター記憶媒体というような、他のコンピューター読み取り可能記憶媒体も含む。図２は、例えば、ディスク・ストレージ２１４を示す。ディスク・ストレージ２１４は、磁気ディスク・ドライブ、フロッピー（登録商標）・ディスク・ドライブ、テープ・ドライブ、ジャズ・ドライブ(Jaz drive)、ジップ・ドライブ(Zip drive)、ＬＳ−１００ドライブ、フラッシュ・メモリ・カード、またはメモリ・ディスクを含むが、これらに限定されるのではない。

加えて、ディスク・ストレージ２１４は、別々に、または他の記憶媒体と組み合わせて、記憶媒体を含むことができ、コンパクト・ディスクＲＯＭドライブ（ＣＤ−ＲＯＭ）のような光ディスク・ドライブ、ＣＤ記録可能ドライブ（ＣＤ−Ｒドライブ）、ＣＤ−上書き可能ドライブ（ＣＤ−ＲＷドライブ）、またはディジタル・バーサタイル・ディスクＲＯＭドライブ（ＤＶＤ−ＲＯＭ）を含むがこれらに限定されるのではない。ディスク・ストレージ２１４のシステム・バス２０８への接続を容易にするために、インターフェース２１６のような、リムーバブルまたは非リムーバブルインターフェースが通例用いられる。

尚、図２は、ユーザーと、計算環境２００において説明する基本的なコンピューター・リソースとの間における仲介として機能するソフトウェアを説明することは認められてしかるべきである。このようなソフトウェアは、オペレーティング・システム２１８を含む。オペレーティング・システム２１８は、ディスク・ストレージ２１４上に格納することができ、コンピューター２０２のリソースを制御し割り当てるように機能する。

システム・アプリケーション２２０は、システム・メモリ２０６またはディスク・ストレージ２１４のいずれかに格納されたプログラム・モジュール２２２およびプログラム・データ２２４を使用する、オペレーティング・システム２１８によるリソースの管理を利用する。尚、特許請求する主題は、種々のオペレーティング・システムまたはオペレーティング・システムの組み合わせとでも実現できることは認められてしかるべきである。

ユーザーは、入力デバイス２２６を介して、コマンドまたは情報をコンピューター２０２に入力する。入力デバイス２２６は、ポインティング・デバイス（マウス、トラックボール、スタイラス等）、キーボード、マイクロフォン、ジェスチャーまたはタッチ入力デバイス、音声入力デバイス、ジョイスティック、衛星ディッシュ、スキャナー、ＴＶチューナ・カード、ディジタル・カメラ、ディジタル・ビデオ・カメラ、ウェブ・カメラ等を含むが、これらに限定されるのではない。入力デバイス２２６は、インターフェース・ポート（１つまたは複数）２２８を介して、システム・バス２０８によって処理ユニット２０４に接続する。インターフェース・ポート（１つまたは複数）２２８は、例えば、シリアル・ポート、パラレル・ポート、ゲーム・ポート、およびユニバーサル・シリアル・バス（ＵＳＢ）を含む。また、出力デバイス（１つまたは複数）２３０も、入力デバイス（１つまたは複数）２２６と同じタイプのポートを用いることができる。つまり、例えば、ＵＳＢポートが入力をコンピューター２０２に供給するため、そしてコンピューター２０２からの情報を出力デバイス２３０に出力するために用いられてもよい。

出力アダプター２３２が、出力デバイス２３０の中でもとりわけ、モニター、スピーカー、およびプリンターというような出力デバイス２３０があることを例示するために設けられる。これらは、出力アダプター２３２を介してアクセス可能である。出力アダプター２３２は、例示としてそして限定ではなく、出力デバイス２３０とシステム・バス２０８との間に接続の手段を設けるビデオおよびサウンド・カードを含む。尚、他のデバイスおよび／またはデバイスのシステムが、リモート・コンピューター（１つまたは複数）２３４のように、入力および出力双方の能力を設けることは、認めることができよう。

コンピューター２０２は、ネットワーキング環境１００のようなネットワーキング環境において、リモート・コンピューター（１つまたは複数）２３４のような１つ以上のリモート・コンピューターへの論理接続を用いて、イベント予想システムをホストするサーバーであることができる。リモート・コンピューター（１つまたは複数）２３４は、ウェブ・ブラウザー、ＰＣアプリケーション、移動体電話アプリケーション等が構成されたクライアント・システムであってもよい。リモート・コンピューター（１つまたは複数）２３４は、パーソナル・コンピューター、サーバー、ルーター、ネットワークＰＣ、ワークステーション、マイクロプロセッサー・ベース・アプライアンス、移動体電話機、ピア・デバイスまたは他の共通ネットワーク・ノード等とすることができ、通例、コンピューター２０２に関して説明したエレメントの多くまたは全てを含む。簡潔さのために、リモート・コンピューター（１つまたは複数）は、メモリ記憶デバイス２３６と共に示される。リモート・コンピューター（１つまたは複数）２３４は、論理的にコンピューター２０２にネットワーク・インターフェース２３８を介して接続され、物理的に通信接続２４０を介して接続される。

ネットワーク・インターフェース２３８は、ローカル・エリア・ネットワーク（ＬＡＮ）およびワイド・エリア・ネットワーク（ＷＡＮ）のような、有線および／またはワイヤレス通信ネットワークを含む(encompass)。ＬＡＮ技術は、ファイバー分散型データ・インターフェース（ＦＤＤＩ）、銅分散型データ・インターフェース（ＣＤＤＩ）、イーサネット（登録商標）、トークン・リング等を含む。ＷＡＮ技術は、二点間リンク、統合サービス・ディジタル・ネットワーク（ＩＳＤＮ）およびその変形というような回線交換ネットワーク、パケット交換ネットワーク、およびディジタル加入者回線（ＤＳＬ）を含むが、これらに限定されるのではない。

通信接続（１つまたは複数）２４０は、ネットワーク２３８をシステム・バス２０８に接続するために採用されるハードウェア／ソフトウェアを指す。通信接続２４０は、例示を明確にするために、コンピューター２０２内部に示されるが、コンピューター２０２の外部にあることも可能である。ネットワーク・インターフェース２３８への接続のためのハードウェア／ソフトウェアは、例えば、移動体電話スイッチのような内部および外部技術、通常の電話級モデム、ケーブル・モデム、およびＤＳＬモデムを含むモデム、ＩＳＤＮアダプター、ならびにイーサネット（登録商標）・カードを含むことができる。

ライセンシング・システム
図３Ａ、図３Ｂ、および図３Ｃは、アプリケーションのライセンスを管理するために用いることができるライセンシング・システム３００の模式図である。ライセンシング・システム３００について、オフィス・アプリケーションまたはオフィスを介して利用可能なアプリケーションのライセンスを管理するために用いられるオフライン・ライセンシング・サービス（ＯＬＳ）３０２に関して説明する。しかしながら、ライセンシング・システム３００は、他の適したタイプのアプリケーションまたはサービスであればいずれを管理するためにでも、用いてもよいことは理解されてしかるべきである。

ライセンシング・システム３００は、多数の同期プロバイダー３０４Ａ〜３０４Ｄを含むことができる。同期プロバイダー３０４Ａ〜３０４Ｄは、ＯＬＳ３０２の変更を行うことなく、ライセンシング・システム３００の拡張を可能にするプラガブル・コンポーネント(pluggable component)である。同期プロバイダー３０４Ａ〜３０４Ｄは、多数のコマース・パートナーにＯＬＳ３０２と相互作用させることができる。例えば、図３Ａに示すように、マイクロソフト・オンライン(MSOnline)同期プロバイダー３０４Ａは、ＯＬＳ３０２とMSOnlineパートナー３０６Ａとの間における相互作用を考慮することができる。オフィス・マーケットプレース体験（ＯＭＥＸ）同期プロバイダー３０４Ｂは、ＯＬＳ３０４とＯＭＥＸパートナー３０６Ｂとの間における相互作用を考慮することができる。ポイント・オブ・セールス・アクティベーション（ＰＯＳＡ）同期プロバイダー３０４Ｃは、ＯＬＳ３０２とＰＯＳＡパートナー３０６Ｃとの間における相互作用を考慮することができる。

加えて、クライアント同期プロバイダー３０４Ｄは、ＯＬＳ３０２とクライアント計算デバイス３０８との間における相互作用を考慮することができる。クライアント計算デバイス３０８は、ＯＬＳ３０２を用いてライセンシング・システム３００を介して特定のアプリケーションまたはサービスのユーザーにライセンスすることができるデスクトップ・コンピューターまたはラップトップ・コンピューターというような、適したタイプの計算デバイスであればいずれでもよい。更に、あらゆる数の追加の同期プロバイダーを用いて、あらゆる数の新たなコマース・パートナーでもライセンシング・システム３００に統合することもできる。

図３Ａに示すように、各同期プロバイダー３０４Ａ、３０４Ｂ、３０４Ｃ、および３０４Ｄは、それぞれのパートナー３０６Ａ、３０６Ｂ、３０６Ｃ、および３０８Ｄによって要求されるアクションを実行するために１つ以上のコンポーネントを含むことができる。加えて、各同期プロバイダー３０４Ａ、３０４Ｂ、３０４Ｃ、および３０４Ｄは、矢印３１２Ａ、３１２Ｂ、３１２Ｃ、および３１２Ｄによってそれぞれ示されるように、ＯＬＳ３０２内部において１つ以上のプロビジョニング・アプリケーション・プログラミング・インターフェース（ＡＰＩ）３１０と相互作用することもできる。プロビジョニングＡＰＩ３１０は、プロビジョニング・アクションを実行するためにＯＬＳ３０２によって用いられる。同期プロバイダー３０４Ａ〜３０４Ｄのような、プロビジョニングＡＰＩ３１０をコールするソースは、総じて、信頼されるソースであると仮定する。

ＯＬＳ ＡＰＩ
ＯＬＳ３０２は、多数のＯＬＳ ＡＰＩ３１４を含むことができ、これらはＯＬＳから情報を引き出すため、更にはクライアント計算デバイス３０８に情報を送るおよび情報を受信するために用いられる。ＯＬＳ ＡＰＩ３１４は、矢印３１８Ａおよび３１８Ｂによって示されるように、クライアント計算デバイス３０８のオフィス・ライセンシング・クライアント（ＯＬＣ）３１６によってコールされればよい。また、ＯＬＳ ＡＰＩ３１４は、矢印３２２Ａ、３２２Ｂ、および３２２Ｃによって示されるように、マシンまたはライセンシング情報をＯＬＳ３０２に送るまたはＯＬＳ３０２から得ることを望むあらゆるサービスまたはウェブサイト３２０Ａおよび３２０Ｂによってコールされてもよい。ＯＬＳ ＡＰＩ３１４は、例えば、プロダクト・キーまたはユーザーのプロビジョニング・ステータスをチェックする、またはプロダクト・キーを引き出すというようなアクションを実行することができる。

実施形態では、２組のＯＬＳ ＡＰＩ３１４がある場合もあり、インターネットを通じてアクセス可能でＯＬＣによってコールされる公開バージョンと、ある種の信頼されるパートナーのみがアクセス可能でこれらのパートナーによってコールされる秘密バージョンとを含む。ＯＬＳ ＡＰＩ３１４の公開バージョンと秘密バージョンとの間における主要な相違は、秘密バージョンが、ユーザー信任状ではなく個人情報としてパスポート一意ＩＤ（ＰＵＩＤ）を受け入れることができ、秘密バージョンが、公開バージョンとは異なるサーバーを用いて異なるエンド・ポイントとして実現できることである。

クライアント計算デバイス３０８のＯＬＣ３１６は、ＯＬＳ３０４と通信する、ＯＳＰＰ３２４を通じてライセンスをアクティベートする、ＵＩとインターフェースする、およびクライアント計算デバイス３０８上でオフィス３２６を実行する許可を与えるというような、クライアント側ライセンシング機能を扱うクライアント側コンポーネントである。また、ＯＬＣ３１６は、矢印３２８Ａおよび３２８Ｂによってそれぞれ示されるように、情報をＰＯＳＡ同期プロバイダー３０４Ｃおよびクライアント同期プロバイダー３０４Ｄに送ることもできる。例えば、ＯＬＣ３１６は、クライアント計算デバイス３０８のライセンスに関するデータを、クライアント同期プロバイダー３０４Ｄにプッシュすることができる。

種々の実施形態において、ＯＬＣ３１６は、個人情報プラットフォーム３３０とも通信する。個人情報プラットフォーム３３０は、ユーザーのオフィス・マーケットプレースＩＤ、即ち、ライブＩＤのような、ユーザーの個人情報に関する情報を含むことができる。このような情報は、クライアント計算デバイス３０８上でオフィス３２６をアクティベートするために用いることができる。

ＯＬＣ３１６は、ユーザーまたはクライアントがライブＩＤまたはＢＰＯＳ ＩＤを用いてオフィス３２６をアクティベートしたか否か確認することができる。これは、コンテキスト特定ユーザーの使用を可能にするとよい。例えば、ライブＩＤ ＵＩはＢＰＯＳ ＵＩとは異なってもよい。加えて、ＯＬＣ３１６が、ダウンロード場所またはオフィス３２６をインストールするために用いられたＣＤにしたがって、どのＵＩをユーザーに表示するか決定できるのでもよい。

ＯＬＳ ３０２は、プロダクト・キー・キャッシュ・サービス３２２と、プロダクト・キー・キャッシュ３３４とを含むことができる。プロダクト・キー・キャッシュ３３４は、ＯＬＳ３０２によって用いられるプロダクト・キーの規則的に満たされるキャッシュであってもよい。プロダクト・キー・キャッシュ・サービス３３２は、矢印３３８によって示されるように、プロダクト・キーをプロダクト・キー記憶データベース３３６から引き出すように構成されるとよい。

ＯＬＳ３０２は、プロビジョニング解除サービス(deprovisioning service)３４０も含むことができる。プロビジョニング解除サービス３４０は、矢印３４４によって示されるように、アクティベーション検証システム（ＡＶＳ）との通信によって、ＯＬＳにおいて解除されたプロダクト・キーをチェックする非同期サービスとすることができる。プロビジョニング解除サービス３４０は、ＡＶＳ３４２を通じて解除されたプロダクト・キーに関連付けられたライセンスを周期的にディアクティベートすることもできる。

ライセンシング・システム３００は、不正検出システム３４６も含むことができる。不正検出システムは、不正検出サービス３４８と、不正検出データベース３５０とを含むことができる。不正検出サービス３４８は、関連データを不正検出データベース３５０に、ＯＬＳ３０２のライセンシング・ストア３５２から定期的に同期させることができる。不正検出サービス３４８は、矢印３５６によって示されるように、ＯＬＳ３０２のデータ・アクセス・レイヤ３５４を通じてライセンシング・ストア３５２からデータを得ることができる。不正検出サービス３４８は、次いで、ＯＬＳ３０２からのデータを別個に分析し、こうしてＯＬＳ３０２上の負荷を低減することができる。種々の実施形態では、ＯＬＳ３０２とは別々に不正検出システム３４６を実装することにより、ＯＬＳ３０２を変更することなく、不正検出システム３４６のコンポーネントのアップグレードを行うこともできる。

オフィスに対するライセンシング・サービスの使用
この章では、オフィス、更に特定すれば、オフィス２０１３（オフィス１５としても知られる）について本明細書において説明するライセンシング・サービス（またはＯＬＳ）の使用の様々な実施形態例を示す。オフィス２０１３では、ＯＬＳは業務用生産性オンライン・スイート（ＢＰＯＳ）登録および消費者登録というような、種々のライセンシング・モデルをサポートすることができ、「ＢＰＯＳ」という用語は、マイクロソフト・オンラインおよびマイクロソフト３６５と相互交換可能に用いられる。また、ＯＬＳは旧来の永続的ライセンシング、試行ライセンシング、およびキー無しライセンシング、即ち、信任状に基づくライセンシング、更には種々のモデル間の変換(conversion)もサポートすることができる。更に、ＯＬＳは、相手先商標製造（ＯＥＭ）プリロード(preload)、ＣＤ、および電子ソフトウェア流通（ＥＳＤ）というような、異なる配信方法のコンテキストにおける異なるモデルもサポートすることができる。

オフィス２０１３においてＯＬＳによってサポートされる種々のライセンシング・モデルは、オフィス２０１３の鍵となる業務優先事項である。これら種々のモデルの全てを扱うことができる１つのシステムがあると、オフィス２０１３のオーバーヘッドおよび複雑さを低減することができる。

ＢＰＯＳのシナリオ
ＢＰＯＳのシナリオとは、業務に的を絞ったシナリオである。このようなシナリオは、通例、アドミニストレーター（アドミン）を伴い、結果的に得られるライセンスは、エンド・ユーザーではなく組織に関連付けられる。したがって、アドミンは、組織内において１人のユーザーからライセンスを引き取り(take away)、他のユーザーにそれを割り当てることができるとよい。更に、ＢＰＯＳのシナリオは登録のみを含むのでもよい。

以下は、ＢＰＯＳのシナリオについての、登録の購入およびプロビジョニングの様々な実施形態例の説明である。このような実施形態によれば、ある会社の所有者が彼の従業員のためのＢＰＯＳの一部として、８人のユーザー・ライセンスを含むＢＰＯＳおよびオフィス登録を購入する。この会社の情報技術（ＩＴ）アドミンは、８人の従業員の各々にＢＰＯＳ信任状を含むアカウントを作成する。次いで、ＩＴアドミンは、従業員毎にオフィスのユーザー・ライセンスをプロビジョニングする。

マシンが１台のユーザー
従業員が、これよりオフィス２０１３を使用できることを伝える電子メールをＩＴアドミンから受信する。この電子メールは、Office.comへのリンクを有し、彼女の使用のために利用できる製品およびサービスについての情報を提供する。この従業員は、この電子メール・リンク上でクリックし、彼女のＢＰＯＳ信任状を用いてサインインするように求められ、オフィス２０１３を起動するためのリンクを確認する。この従業員は、このリンク上でクリックし、瞬時にオフィス２０１３が開始する。オフィス２０１３が起動すると、従業員は、オフィス２０１３をアクティベートするために彼女の信任状を検証するように求められる。

マシンが多数台のユーザー
前述の従業員がOffice.comを訪問すると、彼女は、登録が２台までのマシンにオフィス２０１３をインストールすることを許可することを習得する。このため、従業員は第２のマシンからOffice.comにサインインして、同じ手順を用いて、第２のマシンにおいてオフィスをインストールし起動する。

この従業員は、彼女が２台のマシンにおいてオフィスを使用する権利しかないことを知っているが、第３のマシンにそれをインストールして実行しようとすると何が起こるか確認する決心をする。従業員は同じ手順に従い、オフィスが起動する。しかしながら、この時点で、従業員には、オフィスによって、彼女が既に２台の他のマシンにおいて彼女のライセンスを使用したことを知らされる。従業員には、彼女がオフィスをインストールしたマシンのリストが提示され、続けるためには他のマシンの１つから彼女のライセンスを削除するように促される。リストから削除するマシンを選択する代わりに、彼女は取り消すことを決める。従業員は、なおも一定の日数の間第３のマシンにおけるオフィスのインストールを使用することができるかもしれない。何故なら、登録ライセンスが猶予期間を考慮する場合もあるからである。従業員が既存の２台のマシンの１つから彼女のライセンスを削除することを選択したのであれば、そのマシンにおけるライセンスが削除され、彼女は第３のマシンにおいて彼女のライセンスをアクティベートできたであろう。

ユーザーへのプロビジョニングの解除
数ヶ月後、従業員は一時的な休暇を取る。所有者は、この従業員が休暇を取っている間、一時契約の作業員を雇用することを決心する。契約作業員の最初の作業日の前に、この会社のＩＴアドミンは従業員のＢＰＯＳアカウントをディアクティベートし、契約作業員のアカウントを作成し、契約作業員にオフィスをプロビジョニングする。

契約作業員の最初の作業日に、彼には従業員のコンピューターと、彼に作られたアカウントとが与えられる。オフィスを開始すると、契約作業員には、彼のマシンにおける現在のオフィス・ライセンスは終了していること、そしてオフィスを使用し続けるためには、他のアカウントを提示しなければならないことが伝えられる。契約作業員は、彼のアカウント情報を入力し、オフィスを正常に使用することができる。契約作業員が彼のアカウントを提示しなかった場合でも、猶予期間があるかもしれず、その間彼はオフィスを使用し続けることができた。

登録更新
約１年が過ぎた後、会社の所有者は更新通知電子メールを受信する。所有者は、登録をもう１年延長することを決める。所有者は、登録を更新するために、Office.comを訪問する。その間、従業員は、オフィスの中断のない使用を体験することができる。

大企業のシナリオ
大企業のシナリオは、ＢＰＯＳのシナリオと本質的に同じである。しかしながら、大企業のシナリオは、フェデレーション設定を含むことができ、ユーザーが現在彼らのドメインにサインインしている場合に恐らくはサイレント認証を使用していても、ユーザーが彼のドメイン信任状によってオフィスをアクティベートすることを許可する。

以下は、大企業のシナリオについて登録の購入およびプロビジョニングの様々な実施形態例の説明である。このような実施形態によれば、会社の補充品管理者は作業のために頻繁に移動する。彼は、時として、彼のコンピューターを持たず、彼の供給業者から借りることができるものを借りる。彼は、会社のＩＴアドミンがオフィスをプロビジョニングした従業員の１人である。

ユーザーがオフィス・アプリケーションを未知のマシンにローミングする
補充品管理者が他の会社に出向くとき、彼は彼のラップトップを忘れた。しかしながら、彼は作業していたスプレッドシートにアクセスすることを望む。幸い、彼は、会社のオフィス登録が、いつでもどこでもオフィスにアクセスすることを彼に許可することを思い出す。補充品管理者は、他の会社においてＩＴ管理者からラップトップを借りて、Office.comにログインする。Office.comを通じて、補充品管理者は、一時的な使用のためにエクセルを起動することができ、そしてスプレッドシートを引き出すことができる。その日の作業終了時に、補充品管理者は、ラップトップを他の会社に返還する。

ラップトップを受け取ったときに、他の会社のＩＴ管理者は、補充品管理者のスプレッドシートまたはオフィスの痕跡がラップトップにないことを発見して驚く。これは、不正を防止するために、１日当たりオフィスを開くことができる回数が監視され制限されるという事実による。

補充品管理者は、エクセルを起動するとき、彼の信任状を催促されるかもしれず、またはOffice.comが覚えているかもしれない。Office.comは、補充品管理者が、彼が現在使用しているマシン上にオフィスを有するか否か知ることができる。ＢＰＯＳウェブサイトは、補充品管理者が特定のマシンをプロビジョニングすること、またはそのマシンにおいてオフィスを一時的に使用することという選択肢を有することができる。場合によっては、オフィスがマシン上に残るのでもよい。しかしながら、他の会社のＩＴ管理者がオフィスをブートするとき、彼は、オフィスを使用することが許可される前に、信任状を催促される。

オフィス２０１０からオフィス２０１３への登録アップグレード
会社は、ＢＰＯＳオフィス２０１０（またはオフィス１４）登録を数年間使用しており、所有者はそれにとても満足している。数日前、所有者は、オフィス２０１３が会社の登録の一部としてアップグレードのために入手可能であることを彼およびＩＴアドミンに注意する電子メールを受信した。また、所有者には、彼の現在インストールされているオフィス２０１０は動作し続けるが、あと１年だけであることも知らされる。

ＩＴアドミンは、ＢＰＯＳアドミニストレータ・ウェブサイトに行き、会社の従業員をオフィス２０１３にアップグレードする。すると、各従業員はオフィス２０１３をダウンロードする説明書がある電子メールを受信する。

補充品管理者は、この電子メールを受信し、電子メールからOffice.comへのリンク上でクリックする。彼は、ＢＰＯＳ信任状でサインインするように求められ、オフィス１５を起動するためのリンクを確認する。彼は、このリンク上でクリックし、オフィスが瞬時に開始する。オフィスが起動すると、オフィスをアクティベートするために彼の信任状を検証するように求められる。一方、会社の会計係はこの電子メールを無視し、オフィス２０１０を使用し続ける。１年後、会計係がインストールしたオフィス２０１０は動作しなくなるが、補充品管理者がインストールしたオフィス２０１３は動作し続ける。

オフィス・マーケットプレース（ＯＭＥＸ）のシナリオ
ＯＭＥＸのシナリオは、エンド・ユーザーに的を絞る。このようなシナリオによれば、エンド・ユーザーはOffice.comまたはオフィス２０１３のバックステージ(backstage)を通じてオフィスを購入する。このようなシナリオは、永続的および登録ライセンスの双方を含むことができる。ライセンシング・ユーザー・インターエース（ＵＩ）が、ユーザーがＢＰＯＳのシナリオまたはＯＭＥＸのシナリオのどちらに関連付けられるのか判断することができるのでもよく、しかるべきＵＩを表示するとよい。

ユーザーがOffice.comを通じてオフィスの旧バージョンからアップグレードする
以下は、オフィスの旧バージョン、即ち、既存バージョンからユーザーがOffice.comを通じてアップグレードするシナリオの一例である。ユーザーは、彼のコンピューターにおいて家庭および学生用オフィス２０１０を使用してきたが、現在最新バージョンを購入することを望む。ユーザーはOffice.comに行き、選択を提案される。ユーザーは登録を購入することを決める。ライブＩＤを作成し、登録に対して支払いを済ませた後、ユーザーはオフィス２０１３を起動する。警報が画面上に現れて、ユーザーが彼のマシンにオフィスの古い方のコピーがあることをユーザーに警告する。ユーザーが継続したいことを確認した後、オフィス２０１０が安全にアンインストールされ、新たなバージョンが起動する。ユーザーは、彼が登録を購入したときの信任状を催促される。ユーザーは彼の信任状を入力し、オフィスを正常に使用することができる。

実施形態では、オフィス２０１３がユーザーに、オフィス２０１３をダウンロード／起動するかまたはオフィス２０１３を起動するかについて選択肢を提示する場合がある。信任状の催促をユーザーに強要しないように、信任状を覚えておき、自動的にインターネットからオフィス２０１３に渡されるのでもよい。例えば、ダウンロードのサイトが安全確保される場合、実際のプロダクト・キーをファイル名に挿入することもできる。しかしながら、信任状を渡すことができても、ユーザーにサインインして彼らの信任状を検証するように強制することが望ましい場合もある。場合によっては、Office.comから購入するユーザーはライブＩＤ(Live ID)を有すると仮定してもよい。プロダクト・キーは、ユーザーのオフィスの旧コピー上にバックアップすることもできる。

ユーザーがOffice.comを通じてオフィス登録ライセンスを購入する
このシナリオは、ユーザーがOffice.comを通じてオフィスの旧バージョンからアップグレードするシナリオと同じであるが、マシン上に旧バージョンがないので、オフィスの旧バージョンに関する警告がないことを除く。種々の実施形態において、ユーザーは、特定のマシンの最初のアクティべーションの後、彼の信任状を求められない。代わりに、その後のアクティベーションはMachineKeyを介して行われる。

ユーザーがOffice.comを通じてオフィスの永続ライセンスを購入する
このシナリオは、ユーザーがOffice.comを通じてオフィスの旧バージョンからアップグレードするシナリオと同じであるが、マシン上に旧バージョンがないので、オフィスの旧バージョンに関する警告がないことを除く。個々の実例に応じて、ユーザーがプロダクト・キーを確認することができてもできなくてもよい。ユーザーは、彼のログイン情報を用いて、永続ライセンスをアクティベートすることが許可されてもよい。移転(transfer) のシナリオは、個々の実例に応じて、多数の異なる方法で扱うことができる。例えば、ユーザーが彼のオフィスを他のユーザーに売りたい場合、彼は彼の信任状を新たなユーザーに与えなければならないであろう。また、贈与もサポートしてもよい。

ユーザーが第１コンピューター上でオフィス登録を所有するときに、ユーザーが第１コンピューター上のオフィス登録を第２コンピューターからOffice.comを通じてアップグレードする
このシナリオによれば、ユーザーは家庭および学生用オフィス２０１３を購入し、それを彼のデスクトップおよび彼のラップトップにインストールする。ユーザーは、オフィス２０１３プロフェッショナルにアップグレードすることを決める。デスクトップから、ユーザーはOffice.comに行き、登録をアップグレードする。Office.comにおいて、現在彼の家庭および学生用オフィス２０１３が登録されているコンピューターがリストに纏められ、ユーザーがこれらのコンピューターにおいてオフィスを起動すると、コンピューターがインターネットにアクセスできれば、これらのコンピューターはオフィス２０１３プロフェッショナルに自動的にアップグレードされることが知らされる。また、ユーザーには、今すぐデスクトップをアップグレードするためのリンクが与えられる。ユーザーは、直ちにこのリンク上でクリックし、彼の信任状を提示する。次いで、オフィスはデスクトップ上でオフィス２０１３プロフェッショナルにアップグレードする。

数日後、ユーザーは彼のラップトップ上でワード(Word)を起動する。ワードが起動すると、ユーザーには、ライセンシング変更が行われたことが知らされ、ユーザーには、今オフィス２０１３プロフェッショナルにアップグレードする、後でアップグレードする、または彼のマシンを登録から削除する選択肢が与えられる。ユーザーは、後でアップグレードすることを決める。１日後、ユーザーは再度ワードを起動し、同じ選択肢が与えられる。ユーザーは、その時点でアップグレードすることを決める。

種々の実施形態において、ユーザーがデスクトップ上でOffice.comを使用している場合、Office.comを通じてデスクトップを更新することができるのでもよい。場合によっては、ユーザーが「後でアップグレードする」選択肢を選択することが許されてもよい。他の場合では、アップグレードが直ちに強制されてもよい。「後でアップグレードする」が許される場合、ユーザーは、アップグレードが強制される前に、特定の回数だけこの選択肢を選択することが許されるのでもよい。ユーザーは、今すぐアップグレードするまたは削除するアクションのときに信任状を入力するように促されてもよい。

ユーザーが第１コンピューター上でオフィス登録を所有しないときに、ユーザーが第１コンピューター上のオフィス登録を第２コンピューターからOffice.comを通じてアップグレードする
このシナリオによれば、ユーザーが家庭および学生用オフィス２０１３を購入し、彼のデスクトップ上にそれをインストールする。ユーザーは、友人から中古のラップトップを購入する。彼の友人のオフィス２０１３プロフェッショナル登録が、この中古ラップトップ上で生きている(running)。ユーザーは、この中古ラップトップ上でオフィスを正常に使用することができる。ユーザーの友人は、彼のオフィス２０１３プロフェッショナル登録をラップトップから削除するのを忘れていたことを思い出し、したがってOffice.comに行き彼の登録からこのラップトップを削除する。

次回オフィスを開始すると、ユーザーには、彼のマシンにおける現在のオフィス・ライセンスが削除されたこと、そしてオフィスを使用し続けるためには他のアカウントを提示しなければならないことが知らされる。次いで、ユーザーは、彼の登録によってサポートされるオフィスのバージョンを使用するために、彼の信任状を入力することができる。

ユーザーが第１コンピューター上にオフィス登録を所有するときに、ユーザーが第１コンピューター上のオフィス・ライセンスを登録ライセンスから永続ライセンスに、第２コンピューターからOffice.comを用いて更新する
このシナリオは、ユーザーが第１コンピューター上に登録を所有するときに、ユーザーが、彼が第１コンピューター上で使用するオフィス登録を、第２コンピューターからOffice.comを通じてアップグレードするシナリオと同じである。しかしながら、他の登録ライセンスにアップグレードする代わりに、ユーザーは単に永続ライセンスにアップグレードする。

ユーザーが第１コンピューター上において登録を所有しないときに、ユーザーが第１コンピューター上におけるオフィス・ライセンスを登録ライセンスから永続ライセンスに、第２コンピューターからOffice.comを通じて更新する
このシナリオは、ユーザーが第１コンピューター上において登録を所有しないときに、ユーザーが、彼が第１コンピューター上で使用するオフィス登録を第２コンピューターからOffice.comを通じて更新するシナリオと同じである。しかしながら、他の登録にアップグレードする代わりに、ユーザーは永続ライセンスにアップグレードする。

ユーザーが第１コンピューター上において永続ライセンスを有するときに、ユーザーが第１コンピューター上におけるオフィス・ライセンスを永続ライセンスから登録ライセンスに、第２コンピューターからOffice.comを通じて変更する
ユーザーは、第１コンピューター上に家庭および学生用オフィスを有する。しかしながら、ユーザーは、彼がオフィス製品のもっと広い選択を望むことを発見する。ユーザーは、オフィス・プロフェッショナル登録を購入するために、第２コンピューターからOffice.comにログオンする。購入の終了時に、ユーザーには、オフィス・プロフェッショナルをダウンロードするためのリンクと、現在インストールされているバージョンのオフィスをどのように更新するかについての指示とが与えられる。

ユーザーは再度第１コンピューター上でOffice.comにログオンし、ダウンロード・リンク上でクリックする。第１コンピューター上にあるオフィスのコピーは、Office.comプロフェッショナルに更新される。ユーザーが再度Office.comを訪問しなかった場合、ユーザーは彼の現在インストールされている家庭および学生用オフィスのバックステージに行くことによって、更新を実行することができたであろう。例えば、ユーザーは、ライセンスを更新するまたは更新をチェックするためのボタン上でクリックすることができる。

後に、ユーザーは彼の登録を取り消す。最終的に、第１コンピューター上にあるプロフェッショナル登録は期限が切れて、家庭および学生用オフィスに逆戻りする。

現在のユーザーがライセンス供与されたユーザーとは異なる場合
ある小さな会社の所有者は、３人の従業員を有する。彼は、彼の従業員の各々にオフィスを使わせたい。Office.com上における登録の提案を検討した後、所有者は、各登録が、２台の異なるマシンにおいてオフィスを使用する権利を含むことを知る。しかしながら、所有者は、一度に１つの登録しか有することができないことを知る。このため、彼は、従業員の内１人にも登録を購入するように求め、彼が別個に支払う。所有者および従業員の１人は、彼らのそれぞれのコンピューターにオフィスをダンロードし、所有者の信任状を用いてこれをアクティベートする。２人の他の従業員は、彼らのそれぞれのコンピューターにオフィスをダウンロードし、従業員の信任状を用いてそれをアクティベートする。オフィスを個人専用にするために、従業員は引き続き彼ら自身のＩＤでログインし、これを正常に使用することができる。

実施形態では、各ユーザーが１つのオフィス登録だけしか有することができないと仮定してもよい場合もある。しかしながら、場合によっては、ユーザーが、オフィス・プロフェッショナルの登録だけでなく、家庭および学生用オフィスの登録も有してもよい場合もある。また、ユーザーが、同じ登録の多数のバージョン、または多数の永続ライセンスを有することもできる。

ユーザーが登録ライセンスをＢＰＯＳライセンスに変換する
ある小さな会社の所有者は、３人の従業員を有する。所有者および従業員の内１人は、両者とも、２台までのマシンにオフィスのインストールを許可するオフィス・プロフェッショナル登録を有する。他の２人の従業員は、各々、これらの登録の一方を用いて、彼らのマシンにオフィスをインストールする。

所有者は、最近５人の新たな従業員を雇った。情報をオンラインで読んで、ＢＰＯＳ登録の方が彼の望みに合うと判断する。所有者はOffice.comに行き、彼の登録をＢＰＯＳ登録に変換し(convert)、９個のライセンスを購入する（会社の全員に十分である）。

所有者は、彼の従業員の各々にＢＰＯＳアカウントを与え、各々にオフィスをプロビジョニングする。各従業員がオフィスを起動すると、現在彼のマシンにおけるライセンスはもはや有効ではないこと、そしてオフィスを使用し続けるためには他のアカウントを提示しなければならないことが、彼に知らされる。このため、各従業員は彼らのＢＰＯＳ ＩＤを入力し、次いでオフィスを正常に使用することができる。更に、実施形態では、従業員が直ちに他のアカウントを提示しない場合、猶予期間が設けられる。

ある小さな会社の所有者は、１０人の従業員を有する。所有者は、従業員のマシン毎に、家庭および業務用オフィスの永続ライセンスを既に購入した。しかしながら、オンラインで情報を読んで、所有者は、オフィス・プロフェッショナル・プラスのＢＰＯＳ登録の方が彼の望みに合うと判断する。所有者は、Office.comに行き、１１個のライセンスのＢＰＯＳ登録を購入する（彼の会社の全員に十分である）。所有者は、ＢＰＯＳアカウントを作成し、彼の従業員の各々に与え、各々にオフィスをプロビジョニングする。

各従業員には、所有者から、オフィス登録をダウンロードするために彼らのＢＰＯＳホーム・ページに行くように指示が与えられる。あるいは、彼らのライセンスをバックステージからどのように変更するかについての指示も彼らに与えられる。従業員が彼らの現在のマシンで何のアクションも行わない場合、どのような永続ライセンスが現在彼らのマシンにあっても、彼らが彼らのＢＰＯＳ ＩＤでサインインしたのであっても、実行し続ける。

ユーザーがバックステージを通じて登録を取り消す
ユーザーは、基本オフィス登録パッケージを有するが、オフィス製品のもっと広い選択を望む。ユーザーはバックステージに行き、「自分のアカウント」を選択する。ユーザーは、「自分の登録を管理する」を選択し、彼のバンドル(bundle)を、彼が望む製品を含むものにアップグレードする。彼がもはや追加の製品を望まない場合、ユーザーは、バックステージ下の「自分のアカウント」に行き、彼の登録を取り消す。ユーザーのオフィスのコピーは、機能制限モードに戻るか、または彼が彼のバンドルをアップグレードする前に彼が有していたいずれかのライセンスに戻る。

ユーザーがOffice.comを通じて登録を取り消す
ユーザーは、基本オフィス登録パッケージを有するが、オフィス製品のもっと広い選択を望む。ユーザーは、彼の現在の登録を管理するために、Office.comにログオンする。ユーザーは、彼のバンドルを、彼が望む製品を含むものにアップグレードする。ユーザーがもはや追加製品を望まない場合、彼はOffice.comにログインし、彼の登録を取り消す。彼のオフィスのコピーは、彼の以前のライセンスによってサポートされていた機能制限モードに戻る。

ユーザーが永続ライセンスおよび登録ライセンスの双方を購入する
ユーザーは、オフィス・スターター(Office Starter)を彼のラップトップ上に有する。ユーザーは、彼のライブＩＤでオフィス・マーケットプレースにサインインし、彼のラップトップを用いてバックステージを通じてオフィスを購入する。オフィス・スターターは、登録パッケージにアップグレードされる。

後に、ユーザーは、永続ライセンスを購入するために、ウェブ・ブラウザーを通じてオフィス・マーケットプレースに戻る。ユーザーは、彼の支払い詳細を再入力する必要がない。代わりに、オフィス・マーケットプレースが彼の信任状を覚えている。ユーザーが購入を確認した後、彼はラップトップ上でオフィスをダウンロードし起動する。

彼がオフィスを購入して数ヶ月後、ユーザーは彼のラップトップがウィルスに感染されたため、彼のアプリケーションをインストールし直すことが必要になる。ユーザーは、彼のオフィスのコピーおよび彼のライセンスを再度ダウンロードするために、オフィス・マーケットプレースにログオンする。これは、同じプロダクト・キーを用いて行うことができる。

登録の更新
ユーザーがオフィスの登録を有する場合、彼は自動的に登録を更新することができる。ユーザーは、オフィスの途切れない使用を体験することができる。

登録の失効
ユーザーはオフィスの登録を有する。しかしながら、彼はそのサービスを愛用せず、期限切れになったときに失効させることを決める。課金システムは、ユーザーに多数の電子メールを送るが、彼はそれを無視する。この時間中、ユーザーはオフィスを使用し続ける。彼は、ある時点で、オフィスを通じて彼の登録が期限切れになったこと、そして彼の登録をバックステージから管理すればよいことを通知される。彼はこれらの警告を無視し、最終的にオフィスは彼のコンピューター上では機能しなくなる。

オフィス２０１３から次のバージョンのオフィスへの登録のアップグレード
ユーザーは、オフィス２０１３のオフィス登録を有し、現在彼のコンピューターにはオフィス２０１３がインストールされている。数年が経過し、オフィスの次のバージョンが発売された。次回ユーザーがいずれかのオフィス・アプリケーションを起動するとき、彼はオフィスの新バージョンにアップグレードできることを通知される。また、彼はバックステージからであればいつでもそれを行うことができることも通知される。ユーザーは、その時点でアップグレードすることを決める。オフィスの新たなバージョンがユーザーのコンピューターにインストールされる。

実施形態では、多数のコンポーネントが、ＯＭＥＸまたはオフィス・ライセンシング・クライアント（ＯＬＣ）、あるいは双方というような、新たなバージョンのオフィスが出た(out)ことを、ユーザーに通知する場合もある。場合によっては、ユーザーが次のバージョンにアップグレードするために残っている時間量を追跡することもできる。ある時点において、アップグレードを強制することもでき、古いバージョンを使用不可能にしてもよい。キーは、正しい課税場所(tax location)から得ることができる。ＢＰＯＳの提案に対しても、同じロジックを用いることができる。

小売店／ＯＥＭ／ＣＤのシナリオ
これらのシナリオは、従前からの小売店の経路(channel)に的を絞る。これらのシナリオにおける共通するテーマは、ユーザーがプロダクト・キーを用いて開始することである。例えば、プロダクト・キーは、ユーザーがオフィスを購入したときの箱に含まれることが多い。

ユーザーが小売店からオフィスを購入する
ユーザーは、小売店に行き、家庭および学生用オフィスのボックス・コピー(box copy)を購入する。この箱の中には、ＣＤおよびプロダクト・キーがある。ユーザーはＣＤからオフィスをインストールする。インストール・プロセスの一部として、ユーザーは彼のプロダクト・キーを入力するように促される。また、ユーザーはオフィスにサインインするようにも促され、そうした後に、彼には彼のライセンスを彼のライブＩＤと関連付ける機会が与えられる。数ヶ月後、ユーザーは彼のコンピューター上にウィルスを発見する。ユーザーは、コンピューターをフォーマットし直し、オフィスをインストールし直す。生憎、ユーザーはプロダクト・キーをなくしてしまった。しかしながら、ユーザーは、彼のライブＩＤだけを用いて、オフィスをアクティベートすることができる。ＯＬＳは、このライブＩＤに関連付けられたプロダクト・キーを戻すことができる。

マシンが多数あるユーザー
あるユーザーは４台のコンピューターを自宅に保有する。このユーザーは、オフィスのコピーを小売店から購入し、プロダクト・キーによって最初のコンピューター上ではオフィスをアクティベートすることに成功することができた。彼は、彼の最初のコンピューターを設定したときに、ライセンスを彼のライブＩＤに関連付けたので、ユーザーは、彼のライブＩＤを用いて、２台目および３台目のコンピューター上においてオフィスをアクティベートすることもできた。しかしながら、４台目のコンピューターをアクティベートしようとしたときに、ユーザーは、彼のライセンスが３台のコンピューターしかサポートしないことを彼に知らせるエラー・メッセージを受ける。

ユーザーがオフィス・ライセンスをライブＩＤと関連付ける
一般に、ユーザーが彼にプロダクト・キーを彼のライブＩＤと関連付けることを望む場合、彼は５×５のプロダクト・キー全体をオフィス・マーケットプレースにオンラインで入力することができる。オフィス・マーケットプレースを通じて、ＯＬＳは次にこのプロダクト・キーをユーザーのライブＩＤと関連付けることができる。

ユーザーは、Office.comを通じて、またはバックステージを通じて、彼のライブＩＤと関連付けられたオフィス・ライセンスをオンラインで見ることができる。加えて、ユーザーは、Office.comを通じて、またはバックステージを通じて、彼のライブＩＤからプロダクト・キーを解離することができるのでもよい。ユーザーが再度アクティベーションのために彼のライブＩＤを使用することを試すと、彼はそうすることができない。しかしながら、彼のライブＩＤで既にアクティベートされているコンピューターは通常通りに機能する。

試行のシナリオ
これらのシナリオは、試行ライセンス(trial license)を目的とし、本質的に試行以外のライセンスのシナリオと同じである。しかしながら、ライセンス期間が試行ライセンスでは遙かに短くなる。

ユーザーが試行ライセンスをOffice.comを通じて開始する
ユーザーは、オフィス・スターターを使用している。ユーザーはオフィスを試すことを決め、彼のライブＩＤを提示した後、Office.comから試行ライセンスをダウンロードする。彼のマシン上においてオフィスを起動すると、ユーザーは彼のライブＩＤを入力するように促される。一旦ユーザーが彼のライブＩＤを入力すると、彼はオフィスを使用し始めることができる。

ユーザーがプロダクト・キーを用いて試行ライセンスを開始する
ユーザーは、オフィスの試行コピーを入手してある。オフィスの試行コピーは、試行ライセンスと関連付けられたプロダクト・キーを含む。ユーザーはオフィスをインストールし、プロダクト・キーを用いてオフィスをアクティベートする。

試行ライセンスの失効
ユーザーはオフィス・スターターを使用しており、ここでオフィスを試したくなった。彼のライブＩＤを提示した後、ユーザーは試行ライセンスをOffice.comからダウンロードする。時が過ぎ、ユーザーは彼の試行が直ぐに期限切れになることをＯＬＣから通知される。ユーザーは、これの試行ライセンスを失効させることを決める。オフィスはオフィス・スターターに戻る。

ユーザーが試行ライセンスから登録ライセンスに変換する
ダン(Dan)は、彼がOffice.comからダウンロードしたオフィスの試行版を使用している。時が過ぎ、彼の試行が直に期限切れになることがオフィス・クライアントから通知される。ダンは、オフィス１５を使用して満足できる体験ができたので、Office.com（またはバックステージ）を通じて完全登録に変換することを決める。彼のオフィスのコピーは、サービスの中断なく、自動的に完全登録にアップグレードする。彼がプロダクト・キーによって試行版をアクティベートし、ＩＤを提示したことが全くなかった場合、彼は、完全バージョンに変換するために、彼のＩＤを提示しなければならないかもしれない。

ライセンスの購入、アクティベート、再アクティベート方法
図４は、マーケットプレース・サービスを通じてアプリケーションのライセンスを購入する方法４００のプロセス・フロー図である。種々の実施形態において、マーケットプレース・サービスは、オフィス・マーケットプレース体験（ＯＭＥＸ）である。更に、実施形態では、方法４００が、図３Ａ、図３Ｂ、および図３Ｃに関して以上で論じたライセンシング・システム３００によって実現される場合もある。

方法４００は、ブロック４０２において開始し、ここでユーザーはライセンスの購入を開始する。ユーザーは、例えば、オフィス・スターター、オフィス試行、オフィスのバックステージ、またはOffice.comを通じて、購入を開始することができる。ユーザーは、ブロック４０４において、所望のライセンスに関するストア・キーピング・ユニット（ＳＫＵ）を選択する。ブロック４０６において、ユーザーは、彼のライブＩＤを用いて、オフィス・マーケットプレース、例えば、ＯＭＥＸにログインする。

ブロック４０８において、ユーザーが登録ＳＫＵを購入しているのか否か判断する。ユーザーが登録ＳＫＵを購入しているのではない場合、ユーザーはブロック４１０において支払い手段(payment instrument)を選択し、ブロック４１２において支払いを完了することができる。次いで、ブロック４１４において、ＯＭＥＸ同期プロバイダーによって、ライセンス更新をＯＬＳに通知することができる。

ユーザーが登録ＳＫＵを購入している場合、ブロック４１６において登録ＳＫＵを設定することができる。次いで、ユーザーはブロック４１８において支払い手段を選択し、ブロック４２０において支払いを完了することができる。ブロック４２２において、登録の詳細を記録することができる。例えば、ＳＫＵ、自動更新情報、および／または課金間隔情報を記録することができる。次いで、ブロック４１４において、ＯＭＥＸ同期プロバイダーによってライセンス更新をＯＬＳに通知することができる。

図５は、マーケットプレース・サービスを通じたアプリケーションのライセンスの初期アクティベーション方法５００のプロセス・フロー図である。種々の実施形態において、マーケットプレース・サービスはＯＭＥＸである。ライセンスの初期アクティベーションは、１つのクライアント・デバイス、例えば、１つのコンピューターにおいて行うことができ、アップセリング(upselling)を含むことはできない。実施形態では、方法５００が、図３Ａ、図３Ｂ、および図３Ｃに関して以上で論じたライセンシング・システム３００によって実現される場合もある。

方法５００は、ブロック５０２において開始し、ここでＯＭＥＸは、許可チケットのようなパラメーターをブートストラッパーに渡す。ユーザーは、ブロック５０４において、Office.comからダウンロードを開始する。ブロック５０６においてビットがコンテンツ配信ネットワーク（ＣＤＮ）から引き出され、ブロック５０８において、ビットが引き出されている間に、スプラッシュ・スクリーンが表示される。

ブロック５１０において、ＯＬＣがライセンシング・ストアに包括的ライセンスを要求する。これによって、ライセンスがアクティベートされている間にオフィスの一時的な使用が可能になる。ブロック５１２においてオフィスをロードし、ＯＬＣは、ブロック５１４において、許可チケットを用いて、ＯＬＳにライセンスを要求する。ブロック５１６において、ＯＬＳは、安全が確保された許可（またはキーレス許可）およびプロダクト・キー（非ローミング・アプリケーションのシナリオの場合）を戻す。

ブロック５１８において、ＯＬＣは、プロダクト・キーおよびＯＳＰＰが入手可能か否か判断する。プロダクト・キーおよびＯＰＳＳが入手可能である場合、ブロック５２０においてＯＳＰＰライセンスがプロダクト・キーによって得られる。ブロック５２２において、ユーザーのパスポート一意ＩＤ（ＰＵＩＤ：passport unique ID）およびユーザー名をローカルマシン上にセーブする。

プロダクト・キーおよびＯＰＳＳが入手可能でない場合、オフィスの使用は、キーレス許可によって可能にすることもできる。次いで、ＯＬＣは、ブロック５１８においてプロダクト・キーおよびＯＰＳＳが入手可能か否か周期的に判断することができ、プロダクト・キーおよびＯＰＳＳが入手可能になった場合しかるべきアクションを行うことができる。

図６は、アプリケーションのライセンスの再アクティベーション方法６００のプロセス・フロー図である。このような再アクティベーション方法は、アップセリングを含むことができる。実施形態では、方法６００が、図３Ａ、図３Ｂ、および図３Ｃに関して以上で論じたライセンシング・システム３００によって実現される場合もある。

方法６００は、ブロック６０２において開始し、ここでオフィスをロードするか、または予定されたライセンス・チェックが行われる。ブロック６０４において、オフィスのライセンスが登録ライセンスかまたは試行ライセンスか判断する。ライセンスが登録ライセンスでも試行ライセンスでもない場合、永続ライセンスであると判断する。この場合、方法６００はブロック６０６に進み、ここでユーザーはオフィスを通常通りに使用する。場合によっては、ライセンスが期限切れであったり、何らかの理由で終了している場合、オフィスが機能を停止することもある。

ライセンスが登録ライセンスまたは試行ライセンスである場合、ＯＬＣは、ブロック６０８においてライセンス情報をＯＬＳに送り、ＯＬＳは、ブロック６１０において、ライセンス更新をＯＬＣに送る。ブロック６１２において、ライセンスが更新されているか否か判断する。ライセンスが更新されている場合、ＯＬＣは新たなライセンスでオフィスを更新する。場合によっては、ユーザーが新たなライセンスを今直ぐ実施したいかまたは後で実施したいかについての選択肢を、ＵＩを通じて提示することもできる。加えて、新たなライセンスがオフィスのバージョン変更を伴う場合、新たなバージョンをダウンロードすることができる。あるいは、ライセンスが更新されなかった場合、方法６００はブロック６０６に戻ることができる。この場合、ライセンスは失効されてもよく、つまり、オフィスは機能を停止するのでもよい。

オフィス・ライセンシング・サービス（ＯＬＳ）
この章では、図３Ａ、図３Ｂ、および図３Ｃに関して以上で説明したライセンシング・システム３００のＯＬＳ３０２のような、本明細書において説明するライセンシング・システムのＯＬＳの機能(functioning)について説明する。ＯＬＳは、ライセンシング・システムの中央ハブとして役割を果たす。ＯＬＳは、プロビジョニング・データ、例えば、ユーザーが購入したものを、ＢＰＯＳまたはＯＭＥＸというような種々のソースから得る。また、ＯＬＳは、プロダクト・キーを得て、キーレス許可を行い、ユーザー対マシンの関係、例えば、ユーザーが何台のマシンをアクティベートしたか管理する。

ＯＬＳは、ライセンシング・システムに、種々の異なるタイプのオペレーティング・システムまたはデバイスに対するライセンスを扱わせることができる。これにより、アプリケーションのライセンスを供与するためのオーバーヘッドを低減する結果が得られる。また、ＯＬＳは、業務モデルの変化に伴って機敏性および柔軟性に備えることができ、ユーザー−ライセンス情報の集中展望図(centralized view)を提供することができる。

種々の実施形態において、ＯＭＥＸはＯＬＣがマシンをユーザー個人情報毎に管理するためのインターフェースを設ける。また、ＯＭＥＸは、ウェブサイト、例えば、ＯＭＥＸ管理ウェブサイトがマシンをユーザー個人情報毎に管理するためのインターフェースも設ける。ＯＭＥＸは、ＩＤ、ＩＤに関係するライセンス、およびライセンスが使用されたマシンのデータベースを維持することができる。加えて、ＯＭＥＸは、キー・ストアからライセンス・キーを得る能力を提供することもできる。更に、ＯＭＥＸは、ＯＬＣが、プロダクト・キー配布（ＯＳＰＰが入手可能な場合）または単純な許可に基づくモデル（ＯＳＰＰが入手可能でない、即ち、キーレス許可のシナリオの場合）のいずれかによって、オフィスの使用を許可するときに用いられる(by which)インターフェースを設けることができる。

ＯＬＳは、少なくとも３つの広いクラスのサービスを提供する。これらのサービスは、ユーザー・ライセンシング・プロビジョニング、プロダクト・キーおよびローミング許可引き出し、ならびにマシン管理能力を含み、以下で更に説明する。ユーザー・ライセンシング・プロビジョニングに関して、ＯＬＳはＢＰＯＳおよびＯＭＥＸのようなパートナーによって提供される情報に基づいて、ユーザーに供与されるオフィス・ライセンスのタイプに関する情報を格納するおよび引き出すことができる。例えば、ＯＬＳは、ユーザーが現在家庭および業務用オフィスに登録しているか否か、または彼が永続的なオフィス・プロフェッショナルを購入したか否かに関する情報を格納するおよび引き出すことができる。

プロダクト・キーおよびローミング許可引き出しに関して、ＯＬＳは、ユーザーに権利があるオフィス・ライセンスに基づいて、キー・ストアから正しいプロダクト・キーを引き出すことができる。この能力は、ユーザーおよびパートナーには継ぎ目がない。言い換えると、プロダクト・キーは、ユーザーがマシンをアクティベートしようとしているときに要求に応じて引き出され、実際のプロダクト・キーをユーザーに露出することなく、アクティベーションはＯＬＣによって自動的に行われる。しかしながら、ＯＬＳは、パートナーが任意にプロダクト・キーを引き出す能力を含まない。更に、ＯＬＳは、ローミング許可、即ち、キーレス許可を引き出すこともでき、これによって、ユーザーはプロダクト・キーがなくてもローミング・アプリケーションのシナリオにおいてオフィスを使用することが可能になる。

実施形態では、ＯＬＳが登録ライセンスのみにマシン管理能力を設ける場合がある。単純にプロダクト・キーを引き出すことに加えて、ＯＬＳは、アクティベートされたマシンの台数も管理することができ、ユーザーが彼の登録に含まれるマシンを交替させる方法を提供することができる。例えば、ユーザーが購入した登録が、３台のマシンにおいてオフィスを使用する権利を彼に与える場合、ＯＬＳは４台目のマシンがプロビジョニングされたなら、最初の３台のマシンの内１台を除外する(deprovision)ことができる。

ＯＬＳのデータベースは、ユーザーによって編成することもでき、ユーザーは、１つ以上の権利と、各権利の下で０台以上のマシンとを有することができる。各権利は、１つだけの提案(offer)と関連付けられる。永続提案による永続権利では、１つの永続キーが各権利と関連付けられるとよい。

図７は、多数の異なるマシン７０６Ａ〜７０６Ｆに対してユーザー７０４に供与された多数の権利、即ち、ライセンス７０２Ａ〜７０２Ｅを示すブロック図である。各権利７０２Ａ〜７０２Ｅは、以下で更に論ずるような、永続権利または登録権利、あるいは双方に関係する提案７０８Ａ〜７０８Ｄを含むことができる。

種々の実施形態において、ＯＬＳは、登録権利、例えば、権利７０２Ａ、７０２Ｂ、および７０２Ｅを用いてプロビジョニングされたマシン、例えば、マシン７０６Ａ，７０６Ｂ，７０６Ｃ，７０６Ｄ，７０６Ｆだけを管理する。したがって、永続権利、例えば、権利７０２Ｃおよび７０２Ｄを有するユーザーは、マシン、例えば、マシン７０６Ｅが以前に登録権利から変換されたのでなければ、権利に関連付けられたマシンを全く有さないことになる。

種々の実施形態において、提案(offer)は、例えば、マイクロソフト・オンラインまたはＯＭＥＸを通じた購入に利用可能な使用権利の一種を表す。提案は、ユーザーに特定的ではなく、ライセンシング・システムがオンラインに接続され(bring online)更新されるときに事前設定される(populate)。提案に対する追加および更新は、展開の一部として組み込むこともできる。各提案には、提案ＩＤを関連付けることができ、提案ＩＤは提案を識別する一意のＩＤである。加えて、各提案には、特定の提案タイプも関連付けることができる。例えば、提案が、プロダクト・キーのみの提案、即ち、永続または試行ライセンスに関係する提案、またはマシン管理提案、即ち、登録ライセンスに関係する提案であってもよい。

本明細書において説明する実施形態によれば、ライセンスまたは権利(entitlement)は、１組の特定的な使用権利(use right)である。ユーザーは、１つ以上の権利を有することもできる。権利は、同期プロバイダーによってプロビジョニングの間に事前設定される。各権利は、一意の権利ＩＤを有し、この権利ＩＤは部分的にプロビジョニング・パートナーによって決定することができる。

各権利に関係する種々の情報を、その権利と共に記録することができる。例えば、権利ＩＤ、パートナー権利ＩＤ、対応するパートナー、ユーザーＩＤ、提案ＩＤ、および権利の状態を記録することができる。加えて、権利に関係するパラメーターの値も記録することができる。例えば、権利がローミング・アプリケーションのシナリオを可能にするか否かに関係する情報、即ち、RoamingType、ユーザーの課金国に関係する情報、即ち、BillingCountryISO、および権利の言語に関係する情報を記録することができる。加えて、権利に対して許可されるプロビジョニングされたマシンまたは変換保留マシン(pending conversion machine)の最大数に関係する情報、即ち、ActiveMachineMax、現在権利に含まれるプロビジョニングされたまたは変換保留マシンの数に関係する情報、即ち、ActiveMachineCount、および種々の他の情報も記録することができる。権利のトークンに関係するパラメーターも記録することができる。このようなパラメーターには、とりわけ、SecureToken、TokenUseMax、TokenUseCount、TokenExpiryLength、およびTokenExpiryが含まれる。

マシンは、特定の登録権利を用いるオフィスの特定のインストールとすることができる。権利の下には０以上のマシンがあってもよい。新たな登録（またはＴＢＬ）プロダクト・キーが権利から発行される毎に、新たなマシンが作製される。

各マシンには、MachineKeyと関連付けることができ、MachineKeyはそのマシンを識別するために用いることができる。MachineKeyの値は、マシンに発行されたプロダクト・キーから導出することができる。マシンがプロビジョニングされたか、変換を保留中か、変換されたか、または予見される(prevision)かというような、マシンのステータスを記録することができる。加えて、マシンに関係する種々の他のパラメーターも記録することができ、権利ＩＤ、提案ＩＤ、キー・ステータス、およびマシン自体に関係する情報が含まれる。

本明細書において説明する実施形態によれば、プロダクト・キー、即ち、ProductKeyが権利毎に発行される。各権利の下には１つだけのイネーブルされたProductKeyがあることになり、永続権利のみが、イネーブルされたProductKeyを有することになる。ProductKeyは、最初に永続権利からプロダクト・キーが要求されたときに作成されればよい。権利が変換されない限り、同じ永続キーが全てのその後のキー要求時に用いられる。プロダクト・キーのステータスに関係する情報、即ち、KeyStatusを記録することができる。プロダクト・キーのステータスは、「イネーブルされた」、「ディスエーブル保留」(pending disablement)、または「ディスエーブルされた」とすることができる。プロダクト・キーが発行された回数に関係する情報、即ち、KeyIssuedCount、およびKeyStatusが更新された最後の日付けに関係する情報、即ち、KeyStatusLastUpdateも、プロダクト・キーと共に記録することができる。

種々の実施形態において、プロビジョニングＡＰＩは、プロビジョニングに使用される１組の内部ＡＰＩである。プロビジョニングＡＰＩは、同期プロバイダーのみによってコールされる。各同期プロバイダーＡＰＩは、プロビジョニングＡＰＩの内１つ以上をコールすることができる。プロビジョニングＡＰＩは、ライセンシング・システムの残りに対して原子動作(atomic operation)として現れるように設計することができる。尚、１回のプロビジョニング・アクションが多数のプロビジョニングＡＰＩのコールを要する場合もあることを注記しておく。例えば、ＯＭＥＸ同期プロバイダーのProvisionUser()ＡＰＩに対して、AddUser()およびCreateEntitlement()コールの双方が用いられる。AddUser()が成功したがCreateEntitlementForUser()が失敗した場合、ユーザーは権利を有することができず、ユーザーには、オフィスに対する不正アクセス(unauthorized access)が付与されない。ライセンシング・システム内部におけるＡＰＩの例には、ユーザーをＯＬＳに追加するAddUser()ＡＰＩ、ユーザーに権利を作成するCreateEntitlement()、および権利を他の提案に変換するまたはパラメーターActiveMachineMaxを更新するConvertEntitlement()ＡＰＩが含まれる。ConvertEntitlement()ＡＰＩは、例えば、変換が登録ライセンスから他の登録ライセンスになのか、または登録ライセンスから永続ライセンスになのかには関係なく、同じく機能する。加えて、明示的に指定されない限り、変換の間不正カウンターおよび制限は、リセットされてはいけない。

図８は、権利を他の提案に変換する、または権利に関係する提案を更新する方法８００のプロセス・フロー図である。提案の更新は、例えば、ActiveMachineMaxを更新することを含むこともできる。この方法は、ブロック８０２において開始し、ここで、ConvertEntitlement() ＡＰＩをコールする。ブロック８０４において、権利を解除するか否か決定することができる。権利を解除する場合、本方法８００はブロック８０６において終了する。権利を解除しない場合、方法８００はブロック８０８に進み、ここで、既存の提案が新たな提案と同じであるか否か判断する。

既存の提案が新たな提案と同じではない場合、ブロック８１０において、権利に対して既存のプロビジョニングされたマシンがあるか否か判断する。既存のプロビジョニングされたマシンがある場合、ブロック８１２において、全ての既存のプロビジョニングされたマシンを、ステータス＝変換保留中に更新する。次いで、方法８００はブロック８１４に進み、ここで、権利を新たな提案で更新する。ブロック８１０において既存のプロビジョニングされたマシンがないと判断した場合、方法８００は自動的にブロック８１４に進む。

ブロック８１６において、既存のActiveMachineMax＝MaxMachinesであるか否か判断する。更に、ブロック８０８において、既存の提案が新たな提案と同じであると判断した場合、方法８００は自動的にブロック８１６に進む。

ブロック８１６において既存のActiveMachineMax≠MaxMachinesであるとき、ブロック８１８において、ActiveMachineMaxをMaxMachinesに更新することができる。次いで、ブロック８２０において、ActiveMachineCountがActiveMachineMaxよりも大きいか否か判断することができる。ActiveMachineCountがActiveMachineMaxよりも大きい場合、方法８００がブロック８２４に進む前に、このイベントをブロック８２２において記録する。そうでない場合、方法８００はブロック８２０からブロック８２４に進む。更に、ブロック８１６において既存のActiveMachineMax＝MaxMachinesである場合、方法８００は自動的にブロック８２４に進む。

ブロック８２４において、既存のイネーブルされたPerpetualKeyがあるか否か判断する。既存のイネーブルされたPerpetualKeyがない場合、方法８００はブロック８２６において終了する。既存のイネーブルされたPerpetualKeyがある場合、ブロック８２６における方法８００の終了前に、ブロック８２８においてPerpetualKey＝ディスエーブル保留(pending disabled)となるように、PerpetualKeyを設定する。

[00179] また、ライセンシング・システムには多数の追加のＡＰＩも含ませることができる。例えば、UpdateEntitlementStatus()ＡＰＩは、権利のステータスを更新するために用いることができる。UpdateBillingCountry()ＡＰＩは、ユーザーの課金情報、即ち、BillingCountryISOを更新するために用いることができ、GetDownloadInfo()ＡＰＩは、ダウンロードＵＲＬおよび権利に関する他の除法を戻すために用いることができる。

種々の実施形態において、セキュア・トークン(secure token)、即ち、SecureTokenは、ユーザーとして権利への一時的アクセスを付与するＯＬＳによって生成される、単なるグローバル一意識別子（ＧＵＩＤ）である。クライアントがSecureTokenを用いてＯＬＳコールを行うと、このクライアントは、本質的に、トークンが発行されたユーザーの信任状を用いてＯＬＳをコールしていることになる。個人情報チケットを供給することと、セキュア・トークンを供給することとの間の主要な相違は、セキュア・トークンが特定の権利に範囲が決められている(scoped)ので、特定の権利について情報を引き出すまたはキーを得るためにしか用いることができず、更にセキュア・トークンは、使用が制限され期限が定められることである。

CheckMachineStatus()ＡＰＩは、マシンのステータスを戻す。しかしながら、このＡＰＩは、登録権利の下でプロビジョニングされたマシンについての情報だけを戻すことができる。GetEntitlementForIdentity()ＡＰＩは、供給された個人情報に現在関連付けられている権利（１つまたは複数）を戻すことができる。GetEntitlementForMachineKey()ＡＰＩは、MachineKeyに現在関連付けられている権利（１つまたは複数）を戻すことができる。実施形態では、本プロセス・フローは、以下のようにすることができる。（１）一致するMachineKeyを用いてマシンのEntitlementIDを引き出す、（２）先のEntitlementIDを用いて権利を引き出す、および（３）権利についての情報を戻す。

加えて、GetKey()ＡＰＩは、ＯＬＣがキーレス許可および／またはアクティベーション用のプロダクト・キーを引き出すことができるＡＰＩであってもよい。このＡＰＩのロジックは、多数の部分に分割することができる。

図９は、ユーザーの個人情報、およびキーレス許可がプロビジョニングされようとする権利の識別情報(identity)を検証する方法９００のプロセス・フロー図である。方法９００は、ブロック９０２において開始し、ここで、GetKey()ＡＰＩをコールする。ブロック９０４において、SecuredTokenが使用されたか否か判断する。SecuredTokenが使用された場合、ブロック９０６においてＯＬＳトークンの有効性を判断する。ブロック９０８において、トークンが無効か否か判断する。トークンが無効である場合、ブロック９１０においてエラーを戻す。トークンが有効である場合、ブロック９１２においてTokenUseCountを決定する。次いで、ブロック９１４において、このトークンと関連付けられたユーザーを引き出す。次いで、本方法はブロック９１６に進む。

加えて、ブロック９０４において、SecuredTokenが使用されなかったと判断した場合、方法９００はブロック９１８に進み、ここで識別情報の有効性を判断する。次いで、本方法はブロック９１６に進み、ここで、ユーザーが保留中か否か判断する。ユーザーが保留中である場合、ブロック９２０においてエラーを戻す。そうでない場合、ブロック９２２において、EntitlementIDが存在するか否か判断する。EntitlementIDが存在しない場合、ブロック９２４においてエラーを戻す。そうでない場合、ブロック９２６において、権利が保留または解除されたか否か判断する。権利が保留または解除された場合、ブロック９２８においてエラーを戻す。そうでない場合、方法９００は、図１０に関して以下で論ずるキーレス許可のフローに進む。

図１０は、キーレス許可を適宜プロビジョニングする方法１０００のプロセス・フロー図である。キーレス許可の目的は、ＯＳＰＰなしで、そしてプロダクト・キーを使用したアクティベーションを行わずに、一時的にオフィスを実行することをクライアントに可能にすることとすればよい。これは、例えば、最初のインストール実行中またはローミング・アプリケーションのシナリオの間には有用であろう。

キーレス許可は、一時的なオフィスのアクセスを可能にするためにクライアントによって用いられる許可ストリングを含む署名付きストリングとすることができ、オフィス内にBaseAuthStringとして格納される。キーレス許可は、GetKey()の要求時にクライアントによって送られるＨＷＩＤパラメーター、ならびにクライアントがもはやキーレス許可を使用できない日付けおよび時刻を表すTimeValidEndパラメーターを含む、多数のパラメーターも含むことができる。

方法１０００のキーレス許可フローは、ブロック１００２において開始する。種々の実施形態において、方法１０００は、以上で論じた方法９００の後に実行される。方法１０００は、ブロック１００４〜１０２２において多数の判断を行うことを含み、例えば、クライアントによって要求されたキーのタイプに関する判断を含むことができる。ブロック１０１２または１０１４において方法１０００の条件が満たされない場合、ブロック１０２４または１０２６においてエラーを戻すことができる。

方法１０００において提示された条件が満たされた場合、ブロック１０２８において、プロダクト・キーが要求されたか否か判断することができる。プロダクト・キーが要求されなかった場合、ブロック１０３０においてキーレス許可を戻す。プロダクト・キーが要求された場合、ブロック１０３２において、権利提案がインストールを許可するか否か、即ち、ローミングのみではないか否か判断することができる。権利提案がインストールを許可しない場合、ブロック１０３４においてエラーを戻す。そうでない場合、ブロック１０３６において、提案タイプがKeyOnlyであるか否か判断する。

提案タイプがKeyOnlyでない場合、方法１０００は、ブロック１０３８に示すように、図１１Ａまたは図１１Ｂの登録キー・フローに進む。提案タイプがKeyOnlyである場合、方法１０００は、ブロック１０４０に示すように、図１２Ａおよび図１２Ｂのプロダクト・キー・フローに進む。

図１１Ａは、既存の登録（またはＴＢＬ）キーを引き出す方法１１０００のプロセス・フロー図である。種々の実施形態において、GetKey()ＡＰＩコールにおいて用いられるMachineKeyおよびHWIDがＯＬＳに格納されているものと同一である場合、既存のキーが引き出される。方法１１００の登録キー・フローは、ブロック１１０２において開始する。種々の実施形態において、方法１１００は、以上で論じた方法１０００の後に実行される。方法１１００は、ブロック１１０４〜１１４０において、多数の判断を行い、多数のステップを実行することを含むことができる。実施形態では、方法１１００が、ブロック１１４２に示す、図１１Ｂの新登録キーのフローに進む場合もある。他の実施形態では、ブロック１１４４に示すように、方法１１００の終了時に、既存の登録キーが戻される。

図１１Ｂは、新登録キーを得る方法１１４６のプロセス・フロー図である。種々の実施形態において、新たなインストールが行われたとき、マシンが許容再アクティベーション(tolerance reactivation)を使い果たしたとき、権利変換が行われたとき、またはマシンがプロビジョニングし直されたときに、新たなキーがキー・ストアから引き出される。方法１１４６は、以上で論じた方法１０００または方法１１００の後に実行することができる。

方法１１４６の新登録キーのフローは、ブロック１１４８において開始する。ブロック１１５０〜１１５６において多数のステップを実行した後、ブロック１１５８において、新登録キーを戻す。あるいは、ブロック１１５０において方法１１４６の条件が満たされない場合、ブロック１１６０においてエラーを戻し、新登録キーは得られない。

図１２Ａは、既存のプロダクト・キーを引き出す方法１２００のプロセス・フロー図である。方法１２００はKeyOnly提案タイプに適用することができる。種々の実施形態において、方法１２００は、以上で論じた方法１０００の後に実行される。方法１２００のプロダクト・キーのフローは、ブロック１２０２において開始する。方法１２００は、ブロック１２０４〜１２１２において、多数の判断を行い多数のステップを実行することを含むことができる。実施形態では、ブロック１２０６において方法１２００の条件が満たされない場合、ブロック１２１４においてエラーを戻す。他の実施形態では、ブロック１２１６に示すように、方法１２００は、図１２Ｂの新プロダクト・キーのフローに進む。更に、他の実施形態では、ブロック１２１６に示すように、方法１２００の終了時に、既存のプロダクト・キーを戻す。

図１２Ｂは、新プロダクト・キーを得る方法１２１８のプロセス・フロー図である。新プロダクト・キーは、権利が新しい場合または以前の権利から変換された場合にのみ得ることができる。方法１２１８は、以上で論じた方法１０００または方法１２００の後に実行することができる。方法１２１８の新プロダクト・キーのフローは、ブロック１２２０において開始する。方法１２１８は、ブロック１２２２〜１２２６において、多数の判断を行い、多数のステップを実行することを含むことができる。次いで、ブロック１２２８に示すように、方法１２１８の終了時に、新プロダクト・キーを戻す。

図１３は、権利からマシンを引き出す方法１３００のプロセス・フロー図である。方法１３００は、GetMachineList()ＡＰＩを用いて実行することができる。GetMachineList()ＡＰＩは、ユーザーがキーを要求したマシンを戻すことができる。コール元は、特定の権利と関連付けられたマシン、または特定のステータスを有するマシンを要求することができる。

方法１３００は、ブロック１３０２において開始することができ、ここで、GetMachineList()ＡＰＩをコールする。方法１３００は、ブロック１３０４〜１３１６において多数の判断を行い、多数のステップを実行することを含むことができる。次いで、ブロック１３１８において、権利（１つまたは複数）からマシンを引き出し、ブロック１３２０においてマシンのリストを戻す。

種々の実施形態において、現在永続提案になっている権利からGetMachineList()を試す(attempt to)ことがＡＰＩに要求された場合でも、ＡＰＩはその権利からマシンを引きだそうとする。何故なら、権利が登録提案から変換され、現在登録キーを使用しているマシンを有していない可能性があるからである。

図１４は、権利から特定のマシンを解除する(deprovision)方法１４００のプロセス・フロー図である。方法１４００は、RemoveMachine()ＡＰＩを用いて実行することができる。RemoveMachine()ＡＰＩは、解除の印をマシンに付けるために用いることができる。次いで、解除は非同期で行うこともできる。

方法１４００は、ブロック１４０２において開始し、ここで、RemoveMachineList()ＡＰＩをコールする。方法１４００は、ブロック１４０４〜１４１８において多数の判断を行い多数のステップを実行することを含むことができる。実施形態では、ブロック１４０８、１４１６、または１４１８において方法１４００の条件の１つが満たされない場合、ブロック１４２０、１４２２、または１４２４において、それぞれ、エラーを戻すことができる。そうでない場合、ブロック１４２６において、マシンステータスを解除に設定する。これは、事実上、権利からそのマシンを削除することになる。

種々の実施形態において、GetUrlForEntitlment()ＡＰＩは、権利のビットをダウンロードするために、ダウンロードＵＲＬを戻す。このＡＰＩは、プロビジョニングGetDownloadInfo()ＡＰＩと同様に機能する。しかしながら、識別情報は、ＰＵＩＤではなく、ＢＰＯＳまたはライブ、あるいはＯＬＳのSecuredTokenによって発行されたチケットであればよい。SecureTokenは、用いられた識別情報がＯＬＳSecureTokenである場合、再生成されなくてもよい。むしろ、既存のトークンをＵＲＬにおいて用いればよい。また、このＡＰＩも、ダウンロード・パラメーターではなく、ＵＲＬを戻すだけである。

本明細書において説明する実施形態によれば、プロダクト・キー・キャッシュは、ＯＬＳがキーを得る元であるキー・ストアである。プロダクト・キー・キャッシュは、ＯＳＬの中核ライセンシング・データベースとは独立したデータベースであり、キャッシュにおける利用可能なキーの数が一定の閾値未満であるときはいつでもＪＩＴシステムからキーを引き出す非同期プロセスによって事前設定される。

プロダクト・キー・キャッシュは、キー毎にメタデータを格納することができ、キーのＰＫＰＮ、ＰＫＰＮのＪＩＴ ＳＫＵ、およびキーが最初に得られたデータ・センターの国を含む。プロダクト・キー・キャッシュは、GetKey()ロジックによって供給される様々なパラメーターに基づいて、課税準拠キー(tax compliant key)を戻すことができる。これらのパラメーターには、提案属性である権利KeyStoreReqId、および権利から得られるBillingCountryISOが含まれる。

ＯＬＳ内部では、プロダクト・キー解除コンポーネントは、中核システムとは独立して実行する非同期サービスであってもよい。プロダクト・キー解除コンポーネントは、規則的なスケジュールで実行することができ、規則的なスケジュールは最初は毎日１回に設定される。

プロダクト・キー解除コンポーネントの予定された実行中に、キー・ステータス、即ち、KeyStatusがディスエーブル保留(pending disable)であり、最後のキー・ステータス更新の日付、即ち、KeyStatusLastUpdateが２ヶ月よりも長いマシンを識別することができる。加えて、プロダクト・キー解除コンポーネントの予定された実行中に、キー・ステータスがディスエーブル保留であり、最後のキー・ステータス更新の日付が１ヶ月よりも長いプロダクト・キーを識別することができる。実施形態では、ユーザーがマシンを権利から削除したことに応答してというように、同期プロバイダーの更新またはユーザーのアクションのために、マシンが解除される可能性がある。

オフィス・マーケットプレース体験同期プロバイダー
ＯＭＥＸ同期プロバイダーは、ＯＭＥＸパートナーからプロビジョニング更新を受けるため、そしてこれらの更新をＯＬＳ内に公開するために用いることができる。更に具体的には、ＯＭＥＸ同期プロバイダーは、ＯＭＥＸパートナーにＯＬＳにおけるプライベート・プロビジョニング・レイヤーへの直接アクセスを許可せずに、種々のプロビジョニング・タスクを実行するために、１組のＡＰＩをＯＭＥＸパートナーに露出する抽象化レイヤーである。

図１５Ａは、ユーザーによる権利の初期購入の方法１５００のプロセス・フロー図である。方法１５００は、以上で論じたＯＭＥＸ同期プロバイダーを用いて実行することができる。ユーザーは、ブロック１５０２において購入を開始し、ユーザーは、ブロック１５０４において、クライアントを通じてまたはウェブを通じて、ＯＭＥＸを介してＳＫＵを選択する。ブロック１５０６において、ユーザーは、彼のライブＩＤを用いてサインインし、ユーザーはブロック１５０８において権利を購入するための支払い情報を全て入力する(complete)。

ＯＭＥＸは、ブロック１５１０において、購入アクションを完了するためにＣＴＰをコールし、ブロック１５１２において、ユーザーにプロビジョニングするためにＯＭＥＸ同期プロバイダー、即ち、ProvisionUser()をコールする。ブロック１５１４において、ＯＭＥＸ同期プロバイダーはユーザーにプロビジョニングし、ダウンロードＵＲＬを戻す。ＯＬＳにおけるユーザーへのプロビジョニングは、ProvisionUser()ＡＰＩを用いて遂行することができる。ProvisionUser()ＡＰＩは、ＯＭＥＸパートナーでなければコールできないのでもよい。

場合によっては、同期プロバイダーに対するコールにタイムアウトがある。したがって、ブロック１５１６において、エラーまたはタイムアウトが起きたか否か判断することもできる。エラーまたはタイムアウトが起きた場合、ブロック１５１８において「後で戻って来てダウンロードして下さい」というメッセージをユーザーに表示することもできる。そうでない場合、ＯＭＥＸは、ブロック１５２０において、権利に対するダウンロード・リンクをユーザーに表示する。

図１５Ｂは、権利を更新する方法１５２２のプロセス・フロー図である。方法１５２２は、ブロック１５２４において開始し、ここで、ＣＴＰはプロビジョニング・コールバックを開始する。ブロック１５２６において、ＯＭＥＸライセンシング・ノティファイア(notifier)が、ProvisionUser() ＡＰＩを用いてユーザーにプロビジョニングするために、ＯＭＥＸ同期プロバイダーをコールする。ブロック１５２８において、ＯＭＥＸ同期プロバイダーは、ユーザーにプロビジョニングするかまたは権利を更新する。次いで、ブロック１５３０において、エラーまたはタイムアウトが発生したか否か判断する。エラーまたはタイムアウトが発生した場合、方法１５２２はブロック１５２４に戻る。そうでない場合、方法１５２２はブロック１５３２において終了する。

図１６は、ＯＬＳにおいてユーザーにプロビジョニングする、またはユーザーを１つの権利から他の権利に変換する方法１６００のプロセス・フロー図である。この方法は、ブロック１６０２において開始し、ここで、ProvisionUser()ＡＰＩをコールする。ブロック１６０４において、変換フラグがセットされたか否か判断する。

変換フラグがセットされた場合、ブロック１６０６において、権利が解除されたか否か判断することができる。権利が解除されていた場合、ブロック１６０８において例外を投入する(throw)。そうでない場合、ブロック１６１０において、ユーザーを他の権利に変換する。逆に、ブロック１６０４において変換フラグがセットされなかった場合、ブロック１６１０においてユーザーにプロビジョニングする。

次いで、ブロック１６１２においてDownloadTypeを要求し、ブロック１６１４においてダウンロードＵＲＬを戻す。戻されたダウンロードＵＲＬは、安全が確保されたトークン、例えば、ＧＵＩＤを含むことができ、ユーザーが彼の信任状を再度タイプ入力することなく、オフィスをアクティベートすることを可能にする。したがって、ＵＲＬの使用は制限されてもよい。実施形態では、ダウンロード・リンクを適宜生成し直すために、GetDownloadForEntitlement()ＡＰＩを用いる。

図１７は、ForcedUpdateプロセスにしたがって権利を更新するか否か判断する方法１７００のプロセス・フロー図である。方法１７００は、ブロック１７０２において開始し、ここで、ProvisionUser()ＡＰＩをコールする。方法１７００は、ブロック１７０４〜１７２６において多数の判断を行い多数のステップを実行することを含むことができる。実施形態では、ブロック１７１８において、権利が存在しないと判断し、ブロック１７２８において例外を投入する。そうでない場合、方法１７００はブロック１７３０に進み、ここで、ダウンロードＵＲＬを戻す。ダウンロードＵＲＬは、ブロック１７１２またはブロック１７２２において判断されるように、ForcedUpdateが設定されたか否かに応じて、そしてブロック１７２４において判断されるように、権利更新が許可されるか否かに応じて、様々に変化する可能性がある。

方法１７００によれば、ForcedUpdateは、非同期ＣＴＰプロビジョニング・コールの間に指定されればよい。何故なら、これは、ユーザーが購入したものに対する究極的な権威(authority)になることができるからである。競合状態において不一致が発生する場合もあり、非同期ＣＴＰプロビジョニング・コールは、購入の間に開始されるプロビジョニング・コールよりも前に行われる。場合によっては、プロビジョニングの間にForcedUpdateが指定される場合、ForcedUpdateが新たなProvisionUser()ＡＰＩコールにおいて設定されなければ、同じEntitlementIDに対する他の更新が、最後に成功した更新から１０秒間許可されなくてもよい。この場合、コールは成功し、既存の権利情報に基づいて情報を戻す。時間値は構成可能にするとよく、このチェックのロジックは、同期プロバイダー・レイヤーに分離されてもよい。

ユーザーの権利に対する更新が行われないが、コールが正しく戻った場合、応答は、更新が行われなかったことをコール元に示すフラグを収容することができる。また、この応答は、既にシステム内にある権利情報も収容することができる。コール元は、トラブルシューティングのためまたは他の追加のアクションを行うために、この権利情報を用いることができる。

デバイスに対するライセンシング
本明細書において説明する実施形態によれば、異なるタイプのデバイスのライセンシング、および異なるタイプのデバイスに関係する特定のアプリケーションのライセンシングをサポートするために、ＯＬＳを更新することができる。例えば、ＯＬＳは、オフィス、例えば、オフィス２０１５のライセンシングを、とりわけ、ＭＯＸアプリケーション、移動体オフィス・アプリケーション、Androidアプリケーション、Windows（登録商標） Mobileアプリケーション、およびMacオフィス・アプリケーションの形態でサポートすることができる。したがって、ＯＬＳは、多くの異なるプラットフォームに跨がるオフィスのライセンシングに対処することができる。

ＯＬＳ内部では、「コンピューター」という用語は、ＰＣおよびＭａｃを指すのでもよく、「デバイス」という用語はＭＯＸ（またはスレート）および移動体電話機を指すのでもよい。集合的に、コンピューターおよびデバイスは、双方共ＯＬＳ内部では「マシン」と呼ぶことができる。

ＯＬＳ内部におけるデバイスに対するライセンスは、信任状に基づくライセンスまたはトークンに基づくライセンスのいずれかの形態を取ることができる。信任状に基づくライセンスでは、いずれのデバイスも１つのライセンス・カウントを共有することができ、一方いずれのコンピューターも他のライセンス・カウントを共有することができる。トークンに基づくライセンスでは、ライセンス・トークンがＯＬＳトークンの代わりに用いられる。各ライセンス・トークンの限度を超えたデバイス・カウントはなく、１つのデバイスだけでしか使用できないようになっている。

デバイス・アプリケーション、例えば、ＭＯＸおよび移動体アプリケーションは、プラットフォームのアプリケーション・ストア、例えば、アップル・ストアを通じて、ＯＥＭ−プリインストール、例えば、Windows（登録商標） Mobileによって、またはウェブサイト・ダウンロード、例えば、Androidによって流通させることができる。デバイス毎のライセンシング権利(licensing right)は、ＯＬＳの関与がないプラットフォームのアプリケーション添付を通じて、ＯＬＳを通じて管理されたまたは管理されない登録の購入によって、またはＯＬＳを通じてＶＬ契約によって得ることができる。

図１８Ａは、デバイスに対するアプリケーションの初期ライセンシングの方法１８００のプロセス・フロー図である。方法１８０はブロック１８０２において開始し、ここで、ユーザーは、デバイスのアプリケーション・ストアからアプリケーションをダウンロードする。ブロック１８０４において、ユーザーに彼の信任状を催促する。ブロック１８０６において、ユーザーは、彼のライブＩＤまたは他の信任状を用いてサインインする。ブロック１８０８において、デバイスは次にＯＬＳに問い合わせてライセンス情報を求め、ブロック１８１０において、ＯＬＳは許可ストリングを戻す。ブロック１８１２において、デバイスは、許可ストリングの真正性を検証し、マシン・キーをセーブし、アクセスを付与する。

ブロック１８１４において、デバイスが許可されたか否か判断する。デバイスが許可されない場合、ブロック１８１６においてエラーを戻す。デバイスが許可された場合、ブロック１８１８において、周期的なチェックまたはアプリケーションの再インストールまで、アプリケーションへのアクセスが付与される。

図１８Ｂは、ライセンスの状態を周期的にチェックする方法１８２０のプロセス・フロー図である。種々の実施形態において、方法１８２０は、アプリケーションのその日の最初のブートに応答して実行される。

方法１８２０は、ブロック１８２２において開始し、ここで、デバイスはＯＬＳに問い合わせてライセンス情報を求める。デバイスは、ログイン５回毎または毎月というように、デバイスが決定した間隔で問い合わせることができる。ブロック１８２４において、デバイスはマシン・キーをＯＬＳに送る。

ブロック１８２６において、ＯＬＳはデバイス状態をデバイスに返す。ブロック１８２８に示すように、デバイス状態がプロビジョニングされている場合、アプリケーションへのアクセスを付与する。ブロック１８３０に示すように、デバイス状態が変換保留または変換済みである場合、許可ストリングをＯＬＳから再度入手する。ブロック１８３２に示すように、デバイス状態が解除である場合、エラーを戻す。

図１９は、デバイスに最初にライセンスする方法１９００のプロセス・フロー図である。同様に付番された項目は、図１８Ａに関して説明された通りである。方法１９００は、デバイスにおける特定のアプリケーションの最初のブートに応答して実行することができる。

方法１９００は、図１８Ａの方法１８００と同様であってもよい。しかしながら、ブロック１９０２において、ユーザーにデバイス・トークンを催促し、ユーザーは、ブロック１９０４において、彼のライブＩＤまたは他の信任状を用いてサインインする代わりに、デバイス・トークンを供給する。したがって、方法１９００によれば、デバイスに対するライセンスは、トークンに基づくライセンスである。トークンに基づくライセンスでは、デバイスは、一旦ライセンスが初期設定されると、アプリケーションを使用するように永続的にライセンスされる。したがって、ライセンスに対する周期的なライセンス・チェックはなくてもよい。したがって、ブロック１９０６において、永続的に、またはアプリケーションの再インストールまで、デバイスにアプリケーションへのアクセスを付与する。

本明細書において説明する実施形態によれば、ＯＬＳライセンスは、ＯＬＳによって付与することができる新しいタイプのライセンスである。ＯＬＳライセンスは、GetOLSLicence()ＡＰＩによって発行することができる。ＯＬＳライセンスは、ライセンス・ストリング、即ち、MachineKey、マシン識別、即ち、MachineID、許可を使用し始めることができる有効な日時、即ち、TimeValidStart、および許可をもはや使用できなくなる有効な日時、即ち、TimeValidEndを含むことができる。

デバイスは、ＯＬＳライセンスが様々な判断基準を満たす場合でなければGetOLSLicence()ＡＰＩによって戻されるＯＬＳライセンスを受ける(honor)ことができない。例えば、ＯＬＳライセンスがＯＬＳによって署名されたことを検証することができ、戻されたMachineIDが、要求において用いられたMachineIDと一致することを検証することができ、TimeValidStartが要求において用いられた現在時刻と一致することを検証することができ、現在のクライアント時刻がTimeValidStartとTimeValidEndとの間にあることを検証することができる。

サービスに対するライセンシング
本明細書において説明する実施形態は、サービスに対するライセンシングに関係する種々の機能を実行するために用いることができる。例えば、本明細書において説明する実施形態は、パートナーが、そのローミング設定サービスへのアクセスがユーザーに与えられるのか否か識別することを可能にするのでもよい。加えて、このような実施形態は、オフィス・クライアント・プロビジョニング情報を引き出すためのインターフェースを、オフィス・サービスに供給することもできる。

図２０は、パートナーによる、そのサービスへのアクセスをユーザーに付与するか否かについての決定方法２０００のプロセス・フロー図である。このような決定は、サービス・プロビジョニング情報を用いて行うことができる。実施形態では、パートナーがユーザー・プロビジョニング・キャッシュを維持し、GetEntitlementForIdentityEx()ＡＰＩコールからの結果をキャッシュする場合もある。これは、パートナーの動作(performance)を改良し、ＯＬＳ上の負荷を低減することができる。ユーザー・プロビジョニング・キャッシュの長さは、特定のサービスの特性にしたがって調整することができる。加えて、ユーザー・プロビジョニング・キャッシュは、どれくらい頻繁にリアル・タイム情報がサービスによって望まれるか、そしてプロビジョニング情報を求めてＯＬＳをコールする動作コストに基づいて、消滅してもよい。

本方法は、ブロック２００２において開始し、ここで、ユーザー・プロビジョニング・キャッシュが存在し有効であるか否か判断する。ユーザー・プロビジョニング・キャッシュが存在し有効である場合、ブロック２００４においてサービスへのアクセスを付与する。ユーザー・プロビジョニング・キャッシュが存在しないかまたは有効でない場合、ブロック２００６において、プロバイダーはGetEntitlementForIdentityEx()ＡＰＩをコールする。ブロック２００８において、パートナーはユーザー・プロビジョニング・キャッシュを更新する。次いで、ブロック２０１０において、ユーザーにサービスをプロビジョニングするか否か決定する。ユーザーにサービスをプロビジョニングしない場合、ブロック２０１２に示すように、サービスへのアクセスを付与しない。そうでない場合、ブロック２００４において、サービスへのアクセスをユーザーに付与する。

ジオロケーションおよびジオスケーリング・サービス
種々の実施形態において、ジオロケーション(geolocation)およびジオスケーリング(geo-scaling)サービスが、ＯＬＳの性能、可用性、信頼性、およびスケーラビリティを改良または維持するために用いられる。ＯＬＳに対する全体的なジオロケーション設計は、マスター・データ・センターと多数の複製データ・センターとを含むことができ、複製データ・センターは、世界中に地理的に分散することができる。この設計は、論理的に、無制限の数の複製データ・センターをサポートすることができる。各複製データ・センターは、適宜オンラインに繋ぐことができる。

マスター・データ・センターは、全てのＯＬＳ動作を扱うことができる。例えば、書き込み動作、例えば、プロビジョニングの更新は、最初にマスター・データ・センターを通過することができる。マスター・データ・センターは、ユーザー毎にプロビジョニング情報のマスター・コピーを収容することができる。加えて、全ての同期プロバイダー・コンポーネントおよびキー・キャッシュ・コンポーネントがマスター・データ・センター内に存在することができる。更に、マスター・データ・センターを継続的に監視して複製データ・センターに同期させる更新を決定するために、ジオシンカー(geo-syncer)を用いることもできる。

複製データ・センターは、全ての読み取り動作を扱い、例えば、ユーザーがサービスにアクセスする許可を有するか否かチェックすることができる。また、複製データ・センターは、一部の書き込み動作も扱うことができ、キーレス許可を発行することができる。各複製データ・センターは、ユーザー毎のプロビジョニング情報のコピーを収容することができ、マスター・データ・センターから継続的にプロビジョニング更新を得ることができる。更に、災害復旧のシナリオの場合、複製データ・センターはいずれも、以下で更に論ずるように、マスター・データ・センターになることができる。

図２１は、マスター・データ・センター２１００ならびに多数の複製データ・センター２１０２Ａおよび２１０２Ｂの構成例の模式図である。ＯＭＥＸ２１０４または他のパートナーには、マスター・データ・センター２１００についてのＯＬＳ ＵＲＬ、例えば、generic.ols.office.com、および直接ＵＲＬ、例えば、master.ols.office.comを与えることができる。ＯＭＥＸ同期プロバイダー２１０６の動作というようなある種の動作では、ＯＭＥＸ２１０４は、generic.ols.office.comを用いるのではなく、直接master.ols.office.comをコールすることができる。次いで、コールは、マスター・データ・センター２１００から複製データ・センター２１０２Ａまたは２１０２Ｂのいずれかに、グローバル負荷バランサー２１０８内部のロジックに基づいてリディレクトすることができる。

加えて、多数のジオシンカー２１１０Ａおよび２１１０Ｂを用いて、マスター・データ・センター２１００から複製データ・センター２１０２Ａおよび２１０２Ｂに情報を同期することができる。具体的には、各ジオシンカーは、マスター・データ・センター２１００内部のジオシンク・テーブルからデータを読み出し、このデータを直接複製データ・センター２１０２Ａおよび２１０２Ｂに書き込むことができる。このようなデータは、例えば、プロビジョニング更新またはプロダクト・キー情報更新に関係するデータを含むことができる。

マスター・データ・センター２１００内部のジオシンク・テーブルは、ＯＬＳコア内にあるレコードに対するポインターを収容することができ、これらのレコードを複製データ・センター２１０２Ａまたは２１０２Ｂに同期させることができる。具体的には、ジオシンク・テーブルは、SourceTable名、SourcePartitionキー、SourceRowキー、ModifiedData時刻、およびPublishPendingポインターを収容することができる。ＯＬＳコア・テーブルにおいて書き込みが行われる毎に、例外リストにおける属性のみに影響を与える書き込みを除いて、ジオシンク・テーブル内にレコードが作成される。

図２１には２つのジオシンカー２１１０Ａおよび２１１０Ｂだけが示されるが、この構成はジオシンカー２１１０のプールを含むこともできる。各ジオシンカー２１１０が起動すると(wake up)、複製データ・センター２１０２Ａまたは２１０２Ｂに同期するためのロックを得ようとする。ジオシンカー２１１０はいずれも、いずれの複製データ・センター２１０２Ａまたは２１０２Ｂに同期することもできる。しかしながら、一度に複製データ・センター２１０２Ａまたは２１０２Ｂ毎に１つのジオシンカー２１１０だけがアクティブになることができる。各ジオシンカー２１１０は、１つの複製データ・センター２１０２Ａまたは２１０２Ｂに対する同期を終了しようとした後に、次の複製データ・センター２１０２Ａまたは２１０２Ｂに同期するためのロックを得ようとする。更に、ジオシンカー２１１０は、マスター・データ・センター２１００内部でも実行することができる。種々の実施形態において、マスター・データ・センター２１００は、ロック構成ファイルを収容する。ロック構成ファイルは、全ての複製データ・センター２１０２Ａおよび２１０２Ｂ、対応するロック、対応するロック期間、ジオシンク・テーブル内における対応するPublishPendingフィールド、および実際の同期動作をオンまたはオフに切り替えるためのスイッチを羅列する。加えて、実施形態では、集中同期コントローラー（図示せず）を用いてジオシンカー２１１０の機能を管理することもできる。

いずれの時点においても、いずれの数の新たな複製データ・センターをオンラインに持って行くことができる。新たな複製データ・センターをオンラインに持って行くとき、マスター・データ・センター２１００内部のロック構成ファイルに、新たな複製データ・センターの構成エントリーを追加することができる。最初に、構成エントリーは、新たな複製データ・センターに「オフ」の印を付けて、この複製データ・センターの変更を追跡し始めることを確保することができる。現在の時刻に注目し、現在の時刻までのマスター・データ・センター２１００内部の全てのデータを、新たな複製データ・センターに複製することができる。次いで、構成エントリーは、新たな複製データ・センターに「オン」の印を付けることができる。すると、ジオシンク手順は正常に機能することができる。

災害復旧
本明細書において説明する実施形態によれば、ライセンシング・システム内における多数のデータ・センターの使用、例えば、１つのマスター・データ・センターおよび少なくとも２つの複製データ・センターの使用により、データ・センターの障害の場合に、災害復旧に対処する。例えば、故障したデータ・センターの交換データ・センターとして、いずれの時点においても、新たなデータ・センターをオンラインに接続することができる。また、以前のマスター・データ・センターが故障した場合に、複製データ・センターをマスター・データ・センターに昇格することもできる。加えて、いずれの時点においても計画ダウンタイムを実施することもできる。

災害復旧手順は、ＯＬＳデータを復元するために用いることができる。ＯＬＳはマスター・データ・センターからのデータを複製データ・センターに複製するので、既にライセンシング・システム内部に冗長に構築されたものがある。しかしながら、ジオシンク遅延のために、各複製データ・センター内部のデータは、いずれの時点においてもマスター・データ・センターまたは他の複製データ・センターと１００％同等であることはありそうもない。したがって、災害の発生時に何らかのデータが失われる可能性がある。加えて、ＯＬＳは、権利プロビジョニング・データ、ＯＭＥＸプロビジョニング・データ、およびＢＰＯＳプロビジョニング・データというような、プロビジョニング・データも含むことができる。一部のプロビジョニング・データは、災害の発生時にＯＬＳプロビジョニング・パートナーから復元可能であろうが、ある分量のプロビジョニング・データは失われるかもしれない。したがって、このようなデータを復元することが望ましいであろう。

計画ダウンタイム
図２２は、計画ダウンタイムを実行するための第１ステップを示す模式図である。以下で更に説明するが、第１ステップは、マスター・データ・センター２２００からのコールにサービスすることを停止し、複製データ・センター２２０２および２２０４を同等にすることを含むことができる。

場合によっては、ＯＬＳ内部のマスター・データ・センター２２００を故意に外すこともある。例えば、マスター・データ・センター２２００に間違った構成があってこれを訂正しなければならない場合、またはマスター・データ・センター２２００に入手可能なサービスに大規模な更新があり、マスター・データ・センター２２００が停止しているときでないと実施できない場合もある。

マスター・データ・センター２２００を外そうとするとき、主要複製データ・センター２２０２を、新たなマスター・データ・センターとしてオンラインに接続する。主要複製データ・センター２２０２は、マスター・データ・センター２２００の近くに配置された複製データ・センターであるとよく、マスター・データ・センター２２００が外される場合に新たなマスター・データ・センターに昇格される最初の複製データ・センターである。

実施形態では、各データ・センターに、１から始まる番号が割り当てられる。例えば、マスター・データ・センター２２００には１の番号を割り当てることができ、主要複製データ・センター２２０２には２の番号を割り当てることができ、他の複製データ・センター２２０４には３の番号を割り当てることができる。各データ・センター２２００、２２０２、および２２０４は、それに割り当てられた番号、および最大数を自己認識することができる。この付番システムは、災害のシナリオにおいてある種の判断を行うときに有用であろう。例えば、マスター・データ・センター２２００が故障した場合、主要複製データ・センター２２０２はその番号が２であるので、これを自動的に新たなマスター・データ・センターに昇格させることができる。主要複製データ・センター２２０２が利用できない場合、複製データ・センター２２０４はその番号が３であるので、次に新たなマスター・データ・センターに昇格させることができる。

以上で論じたように、計画ダウンタイムを実行するときの第１ステップは、マスター・データ・センター２２００からのコールにサービスするのを停止し、主要複製データ・センター２２０２を同等にすることとすることができる。これは、マスター・データ・センター２２００を包括ＯＬＳ ＵＲＬ２２０６、即ち、generic.ols.office.com交換(rotation)から削除することによって行うことができる。ＢＰＯＳパートナー２２１０のＢＰＯＳ同期プロバイダー２２０８のシンカー・コンポーネント(syncer component)を停止することができ、公開コンポーネントは、公開するものがなくなるまで、継続することができる。マスターＯＬＳ ＵＲＬ２２１２、即ち、master.ols.office.comに対する全てのコールは、TemporarilyUnavailable例外を戻すことができる。これは、ＯＭＥＸパートナー２２１６のＯＭＥＸ同期プロバイダー２２１４、ＯＬＳ ＡＰＩ、およびＯＬＳパートナーＡＰＩへのコールを含む。加えて、ジオシンカー２２１８は、同期するものがなくなるまで、ジオシンク・プロセスを継続することができる。このプロセスの終了時に、全ての複製データ・センター２２０２および２２０４は、マスター・データ・センター２２００からの全ての同期可能なデータを同期し終えており、事実上マスター・データ・センター２２００と同等になる。

図２３は、計画ダウンタイムを実行するときの第２ステップを示す模式図である。同様に付番された項目は、図２２に関して説明した通りである。第２ステップは、以下で更に説明するように、主要複製データ・センター２２０２を新たなマスター・データ・センターに昇格することを伴えばよい。

この計画ダウンタイムのステップでは、ＢＰＯＳパートナー２２１０のデータ・ベースを、古いマスター・データ・センター、即ち、データ・センター２２００から新たなマスター・データ・センター２２０２にコピーすることができる。ロック構成ファイルを更新することができる。ＯＭＥＸ同期プロバイダー２２１４およびＢＰＯＳ同期プロバイダー２２０８の全てのコンポーネントを、新たなマスター・データ・センター２２０４においてオンに切り替えることができる。新たなマスター・データ・センター２２０２において、全てのＯＬＳ ＡＰＩおよびＯＬＳパートナーＡＰＩコールをオンに切り替えることができる。マスターＯＬＳ ＵＳＬ２２１２を、新たなマスター・データ・センター２２０２にマッピングすることができる。加えて、複製データ・センター２２０４を新たな主要複製データ・センターに指定することができ、ジオシンク・プロセスをオンに切り替えることができる。

このステップの終了時には、古い主要複製データ・センターが新たなマスター・データ・センター２２０２に昇格している。つまり、古いマスター・データ・センター２２００は、この時点で、保守、アップグレード等のために停止させることができる。これらのステップは、逆に古いマスター・データ・センター２２００を現在のマスター・データ・センターに変換するためには、逆に実行すればよい。

実施形態では、新たな複製データ・センターをオンラインに接続することが望ましい場合もある。新たな複製データ・センターは、この複製データ・センターのレコードを、あらゆるデータ・センターのロック構成ファイルに追加し、同期(syncing)を「オフ」に設定することによって、展開することができる。レコードが追加されると、複製データ・センターは実際に新たな複製データ・センターとなる。そうでない場合、これは既存の複製データ・センターとなり、以下のステップは適用されない。一旦レコードがロック構成ファイルに追加されたなら、マスター・データ・センターは、新たな複製データ・センターに同期させる変更を収集し始めることができる。データは、マスター・データ・センターから新たな複製データ・センターにコピーすることができる。コピーが完了した後、新たな複製データ・センターは、マスター・データ・センターのロック構成ファイルにおいて、それ自体のジオシンクをオンに切り替えることができる。加えて、各データ・センターにおいて、最大数のデータ・センターを更新することができる。更に、新たな複製データ・センターをグローバル負荷バランスＵＲＬに追加することができる。

計画外ダウンタイム
計画外ダウンタイムは、種々の理由のために起こる可能性がある。複製データ・センターの計画外ダウンタイムはいずれも、例えば、間欠的または永続的ダウンタイムであっても、他の複製データ・センターにリディレクトするためのグローバル負荷バランサーの修正によって、機敏に扱うことができる。最大ダウンタイムは、グローバル負荷バランサーのＤＮＳエントリーのＴＴＬ時間に依存する場合がある。しかしながら、マスター・データ・センターの計画外ダウンタイムの扱いは機敏さに劣る。マスター・データ・センターは、プロビジョニングを実行しある種のＡＰＩコールにサービスする唯一のデータ・センターであるので、トラフィックを単純にバックアップ・データ・センターにリディレクトすることはできない。

マスター・データ・センターが長期間にわたって予期せずに利用不可能になった場合、主要複製データ・センターを新たなマスター・データ・センターに昇格することができる。これは、ロック構成ファイルを更新し、主要複製データ・センターにおいてＢＰＯＳ同期プロバイダーをオンに切り替え、主要複製データ・センターにおいてＯＭＥＸ同期プロバイダーをオンに切り替えることによって行うことができる。加えて、全てのＯＬＳ ＡＰＩおよびＯＬＳパートナーＡＰＩコールを、主要複製データ・センターにおいてオンに切り替えることができ、マスターＯＬＳ ＵＲＬを主要複製データ・センターにマッピングすることができ、他の複製データ・センターを主要複製データ・センターに指定することができ、ジオシンク・プロセスをオンに切り替えることができる。新たなマスター・データ・センターが指定され、古いマスター・データ・センターが予期せずにオンラインに戻った場合、古いマスター・データ・センターが古い情報を複製データ・センターにジオシンクする(geo-sync)ので、データの不一致(inconsistency)が生ずる可能性がある。したがって、古いマスター・データ・センターが自動的にオンラインに戻ることができないことを保証するために、対策を講じるとよい。例えば、古いマスター・データ・センターをオフに切り替えるために、構成展開(configuration deployment)を用いることもできる。

アプリケーション・ライセンシングの一般的な方法およびシステム
図２４は、アプリケーション・ライセンシング方法２４００のプロセス・フロー図である。種々の実施形態において、方法２４００は、本明細書において説明したライセンシング・システム内においてライセンシング・サービス、例えば、ＯＬＳによって実行される。方法２４００は、ブロック２４０２において開始し、ここでアプリケーションのライセンスがライセンシング・サービスから計算デバイスに戻される。このライセンスは、ライセンスを要求するコールを計算デバイスから受信したことに応答して戻すことができ、ライセンスは、計算デバイスまたはこの計算デバイスのユーザー、あるいはその何らかの組み合わせに基づく。種々の実施形態において、ライセンスは多数の計算デバイスに基づき、この場合、ライセンスのために用いることができる計算デバイスの台数は、ライセンスの条件によって指定される。アプリケーションは、サービス、プログラム、またはアプリケーションであってもよく、マーケットプレース・サービスまたは第三者サービスによって提供することができる。更に、ライセンスは、多数のアプリケーションまたは多数のサービスのためのライセンスであってもよい。加えて、ライセンスは、登録ライセンスまたは永続ライセンスであってもよい。

ブロック２４０４において、ライセンシング・サービスはライセンスの状態を監視する。ライセンスの状態監視は、不正な行為を検出することを含むことができ、不正行為とは、ライセンスの条件によって許可されない行為である。種々の実施形態において、ライセンスの状態監視は、ライセンスが失効しているか否か判断することを含む。ライセンスの状態は、ユーザーによって使用される多数の計算デバイスにまたがって同期させることができる。

ブロック２４０６において、ライセンスの状態にしたがって、ライセンスの条件を調整する。実施形態では、ライセンスの条件調整は、ライセンスが失効した場合ライセンスを解除することを含む。また、ライセンスの条件調整は、ライセンスがユーザーによって更新された場合、ライセンスを再度プロビジョニングすることも含むのでもよい。

実施形態では、ユーザーは、ライセンシング・サービスに接続したままでなくても、アプリケーションを使用することが許可されるのでもよい。しかしながら、ユーザーは、ライセンスの状態の監視を可能にするために、計算デバイスをライセンシング・サービスに周期的に接続するように要求される場合もある。ユーザーが指定時間期間ライセンシング・サービスに接続しない場合、ライセンスを解除することができる。

尚、図２４のプロセス・フロー図は、方法２４００のステップが特定の順序で実行されること、そしてこれらのステップの全てがあらゆる場合に含まれることは全く意図していないことは理解されてしかるべきである。更に、特定の実施態様の詳細に応じて、あらゆる数の追加ステップも方法２４００に含むこともできる。

サービスのライセンスを供与する方法
本明細書では、サービスのライセンスを供与する方法を開示する。この方法は、ライセンシング・サービス内において、ユーザーまたは計算デバイス、あるいはそのあらゆる組み合わせにサービスをライセンスするプル・モデルを使用することを含む。種々の実施形態において、サービスのライセンスを供与する他の方法は、ライセンシング・サービス内において、サービスをユーザーまたは計算デバイスにライセンスするプッシュ・モデルを用いることも含むことができる。

業務連続性を提供する方法
また、本明細書では、データ・センター内部においてまたは多数の地理的に散在するデータ・センターに跨がってデータを連続的に分散するプロセスのプールを含む業務連続性を提供する方法も開示する。更に、業務連続性、ロバスト性、および冗長性を提供するシステムも、本明細書において開示する。このシステムは、１組のロック、これらのロックを得る１組のプロセス、および業務データまたはライセンシング・データ、あるいは双方に対する変更の待ち行列を含む。また、このシステムは、これらの変更を管理するメカニズムと、業務データまたはライセンシング・データ、あるいは双方をデータ・センターに跨がって書き込むメカニズムとを含む。

同期プロバイダーを用いたアプリケーション・ライセンシング方法
図２５は、同期プロバイダーを用いてアプリケーションのライセンスを供与する方法２５００のプロセス・フロー図である。ライセンスされるアプリケーションは、例えば、文書処理アプリケーション、スプレッドシート・アプリケーション、またはプレゼンテーション・アプリケーションでもよい。加えて、アプリケーションは、特定のコマース・パートナーによって提供されるサービスであってもよい。

本方法はブロック２５０２において開始し、ここで、アプリケーションのライセンスを求める要求を、ライセンシング・サービスにおいてクライアント同期プロバイダーから受ける。実施形態では、クライアント同期プロバイダーは、指定されたクライアント計算デバイスに対応し、ライセンスは、指定されたクライアント計算デバイス上におけるアプリケーションの使用を許可する。更に、実施形態では、ライセンスは、クライアント信任状の入力に基づいて、クライアント計算デバイス上におけるアプリケーションの使用を許可する場合もある。

ブロック２５０４において、ライセンスに関係する情報を、アプリケーションを提供するコマース・パートナーから、コマース・パートナーの同期プロバイダーを介して受信する。実施形態では、ライセンシング・サービスが、クライアント同期プロバイダーおよびコマース・パートナーの同期プロバイダーと通信するために多数のプロビジョニングＡＰＩを含む場合がある。

ブロック２５０６において、アプリケーションのライセンスをクライアント計算デバイスに返す。ブロック２５０８において、ライセンスの状態に関する情報を、クライアント同期プロバイダーから受信する。また、ライセンスの状態に関する情報は、コマース・パートナーの同期プロバイダーから受信することもできる。実施形態では、ライセンスの状態は、クライアント同期プロバイダーに対応する多数のクライアント計算デバイスに跨がって同期される場合もある。更に、実施形態では、ライセンスの状態は、ライセンシング・サービスによって直接監視される場合もある。

ブロック２５１０において、ライセンスの状態にしたがって、ライセンスの条件を調整する。例えば、ライセンスが失効状態にある場合、ライセンスを解除することができ、またライセンスが更新状態にある場合、ライセンスを再プロビジョニングすることができる。更に、ライセンスが変換状態を有する場合、ライセンスを異なるライセンスに変換することができる。

尚、図２５のプロセス・フロー図は、方法２５００のステップが特定の順序で実行されること、そしてこれらのステップの全てがあらゆる場合に含まれることを示すことは全く意図していないことは理解されてしかるべきである。更に、特定の実施態様の詳細に応じて、あらゆる数の追加ステップも方法２５００に含むこともできる。例えば、実施形態では、方法２５００が１つ以上のクライアント同期プロバイダーと多数のコマース・パートナーの同期プロバイダーとを含むプラガブル同期プロバイダーのシステムを用いて、アプリケーションをライセンスするステップを含む場合もある。

多数の形態のライセンシングを用いてアプリケーションをライセンスする方法
図２６は、多数の形態のライセンシングを用いてアプリケーションをライセンスする方法２６００のプロセス・フロー図である。この方法はブロック２６０２において開始し、ここで、ライセンシング・サービスを通じて、第１形態のライセンスを第１計算デバイスに提供する。第１形態のライセンスは、ユーザーの信任状またはプロダクト・キーの入力というような、ユーザーによる入力に応答して、第１計算デバイスに提供することができる。ブロック２６０４において、ライセンシング・サービスを通じて、第２形態のライセンスを第２計算デバイスに提供する。第２形態のライセンスは、ユーザー信任状またはプロダクト・キーの入力というような、ユーザーによる入力に応答して第２計算デバイスに提供することができる。種々の実施形態において、第１形態のライセンスおよび第２形態のライセンスは、プロダクト・キーに基づくライセンス、オンライン・ユーザーに基づくライセンス、デバイスに基づくライセンス、またはトークンに基づくライセンス、あるいはそのあらゆる組み合わせを含む。

ブロック２６０６において、第１形態のライセンスの第１状態、および第２形態のライセンスの第２状態を判定し、ブロック２６０８において、第１状態および第２状態を同期させて、組み合わせライセンス状態を形成する。更に、ブロック２６１０において、この組み合わせライセンス状態に基づいてライセンスの条件を調整する。実施形態では、組み合わせライセンス状態が、失効状態、更新状態、変換ライセンス状態、または有効状態、あるいはそのあらゆる組み合わせを含む。組み合わせライセンス状態が失効状態である場合、ライセンスの条件調整はライセンスを解除することを含むことができる。組み合わせライセンス状態が更新状態である場合、ライセンスの条件調整はライセンスを再プロビジョニングすることを含むことができる。組み合わせライセンス状態が有効状態である場合、ライセンスの条件を調整しなくてもよい。組み合わせライセンス状態が変換ライセンス状態である場合、ライセンスを異なるライセンスに変換することができる。

尚、図２６のプロセス・フロー図は、方法２６００のステップが特定の順序で実行されること、そしてこれらのステップの全てがあらゆる場合に含まれることを示すことは全く意図していないことは理解されてしかるべきである。更に、特定の実施態様の詳細に応じて、あらゆる数の追加ステップも方法２６００に含むこともできる。例えば、方法２６００は、組み合わせライセンス状態に基づいて不正行為を検出するステップを含むこともでき、不正行為は、ライセンスの条件によって許可されない行為を含む。次いで、不正行為の検出に基づいて、ライセンスの条件を調整することができる。

デバイスに対してアプリケーションをライセンスする方法
図２７は、デバイスに対してアプリケーションをライセンスする方法２７００のプロセス・フロー図である。この方法は、ブロック２７０２において開始し、ここで、ユーザーによって使用される多数の計算デバイスに、ライセンシング・サービスから、アプリケーションのライセンスを提供する。アプリケーションのライセンスは、信任状を含むことができる。ライセンスは、ユーザーによる入力に応答して、各計算デバイスに提供することができる。

ブロック２７０４において、信任状を計算デバイスの各々に関連付ける。例えば、各計算デバイスの識別を信任状と関連付けることができる。一旦信任状が特定の計算デバイスと関連付けられたなら、ライセンシング・サービスに接続することなく、指定の時間期間計算デバイス上でアプリケーションを使用することをユーザーに許可することができる。

ブロック２７０６において、計算デバイスの各々におけるライセンスに対応する登録の状態を周期的に判定する。種々の実施形態において、各計算デバイスにおける登録の状態は、ライセンスの条件によって指定される構成可能な時間期間によって判定される。計算デバイスにおける登録の状態は、計算デバイスから受けるチェック登録状態コールに応答して判定することができる。チェック登録状態コールは、計算デバイスによって実行される登録状態チェックの成果を含むことができる。次いで、ライセンスの条件を、各計算デバイスにおける登録の状態に基づいて調整することができる。例えば、特定の計算デバイスにおいて登録が失効している場合、ライセンスを解除することができ、特定の計算デバイスにおいて登録が更新されている場合、ライセンスを再プロビジョニングすることができる。加えて、登録が特定の計算デバイスにおいて変換されている場合、ライセンスを異なるライセンスに変換することができる。

尚、図２７のプロセス・フロー図は、方法２７００のステップが特定の順序で実行されること、そしてこれらのステップの全てがあらゆる場合に含まれることを示すことは全く意図していないことは理解されてしかるべきである。更に、特定の実施態様の詳細に応じて、あらゆる数の追加ステップも方法２７００に含むこともできる。

ユーザーに基づいてライセンスをアプリケーションに提供する方法
図２８は、ユーザーに基づいてアプリケーションのライセンス供与を提供する方法２８００のプロセス・フロー図である。この方法はブロック２８０２において開始し、ここでユーザーによる入力に応答して、ライセンシング・サービスにおいて、計算デバイスからユーザー・ログイン情報を受信する。ユーザー・ログイン情報は、ライセンシング・サービス、またはライセンシング・サービスに関連付けられたコマース・パートナーと関連付けることができる。

ブロック２８０４において、アプリケーションのライセンスを計算デバイスに提供する。ここで、ライセンスは、ユーザーに関連付けられたデバイス特定情報を含む。デバイス特定情報は、ライセンスにしたがってアプリケーションを使用するためにユーザーがプロビジョニングされる計算デバイスに関係する情報を含むことができる。加えて、デバイス特定情報は、ライセンスにしたがってアプリケーションを使用するためにユーザーがプロビジョニングされることが許可される計算デバイスの総数も含むことができる。

ブロック２８０６において、デバイス特定情報の入力を用いて、計算デバイス上でアプリケーションをアクティベートする。次いで、計算デバイス上でアプリケーションを使用することをユーザーに許可することができる。実施形態では、計算デバイスをライセンシング・サービスに接続することなく、指定された時間期間計算デバイス上でアプリケーションを使用することがユーザーに許可される場合もある。

実施形態では、計算デバイスからの入力に応答して、ライセンスの状態を周期的に判定してもよい。この入力は、計算デバイスによって実行されるライセンス状態チェックの成果を含む。ライセンスの状態は、ライセンシング・サービスまたはライセンス自体によって指定される構成可能な時間周期毎にチェックすることもできる。次いで、ライセンスの状態に基づいて、ライセンスの条件を調整することができる。

尚、図２８のプロセス・フロー図は、方法２８００のステップが特定の順序で実行されること、そしてこれらのステップの全てがあらゆる場合に含まれることを示すことは全く意図していないことは理解されてしかるべきである。更に、特定の実施態様の詳細に応じて、あらゆる数の追加ステップも方法２８００に含むこともできる。例えば、アプリケーションのライセンスが、ユーザーによって使用される多数の計算デバイスに跨がってローミングされてもよい。

以上、構造的特徴および／または方法論的動作に特定的な文言で、主題について説明したが、添付する特許請求の範囲において定められる主題は、必ずしも以上で説明した特定的な特徴や動作には限定されないことは理解されてしかるべきである。逆に、以上で説明した特定的な特徴や動作は、特許請求の範囲を実現する形態例として開示されたまでである。

Claims (10)

1. 同期プロバイダーを用いてアプリケーション（２２０）をライセンスする方法であって、
   ライセンシング・サービス（３０２）においてクライアント同期プロバイダー（３０４Ｄ)からアプリケーション（２２０）のライセンスを求める要求を受けるステップ（２５０２）と、
   前記アプリケーション（２２０）を提供するコマース・パートナーから前記ライセンスに関する情報を、コマース・パートナーの同期プロバイダーを介して受信するステップ（２５０４）と、
   前記アプリケーション（２２０）のライセンスをクライアント計算デバイス（３０８）に返すステップ（２５０６）と、
   前記ライセンスの状態に関する情報を、前記クライアント同期プロバイダー（３０４Ｄ)から受信するステップ（２５０８）と、
   前記ライセンスの状態にしたがって、前記ライセンスの条件を調整するステップ（２５１０）と、
   を含む、方法。
2. 請求項１記載の方法であって、前記ライセンスの状態に関する情報を、前記コマース・パートナーの同期プロバイダーから受信するステップを含む、方法。
3. 請求項１記載の方法であって、１つ以上のクライアント同期プロバイダー（３０４Ｄ)と複数のコマース・パートナーの同期プロバイダーとを含むプラガブル同期プロバイダーのシステムを用いて、アプリケーション（２２０）をライセンスするステップを含む、方法。
4. 請求項１記載の方法であって、前記クライアント同期プロバイダー（３０４Ｄ)に対応する複数のクライアント計算デバイス（３０８）に跨がって前記ライセンスの状態を同期させるステップを含む、方法。
5. 請求項１記載の方法であって、前記ライセンスの状態が失効状態を含む場合、前記ライセンスを解除するステップを含む、方法。
6. 請求項１記載の方法であって、前記ライセンスの状態が更新状態を含む場合、前記ライセンスを再プロビジョニングするステップを含む、方法。
7. 請求項１記載の方法であって、前記ライセンスの状態が変換状態である場合、前記ライセンスを第２ライセンスに変換するステップを含む、方法。
8. 同期プロバイダーを用いてアプリケーション（２２０）をライセンスするシステムであって、
   クライアント同期プロバイダー（３０４Ｄ）であって、
   コマース・パートナーからのプロビジョニング要求をコマース・パートナーの同期プロバイダーを介して受け、
   アプリケーション（２２０）のライセンスを要求するシステム・コールをライセンシング・サービス（３０２）に送り、
   前記ライセンスの状態を周期的に判定および更新する、
   ように構成された、クライアント同期プロバイダー（３０４Ｄ）と、
   前記ライセンシング・サービス（３０２）であって、
   前記アプリケーション（２２０）のライセンスをクライアント計算デバイス（３０８）に戻し、
   前記ライセンスの状態に関する情報を前記クライアント同期プロバイダー（３０４Ｄ）から受信し、
   前記ライセンスの状態にしたがって、前記ライセンスの条件を調整する、
   ように構成された、ライセンシング・サービス（３０２）と、
   を含む、システム。
9. 請求項８記載のシステムであって、コマース・パートナーの同期プロバイダーおよびクライアント同期プロバイダー（３０４Ｄ）のプラガブル・システムを含み、各クライアント同期プロバイダー（３０４Ｄ）が、１つ以上のコマース・パートナーの同期プロバイダーからライセンシング要求を受けるように構成される、システム。
10. 請求項８記載のシステムであって、前記クライアント同期プロバイダー（３０４Ｄ）に対応する複数のクライアント計算デバイス（３０８）に跨がって前記ライセンスの状態を同期させるように構成されたシステムを含む、システム。

Images