JP6904636B2 - セキュアな取引処理のための方法、コンピュータプログラム及びシステム - Google Patents

Description

背景

本発明は、セキュアな取引処理を提供するための方法、装置、及びシステムに関する。

クレジットカード又はデビットカードなどのペイメントカード、或いは、電子決済のための手段が提供される電話、腕時計などのモバイル通信デバイスなどの代替の支払デバイス（以下、総称的にペイメントカードと呼ぶ）を使用する、クレジット、デビット、及び他の支払口座を使用して実行される取引は、Ｐａｙｍｅｎｔ Ｃａｒｄ Ｉｎｄｕｓｔｒｙ（ＰＣＩ）セキュリティ標準協議会（Ｓｅｃｕｒｉｔｙ Ｓｔａｎｄａｒｄｓ Ｃｏｕｎｃｉｌ）によって制定された標準に従った規制を受ける。

ＰＣＩセキュリティ標準協議会はＰＣＩデータセキュリティ標準（ＰＣＩ−ＤＳＳ）を発行し、この標準は、セキュリティ上のインシデントに対する予防、検出、及び適切な反応を含む、ペイメントカードのデータセキュリティプロセスのための枠組みを提供する。https://www.pcisecuritystandards.org/document_library?document=pci_dssを参照のこと。

これらの標準を満たすようにシステムを維持することは、面倒な仕事である。この結果として小売団体は、通常、マーチャントのフロントエンドシステム及びバックエンドシステム（以下、総称的にマーチャントシステムと呼ぶ）とは別の、支払端末を使用する。マーチャントフロントエンドシステムの一例が、マーチャント販売時点情報管理（ＰＯＳ）端末（例えば、電子キャッシュレジスタ（ＥＣＲ））である。マーチャントバックエンドシステムの例は、在庫システム及び会計システムを含むことができる。ＥＣＲなどのマーチャントシステムは、カード取引で使用されるペイメントカード番号（カード会員番号、又はＰＡＮ）の記憶又は処理をしないため、マーチャントシステムはＰＣＩ−ＤＳＳの範囲外である。専用の支払端末を使用して、ペイメントカード取引のためにＰＡＮを受信及び処理し、ＰＣＩ−ＤＳＳに従って支払サービスプロバイダ（ＰＳＰ）取得者システムとセキュアな方法で通信する。その後、ＰＳＰシステムは、ＰＣＩ−ＤＳＳに従ってセキュアチャネルを使用するカードスキーム（例えば、ＭａｓｔｅｒＣａｒｄ、ＶＩＳＡなど）システムと統合される。

いくつかの実施において、マーチャントシステムは支払端末から完全に分離しており、その場合、支払端末とマーチャントシステムとの間で電子データが交わされることはない。典型的には、こうした実施において、マーチャントは、カード支払いを実行するために支払明細（例えば、取引金額）を支払端末に手動で入力する。

他の実施において、統合の度合が提供され、その度合によって、取引金額などのなんらかの取引明細をマーチャントシステムから支払端末に渡すことが可能である、及び／又は、支払端末が選択された情報をマーチャントシステムのみに通信するように構成される。例えば、支払端末からマーチャントシステムに渡される選択された情報は、取引のための承認コード、及び、カードを使用する支払の承認を確認するためのＰＡＮの切り捨て部分（すなわち、末尾４桁）を含むことができる。しかしながらこうした構成では、マーチャントシステムがＰＣＩ−ＤＳＳを満たすように構成される必要がないため、マーチャントシステムには完全なＰＡＮは渡されない。

例えば、１つ又は複数の専門的な、特有の、又は選択されたサービスを提供するサービスプロバイダ（以下、こうしたサービスプロバイダを、支払承認チャネルの一部を形成する支払サービスプロバイダ（ＰＳＰ）と区別するために、「特別サービスプロバイダ」又は「ＳＳＰ」と呼ぶ）のシステム、例えば、一般売上税（ＧＳＴ）又は付加価値税（ＶＡＴ）の還付のための税金還付サービスを提供するための税金還付オペレータ（ＴＲＯ）システム、動的通貨選択サービスプロバイダなどの、第三者によって付加的又は専門的なサービスが提供される場合、マーチャントシステムはＳＳＰシステムと通信するように構成可能である。こうした構成において、マーチャントシステムは、例えば、マーチャントシステムが入手可能な、取引の金額、普通未払い税、商品の説明、税金還付を受け取るためにペイメントカード保有者の資格に関して販売時点に決定される情報などの、取引に関する情報を提供することができる。しかしながら、マーチャントシステムは支払のためのＰＡＮを使用できないため、ＰＡＮをＳＳＰシステムに渡すことはできない。したがって、ＳＳＰシステムなどの第三者システムは、ＰＡＮの使用が必要な可能性のあるサービスを提供することができない。

したがって、ＰＡＮを必要とする可能性があるが、これをマーチャントシステムが使用できない場合、支払取引に関連付けられた第三者サービスをどのように提供するかという技術的な問題が存在する。

概要

本発明の態様は、特許請求の範囲に定義される。

請求する主題の実施形態は、マーチャントシステムがＰＡＮを保持しないＰＣＩ−ＤＳＳに準拠した様式でＰＡＮの取り扱いを可能にする一方で、取引のためのＰＡＮの知識を必要とするＳＳＰシステムによって第三者サービスが提供されることを可能にする。上記に示すように、ＳＳＰシステムは、支払承認チャネルに関して帯域外の、１つ又は複数の専門的な、特有の、又は選択されたサービスを提供するサービスプロバイダのシステムである。ＳＳＰシステムは、例えば、税金還付サービス（本明細書では、免税サービス（ＴＦＳ）とも呼ぶ）を提供するための１つ又は複数のＴＲＯホストシステムを含むことができる。

例えば、ＥＣＲによってＰＡＮをキャプチャする必要がなく、以てＥＣＲをＰＣＩ−ＤＳＳの範囲外で維持する、マーチャントシステム（例えば、ＥＣＲ）の動作に、ＴＦＳを組み込んでもよい。支払の際、専用のスタンドアロン型又は半統合端末を使用してＰＡＮをキャプチャすることができる。ＰＡＮは、ＥＣＲ及び他のマーチャントシステムを介してルーティングされない。

一例では、支払端末によってキャプチャされたＰＡＮを含む支払取引情報を支払端末がＰＳＰシステム（支払承認チャネル内の支払サービスプロバイダシステム）にルーティングし、その後、ＰＡＮを含む関連情報を承認のためにカードスキームシステムにルーティングすることに応答して、ＰＳＰシステムは、ＰＡＮにマッピングする固有参照（ＰＲＥＦ）を支払端末に戻す。

一例において、ＰＲＥＦはＰＳＰシステムによって生成され、この場合、ＰＲＥＦは取引又はＰＡＮ及びＰＳＰに固有であり得る。その後ＰＲＥＦは、ＰＳＰシステムによって保持される情報を使用して取引のためのＰＡＮにマッピングされ、ＰＣＩ−ＤＳＳに準拠した様式で保持される。代替としてＰＲＥＦは、支払取引自体とは無関係に、ＰＡＮに固有であるように生成可能であり、この場合、ＰＲＥＦはその後、ＰＣＩ−ＤＳＳに準拠した様式でＰＳＰシステムによって保持される情報を使用してＰＡＮに直接マッピングされる。

別の例において、ＰＲＥＦはカードスキームシステムによって生成され、この場合、ＰＲＥＦは取引及びカードスキームシステムに固有であり得る。その後ＰＲＥＦは、カードスキームシステムによって保持される情報を使用して取引のためのＰＡＮにマッピングされ、ＰＣＩ−ＤＳＳに準拠した様式で保持される。代替としてＰＲＥＦは、支払取引自体とは無関係に、ＰＡＮに固有であるように生成可能であり、この場合、ＰＲＥＦはその後、ＰＣＩ−ＤＳＳに準拠した様式でカードスキームシステムによって保持される情報を使用してＰＡＮに直接マッピングされる。

したがって、ＰＲＥＦがマーチャントシステムに提供される例において、その後、マーチャントシステムは、ＰＲＥＦからＰＡＮへのマッピングを取得するために、必要に応じて、ＰＳＰシステム及び／又はカードスキームシステムと通信することが承認された第三者システムによって使用可能なＰＲＥＦを保持し、承認された第三者システムに渡すことが可能である。

半統合システムにおいて、支払端末は、関係しているペイメントカードを使用する支払を承認する従来の情報と共に、ＰＲＥＦ（但し、全ＰＡＮではない）をマーチャントシステムに転送するように構成可能である。

支払端末がマーチャントシステムに関係していないスタンドアロン型システムにおいて、支払端末は、ＰＲＥＦ及び／又はＰＲＥＦを表すバーコード、ＱＲコード（登録商標）などを、支払伝票上に印刷するように構成可能である。このような場合、その後マーチャントは、ＰＲＥＦ及び／又はＰＲＥＦを表すバーコード、ＱＲコードなどをスキャンして、支払取引とマーチャント記録との間にリンクを作成することができる。

マーチャントシステムがＳＳＰシステムと、例えばＴＦＳサービスを提供するためのＴＲＯシステムと通信する場合、ＰＲＥＦをＳＳＰシステムに渡すことができる。

このようにして、マーチャントシステム自体をＰＣＩ−ＤＳＳに準拠させる必要なしに、ＰＣＩ−ＤＳＳに準拠した様式でマーチャントシステムを介して、支払取引のためにＰＡＮにマッピング可能なＰＲＥＦをＳＳＰシステムに渡すことができる。

その後ＳＳＰシステムは、必要に応じて、ＰＣＩ−ＤＳＳに準拠した様式で、ＰＳＰシステム又はカードスキームシステムによって保持されるＰＡＮにＰＲＥＦをリンクさせるように、必要に応じて、ＰＳＰシステム又はカードスキームシステムと通信することが可能である。

実行された場合、１つ又は複数のコンピュータシステムに１つ又は複数の態様を実施させる１つ又は複数のコンピュータプログラムによって、１つ又は複数の態様が実施可能である。

添付の図面を参照しながら、例示の実施形態を説明する。

図１は、取引システムにおけるＰＳＰシステムのトークン化を提供する例示の実施形態を示す概略ブロック図である。 図２Ａは、例示の取引を示すフローチャートである。 図２Ｂは、例示の取引を示すフローチャートである。 図３は、取引システムにおけるＰＳＰのトークン化を提供する別の例示の実施形態を示す概略ブロック図である。 図４は、取引システムにおけるカードスキームシステムのトークン化を提供する例示の実施形態を示す概略ブロック図である。 図５は、固有参照を生成するための例示の方法を示すフローチャートである。 図６は、固有参照を生成するための別の例示の方法を示すフローチャートである。 図７は、ＰＡＮマッピングテーブルへの固有参照の例である。

詳細な説明

図１は、取引システムにおけるＰＳＰシステムのトークン化を提供する例示の実施形態の概略ブロック図である。図１は、図１の取引システムにおいて実行されるいくつかの動作も示す。

販売時点情報管理電子キャッシュレジスタ（ＥＣＲ）１０は、顧客又は旅行者（以下、ユーザと呼ぶ）によって購入されることになる１つ又は複数の製品の詳細を入力するための典型的な電子キャッシュレジスタの機能を提供する、マーチャントシステムである。ＥＣＲ１０は、例えば、１つ又は複数のマーチャントシステム（図示せず）との通信において、購入の総額を計算するため、未払い税などを計算するための機能を提供するように、及び、例えば購入、顧客、在庫などの詳細を記録する機能を実行するようにも、プログラミングされる。ＥＣＲは、１つ又は複数のプロセッサ、ストレージ、ユーザインターフェースデバイス（例えば、ディスプレイ、タッチセンサ―式ディスプレイ、キーボードなど）、通信インターフェース（例えば、Ｅｔｈｅｒｎｅｔ（登録商標）、Ｗｉｆｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＮＦＣリーダー、バーコードスキャナなど）などを含むことができる。

