JP2018533131A - 認証サービス顧客データの管理方法及びシステム - Google Patents

Abstract

方法、媒体及びシステムは、認証システムの少なくとも１人の外部ユーザから、前記外部ユーザについての顧客情報を含むレコードであって前記認証システムでの前記少なくとも１人の外部ユーザの少なくとも登録に関連付けられたレコードを受信するステップと、過去の外部ユーザ顧客情報を格納する認証データベースとインタフェース接続するコンピュータによって、前記外部ユーザについての前記顧客情報を含む前記レコードを受信するステップと、前記外部ユーザについての前記顧客情報及び前記過去の外部ユーザ顧客情報とを含む前記レコードを確認するステップと、前記確認されたレコードを示す指示を格納するステップと、についてのプラットフォームに対するものである。

Description

関連出願の相互参照

本願は、米国特許出願第14/857,406号（2015年9月17日出願）の優先権を主張するものであり、当該出願の開示全体をここに参照のために取り込む。

歴史的に、オンラインショッピング状況と他の「カード不在」のトランザクション（取引）とにおける販売者の主な関心や支払装置（例えばクレジットカード又はデビットカード、それらに関連付けられたアプリケーション）の問題は、支払装置の使用を試みる人物が、当該支払装置の認証済みユーザなのか否かである。カード保有者が不在のとき、販売者又は他のエンティティにとって、実際の認証済みカード保有者が本当に購入を認証するか否か（詐欺活動の種別についての何らかの試みではないこと）を確認し又は検証することは困難である。

オンライン購入と「カード不在」のトランザクションとにおける支払装置による詐欺を低減する試みにおいて、多くのシステムが、支払装置を用いる人物が、当該支払装置の認証済みユーザであることを検証するために提案され使用されてきた。これに関して、オンラインのクレジット又はデビットトランザクションに対する追加の安全策を追加するために発展した１つの安全プロトコルは、3-Dセキュリティ（3DS）プロトコルである。これは、購入トランザクションの金融的承認処理を、当該購入トランザクションを完了するユーザ又はアカウントに対するオンライン承認と結びつける。このプロトコルは、カード保有がオンラインで又は他の「カード不在」の状況で、クレジットカードの発行者がカード保有者を承認することを可能にするよう設計された。しかし、3DS及びそれにつき提案された他の承認処理及びシステムは、典型的には閉ループシステムである。これは、複雑で、実装には高価で、主に、カード保有者のアイデンティティを承認することを意図する。

したがって、認証データ（これは、任意選択的に安定し、効率的で且つ拡張可能な購入トランザクションに関連する）の取得及び処理を支援し且つ改良版データ管理機能を含む改良版方法及びシステムを提供することが望ましい。

本発明のいくつかの実施形態の機能及び効果と、それらが実現される方法とは、添付の図面に関連して記載される本発明の下記の詳細な説明を考慮することで容易に自明である。
一般的なカード保有者認証において使用するためのシステムの例示である。 本開示の実施形態による、認証処理のシステムの例示である。 認証処理システムの例示である。これは、本開示の実施形態による、認証関連データの外部ソースとインタフェース接続することを含む。 本開示の実施形態による、認証プラットフォームの論理構造である。 本開示の実施形態による、システムの機能ブロック図である。 本開示の実施形態による、データ交換フローの例示である。 本開示の実施形態による、装置の機能ブロック図である。

概して、また、本開示の概念を導入する目的で、認証セキュリティポリシーは、オンライン電子商取引（e-commerce）環境でのトランザクション中の、カード保有者アカウントの所有権を確認する処理に関する。ここでは、そのトランザクションは購入トランザクションを含んでよい。本開示のように、購入トランザクション、支払トランザクション（又は単にトランザクション）との用語は、別段の定めが無い限り、相互に交換して使用されてよい。概して購入トランザクションとは、カード不在の又はe-commerceのトランザクションを指す。したがって、これらのトランザクションは、販売者又はエンティティによって、カード保有者、ユーザ又は他のエンティティに、支払装置の認証済みユーザとして支払用支払装置又はそのアカウントを提示させるように要求してよい。というのも、例えば、販売者は、ユーザが支払装置を有することを物理的に確認できないからである。

本開示のいくつかの一般的態様によれば、効率的且つ柔軟なデータ管理機能及びメカニズムを含む認証処理、システム及び方法のためにフレームワークが開示される。本開示の認証フレームワーク又はプラットフォームのデータ管理機能及びメカニズムは、新たな顧客登録についての効率的且つ正確な制御及び管理と、認証プラットフォームの請求態様とを提供することを含むがこれに限定されない。いくつかの実施形態では、認証フレームワーク又はプラットフォームは、顧客登録／データ管理及び請求解決策を支援するメカニズムを提供する。これらは将来のビジネスの成長及び顧客の期待へと拡張可能である。いくつかの実施形態では、認証フレームワーク又はプラットフォームは、認証エコシステム内の発行者、支払プロセッサ及び販売者情報の態様に関連するデータの正確な管理を支援し且つ容易にする。

支払装置システム、アプリケーション又はサービスは、認証エコシステム（これは3DS環境を含むがこれに限定されない）内のビジネス、企業又は組織の様々な内外エンティティ（例えばアプリケーション、装置、サービス等）から認証データを収集する。これは、認証サービスを提供し、収集された認証データをデータリポジトリ（例えばデータウェアハウス、ローカル又は分散ストレージ施設及びクラウドを基礎としたストレージ装置）内に収集する。収集された認証データは、ビジネス分析（例えば、企業又は他のビジネス組織の内外の顧客へのビジネス報告）の基礎として使用されてよい。収集された認証データに基づく分析は、いくつかの実施形態では、トランザクションの詐欺スコアリング目的で使用されてよい。いくつかの実施形態では、収集された認証データから導出されるデータは共有され、データウェアハウス内でトランザクションデータ（例えば購入認証データ）と組合せて使用されてよく、エンドツーエンドのトランザクションライフサイクルの外観を提供してよい。

本開示は、少なくとも部分的に、認証データを含むトランザクションのエンドツーエンド又は完全な外観を報告する処理及びシステムを提供する。当該認証データは、クレジット又は他の種別のトランザクションの認証及び処理において使用される。判定され、処理され、収集され、分析され、及び格納された認証データは、ビジネス及び他のエンティティへ、価値のある洞察を提供するために使用されてよい。そのような洞察は、トランザクションパターン、認証傾向及びパターン、カード発行者認証の成功又は失敗率、特定のカード範囲又は領域内での複数の失敗による詐欺についての指示子、認証放棄についてのカード保有者傾向、特定の認証サービスプロバイダの失敗率、及び特定のトランザクションで使用される認証方法の傾向、に関するがそれに限定されない。

