JP5763780B2 - ドメイン信頼評価機能およびドメインポリシー管理機能を有するスマートカード - Google Patents

Description

本発明は、無線通信に関する。

関連出願の相互参照
本出願は、２０１０年１２月６日に出願された米国特許仮出願第６１／４２０，１６２号明細書の利益を主張するものであり、この仮出願の内容は、その全体が参照によって本明細書に組み込まれている。

今日では、その他のデバイスまたはエンティティと通信することができるまたは通信することができないコンピューティングデバイス、またはそのデバイス内の何らかの部分もしくはコンピューティング環境が、個人、組織、またはその他の何らかのエンティティによって「所有される」という様式でそのデバイスが使用される多くの状況がある。「所有される」という用語は、デバイス、またはそのデバイス内の何らかの部分もしくはコンピューティング環境が、エンティティに対して認証された可能性があるということ、および／またはそのエンティティが、その後に、そのデバイスもしくはそのデバイスの何らかの部分に対して何らかの形態の制御を得た可能性があるということを示すことができる。そのような状況の一例は、ワイヤレスデバイス（たとえば、モバイル電話）のユーザがモバイル通信ネットワークオペレータのサービスに加入することができるワイヤレスモバイル通信業界にある。

モバイル通信デバイスに伴う上述の状況のような、今日の多くのコンピューティングコンテキストにおける問題は、コンピューティングデバイスが、単一のエンティティによってそのデバイスの全体を「所有される」ことに限定される場合があるということである。そして多くのケースにおいては、所有権は、ユーザによるデバイスの購入の時点で確立される場合があり、それによって、もっと後の時点で所有権を確立することが望ましい場合があるビジネスモデルが妨げられる。さらに、これらの限定によって、デバイスのうちの複数の互いに分離された部分の複数の所有権が存在すること、または所有権が随時その他のエンティティに移転されることが望ましい場合がある状況においてデバイスを使用することが妨げられる。たとえば、ワイヤレスモバイル通信デバイス（たとえば、モバイル電話）のケースにおいては、ユーザは、購入の時点で特定のモバイルネットワークオペレータのサービスに加入する場合がある。また、そのようなデバイスが一度に複数のオペレータネットワークにアクセスを提供することは可能ではない場合がある。モバイルネットワークおよびサービスのサブスクリプションを更新または変更することは困難である場合があり、それを無線で行うことは可能ではない場合がある。

また、特にワイヤレスモバイル通信デバイスのコンテキストにおいては、コンピューティングデバイスは、加入者識別モジュール（ＳＩＭ）または汎用集積回路カード（ＵＩＣＣ）を含むことができ、これらを用いて、ユーザは、特定のネットワークオペレータのサービスに加入することができる。残念なことに、このＳＩＭ／ＵＩＣＣメカニズムは、単一のネットワークオペレータでの使用に限定される場合がある。加えて、ＳＩＭ／ＵＩＣＣメカニズムは一般に、高度にセキュアであるとみなされているが、セキュリティは、そのＳＩＭ／ＵＩＣＣメカニズムが存在するデバイス全体のセキュリティプロパティに強くリンクされていない。このことによって、モバイルファイナンシャルトランザクションなどの進化したサービスおよび用途のためにセキュリティコンセプトを拡張するという応用が制限される。とりわけ、これらの欠点は、Ｍ２Ｍ（ｍａｃｈｉｎｅ−ｔｏ−ｍａｃｈｉｎｅ）通信デバイスなどの自律的なデバイスに関連する。

この「発明の概要」は、以降の「発明を実施するための形態」でさらに説明されるさまざまなコンセプトを、簡略化された形式で紹介するために提供されている。この「発明の概要」は、特許請求される主題の鍵となる特徴または必要不可欠な特徴を特定することを意図されておらず、特許請求される主題の範囲を限定するために使用されることも意図されていない。

本明細書においては、１つまたは複数のデバイス上の１つまたは複数の別々のドメインが、１人または複数の別々のローカルまたはリモートの所有者によって所有または制御され、それと同時に、それらのドメインについてのあるレベルのシステムワイドな管理を提供することを可能にするシステム、方法、および手段について記載する。例示的な一実施形態によれば、これらの方法および手段は、１つまたは複数のデバイスを含むことができ、それらのデバイスのそれぞれは、少なくとも１つのプラットフォームによってサポートされている１つまたは複数のドメインを含むことができる。それぞれのドメインは、そのドメインのローカルにまたはそのドメインからリモートに位置する場合があるそのドメインの所有者のための機能を実行するように構成することができる。それぞれのドメインは、別々の所有者を有することができ、それぞれの所有者は、自分のドメインのオペレーションのための、ならびに、自分のドメインが存在しているプラットフォームに関連した、およびその他のドメインに関連したそのドメインのオペレーションのためのポリシーを指定することができる。

ドメインのうちの１つは、セキュリティドメインとすることができ、セキュリティドメインは、外部ステークホルダ（stakeholder）と、そのセキュリティドメインとの間における信頼のレベルを決定するように構成することができる。加えて、システムワイドドメインマネージャが、それらのドメインのうちの１つの上に存在していることが可能である。システムワイドドメインマネージャは、セキュリティドメインに対して補助的であることが可能である。システムワイドドメインマネージャは、セキュリティドメインから受信された特権レベルに基づいて１つまたは複数の補助ドメインの上でポリシーを実施するように構成することができる。特権レベルは、外部ステークホルダと、セキュリティドメインとの間における信頼のレベルに基づくことができる。システムワイドドメインマネージャは、セキュリティドメインから受信された特権レベルに基づくことができる自律のレベルを伴ってポリシーを実施することができる。

システムワイドドメインマネージャは、自分自身のポリシーを実施するように構成することができ、また、セキュリティドメインのポリシーが、システムワイドドメインマネージャのポリシーと矛盾している場合には、セキュリティドメインのポリシーを実施するように構成することもできる。システムワイドドメインマネージャは、自分が存在しているドメインのポリシーを実施するように構成することもでき、また、自分が存在しているドメインに関連して、その他のドメインが各自のポリシーをどのように実施することができるかを調整することができる。加えて、システムワイドドメインマネージャは、その他のドメインどうしの間における対話を、それらのその他のドメインどうしのそれぞれのポリシーに従って調整することができる。システムワイドドメインマネージャが存在しているドメインは、そのドメインを収容しているデバイスの所有者によって所有されることが可能である。あるいは、そのようなドメインは、そのドメインを収容しているデバイスを所有することができない所有者によって所有されることも可能である。

ドメインアプリケーションが、ドメインのうちの１つの上に存在することもできる。ドメインアプリケーションは、プラットフォームへポートすることができる。たとえば、ドメインアプリケーションは、ドメインの少なくとも１人の所有者と、ドメインの少なくとも１人のその他の所有者との間における関係に基づいて、プラットフォームへポートすることができる。

本明細書に記載されているシステム、方法、および手段のその他の特徴は、以降の詳細な説明および添付の図面において提供されている。

以降の説明から、より詳細な理解を得ることができ、以降の説明は、例として添付の図面とともに与えられている。
１つまたは複数の開示されている実施形態を実施することができる例示的な通信システムを示す図である。 １つまたは複数の開示されている実施形態を実施することができる例示的な無線送信／受信ユニット（ＷＴＲＵ）を示す図である。 １つまたは複数の開示されている実施形態を実施することができる例示的な無線アクセスネットワークを示す図である。 ドメインの所有権を取得するプロセスの例示的な一実施形態を示す図である。 ドメインの所有権を取得するプロセスの例示的な一実施形態を示す図である。 グローバルプラットフォーム（ＧＰ）アーキテクチャの例示的な一実施形態を示す図である。 ハイレベルユーザ機器（ＵＥ）デバイスアーキテクチャの一部としてのＴＨＳＭの例示的な一実施形態を示す図である。 ＧＰセキュリティドメイン（ＳＤ）階層を示す図である。 ＧＰ ＳＤ構造の一構成を示す図である。 ＧＰ ＳＤ構造の別の構成を示す図である。 ＧＰ ＳＤ構造の別の構成を示す図である。 一般的なＧＰ設定におけるＳＤ状態およびそれらの遷移メカニズムを示す図である。 ＴＤＭ ＳＤのライフサイクル状態に固有のメッセージングの詳細および注釈を示す図である。 ＴＤＭ ＳＤのライフサイクル状態に固有のメッセージングの詳細および注釈を示す図である。 ＴＤＭ ＳＤのライフサイクル状態に固有のメッセージングの詳細および注釈を示す図である。 ＧＰにおいてアプリケーションが取得することができるさまざまな状態を示す図である。 ＲＴＯ前の信頼できるドメインのインストレーションに関する進展を示す図である。 ＲＴＯ前の信頼できるドメインのインストレーションに関する進展を示す図である。 ＲＴＯ前の信頼できるドメインのインストレーションに関する進展を示す図である。 ＲＴＯポーティングのためのシーケンスを示す図である。 ＲＴＯポーティングのためのシーケンスを示す図である。 登録および／または証明書ロールアウトプロトコルを示す図である。 登録および／または証明書ロールアウトプロトコルを示す図である。 図１４および図１４Ａの登録および／または証明書ロールアウトプロトコルの続きを示す図である。 証明書を発信元カードから宛先カードへ移動させるための修正された移行プロセスを示す図である。

図１Ａ〜図１６は、開示されているシステム、方法、および手段を実施することができる例示的な実施形態に関する。本明細書に記載されている実施形態は、例示的であること、および限定的でないことを意図されている。本明細書においては、プロトコルフローについて例示および説明する場合があるが、それらのフローの順序を変更することができ、一部を省略することができ、および／またはさらなるフローを追加することができる。

図１Ａ、図１Ｂ、および図１Ｃは、本明細書に記載されている実施形態において使用することができる例示的な通信システムおよびデバイスを示している。図１Ａは、１つまたは複数の開示されている実施形態を実施することができる例示的な通信システム１００の図である。通信システム１００は、コンテンツ、たとえば音声、データ、ビデオ、メッセージング、放送などを複数のワイヤレスユーザに提供するマルチプルアクセスシステムとすることができる。通信システム１００は、複数のワイヤレスユーザが、ワイヤレス帯域幅を含むシステムリソースの共有を通じてそのようなコンテンツにアクセスすることを可能にすることができる。たとえば、通信システム１００は、１つまたは複数のチャネルアクセス方法、たとえば符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）などを採用することができる。

図１Ａにおいて示されているように、通信システム１００は、無線送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク１０６、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、およびその他のネットワーク１１２を含むことができるが、開示されている実施形態では、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素が考えられるということがわかるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのそれぞれは、ワイヤレス環境において動作および／または通信を行うように構成されている任意のタイプのデバイスとすることができる。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ワイヤレス信号を送信および／または受信するように構成することができ、ユーザ機器（ＵＥ）、移動局、固定式または移動式のサブスクライバーユニット、ページャー、セルラ電話、携帯情報端末（ＰＤＡ）、スマートフォン、タブレット、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、家庭用電化製品などを含むことができる。

通信システム１００は、基地局１１４ａおよび基地局１１４ｂを含むこともできる。基地局１１４ａ、１１４ｂのそれぞれは、コアネットワーク１０６、インターネット１１０、および／またはネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つとワイヤレスにインターフェースを取るように構成されている任意のタイプのデバイスとすることができる。例として、基地局１１４ａ、１１４ｂは、ベーストランシーバ局（ＢＴＳ）、Ｎｏｄｅ−Ｂ、ｅＮｏｄｅ Ｂ、ホームノードＢ、ホームｅＮｏｄｅ Ｂ、サイトコントローラ、アクセスポイント（ＡＰ）、ワイヤレスルータなどとすることができる。基地局１１４ａ、１１４ｂは、それぞれ単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含むことができるということがわかるであろう。

基地局１１４ａは、ＲＡＮ１０４の一部とすることができ、ＲＡＮ１０４は、その他の基地局および／またはネットワーク要素（図示せず）、たとえば基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどを含むこともできる。基地局１１４ａおよび／または基地局１１４ｂは、特定の地理的領域内でワイヤレス信号を送信および／または受信するように構成することができ、この地理的領域は、セル（図示せず）と呼ばれることもある。セルは、複数のセルセクタへとさらに分割することができる。たとえば、基地局１１４ａに関連付けられているセルは、３つのセクタへと分割することができる。したがって一実施形態においては、基地局１１４ａは、３つのトランシーバ、すなわち、セルのそれぞれのセクタごとに１つのトランシーバを含むことができる。一実施形態においては、基地局１１４ａは、多重入力‐多重出力（ＭＩＭＯ）技術を採用することができ、したがって、セルのそれぞれのセクタごとに複数のトランシーバを利用することができる。

基地局１１４ａ、１１４ｂは、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数と通信することができ、エアインターフェース１１６は、任意の適切なワイヤレス通信リンク（たとえば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）とすることができる。エアインターフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立することができる。

より具体的には、上述したように、通信システム１００は、マルチプルアクセスシステムとすることができ、１つまたは複数のチャネルアクセススキーム、たとえばＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどを採用することができる。たとえば、ＲＡＮ１０４内の基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ユニバーサル移動体通信システム（ＵＭＴＳ）地上波無線アクセス（ＵＴＲＡ）などの無線技術を実施することができ、この無線技術は、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインターフェース１１６を確立することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または発展型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含むことができる。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含むことができる。

別の実施形態においては、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、拡張ＵＭＴＳ地上波無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実施することができ、この無線技術は、ロングタームエボリューション（ＬＴＥ）および／または拡張ＬＴＥ（ＬＴＥ−Ａ）を使用してエアインターフェース１１６を確立することができる。

その他の実施形態においては、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、無線技術、たとえばＩＥＥＥ ８０２．１６（すなわちＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、グローバル移動体通信システム（ＧＳＭ（登録商標））、ＧＳＭエボリューション用の拡張データ転送速度（ＥＤＧＥ）、ＧＳＭ ＥＤＧ（ＥＧＥＲＡＮ）などを実施することができる。

図１Ａにおける基地局１１４ｂは、たとえばワイヤレスルータ、ホームノードＢ、ホームｅＮｏｄｅ Ｂ、またはアクセスポイントとすることができ、局所的なエリア、たとえば事業所、家庭、乗り物、キャンパスなどにおけるワイヤレス接続を容易にするために、任意の適切なＲＡＴを利用することができる。一実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立するために、ＩＥＥＥ ８０２．１１などの無線技術を実施することができる。一実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立するために、ＩＥＥＥ ８０２．１５などの無線技術を実施することができる。さらなる一実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ピコセルまたはフェムトセルを確立するために、セルラベースのＲＡＴ（たとえば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用することができる。図１Ａにおいて示されているように、基地局１１４ｂは、インターネット１１０への直接接続を有することができる。したがって、基地局１１４ｂは、コアネットワーク１０６を介してインターネット１１０にアクセスすることを不要とすることができる。

ＲＡＮ１０４は、コアネットワーク１０６と通信状態にあることが可能であり、コアネットワーク１０６は、音声、データ、アプリケーション、および／またはボイスオーバーインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数に提供するように構成されている任意のタイプのネットワークとすることができる。たとえば、コアネットワーク１０６は、コール制御、課金サービス、モバイルロケーションベースサービス、プリペイドコーリング、インターネット接続、ビデオ配信などを提供すること、および／またはユーザ認証などのハイレベルセキュリティ機能を実行することが可能である。図１Ａにおいては示されていないが、ＲＡＮ１０４および／またはコアネットワーク１０６は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを採用しているその他のＲＡＮと直接または間接の通信状態にあることが可能であるということがわかるであろう。たとえば、コアネットワーク１０６は、Ｅ−ＵＴＲＡ無線技術を利用している可能性があるＲＡＮ１０４に接続されていることに加えて、ＧＳＭ無線技術を採用している別のＲＡＮ（図示せず）と通信状態にあることも可能である。

コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／またはその他のネットワーク１１２にアクセスするためのゲートウェイとして機能することもできる。ＰＳＴＮ１０８は、基本電話サービス（ＰＯＴＳ／ｐｌａｉｎ ｏｌｄ ｔｅｌｅｐｈｏｎｅ ｓｅｒｖｉｃｅ）を提供する回路交換電話ネットワークを含むことができる。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおける伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）など、共通の通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスからなるグローバルシステムを含むことができる。ネットワーク１１２は、その他のサービスプロバイダによって所有および／または運営されている有線またはワイヤレスの通信ネットワークを含むことができる。たとえば、ネットワーク１１２は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを採用している可能性がある１つまたは複数のＲＡＮに接続されている別のコアネットワークを含むことができる。

通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちのいくつかまたはすべては、マルチモード機能を含むことができ、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、別々のワイヤレスリンクを介して別々のワイヤレスネットワークと通信するために複数のトランシーバを含むことができる。たとえば、図１Ａにおいて示されているＷＴＲＵ１０２ｃは、セルラベースの無線技術を採用している可能性がある基地局１１４ａ、およびＩＥＥＥ ８０２無線技術を採用している可能性がある基地局１１４ｂと通信するように構成することができる。

図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂにおいて示されているように、ＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送信／受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、取り外し不能メモリ１３０、取り外し可能メモリ１３２、電源１３４、全世界測位システム（ＧＰＳ）チップセット１３６、およびその他の周辺機器１３８を含むことができる。ＷＴＲＵ１０２は、一実施形態との整合性を保持しながら、上述の要素どうしの任意の下位組合せを含むことができるということがわかるであろう。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連付けられている１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、その他の任意のタイプの集積回路（ＩＣ）、状態マシンなどとすることができる。プロセッサ１１８は、信号コーディング、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ１０２をワイヤレス環境内で機能できるようにするその他の任意の機能を実行することができる。プロセッサ１１８は、トランシーバ１２０に結合することができ、トランシーバ１２０は、送信／受信要素１２２に結合することができる。図１Ｂは、プロセッサ１１８とトランシーバ１２０を別々のコンポーネントとして示しているが、プロセッサ１１８とトランシーバ１２０は、１つの電子パッケージまたはチップ内に統合することができるということがわかるであろう。

送信／受信要素１２２は、エアインターフェース１１６を介して、基地局（たとえば、基地局１１４ａ）に信号を送信するように、または基地局（たとえば、基地局１１４ａ）から信号を受信するように構成することができる。たとえば、一実施形態においては、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されているアンテナとすることができる。一実施形態においては、送信／受信要素１２２は、たとえば、ＩＲ信号、ＵＶ信号、または可視光信号を送信および／または受信するように構成されているエミッタ／検知器とすることができる。一実施形態においては、送信／受信要素１２２は、ＲＦ信号と光信号との両方を送信および受信するように構成することができる。送信／受信要素１２２は、ワイヤレス信号の任意の組合せを送信および／または受信するように構成することができるということがわかるであろう。

加えて、送信／受信要素１２２は、図１Ｂにおいては単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含むことができる。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用することができる。したがって、一実施形態においては、ＷＴＲＵ１０２は、エアインターフェース１１６を介してワイヤレス信号を送信および受信するために、複数の送信／受信要素１２２（たとえば、複数のアンテナ）を含むことができる。

トランシーバ１２０は、送信／受信要素１２２によって送信される信号を変調するように、また、送信／受信要素１２２によって受信される信号を復調するように構成することができる。上述したように、ＷＴＲＵ１０２は、マルチモード機能を有することができる。したがってトランシーバ１２０は、ＷＴＲＵ１０２が、たとえばＵＴＲＡおよびＩＥＥＥ ８０２．１１など、複数のＲＡＴを介して通信できるようにするために複数のトランシーバを含むことができる。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（たとえば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニットまたは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合することができ、そこからユーザ入力データを受け取ることができる。プロセッサ１１８は、ユーザデータをスピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８へ出力することもできる。加えて、プロセッサ１１８は、取り外し不能メモリ１３０および／または取り外し可能メモリ１３２など、任意のタイプの適切なメモリからの情報にアクセスすること、およびそれらのメモリにデータを格納することが可能である。取り外し不能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、ハードディスク、またはその他の任意のタイプのメモリストレージデバイスを含むことができる。取り外し可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード／汎用集積回路カード（ＵＩＣＣ）、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを含むことができる。ＳＩＭ／ＵＩＣＣは、セキュアな実行および格納環境をワイヤレスデバイスに提供することができ、その環境から、認証アルゴリズムが実行され、証明書が格納され、その証明書によって、デバイスは、ネットワークオペレータに対するデバイスのユーザのサブスクリプションをネットワークオペレータに対して認証することができ、および／またはネットワークオペレータは、デバイスに対する何らかの形態の制御、すなわち、所有権を有することができる。その他の実施形態においては、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）上など、ＷＴＲＵ１０２上に物理的に配置されていないメモリからの情報にアクセスすること、およびそれらのメモリにデータを格納することが可能である。

プロセッサ１１８は、電源１３４から電力を受け取ることができ、また、ＷＴＲＵ１０２内のその他のコンポーネントへの電力を分配および／または制御するように構成することができる。電源１３４は、ＷＴＲＵ１０２に電力供給するための任意の適切なデバイスとすることができる。たとえば、電源１３４は、１つまたは複数の乾電池（たとえばニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、燃料電池などを含むことができる。

プロセッサ１１８は、ＧＰＳチップセット１３６に結合することもでき、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（たとえば、経度および緯度）を提供するように構成することができる。ＧＰＳチップセット１３６からの情報に加えて、またはその情報の代わりに、ＷＴＲＵ１０２は、基地局（たとえば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１６を介して位置情報を受信すること、および／または複数の近隣の基地局から受信されている信号のタイミングに基づいて自分の位置を特定することが可能である。ＷＴＲＵ１０２は、一実施形態との整合性を保持しながら、任意の適切な位置特定方法を通じて位置情報を得ることができるということがわかるであろう。

プロセッサ１１８は、その他の周辺機器１３８にさらに結合することができ、その他の周辺機器１３８は、さらなる特徴、機能、および／または有線接続もしくはワイヤレス接続を提供する１つまたは複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含むことができる。たとえば、周辺機器１３８は、加速度計、ｅ−コンパス、衛星トランシーバ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビジョントランシーバ、ハンドフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタルミュージックプレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含むことができる。

