JP2019502204A - トランザクションの代理 - Google Patents

Abstract

支払証明書を用いてトランザクション（ここではトランザクションが代理ユーザによって承認される）を実行する方法が記載される。双方の間の支払証明書のユーザと発行者とは、代理人用に使用許可と認証選択肢とを確立する。代理ユーザは支払証明書を用いてトランザクションを実行する。トランザクションと、代理ユーザによって使用される認証選択肢との両方がユーザへ提供される。トランザクションが使用許可内であり且つ認証選択肢が代理ユーザにつき妥当であるとき、発行者は次いでトランザクションを許可する。適切なコンピューティング装置とサービス提供とがまた、開示される。

Description

関連出願の相互参照

本願は、欧州特許出願第15199664.2号（2015年12月11日出願）の優先権を主張するものであり、当該出願の開示全体をここに参照のために取り込む。

本開示は、概して、トランザクションについてのユーザ識別及び認証に関する。一実施形態は支払装置上でのユーザ認証に関連し、特定の実施形態は第２のユーザの認証に関する。

支払カード（例えばクレジットカード及びデビットカード）は、金融トランザクションの多くの形態で、非常に広く使用されている。支払カードの使用は、近年の技術的発展に伴い、非常に発展した。多くの支払が小売の場所にてなされる。典型的には、物理的な支払カードが販売時点（POS）端末と相互作用して、トランザクションの承認を支援する。これらの支払カードは、磁気ストライプ読み取り機を介したスワイプによってPOSと相互作用してよいし、「チップカード」又は「スマートカード」については、スマートカード読み取り機と（ISO/IEC7816標準のもとで）直接接触することで、若しくは（ISO/IEC14443標準のもとでの）ローカルな近距離無線通信を介した非接触相互作用（インタラクション）により、POSと相互作用してよい。アカウント保有者が支払を要求することを確実にするために、カード保有者検証が使用される。このときユーザは、POS又はモバイル支払装置へ入力された個人識別番号（PIN）によって典型的には認証される。署名は以前の認証における典型例であったが、今や、概して、PINが使用不可能なときにだけ使用される。他の目的で、多くの他の認証典型例が使用される。すなわち、指紋、顔認識、音声認識及び身振りの全てがある程度使用されており、他の生体認証又は他の識別子も同様である。これらの認証アプローチのいくつかは、ユーザの携帯電話を介した認証のために使用されてよい。

ユーザ行動の一層の理解と良好な測定とによって、支払装置トランザクションにおける一層洗練された詐欺検出を可能にした。更なる発展は、ユーザが、自身の許可された又は予測された行動を判定するためのものである。これによって、カード保有者ではないかもしれない請求書支払者によって保証されたカード群又は単一カードを使用することについて境界を設定し、特定の使用制限を可能にし、行動がユーザ設定境界の外で行われたときの詐欺検出を強化する。これは例えば、所有者の「インコントロール（In Control）」という制御手段を使用することによって達成される。カード発行者はインコントロールを使用して、ウェブサイト又はモバイルアプリを提供する。当該インコントロールは、承認済みユーザが、当該ユーザの制御下でカードについての様々な異なる上限又は許可を設定することを可能にする。

現在、解決手段が存在する。ここでは、カード所有者は自身のカード又は他の支払装置を使用することを他の人物に代理させることが好ましい。しかしこれは現在、法的及び実務的困難を生み出している。代理トランザクションを支援するための、ユーザ相互作用の様々な可能性を可能にすることが好ましい。

第１の態様では、本発明は、支払証明書を用いてトランザクションを実行する方法を提供し、前記支払証明書は、前記トランザクションにおいてユーザを代理するよう構成された装置において実装され、支払証明書のユーザ及び発行者は、代理ユーザにつき使用許可と認証選択肢とを確立し、前記方法は、
前記代理ユーザが、前記支払証明書を用いて支払ネットワークインフラストラクチャの端末と前記トランザクションを実行するステップであって、前記トランザクションと前記代理ユーザによって使用される前記認証選択肢とは、前記支払ネットワークインフラストラクチャを介して前記発行者へ提供される、ステップを含み、
前記トランザクションが前記使用許可内であり且つ前記認証選択肢が前記代理ユーザにつき妥当であるとき、前記発行者の発行者認証モジュールは前記トランザクションを許可するよう構成される。

