特許 5992535 無線ＩＤプロビジョニングを実行するための装置及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5992535

(24)【登録日】2016年8月26日

(45)【発行日】2016年9月14日

(54)【発明の名称】無線ＩＤプロビジョニングを実行するための装置及び方法

(51)【国際特許分類】

   G06F 21/31 20130101AFI20160901BHJP

   H04W 12/06 20090101ALI20160901BHJP

   G09C 1/00 20060101ALI20160901BHJP

【ＦＩ】

   G06F21/31

   H04W12/06

   G09C1/00 660E

【請求項の数】3

【全頁数】17

(21)【出願番号】特願2014-550267(P2014-550267)

(86)(22)【出願日】2011年12月30日

(65)【公表番号】特表2015-508536(P2015-508536A)

(43)【公表日】2015年3月19日

(86)【国際出願番号】US2011068050

(87)【国際公開番号】WO2013101164

(87)【国際公開日】20130704

【審査請求日】2014年6月27日

(73)【特許権者】

【識別番号】593096712

【氏名又は名称】インテル コーポレイション

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】スミス，ネッド，エム．

(72)【発明者】

【氏名】バクシ，サンジャイ

【審査官】 宮司 卓佳

(56)【参考文献】

【文献】 特開２００２−３１８８０８（ＪＰ，Ａ）

【文献】 特開２０１１−０７０３９０（ＪＰ，Ａ）

【文献】 特開２００２−２０７９２９（ＪＰ，Ａ）

【文献】 特開２００６−１８５３１３（ＪＰ，Ａ）

【文献】 特開２０１１−０３４２２３（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ２１／３１−２１／４６

Ｇ０９Ｃ １／００

Ｈ０４Ｗ １２／０６

(57)【特許請求の範囲】

【請求項1】

無線（ＯＴＡ）リンクに結合されるインターフェースと、
ユーザの第１のＩＤに対応するデータを記憶する記憶エリアであって、前記第１のＩＤに対応する前記データは前記ユーザの複数の認証情報を含む記憶エリアと、
ユーザから要求を受信し、前記要求の受信に応じて、前記ユーザに対してトランスペアレントに前記ＯＴＡリンクを介して前記第１のＩＤの認証情報を受信するためにＩＤプロバイダと前記ＯＴＡリンクを自動的に確立し、トランスペアレントに前記ＯＴＡリンクを介して受信された前記第１のＩＤの前記認証情報に基づいて、前記ユーザに対してトランスペアレントに前記ユーザの第２のＩＤを確立するプロセッサとを備え、前記第１のＩＤに対応する前記データは、セキュア・プロトコル・セッション中に前記インターフェースを通して受信され、前記第１のＩＤは第１のサービスのために確立され、前記第２のＩＤは第２のサービスのために確立され、前記第１のサービス及び前記第２のサービスは前記ユーザの電子デバイスによって受信される、前記電子デバイスに含まれる装置であって、前記ユーザの前記第１のＩＤに対応する前記データは暗号化された信号において受信され、前記暗号化された信号は、匿名でＩＤの証明を与える暗号化プロトコルの鍵を用いて暗号化される装置。

【請求項2】

情報へのアクセスを制御するための方法であって、
無線（ＯＴＡ）リンクを通してＩＤプロバイダに要求を送信するステップであって、前記要求は、第１のＩＤに基づいて第２のＩＤを確立するために前記ＩＤプロバイダから受信される１つ又は複数のＩＤ認証情報を特定する情報を含むステップと、
ＩＤリクエスタにおいて、前記要求が送信された後に、前記ＩＤプロバイダからデータを受信するステップであって、前記ＩＤプロバイダからの前記データはユーザの第１のＩＤに対応し、前記ユーザの前記第１のＩＤに対応する前記データは暗号化された信号において受信され、前記暗号化された信号は、匿名でＩＤの証明を与える暗号化プロトコルの鍵を用いて暗号化される、受信するステップと、
前記ＩＤリクエスタにおいて、前記ユーザに対してトランスペアレントに、前記ＩＤプロバイダから受信された前記データに基づいて前記ユーザの第２のＩＤを確立するステップとを含み、前記第１のＩＤに対応する前記データはセキュア・プロトコル・セッション中に前記ユーザに対してトランスペアレントに受信され、前記第１のＩＤは第１のサービスのために前記ＩＤプロバイダによって確立され、前記第２のＩＤは前記ＩＤリクエスタによって前記ユーザに対してトランスペアレントに第２のサービスを受信するために確立され、前記第１のサービス及び前記第２のサービスは前記ユーザの電子デバイスによって受信され、前記ＩＤリクエスタは前記電子デバイスに含まれる、情報へのアクセスを制御するための方法。

【請求項3】

前記ＩＤリクエスタは前記第２のサービスを提供する、請求項２に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本明細書における１つ又は複数の実施形態は電子情報管理に関連する。

【背景技術】

【0002】

ユーザのＩＤ（identity）を確立することは、多くのタイプのネットワーク・サービスを受信することへの前提条件である。これは、ユーザにある用紙に情報を記入させることによって、電話を介して情報を与えることによって、及び／又はウェブサイトを用いて情報を入力することによって、手作業で実行されてきた。これらの技法は、コストがかかり、非効率的であることが実証されている。

【0003】

最近になって、ネットワーク・サービスを受信するための要件として、ユーザのＩＤを確立するプロセスを自動化しようという努力がなされている。これらの努力は、ワイヤレス・ネットワークを介して情報を受信し、ユーザＩＤを確立することを含んでいる。情報がワイヤレスで受信されるので、この技術は多くの場合に無線（Over-the-Air）（ＯＴＡ）ＩＤプロビジョニングと呼ばれてきた。

【0004】

既存のＯＴＡ・ＩＤプロビジョニング技法は、ユーザ認証情報が入手され、認証される方法に関して非効率的である。更に、これらの技法は、そのユーザに対するＩＤを既に認証し、確立している他のソース又はドメインとは独立してＩＤを確立しようと試みる。

【図面の簡単な説明】

【0005】

