JP6595337B2 - 電子支払取引の紛争解決を提供するためのシステム及び方法 - Google Patents

Description

（関連出願の相互参照）
本出願は、現在、米国特許第７，９４１，３５２号である２００８年１２月２３出願の米国特許出願第１２／３４３，１９５号の継続出願である、２０１１年５月１０日出願の米国特許出願第１３／１０４，９０７号の一部継続出願であり、各々が引用により本明細書に明示的に組み入れられる。

（技術分野）
本発明は、一般的に、限定されるものではないが、デビットカード、ＡＣＨ、ｅＣｈｅｃｋ、ＬＥＣトランザクション等を含む、クレジットカード又は他の電子支払取引の紛争(dispute)解決を提供するための方法及びシステムに関する。具体的には、本発明は、カード発行者又は他の電子支払プロバイダが、適切な取引パラメータが満足された場合に、定期的支払(recurring payment)プログラムからカード保有者又は他の購入者を自動的に除外する及び／又は係争中のクレジットカード取引のカード保有者にクレジットを発行するための、及び取引パラメータが満足されたかった場合にはこのようなクレジット要求を拒否するのを可能にするための方法及びシステムを提供する。

クレジットカード、及びデビットカードやチェックカードのような他の支払手段は、保有者によって市場で商品及びサービスを購入するために広く使用される。２００７年には米国のカード保有者の全支払の少なくとも３５％が、「プラスチック」（すなわち、クレジット又はデビットカード）を介して行われると予測され、この比率が２０１０年までには少なくとも４９％に上昇することが推定されている。現在のこれらの取引の年間金額は４０００億ドルを超える。クレジットカード取引はカード保有者には便利であるが、クレジットカード取引は、加盟店及びクレジットカード発行者に特別な問題セットを提示する。この問題の１つは、カード保有者がクレジットカード取引に異議を唱えた場合に発生し、当該紛争を調査して解決する際に多大な時間と資源の消費を必要とする。

電子支払プロバイダを使用するカード保有者及び他の購入者は、請求(billing)の紛争を解決するために加盟店に直接連絡するのではなくカード発行者に直接頼ることが多くなっている。このカード保有者により加盟店へ事前に全く接触せずに開始されるチャージバックの傾向は、加盟店が解決処理に直接含まれない場合、カード発行者が加盟店の代わりに解決行動を取る必要があるので、当該紛争の解決が不十分になり、したがって解決処理の複雑さ、時間及び費用が増える。

クレジットカード及び他の電子支払プロバイダ取引の紛争によって引き起こされる問題を理解するために、電子支払プロバイダ処理の簡潔な概要が必要である。クレジットカードは、発行銀行によってカード保有者に提供される。カード保有者がクレジットカードを使用した加盟店との取引を締結する場合、発行銀行は、取引が認証された時点で加盟店への支払を行う。

毎月、クレジットカードユーザに、カードで行われた購入及び支払うべき総合収支を記録した明細書が送られる。公正信用請求法によれば、カード保有者は、カード保有者が間違っていると思う明細書のいずれの課金にも異議を唱えることができる。カード保有者は、発行銀行に接触する前に状況の修復をめぐって加盟店に接触してもよく又は接触しなくてもよい。

チャージバック処理は、クレジットカード会社毎に幾分異なるが、一般的には、図１に示すシーケンスに従う。ステップ１で、クレジットカード保有者がその発行銀行との取引に異議を唱える。ステップ２で、発行銀行は、チャージバック要求が有効であるか否かを判断するために調査を行い、有効でない場合、チャージバックを拒否する。ステップ３で、課金された金額に相当する仮のクレジットがユーザの口座に戻される。ステップ４で、発行銀行がチャージバック処理を開始して、加盟店の銀行からチャージバック購入に相当するクレジットを取得する。ステップ５で、加盟店の銀行は、有効であるか否かを決定するためにチャージバック要求を調査して、有効でない場合、チャージバックが発行銀行に戻される。チャージバックが有効であると加盟店の銀行が決定した場合、ステップ６で、チャージバック額が、加盟店の銀行口座から移動され、加盟店の銀行が、書面通知を加盟店に提示する。ステップ７で、加盟店に、チャージバックに反論する機会が与えられ、その証拠書類が満足のいく場合、チャージバックは拒否され、カード保有者は、再度、販売に対して課金される。チャージバックが拒否されなかった場合、チャージバックが成功して処理が完了する。

本発明は、カード発行者又は他の電子支払プロバイダに、顧客の加盟店との紛争に対する迅速で望ましい効率的な解決を得るためのシステム及び方法を提供し、したがって、優れた顧客サービスを提供すると同時に運営費用を低減する。また、本発明は、クレジットカード、デビットカード、ＡＣＨ、ｅＣｈｅｃｋ、モバイル決済、ＬＥＣ等の取引のようなカード発行者又は他の電子支払プロバイダによって提供される様々な種類の電子支払の１つ又はそれ以上と同時に、及びクレジットカード電子支払取引内のような電子支払取引の各種類内の１つ又はそれ以上のペイメントブランド又はネットワークと同時に使用することができ、Ｖｉｓａ、ＭＣ、Ａｍｅｘ、Ｄｉｓｃｏｖｅｒ及びＪＣＢカード取引との同時使用を可能にする。したがって、本発明は、クレジットカード、デビットカード、ＡＣＨ、ｅＣｈｅｃｋ、モバイル決済、ＬＥＣ等の複数の様々な種類の電子支払ネットワーク、及び電子支払取引の各種類内の１つ又はそれ以上のペイメントブランド又はネットワークとの複数の接続性を提供する。

本発明は、発行者が、最小資源消費によってカード保有者クレジット処理における迅速なターンアラウンドの達成を可能にする。定期的支払プログラム加盟店では、カード保有者が、定期的支払プログラムから除外され、将来の認証要求の提出を阻止し、したがって将来の紛争の可能性を無くす。これによって本発明は、カード保有者取引の紛争を解決するためにカード発行者に必要になる時間と費用を大幅に低減すると同時に、望ましい解決をカード保有者に提供する。

図２及び３に示す１つの好ましい実施形態において、本発明のシステム及び方法を例証する。支払手段ホルダが、カード発行者への紛争通知を開始し、インターネット、郵便、ファックス、電子メール、対面によって、ＳＭＳ移動テキスト、移動電話を介して、又は電話によって、電話のタッチトーンキーパッドを介して、又は口頭で応答することによって、必要な取引情報を提供し、本システムは、音声データをコンピュータ可読データに変換するために音声認識ソフトウェア（ＩＶＲ）を利用する。

カード発行者又は、スキャナ又はＩＶＲシステムのようなカード発行者端末に関連付けられるデバイスが、取引情報をカード発行者処理システムによる処理のためのカード発行者端末に入力する。

カード発行者処理システムは、適格な取引の待ち行列を処理のための紛争解決システムサーバに送信する。この要求は、クレジットカード番号、取引額、取引日付及び加盟店識別のような取引に関する紛争の判定に必要な取引データを含む。紛争解決システムは、取引が本システムの下での解決に適しているか否かを決定し、適している場合、カード保有者への取引に関するクレジットの発行を指示して、取引を取り消し、紛争解決の結果の報告をカード発行者及び発生元加盟店に送信する。本発明は、複数のカードの種類、カード発行者、加盟店、及び、ＡＣＨ、モバイル決済、ＬＥＣ請求等の支払種類と共に使用することができる。

