特表 2022-545659 承諾アーキテクチャ用の認証アプリ

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-10-28

(54)【発明の名称】承諾アーキテクチャ用の認証アプリ

(51)【国際特許分類】

   H04L 9/32 20060101AFI20221021BHJP

   G06F 21/31 20130101ALI20221021BHJP

   G06F 21/60 20130101ALI20221021BHJP

   G06F 21/62 20130101ALI20221021BHJP

   G06Q 20/38 20120101ALI20221021BHJP

【ＦＩ】

H04L9/32 100A

G06F21/31

G06F21/60 320

G06F21/62 345

H04L9/32 200B

H04L9/32 200F

G06Q20/38 310

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2022510912

(86)(22)【出願日】2019-08-21

(85)【翻訳文提出日】2022-04-12

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

(87)【国際公開番号】W WO2021034322

(87)【国際公開日】2021-02-25

(81)【指定国・地域】

(71)【出願人】

【識別番号】502208397

【氏名又は名称】グーグル エルエルシー

【氏名又は名称原語表記】Ｇｏｏｇｌｅ ＬＬＣ

【住所又は居所原語表記】１６００ Ａｍｐｈｉｔｈｅａｔｒｅ Ｐａｒｋｗａｙ ９４０４３ Ｍｏｕｎｔａｉｎ Ｖｉｅｗ， ＣＡ Ｕ．Ｓ．Ａ．

(74)【代理人】

【識別番号】100142907

【弁理士】

【氏名又は名称】本田 淳

(72)【発明者】

【氏名】ジア、ハニア

(72)【発明者】

【氏名】カンナー、ヘマン

(72)【発明者】

【氏名】チャタルジー、アニメシュ

(72)【発明者】

【氏名】パリク、スタヴァン

(72)【発明者】

【氏名】ケディア、リディマ

(72)【発明者】

【氏名】イアマンディ、ボグダン ブリンザレア

【テーマコード（参考）】

5L055

【Ｆターム（参考）】

5L055AA73

(57)【要約】

操作リクエスト（１４２）を取得する工程であって、前記操作リクエストは、サービスアプリケーション（１４０）がリモートエンティティ（１３０）にアクセスして操作（１３８）を行うことを要求する、工程を備える、承諾アーキテクチャ内の認証操作のための方法（１０００）。前記方法は、前記サービスアプリケーションが認証リクエスト（１５２）を発行する工程であって、前記認証リクエストは、前記リモートエンティティが前記操作を行う前に、前記認証アプリケーション（１５０）が前記ユーザ（１２）を認証するためにユーザ認証クレデンシャル（１５４）を取得することを要求する、工程も備える。前記方法は、前記認証アプリケーションが、取得された前記ユーザ認証クレデンシャルを前記リモートエンティティの公開鍵（１３２）を用いて暗号化する工程も備える。前記サービスアプリケーションは、前記ユーザ認証クレデンシャルを暗号化されていない形式にて取得することを制限される。前記方法はまた、前記認証アプリケーションが、暗号化された前記ユーザ認証クレデンシャルを前記サービスアプリケーションに提供する工程と、前記サービスアプリケーションが、前記リモートエンティティに対し、前記操作リクエストおよび暗号化された前記ユーザ認証クレデンシャルを送信する工程と、を備える。

【特許請求の範囲】

【請求項1】

方法（１０００）であって、
サービスアプリケーション（１４０）と認証アプリケーション（１５０）とを実行するユーザデバイス（１０）のデータ処理ハードウェア（３０）にて操作リクエスト（１４２）を取得する工程であって、前記操作リクエスト（１４２）は、前記サービスアプリケーション（１４０）がリモートエンティティ（１３０）にアクセスして操作（１３８）を行うことを要求し、前記操作リクエスト（１４２）は、
前記リモートエンティティ（１３０）を識別するリモートエンティティ識別子（１４２ａ）と、
前記操作（１３８）に関連付けられている操作情報（１４２ｂ）と、を含む、工程と、
前記データ処理ハードウェア（３０）上にて実行中の前記サービスアプリケーション（１４０）が認証リクエスト（１５２）を発行する工程であって、前記認証リクエスト（１５２）は、前記リモートエンティティ（１３０）が前記操作（１３８）を行う前に、前記認証アプリケーション（１５０）がユーザ（１２）を認証するために前記リモートエンティティ（１３０）に関連付けられている前記ユーザデバイス（１０）の前記ユーザ（１２）のユーザ認証クレデンシャル（１５４）を取得することを要求する、工程と、
前記サービスアプリケーション（１４０）が前記ユーザ認証クレデンシャル（１５４）を暗号化されていない形式にて取得することを制限するように、前記データ処理ハードウェア（３０）上にて実行中の前記認証アプリケーション（１５０）が、取得された前記ユーザ認証クレデンシャル（１５４）を前記リモートエンティティ（１３０）の公開鍵（１３２）を用いて暗号化する、ユーザ認証クレデンシャル暗号化工程と、
前記データ処理ハードウェア（３０）上にて実行中の前記認証アプリケーション（１５０）が、暗号化された前記ユーザ認証クレデンシャル（１５４）を前記サービスアプリケーション（１４０）に提供する工程と、
前記データ処理ハードウェア（３０）上にて実行中の前記サービスアプリケーション（１４０）が、前記リモートエンティティ（１３０）に対し、前記操作リクエスト（１４２）および暗号化された前記ユーザ認証クレデンシャル（１５４）を送信する工程であって、前記操作リクエスト（１４２）および暗号化された前記ユーザ認証クレデンシャル（１５４）は、前記リモートエンティティ（１３０）によって受信されたとき、前記リモートエンティティ（１３０）に、
暗号化された前記ユーザ認証クレデンシャル（１５４）を、前記リモートエンティティ（１３０）の秘密鍵（１３３）を用いて、復号する工程と、
復号された前記ユーザ認証クレデンシャル（１５４）をバリデーションする工程と、を行わせる、送信工程と、を備える方法（１０００）。

【請求項2】

前記サービスアプリケーション（１４０）は、決済アプリケーション（１４０Ｐ）を含み、
前記リモートエンティティ（１３０）は、前記ユーザ（１２）に関連付けられている金融機関（１３０Ｆ）を含み、
前記サービスアプリケーション（１４０）が前記リモートエンティティ（１３０）にアクセスすることを要求する前記操作リクエスト（１４２）は、前記決済アプリケーション（１４０Ｐ）が前記金融機関（１３０Ｆ）から受取人への電子決済を開始することを要求する電子決済リクエスト（１４２Ｐ）を含む、請求項１に記載の方法（１０００）。

【請求項3】

