JP6533203B2 - 複数のアクセス制御クライアントをサポートするモバイル装置、及び対応する方法 - Google Patents

Description

（優先権）
本出願は、２０１３年２月１４日に本出願と同時出願された米国特許出願第１３／７６７，５９３号「METHODS AND APPARATUS FOR LARGE SCALE DISTRIBUTION OF ELECTRONIC ACCESS CLIENTS」に対する優先権を主張し、これは更に、２０１２年２月１４日に出願された米国仮特許出願第６１／５９８，８１９号「METHODS AND APPARATUS FOR LARGE SCALE DISTRIBUTION OF ELECTRONIC ACCESS CLIENTS」に対する優先権を主張し、上記のそれぞれは、参照によりその全体が本明細書に組み込まれる。

（関連出願）
本出願は、共同出願で同時係属の米国特許出願第１３／４５７，３３３号（２０１２年４月２６日出願）「ELECTRONIC ACCESS CLIENT DISTRIBUTION APPARATUS AND METHODS」、同第１３／４６４，６７７号（２０１２年５月４日出願）「METHODS AND APPARATUS FOR PROVIDING MANAGEMENT CAPABILITIES FOR ACCESS CONTROL CLIENTS」、同第１３／０９５，７１６号（２０１１年４月２７日出願）「APPARATUS AND METHODS FOR DISTRIBUTING AND STORING ELECTRONIC ACCESS CLIENTS」、同第１３／０８０，５５８号（２０１１年４月５日出願）「APPARATUS AND METHODS FOR CONTROLLING DISTRIBUTION OF ELECTRONIC ACCESS CLIENTS」、同第１２／９５２，０８２号（２０１０年１１月２２日出願）「WIRELESS NETWORK AUTHENTICATION APPARATUS AND METHODS」、同第１２／９５２，０８９号（２０１０年１１月２２日出願）「APPARATUS AND METHODS FOR PROVISIONING SUBSCRIBER IDENTITY DATA IN A WIRELESS NETWORK」、同第１３／１８３，０２３号（２０１１年７月１４日出願）「VIRTUAL SUBSCRIBER IDENTITY MODULE DISTRIBUTION SYSTEM」、同第１２／３５３，２２７号（２００９年１月１３日出願）「POSTPONED CARRIER CONFIGURATION」、同第１３／０９３，７２２号（２０１１年４月２５日出願）「APPARATUS AND METHODS FOR STORING ELECTRONIC ACCESS CLIENTS」、同第１３／１０９，８５１号（２０１１年５月１７日出願）「METHODS AND APPARATUS FOR ACCESS CONTROL CLIENT ASSISTED ROAMING」、同第１３／０７９，６１４号（２０１１年４月４日出願）「MANAGEMENT SYSTEMS FOR MULTIPLE ACCESS CONTROL ENTITIES」、同第１３／１１１，８０１号（２０１１年５月１９日出願）「METHODS AND APPARATUS FOR DELIVERING ELECTRONIC IDENTIFICATION COMPONENTS OVER A WIRELESS NETWORK」、同第１３／０８０，５２１号（２０１１年４月５日出願）「METHODS AND APPARATUS FOR STORAGE AND EXECUTION OF ACCESS CONTROL CLIENTS」、同第１３／０７８，８１１号（２０１１年４月１日出願）「ACCESS DATA PROVISIONING APPARATUS AND METHODS」、同第１３／２８７，８７４号（２０１１年１１月２日出願）「METHODS AND APPARATUS FOR ACCESS DATA RECOVERY FROM A MALFUNCTIONING DEVICE」、同第１３／０８０，５３３号（２０１１年４月５日出願）「SIMULACRUM OF PHYSICAL SECURITY DEVICE AND METHODS」、及び同第１３／２９４，６３１号（２０１１年１１月１１日出願）「APPARATUS AND METHODS FOR RECORDATION OF DEVICE HISTORY ACROSS MULTIPLE SOFTWARE EMULATION」に関連し、上記のそれぞれは、参照によりその全体が本明細書に組み込まれる。

本開示は、全般的に、無線通信及びデータネットワークの分野に関する。より具体的には、本発明は特に、電子アクセス制御クライアントの大規模配信のための方法及び装置に関する。

アクセス制御は、従来技術の無線通信システムの多くにおいて、セキュアな通信のために必要である。一例として、１つの単純なアクセス制御方式は、（ｉ）通信者のアイデンティティを確認すること、及び（ｉｉ）その確認されたアイデンティティに対応するアクセスレベルを与えること、を含み得る。例示的なセルラーシステム（例えば、ユニバーサル移動体通信システム（ＵＭＴＳ））のコンテキストにおいて、アクセス制御は、物理的なユニバーサル集積回路カード（ＵＩＣＣ）（「ＳＩＭカード」とも呼ばれる）の上で実行されるユニバーサル加入識別モジュール（ＵＳＩＭ）と呼ばれるアクセス制御クライアントによって管理される。ＵＳＩＭアクセス制御クライアントは、ＵＭＴＳセルラーネットワークに対する加入者を認証する。認証が成功した後、その加入者はセルラーネットワークに対するアクセスが認められる。本明細書で以下に使用される用語「アクセス制御クライアント」は一般に、ネットワークに対する第１の装置のアクセスを制御するのに適した、ハードウェア又はソフトウェア内のいずれかで実現された論理エンティティを指す。アクセス制御クライアントの一般的な例としては、上述のＵＳＩＭ、ＣＤＭＡ加入者識別モジュール（ＣＳＩＭ）、ＩＰマルチメディアサービス識別モジュール（ＩＳＩＭ）、加入者識別モジュール（ＳＩＭ）、除去可能ユーザ識別モジュール（ＲＵＩＭ）などが挙げられる。

従前のＳＩＭカードに基づいたアプローチは、数多くの問題を抱えている。例えば、従来のＵＩＣＣは単一のＵＳＩＭ（又はより一般的には「ＳＩＭ」）アクセス制御クライアントのみをサポートしている。別のＳＩＭを使用してセルラーネットワークへの認証を受けたい場合は、ユーザは機器のＳＩＭカードを別のＳＩＭカードと物理的に交換しなければならない。一部の機器は２枚のＳＩＭカードを同時に収容するように設計されている（デュアルＳＩＭ電話）。しかしながら、そのようなデュアルＳＩＭ電話はＳＩＭカード機器の基本的な物理的制限に対処するものではない。例えば、一方のＳＩＭカード内に記憶されている情報を、もう一方のＳＩＭカード内に記憶されている情報と統合することは容易にはできない。既存のデュアルＳＩＭ機器は、両方のＳＩＭカードの内容に同時にアクセスすることはできない。

更に、ＳＩＭカードにアクセスするには、ユーザが知覚できる長さの時間を必要とする。ＳＩＭカードを切り替えて情報を移すのは望ましくなく、従来型及びデュアルＳＩＭ機器の両方において問題である。

加えて、既存のＳＩＭカード発行者とアクチベーションエンティティは一般にネットワークごとに固有であり、別のネットワークの別のユーザにとってはユビキタスではない。具体的には、所与のネットワーク内の所与のユーザは、自分の電話をアクチベートするか、又は、ＳＩＭ発行を認定されたごく特定されたエンティティから交換用ＳＩＭカードを入手する必要がある。これは、例えば、他のネットワークを経たローミング、電話機の交換などの場合に、有効なアクセス特権をユーザが迅速に取得する可能性を大幅に制限する可能性がある。

最近では、例えば本明細書の譲受人により、電子ＳＩＭ（ｅＳＩＭと呼ばれる）が開発されている。この電子ＳＩＭは、別のｅＳＩＭとの交換、別の機器への転送などに関して、強化された柔軟性を提供する。しかしながら、ＳＩＭの配信とアクチベーションを行うための既存のネットワークのインフラストラクチャはこの進歩に追いついていない。

したがって、電子アクセスクライアント（例えば、ｅＳＩＭ）により提供される強化された柔軟性を推進するため、及び、電子アクセスクライアントのセキュアでユビキタスな配信をサポートするために、新しいソリューションとインフラストラクチャが必要とされている。

本開示は特に、電子アクセス制御クライアントの大規模配信を提供する。

第１に、電子アクセス制御クライアントの大規模配信のための方法が開示される。例示的な一実施形態において、この方法には、１つ以上の電子アクセス制御クライアントの所有権を確立することと、１つ以上の電子アクセス制御クライアントが以前に複製されていないかどうかを判定することと、１つ以上の電子アクセス制御クライアントを、第２の機器への転送のために暗号化することと、その暗号化された１つ以上の電子アクセス制御クライアントを交換することとが含まれる。

電子アクセス制御クライアントの大規模配信のための装置が更に開示される。例示的な一実施形態において、この装置は、プロセッサと、永続的コンピュータ可読媒体とを含み、このコンピュータ可読媒体は、このプロセッサによって実行されたときに、１つ以上の電子アクセス制御クライアントの所有権を確立し、１つ以上の電子アクセス制御クライアントが以前に複製されていないかどうかを判定し、１つ以上の電子アクセス制御クライアントを、第２の機器への転送のために暗号化し、その暗号化された１つ以上の電子アクセス制御クライアントを交換する、命令を含む。

電子アクセス制御クライアントのトランザクションのためのモバイル機器が更に開示される。一実施形態において、この機器は、無線ネットワークと通信するように構成された無線インタフェースと、このインタフェースとデータ通信するプロセッサと、このインタフェースとデータ通信するセキュアエレメントとを含む。一変異において、このセキュアエレメントは、セキュアプロセッサと、そのセキュアプロセッサとデータ通信し、少なくともその中に記憶されたネットワークとの認証のために有用な複数のアクセス制御クライアントを有する、セキュアな記憶装置と、そのセキュアプロセッサとデータ通信する論理であって、この論理は、複数のアクセス制御クライアントを記憶し、これにアクセスし、装置へ転送し又は装置から転送するように構成されている、論理と、少なくともこのセキュアエレメントと通信を行い、その装置のユーザが、記憶されている複数のアクセス制御クライアントのうちの１つを選択することができるように構成され、その装置をそのネットワークに対して認証して、その中での通信を可能にする、ユーザインタフェース論理とを含む。

無線システムが更に開示される。

加えて、コンピュータ可読装置が開示される。一実施形態において、この装置は、その上に配置されたコンピュータプログラムを有する記憶媒体を含み、このプログラムは、実行されたときに、電子アクセス制御クライアントを配信するように構成されている。

加えて、電子アクセスクライアントを備えた無線モバイル機器を提供するためのネットワークアーキテクチャが開示される。一実施形態において、このアーキテクチャには、複数のブローカーと、その複数のブローカーとデータ通信する複数のメーカーとが含まれる。一変異において、所与のユーザモバイル機器は、複数のブローカーによってサービスを受けることができ、このブローカーのいずれも、１つ以上のメーカーに、電子アクセスクライアントを注文することができる。

１つ以上のモバイル機器に電子アクセスクライアントを提供する装置が更に開示される。一実施形態において、この装置は、少なくとも１つのプロセッサと、その少なくとも１つのプロセッサとデータ通信する、この装置にアクセスクライアントの暗号化及び暗号復号を実行させるように構成されている、第１の論理と、その少なくとも１つのプロセッサとデータ通信する、この装置に対し、このアクセスクライアントが複製されていないことを確実にさせるように構成されている、第２の論理と、その少なくとも１つのプロセッサとデータ通信する、この装置に対し、このアクセスクライアントのユーザの信用、所有権、及び／又は検証のうちの少なくとも１つを確立させるように構成されている、第３の論理と、を含む。

電子アクセス制御クライアントの失効手順が更に開示される。一実施形態において、この手順には、証明書を記憶する１つ以上の装置に関連付けられている、証明書を発行した証明書署名権限が侵害されているかどうかを判定することと、証明書の初期要求が生成されたときに、生成されたその証明書サービス要求を１つ以上の装置で判定することと、その判定された証明書サービス要求を使用して新しい証明書を要求することと、その要求に基づいて新しい証明書を発行することと、が含まれる。一変異において、１つ以上の装置が、以前使用された秘密鍵を、この要求の一部として使用することができ、新しい証明書は、以前の秘密鍵に対応する以前の公開鍵を含んで発行される。

