JP2018063716A - 複数のドメインのシステムおよびドメイン所有権 - Google Patents

Abstract

【課題】１つまたは複数のデバイス上の１つまたは複数のドメインを１つまたは複数の異なるローカルもしくはリモートの所有者が所有または制御することを可能にし、それらのドメインのあるレベルのシステム全体の管理を実現する方法および手段を提供する。【解決手段】各々のドメインは、異なる所有者を有することができ、それぞれの所有者は、そのドメインのオペレーションに対するポリシーおよびドメインが置かれるプラットフォームおよび他のドメインに関するオペレーションに対するポリシーを指定することができる。デバイス１００において、システム全体のドメインマネージャ１０７は、それが置かれているドメイン１０６のポリシーを強制することができ、またドメイン１０６に関するそれらの各ポリシーによる他のドメインの強制を調整する。また、各ポリシーに従って他のドメイン間の相互のやり取りを調整する。【選択図】図１

Description

本発明は、通信の制御に関する。

今日、他のデバイスまたはエンティティと通信する場合も、通信しない場合もあるコンピューティングデバイスが、デバイス、またはデバイス内のある部分もしくはコンピューティング環境が個人、組織、または他の何らかのエンティティによって「所有」される形で使用される状況が多くある。「所有される」は、デバイス、またはそのデバイス内のある部分もしくはコンピューティング環境が、エンティティ内で認証されている可能性があり、またエンティティがそれ以降デバイスまたはそのデバイスの一部に対し何らかの形の制御を行っている可能性があるということを意味する。このような状況の一例は、無線モバイル通信（wireless mobile communications）業界であり、携帯電話などの無線デバイスのユーザが特定のモバイル通信ネットワーク事業者（mobile communication network operator）のサービスに加入することができる。

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

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

また、特に無線モバイル通信デバイスが背景にある場合、ＳＩＭ／ＵＩＣＣのメカニズムは非常に安全であると一般的に考えられるけれども、セキュリティはそのメカニズムが置かれているデバイス全体のセキュリティ特性に強くリンクしているわけではない。これは、モバイル金融取引などの高度なサービスおよびアプリケーションに対するスケーリングセキュリティコンセプト（scaling security concepts）の適用を制限する。特に、こうした欠点は、マシン間（Ｍ２Ｍ）通信デバイスなどの、自立的デバイスに関わるものである。

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

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

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

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

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

本明細書で説明されている方法および手段を使用することができる例示的なシステムを示す図である。 本明細書で説明されている方法および手段がユーザ装置（ＵＥ）内に具現化されるシステムの一実施形態を例示する図である。 ドメインの所有権を取得するための例示的なブートアップおよびプロセスを例示する図である。 ドメインの所有権を取得するための例示的なブートアップおよびプロセスを例示する図である。 ドメインの所有権を取得するためのプロセスの例示的な呼流れ図である。 ドメインの所有権を取得するためのプロセスの例示的な呼流れ図である。 完全なアテステーション付きのドメインの所有権を取得するためのプロセスの例示的な呼流れ図である。 完全なアテステーション付きのドメインの所有権を取得するためのプロセスの例示的な呼流れ図である。 信頼できるハードウェア加入モジュールの一実施形態の例示的な状態定義、遷移、および制御点定義を示す図である。 リモートの所有者ドメインが達成しうる例示的な状態および動的に管理された環境において遷移が発生しうる条件を示す図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これらのドメインのうちの１つまたは複数は、信頼できる加入識別管理（Trusted Subscription Identity Management）（ＴＳＩＭ）などの加入管理機能を実行することができる。ＴＳＩＭ機能を持つ複数のドメインが単一のＴＨＳＭ上に存在しうるため、ＴＨＳＭは、複数のＲＯに対して加入管理をサポートすることができる。ＴＳＩＭ対応ドメインの管理のいくつかの態様は、システム全体のドメインマネージャ（ＳＤＭ）と称される単一の管理機能によって実行されうる。他の態様は、個別のドメイン内で、または個別のドメイン上で、個別に管理されうる。

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

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

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

ＴＳＩＭは、ソフトウェアユニットまたは仮想アプリケーションであってよい。ＴＳＩＭは、最初に、特定のネットワーク通信事業者またはパブリックランドモバイルネットワーク（ＰＬＭＮ）に関連する資格証明を有していなくてもよい。ＴＳＩＭは、ＵＭＴＳセルラーアクセスネットワークの加入資格証明／アプリケーションの管理を指すものとしてよい。例えば、ＴＳＩＭは、ＵＭＴＳ認証鍵などの強い秘密（Ｋｉ）の管理を含むことができる。Ｍ２Ｍの背景状況において、ＴＳＩＭは、Ｍ２Ｍ接続性識別管理（ＭＣＩＭ）も含みうる。

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