【図1】無線（ＯＴＡ）ＩＤプロビジョニングを実行するためのシステムを示す図である。

【図2】デバイス・ユーザに対して確立された既存のＩＤに基づいてＯＴＡ・ＩＤを確立するための方法の一実施形態を示す図である。

【図3】ＩＤプロバイダにおける第１のＩＤ認証情報の一例を示す図である。

【図4】ＩＤリクエスタの一実施形態を示す図である。

【図5】ＯＴＡ・ＩＤプロビジョニングを実行するための別の方法を示す図である。

【図6】ＯＴＡ・ＩＤプロビジョニングを実行するための別の方法を示す図である。

【図7】ＯＴＡ・ＩＤプロビジョニングを実行するための別の方法を示す図である。

【図8】ＯＴＡ・ＩＤプロビジョニングを実行するための別の方法を示す図である。

【図9】ＩＤリクエスタが電子デバイス内に位置する、ＯＴＡ・ＩＤプロビジョニングを実行するためのシステムの別の実施形態を示す図である。

【図10】ＩＤプロバイダとリクエスタとの間でシグマ・セッションを実施するために行われる場合があるメッセージの交換を示す図である。

【発明を実施するための形態】

【0006】

図１は、一実施形態に従ってＯＴＡ・ＩＤプロビジョニングが実行されるシステムの一例を示す。この実施形態では、ワイヤレス・デバイス１０のユーザは、プロバイダから１つ又は複数のサービス、商品又は情報を入手しようとする。ワイヤレス・デバイスは、モバイル若しくはスマート・フォン、ノートブック若しくはデスクトップ・コンピュータ、携帯情報端末、ポッド若しくはパッドタイプ・デバイス、タブレット、又はワイヤレス能力を備えている幾つかの他の電子デバイスのうちのいずれか１つとすることができる。本明細書において説明される実施形態は、モバイル・デバイスにも関連することができる。しかしながら、他の実施形態では、固定式又は可搬式であると見なされるデバイスも、本明細書において説明される方法及びシステムの対象とすることができる。

【0007】

ＩＤプロバイダは、金融サービス、メディア若しくはエンターテインメント・サービス、通信サービス、インターネット関連サービス、及び／又は個人若しくは企業／ビジネス・ソースからの他のサービスを提供することができる。一例によれば、電子デバイスのユーザは、そのソース又はサービスに対して、加入している場合があるか、又は他の約束された形の支払いをしている、若しくは会員である場合がある。プロバイダがサービスを提供できる前に、そのプロバイダはユーザの信頼できるＩＤを確立しなければならない。このために、そのプロバイダは図１においてＩＤリクエスタ２０として説明される。

【0008】

本実施形態によれば、ＩＤリクエスタは、別のプロバイダによって既に確立されているＩＤに基づいて電子デバイスのユーザに対するＩＤを確立する。したがって、他のプロバイダが、既に確立されているＩＤを示す情報をＩＤリクエスタ２０によって使用するために提供する。それゆえ、リクエスタ２０及びプロバイダ３０がいずれも実際にはプロバイダであるという了解のもとで、他方のプロバイダは図１との関連においてＩＤプロバイダ３０として説明される。

【0009】

ＩＤプロバイダ３０は、金融サービス、メディア若しくはエンターテインメント・サービス、通信サービス、インターネット関連サービス、及び／又は種々の他のサービスをユーザに提供することができる。一例によれば、ＩＤプロバイダは、小売業者、公共施設、政府機関、又はユーザによって求められる商品及び／若しくはサービス及び／若しくは情報を提供し、かつＩＤの確立及び認証が要求される他のタイプの個人、企業又はビジネス・ソースとすることができる。

【0010】

ワイヤレス・デバイス１０は、ワイヤレス・リンク４０を介してＩＤリクエスタ２０と通信することができ、例えば、ワイヤレス・リンクは、１つ又は複数のモバイル・ネットワークを通して確立することができるか、又は限定はしないが、インターネットのような有線若しくはワイヤレス・ネットワークに接続される短距離リンクを通して確立することができる。そのデバイスは、同じタイプのリンクを介してＩＤプロバイダ３０と通信することもできる。

【0011】

代替的には、ＩＤプロバイダはデバイス１０と直接通信するのではなく、むしろ、デバイスの使用とは関係のない方法で、このデバイスのユーザのＩＤを単に保持する場合がある。例えば、ＩＤプロバイダはクレジット・カード会社、銀行、投資顧問、株式仲買人、保険会社又は他の金融機関とすることができる。この場合、ＩＤプロバイダ３０は、以下に更に詳細に説明されるように、ＩＤリクエスタ２０によってアクセスできるようになるデータベースにアクセスすることができる。

【0012】

ＩＤリクエスタ２０及びＩＤプロバイダ３０は、無線リンク６０を通して互いに通信する。一実施形態によれば、ＩＤリクエスタとＩＤプロバイダとの間で交換される情報は、格納された制御ソフトウェアに基づいて、ユーザに対してトランスペアレントに発生することができる。交換された情報を用いて、ＩＤリクエスタは自らのドメインにおいてユーザに対するＩＤを認証及び確立し、それにより、手作業、又は他のコストがかかり、非効率的なデータ入力の必要性を緩和する。リンク６０はユーザに対してトランスペアレントに確立されるので、幾つかのアプリケーションにおいて「バック・チャネル（ｂａｃｋ ｃｈａｎｎｅｌ）」と呼ばれる場合がある。

【0013】

図２は、モバイル・デバイス・ユーザに対して確立された既存のＩＤに基づいてＯＴＡ・ＩＤを確立するための方法の一実施形態を示す。この方法は、図１に示されるようなシステム又は異なるシステムにおいて実施することができる。ＩＤプロバイダ及びＩＤリクエスタ内に少なくとも部分的に位置する制御ソフトウェアを用いて、その方法を実施することができる。

【0014】

