特許 6648110 クライアントをデバイスに対して認証するシステム及び方法

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

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

(11)【特許番号】6648110

(24)【登録日】2020年1月17日

(45)【発行日】2020年2月14日

(54)【発明の名称】クライアントをデバイスに対して認証するシステム及び方法

(51)【国際特許分類】

   H04L 9/32 20060101AFI20200203BHJP

   G06Q 20/40 20120101ALI20200203BHJP

   G06Q 20/38 20120101ALI20200203BHJP

   G06F 21/31 20130101ALI20200203BHJP

   H04L 9/14 20060101ALI20200203BHJP

【ＦＩ】

   H04L9/00 675B

   G06Q20/40 300

   G06Q20/38 318

   G06F21/31

   H04L9/00 641

【請求項の数】15

【全頁数】25

(21)【出願番号】特願2017-505504(P2017-505504)

(86)(22)【出願日】2015年7月30日

(65)【公表番号】特表2017-530586(P2017-530586A)

(43)【公表日】2017年10月12日

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

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

(87)【国際公開日】20160204

【審査請求日】2018年7月25日

(31)【優先権主張番号】14/448,641

(32)【優先日】2014年7月31日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】516329587

【氏名又は名称】ノック ノック ラブズ， インコーポレイテッド

(74)【代理人】

【識別番号】100094569

【弁理士】

【氏名又は名称】田中 伸一郎

(74)【代理人】

【識別番号】100088694

【弁理士】

【氏名又は名称】弟子丸 健

(74)【代理人】

【識別番号】100103610

【弁理士】

【氏名又は名称】▲吉▼田 和彦

(74)【代理人】

【識別番号】100067013

【弁理士】

【氏名又は名称】大塚 文昭

(74)【代理人】

【識別番号】100086771

【弁理士】

【氏名又は名称】西島 孝喜

(74)【代理人】

【識別番号】100109070

【弁理士】

【氏名又は名称】須田 洋之

(74)【代理人】

【識別番号】100109335

【弁理士】

【氏名又は名称】上杉 浩

(74)【代理人】

【識別番号】100120525

【弁理士】

【氏名又は名称】近藤 直樹

(74)【代理人】

【識別番号】100139712

【弁理士】

【氏名又は名称】那須 威夫

(72)【発明者】

【氏名】リンデマン ロルフ

【審査官】 青木 重徳

(56)【参考文献】

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

【文献】 国際公開第２０１４／１０５９９４（ＷＯ，Ａ１）

【文献】 米国特許出願公開第２０１３／０１２５１９７（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１０／０２９９７３８（ＵＳ，Ａ１）

【文献】 D. Hardt，The OAuth 2.0 Authrization Framework，Internet Engineering Task Force (IETF) Request for Comments: 6749，［オンライン］，２０１２年１０月，pp.23-42，［検索日 平成３０年１１月２６日］、インターネット，ＵＲＬ，<https://tools.ietf.org/pdf/rfc6749.pdf>

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

Ｈ０４Ｌ ９／３２

Ｇ０６Ｆ ２１／３１

Ｇ０６Ｑ ２０／３８

Ｇ０６Ｑ ２０／４０

Ｈ０４Ｌ ９／１４

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

【請求項1】

方法であって、
クライアントの認証部を依拠当事者に登録することであって、前記登録によって、前記クライアントのユーザが、ネットワーク上で前記依拠当事者に対して前記ユーザを遠隔で認証することを可能にする、ことと、
前記認証部と関連付けられた第１の認証鍵と、第１の検証鍵と共に生成される署名とを少なくとも使用して、前記依拠当事者において、第１の署名付き構造を生成することと、
前記第１の署名付き構造を前記クライアント上でキャッシュすることと、
前記第１の検証鍵に対応する第２の検証鍵をトランザクションデバイスに提供することと、
前記クライアントと前記トランザクションデバイスとの間で認証トランザクションを実行することであって、前記クライアントが、前記第１の認証鍵と関連付けられた第２の認証鍵を使用して第２の署名付き構造を生成し、前記トランザクションデバイスが、前記第２の検証鍵を使用して前記第１の署名付き構造に対して前記署名を有効化し、前記第１の認証鍵を使用して前記第２の署名付き構造を有効化し、前記第１及び第２の検証鍵が同じ鍵である、並びに／あるいは前記第１及び第２の認証鍵が同じ鍵であることと、
を含む、方法。

【請求項2】

前記第１の検証鍵が、前記署名を生成するのに使用される秘密鍵であり、前記トランザクションデバイスに提供される前記第２の検証鍵が、前記署名を有効化することができる対応する公開検証鍵である、請求項１に記載の方法。

【請求項3】

前記第２の認証鍵が、前記認証部と関連付けられた秘密認証鍵を含み、前記第１の認証鍵が対応する公開認証鍵である、請求項１に記載の方法。

【請求項4】

前記第１の認証鍵が前記認証部と関連付けられた公開鍵（Ｕａｕｔｈ．ｐｕｂ）を含み、前記署名が前記第１の検証鍵を使用して少なくとも前記公開鍵に対して生成される、請求項１に記載の方法。

【請求項5】

方法であって、
クライアントの認証部を依拠当事者に登録することであって、前記登録によって、前記クライアントのユーザが、ネットワーク上で前記依拠当事者に対して前記ユーザを遠隔で認証することを可能にする、ことと、
前記認証部と関連付けられた第１の認証鍵と、第１の検証鍵と共に生成される署名とを少なくとも使用して、前記依拠当事者において、第１の署名付き構造を生成することと、
トランザクションデバイスを通したトランザクションを開始するため、ユーザ要求に応答して、前記第１の署名付き構造を前記トランザクションデバイスに格納することと、
前記第１の検証鍵に対応する第２の検証鍵を前記トランザクションデバイスに提供することと、
前記クライアントと前記トランザクションデバイスとの間で認証トランザクションを実行することであって、前記クライアントが、前記第１の認証鍵と関連付けられた第２の認証鍵を使用して第２の署名付き構造を生成し、前記トランザクションデバイスが、前記第２の検証鍵を使用して前記第１の署名付き構造に対して前記署名を有効化し、前記第１の認証鍵を使用して前記第２の署名付き構造を有効化し、前記第１及び第２の検証鍵が同じ鍵である、並びに／あるいは前記第１及び第２の認証鍵が同じ鍵である、ことと、
を含む、方法。

