JP2013522705A

JP2013522705A - Ｔｈｓｍ間における認証情報および／またはドメインのマイグレーション

Info

Publication number: JP2013522705A
Application number: JP2012556209A
Authority: JP
Inventors: ジェイ．グッチョーネルイス; チャインヒョク; シュミットアンドレアス; レイチェルアンドレアス
Original assignee: インターデイジタルパテントホールディングスインコーポレイテッド
Priority date: 2010-03-02
Filing date: 2011-03-02
Publication date: 2013-06-13
Anticipated expiration: 2031-03-02
Also published as: CN103081432A; KR20120140249A; KR20140094008A; US20130212637A1; KR101580353B1; JP5750519B2; JP2014116953A; JP5457563B2; WO2011109518A1; EP2543207A1; EP2543207B1; US9032473B2; CN103081432B

Abstract

ユーザがドメイン間の認証情報のマイグレーションを開始することを可能にするシステム、方法、および手法が開示される。第１のドメインから第２のドメインへの認証情報のマイグレーションを開始する要求が、ユーザによって開始され得る（１ａ．）。リモートの所有者は、マイグレーションが要求されたことを示すメッセージを受信する。リモートの所有者によって受信されるメッセージは、移行元および移行先のデバイスが、内部検査を実行し、マイグレーションが続行し得ると判定したという指示である場合がある。リモートの所有者は、移行元のデバイスから受信された移行元情報と、移行先のデバイスから受信された移行先情報とを評価することができる（６）、（６ａ．）、（６ｂ．）。移行元情報および移行先情報の評価に基づいて、リモートの所有者は、マイグレーションが受け入れ可能であると判定する場合がある。リモートの所有者は、マイグレーションを続行する指示を送信することができる（７）、（７ａ．）。

Description

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

今日のモバイル通信産業において、ユーザが特定のネットワークオペレータのサービスに加入することができる無線デバイスは、主として、ＳＩＭ（Subscriber Identity Module）またはＵＩＣＣ（Universal Integrated Circuit Card）を含む。ＳＩＭ／ＵＩＣＣは、無線デバイスにセキュアな実行およびストレージ環境を提供する。当該ストレージ環境から認証アルゴリズムを実行し、認証情報（credential）を記憶する。当該認証情報は、デバイスがネットワークオペレータに対して、ネットワークオペレータへのデバイスのユーザの加入を認証することを可能にし、かつネットワークオペレータがデバイスに対する何らかの形式の制御、すなわち、所有権を有することを可能にする。残念なことに、このＳＩＭ／ＵＩＣＣメカニズムは、主として、単一のネットワークオペレータでの使用に限定される。

したがって、モバイル通信デバイスによる上記説明した状況のような今日の多くのコンピューティングコンテキストにおける問題は、コンピューティングデバイスが、単一のエンティティによって完全に「所有される（owned）」ことに限定されることである。また、多くの場合、その所有権が、ユーザによるデバイスの購入時に確定されなければならず、所有権を後で確定することが望ましい場合があるビジネスモデルを阻害する。さらに、これらの限定は、デバイスのいくつかの相互に隔離された部分の複数の所有権が存在すること、または所有権が随時その他のエンティティに移行されることが望ましい場合がある状況でのデバイスの使用を妨げる。例えば、モバイル電話などの無線モバイル通信デバイスの場合、通常、ユーザは、購入時に特定のモバイルネットワークのオペレータのサービスに加入することを求められ、そのようなデバイスは、モバイルネットワークのオペレータが無線デバイスの購入後ある程度時間が経ってからしか分からない場合がある用途で使用されることを防止されることが多い。また、そのようなデバイスが、一度に複数のオペレータのネットワークにアクセスすることは通常不可能である。モバイルネットワークおよびサービスの加入を更新または変更することは難しい場合があり、無線でそれを行うのは通常不可能である。

また、特に無線モバイル通信デバイスの状況においては、ＳＩＭ／ＵＩＣＣメカニズムは一般に非常に安全であると考えられるが、セキュリティは、そのＳＩＭ／ＵＩＣＣメカニズムが存在するデバイス全体のセキュリティのプロパティと強く結び付けられない。これは、モバイルでの金融取引などの高度なサービスおよび用途のためのセキュリティの概念のスケーリングの用途を制限する。特に、これらの欠点は、Ｍ２Ｍ（マシンツーマシン）通信デバイスなどの自律的なデバイスに関連する。

したがって、より動的なソリューションが望ましい。

国際公開第２００９／０９２１１５号

ユーザがドメイン間の認証情報のマイグレーション（migration）を開始することを可能にするシステム、方法、および手法が開示される。マイグレーションを、１またはそれ以上の別個のドメインを有する１またはそれ以上のデバイスを含むシステムで行うことができ、各ドメインは、１人または複数の異なるローカルのまたはリモートの所有者によって所有または制御され得る。１またはそれ以上のデバイスは、少なくとも１つのプラットフォームでサポートされる１またはそれ以上のドメインを備えてもよい。各プラットフォームは、ドメインのための下位層のコンピューティングリソース、ストレージリソース、または通信リソースを提供することができる。プラットフォームは、何らかのハードウェア、オペレーティングシステム、何らかの下位層のファームウェアまたはソフトウェア（ブートコード、ＢＩＯＳ、ＡＰＩ、ドライバ、ミドルウェア、もしくは仮想化ソフトウェアなど）、および何らかの上位層のファームウェアまたはソフトウェア（アプリケーションソフトウェアなど）、ならびにそのようなリソースに関するそれぞれの構成データからなってもよい。各ドメインは、少なくとも１つのプラットフォームで実行されるコンピューティングリソース、ストレージリソース、または通信リソースの構成を備えてもよく、各ドメインは、そのドメインのローカルにまたはリモートに位置しうるドメインの所有者のための機能を実行するように構成されてもよい。各ドメインは、異なる所有者を有してもよく、各所有者は、その所有者のドメインの運用に関する、ならびにそのドメインが存在するプラットフォームおよびその他のドメインに関連するその所有者のドメインの運用に関するポリシーを指定してもよい。加入に基づくサービスを提供するリモートの所有者は、リモート所有者ドメインと呼ばれることがあるドメインの所有権を取得してもよい。さらに、ユーザが、ユーザドメインと呼ばれることがあるドメインの所有権を取得してもよい。

第１のドメインから第２のドメインへの認証情報のマイグレーションを開始する要求が、開始され得る。例えば、移行元および移行先のデバイスのユーザが、移行元のデバイス上のリモート所有者ドメインに関連する認証情報が移行先のデバイス上のリモート所有者ドメインに転送されることを要求することができる。リモートの所有者は、マイグレーションが要求されたことを指示するメッセージを受信することができる。リモートの所有者により受信されるメッセージは、移行元および移行先のデバイスが、内部検査を実行し、マイグレーションが続行し得ると判定したという指示であってもよい。リモートの所有者により受信されるメッセージは、ユーザがマイグレーション要求を開始したという指示であってもよい。

リモートの所有者は、移行元のデバイスから受信された移行元情報と、移行先のデバイスから受信された移行先情報とを評価することができる。例えば、移行元情報は、移行元のポリシー、移行元の構成、移行元の識別情報、または移行元の完全性のインジケータのうちの少なくとも１つを含んでもよい。移行先情報は、移行先のポリシー、移行先の構成、移行先の識別情報、または移行先の完全性のインジケータのうちの少なくとも１つを含んでもよい。移行元情報および移行先情報の評価に基づいて、リモートの所有者は、マイグレーションが受け入れ可能であると判定することができる。例えば、リモートの所有者は、デバイスに関連するポリシーが、認証情報のマイグレーションと矛盾しないと判定してもよい。そのようなポリシーの評価は、移行元のドメインおよび移行先のドメイン以外のドメインのポリシーを含んでもよい。リモートの所有者は、マイグレーションを続行する指示を送ってもよい。

さらなる検査を、移行元および移行先のデバイスによって実行することができる。例えば、移行元のデバイスは、移行先のデバイスの状態を評価することができ、移行先のデバイスは、移行元のデバイスの状態を評価することができる。リモートの所有者は、マイグレーションが完了したこと、および移行元のデバイスが認証情報を破棄したことを指示する移行元完了メッセージを移行元のデバイスから受信することができる。リモートの所有者は、マイグレーションが完了し、認証情報が移行先のデバイスのドメインに複製されたことを指示する移行先完了メッセージを移行先のデバイスから受信することができる。

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

本明細書において説明される方法および手法が使用され得る例示的なシステムを表す図である。本明細書において説明される方法および手法がＵＥ（ユーザ機器）で具現化されるシステムの一実施形態を表す図である。例示的な起動、およびドメインの所有権を取得するためのプロセスを表す図である。例示的な起動、およびドメインの所有権を取得するためのプロセスを表す図である。ドメインの所有権を取得するプロセスに関する例示的なコールフロー（call flow）図である。ドメインの所有権を取得するプロセスに関する例示的なコールフロー図である。完全な証明（full attestation）をともなうドメインの所有権を取得するプロセスに関する例示的なコールフロー図である。完全な証明をともなうドメインの所有権を取得するプロセスに関する例示的なコールフロー図である。ＴＨＳＭの一実施形態の例示的な状態の定義、遷移、および制御点の定義である。リモート所有者ドメインが到達し得る例示的な状態、および動的に管理された環境内で遷移が発生し得る条件を表す図である。登録および認証情報のロールアウトプロセスを実装する例示的なコールフローを示す図である。認証情報のマイグレーションを実装する例示的なコールフローを表す図である。認証情報のマイグレーションを実装する例示的なコールフローを表す図である。認証情報のマイグレーションを実装する例示的なコールフローを表す図である。認証情報のマイグレーションを実装する例示的なコールフローを表す図である。認証情報のマイグレーションを実装する例示的なコールフローを表す図である。認証情報のマイグレーションを実装する例示的なコールフローを表す図である。１またはそれ以上の開示された実施形態が実装され得る例示的な通信システムのシステム図である。

図１乃至９は、開示されたシステム、方法、および手法が実装され得る例示的な実施形態に関連し得る。しかし、本発明が例示的な実施形態とともに説明され得るが、本発明はそれらの例示的な実施形態に限定されず、本発明の同様の機能を実行するために、本発明を逸脱することなくその他の実施形態が使用され得るか、または記載された実施形態に対して修正および追加が行われ得ることが理解されるべきである。さらに、図は、例示的であるように意図されるコールフローを表す場合がある。その他の実施形態が使用され得ることを理解されたい。さらに、フローの順序は、必要に応じて変更され得る。加えて、フローは不必要な場合は省略される場合があり、追加的なフローが追加される場合がある。

ユーザがドメイン間の認証情報をマイグレーションすることを可能にするシステム、方法、および手法が開示される。マイグレーションは、１またはそれ以上の別個のドメインを有する１またはそれ以上のデバイスを含むシステムで行われてもよく、各ドメインは、１人または複数の異なるローカルのまたはリモートの所有者によって所有または制御されてもよい。１またはそれ以上のデバイスは、少なくとも１つのプラットフォームでサポートされる１またはそれ以上のドメインを備えてもよい。各プラットフォームは、ドメインのための下位層のコンピューティングリソース、ストレージリソース、または通信リソースを提供してもよい。プラットフォームは、何らかのハードウェア、オペレーティングシステム、何らかの下位層のファームウェアまたはソフトウェア（ブートコード、ＢＩＯＳ、ＡＰＩ、ドライバ、ミドルウェア、もしくは仮想化ソフトウェアなど）、および何らかの上位層のファームウェアまたはソフトウェア（アプリケーションソフトウェアなど）、ならびにそのようなリソースに関するそれぞれの構成データからなってもよい。各ドメインは、少なくとも１つのプラットフォームで実行されるコンピューティングリソース、ストレージリソース、または通信リソースの構成を備えてもよく、各ドメインは、そのドメインのローカルにまたはリモートに位置しうるドメインの所有者のための機能を実行するように構成されてもよい。各ドメインは、異なる所有者を有する場合があり、各所有者は、その所有者のドメインの運用に関する、ならびにそのドメインが存在するプラットフォームおよびその他のドメインに関連するその所有者のドメインの運用に関するポリシーを指定してもよい。加入に基づくサービスを提供するリモートの所有者は、リモート所有者ドメインと呼ばれることがあるドメインの所有権を取得してもよい。さらに、ユーザが、ユーザドメインと呼ばれることがあるドメインの所有権を取得してもよい。

第１のドメインから第２のドメインへの認証情報のマイグレーションを開始する要求を開始することができる。例えば、移行元および移行先のデバイスのユーザが、移行元のデバイス上のリモート所有者ドメインに関連する認証情報を移行先のデバイス上のリモート所有者ドメインに転送することを要求することができる。リモートの所有者は、マイグレーションが要求されたことを指示するメッセージを受信することができる。リモートの所有者によって受信されるメッセージは、移行元および移行先のデバイスが、内部検査を実行し、マイグレーションが続行し得ると判定したという指示であってもよい。リモートの所有者が受信するメッセージは、ユーザがマイグレーション要求を開始したという指示であってもよい。

リモートの所有者は、移行元のデバイスから受信された移行元情報と、移行先のデバイスから受信された移行先情報とを評価することができる。例えば、移行元情報は、移行元のポリシー、移行元の構成、移行元の識別情報、または移行元の完全性のインジケータのうちの少なくとも１つを含んでもよい。移行先情報は、移行先のポリシー、移行先の構成、移行先の識別情報、または移行先の完全性のインジケータのうちの少なくとも１つを含んでもよい。移行元情報および移行先情報の評価に基づいて、リモートの所有者は、マイグレーションが受け入れ可能であると判定する場合がある。例えば、リモートの所有者は、デバイスに関連するポリシーが、認証情報のマイグレーションと矛盾しないと判定してもよい。そのようなポリシーの評価は、移行元のドメインおよび移行先のドメイン以外のドメインのポリシーを含んでもよい。システムレベルのポリシーは、移行元のポリシーと、移行先のポリシーと、移行元のデバイスおよび移行先のデバイス上のその他のドメインのポリシーとの間の衝突の可能性を判定してもよい。リモートの所有者は、マイグレーションを続行する指示を送ってもよい。

Ｉ．例示的なマルチドメインシステム
図１乃至７は、開示されたシステム、方法、および手法が実装され得る例示的な実施形態に関連する場合がある。しかし、本発明が例示的な実施形態に関連して説明される場合があるが、本発明はそれらの例示的な実施形態に限定されず、本発明の同様の機能を実行するために、本発明を逸脱することなくその他の実施形態が使用され得るか、または記載された実施形態に対して修正および追加が行われ得ることが理解されるべきである。

開示されたシステム、方法、および手法が実装され得る例示的なシステムは、１またはそれ以上のデバイスを備えてもよく、それらのデバイスのそれぞれは、少なくとも１つのプラットフォームによってサポートされる１またはそれ以上のドメインを備えてもよい。各プラットフォームは、ドメインのための下位層のコンピューティングリソース、ストレージリソース、または通信リソースを提供してもよい。プラットフォームは、何らかのハードウェア、オペレーティングシステム、およびその他の下位層のファームウェアまたはソフトウェア（ブートコード、ＢＩＯＳ、およびドライバなど）、ならびにそのようなリソースに関するそれぞれの構成データからなってもよい。各ドメインは、少なくとも１つのプラットフォームで実行されるコンピューティングリソース、ストレージリソース、または通信リソースの構成を備えてもよく、各ドメインは、そのドメインのローカルにまたはリモートに位置しうるドメインの所有者のための機能を実行するように構成されてもよい。各ドメインは、異なる所有者を有してもよく、各所有者は、その所有者のドメインの運用に関する、ならびにそのドメインが存在するプラットフォームおよびその他のドメインに関連するその所有者のドメインの運用に関するポリシーを指定してもよい。

各ドメインは（入力の観点から見た）、コンピューティングリソース、ストレージリソース、もしくは通信リソース、または（出力の観点から見た）そのようなコンピューティングリソース、ストレージリソース、もしくは通信リソースを用いることによってドメインが提供する機能に関して、その他のドメインから隔離され得る。各ドメインは、共通の基礎をなすプラットフォームのコンピューティングリソース、ストレージリソース、もしくは通信リソース、または機能を利用する場合がある。一部のドメインは、共通のプラットフォームによって提供されるそのような機能の一部を共有する場合がある。プラットフォームのリソースおよび／または機能のそのような共有は、各ドメインの共有のリソースまたは機能の使用が、別のドメインのそのような使用から隔離され得るようにして行われてもよい。例えば、そのような隔離は、ドメインのリソースに対するいかなるアクセスが、プラットフォームおよび／またはドメインの所有者によって認可されるユーザ、所有者、またはドメインの外部のその他のエンティティもしくはプロセスにのみ許可され得るように、デバイスのプラットフォームがそのプラットフォームがドメインのそれぞれに提供するリソースに対して厳格なアクセス制御を施行することによって実現されてもよい。プラットフォームは、ドメインの機能のいずれもが、デバイス上のドメインのいずれにも含まれないデバイスのリソースに依存する限りにおいて、単に、デバイス上の隔離されたドメインのいずれの一部でもないデバイスの部分からなる場合もある。

同じもしくは異なるプラットフォーム上の、または同じもしくは異なるデバイス上の任意の２つのドメイン間の通信が、安全になされることができ、つまり、ドメインは、（例えば、暗号化手段を用いて）安全に互いを認証することができ、また、機密性、完全性、およびフレッシュネス（freshness）などのセキュリティの観点に関してそれらのドメインの間で交換されるメッセージを保護することができる場合がある。ドメインが存在するプラットフォームによって提供される暗号化手段が、任意のそのような２つのドメイン間のそのような安全な通信を行うために使用される場合がある。

システム全体のドメインマネージャが、ドメインのうちの１つに存在してもよい。システム全体のドメインマネージャは、そのシステム全体のドメインマネージャが存在するドメインのポリシーを施行してもよく、その他のドメインのそれらのそれぞれのポリシーによる施行を、そのシステム全体のドメインマネージャが存在するドメインに関連して調整してもよい。加えて、システム全体のドメインマネージャは、その他のドメインの間の対話を、それらのその他のドメインのそれぞれのポリシーに従って調整してもよい。システム全体のドメインマネージャが存在するドメインは、そのドメインを収容するデバイスの所有者によって所有されてもよい。あるいは、そのようなドメインは、そのドメインを収容するデバイスを所有していない場合がある所有者によって所有されてもよい。

図１は、そのようなシステムの一実施形態を表す。示されるように、システムは、１またはそれ以上のデバイス１００、１１０、および１２０を含んでもよい。各デバイスは、少なくとも１つのプラットフォームでサポートされる１またはそれ以上のドメインを備えてもよい。例えば、デバイス１００は、ドメイン１０６、および１またはそれ以上のその他のドメイン１０１、１０２を備えてもよい。３つのドメインがデバイス１００に関して示されているが、その他の実施形態においては、ドメインの数は、より多いか、またはより少なくてもよい。それらのドメイン１０１、１０２、１０６のそれぞれは、デバイスの少なくとも１つのプラットフォーム１０５で実行されるコンピューティングリソース、ストレージリソース、または通信リソースの構成を備えてもよい。各ドメインは、そのドメインのローカルにまたはリモートに位置しうるドメインの所有者のための機能を実行するように構成されてもよい。例えば、ドメイン１０６は、デバイスの所有者（図示せず）によって所有される場合があり、一方、ドメイン１０１、１０２は、１人またはそれ以上のリモートの所有者によって所有されてもよい。各ドメインが、異なる所有者を有してもよく、またはデバイスの２つ以上のドメインが、同じ所有者によって所有されてもよい。各所有者は、その所有者のドメインの運用に関する、ならびにそのドメインが動作するプラットフォーム、そのドメインが存在するデバイス、および同じまたは異なるデバイス内のその他のドメインに関連するその所有者のドメインの運用に関するポリシーを指定してもよい。

述べられたように、システムはまた、その他のドメインが存在するその他のデバイスを含んでもよい。例えば、デバイス１１０は、ドメイン１１１および１１２を含んでもよく、それらのドメインのそれぞれは、同じリモートの所有者によって所有されてもよい。もちろん、ドメイン１１１および１１２の各々は、その代わりに、異なる所有者によってそれぞれが所有されてもよい。ドメイン１１１、１１２のそれぞれは、デバイス１１０のプラットフォーム１１５で実行されるコンピューティングリソース、ストレージリソース、または通信リソースの構成を備えてもよい。同様に、デバイス１２０は、ドメイン１２１および１２２を含んでもよい。この例に示されるように、それらのドメインのそれぞれは、異なる所有者によって所有されてもよい。あるいは、それらのドメインは、同じ所有者によって所有されてもよい。やはり、ドメイン１２１、１２２の各々は、デバイス１２０のプラットフォーム１２５で実行されるコンピューティングリソース、ストレージリソース、または通信リソースの構成を備えてもよい。

ＳＤＭ（システム全体のドメインマネージャ：system-wide domain manager）１０７が、ドメインのうちの１つに存在してもよい。この例において、ＳＤＭ１０７は、デバイス１００のドメイン１０６に存在する。一実施形態において、ＳＤＭが存在するドメイン（例えば、ドメイン１０６）は、デバイス１００の所有者によって所有される。ＳＤＭ１０７は、デバイス１００で提供される通信メカニズムを介してデバイス１００のリモート所有者ドメイン１０１と通信する。さらに、ＳＤＭ１０７は、有線または無線チャネルとなりうる各々の通信チャネル１３１、１３２、１４１、１４２を介してその他のデバイス上のドメインと通信する。通信チャネル１３１、１３２、１４１、および１４２は、安全であることができる。ＳＤＭ１０７は、そのＳＤＭ１０７が存在するドメイン１０６のポリシーを施行することができ、その他のドメイン１０１、１１１、１１２、１２１、１２２のそれらのそれぞれのポリシーによる施行を、ドメイン１０６に関連して調整することができる。加えて、ＳＤＭ１０７は、その他のドメインの間の対話を、それらのその他のドメインのそれぞれのポリシー、およびＳＤＭが存在するドメインのポリシー（その特定のドメインの所有者のポリシーである）に従って調整することができる。

例として、一実施形態において、ドメインは、サービスプロバイダによって所有されてもよい。例えば、デバイス１００のドメイン１０２は、単に例として、モバイルネットワークのオペレータなどのサービスプロバイダによって所有されてもよい。ドメイン１０２は、デバイス１００とサービスプロバイダの間の通信を可能にするために、ＳＩＭ（加入者識別モジュール）の機能を実行して、サービスプロバイダに対してデバイス１００を認証するか、または場合によっては同様な意味合いでデバイスの所有者またはユーザの加入を認証することができる。

上述のＳＤＭの機能に加えて、ＳＤＭ１０７は、情報にアクセスし、前記１またはそれ以上のドメインによって使用され得るリソースのリストを提供してもよい。ＳＤＭ１０７は、リモートの所有者によって所有されるドメインのロードおよびメンテノンスを管理することもできる。ＳＤＭ１０７は、そのＳＤＭ１０７が存在するデバイス１００のユーザに、そのＳＤＭ１０７がロードすることができるドメインのリストを提供することができ、リスト化されたドメインのうちのどれをロードすべきかをユーザが選択することを要求してもよい。ＳＤＭは、１またはそれ以上のドメインをロードするため、ひいてはそれらのドメインの運用をサポートするために十分なプラットフォームまたはデバイスのコンピューティングリソースが存在するかどうかを評価することもできる。

やはり上述されたように、ＳＤＭ１０７は、本明細書においてはＳＤＰ（システム全体のドメインポリシー：system-wide domain policy）と呼ばれる場合があるそのＳＤＭ１０７自身のポリシーと、その他のドメインのポリシー、すなわち、ＤＰ（ドメイン固有のポリシー）とを施行することに参加することができる。ＳＤＭ１０７は、新しいドメインをロードすべきかどうかを評価するときに、１またはそれ以上の既存のドメインのポリシーを考慮してもよい。例えば、リモートの所有者によって所有される所与のドメインのポリシーは、その所与のドメインが、特定の種類のその他のドメインがアクティブになるときに、非アクティブにされることを指定してもよい。別の例において、リモートの所有者によって所有される所与のドメインのポリシーは、その所与のドメインが、特定のその他のリモートの所有者によって所有される別のドメインがアクティブになるときに、非アクティブにされることを指定してもよい。さらに別の例において、リモートの所有者によって所有される所与のドメインのポリシーは、その所与のドメインの運用が、特定の種類のその他のドメインがアクティブになるときにある特定の方法で制限されることを指定してもよい。さらなる例において、リモートの所有者によって所有される所与のドメインのポリシーは、その所与のドメインの運用が、特定のその他のリモートの所有者によって所有される別のドメインがアクティブになるときに、ある特定の方法で制限されることを指定してもよい。ＳＤＭ１０７は、これらの種類のポリシーのすべての施行を担ってもよい。

ＳＤＭ１０７は、リモートの所有者が後で所有権を取得することができるドメインを確立またはロードすることもできる。例えば、そのようなドメインを、そのドメインがいかなるユーザにも所有されていない、本明細書においては「初期（pristine）」状態と呼ばれる状態で確立することができ、ＳＤＭ１０７は、リモートの所有者によるそのドメインの所有権の確立を管理することができる。

そのために、ＳＤＭ１０７は、リモートの所有者がドメインの所有権を確立するべきかどうかを判定する際に考慮しうる情報を、リモートの所有者に伝送することができる。この情報は、（ｉ）所有権が求められるドメインの完全性を証明する情報、および（ｉｉ）システムの少なくとも１つのその他のドメインの完全性を証明する情報のうちの少なくとも１つを含んでもよい。この情報は、（ｉ）所有権が求められるドメインがそのプラットフォームのリソースを用いて動作するプラットフォームの完全性を証明する情報、および（ｉｉ）システムの少なくとも１つのその他のドメインがそのプラットフォームのリソースを用いて動作するプラットフォームの完全性を証明する情報を含んでもよい。さらに、この情報は、デバイスの現在の環境に関する情報を含んでもよい。そのような情報は、（ｉ）システム内のその他のドメインの数を指示する値、（ｉｉ）システム内のその他のドメインの大まかな性質を示す情報、および（ｉｉｉ）所有権が確立されることが試みられているドメインによって使用可能なプラットフォームのリソースを指定する情報のうちの少なくとも１つを含んでもよい。システムのその他のドメインについてリモートの所有者に情報が提供される程度は、機密性および／または隔離に関するそれらのその他のドメインのそれぞれのポリシーに基づいて調整されてもよい。

リモートの所有者がドメインの所有権を取得した後、リモートの所有者は、ドメインに対してある程度の制御を実施することができる。例えば、リモートの所有者がドメインの所有権を確立した後、ドメインは、暗号鍵、構成情報、パラメータ、およびドメインの機能を高めるための実行コードのうちの少なくとも１つをリモートの所有者から受信することができる。別の例において、リモートの所有者がドメインの所有権を確立した後、ドメインは、そのドメインのドメイン固有のポリシーをリモートの所有者から受信することができる。

本明細書において開示されたシステムは、１またはそれ以上のドメインの隔離およびセキュリティを提供することもできる。例えば、ドメインのうちの１つまたはそれ以上が、その他のドメインから隔離されるセキュリティの実行およびストレージ環境を含んでもよい。そのような安全な環境を実現するために、図１のデバイス１００のプラットフォーム１０５などの、１またはそれ以上のドメインが確立されるデバイスのプラットフォームは、ルートオブトラスト（root of trust）１０３を備えてもよい。ルートオブトラスト１０３は、ハードウェアリソースの変更不可能かつ移動不可能な組を含むことができ、そのハードウェアリソースの組は、事前に確立され、ドメインのリモートの所有者を含む他者によって信頼され得る。ドメイン１０１などのドメインの完全性は、ルートオブトラスト１０３によって支えられたチェインオブトラスト（chain of trust）によって確立され得る。例えば、ドメイン１０１の完全性は、ルートオブトラスト１０３によって生成され得る、ドメイン１０１の少なくとも１つのコンポーネントの測定値を、ルートオブトラスト１０３に記憶され、ドメインの完全性を検証するためにルートオブトラストによって使用され得る基準の完全性の尺度と比較することによって確立されてもよい。あるいは、基準の完全性の尺度が、リモートの所有者によって記憶されてもよく、測定値が、基準の完全性の尺度との比較のためにリモートの所有者に伝送されてもよい。ドメインの完全性は、測定値が基準の完全性の尺度と一致する場合に確認されてもよい。１つの例示的な実施形態において、測定値は、コンポーネントに対して計算されたハッシュを含んでもよく、基準の完全性の尺度は、コンポーネントに対して前に計算されたハッシュを含み、基準の完全性の尺度が本物であることの指示を提供するデジタル証明書が付随してもよい。基準の完全性の尺度は、製造時に、またはデバイスをその所有者に引き渡すときにデバイスに事前にプロビジョニングされてもよい。基準の完全性の尺度は、デバイスの製造者／その所有者への供給の後で通信チャネルを介して（例えば、無線通信チャネルを介して）リモートのソースから届けられ、引き渡しの後でデバイスにプロビジョニングされてもよい。証明書に包含された基準の完全性の尺度が、デバイスに届けられることができる。そのような証明書は、その証明書のデバイスへの伝達の後で使用するために信頼できる第三者によって証明されてもよい。

本明細書において開示されたシステム、ならびのそのさまざまな方法および手法は、多種多様なコンピューティングおよび通信コンテキストで具現化されてもよい。したがって、図１の例示的なデバイス１００、１１０、および１２０などのシステムのデバイスは、さまざまな形態をとることができる。例として、いかなる限定もなしに、システムのデバイスは、ＷＴＲＵ（無線送受信ユニット）、ＵＥ（ユーザ機器）、移動局、固定もしくは移動加入者ユニット、ポケットベル、セルラ電話、ＰＤＡ（携帯情報端末）、Ｍ２Ｍ（マシンツーマシン）デバイス、ＳＩＭカード、ＵＩＣＣ（Universal Integrated Circuit Card）、スマートカード、位置追跡（geo-tracking）デバイス、センサーネットワークノード、計測デバイス（水道、ガス、もしくは電気メータなど）、または無線もしくは有線環境で動作することができる任意のその他の種類のコンピューティングもしくは通信デバイスを含んでもよい。以下の図および説明は、ＷＴＲＵにおける本開示のシステムおよび方法のいくつかのさらなる例示的な実施形態を提供する。しかし、これらの実施形態は例示的であるに過ぎず、本明細書において開示されたシステムおよび方法は、それらの実施形態に決して限定されないことが理解される。むしろ、上述のように、本明細書に記載のシステムおよび方法は、多種多様なコンピューティングおよび通信環境で使用されてもよい。

図２は、本明細書に記載のシステムおよび方法が具現化され得るＷＴＲＵの一実施形態を表す図である。示されるように、ＷＴＲＵは、ＵＥ２００などのモバイル機器を含んでもよい。ＵＥ２００は、ＭＥ（モバイル機器）２１０およびＴＨＳＭ（Trusted Hardware Subscription Module）２２０を含んでもよい。加えて、ＴＨＳＭ２２０は、ＴＨＳＭ−ＤＭ（デバイス製造者）ドメイン２２１、ＴＨＳＭ−ＤＯ（デバイス所有者）ドメイン２２２、ＴＨＳＭ−Ｕ（デバイスユーザ）ドメイン２２３、ＳＤＭ（システム全体のドメインマネージャ）２３０、ドメイン間ポリシーマネージャ２４０（Inter Domain Policy Manager）、ならびにＲＯ（リモートの所有者）のドメインＡ２２４、ＲＯのドメインＢ２２５、およびＲＯのドメインＣ２２６などの１またはそれ以上のＲＯドメインをさらに含んでもよい。さらに、ＵＥ２００は、次の図示されていないコンポーネント、すなわち、プロセッサ、受信機、送信機、およびアンテナを含んでもよい。本明細書に記載の例示的な実装は、図２に関連して説明されるコンポーネントなどのコンポーネントに関連する場合がある。

ＴＨＳＭは、ＳＩＭの機能、ＵＳＩＭの機能、ＩＳＩＭの機能、およびアクセスネットワーク加入によって通常実行される加入管理機能を含む信頼できる加入管理機能を提供するハードウェアに基づくモジュールである場合がある。ＴＨＳＭは、ハードウェアで保護されたモジュールである場合がある。ＴＨＳＭは、関連するセキュリティの特徴を用いて具体的に設計されるハードウェアを含んでもよい。ＴＨＳＭは、複数の隔離されたドメインを内部でサポートされてもよい。ドメインは、ＲＯ（リモートの所有者）と呼ばれる区別可能な所有者によって獲得または所有され得る。ＲＯによって獲得されたドメインは、それぞれのＲＯの代理として振舞うことがありうる。