多くの方法、システム及び解決策が提案され、カード保有者認証処理を提供する。１つの解決策は、MasterCard（登録商標） SecureCode（登録商標）である。これは本願の譲受人によって発表されたもので、カード保有者認証処理に関連するセキュリティレベルを定義し提供する。MasterCard（登録商標）SecureCode（登録商標）処理は、3-D Secure（登録商標）Protocol Specification Core Functionsのバージョン1.0.2（2006年4月17日実施）を組み入れる。この3-D Secure（登録商標）（「3DS」ともいう）についての特定の実施形態は、SPA（安全支払アプリケーション）アルゴリズムと、ユニバーサルカード保有者認証フィールド（UCAF）とへの支援を含む。このとき、3-D Secure（登録商標）仕様、メッセージ又はプロトコルは変更されない。いくつかの実施形態は3-D Secure（登録商標）仕様の様々な態様を確立し、それに依存し、及び利用する。しかし、処理及びシステムは、その仕様にとらわれたセキュリティ認証プロトコル又は処理、あるいは3DSプロトコル内で合致する認証フローに限定されない。3-D Secure（登録商標）仕様の少なくともいくつかの態様とインタフェース接続するシステム及び処理の状況において実施形態が示されるような実施形態では、他の又は代替の認証セキュリティプロトコルは、一般性を失うこと無く代替されてよく、既知のものや将来発展されるものを含んでよい。

図１は、3-D Secure（登録商標）仕様を有する本開示の実施形態による、カード保有者アカウントの所有権を確認する（すなわち、カード保有者認証）ために使用可能な処理を実装するシステム１００の例示的な図である。したがって、図１は部分的に、3-D Secure（登録商標）仕様による、カード保有者認証システム及び処理の外観を提供する。しかし、仕様の全ての詳細がここで示されるわけではない。というのも、そのような情報の完全な詳細な説明は、3-D Secure（登録商標）仕様及び／又はその説明を直接参照することで容易に理解可能だからである。更に、本開示の概念及び詳細は、特定の認証プロトコル（例えば3DS）に限定されない。よって、3DSの徹底的な詳細説明は、本開示を完全に理解するための要件ではない。

システム１００は、複数の特別にフォーマットされたメッセージをセキュア通信チャネル（これは3-D Secure（登録商標）仕様で定義される）に亘って交換することによって互いに相互作用しなければならない複数のエンティティを含む。したがって、特定のエンティティ、メッセージ及び必要な他の要件の数及び程度を考慮すると、図１のカード保有者認証処理は複雑である。

システム１００は、オンラインで存在する販売者と相互作用するカード保有者１０５を含む。典型的には、カード保有者１０５は販売者のウェブサイトを、自身の選択された装置上のブラウザを用いて訪問し、購入する品目（例えば商品及び／又は役務）を選択する。オンライン注文処理の一部として、カード保有者１０５は、支払証明書を販売者へ提供することによって、購入トランザクションを決済して完了する。支払証明書は少なくとも、トランザクション内の資金源として使用されるアカウントを示す主要アカウント番号（PAN）と、当該PANに関連付けられた有効期限と、カード保有者の（請求）住所情報とを含んでよい。PAN及び他の情報は、販売者の販売者サーバプラグイン１１０へ提供される。ここではMPIは、販売者に代わって実行されるソフトウェアモジュールである。MPI１１０は動作して、支払認証が、カード保有者から受信されたPANにつき利用可能か否かを判定する。MPIは、確認登録要求（VEReq）メッセージ（これはPANを含む）をフォーマットして、ディレクトリサーバ（DS）１１５へ送信する。ここではDSは、PANがシステム１００によって提供される認証サービス内で登録されたPANの範囲内か否かを判定可能なコンピュータサーバである。DSは少なくとも１つのプロセッサを有するコンピュータと、プログラム命令及びデータを格納するメモリと、他の装置とインタフェース接続するための通信インタフェースとを含んでよい。

VEReqを受信すると、DS１１５はアクセス制御サーバ（ACS）１２０の装置に問い合わせる。このとき、ACSのアドレスはVEReqで特定される。ACSのアドレスは、ACSについてのウェブアドレスURL（ユニフォームリソースロケータ）を用いて特定されてよい。特定されたACSは、PANによって示されるアカウントの発行者であってよい。いくつかの実施形態では、ACSはPANの発行者に代わって行動してよい。特定されたURLは発行者のそれ以外のウェブアドレスを指す。ACS１２０は、VEReqに含まれるPANにつき認証が利用可能かについての指示を提供することで、クエリ（問い合わせ）へ応答してよい。もし販売者が、参加中のアクワイアラであって販売者が有効な販売者であれば、ACS１２０は確認登録応答（VERes）メッセージと共に応答してよい。当該メッセージは、VEReqメッセージに含まれるPANにつき利用可能であることを示す。ACS１２０はVEReqからのPANを用いて、カード保有者が認証サービスに登録されるか否かを判定する。

いくつかの実施形態では、MPIは、認証サービスに登録されたPANの範囲に関連するデータを格納して、当該PANがシステム１００によって提供される認証サービスに登録されたPANの範囲内か否かを判定してよい。

いくつかの実施形態では、VEResは、認証がPANにつき利用可能であることのフラグを含んでよい（例えばPAN認証利用可能フィールドは、認証が利用可能であることを示す「Y」に設定されてよい）。反対にACS１２０は、認証がPANにつき利用不可能であることを示すVEResと共に応答する（例えばアクワイアラBIN及び／又はPANは不登録、ACSはクエリに対し無応答、等）。いくつかの実施形態では、VEResは、認証がPANにつき利用不可能であることのフラグを含んでよい（例えばPAN認証利用可能フィールドは、認証が利用可能でないことを示す「N」又は認証が利用不可能であることを示す「U」へ設定されてよい）。VEResがフラグと、そのフィールド内の値と、又はPANにつき認証が利用可能でないことを示す他のメカニズムとを含む場合、システム１００によって提供される認証処理は終了し又は失敗する。

ACS１２０は更に、DS１１５に対し、認証が利用可能であるか否かについての指示を含むVEResを送信する。DS１１５は次いで、当該VEResをMPI１１０へ転送する。これは、DSがトランザクションの承認に参加することを意味する。しかし、認証処理は完了から程遠い。VEResを受信すると、MPI１１０は応答を読取り、認証がトランザクションのPANにつき利用可能か否かを確認する。もし認証が利用可能なら、MPI１１０は支払者認証要求（PAReq）メッセージを含むメッセージを、ACS１２０へ、カード保有者のブラウザを介して、VEResに含まれるACS URLを用いて送信する。PAReqメッセージは発行者ACSへ、そのカード保有者を認証するよう要求する。PAReqはカード保有者、販売者、及びトランザクション特有の情報を含んでよい。カード保有者情報は、カード保有者と発行者のみに対し既知のセキュリティ情報を含んでよい。PAReqメッセージは販売者（又はMPI）には共有されない。