【請求項6】

前記第１の認証鍵が前記認証部と関連付けられた公開鍵（Ｕａｕｔｈ．ｐｕｂ）を含み、前記署名が前記第１の検証鍵を使用して少なくとも前記公開鍵に対して生成される、請求項５に記載の方法。

【請求項7】

前記第１の署名付き構造が、前記依拠当事者によって生成されるナンスと、前記公開鍵と、
前記ナンス及び前記公開鍵の組み合わせに対して生成される前記署名との組み合わせを含む、請求項６に記載の方法。

【請求項8】

前記第１の署名付き構造が、前記依拠当事者によって生成されるナンスと、前記第１の署名付き
構造を前記クライアントでキャッシュすることができる時間量を示すキャッシュタイミングデータと、前記公開鍵と、前記ナンス、前記キャッシュタイミングデータ、及び前記公開鍵の組み合わせに対して生成される前記署名との組み合わせを含む、請求項６に記載の方法。

【請求項9】

前記第２の署名付き構造が、前記トランザクションデバイスによって提供されるナンス又は値と、前記トランザクションデバイスによって提供される少なくとも前記ナンス及び／又は前記値に対して、前記第２の認証鍵を適用することによって生成される署名とを含む、
請求項６に記載の方法。

【請求項10】

前記第２の署名付き構造が、前記トランザクションデバイスとのトランザクションの間、前記クライアントにセキュアに表示されるトランザクションテキストに対して、前記第２の認証鍵を適用することによって生成される署名を含む、請求項６に記載の方法。

【請求項11】

前記署名が、前記第１の認証鍵を使用して、前記トランザクションデバイス及び／又は前記依拠当事者によって検証される、請求項１０に記載の方法。

【請求項12】

方法であって、
クライアントの認証部を依拠当事者に登録することであって、前記登録によって、前記クライアントのユーザが、ネットワーク上で前記依拠当事者に対して前記ユーザを遠隔で認証することを可能にする、ことと、
前記認証部と関連付けられた第１の認証鍵を少なくとも使用して、前記依拠当事者において、第１の署名付き構造を生成することと、
前記第１の署名付き構造を前記クライアント上でキャッシュすることと、
前記クライアントとトランザクションデバイスとの間で認証トランザクションを実行することであって、前記クライアントが、前記第１の認証鍵と関連付けられた第２の署名付き鍵を使用して第２の署名付き構造を生成し、前記トランザクションデバイスが、前記依拠当事者に対するオンライン又はアウトオブバンド接続を使用して前記第１の署名付き構造を有効化し、前記第１の認証鍵を使用して前記第２の署名付き構造を有効化し、前記第１及び第２の認証鍵は同じ鍵である、ことと、
を含む、方法。

【請求項13】

前記第１の認証鍵が前記認証部と関連付けられた公開鍵（Ｕａｕｔｈ．ｐｕｂ）を含む、請求項１２に記載の方法。

【請求項14】

前記第１の署名付き構造が、前記依拠当事者によって生成されるナンスと、前記公開鍵と、前記ナンス及び前記公開鍵の組み合わせに対して生成される署名との組み合わせを含む、請求項１３に記載の方法。

【請求項15】

前記第１の署名付き構造が、前記依拠当事者によって生成されるナンスと、前記第１の署名付き構造を前記クライアントでキャッシュすることができる時間量を示すキャッシュタイミングデータと、前記公開鍵と、前記ナンス、前記キャッシュタイミングデータ、及び前記公開鍵の組み合わせに対して生成される署名との組み合わせを含む、請求項１３に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、概して、データ処理システムの分野に関する。より詳細には、本発明は、オフラインデバイス、又は接続可能性が依拠当事者に限定されているデバイスなどのデバイスに対して、クライアントを認証するシステム及び方法に関する。

【背景技術】

【0002】

図１は、生体認証デバイス１００を有する例示的なクライアント１２０を図示している。正常動作時において、生体認証センサ１０２は、ユーザからの生の生体認証データを読み取り（例えば、ユーザの指紋を獲得する、ユーザの音声を録音する、ユーザのスナップ写真を撮るなど）、特徴抽出モジュール１０３は、生の生体認証データの指定された特性を抽出する（例えば、指紋の特定領域、特定の顔特徴などに焦点を当てるなど）。照合部モジュール１０４は、抽出した特徴１３３を、クライアント１２０のセキュアストレージに格納された生体認証基準データ１１０と比較し、抽出した特徴と生体認証基準データ１１０との間の類似度に基づいてスコア１５３を生成する。生体認証基準データ１１０は、一般的に、ユーザが、指紋、音声サンプル、画像、又は他の生体認証データをデバイス１００に登録する登録プロセスの結果である。次に、アプリケーション１０５は、スコア１３５を使用して、認証が成功したか否か（例えば、スコアが特定の指定閾値を上回っているか）を判定してもよい。

【0003】

システムはまた、生体認証センサを使用して、ネットワーク上でセキュアなユーザ認証を提供するために設計されている。かかるシステムでは、アプリケーション１０５によって生成されたスコア１３５及び／又は他の認証データは、リモートサーバによってユーザを認証するため、ネットワークを通じて送信されてもよい。例えば、特許出願公開第２０１１／００８２８０１号（「’８０１号出願」）は、強力な認証（例えば、個人情報の盗難やフィッシングに対する保護）、セキュアトランザクション（例えば、「ブラウザにおけるマルウェア」及びトランザクションに対する「中間者」攻撃に対する保護）、並びに、クライアント認証トークンの登録／管理（例えば、指紋リーダ、顔認識デバイス、スマートカード、トラステッドプラットフォームモジュールなど）を提供する、ネットワーク上のユーザ登録及び認証のためのフレームワークについて記載している。

【0004】