図１の例において、ＥＣＲ１０は、直接、又は他のマーチャントシステム、例えばマーチャントサーバシステム（図示せず）を介して、特別サービスプロバイダ（ＳＳＰ）システム、例えば税金還付オペレータホストサーバシステムと、通信するようにも構成される。

図１の例において、ＥＣＲ１０はＰＣＩ−ＤＳＳに準拠する必要がないため、ＥＣＲ１０はユーザのペイメントカードの全カード会員番号（ＰＡＮ）を受信しないように構成される。「ペイメントカード」に言及する場合、この用語は、例えば、カード会員番号（ＰＡＮ）を使用する電子支払のための、任意の支払デバイス（例えば、従来のデビット、クレジット又はプリペイドのプラスチックカード、電子カードウォレット支払チップを組み込んだモバイル通信デバイスなど）を言い表すために総称的に用いられる。この点を念頭に置き、ユーザのペイメントカードを使用する取引は、電子資金決済支払端末（ＥＦＴ）２０を使用して実行される。ＥＦＴ２０は、典型的には、ディスプレイと、ユーザ入力用キーボードと、電話回線、有線又は無線ネットワーク、ＥＣＲなどのうちの１つ又は複数に接続するための１つ又は複数の通信インターフェースと、接触又は非接触（ＮＦＣ）通信を介するペイメントカード上の磁気ストライプ、ペイメントカード上のチップなどのうちの１つ又は複数を読み取るためのカードリーダーと、プリンタ、例えば感熱式プリンタと、を備える。図１の例において、ＥＣＲ１０及びＥＦＴ２０は相互接続され、ＥＣＲ１０とＥＦＴ２０との間で一定の情報が渡されるようにＥＣＲ１０とＥＦＴ２０との間に部分統合が提供されるが、下記でより詳細に説明するように、全ＰＡＮがＥＦＴ２０からＥＣＲ１０に送られることはない。

動作中、商品の購入がＥＣＲ１０によって処理され、支払合計が計算される場合、その後、商品の合計金額をＥＣＲ１０からＥＦＴ２０へと電子的に渡すことができる。例えばマーチャントは、１つ又は複数の商品を（例えば、ＥＣＲ１０のバーコードスキャナを使用して各商品上のバーコードをスキャンすることによって）入力した後、ＥＣＲ１０上のキーを操作して、ペイメントカードを使用する１つ又は複数の商品についての支払を可能にしてもよい。例えばキーは、ＥＣＲ上の物理的なキースイッチ、又は、ＥＣＲのタッチスクリーン上に表示されるキーとすることができる。その後、従来のＥＣＲ−ＥＦＴメッセージプロトコルに従い、商品の合計金額を含むことが可能なメッセージＭ１がＥＣＲ１０からＥＦＴ２０へと送信される。後で説明するように、この例では、選択された情報をＥＦＴ２０からＥＣＲ１０へと渡すこともできる。

ＥＦＴ２０は、図２を参照しながらより詳細に説明するように、ＰＡＮ、有効期限などを含む、ペイメントカードについてのペイメントカード詳細を、ペイメントカードから読み取るようにプログラミングすることができる。ＥＦＴ２０は、ＰＣＩ−ＤＳＳに準拠するように構成される。

その後、ＥＦＴ２０は、従来のＥＦＴ−ＰＳＰメッセージプロトコルに従い、商品の金額及び全ＰＡＮ、有効期限などを含む取引の詳細を渡すために、セキュアなチャネルを介して（例えば、電話回線又はコンピュータネットワークを介して）支払サービスプロバイダ（ＰＳＰ）システム３０と通信するように構成することができる。ＥＦＴ２０は、例えば承認要求メッセージＭ２をＰＳＰシステム３０に送信するように動作可能とすることができる。ＰＳＰシステム３０は、ＰＣＩ−ＤＳＳに準拠するように構成される。

図１の例において、ＰＳＰシステム３０は、ＥＦＴ２０をマーチャント取得者システム３０及び他のシステムに接続するためのインフラストラクチャを実装する、支払サービスプラットフォームを提供する。ＰＳＰシステム３０は、１つ又は複数のプロセッサ、ストレージ、ネットワークインターフェースなどを備える、ＰＳＰコンピュータサーバシステムとすることができる。ＰＳＰシステム３０は、ＰＡＮに直接又は間接的にリンク又はマッピングする、図１ではＰＳＰＲｅｆとして識別される、固有参照（ＰＲＥＦ）を生成するように動作可能である。

例えば、ＰＲＥＦは取引及びＰＳＰシステム３０に固有とすることが可能であり、ＰＳＰシステム３０は、ＰＲＥＦ、取引、及び取引に関連付けられるＰＡＮを含む記録を記憶するように配置可能であり、以てＰＲＥＦはＰＲＥＦとＰＡＮとの間にマッピングを提供する。例えば、ＰＳＰシステム３０は、ＰＳＰシステム３０が処理する各連続取引について新しい、異なるＰＲＥＦを生成するように動作可能とすることができる。各ＰＲＥＦは固有番号とすることができ、例えばＰＳＰシステム３０は、ＰＳＰシステム３０によって処理された最新の支払取引について、所与の数、例えば１だけ増分する（又は減分する）ことによって、ＰＳＰシステム３０によって処理されることになる所与の支払取引のためのＰＲＥＦを生成する。このようにして、ＰＲＥＦは取引に遡り、次にこれを使用して、ＰＳＰシステム３０によって保持される取引に関する記録を使用してＰＡＮにリンクすることができる。

こうしたプロセスの例が、図５に示されている。

ステップ５１０において、ＰＳＰシステム３０は、新しい取引のためにＥＦＴ２０から承認要求メッセージＭ２を受信する。承認要求は、例えば、ＥＦＴ２０からの取引ＩＤ（ＴＲＩＤ）、ＥＦＴに関するアドレス及び／又は識別子（ＥＦＴＡ）、取引に使用されるＰＡＮ、取引金額（ＴＲＡＭ）などを含む。

ステップ５１２において、ＰＳＰシステム３０は、ＰＳＰシステム３０によって取引に最後に割り振られたＰＲＥＦの値を１増分する（すなわち、ＰＲＥＦ_ｉ＝ＰＲＥＦ_ｉ―１＋１）。他の例では、次のＰＲＥＦを生成するために任意の好適なアルゴリズムを使用することができる。

ステップ５１４において、ＰＳＰシステム３０は、新しい取引に関する新しい取引記録、新しいＰＲＥＦと共にＴＲＩＤを記憶する新しい取引記録、並びに、ＰＡＮ及び、例えばＥＦＴＡ、ＴＲＡＭなどを作成し、（例えば、ＰＳＰシステム３０のストレージ内に）記憶する。

代替として、ＰＲＥＦは、支払取引自体とは無関係なペイメントカードＰＡＮについての固有トークンとして生成可能である。こうした例において、ＰＳＰシステム３０は、新しい支払取引を処理する場合、所与のＰＡＮについてすでにＰＲＥＦを生成したかどうかをチェックすることが可能であり、ＰＡＮについてまだＰＲＥＦを生成していない場合、最後に生成されたＰＲＥＦを増分（又は減分）することによって、ＰＡＮについて新しいＰＲＥＦを生成し、そうでなければ、単にそのＰＡＮについてすでに生成されたＰＲＥＦを使用する。

こうしたプロセスの例が、図６に示されている。

ステップ６１０において、ＰＳＰシステム３０は、新しい取引についてＥＦＴ２０から承認要求を受信する。承認要求は、例えば、ＥＦＴからの取引ＩＤ（ＴＲＩＤ）、ＥＦＴについてのアドレス及び／又は識別子（ＥＦＴＡ）、取引に使用されるＰＡＮ、取引金額（ＴＲＡＭ）などを含む。

ステップ６１２において、ＰＳＰシステム３０は、新しい取引のためのＰＡＮにＰＲＥＦがすでに割り振られているかどうかを判定するために、既存の記録をチェックする。

ステップ６１２において、ＰＡＮにＰＲＥＦがすでに割り振られているものと判定された場合、ステップ６１４において、ＰＳＰシステム３０は、ＰＡＮについての既存のＰＲＥＦを伴うＴＲＩＤを記憶し、また、ＰＡＮ及び、例えばＥＦＴＡ、ＴＲＡＭなどをさらに記憶する、新しい取引についての新しい取引記録を作成し、（例えば、ＰＳＰシステム３０のストレージ内に）記憶する。

ステップ６１２において、ＰＡＮにＰＲＥＦがまだ割り振られていないものと判定された場合、ステップ６１６において、ＰＳＰシステム３０は、ＰＳＰシステム３０によってＰＡＮに最後に割り振られたＰＲＥＦの値を１増分する（すなわち、ＰＲＥＦ_ｉ＝ＰＲＥＦ_ｉ―１＋１）。他の例では、次のＰＲＥＦを生成するために任意の好適なアルゴリズムを使用することができる。

その後ステップ６１８において、ＰＳＰシステム３０は、ＰＡＮについての新しいＰＲＥＦを伴うＴＲＩＤを記憶し、また、ＰＡＮ及び、例えばＥＦＴＡ、ＴＲＡＭなどをさらに記憶する、新しい取引についての新しい取引記録を作成し、（例えば、ＰＳＰシステム３０のストレージ内に）記憶する。

図５及び図６において上記で識別された取引記録の代替、又はこれらへの追加として、ＰＳＰシステム３０は、ＴＲＥＦを対応するＰＡＮに直接マッピングするためにアクセス可能なＰＡＮ変換表に、単純なＴＲＥＦを記憶することができる。

例えば、図７に示される表７００は、それぞれの固有ＰＲＥＦ７１０（ＰＲＥＦ_１からＰＲＥＦ_ｎ）をそれぞれのＰＡＮ７２０（ＰＡＮ_１からＰＡＮ_ｎ）にリンクするために、図５又は図６を参照しながら説明した方法を使用して生成可能である。

ＰＳＰシステム３０は、セキュアチャネルを介して承認要求メッセージＭ３をマーチャント取得者（ＭＡ）システム４０に送信するように、及び、ＭＡシステムから承認応答メッセージＭ６を受信するように、動作可能である。ＭＡシステム４０は、１つ又は複数のコンピュータサーバシステムを備えることが可能であり、例えば、承認要求メッセージＭ４及び承認応答メッセージＭ５を使用するリアルタイムでの承認処理のため、並びに、従来の様式でのバッチプロセス（図示せず）としての決済処理のために、セキュアチャネルを介して、スキーム（スキーマ）システム（ＭａｓｔｅｒＣａｒｄ、ＶＩＳＡなど）と通信するように構成される。ＭＡシステム４０及びスキームシステム５０は、ＰＣＩ−ＤＳＳに準拠するように構成される。

ＰＳＰシステム３０は、追加として、ＰＳＰシステム３０からＥＦＴ２０へのメッセージ、例えば承認応答メッセージＭ７に、ＰＲＥＦを含めるように構成される。