別の関連する態様において、本明細書では、パートナー／アグリゲータプラットフォームによってアフィリエイトされる顧客と加盟店との間の取引に関する、顧客と電子支払プロバイダとの間の照会又は紛争を解決するための加盟店又はパートナーベースの方法及びデバイスを説明する。１つのアプローチにおいて、本方法は、パートナーエンティティ／プラットフォームで、照会／紛争事象の通知を受信するステップを含むことができる。本方法は、取引に関するデータポイントを取得するステップ及びデータポイントに基づいて取引を特定するステップを含むことができる。本方法は、取引を払い戻すステップ、取引を取り消すステップ、及び／又は将来の課金／定期的課金を阻止するステップを含むことができる。関連する態様において、電子デバイス（例えば、パートナー／アグリゲータサーバ又はこれらの構成要素）は、上述された方法を実行するよう構成することができる。

チャージバック処理を示す概略図である。 本発明の好ましい実施形態のシステム構成要素を示す概略図である。 本発明による特定の方法を示す系統線図である。 紛争解決ＡＰＩをパートナーに統合するための例示的な方法を示す。 事象通知及び紛争／照会処理のための例示的な呼出しの系統線図を示す。 例示的な事例ステータスライフサイクルを示す。 パートナーエンティティで実行される例示的な紛争解決方法を示す。 図７の方法の別の任意選択的な態様を示す。 図７の方法の別の任意選択的な態様を示す。 図７−９の方法によるパートナープラットフォームによる紛争解決参加のための例示的な装置を示す。

同じ参照数字が同じ要素を示す図を参照する。以下の説明では、プログラミング、ソフトウェアモジュール、ユーザ選択、ネットワークトランザクション、データベースクエリー、データベース構造等の他の特定の具体的な詳細を、本発明の実施形態の完全な理解のために提供する。しかしながら、当業者であれば、本発明が、特定の詳細の１つ又はそれ以上が無くても、又は他の方法、構成要素、材料等と共に実施できることを理解するであろう。場合によっては、公知の構造、材料、又は動作は、本発明の態様を曖昧にしないように詳しく図示又は記述していない。更に、説明する特徴、構造、又は特性は、１つ又はそれ以上の実施形態に何らかの適切な方式で組み合わせることができる。

図２及び３に示す１つの好ましい実施形態において、本発明のシステム及び方法を例証する。図２に示すように、本発明のシステムは、好ましくは紛争解決サーバ１０を含み、紛争解決サーバ１０は、カード発行者のコンピュータシステムのアプリケーションプログラミングインタフェースによってカード発行者のコンピュータ処理システム１２にリンクする。このインタフェースは、クレジットカード番号、クレジットカード期限日付、カード保有者名及び住所、取引額、及び、加盟店名、電話番号、ＵＲＬ、又は加盟店アクワイアラ銀行識別のような加盟店識別を含む、紛争解決処理を実行するのに必要な取引の詳細を取得する。

このインタフェースは、インターネットといったデータ伝送リンクによって、又は、例えば、ＦＴＰ、ＳＦＴＰ、ＦＴＰＳ、ＨＴＴＰ、ＨＴＴＰＳ、ＴＥＬＮＥＴ、ＳＳＨ、ＸＭＬ、ＲＥＳＴ、又はＪＳＯＮのような他の電子ファイル転送プロトコルによって紛争解決サーバ１０に接続される。

このインタフェースは、好ましくは、インターネット、電話回線又はネットワークケーブルのようなデータ伝送リンクによって紛争解決サーバ１０に接続される。このインタフェースは、バッチファイルで、又は、例えば、ＦＴＰ、ＳＦＴＰ、ＦＴＰＳ、ＨＴＴＰ、ＨＴＴＰＳ、ＴＥＬＮＥＴ、ＳＳＨ、ＸＭＬ、ＲＥＳＴ、又はＪＳＯＮのような電子ファイル転送プロトコルを使用する単一の取引記録によって、サーバに取引データを転送することができる。「夜間」バッチファイル転送又はアプリケーションプログラミングインタフェース（ＡＰＩ）によるリアルタイムの転送のいずれかをこれらのファイルに使用することができる。

若しくは、本発明のシステムは、インターネット又は他の通信ネットワークを介して紛争解決プログラムサーバ１０に接続されたカード発行者のコンピュータ１２で動作することができる。代替的に又は追加的に、本明細書で説明する技術は、例えば、加盟店エンティティ（例えば、図２の加盟店の処理デバイス２４、又は図４の加盟店プラットフォーム１２０）、パートナーエンティティ（図４のパートナープラットフォーム１３０など）、又は同様のもの、又はこれらの組合せのような本システムにおける１つ又はそれ以上のエンティティで動作することができる。

図２に示すように、紛争を起こしたカード保有者は、電話１４、ファックス１６によって、又はメール、ＳＭＳ、若しくは携帯電話、標準的な地上の通信線、ＰＤＡ、若しくはページャのようなコンピュータ１８若しくは移動デバイス２０を使用したオンライン若しくは他の電子媒体によって、カード発行者に関連の情報を提出することができる。カード保有者は、代わりに対面通知又は同様のものを介して紛争情報を提出することができる。

カード発行者及び／又はカード保有者は、係争中の取引に関係付けられるデータを受信及び処理するようプログラムすることができるＰＣ又はラップトップのような処理デバイス１２を備えるか、又はそうでなければこれと通信することができる。紛争データは、キーボード又はマウスのような入力デバイスを使用してカード発行者の従業員によって手動で適切な電子フォーマットに入力することができ、又は電話通知の場合にはＩＶＲによって、郵便若しくはファックス通知の場合にはＯＣＲによってカード保有者の入力から直接、若しくはオンライン提出の場合には電子入力から直接変換することができる。

例えば、カード発行者処理デバイス１２は、１つ又はそれ以上の紛争項目を含むバッチファイルを前述のデータ伝送リンク及び電子ファイル転送プロトコルの１つを介して紛争解決システムサーバ１０に送信することができる。関連の態様において、発行者デバイス１２と紛争解決サーバ１０との間のＡＰＩ及びＢＡＴＣＨベースの通信方式をサポートすることができる。紛争解決システムは、要求を処理して、同じリンクを介して応答をカード発行者処理デバイス１２に戻すことができる。