本出願の譲受人は、’８０１号出願に記載されている認証フレームワークに対する様々な改善を開発している。これらの改善のうちいくつかは、本件の譲受人に譲渡され、全て１０１２年１２月２９日に出願された以下の一群の米国特許出願（「同時係属出願」）に記載されている：第１３／７３０，７６１号、Ｑｕｅｒｙ Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｔｏ Ｄｅｔｅｒｍｉｎｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃａｐａｂｉｌｉｔｉｅｓ；第１３／７３０，７７６号、Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｅｆｆｉｃｉｅｎｔｌｙ Ｅｎｒｏｌｌｉｎｇ，Ｒｅｇｉｓｔｅｒｉｎｇ，ａｎｄ Ａｕｔｈｅｎｔｉｃａｔｉｎｇ Ｗｉｔｈ Ｍｕｌｔｉｐｌｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄｅｖｉｃｅｓ；第１３／７３０，７８０号、Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｐｒｏｃｅｓｓｉｎｇ Ｒａｎｄｏｍ Ｃｈａｌｌｅｎｇｅｓ Ｗｉｔｈｉｎ ａｎ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ；第１３／７３０，７９１号、Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｉｍｐｌｅｍｅｎｔｉｎｇ Ｐｒｉｖａｃｙ Ｃｌａｓｓｅｓ Ｗｉｔｈｉｎ ａｎ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ；第１３／７３０，７９５号、Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｉｍｐｌｅｍｅｎｔｉｎｇ Ｔｒａｎｓａｃｔｉｏｎ Ｓｉｇｎａｌｉｎｇ Ｗｉｔｈｉｎ ａｎ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ。

【0005】

簡単に言えば、同時係属出願は、ユーザがクライアントの生体認証デバイスを用いて登録を行って、（例えば、指スワイプ、画像スナップ、音声記録などによって）生体認証テンプレートデータを生成し；生体認証デバイスをネットワーク（例えば、同時係属出願に記載されているようなセキュアトランザクションサービスが装備されたウェブサイト又は他の依拠当事者）上で１つ以上のサーバに登録し；その後、登録プロセス中に交換されるデータ（例えば、生体認証デバイス内にプロビジョニングされる暗号鍵）を使用して、それらのサーバで認証する、認証技術について記載している。認証されると、ユーザは、ウェブサイト又は他の依拠当事者と１つ以上のオンライントランザクションを実行することが許可される。同時係属出願に記載されているフレームワークでは、ユーザを固有に識別するのに使用することができる、指紋データ及び他のデータなどの機密情報は、ユーザのプライバシーを保護するため、ユーザのクライアントデバイス（例えば、スマートフォン、ノートブックコンピュータなど）上でローカルに保持されてもよい。
本発明のより良好な理解は、以下の図面と共に以下の詳細な説明から得ることができる。

【図面の簡単な説明】

【0006】

【図1】生体認証能力を有する例示のクライアントデバイスを図示している。

【図2A】セキュア認証システムアーキテクチャの２つの異なる実施形態を図示している。

【図2B】セキュア認証システムアーキテクチャの２つの異なる実施形態を図示している。

【図2C】鍵を認証デバイスに登録することができる方法を示すトランザクション図を図示している。

【図3A】セキュアディスプレイを使用するセキュアトランザクション確認の実施形態を図示している。

【図3B】セキュアディスプレイを使用するセキュアトランザクション確認の実施形態を図示している。

【図4】関係が確立されていないデバイスとのトランザクションのための認証を行う本発明の一実施形態を図示している。

【図5A】トランザクションのための認証を行う２つの異なる実施形態を示すトランザクション図である。

【図5B】トランザクションのための認証を行う２つの異なる実施形態を示すトランザクション図である。

【図6】本発明の一実施形態で用いられる追加のアーキテクチャ上の特徴を図示している。

【図7】本発明の異なる実施形態で用いられるベアラートークンの異なる実施形態を図示している。

【図8】本発明の異なる実施形態で用いられるベアラートークンの異なる実施形態を図示している。

【図9】例示の「オフライン」及び「セミオフライン」認証シナリオを図示している。

【図10】クライアント及び／又はサーバのための例示のシステムアーキテクチャを図示している。

【図11】クライアント及び／又はサーバのための別の例示のシステムアーキテクチャを図示している。

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

【0007】

以下、高度な認証技術及び関連アプリケーションを実装するための装置、方法、及び機械可読媒体の実施形態について記載する。説明を通して、説明の目的のために、多数の具体的な詳細が本発明の完全な理解を提供するために記載されている。しかしながら、本発明が、これらの具体的な詳細の一部がなくても実施され得ることは、当業者にとって明白となるであろう。他の例では、周知の構造及びデバイスは示されていないか、又は本発明の基本原理が曖昧になることを避けるため、ブロック図の形態で示されている。

【0008】

以下に考察する本発明の実施形態は、生体認証デバイス又はＰＩＮ入力などの認証能力を備えたクライアントデバイスを伴う。これらのデバイスは、本明細書では、「トークン」、「認証デバイス」、又は「認証部」と称される場合がある。特定の実施形態は、顔認識ハードウェア／ソフトウェア（例えば、ユーザの顔を認識し、ユーザの眼の動きを追跡するためのカメラ及び関連ソフトウェア）に焦点を当てており、いくつかの実施形態は、例えば、指紋センサ、音声認識ハードウェア／ソフトウェア（例えば、ユーザの音声を認識するためのマイクロフォン及び関連ソフトウェア）、並びに光学認識能力（例えば、ユーザの網膜をスキャンするための光学スキャナ及び関連ソフトウェア）を含む、追加の生体認証デバイスを利用してもよい。認証能力はまた、トラステッドプラットフォームモジュール（ＴＰＭ）及びスマートカードなどの非生体認証デバイスを含むことができる。

【0009】

モバイル生体認証の実装例では、生体認証デバイスは依拠当事者から遠隔にあってもよい。本明細書で使用するとき、「遠隔」という用語は、生体認証センサが、センサが通信可能に結合されているコンピュータのセキュリティ境界の一部ではない（例えば、依拠当事者コンピュータと同じ物理的筐体内に埋め込まれていない）ことを意味する。一例として、生体認証デバイスは、ネットワーク（例えば、インターネット、無線ネットワークリンクなど）を介して、又はＵＳＢポートなどの周辺入力を介して、依拠当事者に結合されてもよい。これらの条件下では、そのデバイスが依拠当事者（例えば、認証及び完全性保護の許容レベルを提供するもの）によって認証されるものであるか、及び／又はハッカーが生体認証デバイスを侵害したかを、依拠当事者が知る方法がないことがある。生体認証デバイスにおける信頼性は、デバイスの特定の実装例に応じて決まる。