このアプローチは、ユーザのアカウントを使用して、ユーザから代理人へ、トランザクションを行う能力を有効に、しかしユーザの有効な制御下で代理させることを可能にする、下記の通り、このアプローチは非常に多目的に利用でき、多くの使用モデルにおいて利用可能である。

一実施形態では、支払証明書はコンピューティング装置である。このときコンピューティング装置は支払証明書として動作するようプログラムされ、管理装置として発行者に対し使用許可を確立するよう適合される。コンピューティング装置は例えば無線通信ハンドセットであってよい。

別の実施形態では、支払証明書は任意のコンピューティング装置から分離する。当該任意のコンピューティング装置は管理装置として動作し、発行者に対し使用許可を確立するよう適合される。そのような支払証明書は支払カードであってよいが、トランザクションを開始するよう適合されたトランザクション処理システムの端末によって認識される任意の要素であってよい。

実施形態では、支払証明書はＥＭＶプロトコルを用いてトランザクションを開始するよう適合される。このとき、選択された認証選択肢は発行者アプリケーションデータにて通信される。選択された認証選択肢は、ＰＩＮ試行カウンタ（計数機）にて通信されてよい。

発行者がオンラインである実施形態では、代理ユーザにつき使用許可と認証選択肢との両方が妥当でないとき、トランザクションは実行されない。

発行者がオフラインである実施形態では、支払装置での妥当なトランザクションのあと、トランザクションが完了してよい。

認証選択肢は生体識別子を含んでよい。

第２の態様では、本発明は任意の先行する請求項の方法において使用するのに適合された支払証明書を含む。

第３の態様では、本発明は、上記の適切な方法において管理装置として使用するのに適合されたコンピューティング装置を提供する。

本発明の実施形態が、次の添付図面を参照してここに例示的に記載される。

図１は本発明の実施形態が使用される例示的トランザクションシステムを示す。 図２ａ及び図２ｂはそれぞれ、本発明の実施形態において使用するためのモバイル装置と発行者銀行アプリケーションサーバとの要素を示す。 図３は、本開示の観点にしたがってモバイル装置を認証する方法を示す。 図４は本発明の実施形態が使用される代理トランザクションの使用モデルを示す。 図５は、本発明の実施形態による、図４の使用モデルを実装する処理フローを示す。 図６は、図４の使用モデルの代替案を示す。

本開示の具体的な実施形態が、図面を参照して下記で記載される。

図１は本発明の実施形態が使用される例示的トランザクションシステムを示す。

ユーザ（不図示）は支払装置の提供を受ける。これは例えば支払カード１ａであってよい。下記の通り本発明の実施形態では、支払装置は任意の要素であってよい。当該任意の要素は、支払いを行うためにトランザクションインフラストラクチャへユーザがアクセスすることを可能にするために使用されてよい。

ユーザはまた、支払管理装置を付与される。これによりユーザは自身のアカウント上での支払を管理可能である。ここで、携帯無線通信端末１である（しかしこれは、任意の他のモバイルコンピューティング装置であってよい。実施形態では、これはモバイル装置でなくてよいし、デスクトップコンピューティングであってよい）。支払管理装置１が支払装置でもある実施形態では、支払管理装置１が支払機能（これはNFC非接触通信機能を有する携帯電話上で見られる）を含むとき、それは支払カード１ａの代理として動作してよい。支払装置についての他の可能な選択肢は、携帯消費者装置（例えばスマートウォッチ、リストバンド、指輪、車両のキーフォブ、又は、他の装置（これは当業者が、着用可能な1aとして分類する））であってよい。これらの装置は支払管理装置１として動作してユーザが自身のアカウントでの支払いを管理することを可能にしてよい。

ここで、主要ユーザ１１が代理人１２と共に示される。下記の通り、本実施形態は、主要ユーザ１１が代理人１２に、支払装置１ａを使用して、許可された方法でトランザクションを実行することを可能にするような方法に関する。