他の特徴及び有利点は、添付図面、及び以下に記載されるような例示的実施形態の詳細な説明を参照することで、当業者によって即座に認識されるであろう。

本開示の様々な態様に関連して有用な、１つの例示的な電子ユニバーサル集積回路カード（ｅＵＩＣＣ）の論理ブロック図である。 本開示の様々な態様に関連して有用な、１つの例示的な電子加入者識別モジュール（ｅＳＩＭ）ディレクトリ構造の論理ブロック図である。 本開示の様々な態様に関連して有用な、加入者識別モジュール（ＳＩＭ）専用ファイル（ＳＤＦ）のための、１つの例示的なステートマシンを表わす論理ブロック図である。 本開示の様々な態様に関連して有用な、ｅＳＩＭ動作のための、１つの例示的なステートマシンを表わす論理ブロック図である。 本開示の様々な実施形態に関連して有用な、１つの例示的なｅＳＩＭブローカーネットワークの図である。 本開示の様々な実施形態に関連して有用な、１つの例示的な階層セキュリティプロトコルの論理ブロック図である。 本開示の様々な態様に関連して有用な、３つの要素を含む１つの例示的なデータ構造の図である。 本開示の様々な態様に関連して有用な、１つの例示的なＯＥＭ認証階層の図である。 パーソナライズなしでｅＳＩＭを機器に配信するための、１つの例示的な論理シーケンスの初期段階を表わす論理フロー図である。 パーソナライズなしでｅＳＩＭを機器に配信するための、１つの例示的な論理シーケンスの最終段階を表わす論理フロー図である。 事前パーソナライズを伴ってｅＳＩＭを機器に配信するための、１つの例示的な論理シーケンスの初期段階を表わす論理フロー図である。 事前パーソナライズを伴ってｅＳＩＭを機器に配信するための、１つの例示的な論理シーケンスの中間段階を表わす論理フロー図である。 事前パーソナライズを伴ってｅＳＩＭを機器に配信するための、１つの例示的な論理シーケンスの最終段階を表わす論理フロー図である。 ｅＳＩＭのバッチを機器に配信するための、１つの例示的な論理シーケンスの初期段階を表わす論理フロー図である。 ｅＳＩＭのバッチを機器に配信するための、１つの例示的な論理シーケンスの最終段階を表わす論理フロー図である。 電子ユニバーサル集積回路カード（ｅＵＩＣＣ）装置の論理図である。 電子加入者識別モジュール（ｅＳＩＭ）デポ装置の論理図である。 １つの代表的なユーザ装置を示す論理フロー図である。 電子アクセス制御クライアントの大規模配信のための方法の一実施形態を示す論理フロー図である。

全ての図は、２０１２年から２０１３年に作成され、その全ての著作権はＡｐｐｌｅ Ｉｎｃ．が保持している。

ここで図面を参照するが、全体を通して、同様の番号は同様の部分を指す。

例示的実施形態の説明
本開示の例示的実施形態及び態様が、ここに詳しく記述される。これらの実施形態及び態様は主に、ＧＳＭ（登録商標）、ＧＰＲＳ／ＥＤＧＥ、又はＵＭＴＳセルラーネットワークの加入者識別モジュール（ＳＩＭ）のコンテキストで主に議論されるが、当業者には、本開示がそのように限定されないことが理解されよう。実際、本開示の様々な特徴は、アクセス制御クライアントを機器に記憶及び配信することで利益が得られる可能性がある任意のネットワーク（無線セルラー又はその他かどうかを問わず）において有用である。

本明細書で使用される用語「クライアント」及び「ＵＥ」には、無線使用可能な携帯電話、スマートホン（例えばｉＰｈｏｎｅ（商標）など）、無線使用可能なパーソナルコンピュータ（ＰＣ）、モバイル機器（例えばハンドヘルドコンピュータ、ＰＤＡ、パーソナルメディア装置（ＰＭＤ）、無線タブレット（例えばｉＰａｄ（商標）など）、いわゆる「ファブレット」、又はこれらの任意の組み合わせが挙げられるが、これらに限定されない。

本明細書で以下に使用される用語「加入者識別モジュール（ＳＩＭ）」、「電子ＳＩＭ（ｅＳＩＭ）」、「プロファイル」、及び「アクセス制御クライアント」は、一般に、ネットワークに対する第１の装置のアクセスを制御するのに適した、ハードウェア又はソフトウェア内のいずれかで実現された論理エンティティを指す。アクセス制御クライアントの一般的な例としては、上述のＵＳＩＭ、ＣＤＭＡ加入者識別モジュール（ＣＳＩＭ）、ＩＰマルチメディアサービス識別モジュール（ＩＳＩＭ）、加入者識別モジュール（ＳＩＭ）、除去可能ユーザ識別モジュール（ＲＵＩＭ）など、又はこれらの任意の組み合わせが挙げられる。

用語「加入者識別モジュール」が本明細書で使用されるとき（例えばｅＳＩＭ）、この用語は、下記であるかどうかを必ずしも意味せず又は必要ともしないことが理解されよう。（ｉ）本質的に加入者による使用（すなわち、本開示の様々な機能が、加入者又は非加入者によって実践し得る）、（ｉｉ）単一個人の識別（すなわち、本開示の様々な特徴が、家族などの個人集団、あるいは企業などの無形又は架空のエンティティのために実践され得る）、あるいは（ｉｉｉ）任意の有形の「モジュール」装置又はハードウェア。

例示的なｅＵＩＣＣ及びｅＳＩＭの動作
ここで、本開示の様々な特徴及び機能が、１つの例示的な実装に関して議論される。本開示の例示的な実施形態のコンテキストにおいて、従来技術におけるような物理的なＵＩＣＣを使用する代わりに、ＵＩＣＣが、例えばソフトウェアアプリケーションのような仮想又は電子エンティティ（以下、電子ユニバーサル集積回路カード（ｅＵＩＣＣ）と呼ばれる）としてエミュレートされ、これは、ＵＥ内のセキュアエレメント（例えばセキュアなマイクロプロセッサ又は記憶装置）内に収容される。ｅＵＩＣＣは、以下、電子加入者識別モジュール（ｅＳＩＭ）として呼ばれる、複数のＳＩＭ要素を記憶及び管理することができる。各ｅＳＩＭは、典型的なＵＳＩＭのソフトウェアシミュレーションであり、相似プログラミング及びそれに関連するユーザデータを含む。ｅＵＩＣＣは、ｅＳＩＭのＩＣＣ−ＩＤに基づいてｅＳＩＭを選択する。ｅＵＩＣＣが所望のｅＳＩＭを選択すると、ＵＥは、ｅＳＩＭの対応するネットワークオペレータから無線ネットワークサービスを取得するための認証手順を開始することができる。

ｅＵＩＣＣソフトウェアアーキテクチャ
ここで図１を参照し、本開示に関連して有用な、１つの例示的な電子ユニバーサル集積回路カード（ｅＵＩＣＣ）が示されている。例示的なｅＵＩＣＣの例は、前記で参照により全体が本明細書に組み込まれた、同出願で同時係属の米国特許出願第１３／０９３，７２２号（２０１１年４月２５日出願）「APPARATUS AND METHODS FOR STORING ELECTRONIC ACCESS CLIENTS」に記述されており、ただし他のものも本開示に一貫して使用し得ることが理解されよう。

図１は、１つの例示的なＪａｖａ Ｃａｒｄ（登録商標）ｅＵＩＣＣアーキテクチャである。スマートカードに利用するための他のオペレーティングシステム（ＯＳ）の例としては、ＭＵＬＴＯＳ及び独自仕様のＯＳが挙げられ（これらに限定されない）、Ｊａｖａ Ｃａｒｄは単に説明目的である。ＯＳは、アプリケーションソフトウェアとハードウェアの間のインタフェースを提供する。一般に、ＯＳは、入力出力（Ｉ／Ｏ）、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、不揮発性メモリ（ＮＶ）（ＥＥＰＲＯＭ、フラッシュ）などのために構成されたサービス及び機能を含む。ＯＳは更に、高次の層、メモリ及びファイル管理、並びに通信プロトコルに使用される暗号サービスを提供し得る。

例示的なＪａｖａ実装は、次の３つの部分から成る。Ｊａｖａカード仮想マシン（ＪＣＶＭ）（バイトコードインタプリタ）、Ｊａｖａカードランタイム環境（ＪＣＲＥ）（カードリソース、アプレット実行、及びその他のランタイム特徴を管理する）、及びＪａｖａアプリケーションプログラミングインタフェース（ＡＰＩ）（スマートカードアプリケーションをプログラミングするための一組のカスタマイズされたクラス）。

ＪＣＶＭはカード上の構成要素（バイトコードインタプリタ）と、カード外の相対物（コンバータ）とを有する。カードリソースの制限により、コンバータがいくつかのコンパイルタスクを実施することができる。最初、Ｊａｖａコンパイラは、ソースコードからクラスファイルを作成する。コンバータは、クラスファイルをプリプロセスし、ＣＡＰファイルを作成する。コンバータは、Ｊａｖａクラスのロードイメージが良好に形成されていることを確認し、Ｊａｖａカードの言語サブセット違反をチェックし、更に他のいくつかのタスクを実行する。ＣＡＰファイルはＪａｖａパッケージ内のクラスの実行可能バイナリ表現を含む。コンバータは更に、エクスポートファイルを生成し、これは公開ＡＰＩ情報を含む。ＣＡＰファイルのみが、カードにロードされる。もう１つの広く使用されるフォーマットがＩＪＣであり、これはＣＡＰファイルからコンバートすることができる。ＩＪＣファイルは、ＣＡＰファイルに比べ、大きさがやや小さい可能性がある。

典型的に、カードにアプレットをダウンロードするには、ＣＡＰファイルの内容をカードの永続性メモリにロードするために、アプリケーションプロトコルデータ単位（ＡＰＤＵ）交換が必要である。このオンカードインストーラは更に、ＣＡＰファイルのクラスをカード上の他のクラスとリンクさせ得る。その後、インストールプロセスはアプレットのインスタンスを生成し、ＪＣＲＥでインスタンスを登録する。アプレットは、選択されるまで、サスペンド状態に維持される。

上述の手順は、１つ以上のセキュリティ層を追加で実施し得る。例示的な一実施形態において、グローバルプラットフォーム（ＧＰ）はアプリケーションを管理するためのセキュアプロトコルを提供する。ＧＰはセキュアな発行者セキュリティドメイン内で動作し、これはカード発行者のオンカード表現である。カードは更に、例えばアプリケーションプロバイダのために、他のセキュリティドメインを実行し得る。

例示的な一実施形態において、ｅＵＩＣＣは取り外しができない機器コンポーネントである。動作中、ｅＵＩＣＣはセキュアなブートストラップＯＳを実行する。ブートストラップＯＳは、ｅＵＩＣＣがセキュアであることを確実にし、その中のセキュリティプロトコルの実施を管理する。セキュアなブートストラップＯＳの例は、共同出願で同時係属の米国特許出願第１３／０８０，５２１号（２０１１年４月５日出願）「METHODS AND APPARATUS FOR STORAGE AND EXECUTION OF ACCESS CONTROL CLIENTS」に記述されており、これは上記で参照によりその全体が組み込まれている。更に、様々な移動体通信事業者（ＭＮＯ）が、ｅＳＩＭをカスタマイズして、様々な度合のサービス差別化をサポートし得ることが理解されよう。カスタマイズの一般的な例には、独自仕様のファイル構造及び／又はソフトウェアアプリケーションが挙げられるがこれらに限定されない。ｅＳＩＭの構成可能性により、ｅＳＩＭはその大きさが顕著に変化し得る。