ＥＦＴ２０は、例えば支払完了メッセージＭ８で、ＰＲＥＦをＥＣＲ１０に通信するが、全ＰＡＮは通信しないように動作可能である。前述のプロセスの結果として、ＥＣＲ１０には、ＰＳＰシステム３０の記録内でのマッピングにおいて情報がセキュアに保持された状態で、実際に全ＰＡＮが提供されることなく、全ＰＡＮを識別するために使用可能なＰＲＥＦが提供される。したがってＥＣＲ１０は、ペイメントカードについての全ＰＡＮを保持しないため、ＰＣＩ−ＤＳＳに準拠するように構成される必要はない。

ＥＣＲ１０は、直接、又は他のマーチャントシステム（図示せず）を介して、ＰＲＥＦ及びＰＳＰシステム３０の識別情報をさらに識別する１つ又は複数の税金還付処理メッセージＭ９で、取引の詳細を、ＳＳＰシステム１００、例えば税金還付オペレータホストシステム１１０と通信するように構成される。

図１の例において、ＳＳＰシステム１００は、ＴＲＯホスト（ＴＲＯＨ）システム１１０、外部システム（例えば、税関及び／又は税務システム）との統合を含むＴＲＯ動作を処理するためのＴＲＯプロセス（ＴＲＯＰ）システム１２０、並びに、支払及び／又は引落動作を実行するためのＴＲＯ取引（ＴＲＯＴ）システム１３０を含む。ＴＲＯＨシステム１１０及びＴＲＯＰシステム１２０はＰＣＩ−ＤＳＳに準拠するように構成されないことが好ましいが、ＴＲＯＴシステム１３０はＰＣＩ−ＤＳＳに準拠するように構成される。ＴＲＯＨシステム１１０、ＴＲＯＰシステム１２０、及びＴＲＯＴシステム１３０の各々は、プロセッサ、ストレージなどを備える１つ又は複数のそれぞれのハードウェアサーバシステムによって実装可能であるか、或いは、１つ又は複数のハードウェアコンピュータシステムを実行する１つ又は複数の仮想サーバによって実装可能である。ＴＲＯＨシステム１１０、ＴＲＯＰシステム１２０、及びＴＲＯＴシステム１３０は、コンピュータクラウドベースシステムによっても実装可能である。

特別サービスが税金還付サービスである場合、ＥＣＲ１０は、購入の際に従来の様式の紙及び／又は電子の税金還付書式を生成するように動作可能とすることができる。税金還付書式は、取引の詳細、並びに、ＰＲＥＦとは異なり税金還付書式に固有な取引識別子（ＴＲＩＤ）を含む。税金還付書式は、例えば、税金還付書式取引に関連付けられた商品が輸出されるか、及び、以て還付が認証されるかを判別するために、取引の詳細を追跡可能にする。例えば、紙の還付書式が空港の還付デスクで提示可能であるか、若しくは、例えば、ＴＲＯオペレータが還付デスクで紙の領収書のバーコードをスキャンすることに応答して、或いは、ユーザが検証キオスクで情報を入力するか、又は例えば空港で携帯電話のアプリケーションを使用することによって、電子書式がＴＲＯＨシステム１１０又はＴＲＯＰホストシステム１２０から回収可能である。これらの動作を容易にするために、ＥＣＲ１０は、直接、又は他のマーチャントシステム（図示せず）を介して、ＴＲＯＨシステム１１０と通信し、ＴＲＩＤ、ＰＲＥＦ、及びＰＳＰシステム３０についての識別子（ＰＳＰＩＤ）を含む取引の詳細を含む電子税金還付書式を送信する。

ＴＲＯＨシステム１１０が、ＴＲＩＤ、ＰＲＥＦ、及びＰＳＰＩＤを含む取引の詳細をＥＣＲ１０から受信すると、ＴＲＯＨシステム１１０は、ＴＲＩＤ、ＰＲＥＦ、及びＰＳＰＩＤを含む取引の詳細を、ＴＲＯＰシステム１２０に渡すＭ１１。ＴＲＯＰシステム１２０は、例えば、購入に関連付けられた商品が輸出されたかどうかに関する情報を受信するＭ１２ために、税関システム又は輸出認証システム（図示せず）と通信するように構成可能である。このようにして、ユーザが、例えば空港又は国境区域にある還付デスク又は還付キオスクで、或いは携帯電話の還付認証アプリケーションを使用することによって、商品の輸出を認証する場合、ＴＲＯＰシステム１２０は、取引に関連付けられた商品が輸出された旨の通知を受信することができる。

商品の輸出が、例えばペイメントカードへの貸記によって税金還付の支払を始動させる場合、ＴＲＯＰシステム１２０は、ＴＲＩＤ、ＰＲＥＦ、及びＰＳＰＩＤの詳細、並びに、ユーザのペイメントカードに貸記されることになる金額を含む、他の詳細を、ＴＲＯＴシステム１３０に提供するＭ１３ように、動作可能とすることができる。

後に考察するような代替のシナリオでは、取引に関連付けられた１つ又は複数の商品は購入時点から所定の時間内（例えば、初期購入から２１日以内）に輸出されず、また、初期の取引（例えば、ＶＡＴ−ＯＦＦ又は早期還付取引について）を伴う商品の購入時に、関連付けられた一般売上税（ＧＳＴ）、付加価値税（ＶＡＴ）などは支払われず、その後、ＴＲＯＰシステム１２０は、ＴＲＩＤ、ＰＲＥＦ、及びＰＳＰＩＤの詳細を、その後、ユーザのペイメントカードから引き落とされることになる、関連付けられた一般売上税（ＧＳＴ）、付加価値税（ＶＡＴ）などに基づく金額を含む、他の詳細と共に、ＴＲＯＴシステム１３０に提供するＭ１４ように動作可能とすることができる。

しかしながら、どちらの場合でも、借記又は貸記のいずれが行われるかに関わらず、ＴＲＯＨシステム１１０及びＴＲＯＰシステム１２０はＰＣＩ−ＤＳＳに準拠していない可能性があるため、ＴＲＯＰシステム１２０は全ＰＡＮを保持せず、ＴＲＯＴシステム１３０は、ユーザのペイメントカード勘定に関して貸記又は借記を実施できるようにするために、全ＰＡＮを取得しなければならないことになる。

どちらの場合でも、ＴＲＯＴシステム１３０は、ＴＲＯＨシステム１１０及びＴＲＯＰシステム１２０を含む第１の通信チャネルを介して、マーチャントシステム（例えば、ＥＣＲ１０）から取引情報を受信し、この取引情報はＰＲＥＦを含む。

図１の例において、ＴＲＯＴシステム１３０は、所与のＴＲＩＤについての取引に関連付けられた、ＰＲＥＦと全ＰＡＮとの間のマッピングを取得するＭ１５ために、セキュア通信チャネルを介して、ＰＳＰシステム３０と通信するように構成される。セキュア通信チャネルは、支払承認チャネル、並びに、ＴＲＯＨシステム１１０及びＴＲＯＰシステム１２０を含む第１の通信チャネルに関しては帯域外の、第２の通信チャネルを形成する。

一例において、ＰＳＰシステム３０は、ＰＲＥＦと全ＰＡＮとの間のマッピングを、例えば、他のＰＲＥＦ及びＰＡＮについての他のマッピングと共に、例えばバッチプロセスにおいて、ＴＲＯＴシステム１３０に送る（すなわち、プッシュする）Ｍ１５ように動作可能である。その後、ＴＲＯＴシステム１３０もＰＣＩ−ＤＳＳに準拠しているため、マッピングのうちのすべて又は選択されたものを記憶するように動作可能であり、ユーザの勘定を借記又は貸記するためにＴＲＯＰシステム１２０からメッセージを受信する場合、ＰＲＥＦから記憶されたＰＡＮへのマッピングをすでに有しており、これを使用して、必要に応じてユーザのペイメントカード勘定を貸記又は借記することができる。こうしたバッチプロセスにおいて、ＰＲＥＦ及びＰＡＮはセキュアチャネルを介してブロードキャストすることが可能であり、ＴＲＯＴシステム１３０は、すべてのマッピング、又は、現在の取引の処理に必要なＰＲＥＦについてのマッピングのみの、いずれかをキャプチャするように、及び、ＴＲＯＴシステム１３０が現在必要としていないいずれのＰＲＥＦについてのマッピングも無視するように、動作可能とすることができる。

前述のようなバッチプロセスが使用されないか、又は、ＰＲＥＦからＰＡＮへのマッピングをまだ記憶していない旨を、ＴＲＯＴシステム１３０が発見する、別の例では、ＴＲＯＴシステム１３０は、所与のＰＲＥＦについてのマッピングの要求メッセージＭ１５ＲをＰＳＰシステム３０に送信するように、及び、応答メッセージＭ１５をリアルタイムでＰＳＰシステム３０から受信するように、動作可能である。このようにして、ＴＲＯＴシステム１３０は、ＰＲＥＦからＰＲＥＦに関連付けられたＰＡＮへのマッピングを、第２の通信チャネルを介して、（本例では、ＰＳＰシステム３０からの）カード支払を承認するための承認チャネル内の支払承認チャネル（ＰＡＣ）システムから受信する。

したがって、図１の例において、ＴＲＯＴシステム１３０がユーザのペイメントカード勘定で貸記又は借記を実施できるようにするための情報は、マーチャントシステムがユーザのペイメントカードについての全ＰＡＮを知る必要なしに実施可能であり、以て、マーチャントのＥＣＲ１０は、ＰＣＩ−ＤＳＳに準拠するように構成される必要はない。

図２（図２Ａ及び図２Ｂからなる）は、図１のシステムの動作の特定の例において実行される動作をより詳細に示す。この例を、図１及び図２を参照しながら下記で説明する。

前述のように、図１の例では、ＥＦＴ２０とＥＣＲ１０との間に部分統合が提供される。これは、例えば１つ又は複数の商品がＥＣＲ１０で購入されている場合、代金支払い（tender、テンダー）を作成するためのＥＣＲ−ＥＦＴプロトコルに従って、ＥＣＲ１０からＥＦＴ２０にメッセージが送信されることを意味する。メッセージは、取引金額、ＥＣＲ取引ＩＤ、支払取引のタイプ（デビット、クレジット、予約）などを含むことができる。

その後、ＥＦＴ２０はペイメントカードをＥＦＴ２０に提示するようユーザ５に指示するように構成される。ペイメントカードが（例えば、磁気ストリップリーダー、チップリーダー、又は近距離無線通信（ＮＦＣ）リーダーを使用して）端末に提示されるとき、ＥＦＴ２０は、ＰＡＮ及びペイメントカードからの他の情報を読み取るように動作可能である。

ＥＦＴ２０は、その後、例えば、ペイメントカードが、ＥＦＴ２０が位置している国内で発行されたペイメントカードであるか、又は、ユーザ５が潜在的に一般売上税（ＧＳＴ）又は付加価値税（ＶＡＴ）の還付（本明細書では、総称的に税金還付と呼ぶ）を受ける権利が与えられていることを意味する異なる国で発行されたペイメントカードであるかを判定するために、ペイメントカードを認証するための認証要求メッセージを、ＰＳＰシステム３０に送信するように動作可能である。ＰＳＰシステム３０からＥＦＴ２０への戻りメッセージが、ユーザ５が潜在的に税金還付を受ける権利を与えられていることを示すメタデータを含んでいる場合、ＥＦＴ２０は、ユーザ５が税金還付を受け取るための資格を検証するようにマーチャントに指示するために、メッセージ（ＡｄｄｉｔｉｏｎａｌＤａｔａＣａｌｌｂａｃｋメッセージ）をＥＣＲ１０に伝送するように動作可能である。例えば、マーチャントによって手動で、又はユーザ５によって入力された情報に基づいて（例えば、ユーザ５のパスポート又は携帯電話の情報を使用して）自動的に、チェックを行うことができる。このチェックによって、ユーザが税金還付を受け取る資格があることを確認した場合に、１つ又は複数の還付オプションをユーザ５に提供してもよい。

