取引の当事者を認証するための方法およびシステム
本発明の一実施形態は、提示者に関連する口座に関連するエリアス識別子を受信するステップと、このエリアス識別子を使って、信頼できる関連する当事者を決定するステップと、信頼できる関連した当事者を決定した後に、この信頼できる当事者に検証リクエストメッセージを送るステップと、検証応答メッセーを受信するステップとを含む方法に関する。
【発明の詳細な説明】
【技術分野】
【0001】
(関連出願とのクロスレファレンス)
本願はすべての目的のために、全体を参考例として本願で引用する、2007年4月17日に出願された米国特許出願第60/912,406号の非仮特許出願であり、この米国特許出願の権利を主張するものである。
【背景技術】
【0002】
(背景)
2人の当事者の間で取引(支払いを伴う取引または支払いを伴わない取引)を行う間、各当事者は不正を回避するために、他方の当事者のアイデンティティおよび/または他方の当事者に関係するデータを一般に認証を望む。
【0003】
遠隔通信デバイスによって開始され、このデバイスにより行われる取引は、対面取引よりも、より危険となり得る。その理由は、従来の対面認証手続きを実行できないからである。例えば遠隔取引を行う際に、消費者の運転免許証の写真をチェックすることができないからである。
【発明の概要】
【発明が解決しようとする課題】
【0004】
上記に鑑み、遠隔取引中に消費者のような個人のアイデンティティおよびプロファイルデータを認証するためのシステムが望まれている。認証システムは、実現および使用が容易であり、資源に最小限しか投資するだけでよく、システム参加者の間の高レベルの相互運用可能性を提供できることが望ましい。
【0005】
取引に関係する別の問題は、一般に購入取引中に業者が支払いカード情報を受け取ることが多いことにある。業者が誠実でない場合、消費者の支払い情報は危うくなり得る。本発明の別の実施形態は、業者が消費者の支払い情報を保有することのないよう、支払い取引のような取引を開始するのにエリアス識別子を使用することに関する。
【0006】
本発明の実施形態は、上記課題およびその他の課題を別々に、かつ総合的に解決するものである。
【課題を解決するための手段】
【0007】
概要
本発明の実施形態は、個人の識別を認証し、所定のアイデンティティを有し、かつ対応する所定のプロファイルデータを有する者として自分を別の当事者に提示する個人(提示者)のプロファイルデータの有効性を判断するための方法およびシステムを含む。本発明の実施形態は、遠隔取引だけに限定されないが、本発明の実施形態は、対面で認証手続きを行うことが困難である遠隔取引で有利に使用できる。本発明の実施形態により、信頼できる当事者は、提示者のアイデンティティおよびプロファイルデータを認証することも可能となる。プロファイルデータの提供およびプロファイル更新のような別の能力も実行できる。
【0008】
本発明の一実施形態は、a)提示者の口座に対する口座識別子に関連するエリアス識別子を受信するステップと、b)前記エリアス識別子を使って、信頼できる関連当事者を決定するステップと、c)前記信頼できる関連当事者を決定した後に、前記信頼できる当事者に検証リクエストメッセージを送るステップとを備え、前記検証リクエストメッセージは、前記信頼できる当事者または前記提示者が、認証プログラムに参加しているかどうかに関する情報をリクエストし、d)更に前記信頼できる当事者または前記提示者が前記認証プログラムに参加しているかどうかを示す検証応答メッセージを受信するステップを備える方法に関する。
【0009】
本発明の別の実施形態は、a)提示者の口座に対する口座識別子に関連するエリアス識別子を受信する符号と、b)前記エリアス識別子を使って、信頼できる関連する当事者を決定する符号と、c)前記信頼できる関連する当事者を決定した後に、前記信頼できる当事者に検証リクエストメッセージを送る符号とを備え、前記検証リクエストメッセージは、前記信頼できる当事者または前記提示者が、認証プログラムに参加しているかどうかに関する情報をリクエストし、d)更に前記信頼できる当事者または前記提示者が前記認証プログラムに参加しているかどうかを示す検証応答メッセージを受信する符号を備えるコンピュータが読み取りできるメディアに関する。
【0010】
本発明の別の実施形態は、a)提示者の口座に関連する口座識別子に関連するエリアス識別子を提供するステップと、b)前記エリアス識別子を提供した後に、認証リクエストメッセージを受信するステップと、c)前記認証リクエストメッセージを受信した後に、認証応答メッセージを送るステップとを備える方法に関する。
【0011】
本発明の別の実施形態は、a)提示者の口座に関連する口座識別子に関連するエリアス識別子を提供する符号と、b)前記エリアス識別子を提供した後に、認証リクエストメッセージを受信する符号と、c)前記認証リクエストメッセージを受信した後に、認証応答メッセージを送る符号とを備えるコンピュータが読み取りできるメディアに関する。
【0012】
図面および詳細な説明を参照し、以下、本発明の上記およびそれ以外の実施形態について更に詳細に説明する。
【図面の簡単な説明】
【0013】
【図1】本発明の一実施形態に係わるシステムのブロック図を示す。
【図2】本発明の別の実施形態に係わるシステムの別のブロック図を示す。
【図3】本発明の別の実施形態に係わるシステムの別のブロック図を示す。
【図4】支払い取引前に生じ得る登録プロセスの実施形態を示すフローチャートである。
【図5】支払い取引中に生じ得る登録プロセスの実施形態を示すフローチャートである。
【図6】支払い取引を開始するためのプロセスの実施形態を示すフローチャートである。
【図7】認証プロセスの実施形態を示すフローチャートである。
【図8】支払い認証プロセスの実施形態を示すフローチャートである。
【図9(a)】電話内の部品を示すブロック図である。
【図9(b)】代表的な支払いカードに存在し得る部品を示す。
【図10】コンピュータ装置内の部品のブロック図を示す。 図中、同様な番号は同様な要素を示し、一部のケースでは、同様な要素の説明を繰り返さないことがある。
【発明を実施するための形態】
【0014】
(詳細な説明)
本発明の実施形態は、所定のアイデンティティを有する者であって、かつ所定の対応するプロファイルデータを有するものとして、自らを別の当事者(受領者)に提示する個人(提示者)のアイデンティティを認証し、かつその個人のプロファイルデータの有効性を判断するための方法およびシステムを提供するものである。消費者は提示者の一例となることがあり、受領者は、サービス提供者、政府機関、業者または取引を進める前に提示者のアイデンティティを認証する必要がある他の任意のエンティティとなり得る。アイデンティティの認証は、所定の個人であると主張する提示側当事者のアイデンティティを検証することに依存することができ、プロファイルデータの有効性の判断は、提示者によって提供されるプロファイルデータが実際にその提示者に関連していることの有効性の判断に依存することができる。他の機能、例えばプロファイルデータの供給およびプロファイルの更新も、本発明の実施形態で実行できる。これら機能は別々に実行してもよいし、または互いに組み合わせて実行してもよい。本発明の実施形態は、従来の対面認証手続きの実行が困難である遠隔取引を実行するのに使用することが好ましい。
【0015】
図示するように、本発明の一実施形態では、クレジットカードを使って購入することを業者に求めている消費者を、取引が進行する前に認証できる。クレジットカードの発行者は、取引が終了するまでに、消費者および消費者のプロファイルデータを認証することができる。(カード発行者は、銀行、クレジットユニオンまたは口座を使って消費者が取引を行うことができるように、消費者のために口座を開設できる他の機関となり得る。)消費者および消費者のデータが認証された後に、この情報は業者に送られる。次に業者は、発行者が消費者および消費者のデータを認証したことを知って、取引を進めることができる。クレジットカードの発行者が消費者および消費者のデータを認証すると、後でその取引が詐欺であると判断された場合、発行者がリスクを負う場合がある。したがって、本発明の実施形態を使用すれば、業者およびカード発行者は、行われている取引が正当であるとの、より高い確信を有し得る。
【0016】
以下、本発明の特定の実施形態の多くを詳細に説明する。一部の場合、次のような頭辞略語を使用する。
ACS:アクセス制御サーバ−アクセス制御サーバは、取引、例えば遠隔または対面購入取引中に、提示者(例えば消費者、カード所有者)を認証できる能力をカード発行者に提供できる。
DS:ディレクトリーサーバ−ディレクトリーサーバを使って、業者プラグイン(MPI)と発行者のACSとの間で入会および認証情報を含むメッセージをルーティングできる。
IVR:相互対話音声応答ユニット−相互対話音声応答ユニットは、通常の電話の通話を通してコンピュータ装置が音声およびタッチトーンを検出できるようにする電話技術を含むことができる。
SMS:ショートメッセージサービス−ショートメッセージサービスは、携帯電話との間で送られるメッセージを含むことができる。典型的なSMSメッセージによって、ユーザーはメッセージ当たり160個までの文字を送ることができる。
MPI:業者プラグイン−業者プラグインは、一部の実施形態では取得者のドメイン内で作動するコンポーネントとなり得る。オンライン環境では、この業者プラグインは、業者のために種々の認証機能を実行する。かかる機能として、カード番号に関して認証を利用できるかどうかを判断すること、および認証メッセージ内のデジタル署名の有効性の判断をすることが挙げられる。この業者プラグインでは、業者にアクセスできる適当なハードウェアおよび/またはソフトウェアによって具現化できる。
MSISDN:モバイル加入者用ISDN番号−モバイル加入者用ISDN(統合サービスデジタルネットワーク)番号は、消費者の電話番号とすることができる。
USSD:非構造化補助サービスデータ−非構造化補助サービスデータは、GSMネットワークのチャンネルを通した情報の伝送をサポートするためのGSM(モバイル通信のためのグローバル通信)に組み込まれた機能を有する。USSDは、セッションに基づく通信機能を提供し、よって種々のアプリケーションを可能にする。
WAP:無線アプリケーションプロトコル−WAPブラウザは、PC(パソコン)に基づくウェブブラウザの基本サービスのすべてを提供でき、このWAPブラウザは、携帯電話の制限内で運用できるように簡略化できる。
【0017】
上記のように、本発明の実施形態は特に遠隔取引を行うのに有効である。形態または地上回線音声通話、ショートメッセージサービス(SMS)メッセージなどを含むが、これらだけに限定されない通信を通して、遠隔取引を行うことができる。種々のデータ転送プロトコル(例えばTCP/IP)も使用できる。携帯電話、スマートフォン、インターネット接続されたコンピュータまたはターミナル、パーソナルデジタルアシスタント(PDA)などを含むが、これらに限定されないデバイスからも、遠隔取引を開始できる。
【0018】
本発明の実施形態は、携帯電話の使用および遠隔取引だけに限定されるものではなく、本発明の実施形態は、種々の通信デバイス、支払いチャンネルおよび認証チャンネルの使用も含むことができる。次に、通信デバイス、支払いチャンネルおよび認証チャンネルの数例について記載する。
【表1】
【0019】
次に、図を参照し、本発明の特定の実施形態について説明できる。一実施形態では、エリアス識別子を受け取る。このエリアス識別子は、提示者(例えば消費者)の口座に対する(口座番号のような)口座識別子に関連したものである。エリアス識別子は、電話番号でよく、口座識別子はクレジットカードの口座番号のような口座番号でもよい。エリアス識別子が受信された後に、このエリアス識別子を使って信頼できる関連当事者を決定する。この信頼できる当事者を、クレジットカードの口座番号を提示者に発行した発行者とすることができる。
【0020】
次に、信頼できる関連当事者を決定した後に、この信頼できる当事者へ検証リクエストメッセージを送ることができる。検証リクエストメッセージは、信頼できる当事者または提示者が認証プログラムに参加している旨の検証をリクエストする。例えばこのメッセージは、提示者および信頼できる当事者の一方または双方が認証プログラムに参加している旨の検証をリクエストできる。検証リクエストメッセージが送られた後に、検証応答メッセージが受信される。この検証応答メッセージは、信頼できる当事者または提示者は認証プログラムに参加しているかどうかを示す。
【0021】
検証応答メッセージを受信した後に、消費者によって操作されている通信デバイス(例えば電話)に認証リクエストメッセージを送ることができる。次に消費者は、この消費者を認証する認証応答メッセージの送信を開始できる。消費者が認証された後に、消費者は行おうとしている取引を続けることができる。取引は購入取引、送金などとすることができる。
【0022】
図1は、本発明の一実施形態に係わるシステムを示す。図1のシステムは、インターネットを通すか、または電話(例えば携帯電話)を使って行われるような遠隔取引を行うのに使用できる。
【0023】
このシステムのコンポーネントは、提示者ドメイン、相互運用可能性ドメインおよび信頼できる当事者ドメイン内に設けられていることを特徴とし得る。本発明の別の実施形態では、このシステムにおけるコンポーネントは他のタイプのドメイン、すなわち異なるドメイン内にも存在し得る。本発明の一実施形態に係わるシステムは、単一ドメインまたはドメインの適当な任意の組み合わせ内にある任意の数のコンポーネントまたはこれらコンポーネントの組み合わせを含むことができる。図1における実施形態では、認証システムは、相互運用可能性ドメイン(interoperability domain)および発行者/信頼できる当事者ドメイン内に示されたコンポーネントを含むことができる。
【0024】
図1は、業者22と通信している提示者21を示す。業者22は、ウェブページインターフェース23を提供でき、このウェブページインターフェース23は、発行者のルックアップシステム24に結合できる。発行者のルックアップシステム24は、業者プラグイン(MPI)28、ディレクトリサーバ27、アクセス制御サーバ25、提示者のファイルデータベース26だけでなく、チャレンジインターフェース29にも作動的に結合できる。
【0025】
図1では、提示者ドメインは、提示者21と業者22とを含む。提示者21は、ユーザー、個人または消費者とすることができ、これらユーザー、個人または消費者のアイデンティティは認証中であり、および/またはこれらユーザー、個人、消費者のデータは有効性の判断中または提供中である。業者22は受領者の一例であり、提示者21は取引しようと試みている相手の当事者となり得る。提示者21は、インターネット22を通して、または通信デバイス、例えば携帯電話またはコンピュータ装置を直接使用することによって、認証システムにアクセスできる。
【0026】
データ認証システムは、認証プログラムを作動させることができ、信頼できる当事者または信頼できる当事者によって作動されるコンポーネントを含むことができる。信頼できる当事者は、提示者のアイデンティティを認証し、提示者21に関連するデータの有効性の判断、データの提供または更新するエンティティとすることができる。一部の実施形態では、信頼できる当事者は、銀行、クレジットまたはデビットカード発行銀行、またはクレジットまたはデビットカードサービス機構(例えばVisa)とすることができる。図示して説明するように、銀行はこの提示者が使用するクレジットカードの発行銀行とすることができる。提示者21は、この銀行の顧客とすることができる。信頼できる当事者は、提示者21との間で確立された関係を有することができるので、提示者21を認証するのに使用できる提示者のプロファイルデータを有することができる。この提示者のプロファイルデータとして、提示者のソーシャルセキュリティ番号、誕生日、口座番号、配達先住所、好みなどを挙げることができる。
【0027】
信頼できる当事者は、アクセス制御サーバ25(ACS)を所有または作動させることができ、このサーバは、特に認証プログラムへのアクセスを制御し、リクエストされたデータサービスを実行し、認証サービスに関係するデジタル署名された通知を受領者に提供するコンピュータ装置とすることができる。信頼できる多数の当事者が1つのACSを共用してもよいし、またはACSに一人の信頼できる当事者を関連させてもよい。これとは異なり、各々が提示者のサブセットに関連するような多数のアクセス制御サーバを信頼できる一人の当事者が有してもよい。
【0028】
本明細書で使用するような「サーバ」なる用語は、一般に強力なコンピュータまたはコンピュータのクラスター(群)のことである。例えばサーバは巨大なメインフレームでもよいし、ミニコンピュータクラスターでもよいし、またはユニットとして機能するサーバのグループでもよい。一例では、サーバはウェブサーバに結合されたデータベースとすることができる。更にサーバは、1つ以上のクライアントコンピュータまたはポータブル電子デバイスのリクエストにサービスする単一のコンピュータとして作動できる。
【0029】
提示者のファイルデータベース26は、信頼できる当事者が管理するか、または信頼できる当事者に関連するデータベースとすることができる。このデータベースは認証プログラム内への加入に成功した提示者に関する情報を記憶できる。かかる情報として、プログラムアイデンティティ番号および口座番号のような識別子、プロファイルデータおよびパスワードを挙げることができる。
【0030】
相互運用可能性ドメインは、ディレクトリサーバ27も含む。この相互運用可能性ドメインは、一部の実施形態では信頼できる当事者および受領者の双方が使用するコンポーネントを含むことができる。ディレクトリサーバ27は、提示者がデータ認証サービスを利用できるかどうかを判断できる。一部のケースでは、Visaのようなサービス機構によってディレクトリサーバ27を作動させることができる。
【0031】
データ認証サービスシステム内の提示者と、信頼できる当事者と、受領者との間のそれぞれの関係によって広いレンジのサービスを提供することが可能となっている。かかるサービスの例として、アイデンティティ認証、プロファイルの有効化、プロファイルデータ提供およびプロファイルデータ更新を挙げることができる。プロファイルの有効性判断の一実現例は、提示者のアドレスの有効性を判断するように作動し、プロファイルデータ更新の一実現例は、提示者の口座情報を更新するように作動する。
【0032】
提示者21と業者22との間の支払いを伴わない関連する取引および支払いを伴う関連する取引において、認証システムを使用できる。支払いに関連する取引において、別の作動、例えば金融口座からのデビットおよびクレジットの認証を行うこともできる。発行者の認証および決済システムのような別のシステムも使用できる。
【0033】
次に、提示者の加入プロセスについて説明する。一実施形態では、提示者21は認証プログラムに参加するために、信頼できる当事者と共に登録される。登録に成功すると、信頼できる当事者は提示者にプログラムアイデンティティ番号(または他のエリアス識別子)および認証パスワード、トークンまたは他の認証要素を提供またはこれらを割り当てることができる。認証パスワード、トークンまたは他の認証要素によって、信頼できる当事者は、提示者21のアイデンティティを認証することが可能となる。その理由は、信頼できる当事者および提示者21しかパスワード、トークンまたは他の認証要素を知らないからである。ある方法でエリアス識別子および/または認証要素を通信デバイス(例えば電話)に関連させることができる。例えばエリアス識別子を電話番号とし、認証要素を電話用のSIMカード番号とすることができる。
【0034】
プログラムアイデンティティ番号とは、認証プログラムを使用するのに、適正に入会している提示者を識別する番号のことである。プログラムアイデンティティ番号またはエリアス識別子は、一般に口座識別子、例えば提示者21に関連する口座番号にリンクできる。
【0035】
プログラムアイデンティティ番号は任意の適当なタイプの数を含むことができる。プログラムアイデンティティ番号の一例として、乱数または一連の数字から生じた数字を挙げることができる。一実施形態では、プログラムアイデンティティ番号を電話番号とすることができる。このことは、その電話番号を有する電話を使って音声またはショートメッセージサービス(SMS)メッセージにより、認証システムと提示者21が相互対話するケースで便利である。取引を行う際に、提示者の口座番号の代わりにプログラムアイデンティティ番号を使用してもよい。
【0036】
本発明の実施形態では、アイデンティティ番号を一般に通信デバイスまたは通信サービスアドレスまたは識別子(例えば電話番号、eメールアドレス)などに対応させることができる。電話番号をアイデンティティ番号として使用する場合、システムは提示者の電話番号を自動的に決定するために自動番号識別(ANI)サービスのようなサービスを使用してもい。これとは異なり、提示者21の音声を使用するか、または提示者の電話に電話番号をマニュアルで入力することにより、提示者21に対して提示者の電話番号を提供することを求めてもよい。
【0037】
本発明の実施形態では、アイデンティティ番号は追加情報、例えば口座識別子(例えば口座番号)または受領者識別番号の少なくとも一部を含んでもよい。例えば実施中の取引がクレジットカードを必要とする場合、追加情報を、カード口座番号の最初の6桁に対応するクレジットカード発行者の銀行識別番号(BIN)とすることができる。この追加識別情報は、多数の口座または受領者が所定の提示者アイデンティティ番号に関連し得るときに有効である。
【0038】
入会プロセス中、提示者21は入会データ、認証データおよびプロファイルデータを信頼できる当事者に提供できる。信頼できる当事者が提示者21を認証し、提示者が認証プログラムに参加しているかどうかを判断するように、これらタイプのデータを使って提示者のアイデンティティを検証できる。その後の取引中に提示者を認証するのに認証データを使用できる。認証データの例として、パスワード、チップカード内のユニークなデータ、生体測定データなどを挙げることができる。種々のタイプの認証データを使用できると理解すべきである。かかるデータが信頼できる当事者のもとのファイルに存在しない場合、その後の取引中にプロファイルデータを使ってプロファイルデータの有効性の判断および/またはそのデータの提供をできる。
【0039】
提示者の入会プロセスは種々の方法で行うことができる。例えばオンライン、人と人との相互対話、電話での会話またはメールを通して、この入会プロセスを行うことができる。オンライン入会プロセスの例では、提示者は入会ウェブサイトに進み、プログラムアイデンティティ番号(または他のエリアス識別子)および認証要素を得るための適当な情報を提供できる。一部の実施形態では、入会していない提示者が取引を行おうとする最初のときに、入会を自動的に開始することもできる。
【0040】
次に、図1を参照し、データ認証プログラムに関連するデータ認証プロセスについて説明できる。このデータ認証プログラムは、受領者、例えば業者22が提示者21を認証したいような種々の状況に使用できる。例えば支払いを伴わない例では提示者21は、(受領者のウェブサイトの一例である)政府のウェブサイトに進み、スモールビジネスライセンス(small business licence)のための申請書の書き込みを行うことができる。種々の政府機関は、自らのウェブサイトを通してオンラインサービスを提供している。一般に政府機関は、提示者21が入力した情報(例えば氏名、住所など)を確認したい。本発明の実施形態は、支払いを伴う例でも同じように作動できる。例えば次の例は、顧客が業者22を呼び出し、発注し、自分のクレジットカードで注文に対する支払いを計画する場合のデータ認証プログラムの作動について述べたものである。
【0041】
提示者21は、業者22が物品またはサービスに対する発注に応じることを求めることにより、取引を開始する。別の実施形態では、提示者21はウェブブラウザまたはeメールなどを使用してインターネットを通してSMSメッセージを使って、業者22と相互対話できる。
【0042】
発注後、提示者21は、可能な場合に追加識別情報、例えばBIN(銀行識別番号)および/または追加識別子で補強されたアイデンティティ番号、例えば携帯電話の番号を業者22に提供する。提示者21の口座番号の代わりにこの情報を業者22に提供することもできる。提示者21が手動で提供するのではなく、ANI(自動番号識別)のようなシステムを使って、携帯電話の番号のようなアイデンティティ番号またはアイデンティティ番号の一部を自動的に決定することもできる。
【0043】
(提示者21は、このアイデンティティ番号を認証システムに直接には入力しないと仮定した場合)業者22はアイデンティティ番号を受けた後に、この番号をデータ認証システムに入力する。業者22は、ウェブページインターフェース23を使用するか、または他の、ある手段を通して、認証システムとインターフェースできる。例えば業者22はアイデンティティ番号をウェブページインターフェース23に入力してもよい。別の実施形態では、提示者21はウェブページインターフェース23または他のあるインターフェースを通してシステムにアイデンティティ番号を直接入力できる。
【0044】
ウェブページインターフェース23によりアイデンティティ番号が受信された後に、発行者のルックアップシステム24は、アイデンティティ番号を受信し、このアイデンティティ番号に関連する発行者を判断する。一旦、対応する判断が決定されると、発行者のルックアップシステム24は、アイデンティティ番号を発行者に電子的に送る。発行者はアイデンティティ番号を口座番号に変換するのに使用される提示者のファイルデータベース26を維持する。次に、発行者のルックアップシステム24により、口座番号およびアイデンティティ番号が業者プラグイン(MPI)28へ転送される。
【0045】
次に、業者プラグイン(MPI)28は、提示者21がデータ認証プログラムに参加しているかどうかをチェックする。一実現例では、提示者21が認証プログラムに参加しているかどうかをチェックするのに、2フェーズプロセスが使用される。この2フェーズプロセスでは、ディレクトリサーバ(DS)27およびアクセス制御サーバ(ACS)25に問い合わせが行われる。ディレクトリサーバ27はアイデンティティ番号を受信し、このアイデンティティ番号に関連する発行者がデータ認証プログラムに参加しているかどうかを判断する。発行者が提示者21のアイデンティティを認証し、提示者に関係するデータサービスを提供したい場合、提示者21はデータ認証プログラムを使用できる。アイデンティティ番号を受信した後に、アクセス制御サーバ(ACS)25は、認証プログラムにより提示者21が入会しているかどうか、およびアイデンティティ番号に関連するデバイスのタイプ(例えば携帯電話)が認証システムによりサポートされているかどうかを判断する。
【0046】
発行者がデータ認証プログラムに参加していないか、または提示者21がデータ認証プログラムに入会していない場合、業者22は取引を中断するか、または他のある態様で取引を進めるかどうかを判断できる。発行者が認証プログラムに参加しているが、提示者21が入会していない場合、データ認証プログラムに入会する機会を提示者21に与えてもよい。
【0047】
発行者および提示者21の双方がデータ認証プログラムに参加している場合、およびアイデンティティ番号に関係するデバイスをプログラムで使用できる場合、アクセス制御サーバ(ACS)25は、遠隔認証リクエストメッセージを発生し、(例えば業者プラグイン(MPI)が取得者または他の信頼できる当事者のホストとなっている場合に)このメッセージは、業者プラグイン(MPI)28へ送られる。
【0048】
業者プラグイン(MPI)28は、次にチャレンジインターフェース29を通して認証チャレンジを提示者21へ発生する。このようにするために、業者プラグインは、提示者の支払いカード番号とアイデンティティ番号とを関連付ける。アイデンティティ番号が携帯電話の番号に対応している場合、この電話番号はアイデンティティ番号から抽出され、この番号を使って認証チャレンジを提示者の電話へ送る。チャレンジインターフェースモジュール29を使って、認証チャレンジを顧客の携帯電話へ送るのに、非構造化補助サービスデータ(USSD)プロトコルを使用してもよい。当業者であれば、他のプロトコルまたは通信方法も使用できることが認識できよう。例えば認証チャレンジをSMSメッセージ、自動化された予備記録電話発呼、または相互対話チャットメッセージとすることができる。
【0049】
提示者21は、認証チャレンジを受信すると、所定の認証データに応答する。例えば認証チャレンジがSMSメッセージを介して発せられた場合、提示者21はパスワードを含む応答SMSメッセージを送ることができる。電話の呼び出しにより認証チャレンジが発せられた場合、提示者21は電話のキーパッドを使うか、自分の音声を使ってパスワードを提供できる。この方法とは異なり、他のタイプの認証データ、例えば生体測定データ、チップカードデータなども使用できる。
【0050】
業者プラグイン(MPI)28が提示者の認証データを一旦受信すると、取引データ、例えばカードの口座番号および有効期限日を含むカードデータが添付され、発行者のアクセス制御サーバ(ACS)25へ送られる。発行者のアクセス制御サーバ(ACS)25は、認証データの有効性の判断をし、その有効性の判断の結果を業者プラグイン(MPI)28へレポートする。次に、業者プラグイン(MPI)28は、ウェブページインターフェース23を介して、検証の結果を業者22へ通知する。検証に成功した場合、業者22には提示者の口座識別子(例えば口座番号)またはその一部を提供できる。次に発行者には取引の詳細が通知され、取引は完了するまで続行できる。
【0051】
取引が完了した後に、ウェブページインターフェース23を使ってアイデンティティ番号に対応する提示者のデバイス(例えば電話)および業者22にメッセージを送ることができる。例えば提示者の電話番号を使用する提示者の電話に対し、提示者21が正式に認証されたこと、および取引が成功裏に完了したことを示すメッセージを送ることができる。セキュリティのレベルを高めるために、図1に示されているすべてのメッセージを暗号化できると理解すべきである。
【0052】
提示者21と業者22とが自ら取引するように本発明の実施形態を実現することもできる。提示者21ではなく、業者22に関連するアイデンティティ番号を提供することにより、業者22はシステムと相互対話できる。業者22が提示者21のアイデンティティ番号をシステムに提供することもできる。提示者21は自分のデバイスで認証チャンネルを受信し、上記のように認証データに応答できる。別の実施形態では、提示者21は業者のアイデンティティ番号および取引に対する支払い金額を提供することにより、システムと相互対話できる。
【0053】
本発明の実施形態では、提示者21が多数の支払いカード(例えば3枚以上のクレジットカード)を有し得ることに留意されたい。一実施形態では、提示者21が無線電話のような通信デバイスを使用している場合、提示者21に選択のための主要口座番号のリストを提示できる。提示者21が電話番号による取引を行うときに、取引を行うために最終的に主要デフォルト口座番号を使用するよう、この提示者のそのときの電話番号を主要デフォルト口座番号に対応させることができる。別の実施形態では、主要口座番号のリストを提示者21に提示し、取引を行う前に取引で使用する口座番号を提示者21が選択する。この場合、電話番号に関連するデフォルト口座番号は存在しなくてもよい。更に別の実施形態では、リスト内の各主要口座番号に関連する異なるエリアス識別子が存在し得る。例えば異なる3つの主要口座番号に対して、これらエリアス識別子を単に「card1」、「card2」、「card3」としてもよい。
【0054】
図2は、本発明の別の実施形態にかかわる別のシステムのブロック図を示す。ここには、メッセージのフローも示されている。図2に示されたコンポーネントの一部は、図1のコンポーネントの一部に類似する。図2は更に、業者のコールセンター42と通信する携帯電話40だけでなく、Telco(電話会社)58のインターフェースに結合されたインターフェース要素60も示しており、Telco58のインターフェースは、次に仮想カードホルダーリダイレクトモジュール56に結合されている。図2には特に発行者12および取得者14も示されている。
【0055】
この実施形態では、提示者21はクレジットカード(または他のある支払いデバイス)を使って、業者22との購入取引を開始する。カード取引について詳細に説明するが、この取引は上記とは異なり、ストアードバリューカード(stored value card)、デビットカード、無接点電話、スマートカードなどで実施することもできる。
【0056】
提示者21は、業者のコールセンター42を呼び出すのに自分の携帯電話40を使用する(ステップ1)。提示者21は次に(例えば音声によるか、または電話番号を電話40に入力するなどして)エリアス識別子、例えばアイデンティティ番号を提供する。このアイデンティティ番号は、携帯電話40に関連する電話番号の一部またはすべてを含むことができる。追加識別子情報は、提示者21が保有するクレジットカードのクレジットカード番号に関連するBIN(銀行識別番号)などを含むことができる。別のタイプのエリアス識別子は、ニックネームでもよいし、または使用中の特定のクレジットカードに対して提示者21が割り当てた他のエリアスでもよい。次に業者22は、エリアス識別子のうちの1つ以上を業者のウェブページインターフェース23に入力できる(ステップ2)。
【0057】
業者プラグイン(MPI)28は、エリアス識別子を受信し、この識別子は検証リクエストメッセージ(VE Req(m))内でディレクトリサーバ(DS)48へ送られる(ステップ3)。ディレクトリサーバ48は、検証リクエストメッセージを受信した後に、提示者21に対する認証を利用できるかどうかを判断するように、アクセス制御サーバ25に問い合わせを行う(ステップ3)。この例では、検証リクエストメッセージ(VE Req(m))は、エリアス識別子、例えば携帯電話40の電話番号を含む。
【0058】
アクセス制御サーバ(ACS)25は、ディレクトリサーバ48にメッセージを通過させることにより、検証応答(VE Res(m))メッセージを送ることにより応答する(ステップ4)。検証応答メッセージを受信した後に、業者プラグイン(MPI)28は、ディレクトリサーバ(DS)48を通して、アクセス制御サーバ(ACS)25に支払い認証リクエストメッセージ(PA Req(m))を送る。次にアクセス制御サーバ(ACS)25は、モバイル認証リクエストメッセージを発生し(ステップ6)、このメッセージは仮想カードホルダーリダイレクトモジュール56を介して電話会社(Telco)のインターフェース58へ送られる。このようにするために、ディレクトリサーバ(DS)48は、提示者のクレジットカード番号と、その提示者の電話番号とを再関連付けし、Telcoのインターフェース58を介して提示者21にアクセスできるインターフェース要素60にコンタクトする(ステップ6および7)。インターフェース要素60は、携帯電話60上のユーザーインターフェースを含むことができるし、または携帯電話40を除くデバイス上のユーザーインターフェースを含むこともできる。
【0059】
次に認証リクエストメッセージは提示者21へ送られ、所定のパスワードまたは他の認証データで応答するよう、提示者21を促す(ステップ7)。ステップ8では、認証データに、使用中のクレジットカードに関連するカード番号が再添付され、Telcoのインターフェース58を介し、発行者のアクセス制御サーバ(ACS)25へ補助応答メッセージが送られる。ステップ9では、提示者21からのパスワードを含む認証応答メッセージを受信した後に、発行者12はパスワードの有効性を判断する。発行者12がパスワードを有効であると判断した後に、発行者12は業者プラグイン(MPI)28へ支払い認証応答(PA Res(m))メッセージを送る(ステップ9)。
【0060】
一部の実施形態では、支払い認証応答(PA Res(m))メッセージは、提示者21に関する追加情報(例えば送り先住所、コンタクト情報、例えばeメールアドレス、好みなど)を含むことができる。例えば提示者21の送り先アドレスを発行者のACS25から業者プラグイン(MPI)28へ送ってもよい。かかる実施形態では、業者22がかかる追加情報を維持する必要がないことが好ましい。したがって、提示者21により取引を開始した後に、発行者12が以前収集した任意の適当な情報を、業者22へ送ってもよい。
【0061】
ステップ10では、ウェブページインターフェース23を使って、認証プロセスの結果が業者22の被雇用者に伝えられる。ステップ11において、業者プラグイン(MPI)28から業者の取得者14へ応答メッセージ11が送られる。取得者30は、Telcoのインターフェース58を介して提示者21へ、およびウェブページインターフェース23を介して業者22へ、メッセージを送ることにより、取引を完了する。
【0062】
別の実施形態では、提示者21は業者のコールセンター42を経由することなくウェブページインターフェース23を介して業者のウェブサイトと相互対話できる。提示者21は、自分のアイデンティティ番号を「支払いページ」に入力でき、その後、インターフェース要素60上で認証チャレンジを受信する。
【0063】
図2に示されたフローは、多数の利点を有する。例えば図2において、業者22が、提示者21が使用しているクレジットカードの実際の口座番号を見なくても、または所有していなくても、提示者21を迅速かつ効率的に適正に認証できる。一部の業者または業者の被雇用者が、提示者の支払い口座番号を不正に使用する可能性があるので、このことは提示者21に対して更に高いセキュリティを提供できる。
【0064】
図3には、本発明の別の実施形態にかかわるシステムの別のブロック図が示されている。このシステムは、提示者ドメイン内にある携帯電話72を含む。業者プラグインインターフェース74は、取得者ドメイン内にあり、この取得者ドメイン内の取引開始コンポーネント84と通信する。ディレクトリサーバ76とレポートサーバ78とは、相互運用可能性ドメイン内にあり、アクセス制御サーバ80と登録サーバ82は発行者ドメイン内にある。この実施形態では、モバイル認証コンポーネント86とモバイル登録コンポーネント88は、取得者ドメイン、相互運用可能性ドメインおよび発行者ドメイン内で働くことができる。
【0065】
上記とは異なり、携帯電話72はデータを送信および/または受信できる任意の適当な通信デバイス(例えば固定電話、インターネット上のPCなど)とすることができる。上記のように、消費者(または提示者)は、携帯電話の番号、携帯電話の番号+チェック数字、または他の適当なエリアス識別子に基づき、取引を開始できる。エリアス識別子は、支払い口座番号に対する代替手段として使用できる。消費者は取引を開始し、および/または取引を認証するように自分の携帯電話または携帯電話番号/エリアスも使用できる。消費者は認証プログラム登録をするのに、自分の携帯電話も使用できる。
【0066】
提示者のリクエスト時に、取引開始コンポーネント84により業者は支払いプロセスを開始することが可能となる。この取引開始コンポーネント84は、ハードウェア、ソフトウェアの適当な任意の組み合わせの形態にすることができる。一部のケースでは、このコンポーネントは(例えばPOSターミナル内にあるか、またはこのPOSターミナルに接続された)業者によって操作されるハードウェア内に存在してもよい。取引開始コンポーネント84は、ウェブページがインターネット環境内の標準的MPIと通信するのと同じように、業者プラグイン(MPI)74と通信できる。
【0067】
従来の実施形態と同じように、取引が開始されるときに、提示者の支払いカードの番号を業者に提供しないことが望ましい。その代わりにモバイル取引インジケータと共に提示者の電話番号/エリアスまたは他の識別子に基づいて取引を開始する。
【0068】
取引開始コンポーネント84は、あるレンジの取引開始シナリオを促進できる。このシナリオは、消費者の携帯電話の番号を自動的に業者プラグイン(MPI)74に送ることを可能にするシナリオと、消費者の携帯電話の番号をマニュアルで入力できるようにするシナリオとに分割できる。上記のように、IVR、USSD、SMSまたはWAPを使って、携帯電話の番号を業者プラグイン(MPI)74に自動的に送ってもよい。この方法とは異なり、電話番号をシステム内にマニュアルで入力してもよい。例えばこの電話番号は、PCに向かっているコールセンターのエージェント、受け取りデバイスとして自分の携帯電話を使用するモバイル業者などにより、認証システムへマニュアルで入力してもよい。取引開始コンポーネント84は、提示者に取引のステータスを通知するよう、業者に対し、後方向(backwards)の通信チャンネルも提供できる。
【0069】
業者プラグイン(MPI)74は、多数の機能を実行できる。例えばこのプラグインは、カード番号を使用することなく、携帯電話の番号に基づき、取引の処理を促進できる。更にこのプラグインは、検証メッセージ内に携帯チャンネル/デバイス識別子を含ませ、よって携帯チャンネルを介して取引を認証することを発行者に促すこともできる。更にこのプラグインは、それぞれの発行者による新しい提示者のオンライン加入を可能にするように、業者側への後方向の通信も提供できる。
【0070】
ディレクトリサーバ(DS)76も多数の機能を提供する。このサーバは、携帯電話の番号および/または他のエリアス識別子をDIN(銀行識別番号)にマッピングでき、認証リクエストを適当な発行者にルーティングすることを可能にする。消費者が自分のカード、電話番号またはエリアス識別子を変更したい場合、アクセス制御サーバ(ACS)80から(逆の場合も同様)携帯電話番号および/またはエリアス識別子および/またはBIN番号を更新できる。また、ディレクトリサーバ(DS)76は、取引開始コンポーネント84および業者プラグイン(MPI)74と共同して、適当な発行者による新しい提示者のオンライン加入も容易にできる。
【0071】
レポートサーバ78はレポートを提供する。このサーバは、携帯電話の番号および/またはエリアス識別子も記録できる。
【0072】
アクセス制御サーバ(ACS)80は、多数の機能を実行できる。例えば識別された取引を受信すると、このサーバはモバイル認証コンポーネント86を介した、携帯電話72への認証リクエストメッセージの送信を開始できる。ポジティブな認証応答メッセージを受信すると、アクセス制御サーバ(ACS)80は、提示者の携帯電話の番号を提示者の登録されたPAN(主要口座番号)に変換できる。
【0073】
モバイル認証コンポーネント86は、取引を認証するために提示者とアクセス制御サーバ(ACS)80との間で双方向のモバイルチャンネルを提供する。この双方向のチャンネルは、IVR、WAPまたは提示者の携帯電話72にローディングされたクライアントアプリケーションを含むことができる。
【0074】
登録サーバ82は、登録機能を提供すると共に、携帯電話番号および/またはかかるデータのためのエリアスフィールドを含む。
【0075】
モバイル登録コンポーネント88は、提示者と登録サーバ82との間で双方向のモバイルチャンネルを提供する。このチャンネルは、提示者の認証プログラムに登録するのに使用され、提示者の登録された携帯電話72が正しいことを保証するように使用される。モバイルチャンネルの例として、IVR、WAPまたは提示者の携帯電話にロードされるクライアントアプリケーションを挙げることができる。このチャンネルは、モバイル認証コンポーネント86と同じでもよいし、またはこのコンポーネントに基づくものでもよい。
【0076】
図4は、支払い取引を開始する前に、提示者がデータ認証プログラムに登録する場合のプロセスフローを示す。この例では、提示者はモバイルチャンネルを通し、特定の口座を登録できる。
【0077】
図4を参照すると、提示者は自分の携帯電話72を使って、発行者に関連する口座を発行者の認証プログラムに登録する。これを行うために、携帯電話72は発行者のモバイル登録コンポーネント88と通信することができる。モバイル登録コンポーネント88は、着信登録リクエストを変換し、これを発行者の登録サーバ82(ステップ102)へ転送する。発行者の登録サーバ82は、携帯電話72のためのMSISDNがモバイルチャンネルを通過したかどうかをチェックする(ステップ103)。
【0078】
モバイルチャンネルを介し、携帯電話72のためのMSISDNが提供される場合、発行者の登録サーバ82は、提示者からの別の口座データをリクエストし、モバイル登録コンポーネント88に口座データリクエストを送る(ステップ104)。モバイル登録コンポーネント88は、モバイルチャンネルおよび提示者のデバイス能力に基づき、リクエストを適合させ、これを提示者の携帯電話72へ送る(ステップ105)。次に、提示者は携帯電話72を使用し、口座データをモバイル登録コンポーネント88へ伝送し戻す(ステップ106)。次に、モバイル登録コンポーネント88は、口座データを変換し、それを発行者の登録サーバ82へ転送する(ステップ107)。
【0079】
代替フローAに示されるように、モバイルチャンネルによりMSISDNが提供されない場合、発行者の登録サーバ82は、リクエストをモバイル登録コンポーネント88へ送ることにより、提示者からのMSISDNを含む別の口座データをリクエストする(ステップA−1)。次に、モバイル登録コンポーネント88は、モバイルチャンネルおよび提示者のデバイス能力に基づきリクエストを適合させ、それを提示者の携帯電話72へ送る(ステップA−2)。次に、提示者は、携帯電話72を使って口座データおよびMSISDNをモバイル登録コンポーネント88へ送り戻す(ステップA−3)。次に、モバイル登録コンポーネント88は、口座データおよびMSISDNを変換し、それを発行者の登録サーバ82へ転送する(ステップA−4)。発行者の登録サーバ82は、この情報を受信した後に、モバイル登録コンポーネント88へ登録確認リクエストを送る(ステップA−5)。モバイル登録コンポーネント88は、メッセージングモバイルチャンネル(例えばSMS、USSD)に基づき、リクエストを適合させ、それを提示者の携帯電話72へ送る(ステップA−6)。提示者は確認リクエストを受信し、そのリクエストを受け入れ、モバイル登録コンポーネント88へ転送し戻す(ステップA−7)。モバイル登録コンポーネント88が確認応答を変換し、それを発行者の登録サーバ82へ転送する(ステップA−8)。次に発行者の登録サーバ82は、ペンディング中の提示者の登録ステータスを更新する(ステップA−9)。
【0080】
ある点において、登録サーバ82は、提示者の登録ステータスの有効性をチェックする(ステップ108)。
【0081】
提示者の登録が受け入れ可能である場合、発行者の登録サーバ82は、パスワード作成リクエストをモバイル登録コンポーネント88へ送ることができる(ステップ109)。モバイル登録コンポーネント88は、モバイルチャンネルおよび提示者のデバイス能力に基づき、リクエストを適合させ、それを提示者の携帯電話72へ送る(ステップ110)。提示者は携帯電話72を使って、パスワードを提供し、このパスワードをモバイル登録コンポーネント88へ伝送し戻す(ステップ111)。モバイル登録コンポーネント88は、パスワードを変換し、それを発行者の登録サーバ82へ転送する(ステップ112)。次に、発行者の登録サーバ82は、登録通知をモバイル登録コンポーネント88へ送る(ステップ113)。モバイル登録コンポーネント88は、モバイルチャンネルおよび提示者のデバイス能力に基づき、その通知を適合させ、それを提示者の携帯電話72へ送る(ステップ114)。次に発行者の登録サーバ82は、提示者の口座番号の一部により、アクセス制御サーバ80を更新する(ステップ115)。
【0082】
代替フローBでは、提示者の登録に失敗している。発行者の登録サーバ82は、モバイル登録コンポーネント88に登録通知エラーを送る(ステップB−1)。モバイル登録コンポーネント88は、モバイルチャンネルおよび提示者のデバイス能力に基づき、エラーメッセージを適合させ、そのエラーメッセージを提示者の携帯電話72へ送る(ステップB−2)。
【0083】
代替フローCは、発行者が発生したパスワードに関するものである。このプロセスフローでは、発行者の登録サーバ82は、(例えば提示者による入力がなくても)ユニークなパスワードを発生する(ステップC−1)。発行者の登録サーバ82は、発生したパスワードをモバイル登録コンポーネント88へ送る(ステップC−2)。モバイル登録コンポーネント88は、モバイルチャンネルおよび提示者のデバイス能力に基づき、メッセージを適合させ、メッセージを提示者の携帯電話72へ送る(ステップC−3)。
【0084】
図5は、モバイルチャンネルを通した支払い取引中の登録のためのフローチャートを示す。図5を参照すると、提示者は取引開始コンポーネント84を介して、支払い取引を開始する(ステップ201)。取引開始コンポーネント84は、取引の詳細を変換し、それを業者プラグイン(MPI)74へ転送する(ステップ202)。次に、図6に示されており、以下、更に詳細する開始する支払い取引プロセスを実行する。業者プラグイン(MPI)74は、リターンされた提示者の加入ステータスをチェックする。提示者が登録されている場合、図7に示されており、以下更に説明する支払い認証プロセスを実行しながら、ステップ218でフローが続く。
【0085】
提示者が登録されなかった場合、業者プラグイン(MPI)74は、取引開始コンポーネント84へBIN(銀行識別番号)情報のためのリクエストを送る(ステップ204)。取引開始コンポーネント84は、モバイルチャンネルおよび提示者のデバイス能力に基づき、リクエストを適合させ、このリクエストを提示者の携帯電話72へ送る(ステップ205)。提示者は携帯電話72を使って、リクエストされたBIN情報を提供し、この情報を取引開始コンポーネント82へ伝送し戻す(ステップ206)。取引開始コンポーネント84はリクエストされた口座データを変換し、このデータを業者プラグイン(MPI)74へ転送する(ステップ207)。次に業者プロセス(MPI)74は、ディレクトリサーバ76へ収集した口座データを送ることにより、発行者の参加ステータスをリクエストする(ステップ208)。ディレクトリサーバ76は、この情報を受信した後に、発行者の登録ステータスをチェックする(ステップ209)。次にディレクトリサーバ76は、発行者の登録ステータスを業者プラグイン(MPI)74へ送り戻す(ステップ(210)。業者プラグイン(MPI)74は発行者の登録ステータスをチェックする(ステップ211)。
【0086】
発行者が認証プログラムに参加した場合、業者プラグイン(MPI)74は提示者の登録リクエストをディレクトリサーバ76へルーティングする(ステップ212)。次に提示者を正式に登録するよう、発行者に対してBINおよび電話番号が送られる。次にディレクトリサーバ76は、提示者の登録リクエストをアクセス制御サーバ(ACS)80へルーティングする(ステップ213)。アクセス制御サーバ(ACS)80は提示者の登録リクエストを発行者の登録サーバ82へルーティングする(ステップ214)。次に発行者の登録サーバ82は、提示者の登録リクエストをモバイル登録コンポーネント88へ送る(ステップ215)。モバイル登録コンポーネント88は、モバイルチャンネルおよび提示者のデバイス能力に基づき、リクエストを適合させ、このリクエストを提示者の携帯電話72へ送る(ステップ216)。次に図4に示された提示者登録プロセスを実行できる(ステップ217)。提示者の登録に成功すると、以下、より詳細に説明する図7のプロセスに従って、支払い取引が認証される。
【0087】
発行者が認証プログラムに参加していないケースでは、業者プラグイン(MPI)74は、「発行者無登録」タイプのエラーメッセージを取引開始コンポーネント84へ送る。この取引開始コンポーネント84は、モバイルチャンネルおよび提示者のデバイス能力に基づき、リクエストを適合させ、このリクエストを提示者の携帯電話72へ送る(ステップ2A−1)。この場合、認証は行われず、支払い取引を放棄できる。
【0088】
図6は、提示者が支払い取引を開始するプロセスのためのフローチャートを示す。このプロセスは、提示者がモバイルチャンネルを通して業者/取得者と支払い取引を開始すると決定したときにスタートする。このプロセスは、モバイルチャンネルを通し、支払い取引の開始に成功したときに(まだ認証されていない)、終了できる。
【0089】
図6を参照すると、提示者は取引開始コンポーネント84を通して自分の携帯電話72を使って支払い取引を開始する(ステップ301)。取引開始コンポーネント84は、支払い開始リクエストを変換し、このリクエストを業者プラグイン(MPI)に転送する(ステップ302)。業者プラグイン(MPI)は、MSISDN(携帯電話番号)がモバイルチャンネルを通過したことを検証する(ステップ303)。次に、業者プラグイン(MPI)64は、検証加入リクエスト(VE req)メッセージをディレクトリサーバ76へ送る(ステップ304)。ディレクトリサーバ76は、このメッセージを受信した後に、提示者の加入ステータスに関してアクセス制御サーバ(ACS)76に問い合わせをする。アクセス制御サーバ(ACS)76は、提示者の加入ステータスをディレクトリサーバ(DS)76へ戻す(ステップ306)。ディレクトリサーバ76は、検証加入応答(VE res)メッセージを業者プラグイン(MPI)74へ戻す(ステップ307)。加入応答ステータスを受信した後に、提示者は図5で説明されている登録プロセス(支払い取引中の登録)をスタートできる。
【0090】
モバイルチャンネルによってMSISDNが提供されない場合、業者プラグイン(MPI)74は、取引開始コンポーネント84を通して提示者のMSISDNをリクエストする(ステップ3A−1)。取引開始コンポーネント84は、モバイルチャンネルおよび提示者のデバイス能力に基づき、リクエストを適合させ、このリクエストを提示者の携帯電話72に送る(ステップ3A−2)。次に提示者は、MSISDNを取引開始コンポーネント84に送り戻す(ステップ3A−3)。取引開始コンポーネント84は、MSISDNを変換し、それを業者プラグイン(MPI)74に転送する(ステップ3A−4)。
【0091】
図7は、提示者が認証しなければならない、支払い取引を開始した場合のプロセスを示す。このプロセスは、提示者が支払い取引を開始し、取引を終了するための認証の用意ができたときにスタートする。認証が終わると許可を行うことができる。
【0092】
図7を参照すると、業者プラグイン(MPI)74は、支払い者認証リクエスト(PA req)メッセージをアクセス制御サーバ80へ送る(ステップ401)。次にアクセス制御サーバ80は、認証リクエスト(MSISDNに関連する2つ以上の口座識別子が存在し得る)をモバイル認証コンポーネント86へ送る(ステップ402)。このメッセージを受信後、モバイル認証コンポーネント86は、モバイルチャンネルおよび提示者のデバイス能力に基づき、リクエストを適合させ、それを提示者の携帯電話72へ送る(ステップ403)。
【0093】
提示者は携帯電話72を使ってリクエストされた認証データ(例えばパスワード)を提供し、この認証データを含む応答をモバイル認証コンポーネント86へ送り戻す(ステップ404)。モバイル認証チャンネルは、応答を変換し、有効性の判断のためにその応答をアクセス制御サーバ(ACS)80へ送る(ステップ405)。次にアクセス制御サーバ(ACS)80は認証応答を受信し、受信した認証データをチェックする(ステップ406)。次にアクセス制御サーバ(ACS)80は、支払い者認証応答(PA Res)メッセージを業者プラグイン(MPI)74へ送り戻す(ステップ407)。次に業者プラグイン(MPI)74は、認証応答メッセージをチェックする(ステップ408)。
【0094】
消費者が認証された場合、即時許可が適当であるかどうかの判断が行われる。この即時許可が適当である場合、プロセスは、図8に示され、以下により詳細に説明する許可プロセスに進むことができる(ステップ4B−1)。即時許可が適当でない場合、業者プラグイン(MPI)74は、支払い未決通知メッセージをモバイル認証コンポーネント86へ送る(ステップ409)。モバイル認証コンポーネント86は、モバイルチャンネルおよび提示者のデバイス能力に基づき、通知を適合させ、それを提示者の携帯電話410へ送る。次に図8に示されており(かつ、以下により詳細に説明するような)認証された支払い取引プロセスを実行する(ステップ411)。
【0095】
提示者が認証されないときには、図7の代替フローAが生じ得る。アクセス制御サーバ(ACS)80は、発行者の認証規則に応じ、モバイル認証コンポーネント86を通して、提示者に認証リクエストを再発行してもよいし、または認証の試行回数に達した旨を提示者に通知してもよい。認証試行回数に達した場合、業者プラグイン(MPI)は、「認証試行回数限度到達」タイプの通知をモバイル認証コンポーネント86へ送る(ステップ4C−1)。モバイル認証コンポーネント86は、モバイルチャンネルおよび提示者のデバイス能力に基づき、通知を適合させ、それを提示者の携帯電話72へ送る(ステップ4C−2)。認証試行回数に達していない場合、プロセスはステップ402へ戻ることができ、認証試行回数に達するまでプロセスを続けることができる。
【0096】
図8は、認証された支払い取引を許可しなければならないプロセスを説明できる。この許可は、即座に行ってもよいし延期してもよい。提示者が支払い取引を認証したときに、このプロセスはスタートし、支払い認証に成功したときに、このプロセスは終了する。
【0097】
図8を参照すると、業者プラグイン(MPI)は、支払い許可プロセスを許可システム70へ送る(ステップ501)。許可システム70は、支払い許可を処理する(ステップ502)。許可システム70は、次に支払い許可応答をアクセス制御サーバ(ACS)80へ伝送する(ステップ503)。アクセス制御サーバ(ACS)80は、支払い許可応答を業者プラグイン(MPI)74へ伝送する(ステップ504)。次に、業者プラグイン(MPI)74は、支払い許可応答をチェックする(ステップ505)。
【0098】
支払い取引が許可された場合、業者プラグイン(MPI)74は、支払い受け入れ通知メッセージをモバイル許可コンポーネント86へ送る(ステップ506)。モバイル許可コンポーネント86は、モバイルチャンネルおよび提示者のデバイス能力に基づき、その通知を適合させ、それを提示者の携帯電話72へ送る(ステップ507)。
【0099】
支払い取引が拒否され、許可されない場合、業者プラグイン(MPI)74は、支払い拒否通知メッセージをモバイル許可コンポーネントへ送る(ステップ5A−1および5A−2)。モバイル許可コンポーネントがモバイルチャンネルおよび提示者のデバイス能力に基づき、通知を適合させ、それを提示者の携帯電話72へ送る。
【0100】
III.消費者用ポータブルデバイスおよびコンピュータ装置
【0101】
図9〜10は、本発明の実施形態に係わるシステム内で使用されるコンピュータ装置内に存在し得るポータブルコンピュータデバイスおよびサブシステムのブロック図を示す。上記一部の実施形態では、提示者は、支払いカード(例えばクレジットカード)および認証チャレンジを受けるための電話またはその他の通信デバイスを有することができる。別の実施形態では、提示者は、支払い取引を行うために電話を使用することができ、支払いデータを提供し、かつ認証チャレンジのためのインターフェースとして作動するために、電話を使用することができる。カードおよび電話は消費者用ポータブルデバイスの例であり、本発明の実施形態は、これら特定の消費者用ポータブルデバイスだけに限定されるわけではない。
【0102】
消費者用ポータブルデバイスの例は、任意の適当な形態となり得る。例えば適当な消費者用ポータブルデバイス消費者の財布および/またはポケットに入ることができるよう(例えばポケットサイズとなるよう)、ハンドヘルドかつコンパクトにし得る。これらデバイスとして、スマートカード、(磁気ストライプを有するが、マイクロプロセッサを有しない)通常のクレジットまたはデビットカード、キーチェーンデバイス(例えばエクソン−モービル社から市販されているスピードパス(SpeedpassTM)などを挙げることができる。消費者用ポータブルデバイスの他の例として、携帯電話、パーソナルデジタルアシスタント(PDA)、ページャー、支払いカード、セキュリティカード、アクセスカード、スマートメディア、トランスポンダおよび同等物がある。消費者用ポータブルデバイスは、デビットデバイス(例えばデビットカード)、クレジットデバイス(例えばクレジットカード)またはストアードバリューデバイス(例えばストアードバリューカード)でもよい。
【0103】
電話32’の形態をした消費者用ポータブルデバイスの一例は、図9(a)に示されるような本体およびコンピュータが読み取りできるメディアを含むことができる(図9(a)は、多数のコンポーネントを示し、本発明の実施形態に係わる消費者用ポータブルデバイスは、かかるコンポーネントのサブセットの適当な任意の組み合わせを含むことができる)。コンピュータが読み取りできるメディア32(b)は、本体32(h)内に存在していてもよいし、または本体から取り外し可能でもよい。本体32(h)は、プラスチック基板、ハウジングまたは他の構造体の形態とし得る。コンピュータが読み取りできるメディア32(b)は、データを記憶するメモリでよく、磁気ストライプ、メモリチップ、ユニークに派生されたキー、暗号化アルゴリズムなどを含む任意の適当な形態とし得る。このメモリは、情報、例えば金融情報、(例えば地下鉄または列車のパス内に記憶されるような)乗り換え情報、(アクセスバッジ内に記憶されるような)アクセス情報なども記憶することが好ましい。金融情報として、銀行口座情報、銀行識別番号(BIN)、クレジットまたはデビットカード番号情報、口座バランス情報、有効期限日、氏名、誕生日のような消費者の情報などを挙げることができる。この情報のいずれも、電話32’によって送信できる。
【0104】
メモリ内の情報は、従来通り、クレジットカードに関連するデータトラックのフォームでもよい。かかるトラックは、トラック1とトラック2とを含む。トラック1(「国際航空運輸協会」)はトラック2よりも多くの情報を記憶しており、カード所有者の氏名だけでなく、口座番号およびその他の自由裁量のデータも含む。このトラックは、クレジットカードによる予約を安全にする際に、航空会社によってときどき使用されている。トラック2(「米国銀行協会」)は、現在最も一般的に使用されているものである。このトラックは、ATMおよびクレジットカードチェッカーによって読み取られるトラックである。ABA(米国銀行協会)は、このトラックの仕様を設計し、すべての世界の銀行は、この仕様を守らなければならない。このトラックは、カード所有者の口座、暗号化されたPIN、プラスその他の自己裁量データを含む。
【0105】
コンピュータが読み取りできるメディア32(b)またはメモリは、任意の適当な順序で、上記ステップのうちのいずれかを実行するための符号を含むことができる。例えばコンピュータで読み取りできるメディア32(b)は、a)提示者の口座に関連する口座識別子に関連するエリアス識別子を提供するための符号、b)エリアス識別子を提供した後に認証リクエストメッセージを受信するための符号、およびc)認証リクエストメッセージを受信した後に認証応答メッセージを送るための符号を含むことができる。
【0106】
電話32’は更に無接点要素32(g)も含むことができ、この無接点要素はアンテナのような関連する無線転送(例えばデータ送信)要素を有する半導体チップ(または他のデータ記憶要素)を含むことができる。無接点要素32(g)は、電話32’に関連しており(例えば電話内に埋め込まれており)、セルラーネットワークを介して送信されるデータまたは制御命令は、無接点要素インターフェース(図示されず)により、無接点要素32(g)へ印加できる。無接点要素インターフェースは、モバイルデバイス回路(および従ってセルラーネットワーク)と光学的無接点要素32(g)との間でのデータおよび/または制御命令の交換を可能にするように機能する。
【0107】
無接点要素32(g)は、一般に規格化されたプロトコルまたはデータ転送機構(例えばISO14443/NFC)に従って、近接電磁界通信(NFC)能力(または近接電磁界通信メディア)を使って、データを転送および受信できる。この近接電磁界通信能力は、短距離通信能力、例えばRFID、ブルートゥースTM、赤外線、または電話32’と問い合わせデバイスとの間でデータを交換するのに使用できる他のデータ転送能力のことである。従って、電話32’は、セルラーネットワークおよび近接電磁界通信能力の双方により、データおよび/または制御命令を伝送し、かつ転送できる。
【0108】
電話32’は、電話32’の機能を処理するためのプロセッサ32(c)(例えばマイクロプロセッサ)と、消費者が電話番号およびその他の情報およびメッセージを見ることができるようにするディスプレイ32(d)も含むことができる。この電話32’は、更に消費者(または提示者)がデバイスに情報を入力できるようにするための入力要素32(e)と、消費者が音声通信、音楽などを聞くことができるようにするスピーカー32(f)と、消費者が電話32’を通して自分の音声を送信できるようにするためのマイク32(i)とを含むことができる。電話32’は、無線電話転送(例えばデータ送信)のためのアンテナ32(a)も含むことができる。
【0109】
上記のように、一部の実施形態では提示者または消費者は、デビット、クレジットまたはスマートカードの形態をした消費者用ポータブルデバイスを使用できる。カードの形態をした消費者用ポータブルデバイスは、オプションとして磁気ストライプのような特徴部も有することができる。かかるデバイスは、接触モードまたは無接点モードのいずれかで作動できる。
【0110】
図9(a)にはカード32”の形態をした消費者用ポータブルデバイスの一例が示されている。図9(a)は、プラスチックの基板32(m)を示す。このプラスチック基板32(m)の上には、ポイントオブセールスターミナルのようなアクセスデバイスとのインターフェースをするための無接点要素32(o)が存在していてもよいし、またはこの要素はプラスチック基板内に埋め込まれていてもよい。このカードには、消費者情報32(p)、例えば口座番号、有効期限日および消費者の氏名をプリントしてもよいし、またはエンボス加工してもよい。プリント基板32(m)には、磁気ストライプ32(n)も存在してもよい。
【0111】
図9(b)に示されるように、カード32”は磁気ストライプ32(n)および無接点要素32(o)の双方を含むことができる。別の実施形態では、カード32”内に磁気ストライプ32(n)と無接点要素32(o)の双方が存在してもよい。別の実施形態では、カード32”内に磁気ストライプ32(n)または無接点要素32(o)のいずれかが存在してもよい。
【0112】
これまで説明した図(例えば図1〜3)における種々の参加者および要素は、本明細書に説明した機能を容易にするよう、1つ以上のコンピュータ装置を使って作動できる。これら図内の要素のいずれも、本明細書に記載した機能を容易にするよう、適当な任意の数のサブシステムも使用できる。図10に示されたサブシステムは、システムバス775を介して相互に接続されており、追加サブシステム、例えばプリンタ774、キーボード778、固定ディスク779(またはコンピュータが読み取りできるメディアを含む他のメモリ)、ディスプレイアダプタ782に結合されたモニタ776、およびその他の装置が示されている。I/Oコントローラ771に結合している周辺機器および入力/出力(I/O)デバイスは、任意の数の公知の手段、例えばシリアルポート777により、コンピュータシステムに接続できる。コンピュータ装置をワイドエリアネットワーク、例えばインターネット、マウス入力デバイスまたはスキャナーに接続するのに、例えばシリアルポート777または外部インターフェース781を使用できる。システムバスを介した相互接続により、中央プロセッサ773は、各サブシステムと通信し、システムメモリ772または固定ディスク779からの命令の実行だけでなく、サブシステムの間の情報交換の制御も可能にしている。システムメモリ772および/または固定ディスク779は、コンピュータが読み取りできるメディアを具現化できる。これら要素のいずれも、前に説明した特徴部品内に存在していてもよい。例えば前に説明したディレクトリサーバおよびアクセス制御サーバは、図10に示されたこれらコンポーネントのうちの1つ以上を有することができる。
【0113】
本発明の一実施形態に係わるコンピュータで読み取りできるメディアは、上記機能のいずれかを実行するための符号を含むことができる。例えば上記ディレクトリサーバは、a)提示者の口座に関連する口座識別子に関連するエリアス識別子を提供する符号と、b)前記エリアス識別子を提供した後に、認証リクエストメッセージを受信する符号と、c)前記認証リクエストメッセージを受信した後に、認証応答メッセージを送る符号とを備えることができる。このディレクトリサーバは、コンピュータが読み取りできるメディアに結合されたプロセッサも有することができ、このプロセッサは、コンピュータが読み取りできるメディア上のコンピュータフローによって具現化される命令を実行する。
【0114】
本明細書で使用した用語および表現は、本発明を説明する用語として用いたものであり、本発明を限定するために用いたものではない。特許請求の範囲内において種々の変形が可能であることが認識できるので、かかる用語および表現の使用にあたり、図面に示し、説明した特徴部、およびその一部の均等物を排除する意図はない。更に本発明の範囲から逸脱することなく、本発明の任意の実施形態の1つ以上の特徴部を、本発明の他の実施形態の他の1つ以上の特徴部と組み合わせることができる。
【0115】
また、上記本発明は、コンピュータソフトウェアをモジュラー態様または統合態様で使用する制御ロジックの形態で実現できるとも理解すべきである。当業者であれば、本明細書に記載した開示および教示内容に基づき、ハードウェアを使用し、更にハードウェアとソフトウェアの組み合わせを使って本発明を実施するための他の手段および/または方法も想到できよう。
【0116】
「1つの」、「ある」または「この」なる記載は、特に反対のことを示さない限り、「1つ以上」のものも意味する。
【0117】
上記すべての特許、特許出願、刊行物および説明は、すべての目的のためにこれらの全内容を本明細書で参考例として援用する。これらのいずれも、従来技術として認めるものではない。
【技術分野】
【0001】
(関連出願とのクロスレファレンス)
本願はすべての目的のために、全体を参考例として本願で引用する、2007年4月17日に出願された米国特許出願第60/912,406号の非仮特許出願であり、この米国特許出願の権利を主張するものである。
【背景技術】
【0002】
(背景)
2人の当事者の間で取引(支払いを伴う取引または支払いを伴わない取引)を行う間、各当事者は不正を回避するために、他方の当事者のアイデンティティおよび/または他方の当事者に関係するデータを一般に認証を望む。
【0003】
遠隔通信デバイスによって開始され、このデバイスにより行われる取引は、対面取引よりも、より危険となり得る。その理由は、従来の対面認証手続きを実行できないからである。例えば遠隔取引を行う際に、消費者の運転免許証の写真をチェックすることができないからである。
【発明の概要】
【発明が解決しようとする課題】
【0004】
上記に鑑み、遠隔取引中に消費者のような個人のアイデンティティおよびプロファイルデータを認証するためのシステムが望まれている。認証システムは、実現および使用が容易であり、資源に最小限しか投資するだけでよく、システム参加者の間の高レベルの相互運用可能性を提供できることが望ましい。
【0005】
取引に関係する別の問題は、一般に購入取引中に業者が支払いカード情報を受け取ることが多いことにある。業者が誠実でない場合、消費者の支払い情報は危うくなり得る。本発明の別の実施形態は、業者が消費者の支払い情報を保有することのないよう、支払い取引のような取引を開始するのにエリアス識別子を使用することに関する。
【0006】
本発明の実施形態は、上記課題およびその他の課題を別々に、かつ総合的に解決するものである。
【課題を解決するための手段】
【0007】
概要
本発明の実施形態は、個人の識別を認証し、所定のアイデンティティを有し、かつ対応する所定のプロファイルデータを有する者として自分を別の当事者に提示する個人(提示者)のプロファイルデータの有効性を判断するための方法およびシステムを含む。本発明の実施形態は、遠隔取引だけに限定されないが、本発明の実施形態は、対面で認証手続きを行うことが困難である遠隔取引で有利に使用できる。本発明の実施形態により、信頼できる当事者は、提示者のアイデンティティおよびプロファイルデータを認証することも可能となる。プロファイルデータの提供およびプロファイル更新のような別の能力も実行できる。
【0008】
本発明の一実施形態は、a)提示者の口座に対する口座識別子に関連するエリアス識別子を受信するステップと、b)前記エリアス識別子を使って、信頼できる関連当事者を決定するステップと、c)前記信頼できる関連当事者を決定した後に、前記信頼できる当事者に検証リクエストメッセージを送るステップとを備え、前記検証リクエストメッセージは、前記信頼できる当事者または前記提示者が、認証プログラムに参加しているかどうかに関する情報をリクエストし、d)更に前記信頼できる当事者または前記提示者が前記認証プログラムに参加しているかどうかを示す検証応答メッセージを受信するステップを備える方法に関する。
【0009】
本発明の別の実施形態は、a)提示者の口座に対する口座識別子に関連するエリアス識別子を受信する符号と、b)前記エリアス識別子を使って、信頼できる関連する当事者を決定する符号と、c)前記信頼できる関連する当事者を決定した後に、前記信頼できる当事者に検証リクエストメッセージを送る符号とを備え、前記検証リクエストメッセージは、前記信頼できる当事者または前記提示者が、認証プログラムに参加しているかどうかに関する情報をリクエストし、d)更に前記信頼できる当事者または前記提示者が前記認証プログラムに参加しているかどうかを示す検証応答メッセージを受信する符号を備えるコンピュータが読み取りできるメディアに関する。
【0010】
本発明の別の実施形態は、a)提示者の口座に関連する口座識別子に関連するエリアス識別子を提供するステップと、b)前記エリアス識別子を提供した後に、認証リクエストメッセージを受信するステップと、c)前記認証リクエストメッセージを受信した後に、認証応答メッセージを送るステップとを備える方法に関する。
【0011】
本発明の別の実施形態は、a)提示者の口座に関連する口座識別子に関連するエリアス識別子を提供する符号と、b)前記エリアス識別子を提供した後に、認証リクエストメッセージを受信する符号と、c)前記認証リクエストメッセージを受信した後に、認証応答メッセージを送る符号とを備えるコンピュータが読み取りできるメディアに関する。
【0012】
図面および詳細な説明を参照し、以下、本発明の上記およびそれ以外の実施形態について更に詳細に説明する。
【図面の簡単な説明】
【0013】
【図1】本発明の一実施形態に係わるシステムのブロック図を示す。
【図2】本発明の別の実施形態に係わるシステムの別のブロック図を示す。
【図3】本発明の別の実施形態に係わるシステムの別のブロック図を示す。
【図4】支払い取引前に生じ得る登録プロセスの実施形態を示すフローチャートである。
【図5】支払い取引中に生じ得る登録プロセスの実施形態を示すフローチャートである。
【図6】支払い取引を開始するためのプロセスの実施形態を示すフローチャートである。
【図7】認証プロセスの実施形態を示すフローチャートである。
【図8】支払い認証プロセスの実施形態を示すフローチャートである。
【図9(a)】電話内の部品を示すブロック図である。
【図9(b)】代表的な支払いカードに存在し得る部品を示す。
【図10】コンピュータ装置内の部品のブロック図を示す。 図中、同様な番号は同様な要素を示し、一部のケースでは、同様な要素の説明を繰り返さないことがある。
【発明を実施するための形態】
【0014】
(詳細な説明)
本発明の実施形態は、所定のアイデンティティを有する者であって、かつ所定の対応するプロファイルデータを有するものとして、自らを別の当事者(受領者)に提示する個人(提示者)のアイデンティティを認証し、かつその個人のプロファイルデータの有効性を判断するための方法およびシステムを提供するものである。消費者は提示者の一例となることがあり、受領者は、サービス提供者、政府機関、業者または取引を進める前に提示者のアイデンティティを認証する必要がある他の任意のエンティティとなり得る。アイデンティティの認証は、所定の個人であると主張する提示側当事者のアイデンティティを検証することに依存することができ、プロファイルデータの有効性の判断は、提示者によって提供されるプロファイルデータが実際にその提示者に関連していることの有効性の判断に依存することができる。他の機能、例えばプロファイルデータの供給およびプロファイルの更新も、本発明の実施形態で実行できる。これら機能は別々に実行してもよいし、または互いに組み合わせて実行してもよい。本発明の実施形態は、従来の対面認証手続きの実行が困難である遠隔取引を実行するのに使用することが好ましい。
【0015】
図示するように、本発明の一実施形態では、クレジットカードを使って購入することを業者に求めている消費者を、取引が進行する前に認証できる。クレジットカードの発行者は、取引が終了するまでに、消費者および消費者のプロファイルデータを認証することができる。(カード発行者は、銀行、クレジットユニオンまたは口座を使って消費者が取引を行うことができるように、消費者のために口座を開設できる他の機関となり得る。)消費者および消費者のデータが認証された後に、この情報は業者に送られる。次に業者は、発行者が消費者および消費者のデータを認証したことを知って、取引を進めることができる。クレジットカードの発行者が消費者および消費者のデータを認証すると、後でその取引が詐欺であると判断された場合、発行者がリスクを負う場合がある。したがって、本発明の実施形態を使用すれば、業者およびカード発行者は、行われている取引が正当であるとの、より高い確信を有し得る。
【0016】
以下、本発明の特定の実施形態の多くを詳細に説明する。一部の場合、次のような頭辞略語を使用する。
ACS:アクセス制御サーバ−アクセス制御サーバは、取引、例えば遠隔または対面購入取引中に、提示者(例えば消費者、カード所有者)を認証できる能力をカード発行者に提供できる。
DS:ディレクトリーサーバ−ディレクトリーサーバを使って、業者プラグイン(MPI)と発行者のACSとの間で入会および認証情報を含むメッセージをルーティングできる。
IVR:相互対話音声応答ユニット−相互対話音声応答ユニットは、通常の電話の通話を通してコンピュータ装置が音声およびタッチトーンを検出できるようにする電話技術を含むことができる。
SMS:ショートメッセージサービス−ショートメッセージサービスは、携帯電話との間で送られるメッセージを含むことができる。典型的なSMSメッセージによって、ユーザーはメッセージ当たり160個までの文字を送ることができる。
MPI:業者プラグイン−業者プラグインは、一部の実施形態では取得者のドメイン内で作動するコンポーネントとなり得る。オンライン環境では、この業者プラグインは、業者のために種々の認証機能を実行する。かかる機能として、カード番号に関して認証を利用できるかどうかを判断すること、および認証メッセージ内のデジタル署名の有効性の判断をすることが挙げられる。この業者プラグインでは、業者にアクセスできる適当なハードウェアおよび/またはソフトウェアによって具現化できる。
MSISDN:モバイル加入者用ISDN番号−モバイル加入者用ISDN(統合サービスデジタルネットワーク)番号は、消費者の電話番号とすることができる。
USSD:非構造化補助サービスデータ−非構造化補助サービスデータは、GSMネットワークのチャンネルを通した情報の伝送をサポートするためのGSM(モバイル通信のためのグローバル通信)に組み込まれた機能を有する。USSDは、セッションに基づく通信機能を提供し、よって種々のアプリケーションを可能にする。
WAP:無線アプリケーションプロトコル−WAPブラウザは、PC(パソコン)に基づくウェブブラウザの基本サービスのすべてを提供でき、このWAPブラウザは、携帯電話の制限内で運用できるように簡略化できる。
【0017】
上記のように、本発明の実施形態は特に遠隔取引を行うのに有効である。形態または地上回線音声通話、ショートメッセージサービス(SMS)メッセージなどを含むが、これらだけに限定されない通信を通して、遠隔取引を行うことができる。種々のデータ転送プロトコル(例えばTCP/IP)も使用できる。携帯電話、スマートフォン、インターネット接続されたコンピュータまたはターミナル、パーソナルデジタルアシスタント(PDA)などを含むが、これらに限定されないデバイスからも、遠隔取引を開始できる。
【0018】
本発明の実施形態は、携帯電話の使用および遠隔取引だけに限定されるものではなく、本発明の実施形態は、種々の通信デバイス、支払いチャンネルおよび認証チャンネルの使用も含むことができる。次に、通信デバイス、支払いチャンネルおよび認証チャンネルの数例について記載する。
【表1】
【0019】
次に、図を参照し、本発明の特定の実施形態について説明できる。一実施形態では、エリアス識別子を受け取る。このエリアス識別子は、提示者(例えば消費者)の口座に対する(口座番号のような)口座識別子に関連したものである。エリアス識別子は、電話番号でよく、口座識別子はクレジットカードの口座番号のような口座番号でもよい。エリアス識別子が受信された後に、このエリアス識別子を使って信頼できる関連当事者を決定する。この信頼できる当事者を、クレジットカードの口座番号を提示者に発行した発行者とすることができる。
【0020】
次に、信頼できる関連当事者を決定した後に、この信頼できる当事者へ検証リクエストメッセージを送ることができる。検証リクエストメッセージは、信頼できる当事者または提示者が認証プログラムに参加している旨の検証をリクエストする。例えばこのメッセージは、提示者および信頼できる当事者の一方または双方が認証プログラムに参加している旨の検証をリクエストできる。検証リクエストメッセージが送られた後に、検証応答メッセージが受信される。この検証応答メッセージは、信頼できる当事者または提示者は認証プログラムに参加しているかどうかを示す。
【0021】
検証応答メッセージを受信した後に、消費者によって操作されている通信デバイス(例えば電話)に認証リクエストメッセージを送ることができる。次に消費者は、この消費者を認証する認証応答メッセージの送信を開始できる。消費者が認証された後に、消費者は行おうとしている取引を続けることができる。取引は購入取引、送金などとすることができる。
【0022】
図1は、本発明の一実施形態に係わるシステムを示す。図1のシステムは、インターネットを通すか、または電話(例えば携帯電話)を使って行われるような遠隔取引を行うのに使用できる。
【0023】
このシステムのコンポーネントは、提示者ドメイン、相互運用可能性ドメインおよび信頼できる当事者ドメイン内に設けられていることを特徴とし得る。本発明の別の実施形態では、このシステムにおけるコンポーネントは他のタイプのドメイン、すなわち異なるドメイン内にも存在し得る。本発明の一実施形態に係わるシステムは、単一ドメインまたはドメインの適当な任意の組み合わせ内にある任意の数のコンポーネントまたはこれらコンポーネントの組み合わせを含むことができる。図1における実施形態では、認証システムは、相互運用可能性ドメイン(interoperability domain)および発行者/信頼できる当事者ドメイン内に示されたコンポーネントを含むことができる。
【0024】
図1は、業者22と通信している提示者21を示す。業者22は、ウェブページインターフェース23を提供でき、このウェブページインターフェース23は、発行者のルックアップシステム24に結合できる。発行者のルックアップシステム24は、業者プラグイン(MPI)28、ディレクトリサーバ27、アクセス制御サーバ25、提示者のファイルデータベース26だけでなく、チャレンジインターフェース29にも作動的に結合できる。
【0025】
図1では、提示者ドメインは、提示者21と業者22とを含む。提示者21は、ユーザー、個人または消費者とすることができ、これらユーザー、個人または消費者のアイデンティティは認証中であり、および/またはこれらユーザー、個人、消費者のデータは有効性の判断中または提供中である。業者22は受領者の一例であり、提示者21は取引しようと試みている相手の当事者となり得る。提示者21は、インターネット22を通して、または通信デバイス、例えば携帯電話またはコンピュータ装置を直接使用することによって、認証システムにアクセスできる。
【0026】
データ認証システムは、認証プログラムを作動させることができ、信頼できる当事者または信頼できる当事者によって作動されるコンポーネントを含むことができる。信頼できる当事者は、提示者のアイデンティティを認証し、提示者21に関連するデータの有効性の判断、データの提供または更新するエンティティとすることができる。一部の実施形態では、信頼できる当事者は、銀行、クレジットまたはデビットカード発行銀行、またはクレジットまたはデビットカードサービス機構(例えばVisa)とすることができる。図示して説明するように、銀行はこの提示者が使用するクレジットカードの発行銀行とすることができる。提示者21は、この銀行の顧客とすることができる。信頼できる当事者は、提示者21との間で確立された関係を有することができるので、提示者21を認証するのに使用できる提示者のプロファイルデータを有することができる。この提示者のプロファイルデータとして、提示者のソーシャルセキュリティ番号、誕生日、口座番号、配達先住所、好みなどを挙げることができる。
【0027】
信頼できる当事者は、アクセス制御サーバ25(ACS)を所有または作動させることができ、このサーバは、特に認証プログラムへのアクセスを制御し、リクエストされたデータサービスを実行し、認証サービスに関係するデジタル署名された通知を受領者に提供するコンピュータ装置とすることができる。信頼できる多数の当事者が1つのACSを共用してもよいし、またはACSに一人の信頼できる当事者を関連させてもよい。これとは異なり、各々が提示者のサブセットに関連するような多数のアクセス制御サーバを信頼できる一人の当事者が有してもよい。
【0028】
本明細書で使用するような「サーバ」なる用語は、一般に強力なコンピュータまたはコンピュータのクラスター(群)のことである。例えばサーバは巨大なメインフレームでもよいし、ミニコンピュータクラスターでもよいし、またはユニットとして機能するサーバのグループでもよい。一例では、サーバはウェブサーバに結合されたデータベースとすることができる。更にサーバは、1つ以上のクライアントコンピュータまたはポータブル電子デバイスのリクエストにサービスする単一のコンピュータとして作動できる。
【0029】
提示者のファイルデータベース26は、信頼できる当事者が管理するか、または信頼できる当事者に関連するデータベースとすることができる。このデータベースは認証プログラム内への加入に成功した提示者に関する情報を記憶できる。かかる情報として、プログラムアイデンティティ番号および口座番号のような識別子、プロファイルデータおよびパスワードを挙げることができる。
【0030】
相互運用可能性ドメインは、ディレクトリサーバ27も含む。この相互運用可能性ドメインは、一部の実施形態では信頼できる当事者および受領者の双方が使用するコンポーネントを含むことができる。ディレクトリサーバ27は、提示者がデータ認証サービスを利用できるかどうかを判断できる。一部のケースでは、Visaのようなサービス機構によってディレクトリサーバ27を作動させることができる。
【0031】
データ認証サービスシステム内の提示者と、信頼できる当事者と、受領者との間のそれぞれの関係によって広いレンジのサービスを提供することが可能となっている。かかるサービスの例として、アイデンティティ認証、プロファイルの有効化、プロファイルデータ提供およびプロファイルデータ更新を挙げることができる。プロファイルの有効性判断の一実現例は、提示者のアドレスの有効性を判断するように作動し、プロファイルデータ更新の一実現例は、提示者の口座情報を更新するように作動する。
【0032】
提示者21と業者22との間の支払いを伴わない関連する取引および支払いを伴う関連する取引において、認証システムを使用できる。支払いに関連する取引において、別の作動、例えば金融口座からのデビットおよびクレジットの認証を行うこともできる。発行者の認証および決済システムのような別のシステムも使用できる。
【0033】
次に、提示者の加入プロセスについて説明する。一実施形態では、提示者21は認証プログラムに参加するために、信頼できる当事者と共に登録される。登録に成功すると、信頼できる当事者は提示者にプログラムアイデンティティ番号(または他のエリアス識別子)および認証パスワード、トークンまたは他の認証要素を提供またはこれらを割り当てることができる。認証パスワード、トークンまたは他の認証要素によって、信頼できる当事者は、提示者21のアイデンティティを認証することが可能となる。その理由は、信頼できる当事者および提示者21しかパスワード、トークンまたは他の認証要素を知らないからである。ある方法でエリアス識別子および/または認証要素を通信デバイス(例えば電話)に関連させることができる。例えばエリアス識別子を電話番号とし、認証要素を電話用のSIMカード番号とすることができる。
【0034】
プログラムアイデンティティ番号とは、認証プログラムを使用するのに、適正に入会している提示者を識別する番号のことである。プログラムアイデンティティ番号またはエリアス識別子は、一般に口座識別子、例えば提示者21に関連する口座番号にリンクできる。
【0035】
プログラムアイデンティティ番号は任意の適当なタイプの数を含むことができる。プログラムアイデンティティ番号の一例として、乱数または一連の数字から生じた数字を挙げることができる。一実施形態では、プログラムアイデンティティ番号を電話番号とすることができる。このことは、その電話番号を有する電話を使って音声またはショートメッセージサービス(SMS)メッセージにより、認証システムと提示者21が相互対話するケースで便利である。取引を行う際に、提示者の口座番号の代わりにプログラムアイデンティティ番号を使用してもよい。
【0036】
本発明の実施形態では、アイデンティティ番号を一般に通信デバイスまたは通信サービスアドレスまたは識別子(例えば電話番号、eメールアドレス)などに対応させることができる。電話番号をアイデンティティ番号として使用する場合、システムは提示者の電話番号を自動的に決定するために自動番号識別(ANI)サービスのようなサービスを使用してもい。これとは異なり、提示者21の音声を使用するか、または提示者の電話に電話番号をマニュアルで入力することにより、提示者21に対して提示者の電話番号を提供することを求めてもよい。
【0037】
本発明の実施形態では、アイデンティティ番号は追加情報、例えば口座識別子(例えば口座番号)または受領者識別番号の少なくとも一部を含んでもよい。例えば実施中の取引がクレジットカードを必要とする場合、追加情報を、カード口座番号の最初の6桁に対応するクレジットカード発行者の銀行識別番号(BIN)とすることができる。この追加識別情報は、多数の口座または受領者が所定の提示者アイデンティティ番号に関連し得るときに有効である。
【0038】
入会プロセス中、提示者21は入会データ、認証データおよびプロファイルデータを信頼できる当事者に提供できる。信頼できる当事者が提示者21を認証し、提示者が認証プログラムに参加しているかどうかを判断するように、これらタイプのデータを使って提示者のアイデンティティを検証できる。その後の取引中に提示者を認証するのに認証データを使用できる。認証データの例として、パスワード、チップカード内のユニークなデータ、生体測定データなどを挙げることができる。種々のタイプの認証データを使用できると理解すべきである。かかるデータが信頼できる当事者のもとのファイルに存在しない場合、その後の取引中にプロファイルデータを使ってプロファイルデータの有効性の判断および/またはそのデータの提供をできる。
【0039】
提示者の入会プロセスは種々の方法で行うことができる。例えばオンライン、人と人との相互対話、電話での会話またはメールを通して、この入会プロセスを行うことができる。オンライン入会プロセスの例では、提示者は入会ウェブサイトに進み、プログラムアイデンティティ番号(または他のエリアス識別子)および認証要素を得るための適当な情報を提供できる。一部の実施形態では、入会していない提示者が取引を行おうとする最初のときに、入会を自動的に開始することもできる。
【0040】
次に、図1を参照し、データ認証プログラムに関連するデータ認証プロセスについて説明できる。このデータ認証プログラムは、受領者、例えば業者22が提示者21を認証したいような種々の状況に使用できる。例えば支払いを伴わない例では提示者21は、(受領者のウェブサイトの一例である)政府のウェブサイトに進み、スモールビジネスライセンス(small business licence)のための申請書の書き込みを行うことができる。種々の政府機関は、自らのウェブサイトを通してオンラインサービスを提供している。一般に政府機関は、提示者21が入力した情報(例えば氏名、住所など)を確認したい。本発明の実施形態は、支払いを伴う例でも同じように作動できる。例えば次の例は、顧客が業者22を呼び出し、発注し、自分のクレジットカードで注文に対する支払いを計画する場合のデータ認証プログラムの作動について述べたものである。
【0041】
提示者21は、業者22が物品またはサービスに対する発注に応じることを求めることにより、取引を開始する。別の実施形態では、提示者21はウェブブラウザまたはeメールなどを使用してインターネットを通してSMSメッセージを使って、業者22と相互対話できる。
【0042】
発注後、提示者21は、可能な場合に追加識別情報、例えばBIN(銀行識別番号)および/または追加識別子で補強されたアイデンティティ番号、例えば携帯電話の番号を業者22に提供する。提示者21の口座番号の代わりにこの情報を業者22に提供することもできる。提示者21が手動で提供するのではなく、ANI(自動番号識別)のようなシステムを使って、携帯電話の番号のようなアイデンティティ番号またはアイデンティティ番号の一部を自動的に決定することもできる。
【0043】
(提示者21は、このアイデンティティ番号を認証システムに直接には入力しないと仮定した場合)業者22はアイデンティティ番号を受けた後に、この番号をデータ認証システムに入力する。業者22は、ウェブページインターフェース23を使用するか、または他の、ある手段を通して、認証システムとインターフェースできる。例えば業者22はアイデンティティ番号をウェブページインターフェース23に入力してもよい。別の実施形態では、提示者21はウェブページインターフェース23または他のあるインターフェースを通してシステムにアイデンティティ番号を直接入力できる。
【0044】
ウェブページインターフェース23によりアイデンティティ番号が受信された後に、発行者のルックアップシステム24は、アイデンティティ番号を受信し、このアイデンティティ番号に関連する発行者を判断する。一旦、対応する判断が決定されると、発行者のルックアップシステム24は、アイデンティティ番号を発行者に電子的に送る。発行者はアイデンティティ番号を口座番号に変換するのに使用される提示者のファイルデータベース26を維持する。次に、発行者のルックアップシステム24により、口座番号およびアイデンティティ番号が業者プラグイン(MPI)28へ転送される。
【0045】
次に、業者プラグイン(MPI)28は、提示者21がデータ認証プログラムに参加しているかどうかをチェックする。一実現例では、提示者21が認証プログラムに参加しているかどうかをチェックするのに、2フェーズプロセスが使用される。この2フェーズプロセスでは、ディレクトリサーバ(DS)27およびアクセス制御サーバ(ACS)25に問い合わせが行われる。ディレクトリサーバ27はアイデンティティ番号を受信し、このアイデンティティ番号に関連する発行者がデータ認証プログラムに参加しているかどうかを判断する。発行者が提示者21のアイデンティティを認証し、提示者に関係するデータサービスを提供したい場合、提示者21はデータ認証プログラムを使用できる。アイデンティティ番号を受信した後に、アクセス制御サーバ(ACS)25は、認証プログラムにより提示者21が入会しているかどうか、およびアイデンティティ番号に関連するデバイスのタイプ(例えば携帯電話)が認証システムによりサポートされているかどうかを判断する。
【0046】
発行者がデータ認証プログラムに参加していないか、または提示者21がデータ認証プログラムに入会していない場合、業者22は取引を中断するか、または他のある態様で取引を進めるかどうかを判断できる。発行者が認証プログラムに参加しているが、提示者21が入会していない場合、データ認証プログラムに入会する機会を提示者21に与えてもよい。
【0047】
発行者および提示者21の双方がデータ認証プログラムに参加している場合、およびアイデンティティ番号に関係するデバイスをプログラムで使用できる場合、アクセス制御サーバ(ACS)25は、遠隔認証リクエストメッセージを発生し、(例えば業者プラグイン(MPI)が取得者または他の信頼できる当事者のホストとなっている場合に)このメッセージは、業者プラグイン(MPI)28へ送られる。
【0048】
業者プラグイン(MPI)28は、次にチャレンジインターフェース29を通して認証チャレンジを提示者21へ発生する。このようにするために、業者プラグインは、提示者の支払いカード番号とアイデンティティ番号とを関連付ける。アイデンティティ番号が携帯電話の番号に対応している場合、この電話番号はアイデンティティ番号から抽出され、この番号を使って認証チャレンジを提示者の電話へ送る。チャレンジインターフェースモジュール29を使って、認証チャレンジを顧客の携帯電話へ送るのに、非構造化補助サービスデータ(USSD)プロトコルを使用してもよい。当業者であれば、他のプロトコルまたは通信方法も使用できることが認識できよう。例えば認証チャレンジをSMSメッセージ、自動化された予備記録電話発呼、または相互対話チャットメッセージとすることができる。
【0049】
提示者21は、認証チャレンジを受信すると、所定の認証データに応答する。例えば認証チャレンジがSMSメッセージを介して発せられた場合、提示者21はパスワードを含む応答SMSメッセージを送ることができる。電話の呼び出しにより認証チャレンジが発せられた場合、提示者21は電話のキーパッドを使うか、自分の音声を使ってパスワードを提供できる。この方法とは異なり、他のタイプの認証データ、例えば生体測定データ、チップカードデータなども使用できる。
【0050】
業者プラグイン(MPI)28が提示者の認証データを一旦受信すると、取引データ、例えばカードの口座番号および有効期限日を含むカードデータが添付され、発行者のアクセス制御サーバ(ACS)25へ送られる。発行者のアクセス制御サーバ(ACS)25は、認証データの有効性の判断をし、その有効性の判断の結果を業者プラグイン(MPI)28へレポートする。次に、業者プラグイン(MPI)28は、ウェブページインターフェース23を介して、検証の結果を業者22へ通知する。検証に成功した場合、業者22には提示者の口座識別子(例えば口座番号)またはその一部を提供できる。次に発行者には取引の詳細が通知され、取引は完了するまで続行できる。
【0051】
取引が完了した後に、ウェブページインターフェース23を使ってアイデンティティ番号に対応する提示者のデバイス(例えば電話)および業者22にメッセージを送ることができる。例えば提示者の電話番号を使用する提示者の電話に対し、提示者21が正式に認証されたこと、および取引が成功裏に完了したことを示すメッセージを送ることができる。セキュリティのレベルを高めるために、図1に示されているすべてのメッセージを暗号化できると理解すべきである。
【0052】
提示者21と業者22とが自ら取引するように本発明の実施形態を実現することもできる。提示者21ではなく、業者22に関連するアイデンティティ番号を提供することにより、業者22はシステムと相互対話できる。業者22が提示者21のアイデンティティ番号をシステムに提供することもできる。提示者21は自分のデバイスで認証チャンネルを受信し、上記のように認証データに応答できる。別の実施形態では、提示者21は業者のアイデンティティ番号および取引に対する支払い金額を提供することにより、システムと相互対話できる。
【0053】
本発明の実施形態では、提示者21が多数の支払いカード(例えば3枚以上のクレジットカード)を有し得ることに留意されたい。一実施形態では、提示者21が無線電話のような通信デバイスを使用している場合、提示者21に選択のための主要口座番号のリストを提示できる。提示者21が電話番号による取引を行うときに、取引を行うために最終的に主要デフォルト口座番号を使用するよう、この提示者のそのときの電話番号を主要デフォルト口座番号に対応させることができる。別の実施形態では、主要口座番号のリストを提示者21に提示し、取引を行う前に取引で使用する口座番号を提示者21が選択する。この場合、電話番号に関連するデフォルト口座番号は存在しなくてもよい。更に別の実施形態では、リスト内の各主要口座番号に関連する異なるエリアス識別子が存在し得る。例えば異なる3つの主要口座番号に対して、これらエリアス識別子を単に「card1」、「card2」、「card3」としてもよい。
【0054】
図2は、本発明の別の実施形態にかかわる別のシステムのブロック図を示す。ここには、メッセージのフローも示されている。図2に示されたコンポーネントの一部は、図1のコンポーネントの一部に類似する。図2は更に、業者のコールセンター42と通信する携帯電話40だけでなく、Telco(電話会社)58のインターフェースに結合されたインターフェース要素60も示しており、Telco58のインターフェースは、次に仮想カードホルダーリダイレクトモジュール56に結合されている。図2には特に発行者12および取得者14も示されている。
【0055】
この実施形態では、提示者21はクレジットカード(または他のある支払いデバイス)を使って、業者22との購入取引を開始する。カード取引について詳細に説明するが、この取引は上記とは異なり、ストアードバリューカード(stored value card)、デビットカード、無接点電話、スマートカードなどで実施することもできる。
【0056】
提示者21は、業者のコールセンター42を呼び出すのに自分の携帯電話40を使用する(ステップ1)。提示者21は次に(例えば音声によるか、または電話番号を電話40に入力するなどして)エリアス識別子、例えばアイデンティティ番号を提供する。このアイデンティティ番号は、携帯電話40に関連する電話番号の一部またはすべてを含むことができる。追加識別子情報は、提示者21が保有するクレジットカードのクレジットカード番号に関連するBIN(銀行識別番号)などを含むことができる。別のタイプのエリアス識別子は、ニックネームでもよいし、または使用中の特定のクレジットカードに対して提示者21が割り当てた他のエリアスでもよい。次に業者22は、エリアス識別子のうちの1つ以上を業者のウェブページインターフェース23に入力できる(ステップ2)。
【0057】
業者プラグイン(MPI)28は、エリアス識別子を受信し、この識別子は検証リクエストメッセージ(VE Req(m))内でディレクトリサーバ(DS)48へ送られる(ステップ3)。ディレクトリサーバ48は、検証リクエストメッセージを受信した後に、提示者21に対する認証を利用できるかどうかを判断するように、アクセス制御サーバ25に問い合わせを行う(ステップ3)。この例では、検証リクエストメッセージ(VE Req(m))は、エリアス識別子、例えば携帯電話40の電話番号を含む。
【0058】
アクセス制御サーバ(ACS)25は、ディレクトリサーバ48にメッセージを通過させることにより、検証応答(VE Res(m))メッセージを送ることにより応答する(ステップ4)。検証応答メッセージを受信した後に、業者プラグイン(MPI)28は、ディレクトリサーバ(DS)48を通して、アクセス制御サーバ(ACS)25に支払い認証リクエストメッセージ(PA Req(m))を送る。次にアクセス制御サーバ(ACS)25は、モバイル認証リクエストメッセージを発生し(ステップ6)、このメッセージは仮想カードホルダーリダイレクトモジュール56を介して電話会社(Telco)のインターフェース58へ送られる。このようにするために、ディレクトリサーバ(DS)48は、提示者のクレジットカード番号と、その提示者の電話番号とを再関連付けし、Telcoのインターフェース58を介して提示者21にアクセスできるインターフェース要素60にコンタクトする(ステップ6および7)。インターフェース要素60は、携帯電話60上のユーザーインターフェースを含むことができるし、または携帯電話40を除くデバイス上のユーザーインターフェースを含むこともできる。
【0059】
次に認証リクエストメッセージは提示者21へ送られ、所定のパスワードまたは他の認証データで応答するよう、提示者21を促す(ステップ7)。ステップ8では、認証データに、使用中のクレジットカードに関連するカード番号が再添付され、Telcoのインターフェース58を介し、発行者のアクセス制御サーバ(ACS)25へ補助応答メッセージが送られる。ステップ9では、提示者21からのパスワードを含む認証応答メッセージを受信した後に、発行者12はパスワードの有効性を判断する。発行者12がパスワードを有効であると判断した後に、発行者12は業者プラグイン(MPI)28へ支払い認証応答(PA Res(m))メッセージを送る(ステップ9)。
【0060】
一部の実施形態では、支払い認証応答(PA Res(m))メッセージは、提示者21に関する追加情報(例えば送り先住所、コンタクト情報、例えばeメールアドレス、好みなど)を含むことができる。例えば提示者21の送り先アドレスを発行者のACS25から業者プラグイン(MPI)28へ送ってもよい。かかる実施形態では、業者22がかかる追加情報を維持する必要がないことが好ましい。したがって、提示者21により取引を開始した後に、発行者12が以前収集した任意の適当な情報を、業者22へ送ってもよい。
【0061】
ステップ10では、ウェブページインターフェース23を使って、認証プロセスの結果が業者22の被雇用者に伝えられる。ステップ11において、業者プラグイン(MPI)28から業者の取得者14へ応答メッセージ11が送られる。取得者30は、Telcoのインターフェース58を介して提示者21へ、およびウェブページインターフェース23を介して業者22へ、メッセージを送ることにより、取引を完了する。
【0062】
別の実施形態では、提示者21は業者のコールセンター42を経由することなくウェブページインターフェース23を介して業者のウェブサイトと相互対話できる。提示者21は、自分のアイデンティティ番号を「支払いページ」に入力でき、その後、インターフェース要素60上で認証チャレンジを受信する。
【0063】
図2に示されたフローは、多数の利点を有する。例えば図2において、業者22が、提示者21が使用しているクレジットカードの実際の口座番号を見なくても、または所有していなくても、提示者21を迅速かつ効率的に適正に認証できる。一部の業者または業者の被雇用者が、提示者の支払い口座番号を不正に使用する可能性があるので、このことは提示者21に対して更に高いセキュリティを提供できる。
【0064】
図3には、本発明の別の実施形態にかかわるシステムの別のブロック図が示されている。このシステムは、提示者ドメイン内にある携帯電話72を含む。業者プラグインインターフェース74は、取得者ドメイン内にあり、この取得者ドメイン内の取引開始コンポーネント84と通信する。ディレクトリサーバ76とレポートサーバ78とは、相互運用可能性ドメイン内にあり、アクセス制御サーバ80と登録サーバ82は発行者ドメイン内にある。この実施形態では、モバイル認証コンポーネント86とモバイル登録コンポーネント88は、取得者ドメイン、相互運用可能性ドメインおよび発行者ドメイン内で働くことができる。
【0065】
上記とは異なり、携帯電話72はデータを送信および/または受信できる任意の適当な通信デバイス(例えば固定電話、インターネット上のPCなど)とすることができる。上記のように、消費者(または提示者)は、携帯電話の番号、携帯電話の番号+チェック数字、または他の適当なエリアス識別子に基づき、取引を開始できる。エリアス識別子は、支払い口座番号に対する代替手段として使用できる。消費者は取引を開始し、および/または取引を認証するように自分の携帯電話または携帯電話番号/エリアスも使用できる。消費者は認証プログラム登録をするのに、自分の携帯電話も使用できる。
【0066】
提示者のリクエスト時に、取引開始コンポーネント84により業者は支払いプロセスを開始することが可能となる。この取引開始コンポーネント84は、ハードウェア、ソフトウェアの適当な任意の組み合わせの形態にすることができる。一部のケースでは、このコンポーネントは(例えばPOSターミナル内にあるか、またはこのPOSターミナルに接続された)業者によって操作されるハードウェア内に存在してもよい。取引開始コンポーネント84は、ウェブページがインターネット環境内の標準的MPIと通信するのと同じように、業者プラグイン(MPI)74と通信できる。
【0067】
従来の実施形態と同じように、取引が開始されるときに、提示者の支払いカードの番号を業者に提供しないことが望ましい。その代わりにモバイル取引インジケータと共に提示者の電話番号/エリアスまたは他の識別子に基づいて取引を開始する。
【0068】
取引開始コンポーネント84は、あるレンジの取引開始シナリオを促進できる。このシナリオは、消費者の携帯電話の番号を自動的に業者プラグイン(MPI)74に送ることを可能にするシナリオと、消費者の携帯電話の番号をマニュアルで入力できるようにするシナリオとに分割できる。上記のように、IVR、USSD、SMSまたはWAPを使って、携帯電話の番号を業者プラグイン(MPI)74に自動的に送ってもよい。この方法とは異なり、電話番号をシステム内にマニュアルで入力してもよい。例えばこの電話番号は、PCに向かっているコールセンターのエージェント、受け取りデバイスとして自分の携帯電話を使用するモバイル業者などにより、認証システムへマニュアルで入力してもよい。取引開始コンポーネント84は、提示者に取引のステータスを通知するよう、業者に対し、後方向(backwards)の通信チャンネルも提供できる。
【0069】
業者プラグイン(MPI)74は、多数の機能を実行できる。例えばこのプラグインは、カード番号を使用することなく、携帯電話の番号に基づき、取引の処理を促進できる。更にこのプラグインは、検証メッセージ内に携帯チャンネル/デバイス識別子を含ませ、よって携帯チャンネルを介して取引を認証することを発行者に促すこともできる。更にこのプラグインは、それぞれの発行者による新しい提示者のオンライン加入を可能にするように、業者側への後方向の通信も提供できる。
【0070】
ディレクトリサーバ(DS)76も多数の機能を提供する。このサーバは、携帯電話の番号および/または他のエリアス識別子をDIN(銀行識別番号)にマッピングでき、認証リクエストを適当な発行者にルーティングすることを可能にする。消費者が自分のカード、電話番号またはエリアス識別子を変更したい場合、アクセス制御サーバ(ACS)80から(逆の場合も同様)携帯電話番号および/またはエリアス識別子および/またはBIN番号を更新できる。また、ディレクトリサーバ(DS)76は、取引開始コンポーネント84および業者プラグイン(MPI)74と共同して、適当な発行者による新しい提示者のオンライン加入も容易にできる。
【0071】
レポートサーバ78はレポートを提供する。このサーバは、携帯電話の番号および/またはエリアス識別子も記録できる。
【0072】
アクセス制御サーバ(ACS)80は、多数の機能を実行できる。例えば識別された取引を受信すると、このサーバはモバイル認証コンポーネント86を介した、携帯電話72への認証リクエストメッセージの送信を開始できる。ポジティブな認証応答メッセージを受信すると、アクセス制御サーバ(ACS)80は、提示者の携帯電話の番号を提示者の登録されたPAN(主要口座番号)に変換できる。
【0073】
モバイル認証コンポーネント86は、取引を認証するために提示者とアクセス制御サーバ(ACS)80との間で双方向のモバイルチャンネルを提供する。この双方向のチャンネルは、IVR、WAPまたは提示者の携帯電話72にローディングされたクライアントアプリケーションを含むことができる。
【0074】
登録サーバ82は、登録機能を提供すると共に、携帯電話番号および/またはかかるデータのためのエリアスフィールドを含む。
【0075】
モバイル登録コンポーネント88は、提示者と登録サーバ82との間で双方向のモバイルチャンネルを提供する。このチャンネルは、提示者の認証プログラムに登録するのに使用され、提示者の登録された携帯電話72が正しいことを保証するように使用される。モバイルチャンネルの例として、IVR、WAPまたは提示者の携帯電話にロードされるクライアントアプリケーションを挙げることができる。このチャンネルは、モバイル認証コンポーネント86と同じでもよいし、またはこのコンポーネントに基づくものでもよい。
【0076】
図4は、支払い取引を開始する前に、提示者がデータ認証プログラムに登録する場合のプロセスフローを示す。この例では、提示者はモバイルチャンネルを通し、特定の口座を登録できる。
【0077】
図4を参照すると、提示者は自分の携帯電話72を使って、発行者に関連する口座を発行者の認証プログラムに登録する。これを行うために、携帯電話72は発行者のモバイル登録コンポーネント88と通信することができる。モバイル登録コンポーネント88は、着信登録リクエストを変換し、これを発行者の登録サーバ82(ステップ102)へ転送する。発行者の登録サーバ82は、携帯電話72のためのMSISDNがモバイルチャンネルを通過したかどうかをチェックする(ステップ103)。
【0078】
モバイルチャンネルを介し、携帯電話72のためのMSISDNが提供される場合、発行者の登録サーバ82は、提示者からの別の口座データをリクエストし、モバイル登録コンポーネント88に口座データリクエストを送る(ステップ104)。モバイル登録コンポーネント88は、モバイルチャンネルおよび提示者のデバイス能力に基づき、リクエストを適合させ、これを提示者の携帯電話72へ送る(ステップ105)。次に、提示者は携帯電話72を使用し、口座データをモバイル登録コンポーネント88へ伝送し戻す(ステップ106)。次に、モバイル登録コンポーネント88は、口座データを変換し、それを発行者の登録サーバ82へ転送する(ステップ107)。
【0079】
代替フローAに示されるように、モバイルチャンネルによりMSISDNが提供されない場合、発行者の登録サーバ82は、リクエストをモバイル登録コンポーネント88へ送ることにより、提示者からのMSISDNを含む別の口座データをリクエストする(ステップA−1)。次に、モバイル登録コンポーネント88は、モバイルチャンネルおよび提示者のデバイス能力に基づきリクエストを適合させ、それを提示者の携帯電話72へ送る(ステップA−2)。次に、提示者は、携帯電話72を使って口座データおよびMSISDNをモバイル登録コンポーネント88へ送り戻す(ステップA−3)。次に、モバイル登録コンポーネント88は、口座データおよびMSISDNを変換し、それを発行者の登録サーバ82へ転送する(ステップA−4)。発行者の登録サーバ82は、この情報を受信した後に、モバイル登録コンポーネント88へ登録確認リクエストを送る(ステップA−5)。モバイル登録コンポーネント88は、メッセージングモバイルチャンネル(例えばSMS、USSD)に基づき、リクエストを適合させ、それを提示者の携帯電話72へ送る(ステップA−6)。提示者は確認リクエストを受信し、そのリクエストを受け入れ、モバイル登録コンポーネント88へ転送し戻す(ステップA−7)。モバイル登録コンポーネント88が確認応答を変換し、それを発行者の登録サーバ82へ転送する(ステップA−8)。次に発行者の登録サーバ82は、ペンディング中の提示者の登録ステータスを更新する(ステップA−9)。
【0080】
ある点において、登録サーバ82は、提示者の登録ステータスの有効性をチェックする(ステップ108)。
【0081】
提示者の登録が受け入れ可能である場合、発行者の登録サーバ82は、パスワード作成リクエストをモバイル登録コンポーネント88へ送ることができる(ステップ109)。モバイル登録コンポーネント88は、モバイルチャンネルおよび提示者のデバイス能力に基づき、リクエストを適合させ、それを提示者の携帯電話72へ送る(ステップ110)。提示者は携帯電話72を使って、パスワードを提供し、このパスワードをモバイル登録コンポーネント88へ伝送し戻す(ステップ111)。モバイル登録コンポーネント88は、パスワードを変換し、それを発行者の登録サーバ82へ転送する(ステップ112)。次に、発行者の登録サーバ82は、登録通知をモバイル登録コンポーネント88へ送る(ステップ113)。モバイル登録コンポーネント88は、モバイルチャンネルおよび提示者のデバイス能力に基づき、その通知を適合させ、それを提示者の携帯電話72へ送る(ステップ114)。次に発行者の登録サーバ82は、提示者の口座番号の一部により、アクセス制御サーバ80を更新する(ステップ115)。
【0082】
代替フローBでは、提示者の登録に失敗している。発行者の登録サーバ82は、モバイル登録コンポーネント88に登録通知エラーを送る(ステップB−1)。モバイル登録コンポーネント88は、モバイルチャンネルおよび提示者のデバイス能力に基づき、エラーメッセージを適合させ、そのエラーメッセージを提示者の携帯電話72へ送る(ステップB−2)。
【0083】
代替フローCは、発行者が発生したパスワードに関するものである。このプロセスフローでは、発行者の登録サーバ82は、(例えば提示者による入力がなくても)ユニークなパスワードを発生する(ステップC−1)。発行者の登録サーバ82は、発生したパスワードをモバイル登録コンポーネント88へ送る(ステップC−2)。モバイル登録コンポーネント88は、モバイルチャンネルおよび提示者のデバイス能力に基づき、メッセージを適合させ、メッセージを提示者の携帯電話72へ送る(ステップC−3)。
【0084】
図5は、モバイルチャンネルを通した支払い取引中の登録のためのフローチャートを示す。図5を参照すると、提示者は取引開始コンポーネント84を介して、支払い取引を開始する(ステップ201)。取引開始コンポーネント84は、取引の詳細を変換し、それを業者プラグイン(MPI)74へ転送する(ステップ202)。次に、図6に示されており、以下、更に詳細する開始する支払い取引プロセスを実行する。業者プラグイン(MPI)74は、リターンされた提示者の加入ステータスをチェックする。提示者が登録されている場合、図7に示されており、以下更に説明する支払い認証プロセスを実行しながら、ステップ218でフローが続く。
【0085】
提示者が登録されなかった場合、業者プラグイン(MPI)74は、取引開始コンポーネント84へBIN(銀行識別番号)情報のためのリクエストを送る(ステップ204)。取引開始コンポーネント84は、モバイルチャンネルおよび提示者のデバイス能力に基づき、リクエストを適合させ、このリクエストを提示者の携帯電話72へ送る(ステップ205)。提示者は携帯電話72を使って、リクエストされたBIN情報を提供し、この情報を取引開始コンポーネント82へ伝送し戻す(ステップ206)。取引開始コンポーネント84はリクエストされた口座データを変換し、このデータを業者プラグイン(MPI)74へ転送する(ステップ207)。次に業者プロセス(MPI)74は、ディレクトリサーバ76へ収集した口座データを送ることにより、発行者の参加ステータスをリクエストする(ステップ208)。ディレクトリサーバ76は、この情報を受信した後に、発行者の登録ステータスをチェックする(ステップ209)。次にディレクトリサーバ76は、発行者の登録ステータスを業者プラグイン(MPI)74へ送り戻す(ステップ(210)。業者プラグイン(MPI)74は発行者の登録ステータスをチェックする(ステップ211)。
【0086】
発行者が認証プログラムに参加した場合、業者プラグイン(MPI)74は提示者の登録リクエストをディレクトリサーバ76へルーティングする(ステップ212)。次に提示者を正式に登録するよう、発行者に対してBINおよび電話番号が送られる。次にディレクトリサーバ76は、提示者の登録リクエストをアクセス制御サーバ(ACS)80へルーティングする(ステップ213)。アクセス制御サーバ(ACS)80は提示者の登録リクエストを発行者の登録サーバ82へルーティングする(ステップ214)。次に発行者の登録サーバ82は、提示者の登録リクエストをモバイル登録コンポーネント88へ送る(ステップ215)。モバイル登録コンポーネント88は、モバイルチャンネルおよび提示者のデバイス能力に基づき、リクエストを適合させ、このリクエストを提示者の携帯電話72へ送る(ステップ216)。次に図4に示された提示者登録プロセスを実行できる(ステップ217)。提示者の登録に成功すると、以下、より詳細に説明する図7のプロセスに従って、支払い取引が認証される。
【0087】
発行者が認証プログラムに参加していないケースでは、業者プラグイン(MPI)74は、「発行者無登録」タイプのエラーメッセージを取引開始コンポーネント84へ送る。この取引開始コンポーネント84は、モバイルチャンネルおよび提示者のデバイス能力に基づき、リクエストを適合させ、このリクエストを提示者の携帯電話72へ送る(ステップ2A−1)。この場合、認証は行われず、支払い取引を放棄できる。
【0088】
図6は、提示者が支払い取引を開始するプロセスのためのフローチャートを示す。このプロセスは、提示者がモバイルチャンネルを通して業者/取得者と支払い取引を開始すると決定したときにスタートする。このプロセスは、モバイルチャンネルを通し、支払い取引の開始に成功したときに(まだ認証されていない)、終了できる。
【0089】
図6を参照すると、提示者は取引開始コンポーネント84を通して自分の携帯電話72を使って支払い取引を開始する(ステップ301)。取引開始コンポーネント84は、支払い開始リクエストを変換し、このリクエストを業者プラグイン(MPI)に転送する(ステップ302)。業者プラグイン(MPI)は、MSISDN(携帯電話番号)がモバイルチャンネルを通過したことを検証する(ステップ303)。次に、業者プラグイン(MPI)64は、検証加入リクエスト(VE req)メッセージをディレクトリサーバ76へ送る(ステップ304)。ディレクトリサーバ76は、このメッセージを受信した後に、提示者の加入ステータスに関してアクセス制御サーバ(ACS)76に問い合わせをする。アクセス制御サーバ(ACS)76は、提示者の加入ステータスをディレクトリサーバ(DS)76へ戻す(ステップ306)。ディレクトリサーバ76は、検証加入応答(VE res)メッセージを業者プラグイン(MPI)74へ戻す(ステップ307)。加入応答ステータスを受信した後に、提示者は図5で説明されている登録プロセス(支払い取引中の登録)をスタートできる。
【0090】
モバイルチャンネルによってMSISDNが提供されない場合、業者プラグイン(MPI)74は、取引開始コンポーネント84を通して提示者のMSISDNをリクエストする(ステップ3A−1)。取引開始コンポーネント84は、モバイルチャンネルおよび提示者のデバイス能力に基づき、リクエストを適合させ、このリクエストを提示者の携帯電話72に送る(ステップ3A−2)。次に提示者は、MSISDNを取引開始コンポーネント84に送り戻す(ステップ3A−3)。取引開始コンポーネント84は、MSISDNを変換し、それを業者プラグイン(MPI)74に転送する(ステップ3A−4)。
【0091】
図7は、提示者が認証しなければならない、支払い取引を開始した場合のプロセスを示す。このプロセスは、提示者が支払い取引を開始し、取引を終了するための認証の用意ができたときにスタートする。認証が終わると許可を行うことができる。
【0092】
図7を参照すると、業者プラグイン(MPI)74は、支払い者認証リクエスト(PA req)メッセージをアクセス制御サーバ80へ送る(ステップ401)。次にアクセス制御サーバ80は、認証リクエスト(MSISDNに関連する2つ以上の口座識別子が存在し得る)をモバイル認証コンポーネント86へ送る(ステップ402)。このメッセージを受信後、モバイル認証コンポーネント86は、モバイルチャンネルおよび提示者のデバイス能力に基づき、リクエストを適合させ、それを提示者の携帯電話72へ送る(ステップ403)。
【0093】
提示者は携帯電話72を使ってリクエストされた認証データ(例えばパスワード)を提供し、この認証データを含む応答をモバイル認証コンポーネント86へ送り戻す(ステップ404)。モバイル認証チャンネルは、応答を変換し、有効性の判断のためにその応答をアクセス制御サーバ(ACS)80へ送る(ステップ405)。次にアクセス制御サーバ(ACS)80は認証応答を受信し、受信した認証データをチェックする(ステップ406)。次にアクセス制御サーバ(ACS)80は、支払い者認証応答(PA Res)メッセージを業者プラグイン(MPI)74へ送り戻す(ステップ407)。次に業者プラグイン(MPI)74は、認証応答メッセージをチェックする(ステップ408)。
【0094】
消費者が認証された場合、即時許可が適当であるかどうかの判断が行われる。この即時許可が適当である場合、プロセスは、図8に示され、以下により詳細に説明する許可プロセスに進むことができる(ステップ4B−1)。即時許可が適当でない場合、業者プラグイン(MPI)74は、支払い未決通知メッセージをモバイル認証コンポーネント86へ送る(ステップ409)。モバイル認証コンポーネント86は、モバイルチャンネルおよび提示者のデバイス能力に基づき、通知を適合させ、それを提示者の携帯電話410へ送る。次に図8に示されており(かつ、以下により詳細に説明するような)認証された支払い取引プロセスを実行する(ステップ411)。
【0095】
提示者が認証されないときには、図7の代替フローAが生じ得る。アクセス制御サーバ(ACS)80は、発行者の認証規則に応じ、モバイル認証コンポーネント86を通して、提示者に認証リクエストを再発行してもよいし、または認証の試行回数に達した旨を提示者に通知してもよい。認証試行回数に達した場合、業者プラグイン(MPI)は、「認証試行回数限度到達」タイプの通知をモバイル認証コンポーネント86へ送る(ステップ4C−1)。モバイル認証コンポーネント86は、モバイルチャンネルおよび提示者のデバイス能力に基づき、通知を適合させ、それを提示者の携帯電話72へ送る(ステップ4C−2)。認証試行回数に達していない場合、プロセスはステップ402へ戻ることができ、認証試行回数に達するまでプロセスを続けることができる。
【0096】
図8は、認証された支払い取引を許可しなければならないプロセスを説明できる。この許可は、即座に行ってもよいし延期してもよい。提示者が支払い取引を認証したときに、このプロセスはスタートし、支払い認証に成功したときに、このプロセスは終了する。
【0097】
図8を参照すると、業者プラグイン(MPI)は、支払い許可プロセスを許可システム70へ送る(ステップ501)。許可システム70は、支払い許可を処理する(ステップ502)。許可システム70は、次に支払い許可応答をアクセス制御サーバ(ACS)80へ伝送する(ステップ503)。アクセス制御サーバ(ACS)80は、支払い許可応答を業者プラグイン(MPI)74へ伝送する(ステップ504)。次に、業者プラグイン(MPI)74は、支払い許可応答をチェックする(ステップ505)。
【0098】
支払い取引が許可された場合、業者プラグイン(MPI)74は、支払い受け入れ通知メッセージをモバイル許可コンポーネント86へ送る(ステップ506)。モバイル許可コンポーネント86は、モバイルチャンネルおよび提示者のデバイス能力に基づき、その通知を適合させ、それを提示者の携帯電話72へ送る(ステップ507)。
【0099】
支払い取引が拒否され、許可されない場合、業者プラグイン(MPI)74は、支払い拒否通知メッセージをモバイル許可コンポーネントへ送る(ステップ5A−1および5A−2)。モバイル許可コンポーネントがモバイルチャンネルおよび提示者のデバイス能力に基づき、通知を適合させ、それを提示者の携帯電話72へ送る。
【0100】
III.消費者用ポータブルデバイスおよびコンピュータ装置
【0101】
図9〜10は、本発明の実施形態に係わるシステム内で使用されるコンピュータ装置内に存在し得るポータブルコンピュータデバイスおよびサブシステムのブロック図を示す。上記一部の実施形態では、提示者は、支払いカード(例えばクレジットカード)および認証チャレンジを受けるための電話またはその他の通信デバイスを有することができる。別の実施形態では、提示者は、支払い取引を行うために電話を使用することができ、支払いデータを提供し、かつ認証チャレンジのためのインターフェースとして作動するために、電話を使用することができる。カードおよび電話は消費者用ポータブルデバイスの例であり、本発明の実施形態は、これら特定の消費者用ポータブルデバイスだけに限定されるわけではない。
【0102】
消費者用ポータブルデバイスの例は、任意の適当な形態となり得る。例えば適当な消費者用ポータブルデバイス消費者の財布および/またはポケットに入ることができるよう(例えばポケットサイズとなるよう)、ハンドヘルドかつコンパクトにし得る。これらデバイスとして、スマートカード、(磁気ストライプを有するが、マイクロプロセッサを有しない)通常のクレジットまたはデビットカード、キーチェーンデバイス(例えばエクソン−モービル社から市販されているスピードパス(SpeedpassTM)などを挙げることができる。消費者用ポータブルデバイスの他の例として、携帯電話、パーソナルデジタルアシスタント(PDA)、ページャー、支払いカード、セキュリティカード、アクセスカード、スマートメディア、トランスポンダおよび同等物がある。消費者用ポータブルデバイスは、デビットデバイス(例えばデビットカード)、クレジットデバイス(例えばクレジットカード)またはストアードバリューデバイス(例えばストアードバリューカード)でもよい。
【0103】
電話32’の形態をした消費者用ポータブルデバイスの一例は、図9(a)に示されるような本体およびコンピュータが読み取りできるメディアを含むことができる(図9(a)は、多数のコンポーネントを示し、本発明の実施形態に係わる消費者用ポータブルデバイスは、かかるコンポーネントのサブセットの適当な任意の組み合わせを含むことができる)。コンピュータが読み取りできるメディア32(b)は、本体32(h)内に存在していてもよいし、または本体から取り外し可能でもよい。本体32(h)は、プラスチック基板、ハウジングまたは他の構造体の形態とし得る。コンピュータが読み取りできるメディア32(b)は、データを記憶するメモリでよく、磁気ストライプ、メモリチップ、ユニークに派生されたキー、暗号化アルゴリズムなどを含む任意の適当な形態とし得る。このメモリは、情報、例えば金融情報、(例えば地下鉄または列車のパス内に記憶されるような)乗り換え情報、(アクセスバッジ内に記憶されるような)アクセス情報なども記憶することが好ましい。金融情報として、銀行口座情報、銀行識別番号(BIN)、クレジットまたはデビットカード番号情報、口座バランス情報、有効期限日、氏名、誕生日のような消費者の情報などを挙げることができる。この情報のいずれも、電話32’によって送信できる。
【0104】
メモリ内の情報は、従来通り、クレジットカードに関連するデータトラックのフォームでもよい。かかるトラックは、トラック1とトラック2とを含む。トラック1(「国際航空運輸協会」)はトラック2よりも多くの情報を記憶しており、カード所有者の氏名だけでなく、口座番号およびその他の自由裁量のデータも含む。このトラックは、クレジットカードによる予約を安全にする際に、航空会社によってときどき使用されている。トラック2(「米国銀行協会」)は、現在最も一般的に使用されているものである。このトラックは、ATMおよびクレジットカードチェッカーによって読み取られるトラックである。ABA(米国銀行協会)は、このトラックの仕様を設計し、すべての世界の銀行は、この仕様を守らなければならない。このトラックは、カード所有者の口座、暗号化されたPIN、プラスその他の自己裁量データを含む。
【0105】
コンピュータが読み取りできるメディア32(b)またはメモリは、任意の適当な順序で、上記ステップのうちのいずれかを実行するための符号を含むことができる。例えばコンピュータで読み取りできるメディア32(b)は、a)提示者の口座に関連する口座識別子に関連するエリアス識別子を提供するための符号、b)エリアス識別子を提供した後に認証リクエストメッセージを受信するための符号、およびc)認証リクエストメッセージを受信した後に認証応答メッセージを送るための符号を含むことができる。
【0106】
電話32’は更に無接点要素32(g)も含むことができ、この無接点要素はアンテナのような関連する無線転送(例えばデータ送信)要素を有する半導体チップ(または他のデータ記憶要素)を含むことができる。無接点要素32(g)は、電話32’に関連しており(例えば電話内に埋め込まれており)、セルラーネットワークを介して送信されるデータまたは制御命令は、無接点要素インターフェース(図示されず)により、無接点要素32(g)へ印加できる。無接点要素インターフェースは、モバイルデバイス回路(および従ってセルラーネットワーク)と光学的無接点要素32(g)との間でのデータおよび/または制御命令の交換を可能にするように機能する。
【0107】
無接点要素32(g)は、一般に規格化されたプロトコルまたはデータ転送機構(例えばISO14443/NFC)に従って、近接電磁界通信(NFC)能力(または近接電磁界通信メディア)を使って、データを転送および受信できる。この近接電磁界通信能力は、短距離通信能力、例えばRFID、ブルートゥースTM、赤外線、または電話32’と問い合わせデバイスとの間でデータを交換するのに使用できる他のデータ転送能力のことである。従って、電話32’は、セルラーネットワークおよび近接電磁界通信能力の双方により、データおよび/または制御命令を伝送し、かつ転送できる。
【0108】
電話32’は、電話32’の機能を処理するためのプロセッサ32(c)(例えばマイクロプロセッサ)と、消費者が電話番号およびその他の情報およびメッセージを見ることができるようにするディスプレイ32(d)も含むことができる。この電話32’は、更に消費者(または提示者)がデバイスに情報を入力できるようにするための入力要素32(e)と、消費者が音声通信、音楽などを聞くことができるようにするスピーカー32(f)と、消費者が電話32’を通して自分の音声を送信できるようにするためのマイク32(i)とを含むことができる。電話32’は、無線電話転送(例えばデータ送信)のためのアンテナ32(a)も含むことができる。
【0109】
上記のように、一部の実施形態では提示者または消費者は、デビット、クレジットまたはスマートカードの形態をした消費者用ポータブルデバイスを使用できる。カードの形態をした消費者用ポータブルデバイスは、オプションとして磁気ストライプのような特徴部も有することができる。かかるデバイスは、接触モードまたは無接点モードのいずれかで作動できる。
【0110】
図9(a)にはカード32”の形態をした消費者用ポータブルデバイスの一例が示されている。図9(a)は、プラスチックの基板32(m)を示す。このプラスチック基板32(m)の上には、ポイントオブセールスターミナルのようなアクセスデバイスとのインターフェースをするための無接点要素32(o)が存在していてもよいし、またはこの要素はプラスチック基板内に埋め込まれていてもよい。このカードには、消費者情報32(p)、例えば口座番号、有効期限日および消費者の氏名をプリントしてもよいし、またはエンボス加工してもよい。プリント基板32(m)には、磁気ストライプ32(n)も存在してもよい。
【0111】
図9(b)に示されるように、カード32”は磁気ストライプ32(n)および無接点要素32(o)の双方を含むことができる。別の実施形態では、カード32”内に磁気ストライプ32(n)と無接点要素32(o)の双方が存在してもよい。別の実施形態では、カード32”内に磁気ストライプ32(n)または無接点要素32(o)のいずれかが存在してもよい。
【0112】
これまで説明した図(例えば図1〜3)における種々の参加者および要素は、本明細書に説明した機能を容易にするよう、1つ以上のコンピュータ装置を使って作動できる。これら図内の要素のいずれも、本明細書に記載した機能を容易にするよう、適当な任意の数のサブシステムも使用できる。図10に示されたサブシステムは、システムバス775を介して相互に接続されており、追加サブシステム、例えばプリンタ774、キーボード778、固定ディスク779(またはコンピュータが読み取りできるメディアを含む他のメモリ)、ディスプレイアダプタ782に結合されたモニタ776、およびその他の装置が示されている。I/Oコントローラ771に結合している周辺機器および入力/出力(I/O)デバイスは、任意の数の公知の手段、例えばシリアルポート777により、コンピュータシステムに接続できる。コンピュータ装置をワイドエリアネットワーク、例えばインターネット、マウス入力デバイスまたはスキャナーに接続するのに、例えばシリアルポート777または外部インターフェース781を使用できる。システムバスを介した相互接続により、中央プロセッサ773は、各サブシステムと通信し、システムメモリ772または固定ディスク779からの命令の実行だけでなく、サブシステムの間の情報交換の制御も可能にしている。システムメモリ772および/または固定ディスク779は、コンピュータが読み取りできるメディアを具現化できる。これら要素のいずれも、前に説明した特徴部品内に存在していてもよい。例えば前に説明したディレクトリサーバおよびアクセス制御サーバは、図10に示されたこれらコンポーネントのうちの1つ以上を有することができる。
【0113】
本発明の一実施形態に係わるコンピュータで読み取りできるメディアは、上記機能のいずれかを実行するための符号を含むことができる。例えば上記ディレクトリサーバは、a)提示者の口座に関連する口座識別子に関連するエリアス識別子を提供する符号と、b)前記エリアス識別子を提供した後に、認証リクエストメッセージを受信する符号と、c)前記認証リクエストメッセージを受信した後に、認証応答メッセージを送る符号とを備えることができる。このディレクトリサーバは、コンピュータが読み取りできるメディアに結合されたプロセッサも有することができ、このプロセッサは、コンピュータが読み取りできるメディア上のコンピュータフローによって具現化される命令を実行する。
【0114】
本明細書で使用した用語および表現は、本発明を説明する用語として用いたものであり、本発明を限定するために用いたものではない。特許請求の範囲内において種々の変形が可能であることが認識できるので、かかる用語および表現の使用にあたり、図面に示し、説明した特徴部、およびその一部の均等物を排除する意図はない。更に本発明の範囲から逸脱することなく、本発明の任意の実施形態の1つ以上の特徴部を、本発明の他の実施形態の他の1つ以上の特徴部と組み合わせることができる。
【0115】
また、上記本発明は、コンピュータソフトウェアをモジュラー態様または統合態様で使用する制御ロジックの形態で実現できるとも理解すべきである。当業者であれば、本明細書に記載した開示および教示内容に基づき、ハードウェアを使用し、更にハードウェアとソフトウェアの組み合わせを使って本発明を実施するための他の手段および/または方法も想到できよう。
【0116】
「1つの」、「ある」または「この」なる記載は、特に反対のことを示さない限り、「1つ以上」のものも意味する。
【0117】
上記すべての特許、特許出願、刊行物および説明は、すべての目的のためにこれらの全内容を本明細書で参考例として援用する。これらのいずれも、従来技術として認めるものではない。
【特許請求の範囲】
【請求項1】
a)提示者の口座に対する口座識別子に関連するエリアス識別子を受信するステップと、
b)前記エリアス識別子を使って、信頼できる関連当事者を決定するステップと、
c)前記信頼できる関連当事者を決定した後に、前記信頼できる当事者に検証リクエストメッセージを送るステップとを備え、前記検証リクエストメッセージは、前記信頼できる当事者または前記提示者が、認証プログラムに参加しているかどうかに関する情報をリクエストし、そして
d)前記信頼できる当事者または前記提示者が前記認証プログラムに参加しているかどうかを示す検証応答メッセージを受信するステップを備える方法。
【請求項2】
前記エリアス識別子は、電話番号である、請求項1に記載の方法。
【請求項3】
前記信頼できる当事者は、前記口座を維持する金融機関である、請求項1に記載の方法。
【請求項4】
前記提示者に、認証リクエストメッセージの送信を開始するステップを更に含む、請求項1に記載の方法。
【請求項5】
前記提示者に、認証リクエストメッセージの送信を開始するステップを更に含み、その後、アクセス制御サーバが前記認証リクエストメッセージを提示者に送る、請求項1に記載の方法。
【請求項6】
前記エリアス識別子を受信する前に、前記提示者は、携帯電話を使って前記エリアス識別子を送る、請求項1に記載の方法。
【請求項7】
ディレクトリサーバにより、前記ステップa)〜d)を実行する、請求項1に記載の方法。
【請求項8】
前記信頼できる当事者は、前記口座識別子を発行した発行者である、請求項7に記載の方法。
【請求項9】
a)提示者の口座に対する口座識別子に関連するエリアス識別子を受信するための符号と、
b)前記エリアス識別子を使って、信頼できる関連する当事者を決定するための符号と、
c)前記信頼できる関連する当事者を決定した後に、前記信頼できる当事者に検証リクエストメッセージを送るための符号とを備え、前記検証リクエストメッセージは、前記信頼できる当事者または前記提示者が、認証プログラムに参加しているかどうかに関する情報をリクエストし、
d)更に前記信頼できる当事者または前記提示者が前記認証プログラムに参加しているかどうかを示す検証応答メッセージを受信するための符号を備えるコンピュータが読み取りできるメディア。
【請求項10】
プロセッサと、
前記プロセッサに結合された請求項9に記載のコンピュータが読み取りできるメディアシステムとを備えるディレクトリサーバ。
【請求項11】
a)提示者の口座に関連する口座識別子に関連するエリアス識別子を提供するステップと、
b)前記エリアス識別子を提供した後に、認証リクエストメッセージを受信するステップと、
c)前記認証リクエストメッセージを受信した後に、認証応答メッセージを送るステップとを備える方法。
【請求項12】
前記エリアス識別子は、電話番号である、請求項11に記載の方法。
【請求項13】
前記提示者の音声を使って、前記エリアス識別子が提供される、請求項11に記載の方法。
【請求項14】
前記提示者が操作する電話で、前記認証リクエストメッセージが受信される、請求項13に記載の方法。
【請求項15】
前記認証応答メッセージは、パスワードまたはPIN番号を含む、請求項14に記載の方法。
【請求項16】
対面取引において前記エリアス識別子が業者に提供される、請求項11に記載の方法。
【請求項17】
業者に対して遠隔地に位置する通信デバイスを使って前記エリアス識別子が、前記業者に提供される、請求項11に記載の方法。
【請求項18】
a)提示者の口座に関連する口座識別子に関連するエリアス識別子を提供するための符号と、
b)前記エリアス識別子を提供した後に、認証リクエストメッセージを受信するための符号と、
c)前記認証リクエストメッセージを受信した後に、認証応答メッセージを送るための符号とを備えるコンピュータが読み取りできるメディア。
【請求項19】
プロセッサと、
前記プロセッサに結合されたアンテナと、
前記プロセッサに結合されたマイクと、
前記プロセッサに結合された請求項18に記載のコンピュータが読み取りできるメディアとを備える電話。
【請求項20】
前記プロセッサに結合された無接点要素を更に備える、請求項19に記載の電話。
【請求項1】
a)提示者の口座に対する口座識別子に関連するエリアス識別子を受信するステップと、
b)前記エリアス識別子を使って、信頼できる関連当事者を決定するステップと、
c)前記信頼できる関連当事者を決定した後に、前記信頼できる当事者に検証リクエストメッセージを送るステップとを備え、前記検証リクエストメッセージは、前記信頼できる当事者または前記提示者が、認証プログラムに参加しているかどうかに関する情報をリクエストし、そして
d)前記信頼できる当事者または前記提示者が前記認証プログラムに参加しているかどうかを示す検証応答メッセージを受信するステップを備える方法。
【請求項2】
前記エリアス識別子は、電話番号である、請求項1に記載の方法。
【請求項3】
前記信頼できる当事者は、前記口座を維持する金融機関である、請求項1に記載の方法。
【請求項4】
前記提示者に、認証リクエストメッセージの送信を開始するステップを更に含む、請求項1に記載の方法。
【請求項5】
前記提示者に、認証リクエストメッセージの送信を開始するステップを更に含み、その後、アクセス制御サーバが前記認証リクエストメッセージを提示者に送る、請求項1に記載の方法。
【請求項6】
前記エリアス識別子を受信する前に、前記提示者は、携帯電話を使って前記エリアス識別子を送る、請求項1に記載の方法。
【請求項7】
ディレクトリサーバにより、前記ステップa)〜d)を実行する、請求項1に記載の方法。
【請求項8】
前記信頼できる当事者は、前記口座識別子を発行した発行者である、請求項7に記載の方法。
【請求項9】
a)提示者の口座に対する口座識別子に関連するエリアス識別子を受信するための符号と、
b)前記エリアス識別子を使って、信頼できる関連する当事者を決定するための符号と、
c)前記信頼できる関連する当事者を決定した後に、前記信頼できる当事者に検証リクエストメッセージを送るための符号とを備え、前記検証リクエストメッセージは、前記信頼できる当事者または前記提示者が、認証プログラムに参加しているかどうかに関する情報をリクエストし、
d)更に前記信頼できる当事者または前記提示者が前記認証プログラムに参加しているかどうかを示す検証応答メッセージを受信するための符号を備えるコンピュータが読み取りできるメディア。
【請求項10】
プロセッサと、
前記プロセッサに結合された請求項9に記載のコンピュータが読み取りできるメディアシステムとを備えるディレクトリサーバ。
【請求項11】
a)提示者の口座に関連する口座識別子に関連するエリアス識別子を提供するステップと、
b)前記エリアス識別子を提供した後に、認証リクエストメッセージを受信するステップと、
c)前記認証リクエストメッセージを受信した後に、認証応答メッセージを送るステップとを備える方法。
【請求項12】
前記エリアス識別子は、電話番号である、請求項11に記載の方法。
【請求項13】
前記提示者の音声を使って、前記エリアス識別子が提供される、請求項11に記載の方法。
【請求項14】
前記提示者が操作する電話で、前記認証リクエストメッセージが受信される、請求項13に記載の方法。
【請求項15】
前記認証応答メッセージは、パスワードまたはPIN番号を含む、請求項14に記載の方法。
【請求項16】
対面取引において前記エリアス識別子が業者に提供される、請求項11に記載の方法。
【請求項17】
業者に対して遠隔地に位置する通信デバイスを使って前記エリアス識別子が、前記業者に提供される、請求項11に記載の方法。
【請求項18】
a)提示者の口座に関連する口座識別子に関連するエリアス識別子を提供するための符号と、
b)前記エリアス識別子を提供した後に、認証リクエストメッセージを受信するための符号と、
c)前記認証リクエストメッセージを受信した後に、認証応答メッセージを送るための符号とを備えるコンピュータが読み取りできるメディア。
【請求項19】
プロセッサと、
前記プロセッサに結合されたアンテナと、
前記プロセッサに結合されたマイクと、
前記プロセッサに結合された請求項18に記載のコンピュータが読み取りできるメディアとを備える電話。
【請求項20】
前記プロセッサに結合された無接点要素を更に備える、請求項19に記載の電話。
【図1】
【図2】
【図3】
【図6】
【図8】
【図9(a)】
【図9(b)】
【図10】
【図4】
【図5】
【図7】
【図2】
【図3】
【図6】
【図8】
【図9(a)】
【図9(b)】
【図10】
【図4】
【図5】
【図7】
【公表番号】特表2010−525461(P2010−525461A)
【公表日】平成22年7月22日(2010.7.22)
【国際特許分類】
【出願番号】特願2010−504222(P2010−504222)
【出願日】平成20年4月16日(2008.4.16)
【国際出願番号】PCT/US2008/060508
【国際公開番号】WO2008/131021
【国際公開日】平成20年10月30日(2008.10.30)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.GSM
【出願人】(508168790)ビザ ユー.エス.エー.インコーポレイテッド (21)
【公表日】平成22年7月22日(2010.7.22)
【国際特許分類】
【出願日】平成20年4月16日(2008.4.16)
【国際出願番号】PCT/US2008/060508
【国際公開番号】WO2008/131021
【国際公開日】平成20年10月30日(2008.10.30)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.GSM
【出願人】(508168790)ビザ ユー.エス.エー.インコーポレイテッド (21)
[ Back to top ]