JP2014222522A - 加入方式のサービスにアクセスするための登録および資格証明ロールアウト - Google Patents

Abstract

【課題】デバイス上のドメインのリモート所有者からの加入方式のサービスにユーザーがアクセスすることを可能にすること。
【解決手段】ユーザーは、１つまたは複数の別々のドメインがあり、それぞれのドメインが１つまたは複数の異なるローカルもしくはリモート所有者によって所有もしくは制御されうる、１つまたは複数のデバイスを備えるシステムを介して加入方式のサービスにアクセスできる。それぞれのドメインには、異なる所有者があってもよく、加入方式のサービスを提供するリモート所有者は、リモート所有者ドメインと称しうる、ドメインの所有権を獲得しているものとしてよい。さらに、ユーザーは、ユーザードメインとも称しうる、ドメインの所有権を獲得しているものとしてよい。例示的な登録および資格証明ロールアウトのプロセスは、ユーザーの登録、リモート所有者からの資格証明の取得、および資格証明の格納を含みうる。
【選択図】図８

Description

（関連出願の相互参照）
本出願は、参照によりその全体が本明細書に組み込まれる、２００９年１０月１５日に出願した米国仮特許出願第６１／２５１，９２０号に基づくものであり、その優先権を主張するものである。

本発明は、加入方式のサービスにアクセスするための技術に関する。

今日、他のデバイスまたはエンティティと通信することができる、または通信することができないコンピューティングデバイスが、デバイス、またはデバイス内のある部分もしくはコンピューティング環境が個人、組織、または他の何らかのエンティティによって「所有」される形で使用される状況が多々ある。「所有される」は、デバイス、またはそのデバイス内のある部分もしくはコンピューティング環境が、エンティティ内で認証されている可能性があり、またエンティティがそれ以降デバイスまたはそのデバイスの一部に対し何らかの形の制御を行っている可能性があるということを意味する。このような状況の一例は、ワイヤレスモバイル通信業界であり、携帯電話などのワイヤレスデバイスのユーザーが特定のモバイル通信ネットワーク事業者（ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｎｅｔｗｏｒｋ ｏｐｅｒａｔｏｒ）のサービスに加入することができる。

今日のモバイル通信業界では、ユーザーが特定の通信ネットワーク事業者のサービスに加入するために使用するワイヤレスデバイスとして、典型的には、ＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ：加入者識別モジュール）またはＵＩＣＣ（Ｕｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ：ユニバーサル集積回路カード）が挙げられる。ＳＩＭ／ＵＩＣＣは、認証アルゴリズムを実行し、デバイスユーザーの通信ネットワーク事業者との加入契約を通信ネットワーク事業者に対してデバイス側で認証することを可能にする資格証明を格納し、通信ネットワーク事業者がワイヤレスデバイスに対してある形式の制御権、つまり、所有権を持つことを可能にする安全な実行および格納環境をワイヤレスデバイスに提供するものである。しかし残念なことに、ＳＩＭ／ＵＩＣＣのメカニズムは、典型的には、単一の通信ネットワーク事業者との使用に限定される。

したがって、今日の多くのコンピューティング利用状況における問題は、モバイル通信デバイスについての上述の状況と同様に、コンピューティングデバイスが、多くの場合、単一のエンティティによって丸ごと「所有される」ことに制限されることにある。また、多くの場合に、その所有権はユーザーによるデバイスの購入時点に確立され、後から所有権を確立することが望ましいこともあるビジネスモデルを妨げる。さらに、これらの制限は、デバイスの多くの相互に分離されている部分の複数の所有権が存在すること、または所有権が時に応じて他のエンティティに移行されることが望ましいと思われる状況におけるデバイスの使用を妨げる。例えば、携帯電話などのワイヤレスモバイル通信デバイスの場合、ユーザーは、典型的には、購入時に特定の移動体通信事業者のサービスに加入する必要があり、そのようなデバイスは、ワイヤレスデバイスを購入してからある程度時間が経ってからでないと移動体通信事業者が判明しない可能性のあるアプリケーションでは使用されることが妨げられる。また、典型的には、そのようなデバイスが一度に複数の通信事業者のネットワークにアクセスすることは可能でない。モバイルネットワークおよびサービス加入の更新または変更は困難であるといってよく、無線による更新または変更は、通常、可能でない。

また、特にワイヤレスモバイル通信デバイスが背景にある場合、ＳＩＭ／ＵＩＣＣのメカニズムは非常に安全であると一般的に考えられるけれども、セキュリティはそのメカニズムが置かれているデバイス全体のセキュリティ特性に強く結び付けられているわけではない。これは、モバイル金融取引などの高度なサービスおよびアプリケーションに対するスケーリングセキュリティコンセプト（ｓｃａｌｉｎｇ ｓｅｃｕｒｉｔｙ ｃｏｎｃｅｐｔｓ）の適用を制限する。特に、こうした欠点は、マシン間（Ｍ２Ｍ）通信デバイスなどの、自律デバイスに関わるものである。

そこで、より動的な解決策があることが望ましい。

国際公開第２００９／０９２１１５号パンフレット（ＰＣＴ／ＵＳ２００９／０３１６０３）

デバイス上のドメインのリモート所有者からの加入方式のサービスにユーザーがアクセスすることを可能にするシステムおよび方法が開示される。ユーザーは、１つまたは複数の別々のドメインがあり、それぞれのドメインが１つまたは複数の異なるローカルもしくはリモート所有者によって所有もしくは制御されうる、１つまたは複数のデバイスを備えるシステムを介して加入方式のサービスにアクセスすることができる。１つまたは複数のデバイスは、少なくとも１つのプラットフォームによってサポートされる１つまたは複数のドメインを備えることができる。それぞれのプラットフォームは、それらのドメイン用に低水準のコンピューティング、ストレージ、または通信リソースを提供することができる。プラットフォームは、いくつかのハードウェア、１つのオペレーティングシステム、いくつかの低水準ファームウェアもしくはソフトウェア（ブートコード、ＢＩＯＳ、ＡＰＩ、ドライバ、ミドルウェア、もしくは仮想化ソフトウェアなど）、およびいくつかの高水準ファームウェアもしくはソフトウェア（アプリケーションソフトウェアなど）、およびそのようなリソースに対する各構成データからなるものとしてよい。それぞれのドメインは、少なくとも１つのプラットフォーム上で実行されるコンピューティング、ストレージ、または通信リソースの一構成を備えることができ、それぞれのドメインは、そのドメインのローカルまたはリモートに配置されうるドメインの所有者に対する機能を実行するように構成することができる。それぞれのドメインには、異なる所有者があってもよく、それぞれの所有者は、そのドメインのオペレーションに対するポリシーだけでなくドメインが置かれるプラットフォームおよび他のドメインに関するそのドメインのオペレーションに対するポリシーを指定することができる。加入方式のサービスを提供するリモート所有者は、リモート所有者ドメインと称することもできる、ドメインの所有権を獲得しているものとしてよい。さらに、ユーザーは、ユーザードメインとも称することができる、ドメインの所有権を獲得しているものとしてよい。

ユーザーが加入方式のサービスにアクセスするために、登録および資格証明ロールアウトが必要になる場合がある。例示的な登録および資格証明ロールアウトのプロセスは、ユーザーの登録、リモート所有者からの資格証明の取得、および資格証明の格納を含むことができる。

登録は、リモート所有者ドメインを通じてリモート所有者によって提供される加入方式のサービスの加入ユーザーとしてユーザーをリモート所有者に登録することを含むことができる。ユーザードメインは、リモート所有者ドメインに要求を送信することによってユーザーに代わって登録を開始することができる。リモート所有者ドメインは、ユーザーを加入方式のサービスの加入ユーザーとしてリモート所有者に対して識別するために使用すべき識別子を要求することができる。この要求は、加入方式のサービスのユーザーへの販売を円滑にする第三者に対して出すことができる。リモート所有者ドメインは、第三者から識別子を受信し、ユーザードメインでは、登録の要求を受信したという確認応答をリモート所有者から受信することができる。

資格証明を取得し、格納することは、ユーザードメインが資格証明ロールアウト要求をリモート所有者ドメインに送信することを含むものとしてよい。この要求は、ユーザーおよび／または第三者を識別する情報を含むものとしてよい。リモート所有者ドメインは、資格証明ロールアウト要求をリモート所有者に送信することができる。リモート所有者ドメインは、リモート所有者から資格証明を受信し、資格証明がリモート所有者ドメインによって受信されたという確認応答をユーザードメインに送信することができる。

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

本明細書で説明される方法および手段を使用することができる例示的なシステムを示す図である。 本明細書で説明される方法および手段がユーザー装置（ＵＥ）内に具現化されるシステムの一実施形態を例示する図である。 ドメインの所有権を取得するための例示的なブートアップおよびプロセスを例示する図である。 ドメインの所有権を取得するための例示的なブートアップおよびプロセスを例示する図である。 ドメインの所有権を取得するためのプロセスの例示的な呼流れ図である。 ドメインの所有権を取得するためのプロセスの例示的な呼流れ図である。 完全なアテステーション（ａｔｔｅｓｔａｔｉｏｎ）付きのドメインの所有権を取得するためのプロセスの例示的な呼流れ図である。 完全なアテステーション付きのドメインの所有権を取得するためのプロセスの例示的な呼流れ図である。 信頼できるハードウェア加入モジュール（ｔｒｕｓｔｅｄ ｈａｒｄｗａｒｅ ｓｕｂｓｃｒｉｐｔｉｏｎ ｍｏｄｕｌｅ）の一実施形態の例示的な状態定義、遷移、および制御点定義を示す図である。 リモート所有者ドメインが達成しうる例示的な状態および動的に管理された環境において遷移が発生しうる条件を示す図である。 登録および資格証明ロールアウトのプロセスを実装する例示的な呼流れ図である。 １つまたは複数の開示されている実施形態が実装されうる例示的な通信システムのシステム図である。

Ｉ．マルチドメインシステムの例
図１〜７は、開示されているシステム、方法、および手段が実装されうる例示的な実施形態に関係するものとしてよい。しかし、本発明は、例示的な実施形態に関連して説明することができるが、それに限定されることはなく、他の実施形態を使用することができるか、または本発明から逸脱することなく本発明の同じ機能を実行するように説明されている実施形態に修正および追加を施すことができることは理解されるであろう。

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

それぞれのドメインは、コンピューティング、ストレージ、もしくは通信リソース（入力の観点から）またはそのようなコンピューティング、ストレージ、または通信リソース（出力の観点から）を使用することによってドメインが提供する機能に関して、他のドメインから分離することができる。それぞれのドメインは、共通の基盤プラットフォームのコンピューティング、ストレージ、または通信リソースもしくは機能を利用することができる。共通プラットフォームによって提供されるそのような機能のうちのいくつかを共有することができるドメインもある。プラットフォームリソースおよび／または機能のそのような共有は、それぞれのドメインによる共通リソースもしくは機能の利用を別のドメインによるそのような利用から分離できる形で行うことができる。例えば、そのような分離は、デバイスのプラットフォーム側で厳格なアクセス制御を、ドメインのリソースへのアクセスがプラットフォームおよび／またはドメインの所有者によって許可されたドメインの外部のユーザー（複数可）、所有者（複数可）、または他のエンティティもしくはプロセスにのみ許されるようにドメインのそれぞれにプラットフォームが提供するリソースに強制することによって達成されうる。プラットフォームは、ドメインの機能のどれもがデバイス上のドメインのどれかの外側にあるデバイスのリソースに依存する限りにおいて、デバイス上の分離されたドメインのどれかの一部ではないデバイスの部分から単純に構成されるものであってもよい。

同じもしくは異なるプラットフォーム上の、または同じもしくは異なるデバイス上の、２つのドメイン間の通信は、安全な通信にすることができる、つまり、ドメインは互いに安全な方法で認証すること（例えば、暗号化手段を使用することによって）、また機密性（ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ）、完全性（ｉｎｔｅｇｒｉｔｙ）、および新鮮さ（ｆｒｅｓｈｎｅｓｓ）などのセキュリティの態様についてそれらの間で交換されるメッセージを保護することもできるということである。ドメインが置かれているプラットフォーム（複数可）が備える暗号化手段を使用して、そのような２つのドメイン間のそのような安全な通信を行うことができる。

システム全体のドメインマネージャを、いくつかのドメインのうちの１つに置くことができる。システム全体のドメインマネージャは、それが置かれているドメインのポリシーを強制することができ、またシステム全体のドメインマネージャが置かれているドメインに関するそれらの各ポリシーによる他のドメインの強制を調整することができる。それに加えて、システム全体のドメインマネージャは、各ポリシーに従って他のドメイン間の相互のやり取りを調整することができる。システム全体のドメインマネージャが置かれているドメインは、そのドメインを収容するデバイスの所有者によって所有されうる。あるいは、そのようなドメインは、そのドメインを収容するデバイスを所有しえない所有者によって所有されうる。

図１は、このようなシステムの一実施形態を例示している。図示されているように、システムは、１つまたは複数のデバイス１００、１１０、および１２０を備えることができる。それぞれのデバイスは、少なくとも１つのプラットフォームによってサポートされる１つまたは複数のドメインを備えることができる。例えば、デバイス１００は、１つのドメイン１０６および１つまたは複数の他のドメイン１０１、１０２を備えることができる。３つのドメインはデバイス１００に関して例示されているが、他の実施形態では、ドメインの個数は増減できる。これらのドメイン１０１、１０２、１０６のそれぞれは、デバイスの少なくとも１つのプラットフォーム１０５上で実行されるコンピューティング、ストレージ、または通信リソースの一構成を備えることができる。それぞれのドメインは、そのドメインのローカルまたはリモートに配置されうるドメインの所有者に対する機能を実行するように構成することができる。例えば、ドメイン１０６は、デバイス所有者（図示せず）によって所有されうるが、ドメイン１０１、１０２は、１つまたは複数のリモート所有者によって所有されうる。それぞれのドメインには、異なる所有者があってもよく、または、デバイスの複数のドメインが、同じ所有者によって所有されうる。それぞれの所有者は、そのドメインのオペレーションに対するポリシーだけでなくドメインが動作するプラットフォーム、ドメインが置かれているデバイス、および同じもしくは異なるデバイス内の他のドメインに関するそのドメインのオペレーションに対するポリシーを指定することができる。

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

システム全体のドメインマネージャ（ＳＤＭ：Ｓｙｓｔｅｍ−Ｗｉｄｅ Ｄｏｍａｉｎ Ｍａｎａｇｅｒ）１０７を、いくつかのドメインのうちの１つに置くことができる。この例では、ＳＤＭ １０７は、デバイス１００のドメイン１０６上に置かれる。一実施形態では、ＳＤＭが置かれるドメイン（例えば、ドメイン１０６）は、デバイス１００の所有者によって所有される。ＳＤＭ １０７は、デバイス１００内に備えられている通信メカニズムを介してデバイス１００上のリモート所有者ドメイン１０１と通信する。それに加えて、ＳＤＭ １０７は、有線もしくは無線チャネルとすることができる各通信チャネル１３１、１３２、１４１、１４２を介して他のデバイス上のドメインと通信する。通信チャネル１３１、１３２、１４１、および１４２は、安全であるものとしてよい。ＳＤＭ １０７は、それが置かれているドメイン１０６のポリシーを強制することができ、またドメイン１０６に関するそれらの各ポリシーによる他のドメイン１０１、１１１、１１２、１２１、１２２の強制を調整することができる。それに加えて、ＳＤＭ １０７は、他のドメイン間の相互のやり取りを、それらの各ポリシーさらにはＳＤＭが置かれているドメインのポリシー（その特定のドメインの所有者のポリシーとなる）に従って調整することができる。

一例として、一実施形態では、ドメインは、サービスプロバイダによって所有されうる。例えば、デバイス１００のドメイン１０２は、例にすぎないが移動体通信事業者などのサービスプロバイダによって所有されうる。ドメイン１０２は、デバイス１００を認証するＳＩＭ（加入者識別モジュール）機能、または場合によってはそれと同等である、デバイスの所有者もしくはユーザーの加入を、サービスプロバイダに対して実行し、デバイス１００とサービスプロバイダとの間の通信を使用可能にすることができる。

上述のＳＤＭの機能に加えて、ＳＤＭ １０７は、情報にアクセスし、前述の１つまたは複数のドメインによる使用に利用可能なリソースのリストを提供する機能も持つことができる。ＳＤＭ １０７は、リモート所有者によって所有されるドメインのロードおよびメンテナンスも監視することができる。ＳＤＭ １０７は、これが置かれているデバイス１００のユーザーに、これがロードすることができるドメインのリストを提供し、リストにあるドメインのうちどれをロードすべきかを選択するようユーザーに求めることができる。ＳＤＭは、プラットフォームまたはデバイス上に、ロードするのに十分なコンピューティングリソースがあるかどうかも評価し、したがって、１つまたは複数のドメインのオペレーションをサポートすることができる。

また上述のように、ＳＤＭ １０７は、本明細書ではシステム全体のドメインポリシー（ＳＤＰ：Ｓｙｓｔｅｍ−Ｗｉｄｅ Ｄｏｍａｉｎ Ｐｏｌｉｃｙ）とも称されうるそのポリシー（複数可）だけでなく他のドメインのポリシー（複数可）、つまりドメイン固有のポリシー（ＤＰｓ：ｄｏｍａｉｎ−ｓｐｅｃｉｆｉｃ ｐｏｌｉｃｉｅｓ）を強制することに加わることもできる。ＳＤＭ １０７では、新規ドメインをロードするかどうかを評価する際に１つまたは複数の既存のドメインのポリシーを考慮することができる。例えば、リモート所有者によって所有される所定のドメインのポリシーは、特定の種類の他のドメインがアクティブになったときに所定のドメインが非アクティブにされることを指定することができる。別の例では、リモート所有者によって所有される所定のドメインのポリシーは、特定の他のドメインによって所有される別のドメインがアクティブになったときに所定のドメインが非アクティブにされることを指定することができる。さらに別の例では、リモート所有者によって所有される所定のドメインのポリシーは、特定の種類の他のドメインがアクティブになったときに所定のドメインのオペレーションがある種の特定の様式（複数可）に制限されることを指定することができる。さらに別の例では、リモート所有者によって所有される所定のドメインのポリシーは、特定の他のリモート所有者によって所有される別のドメインがアクティブになったときに所定のドメインのオペレーションがある種の特定の様式（複数可）に制限されることを指定することができる。ＳＤＭ １０７は、これらの種類のポリシーのすべての強制を受け持つことができる。

ＳＤＭ １０７は、リモート所有者が後で所有権を取得できるドメインの確立またはロードを行うこともできる。例えば、このようなドメインは、本明細書において「手つかずの（ｐｒｉｓｔｉｎｅ）」状態と称される状態において確立することができ、この状態では所有者によって所有されず、またＳＤＭ １０７は、リモート所有者によるドメインの所有権の確立を管理することができる。

そのために、ＳＤＭ １０７は、リモート所有者がドメインの所有権を確立するかどうかを判定する際に考慮することができる情報をリモート所有者に送信することができる。この情報は、（ｉ）所有権の探索先となるドメインの完全性のアテステーションを示す情報、および（ｉｉ）システムの少なくとも１つの他のドメインの完全性のアテステーションを示す情報のうちの少なくとも一方を含むことができる。この情報は、（ｉ）所有権の探索先となるドメインが動作する際のリソースを使用するプラットフォームの完全性のアテステーションを示す情報、および（ｉｉ）システムの少なくとも１つの他のドメインが動作する際のリソースを使用するプラットフォームの完全性のアテステーションを示す情報のうちの少なくとも一方を含むことができる。それに加えて、この情報は、デバイスの現在の環境に関する情報を含むことができる。このような情報は、（ｉ）システム内の多数の他のドメインを示す値、（ｉｉ）システム内の他のドメインの性質の要約を提示する情報、および（ｉｉｉ）所有権の確立が試みられているドメインによる使用に利用可能なプラットフォームのリソースを指定する情報のうちの少なくとも１つを含むことができる。システムの他のドメインに関する情報をリモート所有者に提供する程度は、機密性および／または分離に関するこれらの他のドメインの各ポリシーを条件とするものとしてよい。

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

本明細書で開示されるシステムは、１つまたは複数のドメインの分離およびセキュリティも規定することができる。例えば、これらのドメインのうちの１つまたは複数は、他のドメインから分離された安全な実行およびストレージ環境を備えることができる。そのような安全な環境を確保するために、図１のデバイス１００のプラットフォーム１０５などの、１つまたは複数のドメインが確立されるデバイスのプラットフォームは、信頼のルート１０３を備えることができる。信頼のルート１０３は、ハードウェアリソースの不変、不動のセットを備えることができ、その完全性は事前確立され、ドメインのリモート所有者を含む、他者に依存しうる。ドメイン１０１などのドメインの完全性は、信頼のルート１０３によって固定された信頼の連鎖によって確立されうる。例えば、ドメイン１０１の完全性は、ドメイン１０１の少なくとも１つのコンポーネントの、信頼のルート１０３によって生成されうる測定結果を、信頼のルート１０３に格納され、ドメインの完全性を検証するために信頼のルートによって使用されうる参照完全性基準（ｒｅｆｅｒｅｎｃｅ ｉｎｔｅｇｒｉｔｙ ｍｅｔｒｉｃ）と比較することによって確立することができる。あるいは、リモート所有者側で参照完全性基準を格納し、測定結果を、参照完全性基準との比較のためにリモート所有者に送信することができる。ドメインの完全性は、測定結果が参照完全性基準と一致する場合に検証されうる。例示的な一実施形態では、測定結果は、コンポーネント上で計算されたハッシュを含み、参照完全性基準は、コンポーネント上ですでに計算されており、参照完全性基準の真正性を示す情報を提供するデジタル証明書が添付されたハッシュを含みうる。参照完全性基準は、製造の時点において、またはデバイスをその所有者に引き渡す時点において、デバイスに事前に組み込むことができる。参照完全性基準は、デバイスを製造し／その所有者に納入した後に通信チャネル（例えば、無線ワイヤレス通信チャネル）を介してリモートソースから配送され、引き渡し後にデバイス内に組み込むことができる。参照完全性基準は、証明書に同封されたデバイスに配送することができる。このような証明書は、デバイスへの配送後に使用のため信頼できる第三者によって検証することができる。

本明細書で開示されるシステム、ならびにそのさまざまな方法および手段は、広範にわたるコンピューティングおよび通信の背景状況において具現化されうる。そこで、図１の例示的なデバイス１００、１１０、および１２０などのシステムのデバイスは、さまざまな形態をとりうる。例えば、何ら限定されるものではないが、システムのデバイスは、ワイヤレス送信／受信ユニット（ＷＴＲＵ）、ユーザー装置（ＵＥ）、移動局、固定または移動式加入者装置、ポケベル、携帯電話、携帯情報端末（ＰＤＡ）、コンピュータ、マシン間（Ｍ２）デバイス、ＳＩＭカード、ユニバーサル集積回路カード（ＵＩＣＣ）、スマートカード、ジオトラッキング（ｇｅｏ−ｔｒａｃｋｉｎｇ）デバイス、センサー／ネットワーク間ノード、計量デバイス（水道、ガス、電気のメーターなど）、またはワイヤレスもしくは有線環境において動作することが可能である他の種類のコンピューティングもしくは通信デバイスを備えることができる。下記の図および説明では、ワイヤレス送信／受信ユニット（ＷＴＲＵ）における本開示のシステムおよび方法の多数の追加の例示的な実施形態を取り上げる。しかし、これらの実施形態は、単に例示的なものにすぎず、本明細書で開示されるシステムおよび方法は、決してこれらの実施形態に限定されないことは理解されるであろう。むしろ、上で説明されているように、本明細書で説明されるシステムおよび方法は、広範にわたるコンピューティングおよび通信環境において使用することができる。

図２は、本明細書で説明されるシステムおよび方法が具現化されうるＷＴＲＵの一実施形態を例示する図である。図示されているように、ＷＴＲＵは、ＵＥ ２００などの、モバイルデバイスを含むものとしてよい。ＵＥ ２００は、モバイル機器（ＭＥ）２１０および信頼できるハードウェア加入モジュール（ＴＨＳＭ：Ｔｒｕｓｔｅｄ Ｈａｒｄｗａｒｅ Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍｏｄｕｌｅ）２２０を備えることができる。それに加えて、ＴＨＳＭ ２２０は、ＴＨＳＭデバイス製造業者（ＤＭ：Ｄｅｖｉｃｅ Ｍａｎｕｆａｃｔｕｒｅｒ）ドメイン２２１、ＴＨＳＭデバイス所有者（ＤＯ：Ｄｅｖｉｃｅ Ｏｗｎｅｒ）ドメイン２２２、ＴＨＳＭデバイスユーザー（ＤＵまたはＵ：Ｄｅｖｉｃｅ Ｕｓｅｒ）ドメイン２２３、システム全体のドメインマネージャ（ＳＤＭ：Ｓｙｓｔｅｍ−Ｗｉｄｅ Ｄｏｍａｉｎ Ｍａｎａｇｅｒ）２３０、ドメイン間ポリシーマネージャ（Ｉｎｔｅｒ Ｄｏｍａｉｎ Ｐｏｌｉｃｙ Ｍａｎａｇｅｒ）２４０、ならびにＲＯ（Ｒｅｍｏｔｅ Ｏｗｎｅｒ）のドメインＡ ２２４、ＲＯのドメインＢ ２２５、およびＲＯのドメインＣ ２２６などの１つまたは複数のリモート所有者（ＲＯ）ドメインをさらに備えることができる。さらに、ＵＥ ２００は、例示されていないコンポーネント、つまり、プロセッサ、受信機、送信機、およびアンテナを備えることができる。本明細書で説明される例示的な実装は、図２に関して説明されているようなコンポーネントを指すものとしてよい。