支払管理装置及び支払装置は典型的には、プロセッサと、対応するプロセッサによって駆動されるファームウェア及びアプリケーションを含む情報を格納するメモリとを有する。支払装置は、支払インフラストラクチャの他の要素と通信する手段を備える。これらの通信手段は、アンテナ並びに関連ハードウェア及びソフトウェアを含んで、ISO/IEC7816チップインタフェースによる通信を可能にしてよいし、アンテナ並びに関連ハードウェア及びソフトウェアを含んで、802.11プロトコル又は上記の任意の組合せを用いて、ローカル無線ネットワーキングを可能にしてよい。

従来のインフラストラクチャ内の他のコンピュータ機器は、典型的には固定されているが、相互作用の関心点（POI）端末２の場合には携帯可能であってよい。図示される例は、ユーザと相互作用する販売者によって使用されるモバイル販売時点（MPOS）端末である。そのような機器は典型的には、加盟店銀行６又は他のシステムへ安全な方法で（専用チャネルを介して、又は、公衆若しくは非安全チャネル上の安全通信メカニズムを介して）接続され又は接続可能である。ここで、接続は、公衆インターネット８を通貨するものとして示される。また、支払管理装置１とカード発行者銀行５又はユーザに関連付けられたシステムとの間の接続を可能にするメカニズムが存在してよい。銀行インフラストラクチャ７はまた、カード発行者５と加盟店銀行６とを接続し、トランザクションがそれらの間で実行されることを可能にする。

発行者銀行アプリケーションサーバ３は、発行者銀行５の一部として明示される。ここでは単一のコンピューティングシステム（これはプロセッサ、メモリ、通信部、及び当該システムの任意の他の関連要素を含む）として示されるが、発行者銀行アプリケーションサーバ３は発行者銀行の他の要素と共通のコンピューティングシステムの要素として提供されてよいし、物理的又は論理的に分離した要素を含んでよいし、信頼される第三者プロバイダ（例えば銀行インフラストラクチャの提供者）によって提供されるサービスとして全体的又は部分的に実装されてよい。発行者銀行５によって発行者銀行アプリケーションサーバ３を介して提供される２つの機能的要素が、一層詳細に示される。それらは、発行者認証モジュール９と発行者顧客サーバ１０である。発行者認証モジュール９は支払管理装置１へ（いくつかの使用例では）直接接続するものとして示される。もっとも多くの場合、発行者認証モジュールは、銀行インフラストラクチャ７を介してアクセスされ、ユーザがトランザクションを確認することを認証する。発行者顧客サーバ１０はまた、支払管理装置１へ接続するものとして示される。もっともユーザは、任意の適切なコンピューティング装置を用いて発行者顧客サーバ１０へ接続してよい。実施形態では、ユーザは発行者顧客サーバ１０を用いて、ユーザアカウントの使用に関連する許可を設定する。

図２ａ及び２ｂは、ユーザの支払管理装置１と発行者システム（これは発行者認証モジュール９及び発行者顧客サーバ１０を含む）との関連機能を概念的に示す。

図２ａは支払管理装置１を示し、携帯ハンドセットであってよい。もっとも、任意の他の携帯コンピューティング装置（例えばラップトップ、ノートブック、タブレットコンピュータ）又は固定装置（例えばデスクトップコンピュータ）が、本発明の実施形態にてコンピューティング装置として使用されてよい。支払管理装置はプロセッサ２０１とメモリ２０２を含む。このためメモリとプロセッサとはアプリケーション（これはアプリケーション空間２０３に存在するものとして概して示される）（例えば支払管理アプリケーション２０３ａ、指紋走査アプリケーション２０３ｂ、及び音認識アプリケーション２０３ｃ）を実行する。指紋走査アプリケーション２０３ｂ及び音認識アプリケーション２０３ｃは生体認識アプリケーションの例であり、ユーザ認証のために使用されてよく、他の認証メカニズム（例えばアプリケーション内のパスワード）を捕捉又は置き換える。このとき、他の生体認識代替物（例えば顔及び身振りの認識）もまた、使用可能である。支払管理装置は、ディスプレイ２０４とタッチスクリーン２０５（又は他の入力装置）とを含むユーザインタフェースを有し、ユーザがアプリケーション２０３へデータを入力し及びアプリケーション２０３から情報を視認することを可能にする関連ドライバを有する。支払管理装置１はまた、通信機能（例えば加入者情報モジュール２０６と無線通信要素２０７）を有し、携帯通信ネットワークへ接続する機能を提供する。更に又は代替的に、支払管理装置１はwifi又は有線ネットワークアクセスを含んでよい。支払管理装置は暗号による動作を実行する必要があってよく、銀行アプリケーションサーバ３と相互作用する。