オペレータがユーザ５に還付オプションを説明することによって、還付オプションをユーザ５に提示することが可能であるか、又は、メッセージを（例えば、ＷｉＦｉ、ＮＦＣなどを使用して）ユーザ５の携帯電話に渡すことによって、オプションを、例えばＥＣＲ１０のスクリーン上でユーザ５に表示することが可能である。

したがって、図２に示される例において、ＥＣＲ１０は、ユーザ５に異なるサービスを提供するように動作可能とすることができる。図２は、図２において差引還付（Ｒｅｆｕｎｄ Ｏｆｆ）、迅速還付（Ｆａｓｔ Ｒｅｆｕｎｄ）、及び標準（Ｓｔａｎｄａｒｄ）として識別される３つの代替サービスを示す。下記で、処理におけるこれらの次の段階を説明する。
間接的還付

本明細書において間接的還付サービスとして説明する還付サービスとは、ユーザ５が、未払い税を含む商品について総額を支払い、またその後、例えば、ユーザ５が購入している商品を輸出する際に空港の還付デスクで行われる別のキャッシュカード又はクレジットカード取引の形で税金の還付を受け取る、サービスである。

このオプションの（例えば、ユーザ５が自分の選択をマーチャントに通知することに応答して、物理的又は表示されるキーボタンをマーチャントが作動させることによる、及び／又は、ＥＣＲ１０のスクリーン又はユーザの携帯電話を介するデータ交換をユーザ５が使用することによる）選択に応答して、ＥＣＲ１０は、ユーザの間接的還付の選択を含む更新されたテンダーメッセージＭ１をＥＦＴ２０に送信するように構成される。更新されたテンダーメッセージＭ１は、ＥＦＴ２０への税金を含む取引の総額と、間接的還付オプションが選択されたことを示すためのコードＴＦＳ＿ＣＣ＝Ｆａｌｓｅとを含む。

その後、ＥＦＴ２０は、個人識別番号（ＰＩＮ）を挿入するようにユーザ５に指示するように動作可能である。ＰＩＮの入力に応答して、ＥＦＴ２０は、ＰＩＮが正しいことを検証するように動作可能である。ＥＦＴ２０は、ＰＣＩ−ＤＳＳに準拠するように構成され、したがって、ペイメントカードについてのＰＡＮを保持及び処理することが可能である。ＰＩＮが正しい場合、ＥＦＴ２０は、税金と、間接的還付オプションが選択されたことを示すためのＴＦＳ＿ＣＣ＝Ｆａｌｓｅコードとを含む、取引の総額に対応するマーチャントについて、承認要求メッセージＭ２をＰＳＰシステム３０に送信するように動作可能である。ＥＦＴ２０からＰＳＰシステム３０に送信される例示的な承認要求メッセージＭ２は、例えば、ＰＡＮ、有効期限、カードスキーマ、カード保有者の詳細、通貨コード、支払金額、通貨、端末ＩＤ、マーチャントＩＤ、支払取引のタイプなどの、情報を含むことができる。

図１に示されるように、ＰＳＰシステム３０は、承認要求メッセージＭ３をマーチャント取得者（ＭＡ）システム４０に送信する。ＰＳＰシステム３０からＭＡシステム４０に送信される承認要求メッセージＭ３の例は、例えば、ＰＡＮ、有効期限、カードスキーマ、カード保有者の詳細、通貨コード、支払金額、通貨、端末ＩＤ、マーチャントＩＤ、支払取引のタイプなどの情報、及び、ＰＳＰ特有の情報を含むことができる。次に、ＭＡシステム４０は、使用されたカードシステムについてカード発行者（図示せず）のシステムから承認を取得するために、カードスキーム（例えば、ＶＩＳＡ、ＭａｓｔｅｒＣａｒｄ）システム５０と通信するＭ４。ここでは、支払取引がカード発行者システムによって承認されたものと想定され、この場合、カードスキームシステム５０によってカード発行者システムから肯定的な承認要求が受信され、次にカードスキームシステム５０が承認応答メッセージＭ５をＭＡシステム４０に送信し、次にＭＡシステム４０が承認応答メッセージＭ６をＰＳＰシステム３０に送信する。ＭＡシステム４０からＰＳＰシステム３０に送信される例示的な承認応答メッセージＭ６は、例えば、承認応答、クレジットカードトークン、承認コード、金額、取得者コード、通貨などの情報を含むことができる。図１の例におけるＰＳＰシステム３０は、取引及びＰＳＰシステム３０に固有の取引識別情報（ＰＲＥＦ）を生成するように、及び、ＰＲＥＦをペイメントカード番号にマッピングする記録を生成するように、動作可能である。例えば、図７に示される表７００は、それぞれの固有のＰＲＥＦ７１０（ＰＲＥＦ_１からＰＲＥＦ_ｎ）をそれぞれのＰＡＮ７２０（ＰＡＮ_１からＰＡＮ_ｎ）にリンクさせるために、図５又は図６を参照しながら上記で説明した方法を使用して生成可能である。ＭＡシステム４０からの承認応答メッセージＭ６の受信時に、ＰＳＰシステム３０は、承認応答メッセージＭ７をＥＦＴ２０に送信するように動作可能とすることができる。ＰＳＰシステム３０からＥＦＴ２０に送信される例示的な承認応答メッセージＭ７は、例えば、承認応答、クレジットカードトークン、承認コード、金額、取得者コード、通貨などの情報、及び、ＰＳＰ参照番号、ＰＲＥＦなどのＰＳＰ特有の情報を含むことができる。したがって、これはＰＲＥＦを含む。

図２に示されるように、その後、ＥＦＴ２０は、ＰＲＥＦを含むＦｉｎａｌＴｒａｎｓａｃｔｉｏｎＲｅｓｕｌｔＣａｌｌｂａｃｋメッセージＭ８をＥＣＲ１０に送信し、ＥＦＴ２０は、ＥＦＴ２０のカードリーダーからペイメントカードを取り除くためのメッセージをユーザ５に表示する。
迅速還付

本明細書において迅速還付として説明する還付サービスとは、ユーザ５が未払い税を含む商品について総額を支払い、その後、商品の輸出に応答して、購入取引に使用されるペイメントカードへの自動的な貸記の形で税金の還付を受け取る、サービスである。還付デスクでのＴＲＯオペレータによるコンピュータ端末への情報入力、ユーザ５による空港での自動化端末への情報入力、携帯電話が空港にあることを識別するために例えば地理位置情報を使用する携帯電話アプリケーションへの入力情報に応答して、商品の輸出を識別することができる。輸出を確認するメッセージがＴＲＯＰシステム１２０に伝送されるように、コンピュータ端末、自動化端末、及び／又は携帯電話アプリケーションはＴＲＯＰシステム１２０に動作可能にリンクされる。

このオプションの（例えば、ユーザ５が自分の選択をマーチャントに通知することに応答して、物理的又は表示されるキーボタンをマーチャントが作動させることによる、及び／又は、ＥＣＲ１０のスクリーン又はユーザの携帯電話を介するデータ交換をユーザ５が使用することによる）選択に応答して、ＥＣＲ１０は、ユーザの迅速還付の選択を含む更新されたテンダーメッセージＭ１をＥＦＴ２０に送信するように構成される。この例において、更新されたテンダーメッセージＭ１は、ＥＦＴ２０への税金を含む取引の総額と、選択された迅速還付オプションに対してペイメントカードの自動的な借記／貸記が承認されたことを示すためのコードＴＦＳ＿ＣＣ＝Ｔｒｕｅとを含む。

その後、ＥＦＴ２０は、個人識別番号（ＰＩＮ）を挿入するようにユーザ５に指示するように動作可能である。ＰＩＮの入力に応答して、ＥＦＴ２０は、ＰＩＮが正しいことを検証するように動作可能である。ＥＦＴ２０は、ＰＣＩ−ＤＳＳに準拠するように構成され、したがって、ペイメントカードについてのＰＡＮを保持及び処理することが可能である。この例において、ＰＩＮが正しい場合、ＥＦＴ２０は、税金と、迅速還付オプションに対してペイメントカードの自動的な借記／貸記が承認されたことを示すためのＴＦＳ＿ＣＣ＝Ｔｒｕｅコードとを含む、取引の総額に対応するマーチャントについて、承認要求メッセージＭ２をＰＳＰシステム３０に送信するように動作可能である。ＥＦＴ２０からＰＳＰシステム３０に送信される例示的な承認要求メッセージＭ２は、例えば、ＰＡＮ、有効期限、カードスキーマ、カード保有者の詳細、通貨コード、支払金額、通貨、端末ＩＤ、マーチャントＩＤ、支払取引のタイプなどの、情報を含むことができる。

図１に示されるように、ＰＳＰシステム３０は、承認要求メッセージＭ３をＭＡシステム４０に送信する。ＰＳＰシステム３０からＭＡシステム４０に送信される承認要求メッセージＭ３の例は、例えば、ＰＡＮ、有効期限、カードスキーマ、カード保有者の詳細、通貨コード、支払金額、通貨、端末ＩＤ、マーチャントＩＤ、支払取引のタイプなどの情報、及び、ＰＳＰ特有の情報を含むことができる。次に、ＭＡシステム４０は、使用されたカードシステムについてカード発行者（図示せず）のシステムから承認を取得するために、カードスキーム（例えば、ＶＩＳＡ、ＭａｓｔｅｒＣａｒｄ）システム５０と通信するＭ４。ここでは、支払取引がカード発行者システムによって承認されたものと想定され、この場合、カードスキームシステム５０によってカード発行者システムから肯定的な承認要求が受信され、次にカードスキームシステム５０が承認応答メッセージＭ５をＭＡシステム４０に送信し、次にＭＡシステム４０が承認応答メッセージＭ６をＰＳＰシステム３０に送信する。ＭＡシステム４０からＰＳＰシステム３０に送信される例示的な承認応答メッセージＭ６は、例えば、承認応答、クレジットカードトークン、承認コード、金額、取得者コード、通貨などの情報を含むことができる。図１の例におけるＰＳＰシステム３０は、取引及びＰＳＰシステム３０に固有の取引識別情報（ＰＲＥＦ）を生成するように、及び、ＰＲＥＦをペイメントカード番号にマッピングする記録を生成するように、動作可能である。ＭＡシステム４０からの承認応答メッセージＭ６の受信時に、ＰＳＰシステム３０は、承認応答メッセージＭ７をＥＦＴ２０に送信するように動作可能とすることができる。ＰＳＰシステム３０からＥＦＴ２０に送信される例示的な承認応答メッセージＭ７は、例えば、承認応答、クレジットカードトークン、承認コード、金額、取得者コード、通貨などの情報、及び、ＰＳＰ参照番号、ＰＲＥＦなどのＰＳＰ特有の情報を含むことができる。したがって、これはＴＲＥＦを含む（図２ではｐｓｐＲｅｆと識別される）。

図２に示されるように、その後、ＥＦＴ２０は、ＰＲＥＦを含むＦｉｎａｌＴｒａｎｓａｃｔｉｏｎＲｅｓｕｌｔＣａｌｌｂａｃｋメッセージＭ８をＥＣＲ１０に送信し、ＥＦＴ２０は、ＥＦＴ２０のカードリーダーからペイメントカードを取り除くためのメッセージをユーザ５に表示する。
差引還付