ドメインのうちの１つまたはそれ以上は、ＴＳＩＭ（Trusted Subscription Identity Management）などの加入管理機能を実行することができる。ＴＳＩＭ機能を有する複数のドメインが単一のＴＨＳＭに存在する場合があるので、ＴＨＳＭは、複数のＲＯに関する加入管理をサポートすることができる。ＴＳＩＭが可能なドメインの管理の一部は、ＳＤＭ（システム全体のドメインマネージャ）と呼ばれる単一の管理機能によって実行されてもよい。その他の部分は、個々のドメイン内、および個々のドメイン上で個々に管理されてもよい。

ＵＭＴＳ（Universal Mobile Telecommunication System）に関して説明されるが、当業者は、本明細書に記載の方法および装置が、本出願の範囲を超えることなくその他の環境に適用可能であることを認めるであろう。ＴＳＩＭは、「加入アプリケーション（subscription application）」の代表例である場合がある。例えば、３Ｇ−ＵＭＴＳネットワーク内で動作するＷＴＲＵに実装される場合、ＴＳＩＭは、その機能の一部として、ＵＭＴＳ−ＡＫＡ（authentication and key agreement）機能を含む加入に関連する機能のすべてを含んでもよい。ＴＳＩＭは、ＵＩＣＣなどの特定のハードウェアに拘束されない場合がある。これは、ＵＩＣＣにしか存在し得ないＵＳＩＭと対照的である。そうではなく、ＴＳＩＭは、本明細書において説明されるＴＨＳＭに実装され得る。当業者は、本明細書において説明されるＴＨＳＭの機能が、ＥＴＳＩ（ヨーロッパ電気通信標準化協会）のＵＩＣＣの要件に準拠するＵＩＣＣなどのＵＩＣＣもしくは同様のスマートカード、またはグローバルプラットフォーム（Global Platform）の仕様に準拠するスマートカードに、本出願の範囲を超えることなしに組み込まれ得ることも認めるであろう。

ＷＴＲＵは、ＴＨＳＭおよびＭＥ（モバイル機器）を含んでもよい。ＭＥは、モデム、無線機、電源、およびＷＴＲＵで通常見られるさまざまなその他の特徴を含んでもよい。ＴＨＳＭは、別個のハードウェアに基づくモジュールを含んでもよい。ＴＨＳＭは、ＷＴＲＵに埋め込まれてもよいし、またはＴＨＳＭは、独立していてもよい。ＴＨＳＭは、たとえそれがＷＴＲＵに埋め込まれているとしても、ＭＥとは論理的に分かれてもよい。ＴＨＳＭは、それぞれがドメインの特定の所有者によって所有され、安全で信頼できるサービスおよびアプリケーションを提供する所有者の利益のために動作させられる１またはそれ以上のドメインを含んでもよい。したがって、例えば、ＤＭのドメインは、ＴＤＤＭと表記される場合があり、ＴＨＳＭにおけるＴＤＤＯドメインとしてのＤＯのドメインが、ＭＥで実行されるのに安全でないかまたは都合の悪くなりうるセキュリティ上の注意を要する機能およびアプリケーションを実行することができる。

一部のドメインは、１またはそれ以上のサービスプロバイダ（例えば、ＭＮＯ（モバイルネットワークのオペレータ）、ＷＬＡＮ（無線ローカルエリアネットワーク）のプロバイダもしくはＷｉＭａｘのプロバイダなどのその他の通信ネットワークのオペレータ、モバイル決済、モバイル発券、ＤＲＭ（デジタル著作権管理）、モバイルＴＶ、もしくは位置に基づくサービスのサービスプロバイダなどのアプリケーションサービスプロバイダ、またはＩＭＳ（IP Multimedia Core Network Subsystem）サービスプロバイダ）によって所有および管理されてもよい。加入管理は、サービスプロバイダによって所有されるドメインによってサポートされてもよい。簡単にするために、ＴＨＳＭのドメインで実装される加入管理機能は、以降、ＴＳＩＭ機能と表記される場合がある。ＴＳＩＭ機能のサポートは、ドメインによって変わる場合がある。例えば、サポートされるＴＳＩＭ機能は、モバイル端末のＵＩＣＣ上のＵＳＩＭおよびＩＳＩＭアプリケーションによって提供される機能と同様の機能を含む場合がある。ＴＨＳＭは、ＵＩＣＣと同様に、ＴＳＩＭによって提供されるもの以外の機能、アプリケーション、およびデータを含む場合がある。

ＴＳＩＭは、ソフトウェアユニットまたは仮想アプリケーションであってもよい。ＴＳＩＭは、初め、特定のネットワークのオペレータまたはＰＬＭＮ（公衆陸上移動体ネットワーク）に関連する認証情報を持たない場合がある。ＴＳＩＭは、ＵＭＴＳセルラアクセスネットワークに関する加入認証情報／アプリケーションの管理に関連する場合がある。例えば、ＴＳＩＭは、ＵＭＴＳの認証鍵などの強いＫｉ（strong secret）の管理を含んでもよい。Ｍ２Ｍの場合、ＴＳＩＭは、ＭＣＩＭ（M2M Connectivity Identity Management）を含んでもよい。

ＴＨＳＭは、ＴＰＭ（trusted platform module）またはＭＴＭ（mobile trusted module）を有するコンピューティングデバイスに見られる場合があるＲＴＭ（root of trust of measurement）と同様のＣＲＴＭ（Core Root of Trust (RoT) of Measurement）ユニットを含んでもよい。ＴＨＳＭのＣＲＴＭは、例えば、ＴＨＳＭのブート時にＴＨＳＭのブートコードの完全性を測定することができる。完全性の尺度は、Ｅｘｔｅｎｄ操作を通じて、例えば、ＴＨＳＭのブートコード、ＢＩＯＳ、および随意にバージョン番号、ソフトウェアの構成、またはリリース番号などのＴＨＳＭの製造者の特徴に対して暗号学的ダイジェスト値操作を適用することによって計算されてもよい。例えば、完全性の尺度は、ＳＨＡ−Ｘなどの暗号学的ハッシュアルゴリズムのバージョンを用いて計算されてもよい。

ＴＨＳＭは、保護されたストレージに完全性の尺度を記憶するように構成された、ＴＰＭまたはＭＴＭに見られるＲＴＳ（root of trust for storage）と同様のＣＲＴＳ（core RoT of Storage）ユニットを含んでもよい。ＴＨＳＭは、ＴＨＳＭの完全性の測定値を外部の問い合わせ元に報告するように構成された、ＴＰＭまたはＭＴＭに見られるＲＴＲ（root of trust for reporting）と同様のＣＲＴＲ（Core RoT of Reporting）を含んでもよい。

したがって、ＴＨＳＭは、信頼の測定、記憶、および報告の観点でＴＰＭまたはＭＴＭの能力と同様の能力を効果的に提供することができる。ＴＨＳＭは、複数の信頼できるステークホルダのエンジンを実現する能力も含んでもよい。さらに、ＴＨＳＭは、各々の複数のステークホルダの信頼できるサブシステムを実現するように構成されてもよい。したがって、ＴＨＳＭは、ＴＣＧ−ＭＰＷＧ（Mobile Phone Working Group）の仕様によって定義された信頼できるモバイル電話と同様であることができる。

ＴＨＳＭは、例えば、本明細書において説明されるコアＲｏＴ（Core RoT）能力を用いて、複数の内部の「ステークホルダドメイン（stake-holder domain）」をビルドするように構成され得る。ステークホルダは、ＴＨＳＭのＤＭ（デバイスの製造者）、ＴＨＳＭのＤＯ（デバイスの所有者）、またはＴＨＳＭのＤＵ（デバイスのユーザ）であってもよい。ＤＵは、ＤＯと同じである場合があるか、またはＤＯとは異なる場合がある。ＴＨＳＭごとに２人以上のＤＵが存在してもよい。ステークホルダは、ＤＯによって明確に借りられるかまたは所有されるドメインの異なるＲＯ（リモートの所有者）であってもよい。例えば、ＭＮＯなどの３ＧＰＰ（第３世代パートナーシッププロジェクト）のＰＬＭＮのオペレータ、ＩＭＳサービスプロバイダ、非３ＧＰＰアクセスネットワークのオペレータ、または付加価値のあるアプリケーションサービスプロバイダが、ステークホルダであってもよい。

一部のドメインは、必須である場合があり、その場合、それらのドメインは、ＴＨＳＭの製造時に事前に構成される場合がある。例えば、ＤＭのドメインは必須である場合があり、事前に構成されたファイルに従ってブート時にビルドまたはロードされ得る。ＤＯのドメインも必須である場合があり、事前にプロビジョニングされた構成にビルドされ得る。あるいは、そのドメインは、ダウンロードされる構成ファイルに従ってビルドされ得る。

ＤＭのドメイン以外のドメインは、それらのドメインがドメインの所有者によって「獲得（claimed）」および「所有（owned）」される前に、ＲＴＯ（Remote Take-Ownership）プロセスにかけられる場合がある。特定のドメインがＲＴＯプロセスを経る前は、不特定の所有者のための「初期」ドメインが存在する場合がある。この場合、当該ドメインに関して獲得されたいかなる特定の所有権も存在しない。

ＴＨＳＭ上のドメインは、ＴＨＳＭ−ＭＥインターフェースを介してＭＥと情報を通信および交換することができる。例えば、ドメインは、起動またはＲＴＯプロセス中にＭＥと通信する場合がある。ＴＨＳＭ−ＭＥインターフェースを介して交換されるデータの保護が、必要とされる場合がある。

ＴＨＳＭ−ＭＥインターフェースにわたったすべての通信の完全性の保護が、必要とされる場合がある。例えば、完全性の保護は、事前にプロビジョニングされた一時的な鍵、または認証された鍵交換メカニズムを用いることによって交換される鍵などの暗号鍵を使用することができる。暗号鍵は、Ｋｔｅｍｐ＿Ｉのように対称的であるか、または完全性のためにＴＨＳＭによって使用される公開鍵もしくは秘密鍵のためのＫｐｕｂ／ｐｒｉｖ＿ＴＨＳＭ＿ｔｅｍｐ＿Ｉ、および完全性のためにＭＥによって使用される公開鍵もしくは秘密鍵のためのＫｐｕｂ／ｐｒｉｖ＿ＭＥ＿ｔｅｍｐ＿Ｉのように非対称的である場合がある。一時的な鍵は、インターフェースの保護のために使用され得る。例えば、一時的な鍵は、有効期間に関連付けられ得るか、または一度もしくは所定の回数だけ使用されてもよい。

ＴＨＳＭ−ＭＥインターフェースにわたった通信の機密性が、暗号化手段を用いてやはり提供される場合がある。事前にプロビジョニングされた一時的な鍵、または認証された鍵交換メカニズムを用いることによって交換される鍵が、使用され得る。暗号鍵は、暗号化のためのＫｔｅｍｐ＿Ｃのように対称的であるか、または暗号化のためにＴＨＳＭによって使用される公開鍵もしくは秘密鍵のためのＫｐｕｂ／ｐｒｉｖ＿ＴＨＳＭ＿ｔｅｍｐ＿Ｃ、および暗号化のためにＭＥによって使用される公開鍵もしくは秘密鍵のためのＫｐｕｂ／ｐｒｉｖ＿ＭＥ＿ｔｅｍｐ＿Ｃのように非対称的である場合がある。本明細書に記載のＲＴＯの方法および装置は、簡単にするために、事前にプロビジョニングされた対称的な一時的鍵の使用に関連する。しかし、当業者は、その他の鍵の実装が、本出願の範囲を超えることなしに使用され得ることを認めるであろう。

ＴＨＳＭ−ＭＥとＲＯの間とで平文で渡されるメッセージに対するリプレーアタックに対する防護策が、提供される場合がある。ＴＨＳＭ−ＭＥインターフェース上で送信される各メッセージは、ノンスの使用による新鮮さの質を有する場合がある。簡単にするために、本明細書において説明されるＲＴＯプロトコルは、ＭＥ−ＴＨＳＭインターフェースを介して交換されているすべてのメッセージのリプレーに対抗する保護を含み得るが、当業者は、その他のインターフェースの保護構成が、本出願の範囲を超えることなしに使用され得ることを認めるであろう。

署名が、ハッシュに適用されてもよい。例えば、ハッシュは、ＳＨＡ−Ｘアルゴリズムによって生成されてもよい。信頼できる第三者が、Ｃｅｒｔ_TSIM（証明書）を用いて、ＴＨＳＭに関連するＫ_TSIM-PrivおよびＫ_TSIM-Pubなどの秘密−公開鍵の対を証明することができる。信頼できる第三者は、Ｃｅｒｔ_RO（証明書）を用いて、ネットワークに関連するＫ_RO-PrivおよびＫ_RO-Pubなどの鍵の別の組を証明することもできる。これらの証明書は、問題のドメインに割り当てられた保護されたストレージに記憶されてもよい。

公開鍵、Ｋ_RO-Pubは、ＴＨＳＭプラットフォーム、具体的には、ＴＳＩＭによって、ＲＯからの署名を検証するために、またはＲＯに送信されるメッセージを暗号化するために使用されてもよい。秘密鍵、Ｋ_RO-Privは、署名の目的で、または対応する公開鍵を用いてＴＳＩＭによって暗号化されたメッセージを復号するためにネットワークによって使用されてもよい。公開−秘密鍵の対、Ｋ_TSIM-PubおよびＫ_TSIM-Privは、ＴＳＩＭとＲＯの役割が入れ替えられることを除いて同様の機能を含んでもよい。あるいは、ＲＯとＴＳＩＭの両方において、暗号化および署名のために別個の鍵の対が存在してもよい。

鍵の対Ｋ_RO-PrivおよびＫ_RO-Pub、ならびにＫ_TSIM-PrivおよびＫ_TSIM-Pubは、所有者、ユーザ、またはそれら両方によって選択された特定のネットワークサービスに依存する場合がある。ＲＯなどの各サービスプロバイダは、そのプロバイダに関連するＴＨＳＭ上の各ドメインに関するそのサービスプロバイダ独自の証明された公開−秘密鍵の対を有する場合がある。選択されたサービスは、鍵の対のどの組が使用されるかを判定することができる。例えば、公開秘密鍵の対の組は、選択されたサービスプロバイダおよびＴＨＳＭ上の関連するドメインによって判定されてもよい。使用される鍵の対のいかなるネゴシエーションも存在しない場合がある。公開または秘密鍵の対は、サービスプロバイダによって判定されてもよく、ＴＨＳＭのサブシステムまたはドメインに厳密に関連付けられてもよい。

ＴＨＳＭのＴＤ_DOが、ＳＤＭ（「システム全体のドメインマネージャ」）を構成してもよい。ＳＤＭは、ＳＤＰ（「システム全体のドメインポリシー」）を含む事前に構成されたファイルを保護するように記憶することができる。ＳＤＭは、ＳＤＰに準じてＴＨＳＭに関するＲＯのドメインをビルドまたはロードすることができる。ＳＤＭは、ＤＯのドメインの初期構成に含まれてもよい。ＳＤＭは、事前に構成されたＳＤＰを用いて、その他のどのドメインがどのような順序でビルドされるべきかを判定してもよい。

ＳＤＭは、ＲＯドメインに代わって、ＲＯドメインによって要求されたときに、ＴＰＥＳ（ＴＨＳＭプラットフォーム環境サマリ：THSM Platform Environment Summary）およびＴＰＩＡ（ＴＨＳＭプラットフォーム完全性証明：THSM Platform Integrity Attestation）を準備し、供給することができる。ＴＰＥＳは、ＴＨＳＭの直近の「環境（environment）」についての概略情報を記述することができる。そのような情報は、ドメインの数と、ＴＨＳＭ上の機密性および隔離、ならびに要求元のドメインと通信するため、および要求元のドメインと機能またはリソースを共有するために利用可能でありうる、ＴＨＳＭ上の任意の残りのリソースに関して、それぞれのドメインポリシーによって調整されるか、または許可されるドメインの大まかな性質とを含んでもよい。ＴＰＩＡは、ＴＨＳＭのドメインのうちの１またはそれ以上の完全性証明（Integrity Attestation）の集合を含んでもよい。ＴＰＩＡは、前記ドメインをサポートするプラットフォームに関する完全性証明を含んでもよい。ＴＰＩＡは、ＴＨＳＭ上の初期ドメインに対してＲＴＯプロセスを実行することに関心のあるＲＯなどの外部のベリファイア（verifier）に、対象のドメインおよびそれらのドメインをサポートするプラットフォームの信頼の状態を証明するために使用されてもよい。ＲＯまたはＴＤ_RO（ＲＯのドメイン）は、ＳＤＭにＴＰＩＡを要求してもよい。ＳＤＭは、ＳＤＰに準じて要求を受け入れるかまたは拒否してもよい。

ＳＤＭは、ＴＨＳＭのサービス担当者などの物理的に存在するデバイスの所有者と対話して、ビルドされるべきであるその他のドメイン、およびどのような順序でその他のドメインがビルドされるべきかをインタラクティブに特定してもよい。さらに、ＳＤＭは、ユーザのドメインに、ＴＨＳＭの物理的に存在するユーザと対話して、ビルドされるべきドメインおよびビルドの順序に関する入力を提供するように要求してもよい。この情報は、ドメインのビルドプロセスの入力として使用されてもよい。

ＴＨＳＭは、ＲＯのドメインに関するＲＴＯプロセスを実行するとき、リモート所有権取得プロトコルの完了前に、４つの異なるシステム状態に達するように構成されてもよい。ＴＨＳＭ−Ｐｒｅ＿Ｂｏｏｔシステム状態は、ＴＨＳＭが「電源オン（powered-on）」にされていないことを指示することができる。ＴＨＳＭ＿ＴＤ_DM＿ＬＯＡＤ＿ＣＯＭＰＬＥＴＥシステム状態は、ＴＨＳＭ上のＤＭのドメインが、ＴＨＳＭの電源オンの後の第１のステップとしてビルドまたはロードされたことを指示することができる。ＴＨＳＭ＿ＴＤ_DO＿ＬＯＡＤ＿ＣＯＭＰＬＥＴＥシステム状態は、ＴＤ_DO（ＤＯのドメイン）が利用可能な最後の構成にビルドまたはロードされたことを指示する場合がある。この「利用可能な最後の構成（last configuration available）」は、ＤＯのドメインがそれ自体に対するＲＴＯプロセスを経ていない場合には「初期」構成であってもよく、または「ＲＴＯ後の（post-RTO）」構成であってもよい。ＤＭのドメインが、ＤＯのドメインをビルドまたはロードすることができる。ＤＯのドメインが少なくとも１つのＲＴＯプロセスを経る前は、ＤＯのドメインは、「初期」状態である場合があり、いかなる特定のＤＯによっても獲得または所有されていない場合がある。「初期」ドメインは、「シェル（shell）」を含んでもよい。初めてＤＯのドメインがビルドまたはロードされるとき、「利用可能な最後の構成」（以降、「最後の構成（Last-Configuration）」と呼ばれる）は、事前に構成されたファイルから来る。あるいは、「最後の構成」がＲＯのドメインに対するＲＴＯプロセスによるものである場合、ＴＨＳＭ上のその特定のドメインが、リモート所有権取得プロトコルを少なくとも一回経てもよく、リモートの所有者が、ＴＤ_ROの所有権を取得してもよい。これは、リモート所有権取得の完了時に、プラットフォーム上に構成された信頼できるサブシステムを指示することができる。この状態が到達されるとき、またはこの状態が到達される前、その特定のＲＯは、その他のタスクの実行を開始することができる。

ＴＨＳＭ＿ＴＤ_RO＿ＬＯＡＤ＿ＣＯＭＰＬＥＴＥシステム状態は、ＴＤ_RO（ＲＯのドメイン）が利用可能な最後の構成にビルドまたはロードされたことを指示する場合がある。この「利用可能な最後の構成」は、ＲＯのドメインがそれ自体に対するＲＴＯプロセスを経ていない場合には、「初期」構成であってもよく、または「ＲＴＯ後の」構成であってもよい。ＤＭのドメインが、ＲＯのドメインをビルドまたはロードすることができる。ＤＯのドメインが少なくとも１つのＲＴＯプロセスを経る前は、ＤＯのドメインは、「初期」状態であってもよく、いかなる特定のＤＯによっても獲得または所有されていなくてもよい。「初期」ドメインは、「シェル」を含んでもよい。初めてＲＯのＴＤがビルドまたはロードされるとき、最後の構成は、事前に構成されたファイルから来てもよい。

あるいは、「最後の構成」がＲＯのＴＤに対するＲＴＯプロセスによるものである場合、ＴＨＳＭ上のその特定のＴＤが、ＲＴＯプロトコルを少なくとも一回経てもよく、ＲＯが、ＴＤ_ROの所有権を取得してもよい。これは、ＲＴＯの完了時に、プラットフォーム上に構成された信頼できるサブシステムを指示する。この状態が到達されるときまでに、その特定のＲＯは、その他のタスクの実行を開始することができる。ＴＤ_RO（ＲＯのＴＤ）がＭＮＯのＴＤである場合、この段階までに、ＭＮＯのＴＤは、そのＴＤ_RO上に実現された最終的なＴＳＩＭ（Trusted Subscription Identity Management）機能を提供することができる。

あるいは、ＳＤＭ（システム全体のドメインマネージャ）が、ＤＯのＴＤではなくＤＭのＴＤに実装されてもよい。ＤＯは、適切な認可データをＤＭのＴＤに提供した後、ＤＭのＴＤによって提供されるＳＤＭを用いて、ＴＨＳＭ上のさまざまなリモート所有者ＴＤを作成し、ロードし、その他の管理を行うタスクを実行することができる。この場合のＴＨＳＭのシステムのブートシーケンスおよびＲＴＯプロセスのシーケンスの詳細は、本明細書に記載のシーケンスとは異なる場合があるが、本出願の範囲内である。この場合の起動およびＲＴＯプロセス、ならびにＤＯまたはＤＯのＴＤがＤＭのＴＤによって提供されたＳＤＭをどのように使用することができるか、例えば、どのような種類の認可データが提供され得るか（およびその認可データがどのように提供され得るか）の説明は、本明細書に記載のものと同様である場合がある。例えば、スマートカードとして具現化されるＴＨＳＭが、カード発行者の代わりにカード上のセキュリティドメインを管理することを担う、グローバルプラットフォームなどの規格によって仕様が決められたカードマネージャ機能をサポートする機能を有するカードマネージャを含んでもよい。カード発行者は、ＤＭと同様であってもよく、カードマネージャは、ＳＤＭの機能の一部を含んでもよい。したがって、カードマネージャは、ＤＭのドメインに保持されるＳＤＭと同様である場合がある。

第１の実施形態において、ＭＥは、セキュアブート能力を提供するように構成されてもよく、ＴＨＳＭは、完全なＭＴＭの能力を提供するように構成されてもよい。電源オン時に、ＭＥは、安全にブートすることができる。例えば、ＭＥは、ＯＭＴＰ（open mobile terminal platform）の信頼できる実行環境ＴＲ０の仕様などに従って非ＴＣＧの「セキュア（secure）」」ブートを実行することができる。ブート時に、ＴＨＳＭは、例えば起動することによってＴＨＳＭのＴＤ_DM（ＤＭのドメイン）を最初にビルドし、次いで、「初期の」ＴＨＳＭのＴＤ_DO（ＤＯのドメイン）をビルドすることができる。ＤＯとＤＵが別である場合、ＴＨＳＭは、ＴＨＳＭのＤＵのドメインもビルドすることができる。

ＴＨＳＭのＴＤ_DMは、ＴＨＳＭにおいて保護され、ブート時に利用可能にされる事前に構成されたファイルを用いて最初にビルドされてもよい。ＴＨＳＭのＴＤ_DOは、おおむね、事前に構成されたファイルを用いてビルドされ得るが、ＲＴＯプロセスを用いてビルドされることもある。ＴＨＳＭのＴＤ_DOは、ＲＴＯプロトコルを経る場合がある。このプロトコルは、ＴＤ_RO（ＲＯのドメイン）に関するＲＴＯプロトコルと同じ形態をとってもよいし、またはこのプロトコルは、異なるプロトコルであってもよい。ＴＨＳＭのＴＤ_DOがＲＴＯプロトコルを経ない場合、所有権を取得するために必要とされる認証情報は、事前に構成され、事前にプロビジョニングされる。ＴＨＳＭのＴＥＤＯは、ＤＯによって所有されてもよい。ＤＯは、実際の人間のユーザもしくは所有者、会社もしくはその会社のＩＴ（情報技術）部門などの組織、またはリモートのＮＯ（ネットワークオペレータ）であってもよい。

ＴＨＳＭのＴＤ_Uは、ＴＨＳＭのＴＥ_DOに事前にプロビジョニングされた事前に構成されたファイルを用いてビルドされてもよい。ＴＨＳＭのＲＯドメインは、ＴＨＳＭのＤＯのＳＤＰ（システム全体のドメインポリシー）に準じて「初期」構成に最初にビルドされてもよい。ＴＨＳＭのＲＯドメインは、ＲＯとのＲＴＯプロセスを経る場合がある。ＤＯのドメインのＳＤＭは、ＳＤＰに準じて、ＲＯのドメインに対するＲＴＯプロセスを管理することができる。ＴＨＳＭのＲＯがＭＮＯであり、したがって、ＲＯのドメインがＭＮＯのドメインである場合、そのようなＭＮＯのドメインは、ｉ）ＭＮＯのドメインがＭＮＯにどのように登録され得るか、ｉｉ）加入認証情報（例えば、ＵＳＩＭまたはＭＣＩＭの秘密鍵ＫｉおよびＩＭＳＩ（国際移動体加入者識別番号）など）が、ＭＮＯのモバイルネットワークからＴＨＳＭ上のＭＮＯのドメインにどのように複製され、次いでそこにプロビジョニングされ得るか、ならびにｉｉｉ）加入認証情報をダウンロードしたときに、そのような認証情報を処理もしくは使用する機能、またはさらには加入管理機能を提供するドメインが、デバイス間でどのようにマイグレーションされ得るかを定義するプロトコルをやはり経てもよい。そのようなプロトコルは、それぞれ、ｉ）登録プロトコル、ｉｉ）認証情報ロールオフプロトコル、およびiii）マイグレーションプロトコルと呼ばれる場合がある。ＴＨＳＭのＲＯドメインは、ＲＴＯが完了した後、ＲＯにそのＲＯドメイン自体の構成を証明および報告することができる。

ＭＥの信頼構築メカニズム（trust-building mechanism）が電源投入時のセキュアブートプロセスを実行することに制限される場合がある第１の実施形態において、ＭＥの構成は、ＭＥまたはＴＨＳＭによってさらに証明可能でない場合がある。あるいは、ＭＥは、セキュアブートを完了するときに、自己完全性検査を実行し、ＩＶ（完全性の値）を生成することができる。ＭＥは、ＯＴＡ（over the air）方法を用いたＵＭＴＳのセキュリティモードの特徴などのセキュリティモードの特徴に従って、機密性および完全性の保護のためのエンジンなどのソフトウェアをインストールすることができる。随意に、ＲＯのドメインの所有権がＲＯとのＲＴＯプロセスを介して取得されるときに、ＲＯは、ＲＴＯプロセスが完了することを許可するために、そのＲＯが受け入れることができるＴＨＳＭの条件に関するそのＲＯ独自のポリシーをダウンロードするか、またはその他の方法でインポートし、次いでそのポリシーを有効化してもよい。ＲＯのドメインは、ＲＯが、ＴＨＳＭ全体の条件、ＴＨＳＭのその他のドメインのビルド構造の条件、またはそれらの両方に同意するとき、ＴＨＳＭのプラットフォーム上のそのドメイン自身のインストールを「ゲートキープ（gate-keep）」するように構成されてもよい。したがって、ＲＴＯプロセスの一部として、ＲＯは、ＤＯの条件または「ドメインビルド計画（domain-building plan）」を特定するために、ＤＯのドメインのＳＤＭと何らかの情報を交換し、そのような条件がＲＯにとって受け入れ可能である場合にのみＲＴＯプロセスが完了することを許可してもよい。ＲＯドメインは、権利を有する場合もあり、そのような権利を行使して、ＲＯが最初にＴＨＳＭ上のそのＲＯのＲＴＯが完了したＲＯのドメインをビルドすることに同意した後、ＴＨＳＭの条件またはドメインビルド計画のあらゆる変更によってそのＲＯドメインが更新されるか、またはそのような変更を通知されることを可能にするように構成されてもよい。ＲＯのＤＰ（ドメイン固有のポリシー）が、ＲＯのドメインが通知されることを必要とする場合がある変更の種類を指定することができる。

ＳＤＭは、意図されるＲＯに関連するＲＯドメインに対するＲＴＯプロセスを開始することができる。これは、ＲＯのドメインが「初期の」、「獲得されていない（unclaimed）」状態にあるときに行われてもよい。例えば、ＲＯのドメインは、ＤＯのドメインおよびＤＯによって「ドメインＸ」（ＴＤ_X）と命名され得る。このドメインは、まだ獲得されていないシェル、または「初期」状態で作成されてもよい。そのような場合、ＳＤＭが、ＲＴＯプロセスを開始することができ、それによって、意図されるＲＯにドメインＴＤ_Xの代わりに連絡する。ＲＯがこのドメインに対するＲＴＯプロセスを経ると、ＳＤＭは、この同じドメインに対する別のＲＴＯプロセスをもはや開始しない場合がある。その代わりに、ＲＯ自身が、この特定のドメイン上で別の種類の所有権取得プロセスを開始することができる。そのような所有権取得プロセスは、これまでに規定されたＲＴＯプロセスとは、前者が、デバイスの所有者／ユーザまたはデバイス自体によって（おそらくはＳＤＭまたはＤＯのドメインの調整のもとで）ローカルで開始されるのではなく、リモートの所有者によってリモートで開始されることができるという点で異なる場合がある。ＤＯは、ＲＯのドメインがＲＴＯプロセスを経ており、したがって、適切なＲＯによって「獲得」または「所有」された後であっても、任意のＲＯのドメインを削除、破壊、または切断する権限を保有する場合がある。しかし、ＤＯは、概して、ＲＯのドメイン内に記憶された秘密を知ること、またはＲＯのドメイン内で実行された中間の計算または関数を知ることはできない場合がある。

ＳＤＭが初期のＲＯのドメインに対するＲＴＯプロセスを開始する前に、ＳＤＭは、ドメインのビルドのための利用可能なリソースのリストを調べることができる。リストは、ＤＭのドメインによって保有され得る。ＳＤＭは、「所望のドメイン（Desired Domain））リストも調べることができる。所望のドメインリストは、ＤＯのドメインＴＤ_DOに保有されてもよい。ＳＤＭは、ＳＤＰ（システムのドメインポリシー）と、ＤＭのドメインからの問い合わせのために利用可能でありうる、ＴＨＳＭのおよびプラットフォームの既存のドメインの信頼の状態を含む現在の状態とを調べることもできる。この情報は、特定のＲＯのドメインに対する所望のＲＴＯプロセスが、利用可能なリソースおよびポリシーのもとで可能であり、所望のドメインリストのもとで望ましく、ＴＨＳＭの既存のドメインの状態、例えば信頼の状態のもとで許されるかどうかを判定するために使用されてもよい。

あるいは、ＴＤ_RO（リモートの所有者のドメイン）が、それ自体でＲＴＯプロセスを開始し、管理する場合がある。ＴＤ_ROは、ＲＴＯプロセスの前は、獲得されておらず、「初期」状態である場合がある。「初期の」ＲＯのドメインＴＤ_ROは、そのＴＤ_ROが起動時にその意図されるＲＯに連絡すること、およびＲＴＯプロセスを自律的に開始することを可能にする事前に構成された機能を含んでもよい。随意に、ＲＴＯプロセスは、ＴＤ_ROに、ＴＨＳＭの所有者またはユーザに指示し、次いで、ＲＴＯプロセスを開始するためのＴＨＳＭの所有者またはユーザからの「同意（nod）」を得るようにさせた後で、開始されてもよい。作成され（ターゲットの）、リモートの所有者ＲＯ＿ｔａｒｇｅｔによって所有されるように意図されたが、まだＲＴＯプロセスを介して所有されておらず、「初期」状態のままであるドメインＴＤは、以降、ＴＤ_{RO_target}＊と呼ばれる場合がある。