図１Ｃは、一実施形態によるＲＡＮ１０４およびコアネットワーク１０６のシステム図である。上述したように、ＲＡＮ１０４は、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＵＴＲＡ無線技術を採用することができる。ＲＡＮ１０４は、コアネットワーク１０６と通信状態にあることも可能である。

ＲＡＮ１０４は、ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃを含むことができるが、ＲＡＮ１０４は、一実施形態との整合性を保持しながら、任意の数のｅＮｏｄｅ−Ｂを含むことができるということがわかるであろう。ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃはそれぞれ、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために１つまたは複数のトランシーバを含むことができる。一実施形態においては、ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃは、ＭＩＭＯ技術を実施することができる。したがって、ｅＮｏｄｅ−Ｂ１４０ａは、たとえば、ＷＴＲＵ１０２ａにワイヤレス信号を送信するために、およびＷＴＲＵ１０２ａからワイヤレス信号を受信するために、複数のアンテナを使用することができる。

図１Ｃにおいて示されているように、Ｎｏｄｅ−Ｂ１４０ａ、１４０ｂは、ＲＮＣ１４２ａと通信状態にあることが可能である。加えて、Ｎｏｄｅ−Ｂ１４０ｃは、ＲＮＣ１４２ｂと通信状態にあることが可能である。Ｎｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃは、Ｉｕｂインターフェースを介してそれぞれのＲＮＣ１４２ａ、１４２ｂと通信することができる。ＲＮＣ１４２ａ、１４２ｂは、Ｉｕｒインターフェースを介して互いに通信状態にあることが可能である。ＲＮＣ１４２ａ、１４２ｂのそれぞれは、自分が接続されているそれぞれのＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃを制御するように構成することができる。加えて、ＲＮＣ１４２ａ、１４２ｂのそれぞれは、アウターループ電力制御、負荷制御、アドミッション制御、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、データ暗号化など、その他の機能を実行および／またはサポートするように構成することができる。

図１Ｃにおいて示されているコアネットワーク１０６は、メディアゲートウェイ（ＭＧＷ）１４４、移動交換センタ（ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１４８、および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０を含むことができる。上述の要素のうちのそれぞれは、コアネットワーク１０６の一部として示されているが、これらの要素のいずれかが、コアネットワークオペレータ以外のエンティティによって所有および／または運営されることも可能であるということがわかるであろう。

ＲＡＮ１０４内のＲＮＣ１４２ａは、ＩｕＣＳインターフェースを介してコアネットワーク１０６内のＭＳＣ１４６に接続することができる。ＭＳＣ１４６は、ＭＧＷ１４４に接続することができる。ＭＳＣ１４６およびＭＧＷ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、従来の地上通信線の通信デバイスとの間における通信を容易にするために、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。

ＲＡＮ１０４内のＲＮＣ１４２ａは、ＩｕＰＳインターフェースを介してコアネットワーク１０６内のＳＧＳＮ１４８に接続することもできる。ＳＧＳＮ１４８は、ＧＧＳＮ１５０に接続することができる。ＳＧＳＮ１４８およびＧＧＳＮ１５０は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＩＰ対応デバイスとの間における通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。

上述したように、コアネットワーク１０６は、ネットワーク１１２に接続することもでき、ネットワーク１１２は、その他のサービスプロバイダによって所有および／または運営されているその他の有線またはワイヤレスのネットワークを含むことができる。

上述した通信システムおよび／またはデバイスは、本明細書において説明されているように、グローバルプラットフォーム（ＧＰ）スマートカードとともに使用することができる。ＧＰスマートカードアーキテクチャは、単一のデバイス上での１つまたは複数のアプリケーションのためのサポートを提供することができる。比較的オープンな環境内に多数のおよび／または多様な数のアプリケーションを収容すると、セキュリティ上の課題、たとえばマルウェア、ウイルス、ボットからの攻撃、および／または同様のセキュリティ上の課題などが提示される場合がある。それらのセキュリティ上の課題は、絶え間なく続く、および／または常に存在する可能性がある。ＧＰセキュリティメカニズムは、そのカードマネージャの最終的な監督のもとで実行することができるＧＰのセキュリティドメイン（ＳＤ）構造を介して、セキュリティ攻撃からの保護を提供することができる。ＧＰセキュリティ機能は、インテグリティおよび／または信頼性の検証を含むことができる。たとえば、インテグリティおよび／または信頼性の検証は、カード上にロードされるアプリケーションコードおよび／またはデータに適用することができ、これは、たとえばＳＤセキュリティポリシーによって要求される場合がある。その上、プログラムの動作をＳＤおよび／またはマネージャレベルでモニタすることができる。アプリケーションに関連付けられている脅威が検知された場合には、そのアプリケーションを、「ロックされた」状態へと移行することができる。しかし、ＧＰのセキュリティおよび機能への追加を行うことができる。本明細書における実施形態は、たとえばスマートカード、加入者識別モジュール（ＳＩＭ）、汎用集積回路カード（ＵＩＣＣ）、またはその他のカード上の環境上で実行することができるＧＰスマートカードおよび／またはＧＰアーキテクチャに関連して説明されているかもしれないが、本明細書に記載されている実施形態は、たとえば仮想加入者識別モジュール（ｖＳＩＭ）、または組み込まれた信頼環境を有するその他のプラットフォームなど、さまざまなカード外（ｏｆｆ−ｃａｒｄ）の環境において採用することもできるということが理解できるであろう。

ＧＰアーキテクチャに関して、ＧＰ動作環境は、スマートカード上で構成される許容されるアプリケーションスイートに関する柔軟性を提供することができる。ＴＤ（Ｔｒｕｓｔｅｄ Ｄｏｍａｉｎ）コンセプトは、ＴＨＳＭ（Ｔｒｕｓｔｅｄ Ｈａｒｄｗａｒｅ Ｓｕｂｓｃｒｉｂｅｒ Ｍｏｄｕｌｅ）のそのオリジナルの設定から、ＧＰ準拠のスマートカードへ、Ｓ／Ｗとしてポートすることができる。一実施形態によれば、ＧＰスマートカードは、ＴＨＳＭの機能を効果的に実行することができる。そのような機能は、信頼できるドメインＳ／Ｗの特定の要素が、適切に編成された階層内にロードおよび／またはインストールされると、実行することができる。使用することができるＴＤコンセプトの例示的な機能としては、信頼メカニズム、ＴＤのＲＴＯ（ｒｅｍｏｔｅ ｔａｋｅ ｏｗｎｅｒｓｈｉｐ）、ユーザ登録および／またはリモート証明書ロールアウト、ＴＳＩＭ（ｔｒｕｓｔｅｄ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ ｍａｎａｇｅｍｅｎｔ）アプリケーション移行、ならびに完全なＡＫＡ（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ／ｏｒ ｋｅｙ ａｇｒｅｅｍｅｎｔ）機能が含まれる。たとえば、信頼メカニズムは、１つまたは複数のドメインの分離およびセキュリティを提供することができる。一実施形態によれば、ドメインのうちの１つまたは複数は、その他のドメインから分離することができるセキュアな実行および格納環境を含むことができる。たとえば、ＧＰの信頼できるフレームワーク、またはその他の同様の信頼できるフレームワークは、アプリケーション間および／またはドメイン間の通信に関して責任を負うことができ、たとえば、ＣＩのセキュリティルールを実施することによって、アプリケーションの汚染からの分離および保護を確かなものにすることができる。

たとえば、信頼メカニズムは、ランタイムインテグリティチェッキング、および／または、ＭＴＭ（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｍｏｄｕｌｅ）信頼機能に関連付けられているＲＴ（ｒｏｏｔｓ ｏｆ ｔｒｕｓｔ）を含むことができる。信頼のそのような側面は、ファイルローディング中のセーフガードが実行されているがランタイムインテグリティチェッキングを許可することができないＧＰ環境において採用することはできない。ＴＤのＲＴＯ（Ｒｅｍｏｔｅ Ｔａｋｅ Ｏｗｎｅｒｓｈｉｐ）は、完全なサブスクリプションサービスのための機能をＲＯ（ｒｅｍｏｔｅ ｏｗｎｅｒ）に提供することができる。複数のリモートから所有されているＴＤは、同時に存在することができる。ＴＤは、本明細書に記載されているように、ＴＤアプリケーションの主要な機能ユニットであると言える。ＴＨＳＭ環境におけるＲＴＯプロトコルは、所有権を行使する目的でデバイスの信頼性を確立するための信頼メカニズムを組み込むことができる。しかし、ＧＰの設定においては、信頼メカニズムは、カード上へのファイルローディング中のパターンおよび／またはインテグリティチェッキングの形態で存在することができる。ＲＴＯプロトコルおよびＴＤのさらに詳細な説明をここで提供する。

図２および図２Ａにおけるダイアグラムは、完全なＲＴＯプロトコルフローの一実施形態を示している。図２および図２Ａは、例示的なＲＴＯプロセスに関するコールフロー図を示している。たとえば、図２および図２Ａは、ＭＥ２０２、ＴＤ_ＤＯ２０４、ＳＤＭ２０６、ＴＤ^＊ _ＲＯ２０８、およびＲＯ２１０のうちの１つまたは複数の間における例示的なコールを示している。図２および図２Ａにおける矢印は、コールの起点／宛先を表すことができる。ユーザは、ＵＥプラットフォームのパワーオンを開始することができる。このプラットフォームは、ローレベルのコンピューティング、ストレージ、またはドメインのための通信リソースを提供することができる。このプラットフォームは、ハードウェア、オペレーティングシステム、ローレベルのファームウェアもしくはソフトウェア（ブートコード、ＢＩＯＳ、ＡＰＩ、ドライバ、ミドルウェア、もしくは仮想化ソフトウェアなど）、および／またはハイレベルのファームウェアもしくはソフトウェア（アプリケーションソフトウェアなど）、ならびにそのようなリソースに関するそれぞれの構成データから構成することができる。それぞれのドメインは、プラットフォーム上で実行するコンピューティングリソース、ストレージリソース、または通信リソースの構成を含むことができる。２１２においては、ＭＥ２０２によってベースコードブートを完了することができる。２１４においては、ＴＨＳＭが、セキュアにブートすることができる。ＴＨＳＭは、ＤＯのドメイン、含まれているＳＤＭをロードすることができ、この場合、ＳＤＭは、１）ドメイン構築のために利用可能なリソース、および／または２）許容可能なドメインのリストをユーザに提供することができる。２１６においては、ＴＨＳＭは、自分のブートを完了することができる。２１８においては、ＭＥは、自分のブートを完了することができる。２１９においては、ＭＥは、自分のブートが完了したことをＴＤ_ＤＯ２０４に示すことができる。このプロセス中に、ＤＭのドメインを構築することができ、任意選択のユーザドメイン（ＭＥ_Ｕ）を構築することもでき、および／または利用可能なリソースをチェックすることができる。ＤＭのドメインは、ＭＥデバイスのためのドメインポリシーの最初の構成および仕様を提供するＭＥ_ＴＤＭを含むことができる。ＭＥ_ＤＭの事前構成のおかげで、このポリシーを、共通のリモート所有者を有するそれらのドメイン（ＴＨＳＭ上のドメイン、およびＭＥ上のその他のドメインなど）のためのポリシーに関して、ＭＥドメインとＴＨＳＭドメインとの間でＳＤＰのポリシーと整合させることができる。

依然として図２を参照すると、ＭＥ２０２は、自分の事前構成されたドメインとともに、２１９において「ブート完了」メッセージを送信することができ、それによって、２２０においてＲＴＯが開始される。このメッセージは、ＤＭドメインポリシーおよびＭＥ２０２における利用可能なリソースに関する明示的な情報を含むことができる。２２２においては、ターゲットドメインプランを含む開始要求ＲＴＯをＳＤＭ２０６からＴＤ^＊ _ＲＯ２０８へ送信することができる。２２４においては、ＲＴＯ開始要求を受け入れるかまたは拒否するかの判定をＴＤ^＊ _ＲＯ２０８によって行うことができる。２２５においては、ＲＴＯを開始すべきかどうかを示すメッセージをＴＤ^＊ _ＲＯ２０８からＳＤＭ２０６へ送信することができる。あるいは、２２６においては、ＲＴＯは、ＴＤ^＊ _ＲＯ２０８に端を発することができる。２２７においては、ＴＤ^＊ _ＲＯ２０８は、ＲＴＯ最終ドメインプランを開始したいという自分の意図の表示をＳＤＭ２０６へ送信することができる。

ＳＤＭ２０６は、ＴＨＳＭのＳＤＰ（ｓｙｓｔｅｍ−ｗｉｄｅ ｄｏｍａｉｎ ｐｏｌｉｃｙ）を評価すること、ならびにＭＥ２０２ドメイン上にどんな制約が課されるかおよび／または割り当てられるかを決定することによって、ＭＥ２０２ブートメッセージに応答することができる。これらのポリシー制約は、どのドメインを、それらの関連付けられているリモート所有者に従って、たとえばＭＥ２０２およびＴＨＳＭ上などで、許容可能とすることができるかを含むことができる。ＳＤＭ２０６は、ＴＨＳＭ上にドメインを有する同じリモート所有者によって所有されているドメインに関してＭＥ２０２がどのシステムワイドリソースを使用することを許可されるかを決定することができる（その中で、自分が認識させられているものを含む）。ＳＤＭ２０６は、ポリシー制約を自分のベースポリシーに含めることもでき、許容可能なリソースを自分のリソースリストに含めることもできる。ＭＥ_ＰＤＭは、その情報を受信した後に、ＭＥ２０２上のリソースおよびドメインの管理に関する決定を、そのようなすべての決定に関してＳＤＭ２０６に許可を求めることなく、下すことおよび実施することに関する特定の特権を行使することができる。ＳＤＭ２０６およびそのポリシー（ＳＤＰ）は、たとえばＧＰ準拠のスマートカード内のアプリケーションとして見た場合には、ＣＩ ＳＤなどのセキュリティドメインによって却下することができる。ＳＤＭ２０６は、自律を伴ってまたは伴わずに機能している場合に、却下することができる。

依然として図２を参照すると、プロセスは、２２８において継続することができる。２２８においては、ＳＤＭ２０６は、ＳＤＰ、利用可能なリソース、ならびに／または許容可能なドメインおよび／もしくは状態をチェックおよび／または評価することができる。２３０においては、「開始してもよい」という信号をＳＤＭ２０６からＴＤ^＊ _ＲＯ２０８へ送信することができる。２３２においては、ＴＰＩＡ（ＴＨＳＭ Ｐｌａｔｆｏｒｍ Ｉｎｔｅｇｒｉｔｙ Ａｔｔｅｓｔａｔｉｏｎ）、ＴＰＥＳ（ＴＨＳＭ Ｐｌａｔｆｏｒｍ Ｅｎｖｉｒｏｎｍｅｎｔ Ｓｕｍｍａｒｙ）、ＭＰＩＤ（ＭＥ Ｐｌａｔｆｏｒｍ Ｉｎｔｅｇｒｉｔｙ Ｄａｔａ）、および／またはＭＰＥＳ（ＭＥ Ｐｌａｔｆｏｒｍ Ｅｎｖｉｒｏｎｍｅｎｔ Ｓｕｒｖｅｙ）を求める要求を送信することができる。２３４においては、ＳＤＭ２０６は、たとえば、既存のドメインからドメイン当たりのＰＣＲの範囲にわたってインテグリティの認証を収集／連結すること、ならびに／またはＴＰＥＳ情報を収集および／もしくは連結することが可能である。

２３６においては、ＭＰＩＤおよび／またはＭＰＥＳを求める要求をＳＤＭ２０６からＴＤ_ＤＯ２０４へ送信することができる。２４２においては、ＭＰＩＤおよびＭＰＥＳを求める要求への応答をＭＥ２０２によって処理することができる。２３８においては、ＭＰＩＤおよびＭＰＥＳを、信頼の証明とともに、たとえば署名キーとともに、ＳＤＭ２０６へ送信することができる。２３９においては、ＴＰＩＡ、ＴＰＥＳ、ＭＰＩＤ、および／またはＭＰＥＳをＳＤＭ４０６からＴＤ^＊ _ＲＯ２０８へ送信することができる。２４０においては、ＴＨＳＭは、ＭＰＩＤ（生データ）からダイジェストＭＰＩＡを計算して、ＭＰＩＡをチェックすることができる。許容可能である場合には、ダイジェストＭＰＩＡをＴａｒｇｅｔ ＲＯ２１０へ送信することができる。２４２においては、ＴＰＩＡ｜｜ＴＰＥＳ｜｜ＳＣＡＲＤ｜｜Ｐｕｒｐｏｓｅ｜｜ＲＴＯを求める要求をＴＤ^＊ _ＲＯ２０８からＭＥ２０２へ送信することができる。

図２Ａを参照して、図２からのＲＴＯプロセスを続けると、２４４においては、ＴＰＩＡ｜｜ＴＰＥＳ｜｜ＳＣＡＲＤ｜｜Ｐｕｒｐｏｓｅ｜｜ＲＴＯメッセージをＭＥ２０２からＲＯ２１０へ送信することができる。２４６においては、ＲＯ２１０は、ＴＰＩＡ、ＴＰＥＳ、および目的をチェックすること、おそらくは信頼できるサードパーティから受信されてＲＯによって保持されている基準インテグリティメトリックＲＩＭ_ＲＯに照らして元のドメインの信頼性を判定すること、許容可能性に関してドメインポリシー（ＤＰ）をチェックすること、または完全なドメイン状態を構築するためにＣＯＮＦＩＧを作成することのうちの１つまたは複数を実行することができる。２４８においては、メッセージＣＯＮＦＩＧ｜｜ＤＰ｜｜ＲＩＭ_ＲＯ｜｜ＲＯ ｉｄｅｎｔｉｔｙをＴａｒｇｅｔ ＲＯ２１０からＭＥ２０２へ送信することができる。２５０においては、ＣＯＮＦＩＧ｜｜ＤＰ｜｜ＲＩＭ_ＲＯ｜｜ＲＯメッセージをＭＥ２０２からＴＤ^＊ _ＲＯ２０８へ転送することができる。２５２においては、ＴＤ^＊ _ＲＯ２０８は、ドメインを構築および／もしくは構成すること、ならびに／または、ＲＩＭ_ＲＯに対するインテグリティをチェックすることが可能である。加えて、ＴＤ^＊ _ＲＯ２０８は、自分の所有権をＴａｒｇｅｔ ＲＯ２１０によって取得されること、ひいては、それをＴＤ_ＲＯに変換することが可能である。２５４においては、ドメイン完成メッセージをＴＤ_ＲＯ２０８からＭＥ２０２へ送信することができる。２５６においては、ドメイン完成メッセージ（このドメイン完成メッセージには、（たとえば、署名を介して）インテグリティ保護を施すことができる）をＴａｒｇｅｔ ＲＯ２１０からＭＥ２０２へ転送することができる。

ユーザ登録および／またはリモート証明書ロールアウトは、ＴＤ構築を完了すること、および／またはユーザに完全なサブスクライバーステータスを許可することが可能である。このプロセスは、プロトコルへのユーザならびにＰＯＳ（ｐｏｉｎｔ−ｏｆ ｓａｌｅ）の参加を採用することができる。ＴＳＩＭアプリケーションの移行は、ＴＤ機能を含む完全なドメイン転送、または、１つのデバイス（たとえば、発信元（ソース）デバイス）から同様の機能を有する別のデバイス（たとえば、宛先デバイス）へのサブスクライバー証明書のシンプルな再イメージングを含むことができる。移行に関しては、発信元から宛先デバイスへの証明書のポイントツーポイント転送のための２つの構成プロトコルを考慮することができる。１つの構成は、発信元デバイスおよび宛先デバイスの両方に関して１人の所有者を含むことができ、その一方で、別の構成は、それぞれのデバイスごとに別々の所有者を含むことができる。ＧＰスマートカードは、それぞれのインスタンスにおける登録および／または証明書ロールアウトが実行されると、それぞれのＴＤの完全なＡＫＡ（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ／ｏｒ ｋｅｙ ａｇｒｅｅｍｅｎｔ）機能を提供することもできる。この機能は、いくつかの状況のもとでのポーティングには使用することができない。

ここで説明するのは、ＧＰスマートカードと、ＴＨＳＭ／ＴＤアーキテクチャとの比較である。ＧＰスマートカードに関しては、ＧＰスマートカードアーキテクチャは、カードマネージャを含むことができる。カードマネージャは、カードの中央管理者、および／またはグローバルプラットフォームアプリケーションプログラミングインターフェース（ＡＰＩ）とすることができる。カードマネージャは、ＯＰＥＮ（ＧＰ Ｅｎｖｉｒｏｎｍｅｎｔ）、カード発行者（ＣＩ）ドメイン、および／またはＣＶＭ（Ｃａｒｄｈｏｌｄｅｒ Ｖｅｒｉｆｉｃａｔｉｏｎ Ｍｅｔｈｏｄ）サービスを含む論理エンティティとすることができる。カード管理構造は、信頼できるフレームワークを含むことができる。信頼できるフレームワークは、アプリケーション間通信、ならびに／または、たとえばカードリソース管理データ、カードおよびアプリケーションのライフサイクル情報、アプリケーションＩＤ、プロセス特権、関連付けられているドメイン、および／もしくは類似の情報などの情報を格納することができるグローバルプラットフォームレジストリに関して責任を負うことができる。

ＧＰアーキテクチャ構造は、カード上での対話および／またはサービスのうちの多く、たとえば、アプリケーション間通信、アプリケーションにＡＰＩを提供すること、コマンドディスパッチ、アプリケーションの選択、論理チャネルの管理、カードコンテンツの管理、ドメインパーソナライゼーションサービスおよび／もしくはセキュリティサービス、カードのロック、アプリケーションのライフサイクル状態の更新、ならびに／または、カード上での類似の対話および／もしくはサービスなどに関して責任を負うことができる。