図２ｃは、支払カード１ａの要素が暗号による動作を実行して、POS端末と安全に相互作用し又は具体的な認証方法を支援する必要があってよいことを示す。このことは、暗号機能（例えばタンパ保護された要素内の安全処理環境２０９）によって実現されてよい。この安全処理環境は、暗号プロセッサとメモリの安全領域とを含んでよく、メインアプリケーション空間２０３内のアプリケーションによる使用のための秘密情報を保持してよい。あるいはこれらのアプリケーションの一部は安全処理環境２０９内で動作してよい。本実施形態では、支払管理装置１及び支払カード１ａは同一装置であってよい。図２ｂは発行者銀行アプリケーションサーバ３の要素を示す。これは、プロセッサ２２１及びメモリ２２２を有する処理環境２２０と、関連通信機能２２３とを含むものとして示される。通信機能はネットワーキング機能を有してよい。これは、支払ネットワークインフラストラクチャ７との通信を可能にする。公衆インターネット上での支払管理装置１との通信を安全に可能にする通信機能が存在してよい。プロセッサ２２１は処理能力を示してよく、実際、いくつかのプロセッサによって提供されてよい。他の機能（例えばユーザデータベース）は、ここでは明示されない。というのも、それらは従来の手段によって実装されてよく、本開示の要素を説明するのに更に議論する必要がないからである。発行者認証モジュール９は処理環境２２０内の要素として示される。このとき関連ユーザ認証データ２２９はメモリ２２２に格納される。発行者顧客サーバ１０はまた、処理環境２２０内の要素として示されてよい。処理環境２２０内の示される要素は、プロセッサ２２１とメモリ２２２とを用いて、機能を提供する。発行者認証モジュール９の場合、この機能は、発行者５が確認値を銀行インフラストラクチャ７と加盟店銀行６（これはトランザクションに関わる正当なカード保有者である）とへ提供するためのものである。一方で発行者顧客サーバの場合、その機能は、発行者銀行５の、カードを保有する顧客のためのものである。実施形態では暗号プロセッサ２３１は、発行者銀行アプリケーションサーバ３と支払管理装置１との間の安全な通信を可能にするのに使用されてよい。

図３は、本開示の態様による、コンピューティング装置での、一般的な用語での認証方法を示す。まず、支払装置１又は１ａによって支援される複数の認証選択肢は、ステップ３１０にて、装置のユーザに対し利用可能となる。当該複数の認証選択肢はパスワードの提供と、生体識別子（例えば指紋、音、又は顔認識）と、任意の他の適切なメカニズムを含んでよい。選択がなされると、適切な認証プロトコルがステップ３２０にて実行される。ほとんどの実施形態では、コンピューティング装置はモバイル装置であり、特に、携帯電話又はタブレットコンピュータである。しかし、他の実施形態では、携帯消費者装置の広い範囲に適用されてよい。認証が成功すると、認証成功と選択された認証選択肢との両方の指示子がステップ３３０にて関連当事者へ送信される。モバイル装置が支払装置として使用される場合、それは発行者銀行５又は発行者認証モジュール９であってよい。