紛争解決システムは、前述のデータ伝送リンク及び電子ファイル転送プロトコルを介して、発生元加盟店の処理デバイス２４への係争中の取引に関する応答を生成することもできる。例えば、紛争解決システムサーバ１０は、加盟店のための支払処理システムとしても機能することができる。したがって、加盟店のための支払処理システムの能力において、紛争解決システムサーバ１０は、加盟店から取引を受け取り、受け取った取引をアクワイアラ(acquirer)２２に転送して、取引データを記憶する。当技術分野で公知のように、アクワイアラ２２は、加盟店に加盟店の顧客から発生した電子取引の処理のための加盟店処理口座を提供する銀行又は金融機関である加盟店のアクワイアリング銀行である。アクワイアラ２２は、取引情報を、発行者とアクワイアラを接続する、Ｖｉｓａ、ＭＣ、Ａｍｅｘ、Ｄｉｓｃｏｖｅｒ及びＪＣＢのような支払ネットワークに送信して、清算及び決済サービスを提供して発行者とアクワイアラとの間で支払情報を転送する。紛争解決システムサーバ１０が加盟店のための支払処理システムとしても機能するので、本実施例は、進行中の定期的取引を終了させるステップを含む、係争中の顧客に対する加盟店からの将来の取引を即座に拒否するという利点を提供する。これは当該紛争取引の再発を阻止し、一方で現在係争中の取引に関する紛争が解決される。別の実施例では、紛争解決サーバ１０は、加盟店のための支払処理システムとして機能しなくてもよい。更に別の実施例では、紛争解決サービス又は技術は、紛争解決サーバ１０以外のネットワークエンティティ（例えば、図４のパートナープラットフォーム１３０及び／又は加盟店プラットフォーム１２０）を介して実施することができ、ネットワークエンティティは、加盟店のための支払処理システムとして機能しない。例えば、ネットワークエンティティは、加盟店と通信するパートナープラットフォーム又は同様のもの（例えば、図２の加盟店２４又は図４の加盟店プラットフォーム１２０）とすることができ、加盟店は、アクワイアラ／支払ネットワークによって直接支払処理に対処して紛争解決を行う。加盟店は、紛争又は照会を解決するために実行される処理に関するデータ／結果をネットワークエンティティに提供することができる。

図３に示すように、この処理はステップ４０で始まり、カード保有者は、紛争通知をカード発行者に提供することによって紛争を開始する。カード保有者は、電話、郵便、ファックス、電子メール又はオンラインによって発行者に紛争内容を提出することができる。オンライン提出は、ポップアップ形式でカード保有者に提供されるオンラインステートメントのリンクを提供することでカード発行者によって促進される。このリンクは、カード保有者を、カード発行者の処理システムに、又は代替的に取引が開始された加盟店に直接接続することができる。この後者の代替案により、カード保有者が加盟店と直接紛争を調停することが可能になる。

カード保有者は、チャージバック紛争テンプレートを完成すると、提出ボタンを選択することができ、本システムは、テンプレートを使用して、課金に異議を唱えるために必要な情報の全てを含む、一般的な課金紛争フォームを生成する。

この情報は、カード保有者が以下のステートメントと一緒に提出することができる：
（ステートメント）
「私は、自分の口座に行われた課金を調べた結果、以下の理由の項目で異議を申し立てます：
１．私も私のカードの使用を私によって許可されたいずれの人も、上記に列挙された料金を使っていません。加えて、私も私によって許可された何人も、この取引によって表される商品及びサービスを受け取っていません。（あなたが販売を認めない場合は、この選択肢を選択して直ちに顧客サービスを呼び出して下さい。）
２．私は加盟店との取引に参加しましたが、私は、私も私のカードの使用を許可した何人も関わっていない総額＄の取引を請求されました。私は、自分のカードを全て手元に所有しています。許可された販売伝票のコピーを同封します。
３．私は、私に発送されたはずの品物を受け取っていません。配達予定日は（ｍｍ−ｄｄ−ｙｙ）でした。私は（ｍｍ−ｄｄ−ｙｙ）に加盟店と連絡を取り、加盟店の応答は：（あなたを手助けするために、加盟店は連絡を受ける必要がある）でした。」
当然ながら、当技術で理解されるように、後で説明する紛争理由コード(Dispute Reason Codes)のリストに例証されるように、行使される紛争には多くの他の根拠が存在する可能性がある。

ステップ４２で、カード発行者は、カード発行者から受け取った紛争通知に関するデータを入力する。紛争データは、以下のような取引に関する情報を含む：
名前：
日付：（ｍｍ−ｄｄ−ｙｙ）
口座番号：―――
紛争金額：＄
参照番号＃：
加盟店：
紛争理由：

ステップ４４で、紛争通知を受領すると、発行者プロセッサ１０が、交換データから発行者が抽出した係争中の取引の詳細を、紛争解決システムによって提供された参加加盟店の識別子のテーブルと突き合わせること又は比較することによって、紛争又は照会が紛争解決システムによって処理するのに適格であるか否かを判断する。このテーブルは、データ送信によって定期的に更新することができ、好ましくはＦＴＰＳ（ＳＳＬを通じたＦＴＰ）のようなセキュアバッチファイル送信によって更新することができるが、エクセルスプレッドシートファイルの電子メール、又はＤＶＤ若しくはＣＤ／ＲＯＭを含む電子記憶媒体の物理的転送のような他の種類のファイル送信を使用することができる。別の実施例では、発行者１２はオンラインポータル又は同様のものを使用でき、紛争又は照会が紛争解決システムによる処理に適格であるか否かをチェックする。発行者は、加盟店記述子、電話番号、又は同様のものを入力することができ、紛争／照会事例が、紛争解決システム又はネットワークの処理又は参加に適格であるか否かを判断する。

好ましくは、ステップ４６、４８及び５０において、カード発行者システムは、ステップ４６で取引が以前に払い戻されたか又は加盟店及び／若しくは紛争解決システムプロバイダによって払い戻されたか否か、ステップ４８で取引が紛争解決システム紛争要求の日付から１２０日などの所定の間隔より長い中央処理日付（ＣＰＯ）を有するか否か、及びステップ５０でこのような場合にチャージバック権が加盟店に対してカード発行者に存在しない場合にチャージバック保護を受け取る加盟店から取引が発生したか否かのような所定の取引レベル適格性要件に基づいて、不適格な取引の紛争をふるいにかける。当業者によって理解できるように、ステップ４６、４８及び５０でテストされる適格性条件は、その特定のプリファレンスに応じて、種々のカード発行者に対して様々とすることができる。例えば、適格性条件は、カード発行者のプリファレンスに応じて発生元の加盟店のアイデンティティに従って決定することもできる。更に、取引が紛争解決システム紛争要求の日付から１２０日などの所定の最大間隔より長い中央処理日付（ＣＰＯ）を有するか否かも、適格性を判断するために使用することができる。当業者によって理解できるように、取引の日付から紛争解決システム紛争要求の日付までの１２０日の最大間隔は、例示的に提示され、この間隔は、カード発行者が必要に応じて調整することができる。

ステップ５２で、加盟店適格性テーブル（及び／又はマニュアル適格性検証）を参照した場合に一致を戻し、取引レベル条件に違反しない紛争は、紛争解決システムに適格であるとしてフラグ付けされ、紛争解決システムによる処理の前に発行者のシステム内の別々の待ち行列にソートされる。紛争解決システム要求ファイルは、以下に指定される発行者によって生成及び供給することができ、紛争解決システム処理のためにインターネットを介して送信することができる。別の実施例では、発行者は、この事例をＡＰＩ送信又は同様のものを介して紛争解決システムに送信することができる。

データ種類コードの以下のチャートは、上記のテーブルに適用される。

要求ファイルは、取引紛争の理由を指定する紛争理由コードを包含する。以下の例示的な事前に定義された紛争理由コードが、２つの主なカードネットワークによって認識されている：

若しくは、ステップ５４で、テーブルの有資格加盟店識別記述子との「不一致」を戻すか又は取引レベル条件に適合しない紛争は、発行者の従来の紛争解決手順を介して処理されるようフラグ付けされる。