第１のＩＤの確立
初期動作は、モバイル・デバイスのユーザから、ＩＤプロバイダからのサービスを受信する要求２１０を受信することを含む。例示のために、本実施形態では、サービスは加入に基づくものと仮定される。しかしながら、他の実施形態では、他の商品及び／又はサービスが取り扱われる場合がある。その要求は、例えば、電話を介して、本人が直に、インターネットを介して行われる要求を通して、又はデバイスからワイヤレスで行われる要求を含む、店舗及び他の方法で受信することができる。

【0015】

要求が行われると、ＩＤプロバイダは、加入を確立するためにユーザに対するＩＤ２２０（第１のＩＤと呼ばれる）を確立する。そのＩＤは、従来の技法を用いて確立される場合がある。例えば、示されるように、ユーザのＩＤは、手作業で、又は別の方法で入力されたユーザ情報に基づくことができ、生年月日、住所、社会保障番号、クレジット・カード又は口座番号、及びユーザのＩＤを確認することができる信頼性のある基礎を構成する他の情報を含むことができる。これらの技法は、「アウトオブバンド」加入又はＩＤ決定技法と呼ばれる場合がある。

【0016】

ユーザが認証され、そのＩＤが確立されると、第１のＩＤ認証情報２３０が電子的にアクセス可能なデータベース又は他の記憶デバイスに記憶される。これらの認証情報は、上記のユーザ情報に基づいており、ユーザに対する第２のＩＤを確立するための基礎として信頼される。

【0017】

第２のＩＤの確立
第１のＩＤ認証情報が記憶された後に、ユーザは、ＩＤリクエスタからサービス２５０を受信するために、加入を要求する。その要求は、例えば、ワイヤレス・ネットワークを介して、モバイル・デバイス１０から直接行うことができる。代替的には、その要求は、ユーザのモバイル・デバイス上でアクセスされるインターネット・ウェブサイトを通して行うことができる。一例によれば、その要求は、サービスへの加入要求、ウェブサイトへの入会要求、オンライン購入要求、又は別の状況に応じて行われる。

【0018】

１つの具体例によれば、要求をするとき、ユーザは、ユーザ・アカウントを作成するための選択可能なオプションを含む、ＩＤプロバイダのウェブページにアクセスすることができる。そのアカウントは、ユーザ名、パスワード、セキュリティに関する質問への回答、及び他の情報に基づいて作成することができる。別の例では、ユーザは、例えば、公開鍵インフラストラクチャ（ＰＫＩ）鍵に基づいて暗号化された情報の初期転送を与えることができる。その情報は、例えば、証明書要求メッセージの送信に基づいて転送される場合があり、そのメッセージは、ユーザ及び／又はユーザのデバイスに対するデジタル証明書を構成するために証明機関によって用いられる場合がある。

【0019】

要求されると、ＩＤリクエスタは、ユーザの第１のＩＤ認証情報を含む、記憶デバイスからの情報を受信するためのリンク（例えば、ＯＴＡバック・チャネル接続）を自動的に確立することを含む手順を実行する。第１のＩＤ認証情報はＩＤプロバイダのデータベース又は記憶デバイス内に記憶されるので、上記の手順は、ＩＤプロバイダとのリンクが確立されることが必要とされる場合がある。

【0020】

リンクを確立するために、ＩＤリクエスタは、例えば、ユーティリティ・ツールに基づいて、ＩＤプロバイダ３０の存在及び連絡先情報を特定する。より具体的には、ユーザはパスワード・マネージャのようなユーティリティ・ツールを用いて自分のＩＤを管理することができ、パスワード・マネージャはウェブ統合機能を有し、その機能によれば、ユーザ名／パスワードの入力を指示するユニバーサル・リソース・ロケータ（ＵＲＬ）が、オート・コンプリーション／フォーム記入のためにパスワード・マネージャにリダイレクトされる。

【0021】

一実施形態によれば、マネージャ・ツールは、新たなユーザＩＤが作成されることを検出することができる。ユーザに新たなユーザ名及びパスワードを作成するように指示するのではなく、ユーザは、第１のユーザＩＤに対応する情報に基づいて新たなＩＤ（例えば、ユーザ名及びパスワード）を構成する代替の選択肢を与えられる場合があり、その情報は、例えば、ユーザ名、デジタル証明書、及び／又はユーザを識別するための他の情報を含むことができる。

【0022】

ユーザ名及びパスワードの場合、パスワード・マネージャは、ウェブサイトＵＲＬを呼び戻す情報を記憶することができる（例えば、オートフィルインのため）。その後、このＵＲＬを用いて、ＩＤ再利用要求を構成することができる。そのＩＤが証明書であるか、又は証明書を含む場合には、その証明書は、発行者ＲＤＮ及び発行者ＵＲＬのような発行者連絡先情報を含むことができ、その発行者はＩＤプロバイダ３０に対応している。この情報に基づいて、ＩＤリクエスタは、第１のＩＤ認証情報を受信するためのリンクを確立することができる。

【0023】

リンクが確立されると、ＩＤリクエスタによって提示された加入をユーザが受信できるようにするために、そのユーザのための第２のＩＤ２６０を確立する際に用いるための第１のＩＤ認証情報がＩＤリクエスタに送信される。ＩＤリクエスタは、第１のＩＤ認証情報を受信するために、上記のバック・チャネルを介して、ＩＤプロバイダと連絡を取ることができる。示されるように、これは、自動的に（例えば、ユーザの加入要求に応答して）、かつユーザに対してトランスペアレントに行うことができる。

【0024】

受信されると、ＩＤプロバイダは、第１のＩＤ認証情報に基づいて、ユーザを認証し、その後、この情報に基づいて第２のＩＤを確立する。一例によれば、第１のＩＤは、ユーザ名、パスワード及び／又はデジタル証明書を含むことができる。また、第１のＩＤ及び第２のＩＤは同じにすることができるか、又は互いに異なることができ、例えば、異なるユーザ名及びパスワードを有することができる。第１のＩＤがデジタル証明書であり、第２のＩＤが確立されることになる場合、例えば、異なる証明機関でのエンロールメント・プロセスの実行に基づいて、異なる証明書が作成される場合がある。

【0025】