本明細書において差引還付として説明する還付サービスとは、ユーザ５が商品について総額を支払わず、代わりに総額から還付金額を引いた額に等しい減額を支払うサービスであり、還付金額は少額のサービス料が引かれたＧＳＴ又はＶＡＴの金額に相当する。続いて、商品が所定の時間内、例えば２１日以内に輸出された場合、さらなる取引は発生しない。しかしながら、商品が所定の期間内に輸出されない場合、その期間の終わりに、ＧＳＴ又はＶＡＴの総額がペイメントカードから自動的に引き落とされる。還付デスクでのＴＲＯオペレータによるコンピュータ端末への情報入力、ユーザ５による空港での自動化端末への情報入力、携帯電話が空港にあることを識別するために例えば地理位置情報を使用する携帯電話アプリケーションへの入力情報に応答して、商品の輸出を識別することができる。輸出を確認するメッセージがＴＲＯＰシステム１２０に伝送されるように、コンピュータ端末、自動化端末、及び／又は携帯電話アプリケーションはＴＲＯＰシステム１２０に動作可能にリンクされる。所定の期間内に輸出が識別されないことによって、輸出なしが識別される。ＴＯＰシステム１２０は、取引についての記録及び輸出が発生していない期限の満了を監視する。

このオプションの（例えば、ユーザ５が自分の選択をマーチャントに通知することに応答して、物理的又は表示されるキーボタンをマーチャントが作動させることによる、及び／又は、ＥＣＲ１０のスクリーン又はユーザの携帯電話を介するデータ交換をユーザ５が使用することによる）選択に応答して、ＥＣＲ１０は、ユーザの差引還付の選択を含む更新されたテンダーメッセージＭ１をＥＦＴ２０に送信するように構成される。更新されたテンダーメッセージＭ１は、ＥＦＴ２０への税金から還付金額を引いた額を含む取引の総額と、差引還付オプションに対してペイメントカードの自動的な借記／貸記が承認されたことを示すためのコードＴＦＳ＿ＣＣ＝Ｔｒｕｅとを含む。

その後、ＥＦＴ２０は、個人識別番号（ＰＩＮ）を挿入するようにユーザ５に指示するように動作可能である。ＰＩＮの入力に応答して、ＥＦＴ２０は、ＰＩＮが正しいことを検証するように動作可能である。ＥＦＴ２０は、ＰＣＩ−ＤＳＳに準拠するように構成され、したがって、ペイメントカードについてのＰＡＮを保持及び処理することが可能である。ＰＩＮが正しい場合、ＥＦＴ２０は、税金と、差引還付オプションに対してペイメントカードの自動的な借記／貸記が承認されたことを示すためのＴＦＳ＿ＣＣ＝Ｔｒｕｅコードとを含む、取引の総額に対応するマーチャントについて、承認要求メッセージＭ２をＰＳＰシステム３０に送信するように動作可能である。ＥＦＴ２０からＰＳＰシステム３０に送信される例示的な承認要求メッセージＭ２は、例えば、ＰＡＮ、有効期限、カードスキーマ、カード保有者の詳細、通貨コード、支払金額、通貨、端末ＩＤ、マーチャントＩＤ、支払取引のタイプなどの、情報を含むことができる。

図１に示されるように、承認要求メッセージＭ３はＭＡシステム４０に送信される。ＰＳＰシステム３０からＭＡシステム４０に送信される承認要求メッセージＭ３の例は、例えば、ＰＡＮ、有効期限、カードスキーマ、カード保有者の詳細、通貨コード、支払金額、通貨、端末ＩＤ、マーチャントＩＤ、支払取引のタイプなどの情報、及び、ＰＳＰ特有の情報を含むことができる。次に、ＭＡシステム４０は、使用されたカードシステムについてカード発行者（図示せず）のシステムから承認を取得するために、カードスキーム（例えば、ＶＩＳＡ、ＭａｓｔｅｒＣａｒｄ）システム５０と通信するＭ４。ここでは、支払取引がカード発行者システムによって承認されたものと想定され、この場合、カードスキームシステム５０によってカード発行者システムから肯定的な承認応答メッセージが受信され、次にカードスキームシステム５０が承認応答メッセージＭ５をＭＡシステム４０に送信し、次にＭＡシステム４０が承認応答メッセージＭ６をＰＳＰシステム３０に送信する。ＭＡシステム４０からＰＳＰシステム３０に送信される例示的な承認応答メッセージＭ６は、承認応答、クレジットカードトークン、承認コード、金額、取得者コード、通貨などの情報を含むことができる。図１の例におけるＰＳＰシステム３０は、取引及びＰＳＰシステム３０に固有の取引識別情報（ＰＲＥＦ）を生成するように、及び、ＰＲＥＦをペイメントカード番号にマッピングする記録を生成するように、動作可能である。ＭＡシステム４０からの承認応答メッセージＭ６の受信時に、ＰＳＰシステム３０は、承認応答メッセージＭ７をＥＦＴ２０に送信するように動作可能とすることができる。ＰＳＰシステム３０からＥＦＴ２０に送信される例示的な承認応答メッセージＭ７は、例えば、承認応答、クレジットカードトークン、承認コード、金額、取得者コード、通貨などの情報、及び、ＰＳＰ参照番号、ＰＲＥＦなどのＰＳＰ特有の情報を含むことができる。したがって、これはＰＲＥＦを含む（図２ではｐｓｐＲｅｆと識別される）。

図２に示されるように、その後、ＥＦＴ２０は、ＰＲＥＦを含むＦｉｎａｌＴｒａｎｓａｃｔｉｏｎＲｅｓｕｌｔＣａｌｌｂａｃｋメッセージＭ８をＥＣＲ１０に送信し、ＥＦＴ２０は、ＥＦＴ２０のカードリーダーからペイメントカードを取り除くためのメッセージをユーザ５に表示する。

上記で説明した例示の動作において、ＴＦＳ＿ＣＣ＝Ｔｒｕｅフラグの使用は単なる１つのオプションであり、これによってＰＳＰシステム３０は、後にいずれのＰＡＮをＳＳＰシステム１００に提供するかを知ることができることに留意されたい。サービスは、この指示なしでも稼働する。このような場合、様々な他のオプションが存在する。１つのオプションでは、ＳＳＰシステム１００は、ＴＲＥＦ（支払基準）を使用してＰＡＮについてＰＳＰシステム３０に照会することができる。別のオプションでは、ＰＳＰシステム３０はすべてのカード支払取引をＳＳＰシステム１００にプッシュし、ＳＳＰシステム１００は、例えばＳＳＰ取引が支払いにリンクされる場合、他の支払取引を無視する必要がある場合は必ず、ＴＲＥＦをＰＡＮに分解する。

上記で説明した各オプションにおいて、ＥＣＲ１０は、その後、還付取引を要求するために、発行要求メッセージＭ９をＳＳＰシステム１００（例えば、ＴＲＯＨシステム１１０）に渡すように動作可能である。発行要求メッセージは、ＰＲＥＦ（ｐｓｐＲｅｆ、ペイメントカードメタデータ、及び発行データ）を含むことができる。

発行要求に応答して、ＳＳＰシステム１００（例えば、ＴＲＯＨシステム１１０）は、ＥＣＲ１０に税金還付書式（ＴＦＦ）を生成（例えば、印刷）するように命じるために、発行応答メッセージを伝送するように動作可能である。

ＥＣＲ１０は、その後、ＴＦＦの印刷を確認するために、ＳＳＰシステム１００（例えば、ＴＲＯＨシステム１１０）に確認チェックメッセージを送信するように動作可能である。早期還付オプションの場合、ＳＳＰシステム１００（例えば、ＴＲＯＨシステム１１０）は、確認チェックメッセージの受信を確認するために、ＥＣＲ１０に確認チェック応答メッセージを戻すように動作可能でもある。

上記で考察したように、ＳＳＰシステム１００は、マーチャントのＥＣＲ１０とインターフェースする１つ又は複数のＳＳＰホストシステム（例えば、ＴＲＯＨシステム１１０）、１つ又は複数のＳＳＰプロセスシステム（例えば、ＴＲＯＰシステム１２０）、及び、１つ又は複数のＳＳＰ金融取引システム（例えば、ＴＲＯＴシステム１３０）を含むことができる。ＳＳＰプロセスシステム１２０は、ＳＳＰホストシステム１１０から情報を受信するために、ＳＳＰホストシステム１１０とインターフェースするように動作可能である。ＳＳＰプロセスシステム１２０は、例えば、税関システム、ＴＲＯ還付デスクシステム、端末システム、及び／又は、ユーザ５が商品を輸出した時点を特定するように動作可能なユーザの携帯電話の１つ又は複数のモバイルアプリケーションなどの、外部システムとインターフェースするようにも動作可能である。ＳＳＰ取引システム１３０は、ＰＲＥＦ及び貸記又は借記される金額を定義する、メッセージに基づいて貸記及び／又は借記を処理するための命令を受信するために、ＳＳＰプロセスシステムとインターフェースするように動作可能である。ＳＳＰ支払システムは、ＰＲＥＦと、貸記又は借記されるペイメントカードについての関連付けられたＰＡＮとの間のマッピングを取得するために、セキュアチャネルを介してＳＳＰ支払システムとインターフェースするようにも動作可能である。

図２の例示的なフローでさらに示されるように、ＴＦＳ＿ＣＣ＝ＴｒｕｅコードがＥＦＴ２０からＰＳＰシステム３０に送信され、ＰＳＰシステム３０は、ＰＲＥＦをＰＡＮにマッピングするマッピングメッセージＭ１５をＳＳＰ取引システム１３０に送信するように動作可能である。図１を参照しながら説明したように、これは、バッチプロセスの一部として、又は、ＳＳＰ取引システム１３０からのＰＳＰシステム３０への特定要求に応答するものとして、可能である。マッピングメッセージは、ＰＲＥＦ（前述のように、図１の例では、ＰＳＰシステム３０及びＰＡＮに固有である）を識別することが可能であり、以て、ＰＡＮ及びさらにはメタデータが固有に識別される。ＳＳＰ取引システム１３０はＰＣＩ−ＤＳＳに準拠しているため、ＰＡＮに基づいて貸記Ｍ１６及び／又は借記Ｍ１７の取引を実施するために必要な全ＰＡＮ及び他のペイメントカードの詳細を、記憶及び処理することが可能であり、図１に示されるＴＲＯ取得者システム７０を介して、ＰＡＮによって識別される勘定を伴う。ＴＲＯ取得者システム７０は、従来の様式でカードスキームシステム５０とインターフェースする。

図１は、Ｓ１、Ｓ２、Ｓ３、Ｓ４、及びＳ５とラベル表示された破線を用いて、ＥＦＴ２０、ＥＣＲ１０、ＴＲＯＨシステム１１０、及びＴＲＯＰシステム１２０を介する、ＰＳＰシステム３０からＴＲＯＴシステム１３０への、ＰＲＥＦを含むメッセージのフローを示す。これは、ＰＡＮ（すなわち、ＰＲＥＦ）に固有であるが、ＰＡＮを識別しないトークンを、それらのシステムを介して渡すことが可能であることを意味する。結果として、こうしたメッセージはセキュアチャネルによって送信されるが、ＥＣＲ１０、ＴＲＯＨシステム１１０、及びＴＲＯＰシステム１２０は、ＰＣＩ−ＤＳＳに準拠するように構成される必要はない。図１は、Ｓ６とラベル表示された太い破線を用いて、ＰＲＥＦを含むセキュアメッセージと、セキュアなＰＣＩ−ＤＳＳに準拠したチャネルを介するＰＳＰシステム３０からＴＲＯＴシステム１３０への直接的なＰＡＮへのマッピングとを含む、フローも示す。上記で考察したように、ＰＳＰシステム３０及びＴＲＯＴシステム１３０は、どちらもＰＣＩ−ＤＳＳに準拠するように構成される。