ＴＨＳＭは、完全性基準を保護されたストレージに格納するように構成された、ＴＰＭまたはＭＴＭに見られるストレージ用の信頼の基礎（root of trust for storage）（ＲＴＳ）に似た、「ストレージのコアＲｏＴ（ＣＲＴＳ）」ユニットを備えることができる。ＴＨＳＭは、ＴＨＳＭの完全性測定結果を外部チャレンジャに報告するように構成された、ＴＰＭまたはＭＴＭに見られる報告用の信頼の基礎（root of trust for reporting）（ＲＴＲ）に似た、「報告のコアＲｏＴ（ＣＲＴＲ）」ユニットを備えることもできる。

したがって、ＴＨＳＭは、信頼測定、ストレージ、および報告に関してＴＰＭまたはＭＴＭに似た機能を効果的に実現することができる。ＴＨＳＭは、複数のトラステッドステークホルダーエンジン（trusted stakeholder engines）を実現する機能を備えることもできる。さらに、ＴＨＳＭは、各マルチプルステークホルダートラステッドサブシステム（multiple-stakeholder trusted subsystems）を実現するように構成することができる。したがって、ＴＨＳＭは、ＴＣＧモバイルフォンワーキンググループ（ＭＰＷＧ）の仕様によって定められているような信頼できる携帯電話に似たものとしてよい。

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

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

ＤＭのドメイン以外のドメインは、ドメインの所有者によって「請求」または「所有」される前に、リモート所有権取得（ＲＴＯ）プロセスを受ける必要があるものとしてよい。特定のドメインがＲＴＯプロセスを通る前に、指定されていない所有者の「手つかずの」ドメインが存在する可能性がある。この場合、ドメインに対して請求される特定の所有権はない。

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

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

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

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

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

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

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

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

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

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

ＴＨＳＭは、ＲＯのドメインに対してＲＴＯプロセスを実行する場合、リモートの所有権取得プロトコルの完了前に４つの明確に区別されるシステム状態に至ることができるように構成されうる。ＴＨＳＭプレブートシステム状態は、ＴＨＳＭが「電源オン」されていないことを示すものとしてよい。ＴＨＳＭ＿ＴＤ_DM＿ＬＯＡＤ＿ＣＯＭＰＬＥＴＥシステム状態は、ＴＨＳＭ上のＤＭのドメインがＴＨＳＭの電源オン後の最初のステップとして構築またはロードされていることを示すものとしてよい。ＴＨＳＭ＿ＴＤ_DO＿ＬＯＡＤ＿ＣＯＭＰＬＥＴＥシステム状態は、ＤＯのドメイン（ＴＤ_DO）が利用可能な最終構成に合わせて構築またはロードされたことを示すものとしてよい。この「利用可能な最終構成」は、ＤＯのドメインがそれ自体のためにＲＴＯプロセスに通ったことがない場合に、「手つかずの」構成であるか、または「事後ＲＴＯ」構成であるものとすることができる。ＤＭのドメインは、ＤＯのドメインを構築またはロードすることができる。ＤＯのドメインが少なくとも１つのＲＴＯプロセスを通る前に、ＤＯのドメインは、「手つかずの」状態にあり、特定のＤＯによって請求または所有されることはありえない。「手つかずの」ドメインは、「シェル」を含むことができる。はじめてＤＯのドメインが構築またはロードされたときには、「利用可能な最終構成」（これ以降、最終構成（Last Configuration）と称する）は事前構成ファイルに由来するものである。あるいは、「最終構成」が、ＲＯのドメインに対するＲＴＯプロセスによるものである場合、ＴＨＳＭ上の特定のドメインは、少なくとも１回、リモート所有権取得プロトコルを通り、リモートの所有者は、ＴＳＳ_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は、ＴＤ_DOを構築することができる（ＴＤ_DOはＳＤＭを含むことができる）。符号３４４で、ＴＨＳＭは、保存済み構成ファイルを使用して、例えば、ドメインを構築することができる（前のＲＴＯがあるため利用可能である場合がある）。符号３４６で、ＴＨＳＭは、ＴＤ_DO構築状態（ＳＤＭを含む）に到達することができ、ＴＤ_DOは、ＤＯによって未請求であるか、または請求済みであるものとしてよい。符号３５０で、ＴＤ_DOはＴＤ_uを構築することができる。符号３５２で、ＤＯから入力を受け取ることができる。符号３５４で、ＴＨＳＭは、ＴＤ_u構築状態に到達することができ、ＴＤ_uは、未請求であるか、または請求済みであるものとしてよい。符号３５６で、ＴＨＳＭは、ＤＯまたはＤＵから入力を受け取ることができる（例えば、ファイルまたはインタラクティブな操作によって、ＤＯがどのドメインを構築したいかを指定する）。符号３５８で、ＴＤ_DOは、ＲＯドメイン、ＴＤ_ROを構築することができる。

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

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

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

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

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

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

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

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

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

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

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

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