ＧＰ機能は、カードＳＤ構造および／または関連付けられているステークホルダのための動作環境を提供することができる。ステークホルダとは、ＴＣＧ（ｔｒｕｓｔｅｄ ｃｏｍｐｕｔｉｎｇ ｇｒｏｕｐ）の用語だが、この用語は、ＴＣＧ標準の範囲外の類似のエンティティを指すために使用することもできる。ＧＰに関するステークホルダは、カード発行者（ＣＩ）、１つもしくは複数のアプリケーションプロバイダ（ＡＰ）、デバイス製造業者、端末所有者、制御権限者（controlling authority）、ならびに／または、ワイヤレス通信デバイス上のソフトウェアおよび／もしくはハードウェアにおいて権益もしくは所有権を有することができるその他のエンティティとすることができる。ＣＩは、実質的なカード所有者である場合がある。ＡＰは、ネットワークオペレータである場合がある。たとえば、ＡＰは、ＷｉＭＡＸのためのネットワークオペレータ、セルラサービス、ＩＭＳ、金融サービスプロバイダ、および／または類似のネットワークである場合がある。制御権限者は、たとえばＣＶＭなどのグローバルアプリケーションサービスをその他のカードアプリケーションに提供することができる。ここでは、関連するステークホルダの例についてのさらに詳細な説明を提供する。

カードの仕様は、それぞれのステークホルダのアプリケーションが、関連付けられているＳＤを有することを要求することができる。それぞれのＳＤは、自分に関連付けられているアプリケーションの動作に関してステークホルダのセキュリティポリシーを実施することができる。カードのＳＤ構造は、セキュリティポリシー実施についての最終的な制御を有する、たとえばＣＩ ＳＤなどの、外部ステークホルダを伴う階層的なものとすることができる。ＧＰは、ＣＩまたはその他の外部ステークホルダが、最終的なポリシー実施の権限を制御権限者に、またはアプリケーションの関連付けられているＳＤにさえ委任することを可能にすることができる。ＧＰにおいては、ＣＩ ＳＤ以外への「委任される（delegated）」権限のさまざまなレベルを許可することができる。ここでは、委任される権限のレベルの例を特定して論じる。ＣＩは、本明細書においては、セキュリティポリシー実施についての最終的な制御を有する外部ステークホルダを指すために使用することができるが、その他のいかなる（１人または複数の）外部ステークホルダも、セキュリティポリシー実施についての最終的な制御を有することができ、本明細書に記載されているＣＩに関連付けられている機能を実行することができるということが理解できるであろう。同様に、ＣＩ ＳＤは、ＣＩに関連付けられているＳＤを指すことができるが、セキュリティポリシー実施についての最終的な制御を有するその他のいかなる（１人または複数の）外部ステークホルダに関連付けられているＳＤも、本明細書に記載されているＣＩ ＳＤと同じまたは同様の機能を実行することができる。

図３は、ＧＰアーキテクチャの例示的な一実施形態を示す図である。図３において示されているように、ワイヤレス通信デバイスは、複数のアプリケーションを含むことができ、それぞれのアプリケーションは、そのアプリケーション上でのポリシー実施を制御するように構成されているセキュリティドメイン（ＳＤ）に関連付けられている。たとえば、ワイヤレス通信デバイスは、（１つもしくは複数の）カード発行者アプリケーション３０８、（１つもしくは複数の）アプリケーションプロバイダ（ＡＰ）アプリケーション３１０、および／または（１つもしくは複数の）グローバルサービス（ＧＳ）アプリケーション３１２などの複数のアプリケーションを含むことができる。ワイヤレス通信デバイスは、発行者の（１つもしくは複数の）ＳＤ３０２、アプリケーションプロバイダの（１つもしくは複数の）ＳＤ３０４、および／または制御権限者の（１つもしくは複数の）ＳＤ３０６などの複数のＳＤを含むこともできる。（１つもしくは複数の）カード発行者アプリケーション３０８は、発行者のＳＤ３０２に関連付けることができ、（１つもしくは複数の）ＡＰアプリケーション３１０は、アプリケーションプロバイダの（１つもしくは複数の）ＳＤ３０４に関連付けることができ、および／または（１つもしくは複数の）ＧＳアプリケーション３１２は、制御権限者の（１つもしくは複数の）ＳＤ３０６に関連付けることができる。それぞれのセキュリティドメインは、自分の関連付けられている（１つまたは複数の）アプリケーション上でのポリシー実施を制御することができる。

ここで説明するのは、ＧＰプラットフォーム特権およびセキュリティドメイン管理である。一実施形態によれば、ここで説明するそれぞれの機能的な特徴は、ＴＳＩＭがＧＰ準拠のプラットフォーム上で機能している間に実現されることが望ましい場合がある。ＴＳＩＭがＧＰ準拠のプラットフォーム上で機能している間にそれぞれの機能的な特徴を実現することができる程度は、たとえばＧＰカードマネージャまたはその他の外部ステークホルダに対してＴＳＩＭアプリケーションがどの程度自律的に機能することを認められるかによって決定することができる。自律レベルは、ＧＰ ＣＩとＴＳＩＭ ＡＰとの間におけるポリシー合致の結果に基づくことができる。自律レベルは、ＣＩ ＳＤと、たとえばＴＳＩＭ ＡＰなどの外部ステークホルダとの間における信頼のレベルに基づくことができる。信頼のレベルは、さまざまな基準に基づくことができる。たとえば、信頼のレベルは、最終的な制御を有するセキュリティドメイン（たとえば、ＣＩ ＳＤ３０２）のセキュリティポリシーと、外部ステークホルダ（たとえば、１つまたは複数のアプリケーション３１０をスマートカード上に常駐させようとしているＡＰ ＳＤ３０４）のセキュリティポリシーとの間における合致のレベルによって決定することができる。信頼レベルは、ＣＩがＡＰにどの程度なじんでいるかによって決定することもできる。一実施形態においては、信頼のレベルは、サードパーティからの推奨を考慮に入れることができる。ＡＰまたはその他の外部ステークホルダの評判も、信頼のレベルを決定する上で役立つことができる。信頼のレベルに基づいて、特権レベルを付与することができる。たとえば、ＣＩは、ＴＳＩＭ ＡＰの信頼性を決定することができる。ＣＩは、たとえば、ＴＳＩＭ ＳＤＰがＣＩのＳＤＰと整合しているとみなされる場合には、ＡＭＰ（ａｕｔｈｏｒｉｚｅｄ ｍａｎａｇｅｍｅｎｔ ｐｒｉｖｉｌｅｇｅ）を付与することができる。信頼レベルを決定する際に使用されるファクタが、ＣＩにとってあまり合意できるものでない場合には、ＡＭＰよりも低い自律性を提供することができるＤＭＰ（ｄｅｌｅｇａｔｅｄ ｍａｎａｇｅｍｅｎｔ ｐｒｉｖｉｌｅｇｅ）の可能性が高まる場合がある。例示的な一実施形態によれば、ＣＩ ＳＤ３０２は、ＧＰ特権構造、または本明細書に記載されているような類似の構造に関して、最も高いＳＤ権限とすることができる。

ここでは、少なくとも３つの特権レベルを説明することができる。そのような１つの特権レベルは、ＡＭＰ（ａｕｔｈｏｒｉｚｅｄ ｍａｎａｇｅｍｅｎｔ ｐｒｉｖｉｌｅｇｅ）とすることができる。この特権レベルは、このような特権を付与されているいかなるアプリケーションにも最も多くの自律を提供することができる。ＴＳＩＭアプリケーションがＡＭＰを付与されている場合には、そのＴＳＩＭアプリケーションのＳＤは、ＳＤ階層の最上位に配置されること、および／または自己関連付けされる（ｓｅｌｆ-ａｓｓｏｃｉａｔｅｄ）ことが可能である。ＧＰ環境においては、ＳＤは、アプリケーションとみなすことができ、関連付けられているＳＤを有することもできる。ＳＤは、自己関連付けされている場合には、自分自身のセキュリティサービスを使用することができる。このコンテキストにおいては、ＣＩ ＳＤは、ＴＶ（ｔｏｋｅｎ ｖｅｒｉｆｉｃａｔｉｏｎ）特権および／またはＲＧ（ｒｅｃｅｉｐｔ ｇｅｎｅｒａｔｉｏｎ）特権を有するＴＳＩＭ ＳＤを制御することはできない。自己関連付けされているＳＤは、ＳＤ階層内のＴＶおよび／またはＲＧ構造を制御することができ、および／またはトークンを使用しないと決めることができる。これによって、ロードファイルのローディングに対する制御をＳＤに与えることができる。

もう１つの特権レベルは、ＤＭＰ（ｄｅｌｅｇａｔｅｄ ｍａｎａｇｅｍｅｎｔ ｐｒｉｖｉｌｅｇｅ）とすることができる。この特権レベルは、強力であるとみなされているが、ＡＭＰによって提供されるよりも少ない自律しか提供することができない。アプリケーションＳＤは、自己関連付けすることができない。結果として、ＣＩ ＳＤは、階層において自分よりも下のＳＤに対してＴＶおよび／またはＲＧ特権を行使することによって、ロードファイルアクティビティを制御することができる。しかし、ＤＭＰを付与されることが可能であるＳＤは、ロードファイルのローディングを実行する権限、および／または、たとえばロードファイルアクティビティに関わるファイルインテグリティに関連するセキュリティプロセスなど、その他のセキュリティプロセスを監督する権限を有することができる。

別の特権レベルは、ＡＭＰでもＤＭＰでもないものを含むことができる。ＡＭＰもＤＭＰもなければ、ＳＤは、非常にわずかな自律しか有することができない。ＣＩ ＳＤは、ロードファイルに関するローディング機能を実行することができ、ならびに／または、ローディングプロセスを制御する際にＴＶおよび／もしくはＲＧ特権を行使することができる。ＣＩ ＳＤは、ファイルインテグリティを含むロードファイルアクティビティに対する制御を有することもできる。

ここで提供するのは、ＧＰセキュリティドメイン管理の説明であり、これには、１）レシート発行メカニズム、２）トークン署名メカニズム、３）委任管理特権トークン、４）カード管理エンティティＯＰＥＮによるレシートの監督、５）自己関連付けされているＳＣ（ｓｍａｒｔｃａｒｄ）による補足ＳＤ（ｓｕｐｐｌｅｍｅｎｔａｒｙ ＳＤ）の構成に関するメカニズム、６）ＤＭＰを有するＳＤに関する自己引き渡し（ｓｅｌｆ-ｅｘｔｒａｄｉｔｉｏｎ）の問題、７）現実世界における自己引き渡しを伴う全体的な経験レベル、８）ＳＣＷＳ（ＳＣ ｗｅｂ ｓｅｒｖｉｃｅ）に関連付けられているアプリケーション、９）秘密のカード管理、１０）トークン検証特権およびレシート生成特権の使用に関するメカニズム、および１１）自己関連付けされているＳＣによる補足ＳＤの構成に関するさらなる情報の説明が含まれる。

ここでは、いくつかの実施形態によるＧＰセキュリティドメイン管理プロパティについて説明する。ＧＰセキュリティメカニズムを利用する一実施形態においては、補足ＳＤは、トークン検証特権および／またはレシート生成特権を有することができる。例示的な一実施形態においては、カードごとに少なくとも１つのＳＤが、これらの特権のそれぞれを有することができる。そのＳＤは、トークン検証特権およびレシート生成特権の両方を有する同じＳＤである必要はないと言える。したがって、発行者ドメインは、トークン検証特権および／またはレシート生成特権を有することができるが、その他の実施形態においては、それは、トークン検証特権および／またはレシート生成特権を有する別のＳＤとすることができる。たとえば、一実施形態によれば、階層ごとに、レシート生成特権を有する１つのＳＤ、およびトークン検証特権を有する１つのＳＤが、存在することができる。これは、カードごとの、レシート生成特権を有する１つのＳＤ、およびトークン検証特権を有する１つのＳＤとは、異なるものであると言える。これらの特権を有するＳＤは、同じＳＤである必要はないが、同じＳＤであってもよい。階層において現在のＳＤよりも上位のＳＤがＲＧ特権を有することをＯＰＥＮが検知した場合には、レシートを生成することができる。しかし、これは、トークンが使用されたかどうかに依存することができる。レシートを発行すること、および／またはレシートをＳＤの所有者へ送信することができるのは、ＲＧ特権を有するＳＤとすることができる。ＩＳＤがレシートに署名した場合には、そのレシートをＣＩへ送信することができる。

一実施形態によれば、ロードレシートを発行するために、ＴＳＩＭの自律が存在することができる。ＴＳＩＭに関連付けられているＳＤには、承認管理特権を付与することができる。たとえば、ＣＩは、承認管理特権を、ＴＳＩＭに関連付けられているＳＤに付与することができる。ＣＩは、トークン検証特権および／またはレシート生成特権も付与することができる。この構成においては、ＴＳＩＭは、自分のＳＤ階層の最上位に存在することができ、ＴＳＩＭアプリケーションのカードコンテンツを管理することができる。

ＧＰセキュリティ管理プロパティを有する実施形態においては、可能なトークン構築方法は、トークンの生成／発行、トークンの検証、および／またはレシートの生成を含む。たとえば、複数の実施形態は、ＣＩがカードの構成を追跡把握できるようにするために、レシートを使用することができる。レシートは、ＳＤ所有者（たとえばＡＰおよび／またはＣＩなど）に、対応するトークンが首尾よく使用されていることを知らせるために使用することができる。どのＳＤがレシートに署名するかに従って、ＳＤ所有者を確立することができる。ＳＤは、カードの構成を追跡把握することはできない。ＧＰレジストリは、構成に関するデータを格納することができ、および／または、管理イベントが成功した後に自動的に更新されることが可能である。ＯＰＥＮは、たとえば、構成に関する情報を得るためにＧＰレジストリを読み取ることができる。たとえば、承認されたオフカードエンティティ（ｏｆｆ-ｃａｒｄ ｅｎｔｉｔｙ）が、ＧＥＴ ＳＴＡＴＵＳコマンドを使用して、レジストリを読み取ることができる。一実施形態によれば、ＴＳＩＭに関連付けられているＳＤは、ＴＳＩＭ ＡＰによって所有されることが可能である。ＧＰレジストリは、トークンおよび／またはレシートが使用される場合に構成データを格納することができる。格納メカニズムは、トークンがＴＳＩＭ ＡＰによって発行される場合、および／またはそのようなトークンが、ＴＳＩＭ ＳＤによって、署名されたレシートを用いて検証される場合には、同じものとすることができる。

ＧＰセキュリティメカニズムを使用する一実施形態においては、補足ＳＤは、トークンを検証することができる。新たなアプリケーションをロードするために、ＤＭ特権を有する補足ＳＤのためにＤＡＰおよび／またはＤＭトークンを要求することができる。これは、新たな子ＳＤをロードすることを含むことができる。アプリケーションをロードおよび／もしくはインストールするために、ならびに／または、そのアプリケーションをそのアプリケーションのさまざまなライフサイクル状態を通じて移動させるために、さまざまなタイプのトークンを使用することができる。ＤＡＰは、ＡＰによって生成することができる。ＡＰは、ＤＭ特権を有する補足ＳＤを所有することができる。しかし、トークン（Ｄｅｌｅｇａｔｅｄ Ｍａｎａｇｅｍｅｎｔトークンを含むことができる）は、ＣＩによって生成することができる。これが意味することができるのは、自分の特権を有する、補足的な、自己引き渡しされたＳＤは、ＣＩからトークンを得ることができるということである。トークンは、ＡＰからのさまざまなＩＮＳＴＡＬＬコマンド内に含めてスマートカードに供給することができる。ＡＰは、アプリケーションをロードするために、自分のＤＭ特権を使用することができる。加えて、１つのタイプのトークンが存在することができる。ＤＡＰは、トークンから独立することもできる。トークンは、たとえばＳＤのオフカード所有者（ｏｆｆ-ｃａｒｄ ｏｗｎｅｒ）によって、ＴＶ特権を伴って、署名および／または発行することができる。なぜなら、そのＳＤは、トークンを検証する際に用いるキーを有することができるためである。一実施形態によれば、階層ごとに１つのＴＶ特権が存在することができる。１つのツリーを伴うカードに関しては、ＩＳＤは、ＤＭＰを有するＳＤが存在する場合には、ＴＶ特権を有することができる。代替実施形態においては、トークン発行者は、そのトークンに署名することができるＡＰに署名キーを送信することができる。これは、どのＳＤがＴＶ特権を有するかに影響を与えることはできない。対称的な署名プロセスが使用されている場合には、ＡＰは、ＴＶ特権を有しているならば、トークンを検証することができる。一実施形態によれば、ＣＩは、キーを与えないことが可能であり、および／または、２つの異なる階層での、それぞれの階層のルートにおいて自分自身のＡＭ特権を伴う、分割管理を選択することができる。

ＴＳＩＭ ＡＰは、自分が所有するＳＤとキーを共有することができる。一実施形態によれば、ＴＳＩＭ ＡＰは、対称キーが採用されている場合には、キーを共有することができる。ＡＰは、トークンを発行すること、および／またはトークンに署名することが可能である。ＳＤは、トークンの署名を検証すること、ならびに／またはレシートを生成すること、および／もしくはレシートに署名することが可能であり、そのレシートは、レシート検証のためにＡＰへ返送される。この手順において使用されるＧＰ証明書は、ＴＳＩＭの信頼できるドメインに関連付けられている証明書とは異なるものとすることができる。

いくつかの実施形態においては、ＤＭトークン（たとえば、またはその他のトークン）には、ＣＩ以外の外部ステークホルダによって署名することができる。たとえば、トークンの発行者は、トークン検証特権を有するＳＤのＳＤプロバイダとすることができる。一実施形態によれば、ＳＤプロバイダは、ＣＩとすることができる。ＤＭトークンには、たとえばＡＰなど、ＣＩ以外の者によって署名することができる。適切な特権を有する自己引き渡しされた補足ＳＤは、ＣＩから独立することができる。いかなるＳＤも、ＴＶ特権を有することができる。たとえば、階層ごとに１つのＳＤが、ＴＶを有することができる。トークンに署名することができるのは、特権付きのＳＤの所有者とすることができる。それは、発行者、またはセキュリティポリシー実施の最終的な制御を有するその他の外部ステークホルダである必要はないと言える。たとえば、非ＩＳＤ階層におけるＳＤは、ＴＶ特権を有することができ、および／またはそのＳＤの所有者は、トークンに署名できるようにすることができる。

さらに、所望のタイプのＴＳＩＭ構成に基づいて、さまざまなＧＰドメイン階層が考えられる。たとえば、別々のリモート所有者はそれぞれ、自分のＴＤ機能の一部として実行されるソフトウェアを有することができる。ＴＳＩＭアプリケーションは、これらのリモート所有者のそれぞれに関する対応する、関連付けられているＧＰ ＳＤを伴って構築することができる。ＳＤは、自分のアクティビティを監督するＴＳＩＭに関連付けられているＳＤとともに自分自身の構成を管理するための委任管理特権を付与されることが可能である。

ここでは、ＤＭトークンについて、一実施形態に従ってさらに説明する。トークンは、さまざまなアクションおよび／または特権において使用することができる。ＤＭトークンとは、カードコンテンツを管理するＤＭプロセスにおいて使用される任意のトークンを指すことができる。上述のようなＤＭトークンは、たとえばＴＳＩＭアプリケーション構成構築プロセスのコンテキストにおいて使用することができる。

一実施形態によれば、ＯＰＥＮは、レシートが使用されるかどうかを判定することができる。ＯＰＥＮは、レシートを使用することができる場合には、たとえば、関連するコマンド（たとえば、ＩＮＳＴＡＬＬ）が首尾よく実行された後には、必ずレシートが生成されるようにすることができる。ＯＰＥＮは、階層内のＳＤのうちのいずれかがレシート発行特権を有するかどうかを判定することができる。現在のＳＤ、または階層においてそのＳＤよりも上位のＳＤが、Ｒｅｃｅｉｐｔ Ｇｅｎｅｒａｔｉｏｎ特権を有する場合には、ＯＰＥＮは、必ずレシートが生成されるように、および／またはＡｐｐｌｉｃａｔｉｏｎ Ｐｒｏｖｉｄｅｒへ送信されるようにすることができる。ＴＳＩＭポーティングのさまざまな実施形態は、１）トークンなし、２）レシートを伴わないトークンあり、ならびに／または、３）完全な検証を伴うトークンおよび／もしくはレシートありなど、トークンおよびレシートのさまざまな使用の組合せを含むことができる。一実施形態においては、発行者ドメインがレシート発行特権を有する場合には、（たとえば、自己関連付けされているＳＤのためにではなく）ＩＳＤに関連付けられているＳＤのためにレシートを生成することができる。一実施形態においては、アプリケーションをロードするＳＤが、自己関連付けされていて、レシート生成特権を有していない場合には、階層の最上位にあるＳＤによってレシートを生成することはできない。レシートは、任意選択とすることができる。たとえば、ＳＤが階層の最上位にある場合には、そのＳＤがアプリケーションをロードするためにどの特権を使用するかを決定することができる。たとえば、ＳＤがＡＭ特権を有する場合があり、これが意味することができるのは、そのＳＤは、トークンを使用することができず、ひいてはレシートを生成することができないということである。ＳＤは、ＲＧおよび／またはＴＶ特権を有する場合には、補助ＳＤ（ｓｕｂｓｉｄｉａｒｙ ＳＤ）のためのレシートを発行することができる。一実施形態によれば、レシートは、ＤＭ特権を有する場合に、および／またはＣＣＭオペレーションを実行するためのトークンを有する場合に、発行することができる。ＳＤは、ＤＭおよびＴＶ特権の両方を有する場合には、ＡＭ特権を有するのと実質的に同等な自律を有することができる。なぜなら、ＳＤは、自分自身のトークンを検証することができるためである。