ACS１２０はPAReqを受信して、受信されたメッセージを検証し、それが適切にフォーマットされていることと、それが必要情報（例えばデジタル証明書と適切なPAN認証利用可能フラグ（例えば「Y」））を含むこととを確認してよい。ACS１２０は更にカード保有者の認証を提供するか否かを判定してよい。ACS１２０は、トランザクションの状態を提供することで、その判定についての指示を提供してよい。当該状態についての値は、3-D Secure（登録商標）によれば、顧客が十分に認証されることを意味する「Y」と、顧客が認証を失敗し又は取り消したこと（すなわち、トランザクション拒否）を意味する「N」と、認証が完了しなかったことを意味する「U」と（例えば通信障害又はタイムアウト等による技術的問題）、認証が試行されたことを証明する「A」とを含んでよい。

ACS１２０によって判定されたトランザクション状態を含むメッセージはACS１２０からMPI１１０へ送信される。メッセージは支払認証応答、すなわち、PAResメッセージを含んでよい。トランザクション状態が「Y」と判定されると、PAResは認証トークンAAVを含み、これはMPI１１０へ送信される。PAResはデジタル署名され、メッセージ自体の認証に関するセキュリティレベルを提供してよい。PAResはカード保有者のブラウザを介してMPI１１０にて受信される。PAResを受信すると、MPI１１０は動作して、PAResの署名を検証し、VEResを含む値に少なくとも部分的に基づいてトランザクションを認証するか否かを判定してよい。

もしカード保有者が、上記に概略された認証処理を用いて認証されると、購入トランザクションは購入又は支払認証処理へ進んでよく、MPIへ、AAV値又はトークンを通知してよい。MPIが販売者支払システムへ認証試行の結果を通知した後、購入認証は従来の方法で完了してよい。

図１に関して本開示で説明されるカード保有者又はアカウントの認証は、本開示と互換性を有する認証フローの一例に過ぎないことに注意されたい。したがって、上記と同一の又は異なるメッセージ種別を用いて互いに通信するいくつかの異なるエンティティを含む他の認証フロー又は処理は、本開示の範囲内である。

いくつかの実施形態では、もし認証が成功しなければ、販売者は依然、従来のトランザクション承認へと進んでよい。このとき、不認証トランザクションとして、認証トークンは存在しない。不認証トランザクションの処理の責任は、いくつかの実施形態では、販売者にあってよい。本開示のいくつかの実施形態では、カード保有者認証の不成功を示す指示を含むデータは、添付され維持されてよい。

図１に関して述べたように、多くのメッセージが典型的には、多くの異なるエンティティ間で通信されてよい。したがって、関連当事者の数と、異なるエンティティ間で交換される特定のメッセージの数と、交換されるメッセージの内容に関してなされる必要がある判定の数と、メッセージの安全な通信とを考慮すると、カード保有者認証処理は典型的には複雑な処理である。本開示のいくつかの実施形態では、認証処理についての全ての関連する段階は、１以上の一時的レコード、メッセージ又はデータ構造にて維持される。

図２は本開示の実施形態による、システム２００を示す。システム２００はアプリケーション２０５を含む。いくつかの実施形態では、アプリケーション２０５は企業、ビジネス又は他の組織の内部であってよい。本開示のように「内部」アプリケーション、サービス、装置又はシステムは、特定の企業、ビジネス又は他の組織の外部にあるシステム、装置、サービス又は通信チャネルにさらされない。いくつかの実施形態では、アプリケーション２０５は、本開示のAPI（アプリケーションプログラミングインタフェース）仕様により構成されるソフトウェアアプリケーション又はサービスであってよい。APIは本開示の認証APIを指してよい。認証APIはアプリケーション２０５と他のソフトウェアアプリケーション、装置、システム又はサービス（例えば企業サーバ２１０）との間の情報交換に含まれる情報を特定してよい。企業サーバ２１０は動作して、認証値又はトークンに対する要求を、APIコールを介してアプリケーション２０５から受信してよく、また、そのAPIコール（すなわち、要求）へ返信して、API応答を介して認証値をソフトウェアアプリケーション２０５へ送信してよい。

いくつかの実施形態では、要求された認証値は、ユニバーサルカード保有者認証フィールド（UCAF）データ構造（これは認証支払環境に対応する）に対応するセキュリティコードを含んでよい。しかし、いくつかの実施形態では、本開示の認証値はUCAFデータ構造又はそのインスタンスに限定されないことに留意されたい。本開示のいくつかの実施形態では、要求された認証値は、特定のトランザクション及び／又は使用例において使用される１以上の認証フローに対応してよい。

いくつかの実施形態では、認証支払環境は３ドメイン（3-D）セキュリティプロトコルを含んでよい。しかし、他の認証フロー及びプロトコルがいくつかの実施形態では使用されてよい。いくつかの実施形態及び態様では、APIコール及びそれに対する返信におけるAPI応答を生成及び通信する処理、並びに、その処理を実行するシステム及び装置は、セキュリティプロトコルから分離され又は区別されてよい。いくつかの実施形態では、本開示の方法及び処理の態様は、いくつかの場合、セキュリティプロトコルを含む処理及びシステムへ情報を提供し、及び／又は、そこから情報を受信してよいが、それと別であってよい。

一実施形態では、認証値又はトークンに対する要求は、特定のトランザクションについてのものであってよい。このとき、APIコールへの返信にて発呼アプリケーション２０５へ返信され又は送信される認証値は、当該APIコールで特定されたトランザクションにつき有効な及び当該トランザクションに特定的に関連付けられた、認証値を提供する。いくつかの実施形態では、企業サーバ２１０からアプリケーション２０５へ送信される認証値又はトークンは、アプリケーション２０５及び／又は他のアプリケーション、システム、装置及びサービスによって、アプリケーション２０５及び／又は他のアプリケーション、システム、装置及びサービスによって実行される１以上の処理において、使用されてよい。一例として、企業サーバ２１０によって生成され、アプリケーションからのAPIコールへの応答にてアプリケーション２０５へ送信される認証値は、確認された認証の指示子（すなわち、証明（プルーフ））として使用されてよく、支払トランザクション承認要求又は他の処理に更に含まれてよい。いくつかの実施形態では、認証値はフォーマットされ、適切な方法でエンコード（例えばフォーマット、エンコード、暗号化等）されてよい。これにより、認証値を含む特定の承認要求は、認証値を包含するように変更される必要はなく、又は他の方法で処理される必要がない。したがって、図２のいくつかの実施形態はシステム及び処理（これは、少なくとも部分的に１以上のセキュリティプロトコルに合致する現在既知の又は将来開発されるシステム及び処理を含む）とインタフェース接続し、それらを含んでよい。少なくとも１つの使用例では、認証値は更に購入トランザクション処理（これは、少なくとも部分的に購入トランザクション承認（例えばクレジットカード承認）を含む）にて使用されてよい。いくつかの実施形態では、アプリケーション２０５による要求への返信において企業サーバ２１０によって取得された認証値は更に、要害要求を含む態様でフォーマットされ及び／又はエンコードされ、要求元アプリケーション２０５に対応してよい。