【0010】

しかしながら、後述するように、ユーザを認証するのに用いられる認証技術は、遠隔サーバ及び／又は他のデータ処理デバイスとのネットワークを介した通信など、非位置要素を伴ってもよい。更に、具体的な実施形態（ＡＴＭ及び小売店など）が本明細書において記載されるが、本発明の基本原理は、トランザクションがエンドユーザによってローカル又は遠隔で開始される、任意のシステムのコンテキスト内で実装されてもよいことに留意すべきである。

【0011】

「依拠当事者」という用語は、本明細書では、ユーザトランザクションを実行しようとしているエンティティ（例えば、ユーザトランザクションを実行するウェブサイト又はオンラインサービス）だけでなく、本明細書に記載する基本認証技術を実行してもよいそのエンティティの代理として実装されるセキュアトランザクションサーバも指すのに使用される場合がある。遠隔認証能力を提供したセキュアトランザクションサーバは、所有され、及び／又は依拠当事者の制御下にあってもよく、あるいは事業構成の一部として依拠当事者に対してセキュアトランザクションサービスを提供する第三者の制御下にあってもよい。

【0012】

「サーバ」という用語は、本明細書では、クライアントからネットワークを介して要求を受信し、応答として１つ以上の動作を行い、一般的に動作の結果を含む応答をクライアントに送信する、ハードウェアプラットフォーム上で（又は複数のハードウェアプラットフォームにわたって）実行されるソフトウェアを指すのに使用される。サーバは、ネットワーク「サービス」をクライアントに提供する、又は提供する助けとなるように、クライアントの要求に応答する。重要なことには、サーバは、単一のコンピュータ（例えば、サーバソフトウェアを実行する単一のハードウェアデバイス）に限定されず、実際には、潜在的に複数の地理的位置において、複数のハードウェアプラットフォームにわたって散在してもよい。

【0013】

本明細書に記載する本発明の実施形態は、セキュアトランザクションデバイスを通してトランザクションを開始するために、ユーザを認証する技術を含む。一例として、トランザクションは、払い戻し、振替、又は他のユーザ起動型動作であってもよく、トランザクションデバイスは、自動預金支払機（ＡＴＭ）、売場専用（ＰｏＳ）トランザクションデバイス、又はユーザの代理としてトランザクションを実行することができる他のデバイスであってもよい。トランザクションは、例えば、デバイスを装備した小売店若しくは他の小売場所における物品又はサービスの購入に対する支払いの完了、デバイスを介したファンドの払い戻し、デバイスに対するメンテナンスの実行、あるいはユーザ認証を要する他の任意のトランザクションを伴ってもよい。

【0014】

本発明の一実施形態は、デバイスがオフライン（即ち、バックエンド認証サーバに接続されていない）又はセミオフライン（即ち、周期的にのみバックエンド認証サーバに接続される）の状況であっても、ユーザをローカルで認証する（即ち、ユーザを検証する）ための技術を提供する。一実施形態では、ユーザのクライアントデバイスは、（例えば、依拠当事者の代理として動作する）バックエンド認証サーバによって生成される認証要求をキャッシュする能力を備え、デバイスは、ユーザのクライアントデバイスからデバイスに送信された認証応答を検証するのに必要なデータを備える。

【0015】

これらの実施形態の詳細を考察する前に、遠隔ユーザ認証技術の概要を提供する。これら及び他の遠隔ユーザ認証技術は、本出願の譲受人に譲渡されており、参照により本明細書に組み込まれる、同時係属出願に記載されている。

【0016】

遠隔ユーザ認証技術
図２Ａ及び図２Ｂは、ユーザを遠隔で認証する、クライアント側及びサーバ側の構成要素を備えるシステムアーキテクチャの２つの実施形態を図示している。図２Ａに示される実施形態は、ウェブサイトと通信するため、ブラウザプラグインベースのアーキテクチャを使用するが、図２Ｂに示される実施形態はブラウザを要しない。本明細書に記載する様々な認証技術及び関連アプリケーションは、これらのシステムアーキテクチャのいずれかに実装されてもよい。例えば、本明細書に記載するクライアントデバイス内の認証エンジンは、インターフェース２０２を含むセキュアトランザクションサービス２０１の一部として実装されてもよい。しかしながら、上述した実施形態は、図２Ａ及び図２Ｂに示されるもの以外のハードウェア及びソフトウェアのロジック構成を使用して実装されてもよいことに留意すべきである。

【0017】

図２Ａを参照すると、図示される実施形態は、エンドユーザを登録し認証するための１つ以上の認証デバイス２１０〜２１２を装備したクライアント２００を含む。上述したように、認証デバイス２１０〜２１２は、指紋センサ、音声認識ハードウェア／ソフトウェア（例えば、ユーザの音声を認識するためのマイクロフォン及び関連ソフトウェア）、顔認識ハードウェア／ソフトウェア（例えば、ユーザの顔を認識するためのカメラ及び関連ソフトウェア）、及び光学認識能力（ユーザの網膜をスキャンするための光スキャナ及び関連ソフトウェア）などの生体認証デバイス、並びにトラステッドプラットフォームモジュール（ＴＰＭ）及びスマートカードなどの非生体認証デバイスを含んでもよい。ユーザは、セキュアトランザクションサービス２０１が（インターフェース２０２を介して）セキュアストレージ２２０に生体認証テンプレートデータとして格納してもよい、生体認証データを提供する（例えば、指紋認証デバイス上で指をスワイプする）ことによって、生体認証デバイスに登録してもよい。

【0018】

セキュアストレージ２２０は、認証デバイス２１０〜２１２のセキュア周辺の外側に図示されているが、一実施形態では、各認証デバイス２１０〜２１２は独自の統合セキュアストレージを有してもよい。それに加えて、各認証デバイス２１０〜２１２は、生体認証基準データレコードを暗号的に保護（例えば、ストレージ２２０をセキュアにするため、データレコードをラッピング）してもよい。

【0019】