別の代替的方法において、ＴＤ_ROは、特定のＲＯとの少なくとも１つのＲＴＯプロセスを経た場合があり、ＴＤ_ROは、現在、ＲＯによって「獲得」または「所有」されている場合がある。ＤＯ、またはドメインＴＤ_DOなどのＴＨＳＭ上のＤＯの代理が、同じＲＯのドメインに対する別のＲＴＯプロセスを開始することを許可されるかことができるかどうかは、ＲＯのポリシーおよび／またはＳＤＭのポリシーに依存する場合がある。ＳＤＭは、ＲＴＯの目的を調べることができ、そのポリシーの構造内の許容できる目的または活動に基づいて、そのような新しいＲＴＯが続行することを許可すべきかどうかを判定してもよい。リモートシグナリングによるＲＯ、またはＴＤ_RO（ＲＯのドメイン）は、同じＲＯとの、そのドメインに対する別のＲＴＯプロセスを開始してもよい。これは、ＲＯが、ＴＤ_ROの内の構成ファイル、セキュリティポリシー、または実行コードを更新する必要があるときに行われてもよい。ＲＯは、更新をダウンロードすることができる。更新は、非ＲＴＯの、ＯＴＡ（over the air）更新プロセスを介して行われてもよい。しかし、場合によっては、ＲＯまたはＴＤ_ROは、別のＲＴＯプロセスを用いて一部のファイルまたはコードを更新する場合がある。

「初期」ＴＤ_ROがそのＴＤ_ROに対するＲＴＯプロセスを開始するとき、そのＴＤ_ROは、ＤＭのドメインによって保有されうる、ドメインのビルドのための利用可能なリソースのリストを調べるために、ＳＤＭに依存する必要がある場合がある。ＴＤ_ROは、ＤＯのドメインに保有される場合がある「所望のドメイン」リストと、ＳＤＰ（システムのドメインポリシー）と、ＤＭのドメインからの問い合わせのために利用可能でありうる、ＴＨＳＭの既存のドメインの信頼の状態を含む現在の状態とを調べるためにやはりＳＤＭに依存する場合がある。この情報は、特定のＲＯのドメインに対する所望のＲＴＯプロセスが、利用可能なリソースおよびポリシーのもとで可能であり、所望のドメインリストのもとで望ましく、ＴＨＳＭの既存のドメインの状態または信頼の状態のもとで許されるかどうかを判定するために使用されてもよい。

ＳＤＭのポリシーは、ＤＯに関するＴＯ（take-ownership）プロセス中に構成されてもよい。このプロセスは、ブートプロセス中に施行されるあらかじめ存在する構成の構造によってローカルで行われてもよい。ＤＯのＴＯは、リモートで行われることもでき、このプロセスは、デバイスの所有者でないリモートの所有者に関するＲＴＯプロセスの場合と異なり、ＤＯのドメインに対するＴＯプロセスの場合は、ＲＴＯを阻むかまたは許可するためのＳＤＭの調査が呼び出されない場合があることを除いて、本明細書において規定された、デバイスの所有者のドメインではないドメインの所有権取得での使用を対象とするＲＴＯプロセスと同様であってもよい。ＳＤＰは、ローカル（物理的に存在し、デバイスと対話するＤＯによって）で、または遠隔に位置するデバイスの所有者とのリモートの対話を含むようにして実行され得るＤＯの所有権取得プロセス中に確立されてもよい。ＳＤＰのコンポーネントは、すべての非ＤＯドメインに共通の許容できる活動または目的のリストである。このリストは、ドメインの所有権取得が許されないリモートの所有者を指定する追加的なエントリを含んでもよい。

第２の実施形態において、ＭＥは、セキュアブート能力を有してもよく、そのＭＥのブートコードの一部の「セキュアブート（secure boot）」検査の一部を実行するためにＴＨＳＭに依存する場合がある。ＭＥは、ＯＭＴＰのＴＲ０のセキュアブートなどの非ＴＣＧセキュアブートを実行することができる。ＴＨＳＭは、ＴＨＳＭに与えられた物理的な保護を「利用する（utilize）」ように、ＭＥの完全性を検査するために使用されてもよい。例えば、ＭＥが、ＴＨＳＭに生データを送信することができ、ＴＨＳＭが、ＭＥの完全性を検査することができる。ＷＴＲＵは、ＭＥとＴＨＳＭの間の安全なチャネルを提供するためのメカニズムと、ＴＨＳＭがＭＥの完全性の検査をする目的で、少なくとも、安全にＴＨＳＭにコードまたはデータを送信すること、およびＴＨＳＭと安全なチャネルを介するなどして安全に通信することを任され得る、ＭＥの「ある程度信頼できる（somewhat trustworthy）」部分とを実装することができる。ＴＨＳＭは、そのＴＨＳＭの中に、ＭＥの代わりにＭＥのコードの一部を記憶することもできる。これらのコードが、ブートプロセス中にＭＥにロードされてもよい。ＴＨＳＭは、そのＴＨＳＭ自体とＭＥとの間で、ＴＨＳＭが、そのハードウェアに基づく保護メカニズムのおかげでより信頼できる環境である場合があるので、ＭＥの完全性の検査を実行する役割、またはＭＥに関するコードの一部を記憶およびロードする役割を担ってもよい。

第３の実施形態において、ＴＨＳＭは、セキュアブート、またはＭＥのコードの完全性の検査の一部を実行してもよい。これは、ＲＯに証明可能である場合がある。ＭＥは、単一の信頼できるエンティティ、ＭＴＥ（Mobile Trusted Environment）を含んでもよい。ＭＴＥは、ＭＥの残りの部分よりも信頼されるＭＥ内の論理的に分かれた環境であってもよい。ＭＴＥは、ハードウェアに基づくＲｏＴ（root of trust）などのいくつかのハードウェアに基づく保護メカニズムを利用してもよい。ＭＥの基本コードがロードされた後、ＭＴＥがロードされてもよい。ＭＴＥは、外部のベリファイア（verifier）に、信頼できる署名鍵の使用など、信頼の証拠を提供することができるという意味で、信頼できるエンティティである場合がある。ＭＴＥは信頼できるエンティティであるが、ＭＴＥは、実際のＴＰＭに関連する測定プログラムコードであるｃｏｒｅｒｏｏｔｏｆｔｒｕｓｔｆｏｒｍｅａｓｕｒｅｍｅｎｔを持たない場合がある。受電デバイス（powered device）としてのＭＥが、ＴＨＳＭが動作することができる「プラットフォーム」を提供する限り、ＭＥは、本明細書においてはＭＥプラットフォームと呼ばれる場合がある。ＭＴＥは、ＭＥプラットフォームの完全性の証拠を収集し、その証拠を、ＭＴＥ内の保護された署名鍵を用いることによって提供される少なくとも完全性の保護のもとで、ブート後のＳＤＭなどのＴＨＳＭ内の信頼できるエンティティに転送するように構成されてもよい。ＴＨＳＭは、ＴＣＧのＴＰＭまたはＭＴＭのような完全性の測定および検証機能を実装するので、ＴＨＳＭは、「エクステンド（extend）」操作を実行するＴＣＧのＴＰＭまたはＭＴＭの能力をやはり実装する場合があり、それによって、ＰＣＲ（Platform Configuration Register）のための新しい値を計算するために、現在のソフトウェアの測定値が、ソフトウェアのロードの履歴的状態を指示するＰＣＲの現在の値と組み合わされる。ＴＨＳＭは、（ソフトウェアコンポーネントの完全性の生の測定値である）ダイジェスト値、またはＰＣＲの値を、ＴＨＳＭに対するＭＥプラットフォームの信頼性の証明のために使用され得る別の完全性データに変換するためのメカニズムが実装されてもよい。簡単にするために、ＭＥプラットフォームの完全性の収集されたデータは、以降、ＭＰＩＤ（ＭＥプラットフォーム完全性データ）と表される場合がある。ＴＨＳＭは、ＭＥまたはＭＴＥのためのドメインを維持しない場合がある。ＴＨＳＭは、そのＴＨＳＭが計算されたダイジェストを照合する証明された尺度を、事前に構成されたファイルからか、またはＤＭとリアルタイムで連絡を取ることによってかのいずれかで取得することができる場合がある。一致が判定されるならば、ＭＥの証明が、その後に続いてもよい。ＭＴＥは、モデル番号、どの種類のサービスを実行するようにＭＥが意図されているか、および誰のためにサービスを実行するようにＭＥが意図されているかなどの、ＭＥの「環境」を示すデータを収集してもよい。簡単にするために、そのようなＭＥの環境の説明は、以降、ＭＰＥＳ（ＭＥプラットフォーム環境サーベイ）と表される場合がある。ＴＨＳＭのＤＯのＲＯは、そのＲＯ自身のドメインとＭＥプラットフォームの両方の完全性を証明することができる。この証明は、例えば特許文献１で規定された、Ｍ２Ｍに関連するＴＲＥ（Trusted Environment）のＭ２ＭＥ検証（M2ME Validation）機能と同様である場合がある。ＭＥは、継続的に、自律的に、またはＴＨＳＭからの要求に応じて、そのＭＥの変化する状態をＴＨＳＭに報告することができる。

第４の実施形態において、ＭＥとＴＨＳＭの両方は、完全なＭＴＭの機能を実行するように構成されてもよい。ＭＥまたはそのドメインの信頼性が、ＭＥによってまたはドメインによって直接証明可能である場合がある。ＭＥのＲＯドメインは、その状態を継続的にまたは要求があるごとにＲＯに報告してもよい。ＴＨＳＭのＲＯドメインは、同様に機能してもよい。ＭＥのＲＯドメインおよびＴＨＳＭのＲＯドメインによる報告は、同期されてもよく、互いに結び付けられてもよい。また、報告は、プロトコルフローの共通セッションを用いて行われてもよい。

この実施形態において、ＭＥは、本明細書に記載のＴＨＳＭのいくつかの機能を実行するように構成されてもよい。ＭＥは、それぞれが特定の所有者に関する、そのＭＥ自体の１またはそれ以上のドメインを含んでもよい。これらのドメインは、ＴＨＳＭによる信頼できるエンティティのプロパティを含んでもよい。そのようなドメインは、ＤＭ（デバイス製造者）ドメインおよびＵ（ユーザドメイン）を含んでもよい。これらのドメインは、ＴＨＳＭと同様にして事前に構成されてもよい。ＭＥ上のドメインをＴＨＳＭ上のドメインと区別するために、文字列ＭＥが、ドメイン自体を指定する文字列を下付きで添えられてもよい。したがって、ＤＭに関するドメインは、ＭＥ_DMと表され得る。ＴＨＳＭ上のＤＯ（デバイス所有者）ドメインは、ＳＤＭに存在するＳＤＰ（システム全体のドメインポリシー）への準拠を保証するために、ＭＥ側のドメインを監視してもよい。ＭＥで各ドメインが作成されると、ＳＤＭとの通信が、それぞれの新しいドメインの構成をＴＨＳＭのＤＯに知らせることができる。

ＭＥは、ＴＨＳＭのＳＤＭの方法と同様の方法で機能することができるＭＥ_PDM（プラットフォームドメインマネージャ）と呼ばれる場合があるドメインマネージャを含んでもよい。ＭＥ_PDMは、ＭＥ_DMに存在してもよく、初め、ＤＭによって定義された事前の構成を有してもよい。この最初の構成は、ＴＨＳＭ上のＴＤ_DMの最初の事前に構成された定義の最初の構成と、その目的および機能の点で同様である場合がある。ＭＥ_DMの設定は、ＴＤ_DOがＴＨＳＭにおいてインスタンス化された後に行われるように時間が決められてもよい。ＳＤＭが、ＭＥ_DMに関する設定が完了していることを知らされるとき、ＳＤＭは、システム全体の制約によって、ＳＤＰから生じた、またはＳＤＰを反映するポリシーの制約を課す場合がある。ＳＤＭは、幾人かのリモートの所有者およびＴＨＳＭ上のそれらの所有者のドメインのリストを保持する場合がある。リスト内の所有者のうちの１人に属するドメインがＭＥ上で作成され、管理されることになる場合、ＳＤＭは、ＭＥ上のこれらのドメインの作成および管理をある程度制御することができる。

この実施形態において、ＭＥは、完全なＭＴＭの機能を有する場合がある。したがって、ＭＥは、ＣＲＴＭ（core root of trust for measurement）、ＣＲＴＲ（core root of trust for reporting）、およびＣＲＴＳ（core root of trust for storage）を含んでもよい。ＴＨＳＭ上では、ドメインの加入機能は、ＴＳＩＭ機能によって管理されてもよい。ＴＨＳＭにおける１つのドメインおよびＭＥ上のもう１つのドメインのような２つのドメインが同じＲＯに関する場合、ＴＨＳＭ上のドメインが、加入機能およびそのリモートの所有者のためのそのドメインの管理などの、非常に高レベルのセキュリティおよび／または信頼を必要とするＲＯのための機能またはサービスのために使用されてもよい。一方、ＭＥ上のドメインは、あるレベルのセキュリティまたは信頼をやはり必要とするが、ＴＨＳＭ上のドメインから期待される機能およびサービスに関して必要とされるのと同じレベルまでは必要としない場合がある、同じＲＯに関する機能またはサービスのために使用されてもよい。事前に構成されたファイルからビルドされないドメインは、ＲＴＯ（remote take ownership）プロセスによって構成されてもよい。通常のＲＯ（リモートの所有者）に関する、ＭＥのためのＲＴＯは、ＴＨＳＭのためのＲＴＯと同様である場合がある。

ＭＥ上のドメインは、リモートの所有者に関する加入管理のために使用されるように意図されていない場合がある。その代わりに、それらのドメインは、ユーザ、所有者、リモートの所有者、またはこれらの任意の組み合わせの利益のために、計算およびリソースを多く消費するタスクを実行するために使用されるように意図される場合がある。例えば、これらのドメインは、ＴＨＳＭ上の比較的限られたリソースに対しては実行可能でない場合があるタスクを実行することができる。ＭＥ上のドメインは、一度作成され、その後、明示的に削除されるまでＭＥ内に残るのではなく、これらのドメインは、仮想化に似て、ブート時に、または、さらにはランタイムセッション上で作成されることができ、それらのドメインの特定の目的のために一時的にセッションに基づいて使用されることができるという意味で、より「つかの間の（ephemeral）」または「一時的である（temporary）」場合もある。ＭＥ上のドメインのリモートの所有者は、その他のリモートの所有者によって所有されるＭＥ上のその他のドメイン、またはＴＨＳＭ上のそのようなその他のドメインのリソースの割り当ておよびそれらの目的の証明されたサーベイを要求および取得するという観点で、同じレベルの特権を持たない場合がある。

モバイルの信頼できるプラットフォームのデバイスの所有者が、ＭＮＯリモート所有者としても知られる特定のＰＬＭＮによって事前に割り当ておよび初期化されていない「空の（blank）」ＷＴＲＵを購入するための方法を提供し、制限なしにモバイルネットワークのオペレータの任意の選択を可能にすることが有利である。当該方法は、ＵＥ（ＵＭＴＳデバイス）などのＷＴＲＵのＲＴＯプロセスなどの所有権取得プロセスを実行することを含む場合があり、リモートの所有者は、ＰＬＭＮのオペレータ、または加入アプリケーションが対象とするその他の同様のオペレータであり、ＴＨＳＭの内部のドメインであり、正しいＲＯによって獲得され得るＲＯのドメインなどのサブシステムを設定し、カスタマイズし、確定する。

上述のように、ＴＨＳＭ（Trusted Hardware Subscription Module）は、ＩＳＩＭ（IMS Subscription Identity Module）のような、ＰＬＭＮのオペレータのための加入アプリケーション、およびその他の付加価値のあるサービスに関する機能を含む耐タンパ性ハードウェアコンポーネントモジュールとして構築されてもよく、またはそのようなモジュールをそのＴＨＳＭの中に含んでもよい。ＴＨＳＭは、ＷＴＲＵから取り外し可能であるか、または取り外し不可能であってもよい。ＵＩＣＣの拡張されたバージョン、またはグローバルプラットフォーム規格に準拠したスマートカードが、そのようなＴＨＳＭの１つの実施形態であってもよい。

所有権取得操作は、オペレータまたはＰＬＭＮとＷＴＲＵとの間の基本的な「信頼（trust）」関係を構築する。この手順は、汎用的な「ｔｒｕｓｔｅｄ」ソフトウェア構成を有する「初期」エンジンを備える「ｂｌａｎｋｔｒｕｓｔｅｄ」ＴＳＩＭをインストールし、インスタンス化することができる。このサブシステムは、プラットフォームがそのプラットフォームの「初期」構成およびセキュリティ属性の証拠を提供することができる場合に、リモートの所有者によって「証明され（certified）」得る。図３および３Ａは、このプロセスが特に本明細書に記載の第１の実施形態に関連するときのこのプロセスの例を示す。リモートの所有者は、ユーザに要求されたサービスを提供し、適切なセキュリティポリシーを設定し、サービスに合ったデバイスの構成を施行するモバイルネットワークである場合がある。このプロトコルに関する所有者は、ローカルである場合がある。

図３および３Ａは、例示的な起動およびＲＴＯプロセスを示す。ＭＥは、ブート前の状態３０４を有する場合がある。３０６において、デバイスが、電源をオンにされ得る。３０８において、ＭＥは、「セキュア」ブート（非ＴＣＧ）を実行することができる。ＭＥは、基本コードがブートされた状態３１０に到達することができる。さらに、３１２において、ＭＥは、ＴＨＳＭに「基本ブート完了（base boot completed）」信号を送信することができる。３１４において、ＭＥは、基本構成に従って追加的なソフトウェアをロードすることができる。３１６において、ＭＥのブートは、完了した（アプリケーションがロードされた）状態である場合がある。３１８において、ＭＥは、ＴＨＳＭにブート完了メッセージを送信することができる。

ＴＨＳＭは、ブート前の状態３３０にある場合がある。３３４において、ＴＨＳＭは、ＴＤ_DMをロードすることができる。ＴＨＳＭは、構成中に、事前に構成されたファイルを受信することができ、例えば、３３６は、事前に構成されたファイルの使用を示す。３３８において、ＴＨＳＭは、「ＴＤ_DMビルド（TDDM build）」状態（基本構成状態：basic configuration state）に到達することができる。ＴＨＳＭは、例えば、３４０で示されるように、ＲＯドメインのための利用可能なリソースに関するＤＭの仕様を受信することができる。

３４２において、ＴＤ_DMは、ＴＤ_DOをビルドすることができる（ＴＤ_DOはＳＤＭを含んでもよい）。３４４において、ＴＨＳＭは、例えば、保存された構成ファイルを用いて、前のＲＴＯにより利用可能となり得るドメインをビルドすることができる。３４６において、ＴＨＳＭは、ＴＤ_DOがビルドされた状態（ＳＤＭを含む）に到達することができ、ＴＤ_DOは、ＤＯによって獲得されていないか、または獲得されている場合がある。３５０において、ＴＤ_DOは、ＴＤ_Uをビルドすることができる。３５２において、入力が、ＤＯから受信され得る。３５４において、ＴＨＳＭは、ＴＤ_Uビルド状態に到達することができ、ＴＤ_Uは、獲得されていないか、または獲得されている場合がある。３５６において、ＴＨＳＭは、ＤＯまたはＤＵから（例えば、ファイルまたは対話によって、ＤＯがどのドメインをビルドしたい場合があるかを指定する）入力を受信することができる。３５８において、ＴＤ_DOは、ＲＯドメイン、ＴＤ_ROをビルドすることができる。

ここで図３Ａを参照すると、３６２において、ＴＨＳＭは、ＴＤ_ROがビルドされた状態に到達することができ、ＴＤ_ROは、ＲＯによって獲得されていないか、または獲得されている場合がある。３６６において、ＳＤＭが、ＴＤ_ROにＲＴＯを実行するように要求することができるか、またはＴＤ_ROが、ＳＤＭにそのＴＤ_ROがＲＴＯを実行することを通知する（または要求する）ことができる。３７０において、ＴＤ_ROは、ＲＴＯプロセスを開始することができる。３８０において、代表的なリモートの所有者（ＲＯ₁．．．ＲＯ_n）が存在する。３８４において、情報が交換され得る。例えば、リモートの所有者とのＲＴＯプロセスの一部として、交換される情報は、証明、構成、ポリシー、目的、証明書（本明細書においてはＣＥＲＴとも呼ばれる）、鍵、およびＴＤ_ROに対するＳＰのうちの１つまたは複数を含み得る。随意に、ＲＯは、ＲＴＯプロセス中にＤＯの「環境」または「ドメイン計画（domain plan）」を見つけることができ、ＲＯがその環境／計画に同意する場合、プロセスが継続することを許可することができる。

３７２において、ＴＨＳＭは、さまざまなドメインに関するシステム構成をキャプチャ／更新し、その情報を保存し、その情報をＴＨＳＭ内の不揮発性の保護されたメモリに記憶することができる。３７４において、ＴＨＳＭは、ＲＴＯ後のＴＤ_ROを有する状態に到達することができる。

第１の実施形態を参照すると、ＤＯのＲＴＯによって形成されたポリシーのドメインが、後続のＲＴＯプロセスのドメインの構成に影響を及ぼす規定を含んでもよい。このＲＴＯプロトコルは、ＤＯではないＲＯに適する場合がある。ドメイン固有のポリシー（ＤＰ）が、ＲＴＯのトランザクション中にダウンロードされ得る。ＤＯに関するＤＰは、そのようなＤＰ（ＤＰ_DO）が、ＴＨＳＭ内の、リモートで所有される場合があるその他のドメインをビルドし、保守するために使用することを対象とするＳＤＰ（システム全体のドメインポリシー）を含み得るという点で、ＲＯに関するＤＰとは異なる場合がある。ＲＴＯプロセスの前、またはＲＴＯプロセス中に、ドメインのＲＯは、ＴＴＰ（信頼できる第三者：trusted third party）から、ＴＨＳＭのドメインのすべてのすべてまたは一部をサポートするハードウェアまたはソフトウェアの構成および現在の完全性の状態に関するＲＩＭ_RO（Reference Integrity Metric）を取得することができ、

と表され得る。

場合によっては、ＴＴＰは、ＲＯが検証することに関心がある、ドメインを含むＴＨＳＭのＨＷおよびＳＷの一部に関するＲＩＭ_ROを提供することができる場合がある。２つ以上のＴＴＰが、ＲＩＭ_ROを提供するために必要とされる場合があり、ＲＯは、それらのＲＩＭ_ROを収集し、集合的な基準尺度を形成する。ＲＴＯプロセスを受けるＴＨＳＭのＴＤ_{RO_target}（ターゲットのドメイン）は、ＴＨＳＭのＳＤＭの助けを借りて、そのドメインのＲＯに、署名されたＴＰＩＡを提供するように構成され得る。ＴＰＩＡは、ＴＤ_{RO_target}のＲＴＯプロセスの完了を許可する前に、ターゲットのドメインのＲＯが検証することに関心があるＴＨＳＭ上のドメインの個々の完全性証明および／またはデバイスのプラットフォームの完全性証明の連なりである場合がある。ＴＤ_{RO_target}（ＴＨＳＭのターゲットのドメイン）は、ＴＨＳＭのＳＤＭの助けを借りて、そのドメインのＲＯに、署名されたＴＰＥＳを提供することができる場合がある。ＴＰＥＳは、ＴＨＳＭのその他のドメインの数および性質と、ＴＤ_{RO_target}の利益のために使用され得るＴＨＳＭのプラットフォームのリソースなどの任意の残りの利用可能なリソースとを含むＴＨＳＭの環境のサマリを含むことができ、

と表され得る。

あるいは、ＲＯが関心のあるすべてのドメインのすべての証明を含み得るＴＰＩＡを報告する代わりに、ＳＤＭは、そのＳＤＭがすべてのそのようなドメインの完全性を検査し、それらのドメインが信頼できるとみなすという、準自律的なステートメントである場合がある署名されたステートメントを提供することができる。この証明は、ドメインの集合の完全性のローカルでの検証を含んでもよい。ローカルのベリファイアは、ＴＨＳＭ上の各ドメインに関する有効な構成のリストを含んでもよい。ＳＤＭは、ローカルのベリファイアに、ＡＩＫによって署名され得るＴＰＩＡを提供することができる。個々の完全性証明の検証は、それらの完全性証明が、対応するローカルに記憶された構成のリストのエントリに一致することを必要とする場合がある。ＳＤＭは、ＴＰＩＡを構築するために必要な完全性の測定、ロギング、およびＰＣＲへのエクステンション（extension）を実行し、各ドメインの信頼性を証明することができる。これらの測定およびそれらのエクステンションは、必要とされるドメインに関する証明が行われたことを確定するためにベリファイアによって使用されてもよい。

検証が行われると、ローカルのベリファイアは、関連する証明が行われたというステートメントを準備することができ、証明された鍵の組（Ｋ_{sign_verify_priv}、Ｋ_{sign_verify_pub}）からの秘密鍵を用いてこのステートメントに署名する。署名されたＴＰＥＳと連結された署名された検証ステートメントを含むメッセージは、

と表され得る。

ＴＴＰからの｛ＲＩＭ_RO｝ならびにＴＤ_{RO_target}からの署名されたＴＰＩＡおよび署名されたＴＰＥＳを受信すると、ＲＯは、ＴＤ_{RO_target}が、ＲＴＯプロセスを継続する目的でＲＯが同意できると認めるＴＨＳＭ内の環境などの環境内にあるかどうかと、ＴＤ_{RO_target}およびＲＯが関心のある任意のその他のドメインをサポートするハードウェアまたはソフトウェアが、それらの完全性がＲＯにとって同意可能である状態にあるかどうかとを検証することができる。

初期ドメインに関するＲＴＯプロトコルは、電源投入時に開始することができる。随意に、ＲＴＯプロトコルは、電源投入後に開始する場合がある。ＴＨＳＭのセキュアブートが完了するとき、結果として生じるドメインのビルドは、一回目などの最初の電源オン時のプラットフォームの状態か、またはデバイスが前に起動され、その後、電源を切られたときの前の状態のプラットフォームの状態かのどちらかを反映する内容を有する構成ファイルによって判定されてもよい。したがって、デバイスは、ＴＤ_DMのビルド、「初期の」ＴＤ_DOの状態、および「初期の」ＴＤ_Uの状態を含む基本構成である場合がある。あるいは、ＷＴＲＵは、より後の構成、例えば、ＴＤ_DM、「ＲＴＯ後の」ＴＤ_DOの状態、および「ＲＴＯ後の」ＴＤ_Uの状態を含む、前の起動およびドメインのビルドまたはＲＴＯプロセスに基づく構成である場合がある。別の代替的方法において、ＷＴＲＵは、図２に示されたドメインなどの追加的なドメインの拡張された組も含む構成である場合がある。そのようなドメインは、前の作動セッション中に作成された場合があり、所有権が、前のセッション中に行われた前に実行されたＲＴＯプロセスによってそれぞれの所有者により取得された場合がある。

第１の実施形態を参照すると、プラットフォームの安全なおよび信頼できるエンティティとして、ＴＨＳＭが、所有権取得プロトコルを制御し、ＭＥが最初の信頼できる状態であるか否かを判定することができる。事前にプロビジョニングされた鍵Ｋ_tempが、ＴＨＳＭ−ＭＥインターフェースに渡って送信されるメッセージの機密性を保護するために使用されてもよい。簡単にするために、暗号化されたメッセージＡは｛Ａ｝によって表される場合があり、メッセージの署名は［Ａ］によって表される場合があり、表記ＩＤ_MEおよびＩＤ_THSMは、それぞれ、ＭＥおよびＴＨＳＭの事前にプロビジョニングされた一時的なＩＤを表す。

ＲＴＯの開始は、ＴＤ_DOのＳＤＭが、ＲＯとのＲＴＯプロセスの後にその特定のＲＯによって獲得されるように意図される「獲得されていない」「初期」ドメインに対するＲＴＯを開始することを含んでもよい。ユーザは、ＭＥプラットフォームの電源オンを開始することができる。電源オン時に、ＭＥは、そのＭＥが「アライブ（alive）」になる基本コードの、ＯＭＴＰによって定義されるブートなどの「非ＴＣＧ（non-TCG）」「セキュアブート」を実行することができる。非ＴＣＧセキュアブートプロセスの一部として、ＭＥの基本コードの完全性が、自律的に検査されてもよい。

第３の実施形態を参照すると、ＭＴＥ（Mobile Trusted Environment）が、基本コードのブートプロセスの完了に続いてロードされてもよい。署名鍵を用いて、ＭＴＥは、ＭＥプラットフォームの構成の完全性を証明することができる。

ＭＥは、基本コードをロードした後、そのＭＥが最小限の安全な設定でブートしたことを指示する信号を、ＴＨＳＭに周期的に送信することができる。ＴＨＳＭのＤＯのドメインは、信号が送信されるときまだブートしていない場合があるので、ＭＥは、ＴＨＳＭのＤＯのドメインからから肯定応答信号を受信するまで異なるランダムなノンス（ｎｏｎｃｅ＿１）とともに同じ信号を送信することができる。この信号は、

と表され得る。

第３の実施形態を参照すると、このシグナリングは、

と表され得る。

ＴＨＳＭは、「安全に（securely）」ブートすることができ、したがって、ＴＨＳＭは、そのＴＨＳＭのＤＭのドメイン、「初期の」ＤＯのドメイン、ユーザのドメイン、およびＲＯによって所有されるように意図されているが、まだ所有されていない場合がある少なくとも１つの「初期」ドメインをロードした場合がある。また、これらのドメインをロードする際、ドメインのコードの状態のそれぞれの完全性が、ドメインのそれぞれのＲＩＭ（reference integrity metrics）と照合されてもよい。照合は、ＴＣＧのＭＰＷＧの仕様などの仕様に従って実行されてもよい。

ＴＤ_DO（デバイスの所有者のドメイン）は、「事前に構成された（pre-configured）」構成か、またはそのＴＤ_DOがＤＯのためのＲＴＯプロセスを既に経ている場合の「最後に保存された：Last-saved（前のＲＴＯ後の：post-previous-RTO）」構成かのどちらかにロードされてもよい。ＤＯのドメインは、ロードされるとき、ＳＤＭ（システム全体のドメインマネージャ）を含んでもよい。ＳＤＭは、その他のＲＯ（リモートの所有者）に属するべきドメインのビルドまたはロードおよび保守を管理することができる。ＳＤＭは、ＤＭのドメインからの「ドメインのために利用可能なリソースなリスト（list of resources available for domains）」を調べることができ、ＴＤ_DOが保護するＳＤＰ（システム全体のドメインポリシー）も調べることができる。

ブート時に、ＳＤＭは、ＴＨＳＭの人間のユーザまたはＤＯ（人間の所有者）に「ビルドされ得るドメインのリスト（list of domains that can be built）」を示し、ビルドされるべきドメインを選択する入力を要求することもできる。ユーザまたは所有者からその入力を得た後、ＳＤＭは、人間の所有者またはユーザからの応答で指定されたドメインだけをビルドすることに進むことができる。ＳＤＭは、ＭＥと対話して、これらのトランザクションのためのＵＩ（ユーザインターフェース）を提供することができる。

セキュアブートの後、ＴＨＳＭのＴＤ_DOは、ＭＥに「ＴＨＳＭブート完了」メッセージを送信することができる。メッセージ内に、ＴＤ_DOは、ロードされたＲＯのドメインの数および名称などの、ドメインの現在の状態の外部に開示可能なサマリも含めることができる。ＴＤ_DOのＳＤＭは、ドメインの現在の状態のサマリの外部への開示の程度を判定し、施行することができ、そのような判定は、ＳＤＰ、ならびに／またはＴＨＳＭおよび／もしくはＭＥ上のドメインのＤＰ（ドメイン固有のポリシー）に基づくことができる。ＴＤ_DOは、受信されたｎｏｎｃｅ＿１をＳＨＡ−Ｘ完全性検査コード入力の一部として含めることによって、このメッセージ内のＰａｃｋａｇｅ＿１の受信に対して肯定応答することができ、これは、以下のように表され得る。