いくつかの実施形態では、アプリケーション２０５は企業サーバ２１０へ単一のAPIコールを用いて、認証要求を行ってよい。反対に企業サーバは単一のAPI応答を用いてアプリケーション２０５へ返信を提供してよい。このように、認証値は、アプリケーションからの単一のAPIコールを用いて、認証値又はトークンを要求又は受信することによる効率的な処理で取得されてよい。いくつかの実施形態では、これは、例えば図１を参照して開示された処理の実施形態（これは、特定の一続き（シーケンス）で互いに必要的に通信する複数の異なるエンティティを伴う一方で、特定のセキュリティプロトコルにつき、特手のメッセージフォーマットと通信セッション要件とを有する特定のメッセージを交換する）とは対照的である。

図３を参照すると、本開示の実施形態による、システム３００の例示が示される。いくつかの観点では、図３は、認証処理の承認要求ごとのエンドツーエンドのトランザクションフローを記録及びログ可能な履歴サーバを含んだ認証プラットフォームの論理的態様を開示する（3-D Secure（登録商標）を含むがこれに限定されない）。したがって、実際のシステムは、図２に明示されない配置で、一般性又は適用可能性を損なうこと無く、より少ない、より多い、又は異なる装置及びエンティティを含んでよい。いくつかの実施形態では、システム３００は従来の認証システムのいくつかの態様を利用するプラットフォーム（例えば図１のプラットフォーム（もっとも、これに限定されない））及び図３に開示されるシステムのいくつかの態様を含んでよい。いくつかの実施形態では、システム３００及びそれによって実装される処理は、一日あたり、数百万のトランザクションと、認証要求とを処理するよう動作してよい。そのような処理範囲と規模（認証要求が完了し且つ初期購入トランザクションはまた関連購入承認において示されるか否か、又は、認証要求が完了したか否かにかかわらず、毎認証要求を含む）は、システム３００によって可能になる。したがって、システム３００は、既知の処理を実装することに限定されず、必要的にコンピュータ装置、システム、改良版ネットワークを含んでよい。

いくつかの実施形態では、システム３００は、使用される認証プロトコルに応じて、支払承認要求（PAReq）メッセージ又は他のメッセージを受信するアプリケーションサーバ３１０を含み、１以上のソースからのトランザクションに関連付けられて使用される認証プロトコルに応じて、支払認証要求（PARes）メッセージ又は他のメッセージを含む。認証システム及び処理によって、PAReq又は他のメッセージ及びPARes又は他のメッセージは、企業環境の外部のACS３０５から受信されてよい。いくつかの実施形態では、PAReqメッセージ及びPAResメッセージは、構成されたシステムの発行者ACS（少なくとも図１のシステム１００に類似する）から受信されてよい。トランザクションPAReq及びPARes又は外部ACSから受信される他のデータは、外部ACSプロバイダから要求されてよい。サーバ４１０によって受信されるPAReq及びPAResデータは、データベースサーバ４２５へ送信されてよい。サーバ４２５（「履歴サーバ」とも称される）は、動作して、受信されたデータを追跡、格納、フォーマット、エンコード及び／又は暗号化して、PAReq及びPARes又は他の認証データを、データベーステーブル、システム、他のデータ構造及びデータストレージサービスへ挿入してよい。

いくつかの実施形態では、サーバ３１０はトランザクションに関連付けられたPAReq及びPAResデータを、企業環境の内部の１以上のサーバから（例えばサーバ３１５及び３２０から）受信する。サーバ３１５及び３２０は、少なくとも部分的にACSとして機能する１以上の装置又はシステムであってよい。いくつかの実施形態では、ACS３１５は内部ACSであり、企業環境の内部（例えば図２のセキュリティ（ACS）サーバ２１５）にあってよい。図２に関して上記したように、企業サーバ２１０及び他の構成要素を含むシステム２００は、企業環境に対して内部的に動作してよい。ここでは、企業２００は、アプリケーション又はサービス２０５からのAPIコールに応答して、認証値を生成する。認証値の生成によれば、ACS３１５はトランザクションPAReq及びPAResデータ又は、使用される認証プロトコルに応じた他のメッセージを有してよい。

いくつかの実施形態では、サーバ３２０は企業によって提供されるオンライン認証サービスACSを含んでよい。一方いくつかの実施形態では、サーバ３２０は他の種別のACSサーバを含んでよい。これは、少なくとも時として、アプリケーション、装置及び／又は企業環境の外部のサービスと通信してよい。サーバ３２０はトランザクションPAReq及びPAResデータ又は、特定のオンラインの又は他の種別のトランザクションに関連付けられた他の認証データを有してよい。PAReq及びPARes又はサーバ３１５及び３２０からの他の認証データは、アプリケーションサーバ３１０へ送信され、次いで履歴サーバ３２５へ送信されてよい。

認証処理データの他の態様（確認登録要求（VEReq）メッセージ及び確認登録応答（VERes）メッセージ、又は、使用される認証プロトコルに応じた他のメッセージ）は、１以上のサーバ３１５（例えば内部ACSサーバ）及びディレクトリサーバ（DS）３４０から受信されてよい。いくつかの実施形態では、サーバ３１５は内部ACSである。これはトランザクションのための認証値の内部的生成を支援してよい（図２に関して述べられる通り）。したがって、関連トランザクションに対応するVEReq及びVEResデータは、内部ACS３１５によって格納される。このVEReq及びVERes又は他のメッセージはアプリケーションサーバ３４０へ、少なくとも格納目的で、送信されてよい。

いくつかの実施形態では、VEReq及びVERes又は他のメッセージは、外部装置、アプリケーション、及びサービス（例えば図１のシステム１００）の支援及び協働により生成されてよい。したがって、VEReq及びVEReq又はいくつかのトランザクションに関連付けられた他のデータは、販売者MPIインタフェース３３５からサーバ３４０経由で受信されてよいし、DS３４０に格納されてよい。

いくつかのVEReq及びVEResデータが内部ACS又はDS３４０のどちらから受信されようが、サーバ３４０は動作して、受信されたデータを追跡、格納、フォーマット、エンコード及び／又は暗号化して、VEReq及びVERes又は他のデータを、データベーステーブル、システム及び他のデータ構造へ挿入してよい。いくつかの実施形態では、VEReq及びVERes又は他のデータを提供するソース又は装置種別を示す指示が、VEReq及びVEResデータ又は使用される認証プロトコルに応じた他のメッセージに含まれてよい。このソース指示子は、特定のトランザクションに関連付けられた認証トークン要求が内部処理（例えば図２）又は外部処理、装置、サービス若しくはシステムによって生成されたか否かに対する洞察を提供してよい。