ＴＨＳＭは、ＳＩＭ機能、ＵＳＩＭ機能、ＩＳＩＭ機能、およびアクセスネットワーク加入によって典型的に実行される機能を含む、信頼できる加入管理機能（ｔｒｕｓｔｅｄ ｓｕｂｓｃｒｉｐｔｉｏｎ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎｓ）を提供するハードウェアベースのモジュールであるものとしてよい。ＴＨＳＭは、ハードウェアで保護されたモジュールとすることができる。これは、関連するセキュリティ機能を備えるように特に設計されたハードウェアを含むことができる。これは、複数の分離されたドメインを内部的にサポートすることが可能であるものとしてよい。ドメインは、リモート所有者（ＲＯ：Ｒｅｍｏｔｅ Ｏｗｎｅｒ）と称される明確に区別される所有者によって請求または所有されうる。ＲＯによって請求されるドメインは、各ＲＯに対するプロキシとして動作しうる。

これらのドメインのうちの１つまたは複数は、信頼できる加入識別管理（ＴＳＩＭ：Ｔｒｕｓｔｅｄ Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｉｄｅｎｔｉｔｙ Ｍａｎａｇｅｍｅｎｔ）などの加入管理機能を実行することができる。ＴＳＩＭ機能を持つ複数のドメインが単一のＴＨＳＭ上に存在しうるため、ＴＨＳＭは、複数のＲＯに対して加入管理をサポートすることができる。ＴＳＩＭ対応ドメインの管理のいくつかの態様は、システム全体のドメインマネージャ（ＳＤＭ：Ｓｙｓｔｅｍ−Ｗｉｄｅ Ｄｏｍａｉｎ Ｍａｎａｇｅｒ）と称される単一の管理機能によって実行されうる。他の態様は、個別のドメイン内で、または個別のドメイン上で、個別に管理されうる。

ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）環境に関して説明されているが、当業者であれば、本明細書で説明される方法および装置は、本出願の範囲を超えることなく他の環境にも適用することが可能であることを理解できるであろう。ＴＳＩＭは、「加入アプリケーション（ｓｕｂｓｃｒｉｐｔｉｏｎ ａｐｐｌｉｃａｔｉｏｎ）」の代表例であるものとしてよい。例えば、３Ｇ ＵＭＴＳネットワークで動作するＷＴＲＵ上で実装された場合、ＴＳＩＭは、その機能の一部として、ＵＭＴＳの認証と鍵照合（ＡＫＡ）機能を含む、加入関係機能のすべてを含むことができる。ＴＳＩＭは、ＵＩＣＣなどの特定のハードウェアに束縛されない。これは、ＵＩＣＣ上にしか存在しえないＵＳＩＭとは対照的である。その代わりに、ＴＳＩＭは、本明細書で説明されているような信頼できるハードウェア加入モジュール（ＴＨＳＭ：Ｔｒｕｓｔｅｄ Ｈａｒｄｗａｒｅ Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍｏｄｕｌｅ）上に実装されうる。当業者であれば、本明細書で説明されているようなＴＨＳＭの機能は、本出願の範囲を超えることなく、欧州電気通信標準化機構（ＥＴＳＩ：Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ）のＵＩＣＣ要件に適合するＵＩＣＣまたはグローバルプラットフォーム（Ｇｌｏｂａｌ Ｐｌａｔｆｏｒｍ）仕様に適合するスマートカードなどの、ＵＩＣＣまたは類似のスマートカードに組み込むことができることも理解するであろう。

ＷＴＲＵは、ＴＨＳＭおよびモバイル機器（ＭＥ）を備えることができる。ＭＥは、モデム、ラジオ、電源、およびＷＴＲＵに典型的に見られる他のさまざまな特徴を備えることができる。ＴＨＳＭは、別のハードウェアベースのモジュールを含みうる。ＴＨＳＭは、ＷＴＲＵ上に埋め込まれるか、または独立したものとすることができる。ＴＨＳＭは、ＷＴＲＵ上に埋め込まれる場合であってもＭＥから論理的に分離されているものとしてよい。ＴＨＳＭは、１つまたは複数のドメインを備え、それぞれがドメインの特定の所有者によって所有され、安全な信頼できるサービスおよびアプリケーションを提供することを目的として所有者の利益ために運用されうる。したがって、例えば、ＤＭのドメインはＴＤ_DMと表され、ＤＯのドメインはＴＤ_DOとして表される。ＴＨＳＭにおけるドメインは、ＭＥにおいて実行するのに安全または都合がよいというわけではないセキュリティ上重要な機能およびアプリケーションを実行することができる。

いくつかのドメインは、１つまたは複数のサービスプロバイダによって所有され、管理されうる。例えば、移動体通信事業者（ＭＮＯ：ｍｏｂｉｌｅ ｎｅｔｗｏｒｋ ｏｐｅｒａｔｏｒｓ）、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）プロバイダ、またはＷｉＭａｘプロバイダなどの他の通信ネットワーク事業者、モバイル決済、モバイル発券、デジタル著作権管理（ＤＲＭ）、モバイルＴＶ、または位置情報サービスにおけるサービスプロバイダなどのアプリケーションサービスプロバイダ、またはＩＰマルチメディアコアネットワークサブシステム（ＩＭＳ：ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｃｏｒｅ Ｎｅｔｗｏｒｋ Ｓｕｂｓｙｓｔｅｍ）サービスプロバイダが挙げられる。加入管理は、サービスプロバイダによって所有されているドメインによってサポートされうる。簡単のため、ＴＨＳＭドメイン上に実装される加入管理機能は、これ以降、ＴＳＩＭ機能と表記される場合がある。ＴＳＩＭ機能のサポートは、ドメインによって異なっていてもよい。例えば、サポートされているＴＳＩＭ機能は、携帯端末のＵＩＣＣ上でＵＳＩＭおよびＩＳＩＭアプリケーションによって提供されるものと似た機能を含むことができる。ＴＨＳＭは、ＵＩＣＣのように、ＴＳＩＭによって提供されるものに加えて、機能、アプリケーション、およびデータを含むことができる。

ＴＳＩＭは、ソフトウェアユニットまたは仮想アプリケーションであってよい。ＴＳＩＭは、最初に、特定のネットワーク通信事業者または公衆移動体網（ＰＬＭＮ：Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）に関連する資格証明を有していなくてもよい。ＴＳＩＭは、ＵＭＴＳセルラーアクセスネットワークの加入資格証明／アプリケーションの管理を指すものとしてよい。例えば、ＴＳＩＭは、ＵＭＴＳ認証鍵などの強い秘密（Ｋｉ）の管理を含むことができる。Ｍ２Ｍの背景状況において、ＴＳＩＭは、Ｍ２Ｍ接続性識別管理（ＭＣＩＭ：Ｍ２Ｍ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｉｄｅｎｔｉｔｙ Ｍａｎａｇｅｍｅｎｔ）も含みうる。

ＴＨＳＭは、ＴＰＭ（ｔｒｕｓｔｅｄ ｐｌａｔｆｏｒｍ ｍｏｄｕｌｅ）またはＭＴＭ（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｍｏｄｕｌｅ）を有するコンピューティングデバイスに見られるＲＴＭ（ｒｏｏｔ ｏｆ ｔｒｕｓｔ ｏｆ ｍｅａｓｕｒｅｍｅｎｔ）に似たＣＲＴＭ（Ｃｏｒｅ Ｒｏｏｔ ｏｆ Ｔｒｕｓｔ（ＲｏＴ） ｏｆ Ｍｅａｓｕｒｅｍｅｎｔ）ユニットを備えることができる。ＴＨＳＭのＣＲＴＭは、例えばＴＨＳＭのブート時に、ＴＨＳＭブートコードの完全性を測定することができる。完全性基準は、Ｅｘｔｅｎｄオペレーションを通じて、例えば、暗号ダイジェスト値のオペレーションをＴＨＳＭのブートコード、ＢＩＯＳ、および適宜、バージョン番号、ソフトウェア構成、またはリリース番号などのＴＨＳＭの製造業者の特性に対し適用することによって計算されうる。例えば、完全性基準は、ＳＨＡ−Ｘなどのあるバージョンの暗号ハッシュアルゴリズムを使用して計算することができる。

ＴＨＳＭは、完全性基準を保護されたストレージに格納するように構成された、ＴＰＭまたはＭＴＭに見られるＲＴＳ（ｒｏｏｔ ｏｆ ｔｒｕｓｔ ｆｏｒ ｓｔｏｒａｇｅ）に似た、ストレージのＣＲＴＳ（ｃｏｒｅ ＲｏＴ ｏｆ Ｓｔｏｒａｇｅ）ユニットを備えることができる。ＴＨＳＭは、ＴＨＳＭの完全性測定結果を外部チャレンジャに報告するように構成され、ＴＰＭまたはＭＴＭに見られるＲＴＲ（ｒｏｏｔ ｏｆ ｔｒｕｓｔ ｆｏｒ ｒｅｐｏｒｔｉｎｇ）に似たＣＲＴＲ（Ｃｏｒｅ ＲｏＴ ｏｆ Ｒｅｐｏｒｔｉｎｇ）ユニットを備えることもできる。

したがって、ＴＨＳＭは、信頼測定、ストレージ、および報告に関してＴＰＭまたはＭＴＭに似た機能を効果的に実現することができる。ＴＨＳＭは、複数のトラステッドステークホルダーエンジン（ｔｒｕｓｔｅｄ ｓｔａｋｅｈｏｌｄｅｒ ｅｎｇｉｎｅｓ）を実現する機能を備えることもできる。さらに、ＴＨＳＭは、各マルチプルステークホルダートラステッドサブシステム（ｍｕｌｔｉｐｌｅ−ｓｔａｋｅｈｏｌｄｅｒ ｔｒｕｓｔｅｄ ｓｕｂｓｙｓｔｅｍｓ）を実現するように構成することができる。したがって、ＴＨＳＭは、ＴＣＧモバイルフォンワーキンググループ（ＭＰＷＧ）の仕様によって定められているような信頼できる携帯電話に似たものとしてよい。

ＴＨＳＭは、例えば、本明細書で説明されるコアＲｏＴ（Ｃｏｒｅ ＲｏＴ）機能を使用して複数の内部「ステークホルダードメイン（ｓｔａｋｅ−ｈｏｌｄｅｒ ｄｏｍａｉｎｓ）」を構築するように構成されうる。ステークホルダーは、ＴＨＳＭデバイス製造業者（ＤＭ）、ＴＨＳＭデバイス所有者（ＤＯ）、またはＴＨＳＭデバイスユーザー（ＤＵ）であってもよい。ＤＵは、ＤＯと同じであるか、またはＤＯと明確に区別されてもよい。ＴＨＳＭ毎に複数のＤＵがあってもよい。ステークホルダーは、ＤＯによって特にリースされるか、または所有されているドメインの異なるリモート所有者（ＲＯ）であってもよい。例えば、ＭＮＯ、ＩＭＳサービスプロバイダ、非３ＧＰＰアクセスネットワーク通信事業者、または付加価値アプリケーションサービスプロバイダなどの第三世代パートナーシッププロジェクト（３ＧＰＰ）ＰＬＭＮ事業者は、ステークホルダーであってよい。

いくつかのドメインは、必須であり、その場合、これらはＴＨＳＭの製造時に予め構成されていてもよい。例えば、ＤＭのドメインは、必須であり、事前構成されたファイルに従ってブート時に構築またはロードされうる。ＤＯのドメインも必須であり、事前に用意されている構成に合わせて構築されうる。あるいは、ドメインは、ダウンロードした構成ファイルに従って構築されうる。

ＤＭのドメイン以外のドメインは、ドメインの所有者によって「請求（ｃｌａｉｍｅｄ）」または「所有（ｏｗｎｅｄ）」される前に、リモート所有権取得（ＲＴＯ：Ｒｅｍｏｔｅ Ｔａｋｅ−Ｏｗｎｅｒｓｈｉｐ）プロセスを受ける必要があるものとしてよい。特定のドメインがＲＴＯプロセスを完了する前に、指定されていない所有者の「手つかずの」ドメインが存在する可能性がある。この場合、そのドメインに対して請求される特定の所有権はない。

ＴＨＳＭ上のドメインは、ＴＨＳＭ−ＭＥインターフェースを介してＭＥと通信し、情報を交換することができる。例えば、ドメインは、ブートアップ（ｂｏｏｔ−ｕｐ）またはＲＴＯプロセスの実行時にＭＥと通信することができる。ＴＨＳＭ−ＭＥインターフェース上で交換されるデータの保護が必要になる場合がある。

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

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

ＲＯによりＴＨＳＭ−ＭＥ間で平文で渡されるメッセージに関するリプレイアタックの防止を行うことができる。ＴＨＳＭ−ＭＥインターフェース上で送信されるそれぞれのメッセージは、ノンスを使って新鮮さのクオリティを保持することができる。簡単のため、本明細書で説明されるＲＴＯプロトコルは、ＭＥ−ＴＨＭＳインターフェース上で交換されるすべてのメッセージのアンチリプレイ保護機能を備えるが、当業者であれば、本出願の範囲を超えることなく他のインターフェース保護構成も使用できることを理解するであろう。

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

ＴＨＳＭプラットフォーム、特にＴＳＩＭが公開鍵Ｋ_RO-Pubを使用して、ＲＯからの署名を検証するか、またはＲＯに送信されたメッセージを暗号化することができる。ネットワーク側で署名のため秘密鍵Ｋ_RO-Privを使用し、また対応する公開鍵を使用してＴＳＩＭによって暗号化されたメッセージを解読することができる。公開−秘密鍵ペアＫ_TSIM-PubおよびＫ_TSIM-Privは、ＴＳＩＭとＲＯの役割が入れ替わっていることを除き類似の機能を備えることができる。あるいは、ＲＯとＴＳＩＭの両方において、暗号化と署名のために別々の鍵ペアがあってもよい。

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

ＴＨＳＭ ＴＤ_DOは、「システム全体のドメインマネージャ（Ｓｙｓｔｅｍ−Ｗｉｄｅ Ｄｏｍａｉｎ Ｍａｎａｇｅｒ）」（ＳＤＭ）を構成することができる。ＳＤＭは、「システム全体のドメインポリシー（Ｓｙｓｔｅｍ−Ｗｉｄｅ Ｄｏｍａｉｎ Ｐｏｌｉｃｙ）」（ＳＤＰ）を含む事前構成されたファイルを保護して格納することができる。ＳＤＭは、ＳＤＰに従ってＴＨＳＭに対するＲＯのドメインを構築またはロードすることができる。ＳＤＭは、ＤＯのドメインの手つかずの構成に含まれうる。ＳＤＭは、事前構成されたＳＤＰを使用して、他のドメインのうちのいずれを、どのような順序で構築すべきかを決定することができる。

ＳＤＭは、ＲＯドメインに代わって、ＲＯドメインによって要求されたときに、ＴＨＳＭプラットフォーム環境要約（ＴＰＥＳ：Ｐｌａｔｆｏｒｍ Ｅｎｖｉｒｏｎｍｅｎｔ Ｓｕｍｍａｒｙ）およびＴＨＳＭプラットフォーム完全性アテステーション（ＴＰＩＡ：Ｐｌａｔｆｏｒｍ Ｉｎｔｅｇｒｉｔｙ Ａｔｔｅｓｔａｔｉｏｎ）を作成して提供することができる。ＴＰＥＳは、ＴＨＳＭの最新の「環境（ｅｎｖｉｒｏｎｍｅｎｔ）」に関する要約情報を記述するものとすることができる。このような情報は、ＴＨＳＭ上の、機密性および分離に関して各ドメインポリシーによって条件付けられるか、または許されるような、ドメインの個数および要約性、ならびに要求側ドメインとの機能またはリソースの通信および共有に利用可能であると思われるＴＨＳＭ上の残りのリソースを含むことができる。ＴＰＩＡは、ＴＨＳＭのドメインのうちの１つまたは複数における完全性アテステーション（Ｉｎｔｅｇｒｉｔｙ Ａｔｔｅｓｔａｔｉｏｎ）の集まりを含むことができる。ＴＰＩＡは、前述のドメインをサポートするプラットフォームの完全性アテステーションも含みうる。ＴＰＩＡは、注目しているドメイン、およびＴＨＳＭ上の手つかずのドメインに対しＲＴＯプロセスを実行することに関心のあるＲＯなどの、外部ベリファイアに対してこれらのドメインをサポートするプラットフォームの信頼状態のアテステーションを行うために使用されうる。ＲＯ、またはＲＯのドメイン（ＴＤ_RO）は、ＳＤＭにＴＰＩＡを要求することができる。ＳＤＭは、ＳＤＰに従って要求を義務付けるか、または拒絶することができる。

ＳＤＭは、ＴＨＳＭの、サービス要員などの、物理的に存在するデバイス所有者（Ｐｈｙｓｉｃａｌｌｙ Ｐｒｅｓｅｎｔ Ｄｅｖｉｃｅ Ｏｗｎｅｒ）とやり取りし、構築すべき他のドメインおよびその構築順序をインタラクティブに識別することもできる。さらに、ＳＤＭは、ＴＨＳＭの物理的に存在するユーザーとやり取りして構築すべきドメインとその構築順序に対する入力を与えるようにユーザーのドメインに要求することもできる。この情報は、ドメイン構築プロセスの入力として使用することができる。

ＴＨＳＭは、ＲＯのドメインに対してＲＴＯプロセスを実行する場合、リモート所有権取得プロトコルの完了前に４つの明確に区別されるシステム状態に至ることができるように構成されうる。ＴＨＳＭプレブートシステム状態は、ＴＨＳＭが「電源オン」されていないことを示すものとしてよい。ＴＨＳＭ＿ＴＤ_DM＿ＬＯＡＤ＿ＣＯＭＰＬＥＴＥシステム状態は、ＴＨＳＭ上のＤＭのドメインがＴＨＳＭの電源オン後の最初のステップとして構築またはロードされていることを示すものとしてよい。ＴＨＳＭ＿ＴＤ_DO＿ＬＯＡＤ＿ＣＯＭＰＬＥＴＥシステム状態は、ＤＯのドメイン（ＴＤ_DO）が利用可能な最終構成（ｌａｓｔ−ｃｏｎｆｉｇｕｒａｔｉｏｎ−ａｖａｉｌａｂｌｅ）に合わせて構築またはロードされたことを示すものとしてよい。この「利用可能な最終構成（ｌａｓｔ ｃｏｎｆｉｇｕｒａｔｉｏｎ ａｖａｉｌａｂｌｅ）」は、ＤＯのドメインがそれ自体のためにＲＴＯプロセスに通ったことがない場合に、「手つかずの（ｐｒｉｓｔｉｎｅ）」構成であるか、または「事後ＲＴＯ（ｐｏｓｔ−ＲＴＯ）」構成であるものとすることができる。ＤＭのドメインは、ＤＯのドメインを構築またはロードすることができる。ＤＯのドメインが少なくとも１つのＲＴＯプロセスを通る前に、ＤＯのドメインは、「手つかずの」状態にあり、特定のＤＯによって請求または所有されることはありえない。「手つかずの」ドメインは、「シェル（ｓｈｅｌｌ）」を含むことができる。はじめてＤＯのドメインが構築またはロードされたときには、「利用可能な最終構成」（これ以降最終構成（Ｌａｓｔ−Ｃｏｎｆｉｇｕｒａｔｉｏｎ）と称する）は事前構成ファイルに由来するものである。あるいは、「最終構成（Ｌａｓｔ−Ｃｏｎｆｉｇｕｒａｔｉｏｎ）」が、ＲＯのドメインに対するＲＴＯプロセスによるものである場合、ＴＨＳＭ上の特定のドメインは、少なくとも１回、リモート所有権取得プロトコルを通り、リモート所有者は、ＴＳＳ_ROの所有権を取得している可能性がある。これは、リモート所有権取得が完了した後に、プラットフォーム上に構成された信頼できるサブシステムを示すものとしてよい。この状態に到達したとき、またはその前に、特定のＲＯが他のタスクの実行を開始することがある。

ＴＨＳＭ＿ＴＤ_RO＿ＬＯＡＤ＿ＣＯＭＰＬＥＴＥシステム状態は、ＲＯのドメイン（ＴＤ_RO）が利用可能な最終構成に合わせて構築またはロードされたことを示すものとしてよい。この「利用可能な最終構成」は、ＲＯのドメインがそれ自体のためにＲＴＯプロセスに通ったことがない場合に、「手つかずの」構成であるか、または「事後ＲＴＯ」構成であるものとすることができる。ＤＭのドメインは、ＲＯのドメインを構築またはロードすることができる。ＤＯのドメインが少なくとも１つのＲＴＯプロセスを通る前に、ＤＯのドメインは、「手つかずの」状態にあり、特定のＤＯによって請求または所有されることはありえない。「手つかずの」ドメインは、「シェル」を含むことができる。はじめてＲＯのＴＤが構築またはロードされたときには、「最終構成」は事前構成ファイル（Ｐｒｅ−Ｃｏｎｆｉｇｕｒｅｄ Ｆｉｌｅｓ）に由来するものである。

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

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

第１の実施形態では、ＭＥは、セキュアブート機能を備えるように構成され、ＴＨＳＭは、完全なＭＴＭ機能を備えるように構成されうる。電源オン時に、ＭＥは安全にブートすることができる。例えば、ＭＥは、ＯＭＴＰ（ｏｐｅｎ ｍｏｂｉｌｅ ｔｅｒｍｉｎａｌ ｐｌａｔｆｏｒｍ）のｔｒｕｓｔｅｄ ｅｘｅｃｕｔｉｏｎ ｅｎｖｉｒｏｎｍｅｎｔ ＴＲ０の仕様などに従って非ＴＣＧ「セキュア」ブートを実行することができる。ブート時に、ＴＨＳＭは、最初に、例えば、ブートアップによって、ＴＨＳＭ ＤＭのドメイン（ＴＤ_DM）を構築し、次いで、「手つかずの」ＴＨＳＭ ＤＯのドメイン（ＴＤ_DO）を構築することができる。ＤＯおよびＤＵが分離している場合、ＴＨＳＭは、ＴＨＳＭ ＤＵのドメインも構築することができる。

ＴＨＳＭ ＴＤ_DMは、ＴＨＳＭで保護されている事前構成されたファイルで最初に構築しておき、ブート時に利用可能にすることができる。ＴＨＳＭ ＴＤ_DOは、事前構成されたファイルで大半が構築されうるが、ＲＴＯプロセスを使用して構築することもできる。ＴＨＳＭ ＴＤ_DOは、ＲＴＯプロトコルを通ることができる。このプロトコルは、ＲＯのドメイン（ＴＤ_RO）に対するＲＴＯプロトコルと同じ形態をとるか、または異なるプロトコルであってもよい。ＴＨＳＭ ＴＥ_DOがＲＴＯプロトコルを通らない場合、所有権を取得するために必要な資格証明が事前構成され、事前に用意される。ＴＨＳＭ ＴＥ_DOは、ＤＯによって所有されうる。ＤＯは、実際の人間ユーザーもしくは所有者、企業もしくはその情報技術（ＩＴ）部門などの組織、またはリモートネットワーク通信事業者（ＮＯ：Ｎｅｔｗｏｒｋ Ｏｐｅｒａｔｏｒ）であるものとしてよい。

ＴＨＳＭ ＴＤ_Uは、ＴＨＳＭ ＴＥ_DO内に事前に用意された事前構成ファイルで構築することができる。ＴＨＳＭのＲＯドメインは、最初に、ＴＨＳＭ ＤＯのシステム全体のドメインポリシー（ＳＤＰ）に従って、「手つかずの」構成に合わせて構築することができる。ＴＨＳＭのＲＯドメインは、ＲＯによるＲＴＯプロセスを通ることができる。ＤＯのドメインのＳＤＭは、ＳＤＰに従って、ＲＯのドメインに対するＲＴＯプロセスを管理することができる。ＴＨＳＭのＲＯが、ＭＮＯであり、ＲＯのドメインがＭＮＯのドメインである場合、そのようなＭＮＯのドメインは、ｉ）ＭＮＯのドメインをＭＮＯに登録する方法、ｉｉ）加入資格証明（例えば、ＵＳＩＭまたはＭＣＩＭ秘密鍵Ｋｉおよび国際移動電話加入者識別番号（ＩＭＳＩ：Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｆｉｅｒ）など）をＭＮＯのモバイルネットワークからＴＨＳＭ上のＭＮＯのドメインにロールオフし、次いでそこに用意する方法、およびｉｉｉ）加入資格証明をダウンロードした後、そのような資格証明を取り扱う、または使用する機能、またはさらには加入管理機能を備えるドメインを一方のデバイスから別のデバイスへ移行する方法を定めるプロトコルを通ることもできる。そのようなプロトコルは、ｉ）登録プロトコル、ｉｉ）資格証明ロールオフプロトコル、および３）移行プロトコルとそれぞれ称することができる。ＴＨＳＭのＲＯドメインは、ＲＴＯが完了した後に、その自構成のアテステーションを行い、それをＲＯに報告することができる。