図３は、取引システムにおける、ＰＳＰシステムのトークン化を提供する例示の実施形態の概略ブロック図である。図３の例は、ＥＦＴ２０がＥＣＲ１０に統合されていない点を除いて、図１の例と同じである。図３の例は、ＥＦＴ２０とＥＣＲ１０との間の統合がないことを別にすれば、実質的に図１の例に対応しているため、図３の説明のために、上記の図１及び図２の説明が参照され、同様の参照記号が図３及び図１で使用される。唯一の相違は、ＥＦＴ２０とＥＣＲ１０との間で情報が転送される様式に関係しており、次に、その例を説明する。

図３の例では、ＥＦＴ２０は、ＥＣＲ１０と統合されていないスタンドアロン型ＥＦＴ２０である。

例えば、マーチャントは、１つ又は複数の商品を（例えば、ＥＣＲ１０のバーコードスキャナを使用して、その商品又は各商品上のバーコードをスキャンすることによって）入力し、その後、ＥＣＲ１０のキーを操作して、ＥＦＴ２０のユーザインターフェース（例えば、キーボード）を使用して、ＥＣＲ１０のオペレータによって手動で入力されるべきＥＣＲ情報を生成してもよい。マーチャントオペレータは、ＥＦＴ２０のユーザインターフェースを使用して、ＥＣＲ１０のディスプレイ上に示される商品の価格を入力することができる。

図１を参照しながら上記で説明したように、ＥＦＴ２０は、例えば図２を参照しながら説明するように、ペイメントカードについてのＰＡＮ、有効期限などを含むペイメントカードの詳細を、ペイメントカードから読み取るようにプログラミングすることができる。ＥＦＴ２０は、ＰＣＩ−ＤＳＳに準拠するように構成される。また図１を参照しながら説明したように、ＥＦＴ２０は、その後、ＥＦＴ−ＰＳＰメッセージプロトコルに従って、商品の金額及び全ＰＡＮ、有効期限などを含む取引の詳細を渡すために、セキュアチャネルを介して支払サービスプロバイダ（ＰＳＰ）システム３０と通信するように構成することができる。ＥＦＴ２０は、例えば、承認要求メッセージをＰＳＰシステム３０に送信するように動作可能とすることができる。ＰＳＰシステム３０は、ＰＣＩ−ＤＳＳに準拠するように構成される。図３の例において、ＰＳＰシステム３０は、ＰＡＮ及びＰＳＰシステム３０に固有であり、以て、ＰＲＥＦとＰＡＮとの間にマッピングを提供する取引について、図３においてＰＳＰＲｅｆとして識別される取引基準（ＰＲＥＦ）を生成するようにも動作可能である。ＰＳＰシステム３０は、セキュアチャネルを介してマーチャント取得者システム（ＭＡシステム）４０と通信するように動作可能である。次にＭＡシステム４０は、例えば、リアルタイムでの承認処理のため、及び、従来の様式でのバッチプロセスとしての決済処理のために、セキュアチャネルを介してスキームシステム（ＭａｓｔｅｒＣａｒｄ、ＶＩＳＡなど）５０と通信するように構成される。ＭＡシステム４０及びスキームシステム５０は、ＰＣＩ−ＤＳＳに準拠するように構成される。ＰＳＰシステム３０は、追加として、ＰＳＰシステム３０からＥＦＴ２０へのメッセージ、例えば承認応答メッセージに、ＰＲＥＦを含めるように構成される。

図３の例において、ＥＦＴ２０はスタンドアロン型ユニットであり、ＥＣＲ１０と統合されていないため、自動的にＰＲＥＦをＥＣＲ１０に送信することができない。しかしながら、従来の様式では、カード取引の印刷された記録を提供するために、ＥＦＴにプリンタが提供される。したがって、図３の例においてＥＦＴは、カード取引の印刷された記録（領収書）を印刷する場合、ＰＲＥＦの表現を含むバーコード（例えば、１次元バーコード又は２次元バーコード（ＱＲコード））２５を含めるように構成される。このバーコードは、その後、バーコード内の情報をキャプチャするために、ＥＣＲ１０のスキャナ１５を使用してスキャンすることができる。ＥＣＲ１０は、ＰＲＥＦをＥＣＲ１０に入力できるようにするために、バーコードによって表される情報からＰＲＥＦを抽出するように構成可能である。特に２Ｄバーコードの場合、追加情報（カードスキーマ、有効期限、カード発行者の国名、カード保有者の名前、マスクされたクレジットカード番号など）をバーコード内にコーディングすることができる。

前述のプロセスの結果として、図３のＥＣＲ１０には、ＰＳＰシステム３０におけるマッピングで情報がセキュアに保持された状態で、実際に全ＰＡＮが提供されることなく、全ＰＡＮを識別するために使用可能なＰＲＥＦが提供される。したがって、ＥＣＲ１０は、ペイメントカードについての全ＰＡＮを保持していないため、ＰＣＩ−ＤＳＳに準拠するように構成される必要はない。その後、図３の例において、図１の例で部分統合によってＰＲＥＦが転送されるのと同様に、ＰＲＥＦを使用することができる。図３の例のさらなる動作は図１の動作に対応しており、本明細書では反復しない。

図３は、Ｓ１、Ｓ２−１、Ｓ２−２、Ｓ３、Ｓ４、及びＳ５とラベル表示された太い破線を用いて、ＥＦＴ２０、バーコード２５及びスキャナ１５、ＥＣＲ１０、ＴＲＯＨシステム１１０、及びＴＲＯＰシステム１２０を介して、ＰＳＰシステム３０からＴＲＯＴシステム１３０へのＰＲＥＦを含むメッセージのフローを示す。これは、ＰＡＮ（すなわち、ＰＲＥＦ）に固有であるが、ＰＡＮを識別しないトークンを、それらのシステムを介して渡すことが可能であることを意味する。結果として、こうしたメッセージはセキュアチャネルによって送信されるが、ＥＣＲ１０、ＴＲＯＨシステム１１０、及びＴＲＯＰシステム１２０は、ＰＣＩ−ＤＳＳに準拠するように構成される必要はない。図１は、Ｓ６とラベル表示された太い破線を用いて、ＰＲＥＦを含むセキュアメッセージと、セキュアなＰＣＩ−ＤＳＳに準拠したチャネルを介するＰＳＰシステム３０からＴＲＯＴシステム１３０への直接的なＰＡＮへのマッピングとを含む、フローも示す。上記で考察したように、ＰＳＰシステム３０及びＴＲＯＴシステム１３０は、どちらもＰＣＩ−ＤＳＳに準拠するように構成される。

結果として、図１又は図３及び図２を参照しながら説明した、請求する主題の実施形態は、マーチャントシステムがＰＡＮを保持していない相互接続されたシステムにわたって、ＰＣＩ−ＤＳＳに準拠した様式でＰＡＮの取り扱いを可能にすることができる一方で、取引のためにＰＡＮの知識を必要とするＳＳＰシステムによって、第三者サービスの提供も可能にする。説明したように、ＳＳＰシステムは、例えば、税金還付サービスを提供するための１つ又は複数のＴＲＯホストシステムを含むことができる。例えば、ＥＣＲによってＰＡＮをキャプチャする必要なしに、ＴＦＳをマーチャントシステム（例えば、ＥＣＲ）の動作に組み込んでもよく、以て、ＥＣＲをＰＣＩ−ＤＳＳの範囲外に維持することができる。支払いのために、専用のスタンドアロン型又は半統合端末を使用して、ＰＡＮをキャプチャすることができる。ＰＡＮは、ＥＣＲ及び他のマーチャントシステムを介してルーティングされない。

図４は、取引システムにおけるカードスキームシステムのトークン化を提供する例示の実施形態の概略ブロック図である。図４の例では、ＰＳＰシステム３０ではなくカードスキームシステム４０によってＰＲＥＦが生成される。

図４の例において、販売時点情報管理電子キャッシュレジスタ（ＥＣＲ）１０は、顧客（以下、ユーザ５と呼ぶ）によって購入されることになる１つ又は複数の製品の詳細を入力するための典型的な電子キャッシュレジスタの機能を提供する、マーチャントシステムである。ＥＣＲ１０は、例えば、１つ又は複数のマーチャントシステム（図示せず）との通信において、購入の総額を計算するため、未払い税などを計算するための機能を提供するように、及び、例えば購入、顧客、在庫などの詳細を記録する機能を実行するようにも、プログラミングされる。ＥＣＲは、１つ又は複数のプロセッサ、ストレージ、１つ又は複数のディスプレイ、キーボードなどの１つ又は複数のユーザインターフェース、ＮＦＣリーダー、バーコードスキャナなどを含むことができる。

図４の例において、ＥＣＲ１０は、直接、又は他のマーチャントシステム（図示せず）を介して、特別サービスプロバイダ（ＳＳＰ）システム１００、例えば税金還付オペレータ（ＴＲＯ）システム１００と通信するようにも構成される。

図４の例において、ＥＣＲ１０はＰＣＩ−ＤＳＳに準拠する必要がないため、ＥＣＲ１０はユーザのペイメントカードの全カード会員番号（ＰＡＮ）を受信しないように構成される。この点を念頭に置き、ユーザのペイメントカードを使用する取引は、電子資金決済支払端末（ＥＦＴ）２０を使用して実行される。図４の例において、ＥＣＲ１０とＥＦＴ２０との間で一定の情報が渡されるようにＥＣＲ１０とＥＦＴ２０との間に部分統合が提供されるが、図１の例を用いて説明したように、全ＰＡＮがＥＦＴ２０からＥＣＲ１０に送られることはない。これに代わり、図３の例と同様にスタンドアロン型ＥＦＴを提供することができる。

動作中、図４の例において、商品の購入がＥＣＲ１０によって処理され、支払合計が計算される場合、その後、商品の合計金額をＥＣＲ１０からＥＦＴ２０へと電子的に渡すことができる。例えばマーチャントは、１つ又は複数の商品を（例えば、ＥＣＲ１０のバーコードスキャナを使用して各商品上のバーコードをスキャンすることによって）入力した後、ＥＣＲ１０上のキーを操作して、ペイメントカードを使用する１つ又は複数の商品についての支払を可能にしてもよい。その後、ＥＣＲ−ＥＦＴメッセージプロトコルに従い、商品の合計金額を含むことが可能なメッセージがＥＣＲ１０からＥＦＴ２０へと送信される。この例では、選択された情報をＥＦＴ２０からＥＣＲ１０へと渡すこともできる。

ＥＦＴ２０は、図２を参照しながら上記でより詳細に説明したように、ＰＡＮ、有効期限などを含む、ペイメントカードについてのペイメントカードの詳細を、ペイメントカードから読み取るようにプログラミングすることができる。ＥＦＴ２０は、ＰＣＩ−ＤＳＳに準拠するように構成される。