ＩＤ_THSMのようなＴＨＳＭのＩＤは、ＤＭのドメインＴＤ_DMに保有されてもよく、ＴＤ_DMのＩＤと同じであってもよい。ＤＯのドメインＴＤ_DOは、そのＴＨＳＭのＩＤをＴＤ_DMから取り出して、式６のＰａｃｋａｇｅ＿２を構築することができる。

「ＴＨＳＭブート完了」信号に応答して、ＭＥは、そのＭＥのブートプロセスを完了することを継続することができる。そのＭＥのブートプロセスを完了した後、ＭＥは、ＴＨＳＭのＴＤ_DOに、

と表され得るメッセージを送信することができる。

以下は、ＤＯのドメインのＳＤＭが、現在「初期の」ＲＯのドメインに対するＲＴＯプロセスを開始し、管理する場合に当てはまる。

ＴＤ_DOがＭＥからＰａｃｋａｇｅ＿２を受信した後、ＲＴＯプロセスが開始されてもよい。ＴＤ_DO内のＳＤＭ（システム全体のドメインマネージャ）は、「初期の」ターゲットのＲＯのドメイン（ＴＤ＊_{RO_Target}）にＲＴＯプロセスを開始するように要求することによってＲＴＯプロセスを開始することができる。ＳＤＭは、自律的に、または人間の所有者もしくはユーザに促されたときにこのプロセスを開始することができる。ＳＤＭは、ＴＤ＊_ROに、ターゲットのＲＯに関するＲＴＯプロセスを開始する要求を送信することができる。要求は、ＲＯのＩＤまたはＮＡＩ（ネットワークアクセス識別子：Network Access Identifier）などの、ターゲットのＲＯが誰なのか、および現在の要求の有効期間を含んでもよい。要求の一部としてか、または要求に付随する別個のパッケージとしてかのいずれかで、ＳＤＭは、「許可されるＲＯのドメインに関するＳＤＰの条件（SDP’s Conditions for Allowed RO’s Domains）」（以降、ＳＣＡＲＤと呼ばれる）のリストも送信することができる。ＳＤＭは、意図されるＲＴＯプロセスの後で、それが完了されるときに、ＴＤ_ROに関する「ターゲットのドメイン計画（Target Domain Plan）」も送信することができる。このメッセージングは、

と表され得る。

ＴＤ＊_{RO_Target}は、Ｐａｃｋａｇｅ＿４の受信に応答して、その要求を受け入れるかまたは拒否するかのどちらかを行うことができる。この要求は、ＲＯがＲＯのドメインの所有権を取得することを許可する「提案（offer）」として解釈されてもよい。ＴＤ＊_{RO_Target}は、事前に構成された基準、またはロードされたＲＯのドメインポリシーの独自の「初期」バージョンに基づいて決定を行うことができる。ＴＤ＊_{RO_Target}は、ＲＴＯを開始する要求、ＳＣＡＲＤ、およびターゲットのドメイン計画を調べ、実際のターゲットのリモートの所有者が不在の場合に、実際のターゲットのリモートの所有者の利益のためにそのような決定を行うように構成され得る。これは、

と表され得る。

「初期の」ＴＤ＊_{RO_Target}（ターゲットのＲＯのドメイン）が、このプロセスを開始することができる。ＴＤ＊_{RO_Target}は、ＲＴＯプロセスに関するそのＴＤ＊_{RO_Target}の「最終ドメイン計画（final domain plan）」をＳＤＭに知らせることができる。ＳＤＭは、要求を許可するかまたは拒否することができる。ＳＤＭが要求を許可する場合、ＴＤ＊_ROは、ＲＴＯプロセスを開始することができ、これは、

と表され得る。

Ｐａｃｋａｇｅ＿５ａまたはＰａｃｋａｇｅ＿５ｂの受信に応答して、ＳＤＭは、ＴＤ＊_{RO_Target}に対するＲＴＯプロセスに関して、事前に構成されるか、もしくはＴＤ_DOに対するＲＴＯプロセスによって取得され得るＳＤＰ（システムのドメインポリシー）、事前に構成されるか、もしくは所有者によって供給されるかのいずれかである場合がある「所望のドメイン」のリスト、ＤＭのドメインによって保有され、継続的に更新され得る「ドメインのための利用可能なリソース」のリスト、またはＴＨＳＭ内のドメインの現在の状態を調べることができる。

ＳＤＭは、ＴＨＳＭ上の複数のドメインをビルドもしくは保守するために利用可能な、仮想マシンのスレッドのためのメモリもしくはリソースなどの十分なリソースが存在するかどうか、ＴＨＳＭ内のドメインの現在の状態が、「所望のドメイン」リストで指定された状態と一致するかどうか、「所望のドメイン」内の任意の新しいドメインのビルドもしくはロードが、ＴＨＳＭ内のドメインの現在の状態によって支持可能であり、しかもＳＤＰのもとで許されるかどうか、またはドメインのうちの１つもしくは複数がＲＴＯプロセスを経る必要があるかどうかも評価することができる。

ＳＤＭが、ＴＤ＊_{RO_Target}が、利用可能なリソース、ＴＨＳＭの既存のドメインの現在の状態、およびＳＤＰに従ってＲＴＯプロセスを経ることができると判定する場合、ＳＤＭは、この判定（ＴＤ＊_{RO_Target}）を指示し、ＴＤ＊_{RO_Target}およびその周辺のドメインのＲＯの評価のためにＲＴＯプロセス中にそのＲＯに転送されるべきいくつかの完全性証明を準備することに進むことができる。これは、

と表され得る。

ＳＤＭは、人間のユーザに、例えば、ＷＴＲＵ上に表示されるメッセージによって、そのＳＤＭが特定のドメインに対するＲＴＯプロセスを開始しようとしていることを指示することができる。ＳＤＭは、人間のユーザまたはＤＯ（人間の所有者）に「ＲＴＯプロセスを開始する所望のドメイン、および所望のＲＯ（desired domains to start the RTO process and the desired RO）」のリストを示すこともでき、その指示に応答して所有者またはユーザが指定するＲＯドメインに対してのみＲＴＯプロセスを開始することに進む。ＳＤＭは、これらのトランザクションのためのＵＩ（ユーザインターフェース）を提供するＭＥと対話することができる。

ＴＤ＊_{RO_Target}は、そのＴＤ＊_{RO_Target}がＴＰＩＡおよびＴＰＥＳを構築するために使用することができる材料を準備するようにＳＤＭに要求することができる。これは、

と表され得る。

第３の実施形態を参照すると、この要求は、

と表され得る。

ＴＰＩＡおよびＴＰＥＳの要求で、ＲＯは、そのＲＯがＳＤＭからＴＰＩＡおよびＴＰＥＳに関するどの種類の情報を求めるかを指定することができる。例えば、ＴＰＩＡに関して、ＲＯは、ＴＰＩＡ自体ではなく、そのＲＯが完全性を検証したいドメインの名称または範囲を指定する場合がある。同様に、ＴＰＥＳに関して、ＲＯは、ＴＰＥＳ自体ではなく、ドメインの所有者のＮＡＩなどの公開ＩＤを指定する場合がある。

第３の実施形態を参照すると、ターゲットのＲＯは、ＭＥプラットフォームの完全性に関する具体的な情報（以降、ＭＰＩＤと呼ばれる）と、ＭＥの環境に関するその他の情報とをやはり要求してもよい。あるいは、ＲＯは、ＭＴＥがロードされ、ＭＰＩＤおよびＭＰＥＳがＭＥからＳＤＭに送信されたことの単純なインジケータを要求する場合がある。ＭＴＥ、ＭＥプラットフォームに存在する信頼できるエンティティは、それがＳＤＭによってそのようにすることを要求したときに、値ＭＰＩＤおよびＭＰＥＳを準備することができる。この要求は、

と表され得る。

ＭＴＥは、ＭＥから構成データを収集し、ＭＰＩＤを構築することができる。環境データも、ＭＰＥＳ（ＭＥプラットフォーム環境サーベイ：ME Platform Environment Survey）を生成するために獲得されてもよい。これらの値は、経時的に変わり得る現在のＭＥの状態に基づく場合がある。更新された値が、ＭＥの状態の変化の後で、将来の要求が行われる場合に、および将来の要求が行われるときに、ＳＤＭに送信されてもよい。概して、ＭＴＥは、ＳＤＭに、

と表され得る応答を送信することができる。

ＭＴＥは、そのＭＴＥの公開鍵Ｋ_{MTE_Pub}を含む、ＣＡによって署名され得る証明書を提供することができる。したがって、ＳＤＭは、ＣＡの署名の検証によってこの公開鍵が本物であることを確かめ、それによって、Ｋ_{MTE_Pub}を用いてＭＴＥからのメッセージの完全性を検査することができる。ＳＤＭは、ＴＰＩＡおよびＴＰＥＳを準備し、その後、それらをＴＤ＊_{RO_Target}に転送することができる。

ＴＰＩＡの準備のために、ＳＤＭは、「初期」ＴＤ_ROの、「初期」ＴＤ_ROによる完全性証明、ＴＥ_DMの、ＴＥ_DMによる完全性証明、ＴＥ_DOの、ＴＥ_DOによる完全性証明、ＴＥ_Uの、ＴＥ_Uによる完全性証明（デバイスのユーザがＤＯと異なる場合）、およびＲＯが関心のある任意のその他の既存のＴＤ_ROの、そのＴＤ_ROによる完全性証明などの完全性証明を収集することができる。

あるいは、ＳＤＭは、ＰＣＲから完全性の値を収集した後、コードおよびデータなどの測定ログのローカルの自律的な検査および再計算のプロセスによって、ドメインを、それぞれのドメインに関するＰＣＲからのダイジェスト値と照合することができる。これは、ＴＴＰ（ＰＣＡ）が、それぞれのドメインを含むべき最新のコードを知らず、ＴＴＰが、ＷＴＲＵ上のＴＰＭまたはＭＴＭに関して証明されているＡＩＫにリンクされた署名鍵を証明することができるときに実行されてもよい。ＴＴＰは、ＲＯがＳＤＭからのＴＰＩＡを比較するために使用することができるダイジェストの尺度に関する基準値を提供するように構成されない場合がある。ＳＤＭは、ドメインに関するコードのダイジェストを再計算し、それらのダイジェストをクォート（quoted）されたＰＣＲ値と比較することによって、そのＳＤＭがドメインに関して得たＰＣＲのクォート（quote）が最新であるかどうかをローカルで検査することができる。このローカルの検査が通ったならば、ＳＤＭは、ＴＰＩＡに署名をし、それをＴＤ_{RO_target}に、およびＭＴＥまたはＭＥを経由してＲＯ_targetに渡すことができる。

別の代替的方法、３元的な検証において、ＳＤＭは、ＴＰＩＡの一部として、ドメインのダイジェストおよび実際のコードなどの測定ログを提供することができる。ＲＯは、ダイジェストとともにコードを得るとき、ＴＴＰからダイジェストに関する基準尺度を得ることができ、測定ログからダイジェストを再計算することができ、それを、そのＲＯがＴＤ_{RO_Target}から受信したクォートされたＰＣＲのダイジェストおよびそのＲＯがＴＴＰから受信したダイジェストの基準尺度と比較することができる。

測定ログをともなうかまたはともなわないＴＰＩＡは、ＰＣＲのクォートが行われた「ローカル時間（local time）」の指示も含むことができ、個々のドメインに関するダイジェストのクォートに実質的にタイムスタンプを付ける。これは、ドメインのＰＣＲのダイジェストのそれぞれがＳＤＭによって最後に取得されたときの何らかの指示を提供する。測定ログがＲＯに送信されない場合に、ＰＣＲのタイムスタンプを付けられたクォートは、ＲＯがＴＰＩＡで指示された証明を検証する必要があるときに、ローカルのダイジェストが取得され、ＴＰＩＡに含められた時間が、証明の検証でそのダイジェストを使用することを許可できるだけ最近であるかどうかを判断する観点で、何らかの追加的な情報をＲＯに提供することができる。そのようなタイムスタンプを付けることに使用されている時計は、信頼できる時計である場合がある。

３元的な検証が失敗する場合、ＲＯは、更新された基準尺度、またはそのＲＯが所望のダイジェストを計算することができる測定ログをＴＴＰがそのＲＯに提供することを要求することができる。ＲＯは、３元的な検証を再試行することができる。検証が成功である場合、ＲＴＯは継続する。検証が失敗し、３元的な検証の成功がＲＯのポリシーによって必要とされる場合、ＲＴＯは終了されてもよい。

ＤＯのドメインの完全性証明に関して、ＳＤＭは、その完全性証明をＳＤＭのネイティブの機能によるなどして自律的に取得することができる。ＤＯのドメインの完全性証明を除く完全性証明に関して、ＳＤＭは、それぞれのその他のドメインに、独自のそれぞれの完全性証明を生成し、署名するように要求することができる。要求に、ＳＤＭは、受信者が、ＳＤＭがドメインからの完全性証明を要求および取得するための権限を有するかどうかを検査するために使用することができるトークンなどの認可データを含めることができる。要求は、ターゲットのＲＯ、およびターゲットのＲＯの要求の転送者としてのＳＤＭが受信者のドメインの完全性を検査ために必要とする受信者のドメインのＰＣＲ（Platform Configuration Register）の範囲を含んでもよい。この要求は、

と表され得る。

Ｎは、ＳＤＭがＰＣＲ値を収集するドメインの数であるものとしてドメイン（ｉ），ｉ＝１，２，．．．，Ｎと表記されるドメインのそれぞれは、初めに、証明の要求の中の認可データを検査し、次に、証明の要求で指定されたＰＣＲの範囲のＰＣＲ値を取り出す。この操作は、

と表され得る。

ＳＤＭは、ＴＰＩＡを実行して、証明のすべてを連結し、それにそのＳＤＭの署名鍵で署名することができる。これは、

と表され得る。

ＴＰＥＳの準備に関して、ＳＤＭは、ＤＭのドメインから取得され得るＴＨＳＭのＨＷおよびＳＷの構成およびバージョン番号、ＢＩＯＳの構成、プラットフォーム上のドメインの数、現在のドメインのために占有されているメモリなどの合計のプラットフォームのリソース、既存のもしくは新しいドメインのさらなるビルドもしくは拡張のために残っているプラットフォームのリソース、ドメインの名称、またはそれらのドメインの所有者の名称もしくはＮＡＩなどのＩＤ（それぞれのドメインの所有者によって許可される場合）、日付／時刻、または単調カウンタ値が利用可能であるが、日付／時刻は利用可能でない場合のそのような単調カウンタ値、上記の環境情報がＳＤＭに収集されたときの任意のその他の関連する情報などの、ＳＤＭがＴＤ_DM、ＴＤ_DO、およびＴＤ_Domains(i)から収集する情報を連結することによってＴＰＥＳを生成することができる。この要求は、

と表され得る。

ＳＤＭは、ＴＰＩＡおよびＴＰＥＳに署名し、それらをＴＤ＊_{RO_Target}に転送することができる。ＳＤＭは、署名されたＳＣＡＲＤを含むこともでき、したがって、ＤＯは、そのＤＯがＳＣＡＲＤを調べることができなかった場合、いかなる初期ＴＤ＊_{RO_Target}にも頼る必要がない場合がある。ＳＣＡＲＤは、ＲＯが、ＳＣＡＲＤ、ＴＰＩＡ、およびＴＰＥＳを調べた後で所有権取得を進める判断を行うことができるように、ＴＰＩＡおよびＴＰＥＳとともにＲＯに送信されることができる。このメッセージングは、

と表され得る。

ＳＤＭからＴＰＩＡ、ＴＰＥＳ、およびＳＣＡＲＤを受信すると、ＴＤ＊_{RO_Target}は、ＳＤＭの公開署名鍵を用いてそれらを検査することによってそれらの完全性を検査することができる。次いで、ＴＰＩＡ、ＴＰＥＳ、ＳＣＡＲＤ、ユーザによって望まれるサービスを指示する目的情報要素（Ｐ）、および所有権取得メッセージの要求（ｒｅｑｕｅｓｔ＿ＴＯ）が、ＭＥに送信されてもよい。ＲＴＯプロセスが、完全なＴＳＩＭ能力のためにプロビジョニングされなければならないドメインに対するものである場合、ＴＳＩＭ機能についての署名されたＣｅｒｔ_TSIM（証明書）も、準備され、上記のパッケージとともに送信されてもよい。

ＴＳＩＭ機能のために使用される２つ以上の証明書が存在してもよい。１つは、ＣＥＲＴ＊_TSIM（初期ＴＳＩＭ機能）に関し、その他は、完全にインスタンス化されている、または更新されるＴＳＩＭ機能に関するものである。初期ＴＳＩＭ機能のための証明書は、ＤＭに関する証明書の構造にモジュール式に埋め込まれることができ、例えば、その証明書は、ＤＭからの機能である初期ドメインに組み込まれることができる。

ＲＯが、ＴＤ_ROが前もって少なくとも１つのＲＴＯを経た後でＲＴＯプロセスを実行するとき、そのＲＯは、ＣＥＲＴ＊_TSIMが初期ドメインで使用するためにのみ適切であり、ＴＤ_ROはもはやその初期ドメインではない場合があるので、もはやこの証明書を送信する必要がない場合がある。したがって、この場合、ＲＯは、更新された証明書ＣＥＲＴ_TSIMを送信する場合がある。

内容は、例えば、証明書の転送によって、またはＴＤ＊_{RO_Target}による使用の前に、初期ＴＤ＊_{RO_Target}がロードされるときにターゲットのＲＯが既に分かっている場合は、事前の構成によって利用可能にされた場合があるターゲットのＲＯの公開鍵（Ｋ＿Ｔａｒｇｅｔ＿ＲＯ＿ｐｕｂ）で暗号化されてもよい。ＴＳＩＭは、署名鍵Ｋ＿_TSIM-Signを事前にプロビジョニングされてもよい。この秘密署名鍵の公開鍵は、ターゲットのＲＯに事前に配布されてもよい。ＩＤ_MEは、ＴＤ＊_{RO_Target}がＴＨＳＭのＤＭのドメインＴＤ_DMから取得するＭＥのＩＤであり、ＴＤ_DMは、このＭＥのＩＤを安全に保有する。これは、

と表され得る。

第３の実施形態を参照すると、値ＭＰＩＡおよびＭＰＥＳが、メッセージに追加されてもよい。ＭＰＩＡは、ＭＴＥによってまとめられたＭＰＩＤ（THSM based on the configuration data）で計算されたダイジェストを含んでもよい。このダイジェストは、このダイジェストが、構成ファイルに事前に存在するか、またはＤＭとのリアルタイムの通信を介して伝達される、取得され証明された尺度に一致する場合にのみ証明されてもよい。完全性および環境の情報のＲＯの要求に従って、式２０は、ＳＤＭがＭＰＩＤおよびＭＰＥＳを正常に受信したという単純な指示を含んでもよい。これは、

と表され得る。

ＭＥは、上記のメッセージ全体をＲＯに転送することができ、これは、

と表され得る。

第３の実施形態を参照すると、メッセージは、ＭＰＩＡおよびＭＰＥＳを含む。

ＲＯは、そのＲＯの秘密鍵Ｋ_{Target_RO_Priv}を用いてＰａｃｋａｇｅ＿１０を復号し、ＭＥのＩＤを検査し、メッセージを解釈することができる。ＲＯは、ＳＣＡＲＤを解釈し、そのＲＯがＳＤＰからのこれらの条件に「同意（agree）」できるかどうかを調べることができる。ＲＯがＳＣＡＲＤに同意する場合、例えば、初期ＴＤ＊_{RO_Target}からの値ＴＰＩＡが、任意のサービスの認証情報または構成の制御がターゲットのＲＯのドメインＴＤ＊_{RO_Target}に提供される前の最初のＴＳＩＭの状態の全体を表すように解釈されてもよい。値Ｐは、ユーザによって望まれるサービスを指示するように解釈されてもよい。ＴＳＩＭに対応したＴＤ＊_{RO_Target}の場合には、ＭＮＯでありうるターゲットのＲＯは、ＴＰＩＡを、そのＲＯがＴＴＰから別途取得したＲＩＭ（Reference Integrity Metrics）値（ＲＩＭ_RO）と比較することによって、そのＴＰＩＡで指示されるそのＲＯが関心のあるドメインの完全性を検証することができる。

ＭＮＯは、ＷＴＲＵ／ＴＨＳＭの供給者によって例えばＴＴＰに提供される証明書によってＴＰＩＡの期待される値を知る能力を有する場合がある。第３の実施形態を参照すると、ＭＰＩＡおよびＭＰＥＳの期待される値が、ＭＴＥが信頼できるエンティティであり、その信頼性がＴＨＳＭによって証明されているという事実によって可能にされる証明プロセスによって前もって知られてもよい。

ターゲットのＲＯは、受信されたＴＰＥＳを検索し、ＲＯが、自らがＲＴＯプロセスをさらに進めることを許す状況において、ターゲットのＲＯが「同意できる（agreeable）」、例えば、ＴＰＥＳによって示されたような「周囲のシステム環境（surrounding system environment）」を有するＴＨＳＭシステム内にＴＤ＊_{RO_Target}があるのかどうかを評価することができる。

ＴＰＩＡ、ＴＰＥＳ、目的Ｐ、Ｒｅｑｕｅｓｔ＿ＴＯ、ならびに第３の実施形態を参照した場合のＭＰＩＡおよびＭＰＥＳを検査した後、ＭＮＯなどのターゲットのＲＯは、ターゲットのＲＯによって「所有権を取得される（taken ownership）」ことを要求している初期ＴＤ＊_{RO_Target}と、そのＴＤ＊_{RO_Target}を含むＴＨＳＭ全体とが、そのＲＯがＲＴＯプロセスをさらに進めることを許可するのに、また、いくつかの事前に指定された基本的なサービスを提供するためにＴＤ＊_{RO_Target}がそのＲＯと対話することをそのＲＯが許可するのに十分なだけ「信頼できる（trustworthy）」と判定する場合がある。

次に、ドメインが、鍵、より完全な構成、パラメータ、および実行ファイルを後でダウンロードすることができ、それらをインストールして、基本的な「初期」状態が可能にするよりも機能的になり、さらにターゲットのＲＯ（リモートの所有者）によって獲得または所有され、管理されるようになることができるようにＴＤ＊_{RO_Target}の所有権取得を実行するために、ターゲットのＲＯは、実行ファイルを含み得る構成信号（ＣＯＮＦＩＧ）を送信することができる。ＲＯは、ＴＤ_{RO_Target}が、受信されたＣＯＮＦＩＧに準じて、それらの構成、パラメータ、および実行ファイルをインストールする場合に、インストール後の状態と一致する場合がある、ＲＩＭ_TSIMと呼ばれるＴＳＩＭに関するＲＩＭも送信する。ＲＩＭ_TSIMは、ＴＤ＊_{RO_Target}上の安全なメモリ内に記憶されてもよく、将来のブート時にＴＳＩＭ機能の完全性を検査するために使用されてもよい。使用されるべきセキュリティ対策およびその他の設定の問題を指定するＤＰ（ドメインポリシー）が、このトランザクションに含められてもよい。

ＲＯ固有のＤＰ（ドメインポリシー）は、ＳＤＭによって保有され、ＴＨＳＭ上の特定のＲＯによって所有される１またはそれ以上のドメインをビルドおよび管理するための計画を表すＳＤＰ（システム全体のドメインポリシー）とは異なる場合がある。ＲＯ固有のＤＰは、その特定のドメインに固有であり、それに専用であるドメイン内のアプリケーションおよびセキュリティ対策のみを管理するポリシーまたは計画を含んでもよい。

一部のＲＯは、ＤＰが、その他のＲＯがＴＨＳＭ上で何がビルドまたは管理されることに「同意できる」のかに関する制約を課す規定も含み得るように、そのような方法でそれらのＲＯのＤＰを作成することができる。例えば、モバイルネットワークのオペレータ（ＭＮＯ＿Ａ）は、そのＴＤ_{MNO_A}（オペレータのターゲットのドメイン）が、ＤＰ_{MNO_A}のダウンロードおよびインストールの後で、例えば、ＴＨＳＭ上のその他のドメインの一部の状態および性質に関するＤＰ_{MNO_A}で指定された条件の一部が十分に満たされないことが認められない場合に、そのオペレータのサービスまたは活動に対する一組の制約によって管理されるような方法でそのオペレータのＤＰ_{MNO_A}を作成することができる。例えば、ＭＮＯは、ＴＤ_{MNO_A}が、ＴＨＳＭ内のより大きな環境を調べた後、同じＴＨＳＭ上にインストールされ、アクティブである、独自のアクティブ化されたＴＳＩＭ機能を有するその他のＭＮＯのドメインが存在することを発見する場合に、ＴＤ_{MNO_A}が、そのＴＤ_{MNO_A}のＴＳＩＭ機能を無効化するＤＰ_{MNO_A}を実装する場合がある。

ＴＤ＊_{RO_Target}は、Ｐ内の要求されたサービスに対応するようにしてそのＴＤ＊_{RO_Target}自身を構成するように要求されてもよい。例えば、ＲＯが、ＭＥに応答を送信することができ、メッセージの機密性が、公開鍵Ｋ_TSIM-Pubを用いて保護される。ＭＥは、このメッセージを、ＴＨＳＭ上のＴＤ＊_{Target_RO}に転送することができる。Ｃｅｒｔ_ROが、Ｔａｒｇｅｔ＿ＲＯの公開鍵Ｋ＿ＲＯ_-privを含み得る。ＲＯは、このとき、ＴＳＩＭに関するＲＩＭ（reference integrity metric）を送信することができる。ＲＯの応答は、

と表され得る。

ＴＤ＊_{RO_Target}は、メッセージを秘密鍵Ｋ_TSIM-Privを用いて復号し、ＣＡでＣｅｒｔ_ROを検査した後、その証明書内の公開鍵Ｋ_RO-Pubを用いてＲＯの署名を検証することができる。ＴＤ＊_{RO_Target}は、ＴＳＩＭアプリケーションに関する受信された基準の完全性の尺度ＲＩＭ_TSIMを安全に記憶することができる。ＴＤ＊_{RO_Target}は、ＩＤ_ROからＲＯのＩＤを検査し、ＲＯのポリシーＤＰ_ROを検査し、ＴＤ＊_{RO_Target}がＣＯＮＦＩＧの構成およびインストールの残りを続行し得るかどうかを判定することができる。ＴＤ＊_{RO_Target}は、ＣＯＮＦＩＧによって再構成を実行して「完全な（complete）」ドメインの状態に到達することができ、次に、そのＴＤ＊_{RO_Target}のＴＳＩＭ機能の測定された尺度が、ネットワークによって伝えられ、ＲＩＭ_TSIMで表される尺度と一致するかどうかを判定するための自己検査を実行する。ドメインＴＤ_{RO_Target}は、現在「完了（completed）」しており、もはや「初期」ではなく、したがって、表記からアスタリスク（＊）を取り除くこと。これは、

と表され得る。

完了したドメインＴＤ_Target _ROは、「ＲＴＯ成功およびドメイン完了（RTO success and domain completed）」ステータスメッセージをＭＥに送信することができ、ＭＥは、そのメッセージをターゲットのＲＯに転送することができる。これは、

と表され得る。

随意に、ＭＥは、例えばＷＴＲＵのスクリーンに表示される、電話が現在登録および認証情報のロールアウトの準備ができているというステータスメッセージをユーザに送信することができる。

ＭＥは、プラットフォームの再構成が正常に完了し、ＴＳＩＭの認証情報の登録の準備ができているというステータスメッセージをＲＯに転送することができる。ＴＤ_{RO_}Ｔａｒｇｅｔは、「ＴＨＳＭ＿ＴＤ_RO＿ＬＯＡＤ＿ＣＯＭＰＬＥＴＥ」状態に達している。このメッセージは、

と表され得る。

このＲＴＯプロトコルは、加入されたサービスを提供する３ＧＵＭＴＳネットワークのオペレータに加入者をＴＨＳＭの所有者またはユーザとして登録するためのプロトコルと、さらに、共有の秘密鍵Ｋおよび加入者のアイデンティティＩＭＳＩのダウンロードおよびプロビジョニングを含む、ＡＫＡ（authentication and key agreement）に関する認証情報のダウンロードおよびプロビジョニングのためのより後のプロトコルとの前触れとして役割を担ってもよい。

公開−秘密鍵の組のための証明書Ｃｅｒｔ_TSIMおよびＣｅｒｔ_ROは、それらが使用されるメッセージで伝達されてもよい。あるいは、ＴＤ_RO（ＲＯのドメイン）およびＲＯは、それらのそれぞれの証明書を信頼できる第三者から取得することができる。この取得は、

と表され得る。

別の代替的方法において、ＲＯの証明書Ｃｅｒｔ_ROおよびＴＨＳＭの証明書Ｃｅｒｔ_TSIMが使用されるメッセージの伝達の前に、ＲＯの証明書Ｃｅｒｔ_ROが、ネットワークからＭＥに伝達されることができ、ＴＨＳＭの証明書Ｃｅｒｔ_TSIMが、ＭＥからネットワークに伝達されることができる。したがって、通信が、本明細書に記載の暗号化されたメッセージの前に送信される場合があり、これらの通信は、

と表され得る。

これらの代替的な証明書の伝達の方法のそれぞれに関して、エンティティのＩＤが、公開暗号鍵が使用されるメッセージに付随する場合がある。

別の代替的方法において、公開鍵の代わりに対称的な鍵を使用することが、メッセージの機密性を保護するために使用されてもよい。どの場合も、送信者は、例えば、ＰＲＮＧ（擬似ランダム数生成器）を用いて対称的な鍵Ｋ_sを生成し、メッセージの機密性を保護するために公開鍵ではなくこの鍵を使用することができる。対称的な暗号鍵は、暗号化されたメッセージとともに受信者にやはり送信されることができ、対称的な暗号鍵は、公開鍵で保護される。したがって、受信者は、その受信者の秘密鍵を用いて鍵Ｋ_sにアクセスし、次に、その鍵Ｋ_sを使用してメッセージを復号することができる。

第２の実施形態を参照すると、ＴＨＳＭおよびＭＥは、第１の実施形態のＴＨＳＭおよびＭＥと異なる場合がある。ＭＥ自体またはＭＴＥなどのＭＥ内の信頼できるエンティティの代わりに、ＴＨＳＭが、ＭＥがブートするときにＭＥのコードの一部またはすべての完全性の検査を実行するように構成されてもよい。随意に、ＴＨＳＭは、ＭＥに関するブートコードの一部またはすべてを記憶することもできる。ＴＨＳＭは、外部のエバリュエータにＭＥの完全性を証明するように構成されない場合がある。ＴＨＳＭは、ブート時にＭＥのコードの完全性の「ローカルの（local）」検査を実行されるように構成されてもよい。

ＭＥに関する完全性の値は、起動プロセスで使用される場合があり、ＲＴＯプロセスで使用されない場合がある。ＭＥのセキュアブートの結果として生じるＭＥのコードおよび構成の状態を表す、ｍｅａｓ＿ＭＥによって表されるＭＥの完全性の測定値が、ＴＨＳＭのＤＭのドメインＴＥ_DMによって取得されてもよい。ＴＨＳＭのＴＤ_DMは、ｍｅａｓ＿ＭＥの有効性を検査することができるが、それをプラットフォームの証明に組み込まない場合がある。

第４の実施形態を参照すると、ＭＥは、例えば、ＴＣＧのＭＰＷＧの意味で信頼できるＭＥであってもよい。ＭＥは、ＭＴＭ（mobile trusted module）を含んでもよく、ストレージ、報告、測定、検証、および施行のための信頼のルートを提供するそのＭＥのトラストアンカーとしてＭＴＭを有するので信頼され得る。

図４および４Ａは、リモート所有権取得プロセスに関する例示的なコールフロー図を表す。例えば、図４および４Ａは、ＭＥ４０２、ＴＤ_DO４０４、ＳＤＭ４０６、ＴＤ＊_{Target_RO}４０８、およびターゲットのＲＯ４１０のうちの１またはそれ以上の間の例示的なコールを示す。図４および４Ａ内の矢印は、コールの元／先を表す場合がある。