従来技術のＳＩＭカードとは異なり、ｅＳＩＭは、セキュアなトランザクションにより機器間で自由に交換することができる。加入者は、機器間でＳＩＭを移動するのに「物理的なカード」を必要としない。ただし、ｅＳＩＭの実際のトランザクションは、例えば特定のセキュリティプロトコルを介して、確実なセキュリティで保護されなければならない。例示的な一実施形態において、ｅＳＩＭは、特定の受信者に対して暗号化されてから配信される。いくつかの変異において、暗号化された内容に加え、各ｅＳＩＭが、平文であるメタデータ部分を含み得る。更に暗号化署名を使用して、平文内容の完全性を確保することができる。このメタデータ部分は、非セキュアな記憶装置などを支援するため、（セキュアでないエンティティに対してであっても）自由に提供し得る。

ｅＳＩＭソフトウェアアーキテクチャ
ここで図２を参照し、例示的なｅＵＩＣＣ内に実施されている、１つの例示的な電子加入者識別モジュール（ｅＳＩＭ）ディレクトリ構造が開示されている。図示のように、ｅＳＩＭディレクトリ構造は、ｅＳＩＭにより提供される柔軟性をサポートするよう改変されている。例えば、このｅＳＩＭディレクトリ構造は特に次のものを含む。（ｉ）インストールされているｅＳＩＭのリストを含むＥＦｅＳｉｍＤｉｒ、（ｉｉ）ｅＵＥＣＣをグローバル、一意に特定するカードシリアル番号を含むＥＦｃｓｎ、（ｉｉｉ）１つ以上のｅＵＩＣＣ証明書に対応するセキュリティ関連データ及び秘密鍵を記憶するＤＦｓｅｃｕｒｉｔｙ。そのような一変異において、ＤＦｓｅｃｕｒｉｔｙ情報には次のものが含まれる。（ｉ）ｅＵＩＣＣプラットフォームレベルＰＣＦを含むＤＦｅｐｃｆ、（ｉｉ）ルート証明書及びＯＥＭ一般名を含むＥＦｏｅｍｃｅｒｔ（ＯＥＭ認証情報は、例えば工場リファビッシュなどの特殊な操作に使用され得る）、（ｉｉｉ）ｅＵＩＣＣの証明書であるＥｆｅＵＩＣＣｃｅｒｔ、（ｉｖ）サーバＬ１アプライアンスのルート証明書であるＥＦｓＬ１ｃｅｒｔ、（ｖ）サーバＬ２アプライアンスのルート証明書であるＥＦｓＬ２ｃｅｒｔ、及び、（ｖｉ）サーバＬ３アプライアンスのルート証明書であるＥＦｓＬ３ｃｅｒｔ。

例示的な一実施形態において、このディレクトリ構造は更に、あるｅＳＩＭに固有のファイル構造を含むＳＩＭ専用ファイル（ＳＤＦ）を含む。各ＳＤＦはＭＦの直下に位置する。各ＳＤＦは名前属性と、例えば、集積回路カード識別子（ＩＣＣＩＤ）などのＳＩＤ（ｅＳＩＭ ＩＤ）を有する。図示のように、各ＳＤＦは更に、ＤＦｐｒｏｆｉｌｅｓ及びＤＦｃｏｄｅｓを含む。更に、一変異において、すべてのプロファイルＰＣＦ関連ＥＦは、ＤＦｐｐｃｆの下に記憶され、ＤＦｐｐｃｆはＤＦｐｒｏｆｉｌｅの下に記憶される。

例示的な一実施形態において、ＤＦｐｒｏｆｉｌｅ情報には次のものが含まれる。（ｉ）ｅＳＩＭの記述であるＥＦｎａｍｅ（ｅＳＩＭの名前とバージョンなど）、（ｉｉ）ｅＳＩＭのタイプを記述するＥＦｔｙｐｅ（例えば、レギュラー、ブートストラップ、及びテストなど）。ソフトウェアアプリケーションは、この情報を、例えば、ブートストラップｅＳＩＭが使用中のときにアイコンを表示するために使用することができる。（ｉｉｉ）ｅＳＩＭをサポートするのに必要なｅＵＩＣＣソフトウェアの最小バージョン番号であるＥＦｓｙｓ＿ｖｅｒ、（ｉｖ）ｅＳＩＭが必要とする不揮発性メモリの最小量を示すＥＦｎｖ＿ｍｉｎ、（ｖ）必要な揮発性メモリの最小量を示すＥＦｒａｍ＿ｍｉｎ、（ｖｉ）オーバーザエアートランザクション（ＯＴＡ）のために確保される不揮発性メモリの量を示すＥＦｎｖ＿ｒｓｖｄ、及び（ｖｉｉ）ＯＴＡのために確保される揮発性メモリの量を示すＥＦｒａｍ＿ｒｓｖｄ。

例示的な一実施形態において、ＤＦｃｏｄｅ情報は各ｅＳＩＭの一組の鍵を含む。これらの値は、多くの状況において、ｅＵＩＣＣから読み出すことができない。１つの例外的な使用例が、ｅＳＩＭ全体を暗号的にラップしエクスポートするエクスポート動作である。ｅＳＩＭ全体が暗号化されているため、鍵の値はセキュアに保たれる。例示的な一実施形態において、ＤＦｃｏｄｅ情報は次のものを含む。（ｉ）グローバルＰＩＮ（個人識別番号）及びＰＵＫ（ＰＩＮロック解除鍵）を含むＥｘＥＦｇＰｉｎｘ／ｇＰｕｋｘ、（ｉｉ）ユニバーサルなＰＩＮ及びＰＵＫを含むＥＦｕＰｉｎ／ｕＰｕｋ、（ｉｉｉ）ＡＤＭＩＮコードを含むＥＦａｄｍｉｎｘ、及び（ｉｖ）ＯＴＡコードを含むＥＦｏｔａｘ。いくつかの変異において、更に、次のような追加の要素を含むＡＤＦｕｓｉｍが存在し得る。（ｉ）Ｋ（１２８ビットの共有認証鍵）を記憶するＥＦｋ、（ｉｉ）加入者鍵及びオペレータ変異体アルゴリズム構成フィールドＯＰから導出されるＯＰｃを記憶するＥＦｏｐｃ（一部の変異体はＯＰｃではなくＯＰを記憶し得る）、（ｉｉｉ）ＲＥＳの長さを特定するＥＦａｕｔｈｐａｒ、（ｉｖ）ネットワーク認証アルゴリズム（例えばＭｉｌｅｎａｇｅ）を特定するＥＦａｌｇｉｄ、（ｖ）ＳＱＮを記憶するＥＦｓａｎ、及び（ｖｉ）ローカルＰＩＮのためにＰＩＮ及びＰＵＫを記憶するＥＦｌｐｉｎｘ／ｌｐｕｋｘ。

本開示を読む当業者には、上記のファイル、構造、又は要素が単に例示であり、所望の機能又は構造を所有する他のものに置き換え得ることが理解されよう。

ここで図３を参照すると、ＳＤＦ動作のための１つの例示的なステートマシンが示されている。図示されているように、このＳＤＦステートマシンは次のステートを含む。作成、初期化、動作（アクチベーション済み）、動作（アクチベーション解除済み）、及び終了。

ｅＳＩＭが最初にインストールされると、ＳＤＦが作成され（作成）、次にそのｅＳＩＭに含まれているファイル構造データで初期化される（初期化）。ｅＳＩＭがインストールされると、ＳＤＦはアクチベーション解除済みステートに移行する。アクチベーション解除済みステート中は、利用できるファイルはない。ｅＳＩＭが選択されると、ＳＤＦがアクチベーション解除済みステートからアクチベーション済みステートに移行する。このアクチベーション済みステートにより、ＳＤＦのファイルへのアクセスが可能になる。ｅＳＩＭが（暗示的又は明示的のいずれでも）選択解除されると、ＳＤＦはアクチベーション済みステートからアクチベーション解除済みステートに戻る。

ここで図４を参照すると、ｅＳＩＭ動作のための１つの例示的なステートマシンが示されている。図示されているように、このｅＳＩＭステートマシンは次のステートを含む。インストール済み、選択済み、ロック済み、アクチベーション解除済み、エクスポート済み、及び削除済み。

ｅＳＩＭのインストール中に（インストール済み）、ｅＳＩＭのためのエントリがｅＵＩＣＣレジストリに作成される。このエントリは、１つ以上の関連するＳＤＦ及びアプリケーションを示す。インストール済みステート中に、ＳＤＦがアクチベーション解除済みステートに設定され、アプリケーションはインストール済みステートに設定される。

ｅＳＩＭが選択されると、このｅＳＩＭが選択済みステートに移行する。選択済みステート中に、ＳＤＦはアクチベーション済みステートに移行し、アプリケーションは選択可能ステートに移行される。ｅＳＩＭが選択解除されると、このｅＳＩＭはインストール済みステートに戻る。

特定の条件下において、ｅＳＩＭはロック済みステートになり得る。例えば、ｅＵＩＣＣ ＰＣＦが変更されて、インストール済みｅＳＩＭがもはや使用できなくなった場合、ｅＳＩＭはロック済みステートに移行する。ロック済みステート中に、ＳＤＦがアクチベーション解除済みステートに設定され、アプリケーションはロック済みステートに設定される。その他の種々のステートには、エクスポート済みステート（すなわち、ｅＳＩＭがエクスポートされ、もはや選択できない状態）、及び削除済みステート（すなわち、ｅＳＩＭが削除されている状態）が挙げられる。

ネットワーク認証アルゴリズム
ネットワーク認証アルゴリズム（ＮＡＡ）は、一般に、移動体通信事業者（ＭＮＯ）の動作に必須である。ＮＡＡの様々な実装が存在するが、その機能は実質的に異なるものではない。特定の実施形態において、ｅＵＩＣＣはＮＡＡの共通パッケージを含み得る。ｅＳＩＭインストール中に、各ＮＡＡアプリケーションのインスタンスを、事前ロード済みパッケージから各ｅＳＩＭについて作成することができ、これによってｅＳＩＭの全体のロード時間が短縮され、ｅＵＩＣＣの不必要なメモリ消費が低減され得る。

ＮＡＡの一般的な例としては、Ｍｉｌｅｎａｇｅ、ＣＯＭＰ１２８ Ｖ１、ＣＯＭＰ１２８ Ｖ２、ＣＯＭＰ１２８ Ｖ３、ａｎｄ ＣＯＭＰ１２８ Ｖ４、及び特定の独自仕様アルゴリズムが挙げられるが、これらに限定されない。今も使用されている数多くの独自仕様アルゴリズムがある（ＣＯＭＰＩ２８ ＶＩに対する攻撃が知られているため）。一実施形態において、ネットワーク認証は、周知の認証及び鍵合意（ＡＫＡ）プロトコルに基づく。

ＮＡＡが損われるという可能性の低い事態が生じた場合、代替のＮＡＡ方式には、ソフトウェアの更新が必要となり得る。そのような事態において、ｅＳＩＭは、例えば、セキュアなソフトウェア更新を介して、代替アルゴリズムでパッチを行うことができる。これ以降、ＭＮＯは既存のＯＴＡ機構を介して代替アルゴリズムを使用可能にすることができる。

例示的なｅＳＩＭブローカーネットワーク
図５は、本開示の様々な態様に関連して有用な、１つの例示的なｅＳＩＭブローカーネットワークの高レベル図である。例示的な一実施形態において、このブローカーネットワークは、ブローカーとメーカーの分散ネットワークを含み、これにより機器は複数のブローカーによってサービスを受けることができ、ブローカーは複数のｅＳＩＭメーカーにｅＳＩＭを注文することができる。いくつかの実施形態において、機器が特定のｅＳＩＭ動作で通信可能とする、ブローカー群を制限するような、ｅＵＩＣＣ及び／又はｅＳＩＭプロファイルポリシーが存在し得る。例えば、ＭＮＯは、そのＭＮＯにより補助されている機器が、そのＭＮＯが所有するブローカーとのみ通信することを義務付けることがある。