前記操作情報（１４２ｂ）は、前記電子決済の明細、前記電子決済の値／金額、前記金融機関（１３０Ｆ）における前記ユーザ（１２）に関連付けられている口座を識別する一意口座識別子の少なくとも一部、および前記受取人を識別する受取人識別子、のうちの１つ以上を含む、請求項２に記載の方法（１０００）。

【請求項4】

前記リモートエンティティ（１３０）は、前記ユーザ（１２）に関連付けられている個人情報（４２０）を記憶する記録データストア（４１０）を備え、
前記サービスアプリケーション（１４０）が前記リモートエンティティ（１３０）にアクセスすることを要求する前記操作リクエスト（１４２）は、前記サービスアプリケーション（１４０）が前記記録データストア（４１０）から前記個人情報（４２０）の少なくとも一部を取り出すことを要求する情報取出リクエスト（１４２Ｒ）を含む、請求項１～３のいずれか一項に記載の方法（１０００）。

【請求項5】

前記個人情報（４２０）は、前記ユーザ（１２）に関連付けられている個人記録を含む、請求項４に記載の方法（１０００）。

【請求項6】

前記ユーザ認証クレデンシャル暗号化工程の後、前記データ処理ハードウェア（３０）上にて実行中の前記認証アプリケーション（１５０）が、暗号化された前記ユーザ認証クレデンシャル（１５４）を、前記リモートエンティティ（３０）の検証ネットワーク（２２０）に関連付けられている公開鍵（２２２）を用いて再び暗号化する工程をさらに備える、請求項１～５のいずれか一項に記載の方法（１０００）。

【請求項7】

前記ユーザ認証クレデンシャル暗号化工程の後、前記データ処理ハードウェア（３０）上にて実行中の前記認証アプリケーション（１５０）が、暗号化された前記ユーザ認証クレデンシャル（１５４）を、前記ユーザデバイス（１０）の秘密鍵（６０６Ｒ）を用いて署名する工程をさらに備える、請求項１～６のいずれか一項に記載の方法（１０００）。

【請求項8】

前記ユーザデバイス（１０）の公開鍵（６０６Ｕ）は、前記リモートエンティティ（１３０）に登録されており、前記ユーザデバイス（１０）の前記公開鍵（６０６Ｕ）は、前記ユーザデバイス（１０）の前記秘密鍵（６０６Ｒ）に対応するとともに、暗号化された前記ユーザ認証クレデンシャル（１５４）の署名を検証するために前記リモートエンティティ（１３０）によって用いられる、請求項７に記載の方法（１０００）。

【請求項9】

前記ユーザ認証クレデンシャル暗号化工程は、前記リモートエンティティ（１３０）の前記公開鍵（１３２）を用いて、前記操作リクエスト（１４２）および前記ユーザ認証クレデンシャル（１５４）をともに暗号化する工程をさらに含む、請求項１～８のいずれか一項に記載の方法（１０００）。

【請求項10】

前記ユーザ認証クレデンシャル暗号化工程の前に、前記データ処理ハードウェア（３０）上にて実行中の前記認証アプリケーション（１５０）が、ユーザデバイス（１０）のアンロックチャレンジを前記ユーザ（１２）に発行する工程をさらに備える、請求項１～９のいずれか一項に記載の方法（１０００）。

【請求項11】

前記サービスアプリケーション（１４０）によって発行された前記認証リクエスト（１５２）は、前記ユーザ認証クレデンシャル（１５４）を取得する前に前記認証アプリケーション（１５０）が前記サービスアプリケーション（１４０）をバリデーションするために用いる認証トークン（１５３）を含む、請求項１～１０のいずれか一項に記載の方法（１０００）。

【請求項12】

前記送信工程の後、
前記データ処理ハードウェア（３０）上にて実行中の前記サービスアプリケーション（１４０）にて、チャレンジリクエスト（１４４）を前記リモートエンティティ（１３０）から受信する工程であって、前記チャレンジリクエスト（１４４）は前記ユーザ（１２）からの追加のユーザ認証クレデンシャル（１５４）を要求する、工程と、
前記データ処理ハードウェア（３０）上にて実行中の前記サービスアプリケーション（１４０）が、前記認証アプリケーション（１５０）を呼び出して前記ユーザ（１２）から前記追加のユーザ認証クレデンシャル（１５４）を取得する工程と、
前記データ処理ハードウェア（３０）上にて実行中の前記認証アプリケーション（１５０）が、取得された前記追加のユーザ認証クレデンシャル（１５４）を、前記リモートエンティティ（１３０）の前記公開鍵（１３２）を用いて暗号化する工程と、
前記データ処理ハードウェア（３０）上にて実行中の前記認証アプリケーション（１５０）が、暗号化された前記追加のユーザ認証クレデンシャル（１５４）を前記サービスアプリケーション（１４０）に提供する工程と、
前記データ処理ハードウェア（３０）上にて実行中の前記サービスアプリケーション（１４０）が、暗号化された前記追加のユーザ認証クレデンシャル（１５４）を含むチャレンジレスポンス（１５７）を前記リモートエンティティ（１３０）に送信する工程であって、前記チャレンジレスポンス（１５７）は、前記リモートエンティティ（１３０）によって受信されたとき、前記リモートエンティティ（１３０）に
暗号化された前記追加のユーザ認証クレデンシャル（１５４）を、前記リモートエンティティ（１３０）の前記秘密鍵（１３３）を用いて復号する工程と、
復号された前記追加のユーザ認証クレデンシャル（１５４）をバリデーションする工程と、を行わせる、工程と、をさらに備える、請求項１～１１のいずれか一項に記載の方法（１０００）。

【請求項13】

前記リモートエンティティ（１３０）は、復号された前記ユーザ認証クレデンシャル（１５４）と復号された前記追加のユーザ認証クレデンシャル（１５４）との両方をバリデーションした後、前記操作リクエスト（１４２）に基づいて操作（１３８）を行うように構成されている、請求項１２に記載の方法（１０００）。

【請求項14】

前記リモートエンティティ（１３０）は、復号された前記ユーザ認証クレデンシャル（１５４）をバリデーションした後、電子決済を受取人に転送するように構成されている、請求項１～１３のいずれか一項に記載の方法（１０００）。

【請求項15】