適格な紛争の所定の数が記録されると、又は所定の間隔で、カード発行者システムは、１つ又はそれ以上の紛争項目を含むバッチファイルをＦＴＰＳのようなファイル転送システムに送信することができる。別の実施例では、カード発行者システムは、ＡＰＩ又は同様のものを介して紛争項目を送信することができる。ステップ５６で、紛争解決システムは、ファイルをピックアップして、ＦＴＰＳシステムからファイルを取り除き、ファイルを紛争解決システムにロードすることになる。別の実施例では、紛争解決システムは、ＡＰＩ又は同様のものを介して応答を発行者に戻すことができる。次のステップでは、紛争解決システムはファイルを処理して、応答をＦＴＰＳシステムのある位置に戻す。

ステップ５８で、紛争解決システムプロセッサ１０は、係争中の取引からの加盟店識別記述子を参加加盟店の識別子のテーブルに対して突き合わせることによって、紛争が紛争解決システム取引による処理に対して適格であるか否かを確認する。

ステップ６０で、紛争解決システムプロセッサ１０は、取引が紛争解決システム処理に適格であるか否かを判断する。例えば、この適格性は、紛争要求取引詳細を販売取引データベースの記録に対して突き合わせる試みによって判定することができる。別の実施例では、適格性は、紛争データをパートナー（例えばパートナープラットフォーム１３０）に送信することによって判断することができ、データベース又は同様のものによってこのようなチェックを実行し、販売取引に関するデータが紛争解決システム内に記憶されることはない。この販売取引データベースは、参加加盟店によって開始された取引を表し、必要に応じて、加盟店からカード保有者へ払い戻しが発行される。図３のステップ６０に示すように、販売取引データベースに、参加加盟店からの取引に関するデータを読み込むことができ、この取引は、当初、紛争解決システムプロセッサ１０によって処理されている。１つの実施例では、紛争解決システムプロセッサ１０の取引ゲートウェイを介して処理された取引だけが、紛争解決システム処理に適格であり、ステップ６０で選択される。任意選択的に、販売取引データベースに、参加加盟店によって開始された取引を表わすデータのバルクファイル転送を読み込むことができる。このデータは、加盟店自体によって、又はアクワイアラ、カードアソシエーション、若しくは他のエンティティから提供することができる。したがって、適格な販売取引データベースに対して紛争要求取引詳細を突き合わせる試みによって、紛争解決システム処理に対する適格性を判断することができ、これによって加盟店からカード保有者に払い戻しを発行する機能が存在する取引だけが、紛争解決システムで処理される。

ステップ６２で、加盟店適格性テーブルを参照した場合に「一致」を戻し、本来は紛争解決システムを介して処理された場合に販売取引データベースの記録に一致する、取引の紛争要求は、「未解決」としてタグ付けされ、紛争解決システムによる更なる処理のために待ち行列に入れられる。紛争要求は、以下のテーブルに従って識別される：

テーブルで識別されたクレジット要求を拒否するための基準の１つは、取引が紛争解決システム紛争要求の日付から１２０日以上の中央処理日付（ＣＰＯ）を有することである。上述したように、取引から紛争解決システム紛争要求の日付までの１２０日間の最大間隔は例示的であり、この間隔は、カード発行者によって必要に応じて調整することができる。

若しくは、ステップ６４で、テーブルの有資格加盟店識別記述子との「不一致」を戻すか又は本来、紛争解決システムを介して処理されていない紛争は、「不一致」としてタグ付けされ、ステップ６６で、失敗したクレジット取引の理由（無効口座番号、閉じられた口座、以前にチャージバックされた等）を決定するためのマニュアルレビューのために転送される。

ステップ６８で、クレジット裁定(determination)の適用対象となるカード口座は、将来の認証及び加入の取り消しがフラグ付けされ、これによって係争中のカード保有者に対する加盟店からの将来の認証は、ゲートウェイレベルで阻止され、カード保有者の加入が取り消される。これは、紛争が満足のいくように解決されるまで販売側加盟店によって提供される商品又はサービスに対するカードの更なる使用を阻止する。

ステップ７０、７２、及び７４で、紛争解決プロセッサデバイス１０及び／又はカード発行者システム１２は、ステップ７０において取引が以前に払い戻されたか又は加盟店及び／若しくは紛争解決システムプロバイダによって払い戻されたか否か、ステップ７２において取引が紛争解決システム紛争要求の日付から１２０日以上の中央処理日付（ＣＰＯ）を有するか否か、及びステップ７４においてこのような場合に加盟店に対するチャージバック権がカード発行者に存在しない場合にチャージバック保護を受け取る加盟店から取引が発生したか否か、といった所定の取引レベル適格性要件に基づいて紛争解決システムに対して取引が適格であることを確認できる。１つの実施例では、このような適格性チェックを適用するために、紛争解決システム１２によって受け取られた要求は、適格性チェックとしてそれ自体が機能するものに一致させることができる。

ステップ７６で、適格なクレジット取引はクレジットカード支払ゲートウェイ２２で処理することができ、これによって紛争が有効であると決定された場合、元々の販売取引が破棄され、カード保有者の口座には係争中の購入金額が入金される。別の実施例では、このような処理は、紛争解決プロセッサデバイス１０によって又はパートナー（例えば図４のパートナープラットフォーム１３０）によって開始することができる。

若しくは、ステップ７８で、所定の取引レベルの適格性要件に基づいて紛争解決システムにとって不適格であると判断された紛争は、ステップ６６でマニュアルレビューを行うようフラグが立てられ、適格性要件を満たすことができなかった理由（例えば、無効の口座番号、閉じられた口座、以前にチャージバックされた、紛争解決システム１２によってマッチさせることができない等）を判断する。

ステップ８０での、元の販売取引が、クレジットが処理された交換システムからの応答によってクレジットされたか否かの裁定、及びステップ８２での、成功したクレジット紛争は、「解決済みｗ／クレジット」に更新される紛争解決システム要求ステータスをもたらす。

ステップ７８で、失敗したクレジット紛争が識別され、ステップ６６でマニュアルレビューを受け、失敗したクレジット取引の理由（無効口座番号、閉じられた口座、以前にチャージバックされた等）を決定する。

ステップ８４で、取引の紛争解決システム記録ステータスが、「解決済みｗ／アウトクレジット」に更新され、クレジット要求失敗の説明が応答ファイルに包含される。

若しくは、ステップ８６で、成功したクレジット取引に対して、紛争解決システム記録のステータスが「クレジットによる解決済み」に更新される。

ステップ８８で、成功したクレジット取引及び不成功のクレジット取引の両方に対して、全ての紛争解決システム要求記録の更新された情報を含む応答ファイルがコンパイルされ、カード発行者及び加盟店に対して各取引に関する適切な処理−「解決済みｗ／クレジット」、「解決済みｗ／ｏクレジット」、「不一致」等を付して送信される。応答ファイルは、カード発行者及び加盟店が好都合にダウンロードするためのオンデマンドウェブポータルによってカード発行者及び加盟店が利用できる。

紛争解決システム応答ファイルは、紛争解決システム要求ファイルに一致する取引レベルを処理する際に、以下に指定されるように発行者に送信される。

紛争解決システム発行者応答ファイルの上記のテーブルの応答コードは以下のテーブルの値に対応する。

ステップ８８で、定期的支払プログラムから係争中の顧客を取り除くよう生成された取り消し記録を含む加盟店応答ファイルが、加盟店にルーティングされる。取り消しエクスポートバッチフィルが以下に示すように提供される。

ステップ９０で、紛争が解決されていることが確認され、カード発行者によるファイルの受領の肯定応答(acknowledgement)を、紛争解決システムに送信してカード発行者による解決を確認することができる。