このアプローチは、従来の認証で用いられたものとは異なる。というのも、従来の認証ではモバイル装置にて認証種別は記録されず、特に、確認された認証と共に任意の遠隔当事者へ送信されない。このように認証種別を保存及び送信することにより、遠隔当事者は認証だけでなく、判定時に選択された認証選択肢をも評価（ステップ３４０）することができる。下記のように、これは少なくとも２つの場合に関する。すなわち、支払装置の使用について代理人へ許可を与えることと、改良版詐欺検出及び保護とである。

代理トランザクションが、図４及び５を参照して検討される。図４は本発明の実施形態で使用される代理トランザクションの使用モデルを示す。この場合、支払装置は、支払管理装置としても使用可能であるモバイル装置である。ユーザ１１は発行者顧客サーバ１０と、モバイル装置１（又は他のコンピューティング装置４１）を介して相互作用する。ユーザ１１は支払装置（この場合、モバイル装置１）を介してユーザアカウントへアクセスすることを許可された１以上の代理人１２を、特定の認証方法（例えば代理人生体認識、又は、代理人特有パスワード）を用いて識別する。これは、使用上の任意の制限及び制御事項と共に、ユーザ１１と発行者顧客サーバ１０との間で、支払装置許可ソフトウェア４３を用いて確立される。これは、例えば、所有者のインコントロールソフトウェアの修正版であってよい。代理人１２によって代理人特有認証方法を用いてモバイル装置１を支払装置として使用すると（ここでは端末２との相互作用として示される）、トランザクション詳細は銀行インフラストラクチャを介して発行者銀行５（これは便宜上、発行者顧客サーバ１０とは別に、相互作用するように示される）へ戻される。トランザクション詳細はモバイル支払装置１での認証の指示子だけでなく、認証方法の指示子（これは代理人認証としての認証を識別するのに十分である）も含む。発行者銀行５は、支払装置許可ソフトウェアを介して判定された許可を用いて、代理人１２による使用が正当か否かだけでなく、それがユーザ１１によって確立された使用許可内であるか否かを確立可能である。

図５は、本発明の実施形態による、図４の使用モデルを実装する処理フローを示す。まずユーザと発行者とは、代理人用の、使用許可と認証選択肢とを確立する（ステップ５１０）。代理人は支払装置を用いてトランザクションを実行する（ステップ５２０）。このときトランザクション情報と代理人により使用される認証選択肢とは、発行者へ提供される（ステップ５３０）。もしトランザクションが使用許可内であり且つ認証選択肢が代理人にとって妥当なら、発行者５４０はトランザクションを許可する。いくつかの実施形態では、このステップは、トランザクションが完了してから実行されてよい。このとき他のアクション（例えば発行者とユーザとの間の直接通信までのアカウント停止）が代わりに実行されてよい。

図５に示すステップの各々が、より詳細に示される。

ユーザと発行者とはまず、誰が正当な代理人か、その代理人の使用許可は何か、及び、その代理人についての認証選択肢を、発行者顧客サーバ１０によってホストされる適切な支払装置許可ソフトウェア４３を用いて確立可能である。このときユーザはモバイル装置１又は他のコンピューティング装置４１上でクライアントを介して相互作用する。支払装置許可ソフトウェア４３は本願出願人のインコントロールソフトウェアの機能により拡張されてよい。もっとも本発明の実施形態は、既存のインコントロール機能を使用する必要がない。インコントロールソフトウェアは発行者顧客サーバ１０上にホストされ、又は類似的に、発行者の代わりにホストされる。それは現在、ユーザが、発行者によって許可されたクレジット上限を超えた自身の使用行動に制限を設定することを可能にし、例えば、家族内又は同僚内のカード保有者の使用行動を制御するのに使用されてよい。これらの場合、カード「所有者」は、カード「ユーザ」と異なってよい。支払装置を使用するために請求書を支払う最終的な責任を有してこれらの許可を設定するのは、典型的には所有者である。