認証デバイス２１０〜２１２は、セキュアトランザクションサービス２０１によって露出されたインターフェース２０２（例えば、アプリケーションプログラミングインターフェース、即ちＡＰＩ）を通して、クライアントに通信可能に結合される。セキュアトランザクションサービス２０１は、ネットワーク上で１つ以上のセキュアトランザクションサーバ２３２〜２３３と通信し、ウェブブラウザ２０４のコンテキスト内で実行されるセキュアトランザクションプラグイン２０５とインターフェース接続するためのセキュアアプリケーションである。図示されるように、インターフェース２０２はまた、デバイス識別コード（認証部証明ＩＤ（ＡＡＩＤ））、ユーザ識別コード、ユーザ登録データ（例えば、スキャンされた指紋又は他の生体認証データ）、及び本明細書に記載するセキュア認証技術を実行するのに使用される鍵など、認証デバイス２１０〜２１２のそれぞれに関する情報を格納する、クライアント２００のセキュアストレージデバイス２２０に対するセキュアアクセスを提供してもよい。例えば、詳細に後述するように、固有の鍵が認証デバイスそれぞれに格納され、その後、インターネットなどのネットワーク上でサーバ２３０と通信するときに使用されてもよい。

【0020】

後述するように、特定の種類のネットワークトランザクションは、ウェブサイト２３１若しくは他のサーバとのＨＴＴＰ又はＨＴＴＰＳトランザクションなど、セキュアトランザクションプラグイン２０５によってサポートされる。一実施形態では、セキュアトランザクションプラグインは、セキュア企業又はウェブデスティネーション２３０内のウェブサーバ２３１（以下、単に「サーバ２３０」と称されることがある）によって、ウェブページのＨＴＭＬコードに挿入された特定のＨＴＭＬタグに応答して開始される。かかるタグの検出に応答して、セキュアトランザクションプラグイン２０５は、トランザクションをセキュアトランザクションサービス２０１に転送して処理してもよい。それに加えて、特定の種類のトランザクション（例えば、セキュア鍵交換など）について、セキュアトランザクションサービス２０１は、構内トランザクションサーバ２３２（すなわち、ウェブサイトと同位置に配置される）又は構外トランザクションサーバ２３３との直接の通信チャネルを開いてもよい。

【0021】

セキュアトランザクションサーバ２３２〜２３３は、ユーザデータ、認証デバイスデータ、鍵、及び後述するセキュア認証トランザクションをサポートするのに必要な他のセキュア情報を格納する、セキュアトランザクションデータベース２４０に結合される。しかしながら、本発明の基本原理は、図２Ａに示されるセキュア企業又はウェブデスティネーション２３０内の論理的構成要素の分離を要しないことに留意すべきである。例えば、ウェブサイト２３１及びセキュアトランザクションサーバ２３２〜２３３は、単一の物理的サーバ又は別個の物理的サーバ内に実装されてもよい。更に、ウェブサイト２３１及びトランザクションサーバ２３２〜２３３は、後述する機能を行うために１つ以上のサーバ上で実行される統合されたソフトウェアモジュール内に実装されてもよい。

【0022】

上述したように、本発明の基本原理は、図２Ａに示されるブラウザベースのアーキテクチャに限定されない。図２Ｂは、スタンドアロンアプリケーション２５４が、セキュアトランザクションサービス２０１によって提供される機能を利用してネットワーク上でユーザを認証する、代替の実装例を図示している。一実施形態では、アプリケーション２５４は、詳細に後述するユーザ／クライアント認証技術を実行するための、セキュアトランザクションサーバ２３２〜２３３に依存する１つ以上のネットワークサービス２５１との通信セッションを確立するように設計される。

【0023】

図２Ａ及び図２Ｂに示される実施形態のどちらにおいても、セキュアトランザクションサーバ２３２〜２３３は、次にセキュアトランザクションサービス２０１に対してセキュアに送信され、セキュアストレージ２２０内の認証デバイスに格納される、鍵を生成してもよい。それに加えて、セキュアトランザクションサーバ２３２〜２３３は、サーバ側のセキュアトランザクションデータベース２４０を管理する。

【0024】

図２Ｃは、認証デバイスを登録するための一連のトランザクションを図示している。上述したように、登録の間、鍵は認証デバイスとセキュアトランザクションサーバ２３２〜２３３のうち１つとの間で共有される。鍵は、クライアント２００のセキュアストレージ２２０、及びセキュアトランザクションサーバ２３２〜２３３によって使用されるセキュアトランザクションデータベース２２０内に格納される。一実施形態では、鍵は、セキュアトランザクションサーバ２３２〜２３３のうち１つによって生成される対称鍵である。しかしながら、後述する別の実施形態では、非対称鍵が使用されてもよい。この実施形態では、公開鍵は、セキュアトランザクションサーバ２３２〜２３３によって格納されてもよく、第２の関連する秘密鍵は、クライアントのセキュアストレージ２２０に格納されてもよい。更に、別の実施形態では、鍵は、（例えば、セキュアトランザクションサーバ２３２〜２３３よりもむしろ認証デバイス又は認証デバイスインターフェースによって）クライアント２００上で生成されてもよい。本発明の基本原理は、任意の特定の種類の鍵又は鍵の生成方法に限定されない。

【0025】

動的対称鍵プロビジョニングプロトコル（ＤＳＫＰＰ）などのセキュア鍵プロビジョニングプロトコルは、セキュア通信チャネルを通じてクライアントと鍵を共有するのに使用されてもよい（例えば、コメント要請（ＲＦＣ）６０６３を参照）。しかしながら、本発明の基本原理は、いかなる特定の鍵プロビジョニングプロトコルにも限定されない。

【0026】