したがって、本発明は、顧客と、顧客と加盟店との間の電子取引に関する電子支払プロバイダとの間の紛争を解決するためのシステムを提供し、取引に関するデータを受信しこのデータを紛争解決サーバに送信するようプログラムされたコンピュータ、及び取引データを紛争解決のための所定の適格性条件と比較するようプログラムされた紛争解決サーバを含み、紛争解決条件が満たされた場合、係争中の消費者に対する加盟店からの将来の取引を拒否し、このサーバは、取引データを取引クレジットに対する所定の適格性条件と比較するよう更にプログラムされ、クレジット条件が満たされた場合、取引に対するクレジット命令を送信する。

本発明は、顧客と、顧客と加盟店の間の電子取引に関する電子支払プロバイダとの間の紛争を解決するためのコンピュータに基づく方法も提供し、コンピュータの取引に関するデータを受信するステップ、コンピュータからのデータを紛争解決サーバに送信するステップ、取引データを紛争解決サーバの紛争解決に関する所定の適格性条件と比較するステップ、及び紛争解決条件が満たされた場合、係争中の消費者に対する加盟店からの将来の取引を拒否するステップ、及び取引データを取引クレジットに関する所定の適格性条件と比較するステップ、及びクレジット条件が満たされた場合、取引に対するクレジット命令を送信するステップを含む。

本明細書で説明する実施形態の１つ又はそれ以上の態様により、紛争解決ネットワークをパートナー／アグリゲータ技術プラットフォームに統合するための技術が提供され、加盟店が、紛争解決処理に参加するのを可能にする。例えば、加盟店又は加盟店サービスプロバイダのシステムは、係争中の取引を払い戻す及び／又は係争中の顧客に対する加盟店からの将来の取引を拒否する役割を果たすことができ、これによってこのような責務を紛争解決サーバ１０又は同様のものから移行させる。

図４を参照すると、加盟店エンティティ１２０、パートナーエンティティ１３０、紛争解決エンティティ１４０、発行者エンティティ１５０を含む、多数のネットワークエンティティを含む例示的な紛争解決システム１００が示されている。参加加盟店１２０は、紛争解決パートナープラットフォーム１３０を介して紛争解決処理に参加することができる。パートナープラットフォーム１３０は、１つ又はそれ以上の加盟店１２０と通信することができ、別々の小売又は加盟店ウェブサイトを備えた電子商取引（Ｅコマース）プラットフォームとすることができる。パートナープラットフォーム１３０は、紛争解決サーバ又はプラットフォーム１４０と通信することができ、紛争解決サーバ又はプラットフォーム１４０は、１つ又はそれ以上の参加カード発行者１５０と通信することができる。紛争解決プラットフォーム１４０は、パートナーＡＰＩ１４２を介してパートナープラットフォーム１３０に接続すること、及び／又は発行者ＡＰＩ１４４を介して参加カード発行者１５０に接続することができる点に留意されたい。パートナーＡＰＩ１４２は、ＲＥＳＴフルＡＰＩ実施構成に従うことができ、パートナーＡＰＩ１４２は、システムがどのように要求を処理するか指示するためにＨＴＴＰステータスコードを活用して要求の同時及び非同時処理を可能にすることができる。

例えば、ユーザ又は消費者１１０は、参加加盟店１２０で購入を行うことができる。消費者１１０は、購入に関する照会を行うこと及び／又は購入／カード発行者１５０との取引に異議を唱えることができる。カード発行者１５０は、照会及び／又は紛争に関する事例を紛争解決プラットフォーム１４０に提出することができ、紛争解決プラットフォーム１４０は、紛争事象通知をパートナープラットフォーム１３０に提出することができる。パートナープラットフォーム１３０は、紛争解決プラットフォーム１４０から及び／又は紛争解決プラットフォーム１４０と通信できる別のプラットフォームから事例の詳細を取得することができる。パートナープラットフォーム１３０は、事例を処理して、事例が解決されたことを紛争解決プラットフォーム１４０に通知することができる。パートナープラットフォーム１３０は、事例及びいずれかの関連のある払い戻し及び／又は請求の取り消しに関して加盟店１２０に通知することができる。紛争解決プラットフォーム１４０は、事例解決をカード発行者１５０に通知することができる。

関連の態様では、紛争解決システム１００が、事例事象をパートナー１２０に通知するために通知スキームを活用することができる。事象は、パートナープラットフォーム１３に登録されシステム１００に参加している関連の加盟店１２０のための照会又は紛争事例の作成を表すことができる。この通知スキームは、パートナー１３０が事例要求を処理して自らのプラットフォーム内で紛争を解決するのを可能にする。

更に関連の態様では、通知が送信されパートナー１３０が受信した後、紛争解決ＡＰＩへの呼出しがパートナー１３０によって開始され、付加的な事例の詳細を取得し、事例解決を処理して、事例が解決された後にネットワークの取引詳細を更新する。

事象種類：１つの実施形態では、事象種類は、紛争解決プラットフォーム１４０から発生することができる。要求は、紛争解決システム１００の１つ又はそれ以上のネットワークエンティティで実行される紛争解決プログラムに従って事象種類に少なくとも一部基づいてパートナー１３０によって処理することができる。例示的な事象の種類は、紛争、取り消し、又は破棄を含むことができる。

「ＤＩＳＰＵＴＥ（紛争）」事象は、指示された加盟店に対して受信したカード保有者紛争を識別する。要求の解決は、参照された取引が払い戻されるステップを伴うことができ、その製品に対するカード保有者への何らかのその後の請求も阻止又は保留される。一般的には、これは、口座番号がパートナー１３０又は加盟店１２０によって管理されるネガティブリストに追加されることを伴う。

「ＣＡＮＣＥＬ（取り消し）」事象通知は、言及される口座番号に対する何らかのその後の請求も阻止又は保留されることを包含できる。一般的には、これは、口座番号がパートナー１３０及び／又は加盟店１２０によって管理されるネガティブリストに追加されることを伴う。

「ＲＥＶＯＫＥ（破棄）」事象通知は、紛争解決プラットフォーム１４０によって処理のためのパートナー１３０に以前に提出された事例に関するものとすることができる。特定のシナリオでは、事例は誤って処理される場合があり、この事象種類は、事例をＤＩＳＰＵＴＥ（紛争）又はＣＡＮＣＥＬ（取り消し）処理から破棄するのを可能にする。パートナー１３０は、事例がＰＲＯＣＥＳＳＩＮＧ（処理中）のステータスである場合にこれらの通知を受信できるが、ＲＥＳＯＬＶＥＤ（解決済み）又はＤＥＣＬＩＮＥＤ（拒否済み）されていない。

「ＥＶＥＮＴ ＮＯＴＩＦＩＣＡＴＩＯＮ（事象通知）」：図５の呼出し系統線図２００に関して、加盟店１２０（図示せず）又はパートナー１３０は、紛争解決プラットフォーム１４０からの事象通知を受信できる通知ＵＲＬエンドポイントを実装することができる。通知は、処理の準備が整った照会／紛争事例を識別することができる。