ＩＤリクエスタからの加入要求（又は他のサービス要求）はワイヤレスで行われ、及び／又はＩＤプロバイダから得られる情報は、モバイル・ネットワークを含むリンクを介してワイヤレスで得られるので、第２のＩＤを確立するための手順は、無線（ＯＴＡ）ＩＤプロビジョニングと呼ばれる場合がある（したがって、ＩＤリクエスタとＩＤプロバイダとの間のバック・チャネルは、ＯＴＡ接続と呼ばれる場合がある）。第２のＩＤが確立されると、その第２のＩＤに基づいて、ユーザのモバイル・デバイス上でユーザに対してサービス２７０を提供することができる。

【0026】

図３は、第１のＩＤ認証情報をいかに分類することができ、それらの認証情報がＩＤリクエスタにいかに転送されるかの一例を示す。これらの認証情報を転送するために、ＩＤリクエスタ２０は、ＩＤプロバイダ３０へのＯＴＡバック・チャネル２４０を確立する。そのリンクは、例えば、ＩＤリクエスタからＩＤプロバイダに送信される情報要求（request-for-information）（ＲＦＩ）信号に基づいて自動的に確立することができる。

【0027】

ＲＦＩ信号を送信するために、ＩＤリクエスタは最初にＩＤプロバイダ及び対応するアドレス情報を識別しなければならない。これは、例えば、モバイル・デバイスにおいて実行されることになるダウンロードされたアプリケーションに基づいて、又は例えば、コンパクト・ディスク（ＣＤ）又はデジタル多用途ディスク（ＤＶＤ）から読み出されるときに、モバイル・デバイス上に記憶される実行可能ファイルによって成し遂げられる場合がある。実行されるときに、そのアプリケーション又はファイルは、第２のユーザＩＤを確立するために必要とされる認証情報を得るためにＩＤプロバイダへの接続を自動的に確立することができる。

【0028】

インターフェース３３０を通してＲＦＩ信号が受信されると、ＩＤプロバイダ３０内の制御ソフトウェア３４０によって管理されるプロセッサが、記憶デバイス３１０からの１つ又は複数の第１のＩＤ認証情報の出力を制御し、そのデバイスは例えば、加入者データベース、メモリ、又は他の記憶エリアとすることができる。一実施形態によれば、１つ又は複数の選択された認証情報のみがＩＤリクエスタに与えられる場合がある。

【0029】

例えば、第１のＩＤ認証情報が、公開認証情報３２０及び秘密認証情報３３０を含むように分類される場合について考える。公開認証情報は、例えば、住所、電話番号、電子メール・アドレス及び／又はユーザに関連する他の公知の情報に対応することができる。秘密認証情報は、クレジット・カード情報、社会保障番号、パスワード及び／若しくはユーザ名、並びに／又は他の秘密情報を含むことができる。

【0030】

ユーザを認証し、それゆえ、第２のＩＤを確立するために、秘密認証情報は不要である場合がある。更に、ユーザは、特別な許可を得ることなく、この情報に他のエンティティがアクセスするのを個別に阻止したい場合がある。これらの状況下で、公開認証情報３２０はバック・チャネルを介してＩＤリクエスタに送信することができ、秘密認証情報は、秘密認証情報の転送を管理するＩＤプロバイダの制御ソフトウェアに基づいて、送信されないように阻止することができる。

【0031】

その代わりに、又はそれに加えて、秘密認証情報の転送を阻止する判断は、ＩＤプロバイダ内に記憶される１つ又は複数のユーザ設定に基づいて、及び／又はＲＦＩ信号内の情報に基づいて行うことができる。

【0032】

秘密認証情報の転送を阻止することは２つの目的を果たすことができる。

【0033】

第一に、秘密認証情報の転送を阻止することは、ユーザのＩＤを不正利用から保護し、それはネットワークを介して行われる通信にとって益々重要になっている。

【0034】

第二に、秘密認証情報を阻止することによって、ユーザＩＤがＩＤプロバイダによってあらかじめ確認されているという事実に基づいて、第２のＩＤの信憑性を確認できるようになる。ＩＤプロバイダが信頼できる場合には、ユーザのＩＤを別にもう一度確認する必要はない場合がある。これにより、更に、第２のＩＤの確立プロセスが、処理速度及びユーザ利便性に関して、より効率的になる。

【0035】

代替の実施形態では、秘密認証情報は、暗号化された形で、及び／又は情報保護の他の安全な方法を用いてＩＤリクエスタに送信することができる。公開認証情報が秘密認証情報よりも機密性が低いと見なされる場合であっても、同じことを公開認証情報に対して実行することもできる。

【0036】

図４は、ＩＤリクエスタの一実施形態を示しており、ＩＤリクエスタは、ＩＤプロバイダとの安全なＯＴＡ接続を確立するために、信頼できるクライアント・アプレットを実施する能力を備えている。図示されるように、ＩＤリクエスタは、ＯＴＡプロキシ・インターフェース４１０と、ＯＴＡ接続及び第２のユーザＩＤを確立するための動作を実行し、かつ他の処理機能及び管理機能を実行するための管理エンジン４２０を含むプロセッサ４１５と、第２のユーザＩＤを確立するための認証情報を記憶する記憶デバイス４３０とを含む。

【0037】

ＯＴＡプロキシ４１０は、ネットワーク接続性を提供するように動作することができ、管理エンジンが直接ネットワークにアクセスしない場合に用いられる場合がある。一実施形態によれば、ＯＴＡプロキシは、所定の標準規格又はプロトコルに基づいて、モバイル通信システムにおいて信号を中継するためのインターフェースとして動作する。この実施形態では、プロキシはＯＴＡバック・チャネル接続を通して、ＩＤリクエスタとＩＤプロバイダとの間の通信を制御することができる。プロキシは、管理エンジン／コントローラによって実行されるチップセット・ファームウェアとして実現することができ、エンジンの信頼境界外に、又は信頼境界内に存在することができる。

【0038】

他の実施形態では、管理エンジンは、通信ネットワーク及び／又は通信ハブに直接アクセスする場合がある。このシナリオでは、管理エンジンがプロキシとは別にＯＴＡバック・チャネル接続を確立することができるので、プロキシはオプションの機構と見なすことができる。