第１の実施形態において、ＭＥの信頼構築メカニズムが電源投入時セキュアブートプロセスの実行に制限されうる場合、ＭＥ構成は、ＭＥまたはＴＨＳＭによってさらにアテステーション可能でない場合がある。あるいは、ＭＥは、セキュアブートを完了するときに、自己完全性（ｓｅｌｆ−ｉｎｔｅｇｒｉｔｙ）チェックを実行し、完全性値（ＩＶ）を生成することができる。ＭＥは、機密性および完全性保護用のエンジンなどのソフトウェアを、無線（ＯＴＡ）による方法を使用して、ＵＭＴＳセキュリティモード機能などのセキュリティモード機能などに従ってインストールすることができる。適宜、ＲＯによるＲＴＯプロセスを介してＲＯのドメインの所有権を取得する場合、ＲＯは、ＲＴＯプロセスを完了させるために受け入れることができるＴＨＳＭの条件に関する自ポリシーをダウンロードするか、または他の何らかの形でインポートし、次いでアサートすることができる。ＲＯは、ＲＯがＴＨＳＭ全体の条件、またはＴＨＳＭの他のドメインの構築構造の条件、またはその両方に合意したときにＴＨＳＭプラットフォーム上に自分のドメインをインストールする「ゲートキープ（ｇａｔｅ−ｋｅｅｐ）」を行うように構成されうる。したがって、ＲＴＯプロセスの一部として、ＲＯは、ＤＯのドメインのＳＤＭと何らかの情報の交換を行って、ＤＯの条件または「ドメイン構築プラン（ｄｏｍａｉｎ−ｂｕｉｌｄｉｎｇ ｐｌａｎｓ）」を識別し、そのような条件がＲＯに受け入れ可能である場合のみＲＴＯプロセスを完了させることができる。ＲＯドメインは、権利を持つこともでき、最初にＴＨＳＭ上にそのＲＴＯ完了ＲＯ（ＲＴＯ−ｃｏｍｐｌｅｔｅ ＲＯ）のドメインを構築することに合意した後ＴＨＳＭの条件またはドメイン構築プランの変更があれば更新するか、または通知するようにそのような権利を強制する機能を実行するように構成されうる。ＲＯのドメイン固有のポリシー（ＤＰ：ｄｏｍａｉｎ−ｓｐｅｃｉｆｉｃ ｐｏｌｉｃｙ）では、ＲＯのドメインに通知する必要があると思われる変更の種類を指定することができる。

ＳＤＭは、対象となるＲＯに関連付けられているＲＯドメインに対するＲＴＯプロセスを開始することができる。これは、ＲＯのドメインが「手つかずの（ｐｒｉｓｔｉｎｅ）」、「未請求（ｕｎｃｌａｉｍｅｄ）」状態にある場合に起こりうる。例えば、ＲＯのドメインに、ＤＯのドメインとＤＯにより「Ｄｏｍａｉｎ Ｘ」（ＴＤ_X）と名付けることができる。ドメインは、今のところ未請求のシェルまたは「手つかずの」状態で作成されうる。このような場合、ＳＤＭはＲＴＯプロセスを開始することができ、これにより、ドメインＴＤ_Xの代わりに、対象のＲＯと接触する。ＲＯがこのドメインについてＲＴＯプロセスを通った後、ＳＤＭは、この同じドメインについて別のＲＯプロセスを開始することができなくなる。その代わりに、ＲＯそれ自体が、この特定のドメイン上で別の種類の所有権取得プロセスを開始することができる。そのような所有権取得プロセスは、これまでに指定されているＲＴＯプロセスと、前者がデバイスの所有者／ユーザーまたはデバイスそれ自体によってローカルで開始されるのではなくリモート所有者によってリモートで開始されうるという点で異なることがある（場合によってはＳＤＭまたはＤＯのドメインの調整の下で）。ＤＯは、ＲＯのドメインがＲＴＯプロセスを通り、そうして適切なＲＯによって「請求（ｃｌａｉｍｅｄ）」または「所有（ｏｗｎｅｄ）」された後でも、ＲＯのドメインの削除、破壊、または切断を行う権限を保持することができる。しかし、ＤＯは、一般に、ＲＯのドメイン内に格納されている秘密を知ること、またはＲＯのドメイン内で実行される計算または機能の中間結果を知ることができない可能性がある。

ＳＤＭが手つかずのＲＯのドメインに対してＲＴＯプロセスを開始する前に、利用可能なリソースのリストにドメイン構築が載っていないか調べることができる。リストは、ＤＭのドメインによって保持されうる。ＳＤＭは、「望ましいドメイン（Ｄｅｓｉｒｅｄ Ｄｏｍａｉｎｓ）」リストを調べることもできる。望ましいドメインリストは、ＤＯのドメインＴＤ_DO内に保持されうる。ＳＤＭは、システムドメインポリシー（ＳＤＰ：Ｓｙｓｔｅｍ Ｄｏｍａｉｎ Ｐｏｌｉｃｙ）、およびＤＭのドメインからのクエリに利用可能であると思われる、ＴＨＳＭの既存のドメインの、またプラットフォームの、信頼状態を含む現在状態を調べることもできる。この情報を使用して、特定のＲＯのドメインに望ましいＲＴＯプロセスが利用可能なリソースおよびポリシーの下で可能であり、望ましいドメインリスト（Ｄｅｓｉｒｅｄ Ｄｏｍａｉｎｓ ｌｉｓｔ）の下で望ましく、ＴＨＳＭの既存のドメインの状態、例えば、信頼状態の下で許されるかどうかを判定することができる。

あるいは、リモート所有者のドメイン（ＴＤ_RO）は、単独でＲＴＯプロセスを開始し、管理することもできる。ＴＤ_ROは、未請求で、ＲＴＯプロセスの前の「手つかずの」状態にあるものとしてよい。「手つかずの」ＲＯのドメインＴＤ_ROは、ブートアップ後に対象のＲＯと接触し、ＲＴＯプロセスを自律的に開始させることを可能にする事前構成済みの機能を備えることができる。適宜、取得側ＴＤ_ROがＴＨＳＭの所有者またはユーザーにプロンプトを出し、次いでＴＨＳＭの所有者またはユーザーから「うなずき」を得てＲＴＯプロセスを開始した後、ＲＴＯプロセスを開始することができる。（ターゲットの）リモート所有者ＲＯ＿ｔａｒｇｅｔによって作成され、所有されることが意図されているが、ＲＴＯプロセスを介してまだ所有されていない、まだ「手つかずの」状態にあるドメインＴＤは、これ以降、ＴＤ_{RO_target}＊と称される場合がある。

別の代替的形態では、ＴＤ_ROは、特定のＲＯによる少なくとも１つのＲＴＯプロセスを通っており、これは、ＲＯによって現在「請求」または「所有」されている可能性がある。ドメインＴＤ_DOなどのＴＨＳＭ上のＤＯまたはそのプロキシが同じＲＯのドメインに対し別のＲＴＯプロセスを開始することが許されうるかどうかは、ＲＯのポリシーおよび／またはＳＤＭのポリシーに依存しうる。ＳＤＭは、ＲＴＯの目的を調べ、そのポリシー構造内の許容可能な目的または活動に基づいて、そのような新しいＲＴＯを進めることを許すかどうかを決定することができる。リモート信号送信を介したＲＯ、またはＲＯのドメイン（ＴＤ_RO）は、同じＲＯを持つドメインに対して別のＲＴＯプロセスを開始することができる。これは、ＲＯがＴＤ_RO内の構成ファイル、セキュリティポリシー、または実行可能コードを更新する必要がある場合に起こりうる。ＲＯは、更新をダウンロードすることができる。更新は、非ＲＴＯの無線（ＯＴＡ：ｏｖｅｒ ｔｈｅ ａｉｒ）による更新プロセスで実行できる。しかし、場合によっては、ＲＯまたはＴＤ_ROは、別のＲＴＯプロセスを使用していくつかのファイルもしくはコードを更新することができる。

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

ＳＤＭポリシーは、ＤＯに対する所有権取得（ＴＯ：ｔａｋｅ−ｏｗｎｅｒｓｈｉｐ）プロセス実行時に構成されうる。このプロセスは、ブートプロセスの実行時に強制される既存の構成構造を介して、ローカルで実行できる。ＤＯのＴＯは、リモートでも実行することができ、このプロセスは、ＲＴＯをブロックまたは許可するためのＳＤＭｅｘａｍｉｎａｔｉｏｎが非デバイス所有者のリモート所有者に対するＲＴＯプロセスの場合と異なりＤＯのドメインに対するＴＯプロセスの場合には呼び出されないという点を除き、本明細書で指定されているように、デバイス所有者のドメインではないドメインの所有権取得とともに使用することが意図されているＲＴＯプロセスに類似するものとしてよい。ＳＤＰは、ローカルで実行されうるＤＯ所有権取得プロセスの際に（ＤＯが物理的に存在し、デバイスとインタラクティブにやり取りする）、またはリモートに位置するデバイス所有者とのリモートのインタラクティブなやり取りを伴う形で確立されうる。ＳＤＰのコンポーネントは、すべての非ＤＯドメインに共通の許容可能な活動または目的のリストである。このリストは、ドメインの所有権取得を許可されないリモート所有者を指定する追加のエントリも含みうる。

第２の実施形態では、ＭＥは、セキュアブート機能を有し、そのブートコードの一部の「セキュアブート（ｓｅｃｕｒｅ ｂｏｏｔ）」チェック機能の一部を実行するためにＴＨＳＭに依存しうる。ＭＥは、ＯＭＴＰ ＴＲ０セキュアブートなどの非ＴＣＧセキュアブートを実行することができる。ＴＨＳＭを使用して、ＭＥの完全性をチェックし、ＴＨＳＭに与えられる物理的保護を「利用する（ｕｔｉｌｉｚｅ）」ことができる。例えば、ＭＥは、未加工データをＴＨＳＭに送信することができ、ＴＨＳＭは、ＭＥの完全性をチェックすることができる。ＷＴＲＵは、ＭＥとＴＨＳＭとの間にセキュアチャネルを設けるメカニズム、およびＭＥの完全性チェックをＴＨＳＭ側で実行することを目的としてコードまたはデータをＴＨＳＭに安全な方法で送信し、ＴＨＳＭとセキュアチャネルなどを介して安全に通信することを少なくとも信頼できるＭＥの「いくぶん信頼に足る（ｓｏｍｅｗｈａｔ ｔｒｕｓｔｗｏｒｔｈｙ）」部分を実装することができる。ＴＨＳＭは、その中に、ＭＥに代わってＭＥのコードの一部を格納することもできる。これらのコードは、ブートプロセスの実行時にＭＥ内にロードすることができる。ＴＨＳＭは、ＭＥの完全性チェックを実行するか、またはＭＥに対するコードの一部を格納しロードする役割を受け持つことができるが、それは、それ自身とＭＥとの間でＴＨＳＭがハードウェアベースの保護メカニズムを持つことでより信頼性の高い環境となりうるからである。

第３の実施形態では、ＴＨＳＭは、セキュアブートの一部またはＭＥのコードの完全性チェックを実行することができる。これは、ＲＯをアテステーション可能であるものとしてよい。ＭＥは、単一の信頼できるエンティティ、つまりモバイルトラステッド環境（ＭＴＥ：Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｅｎｖｉｒｏｎｍｅｎｔ）を備えることができる。ＭＴＥは、ＭＥの残り部分よりも信頼できるＭＥ内の論理的に分離されている環境であるものとすることができる。ＭＴＥは、ハードウェアベースの信頼のルート（ＲｏＴｓ）などのいくつかのハードウェアベースの保護メカニズムを利用することができる。ＭＥのベースコードがロードされた後、ＭＴＥをロードすることができる。ＭＴＥは、外部ベリファイアに信頼できる署名鍵の使用などの信頼の証明を与えることができるという意味で信頼できるエンティティであるものとしてよい。ＭＴＥは、信頼できるエンティティであるけれども、実際のＴＰＭに関連付けられている測定プログラムコードであるＣＲＴＭ（ｃｏｒｅ ｒｏｏｔ ｏｆ ｔｒｕｓｔ ｆｏｒ ｍｅａｓｕｒｅｍｅｎｔ）を有することができない。ＭＥが、電力を供給されるデバイスとして、ＴＨＳＭが動作しうる「プラットフォーム（ｐｌａｔｆｏｒｍ）」を提供する限り、ＭＥは、本明細書ではＭＥプラットフォームと称することができる。ＭＴＥは、ＭＥプラットフォームの完全性の証拠を集めて、その証拠を、ＭＴＥ内で保護されている署名鍵の使用によってなされる少なくとも完全性保護の下で、ポストブートＳＤＭなどのＴＨＳＭ内の信頼できるエンティティに回送するように構成されうる。ＴＨＳＭは、ＴＣＧ ＴＰＭまたはＭＴＭに似た完全性測定および検証機能を実装するので、ＴＨＳＭは、「Ｅｘｔｅｎｄ」オペレーションを実行するＴＣＧ ＴＰＭまたはＭＴＭの機能も実装することができ、これにより、現在のソフトウェアの測定結果を、ソフトウェアのロードの状態の推移を示すプラットフォーム構成レジスタ（ＰＣＲｓ：Ｐｌａｔｆｏｒｍ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｒｅｇｉｓｔｅｒｓ）の現在値と組み合わせて、ＰＣＲに対する新しい値を計算する。ＴＨＳＭは、ダイジェスト値（ソフトウェアコンポーネントの完全性の未加工の測定値である）またはＰＣＲの値を、ＴＨＳＭに対してＭＥプラットフォームが信頼性のアテステーションを行うために使用することができる別の完全性データに変換するメカニズムを実装することもできる。簡単のため、ＭＥプラットフォーム完全性の収集データは、これ以降、ＭＥプラットフォーム完全性データ（ＭＰＩＤ：ＭＥ Ｐｌａｔｆｏｒｍ Ｉｎｔｅｇｒｉｔｙ Ｄａｔａ）と表す場合がある。ＴＨＳＭは、ＭＥまたはＭＴＥに対するドメインを維持することができない。ＴＨＳＭは、事前構成されたファイルから、またはＤＭとのリアルタイムの接触によって、計算されたダイジェストをチェックする際に突き合わせる認定済みの基準を取得することができるものとしてよい。一致していると判定された場合、次にＭＥのアテステーションを行うことができる。ＭＴＥは、型式番号、実行が意図されているサービスの種類、およびサービスの対象者などの、ＭＥの「環境（ｅｎｖｉｒｏｎｍｅｎｔ）」を記述するデータを収集することができる場合もある。簡単のため、ＭＥのそのような環境記述は、これ以降、ＭＥプラットフォーム環境調査（ＭＰＥＳ：ＭＥ Ｐｌａｔｆｏｒｍ Ｅｎｖｉｒｏｎｍｅｎｔ Ｓｕｒｖｅｙ）と表す場合がある。ＴＨＳＭ ＤＯのＲＯは、その自ドメインとともにＭＥプラットフォームの完全性のアテステーションを行うことができる。このアテステーションは、特許文献１において指定されているような、Ｍ２Ｍを背景とする、トラステッド環境（ＴＲＥ：Ｔｒｕｓｔｅｄ Ｅｎｖｉｒｏｎｍｅｎｔ）のＭ２ＭＥ妥当性確認機能（Ｍ２ＭＥ Ｖａｌｉｄａｔｉｏｎ ｆｕｎｃｔｉｏｎ）に類似しているものとしてよい。ＭＥは、継続的に、単独で、またはＴＨＳＭからの要求があったときに、その変化する状態をＴＨＳＭに報告することができる。

第４の実施形態では、ＭＥとＴＨＳＭの両方を、完全なＭＴＭ機能を実行するように構成することができる。ＭＥ、またはそのドメインが信頼に足るかどうかは、ＭＥによって、またはそのドメインによって直接的に、アテステーション可能であるものとしてよい。ＭＥのＲＯドメインは、継続的に、または要求があったときに、その状態をＲＯに報告することができる。ＴＨＳＭのＲＯドメインも同様に機能しうる。ＭＥのＲＯドメインおよびＴＨＳＭのＲＯドメインによる報告は、同期させることができ、また互いに束縛することもできる。これらの報告は、プロトコルフローの共通セッションを使用して行うこともできる。

この実施形態では、ＭＥは、本明細書で説明されるようにＴＨＳＭのいくつかの機能を実行するように構成されうる。ＭＥは、自らの１つまたは複数のドメインを備え、それぞれ特定の所有者に関係するものとしてよい。これらのドメインは、ＴＨＳＭによる信頼できるエンティティの特性を備えるものとしてよい。そのようなドメインは、デバイス製造業者（ＤＭ）ドメインおよびユーザー（Ｕ）ドメインを含みうる。これらのドメインは、ＴＨＳＭと同様にして事前構成することができる。ＭＥ上のドメインをＴＨＳＭ上のドメインから区別するために、ＭＥに、ドメインそれ自体を指定する文字を下付き文字にして付けることができる。したがって、ＤＭに対するドメインは、ＭＥ_DMで表すことができる。ＴＨＳＭ上のデバイス所有者（ＤＯ）ドメインは、ＭＥ側のドメインを監視して、ＳＤＭに置かれるシステム全体のドメインポリシー（ＳＤＰ）への準拠を確認することができる。ＭＥ内にそれぞれのドメインを作成する場合に、ＳＤＭとの通信により、ＴＨＳＭ ＤＯはそれぞれの新しいドメイン構成を認識することができる。

ＭＥは、ＴＨＳＭにおけるＳＤＭと同様に機能しうる、プラットフォームドメインマネージャ（ＭＥ_PDM）として称されうる、ドメインマネージャを備えることができる。ＭＥ_PDMは、ＭＥ_DM内に置かれ、最初は、ＤＭによって定義されるような事前構成を有することができる。この初期構成は、その目的と機能に関して、ＴＨＳＭ上のＴＤ_DMの初期の事前構成された定義と類似するものとすることができる。ＭＥ_DMのセットアップは、ＴＤ_DOがＴＨＳＭにおいてインスタンス化された後に行われるように時間設定することができる。ＳＤＭが、ＭＥ_DMに対するセットアップが完了したことを通知された場合、これは、システム全体の制約条件に応じて、ＳＤＰに由来する、またはＳＤＰの反射におけるポリシー制約条件を課すことができる。ＳＤＭは、ＴＨＳＭ上に多数のリモート所有者およびそのドメインのリストを保持することができる。ドメインが、リストに載っている所有者の１人に属するＭＥ上に作成され、管理される場合、ＳＤＭは、ＭＥ上のそれらのドメインの作成および管理の特定の制御を行うことができる。

この実施形態では、ＭＥは、完全なＭＴＭ機能を有することができる。したがって、これは、ＣＲＴＭ（ｃｏｒｅ ｒｏｏｔ ｏｆ ｔｒｕｓｔ ｆｏｒ ｍｅａｓｕｒｅｍｅｎｔ）、ＣＲＴＲ（ｃｏｒｅ ｒｏｏｔ ｏｆ ｔｒｕｓｔ ｆｏｒ ｒｅｐｏｒｔｉｎｇ）、およびＣＲＴＳ（ｃｏｒｅ ｒｏｏｔ ｏｆ ｔｒｕｓｔ ｆｏｒ ｓｔｏｒａｇｅ）を備えることができる。ＴＨＳＭ上で、ドメイン加入機能はＴＳＩＭ機能によって管理されうる。ＴＨＳＭ内の一方のドメインおよびＭＥ内の他方のドメインなどの２つのドメインが、同じＲＯに対するものである場合、ＴＨＳＭ上のドメインは、そのリモート所有者に対する加入機能およびその管理などの、非常の高レベルのセキュリティおよび／または信頼を必要とするＲＯに対する機能またはサービスに使用することができるが、ＭＥ上のドメインは、それでもまだ特定のレベルのセキュリティまたは信頼を必要としうるがＴＨＳＭ上のドメインから予想される機能およびサービスに必要なレベルと同じレベルではない同じＲＯに対する機能またはサービスに使用することができる。事前構成されたファイルから構築されないドメインは、リモート所有権取得（ＲＴＯ）プロセスを通じて構成されうる。典型的なリモート所有者（ＲＯ）に対するＭＥのＲＴＯは、ＴＨＳＭのものと類似のものであってよい。

ＭＥ上のドメインは、リモート所有者に対する加入管理に使用されることが意図されていない場合がある。その代わりに、これらは、ユーザー、所有者、リモート所有者、またはこれらの組み合わせのために大量の計算およびリソースを必要とするタスクを実行するために使用されることが意図されていてもよい。例えば、これらのドメインは、ＴＨＳＭ上の比較的限られたリソースに対して実用的でない可能性のあるタスクを実行することができる。ＭＥ上のドメインは、１回作成されてその後明示的に削除されるまでＭＥ内に留まる代わりに、これらのドメインは仮想化の場合と同様にブート時に、またはさらには実行時のセッションにおいて作成され、一時的なセッションベースで特定の目的に使用されうるという点で「つかの間の（ｅｐｈｅｍｅｒａｌ）」または「一時的な（ｔｅｍｐｏｒａｒｙ）」ものであってもよい。ＭＥ上のドメインのリモート所有者は、他のリモート所有者によって所有されるＭＥ上の他のドメインまたはＴＨＳＭ上のそのような他のドメインのリソースおよびその目的の割り当てのアテステーションがなされた調査を要求し取得することに関して同じレベルの特権を有することはできない場合もある。

モバイルトラステッドプラットフォーム（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｐｌａｔｆｏｒｍ）のデバイス所有者がＭＮＯリモート所有者としても知られる特定のＰＬＭＮによって事前割り当ておよび初期化がなされていない「ブランク（ｂｌａｎｋ）」のＷＴＲＵを購入し、制約なしで移動体通信事業者を任意に選択できるようにする方法を提供すると有益である。この方法は、リモート所有者がＰＬＭＮ事業者であるか、または加入アプリケーションの対象となる他の類似の事業者である場合にＵＭＴＳデバイス（ＵＥ）などの、ＷＴＲＵの、ＲＴＯプロセスなどの、所有権取得プロセスを実行することを含み、ＴＨＳＭ内のドメインであり、正しいＲＯによって請求されうるＲＯのドメインなどの、サブシステムをセットアップし、カスタマイズし、ファイナライズすることができる。

すでに述べたように、信頼できるハードウェア加入モジュール（ＴＨＳＭ）は、ＩＭＳ加入識別モジュール（ＩＳＩＭ）などの、ＰＬＭＮ事業者のための加入アプリケーションおよび他の付加価値サービスの機能を備える改竄防止機能付きハードウェアコンポーネントモジュールとして構築されるか、またはＴＨＳＭ内に、そのような改竄防止機能付きハードウェアコンポーネントモジュールを備えることができる。ＴＨＳＭは、ＷＴＲＵから取り外し可能であるか、または取り外し不可能であるものとしてよい。ＵＩＣＣの機能強化バージョンまたはグローバルプラットフォーム規格に準拠するスマートカードは、そのようなＴＨＳＭの一実施形態であるものとしてよい。

所有権取得オペレーションは、通信事業者またはＰＬＭＮとＷＴＲＵとの間の基本的な「信頼（ｔｒｕｓｔ）」関係を構築する。この手順で、汎用の「信頼できる（ｔｒｕｓｔｅｄ）」ソフトウェア構成を有する「手つかずの（ｐｒｉｓｔｉｎｅ）」エンジンを備える「ブランクトラステッド（ｂｌａｎｋ ｔｒｕｓｔｅｄ）」ＴＳＩＭをインストールしてインスタンス化することができる。このサブシステムは、プラットフォームが「手つかずの（ｐｒｉｓｔｉｎｅ）」構成およびセキュリティ属性の証拠をもたらすことが可能である場合に、リモート所有者によって「認定（ｃｅｒｔｉｆｉｅｄ）」されうる。図３および図３Ａは、本明細書で説明される第１の実施形態に特に関係しているときにこのプロセスの一例を示している。リモート所有者は、要求されたサービスをユーザーに提供し、適切なセキュリティポリシーをセットアップし、サービスと整合性のとれたデバイス構成を強制するモバイルネットワークであってもよい。このプロトコルに対する所有者はローカルに置かれていてもよい。

図３および図３Ａは、例示的なブートアップおよびＲＴＯプロセスを例示している。ＭＥは、プレブート（ｐｒｅ−ｂｏｏｔ）状態３０４を有することができる。３０６でデバイスを電源オンにすることができる。ＭＥは、３０８で、「セキュア（Ｓｅｃｕｒｅ）」ブート（非ＴＣＧ）を実行することができる。ＭＥは、ベースコードブート（ｂａｓｅ ｃｏｄｅ ｂｏｏｔ）状態３１０に到達することができる。さらに、ＭＥは、３１２で、「ベースブート完了（ｂａｓｅ ｂｏｏｔ ｃｏｍｐｌｅｔｅｄ）」信号をＴＨＳＭに送信することができる。ＭＥは、３１４で、基本構成により追加のソフトウェアをロードすることができる。ＭＥブートは、３１６で、完了（アプリケーションロード）状態になるものとしてよい。ＭＥは、３１８で、ＴＨＳＭにブート完了メッセージを送信することができる。

ＴＨＳＭは、プレブート状態３３０にあるものとしてよい。ＴＨＳＭは、３３４で、ＴＥ_DMをロードすることができる。ＴＨＳＭは、構成時に事前構成されたファイルを受け取ることができ、例えば、３３６は、事前構成されたファイルの使用を例示している。３３８で、ＴＨＳＭは、「ＴＤ_DM構築（ＴＤ_DM ｂｕｉｌｄ）」状態（基本構成状態）に到達しうる。ＴＨＳＭは、例えば３４０に例示されているように、ＲＯドメインに対する利用可能なリソースに関するＤＭの仕様を受信することができる。