履歴サーバ３２５（すなわち、PAReq及びPARes又は他のデータ）とDSサーバ３４５（例えばVEReq及びVERes又は他のデータ）との両方におけるデータは、データウェアハウス、ストレージ施設、装置又はシステム３００内に含めるために、同期され、処理され、組み合わされ又は集約されてよい。いくつかの実施形態では、データウェアハウス３３０はデータベース管理システムと、データベース管理システムのノードのインスタンスとを含んでよい。いくつかの実施形態では、組み合わされたPAReq及びPARes又は他のデータ並びにVEReq及びVERes又は他のデータは、単一のデータレコード又はその構造表示を含んでよい。組み合わされたデータレコードは、他のトランザクション詳細に加えて、エンドツーエンドのトランザクションフローの外観を提供してよい。これは、認証が販売者によって要求されたか否か、認証が発行者によって提供されたか否か、認証が承認されたか拒否されたか、及び、トランザクションのための支払承認が要求されたか否か及びそれが承認されたか拒否されたか、を含む。

いくつかの実施形態では、データウェアハウス３３０内のデータは、他のシステム及び装置（不図示）によってアクセスされて、トランザクションに対する洞察を提供してよい。いくつかの実施形態では、企業レベル分析が使用されて、例えば報告、提示及びダッシュボードを生成するためにデータを分析してよい。いくつかの実施形態では、データウェアハウス３３０内のデータは企業の様々な組織によって使用されてよい。これにより例えば、トランザクション問題を解決し、発行者又は販売者の苦情を管理し及びそれに回答し、準拠（コンプライアンス）プログラムを管理し、放棄率を管理等する。いくつかの実施形態では、システム３００は、トランザクション内の一意のパターンを判定し、トランザクションデータ収集のための以前の方法よりも良く、ユーザ及び販売者の実務（例えば詐欺）を確認する機能を支援し及び可能にする。

いくつかの実施形態では、いくつかの実施形態により処理及び収集される認証データは、処理、システム、及び装置において使用されてよく、特定のトランザクションのリスクレベルについての指示を得点付けし、提供してよい。これは例えば、過去の認証パターン及び／又はアカウント若しくはアイデンティティに対する過去の認証速度に基づく。この状況又は他の状況で、過去の認証活動は、少なくとも部分的に現在の要求と比較されてよく、認証データが、観察され予期され所望され算出され又は予測されたパターン、範囲及び「標準」外（内）にあるか否かを判定する。いくつかの実施形態では、処理され格納される認証データは、データを使用した分析、格納、検索及び報告機能を支援する試みにおいて集約されてよい。

認証エコシステム又はプラットフォーム５００の一部は、認証サービス５０５に代わって、アクセス制御サーバ（ACS）又は他のいくつかのシステムによって発呼されてよく、「帯域外」手法で実際の認証を提供してよい。当該方法、例えば、ワンタイムパスコード生成及び検証サービス、モバイルアプリケーション、生体検証サービス及び他の種別のサービス、処理、アプリケーション及び仕様例を含んでよい。これら及び他の要求の全ての結果はまた、データウェアハウス内のデータリポジトリへ付与されてよい。これは、他のデータとインタフェース接続し、詳細なトランザクション報告及び分析を提供してよい。

いくつかの実施形態では、いくつかの実施形態による認証APIは、１以上のデータフィールドを含んでよい。下記表１は、いくつかの実施形態による、いくつかのデータフィールドの表リストである。これは、ウェブサービス又はアプリケーションによって使用されるAPIを実装するために特定されてよい。いくつかの実施形態では、表１に列挙されるデータフィールドは、インタフェース記述言語（例えばウェブサービス記述言語、WSDL）で記述されてよく、ウェブサービス又はアプリケーションの開発者へ、当該開発者又は他のエンティティによる使用のために提供されてよい。これにより、適切に定義されたAPIを使用して効率的に通信することができるウェブサービス又はアプリケーションが生成される。

いくつかの実施形態では、認証APIは、表１に列挙されたデータフィールドの全てに対し、値が指定されることを要求し又は期待してよい。すなわち、APIコールは表に列挙されたデータフィールドのそれぞれにつき、対応する値を含んでよい。他のいくつかの実施形態では、表１で指定されるデータフィールドのいくつか（必ずしも全てでなくてよい）は、APIコールで提供される対応値を有してよい。例えば認証APIのいくつかのインスタンスは、PANの値（すなわち、支払アカウント番号）と、販売者名と、当該PANに対応する有効期限とを指定してよい。APIコールにはこれらの最小値が含まれてよい。当該最小値は、いくつかの実施形態では、認証値の要求において十分である。いくつかの実施形態によれば、認証履歴サーバによって受信され又はそれに提供されるデータは、次の構成要素の少なくともいくつかを含む。

表１は、いくつかの実施形態についてのデータの例示的リストを示す。列挙されたデータは網羅的でなくてよいし、徹底的でなくてよい。したがって、他のデータ（例えばハイレベルカード保有者情報と他のトランザクションデータ）はまた、いくつかの実施形態では、格納され、又は、認証履歴サーバによって受信され及び／又は当該履歴サーバへ提供されてよい。

いくつかの実施形態では、処理３００に応じて動作するアプリケーションは、発行者に代わって開発された電子支払ウォレットアプリケーションを含んでよい。電子ウォレットの開発及び展開の一部として、電子ウォレットの認証は、支払ネットワークプロバイダ又は他のエンティティへ割り当てられ又は渡されてよい。ウォレットアプリケーションのログイン時に、ウォレットの発行者と共に、ウォレットアプリケーションの確実性又はアイデンティティを確認する、何らかのレベルの認証が行われてよい。したがって、顧客を伴う購入時の販売者は、決済時に、ウォレットを認証する必要はなくてよい。というのも、ウォレットアプリケーションは既に発行者により認証されているからである。いくつかの実施形態では、ウォレット認証はウォレット初期化処理の一部として行われてよい。

本開示のウォレットアプリケーションに関連付けられたユーザは、既に、発行者及び／又は他の者の懸念を満たすように判定され設計された認証レベルで、発行者により認証されている（すなわち、「事前認証」されている）。しかし、特定の認証は、認証値又はトークン（例えばAAV値）を提供しなくてよい。これは通常、セキュリティプロトコルによって及び／又はそれに応じて、生成されてよい。認証値又はトークン（例えばAAV値）を取得する試みにおいて、電子ウォレットアプリケーションは、本開示により、APIコールを介して、認証値を要求してよい。APIコールはサービスへ直接提示され、そこから認証値をプル（取得）する。いくつかの実施形態では、アプリケーションからのAPIコールは、認証値を取得する。このとき、１以上のセキュリティプロトコルの要件を全て満たす必要はない。というのも、例えば発行者又はそれに代わって行動するエンティティは、所定の条件が満たされるときにAPIコールを処理することに同意するからである。いくつかの実施形態では、本開示によるアプリケーションからのAPIコールを受付けて処理することの同意は、APIコールが企業サーバによって受信される前（例えば処理３００の動作３０５の前）に判定される。いくつかの実施形態では、本開示での電子ウォレットの認証は、事前承認された認証を含んでよい。

いくつかの実施形態では、電子ウォレット又は他の発呼アプリケーションの認証を管理するポリシーは、発呼アプリケーションと、発呼アプリケーションによる認証値又はトークンの使用意図と、他の考慮事項とに応じて可変的であってよい。