パートナー１３０は、ステータスをＰＲＯＣＥＳＳＩＮＮＧ（処理中）に設定するために事例更新要求を起動することによってＤＩＳＰＵＴＥ（紛争）及びＣＡＮＣＥＬ（取り消し）通知に肯定応答することが予想される。ＲＥＶＯＫＥ（破棄）通知は、事例ステータスをＣＡＮＣＥＬＬＥＤ（取り消し済み）に設定することによって肯定応答することができる。

通知に続いて事象が肯定応答されず保留ステータスのままである場合、通知を再提出することができる。事例ステータスによって識別される肯定応答が、パートナー１３０によってＰＥＮＤＩＮＧ（保留中）から変わるか又はＲＥＳＯＬＶＥＤ（解決済み）になるまで、通知を再試行することができる。

図５を続けて参照すると、カード発行者１５０は、紛争解決要求を紛争解決プラットフォーム１４０に送信することができ、紛争解決プラットフォーム１４０は、事象通知をパートナープラットフォーム１３０に送信することができる。事象通知は、以下の情報の１つ又はそれ以上、すなわち（ａ）事例(case)ＩＤ（例えば、一般的に紛争解決プラットフォーム１４０又は紛争解決システム１００全体に渡った事例の固有識別子）、（ｂ）加盟店(merchant)ＩＤ（例えば、紛争が要求されている加盟店口座を表わす加盟店識別子）、（ｃ）事象種類(event type)（例えば、ＤＩＳＰＵＴＥ（紛争）、ＣＡＮＣＥＬ（取り消し）、又はＲＥＶＯＫＥ（破棄））、（ｄ）通知(notification)ＩＤ（例えば、特定の通知メッセージの引用）、又はこれらの変形例を含むことができる。

パートナー１３０は、事例ステータスをＰＲＯＣＥＳＳＩＮＧ（処理中）に更新して、この情報を紛争解決プラットフォーム１４０に送信することによって、事例通知に肯定応答することができる。紛争解決プラットフォーム１４０では、次の通知間隔によって、事例ステータスがＰＲＯＣＥＳＳＩＮＧ（処理中）又は事例解決ステータスに更新されなかった場合、別の通知をパートナー１３０に送信することができる。

例えば、パートナープラットフォームは、（ａ）紛争解決プラットフォーム１４０から全ての事例詳細を取得するためにＧＥＴ呼出しを行うステップ、（ｂ）例えばＡＲＮ又は同様のもののような地球的固有取引識別子によって係争中の販売を特定するステップ、（ｃ）既に払い戻されている場合は最大紛争解決事例金額まで係争中の販売を払い戻すステップ、（ｄ）関連の定期的課金に対する将来のカード保有者課金を取り消すステップ、（ｅ）事例ステータスを、要件が満足されたことを表す解決済みに更新するステップの１つ又はそれ以上を実行することができる。事例が解決されると、事例の結果が紛争解決応答メッセージ又は同様のものを介して発行者１５０に伝送される。（ｂ）に関して、１つの実施例では、照会される販売をＡＲＮ又は同様のものによって特定することができる。別の実施例では、取引及び事例データ属性を使用して、照会される販売を探すことができ、このようなデータポイントは、ＢＩＮ、口座番号の最後の４桁、取引の日付、取引額等を含むことができる。

ＤＩＳＰＵＴＥ（紛争）事象の処理に関して、事象通知は、パートナー１３０に紛争解決要求に指示された金額だけ係争中の取引を払い戻すよう命じること、又は払い戻しが係争中の取引に既に適用されている場合、払い戻しの詳細を完全に又は部分的に提供することによって事例を解決するよう命じることができる（任意選択的に、処理される付加的な部分的払い戻しを伴うことができる）。更なる関連の態様では、事象通知は、係争中の製品／サービスに対するその口座ホルダへの何らかの定期的請求も取り消すようパートナー１３０に命じることができる。

ＣＡＮＣＥＬ（取り消し）事象の処理に関して、事象通知は、事例が参照する製品取引に関するその口座ホルダへ何らかの定期的又は将来の請求を取り消すようパートナー１３０に命じることができる。

ＲＥＶＯＫＥ（破棄）事象の処理に関して、事象通知は、パートナー１３０が、ＤＩＳＰＵＴＥ（紛争）又はＣＡＮＣＥＬ（取り消し）事例の処理に関する何らかの現在の処理も中止するのを可能にする。例えば、事象通知は、口座番号の元の取引の払い戻し又は定期的請求の取り消しに関する何らかの取引を保留するようパートナー１３０に命じることができる。

ＣＡＳＥ（事例）−図４を参照すると、紛争解決事例は、カード発行者１５０に連絡を取った際に消費者が起こした紛争を表わすことができる。紛争は、紛争ネットワーク又はシステム１００によって受信することができ、パートナー１３０によって解決を保留にすることができる。パートナー１３０は、ＨＴＴＰ方法を使用して、事例を検索及び解決することができる。例示的なＨＴＴＰ方法は、ＧＥＴ（すなわち、事例ＩＤ又は同様のものを参照することによって単一の事例の詳細にアクセスして読み取る）、ＰＵＴ（すなわち、パートナー１３０又はシステム１００の別のネットワークエンティティによって維持できる事例ステータス及び関連の取引データを更新する）、及び／又はこれらの組合せ／変形例を含むことができる。

事例ステータスライフサイクルに関して、事例は、パートナー１３０によって及び紛争解決プラットフォーム１４０によって対処及び処理される場合にステータスライフサイクルを通過することができる。図６は、例示的な事例ステータスライフサイクルの図を示す。事例通知が処理のためのパートナー１３０に送信されると、パートナー１３０は、事例の解決を期待されるが、事例は、解決される前に発行者１５０によって破棄されうる。これが起こった時、ＲＥＶＯＫＥ（破棄）通知がパートナー１３０に送信され、事例ステータスをＲＥＶＯＫＥＤ（破棄済み）に変更する。ＤＩＳＰＵＴＥ（紛争）及びＣＡＮＣＥＬ（取り消し）の事例タイプは、ＲＥＶＯＫＥ（破棄）通知に含めることができる。例示的なシナリオ及び対応する応答を以下の表に示す。

紛争解決プラットフォーム１４０とパートナープラットフォーム１３０との間の通信は、多数の構成詳細（例えば、紛争解決プラットフォーム１４０のパートナーＡＰＩ１４２及び／又はパートナープラットフォーム１３０で）を実装することによって達成することができる。例示的な構成パラメータを以下の表に示す：

本明細書に図示し説明した例示的なシステムの点から、開示された主題に従って実施することができる方法は、様々な流れ図を参照して良く理解されるであろう。説明を簡単にするために、方法は、一連の動作／ブロックとして図示及び記述されており、クレームされる主題は、ブロックの数又は順序によって制限されず、幾つかのブロックは、本明細書に図示及び記述とは異なる順序で及び／又は他のブロックを有する実質的に同じ時間に発生できることを理解及び評価されたい。更に、本明細書で説明する方法を実施するために全ての示されたブロックが必要となるものではない。ブロックに関連付けられる機能は、ソフトウェア、ハードウェア、これらの組合せ又は何らかの他の適切な手段（例えば、デバイス、システム、処理、又は構成要素）によって実装できることを理解されたい。加えて、本明細書全体を通して開示される方法は、このような方法の様々なデバイスへの移送及び転送を容易にするために製品に記憶できることを更に理解すべきである。当業者であれば、方法を状態図のように一連の相互に関係のある状態又は事象として代わりに表すことができることを理解及び評価できるはずである。