３４２で、ＴＤ_DMは、ＴＤ_DOを構築することができる（ＴＤ_DOはＳＤＭを含むことができる）。３４４で、ＴＨＳＭは、保存済み構成ファイルを使用して、例えば、ドメインを構築することができる（前のＲＴＯがあるため利用可能である場合がある）。３４６で、ＴＨＳＭは、ＴＤ_DO構築状態（ＳＤＭを含む）に到達することができ、ＴＤ_DOは、ＤＯによって未請求であるか、または請求済みであるものとしてよい。３５０で、ＴＤ_DOはＴＤ_Uを構築することができる。３５２で、ＤＯから入力を受け取ることができる。３５４で、ＴＨＳＭは、ＴＤ_U構築状態に到達することができ、ＴＤ_Uは、未請求であるか、または請求済みであるものとしてよい。３５６で、ＴＨＳＭは、ＤＯまたはＤＵから入力を受け取ることができる（例えば、ファイルまたはインタラクティブな操作によって、ＤＯがどのドメインを構築したいかを指定する）。３５８で、ＴＤ_DOは、ＲＯドメイン、ＴＤ_RO（複数可）を構築することができる。

次に図３Ａを参照すると、３６２で、ＴＨＳＭが、ＴＤ_ROが構築された状態に到達することができ、ＴＤ_ROは、ＲＯによって未請求であるか、または請求済みであるものとしてよいことがわかる。３６６で、ＳＤＭが、ＲＴＯを実行するようにＴＤ_ROに要求することができるか、またはＴＤＲＯが、ＲＴＯを実行することをＳＤＭに通知する（または要求する）ことができる。３７０で、ＴＤ_ROはＲＴＯプロセスを開始することができる。３８０では、代表的なリモート所有者（ＲＯ₁．．．ＲＯ_n）がある。３８４で、情報を交換することができる。例えば、リモート所有者によるＲＴＯプロセスの一部として、交換される情報は、アテステーション、構成、ポリシー、目的、証明書（本明細書ではＣＥＲＴと称する）、鍵、およびＳＰからＴＤ_ROまでのうちの１つまたは複数の含むことができる。適宜、ＲＯは、ＲＴＯプロセスの実行中にＤＯの「環境（ｅｎｖｉｒｏｎｍｅｎｔ）」または「ドメインプラン（ｄｏｍａｉｎ ｐｌａｎ）」を見いだすことができ、それが環境／プランと一致する場合にプロセスを続行させることができる。

３７２で、ＴＨＳＭは、さまざまなドメインに対するシステム構成を取り込み／更新し、その情報を保存し、その情報をＴＨＳＭ内の不揮発性の保護されたメモリに格納することができる。３７４で、ＴＨＳＭは、ポストＲＴＯ（ｐｏｓｔ−ＲＴＯ） ＴＤ_ROを持つ状態に到達することができる。

第１の実施形態を参照すると、ＤＯのＲＴＯによって形成されたポリシードメインは、その後のＲＴＯプロセスのドメイン構成に影響を及ぼす規定を含みうることがわかる。ＲＴＯプロトコルは、非ＤＯ ＲＯに適しているものとしてよい。ドメイン固有のポリシー（ＤＰ）を、ＲＴＯトランザクションの実行時にダウンロードすることができる。ＤＯに対するＤＰは、ＲＯに対するＤＰと、そのようなＤＰ（ＤＰ_DO）がＴＨＳＭ内の、リモートで所有されうる、他のドメインを構築し、維持するために使用することを目的とするシステム全体のドメインポリシー（ＳＤＰ）を含みうるという点で、異なる場合がある。ＲＴＯプロセスの実行前に、またはＲＴＯプロセスの実行中に、ドメインのＲＯは、信頼できる第三者（ＴＴＰ）から、ＴＨＳＭのすべてのドメインもしくはすべてのドメインのサブセットをサポートするハードウェアもしくはソフトウェアの構成および現在の完全性状態に対する参照完全性基準（ＲＩＭ_RO）を取得することができ、
ＴＴＰ→ＲＯ：ＲＩＭ_RO＝｛Ｃｏｎｆｉｇｕｒａｔｉｏｎ ａｎｄ ｓｔａｔｅ ｏｆ ｔｈｅ ＨＷ／ＳＷ ｓｕｐｐｏｒｔｉｎｇ Ｄｏｍａｉｎｓ ｏｆ ｔｈｅ ＴＨＡＭ，ａｎｄ／ｏｒ ｄｉｇｅｓｔ ｖａｌｕｅｓ｝
式１
と表すことができる。

いくつかの場合において、ＴＴＰは、ＲＯが検証しようとしているドメインを含む、ＴＨＳＭのＨＷおよびＳＷのサブセットに対しＲＩＭ_ROを提供することができる。ＲＩＭ_ROを提供するために複数のＴＴＰが必要になる場合があり、ＲＯは集合的な参照基準を集めて形成する。ＲＴＯプロセスが適用されるＴＨＳＭのターゲットドメイン（ＴＤ_{RO_target}）は、ＴＨＳＭのＳＤＭの助けを借りて、そのＲＯに署名されたＴＨＳＭプラットフォーム完全性アテステーション（ＴＰＩＡ）を提供するように構成されうる。ＴＰＩＡは、ＴＨＳＭ上のドメインの個別の完全性アテステーションおよび／またはＴＤ_{RO_target}によるＲＴＯプロセスの完了を許す前にターゲットドメインのＲＯが検証しようとしているデバイスのプラットフォームの完全性アテステーションの連結であるものとしてよい。ＴＨＳＭのターゲットドメイン（ＴＤ_{RO_target}）は、ＴＨＳＭのＳＤＭの助けを借りて、そのＲＯに署名されたＴＨＳＭプラットフォーム環境要約（ＴＰＥＳ）を提供することができるものとしてよい。ＴＰＥＳは、ＴＨＳＭ上の他のドメインの数および性質、およびＴＥ_{RO_target}のために使用することが可能な、ＴＨＳＭのプラットフォームのリソースなどの残りの利用可能なリソースを含む、ＴＨＳＭの環境の要約を含むことができ、
ＴＤ_{RO_target}→ＲＯ：［ＴＰＩＡ］_signed｜｜［ＴＰＥＳ］_signed
式２
と表すことができる。

あるいは、ＲＯが注目するすべてのドメイン上のすべてのアテステーションを含むことができるＴＰＩＡを報告する代わりに、ＳＤＭは、すべてのドメインの完全性のチェックを済ませ、それらが信頼に足るものであるとみなすことを示す、半自律的ステートメントであってもよい、署名されたステートメントを提供することができる。このアテステーションは、ドメインの集まりの完全性のローカルでの検証を含みうる。ローカルのベリファイアは、ＴＨＳＭ上のそれぞれのドメインに対する有効な構成リストを含みうる。ＳＤＭは、ローカルのベリファイアに、ＡＩＫによって署名されうるＴＰＩＡを提供することができる。個別の完全性アテステーションの検証は、構成リストに載っている対応するローカルに格納されているエントリと一致することを要求する場合がある。ＳＤＭは、ＴＰＩＡを組み立てて、それぞれのドメインが信頼に足ることを証明するのに必要な完全性測定、ロギング、およびＰＣＲへの拡張を実行することができる。これらの測定、およびその拡張は、必要なドメインに対するアテステーションが行われたことを立証するためにベリファイアによって使用されうる。

検証が行われた後、ローカルのベリファイアは、関連するアテステーションが行われことを示すステートメントを作成し、このステートメントに、認証された鍵ペア（Ｋ_{sign_verify_priv}、Ｋ_{sign_verify_pub}）からの秘密鍵とともに署名する。署名されたＴＰＥＳと連結された署名入りの検証ステートメント（Ｖｅｒｉｆｉｃａｔｉｏｎ Ｓｔａｔｅｍｅｎｔ）を含むメッセージは、
ＴＤ_{RO_target}→ＲＯ：［Ｖｅｒｉｆｉｃａｔｉｏｎ Ｓｔａｔｅｍｅｎｔ］Ｋ_{sign_verify_priv}｜｜［ＴＰＥＳ］_signed
式３
と表すことができる。

ＴＴＰ（複数可）からの｛ＲＩＭ_RO｝（複数可）ならびにＴＤ_{RO_target}からの署名されたＴＰＩＡおよび署名されたＴＰＥＳを受け取った後、ＲＯは、ＴＤ_{RO_target}がＲＴＯプロセスを続行するために同意できるとＲＯが判断したＴＨＳＭ内の環境などの環境内に入っており、ＴＤ_{RO_target}およびＲＯが注目する他の任意のドメインをサポートするハードウェアまたはソフトウェアが、完全性がＲＯにとって同意できるものである状態にあるかどうかを検証することができる。

手つかずのドメインに対するＲＴＯプロトコルは、電源投入時に開始することができる。適宜、ＲＴＯプロトコルは、電源投入後に開始することもできる。ＴＨＳＭのセキュアブートが完了すると、その結果のドメインの構築は、最初など、初期の電源オン時にプラットフォームの状態、またはデバイスがすでにブートアップされ、次いで電源が落とされたときの前の状態を反映する内容を持つ構成ファイルによって決定されうる。したがって、デバイスは、ＴＤ_DM構築、「手つかずの」ＴＤ_DO、および「手つかずの」ＴＥ_U状態を含む基本構成をとる可能性がある。あるいは、ＷＴＲＵは、後の構成、例えば、前のブートアップおよびＴＤ_DM、「ポストＲＴＯ」ＴＤ_DO、および「ポストＲＴＯ」ＴＥ_U状態を含むドメイン構築もしくはＲＴＯプロセスに基づく構成をとることができる。別の代替的形態では、ＷＴＲＵは、図２に示されているような、追加のドメインの拡大セットも含む構成をとることができる。そのようなドメインは、前の電源投入セッション時に作成されている可能性があり、また所有権は、前のセッションで行われたすでに実行されているＲＴＯプロセスにより各所有者によって取得されている可能性がある。

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

ＲＴＯの開始は、ＴＤ_DOのＳＤＭが、ＲＯによって、その特定のＲＯによるＲＴＯプロセスの後に請求されることが意図されている「未請求」で、「手つかずの」ドメインに対するＲＴＯを開始することを含むことができる。ユーザーは、ＭＥプラットフォームの電源オン操作を開始することができる。電源オン時に、ＭＥは、これが「アライブ（ａｌｉｖｅ）」になるベースコードの、ＯＭＴＰによって定められたブートなどの「非ＴＣＧ（ｎｏｎ−ＴＣＧ）」「セキュアブート（ｓｅｃｕｒｅ ｂｏｏｔ）」を実行することができる。非ＴＣＧセキュアブートプロセスの一部として、ＭＥのベースコードの完全性を自律的にチェックすることができる。

第３の実施形態を参照すると、ベースコードのブートプロセスの完了後にモバイルトラステッド環境（ＭＴＥ）をロードすることができることがわかる。署名鍵を使用することで、ＭＴＥは、ＭＥプラットフォーム構成の完全性のアテステーションを行うことができる。

ＭＥは、ベースコードをロードした後に、信号を定期的にＴＨＳＭに送信し、最低限の安全な設定でブートしたことを指示することができる。ＴＨＳＭのＤＯのドメインは信号が送信されたときにはまだブートされていない場合があるため、ＭＥは、同じ信号を、異なるランダムなノンス（ｎｏｎｃｅ＿１）とともに、ＴＨＳＭのＤＯのドメインから送り返される確認応答信号を受信するまで送信することができる。この信号は、
Ｄｅｆ）Ｐａｃｋａｇｅ＿１＝“ＭＥ Ｂａｓｅ Ｃｏｄｅ Ｂｏｏｔ ｃｏｍｐｌｅｔｅｄ”ＭＳＧ｜｜ｎｏｎｃｅ＿１｜｜ＩＤ_ME
ＭＥ→ＴＨＳＭ’Ｓ ＴＤ_DO：Ｐａｃｋａｇｅ＿１｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１）］Ｋ_{temp_I}
式４
として表すことができる。

第３の実施形態を参照すると、信号送受信は、
Ｄｅｆ）Ｐａｃｋａｇｅ＿１＝“ＭＥ Ｂａｓｅ Ｃｏｄｅ Ｂｏｏｔ ｃｏｍｐｌｅｔｅｄ＆ＭＴＥ ｌｏａｄｉｎｇ”ＭＳＧ｜｜ｎｏｎｃｅ＿１｜｜ＩＤ_ME
ＭＥ→ＴＨＳＭ’Ｓ ＴＤ_DO：Ｐａｃｋａｇｅ＿１｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１）］Ｋ_{temp_I}
式５
として表すことができることがわかる。

ＴＨＳＭは、「安全に（ｓｅｃｕｒｅｌｙ）」ブートすることができ、したがって、ＴＨＳＭは、そのＤＭのドメイン、「手つかずの」ＤＯのドメイン、ユーザーのドメイン、およびＲＯによって所有されることが意図されているが、まだＲＯによって所有されていないと思われる少なくとも１つの「手つかずの」ドメインをロードしている可能性がある。また、これらのドメインをロードする際に、ドメインのコード状態のそれぞれの完全性を、ドメインのそれぞれの参照完全性基準（ＲＩＭ）と突き合わせてチェックすることができる。チェックは、ＴＣＧ ＭＰＷＧ仕様などの仕様に従って実行されうる。

デバイス所有者のドメイン（ＴＤ_DO）は、ＤＯに対するＲＴＯプロセスをすでに通っている場合に、「事前構成された（ｐｒｅ−ｃｏｎｆｉｇｕｒｅｄ）」構成、または「最後に保存された（後／前ＲＴＯ）（Ｌａｓｔ−ｓａｖｅｄ（ｐｏｓｔ−ｐｒｅｖｉｏｕｓ−ＲＴＯ））」構成のいずれかに合わせてロードすることができる。ＤＯのドメインは、ロードされるときに、システム全体のドメインマネージャ（ＳＤＭ）を含むことができる。ＳＤＭは、他のリモート所有者（ＲＯ）に属すドメインの構築またはロードおよびメンテナンスを監視することができる。ＳＤＭは、ＤＭのドメインからの「ドメインに対して利用可能なリソースのリスト（ｌｉｓｔ ｏｆ ｒｅｓｏｕｒｃｅｓ ａｖａｉｌａｂｌｅ ｆｏｒ ｄｏｍａｉｎｓ）」を調べることができ、ＴＤ_DOが保護する、システム全体のドメインポリシー（ＳＤＰ）を調べることもできる。

ブート時に、ＳＤＭは、ＴＨＳＭの人間のユーザーまたは人間の所有者（ＤＯ）に「構築することができるドメインのリスト」をプロンプトとして表示し、構築するドメインを選択する入力を要求することができる。ユーザーまたは所有者からその入力を取得した後、ＳＤＭは、人間の所有者またはユーザーからの応答で指定されたドメインのみを構築する作業を進めることができる。ＳＤＭは、これらのトランザクションに対するユーザーインターフェース（ＵＩ）を提供するためにＭＥとインタラクティブにやり取りすることができる。

セキュアブートの後、ＴＨＳＭのＴＤ_DOは、「ＴＨＳＭブート完了」メッセージをＭＥに送信することができる。ＴＤ_DOは、このメッセージ内に、ロードされるＲＯのドメインの数および名前などの、ドメインの現在状態の外部開示可能な要約を含めることもできる。ＴＤ_DOのＳＤＭは、ドメインの現在状態の要約の外部への開示の範囲を決定して強制することができ、そのような決定は、ＳＤＰ、および／またはＴＨＳＭおよび／またはＭＥ上のドメインのドメイン固有のポリシー（ＤＰ）に基づくものとしてよい。ＴＤ_DOは、このメッセージ内のＰａｃｋａｇｅ＿１を受け取ったことを、ＳＨＡ−Ｘ完全性チェックコード入力の一部として受信したｎｏｎｃｅ＿１を含めることによって確認することができ、これは、以下のように表すことができる。
Ｄｅｆ） Ｐａｃｋａｇｅ＿２＝“ＴＨＳＭ ｂｏｏｔ ｃｏｍｐｌｅｔｅｄ”ＭＳＧ｜｜ｎｏｎｃｅ＿２｜｜ＩＤ_THSM
ＴＤ_DO→ＭＥ：Ｐａｃｋａｇｅ＿２｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１｜｜ｎｏｎｃｅ＿１）］_{Ktemp_I}
式６

ＩＤ_THSMなどのＴＨＳＭのＩＤは、ＤＭのドメインＴＤ_DM内に保持することができ、またＴＤ_DMのＩＤと同等であるものとしてよい。ＤＯのドメインＴＤ_DOは、それをＴＤ_DMからフェッチして、式６においてＰａｃｋａｇｅ＿２を構成することができる。

「ＴＨＳＭブート完了」信号に応答して、ＭＥは引き続きそのブートプロセスを完了させることができる。そのブートプロセスを完了した後、ＭＥは、ＴＨＳＭのＴＤ_DOに、
Ｄｅｆ） Ｐａｃｋａｇｅ＿３＝“ＭＥ ｂｏｏｔ ｃｏｍｐｌｅｔｅｄ”｜｜ｎｏｎｃｅ＿３
ＭＥ→ＴＤ_DO：Ｐａｃｋａｇｅ＿３｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿３｜｜ ｎｏｎｃｅ＿２）］_{Ktemp_I}
式７
として表すことができるメッセージを送信することができる。

以下は、ＤＯのドメインのＳＤＭが現在「手つかず」であるＲＯのドメインに対するＲＴＯプロセスを開始し、監視する場合に適用される。

ＴＤ_DOがＭＥからＰａｃｋａｇｅ＿２を受信した後、ＲＴＯプロセスを開始することができる。ＴＤ_DO内のシステム全体のドメインマネージャは、「手つかずの」ターゲットＲＯのドメイン（ＴＤ＊_{RO_Target}）にＲＴＯプロセスを起動するように要求することによってＲＴＯプロセスを開始することができる。ＳＤＭは、自律的に、または人間の所有者もしくはユーザーによって促されたときに、このプロセスを開始することができる。ＳＤＭは、ＴＤ＊_ROに、ターゲットＲＯに対するＲＴＯプロセスを起動する要求を送信することができる。この要求には、ＲＯのＩＤまたはネットワークアクセス識別子（ＮＡＩ：Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｉｄｅｎｔｉｆｉｅｒ）など、ターゲットＲＯの素性を示すもの、および現在の要求の有効期間を含めることができる。要求の一部として、またはその要求に同伴する別のパッケージとして、ＳＤＭは、「許可されたＲＯのドメインに対するＳＤＰの条件（ＳＤＰ’ｓ Ｃｏｎｄｉｔｉｏｎｓ ｆｏｒ Ａｌｌｏｗｅｄ ＲＯ’ｓ Ｄｏｍａｉｎｓ）」（以下、ＳＣＡＲＤと称する）のリストも送信することができる。ＳＤＭは、意図されたＲＴＯプロセスの後に完了するときにＴＤ_ROに対する「ターゲットドメインプラン（Ｔａｒｇｅｔ Ｄｏｍａｉｎ Ｐｌａｎ）」を送信することもできる。このメッセージングは、
Ｄｅｆ） Ｐａｃｋａｇｅ＿４ａ＝Ｒｅｑｕｅｓｔ＿ｔｏ＿ｓｔａｒｔ＿ＲＴＯ｜｜ＳＣＡＲＤ｜｜Ｔａｒｇｅｔ Ｄｏｍａｉｎ Ｐｌａｎ｜｜ｎｏｎｃｅ＿４
ＳＤＭ→ＴＤ＊_{RO_Target}：Ｐａｃｋａｇｅ＿４ａ｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿４ａ）］_{Ksign_SDM}
式８
として表すことができる。

ＴＤ＊_{RO_Target}は、Ｐａｃｋａｇｅ＿４を受信したことに対する応答として、その要求を受け入れるか、または拒絶することができる。この要求は、ＲＯにＲＯのドメインの所有権を取らせるための「オファー（ｏｆｆｅｒ）」として解釈されうる。ＴＤ＊_{RO_Target}は、事前構成された基準、またはロードされたそれ自身の「手つかずの」バージョンのＲＯのドメインポリシーに基づいて決定を下すことができる。ＴＤ＊_{RO_Target}は、ＲＴＯ、ＳＣＡＲＤ、およびターゲットドメインプランを開始する要求を調べて、実際のターゲットのリモート所有者が不在の場合に、実際のターゲットのリモート所有者のために、そのような決定を下すように構成されうる。これは、
Ｄｅｆ） Ｐａｃｋａｇｅ＿５ａ＝Ｏｋａｙ（ｏｒ Ｎｏｔ＿Ｏｋａｙ）＿ｔｏ＿ｓｔａｒｔ＿ＲＴＯ｜｜ｎｏｎｃｅ＿５ａ
ＴＤ＊_{RO_target}→ＳＤＭ：
Ｐａｃｋａｇｅ＿５ａ｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿５ａ）｜｜ｎｏｎｃｅ＿４］_{Ksign_TD*RO_target}
式９
として表すことができる。

「手つかずの」ターゲットＲＯのドメイン（ＴＤ＊_{RO_Target}）が、このプロセスを開始することができる。ＴＤ＊_{RO_Target}は、ＳＤＭにＲＴＯプロセスに対する「最終ドメインプラン（Ｆｉｎａｌ Ｄｏｍａｉｎ Ｐｌａｎ）」をアラートすることができる。ＳＤＭは、その要求を認めるか、または拒絶することができる。ＳＤＭがその要求を認めた場合、ＴＤ＊_ROはＲＴＯプロセスを起動することができ、これは
Ｄｅｆ） Ｐａｃｋａｇｅ＿５ｂ＝Ｉｎｔｅｎｄ＿ｔｏ＿ｓｔａｒｔ＿ＲＴＯ｜｜Ｆｉｎａｌ Ｄｏｍａｉｎ Ｐｌａｎ｜｜ｎｏｎｃｅ＿５ｂ
ＴＤ＊_{RO_Target}→ＳＤＭ：
Ｐａｃｋａｇｅ＿５ｂ｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿５ｂ）］_{Ksign_TD*RO_Target}
式１０
として表すことができる。

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

ＳＤＭは、ＴＨＳＭ上で複数のドメインを構築または維持するために利用可能である、仮想マシンのスレッドのためのメモリもしくはコンピューティングリソースなどのリソースが十分にあるかどうか、ＴＨＳＭ内のドメインの現在状態が「望ましいドメイン」リストで指定された状態と一致しているかどうか、「望ましいドメイン」内の新規ドメインの構築またはロードが、ＴＨＳＭ内のドメインの現在状態によってサポート可能であり、またＳＤＰの下で許されるかどうか、またはドメインの１つまたは複数がＲＴＯプロセスを通る必要があるかどうかを評価することもできる。

ＳＤＭが、利用可能なリソース、ＴＨＳＭの既存のドメインの現在状態、およびＳＤＰに従ってＴＤ＊_{RO_Target}がＲＴＯプロセスを通ると判定した場合、ＳＤＭは、この判定（ＴＤ＊_{RO_Target}）を示して、ＴＤ＊_{RO_Target}およびその周囲のドメインの評価のためにＲＴＯプロセス実行時にＲＯに多数の完全性アテステーション回送する準備をする作業を続けることができる。これは、
Ｄｅｆ） Ｐａｃｋａｇｅ＿６＝Ｏｋａｙ＿ｔｏ＿ｇｏ＿ａｈｅａｄ＿ｗｉｔｈ＿ＲＴＯ｜｜ｎｏｎｃｅ＿６
ＳＤＭ→ＴＤ＊_{RO_Target}：
Ｐａｃｋａｇｅ＿６｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿６）｜｜ｎｏｎｃｅ＿５（ａ ｏｒ ｂ）］_{Ksign_SDM}
式１１
として表すことができる。

ＳＤＭは、人間のユーザーに対して、例えば、ＷＴＲＵ上に表示されるメッセージによって特定のドメインに対するＲＴＯプロセスを開始しようとしていることを知らせることができる。ＳＤＭは、「ＲＴＯプロセスを起動する望ましいドメインおよび望ましいＲＯ（ｄｅｓｉｒｅｄ ｄｏｍａｉｎｓ ｔｏ ｓｔａｒｔ ｔｈｅ ＲＴＯ ｐｒｏｃｅｓｓ ａｎｄ ｔｈｅ ｄｅｓｉｒｅｄ ＲＯ）」のリストをプロンプトとして人間のユーザーもしくは人間の所有者（ＤＯ）に示し、そのプロンプトへの応答として所有者もしくはユーザーが指定するＲＯのドメインのみに対してＲＴＯプロセスを開始する作業を続けることもできる。ＳＤＭは、これらのトランザクションに対するユーザーインターフェース（ＵＩ）を構成するＭＥとインタラクティブなやり取りをすることができる。