第３の実施形態を参照すると、信号送受信は、
Ｄｅｆ）Ｐａｃｋａｇｅ＿１＝「ＭＥベースコードブート完了＆ＭＴＥロード」ＭＳＧ｜｜ｎｏｎｃｅ＿１｜｜ＩＤ_ME ＭＥ→ＴＨＳＭのＴＤ_DO：Ｐａｃｋａｇｅ＿１｜｜［ＳＨＡ−Ｘ（Ｐａｃｋａｇｅ＿１）］_{Ktemp_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_R}：ＤＰ_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_}ＲＯの所有権を要求するリモートの所有者を含んでいてもよい。

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

図４をなおも参照すると、ベースコードブートは、符号４１でＭＥ４０２によって実行されうる。符号４１５で、ＴＨＳＭは安全にブートすることができる。ＴＨＳＭは、ＳＤＭが含まれる、ＤＯのドメインをロードすることができ、ＳＤＭは、１）ドメイン構築に利用可能なリソース、および／または２）ユーザへの受け入れ可能なドメインのリストを備えることができる。符号４２で、ＴＨＳＭはそのブートを完了することができる。符号４２５で、ＭＥはそのブートを完了することができる。符号４３で、ＭＥはそのブートが完了していることを示すことができる。このプロセスにおいて、ＤＭのドメインが構築され、オプションのユーザドメイン（ＭＥｕ）も構築され、また利用可能なリソースがチェックされる。ＤＭのドメインは、ＭＥデバイスに対するドメインポリシーの初期構成および仕様を提供するＭＥ_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は、ＲＯに、ＴＰＩＡ、ＴＰＥＳ、およびＳＣＡＲＤのハッシュ値を、これらの測定結果を全部送信する代わりに、送信することができる。ＲＯは、単独で、またはＴＴＰを使って、そのようなハッシュ値を検証し、それによりＴＤＲＯおよび周囲システムの実行可能性の評価を行う手段を有することができる。この方法は、特許文献１において指定されているような、半自立妥当性確認（ＳＡＶ）に類似しているものとしてよい。アテステーション段階で、ＴＰＩＡ、ＴＰＥＳ、およびＳＣＡＲＤ測定のうちの１つまたは２つを送出することができる。

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

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

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

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

Claims (3)

1. システムであって、
   １つまたは複数のデバイスであって、それぞれのデバイスは、少なくとも１つのプラットフォームによってサポートされる１つまたは複数のドメインを備え、それぞれのドメインは、前記少なくとも１つのプラットフォーム上で実行されるコンピューティングリソースの一構成を備え、それぞれのドメインは、前記ドメインからローカルまたはリモートに配置されうる前記ドメインの所有者に対する機能を実行するように構成され、それぞれのドメインは、異なる所有者を有することができ、それぞれの所有者は、そのドメインのオペレーションに対するポリシーだけでなく前記ドメインが置かれるプラットフォームおよび他のドメインに関するそのドメインのオペレーションに対するポリシーを指定することができる１つまたは複数のデバイスと、
   前記ドメインのうちの１つに置かれているシステム全体のドメインマネージャであって、前記システム全体のドメインマネージャはそれが置かれている前記ドメインの前記ポリシーを強制し、前記システム全体のドメインマネージャが置かれている前記ドメインに関して前記他のドメインの各ポリシーの強制を調整し、各ポリシーおよび前記システム全体のドメインマネージャが置かれている前記ドメインのポリシーに従って前記他のドメイン間のインタラクティブなやり取りを調整するシステム全体のドメインマネージャと
   を備えることを特徴とするシステム。
2. 前記システム全体のドメインマネージャは、ドメイン所有者に情報を提供し、前記所有者がそのポリシーに従っているかどうかを判定することを可能にすることを特徴とする請求項１に記載のシステム。
3. 前記システム全体のドメインマネージャが置かれている前記ドメインは、そのドメインが置かれている前記デバイスの所有者によって所有されることを特徴とする請求項１に記載のシステム。