前記データ処理ハードウェア（３０）上にて実行中の前記認証アプリケーション（１５０）が、前記ユーザ（１２）のアイデンティティを前記ユーザデバイス（１０）に結合するユーザアイデンティティ結合工程をさらに備え、前記ユーザアイデンティティ結合工程は、
サービス登録リクエスト（６０２）を、前記データ処理ハードウェア（３０）上にて実行中の前記サービスアプリケーション（１４０）から受信する工程であって、前記サービス登録リクエスト（６０２）はユーザ識別情報（６０４ｂ）およびサービスアプリケーション識別情報（６０４ａ）を含み、前記ユーザ識別情報（６０４ｂ）は前記サービスアプリケーション（１４０）に対し前記ユーザ（１２）を一意に識別し、前記サービスアプリケーション識別情報（６０４ａ）は前記認証アプリケーション（１５０）に対し前記サービスアプリケーション（１４０）を一意に識別する、工程と、
デバイスバウンドキーペア（６０６）を生成する工程であって、前記デバイスバウンドキーペア（６０６）は、前記ユーザ識別情報（６０４ｂ）および前記サービスアプリケーション識別情報（６０４ａ）に基づくデバイス公開鍵（６０６Ｕ）およびデバイス秘密鍵（６０６Ｒ）を備える、工程と、
前記デバイス秘密鍵（６０６Ｒ）を用いて前記サービスアプリケーション識別情報（６０４ａ）に署名する工程と、
前記デバイス公開鍵（６０６Ｕ）および署名された前記サービスアプリケーション識別情報（６０４ａ）を前記リモートエンティティ（１３０）に送る工程と、を備える、請求項１～１４のいずれか一項に記載の方法（１０００）。

【請求項16】

前記データ処理ハードウェア（３０）上にて実行中の前記認証アプリケーション（１５０）が、前記ユーザ（１２）および前記リモートエンティティ（１３０）に関連付けられているユーザ口座（１３７）を前記ユーザデバイス（１０）と結合するユーザ口座結合工程をさらに備え、前記ユーザ口座結合工程は、
前記デバイス秘密鍵（６０６Ｒ）により前記サービスアプリケーション識別情報（６０４ａ）に署名する工程と、
署名された前記サービスアプリケーション識別情報（６０４ａ）を、前記データ処理ハードウェア（３０）上にて実行中の前記サービスアプリケーション（１４０）に送る工程であって、署名された前記サービスアプリケーション識別情報（６０４ａ）は、前記サービスアプリケーション（１４０）によって受信されたとき、前記サービスアプリケーション（１４０）に、署名された前記サービスアプリケーション識別情報（６０４ａ）および口座識別情報（９０９）を前記リモートエンティティ（１３０）に対し送らせ、前記口座識別情報（９０９）は前記ユーザ口座（１３７）を一意に識別する、工程と、を備える、請求項１５に記載の方法（１０００）。

【請求項17】

前記サービスアプリケーション（１４０）および前記認証アプリケーション（１５０）が実行しているとき、
前記データ処理ハードウェア（３０）が、１つまたは複数の追加のサービスアプリケーション（１４０）を実行させる工程であって、各追加のサービスアプリケーション（１４０）は、
対応操作リクエスト（１４２）を受信する工程であって、前記対応操作リクエスト（１４２）は、前記追加のサービスアプリケーション（１４０）が同一のリモートエンティティ（１３０）または異なるリモートエンティティ（１３０）にアクセスして対応する操作（１３８）を行うことを要求する、工程と、
対応認証リクエスト（１５２）を発行する工程であって、前記対応認証リクエスト（１５２）は、同一のリモートエンティティ（１３０）または異なるリモートエンティティ（１３０）が前記操作（１３８）を行う前に、前記認証アプリケーション（１５０）が前記ユーザ（１２）を認証するために前記ユーザ（１２）の前記ユーザ認証クレデンシャル（１５４）を取得することを要求する、工程と、
前記追加のサービスアプリケーション（１４０）が前記ユーザ認証クレデンシャル（１５４）を暗号化されていない形式にて取得することを制限するように、暗号化された前記ユーザ認証クレデンシャル（１５４）を前記認証アプリケーション（１５０）から受信する工程と、を行うように構成されている、工程をさらに備える、請求項１～１６のいずれか一項に記載の方法（１０００）。

【請求項18】

システム（１００）であって、
サービスアプリケーション（１４０）と認証アプリケーション（１５０）とを実行するユーザデバイス（１０）のデータ処理ハードウェア（３０）と、
前記データ処理ハードウェア（３０）と通信するメモリハードウェア（２０）であって、前記データ処理ハードウェア（３０）上における実行時、前記データ処理ハードウェア（３０）に、
操作リクエスト（１４２）を取得する工程であって、前記操作リクエスト（１４２）は、前記サービスアプリケーション（１４０）がリモートエンティティ（１３０）にアクセスして操作（１３８）を行うことを要求し、前記操作リクエスト（１４２）は、
前記リモートエンティティ（１３０）を識別するリモートエンティティ識別子（１４２ａ）と、
前記操作（１３８）に関連付けられている操作情報（１４２ｂ）と、を含む、工程と、
前記サービスアプリケーション（１４０）が認証リクエスト（１５２）を発行する工程であって、前記認証リクエスト（１５２）は、前記リモートエンティティ（１３０）が前記操作（１３８）を行う前に、前記認証アプリケーション（１５０）がユーザ（１２）を認証するために前記リモートエンティティ（１３０）に関連付けられている前記ユーザデバイス（１０）の前記ユーザ（１２）のユーザ認証クレデンシャル（１５４）を取得することを要求する、工程と、
前記サービスアプリケーション（１４０）が前記ユーザ認証クレデンシャル（１５４）を暗号化されていない形式にて取得することを制限するように、前記認証アプリケーション（１５０）が、取得された前記ユーザ認証クレデンシャル（１５４）を前記リモートエンティティ（１３０）の公開鍵（１３２）を用いて暗号化する、ユーザ認証クレデンシャル暗号化工程と、
前記認証アプリケーション（１５０）が、暗号化された前記ユーザ認証クレデンシャル（１５４）を前記サービスアプリケーション（１４０）に提供する工程と、
前記サービスアプリケーション（１４０）が、前記リモートエンティティ（１３０）に対し、前記操作リクエスト（１４２）および暗号化された前記ユーザ認証クレデンシャル（１５４）を送信する工程であって、前記操作リクエスト（１４２）および暗号化された前記ユーザ認証クレデンシャル（１５４）は、前記リモートエンティティ（１３０）によって受信されたとき、前記リモートエンティティ（１３０）に、
暗号化された前記ユーザ認証クレデンシャル（１５４）を、前記リモートエンティティ（１３０）の秘密鍵（１３３）を用いて、復号する工程と、
復号された前記ユーザ認証クレデンシャル（１５４）をバリデーションする工程と、を行わせる、送信工程と、を備える動作を行わせる命令を記憶する、メモリハードウェア（２０）と、を備えるシステム（１００）。

【請求項19】