一実施形態によれば、ＤＭ特権を有する自己関連付けされているＳＤは、自分自身の下に、補助ＳＤの直線的なチェーンおよび／またはＳＤのマルチレベルツリーを作成することができる。たとえば、ＳＤは、階層内のＴＶ特権付きのＳＤによって検証することができる正しいトークンを提示することができる。一実施形態によれば、少なくとも２つのレベルのＳＤが存在することができる。たとえば、１つの補足ＳＤが、Ｉｓｓｕｅｒ Ｄｏｍａｉｎの下に存在することができる。自己関連付けされているＳＤは、自分の下にいかなるＳＤも有することができない。多層ツリーを作成することができる。それぞれのＳＤは、自分が他のどのＳＤに関連付けられているかを知ることができ、および／または、正しい情報をＧＰ Ｒｅｇｉｓｔｒｙ内に格納することができる。一実施形態においては、補助ＳＤは、アプリケーションとすることができ、カード上にロードされるためには、および／または動作可能になるためには、さまざまなカードコンテンツ管理プロセスを経なければならないこととすることもできる。補足ＳＤは、自分自身の下に補助ＳＤをロードできるようになるために自己関連付けされる必要はないと言える。補足ＳＤは、ＤＭ特権を有することができる。たとえ補足ＳＤがＤＭ特権を有していなくても、最上位レベルのＳＤを使用して、補足ＳＤの下にＳＤをロードすることができる。自己関連付けされているＳＤは、自分自身のサービスを提供しなければならない場合があり、それらのサービスは、いくつかのＡＰにとって望ましい場合がある。Ｉｓｓｕｅｒ Ｄｏｍａｉｎは、自己関連付けされているＳＤおよび／またはそのアプリケーションを無効にする（ｋｉｌｌ）ことができる。自己引き渡しされたＳＤは、ＡＭ特権を有することができる。たとえば、トークンは、自分が子ＳＤを作成することを必要とされない場合がある。一実施形態においては、トークンを検証する上で、最上位レベルのＳＤよりも上位のエンティティは存在することができず、たとえば、最上位レベルのＳＤは、ＤＭ特権を有することができない。たとえば、これは、ＴＳＩＭに関連する場合がある。なぜなら、ＴＳＩＭセキュリティドメイン階層内のＳＤは、リモート所有者の好みに従って自分の構成を構築することができるためである。

一実施形態においては、ＤＭ特権を有するＳＤは、自分自身の自己引き渡しを実行することができる。一実施形態によれば、トークンを使用することができる。自己引き渡しの後に、自己関連付けされているＳＤは、本明細書に記載されているように、ＡＭ特権を取得することができる。ＩＳＤは、一実施形態によれば、ＡＭを付与することができる。ＡＭは、ＧＰ Ｒｅｇｉｓｔｒｙを更新することによって付与することができる。自己関連付けされているＳＤの所有者は、ＧＰ Ｒｅｇｉｓｔｒｙを更新するようＣＩに求めることができる。したがって、ＳＤは、ＣＩからの許可なく自分自身を自分の親から切り離すことができない場合がある。一実施形態によれば、ＳＤは、引き渡しトークンを使用する場合に、自己引き渡しを許可されることが可能である。一実施形態によれば、複数の自律的なＳＤ階層が存在することができる。ＳＤ階層は、ＴＳＩＭの範囲内に存在することができる。たとえば、それぞれのリモート所有者ごとに１つのＳＤ階層が存在することができる。

同様に、承認管理特権を有するＳＤは、自分自身の自己引き渡しを実行することができる。たとえば、そのＳＤは、自分自身の階層の最上位に存在することができる。そのＳＤは、ＩＳＤの階層内に存在することはできない。これは、ＩＳＤがその階層内にＡＭを有することができることに起因する場合がある。ＩＳＤの下の既存のＳＤがＩＳＤによって自己引き渡しされた場合には、ＩＳＤは、ＧＰ Ｒｅｇｉｓｔｒｙに入ること、および／または新たに自己関連付けされたＳＤにＡＭ特権を付与することが可能である。

いくつかの実施形態においては、キー管理のためのＧＰメカニズムに関連した発行を決定することができる。たとえば、ＳＣＷＳに関連付けられているＯＰは、ＭＮＯによって管理および／または所有されることは不可能であり、そのＳＣＷＳに関連付けられているＯＰを補助ＳＤ内にインストールするサードパーティのＯＰによって所有されることが可能である。ＳＣＷＳに関連付けられているＯＰの所有者は、アプリケーションを管理するために直接ＧＰコマンドを使用することができる。一実施形態によれば、ＳＣＷＳを経由しなければならない代わりに、直接のコマンドを使用することができる。ＯＰの所有者が、ＳＣＷＳを所有しているカード発行者ではない場合に、直接のコマンドを使用することができる。ＳＣＷＳおよび／またはＯＰアプリケーションの両方がＧＰアプリケーションである場合には、ＳＣＷＳは、Ｔｒｕｓｔｅｄ Ｐａｔｈを使用して、ＯＰアプリケーションを呼び出すことができる。ＳＣＷＳおよび／またはＯＰは、別々のＳＤの下に存在することができる。たとえば、ＳＣＷＳおよび／またはＯＰは、別々の所有権の下に存在することができる。ＯＰアプリケーションには、ＧＰ方法および／またはＯＭＡ／ＳＣＷＳ方法を使用して、キーを供給することができる。たとえば、ＳＣＷＳがＧＰアプリケーション（通常のＪａｖａ（登録商標）ｃａｒｄまたはネイティブアプリケーションなど）ではない場合、および／またはＯＰがＧＰアプリケーションである場合には、ＧＰを使用してＯＰアプリケーションを管理することができる。ＳＣＷＳがＯＰアプリケーションを呼び出すこと、および／またはＯＰアプリケーションにキーを供給することを可能にするための機能がＧＰ内に存在することはできない。一実施形態においては、ＳＣＷＳおよびＯＰアプリケーションは、ＴＳＩＭとともにカード上に存在することができるが、カードの外で機能することができる。

一実施形態によれば、ＣＣＭ（Ｃｏｎｆｉｄｅｎｔｉａｌ Ｃａｒｄ Ｍａｎａｇｅｍｅｎｔ）は、暗号化されたロードブロックのローディングを可能にすることができる。暗号化されたロードブロックは、ＡＰ以外のいかなる者によっても復号することはできない。ＡＰは、信頼されていないトランスポートリンクを介して秘密のアプリケーションをロードすることができる。Ｌｉｎｋ Ｐｌａｔｆｏｒｍ Ｏｐｅｒａｔｏｒ（たとえばセキュアなＯＴＡシステムを伴うＭＮＯなど）は、秘密のアプリケーションをロードおよび／もしくは管理するために、ＳＤ（ＡＰＳＤと呼ばれる場合がある）を作成すること、ならびに／またはＡＰＳＤの所有権をＡＰへ移転することが可能である。ＡＰは、秘密のローディングを管理するために、ＳＤ（たとえば、ＡＰＳＤ）を使用することができる。ＡＰＳＤによって使用されるキーは、ＬＰＯによって知られていないものにすることができる。それを達成するために、Ｃｏｎｔｒｏｌｌｉｎｇ Ａｕｔｈｏｒｉｔｙの役割を拡張することができ、それによって、Ｃｏｎｔｒｏｌｌｉｎｇ Ａｕｔｈｏｒｉｔｙは、ＡＰＳＤのためのキーの作成および／またはＡＰＳＤのパーソナライゼーションをセキュアなものにすることができる。これは、ＳＴＯＲＥ ＤＡＴＡコマンドを使用して、ＬＰＯのネットワークを介して行うことができる。ＡＰＳＤキーは、カード上に生成すること、および／またはリモートＡＰへ送信することが可能である。ＡＰＳＤは、カード外に生成すること、および／またはＡＰＳＤへ送信することが可能である。ＤＭトークンに署名するために、対称暗号化（ｓｙｍｍｅｔｒｉｃ ｃｒｙｐｔｏ）を使用することができる。ＣＣＭは、カードコンテンツ管理のためのメカニズムを避けて通ることはできない。たとえば、ＤＡＰおよび／またはトークンは、依然として使用することができる。ロードトークンには、Ｃａｒｄ Ｉｓｓｕｅｒによって署名することができる。ＳＤの作成および／または割り当てに関しては、信頼をＣＩからＣｏｎｔｒｏｌｌｉｎｇ Ａｕｔｈｏｒｉｔｙへ移すことができる。一実施形態によれば、ＣＡは、ＡＰの公開キーを保持することができる。ＣＡは、ＡＰのＳＤキーのカード上での生成を行うこともできる。ＣＡは、ＡＰのＳＤキーをＡＰの公開キーとともに暗号化すること、および／またはそれらをＡＰへ送信することが可能である。アプリケーションペイロードは、ＬＰＯの（たとえば、ＮＯの）ネットワークを通って進むことができる。

ＡＰＳＤ（リモート所有者によって作成することができ、および／またはＤＭ特権を有することができる）は、階層の最上位におけるＴＳＩＭ ＳＤの監督を伴う自分の実行可能なＳ／Ｗを構成することができる。たとえば、信頼できるドメインの機能のポーティングは、ＣＩによってＴＳＩＭ ＳＤに付与される自律のレベルに直接依存することができる。上述の機能のうちのいくつかは、ＣＩ、または、セキュリティポリシー実施の最終的な制御を有するその他の外部ステークホルダの権限のもとで実行することができる。全体的なＴＳＩＭの自律がなければ、ＴＳＩＭ機能のうちのいくつかおよび／またはすべてを許可することはできない。

一実施形態によれば、トークン検証特権（カードごとにこれらのうちの少なくとも１つが存在することができる）を有するＳＤは、トークンを発行していなくてもトークンを検証することができる。たとえば、このＳＤは、トークンを検証するために使用されるキーへのアクセスを有することができる。トークン検証のプロセス（トークンを含んだコマンドをカードが実行することを承認することができる）は、ＯＰＥＮの一部とすることができる。ＡＰは、ＣＩからトークンを得ることができる。たとえばＡＰは、ＣＩが、トークンを発行したＣＩである場合には、そのＣＩからトークンを得ることができる。これは、帯域外で行うことができる。階層ごとに、ＴＶ特権を有する少なくとも１つのＳＤ、および／またはＲＧ特権を有する１つのＳＤが存在することができる。一実施形態においては、ＴＶ特権を有するＳＤは、トークンに署名したオフカードエンティティによって所有することができる。その階層内のＲＧ特権を有するＳＤは、レシートに署名するＳＤとすることができる。ＡＰがトークンを得るプロセス、および／またはＡＰがレシートを処理するプロセスは、カード外で行うことができる。たとえば、ＯＰＥＮは、ＤＭ特権を有するＳＤのためのカード管理コマンドを実行するための前提条件として、カード上でのトークン検証プロセスを実施することができる。ＯＰＥＮは、ＲＧを実施することもできる。たとえば、ＯＰＥＮは、階層内でＲＧ特権が検知された場合には、ＲＧを実施することができる。

一実施形態によれば、承認管理特権を有する（１つまたは複数の）ＴＳＩＭ ＳＤが、トークン使用の有無を問わずに機能することができる限り、ＯＰＥＮの実施ポリシーは、ＴＳＩＭアクティビティに干渉することはできない。ＴＳＩＭは、委任管理特権をＳＤが有するかどうか、およびトークンが使用されるかどうかという点から、自分のＳＤをどのように構成するかを決めるために、使用されることが可能である。

例示的な一実施形態においては、ＤＭ特権を有する自己関連付けされているＳＤは、補助ＳＤのグループを、ＳＤのそのグループが同じレベル上に存在するように、作成することができる。たとえば、ＤＭ特権を有するＳＤは、より多くのＳＤを自分の下にロードできるようにするために自己関連付けされる必要はないと言える。しかし、トークンを使用することはできる。上述のように、自己関連付けされているＳＤは、ＤＭＰを有することはできない。ツリーの最上位にあるＳＤは、ＡＭＰを有することができる。最上位のＳＤよりも下位のＳＤがＤＭＰを有する場合には、最上位のＳＤは、ＴＶ特権および／またはＲＧ特権を有することができる。これらの特権のそれぞれは、レシートが使用されるかどうかに依存することができる。親（たとえばＡＭＰを有する自己関連付けされているＳＤなど）は、互いに同じレベルにある子ＳＤのグループを作成することができる。一実施形態においては、親は、自分と同じレベルに子ＳＤのグループを作成することはできない。

ＴＨＳＭに関しては、ＴＨＳＭは、信頼できるサブスクリプション管理機能を提供するように設計することができる、ハードウェアで保護されたモジュールである。たとえば、ＴＨＳＭ機能は、ＧＳＭのためのＳＩＭ機能、それぞれＵＭＴＳおよび／もしくはＩＭＳオペレータのためのＵＳＩＭおよび／もしくはＩＳＩＭ機能、ならびに／または非３ＧＰＰアクセスネットワークサブスクリプションとして実行される機能を含むことができる。たとえば、ＵＭＴＳ環境に関連付けられているＵＩＣＣ機能を含むことができる。

図４は、ＴＨＳＭ４０４がハイレベルユーザ機器（ＵＥ）４００デバイスアーキテクチャの一部である一実施形態を示す図である。ＵＥ４００は、ＴＨＳＭ４０４およびＭＥ４０２から構成することができる。ＴＨＳＭ４０４は、ＵＥ４００上に組み込んでもよく、または組み込まなくてもよい。ＴＨＳＭ４０４は、たとえＵＥ４００上に組み込まれていても、ＭＥ４０２とは論理的に別個のものとすることができる。ＴＨＳＭ４０４は、１つまたは複数のドメインを有することができる。たとえば、ＴＨＳＭ４０４は、ＴＨＳＭデバイス製造者（ＤＭ）ドメイン４０６、ＴＨＳＭデバイス所有者（ＤＯ）ドメイン４０８、ＴＨＳＭ ＤＵもしくはデバイスユーザ（Ｕ）ドメイン４１２、ＳＤＭ（Ｓｙｓｔｅｍ−Ｗｉｄｅ Ｄｏｍａｉｎ Ｍａｎａｇｅｒ）ドメイン４１０、および／または、１つもしくは複数のＲＯ（Ｒｅｍｏｔｅ Ｏｗｎｅｒ）ドメイン４１４を含むことができる。それぞれのドメインは、そのドメインの特定の所有者によって所有することができ、ならびに／または、セキュアな信頼できるサービスおよび／もしくはアプリケーションを提供することによって、その所有者のために機能することができる。図４における点線は、ドメイン所有者と、ＴＨＳＭ４０４内の対応するドメインとの間における接続を示している。一実施形態によれば、これらの接続は、ドメイン所有者と、ＭＥ４０２との間におけるＯＴＡ（ｏｖｅｒ ｔｈｅ ａｉｒ）インターフェースを介して、およびＭＥ４０２と、ＴＨＳＭ４０４との間におけるインターフェースを介して可能にすることができる。ＴＨＳＭ４０４内のドメインは、格納および／または実行環境としてはＴＨＳＭ４０４よりもセキュアではないとみなされることがあるＭＥ４０２内で実行するには安全または好都合ではない可能性があるセキュリティに敏感な機能および／またはアプリケーションを実行することができる。本明細書に記載されている例示的な実施態様では、図４に関連して説明されているようなコンポーネントに言及する場合がある。

ドメインのうちのいくつかは、１つまたは複数のモバイルネットワークオペレータ（ＭＮＯ、たとえば３Ｇおよび／または４ＧモバイルＭＮＯなどによって所有および／または管理することができる。ドメインは、その他の通信ネットワークオペレータ、たとえば、ＷＬＡＮ、ＷｉＭａｘ、または類似の通信ネットワークオペレータおよび／もしくはアプリケーションサービスプロバイダなどによって所有および／または管理することができる。サブスクリプションの管理は、所有者によって所有されているドメインによってサポートすることができる主要なアプリケーションであると言える。ＴＨＳＭドメイン上で実施されるサブスクリプション管理の機能については、ＴＳＩＭの機能として説明する。さまざまなドメインが、複数のタイプの機能をサポートすることができる。たとえば、それらの機能は、３Ｇモバイル端末上のＵＩＣＣ上のＵＳＩＭおよび／またはＩＳＩＭアプリケーションによって提供される機能と同様のものとすることができる。ＴＨＳＭは、たとえばＵＩＣＣのように、ＴＳＩＭ用以外の機能ならびに／またはアプリケーションおよびデータを有することができる。ここでは、ＴＨＳＭコンポーネントについてのさらなる説明を記載する。それらの説明は、限定を伴わずに、例示的な目的で提供される。

ＴＤ（Ｔｒｕｓｔｅｄ Ｄｏｍａｉｎ）は、ＴＨＳＭアーキテクチャおよび／またはＭＥ内のソフトウェア／ファームウェアエンティティである。ＴＤは、自分の所有者（たとえばリモート所有者を含むことができる）のために、信頼できるセキュリティ機能および／またはアプリケーションを含むサブスクリプションサービスを提供することができる。サブスクリプションモジュール内のドメインは、ＭＥ内で実行するには安全または好都合ではない可能性があるセキュリティに敏感な機能および／またはアプリケーションを実行することができる。ドメインは、所有権が発生する前の基本的な機能を伴う「元の」状態にあることが可能である。ドメインは、所有権プロセスを通じて完全な機能を実現することができる。例示的な一実施形態によれば、所有者は、本明細書に記載されているような外部ステークホルダまたはその他のステークホルダであることが可能である。１人の所有者が、１つのＴＤの所有権を取得することができる。１人の所有者が、複数のＴＤを所有することもできる。ＴＤアプリケーションは、ＴＤおよび／またはアプリケーションが存在する構造を監督することができる。ＴＤは、ＴＤ ＡＰＰ Ｓ／Ｗおよび／またはポリシーファイルＳＤＭおよび／またはＳＤＰおよびその関連付けられているＳＤによって管理することができる。たとえば、ＴＤは、ＴＤアプリケーションの観点から管理することができる。

ＴＳＩＭ（Ｔｒｕｓｔｅｄ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍａｎａｇｅｍｅｎｔ）は、ＵＭＴＳにおけるＵＳＩＭとして特定のＴＤ内で同様の役割を果たすことができる。これは、ＵＳＩＭがＵＭＴＳにおけるサブスクリプションアプリケーション機能であることに起因すると言える。ＴＳＩＭは、ＵＳＩＭよりも抽象的な論理エンティティであると言える。ＴＳＩＭは、ＵＭＴＳ環境におけるＵＳＩＭのサブスクライバー機能、たとえば認証および／またはキー合致などを提供することができるが、ＵＳＩＭのようにＵＩＣＣに結び付けることはできない。その代わりに、ＴＳＩＭは、ＴＨＳＭ内のＲＯの（１つまたは複数の）ＴＤ内に存在することができる。より大きな一般性をＧＰ準拠のアーキテクチャから得ることができ、ここでは、そうした一般性について説明する。ＴＳＩＭは、ＶＳＩＭ（Ｖｉｒｔｕａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ）に関連し、ＶＳＩＭの拡張であることも可能である。

ＲＯ（Ｒｅｍｏｔｅ Ｏｗｎｅｒ）は、ＲＴＯ（Ｒｅｍｏｔｅ Ｔａｋｅ−Ｏｗｎｅｒｓｈｉｐ）プロトコルを通じてＴＤに対する自分の所有権ステータスを得るリモートステークホルダであると言える。複数のＲＯが、ＴＤの所有権を得ることができる。

ＤＭ（Ｄｅｖｉｃｅ Ｍａｎｕｆａｃｔｕｒｅｒ）は、リモート所有者であると言える。ＤＭの所有権プロセスは、ＵＥの電源投入時に事前構成することおよび／または確立することが可能である。ＤＭによって所有されている信頼できるドメインは、ＴＤ_ＤＭと表示される。

ＤＯ（Ｄｅｖｉｃｅ Ｏｗｎｅｒ）は、たとえば企業のＩＳＴ部門などの団体である場合がある。ＤＯは、個人である場合がある。ＤＯは、ＵＥにとってローカルであるとみなされる場合がある。所有権プロセスは、事前構成すること、および／またはリモートで行うこと（ＲＴＯ）が可能である。ＤＯによって所有されている信頼できるドメインは、ＴＤ_ＤＯと表示される。ＤＯによって所有されているエンティティは、ＵＥ、ＭＥ、および／またはＴＨＳＭであることも可能である。

Ｕ（Ｄｅｖｉｃｅ Ｕｓｅｒ）は、ＤＯと同じ場合もあり、または異なる場合もある。このアーキテクチャによって、複数のユーザをサポートすることができる。団体による所有権のケースにおいては、団体、および／または団体内のそれぞれのエンティティが、ユーザとして機能することができる。たとえば、団体が複数の従業員を含むケースにおいては、それらの従業員は、ユーザとして機能することができる。ユーザは、ローカルなＴＯ（ｔａｋｅ ｏｗｎｅｒｓｈｉｐ）プロセスを通じて所有権を取得することができる。Ｕによって所有されている信頼できるドメインは、ＴＤ_Ｕと表示される。

ＳＤＭ（Ｓｙｓｔｅｍ−ｗｉｄｅ Ｄｏｍａｉｎ Ｍａｎａｇｅｒ）は、リモートから所有されるドメインを構成すること、リモートから所有されるドメインの元の状態を確立すること、および／または、リモートから所有されるドメインに関するＲＴＯを通じて確立されるその後の状態において主要な役割を果たすことを担当することができる。ＳＤＭは、自分のプロセスを推進するためにポリシー情報を採用することができる。ＳＤＭは、ＴＳＩＭ階層内のＴＤのＴＳＩＭシステムを管理することができる。ＳＤＭは、ＧＰ環境内のアプリケーションの１つのスイートであることが可能である。ＳＤＭがＧＰ環境内にある場合には、ＳＤＭの監督下にないその他のアプリケーションが存在することができる。たとえば、ＴＳＩＭ階層、ならびにスマートカード上のその他のアプリケーションは、ＣＩによって付与される許可のおかげでＧＰ環境内に存在することができる。信頼のレベルに基づいて特権を付与することができ、スマートカード上に常駐することを許可されているアプリケーションに対して、たとえばＣＩによって、特権を付与することができる。