【0039】

管理エンジン４２０はＯＴＡアプレット（又は他のタイプのアプリケーション）を実行し、ＯＴＡアプレットは、ＩＤプロバイダへのＯＴＡバック・チャネル接続を確立する。この接続はＩＤプロバイダ及びＩＤリクエスタにおけるシグマ・セッション中に確立される場合がある。より具体的には、ＯＴＡ接続は、認証を伴うシグマ・プロトコルを用いて確立される場合がある。ＩＤプロバイダからＩＤリクエスタへの認証情報の転送を管理する所定のＩＤ属性開示ポリシーがＩＤプロバイダによって実施される場合がある。そのようなポリシー（ソフトウェアにおいて実施される）によって、公開認証情報を転送できるようになり、かつ秘密（又は機密性が高い階層の）認証情報をＩＤリクエスタに転送できるようになる場合がある。

【0040】

管理エンジンは、先に説明されたように、ＯＴＡバック・チャネル接続を介して、ＩＤプロバイダの記憶デバイスから認証情報（暗号化されている場合も、されてない場合もある）を受信し、その後、これらの認証情報を記憶デバイス４３０に記憶する。その後、管理エンジンは、記憶された認証情報に基づいて、第２のユーザＩＤを確立し、確立された第２のＩＤに基づいて、ユーザ・デバイスに加入及び／又はサービスを提供する（４５０）。このようにして、管理エンジンは、保護された環境内で信頼できるサービス・マネージャとして動作すると考えることができる。一実施形態によれば、ＯＴＡプロキシ、管理エンジン及び／又は記憶デバイスはＩＤリクエスタのサーバ内に位置することができる。

【0041】

一例によれば、管理エンジンは、ＩＤリクエスタ内に含まれるチップセット内のコントローラによって実現することができる。このエンジンはセキュア・エレメントとして動作することができ、信頼できるコードを実行する強化された安全境界を有する。このコードを実行する際に、ＩＤプロバイダ及びＩＤリクエスタはいずれも、例えば、先に論じられたＲＦＩ信号の送信に応じて、ＩＤプロバイダからＩＤリクエスタに第１のＩＤを転送するための機能に頼ることができる。

【0042】

ＩＤリクエスタからのＲＦＩ信号は管理エンジン・アプレットによって生成することができ、管理エンジン・アプレットは、それに関するＩＤが既に確立されており、記憶された情報がＩＤリクエスタをこのＩＤプロバイダにリンクするための情報を提供するプロバイダを識別するように動作する。この機能を実行する際に、アプレットは、コントローラに、可能なら、ＩＤリクエスタのための第２のＩＤを確立するために必要とされるＩＤ認証情報に近い既存のＩＤを確立しているプロバイダを選択するように指示することができる。また、ＩＤリクエスタは、本明細書において説明されたようにして、ＩＤプロバイダが第１のＩＤに対応する認証情報の開示を許可したことを検証することもできる。

【0043】

例えば、ＩＤプロバイダがＡｍａｚｏｎ．ｃｏｍ（第１のユーザＩＤ認証情報のデータベースを保守管理する）であり、ＩＤリクエスタがビデオオンデマンド（ＶＯＤ）ウェブサイトである場合について考える。このシナリオでは、管理エンジンは信頼できるサードパーティの役割を果たし、そのサードパーティによって、Ａｍａｚｏｎ．ｃｏｍ及びＶＯＤエンティティは、ユーティリティ・ツールを用いて互いに接続できるようになる。そのツールは、Ａｍａｚｏｎ．ｃｏｍのための接続情報（例えば、ＵＲＬ）（例えば、管理エンジンに結合されるメモリ内に記憶される）にアクセスすることができ、その接続情報によって、ＯＴＡバック・チャネル・リンクを確立できるようになる。その後、管理エンジンによって実行される動作に基づいて、ＶＯＤエンティティのための第２のＩＤを確立するために、第１のＩＤ認証情報をＡｍａｚｏｎ．ｃｏｍからＶＯＤエンティティに送信することができる。

【0044】

図５〜図８は、ＯＴＡ・ＩＤプロビジョニングを実行するための方法の更に詳細な実施形態に含まれる動作を示す。この方法は、ＩＤリクエスタとＩＤプロバイダとの間にＯＴＡ接続を確立することを含む（ブロック５１０）。ＩＤリクエスタ及びＩＤプロバイダは先に論じられたものにすることができ、ＯＴＡ接続は、限定はしないが、バック・チャネル接続を含む、先に論じられた任意のタイプの接続であると考えることができる。

【0045】

ＯＴＡ接続は、例えば、図１に示される電子デバイス１０から受信された信号に応答して、又は別の方法で通知されるときに、ＩＤリクエスタによって開始することができる。その信号又は他の通知は、電子デバイス上で実行されるアプリケーションの制御に基づいて受信される場合があるか、又は有線リンク若しくはワイヤレス・リンクを介してユーザから受信された情報に基づいて後の時点で開始される場合がある。

【0046】

接続が確立された後に、ＩＤプロバイダはＩＤリクエスタから１つ又は複数の特定の認証情報の要求を受信する（ブロック５２０）。認証情報は、先に確認された認証情報のいずれかとすることができる。その要求に応じて、ＩＤプロバイダは、そのユーザに対応する記憶エリアから認証情報を検索する。認証情報は、その要求において特定される特定の認証情報の全て又は一部とすることができる。記憶エリアは、ＩＤプロバイダのサーバ内に位置する場合があるか、又は遠隔して位置し、そのサーバに結合される場合がある（ブロック５３０）。

【0047】

検索されると、その要求において特定された全ての認証情報が、検索された認証情報において見つけられるか否かに関する判断が行われる（ブロック５４０）。見つけられると判断された場合には、各認証情報がチェックされることになる（ブロック５５０）。この動作は、ＩＤリクエスタに認証情報を与える際に順守されることになる許可又は開示ポリシーを重視する。

【0048】