図２および３に示されたように、ＳＤＭは、ＴＨＳＭに存在するシステム全体のドメインマネージャを含み、ＤＯの機能の一部を提供することができる。ＳＤＭは、デバイスにおけるすべてのドメインの設定を監督および調整して、ＳＤＰおよびドメイン固有のポリシーのあらゆる衝突が、ＤＯおよびその他のドメインのＲＯの代わりにＳＤＭによって折り合いを付けられるように試みられる限り、すべてのそのようなドメインが、ＳＤＰに準じて、およびドメイン固有のポリシーに従って動作し、互いに対話することを保証することができる。ＴＤ_DOは、ＴＨＳＭ内の必須のデバイス所有者ドメインを含んでもよい。ＴＤ_DOは、ＳＤＭを含んでもよく、したがって、ＴＤ_DOは、システムレベルのドメインポリシーを保守することができる。ＭＴＥは、ＭＥ側のポリシーマネージャＭＥ_PDMを含んでもよい。ＭＥ_PDMは、ＭＥ上でポリシーマネージャ機能を実行することができるが、ＴＨＳＭのＳＤＭの監督を受ける場合がある。ＭＥ＊_{Target_RO}は、許可されたリモートの所有者によるリモートの所有権に関する初期ドメインの設定を含んでもよい。ターゲットのＲＯは、ＭＥ＊Ｔａｒｇｅｔ＿ＲＯの所有権を要求するリモートの所有者を含んでもよい。

ＭＥは、完全なＭＴＭの機能を引き受けることができ、したがって、認識されたリモートの所有者によるＭＥ上のドメインのリモート所有権取得がサポートされる。第１の実施形態を参照して説明されたＲＴＯのものと似ているが、それらは、ＴＨＳＭとＭＥの両方で同じリモートの所有者によって所有されるドメインに対してＭＥ_PDMを介してＳＤＭによって最大限のポリシー制御が行われるので本質的に異なる。したがって、ＴＨＳＭ上のドメインも所有する同じリモートの所有者によって所有される任意のＭＥドメインの形成および管理は、ＳＤＭのポリシーに従うようにして行われなければならない。

引き続き図４を参照すると、４１において、基本コードのブートをＭＥ４０２によって完了することができる。４１５において、ＴＨＳＭが、安全にブートすることができる。ＴＨＳＭが、ＳＤＭが含まれるＤＯのドメインをロードすることができ、ＳＤＭは、１）ドメインのビルドに利用可能なリソース、および／または２）ユーザが受け入れ可能なドメインのリストを提供することができる。４２において、ＴＨＳＭが、そのＴＨＳＭのブートを完了することができる。４２５において、ＭＥが、そのＭＥのブートを完了することができる。４３において、ＭＥが、そのＭＥのブートが完了していることを指示することができる。このプロセス中に、ＤＭのドメインがビルドされることができ、任意的なＭＥ_U（ユーザのドメイン）もビルドされることができ、利用可能なリソースが調べられる。ＤＭのドメインは、ＭＥデバイスに関するドメインポリシーの最初の構成および規定を提供するＭＥ_PDMを含んでもよい。ＭＥ_DMの事前構成によって、このポリシーは、ＭＥのドメインとＴＨＳＭのドメインの間で、共通のリモートの所有者を有するＴＨＳＭ上のドメインおよびＭＥ上のドメインなどのドメインに関して、ＳＤＰのポリシーに一致するように作成されてもよい。

引き続き図４を参照すると、４３１において、自らの事前に構成されたドメインの有するＭＥが、「ブート完了（boot complete）」メッセージを送り、ＲＴＯを開始することができる。このメッセージは、ＤＭのドメインポリシーおよびＭＥ内の利用可能なリソースについての明示的な情報を含んでもよい。４４において、ターゲットのドメイン計画を含む、ＲＴＯを開始する要求を送信することができる。４５５において、ＲＴＯ開始要求を受け入れるか、または拒否するのかのいずれかの決定を、ＴＤ＊_{Target_RO}４０８によって行うことができる。４５において、ＲＴＯが開始されるべきかどうかを指示するメッセージを送信することができる。あるいは、４５６において、ＲＴＯは、ＴＤ＊_{Target_RO}４０８を発端とする場合がある。４５１において、ＴＤ＊_{Target_RO}４０８は、「ＲＴＯの最終ドメイン計画を開始する意図（intention to start RTO final domain plan）」を送信することができる。

ＳＤＭは、ＴＨＳＭのシステム全体のＤＳＰ（ドメインポリシー）を評価し、およびＭＥのドメインにどの制約が課されるか、または割り当てられるべきかを判定することによって、ＭＥブートメッセージに反応することができる。これらのポリシーの制約は、どのドメインが、それらの関連するリモートの所有者によってＭＥおよびＴＨＳＭ上で許容され得るかを含む場合がある。ＳＤＭは、同じリモートの所有者が知らされているドメインを含むＴＨＳＭ上のドメインを有するその同じリモートの所有者によって所有されるドメインに対して、どのシステム全体のリソースを使用することをＭＥが許されるのかを決定することができる。ＭＥ_PDMは、式７のメッセージによってこの情報を受信することができる。ＳＤＭは、その基本的なポリシーに対するポリシーの制約およびそのリソースのリストに対する許容可能なリソースも含めることができる。ＭＥ_PDMがこの情報を受信した後、ＭＥ_PDMは、ＭＥ上のリソースおよびドメインの管理に関する決定を行い、施行するという点で、すべてのそのような決定に関してＳＤＭから許可を得ることを必要とせずに特定の権限を行使することができる。

引き続き図４を参照すると、４６５において、プロセスを継続することができる。４６５において、以下、すなわち、ＳＤＰ、利用可能なリソース、ならびに／または受け入れ可能なドメインおよび／もしくは状態が、検査および／または評価されてもよい。４６において、「開始することのＯＫ（OK to start）」信号を送信することができる。４７において、ＴＰＩＡ、ＴＰＥＳ、ＭＰＩＤ、およびＭＰＥＳの要求を送信することができる。４７５において、ＳＤＭ４０６は、例えば、ドメインごとにＰＣＲの範囲にわたって既存のドメインからの完全性証明を収集／連結し、ならびに／またはＴＰＥＳ情報を収集および／もしくは連結することができる。

４７１において、ＭＰＩＤおよびＭＰＥＳの要求を送信することができる。４７６において、ＭＰＩＤおよびＭＰＥＳの要求に対する応答を、ＭＴＥによって処理することができる。４８において、ＭＰＩＤおよびＭＰＥＳを、署名鍵を用いた信頼の証拠とともに送信することができる。４８１において、ＴＰＩＡ、ＴＰＥＳ、ＭＰＩＤ、およびＭＰＥＳを、ＳＤＭ４０６からＴＤ＊_{Target_RO}４０８に送信することができる。４８５において、ＴＨＳＭが、ＭＰＩＤ（生データ）からダイジェストＭＰＩＡを計算し、ＭＰＩＡを検査することができる。受け入れ可能である場合、ダイジェストＭＰＩＡを、ＲＯに送信することができる。４９において、ＴＰＩＡ｜｜ＴＰＥＳ｜｜ＭＰＩＡ｜｜ＭＰＥＳ｜｜目的｜｜ＲＴＯの要求を送信することができる。

図４Ａを参照し、ＲＴＯプロセスを続けると、４１０において、ＴＰＩＡ｜｜ＴＰＥＳ｜｜ＭＰＩＡ｜｜ＭＰＥＳ｜｜目的｜｜ＲＴＯメッセージを、ターゲットのＲＯ４１０に送信することができる。４１８において、ターゲットのＲＯ４１０が、例えば、以下、すなわち、ＴＰＩＡ、ＴＰＥＳ、ＭＰＩＡ、ＭＰＥＳ、および目的を検査すること、ＲＩＭＴＤＲＯに対して初期ドメインの信頼性を判定すること、許容場合に関してＤＰを調べること、または完全なドメインの状態をビルドするためのＣＯＮＦＩＧを生成することのうちの１つまたは複数を実行することができる。

上記の方法の代替的方法は、ＴＤ＊_{Target_RO}４０８が、ＭＰＩＡおよびＭＰＥＳの代わりにＭＥ信頼性の、ＳＤＭからの単純な指示を要求することであり、その場合、ＳＤＭは、ＴＰＩＡ、ＴＰＥＳ、およびＭＥの信頼性の指示を提供する。しかし、ＳＤＭは、ＭＴＥからのＭＰＩＡおよびＭＰＥＳをやはり要求し、受信する。

引き続き図４ａを参照すると、４１１において、メッセージＣＯＮＦＩＧ｜｜ＤＰ｜｜ＲＩＭ_TDRO｜｜ＲＯを送信することができる。４１２において、ＣＯＮＦＩＧ｜｜ＤＰ｜｜ＲＩＭ_TDRO｜｜ＲＯメッセージを転送することができる。４２８において、ドメインをビルドしおよび構成することができ、完全性をＲＩＭ_TDROと照合することができる。加えて、ＴＤ＊_{Target_RO}の所有権を取得することができ、したがって、そのＴＤ＊_{Target_RO}をＴＤ_{Target_RO}に変換する。４１３において、ドメイン完了メッセージを送信することができる。４１４において、ドメイン完了メッセージを転送することができる。

図５および５Ａは、（例えば、第４の実施形態に関連する）完全な証明をともなうリモート所有権取得に関する例示的なコールフロー図を表す。例えば、図５および５Ａは、ＳＤＭ５０２、ＴＤ_DO５０４、ＭＥ_PDM５０６、ＭＥ＊_{Target_RO}５０８、およびターゲットのＲＯ５１０のうちの１またはそれ以上の間の例示的なコールを表す。図５および５Ａ内の矢印は、コールの元／先を表す場合がある。５１において、基本コードブート完了メッセージを送信することができる。それに応じて、５１５において、ＴＨＳＭが、安全にブートし、ＳＤＭを含むＤＯのドメインをロードすることができる。５２において、ＴＨＳＭブート完了メッセージを送信することができる。それに応じて、５２５において、ＭＥが、ＭＥ_PDMが含まれるＤＭのドメインをロードすることと、利用可能なリソースを調べることとを含み得る安全なブートを行うことができる。ＭＥ_PDMは、ＳＤＰに一致するドメインポリシーおよび利用可能なリソースを指定する最初の構成を提供することができる。５３において、ＤＭのドメイン（ポリシー情報）およびＭＥ内の利用可能なリソースを含む、ＭＥのセキュアブートが完了しているというメッセージを送信することができる。５３１において、「ＭＥのブートが完了（ME boot is complete）」メッセージをＳＤＭ５０２に転送することができる。５３５において、ＳＤＭ５０２が、例えば、システム全体のポリシーを評価し、ＭＥに対する許されるドメイン、リソース、およびポリシーの制約を判定することができる。５４において、ドメインポリシーの制約および／または許可されるリソースに関する情報を提供するメッセージを送信することができる。５４５において、ポリシーの制約を基本的なポリシーに付け加えることができ、必要に応じて、リソースのリストを修正することができる。

図５および５Ａの要素５５乃至５１１は、図４および４Ａに示された要素４５乃至４１４と同様である場合がある。値ＭＰＩＡおよびＭＰＥＳの評価は、式１４から１９の評価と同様である場合がある。ＭＥは、ＭＴＭに対応している場合があり、生データＭＰＩＤだけでなく、自身でダイジェストＭＰＩＡを計算するように構成されてもよい。ＳＤＭによって送信された更新されたポリシーの制約が、禁止されたドメインまたはドメインポリシーが具現化されないように検査されてもよい。ポリシーの検査および評価は、ＭＥ_PDMによって実行されてもよい。

５５において、ターゲットのドメイン計画を含み得る、ＲＴＯを開始する要求を送信することができる。５５５において、ＭＥ_PDMによるＲＴＯの要求を受け入れるか、または拒否するのかのいずれかの決定を行うことができる。５５１において、ＲＴＯが開始されるべきかどうかを指示するメッセージを送信することができる。代替的方法では、５５６において、ＲＴＯを開始する意図は、ＭＥのターゲットを発端とする場合がある。５６において、ＲＴＯを開始する意図のメッセージを送信することができる。５６５において、以下、すなわち、１）拡張されたドメインポリシー、および／または２）拡張されたポリシーに従った利用可能なリソース、受け入れ可能なドメイン、および状態を検査しおよび／または評価することができる。５６１において、ＲＴＯを開始することが受け入れ可能であることを指示するメッセージを送信することができる。５７において、設定されるＭＥのドメインからのＭＰＩＡおよびＭＰＥＳの要求を送信することができる。５７５において、ドメインごとにＰＣＲの範囲にわたる既存のＭＰＩＡ（ドメインからの完全性証明）の収集および連結を実行することができ、ＭＰＥＳ情報の収集および連結も、実行することができる。５８において、ＭＰＩＡおよびＭＰＥＳを送信することができる。５９において、ＭＰＩＡ｜｜ＭＰＥＳ｜｜目的｜｜ＲＴＯ要求を送信することができる（メッセージの完全性および機密性は、証明された公開／秘密鍵によって保護することができる）。５９５において、ターゲットのＲＯ５１０が、例えば、以下、すなわち、ＭＰＩＡ、ＭＰＥＳ、および目的を検査すること、ＲＩＭ_TSIMに対して初期ドメインの信頼性を判定すること、許容場合に関してＤＰを調べること、または完全なドメインの状態をビルドするためのＣＯＮＦＩＧを生成することのうちの１つまたは複数を実行することができる。５１４において、メッセージＣＯＮＦＩＧ｜｜ＤＰ｜｜ＲＩＭ_TSIM｜｜ＲＯを送信することができる。５１５において、ドメインをビルドし、および構成することができ、完全性をＲＩＭ_TDROと照合することができる。加えて、ＭＥ＊_{Target_RO}の所有権を取得することができ、したがって、そのＭＥ＊_{Target_RO}をＭＥ_{Target_RO}に変換する。５１１において、ドメイン完了メッセージを送信することができる（署名され、完全性を保護される）。ＭＥは、ターゲットのＲＯと直接通信することができ、したがって、図３および３Ａに示されたメッセージ転送のようなメッセージ転送は、使用されない場合があり、メッセージの数を削減することができる。ＭＥとターゲットのＲＯの間のメッセージングにおける公開／秘密鍵交換のための必要とされる証明書に関する詳細は、初期のエンジンの信頼性の検証のためのＲＩＭの証明書に関する詳細とともに、図５に示されていない。

図６は、ＴＨＳＭの例示的な状態の定義、遷移、および制御点の定義を表す。例として、例えば特許文献１で定義された定義および基本的な機能を有するＭＣＩＭ（M2M Communication Identity Module）に関するライフサイクルが、本明細書において定義されている。ＴＨＳＭは、ＭＣＩＭの状態の定義および遷移を含む機能および特徴を改善し、汎用的にすることができる。

参照符号６０１において、ＴＨＳＭは、ブート前の状態にある場合がある。第１のユーザがＴＨＳＭの電源をオンにすることができ、ＴＨＳＭが安全にブートすることができ、ＴＨＳＭは状態６０２にある場合がある。６０２において、ＤＭおよびＤＯが、初期状態で存在する場合がある。ＤＭドメインを、事前に構成されたファイルからビルドすることができ、ＴＨＳＭは、状態６０６にある場合がある。６０６において、ＴＨＳＭは、ＴＤ_DMがロードされ得るブート後２状態にある。６０６から、ＤＯドメインを、事前に構成されたかまたはダウンロードされたファイルからビルドすることができ、ＴＨＳＭを状態６０５にする。６０５において、ＴＨＳＭは、ＴＤ_DOドメインがビルドされ得るが、ＴＤ_UまたはＴＤ_ROはロードされない場合がある、ブート後３状態にある場合がある。状態６０５から、ＳＤＭ（ＤＯのドメイン）が、ユーザのドメインをロードすることができ、ＴＨＳＭを状態６０４にする。６０４において、ＴＨＳＭは、ＴＤ_Uがロードされるが、ＲＯドメインはロードされない場合がある、ブート後状態２ａにある場合がある。状態６０５から、初期ＲＯドメインをＳＤＰに基づいてビルドすることができ、ＴＨＳＭを状態６０７にする。６０７において、ＴＨＳＭは、ＴＤ_ROおよびＴＤ_DOがロードされたが、ＴＤ_Uはロードされない場合がある、ブート後状態４にある場合がある。状態６０７から、ＴＤ_DO（ＳＤＭ）は、ＴＤ_Uをロードすることができ、ＴＨＳＭを状態６０８にする。６０８において、ＴＨＳＭは、ロードされたＤＯ、ＤＵ、およびＲＯドメインを有する場合がある。

状態６０１から、ユーザが電源をオンにすることができ、ＴＨＳＭを安全にブートすることができ、ＴＨＳＭを状態６０３にする。６０３において、ＴＨＳＭが、記憶された構成をロードすることができ、記憶された構成は、もっとも最近の電源オフの前の構成であったものとなる。状態６０３から、構成を変更するブート後のトランザクションを行うことができ、ＴＨＳＭを状態６１０にする。６１０において、ＴＨＳＭは、１またはそれ以上の既にアクティブな状態が、非アクティブになる状態にある。６０３から状態６１０に到達するプロセスと同様に、ＴＨＳＭは、ＴＨＳＭが１またはそれ以上のアクティブなドメインを有する状態６０９にある場合がある。状態６０９から、遷移が、構成変更イベントの結果として起こる場合があり、ＴＨＳＭをやはり状態６１０にする。

状態６０４、６０５、６０７、および６０８において、ＴＨＳＭは、新しいポリシーおよび／もしくは実行ファイルを用いて再構成されるか、または非アクティブ状態に遷移する場合がある。加えて、状態６０５において、ＳＤＰを記憶することができる。

ドメイン管理のための第１の方法において、ドメインの所有者からのポリシー、すなわち、ＳＤＰ（システム全体のドメインポリシー）は、非常に制限的および「静的（static）」である場合があり、新しいドメインの活動または目的について厳格な規則を有する場合がある。これらのポリシーは、あらゆる新しいドメインの登録または既存のドメインの更新をＲＯに伝える必要性を少なくする傾向がある場合がある。

ドメイン管理のための第２の方法において、ＳＤＰは、より制限的でなく、活動および目的の観点でより柔軟性を認める場合がある。あらゆる新しいドメインの登録およびあらゆるドメインの変更を、既存のドメインの所有者に報告することができる。これは、プラットフォームとＲＯとの間の最初の、および後に続くネゴシエーションが行われ得るポリシーの施行のより動的なシステムをもたらす場合がある。

ドメイン管理のための第１の方法を参照すると、ＳＤＰは、事前に構成されたリストで例外なく許可されるドメインを指定することができる。このリストは、ＲＯの種類、および（それぞれの種類に関して）いくつ許容されるかに関する情報を含んでもよい。リストは、ＲＯがそれらのＲＯのドメインを設定した後、それらのＲＯが提供することができるサービスの種類も含んでもよい。見込まれるＲＯは、リストによって指示された基準を満たすＲＯである場合がある。ＲＯは、リストおよびポリシーの制約などの条件について、例えば、式９に示されたように、ＲＴＯプロセスの一部として警告され得る。ＲＯは、ＳＣＡＲＤを受信すると、そのＲＯが問題のプラットフォームまたはデバイスのステークホルダになりたいか否かを独自に判断することができる。ＲＯに送信される条件は、ドメインの種類およびそれらの目的を含み得るが、その他のＲＯのアイデンティティを保護するために、いかなるその他のＲＯのリストの実際の名称も含まない場合がある。ＲＯがＲＴＯを完遂すると決定する場合、ポリシーからのいかなる逸脱も、このＲＯ、またはプラットフォーム上で現在アクティブなすべてのその他のＲＯ、または将来アクティブになる場合があるすべてのその他のＲＯよって許されないことを保証することができる。結果として、ＲＯは、行われ得るその後のＲＴＯを警告する必要がない場合があり、および警告されない場合がある。

ドメイン管理のための第２の方法を参照すると、いかなる特定のＲＯの種類も特定しない、どのリモートの所有者が許可されるかなどの比較的広い制約のみと、ＲＯからＳＤＭへのより多くの情報の要求またはいくつかのネゴシエーションなどのより多くの対話を許可するポリシーとを、ＲＴＯプロセス中に実行することができる。ドメインの構成が変わるときに、ＳＤＭとすべてのＲＯとの間で継続中の協調（collaboration）が存在する場合もある。したがって、最初のおよびさらには後に続くネゴシエーションは、ＲＯ／ＳＤＭの変遷の一部として起こる場合がある

ＲＴＯプロセスの一部として、ＲＯは、構成およびその信頼性に関する、第１の方法の場合と比較してより広い情報を含み得るＴＰＩＡ、ＴＰＥＳ、およびＳＣＡＲＤなどの、そのＲＯが必要とする証明およびポリシーの条件の情報を与えられる場合がある。既存のドメインの構成に基づいて、ターゲットのＲＯは、ＲＴＯを継続するか否かを決定することができる。ターゲットのＲＯが所有権を取得しないと直ちに決定しない限り、ＳＤＭとのネゴシエーションプロセスが、続いて起こる場合がある。例えば、ＳＤＭは、ターゲットのＲＯから、ターゲットのＲＯのドメインがアクティブである間に、どのドメインの種類および付随するサービスがアクティブであることができるか、またはそのターゲットのＲＯが拒絶するドメインの種類がアクティブになろうとしている場合に、どの手順に従うべきかを要求する場合がある。ＲＯは、例えば、特定のその他のドメインの種類、もしくはさらには特定のその他のＲＯによって所有されるドメインがアクティブになるか、もしくはアクティブになろうとしているときに、そのＲＯ自身のドメインが非アクティブにされることを要求する場合があるか、またはＲＯは、そのＲＯ自身のドメインがアクティブのままではあるが、性能またはケイパビリティ（capability）が縮小されていることを要求する場合がある。ＳＤＭは、ＲＯから、どのイベントの発生をそのＲＯが警告されるべきかを要求する場合がある。そのようなイベントは、そのＲＯが拒絶するドメインの種類がアクティブまたは非アクティブになることを含み得る。ＲＯは、そのＲＯ自身のドメインがアクティブである間、その他のドメインの種類、または特定のその他の所有者によって保有されるドメインがいかなる活動も完全に禁止されることを要求する場合がある。

ＳＤＭは、そのような条件を受け入れるかまたは拒絶することを決定することができる。ポリシーの要件の幅広い組を用いて動作するが、ＳＤＭは、ＲＯからの要求を受け入れることが「静的な」ＳＤＰ（システムのドメインポリシー）の字義または意図にいまだに従うことができるかどうかを判断する自由度および意味論的ケイパビリティを有することができる。

図７は、ＲＯドメインが到達し得る例示的な状態、および動的に管理された環境内で遷移が発生し得る条件を表す。７０１において、ｎｕｌｌ状態が存在する場合があり、例えば、ＲＯが、ビルドされていない場合がある。状態７０１から、初期ＲＯドメインをＳＤＰに準じてビルドすることができ、ＲＯドメインを状態７０２にする。７０２から、ＲＯがＴＰＩＡ、ＴＰＥＳ、およびＳＣＡＲＤを獲得することを含むＲＴＯプロセスを実行することができる。さらに、ＲＯは、ＲＴＯの条件を受け入れることができ、ＲＯドメインを状態７０３にする。７０３から、新しくアクティブになったドメインとのポリシーの衝突が存在すると判定される場合があり、それに応じて、ＲＯドメインの機能を縮小するか、またはＲＯドメインを非アクティブにし、ＲＯドメインを状態７０４にする。やはり７０３から、ＲＯドメインは、更新されたポリシー／構成の変更を受信する場合があり、その結果、ＲＯドメインは修正された構成および／または更新されたポリシーの制約を持つことになる。７０６から、新しくアクティブになったドメインとのポリシーの衝突が存在すると判定される場合があり、それに応じて、ＲＯドメインの機能を縮小するか、またはＲＯドメインを非アクティブにし、ＲＯドメインを状態７０４にする。やはり７０３から、新しいソフトウェアコンポーネントが、ダウンロードまたはＲＴＯによって導入される場合があり、ＲＯドメインの修正された／拡張された状態をもたらし、ＲＯドメインを７０５にする。７０５から、新しくアクティブになったドメインとのポリシーの衝突が存在すると判定される場合があり、それに応じて、ＲＯドメインの機能を縮小するか、またはＲＯドメインを非アクティブにし、ＲＯドメインを状態７０４にする。

参照符号７１１に表されるように、状態７０２、７０３、７０４、７０５、または７０６のＲＯドメインは、ｎｕｌｌになる、例えば、ＤＯおよびＲＯなどによって削除される場合がある。７４１に表されるように、非アクティブな／機能を縮小されたＲＯドメインは、例えば、ＲＯドメインを状態７０４に移した原因の衝突を解決することによって状態７０３、７０５、または７０６に移ることができる。７５１に表されるように、状態７０５のＲＯドメインは、状態７０３、７０４、または７０６に移る場合がある。７６１に表されるように、状態７０６のＲＯドメインは、状態７０３、７０５、または７０６に移る場合がある。

ＲＯドメインの管理に関して、動的なドメイン管理の一部として許可され得ることは、ネゴシエーションの要件が、イベントが発生する際に変わることである。例えば、ＲＯは、前は拒否すべきであった別のＲＯによって提供される特定のサービスが、そのＲＯがもはやそのサービスと競う必要がないと判断した結果として、いまだに許容されると判断する場合がある。経時的なビジネスモデルに対する変更が、期待されるＲＯによるネゴシエーションの戦略およびポリシーに影響を及ぼす場合がある。動的なポリシーの構造を使用するＳＤＰは、そのような戦略の変更に対応するように作成され得る。

これに限定されないが、スマートビリング（smart-billing）と組み合わされたＭ２Ｍ位置追跡などのサービスにおいて、ＲＯの好ましいローミングパートナーシップまたは閉じたグループを形成する場合がある。同様のまたは異なるサービスを提供する異なるオペレータが、互いに組み合うそのようなグループ化されたサービスは、好ましい閉じたグループにつながる場合がある。サービス、オペレータ、またはそれらの両方のそのような好ましいグループは、セットになったサービスまたはセットになった契約として提示され得る。

第１の例において、パッケージが、それが世界中を移動するときに追跡される場合がある。何百万個ものそのような位置追跡デバイスを利用することができる。パッケージが大陸を横断するとき、そのパッケージは、異なる国の異なるオペレータによって接続を提供される。したがって、接続するために、ユーザは、複数のローミングプロファイルに加入する必要がある場合がある。さまざまなリモートのオペレータにまたがるこれらのローミングプロファイルは、各ドメインがリモートのオペレータによって所有および管理されるので、ドメイン間ポリシーとして管理される。これらのポリシーは、ローミングに基づくソリューションをサポートする代わりに、新しいサービスプロバイダへの完全な移管をサポートするためにやはり施行される場合がある。

第２の例において、スマートメータのオペレータと位置追跡のオペレータとの間のパートナーシップが説明される。これらのドメインは、異なるオペレータによって所有および運用される場合がある。ビジネスパートナーシップまたはユーザの好みによって、ドメインが、複合プロファイルをサポートするために組み合わされ得る。労働、保管、または駐車などのリソースの使用に基づく課金のために、スマートビリングが、パッケージの追跡と一緒に使用され得る。別個のカテゴリーに入る共存するサービスのそのような場合は、ドメイン間ポリシー管理のサポートを使用する場合がある。

ＩＤＰＭ（ドメイン間ポリシーマネージャ）は、ドメインのグループの振る舞いを統治するポリシーを管理することができる。ＩＤＰ（Inter Domain Policy）を、ＲＴＯプロセス中に各ＲＯによってダウンロードすることができる。ＩＤＰを、各ＲＯによって署名された証明書によって認証することができる。これらの証明書を、ＩＤＰと一緒に発行することができる。あるいは、これらのポリシーを、外部のサービスディーラーによって証明およびダウンロードすることができる。好ましいオペレータのリストを作成することに関心があるデバイスのユーザまたはデバイスの所有者は、ＩＤＰを作成することができる。ＩＤＰＭは、候補のポリシーの受け入れ可能な共通部分、またはＩＤＰを選択する優先度を評価し、次いで、結果として生じるポリシーを施行することによってこれらのポリシーを処理することができる。

ＩＤＰＭを、あるいは、ＳＤＭの機能の１つとして、またはＴＨＳＭにロード（ビルド）もしくはダウンロードされ得る別個のエンティティとしてＳＤＭに追加することができる。

証明プロトコルの一部として、ＴＤ_ROは、完全なＴＰＩＡ、ＴＰＥＳ、およびＳＣＡＲＤを送信する代わりに、これらの測定値のハッシュをＲＯに送信することができる。ＲＯは、それ自体で、またはＴＴＰによってのいずれかで、そのようなハッシュを検証する手段を有し、それによって、ＴＤＲＯおよび周囲のシステムの実現性の評価を行うことができる。この方法は、例えば特許文献１で規定された準自律的検証ＳＡＶ（Semi Autonomous Validation）と同様となりうる。ＴＰＩＡ、ＴＰＥＳ、およびＳＣＡＲＤの測定値のうちの任意の１つまたは２つを、証明のフェーズの間に送信することができる。

ＴＨＳＭは、ＭＥの一部として一体的に埋め込まれる場合がある。そのようなデバイスに関するＲＴＯプロセスは、そのプロセスがＭＥとＴＨＳＭの間のインターフェースを取り除くので、簡素化することができる。

特徴および要素が特定の組み合わせで上記説明されているが、それぞれの特徴または要素をその他の特徴および要素なしに単独で、またはその他の特徴および要素とさまざまに組み合わせて、もしくは組み合わせずに用いられてもよい。本明細書で提供された方法またはフロー図は、汎用コンピュータまたはプロセッサによる実行のためにコンピュータ可読記憶媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアで実装されてもよい。コンピュータ可読記憶媒体の例は、ＲＯＭ（リードオンリメモリ）、ＲＡＭ（ランダムアクセスメモリ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびＤＶＤ（デジタル多用途ディスク）などの光学媒体を含む。

適切なプロセッサは、例として、汎用プロセッサ、専用プロセッサ、通常のプロセッサ、ＤＳＰ（デジタル信号プロセッサ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つもしくは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ＡＳＩＣ（特定用途向け集積回路）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）回路、任意のその他の種類のＩＣ（集積回路）、および／または状態機械を含む。

ソフトウェアに関連するプロセッサが、ＷＴＲＵ（無線送受信ユニット）、ＵＥ（ユーザ機器）、端末、基地局、ＲＮＣ（無線ネットワークコントローラ）、または任意のホストコンピュータで使用するための無線周波数トランシーバを実装するために使用されてもよい。ＷＴＲＵは、カメラ、ビデオカメラモジュール、テレビ電話、スピーカーフォン、振動デバイス、スピーカー、マイクロホン、テレビトランシーバ、ハンズフリーヘッドセット、キーボード、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、ＦＭ（周波数変調）ラジオユニット、ＬＣＤ（液晶ディスプレイ）ディスプレイユニット、ＯＬＥＤ（有機発光ダイオード）ディスプレイユニット、デジタル音楽プレーヤー、メディアプレーヤー、ビデオゲームプレーヤーモジュール、インターネットブラウザ、および／または任意のＷＬＡＮ（無線ローカルエリアネットワーク）もしくはＵＷＢ（超広帯域）モジュールなどの、ハードウェアおよび／またはソフトウェアで実装されたモジュールに関連して使用されてもよい。

ＩＩ．加入に基づくサービスにアクセスするための登録および認証情報のロールアウト
デバイスのユーザは、加入に基づくサービスのプロバイダと加入関係を創りたいと望む場合がある。例えば、図１のデバイス１００、１１０、もしくは１２０などのＵＥ、または図２のＵＥ２００のユーザが、リモートの所有者によって提供される加入に基づくサービスの加入したユーザとして登録することを望む場合がある。加入に基づくサービスの提供は、第三者によって円滑にされる場合がある（例えば、第三者が、リモートの所有者の代わりに、加入に基づくサービスをユーザに販売する場合がある）。リモートの所有者は、デバイス上のドメインの所有権を取得している場合があり、このドメインは、ＲＴＯプロセスに関連して上記説明されたように、リモート所有者ドメインと呼ばれる場合がある。さらに、ユーザが、デバイス上のドメインの所有権を取得している場合があり、このドメインは、ユーザドメインと呼ばれる場合がある。