その後、ＥＦＴ２０は、ＥＦＴ−ＰＳＰメッセージプロトコルに従い、商品の金額及び全ＰＡＮ、有効期限などを含む取引の詳細を渡すために、セキュアなチャネルを介して支払サービスプロバイダ（ＰＳＰ）システム３０と通信するように構成することができる。ＥＦＴ２０は、例えば承認要求メッセージをＰＳＰシステム３０に送信するように動作可能とすることができる。ＰＳＰシステム３０は、ＰＣＩ−ＤＳＳに準拠するように構成される。

ＰＳＰシステム３０は、マーチャント取得者（ＭＡ）システム４０と通信するように動作可能であり、次にＭＡシステム４０は、例えば、リアルタイムでの承認処理のため、及び、従来の様式でのバッチプロセスとしての決済処理のために、セキュアチャネルを介して、スキームシステム（ＭａｓｔｅｒＣａｒｄ、ＶＩＳＡなど）５０と通信するように構成される。ＭＡシステム４０及びスキームシステム５０は、ＰＣＩ−ＤＳＳに準拠するように構成される。

図４の例において、スキームシステム５０は、ＰＡＮ及びスキームシステム５０に固有であり、以てＰＲＥＦとＰＡＮとの間にマッピングを提供する取引のために、取引基準（ＰＲＥＦ）を生成するように動作可能である。

スキームシステム５０は、追加として、スキームシステム５０から（任意選択で、ＭＡシステム４０を介して）ＰＳＰシステム３０へのメッセージにＰＲＥＦを含めるように構成され、次にＰＳＰシステム３０は、メッセージ、例えば、承認応答メッセージ内のＰＲＥＦを、ＥＦＴ２０に渡すように構成される。

ＥＦＴ２０は、ＥＣＲ１０にＰＲＥＦを通信するが、全ＰＡＮは通信しないように動作可能である。上記で説明したプロセスの結果として、ＥＣＲ１０には、スキームシステム５０内でのマッピングにおいて情報がセキュアに保持された状態で、実際に全ＰＡＮが提供されることなく、全ＰＡＮを識別するために使用可能なＰＲＥＦが提供される。したがってＥＣＲ１０は、ペイメントカードについての全ＰＡＮを保持しないため、ＰＣＩ−ＤＳＳに準拠するように構成される必要はない。

ＥＣＲ１０は、直接、又は他のマーチャントシステム（図示せず）を介して、ＰＲＥＦ及びＰＳＰの識別情報をさらに識別する１つ又は複数のメッセージで、取引の詳細を、ＳＳＰシステム１００、例えばＴＲＯシステム１１０と通信するように構成される。特別サービスが税金還付サービスである場合、ＥＣＲ１０は、例えば図１を参照しながら説明したように、購入が行われるときに、従来の様式で紙及び／又は電子的な税金還付書式１２を生成するようにも動作可能とすることができる。

図４の例において、ＳＳＰシステム１００は、一方では、ＧＳＴ／ＶＡＴ及び手数料取引のためにマーチャントシステム１５０と、並びに、図１及び図２を参照しながら説明したように、ユーザの貸記及び／又は借記のためにＴＲＯ取得者システム７０とも、通信するように動作可能である。

しかしながら、ＥＣＲ１０はペイメントカードを使用して行われる取引に関して、ペイメントカードについての全ＰＡＮを保持しないため、ＥＣＲ１０は、ＴＲＯ取得者システム７０との取引を実施できるようにするために、ＰＡＮをＳＳＰシステム１００に渡すことができない。したがって、ＳＳＰシステム１００、又はより詳細には、ＳＳＰシステム１００のうちの支払取引を管理する責務を負う部分（例えば、図１のＴＲＯＴシステム１３０に対応するＴＲＯＴシステム）は、ユーザのペイメントカード勘定に関して貸記又は借記を実施できるようにするために、全ＰＡＮを取得しなければならない。

図４の例において、ＰＣＩ−ＤＳＳに準拠するように構成されたＳＳＰシステム１００のセキュア部分（例えば、図１のＴＲＯＴシステム１３０に対応するＴＲＯＴシステム）は、ＰＲＥＦと所与のＴＲＩＤのための取引に関連付けられた全ＰＡＮとの間のマッピングを取得するために、セキュア通信チャネルを介してスキームシステム（複数可）５０と通信するように構成される。したがってセキュア通信チャネルは、支払承認チャネル、及び、ＥＣＲ１０がＳＳＰシステム１００と通信する際に用いるチャネルによって形成される第１の通信チャネルに関連して、帯域外の第２の通信チャネルを形成する。

一例において、スキームシステム５０は、ＰＲＥＦと全ＰＡＮとの間のマッピングを、例えば、他のＰＲＥＦ及びＰＡＮについての他のマッピングと共に、バッチプロセスにおいて、ＳＳＰシステム１００のＰＣＩ−ＤＳＳに準拠する部分（例えば、図１のＴＲＯＴシステム１３０に対応するＴＲＯＴシステム）に通信するように動作可能である。その後、ＳＳＰシステム１００のＰＣＩ−ＤＳＳに準拠する部分（例えば、図１のＴＲＯＴシステム１３０に対応するＴＲＯＴシステム）は、同じくＰＣＩ−ＤＳＳに準拠しているためにマッピングを記憶するように動作可能であり、（例えば、ＳＳＰシステム１００の別の部分から、ユーザ勘定を借記又は貸記するためのメッセージを受信した場合、ＰＲＥＦから記憶されたＰＡＮへのマッピングをすでに有しており、これを使用してユーザのペイメントカード勘定を必要に応じて貸記又は借記することが可能となる。

別の例において、前述のようにバッチプロセスが使用されないか、又はＳＳＰシステム１００のＰＣＩ−ＤＳＳに準拠する部分（例えば、図１のＴＲＯＴシステム１３０に対応するＴＲＯＴシステム）が、ＰＲＥＦからＰＡＮへのマッピングをまだ記憶していないことを見つけた場合、所与のＰＲＥＦについてのマッピングのための要求メッセージをスキームシステム５０に送信し、スキームシステム５０からリアルタイムで応答メッセージを受信することができる。

したがって、図４の例において、ＳＳＰシステム１００のＰＣＩ−ＤＳＳに準拠する部分（例えば、図１のＴＲＯＴシステム１３０に対応するＴＲＯＴシステム）が、ユーザのペイメントカード勘定との貸記又は借記を実施できるようにするための情報は、マーチャントシステムがユーザのペイメントカードについての全ＰＡＮを知る必要なしに実施可能であり、以て、マーチャントのＥＣＲ１０は、ＰＣＩ−ＤＳＳに準拠するように構成される必要がない。

図４は、Ｆ１とラベル表示された破線を用いて、スキームシステム５０から、ＰＳＰシステム３０、ＥＦＴ２０、及びＥＣＲ１０を介して、ＳＳＰシステム１００のＰＣＩ−ＤＳＳに準拠する部分（例えば、図１のＴＲＯＴシステム１３０に対応するＴＲＯＴシステム）までのＰＲＥＦを含むメッセージのフローを示す。これは、ＰＡＮに固有であるがＰＡＮを識別しないトークン（すなわち、ＰＲＥＦ）を、それらのシステムを介して渡すことができることを意味する。結果として、こうしたメッセージはセキュアチャネルによって送信されるが、ＥＣＲ１０はＰＣＩ−ＤＳＳに準拠するように構成される必要はない。したがって、ＳＳＰシステム１００のＰＣＩ−ＤＳＳに準拠する部分は、第１の通信チャネルを介してマーチャントシステム（例えば、ＥＣＲ１０）から取引情報を受信し、取引情報はＰＲＥＦを含む。図４は、Ｆ２とラベル表示された太い破線を用いて、ＰＲＥＦを含むセキュアメッセージと、セキュアなＰＣＩ−ＤＳＳに準拠したチャネルを介するスキームシステム５０からＳＳＰシステム１００のＰＣＩ−ＤＳＳに準拠する部分（例えば、図１のＴＲＯＴシステム１３０に対応するＴＲＯＴシステム）への直接的なＰＡＮへのマッピングとを含む、フローも示す。したがって、ＳＳＰシステム１００のＰＣＩ−ＤＳＳに準拠する部分は、カード支払いを承認するための承認チャネルにおける支払承認チャネル（ＰＡＣ）システムから（本例では、スキームシステム５０から）、第２の通信チャネルを介するＰＲＥＦに関連付けられた、ＰＲＥＦからＰＡＮへのマッピングを受信する。前述のように、スキームシステム５０及びＳＳＰシステム１００のＰＣＩ−ＤＳＳに準拠する部分（例えば、図１のＴＲＯＴシステム１３０に対応するＴＲＯＴシステム）は、どちらもＰＣＩ−ＤＳＳに準拠するように構成される一方で、マーチャントのＥＣＲ１０はＰＣＩ−ＤＳＳに準拠するように構成される必要はない。

それぞれの図に示された例示の取引システムを参照すると、各図には、図示及び説明を容易にするために、単一のＥＣＲ１０、単一のＥＦＴ２０、単一のＰＳＰ３０、単一のＭＡシステム４０、単一のカードスキームシステム５０、及び／又は単一のカード発行者システム６０、及び／又は単一のＴＲＯ取得者システム７０などのみが示されているが、例示の取引システムは、１つ又は複数のネットワークによって相互接続された複数のこうしたデバイス及びシステムを含むことができる。また、説明したように、ＳＳＰシステム１００は、複数のＴＲＯＨ１１０、ＴＲＯＰ１２０、及びＴＲＯＴ１３０のシステムを含むことができる。

本明細書では、ペイメントカード、カード支払い、及びペイメントカード番号に総称的に言及しているが、本書との関連において、ペイメントカードという表現は、単に従来のプラスチック製の物理カード及び従来のプラスチック製のペイメントカードを用いる支払いを定義するものではなく、むしろ、例えば、電子カードウォレット又は支払チップを組み込み、例えばカード会員番号（ＰＡＮ）を使用する電子支払を許可する、モバイル通信デバイスを含む、任意のクレジット、デビット、及びプリペイドの支払デバイスを定義するものと理解されるであろうことに留意されたい。同様に、本書との関連において、カード支払いへの言及は、こうした支払デバイスを使用する支払いを言い表すものであることを理解されよう。また、本書との関連において、ペイメントカード番号への言及は、単に物理カードのＰＡＮを言い表すためではなく、むしろこうした支払デバイスと共に使用される任意のカード会員番号（ＰＡＮ）を言い表すために使用されるものであることを理解されよう。

説明した実施形態のうちの１つ又は複数の態様は、１つ又は複数のコンピュータシステムで実行された場合、本明細書で説明する１つ又は複数のコンピュータシステムの動作の方法を実施する、１つ又は複数のコンピュータプログラムによって実装可能である。１つ又は複数のコンピュータプログラムは、例えば、１つ又は複数の持続性ストレージ媒体上に保持される命令のような、１つ又は複数のコンピュータプログラム製品の形とすることができる。