電子ウォレットの例について続けて述べると、顧客カード保有者が販売者のウォレットサービスにログインする場合、当該ウォレットサービスに登録された顧客は、既に認証されたものとして考慮されてよい（すなわち、認証は事前承認される）。しかし、この場合、認証値又はトークンは、顧客の購入トランザクションに関連付けられた支払承認要求において使用するのに好適であってよい。いくつかの実施形態では、支払承認要求は、発行者（又はそれに代わって行動するエンティティ）によって、認証値又はトークンを含むように予期される。いくつかの実施形態では、支払承認は、予期された認証値又はトークンの不在時には処理されなくてよい。

いくつかの実施形態では、認証値又はトークンを支払承認要求に含めることは、既知の所定の又は将来開発される処理フローに応じて、支払承認の処理を支援してよい。予期された認証値又はトークンの不在は、代替の又は「例外」処理フローに応じた支払承認処理を誘起してよいし、処理フローの終了を誘起してよい。

図２を参照すると、いくつかの実施形態では、セキュリティサーバ２１５は、企業サーバ２１０によって生成された認証値又はトークンのレコード又は表示を履歴サーバ２２０へ転送してよい。履歴サーバ２２０は更にトランザクション詳細をデータベース２２５へ送信してよい。トランザクション詳細は更なる処理、報告及び分析にて使用されてよい。

図４は、本開示の実施形態による、システム４００の機能ブロック図である。システム４００は認証データ管理プラットフォーム４０５を含んでよい。これは１以上の認証システム、装置、アプリケーション、サービス４１５とインタフェース接続し又はそれらと通信する。いくつかの実施形態では、認証管理プラットフォーム４０５は顧客データと、認証サービスに関する他のデータとの取得、更新及び分析を支援し容易にしてよい。いくつかの実施形態では、認証システム４１５は3DS認証システム、サービス及びアプリケーションを含み又はそれらに関連してよい。もっとも、認証管理プラットフォーム４０５を含む本開示の実施形態は、3DS認証プロトコルを実装する認証システムと通信し又はインタフェース接続することに限定されない。いくつかの実施形態では、１以上の認証システムは互いに動作可能でもよいし、そうでなくてもよい。１以上の認証システム４１５が互いに動作可能かどうかにかかわらず、認証システム４１５のそれぞれは、認証管理プラットフォーム４０５と通信し又はインタフェース接続してよい。いくつかの実施形態では、認証システム４１５と認証管理プラットフォーム４０５との間で送受信される通信メッセージ、コマンド及び／又は命令は、１以上の通信インタフェース又は他の装置、サービス若しくはアプリケーションによって支援されてよく、認証システム４１５と認証管理プラットフォーム４０５との間でのそのメッセージの互換性を確実にする。

認証管理プラットフォーム４０５は１以上のデータストレージ施設又はリポジトリ４１０へのアクセス権を含み又は少なくとも有してよい。いくつかの実施形態では、データリポジトリ４１０は１以上のデータベースノードを含むリレーショナルデータベースを含み、ビジネス企業のためのデータを管理してよく、いくつかの実施形態では、認証サービスに関連するデータ管理機能を提供する。当該機能は、顧客登録（enrollment）と顧客データ管理（すなわち、顧客登録／データ管理としても示される）と請求解決策とを含むがこれらに限定されない。リポジトリ４１０は様々なデータ構造で、データの全ての態様及び種別（例えば、１以上の異なる組織、部署又は企業の他のビジネスエンティティにおける顧客に関連する顧客問い合わせ先データ）を有し及び管理する。認証管理プラットフォーム４０５は更に、バックエンドシステム４２０を含み、認証管理プラットフォーム４０５のデータ取得、データ処理、及びデータ管理機能を支援してよい。いくつかの実施形態では、バックエンドシステム４２０は少なくとも論理的に、ビジネス企業のビジネス組織にて組織されてよい。

図５はいくつかの実施形態による、システム用の論理構造５００の例示である。いくつかの実施形態では、システム５００によって提供され支援され及び容易にされる機能は、認証管理プラットフォーム（例えばプラットフォーム４００）によって提供され又は実装されてよい。実際のシステム５００の実装は、より多くの構成要素を含み、又は、図５の明示される構成要素よりも多くの構成要素を含んでよいし、他の構成にて設計されてよい（図５に示す構成だけに限定されない）。他のトポロジが、他の実施形態に関して使用されてよい。更に本開示の各システムは、任意の数の他の公衆及び／又はプライベートネットワークを介して通信する任意の数の装置によって実装されてよい。２以上のそのようなコンピューティング装置は、互いに遠隔に配置されてよいし、任意の既知のネットワーク手法及び／又は専用接続によって互いに通信してよい。各装置は、任意の数のハードウェア及び／又はソフトウェア要素を含んでよい。これらは本開示の機能及び任意の他の機能を提供するのに適切である。例えば、いくつかの実施形態の実装にて使用される任意のコンピューティング装置は、プロセッサを含んでプログラムコードを実行してよい。このため、コンピューティング装置は本開示のように動作する。

システム５００は認証ポータル５０５を含む。新規の認証ポータル５０５は１以上の外部ユーザ（すなわち、システム５００のサービス又は機能を提供する企業又はビジネス組織に対し外部）のためのメカニズムを提供し、本開示の認証管理プラットフォームによって管理される認証情報と通信し及び当該認証情報へのアクセスを有する。いくつかの実施形態では、外部ユーザ５１５は、外部顧客メインポータル５１０を介して認証ポータル５０５とインタフェース接続してよい。いくつかの実施形態では、外部顧客メインポータル５１０は少なくとも部分的に、外部に面したグラフィカルユーザインタフェースを含んでよい。これは、コンピュータ又はプロセッサ対応装置（例えばコンピュータ、タブレット、又は適用可能なアプリケーション（例えば「アプリ」）を駆動するスマートフォン）によってアクセス可能である。外部顧客メインポータル５１０はいくつかの実施形態では、ブラウザ、ブラウザ拡張機能、又はアプリケーションプログラミングインタフェース（API）を介して実装され及び／又はアクセスされてよい。いくつかの実施形態では、外部ユーザ５１５は発行者（イシュア）、アクワイアラ、及び承認済み第三者（例えば発行者及びアクワイアラサービスプロバイダ）を含んでよい。これらは、本開示の認証プラットフォームの認証サービス及びアプリケーションにて登録され又は潜在的に登録される。いくつかの実施形態では、外部顧客５１５の問い合わせ先は、外部顧客メインポータル５１０のいくつかの実装によって格納され及び管理されてよい。