図２Ｃに示される具体的な詳細を参照すると、ユーザ登録又はユーザ検証が完了すると、サーバ２３０は、デバイス登録の間にクライアントによって提示されなければならないランダム生成チャレンジ（例えば、暗号化ナンス）を生成する。ランダムチャレンジは、限定機関の間有効であってもよい。セキュアトランザクションプラグインは、ランダムチャレンジを検出し、それをセキュアトランザクションサービス２０１に転送する。それに応答して、セキュアトランザクションサービスは、サーバ２３０とのアウトオブバンドセッション（例えば、アウトオブバンドトランザクション）を開始し、鍵プロビジョニングプロトコルを使用してサーバ２３０と通信する。サーバ２３０は、ユーザ名を用いてユーザの位置を確認し、ランダムチャレンジを有効化し、デバイスの認証コードが送られた場合にその認証コード（例えば、ＡＡＩＤ）を有効化し、セキュアトランザクションデータベース２２０にユーザのための新たなエントリを作成する。また、鍵又は公開／秘密鍵の対を生成し、鍵をデータベース２２０に書き込み、鍵プロビジョニングプロトコルを使用して鍵をセキュアトランザクションサービス２０１に返送してもよい。完了すると、認証デバイス及びサーバ２３０は、対称鍵が使用された場合には同じ鍵を共有し、非対称鍵が使用された場合には異なる鍵を共有する。

【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】

認証鍵に対する署名付きトークンの結合
図７に図示されるように、一実施形態では、署名付きトークンを認証鍵に結合するために、トークン発行者（例えば、依拠当事者４５１）は：（ａ）認証公開鍵（Ｕａｕｔｈ．ｐｕｂ）７０２を署名（待ち）トークンの署名待ち部分７０１に追加し；（ｂ）その署名付きトークンを認証応答の署名待ち部分に含める。これを行うことによって、トークン受領者（例えば、トランザクションデバイス４５０）は、署名７０３（例えば、上述の公開ＲＰＶｅｒｉｆｙＫｅｙ）を有効化することによって、トークンを検証することができる。検証が成功した場合、上述したように、公開鍵（Ｕａｕｔｈ．ｐｕｂ）を抽出し、それを使用して認証応答を検証することができる。

【0076】

認証鍵に対する無署名トークンの結合
図８に図示されるように、無署名トークン８０２を認証鍵に結合するために、一実施形態では、トークン発行者（例えば、依拠当事者４５１）は、（少なくとも）元のトークン８０２と認証公開鍵（Ｕａｕｔｈ．ｐｕｂ）を含む署名待ちデータ８０１とを網羅する、署名付き構造を作成する。署名付き構造は、秘密署名鍵（例えば、上述のＲＰＶｅｒｉｆｙＫｅｙ対）に関連する公開鍵を使用して、署名８０３を有効化することによって、検証することができる。この公開署名鍵は、トークン受領者（例えば、トランザクションデバイス４５０）と共有する必要がある。共有は、署名鍵対を生成した後に、潜在的には第１の署名付き構造がよりも生成される大分前に行うことができる。

【0077】

本明細書に記載する技術は、「完全オフライン」実装例（即ち、トランザクションの時点でトランザクションデバイス４５０が依拠当事者４５１に対する接続を有さない）、並びに「セミオフライン」実装例（即ち、トランザクションの時点でトランザクションデバイスは依拠当事者４５１に対する接続を有するが、クライアントは有さない）の両方をサポートする。

【0078】

完全オフラインの場合であっても、トランザクションデバイス４５０は以前として、依拠当事者４５１に対してホストを介して時々接続されることが期待される。例えば、ホストは、トランザクションデバイス４５０に格納された全ての応答を、依拠当事者に送るために収集してもよく、また、取り消されたＵａｕｔｈ鍵（例えば、最後の接続以降は取り消されている公開認証鍵）のリストを更新（必要であれば）してもよい。

【0079】

いくつかの実施形態はまた、純粋な（セッション）認証並びにトランザクション確認もサポートする。トランザクション確認の場合であっても、依拠当事者４５１は、トランザクションデバイス４５０がトランザクションテキストを認証応答と共に依拠当事者４５１に提出する場合、トランザクションを検証することができる。

【0080】

本明細書に記載する技術に対して、いくつかの異なる使用事例／アプリケーションがある。例えば：
１．支払いユーザは、自身の認証部（例えば、スマートフォン）に支払いサービス提供者（ＰＳＰ）を登録している。ユーザは、ＰＳＰによって認証された売場専用デバイス（ＰｏＳ）を使用して、あるマーチャントでの支払いを認証したいが、ＰｏＳは、（例えば、バスに配置された）ＰＳＰに対する信頼できる恒久的なオンライン接続を有さない。この例では、信頼できる恒久的な接続がないにも関わらずトランザクションを可能にするため、上述したように、ＰｏＳはトランザクションデバイス４５０として実装されてもよく、ＰＳＰは依拠当事者４５１として実装されてもよい。
２．物のインターネット企業は、（例えば、工場、ビルなどに）いくつかの埋め込みデバイスをインストールしている。かかるデバイスのメンテナンスは、契約当事者が雇用した技術者によって実行される。メンテナンスを実行するため、技術者は、その作業に対する自身の適格性を証明するために、デバイスに対して認証しなければならない。以下の仮定が（現実の構成条件に基づいて）行われる。
ａ．技術者は、かかるデバイスのそれぞれの登録を実行することはできない（デバイスが多すぎるため）。
ｂ．デバイスそれぞれにおいて適格技術者のリストを細心に保つためには、技術者の人数が多すぎ、かかる技術者のばらつきが大きすぎる。
ｃ．デバイスも技術者のコンピュータも、メンテナンスの時点で信頼できるネットワーク接続を有さない。

【0081】

上述の技術を使用して、企業は、トラストアンカー（例えば、公開ＲＰＶｅｒｉｆｙＫｅｙ）を全てのデバイスに一度に（例えば、インストール時に）注入することができる。
各技術者は、次に、契約当事者（例えば、技術者の雇用主であってもよい依拠当事者４５１）に登録する。上述の技術を使用して、技術者は、各デバイスを認証することができる。

【0082】

上述した本発明の実施形態は、認証能力を有するクライアントを依拠当事者に登録するいずれかのシステムで実装されてもよく、認証動作は、このクライアントと、（ａ）依拠当事者の代理を果たす、及び（ｂ）トランザクションの時点でオフラインである（即ち、クライアントが登録されている依拠当事者の元のサーバに対して信頼できるネットワーク接続を有していない）、デバイスとの間で実行される。かかる例では、クライアントは、キャッシュ可能な認証要求を元のサーバから受信し、それをキャッシュする。要求されると、クライアントは認証応答を計算し、それをデバイスに送る。

【0083】