前記サービスアプリケーション（１４０）は、決済アプリケーション（１４０Ｐ）を含み、
前記リモートエンティティ（１３０）は、前記ユーザ（１２）に関連付けられている金融機関（１３０Ｆ）を含み、
前記サービスアプリケーション（１４０）が前記リモートエンティティ（１３０）にアクセスすることを要求する前記操作リクエスト（１４２）は、前記決済アプリケーション（１４０Ｐ）が前記金融機関（１３０Ｆ）から受取人への電子決済を開始することを要求する電子決済リクエスト（１４２Ｐ）を含む、請求項１８に記載のシステム（１００）。

【請求項20】

前記操作情報（１４２ｂ）は、前記電子決済の明細、前記電子決済の値／金額、前記金融機関（１３０Ｆ）における前記ユーザ（１２）に関連付けられている口座を識別する一意口座識別子の少なくとも一部、および前記受取人を識別する受取人識別子、のうちの１つ以上を含む、請求項１８に記載のシステム（１００）。

【請求項21】

前記リモートエンティティ（１３０）は、前記ユーザ（１２）に関連付けられている個人情報（４２０）を記憶する記録データストア（４１０）を備え、
前記サービスアプリケーション（１４０）が前記リモートエンティティ（１３０）にアクセスすることを要求する前記操作リクエスト（１４２）は、前記サービスアプリケーション（１４０）が前記記録データストア（４１０）から前記個人情報（４２０）の少なくとも一部を取り出すことを要求する情報取出リクエスト（１４２Ｒ）を含む、請求項１８～２０のいずれか一項に記載のシステム（１００）。

【請求項22】

前記個人情報（４２０）は、前記ユーザ（１２）に関連付けられている個人記録を含む、請求項２１に記載のシステム（１００）。

【請求項23】

前記ユーザ認証クレデンシャル暗号化工程の後、前記認証アプリケーション（１５０）が、暗号化された前記ユーザ認証クレデンシャル（１５４）を、前記リモートエンティティ（３０）の検証ネットワーク（２２０）に関連付けられている公開鍵（２２２）を用いて再び暗号化する工程をさらに備える、請求項１７～２１のいずれか一項に記載のシステム（１００）。

【請求項24】

前記ユーザ認証クレデンシャル暗号化工程の後、前記認証アプリケーション（１５０）が、暗号化された前記ユーザ認証クレデンシャル（１５４）を、前記ユーザデバイス（１０）の秘密鍵（６０６Ｒ）を用いて署名する工程をさらに備える、請求項１８～２３のいずれか一項に記載のシステム（１００）。

【請求項25】

前記ユーザデバイス（１０）の公開鍵（６０６Ｕ）は、前記リモートエンティティ（１３０）に登録されており、前記ユーザデバイス（１０）の前記公開鍵（６０６Ｕ）は、前記ユーザデバイス（１０）の前記秘密鍵（６０６Ｒ）に対応するとともに、暗号化された前記ユーザ認証クレデンシャル（１５４）の署名を検証するために前記リモートエンティティ（１３０）によって用いられる、請求項２４に記載のシステム（１００）。

【請求項26】

前記ユーザ認証クレデンシャル暗号化工程は、前記リモートエンティティ（１３０）の前記公開鍵（１３２）を用いて、前記操作リクエスト（１４２）および前記ユーザ認証クレデンシャル（１５４）をともに暗号化する工程をさらに含む、請求項１８～２５のいずれか一項に記載のシステム（１００）。

【請求項27】

前記ユーザ認証クレデンシャル暗号化工程の前に、前記認証アプリケーション（１５０）が、ユーザデバイス（１０）のアンロックチャレンジを前記ユーザ（１２）に発行する工程をさらに備える、請求項１８～２６のいずれか一項に記載のシステム（１００）。

【請求項28】

前記サービスアプリケーション（１４０）によって発行された前記認証リクエスト（１５２）は、前記ユーザ認証クレデンシャル（１５４）を取得する前に前記認証アプリケーション（１５０）が前記サービスアプリケーション（１４０）をバリデーションするために用いる認証トークン（１５３）を含む、請求項１８～２７のいずれか一項に記載のシステム（１００）。

【請求項29】

前記動作は、前記送信工程の後、
前記サービスアプリケーション（１４０）にて、チャレンジリクエスト（１４４）を前記リモートエンティティ（１３０）から受信する工程であって、前記チャレンジリクエスト（１４４）は前記ユーザ（１２）からの追加のユーザ認証クレデンシャル（１５４）を要求する、工程と、
前記サービスアプリケーション（１４０）が、前記認証アプリケーション（１５０）を呼び出し、前記ユーザ（１２）から前記追加のユーザ認証クレデンシャル（１５４）を取得する工程と、
前記認証アプリケーション（１５０）が、取得された前記追加のユーザ認証クレデンシャル（１５４）を、前記リモートエンティティ（１３０）の前記公開鍵（１３２）を用いて暗号化する工程と、
前記認証アプリケーション（１５０）が、暗号化された前記追加のユーザ認証クレデンシャル（１５４）を前記サービスアプリケーション（１４０）に提供する工程と、
前記サービスアプリケーション（１４０）が、暗号化された前記追加のユーザ認証クレデンシャル（１５４）を含むチャレンジレスポンス（１５７）を前記リモートエンティティ（１３０）に送信する工程であって、前記チャレンジレスポンス（１５７）は、前記リモートエンティティ（１３０）によって受信されたとき、前記リモートエンティティ（１３０）に
暗号化された前記追加のユーザ認証クレデンシャル（１５４）を、前記リモートエンティティ（１３０）の前記秘密鍵（１３３）を用いて復号する工程と、
復号された前記追加のユーザ認証クレデンシャル（１５４）をバリデーションする工程と、を行わせる、工程と、をさらに備える、請求項１８～２８のいずれか一項に記載のシステム（１００）。

【請求項30】

前記リモートエンティティ（１３０）は、復号された前記ユーザ認証クレデンシャル（１５４）と復号された前記追加のユーザ認証クレデンシャル（１５４）との両方をバリデーションした後、前記操作リクエスト（１４２）に基づいて操作（１３８）を行うように構成されている、請求項２９に記載のシステム（１００）。

【請求項31】

前記リモートエンティティ（１３０）は、復号された前記ユーザ認証クレデンシャル（１５４）をバリデーションした後、電子決済を受取人に転送するように構成されている、請求項１８～３０のいずれか一項に記載のシステム（１００）。

【請求項32】

