"1または複数のデバイスを備えるシステムであって、各デバイスは1または複数のドメインを備え、各ドメインは前記1または複数のデバイス上で実行されるコンピューティングリソースの構成を備え、各ドメインは、前記ドメインからローカルにまたはリモートに位置することができる、前記ドメインの所有者のための機能を実行するように構成され、各ドメインは異なる所有者を有することができ、少なくとも1のドメインは、前記1または複数のデバイスのユーザにより所有され、少なくとも1つの他のドメインは、リモートの所有者により所有される、システムにおいて、マイグレーションが要求されたことを示すメッセージを受信するステップであって、第1のドメインまたは前記第1のドメインに関連する認証情報のうちの少なくとも1つが、移行元のデバイスから移行先のデバイスにマイグレーションされる、ステップと、前記移行元のデバイスから受信された移行元情報、および前記移行先のデバイスから受信された移行先情報を評価するステップと、前記評価するステップに基づいて、前記マイグレーションが受け入れ可能であることを判定するステップと、前記マイグレーションを続行するインジケーションを送信するステップと、を備えることを特徴とする方法。前記移行元情報は、移行元のポリシー、移行元の構成、移行元の識別情報、または移行元の完全性のインジケータのうちの少なくとも1つを含み、前記移行先情報は、移行先のポリシー、移行先の構成、移行先の識別情報、または移行先の完全性のインジケータのうちの少なくとも1つを含む、ことを特徴とする請求項1に記載の方法。リモートの所有者のポリシーを評価するステップと、前記マイグレーションが、前記リモートの所有者のポリシーに基づいて受け入れ可能であることを判定するステップと、をさらに備えることを特徴とする請求項1に記載の方法。前記移行元情報は、移行元のシステム全体のドメインマネージャが前記マイグレーションを承認したことを示すことを特徴とする請求項1に記載の方法。前記移行元情報は、前記マイグレーションが、前記第1のドメインに関連する第1のポリシー、および前記移行元のデバイスの第2のドメインに関連する第2のポリシーに違反しないことをさらに示し、前記第1のドメインは、第1のリモートの所有者によって所有され、前記第2のドメインは、第2のリモートの所有者によって所有されることを特徴とする請求項4に記載の方法。前記マイグレーションが完了したこと、および前記移行元のデバイスが前記認証情報を破棄したかどうかを示す移行元完了メッセージを受信するステップと、前記マイグレーションが完了したことを示す移行先完了メッセージを受信するステップであって、前記第1のドメインまたは前記認証情報のうちの少なくとも1つが、前記移行先のデバイスのドメインに複製される、ステップと、をさらに備えることを特徴とする請求項1に記載の方法。前記移行元完了メッセージは、移行元のシステム全体のドメインマネージャが前記移行先のデバイスの状態を検証したことを示し、前記移行先完了メッセージは、移行先のシステム全体のドメインマネージャが前記移行元のデバイスの状態を検証したことを示す、ことを特徴とする請求項6に記載の方法。前記移行元完了メッセージは、移行元のシステム全体のドメインマネージャが前記移行先のデバイスの完全性を検証したことを示し、前記移行先完了メッセージは、移行先のシステム全体のドメインマネージャが前記移行元のデバイスの完全性を検証したことを示す、ことを特徴とする請求項6に記載の方法。前記メッセージは、前記マイグレーションがユーザによって要求されたことを示すことを特徴とする請求項1に記載の方法。1または複数のデバイスを備えるシステムであって、各デバイスは1または複数のドメインを備え、各ドメインは前記1または複数のデバイス上で実行されるコンピューティングリソースの構成を備え、各ドメインは、前記ドメインからローカルにまたはリモートに位置することができる、前記ドメインの所有者のための機能を実行するように構成され、各ドメインは異なる所有者を有することができ、少なくとも1のドメインは、前記1または複数のデバイスのユーザにより所有され、少なくとも1つの他のドメインは、リモートの所有者により所有され、前記1または複数のデバイスのうちの少なくとも1つは、マイグレーションが要求されたことを示すメッセージを受信し、第1のドメインまたは前記第1のドメインに関連する認証情報のうちの少なくとも1つが、移行元のデバイスから移行先のデバイスにマイグレーションされるように構成され、前記移行元のデバイスから受信された移行元情報、および前記移行先のデバイスから受信された移行先情報を評価するように構成され、前記評価することに基づいて、前記マイグレーションが受け入れ可能であることを判定するように構成され、前記マイグレーションを続行するインジケーションを送信するように構成される、ことを特徴とするシステム。前記移行元情報は、移行元のポリシー、移行元の構成、移行元の識別情報、または移行元の完全性のインジケータのうちの少なくとも1つを含み、前記移行先情報は、移行先のポリシー、移行先の構成、移行先の識別情報、または移行先の完全性のインジケータのうちの少なくとも1つを含む、ことを特徴とする請求項10に記載の方法。前記1または複数のデバイスのうちの前記少なくとも1つは、リモートの所有者のポリシーを評価し、前記マイグレーションが前記リモートの所有者のポリシーに基づいて受け入れ可能であることを判定する、ようにさらに構成されることを特徴とする請求項10に記載の方法。前記移行元情報は、移行元のシステム全体のドメインマネージャが前記マイグレーションを承認したことを示すことを特徴とする請求項10に記載の方法。前記移行元情報は、前記マイグレーションが、前記第1のドメインに関連する第1のポリシー、および前記移行元のデバイスの第2のドメインに関連する第2のポリシーに違反しないことをさらに示し、前記第1のドメインは、第1のリモートの所有者によって所有され、前記第2のドメインは、第2のリモートの所有者によって所有されることを特徴とする請求項13に記載の方法。前記1または複数のデバイスのうちの前記少なくとも1つは、さらに、前記マイグレーションが完了したこと、および前記移行元のデバイスが前記認証情報を破棄したかどうかを示す移行元完了メッセージを受信するように構成され、前記マイグレーションが完了したことを示す移行先完了メッセージを受信し、前記第1のドメインまたは前記認証情報のうちの少なくとも1つが前記移行先のデバイスのドメインに複製されるように構成される、ことを特徴とする請求項10に記載の方法。前記移行元完了メッセージは、移行元のシステム全体のドメインマネージャが前記移行先のデバイスの状態を検証したことを示し、前記移行先完了メッセージは、移行先のシステム全体のドメインマネージャが前記移行元のデバイスの状態を検証したことを示す、ことを特徴とする請求項15に記載の方法。前記移行元完了メッセージは、移行元のシステム全体のドメインマネージャが前記移行先のデバイスの完全性を検証したことを示し、前記移行先完了メッセージは、移行先のシステム全体のドメインマネージャが前記移行元のデバイスの完全性を検証したことを示す、ことを特徴とする請求項15に記載の方法。前記メッセージは、前記マイグレーションがユーザによって要求されたことを示すことを特徴とする請求項10に記載の方法。図1乃至9は、開示されたシステム、方法、および手法が実装され得る例示的な実施形態に関連し得る。しかし、本発明が例示的な実施形態とともに説明され得るが、本発明はそれらの例示的な実施形態に限定されず、本発明の同様の機能を実行するために、本発明を逸脱することなくその他の実施形態が使用され得るか、または記載された実施形態に対して修正および追加が行われ得ることが理解されるべきである。さらに、図は、例示的であるように意図されるコールフローを表す場合がある。その他の実施形態が使用され得ることを理解されたい。さらに、フローの順序は、必要に応じて変更され得る。加えて、フローは不必要な場合は省略される場合があり、追加的なフローが追加される場合がある。ユーザがドメイン間の認証情報をマイグレーションすることを可能にするシステム、方法、および手法が開示される。マイグレーションは、1またはそれ以上の別個のドメインを有する1またはそれ以上のデバイスを含むシステムで行われてもよく、各ドメインは、1人または複数の異なるローカルのまたはリモートの所有者によって所有または制御されてもよい。1またはそれ以上のデバイスは、少なくとも1つのプラットフォームでサポートされる1またはそれ以上のドメインを備えてもよい。各プラットフォームは、ドメインのための下位層のコンピューティングリソース、ストレージリソース、または通信リソースを提供してもよい。プラットフォームは、何らかのハードウェア、オペレーティングシステム、何らかの下位層のファームウェアまたはソフトウェアブートコード、BIOS、API、ドライバ、ミドルウェア、もしくは仮想化ソフトウェアなど、および何らかの上位層のファームウェアまたはソフトウェアアプリケーションソフトウェアなど、ならびにそのようなリソースに関するそれぞれの構成データからなってもよい。各ドメインは、少なくとも1つのプラットフォームで実行されるコンピューティングリソース、ストレージリソース、または通信リソースの構成を備えてもよく、各ドメインは、そのドメインのローカルにまたはリモートに位置しうるドメインの所有者のための機能を実行するように構成されてもよい。各ドメインは、異なる所有者を有する場合があり、各所有者は、その所有者のドメインの運用に関する、ならびにそのドメインが存在するプラットフォームおよびその他のドメインに関連するその所有者のドメインの運用に関するポリシーを指定してもよい。加入に基づくサービスを提供するリモートの所有者は、リモート所有者ドメインと呼ばれることがあるドメインの所有権を取得してもよい。さらに、ユーザが、ユーザドメインと呼ばれることがあるドメインの所有権を取得してもよい。第1のドメインから第2のドメインへの認証情報のマイグレーションを開始する要求を開始することができる。例えば、移行元および移行先のデバイスのユーザが、移行元のデバイス上のリモート所有者ドメインに関連する認証情報を移行先のデバイス上のリモート所有者ドメインに転送することを要求することができる。リモートの所有者は、マイグレーションが要求されたことを指示するメッセージを受信することができる。リモートの所有者によって受信されるメッセージは、移行元および移行先のデバイスが、内部検査を実行し、マイグレーションが続行し得ると判定したという指示であってもよい。リモートの所有者が受信するメッセージは、ユーザがマイグレーション要求を開始したという指示であってもよい。リモートの所有者は、移行元のデバイスから受信された移行元情報と、移行先のデバイスから受信された移行先情報とを評価することができる。例えば、移行元情報は、移行元のポリシー、移行元の構成、移行元の識別情報、または移行元の完全性のインジケータのうちの少なくとも1つを含んでもよい。移行先情報は、移行先のポリシー、移行先の構成、移行先の識別情報、または移行先の完全性のインジケータのうちの少なくとも1つを含んでもよい。移行元情報および移行先情報の評価に基づいて、リモートの所有者は、マイグレーションが受け入れ可能であると判定する場合がある。例えば、リモートの所有者は、デバイスに関連するポリシーが、認証情報のマイグレーションと矛盾しないと判定してもよい。そのようなポリシーの評価は、移行元のドメインおよび移行先のドメイン以外のドメインのポリシーを含んでもよい。システムレベルのポリシーは、移行元のポリシーと、移行先のポリシーと、移行元のデバイスおよび移行先のデバイス上のその他のドメインのポリシーとの間の衝突の可能性を判定してもよい。リモートの所有者は、マイグレーションを続行する指示を送ってもよい。さらなる検査を、移行元および移行先のデバイスによって実行することができる。例えば、移行元のデバイスは、移行先のデバイスの状態を評価することができ、移行先のデバイスは、移行元のデバイスの状態を評価することができる。リモートの所有者は、マイグレーションが完了したこと、および移行元のデバイスが認証情報を破棄したことを指示する移行元完了メッセージを移行元のデバイスから受信することができる。リモートの所有者は、マイグレーションが完了し、認証情報が移行先のデバイスのドメインに複製されたことを指示する移行先完了メッセージを移行先のデバイスから受信することができる。I.例示的なマルチドメインシステム図1乃至7は、開示されたシステム、方法、および手法が実装され得る例示的な実施形態に関連する場合がある。しかし、本発明が例示的な実施形態に関連して説明される場合があるが、本発明はそれらの例示的な実施形態に限定されず、本発明の同様の機能を実行するために、本発明を逸脱することなくその他の実施形態が使用され得るか、または記載された実施形態に対して修正および追加が行われ得ることが理解されるべきである。開示されたシステム、方法、および手法が実装され得る例示的なシステムは、1またはそれ以上のデバイスを備えてもよく、それらのデバイスのそれぞれは、少なくとも1つのプラットフォームによってサポートされる1またはそれ以上のドメインを備えてもよい。各プラットフォームは、ドメインのための下位層のコンピューティングリソース、ストレージリソース、または通信リソースを提供してもよい。プラットフォームは、何らかのハードウェア、オペレーティングシステム、およびその他の下位層のファームウェアまたはソフトウェアブートコード、BIOS、およびドライバなど、ならびにそのようなリソースに関するそれぞれの構成データからなってもよい。各ドメインは、少なくとも1つのプラットフォームで実行されるコンピューティングリソース、ストレージリソース、または通信リソースの構成を備えてもよく、各ドメインは、そのドメインのローカルにまたはリモートに位置しうるドメインの所有者のための機能を実行するように構成されてもよい。各ドメインは、異なる所有者を有してもよく、各所有者は、その所有者のドメインの運用に関する、ならびにそのドメインが存在するプラットフォームおよびその他のドメインに関連するその所有者のドメインの運用に関するポリシーを指定してもよい。各ドメインは入力の観点から見た、コンピューティングリソース、ストレージリソース、もしくは通信リソース、または出力の観点から見たそのようなコンピューティングリソース、ストレージリソース、もしくは通信リソースを用いることによってドメインが提供する機能に関して、その他のドメインから隔離され得る。各ドメインは、共通の基礎をなすプラットフォームのコンピューティングリソース、ストレージリソース、もしくは通信リソース、または機能を利用する場合がある。一部のドメインは、共通のプラットフォームによって提供されるそのような機能の一部を共有する場合がある。プラットフォームのリソースおよび/または機能のそのような共有は、各ドメインの共有のリソースまたは機能の使用が、別のドメインのそのような使用から隔離され得るようにして行われてもよい。例えば、そのような隔離は、ドメインのリソースに対するいかなるアクセスが、プラットフォームおよび/またはドメインの所有者によって認可されるユーザ、所有者、またはドメインの外部のその他のエンティティもしくはプロセスにのみ許可され得るように、デバイスのプラットフォームがそのプラットフォームがドメインのそれぞれに提供するリソースに対して厳格なアクセス制御を施行することによって実現されてもよい。プラットフォームは、ドメインの機能のいずれもが、デバイス上のドメインのいずれにも含まれないデバイスのリソースに依存する限りにおいて、単に、デバイス上の隔離されたドメインのいずれの一部でもないデバイスの部分からなる場合もある。同じもしくは異なるプラットフォーム上の、または同じもしくは異なるデバイス上の任意の2つのドメイン間の通信が、安全になされることができ、つまり、ドメインは、例えば、暗号化手段を用いて安全に互いを認証することができ、また、機密性、完全性、およびフレッシュネスfreshnessなどのセキュリティの観点に関してそれらのドメインの間で交換されるメッセージを保護することができる場合がある。ドメインが存在するプラットフォームによって提供される暗号化手段が、任意のそのような2つのドメイン間のそのような安全な通信を行うために使用される場合がある。システム全体のドメインマネージャが、ドメインのうちの1つに存在してもよい。システム全体のドメインマネージャは、そのシステム全体のドメインマネージャが存在するドメインのポリシーを施行してもよく、その他のドメインのそれらのそれぞれのポリシーによる施行を、そのシステム全体のドメインマネージャが存在するドメインに関連して調整してもよい。加えて、システム全体のドメインマネージャは、その他のドメインの間の対話を、それらのその他のドメインのそれぞれのポリシーに従って調整してもよい。システム全体のドメインマネージャが存在するドメインは、そのドメインを収容するデバイスの所有者によって所有されてもよい。あるいは、そのようなドメインは、そのドメインを収容するデバイスを所有していない場合がある所有者によって所有されてもよい。図1は、そのようなシステムの一実施形態を表す。示されるように、システムは、1またはそれ以上のデバイス100、110、および120を含んでもよい。各デバイスは、少なくとも1つのプラットフォームでサポートされる1またはそれ以上のドメインを備えてもよい。例えば、デバイス100は、ドメイン106、および1またはそれ以上のその他のドメイン101、102を備えてもよい。3つのドメインがデバイス100に関して示されているが、その他の実施形態においては、ドメインの数は、より多いか、またはより少なくてもよい。それらのドメイン101、102、106のそれぞれは、デバイスの少なくとも1つのプラットフォーム105で実行されるコンピューティングリソース、ストレージリソース、または通信リソースの構成を備えてもよい。各ドメインは、そのドメインのローカルにまたはリモートに位置しうるドメインの所有者のための機能を実行するように構成されてもよい。例えば、ドメイン106は、デバイスの所有者図示せずによって所有される場合があり、一方、ドメイン101、102は、1人またはそれ以上のリモートの所有者によって所有されてもよい。各ドメインが、異なる所有者を有してもよく、またはデバイスの2つ以上のドメインが、同じ所有者によって所有されてもよい。各所有者は、その所有者のドメインの運用に関する、ならびにそのドメインが動作するプラットフォーム、そのドメインが存在するデバイス、および同じまたは異なるデバイス内のその他のドメインに関連するその所有者のドメインの運用に関するポリシーを指定してもよい。述べられたように、システムはまた、その他のドメインが存在するその他のデバイスを含んでもよい。例えば、デバイス110は、ドメイン111および112を含んでもよく、それらのドメインのそれぞれは、同じリモートの所有者によって所有されてもよい。もちろん、ドメイン111および112の各々は、その代わりに、異なる所有者によってそれぞれが所有されてもよい。ドメイン111、112のそれぞれは、デバイス110のプラットフォーム115で実行されるコンピューティングリソース、ストレージリソース、または通信リソースの構成を備えてもよい。同様に、デバイス120は、ドメイン121および122を含んでもよい。この例に示されるように、それらのドメインのそれぞれは、異なる所有者によって所有されてもよい。あるいは、それらのドメインは、同じ所有者によって所有されてもよい。やはり、ドメイン121、122の各々は、デバイス120のプラットフォーム125で実行されるコンピューティングリソース、ストレージリソース、または通信リソースの構成を備えてもよい。SDMシステム全体のドメインマネージャ:systemwidedomainmanager107が、ドメインのうちの1つに存在してもよい。この例において、SDM107は、デバイス100のドメイン106に存在する。一実施形態において、SDMが存在するドメイン例えば、ドメイン106は、デバイス100の所有者によって所有される。SDM107は、デバイス100で提供される通信メカニズムを介してデバイス100のリモート所有者ドメイン101と通信する。さらに、SDM107は、有線または無線チャネルとなりうる各々の通信チャネル131、132、141、142を介してその他のデバイス上のドメインと通信する。通信チャネル131、132、141、および142は、安全であることができる。SDM107は、そのSDM107が存在するドメイン106のポリシーを施行することができ、その他のドメイン101、111、112、121、122のそれらのそれぞれのポリシーによる施行を、ドメイン106に関連して調整することができる。加えて、SDM107は、その他のドメインの間の対話を、それらのその他のドメインのそれぞれのポリシー、およびSDMが存在するドメインのポリシーその特定のドメインの所有者のポリシーであるに従って調整することができる。例として、一実施形態において、ドメインは、サービスプロバイダによって所有されてもよい。例えば、デバイス100のドメイン102は、単に例として、モバイルネットワークのオペレータなどのサービスプロバイダによって所有されてもよい。ドメイン102は、デバイス100とサービスプロバイダの間の通信を可能にするために、SIM加入者識別モジュールの機能を実行して、サービスプロバイダに対してデバイス100を認証するか、または場合によっては同様な意味合いでデバイスの所有者またはユーザの加入を認証することができる。上述のSDMの機能に加えて、SDM107は、情報にアクセスし、前記1またはそれ以上のドメインによって使用され得るリソースのリストを提供してもよい。SDM107は、リモートの所有者によって所有されるドメインのロードおよびメンテノンスを管理することもできる。SDM107は、そのSDM107が存在するデバイス100のユーザに、そのSDM107がロードすることができるドメインのリストを提供することができ、リスト化されたドメインのうちのどれをロードすべきかをユーザが選択することを要求してもよい。SDMは、1またはそれ以上のドメインをロードするため、ひいてはそれらのドメインの運用をサポートするために十分なプラットフォームまたはデバイスのコンピューティングリソースが存在するかどうかを評価することもできる。やはり上述されたように、SDM107は、本明細書においてはSDPシステム全体のドメインポリシー:systemwidedomainpolicyと呼ばれる場合があるそのSDM107自身のポリシーと、その他のドメインのポリシー、すなわち、DPドメイン固有のポリシーとを施行することに参加することができる。SDM107は、新しいドメインをロードすべきかどうかを評価するときに、1またはそれ以上の既存のドメインのポリシーを考慮してもよい。例えば、リモートの所有者によって所有される所与のドメインのポリシーは、その所与のドメインが、特定の種類のその他のドメインがアクティブになるときに、非アクティブにされることを指定してもよい。別の例において、リモートの所有者によって所有される所与のドメインのポリシーは、その所与のドメインが、特定のその他のリモートの所有者によって所有される別のドメインがアクティブになるときに、非アクティブにされることを指定してもよい。さらに別の例において、リモートの所有者によって所有される所与のドメインのポリシーは、その所与のドメインの運用が、特定の種類のその他のドメインがアクティブになるときにある特定の方法で制限されることを指定してもよい。さらなる例において、リモートの所有者によって所有される所与のドメインのポリシーは、その所与のドメインの運用が、特定のその他のリモートの所有者によって所有される別のドメインがアクティブになるときに、ある特定の方法で制限されることを指定してもよい。SDM107は、これらの種類のポリシーのすべての施行を担ってもよい。SDM107は、リモートの所有者が後で所有権を取得することができるドメインを確立またはロードすることもできる。例えば、そのようなドメインを、そのドメインがいかなるユーザにも所有されていない、本明細書においては初期pristine状態と呼ばれる状態で確立することができ、SDM107は、リモートの所有者によるそのドメインの所有権の確立を管理することができる。そのために、SDM107は、リモートの所有者がドメインの所有権を確立するべきかどうかを判定する際に考慮しうる情報を、リモートの所有者に伝送することができる。この情報は、i所有権が求められるドメインの完全性を証明する情報、およびiiシステムの少なくとも1つのその他のドメインの完全性を証明する情報のうちの少なくとも1つを含んでもよい。この情報は、i所有権が求められるドメインがそのプラットフォームのリソースを用いて動作するプラットフォームの完全性を証明する情報、およびiiシステムの少なくとも1つのその他のドメインがそのプラットフォームのリソースを用いて動作するプラットフォームの完全性を証明する情報を含んでもよい。さらに、この情報は、デバイスの現在の環境に関する情報を含んでもよい。そのような情報は、iシステム内のその他のドメインの数を指示する値、iiシステム内のその他のドメインの大まかな性質を示す情報、およびiii所有権が確立されることが試みられているドメインによって使用可能なプラットフォームのリソースを指定する情報のうちの少なくとも1つを含んでもよい。システムのその他のドメインについてリモートの所有者に情報が提供される程度は、機密性および/または隔離に関するそれらのその他のドメインのそれぞれのポリシーに基づいて調整されてもよい。リモートの所有者がドメインの所有権を取得した後、リモートの所有者は、ドメインに対してある程度の制御を実施することができる。例えば、リモートの所有者がドメインの所有権を確立した後、ドメインは、暗号鍵、構成情報、パラメータ、およびドメインの機能を高めるための実行コードのうちの少なくとも1つをリモートの所有者から受信することができる。別の例において、リモートの所有者がドメインの所有権を確立した後、ドメインは、そのドメインのドメイン固有のポリシーをリモートの所有者から受信することができる。本明細書において開示されたシステムは、1またはそれ以上のドメインの隔離およびセキュリティを提供することもできる。例えば、ドメインのうちの1つまたはそれ以上が、その他のドメインから隔離されるセキュリティの実行およびストレージ環境を含んでもよい。そのような安全な環境を実現するために、図1のデバイス100のプラットフォーム105などの、1またはそれ以上のドメインが確立されるデバイスのプラットフォームは、ルートオブトラストrootoftrust103を備えてもよい。ルートオブトラスト103は、ハードウェアリソースの変更不可能かつ移動不可能な組を含むことができ、そのハードウェアリソースの組は、事前に確立され、ドメインのリモートの所有者を含む他者によって信頼され得る。ドメイン101などのドメインの完全性は、ルートオブトラスト103によって支えられたチェインオブトラストchainoftrustによって確立され得る。例えば、ドメイン101の完全性は、ルートオブトラスト103によって生成され得る、ドメイン101の少なくとも1つのコンポーネントの測定値を、ルートオブトラスト103に記憶され、ドメインの完全性を検証するためにルートオブトラストによって使用され得る基準の完全性の尺度と比較することによって確立されてもよい。あるいは、基準の完全性の尺度が、リモートの所有者によって記憶されてもよく、測定値が、基準の完全性の尺度との比較のためにリモートの所有者に伝送されてもよい。ドメインの完全性は、測定値が基準の完全性の尺度と一致する場合に確認されてもよい。1つの例示的な実施形態において、測定値は、コンポーネントに対して計算されたハッシュを含んでもよく、基準の完全性の尺度は、コンポーネントに対して前に計算されたハッシュを含み、基準の完全性の尺度が本物であることの指示を提供するデジタル証明書が付随してもよい。基準の完全性の尺度は、製造時に、またはデバイスをその所有者に引き渡すときにデバイスに事前にプロビジョニングされてもよい。基準の完全性の尺度は、デバイスの製造者/その所有者への供給の後で通信チャネルを介して例えば、無線通信チャネルを介してリモートのソースから届けられ、引き渡しの後でデバイスにプロビジョニングされてもよい。証明書に包含された基準の完全性の尺度が、デバイスに届けられることができる。そのような証明書は、その証明書のデバイスへの伝達の後で使用するために信頼できる第三者によって証明されてもよい。本明細書において開示されたシステム、ならびのそのさまざまな方法および手法は、多種多様なコンピューティングおよび通信コンテキストで具現化されてもよい。したがって、図1の例示的なデバイス100、110、および120などのシステムのデバイスは、さまざまな形態をとることができる。例として、いかなる限定もなしに、システムのデバイスは、WTRU無線送受信ユニット、UEユーザ機器、移動局、固定もしくは移動加入者ユニット、ポケットベル、セルラ電話、PDA携帯情報端末、M2Mマシンツーマシンデバイス、SIMカード、UICCUniversalIntegratedCircuitCard、スマートカード、位置追跡geotrackingデバイス、センサーネットワークノード、計測デバイス水道、ガス、もしくは電気メータなど、または無線もしくは有線環境で動作することができる任意のその他の種類のコンピューティングもしくは通信デバイスを含んでもよい。以下の図および説明は、WTRUにおける本開示のシステムおよび方法のいくつかのさらなる例示的な実施形態を提供する。しかし、これらの実施形態は例示的であるに過ぎず、本明細書において開示されたシステムおよび方法は、それらの実施形態に決して限定されないことが理解される。むしろ、上述のように、本明細書に記載のシステムおよび方法は、多種多様なコンピューティングおよび通信環境で使用されてもよい。図2は、本明細書に記載のシステムおよび方法が具現化され得るWTRUの一実施形態を表す図である。示されるように、WTRUは、UE200などのモバイル機器を含んでもよい。UE200は、MEモバイル機器210およびTHSMTrustedHardwareSubscriptionModule220を含んでもよい。加えて、THSM220は、THSM-DMデバイス製造者ドメイン221、THSM-DOデバイス所有者ドメイン222、THSM-Uデバイスユーザドメイン223、SDMシステム全体のドメインマネージャ230、ドメイン間ポリシーマネージャ240InterDomainPolicyManager、ならびにROリモートの所有者のドメインA224、ROのドメインB225、およびROのドメインC226などの1またはそれ以上のROドメインをさらに含んでもよい。さらに、UE200は、次の図示されていないコンポーネント、すなわち、プロセッサ、受信機、送信機、およびアンテナを含んでもよい。本明細書に記載の例示的な実装は、図2に関連して説明されるコンポーネントなどのコンポーネントに関連する場合がある。THSMは、SIMの機能、USIMの機能、ISIMの機能、およびアクセスネットワーク加入によって通常実行される加入管理機能を含む信頼できる加入管理機能を提供するハードウェアに基づくモジュールである場合がある。THSMは、ハードウェアで保護されたモジュールである場合がある。THSMは、関連するセキュリティの特徴を用いて具体的に設計されるハードウェアを含んでもよい。THSMは、複数の隔離されたドメインを内部でサポートされてもよい。ドメインは、ROリモートの所有者と呼ばれる区別可能な所有者によって獲得または所有され得る。ROによって獲得されたドメインは、それぞれのROの代理として振舞うことがありうる。ドメインのうちの1つまたはそれ以上は、TSIMTrustedSubscriptionIdentityManagementなどの加入管理機能を実行することができる。TSIM機能を有する複数のドメインが単一のTHSMに存在する場合があるので、THSMは、複数のROに関する加入管理をサポートすることができる。TSIMが可能なドメインの管理の一部は、SDMシステム全体のドメインマネージャと呼ばれる単一の管理機能によって実行されてもよい。その他の部分は、個々のドメイン内、および個々のドメイン上で個々に管理されてもよい。UMTSUniversalMobileTelecommunicationSystemに関して説明されるが、当業者は、本明細書に記載の方法および装置が、本出願の範囲を超えることなくその他の環境に適用可能であることを認めるであろう。TSIMは、加入アプリケーションsubscriptionapplicationの代表例である場合がある。例えば、3G-UMTSネットワーク内で動作するWTRUに実装される場合、TSIMは、その機能の一部として、UMTS-AKAauthenticationandkeyagreement機能を含む加入に関連する機能のすべてを含んでもよい。TSIMは、UICCなどの特定のハードウェアに拘束されない場合がある。これは、UICCにしか存在し得ないUSIMと対照的である。そうではなく、TSIMは、本明細書において説明されるTHSMに実装され得る。当業者は、本明細書において説明されるTHSMの機能が、ETSIヨーロッパ電気通信標準化協会のUICCの要件に準拠するUICCなどのUICCもしくは同様のスマートカード、またはグローバルプラットフォームGlobalPlatformの仕様に準拠するスマートカードに、本出願の範囲を超えることなしに組み込まれ得ることも認めるであろう。WTRUは、THSMおよびMEモバイル機器を含んでもよい。MEは、モデム、無線機、電源、およびWTRUで通常見られるさまざまなその他の特徴を含んでもよい。THSMは、別個のハードウェアに基づくモジュールを含んでもよい。THSMは、WTRUに埋め込まれてもよいし、またはTHSMは、独立していてもよい。THSMは、たとえそれがWTRUに埋め込まれているとしても、MEとは論理的に分かれてもよい。THSMは、それぞれがドメインの特定の所有者によって所有され、安全で信頼できるサービスおよびアプリケーションを提供する所有者の利益のために動作させられる1またはそれ以上のドメインを含んでもよい。したがって、例えば、DMのドメインは、TDDMと表記される場合があり、THSMにおけるTDDOドメインとしてのDOのドメインが、MEで実行されるのに安全でないかまたは都合の悪くなりうるセキュリティ上の注意を要する機能およびアプリケーションを実行することができる。一部のドメインは、1またはそれ以上のサービスプロバイダ例えば、MNOモバイルネットワークのオペレータ、WLAN無線ローカルエリアネットワークのプロバイダもしくはWiMaxのプロバイダなどのその他の通信ネットワークのオペレータ、モバイル決済、モバイル発券、DRMデジタル著作権管理、モバイルTV、もしくは位置に基づくサービスのサービスプロバイダなどのアプリケーションサービスプロバイダ、またはIMSIPMultimediaCoreNetworkSubsystemサービスプロバイダによって所有および管理されてもよい。加入管理は、サービスプロバイダによって所有されるドメインによってサポートされてもよい。簡単にするために、THSMのドメインで実装される加入管理機能は、以降、TSIM機能と表記される場合がある。TSIM機能のサポートは、ドメインによって変わる場合がある。例えば、サポートされるTSIM機能は、モバイル端末のUICC上のUSIMおよびISIMアプリケーションによって提供される機能と同様の機能を含む場合がある。THSMは、UICCと同様に、TSIMによって提供されるもの以外の機能、アプリケーション、およびデータを含む場合がある。TSIMは、ソフトウェアユニットまたは仮想アプリケーションであってもよい。TSIMは、初め、特定のネットワークのオペレータまたはPLMN公衆陸上移動体ネットワークに関連する認証情報を持たない場合がある。TSIMは、UMTSセルラアクセスネットワークに関する加入認証情報/アプリケーションの管理に関連する場合がある。例えば、TSIMは、UMTSの認証鍵などの強いKistrongsecretの管理を含んでもよい。M2Mの場合、TSIMは、MCIMM2MConnectivityIdentityManagementを含んでもよい。THSMは、TPMtrustedplatformmoduleまたはMTMmobiletrustedmoduleを有するコンピューティングデバイスに見られる場合があるRTMrootoftrustofmeasurementと同様のCRTMCoreRootofTrustofMeasurementユニットを含んでもよい。THSMのCRTMは、例えば、THSMのブート時にTHSMのブートコードの完全性を測定することができる。完全性の尺度は、Extend操作を通じて、例えば、THSMのブートコード、BIOS、および随意にバージョン番号、ソフトウェアの構成、またはリリース番号などのTHSMの製造者の特徴に対して暗号学的ダイジェスト値操作を適用することによって計算されてもよい。例えば、完全性の尺度は、SHA-Xなどの暗号学的ハッシュアルゴリズムのバージョンを用いて計算されてもよい。THSMは、保護されたストレージに完全性の尺度を記憶するように構成された、TPMまたはMTMに見られるRTSrootoftrustforstorageと同様のCRTScoreRoTofStorageユニットを含んでもよい。THSMは、THSMの完全性の測定値を外部の問い合わせ元に報告するように構成された、TPMまたはMTMに見られるRTRrootoftrustforreportingと同様のCRTRCoreRoTofReportingを含んでもよい。したがって、THSMは、信頼の測定、記憶、および報告の観点でTPMまたはMTMの能力と同様の能力を効果的に提供することができる。THSMは、複数の信頼できるステークホルダのエンジンを実現する能力も含んでもよい。さらに、THSMは、各々の複数のステークホルダの信頼できるサブシステムを実現するように構成されてもよい。したがって、THSMは、TCG-MPWGMobilePhoneWorkingGroupの仕様によって定義された信頼できるモバイル電話と同様であることができる。THSMは、例えば、本明細書において説明されるコアRoTCoreRoT能力を用いて、複数の内部のステークホルダドメインstakeholderdomainをビルドするように構成され得る。ステークホルダは、THSMのDMデバイスの製造者、THSMのDOデバイスの所有者、またはTHSMのDUデバイスのユーザであってもよい。DUは、DOと同じである場合があるか、またはDOとは異なる場合がある。THSMごとに2人以上のDUが存在してもよい。ステークホルダは、DOによって明確に借りられるかまたは所有されるドメインの異なるROリモートの所有者であってもよい。例えば、MNOなどの3GPP第3世代パートナーシッププロジェクトのPLMNのオペレータ、IMSサービスプロバイダ、非3GPPアクセスネットワークのオペレータ、または付加価値のあるアプリケーションサービスプロバイダが、ステークホルダであってもよい。一部のドメインは、必須である場合があり、その場合、それらのドメインは、THSMの製造時に事前に構成される場合がある。例えば、DMのドメインは必須である場合があり、事前に構成されたファイルに従ってブート時にビルドまたはロードされ得る。DOのドメインも必須である場合があり、事前にプロビジョニングされた構成にビルドされ得る。あるいは、そのドメインは、ダウンロードされる構成ファイルに従ってビルドされ得る。DMのドメイン以外のドメインは、それらのドメインがドメインの所有者によって獲得claimedおよび所有ownedされる前に、RTORemoteTakeOwnershipプロセスにかけられる場合がある。特定のドメインがRTOプロセスを経る前は、不特定の所有者のための初期ドメインが存在する場合がある。この場合、当該ドメインに関して獲得されたいかなる特定の所有権も存在しない。THSM上のドメインは、THSM-MEインターフェースを介してMEと情報を通信および交換することができる。例えば、ドメインは、起動またはRTOプロセス中にMEと通信する場合がある。THSM-MEインターフェースを介して交換されるデータの保護が、必要とされる場合がある。THSM-MEインターフェースにわたったすべての通信の完全性の保護が、必要とされる場合がある。例えば、完全性の保護は、事前にプロビジョニングされた一時的な鍵、または認証された鍵交換メカニズムを用いることによって交換される鍵などの暗号鍵を使用することができる。暗号鍵は、Ktemp_Iのように対称的であるか、または完全性のためにTHSMによって使用される公開鍵もしくは秘密鍵のためのKpub/priv_THSM_temp_I、および完全性のためにMEによって使用される公開鍵もしくは秘密鍵のためのKpub/priv_ME_temp_Iのように非対称的である場合がある。一時的な鍵は、インターフェースの保護のために使用され得る。例えば、一時的な鍵は、有効期間に関連付けられ得るか、または一度もしくは所定の回数だけ使用されてもよい。THSM-MEインターフェースにわたった通信の機密性が、暗号化手段を用いてやはり提供される場合がある。事前にプロビジョニングされた一時的な鍵、または認証された鍵交換メカニズムを用いることによって交換される鍵が、使用され得る。暗号鍵は、暗号化のためのKtemp_Cのように対称的であるか、または暗号化のためにTHSMによって使用される公開鍵もしくは秘密鍵のためのKpub/priv_THSM_temp_C、および暗号化のためにMEによって使用される公開鍵もしくは秘密鍵のためのKpub/priv_ME_temp_Cのように非対称的である場合がある。本明細書に記載のRTOの方法および装置は、簡単にするために、事前にプロビジョニングされた対称的な一時的鍵の使用に関連する。しかし、当業者は、その他の鍵の実装が、本出願の範囲を超えることなしに使用され得ることを認めるであろう。THSM-MEとROの間とで平文で渡されるメッセージに対するリプレーアタックに対する防護策が、提供される場合がある。THSM-MEインターフェース上で送信される各メッセージは、ノンスの使用による新鮮さの質を有する場合がある。簡単にするために、本明細書において説明されるRTOプロトコルは、ME-THSMインターフェースを介して交換されているすべてのメッセージのリプレーに対抗する保護を含み得るが、当業者は、その他のインターフェースの保護構成が、本出願の範囲を超えることなしに使用され得ることを認めるであろう。署名が、ハッシュに適用されてもよい。例えば、ハッシュは、SHA-Xアルゴリズムによって生成されてもよい。信頼できる第三者が、CertTSIM証明書を用いて、THSMに関連するKTSIMPrivおよびKTSIMPubなどの秘密-公開鍵の対を証明することができる。信頼できる第三者は、CertRO証明書を用いて、ネットワークに関連するKROPrivおよびKROPubなどの鍵の別の組を証明することもできる。これらの証明書は、問題のドメインに割り当てられた保護されたストレージに記憶されてもよい。公開鍵、KROPubは、THSMプラットフォーム、具体的には、TSIMによって、ROからの署名を検証するために、またはROに送信されるメッセージを暗号化するために使用されてもよい。秘密鍵、KROPrivは、署名の目的で、または対応する公開鍵を用いてTSIMによって暗号化されたメッセージを復号するためにネットワークによって使用されてもよい。公開-秘密鍵の対、KTSIMPubおよびKTSIMPrivは、TSIMとROの役割が入れ替えられることを除いて同様の機能を含んでもよい。あるいは、ROとTSIMの両方において、暗号化および署名のために別個の鍵の対が存在してもよい。鍵の対KROPrivおよびKROPub、ならびにKTSIMPrivおよびKTSIMPubは、所有者、ユーザ、またはそれら両方によって選択された特定のネットワークサービスに依存する場合がある。ROなどの各サービスプロバイダは、そのプロバイダに関連するTHSM上の各ドメインに関するそのサービスプロバイダ独自の証明された公開-秘密鍵の対を有する場合がある。選択されたサービスは、鍵の対のどの組が使用されるかを判定することができる。例えば、公開秘密鍵の対の組は、選択されたサービスプロバイダおよびTHSM上の関連するドメインによって判定されてもよい。使用される鍵の対のいかなるネゴシエーションも存在しない場合がある。公開または秘密鍵の対は、サービスプロバイダによって判定されてもよく、THSMのサブシステムまたはドメインに厳密に関連付けられてもよい。THSMのTDDOが、SDMシステム全体のドメインマネージャを構成してもよい。SDMは、SDPシステム全体のドメインポリシーを含む事前に構成されたファイルを保護するように記憶することができる。SDMは、SDPに準じてTHSMに関するROのドメインをビルドまたはロードすることができる。SDMは、DOのドメインの初期構成に含まれてもよい。SDMは、事前に構成されたSDPを用いて、その他のどのドメインがどのような順序でビルドされるべきかを判定してもよい。SDMは、ROドメインに代わって、ROドメインによって要求されたときに、TPESTHSMプラットフォーム環境サマリ:THSMPlatformEnvironmentSummaryおよびTPIATHSMプラットフォーム完全性証明:THSMPlatformIntegrityAttestationを準備し、供給することができる。TPESは、THSMの直近の環境environmentについての概略情報を記述することができる。そのような情報は、ドメインの数と、THSM上の機密性および隔離、ならびに要求元のドメインと通信するため、および要求元のドメインと機能またはリソースを共有するために利用可能でありうる、THSM上の任意の残りのリソースに関して、それぞれのドメインポリシーによって調整されるか、または許可されるドメインの大まかな性質とを含んでもよい。TPIAは、THSMのドメインのうちの1またはそれ以上の完全性証明IntegrityAttestationの集合を含んでもよい。TPIAは、前記ドメインをサポートするプラットフォームに関する完全性証明を含んでもよい。TPIAは、THSM上の初期ドメインに対してRTOプロセスを実行することに関心のあるROなどの外部のベリファイアverifierに、対象のドメインおよびそれらのドメインをサポートするプラットフォームの信頼の状態を証明するために使用されてもよい。ROまたはTDROROのドメインは、SDMにTPIAを要求してもよい。SDMは、SDPに準じて要求を受け入れるかまたは拒否してもよい。SDMは、THSMのサービス担当者などの物理的に存在するデバイスの所有者と対話して、ビルドされるべきであるその他のドメイン、およびどのような順序でその他のドメインがビルドされるべきかをインタラクティブに特定してもよい。さらに、SDMは、ユーザのドメインに、THSMの物理的に存在するユーザと対話して、ビルドされるべきドメインおよびビルドの順序に関する入力を提供するように要求してもよい。この情報は、ドメインのビルドプロセスの入力として使用されてもよい。THSMは、ROのドメインに関するRTOプロセスを実行するとき、リモート所有権取得プロトコルの完了前に、4つの異なるシステム状態に達するように構成されてもよい。THSM-Pre_Bootシステム状態は、THSMが電源オンpoweredonにされていないことを指示することができる。THSM_TDDM_LOAD_COMPLETEシステム状態は、THSM上のDMのドメインが、THSMの電源オンの後の第1のステップとしてビルドまたはロードされたことを指示することができる。THSM_TDDO_LOAD_COMPLETEシステム状態は、TDDODOのドメインが利用可能な最後の構成にビルドまたはロードされたことを指示する場合がある。この利用可能な最後の構成lastconfigurationavailableは、DOのドメインがそれ自体に対するRTOプロセスを経ていない場合には初期構成であってもよく、またはRTO後のpostRTO構成であってもよい。DMのドメインが、DOのドメインをビルドまたはロードすることができる。DOのドメインが少なくとも1つのRTOプロセスを経る前は、DOのドメインは、初期状態である場合があり、いかなる特定のDOによっても獲得または所有されていない場合がある。初期ドメインは、シェルshellを含んでもよい。初めてDOのドメインがビルドまたはロードされるとき、利用可能な最後の構成以降、最後の構成LastConfigurationと呼ばれるは、事前に構成されたファイルから来る。あるいは、最後の構成がROのドメインに対するRTOプロセスによるものである場合、THSM上のその特定のドメインが、リモート所有権取得プロトコルを少なくとも一回経てもよく、リモートの所有者が、TDROの所有権を取得してもよい。これは、リモート所有権取得の完了時に、プラットフォーム上に構成された信頼できるサブシステムを指示することができる。この状態が到達されるとき、またはこの状態が到達される前、その特定のROは、その他のタスクの実行を開始することができる。THSM_TDRO_LOAD_COMPLETEシステム状態は、TDROROのドメインが利用可能な最後の構成にビルドまたはロードされたことを指示する場合がある。この利用可能な最後の構成は、ROのドメインがそれ自体に対するRTOプロセスを経ていない場合には、初期構成であってもよく、またはRTO後の構成であってもよい。DMのドメインが、ROのドメインをビルドまたはロードすることができる。DOのドメインが少なくとも1つのRTOプロセスを経る前は、DOのドメインは、初期状態であってもよく、いかなる特定のDOによっても獲得または所有されていなくてもよい。初期ドメインは、シェルを含んでもよい。初めてROのTDがビルドまたはロードされるとき、最後の構成は、事前に構成されたファイルから来てもよい。あるいは、最後の構成がROのTDに対するRTOプロセスによるものである場合、THSM上のその特定のTDが、RTOプロトコルを少なくとも一回経てもよく、ROが、TDROの所有権を取得してもよい。これは、RTOの完了時に、プラットフォーム上に構成された信頼できるサブシステムを指示する。この状態が到達されるときまでに、その特定のROは、その他のタスクの実行を開始することができる。TDROROのTDがMNOのTDである場合、この段階までに、MNOのTDは、そのTDRO上に実現された最終的なTSIMTrustedSubscriptionIdentityManagement機能を提供することができる。あるいは、SDMシステム全体のドメインマネージャが、DOのTDではなくDMのTDに実装されてもよい。DOは、適切な認可データをDMのTDに提供した後、DMのTDによって提供されるSDMを用いて、THSM上のさまざまなリモート所有者TDを作成し、ロードし、その他の管理を行うタスクを実行することができる。この場合のTHSMのシステムのブートシーケンスおよびRTOプロセスのシーケンスの詳細は、本明細書に記載のシーケンスとは異なる場合があるが、本出願の範囲内である。この場合の起動およびRTOプロセス、ならびにDOまたはDOのTDがDMのTDによって提供されたSDMをどのように使用することができるか、例えば、どのような種類の認可データが提供され得るかおよびその認可データがどのように提供され得るかの説明は、本明細書に記載のものと同様である場合がある。例えば、スマートカードとして具現化されるTHSMが、カード発行者の代わりにカード上のセキュリティドメインを管理することを担う、グローバルプラットフォームなどの規格によって仕様が決められたカードマネージャ機能をサポートする機能を有するカードマネージャを含んでもよい。カード発行者は、DMと同様であってもよく、カードマネージャは、SDMの機能の一部を含んでもよい。したがって、カードマネージャは、DMのドメインに保持されるSDMと同様である場合がある。第1の実施形態において、MEは、セキュアブート能力を提供するように構成されてもよく、THSMは、完全なMTMの能力を提供するように構成されてもよい。電源オン時に、MEは、安全にブートすることができる。例えば、MEは、OMTPopenmobileterminalplatformの信頼できる実行環境TR0の仕様などに従って非TCGのセキュアsecureブートを実行することができる。ブート時に、THSMは、例えば起動することによってTHSMのTDDMDMのドメインを最初にビルドし、次いで、初期のTHSMのTDDODOのドメインをビルドすることができる。DOとDUが別である場合、THSMは、THSMのDUのドメインもビルドすることができる。THSMのTDDMは、THSMにおいて保護され、ブート時に利用可能にされる事前に構成されたファイルを用いて最初にビルドされてもよい。THSMのTDDOは、おおむね、事前に構成されたファイルを用いてビルドされ得るが、RTOプロセスを用いてビルドされることもある。THSMのTDDOは、RTOプロトコルを経る場合がある。このプロトコルは、TDROROのドメインに関するRTOプロトコルと同じ形態をとってもよいし、またはこのプロトコルは、異なるプロトコルであってもよい。THSMのTDDOがRTOプロトコルを経ない場合、所有権を取得するために必要とされる認証情報は、事前に構成され、事前にプロビジョニングされる。THSMのTEDOは、DOによって所有されてもよい。DOは、実際の人間のユーザもしくは所有者、会社もしくはその会社のIT情報技術部門などの組織、またはリモートのNOネットワークオペレータであってもよい。THSMのTDUは、THSMのTEDOに事前にプロビジョニングされた事前に構成されたファイルを用いてビルドされてもよい。THSMのROドメインは、THSMのDOのSDPシステム全体のドメインポリシーに準じて初期構成に最初にビルドされてもよい。THSMのROドメインは、ROとのRTOプロセスを経る場合がある。DOのドメインのSDMは、SDPに準じて、ROのドメインに対するRTOプロセスを管理することができる。THSMのROがMNOであり、したがって、ROのドメインがMNOのドメインである場合、そのようなMNOのドメインは、iMNOのドメインがMNOにどのように登録され得るか、ii加入認証情報例えば、USIMまたはMCIMの秘密鍵KiおよびIMSI国際移動体加入者識別番号などが、MNOのモバイルネットワークからTHSM上のMNOのドメインにどのように複製され、次いでそこにプロビジョニングされ得るか、ならびにiii加入認証情報をダウンロードしたときに、そのような認証情報を処理もしくは使用する機能、またはさらには加入管理機能を提供するドメインが、デバイス間でどのようにマイグレーションされ得るかを定義するプロトコルをやはり経てもよい。そのようなプロトコルは、それぞれ、i登録プロトコル、ii認証情報ロールオフプロトコル、およびiiiマイグレーションプロトコルと呼ばれる場合がある。THSMのROドメインは、RTOが完了した後、ROにそのROドメイン自体の構成を証明および報告することができる。MEの信頼構築メカニズムtrustbuildingmechanismが電源投入時のセキュアブートプロセスを実行することに制限される場合がある第1の実施形態において、MEの構成は、MEまたはTHSMによってさらに証明可能でない場合がある。あるいは、MEは、セキュアブートを完了するときに、自己完全性検査を実行し、IV完全性の値を生成することができる。MEは、OTAovertheair方法を用いたUMTSのセキュリティモードの特徴などのセキュリティモードの特徴に従って、機密性および完全性の保護のためのエンジンなどのソフトウェアをインストールすることができる。随意に、ROのドメインの所有権がROとのRTOプロセスを介して取得されるときに、ROは、RTOプロセスが完了することを許可するために、そのROが受け入れることができるTHSMの条件に関するそのRO独自のポリシーをダウンロードするか、またはその他の方法でインポートし、次いでそのポリシーを有効化してもよい。ROのドメインは、ROが、THSM全体の条件、THSMのその他のドメインのビルド構造の条件、またはそれらの両方に同意するとき、THSMのプラットフォーム上のそのドメイン自身のインストールをゲートキープgatekeepするように構成されてもよい。したがって、RTOプロセスの一部として、ROは、DOの条件またはドメインビルド計画domainbuildingplanを特定するために、DOのドメインのSDMと何らかの情報を交換し、そのような条件がROにとって受け入れ可能である場合にのみRTOプロセスが完了することを許可してもよい。ROドメインは、権利を有する場合もあり、そのような権利を行使して、ROが最初にTHSM上のそのROのRTOが完了したROのドメインをビルドすることに同意した後、THSMの条件またはドメインビルド計画のあらゆる変更によってそのROドメインが更新されるか、またはそのような変更を通知されることを可能にするように構成されてもよい。ROのDPドメイン固有のポリシーが、ROのドメインが通知されることを必要とする場合がある変更の種類を指定することができる。SDMは、意図されるROに関連するROドメインに対するRTOプロセスを開始することができる。これは、ROのドメインが初期の、獲得されていないunclaimed状態にあるときに行われてもよい。例えば、ROのドメインは、DOのドメインおよびDOによってドメインXTDXと命名され得る。このドメインは、まだ獲得されていないシェル、または初期状態で作成されてもよい。そのような場合、SDMが、RTOプロセスを開始することができ、それによって、意図されるROにドメインTDXの代わりに連絡する。ROがこのドメインに対するRTOプロセスを経ると、SDMは、この同じドメインに対する別のRTOプロセスをもはや開始しない場合がある。その代わりに、RO自身が、この特定のドメイン上で別の種類の所有権取得プロセスを開始することができる。そのような所有権取得プロセスは、これまでに規定されたRTOプロセスとは、前者が、デバイスの所有者/ユーザまたはデバイス自体によっておそらくはSDMまたはDOのドメインの調整のもとでローカルで開始されるのではなく、リモートの所有者によってリモートで開始されることができるという点で異なる場合がある。DOは、ROのドメインがRTOプロセスを経ており、したがって、適切なROによって獲得または所有された後であっても、任意のROのドメインを削除、破壊、または切断する権限を保有する場合がある。しかし、DOは、概して、ROのドメイン内に記憶された秘密を知ること、またはROのドメイン内で実行された中間の計算または関数を知ることはできない場合がある。SDMが初期のROのドメインに対するRTOプロセスを開始する前に、SDMは、ドメインのビルドのための利用可能なリソースのリストを調べることができる。リストは、DMのドメインによって保有され得る。SDMは、所望のドメインDesiredDomainリストも調べることができる。所望のドメインリストは、DOのドメインTDDOに保有されてもよい。SDMは、SDPシステムのドメインポリシーと、DMのドメインからの問い合わせのために利用可能でありうる、THSMのおよびプラットフォームの既存のドメインの信頼の状態を含む現在の状態とを調べることもできる。この情報は、特定のROのドメインに対する所望のRTOプロセスが、利用可能なリソースおよびポリシーのもとで可能であり、所望のドメインリストのもとで望ましく、THSMの既存のドメインの状態、例えば信頼の状態のもとで許されるかどうかを判定するために使用されてもよい。あるいは、TDROリモートの所有者のドメインが、それ自体でRTOプロセスを開始し、管理する場合がある。TDROは、RTOプロセスの前は、獲得されておらず、初期状態である場合がある。初期のROのドメインTDROは、そのTDROが起動時にその意図されるROに連絡すること、およびRTOプロセスを自律的に開始することを可能にする事前に構成された機能を含んでもよい。随意に、RTOプロセスは、TDROに、THSMの所有者またはユーザに指示し、次いで、RTOプロセスを開始するためのTHSMの所有者またはユーザからの同意nodを得るようにさせた後で、開始されてもよい。作成されターゲットの、リモートの所有者RO_targetによって所有されるように意図されたが、まだRTOプロセスを介して所有されておらず、初期状態のままであるドメインTDは、以降、TDROtargetと呼ばれる場合がある。別の代替的方法において、TDROは、特定のROとの少なくとも1つのRTOプロセスを経た場合があり、TDROは、現在、ROによって獲得または所有されている場合がある。DO、またはドメインTDDOなどのTHSM上のDOの代理が、同じROのドメインに対する別のRTOプロセスを開始することを許可されるかことができるかどうかは、ROのポリシーおよび/またはSDMのポリシーに依存する場合がある。SDMは、RTOの目的を調べることができ、そのポリシーの構造内の許容できる目的または活動に基づいて、そのような新しいRTOが続行することを許可すべきかどうかを判定してもよい。リモートシグナリングによるRO、またはTDROROのドメインは、同じROとの、そのドメインに対する別のRTOプロセスを開始してもよい。これは、ROが、TDROの内の構成ファイル、セキュリティポリシー、または実行コードを更新する必要があるときに行われてもよい。ROは、更新をダウンロードすることができる。更新は、非RTOの、OTAovertheair更新プロセスを介して行われてもよい。しかし、場合によっては、ROまたはTDROは、別のRTOプロセスを用いて一部のファイルまたはコードを更新する場合がある。初期TDROがそのTDROに対するRTOプロセスを開始するとき、そのTDROは、DMのドメインによって保有されうる、ドメインのビルドのための利用可能なリソースのリストを調べるために、SDMに依存する必要がある場合がある。TDROは、DOのドメインに保有される場合がある所望のドメインリストと、SDPシステムのドメインポリシーと、DMのドメインからの問い合わせのために利用可能でありうる、THSMの既存のドメインの信頼の状態を含む現在の状態とを調べるためにやはりSDMに依存する場合がある。この情報は、特定のROのドメインに対する所望のRTOプロセスが、利用可能なリソースおよびポリシーのもとで可能であり、所望のドメインリストのもとで望ましく、THSMの既存のドメインの状態または信頼の状態のもとで許されるかどうかを判定するために使用されてもよい。SDMのポリシーは、DOに関するTOtakeownershipプロセス中に構成されてもよい。このプロセスは、ブートプロセス中に施行されるあらかじめ存在する構成の構造によってローカルで行われてもよい。DOのTOは、リモートで行われることもでき、このプロセスは、デバイスの所有者でないリモートの所有者に関するRTOプロセスの場合と異なり、DOのドメインに対するTOプロセスの場合は、RTOを阻むかまたは許可するためのSDMの調査が呼び出されない場合があることを除いて、本明細書において規定された、デバイスの所有者のドメインではないドメインの所有権取得での使用を対象とするRTOプロセスと同様であってもよい。SDPは、ローカル物理的に存在し、デバイスと対話するDOによってで、または遠隔に位置するデバイスの所有者とのリモートの対話を含むようにして実行され得るDOの所有権取得プロセス中に確立されてもよい。SDPのコンポーネントは、すべての非DOドメインに共通の許容できる活動または目的のリストである。このリストは、ドメインの所有権取得が許されないリモートの所有者を指定する追加的なエントリを含んでもよい。第2の実施形態において、MEは、セキュアブート能力を有してもよく、そのMEのブートコードの一部のセキュアブートsecureboot検査の一部を実行するためにTHSMに依存する場合がある。MEは、OMTPのTR0のセキュアブートなどの非TCGセキュアブートを実行することができる。THSMは、THSMに与えられた物理的な保護を利用するutilizeように、MEの完全性を検査するために使用されてもよい。例えば、MEが、THSMに生データを送信することができ、THSMが、MEの完全性を検査することができる。WTRUは、MEとTHSMの間の安全なチャネルを提供するためのメカニズムと、THSMがMEの完全性の検査をする目的で、少なくとも、安全にTHSMにコードまたはデータを送信すること、およびTHSMと安全なチャネルを介するなどして安全に通信することを任され得る、MEのある程度信頼できるsomewhattrustworthy部分とを実装することができる。THSMは、そのTHSMの中に、MEの代わりにMEのコードの一部を記憶することもできる。これらのコードが、ブートプロセス中にMEにロードされてもよい。THSMは、そのTHSM自体とMEとの間で、THSMが、そのハードウェアに基づく保護メカニズムのおかげでより信頼できる環境である場合があるので、MEの完全性の検査を実行する役割、またはMEに関するコードの一部を記憶およびロードする役割を担ってもよい。第3の実施形態において、THSMは、セキュアブート、またはMEのコードの完全性の検査の一部を実行してもよい。これは、ROに証明可能である場合がある。MEは、単一の信頼できるエンティティ、MTEMobileTrustedEnvironmentを含んでもよい。MTEは、MEの残りの部分よりも信頼されるME内の論理的に分かれた環境であってもよい。MTEは、ハードウェアに基づくRoTrootoftrustなどのいくつかのハードウェアに基づく保護メカニズムを利用してもよい。MEの基本コードがロードされた後、MTEがロードされてもよい。MTEは、外部のベリファイアverifierに、信頼できる署名鍵の使用など、信頼の証拠を提供することができるという意味で、信頼できるエンティティである場合がある。MTEは信頼できるエンティティであるが、MTEは、実際のTPMに関連する測定プログラムコードであるcorerootoftrustformeasurementを持たない場合がある。受電デバイスpowereddeviceとしてのMEが、THSMが動作することができるプラットフォームを提供する限り、MEは、本明細書においてはMEプラットフォームと呼ばれる場合がある。MTEは、MEプラットフォームの完全性の証拠を収集し、その証拠を、MTE内の保護された署名鍵を用いることによって提供される少なくとも完全性の保護のもとで、ブート後のSDMなどのTHSM内の信頼できるエンティティに転送するように構成されてもよい。THSMは、TCGのTPMまたはMTMのような完全性の測定および検証機能を実装するので、THSMは、エクステンドextend操作を実行するTCGのTPMまたはMTMの能力をやはり実装する場合があり、それによって、PCRPlatformConfigurationRegisterのための新しい値を計算するために、現在のソフトウェアの測定値が、ソフトウェアのロードの履歴的状態を指示するPCRの現在の値と組み合わされる。THSMは、ソフトウェアコンポーネントの完全性の生の測定値であるダイジェスト値、またはPCRの値を、THSMに対するMEプラットフォームの信頼性の証明のために使用され得る別の完全性データに変換するためのメカニズムが実装されてもよい。簡単にするために、MEプラットフォームの完全性の収集されたデータは、以降、MPIDMEプラットフォーム完全性データと表される場合がある。THSMは、MEまたはMTEのためのドメインを維持しない場合がある。THSMは、そのTHSMが計算されたダイジェストを照合する証明された尺度を、事前に構成されたファイルからか、またはDMとリアルタイムで連絡を取ることによってかのいずれかで取得することができる場合がある。一致が判定されるならば、MEの証明が、その後に続いてもよい。MTEは、モデル番号、どの種類のサービスを実行するようにMEが意図されているか、および誰のためにサービスを実行するようにMEが意図されているかなどの、MEの環境を示すデータを収集してもよい。簡単にするために、そのようなMEの環境の説明は、以降、MPESMEプラットフォーム環境サーベイと表される場合がある。THSMのDOのROは、そのRO自身のドメインとMEプラットフォームの両方の完全性を証明することができる。この証明は、例えば特許文献1で規定された、M2Mに関連するTRETrustedEnvironmentのM2ME検証M2MEValidation機能と同様である場合がある。MEは、継続的に、自律的に、またはTHSMからの要求に応じて、そのMEの変化する状態をTHSMに報告することができる。第4の実施形態において、MEとTHSMの両方は、完全なMTMの機能を実行するように構成されてもよい。MEまたはそのドメインの信頼性が、MEによってまたはドメインによって直接証明可能である場合がある。MEのROドメインは、その状態を継続的にまたは要求があるごとにROに報告してもよい。THSMのROドメインは、同様に機能してもよい。MEのROドメインおよびTHSMのROドメインによる報告は、同期されてもよく、互いに結び付けられてもよい。また、報告は、プロトコルフローの共通セッションを用いて行われてもよい。この実施形態において、MEは、本明細書に記載のTHSMのいくつかの機能を実行するように構成されてもよい。MEは、それぞれが特定の所有者に関する、そのME自体の1またはそれ以上のドメインを含んでもよい。これらのドメインは、THSMによる信頼できるエンティティのプロパティを含んでもよい。そのようなドメインは、DMデバイス製造者ドメインおよびUユーザドメインを含んでもよい。これらのドメインは、THSMと同様にして事前に構成されてもよい。ME上のドメインをTHSM上のドメインと区別するために、文字列MEが、ドメイン自体を指定する文字列を下付きで添えられてもよい。したがって、DMに関するドメインは、MEDMと表され得る。THSM上のDOデバイス所有者ドメインは、SDMに存在するSDPシステム全体のドメインポリシーへの準拠を保証するために、ME側のドメインを監視してもよい。MEで各ドメインが作成されると、SDMとの通信が、それぞれの新しいドメインの構成をTHSMのDOに知らせることができる。MEは、THSMのSDMの方法と同様の方法で機能することができるMEPDMプラットフォームドメインマネージャと呼ばれる場合があるドメインマネージャを含んでもよい。MEPDMは、MEDMに存在してもよく、初め、DMによって定義された事前の構成を有してもよい。この最初の構成は、THSM上のTDDMの最初の事前に構成された定義の最初の構成と、その目的および機能の点で同様である場合がある。MEDMの設定は、TDDOがTHSMにおいてインスタンス化された後に行われるように時間が決められてもよい。SDMが、MEDMに関する設定が完了していることを知らされるとき、SDMは、システム全体の制約によって、SDPから生じた、またはSDPを反映するポリシーの制約を課す場合がある。SDMは、幾人かのリモートの所有者およびTHSM上のそれらの所有者のドメインのリストを保持する場合がある。リスト内の所有者のうちの1人に属するドメインがME上で作成され、管理されることになる場合、SDMは、ME上のこれらのドメインの作成および管理をある程度制御することができる。この実施形態において、MEは、完全なMTMの機能を有する場合がある。したがって、MEは、CRTMcorerootoftrustformeasurement、CRTRcorerootoftrustforreporting、およびCRTScorerootoftrustforstorageを含んでもよい。THSM上では、ドメインの加入機能は、TSIM機能によって管理されてもよい。THSMにおける1つのドメインおよびME上のもう1つのドメインのような2つのドメインが同じROに関する場合、THSM上のドメインが、加入機能およびそのリモートの所有者のためのそのドメインの管理などの、非常に高レベルのセキュリティおよび/または信頼を必要とするROのための機能またはサービスのために使用されてもよい。一方、ME上のドメインは、あるレベルのセキュリティまたは信頼をやはり必要とするが、THSM上のドメインから期待される機能およびサービスに関して必要とされるのと同じレベルまでは必要としない場合がある、同じROに関する機能またはサービスのために使用されてもよい。事前に構成されたファイルからビルドされないドメインは、RTOremotetakeownershipプロセスによって構成されてもよい。通常のROリモートの所有者に関する、MEのためのRTOは、THSMのためのRTOと同様である場合がある。ME上のドメインは、リモートの所有者に関する加入管理のために使用されるように意図されていない場合がある。その代わりに、それらのドメインは、ユーザ、所有者、リモートの所有者、またはこれらの任意の組み合わせの利益のために、計算およびリソースを多く消費するタスクを実行するために使用されるように意図される場合がある。例えば、これらのドメインは、THSM上の比較的限られたリソースに対しては実行可能でない場合があるタスクを実行することができる。ME上のドメインは、一度作成され、その後、明示的に削除されるまでME内に残るのではなく、これらのドメインは、仮想化に似て、ブート時に、または、さらにはランタイムセッション上で作成されることができ、それらのドメインの特定の目的のために一時的にセッションに基づいて使用されることができるという意味で、よりつかの間のephemeralまたは一時的であるtemporary場合もある。ME上のドメインのリモートの所有者は、その他のリモートの所有者によって所有されるME上のその他のドメイン、またはTHSM上のそのようなその他のドメインのリソースの割り当ておよびそれらの目的の証明されたサーベイを要求および取得するという観点で、同じレベルの特権を持たない場合がある。モバイルの信頼できるプラットフォームのデバイスの所有者が、MNOリモート所有者としても知られる特定のPLMNによって事前に割り当ておよび初期化されていない空のblankWTRUを購入するための方法を提供し、制限なしにモバイルネットワークのオペレータの任意の選択を可能にすることが有利である。当該方法は、UEUMTSデバイスなどのWTRUのRTOプロセスなどの所有権取得プロセスを実行することを含む場合があり、リモートの所有者は、PLMNのオペレータ、または加入アプリケーションが対象とするその他の同様のオペレータであり、THSMの内部のドメインであり、正しいROによって獲得され得るROのドメインなどのサブシステムを設定し、カスタマイズし、確定する。上述のように、THSMTrustedHardwareSubscriptionModuleは、ISIMIMSSubscriptionIdentityModuleのような、PLMNのオペレータのための加入アプリケーション、およびその他の付加価値のあるサービスに関する機能を含む耐タンパ性ハードウェアコンポーネントモジュールとして構築されてもよく、またはそのようなモジュールをそのTHSMの中に含んでもよい。THSMは、WTRUから取り外し可能であるか、または取り外し不可能であってもよい。UICCの拡張されたバージョン、またはグローバルプラットフォーム規格に準拠したスマートカードが、そのようなTHSMの1つの実施形態であってもよい。所有権取得操作は、オペレータまたはPLMNとWTRUとの間の基本的な信頼trust関係を構築する。この手順は、汎用的なtrustedソフトウェア構成を有する初期エンジンを備えるblanktrustedTSIMをインストールし、インスタンス化することができる。このサブシステムは、プラットフォームがそのプラットフォームの初期構成およびセキュリティ属性の証拠を提供することができる場合に、リモートの所有者によって証明されcertified得る。図3および3Aは、このプロセスが特に本明細書に記載の第1の実施形態に関連するときのこのプロセスの例を示す。リモートの所有者は、ユーザに要求されたサービスを提供し、適切なセキュリティポリシーを設定し、サービスに合ったデバイスの構成を施行するモバイルネットワークである場合がある。このプロトコルに関する所有者は、ローカルである場合がある。図3および3Aは、例示的な起動およびRTOプロセスを示す。MEは、ブート前の状態304を有する場合がある。306において、デバイスが、電源をオンにされ得る。308において、MEは、セキュアブート非TCGを実行することができる。MEは、基本コードがブートされた状態310に到達することができる。さらに、312において、MEは、THSMに基本ブート完了basebootcompleted信号を送信することができる。314において、MEは、基本構成に従って追加的なソフトウェアをロードすることができる。316において、MEのブートは、完了したアプリケーションがロードされた状態である場合がある。318において、MEは、THSMにブート完了メッセージを送信することができる。THSMは、ブート前の状態330にある場合がある。334において、THSMは、TDDMをロードすることができる。THSMは、構成中に、事前に構成されたファイルを受信することができ、例えば、336は、事前に構成されたファイルの使用を示す。338において、THSMは、TDDMビルドTDDMbuild状態基本構成状態:basicconfigurationstateに到達することができる。THSMは、例えば、340で示されるように、ROドメインのための利用可能なリソースに関するDMの仕様を受信することができる。342において、TDDMは、TDDOをビルドすることができるTDDOはSDMを含んでもよい。344において、THSMは、例えば、保存された構成ファイルを用いて、前のRTOにより利用可能となり得るドメインをビルドすることができる。346において、THSMは、TDDOがビルドされた状態SDMを含むに到達することができ、TDDOは、DOによって獲得されていないか、または獲得されている場合がある。350において、TDDOは、TDUをビルドすることができる。352において、入力が、DOから受信され得る。354において、THSMは、TDUビルド状態に到達することができ、TDUは、獲得されていないか、または獲得されている場合がある。356において、THSMは、DOまたはDUから例えば、ファイルまたは対話によって、DOがどのドメインをビルドしたい場合があるかを指定する入力を受信することができる。358において、TDDOは、ROドメイン、TDROをビルドすることができる。ここで図3Aを参照すると、362において、THSMは、TDROがビルドされた状態に到達することができ、TDROは、ROによって獲得されていないか、または獲得されている場合がある。366において、SDMが、TDROにRTOを実行するように要求することができるか、またはTDROが、SDMにそのTDROがRTOを実行することを通知するまたは要求することができる。370において、TDROは、RTOプロセスを開始することができる。380において、代表的なリモートの所有者RO1...ROnが存在する。384において、情報が交換され得る。例えば、リモートの所有者とのRTOプロセスの一部として、交換される情報は、証明、構成、ポリシー、目的、証明書本明細書においてはCERTとも呼ばれる、鍵、およびTDROに対するSPのうちの1つまたは複数を含み得る。随意に、ROは、RTOプロセス中にDOの環境またはドメイン計画domainplanを見つけることができ、ROがその環境/計画に同意する場合、プロセスが継続することを許可することができる。372において、THSMは、さまざまなドメインに関するシステム構成をキャプチャ/更新し、その情報を保存し、その情報をTHSM内の不揮発性の保護されたメモリに記憶することができる。374において、THSMは、RTO後のTDROを有する状態に到達することができる。第1の実施形態を参照すると、DOのRTOによって形成されたポリシーのドメインが、後続のRTOプロセスのドメインの構成に影響を及ぼす規定を含んでもよい。このRTOプロトコルは、DOではないROに適する場合がある。ドメイン固有のポリシーDPが、RTOのトランザクション中にダウンロードされ得る。DOに関するDPは、そのようなDPDPDOが、THSM内の、リモートで所有される場合があるその他のドメインをビルドし、保守するために使用することを対象とするSDPシステム全体のドメインポリシーを含み得るという点で、ROに関するDPとは異なる場合がある。RTOプロセスの前、またはRTOプロセス中に、ドメインのROは、TTP信頼できる第三者:trustedthirdpartyから、THSMのドメインのすべてのすべてまたは一部をサポートするハードウェアまたはソフトウェアの構成および現在の完全性の状態に関するRIMROReferenceIntegrityMetricを取得することができ、と表され得る。場合によっては、TTPは、ROが検証することに関心がある、ドメインを含むTHSMのHWおよびSWの一部に関するRIMROを提供することができる場合がある。2つ以上のTTPが、RIMROを提供するために必要とされる場合があり、ROは、それらのRIMROを収集し、集合的な基準尺度を形成する。RTOプロセスを受けるTHSMのTDROtargetターゲットのドメインは、THSMのSDMの助けを借りて、そのドメインのROに、署名されたTPIAを提供するように構成され得る。TPIAは、TDROtargetのRTOプロセスの完了を許可する前に、ターゲットのドメインのROが検証することに関心があるTHSM上のドメインの個々の完全性証明および/またはデバイスのプラットフォームの完全性証明の連なりである場合がある。TDROtargetTHSMのターゲットのドメインは、THSMのSDMの助けを借りて、そのドメインのROに、署名されたTPESを提供することができる場合がある。TPESは、THSMのその他のドメインの数および性質と、TDROtargetの利益のために使用され得るTHSMのプラットフォームのリソースなどの任意の残りの利用可能なリソースとを含むTHSMの環境のサマリを含むことができ、と表され得る。あるいは、ROが関心のあるすべてのドメインのすべての証明を含み得るTPIAを報告する代わりに、SDMは、そのSDMがすべてのそのようなドメインの完全性を検査し、それらのドメインが信頼できるとみなすという、準自律的なステートメントである場合がある署名されたステートメントを提供することができる。この証明は、ドメインの集合の完全性のローカルでの検証を含んでもよい。ローカルのベリファイアは、THSM上の各ドメインに関する有効な構成のリストを含んでもよい。SDMは、ローカルのベリファイアに、AIKによって署名され得るTPIAを提供することができる。個々の完全性証明の検証は、それらの完全性証明が、対応するローカルに記憶された構成のリストのエントリに一致することを必要とする場合がある。SDMは、TPIAを構築するために必要な完全性の測定、ロギング、およびPCRへのエクステンションextensionを実行し、各ドメインの信頼性を証明することができる。これらの測定およびそれらのエクステンションは、必要とされるドメインに関する証明が行われたことを確定するためにベリファイアによって使用されてもよい。検証が行われると、ローカルのベリファイアは、関連する証明が行われたというステートメントを準備することができ、証明された鍵の組Ksignverifypriv、Ksignverifypubからの秘密鍵を用いてこのステートメントに署名する。署名されたTPESと連結された署名された検証ステートメントを含むメッセージは、と表され得る。TTPからの{RIMRO}ならびにTDROtargetからの署名されたTPIAおよび署名されたTPESを受信すると、ROは、TDROtargetが、RTOプロセスを継続する目的でROが同意できると認めるTHSM内の環境などの環境内にあるかどうかと、TDROtargetおよびROが関心のある任意のその他のドメインをサポートするハードウェアまたはソフトウェアが、それらの完全性がROにとって同意可能である状態にあるかどうかとを検証することができる。初期ドメインに関するRTOプロトコルは、電源投入時に開始することができる。随意に、RTOプロトコルは、電源投入後に開始する場合がある。THSMのセキュアブートが完了するとき、結果として生じるドメインのビルドは、一回目などの最初の電源オン時のプラットフォームの状態か、またはデバイスが前に起動され、その後、電源を切られたときの前の状態のプラットフォームの状態かのどちらかを反映する内容を有する構成ファイルによって判定されてもよい。したがって、デバイスは、TDDMのビルド、初期のTDDOの状態、および初期のTDUの状態を含む基本構成である場合がある。あるいは、WTRUは、より後の構成、例えば、TDDM、RTO後のTDDOの状態、およびRTO後のTDUの状態を含む、前の起動およびドメインのビルドまたはRTOプロセスに基づく構成である場合がある。別の代替的方法において、WTRUは、図2に示されたドメインなどの追加的なドメインの拡張された組も含む構成である場合がある。そのようなドメインは、前の作動セッション中に作成された場合があり、所有権が、前のセッション中に行われた前に実行されたRTOプロセスによってそれぞれの所有者により取得された場合がある。第1の実施形態を参照すると、プラットフォームの安全なおよび信頼できるエンティティとして、THSMが、所有権取得プロトコルを制御し、MEが最初の信頼できる状態であるか否かを判定することができる。事前にプロビジョニングされた鍵Ktempが、THSM-MEインターフェースに渡って送信されるメッセージの機密性を保護するために使用されてもよい。簡単にするために、暗号化されたメッセージAは{A}によって表される場合があり、メッセージの署名は[A]によって表される場合があり、表記IDMEおよびIDTHSMは、それぞれ、MEおよびTHSMの事前にプロビジョニングされた一時的なIDを表す。RTOの開始は、TDDOのSDMが、ROとのRTOプロセスの後にその特定のROによって獲得されるように意図される獲得されていない初期ドメインに対するRTOを開始することを含んでもよい。ユーザは、MEプラットフォームの電源オンを開始することができる。電源オン時に、MEは、そのMEがアライブaliveになる基本コードの、OMTPによって定義されるブートなどの非TCGnonTCGセキュアブートを実行することができる。非TCGセキュアブートプロセスの一部として、MEの基本コードの完全性が、自律的に検査されてもよい。第3の実施形態を参照すると、MTEMobileTrustedEnvironmentが、基本コードのブートプロセスの完了に続いてロードされてもよい。署名鍵を用いて、MTEは、MEプラットフォームの構成の完全性を証明することができる。MEは、基本コードをロードした後、そのMEが最小限の安全な設定でブートしたことを指示する信号を、THSMに周期的に送信することができる。THSMのDOのドメインは、信号が送信されるときまだブートしていない場合があるので、MEは、THSMのDOのドメインからから肯定応答信号を受信するまで異なるランダムなノンスnonce_1とともに同じ信号を送信することができる。この信号は、と表され得る。第3の実施形態を参照すると、このシグナリングは、と表され得る。THSMは、安全にsecurelyブートすることができ、したがって、THSMは、そのTHSMのDMのドメイン、初期のDOのドメイン、ユーザのドメイン、およびROによって所有されるように意図されているが、まだ所有されていない場合がある少なくとも1つの初期ドメインをロードした場合がある。また、これらのドメインをロードする際、ドメインのコードの状態のそれぞれの完全性が、ドメインのそれぞれのRIMreferenceintegritymetricsと照合されてもよい。照合は、TCGのMPWGの仕様などの仕様に従って実行されてもよい。TDDOデバイスの所有者のドメインは、事前に構成されたpreconfigured構成か、またはそのTDDOがDOのためのRTOプロセスを既に経ている場合の最後に保存された:Lastsaved前のRTO後の:postpreviousRTO構成かのどちらかにロードされてもよい。DOのドメインは、ロードされるとき、SDMシステム全体のドメインマネージャを含んでもよい。SDMは、その他のROリモートの所有者に属するべきドメインのビルドまたはロードおよび保守を管理することができる。SDMは、DMのドメインからのドメインのために利用可能なリソースなリストlistofresourcesavailablefordomainsを調べることができ、TDDOが保護するSDPシステム全体のドメインポリシーも調べることができる。ブート時に、SDMは、THSMの人間のユーザまたはDO人間の所有者にビルドされ得るドメインのリストlistofdomainsthatcanbebuiltを示し、ビルドされるべきドメインを選択する入力を要求することもできる。ユーザまたは所有者からその入力を得た後、SDMは、人間の所有者またはユーザからの応答で指定されたドメインだけをビルドすることに進むことができる。SDMは、MEと対話して、これらのトランザクションのためのUIユーザインターフェースを提供することができる。セキュアブートの後、THSMのTDDOは、MEにTHSMブート完了メッセージを送信することができる。メッセージ内に、TDDOは、ロードされたROのドメインの数および名称などの、ドメインの現在の状態の外部に開示可能なサマリも含めることができる。TDDOのSDMは、ドメインの現在の状態のサマリの外部への開示の程度を判定し、施行することができ、そのような判定は、SDP、ならびに/またはTHSMおよび/もしくはME上のドメインのDPドメイン固有のポリシーに基づくことができる。TDDOは、受信されたnonce_1をSHA-X完全性検査コード入力の一部として含めることによって、このメッセージ内のPackage_1の受信に対して肯定応答することができ、これは、以下のように表され得る。IDTHSMのようなTHSMのIDは、DMのドメインTDDMに保有されてもよく、TDDMのIDと同じであってもよい。DOのドメインTDDOは、そのTHSMのIDをTDDMから取り出して、式6のPackage_2を構築することができる。THSMブート完了信号に応答して、MEは、そのMEのブートプロセスを完了することを継続することができる。そのMEのブートプロセスを完了した後、MEは、THSMのTDDOに、と表され得るメッセージを送信することができる。以下は、DOのドメインのSDMが、現在初期のROのドメインに対するRTOプロセスを開始し、管理する場合に当てはまる。TDDOがMEからPackage_2を受信した後、RTOプロセスが開始されてもよい。TDDO内のSDMシステム全体のドメインマネージャは、初期のターゲットのROのドメインTDROTargetにRTOプロセスを開始するように要求することによってRTOプロセスを開始することができる。SDMは、自律的に、または人間の所有者もしくはユーザに促されたときにこのプロセスを開始することができる。SDMは、TDROに、ターゲットのROに関するRTOプロセスを開始する要求を送信することができる。要求は、ROのIDまたはNAIネットワークアクセス識別子:NetworkAccessIdentifierなどの、ターゲットのROが誰なのか、および現在の要求の有効期間を含んでもよい。要求の一部としてか、または要求に付随する別個のパッケージとしてかのいずれかで、SDMは、許可されるROのドメインに関するSDPの条件SDP’sConditionsforAllowedRO’sDomains以降、SCARDと呼ばれるのリストも送信することができる。SDMは、意図されるRTOプロセスの後で、それが完了されるときに、TDROに関するターゲットのドメイン計画TargetDomainPlanも送信することができる。このメッセージングは、と表され得る。TDROTargetは、Package_4の受信に応答して、その要求を受け入れるかまたは拒否するかのどちらかを行うことができる。この要求は、ROがROのドメインの所有権を取得することを許可する提案offerとして解釈されてもよい。TDROTargetは、事前に構成された基準、またはロードされたROのドメインポリシーの独自の初期バージョンに基づいて決定を行うことができる。TDROTargetは、RTOを開始する要求、SCARD、およびターゲットのドメイン計画を調べ、実際のターゲットのリモートの所有者が不在の場合に、実際のターゲットのリモートの所有者の利益のためにそのような決定を行うように構成され得る。これは、と表され得る。初期のTDROTargetターゲットのROのドメインが、このプロセスを開始することができる。TDROTargetは、RTOプロセスに関するそのTDROTargetの最終ドメイン計画finaldomainplanをSDMに知らせることができる。SDMは、要求を許可するかまたは拒否することができる。SDMが要求を許可する場合、TDROは、RTOプロセスを開始することができ、これは、と表され得る。Package_5aまたはPackage_5bの受信に応答して、SDMは、TDROTargetに対するRTOプロセスに関して、事前に構成されるか、もしくはTDDOに対するRTOプロセスによって取得され得るSDPシステムのドメインポリシー、事前に構成されるか、もしくは所有者によって供給されるかのいずれかである場合がある所望のドメインのリスト、DMのドメインによって保有され、継続的に更新され得るドメインのための利用可能なリソースのリスト、またはTHSM内のドメインの現在の状態を調べることができる。SDMは、THSM上の複数のドメインをビルドもしくは保守するために利用可能な、仮想マシンのスレッドのためのメモリもしくはリソースなどの十分なリソースが存在するかどうか、THSM内のドメインの現在の状態が、所望のドメインリストで指定された状態と一致するかどうか、所望のドメイン内の任意の新しいドメインのビルドもしくはロードが、THSM内のドメインの現在の状態によって支持可能であり、しかもSDPのもとで許されるかどうか、またはドメインのうちの1つもしくは複数がRTOプロセスを経る必要があるかどうかも評価することができる。SDMが、TDROTargetが、利用可能なリソース、THSMの既存のドメインの現在の状態、およびSDPに従ってRTOプロセスを経ることができると判定する場合、SDMは、この判定TDROTargetを指示し、TDROTargetおよびその周辺のドメインのROの評価のためにRTOプロセス中にそのROに転送されるべきいくつかの完全性証明を準備することに進むことができる。これは、と表され得る。SDMは、人間のユーザに、例えば、WTRU上に表示されるメッセージによって、そのSDMが特定のドメインに対するRTOプロセスを開始しようとしていることを指示することができる。SDMは、人間のユーザまたはDO人間の所有者にRTOプロセスを開始する所望のドメイン、および所望のROdesireddomainstostarttheRTOprocessandthedesiredROのリストを示すこともでき、その指示に応答して所有者またはユーザが指定するROドメインに対してのみRTOプロセスを開始することに進む。SDMは、これらのトランザクションのためのUIユーザインターフェースを提供するMEと対話することができる。TDROTargetは、そのTDROTargetがTPIAおよびTPESを構築するために使用することができる材料を準備するようにSDMに要求することができる。これは、と表され得る。第3の実施形態を参照すると、この要求は、と表され得る。TPIAおよびTPESの要求で、ROは、そのROがSDMからTPIAおよびTPESに関するどの種類の情報を求めるかを指定することができる。例えば、TPIAに関して、ROは、TPIA自体ではなく、そのROが完全性を検証したいドメインの名称または範囲を指定する場合がある。同様に、TPESに関して、ROは、TPES自体ではなく、ドメインの所有者のNAIなどの公開IDを指定する場合がある。第3の実施形態を参照すると、ターゲットのROは、MEプラットフォームの完全性に関する具体的な情報以降、MPIDと呼ばれると、MEの環境に関するその他の情報とをやはり要求してもよい。あるいは、ROは、MTEがロードされ、MPIDおよびMPESがMEからSDMに送信されたことの単純なインジケータを要求する場合がある。MTE、MEプラットフォームに存在する信頼できるエンティティは、それがSDMによってそのようにすることを要求したときに、値MPIDおよびMPESを準備することができる。この要求は、と表され得る。MTEは、MEから構成データを収集し、MPIDを構築することができる。環境データも、MPESMEプラットフォーム環境サーベイ:MEPlatformEnvironmentSurveyを生成するために獲得されてもよい。これらの値は、経時的に変わり得る現在のMEの状態に基づく場合がある。更新された値が、MEの状態の変化の後で、将来の要求が行われる場合に、および将来の要求が行われるときに、SDMに送信されてもよい。概して、MTEは、SDMに、と表され得る応答を送信することができる。MTEは、そのMTEの公開鍵KMTEPubを含む、CAによって署名され得る証明書を提供することができる。したがって、SDMは、CAの署名の検証によってこの公開鍵が本物であることを確かめ、それによって、KMTEPubを用いてMTEからのメッセージの完全性を検査することができる。SDMは、TPIAおよびTPESを準備し、その後、それらをTDROTargetに転送することができる。TPIAの準備のために、SDMは、初期TDROの、初期TDROによる完全性証明、TEDMの、TEDMによる完全性証明、TEDOの、TEDOによる完全性証明、TEUの、TEUによる完全性証明デバイスのユーザがDOと異なる場合、およびROが関心のある任意のその他の既存のTDROの、そのTDROによる完全性証明などの完全性証明を収集することができる。あるいは、SDMは、PCRから完全性の値を収集した後、コードおよびデータなどの測定ログのローカルの自律的な検査および再計算のプロセスによって、ドメインを、それぞれのドメインに関するPCRからのダイジェスト値と照合することができる。これは、TTPPCAが、それぞれのドメインを含むべき最新のコードを知らず、TTPが、WTRU上のTPMまたはMTMに関して証明されているAIKにリンクされた署名鍵を証明することができるときに実行されてもよい。TTPは、ROがSDMからのTPIAを比較するために使用することができるダイジェストの尺度に関する基準値を提供するように構成されない場合がある。SDMは、ドメインに関するコードのダイジェストを再計算し、それらのダイジェストをクォートquotedされたPCR値と比較することによって、そのSDMがドメインに関して得たPCRのクォートquoteが最新であるかどうかをローカルで検査することができる。このローカルの検査が通ったならば、SDMは、TPIAに署名をし、それをTDROtargetに、およびMTEまたはMEを経由してROtargetに渡すことができる。別の代替的方法、3元的な検証において、SDMは、TPIAの一部として、ドメインのダイジェストおよび実際のコードなどの測定ログを提供することができる。ROは、ダイジェストとともにコードを得るとき、TTPからダイジェストに関する基準尺度を得ることができ、測定ログからダイジェストを再計算することができ、それを、そのROがTDROTargetから受信したクォートされたPCRのダイジェストおよびそのROがTTPから受信したダイジェストの基準尺度と比較することができる。測定ログをともなうかまたはともなわないTPIAは、PCRのクォートが行われたローカル時間localtimeの指示も含むことができ、個々のドメインに関するダイジェストのクォートに実質的にタイムスタンプを付ける。これは、ドメインのPCRのダイジェストのそれぞれがSDMによって最後に取得されたときの何らかの指示を提供する。測定ログがROに送信されない場合に、PCRのタイムスタンプを付けられたクォートは、ROがTPIAで指示された証明を検証する必要があるときに、ローカルのダイジェストが取得され、TPIAに含められた時間が、証明の検証でそのダイジェストを使用することを許可できるだけ最近であるかどうかを判断する観点で、何らかの追加的な情報をROに提供することができる。そのようなタイムスタンプを付けることに使用されている時計は、信頼できる時計である場合がある。3元的な検証が失敗する場合、ROは、更新された基準尺度、またはそのROが所望のダイジェストを計算することができる測定ログをTTPがそのROに提供することを要求することができる。ROは、3元的な検証を再試行することができる。検証が成功である場合、RTOは継続する。検証が失敗し、3元的な検証の成功がROのポリシーによって必要とされる場合、RTOは終了されてもよい。DOのドメインの完全性証明に関して、SDMは、その完全性証明をSDMのネイティブの機能によるなどして自律的に取得することができる。DOのドメインの完全性証明を除く完全性証明に関して、SDMは、それぞれのその他のドメインに、独自のそれぞれの完全性証明を生成し、署名するように要求することができる。要求に、SDMは、受信者が、SDMがドメインからの完全性証明を要求および取得するための権限を有するかどうかを検査するために使用することができるトークンなどの認可データを含めることができる。要求は、ターゲットのRO、およびターゲットのROの要求の転送者としてのSDMが受信者のドメインの完全性を検査ために必要とする受信者のドメインのPCRPlatformConfigurationRegisterの範囲を含んでもよい。この要求は、と表され得る。Nは、SDMがPCR値を収集するドメインの数であるものとしてドメインi,i=1,2,...,Nと表記されるドメインのそれぞれは、初めに、証明の要求の中の認可データを検査し、次に、証明の要求で指定されたPCRの範囲のPCR値を取り出す。この操作は、と表され得る。SDMは、TPIAを実行して、証明のすべてを連結し、それにそのSDMの署名鍵で署名することができる。これは、と表され得る。TPESの準備に関して、SDMは、DMのドメインから取得され得るTHSMのHWおよびSWの構成およびバージョン番号、BIOSの構成、プラットフォーム上のドメインの数、現在のドメインのために占有されているメモリなどの合計のプラットフォームのリソース、既存のもしくは新しいドメインのさらなるビルドもしくは拡張のために残っているプラットフォームのリソース、ドメインの名称、またはそれらのドメインの所有者の名称もしくはNAIなどのIDそれぞれのドメインの所有者によって許可される場合、日付/時刻、または単調カウンタ値が利用可能であるが、日付/時刻は利用可能でない場合のそのような単調カウンタ値、上記の環境情報がSDMに収集されたときの任意のその他の関連する情報などの、SDMがTDDM、TDDO、およびTDDomainsから収集する情報を連結することによってTPESを生成することができる。この要求は、と表され得る。SDMは、TPIAおよびTPESに署名し、それらをTDROTargetに転送することができる。SDMは、署名されたSCARDを含むこともでき、したがって、DOは、そのDOがSCARDを調べることができなかった場合、いかなる初期TDROTargetにも頼る必要がない場合がある。SCARDは、ROが、SCARD、TPIA、およびTPESを調べた後で所有権取得を進める判断を行うことができるように、TPIAおよびTPESとともにROに送信されることができる。このメッセージングは、と表され得る。SDMからTPIA、TPES、およびSCARDを受信すると、TDROTargetは、SDMの公開署名鍵を用いてそれらを検査することによってそれらの完全性を検査することができる。次いで、TPIA、TPES、SCARD、ユーザによって望まれるサービスを指示する目的情報要素P、および所有権取得メッセージの要求request_TOが、MEに送信されてもよい。RTOプロセスが、完全なTSIM能力のためにプロビジョニングされなければならないドメインに対するものである場合、TSIM機能についての署名されたCertTSIM証明書も、準備され、上記のパッケージとともに送信されてもよい。TSIM機能のために使用される2つ以上の証明書が存在してもよい。1つは、CERTTSIM初期TSIM機能に関し、その他は、完全にインスタンス化されている、または更新されるTSIM機能に関するものである。初期TSIM機能のための証明書は、DMに関する証明書の構造にモジュール式に埋め込まれることができ、例えば、その証明書は、DMからの機能である初期ドメインに組み込まれることができる。ROが、TDROが前もって少なくとも1つのRTOを経た後でRTOプロセスを実行するとき、そのROは、CERTTSIMが初期ドメインで使用するためにのみ適切であり、TDROはもはやその初期ドメインではない場合があるので、もはやこの証明書を送信する必要がない場合がある。したがって、この場合、ROは、更新された証明書CERTTSIMを送信する場合がある。内容は、例えば、証明書の転送によって、またはTDROTargetによる使用の前に、初期TDROTargetがロードされるときにターゲットのROが既に分かっている場合は、事前の構成によって利用可能にされた場合があるターゲットのROの公開鍵K_Target_RO_pubで暗号化されてもよい。TSIMは、署名鍵K_TSIMSignを事前にプロビジョニングされてもよい。この秘密署名鍵の公開鍵は、ターゲットのROに事前に配布されてもよい。IDMEは、TDROTargetがTHSMのDMのドメインTDDMから取得するMEのIDであり、TDDMは、このMEのIDを安全に保有する。これは、と表され得る。第3の実施形態を参照すると、値MPIAおよびMPESが、メッセージに追加されてもよい。MPIAは、MTEによってまとめられたMPIDTHSMbasedontheconfigurationdataで計算されたダイジェストを含んでもよい。このダイジェストは、このダイジェストが、構成ファイルに事前に存在するか、またはDMとのリアルタイムの通信を介して伝達される、取得され証明された尺度に一致する場合にのみ証明されてもよい。完全性および環境の情報のROの要求に従って、式20は、SDMがMPIDおよびMPESを正常に受信したという単純な指示を含んでもよい。これは、と表され得る。MEは、上記のメッセージ全体をROに転送することができ、これは、と表され得る。第3の実施形態を参照すると、メッセージは、MPIAおよびMPESを含む。ROは、そのROの秘密鍵KTargetROPrivを用いてPackage_10を復号し、MEのIDを検査し、メッセージを解釈することができる。ROは、SCARDを解釈し、そのROがSDPからのこれらの条件に同意agreeできるかどうかを調べることができる。ROがSCARDに同意する場合、例えば、初期TDROTargetからの値TPIAが、任意のサービスの認証情報または構成の制御がターゲットのROのドメインTDROTargetに提供される前の最初のTSIMの状態の全体を表すように解釈されてもよい。値Pは、ユーザによって望まれるサービスを指示するように解釈されてもよい。TSIMに対応したTDROTargetの場合には、MNOでありうるターゲットのROは、TPIAを、そのROがTTPから別途取得したRIMReferenceIntegrityMetrics値RIMROと比較することによって、そのTPIAで指示されるそのROが関心のあるドメインの完全性を検証することができる。MNOは、WTRU/THSMの供給者によって例えばTTPに提供される証明書によってTPIAの期待される値を知る能力を有する場合がある。第3の実施形態を参照すると、MPIAおよびMPESの期待される値が、MTEが信頼できるエンティティであり、その信頼性がTHSMによって証明されているという事実によって可能にされる証明プロセスによって前もって知られてもよい。ターゲットのROは、受信されたTPESを検索し、ROが、自らがRTOプロセスをさらに進めることを許す状況において、ターゲットのROが同意できるagreeable、例えば、TPESによって示されたような周囲のシステム環境surroundingsystemenvironmentを有するTHSMシステム内にTDROTargetがあるのかどうかを評価することができる。TPIA、TPES、目的P、Request_TO、ならびに第3の実施形態を参照した場合のMPIAおよびMPESを検査した後、MNOなどのターゲットのROは、ターゲットのROによって所有権を取得されるtakenownershipことを要求している初期TDROTargetと、そのTDROTargetを含むTHSM全体とが、そのROがRTOプロセスをさらに進めることを許可するのに、また、いくつかの事前に指定された基本的なサービスを提供するためにTDROTargetがそのROと対話することをそのROが許可するのに十分なだけ信頼できるtrustworthyと判定する場合がある。次に、ドメインが、鍵、より完全な構成、パラメータ、および実行ファイルを後でダウンロードすることができ、それらをインストールして、基本的な初期状態が可能にするよりも機能的になり、さらにターゲットのROリモートの所有者によって獲得または所有され、管理されるようになることができるようにTDROTargetの所有権取得を実行するために、ターゲットのROは、実行ファイルを含み得る構成信号CONFIGを送信することができる。ROは、TDROTargetが、受信されたCONFIGに準じて、それらの構成、パラメータ、および実行ファイルをインストールする場合に、インストール後の状態と一致する場合がある、RIMTSIMと呼ばれるTSIMに関するRIMも送信する。RIMTSIMは、TDROTarget上の安全なメモリ内に記憶されてもよく、将来のブート時にTSIM機能の完全性を検査するために使用されてもよい。使用されるべきセキュリティ対策およびその他の設定の問題を指定するDPドメインポリシーが、このトランザクションに含められてもよい。RO固有のDPドメインポリシーは、SDMによって保有され、THSM上の特定のROによって所有される1またはそれ以上のドメインをビルドおよび管理するための計画を表すSDPシステム全体のドメインポリシーとは異なる場合がある。RO固有のDPは、その特定のドメインに固有であり、それに専用であるドメイン内のアプリケーションおよびセキュリティ対策のみを管理するポリシーまたは計画を含んでもよい。一部のROは、DPが、その他のROがTHSM上で何がビルドまたは管理されることに同意できるのかに関する制約を課す規定も含み得るように、そのような方法でそれらのROのDPを作成することができる。例えば、モバイルネットワークのオペレータMNO_Aは、そのTDMNOAオペレータのターゲットのドメインが、DPMNOAのダウンロードおよびインストールの後で、例えば、THSM上のその他のドメインの一部の状態および性質に関するDPMNOAで指定された条件の一部が十分に満たされないことが認められない場合に、そのオペレータのサービスまたは活動に対する一組の制約によって管理されるような方法でそのオペレータのDPMNOAを作成することができる。例えば、MNOは、TDMNOAが、THSM内のより大きな環境を調べた後、同じTHSM上にインストールされ、アクティブである、独自のアクティブ化されたTSIM機能を有するその他のMNOのドメインが存在することを発見する場合に、TDMNOAが、そのTDMNOAのTSIM機能を無効化するDPMNOAを実装する場合がある。TDROTargetは、P内の要求されたサービスに対応するようにしてそのTDROTarget自身を構成するように要求されてもよい。例えば、ROが、MEに応答を送信することができ、メッセージの機密性が、公開鍵KTSIMPubを用いて保護される。MEは、このメッセージを、THSM上のTDTargetROに転送することができる。CertROが、Target_ROの公開鍵K_ROprivを含み得る。ROは、このとき、TSIMに関するRIMreferenceintegritymetricを送信することができる。ROの応答は、と表され得る。TDROTargetは、メッセージを秘密鍵KTSIMPrivを用いて復号し、CAでCertROを検査した後、その証明書内の公開鍵KROPubを用いてROの署名を検証することができる。TDROTargetは、TSIMアプリケーションに関する受信された基準の完全性の尺度RIMTSIMを安全に記憶することができる。TDROTargetは、IDROからROのIDを検査し、ROのポリシーDPROを検査し、TDROTargetがCONFIGの構成およびインストールの残りを続行し得るかどうかを判定することができる。TDROTargetは、CONFIGによって再構成を実行して完全なcompleteドメインの状態に到達することができ、次に、そのTDROTargetのTSIM機能の測定された尺度が、ネットワークによって伝えられ、RIMTSIMで表される尺度と一致するかどうかを判定するための自己検査を実行する。ドメインTDROTargetは、現在完了completedしており、もはや初期ではなく、したがって、表記からアスタリスクを取り除くこと。これは、と表され得る。完了したドメインTDTargetROは、RTO成功およびドメイン完了RTOsuccessanddomaincompletedステータスメッセージをMEに送信することができ、MEは、そのメッセージをターゲットのROに転送することができる。これは、と表され得る。随意に、MEは、例えばWTRUのスクリーンに表示される、電話が現在登録および認証情報のロールアウトの準備ができているというステータスメッセージをユーザに送信することができる。MEは、プラットフォームの再構成が正常に完了し、TSIMの認証情報の登録の準備ができているというステータスメッセージをROに転送することができる。TDROTargetは、THSM_TDRO_LOAD_COMPLETE状態に達している。このメッセージは、と表され得る。このRTOプロトコルは、加入されたサービスを提供する3GUMTSネットワークのオペレータに加入者をTHSMの所有者またはユーザとして登録するためのプロトコルと、さらに、共有の秘密鍵Kおよび加入者のアイデンティティIMSIのダウンロードおよびプロビジョニングを含む、AKAauthenticationandkeyagreementに関する認証情報のダウンロードおよびプロビジョニングのためのより後のプロトコルとの前触れとして役割を担ってもよい。公開-秘密鍵の組のための証明書CertTSIMおよびCertROは、それらが使用されるメッセージで伝達されてもよい。あるいは、TDROROのドメインおよびROは、それらのそれぞれの証明書を信頼できる第三者から取得することができる。この取得は、と表され得る。別の代替的方法において、ROの証明書CertROおよびTHSMの証明書CertTSIMが使用されるメッセージの伝達の前に、ROの証明書CertROが、ネットワークからMEに伝達されることができ、THSMの証明書CertTSIMが、MEからネットワークに伝達されることができる。したがって、通信が、本明細書に記載の暗号化されたメッセージの前に送信される場合があり、これらの通信は、と表され得る。これらの代替的な証明書の伝達の方法のそれぞれに関して、エンティティのIDが、公開暗号鍵が使用されるメッセージに付随する場合がある。別の代替的方法において、公開鍵の代わりに対称的な鍵を使用することが、メッセージの機密性を保護するために使用されてもよい。どの場合も、送信者は、例えば、PRNG擬似ランダム数生成器を用いて対称的な鍵Ksを生成し、メッセージの機密性を保護するために公開鍵ではなくこの鍵を使用することができる。対称的な暗号鍵は、暗号化されたメッセージとともに受信者にやはり送信されることができ、対称的な暗号鍵は、公開鍵で保護される。したがって、受信者は、その受信者の秘密鍵を用いて鍵Ksにアクセスし、次に、その鍵Ksを使用してメッセージを復号することができる。第2の実施形態を参照すると、THSMおよびMEは、第1の実施形態のTHSMおよびMEと異なる場合がある。ME自体またはMTEなどのME内の信頼できるエンティティの代わりに、THSMが、MEがブートするときにMEのコードの一部またはすべての完全性の検査を実行するように構成されてもよい。随意に、THSMは、MEに関するブートコードの一部またはすべてを記憶することもできる。THSMは、外部のエバリュエータにMEの完全性を証明するように構成されない場合がある。THSMは、ブート時にMEのコードの完全性のローカルのlocal検査を実行されるように構成されてもよい。MEに関する完全性の値は、起動プロセスで使用される場合があり、RTOプロセスで使用されない場合がある。MEのセキュアブートの結果として生じるMEのコードおよび構成の状態を表す、meas_MEによって表されるMEの完全性の測定値が、THSMのDMのドメインTEDMによって取得されてもよい。THSMのTDDMは、meas_MEの有効性を検査することができるが、それをプラットフォームの証明に組み込まない場合がある。第4の実施形態を参照すると、MEは、例えば、TCGのMPWGの意味で信頼できるMEであってもよい。MEは、MTMmobiletrustedmoduleを含んでもよく、ストレージ、報告、測定、検証、および施行のための信頼のルートを提供するそのMEのトラストアンカーとしてMTMを有するので信頼され得る。図4および4Aは、リモート所有権取得プロセスに関する例示的なコールフロー図を表す。例えば、図4および4Aは、ME402、TDDO404、SDM406、TDTargetRO408、およびターゲットのRO410のうちの1またはそれ以上の間の例示的なコールを示す。図4および4A内の矢印は、コールの元/先を表す場合がある。図2および3に示されたように、SDMは、THSMに存在するシステム全体のドメインマネージャを含み、DOの機能の一部を提供することができる。SDMは、デバイスにおけるすべてのドメインの設定を監督および調整して、SDPおよびドメイン固有のポリシーのあらゆる衝突が、DOおよびその他のドメインのROの代わりにSDMによって折り合いを付けられるように試みられる限り、すべてのそのようなドメインが、SDPに準じて、およびドメイン固有のポリシーに従って動作し、互いに対話することを保証することができる。TDDOは、THSM内の必須のデバイス所有者ドメインを含んでもよい。TDDOは、SDMを含んでもよく、したがって、TDDOは、システムレベルのドメインポリシーを保守することができる。MTEは、ME側のポリシーマネージャMEPDMを含んでもよい。MEPDMは、ME上でポリシーマネージャ機能を実行することができるが、THSMのSDMの監督を受ける場合がある。METargetROは、許可されたリモートの所有者によるリモートの所有権に関する初期ドメインの設定を含んでもよい。ターゲットのROは、METarget_ROの所有権を要求するリモートの所有者を含んでもよい。MEは、完全なMTMの機能を引き受けることができ、したがって、認識されたリモートの所有者によるME上のドメインのリモート所有権取得がサポートされる。第1の実施形態を参照して説明されたRTOのものと似ているが、それらは、THSMとMEの両方で同じリモートの所有者によって所有されるドメインに対してMEPDMを介してSDMによって最大限のポリシー制御が行われるので本質的に異なる。したがって、THSM上のドメインも所有する同じリモートの所有者によって所有される任意のMEドメインの形成および管理は、SDMのポリシーに従うようにして行われなければならない。引き続き図4を参照すると、41において、基本コードのブートをME402によって完了することができる。415において、THSMが、安全にブートすることができる。THSMが、SDMが含まれるDOのドメインをロードすることができ、SDMは、1ドメインのビルドに利用可能なリソース、および/または2ユーザが受け入れ可能なドメインのリストを提供することができる。42において、THSMが、そのTHSMのブートを完了することができる。425において、MEが、そのMEのブートを完了することができる。43において、MEが、そのMEのブートが完了していることを指示することができる。このプロセス中に、DMのドメインがビルドされることができ、任意的なMEUユーザのドメインもビルドされることができ、利用可能なリソースが調べられる。DMのドメインは、MEデバイスに関するドメインポリシーの最初の構成および規定を提供するMEPDMを含んでもよい。MEDMの事前構成によって、このポリシーは、MEのドメインとTHSMのドメインの間で、共通のリモートの所有者を有するTHSM上のドメインおよびME上のドメインなどのドメインに関して、SDPのポリシーに一致するように作成されてもよい。引き続き図4を参照すると、431において、自らの事前に構成されたドメインの有するMEが、ブート完了bootcompleteメッセージを送り、RTOを開始することができる。このメッセージは、DMのドメインポリシーおよびME内の利用可能なリソースについての明示的な情報を含んでもよい。44において、ターゲットのドメイン計画を含む、RTOを開始する要求を送信することができる。455において、RTO開始要求を受け入れるか、または拒否するのかのいずれかの決定を、TDTargetRO408によって行うことができる。45において、RTOが開始されるべきかどうかを指示するメッセージを送信することができる。あるいは、456において、RTOは、TDTargetRO408を発端とする場合がある。451において、TDTargetRO408は、RTOの最終ドメイン計画を開始する意図intentiontostartRTOfinaldomainplanを送信することができる。SDMは、THSMのシステム全体のDSPドメインポリシーを評価し、およびMEのドメインにどの制約が課されるか、または割り当てられるべきかを判定することによって、MEブートメッセージに反応することができる。これらのポリシーの制約は、どのドメインが、それらの関連するリモートの所有者によってMEおよびTHSM上で許容され得るかを含む場合がある。SDMは、同じリモートの所有者が知らされているドメインを含むTHSM上のドメインを有するその同じリモートの所有者によって所有されるドメインに対して、どのシステム全体のリソースを使用することをMEが許されるのかを決定することができる。MEPDMは、式7のメッセージによってこの情報を受信することができる。SDMは、その基本的なポリシーに対するポリシーの制約およびそのリソースのリストに対する許容可能なリソースも含めることができる。MEPDMがこの情報を受信した後、MEPDMは、ME上のリソースおよびドメインの管理に関する決定を行い、施行するという点で、すべてのそのような決定に関してSDMから許可を得ることを必要とせずに特定の権限を行使することができる。引き続き図4を参照すると、465において、プロセスを継続することができる。465において、以下、すなわち、SDP、利用可能なリソース、ならびに/または受け入れ可能なドメインおよび/もしくは状態が、検査および/または評価されてもよい。46において、開始することのOKOKtostart信号を送信することができる。47において、TPIA、TPES、MPID、およびMPESの要求を送信することができる。475において、SDM406は、例えば、ドメインごとにPCRの範囲にわたって既存のドメインからの完全性証明を収集/連結し、ならびに/またはTPES情報を収集および/もしくは連結することができる。471において、MPIDおよびMPESの要求を送信することができる。476において、MPIDおよびMPESの要求に対する応答を、MTEによって処理することができる。48において、MPIDおよびMPESを、署名鍵を用いた信頼の証拠とともに送信することができる。481において、TPIA、TPES、MPID、およびMPESを、SDM406からTDTargetRO408に送信することができる。485において、THSMが、MPID生データからダイジェストMPIAを計算し、MPIAを検査することができる。受け入れ可能である場合、ダイジェストMPIAを、ROに送信することができる。49において、TPIA||TPES||MPIA||MPES||目的||RTOの要求を送信することができる。図4Aを参照し、RTOプロセスを続けると、410において、TPIA||TPES||MPIA||MPES||目的||RTOメッセージを、ターゲットのRO410に送信することができる。418において、ターゲットのRO410が、例えば、以下、すなわち、TPIA、TPES、MPIA、MPES、および目的を検査すること、RIMTDROに対して初期ドメインの信頼性を判定すること、許容場合に関してDPを調べること、または完全なドメインの状態をビルドするためのCONFIGを生成することのうちの1つまたは複数を実行することができる。上記の方法の代替的方法は、TDTargetRO408が、MPIAおよびMPESの代わりにME信頼性の、SDMからの単純な指示を要求することであり、その場合、SDMは、TPIA、TPES、およびMEの信頼性の指示を提供する。しかし、SDMは、MTEからのMPIAおよびMPESをやはり要求し、受信する。引き続き図4aを参照すると、411において、メッセージCONFIG||DP||RIMTDRO||ROを送信することができる。412において、CONFIG||DP||RIMTDRO||ROメッセージを転送することができる。428において、ドメインをビルドしおよび構成することができ、完全性をRIMTDROと照合することができる。加えて、TDTargetROの所有権を取得することができ、したがって、そのTDTargetROをTDTargetROに変換する。413において、ドメイン完了メッセージを送信することができる。414において、ドメイン完了メッセージを転送することができる。図5および5Aは、例えば、第4の実施形態に関連する完全な証明をともなうリモート所有権取得に関する例示的なコールフロー図を表す。例えば、図5および5Aは、SDM502、TDDO504、MEPDM506、METargetRO508、およびターゲットのRO510のうちの1またはそれ以上の間の例示的なコールを表す。図5および5A内の矢印は、コールの元/先を表す場合がある。51において、基本コードブート完了メッセージを送信することができる。それに応じて、515において、THSMが、安全にブートし、SDMを含むDOのドメインをロードすることができる。52において、THSMブート完了メッセージを送信することができる。それに応じて、525において、MEが、MEPDMが含まれるDMのドメインをロードすることと、利用可能なリソースを調べることとを含み得る安全なブートを行うことができる。MEPDMは、SDPに一致するドメインポリシーおよび利用可能なリソースを指定する最初の構成を提供することができる。53において、DMのドメインポリシー情報およびME内の利用可能なリソースを含む、MEのセキュアブートが完了しているというメッセージを送信することができる。531において、MEのブートが完了MEbootiscompleteメッセージをSDM502に転送することができる。535において、SDM502が、例えば、システム全体のポリシーを評価し、MEに対する許されるドメイン、リソース、およびポリシーの制約を判定することができる。54において、ドメインポリシーの制約および/または許可されるリソースに関する情報を提供するメッセージを送信することができる。545において、ポリシーの制約を基本的なポリシーに付け加えることができ、必要に応じて、リソースのリストを修正することができる。図5および5Aの要素55乃至511は、図4および4Aに示された要素45乃至414と同様である場合がある。値MPIAおよびMPESの評価は、式14から19の評価と同様である場合がある。MEは、MTMに対応している場合があり、生データMPIDだけでなく、自身でダイジェストMPIAを計算するように構成されてもよい。SDMによって送信された更新されたポリシーの制約が、禁止されたドメインまたはドメインポリシーが具現化されないように検査されてもよい。ポリシーの検査および評価は、MEPDMによって実行されてもよい。55において、ターゲットのドメイン計画を含み得る、RTOを開始する要求を送信することができる。555において、MEPDMによるRTOの要求を受け入れるか、または拒否するのかのいずれかの決定を行うことができる。551において、RTOが開始されるべきかどうかを指示するメッセージを送信することができる。代替的方法では、556において、RTOを開始する意図は、MEのターゲットを発端とする場合がある。56において、RTOを開始する意図のメッセージを送信することができる。565において、以下、すなわち、1拡張されたドメインポリシー、および/または2拡張されたポリシーに従った利用可能なリソース、受け入れ可能なドメイン、および状態を検査しおよび/または評価することができる。561において、RTOを開始することが受け入れ可能であることを指示するメッセージを送信することができる。57において、設定されるMEのドメインからのMPIAおよびMPESの要求を送信することができる。575において、ドメインごとにPCRの範囲にわたる既存のMPIAドメインからの完全性証明の収集および連結を実行することができ、MPES情報の収集および連結も、実行することができる。58において、MPIAおよびMPESを送信することができる。59において、MPIA||MPES||目的||RTO要求を送信することができるメッセージの完全性および機密性は、証明された公開/秘密鍵によって保護することができる。595において、ターゲットのRO510が、例えば、以下、すなわち、MPIA、MPES、および目的を検査すること、RIMTSIMに対して初期ドメインの信頼性を判定すること、許容場合に関してDPを調べること、または完全なドメインの状態をビルドするためのCONFIGを生成することのうちの1つまたは複数を実行することができる。514において、メッセージCONFIG||DP||RIMTSIM||ROを送信することができる。515において、ドメインをビルドし、および構成することができ、完全性をRIMTDROと照合することができる。加えて、METargetROの所有権を取得することができ、したがって、そのMETargetROをMETargetROに変換する。511において、ドメイン完了メッセージを送信することができる署名され、完全性を保護される。MEは、ターゲットのROと直接通信することができ、したがって、図3および3Aに示されたメッセージ転送のようなメッセージ転送は、使用されない場合があり、メッセージの数を削減することができる。MEとターゲットのROの間のメッセージングにおける公開/秘密鍵交換のための必要とされる証明書に関する詳細は、初期のエンジンの信頼性の検証のためのRIMの証明書に関する詳細とともに、図5に示されていない。図6は、THSMの例示的な状態の定義、遷移、および制御点の定義を表す。例として、例えば特許文献1で定義された定義および基本的な機能を有するMCIMM2MCommunicationIdentityModuleに関するライフサイクルが、本明細書において定義されている。THSMは、MCIMの状態の定義および遷移を含む機能および特徴を改善し、汎用的にすることができる。参照符号601において、THSMは、ブート前の状態にある場合がある。第1のユーザがTHSMの電源をオンにすることができ、THSMが安全にブートすることができ、THSMは状態602にある場合がある。602において、DMおよびDOが、初期状態で存在する場合がある。DMドメインを、事前に構成されたファイルからビルドすることができ、THSMは、状態606にある場合がある。606において、THSMは、TDDMがロードされ得るブート後2状態にある。606から、DOドメインを、事前に構成されたかまたはダウンロードされたファイルからビルドすることができ、THSMを状態605にする。605において、THSMは、TDDOドメインがビルドされ得るが、TDUまたはTDROはロードされない場合がある、ブート後3状態にある場合がある。状態605から、SDMDOのドメインが、ユーザのドメインをロードすることができ、THSMを状態604にする。604において、THSMは、TDUがロードされるが、ROドメインはロードされない場合がある、ブート後状態2aにある場合がある。状態605から、初期ROドメインをSDPに基づいてビルドすることができ、THSMを状態607にする。607において、THSMは、TDROおよびTDDOがロードされたが、TDUはロードされない場合がある、ブート後状態4にある場合がある。状態607から、TDDOSDMは、TDUをロードすることができ、THSMを状態608にする。608において、THSMは、ロードされたDO、DU、およびROドメインを有する場合がある。状態601から、ユーザが電源をオンにすることができ、THSMを安全にブートすることができ、THSMを状態603にする。603において、THSMが、記憶された構成をロードすることができ、記憶された構成は、もっとも最近の電源オフの前の構成であったものとなる。状態603から、構成を変更するブート後のトランザクションを行うことができ、THSMを状態610にする。610において、THSMは、1またはそれ以上の既にアクティブな状態が、非アクティブになる状態にある。603から状態610に到達するプロセスと同様に、THSMは、THSMが1またはそれ以上のアクティブなドメインを有する状態609にある場合がある。状態609から、遷移が、構成変更イベントの結果として起こる場合があり、THSMをやはり状態610にする。状態604、605、607、および608において、THSMは、新しいポリシーおよび/もしくは実行ファイルを用いて再構成されるか、または非アクティブ状態に遷移する場合がある。加えて、状態605において、SDPを記憶することができる。ドメイン管理のための第1の方法において、ドメインの所有者からのポリシー、すなわち、SDPシステム全体のドメインポリシーは、非常に制限的および静的staticである場合があり、新しいドメインの活動または目的について厳格な規則を有する場合がある。これらのポリシーは、あらゆる新しいドメインの登録または既存のドメインの更新をROに伝える必要性を少なくする傾向がある場合がある。ドメイン管理のための第2の方法において、SDPは、より制限的でなく、活動および目的の観点でより柔軟性を認める場合がある。あらゆる新しいドメインの登録およびあらゆるドメインの変更を、既存のドメインの所有者に報告することができる。これは、プラットフォームとROとの間の最初の、および後に続くネゴシエーションが行われ得るポリシーの施行のより動的なシステムをもたらす場合がある。ドメイン管理のための第1の方法を参照すると、SDPは、事前に構成されたリストで例外なく許可されるドメインを指定することができる。このリストは、ROの種類、およびそれぞれの種類に関していくつ許容されるかに関する情報を含んでもよい。リストは、ROがそれらのROのドメインを設定した後、それらのROが提供することができるサービスの種類も含んでもよい。見込まれるROは、リストによって指示された基準を満たすROである場合がある。ROは、リストおよびポリシーの制約などの条件について、例えば、式9に示されたように、RTOプロセスの一部として警告され得る。ROは、SCARDを受信すると、そのROが問題のプラットフォームまたはデバイスのステークホルダになりたいか否かを独自に判断することができる。ROに送信される条件は、ドメインの種類およびそれらの目的を含み得るが、その他のROのアイデンティティを保護するために、いかなるその他のROのリストの実際の名称も含まない場合がある。ROがRTOを完遂すると決定する場合、ポリシーからのいかなる逸脱も、このRO、またはプラットフォーム上で現在アクティブなすべてのその他のRO、または将来アクティブになる場合があるすべてのその他のROよって許されないことを保証することができる。結果として、ROは、行われ得るその後のRTOを警告する必要がない場合があり、および警告されない場合がある。ドメイン管理のための第2の方法を参照すると、いかなる特定のROの種類も特定しない、どのリモートの所有者が許可されるかなどの比較的広い制約のみと、ROからSDMへのより多くの情報の要求またはいくつかのネゴシエーションなどのより多くの対話を許可するポリシーとを、RTOプロセス中に実行することができる。ドメインの構成が変わるときに、SDMとすべてのROとの間で継続中の協調collaborationが存在する場合もある。したがって、最初のおよびさらには後に続くネゴシエーションは、RO/SDMの変遷の一部として起こる場合があるRTOプロセスの一部として、ROは、構成およびその信頼性に関する、第1の方法の場合と比較してより広い情報を含み得るTPIA、TPES、およびSCARDなどの、そのROが必要とする証明およびポリシーの条件の情報を与えられる場合がある。既存のドメインの構成に基づいて、ターゲットのROは、RTOを継続するか否かを決定することができる。ターゲットのROが所有権を取得しないと直ちに決定しない限り、SDMとのネゴシエーションプロセスが、続いて起こる場合がある。例えば、SDMは、ターゲットのROから、ターゲットのROのドメインがアクティブである間に、どのドメインの種類および付随するサービスがアクティブであることができるか、またはそのターゲットのROが拒絶するドメインの種類がアクティブになろうとしている場合に、どの手順に従うべきかを要求する場合がある。ROは、例えば、特定のその他のドメインの種類、もしくはさらには特定のその他のROによって所有されるドメインがアクティブになるか、もしくはアクティブになろうとしているときに、そのRO自身のドメインが非アクティブにされることを要求する場合があるか、またはROは、そのRO自身のドメインがアクティブのままではあるが、性能またはケイパビリティcapabilityが縮小されていることを要求する場合がある。SDMは、ROから、どのイベントの発生をそのROが警告されるべきかを要求する場合がある。そのようなイベントは、そのROが拒絶するドメインの種類がアクティブまたは非アクティブになることを含み得る。ROは、そのRO自身のドメインがアクティブである間、その他のドメインの種類、または特定のその他の所有者によって保有されるドメインがいかなる活動も完全に禁止されることを要求する場合がある。SDMは、そのような条件を受け入れるかまたは拒絶することを決定することができる。ポリシーの要件の幅広い組を用いて動作するが、SDMは、ROからの要求を受け入れることが静的なSDPシステムのドメインポリシーの字義または意図にいまだに従うことができるかどうかを判断する自由度および意味論的ケイパビリティを有することができる。図7は、ROドメインが到達し得る例示的な状態、および動的に管理された環境内で遷移が発生し得る条件を表す。701において、null状態が存在する場合があり、例えば、ROが、ビルドされていない場合がある。状態701から、初期ROドメインをSDPに準じてビルドすることができ、ROドメインを状態702にする。702から、ROがTPIA、TPES、およびSCARDを獲得することを含むRTOプロセスを実行することができる。さらに、ROは、RTOの条件を受け入れることができ、ROドメインを状態703にする。703から、新しくアクティブになったドメインとのポリシーの衝突が存在すると判定される場合があり、それに応じて、ROドメインの機能を縮小するか、またはROドメインを非アクティブにし、ROドメインを状態704にする。やはり703から、ROドメインは、更新されたポリシー/構成の変更を受信する場合があり、その結果、ROドメインは修正された構成および/または更新されたポリシーの制約を持つことになる。706から、新しくアクティブになったドメインとのポリシーの衝突が存在すると判定される場合があり、それに応じて、ROドメインの機能を縮小するか、またはROドメインを非アクティブにし、ROドメインを状態704にする。やはり703から、新しいソフトウェアコンポーネントが、ダウンロードまたはRTOによって導入される場合があり、ROドメインの修正された/拡張された状態をもたらし、ROドメインを705にする。705から、新しくアクティブになったドメインとのポリシーの衝突が存在すると判定される場合があり、それに応じて、ROドメインの機能を縮小するか、またはROドメインを非アクティブにし、ROドメインを状態704にする。参照符号711に表されるように、状態702、703、704、705、または706のROドメインは、nullになる、例えば、DOおよびROなどによって削除される場合がある。741に表されるように、非アクティブな/機能を縮小されたROドメインは、例えば、ROドメインを状態704に移した原因の衝突を解決することによって状態703、705、または706に移ることができる。751に表されるように、状態705のROドメインは、状態703、704、または706に移る場合がある。761に表されるように、状態706のROドメインは、状態703、705、または706に移る場合がある。ROドメインの管理に関して、動的なドメイン管理の一部として許可され得ることは、ネゴシエーションの要件が、イベントが発生する際に変わることである。例えば、ROは、前は拒否すべきであった別のROによって提供される特定のサービスが、そのROがもはやそのサービスと競う必要がないと判断した結果として、いまだに許容されると判断する場合がある。経時的なビジネスモデルに対する変更が、期待されるROによるネゴシエーションの戦略およびポリシーに影響を及ぼす場合がある。動的なポリシーの構造を使用するSDPは、そのような戦略の変更に対応するように作成され得る。これに限定されないが、スマートビリングsmartbillingと組み合わされたM2M位置追跡などのサービスにおいて、ROの好ましいローミングパートナーシップまたは閉じたグループを形成する場合がある。同様のまたは異なるサービスを提供する異なるオペレータが、互いに組み合うそのようなグループ化されたサービスは、好ましい閉じたグループにつながる場合がある。サービス、オペレータ、またはそれらの両方のそのような好ましいグループは、セットになったサービスまたはセットになった契約として提示され得る。第1の例において、パッケージが、それが世界中を移動するときに追跡される場合がある。何百万個ものそのような位置追跡デバイスを利用することができる。パッケージが大陸を横断するとき、そのパッケージは、異なる国の異なるオペレータによって接続を提供される。したがって、接続するために、ユーザは、複数のローミングプロファイルに加入する必要がある場合がある。さまざまなリモートのオペレータにまたがるこれらのローミングプロファイルは、各ドメインがリモートのオペレータによって所有および管理されるので、ドメイン間ポリシーとして管理される。これらのポリシーは、ローミングに基づくソリューションをサポートする代わりに、新しいサービスプロバイダへの完全な移管をサポートするためにやはり施行される場合がある。第2の例において、スマートメータのオペレータと位置追跡のオペレータとの間のパートナーシップが説明される。これらのドメインは、異なるオペレータによって所有および運用される場合がある。ビジネスパートナーシップまたはユーザの好みによって、ドメインが、複合プロファイルをサポートするために組み合わされ得る。労働、保管、または駐車などのリソースの使用に基づく課金のために、スマートビリングが、パッケージの追跡と一緒に使用され得る。別個のカテゴリーに入る共存するサービスのそのような場合は、ドメイン間ポリシー管理のサポートを使用する場合がある。IDPMドメイン間ポリシーマネージャは、ドメインのグループの振る舞いを統治するポリシーを管理することができる。IDPInterDomainPolicyを、RTOプロセス中に各ROによってダウンロードすることができる。IDPを、各ROによって署名された証明書によって認証することができる。これらの証明書を、IDPと一緒に発行することができる。あるいは、これらのポリシーを、外部のサービスディーラーによって証明およびダウンロードすることができる。好ましいオペレータのリストを作成することに関心があるデバイスのユーザまたはデバイスの所有者は、IDPを作成することができる。IDPMは、候補のポリシーの受け入れ可能な共通部分、またはIDPを選択する優先度を評価し、次いで、結果として生じるポリシーを施行することによってこれらのポリシーを処理することができる。IDPMを、あるいは、SDMの機能の1つとして、またはTHSMにロードビルドもしくはダウンロードされ得る別個のエンティティとしてSDMに追加することができる。証明プロトコルの一部として、TDROは、完全なTPIA、TPES、およびSCARDを送信する代わりに、これらの測定値のハッシュをROに送信することができる。ROは、それ自体で、またはTTPによってのいずれかで、そのようなハッシュを検証する手段を有し、それによって、TDROおよび周囲のシステムの実現性の評価を行うことができる。この方法は、例えば特許文献1で規定された準自律的検証SAVSemiAutonomousValidationと同様となりうる。TPIA、TPES、およびSCARDの測定値のうちの任意の1つまたは2つを、証明のフェーズの間に送信することができる。THSMは、MEの一部として一体的に埋め込まれる場合がある。そのようなデバイスに関するRTOプロセスは、そのプロセスがMEとTHSMの間のインターフェースを取り除くので、簡素化することができる。特徴および要素が特定の組み合わせで上記説明されているが、それぞれの特徴または要素をその他の特徴および要素なしに単独で、またはその他の特徴および要素とさまざまに組み合わせて、もしくは組み合わせずに用いられてもよい。本明細書で提供された方法またはフロー図は、汎用コンピュータまたはプロセッサによる実行のためにコンピュータ可読記憶媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアで実装されてもよい。コンピュータ可読記憶媒体の例は、ROMリードオンリメモリ、RAMランダムアクセスメモリ、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、光磁気媒体、ならびにCD-ROMディスクおよびDVDデジタル多用途ディスクなどの光学媒体を含む。適切なプロセッサは、例として、汎用プロセッサ、専用プロセッサ、通常のプロセッサ、DSPデジタル信号プロセッサ、複数のマイクロプロセッサ、DSPコアと関連する1つもしくは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ASIC特定用途向け集積回路、FPGAフィールドプログラマブルゲートアレイ回路、任意のその他の種類のIC集積回路、および/または状態機械を含む。ソフトウェアに関連するプロセッサが、WTRU無線送受信ユニット、UEユーザ機器、端末、基地局、RNC無線ネットワークコントローラ、または任意のホストコンピュータで使用するための無線周波数トランシーバを実装するために使用されてもよい。WTRUは、カメラ、ビデオカメラモジュール、テレビ電話、スピーカーフォン、振動デバイス、スピーカー、マイクロホン、テレビトランシーバ、ハンズフリーヘッドセット、キーボード、Bluetooth登録商標モジュール、FM周波数変調ラジオユニット、LCD液晶ディスプレイディスプレイユニット、OLED有機発光ダイオードディスプレイユニット、デジタル音楽プレーヤー、メディアプレーヤー、ビデオゲームプレーヤーモジュール、インターネットブラウザ、および/または任意のWLAN無線ローカルエリアネットワークもしくはUWB超広帯域モジュールなどの、ハードウェアおよび/またはソフトウェアで実装されたモジュールに関連して使用されてもよい。II.加入に基づくサービスにアクセスするための登録および認証情報のロールアウトデバイスのユーザは、加入に基づくサービスのプロバイダと加入関係を創りたいと望む場合がある。例えば、図1のデバイス100、110、もしくは120などのUE、または図2のUE200のユーザが、リモートの所有者によって提供される加入に基づくサービスの加入したユーザとして登録することを望む場合がある。加入に基づくサービスの提供は、第三者によって円滑にされる場合がある例えば、第三者が、リモートの所有者の代わりに、加入に基づくサービスをユーザに販売する場合がある。リモートの所有者は、デバイス上のドメインの所有権を取得している場合があり、このドメインは、RTOプロセスに関連して上記説明されたように、リモート所有者ドメインと呼ばれる場合がある。さらに、ユーザが、デバイス上のドメインの所有権を取得している場合があり、このドメインは、ユーザドメインと呼ばれる場合がある。ユーザが加入に基づくサービスにアクセスするためには、登録および認証情報のロールアウトが、行われる必要がある場合がある。登録および認証情報のロールアウトは、ユーザをリモートの所有者に加入に基づくサービスの加入したユーザとして登録することそのようなサービスが、リモート所有者ドメインを通じてリモートの所有者によって行われ得る、ユーザが加入に基づくサービスを加入したユーザとして使用することを可能にする認証情報をリモートの所有者から取得すること、および/または認証情報をリモート所有者ドメインに記憶することのうちの1つまたは複数を含んでもよい。認証情報は、ユーザがデバイスを通じて、加入に基づくサービスを使用することを可能にする。認証情報の用語は、通常の認証情報例えば、鍵、ID、証明書などを含んでもよい。認証情報の用語は、加入管理機能のために使用される実行ファイルおよびアプレットなどのその他の状況に即したデータおよびアプリケーションを含んでもよい。本明細書において開示されたシステムおよび方法は、ユーザが1つのデバイスまたは複数のデバイスによって、複数の加入に基づくサービスにアクセスすることができることを想定する。例えば、図1および2に関連して、ならびにRTOプロセスに関連して上記説明されたように、デバイスは、異なるリモートの所有者によって所有され得る複数のドメインを有する場合がある。ユーザは、複数のリモートの所有者からの複数の加入に基づくサービスに加入することができる。登録および認証情報のロールアウトは、リモートの所有者がリモート所有者ドメインの所有権を取得してから長い時間が経ってから行われてもよい。無線電話ケイパビリティを有する無線デバイスが、例として使用されてもよい。複数の無線キャリアが、デバイス上の複数のドメインの所有権を取得した場合がある例えば、各無線キャリアがリモートの所有者である。例えば、無線キャリア1が、リモート所有者ドメイン1の所有権を取得した場合があり、無線キャリア2が、リモート所有者ドメイン2の所有権を取得した場合がある。しかし、ユーザは、無線キャリア1の加入に基づくサービス例えば、無線電話サービスに関連する登録および認証情報のロールアウトを開始した場合があるが、無線キャリア2の加入に基づくサービスに関連する登録および認証情報のロールアウトは開始しなかった場合がある。例えば、無線キャリア1は、無線電話サービス全体に関して無線キャリア2よりもよい契約をユーザに提供した場合がある。後で例えば、数日、数か月、数年、ユーザは、無線キャリア2の加入に基づくサービス例えば、無線電話サービスに関連する登録および認証情報のロールアウトを開始することができる。例えば、そのとき、無線キャリア2が、長距離電話に関して無線キャリア1よりもよい契約を提供する場合がある。ユーザは、両方に関して登録および認証情報のロールアウトが完了しているので、両方の加入に基づくサービスを使用することができる。例えば、ユーザは、市内電話のために無線キャリア1の無線電話サービスを使用し、長距離電話のために無線キャリア2の無線電話サービスを使用することができる。この例は、どちらのリモートの所有者もそのような構成を禁じる規則を設定しなかった例えば、RTOプロセスを参照と仮定する。この例は、登録および認証情報のロールアウトが、リモートの所有者がリモート所有者ドメインの所有権を取得してから長い時間が経ってから行われる場合があることをやはり表す。登録および認証情報のロールアウトプロセスに含まれるエンティティは、以下、すなわち、ユーザ、ユーザドメイン、リモートの所有者、リモート所有者ドメイン、第三者、または準自律的検証を容易にするコンポーネント例えば、システム全体のドメインマネージャのうちの1つまたは複数を含んでもよい。登録および認証情報のロールアウトに関して、エンティティは、以下のような属性を有してもよい。ユーザは、加入に基づくサービスなどのサービスに加入することを試みるデバイスのユーザであってもよい。そのような加入に基づくサービスの例は、金融サービス、セルラ通信サービス、インターネット接続サービス、音楽/ビデオ/マルチメディア加入サービス、本人確認サービス、位置に基づくサービス、電子メール/メッセンジャー/ソーシャルネットワークサービス、電子ブックサービス、ゲームサービスなどを含んでもよいが、これらに限定されない。ユーザは、デバイスの所有者でもあってもよい。ユーザは、登録および認証情報のロールアウトを開始してもよい。開始は、ユーザが個人データおよび/または通常のログイン情報を送信することを含んでもよい。ユーザは、例えば、ユーザが加入している/加入しようとしている加入に基づくサービスに関連するアクションに関連するとき、加入者と呼ばれることもある。TDUユーザドメインは、ユーザの機能に関連するデバイス上のドメインであってもよい。ユーザドメインは、任意的なドメインであってもよい。ユーザドメインは、本明細書において説明されたようにTHSMの一部であってもよい例えば、図2を参照。ユーザドメインは、プラットフォームの最初のブートシーケンス中に作成され、その機能を提供されてもよい。TDO所有者ドメインは、ユーザドメインを含まない構成のためにTDUの機能を実行してもよい。ユーザは、IDUユーザ名、PWUパスワード、およびREGDATAU個人登録データを供給されることによってTDUを用いて登録を開始してもよい。TDUは、ユーザ登録の一部としてPID_UプロセスIDを生成してもよい。この情報は、登録を開始し、認証情報のロールアウトを要求するのに使用されてもよい。例えば、この情報は、特定の要求例えば、特定の登録および/または認証情報のロールアウト要求に関連付けられる場合があり、登録および/または認証情報のロールアウトのための異なるセッションまたはプロセスを識別するか、またはそれらに印を付けるために使用されてもよい。ユーザとユーザドメインは、MEを介して通信してもよい。事前にプロビジョニングされた鍵例えば、機密性のためのKtempCおよび例えば、完全性/認証のためのKtempIが、ME/THSMインターフェースを介したメッセージングを保護するために使用されてもよい。非対称的な鍵の対が、ME/THSMインターフェースを介したメッセージングを保護するために使用されてもよい。MEは、図8に関連して示されていない場合がある。THSMへのユーザの通信は、TDUを介して行われてもよい。ROリモートの所有者は、デバイスを介してユーザに加入されたサービスを提供してもよい。リモートの所有者は、ユーザが加入したサービスを使用するために必要とされ得る認証情報を提供してもよい。認証情報は、リモート所有者ドメインとリモートの所有者との間の強力な秘密としての役目を果たすことができる認証鍵Kを含んでもよい。例として、ROは、以下、すなわち、MNO、その他の通信ネットワークのオペレータ例えば、WLANおよびWiMaxなど、電子メールサービスプロバイダ、インターネットサービスプロバイダ、ソーシャルネットワークサービスプロバイダ、デジタルコンテンツ音楽、電子ブック、ビデオなどプロバイダ、ゲームサービスプロバイダ、金融サービスプロバイダ、アプリケーションサービスプロバイダ例えば、モバイル決済、モバイル発券、DRM、モバイルTV、位置に基づくサービスなどのサービスプロバイダ、またはIMSサービスプロバイダなどのうちの1つまたはそれ以上であってもよい。TDROリモート所有者ドメインは、リモートの所有者によって定義された機能を提供することができるデバイス上のドメインであってもよい。リモート所有者ドメインは、上記説明されたようにTHSMの一部であってもよい例えば、図2を参照。リモート所有者ドメインは、上述のRTOプロセスに関連して説明されたTSIM機能を有してもよい。リモート所有者ドメインは、リモートの所有者によって提供された認証情報を記憶してもよい。TDROは、ユーザドメインからIDUおよびPID_UユーザのIDおよびプロセスIDを受信し、登録および認証情報のロールアウト中にこの情報をさまざまに使用してもよい。POSpointofsaleorpointofserviceentityが、ユーザに対する加入に基づくサービスの販売/サービスを容易にする第三者であってもよい。POSは、図8に関連して説明されるチケットによって販売を容易にすることができる。例として、POSは、リモートの所有者の加入に基づくサービスを販売し、ならびに/またはその販売前および販売後の顧客サービスの義務を遂行する小売店オンライン型、実店舗型などであってもよい。SDMシステム全体のドメインマネージャ、例えば、節Iで開示されたSDMが、登録および認証情報のロールアウトの一部として、1またはそれ以上のプラットフォームに関連する証明情報を提供してもよい。例えば、登録および認証情報のロールアウト中に要求があると、準自律的な完全性の確認が、SDMによって行われてもよい。SDMは、ドメインのコンポーネントなど、THSMの一部であってもよい例えば、図2を参照。登録および認証情報のロールアウトは、以下のうちの1つまたは複数を含んでもよい。1POSが、チケットをユーザと関連付けることができる。チケットは、ユーザのIDを確立することができ、認証情報の要求がリモートの所有者に対してなされるときに当該チケットを示すことができる。チケット例えば、ユーザに与えられるチケットなどは、ROによってPOSに例えば、事前に生成された組で分配されてもよい。チケットは、登録および認証情報のロールアウトプロセスで使用されるべき情報を含んでもよい。例えば、情報は、三つ組みtripleを含んでもよく、三つ組みは、識別子例えば、IMSIと、例えば、認証情報の要求がなされるときにリモートの所有者へのチャレンジ番号challengenumberとしての機能を果たす乱数RANDと、チケットの認証値AUTHとを含んでもよい。2ユーザドメインが、ユーザの代わりに、登録を要求することができる。3POSが、ユーザに関連する個人登録データとともに、リモートの所有者にユーザのアイデンティティを報告することができる例えば、分配されたチケットが、国際移動体加入者識別番号--IMSIなどの識別子を提供することができる。4ユーザが、識別子例えば、IMSIを用いて認証情報のロールアウトを要求することができる。5認証情報を、デバイスに例えば、リモート所有者ドメイン届けることができ、その認証情報は、加入サービスにアクセスするために使用されてもよい。リモート所有者ドメインは、加入サービスの管理においてTSIM機能を提供することができる。登録および認証情報のロールアウトを安全な方法で行うことができる。以下の事前の条件のうちの1つまたはそれ以上が、ユーザの登録および認証情報のロールアウトが安全な方法で行われるために充足され、および/または仮定される場合がある。1THSM/MEプラットフォームを信頼できる状態にあるとみなすことができ、RTOリモート所有権取得プロトコルによって、事前に構成されたドメインを有するリモートの所有者によって要求されるときに、プラットフォームの構成の状態またはその一部を報告することができる。デバイスは、完全に信頼できるcompletelytrustedプラットフォームのコンポーネントとみなされない場合があるMEを含んでもよい。MEの信頼性をTHSMによって周期的に監視することができる。MEとTHSMを接続するインターフェースは、概して、安全とみなされない場合がある。MEは完全なMTMの能力を有し、そのMEの完全性を証明することができると仮定してもよい。2以下の方法のうちの1つまたは複数で実装され得るプラットフォームの証明。aTPIA、TPES、およびSCARDの使用を含む証明の報告。例えば、RTOプロセス参照。bROに現在の構成のハッシュを送信することを含み得るリモートの検証のスケーリングされたバージョン。この種類の証明は、大量のデータを転送することを避けることを求めるときに使用されてもよい。c内部的な完全性の検査の実行、およびプラットフォームが安全であることの確認を提供することを含み得る準自律的検証。3認証情報をリモートでダウンロードすることができる。POSが、ユーザをリモートの所有者に登録することに関与することができる。POSとの通信は、以下の方法のうちの1つまたは複数で行われてもよい。aユーザがそのユーザの識別情報および登録データを送信するときに、ユーザはOTA無線上またはインターネットリンクを介してPOSと通信することができる。bユーザがハンドセットを用いて登録のログインステップを完了した後は、ユーザドメインが、登録および認証情報のロールアウトプロセスに関してPOSとインターネットを介して通信することができる。4POSを、チケット配布機能を処理するのに十分なだけ信頼できるとみなすことができる。したがって、POSは、関連する証明書CertPOSとともにKPOSPrivおよびKPOSPubと表される証明された鍵の対の組を有することができる。これらは、それぞれ関連する証明書CertROおよびCertTSIMをともなうリモートの所有者に関する鍵の組KROPriv、KROPubおよびTSIMに関する鍵の組KTSIMPriv、KTSIMPubと併せて登録および認証情報のロールアウトにおいて使用されてもよい。aユーザとユーザドメインの間の通信が、MEを仲立ちとして使用すると仮定することができ、ユーザによって使用されることを意図されたメッセージが、ハンドセットのスクリーン上に表示される。これらのメッセージは、それぞれ完全性および機密性の保護のための一時的な鍵KtempIおよびKtempCを使用することができ、MEが、ユーザのために解釈する例えば、復号するおよび/または署名を検証することができる。b登録および認証情報のロールアウトが、それが同じユーザまたは場合によっては複数のユーザからの複数の登録および認証情報の要求を可能にすることができるほど柔軟であり得る。例として、各ユーザは、所与のTDRO信頼できるドメイン:trusteddomainに対して1つかつ1つだけの登録を確立することができるが、複数のそのようなドメインにわたって複数の登録を確立することはできない。しかし、複数の異なるユーザは、それぞれ、1つのそのようなドメインに対してそれらのユーザ独自の登録を有することができる。各TDROは、1人のROを有することができるが、ROは、各登録が異なるユーザに関する複数の登録を管理することができる。所与のROが2つ以上のTDROを所有することもできる。多数のユーザ、および場合によっては複数のリモートの所有者に対応する信頼できるドメインが存在する場合、プロセスIDが、例えば、ユーザドメイン、POS、およびリモートの所有者によって生成され、複数の登録に関連する曖昧性をなくすために使用され得る。所与の登録および認証情報の要求に関して、緊密に関連付けられる3つのプロセスID、すなわち、ユーザドメインによるPID_U、POSによるPID_POS、およびリモートの所有者によるPID_ROが、生成され得る。PID_Uは、ユーザドメインを識別するために、POSかまたはリモートの所有者かのいずれかと通信するときにTHSM内のエンティティによって使用され得る。これらのIDは、所与の登録プロセスを一意に識別するのに十分であり得る。c信頼できるエンティティ間の通信を、公開-秘密鍵の対を用いて保護することができ、公開鍵が、CA認証局により発行された証明書によって配布され得る。d登録および認証情報のロールアウト中、リプレーアタックを防ぐためにノンスを使用することができる。ノンスは、連続的に付番されてもよく、もしくはその他の方法で順次順序付けられてもよく、または連続したもしくはその他の方法で順次順序付けられた数を含んでもよい。記述的なノンスの指定が使用される特定の内部的なドメイン間対話は、連続的に付番されない場合がある。2つのエンティティ間の往復の通信に関して、送信された第1のノンスが、返信メッセージで平文の新しいノンスとともにその第1のノンスの送信元に返送される平文でないことができる。返信のノンスを受信するエンティティは、その値が最初にそのエンティティによって生成され、したがって既知であり得ることを考えれば、それが平文で送信されることを必要としない場合がある。e署名を、例えば、本明細書においてはSHA-Xと表記されることがあるSHAアルゴリズムの特定されないバージョンによって計算された固定ビット長の暗号学的ハッシュ値に適用することができる。登録および認証情報のロールアウトを説明する方法を、ここで、図8を参照して明らかにすることができる。図8は、登録および認証情報のロールアウトプロセスを実装する例示的なコールフローを表す。コールフローは、式として表され得る。式は、それぞれのフローに関連する場合があるセキュリティ機能を含んでもよい。図8に示されるコールフローは、例示的であるように意図される。その他の実施形態が使用され得ることを理解されたい。さらに、フローの順序は、必要に応じて変更され得る。加えて、フローは不必要な場合は省略される場合があり、追加的なフローが追加される場合がある。参照符号1において、POS30が、リモートの所有者、RO40に、ユーザ32などのさまざまな認可されたユーザに配布され得る事前に生成されたチケットの要求を行うことができる。2において、RO40が、例えば、CertPOSで受信された公開鍵KPOSPubでPOSの署名の有効性を検査し、ユーザ32などのユーザを登録するときに使用され得るチケットのインデックス付けされた組を送信することによって応答することができる。インデックス付けされた組の中の各チケットは、三つ組みを含んでもよい。Ticketi=IMSIi||RANDi||AUTHi|IMSI国際移動体識別加入者識別番号は、例えば、サービスの認証情報を要求するときに、ユーザ/加入者の一意的な識別子として働くことができる。RAND値は、チケット自体のフレッシュネスな指示を提供することができる乱数であり、AUTHは、チケットの完全性およびチケットが本物であることが検証され得る手段である。鍵KROPrivROの秘密鍵を用いたPackage_1のハッシュの署名が、リモートの所有者を認証しながらメッセージの完全性を保護することができる。2において送信されたメッセージに関して、POS30は、そのPOS30の秘密鍵KPOSPrivを用いてチケットの組を復号し、例えば、証明書CertROで受信された公開鍵KROPubを用いてリモートの所有者の署名を検証することができる。式1および2で指示されたように、nonce0が、送信者から受信者へ、そして再び送信者へ往復し、それが安全な通信のために必要とされる場合がある。3において、ユーザ32が、例えばTHSMのユーザドメインTDU34に登録し、ID、パスワード、および/または登録データなどの情報を提供する場合がある。3のプロセスを、通常のログインおよび登録手順とみなしてもよい。メッセージの暗号化および署名の特徴、ならびにノンスnonceUの使用は、MEの暗黙的な存在を反映する場合があり、ユーザに透過的である場合がある。この透過性は、図8に示された方法全体を通じて、ユーザ/所有者とTDUの間のその他の通信に関わる場合がある。IDUおよびPasswordUPWUとも表記されるは、ユーザがプラットフォーム上で設定するアカウントのそれぞれに対してユーザによって作成された一意的なユーザ名およびパスワードの対であってもよい。IDUは、特定のアカウントに関するユーザを特定することができ、関連するPasswordUパスワードは、例えば、認可されたユーザによって知られているが、その他の者には知られていない秘密であることができ、ユーザの認可のために使用されてもよい。REGDATAUは、ユーザの個人情報を含んでもよい。4において、TDU34が、3において受信されたメッセージ内の情報を読み、記憶し、プロセスIDPID_Uを生成することができる。KtempCおよびKtempIは、事前にプロビジョニングされ得る機密性の鍵および完全性の鍵をそれぞれ表してもよい。これは、TDU34がPasswordUパスワードを復号し、Package_2のハッシュされた署名を検証することを可能にする。PID_Uが、登録およびチケット要求プロセスを開始するためにREGDATAUと一緒にPOS30に送信されてもよい。PID_Uは、第1のプロセス識別子であってもよい。5において、POS30が、PID_UおよびREGDATAUを受信した後、そのPID_POSPOS独自のPIDを生成し、そのPIDをPID_Uおよびユーザ登録情報と関連付けることができる。プラットフォームがPID_Uを用いてPOS30と通信するとき、POS30は、メッセージを、PID_POSによって識別される登録プロセスの一部とみなすことができる。したがって、複数の登録プロセスが、同時に行われることができる。PID_POSは、第2のプロセス識別子である場合がある。証明書CertTDUによって、POS30は、公開鍵KTDUPubを用いてSHA-XPackage_3の署名を検証することができる場合がある。POS30は、例えば、以下のメッセージに示されるように、PID_UとともにTDU34にPID_POSを送り返すことによって、4のメッセージに応答することができる。TDU34は、証明書CertPOSから得られるKPOSPubを用いてSHA-XPackage_4の署名を検証することができる。TDU34とPOS30の間の通信は、無線でまたはインターネットの経路を介して行われてもよい。6において、TDU34が、TDRO38に登録要求を送信することができる。PID_UおよびPID_POSを、TDRO38が関連するプロセスの関連付けを行うことを可能にするためにメッセージの一部として送信することができる。ユーザの識別情報IDUが、メッセージに含められてもよく、TDRO38が、そのIDUを、登録を試みる特定のユーザのサービスプロファイルとの照合として使用することができる。この特徴は、同じドメインに対する複数のユーザ登録のための柔軟性を提供することができる。TDRO38は、証明書CertTDUから得られる公開鍵KTDUPubを用いてTDU34の署名を検証することができる場合がある。7において、TDRO38が、以下のメッセージでPOS30にチケット要求を行うことができる。POS30は、そのPOS30がメッセージ5でTDU34に送信し、メッセージ6でTDRO38に渡されたnonce4を期待する場合がある。nonce4をともなうPackage_6が、秘密鍵KTSIMPrivを用いて署名され得る。POS30は、この要求を、プロセスIDPID_Uを用いて、4で送信された登録データと関連付けることができる場合がある。POS30は、このメッセージの署名を、そのPOS30が証明書CertTSIMを介して得ることができる公開鍵KTSIMPubを用いて検証することができる。POS30は、Package_6平文で送信されるおよびnonce4を用いてSHA-Xを再作成することができる。8において、登録要求チケット要求がPOS30によって受信された後、そのPOS30が、RO40から前に受信された組からチケットを取り出すことができる。POS30は、このチケットを、例えばTHSMを介してTDRO38に送信することができる。公開鍵KTSIMPubが、ticketkを暗号化し、そのチケットを受信者にバインドするために使用されてもよい。TDRO38は、そのTDRO38の秘密鍵KTSIMPrivを用いてticketkを復号バインド解除し、メッセージ6のCertPOSによって得られたKPOSPubを用いてPackage_7の署名を検証することができる。このプロセスは、チケットを認証し、チケットの完全性を検証する機能を果たすことができる。TDRO38は、PID_POSを用いて正しいプロセスの関連付けを行うことができる。ノンンス、nonce5がTDRO38に返されてもよい。9において、TDRO38に送信されたチケットに加えて、POS30は、REGDATAUを含む場合があり、ticketkによってユーザを特定することができる登録メッセージをRO40にやはり送信することができる。RO40にプロセスの関連付けのために必要とされ得る情報を提供するために、PID_POSおよびPID_Uが、送信されてもよい。これは、RO40が、受信されたプロセスIDを、そのRO40がこの登録に対して生成するIDと関連付けることを可能にする。このメッセージは、RO40によって、指定されたユーザにそのRO40が要求する場合がある認証情報を提供するために必要とされ得る情報を含んでもよい。チケットは、メッセージ2のCertROでPOS30によって取得されたKROPubを用いて暗号化されてもよい。RO40は、そのRO40の秘密鍵KROPrivを用いてticketkを復号し、公開鍵KPOSPubを用いてPackage_8の署名を検証することができる場合がある。公開鍵KROPubは、チケットをRO40にバインドする効果がある場合がある。10において、RO40が、チケットを含む登録情報の受信に肯定応答することができる。例えば、RO40は、TDU34に以下のメッセージを送信することができる。TDU34は、PID_Uと、9においてメッセージを受信した後にRO40によって生成されたPID_ROとを受信することによって、RO40とのプロセス識別情報を保有する場合がある。TDU34は、証明書CertROで受信された公開鍵KROPubを用いてpackage_9のハッシュの署名を検証することができる。11において、式10に関連するメッセージを受信した後、TDU34は、認証情報を要求する許可をユーザ32に付与するスクリーンメッセージをユーザ32に対して発することができる。このメッセージは、メッセージ3で使用された署名および検証プロセスと同様であるが逆向きの、ME側で同じ鍵を用いて検証されるようにTHSM側で適用され得る署名鍵KtempIの使用を示す。nonceUが、TDU34によってMEに返され、往復することができる。IDUが、ユーザ32を識別するためにMEおよびTDU34によって使用されることができ、PID_Uとともに現在の登録および認証情報のロールアウトに結び付くことができ、そのことがプロセスの曖昧性を防ぐことができる。ユーザは、認証情報のロールアウトを開始することができ、例えば、ユーザは、リモートの所有者に申し込んで加入者に関連する認証情報を取得することができる。12において、ユーザ32は、認証情報の要求によって、11で伝達されたメッセージに応答することができる。パスワードを、共有された暗号鍵KtempCを用いて保護することができる。nonce9が、TDU34に返されてもよい。TDU34は、共有された鍵の組を用いてパスワードを復号し、署名を検証することができる場合がある。11において伝達されたメッセージは、PID_UとIDUの組み合わせの使用を表す。ノンスおよびPIDは、ユーザ/所有者に対して透過的であってもよく、人間でない通信エンティティによる使用に限定してもよい。13において、TDU34は、今や、TDRO40に認証情報のユーザ要求を転送することができ、そのことが、TDRO38がRO40に直接の要求を行うことを引き起こすことができる。PID_ROおよびPID_Uが、通信エンティティとのプロセスの関連付けを可能にする。ここで、TDRO40は、3つのプロセスIDを関連付けることができる。メッセージの検証が、6で伝達されたメッセージで受信されたCertTDUで受信されたKTDUPubを用いて行われてもよい。14において、TDROが、SDM36に準自律的な完全性の検証の要求を行うことができる。準自律的な完全性の検証は、重要な完全性のインジケータ例えば、TPIA、TPES、およびSCARDのハッシュ値の使用に制限されてもよい。証明書CertTSIMが、SDM36がPackage_13のハッシュの署名の検証のための公開鍵KTDROPubを得ることを可能にするために送信されてもよい。プロセスIDの関連付けが、PID_Uの使用によって維持されてもよい。SDM36は、外部のエンティティ、例えば、THSMの外部のエンティティと通信しない場合があるので、PID_U以外は必要としない場合がある。15において、SDM36が、例えば、RTOプロセス以降に行われた場合がある構成の変更に関して更新された証明情報を収集することができる。TPIA、TPES、およびSCARDが、必要に応じて更新される場合があり、完全性データを、単一の値IV完全性検証値へとハッシュすることができる。PID_UおよびIVが、返信メッセージでTDRO34に送信されてもよい。ノンスnonceTDROが、返されてもよい。署名が、証明書CertSDMで得られた公開鍵KSDMPubを用いて検証され得る。16において、TDRO38が、RO40に認証情報のロールアウトの要求を行うことができる。16において送信されるメッセージにおいて、13におけるメッセージの証明書CertROでTDRO40によって受信されたRO40の公開鍵KROPubを用いて暗号化された識別子IMSIkが、送信されてもよい。完全性の値IVを、信頼の検証の目的で送信することができ、プロセスIDPID_Uを、9におけるメッセージの情報とのプロセスの関連付けを可能にするために送信することができる。RO40は、そのRO40の秘密鍵KROPrivを用いてIMSIkを復号し、証明書CertTDROでRO40によって取得された公開鍵KTDROPubを用いて署名を検証することができる。17において、認証情報を、RO40によってTDRO38に送信することができる。認証情報は、16におけるCertTDROから取得された公開鍵KTDROPubを用いて暗号化されてもよい。これは、認証情報をTDRO38にバインドすることができる。TDRO38は、そのTDRO38の秘密鍵KTDROPrivを用いて認証情報をバインド解除することができる。ノンスnonce11が、往復されてもよい。TDRO38は、13における関連する証明書で受信された公開鍵KROPubを用いて署名を検証することができる。プロセスIDPID_ROが、正しいプロセスの関連付けを提供する。例えば、17に指示されたように認証情報が受信されると、認証情報の鍵は、保護されたメモリに記憶されてもよく、またはSDM36に提供されたセキュリティポリシーに従って記憶されてもよい。ポリシーは、RTOプロセス中に定義されてもよい。18において、ロールアウトが完了すると、肯定応答メッセージが、RO40に送信されてもよい。ノンスnonce12が返されてもよく、プロセスの曖昧性をPID_Uによって防ぐことができる。RO40は、16において取得された公開鍵KTDROPubを用いて署名を検証することができる。19において、TDRO38が、ロールアウト完了肯定応答メッセージをTDU34に送信することができる。ノンスnonceTDU213参照およびnonceTDU116参照が返されてもよく、プロセスの曖昧性をPID_Uによって防ぐことができる。署名が、証明書CertTDROで取得された公開鍵KTDROPubを用いてTDU34によって検証されてもよい。20において、ユーザ32は、認証情報が受信され、構成されることを指示するスクリーンメッセージをTDU34から提供されてもよい。今や、認証情報が、ユーザ32が認可される安全なサービスで利用可能となってもよい。ノンスnonce10が、返されてもよい12参照。署名の検証が、3、11、および12に関連して説明されたように行われてもよい。PID_UとIDUの組み合わせの使用が、11に関連して説明されたように行われてもよい。21において、ticketkが現在使用中であり、他の所に配布されるべきでないことを指示するメッセージが、POS30に送信されてもよい。POS30は、2においてそのPOS30が受信した証明書CertROで取得された公開鍵KROPubを用いて署名を検証することができる場合がある。PID_ROが、プロセスの関連付けを可能にする。図8に示されたコールフローに関連して、一方向に移動する3つのノンスが示されてもよい。つまり、それらのノンスは、それらのノンスが最初に伝達されたとき以後のメッセージで返されない場合がある。3つのそのようなノンスは、10におけるnonce8、15におけるnonceSDM、および21におけるnonce15である。コールフローの説明で指示されていないが、これらのノンスのそれぞれに関して、ノンスを含むACKが、受信者から対応する送信者に送信される返されることが仮定されてもよい。したがって、例えば、nonce8が、10におけるメッセージの受信の後で、TDU34によるACKメッセージによってRO40に返されてもよい。III.認証情報および/またはドメインのマイグレーション認証情報および/またはドメインのマイグレーション、例えば、1つのデバイス移行元から別のデバイス移行先へのドメインのマイグレーション、移行元のデバイス上の第1のドメインから移行先のデバイス上の第2のドメインへの認証情報のマイグレーション、デバイス上の第1のドメインから当該デバイス上の第2のドメインへの認証情報のマイグレーションなどのためのシステム、方法、および手法が開示される。認証情報のマイグレーションを示す例が、提供され得る。しかし、本明細書において開示されたマイグレーションはそのような実施形態に限定されないことを理解されたい。マイグレーションは、第1のドメインから第2のドメインに認証情報をマイグレーションすることを含んでもよい。例えば、デバイスのユーザが、デバイス上のリモート所有者ドメインにアクセスできる場合がある。ユーザは、リモート所有者ドメインに記憶された認証情報を有する場合があり、例えば、認証情報は、ユーザが、リモート所有者ドメインに関連するリモートの所有者によって提供されるサービスを使用することを可能にする。さらに、ユーザは、認証情報を異なる第2のリモート所有者ドメインに移す、すなわち、マイグレーションすることを望む場合がある。第2のリモート所有者ドメインは、同じデバイスまたは異なるデバイス上にある場合がある。例えば、ユーザは、新しいデバイスを購入した場合があり、ユーザは、新しいデバイスでリモートの所有者のサービスを使用することを望む。ユーザは、例えば、現在使用中のデバイスのTSIMのコア構成コアセキュリティ認証情報:永続的なアイデンティティおよび共有された秘密K、ならびに/またはTSIM機能/実行ファイルを新しく購入されたデバイスに移すことを望む場合がある。TSIMの概念では、デバイス上に構成された1またはそれ以上のリモートで所有されるドメインにそれぞれがアクセスできる潜在的に複数のユーザが、これらのドメインのうちの1またはそれ以上のTSIMのコアを、ユーザがやはりアクセスできる別のデバイスに移したい場合がある。本明細書において開示されたシステム、方法、および手法は、移行元から移行先へのマイグレーションを説明することができ、この手順は、複数のドメインの移動のために繰り返されるとみなされ得る。認証情報およびドメインは、本明細書に記載の信頼できるTHSMtrustedhardwaresecuritymoduleのフレームワークの一部である場合がある。例示的なマイグレーションが、同じ所有者に属する移行元のドメインおよびターゲットのドメインを参照して示されてもよい。しかし、本明細書において開示されたマイグレーションはそのような実施形態に限定されないことを理解されたい。以下のうちの1つまたはそれ以上が、マイグレーションが行われるために満足されるおよび/または仮定される場合がある。ユーザ例えば、デバイスの所有者によって許可されることによるが、ユーザプロファイルが記憶され、移行元のデバイスと移行先のデバイスの両方で保有されるユーザドメインを登録および作成することができる。マイグレーションが、あるレベルのROリモートの所有者/オペレータの関与を含んでもよい。RO、および移行元のデバイスと移行先のデバイスの両方のSDMシステム全体のドメインマネージャが、マイグレーションが続行することを阻むことができる場合がある。ROは、デバイスが、マイグレーションが続行することを許すのに十分な信頼性のレベルにあるかどうかを判定することができる。ユーザプロファイルが、そのユーザが利用可能なサービスを指示するアカウント情報、およびその他のユーザの個人データなどのユーザ登録データ、ならびに識別子例えば、ユーザ名およびユーザ認証データ例えば、パスワード、実際のパスワードのダイジェスト、生体認証データなどを備えてもよい。1人の所有者を有する複数のデバイスでサービスにアクセスできるユーザの登録データおよびアカウント情報は、それらのデバイスでのそのユーザに関するアクセス可能なサービスに応じてデバイスごとに変わり得る。マイグレーションは、マイグレーションされる認証情報に関連するサービスに関連するユーザ登録データの転送を含んでもよい。ユーザドメインが、ユーザがデバイスと通信するために必要である場合がある。つまり、ユーザが、概してサービスプロバイダによってリモートで所有されるドメインによって提供されるサービスにアクセスすることができるのは、ユーザドメインを通じてである場合がある。デバイスの所有者が、ユーザである場合がある。場合によっては、デバイスの所有者が、唯一のユーザである場合がある。デバイスは、1人の所有者を有することに制限される場合があるが、2人以上のユーザを持つことができる。各ユーザは、所与のユーザのプロファイルによって定義された一意的な構成を有する異なるユーザドメインを持つことができる。移行元のデバイスから移行先のデバイスへの開示された例示的なマイグレーションに関しては、移行元のデバイスと移行先のデバイスの両方が、同じ所有者を有する場合がある。ユーザのアクセスは、ユーザが登録され、使用の認可がされたサービス、およびひいてはそれらの関連するドメインに制限され得る。PasswordUPWUおよびIDUは、特定のドメインに固有である場合があり、ドメインがマイグレーションされ、同じユーザに関して、似ているが異なる登録認証情報がその他のドメインに対して存在する場合がある。ユーザによって提供された登録認証情報に応じて、信頼できるユーザ/所有者ドメインは、それらの認証情報を適切なドメインに導き、安全にプロビジョニングする役割を担い、それによって意図されるサービスがアクセスされ得る。マイグレーションが行われるために、移行元のドメインのROリモートの所有者が移行先のドメインの所有権もRTOを介して取得していることが必要である場合がある。そのとき、ROは、その最初のポリシーおよび構成を知る場合がある。移行先のデバイスは、独自のシステム構成ファイルを有し、したがって、スタートアップドメイン例えば、デバイスの製造者のドメイン、ならびにユーザ/所有者ドメイン、および将来の所有のための初期ドメインの最小限の組と、場合によっては既に存在するリモートで所有されるドメインとを持っている場合がある。SDPシステム全体のドメインポリシーは、同じ所有者を有する複数のデバイスにわたって必ずしも複製されない。移行元のドメインおよび移行先のドメインのリモートの所有者は、マイグレーションが実行される前に両方のデバイスのSDPを受け入れていると仮定される場合がある。マイグレーションに関与するエンティティは、ユーザ/所有者、移行元に関連するシステム全体のドメインマネージャ、移行先に関連するシステム全体のドメインマネージャ、移行元に関連するリモート所有者ドメイン、移行先に関連するリモート所有者ドメイン、またはリモートの所有者のうちの1つまたは複数を含み得る。リモート所有者ドメインは、リモートで所有されるドメインと呼ばれることもある。ユーザは、デバイス、例えば、1またはそれ以上のリモート所有者ドメインを含むデバイスのユーザである場合がある。ユーザは、デバイスの所有者でもある場合がある。ユーザは、リモート所有者ドメインのリモートの所有者に登録されてもよい。ユーザに関連する認証情報が、ユーザがリモートの所有者によって提供されるサービスにアクセスすることを可能にするためにリモート所有者ドメインにロードされてもよい。ユーザは、同じデバイスまたは異なるデバイス上の別のドメインに認証情報をマイグレーションすることを望む場合がある。ユーザは、認証情報のマイグレーションを開始することができる。ROリモートの所有者は、デバイスを介してユーザにサービスを提供することができる。リモートの所有者は、ユーザがサービスを使用するために必要とされる場合がある認証情報を提供することができる。認証情報は、リモート所有者ドメインとリモートの所有者の間の強力な秘密として機能することができる認証鍵Kを含んでもよい。例として、ROは、以下、すなわち、MNO、その他の通信ネットワークのオペレータ例えば、WLAN、WiMaxなど、電子メールサービスプロバイダ、インターネットサービスプロバイダ、ソーシャルネットワークサービスプロバイダ、デジタルコンテンツ音楽、電子ブック、ビデオなどプロバイダ、ゲームサービスプロバイダ、金融サービスプロバイダ、アプリケーションサービスプロバイダ例えば、モバイル決済、モバイル発券、DRM、モバイルTV、位置に基づくサービスなどのサービスプロバイダ、またはIMSサービスプロバイダなどのうちの1つまたはそれ以上であってもよい。TDROリモート所有者ドメインは、リモートの所有者によって定義された機能を提供することができるデバイス上のドメインである。リモート所有者ドメインは、上記説明されたようにTHSMの一部である場合がある例えば、図2を参照。リモート所有者ドメインは、上述のRTOプロセスに関連して説明されたTSIM機能を有する場合がある。リモート所有者ドメインは、リモートの所有者によって提供された認証情報を記憶することができる。TDROは、ユーザドメインからIDUおよびPID_UユーザのIDおよびプロセスIDを受信し、登録および認証情報のロールアウト中にこの情報をさまざまに使用することができる。認証情報がマイグレーションされるTDROS移行元のリモート所有者ドメインと、認証情報がマイグレーションされるTDROD移行先のリモート所有者ドメインとが存在し得る。例えば、ユーザは、移行元のデバイスに関連するリモート所有者ドメインから移行先のデバイスに関連するリモート所有者ドメインへの転送を開始することができる。SDMシステム全体のドメインマネージャ、例えば、節Iで開示されたSDMが、マイグレーションプロセスの一部として1またはそれ以上のプラットフォームに関連する証明情報を提供することができる。例えば、準自律的な完全性の確認などの完全性のインジケータが、SDMによって提供されてもよい。SDMは、ドメインのコンポーネントなど、THSMの一部である場合がある例えば、図2を参照。SDMは、信頼できるユーザドメインおよび/または信頼できる所有者ドメインと組み合わされてもよい。移行元のリモート所有者ドメインに関連するSDMS移行元のシステム全体のドメインマネージャと、移行先のリモート所有者ドメインに関連するSDMD移行先のシステム全体のドメインマネージャとが存在し得る。下の最初の3つの式のそれぞれは、2つの部分、移行元のデバイスにおける通信に関する1つの部分と、移行先のデバイスにおける同様の通信に関するもう1つの部分とを含んでもよい。これらの部分は、例えば、式1の場合、1移行元の部分および1a移行先の部分とラベル付けされてもよい。これらの式中の鍵および証明書は、たとえそれらがそれらのそれぞれの部分で異なる値を示す場合があるとしても同様に表記され得る。例えば、式1において、機密性の鍵および完全性の鍵は、たとえそれらが異なる鍵の組を表す場合があるとしても、移行元の部分1と移行先の部分1aの両方に対してそれぞれKtempCおよびKtempIと表記され得る。別の例において、KSDMPubおよびKSDMPrivが、それらの移行元の使用および移行先の使用における異なる公開-秘密鍵の対を表す場合があり、例えば、3および3aを参照のこと。マイグレーション全体にわたって、メッセージの署名および署名の検証が、承認されてもよい。公開-秘密鍵の対を、このセキュリティ機能を実行するために使用することができ、それによって、メッセージが認証され、その上、完全性が保護される。信頼できる第三者の証明書によって、メッセージの署名者により秘密署名鍵に対応する公開鍵を配布することが、含まれてもよい。例えば、CertTSIMと表記される移行元のリモートで所有されるドメインおよび移行先のリモートで所有されるドメインに関してそれぞれCertTSIMSおよびCertTSIMDと表記される第三者が発行した証明書が、秘密鍵KTSIMPrivKTSIMSPrivかまたはKTSIMDPrivかのいずれかに対応する公開鍵KTSIMPubそれぞれ移行元または移行先に応じてKTSIMSPubかまたはKTSIMDPubかのいずれかを配送するために使用されてもよい。秘密鍵は、所与のメッセージを固定長にするそのメッセージのSHA-Xハッシュに署名する。対応する公開鍵が、署名の検証のために使用される。プラットフォームとのユーザ/所有者の通信は、図9A/9Bに示されず、または式で参照されない端末を通じて実行され得る。移行元のデバイスと移行先のデバイスの両方に関して、事前にプロビジョニングされた対称的な異なる鍵の組KtempCおよびKtempIが、端末とTHSMの間の通信を保護することができる。ユーザ/所有者が、移行元のデバイスかまたは移行先のデバイスかのいずれかの信頼できるユーザ/所有者ドメイン総称的にSDM/TDU/TDOと表記されると通信するとき、そのような鍵が、含められることができる。プロセスID管理は、マイグレーションにおいては例えば、帯域外メッセージングが利用可能でない場合があるので使用されない場合がある。表記SDM/TDU/TDOが、組み合わされたSDMとユーザ/所有者ドメインを表すために使用されてもよい。表記SDM/TDU/TDOは、別々のエンティティを表す場合があり、マイグレーションの異なる部分において、参照はSDMに限られる場合があり、その他のときには、参照はユーザ/所有者ドメインに限られる場合があり、参照は状況に依存する。状況は、例えば、ユーザIDおよび場合によってはパスワードを使用するマイグレーション要求メッセージングを含むユーザ/所有者の対話である場合があり、または状況は、関与がSDMに限られる場合があるポリシーに関する対話である場合がある。同様の表記によって、ユーザ/所有者は、ユーザ/所有者の対話を示す場合があり、SDMは、SDMの対話を示す場合がある。SA-IV準自律的な完全性のインジケータなどの完全性のインジケータが、移行元のデバイスおよび移行先のデバイスの信頼性のレベルを評価するためにマイグレーションにおいて使用されてもよい。準自律的な完全性のインジケータは、完全性の検査を通らないデバイス内のモジュールのリストを含んでもよい。表記SA-IVsrcおよびSA-IVdestが、移行元および移行先の準自律的な完全性のインジケータを示すために使用され得る。Proc_IDプロセス識別子が、マイグレーション要求、およびプロセスのために必要とされ得る後に続くメッセージングの発生源についての曖昧性を回避するために、マイグレーションに関連するメッセージング全体を通じて提供されてもよい。署名メカニズムによるメッセージの完全性の保護が、このアイデンティティの外部の不正行為を防止することができる。ユーザIDおよびプロセスIDの使用が、例えば、ユーザが複数のドメインをマイグレーションすることを望む場合の曖昧性を回避するためにドメイン識別子を含むように拡張されてもよい。以下の例は、ユーザが単一のドメインをマイグレーションする場合を示す場合がある。しかし、プロセスは、その場合に限定されず、複数のドメインのマイグレーションの場合も含んでもよい。PWUユーザのパスワードの最初の使用は、ユーザの成りすましを防止することができ、したがって、マイグレーション要求の開始は、正規のユーザ/所有者に制限され得る。リプレーからの保護が、プロトコル全体を通じてノンスを使用することによって提供されてもよい。往復の通信の発生元が、意図される受信者にノンスを送信することができ、受信者は、署名されたハッシュの一部として発生元にそのノンスを返すことができる。場合によっては、ノンスは、式4で移行元のドメインからnonce4を受信した後の式7aにおけるROによるそのnonce4の返却のように、プロトコルにおいてさらに後で返される場合がある。ノンスは、概して、順番に従って連続的に付番されることができ、例えば、ステップiで送信者によって生成されたノンスは、通常、値nonceiを得ることができる。下の式の特定の例は、帰ってくるノンスを示す場合があり、発生元からのノンスの転送は示されない。それぞれの場合のノンスは、示される通信の前の出ていく通信において発生元によって提供されたと仮定されてもよい。このような発信するoutgoing通信は、必要とされるノンスに制限される場合がある。これらの省略は、以下の場合に起こる。i.SDMSで発生する1におけるnonce1ii.SDMDで発生する1におけるnonce1aiii.TDRODで発生する2式2におけるnonce2div.TDROSで発生する2式2aにおけるnonce2sv.ROで発生する4におけるnonce4cvi.TDRODで発生する7におけるnonce4avii.SDMDで発生する5におけるnonce4bviii.TDRODで発生する8におけるnonce8aix.端末で発生する18におけるnonce18x.端末で発生する20におけるnonce20図9Aおよび9Bは、認証情報のマイグレーションを実装する例示的なコールフローを表す。図9Aは、移行元のドメインおよび移行先のドメインの完全性の検証がリモートの所有者によって実行され得る例示的なマイグレーションを表す。図9Bは、移行元のドメインの完全性の検証がSDMDによって実行されてもよく、移行先のドメインの完全性の検証がSDMSによって実行されることができる例示的なマイグレーションを表す。図9Aおよび9Bのマイグレーションおよび関連するコールフローの詳細などのマイグレーションおよび関連するコールフローの詳細が提供される。上述のように、3aまでの式において、総称的な表記が使用される場合がある。図9Aを参照すると、例示的なマイグレーションは、所有者でもある場合があるユーザ、ユーザ/所有者940と、SDMS、TDUS、TDOSのうちの1つまたは複数を指す場合があるSDMS/TDUS/TDOS950と、移行元のリモート所有者ドメインTDROS960とを含む場合があり、TDROD970およびSDMD/TDUD/TDOD980を含む移行先のデバイスに関する同様の参照をともなう。マイグレーションの前に、ROリモートの所有者990が、TDROD970のRTOを完了し、TDROD970の最初のポリシーおよび構成を知っている場合がある。1および1aにおいて、認証情報のマイグレーション要求が、ユーザ/所有者940によってなされてもよい。式1および1aは、ユーザ/所有者940に関する通信を示し、ユーザ/所有者940は、マイグレーションを開始するために、ログイン情報およびマイグレーション要求をSDMS/TDUS/TDOS950およびSDMD/TDUD/TDOD980移行元のおよび移行先のユーザ/所有者ドメインにそれぞれ送信することができる。鍵KtempCがユーザのパスワードを暗号化し、KtempIがメッセージに署名する。上述のように、KtempCおよびKtempIは、端末図示せずとTHSMとのインターフェースを介した通信を保護することができる。事前にプロビジョニングされた対称的な鍵のプロパティが、移行元のドメインおよび移行先のドメインがパスワードを復号し、メッセージの署名を検証することを可能にすることができる。ユーザは、ログイン情報移行元のドメインおよび移行先のドメインに対して同じである場合があり、例えば、ユーザが、両方のドメインに関してサービスに一度登録する場合があるを移行元のおよび移行先のユーザ/所有者ドメインに提供する場合があり、ここで、移行先に関して、ログインの認証情報は転送済みである。TSIMの認証情報がマイグレーションされるとき、ユーザ登録プロファイルの転送が、例えば、16において行われ得る。1の前に、ノンス1および1aが、ユーザ/所有者940による最初のマイグレーション要求で使用するために、それぞれ、移行元のSDMおよび移行先のSDMによって端末に送信された場合がある。これは、ステップ1におけるそれらのノンスの返却によって反射を防止することができる。PWUおよびIDUが、マイグレーションされているドメインのTSIMに関連付けられ得る。同じユーザが、異なるパスワードおよびログインIDの認証情報を用いてその他のリモートで所有されるドメインに登録する場合がある。システム全体のポリシーの検査が、ポリシーの規定がマイグレーションの続行を禁じるかどうかを判定するためにそれぞれのSDMによって行われてもよい。システムレベルの検査は、万一いずれかのプラットフォーム上に2人以上のドメインのリモートの所有者が存在する場合に、複数のそのような所有者の間で起こり得る衝突を考慮に入れることができる。1および1aに関して、通信される情報は、移行元のおよび移行先のSDM950および980によるポリシーの検査と、移行元のおよび移行先の信頼できるドメインTDUX/TDOX950および980によるユーザのログイン情報の処理とを要求することができ、X=SまたはDである。一実施形態において、マイグレーション要求は、移行元に要請されるが、移行先には要請されない場合がある。例えば、移行先のドメインを有するデバイスが、ユーザ/所有者940にまだ販売されない場合があり、マイグレーションが、販売プロセスの一部とされる場合があり、例えば、販売者が、ユーザドメインを受け取るまでデバイスを保管する場合があり、それを支払までの抵当hostageとする。この場合、移行先のデバイスは、最初のユーザのログインまで、受け取られたドメインを非アクティブのままにする場合がある。この最初のユーザのログインは、受け取られたユーザドメインTDUからユーザが認証されたメッセージを取得することができる別のドメインデバイス製造者ドメインTDDMによって処理される必要がある場合があり、そのとき、TDDMが、移行先のデバイス上でTDUをアクティブにすることができる。2および2aにおいて、SDMS/TDUS/TDOS950およびSDMD/TDUD/TDOD980ユーザ/所有者ドメインが、ユーザによって開始されたドメインのマイグレーション要求メッセージを、例えば、それぞれ、式2aおよび2でTDROS960およびTDROD970ROの移行元のドメインおよび移行先のドメインに転送することができる。ユーザの識別情報IDUが、サービスの認可の検査のために必要とされ得る。Proc_IDプロセスIDが、さまざまなサービスの同時の要求を行う複数のユーザ間の潜在的な曖昧性をなくすために例えば、4参照生成される。Proc_IDとユーザIDIDUの間の関連付けは、明示的に示されない場合がある。公開鍵KSDMPubが、証明書CertSDMによってTDROS960およびTDROD970移行元のドメインおよび移行先のドメインに渡されてもよい。TDROS960およびTDROD970移行元のドメインおよび移行先のドメインは、KSDMPubを用いてメッセージの署名を検証する。メッセージは、移行元の転送および移行先の転送のためにKSDMPrivによって署名されてもよい。ノンス、nonce2dおよびnonce2sが、それぞれ、移行先のドメインおよび移行元のドメインによってそれらのそれぞれのSDMに渡されたと仮定されてもよい。署名および転送の動作は、ユーザ/所有者の移行元のおよび移行先のドメインに関連する機能によって実行されてもよい。2bおよび2cにおいて、それぞれのTDROS960およびTDROD970移行元のドメインおよび移行先のドメインが、マイグレーションに関するポリシーの衝突がドメインレベルで存在するかどうかを判定するための検査を実行することができる。システム全体のまたはドメインレベルのポリシーの衝突は、マイグレーションを阻む場合があり、例えば、3において、プロトコルの継続を防止する否定応答NACKが送信されてもよい。3および3aにおいて、TDROS960およびTDROD970移行元のドメインおよび移行先のドメインが、肯定ACKまたは否定NACK応答で、マイグレーション要求、それぞれ1および1aに応答する。SDMS/TDUS/TDOS950およびSDMD/TDUD/TDOD980移行元のまたは移行先のユーザ/所有者ドメインが、そのリモートで所有されるドメインに関するポリシーがこのマイグレーション要求を禁じることを指示するNACKを受信する場合、マイグレーションは終了される。両方がACKを受信する場合、プロセスは継続することができる。ユーザ/所有者ドメインは、式3および3aにおいて、それらの証明書CertTSIMによって取得され得る公開鍵KTSIMPubのそれらのそれぞれのバージョンでそれらのメッセージの署名を検証することができる。示されたように、メッセージは、KTSIMPrivを用いて署名されてもよい。3bにおいて、TDROS960が、ユーザ所有者ドメインSDMS/TDUS/TDOS950から許可されたメッセージを受信することができる。式3b以降、移行元と移行先の鍵の組およびそれらの対応する証明書の間で表記上の区別がなされる。メッセージの署名が、例えば、式2aで伝達されたCertSDMS証明書CertSDMからTDROS960によって取得された公開鍵KSDMSPubを用いて検証されることができる。4において、TDROS960が、RO990にマイグレーションが要求されていることを警告するメッセージを送信することができる。メッセージは、TDROS960およびTDROD970移行元のドメインおよび移行先のドメインのポリシー、構成の状態、およびSA-IVを検査することを指示することができ、例えば、2を参照して、IDUおよびデバイスIDのRO990への転送が、認可の検査の目的で使用されてもよい。メッセージの署名が、証明書CertTSIMSで受信された公開鍵KTSIMSPubを用いて検査および検証されてもよい。移行元のドメインがマイグレーションの要求を許可しない場合、プロセスを終了することができ、例えば、式4のメッセージは送信されない。しかし、移行元がマイグレーションを許可し、移行先のドメインが同時に許可しない場合があり、これは、競合状態につながる場合がある。そのような場合、プロセスは、終了されるか、または場合によっては例えば6において再ネゴシエーションされる場合がある。万一、移行元は許可しないが、移行先は許可することが起こったとすると、移行先のドメインによって開始されたアクティブなプロセスは、特定の事前に定義された期間の後タイムアウトする場合がある。5および5aにおいて、RO990が、それぞれ、SDMS/TDUS/TDOS950およびSDMD/TDUD/TDOD980移行元のSDMおよび移行先のSDMからのポリシーおよび構成情報を要求することができる。例えば、RO990は、移行元のドメインおよび移行先のドメインからの構成、デバイスID、SA-IV情報、ならびにマイグレーションポリシーを要求することができる。システム全体のドメインポリシーを管理するSDMが、要求を受信し、RO990に対するそれらのSDMのそれぞれの応答を準備することができる。両方のメッセージに関して、メッセージの署名が、CertROで得られた公開鍵KROPubを用いて検証されることができる。6および6aにおいて、SDMSDMS/TDUS/TDOS950およびSDMD/TDUD/TDOD980が、要求された情報をRO990に送信する。マイグレーションが移行先のドメインTDROD970によって禁じられる場合、NACKメッセージがRO990に返され、プロセスが終了される。この場合、RO990は、なぜマイグレーションが拒否されるのかを知るために、SDMD/TDUD/TDOD980移行先のSDMからの追加的な情報を要求することができる。4の要求から、移行元のドメインは既に許可したことが理解され得る。修正されたドメインの構成例えば、サービスの修正がそれに受け入れ可能であるかを判定するためにRO990とSDMの間の潜在的なネゴシエーションが存在する場合がある。修正の許容場合は、例えば、例えば、所有者とは異なるユーザがマイグレーションを開始していると仮定すればデバイスの所有者、または元の構成を禁じるドメインポリシーを有する別のリモートの所有者によって判定されてもよい。ネゴシエーションが失敗する場合、マイグレーションは、さらなる通信なしに終了される場合があり、移行元のドメインによってアクティブ化されたマイグレーションプロセスは、事前に決められた期間の後、タイムアウトする場合がある。そうでない場合、マイグレーションは、続行することができ、移行先のドメインに対する修正が、そのドメインの別のRTOを引き起こす場合がある。引き続き6および6aを参照すると、RO990は、Proc_IDならびに移行元のおよび移行先のデバイスIDを受信して、プロセスを2つのデバイスと関連付けることができる。登録されたサービスに関する認可の検査が、行われ得る。SA-IVsrcおよびdestの受信によって、両方のデバイスの完全性が検証され得る。構成の許容場合も、評価され得る。RO990は、それぞれ、証明書CertSDMDおよびCertSDMSから得られた公開鍵KSDMDPubおよびKSDMSPubを用いて署名を検証することができる。一実施形態において、ドメインの構成およびポリシーの要求は、そのような情報がマイグレーションの発生までに起こり得るRTOプロセスから取得されるので、省略される場合がある。6bにおいて、RO990が、TDROS960およびTDROD970移行元のドメインおよび移行先のドメインのポリシー、構成、および信頼性の許容場合を検査することができる。NACKがないものと仮定する場合がある6および6aにおいて移行元のドメインおよび移行先のドメインから受信された構成のポリシーおよび完全性のインジケータのそのRO990の評価に基づいて、RO990は、マイグレーションを継続するか、または終了するかのいずれかの決定を行うことができる。継続する場合、7および7aにおいて、継続するためのメッセージが、それぞれ、TDROS960およびTDROD970に送信されることができる。RO990が現在の構成を受け入れ可能でないと認識する例えば、構成が最初のRTO以降に変わった場合がある場合、RO990は、いかなるネゴシエーションもせずにマイグレーションを終了するか、または関係するものが受け入れ可能であり、継続を可能にする新しい構成およびポリシーをネゴシエーションすることができる。メッセージは、CertROから得られた公開鍵KROPubを用いて検証されてもよい。5、5a、6、および6aに関連する例示的なバリエーションにおいて、移行元のドメインおよび移行先のドメインの完全性の状態は、RO990によって検査されない場合がある。完全性の状態は、ドメイン自体によって検査されてもよい。つまり、移行元のドメインの完全性の状態は、移行先のドメインによって検査されてもよく、その逆も可能である。これは、ドメインが、その他のドメインの完全性の状態を検査するそれらのドメインの能力の観点でRO990の有能な代理であると仮定する場合がある。8において、TDROS960が、例えば、移行元および移行先の構成、信頼性のレベル、およびポリシーがマイグレーションのために受け入れ可能であるというRO990による判定の後で、マイグレーションサービスをアクティブ化するためにTDROD970にメッセージを送信することができる。ドメインの状態の要求が、発せられることができる。受信者は、証明書CertTSIMSで運ばれた公開鍵KTSIMSPubを用いて署名を検証することができる。9乃至12において、1またはそれ以上のアクションが、ドメインの認証情報の転送のための移行元および移行先の準備の状況を判定するために行われてもよい。RO990が、移行元のドメインおよび移行先のドメインの信頼性を評価し、それらをプロトコルが続行するのに適するとみなしたと仮定してもよい。9において、TDROD970が、SDMD/TDUD/TDOD980移行先のユーザ/所有者ドメインからの例えば、ドメインの利用可能なメモリの状態を示す状態情報を要求することができる。9aにおいて、SDMD/TDUD/TDOD980移行先のユーザ/所有者ドメインが、状態情報を提供することができる。署名の検証が、例えば、2においてCertSDMとして示されたCertSDMDで取得された公開鍵KSDMDPubを用いて実行されてもよい。式9および9aは、移行先のドメインがそのドメイン自身の状態を、式8におけるその情報の要求の後で取得することを示す。10において、TDROD970が、状態情報をTDROS960に提供することができ、例えば、式10において、移行先のドメインが、要求された状態情報を移行元に提供する。10aにおいて、移行元のドメインが、移行先の状態情報の検査を実行することができる。例えば、移行元のドメインが、続行する、延期する、または終了することを決定する場合がある。移行先の状態情報が受け入れ可能な準備の状態例えば、メモリおよび機能的な能力に関する受け入れ可能な状態を指示する場合、移行元のドメインは、続行することを決定することができる。移行先の状態情報が受け入れ可能でない準備の状態を指示する場合、移行元のドメインは、必要とされるソフトウェアのダウンロードが完了するまでマイグレーションを延期することを決定することができる。11において、TDROS960が、SDMS/TDUS/TDOS950移行元のユーザ/所有者ドメインからの例えば、必要とされるソフトウェアのバージョンなどのマイグレーション機能の状態を示す状態情報を要求することができる。11aにおいて、SDMS/TDUS/TDOS950移行元のユーザ/所有者ドメインが、状態情報を提供することができる。式11および11aは、移行元に関して、9および9aの同様のプロセスを提供する。この情報は、以下に示されるように、移行元の準備の移行先のドメインの評価ために移行先のドメインに渡さてもよい。移行元のユーザ/所有者ドメインは、CertTSIMS例えば、3参照で取得された公開鍵KTSIMSPubを用いてメッセージ式11の署名を検証することができる。式11aにおいて、署名は、ステップ3のCertSDMSで取得された公開鍵KSDMSPubを用いて検証される。12以降、署名の検証に対する明示的な言及はされない場合がある。署名は、適切な署名鍵を用いて指示されてもよく、証明書の受け渡しも、必要に応じて指示される。これらの場合のそれぞれにおいて、上述のステップにおいて示された公開鍵が、関連する署名を検証するために使用されてもよい。12において、TDROS960が、TDROD970に状態情報を提供することができ、例えば、式12は、移行元がその移行元の状態を移行先に提供することを示す。式12は、マイグレーションOKメッセージも渡すことができる。マイグレーションが続行することができる前に状態の変更が必要とされる場合、延期メッセージが、代わりに用いられる場合がある。12aにおいて、移行先のドメインが、移行元の状態情報の検査を実行することができる。例えば、移行先のドメインが、続行する、延期する、または終了することを決定する場合がある。移行元の状態情報が受け入れ可能な準備の状態例えば、受け入れ可能最新のマイグレーションソフトウェアを指示する場合、移行先のドメインは、続行することを決定することができる。移行元の状態情報が受け入れ可能でない状態を指示する場合、移行先のドメインは、必要とされるソフトウェアがダウンロードされるまでマイグレーションを延期することを決定することができる。一実施形態において、9乃至12で示されたように移行元のドメインの状態を検査する代わりに、移行先のドメインは、パッケージを受信した後で、受信されたパッケージを検査する場合がある。そのとき、完全なパッケージが、最初に、移行先のSDMに転送され、知られているIV完全性の検証の基準と照合される必要がある場合がある。安全なブートの結果として生じるIVは、マイグレーションの構成のパッケージから計算されるIVとは異なる場合がある。13において、TDROD970が、例えば、認証情報送信sendcredentialsメッセージでTDROS960が認証情報を送信することの要求を送信することができる。13のメッセージは、10aおよび12aによりマイグレーションが受け入れ可能であることを指示されるときに送信されてもよい。13aにおいて、TDROS960が、認証情報をTDROD970に送信することができる。13bにおいて、TDROD970が、マイグレーションされた認証情報を用いて構成されてもよい。万一、延期メッセージが送信されたとすると、例えば、プロセスが移行元のタイマーおよび移行先のタイマーの制限内に再開しない場合、タイムアウトが発生する場合がある。14乃至20において、クリーンアッププロセスが、実施されてもよい。式14乃至20は、クリーンアップを実行するメッセージを含み、それによって、マイグレーションが行われ、ROのポリシーが移行元のドメイン上の古い認証情報の破棄を命じる場合に移行元のドメイン内の認証情報の破棄プロセスが、そのような破棄が許されるというポリシーの検査中に行われるべきであるという肯定応答が交換されてもよい。14において、TDROD970が、TDROS960上の認証情報が破棄されるべきであることを指示し得るマイグレーション確認メッセージをTDROS960に送信する。式14は、マイグレーションが行われ、移行先のデバイスが新しくマイグレーションされた認証情報に従って再構成されたという移行先のドメインから移行元への肯定応答を示す。古い認証情報移行元のドメインの認証情報を破棄する要求が含まれる。前のRTOプロセス中に、ネゴシエーションが行われた場合があり、移行元のデバイスの所有者の代理としての移行元のデバイスのSDMとROとが、移行元のドメイン上の認証情報の任意のマイグレーション後の破棄または引き続きの記憶について相互に合意したことが仮定されてもよい。認証情報の転送の後、移行元のSDMによる認証情報の破棄に関するシステム全体のポリシーの検査が、必要とされる場合がある。15において、認証情報の破棄に関連するポリシーの検査を実行するために、TDROS960からSDMS/TDUS/TDOS950移行元のSDMにメッセージが送信されてもよい。15aにおいて、ポリシーの検査が、実行されてもよい。式15は、そのような検査を実行するための、SDMSへの移行元のドメインによる要求を指示するメッセージを示す。16において、SDMS/TDUS/TDOS950移行元のユーザ/所有者ドメインが、SDMD/TDUD/TDOD980移行先のユーザ/所有者ドメインにユーザデータを送信することができる。式16において、ユーザ登録データが、移行元から移行先のドメインに転送される。REGDATAは、マイグレーションされた認証情報に関連する加入者情報を含むユーザプロファイルを表す。最小限の加入者プロファイルが、移行先のドメインへのアクセスおよびプロトコルの開始のために移行先のデバイスへのユーザのログインを可能にするために使用されてもよい。17において、SDMS/TDUS/TDOS950移行元のユーザ/所有者ドメインが、マイグレーションが完了していること、およびマイグレーションされた認証情報が、移行元で例えば、TDROS960で破棄されたかどうかを指示するメッセージをRO990に送信することができる。式17は、認証情報の破棄がシステムのポリシーに違反しないと仮定して、ROに認証情報の破棄を確認する。認証情報の破棄が移行元のシステムのポリシーによって許されない場合、想定できる解決メカニズムは、同じ認証情報が別々のデバイス上に共存することができるかどうかをROが判定することを要求する場合がある。18において、移行元のドメインが、ユーザ/所有者に、マイグレーションが完了していること、および認証情報の破棄が移行元のデバイス上で実行されたことを知らせることができる。移行元の認証情報が破棄された場合、ユーザは、ユーザが移行元のデバイスで加入したサービスにもはやアクセスできない。それらのサービスの使用は、今や、新しいプラットフォームに移された。事前にプロビジョニングされた鍵KtempI例えば、1参照が、メッセージに署名するために使用されてもよい例えば、端末/THSMのリンクを介した通信は、機密性のためのKtempCならびに完全性および認証のためのKtempIの使用を必要とする場合がある。19において、TDROD970が、そのTDROD970が認証情報を受信し、構成が実行されたことを指示するメッセージをRO990に送信することができる。式19は、ROに、移行先のドメインがマイグレーションされた認証情報に従って再構成されたことを知らせる。ユーザは、今や、移行先のデバイスでサービス、例えば、移行元のデバイスで前に利用可能であったサービスにアクセスすることができる。20において、TDROD970が認証情報を受信し、構成を実行したことを指示するメッセージが、TDROD970からユーザ/所有者940に送信される。マイグレーションが完了しているという肯定応答が、両方のデバイスによって提供されてもよい。通知されるエンティティは、ユーザ/所有者およびROを含んでもよい。ユーザが認証情報の転送を通知される式18と同様に、式20は、ユーザに、移行先のデバイスの再構成が完了していることの情報を与える。これは、ユーザが加入していたサービスが今や移行先のプラットフォームでアクセス可能であることのユーザへの警告を表すことができる。式18と同様に、署名鍵はKtempIであり、ここで、この鍵は、移行先のデバイスに関連付けられる。事前にプロビジョニングされた鍵の組KtempCおよびKtempIが、移行元のデバイスと移行先のデバイスの間で別であり異なると仮定されてもよい。図9Bは、図9Aと似ているTSIMのドメインのマイグレーションに関するコールフロー図である。しかし、9乃至12に示されるように、図9Bは、移行元の完全性の検証が、移行先のデバイスのSDMによって実行されることができ、移行先のドメインの完全性の検証が、移行元のデバイスのSDMによって実行されることができる場合を示す。9において、移行元からの完全性検証情報を要求するメッセージが、TDROD970からTDROS960に送信されてもよい。9aにおいて、要求が、TDROS960からSDMS/TDUS/TDOS950移行元のSDMに渡されてもよい。9bにおいて、SDMS/TDUS/TDOS950移行元のSDMが、完全性検証情報を取得する。10において、完全性検証情報が、SDMS/TDUS/TDOS950移行元のSDMからTDROS960に送信されてもよい。10aにおいて、移行元の完全性検証情報が、TDROS960からTDROD970に送信されてもよい。11において、移行元の完全性検証情報が、TDROD970からSDMD/TDUD/TDOD980移行先のSDMに送信されてもよい。メッセージ10aおよび11において、TDROSを発端とする移行先の完全性検証情報の要求が、TDRODに、次いで、SDMSDMD/TDUD/TDOD980に送信されてもよい。11aにおいて、SDMD/TDUD/TDOD980移行先のSDMが、移行元の完全性検証情報を検査し、移行先の完全性検証情報を準備する。11bにおいて、移行元の完全性検証情報の検査に基づいてマイグレーションを続行すべきか、または終了すべきかを指示し、移行先の完全性検証情報を転送するメッセージが、SDMD/TDUD/TDOD980移行先のSDMからTDROD970に送信される。フロー12乃至12Cは、移行元と移行先の役割を逆にした同様のフローを表す。図9Cは、1またはそれ以上の開示された実施形態が実装され得る例示的な通信システム900の図である。通信システム900は、複数の無線ユーザに音声、データ、ビデオ、メッセージング、放送などのコンテンツを提供する多元接続システムである場合がある。通信システム900は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有によってそのようなコンテンツにアクセスすることを可能にする。例えば、通信システム900は、符号分割多元接続CDMA、時分割多元接続TDMA、周波数分割多元接続FDMA、直交FDMAOFDMA、シングルキャリアFDMASC-FDMAなどの1またはそれ以上のチャネルアクセス方法を使用することができる。図9Cに示されるように、通信システム900は、WTRU無線送受信ユニット902a、902b、902c、および902d、RAN無線アクセスネットワーク904、コアネットワーク906、PSTN公衆交換電話網908、インターネット910、およびその他のネットワーク912を含んでもよいが、開示された実施形態は、任意の数のWTRU、基地局、ネットワーク、および/または中継ノード、ゲートウェイ、フェムトセル基地局、セットトップボックスなどを含んでもよいが、これらに限定されないネットワーク要素を考慮することが理解されるであろう。WTRU902a、902b、902c、および902dのそれぞれは、無線環境内で動作および/または通信するように構成された任意の種類のデバイスであってもよい。例として、WTRU902a、902b、902c、および902dは、無線信号を伝送および/または受信するように構成されてもよく、UEユーザ機器、移動局、固定または移動加入者ユニット、ポケットベル、セルラ電話、PDA携帯情報端末、スマートフォン、ラップトップ、ネットブック、タブレット、パーソナルコンピュータ、無線センサー、および家庭用電化製品などを含んでもよい。通信システム900は、基地局914aおよび基地局914bも含んでもよい。基地局914a、914bのそれぞれは、コアネットワーク906、インターネット910、および/またはネットワーク912などの1またはそれ以上の通信ネットワークへのアクセスを容易にするために、WTRU902a、902b、902c、および902dのうちの少なくとも1つと無線でインターフェースをとるように構成された任意の種類のデバイスであってもよい。例として、基地局914a、914bは、BTSベーストランシーバ基地局、NodeB、eNodeB、ホームNodeBHome-NodeB、ホームeNodeBHome-eNodeB、サイトコントローラ、APアクセスポイント、無線ルータ、無線に対応したセットトップボックス、無線に対応したホームゲートウェイ、中継ノードなどであってもよい。基地局914a、914bはそれぞれ単一の要素として示されているが、基地局914a、914bは、任意の数の相互に接続された基地局および/またはネットワーク要素を含んでもよいことが理解されるであろう。基地局914aは、RAN904の一部であってもよく、RAN904は、その他の基地局、および/またはBSC基地局制御装置、RNC無線ネットワーク制御装置、中継ノードなどのネットワーク要素図示せずも含んでもよい。基地局914aおよび/または基地局914bは、セルと呼ばれ得る特定の地理的領域図示せず内で無線信号を伝送および/または受信するように構成されてもよい。セルは、セルのセクタにさらに分割されてもよい。例えば、基地局914aに関連するセルは、3つのセクタに分割されてもよい。したがって、一実施形態において、基地局914aは、3つのトランシーバ、すなわち、セルの各セクタに対して1つのトランシーバを含んでもよい。別の実施形態において、基地局914aは、MIMOmultipleinputmultipleoutput技術を採用してもよく、したがって、セルの各セクタに対して複数のトランシーバを利用してもよい。基地局914a、914bは、任意の適切な無線通信リンク例えば、RF無線周波数、マイクロ波、IR赤外線、UV紫外線、可視光などであり得る無線インターフェース916を介してWTRU902a、902b、902c、および902dのうちの1つまたはそれ以上と通信してもよい。無線インターフェース916は、任意の適切なRAT無線アクセス技術を用いて確立されてもよい。より具体的には、上述のように、通信システム900は、多元接続システムであってもよく、CDMA、TDMA、FDMA、OFDMA、SC-FDMAなどの1またはそれ以上のチャネルアクセススキームを使用してもよい。例えば、RAN904内の基地局914a、およびWTRU902a、902b、902cは、WCDMA広帯域CDMAを使用して無線インターフェース916を確立することができるUMTSUNIVERSALMobileTelecommunicationsSystemUTRATerrestrialRadioAccessなどの無線技術を実装してもよい。WCDMAは、HSPAHighSpeedPacketAccessおよび/またはHSPAEvolvedHSPAなどの通信プロトコルを含んでもよい。HSPAは、HSDPAHighSpeedDownlinkPacketAccessおよび/またはHSUPAHighSpeedUplinkPacketAccessを含んでもよい。別の実施形態において、基地局914aおよびWTRU902a、902b、902cは、LTELongTermEvolutionおよび/またはLTE-ALTEAdvancedを使用して無線インターフェース916を確立することができるE-UTRAEvolvedUMTSTerrestrialRadioAccessなどの無線技術を実装してもよい。その他の実施形態において、基地局914aおよびWTRU902a、902b、902cは、IEEE802.16すなわち、WiMAXWorldwideInteroperabilityforMicrowaveAccess、CDMA2000、CDMA2000-1X、CDMA2000EV-DO、IS-2000InterimStandard2000、IS-95InterimStandard95、IS-856InterimStandard856、GSM登録商標GlobalSystemforMobilecommunications、EDGEEnhancedDataratesforGSMEvolution、GERANGSMEDGEなどの無線技術を実装してもよい。図9Cの基地局914bは、例えば、無線ルータ、ホームNodeB、ホームeNodeB、またはアクセスポイントであってもよく、事業所、家庭、車両、キャンパスなどの局所的な地域で無線接続を容易にするための任意の好適なRATを利用してもよい。一実施形態において、基地局914bおよびWTRU902cおよび902dは、WLAN無線ローカルエリアネットワークを確立するためのIEEE802.11などの無線技術を実装してもよい。別の実施形態において、基地局914bおよびWTRU902cおよび902dは、WPAN無線パーソナルエリアネットワークを確立するためのIEEE802.15などの無線技術を実装してもよい。さらに別の実施形態において、基地局914b、ならびにWTRU902cおよび902dは、セルラに基づくRAT例えば、WCDMA、CDMA2000、GSM、LTE、およびLTE-Aなどを利用してピコセルまたはフェムトセルを確立してもよい。図9Cに示されたように、基地局914bは、インターネット910への直接的なコネクションを有してもよい。したがって、基地局914bは、コアネットワーク906を介してインターネット910にアクセスする必要がない。RAN904は、コアネットワーク906と通信してもよく、コアネットワーク906は、WTRU902a、902b、902c、および902dのうちの1つまたはそれ以上に音声、データ、アプリケーション、および/またはVoIPvoiceoverinternetprotocolサービスを提供するように構成された任意の種類のネットワークであってもよい。例えば、コアネットワーク906は、呼制御、課金サービス、モバイルの位置に基づくサービス、プリペイド電話、インターネット接続、映像配信などを提供し、および/またはユーザ認証などの高レベルのセキュリティ機能を実行してもよい。図9Cには示されていないが、RAN904および/またはコアネットワーク906は、RAN904と同じRAT、または異なるRATを使用するその他のRANと直接的または間接的に通信してもよいことが理解されるであろう。例えば、E-UTRA無線技術を利用し得るRAN904に接続されることに加えて、コアネットワーク906は、GSM無線技術を使用する別のRAN図示せずとも通信してもよい。コアネットワーク906は、WTRU902a、902b、902c、および902dがPSTN908、インターネット910、および/またはその他のネットワーク912にアクセスするためのゲートウェイとしての機能を果たしてもよい。PSTN908は、POTSplainoldtelephoneserviceを提供する回線交換電話ネットワークを含んでもよい。インターネット910は、TCP/IPインターネットプロトコル群のTCPtransmissioncontrolprotocol、UDPuserdatagramprotocol、およびIPinternetprotocolなどの共通の通信プロトコルを使用する相互に接続されたコンピュータネットワークおよびデバイスの全世界的なシステムを含んでもよい。ネットワーク912は、その他のサービスプロバイダによって所有および/または運用される有線または無線通信ネットワークを含んでもよい。例えば、ネットワーク912は、RAN904と同じRAT、または異なるRATを使用し得る1またはそれ以上のRANに接続された別のコアネットワークを含んでもよい。通信システム900のWTRU902a、902b、902c、および902dの一部またはすべては、マルチモード機能を含んでもよく、すなわち、WTRU902a、902b、902c、および902dは、異なる無線リンクを介して異なる無線ネットワークと通信するための複数のトランシーバを含んでもよい。例えば、図9Cに示されたWTRU902cは、セルラに基づく無線技術を使用することができる基地局914aと、およびIEEE802無線技術を使用することができる基地局914bと通信するように構成されてもよい。"