ＳＤＰ（Ｓｙｓｔｅｍ Ｄｏｍａｉｎ Ｐｏｌｉｃｙ）は、元のリモートから所有されているドメインのうちのどれがＳＤＭによって作成されているか、および／またはそれらのドメインに関するＲＴＯがどんな状況のもとで行われるかを特定することができる事前構成されたファイルであると言える。ＳＤＰは、静的なものとすることはできない。なぜなら、ポリシーの変更については、必要が生じるたびに個々にＲＯと交渉することができるためである。ＴＳＩＭプロセスを統制するアクティブポリシーは、ＧＰカードマネージャによって最終的に監督することができる。

スマートカード、たとえばＧＰ準拠のスマートカードなどを含むデバイスに関してさまざまなステークホルダが果たす役割を識別および／または定義することは、ＴＤアプリケーションが自分の潜在的な機能を実現できる際の柔軟性を決定する上で役立つことができる。ここで説明するのは、さまざまなステークホルダの例、およびスマートカードを含むデバイスに関してそれらのステークホルダが果たすことができる役割の説明である。ここで説明するステークホルダのうちの任意の１人または複数は、ワイヤレス通信デバイス上でのセキュリティポリシー実施の最終的な制御を有することができる外部ステークホルダであることが可能であるが、本明細書においては、一般にＣａｒｄ Ｉｓｓｕｅｒが、セキュリティポリシー実施の最終的な制御を有する外部ステークホルダとして記載されている。

ＣＩ（Ｃａｒｄ Ｉｓｓｕｅｒ）カード発行者は、カードを所有する人および／またはエンティティであると言える。ＣＩは、自分の動作に最終的に責任を負うことができる。ＣＩ ＳＤは、カード上にロードすることができるあらゆるアプリケーションのコントローラおよび／またはスーパーバイザであると言える。しかし、本明細書において示されているように、アプリケーションの自律レベルは、関連付けられているＳＤに付与される特権に応じて大幅に変わることができる。

ＣＭ（Ｃａｒｄ Ｍａｎｕｆａｃｔｕｒｅｒ）は、スマートカードの製造業者である。ＣＭは、カードコンポーネント、コマンドインターフェース、トランザクションシーケンス、および／またはスマートカード内の類似のハードウェアから構成されている実際のハードウェアの生産者であると言える。概念的なエンティティとしてのＣＭは、スマートカードのソフトウェアおよび／またはアプリケーション機能を実施する上での重要性が相対的に高くないと言える。

端末所有者は、デバイスの端末コンポーネント部分を所有する人またはエンティティであると言える。たとえば、デバイスが、統合されたカードおよび／または端末から構成されている場合には、所有者は、ＡＴ＆Ｔ（登録商標）もしくはＶＥＲＩＺＯＮ（登録商標）などのサービスプロバイダ、金融機関、および／またはその他のサービス提供エンティティであることが可能である。例示的な一実施形態によれば、端末所有者は、ＩＳＴ部門などの企業、および／または、デバイスのユーザとして識別することができる従業員にデバイスを分配している会社であることが可能である。端末所有者は、デバイスの個人ユーザであることも可能である。２つの所有権構成を可能とすることができる。たとえば、カードおよび／または端末の所有者どうしは、同じエンティティもしくは人であってもよく、または異なってもよい。したがってＣＩは、端末ならびにカードを所有することができる。

デバイスユーザは、デバイスを使用する人または企業であると言える。

ＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｖｉｄｅｒ）は、カード上に常駐するアプリケーションを提供および／またはインストールすることができる潜在的な多くのエンティティのうちの任意のエンティティであると言える。たとえば、ＡＰは、サービスプロバイダであることが可能である。ＴＤアプリケーションに関しては、ＡＰは、ＴＤアプリケーションプロバイダおよび／またはＴＤのＲＯであることが可能である。ＴＤ ＡＰは、ＴＤ構成を、および／または、自律を有する範囲内でＴＤアプリケーション内のＴＤの動作を制御するソフトウェアの所有権を有することができる。ＴＤ ＳＤＭ、および／またはＴＳＩＭ ＳＤＰは、本明細書において説明および／または定義されているような関連するエンティティであることが可能である。ＲＯはＡＰであることが可能であるということを考えれば、ＡＰおよびＲＯは、交換可能に使用することができる。

ＣＡ（Ｃｏｎｔｒｏｌｌｉｎｇ Ａｕｔｈｏｒｉｔｙ）は、インテグリティチェック方法であるＤＡＰ（Ｄａｔａ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐａｔｔｅｒｎ）Ｖｅｒｉｆｉｃａｔｉｏｎを命じることを通じてＣａｒｄ Ｃｏｎｔｅｎｔに対する制御を保持する特権を有することができる。ＣＡは、カード上にロードされたアプリケーションコード上でセキュリティポリシーを実施する特権を有することができる。

上述のステークホルダの説明に関して、さまざまな想定を行うことができる。さまざまなステークホルダの構成によって、カード管理の結果を推進することができる。これらのカード管理の結果は、カードアプリケーションが行動を許可される様式に影響を与えることができる。したがって、アプリケーション自律のレベルは、説明する想定に依存することができる。

ＧＰ（Ｇｌｏｂａｌ Ｐｌａｔｆｏｒｍ）およびＴＳＩＭ／ＴＨＳＭスマートカードは、アーキテクチャおよび／またはフィロソフィーにおいて異なることが可能である。ＧＰは、ＧＰの主要部分、たとえばＣＩ ＳＤ、ＯＰＥＮ、および／またはＣＶＭ（Ｃａｒｄｈｏｌｄｅｒ Ｖｅｒｉｆｉｃａｔｉｏｎ Ｍｅｔｈｏｄ）Ｓｅｒｖｉｃｅｓなどを用いて、カードマネージャの定義および／または記述を指定することができる。ＧＰは、ステークホルダに対応するセキュリティドメインを使用して、カードマネージャの定義および／または記述を指定することもできる。たとえば、ＧＰは、ＣＩＳＤ、ＯＰＥＮ、およびＣＶＭ Ｓｅｒｖｉｃｅｓ、ならびに、３つの主要なステークホルダに対応するセキュリティドメインを用いて、カードマネージャの定義および／または記述を指定することができる。これらの記述は、セキュリティドメインおよび／または非セキュリティドメインアプリケーションのライフサイクル、ならびにカード上での（アプリケーション間の）および／またはカード外での通信（関連したセキュリティ問題を含む場合がある）をカバーすることができる。記述されるセキュリティドメインの特徴は、ドメインの階層構造、および／またはそれらの構造を統制するルールを含むことができる。しかし、さまざまなアーキテクチャフレームワーク内で、少なくとも２つのＴＳＩＭ／ＧＰの共通点を認識することができる。それらは、次のように与えられる。１）アプリケーション、機能、および／もしくは証明書のリモートダウンロード、ならびに／または２）複数のステークホルダの調節。ＧＰに関する主要なステークホルダは、ＣＩ、ＣＡ、および／またはＡＰであると言える。

ここで説明するのは、ＴＨＳＭ／ＴＤと、ＧＰとの間における実施態様の比較の例である。一実施形態によれば、ＧＰの実施態様と比べて、ＲＴＯ、登録、および証明書ダウンロードプロトコルへのユーザの関与は、異なることが可能であり、登録および／もしくは証明書ロールアウトプロセスにおけるＰＯＳ（ｐｏｉｎｔ ｏｆ ｓａｌｅ）の使用は、異なることが可能であり、インテグリティチェックを採用するＴＤのセキュリティの側面は、異なることが可能であり、１人および／もしくは２人のデバイス所有者を含む移行プロトコルは、異なることが可能であり、ならびに／または、ＭＥが完全なＭＴＭ機能を有し、リモートから所有されるドメインを自分の上に、および／もしくはカード上にインストールすることを可能にすることができるＴＤの実施形態は、異なることが可能である。

本明細書に記載されているように、ＴＤコンセプトは、ＧＰアーキテクチャ内に組み込むことができる。ＧＰ環境におけるＴＤの実現は、ＴＤおよび／またはそれらの関連付けられているＧＰ ＳＤから構成することができる。それぞれのＴＤは、そのドメインのための機能を提供するＴＤアプリケーションを所有することができる。それぞれのＴＤは、自分のアプリケーションのインストレーションおよび／またはその後の動作に関するカードレベルのセキュリティを提供することができる、関連付けられているＳＤを有することもできる。いくつかの実施形態においては、ＴＤは、ＳＤとは別個の異なるエンティティである。

図５は、非ＴＳＩＭ関連ＳＳＤ（ｓｕｂｓｉｄｉａｒｙ ｓｅｃｕｒｉｔｙ ｄｏｍａｉｎ）５０２、およびＴＤＭ（ＴＤ ｄｏｍａｉｎ ｍａｎａｇｅｒ）関連ＳＳＤ５０４という２つのセキュリティドメイン（両方とも、ＣＩ ＳＤ５００に対して補助的である）を伴うＧＰ ＳＤ階層を示す例示的なブロック図である。非ＴＳＩＭ ＳＳＤ５０２は、アプリケーション５１６を制御することができる。ＴＤＭ ＳＳＤ５０４は、デバイス所有者（ＤＯ）またはユーザ（Ｕ）のためのアプリケーションＴＤ５１０から構成することができる。アプリケーションＴＤ５１０は、ＴＤＭ ＳＳＤ５０４に対して補助的である関連付けられているＴＳＩＭ ＳＳＤ５０８を有する。ＴＤＭ ＳＳＤ５０４に対して補助的である関連付けられているＳＤ５１２_１〜ｎを有するＲＴＯ前のアプリケーションＴＤ^＊５１４_１〜ｎのセットも示されている。たとえば、ＲＴＯが行われない場合には、それぞれのＴＤ^＊５１４_１〜ｎは、元の状態にあり、まだリモートから所有されない。ＴＤＭ ＳＳＤ５０４は、ドメインマネージャと呼ばれる場合もある。ＴＤＭ ＳＳＤ５０４の機能は、実質的に、デバイス製造業者および／またはデバイス所有者の機能に取って代わることができる。

ＣＩと、ＴＳＩＭ−ＡＰ（ＴＳＩＭ ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｖｉｄｅｒ）との間における演繹的なポリシー合致は、ＡＭＰ、ＤＭＰを許可すること、またはＡＭＰもＤＭＰも許可しないことが可能である。オペレーショナルモードは、トークンベースとすることができる。一実施形態においては、ＣＩ ＳＤ５００は、ＴＤＭ ＳＳＤ５０４がＡＭＰを付与されない限り、ＴＶおよびＲＧ特権を有する。ＣＩ ＳＤ５００は、たとえば、ＡＭＰもＤＭＰもＴＤＭ ＳＳＤ５０４に付与されていない場合には、信頼できるドメインのＴＳＩＭアプリケーションプロバイダのロードファイルをロードすることができる。トークンベースモードにおいては、たとえば、信頼できるドメインのＴＤＭアプリケーション（ＡＰＰ ＴＤ_ＴＤＭ５０６など）のローディングのためのＴＶおよびＲＧを、信頼できるドメインのアプリケーションプロバイダによって実行することができる。完成された信頼できるドメインは、可能性のあるＧＰの制約を除いて、完全に機能的である（たとえば、元の状態ではない）ことが可能であり、証明書を含むことができる。ＡＭＰまたはＤＭＰが演繹的なポリシー合致において許可されている場合には、それぞれの元のＴＤ^＊５１４_１〜ｎのためのアプリケーションをＴＤＭ ＳＳＤ５０４によってロードすることができる。そうでない場合には、それらのアプリケーションは、ＣＩ ＳＤ５００によってロードすることができる。結果として得られる元の信頼できるドメインの機能がＴＳＩＭの好みと合っているかどうかは、アプリケーションローディングプロセスに依存することができる。

Ａｐｐ ＴＤ_ＴＤＭ５０６と表示されている信頼できるドメインは、さまざまなサービスプロバイダ、たとえば、ＭＮＯ、銀行コンツェルン（ｂａｎｋｉｎｇ ｃｏｎｃｅｒｎ）などに相当する場合があるリモート所有者の複数のリモートから所有されている信頼できるドメインになることができるものは何であるかを管理するアプリケーションコンポーネントを含むことができる。ＴＤマネージャアプリケーションは、少なくとも部分的に、ＳＤＭおよび／またはＳＤＰから構成することができる。これらは、図５において構成されている内容を推進するものであると言える。

たとえば、ＧＰ Ｐｌａｔｆｏｒｍ上には、さまざまなＴＳＩＭ構成が存在することができる。ここで説明する例示的なＴＳＩＭ構成は、ＴＳＩＭアプリケーション、および／または、ＴＳＩＭアプリケーションによって対応される任意のアプリケーションに対してＧＰプラットフォーム動作環境が許可することができる自律のレベルに対応する。図６、図７、および図８は、ＧＰセキュリティドメイン（ＳＤ）構造の例示的な構成を示す図である。ＴＳＩＭ Ｄｏｍａｉｎ Ｍａｎａｇｅｒ ＳＤは、ＣＩ ＳＤに対して補助的であることが可能である。ＴＳＩＭ Ｄｏｍａｉｎ Ｍａｎａｇｅｒ ＳＤは、非ＴＳＩＭアプリケーションＳＤに対して補助的であることが可能である。リモートから所有されているＴＤ ＳＤは、ドメインマネージャと同じレベル上に存在すること、および／またはドメインマネージャに対して補助的であることが可能である。ＧＰカード管理システムによって付与される特権は、ＴＤ構成どうしを互いに区別することができる。ＣＩによって許可される特権は、ＴＤ構成どうしを区別する際に特に重要となる場合がある。ＴＳＩＭは、アプリケーションのセットとみなすことができる。それぞれのアプリケーションは、それぞれのＴＤによって実現される機能を提供することができる。

一実施形態によれば、ＣＩは、ドメインマネージャＳＤに、および／または、階層においてドメインマネージャＳＤよりも下位のいかなるＳＤにもＤＭＰ（ｄｅｌｅｇａｔｅｄ ｍａｎａｇｅｍｅｎｔ ｐｒｉｖｉｌｅｇｅ）を付与することはできない。図６は、ＣＩ ＳＤ６００がＤＭＰを付与しないＧＰセキュリティドメイン（ＳＤ）構造の一構成を示す図である。この構成においては、ドメインマネージャＳＤ６０４は、関連付けられているアプリケーションソフトウェアを、ＡＰＰ ＴＤ_ＴＤＭ６０６と表示されているＴＤ内にインストールすることができる。そしてドメインマネージャＳＤ６０４は、インストールされるその後のアプリケーションのためのすべてのロードファイルを、その編成におけるＴＳＩＭドメイン階層の一部として、ならびに／または、主要なＴＳＩＭ機能、たとえば、ＲＴＯ、登録、証明書ロールアウト、および／もしくは類似のＴＳＩＭ機能などのうちの任意の機能の実行の一部として、ロードする特権を有することはできない。ＣＩ ＳＤ６００は、ローディングオペレーション、および／またはトークン使用に関するオペレーションを制御することができる。たとえば、ＣＩ ＳＤ６００は、システムドメインポリシーに従って、それぞれのＴＤに関するロードファイルをロードすることができる。ＴＶおよびＲＧ特権を有するＣＩ ＳＤ６００では、オペレーショナルモードは、シンプルにすること（たとえば、トークンなしにすること）、またはトークンベースにすることが可能である。ＣＩ ＳＤ６００は、アプリケーションコードのインテグリティチェック（ＧＰにおいては、ＤＡＰ（Ｄａｔａ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐａｔｔｅｒｎ）Ｖｅｒｉｆｉｃａｔｉｏｎと呼ばれる）を取り扱うこともできる。

図６において示されているように、信頼できるドメインＴＤ６１４_１〜ｎ ＴＤ_ＲＯには、アスタリスクが付いていない。なぜなら、ＲＴＯがそれぞれのインスタンスにおいて行われていると想定することができるためである。このインスタンスにおけるＲＴＯは、ＣＩ ＳＤ６００ポリシーによって制限することができ、それぞれのＲＯが自分のＴＤの制御を有することになるレベルは、そのようなポリシーによって決定することができ、最小限には、ＴＳＩＭドメインマネージャＳＤＭメカニズムによって決定することができる。たとえば、それぞれのＴＤ６１４_１〜ｎは、ＣＩ ＳＤ６００によって制御されるＲＴＯプロトコルを介して形成することができ、ひいては、結果として得られる信頼できるドメインは、限定されたＴＳＩＭ機能を有することができる。ＲＴＯ前のアプリケーションＴＤ６１４_１〜ｎのセットはそれぞれ、関連付けられているＳＳＤ６１２_１〜ｎを有することができる。トークンベースモードにおいては、それぞれのＴＤ６１４_１〜ｎごとのアプリケーションのローディングに関するトークン検証およびレシート生成は、対応するリモート所有者によって実行することができる。ドメインマネージャＴＤ６０６に関しては、ＴＶおよびＲＧは、ＴＳＩＭアプリケーションプロバイダによって実行することができる。

別の実施形態によれば、ＣＩは、ＤＭＰをドメインマネージャＳＤに付与することができる。図７は、ＣＩ ＳＤ７００がＤＭＰを、たとえば演繹的なポリシー合致に従って付与するＧＰ ＳＤ（ｓｅｃｕｒｉｔｙ ｄｏｍａｉｎ）構造の例示的な一構成を示す図である。ＣＩ ＳＤ７００は、ＴＶおよびＲＧ特権を所有することができる。このインスタンスにおいては、ＴＤドメインマネージャＳＤ７０４は、自分自身のロードファイルをロードすることを選択することができる。ＴＳＩＭドメインマネージャＳＤは、トークン管理、もしくはＴＶ（ｔｏｋｅｎ ｖｅｒｉｆｉｃａｔｉｏｎ）、および／またはＲＧ（ｒｅｃｅｉｐｔ ｇｅｎｅｒａｔｉｏｎ）をＣＩ ＳＤ７００によって取り扱うことができる場合には、自分自身のロードファイルをロードすることを選択することができる。ＤＡＰの検証も、発行者ＳＤ７００の担当とすることができる。

ＴＤドメインマネージャＳＤ７０４がＤＭＰを付与される一実施形態においては、ドメインマネージャＳＤ７０４は、ＲＴＯ後の機能がＴＳＩＭの動作環境との整合性に類似するレベルを決定するために、より多くの自律を有することができる。たとえば、オフカードＴＳＩＭ ＡＰは、ロードプロセスを開始するためのトークンを生成することができる。ロードプロセスは、トークンがＣＩ ＳＤ７００によって検証される場合に、継続することができる。ロードプロセスは、ＣＩによるレシートの生成、および／またはＡＰによるレシートの検証に伴って、完了することができる。ＴＶおよび／またはＲＧ手順は、ＣＩ ＳＤ７００および／またはＡＰの間に署名および／または検証のためのキー構造が存在するということを前提にすることができる。トークンベースモードにおいては、それぞれのＴＤ７１４_１〜ｎごとのアプリケーションのローディングのためのトークンの検証およびレシートの生成は、対応するリモート所有者によって実行することができる。それぞれのＴＤ７１４_１〜ｎは、ＴＤＭ ＳＳＤ７０４に対して補助的であることが可能な対応するＴＳＩＭ ＳＳＤ７１２_１〜ｎを有することができる。ドメインマネージャＴＤ７０６に関しては、ＴＶおよびＲＧは、本明細書に記載されているように、ＴＳＩＭアプリケーションプロバイダによって実行することができる。

別の実施形態によれば、ドメインマネージャＳＤには、例示的な一構成に関しては、発行者ＳＤによって完全なＡＭ（Ａｕｔｈｏｒｉｚｅｄ Ｍａｎａｇｅｍｅｎｔ）Ｐｒｉｖｉｌｅｇｅを付与することができる。図８は、発行者ＳＤ８００によって完全なＡＭ（Ａｕｔｈｏｒｉｚｅｄ Ｍａｎａｇｅｍｅｎｔ）Ｐｒｉｖｉｌｅｇｅを付与されている例示的なＴＤドメインマネージャＳＤ８０４を示す図である。ＡＭＰの付与によって、ＴＳＩＭアプリケーションに完全な自律をもたらすことができる。ＴＳＩＭアプリケーションは、発行者ＳＤ８００からの管理制御を伴わずに、ロードファイルをロードすることができる。したがって、ＴＳＩＭアプリケーションは、トークンの有無を問わずに、コードインストレーションを実行することができる。ＴＳＩＭアプリケーションは、ＤＡＰ検証アクティビティを担当することができる。ＴＤドメインマネージャＳＤ８０４は、ＴＶおよびＲＧ特権を有することもできる。トークンベースモードにおいては、それぞれのＴＤ８１４_１〜ｎごとのアプリケーションのローディングのためのトークンの検証およびレシートの生成は、対応するリモート所有者によって実行することができる。ドメインマネージャＴＤ８０６に関しては、ＴＶおよびＲＧは、ＴＳＩＭアプリケーションプロバイダによって実行することができる。

ＴＳＩＭアプリケーションに関しては、このレベルの自律で完全なＴＳＩＭ機能を実現できると想定することができるが、カードマネージャ、具体的にはＯＰＥＮ（Ｇｌｏｂａｌ Ｐｌａｔｆｏｒｍ Ｅｎｖｉｒｏｎｍｅｎｔ）（その担当としては、インストールされたアプリケーションにＡＰＩを提供すること、コマンドディスパッチ、および／またはカードコンテンツの管理を含むことができる）が、アプリケーションの動作を監督することができる。たとえば、ＯＰＥＮは、それぞれのＴＤ８１４_１〜ｎを形成してＴＤドメインマネージャＳＤ８０４によって制御されるＲＴＯプロトコルを監督することができる。それぞれのＴＤ８１４_１〜ｎは、ＴＳＩＭ機能のほとんどすべてまたはすべてを所有することができる。特定のセキュリティポリシーが違反された場合には、アプリケーションをＬＯＣＫＥＤ状態に置くこと、および／またはアプリケーションの実行を防止することが可能である。これらの制御は、図６および図７に関連して説明した構成にも適用することができる。なぜなら、それらの構成は、より多くの制約のもとで機能している場合もあるためである。ここでは、アプリケーション動作の制御のためのグローバルプラットフォームルールについて、さらに詳細に説明する。