そのような一変異において、プライマリブローカーは機器に対しディスカバリーサービスを提供し、これにより機器は適切なブローカーを特定することができる。これ以降、その機器はｅＳＩＭ動作（例えば、購入、インストール、エクスポート、及びインポート）に関して、特定されたブローカーと直接通信することができる。

関連するネットワーク分野の当業者には、図５に示されているもののような大規模配信ネットワークの動作中に、複数の実際的な問題が生じることが理解されよう。具体的には、大規模配信ネットワークは、プロビジョニングトラフィックの大きなバースト（例えば、所与のモバイルユーザ機器のいわゆる「発売日」に起こり得る）を取り扱えるよう、スケーラブルでなければならない。ネットワークトラフィック全体を低減するための１つの提案される方式は、発売日以前の、事前パーソナライズｅＳＩＭを伴う（可能な場合）。例えば、いわゆる「ＳＩＭイン」ユニットは、出荷時にｅＳＩＭが既に割り当てられている。この事前割り当てされたｅＳＩＭは、例えば、ユニットのｅＵＩＣＣに固有の鍵で、対応するｅＳＩＭプロファイルを暗号化することによって、そのユニットの事前パーソナライズを行うことができる。

その他の考慮事項には、システム信頼性が挙げられる。例えば、ブローカーネットワークは様々な装置故障から回復することが可能でなければならない。１つの解決策は、様々な地域にわたって複数のデータセンターが重複コンテンツを有する、地理的冗長性である。しかしながら、データセンターのネットワークは、ｅＳＩＭクローニングを回避するため、能動的に互いに同期し得る。そのようなネットワーク同期には、非常に大きなネットワーク帯域を必要とし得る。別の解決策として、各データセンターが別のｅＳＩＭセットを有することができる。しかしながら、これには多大なｅＳＩＭオーバーヘッドが必要である。

理想的には、ブローカーネットワークは柔軟に、様々なビジネスモデルに適合し得る。具体的には、様々な法的及び反トラストの理由から、上記のブローカーネットワークの様々な構成要素が、異なる当事者により取り扱われる可能性がある。したがって、ｅＳＩＭトラフィックのセキュリティ面は、注意深い監視と評価が必要になる。各ｅＳＩＭは、大切なユーザ情報及びＭＮＯ情報を含む。例えば、ｅＳＩＭは共有認証鍵（ＵＳＩＭ用のＫ、及びＳＩＭ用のＫｉ）を含む可能性があり、もし侵害されると、ＳＩＭクローニングに利用される可能性がある。同様に、ｅＳＩＭは更に、銀行口座情報などのセンシティブなユーザデータを有している可能性があるアプリケーションを含み得る。

加えて、ｅＵＩＣＣソフトウェアは機器リカバリのために更なる対策を必要とすることが理解されよう。物理的ＳＩＭとは異なり、ｅＵＩＣＣソフトウェアが回復不能な状態になった場合、機器全体を交換する必要がある（これは、ＳＩＭカードを交換するよりはるかに高価につく）。したがって、例示的な解決策は、そのような苛酷な手段をあらかじめ除外するために、機器リカバリを取り扱うことが可能であるべきである。

最後に、ネットワーク動作は「良好な」ユーザエクスペリエンスを提供すべきである。長すぎる応答時間、信頼性の低い動作、過剰なソフトウェアクラッシュなどは、全体的なユーザエクスペリエンスに大きなマイナスとなり得る。

例示的なセキュリティプロトコル
したがって、本明細書において、上記の様々な問題に対処するため、階層セキュリティソフトウェアプロトコルが開示される。例示的な一実施形態において、サーバｅＵＩＣＣ及びクライアントｅＵＩＣＣソフトウェアは、いわゆる、ソフトウェア層の「スタック」を含む。各ソフトウェア層は、一組の階層的機能を担当し、これらは対応するピアソフトウェア層と交渉される。更に、各ソフトウェア層はその層自体と通信する。場合によっては、機器アプリケーションプロセッサ（ＡＰ）が侵害される可能性がある（例えば「ジェイルブレイク」されるなど）ことが更に理解されよう。したがって、クライアントｅＵＩＣＣと対応するサーバｅＵＩＣＣ（又はその他のセキュアなエンティティ）との間に信頼関係が存在することが認識される。すなわち、そのＡＰは信頼されない。

例示的な一実施形態において、３階層システムが開示される。図６に示すように、セキュリティソフトウェアプロトコルは、レベル１（Ｌ１）、レベル２（Ｌ２）、及びレベル３（Ｌ３）を含む。Ｌ１セキュリティは、ｅＳＩＭデータの暗号化及び暗号復号を実施する。Ｌ１動作は、実行環境（例えば、ｅＵＩＣＣ又はハードウェアセキュリティモジュール（ＨＳＭ））をセキュアにすることに限定される。Ｌ１内で、ｅＳＩＭデータは論理Ｌ１バウンダリ内に平文で（すなわち、暗号化されていない状態で）記憶することができる。Ｌ１バウンダリの外では、ｅＳＩＭデータは常にセキュアに暗号化される。Ｌ２セキュリティにより、ｅＳＩＭが複製できないよう確実にする。Ｌ２バウンダリにより、ｅＳＩＭの唯一のコピーが１つだけ存在するよう確実にする。Ｌ２バウンダリ内には、複数のコピーが存在する可能性がある。加えて、Ｌ２セキュリティは更に、暗号化されたｅＳＩＭペイロードにチャレンジを埋め込む可能性がある。ｅＳＩＭの受け取り側は、ｅＳＩＭをインストールするより前に記憶されたチャレンジと、受信したチャレンジとを比較して、そのｅＳＩＭが陳腐化していないことを（すなわち現行の唯一のｅＳＩＭであることを）確認する。Ｌ３セキュリティは、ユーザの信頼、所有、及び検証の確立を担当する。各ｅＳＩＭについて、ｅＵＩＣＣは、ｅＳＩＭに関連付けられた所有権を示す情報を記憶し得る。

１つの例示的な実施において、いわゆる「チャレンジ」は、特定のｅＳＩＭインスタンスをｅＵＩＣＣと関連付けるのに使用される重要なリソースである。具体的には、各ｅＵＩＣＣは各プロファイルエージェントについて特定の数のチャレンジを保持し、このプロファイルエージェントは、Ｌ２セキュリティを保持する論理エンティティである。チャレンジが有効であることを検証することによって、ｅＵＩＣＣはそのｅＳＩＭが陳腐化したｅＳＩＭ（すなわち、無効な複製）ではないことを確認できる。パーソナライズされる各ｅＳＩＭについて、数多くのチャレンジが作成される。ｅＵＩＣＣは、合致するｅＳＩＭを受信すると、チャレンジを削除する。

下記の事前パーソナライズシナリオを考慮する。ｅＵＩＣＣが、ネットワークに提供される数多くのチャレンジを作成し（又は与えられ）、このチャレンジは更に、ｅＵＩＣＣの不揮発性メモリに保存される。したがって、これ以降、ネットワークは、事前生成されたチャレンジに拘束されたｅＵＩＣＣのためのｅＳＩＭを生成することができる。ｅＵＩＣＣが後で機器アクチベーションの際にｅＳＩＭを受信すると、ｅＵＩＣＣはその受け取ったｅＳＩＭが適切なチャレンジを含んでいることを検証することができる。

しかしながら、上記の方式の欠点の１つは、固定数のチャレンジは容易に、サービス拒否（ＤＯＳ）攻撃で侵害される可能性があることである。ＤＯＳ攻撃では、ｅＵＩＣＣがチャレンジを生成するよう連続的にトリガされ、ついにはチャレンジリソースすべてが枯渇する。したがって、そのような一変異において、ｅＵＩＣＣは追加として、プロファイルサーバ／エージェントの認証を行うためのハンドシェイクセッションを実施してから、チャレンジを生成するようｅＵＩＣＣをトリガする要求を処理する。加えて、リソースが枯渇し、ｅＵＩＣＣが新たなチャレンジを生成できなくなるという、可能性の低い場合において、ｅＵＩＣＣは、別のチャレンジセットを解放するよう特別に指定された、別個の確保されたチャレンジセットを記憶することができる。場合によっては、ｅＵＩＣＣは更に、相手先ブランド名製造者（ＯＥＭ）認証情報を含めることができ、ＯＥＭはこれを使用して更にチャレンジ操作を制御することができる。

ここで図７を参照して、ｅＳＩＭのための１つの例示的なデータ構造が図示されている。図示されているように、例示的なデータ構造は、３つの部分を含み、このそれぞれが、Ｌ１、Ｌ２、及びＬ３セキュリティレベルである。セキュリティ構成要素を別個のレベルに分離することによって、全体的なネットワーク動作を、幅広いオプションにより、複数のエンティティにわたって分散することができる。例えば、様々なネットワークエンティティが、セキュリティ層を１つ又は２つだけ実施することができる（例えば、ｅＳＩＭ業者はＬ２のみを取り扱うことができるなど）。この柔軟性により、事実上、任意のビジネス構成に容易、有利に適合させることができる。

図７に示すように、非対称暗号化（すなわち、各エンティティが異なる一意の鍵を有する）は対称動作（エンティティが鍵を共有）よりもずっと遅いため、各ｅＳＩＭプロファイル構成要素７０２は対称鍵で暗号化され、この対称鍵は、予定されたｅＳＩＭ受信者のＬ１公開鍵で暗号化される。このｅＳＩＭは更に、メタデータ（例えば、ＩＣＣＩＤの文字列）のための平文部分を含み得る。暗号化された対称鍵、メタデータ、及び暗号化されたｅＳＩＭコンテンツは、「供与側」Ｌ１エンティティの公開鍵でハッシュされ、署名される。関連するＬ１証明書が、検証のために、（例えば、末尾に）添付される。

図７のバッチ記述子構成要素７０４は、ｅＳＩＭのＬ２情報を含む。これは、グローバル一意識別子（ＧＵＩＤ）、予定されたｅＳＩＭ受信者に対するチャレンジ、そのｅＳＩＭ受信者の一意のＩＤ、プロファイルを取得するためのＵＲＬ、及びインストール結果をポストするためのＵＲＬを含む平文部分を有する。このバッチ記述子は更に、次のものからなる要素のアレイの平文部分を含む。各プロファイルのＩＣＣＩＤ、及びプロファイルのハッシュされた部分（メタデータ部分及び暗号化されたｅＳＩＭコンテンツ）。一実施形態において、このハッシュは対称鍵を含まず、これによってバッチ記述子を、実際のプロファイルが生成されるのを待たずに生成することができる。機器側の動作のために、バッチ記述子は、１つのＩＣＣＩＤとプロファイルハッシュを含むだけである。サーバ間バッチ移動のためには、ずっと大きなアレイが期待される。バッチ記述子のデータコンテンツはＬ２公開鍵でハッシュ及び署名され、関連するＬ２証明書が末尾に添付される。

Ｌ３所有者構成要素７０６は、そのｅＳＩＭのためのＬ３情報を含む。このプリンシパルフィールドは、ｅＳＩＭに関連付けられているユーザアカウント（例えばａｂｃ＠ｍｅ．ｃｏｍ）を特定し、サービス名は、これでユーザアカウントを認証するサービスプロバイダを特定する。バッチ記述子のハッシュは、Ｌ２及びＬ３データ構造を関連付けるために含められる。このデータは、Ｌ３公開鍵でハッシュ及び署名され、平文内に記憶され得る。Ｌ３証明書は末尾に添付される。