前記認証アプリケーション（１５０）が、前記ユーザ（１２）のアイデンティティを前記ユーザデバイス（１０）に結合するユーザアイデンティティ結合工程をさらに備え、前記ユーザアイデンティティ結合工程は、
サービス登録リクエスト（６０２）を、前記サービスアプリケーション（１４０）から受信する工程であって、前記サービス登録リクエスト（６０２）はユーザ識別情報（６０４ｂ）およびサービスアプリケーション識別情報（６０４ａ）を含み、前記ユーザ識別情報（６０４ｂ）は前記サービスアプリケーション（１４０）に対し前記ユーザ（１２）を一意に識別し、前記サービスアプリケーション識別情報（６０４ａ）は前記認証アプリケーション（１５０）に対し前記サービスアプリケーション（１４０）を一意に識別する、工程と、
デバイスバウンドキーペア（６０６）を生成する工程であって、前記デバイスバウンドキーペア（６０６）は、前記ユーザ識別情報（６０４ｂ）および前記サービスアプリケーション識別情報（６０４ａ）に基づくデバイス公開鍵（６０６Ｕ）およびデバイス秘密鍵（６０６Ｒ）を備える、工程と、
前記デバイス秘密鍵（６０６Ｒ）を用いて前記サービスアプリケーション識別情報（６０４ａ）に署名する工程と、
前記デバイス公開鍵（６０６Ｕ）および署名された前記サービスアプリケーション識別情報（６０４ａ）を前記リモートエンティティ（１３０）に送る工程と、を備える、請求項１８～３１のいずれか一項に記載のシステム（１００）。

【請求項33】

前記認証アプリケーション（１５０）が、前記ユーザ（１２）および前記リモートエンティティ（１３０）に関連付けられているユーザ口座（１３７）を前記ユーザデバイス（１０）と結合するユーザ口座結合工程をさらに備え、前記ユーザ口座結合工程は、
前記デバイス秘密鍵（６０６Ｒ）により前記サービスアプリケーション識別情報（６０４ａ）に署名する工程と、
署名された前記サービスアプリケーション識別情報（６０４ａ）を前記サービスアプリケーション（１４０）に送る工程であって、署名された前記サービスアプリケーション識別情報（６０４ａ）は、前記サービスアプリケーション（１４０）によって受信されたとき、前記サービスアプリケーション（１４０）に、署名された前記サービスアプリケーション識別情報（６０４ａ）および口座識別情報（９０９）を前記リモートエンティティ（１３０）に対し送らせ、前記口座識別情報（９０９）は前記ユーザ口座（１３７）を一意に識別する、工程と、を備える、請求項３２に記載のシステム（１００）。

【請求項34】

前記動作は、前記サービスアプリケーション（１４０）および前記認証アプリケーション（１５０）が実行しているとき、
１つまたは複数の追加のサービスアプリケーション（１４０）を実行させる工程であって、各追加のサービスアプリケーション（１４０）は、
対応操作リクエスト（１４２）を受信する工程であって、前記対応操作リクエスト（１４２）は、前記追加のサービスアプリケーション（１４０）が同一のリモートエンティティ（１３０）または異なるリモートエンティティ（１３０）にアクセスして対応する操作（１３８）を行うことを要求する、工程と、
対応認証リクエスト（１５２）を発行する工程であって、前記対応認証リクエスト（１５２）は、同一のリモートエンティティ（１３０）または異なるリモートエンティティ（１３０）が前記操作（１３８）を行う前に、前記認証アプリケーション（１５０）が前記ユーザ（１２）を認証するために前記ユーザ（１２）の前記ユーザ認証クレデンシャル（１５４）を取得することを要求する、工程と、
前記追加のサービスアプリケーション（１４０）が前記ユーザ認証クレデンシャル（１５４）を暗号化されていない形式にて取得することを制限するように、暗号化された前記ユーザ認証クレデンシャル（１５４）を前記認証アプリケーション（１５０）から受信する工程と、を行うように構成されている、工程をさらに備える、請求項１９～３４のいずれか一項に記載のシステム（１００）。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、任意の数のアプリケーション用のセキュアな認証用のクロスアプリケーション認証アプリケーションに関する。

【背景技術】

【0002】

リアルタイム決済（ＲＴＰ）は、受取人が、送信側金融機関が取引を開始して数秒内に（すなわち、「リアルタイム」に）支払いを受けることを可能にする金融取引である。これらの決済システムは、典型的には、両替および清算を扱うクレジットカードネットワークと同様に、イシュア間の金銭を行う中央当局である、ＲＴＰネットワークによって維持されることが多い。ＲＴＰは、金融機関におけるあるユーザの口座から異なるまたは同一の金融機関における別のユーザの口座へと即座に送金する決済アプリケーション（アプリ）を実行させる、ユーザデバイス（例えば、携帯電話）によって行われることが多い。これらの決済アプリは、通常、アプリケーションプログラミングインタフェース（ＡＰＩ）を介してＲＴＰネットワークに対するアクセスを得る。ＲＴＰは、一般に大幅に増加しており、取引の数が急上昇していることにより、競合する決済アプリケーションの数が同様に増加している。ユーザが同一のユーザデバイス上に複数の独立した決済アプリ（各決済アプリはユーザの口座の１つまたは複数にアクセスするように認可されている）を有することは普通ではない。

【発明の概要】

【0003】

本開示の１つの態様は、承諾アーキテクチャ内の認証操作の方法を提供する。方法は、サービスアプリケーションと認証アプリケーションとを実行するユーザデバイスのデータ処理ハードウェアにて操作リクエストを取得する工程であって、前記操作リクエストは、前記サービスアプリケーションがリモートエンティティにアクセスして操作を行うことを要求する、工程を備える。前記操作リクエストは、リモートエンティティを識別するリモートエンティティ識別子と、前記操作に関連付けられている操作情報と、を含む。方法は、前記データ処理ハードウェア上にて実行中の前記サービスアプリケーションが認証リクエストを発行する工程であって、前記認証リクエストは、前記リモートエンティティが前記操作を行う前に、前記認証アプリケーションが前記ユーザを認証するために前記リモートエンティティに関連付けられている前記ユーザデバイスのユーザのユーザ認証クレデンシャルを取得することを要求する、工程も含む。方法は、前記サービスアプリケーションが前記ユーザ認証クレデンシャルを暗号化されていない形式にて取得することを制限するように、前記データ処理ハードウェア上にて実行中の前記認証アプリケーションが、取得された前記ユーザ認証クレデンシャルを前記リモートエンティティの公開鍵を用いて暗号化する、ユーザ認証クレデンシャル暗号化工程も含む。方法はまた、前記データ処理ハードウェア上にて実行中の前記認証アプリケーションが、暗号化された前記ユーザ認証クレデンシャルを前記サービスアプリケーションに提供する工程と、前記データ処理ハードウェア上にて実行中の前記サービスアプリケーションが、前記リモートエンティティに対し、前記操作リクエストおよび暗号化された前記ユーザ認証クレデンシャルを送信する工程と、を含む。前記操作リクエストおよび暗号化された前記ユーザ認証クレデンシャルは、前記リモートエンティティよって受信されたとき、前記リモートエンティティに、暗号化された前記ユーザ認証クレデンシャルを、前記リモートエンティティの秘密鍵を用いて、復号する工程と、復号された前記ユーザ認証クレデンシャルをバリデーションする工程と、を行わせる。