例えば、各認証情報（例えば、名前、電話番号、口座番号、ＩＤプロバイダの１つ又は複数の鍵によって署名されたシグネチャ・ビットなど）は、異なる一意性及び機密性を有する場合がある。したがって、幾つかの認証情報は開示を許容できる場合があるが、他の認証情報は、ＩＤプロバイダに対するユーザの信頼を仮定して、許容されない。望ましくない情報の開示を防ぐために、ＩＤプロバイダは、開示されることになる認証情報のネゴシエーションを制御する際に、ユーザの許可（例えば、記憶された情報に基づく）を順守することができる。開示されることを許容された認証情報の転送はシグマ・セッション中に送信され、シグマ・セッションは、望ましくない、又は意図しない開示に対する更なる安全措置を提供する。

【0049】

その要求において特定された全ての認証情報は検索された認証情報において見つけられないと判断された場合には、そのＩＤプロバイダはＩＤリクエスタのための第２のユーザＩＤを確立するために使用できないと結論付けられる。この場合、第２のユーザＩＤを確立するために別のＩＤプロバイダを使用できるか、又は利用可能であるかに関する判断がＩＤリクエスタによって行われる。他のプロバイダによって確立されたＩＤは、あらかじめ確立されたＩＤとすることができる（ブロック５７０）。

【0050】

別のＩＤプロバイダが存在すると判断された場合には、そのＩＤプロバイダに対して、ブロック５３０及び後続のブロックが繰り返される。そうでない場合には、その方法は終了する場合があり、例えば、従来の方法に従って、ユーザのＩＤが確立されなければならない。

【0051】

ブロック５５０における動作が実行された後に、要求において特定された全ての認証情報がユーザによって開示を許可されたか否かに関する判断が行われる（ブロック５６０）。この判断は、例えば、ユーザによってあらかじめ提供され、現時点でＩＤプロバイダにおいて記憶される設定又は許可情報に基づいて、ＩＤプロバイダによって行われる。ユーザによって、全ての要求された認証情報は、ＩＤリクエスタへの開示を許可されない場合には（例えば、そのうちの幾つかが、先に論じられたように、別のエンティティへの転送が許可されない秘密認証情報であるため）、プロセス・フローはブロック５７０に続き、可能なら、別のＩＤプロバイダを特定する。

【0052】

ユーザによって、全ての要求された認証情報が開示を許可される（例えば、全て公開認証情報であるか、又はユーザがあらかじめ開示するのを許可した秘密認証情報を含む）場合には、認証情報の利用可能性を確認するために、ＯＴＡ接続を介して、ＩＤプロバイダからＩＤリクエスタに確認応答信号が送信される（ブロック６１０）。この信号は、ＯＴＡ接続に沿って送信するために、管理エンジンによって生成することができる。

【0053】

確認応答信号が受信された後に、ＩＤリクエスタ内の管理エンジンは第２のユーザＩＤを作成するためのシグマ・セッションを開始する（ブロック６２０）。１つの例示的な実施形態によれば、シグマ・セッションは、シグマ鍵交換プロトコルに基づいて実行される場合がある。このプロトコルを実施する際に、２つのセッション鍵ＭＫ及びＳＫが用いられる場合がある。これらの鍵のうちの一方（ＭＫ）は秘密性を保護するために用いられ、他方の鍵（ＳＫ）は、ＩＤプロバイダとＩＤリクエスタとの間で交換されることになるメッセージの完全性を保護するために用いられる。

【0054】

セッション中に、ＩＤリクエスタは、ＩＤプロバイダに対して、ＩＤリクエスタが信頼できるセキュア・エレメントであることを証明することができる。これは、例えば、セキュア・エレメントのファームウェア構成を厳密に記述するＴＡＳＫＩＮＦＯ信号に基づいて成し遂げることができ、一方、ＥＰＩＤは、そのリンクのクライアント側が特定の（例えば、インテル社の）ハードウェアであることを定めている。図１０は、シグマ・セッションを実施する際に交換される場合があるメッセージの一例を示す。

【0055】

シグマ・セッションが開始された後に、ＩＤリクエスタ内の管理エンジンは、ユーザを認証する手順を実行する（ブロック６３０）。この手順を実行する際に、認証情報がユーザを記述することができ、認証情報はＩＤプロバイダにおいて、又はＩＤプロバイダによって保守管理されているとして、ユーザのセキュア・エレメントに由来していると信用されることは理解されたい。このようにして、認証は、ＩＤプロバイダによるユーザのためのＩＤの確立に基づくことができ、また、先に説明されたように、シグマ・セッション中に交換されるメッセージに従うこともできる。

【0056】

ユーザが認証された後に、認証情報がＩＤプロバイダによって開示するのを許可されるか否かに関する判断が行われる（ブロック６４０）。これは、ＩＤプロバイダ内のコントローラ（例えば、管理エンジン４２０に類似している場合があるか、又は類似していない場合がある）によって実施されるポリシーに基づいて実行することができる。このポリシーは、コントローラに、どの認証情報が、機密性があるか（例えば、優先順位が高いか、及び／又は開示するのを許可されないか）をタグ付けするように指示することができる。それに加えて、又はその代わりに、シグマ・セッション及びＯＴＡバック・チャネル接続を用いて、属性ごとに問合せを実行することができる。認証を実施する擬似コードのサンプルを以下のように与えることができ、ドメインＢがＩＤリクエスタに対応する。
与えられたユーザ１、アサート：
属性ＡをドメインＢに開示するのを許可する（イエス／ノー）
属性ＢをドメインＢに開示するのを許可する（イエス／ノー）
認証情報が、ＩＤプロバイダによって開示するのを許可されない場合には、ブロック５７０の動作を実行して、第２のＩＤを確立するために、別のＩＤプロバイダが利用可能であるか否かを判断する。一方、認証情報が、ＩＤプロバイダによって開示するのを許可される場合には、ＩＤプロバイダがシグマ・エンロールメントをサポートするか否かの判断が行われる（ブロック７１０）。これは、例えば、図１０におけるＳ１メッセージを送信することに基づいて成し遂げることができる。