ＴＤ＊_{RO_Target}は、ＳＤＭに、ＴＨＳＭプラットフォーム完全性アテステーション（ＴＰＩＡ）およびＴＨＳＭプラットフォーム環境要約（ＴＰＥＳ）を作成するために使用することができる資料を準備するように要求することができる。これは、
Ｄｅｆ） Ｐａｃｋａｇｅ＿７＝Ｒｅｑｕｅｓｔ＿ｆｏｒ＿ＴＰＩＡ｜｜Ｒｅｑｕｅｓｔ＿ｆｏｒ＿ＴＰＥＳ｜｜ｎｏｎｃｅ＿７
ＴＤ＊_{RO_Target}→ＳＤＭ：
Ｐａｃｋａｇｅ＿７｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿７）｜｜ｎｏｎｃｅ＿６］_{Ksign_TD*RO_Target}
式１２
として表すことができる。

第３の実施形態を参照すると、要求は、
Ｄｅｆ） Ｐａｃｋａｇｅ＿７ａ＝Ｒｅｑｕｅｓｔ＿ｆｏｒ＿ＴＰＩＡ｜｜Ｒｅｑｕｅｓｔ＿ｆｏｒ＿ＴＰＥＳ｜｜Ｒｅｑｕｅｓｔ ｆｏｒ ＭＰＩＤ｜｜Ｒｅｑｕｅｓｔ ｆｏｒ ＭＰＥＳ｜｜ｎｏｎｃｅ＿７ａ
ＴＤ＊ＲＯ＿Ｔａｒｇｅｔ→ＳＤＭ：
Ｐａｃｋａｇｅ＿７ａ｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿７ａ｜｜ｎｏｎｃｅ＿６）］Ｋｓｉｇｎ＿ＴＤ＊ＲＯ＿Ｔａｒｇｅｔ
式１３
として表すことができることがわかる。

ＴＰＩＡおよびＴＰＥＳの要求では、ＲＯは、ＳＤＭから探すＴＰＩＡおよびＴＰＥＳに関する情報の種類を指定することができる。例えば、ＴＰＩＡについては、完全性の検証を望んでいる、それ自身とは別の、ドメインの名前または範囲を指定することができる。同様に、ＴＰＥＳについては、ＲＯは、それ自身とは別のドメインの所有者の、ネットワーク割り当て識別子（ＮＡＩｓ：Ｎｅｔｗｏｒｋ Ａｌｌｏｃａｔｉｏｎ Ｉｄｅｎｔｉｆｉｅｒｓ）などの、公開ＩＤを指定することが可能である。

第３の実施形態を参照すると、ターゲットＲＯは、ＭＥプラットフォームの完全性に関する情報（これ以降ＭＰＩＤと称する）およびＭＥ環境に関する他の情報を要求することもできる。あるいは、ＲＯは、ＭＴＥがロードされ、ＭＰＩＤおよびＭＰＥＳがＭＥによってＳＤＭに送信されたことを示す単純な指標を要求することもできる。ＭＴＥ、つまりＭＥプラットフォームに置かれている信頼できるエンティティは、ＳＤＭによってそうするように要求されたときに値ＭＰＩＤおよびＭＰＥＳを準備することができる。この要求は、
Ｄｅｆ） Ｐａｃｋａｇｅ＿７ｂ＝Ｒｅｑｕｅｓｔ ｆｏｒ ＭＰＩＤ｜｜Ｒｅｑｕｅｓｔ ｆｏｒ ＭＰＥＳ｜｜ｎｏｎｃｅ＿７ｂ
ＳＤＭ→ＭＴＥ：
Ｐａｃｋａｇｅ＿７ｂ｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿７ｂ）］Ｋｓｉｇｎ＿ＳＤＭ
式１４
として表すことができる。

ＭＴＥは、ＭＥから構成データを収集し、ＭＰＩＤを構築することができる。ＭＥプラットフォーム環境調査（ＭＰＥＳ）を行うために、環境データも取得することができる。これらの値は、時間の経過とともに変化する可能性のある現在のＭＥ状態に基づいていてもよい。更新された値は、もしＭＥ状態の変化の後に将来の要求がなされるのであればＳＤＭに送信されうる。一般に、ＭＴＥは、ＳＤＭに、
Ｄｅｆ） Ｐａｃｋａｇｅ＿８ａ＝ＭＰＩＤ｜｜ＭＰＥＳ｜｜Ｃｅｒｔ_MTE
ＭＴＥ→ＳＤＭ：
Ｐａｃｋａｇｅ＿８ａ｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿８ａ｜｜ｎｏｎｃｅ＿７ｂ）］Ｋｓｉｇｎ＿ＭＴＥ
式１４
として表すことができる応答を送信することができる。

ＭＴＥは、公開鍵Ｋ_{MTE_Pub}を含む、ＣＡによって署名されうる、証明書を提供することができる。そのため、ＳＤＭはＣＡ署名の検証を通じてこの公開鍵の真正性を検証し、これにより、ＭＴＥからのメッセージの完全性をＫ_{MTE_Pub}でチェックすることができる。ＳＤＭは、ＴＰＩＡおよびＴＰＥＳを準備し、後で、これらをＴＤ＊_{RO_Target}に回送することができる。

ＴＰＩＡの準備のために、ＳＤＭは、「手つかずの」ＴＤ_ROの、「手つかずの」ＴＤ_ROによる完全性アテステーション、ＴＥ_DMの、ＴＥ_DMによる完全性アテステーション、ＴＥ_DOの、ＴＥ_DOによる完全性アテステーション、ＴＥ_Uの、ＴＥ_Uによる完全性アテステーション（デバイスユーザーがＤＯと異なる場合）、およびＲＯが注目している他の既存のＴＤ_ROの、またそのＴＤ_ROによる完全性アテステーションなどの完全性アテステーションを収集することができる。

あるいは、ＳＤＭは、ＰＣＲから完全性値を収集した後、コードおよびデータなどの、測定ログのローカルにおける自律的チェックおよび再計算のプロセスによって、各ドメインに対するＰＣＲからのダイジェスト値と突き合わせてドメインを検証することができる。これは、ＴＴＰ（ＰＣＡ）が各ドメインを含むべきである最新のコードを認識しないときに実行することができ、ＴＴＰは、ＷＴＲＵ上で、ＴＰＭ、またはＭＴＭに対し認定されているＡＩＫにリンクした署名鍵を認定することができる。ＴＴＰは、ＲＯがＳＤＭからのＴＰＩＡを比較するために使用することができるダイジェスト基準に対する参照値を提供するようには構成されえない。ＳＤＭは、ドメインに対するコードのダイジェストを再計算し、見積もられたＰＣＲ値と比較することによって、ドメインに対し得られるＰＣＲ見積もりが最新のものであるかどうかをローカルでチェックすることができる。次いで、このローカルでのチェックに通ったことを条件として、ＳＤＭは、ＴＰＩＡに署名し、これをＴＤ_{RO_target}に受け渡し、またＭＴＥ、もしくはＭＥによりＲＯ_targetに受け渡すことができる。

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

ＴＰＩＡは、測定ログがある場合もない場合も、ＰＣＲ見積もりが行われるときの「ローカルの時間（ｌｏｃａｌ ｔｉｍｅ）」を示す情報も含むことができ、個別のドメインに対するダイジェストの見積もりに効果的にタイムスタンプを付けることができる。これは、ドメインのＰＣＲダイジェストのそれぞれが最後にＳＤＭによって取得された時間を示すある種の情報となる。測定ログがＲＯに送信されない場合、ＰＣＲのタイムスタンプを付けた見積もりは、ローカルのダイジェストが取得され、ＴＰＩＡに含まれる時間がアテステーション検証において使用できるほど十分に最近であるかどうかを決定することに関して、ＴＰＩＡに示されているアテステーションを検証する必要があるときにＲＯへの何らかの追加情報を提供することができる。そのようなタイムスタンプに使用されるクロックは、信頼に足るクロックであるものとしてよい。

３方向検証が失敗した場合、ＲＯは、ＴＴＰがそれに、望ましいダイジェストから計算することができる更新された参照基準または測定ログを提供するよう要求することができる。ＲＯは、３方向検証をリトライすることができる。検証が成功した場合、ＲＴＯが続行される。検証が失敗し、成功する３方向検証がＲＯポリシーによって必要とされる場合、ＲＴＯを終了することができる。

ＤＯドメインの完全性アテステーションに関して、ＳＤＭは、ＳＤＭの固有の機能などを通じて、自律的にそれを取得することができる。完全性アテステーションでは、ＤＯのドメインのアテステーションを除き、ＳＤＭは、他の各ドメインに、各自の完全性アテステーションを行い、それに署名するよう要求することができる。ＳＤＭは、その要求に、ＳＤＭがドメインに完全性アテステーションを要求し、取得する権限を有しているかチェックするために受け取り側が使用することができる、トークンなどの許可データを含めることができる。要求は、ターゲットＲＯ（Ｔａｒｇｅｔ ＲＯ）およびターゲットＲＯの要求の回送者としてのＳＤＭが、受け取り側のドメインの完全性をチェックするために必要とする受け取り側のドメインのプラットフォーム構成レジスタ（ＰＣＲ）の範囲も含むことができる。この要求は、
Ｄｅｆ） Ｐａｃｋａｇｅ＿８ｂ（ｉ）＝Ｒｅｑｕｅｓｔ＿ｆｏｒ＿Ａｔｔｅｓｔａｔｉｏｎ｜｜ｎｏｎｃｅ＿８ｂ（ｉ），ｉ＝１，２，．．．，Ｎ
ＳＤＭ→ＴＤ_Domain(i)：
Ｐａｃｋａｇｅ＿８ｂ（ｉ）｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿８ｂ（ｉ））］_{Ksign_SDM}
式１５
として表すことができる。

ＮをＳＤＭによるＰＣＲ値の収集元のドメインの数として、ｄｏｍａｉｎ（ｉ），ｉ＝１，２，．．．，Ｎと表されるドメインのそれぞれは、最初に、アテステーションの要求の中の許可データをチェックし、次いで、アテステーションの要求において指定されているようなＰＣＲの範囲のＰＣＲ値をフェッチする。このオペレーションは、
Ｄｅｆ） Ｐａｃｋａｇｅ＿８ｃ（ｉ） ＝
Ｖａｌｕｅｓ ｏｆ ｔｈｅ ｓｐｅｃｉｆｉｅｄ ｒａｎｇｅ ｏｆ ＰＣＲｓ｜｜ｎｏｎｃｅ＿８ｃ（ｉ），ｉ＝１，２，．．，Ｎ
ＴＤ_Domain（ｉ）→ＳＤＭ：
Ｐａｃｋａｇｅ＿８ｃ（ｉ）｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿８ｃ（ｉ）｜｜ｎｏｎｃｅ＿８ｂ（ｉ）］_{Ksign_TD_Domain(i)}
式１６
として表すことができる。

ＳＤＭは、ＴＨＳＭプラットフォーム完全性アテステーション（ＴＰＩＡ）を実行して、すべてのアテステーションを連結し、それに、署名鍵で署名することができる。これは、
Ｄｅｆ） ＴＰＩＡ＝Ｃｏｎｃａｔｅｎａｔｉｏｎ｛ｓｉｇｎｅｄ ＰＣＲ ｖａｌｕｅｓ ｆｒｏｍ Ｄｏｍａｉｎ（ｉ）｝，ｉ＝１，２，．．．，Ｎ
式１７
と表すことができる。

ＴＰＥＳの準備のため、ＳＤＭは、ＤＭのドメインから取得することができるＴＨＳＭ ＨＷおよびＳＷ構成およびバージョン番号、ＢＩＯＳ構成、プラットフォーム上のドメインの個数、現在のドメインのために使い切ったメモリなどの総プラットフォームリソース、既存のもしくは新規のドメインのさらなる構築もしくは拡張のため残してあるプラットフォームリソース、ドメインの名前、またはそれらの所有者の、ＮＡＩなどの、名前もしくはＩＤ（各ドメイン所有者によって許可されている場合）、日時、または上記の環境情報がＳＤＭによって収集された場合に日時ではなく利用可能であれば単調カウンタ値、他の任意の関連する情報など、ＴＤ_DM、ＴＤ_DO、およびＴＤ_Domains(i)から集める情報を連結することによってＴＰＥＳを生成することができる。この要求は、
Ｄｅｆ） ＴＰＥＳ＝｛ｃｏｌｌｅｃｔｅｄ ｉｎｆｏｒｍａｔｉｏｎ｝
式１８
で表すことができる。

ＳＤＭは、ＴＰＩＡおよびＴＰＥＳに署名し、これらをＴＤ＊_{RO_Target}に回送することができる。ＳＤＭは、ＳＣＡＲＤを調べることができなかった場合にＤＯが手つかずのＴＤ＊_{RO_Target}に依存する必要のないように署名されたＳＣＡＲＤを含めることもできる。ＳＣＡＲＤを、ＴＰＩＡおよびＴＰＥＳとともに、ＲＯに送信することができ、これにより、ＲＯは、ＳＣＡＲＤ、ＴＰＩＡ、およびＴＰＥＳを調べた後に所有権取得を進める決定を下すことができる。このメッセージングは、
ＳＤＭ→ＴＤ_{RO_Target}：
ＳＣＡＲＤ｜｜ｎｏｎｃｅ＿８ｆｂ｜｜［ＳＨＡ−Ｘ（ＳＣＡＲＤ）｜｜ｎｏｎｃｅ＿８ｆｂ）］_{Ksign_SDM}
ＴＰＩＡ｜｜Ｃｏｎｃａｔｅｎａｔｉｏｎ｛ｎｏｎｃｅ＿８ｃ（ｉ）｝［ＳＨＡ−Ｘ（ＴＰＩＡ）｜｜Ｃｏｎｃａｔｅｎａｔｉｏｎ｛ｎｏｎｃｅ＿８ｃ（ｉ）｝］_{Ksign_SDM}
ＴＰＥＳ｜｜ｎｏｎｃｅ＿８ｆ｜｜［ＳＨＡ−Ｘ（ＴＰＥＳ｜｜ｎｏｎｃｅ＿８ｆ）］_{Ksign_SDM}
または
ＳＣＡＲＤ｜｜ＴＰＩＡ｜｜ＴＰＥＳ｜｜［ＳＨＡ−Ｘ（ＳＣＡＲＤ｜｜ＴＰＩＡ｜｜ＴＰＥＳ｜｜ｎｏｎｃｅ＿８ｆ）］_{Ksign_SDM}
式１９
として表すことができる。

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

ＴＳＩＭ機能に使用される証明書は２つ以上ありうる。１つは手つかずのＴＳＩＭ機能に対するもの（ＣＥＲＴ＊_TSIM）であり、他は、完全にインスタンス化または更新されている機能に対するものである。手つかずのＴＳＩＭ機能の証明書は、ＤＭに対する証明書構造にモジュール方式で埋め込むことができ、例えば、ＤＭからの機能である手つかずのドメイン内にプラグインとして差し込むことができる。

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

コンテンツは、ＴＤ＊_{RO_Target}によって使用される前に、手つかずのＴＤ＊_{RO_Target}がロードされたときにターゲットＲＯがすでに知られている場合に、例えば証明書転送によって、または事前構成によってすでに利用可能になっていると思われる、ターゲットＲＯの公開鍵（Ｋ＿Ｔａｒｇｅｔ＿ＲＯ＿ｐｕｂ）で暗号化することができる。ＴＳＩＭは、署名鍵Ｋ＿_TSIM-Signとともに事前に用意することができる。この秘密署名鍵の公開鍵は、ターゲットＲＯに事前に配布することができる。ＩＤ_MEは、ＭＥ ＩＤを安全に保持するＴＨＳＭ ＤＭドメインＴＤ_DMからＴＤ＊_{RO_Target}が取得するＭＥのＩＤである。これは、
Ｄｅｆ） Ｐａｃｋａｇｅ＿９＝ＳＣＡＲＤ｜｜ＴＰＩＡ｜｜ＴＰＥＳ｜｜Ｐ｜｜Ｒｅｑｕｅｓｔ＿ＴＯ｜｜Ｃｅｒｔ_TSIM｜｜ＩＤ_ME｜｜ｎｏｎｃｅ＿９
ＴＤ＊_{RO_Target}→ＭＥ：
｛Ｐａｃｋａｇｅ＿９｝_{K_Target_RO_Pub}｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿９）］_{K_TSIM-SIGN}
式２０
として表すことができる。

第３の実施形態を参照すると、値ＭＰＩＡおよびＭＰＥＳをメッセージに追加することができることがわかる。ＭＰＩＡは、ＭＴＥによってコンパイルされた構成データ（ＭＰＩＤ）に基づきＴＨＳＭにおいて計算されたダイジェストを含むことができる。このダイジェストのアテステーションは、構成ファイル内にすでに存在しているか、またはＤＭとのリアルタイムの通信を介して配信された取得済みの認定された基準を使ってチェックする場合にのみ行うことができる。完全性および環境情報に対するＲＯ要求によれば、式２０は、ＳＤＭがＭＰＩＤおよびＭＰＥＳを正常に受信したことを示す単純な指示を含むことができる。これは、
Ｄｅｆ） Ｐａｃｋａｇｅ＿９＝ＳＣＡＲＤ｜｜ＴＰＩＡ｜｜ＴＰＥＳ｜｜ ＭＰＩＡ ｜｜ ＭＰＥＳ｜｜Ｐ｜｜Ｒｅｑｕｅｓｔ＿ＴＯ｜｜Ｃｅｒｔ_TSIM｜｜ＩＤ_ME｜｜ｎｏｎｃｅ＿９
ＴＤ＊_{RO_Target}→ＭＥ：
｛Ｐａｃｋａｇｅ＿９｝_{K_Target_RO_Pub}｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿９）］_{K_TSIM-SIGN}
式２１
として表すことができる。

ＭＥは、上記のメッセージ全体をＲＯに転送することができ、これは
ＭＥ→Ｔａｒｇｅｔ ＲＯ：
｛Ｐａｃｋａｇｅ＿９｝_{K_Target_RO_Pub}｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿９）］_{K_TSIM-SIGN}
式２２
として表すことができる。

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

ＲＯは秘密鍵Ｋ_{Target_RO_Priv}を使用してＰａｃｋａｇｅ＿１０を復号し、ＭＥのＩＤをチェックし、メッセージを解釈する。ＲＯは、ＳＣＡＲＤを解釈して、ＳＤＰからのそれらの条件に「合意（ａｇｒｅｅ）」できるか調べることができる。ＲＯがＳＣＡＲＤに合意した場合、例えば、手つかずのＴＤ＊_{RO_Target}からの値ＴＰＩＡ を解釈して、サービス資格証明または構成制御がターゲットＲＯのドメインＴＤ＊_{RO_Target}に与えられる前に初期ＴＳＩＭ状態全体を表すことができる。値Ｐは、ユーザーが望んでいるサービスを示すものとして解釈することができる。ＴＳＩＭ対応ＴＤ＊_{RO_Target}の場合にＭＮＯとすることもできる、ターゲットＲＯは、ＴＴＰと無関係に取得した参照完全性基準（ＲＩＭ）値（ＲＩＭ_RO）と比較することによってＴＰＩＡに示されているように注目するドメインの完全性を検証することができる。

ＭＮＯは、例えばＴＴＰにＷＴＲＵ／ＴＨＳＭの供給者によって提供される証明書を通じてＴＰＩＡの予想値を知る機能を有するものとしてよい。第３の実施形態を参照すると、ＭＰＩＡおよびＭＰＥＳの予想値は、ＴＨＳＭによってそれが信頼に足るかどうかのアテステーションが行われている場合に、ＭＴＥが信頼できるエンティティであるという事実によって可能にされる認証プロセスを通じて前もって知ることができることがわかる。

ターゲットＲＯは、受け取ったＴＰＥＳを調べ、ＲＯがＲＴＯプロセスをさらに進めることができるという背景状況において例えばＴＰＥＳによって表されるような「周囲システム環境（ｓｕｒｒｏｕｎｄｉｎｇ ｓｙｓｔｅｍ ｅｎｖｉｒｏｎｍｅｎｔ）」がターゲットＲＯにとって「合意可能（ａｇｒｅｅａｂｌｅ）」であるＴＨＳＭシステム内にＴＤ＊_{RO_Target}があるかどうかを評価することができる。
ＴＰＩＡ、ＴＰＥＳ、目的Ｐ、Ｒｅｑｕｅｓｔ＿ＴＯ、ならびに第３の実施形態を参照して、ＭＰＩＡおよびＭＰＥＳをチェックした後、ＭＮＯなどのターゲットＲＯは、ターゲットＲＯによって「所有権が取得される（ｔａｋｅｎ ｏｗｎｅｒｓｈｉｐ）」ことを要求している手つかずのＴＤ＊_{RO_Target}、さらには、ＴＤ＊_{RO_Target}を含む、全体としてＴＨＳＭが、ＲＴＯプロセスについてターゲットＲＯをさらに進行させるのに、またＴＤ＊_{RO_Target}がターゲットＲＯとインタラクティブにやり取りしていくつかの事前に指定されている基本サービスを提供することをターゲットＲＯに認めさせるのに十分「信頼に足る（ｔｒｕｓｔｗｏｒｔｈｙ）」と判定することができる。

ＴＤ＊_{RO_Target}の所有権取得を実行して、ドメインが後で鍵、より完全な構成、パラメータ、および実行ファイルをダウンロードしてインストールし、基本的な「手つかずの」状態が許容する以上の機能を持たせ、またターゲットリモート所有者（ＲＯ）によって請求または所有され、管理されるようにするために、ターゲットＲＯは、実行ファイルを含みうる構成信号（ＣＯＮＦＩＧ）を送信することができる。ＲＯは、ＴＤ_{RO_Target}が受け取ったＣＯＮＦＩＧに従って構成、パラメータ、および実行ファイルをインストールする場合にインストール後状態と一致しうる、ＲＩＭ_TSIMと称するＴＳＩＭに対するＲＩＭも送信する。ＲＩＭ_TSIMは、ＴＤ＊_{RO_Target}上のセキュアメモリ内に格納することができ、また将来のブート時にＴＳＩＭ機能の完全性をチェックするために使用することができる。採用されるセキュリティ対策さらには他の構成上の課題を指定する、ドメインポリシー（ＤＰ）をトランザクションに含めることができる。

ＲＯ固有のドメインポリシー（ＤＰ）は、ＳＤＭによって保持され、ＴＨＳＭ上の特定のＲＯによって所有される１つまたは複数のドメインを構築し、管理するためのプランを表すシステム全体のドメインポリシー（ＳＤＰ）と異なっていてもよい。ＲＯ固有のＤＰは、その特定のドメインに固有であり、それに限定されるドメイン内アプリケーションおよびセキュリティ対策のみに適用されるポリシーまたはプランを含むことができる。

いくつかのＲＯは、ＤＰがＴＨＳＭ上で他のＲＯが構築または管理されることに「合意可能」であるものに関して制限を課す規定も含むようにＤＰを作成することができる。例えば、移動体通信事業者（ＭＮＯ＿Ａ）は、ＴＨＳＭ上の他のドメインのうちのいくつかのドメインの状態および性質に関するＤＰ_{MNO_A}において指定されている条件のうちのいくつかが十分に満たされていないことが判明した場合に、そのターゲットドメイン（ＴＤ_{MNO_A}）が、ＤＰ_{MNO_A}をダウンロードしインストールした後に、例えば、そのサービスもしくは活動に対する一組の制約条件を適用されるように、自分のＤＰ_{MNO_A}を作成することができる。例えば、ＭＮＯは、ＤＰ_{MNO_A}を実装することができ、これにより、ＴＤ_{MNO_A}は、ＴＤ_{MNO_A}がＴＨＳＭ内のより大きな環境を調査した後にアクティブ化された自らのＴＳＩＭ機能を持つ他のＭＮＯのドメインが同じＴＨＳＭ上にインストールされアクティブ状態にあることを見いだした場合に、そのＴＳＩＭ機能を無効にする。

ＴＤ＊_{RO_Target}は、Ｐにおける要求されたサービスに対応する形でそれ自身を構成することが必要になる場合がある。例えば、ＲＯは、ＭＥに応答を送信することができ、メッセージの機密は、公開鍵Ｋ_{TSIM_Pub}を使用して保護される。ＭＥは、このメッセージをＴＨＳＭ上のＴＤ＊_{Target_RO}に転送することができる。Ｃｅｒｔ_ROはＴａｒｇｅｔ＿ＲＯの公開鍵Ｋ＿ＲＯ−_privを含むものとしてよい。ＲＯは、このときに、ＴＳＩＭの参照完全性基準（ＲＩＭ）を送信することができる。ＲＯの応答は、
Ｄｅｆ） Ｐａｃｋａｇｅ＿１０＝
｛ＣＯＮＦＩＧ，ＤＰ_RO，ＩＤ_RO，ＲＩＭ_TSIM｝Ｋ_TSIM-Pub｜｜Ｃｅｒｔ_RO｜｜Ｃｅｒｔ_TSIM｜｜ｎｏｎｃｅ＿１０
Ｔａｒｇｅｔ ＲＯ→ＭＥ：
｛Ｐａｃｋａｇｅ＿１０｝_{K_RO-Priv}｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１３｜｜ｎｏｎｃｅ＿９）］_{K_TSIM-SIGN}
式２３
ＭＥ→ＴＤ＊_{Target RO}：
｛Ｐａｃｋａｇｅ＿１０｝_{K_RO-Priv}｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１３｜｜ｎｏｎｃｅ＿９］_{K_TSIM-SIGN}
式２４
として表すことができる。