機能拡張によりユーザは、代理人が支払装置（この支払装置は概して、支払カードについての代理人であり、下記で説明の便宜のために「カード」と称される）を使用できるように確立することができる。これは、カード所有者が複数の支払装置につき責任を有するがそれらは別々のカード保有者を有するという既存の関係とは異なる。カード所有者は現在、カード所有者がカード保有者でもあるというカードについて代理人を確立するメカニズムを有さない。現在、これは問題であると考慮されている。というのも、主に、本発明の実施形態で対処される認証についての懸念が理由である。新たな機能によって代理人が確立され、その代理人についての認証選択肢もまた確立される。代理人許可は、インコントロール技術と同様に代理人につき確立可能であり、金銭的又は時間利用上の制約、地理的制約、又は特定の販売者若しくは特定のトランザクション種別についての使用に関する制約を可能にする。

代理人確立は、ユーザと代理人との両方により十分安全と考えられる方法で実現されるべきである。代理人アイデンティティは、ユーザセッションにて確立される必要がある。１つの可能性は、代理人がセッションにおいて存在し、代理人詳細と代理人認証選択肢とをセッション（このときユーザは処理に対し正当な可視性を有する）にて完成させることである。もし代理人が物理的な支払装置（例えばモバイル装置１）を使用しそれがまた、支払装置許可ソフトウェアとの関連セッションにつき使用されることを意図するなら、これは適切な選択肢である。モバイル装置１は単純に代理人へ手渡され、代理人詳細が入力され、代理人認証選択肢が確立される。これは、代理人にとって個人的なパスワードであってよいし、生体認識（例えば代理人指紋）であってよい。これはまた、代理人認証選択肢に関連付けられた安全なデータがモバイル装置自体を超えて送信される必要がなくその装置の安全領域内に保持されることを意味する。

代理人詳細を確立するための他の選択肢は、ユーザが、代理人についての十分な詳細を提供し、代理人が発行者顧客サーバ１０との自身のセッションを確立することである。これは例えば、異なる通信パスを用いて（例えばeメールアドレス及び携帯電話番号）ユーザが２つの代理人証明書を提供し、代理人認証選択肢が確立される代理人セッション内で２要素相互作用を可能にすることを伴う。このアプローチは、ユーザと代理人と発行者とへ、十分なレベルの安全性を提供する。

代理人による支払装置の使用は、本質的には、ユーザによる使用と同一である。というのも、代理人は同様にトランザクションに参加し、認証を提供するよう求められたときに代理人認証選択肢を提供するからである。販売者と加盟店銀行との観点からは、既存の処理に変更はない。しかし、トランザクション詳細は、発行者銀行と銀行インフラストラクチャとのみに関する方法で修正される。これを行う適切な方法はこの直後に記載される。

支払装置について、利用可能な様々なカード保有者検証方法（CVM）が複数存在してよい。チップ及びピン端末と相互作用する物理的なカードについては、標準CVMはオンラインPIN（個人識別番号）であり、このとき、PIN情報が入力されてカード発行者へ送信される。一方オフラインPINトランザクションについては、発行者とのオンライン通信はなされないが、支払装置自身によるPIN確認がなされる。主な支払装置標準は、EMVCoによる技術によって発展されたものである。これは、https://www.emvco.com/specifications.aspxにて仕様を提供する。実際、生体認識、身振り、及び他の認証アプローチは、支払装置にて、ユーザ認証プロトコルの一部として使用されてよい。しかし、これらは任意の記録されたトランザクション情報において区別されない（これらは、発行者との直接的な通信があるか否かに応じて、典型的には、オンラインPIN、又はオフラインPINとして取り扱われる）。しかし、EMVCoプロトコルのもとで発行者へ提供される、トランザクションからの特定の情報が存在する。これは、発行者アプリケーションデータ（IAD）として知られる。このIADメッセージは、CVM種別を示す、追加の１以上のバイトのデータを伝送するよう拡張される。値は、使用されるCVMの種別だけでなく、PIN（又はその同等物）がユーザ又は代理人に関連するか否かを示すように選択可能である。既存のメッセージサイズを変更しない代替アプローチは、関連フィールド（例えば、実行された認証試行の数を追跡するPIN試行カウンタ（PIN Try Counter））へ負担をかけすぎる。これは、全バイトを要求しない。というのも特に、ほとんどの安全性プロトコルは任意の認証アプローチを要求して、全バイトの認証試行が実行される前に挫折するからである。これは例えば、PIN試行カウンタの低いニブル（値：0...7）が自身の元の機能を保持することによってなされうるが、高いニブル（値：8...F）がCVM種別（指紋、パスコード、PIN、身振り、代理人識別子等）を伝送する。これにより、トランザクション詳細は、販売者と加盟店銀行と銀行インフラストラクチャのほとんどの部分とによって、通常の方法で処理されることができる。他方でCVM種別情報は発行者、銀行インフラストラクチャ又は発行者に代わって動作する他の当事者（いくつかの実施形態では、発行者から独立した銀行インフラストラクチャ）によって使用されることができる。