【0057】

ＩＤプロバイダがシグマ・エンロールメントをサポートしない場合には、制御はブロック５７０に移る。一方、ＩＤプロバイダがシグマ・エンロールメントをサポートすると判断される場合には、ＩＤプロバイダにおいてシグマ・セッションが開始される（ブロック７２０）。シグマ・セッションの開始は、図１０におけるＳ１メッセージを送信することを伴う場合がある。一実施形態によれば、第１のメッセージは、シグマとも呼ばれる、署名付きディフィ−ヘルマン鍵交換プロトコルに基づいて送信される。

【0058】

また、図１０において、検証機構、証明機構及びオンライン証明書状態プロトコル（ＯＳＣＰ）応答機構は、ＩＤプロバイダ、ＩＤリクエスタ及び電子デバイスの任意の組み合わせに対応することができる。また、一例によれば、証明機構は、シグマ・プロトコルのクライアント側に対応すると見なすことができ、検証機構は、シグマ・プロトコルのサーバ側に対応すると見なすことができる。シグマ・プロトコルを用いることによって、証明機構は、検証機構ＩＤを検証できるようになる（したがって、例えば、クライアントは、自らがやりとりしているドメインがわかる）。サーバは、クライアント（例えば、証明機構）が信頼できる環境（例えば、セキュア・エレメント）であることを検証することができる。

【0059】

また、一実施形態では、ＯＳＣＰ応答機構は、取消リスト情報を供給する第３のエンティティとして動作することができる。第３のエンティティは、例えば、証明機関とすることができ、証明機関は、証明機構ハードウェア内に埋め込まれた公開鍵を有し、その公開鍵によって、検証機構の証明書及び証明機関の１つ又は複数の取消リストを検証できるようになる。Ｓ２メッセージ及びＳ３メッセージは証明機構と検証機構との間で交換され、ＯＣＳＰ応答機構からの応答メッセージの受信後にＩＤを検証できるようにする。

【0060】

シグマ・セッションが開始された後に、ＩＤプロバイダのサーバ（又は他の場所）に記憶される要求された認証情報が所定の鍵を用いて暗号化される（ブロック７３０）。暗号化は、例えば、高度暗号化標準（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ：ＡＥＳ）及びトリプル・データ暗号化標準（Ｔｒｉｐｌｅ Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ：３ＤＥＳ）のような対称鍵暗号を用いてシグマ・セッション鍵（ＳＫ）に基づいて実行することができる。シグマ鍵は、ユーザに対応する秘密鍵とすることができるか、又は別のタイプの鍵とすることができる。

【0061】

暗号化されると、認証情報は、ＯＴＡ接続に沿ってＩＤプロバイダからＩＤリクエスタに転送される（ブロック７４０）。この動作は、開始されたシグマ・セッションに対応する１つ又は複数の所定のエンロールメント・プロトコルに基づいて実行することができる。認証情報をＩＤリクエスタに開示するプロセスは、エンロールメント・プロトコルを構成すると考えることができる。この関連で、ＩＤプロバイダ内の管理エンジン（又は他のセキュア・エレメント）（又は代替的には、ＩＤリクエスタ内の管理エンジン）が、認証情報の信憑性を保証する信頼できる機関の役割を果たすことができる。ＰＫＩ用語において、管理エンジンは、この場合、登録認定機関であると見なすことができる。

【0062】

暗号化された認証情報は、管理エンジンによって暗号解読され、その後、このエンジンは認証情報に基づいて第２のユーザＩＤを確立する（ブロック７５０）。暗号解読は、暗号化のために用いられた所定の鍵及び技法に基づいて実行され、その情報は、シグマ・セッション中にＩＤリクエスタに通知することができ、例えば、図１０に示される交換されるメッセージのうちの１つ又は複数において、ＭＫ鍵（マスター鍵）及びＳＫ鍵が送信される。

【0063】

第２のユーザＩＤは、ユーザを一意的に識別する高い確率を有する１つ又は複数の認証情報（先に言及された認証情報のいずれか、例えば、名前、口座番号などを含む）によって確立することができる。第２のユーザＩＤを確立するために実行される動作の一例は、以下のことを含む場合がある。
１．ユーザの認証情報を得る。
２．ユーザに対する正当性及び／又は妥当性を吟味する。例えば、それは登録認定機関のような信頼できる機関によって実行される。その際、ＩＤリクエスタの管理エンジンは、別のサービス・プロバイダからあらかじめ発行されたＩＤを利用して、正当性及び妥当性を得る。
３．ドメイン命名機関によって制御されるドメイン特有の認証情報又は他の属性（例えば、名前、番号、役割、特権）を関連付けるドメイン機関に認証情報を提示する。例えば、．ｃｏｍドメインは、インターネット属性及び命名機関（Ｉｎｔｅｒｎｅｔ Ａｔｔｒｉｂｕｔｅ ａｎｄ Ｎａｍｉｎｇ Ａｕｔｈｏｒｉｔｙ：ＩＡＮＡ）によって制御される。

【0064】

ドメイン機関は、例えば、証明書に署名することによって、又は関連するドメイン、例えば、ＩＤリクエスタのドメインによって制御されるデータベース内のエントリを作成することによって、第２のユーザＩＤに対応する１つ又は複数の認証情報を発行することができる。この例では、ＩＤプロバイダの管理エンジンがユーザに対するドメインの役割を果たすことができる。管理エンジンは、属性を適切にネゴシエートするために、他のドメイン（例えば、ＩＤリクエスタ）によって信頼されるので、人手が介入することなく、認証情報を無線で自動的に構成できるようになる。

【0065】

基本的に、このＩＤは、ユーザによって求められた加入又はサービスが、そのユーザに対して許可された、例えば、ユーザのモバイル・デバイス又は他のデバイス上で受信されることを許可されたという指示をＩＤプロバイダに与える。図１に示されるように、モバイル・デバイスは無線リンク又は他のタイプのリンクを通してＩＤプロバイダに結合される場合がある。別のエンティティ／ＩＤプロバイダによってユーザに対して既に確立されているＩＤに基づいて、ユーザに対してトランスペアレントに第２のユーザＩＤを確立することによって、他の人手に基づく方法と比べて、加入／サービスの受信を認証し、許可するプロセスが効率的にされる。