ＴＤ＊_{RO_Target}は、公開鍵Ｋ_TSIM-Privでメッセージを復号し、ＣＡでその証明書をチェックした後にＣｅｒｔ_ROにおいて公開鍵Ｋ_{RO_Pub}を使用してＲＯ署名を検証することができる。これは、ＴＳＩＭアプリケーションに対する受け取った参照完全性基準ＲＩＭ_TSIMを安全に格納することができる。これは、ＩＤ_ROからのＲＯのＩＤをチェックし、次いで、ＲＯのポリシーＤＰ_ROをチェックし、ＣＯＮＦＩＧの構成およびインストールの残り部分を続けることができるかどうかを決定することができる。ＴＤ＊_{RO_Target}は、ＣＯＮＦＩＧを介して再構成を実行し、「完了（ｃｏｍｐｌｅｔｅ）」ドメイン状態に到達することができ、次いで、セルフテストを実行しＴＳＩＭ機能の測定された基準がネットワークによって通信され、ＲＩＭ_TSIMにおいて表されているものと一致するかどうかを判定する。ドメインＴＤ_{RO_Target}は、これで「完了した（ｃｏｍｐｌｅｔｅｄ）」となり、もはや「手つかず」ではなくなり、したがって表記中のアスタリスク＊を取り外す。これは、
ＴＤ＊_{Target_RO}：ｃｈｅｃｋ ＤＰ_RO，ｓｔｏｒｅ ＲＩＭ_TSIM，ａｎｄ ｉｎｓｔａｌｌ ＣＯＮＦＩＧ．
→
ＴＤ_{Target_RO}：ＲＯ’ｓ ｄｏｍａｉｎ ｉｓ “ｃｏｍｐｌｅｔｅ”．
式２５
として表すことができる。

完了したドメインＴＤ_{Target_RO}は、「ＲＴＯ成功およびドメイン完了」ステータスメッセージをＭＥに送信し、これはターゲットＲＯに回送することができる。これは、
Ｄｅｆ） Ｐａｃｋａｇｅ＿１１＝｛“ｄｏｍａｉｎ ｃｏｍｐｌｅｔｅｄ”｜｜ＩＤ_{RO_Target}｝_{K_RO-Pub}｜｜ｎｏｎｃｅ＿１１
ＴＤ_{Target_RO}→ＭＥ：
Ｐａｃｋａｇｅ＿１１｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１１｜｜ｎｏｎｃｅ＿１０）］_{K_TSIM_SIGN}
式２６
として表すことができる。

適宜、ＭＥは、電話の登録および資格証明ロールアウトが現在可能な状態にあることを示す、例えばＷＴＲＵの画面に表示されるステータスメッセージをユーザーに送信することができる。

ＭＥは、プラットフォームの再構成が正常に完了し、ＴＳＩＭ資格証明の登録をすることが可能な状態であることを示すステータスメッセージをＲＯに回送することができる。ＴＤ_{RO_Target}は「ＴＨＳＭ＿ＴＤ_RO＿ＬＯＡＤ＿ＣＯＭＰＬＥＴＥ」状態に至っている。このメッセージは、
ＭＥ→Ｔａｒｇｅｔ ＲＯ：
Ｐａｃｋａｇｅ＿１１｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１１｜｜ｎｏｎｃｅ＿１０）］_{K_TSIM_SIGN}
式２７
として表すことができる。

このＲＴＯプロトコルは、ＴＨＳＭの所有者またはユーザーとしての加入者を、加入サービスを提供する３Ｇ ＵＭＴＳネットワーク通信事業者に登録するためのプロトコルの先行プロトコルとして使用され、また共有鍵Ｋおよび加入者識別ＩＭＳＩのダウンロードおよび提供を含む、認証および鍵照合（ＡＫＡ）の資格証明のダウンロードおよび提供を行うための後続プロトコルとしても使用されうる。

公開−秘密鍵セットに対する証明書Ｃｅｒｔ_TSIMおよびＣｅｒｔ_ROは、これらが使用されるメッセージに入れて配信することができる。あるいは、ＲＯのドメイン（ＴＤ_RO）およびＲＯは、信頼できる第三者から各証明書を取得することができる。この取得は、
ＴＴＰ→ＭＥ→ＴＤ_RO：Ｃｅｒｔ_RO
ＴＴＰ→ＲＯ：Ｃｅｒｔ_TSIM
式２８
として表すことができる。

別の代替的形態では、ＲＯの証明書Ｃｅｒｔ_ROは、ネットワークからＭＥに配信することができ、ＴＨＳＭの証明書Ｃｅｒｔ_TSIMは、これらが使用されるメッセージの配信の前にＭＥからネットワークに配信することができる。したがって、通信は、本明細書で説明される暗号化されたメッセージの前に送信することができ、これらの通信は、
ＭＥ→ＲＯ：Ｃｅｒｔ_TSIM（ステップ９のメッセージが送信される前）
ＲＯ→ＭＥ：ＣＥＲＴ_RO（ステップ１３のメッセージが送信される前）
式２９
として表すことができる。

これらの代替的証明書配信方法のそれぞれについて、エントリＩＤは、公開暗号鍵が使用されるメッセージに添付することができる。

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

第２の実施形態を参照すると、ＴＨＳＭおよびＭＥは、第１の実施形態のものと異なる場合のあることがわかる。ＴＨＳＭは、ＭＥそれ自体またはＭＴＥなどのＭＥ内の信頼できるエンティティの代わりに、ＭＥがブートするときにＭＥのコードの一部または全部の完全性チェックを実行するように構成されうる。適宜、ＴＨＳＭは、ＭＥのブートコードの一部または全部を格納することもできる。ＴＨＳＭは、ＭＥの完全性のアテステーションを外部のエバリュエータに対して行うようには構成することができない。これは、ブート時にＭＥコードの完全性の「ローカル（ｌｏｃａｌ）」チェックを実行するように構成することができる。

ＭＥに対する完全性値は、ブートアッププロセスで使用することができ、ＲＴＯプロセスでは使用することができない。ＭＥのセキュアブートの結果得られるＭＥコードおよび構成状態を表す、ｍｅａｓ＿ＭＥで表される、ＭＥの完全性測定は、ＴＨＳＭのＤＭのドメインＴＥ_DMによって行うことができる。ＴＨＳＭのＴＤ_DMは、ｍｅａｓ＿ＭＥの有効性をチェックすることができるが、プラットフォームアテステーションに組み込むことはできない。

第４の実施形態を参照すると、ＭＥは、例えばＴＣＧ ＭＰＷＧの意味で、信頼できるＭＥであるものとしてよいことがわかる。ＭＥは、ＭＴＭ（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｍｏｄｕｌｅ）を備えることができ、またＭＴＭをストレージ（ｓｔｏｒａｇｅ）、報告（ｒｅｐｏｒｔｉｎｇ）、測定（ｍｅａｓｕｒｅｍｅｎｔ）、検証（ｖｅｒｉｆｉｃａｔｉｏｎ）、および強制（ｅｎｆｏｒｃｅｍｅｎｔ）のための信頼のルート（ｒｏｏｔ ｏｆ ｔｒｕｓｔｓ）を与える信頼点として有するので信頼することができる。

図４および図４Ａは、リモート所有権取得プロセスの例示的な呼流れ図を示している。例えば、図４および図４Ａは、ＭＥ ４０２、ＴＤ_DO ４０４、ＳＤＭ ４０６、ＴＤ＊_{Target_RO} ４０８、およびターゲットＲＯ ４１０のうちの１つまたは複数の間の例示的な呼を示している。図４および図４Ａの矢印は、発呼側／着呼側を表すものとしてよい。

図２および図３に示されているように、ＳＤＭは、ＴＨＳＭに置かれているシステム全体のドメインマネージャを備え、ＤＯの機能の一部を提供することができる。ＳＤＭは、デバイス内のすべてのドメインセットアップの監視および調整を行い、そのようなすべてのドメインが、ＳＤＰに準拠して、またドメイン固有のポリシーに従って、そのようなポリシーにおける競合を他のドメインのＤＯおよびＲＯの代わりにＳＤＭによる仲裁で解消しようとする限りにおいて、動作し、互いにインタラクティブにやり取りすることを確実にするものとしてよい。ＴＤ_DOは、ＴＨＳＭにおける必須のデバイス所有者ドメインを含むことができる。ＴＤ_DOは、ＳＤＭを含み、したがって、システムレベルのドメインポリシーを維持することができる。ＭＴＥは、ＭＥ側に対するポリシーマネージャＭＥ_PDMを含むことができる。ＭＥ_PDMは、ＭＥ上でポリシーマネージャ機能を実行することができるが、ＴＨＳＭにおけるＳＤＭの監視を受けるものとしてよい。ＭＥ＊_{Target_RO}は、許可されたリモート所有者によるリモート所有権に対して手つかずのドメインのセットアップを含むことができる。ターゲットＲＯは、ＭＥ＊_{Target_RO}の所有権を要求するリモート所有者を含んでいてもよい。

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

図４をなおも参照すると、ベースコードブートは、４１でＭＥ ４０２によって実行されうる。４１５で、ＴＨＳＭは安全にブートすることができる。ＴＨＳＭは、ＳＤＭが含まれる、ＤＯのドメインをロードすることができ、ＳＤＭは、１）ドメイン構築に利用可能なリソース、および／または２）ユーザーへの受け入れ可能なドメインのリストを備えることができる。４２で、ＴＨＳＭはそのブートを完了することができる。４２５で、ＭＥはそのブートを完了することができる。４３で、ＭＥはそのブートが完了していることを示すことができる。このプロセスにおいて、ＤＭのドメインが構築され、オプションのユーザードメイン（ＭＥ_U）も構築され、また利用可能なリソースがチェックされる。ＤＭのドメインは、ＭＥデバイスに対するドメインポリシーの初期構成および仕様を提供するＭＥ_PDMを備えることができる。ＭＥ_DMの事前構成により、このポリシーは、ＭＥドメインとＴＨＳＭドメインとの間の、共通のリモート所有者とともに、ＴＨＳＭ上の一方のドメインとＭＥ上の他方のドメインなど、これらのドメインに対するポリシーに関してＳＤＰのものと整合するようにされうる。

図４をなおも参照すると、事前構成されたドメインを持つ、ＭＥは、４３１で「ブート完了」メッセージを送信し、ＲＴＯを開始することができることがわかる。このメッセージは、ＤＭドメインポリシーおよびＭＥにおいて利用可能なリソースに関する明示的な情報を含みうる。４４で、ターゲットドメインプランを含む、ＲＴＯを開始する要求が送信されうる。４５５で、ＲＴＯ開始要求を受け入れるか、または拒絶する決定を、ＴＤ＊_{Target_RO} ４０８側で下すことができる。４５で、ＲＴＯを開始するかどうかを示すメッセージを送信することができる。あるいは、４５６で、ＲＴＯは、ＴＤ＊_{Target_RO} ４０８から開始することができる。４５１で、ＴＤ＊_{Target_RO} ４０８は、「ＲＴＯ最終ドメインプランを開始する意図」を送信することができる。

ＳＤＭは、ＴＨＳＭのシステム全体のドメインポリシー（ＳＤＰ）を評価し、どのような制約をＭＥドメインに課すか、または割り当てるかを決定することによってＭＥブートメッセージに応答することができる。これらのポリシー制約条件は、ＭＥおよびＴＨＳＭ上で、どのようなドメインがそれらの関連するリモート所有者に従って許容可能であるかを決める条件を含むものとしてよい。ＳＤＭは、リモート所有者が気づいているものを含めて、ＴＨＳＭ上にドメインを有する同じリモート所有者によって所有されるドメインに対してＭＥによる使用が許されるシステム全体のリソースを決定することができる。ＭＥ_PDMは、式７のメッセージを介してこの情報を受信することができる。ＳＤＭは、そのベースポリシーへのポリシー制約条件およびそのリソースリストへの許容可能なリソースを含むこともできる。ＭＥ_PDMが情報を受け取った後、これは、ＭＥ上のリソースおよびドメインの管理に関する決定を下し、強制することに関して、そのようなすべての決定についてＳＤＭから許可を取得しなくてもいくつかの特権を行使することができる。

図４をなおも参照すると、プロセスは４６５に続くことがわかる。４６５で、ＳＤＰ、利用可能なリソース、および／または受け入れ可能なドメインおよび／または状態を、チェックおよび／または評価することができる。４６で、「開始ＯＫ」信号を送信することができる。４７で、ＴＰＩＡ、ＴＰＥＳ、ＭＰＩＤ、およびＭＰＥＳの要求を送信することができる。４７５で、ＳＤＭ ４０６は、例えば、ドメイン毎にＰＣＲの範囲にわたって既存のドメインから完全性アテステーションを収集／連結し、および／またはＴＰＥＳ情報を収集および／または連結することができる。

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

図４Ａを参照し、ＲＴＯプロセスを続けると、４１０で、ＴＰＩＡ｜｜ＴＰＥＳ｜｜ＭＰＩＡ｜｜ＭＰＥＳ｜｜目的｜｜ＲＴＯメッセージがターゲットＲＯ ４１０に送信されうることがわかる。４１８で、ターゲットＲＯ ４１０は、例えば、ＴＰＩＡ、ＴＰＥＳ、ＭＰＩＡ、ＭＰＥＳ、および目的をチェックすること、ＲＩＭＴＤＲＯに対して手つかずのドメインが信頼に足るものかどうかを判定すること、ＤＰの受け入れ可能性をチェックすること、または完了ドメイン状態を構築するＣＯＮＦＩＧを作成することのうちの１つまたは複数を実行することができる。

上記の代替えとして、ＴＤ＊_{Target_RO} ４０８がＭＰＩＡおよびＭＰＥＳの代わりにＭＥが信頼に足るものであることを単純に示す情報をＳＤＭに要求するが、その場合、ＳＤＭは、ＴＰＩＡ、ＴＰＥＳ、およびＭＥの信頼性指示を与える。しかし、ＳＤＭは、それでも、ＭＴＥにＭＰＩＡおよびＭＰＥＳを要求し、ＭＴＥから受け取る。

図４ａをなおも参照すると、４１１で、メッセージＣＯＮＦＩＧ｜｜ＤＰ｜｜ＲＩＭ_TDRO｜｜ＲＯが送信されうることがわかる。４１２で、ＣＯＮＦＩＧ｜｜ＤＰ｜｜ＲＩＭ_TDRO｜｜ＲＯメッセージを転送することができる。４２８で、ドメインを構築し、構成して、完全性をＲＩＭ_TDROに対してチェックすることができる。それに加えて、ＴＤ＊_{Target_RO}の所有権を取得し、そうして、ＴＤ_{Target_RO}に変換することができる。４１３で、ドメイン完了メッセージを送信することができる。４１４で、ドメイン完了メッセージを転送することができる。

図５および図５Ａは、完全なアテステーション（例えば、第４の実施形態に関係する）を伴うリモート所有権取得プロセスの例示的な呼流れ図を示している。例えば、図５および図５Ａは、ＳＤＭ ５０２、ＴＤ_DO ５０４、ＭＥ_PDM ５０６、ＭＥ＊_{Target_RO} ５０８、およびターゲットＲＯ ５１０のうちの１つまたは複数の間の例示的な呼を示している。図５および図５Ａの矢印は、発呼側／着呼側を表すものとしてよい。５１で、ベースコードブート完了メッセージを送信することができる。それに応答して、５１５で、ＴＨＳＭは、ＳＤＭを含む、ＤＯドメインを安全にブートし、ロードすることができる。５２で、ＴＨＳＭブート完了メッセージを送信することができる。それに応答して、５２５で、ＭＥは安全にブートすることができ、これは、ＭＥ_PDMが含まれるＤＭドメインをロードすることと、さらには利用可能なリソースをチェックすることを含みうる。ＭＥ_PDMは、ＳＤＰおよび利用可能なリソースと一致するドメインポリシーを指定する初期構成を行うことができる。５３で、ＤＭのドメイン（ポリシー情報）およびＭＥ内の利用可能なリソースを含む、ＭＥセキュアブートが完了したことを示すメッセージを送信することができる。５３１で、「ＭＥブートが完了」メッセージをＳＤＭ ５０２に転送することができる。５３５で、ＳＤＭ ５０２は、例えば、システム全体のポリシーを評価し、ＭＥに対する許容可能なドメイン、リソース、およびポリシー制約条件を決定することができる。５４で、ドメインポリシー制約条件および／または許容可能なリソースに関する情報を与えるメッセージを送信することができる。５４５で、ポリシー制約条件をベースポリシーに付加し、必要ならば、リソースリストを加えることもできる。

図５および図５Ａの要素５５〜５１１は、図４および図４Ａに示されているような要素４５〜４１１と類似のものであってよい。値ＭＰＩＡおよびＭＰＥＳの評価は、式１４から１９までの評価と類似するものであってよい。ＭＥは、ＭＴＭ対応のものであり、ただ単に未加工データＭＰＩＤではなく、ダイジェストＭＰＩＡを単独で計算するように構成することができる。ＳＤＭによって伝えられる更新されたポリシー制約条件は、禁止されたドメインまたはドメインポリシーが実現されないようにチェックすることができる。ポリシーのチェックおよび評価は、ＭＥ_PDMによって実行されうる。

５５で、ターゲットドメインプランを含みうる、ＲＴＯを開始する要求が送信されうる。５５５で、ＭＥ_PDM側で、ＲＴＯ要求を受け入れるか、または拒絶する決定を下すことができる。５５１で、ＲＴＯを開始するかどうかを示すメッセージを送信することができる。代替的形態では、５５６で、ＲＴＯを開始する意図がＭＥターゲットから始まるものとしてよい。５６で、ＲＴＯを開始する意図メッセージを送信することができる。５６５で、１）拡張ドメインポリシー、および／または２）拡張ポリシーによる利用可能なリソース、受け入れ可能なドメイン、および状態を、チェックおよび／または評価することができる。５６１で、ＲＴＯを開始することが受け入れ可能であることを示すメッセージを送信することができる。５７で、ＭＥドメインセットからの、ＭＰＩＡおよびＭＰＥＳの要求を送信することができる。５７５で、ドメイン毎のＰＣＲの範囲にわたる既存のドメイン（ＭＰＩＡ）からの完全性アテステーションの収集および連結を、ＭＰＥＳ情報の収集および連結とともに実行することができる。５８で、ＭＰＩＡおよびＭＰＥＳを送信することができる。５９で、ＭＰＩＡ｜｜ＭＰＥＳ｜｜目的｜｜ＲＴＯ要求を送信することができる（メッセージ完全性および機密性は、認証された公開／秘密鍵で保護されうる）。５９５で、ターゲットＲＯ ５１０は、例えば、ＭＰＩＡ、ＭＰＥＳ、および目的をチェックすること、ＲＩＭ_TSIMに対して手つかずのドメインが信頼に足るものかどうかを判定すること、ＤＰの受け入れ可能性をチェックすること、または完了ドメイン状態を構築するＣＯＮＦＩＧを作成することのうちの１つまたは複数を実行することができる。５１４で、メッセージＣＯＮＦＩＧ｜｜ＤＰ｜｜ＲＩＭ_TSIM｜｜ＲＯを送信することができる。５１５で、ドメインを構築し、構成して、完全性をＲＩＭ_TDROに対してチェックすることができる。それに加えて、ＭＥ＊_{Target_RO}の所有権を取得し、そうして、ＭＥ_{Target_RO}に変換することができる。５１１で、ドメイン完了メッセージを送信することができる（署名付き、完全性保護）。ＭＥは、ターゲットＲＯと直接通信することができ、したがって、図３および図３Ａに示されているようなメッセージ転送は、使用されず、メッセージの数を減らすことができる。手つかずのエンジン信頼性検証に対するＲＩＭ証明書に関するものとともにＭＥとターゲットＲＯとの間のメッセージングにおける公開／秘密鍵の交換に必要な証明書に関する詳細は、図５に示されていない。

図６は、ＴＨＳＭの例示的な状態定義、遷移、および制御点定義を示している。例えば、特許文献１においてその定義および基本機能が定義されているＭ２Ｍ通信識別モジュール（ＭＣＩＭ：Ｍ２Ｍ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ）のライフサイクルは、本明細書で定義されている。ＴＨＳＭは、ＭＣＩＭの、状態定義および遷移を含む、機能性および特徴を改善し、一般化することができる。

６０１で、ＴＨＳＭは、プレブート状態にあるものとしてよい。第１のユーザーがＴＨＳＭの電源をオンにし、ＴＨＳＭは安全にブートし、ＴＨＳＭは状態６０２にあるものとしてよい。６０２で、ＤＭおよびＤＯは、手つかずの状態で存在することができる。ＤＭドメインを事前構成ファイルから構築することができ、ＴＨＳＭは状態６０６にあるものとしてよい。６０６で、ＴＨＳＭは、ポストブート２状態に入り、ＴＤ_DMがロードされうる。６０６からは、ＤＯドメインを事前構成ファイルまたはダウンロードファイルから構築することができ、ＴＨＳＭを状態６０５に残す。６０５で、ＴＨＳＭは、ポストブート３状態に入り、そこでＴＤ_DOが構築されうるが、ＴＤ_UまたはＴＤ_ROは、ロードできない。状態６０５から、ＤＯドメイン（ＳＤＭ）は、ユーザーのドメインをロードし、ＴＨＳＭを状態６０４に残すことができる。６０４で、ＴＨＳＭは、ポストブート状態２ａに入り、そこでＴＤ_Uがロードされるが、ＲＯドメインは、ロードできない。状態６０５から、手つかずのＲＯドメインを、ＳＤＰに基づいて構築し、ＴＨＳＭを状態７０７に残すことができる。７０７で、ＴＨＳＭは、ポストブート状態７に入り、そこでＴＤ_ROおよびＴＤ_DOがロードされているが、ＴＤ_Uは、ロードできない。状態６０７から、ＴＤ_DO（ＳＤＭ）は、ＴＤ_Uをロードし、ＴＨＳＭを状態６０８に残すことができる。６０８で、ＴＨＳＭは、ＤＯ、ＤＵ、およびＲＯドメインをロードしておくことができる。

状態６０１から、ユーザーが電源をオンにすると、ＴＨＳＭは安全にブートし、ＴＨＳＭを状態６０３に残すことができる。６０３で、ＴＨＳＭに、格納されている構成をロードすることができ、そこでは、格納されている構成は一番最近に電源をオフにする前の構成であった。状態６０３から、構成を変更するポストブートトランザクションを実行し、ＴＨＳＭを状態６１０に残すことができる。６１０で、ＴＨＳＭは、１つまたは複数のすでにアクティブの状態が非アクティブになる。６０３から状態６１０に到達するプロセスと同様に、ＴＨＳＭは状態６０９にあってよく、そこで、ＴＨＳＭは１つまたは複数のアクティブなドメインを有する。状態６０９から、構成変更イベントの結果、遷移が生じて、ＴＨＳＭを再び状態６１０に残すことができる。

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

ドメイン管理の第１の方法では、ドメイン所有者からのポリシー、つまり、システム全体のドメインポリシー（ＳＤＰ）は、非常に制約的であり、また「静的（ｓｔａｔｉｃ）」であり、新規ドメイン活動または目的に関して厳しいルールを有している可能性がある。これらのポリシーは、新規ドメインエントリまたは既存のドメインが更新される毎にＲＯと通信する必要性を軽減する傾向があると思われる。

ドメイン管理の第２の方法では、ＳＤＰは、制約が少なく、活動および目的に関してより柔軟に対応できる。すべての新規ドメインエントリおよびすべてのドメイン変更が既存のドメイン所有者に報告されうる。この結果、プラットフォームとＲＯとの間の最初のネゴシエーションおよびその後のネゴシエーションが実行されうるポリシー強制のより動的なシステムが得られる。

ドメイン管理の第１の方法を参照すると、ＳＤＰは、事前構成リスト内で例外なく許可されているドメインを指定することができる。このリストは、ＲＯの種類および（種類毎に）許可される数に関する情報を含むことができる。このリストは、ドメインがセットアップされた後ＲＯが提供することができるサービスの種類も含むことができる。ＲＯ候補は、リストで示されている条件を満たすＲＯであるものとしてよい。ＲＯは、リストおよびポリシー制約条件などの条件に関して、例えば式９に示されているような、ＲＴＯプロセスの一部としてアラートされうる。ＲＯは、ＳＣＡＲＤを受け取った後、注目しているプラットフォームまたはデバイス上のステークホルダーになりたいかどうかを独立して決定することができる。ＲＯに送られる条件は、ドメインの種類およびその目的を含むことができるが、他のＲＯの素性を保護するために、他のＲＯのリストの実際の名前については含まないようにできる。ＲＯがＲＴＯを完遂することを決定した場合、ポリシーからの逸脱がこのＲＯ、またはプラットフォーム上で現在アクティブである他のＲＯ、または将来アクティブになる可能性のある他のＲＯによって許されないことは確実であるものとしてよい。その結果、ＲＯは、実行される可能性のあるその後のＲＴＯにアラートされる必要はなく、またアラートされることもない。

ドメイン管理の第２の方法を参照すると、どのようなリモート所有者が特定のＲＯの種類を識別することなく許可されるかなどの比較的広範な制約条件のみ、またＲＯからＳＤＭへのより多くの情報の要求またはいくつかのネゴシエーションなどの、より多くのインタラクティブなやり取りを許すポリシーを、ＲＴＯプロセスにおいて遂行することができることがわかる。ドメイン構成が変更されるときに、ＳＤＭとすべてのＲＯとの間に進行中の協力もありうる。したがって、最初の、さらにはその後のネゴシエーションは、ＲＯ／ＳＤＭの動的な関係の一部として実行されうる。