別の実施形態では、クライアントは、暗号的にセキュアな方法で、チャネル結合データ（認証要求で受信される）を応答に追加する。これを行うことによって、依拠当事者の元のサーバは、要求が（何らかの中間者ではなく）合法的なクライアントによって受信されたことを検証することができる。

【0084】

一実施形態では、依拠当事者は、許可されたＵａｕｔｈ．ｐｕｂ鍵を取得するために依拠当事者サーバにコンタクトする必要なしに、デバイスが認証又はトランザクション確認応答を検証するのを可能にするＵａｕｔｈ．ｐｕｂ鍵など、追加の認証済みデータを応答に追加する。別の実施形態では、依拠当事者は、（サービス攻撃の拒否を防止するために）「キャッシュ可能な」認証要求を発行する前に、クライアントのユーザが成功する認証を実行することを要求する。一実施形態では、依拠当事者は、要求がキャッシュ可能であるか否かをクライアントが示すことを要求する。キャッシュ可能である場合、依拠当事者は、応答において追加の認証データを要求してもよい（例えば、上述のＭａｘＣａｃｈｅＴｉｍｅ）。

【0085】

一実施形態では、トランザクションデバイス４５０などのデバイスは、依拠当事者に対する直接ネットワーク接続を有さず、別個のコンピュータ（本明細書では、「ホスト」と称されることがある）を使用して、依拠当事者に「同期」される。このホストは、全ての収集された認証応答をデバイスから取得し、それらを依拠当事者に転送する。それに加えて、ホストはまた、取り消されたＵａｕｔｈ鍵のリストをデバイスにコピーして、取り消された鍵の１つが認証応答で使用されていないことを保証してもよい。

【0086】

一実施形態では、トランザクションデバイス４５０などのデバイスは、ランダム値（例えば、ナンス）をクライアントに送り、クライアントは、このランダム値を、署名前の認証応答に対する拡張として、暗号的に追加する。この署名付きランダム値は、デバイスに対する鮮度の証明として役立つ。

【0087】

一実施形態では、クライアントの認証部は、署名前の認証応答に対する拡張として、現在時間Ｔａを追加する。デバイス／トランザクションデバイスは、その時間を現在時間Ｔｄと比較し、ＴａとＴｄとの差が許容可能である場合（例えば、差が２分未満（ａｂｓ（Ｔｄ−Ｔａ）＜２分）である場合）にのみ、応答を許容してもよい。

【0088】

一実施形態では、依拠当事者は、認証済み（即ち、署名付き）の有効期限をキャッシュ可能な要求に追加する。上述したように、デバイス／トランザクションデバイスは、有効期限前に受信された場合にのみ、応答を有効であるとして許容する。

【0089】

一実施形態では、依拠当事者は、公開鍵、有効期限、最大トランザクション値（例えば、セキュリティアサーションマークアップランゲージ（ＳＡＭＬ）アサーション、ＯＡｕｔｈトークン、ＪＳＯＮウェブ署名（ＪＷＳ）オブジェクトなど）などの（但しそれらに限定されない）、キャッシュ可能な要求に対する追加情報を含む、認証済み（即ち、署名付き）のデータブロック（例えば、上述の「署名付きトークン構造」）を追加する。デバイス／トランザクションデバイスは、署名付きデータブロックを肯定的に検証でき、内容が許容可能である場合にのみ、応答を有効として許容してもよい。

【0090】

一実施形態では、依拠当事者は、署名トークンのみをキャッシュ可能な認証要求に追加するが、トランザクションデバイスは、トランザクションの時点で依拠当事者に対するオンライン接続を有する。トランザクションデバイスは、トランザクションの時点で依拠当事者に対するオンライン接続を使用して、無署名トークンの信頼性を検証する。

【0091】

図９は、本発明の一実施形態による、例示の「オフライン」及び「セミオフライン」認証シナリオを図示している。この実施形態では、コンピュータデバイス９１０を有するユーザは、依拠当事者９３０に対する確立された関係を有し、依拠当事者を認証することができる。しかしながら、いくつかの状況では、ユーザは、依拠当事者９３０に対する確立された関係を有するが、ユーザのコンピュータデバイス９１０に対しては必ずしも有さないデバイス９７０を用いて、トランザクション（例えば、トランザクション確認の認証）を実行することを望む。この実施形態に関して、トランザクションは、接続９２０及び接続９２１が存在しないか、関連がある時点（例えば、ユーザのコンピュータデバイス９１０をデバイス９７０に対して認証する時点、又はユーザのコンピュータデバイス９１０とデバイス９７０との間のトランザクションの時点）で安定しない場合、「完全オフライン」と称される。この実施形態に関して、トランザクションは、ユーザのコンピュータデバイス９１０と依拠当事者９３０との間の接続９２０は安定しないが、デバイス９７０と依拠当事者９３０との間の接続９２１は安定している場合に、「セミオフライン」である。この実施形態では、ユーザのコンピュータデバイス９１０とデバイス９７０との間の接続９２２は、関連がある時点で安定している必要があることに留意されたい。また、認証部がユーザのコンピュータデバイス９１０に接続されることも予期される。接続９２２は、ブルートゥース、ブルートゥースローエナジー（ＢＴＬＥ）、近距離無線通信（ＮＦＣ）、Ｗｉｆｉ、汎欧州デジタル移動電話方式（ＧＳＭ（登録商標））、ユニバーサル移動体通信システム（ＵＴＭＳ）、ロングタームエボリューション（ＬＴＥ）（例えば、４Ｇ ＬＴＥ）、及びＴＣＰ／ＩＰを含むがそれらに限定されない、あらゆる種類の通信チャネル／プロトコルを使用して実装することができる。

【0092】

例示的なデータ処理デバイス
図１０は、本発明のいくつかの実施形態で使用されてもよい、例示的なクライアント及びサーバを図示するブロック図である。図１０は、コンピュータシステムの様々な構成要素を図示しているが、かかる詳細は本発明に適切でないため、構成要素を相互接続する任意の特定のアーキテクチャ又は方法を表すことを意図するものではないことを理解すべきである。より少数の構成要素又はより多数の構成要素を有する他のコンピュータシステムも、本発明によって使用されてもよいことが理解されるであろう。

【0093】