【0004】

本開示の実装は、以下の随意の特徴のうちの１つまたは複数を含んでよい。いくつかの実装では、前記サービスアプリケーションは、決済アプリケーションを含み、前記リモートエンティティは、前記ユーザに関連付けられている金融機関を含む。前記サービスアプリケーションが前記リモートエンティティにアクセスすることを要求する前記操作リクエストは、前記決済アプリケーションが前記金融機関から受取人への電子決済を開始することを要求する電子決済リクエストを含む。いくつかの例では、前記操作情報は、前記電子決済の明細、前記電子決済の値／金額、前記金融機関における前記ユーザに関連付けられている口座を識別する一意口座識別子の少なくとも一部、および前記受取人を識別する受取人識別子、のうちの１つ以上を含む。

【0005】

随意では、前記リモートエンティティは、前記ユーザに関連付けられている個人情報を記憶する記録データストアを備え、前記サービスアプリケーションが前記リモートエンティティにアクセスすることを要求する前記操作リクエストは、前記サービスアプリケーションが前記記録データストアから前記個人情報の少なくとも一部を取り出すことを要求する情報取出リクエストを含む。前記個人情報は、前記ユーザに関連付けられている個人記録を含む。個人情報は、ユーザが秘密にしておくことを望む情報、またはサービスプロバイダが秘密にしておく義務を有する情報であり得る。いくつかの実装では、前記ユーザ認証クレデンシャル暗号化工程の後、前記データ処理ハードウェア上にて実行中の前記認証アプリケーションが、暗号化された前記ユーザクレデンシャルを、前記リモートエンティティの検証ネットワークに関連付けられている公開鍵を用いて再び暗号化する工程をさらに備える。

【0006】

いくつかの例では、方法は、前記ユーザ認証クレデンシャル暗号化工程の後、前記データ処理ハードウェア上にて実行中の前記認証アプリケーションが、暗号化された前記ユーザクレデンシャルを、前記ユーザデバイスの秘密鍵を用いて署名する工程をさらに備える。前記ユーザデバイスの公開鍵は、前記リモートエンティティに登録されていてよい。前記ユーザデバイスの前記公開鍵は、前記ユーザデバイスの前記秘密鍵に対応するとともに、暗号化された前記ユーザ認証クレデンシャルの署名を検証するために前記リモートエンティティによって用いられる。随意では、前記ユーザ認証クレデンシャル暗号化工程は、前記リモートエンティティの前記公開鍵を用いて、前記操作リクエストおよび前記ユーザ認証クレデンシャルをともに暗号化する工程をさらに含む。

【0007】

いくつかの実装では、前記ユーザ認証クレデンシャル暗号化工程の前に、前記データ処理ハードウェア上にて実行中の前記認証アプリケーションが、ユーザデバイスのアンロックチャレンジを前記ユーザに発行する工程をさらに備える。前記サービスアプリケーションによって発行された前記認証リクエストは、前記ユーザ認証クレデンシャルを取得する前に前記認証アプリケーションが前記サービスアプリケーションをバリデーションするために用いる認証トークンを含む。

【0008】

随意では、方法は、前記送信工程の後、前記データ処理ハードウェア上にて実行中の前記サービスアプリケーションにて、チャレンジリクエストを前記リモートエンティティから受信する工程をさらに備える。前記チャレンジリクエストは前記ユーザからの追加のユーザ認証クレデンシャルを要求する。方法はまた、前記データ処理ハードウェア上にて実行中の前記サービスアプリケーションが、前記認証アプリケーションを呼び出し、前記ユーザから前記追加のユーザ認証クレデンシャルを取得する工程と、前記データ処理ハードウェア上にて実行中の前記認証アプリケーションが、取得された前記追加のユーザ認証クレデンシャルを、前記リモートエンティティの前記公開鍵を用いて暗号化する工程と、を備えてよい。方法はまた、前記データ処理ハードウェア上にて実行中の前記認証アプリケーションが、暗号化された前記追加のユーザ認証クレデンシャルを前記サービスアプリケーションに提供する工程と、前記データ処理ハードウェア上にて実行中の前記サービスアプリケーションが、暗号化された前記追加のユーザ認証クレデンシャルを含むチャレンジレスポンスを前記リモートエンティティに送信する工程と、を備えてよい。前記チャレンジレスポンスは、前記リモートエンティティによって受信されたとき、前記リモートエンティティに暗号化された前記追加のユーザ認証クレデンシャルを、前記リモートエンティティの前記秘密鍵を用いて復号する工程と、復号された前記追加のユーザ認証クレデンシャルをバリデーションする工程と、を行わせる。

【0009】

いくつかの例では、前記リモートエンティティは、復号された前記ユーザ認証クレデンシャルと復号された前記追加のユーザ認証クレデンシャルとの両方をバリデーションした後、前記操作リクエストに基づいて操作を行うように構成されている。前記リモートエンティティは、復号された前記ユーザ認証クレデンシャルをバリデーションした後、電子決済を受取人に転送するように構成されてよい。

【0010】

いくつかの例では、方法は、前記データ処理ハードウェア上にて実行中の前記認証アプリケーションが、アイデンティティを前記ユーザデバイスに結合するユーザアイデンティティ結合工程をさらに備える。前記ユーザアイデンティティ結合工程は、サービス登録リクエストを、前記データ処理ハードウェア上にて実行中の前記サービスアプリケーションから受信する工程を含んでよい。前記サービス登録リクエストはユーザ識別情報およびサービスアプリケーション識別情報を含む。前記ユーザ識別情報は前記サービスアプリケーションに対し前記ユーザを一意に識別し、前記サービスアプリケーション識別情報は前記認証アプリケーションに対する前記サービスアプリケーションを一意に識別する。前記ユーザアイデンティティ結合工程は、デバイスバウンドキーペアを生成する工程も含んでよい。前記デバイスバウンドキーペアは、前記ユーザ識別情報および前記サービスアプリケーション識別情報に基づくデバイス公開鍵およびデバイス秘密鍵を備える。前記ユーザアイデンティティ結合工程は、前記デバイス秘密鍵を用いて前記サービスアプリケーション識別情報に署名する工程と、前記デバイス公開鍵および署名された前記サービスアプリケーション識別情報を前記リモートエンティティに送る工程と、を含んでよい。

【0011】