本明細書で使用される場合、証明書には、ｅＵＩＣＣ証明書、サーバアプライアンス証明書、及びＯＥＭ証明書の３つのタイプがある。一実施形態において、信頼されるサードパーティが、認証されたｅＵＩＣＣに対する証明書を発行する。各ｅＵＩＣＣは、このエンティティ、又はこのエンティティに従属する鍵権限者によって発行された、公開鍵及び関連付けられた証明書を含む。いくつかの実施形態において、１つの信頼されるサードパーティが、認証されたＬ１、Ｌ２、及びＬ３アプライアンスに対する証明書を発行し得る。またあるいは、別のサードパーティエンティティが、Ｌ１、Ｌ２、又はＬ３アプライアンスに対する証明書を発行し得る。複数のサードパーティが存在する場合、ｅＵＩＣＣは、サードパーティのルート証明書認証局（ＣＡ）を事前ロードし（又は信頼されるエンティティからのＯＴＡを供給され得る）、適切なＣＡに基づいてサーバアプライアンスから受け取ったメッセージを検証することができる。

ここで図８を参照し、１つの例示的なＯＥＭ証明書階層が示されている。ルート証明書認証局（ＣＡ）は、タスクのサブセット（例えば、ｉＯＳなどの発行、又は匹敵する機器証明書の発行）を実行する一組の中間ＣＡを有する。図示のように、ｅＵＩＣＣ ＣＡにはｅＳＩＭ固有の動作が搭載されている。ｅＵＩＣＣ ＣＡは一組のサーバに対して証明書を発行できる。図示のように、この証明書には例えば、ｅＵＩＣＣ保守のための工場リファビッシュサーバ、及びｅＵＩＣＣ ＰＣＦに署名するアクチベーションサーバが含まれる。ルートＣＡは、ｅＵＩＣＣ ＣＡの共通名と合わせて、クライアントｅＵＩＣＣによって使用され、ＯＥＭ署名のメッセージを検証する。

上記に従い、例示的な一実施形態において、各クライアントｅＵＩＣＣは次のセキュリティ関連データを記憶する。（ｉ）ｅＵＩＣＣ Ｌ１、Ｌ２、及びＬ３動作に使用されるｅＵＩＣＣ証明書（各ｅＵＩＣＣはＬ１、Ｌ２、及びＬ３セキュリティ関連動作両方に使用される証明書を記憶する）、（ｉｉ）ｅＵＩＣＣ証明書に関連付けられているｅＵＩＣＣ秘密鍵、（ｉｉｉ）ＯＥＭのルート証明書及びＯＥＭ ｅＵＩＣＣ ＣＡの共通名を含む、ＯＥＭ認証情報、並びに（ｉｖ）サーバアプライアンスを認証できるサードパーティのルート証明書。いくつかの変異において、ｅＵＩＣＣの証明書は、ＣＡ署名が侵害された場合に交換する必要があり得る。例えば、ｅＵＩＣＣ ＣＡ又はサーバＣＡが侵害された場合（例えば、秘密鍵が侵害／紛失した場合）、２つの失効手順が下記に記述される。

第１の例示的な失効手順により、ｅＵＩＣＣ証明書を発行する署名ＣＡが侵害された場合、影響を受けたｅＵＩＣＣ内に記憶されているｅＵＩＣＣ証明書は交換されるべきである。具体的には、そのｅＵＩＣＣに対して初期証明書要求が生成されたとき、その証明書署名要求（ＣＳＲ）が保存されている。署名ＣＡが侵害された場合、初期ＣＳＲを使って、そのｅＵＩＣＣに対して新しい証明書を要求することができる。同じＣＳＲを保持することにより、ｅＵＩＣＣは同じ秘密鍵を使用することができ、同じｅＵＩＣＣ公開鍵を含んだ新しい証明書が発行される。ＯＥＭは、そのＯＥＭの秘密鍵を使って、新しい証明書に署名できる。ｅＵＩＣＣがサーバブローカーに要求を送ると、ブローカーは不良ｅＵＩＣＣ ＣＡの失効リストをチェックし、その証明書を交換する必要がある旨を示した特定のエラーをもってその要求を却下することができる。ＡＰは、既存のＯＥＭサービスを介して新しいｅＵＩＣＣ証明書を取得し、その新しい証明書をｅＵＩＣＣに送ることができる（ＡＰはこのシナリオにおいて信頼されている必要はない）。

この後、ｅＵＩＣＣはＯＥＭ署名を検証し、受け取った公開鍵が、前にｅＵＩＣＣに記憶された公開鍵に合致していることを確認する。いくつかの変異において、サービス拒否（ＤＯＳ）攻撃又はリプレイ攻撃を防ぐために、ｅＵＩＣＣは更にｅＵＩＣＣ証明書を含む。一変異において、新しい証明書が発行されると、このエポックが増加する。ｅＵＩＣＣは、受け取った証明書のｅＵＩＣＣエポックが、現行の証明書のそれよりも高いことを検証してから、新しい証明書を記憶することができる。

残念ながら、様々なｅＵＩＣリソースの制限により、ｅＵＩＣＣにおいてサーバ証明書を失効させるのは困難であり得る。すなわち、大きな失効リストの処理は、１つのｅＵＩＣＣには対処できない可能性がある。失効リストの保守を回避するため、第２の失効方式においては、各サーバ証明書が追加として１つのエポックに関連付けられる。ＣＡが侵害されたとき、ルートＣＡが正当なすべてのエンティティに対して証明書を再発行し、新しい証明書のそれぞれのエポックを増加させる。サーバ証明書の数は大きくならないため、証明書の再発行は既存のシステムで扱うことができる。クライアントｅＵＩＣＣにおいて、このｅＵＩＣＣは、サーバＬ１、Ｌ２、及びＬ３証明書の予期されるエポックを、不揮発性メモリに保存する。受信した証明書が高いエポックを含む場合、ｅＵＩＣＣは対応するＮＶエポックを更新しなければならず、より低いエポックの証明書を今後却下しなければならない。すなわちｅＵＩＣＣは、ＣＡが侵害されて以来署名していない不良サーバを却下する。いくつかの変異において、このサーバは更に、侵害されたｅＵＩＣＣに関するｅＵＩＣＣブラックリストを保守し得る。一実施形態において、ブラックリストに掲載されたｅＵＩＣＣからの要求は、サーバにより却下される。

ポリシー制御機能
上記のセキュリティ解決策のコンテキストにおいて、（ｉ）ｅＵＩＣＣプラットフォームレベル、及び（ｉｉ）プロファイルレベルの、２つのレベルのポリシー制御機能（ＰＣＦ）がある。例示的な一実施形態において、ｅＵＩＣＣ ＰＣＦはＯＥＭによってのみ更新することができ、一方、プロファイルＰＣＦはＭＮＯによって制御され、ｅＳＩＭの一部である。そのような１つの変異において、ｅＳＩＭがエクスポート及び／又はインポートされた場合、プロファイルＰＣＦはエクスポート／インポートパッケージの一部として含まれる。

ここでｅＵＩＣＣ ＰＣＦを参照して、ｅＵＩＣＣ ＰＣＦは次のものを含み得る。（ｉ）ｅＵＩＣＣがアクチベーションし得るｅＳＩＭのタイプを特定するＳＩＭロックポリシー、（ｉｉ）ｅＵＩＣＣ内のすべてのｅＳＩＭの削除を承認するのに使用することができる秘密のコード、（ｉｉｉ）ｅＵＩＣＣが通信し得るサーバアプライアンスのクラスタを特定するサーバ（Ｌ１、Ｌ２、及びＬ３）の共通名のリスト（例えば、ビジネス検討事項又は方法に基づく）（すなわち、包含リスト）、（ｉｖ）ｅＵＩＣＣが通信することができないサーバアプライアンスのクラスタを特定するサーバ（Ｌ１、Ｌ２、及びＬ３）の共通名のリスト（すなわち、除外リスト）。

同様に、プロファイルＰＣＦは次のものを含み得る。（ｉ）ｅＵＩＣＣがｅＳＩＭをエクスポートし得るデポのクラスタを特定するサーバ（Ｌ１、Ｌ２、及びＬ３）の共通名のリスト（包含）、（ｉｉ）ｅＵＩＣＣがｅＳＩＭをエクスポートできないデポのクラスタを特定するサーバ（Ｌ１、Ｌ２、及びＬ３）の共通名のリスト（除外）、（ｉｉｉ）特定されたｅＳＩＭ動作の完了時に通知が送られるＵＲＬを特定する、通知ＵＲＬ及び動作タイプ、（ｉｖ）プロファイルが失効になったときにＡＰがｅＳＩＭを削除し得る場合の、自動失効パラメータ、（ｖ）実施されるセキュリティレベルを示す別のクラスが割り当てられ得るサーバアプライアンス（Ｌ１、Ｌ２、及びＬ３）のクラス（プロファイルは、特定のレベルを超えるサーバ構成要素とのみ通信するように選択することができる）、（ｖｉ）インストール中にチェックされるサーバ証明書（Ｌ１、Ｌ２及びＬ３）のエポック（例えば、ｅＵＩＣＣサーバ証明書のエポックが指定されたエポック以上である場合にのみ、ｅＵＩＣＣはプロファイルをインストールする）、（ｖｉｉ）Ｌ３認証が使用し得るＬ３サービス名、及び／又は、Ｌ３認証が使用できないサービス名のリスト、（ｖｉｉｉ）ｅＵＩＣＣシステムの最少バージョン（指定された最少バージョン以上のｅＵＩＣＣシステムにのみ、ｅＳＩＭがインストールされ得る）、（ｉｘ）そのｅＳＩＭに必要な最小ＲＡＭサイズ（ＯＴＡ動作を含まない）、（ｘ）ＯＴＡのために確保される最小ＲＡＭサイズ、（ｘｉ）ｅＳＩＭのために必要な最小の不揮発性（ＮＶ）メモリサイズ（ＯＴＡのために用いられるスペースを除く）、（ｘｉｉ）ＯＴＡのために確保される最小ＮＶサイズ。

例示的な動作
上記の構成要素（例えば、ｅＵＩＣＣ、ｅＳＩＭ、ブローカーネットワーク、セキュリティプロトコルなど）のコンテキスト内で、下記の例示的なメッセージングシーケンスが開示される。以下のシーケンス図において、ブローカー、プロファイルエージェント、及びプロファイルロッカーの３つのエンティティが表わされ、これはそれぞれＬ３、Ｌ２、Ｌ１セキュリティを担当するエンティティを表わす。ただし、これらは論理エンティティであって、別のネットワークトポロジーを包含することが可能であり、また、それらの上記機能を更に差別化することが可能であることが理解されよう。

クライアントｅＵＩＣＣは、図示の実施形態において、３つのセキュリティレベルすべてを担当している。ただし、明確さのため、クライアントｅＵＩＣＣは、そのｅＵＩＣＣ内での機能的要件を捕捉するため、３つの論理エンティティに分けられている。加えて、クライアントｅＵＩＣＣ内のＬ１、Ｌ２、及びＬ３のための別の認証情報セットがあってもよいが、クライアント機器は単一の機器であるため、同じ（すなわち、１つの認証情報）が使用され得ることが理解されよう。

ｅＳＩＭ配信、パーソナライズなし
図９は、パーソナライズなしでｅＳＩＭを機器に配信するための、１つの例示的な論理シーケンスを示す。最初に、機器は発見プロセス（図示なし）を介してサーバブローカーを特定する。機器がサーバブローカーと通信を試みた後、次の３つの主な動作がある。（ｉ）機器が、利用可能なｅＳＩＭオプションについてサーババックエンドにクエリを行う、（ｉｉ）要求したｅＳＩＭが事前パーソナライズされていない場合、サーバがｅＳＩＭをパーソナライズするよう、機器が要求する、及び、（ｉｉｉ）機器が実際のｅＳＩＭをダウンロードし、これをインストールする。

第１段階で、機器がｇｅｔＰｒｏｆｉｌｅＯｐｔｉｏｎｓを使用し、使用可能なｅＳＩＭオプションについてサーババックエンドにクエリを行う。機器に関連付けられているｅＵＩＣＣは、ＵｎｉｑｕｅＩｄにより特定され、これは、例えば、カードのシリアル番号であり得る。ブローカーは、機器に利用できる１つ以上のｅＳＩＭオプションを決定するため、販売情報を利用する。ロック解除された機器については、利用可能なｅＳＩＭの非常に大きなセットがある可能性がある。よって、いくつかの実施形態において、ユーザが選択する可能性が高い一般的なオプションが表示される（例えば、ロケーション、費用などに基づいて）。サーバは、その機器に有効なプロファイルプロバイダ（ＭＮＯ）及びプロファイルタイプ（例えば、プリペイド／ポストペイド）のアレイを返す。