当業者であれば、前述の開示を完全に理解したときに、多数の変形及び修正が明らかとなろう。下記の特許請求の範囲は、すべてのこうした変形及び修正並びにそれらの等価物を含むものと解釈されることが意図される。
［発明の項目］
［項目１］
特別サービスプロバイダ「ＳＳＰ」の少なくとも１つのコンピュータシステムにおいて、マーチャントシステムから第１の通信チャネルを介して取引情報を受信するステップであって、前記取引情報は、支払承認チャネルシステム、「ＰＡＣ」システムによって生成される固有参照「ＰＲＥＦ」を含み、前記ＰＡＣシステムは支払いを承認するための承認チャネルにおけるシステムであり、前記ＰＲＥＦは、前記ＰＲＥＦと、前記取引又は前記取引に関連付けられたカード会員番号「ＰＡＮ」のうちの１つとを生成した、前記ＰＡＣシステムに固有である、取引情報を受信するステップと、
前記ＳＳＰの前記少なくとも１つのコンピュータシステムにおいて、前記承認チャネル内の前記ＰＡＣシステムから第２の通信チャネルを介して、前記ＰＲＥＦから前記ＰＲＥＦに関連付けられた前記ＰＡＮへのマッピングを受信するステップと、
前記ＳＳＰの前記少なくとも１つのコンピュータシステムによって、前記マッピングに従い、前記ＰＲＥＦに関連付けられた前記ＰＡＮを使用して前記取引情報に関連付けられたサービスを処理するステップと、
を含む、コンピュータ実装方法。
［項目２］
前記マーチャントシステムは前記ＰＡＮの受信又は処理をしない、項目１に記載の方法。
［項目３］
前記ＳＳＰの前記少なくとも１つのコンピュータシステムは、前記ＰＲＥＦから、前記ＰＲＥＦを生成した前記ＰＡＣシステムからの前記ＰＲＥＦに関連付けられた前記ＰＡＮへの前記マッピングを受信する、項目１又は２に記載の方法。
［項目４］
前記ＰＲＥＦを生成した前記ＰＡＣシステムは支払サービスプロバイダ「ＰＳＰ」システムである、項目１〜３のいずれか一項に記載の方法。
［項目５］
前記ＰＲＥＦは前記取引及び前記ＰＳＰシステムに固有であり、前記ＰＲＥＦは、前記ＰＳＰシステムによって保持されている情報を使用して前記取引のために前記ＰＡＮにマッピングする、項目４に記載の方法。
［項目６］
前記ＰＲＥＦは前記ＰＡＮ及び前記ＰＳＰシステムに固有であり、前記ＰＲＥＦは、前記ＰＳＰシステムによって保持されている情報を使用して前記取引のために前記ＰＡＮにマッピングする、項目４に記載の方法。
［項目７］
前記ＰＲＥＦはカードスキームシステムによって生成される、項目１〜３のいずれか一項に記載の方法。
［項目８］
前記ＰＲＥＦは前記取引及び前記カードスキームシステムに固有であり、前記ＰＲＥＦは、前記カードスキームシステムによって保持されている情報を使用して前記取引のために前記ＰＡＮにマッピングする、項目７に記載の方法。
［項目９］
前記ＰＲＥＦは前記ＰＡＮ及び前記カードスキームシステムに固有であり、前記ＰＲＥＦは、前記カードスキームシステムによって保持されている情報を使用して前記取引のために前記ＰＡＮにマッピングする、項目７に記載の方法。
［項目１０］
前記ＳＳＰの前記少なくとも１つのコンピュータシステムは、前記ＳＳＰの前記少なくとも１つのコンピュータシステムから前記ＰＡＣシステムへの要求メッセージに応答して、前記ＰＲＥＦから前記ＰＲＥＦに関連付けられたＰＡＮへの前記マッピングを受信し、前記要求メッセージは前記ＰＲＥＦを含む、前記項目１〜９のいずれか一項に記載の方法。
［項目１１］
前記ＳＳＰの前記少なくとも１つのコンピュータシステムは、前記マッピングが、前記ＰＡＣシステムから前記ＳＳＰの前記少なくとも１つのコンピュータシステムへとプッシュされる結果として、前記ＰＲＥＦから前記ＰＲＥＦに関連付けられたＰＡＮへの前記マッピングを受信する、項目１〜９のいずれか一項に記載の方法。
［項目１２］
支払端末が、前記支払端末によってキャプチャされたＰＡＮを含む支払取引情報をＰＳＰシステムへとルーティングすることに応答して、前記ＰＳＰシステムは前記取引のための前記ＰＲＥＦを前記支払端末に戻す、前記項目１〜１１のいずれか一項に記載の方法。
［項目１３］
前記ＰＲＥＦは、前記支払取引の承認の際に前記支払端末から前記マーチャントシステムに提供される、項目１０に記載の方法。
［項目１４］
前記支払端末は、前記取引の承認を確認する情報と共に、前記ＰＲＥＦを前記マーチャントシステムに転送するように構成される、項目１３に記載の方法。
［項目１５］
前記支払端末は、前記ＰＲＥＦ及び／又は前記ＰＲＥＦを表すコードを支払伝票上に印刷し、前記ＰＲＥＦを前記マーチャントシステムに転送するために、前記マーチャントシステムのスキャナによって、前記ＰＲＥＦ及び／又は前記ＰＲＥＦを表す前記コードをスキャンするように構成される、項目１３に記載の方法。
［項目１６］
前記ＳＳＰの前記少なくとも１つのシステムは、税金還付サービスプロバイダの少なくとも１つのシステムである、前記項目１〜１５のいずれか一項に記載の方法。
［項目１７］
前記ＳＳＰの前記少なくとも１つのシステムは、購入された商品が、購入の際、税金を課されなかった場合、税金還付取引の発行の所与の時間内に輸出されたかどうかを判定するように、且つ、前記購入された商品について税金を回収するために前記ＰＡＮを使用して支払取引を開始するように、動作可能である、項目１６に記載の方法。
［項目１８］
１つ又は複数のコンピュータシステムで実行された場合、前記項目１〜１７のいずれか一項に記載の方法を実装する、１つ又は複数のコンピュータプログラム。
［項目１９］
項目１〜１７のいずれか一項に記載の方法を実施するように構成されるとともにプログラミングされた１つ又は複数のコンピュータを備えるシステム。

Claims (19)

1. 特別サービスプロバイダ「ＳＳＰ」の少なくとも１つのコンピュータシステムにおいて、マーチャントシステムから第１の通信チャネルを介して取引に関する取引情報を受信するステップであって、前記取引情報は、支払承認チャネルシステム、「ＰＡＣ」システムによって生成される固有参照「ＰＲＥＦ」を含み、前記ＰＡＣシステムは支払いを承認するための承認チャネルにおけるシステムであり、前記ＰＲＥＦは、前記ＰＲＥＦと、前記取引又は前記取引に関連付けられたカード会員番号「ＰＡＮ」のうちの１つとを生成した、前記ＰＡＣシステムに固有である、取引情報を受信するステップと、
   前記ＳＳＰの前記少なくとも１つのコンピュータシステムにおいて、前記承認チャネル内の前記ＰＡＣシステムから第２の通信チャネルを介して、前記ＰＲＥＦから前記ＰＲＥＦに関連付けられた前記ＰＡＮへのマッピングを受信するステップと、
   前記ＳＳＰの前記少なくとも１つのコンピュータシステムによって、前記マッピングに従い、前記ＰＲＥＦに関連付けられた前記ＰＡＮを使用して前記取引情報に関連付けられたサービスを処理するステップと、
   を含む、コンピュータ実装方法。
2. 前記マーチャントシステムは前記ＰＡＮの受信又は処理をしない、請求項１に記載の方法。
3. 前記ＳＳＰの前記少なくとも１つのコンピュータシステムは、前記ＰＲＥＦから、前記ＰＲＥＦを生成した前記ＰＡＣシステムからの前記ＰＲＥＦに関連付けられた前記ＰＡＮへの前記マッピングを受信する、請求項１又は２に記載の方法。
4. 前記ＰＲＥＦを生成した前記ＰＡＣシステムは支払サービスプロバイダ「ＰＳＰ」システムである、請求項１〜３のいずれか一項に記載の方法。
5. 前記ＰＲＥＦは前記取引及び前記ＰＳＰシステムに固有であり、前記ＰＲＥＦは、前記ＰＳＰシステムによって保持されている情報を使用して前記取引のために前記ＰＡＮにマッピングする、請求項４に記載の方法。
6. 前記ＰＲＥＦは前記ＰＡＮ及び前記ＰＳＰシステムに固有であり、前記ＰＲＥＦは、前記ＰＳＰシステムによって保持されている情報を使用して前記取引のために前記ＰＡＮにマッピングする、請求項４に記載の方法。
7. 前記ＰＲＥＦはカードスキームシステムによって生成される、請求項１〜３のいずれか一項に記載の方法。
8. 前記ＰＲＥＦは前記取引及び前記カードスキームシステムに固有であり、前記ＰＲＥＦは、前記カードスキームシステムによって保持されている情報を使用して前記取引のために前記ＰＡＮにマッピングする、請求項７に記載の方法。
9. 前記ＰＲＥＦは前記ＰＡＮ及び前記カードスキームシステムに固有であり、前記ＰＲＥＦは、前記カードスキームシステムによって保持されている情報を使用して前記取引のために前記ＰＡＮにマッピングする、請求項７に記載の方法。
10. 前記ＳＳＰの前記少なくとも１つのコンピュータシステムは、前記ＳＳＰの前記少なくとも１つのコンピュータシステムから前記ＰＡＣシステムへの要求メッセージに応答して、前記ＰＲＥＦから前記ＰＲＥＦに関連付けられたＰＡＮへの前記マッピングを受信し、前記要求メッセージは前記ＰＲＥＦを含む、請求項１〜９のいずれか一項に記載の方法。
11. 前記ＳＳＰの前記少なくとも１つのコンピュータシステムは、前記マッピングが、前記ＰＡＣシステムから前記ＳＳＰの前記少なくとも１つのコンピュータシステムへとプッシュされる結果として、前記ＰＲＥＦから前記ＰＲＥＦに関連付けられたＰＡＮへの前記マッピングを受信する、請求項１〜９のいずれか一項に記載の方法。
12. 支払端末が、前記支払端末によってキャプチャされたＰＡＮを含む支払取引情報をＰＳＰシステムへとルーティングすることに応答して、前記ＰＳＰシステムは前記取引のための前記ＰＲＥＦを前記支払端末に戻す、請求項１〜１１のいずれか一項に記載の方法。
13. 前記ＰＲＥＦは、前記取引の承認の際に支払端末から前記マーチャントシステムに提供される、請求項１０に記載の方法。
14. 前記支払端末は、前記取引の承認を確認する情報と共に、前記ＰＲＥＦを前記マーチャントシステムに転送するように構成される、請求項１３に記載の方法。
15. 前記支払端末は、前記ＰＲＥＦ及び／又は前記ＰＲＥＦを表すコードを支払伝票上に印刷し、前記ＰＲＥＦを前記マーチャントシステムに転送するために、前記マーチャントシステムのスキャナによって、前記ＰＲＥＦ及び／又は前記ＰＲＥＦを表す前記コードをスキャンするように構成される、請求項１３に記載の方法。
16. 前記ＳＳＰの前記少なくとも１つのシステムは、税金還付サービスプロバイダの少なくとも１つのシステムである、請求項１〜１５のいずれか一項に記載の方法。
17. 前記ＳＳＰの前記少なくとも１つのシステムは、購入された商品が、購入の際、税金を課されなかった場合、税金還付取引の発行の所与の時間内に輸出されたかどうかを判定するように、且つ、前記購入された商品について税金を回収するために前記ＰＡＮを使用して支払取引を開始するように、動作可能である、請求項１６に記載の方法。
18. １つ又は複数のコンピュータシステムで実行された場合、請求項１〜１７のいずれか一項に記載の方法を実装する、１つ又は複数のコンピュータプログラム。
19. 請求項１〜１７のいずれか一項に記載の方法を実施するように構成されるとともにプログラミングされた１つ又は複数のコンピュータを備えるシステム。

Images