(57)【要約】  セキュア通信プロトコルを使用して信頼を確立するためのシステム、方法、及び機械可読媒体について記載されており、この確立は、認証部を有するクライアント装置に向けられた通信を認証サーバにおいて生成し、分散型公開鍵基盤（ＰＫＩ）からの自己署名証明書の鍵を使用して、この第１の通信に署名し、通信基盤を使用して、クライアント装置のアプリとの第１のチャネルを確立し、署名を伴う第１の通信を第１のチャネルを介してアプリに送信し、信頼済みセキュア通信基盤を使用してクライアント装置の認証クライアントとの第２のチャネルを確立し、分散型ＰＫＩからの自己署名証明書の第２の鍵を第２のチャネルを介して認証クライアントに送信し、第１の通信をアプリから認証クライアントに提供し、認証クライアントが、第２の鍵を使用して、第１の鍵により第１の認証関連通信に対して生成された署名を検証することによって行われる。
2017528963.tif 000002
【特許請求の範囲】
【請求項１】
方法であって、
依拠当事者の代わりに認証サーバにおいて第１の認証関連通信を生成することであって、前記第１の認証関連通信は、１つ以上の認証部を有するクライアント装置に向けられたものである、生成することと、
分散型公開鍵基盤（ＰＫＩ）からの自己署名証明書の第１の鍵を使用して、前記第１の認証関連通信に署名することと、
信頼済みセキュア通信基盤を使用して前記クライアント装置の依拠当事者アプリとの第１のセキュア通信チャネルを確立することと、
前記署名を伴う前記第１の認証関連通信を、前記第１のセキュア通信チャネルを介して前記依拠当事者アプリに送信することと、
信頼済みセキュア通信基盤を使用して前記クライアント装置の認証クライアントとの第２のセキュア通信チャネルを確立することと、
前記分散型ＰＫＩからの前記自己署名証明書の第２の鍵を前記第２の通信チャネルを介して前記認証クライアントに送信することと、
前記第１の認証関連通信を前記依拠当事者アプリから前記認証クライアントに提供することと、
前記認証クライアントが、前記第２の鍵を使用して、前記第１の鍵により前記第１の認証関連通信に対して生成された前記署名を検証することと、を含む、方法。
【請求項２】
前記第１の鍵は、前記分散型ＰＫＩの秘密鍵を含み、前記第２の鍵は、対応する公開鍵を含む、請求項１に記載の方法。
【請求項３】
前記信頼済みセキュア通信基盤は、前記第１及び／又は第２のセキュア通信チャネルのためのセキュアなトランスポート層セキュリティ（ＴＬＳ）接続を確立するのに使用することができる信頼済み証明書を含む、請求項１に記載の方法。
【請求項４】
前記信頼済み証明書は、Ｘ．５０９証明書を含む、請求項３に記載の方法。
【請求項５】
前記認証クライアントが前記第１の認証関連通信に応答して第２の認証関連通信を生成することを更に含む、請求項１に記載の方法。
【請求項６】
前記第１の認証関連通信は、前記依拠当事者の代わりとして操作される認証サーバにおいて生成される認証リクエストを含み、前記第２の認証関連通信は、前記認証クライアントによって生成される認証応答を含む、請求項５に記載の方法。
【請求項７】
前記認証リクエストは、ランダムチャレンジと、前記クライアント装置の認証部と関連付けられた公開鍵を使用して前記ランダムチャレンジに対して生成される署名とを含む、請求項６に記載の方法。
【請求項８】
前記認証クライアントは、前記認証部と関連付けられた秘密鍵を使用して前記署名を検証する、請求項７に記載の方法。
【請求項９】
前記認証クライアントは、前記クライアント装置の前記認証部のうちの１つ以上を使用したユーザ認証の成功に応答して前記認証応答を生成する、請求項８に記載の方法。
【請求項１０】
前記クライアント装置の前記認証部は、指紋認証部を含む、請求項９に記載の方法。
【請求項１１】
前記第１の認証関連通信を前記依拠当事者アプリから前記認証クライアントに提供することは、前記依拠当事者アプリと前記認証クライアントとの間にプロセス間通信（ＩＰＣ）を実装することを更に含む、請求項１に記載の方法。
【請求項１２】
前記自己署名証明書の前記第２の鍵は、前記第２の通信チャネルを介して公開鍵ファイル内に送信される、請求項１に記載の方法。
【請求項１３】
認証を行うためのシステムであって、
１つ以上の認証部、認証クライアント、及び依拠当事者アプリを有する、クライアント装置と、
前記クライアント装置に向けられた第１の認証関連通信を生成する、依拠当事者の代わりに操作される認証サーバと、を備え、
前記認証サーバは、分散型公開鍵基盤（ＰＫＩ）からの自己署名証明書の第１の鍵を使用して、前記第１の認証関連通信に署名し、
前記認証サーバは、信頼済みセキュア通信基盤を使用して前記クライアント装置の依拠当事者アプリとの第１のセキュア通信チャネルを確立し、
前記認証サーバは、前記署名を伴う前記第１の認証関連通信を、前記第１のセキュア通信チャネルを介して前記依拠当事者アプリに送信し、
前記認証サーバは、信頼済みセキュア通信基盤を使用して前記クライアント装置の認証クライアントとの第２のセキュア通信チャネルを確立し、
前記認証サーバは、前記分散型ＰＫＩからの前記自己署名証明書の第２の鍵を前記第２の通信チャネルを介して、前記認証クライアントに送信し、
前記依拠当事者アプリは、前記第１の認証関連通信を前記認証クライアントに提供し、
前記認証クライアントが、前記第２の鍵を使用して、前記第１の鍵により前記第１の認証関連通信に対して生成された前記署名を検証する、システム。
【請求項１４】
前記第１の鍵は、前記分散型ＰＫＩの秘密鍵を含み、前記第２の鍵は、対応する公開鍵を含む、請求項１３に記載のシステム。
【請求項１５】
前記信頼済みセキュア通信基盤は、前記第１及び／又は第２のセキュア通信チャネルのためのセキュアなトランスポート層セキュリティ（ＴＬＳ）接続を確立するのに使用することができる信頼済み証明書を含む、請求項１３に記載のシステム。
【請求項１６】
前記信頼済み証明書は、Ｘ．５０９証明書を含む、請求項１５に記載のシステム。
【請求項１７】
前記認証クライアントが前記第１の認証関連通信に応答して第２の認証関連通信を生成することを更に含む、請求項１３に記載のシステム。
【請求項１８】
前記第１の認証関連通信は、前記依拠当事者の代わりとして操作される認証サーバにおいて生成される認証リクエストを含み、前記第２の認証関連通信は、前記認証クライアントによって生成される認証応答を含む、請求項１７に記載のシステム。
【請求項１９】
前記認証リクエストは、ランダムチャレンジと、前記クライアント装置の認証部と関連付けられた公開鍵を使用して前記ランダムチャレンジに対して生成される署名とを含む、請求項１８に記載のシステム。
【請求項２０】
前記認証クライアントは、前記認証部と関連付けられた秘密鍵を使用して前記署名を検証する、請求項１９に記載のシステム。
【請求項２１】
前記認証クライアントは、前記クライアント装置の前記認証部のうちの１つ以上を使用したユーザ認証の成功に応答して前記認証応答を生成する、請求項２０に記載のシステム。
【請求項２２】
前記クライアント装置の前記認証部は、指紋認証部を含む、請求項２１に記載のシステム。
【請求項２３】
前記第１の認証関連通信を前記依拠当事者アプリから前記認証クライアントに提供することは、前記依拠当事者アプリと前記認証クライアントとの間にプロセス間通信（ＩＰＣ）を実装することを更に含む、請求項１３に記載のシステム。
【請求項２４】
前記自己署名証明書の前記第２の鍵は、前記第２の通信チャネルを介して公開鍵ファイル内に送信される、請求項１３に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、データ処理システムの分野に関する。より具体的には、本発明は、セキュア送信プロトコルを使用して信頼を確立するためのシステム及び方法に関する。
【背景技術】
【０００２】
システムはまた、バイオメトリックセンサを使用してネットワーク上でセキュアなユーザ認証を提供するために設計されている。そのようなシステムにおいて、認証部、及び／又は他の認証データにより生成されたスコアは、遠隔サーバでユーザを認証するためにネットワークで送ることができる。例えば、特許出願第２０１１／００８２８０１号（「‘８０１出願」）は、強力な認証（例えば、アイデンティティ盗難やフィッシングに対する保護）、セキュアトランザクション（例えば、「ブラウザにおけるマルウェア」及びトランザクションについての「中間者」攻撃に対する保護）、並びにクライアント認証トークンの登録／管理（例えば、指紋リーダ、顔認識装置、スマートカード、トラステッドプラットフォームモジュールなど）を提供するネットワーク上のユーザ登録及び認証のためのフレームワークについて記載している。
【０００３】
本特許出願の譲受人は、‘８０１出願に記載された認証フレームワークに対する様々な改善を開発している。これらの改善のうちいくつかは、本件の譲受人に譲渡された以下の一群の米国特許出願（「同時係属出願」）に記載されている：第１３／７３０，７６１号、Ｑｕｅｒｙ  Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ  ｔｏ  Ｄｅｔｅｒｍｉｎｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃａｐａｂｉｌｉｔｉｅｓ；第１３／７３０，７７６号、Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ  ｆｏｒ  Ｅｆｆｉｃｉｅｎｔｌｙ  Ｅｎｒｏｌｌｉｎｇ，Ｒｅｇｉｓｔｅｒｉｎｇ，ａｎｄ  Ａｕｔｈｅｎｔｉｃａｔｉｎｇ  Ｗｉｔｈ  Ｍｕｌｔｉｐｌｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｄｅｖｉｃｅｓ；第１３／７３０，７８０号、Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ  ｆｏｒ  Ｐｒｏｃｅｓｓｉｎｇ  Ｒａｎｄｏｍ  Ｃｈａｌｌｅｎｇｅｓ  Ｗｉｔｈｉｎ  ａｎ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｆｒａｍｅｗｏｒｋ；第１３／７３０，７９１号、Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ  ｆｏｒ  Ｉｍｐｌｅｍｅｎｔｉｎｇ  Ｐｒｉｖａｃｙ  Ｃｌａｓｓｅｓ  Ｗｉｔｈｉｎ  ａｎ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｆｒａｍｅｗｏｒｋ；第１３／７３０，７９５号、Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ  ｆｏｒ  Ｉｍｐｌｅｍｅｎｔｉｎｇ  Ｔｒａｎｓａｃｔｉｏｎ  Ｓｉｇｎａｌｉｎｇ  Ｗｉｔｈｉｎ  ａｎ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｆｒａｍｅｗｏｒｋ；及び第１４／２１８，５０４号Ａｄｖａｎｃｅｄ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｔｅｃｈｎｉｑｕｅｓ  ａｎｄ  Ａｐｐｌｉｃａｔｉｏｎｓ（本明細書では以降「‘５０４出願」）。
【０００４】
簡潔に述べると、同時係属出願は、ユーザがクライアント装置上のバイオメトリック装置（例えば、指紋センサ）などの認証装置（又は認証部）に登録する認証技術を記載している。ユーザがバイオメトリック装置に登録されるとき、バイオメトリック参照データが、（例えば、指をスワイプする、写真をスナップする、声を録音することなどにより）捕捉される。ユーザは、その後、ネットワーク上で１つ以上のサーバ（例えば、同時係属中の出願で説明されているようにセキュアなトランザクションサービスが装備されたウェブサイト又は他の依拠当事者）に認証装置を登録して、その後、登録プロセス中に交換されるデータ（例えば、認証装置にプロビジョニングされる暗号鍵）を使用してそれらのサーバで認証することができる。認証されると、ユーザは、ウェブサイト又は他の依拠当事者と１つ以上のオンライントランザクションを実行することが許可される。同時係属出願に記載されているフレームワークでは、ユーザを固有に識別するために使用することができる指紋データ及び他のデータなどの機密情報は、ユーザのプライバシーを保護するためにユーザの認証装置上でローカルに保持され得る。‘５０４出願は、ほんの２〜３の例を挙げると、複合的な認証部を設計し、認証の保証レベルをインテリジェントに生成し、非侵襲型ユーザ検証を使用し、認証データを新しい認証装置に転送し、認証データをクライアントリスクデータによって増強し、認証ポリシーを適応的に適用し、かつトラストサークルを築くための技術を含む様々な追加の技術を記載している。
本発明のより良好な理解は、以下の図面と共に以下の詳細な説明から得ることができる。
【図面の簡単な説明】
【０００５】
【図１Ａ】セキュアな認証システムアーキテクチャの２つの異なる実施形態を図示している。
【図１Ｂ】セキュアな認証システムアーキテクチャの２つの異なる実施形態を図示している。
【図２】鍵を認証装置に登録することができる方法を示すトランザクション図である。
【図３】遠隔認証を示すトランザクション図を図示している。
【図４】依拠当事者による認証がどのように依拠当事者アプリの使用を必要とし得るかを図示している。
【図５】セキュア通信プロトコルを使用して信頼を確立することによって認証を行うためのシステムの一実施形態を図示している。
【図６】セキュア通信プロトコルを使用して信頼を確立することによって認証を行うための方法の一実施形態を図示している。
【図７】本明細書に記載されるクライアント及び／又はサーバを実装するための例示的なデータ処理アーキテクチャを図示している。
【図８】本明細書に記載されるクライアント及び／又はサーバを実装するための別の例示的なデータ処理アーキテクチャを図示している。
【発明を実施するための形態】
【０００６】
以下に説明するものは、高度な認証技術及び関連するアプリケーションを実行するための装置、方法及び機械可読媒体の実施形態である。説明を通して、説明の目的のために、多数の具体的な詳細が本発明の完全な理解を提供するために記載されている。しかしながら、本発明が、これらの具体的な詳細の一部がなくても実施され得ることは当業者にとって明らかであろう。他の例において、周知の構造及び装置は示されていないか、又は、本発明の基本原理を曖昧にすることを避けるためにブロック図の形態で示されている。
【０００７】
以下に説明する本発明の実施形態には、バイオメトリックモダリティ又はＰＩＮ入力などのユーザ検証機能を備えた認証装置が含まれる。これらの装置は、本明細書において「トークン」、「認証装置」、又は「認証部」と称される場合がある。特定の実施形態は、顔認識ハードウェア／ソフトウェア（例えば、ユーザの顔を認識してユーザの眼の動きを追跡するためのカメラ及び関連するソフトウェア）にフォーカスしており、いくつかの実施形態は、例えば、指紋センサ、音声認識ハードウェア／ソフトウェア（例えば、マイクロフォン及びユーザの音声を認識するための関連するソフトウェア）、及び、光学的認識機能（例えば、ユーザの網膜をスキャンするための光学スキャナ及び関連するソフトウェア）を含む追加のバイオメトリック装置を利用することができる。ユーザ検証機能は、ＰＩＮ入力のような、非バイオメトリックモダリティを含んでもよい。認証部は、暗号動作及び鍵記憶のためにトラスデッドプラットフォームモジュール（ＴＰＭ）、スマートカード及びセキュアエレメントのような装置を使用することがあり得る。
【０００８】
モバイルバイオメトリックの実装において、バイオメトリック装置は、依拠当事者から遠隔にあってもよい。本明細書では、「遠隔」という用語は、バイオメトリックセンサが通信可能に結合されているコンピュータのセキュリティ境界の一部ではない（例えば、依拠当事者コンピュータと同じ物理的筐体内に埋め込まれていない）ことを意味する。一例として、バイオメトリック装置は、ネットワーク（例えば、インターネット、無線ネットワークリンクなど）を介して又はＵＳＢポートなどの周辺入力を介して依拠当事者に結合することができる。これらの条件下では、その装置が依拠当事者（例えば、認証強度及び完全性保護の許容可能なレベルを提供するもの）によって認証されるものであるかどうか及び／又はハッカーがバイオメトリック装置を侵害したかどうか若しくは更には交換したかどうかを依拠当事者が知る方法はない可能性がある。バイオメトリック装置における信頼は、装置の特定の実装に依存する。
【０００９】
「ローカル」という用語は、ユーザが現金自動預け払い機（ＡＴＭ）又は店舗販売時点情報管理（ＰＯＳ）小売チェックアウトの位置などの特定の位置において個人がトランザクションを完了していることを意味するために本明細書において使用される。しかしながら、以下に説明するように、ユーザを認証するために用いられる認証技術は、遠隔サーバ及び／又は他のデータ処理装置とのネットワークを介した通信などの非位置要素を含むことができる。更に、具体的な実施形態が（ＡＴＭや小売店など）本明細書において記載されるが、本発明の基礎原理は、トランザクションがエンドユーザによってローカルに開始される任意のシステムのコンテキスト内で実装されてもよいことに留意すべきである。
【００１０】
「依拠当事者」という用語は、単にユーザのトランザクションを実行しようとしているエンティティ（例えば、ユーザトランザクションを実行するウェブサイト又はオンラインサービス）のみならず、本明細書に記載された基礎となる認証技術を実行することができるそのエンティティの代わりに実装されるセキュアトランザクションサーバ（「ａｕ」と称されることがある）を指すために本明細書において使用される場合もある。セキュアトランザクションサーバは、所有される及び／又は依拠当事者の制御下にあってもよく、又は、事業構成の一部として依拠当事者に対してセキュアトランザクションサービスを提供する第三者の制御下にあってもよい。
【００１１】
「サーバ」という用語は、クライアントからネットワークを介してリクエストを受信し、応答として１つ以上の操作を実行し、クライアントに通常は操作の結果を含む応答を送信するハードウェアプラットフォーム上で（又は複数のハードウェアプラットフォームにわたって）実行されるソフトウェアを指すために本明細書において使用される。サーバは、クライアントに対してネットワーク「サービス」を提供する又は提供するのに役立つように、クライアントのリクエストに応答する。重要なことは、サーバが単一のコンピュータ（例えば、サーバソフトウェアを実行する単一のハードウェア装置）に限定されるものではなく、実際には、潜在的に複数の地理的位置における複数のハードウェアプラットフォームにまたがってもよいということである。
【００１２】
例示的なシステムアーキテクチャ及びトランザクション
図１Ａ及び図１Ｂは、認証装置の登録及びユーザ認証に関して、クライアント側及びサーバ側の構成要素を含むシステムアーキテクチャの２つの実施形態を例示する。図１Ａに示される実施形態は、ウェブサイトと通信するためのウェブブラウザプラグインベースのアーキテクチャを使用する一方で、図１Ｂで示される実施形態は、ブラウザを必要としない。ユーザを認証装置に登録すること、認証装置をセキュアなサーバに登録すること、及びユーザを検証することなどの、本明細書に記載の様々な技術は、これらのシステムアーキテクチャのうちのどちらにも実装され得る。このため、図１Ａに示されるアーキテクチャは、以下に説明される実施形態のうちのいくつかの動作を例証するために使用されているものの、同じ基本原理は、図１Ｂに示されるシステムに容易に実装され得る（例えば、サーバ１３０とクライアント上のセキュアトランザクションサービス１０１との間の通信手段としてのブラウザプラグイン１０５を削除することによって）。
【００１３】
まず図１Ａを参照すると、図示されている実施形態は、エンドユーザを登録及び検証するための１つ以上の認証装置１１０〜１１２（当該技術分野では、「トークン」又は「認証部」と称される場合もある）を備えたクライアント１００を含む。上述したように、認証装置１１０〜１１２は、指紋センサ、音声認識ハードウェア／ソフトウェア（例えば、ユーザの音声を認識するためのマイクロフォン及び関連するソフトウェア）、顔認識ハードウェア／ソフトウェア（例えば、ユーザの顔を認識するためのカメラ及び関連するソフトウェア）、及び光学認識機能（ユーザの網膜をスキャンするための光スキャナ及び関連するソフトウェア）などのバイオメトリック装置、並びにＰＩＮ検証などの非バイオメトリック様相のサポートを含むことができる。認証装置は、トラステッドプラットフォームモジュール（ＴＰＭ）、スマートカード、又はセキュアな要素を暗号操作及び鍵記憶のために使用してもよい。
【００１４】
認証装置１１０〜１１２は、セキュアトランザクションサービス１０１によって露出されたインターフェース１０２（例えば、アプリケーションプログラミングインターフェース又はＡＰＩ）を介してクライアントに通信可能に接続されている。セキュアトランザクションサービス１０１は、ネットワークを介して１つ以上のセキュアトランザクションサーバ１３２〜１３３と通信を行い、かつウェブブラウザ１０４のコンテキスト内で実行されるセキュアトランザクションプラグイン１０５とインターフェースするためのセキュアアプリケーションである。図示されたように、インターフェース１０２はまた、装置識別コードなどの認証装置１１０〜１１２のそれぞれに関連する情報、ユーザ識別コード、認証装置により保護されたユーザ登録データ（例えば、スキャンされた指紋又は他のバイオメトリックデータ）、及び本明細書に記載されたセキュア認証技術を実行するために使用される認証装置によりラップされた鍵を記憶するクライアント１００のセキュア記憶装置１２０に対するセキュアアクセス権を提供することができる。例えば、以下に詳細に説明するように、固有の鍵は、認証装置のそれぞれに記憶され、インターネットなどのネットワークを介してサーバ１３０と通信するときに使用することができる。
【００１５】
後述するように、特定の種類のネットワークトランザクションは、ウェブサイト１３１又は他のサーバとのＨＴＴＰ又はＨＴＴＰＳトランザクションなどのセキュアトランザクションプラグイン１０５によって、サポートされる。一実施形態において、セキュアトランザクションプラグインは、セキュアエンタープライズ又はウェブデスティネーション１３０内のウェブサーバ１３１（以下では単に「サーバ１３０」と称されることもある）によってウェブページのＨＴＭＬコード内に挿入された特定のＨＴＭＬタグに応答して開始される。そのようなタグを検出することに応答して、セキュアトランザクションプラグイン１０５は、処理のために、セキュアトランザクションサービス１０１に、トランザクションを転送することができる。更に、特定の種類のトランザクション（例えば、セキュア鍵交換などの）について、セキュアトランザクションサービス１０１は、オンプレミストランザクションサーバ１３２（すなわち、ウェブサイトと同じ位置に配置された）又はオフプレミストランザクションサーバ１３３との直接の通信チャンネルを開くことができる。
【００１６】
セキュアトランザクションサーバ１３２〜１３３は、ユーザデータ、認証装置データ、鍵、及び、後述するセキュア認証トランザクションをサポートするために必要な他のセキュア情報を記憶するためにセキュアトランザクションデータベース１２０に結合される。しかしながら、本発明の基本原理は、図１Ａに示されるセキュアエンタープライズ又はウェブデスティネーション１３０内の論理的な構成要素の分離を必要としないことに留意すべきである。例えば、ウェブサイト１３１及びセキュアトランザクションサーバ１３２〜１３３は、単一の物理サーバ又は他の物理サーバ内に実装されてもよい。更に、ウェブサイト１３１及びトランザクションサーバ１３２〜１３３は、以下に説明する機能を実行するための１つ以上のサーバ上で実行される統合されたソフトウェアモジュール内に実装されてもよい。
【００１７】
上述したように、本発明の基本原理は、図１Ａに示されるブラウザベースアーキテクチャに限定されるものではない。図１Ｂは、スタンドアロンアプリケーション１５４がネットワークを介してユーザを認証するためにセキュアトランザクションサービス１０１によって提供される機能を利用する代替の実施形態を示している。一実施形態において、アプリケーション１５４は、以下に詳細に説明したユーザ／クライアント認証技術を実行するためのセキュアトランザクションサーバ１３２〜１３３に依存する１つ以上のネットワークサービス１５１との通信セッションを確立するように設計されている。
【００１８】
図１Ａ及び図１Ｂに示された実施形態のどちらにおいても、セキュアトランザクションサーバ１３２〜１３３は、次いでセキュアトランザクションサービス１０１に対してセキュアに伝送され、かつセキュア記憶装置１２０内の認証装置に記憶される鍵を生成することができる。更に、セキュアトランザクションサーバ１３２〜１３３は、サーバ側のセキュアトランザクションデータベース１２０を管理する。
【００１９】
認証装置を遠隔で登録し、依拠当事者により認証を行うことと関連するある特定の基本原理は、図２〜５に関連して記載されており、セキュアな通信プロトコルを使用して信頼を確立するための本発明の実施形態の詳細な説明がそれに続いている。
【００２０】
図２は、クライアントの認証装置（図１Ａ〜Ｂのクライアント１００の装置１１０〜１１２など）を登録するための一連のトランザクションを図示している。簡略化するために、セキュアトランザクションサービス１０１及びインターフェース１０２は、認証クライアント２０１として一緒に組み合わされ、セキュアトランザクションサーバ１３２〜１３３を含むセキュアエンタープライズ又はウェブデスティネーション１３０は、依拠当事者２０２として表されている。
【００２１】
認証部（例えば、指紋認証部、音声認証部など）の登録の際、認証部と関連付けられた鍵が、認証クライアント２０１と依拠当事者２０２との間で共有される。図１Ａ〜Ｂを再度参照すると、この鍵は、クライアント１００のセキュア記憶装置１２０及びセキュアトランザクションサーバ１３２〜１３３によって使用されるセキュアトランザクションデータベース１２０内に記憶され得る。一実施形態において、鍵は、セキュアトランザクションサーバ１３２〜１３３のいずれかによって生成された対称鍵である。しかしながら、以下に説明される他の実施形態では、非対称鍵が使用される。本実施形態では、公開鍵／秘密鍵の対は、セキュアトランザクションサーバ１３２〜１３３によって生成され得る。次いで、公開鍵はセキュアトランザクションサーバ１３２〜１３３によって記憶され得、関連する秘密鍵は、クライアントのセキュア記憶装置１２０に記憶され得る。代替的な実施形態では、鍵（複数可）は、（例えば、セキュアトランザクションサーバ１３２〜１３３ではなく認証装置又は認証装置インターフェースによって）クライアント１００で生成されてもよい。本発明の基本原理は、任意の特定の種類の鍵又は鍵の生成方法に限定されるものではない。
【００２２】
一実施形態では、セキュアな鍵プロビジョニングプロトコルが、セキュア通信チャネルを介して鍵をクライアントと共有するのに用いられる。鍵プロビジョニングプロトコルの一例は、動的対称鍵プロビジョニングプロトコル（ＤＳＫＰＰ）である（例えば、コメントリクエスト（ＲＦＣ）６０６３を参照されたい）。しかしながら、本発明の基本原理は、いかなる特定の鍵プロビジョニングプロトコルにも限定されるものではない。１つの特定の実施形態では、クライアントは、公開鍵／秘密鍵の対を生成し、公開鍵をサーバに送信し、これが、証明鍵によって証明され得る。
【００２３】
図２に示される具体的な詳細を参照すると、登録プロセスを開始するために、依拠当事者２０２は、装置登録時に認証クライアント２０１によって提示する必要のあるランダム生成チャレンジ（例えば、暗号化ナンス）を生成する。ランダムチャレンジは、限られた期間について有効であり得る。それに応答して、認証クライアント２０１は、依拠当事者２０２との帯域外セキュア接続（例えば、帯域外トランザクション）を開始し、鍵プロビジョニングプロトコル（例えば、上述のＤＳＫＰＰプロトコル）を使用して、依拠当事者２０２と通信する。セキュア接続を開始するために、認証クライアント２０１は、ランダムチャレンジを依拠当事者２０２に戻すことができる（ランダムチャレンジに対して生成された署名を伴い得る）。加えて、認証クライアント２０１は、登録されるべきユーザのアイデンティティ（例えば、ユーザＩＤ又は他のコード）及び認証装置（複数可）のアイデンティティ（例えば、登録されている認証装置（複数可）の種類を固有に識別する認証証明ＩＤ（ＡＡＩＤ）を使用して）を送信し得る。
【００２４】
依拠当事者は、ユーザ名又はＩＤコード（例えば、ユーザアカウントデータベース内の）によりユーザの位置を特定し、ランダムチャレンジを検証し（例えば、署名を使用して、又はランダムチャレンジと送信されたものとを単純に比較することで）、認証装置の認証コード（例えば、ＡＡＩＤ）が送信された場合にはそれを検証し、セキュアトランザクションデータベース（例えば、図１Ａ〜Ｂのデータベース１２０）にユーザ及び認証装置（複数可）に関する新たなエントリを作成する。一実施形態において、依拠当事者は、依拠当事者が認証を許容する認証装置のデータベースを維持する。依拠当事者は、ＡＡＩＤ（又は他の認証装置（複数可）のコード）をこのデータベースに照会し、登録されている認証装置（複数可）の認証が許容できるかどうかを判定することができる。許容できる場合、登録プロセスへと進むことになる。
【００２５】
一実施形態において、依拠当事者２０２は、登録されているそれぞれの認証装置に対して、認証鍵を生成する。依拠当事者は、鍵をセキュアデータベースに書き込み、鍵プロビジョニングプロトコルを使用して鍵を認証クライアント２０１へと送り返す。完了すると、認証装置及び依拠当事者２０２は、対称鍵が使用された場合には同じ鍵を共有し、非対称鍵が使用された場合には異なる鍵を共有する。例えば、非対称鍵が使用された場合には、依拠当事者２０２は、公開鍵を記憶し、秘密鍵を認証クライアント２０１に提供してもよい。依拠当事者２０２から秘密鍵を受け取ると、認証クライアント２０１は、この鍵を認証装置にプロビジョニングする（認証装置と関連付けられたセキュア記憶装置内にそれを記憶する）。次いで、（以下に記載されるように）ユーザの認証時にこの鍵を使用することができる。代替的な実施形態では、鍵（複数可）は、認証クライアント２０１によって生成され、鍵プロビジョニングプロトコルを使用して、鍵（複数可）が依拠当事者２０２に提供される。いずれの場合でも、プロビジョニングが完了すると、認証クライアント２０１及び依拠当事者２０２はそれぞれが鍵を有し、認証クライアント２０１が、依拠当事者に完了を通知する。
【００２６】
図３は、登録された認証装置によるユーザ認証のための一連のトランザクションを図示している。装置の登録が完了すると（図２に記載されるように）、依拠当事者２０１は、クライアント上のローカル認証装置によって生成された認証応答（「トークン」と称されることもある）を、有効な認証応答として受け入れる。
【００２７】
図３に示される具体的な詳細を参照すると、認証を要求する依拠当事者２０２とのトランザクションをユーザが開始すること（例えば、依拠当事者のウェブサイトから支払いを開始する、プライベートのユーザアカウントデータにアクセスするなど）に応じて、依拠当事者２０２は、ランダムチャレンジ（例えば、暗号化ナンス）を含む認証リクエストを生成する。一実施形態において、ランダムチャレンジは、それと関連付けられた制限時間を有する（例えば、指定された期間について有効である）。依拠当事者はまた、認証クライアント２０１が認証に使用することになる認証部を識別することができる。上述のように、依拠当事者は、クライアント上で利用可能なそれぞれの認証装置を登録することができ、登録されたそれぞれの認証部に対する公開鍵を記憶する。このため、使用されることになる認証部を識別するために、認証部の公開鍵を使用してもよく、又は認証部ＩＤ（例えば、ＡＡＩＤ）を使用してもよい。あるいは、クライアントに認証オプションの一覧を提供することもでき、ユーザがそこから選択してもよい。
【００２８】
認証リクエストの受信に応答して、ユーザには、認証をリクエストするグラフィカルユーザインターフェース（ＧＵＩ）が（例えば、ウェブページ又は認証アプリケーション／アプリのＧＵＩの形態で）提示され得る。次いで、ユーザが認証を行う（例えば、指紋リーダ上で指をスワイプするなど）。これに応じて、認証クライアント２０１は、認証部と関連付けられた秘密鍵を用いてランダムチャレンジに対する署名を含む認証応答を生成する。これは、認証応答にユーザＩＤコードなどの他の関連デーも含む場合がある。
【００２９】
認証応答を受信すると、依拠当事者は、ランダムチャレンジに対する署名を検証し（例えば、認証部と関連付けられた公開鍵を使用して）、ユーザのアイデンティティを確認する。図示されるように、認証が完了すると、ユーザは、依拠当事者とのセキュアトランザクションに入ることが許される。
【００３０】
図２〜３に図示されるトランザクションのいずれか又は全てに関して、トランスポート層セキュリティ（ＴＬＳ）又はセキュアソケット層（ＳＳＬ）などのセキュア通信プロトコルを使用して、依拠当事者２０１と認証クライアント２０２との間のセキュア接続を確立してもよい。
【００３１】
セキュア送信プロトコルを使用して信頼を確立するためのシステム及び方法
上述のように、遠隔認証を使用するある特定の実装形態では、依拠当事者と認証クライアントとの間でデータをセキュアに交換するためにＴＬＳ又はＳＳＬなどのセキュア通信プロトコルが使用され得る。簡単に述べると、ＴＬＳ及びＳＳＬは、通常はセキュアでない通信チャネル（例えば、インターネット）上でセキュアな通信を提供する暗号化プロトコルである。これらは、対称鍵を交換するための非対称暗号を実装するＸ．５０９証明書を使用している。次いで、この対称鍵は、当事者間でデータチャネルを暗号化するための通信セッション中に使用される。本詳細な説明の残りの部分ではＴＬＳの使用に焦点を当てることになるが、本発明の基本原理は、ＳＳＬなどの他の暗号化プロトコルを使用して実装されてもよい。
【００３２】
一実施形態において、ＴＬＳは、依拠当事者と認証クライアントとの間の通信チャネルをセキュアにし、送信者のアイデンティティを検証するために使用される。すなわち、Ｘ．５０９証明書によりサポートされる非対称暗号を使用することで、一方の当事者（例えば、認証クライアント）は、相手側（例えば、依拠当事者）のアイデンティティを検証する能力を有し、逆もまた同様である。相手側のアイデンティティは、コード又は名称に埋め込まれていてもよく、このコード又は名称は、依拠当事者を識別するか（例えば、「ＲＰＮＡＭＥ」）、又は認証クライアント若しくは依拠当事者との通信チャネルを確立するのに使用されるクライアント側の特定のアプリケーションを識別する（例えば、「ＡｐｐＩＤ」）。認証クライアントと依拠当事者との間に直接的なチャネルが存在する場合（上述の例のように）、データは典型的にインターネットを介して送信され、かつＴＬＳが常に利用可能であるため、ＴＬＳの使用はこの目的を十分に果たす。
【００３３】
しかしながら、ｉＯＳ（商標）、Ａｎｄｒｏｉｄ（商標）、及び近距離無線通信（ＮＦＣ）トランザクションなどのある特定のコンピューティング装置プラットフォームでは、このＴＬＳの前提は適用されない。図４に概して示されるように、これらのプラットフォームでは、依拠当事者アプリ４１０などの第三者コードが、依拠当事者４０２と認証クライアント４０１との間の全ての通信を管理することが予測される。したがって、依拠当事者アプリ４１０は、本質的に、依拠当事者４０２と認証クライアント４０１との間の中間者のように機能する。更に、認証クライアント４０１は、依拠当事者アプリ４１０によって確立されたＴＬＳ接続の有効性に関する情報を有さない。（示されるように）ＩＰＣ機構を使用してこの判定を行い、認証リクエストを受け渡すことに関して、単純に第三者コードに依拠しなければならない。これらのＩＰＣ機構は、送信するアプリの識別コード（例えば、「バンドルＩＤ」）へのアクセスを有するが、バンドルＩＤを使用して送信者／受信者のアイデンティティ（例えば、ＲＰＮＡＭＥ、ＡｐｐＩＤ）を検証することに関しては、オペレーティングシステムと、依拠当事者アプリを配布しているアプリストアによって実装されている点検プロセスの管理に依拠するところが大きい。
【００３４】
ＮＦＣでは、この状況は更に悪いが、これは、送信機構に付随するバンドルＩＤなどの識別コードがないためである。ＮＦＣは、一般的な多目的インターネットメール拡張（ＭＩＭＥ）ハンドラによって扱われる。認証クライアント４０１は、主張されている識別コード（例えば、ＲＰＮＡＭＥ）がどのようなものであっても正しく、認証リクエストが有効なソースから来ていると見なさざるを得ない。
【００３５】
より具体的には、ｉＯＳ装置では、認証クライアント４０１と通信しているアプリ４１０は、多要素認証クライアントのＡｐｐＤｅｌｅｇａｔｅコードでｏｐｅｎＵＲＬ（）呼び出しのｓｏｕｒｃｅＡｐｐｌｉｃａｔｉｏｎパラメータを用いて判定される：−（ＢＯＯＬ）ａｐｐｌｉｃａｔｉｏｎ：（ＵＩＡｐｐｌｉｃａｔｉｏｎ  *）ａｐｐｌｉｃａｔｉｏｎ  ｏｐｅｎＵＲＬ：（ＮＳＵＲＬ  *）ｕｒｌ  ｓｏｕｒｃｅＡｐｐｌｉｃａｔｉｏｎ：（ＮＳＳｔｒｉｎｇ  *）ｓｏｕｒｃｅＡｐｐｌｉｃａｔｉｏｎ  ａｎｎｏｔａｔｉｏｎ：（ｉｄ）ａｎｎｏｔａｔｉｏｎ
【００３６】
この例では、ｓｏｕｒｃｅＡｐｐｌｉｃａｔｉｏｎは、呼び出しアプリのバンドルＩＤを含んでいる。バンドルＩＤは、Ａｐｐｌｅ（商標）データベースにおいてアプリを特定する、呼び出しアプリのｐｌｉｓｔ  ｍａｎｉｆｅｓｔ内の固有のストリングである。バンドルＩＤは、その会社の基本ＵＲＬを逆の表記で（例えば、ｃｏｍ．ｐａｙｐａｌ．ａｐｐ）使用して部分的に構築されることが推奨されている。そのため、Ａｐｐｌｅは、そのアプリが他のアプリケーションになりすまそうとしないように、このストリングを点検するものと考えられる。
【００３７】
Ａｎｄｒｏｉｄ装置については、現在のトランザクションを処理されている多要素認証プロセスに送信した依拠当事者プロセスに割り当てたれたＬｉｎｕｘ  ｕｉｄを返す、例えば以下のｇｅｔＣａｌｌｉｎｇＵｉｄ（）が、まずシステムＢｉｎｄｅｒから呼び出される：
ｉｎｔ  ｃａｌｌｅｒＵＩｄ＝Ｂｉｎｄｅｒ．ｇｅｔＣａｌｌｉｎｇＵｉｄ（）；；
【００３８】
アプリは、次いで、システムＰａｃｋａｇｅＭａｎａｇｅｒからそのユーザのＩＤと関連付けられているパッケージを取り出す。パッケージは、依拠当事者の基本ＵＲＬを構成要素として用いるが、逆の表記で命名されている（例えば、「ｃｏｍ．ｆｉｄｏ．ａｎｄｒｏｉｄ．ｓａｍｐｌｅ．ａｐｐ．ｐａｙｐａｌ」）。例えば、
Ｓｔｒｉｎｇ  ｐａｃｋａｇｅＮａｍｅｓ［］＝ｍＰａｃｋａｇｅＭａｎａｇｅｒ．ｇｅｔＰａｃｋａｇｅｓＦｏｒＵｉｄ（ｃａｌｌｅｒＵＩｄ）；；
【００３９】
ＮＦＣでは、相手側の識別子（例えば、ＲＰＮＡＭＥ又はＡｐｐＩＤ）にマッピングすることができる、信頼性のある情報の断片は存在しない。ＡｎｄｒｏｉｄにおけるＮＦＣでは、リクエストは、多目的インターネットメール拡張（ＭＩＭＥ）ハンドラを介して入来し、呼び出し側を特定することはできない。したがって、リクエストに含まれているいずれの識別子も、有効である場合もそうでない場合もある。
【００４０】
本発明の一実施形態は、信頼済み証明書を用いて認証リクエスト及び発行元識別子に署名することによって、これらの制限に対処する。携帯型装置のルート証明書ストアに対して検証され得るウェブサーバからのＳＳＬ  Ｘ．５０９証明書は、一実施形態において採用される１つのオプションである。しかしながら、依拠当事者の認証サーバは、鍵へのアクセスを有さない場合がある。特に認証サーバ用に新たなＸ．５０９証明書を生成することは、もう１つのオプションであるが、これは、更に別のＸ．５０９証明書を管理するための追加オーバーヘッドを意味する。
【００４１】
この問題を回避するために、図５に示される本発明の一実施形態は、分散型公開鍵基盤（ＰＫＩ）からの自己署名証明書を使用して、依拠当事者５０２の認証サーバ５２０からの認証リクエスト及び対応する発行元識別子（例えば、「ＲＰＮＡＭＥ」識別子）に署名する。具体的には、一実施形態において、自己署名証明書は、秘密鍵５２２と、認証サーバ５２０の公開鍵ファイル５２５に記憶されている１つ以上の公開鍵とから構成される。Ｘ．５０９証明書とは異なり、これらの自己署名証明書は、それらと信頼済みルート証明書とをつなぐ鎖が存在しないため、それら自体によって信頼済みとはならない。
【００４２】
一実施形態において、信頼を確立するために、ウェブサーバの公開鍵ファイル５２５に記憶されている公開鍵は、信頼済み証明書５２６（例えば、ＴＬＳ接続を確立するために使用される既存のＸ．５０９信頼済み証明書など）を用いて確立されたセキュア通信チャネルを介してクライアント装置５００（例えば、携帯電話）の認証クライアント５３０へと送信される。ＴＬＳの使用は、公開鍵ファイル５２５内の脆弱な自己署名公開鍵が、正しい所有者から得られることを確実にするが、これは、ウェブサーバからインターネットを介してそれらを送信するのに使用された信頼済み証明書／鍵５２６を、ルート証明書ストア（Ｘ．５０９又は他の既知の標準規格が使用される場合）に対して検証することができるためである。ファイル内のこれらの自己署名公開鍵５２６は、次いで、暗黙のうちに信頼され、発行元識別子（例えば、ＲＰＮＡＭＥ）を含む認証リクエスト５２３を検証するために使用することができる。
【００４３】
認証リクエスト５２３は、図３に関して上述されたものと同じ様式かつ同じ条件下で、認証サーバ５２０によって生成され得る。例えば、認証サーバ５２０は、ランダムチャレンジを生成し、使用されるべきクライアント側の認証部を（例えば、認証部に登録されている公開鍵で）識別することができる。ランダムチャレンジ及び認証部ＩＤ情報は、認証リクエスト５２３にパッケージングされてもよい。
【００４４】
追加として、一実施形態では、認証リクエスト５２３は、分散型ＰＫＩの秘密鍵５２２を用いて署名される。上述のように、一実施形態では、秘密鍵５２２は、ファイル５２５内の公開鍵に対応する。例えば、秘密鍵５２２によって生成された任意の署名を、公開鍵のうちの１つを用いて検証することができる。
【００４５】
ここでも、信頼を確立するために、認証サーバ５２０において秘密鍵５２２を用いて署名された認証リクエスト５２３は、信頼済み証明書５２１（例えば、ＴＬＳ接続を確立するために使用される既存のＸ．５０９の信頼済み証明書など）を用いて確立されたセキュア通信チャネルを介してクライアント装置５００の依拠当事者アプリ５１０へと送信される。一実施形態において、信頼済み証明書５２１は、認証クライアント５３０とのＴＬＳチャネルを確立するために使用した信頼済み証明書５２６と同じである。秘密鍵により署名された認証リクエスト５２３は、次いで、発行元識別子（例えば、依拠当事者を識別するためのＲＰＮＡＭＥ）と共に、ＴＬＳチャネルを使用して、依拠当事者アプリ５１０へと送信される。
【００４６】
一実施形態において、依拠当事者アプリ５１０は、基本的な秘密鍵により署名された認証リクエストを抽出し（すなわち、ＴＬＳデータをストリップし）、クライアント装置５００の認証クライアント５３０にそれを提供する。依拠当事者アプリ５１０は、既知のプロセス間通信（ＩＰＣ）機構を用いて認証クライアント５３０と通信してもよい。しかしながら、本発明の基本原理は、クライアント装置５００において情報を交換するためのいずれの特定の通信機構にも限定されない。
【００４７】
秘密鍵により署名された認証リクエスト５２３を受信すると、認証クライアント５３０は、公開鍵ファイルからの公開鍵を使用して署名を検証する。署名が有効である場合、クライアントは、上述のように認証応答を生成する。例えば、クライアントは、ユーザによる認証の成功に応答して、認証部の秘密鍵を使用して、認証リクエスト５２３に含まれているランダムチャレンジに対する署名を生成し、結果として生じる認証応答を認証サーバ５２０に送信し得る（例えば、直接又は依拠当事者アプリ５１０を介してのいずれかで）。認証サーバ５２０が対応する公開認証部鍵を用いて署名を検証すると、ユーザは、依拠当事者５０２に認証され、所望されるトランザクションを完了させることが認められる。
【００４８】
本明細書に記載される技法を用いることで、認証リクエスト５２３及び発行元識別子（例えば、ＲＰＮＡＭＥ）は、集中型ＳＳＬ  Ｘ．５０９鍵によって暗号化された状態で検証され、同時に、分散型ＰＫＩにより得られる柔軟性と最小限の管理オーバーヘッドが保持される。証明書を含むファイルがある特定のウェブサーバに位置するという事実を用いることにより、暗黙のうちに自己署名証明書の有効性を信頼することは、いくつかの危険性を有する。ウェブサーバ上のこのファイルを改変する能力がある者であれば、公開鍵を変更することができる。しかしながら、このファイルへのアクセスがＸ．５０９証明書を管理する能力と同程度に注意深く保護されている限りは、両方の解決法によって与えられる信頼も、同程度となるはずである。
【００４９】
本発明の一実施形態による方法が図６に示されている。本方法は、図５に示されているアーキテクチャを用いて実装することができるが、任意の特定のアーキテクチャに限定されるものではない。
【００５０】
６０１において、第１の認証関連通信が、依拠当事者の代わりに認証サーバで生成される。一実施形態において、第１の認証関連通信は、（例えば、ランダムチャレンジ、認証部ＩＤなどを含む）上述の認証リクエスト５２３を含む。
【００５１】
６０２において、第１の認証関連通信は、分散型公開鍵基盤（ＰＫＩ）からの自己署名証明書の第１の鍵を使用して署名される。一実施形態において、第１の鍵は、上述の秘密鍵５２２を含む。
【００５２】
６０３において、既存の信頼済み通信基盤を用いてクライアント装置の依拠当事者アプリとの第１のセキュアチャネルが確立される。一実施形態では、既存の信頼済み通信基盤を用いることは、依拠当事者とのセキュアなトランスポート層セキュリティ（ＴＬＳ）チャネルを確立するために信頼済みＸ．５０９証明書を用いることを含む。
【００５３】
６０４において、第１の認証関連通信が、第１のセキュア通信チャネルを介して依拠当事者アプリに送信される。上述のように、一実施形態では、発行元識別子（例えば、ＲＰＮＡＭＥ）がこの通信と共に提供される。
【００５４】
６０５において、既存の信頼済み通信基盤を使用して、クライアント装置上の認証クライアントとの第２のセキュア通信チャネルが確立される。上述のように、一実施形態では、既存の信頼済み通信基盤を用いることは、依拠当事者とのセキュアなＴＬＳチャネルを確立するために信頼済みＸ．５０９証明書を用いることを含む。
【００５５】
６０６において、分散型ＰＫＩからの自己署名証明書の第２の鍵が、第２のセキュア通信チャネルを介して認証クライアントに送信される。一実施形態では、第２の鍵は、分散型ＰＫＩからの自己署名証明書と関連付けられた公開鍵を含む。１つ以上の追加の鍵が、（上述のように）公開鍵ファイル５２６により提供されてもよい。
【００５６】
６０７において、署名を伴う第１の認証関連通信が、依拠当事者アプリから認証クライアントに提供される。一実施形態では、これは、クライアント装置上の既存のプロセス間通信（ＩＰＣ）に従って行われる。
【００５７】
６０８において、認証クライアントは、第２の鍵を用いて、第１の鍵により生成された署名を検証する。検証が成功すると、認証クライアントは、第１の認証関連通信に応答して第２の認証関連通信を生成する。例えば、上述のように、第１の認証関連通信が認証リクエストを含む場合、第２の認証関連通信は、認証応答を含み得る。応答を生成するために、認証クライアントは、クライアント装置で認証を行うように（例えば、指をスワイプする、音声を記録する、コードを入力するなど）ユーザにリクエストし得る。認証が成功すると、認証クライアントは、認証リクエストと共に提供されるランダムチャレンジなどの他の検証可能情報と併せて、認証が成功したことの指示を送信し得る。認証サーバが第２の認証関連通信を受信すると、ユーザは、依拠当事者により認証され、依拠当事者とのトランザクションに入ることが認められ得る。
【００５８】
例示的なデータ処理装置
図１１は、本発明のいくつかの実施形態において使用することができる例示的なクライアント及びサーバを図示するブロック図である。図１１は、コンピュータシステムの様々な構成要素を図示しているが、そのような詳細は本発明に適切でないため、構成要素を相互接続する任意の特定のアーキテクチャ又は方法を表すことを意図するものではないことを理解すべきである。より少ない構成要素又は複数の構成要素を有する他のコンピュータシステムもまた、本発明によって使用可能であることが理解されるであろう。
【００５９】
図７に示されるように、データ処理システムの形態であるコンピュータシステム７００は、処理システム７２０に結合されているバス７５０と、電源７２５と、メモリ７３０と、不揮発性メモリ７４０（例えば、ハードドライブ、フラッシュメモリ、相変化メモリ（ＰＣＭ）など）とを含む。バス７５０は、当該技術分野において周知であるように、様々なブリッジ、コントローラ及び／又はアダプタを介して互いに接続され得る。処理システム７２０は、メモリ７３０及び／又は不揮発性メモリ７４０から命令を取得することができ、上述したように動作を実行するための命令を実行することができる。バス７５０は、上記構成要素を一体に相互接続し、また、任意のドック７６０、ディスプレイコントローラ及びディスプレイ装置７７０、入力／出力装置７８０（例えば、ＮＩＣ（ネットワークインターフェースカード）、カーソル制御（例えば、マウス、タッチスクリーン、タッチパッドなど）、キーボードなど）及び任意の無線送受信機７９０（例えば、ブルートゥース（登録商標）、ＷｉＦｉ、赤外線など）にそれらの構成要素を相互接続する。
【００６０】
図８は、本発明のいくつかの実施形態において使用され得る例示的なデータ処理システムを図示するブロック図である。例えば、データ処理システム８００は、ハンドヘルドコンピュータ、パーソナルディジタルアシスタント（ＰＤＡ）、携帯電話、ポータブルゲームシステム、ポータブルメディアプレーヤ、タブレット、又は、携帯電話、メディアプレーヤ及び／又はゲームシステムを含むことができるハンドヘルドコンピューティング装置とすることができる。他の例として、データ処理システム８００は、ネットワークコンピュータ又は他の装置内の埋め込み処理装置とすることができる。
【００６１】
本発明の一実施形態によれば、データ処理システム８００の例示的なアーキテクチャは、上述した携帯機器のために使用することができる。データ処理システム８００は、集積回路上の１つ以上のマイクロプロセッサ及び／又はシステムを含むことができる処理システム８２０を含む。処理システム８２０は、メモリ８１０、（１つ以上のバッテリを含む）電源８２５、オーディオ入力／出力８４０、ディスプレイコントローラ及びディスプレイ装置８６０、任意の入力／出力８５０、入力装置８７０及び無線送受信機８３０に連結されている。図８には示されていない追加の構成要素はまた、本発明の特定の実施形態においてデータ処理システム８００の一部であってもよく、本発明の特定の実施形態において図８に示されるよりも少ない構成要素が使用可能であることが理解されるであろう。更に、図８には示されていない１つ以上のバスは、当該技術分野において周知であるように様々な構成要素を相互接続するために使用することができることが理解されるであろう。
【００６２】
メモリ８１０は、データ処理システム８００による実行のためのデータ及び／又はプログラムを記憶する。オーディオ入力／出力８４０は、例えば、音楽を再生するためにマイクロフォン及び／又はスピーカを含むことができ、並びに／又はスピーカ及びマイクロフォンを介して電話機能を提供することができる。ディスプレイコントローラ及びディスプレイ装置８６０は、グラフィカルユーザインターフェース（ＧＵＩ）を含むことができる。無線（例えば、ＲＦ）送受信機８３０（例えば、ＷｉＦｉ送受信機、赤外線送受信機、ブルートゥース送受信機、無線携帯電話送受信機など）は、他のデータ処理システムと通信するために使用することができる。１つ以上の入力装置８７０は、ユーザがシステムに入力を提供するのを可能にする。これらの入力装置は、キーパッド、キーボード、タッチパネル、マルチタッチパネルなどであってもよい。任意の他の入力／出力８５０は、ドック用コネクタであってもよい。
【００６３】
上述したように、本発明の実施形態は、様々な工程を含んでもよい。工程は、汎用又は特殊目的のプロセッサに特定の工程を実行させる機械実行可能な命令で具現化され得る。代替的に、これらの工程は、工程を実行するためのハードワイヤードロジックを含む特定のハードウェア構成要素によって又はプログラミングされたコンピュータ構成要素及びカスタムハードウェア構成要素の任意の組み合わせによって実行することができる。
【００６４】
本発明の要素はまた、機械実行可能なプログラムコードを記憶する機械可読媒体として提供することができる。機械可読媒体としては、フロッピーディスク、光ディスク、ＣＤ−ＲＯＭ及び光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気若しくは光カード、又は、電子プログラムコードを記憶するのに適した他の種類の媒体／機械可読媒体を挙げることができるが、これらに限定されるものではない。
【００６５】
上記の説明全体を通じて、説明の目的のために、多数の具体的な詳細が本発明の完全な理解を提供するために記載された。しかしながら、本発明は、これらの具体的な詳細の一部がなくても実施され得ることは、当業者にとって明らかであろう。例えば、本明細書に記載された機能モジュール及び方法は、ソフトウェア、ハードウェア又はそれらの任意の組み合わせとして実装されてもよいことは、当業者にとって容易に明らかであろう。更に、本発明のいくつかの実施形態は、モバイルコンピューティング環境のコンテキストで本明細書において記載されているが、本発明の基本原理は、モバイルコンピューティングの実装に限定されるものではない。実質的に任意の種類のクライアント又はピアデータ処理装置は、例えば、デスクトップ又はワークステーションコンピュータを含むいくつかの実施形態で使用することができる。したがって、本発明の範囲及び趣旨は、以下の特許請求の範囲の観点から判断されるべきである。
【００６６】
上述したように、本発明の実施形態は、様々な工程を含んでもよい。工程は、汎用又は特殊目的のプロセッサに特定の工程を実行させる機械実行可能な命令で具現化され得る。代替的に、これらの工程は、工程を実行するためのハードワイヤードロジックを含む特定のハードウェア構成要素によって又はプログラミングされたコンピュータ構成要素及びカスタムハードウェア構成要素の任意の組み合わせによって実行することができる。
【図１Ａ】
2017528963.tif 000003
【図１Ｂ】
2017528963.tif 000004
【図２】
2017528963.tif 000005
【図３】
2017528963.tif 000006
【図４】
2017528963.tif 000007
【図５】
2017528963.tif 000008
【図６】
2017528963.tif 000009
【図７】
2017528963.tif 000010
【図８】
2017528963.tif 000011
【国際調査報告】
2017528963.tif 000012