いくつかのシナリオにおいて、ユーザが利用できるｅＳＩＭのタイプは、プライベート情報と考えられ得るため、いくつかの変異において、ｇｅｔＰｒｏｆｉｌｅＯｐｔｉｏｎｓ ＡＰＩが更に機器のｅＵＩＣＣ Ｌ３に対しｅＵＩＣＣの一意の識別子に署名し、その署名された識別子をＡＰＩに含めるように要求する。サーバブローカー（又はブローカーサーバ）は、署名を検証してからその要求を処理することができる。これにより、なりすまされた要求を送信することによって悪意ある者がユーザのプロファイルオプションを取得するのを妨げる。いくつかの変異において、機器ブローカーとサーバブローカーの間の通信にはセキュリティプロトコル（例えば、トランスポート層セキュリティ（ＴＬＳ））を使用して、取得及びリプレイ攻撃を防ぐ。

一実施形態において、ｇｅｔＰｒｏｆｉｌｅＯｐｔｉｏｎｓは、ｅＳＩＭの現行及び新しい所有権を検証するため、２つのＬ３トークンを含む。現行Ｌ３トークンは一意の識別子、又はいわゆる「偽カード」スクラッチコードであり得る。新しいＬ３トークンは、ユーザアカウントをｅＳＩＭと関連付けるのに使用される情報であり得、例えば、ｉＣｌｏｕｄアカウントのためのサインオントークンであり得る（例えば、機器がトークンを取得するためにユーザアカウントにログインされている場合）。両方のＬ３トークンが、ｅＵＩＣＣ Ｌ３により署名される。サーバブローカーは、関連付けられた認証サービスを使用してＬ３トークンを認証する。例えば、ネットワークサーバ（例えば譲受人のｉＣｌｏｕｄサーバ）、又はサードパーティサービスと通信して、サインオントークンを検証することができる。

性能を最適化し、重複の認証を避けるため、機器により渡されたトークンを認証した後、サーバブローカーは、ワンタイムコード（ＯＴＣ）を生成し、そのＯＴＣを機器に戻し渡す。機器は、サーバが既にＬ３認証を実施した証明としてこのＯＴＣを使用することができる。完全なデータのバイナリラージオブジェクト（ＢＬＯＢ）は、生成されたＯＴＣ、一意の機器識別子（例えば、カードのシリアル番号（ＣＳＮ））、プリンシパル、サービスプロバイダ、及びそのＯＴＣの有効性を示すタイムスタンプを含み得る。このＢＬＯＢは、ブローカーにハッシュされ、署名される。一変異において、ハッシュは、全体の性能を改善するために対称鍵で実施される。ｇｅｔＰｒｏｆｉｌｅＯｐｔｉｏｎｓがｅＳＩＭのアレイを返した場合、ユーザには選択を行うプロンプトが提示される。

第２段階において、機器はｐｅｒｓｏｎａｌｉｚｅＰｒｏｆｉｌｅを呼び出し、ｅＳＩＭをパーソナライズするようサーババックエンドに要求する。機器がパーソナライズの要求をサーバに送る前に、認証のため、ｅＵＩＣＣプロファイルエージェントとサーバプロファイルエージェントとの間でハンドシェイクセッションがある。機器ブローカー及びｅＵＩＣＣは、ユーザが選択したプロファイルオプション、及びサーバブローカーから送られた現行のＬ３コード及び新しいＬ３コードに基づいて、セッションを作成する。ｅＵＩＣＣはこの情報を保存して、以後これにより送られるプロファイル要求を満たすことができる。ｅＵＩＣＣプロファイルエージェントは、セッションＩＤを作成し、これは以後、これに対する認証のために、サーバエージェントによりエコーバックされる。

機器ブローカーはこれで、ｅＵＩＣＣにより生成された要求セッションを、サーバブローカーに渡すことができる。サーバブローカーは、この要求をチェックすることができる。例えば、サーバブローカーは、一意のＩＤにより表わされたｅＵＩＣＣの要求がサービス可能であるかどうかを判定する。一意の識別子は平文に含まれているため、サーバプロファイルエージェントによって、より徹底した要求検証が実施されるけれども、サーバブローカーはこの情報を取得することができる。

要求が適切な場合、サーバブローカーはその要求をプロファイルエージェントに渡す。プロファイルエージェントは、ｅＵＩＣＣ Ｌ２証明書を検証し、ｅＵＩＣＣ Ｌ２公開鍵を使用してＬ２署名を検証することによって、その要求を暗号により検証する。検証が合格すると、サーバプロファイルエージェントはＳｅｓｓｉｏｎＲｅｓｐｏｎｓｅを作成し、これには次のものを含む平文部分が含まれる。受信したセッション識別子及び一意の識別子、Ｌ２署名（平文部分のハッシュと、サーバプロファイルエージェントの秘密鍵を使ってそのハッシュに署名することによって生成）、及びサーバプロファイルエージェントの証明書。

セッション応答はサーバプロファイルエージェントからサーバブローカーに送られ、これは次に、セッション応答を機器ブローカーに転送する。機器ブローカーはこの応答を、ｐｒｅｐａｒｅＰｒｏｆｉｌｅＲｅｑｕｅｓｔメッセージ内でｅＵＩＣＣに渡す。ｅＵＩＣＣ Ｌ２は、サーバプロファイルエージェントの証明書及びＬ２署名を検証することにより、ｓｅｓｓｉｏｎＲｅｐｏｎｓｅを検証する。ｅＵＩＣＣ Ｌ２は更に、セッション識別子及び一意の識別子が、ｅＵＩＣＣ内の情報に合致することを検証する。検証が合格したら、ｅＵＩＣＣはパーソナライズされたプロファイル要求に対するチャレンジを作成する。このチャレンジは不揮発性メモリに記載される。ｅＵＩＣＣは次に、Ｌ１、Ｌ２及びＬ３関連情報を含むプロファイル要求ＢＬＯＢを作成する。詳細な構造は本明細書の付録Ａに記載されており、参照により本明細書に組み込まれる。

次に、プロファイル要求ＢＬＯＢがサーババックエンドに送られる。サーバブローカーはＬ３検証を行い、ｅＳＩＭを関連付けるためのＬ３所有者情報（例えば、プリンシパル及びサーバプロバイダ）を含む。このサーバプロファイルエージェントは、バッチ記述子を作成し、サーバプロファイルロッカーはそのｅＵＩＣＣのためのｅＳＩＭをパーソナライズする。パーソナライズされたｅＳＩＭは、性能最適化のため、コンテンツ配信ネットワーク（ＣＤＮ）に分散され得る。

機器ブローカーは、プロファイル記述子及び関連するＬ３所有者情報を受け取った後、受け取ったＧＵＩＤ（グローバル一意識別子）を提供することにより、ｇｅｔＰｒｏｆｉｌｅを介して、関連付けられたプロファイルを取得する。

機器ブローカーがプロファイル記述子及びプロファイルを取得すると、クライアントｅＵＩＣＣに対し、ｅＳＩＭをインストールするよう指示を行う。この呼び出しフローは３つの異なる呼び出し、ｐｒｏｃｅｓｓＬ３Ｏｗｎｅｒ、ｐｒｏｃｅｓｓＰｒｏｆｉｌｅＤｅｓｃｒｉｐｔｏｒ、及びｉｎｓｔａｌｌＰｒｏｆｉｌｅを示しているが、ただし、実際の実装においては、これら３つの論理呼び出しは、単一のトランザクション内に組み合わせることができることが理解されよう。ｅＵＩＣＣはＬ３、Ｌ２、及びＬ１検証を実施し、検証された後、ｅＳＩＭがインストールされる。関連付けられたチャレンジは削除される。Ｌ３所有者情報は、適切な所有権を示すため、ｅＳＩＭと一緒に保存される。Ｌ３所有者情報は、ユーザがｅＳＩＭをエクスポートした場合、後の時点で提供することができる。

プロファイルがインストールされると、ｅＵＩＣＣはインストール結果をサーバに返す。サーバインフラストラクチャは、コンテンツ配信ネットワーク（ＣＤＮ）内のキャッシュされたコンテンツのパージをトリガする通知を使用することができる。場合によっては、この情報は更に、例えば、インストール成功、部分的インストール、インストール失敗などを示す通知サービスのために使用することもできる。

ｅＳＩＭ配信、事前パーソナライズ
図１０は、事前パーソナライズを伴ってｅＳＩＭを機器に配信するための、１つの例示的な論理シーケンスを示す。図９の方式と同様、事前パーソナライズされたｅＳＩＭの配信には３つの段階が必要である。

最初に、クライアント機器の製造中に、工場ブローカーがｅＵＩＣＣに対し、ｅＳＩＭ事前パーソナライズに対するチャレンジを後で作成するよう指示を行う。ただし、図９の方式とは異なり、機器はまだＭＮＯにも、またｅＳＩＭタイプにも関連付けられていない。代わりに、これらのフィールドは特別な値が入れられ、選択が後で行われることを示す。プロファイル要求ＢＬＯＢの完全なコンテンツは、後でのパーソナライズ使用のために保存される。

第２段階は、例えば、出荷通知、機器販売などにより自動的にトリガされる。配信センターＬ２（クライアントプロファイルエージェント）は、クライアントｅＵＩＣＣ Ｌ２のためのプロキシとして機能する。ｅＵＩＣＣプロファイル要求ＢＬＯＢはＭＮＯ及びｅＳＩＭタイプを含んでいないが、クライアントプロファイルエージェントは、これらのフィールドを更新情報で置き換えることにより、ＢＬＯＢを再生成することができる。クライアントプロファイルエージェントは、それ自体のチャレンジを生成し、ｅＵＩＣＣチャレンジを置換することができる。クライアントプロファイルエージェントはそれ自体の秘密鍵でコンテンツの署名を行う（そうでなければ、すべてのＬ２が一意のチャレンジを必要とすることになる）。ＢＬＯＢはｅＵＩＣＣのＬ１署名を含み、このｅＵＩＣＣは依然として、パーソナライズされたｅＳＩＭの暗号を復号する必要がある。新しいプロファイル要求ＢＬＯＢは、既存のｐｅｒｓｏｎａｌｉｚｅＰｒｏｆｉｌｅ要求を使用して、サーバブローカーに送られる。これ以降の手順は、図９の手順と違いはない。

加えて、ＭＮＯがそれ自体のブローカーシステムをサポートしたい場合であっても、本開示の事前パーソナライズプロセスは同じインタフェースを使用できることが理解されよう。サーバブローカーは、バッチ記述子をクライアントに返し、ｅＳＩＭをパーソナライズする。クライアントプロファイルエージェントはｅＵＩＣＣのチャレンジで新しいバッチ記述子を作成し、これは、ｅＵＩＣＣがプロファイルを後で要求したときに使用される。

最後に、最終段階で、ユーザが機器の電源を入れると、機器がｇｅｔＰｒｏｆｉｌｅＯｐｔｉｏｎｓを実行して、使用できるｅＳＩＭオプションをチェックする。ｅＳＩＭがすでに事前パーソナライズされているため、この応答には有効なバッチ記述子が含まれ、機器はもはやｐｅｒｓｏｎａｌｉｚｅＰｒｏｆｉｌｅを呼び出す必要はない。これは、ｇｅｔＰｒｏｆｉｌｅ要求を介してｅＳＩＭを直接取得するための記述子内の情報を使用し得る。

