(57)【要約】装置を操作してトランザクションを完了するシステム、方法及び装置が提供される。これらは、販売者とのトランザクションを開始する要求を受信することと、支払トランザクション開始メッセージを販売者に関連付けられた販売者サーバへ送信することと、遠隔支払データについて販売者サーバから要求メッセージ（これは販売者サーバが第１のデータ形式と代替データ形式とのうち選択された１つを支援するか否かを識別する情報を含む）を受信することと、遠隔支払データを販売者サーバへ、販売者サーバによる使用のために選択されたデータ形式で提供して、トランザクションの承認処理を開始することとを含む。
2018536921.tif 000002
【特許請求の範囲】
【請求項１】
装置を操作してトランザクションを完了する方法において、
販売者とのトランザクションを開始する要求を受信するステップと、
前記販売者と関連付けられた販売者サーバへ支払トランザクション開始メッセージを送信するステップと、
前記販売者サーバから遠隔支払データについての要求メッセージを受信するステップであって、前記要求メッセージは、前記販売者サーバが第１のデータ形式と代替データ形式とのうち選択された１つを支援するか否かを識別する情報を含む、ステップと、
前記販売者サーバによる使用のための前記選択されたデータ形式にて前記遠隔支払データを前記販売者サーバへ提供して、前記トランザクションの承認処理を開始するステップと、
を含む方法。
【請求項２】
請求項１に記載の方法において、前記第１のデータ形式は、完全な承認要求暗号（「ARQC」）の受信を可能にするデータ形式である、方法。
【請求項３】
請求項２に記載の方法において、前記代替データ形式は、前記販売者サーバによって修正済み承認要求暗号（「ARQC」）を前記装置から受信することを可能にするデータ形式である、方法。
【請求項４】
請求項３に記載の方法において、前記修正済みARQCは、データ入力の部分セットを用いて生成される、方法。
【請求項５】
請求項４に記載の方法において、データ入力の前記部分セットは、前記トランザクションに特有の値ではなくデフォルト値に設定される第１のデータフィールドを少なくとも含む、方法。
【請求項６】
請求項１に記載の方法において、前記選択されたデータ形式は代替データ形式であり、前記方法は更に、
前記遠隔支払データと前記代替データ形式とを、前記第１のデータ形式を用いて、承認要求メッセージへ変換するステップを更に含む、方法。
【請求項７】
請求項６に記載の方法において、前記変換は、前記装置が前記遠隔支払データを前記選択されたデータ形式にて前記販売者サーバへ提供した後に、エンティティによって実行される、方法。
【請求項８】
請求項１に記載の方法において、前記装置は、安全要素に格納された第１の支払カードレットを少なくとも有するモバイル装置である、方法。
【請求項９】
請求項８に記載の方法において、前記第１の支払カードレットは、少なくとも(i)アプリケーションPANと(ii)アプリケーションPAN通し番号とがコマンド応答にて返信可能なように、個人向けに設定される、方法。
【請求項１０】
装置において、
販売者と関連付けられた販売者サーバと通信する通信装置と、
トランザクションと関連付けられたデータを受信、格納及び提供するコンピュータストレージユニットと、
前記通信装置及び前記コンピュータストレージユニットと通信するプロセッサであって、
前記プロセッサは、
販売者とのトランザクションを開始する要求を受信するステップと、
前記販売者と関連付けられた前記販売者サーバへ支払トランザクション開始メッセージを送信するステップと、
前記販売者サーバから遠隔支払データについての要求メッセージを受信するステップであって、前記要求メッセージは、前記販売者サーバが第１のデータ形式と代替データ形式とのうち選択された１つを支援するか否かを識別する情報を含む、ステップと、
前記販売者サーバによる使用のための前記選択されたデータ形式にて前記遠隔支払データを前記販売者サーバへ提供して、前記トランザクションの承認処理を開始するステップとを実行するよう構成される、装置。
【請求項１１】
請求項１０に記載の装置において、前記第１のデータ形式は、完全な承認要求暗号（「ARQC」）の受信を可能にするデータ形式である、装置。
【請求項１２】
請求項１１に記載の装置において、前記代替データ形式は、前記販売者サーバによって修正済み承認要求暗号（「ARQC」）を前記装置から受信することを可能にするデータ形式である、装置。
【請求項１３】
請求項１２に記載の装置において、前記修正済みARQCは、データ入力の部分セットを用いて生成される、装置。
【請求項１４】
請求項１３に記載の装置において、データ入力の前記部分セットは、前記トランザクションに特有の値ではなくデフォルト値に設定される第１のデータフィールドを少なくとも含む、装置。
【請求項１５】
請求項１０に記載の装置において、前記選択されたデータ形式は代替データ形式であり、前記プロセッサは更に、
前記遠隔支払データと前記代替データ形式とを、前記第１のデータ形式を用いて、承認要求メッセージへ変換するよう構成される、装置。
【請求項１６】
請求項１５に記載の装置において、前記変換は、前記装置が前記遠隔支払データを前記選択されたデータ形式にて前記販売者サーバへ提供した後に、エンティティによって実行される、装置。
【請求項１７】
請求項１０に記載の装置において、前記装置は、安全要素に格納された第１の支払カードレットを少なくとも有するモバイル装置である、装置。
【請求項１８】
請求項１７に記載の装置において、前記第１の支払カードレットは、少なくとも(i)アプリケーションPANと(ii)アプリケーションPAN通し番号とがコマンド応答にて返信可能なように、個人向けに設定される、装置。
【発明の詳細な説明】
【関連出願の相互参照】
【０００１】
本願は、米国特許出願第14/881,249号（2015年10月13日出願）の優先権を主張するものであり、当該出願の開示全体をここに参照のために取り込む。
【背景技術】
【０００２】
消費者にとって、携帯電話等の装置を用いて購入を行うことはますます一般的である。これらの遠隔購入トランザクション（取引）は、金融機関及び他のエンティティへ課題を与える。例えばこれらのトランザクションは、ユーザの認証と他の詐欺関連事項とに関連する課題を提示する。多くのアプローチが提案され、ユーザ認証を改善し、遠隔トランザクションでの詐欺を低減してきた。例えば１つの好ましいアプローチは、EMV標準（www.emvco.com）によって提供される認証及びセキュリティ機能を遠隔トランザクションで用いることである。しかし、全てのオンライン又は遠隔販売システムがこれらの標準を支援（サポート）するわけではない。詐欺を低減しつつ良好なユーザ体験を提供するには、ブラウザから、モバイル装置上で、又は、アプリケーション内等で、遠隔トランザクションを可能にするシステム及び方法を提供することが好ましい。
【０００３】
本開示のいくつかの実施形態の特徴及び利点、並びに、それらが実現される方法は、本開示や添付図面の詳細（下記）を考慮することで一層容易に明らかになる。本開示や添付図面は、好適且つ例示的な実施形態を示すが、必ずしも正しい縮尺で記載されているわけではない。
【図面の簡単な説明】
【０００４】
【図１】本発明が適用されてよいシステムを示す機能ブロック図である。
【図２】本発明の実施形態において提供される支払対応スマートフォンの例示的実施形態を示す機能ブロック図である。
【図３】本開示の実施形態による、図２のスマートフォンにて提供される機能的ソフトウェアブロックを示す情報フロー図である。
【図４】本開示の実施形態による、図２のスマートフォンにて実行可能な処理を示すフローチャートである。
【発明を実施するための形態】
【０００５】
本開示の実施形態は、トランザクションを完了するためのシステム、方法、装置及び装置を動作させるプログラミングコードを提供する。実施形態がここに開示される。これは、販売者とのトランザクションを開始する要求を受信し、支払トランザクション開始メッセージを販売者に関連付けられた販売者サーバへ送信し、遠隔支払データについて販売者サーバから要求メッセージ（これは販売者サーバが第１のデータ形式と代替データ形式とのうち選択された１つを支援するか否かを識別する情報を含む）を受信し、遠隔支払データを販売者サーバへ、販売者サーバによる使用のために選択されたデータ形式で提供して、トランザクションの承認処理を開始することを含む。
【０００６】
図１は、本発明が適用されてよいシステム１００を示す機能ブロック図である。例示目的で、本発明の機能は支払対応装置１０２の使用の状況で開示される、しかし、当業者は、本発明の機能は、他の装置（例えばタブレット又は他のコンピューティング装置）を伴うトランザクションにおいて所望の結果で使用されてよいことを理解する。開示されるように、システム１００は支払対応モバイル装置１０２を含む。モバイル装置１０２は携帯電話として動作可能であるが、本開示の実施形態で下記にて提供されるように、非接触支払カードの機能を実行可能である。モバイル装置１０２の更なる詳細は、図２及び３に関して後述される。
【０００７】
開示されるように、システム１００は更に、モバイル装置１０２と通信する販売者サーバ１０６を含む。ただ１つのモバイル装置１０２と販売者サーバ１０６とが示されるが、システム１００は両方の装置を多数含むことがある。例えば多くのモバイル装置１０２を操作する多くの消費者は、販売者サーバ１０６を操作する多くの異なる販売者と相互作用（インタラクション）して、本発明にしたがって、トランザクションを支援する。モバイル装置１０２と販売者サーバ１０６との間の相互作用は、例えば、ネットワークインタフェース上での無線相互作用であってよい。例えばモバイル装置１０２は販売者サーバ１０６と相互作用して、携帯電話通信ネットワーク上でプロトコル（例えばHTTP（Hyper  Text  Transfer  Protocol）等）を用いて購入トランザクションを実行してよい。いくつかの実施形態では、モバイル装置１０２と販売者サーバ１０６との間の通信は、モバイル装置１０２にインストールされたモバイルアプリケーション（例えばモバイル装置上の販売者アプリケーション）によって支援され又は制御されてよい。
【０００８】
いくつかの実施形態では、モバイル装置１０２はモバイル装置１０２上のブラウザから又はモバイル装置１０２上のアプリケーションから、販売者サーバ１０６とトランザクションを実行してよい。これは、支払サーバ１０４（これは「ウォレットサーバ」とも称されてよい）と相互作用する。モバイル装置１０２は、ウォレットサーバ上の１以上のウォレットに対応する１以上の支払ウォレットに関連付けられた情報を格納してよい。いくつかの実施形態では、トランザクションは、本書にて「デジタル安全遠隔支払（DSRP）」と称される安全支払プロトコルを用いて処理される。これは、改良版の詐欺防止策（これはいくつかの実施形態では、販売者にとって、詐欺に対する責任を低減することを可能にする）を提供する。開示されるように、実施形態は多くの利益（これは例えば、モバイル装置１０２を用いてトランザクションを実行するユーザにとっての改良版ユーザ体験や、モバイルでの特定の様々なユースケース（例えば通路でのショッピング等）や、（販売者とユーザとの観点からの）潜在的責任移転や、改良版ユーザ認証）を提供する。
【０００９】
いくつかの実施形態によるトランザクション機能が、図１の構成要素を参照して開示される。概して、トランザクションはモバイル装置１０２を操作するユーザによって（例えば商品又は役務を販売者から購入する要求を開始することによって）（例えばモバイル装置１０２のアプリケーション又はブラウザ内から）、販売者との通信中に開始されてよい。販売者に関連付けられた販売者サーバ１０６はモバイル装置１０２と通信し、モバイル装置１０２（図３に示す）の販売者が支払トランザクションを実行することを要求する。当該要求に含まれるものは、販売者サーバ１０６によって支援されるデータ形式の種別を識別する情報である。例えば本開示のように、販売者サーバが「第１のデータ形式」又は「代替データ形式」を支援可能（又は特定のトランザクションを支援するよう構成可能）な実施形態が開示される。いくつかの実施形態では、複数のデータ形式が使用可能である。例えば、「第１のデータ形式」、「第２のデータ形式」及び「第３のデータ形式」を使用するいくつかの実施形態が開示される。本開示のように、「代替データ形式」又は「第２のデータ形式」との用語は、概して、「第１のデータ形式」以外の形式（例えば「第２のデータ形式」、「第３のデータ形式」又は他の変形例）を指す。
【００１０】
特定の例として、第１のデータ形式はEMV標準（これはhttp://www.emvco.comで利用可能であり、そのコンテンツはあらゆる目的で、参照によりその全体がここに取り込まれる）にしたがう完全データ暗号を支援するデータ形式であってよい。もし販売者サーバ１０６が、それが第１のデータ形式を支援することを示せば、いくつかの実施形態によれば、販売者サーバ１０６は、EMV集積回路カード（ICC）システム関連データのデータ要素５５（「DE55」）にて返信されるEMV承認要求暗号（ARQC）を受信可能であり、EMV標準にしたがうARQC生成についての入力の完全セットを用いて生成される。もし販売者サーバ１０６が第１のデータ形式にてメッセージを受信可能なら、暗号は標準EMV承認ホストシステムを用いて確認可能である。
【００１１】
もし販売者サーバ１０６が第１のデータ形式にてメッセージを支援しなければ、それは代替データ形式にてメッセージを支援する。例えばいくつかの実施形態では、異なるデータ形式（例えば「代替データ形式」、「第２のデータ形式」又は「第３のデータ形式」）がトランザクションにつき使用されてよい。このとき、いくつかの計数情報は、承認トランザクションの一部として実行される必要がある。この場合、ARQCは、利用可能な入力の部分セットを用いて生成される。すなわち、いくつかのフィールドは、トランザクションに特有の値ではなく、デフォルト値（既定値）へ設定される。ARQC及び関連EMVデータは圧縮され（例えばデフォルトに基づく静的値は除去され、ビットマップコーディングが使用されてよい）、標準メッセージフィールドに入れられる。暗号を確認するために、UCAF（又は他の標準メッセージフィールド）内の値は、当該デフォルトと当該静的値とを追加することによって、第１のデータ形式（例えばDE55形式）へ変換して戻される必要がある。これは、トランザクションを承認する発行者によって又は代理処理エンティティによって、前処理として実行されてよい。変換された値は次いで標準承認ホストシステム（例えば発行者又は代理エンティティ等）によって確認されてよい。
【００１２】
いくつかの実施形態では、もし販売者サーバ１０６が第１のデータ形式にてメッセージを支援しなければ、それは異なるデータ形式（例えば「代替データ形式」、「第２のデータ形式」又は「第２のデータ形式」）でメッセージを支援してよい。例えば代替データ形式は、ユーザ承諾及びユーザ認証についての追加情報を承認システムに含むことを要求し又はそのことから利益を受けるトランザクションにおいて使用されてよい。
【００１３】
このように、実施形態は、トランザクションが、モバイル装置１０２と異なる販売者サーバ１０６（これは完全EMV形式メッセージを受信不可能な又は当該メッセージを受信するよう構成されていない販売者サーバ１０６を含む）との間で実行されることを可能にする。結果として、通常の支払トランザクションのみを処理可能な又はそれのみを処理するよう構成される販売者サーバ１０６は、遠隔支払トランザクションにおいて、EMVで改良された詐欺対策の利益を享受することができる。
【００１４】
販売者サーバ１０６からの応答の種類（それが第１のデータ形式又は代替データ形式を支援するかについて）によっては、モバイル装置１０２は、販売者サーバ１０６への送信のための遠隔支払データを生成してトランザクションを処理する。遠隔支払データの生成についての詳細は、図３に関連して下記に開示される。概して、遠隔支払データ形式は、販売者サーバ１０６が第１のデータ形式又は代替データ形式を支援するか否かに依存する。販売者サーバ１０６は遠隔支払データを、アクワイアラ１１０への送信のために承認応答（これは支払ゲートウェイ１０８を介して送信されてよい）に含める。承認要求、応答及び清算は次いで、販売者サーバ１０６（及び／又は関連する場合は支払ゲートウェイ１０８）と、支払サーバ１０４と、トランザクションにおいて使用される支払手段の発行者との間で処理される。いくつかの実施形態では、これらのエンティティの間での処理は、販売者サーバ１０６が第１のデータ形式又は代替データ形式を支援するか否かによって異なってよい。
【００１５】
例えばもし販売者サーバ１０６が第１のデータ形式を支援するとき、モバイル装置１０２から受信された遠隔支払データは、遠隔支払メッセージのデータ要素55内の標準EMV  ARQCに含まれる。システムは標準EMV処理を用いてトランザクションを処理し、ARQCを確認する。しかし、もし販売者サーバ１０６が第１のデータ形式を支援しなかった（又は支援するよう構成されなかった）とき、遠隔支払メッセージは代替データ形式にて受信され、ARQCは利用可能な入力の部分セットから生成される。ARQC及び関連EMVデータは圧縮され（例えばデフォルトに基づく静的値が除去され、ビットマップコーディングが使用可能）、標準支払トランザクションメッセージフィールド（例えば「UCAFフィールド」等）にて販売者サーバ１０６によって受信される。このような実施形態では、システムは受信されたデータから、DE55フィールドを再確立又は再構築する。この再確立は、その通常のマッピング処理を実行する前に実行される。再確立は次の処理を含んでよい。（１）タグの長さを、UCAFフィールドから受信されたデータに追加すること、（２）デフォルトデータを、再構築されたDE55フィールドへ追加すること、（３）支払アカウント番号（「PAN」）を支払トランザクションメッセージから（例えばそれを標準トランザクションメッセージフィールド（例えばDE2）から検索することによって）抽出し、それを、フィールド「5A」（EMV「アプリケーション主要アカウント番号（PAN）」フィールド）内及びフィールド「5F34」（EMV「アプリケーション主要アカウント番号（PAN）通し番号」フィールド）内の再構築されたDE55フィールドへ追加すること。このように、標準EMVメッセージを処理しない（又は処理するよう構成されない）販売者サーバ１０６は、そのようなメッセージを処理するよう適合されてよい。
【００１６】
アクワイアラ（加盟店金融機関）によって操作されるコンピュータ１１０は、図１のシステム１００の一部として示される。アクワイアラのコンピュータ１１０は、従来の方法で動作して、販売者サーバ１０６からトランザクションについての承認要求を受信する。アクワイアラのコンピュータ１１０は、承認要求を、支払ネットワーク（不図示）を介してサーバコンピュータ又は支払カードの発行者によって操作される他のシステム又は当該発行者に代わって操作される他のシステムへルーティングすることができる。当該支払アカウントは、モバイル装置１０２によってアクセス可能であり、現在の支払トランザクションにおいて使用されるために選択されたものである。従来の方法では、支払カード発行者によって生成される承認応答は、支払ネットワークを介して販売者サーバ１０６及びアクワイアラコンピュータ１１０へルーティングで戻されてよい。
【００１７】
支払ネットワークは、全体的に又は実質的に従来的である。適切な支払ネットワークの一例は、MasterCard  International  Incorporated（本願の譲受人）によって操作される周知のBanknetシステムである。
【００１８】
トランザクションで使用される支払カードの発行者によって操作され又は当該発行者に代わって操作されるシステム又はコンピュータは従来的であってよく、個別のユーザへ支払カードアカウントを発行する金融機関によって又は当該金融機関（「FI」：別途図示されず）に代わって操作されてよい。例えば支払カードイシュアによって操作され又は当該イシュアに代わって操作されるシステム又はコンピュータは、従来の機能（（ａ）ＦＩによって発行された支払カードアカウントへ請求される、支払カードアカウントのトランザクションにつき、承認要求を受信しそれに応答すること、及び、（ｂ）トランザクションを追跡及び格納してアカウント記録を維持する等）を実行してよい。
【００１９】
図１に示すシステム１００の構成要素は、単一のトランザクションを処理するために必要なものだけを示す。システム１００の典型的な実施形態は、多くの購入トランザクション（同時トランザクションを含む）を処理可能であり、支払カード発行者及びそれらのコンピュータの多くの数を含んでよく、また、アクワイアラ及びそのコンピュータの多くの数や、多くの販売者、販売者サーバ及び関連構成要素を含んでよい。システムはまた、非常に多い数の支払カードアカウント保有者を含んでよい。彼らは、支払対応モバイル装置１０２及び／又は支払カード（これは非接触支払カード及び／又は磁気ストライプカードを含む）を携帯する。
【００２０】
モバイル装置１０２は、（音声及びデータの両方での）通信用の従来の携帯電話として、銃らのモバイル電話通信ネットワーク（不図示）上で動作可能である。したがって、モバイル装置１０２は時として、従来の方法で、モバイルネットワークオペレータ（「MNO」（不図示））と通信可能である。モバイル装置１０２と支払カード発行者サーバコンピュータ（又は関連コンピュータ、図１に不図示）との間の無線（OTA）通信チャネル（図１で不図示）は、時として、モバイル装置１０２に関して個人用又は設定等の目的で確立されてよい。
【００２１】
図２は、図１に示す支払対応モバイル装置１０２の例示的実施形態を示す、本発明の実施形態によるブロック図である。モバイル装置１０２はハードウェア態様においては従来的であってよい。例えばモバイル装置１０２は、ハードウェア態様及び機能面のほとんどにおいて、Apple  Inc.によって販売される従来の「iPhone」に類似してよいし、「アンドロイド」のオペレーティングシステムを駆動する多くのスマートフォンの１つに類似してよい。
【００２２】
モバイル装置１０２はモバイル装置１０２の他の構成要素を含み及び／又は支援する従来の筐体（ハウジング）（図２の破線２０２により示される）を含んでよい。筐体２０２はユーザの手で保持されるように形成され寸法調整されてよいし、例えば、モバイル装置の現在の作成において共通な、形態要素の種別を提示してよい。
【００２３】
モバイル装置１０２は更に制御回路２０４を含み、モバイル装置１０２の全体動作を制御する。例えば制御回路２０４はモバイル装置の「脳」として設計される種別の従来型プロセッサを含んでよい。
【００２４】
モバイル装置１０２の他の構成要素（これは制御回路２０４と通信し及び／又は制御回路２０４によって制御される）は次のものを含んでよい。（ａ）１以上のメモリ装置２０６（例えばプログラム及びワークメモリ等）、（ｂ）従来のSIM（加入者識別モジュール）カード２０８、（ｃ）モバイル装置１０２用の主要入出力装置として機能し、したがって、ユーザから入力情報を受信し、ユーザへ出力情報を提示する従来型タッチスクリーン２１２。モバイル装置の多くの型に当てはまるが、いくつかの実施形態では、モバイル装置１０２はまた、多少の物理動作スイッチ／制御装置（不図示）（例えばオン／オフ／リセットスイッチ、メニューボタン、「戻る」ボタン、音量制御スイッチ等）を含んでよい。スマートフォンが従来のデジタルカメラ（不図示）を含んでよい。
【００２５】
モバイル装置１０２はまた、従来型送受信回路２１６を含む。これはまた、制御回路２０４と通信し及び／又は制御回路２０４によって制御される。送受信回路２１６は、アンテナ２１８へ接続され通信チャネルを提供する。当該通信チャネルによって、モバイル装置１０２はモバイル電話通信ネットワーク（不図示）を介して通信する。送受信回路２１６は、データ通信機能を実行することに加え、音声信号を送受信するよう動作してよい。
【００２６】
モバイル装置１０２は更に、従来のマイクロフォン２２０を含んでよく、これは送受信回路２１６に接続される。もちろん、マイクロフォン２２０はユーザからの音声入力を受信する。更に拡声器２２２は、ユーザへ音声出力を提供するために含まれてよいし、送受信回路２１６へ接続されてよい。
【００２７】
送受信回路２１６は従来の方法で動作して、アンテナ２１８を介して、マイクロフォン２２０によって生成された音声信号を送信してよいし、拡声器２２２を介して、アンテナ２１８を介して受信された音声信号を複製してよい。送受信回路２１６はまた、テキストメッセージの送受信及び他のデータ通信を、アンテナ２１８を介して処理してよい。
【００２８】
モバイル装置１０２はまた回路２２４を含んでよい。これは、部分的又は全体的に、モバイル装置１０２のNFC通信回路機能を実装するための専用のものである。モバイル装置１０２は更に、ループアンテナ２２６を含んでよく、これはNFC回路２２４に接続される。いくつかの実施形態では、NFC回路２２４はモバイル装置１０２のための制御回路２０４と部分的に重複してよい。更に支払回路は、安全要素２２８に関連付けられ及び安全要素２２８と重複してよい。当該安全要素２２８はモバイル装置１０２の一部であり、筐体２０２に含まれる。あるいはNFC回路２２４は、NFCを利用しない実施形態において省略されてよい。「安全要素」との用語は当業者にとって周知であり、典型的には、小さいプロセッサと揮発性及び不揮発性メモリ（別途示さず）とを含んでよい装置を指す。当該プロセッサと当該メモリとは、適切な手段によって、改ざん及び／又は再プログラミングから保護される。
【００２９】
安全要素２２８に関連し、特にそのプログラミングに関連する更なる詳細が図３及び４を参照して後述される。いくつかの実施形態では、安全要素２２８はSIMカード２０８の一部として提供されてよい。他の実施形態では、安全要素２２８は、SIMカード２０８とは別だがSIMカード２０８と同一の形態要素を有することがある集積回路によって構成されてよい。モバイル装置１０２のいくつかの実施形態では、安全要素２２８はそのハードウェア態様においては従来的であってよいが、しかし、下記の方法で本発明の態様に応じてプログラムされてよい。いくつかの実施形態では、「安全要素」との用語は、ICを基礎にした装置に限定されないが、しかし、モバイル装置内の任意の安全実行環境を含んでよいし、主要モバイル装置プロセッサ上で駆動する、ソフトウェアを基礎にした安全実行環境を含んでよい。
【００３０】
図３は、本開示の実施形態による、モバイル装置１０２にて提供される機能的ソフトウェアブロックを示す情報フロー図である。図３の破線ブロック３０２は、ブロック３０２内に示されるソフトウェア及びハードウェア構成要素がモバイル装置１０２の機能であるという意味で、スマートフォン１０２の筐体２０２を概略的に示す。ブロック３０４は、上記の図２で示される安全要素２２８を示し、適宜付番される。
【００３１】
本実施形態によれば、安全要素２２８は複数のモバイル支払カードレット（支払カードアプリケーション）３０６を格納する。図３には単一のモバイル支払カードレット３０６が示される。しかし、安全要素２２８／スマートフォン１０２内に実在する符号は、それより多くてよい。従来通り、モバイル支払カードレット３０６は、ユーザに属するそれぞれの支払カードアカウントを示し、それが示す支払カードアカウントについての対応支払カードアカウント番号を格納して又はそれへのアクセスを有してよい。多くの方法で、モバイル支払カードレット３０６は、支払トランザクションを完了する際に従来の方法で動作してよい。しかし本書記載の通り、トランザクションを完了する際に使用されるための販売者サーバ３１６へ支払データが提供される方法は、販売者サーバ３１６が支援するデータ形式に応じて、異なる。
【００３２】
図３に示すように、安全要素３０４はまた、支払カードレット３０４のそれぞれとの相互作用を支援し、また、支払カードレット３０４のそれぞれからのデータ検索を支援する１以上のクライアントアプレット３０８を格納してよい。モバイル装置３０２はまた、１以上の販売者アプレット３１０と、支払アプレット３１２とを格納する。各販売者アプレット３１０は例えば機能性を提供し、販売者サーバ３１６との相互作用を可能にしてよい。販売者アプレット３１０は（１以上の販売者サーバ３１６を有する）特定の販売者との相互作用のために構成されてよいし、複数の販売者との相互作用を可能にするよう構成されてよい。例えば販売者アプレット３１０はモバイル装置１０２上で動作する販売者アプリケーションの一部であってよいし、又は販売者アプリケーションと関連付けられてよい。支払アプレット３１２はウォレットサーバ（例えば支払サーバ３１４）との通信を支援してよい。例えば支払アプレット３１２は、MasterPassウォレットサーバ（これは、MasterCard  International  Incorporated（本願の譲受人）によってまたはそれに代わって操作される）との相互作用を可能にするアプリケーションであってよい。アプレット３０６、３０８、３１０及び３１２のそれぞれは、本発明の支払トランザクション中に相互作用し、販売者サーバ３１６によって支援される形式にて遠隔支払データを提供し、販売者サーバ３１６によって支援される方法でトランザクションが安全に実行されることを可能にする。遠隔支払データの提供処理が図４を参照して開示される。支払カードレット３０４、アプレット３０８、３１０及び３１２は、ソフトウェアアプリケーション又はアプレットであり、したがって、ソフトウェアエンティティとして参照されてよいことを理解されたい。いくつかの実施形態では、カードレット及びアプレットは、JavaCard仕様（例えばhttp://globalplatform.orgにて利用可能であり、その全体内容はあらゆる目的で参照によってここに取り込まれる）にしたがって作成されてよい。
【００３３】
いくつかの実施形態では、カードレットは、追加データが販売者トランザクションへの応答において返されてよいように、個人向けに設定されてよい。例えば申請PAN及び申請PAN通し番号は、それらがコマンド応答メッセージにて返されてよいように、個人向けに設定されてよい。
【００３４】
図４は、本開示の実施形態による、モバイル装置１０２にて実行可能な処理を示すフローチャートである。図４の処理は、図４のブロック４０２によって示される誘起（トリガ）イベントによって開始される。例えば、モバイル装置１０２のユーザがモバイル装置１０２と相互作用して支払トランザクションを開始するとき、誘起イベントが生じてよい。例えばユーザは、モバイル装置１０２上の販売者アプリケーションと相互作用することによって、支払トランザクションを開始してよく、１以上の商品又は役務を選択して、購入及びトランザクション開始要求を行ってよい。他の実施形態では、ユーザは、モバイル装置１０２上のウェブブラウザと相互作用することによって、支払トランザクションを開始してよく、１以上の商品又は役務を選択して、購入及びトランザクション開始要求を行ってよい。トランザクションは他の多くの方法においても開始されてよい。
【００３５】
一旦トランザクションが開始されると、処理は４０へ続く。このときモバイル装置１０２（例えば販売者アプレット３１０、支払アプレット３１２及び／又はクライアントアプレット３０８）は、支払トランザクション開始要求を、トランザクションが実行される販売者と関連付けられた販売者サーバ１０６へ送信する。支払トランザクション開始要求は、モバイル装置１０２と販売者サーバ１０６との間のネットワーク接続上で送信されてよい。
【００３６】
処理は４０６へ続く。このときモバイル装置１０２は、販売者サーバ１０６によって支援されるデータ形式を識別する情報を受信する。例えば販売者サーバ１０６はモバイル装置１０２へ、販売者サーバ１０６がトランザクション用の第１のデータ形式又は代替データ形式を支援するか否かを示す。いくつかの実施形態では、販売者サーバ１０６は完全EMV様式トランザクション（例えば本開示のように、モバイル装置が完全EMV形式にて暗号を販売者サーバ１０６へ送信する際の「第１のデータ形式」）を支援してよい。いくつかの実施形態では、販売者サーバ１０６は完全EMV様式トランザクション（例えば本書のように、モバイル装置が、入力の部分セットを用いてエンティティが暗号を生成することを可能にするための情報を提供する際の「代替データ形式」であり、メッセージは完全EMV形式では提供されない）を支援しなくてよい。いくつかの実施形態では、代替データ形式はまた、カード保有者検証結果を提供するために使用されてよい。例えば表２に示すように、代替「形式１」は、カード保有者検証結果データを、スクリプト又はPIN計数機を用いて算出される「カード検証結果」として名称付けされるデータオブジェクトにて提供する。
【００３７】
モバイル装置１０２が一旦、どのデータ形式が販売者サーバ１０６によって支援されるかを示す情報を受信すると、処理は４０８へ継続する。このときモバイル装置１０２は、遠隔支払データを、支援されたデータ形式にて販売者サーバ１０６へ提供するよう動作する。
【００３８】
販売者サーバ１０６が第１のデータ形式を支援するとき、モバイル装置１０２のソフトウェアは操作され、暗号（例えばEMV認証要求暗号（「ARQC」））を用いて、（EMV仕様にて特定される）データ要素５５内の完全EMVデータ形式にて、遠隔支払データを販売者サーバ１０６へ提供する。暗号は次いで、販売者サーバ１０６（及び／又は支払ゲートウェイ１０８、アクワイアラ１１０又は発行者システム）によって使用されて、標準EMV認証ホストシステムを用いて確認されてよい。
【００３９】
もし販売者サーバ１０６が第１のデータ形式を支援しなければ（及び、代わりに、代替データ形式を支援すれば）、選択された支払カードレット３０６からの入力データの部分セットを用いて暗号が生成される。具体的な例示目的で、下記の表は、販売者サーバが第１のデータ形式又は代替データ形式を支援するか否かによって、支払カードレット３０６が遠隔支払暗号への入力として提供するデータを示す。
【００４０】
【表１】
2018536921.tif 000003
【００４１】
【表２】
2018536921.tif 000004
【００４２】
表１に示すように、販売者サーバ１０６が第２のデータ形式を支援するとき、遠隔支払暗号を生成するために使用されるいくつかのデータはゼロへデフォルト設定される。一方、第１のデータ形式のための遠隔支払暗号を生成するために使用されるデータは、入力データから（例えばカードレット又は支払アプレットから）値を取ってよいし、安全要素において個人向けに設定された値を使用してよい。
【００４３】
表２及び下記表４に示すように、多くの異なる代替データ形式が提供されてよい。例えば「代替形式０」は、安全要素を有するモバイル装置が関わるトランザクション又はMCBPトランザクション用に使用されてよい。「代替形式１」は、安全要素を有するモバイル装置に関わるトランザクション用に使用されてよい。ここでは、計数情報が、承認トランザクションの一部として伝送される必要がある。「代替形式２」は、MCBPトランザクションに関わるトランザクション用に使用されてよい。MCBPトランザクションは、また、発行者又は支払ネットワークに対するユーザ承諾又はユーザ認証（「CDCVM」データを指す）についての情報から利益を受け又は当該情報を要求する。
【００４４】
いくつかの実施形態では、販売者サーバ１０６が第１のデータ形式にてデータを支援するとき、遠隔支払データはISO「形式２」応答において販売者サーバ１０６へ返信される。当該応答メッセージにて返信されたデータオブジェクトは、「ABC」と等しいタグを有する構築済みデータオブジェクトである。当該値フィールドはいくつかのBasic  Encoding  Rulesのタグ、長さ、及び値（「BER-TLV」）でコードされたデータオブジェクトを含む。例えば、第１のデータ要素トランザクションについて、トランザクションへの入力の「ABC」部分のコンテンツは、下記表２に示される。
【００４５】
【表３】
2018536921.tif 000005
【００４６】
いくつかの実施形態では、販売者サーバ１０６が代替データ形式にてデータを支援するとき、遠隔支払データはISO「形式１」応答の同等物において販売者サーバ１０６へ返信される。当該応答メッセージにて返信されたデータオブジェクトは、「DEF」と等しいタグを有する原始的なデータオブジェクトである。下記表３に示すように、値フィールドは、データオブジェクトの値フィールドの区切り記号（タグ及び長さ）を有さない連鎖を有する。いくつかの実施形態では、表３のアプリケーション暗号フィールドは、１以上の暗号を格納するために使用されてよい。例えばいくつかの実施形態では、１つの暗号を要求する安全要素に関連付けられた実施形態は、１又は２の暗号を使用する実施形態（例えばクラウドを基礎とした支払いシステムのような、安全要素を有さない実施形態）と同様に支援されてよい。
【００４７】
【表４】
2018536921.tif 000006
【００４８】
いくつかの実施形態では、販売者サーバ１０６が代替データ形式を支援するとき、ARQCは、利用可能な入力の部分セットを用いて生成されてよい（上記表１に示す）。ARQC及び関連EMVデータは圧縮され、標準ISO支払承認要求メッセージのフィールド（例えばUCAFフィールド）内に含まれる。データは処理のために販売者サーバ１０６へ提供される。いくつかの実施形態では、販売者サーバ１０６は、支払ネットワークへの送信のために、承認要求を下記のように生成する。承認要求は「８１」（これは「チップ包含電子商取引」のエントリモードを示す）へ設定された「サービス点エントリモード」（DE22SFI）と共に提出される。電子商取引指示子は次の（１）又は（２）へ設定される：（１）サブフィールド１（電子商取引安全レベル指示子及びUCAF収集指示子）は、次の（ｉ）〜（ｉｉｉ）の値と共に「２１２」との値へ設定される。（ｉ）「２」（「チャネル」）へ設定された位置１（安全プロトコル）、（ｉｉ）「１」（カード保有者証明書不使用）へ設定された位置２（カード保有者認証）、（ｉｉｉ）「２」（UCAFデータ収集は販売者によって支援され、UCAFデータは存在する必要がある）へ設定された位置３（UCAF収集指示子）、及び（２）暗号はDE48SE43フィールド（UCAFフィールドとしても既知）内に含まれる。
【００４９】
代替データ形式トランザクションの処理の説明を続けると、遠隔支払データがモバイル装置１０２のカードレット及びアプレットによって一旦生成されると、データは、販売者サーバ１０６への送信のために、販売者アプレット３１０へ送信される。販売者サーバ１０６は（場合によっては販売者支払ゲートウェイを介して）、アクワイアラ１１０への送信のために、遠隔支払データを承認要求へ包含する。承認要求、応答及び清算は、販売者サーバ１０６（又はゲートウェイ１０８）、支払サーバ１０４及び発行者の間で処理される。これらのトランザクションは支払サーバによってマッピングされる。代替データ形式トランザクションについては、支払サーバ（又は他の遠隔支払データ）は、代替データ形式メッセージを、第１のデータ形式メッセージへ再確立する。再確立は、タグの長さを、UCAFフィールドにて受信データへ追加することと、（表１の）デフォルト設定されたデータを追加して第１のデータ形式メッセージを再作成することと、PANをメッセージから抽出することと、それを第１のデータ形式へ（表２の「5A」及び「5F34」として）追加することとを含んでよい。このように代替データ形式のみを支援する販売者は、第１のデータ形式を用いて実行されるトランザクションの利益を享受することができる。
【００５０】
本発明の態様は、モバイル装置（例えば携帯電話）の文脈で上記される。しかし、本発明の趣旨は、他の種別の装置（これは、タブレットコンピュータ又は他のコンピューティング装置を含む）にも等しく提供可能である。
【００５１】
本開示及び添付の特許請求の範囲で使用されるように、「コンピュータ」との用語は、単一のコンピュータ又は互いに通信する２以上のコンピュータを含むことを理解されたい。
【００５２】
本開示及び添付の特許請求の範囲で使用されるように、「プロセッサ」との用語は、単一のプロセッサ又は互いに通信する２以上のプロセッサを含むことを理解されたい。
【００５３】
本開示及び添付の特許請求の範囲で使用されるように、「メモリ」との用語は、単一のメモリ若しくはストレージ装置、又は、２以上のメモリ若しくはストレージ装置を含むことを理解されたい。
【００５４】
本開示のフローチャート及びその記載は、そこに記載された方法ステップを固定的な順番で実行するものと理解してはならない。むしろ方法のステップは、実行可能な任意の順番で実行可能である。
【００５５】
本開示及び添付の特許請求の範囲で使用されるように、「支払カードアカウント」又は「支払装置」との用語は、クレジットカードアカウント又は、アカウント保有者がデビットカードを用いてアクセス可能な銀行口座を含む。「支払カードアカウント番号」との用語は、支払カードシステムアカウントを識別する番号、支払カードによって通信される番号、又は、デビットカード及び／又はクレジットカードのトランザクションを処理する支払システムにおいてトランザクションをルーティングするために使用される番号、を含む。「支払カード」との用語はクレジットカード、デビットカード、又は他の支払装置を含む。
【００５６】
本開示及び添付の特許請求の範囲で使用されるように、「支払カードシステム」との用語は、購入トランザクション及び関連トランザクションを処理するシステムを示す。そのようなシステムの例には、MasterCard  International  Incorporated（本願の譲受人）によって操作されるものがある。いくつかの実施形態では、「支払カードシステム」は、会員金融機関が支払カードアカウントを個人、法人及び／又は他の組織へ発行するシステムに限定されてよい。
【００５７】
本発明は、特定の例示的実施形態に関連して記載される。しかし、添付の特許請求の範囲で規定される発明の趣旨及び範囲から逸脱すること無く、当業者にとって自明な様々な変更、置換及び／又は改変が開示された実施形態に対しなされてよいことを理解されたい。
【図１】
2018536921.tif 000007
【図２】
2018536921.tif 000008
【図３】
2018536921.tif 000009
【図４】
2018536921.tif 000010
【国際調査報告】
2018536921.tif 000011
2018536921.tif 000012