本明細書に記載されているように、ＴＤは、ＧＰプラットフォーム上に構築することができる。ＴＳＩＭアプリケーションは、その動的な性質のおかげで、時間とともに自分自身を構築することができる。ＴＳＩＭアプリケーションは進化的であると言うことができる。この進化的なプロセスを開始するために使用することができるメカニズムが、構成ファイルであると言える。構成ファイルは、ＴＳＩＭのための構造的な土台を築くことができる。構成ファイルは、カード上に常駐することができるということを考えれば、ＴＤ_ＴＤＭ（ｄｏｍａｉｎ ｍａｎａｇｅｒ ｔｒｕｓｔｅｄ ｄｏｍａｉｎ）の編成を担当することができる。ＴＤ_ＤＯ（ｄｅｖｉｃｅ ｏｗｎｅｒ ｔｒｕｓｔｅｄ ｄｏｍａｉｎ）および／またはＴＤ_ｕ（ｕｓｅｒ’ｓ ｔｒｕｓｔｅｄ ｄｏｍａｉｎ）など、その他のドメインをインストールすることもできる。しかし、信頼できるドメインのインストレーションプロセスは、ＧＰ準拠のカード上では、ＴＨＳＭ環境と比較して、異なることが可能である。ＴＤ_ＴＤＭは、カード発行者ＳＤの許可に伴ってロードすることができる。構成ファイルは、ＴＤ_ＴＤＭを構成するために使用することができるが、製造時にインストールすることはできない。このファイルは、ＤＭロードファイルの一部とすることができ、ならびに／または、所与の信頼できるドメインを構成するために、および／もしくは所与の信頼できるドメインのためのコードをインストールするために、ＯＰＥＮによってアクティブ化することができる。

上述の構成は、ドメインマネージャの信頼できるドメインＴＤ_ＴＤＭに関連付けられているＳＤの中心に置かれたＴＳＩＭ制御を有することができるが、その一方で、ＴＤアプリケーションの実際の実施態様においては、ポリシー制御は、ＳＤＭとともに存在することができ、ＳＤＭは、ＴＤ_ＤＯ内のアプリケーションであることが可能である。上述のＳＤ階層は、ＴＤ_ＴＤＭ内に存在する同様のＴＳＩＭポリシーマネージャを使用して実装することができる。

いくつかの実施形態によれば、信頼できるドメインのアプリケーションをＧＰ環境へポートすることができる。最も高いレベルにおいては、ＴＤコンセプトを、ＧＰ準拠のスマートカード上のアプリケーションの別個のセットとしてＧＰ環境へポートすることができる。特定のステークホルダどうしによるＳＤ所有権の関係が、ＴＤをＧＰへポートする際の制約に影響を与える場合がある。たとえば、ＴＤ ＡＰおよびＣＩが同じであることは、ＧＰへの堅牢なポーティングにとって好ましい場合があり、ＴＤ ＡＰおよびＣＩが異なることは、あまり好ましくない場合がある。このポーティングプロセスに関しては、いくつかの使用事例を考えることができる。ここでは、ポーティングプロセスへの影響について、さらに詳細に説明する。

一実施形態によれば、ポーティングプロセスは、ＴＤアプリケーションが進展するにつれて、そのＴＤアプリケーションのための最大限の自律を許可することができる。ＣＩおよび／またはＴＤ ＡＰが同じであることがある使用は、許可された自律の影響を最も受けやすい場合がある。

ＴＤＭ（ｔｒｕｓｔｅｄ ｄｏｍａｉｎ ｍａｎａｇｅｒ） ＳＤ（ｓｅｃｕｒｉｔｙ ｄｏｍａｉｎ）を作成することができる。本明細書に記載されているように、ＴＤＭ ＳＤは、ＩＮＳＴＡＬＬＥＤ状態、ＳＥＬＥＣＴＡＢＬＥ状態、ＰＥＲＳＯＮＡＬＩＺＥＤ状態、および／またはＬＯＣＫＥＤ状態など、さまざまな状態に従って構成することができる。ＴＤＭアプリケーション（ＴＤ_ＴＤＭ）に対応する、および／またはＴＤ ＡＰによって所有されているＴＤＭ ＳＤ（ｔｒｕｓｔｅｄ ｄｏｍａｉｎ ｍａｎａｇｅｒ’ｓ ｓｅｃｕｒｉｔｙ ｄｏｍａｉｎ）は、ＧＰスマートカード上でＰＥＲＳＯＮＡＬＩＺＥすることができ、その後で、ＴＤＭの指示のもとで動作するアプリケーションを作成すること、および／またはそうしたアプリケーションをＴＤＭに関連付けること、および／またはそうしたアプリケーションをそれらのアプリケーションのその他の補助セキュリティドメインに関連付けることが可能である。一実施形態によれば、ＴＤ ＡＰは、ＴＤＭ ＳＤがＣＩによってＩＮＳＴＡＬＬされること、および／またはＧｌｏｂａｌ Ｐｌａｔｆｏｒｍ Ｒｅｇｉｓｔｒｙ内に入れられることを要求することができる。次いでドメインは、ＳＥＬＥＣＴＡＢＬＥ状態へと遷移することができ、それによってドメインは、オフカードエンティティからパーソナライゼーションコマンドを受け取ること、および／またはＰＥＲＳＯＮＡＬＩＺＥＤ状態へと遷移することが可能である。ＰＥＲＳＯＮＡＬＩＺＥＤ状態においては、ＳＤは、ＧＰ環境において正しく機能するためのキーイング情報を有することができる。

セキュリティドメインに関するライフサイクル状態は、いかなるＳＤ階層におけるそれらのセキュリティドメインの位置にもかかわらず、一定であることが可能である。図９は、ＩＮＳＴＡＬＬＥＤ９０２、ＳＥＬＥＣＴＡＢＬＥ９０４、ＰＥＲＳＯＮＡＬＩＺＥＤ９０６、およびＬＯＣＫＥＤ９０８という例示的なＳＤ状態を示す図である。図９はまた、一般的なＧＰ設定における遷移メカニズムを示している。ＴＤＭ ＳＤのケースにおいては、ＣＩ ＳＤは、（たとえば、ＩＮＳＴＡＬＬＥＤ状態９０２への）インストールを行うための、および／またはＳＤをＳＥＬＥＣＴＡＢＬＥ状態９０４へ遷移させるための特権を有するセキュリティドメインであることが可能であり、ＳＥＬＥＣＴＡＢＬＥ状態９０４では、ＣＩ ＳＤは、適切なアクセス特権を有するオフカードのまたは外部のエンティティからＧＰコマンドを受け取ることができる。そのような１つのオフカードエンティティが、たとえばＳＤのＡＰであると言える。遷移プロセスがＳＤ自体によって開始されると、ＡＰは、ＰＥＲＳＯＮＡＬＩＺＥＤ状態９０６に入る手段としてパーソナライゼーションデータおよび／またはセキュリティキーを生成および／またはロードすることによって、フォローアップすることができる。ＤＭ ＳＤは、たとえばＣＩ ＳＤ、ＴＤＭ ＳＤ自体、および／または別の外部ステークホルダＳＤによって、ＬＯＣＫＥＤ状態９０８へと遷移させることができる。ＬＯＣＫＥＤ状態９０８は、セキュリティ上の制御として使用することができる。たとえば、ＬＯＣＫＥＤ状態９０８は、ＳＤに関連する脅威がカード内で検知された場合に、セキュリティ上の制御として使用することができる。脅威の検知は、ＯＰＥＮによって監督することができる。

図１０、図１０Ａ、および図１０Ｂは、ＴＤＭ ＳＤのライフサイクル状態に対応することができる例示的なメッセージングの詳細を示している。このライフサイクル構造は、図９において示されているライフサイクル構造を反映することができる。たとえば、トークンの使用は、図１０におけるＣＩ ＳＤ１０００のポリシー要求であると想定することができる。オフカードＴＤ ＡＰ１００４が、署名されたトークンを１００６において提供することができる。それらのトークンを検証して、プロセスを前に進めることができる。ＣＩ ＳＤ１０００と通信する際には、トークンを使用することができる。ＡＭＰを有するＴＤＭ ＳＳＤ（ｓｕｐｐｌｅｍｅｎｔａｌ ｓｅｃｕｒｉｔｙ ｄｏｍａｉｎ）１００２などの補足ＳＤと通信する際には、トークンを、要求されていない場合に使用することはできない。

ＴＤ ＡＰ１００４および／またはＣＩ ＳＤ１０００は、示されているプロトコルステップが行われる前にキー構造が配置されるように手配することができる。ＴＤＭ ＳＤは、図１０〜図１０ＢにおいてはＴＤＭ ＳＳＤ１００２として示されている。なぜなら、このセキュリティドメインは、ＣＩ ＳＤ１０００に対して補助的であることが可能であるためである。図１０のそれぞれのステップは、ＴＤＭ ＳＤを次の状態へ遷移させることができる。

たとえば、ＴＤ ＡＰ１００４は、ＴＤＭ ＳＳＤ１００２の作成を要求することができる。その要求に基づいて、ＣＩ ＳＤ１０００は、ＴＤ ＡＰ１００４からのトークンを検証して、ＴＤＭ ＳＳＤ１００２を作成することができる。ＴＤＭ ＳＳＤ１００２は、ＩＮＳＴＡＬＬされることが可能になり、ＧＰレジストリ内にエントリを有することができる。ＴＤＭ ＳＳＤ１００２は、その後のアプリケーションインストレーションを実行するためのＧＰ内のセキュリティサービス、および／または特定のアプリケーションのためのその他のＳＤの作成を提供することができる。

図１０Ａは、一実施形態に従って、ＴＤＭ ＳＳＤ１００２をＳＥＬＥＣＴＡＢＬＥ状態へ遷移させるためのコマンド１００８がＴＤ ＡＰ１００４からどのように生じることができるかを示している。コマンド１００８は、ＴＤＭ ＳＳＤ１００２を遷移させるためのトークンを含むことができる。ＣＩ ＳＤ１０００は、そのトークンを検証して、ＴＤＭ ＳＳＤ１００２をＳＥＬＥＣＴＡＢＬＥ状態へ遷移させることができる。いったんＳＥＬＥＣＴＡＢＬＥ状態に入ると、ＴＤＭ ＳＳＤ１００２は、承認されたオフカードエンティティ、たとえばＴＤ ＡＰ１００４などからのパーソナライズされたコマンドを処理することができる。

一実施形態によれば、図１０Ｂは、ＴＤＭ ＳＳＤ１００２がどのようにしてＰＥＲＳＯＮＡＬＩＺＥＤ状態へ遷移することができるかを示している。たとえば、ＣＩ ＳＤ１０００およびオフカードＴＤ ＡＰ１００４は、セキュリティポリシーを取り決めることができる。セキュリティ標準は、ＣＩ ＳＤ１０００によって決定することもできる。ＴＤＭ ＳＳＤ１００２は、自分自身をＰＥＲＳＯＮＡＬＩＺＥＤ状態へ遷移させることができる。パーソナライゼーションデータおよび／またはセキュリティキーを１０１０においてリモートからロードすることができ、それによって、ＴＤＭ ＳＳＤ１００２は、ＴＤ Ｓ／Ｗモジュールおよび／またはサポーティングファイルのインストレーションのために完全に機能するようになる。ローディングプロセスは、ＴＤＭ ＳＳＤ１００２によって開始することができる。ＴＤＭ ＳＳＤのセキュリティ機能は、関連付けられているアプリケーションにとって利用可能にすることができる。トークンは、ＣＩ ＳＤ１０００によって要求することができるが、コマンドは、ＴＤＭ ＳＳＤ１００２に送達することができる。

ＴＤＭ ＳＳＤ１００２のインストレーション、選択、および／またはパーソナライゼーションに続いて、ＴＤアプリケーションの信頼できるドメインをロードおよび／またはインストールすることができる。このプロセスは、ＧＰ準拠のカードのライフサイクル構造に準拠することができる。

図１１は、たとえばＧＰなどにおいて、カード上にロードされたアプリケーションが取得することができるさまざまな状態を示す図である。状態から状態への、および／または特定の状態の外での転送のモードは、いくつかのケースにおいては特権に依存することができる。たとえば、ＡＭ特権および／またはＤＭＰを有するＳＤは、アプリケーションをＩＮＳＴＡＬＬＥＤ１１００からＳＥＬＥＣＴＡＢＬＥ１１０２へ遷移させることができる。しかし、ＤＭ ＳＤがＡＭ特権を有しているか否か、ＤＭＰを有しているか否か、またはそのどちらも有していないかにかかわらず、アプリケーションは、自分自身で、自分に特有であることが可能な特定の状態へと遷移することができる。これらの特定の状態は、図１１においてアプリケーション固有の状態１１０４として示されている。遷移のうちのいくつかは、不可逆的とすることができる。たとえば、ロードされた状態からインストールされた状態１１００への遷移、および／またはインストールされた状態１１００から選択可能な状態１１０２への遷移は、不可逆的とすることができる。遷移のうちのいくつかは、可逆的とすることができる。たとえば、任意の状態から、ロックされた状態１１０６へは、可逆的とすることができ、選択された状態１１０２からアプリケーション固有の状態１１０４へは、可逆的とすることができる。

図１２、図１２Ａ、および図１２Ｂは、ＴＤ_ＴＤＭ（ｄｏｍａｉｎ ｍａｎａｇｅｒ ＴＤ）、ＴＤ_ＤＯ／Ｕ（ｄｅｖｉｃｅ ｏｗｎｅｒ ｏｒ ｕｓｅｒ ＴＤ）、および一般的なＴＤ_ＲＯ（ｒｅｍｏｔｅｌｙ ｏｗｎｅｄ ｄｏｍａｉｎ）など、ＲＴＯ前の信頼できるドメインのインストレーションに関する例示的な進展を示している。このインストレーションでは、ＴＤＭ ＳＳＤ１２０４にＡＭＰを付与することができ、ＧＰメカニズムは、示されている実施形態に関して最大限の自律を可能にすると想定することができる。これによって、ＴＤ ＡＰ１２０２によるコマンドに応じてさまざまな実行可能ファイルおよび／またはデータファイルをロードおよび／またはインストールするための権限をＴＤＭ ＳＳＤ１２０４に提供することができる。複数の実施形態では、トークン使用の有無を問わずにローディングおよび／またはその後のインストレーションを実行するための決定を含むことができる。インストレーションの使用事例のコンテキストに応じて、本明細書において定義されている構成のうちの任意の構成を想定することができ、および／またはプロセスは、それに応じて変わることができる。

インストレーションは、下記のステップのうちの１つまたは複数を含むことができる。１２０６において、ＴＤ ＡＰ１２０２は、要求トークンをＣＩ ＳＤ１２００へ送信することができる。このトークンは、ＴＤＭ ＳＳＤ１２０４にＡＭＰ（ａｕｔｈｏｒｉｚｅｄ ｍａｎａｇｅｍｅｎｔ ｐｒｉｖｉｌｅｇｅ）を付与するために、１２０６において送信することができる。ＣＩ ＳＤ１２００は、トークンを検証することができ、自分のセキュリティポリシーを考慮したことに応答して、その後に、ＴＤＭ ＳＳＤ１２０４にＡＭＰを付与することができる。したがって、ＴＤＭ ＳＳＤ１２０４は、ＰＥＲＳＯＮＡＬＩＺＥＤ状態にあることが可能であり、ＴＤ ＡＰ１２０２からのパーソナライゼーションコマンドを受け入れることができる。また、ＴＤＭ ＳＳＤ１２０４は、ＡＭＰを取得した後に、たとえば自分自身の階層内で、Ｓ／Ｗ実行可能ファイルをロードすること、およびＳＤなどのアプリケーションを構成することが可能である。

（図１２Ａにおいて示されている）１２０８においては、信頼できるドメインの所望のセットを構成するためにインストール可能なＳ／Ｗおよび／またはデータファイルを含むことができるＴＤＭロードファイルをロードするためのコマンドをＴＤ ＡＰ１２０２によってＴＤＭ ＳＳＤ１２０４へ送信することができる。図１２Ｂにおいて示されているように、ＴＤＭロードファイル１２１２は、別々のモジュールから構成することができ、それぞれのファイルおよび／またはＳ／Ｗモジュールは、別個のコマンド１２１０を用いてインストールすることができる。図１２Ｂにおいて示されているような一実施形態によれば、それぞれのＴＤタイプに対応するアプリケーションＳ／Ｗをロードファイル１２１２内に含めることができる。リモートから所有されているドメインＴＤ_ＲＯ１２２０_１〜ｎに関しては、１つの一般的なＳ／Ｗ構成を使用することができる。提示された数のドメインをインストールするために、この構成を繰り返しインスタンス化することを命じることができる。抽出ユーティリティのためのＳ／Ｗをロードファイル内に含めて提供することができる。ここでは、このユーティリティの使用について、さらに説明する。それぞれのＴＤをＴＤＭ ＳＤ１２０４に関連付けることができる。それらのＴＤは、ＴＤ_ＴＤＭ１２１６を除いて、元の（ＲＴＯ前の）状態にあることが可能である。元の状態にあることが可能なＴＤは、図１２ＢにおいてはＴＤ^＊という表記を示している。図１２Ｂにおいては示されていないが、元のドメインは、ＩＮＳＴＡＬＬＥＤであるとみなすことができ、その一方で、ＴＤ_ＴＤＭ１２１６は、完全に機能していること、および／またはアプリケーション固有であることが可能である。ＴＤ_ＴＤＭ１２１６は、ＳＤＭ（ｓｅｃｕｒｉｔｙ ｄｏｍａｉｎ ｍａｎａｇｅｍｅｎｔ）およびＳＤＰ（ｓｙｓｔｅｍ ｄｏｍａｉｎ ｐｏｌｉｃｙ）情報を含むことができる。

ＴＤＭ ＳＳＤ１２０４はＡＭＰを有することができるということを考えれば、ＴＤＭ ＳＳＤ１２０４は、自己関連付けすることができる。図１２Ｂにおいて示されているように、ＴＤＭ ＳＳＤ１２０４は、ＳＤ階層ツリーの最上位に存在することができる。ＴＤ_ＴＤＭ１２１６は、ＳＤ階層内に常駐するアプリケーションのその後の開発のためのマネージャアプリケーションとして機能することができる。ＴＤ_ＴＤＭ１２１６は、マネージャアプリケーションとして機能するために、ＴＤＭ ＳＳＤ１２０４によって提供されるセキュリティサービスを使用することができる。図１２は、ＴＤＭ ＳＳＤ１２０４に関連付けられている信頼できるドメインを示している（別々のＳＤに関連付けられているそれぞれのそのようなアプリケーションとは対照的である）。それらの信頼できるドメインは、本明細書に記載されている構成において示されているように、ＴＤＭ ＳＳＤ１２０４に対して補助的であることが可能である。その構成は、このインストレーションプロセスにおける結果として生じることができる。ＴＤ ＡＰＰ（ａｐｐｌｉｃａｔｉｏｎ）および／または関連付けられているＳＤの多くの異なる組合せを示すことができる。一実施形態によれば、ＴＤＭ ＳＳＤ１２０４に対して補助的である別々のＴＤ ＳＤを、リモートから所有されているドメインのために、登録および／または証明書ロールアウトが行われる際に作成することができる。

ここでは、ＴＤアプリケーションの所有権、およびポーティングを特徴付ける上での意味合いに関して、少なくとも３つのシナリオを説明する。ステークホルダに関しては、いくつかの所有権構成シナリオを考えることができる。ＣＩは、たとえばＭＮＯおよび／または銀行などの金融機関とみなすことができる。ＴＤ ＡＰも、同様にみなすことができる。これらの団体または組織が同じであるかどうかに関して、判定を下すことができる。別の言い方をすれば、カードを発行したエンティティは、ＴＤソフトウェアを所有するエンティティと同じである場合もあり、または異なる場合もある。全体的には、ＴＳＩＭ機能を実現できるレベルは、ＣＩのセキュリティポリシーと、ＴＤのＳＤＰとの間における合致のレベル、または信頼のレベルによって統制することができる。カード発行者およびＴＤ ＡＰが同じエンティティである場合には、高いレベルのポリシー合致が存在することができる。２つの発行エンティティが関与している場合には、可変のポリシーを予期することができる。ポリシーは、ＣＩマネージャレベルおよび／またはＴＤシステムレベルとすることができる。ＴＤコンテキストにおける潜在的に競合するリモート所有者どうしの間でのポリシーの問題は、ここで定義されるシナリオに関連する場合もあり、または関連しない場合もある。

ＲＯがＴＤの所有権を取得することに関しては、ＣＩのポリシーではなく、ＲＯのポリシーと、ＴＤ ＳＤＰのポリシーとの問題が存在する場合がある。カードマネージャおよび／またはＣＩは、望ましくない動作が検知された場合には、アプリケーションをロックすることができる。

上記は、ＣＩと、ＴＤ ＡＰとの間における所有権のシナリオを暗示している。第１のシナリオ（Ｓｃｅｎａｒｉｏ １）によれば、ＣＩカードレベルセキュリティポリシーは、ＴＳＩＭ ＳＤＰに緊密に合致および／または適合することができる。高いポリシー合致は、ＣＩおよびＴＤ ＡＰが同じエンティティであるということを意味している場合がある。高いポリシー合致は、ＣＩがそのアプリケーションを十分に知っており、それによって、ＴＤドメインマネージャＳＤにＤＭＰおよび／またはＡＭ特権を付与する見込みが高くなる可能性があるということを意味している場合がある。そのようなケースにおいては、ロードされるソフトウェア、およびそのソフトウェアがどのように機能するかについて、相当な自由をＴＳＩＭに与えることができる。たとえば、ある使用事例においては、ＣＩは、ＴＤアプリケーションの使用を承認するＭＮＯである場合がある。ＴＤ ＡＰは、たとえばＭＮＯ自体、または承認されたサードパーティベンダである場合がある。Ｓｃｅｎａｒｉｏ １は、ＧＰフレームワークへのＴＨＳＭ／ＴＳＩＭ機能の最大のポーティングにとって最も好ましいと思われる構成であると言える。