本明細書で説明する実施形態の１つ又はそれ以上の態様によれば、電子取引に関する照会及び／又は紛争を解決するための少なくとも１つのネットワークエンティティによって（例えば、少なくとも１つの加盟店プラットフォーム／サーバ及び／又は複数の加盟店プラットフォーム／サーバと通信できる少なくとも１つのパートナー／アグリゲータプラットフォーム／サーバで）動作できる技術が提供される。例えば、ネットワークエンティティは、図４−５に示したパートナー／アグリゲータプラットフォーム１３０及び／若しくは加盟店プラットフォーム１２０、若しくはこれらの変形例、又はこれらの構成要素とすることができる。図７の実施例を参照すると、加盟店エンティティ及び／又はパートナー／アグリゲータエンティティ（例えば、１つ又はそれ以上の加盟店エンティティと通信できるパートナープラットフォーム又はサーバ）で、取引（例えばオンライン販売）に関する照会／紛争事象通知を受信するステップ（ブロック７１０）を含むことができる方法７００が示されている。方法７００は、取引に関するデータポイントを取得するステップ（ブロック７２０）を含むことができる。方法７００は、データポイントに基づいて取引に関する更なる情報を（ローカルに及び／又はリモートに）特定するステップ（ブロック７３０）を含むことができる。方法７００は、所定の適格性条件が満たされたことに応じて、更なる情報に基づいて取引を払い戻す又は取り消すか否かを決定するステップ（ブロック７４０）を含むことができる。

図８を参照すると、関連の態様では、方法７００は、定期的課金の一部である取引に応じて将来のカード保有者課金を取り消すステップ（ブロック７５０）を更に含むことができる。更なる関連の態様では、通知が、事例ＩＤ、加盟店ＩＤ、又は通知ＩＤの少なくとも１つを含むことができる（ブロック７６０）。更なる関連の態様では、方法７００は、通知の受信に応じて通知を肯定応答するステップ（ブロック７７０）を更に含むことができる。肯定応答は、取引の事例ステータスを更新するステップ（ブロック７７２）を含むことができる。方法７００は、取引の解決に応じて、取引の解決を表すよう事例ステータスを更新するステップ（ブロック７７４）を含むことができる。

図９を参照すると、関連の態様では、ブロック７４０は、取引を払い戻すか否かを決定するステップ（ブロック７８０）を含むことができる。ブロック７８０は、取引が既に払い戻されているか否かを決定するステップ（ブロック７８２）、及び、取引を払い戻す必要があるという決定に応じて取引を払い戻すステップ（ブロック７８４）を含むことができる。更に関連の態様では、方法７００は、定期的課金の一部である取引に応じて、紛争が定期的課金に関連付けられる将来の課金の取り消し要求を含むステップを更に含むことができる（ブロック７９０）。更なる関連の態様では、データポイントは、受信される通知に含めることができる（ブロック７９５）。

本明細書で説明する実施形態の１つ又はそれ以上の態様により、図７−９に関して上述したオンライサービス口座を管理するためのデバイス及び装置が提供される。図１０に関して、オンライン若しくは移動ネットワークのパートナー／アグリゲータプラットフォーム若しくはサーバとして、若しくはパートナープラットフォーム若しくはサーバ内で使用するプロセッサ若しくは類似のデバイスとして、及び／若しくはオンライン若しくは移動ネットワークの加盟店プラットフォーム若しくはサーバとして、又は加盟店プラットフォーム若しくはサーバ内で使用するプロセッサ若しくは類似のデバイスとして構成できる例示的な装置１０００が提供される。装置１０００は、プロセッサ、ソフトウェア、又はこれらの組合せ（例えば、ファームウェア）によって実装される機能を表わすことができる機能的ブロックを含むことができる。

図示のように、１つの実施形態では、装置１０００が、取引に関する照会／紛争事象通知を受信するための電気構成要素又はモジュール１００２を含むことができる。この装置は、通知の受信に応じて取引に関するデータポイントを取得するための構成要素１００４を含むことができる。この装置は、データポイントに基づいて取引を特定するための構成要素１００６を含むことができる。この装置は、所定の適格性条件及び／又は紛争解決条件が満たされたことに応じて、取引を払い戻すか又は取り消すか否かを決定するための構成要素１００８を含むことができる。

関連の態様では、装置１０００は、任意選択的にプロセッサとしてではなくパートナーエンティティとして構成される装置１０００の場合に、少なくとも１つのプロセッサを有するプロセッサ構成要素１０１０を含むことができる。このような場合、プロセッサ１０１０は、バス１０１２又は類似の通信結合を介して構成要素１００２−１００８と通信することができる。プロセッサ１０１０は、電気構成要素１００２−１００８によって実行される処理又は機能の開始及びスケジューリングを行うことができる。

更なる関連の態様では、装置１０００は、ネットワークインタフェース１０１３及び／又は送受信器構成要素１０１４を含むことができる。独立型受信器及び／又は独立型送信機は、送受信器１０１４の代わりに又はこれと共に使用することができる。装置１０００は、例えばメモリデバイス／構成要素１０１６のような情報を記憶するための構成要素を任意選択的に含むことができる。コンピュータ可読媒体又はメモリ構成要素１０１６は、バス１０１２又は同様のものを介して装置１０００の他の構成要素に動作可能に結合することができる。メモリ構成要素１０１６は、構成要素１００２−１００８、及びこの副構成要素、若しくはプロセッサ１０１０、又は本明細書に開示する方法の処理及び動作を行うためのコンピュータ可読命令及びデータを記憶するよう適応させることができる。メモリ構成要素１０１６は、構成要素１００２−１００８に関連付けられる機能を実行するための命令を保存することができる。構成要素１００２−１００８は、メモリ１０１６の外部に図示しているが、メモリ１０１６内に存在できることを理解されたい。

したがって以下の請求項は、具体的に図示及び上記に説明したもの、概念的に等価のもの、明らかに置き換えられるもの、及び本発明の基本的な理念を本質的に組み入れるものを含むことを理解すべきである。当業者であれば、説明した好ましい実施形態の様々な適応例及び変更例を本発明の範囲から逸脱することなく構成できることを理解するであろう。図示した実施形態は、例示目的のみで示しており、本発明を限定すると捉えるべきではない。したがって、特許請求の範囲の範疇で本明細書に具体的に説明したもの以外に本発明を実施できることを理解されたい。

１０ 紛争解決プログラムサーバ
１２ カード発行者のコンピュータ
１４ 電話
１６ ファックス
１８ コンピュータ
２０ 移動デバイス
２２ アクワイアラ
２４ 発生元加盟店の処理デバイス

Claims (22)

1. プロセッサを有するネットワークエンティティプラットフォームによって動作可能な方法であって、
   事例識別子を含む、ユーザ及び加盟店の間の電子取引に関する照会／紛争事象通知を、紛争解決サーバから受信するステップと、
   前記プロセッサにより、前記電子取引に関する取引データを前記紛争解決サーバから取得するための要求を送信するステップであって、該要求は前記事例識別子を含む、ステップと、
   前記事例識別子及び前記照会／紛争事象通知が処理されている表示を含む第１のステータスメッセージを前記紛争解決サーバへ送信するステップと、
   前記紛争解決サーバから受信した前記取引データを用いて、前記紛争解決サーバ以外のローカル又はリモートデータベースにおいて前記電子取引に関する更なる情報を特定するステップと、
   前記プロセッサにより、前記紛争解決サーバからの前記取引データ及び前記ローカル又はリモートデータベースにおいて特定された前記更なる情報により前記電子取引に関して１又は複数の所定の取引適格性基準が満たされることを判断するステップと、
   前記事例識別子及び前記判断するステップにより前記照会／紛争事象通知が解決された表示を含む第２のステータスメッセージを前記紛争解決サーバへ送信するステップと、を含み、
   前記１又は複数の所定の取引適格性基準は、前記電子取引が以前に払い戻されたか、前記電子取引が所定の間隔より大きい処理日付を有するか、及び前記電子取引に関連付けられた加盟店がチャージバック権を有するか、のうちの１つである、
   方法。