ＲＴＯプロセスの一部として、ＲＯは、ＴＰＩＡ、ＴＰＥＳ、およびＳＣＡＲＤなどの、必要とされる、アテステーションおよびポリシー条件の情報を与えられ、これは、構成およびその信頼性に関する、第１の方法の場合と比較してより一般的な情報を含みうる。既存のドメイン構成に基づき、ターゲットＲＯは、ＲＴＯを継続するかどうかを決定することができる。ターゲットＲＯが所有権取得に反対する決定を即座に下さない限り、ＳＤＭとのネゴシエーションプロセスが続きうる。例えば、ＳＤＭは、ターゲットＲＯのドメインがアクティブである間アクティブでありうるドメインタイプおよびアテンダントサービス、またはそれが反対する種類のドメインがアクティブになろうとしている場合の続けるべき手順をターゲットＲＯに要求することができる。ＲＯは、例えば、いくつかの他のドメインタイプまたはいくつかの他のＲＯが所有するドメインさえもアクティブになるか、またはアクティブになろうとしているときに自ドメインが非アクティブにされることを要求する場合があるか、またはアクティブのままであるが、容量または能力を減らした状態にすることを要求する場合もある。ＳＤＭは、アラートすべきイベント発生をＲＯに要求することもできる。そのようなイベントは、アクティブになるか、または非アクティブになる、それが反対する、ドメインタイプを含む可能性がある。ＲＯは、いくつかの他の所有者によって保持される他のドメインタイプまたはドメインが、自ドメインがアクティブである間、一切の活動から完全にブロックされることを要求することもできる。

ＳＤＭは、そのような条件を受け入れるか、または拒絶する決定をすることができる。広範な一組のポリシー要件で動作するけれども、ＳＤＭは、ＲＯからの要求を受け入れることが「静的な」システムドメインポリシー（ＳＤＰ）の契約内示書にそのまま適合しうるかどうかを決定する自由度と意味論的な能力を有することができる。

図７は、ＲＯドメインが達成しうる例示的な状態および動的に管理された環境において遷移が発生しうる条件を示している。７０１で、ヌル状態が存在する可能性があり、例えば、ＲＯは構築されえない。７０１から、手つかずのＲＯドメインを、ＳＤＰに従って構築し、ＲＯドメインを状態７０２に残すことができる。７０２から、ＲＯがＴＰＩＡ、ＴＰＥＳ、およびＳＣＡＲＤを取得することを含む、ＲＴＯプロセスを実行することができる。さらに、ＲＯは、ＲＴＯの条件を受け入れて、ＲＯドメインを状態７０３に残すことができる。７０３から、新規アクティブドメインとのポリシー競合があると判定されることがあり、それに応答して、ＲＯドメインの機能を低減するか、または非アクティブにし、ＲＯドメインを状態７０４に残す。また７０３から、ＲＯドメインは更新されたポリシー／構成変更を受け取り、その結果、ＲＯドメインは修正された構成および／または更新されたポリシー制約条件を有することになる。７０６から、新規アクティブドメインとのポリシー競合があると判定されることがあり、それに応答して、ＲＯドメインの機能を低減するか、または非アクティブにし、ＲＯドメインを状態７０４に残す。また７０３から、新規ソフトウェアコンポーネントを、ダウンロードまたはＲＴＯを介して導入することができ、その結果、ＲＯドメインの状態が修正／拡張され、ＲＯドメインを７０５に残す。７０５から、新規アクティブドメインとのポリシー競合があると判定されることがあり、それに応答して、ＲＯドメインの機能を低減するか、または非アクティブにし、ＲＯドメインを状態７０４に残す。

７１１に例示されているように、状態７０２、７０３、７０４、７０５、または７０６のＲＯドメインはヌルになり、例えば、ＤＯ、ＲＯなどによって削除されうる。７４１に例示されているように、非アクティブ／低減機能のＲＯドメインは、状態７０３、７０５、または７０６に、例えば、ＲＯドメインを状態７０４に移動させた原因である競合を解決することによって移動することができる。７５１に例示されているように、状態７０５にあるＲＯドメインは、状態７０３、７０４、または７０６に移動することができる。７６１に例示されているように、状態７０６にあるＲＯドメインは、状態７０３、７０５、または７０６に移動することができる。

ＲＯドメインの管理に関して、動的ドメイン管理の一部として許されうるものは、イベントが展開するときに変更する要件をネゴシエートすることに対するものである。例えば、ＲＯは、以前に異議のあった、別のＲＯによって提供される特定のサービスが、もはやそのサービスと競争する必要がなくなったと判断された結果、現在では許可可能であると決定することがありうる。時間の経過によるビジネスモデルの変化は、ＲＯ候補による戦略およびポリシーのネゴシエーションに影響を及ぼしうる。動的ポリシー構造を採用するＳＤＰは、そのような戦略変更に対応するようになされうる。

限定はしないが、自動支払いサービスと組み合わせたＭ２Ｍジオトラッキングなどのサービスでは、優先ローミングパートナーシップ、またはＲＯのクローズドグループが形成されうる。このようなグループ化されたサービスは、類似のまたは異なるサービスを提供する異なる通信事業者が互いに提携する場合に、優先するクローズドグループとなる可能性がある。サービス、通信事業者、またはその両方の優先グループは、デバイスユーザーへのバンドルサービスまたは抱き合わせ販売として提供されうる。

第１の例では、パッケージは、地球を巡る間に追跡可能である。数百万のこのようなジオトラッキングデバイスが利用される可能性がある。パッケージが大陸を横断する際に、異なる国の異なる通信事業者による接続性を提供される。したがって、接続するために、ユーザーは、複数のローミングプロファイルを使用する必要がある場合がある。これらのローミングプロファイルは、さまざまなリモート通信事業者にまたがっており、それぞれのドメインがリモート通信事業者によって所有され管理されているのでドメイン間ポリシーとして管理される。ポリシーは、ローミングベースのソリューションをサポートする代わりに新しいサービスプロバイダへの完全な引き継ぎをサポートするよう強制することもできる。

第２の例では、スマートメータリング事業者とジオトラッキング事業者との間の提携が説明される。これらのドメインは、異なる通信事業者によって所有され運営されうる。事業提携またはユーザーの好みにより、ドメインを組み合わせてジョイントプロファイルをサポートすることができる。労力、ストレージ、または駐車などの、リソースの利用度に基づく課金の場合、自動支払いサービスをパッケージの追跡と平行して使用することができる。共存するサービスが独立したカテゴリに分類されるこのような事例では、ドメイン間ポリシー管理のサポートを使用することができる。

ドメイン間ポリシーマネージャ（ＩＤＰＭ：Ｉｎｔｅｒ Ｄｏｍａｉｎ Ｐｏｌｉｃｙ Ｍａｎａｇｅｒ）は、ドメインのグループ挙動を決定するポリシーを管理することができる。ドメイン間ポリシー（ＩＤＰ：Ｉｎｔｅｒ Ｄｏｍａｉｎ Ｐｏｌｉｃｉｅｓ）は、ＲＴＯプロセスにおいてそれぞれのＲＯによってダウンロードされうる。ＩＤＰは、それぞれのＲＯによって署名された証明書によって認証されうる。これらの証明書は、ＩＤＰとともに発行されうる。あるいは、これらのポリシーは、外部サービスディーラーによって認定され、ダウンロードされうる。優先事業者リストを作成することに関心を持つデバイスユーザーまたはデバイス所有者は、ＩＤＰを作成することができる。ＩＤＰＭは、これらのポリシーを、ＩＤＰを選択する候補ポリシーまたは優先度の受け入れ可能な交差を評価し、次いでその結果得られるポリシーを強制することによって処理することができる。

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

アテステーションプロトコルの一部として、ＴＤ_ROは、ＲＯに、ＴＰＩＡ、ＴＰＥＳ、およびＳＣＡＲＤのハッシュを、これらの測定結果を全部送信する代わりに、送信することができる。ＲＯは、単独で、またはＴＴＰを使って、そのようなハッシュを検証し、それによりＴＤＲＯおよび周囲システムの実行可能性の評価を行う手段を有することができる。この方法は、特許文献１において指定されているような、半自律妥当性確認（ＳＡＶ：Ｓｅｍｉ Ａｕｔｏｎｏｍｏｕｓ Ｖａｌｉｄａｔｉｏｎ）に類似しているものとしてよい。アテステーション段階で、ＴＰＩＡ、ＴＰＥＳ、およびＳＣＡＲＤ測定のうちの１つまたは２つを送出することができる。

ＴＨＳＭは、ＭＥの一部として埋め込んで一体にできる。そのようなデバイスに対するＲＴＯプロセスは、ＭＥとＴＨＳＭとの間のインターフェースがないので、簡素化することができる。

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

好適なプロセッサとして、例えば、汎用プロセッサ、専用プロセッサ、従来型のプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアとの関連性を持つ１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、他のタイプの集積回路（ＩＣ）および／または状態機械が挙げられる。

ソフトウェアとの関連性を持つプロセッサは、ワイヤレス送信受信ユニット（ＷＴＲＵ）、ユーザー装置（ＵＥ）、端末、基地局、無線ネットワークコントローラ（ＲＮＣ）、またはホストコンピュータにおいて使用するための無線周波トランシーバを実装するために使用できる。ＷＴＲＵは、カメラ、ビデオカメラモジュール、テレビ電話、スピーカーフォン、バイブレーションデバイス、スピーカー、マイク、テレビトランシーバ、ハンズフリーヘッドセット、キーボード、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、液晶ディスプレイ（ＬＣＤ）表示装置、有機発光ダイオード（ＯＬＥＤ）表示装置、デジタル音楽プレーヤー、メディアプレーヤー、ゲーム機モジュール、インターネットブラウザ、および／またはワイヤレスローカルエリアネットワーク（ＷＬＡＮ）モジュールまたはウルトラワイドバンド（ＵＷＢ）モジュールなどの、ハードウェアおよび／またはソフトウェアで実装された、モジュール群と併せて使用できる。
ＩＩ．加入方式のサービスにアクセスするための登録および資格証明ロールアウト
デバイスのユーザーは、加入方式のサービスのプロバイダと加入関係を結ぶことを望んでいるものとしてよい。例えば、図１のデバイス１００、１１０、もしくは１２０、または図２のＵＥ ２００などのＵＥのユーザーは、リモート所有者によって提供される加入方式のサービスの加入ユーザーとして登録することを望んでいる場合がある。加入方式のサービスの提供は、第三者によって円滑に行われるようにすることができる（例えば、第三者は、リモート所有者に代わって加入方式のサービスをユーザーに販売することができる）。リモート所有者は、ＲＴＯプロセスに関して上で説明されているように、リモート所有者ドメインと称されうる、デバイス上のドメインの所有権を取得している可能性がある。さらに、ユーザーは、ユーザードメインと称されうる、デバイス上のドメインの所有権を取得している可能性がある。

ユーザーが加入方式のサービスにアクセスするために、登録および資格証明ロールアウトが行われる必要がある場合がある。登録および資格証明ロールアウトは、ユーザーを加入方式のサービスの加入ユーザーとしてリモート所有者に登録し、そのようなサービスがリモート所有者ドメインを通じてリモート所有者によって提供されうること、ユーザーが加入方式のサービスを加入ユーザーとして利用することを可能にしうる資格証明をリモート所有者から取得すること、および／または資格証明をリモート所有者ドメインに格納することのうちの１つまたは複数を含みうる。資格証明により、ユーザーがデバイスを介して加入方式のサービスを利用することが可能になる。資格証明という用語は、従来の資格証明（例えば、鍵、ＩＤ、証明書など）を含むものとしてよい。資格証明という用語は、他の文脈に関連するデータ、ならびに加入管理機能に使用される実行ファイルおよびアプレットなどのアプリケーションも含みうる。

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

登録および資格証明ロールアウトは、リモート所有者がリモート所有者ドメインの所有権を獲得してからずっと後になって発生しうる。ワイヤレス電話機能を持つワイヤレスデバイスは、一例として使用できる。複数のワイヤレスキャリアが、デバイス上の複数のドメインの所有権を取得している可能性がある（例えば、それぞれのワイヤレスキャリアがリモート所有者である）。例えば、ワイヤレスキャリア１がリモート所有者ドメイン１の所有権を取得している可能性があり、ワイヤレスキャリア２がリモート所有者ドメイン２の所有権を取得している可能性がある。しかし、ユーザーは、ワイヤレスキャリア２ではなく、ワイヤレスキャリア１の加入方式のサービス（例えば、ワイヤレス電話サービス）に関係する登録および資格証明ロールアウトを開始している可能性がある。例えば、ワイヤレスキャリア１は、ユーザーに、ワイヤレス電話サービス全体においてワイヤレスキャリア２に比べてよい取引を提供していた可能性がある。後日（例えば、数日後、数ヶ月後、数年後）、ユーザーは、ワイヤレスキャリア２の加入方式のサービス（例えば、ワイヤレス電話サービス）に関係する登録および資格証明ロールアウトを開始することができる。そこで、例えば、ワイヤレスキャリア２は、長距離電話においてワイヤレスキャリア１に比べてよい取引を提供することができる。ユーザーは、両方の加入方式のサービスを使用することができるが、それは、登録および資格証明ロールアウトが両方に対して完了しているからである。例えば、ユーザーは、市内通話に対しワイヤレスキャリア１のワイヤレス電話サービスを、長距離電話に対してワイヤレスキャリア２のワイヤレス電話サービスを使用することができる。この例では、いずれのリモート所有者も、そのような取り決めを禁止する規則を定めていると想定している（例えば、ＲＴＯプロセスを参照）。この例も、登録および資格証明ロールアウトが、リモート所有者がリモート所有者ドメインの所有権を獲得してからずっと後になって発生しうることを示している。

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

ユーザーは、加入方式のサービスなどのサービスに加入することを求めるデバイスのユーザーとすることができる。このような加入方式のサービスの例として、限定はしないが、金融サービス、移動体通信サービス、インターネット接続サービス、音楽／動画／マルチメディア加入サービス、アイデンティティサービス、位置情報サービス、電子メール／メッセンジャー／ソーシャルネットワーキングサービス、電子書籍サービス、ゲームサービスなどが挙げられる。ユーザーは、デバイスの所有者であってもよい。ユーザーは、登録および資格証明ロールアウトを開始することができる。この開始には、ユーザーが個人データおよび／または従来のログイン情報を送信することが含まれうる。ユーザーは、例えば、ユーザーの加入がなされた／ユーザーが加入している加入方式のサービスに関連付けられているアクションに関係する場合に、加入者と称してもよい。

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

リモート所有者（ＲＯ）は、デバイスを介して加入サービスをユーザーに提供することができる。リモート所有者は、加入サービスをユーザーが使用するために必要になる場合がある資格証明を与えることができる。資格証明は、リモート所有者ドメインとリモート所有者との間の強い秘密として使用することができる認証鍵Ｋを含むものとしてよい。一例として、ＲＯは、ＭＮＯ、他の通信ネットワーク事業者（例えば、ＷＬＡＮ、ＷｉＭａｘなど）、電子メールサービスプロバイダ、インターネットサービスプロバイダ、ソーシャルネットワーキングサービスプロバイダ、デジタルコンテンツ（音楽、電子書籍、動画など）プロバイダ、ゲームサービスプロバイダ、金融サービスプロバイダ、アプリケーションサービスプロバイダ（例えば、モバイル決済、モバイル発券、ＤＲＭ、モバイルＴＶ、位置情報サービスなどのサービスプロバイダ）、ＩＭＳサービスプロバイダなどのうちの１つまたは複数とすることができる。

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

ＰＯＳ（販売時点またはサービス提供時点管理エンティティ）は、加入方式のサービスのユーザーへの販売／サービス提供を円滑にする第三者とすることができる。ＰＯＳは、図８に関して説明されているようにチケットを介して販売を円滑にすることができる。一例として、ＰＯＳは、リモート所有者の加入方式のサービスを販売し、および／またはリモート所有者の加入方式のサービスの販売前および販売後顧客サービス業務を遂行する小売店（オンライン店舗、オンラインでない従来型の店舗など）とすることができる。
システム全体のドメインマネージャ（ＳＤＭ）、例えば、セクションＩで開示されているＳＤＭは、登録および資格証明ロールアウトの一部として１つまたは複数のプラットフォームに関係するアテステーション情報を提供することができる。例えば、登録および資格証明ロールアウトにおいて要求があったときに、ＳＤＭは半自律完全性確認を送ることができる。ＳＤＭは、ドメインのコンポーネントなど、ＴＨＳＭの一部であってよい（例えば、図２を参照）。

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

登録および資格証明ロールアウトは安全な方法で実行できる。ユーザー登録および資格証明ロールアウトを安全に実行するうえで以下の前提条件のうちの１つまたは複数が満たされ、および／または仮定されうる。
・ＴＨＳＭ／ＭＥプラットフォームは、信頼に足る状態にあるとみなすことができ、ドメインがリモート所有権取得（ＲＴＯ）プロトコルを介してすでに構成されているリモート所有者による要求があった後、プラットフォーム構成のステータス、またはその一部分を報告することができるものとしてよい。デバイスは、「完全に信頼できる」プラットフォームコンポーネントであるとみなせないＭＥを含みうる。ＭＥの信頼性は、ＴＨＳＭによって定期的に監視されうる。ＭＥおよびＴＨＳＭを接続するインターフェースは、一般的に、安全であるとみなせない。ＭＥは完全なＭＴＭの能力を有し、その完全性のアテステーションを実行することができると仮定してよい。
・以下の方法のうちの１つまたは複数で実行されうる、プラットフォームのアテステーション。
（１）ＴＰＩＡ、ＴＰＥＳ、およびＳＣＡＲＤの使用を含むアテステーション報告（例えば、ＲＴＯプロセスを参照）。
（２）現在の構成のハッシュをＲＯに送信することを含みうるリモート検証のスケーリングされたバージョン。このタイプのアテステーションは、多量のデータの転送を回避したい場合に使用するとよい。
（３）内部完全性チェックの実行、およびプラットフォームが安全であるという確認を送ることを含みうる、半自律的検証。
・資格証明をリモートでダウンロードすることができる。ＰＯＳは、リモート所有者にユーザーを登録することに関わることができる。ＰＯＳとの通信は、以下の方法のうちの１つまたは複数で実行できる。
（１）ユーザーは、ＰＯＳが識別情報および登録データを送信するときに無線（ＯＴＡ）で、またはインターネットリンクでＰＯＳと通信することができる。
（２）ユーザーがハンドセットを使って登録ログインステップを完了した後、ユーザードメインは登録および資格証明ロールアウトプロセスに関係するＰＯＳとインターネット経由で通信することができる。
・ＰＯＳは、発券機能を処理するうえで十分に信頼に足るとみなせる。したがって、ＰＯＳは、Ｃｅｒｔ_POSの関連付けられている証明書とともにＫ_POS-PrivおよびＫ_POS-Pubと表される証明済みの鍵の対のセットを有している可能性がある。これらは、それぞれ関連付けられている証明書Ｃｅｒｔ_ROおよびＣｅｒｔ_TSIMとともに、リモート所有者の鍵セット（Ｋ_{RO_Priv}，Ｋ_{RO_Pub}）およびＴＳＩＭ（Ｋ_TSIM-Priv，Ｋ_TSIM-Pub）と併せて、登録および資格証明ロールアウトで使用されうる。
・ユーザーとユーザードメインとの間の通信では、ＭＥを仲介手段として使用することを想定することができ、ユーザーによる使用を意図されているメッセージは、ハンドセットの画面上に表示されうる。これらのメッセージは、完全性および機密保護をそれぞれ目的として一時鍵Ｋ_{temp_I}およびＫ_{temp_C}を使用することができ、ＭＥは、ユーザーのために解釈する（例えば、署名を復号し、および／または検証する）ことができる。
・登録および資格証明ロールアウトは、同じユーザーまたは場合によっては複数のユーザーからの複数の登録および資格証明要求を許容できる程度には柔軟性があるものとしてよい。例えば、それぞれのユーザーは、所定の信頼できるドメイン（ＴＤ_RO）に対して１つの（かつ、ただ１つの）登録を確立することができるが、複数のそのようなドメインにまたがって複数の登録を確立することができる。しかし、複数の明確に区別されるユーザーは、それぞれ、そのような１つのドメインに対してそのユーザー専用の登録を行うことができる。それぞれのＴＤ_ROは、１つのＲＯを有することができるが、ＲＯは、複数の登録を管理し、明確に区別される１人のユーザーに対してそれぞれの登録を管理することができる。所定のＲＯが複数のＴＤ_ROを所有することも可能である。場合によっては複数のリモート所有者に対応する複数のユーザーおよび信頼できるドメインが与えられた場合、プロセスＩＤは、例えば、ユーザードメイン、ＰＯＳ、およびリモート所有者によって生成され、複数の登録に関係する曖昧さを防ぐようするために使用されうる。所定の登録および資格証明要求に対して、緊密に関連付けられている３つのプロセスＩＤを生成することができる、つまり、ＰＩＤ＿Ｕ（ユーザードメインによる）、ＰＩＤ＿ＰＯＳ（ＰＯＳによる）、およびＰＩＤ＿ＲＯ（リモート所有者による）を生成することができる。ＰＩＤ＿Ｕは、ユーザードメインを識別するためにＰＯＳまたはリモート所有者のいずれかと通信するときにＴＨＳＭ内のエンティティによって使用されうる。これらのＩＤは、所定の登録プロセスを一意に識別するのに十分なものとしてよい。
・信頼できるエンティティ間の通信は、公開−秘密鍵の対を使用して保護することができ、公開鍵は、認証局（ＣＡ）によって発行された証明書を介して分配することができる。
・登録および資格証明ロールアウトにおいて、ノンスを使用して、再生攻撃を防止することができる。ノンスは、連続する番号を振られるか、もしくは他の何らかの順次的な順序付けをされうるか、または連続的、もしくは他の何らかの順次的に順序付けされた番号を含むものとすることができる。いくつかの内部的なドメイン間の相互作用は、記述的なノンス指定記号が使用される場合、連続的な番号を振られない。２つのエンティティ間の往復通信については、送信された第１のノンスをその発信地に返送メッセージ内の新しいノンス（平文で）とともに送り返す（平文でなく）ことができる。返送ノンスを受信したエンティティは、値がそれによって最初に生成されており、したがって知られている可能性がある場合に、平文で送信されることを要求しないものとしてよい。
・署名を、例えば、ＳＨＡ−Ｘとして本明細書で表されうる、ＳＨＡアルゴリズムの未指定バージョンによって計算された固定ビット長の暗号ハッシュ値に適用することができる。

次に、登録および資格証明ロールアウトを例示する方法を、図８を参照しつつ説明する。図８は、登録および資格証明ロールアウトのプロセスを実装する例示的な呼流れ図である。呼の流れは、式で表すことができる。式は、各流れに関連付けることができるセキュリティ機能を含むことができる。図８に例示されている呼の流れは、例であることが意図されている。他の実施形態も使用できることは理解されるであろう。さらに、流れの順序は、適宜変えることができる。それに加えて、流れは、必要でなければ省略することができ、追加の流れを加えることもできる。

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

Ｐａｃｋａｇｅ＿０＝ｔｉｃｋｅｔ ｒｅｑｕｅｓｔ｜｜ＩＤ_POS｜｜ｎｏｎｃｅ０
ＰＯＳ→ＲＯ：Ｐａｃｋａｇｅ＿０｜｜Ｃｅｒｔ_POS｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿０）］Ｋ_POS-Pri
式１

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

Ｐａｃｋａｇｅ＿１＝Ｔｉｃｋｅｔ_i｜｜ｎｏｎｃｅ０｜｜ｎｏｎｃｅ１
ＲＯ→ＰＯＳ：｛Ｔｉｃｋｅｔ_i｝Ｋ_POS-Pub｜｜ｎｏｎｃｅ１｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１）］Ｋ_{RO_Priv}Ｃｅｒｔ_RO
式２
インデックス付きセット内のそれぞれのチケットは、三つ組み
Ｔｉｃｋｅｔ_i＝（ＩＭＳＩ_i｜｜ＲＡＮＤ_i｜｜ＡＵＴＨ_i｜｜）
を含むことができる。

ＩＭＳＩ（国際移動電話加入者識別番号）は、例えば、サービス資格証明を要求するときに、ユーザー／加入者の一意的な識別子として使用することができる。ＲＡＮＤ値は、チケット自体の新鮮さを示すものとしてよい乱数であり、ＡＵＴＨは、チケットの完全性および真正性を確認するための手段である。鍵Ｋ_{RO_Priv}（ＲＯ秘密鍵）を使用するＰａｃｋａｇｅ＿１ハッシュの署名は、リモート所有者の認証を行っている間にメッセージの完全性を保護することができる。

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

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

Ｐａｃｋａｇｅ＿２＝ＩＤ_U｜｜Ｐａｓｓｗｏｒｄ_U｜｜ＲＥＧＤＡＴＡ_U｜｜ｎｏｎｃｅ_U
Ｕｓｅｒ／Ｏｗｎｅｒ→ＴＤ_U：
ＩＤ_U｜｜ｎｏｎｃｅ_U｜｜ＲＥＧＤＡＴＡ_U｜｜｛Ｐａｓｓｗｏｒｄ_U｝Ｋ_{temp_C}｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿２）］Ｋ_{temp_I}
式３