第２のシナリオ（Ｓｃｅｎａｒｉｏ ２）によれば、ＣＩカードレベルセキュリティポリシーは、ＴＤ ＳＤＰに部分的にしか合致することができない。部分的な合致は、ＣＩおよびＴＤ ＡＰが別々のエンティティであるということを意味している場合がある。ＣＩおよびＴＤ ＡＰが別々のエンティティであるということをポリシーレベルが示している場合には、アプリケーションに付与される自由のレベルに関して、より制限的な立場を取ることができる。したがって、せいぜいＤＭＰを付与することしかできず、この場合には、ＣＩ ＳＤは、カード上に何がロードされるかを監督する手段として、トークン検証および／またはレシート生成特権を有することができる。ある使用事例においては、ＴＤアプリケーションは、ＣＩではないかもしれないがＣＩによってあるレベルの信頼を与えられている可能性があるＭＮＯによって使用されることを承認されることが可能である。ＴＤ ＡＰは、ＭＮＯ自体、またはＭＮＯによって承認されたサードパーティベンダである場合がある。デバイスのユーザは、独立してアプリケーションをダウンロードできるようにすることができる。

第３のシナリオ（Ｓｃｅｎａｒｉｏ ３）によれば、ＣＩカードレベルセキュリティポリシーは、ＴＤ ＳＤＰと最小限にしか合致することができない。最小限の合致は、ＣＩ ＳＤがアプリケーションを高度に制限的にみなしているということを意味している場合がある。したがって、ＴＳＩＭアプリケーションドメインマネージャＳＤには、ＤＭＰもＡＭ特権も付与することはできない。ソフトウェアは、ＣＩ ＳＤによってロードおよび／または検証することができる。ある使用事例においては、ＴＤアプリケーションは、ＣＩではないがＣＩによって高いレベルの信頼を与えられているＭＮＯによって使用されることを承認されることが可能である。一実施形態によれば、ＴＤ ＡＰは、ＭＮＯ自体、またはＭＮＯによって承認されたサードパーティベンダである場合がある。デバイスのユーザは、独立してアプリケーションをダウンロードすることを許可されることが可能である。しかし、そのようなケースにおいては、ＣＩは、たとえばダウンロードを許可するという、補助ＳＤによって下された決定を却下することができる。ＡＭ特権を有するＳＤが、ダウンロードするという決定を下した場合には、アプリケーションをＬＯＣＫＥＤ状態に遷移することを、ダウンロードおよび／またはその後のアクティブ化の後に、システム（たとえば、ＯＰＥＮ、ＣＩ ＳＤ、または、そうするための特権を有する任意のＳＤ）によって行うことができる。

上述の所有権オプションに関しては、ステークホルダは、ユーザである場合がある。このユーザは、いくらか抽象的にみなすことができ、さまざまな役割を担うことができる。このユーザは、ＣＩ、端末所有者、ＣＡ兼端末所有者、および／またはＤＯである場合がある。

ＴＳＩＭ機能をＧＰへポートできる際の容易さは、ステークホルダ所有権オプション、および／または、ステークホルダに関連付けられているポリシーの対応レベルに依存することができる。ＣＩは、カード上で実行されるアプリケーションの動作を統制するセキュリティポリシーを有することができる。

ここでは、Ｓｃｅｎａｒｉｏ １のもとでのＴＤ機能、たとえば、ＲＴＯ、Ｒｅｇｉｓｔｒａｔｉｏｎおよび／もしくはＲｏｌｌｏｕｔ、ならびに／またはＭｉｇｒａｔｉｏｎなどのポーティングについての説明を提供する。一実施形態によれば、ＴＨＳＭ／ＴＳＩＭの少なくとも３つの機能に関するポーティング手順が存在することができる。本明細書に記載されているように、信頼できるドメインの機能は、それらの機能がＴＨＳＭ環境において考えられるのと同様に定義することができる。ポートされる機能としては、１）ＲＴＯ、２）登録および／もしくは証明書ロールアウト、ならびに／または３）移行を含むことができる。ＣＩは、所有権シナリオ（上述のＳｃｅｎａｒｉｏ １、２、または３）を問わずに、ＡＭＰをＴＤＭ ＳＤに与えることができる。この方法では、それぞれのシナリオのもとで（または、それぞれのシナリオに固有の形で）、ＴＤＭは、たとえば、ＴＤＭがＤＭＰを有することになるケースと比較して、より多くの自律を有することができる。Ｓｃｅｎａｒｉｏ ２および／またはＳｃｅｎａｒｉｏ ３のもとでは、ＣＩがＡＭＰを付与することは、その他の実施形態のもとでの場合と比べて、可能性または現実性が低いかもしれない。ここでは、ポーティングの説明について、さらに記載する。プレゼンテーションモードは、オンカードのＳＤ／ＡＰＰ階層内のさまざまなエンティティと、オフカードＡＰを伴うエンティティとの間におけるメッセージングを示している。ＡＰは、たとえばＣＩを含む任意のリモート所有者である場合がある。

例示的なＲＴＯプロセスが、図１３および図１３Ａにおいて示されている。リモート所有者は、プロトコルの開始時に元の状態にあるＴＤ（たとえば、ＡＰＰ ＴＤ^＊ _ＲＯ１１３０８）の所有権を取得したいと希望しているアプリケーションプロバイダとすることができる。ＲＯ ＡＰ１３０２は、任意のサービスプロバイダとみなすことができる。ＣＩ１３００および／または（そのＣＩと同じ、もしくは異なる）ＴＤ ＡＰは、ＴＤの所有権を取得したいと望む場合には、その他の任意のリモート所有者と同様に、ＲＴＯに従って進むことができる。それらのステップについて、以降で説明する（また、それらのステップは、特定の順序に限定されるものではない）。

ステップ１に関しては、ＲＴＯロードファイルをロードしたいという要求１３１２を、ＲＯ ＡＰ１３０２によってＴＤＭ ＳＤ１３０４に対して行うことができる。この要求は、ＲＯポリシーおよび／またはＴＤ ＳＤＰが十分に合っている場合に許可することができる。交渉を行うことも可能である。本明細書に記載されている図２および図２Ａは、例示的なＲＴＯプロトコルの流れ図を提供している。たとえば、ＲＯ ＡＰ１３０２は、ＳＤＰ／カードポリシー制約に準拠することに合意することができる。ポリシーチェックが実行された後に、ＴＤＭ ＳＤ１３０４は、ＲＯ ＡＰ１３０２による要求に応じて、ＲＴＯファイルをロードすることができる。アプリケーションＴＤ ＴＤＭ１３０６は、ＴＤＭ構成およびポリシー（たとえば、ＳＤＭおよびＳＤＰ）の情報を含むことができる。

図１３Ａにおいて示されているステップ１３１２に関しては、元のＴＤ^＊ _ＲＯ１３０８は、このステップにおいて、（所有されている、元の状態ではない）ＴＤ_ＲＯ１３１０になることができる。ポリシーおよび／もしくは目的ファイル、ならびに／または抽出可能なＳ／Ｗを含むファイルなど、さまざまなコンテンツのＲＴＯロードファイル１３１４をインストールしたいという要求を１３１８において行うことができる。抽出可能なＳ／Ｗを含むファイル内の実行可能ファイルは、ＴＤ ＡＰＰインストレーション（たとえば図１２を参照されたい）中に元のドメインが備えることができる抽出ユーティリティによって抽出することができる。構成情報は、オフカードＲＯ ＡＰ１３０２によって保持することができ、および／または、ＲＴＯ完了時の所有されている信頼できるドメインの状態は、ＰＥＲＳＯＮＡＬＩＺＥすることができる。ＲＴＯファイル１３１４がインストールされた場合には、アプリケーションは、事前に登録されたリモートから所有されているＴＤとして完全に機能するようになることができる。アプリケーションは、ＲＴＯにおいてトークンを使用するかどうかに関する決定を下すことができる。実行可能な抽出されたメカニズムは、オンカードアプリケーションに対するＳ／Ｗ更新上のＧＰ制約を回避するための回避策とすることができる。抽出メカニズムを使用しない場合には、実行可能ファイルを消去すること、および／または新たなＳ／Ｗによって置き換えることが必要となる場合がある。

登録および／または証明書ロールアウトプロトコルは、たとえばＲＴＯなど、所有権取得プロセスを通じて所有されるＴＤ上で実行することができる。図１４、図１４Ａ、および図１５は、登録および／または証明書ロールアウトが実行される一実施形態を示している。図１４および図１４Ａは、ステップ１および２（これらは、特定の順序に限定されるものではない）に関する登録および／または証明書ロールアウトを示している。このプロトコルは、たとえばＴＨＳＭ環境において考えたとおりに実施することができる。

図１４において示されているように、ステップ１は、さらなるサブステップ（これらは、特定の順序に限定されるものではない）を含むことができる。サブステップ１４００においては、ユーザ１４０２が、ユーザ名、および／またはパスワード、および／または、ＴＤ所有者／ユーザが以前に所有権（図示せず）を取得していた可能性があるＴＤ_ＤＯ／Ｕ１４０４へのユーザ個人データ（ＲＥＧＤＡＴＡ）の提出によってログインすることができる。サブステップ１４０６においては、ＴＤ_ＤＯ／Ｕ１４０４は、オンカードのＲＥＧＤＡＴＡをＴＤ_ＲＯ１１４０８へ送信することができる。サブステップ１４１０においては、ＴＤ_ＲＯ１１４０８は、ユーザデータを使用して、登録チケットをＰＯＳ（ｐｏｉｎｔ ｏｆ ｓａｌｅ）１４１２に要求することができる。ＰＯＳ１４１２は、チケットのインデックス付けされたセットをＲＯ１４１８に要求してＲＯ１４１８から受け取っていた可能性がある。それぞれのチケットは、ＩＭＳＩ値を含む非キー証明書（ｎｏｎ−ｋｅｙ ｃｒｅｄｅｎｔｉａｌ）を含むことができる。サブステップ１４１６においては、ＰＯＳ１４１２は、使用されていないチケットを選択すること、ならびに／またはそのチケットおよび／もしくはＲＥＧＤＡＴＡをＲＯ１４１８へ送信することが可能である。サブステップ１４１４においては、同じチケットをＴＤ_ＲＯ１１４０８へ送信することができる。ＰＯＳ１４１２は、チケットのインデックス付けされたセットを、ＲＯ１４１８にチケット分配サービスを提供する際に使用するためにＲＯ１４１８に要求すること、および／またはＲＯ１４１８から受け取ることが可能である。そのような１つのチケットをこのプロトコルにおいて使用することができる。オンカードエンティティ１４２０と、オフカードエンティティとの間における通信は、ＴＤＭ ＳＤ１４２２によって保護することができる。アプリケーションＴＤ_ＴＤＭ１４２３は、ＴＤＭ構成およびポリシー（たとえば、ＳＤＭおよびＳＤＰ）の情報を含むことができる。

図１４Ａにおいてさらに示されているように、ステップ２は、ＳＤへのダウンロードのための準備における２つのステップを含むことができ、そのＳＤは、ＴＤＭ ＳＳＤ１４２２によって今まさに作成されようとしているところである場合があり、およびＴＤ_ＲＯ１１４０８に関連付けられている場合があり、および／またはその証明書の所持者である場合がある。したがって、サブステップ１４２４においては、ＴＤ１４０８は、証明書のダウンロードを要求する際にチケットをＲＯ１４１８へ送信することができる。ＲＯ１４１８は、ＲＥＧＤＡＴＡを、ＰＯＳ１４１２から１４１６において送信されたチケットおよび／またはＲＥＧＤＡＴＡ情報にマップしておくことができる。サブステップ１４２６においては、ＲＯは、ＴＤＭ ＳＳＤ１４２２がＳＤを作成すること、および／またはＴＤ_ＲＯ１１４０８がそれに引き渡されることを要求することができる。作成されたＳＤは、ＴＤ_ＲＯ１１４０８のためのＴＳＩＭ証明書を含むことができ、そのＴＳＩＭ証明書は、ＴＤ_ＲＯ１１４０８に、そのセキュリティサービスの使用を提供することができる。

図１５は、一実施形態によるプロセスのステップ３において実行することができる登録および／または証明書ロールアウトを示している。ＴＤ_ＲＯ１１４０８に関連付けることができる作成されたＳＤ（ＲＯ１ ＳＳＤ１５００）を作成すること、インストールすること、選択可能にすること、および／またはパーソナライズすることが可能である。ＴＤ_ＲＯ１１４０８をＲＯ１ ＳＳＤ１５００に引き渡すことができ、それによって、そのセキュリティサービスを利用可能にすることができる。図１５の１５０２において示されているように、要求された証明書をＲＯ１ ＳＳＤ１５００へダウンロードすることができ、それによって、ＴＤ_ＲＯ１１４０８にＴＳＩＭ機能を提供することができる。可能な証明書は、認証キー、インテグリティキー、ＩＭＳＩを含むチケットなどを含むことができる。要求された証明書は、対称キーペアまたはＰＫＩを含むことができる。

一実施形態によれば、図１６は、証明書を発信元カード１６００から宛先カード１６０２へ移動させることによる修正された移行を示している。図１６においては、発信元カード（Ａ）１６００から宛先カード（Ｂ）１６０２への証明書の例示的な移行が提示されている。このプロセスについては、一連のステップ（特定の順序に限定されるものではない）を介して示し、それらのステップについては、両方のカード上で概説する。示されている方法は、発信元カード１６００と、宛先カード１６０２との間には直接のピアツーピア通信が存在することはできないという、ＧＰにおける例示的な状況を反映している。したがって、データの直接の転送を禁止することができる。証明書を発信元カード１６００上で削除してから宛先カード１６０２上にロードおよび／またはインストールすることは、転送を行うためのメカニズムであると言える。

ここで説明するのは、移行に関して考慮に入れることができる前提である。たとえば、リモート所有者ＡＰ１６０４は、一実施形態においては、両方のカードに関して同じである場合がある。したがって、１人の所有者から別の所有者へ秘密を転送することはできない。一実施形態によれば、宛先ＴＤ ＴＤ_ＲＯ１１６０８の所有権は、移行が開始する前に（たとえば、ＲＴＯを介して）ＲＯ１６０４によって取得することができる。一実施形態においては、ＴＤ_ＲＯ１１６０８を作成してＲＯ１ ＳＳＤ１６１０へ引き渡すことは、移行が開始する前に行っておくことができる。ＲＯ１ ＳＳＤ１６１０および／またはＴＤ_ＲＯ１１６０８の両方は、移行が開始するときにＳＥＬＥＣＴＡＢＬＥであることが可能である。カードＡのユーザ１６１０は、カードＢのユーザ１６１２とは異なる場合があり、これらのユーザは両方とも、移行に合意することができ、その後に移行を行うことができる。これらのユーザは、各自のデバイスにログインすること、および／または移行を要求することが可能であり、その後にプロトコルが実行されて、完了することができる。図示されていないが、複数のＴＤを、片方または両方のカード上でリモートから所有することができる。したがって、移行に含まれない可能性があるその他のＴＤ、たとえばリモートから所有されているＴＤなどが存在する場合がある。これに関連して、自分の証明書が転送されている最中であるＲＯは、移行の目的で宛先カード１６０２上のＴＤをリモートから所有するようになったと想定することができる。

一実施形態によれば、１６１４および１６１５において、両方の（または片方の）ユーザは、ＲＴＯおよび／または要求移行を通じて、自分が所有することができるＴＤ ＴＤ_ＤＯ／Ｕ（たとえば、ＴＤ_ＤＯ／Ｕ１６２８およびＴＤ_ＤＯ／Ｕ１６３０）にログインすることができる。例示的なログインは、どのＴＤ ＡＰＰを移行のためのターゲットとすることができるかを示す情報を含むことができる。たとえば、ＴＤ_ＲＯ１１６０８を、移行のためのターゲットとすることができる。

発信元カード１６００に関しては１６１６、１６１８、および／または１６２０において、宛先カード１６０２に関してはステップ１６１７、１６１９、および／または１６２１において、移行に関するさまざまなポリシーをチェックすることができる。たとえば、ＴＤ_ＤＯ／Ｕ１６２８は、ドメインマネージャＴＤ上でＴＤシステムポリシーチェックを実行することができる。単一の所有者を伴う一実施形態においては、ＡＰＰポリシーは、両方のカードに関して同じとすることができる。信頼できるドメインのシステムポリシー（ＳＤＰを含む）および／またはカードレベルポリシーは、２枚のカードを比較する際には、異なる場合がある。ポリシーレベルは、移行に対して従順であることが可能であり、それによって移行は、先に進むことを許可されることが可能である。

１６２２（宛先カード１６０２では１６２３）においては、ＣＩ ＳＤ１６３２（宛先カード１６０２ではＣＩ ＳＤ１６３４）が、ＲＯ１６０４へ移行するための許可を付与することができる。ＲＯ１６０４は、両方のカードからの許可を受信した後に、移行を進めないと決定することができる。ＲＯ１６０４は、ＯＰＥＮが発信元カード１６００上でＲＯ１ １６０７およびＴＤ_ＲＯ１１６０６を削除することをステップ１６２４において要求することができ、および／またはＯＰＥＮは、ステップ１６２６において削除オペレーションを実行することができる。

ＲＯ１６０４は、ステップ１６２５において宛先カード１６０２上に証明書をロードおよび／またはインストールすることを要求することができる。これらの証明書は、発信元カード１６００上に存在した証明書のコピーとすることができ、および／またはＲＯ１６０２によって知られていることが可能である。例示的な証明書は、認証キー、インテグリティキー、およびパーソナライゼーションデータを含む。インストレーションが行われる前に、証明書を含むロードファイル上でＤＡＰチェックを実行することができる。

一実施形態においては、ＧＰ動作環境は、アプリケーションの関連付けられているＳＤが、自分自身への引き渡しを行うこと（たとえば、自己関連付けされること）を許可されていない場合には、信頼できるドメインの機能（たとえば、インテグリティチェッキング、ＲＴＯ、登録および／もしくは証明書ロールアウト、ならびに／または移行など）のうちのいくつかを許可することができない。自己関連付けされるという特権は、これらのＴＨＳＭ／ＴＤ機能をＧＰカードアプリケーション上で実施することを可能にすることができる。ここでは、許可されるＴＳＩＭ動作に関するさらなる詳細を、さまざまなポーティングオプションに関連して提供する。

ここで説明するのは、ＣＩカードレベルセキュリティポリシーがＴＳＩＭ ＳＤＰに緊密に合致および／または適合することができる一実施形態（たとえば、上述のＳｃｅｎａｒｉｏ １）に従ってポートされるＴＤアプリケーション機能の査定である。たとえば、ＣＩおよびＲＯは同じであることが可能であり、したがって、彼らのポリシーどうしは適合することができる。例示的な一実施形態においては、ＣＩ ＳＤは、高いレベルの自律をＴＤＭ ＳＤに付与することができ、ＴＤＭ ＳＤは、信頼できるＳＤ階層の最上位に存在することができる。高いレベルの自律は、ＡＭＰが付与されていること、またはＤＭＰが付与されていることを意味する場合がある。Ｓｃｅｎａｒｉｏ １のもとでのポーティングインテグリティ信頼メカニズムに関しては、ロード時のＤＡＰを実行することができるが、ランタイムインテグリティを実行することはできない。一実施形態においては、ＲＴＯの信頼できるドメインの機能は、Ｓｃｅｎａｒｉｏ １のもとでは、ＳＤＰおよび／またはＲＯのポリシーの間におけるＴＤポリシー適合性チェックのもとでポートすることができる。たとえば、所有されることになる信頼できるドメイン内にインストールされるＳ／Ｗスイートは、実行可能ファイルを、ＲＯポリシーおよび／または目的ファイルも含む場合があるロードファイルから抽出するエクストラクタを含むことができ、このエクストラクタは、証明書がロードおよび／またはインストールされる際に使用することができる。Ｓｃｅｎａｒｉｏ １のもとでの一実施形態に従って、ユーザ登録およびリモート証明書ロールアウトを許可することもできる。たとえば、ポリシーは、ＲＴＯがユーザ登録およびリモート証明書ロールアウト機能を実行することを許可することができる。この機能の実行中に、ロールアウトのターゲットとすることができるＴＤ ＡＰＰのためにＳＤを作成することができる。ＴＤＭ ＳＤに最初に関連付けることができるＡＰＰを、新たに作成されたＳＤに引き渡すことができ、その新たなＳＤ内に証明書をインストールすることができ、その間に、実行可能ファイルをＴＤ ＡＰＰへと抽出することができる。一実施形態によれば、Ｓｃｅｎａｒｉｏ １のもとで、ＴＳＩＭアプリケーション移行機能をポートして修正することができる。ポリシー適合性チェックは、複数のエンティティ、たとえば、発信元および／もしくは宛先ＴＤＤ ＡＰＰ、発信元および／もしくは宛先ＳＤＰ、発信元および／もしくは宛先ＣＩ ＳＤポリシー、ならびに／または、２人のユーザが関与する場合にはユーザの好みなどを含むことができる。ＲＯを推進役として用いて、発信元証明書を削除してから宛先へコピーすることは、一実施形態においてＴＳＩＭアプリケーション移行のために使用されるメカニズムであると言える。