ｅＳＩＭ配信、バッチ配信
図１１は、例えば、２つのエンティティの間で多数の（バッチ）ｅＳＩＭを配信するための１つの例示的な論理シーケンスを示す。一実施形態において、クライアントブローカー及びサーバブローカーは、例えば、仮想プライベートネットワーク（ＶＰＮ）を介したセキュアな通信を有するセキュアなエンティティである。「バッチ化」は、クライアントが大量のｅＳＩＭを注文できるようサポートされる。

このシナリオにおいて、プロファイルエージェントがプロファイルをパーソナライズする要求を受信した場合、このプロファイルは、バッチ記述子が返されている場合はパーソナライズする必要はない。むしろ、クライアントは所望に応じて後の段階で実際のプロファイルを要求することができる。バッチ記述子動作において、プロファイルコンテンツのハッシュは、暗号化されたプロファイル（対称鍵でラップされている）及びプロファイルメタデータを用いて計算され、これらのいずれも、プロファイルをパーソナライズする必要はない。また、Ｌ１がｅＵＩＣＣごとに対称鍵を記憶する必要もない。これは、記憶する必要がある場合は、充足するのが難しい追加記憶容量要件によってＬ１の大きな負担となり得る。一実施形態において、暗号化ｅＳＩＭ（対称鍵でラップされている）は、外部記憶装置に記憶することができる。対称鍵はＬ１ ＲＦＳ（リモートファイルシステム）鍵でラップされてもよく、このラップされた鍵は、暗号化されたｅＳＩＭと一緒に外部記憶装置に保存することができる。

ｅＳＩＭエクスポート
最後に、ｅＳＩＭがクライアント機器に記憶されると、ユーザは選択により、機器外にｅＳＩＭをエクスポートし、後でこのｅＳＩＭを同じ又は異なる機器にインポートすることができる。目的の１つは、ｅＳＩＭのスワップをサポートすることである。もう１つの目的は、追加のｅＳＩＭを記憶するためにｅＵＩＣＣメモリのスペースを解放することである。エクスポートする際は、次の３つの可能なシナリオがある。（ｉ）クラウドにエクスポートする、（ｉｉ）ＡＰ（オフボード記憶装置用）にエクスポートする、及び（ｉｉｉ）機器間ｅＳＩＭ転送を行う。同様に、ユーザは、クラウド、ＡＰ、又はその他の機器からインポートすることができる。

ｅＳＩＭインストール中、ユーザアカウント情報はｅＳＩＭに関連付けられる（ユーザがオプトアウトしない限り）。アカウント情報には、Ｌ３認証のための十分な情報が含まれる。例えば、これには、認証のための、プリンシパル（例えば、ｘ２ｚ＠ｙａｈｏｏ．ｃｏｍ）、及びそれに関連付けられたサービスプロバイダが含まれ得る。ｅＳＩＭに関連付けられたアカウント情報がない場合は、ユーザは他の認証方法と共にｅＳＩＭをエクスポートすることができる。そのような一実施形態は、機器の物理的な所有を証明するｅＵＩＣＣにセキュアに接続されている物理的なボタンを含む。別の実施形態において、各ｅＳＩＭは一意のパスワードを含み、ユーザは自らの所有権を証明するパスワードを有しなければならない。ＯＥＭ認証情報を使用することも更に別のオプションである。

ユーザがｅＳＩＭをエクスポートする場合、ＡＰはｅＵＩＣＣから、インストールされたプロファイルのリストを取得する。各プロファイルについて、ｅＵＩＣＣは更に、関連付けられたプリンシパルと、リプレイ防止のために生成されたノンスとを返す。ユーザがプロファイルをエクスポートすることを選択した場合、ＡＰはプリンシパルに含まれる情報を使用して、サービスプロバイダからシングルサインオン（ＳＳＯ）トークンを取得し、ユーザには、この目的のためにユーザ名とパスワードを入力するようプロンプトが提示され得る。ＳＳＯトークンは、エクスポート要求において、プリンシパル及びノンスと一緒にサーバブローカーに渡される。サーバブローカーは、機器により供給されたＳＳＯトークンを使用して、サービスプロバイダと共に認証を処理することができる。認証が合格すると、フローは機器へのｅＳＩＭ配信を反映するが、ただしクライアントとサーバの役割は逆転する。高レベルにおいて、サーバブローカーはｅＵＩＣＣとのセッションを開始し、そのエクスポートのための要求ＢＬＯＢを作成する。この要求には、動作がＬ３認証に合格したことを示すための、ｅＵＩＣＣが生成したノンスが含まれる。ｅＵＩＣＣは要求ＢＬＯＢを検証し、サーバエージェントの公開鍵を使ってｅＳＩＭを暗号化し、そのｅＳＩＭのためのバッチ記述子及びＬ３所有者情報を作成する。Ｌ３及びＬ２情報と共にｅＳＩＭは、サーバに送られ得る。

ｅＵＩＣＣがエクスポートのためにｅＳＩＭを暗号化すると、ｅＵＩＣＣはそのｅＳＩＭの所有権を放棄し、そのｅＳＩＭをもはや使用しないか、あるいはそのｅＳＩＭを任意の他のエンティティにエクスポートしない。いくつかの場合において、ｅＵＩＣＣは暗号化されたコピーを保存して、接続喪失（すなわち、暗号化ｅＳＩＭがサーバに全く到達しない場合）からのリカバリに役立てることができる。あるいは、ＡＰは、接続障害の場合に再送信を行うため、暗号化されたｅＳＩＭのコピーを保存し得る。サーバは承認を返すことができ、これによりＡＰをトリガして、記憶されたコピーを除去する。

いくつかの実施形態において、エクスポートは、ウェブポータルから開始することもできる。ユーザが自分の機器を紛失した場合は、ウェブポータルを使用して、自分の機器からｅＳＩＭをエクスポートすることができる。この場合、ウェブポータルはその機器と通信を行って、エクスポート動作を開始し得る。このフローは同様であるが、ただし、ユーザはＡＰの代わりにウェブポータルを使用して、所有権検証のためにＳＳＯトークンを取得し得る。

装置
上述の方法に関連して有用な様々な装置が、ここで詳しく記述される。

ｅＵＩＣＣアプライアンス
図１２は、本開示によるｅＵＩＣＣアプライアンス１２００の例示的な一実施形態を示す。ｅＵＩＣＣアプライアンスは、スタンドアロンのエンティティを含み得、又は、例えばサーバなどの他のネットワークエンティティを組み込み得る。図示のように、ｅＵＩＣＣアプライアンス１２００は一般に、通信ネットワークとのインタフェースのためのネットワークインタフェース１２０２、プロセッサ１２０４、及び１つ以上の記憶装置１２０６を含む。ネットワークインタフェースはＭＮＯインフラストラクチャに接続した状態で示されており、これにより、他のｅＵＩＣＣアプライアンスへのアクセス、及び１つ以上のモバイル機器への直接的又は間接的なアクセスが提供されているが、ただし、他の構成及び機能に置換することもできる。

一構成において、このｅＵＩＣＣアプライアンスは次のことが可能である。（ｉ）他のｅＵＩＣＣ（ｅＵＩＣＣアプライアンス又はクライアント機器）との通信を確立する、（ｉｉ）ｅＳＩＭをセキュアに記憶する、（ｉｉｉ）セキュアに記憶されたｅＳＩＭを取得する、（ｉｖ）他の特定のｅＵＩＣＣに配信するために、ｅＳＩＭを暗号化する、及び（ｖ）ｅＳＩＭデポとの間で複数のｅＳＩＭの送信のやりとりを行う。

ｅＳＩＭデポ
図１３は、本開示によるｅＳＩＭデポ１３００の例示的な一実施形態を示す。ｅＳＩＭデポ１３００は、スタンドアロンエンティティとして実施することができ、あるいは、他のネットワークエンティティ（例えば、ｅＵＩＣＣアプライアンス１２００）を組み込み得る。図示のように、ｅＳＩＭデポ１３００は一般に、通信ネットワークとのインタフェースのためのネットワークインタフェース１３０２、プロセッサ１３０４、及び記憶装置１３０６を含む。

図１３に図示される実施形態において、ｅＳＩＭデポ１３００は次のことが可能である。（ｉ）ｅＳＩＭのインベントリ管理（例えば関連付けられているメタデータを介して）、（ｉｉ）暗号化されたｅＳＩＭのための（例えば、他のｅＳＩＭデポ及び／又はｅＵＩＣＣアプライアンス１２００からの）要求に対する応答、（ｉｉｉ）ｅＳＩＭのための加入者要求の管理。

例えば、あるｅＳＩＭがユーザによりｅＳＩＭデポ１３００に記憶されているとき、そのｅＳＩＭは意図された行先と共に記憶することができ（例えば、他の機器への転送を促進するため）、又は無期限に駐留させることができる。いずれの場合でも、ｅＳＩＭデポは、セキュアな記憶、及び行先装置向けのその後の暗号化のために、ｅＳＩＭをｅＵＩＣＣアプライアンスに提供することができる。

ユーザ装置
ここで図１４を参照して、本開示の様々な態様による例示的なユーザ装置１４００が図示されている。

図１４の例示的なＵＥ装置は、プロセッササブシステム１４０２（例えば、デジタル信号プロセッサ、マイクロプロセッサ、フィールドプログラマブルゲートアレイ、又は１つ以上の基板に搭載された複数の処理構成要素）を備えた無線機器である。この処理サブシステムはまた、内部キャッシュメモリも含み得る。この処理サブシステムは、メモリサブシステム１４０４と通信しており、メモリサブシステムには例えば、ＳＲＡＭ、フラッシュ、及び／又はＳＤＲＡＭ構成要素を含み得るメモリが含まれる。このメモリサブシステムは、当該技術分野において周知のようにデータアクセスを促進するために、１つ以上のＤＭＡタイプのハードウェアを実装することができる。このメモリサブシステムは、プロセッササブシステムにより実行可能な、コンピュータ実行可能命令を含む。

例示的な一実施形態において、この機器は、１つ以上の無線ネットワークに接続するよう適合された、１つ以上の無線インタフェース１４０６を含む。複数の無線インタフェースは、例えば、ＧＳＭ、ＣＤＭＡ、ＵＭＴＳ、ＬＴＥ／ＬＴＥ−Ａ、ＷｉＭＡＸ、ＷＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの異なる無線技術を、無線技術分野で周知である適切なアンテナ及びこの種の現行のサブシステムを実装することによりサポートし得る。

ユーザインタフェースサブシステム１４０８は、任意の数の周知のＩ／Ｏを含み、これには、キーパッド、タッチスクリーン（例えば、マルチタッチインタフェース）ＬＣＤディスプレイ、バックライト、スピーカー、及び／又はマイクロホンが挙げられるがこれらに限定されない。しかしながら、特定の適用例では、これらの構成要素のうちの１つ以上が不要となり得ることが認識されよう。例えば、ＰＣＭＣＩＡカードタイプクライアントの実施形態は、ユーザインタフェースが欠如する場合がある（それらは、物理的及び／又は電気的に結合されるホスト機器のユーザインタフェースを、便乗して利用することが可能であるため）。

図示の実施形態において、機器には、ｅＵＩＣＣアプリケーションを含み動作するセキュアエレメント１４１０が含まれる。このｅＵＩＣＣは、ネットワークオペレータとの認証に使用するための、複数のアクセス制御クライアントを記憶し、これにアクセスすることができる。セキュアエレメントには、セキュアな媒体に記憶されているソフトウェアを実行するセキュアプロセッサが含まれる。このセキュアな媒体は、他の構成要素（セキュアプロセッサ以外）に対してはアクセス不可である。更に、例示的なセキュアエレメントは、前述のように、改ざんを防止するために更に硬化することができる（例えば、樹脂に封入）。例示的なセキュアエレメント１４１０は、１つ以上のアクセス制御クライアントを受信し記憶することができる。一実施形態において、セキュアエレメントは、ユーザに関連付けて（例えば、１つを仕事用、１つを個人用、いくつかをローミングアクセス用、など）、及び／又は他の論理方式又は関係に従って（例えば、１つを家族又は事業エンティティの複数の各メンバー用、１つを家族メンバーの個人と仕事用それぞれに、など）、ｅＳＩＭのアレイ又は複数のｅＳＩＭを記憶する。各ｅＳＩＭには小さなファイルシステムが含まれ、これにはコンピュータ可読命令（ｅＳＩＭプログラム）及び関連データ（例えば、暗号鍵、完全性鍵など）が含まれる。