電子データリポジトリ（EDR）５２０がシステム５００に含まれてよい。EDR５２０はデータストレージ施設（例えばリレーショナルデータベース管理システム）を含んで、例えば、本開示の認証プラットフォームの既存の外部顧客５１５に関連する履歴データを格納、維持及び管理してよい。EDR５２０は少なくとも部分的にクラウドを基礎としたストレージ装置、システム又はアプリケーションを含んでよい。いくつかの実施形態では、EDR５２０は１以上のデータベースノード又はインスタンスを含む中央又は分散データベースシステムであってよい。EDR５２０は、進行中の試行において、データが外部顧客５００からシステム５００へ入ること又はシステム５００によって取得されたことの確認点として動作し、そのようなデータが、企業によって既知の且つ管理されたデータと一貫し且つ正確に対応することを確実にする。いくつかの実施形態では、EDR５２０は自動的に、１以上の規則又は実行可能なトリガに基づいて、本開示のデータを更新及び確認してよい。

いくつかの実施形態では、システム５００は更に、判定管理プラットフォーム又はサービス５２５を含む。判定管理プラットフォーム５２５はデータ管理装置又はシステム（例えばリレーショナルデータベースシステム）であってよい。これは、外部の顧客、発行者、アクワイアラ及び承認された第三者についての外部顧客情報を格納する。いくつかの実施形態では、判定管理プラットフォーム又はサービス５２５は、認証データベース５３０を含んでよい。認証データベース５３０はレコード、ファイル及び、顧客データを示す他のデータ構造を格納及び維持してよい。これらは、契約、文書（例えばメッセージ、文書、未構造データ等）、証明書情報、クレジットカード範囲、支払装置BIN（銀行識別番号）、販売者情報及び他のデータを含むがこれらに限定されない。

システム５００は認証データベースのユーザインタフェース５３５を含んでよい。これは、企業の内部で、内部認証ユーザ５４０が判定管理プラットフォーム５２５へアクセスし及びそれと通信するためのインタフェースである。いくつかの実施形態では、認証データベースのユーザインタフェース５３５はメカニズムを提供する。そこでは、内部認証ユーザ５４０が、認証プラットフォームの認証情報へアクセスし、顧客支援機能と、外部顧客認証関連データ（例えば問い合わせ先情報、請求情報等）へのビジネスアクセス若しくは分析者アクセスとを、提供し又は少なくとも支援する。認証データベースのユーザインタフェース５３５を介した認証データベースへのアクセスは、内部認証ユーザの役割に応じて、内部認証ユーザに限定されてよい。

図６は、データ交換の例示的論理図である。当該データ交換は、本開示の実施形態による、認証プラットフォームによって実行されてよい。図６のデータは概して、外部ユーザインタフェース６０４を介して外部ユーザによってアクセス可能な、且つ、内部ユーザインタフェース６１５を介して内部認証ユーザによってアクセス可能な、データベース６１０によって格納され及び維持されてよい。多くの異なる種別のデータ（これは、カード範囲情報６０２、販売者情報６０４、外部ユーザ問い合わせ先６０６、検査及び証明データ６０９、及び発行者情報６１２を含む）が、外部UI６０５を介してデータベース６１０へ提供されてよい。認証プラットフォームの１以上の外部ユーザに関連する他の態様及び種別のデータは、図６に示す外部ユーザ情報に加えて又はそれに代えて、いくつかのインスタンス及び実施形態にて包含されてよい。

いくつかの実施形態では、多くの異なる種別のデータ（これは、カード範囲情報６２４、販売者情報６２６、外部ユーザ問い合わせ先６２８、検査及び証明データ６３０、及び発行者情報６３２を含む）が、内部UI６１５を介してデータベース６１０へ提供されてよい。認証プラットフォームの１以上の内部ユーザに関連する他の態様及び種別のデータは、図６に示す特定のユーザ情報に加えて又はそれに代えて、いくつかのインスタンス及び実施形態にて包含されてよい。

いくつかの実施形態では、外部顧客メインポータル６１８は、図５の外部顧客メインポータル５１０と類似の機能を提供してよい。図６に示す認証データベース６１４、６１６、６２０及び６２２のインスタンスは、図５の認証データベース５３０と類似の機能を提供してよい。いくつかの実施形態では、EDR（例えば図５のEDR５２０）は、外部ユーザと、内部ユーザと、図６で示されるデータベースとの間で交換されるデータに対し多くの確認点を提供する。

図７は、いくつかの実施形態による、システム又は装置７００の機能ブロック図の概要である。システム７００は例えば、本開示の任意の装置（これは例えば、企業サーバ、認証データベースサーバ及び本開示の処理による類似の機能を含む）と関連付けられてよい。システム５００はプロセッサ７０５（例えば１以上の商業利用可能な中央処理装置（CPU））を、１チップのマイクロプロセッサ又はマルチコアプロセッサの形態で含んでよく、他の装置又はシステムと通信ネットワーク（図７で不図示）を介して通信するよう構成された通信装置７１５に接続される。システム７００がサーバ（例えばこれは認証プラットフォームによって提供される機能及びサービスを支援する）を含む場合、通信装置７１５はシステム７００が他の装置、システム及びサービス（例えば認証システムのインスタンス）とインタフェース接続するためのメカニズムを提供してよい。システム７００はまた、ローカルメモリ７１０（例えばRAMメモリモジュール）を含んでよい。システムは更に、入力装置７２０（例えばコンテンツを入力するためのタッチスクリーン、マウス及び／又はキーボード）と、出力装置７２５（例えばタッチスクリーン、表示用コンピュータモニタ、LCDディスプレイ）とを含む。

プロセッサ７０５はストレージ装置７３０と通信する。ストレージ装置７３０は任意の適切な情報ストレージ装置を含んでよい。これは、磁気ストレージ装置（例えばハードディスク）、光ストレージ装置、ソリッドステートドライブ、及び／又は半導体メモリ装置を含む。いくつかの実施形態による、ストレージ装置６３０はデータベースシステムを含んでよい。

ストレージ装置７３０は、コンピュータ実行可能な命令を提供するプログラムコード又は命令７３５を格納してよい。これは、本開示の処理によって、処理、分析及び報告目的で、顧客認証データを更新及び確認してそのデータレコードを格納するためのものである。プロセッサ７０５はプログラム命令７３５の命令を実行して、それによって、本開示の任意の実施形態によって動作してよい。プログラムコード７３５は圧縮された、未編集の、及び／又は暗号化されたフォーマットで格納されてよい。プログラムコード７３５は更に、他のプログラム要素（例えばオペレーティングシステム、データベース管理システム、及び／又は、例えば周辺装置とインタフェース接続するためにプロセッサ７０５によって使用される装置ドライバ）を含んでよい。ストレージ装置７３０はまた、データ７４０（例えばデータベースレコード又はルックアップテーブル）を含んでよい。これは例えば、特定の認証プログラム又はサービスに参加する販売者、発行者及びアクワイアラのレコードと、それらのエンティティによってサービスを実装するために使用される装置のアドレスとを含む。いくつかの実施形態では、本開示の１以上の処理を実行する際に、データ７４０はシステム７００によって使用されてよい。これは、個々の処理と、それらの処理の個々の動作と、個々の処理及び個々の処理動作の組合せとを含む。