トランザクション詳細が発行者（具体的には発行者認証モジュール９）へ到達すると、CVM種別情報は、CVMがカード保有者に関連するか代理人に関連するかを判定するために使用されてよい（このこと以上に、CVM情報を記録することには他の利点がある（下記参照））。発行者は次いで、トランザクションがユーザ／カード保有者と発行者とによって代理人について確立された許容動作内にあるか否かを判定する。もしそうなら、トランザクションは（オンライントランザクションについて）適宜承認又は拒否され、（トランザクションがオフライン且つ完了なら）適切にフラグ付けされる。これにより、状況が整うまで関連カード保有者アカウントの使用は防がれる。

図４は、支払管理装置でもある支払装置１を示す。上記のように、支払装置及び支払管理装置は別々であってよいし、それらの両方は携帯モバイル通信ハンドセットでなくてよい。そのような配置は図６に示される。

図６の要素のほとんどが図４に示される。ユーザ１１は発行者顧客サーバ１０と、コンピューティング装置（この場合、パーソナルコンピュータ４１）を介して相互作用する。ユーザ１１は代理人１２によるトランザクションについて許可と代理人についての証明書とを確立する。当該証明書は典型的には、オンラインPINである。

代理人によって使用される支払装置は、多くの異なる種別のオブジェクトの１つであってよい。その共通の機能は、各々がメカニズムとして使用され、ユーザアカウントを用いたトランザクションを開始可能なことである。上記のようにこれは携帯電話であってよく、ウェアラブル装置であってよい。ウェアラブル装置の場合、支払装置は対（ペア）になったウェアラブルなコンピューティング装置（例えば携帯電話）によって提供されてよい。いくつかの実施形態では、この理由は、支払装置が積極的に動作し、トランザクションを開始することができるからである（図４の場合を参照）。他の実施形態では支払装置は、十分なアカウント詳細を含む支払証明書であってよく、端末（従来の支払カードの磁気ストライプのようなもの）がトランザクションを開始することを可能にする。これは下記でトークンとして示される。

この使用モデルは、特に代理人がユーザの世話人である実施形態では、ユーザ／代理人相互作用にとって一層魅力的である。この場合、図４のモデルは適切でないかもしれない。というのも、携帯電話４１は、ユーザに常に保有される必要がある、当該ユーザの必須アイテムであるからである。他のトークン（例えば支払カード１ａ）は、ユーザにとって手から放すのが一層容易かもしれない。この支払カード１ａは従来のクレジットカード若しくはデビットカード又は他のカード種別（例えば店舗カード）であってよい。このとき、追加情報が当該カード又は他の場所に格納され、必要なアカウント詳細へのアクセスを可能にする。それの代替例は、トークン（例えばペン６２）を提供することである。これは（例えばRFIDメカニズムによってアクセスされるメモリを用いて）アカウント情報を有する。これはまた、そのアカウントを用いたトランザクションへのオンランプを可能にするために使用されてよい。支払カード１ａ又は他のトークンは次いで、端末２と相互作用して、適切な方法でトランザクションを確立する。トランザクションは次いで、図４及び５を参照して上記のように進んでよい。