このセキュアエレメントは更に、モバイル機器との間のｅＳＩＭの転送を可能にするよう適合することができる。一実施形態において、モバイル機器はＧＵＩベースの承認を提供して、ｅＳＩＭの転送を開始する。

モバイル機器のユーザがｅＳＩＭのアクチベーションを行うことを決めると、そのモバイル機器は、アクチベーションサービスにアクチベーションの要求を送る。モバイル機器は、標準の認証及び鍵合意（ＡＫＡ）交換のためにｅＳＩＭを使用することができる。

方法
上述の方法に関連して有用な様々な方法が、ここで詳しく記述される。

図１５は、電子アクセス制御クライアントの大規模配信のための方法の一実施形態を示す。

ステップ１５０２で、第１の機器が、１つ以上の電子アクセス制御クライアントの所有権を確立する。

ステップ１５０４で、この第１の機器が、１つ以上の電子アクセス制御クライアントが以前に複製されていないかどうかを判定する。

ステップ１５０６で、この第１の機器が、第２の機器への転送のために、１つ以上の電子アクセス制御クライアントを暗号化する。

ステップ１５０８で、第１の機器及び第２の機器が、暗号化された１つ以上の電子アクセス制御クライアントの交換又は転送を行う。

本開示により、当業者には、電子アクセス制御クライアントの大規模配信のための、他の無数の方式が認識されよう。

本開示の特定の態様が、特定の方法の具体的なステップのシーケンスの観点から説明されているが、これらの説明は、本開示のより広範な方法の例示に過ぎないものであり、具体的な適用によって、必要に応じて修正することができる点が、認識されるであろう。特定のステップは、特定の状況下では、不必要又は任意選択とすることができる。更には、特定のステップ又は機能性を、開示される実施形態に追加することができ、あるいは２つ以上のステップの実行の順序を、置き換えることもできる。全てのそのような変更形態は、本明細書で開示され特許請求される、本開示の範囲内に包含されると見なされる。

上記の発明を実施するための形態は、様々な実施形態に適用されるような、本開示の新規の機構を示し、説明し、指摘しているが、例示された機器又はプロセスの形態及び詳細の様々な省略、置換、並びに変更を、本開示から逸脱することなく当業者によって実施することができる点が理解されるであろう。上記の説明は、本開示の実施について現時点で想到される最適な例である。本説明は、限定することを決して意図するものではなく、むしろ、本開示の一般的原理の例示として解釈されるべきである。本開示の範囲は、特許請求の範囲に準拠して決定されるべきである。

Claims (20)

1. モバイル装置に含まれる電子ユニバーサル集積回路カード（ｅＵＩＣＣ）に関連付けられた、侵害されたデジタル証明書を交換する様に構成されたｅＵＩＣＣ管理サーバであって、
   それぞれが各ｅＵＩＣＣに関連付けられている複数のデジタル証明書に関連付けられた署名権限が侵害されたことを判定することと、
   前記複数のデジタル証明書の各デジタル証明書について、
   失効リストに前記デジタル証明書を追加することであって、前記失効リストは、（ｉ）前記ｅＵＩＣＣが、前記ｅＵＩＣＣ管理サーバに前記デジタル証明書を含む要求を送信し、（ｉｉ）更新デジタル証明書が前記デジタル証明書より新しい場合に、前記デジタル証明書に関連付けられた前記各ｅＵＩＣＣが前記デジタル証明書を前記更新デジタル証明書に交換する原因となる、前記追加することと、
   を含むステップを、前記ｅＵＩＣＣ管理サーバに実行させる様に構成されたプロセッサを含む、ｅＵＩＣＣ管理サーバ。
2. 前記更新デジタル証明書に含まれる第２エポックのプロパティが、前記デジタル証明書に含まれる第１エポックのプロパティを超えていると、前記更新デジタル証明書が前記デジタル証明書より新しい、請求項１に記載のｅＵＩＣＣ管理サーバ。
3. 前記ステップは、
   （ｉ）前記ｅＵＩＣＣに対応し、かつ、（ｉｉ）前記デジタル証明書に関連付けられている公開鍵（ＰＫｅＵＩＣＣ）を識別することと、
   前記更新デジタル証明書を取得することと、
   をさらに含み、
   前記更新デジタル証明書は、前記ＰＫｅＵＩＣＣと、前記署名権限に対応する更新された秘密鍵（ＳＫＵｐｄａｔｅｄ＿ＳＡ）と、に基づく、請求項１に記載のｅＵＩＣＣ管理サーバ。
4. 前記複数のデジタル証明書の各デジタル証明書について、前記ＰＫｅＵＩＣＣを識別することは、最初に前記デジタル証明書を生成させた証明書署名要求（ＣＳＲ）を取得することを含む、請求項３に記載のｅＵＩＣＣ管理サーバ。
5. 前記複数のデジタル証明書の各デジタル証明書について、前記デジタル証明書及び前記更新デジタル証明書は、（ｉ）前記ＰＫｅＵＩＣＣと、（ｉｉ）前記ＰＫｅＵＩＣＣに対応する秘密鍵（ＳＫｅＵＩＣＣ）と、に関連付けられている、請求項４に記載のｅＵＩＣＣ管理サーバ。
6. 前記複数のデジタル証明書の各デジタル証明書について、前記デジタル証明書は、前記署名権限に対応する元の秘密鍵（ＳＫＯｒｉｇｉｎａｌ＿ＳＡ）を使用してデジタル的に署名され、前記ＳＫＯｒｉｇｉｎａｌ＿ＳＡは、侵害されている、請求項３に記載のｅＵＩＣＣ管理サーバ。
7. 前記ＳＫＵｐｄａｔｅｄ＿ＳＡは、前記ＳＫＯｒｉｇｉｎａｌ＿ＳＡの改変に応答して前記署名権限により生成される、請求項６に記載のｅＵＩＣＣ管理サーバ。
8. モバイル装置に含まれる電子ユニバーサル集積回路カード（ｅＵＩＣＣ）に関連付けられた、侵害されたデジタル証明書を交換する方法であって、
   ｅＵＩＣＣ管理サーバにおいて、
   それぞれが各ｅＵＩＣＣに関連付けられている複数のデジタル証明書に関連付けられた署名権限が侵害されたことを判定することと、
   前記複数のデジタル証明書の各デジタル証明書について、
   失効リストに前記デジタル証明書を追加することであって、前記失効リストは、（ｉ）前記ｅＵＩＣＣが、前記ｅＵＩＣＣ管理サーバに前記デジタル証明書を含む要求を送信し、（ｉｉ）更新デジタル証明書が前記デジタル証明書より新しい場合に、前記デジタル証明書に関連付けられた前記各ｅＵＩＣＣが前記デジタル証明書を前記更新デジタル証明書に交換する原因となる、前記追加することと、
   を含む、方法。
9. 前記更新デジタル証明書に含まれる第２エポックのプロパティが、前記デジタル証明書に含まれる第１エポックのプロパティを超えていると、前記更新デジタル証明書が前記デジタル証明書より新しい、請求項８に記載の方法。
10. （ｉ）前記ｅＵＩＣＣに対応し、かつ、（ｉｉ）前記デジタル証明書に関連付けられている公開鍵（ＰＫｅＵＩＣＣ）を識別することと、
    前記更新デジタル証明書を取得することと、
    をさらに含み、
    前記更新デジタル証明書は、前記ＰＫｅＵＩＣＣと、前記署名権限に対応する更新された秘密鍵（ＳＫＵｐｄａｔｅｄ＿ＳＡ）と、に基づく、請求項８に記載の方法。
11. 前記複数のデジタル証明書の各デジタル証明書について、前記ＰＫｅＵＩＣＣを識別することは、最初に前記デジタル証明書を生成させた証明書署名要求（ＣＳＲ）を取得することを含む、請求項１０に記載の方法。
12. 前記複数のデジタル証明書の各デジタル証明書について、前記デジタル証明書及び前記更新デジタル証明書は、（ｉ）前記ＰＫｅＵＩＣＣと、（ｉｉ）前記ＰＫｅＵＩＣＣに対応する秘密鍵（ＳＫｅＵＩＣＣ）と、に関連付けられている、請求項１１に記載の方法。
13. 前記複数のデジタル証明書の各デジタル証明書について、前記デジタル証明書は、前記署名権限に対応する元の秘密鍵（ＳＫＯｒｉｇｉｎａｌ＿ＳＡ）を使用してデジタル的に署名され、前記ＳＫＯｒｉｇｉｎａｌ＿ＳＡは、侵害されている、請求項１０に記載の方法。
14. 前記ＳＫＵｐｄａｔｅｄ＿ＳＡは、前記ＳＫＯｒｉｇｉｎａｌ＿ＳＡの改変に応答して前記署名権限により生成される、請求項１３に記載の方法。
15. モバイル装置に含まれる電子ユニバーサル集積回路カード（ｅＵＩＣＣ）に関連付けられた、侵害されたデジタル証明書を交換する様に構成されたｅＵＩＣＣ管理サーバであって、
    それぞれが各ｅＵＩＣＣに関連付けられている複数のデジタル証明書に関連付けられた署名権限が侵害されたことを判定し、
    前記複数のデジタル証明書の各デジタル証明書について、
    失効リストに前記デジタル証明書を追加する様に構成され、
    前記失効リストは、（ｉ）前記ｅＵＩＣＣが、前記ｅＵＩＣＣ管理サーバに前記デジタル証明書を含む要求を送信し、（ｉｉ）更新デジタル証明書が前記デジタル証明書より新しい場合に、前記デジタル証明書に関連付けられた前記各ｅＵＩＣＣが前記デジタル証明書を前記更新デジタル証明書に交換する原因となる、ｅＵＩＣＣ管理サーバ。
16. （ｉ）前記ｅＵＩＣＣに対応し、かつ、（ｉｉ）前記デジタル証明書に関連付けられている公開鍵（ＰＫｅＵＩＣＣ）を識別し、
    前記更新デジタル証明書を取得する様にさらに構成され、
    前記更新デジタル証明書は、前記ＰＫｅＵＩＣＣと、前記署名権限に対応する更新された秘密鍵（ＳＫＵｐｄａｔｅｄ＿ＳＡ）と、に基づく、請求項１５に記載のｅＵＩＣＣ管理サーバ。
17. 前記複数のデジタル証明書の各デジタル証明書について、前記ＰＫｅＵＩＣＣを識別することは、最初に前記デジタル証明書を生成させた証明書署名要求（ＣＳＲ）を取得することを含む、請求項１６に記載のｅＵＩＣＣ管理サーバ。
18. 前記複数のデジタル証明書の各デジタル証明書について、前記デジタル証明書及び前記更新デジタル証明書は、（ｉ）前記ＰＫｅＵＩＣＣと、（ｉｉ）前記ＰＫｅＵＩＣＣに対応する秘密鍵（ＳＫｅＵＩＣＣ）と、に関連付けられている、請求項１７に記載のｅＵＩＣＣ管理サーバ。
19. 前記複数のデジタル証明書の各デジタル証明書について、前記デジタル証明書は、前記署名権限に対応する元の秘密鍵（ＳＫＯｒｉｇｉｎａｌ＿ＳＡ）を使用してデジタル的に署名され、前記ＳＫＯｒｉｇｉｎａｌ＿ＳＡは、侵害されている、請求項１６に記載のｅＵＩＣＣ管理サーバ。
20. 前記ＳＫＵｐｄａｔｅｄ＿ＳＡは、前記ＳＫＯｒｉｇｉｎａｌ＿ＳＡの改変に応答して前記署名権限により生成される、請求項１９に記載のｅＵＩＣＣ管理サーバ。

Images