【0066】

図７のブロック７２０、７３０及び７４０の動作に対する代替形態として、図８の動作を実行することができる。これらの動作は、所定の鍵によって署名された公開鍵暗号化標準（ＰＫＣＳ）要求を構成すること（ブロック８２０）を含む。ＰＫＣＳ要求は、証明要求を構成するＰＣＫＳ１０標準に対応する。より具体的には、ＰＣＫＳ１０は、鍵の証明を要求するために証明機関に送信されるメッセージのフォーマットに対応する。その鍵は公開鍵又は秘密鍵とすることができ、後者の場合、モバイル・デバイス１０のユーザの秘密鍵に対応することができる。

【0067】

ＰＣＫＳ要求が構成されると、その要求は、エンハンスト・プライバシーＩＤ（Ｅｎｈａｎｃｅｄ Ｐｒｉｖａｃｙ Ｉｄｅｎｔｉｔｙ：ＥＰＩＤ）鍵を用いて暗号化又は署名することができる（ブロック８３０）。ＥＰＩＤは、匿名でＩＤの証明（又はグループ内のメンバーシップ）を与える暗号化プロトコルである。このプロトコルによれば、ＥＰＩＤを発行するエンティティは、データベース内にユーザの秘密鍵を記憶せず、ユーザの秘密鍵が漏れた場合には、ＥＰＩＤ鍵は取消可能である。

【0068】

より具体的には、ＥＰＩＤは高度な取消能力を有する直接匿名認証方式を利用し、その能力はユーザに対して高度な保護手段を提供する。他の方法とは異なり、ＥＰＩＤでは、署名者を特定するグループ署名を誰も公開することができない。更に、ＥＰＩＤは、ユーザのプライバシーを保護しながら、同時に、認証及び証明のために用いることができる。

【0069】

ＰＣＫＳ要求がＥＰＩＤ鍵を用いて暗号化されると、ＩＤリクエスタに送信される（ブロック８４０）。その要求は、ＯＴＡ接続又は異なる接続に沿って送信される場合がある。ＥＰＩＤによって提供される高度な保護のため、その要求の安全性は無傷のままである。その後、ＩＤリクエスタは、ブロック７５０と同様に、第２のユーザＩＤを確立することができる。

【0070】

図９は、ＯＴＡ・ＩＤプロビジョニングを実行するために、ＩＤリクエスタが電子デバイス内に位置するシステムの別の実施形態を示す。この実施形態では、ＩＤリクエスタ９１５は、ユーザの電子デバイス９１０内に位置し、例えば、電子デバイスはモバイル・デバイス、又は上記の他のデバイスのいずれかとすることができる。ＩＤリクエスタは、ＩＤ認証情報を得るために、更には、ＩＤプロバイダ９２０とともにインタラクティブに実行される他の動作のために、上記のＩＤリクエスタと同じように動作することができる。ＩＤプロバイダ及びＩＤリクエスタ／デバイスは、ＯＴＡ接続９３０を介して互いに通信することができる。

【0071】

別の実施形態によれば、電子デバイスは含まれず、ＩＤリクエスタは、ＩＤプロバイダによってあらかじめ確立されたＩＤに基づいてユーザのためのＩＤを確立する。そのような実施形態は、例えば、ＩＤリクエスタが店頭（ＰＯＳ）端末、チケット端末又は現金自動預払機、給油所ポンプの制御システム、事務所、建物又は家庭用のセキュリティ・システム、駐車場検証又は支払機、又はユーザ認証及びＩＤ確認を必要とする他のタイプのシステム又はデバイスである場合を含むことができる。

【0072】

別の実施形態は、上記の方法の動作を実行するためのコード部分を含むプログラムを記憶するコンピュータ可読媒体に対応する。第１のコンピュータ可読媒体はＩＤリクエスタ内に位置し、管理エンジン及びその関連する機構の動作を実行するためのコードを記憶することができる。第２のコンピュータ可読媒体は、先に説明されたようにＩＤプロバイダの動作を実行するコードを記憶するためにＩＤプロバイダ内に位置することができる。第３のコンピュータ可読媒体は、本明細書において説明されたように、サービスを要求し、及び／又は受信するための動作を実行するためにデバイス内に位置することができる。

【0073】

本明細書において「実施形態」を参照することは、その実施形態に関連して記述される特定の特徴、構造又は特性が本発明の少なくとも１つの実施形態に含まれることを意味する。本明細書内の種々の場所において、そのような語句が現れても、全てが同じ実施形態を指しているとは限らない。更に、任意の実施形態に関連して特定の特徴、構造又は特性が記述されるとき、他の実施形態に関連してそのような特徴、構造又は特性を達成することも当業者の理解の範囲内にあると考えられる。また、本明細書において説明されるいずれか１つの実施形態の特徴を１つ又は複数の他の実施形態の特徴と組み合わせて、更なる実施形態を形成することができる。

【0074】

更に、理解するのを容易にするために、特定の機能ブロックが別々のブロックとして示されている場合がある。しかしながら、これらの別々に図示されるブロックは、それらのブロックが本明細書において論じられるか、又は別の方法で提示される順序をなすものと必ずしも解釈されるべきではない。例えば、幾つかのブロックは別の順序で、同時に、などで実行できる場合がある。

【0075】

本発明は本明細書において幾つかの例示的な実施形態を参照しながら説明されてきたが、当業者は、本発明の原理の精神及び範囲内に入る数多くの他の変更形態及び実施形態を考案できることは理解されたい。より詳細には、本発明の精神から逸脱することなく、これまでの開示、図面及び添付の特許請求の範囲の中で、対象となる組み合わせの構成の構成部品及び／又は構成に関して合理的な変形及び変更が可能である。構成部品及び／又は構成に関する変形及び変更に加えて、代替の使用も当業者には明らかであろう。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】