本開示の全てのシステム及び処理は、１以上の非一時的コンピュータ可読のプロセッサ実行可能な媒体上に格納されたプログラム命令内で実現されてよい。そのような媒体は例えば、ソリッドステートドライブ、フロッピーディスク、CD-ROM、DVD-ROM、磁気テープ、及びソリッドステートランダムアクセスメモリ（RAM）又は読み取り専用メモリ（ROM）ストレージユニットを含んでよい。

いくつかの実施形態によれば、メモリストレージユニットはアクセスパターンに関連付けられてよく、（例えば磁気の、光電子の、半導体／ソリッドステート等の）装置から独立してよい。更に、インメモリ技術が使用されてよい。これによりデータベース等がプロセッサにてRAMメモリ内で完全に動作されてよい。したがって、実施形態はハードウェア及びソフトウェアの任意の特定の組合せに限定されない。本開示の実施形態は、例示目的のみで記載される。本開示から当業者は、開示範囲が上記のものに限定されないことを認識すると共に、実施形態が、請求項の趣旨及び範囲によってのみ限定される修正例及び変形例と共に実装されてよいことを認識する。

Claims (21)

1. コンピュータ実装方法において、
   コンピュータによって、認証システムの少なくとも１人の外部ユーザから、前記外部ユーザについての顧客情報を含むレコードであって前記認証システムでの前記少なくとも１人の外部ユーザの少なくとも登録に関連付けられたレコードを受信するステップと、
   過去の外部ユーザ顧客情報を格納する認証データベースとインタフェース接続するコンピュータによって、前記外部ユーザについての前記顧客情報を含む前記レコードを受信するステップと、
   前記外部ユーザについての前記顧客情報と前記過去の外部ユーザ顧客情報とを含む前記レコードを確認するステップと、
   前記確認されたレコードを示す指示を格納するステップと、を含む方法。
2. 請求項１に記載の方法において、前記外部ユーザについての顧客情報を含む前記レコードを確認する前記ステップは、前記外部ユーザについての顧客情報を含む前記レコードが受信されるときに自動的に実行される、方法。
3. 請求項１に記載の方法において、前記外部ユーザは、発行者と、アクワイアラと、発行者又はアクワイアラに代わって動作することを承認された第三者エンティティとの少なくとも１つである、方法。
4. 請求項１に記載の方法において、前記認証データベースはリレーショナルデータベースシステムを含む、方法。
5. 請求項１に記載の方法において、前記確認は、前記少なくとも１人の外部ユーザから受信された全てのデータに対し実行される、方法。
6. 請求項１に記載の方法において、前記過去のデータは内部認証ユーザから取得され、前記過去のデータは更に、前記外部ユーザから受信された前記顧客情報を含む前記レコードに対して確認される、方法。
7. 請求項１に記載の方法において、前記認証データベースは、第１の認証プロトコルを実装する認証システム用のデータを格納し、前記顧客情報を含む前記レコードは、前記第１の認証プロトコルを実装する認証システムについての前記少なくとも１人の外部ユーザの少なくとも登録情報を含む、方法。
8. システムにおいて、
   認証サーバと装置とを含み、
   前記装置は、
   プロセッサと、
   前記プロセッサと通信し、プログラム命令を格納するメモリ装置とを含み、
   前記プロセッサは前記プログラム命令で動作して、
   認証システムの少なくとも１人の外部ユーザから、前記外部ユーザについての顧客情報を含むレコードであって前記認証システムでの前記少なくとも１人の外部ユーザの少なくとも登録に関連付けられたレコードを受信し、
   過去の外部ユーザ顧客情報を格納する認証データベースから、前記外部ユーザについての前記顧客情報を含む前記レコードを受信し、
   前記外部ユーザについての前記顧客情報と前記過去の外部ユーザ顧客情報とを含む前記レコードを確認し、
   前記確認されたレコードを示す指示を格納する、システム。
9. 請求項８に記載のシステムにおいて、前記外部ユーザについての顧客情報を含む前記レコードを前記確認することは、前記外部ユーザについての顧客情報を含む前記レコードが受信されるときに自動的に実行される、システム。
10. 請求項８に記載のシステムにおいて、前記外部ユーザは、発行者と、アクワイアラと、発行者又はアクワイアラに代わって動作することを承認された第三者エンティティとの少なくとも１つである、システム。
11. 請求項８に記載のシステムにおいて、前記認証データベースはリレーショナルデータベースシステムを含む、システム。
12. 請求項８に記載のシステムにおいて、前記確認は、前記少なくとも１人の外部ユーザから受信された全てのデータに対し実行される、システム。
13. 請求項８に記載のシステムにおいて、前記過去のデータは内部認証ユーザから取得され、前記過去のデータは更に、前記外部ユーザから受信された前記顧客情報を含む前記レコードに対して確認される、システム。
14. 請求項８に記載のシステムにおいて、前記認証データベースは、第１の認証プロトコルを実装する認証システム用のデータを格納し、前記顧客情報を含む前記レコードは、前記第１の認証プロトコルを実装する認証システムについての前記少なくとも１人の外部ユーザの少なくとも登録情報を含む、システム。
15. プログラム命令を有する媒体において、
    認証システムの少なくとも１人の外部ユーザから、前記外部ユーザについての顧客情報を含むレコードであって前記認証システムでの前記少なくとも１人の外部ユーザの少なくとも登録に関連付けられたレコードを受信するプログラム命令と、
    過去の外部ユーザ顧客情報を格納する認証データベースから、前記外部ユーザについての前記顧客情報を含む前記レコードを受信するプログラム命令と、
    前記外部ユーザについての前記顧客情報と前記過去の外部ユーザ顧客情報とを含む前記レコードを確認するプログラム命令と、
    前記確認されたレコードを示す指示を格納するプログラム命令と
    を含む媒体。
16. 請求項１５に記載の媒体において、前記外部ユーザについての顧客情報を含む前記レコードを前記確認することは、前記外部ユーザについての顧客情報を含む前記レコードが受信されるときに自動的に実行される、媒体。
17. 請求項１５に記載の媒体において、前記外部ユーザは、発行者と、アクワイアラと、発行者又はアクワイアラに代わって動作することを承認された第三者エンティティとの少なくとも１つである、媒体。
18. 請求項１５に記載の媒体において、前記認証データベースはリレーショナルデータベースシステムを含む、媒体。
19. 請求項１５に記載の媒体において、前記確認は、前記少なくとも１人の外部ユーザから受信された全てのデータに対し実行される、媒体。
20. 請求項１５に記載の媒体において、前記過去のデータは内部認証ユーザから取得され、前記過去のデータは更に、前記外部ユーザから受信された前記顧客情報を含む前記レコードに対して確認される、媒体。
21. 請求項１５に記載の媒体において、前記認証データベースは、第１の認証プロトコルを実装する認証システム用のデータを格納し、前記顧客情報を含む前記レコードは、前記第１の認証プロトコルを実装する認証システムについての前記少なくとも１人の外部ユーザの少なくとも登録情報を含む、媒体。