2. 前記プロセッサにより、前記取引データに少なくとも部分的に基づいて前記電子取引が定期的取引であることを決定するステップを更に含む、請求項１に記載の方法。
3. 前記照会／紛争事象通知は、加盟店識別子及び通知識別子の少なくとも１つを含む、請求項１に記載の方法。
4. 前記照会／紛争事象通知の受信に応じて、該通知を受け取ったことを肯定応答するメッセージを前記紛争解決サーバへ送信するステップを更に含む、請求項１に記載の方法。
5. 前記メッセージは、共有秘密鍵及び所定の署名ハッシュプロトコルを用いて送信される、請求項４に記載の方法。
6. 前記第２のステータスメッセージを送信する前に、前記紛争解決サーバから、前記事例識別子を含む破棄通知を受信するステップと、
   前記電子取引に関して実行されたあらゆる更新を破棄するステップと、を更に含む、請求項１に記載の方法。
7. 前記電子取引を更新するステップは、前記電子取引に含まれる額に基づいて前記ユーザに払い戻しを開始するステップを含む、請求項１に記載の方法。
8. 前記プロセッサにより、前記払い戻しを開始する前に、前記電子取引が既に払い戻されているか否かを決定するステップを含む、請求項７に記載の方法。
9. 前記プロセッサにより、前記電子取引が既に払い戻されていないという決定に応じて、前記電子取引を払い戻すステップを更に含む、請求項８に記載の方法。
10. 前記電子取引は、オンライン販売又は電子支払を含む、請求項１に記載の方法。
11. 前記ネットワークエンティティプラットフォームは、加盟店エンティティを含む、請求項１に記載の方法。
12. 前記ネットワークエンティティプラットフォームは、複数の加盟店エンティティにサービスを提供するパートナー／アグリゲータエンティティを含む、請求項１に記載の方法。
13. 前記照会／紛争事象通知は、前記電子取引の払い戻し又は取り消しの少なくとも１つの要求を含む、請求項１に記載の方法。
14. 定期的課金の一部である前記電子取引に応じて、前記照会／紛争事象通知は、前記定期的課金に関連付けられる将来の課金の取り消し要求を含む、請求項１に記載の方法。
15. 更なる取引データは、前記照会／紛争事象通知に含まれる、請求項１に記載の方法。
16. 事例識別子を含む、電子取引に関する照会／紛争事象通知を、紛争解決サーバから受信するための受信器と、
    データを記憶するためのメモリと、
    前記受信器及び前記メモリと通信することができる少なくとも１つのプロセッサと、を備える装置であって、
    前記少なくとも１つのプロセッサは、
    前記電子取引に関する取引データを、前記紛争解決サーバから取得するための要求を送信し、該要求は前記事例識別子を含むものであり、
    前記紛争解決サーバから受信した前記取引データを用いて、前記紛争解決サーバ以外のローカル又はリモートデータベースにおいて前記電子取引に関する更なる情報を特定し、
    前記紛争解決サーバからの前記取引データ及び前記ローカル又はリモートデータベースにおいて特定された前記更なる情報により前記電子取引に関して１又は複数の所定の取引適格性基準が満たされることを判断し、及び
    前記事例識別子及び前記判断することにより前記照会／紛争事象通知が解決された表示を含むステータスメッセージを前記紛争解決サーバへ送信し、
    前記１又は複数の所定の取引適格性基準は、前記電子取引が以前に払い戻されたか、前記電子取引が所定の間隔より大きい処理日付を有するか、及び前記電子取引に関連付けられた加盟店がチャージバック権を有するか、のうちの１つである、
    装置。
17. 前記少なくとも１つのプロセッサは、前記取引データに少なくとも部分的に基づいて前記電子取引が定期的取引であることを決定するように構成される、請求項１６に記載の装置。
18. 前記装置は、加盟店デバイス又は複数の加盟店デバイスと通信することができるパートナー／アグリゲータデバイスを含む、請求項１６に記載の装置。
19. 前記加盟店デバイスは加盟店サーバを含み、前記パートナー／アグリゲータデバイスは、パートナー／アグリゲータサーバを含む、請求項１８に記載の装置。
20. 事例識別子を含む、電子取引に関する照会／紛争事象通知を、紛争解決サーバから受信するための手段と、
    前記電子取引に関する取引データを、前記紛争解決サーバから取得するための要求を送信するための手段であって、該要求は前記事例識別子を含む、手段と、
    前記紛争解決サーバから受信した前記取引データを用いて、前記紛争解決サーバ以外のローカル又はリモートデータベースにおいて前記電子取引に関する更なる情報を特定するための手段と、
    前記紛争解決サーバからの前記取引データ及び前記ローカル又はリモートデータベースにおいて特定された前記更なる情報により前記電子取引に関して１又は複数の所定の取引適格性基準が満たされることを判断するための手段と、
    前記事例識別子及び前記判断することにより前記照会／紛争事象通知が解決された表示を含むステータスメッセージを前記紛争解決サーバへ送信するための手段と、を備え、
    前記１又は複数の所定の取引適格性基準は、前記電子取引が以前に払い戻されたか、前記電子取引が所定の間隔より大きい処理日付を有するか、及び前記電子取引に関連付けられた加盟店がチャージバック権を有するか、のうちの１つである、
    装置。
21. 前記取引データに少なくとも部分的に基づいて前記電子取引が定期的取引であることを決定するための手段を更に含む、請求項２０に記載の装置。
22. 命令を含むコンピュータプログラム製品であって、該命令は、装置のプロセッサにより実行されるとき、該装置に少なくとも、
    事例識別子を含む、電子取引に関する照会／紛争事象通知を、紛争解決サーバから受信させ、
    前記電子取引に関する取引データを取得するための要求を前記紛争解決サーバへ送信させ、該要求は前記事例識別子を含むものであり、
    前記紛争解決サーバから受信した前記取引データを用いて、前記紛争解決サーバ以外のローカル又はリモートデータベースにおいて前記電子取引に関する更なる情報を特定させ、
    前記紛争解決サーバからの前記取引データ及び前記ローカル又はリモートデータベースにおいて特定された前記更なる情報により前記電子取引に関して１又は複数の所定の取引適格性基準が満たされることを判断させ、及び
    前記事例識別子及び前記判断することにより前記照会／紛争事象通知が解決された表示を含むステータスメッセージを前記紛争解決サーバへ送信させ、
    前記１又は複数の所定の取引適格性基準は、前記電子取引が以前に払い戻されたか、前記電子取引が所定の間隔より大きい処理日付を有するか、及び前記電子取引に関連付けられた加盟店がチャージバック権を有するか、のうちの１つである、
    コンピュータプログラム製品。

Images