いくつかの実施形態では、トークンはトランザクションの目的に直接関連してよい。示される１つの可能なトークンは車両６１である。ユーザアカウント情報は車両内で、端末を用いて通信可能なようにプログラムされてよい。あるいは車両は、ユーザのアカウントにつき支払装置として動作するようプログラムされてよい。ユーザ１１は、代理人１２が車両６１に燃料を補給する目的でユーザアカウントの使用を許可されたことを確立してよい。この場合、代理人は車両６１を関連ガレージへ単に移動させることができる。そこで通信が車両とガレージ端末との間で確立される。代理人証明書（例えばオンラインPIN）の入力によって、燃料補給トランザクションを実行することが可能である。

上記で詳述された実施形態は主に支払装置に関するが、本実施形態は他の文脈で提供されてよい。アイテムの代理使用は他の実施形態（例えば旅行又はイベントのチケットの使用）で好ましいものであってよい。もしチケット発行者が、他の識別済み当事者への代理を許可すれば、上記のアプローチは、ユーザによる同意とチケット発行者による同意及び制御とのもとで、そのチケットを他の当事者が使用するための代理を可能にするために使用されてよい。本発明の範囲は請求項の趣旨及び範囲で画定されるので、本実施形態によって限定されない。

Claims (15)

1. 支払証明書を用いてトランザクションを実行する方法において、前記支払証明書は、前記トランザクションにおいてユーザを代理するよう構成された装置において実装され、支払証明書のユーザ及び発行者は、代理ユーザにつき使用許可と認証選択肢とを確立し、前記方法は、
   前記代理ユーザが、前記支払証明書を用いて支払ネットワークインフラストラクチャの端末と前記トランザクションを実行するステップであって、前記トランザクションと前記代理ユーザによって使用される前記認証選択肢とは、前記支払ネットワークインフラストラクチャを介して前記発行者へ提供される、ステップを含み、
   前記トランザクションが前記使用許可内であり且つ前記認証選択肢が前記代理ユーザにつき妥当であるとき、前記発行者の発行者認証モジュールは前記トランザクションを許可するよう構成される、方法。
2. 請求項１に記載の方法において、前記支払証明書はコンピューティング装置であり、前記コンピューティング装置は支払証明書として動作するようプログラムされ、管理装置として前記発行者に対し使用許可を確立するよう適合される、方法。
3. 請求項２に記載の方法において、前記コンピューティング装置は携帯無線通信ハンドセットである、方法。
4. 請求項１に記載の方法において、前記支払証明書は任意のコンピューティング装置から分離し、当該任意のコンピューティング装置は管理装置として動作し、前記発行者に対し使用許可を確立する、方法。
5. 請求項１に記載の方法において、前記支払証明書はウェアラブル装置に含まれる、方法。
6. 請求項４に記載の方法において、前記支払証明書は支払カードである、方法。
7. 請求項４又は５の記載の方法において、前記支払証明書は、トランザクションを開始するよう適合されたトランザクション処理システムの端末によって認識される要素である、方法。
8. 請求項１乃至７のいずれか１項に記載の方法において、前記支払証明書はＥＭＶプロトコルを用いてトランザクションを開始するよう適合され、選択された前記認証選択肢は発行者アプリケーションデータにて通信される、方法。
9. 請求項８に記載の方法において、選択された前記認証選択肢は、ＰＩＮ試行カウンタにて通信される、方法。
10. 請求項１乃至９のいずれか１項に記載の方法において、前記発行者はオンラインであり、前記使用許可と前記認証選択肢との両方が前記代理ユーザにつき妥当でないとき、前記トランザクションは実行されない、方法。
11. 請求項１乃至９のいずれか１項に記載の方法において、前記発行者はオフラインであり、前記支払装置での妥当なトランザクションの後、前記トランザクションは完了する、方法。
12. 請求項１乃至１１に記載の方法において、前記認証選択肢は生体識別子を含む、方法。
13. 請求項１乃至１２のいずれか１項に記載の方法での使用に適合された支払証明書。
14. 請求項１３に記載の支払証明書であって、支払管理装置と対になったウェアラブル装置に含まれる、支払証明書。
15. 請求項２又は４に従属する場合の請求項１乃至１４のいずれか１項に記載の方法にて使用するための管理装置として使用するのに適合されたコンピューティング装置。

Images