ユーザが加入に基づくサービスにアクセスするためには、登録および認証情報のロールアウトが、行われる必要がある場合がある。登録および認証情報のロールアウトは、ユーザをリモートの所有者に加入に基づくサービスの加入したユーザとして登録すること（そのようなサービスが、リモート所有者ドメインを通じてリモートの所有者によって行われ得る）、ユーザが加入に基づくサービスを加入したユーザとして使用することを可能にする認証情報をリモートの所有者から取得すること、および／または認証情報をリモート所有者ドメインに記憶することのうちの１つまたは複数を含んでもよい。認証情報は、ユーザがデバイスを通じて、加入に基づくサービスを使用することを可能にする。認証情報の用語は、通常の認証情報（例えば、鍵、ＩＤ、証明書など）を含んでもよい。認証情報の用語は、加入管理機能のために使用される実行ファイルおよびアプレットなどのその他の状況に即したデータおよびアプリケーションを含んでもよい。

本明細書において開示されたシステムおよび方法は、ユーザが１つのデバイスまたは複数のデバイスによって、複数の加入に基づくサービスにアクセスすることができることを想定する。例えば、図１および２に関連して、ならびにＲＴＯプロセスに関連して上記説明されたように、デバイスは、異なるリモートの所有者によって所有され得る複数のドメインを有する場合がある。ユーザは、複数のリモートの所有者からの複数の加入に基づくサービスに加入することができる。

登録および認証情報のロールアウトは、リモートの所有者がリモート所有者ドメインの所有権を取得してから長い時間が経ってから行われてもよい。無線電話ケイパビリティを有する無線デバイスが、例として使用されてもよい。複数の無線キャリアが、デバイス上の複数のドメインの所有権を取得した場合がある（例えば、各無線キャリアがリモートの所有者である）。例えば、無線キャリア１が、リモート所有者ドメイン１の所有権を取得した場合があり、無線キャリア２が、リモート所有者ドメイン２の所有権を取得した場合がある。しかし、ユーザは、無線キャリア１の加入に基づくサービス（例えば、無線電話サービス）に関連する登録および認証情報のロールアウトを開始した場合があるが、無線キャリア２の加入に基づくサービスに関連する登録および認証情報のロールアウトは開始しなかった場合がある。例えば、無線キャリア１は、無線電話サービス全体に関して無線キャリア２よりもよい契約をユーザに提供した場合がある。後で（例えば、数日、数か月、数年）、ユーザは、無線キャリア２の加入に基づくサービス（例えば、無線電話サービス）に関連する登録および認証情報のロールアウトを開始することができる。例えば、そのとき、無線キャリア２が、長距離電話に関して無線キャリア１よりもよい契約を提供する場合がある。ユーザは、両方に関して登録および認証情報のロールアウトが完了しているので、両方の加入に基づくサービスを使用することができる。例えば、ユーザは、市内電話のために無線キャリア１の無線電話サービスを使用し、長距離電話のために無線キャリア２の無線電話サービスを使用することができる。この例は、どちらのリモートの所有者もそのような構成を禁じる規則を設定しなかった（例えば、ＲＴＯプロセスを参照）と仮定する。この例は、登録および認証情報のロールアウトが、リモートの所有者がリモート所有者ドメインの所有権を取得してから長い時間が経ってから行われる場合があることをやはり表す。

登録および認証情報のロールアウトプロセスに含まれるエンティティは、以下、すなわち、ユーザ、ユーザドメイン、リモートの所有者、リモート所有者ドメイン、第三者、または準自律的検証を容易にするコンポーネント（例えば、システム全体のドメインマネージャ）のうちの１つまたは複数を含んでもよい。登録および認証情報のロールアウトに関して、エンティティは、以下のような属性を有してもよい。

ユーザは、加入に基づくサービスなどのサービスに加入することを試みるデバイスのユーザであってもよい。そのような加入に基づくサービスの例は、金融サービス、セルラ通信サービス、インターネット接続サービス、音楽／ビデオ／マルチメディア加入サービス、本人確認サービス、位置に基づくサービス、電子メール／メッセンジャー／ソーシャルネットワークサービス、電子ブックサービス、ゲームサービスなどを含んでもよいが、これらに限定されない。ユーザは、デバイスの所有者でもあってもよい。ユーザは、登録および認証情報のロールアウトを開始してもよい。開始は、ユーザが個人データおよび／または通常のログイン情報を送信することを含んでもよい。ユーザは、例えば、ユーザが加入している／加入しようとしている加入に基づくサービスに関連するアクションに関連するとき、加入者と呼ばれることもある。

ＴＤ_U（ユーザドメイン）は、ユーザの機能に関連するデバイス上のドメインであってもよい。ユーザドメインは、任意的なドメインであってもよい。ユーザドメインは、本明細書において説明されたようにＴＨＳＭの一部であってもよい（例えば、図２を参照）。ユーザドメインは、プラットフォームの最初のブートシーケンス中に作成され、その機能を提供されてもよい。ＴＤ_O（所有者ドメイン）は、ユーザドメインを含まない構成のためにＴＤ_Uの機能を実行してもよい。ユーザは、ＩＤ_U（ユーザ名）、ＰＷ_U（パスワード）、およびＲＥＧＤＡＴＡ_U（個人登録データ）を供給されることによってＴＤ_Uを用いて登録を開始してもよい。ＴＤ_Uは、ユーザ登録の一部としてＰＩＤ＿Ｕ（プロセスＩＤ）を生成してもよい。この情報は、登録を開始し、認証情報のロールアウトを要求するのに使用されてもよい。例えば、この情報は、特定の要求（例えば、特定の登録および／または認証情報のロールアウト要求）に関連付けられる場合があり、登録および／または認証情報のロールアウトのための異なるセッションまたはプロセスを識別するか、またはそれらに印を付けるために使用されてもよい。ユーザとユーザドメインは、ＭＥを介して通信してもよい。事前にプロビジョニングされた鍵（例えば、機密性のための）Ｋ_{temp_C}および（例えば、完全性／認証のための）Ｋ_{temp_I}が、ＭＥ／ＴＨＳＭインターフェースを介したメッセージングを保護するために使用されてもよい。非対称的な鍵の対が、ＭＥ／ＴＨＳＭインターフェースを介したメッセージングを保護するために使用されてもよい。ＭＥは、図８に関連して示されていない場合がある。ＴＨＳＭへのユーザの通信は、ＴＤ_Uを介して行われてもよい。

ＲＯ（リモートの所有者）は、デバイスを介してユーザに加入されたサービスを提供してもよい。リモートの所有者は、ユーザが加入したサービスを使用するために必要とされ得る認証情報を提供してもよい。認証情報は、リモート所有者ドメインとリモートの所有者との間の強力な秘密としての役目を果たすことができる認証鍵Ｋを含んでもよい。例として、ＲＯは、以下、すなわち、ＭＮＯ、その他の通信ネットワークのオペレータ（例えば、ＷＬＡＮおよびＷｉＭａｘなど）、電子メールサービスプロバイダ、インターネットサービスプロバイダ、ソーシャルネットワークサービスプロバイダ、デジタルコンテンツ（音楽、電子ブック、ビデオなど）プロバイダ、ゲームサービスプロバイダ、金融サービスプロバイダ、アプリケーションサービスプロバイダ（例えば、モバイル決済、モバイル発券、ＤＲＭ、モバイルＴＶ、位置に基づくサービスなどのサービスプロバイダ）、またはＩＭＳサービスプロバイダなどのうちの１つまたはそれ以上であってもよい。

ＴＤ_RO（リモート所有者ドメイン）は、リモートの所有者によって定義された機能を提供することができるデバイス上のドメインであってもよい。リモート所有者ドメインは、上記説明されたようにＴＨＳＭの一部であってもよい（例えば、図２を参照）。リモート所有者ドメインは、上述のＲＴＯプロセスに関連して説明されたＴＳＩＭ機能を有してもよい。リモート所有者ドメインは、リモートの所有者によって提供された認証情報を記憶してもよい。ＴＤ_ROは、ユーザドメインからＩＤ_UおよびＰＩＤ＿Ｕ（ユーザのＩＤおよびプロセスＩＤ）を受信し、登録および認証情報のロールアウト中にこの情報をさまざまに使用してもよい。

ＰＯＳ（point of sale or point of service entity）が、ユーザに対する加入に基づくサービスの販売／サービスを容易にする第三者であってもよい。ＰＯＳは、図８に関連して説明されるチケットによって販売を容易にすることができる。例として、ＰＯＳは、リモートの所有者の加入に基づくサービスを販売し、ならびに／またはその販売前および販売後の顧客サービスの義務を遂行する小売店（オンライン型、実店舗型など）であってもよい。

ＳＤＭ（システム全体のドメインマネージャ）、例えば、節Ｉで開示されたＳＤＭが、登録および認証情報のロールアウトの一部として、１またはそれ以上のプラットフォームに関連する証明情報を提供してもよい。例えば、登録および認証情報のロールアウト中に要求があると、準自律的な完全性の確認が、ＳＤＭによって行われてもよい。ＳＤＭは、ドメインのコンポーネントなど、ＴＨＳＭの一部であってもよい（例えば、図２を参照）。

登録および認証情報のロールアウトは、以下のうちの１つまたは複数を含んでもよい。
１）ＰＯＳが、チケットをユーザと関連付けることができる。チケットは、ユーザのＩＤを確立することができ、認証情報の要求がリモートの所有者に対してなされるときに当該チケットを示すことができる。チケット（例えば、ユーザに与えられるチケットなど）は、ＲＯによってＰＯＳに（例えば、事前に生成された組で）分配されてもよい。チケットは、登録および認証情報のロールアウトプロセスで使用されるべき情報を含んでもよい。例えば、情報は、「三つ組み（triple）」を含んでもよく、三つ組みは、識別子（例えば、ＩＭＳＩ）と、例えば、認証情報の要求がなされるときにリモートの所有者へのチャレンジ番号（challenge number）としての機能を果たす乱数（ＲＡＮＤ）と、チケットの認証値（ＡＵＴＨ）とを含んでもよい。
２）ユーザドメインが、ユーザの代わりに、登録を要求することができる。
３）ＰＯＳが、ユーザに関連する個人登録データとともに、リモートの所有者にユーザのアイデンティティを報告することができる（例えば、分配されたチケットが、国際移動体加入者識別番号−−ＩＭＳＩなどの識別子を提供することができる）。
４）ユーザが、識別子（例えば、ＩＭＳＩ）を用いて認証情報のロールアウトを要求することができる。
５）認証情報を、デバイスに（例えば、リモート所有者ドメイン）届けることができ、その認証情報は、加入サービスにアクセスするために使用されてもよい。リモート所有者ドメインは、加入サービスの管理においてＴＳＩＭ機能を提供することができる。

登録および認証情報のロールアウトを安全な方法で行うことができる。以下の事前の条件のうちの１つまたはそれ以上が、ユーザの登録および認証情報のロールアウトが安全な方法で行われるために充足され、および／または仮定される場合がある。
１）ＴＨＳＭ／ＭＥプラットフォームを信頼できる状態にあるとみなすことができ、ＲＴＯ（リモート所有権取得）プロトコルによって、事前に構成されたドメインを有するリモートの所有者によって要求されるときに、プラットフォームの構成の状態またはその一部を報告することができる。デバイスは、「完全に信頼できる（completely trusted）」プラットフォームのコンポーネントとみなされない場合があるＭＥを含んでもよい。ＭＥの信頼性をＴＨＳＭによって周期的に監視することができる。ＭＥとＴＨＳＭを接続するインターフェースは、概して、安全とみなされない場合がある。ＭＥは完全なＭＴＭの能力を有し、そのＭＥの完全性を証明することができると仮定してもよい。
２）以下の方法のうちの１つまたは複数で実装され得るプラットフォームの証明。
（ａ）ＴＰＩＡ、ＴＰＥＳ、およびＳＣＡＲＤの使用を含む証明の報告。例えば、ＲＴＯプロセス参照。
（ｂ）ＲＯに現在の構成のハッシュを送信することを含み得るリモートの検証のスケーリングされたバージョン。この種類の証明は、大量のデータを転送することを避けることを求めるときに使用されてもよい。
（ｃ）内部的な完全性の検査の実行、およびプラットフォームが安全であることの確認を提供することを含み得る準自律的検証。
３）認証情報をリモートでダウンロードすることができる。ＰＯＳが、ユーザをリモートの所有者に登録することに関与することができる。ＰＯＳとの通信は、以下の方法のうちの１つまたは複数で行われてもよい。
（ａ）ユーザがそのユーザの識別情報および登録データを送信するときに、ユーザはＯＴＡ（無線上）またはインターネットリンクを介してＰＯＳと通信することができる。
（ｂ）ユーザがハンドセットを用いて登録のログインステップを完了した後は、ユーザドメインが、登録および認証情報のロールアウトプロセスに関してＰＯＳとインターネットを介して通信することができる。
４）ＰＯＳを、チケット配布機能を処理するのに十分なだけ信頼できるとみなすことができる。したがって、ＰＯＳは、関連する証明書Ｃｅｒｔ_POSとともにＫ_POS-PrivおよびＫ_POS-Pubと表される証明された鍵の対の組を有することができる。これらは、それぞれ関連する証明書Ｃｅｒｔ_ROおよびＣｅｒｔ_TSIMをともなうリモートの所有者に関する鍵の組（Ｋ_{RO_Priv}、Ｋ_{RO_Pub}）およびＴＳＩＭに関する鍵の組（Ｋ_TSIM-Priv、Ｋ_TSIM-Pub）と併せて登録および認証情報のロールアウトにおいて使用されてもよい。
（ａ）ユーザとユーザドメインの間の通信が、ＭＥを仲立ちとして使用すると仮定することができ、ユーザによって使用されることを意図されたメッセージが、ハンドセットのスクリーン上に表示される。これらのメッセージは、それぞれ完全性および機密性の保護のための一時的な鍵Ｋ_{temp_I}およびＫ_{temp_C}を使用することができ、ＭＥが、ユーザのために解釈する（例えば、復号するおよび／または署名を検証する）ことができる。
（ｂ）登録および認証情報のロールアウトが、それが同じユーザまたは場合によっては複数のユーザからの複数の登録および認証情報の要求を可能にすることができるほど柔軟であり得る。例として、各ユーザは、所与のＴＤ_RO（信頼できるドメイン：trusted domain）に対して１つ（かつ１つだけ）の登録を確立することができるが、複数のそのようなドメインにわたって複数の登録を確立することはできない。しかし、複数の異なるユーザは、それぞれ、１つのそのようなドメインに対してそれらのユーザ独自の登録を有することができる。各ＴＤ_ROは、１人のＲＯを有することができるが、ＲＯは、各登録が異なるユーザに関する複数の登録を管理することができる。所与のＲＯが２つ以上のＴＤ_ROを所有することもできる。多数のユーザ、および場合によっては複数のリモートの所有者に対応する信頼できるドメインが存在する場合、プロセスＩＤが、例えば、ユーザドメイン、ＰＯＳ、およびリモートの所有者によって生成され、複数の登録に関連する曖昧性をなくすために使用され得る。所与の登録および認証情報の要求に関して、緊密に関連付けられる３つのプロセスＩＤ、すなわち、（ユーザドメインによる）ＰＩＤ＿Ｕ、（ＰＯＳによる）ＰＩＤ＿ＰＯＳ、および（リモートの所有者による）ＰＩＤ＿ＲＯが、生成され得る。ＰＩＤ＿Ｕは、ユーザドメインを識別するために、ＰＯＳかまたはリモートの所有者かのいずれかと通信するときにＴＨＳＭ内のエンティティによって使用され得る。これらのＩＤは、所与の登録プロセスを一意に識別するのに十分であり得る。
（ｃ）信頼できるエンティティ間の通信を、公開−秘密鍵の対を用いて保護することができ、公開鍵が、ＣＡ（認証局）により発行された証明書によって配布され得る。
（ｄ）登録および認証情報のロールアウト中、リプレーアタックを防ぐためにノンスを使用することができる。ノンスは、連続的に付番されてもよく、もしくはその他の方法で順次順序付けられてもよく、または連続したもしくはその他の方法で順次順序付けられた数を含んでもよい。記述的なノンスの指定が使用される特定の内部的なドメイン間対話は、連続的に付番されない場合がある。２つのエンティティ間の往復の通信に関して、送信された第１のノンスが、返信メッセージで（平文の）新しいノンスとともにその第１のノンスの送信元に返送される（平文でない）ことができる。返信のノンスを受信するエンティティは、その値が最初にそのエンティティによって生成され、したがって既知であり得ることを考えれば、それが平文で送信されることを必要としない場合がある。
（ｅ）署名を、例えば、本明細書においてはＳＨＡ−Ｘと表記されることがあるＳＨＡアルゴリズムの特定されないバージョンによって計算された固定ビット長の暗号学的ハッシュ値に適用することができる。

登録および認証情報のロールアウトを説明する方法を、ここで、図８を参照して明らかにすることができる。図８は、登録および認証情報のロールアウトプロセスを実装する例示的なコールフローを表す。コールフローは、式として表され得る。式は、それぞれのフローに関連する場合があるセキュリティ機能を含んでもよい。図８に示されるコールフローは、例示的であるように意図される。その他の実施形態が使用され得ることを理解されたい。さらに、フローの順序は、必要に応じて変更され得る。加えて、フローは不必要な場合は省略される場合があり、追加的なフローが追加される場合がある。

参照符号１において、ＰＯＳ３０が、リモートの所有者、ＲＯ４０に、ユーザ３２などのさまざまな認可されたユーザに配布され得る事前に生成されたチケットの要求を行うことができる。

２において、ＲＯ４０が、（例えば、Ｃｅｒｔ_POSで受信された）公開鍵Ｋ_POS-PubでＰＯＳの署名の有効性を検査し、ユーザ３２などのユーザを登録するときに使用され得るチケットのインデックス付けされた組を送信することによって応答することができる。

インデックス付けされた組の中の各チケットは、三つ組みを含んでもよい。

Ｔｉｃｋｅｔ_i＝（ＩＭＳＩ_i｜｜ＲＡＮＤ_i｜｜ＡＵＴＨ_i｜）
ＩＭＳＩ（国際移動体識別加入者識別番号）は、例えば、サービスの認証情報を要求するときに、ユーザ／加入者の一意的な識別子として働くことができる。ＲＡＮＤ値は、チケット自体のフレッシュネスな指示を提供することができる乱数であり、ＡＵＴＨは、チケットの完全性およびチケットが本物であることが検証され得る手段である。鍵Ｋ_{RO_Priv}（ＲＯの秘密鍵）を用いたＰａｃｋａｇｅ＿１のハッシュの署名が、リモートの所有者を認証しながらメッセージの完全性を保護することができる。

２において送信されたメッセージに関して、ＰＯＳ３０は、そのＰＯＳ３０の秘密鍵Ｋ_{POS_Priv}を用いてチケットの組を復号し、（例えば、証明書Ｃｅｒｔ_ROで受信された）公開鍵Ｋ_{RO_Pub}を用いてリモートの所有者の署名を検証することができる。式１および２で指示されたように、ｎｏｎｃｅ０が、（送信者から受信者へ、そして再び送信者へ）往復し、それが安全な通信のために必要とされる場合がある。

３において、ユーザ３２が、例えばＴＨＳＭのユーザドメインＴＤ_U３４に登録し、ＩＤ、パスワード、および／または登録データなどの情報を提供する場合がある。

３のプロセスを、通常のログインおよび登録手順とみなしてもよい。メッセージの暗号化および署名の特徴、ならびにノンスｎｏｎｃｅ_Uの使用は、ＭＥの暗黙的な存在を反映する場合があり、ユーザに透過的である場合がある。この透過性は、図８に示された方法全体を通じて、ユーザ／所有者とＴＤ_Uの間のその他の通信に関わる場合がある。

ＩＤ_UおよびＰａｓｓｗｏｒｄ_U（ＰＷ_Uとも表記される）は、ユーザがプラットフォーム上で設定するアカウントのそれぞれに対してユーザによって作成された一意的なユーザ名およびパスワードの対であってもよい。ＩＤ_Uは、特定のアカウントに関するユーザを特定することができ、関連するＰａｓｓｗｏｒｄ_U（パスワード）は、（例えば、認可されたユーザによって知られているが、その他の者には知られていない）秘密であることができ、ユーザの認可のために使用されてもよい。ＲＥＧＤＡＴＡ_Uは、ユーザの個人情報を含んでもよい。

４において、ＴＤ_U３４が、３において受信されたメッセージ内の情報を読み、記憶し、プロセスＩＤ（ＰＩＤ＿Ｕ）を生成することができる。Ｋ_{temp_C}およびＫ_{temp_I}は、事前にプロビジョニングされ得る機密性の鍵および完全性の鍵をそれぞれ表してもよい。これは、ＴＤ_U３４がＰａｓｓｗｏｒｄ_U（パスワード）を復号し、Ｐａｃｋａｇｅ＿２のハッシュされた署名を検証することを可能にする。ＰＩＤ＿Ｕが、登録およびチケット要求プロセスを開始するためにＲＥＧＤＡＴＡ_Uと一緒にＰＯＳ３０に送信されてもよい。ＰＩＤ＿Ｕは、第１のプロセス識別子であってもよい。

５において、ＰＯＳ３０が、ＰＩＤ＿ＵおよびＲＥＧＤＡＴＡ_Uを受信した後、そのＰＩＤ＿ＰＯＳ（ＰＯＳ独自のＰＩＤ）を生成し、そのＰＩＤをＰＩＤ＿Ｕおよびユーザ登録情報と関連付けることができる。プラットフォームがＰＩＤ＿Ｕを用いてＰＯＳ３０と通信するとき、ＰＯＳ３０は、メッセージを、ＰＩＤ＿ＰＯＳによって識別される登録プロセスの一部とみなすことができる。したがって、複数の登録プロセスが、同時に行われることができる。ＰＩＤ＿ＰＯＳは、第２のプロセス識別子である場合がある。証明書Ｃｅｒｔ_TDUによって、ＰＯＳ３０は、公開鍵Ｋ_TDU-Pubを用いてＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿３）の署名を検証することができる場合がある。ＰＯＳ３０は、例えば、以下のメッセージに示されるように、ＰＩＤ＿ＵとともにＴＤ_U３４にＰＩＤ＿ＰＯＳを送り返すことによって、４のメッセージに応答することができる。

ＴＤ_U３４は、証明書Ｃｅｒｔ_POSから得られるＫ_{POS_Pub}を用いてＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿４）の署名を検証することができる。ＴＤ_U３４とＰＯＳ３０の間の通信は、無線でまたはインターネットの経路を介して行われてもよい。

６において、ＴＤ_U３４が、ＴＤ_RO３８に登録要求を送信することができる。ＰＩＤ＿ＵおよびＰＩＤ＿ＰＯＳを、ＴＤ_RO３８が関連するプロセスの関連付けを行うことを可能にするためにメッセージの一部として送信することができる。ユーザの識別情報ＩＤ_Uが、メッセージに含められてもよく、ＴＤ_RO３８が、そのＩＤ_Uを、登録を試みる特定のユーザのサービスプロファイルとの照合として使用することができる。この特徴は、同じドメインに対する複数のユーザ登録のための柔軟性を提供することができる。

ＴＤ_RO３８は、証明書Ｃｅｒｔ_TDUから得られる公開鍵Ｋ_TDU-Pubを用いてＴＤ_U３４の署名を検証することができる場合がある。

７において、ＴＤ_RO３８が、以下のメッセージでＰＯＳ３０にチケット要求を行うことができる。ＰＯＳ３０は、そのＰＯＳ３０がメッセージ５でＴＤ_U３４に送信し、メッセージ６でＴＤ_RO３８に渡されたｎｏｎｃｅ４を期待する場合がある。ｎｏｎｃｅ４をともなうＰａｃｋａｇｅ＿６が、秘密鍵Ｋ_TSIM-Privを用いて署名され得る。ＰＯＳ３０は、この要求を、プロセスＩＤＰＩＤ＿Ｕを用いて、４で送信された登録データと関連付けることができる場合がある。

ＰＯＳ３０は、このメッセージの署名を、そのＰＯＳ３０が証明書Ｃｅｒｔ_TSIMを介して得ることができる公開鍵Ｋ_TSIM-Pubを用いて検証することができる。ＰＯＳ３０は、Ｐａｃｋａｇｅ＿６（平文で送信される）およびｎｏｎｃｅ４を用いてＳＨＡ−Ｘを再作成することができる。

８において、登録要求（チケット要求）がＰＯＳ３０によって受信された後、そのＰＯＳ３０が、ＲＯ４０から前に受信された組からチケットを取り出すことができる。ＰＯＳ３０は、このチケットを、例えばＴＨＳＭを介してＴＤ_RO３８に送信することができる。公開鍵Ｋ_TSIM-Pubが、ｔｉｃｋｅｔ_kを暗号化し、そのチケットを受信者にバインドするために使用されてもよい。

ＴＤ_RO３８は、そのＴＤ_RO３８の秘密鍵Ｋ_TSIM-Privを用いてｔｉｃｋｅｔ_kを復号（バインド解除）し、メッセージ６のＣｅｒｔ_POSによって得られたＫ_POS-Pubを用いてＰａｃｋａｇｅ＿７の署名を検証することができる。このプロセスは、チケットを認証し、チケットの完全性を検証する機能を果たすことができる。ＴＤ_RO３８は、ＰＩＤ＿ＰＯＳを用いて正しいプロセスの関連付けを行うことができる。ノンンス、ｎｏｎｃｅ５がＴＤ_RO３８に返されてもよい。

９において、ＴＤ_RO３８に送信されたチケットに加えて、ＰＯＳ３０は、ＲＥＧＤＡＴＡ_Uを含む場合があり、ｔｉｃｋｅｔ_kによってユーザを特定することができる登録メッセージをＲＯ４０にやはり送信することができる。ＲＯ４０にプロセスの関連付けのために必要とされ得る情報を提供するために、ＰＩＤ＿ＰＯＳおよびＰＩＤ＿Ｕが、送信されてもよい。これは、ＲＯ４０が、受信されたプロセスＩＤを、そのＲＯ４０がこの登録に対して生成するＩＤと関連付けることを可能にする。このメッセージは、ＲＯ４０によって、指定されたユーザにそのＲＯ４０が要求する場合がある認証情報を提供するために必要とされ得る情報を含んでもよい。

チケットは、メッセージ２のＣｅｒｔ_ROでＰＯＳ３０によって取得されたＫ_RO-Pubを用いて暗号化されてもよい。ＲＯ４０は、そのＲＯ４０の秘密鍵Ｋ_RO-Privを用いてｔｉｃｋｅｔ_kを復号し、公開鍵Ｋ_POS-Pubを用いてＰａｃｋａｇｅ＿８の署名を検証することができる場合がある。公開鍵Ｋ_RO-Pubは、チケットをＲＯ４０にバインドする効果がある場合がある。

１０において、ＲＯ４０が、チケットを含む登録情報の受信に肯定応答することができる。例えば、ＲＯ４０は、ＴＤ_U３４に以下のメッセージを送信することができる。

ＴＤ_U３４は、ＰＩＤ＿Ｕと、９においてメッセージを受信した後にＲＯ４０によって生成されたＰＩＤ＿ＲＯとを受信することによって、ＲＯ４０とのプロセス識別情報を保有する場合がある。ＴＤ_U３４は、証明書Ｃｅｒｔ_ROで受信された公開鍵Ｋ_RO-Pubを用いてｐａｃｋａｇｅ＿９のハッシュの署名を検証することができる。

１１において、式１０に関連するメッセージを受信した後、ＴＤ_U３４は、認証情報を要求する許可をユーザ３２に付与するスクリーンメッセージをユーザ３２に対して発することができる。

このメッセージは、メッセージ３で使用された署名および検証プロセスと同様であるが逆向きの、ＭＥ側で同じ鍵を用いて検証されるようにＴＨＳＭ側で適用され得る署名鍵Ｋ_{temp_I}の使用を示す。ｎｏｎｃｅ_Uが、ＴＤ_U３４によってＭＥに返され、往復することができる。ＩＤ_Uが、ユーザ３２を識別するためにＭＥおよびＴＤ_U３４によって使用されることができ、ＰＩＤ＿Ｕとともに現在の登録および認証情報のロールアウトに結び付くことができ、そのことがプロセスの曖昧性を防ぐことができる。

ユーザは、認証情報のロールアウトを開始することができ、例えば、ユーザは、リモートの所有者に申し込んで加入者に関連する認証情報を取得することができる。１２において、ユーザ３２は、認証情報の要求によって、１１で伝達されたメッセージに応答することができる。パスワードを、共有された暗号鍵Ｋ_{temp_C}を用いて保護することができる。ｎｏｎｃｅ９が、ＴＤ_U３４に返されてもよい。

ＴＤ_U３４は、共有された鍵の組を用いてパスワードを復号し、署名を検証することができる場合がある。１１において伝達されたメッセージは、ＰＩＤ＿ＵとＩＤ_Uの組み合わせの使用を表す。ノンスおよびＰＩＤは、ユーザ／所有者に対して透過的であってもよく、人間でない通信エンティティによる使用に限定してもよい。

１３において、ＴＤ_U３４は、今や、ＴＤ_RO４０に認証情報のユーザ要求を転送することができ、そのことが、ＴＤ_RO３８がＲＯ４０に直接の要求を行うことを引き起こすことができる。ＰＩＤ＿ＲＯおよびＰＩＤ＿Ｕが、通信エンティティとのプロセスの関連付けを可能にする。ここで、ＴＤ_RO４０は、３つのプロセスＩＤを関連付けることができる。

メッセージの検証が、６で伝達されたメッセージで受信されたＣｅｒｔ_TDUで受信されたＫ_TDU-Pubを用いて行われてもよい。

１４において、ＴＤ_ROが、ＳＤＭ３６に準自律的な完全性の検証の要求を行うことができる。準自律的な完全性の検証は、重要な完全性のインジケータ（例えば、ＴＰＩＡ、ＴＰＥＳ、およびＳＣＡＲＤ）のハッシュ値の使用に制限されてもよい。

証明書Ｃｅｒｔ_TSIMが、ＳＤＭ３６がＰａｃｋａｇｅ＿１３のハッシュの署名の検証のための公開鍵Ｋ_TDRO-Pubを得ることを可能にするために送信されてもよい。プロセスＩＤの関連付けが、ＰＩＤ＿Ｕの使用によって維持されてもよい。ＳＤＭ３６は、外部のエンティティ、例えば、ＴＨＳＭの外部のエンティティと通信しない場合があるので、ＰＩＤ＿Ｕ以外は必要としない場合がある。

１５において、ＳＤＭ３６が、例えば、ＲＴＯプロセス以降に行われた場合がある構成の変更に関して更新された証明情報を収集することができる。ＴＰＩＡ、ＴＰＥＳ、およびＳＣＡＲＤが、必要に応じて更新される場合があり、完全性データを、単一の値ＩＶ（完全性検証値）へとハッシュすることができる。ＰＩＤ＿ＵおよびＩＶが、返信メッセージでＴＤ_RO３４に送信されてもよい。ノンスｎｏｎｃｅ_TDROが、返されてもよい。

署名が、証明書Ｃｅｒｔ_SDMで得られた公開鍵Ｋ_SDM-Pubを用いて検証され得る。

１６において、ＴＤ_RO３８が、ＲＯ４０に認証情報のロールアウトの要求を行うことができる。１６において送信されるメッセージにおいて、１３におけるメッセージの証明書ＣｅｒｔＲＯでＴＤ_RO４０によって受信されたＲＯ４０の公開鍵Ｋ_RO-Pubを用いて暗号化された識別子ＩＭＳＩ_kが、送信されてもよい。完全性の値ＩＶを、信頼の検証の目的で送信することができ、プロセスＩＤＰＩＤ＿Ｕを、９におけるメッセージの情報とのプロセスの関連付けを可能にするために送信することができる。

ＲＯ４０は、そのＲＯ４０の秘密鍵Ｋ_RO-Privを用いてＩＭＳＩ_kを復号し、証明書Ｃｅｒｔ_TDROでＲＯ４０によって取得された公開鍵Ｋ_TDRO-Pubを用いて署名を検証することができる。

１７において、認証情報を、ＲＯ４０によってＴＤ_RO３８に送信することができる。認証情報は、１６におけるＣｅｒｔＴＤＲＯから取得された公開鍵Ｋ_TDRO-Pubを用いて暗号化されてもよい。これは、認証情報をＴＤ_RO３８にバインドすることができる。ＴＤ_RO３８は、そのＴＤ_RO３８の秘密鍵Ｋ_TDRO-Privを用いて認証情報をバインド解除することができる。ノンスｎｏｎｃｅ１１が、往復されてもよい。