図１０に図示されるように、データ処理システムの形態であるコンピュータシステム１０００は、処理システム１０２０に結合されているバス１０５０と、電源１０２５と、メモリ１０３０と、不揮発性メモリ１０４０（例えば、ハードドライブ、フラッシュメモリ、相変化メモリ（ＰＣＭ）など）とを含む。バス１０５０は、当該技術分野において周知であるように、様々なブリッジ、コントローラ、及び／又はアダプタを通して互いに接続されてもよい。処理システム１０２０は、メモリ１０３０及び／又は不揮発性メモリ１０４０から命令を取得し、命令を実行して上述したような動作を行ってもよい。バス１０５０は、上述の構成要素を一体に相互接続し、また、任意のドック１０６０、ディスプレイコントローラ及びディスプレイデバイス１０７０、入出力デバイス１０８０（例えば、ＮＩＣ（ネットワークインターフェースカード）、カーソル制御（例えば、マウス、タッチスクリーン、タッチパッドなど）、キーボードなど）、及び任意の無線送受信機１０９０（例えば、ブルートゥース、ＷｉＦｉ、赤外線など）にそれらの構成要素を相互接続する。

【0094】

図１１は、本発明のいくつかの実施形態で使用されてもよい、例示的なデータ処理システムを図示するブロック図である。例えば、データ処理システム１９０は、ハンドヘルドコンピュータ、パーソナルディジタルアシスタント（ＰＤＡ）、携帯電話、ポータブルゲームシステム、ポータブルメディアプレーヤ、タブレット、あるいは携帯電話、メディアプレーヤ、及び／又はゲームシステムを含んでもよいハンドヘルドコンピュータデバイスであってもよい。別の例として、データ処理システム１１００は、ネットワークコンピュータ、又は別のデバイス内の埋め込み処理デバイスであってもよい。

【0095】

本発明の一実施形態によれば、データ処理システム１１００の例示的なアーキテクチャは、上述したモバイルデバイスのために使用されてもよい。データ処理システム１１００は、集積回路上の１つ以上のマイクロプロセッサ及び／又はシステムを含んでもよい、処理システム１１２０を含む。処理システム１１２０は、メモリ１１１０、（１つ以上のバッテリを含む）電源１１２５、オーディオ入出力１１４０、ディスプレイコントローラ及びディスプレイデバイス１１６０、任意の入出力１１５０、入力デバイス１１７０、及び無線送受信機１１３０に連結されている。図１１には図示されない追加の構成要素も、本発明の特定の実施形態におけるデータ処理システム１１００の一部であってもよく、本発明の特定の実施形態では、図１１に示されているのよりも少数の構成要素が使用されてもよいことが理解されるであろう。それに加えて、図１１には図示されない１つ以上のバスは、当該技術分野において周知であるような様々な構成要素を相互接続するのに使用されてもよいことが理解されるであろう。

【0096】

メモリ１１１０は、データ処理システム１１００による実行のためのデータ及び／又はプログラムを格納してもよい。オーディオ入出力１１４０は、例えば、音楽を再生するためにマイクロフォン及び／又はスピーカを含んでもよく、並びに／あるいはスピーカ及びマイクロフォンを介して電話機能を提供してもよい。ディスプレイコントローラ及びディスプレイデバイス１１６０は、グラフィカルユーザインターフェース（ＧＵＩ）を含んでもよい。無線（例えば、ＲＦ）送受信機１１３０（例えば、ＷｉＦｉ送受信機、赤外線送受信機、ブルートゥース送受信機、無線携帯電話送受信機など）は、他のデータ処理システムと通信するのに使用されてもよい。１つ以上の入力デバイス１１７０によって、ユーザがシステムに入力を提供することが可能になる。これらの入力デバイスは、キーパッド、キーボード、タッチパネル、マルチタッチパネルなどであってもよい。他の任意の入出力１１５０は、ドック用コネクタであってもよい。

【0097】

上述したように、本発明の実施形態は様々な工程を含んでもよい。工程は、汎用又は専用プロセッサに特定の工程を実行させる機械実行可能命令の形で具現化されてもよい。あるいは、これらの工程は、工程を実行するためのハードワイヤードロジックを含む特定のハードウェア構成要素によって、又はプログラミングされたコンピュータ構成要素及びカスタムハードウェア構成要素の任意の組み合わせによって実行されてもよい。

【0098】

本発明の要素はまた、機械実行可能プログラムコードを格納するための機械可読媒体として提供されてもよい。機械可読媒体としては、フロッピーディスク、光ディスク、ＣＤ−ＲＯＭ、及び光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気若しくは光カード、又は電子プログラムコードを格納するのに適した他の種類の媒体／機械可読媒体を挙げることができるが、これらに限定されない。

【0099】

上述の説明全体を通じて、説明目的で、本発明の完全な理解を提供するために多数の具体的な詳細を記載した。しかしながら、本発明は、これらの具体的な詳細の一部がなくても実施されてもよいことが、当業者には明白となるであろう。例えば、本明細書に記載した機能モジュール及び方法は、ソフトウェア、ハードウェア、又はそれらの任意の組み合わせとして実装されてもよいことが、当業者にとって容易に明白となるであろう。更に、本発明のいくつかの実施形態は、モバイルコンピューティング環境との関連で本明細書に記載しているが、本発明の基本原理は、モバイルコンピューティングの実装例に限定されない。例えば、デスクトップ又はワークステーションコンピュータを含む、実質的にあらゆる種類のクライアント又はピアデータ処理デバイスが、いくつかの実施形態で使用されてもよい。したがって、本発明の範囲及び趣旨は、以下の特許請求の範囲の観点から判断されるべきである。

【0100】

上述したように、本発明の実施形態は様々な工程を含んでもよい。工程は、汎用又は専用プロセッサに特定の工程を実行させる機械実行可能命令の形で具現化されてもよい。あるいは、これらの工程は、工程を実行するためのハードワイヤードロジックを含む特定のハードウェア構成要素によって、又はプログラミングされたコンピュータ構成要素及びカスタムハードウェア構成要素の任意の組み合わせによって実行されてもよい。

【図1】

【図2A】

【図2B】

【図2C】

【図3A】

【図3B】

【図4】

【図5A】

【図5B】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】