(57)【要約】トランザクション又は遠隔サービスの使用のために適切に提供される、コンピューティング装置にてユーザを認証する方法において、複数の認証選択肢が前記コンピューティング装置（１）にて前記ユーザへ提供される。前記ユーザによる認証選択肢に対する選択に応答して、前記選択された認証選択肢につき認証プロトコルが実行される。前記認証プロトコルの実行が成功すると、前記コンピューティング装置は、前記遠隔サービスと通信して、前記遠隔サービスにつき認証が成功したことの確認値を、前記複数の認証選択肢のいずれが前記ユーザによって選択されたかを示す指示子と共に提供する。このアプローチは、詐欺検出及び詐欺からの保護において、代理ユーザによるトランザクションを可能にするために使用されてよい。適切なコンピューティング装置とサービス提供がまた、開示される。
2018538625.tif 000002
【特許請求の範囲】
【請求項１】
遠隔サービスのためにコンピューティング装置にてユーザを認証する方法において、前記コンピューティング装置において、
前記ユーザへ複数の認証選択肢を提供するステップと、
前記ユーザによる認証選択肢に対する選択に応答して、前記選択された認証選択肢につき認証プロトコルを実行するステップと、
前記認証プロトコルの実行が成功すると、前記遠隔サービスと通信して、前記遠隔サービスにつき認証が成功したことの確認値を、前記複数の認証選択肢のいずれが前記ユーザによって選択されたかを示す指示子と共に提供するステップと、
を含む方法。
【請求項２】
請求項１に記載の方法において、前記コンピューティング装置は無線通信ハンドセットである、方法。
【請求項３】
請求項１又は２に記載の方法において、前記認証選択肢は少なくとも１つの生体識別子を含む、方法。
【請求項４】
請求項１乃至３のいずれか１項に記載の方法において、前記認証選択肢は、代理ユーザについての少なくとも１つの認証選択肢を含む、方法。
【請求項５】
請求項１乃至４のいずれか１項に記載の方法において、前記コンピューティング装置は支払装置である、方法。
【請求項６】
請求項５に記載の方法において、前記遠隔サービスは、前記支払装置についての発行者認証サービスを含む、方法。
【請求項７】
請求項６に記載の方法において、前記支払装置はＥＭＶプロトコルを含み、選択された前記認証選択肢は発行者アプリケーションデータにて通信される、方法。
【請求項８】
請求項７に記載の方法において、選択された前記認証選択肢は、ＰＩＮ試行計数機にて通信される、方法。
【請求項９】
プロセッサとメモリとを有するコンピューティング装置であって、請求項１乃至８のいずれか１項に記載の方法を実行するようプログラムされ、１以上の認証選択肢を提供するためのユーザ用ユーザインタフェースを有する、コンピューティング装置。
【請求項１０】
詐欺検出方法において、
装置又はサービスのユーザへ複数の認証選択肢を提供するステップと、
前記ユーザにつき、異なる認証選択肢の使用を追跡して、前記ユーザの認証パターンを確立するステップと、
前記使用が前記認証パターンに一致しないとき、認証選択肢の使用は潜在的に詐欺であると識別するステップと、
を含む方法。
【発明の詳細な説明】
【関連出願の相互参照】
【０００１】
本願は、欧州特許出願第15199658.4号（2015年12月11日出願）の優先権を主張するものであり、当該出願の開示全体をここに参照のために取り込む。
【技術分野】
【０００２】
本開示は、概して、トランザクションについてのユーザ認証に関する。実施形態は支払装置上でのユーザ認証に関連し、特定の実施形態は詐欺からの保護のためのユーザ認証情報を使用することに関する。
【背景技術】
【０００３】
支払カード（例えばクレジットカード及びデビットカード）は、金融トランザクションの多くの形態で、非常に広く使用されている。支払カードの使用は、近年の技術的発展に伴い、非常に発展した。多くの支払が小売の場所にてなされる。典型的には、物理的な支払カードが販売時点（POS）端末と相互作用して、トランザクションの承認を支援する。これらの支払カードは、磁気ストライプ読み取り機を介したスワイプによってPOSと相互作用してよいし、「チップカード」又は「スマートカード」については、スマートカード読み取り機と（ISO/IEC7816標準のもとで）直接接触することで、若しくは（ISO/IEC14443標準のもとでの）ローカルな近距離無線通信を介した非接触相互作用により、POSと相互作用してよい。アカウント保有者が支払を要求することを確実にするために、カード保有者検証が使用される。典型的には、このときユーザは、POS又はモバイル支払装置へ入力された個人識別番号（PIN）によって認証される。署名は以前の認証における典型例であったが、今や、概して、PINが使用不可能なときにだけ使用される。他の目的で、多くの他の認証典型例が使用される。すなわち、指紋、顔認識、音声認識及び身振りの全てがある程度使用されており、他の生体認証又は他の識別子も同様である。これらの認証アプローチのいくつかは、ユーザのコンピューティング装置（例えばユーザの携帯電話）を介した認証のために使用されてよい。
【０００４】
ユーザ認証の選択肢が様々あることを考慮すると、ユーザ認証データを豊富に用いることが望ましい。
【発明の概要】
【０００５】
第１の態様では、本発明は、遠隔サービスのためにコンピューティング装置にてユーザを認証する方法を提供し、当該方法は前記コンピューティング装置において、
前記ユーザへ複数の認証選択肢を提供するステップと、
前記ユーザによる認証選択肢に対する選択に応答して、前記選択された認証選択肢につき認証プロトコルを実行するステップと、
前記認証プロトコルの実行が成功すると、前記遠隔サービスと通信して、前記遠隔サービスにつき認証が成功したことの確認値を、前記複数の認証選択肢のいずれが前記ユーザによって選択されたかを示す指示子と共に提供するステップと、
を含む。
【０００６】
いくつかの実施形態では、コンピューティング装置は無線通信ハンドセットであってよい。
【０００７】
認証選択肢は少なくとも１つの生体識別子を含んでよい。認証選択肢は、代理ユーザに対し、少なくとも１つの認証選択肢を含んでよい。
【０００８】
コンピューティング装置は支払装置であってよい。この場合、遠隔サービスは、支払装置についての発行者認証サービスを含んでよい。そのような支払装置はＥＭＶプロトコルを用いてよい。この場合、選択された認証選択肢は発行者アプリケーションデータにて通信されてよい。そのような実施形態では、選択された認証選択肢はＰＩＮ試行計数機（カウンタ）にて高負荷をかけられ、既存のデータ要素及びサイズの継続性を維持し、又は、情報を、カード検証結果データ要素へ、発行者アプリケーションデータのサブ要素として追加してよい。
【０００９】
第２の態様では、本発明は、プロセッサとメモリとを有するコンピューティング装置を提供し、上記の方法を実行するようプログラムされ、１以上の認証選択肢を提供するためのユーザ用ユーザインタフェースを有する。
【００１０】
第３の態様では、本発明は詐欺検出方法を提供する。当該方法は、装置又はサービスのユーザのための複数の認証選択肢を提供することと、そのユーザについての異なる認証選択肢の使用を追跡して、そのユーザの認証パターンを確立することと、当該使用が認証パターンと一致しないとき、認証選択肢の使用を潜在的詐欺として識別することとを含む。
【図面の簡単な説明】
【００１１】
一例として本開示の実施形態が、次の添付図面を参照してここに記載される。
【００１２】
【図１】図１は本発明の実施形態が使用される例示的トランザクションシステムを示す。
【図２】図２ａ及び図２ｂはそれぞれ、本発明の実施形態において使用するためのモバイル装置と発行者銀行アプリケーションサーバとの要素を示す。
【図３】図３は、本開示の観点にしたがってモバイル装置を認証する方法を示す。
【図４】図４は本発明の実施形態が使用される代理トランザクションの使用モデルを示す。
【図５】図５は、本発明の実施形態による、図４の使用モデルを実装する処理フローを示す。
【図６】図６は、本開示の実施形態によって提供されるユーザ認証種別情報を用いた詐欺検出処理の処理フローを示す。
【発明を実施するための形態】
【００１３】
本開示の具体的な実施形態が、図面を参照して下記で記載される。
【００１４】
図１は本発明の実施形態が使用される例示的トランザクションシステムを示す。
【００１５】
ユーザ（不図示）は支払装置の提供を受ける。これは、ユーザコンピューティング装置（例えば携帯電話等又はノートブックコンピュータ若しくはタブレット）であってよい。これは、支払カード又は携帯消費者装置（例えばスマートウォッチ、リストバンド、指輪、車両のキーフォブ、又は、他の装置（これは当業者が、着用可能な1aとして分類する））にとっての代理として動作してよく、支払管理装置１として動作してユーザが自身のアカウントでの支払いを管理することを可能にしてよい。
【００１６】
これらの装置は、典型的には、プロセッサと、対応するプロセッサによって駆動されるファームウェア及びアプリケーションを含む情報を格納するメモリとを有する。支払装置は、支払インフラストラクチャの他の要素と通信する手段を備える。これらの通信手段は、アンテナ並びに関連ハードウェア及びソフトウェアを含んで、ISO/IEC7816チップインタフェースによる通信を可能にしてよいし、アンテナ並びに関連ハードウェア及びソフトウェアを含んで、802.11プロトコル又は上記の任意の組合せを用いて、ローカル無線ネットワーキングを可能にしてよい。
【００１７】
従来のインフラストラクチャ内の他のコンピュータ機器は、典型的には、固定されているが、相互作用の関心点（POI）端末２の場合には携帯可能であってよい。図示される例は、ユーザと相互作用する販売者によって使用されるモバイル販売時点（MPOS）端末である。そのような機器は典型的には、加盟店銀行６又は他のシステムへ安全な方法で（専用チャネルを介して、又は、公衆若しくは非安全チャネル上の安全通信メカニズムを介して）接続され又は接続可能である。ここで、接続は、公衆インターネット８を通貨するものとして示される。また、支払管理装置１とカード発行者銀行５又はユーザに関連付けられたシステムとの間の接続を可能にするメカニズムが存在してよい。銀行インフラストラクチャ７はまた、カード発行者５と加盟店銀行６とを接続し、トランザクションがそれらの間で実行されることを可能にする。
【００１８】
発行者銀行アプリケーションサーバ３は、発行者銀行５の一部として明示される。ここでは単一のコンピューティングシステム（これはプロセッサ、メモリ、通信部、及び当該システムの任意の他の関連要素を含む）として示されるが、発行者銀行アプリケーションサーバ３は発行者銀行の他の要素と共通のコンピューティングシステムの要素として提供されてよいし、物理的又は論理的に分離した要素を含んでよいし、信頼される第三者プロバイダ（例えば銀行インフラストラクチャの提供者）によって提供されるサービスとして全体的又は部分的に実装されてよい。発行者銀行５によって発行者銀行アプリケーションサーバ３を介して提供される２つの機能的要素が、一層詳細に示される。それらは、発行者認証モジュール９と発行者顧客サーバ１０である。発行者認証モジュール９は支払管理装置１へ（いくつかの使用例では）直接接続するものとして示される。もっとも多くの場合、発行者認証モジュールは、銀行インフラストラクチャ７を介してアクセスされ、ユーザがトランザクションを確認することを認証する。発行者顧客サーバ１０はまた、支払管理装置１へ接続するものとして示される。もっともユーザは、任意の適切なコンピューティング装置を用いて発行者顧客サーバ１０へ接続してよい。実施形態では，ユーザは発行者顧客サーバ１０を用いて、ユーザアカウントの使用に関連する許可を設定する。
【００１９】
図２ａ及び２ｂは、ユーザの支払管理装置１と発行者システム（これは発行者認証モジュール９及び発行者顧客サーバ１０を含む）との関連機能を概念的に示す。
【００２０】
図２ａは支払管理装置１を示し、携帯ハンドセットであってよい。もっとも、任意の他の携帯コンピューティング装置（例えばラップトップ、ノートブック、タブレットコンピュータ）又は固定装置（例えばデスクトップコンピュータ）が、本発明の実施形態にてコンピューティング装置として使用されてよい。支払管理装置はプロセッサ２０１とメモリ２０２を含む。このためメモリとプロセッサとはアプリケーション（これはアプリケーション空間２０３に存在するものとして概して示される）（例えば支払管理アプリケーション２０３ａ、指紋走査アプリケーション２０３ｂ、及び音認識アプリケーション２０３ｃ）を実行する。指紋走査アプリケーション２０３ｂ及び音認識アプリケーション２０３ｃは生体認識アプリケーションの例であり、ユーザ認証のために使用されてよく、他の認証メカニズム（例えばアプリケーション内のパスワード）を捕捉又は置き換える。このとき、他の生体認識代替物（例えば顔及び身振りの認識）もまた、使用可能である。支払管理装置は、ディスプレイ２０４とタッチスクリーン２０５（又は他の入力装置）とを含むユーザインタフェースを有し、ユーザがアプリケーション２０３へデータを入力し及びアプリケーション２０３から情報を視認することを可能にする関連ドライバを有する。支払管理装置１はまた、通信機能（例えば加入者情報モジュール２０６と無線通信要素２０７）を有し、携帯通信ネットワークへ接続する機能を提供する。更に又は代替的に、支払管理装置１はwifi又は有線ネットワークアクセスを含んでよい。支払管理装置１は暗号による動作を実行する必要があってよく、銀行アプリケーションサーバ３と相互作用する。
【００２１】
図２ｃは、支払カード１ａの要素が暗号による動作を実行して、POS端末と安全に相互作用し又は具体的な認証方法を支援する必要があってよいことを示す。このことは、暗号機能（例えばタンパ保護された要素内の安全処理環境２０９）によって実現されてよい。この安全処理環境は、暗号プロセッサとメモリの安全領域とを含んでよく、メインアプリケーション空間２０３内のアプリケーションによる使用のための秘密情報を保持してよい。あるいはこれらのアプリケーションの一部は安全処理環境２０９内で動作してよい。
【００２２】
図２ｂは発行者銀行アプリケーションサーバの要素を示す。これは、プロセッサ２２１及びメモリ２２２を有する処理環境２２０と、関連通信機能２２３とを含むものとして示される。通信機能はネットワーキング機能を有してよい。これは、支払ネットワークインフラストラクチャ７との通信を可能にする。公衆インターネット上での支払管理装置１との通信を安全に可能にする通信機能が存在してよい。プロセッサ２２１は処理能力を示してよく、実際、いくつかのプロセッサによって提供されてよい。他の機能（例えばユーザデータベース）は、ここでは明示されない。というのも、それらは従来の手段によって実装されてよく、本開示の要素を説明するのに更に議論する必要がないからである。発行者認証モジュール９は処理環境２２０内の要素として示される。このとき関連ユーザ認証データ２２９はメモリ２２２に格納される。発行者顧客サーバ１０はまた、処理環境２２０内の要素として示されてよい。処理環境２２０内に示される要素は、プロセッサ２２１とメモリ２２２とを用いて、機能を提供する。発行者認証モジュール９の場合、この機能は、発行者５が確認値を銀行インフラストラクチャ７と加盟店銀行６（これはトランザクションに関わる正当なカード保有者である）とへ提供するためのものである。一方で発行者顧客サーバの場合、その機能は、発行者銀行５の、カードを保有する顧客のためのものである。実施形態では暗号プロセッサ２３１は、発行者銀行アプリケーションサーバ３と支払管理装置１との間の安全な通信を可能にするのに使用されてよい。
【００２３】
図３は、本開示の態様による、コンピューティング装置での、一般的な用語での認証方法を示す。まず、支払装置１又は１ａによって支援される複数の認証選択肢は、ステップ３１０にて、装置のユーザに対し利用可能となる。上記のように、これらはパスワードの提供と、生体識別子（例えば指紋、音、又は顔認識）と、任意の他の適切なメカニズムを含んでよい。選択がなされると、適切な認証プロトコルがステップ３２０にて実行される。ほとんどの実施形態では、コンピューティング装置はモバイル装置であり、特に、携帯電話又はタブレットコンピュータである。しかし、他の実施形態では、代理による支払カード１ａを含む携帯消費者装置の広い範囲に適用されてよい。認証が成功すると、認証成功と選択された認証選択肢との両方の指示子がステップ３３０にて関連当事者へ送信される。モバイル装置が支払装置として使用される場合、それは発行者銀行５又は発行者認証モジュール９であってよい。
【００２４】
このアプローチは、従来の認証で用いられたものとは異なる。というのも、従来の認証ではモバイル装置にて認証種別は記録されず、特に、確認された認証と共に任意の遠隔当事者へ送信されない。このように認証種別を保存及び送信することにより、遠隔当事者は認証だけでなく、判定時に選択された認証選択肢をも評価（ステップ３４０）することができる。下記のように、これは少なくとも２つの場合に関する。すなわち、支払装置の使用につき、代理人へ許可を与えることと、改良版詐欺検出及び保護とである。
【００２５】
代理トランザクションが図４及び５を参照して検討される。図４は本発明の実施形態で使用される代理トランザクションの使用モデルを示す。ユーザ４０は発行者顧客サーバ１０と、モバイル装置１又は他のコンピューティング装置４１を介して相互作用する。ユーザ４０は支払装置（この場合、モバイル装置１）を介して支払カード１ａに関連付けられたユーザアカウントへアクセスすることを許可された１以上の代理人４２を、特定の認証方法（例えば代理人の生体認識、又は、代理人特有のパスワード）と共に、識別する。これは、使用上の任意の制限及び制御事項と共に、ユーザ４０と発行者顧客サーバ１０との間で、支払装置許可ソフトウェア４３を用いて確立される。これは、例えば、所有者の制御下（In  Control）ソフトウェアの修正版であってよい。代理人４２によって代理人特有認証方法を用いてモバイル装置１を支払装置として使用すると（ここでは端末２との相互作用として示される）、トランザクション詳細は銀行インフラストラクチャを介して発行者銀行５（これは便宜上、発行者顧客サーバ１０とは別に、相互作用するように示される）へ戻される。トランザクション詳細はモバイル支払装置１での認証の指示子だけでなく、認証方法の指示子（これは代理人認証としての認証を識別するのに十分である）も含む。発行者銀行５は、支払装置許可ソフトウェアを介して判定された許可を用いて、代理人４２による使用が正当か否かだけでなく、それがユーザ４０によって確立された使用許可内であるか否かを確立可能である。
【００２６】
図５は、本発明の実施形態による、図４の使用モデルを実装する処理フローを示す。まずユーザと発行者とは、使用許可と、代理人用の認証選択肢とを確立する（ステップ５１０）。代理人は支払装置を用いてトランザクションを実行する（ステップ５２０）。このときトランザクション情報と代理人により使用される認証選択肢とは、発行者へ提供される（ステップ５３０）。もしトランザクションが使用許可内であり且つ認証選択肢が代理人にとって有効なら、発行者５４０はトランザクションを許可する。いくつかの実施形態では、このステップは、トランザクションが完了してから実行されてよい。このとき他のアクション（例えば発行者とユーザとの間の直接通信までのアカウント停止）が代わりに実行されてよい。
【００２７】
図５に示すステップの各々が、より詳細に示される。
【００２８】
ユーザと発行者とはまず、誰が正当な代理人か、その代理人の使用許可は何か、及び、その代理人についての認証選択肢を、発行者顧客サーバ１０によってホストされる適切な支払装置許可ソフトウェア４３を用いて確立可能である。このときユーザはモバイル装置１又は他のコンピューティング装置４１上でクライアントを介して相互作用する。支払装置許可ソフトウェア４３は本願出願人の制御下ソフトウェアの機能により拡張されてよい。もっとも本発明の実施形態は、既存の制御下機能を使用する必要がない。制御下ソフトウェアは発行者顧客サーバ１０上にホストされ、又は類似的に、発行者の代わりにホストされる。それは現在、ユーザが、発行者によって許可されたクレジット上限を超えた自身の使用行動に制限を設定することを可能にし、例えば、家族内又は同僚内のカード保有者の使用行動を制御するのに使用されてよい。これらの場合、カード「所有者」は、カード「ユーザ」と異なってよい。支払装置を使用するために請求書を支払う最終的な責任を有してこれらの許可を設定するのは、典型的には所有者である。
【００２９】
機能拡張によりユーザは、代理人が支払装置（下記で説明の便宜のために「カード」と称される）を使用できるように確立することができる。これは、カード所有者が複数の支払装置につき責任を有するがそれらは別々のカード保有者を有するという既存の関係とは異なる。カード所有者は現在、カード所有者がカード保有者でもあるというカードについて代理人を確立するメカニズムを有さない。現在、これは問題であると考慮されている。というのも、主に、本発明の実施形態で対処される認証についての懸念が理由である。新たな機能によって代理人が確立され、その代理人についての認証選択肢もまた確立される。代理人許可は、制御技術と同様に代理人につき確立可能であり、金銭的又は時間利用上の制約、地理的制約、又は特定の販売者若しくは特定のトランザクション種別についての使用に関する制約を可能にする。
【００３０】
代理人確立は、ユーザと代理人との両方により十分安全と考えられる方法で実現されるべきである。代理人アイデンティティは、ユーザセッションにて確立される必要がある。１つの可能性は、代理人がセッションにおいて存在し、代理人詳細と代理人認証選択肢とをセッション（このときユーザは処理に対し正当な可視性を有する）にて完成させることである。もし代理人が物理的な支払装置（例えばモバイル装置１）を使用しそれがまた、支払装置許可ソフトウェアとの関連セッションにつき使用されることを意図するなら、これは適切な選択肢である。モバイル装置１は単純に代理人へ手渡され、代理人詳細が入力され、代理人認証選択肢が確立される。これは、代理人にとって個人的なパスワードであってよいし、生体認識（例えば代理人指紋）であってよい。これはまた、代理人認証選択肢に関連付けられた安全なデータがモバイル装置自体を超えて送信される必要がなくその装置の安全領域内に保持されることを意味する。
【００３１】
代理人詳細を確立するための他の選択肢は、ユーザが、代理人についての十分な詳細を提供し、代理人が発行者顧客サーバ１０との自身のセッションを確立することである。これは例えば、異なる通信パスを用いて（例えばeメールアドレス及び携帯電話番号）ユーザが２つの代理人証明書を提供し、代理人認証選択肢が確立される代理人セッション内で２要素相互作用を可能にすることを伴う。このアプローチは、ユーザと代理人と発行者とへ、十分なレベルの安全性を提供する。
【００３２】
代理人認証を確立する別の方法は、ユーザが、代理人の認証パスワード又はPINコードを代理でロードし、当該コードを代理人へ直接通信することである。実施形態では、装置が支払用に使用可能となる前に、代理人がこの認証証明書を支払管理装置１上で変更しなくてはならない。
【００３３】
支払装置が支払カード１ａである実施形態では、支払管理装置１は、認証確立中に、代理人認証データを支払カード１ａへ通信する（ステップ３３０）。
【００３４】
代理人による支払装置の使用は、本質的には、ユーザによる使用と同一である。というのも、代理人は同様にトランザクションに参加し、認証を提供するよう求められたときに代理人認証選択肢を提供するからである。販売者と加盟店銀行との観点からは、既存の処理に変更はない。しかし、トランザクション詳細は、発行者銀行と銀行インフラストラクチャとのみに関する方法で修正される。これを行う適切な方法はこの直後に記載される。
【００３５】
支払装置について、利用可能な様々なカード保有者検証方法（CVM）が複数存在してよい。チップ及びピン端末と相互作用する物理的なカードについては、標準CVMはオンラインPIN（個人識別番号）であり、このとき、PIN情報が入力されてカード発行者へ送信される。一方オフラインPINトランザクションについては、発行者とのオンライン通信はなされないが、支払装置自身によるPIN確認がなされる。主な支払装置標準は、EMVCoによる技術によって発展されたものである。これは、https://www.emvco.com/specifications.aspxにて仕様を提供する。実際、生体認識、身振り、及び他の認証アプローチは、支払装置にて、ユーザ認証プロトコルの一部として使用されてよい。しかし、これらは任意の記録されたトランザクション情報において区別されない（これらは、発行者との直接的な通信があるか否かに応じて、典型的には、オンラインPIN、オフラインPIN、又は消費者−装置カード保有者検証（CD-CVM）として取り扱われる）。しかし、EMVCoプロトコルのもとで発行者へ提供される、トランザクションからの特定の情報が存在する。これは、発行者アプリケーションデータ（IAD）として知られる。このIADメッセージは、CVM種別を示す、追加の１以上のバイトのデータを伝送するよう拡張される。値は、使用されるCVMの種別だけでなく、PIN（又はその同等物）がユーザ又は代理人に関連するか否かを示すように選択可能である。既存のメッセージサイズを変更しない代替アプローチは、関連フィールド（例えば、実行された認証試行の数を追跡するPIN試行計数機（PIN  Try  Counter））へ負担をかけすぎる。これは、全バイトを要求しない。というのも特に、ほとんどの安全性プロトコルは任意の認証アプローチを要求して、全バイトの認証試行が実行される前に挫折するからである。これは例えば、PIN試行計数機の低いニブル（値：x0...xF）が自身の元の機能を保持することによってなされうるが、高いニブル（値：0x...Fx）がCVM種別（指紋、パスコード、PIN、身振り、代理人識別子等）を伝送する。これにより、トランザクション詳細は、販売者と加盟店銀行と銀行インフラストラクチャのほとんどの部分とによって、通常の方法で処理されることができる。他方でCVM種別情報は発行者、銀行インフラストラクチャ又は発行者に代わって動作する他の当事者（いくつかの実施形態では、発行者から独立した銀行インフラストラクチャ）によって使用されることができる。
【００３６】
トランザクション詳細が発行者（具体的には発行者認証モジュール９）へ到達すると、CVM種別情報は、CVMがカード保有者に関連するか代理人に関連するかを判定するために使用されてよい（このこと以上に、CVM情報を記録することには他の利点がある（下記参照））。発行者は次いで、トランザクションがユーザ／カード保有者と発行者とによって代理人について確立された許容動作内にあるか否かを判定する。もしそうなら、トランザクションは（オンライントランザクションについて）適宜承認又は拒否され、（トランザクションがオフライン且つ完了なら）適切にフラグ付けされる。これにより、状況が整うまで関連カード保有者アカウントの使用は防がれる。
【００３７】
代理人による使用は、図３の示す認証選択肢についての使用されるアプローチの利点の１つである。しかし、この追加的な認証情報の利用可能性による利点は他にも（特に詐欺防止に）ある。図６は、本開示の実施形態によって提供されるユーザ認証種別情報を用いた詐欺検出処理の処理フローを示す。
【００３８】
本実施形態にしたがって支払装置を用いてトランザクションが実行されると、複数の利用可能な認証選択肢のうち１つが使用される（ステップ６１０）。選択された認証選択肢を含むトランザクション情報は支払インフラストラクチャへ送信され（ステップ６２０）、発行者（実施形態によっては、発行者認証モジュール９）に代わって動作するシステムへ提供され、支払装置の使用が妥当か否かを確立する。発行者（又は発行者にとっての若しくは発行者以外の銀行インフラストラクチャ）は次いで、トランザクション詳細（これは選択された認証選択肢を含む）から、トランザクションが、支払装置についてのユーザの既存の使用パターンと一貫していないか（潜在的に詐欺か）否かを（例えばリスク点数をトランザクション機能に割り当てて、トランザクションについての全体リスク点数を確立することによって）判定する（ステップ６３０）。もしそうであれば、アクションを実行して（ステップ６４０）、トランザクションが潜在的に詐欺であると識別する。使用される認証形態は（仮に予期されたものでなくても）、発行者によって確立され承認されたものである。よって、トランザクションの拒否は適切でないかもしれない。そこで、代替例は、カード保有者へ発呼して、使用者が正当であることを確認することである。
【００３９】
選択された認証選択肢を識別することでもたらされる追加の情報は、任意のリスク点数に重大に影響しうる。例えば自身の携帯電話でのトランザクションについて、ユーザは便利な生体認識（例えば指紋）又は、他の認証選択肢を習慣的に使用することがある。他の認証選択肢（例えばパスワード）が利用可能であるが、その支払装置でのトランザクションのために普通は決して使用されない。携帯電話上でのユーザ認証のためにパスワードを使用することは、使用が詐欺的であるリスクをかなり高める。というのも、パスワードについては、支払装置の使用についてのユーザの通常のパターンからの相違点が明りょうだからである。
【００４０】
上記で詳述された実施形態は主に支払装置に関するが、本実施形態は他の文脈で提供されてよい。本発明の範囲は請求項の趣旨及び範囲で画定されるので、本実施形態によって限定されない。
【図１】
2018538625.tif 000003
【図２ａ】
2018538625.tif 000004
【図２ｂ】
2018538625.tif 000005
【図３】
2018538625.tif 000006
【図４】
2018538625.tif 000007
【図５】
2018538625.tif 000008
【図６】
2018538625.tif 000009
【国際調査報告】
2018538625.tif 000010
2018538625.tif 000011