本明細書に記載されているように、ＣＩカードレベルセキュリティポリシーがＴＤ ＳＤＰに部分的にしか合致することができないＳｃｅｎａｒｉｏ ２のもとで、ＴＤ Ａｐｐｌｉｃａｔｉｏｎ機能をポートすることができる。Ｓｃｅｎａｒｉｏ ２によれば、ＧＰカード発行者は、ＳＤツリーの最上位にあるＴＤアプリケーションセキュリティドメインにＤＭＰ（ｄｅｌｅｇａｔｅｄ ｍａｎａｇｅｍｅｎｔ ｐｒｉｖｉｌｅｇｅ）を付与することができる。ＧＰカード発行者は、ＡＭＰを付与することはできない。このケースにおいては、ＴＤＭ ＳＤが自分自身への引き渡しを行うこと（および／または自己関連付けを行うこと）を可能にすることができる。したがって、ＴＤＭ ＳＤは、自分自身の構成管理システムに従って自分自身を構成することができる。実際に自己関連付けが行われた場合には、ＳＤは、ＡＭＰと同等のものを有することができる。しかし、一実施形態によれば、アプリケーションＳＤの引き渡しは、そのようなオペレーションのためのトークンをＣＩおよび／または制御権限者から受信せずに行うことはできない。構成および／または状態の変化は、カード上でのそのような変化を追跡把握する目的でのＣＩによるレシート生成を含むことができる。したがって、ＣＩは、ＡＭＰが付与されない場合に、ＴＤ ＡＰＰアクティビティを監督することができる。このオプションに関しては、自己関連付けが行われず、ひいては、ＴＤＭ ＳＤは、ＡＭＰに伴って有することになる自律と同じ自律を有することはできないと想定することができる。ドメインマネージャＴＤ ＡＰＰは、本明細書に記載されている特定の例示において採用されている自律を伴うリモートから所有されているＴＤを管理することはできない。

Ｓｃｅｎａｒｉｏ ２のもとで、信頼できるドメインの機能をポートすることができる。Ｓｃｅｎａｒｉｏ ２のもとでのインテグリティ信頼メカニズムに関しては、ロード時のＤＡＰを実行することができるが、ランタイムインテグリティチェッキングを実行することはできない。たとえば、ＣＩおよびＲＯは異なることが可能であり、および／または彼らのポリシーは、Ｓｃｅｎａｒｉｏ ２のもとでＲＯが信頼されている場合に何らかのレベルの適合性を有することができる。Ｓｃｅｎａｒｉｏ ２のもとでの一実施形態においては、ＳＤＰおよび／またはＲＯのポリシーの間における通常のＴＤポリシー適合性チェックのもとで、ＲＴＯ機能を許可することができる。例示的な一実施形態においては、ＣＩ ＳＤセキュリティポリシーは、Ｓｃｅｎａｒｉｏ １におけるよりも、Ｓｃｅｎａｒｉｏ ２のもとでの方が、ＴＲＯ手順を許可しない可能性が高くなる場合がある。所有されることになる信頼できるドメイン内にインストールされるＳ／Ｗスイートは、実行可能ファイルを、ＲＯポリシーおよび／または目的ファイルを含む場合があるロードファイルから抽出するエクストラクタを含むことができ、このエクストラクタは、証明書がロードおよび／またはインストールされる際に使用することができる。ＤＭＰがあれば、ＣＩは、トークン検証および／またはレシート生成特権を有することができる、ということを考えれば、ＣＩ ＳＤは、ローディングプロセスに対するさらに多くの制御を有することができる。一実施形態においては、Ｓｃｅｎａｒｉｏ ２のもとで、ユーザ登録および／またはリモート証明書ロールアウト機能が許可される。たとえば、ロールアウトのターゲットとすることができるＴＤ ＡＰＰのためにＳＤを作成することができる。ＴＤＭ ＳＤに最初に関連付けることができるＡＰＰを、新たに作成されたＳＤに引き渡すことができる。その作成されたＳＤ内に証明書をインストールすることができ、その間に、実行可能ファイルをＴＤ ＡＰＰへと抽出することができる。この抽出メカニズムによって、Ｓ／Ｗを導入する際のＧＰ制約を回避することができるが、Ｓｃｅｎａｒｉｏ ２では、Ｓ／Ｗが実行を開始した際にＡＰＰがＬＯＣＫＥＤになる可能性が高くなる場合がある。一実施形態によれば、Ｓｃｅｎａｒｉｏ ２のもとで、ＴＳＩＭアプリケーション移行機能をポートして修正することができる。たとえば、発信側には何の障害もないかもしれないが、宛先側にポリシーを阻むものが存在する可能性がある。ポリシー適合性チェックは、複数のエンティティ、たとえば、発信元および／もしくは宛先ＴＤＤ ＡＰＰ、発信元および／もしくは宛先ＳＤＰ、発信元および／もしくは宛先ＣＩ ＳＤポリシー、ならびに／または、２人のユーザが関与する場合にはユーザの好みなどを含むことができる。ＲＯを推進役として用いて、発信元証明書を削除してから宛先へコピーすることは、Ｓｃｅｎａｒｉｏ ２のもとでの一実施形態においてＴＳＩＭアプリケーション移行のために使用されるメカニズムであると言える。

本明細書に記載されているように、ＣＩカードレベルセキュリティポリシーがＴＤ ＳＤＰに最小限にしか合致しないＳｃｅｎａｒｉｏ ３のもとで、ＴＤ Ａｐｐｌｉｃａｔｉｏｎ機能をポートすることができる。Ｓｃｅｎａｒｉｏ ３においては、ＣＩおよび／もしくはＲＯは異なることが可能であり、ならびに／またはＲＯに関する信頼レベルは最も低くなる可能性があり、したがって、彼らのポリシーどうしは、最小限にしか適合することができない。Ｓｃｅｎａｒｉｏ ３によれば、ＧＰ ＣＩは、ＴＤ ＳＤにＤＭ特権を付与することはできない。このセキュリティメカニズムが機能している場合には、アプリケーションコンテンツは、ＣＩの監督を伴って取り扱うことができる。アプリケーションおよび／または構成ファイルがロードされる前に、ＣＩ ＳＤによってトークンを提供および／または検証することができる。ＣＩ ＳＤは、構成ファイルおよびアプリケーションのローディングおよび／またはインストレーションを実行することを担当するエンティティであると言える。アプリケーションプロバイダ、またはたとえばＲＯ ＡＰによって要求されるオペレーションは、ＣＩ ＳＤを経由することができる。これは、ここで説明されているさらに制限的なポーティングオプションのうちの１つであると言える。

Ｓｃｅｎａｒｉｏ ３のもとで、信頼できるドメインの機能をポートすることができる。たとえば、インテグリティ信頼メカニズムをポートすることができる。ロード時のＤＡＰを実行することができるが、ランタイムインテグリティチェッキングを実行することはできない。Ｓｃｅｎａｒｉｏ ３のもとでの一実施形態においては、ＳＤＰおよび／またはＲＯのポリシーの間における通常のＴＤポリシー適合性チェックのもとで、ＲＴＯを許可することができる。Ｓｃｅｎａｒｉｏ ３では、ＴＤ ＡＰＰ機能のうちの多くを減らすことができ、それによって、複数の機能を許可しないことが可能である。したがって、少なくとも１つのＴＤをリモートから所有することができる。所有されることになる信頼できるドメイン内にインストールされるＳ／Ｗスイートは、実行可能ファイルを、ＲＯポリシーおよび／または目的ファイルを含む場合があるロードファイルから抽出するエクストラクタを含むことができ、このエクストラクタは、証明書がロードおよび／またはインストールされる際に使用することができる。これらのファイルのローディングは、Ｓｃｅｎａｒｉｏ ３のもとでの一実施形態によれば、ＣＩ ＳＤの直接の担当とすることができる。シナリオ３のもとでの一実施形態においては、ユーザ登録およびリモート証明書ロールアウト信頼できるドメイン機能を許可することができるが、ＲＴＯを行うことができる頻度が低くなることを考えれば、それらの機能を行うことができる頻度は低くなり、ＲＴＯのために採用されるポリシーチェックは、この機能に関する許可を提供することができる。この機能の実行中に、ロールアウトのターゲットとされるＴＤ ＡＰＰのために新たなＳＤが作成される。ＴＤＭ ＳＤに最初に関連付けられるＡＰＰが、新たに作成されたＳＤに引き渡され、その新たなＳＤ内に証明書がインストールされ、その間に、実行可能ファイルがＴＤ ＡＰＰへと抽出される。この抽出メカニズムによって、新たなＳ／Ｗを導入する際のＧＰ制約を回避することができるが、Ｓｃｅｎａｒｉｏ ３では、Ｓｃｅｎａｒｉｏ ２と比較して、Ｓ／Ｗが実行を開始した際にＡＰＰがＬＯＣＫＥＤになる可能性が高くなる場合がある。一実施形態によれば、ＴＳＩＭ移行機能は、Ｓｃｅｎａｒｉｏ ３のもとで許可されるが、修正される。たとえば、（移行を行っているＲＯとは異なる）既存のＲＯが宛先に存在すると、ＴＳＩＭ移行プロセスを実行して完了させることが妨げられる場合がある。

一実施形態によれば、ＴＨＳＭ／ＴＤ機能は、信頼できる環境にとって決定的に重要となる場合がある信頼のいくつかの源（たとえばＲＴＲ、ＲＴＶ、ＲＴＳ、および／またはＲＴＭなど）に依存する場合がある信頼の要素を含むことができる。したがって、ＴＤ機能についての上述のポーティングの実施に関しては、特にＰＴＯに関しては、そのような信頼サポートメカニズムが欠如していると、カードのセキュリティ構造が弱くなる場合がある。たとえば、リモート所有者の観点から、カードのセキュリティ構造が弱くなる場合がある。信頼の確固たる源に基づいてカード構成のインテグリティを立証する能力は、ＲＯの重要なポリシー考慮事項であると言える。たとえＣＩがカードのコンテンツのインテグリティに自信があるとしても、ＲＯは、その同じレベルの自信または信頼を確信することはできない。このことは潜在的に、ＲＴＯを進めようかどうか決めている最中であるかもしれないＲＯにとって、抑制要因となる可能性がある。

一実施形態によれば、インテグリティチェッキングは、ＭＴＭ（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｍｏｄｕｌｅ）機能と整合する信頼メカニズムを採用している任意のデバイスによって使用することができる。したがって、ＴＨＳＭ／ＴＤは、信頼レベルを立証することに関しては、ＧＰ環境において設計されているとおりに機能することはできない。しかし、本明細書に記載されているように、ＣＩ ＳＤの指示および／または与えられているＡＭＰのもとで、ＴＤＭのＳＤが作成および／またはＰＥＲＳＯＮＡＬＩＺＥされると、セキュリティドメイン階層を確立することができる。ＳＤＰ内に書き込まれたＴＤシステムレベルポリシーが、カード上へロードされている最中であるＴＤファイルのＤＡＰチェッキングを実行する場合には、信頼レベルが弱くなるのを緩和することができる。その上、ＤＭＰ ＳＤは、ＡＭＰを付与されている場合にはトークン検証および／またはレシート生成を採用する必要はないかもしれないが、それでもなおそのようなメカニズムを採用すること、および／またはそれらのメカニズムを自分のポリシー要件の一部にすることが可能である。したがって、ＲＴＯおよび証明書ロールアウトファイルがこのように取り扱われ、ポリシーＳＤＰポリシー要件を通じてそのようなメカニズムが機能していることが保証されている状態では、ＲＯは、ＲＴＯおよび証明書ダウンロードを進める上でカード構成に対して十分なレベルの信頼を有することができる。たとえば、機能しているセキュリティ手順は、ＭＴＭ機能の代わりとしての役割を果たすことができる。

Ｓｃｅｎａｒｉｏ ２および／またはＳｃｅｎａｒｉｏ ３に関しては、ＣＩ ＳＤ内のカードマネージャポリシーへの依存が存在することができ、ＴＤＭ ＳＤの側での自律は少ない。ＣＩは、トークン検証特権および／またはレシート生成特権を有することができ、ひいては、ローディングプロセスについての直接の監督を有することができる。ＣＩ以外のリモート所有者に関しては、ポリシーの交渉をカードマネージャに向けることができる。これは、信頼の点でセキュリティが低くなることを意味しない場合がある。ＣＩは、さらにいっそう厳格なセキュリティ手順が課されることを要求することができる。信頼の問題とは別に、これは、結果として、リモートＴＤ所有者の数の上での制約につながる場合がある。

上記では特徴および要素について特定の組合せで説明しているが、それぞれの特徴または要素は、単独で、またはその他の特徴および要素との任意の組合せで使用することができるということを当業者なら理解するであろう。加えて、本明細書に記載されている方法は、コンピュータまたはプロセッサによって実行するためにコンピュータ可読メディア内に組み込まれているコンピュータプログラム、ソフトウェア、またはファームウェアで実装することができる。コンピュータ可読メディアの例としては、（有線接続またはワイヤレス接続を介して伝送される）電子信号、およびコンピュータ可読ストレージメディアが含まれる。コンピュータ可読ストレージメディアの例としては、読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび取り外し可能ディスクなどの磁気メディア、光磁気メディア、ならびにＣＤ−ＲＯＭディスクおよびデジタル多目的ディスク（ＤＶＤ）などの光メディアが含まれるが、それらには限定されない。ソフトウェアと関連付けられているプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおいて使用するための無線周波数トランシーバを実装するために使用することができる。

Claims (20)

1. １つまたは複数のデバイス上に存在している複数のドメインであって、少なくとも１つのプラットフォームによってサポートされており、それぞれのドメインは、前記少なくとも１つのプラットフォーム上で動作する、ある構成のコンピューティングリソースを含み、それぞれのドメインは、前記ドメインのローカルにまたは前記ドメインからリモートに位置されうる前記ドメインの所有者のための機能を実行するように構成されており、それぞれのドメインは、別々の所有者を有することができ、それぞれの所有者は、自分のドメインのオペレーションのための、ならびに、前記ドメインが存在している前記プラットフォームおよびその他のドメインに関連した自分のドメインのオペレーションのためのポリシーを指定することができる、複数のドメインと、
   前記複数のドメインのうちの１つであるセキュリティドメインであって、外部ステークホルダと、前記セキュリティドメインとの間における信頼のレベルを決定するように構成されている、セキュリティドメインと、
   前記複数のドメインのうちのもう１つの上に存在しているシステムワイドドメインマネージャであって、前記システムワイドドメインマネージャが存在している前記ドメインは、前記セキュリティドメインに対して補助的であり、前記システムワイドドメインマネージャは、前記セキュリティドメインから受信された特権レベルに基づいて前記複数のドメインのうちの１つまたは複数の補助ドメインの上で前記ポリシーを実施するように構成されており、前記特権レベルは、前記外部ステークホルダと、前記セキュリティドメインとの間における前記信頼のレベルに基づく、システムワイドドメインマネージャと
   を含むことを特徴とするシステム。
2. 前記外部ステークホルダは、前記１つまたは複数のデバイス上のアプリケーションのアプリケーションプロバイダであることを特徴とする請求項１に記載のシステム。
3. 前記セキュリティドメインは、カード発行者によって所有されているカード発行者セキュリティドメインであることを特徴とする請求項２に記載のシステム。
4. 前記外部ステークホルダは、前記１つまたは複数の補助ドメインのうちの少なくとも１つの所有者を含むことを特徴とする請求項１に記載のシステム。
5. 前記セキュリティドメインおよび前記システムワイドドメインマネージャは、グローバルプラットフォーム（ＧＰ）準拠カード上に存在していることを特徴とする請求項１に記載のシステム。
6. 前記複数のドメインは、グローバルプラットフォーム（ＧＰ）準拠カード上に存在しており、それぞれのドメインは、１つまたは複数のオフカードエンティティと通信するように構成されていることを特徴とする請求項１に記載のシステム。
7. 前記特権レベルは、委任管理特権（delegated management privilege）または承認管理特権（authorized management privilege）のうちの少なくとも１つを含むことを特徴とする請求項１に記載のシステム。
8. 前記委任管理特権および前記承認管理特権はそれぞれ、前記システムワイドドメインマネージャが、対応するレベルの自律を伴って前記ポリシーを実施することを可能にするように構成されていることを特徴とする請求項７に記載のシステム。
9. 前記承認管理特権に対応する前記自律のレベルは、前記委任管理特権に対応する前記自律のレベルよりも高いことを特徴とする請求項８に記載のシステム。
10. それぞれのドメインは、１つの状態に関連付けられており、それぞれの関連付けられている状態は、インストールされた状態、選択可能な状態、パーソナライズされた状態、またはロックされた状態のうちの１つであることを特徴とする請求項１に記載のシステム。
11. 前記システムワイドドメインマネージャの前記１つまたは複数の補助ドメインのうちの少なくとも１つの上にロードされる１つまたは複数のアプリケーションをさらに含み、前記１つまたは複数のアプリケーションはそれぞれ、１つの状態に関連付けられており、それぞれの関連付けられている状態は、インストールされた状態、選択可能な状態、パーソナライズされた状態、またはロックされた状態のうちの１つである
    ことを特徴とする請求項１に記載のシステム。
12. 前記１つまたは複数のアプリケーションのうちの１つは、制御権限者からの表示に従って前記関連付けられている状態を別の状態へ変更するように構成されており、前記別の状態および前記制御権限者からの前記表示は、前記特権レベルに基づいており、前記制御権限者は、前記セキュリティドメインまたは前記システムワイドドメインマネージャのうちの１つであることを特徴とする請求項１１に記載のシステム。
13. 前記セキュリティドメインのポリシーが、前記システムワイドドメインマネージャが存在している前記ドメインのポリシーと矛盾している場合には、前記システムワイドドメインマネージャは、前記セキュリティドメインの前記ポリシーを実施するようにさらに構成されていることを特徴とする請求項１に記載のシステム。
14. 前記システムワイドドメインマネージャは、
    前記システムワイドドメインマネージャが存在している前記ドメインのオペレーションのための前記ポリシーを実施すること、
    前記システムワイドドメインマネージャが存在している前記ドメインに関連して、前記補助ドメインどうしのそれぞれのポリシーの前記実施を調整すること、または
    前記補助ドメインどうしの間における対話を、前記補助ドメインどうしのそれぞれのポリシー、および前記システムワイドドメインマネージャが存在している前記ドメインの前記ポリシーに従って調整すること
    を行うようにさらに構成されていることを特徴とする請求項１に記載のシステム。
15. １つまたは複数のデバイス上に存在している複数のドメインを含むシステムであって、前記複数の前記ドメインは、少なくとも１つのプラットフォームによってサポートされており、それぞれのドメインは、前記少なくとも１つのプラットフォーム上で動作する、ある構成のコンピューティングリソースを含み、それぞれのドメインは、前記ドメインのローカルにまたは前記ドメインからリモートに位置されうる前記ドメインの所有者のための機能を実行するように構成されており、それぞれのドメインは、別々の所有者を有することができ、それぞれの所有者は、自分のドメインのオペレーションのための、ならびに、前記ドメインが存在している前記プラットフォームおよびその他のドメインに関連した自分のドメインのオペレーションのためのポリシーを指定することができる、システムにおいて、
    セキュリティドメインによって、外部ステークホルダと、前記セキュリティドメインとの間における信頼のレベルを決定するステップであって、前記セキュリティドメインは、前記複数のドメインのうちの１つである、ステップと、
    前記セキュリティドメインに対して補助的である、前記複数のドメインのうちのもう１つの上に存在しているシステムワイドドメインマネージャによって、前記セキュリティドメインから受信された特権レベルに基づいて前記複数の前記ドメインのうちの１つまたは複数の補助ドメインの上で前記ポリシーを実施するステップであって、前記特権レベルは、前記外部ステークホルダと、前記セキュリティドメインとの間における前記信頼のレベルに基づく、ステップと
    を含むことを特徴とする方法。
16. 前記システムワイドドメインマネージャによって、前記システムワイドドメインマネージャが存在している前記ドメインの前記ポリシーを実施するステップ、
    前記システムワイドドメインマネージャによって、前記システムワイドドメインマネージャが存在している前記ドメインに関連して、前記補助ドメインどうしのそれぞれのポリシーの前記実施を調整するステップ、または
    前記システムワイドドメインマネージャによって、前記補助ドメインどうしの間における対話を、前記補助ドメインどうしのそれぞれのポリシー、および前記システムワイドドメインマネージャが存在している前記ドメインの前記ポリシーに従って調整するステップ
    をさらに含むことを特徴とする請求項１５に記載の方法。
17. 前記セキュリティドメインのポリシーが、前記システムワイドドメインマネージャが存在している前記ドメインのポリシーと矛盾している場合に、前記システムワイドドメインマネージャによって、前記セキュリティドメインの前記ポリシーを実施するステップ
    をさらに含むことを特徴とする請求項１５に記載の方法。
18. 前記外部ステークホルダは、前記１つまたは複数のデバイス上のアプリケーションのアプリケーションプロバイダであることを特徴とする請求項１５に記載の方法。
19. 前記セキュリティドメインは、カード発行者によって所有されているカード発行者セキュリティドメインであることを特徴とする請求項１５に記載の方法。
20. １つまたは複数のデバイス上に存在している複数のドメインであって、少なくとも１つのプラットフォームによってサポートされており、それぞれのドメインは、前記少なくとも１つのプラットフォーム上で動作する、ある構成のコンピューティングリソースを含み、それぞれのドメインは、前記ドメインのローカルにまたは前記ドメインからリモートに位置されうる前記ドメインの所有者のための機能を実行するように構成されており、それぞれのドメインは、別々の所有者を有することができ、それぞれの所有者は、自分のドメインのオペレーションのための、ならびに、前記ドメインが存在している前記プラットフォームおよびその他のドメインに関連した自分のドメインのオペレーションのためのポリシーを指定することができる、複数のドメインと、
    前記複数のドメインのうちの１つであるグローバルプラットフォーム（ＧＰ）準拠カードのカード発行者セキュリティドメインであって、外部ステークホルダと、前記カード発行者セキュリティドメインとの間における信頼のレベルを決定するように構成されている、カード発行者セキュリティドメインと、
    前記複数のドメインのうちのもう１つの上に存在しているシステムワイドドメインマネージャであって、前記システムワイドドメインマネージャが存在している前記ドメインは、前記カード発行者セキュリティドメインに対して補助的であり、前記システムワイドドメインマネージャは、前記カード発行者セキュリティドメインから受信された特権レベルに基づいて前記複数のドメインのうちの１つまたは複数の補助ドメインの上で前記ポリシーを実施するように構成されており、前記特権レベルは、前記外部ステークホルダと、前記カード発行者セキュリティドメインとの間における前記信頼のレベルに基づく、システムワイドドメインマネージャと
    を含むことを特徴とするシステム。

Images