ＴＤ_RO３８は、１３における関連する証明書で受信された公開鍵Ｋ_RO-Pubを用いて署名を検証することができる。プロセスＩＤＰＩＤ＿ＲＯが、正しいプロセスの関連付けを提供する。

例えば、１７に指示されたように認証情報が受信されると、認証情報の鍵は、保護されたメモリに記憶されてもよく、またはＳＤＭ３６に提供されたセキュリティポリシーに従って記憶されてもよい。ポリシーは、ＲＴＯプロセス中に定義されてもよい。１８において、ロールアウトが完了すると、肯定応答メッセージが、ＲＯ４０に送信されてもよい。

ノンスｎｏｎｃｅ１２が返されてもよく、プロセスの曖昧性をＰＩＤ＿Ｕによって防ぐことができる。ＲＯ４０は、１６において取得された公開鍵Ｋ_TDRO-Pubを用いて署名を検証することができる。

１９において、ＴＤ_RO３８が、ロールアウト完了肯定応答メッセージをＴＤ_U３４に送信することができる。ノンスｎｏｎｃｅ_TDU2（１３参照）およびｎｏｎｃｅ_TDU1（１６参照）が返されてもよく、プロセスの曖昧性をＰＩＤ＿Ｕによって防ぐことができる。

署名が、証明書Ｃｅｒｔ_TDROで取得された公開鍵Ｋ_TDRO-Pubを用いてＴＤ_U３４によって検証されてもよい。

２０において、ユーザ３２は、認証情報が受信され、構成されることを指示するスクリーンメッセージをＴＤ_U３４から提供されてもよい。今や、認証情報が、ユーザ３２が認可される安全なサービスで利用可能となってもよい。ノンスｎｏｎｃｅ１０が、返されてもよい（１２参照）。

署名の検証が、３、１１、および１２に関連して説明されたように行われてもよい。ＰＩＤ＿ＵとＩＤ_Uの組み合わせの使用が、１１に関連して説明されたように行われてもよい。

２１において、ｔｉｃｋｅｔ_kが現在使用中であり、他の所に配布されるべきでないことを指示するメッセージが、ＰＯＳ３０に送信されてもよい。

ＰＯＳ３０は、２においてそのＰＯＳ３０が受信した証明書Ｃｅｒｔ_ROで取得された公開鍵Ｋ_RO-Pubを用いて署名を検証することができる場合がある。ＰＩＤ＿ＲＯが、プロセスの関連付けを可能にする。

図８に示されたコールフローに関連して、一方向に移動する３つのノンスが示されてもよい。つまり、それらのノンスは、それらのノンスが最初に伝達されたとき以後のメッセージで返されない場合がある。３つのそのようなノンスは、１０におけるｎｏｎｃｅ８、１５におけるｎｏｎｃｅ_SDM、および２１におけるｎｏｎｃｅ１５である。コールフローの説明で指示されていないが、これらのノンスのそれぞれに関して、ノンスを含むＡＣＫが、受信者から対応する送信者に送信される（返される）ことが仮定されてもよい。したがって、例えば、ｎｏｎｃｅ８が、１０におけるメッセージの受信の後で、ＴＤ_U３４によるＡＣＫメッセージによってＲＯ４０に返されてもよい。

ＩＩＩ．認証情報および／またはドメインのマイグレーション
認証情報および／またはドメインのマイグレーション、例えば、１つのデバイス（移行元）から別のデバイス（移行先）へのドメインのマイグレーション、移行元のデバイス上の第１のドメインから移行先のデバイス上の第２のドメインへの認証情報のマイグレーション、デバイス上の第１のドメインから当該デバイス上の第２のドメインへの認証情報のマイグレーションなどのためのシステム、方法、および手法が開示される。認証情報のマイグレーションを示す例が、提供され得る。しかし、本明細書において開示されたマイグレーションはそのような実施形態に限定されないことを理解されたい。

マイグレーションは、第１のドメインから第２のドメインに認証情報をマイグレーションすることを含んでもよい。例えば、デバイスのユーザが、デバイス上のリモート所有者ドメインにアクセスできる場合がある。ユーザは、リモート所有者ドメインに記憶された認証情報を有する場合があり、例えば、認証情報は、ユーザが、リモート所有者ドメインに関連するリモートの所有者によって提供されるサービスを使用することを可能にする。さらに、ユーザは、認証情報を異なる（第２の）リモート所有者ドメインに移す、すなわち、マイグレーションすることを望む場合がある。第２のリモート所有者ドメインは、同じデバイスまたは異なるデバイス上にある場合がある。例えば、ユーザは、新しいデバイスを購入した場合があり、ユーザは、新しいデバイスでリモートの所有者のサービスを使用することを望む。ユーザは、例えば、現在使用中のデバイスのＴＳＩＭのコア構成（コアセキュリティ認証情報：永続的なアイデンティティおよび共有された秘密Ｋ、ならびに／またはＴＳＩＭ機能／実行ファイル）を新しく購入されたデバイスに移すことを望む場合がある。

ＴＳＩＭの概念では、デバイス上に構成された１またはそれ以上のリモートで所有されるドメインにそれぞれがアクセスできる潜在的に複数のユーザが、これらのドメインのうちの１またはそれ以上のＴＳＩＭのコアを、ユーザがやはりアクセスできる別のデバイスに移したい場合がある。本明細書において開示されたシステム、方法、および手法は、移行元から移行先へのマイグレーションを説明することができ、この手順は、複数のドメインの移動のために繰り返されるとみなされ得る。

認証情報およびドメインは、本明細書に記載の信頼できるＴＨＳＭ（trusted hardware security module）のフレームワークの一部である場合がある。例示的なマイグレーションが、同じ所有者に属する移行元のドメインおよびターゲットのドメインを参照して示されてもよい。しかし、本明細書において開示されたマイグレーションはそのような実施形態に限定されないことを理解されたい。

以下のうちの１つまたはそれ以上が、マイグレーションが行われるために満足されるおよび／または仮定される場合がある。

ユーザ（例えば、デバイスの所有者によって許可されることによる）が、ユーザプロファイルが記憶され、移行元のデバイスと移行先のデバイスの両方で保有されるユーザドメインを登録および作成することができる。

マイグレーションが、あるレベルのＲＯ（リモートの所有者／オペレータ）の関与を含んでもよい。ＲＯ、および移行元のデバイスと移行先のデバイスの両方のＳＤＭ（システム全体のドメインマネージャ）が、マイグレーションが続行することを阻むことができる場合がある。ＲＯは、デバイスが、マイグレーションが続行することを許すのに十分な信頼性のレベルにあるかどうかを判定することができる。

ユーザプロファイルが、そのユーザが利用可能なサービスを指示するアカウント情報、およびその他のユーザの個人データなどのユーザ登録データ、ならびに識別子（例えば、ユーザ名）およびユーザ認証データ（例えば、パスワード、実際のパスワードのダイジェスト、生体認証データなど）を備えてもよい。１人の所有者を有する複数のデバイスでサービスにアクセスできるユーザの登録データおよびアカウント情報は、それらのデバイスでのそのユーザに関するアクセス可能なサービスに応じてデバイスごとに変わり得る。マイグレーションは、マイグレーションされる認証情報に関連するサービスに関連するユーザ登録データの転送を含んでもよい。

ユーザドメインが、ユーザがデバイスと通信するために必要である場合がある。つまり、ユーザが、概してサービスプロバイダによってリモートで所有されるドメインによって提供されるサービスにアクセスすることができるのは、ユーザドメインを通じてである場合がある。

デバイスの所有者が、ユーザである場合がある。場合によっては、デバイスの所有者が、唯一のユーザである場合がある。

デバイスは、１人の所有者を有することに制限される場合があるが、２人以上のユーザを持つことができる。各ユーザは、所与のユーザのプロファイルによって定義された一意的な構成を有する異なるユーザドメインを持つことができる。

移行元のデバイスから移行先のデバイスへの開示された例示的なマイグレーションに関しては、移行元のデバイスと移行先のデバイスの両方が、同じ所有者を有する場合がある。

ユーザのアクセスは、ユーザが登録され、使用の認可がされたサービス、およびひいてはそれらの関連するドメインに制限され得る。Ｐａｓｓｗｏｒｄ_U（ＰＷ_U）およびＩＤ_Uは、特定のドメインに固有である場合があり、ドメインがマイグレーションされ、同じユーザに関して、似ているが異なる登録認証情報がその他のドメインに対して存在する場合がある。ユーザによって提供された登録認証情報に応じて、信頼できるユーザ／所有者ドメインは、それらの認証情報を適切なドメインに導き、安全にプロビジョニングする役割を担い、それによって意図されるサービスがアクセスされ得る。

マイグレーションが行われるために、移行元のドメインのＲＯ（リモートの所有者）が移行先のドメインの所有権もＲＴＯを介して取得していることが必要である場合がある。そのとき、ＲＯは、その最初のポリシーおよび構成を知る場合がある。移行先のデバイスは、独自のシステム構成ファイルを有し、したがって、スタートアップドメイン（例えば、デバイスの製造者のドメイン、ならびにユーザ／所有者ドメイン、および将来の所有のための初期ドメインの最小限の組）と、場合によっては既に存在するリモートで所有されるドメインとを持っている場合がある。ＳＤＰ（システム全体のドメインポリシー）は、同じ所有者を有する複数のデバイスにわたって必ずしも複製されない。移行元のドメインおよび移行先のドメインのリモートの所有者は、マイグレーションが実行される前に両方のデバイスのＳＤＰを受け入れていると仮定される場合がある。

マイグレーションに関与するエンティティは、ユーザ／所有者、移行元に関連するシステム全体のドメインマネージャ、移行先に関連するシステム全体のドメインマネージャ、移行元に関連するリモート所有者ドメイン、移行先に関連するリモート所有者ドメイン、またはリモートの所有者のうちの１つまたは複数を含み得る。リモート所有者ドメインは、リモートで所有されるドメインと呼ばれることもある。

ユーザは、デバイス、例えば、１またはそれ以上のリモート所有者ドメインを含むデバイスのユーザである場合がある。ユーザは、デバイスの所有者でもある場合がある。ユーザは、リモート所有者ドメインのリモートの所有者に登録されてもよい。ユーザに関連する認証情報が、ユーザがリモートの所有者によって提供されるサービスにアクセスすることを可能にするためにリモート所有者ドメインにロードされてもよい。ユーザは、同じデバイスまたは異なるデバイス上の別のドメインに認証情報をマイグレーションすることを望む場合がある。ユーザは、認証情報のマイグレーションを開始することができる。

ＲＯ（リモートの所有者）は、デバイスを介してユーザにサービスを提供することができる。リモートの所有者は、ユーザがサービスを使用するために必要とされる場合がある認証情報を提供することができる。認証情報は、リモート所有者ドメインとリモートの所有者の間の強力な秘密として機能することができる認証鍵Ｋを含んでもよい。例として、ＲＯは、以下、すなわち、ＭＮＯ、その他の通信ネットワークのオペレータ（例えば、ＷＬＡＮ、ＷｉＭａｘなど）、電子メールサービスプロバイダ、インターネットサービスプロバイダ、ソーシャルネットワークサービスプロバイダ、デジタルコンテンツ（音楽、電子ブック、ビデオなど）プロバイダ、ゲームサービスプロバイダ、金融サービスプロバイダ、アプリケーションサービスプロバイダ（例えば、モバイル決済、モバイル発券、ＤＲＭ、モバイルＴＶ、位置に基づくサービスなどのサービスプロバイダ）、またはＩＭＳサービスプロバイダなどのうちの１つまたはそれ以上であってもよい。

ＴＤ_RO（リモート所有者ドメイン）は、リモートの所有者によって定義された機能を提供することができるデバイス上のドメインである。リモート所有者ドメインは、上記説明されたようにＴＨＳＭの一部である場合がある（例えば、図２を参照）。リモート所有者ドメインは、上述のＲＴＯプロセスに関連して説明されたＴＳＩＭ機能を有する場合がある。リモート所有者ドメインは、リモートの所有者によって提供された認証情報を記憶することができる。ＴＤ_ROは、ユーザドメインからＩＤＵおよびＰＩＤ＿Ｕ（ユーザのＩＤおよびプロセスＩＤ）を受信し、登録および認証情報のロールアウト中にこの情報をさまざまに使用することができる。認証情報がマイグレーションされるＴＤ_RO,S（移行元のリモート所有者ドメイン）と、認証情報がマイグレーションされるＴＤ_RO,D（移行先のリモート所有者ドメイン）とが存在し得る。例えば、ユーザは、移行元のデバイスに関連するリモート所有者ドメインから移行先のデバイスに関連するリモート所有者ドメインへの転送を開始することができる。

ＳＤＭ（システム全体のドメインマネージャ）、例えば、節Ｉで開示されたＳＤＭが、マイグレーションプロセスの一部として１またはそれ以上のプラットフォームに関連する証明情報を提供することができる。例えば、準自律的な完全性の確認などの完全性のインジケータが、ＳＤＭによって提供されてもよい。ＳＤＭは、ドメインのコンポーネントなど、ＴＨＳＭの一部である場合がある（例えば、図２を参照）。ＳＤＭは、信頼できるユーザドメインおよび／または信頼できる所有者ドメインと組み合わされてもよい。移行元のリモート所有者ドメインに関連するＳＤＭ_S（移行元のシステム全体のドメインマネージャ）と、移行先のリモート所有者ドメインに関連するＳＤＭ_D（移行先のシステム全体のドメインマネージャ）とが存在し得る。

下の最初の３つの式のそれぞれは、２つの部分、移行元のデバイスにおける通信に関する１つの部分と、移行先のデバイスにおける同様の通信に関するもう１つの部分とを含んでもよい。これらの部分は、例えば、式１の場合、１（移行元の部分）および１ａ（移行先の部分）とラベル付けされてもよい。これらの式中の鍵および証明書は、たとえそれらがそれらのそれぞれの部分で異なる値を示す場合があるとしても同様に表記され得る。例えば、式１において、機密性の鍵および完全性の鍵は、たとえそれらが異なる鍵の組を表す場合があるとしても、移行元の部分（１）と移行先の部分（１ａ）の両方に対してそれぞれＫ_{temp_C}およびＫ_{temp_I}と表記され得る。別の例において、Ｋ_SDM-PubおよびＫ_SDM-Privが、それらの移行元の使用および移行先の使用における異なる公開−秘密鍵の対を表す場合があり、例えば、３および３ａを参照のこと。

マイグレーション全体にわたって、メッセージの署名および署名の検証が、承認されてもよい。公開−秘密鍵の対を、このセキュリティ機能を実行するために使用することができ、それによって、メッセージが認証され、その上、完全性が保護される。信頼できる第三者の証明書によって、メッセージの署名者により秘密署名鍵に対応する公開鍵を配布することが、含まれてもよい。例えば、Ｃｅｒｔ_TSIMと表記される（移行元のリモートで所有されるドメインおよび移行先のリモートで所有されるドメインに関してそれぞれＣｅｒｔ_TSIMSおよびＣｅｒｔ_TSIMDと表記される）第三者が発行した証明書が、秘密鍵Ｋ_TSIM-Priv（Ｋ_TSIMS-PrivかまたはＫ_TSIMD-Privかのいずれか）に対応する公開鍵Ｋ_TSIM-Pub（それぞれ移行元または移行先に応じてＫ_TSIMS-PubかまたはＫ_TSIMD-Pubかのいずれか）を配送するために使用されてもよい。秘密鍵は、所与のメッセージを固定長にするそのメッセージのＳＨＡ−Ｘハッシュに署名する。対応する公開鍵が、署名の検証のために使用される。

プラットフォームとのユーザ／所有者の通信は、図９Ａ／９Ｂに示されず、または式で参照されない端末を通じて実行され得る。移行元のデバイスと移行先のデバイスの両方に関して、事前にプロビジョニングされた対称的な異なる鍵の組Ｋ_{temp_C}およびＫ_{temp_I}が、端末とＴＨＳＭの間の通信を保護することができる。ユーザ／所有者が、移行元のデバイスかまたは移行先のデバイスかのいずれかの信頼できるユーザ／所有者ドメイン（総称的にＳＤＭ／ＴＤ_U／ＴＤ_Oと表記される）と通信するとき、そのような鍵が、含められることができる。

プロセスＩＤ管理は、マイグレーションにおいては（例えば、帯域外メッセージングが利用可能でない場合があるので）使用されない場合がある。

表記ＳＤＭ／ＴＤ_U／ＴＤ_Oが、組み合わされたＳＤＭとユーザ／所有者ドメインを表すために使用されてもよい。表記ＳＤＭ／ＴＤ_U／ＴＤ_Oは、別々のエンティティを表す場合があり、マイグレーションの異なる部分において、参照はＳＤＭに限られる場合があり、その他のときには、参照はユーザ／所有者ドメインに限られる場合があり、参照は状況に依存する。状況は、例えば、ユーザＩＤおよび場合によってはパスワードを使用するマイグレーション要求メッセージングを含むユーザ／所有者の対話である場合があり、または状況は、関与がＳＤＭに限られる場合があるポリシーに関する対話である場合がある。同様の表記によって、ユーザ／所有者は、ユーザ／所有者の対話を示す場合があり、ＳＤＭは、ＳＤＭの対話を示す場合がある。

ＳＡ−ＩＶ（準自律的な完全性のインジケータ）などの完全性のインジケータが、移行元のデバイスおよび移行先のデバイスの信頼性のレベルを評価するためにマイグレーションにおいて使用されてもよい。準自律的な完全性のインジケータは、完全性の検査を通らないデバイス内のモジュールのリストを含んでもよい。表記ＳＡ−ＩＶ（ｓｒｃ）およびＳＡ−ＩＶ（ｄｅｓｔ）が、移行元および移行先の準自律的な完全性のインジケータを示すために使用され得る。

Ｐｒｏｃ＿ＩＤ（プロセス識別子）が、マイグレーション要求、およびプロセスのために必要とされ得る後に続くメッセージングの発生源についての曖昧性を回避するために、マイグレーションに関連するメッセージング全体を通じて提供されてもよい。署名メカニズムによるメッセージの完全性の保護が、このアイデンティティの外部の不正行為を防止することができる。ユーザＩＤおよびプロセスＩＤの使用が、例えば、ユーザが複数のドメインをマイグレーションすることを望む場合の曖昧性を回避するためにドメイン識別子を含むように拡張されてもよい。以下の例は、ユーザが単一のドメインをマイグレーションする場合を示す場合がある。しかし、プロセスは、その場合に限定されず、複数のドメインのマイグレーションの場合も含んでもよい。

ＰＷ_U（ユーザのパスワード）の最初の使用は、ユーザの成りすましを防止することができ、したがって、マイグレーション要求の開始は、正規のユーザ／所有者に制限され得る。

リプレーからの保護が、プロトコル全体を通じてノンスを使用することによって提供されてもよい。往復の通信の発生元が、意図される受信者にノンスを送信することができ、受信者は、署名されたハッシュの一部として発生元にそのノンスを返すことができる。場合によっては、ノンスは、式４で移行元のドメインからｎｏｎｃｅ４を受信した後の式７ａにおけるＲＯによるそのｎｏｎｃｅ４の返却のように、プロトコルにおいてさらに後で返される場合がある。ノンスは、概して、順番に従って連続的に付番されることができ、例えば、ステップｉで送信者によって生成されたノンスは、通常、値ｎｏｎｃｅｉを得ることができる。

下の式の特定の例は、帰ってくるノンスを示す場合があり、発生元からのノンスの転送は示されない。それぞれの場合のノンスは、示される通信の前の出ていく通信において発生元によって提供されたと仮定されてもよい。このような発信する（outgoing）通信は、必要とされるノンスに制限される場合がある。これらの省略は、以下の場合に起こる。
ｉ．ＳＤＭ_Sで発生する１におけるｎｏｎｃｅ１
ｉｉ．ＳＤＭ_Dで発生する１におけるｎｏｎｃｅ１ａ
ｉｉｉ．ＴＤ_RO,Dで発生する２（式２）におけるｎｏｎｃｅ２ｄ
ｉｖ．ＴＤ_RO,Sで発生する２（式２ａ）におけるｎｏｎｃｅ２ｓ
ｖ．ＲＯで発生する４におけるｎｏｎｃｅ４ｃ
ｖｉ．ＴＤ_RO,Dで発生する７におけるｎｏｎｃｅ４ａ
ｖｉｉ．ＳＤＭ_Dで発生する５におけるｎｏｎｃｅ４ｂ
ｖｉｉｉ．ＴＤ_RO,Dで発生する８におけるｎｏｎｃｅ８ａ
ｉｘ．端末で発生する１８におけるｎｏｎｃｅ１８
ｘ．端末で発生する２０におけるｎｏｎｃｅ２０

図９Ａおよび９Ｂは、認証情報のマイグレーションを実装する例示的なコールフローを表す。図９Ａは、移行元のドメインおよび移行先のドメインの完全性の検証がリモートの所有者によって実行され得る例示的なマイグレーションを表す。図９Ｂは、移行元のドメインの完全性の検証がＳＤＭ_Dによって実行されてもよく、移行先のドメインの完全性の検証がＳＤＭ_Sによって実行されることができる例示的なマイグレーションを表す。

図９Ａおよび９Ｂのマイグレーションおよび関連するコールフローの詳細などのマイグレーションおよび関連するコールフローの詳細が提供される。上述のように、３ａまでの式において、総称的な表記が使用される場合がある。

図９Ａを参照すると、例示的なマイグレーションは、所有者でもある場合があるユーザ、ユーザ／所有者９４０と、ＳＤＭ_S、ＴＤ_U,S、ＴＤ_O,Sのうちの１つまたは複数を指す場合があるＳＤＭ_S／ＴＤ_U,S／ＴＤ_O,S９５０と、移行元のリモート所有者ドメインＴＤ_RO,S９６０とを含む場合があり、ＴＤ_RO,D９７０およびＳＤＭ_D／ＴＤ_U,D／ＴＤ_O,D９８０を含む移行先のデバイスに関する同様の参照をともなう。マイグレーションの前に、ＲＯ（リモートの所有者）９９０が、ＴＤ_RO,D９７０のＲＴＯを完了し、ＴＤ_RO,D９７０の最初のポリシーおよび構成を知っている場合がある。

１および１ａにおいて、認証情報のマイグレーション要求が、ユーザ／所有者９４０によってなされてもよい。式１および１ａは、ユーザ／所有者９４０に関する通信を示し、ユーザ／所有者９４０は、マイグレーションを開始するために、ログイン情報およびマイグレーション要求をＳＤＭ_S／ＴＤ_U,S／ＴＤ_O,S９５０およびＳＤＭ_D／ＴＤ_U,D／ＴＤ_O,D９８０（移行元のおよび移行先のユーザ／所有者ドメイン）にそれぞれ送信することができる。鍵Ｋ_{temp_C}がユーザのパスワードを暗号化し、Ｋ_{temp_I}がメッセージに署名する。上述のように、Ｋ_{temp_C}およびＫ_{temp_I}は、端末（図示せず）とＴＨＳＭとのインターフェースを介した通信を保護することができる。事前にプロビジョニングされた対称的な鍵のプロパティが、移行元のドメインおよび移行先のドメインがパスワードを復号し、メッセージの署名を検証することを可能にすることができる。ユーザは、ログイン情報（移行元のドメインおよび移行先のドメインに対して同じである場合があり、例えば、ユーザが、両方のドメインに関してサービスに一度登録する場合がある）を移行元のおよび移行先のユーザ／所有者ドメインに提供する場合があり、ここで、移行先に関して、ログインの認証情報は転送済みである。ＴＳＩＭの認証情報がマイグレーションされるとき、ユーザ登録プロファイルの転送が、例えば、１６において行われ得る。１の前に、ノンス１および１ａが、ユーザ／所有者９４０による最初のマイグレーション要求で使用するために、それぞれ、移行元のＳＤＭおよび移行先のＳＤＭによって端末に送信された場合がある。これは、ステップ１におけるそれらのノンスの返却によって反射を防止することができる。

ＰＷ_UおよびＩＤ_Uが、マイグレーションされているドメインのＴＳＩＭに関連付けられ得る。同じユーザが、異なるパスワードおよびログインＩＤの認証情報を用いてその他のリモートで所有されるドメインに登録する場合がある。

システム全体のポリシーの検査が、ポリシーの規定がマイグレーションの続行を禁じるかどうかを判定するためにそれぞれのＳＤＭによって行われてもよい。システムレベルの検査は、万一いずれかのプラットフォーム上に２人以上のドメインのリモートの所有者が存在する場合に、複数のそのような所有者の間で起こり得る衝突を考慮に入れることができる。１および１ａに関して、通信される情報は、移行元のおよび移行先のＳＤＭ９５０および９８０によるポリシーの検査と、移行元のおよび移行先の信頼できるドメインＴＤ_U,X／ＴＤ_O,X９５０および９８０によるユーザのログイン情報の処理とを要求することができ、Ｘ＝ＳまたはＤである。

一実施形態において、マイグレーション要求は、移行元に要請されるが、移行先には要請されない場合がある。例えば、移行先のドメインを有するデバイスが、ユーザ／所有者９４０にまだ販売されない場合があり、マイグレーションが、販売プロセスの一部とされる場合があり、例えば、販売者が、ユーザドメインを受け取るまでデバイスを保管する場合があり、それを支払までの「抵当（hostage）」とする。この場合、移行先のデバイスは、最初のユーザのログインまで、受け取られたドメインを非アクティブのままにする場合がある。この最初のユーザのログインは、受け取られたユーザドメインＴＤ_Uからユーザが認証されたメッセージを取得することができる別のドメイン（デバイス製造者ドメインＴＤ_DM）によって処理される必要がある場合があり、そのとき、ＴＤ_DMが、移行先のデバイス上でＴＤ_Uをアクティブにすることができる。

２および２ａにおいて、ＳＤＭ_S／ＴＤ_U,S／ＴＤ_O,S９５０およびＳＤＭ_D／ＴＤ_U,D／ＴＤ_O,D９８０（ユーザ／所有者ドメイン）が、ユーザによって開始されたドメインのマイグレーション要求メッセージを、例えば、それぞれ、式２ａおよび２でＴＤ_RO,S９６０およびＴＤ_RO,D９７０（ＲＯの移行元のドメインおよび移行先のドメイン）に転送することができる。ユーザの識別情報ＩＤ_Uが、サービスの認可の検査のために必要とされ得る。Ｐｒｏｃ＿ＩＤ（プロセスＩＤ）が、さまざまなサービスの同時の要求を行う複数のユーザ間の潜在的な曖昧性をなくすために（例えば、４参照）生成される。Ｐｒｏｃ＿ＩＤとユーザＩＤＩＤ_Uの間の関連付けは、明示的に示されない場合がある。公開鍵Ｋ_SDM-Pubが、証明書Ｃｅｒｔ_SDMによってＴＤ_RO,S９６０およびＴＤ_RO,D９７０（移行元のドメインおよび移行先のドメイン）に渡されてもよい。ＴＤ_RO,S９６０およびＴＤ_RO,D９７０（移行元のドメインおよび移行先のドメイン）は、Ｋ_SDM-Pubを用いてメッセージの署名を検証する。メッセージは、移行元の転送および移行先の転送のためにＫ_SDM-Privによって署名されてもよい。ノンス、ｎｏｎｃｅ２ｄおよびｎｏｎｃｅ２ｓが、それぞれ、移行先のドメインおよび移行元のドメインによってそれらのそれぞれのＳＤＭに渡されたと仮定されてもよい。署名および転送の動作は、ユーザ／所有者の移行元のおよび移行先のドメインに関連する機能によって実行されてもよい。

２ｂおよび２ｃにおいて、それぞれのＴＤ_RO,S９６０およびＴＤ_RO,D９７０（移行元のドメインおよび移行先のドメイン）が、マイグレーションに関するポリシーの衝突がドメインレベルで存在するかどうかを判定するための検査を実行することができる。システム全体のまたはドメインレベルのポリシーの衝突は、マイグレーションを阻む場合があり、例えば、３において、プロトコルの継続を防止する否定応答（ＮＡＣＫ）が送信されてもよい。

３および３ａにおいて、ＴＤ_RO,S９６０およびＴＤ_RO,D９７０（移行元のドメインおよび移行先のドメイン）が、肯定（ＡＣＫ）または否定（ＮＡＣＫ）応答で、マイグレーション要求、それぞれ１および１ａに応答する。ＳＤＭ_S／ＴＤ_U,S／ＴＤ_O,S９５０およびＳＤＭ_D／ＴＤ_U,D／ＴＤ_O,D９８０（移行元のまたは移行先のユーザ／所有者ドメイン）が、そのリモートで所有されるドメインに関するポリシーがこのマイグレーション要求を禁じることを指示するＮＡＣＫを受信する場合、マイグレーションは終了される。両方がＡＣＫを受信する場合、プロセスは継続することができる。ユーザ／所有者ドメインは、式３および３ａにおいて、それらの証明書Ｃｅｒｔ_TSIMによって取得され得る公開鍵Ｋ_TSIM-Pubのそれらのそれぞれのバージョンでそれらのメッセージの署名を検証することができる。示されたように、メッセージは、Ｋ_TSIM-Privを用いて署名されてもよい。

３ｂにおいて、ＴＤ_RO,S９６０が、ユーザ所有者ドメインＳＤＭ_S／ＴＤ_U,S／ＴＤ_O,S９５０から許可されたメッセージを受信することができる。（式３ｂ以降、移行元と移行先の鍵の組およびそれらの対応する証明書の間で表記上の区別がなされる）。メッセージの署名が、例えば、式２ａで伝達されたＣｅｒｔ_SDMS（証明書Ｃｅｒｔ_SDM）からＴＤ_RO,S９６０によって取得された公開鍵Ｋ_SDMS-Pubを用いて検証されることができる。

４において、ＴＤ_RO,S９６０が、ＲＯ９９０にマイグレーションが要求されていることを警告するメッセージを送信することができる。メッセージは、ＴＤ_RO,S９６０およびＴＤ_RO,D９７０（移行元のドメインおよび移行先のドメイン）のポリシー、構成の状態、およびＳＡ−ＩＶを検査することを指示することができ、例えば、２を参照して、ＩＤ_UおよびデバイスＩＤのＲＯ９９０への転送が、認可の検査の目的で使用されてもよい。メッセージの署名が、証明書Ｃｅｒｔ_TSIMSで受信された公開鍵Ｋ_TSIMS-Pubを用いて検査および検証されてもよい。移行元のドメインがマイグレーションの要求を許可しない場合、プロセスを終了することができ、例えば、式４のメッセージは送信されない。しかし、移行元がマイグレーションを許可し、移行先のドメインが同時に許可しない場合があり、これは、競合状態につながる場合がある。そのような場合、プロセスは、終了されるか、または場合によっては例えば６において再ネゴシエーションされる場合がある。万一、移行元は許可しないが、移行先は許可することが起こったとすると、移行先のドメインによって開始されたアクティブなプロセスは、特定の事前に定義された期間の後タイムアウトする場合がある。

５および５ａにおいて、ＲＯ９９０が、それぞれ、ＳＤＭ_S／ＴＤ_U,S／ＴＤ_O,S９５０およびＳＤＭ_D／ＴＤ_U,D／ＴＤ_O,D９８０（移行元のＳＤＭおよび移行先のＳＤＭ）からのポリシーおよび構成情報を要求することができる。例えば、ＲＯ９９０は、移行元のドメインおよび移行先のドメインからの構成、デバイスＩＤ、ＳＡ−ＩＶ情報、ならびにマイグレーションポリシーを要求することができる。システム全体のドメインポリシーを管理するＳＤＭが、要求を受信し、ＲＯ９９０に対するそれらのＳＤＭのそれぞれの応答を準備することができる。両方のメッセージに関して、メッセージの署名が、Ｃｅｒｔ_ROで得られた公開鍵Ｋ_{RO_Pub}を用いて検証されることができる。