いくつかの実装では、方法は、前記データ処理ハードウェア上にて実行する前記認証アプリケーションが、前記ユーザおよび前記リモートエンティティに関連付けられているユーザ口座を前記ユーザデバイスと結合するユーザ口座結合工程をさらに備える。前記ユーザ口座結合工程は、前記デバイス秘密鍵により前記サービスアプリケーション識別情報に署名する工程と、署名された前記サービスアプリケーション識別情報を、前記データ処理ハードウェア上にて実行中の前記サービスアプリケーションに送る工程と、を含んでよい。署名された前記サービスアプリケーション識別情報は、前記サービスアプリケーションによって受信されたとき、前記サービスアプリケーションに、署名された前記サービスアプリケーション識別情報および口座識別情報を前記リモートエンティティに対し送らせる。前記口座識別情報は前記ユーザ口座を一意に識別する。

【0012】

いくつかの例では、方法は、前記サービスアプリケーションおよび前記認証アプリケーションが実行しているとき、前記データ処理ハードウェアが、１つまたは複数の追加のサービスアプリケーションを実行させる工程をさらに備える。各追加のサービスアプリケーションは、対応操作リクエストを受信する工程であって、前記対応操作リクエストは、前記追加のサービスアプリケーションが同一のリモートエンティティまたは異なるリモートエンティティにアクセスして対応する操作を行うことを要求するように構成されてよい。各追加のサービスアプリケーションは、対応認証リクエストを発行する工程であって、前記対応認証リクエストは、同一のリモートエンティティまたは異なるリモートエンティティが前記操作を行う前に、前記認証アプリケーションが前記ユーザを認証するために前記ユーザの前記ユーザ認証クレデンシャルを取得することを要求する、工程と、前記追加のサービスアプリケーションが前記ユーザ認証クレデンシャルを暗号化されていない形式にて取得することを制限するように、暗号化された前記ユーザ認証クレデンシャルを前記認証アプリケーションから受信する工程と、を行うように構成されてもよい。

【0013】

本開示の別の態様は、承諾アーキテクチャ内の認証操作のシステムを提供する。システムは、サービスアプリケーションと認証アプリケーションとを実行するユーザデバイスのデータ処理ハードウェアと、前記データ処理ハードウェアと通信するメモリハードウェアと、を備える。前記メモリハードウェアは、前記データ処理ハードウェア上における実行時、前記データ処理ハードウェアに動作を行わせる命令を記憶する。

【0014】

動作は、操作リクエストを取得する工程であって、前記操作リクエストは、前記サービスアプリケーションがリモートエンティティにアクセスして操作を行うことを要求する、工程を備える。前記操作リクエストは、前記リモートエンティティを識別するリモートエンティティ識別子と、前記操作に関連付けられている操作情報と、を含む。動作は、前記サービスアプリケーションが認証リクエストを発行する工程であって、前記認証リクエストは、前記リモートエンティティが前記操作を行う前に、前記認証アプリケーションが前記ユーザを認証するために前記リモートエンティティに関連付けられている前記ユーザデバイスのユーザのユーザ認証クレデンシャルを取得することを要求する工程も備える。動作は、前記サービスアプリケーションが前記ユーザ認証クレデンシャルを暗号化されていない形式にて取得することを制限するように、前記認証アプリケーションが、取得された前記ユーザ認証クレデンシャルを前記リモートエンティティの公開鍵を用いて暗号化する、ユーザ認証クレデンシャル暗号化工程も備える。動作は、前記認証アプリケーションが、暗号化された前記ユーザ認証クレデンシャルを前記サービスアプリケーションに提供する工程と、前記サービスアプリケーションが、前記リモートエンティティに対し、前記操作リクエストおよび暗号化された前記ユーザ認証クレデンシャルを送信する工程と、も備える。前記操作リクエストおよび暗号化された前記ユーザ認証クレデンシャルは、前記リモートエンティティによって受信されたとき、前記リモートエンティティに、暗号化された前記ユーザ認証クレデンシャルを、前記リモートエンティティの秘密鍵を用いて、復号する工程と、復号された前記ユーザ認証クレデンシャルをバリデーションする工程と、を行わせる。

【0015】

この態様は、以下の随意の特徴のうちの１つまたは複数を含んでよい。いくつかの実装では、前記サービスアプリケーションは、決済アプリケーションを含み、前記リモートエンティティは、前記ユーザに関連付けられている金融機関を含む。前記サービスアプリケーションが前記リモートエンティティにアクセスすることを要求する前記操作リクエストは、前記決済アプリケーションが前記金融機関から受取人への電子決済を開始することを要求する電子決済リクエストを含む。いくつかの例では、前記操作情報は、前記電子決済の明細、前記電子決済の値／金額、前記金融機関における前記ユーザに関連付けられている口座を識別する一意口座識別子の少なくとも一部、および前記受取人を識別する受取人識別子、のうちの１つ以上を含む。

【0016】

随意では、前記リモートエンティティは、前記ユーザに関連付けられている個人情報を記憶する記録データストアを備え、前記サービスアプリケーションが前記リモートエンティティにアクセスすることを要求する前記操作リクエストは、前記サービスアプリケーションが前記記録データストアから前記個人情報の少なくとも一部を取り出すことを要求する情報取出リクエストを含む。前記個人情報は、前記ユーザに関連付けられている個人記録を含む。いくつかの実装では、動作は、前記ユーザ認証クレデンシャル暗号化工程の後、前記認証アプリケーションが、暗号化された前記ユーザクレデンシャルを、前記リモートエンティティの検証ネットワークに関連付けられている公開鍵を用いて再び暗号化する工程をさらに備える。

【0017】

いくつかの例では、動作は、前記ユーザ認証クレデンシャル暗号化工程の後、前記認証アプリケーションが、暗号化された前記ユーザクレデンシャルを、前記ユーザデバイスの秘密鍵を用いて署名する工程をさらに備える。前記ユーザデバイスの公開鍵は、前記リモートエンティティに登録されていてよい。前記ユーザデバイスの前記公開鍵は、前記ユーザデバイスの前記秘密鍵に対応するとともに、暗号化された前記ユーザ認証クレデンシャルの署名を検証するために前記リモートエンティティによって用いられる。随意では、前記ユーザ認証クレデンシャル暗号化工程は、前記リモートエンティティの前記公開鍵を用いて、前記操作リクエストおよび前記ユーザ認証クレデンシャルをともに暗号化する工程をさらに含む。

【0018】

いくつかの実装では、動作は、前記ユーザ認証クレデンシャル暗号化工程の前に、前記認証アプリケーションが、ユーザデバイスのアンロックチャレンジを前記ユーザに発行する工程をさらに備える。前記サービスアプリケーションによって発行された前記認証リクエストは、前記ユーザ認証クレデンシャルを取得する前に前記認証アプリケーションが前記サービスアプリケーションをバリデーションするように用いる認証トークンを含む。