３におけるプロセスは、典型的なログインおよび登録手順とみなせる。メッセージの暗号化および署名機能、さらにはノンスｎｏｎｃｅ_Uの使用は、ＭＥの暗黙の存在を反映するものとしてよく、またユーザーに対して透過的であるものとしてよい。この透過性は、図８に例示されている方法全体を通してユーザー／所有者とＴＤ_Uとの間の他の通信に関係しうる。

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

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

Ｐａｃｋａｇｅ＿３＝ＰＩＤ＿Ｕ｜｜ＲＥＧＤＡＴＡ_U｜｜ｎｏｎｃｅ３
ＴＤ_U→ＰＯＳ：
ＰＩＤ＿Ｕ｜｜ｎｏｎｃｅ３｜｜Ｃｅｒｔ_TDU｜｜ＲＥＧＤＡＴＡ_U｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿３）］Ｋ_TDU-Priv
式４

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

Ｐａｃｋａｇｅ＿４＝ＰＩＤ＿Ｕ｜｜ＰＩＤ＿ＰＯＳ｜｜ｎｏｎｃｅ３｜｜ｎｏｎｃｅ４
ＰＯＳ→ＴＤ_U：ＰＩＤ＿Ｕ｜｜ＰＩＤ＿ＰＯＳ｜｜ｎｏｎｃｅ４｜｜Ｃｅｒｔ_POS｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿４）］Ｋ_POS-Priv
式５

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

６で、ＴＤ_U ３４は登録要求をＴＤ_RO ３８に送信することができる。ＰＩＤ＿ＵおよびＰＩＤ＿ＰＯＳをメッセージの一部として送信し、これによりＴＤ_RO ３８が適切なプロセスの関連付けを行うことが可能になる。ユーザー識別ＩＤ_Uをメッセージに入れることができ、ＴＤ_RO ３８はこれを登録を試みようとしている特定のユーザーのサービスプロファイルに対するチェックとして使用することができる。この特徴により、同じドメインに関する複数のユーザー登録の自由度が高まる。

Ｐａｃｋａｇｅ＿５：Ｒｅｇｉｓｔｒａｔｉｏｎ Ｔｒｉｇｇｅｒ｜｜ＰＩＤ＿Ｕ｜｜ＰＩＤ＿ＰＯＳ｜｜ＩＤ_U｜｜ｎｏｎｃｅ４｜｜ｎｏｎｃｅ_TDU1
ＴＤ_U→ＴＤ_RO：Ｐａｃｋａｇｅ＿５｜｜Ｃｅｒｔ_POS｜｜Ｃｅｒｔ_TDU｜｜［Ｐａｃｋａｇｅ＿５］Ｋ_TDU-Priv
式６
ＴＤ_RO ３８は、証明書Ｃｅｒｔ_TDUから得られた公開鍵Ｋ_TDU-Pubを使用してＴＤ_U ３４の署名を検証することができるものとしてよい。

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

Ｐａｃｋａｇｅ＿６＝Ｔｉｃｋｅｔ＿ｒｅｑｕｅｓｔ｜｜ＰＩＤ＿Ｕ｜｜ｎｏｎｃｅ５
ＴＤ_RO→ＰＯＳ：Ｐａｃｋａｇｅ＿６｜｜Ｃｅｒｔ_TSIM｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿６｜｜ｎｏｎｃｅ４）］Ｋ_TSIM-Priv
式７
ＰＯＳ ３０は、証明書Ｃｅｒｔ_TSIMを介して取得できる公開鍵Ｋ_TSIM-Pubを使用してこのメッセージ内の署名を検証することができる。ＰＯＳ ３０は、Ｐａｃｋａｇｅ＿６（平文で送信される）とｎｏｎｃｅ４を使用してＳＨＡ−Ｘを再作成することができる。

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

Ｐａｃｋａｇｅ＿７＝ｔｉｃｋｅｔｋ｜｜ＰＩＤ＿ＰＯＳ｜｜ｎｏｎｃｅ５｜｜ｎｏｎｃｅ６
ＰＯＳ→ＴＤ_RO：｛ｔｉｃｋｅｔ_k｝Ｋ_TSIM-Pub｜｜ｎｏｎｃｅ６｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿７）］Ｋ_POS-Priv
（ｋは、ＲＯに関連付けられているチケットセットからの固定値である）
式８
ＴＤ_RO ３８は、ｔｉｃｋｅｔ_kをその秘密鍵Ｋ_TSIM-Privで復号（アンバインド）し、Ｐａｃｋａｇｅ＿７の署名をメッセージ６においてＣｅｒｔ_POSを介して得られたＫ_POS-Pubで検証することができる。このプロセスは、認証を行い、チケットの完全性を検証するために使用されうる。ＴＤ_RO ３８は、ＰＩＤ＿ＰＯＳを使用して正しいプロセス関連付けを行うことができる。ノンスｎｏｎｃｅ５は、ＴＤ_RO ３８に返送することができる。

９で、ＴＤ_RO ３８に送信されるチケットに加えて、ＰＯＳ ３０は、ＲＥＧＤＡＴＡ_Uを含み、ｔｉｃｋｅｔ_kでユーザーを識別することができる登録メッセージもＲＯ ４０に送信することができる。ＲＯ ４０にプロセス関連付けに必要と思われる情報を供給するために、ＰＩＤ＿ＰＯＳおよびＰＩＤ＿Ｕを送信することができる。これにより、ＲＯ ４０は、受信されたプロセスＩＤをこの登録のために作成されたＩＤに関連付けることが可能になるものとしてよい。このメッセージは、要求されうる資格証明を指定されたユーザーに提供するためにＲＯ ４０が必要とする可能性のある情報を含むことができる。

Ｐａｃｋａｇｅ＿８＝｜｜ＲＥＧＤＡＴＡ_U｜｜ｎｏｎｃｅ７｜｜ＰＩＤ＿ＰＯＳ｜｜ＰＩＤ＿Ｕ
ＰＯＳ→ＲＯ：
｛ｔｉｃｋｅｔ_k｝Ｋ_RO-Pub｜｜Ｐａｃｋａｇｅ＿８｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿８｜｜ｔｉｃｋｅｔ_k｜｜ｎｏｎｃｅ１）］Ｋ_POS-Priv
式９
チケットは、メッセージ２中のＣｅｒｔ_ROでＰＯＳ ３０によって取得されたＫ_RO-Pubを使用して暗号化されうる。ＲＯ ４０は、ｔｉｃｋｅｔ_kを、その秘密鍵Ｋ_RO-Privを使用して復号し、公開鍵Ｋ_POS-Pubを使用してＰａｃｋａｇｅ＿８の署名を検証することができるものとしてよい。公開鍵Ｋ_{RO_Pub}は、チケットをＲＯ ４０にバインドする効果を有することができる。

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

Ｐａｃｋａｇｅ＿９＝ＡＣＫ（Ｒｅｇ Ｄａｔａ Ｒｅｃｅｉｖｅｄ）｜｜ＰＩＤ＿Ｕ｜｜ＰＩＤ＿ＲＯ｜｜ｎｏｎｃｅ８
ＲＯ→ＴＤ_U：Ｐａｃｋａｇｅ＿９｜｜Ｃｅｒｔ_RO｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿９）］Ｋ_RO-Priv
式１０

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

１１で、式１０に関連付けられているメッセージを受信した後、ＴＤ_U ３４は、ユーザー３２に対して、資格証明を要求する許可を付与する画面メッセージをユーザー３２に発行することができる。

Ｐａｃｋａｇｅ＿１０＝ｃａｎ ｒｅｑｕｅｓｔ ｃｒｅｄｅｎｔｉａｌ ｒｏｌｌｏｕｔ｜｜ｎｏｎｃｅ９｜｜ＰＩＤ＿Ｕ｜｜ＩＤ_U
ＴＤ_U→Ｕｓｅｒ／Ｏｗｎｅｒ：Ｐａｃｋａｇｅ＿１０｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１０｜｜ｎｏｎｃｅ_U）］Ｋ_{temp_I}
式１１

このメッセージは、メッセージ３で使用される署名および検証プロセスと似ているが、反対方向である、ＭＥ側の同じ鍵を使用して検証されるＴＳＨＭ側に適用されうる署名鍵Ｋ_{temp_I}の使用を示している。ｎｏｎｃｅ_Uは、ＴＤ_U ３４によってＭＥに返送され、往復するものとしてよい。ＩＤ_Uは、ユーザー３２を識別するためにＭＥおよびＴＤ_U ３４によって使用され、ＰＩＤ＿Ｕと併せて、プロセスの曖昧さを回避することができる現在の登録および資格証明ロールアウトに関連付けられうる。

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

Ｐａｃｋａｇｅ＿１１＝Ｒｅｑｕｅｓｔ ｃｒｅｄｅｎｔｉａｌ ｒｏｌｌ−ｏｕｔ｜｜ｎｏｎｃｅ１０｜｜ＰＩＤ＿Ｕ｜｜ＩＤ_U
Ｕｓｅｒ／Ｏｗｎｅｒ→ＴＤ_U：Ｐａｃｋａｇｅ＿１１｜｜｛Ｐａｓｓｗｏｒｄ_U｝Ｋ_{temp_C}｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１１｜｜ＰａｓｓｗｏｒｄＵ｜｜ｎｏｎｃｅ９）］Ｋ_{temp_I}
式１２
ＴＤ_U ３４はパスワードを復号し、共有鍵セットを使用して署名を検証することができるものとしてよい。１１で送られるメッセージは、ＰＩＤ＿ＵとＩＤ_Uの組み合わせを使用することを例示している。ノンスとＰＩＤは、ユーザー／所有者に対して透過的であり、人間以外の通信エンティティによる使用に限定されうる。

１３で、ＴＤ_U ３４は、資格証明のユーザー要求をＴＤ_RO ４０に送ることができ、これは、直接要求をＲＯ ４０に行うきっかけとなりうる。ＰＩＤ＿ＲＯおよびＰＩＤ＿Ｕは、通信エンティティとのプロセス関連付けを可能にすることができる。ＴＤ_RO ４０は、そこで、３つのプロセスＩＤの関連付けを行うことができる。

Ｐａｃｋａｇｅ＿１２：Ｒｅｑｕｅｓｔ Ｃｒｅｄｅｎｔｉａｌ Ｒｏｌｌ−Ｏｕｔ（ＴＳＩＭ）｜｜ｎｏｎｃｅ_TDU2｜｜ＰＩＤ＿Ｕ｜｜ＰＩＤ＿ＲＯ
ＴＤ_U→ＴＤ_RO：Ｐａｃｋａｇｅ＿１２｜｜Ｃｅｒｔ_RO｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１２）］Ｋ_TDU-Priv
式１３
メッセージ検証は、６で送られたメッセージ内に受信されたＣｅｒｔ_TDUで受信されたＫ_TDU-Pubを使用して行える。

１４で、ＴＤ_ROは、半自律完全性検証の要求をＳＤＭ ３６に出すことができる。半自律完全性検証は、鍵完全性指標（例えば、ＴＰＩＡ、ＴＰＥＳ、およびＳＣＡＲＤ）のハッシュ値の使用に制限されうる。

Ｐａｃｋａｇｅ＿１３＝Ｒｅｑｕｅｓｔ Ｓｅｍｉ−Ａｕｔｏｎｏｍｏｕｓ Ｉｎｔｅｇｒｉｔｙ Ｖｅｒｉｆｉｃａｔｉｏｎ｜｜ＰＩＤ＿Ｕ｜｜ｎｏｎｃｅ_TDRO
ＴＤ_RO→ＳＤＭ：Ｐａｃｋａｇｅ＿１３｜｜Ｃｅｒｔ_TSIM｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１３）］Ｋ_TDRO-Priv
式１４
証明書Ｃｅｒｔ_TSIMを送信して、ＳＤＭ ３６がＰａｃｋａｇｅ＿１３ハッシュの署名検証のために公開鍵Ｋ_TDRO-Pubを取得することができるようにする。プロセスＩＤの関連付けは、ＰＩＤ＿Ｕの使用により維持されうる。ＳＤＭ ３６には、せいぜいＰＩＤ＿Ｕがあればよいが、それはＳＤＭ ３６が外部のエンティティ、例えば、ＴＨＳＭの外のエンティティと通信することができないからである。

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

Ｐａｃｋａｇｅ＿１４＝ＩＶ｜｜ＰＩＤ＿Ｕ｜｜ｎｏｎｃｅ_SDM
ＳＤＭ→ＴＤ_RO：Ｐａｃｋａｇｅ＿１４｜｜Ｃｅｒｔ_SDM｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１４｜｜ｎｏｎｃｅ_TDRO）］Ｋ_SDM-Priv
式１５
証明書Ｃｅｒｔ_SDMで取得された公開鍵Ｋ_SDM-Pubを使用して署名を検証することができる。

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

Ｐａｃｋａｇｅ＿１５＝Ｃｒｅｄｅｎｔｉａｌ Ｒｏｌｌ−Ｏｕｔ Ｒｅｑｕｅｓｔ｜｜ＩＤ_U｜｜ＩＶ｜｜ＰＩＤ＿Ｕ｜｜ｎｏｎｃｅ１１
ＴＤ_RO→ＲＯ：
｛ＩＭＳＩ_k｝Ｋ_RO-Pub｜｜Ｐａｃｋａｇｅ＿１５｜｜Ｃｅｒｔ_TDRO｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１５｜｜ＩＭＳＩ_k）］Ｋ_TDRO-Priv
式１６
ＲＯ ４０は、秘密鍵Ｋ_RO-Privを使用してＩＭＳＩ_kを復号し、証明書Ｃｅｒｔ_TDROにおいてＲＯ ４０によって取得された公開鍵Ｋ_TDRO-Pubを使用して署名を検証することができる。

１７で、ＲＯ ４０が資格証明をＴＤ_RO ３８に送信することができる。１６でＣｅｒｔＴＤＲＯから取得された公開鍵Ｋ_TDRO-Pubを使用して、資格証明を暗号化することができる。これは、資格証明をＴＤ_RO ３８にバインドすることができる。ＴＤ_RO ３８は、秘密鍵Ｋ_TDRO-Privを使用して資格証明をアンバインドすることができる。ノンスｎｏｎｃｅ１１は、往復を行うことができる。

Ｐａｃｋａｇｅ＿１６＝ＰＩＤ＿ＲＯ｜｜ｎｏｎｃｅ１２
ＲＯ→ＴＤ_RO：
｛Ｃｒｅｄ_TSIM｝Ｋ_TDRO-Pub｜｜Ｐａｃｋａｇｅ＿１６｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１６｜｜ｎｏｎｃｅ１１｜｜Ｃｒｅｄ_TSIM）］Ｋ_RO-Priv
式１７
ＴＤ_RO ３８は、１３で関連する証明書で受信された公開鍵Ｋ_RO-Pubを使用して署名を検証することができる。プロセスＩＤ ＰＩＤ＿ＲＯにより、正しいプロセス関連付けを行うことができる。

資格証明鍵は、保護されたメモリ内に格納されうるか、またはＳＤＭ ３６において与えられるセキュリティポリシーに従って、例えば、１７において指示されているような資格証明を受信した後に格納されうる。ポリシーは、ＲＴＯプロセスの実行時に定義されている場合がある。１８で、ロールアウトが完了した後、確認応答メッセージをＲＯ ４０に送信することができる。

Ｐａｃｋａｇｅ＿１７＝ＡＣＫ ｒｏｌｌ−ｏｕｔ ｃｏｍｐｌｅｔｅ｜｜ＰＩＤ＿Ｕ｜｜ｎｏｎｃｅ１３
ＴＤ_RO→ＲＯ：Ｐａｃｋａｇｅ＿１７｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１７｜｜ｎｏｎｃｅ１２）］Ｋ_TDRO-Priv
式１８
ノンスｎｏｎｃｅ１２を返送し、ＰＩＤ＿Ｕでプロセスの曖昧さを回避することができる。ＲＯ ４０は、１６で取得された公開鍵Ｋ_TDRO-Pubで署名を検証することができるものとしてよい。

１９で、ＴＤ_RO ３８は、ロールアウト完了確認応答メッセージをＴＤ_U ３４に送信することができる。ノンスｎｏｎｃｅ_TDU2（１３を参照）およびｎｏｎｃｅ_TDU1（１６を参照）を返送し、ＰＩＤ＿Ｕでプロセスの曖昧さを回避することができる。

Ｐａｃｋａｇｅ＿１８＝Ｒｏｌｌ−ｏｕｔ ｃｏｍｐｌｅｔｅ｜｜ＰＩＤ＿Ｕ
ＴＤ_RO→ＴＤ_U：Ｐａｃｋａｇｅ＿１８｜｜Ｃｅｒｔ_TDRO｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１８｜｜ｎｏｎｃｅ_TDU1｜｜ｎｏｎｃｅ_TDU2）］Ｋ_TDRO-Priv
式１９
ＴＤ_U ３４が証明書Ｃｅｒｔ_TDROで取得された公開鍵Ｋ_TDRO-Pubを使用して署名を検証することができる。

２０で、ＴＤ_U ３４から、資格証明が受信されて構成されていることを指示する画面メッセージをユーザー３２に提示することができる。これで、資格証明が、ユーザー３２が許可される安全なサービスに利用可能になるものとしてよい。ノンスｎｏｎｃｅ１０は、返送することができる（１２を参照）。

Ｐａｃｋａｇｅ＿１９＝Ｃｒｅｄｅｎｔｉａｌｓ Ｉｎｓｔａｌｌｅｄ｜｜ＩＤ_U｜｜ＰＩＤ＿Ｕ｜｜ｎｏｎｃｅ１４
ＴＤ_U→Ｕｓｅｒ／Ｏｗｎｅｒ：Ｐａｃｋａｇｅ＿１９｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１９｜｜ｎｏｎｃｅ１０）］Ｋ_{temp_I}
式２０
３、１１、および１２に関して説明されているように署名検証を実行できる。ＰＩＤ＿ＵとＩＤ_Uとの組み合わせの使用は、１１に関して説明されているように達成されうる。

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

Ｐａｃｋａｇｅ＿２０＝Ｔｉｃｋｅｔ_k ｎｏｗ ｉｎ ｕｓｅ｜｜ＰＩＤ＿ＰＯＳ｜｜ＰＩＤ＿ＲＯ｜｜ｎｏｎｃｅ１５
ＲＯ→ＰＯＳ：Ｐａｃｋａｇｅ＿２０｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿２０）］Ｋ_RO-Priv
式２１
ＰＯＳ ３０は、２で受信された証明書Ｃｅｒｔ_ROで取得された公開鍵Ｋ_RO-Pubを使用して署名を検証することができるものとしてよい。ＰＩＤ＿ＲＯにより、プロセスの関連付けを可能にすることができる。

図８に例示されている呼の流れに関して、３つのノンスが往路を進むことを示すことができる。つまり、これらは、最初に伝達した後のメッセージで返送することはできない。３つのこのようなノンスは、１０におけるｎｏｎｃｅ８、１５におけるｎｏｎｃｅ_SDM、および２１におけるｎｏｎｃｅ１５である。呼の流れの説明において示されていないけれども、これらのノンスのそれぞれについて、ノンスを含むＡＣＫが受信側によって対応する送信側に送信される（返送される）と仮定してよい。したがって、例えば、ｎｏｎｃｅ８は、１０でメッセージを受信した後に、ＴＤ_U ３４によるＡＣＫメッセージを介してＲＯ ４０に返送されうる。

１、２、９、および２１に関係するメッセージは、帯域外として指定されうる。

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

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

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

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

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

より具体的には、上記のように、通信システム９００は多元接続システムとすることができ、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡ、および同様のものなどの、１つまたは複数のチャネルアクセス方式を使用することができる。例えば、ＲＡＮ ９０４内の基地局９１４ａ、およびＷＴＲＵ ９０２ａ、９０２ｂ、９０２ｃでは、広帯域ＣＤＭＡ（ＷＣＤＭＡ）を使用してエアーインターフェース９１６を設置することができる、ユニバーサルモバイル通信システム（ＵＭＴＳ）地上波無線アクセス（ＵＴＲＡ）などの無線技術を実装することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または発展型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを備えることができる。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を備えることができる。

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

他の実施形態において、基地局９１４ａおよびＷＴＲＵ ９０２ａ、９０２ｂ、９０２ｃは、ＩＥＥＥ ８０２．１６（つまり、ＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ ＩＸ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、ＩＳ−２０００（Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ２０００）、ＩＳ−９５（Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ９５）、ＩＳ−８５６（Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ８５６）、ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、ＥＤＧＥ（Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ）、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）、および同様のものなどの無線技術を実装することができる。

図９の基地局９１４ｂは、例えば、ワイヤレスルーター、ホームノードＢ、ホームｅＮｏｄｅＢ、またはアクセスポイントとすることができ、事業所、家庭、自動車、キャンパス、および同様のものなどの、局在化されたエリア内でワイヤレス接続を円滑に行えるようにするために好適なＲＡＴを利用することができる。一実施形態において、基地局９１４ｂおよびＷＴＲＵ ９０２ｃ、９０２ｄは、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）を設置するためにＩＥＥＥ８０２．１１などの無線技術を実装することができる。別の実施形態では、基地局９１４ｂおよびＷＴＲＵ ９０２ｃ、９０２ｄは、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）を設置するためにＩＥＥＥ８０２．１５などの無線技術を実装することができる。さらに別の実施形態において、基地局９１４ｂおよびＷＴＲＵ ９０２ｃ、９０２ｄは、ピコセルまたはフェムトセルを設置するためにセルラーベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用することができる。図９に示されているように、基地局９１４ｂは、インターネット９１０との直接接続を有することができる。そうすると、基地局９１４ｂは、コアネットワーク９０６を介してインターネット９１０にアクセスする必要がなくなる。

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

コアネットワーク９０６は、ＷＴＲＵ ９０２ａ、９０２ｂ、９０２ｃ、９０２ｄがＰＳＴＮ ９０８、インターネット９１０、および／または他のネットワーク９１２にアクセスするためのゲートウェイとしても機能しうる。ＰＳＴＮ ９０８は、アナログ音声通話のみ可能な旧来の電話サービス（ＰＯＴＳ）を提供する回線交換電話網を含むものとしてよい。インターネット９１０は、ＴＣＰ／ＩＰインターネットプロトコル群に含まれる伝送制御プロトコル（ＴＣＰ）、ユーザーデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）などの、共通通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスの地球規模のシステムインを含むことができる。ネットワーク９１２は、他のサービスプロバイダによって所有され、および／または運営される有線もしくはワイヤレス通信ネットワークを含むことができる。例えば、ネットワーク９１２は、ＲＡＮ ９０４と同じＲＡＴ、または異なるＲＡＴを使用することができる、１つまたは複数のＲＡＮに接続された別のコアネットワークを含むことができる。

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

Claims (3)

1. 少なくとも１つのプラットフォームによってサポートされる複数のドメインを備える第１のデバイスを具備し、前記複数のドメインのうちのそれぞれのドメインは、前記少なくとも１つのプラットフォーム上で実行されるコンピューティングリソースの一構成を備え、前記複数のドメインのうちのそれぞれのドメインは、前記ドメインの所有者であって、ローカルに又は前記第１のデバイスからリモートに配置されうる前記ドメインの所有者に対する機能を実行するように構成されるシステムであって、前記複数のドメインのうちのそれぞれのドメインは、異なる所有者を有することができ、前記複数のドメインのうちの少なくとも１つのドメインは、前記第１のデバイスのユーザーによって所有され、前記複数のドメインのうちの少なくとも１つの他のドメインは、リモート所有者のデバイスを介して前記第１のデバイスと通信するリモート所有者によって所有されるシステムにおける方法であって、
   前記第１のデバイスが、前記第１のデバイスの前記リモート所有者ドメインを通じて前記リモート所有者によって提供される加入方式のサービスの加入ユーザーとして前記ユーザーを前記リモート所有者のデバイスに登録するステップと、
   前記第１のデバイスの前記リモート所有者ドメインが、前記ユーザーが前記加入方式のサービスを前記加入ユーザーとして利用することを可能にする資格証明を前記リモート所有者のデバイスから取得するステップと、
   前記資格証明を前記第１のデバイスの前記リモート所有者ドメインに格納するステップと、
   前記第１のデバイスの前記ユーザードメインが、前記資格証明が前記リモート所有者ドメインによって受信されたという確認応答を前記リモート所有者ドメインから受信するステップと
   を含むことを特徴とする方法。
2. 前記ユーザーを前記リモート所有者のデバイスに登録するステップは、
   前記ユーザーに代わって前記ユーザードメインが、登録の要求を開始するステップと、
   登録の前記要求に応答して前記リモート所有者ドメインが、前記ユーザーへの前記加入方式のサービスの販売を円滑にする第三者のデバイスに、前記ユーザーを前記リモート所有者に対して前記加入方式のサービスの前記加入ユーザーとして識別するために使用される識別子を要求するステップと、
   前記リモート所有者ドメインが、前記第三者のデバイスから前記識別子を受信するステップと、
   前記ユーザードメインが、登録の前記要求が受信されたという確認応答を前記リモート所有者のデバイスから受信するステップとを含むことを特徴とする請求項１に記載の方法。
3. 前記ユーザーを前記リモート所有者のデバイスに登録するステップは、
   前記ユーザードメインが、登録の前記要求に関連付けられている第１のプロセス識別子または前記ユーザーに関係する個人情報のうちの少なくとも一方を送信するステップと、
   前記ユーザードメインが、前記第三者のデバイスから、登録の前記要求に関連付けられている第２のプロセス識別子を受信するステップとをさらに含むことを特徴とする請求項２に記載の方法。

Images