６および６ａにおいて、ＳＤＭ（ＳＤＭ_S／ＴＤ_U,S／ＴＤ_O,S９５０およびＳＤＭ_D／ＴＤ_U,D／ＴＤ_O,D９８０）が、要求された情報をＲＯ９９０に送信する。マイグレーションが移行先のドメインＴＤ_RO,D９７０によって禁じられる場合、ＮＡＣＫメッセージがＲＯ９９０に返され、プロセスが終了される。この場合、ＲＯ９９０は、なぜマイグレーションが拒否されるのかを知るために、ＳＤＭ_D／ＴＤ_U,D／ＴＤ_O,D９８０（移行先のＳＤＭ）からの追加的な情報を要求することができる。４の要求から、移行元のドメインは既に許可したことが理解され得る。修正されたドメインの構成（例えば、サービスの修正）がそれに受け入れ可能であるかを判定するためにＲＯ９９０とＳＤＭの間の潜在的なネゴシエーションが存在する場合がある。修正の許容場合は、例えば、（例えば、所有者とは異なるユーザがマイグレーションを開始していると仮定すれば）デバイスの所有者、または元の構成を禁じるドメインポリシーを有する別のリモートの所有者によって判定されてもよい。ネゴシエーションが失敗する場合、マイグレーションは、さらなる通信なしに終了される場合があり、移行元のドメインによってアクティブ化されたマイグレーションプロセスは、事前に決められた期間の後、タイムアウトする場合がある。そうでない場合、マイグレーションは、続行することができ、移行先のドメインに対する修正が、そのドメインの別のＲＴＯを引き起こす場合がある。

引き続き６および６ａを参照すると、ＲＯ９９０は、Ｐｒｏｃ＿ＩＤならびに移行元のおよび移行先のデバイスＩＤを受信して、プロセスを２つのデバイスと関連付けることができる。登録されたサービスに関する認可の検査が、行われ得る。ＳＡ−ＩＶ（ｓｒｃおよびｄｅｓｔ）の受信によって、両方のデバイスの完全性が検証され得る。構成の許容場合も、評価され得る。

ＲＯ９９０は、それぞれ、証明書Ｃｅｒｔ_SDMDおよびＣｅｒｔ_SDMSから得られた公開鍵Ｋ_SDMD-PubおよびＫ_SDMS-Pubを用いて署名を検証することができる。

一実施形態において、ドメインの構成およびポリシーの要求は、そのような情報がマイグレーションの発生までに起こり得るＲＴＯプロセスから取得されるので、省略される場合がある。

６ｂにおいて、ＲＯ９９０が、ＴＤ_RO,S９６０およびＴＤ_RO,D９７０（移行元のドメインおよび移行先のドメイン）のポリシー、構成、および信頼性の許容場合を検査することができる。（ＮＡＣＫがないものと仮定する場合がある）６および６ａにおいて移行元のドメインおよび移行先のドメインから受信された構成のポリシーおよび完全性のインジケータのそのＲＯ９９０の評価に基づいて、ＲＯ９９０は、マイグレーションを継続するか、または終了するかのいずれかの決定を行うことができる。継続する場合、７および７ａにおいて、継続するためのメッセージが、それぞれ、ＴＤ_RO,S９６０およびＴＤ_RO,D９７０に送信されることができる。ＲＯ９９０が現在の構成を受け入れ可能でないと認識する（例えば、構成が最初のＲＴＯ以降に変わった場合がある）場合、ＲＯ９９０は、いかなるネゴシエーションもせずにマイグレーションを終了するか、または関係するものが受け入れ可能であり、継続を可能にする新しい構成およびポリシーをネゴシエーションすることができる。メッセージは、Ｃｅｒｔ_ROから得られた公開鍵Ｋ_{RO_Pub}を用いて検証されてもよい。

５、５ａ、６、および６ａに関連する例示的なバリエーションにおいて、移行元のドメインおよび移行先のドメインの完全性の状態は、ＲＯ９９０によって検査されない場合がある。完全性の状態は、ドメイン自体によって検査されてもよい。つまり、移行元のドメインの完全性の状態は、移行先のドメインによって検査されてもよく、その逆も可能である。これは、ドメインが、その他のドメインの完全性の状態を検査するそれらのドメインの能力の観点でＲＯ９９０の有能な代理であると仮定する場合がある。

８において、ＴＤ_RO,S９６０が、例えば、移行元および移行先の構成、信頼性のレベル、およびポリシーがマイグレーションのために受け入れ可能であるというＲＯ９９０による判定の後で、マイグレーションサービスをアクティブ化するためにＴＤ_RO,D９７０にメッセージを送信することができる。ドメインの状態の要求が、発せられることができる。受信者は、証明書Ｃｅｒｔ_TSIMSで運ばれた公開鍵Ｋ_TSIMS-Pubを用いて署名を検証することができる。

９乃至１２において、１またはそれ以上のアクションが、ドメインの認証情報の転送のための移行元および移行先の準備の状況を判定するために行われてもよい。ＲＯ９９０が、移行元のドメインおよび移行先のドメインの信頼性を評価し、それらをプロトコルが続行するのに適するとみなしたと仮定してもよい。９において、ＴＤ_RO,D９７０が、ＳＤＭ_D／ＴＤ_U,D／ＴＤ_O,D９８０（移行先のユーザ／所有者ドメイン）からの（例えば、ドメインの利用可能なメモリの状態を示す）状態情報を要求することができる。９ａにおいて、ＳＤＭ_D／ＴＤ_U,D／ＴＤ_O,D９８０（移行先のユーザ／所有者ドメイン）が、状態情報を提供することができる。署名の検証が、（例えば、２においてＣｅｒｔ_SDMとして示された）Ｃｅｒｔ_SDMDで取得された公開鍵Ｋ_SDMD-Pubを用いて実行されてもよい。式９および９ａは、移行先のドメインがそのドメイン自身の状態を、式８におけるその情報の要求の後で取得することを示す。

１０において、ＴＤ_RO,D９７０が、状態情報をＴＤ_RO,S９６０に提供することができ、例えば、式１０において、移行先のドメインが、要求された状態情報を移行元に提供する。１０ａにおいて、移行元のドメインが、移行先の状態情報の検査を実行することができる。例えば、移行元のドメインが、続行する、延期する、または終了することを決定する場合がある。移行先の状態情報が受け入れ可能な準備の状態（例えば、メモリおよび機能的な能力に関する受け入れ可能な状態）を指示する場合、移行元のドメインは、続行することを決定することができる。移行先の状態情報が受け入れ可能でない準備の状態を指示する場合、移行元のドメインは、必要とされるソフトウェアのダウンロードが完了するまでマイグレーションを延期することを決定することができる。

１１において、ＴＤ_RO,S９６０が、ＳＤＭ_S／ＴＤ_U,S／ＴＤ_O,S９５０（移行元のユーザ／所有者ドメイン）からの（例えば、必要とされるソフトウェアのバージョンなどのマイグレーション機能の状態を示す）状態情報を要求することができる。１１ａにおいて、ＳＤＭ_S／ＴＤ_U,S／ＴＤ_O,S９５０（移行元のユーザ／所有者ドメイン）が、状態情報を提供することができる。式１１および１１ａは、移行元に関して、９および９ａの同様のプロセスを提供する。この情報は、以下に示されるように、移行元の準備の移行先のドメインの評価ために移行先のドメインに渡さてもよい。

移行元のユーザ／所有者ドメインは、Ｃｅｒｔ_TSIMS（例えば、３参照）で取得された公開鍵Ｋ_TSIMS-Pubを用いてメッセージ（式１１）の署名を検証することができる。式１１ａにおいて、署名は、ステップ３のＣｅｒｔ_SDMSで取得された公開鍵Ｋ_SDMS-Pubを用いて検証される。１２以降、署名の検証に対する明示的な言及はされない場合がある。署名は、適切な署名鍵を用いて指示されてもよく、証明書の受け渡しも、必要に応じて指示される。これらの場合のそれぞれにおいて、上述のステップにおいて示された公開鍵が、関連する署名を検証するために使用されてもよい。

１２において、ＴＤ_RO,S９６０が、ＴＤ_RO,D９７０に状態情報を提供することができ、例えば、式１２は、移行元がその移行元の状態を移行先に提供することを示す。式１２は、マイグレーションＯＫメッセージも渡すことができる。マイグレーションが続行することができる前に状態の変更が必要とされる場合、延期メッセージが、代わりに用いられる場合がある。

１２ａにおいて、移行先のドメインが、移行元の状態情報の検査を実行することができる。例えば、移行先のドメインが、続行する、延期する、または終了することを決定する場合がある。移行元の状態情報が受け入れ可能な準備の状態（例えば、受け入れ可能最新のマイグレーションソフトウェア）を指示する場合、移行先のドメインは、続行することを決定することができる。移行元の状態情報が受け入れ可能でない状態を指示する場合、移行先のドメインは、必要とされるソフトウェアがダウンロードされるまでマイグレーションを延期することを決定することができる。

一実施形態において、９乃至１２で示されたように移行元のドメインの状態を検査する代わりに、移行先のドメインは、パッケージを受信した後で、受信されたパッケージを検査する場合がある。そのとき、完全なパッケージが、最初に、移行先のＳＤＭに転送され、知られているＩＶ（完全性の検証）の基準と照合される必要がある場合がある。安全なブートの結果として生じるＩＶは、マイグレーションの構成のパッケージから計算されるＩＶとは異なる場合がある。

１３において、ＴＤ_RO,D９７０が、（例えば、「認証情報送信（send credentials）」メッセージで）ＴＤ_RO,S９６０が認証情報を送信することの要求を送信することができる。１３のメッセージは、１０ａおよび１２ａによりマイグレーションが受け入れ可能であることを指示されるときに送信されてもよい。１３ａにおいて、ＴＤ_RO,S９６０が、認証情報をＴＤ_RO,D９７０に送信することができる。１３ｂにおいて、ＴＤ_RO,D９７０が、マイグレーションされた認証情報を用いて構成されてもよい。万一、延期メッセージが送信されたとすると、例えば、プロセスが移行元のタイマーおよび移行先のタイマーの制限内に再開しない場合、タイムアウトが発生する場合がある。

１４乃至２０において、クリーンアッププロセスが、実施されてもよい。式１４乃至２０は、クリーンアップを実行するメッセージを含み、それによって、マイグレーションが行われ、（ＲＯのポリシーが移行元のドメイン上の古い認証情報の破棄を命じる場合に）移行元のドメイン内の認証情報の破棄プロセスが、そのような破棄が許されるというポリシーの検査中に行われるべきであるという肯定応答が交換されてもよい。

１４において、ＴＤ_RO,D９７０が、ＴＤ_RO,S９６０上の認証情報が破棄されるべきであることを指示し得るマイグレーション確認メッセージをＴＤ_RO,S９６０に送信する。式１４は、マイグレーションが行われ、移行先のデバイスが新しくマイグレーションされた認証情報に従って再構成されたという移行先のドメインから移行元への肯定応答を示す。古い認証情報（移行元のドメインの認証情報）を破棄する要求が含まれる。前のＲＴＯプロセス中に、ネゴシエーションが行われた場合があり、（移行元のデバイスの所有者の代理としての）移行元のデバイスのＳＤＭとＲＯとが、移行元のドメイン上の認証情報の任意のマイグレーション後の破棄または引き続きの記憶について相互に合意したことが仮定されてもよい。

認証情報の転送の後、移行元のＳＤＭによる認証情報の破棄に関するシステム全体のポリシーの検査が、必要とされる場合がある。１５において、認証情報の破棄に関連するポリシーの検査を実行するために、ＴＤ_RO,S９６０からＳＤＭ_S／ＴＤ_U,S／ＴＤ_O,S９５０（移行元のＳＤＭ）にメッセージが送信されてもよい。１５ａにおいて、ポリシーの検査が、実行されてもよい。式１５は、そのような検査を実行するための、ＳＤＭ_Sへの移行元のドメインによる要求を指示するメッセージを示す。

１６において、ＳＤＭ_S／ＴＤ_U,S／ＴＤ_O,S９５０（移行元のユーザ／所有者ドメイン）が、ＳＤＭ_D／ＴＤ_U,D／ＴＤ_O,D９８０（移行先のユーザ／所有者ドメイン）にユーザデータを送信することができる。式１６において、ユーザ登録データが、移行元から移行先のドメインに転送される。ＲＥＧＤＡＴＡは、マイグレーションされた認証情報に関連する加入者情報を含むユーザプロファイルを表す。最小限の加入者プロファイルが、移行先のドメインへのアクセスおよびプロトコルの開始のために移行先のデバイスへのユーザのログインを可能にするために使用されてもよい。

１７において、ＳＤＭ_S／ＴＤ_U,S／ＴＤ_O,S９５０（移行元のユーザ／所有者ドメイン）が、マイグレーションが完了していること、およびマイグレーションされた認証情報が、移行元で（例えば、ＴＤ_RO,S９６０で）破棄されたかどうかを指示するメッセージをＲＯ９９０に送信することができる。式１７は、認証情報の破棄がシステムのポリシーに違反しないと仮定して、ＲＯに認証情報の破棄を確認する。認証情報の破棄が移行元のシステムのポリシーによって許されない場合、想定できる解決メカニズムは、同じ認証情報が別々のデバイス上に共存することができるかどうかをＲＯが判定することを要求する場合がある。

１８において、移行元のドメインが、ユーザ／所有者に、マイグレーションが完了していること、および認証情報の破棄が移行元のデバイス上で実行されたことを知らせることができる。移行元の認証情報が破棄された場合、ユーザは、ユーザが移行元のデバイスで加入したサービスにもはやアクセスできない。それらのサービスの使用は、今や、新しいプラットフォームに移された。事前にプロビジョニングされた鍵Ｋ_{temp_I}（例えば、１参照）が、メッセージに署名するために使用されてもよい（例えば、端末／ＴＨＳＭのリンクを介した通信は、機密性のためのＫ_{temp_C}ならびに完全性および認証のためのＫ_{temp_I}の使用を必要とする場合がある）。

１９において、ＴＤ_RO,D９７０が、そのＴＤ_RO,D９７０が認証情報を受信し、構成が実行されたことを指示するメッセージをＲＯ９９０に送信することができる。式１９は、ＲＯに、移行先のドメインがマイグレーションされた認証情報に従って再構成されたことを知らせる。ユーザは、今や、移行先のデバイスでサービス、例えば、移行元のデバイスで前に利用可能であったサービスにアクセスすることができる。

２０において、ＴＤ_RO,D９７０が認証情報を受信し、構成を実行したことを指示するメッセージが、ＴＤ_RO,D９７０からユーザ／所有者９４０に送信される。マイグレーションが完了しているという肯定応答が、両方のデバイスによって提供されてもよい。通知されるエンティティは、ユーザ／所有者およびＲＯを含んでもよい。ユーザが認証情報の転送を通知される式１８と同様に、式２０は、ユーザに、移行先のデバイスの再構成が完了していることの情報を与える。これは、ユーザが加入していたサービスが今や移行先のプラットフォームでアクセス可能であることのユーザへの警告を表すことができる。式１８と同様に、署名鍵はＫ_{temp_I}であり、ここで、この鍵は、移行先のデバイスに関連付けられる。事前にプロビジョニングされた鍵の組Ｋ_{temp_C}およびＫ_{temp_I}が、移行元のデバイスと移行先のデバイスの間で別であり異なると仮定されてもよい。

図９Ｂは、図９Ａと似ているＴＳＩＭのドメインのマイグレーションに関するコールフロー図である。しかし、９乃至１２に示されるように、図９Ｂは、移行元の完全性の検証が、移行先のデバイスのＳＤＭによって実行されることができ、移行先のドメインの完全性の検証が、移行元のデバイスのＳＤＭによって実行されることができる場合を示す。

９において、移行元からの完全性検証情報を要求するメッセージが、ＴＤ_RO,D９７０からＴＤ_RO,S９６０に送信されてもよい。９ａにおいて、要求が、ＴＤ_RO,S９６０からＳＤＭ_S／ＴＤ_U,S／ＴＤ_O,S９５０（移行元のＳＤＭ）に渡されてもよい。９ｂにおいて、ＳＤＭ_S／ＴＤ_U,S／ＴＤ_O,S９５０（移行元のＳＤＭ）が、完全性検証情報を取得する。１０において、完全性検証情報が、ＳＤＭ_S／ＴＤ_U,S／ＴＤ_O,S９５０（移行元のＳＤＭ）からＴＤ_RO,S９６０に送信されてもよい。１０ａにおいて、移行元の完全性検証情報が、ＴＤ_RO,S９６０からＴＤ_RO,D９７０に送信されてもよい。１１において、移行元の完全性検証情報が、ＴＤ_RO,D９７０からＳＤＭ_D／ＴＤ_U,D／ＴＤ_O,D９８０（移行先のＳＤＭ）に送信されてもよい。メッセージ１０ａおよび１１において、ＴＤ_RO,Sを発端とする移行先の完全性検証情報の要求が、ＴＤ_RO,Dに、次いで、ＳＤＭＳＤＭ_D／ＴＤ_U,D／ＴＤ_O,D９８０に送信されてもよい。１１ａにおいて、ＳＤＭ_D／ＴＤ_U,D／ＴＤ_O,D９８０（移行先のＳＤＭ）が、移行元の完全性検証情報を検査し、移行先の完全性検証情報を準備する。１１ｂにおいて、移行元の完全性検証情報の検査に基づいてマイグレーションを続行すべきか、または終了すべきかを指示し、移行先の完全性検証情報を転送するメッセージが、ＳＤＭ_D／ＴＤ_U,D／ＴＤ_O,D９８０（移行先のＳＤＭ）からＴＤ_RO,D９７０に送信される。フロー１２乃至１２Ｃは、移行元と移行先の役割を逆にした同様のフローを表す。

図９Ｃは、１またはそれ以上の開示された実施形態が実装され得る例示的な通信システム９００の図である。通信システム９００は、複数の無線ユーザに音声、データ、ビデオ、メッセージング、放送などのコンテンツを提供する多元接続システムである場合がある。通信システム９００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有によってそのようなコンテンツにアクセスすることを可能にする。例えば、通信システム９００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）などの１またはそれ以上のチャネルアクセス方法を使用することができる。

図９Ｃに示されるように、通信システム９００は、ＷＴＲＵ（無線送受信ユニット）９０２ａ、９０２ｂ、９０２ｃ、および９０２ｄ、ＲＡＮ（無線アクセスネットワーク）９０４、コアネットワーク９０６、ＰＳＴＮ（公衆交換電話網）９０８、インターネット９１０、およびその他のネットワーク９１２を含んでもよいが、開示された実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／または中継ノード、ゲートウェイ、フェムトセル基地局、セットトップボックスなどを含んでもよいが、これらに限定されないネットワーク要素を考慮することが理解されるであろう。ＷＴＲＵ９０２ａ、９０２ｂ、９０２ｃ、および９０２ｄのそれぞれは、無線環境内で動作および／または通信するように構成された任意の種類のデバイスであってもよい。例として、ＷＴＲＵ９０２ａ、９０２ｂ、９０２ｃ、および９０２ｄは、無線信号を伝送および／または受信するように構成されてもよく、ＵＥ（ユーザ機器）、移動局、固定または移動加入者ユニット、ポケットベル、セルラ電話、ＰＤＡ（携帯情報端末）、スマートフォン、ラップトップ、ネットブック、タブレット、パーソナルコンピュータ、無線センサー、および家庭用電化製品などを含んでもよい。

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

基地局９１４ａは、ＲＡＮ９０４の一部であってもよく、ＲＡＮ９０４は、その他の基地局、および／またはＢＳＣ（基地局制御装置）、ＲＮＣ（無線ネットワーク制御装置）、中継ノードなどのネットワーク要素（図示せず）も含んでもよい。基地局９１４ａおよび／または基地局９１４ｂは、セルと呼ばれ得る特定の地理的領域（図示せず）内で無線信号を伝送および／または受信するように構成されてもよい。セルは、セルのセクタにさらに分割されてもよい。例えば、基地局９１４ａに関連するセルは、３つのセクタに分割されてもよい。したがって、一実施形態において、基地局９１４ａは、３つのトランシーバ、すなわち、セルの各セクタに対して１つのトランシーバを含んでもよい。別の実施形態において、基地局９１４ａは、ＭＩＭＯ（multiple-input multiple output）技術を採用してもよく、したがって、セルの各セクタに対して複数のトランシーバを利用してもよい。

基地局９１４ａ、９１４ｂは、任意の適切な無線通信リンク（例えば、ＲＦ（無線周波数）、マイクロ波、ＩＲ（赤外線）、ＵＶ（紫外線）、可視光など）であり得る無線インターフェース９１６を介してＷＴＲＵ９０２ａ、９０２ｂ、９０２ｃ、および９０２ｄのうちの１つまたはそれ以上と通信してもよい。無線インターフェース９１６は、任意の適切なＲＡＴ（無線アクセス技術）を用いて確立されてもよい。

より具体的には、上述のように、通信システム９００は、多元接続システムであってもよく、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどの１またはそれ以上のチャネルアクセススキームを使用してもよい。例えば、ＲＡＮ９０４内の基地局９１４ａ、およびＷＴＲＵ９０２ａ、９０２ｂ、９０２ｃは、ＷＣＤＭＡ（広帯域ＣＤＭＡ）を使用して無線インターフェース９１６を確立することができるＵＭＴＳ（UNIVERSAL Mobile Telecommunications System）ＵＴＲＡ（Terrestrial Radio Access）などの無線技術を実装してもよい。ＷＣＤＭＡは、ＨＳＰＡ（High-Speed Packet Access）および／またはＨＳＰＡ＋（Evolved HSPA）などの通信プロトコルを含んでもよい。ＨＳＰＡは、ＨＳＤＰＡ（High-Speed Downlink Packet Access）および／またはＨＳＵＰＡ（High-Speed Uplink Packet Access）を含んでもよい。

別の実施形態において、基地局９１４ａおよびＷＴＲＵ９０２ａ、９０２ｂ、９０２ｃは、ＬＴＥ（Long Term Evolution）および／またはＬＴＥ−Ａ（LTE-Advanced）を使用して無線インターフェース９１６を確立することができるＥ−ＵＴＲＡ（Evolved UMTS Terrestrial Radio Access）などの無線技術を実装してもよい。

その他の実施形態において、基地局９１４ａおよびＷＴＲＵ９０２ａ、９０２ｂ、９０２ｃは、ＩＥＥＥ８０２．１６（すなわち、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）、ＣＤＭＡ２０００、ＣＤＭＡ２０００−１Ｘ、ＣＤＭＡ２０００ＥＶ−ＤＯ、ＩＳ−２０００（Interim Standard 2000）、ＩＳ−９５（Interim Standard 95）、ＩＳ−８５６（Interim Standard 856）、ＧＳＭ（登録商標）（Global System for Mobile communications）、ＥＤＧＥ（Enhanced Data rates for GSM Evolution）、ＧＥＲＡＮ（GSM EDGE））などの無線技術を実装してもよい。

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

ＲＡＮ９０４は、コアネットワーク９０６と通信してもよく、コアネットワーク９０６は、ＷＴＲＵ９０２ａ、９０２ｂ、９０２ｃ、および９０２ｄのうちの１つまたはそれ以上に音声、データ、アプリケーション、および／またはＶｏＩＰ（voice over internet protocol）サービスを提供するように構成された任意の種類のネットワークであってもよい。例えば、コアネットワーク９０６は、呼制御、課金サービス、モバイルの位置に基づくサービス、プリペイド電話、インターネット接続、映像配信などを提供し、および／またはユーザ認証などの高レベルのセキュリティ機能を実行してもよい。図９Ｃには示されていないが、ＲＡＮ９０４および／またはコアネットワーク９０６は、ＲＡＮ９０４と同じＲＡＴ、または異なるＲＡＴを使用するその他のＲＡＮと直接的または間接的に通信してもよいことが理解されるであろう。例えば、Ｅ−ＵＴＲＡ無線技術を利用し得るＲＡＮ９０４に接続されることに加えて、コアネットワーク９０６は、ＧＳＭ無線技術を使用する別のＲＡＮ（図示せず）とも通信してもよい。

コアネットワーク９０６は、ＷＴＲＵ９０２ａ、９０２ｂ、９０２ｃ、および９０２ｄがＰＳＴＮ９０８、インターネット９１０、および／またはその他のネットワーク９１２にアクセスするためのゲートウェイとしての機能を果たしてもよい。ＰＳＴＮ９０８は、ＰＯＴＳ（plain old telephone service）を提供する回線交換電話ネットワークを含んでもよい。インターネット９１０は、ＴＣＰ／ＩＰインターネットプロトコル群のＴＣＰ（transmission control protocol）、ＵＤＰ（user datagram protocol）、およびＩＰ（internet protocol）などの共通の通信プロトコルを使用する相互に接続されたコンピュータネットワークおよびデバイスの全世界的なシステムを含んでもよい。ネットワーク９１２は、その他のサービスプロバイダによって所有および／または運用される有線または無線通信ネットワークを含んでもよい。例えば、ネットワーク９１２は、ＲＡＮ９０４と同じＲＡＴ、または異なるＲＡＴを使用し得る１またはそれ以上のＲＡＮに接続された別のコアネットワークを含んでもよい。

通信システム９００のＷＴＲＵ９０２ａ、９０２ｂ、９０２ｃ、および９０２ｄの一部またはすべては、マルチモード機能を含んでもよく、すなわち、ＷＴＲＵ９０２ａ、９０２ｂ、９０２ｃ、および９０２ｄは、異なる無線リンクを介して異なる無線ネットワークと通信するための複数のトランシーバを含んでもよい。例えば、図９Ｃに示されたＷＴＲＵ９０２ｃは、セルラに基づく無線技術を使用することができる基地局９１４ａと、およびＩＥＥＥ８０２無線技術を使用することができる基地局９１４ｂと通信するように構成されてもよい。

Claims

１または複数のデバイスを備えるシステムであって、各デバイスは１または複数のドメインを備え、各ドメインは前記１または複数のデバイス上で実行されるコンピューティングリソースの構成を備え、各ドメインは、前記ドメインからローカルにまたはリモートに位置することができる、前記ドメインの所有者のための機能を実行するように構成され、各ドメインは異なる所有者を有することができ、少なくとも１のドメインは、前記１または複数のデバイスのユーザにより所有され、少なくとも１つの他のドメインは、リモートの所有者により所有される、システムにおいて、
マイグレーションが要求されたことを示すメッセージを受信するステップであって、第１のドメインまたは前記第１のドメインに関連する認証情報のうちの少なくとも１つが、移行元のデバイスから移行先のデバイスにマイグレーションされる、ステップと、
前記移行元のデバイスから受信された移行元情報、および前記移行先のデバイスから受信された移行先情報を評価するステップと、
前記評価するステップに基づいて、前記マイグレーションが受け入れ可能であることを判定するステップと、
前記マイグレーションを続行するインジケーションを送信するステップと、
を備えることを特徴とする方法。
前記移行元情報は、移行元のポリシー、移行元の構成、移行元の識別情報、または移行元の完全性のインジケータのうちの少なくとも１つを含み、
前記移行先情報は、移行先のポリシー、移行先の構成、移行先の識別情報、または移行先の完全性のインジケータのうちの少なくとも１つを含む、
ことを特徴とする請求項１に記載の方法。
リモートの所有者のポリシーを評価するステップと、
前記マイグレーションが、前記リモートの所有者のポリシーに基づいて受け入れ可能であることを判定するステップと、
をさらに備えることを特徴とする請求項１に記載の方法。
前記移行元情報は、移行元のシステム全体のドメインマネージャが前記マイグレーションを承認したことを示すことを特徴とする請求項１に記載の方法。
前記移行元情報は、前記マイグレーションが、前記第１のドメインに関連する第１のポリシー、および前記移行元のデバイスの第２のドメインに関連する第２のポリシーに違反しないことをさらに示し、前記第１のドメインは、第１のリモートの所有者によって所有され、前記第２のドメインは、第２のリモートの所有者によって所有されることを特徴とする請求項４に記載の方法。
前記マイグレーションが完了したこと、および前記移行元のデバイスが前記認証情報を破棄したかどうかを示す移行元完了メッセージを受信するステップと、
前記マイグレーションが完了したことを示す移行先完了メッセージを受信するステップであって、前記第１のドメインまたは前記認証情報のうちの少なくとも１つが、前記移行先のデバイスのドメインに複製される、ステップと、
をさらに備えることを特徴とする請求項１に記載の方法。
前記移行元完了メッセージは、移行元のシステム全体のドメインマネージャが前記移行先のデバイスの状態を検証したことを示し、
前記移行先完了メッセージは、移行先のシステム全体のドメインマネージャが前記移行元のデバイスの状態を検証したことを示す、
ことを特徴とする請求項６に記載の方法。
前記移行元完了メッセージは、移行元のシステム全体のドメインマネージャが前記移行先のデバイスの完全性を検証したことを示し、
前記移行先完了メッセージは、移行先のシステム全体のドメインマネージャが前記移行元のデバイスの完全性を検証したことを示す、
ことを特徴とする請求項６に記載の方法。
前記メッセージは、前記マイグレーションがユーザによって要求されたことを示すことを特徴とする請求項１に記載の方法。
１または複数のデバイスを備えるシステムであって、各デバイスは１または複数のドメインを備え、各ドメインは前記１または複数のデバイス上で実行されるコンピューティングリソースの構成を備え、各ドメインは、前記ドメインからローカルにまたはリモートに位置することができる、前記ドメインの所有者のための機能を実行するように構成され、各ドメインは異なる所有者を有することができ、少なくとも１のドメインは、前記１または複数のデバイスのユーザにより所有され、少なくとも１つの他のドメインは、リモートの所有者により所有され、
前記１または複数のデバイスのうちの少なくとも１つは、
マイグレーションが要求されたことを示すメッセージを受信し、第１のドメインまたは前記第１のドメインに関連する認証情報のうちの少なくとも１つが、移行元のデバイスから移行先のデバイスにマイグレーションされるように構成され、
前記移行元のデバイスから受信された移行元情報、および前記移行先のデバイスから受信された移行先情報を評価するように構成され、
前記評価することに基づいて、前記マイグレーションが受け入れ可能であることを判定するように構成され、
前記マイグレーションを続行するインジケーションを送信するように構成される、
ことを特徴とするシステム。
前記移行元情報は、移行元のポリシー、移行元の構成、移行元の識別情報、または移行元の完全性のインジケータのうちの少なくとも１つを含み、
前記移行先情報は、移行先のポリシー、移行先の構成、移行先の識別情報、または移行先の完全性のインジケータのうちの少なくとも１つを含む、
ことを特徴とする請求項１０に記載の方法。
前記１または複数のデバイスのうちの前記少なくとも１つは、
リモートの所有者のポリシーを評価し、
前記マイグレーションが前記リモートの所有者のポリシーに基づいて受け入れ可能であることを判定する、
ようにさらに構成されることを特徴とする請求項１０に記載の方法。
前記移行元情報は、移行元のシステム全体のドメインマネージャが前記マイグレーションを承認したことを示すことを特徴とする請求項１０に記載の方法。
前記移行元情報は、前記マイグレーションが、前記第１のドメインに関連する第１のポリシー、および前記移行元のデバイスの第２のドメインに関連する第２のポリシーに違反しないことをさらに示し、前記第１のドメインは、第１のリモートの所有者によって所有され、前記第２のドメインは、第２のリモートの所有者によって所有されることを特徴とする請求項１３に記載の方法。
前記１または複数のデバイスのうちの前記少なくとも１つは、さらに、
前記マイグレーションが完了したこと、および前記移行元のデバイスが前記認証情報を破棄したかどうかを示す移行元完了メッセージを受信するように構成され、
前記マイグレーションが完了したことを示す移行先完了メッセージを受信し、前記第１のドメインまたは前記認証情報のうちの少なくとも１つが前記移行先のデバイスのドメインに複製されるように構成される、
ことを特徴とする請求項１０に記載の方法。
前記移行元完了メッセージは、移行元のシステム全体のドメインマネージャが前記移行先のデバイスの状態を検証したことを示し、
前記移行先完了メッセージは、移行先のシステム全体のドメインマネージャが前記移行元のデバイスの状態を検証したことを示す、
ことを特徴とする請求項１５に記載の方法。
前記移行元完了メッセージは、移行元のシステム全体のドメインマネージャが前記移行先のデバイスの完全性を検証したことを示し、
前記移行先完了メッセージは、移行先のシステム全体のドメインマネージャが前記移行元のデバイスの完全性を検証したことを示す、
ことを特徴とする請求項１５に記載の方法。
前記メッセージは、前記マイグレーションがユーザによって要求されたことを示すことを特徴とする請求項１０に記載の方法。