【0019】

随意では、動作は、前記送信工程の後、前記サービスアプリケーションにて、チャレンジリクエストを前記リモートエンティティから受信する工程をさらに備える。前記チャレンジリクエストは前記ユーザからの追加のユーザ認証クレデンシャルを要求する。動作はまた、前記サービスアプリケーションが、前記認証アプリケーションを呼び出し、前記ユーザから前記追加のユーザ認証クレデンシャルを取得する工程と、前記認証アプリケーションが、取得された前記追加のユーザ認証クレデンシャルを、前記リモートエンティティの前記公開鍵を用いて暗号化する工程と、を備えてよい。動作はまた、前記認証アプリケーションが、暗号化された前記追加のユーザ認証クレデンシャルを前記サービスアプリケーションに提供する工程と、前記サービスアプリケーションが、暗号化された前記追加のユーザ認証クレデンシャルを含むチャレンジレスポンスを前記リモートエンティティに送信する工程と、を備えてよい。前記チャレンジレスポンスは、前記リモートエンティティによって受信されたとき、前記リモートエンティティに暗号化された前記追加のユーザ認証クレデンシャルを、前記リモートエンティティの前記秘密鍵を用いて復号する工程と、復号された前記追加のユーザ認証クレデンシャルをバリデーションする工程と、を行わせる。

【0020】

いくつかの例では、前記リモートエンティティは、復号された前記ユーザ認証クレデンシャルと復号された前記追加のユーザ認証クレデンシャルとの両方をバリデーションした後、前記操作リクエストに基づいて操作を行うように構成されている。前記リモートエンティティは、復号された前記ユーザ認証クレデンシャルをバリデーションした後、電子決済を受取人に転送するように構成されてよい。

【0021】

いくつかの例では、動作は、前記認証アプリケーションが、アイデンティティを前記ユーザデバイスに結合するユーザアイデンティティ結合工程をさらに備える。前記ユーザアイデンティティ結合工程は、サービス登録リクエストを、前記サービスアプリケーションから受信する工程を含んでよい。前記サービス登録リクエストはユーザ識別情報およびサービスアプリケーション識別情報を含む。前記ユーザ識別情報は前記サービスアプリケーションに対し前記ユーザを一意に識別し、前記サービスアプリケーション識別情報は前記認証アプリケーションに対し前記サービスアプリケーションを一意に識別する。前記ユーザアイデンティティ結合工程は、デバイスバウンドキーペアを生成する工程も含んでよい。前記デバイスバウンドキーペアは、前記ユーザ識別情報および前記サービスアプリケーション識別情報に基づくデバイス公開鍵およびデバイス秘密鍵を備える。前記ユーザアイデンティティ結合工程は、前記デバイス秘密鍵を用いて前記サービスアプリケーション識別情報に署名する工程と、前記デバイス公開鍵および署名された前記サービスアプリケーション識別情報を前記リモートエンティティに送る工程と、を含んでよい。

【0022】

いくつかの実装では、動作は、前記認証アプリケーションが、前記ユーザおよび前記リモートエンティティに関連付けられているユーザ口座を前記ユーザデバイスと結合するユーザ口座結合工程をさらに備える。前記ユーザ口座結合工程は、前記デバイス秘密鍵により前記サービスアプリケーション識別情報に署名する工程と、署名された前記サービスアプリケーション識別情報を、前記サービスアプリケーションに送る工程と、を含んでよい。署名された前記サービスアプリケーション識別情報は、前記サービスアプリケーションによって受信されたとき、前記サービスアプリケーションに、署名された前記サービスアプリケーション識別情報および口座識別情報を前記リモートエンティティに対し送らせる。前記口座識別情報は前記ユーザ口座を一意に識別する。

【0023】

いくつかの例では、動作は、前記サービスアプリケーションおよび前記認証アプリケーションが実行しているとき、１つまたは複数の追加のサービスアプリケーションを実行させる工程をさらに備える。各追加のサービスアプリケーションは、対応操作リクエストを受信する工程であって、前記対応操作リクエストは、前記追加のサービスアプリケーションが同一のリモートエンティティまたは異なるリモートエンティティにアクセスして対応する操作を行うことを要求するように構成されてよい。各追加のサービスアプリケーションは、対応認証リクエストを発行する工程であって、前記対応認証リクエストは、同一のリモートエンティティまたは異なるリモートエンティティが前記操作を行う前に、前記認証アプリケーションが前記ユーザを認証するために前記ユーザの前記ユーザ認証クレデンシャルを取得することを要求する、工程と、前記追加のサービスアプリケーションが前記ユーザ認証クレデンシャルを暗号化されていない形式にて取得することを制限するように、暗号化された前記ユーザ認証クレデンシャルを前記認証アプリケーションから受信する工程と、を行うように構成されてもよい。

【0024】

本開示の１つまたは複数の実装の詳細は、添付の図面および以下の記載において説明される。他の態様、特徴、および利点は、記載および図面から、また特許請求の範囲から明らかとなる。

【図面の簡単な説明】

【0025】

【図1】ユーザデバイスからのリモートエンティティに対するセキュアな認証を提供する、承諾アーキテクチャシステム用の一例としてのオーセンティケータの概略図。

【図2】決済アプリケーションのセキュアな認証を提供する、図１のオーセンティケータの概略図。

【図3】操作リクエストの概略図。

【図4】プライベートデータストアに対するアクセスを有するリモートエンティティの概略図。

【図5A】サービスアプリケーションを実行する、例としてのユーザデバイスの概略図。

【図5B】サービスアプリケーションを実行する、例としてのユーザデバイスの概略図。

【図6】図１の認証アプリケーションおよびサービス登録リクエストの概略図。

【図7】デバイスキーペアを生成するようにユーザに対しチャレンジを発行する、例としてのユーザデバイスの概略図。

【図8A】口座選択を提供するサービスアプリケーションを実行する、例としてのユーザデバイスの概略図。

【図8B】口座選択を提供するサービスアプリケーションを実行する、例としてのユーザデバイスの概略図。

【図9】図１の認証アプリケーションおよび口座登録リクエストの概略図。

【図10】承諾アーキテクチャにおいて認証アプリケーションを提供する方法のための動作の例としての構成のフローチャート。

【図11】本明細書に記載されるシステムおよび方法を実装するように用いられ得るコンピューティングデバイスの概略図。

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

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

多くの実装が記載されている。しかしながら、様々な変更が本開示の趣旨および範囲から逸脱することなくなされ得ることが理解される。したがって、他の実装は以下の特許請求の範囲の範囲内にある。

【図1】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図6】

【図7】

【図8A】

【図8B】

【図9】

【図10】

【図11】

【国際調査報告】