(57)【要約】  本発明は、クレジットカード取得者及び／又は取引プロセッサに対する購入者／支払人又は供給者／受取人の代わりにＥＩＰＰサービスのサードパーティのサービスプロバイダが請求書品目名データ（レベルIIIデータ）による支払いカードの支払いの認証及び決済を開始することができるシステム及び方法を提供する。支払いの開始は、購入注文書に対して有効にされた予め承認した請求書若しくは注文確認、又は購入者／支払人の組織によって承認されるとともに支払いに対してスケジューリングされた請求書の提出に基づく。
2008511085.tif 000002
【特許請求の範囲】
【請求項１】
電子請求書・決済（ＥＩＰＰ）システムによって購入者と供給者との間で購入カードの取引を行う方法であって、
前記購入者の企業資源計画（ＥＲＰ）システムで前記購入カードの取引に対する請求書を承認し、
前記購入者のＥＲＰシステムの支払いに対する請求書をスケジューリングし、
前記取引に関連した独自の取引識別子を有する支払いファイルを、前記購入者のＥＲＰシステムから抽出し、
独自の取引番号を含む支払いファイルを、前記購入者のＥＲＰから支払い認証及び決済の取得者に送出し、
前記取引を記述するデータを含む取引カード明細を前記購入者のＥＲＰに供給し、前記明細のデータが前記独自の取引識別子を有し、
前記購入カードの発行者との取引を前記購入者によって決済することを特徴とする方法。
【請求項２】
請求項１記載の方法において、前記供給者の口座の銀行勘定調整を行うために、前記独自の取引識別子を有する送金データを前記供給者に供給することを特徴とする方法。
【請求項３】
電子請求書・決済（ＥＩＰＰ）システムによって購入者と供給者との間で購入カードの取引を行う方法であって、
前記購入者の企業資源計画（ＥＲＰ）システムで前記購入カードの取引に対する請求書を承認し、
前記購入者のＥＲＰシステムの支払いに対する請求書をスケジューリングし、
前記取引に関連した独自の取引識別子を有する支払いファイルを、前記購入者のＥＲＰシステムから抽出し、
認証及び決済のために、前記取引を記述するとともに前記独自の取引識別子を有するデータを、販売（ＰＯＳ）装置に提供し、
独自の取引番号を含む支払いファイルを、前記購入者のＥＲＰから支払い認証及び決済の取得者に送出し、
前記取引を記述するデータを含む取引カード明細を前記購入者のＥＲＰに供給し、前記明細のデータが前記独自の取引識別子を有し、
前記購入カードの発行者との取引を前記購入者によって決済することを特徴とする方法。
【請求項４】
請求項２記載の方法において、前記供給者の口座の銀行勘定調整を行うために、前記独自の取引識別子を有する送金データを取得者から前記供給者に供給することを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この出願は、発明の名称が「統合された電子請求書提示及び支払いシステム及び方法」(System and Method for Integrated Electronic Invoice Presentment and Payment)である２００３年６月１８日に出願された米国特許出願第１０／４６５３９４号に対する優先権を主張する、発明の名称が「自動化した支払い認証及び決済」(Automated Payment Authorization and Settlement)である２００４年８月２５日に出願された米国分割出願第６０／６０４，２１５号に対する優先権を主張し、両出願は、参照によってここに組み込まれる。また、この出願は、発明の名称が「自動化された支払い認証及び決済」(Method and System For Automated Payment Authorization and Settlement)である２００４年１０月２９日に出願された米国分割出願第６０／６２３，６５６号に対する優先権も主張し、この出願の全体も、参照によってここに組み込まれる。
【背景技術】
【０００２】
本発明は、自動化された支払い認証及び決済の方法及びシステムに関する。
【０００３】
サードパーティのサービスプロバイダ（３ＰＳＰＳ）を用いることによって請求書送付及び支払いプロセスを自動化する試みがなされている。３ＰＳＰは、Ａｒｉｂａ（登録商標）のような電子調達プロバイダ、Ｘｉｇｎ（登録商標）のような電子請求書・決済（ＥＩＰＰ）及びＯｒａｃｌｅ（登録商標）のような企業資源計画（ＥＲＰ）プロバイダを含む。これらの初期の３ＰＳＰの解決は、供給者／受取人／請求書作成機械の要求に焦点が当てられ、購入者／支払人／支払機の要求に十分に対処しなかった。例えば、多数の早期の３ＰＳＰの解決は、支払いの開始の効率的かつ有効な制御、決済の繰り延べ、購入者／支払人の金融システムでの銀行勘定調整及びこれらのかかる金融システムへの統合のような購入者／支払人／支払機の支払いに関する要求に十分に対処しなかった。
【０００４】
また、現存する３ＰＳＰの解決は、企業間の支払いの手段としてクレジットカード、デビットカード、法人カード、購入カードのような支払いカードを一般的には用いていない。さらに、これら３ＰＳＰの解決は、支払いカードによる支払いに関連した支払い期間の使用又は支払いカードによる支払い前の購入者／支払人の請求書発行規則を有効にすることが許容されていない。
【０００５】
さらに、現存する３ＰＳＰは、ＥＰＲシステムや買掛管理（Ａ／Ｐ）システムのような組織の内部システムに支払いデータを自動的に統合することができない。したがって、組織は、請求書データにマニュアルで鍵をかけ、銀行勘定調整のために請求書データをカード取引に整合し、データを組織のＥＲＰシステム又はＡ／Ｐシステムにマニュアルで入力することが強いられる。このプロセスは、時間がかかるとともに人為的な誤りが生じる傾向にある。
【０００６】
一部の現存する３ＰＳＰの解決は、金融電子データ交換（ＥＤＩ）又は他の電子的な支払い技術を用いることができる。しかしながら、これらの支払方法は、内部システム及びプロセスに対するコストのかかる変更を含む著しいセットアップコストを要し、銀行取引における変更を必要とする。
【０００７】
したがって、費用効果が高く、現存するプロセス及びシステムへの統合が簡単であり、有効な支払い及び金融記録の銀行勘定調整を許容する自動化されたＥＩＰＰ方法及びシステムが必要とされる。
【０００８】
米国特許出願第１０／４６５，３９４号において、マスターカードは、あり得る支払方法として購入カードを利用する自動的な電子請求書提示及び支払いシステム及び方法を提供している。本発明は、従来のアプリケーションを向上する。本発明によれば、電子的な調達及び／又は請求書発行を行う３ＰＳＰによって、顧客は、マスターカードのクレジットカード口座における取引を自動的に決済することができ、これによって、顧客は、銀行の支払条件の下で購入注文（ＰＯ）又は請求書に基づく購入を行うことができる。支払人は、遅延した支払い期間と、発行銀行からの手数料を受け取る機会とから利益を得る。供給者は、（伝票処理のコストに対する）電子的な支払い受け取りと、ハードウェア又はソフトウェアに更に投資することなく（更に低い割引率を受け取るための）レベルIIIデータを渡す機会から利益を得る。金融機関及びそのプロセッサは、処理される多大な取引から利益を得る。取得期間及び取引プロセッサの例は、シティーバンク、ファーストデータ・コーポレーション、グローバルペイメント及びバンクオブアメリカである。
【発明の開示】
【０００９】
本発明は、クレジットカード取得者及び／又は取引プロセッサに対する購入者／支払人又は供給者／受取人の代わりに３ＰＳＰが請求書品目名データ（レベルIIIデータ）による支払いカードの支払いの認証及び決済を開始することができるシステム及び方法を提供する。支払いの開始は、購入注文書に対して有効にされた予め承認した請求書若しくは注文確認、又は購入者／支払人の組織によって承認されるとともに支払いに対してスケジューリングされた請求書の提出に基づく。
【発明を実施するための最良の形態】
【００１０】
図１及び３は、支払いカード取引の自動化した支払い認証及び決済用のシステムの例を示す。図１に示す実施の形態において、支払いが支払人によって開始され、それに対して、図３に示す実施の形態において、支払いが受取人によって開始される。図１及び３を参照すると、購入者／支払人１００及び供給者／受取人１３０は、好適にはＥＲＰシステム１１０ａ及び１３０ａをそれぞれ有する。ソフトウェアプロバイダ１２０を、調達サービス、請求サービス、提示サービス及び／又は支払いサービスを提供するＥＩＰＰシステム１２０ａのような３ＰＳＰとする。例えば、ソフトウェアプロバイダ１２０を、マスターカードｅ−Ｐ３（登録商標）ＥＩＰＰソリュージョンを提供するXign Corporation（登録商標）とすることができる。
【００１１】
取得者／プロセッサ１６０を、支払いカード取引を処理する金融機関又は取引プロセッサとする。支払いネットワーク１７０を、マスターカード支払いネットワーク（登録商標）のような支払いカードネットワークとする。マーチャントサービス（ＭＳ）支払いゲートウェイ１７０ａを、支払いカード取引の認証及び決済が好適に処理されるゲートウェイとする。発行銀行１４０を、支払いカードを購入者／支払人１１０に発行する銀行とする。ＭＩＳ１５０を、発行銀行１４０の管理情報システムとする。図３のＰＯＳ装置３１０を、販売端末又は任意の同様な従来のシステムのポイントとし、それは、供給者／受取人１３０の位置又はその付近で金融口座データを許容し、報告動作、認証及び取引のロギングのために当該データを支払いネットワークに送信する。
【００１２】
図２は、支払いが購入者／支払人１１０によって開始される支払いカード取引の自動化した支払いの認証及び決済を行う方法の一例を示すフローチャートである。図１及び２を参照すると、ステップ２１０において、購入者／支払人のＥＲＰ１１０ａは、請求書の支払いを承認し及びスケジューリングする。本実施の形態において、購入者／支払人のＥＲＰ１１０ａを、例えば、オラクル（登録商標）ペイアブルシステム(payable system)とする。ステップ２２０において、ソフトウェアプロバイダ１２０は、支払い認証及び決済のために、購入者／支払人のＥＲＰ１１０ａから支払いファイルを抽出し、支払いファイルを取得者／プロセッサ１６０に送信する。例えば、支払いファイルを、オラクルｉＰａｙｍｅｎｔ（登録商標）によるオラクルペイアブル金融システム又はマスターカードｅ−Ｐ３（登録商標）プロバイダにより購入者／支払人のＥＲＰ１１０ａから抽出することができる。
【００１３】
支払いファイルは、マーチャントＩＤと、支払いカード口座情報と、ＥＲＰ請求書の銀行勘定調整に用いられる独自の取引ＩＤとを有し、請求書品目名データ（レベルIIIデータ）を有することができる。マーチャントＩＤを、供給者／受取人１３０の登録処理中に取得することができる。オラクルｉＰａｙｍｅｎｔ（登録商標）のようなソフトウェアプロバイダ１２０は、オラクルペイアブルのような購入者／支払人のＥＲＰ１１０又はソフトウェアプロバイダ１２０の支払いインタフェース１２０ａから支払いカード口座情報を取得することができる。
【００１４】
ステップ２３０において、購入者／支払人１１０の支払いカードの支払い要求は、認証及び決済のためにマスターカード（登録商標）の支払いネットワークのような支払いネットワーク１７０に提供される。ステップ２４０において、支払いカード取引データは、支払いネットワーク１７０から発行銀行のＭＩＳアプリケーション１５０を通じて又は支払いネットワーク１７０から直接購入者／支払人１１０に供給される。好適には、支払いカード取引データは、支払いファイルからの独自の取引ＩＤを有する（ステップ２２０参照）。
【００１５】
ステップ２５０において、ソフトウェアプロバイダ１２０は、取得者／プロセッサ１６０によって提供される銀行取引の銀行勘定調整のために、独自の取引ＩＤを有する支払い送金データを供給者／受取人１３０に提供する。例えば、支払い送金データを、銀行取引の銀行勘定調整のためにオラクルｉＰａｙｍｅｎｔ（登録商標）のようなｅ−Ｐ３（登録商標）プロバイダによって供給者／受取人１３０に提供される。最後に、ステップ２６０において、購入者／支払人１１０は、伝票発行サイクルの最後で発行銀行１４０との支払いカード取引を決済する。
【００１６】
図４は、支払いが供給者／受取人１３０によって開始される支払いカード取引の自動化された支払い認証及び決済の方法の一例を示すフローチャートである。図３及び４を参照すると、ステップ４１０において、購入者／支払人のＥＲＰ１１０ａは、請求書の支払いを承認し及びスケジューリングする。ステップ４２０において、ソフトウェアプロバイダ１２０は、支払い認証及び決済のために、購入者／支払人のＥＰＲシステム１１０ａから支払いファイルを抽出し、（例えば、ｅメールによって）支払いファイルを供給者／受取人１３０に送信する。支払いファイルは、マーチャントＩＤと、支払いカード口座情報と、ＥＲＰの請求書の銀行勘定調整に用いられる独自の取引ＩＤとを有し、請求書品目名データ（レベルIIIデータ）を有することもできる。マーチャントＩＤは、供給者／支払人１３０の登録処理中に取得される。ソフトウェアプロバイダ１２０は、購入者／支払人のＥＲＰ１００ａ又はソフトウェアプロバイダの支払いインタフェース１２０ａから支払いカード口座情報を取得する。
【００１７】
ステップ４３０において、供給者／受取人１３０は、認証及び決済のために支払いカード及び他の取引情報をＰＯＳ装置３１０を通じて取得者／プロセッサ１６０に提供する。取得者／プロセッサは、支払いネットワーク１７０を通じて認証及び決済情報を提供する。ステップ４４０において、ソフトウェアプロバイダ１２０は、整合のために、独自の取引ＩＤを有する請求書品目名データを直接支払いネットワーク１７０に送信する。
【００１８】
ステップ４５０において、支払いカード取引データが、支払いネットワーク１７０から発行銀行のＭＩＳアプリケーション１５０を経て又は支払いネットワーク１７０から直接購入者／支払人１１０に提供される。好適には、支払いカード取引データは、支払いファイルからの独自の取引ＩＤを有する（ステップ４２０参照）。ステップ４６０において、支払い送金データが、銀行勘定調整のために取得者／プロセッサ１６０によって供給者／受取人１３０に提供される。最後に、ステップ４７０において、購入者／支払人１１０は、伝票発行サイクルの最後で発行銀行１４０との支払いカード取引を決済する。
【００１９】
本発明の他の実施の形態を示す。これらの実施の形態は、マスターカードのＰ−Ｃａｒｄ（登録商標）のような購入カードの使用を参照するが、あらゆる支払いカードを代わりに用いることができる。本発明は、供給者／支払人１３０の登録、支払い認証及び／又は決済要求及び応答並びに例外ワークフロー通知を自動化し及び統合する機能を構築する際に、ＥＩＰＰプラットフォーム１２０ａを提供するソフトウェアプロバイダ１２０と取得者／プロセッサ１６０の両方をアシストする。
【００２０】
ここで説明する実施の形態において、好適には、マーチャントサービス（ＭＳ）支払いゲートウェイ１７０ａを用いる。ＭＳゲートウェイ１７０ａを、購入カード取引に対する認証及び決済が好適に処理されるゲートウェイとする。この処理を、バッチモードで満足することができ、この場合、レベルIII取引が、標準的なデータ交換フォーマット、例えば、８１０ＥＤＩフォーマットにおいて周期的な間隔でＭＳゲートウェイ１７０ａに構築され及び送信される。好適には、ＭＳゲートウェイ１７０ａは、取引を適切なロケーションに送信するためにマーチャント識別子（「マーチャントＩＤ」）に基づいて取引を分離する。好適には、ＭＳゲートウェイ１７０ａは、８２４ＥＤＩフォーマットのような標準的なデータ交換フォーマットで認証応答を戻す。認証された取引に対して、ＭＳ支払いゲートウェイ１７０ａは、好適には、提供されたレベルIIIデータによる決済処理を用いて処理を行う。
【００２１】
図５は、本発明の実施の形態による購入カード取引を開始した注文書（ＰＯ）の即時の決済を表すフローチャートである。ステップ５０５において、購入者／支払人１１０は、ＰＯを購入者／支払人１１０のＥＰＲシステム１１０ａからソフトウェアプロバイダのＥＩＰＰシステム１２０ａに電子的に送信する。ステップ５１０において、要求されたフォーマットで一旦ＰＯファイルがＥＩＰＰシステム１２０ａに送信されると、ＰＯロードプロセスは、ＰＯを変換し、分析し及びＥＩＰＰシステム１２０ａにロードするよう起動される。
【００２２】
ステップ５１５において、一旦ＰＯがＥＩＰＰシステム１２０ａにロードされるとともにフォーマット及び構造に対して有効にされると、ＥＩＰＰシステム１２０ａは、ＰＯのポストロード分析(post-load analysis)を開始する。ポストロード分析は、（ｉ）供給者／受取人１３０及び購入者／支払人１１０についての情報がＰＯヘッダで利用できるか否かの決定（ii）支払い方法として提供される購入カード情報の決定及び認証（iii）新たなＰＯ、二重ＰＯ又は変更ＰＯであるかの決定及び更なる処理に対するＰＯへの適切なフラグ立て、並びに（iv）支払い項目すなわち即時のＰＯであるか遅延したＰＯであるかの決定のような一連の基本的な確認を含む。
【００２３】
ステップ５２０において、ポストロードＰＯ分析が完了した後、好適には、ＰＯが更なる処理に対して新たなＰＯとしてフラグを立てるか変更ＰＯとしてフラグを立てるかを決定する。例外の場合、ＰＯは、適切な理由に従ってエラーとしてフラグを立てられ、ステップ５２３の例外キューに進む。ＰＯが変更ＰＯとしてフラグを立てられた場合、ステップ５２５において、ＥＩＰＰシステム１２０ａは、「変更ＰＯ」処理を開始する。元のＰＯが満足されるとともに購入者／支払人１１０と供給者／受取人１３０との間の関係に対して規定したルールに基づくか否かに応じて、システムは、ＰＯに対する変化に適用するよう処理を行い、ＰＯ履歴を発生する。
【００２４】
変更ＰＯの場合、ステップ５２５において適切な処理が一旦完了すると、好適には、ステップ５３０において、変更が有効な変更であるか否か決定する。変更が有効でない場合、ＰＯは、エラーとしてフラグが立てられ、ステップ５２３の例外キューに進む。変化が有効である場合、ＰＯは、供給者／受取人１３０セットアップ情報及び／又はＰＯから取得されるベンダーＩＤ／顧客口座番号の詳細を用いて供給者／支払人１３０の一つ以上の代理業者に送出される。好適には、ＰＯについての情報を知らせるためにｅメール通知を供給者／支払人１３０に送信する。
【００２５】
ステップ５３５において、供給者／受取人１３０の代理業者は、好適には、送られた全てのＰＯの要約を見ることができる。ＰＯが、関連の購入口座番号を有する場合、当該ＰＯに対する要約文は、好適にはそのような場合を表す。また、ＰＯの要約文は、支払い項目が即時であるか否かを表す。供給者／受取人１３０の代理業者は、ＰＯの詳細を見ることを選択できる。ＰＯの詳細のビューを表示することができる。マスクされた購入カード情報をＰＯ詳細ビューで利用することもできる。
【００２６】
ステップ５４０において、ＰＯ要約又はＰＯ詳細ビューから、供給者／受取人１３０の代理業者はＰＯをフリップ(flip)することができる。ＰＯ詳細の（購入者／支払人１１０によって規定されるような）編集可能なインタフェースが代理業者に提供される。この段階でも、購入カード番号はマスクされたままである。供給者／支払人１３０の代理業者は、注文確認に含まれる要素を量に従って選択する。供給者／支払人１３０の代理業者が、（部分的又は全体的な）フリップを実行するよう処理を行うとき、システムは、見積注文確認を発生する。見積注文確認は、ＰＯによって利用可能な場合には予め値が入れられた税及びＦＯＢの編集可能な領域を有する。供給者／受取人１３０は、これらの要素を無効にすることができ、発生した請求書番号を無効にするとともに注文確認を発生するよう処理を行うこともできる。
【００２７】
ステップ５４５において、ＰＯのステータスは「支払い処理」に変化し、ＥＩＰＰ１２０ａは、独自の番号を発生するとともにその番号を注文確認に関連させる。ステップ５５０において、供給者／受取人１３０がＭＳゲートウェイによって取得されたか否かに基づいて、適切な支払い関連処理が開始される。供給者／受取人１３０がＭＳゲートウェイ１７０ａによって取得されない場合、ステップ５５５において、供給者／受取人１３０に提供された注文確認ビューは、マニュアル支払い認証処理を開始するためのオプションを有する。
【００２８】
ステップ５６０において、マニュアルオプションを選択する際に、認証コード及び（システムの日付が予め入れられた）取引日を入力するための編集可能な領域を有する注文確認のビューが供給者／受取人１３０に提供される。独自の番号もこのスクリーン上に表示することができる。この段階において、購入カード番号のマスクを外すことができる。供給者／受取人１３０は、外部のＰＯＳ装置３１０を通じて認証を行い、例えば顧客コードを促されたときに独自の番号をＰＯＳ装置３１０に入力する。
【００２９】
認証された場合、ステップ５６５において、供給者／受取人１３０は、注文確認を認証コード及び取引日によって更新し、「支払済み」として注文確認にフラグを立てる。支払い認証が拒否され又は失敗する場合、このことがｅメールを通じて購入者／支払人１１０と供給者／受取人１３０の両方に知らされ、「失敗」として注文書にフラグが立てられ、注文書が「失敗した認証」要約ビュー又はバスケットに配置される。
【００３０】
ステップ５５０において供給者／支払人１３０がＭＳゲートウェイ１７０ａによって取得された場合、ＥＩＰＰシステム１２０ａは、ステップ５７０に進み、ＭＳゲートウェイ認証及び決済プロセスを行う。好適には、ＭＳゲートウェイ認証及び決済プロセス（ステップ５７０）を、認証／決済ファイルをＥＩＰＰシステム１２０ａによって発生するとともにＭＳゲートウェイ１７０ａに送信するバッチ処理とする。ファイルは、レベルIII決済データを有する。ステップ５７５において、ＥＩＰＰシステム１２０ａは、認証コードを含む応答をＭＳゲートウェイ１７０ａから受信し、認証されたすなわち「支払済み」として注文確認にフラグを立てるとともに認証コードを注文確認に関連する処理を行う。支払い認証が拒否され又は失敗する場合、このことがｅメールを通じて購入者／支払人１１０と供給者／受取人１３０の両方に知らされ、「失敗」として注文書にフラグが立てられ、注文書が「失敗した認証」要約ビュー又はバスケットに配置される。ＭＳに基づく認証に対して、取引は、好適には適切な理由コードを有する。
【００３１】
供給者／受取人１３０は、特定の注文確認を詳細に観察するよう選択するために要約レベルで発生する互いに相違する注文確認の観察のオプションも有することができる。供給者／受取人（ＭＳなし）がフリップ後に何も行わないことを選択することができる所定の注文確認が存在しうる。これらに対して、「マニュアル認証待機」としてフラグを立てる。
【００３２】
一旦「支払済み」として注文確認にフラグが立てられると、ステップ５８０において、関連の情報を、特定のＸＭＬスキーマにおいてマークするとともに、外部に出すことができるＥＩＰＰ１２０ａのＸＭＬファイルに付加することができる。その間、注文確認は、ＥＩＰＰ１２０ａで規定されたルーティング規則に基づいて購入者／支払人１１０に送出される。好適には、文書が注文確認であることを表す請求書／注文確認要約品目名に並列なインジケータが存在する。購入者／支払人１１０は、購入カードの詳細（口座番号の下４桁を除いてマスクされた購入カードの詳細）に従って注文確認の詳細を観察することができる。好適には、購入者／支払人１１０は、支払勘定システムに統合するために注文確認を外部に出すこと以外に注文確認に更なる処理を行わない。
【００３３】
図６は、本発明の実施の形態による購入カード取引を開始したＰＯの遅延決済を表すフローチャートである。ステップ６０５において、購入者／支払人１１０は、ＰＯを購入者／支払人１１０のＥＲＰ１２０ａからソフトウェアプロバイダのＥＩＰＰシステム１２０ａに電子的に送出する。ステップ６１０において、要求されたフォーマットで一旦ＰＯファイルがＥＩＰＰ１２０ａに送信されると、ＰＯロードプロセスは、ＰＯを変換し、分析し及びＥＩＰＰシステム１２０ａにロードするよう起動される。
【００３４】
ステップ６１５において、一旦ＰＯがＥＩＰＰシステム１２０ａにロードされるとともにフォーマット及び構造に対して有効にされると、ＥＩＰＰシステム１２０ａは、ＰＯのポストロード分析を開始する。ポストロード分析は、（ｉ）供給者／受取人１３０及び購入者／支払人１１０についての情報がＰＯヘッダで利用できるか否かの決定（ii）支払い方法として提供される購入カード情報の決定及び認証（iii）新たなＰＯ、二重ＰＯ又は変更ＰＯであるかの決定及び更なる処理に対するＰＯへの適切なフラグ立て、並びに（iv）支払い項目すなわち即時のＰＯであるか遅延ＰＯであるかの決定のような一連の基本的な確認を含む。本実施の形態において、遅延ＰＯは、「請求書の日付から１５日以内に全額を支払うこと」（ｎｅｔ１５）や「請求書の日付から３０日以内に全額を支払うこと」（ｎｅｔ３０）のような支払い項目を有することができる。支払い項目が全く存在しなくてもよく、これは、好適には、遅延ＰＯの特別な場合と考えられる。
【００３５】
ステップ６２０において、ポストロードＰＯ分析が完了した後、好適には、ＰＯが更なる処理に対して新たなＰＯとしてフラグを立てるか変更ＰＯとしてフラグを立てるかを決定する。例外の場合、ＰＯは、適切な理由に従ってエラーとしてフラグを立てられ、ステップ６２３の例外キューに進む。ＰＯが変更ＰＯとしてフラグを立てられた場合、ステップ６２５において、ＥＩＰＰシステム１２０ａは、「変更ＰＯ」処理を開始する。元のＰＯが満足されるとともに購入者／支払人１１０と供給者／受取人１３０との間の関係に対して規定したルールに基づくか否かに応じて、システムは、ＰＯに対する変化に適用するよう処理を行い、ＰＯ履歴を発生する。変更ＰＯの場合、ステップ６２５において適切な処理が一旦完了すると、好適には、ステップ６３０において、変更が有効な変更であるか否か決定する。変更が有効でない場合、ＰＯは、エラーとしてフラグが立てられ、ステップ６２３の例外キューに進む。変化が有効である場合、ＰＯは、供給者／受取人１３０セットアップ情報及び／又はＰＯから取得されるベンダーＩＤ／顧客口座番号の詳細を用いて供給者／支払人１３０の一つ以上の代理業者に送出される。好適には、ＰＯについての情報を知らせるためにｅメール通知を供給者／支払人１３０に送信する。
【００３６】
ステップ６３５において、供給者／受取人１３０の代理業者は、好適には、送られた全てのＰＯの要約を見ることができる。ＰＯが、関連の購入口座番号を有する場合、当該ＰＯに対する要約文は、好適にはそのような場合を表す。ＰＯの要約文は、支払い項目が即時であるか否かを表す。供給者／受取人１３０の代理業者は、ＰＯの詳細を見ることを選択できる。ＰＯの詳細のビューを表示することができる。マスクされた購入カード情報をＰＯ詳細ビューで利用することもできる。
【００３７】
ステップ６４０において、ＰＯ要約又はＰＯ詳細ビューから、供給者／受取人１３０の代理業者はＰＯをフリップすることができる。ＰＯ詳細の（購入者／支払人１１０によって規定されるような）編集可能なインタフェースが代理業者に提供される。この段階でも、購入カード番号はマスクされたままである。供給者／支払人１３０の代理業者は、注文確認に含まれる要素を量に従って選択する。供給者／支払人１３０の代理業者が、（部分的又は全体的な）フリップを実行するよう処理を行うとき、ＥＩＰＰシステムは、見積注文書を発生する。見積注文書は、ＰＯによって利用可能な場合には予め値が入れられた税及びＦＯＢの編集可能な領域を有する。供給者／受取人１３０は、これらの要素を無効にすることができ、発生した請求書番号を無効にするとともに注文確認を発生するよう６４５に進むこともできる。
【００３８】
ステップ６４５において、発生した請求書は、承認及びスケジューリングのために適切な購入者／支払人１１０の代理業者に送出される。ルーティングは、購入者／支払人１１０のルーティングセットアップと、元のＰＯから取得される購入者／支払人１１０のＩＤ及び顧客口座番号についての他の関連の情報とによって決定される。
【００３９】
ステップ６５０において、購入者／支払人１１０の代理業者は、購入者／支払人１１０のＩＤに送出された全ての請求書の要約を見ることができる。好適には、ＰＯの要約は、例えば、特定のロゴの使用や、関連の購入カード取引を有するあらゆるＰＯを表す。購入者／支払人１１０の代理業者は、請求書の詳細を見ることを選択できる。購入カード情報は、このような詳細なビューでも表示される。購入カード番号は、下４桁を除いてマスクされたままである。
【００４０】
ステップ６５５において、購入者／支払人１１０の代理業者は、承認のために請求書を送出する。購入者／支払人１１０の代理業者は、購入者／支払人１１０の組織に対して規定されたワークフローを用いて、請求書を承認し及び／又は請求書を他の代理業者に送出する。ステップ６６０において、ＰＯに何らかの支払い項目が付加されているか否か決定し、そうである場合には、その支払い項目が何であるかを決定する。ＰＯが、明らかに存在する遅延支払い項目を有する場合、発生した請求書は、ステップ６５５においてこれらの項目に基づいてスケジューリングされ及び承認される。例えば、支払い項目がＮｅｔ１５を表す場合、請求書は、好適には、観察のために購入者／支払人１１０が利用できる日付から１５日に支払いがスケジューリングされる。しかしながら、支払い項目が存在しない場合、ステップ６６７において、将来の日付の承認及び支払いに対する請求書をスケジューリングする。ステップ６５５において、請求書が一旦承認されると、承認された請求書は、ステップ６５５での観察のために供給者／受取人に送出される。
【００４１】
ステップ６７０において、スケジューリングされた日付に到達すると、請求書の状態が「支払い処理」に変更される。好適には、独自の番号を発生させるとともに請求書に関連させる。ステップ６７０において、供給者／受取人がＭＳゲートウェイ１７０ａによって取得されたか否かに基づいて、適切な支払い関連プロセスを開始する。供給者／受取人１３０がＭＳゲートウェイ１７０ａによって取得された場合、ＥＩＰＰ１２０ａは、ＭＳゲートウェイ１７０ａの認証及び決済プロセスを行うステップ６７５に進む。
【００４２】
好適には、ＭＳゲートウェイ１７０ａの認証及び決済処理を、認証／決済ファイルをＥＩＰＰ１２０ａによって発生させるとともにＭＳゲートウェイ１７０ａに送信するバッチ処理とする。好適には、ファイルは、レベルIII決済データを有する。ＥＩＰＰ１２０ａは、認証コードを含むＭＳゲートウェイ１７０ａから応答を受け取り、ステップ６８０において、認証されたものすなわち「支払済み」として請求書にフラグを立てるとともに認証コードを請求書に関連させる処理を行う。
【００４３】
支払い認証が拒絶され又は失敗した場合、購入者／支払人１１０と供給者／受取人１３０の両方がその旨をｅメールによって通知され、ステップ６８０において請求書に適切にフラグが立てられ、請求書が「失敗した認証」要約ビュー又はバスケットに配置される。ＭＳゲートウェイ１７０ａの認証に対して、取引は、好適には適切な理由コードを有する。
【００４４】
ステップ６７０において、請求書が予定日に到達して「支払い処理」状態になったときにマーチャントが取得されなかったと決定され、すなわち、「マニュアル認証の待機」として供給者／受取人１３０にフラグが立てられたとき、ステップ６８５において、マニュアル認証プロセスが生じる。供給者／受取人１３０が、マニュアル認証を待機する請求書の詳細を見るとき、支払い処理を開始するオプションが供給者／受取人１３０に提供される。このオプションを選択する際、認証コード及び（システムの日付が予め入った）取引日を入力する編集可能な領域を有する請求書のビューを供給者／受取人１３０に供給する。独自の番号もこのスクリーン上に提示される。この段階において、購入カード番号はマスクされない。供給者／支払人１３０は、外部のＰＯＳ装置を通じて認証を行うとともに、促されたとき、例えば、顧客コードが促されたときに独自の番号をＰＯＳ装置に入力する。一旦認証されると、供給者／受取人１３０は、請求書を認証コード及び取引の日付によって更新し、「支払済み」として請求書にフラグを立てる処理を行う。
【００４５】
支払い認証が拒絶され又は失敗した場合、購入者／支払人１１０と供給者／受取人１３０の両方がその旨をｅメールによって通知され、ステップ６９０において請求書に適切にフラグが立てられ、請求書が「失敗した認証」要約ビュー又はバスケットに配置される。支払い認証が成功した場合、ステップ６９０において、「支払済み」として請求書にフラグが立てられ、ステップ６９５において、外部に送出するために関連の情報がＥＩＰＰ  ＸＭＬファイルに付加される。
【００４６】
図７は、本発明の実施の形態によるＰＯのない購入カード取引の遅延決済を示すフローチャートである。本実施の形態において、ＥＩＰＰシステム１２０ａにロードされるＰＯが存在しない。ここでは、ステップ７１０において、請求書が供給者／受取人１３０によりソフトウェアプロバイダ１２０に電子的に送信される。ソフトウェアプロバイダ１２０において、請求書がステップ７１５でＥＩＰＰ１２０ａにロードされる。請求書ロードプロセス中、ＥＩＰＰ１２０ａは、好適には、供給者／受取人１３０が購入カードを支払方法として許容したか否かを識別する。さらに、購入カードが、（購入者／支払人−供給者／受取人関係レベルで規定された）特定の顧客口座に対してデフォールト支払い方法(default payment method)として規定された場合、ＥＩＰＰシステム１２０ａは、購入カードを請求書に関連させる。
【００４７】
購入者／支払人１１０は、購入カードを用いて支払いを行うよう認証された複数の代理業者を具えるユーザ群をセットアップする。購入者／支払人１１０のアドミニストレータは、カード名義人氏名、カード番号、満了日、ＣＶＣ２コード等の購入カードの詳細を入力するとともに、購入カードを一つ以上のユーザ群に関連させることができる。購入者／支払人１１０のアドミニストレータは、購入カードがある特定の供給者／受取人１３０に対してのみ利用されるとみなすこともできる。
【００４８】
ステップ７１５において、請求書がロードされ、請求書から利用できるルーティング情報に基づいて適切な購入者／支払人１１０の群に請求書が送出される。ルーティングを、ルーティングＩＤ又は顧客口座番号に基づいて行うことができる。ステップ７２０において、購入者／支払人１１０の代理業者は、ルーティングＩＤに送出された全ての請求書の要約を見ることができる。ステップ７２５において、購入者／支払人１１０の代理業者は、請求書を認証し及び／又は購入者／支払人１１０の組織に対して規定されたワークフローを用いて請求書を他の代理業者に送出する。購入者／支払人１１０の代理業者は、支払い方法を「購入カード」として選択することができ、すなわち、「購入カード」は、特定の顧客口座に対するデフォールト支払い方法として予め規定されており、この場合、ＥＩＰＰシステム１２０ａは、請求書に関連した購入カードを既に有する。
【００４９】
ステップ７３０において、一旦「購入カード」が支払いオプションとして確立される場合、請求書は、将来の日付の支払いに対して自動的にスケジューリングされ、又は「スケジューラ」特権を有する購入者／支払人１１０の代理業者によってマニュアルでスケジューリングされる。ステップ７３５において、購入カードの詳細は、自動的に請求書に関連される。ステップ７４０において、請求書は、ステップ７４５で見るために支払いが承認されるとともに供給者／受取人１３０に送出される。
【００５０】
ステップ７５０において、予定日に到達すると、請求書の状態は「支払い処理」に変更され、独自の取引番号を発生させるとともに請求書に関連させる。ステップ７５５において、供給者／受取人１３０がＭＳゲートウェイ１７０ａによって取得されたか否かに基づいて、適切な支払い関連プロセスが開始される。ステップ７６０及び７６５において、供給者／受取人１３０がＭＳゲートウェイ１７０ａによって取得された場合、ＥＩＰＰ１２０ａは、ＭＳゲートウェイ認証及び決済プロセスに進む。ＭＳゲートウェイ認証及び決済を、好適には、認証／決済ファイルをＥＩＰＰシステム１２０ａによって発生するとともにＭＳゲートウェイ１７０ａに送信するバッチ処理とする。認証／決済ファイルは、好適にはレベルIII決済データを有する。
【００５１】
ステップ７７０において、ＥＩＰＰシステム１２０ａは、認証コードを含むＭＳゲートウェイ１７０ａから応答を受け取り、認証されたもの（支払済み）として請求書にフラグを立てるとともに認証コードを請求書に関連させる処理を行う。支払い認証が拒絶され／失敗する場合、購入者／支払人１１０と供給者／受取人１３０の両方はその旨がｅメールによって通知され、請求書は、フラグが立てられるとともに「失敗した認証」要約ビュー／バスケットに配置される。ＭＳゲートウェイ１７０ａの認証に対して、取引は、適切な理由コードを有する。
【００５２】
ステップ７５５においてマーチャントが取得されなかったことを決定した場合、すなわち、「待機マニュアル認証」として供給者／受取人１３０にフラグを立てることを決定した場合、マニュアル認証プロセスがステップ７５５で開始される。供給者／受取人１３０がそのような請求書の詳細（「待機マニュアル認証」）を見ると、支払い処理を開始するオプションが供給者／支払人１３０に提示される。このオプションを選択する際に、認証コード及び（システムの日付が入れられた）取引日を入力する編集可能な領域を有する請求書のビューを供給者／受取人１３０に提供することができる。独自の番号もこのスクリーン上に提示される。この段階では、購入カードの番号は好適にはマスクされない。供給者／受取人１３０は、外部のＰＯＳ装置３１０を通じて認証を行い、例えば顧客コードが促されたときにＰＯＳ装置３１０に独自の番号を入力する。
【００５３】
ステップ７８０において、一旦認証されると、供給者／受取人１３０は、認証コード及び取引日によって請求書を更新し、「支払済み」として請求書にフラグを立てる処理を行う。ステップ７８０において支払い認証が拒絶され／失敗する場合、購入者／支払人１１０と供給者／受取人１３０の両方はその旨がｅメールによって通知され、請求書は、フラグが立てられるとともに「失敗した認証」要約ビュー／バスケットに配置される。ステップ７８５において一旦請求書に「支払済み」としてフラグが立てられると、外部に送出するために、関連情報がマークされ、ＥＩＰＰ１２０ａのＸＭＬファイルに添付される。
【００５４】
ＭＳ認証及び決済を、本発明によるＭＳゲートウェイ認証及び決済のプロセスの一例を示すフローチャートである図８に関連して更に詳細に説明する。好適には、ＭＳ認証及び決済を、組合せのバッチ処理とするが、認証及び決済を個別のプロセスとすることもできる。好適には、ＭＳ認証及び決済をバックエンドプロセスとし、すなわち、ユーザは、プロセスの実行に入るのを見ることができない。
【００５５】
ステップ８２０において、認証／決済取引記録をステップ８１０のトリガに基づいて構成する。好適には、トリガを、注文確認請求書を発生したとき及び請求書が「支払い処理」状態に到達したときとする。このようなトリガが生じると、好適には、基本ファイルを、基本要素のみを有するスケジューリングに基づいて形成する。ＭＳに対する伝送があるときに新たなファイルも構成される。このファイルに対して、好適には、支払い取引がＥＩＰＰシステム１２０ａ内で生じたときに記録が追加される。予め決定されたときに、好適には、ファイルがＭＳゲートウェイ１７０ａに送出され、処理を再開する。
【００５６】
認証／決済取引は、好適には８１０ＥＤＩフォーマットで行われ、レベルIII決済データを有する。独自の取引番号、ＥＩＰＰで発生した整合及び顧客コードも好適にはこの取引の一部とする。認証／決済取引（レベルIII）に対するデータを、好適には（ａ）請求書に提示されるデータ要素、（ｂ）データに関連した購入カード、及び（ｃ）ＭＳマーチャントゲートウェイ１７０ａのセットアップ情報から取得する。好適には、認証／決済取引を、規則的な時間間隔で抽出し、バッチ認証／決済ファイルに添付する。好適にはバックアップファイルも更新される。
【００５７】
ステップ８３０において、認証／決済ファイルは、処理のために予め規定された時間間隔でＥＩＰＰシステム１２０ａを通じてＭＳゲートウェイ１７０ａに送出される。ＭＳゲートウェイ１７０ａは、ソフトウェアプロバイダ１２０に対して規定されたマッピングセットアップに基づいて認証／決済ファイルをマッピングする。ＭＳゲートウェイ１７０ａは、適切に取得されたプラットフォームに対する取引を識別する。この識別に基づいて、更なる処理のために認証／決済ファイルを分割して対応するプラットフォームに送出する。ＭＳゲートウェイ１７０ａは、決済金額の合計値の制限に適合するために認証／決済取引を複数の取引に分割することができる。
【００５８】
ステップ８４０において、認証応答は、ＭＳゲートウェイ１７０ａからＥＩＰＰ１２０ａに戻される。応答は、８２４ＥＤＩフォーマットでＥＩＰＰ１２０ａに戻される。ステップ８５０において、ＥＩＰＰ１２０ａは、認証応答取引を受け取り、個別の応答記録を評価する。応答（失敗したか否か）に基づいて、システムは、対応する請求書を更新する。成功した認証が可能である場合、ソフトウェアプロバイダ１２０から取得した動作を行うことなく決済処理をＭＳゲートウェイ１７０ａによって続ける。決済処理に対して応答がないことがＭＳゲートウェイ１７０ａから予測される。
【００５９】
認証が成功した場合、ステップ８５５において、認証されたものとして請求書にフラグが立てられ、その状態が適切に更新される。ステップ８６０において、請求書の詳細を認証の詳細にも関連させる。これは、供給者／受取人１３０に見える認証コード、取引日等を有する。購入者／支払人１１０は、取引日のみ見ることができる。独自の取引番号、デビット／クレジット等を有する支払い記録の他の詳細も請求書に関連させる。ステップ８６５において、特定の請求書に対して認証が成功したことを表すためにｅメールの通知が供給者／受取人１３０に送出される。ステップ８７０において、ＥＩＰＰ  ＸＭＬファイルに関連した取引を記録のために発生し、好適には必要に応じて外部に送出する。
【００６０】
認証が成功しなかった場合、ステップ８７５において、請求書に対して適切にフラグが立てられ、ステータスが更新される。ステップ８８０において、購入者／支払人１１０及び供給者／受取人１３０の代理業者は、ｅメールによる通知が行われる。最後に、ステップ８８５において、取引が、適切な失敗認証例外「バスケット」に配置される。
【００６１】
ＭＳ認証の失敗の処理を、本発明によるＭＳ認証失敗の処理工程の一例を示すフローチャートである図９に関連して詳細に説明する。ステップ９０５において、ＭＳ認証失敗処理は、好適には、請求書又は注文確認に関連した認証要求が（ｉ）ＭＳゲートウェイ認証及び決済プロセスの一部としてＭＳゲートウェイ１７０ａによって拒否され又は（ii）マニュアル認証及び決済プロセスの一部としてＰＯＳ装置３１０によって拒否されるときに開始される。認証拒否の理由を詳述するデータを、ＭＳゲートウェイ１７０ａの認証応答を通じて又はＭＳゲートウェイ１７０ａによって取得されなかった供給者／受取人１３０の代理業者によるマニュアルエントリによって取得することができる。好適には、ＥＩＰＰシステム「１２０ａは、認証拒否理由を請求書確認に関連付ける。
【００６２】
ステップ９１０において、請求書又は注文確認状態は「認証失敗」に変更される。ステップ９１５において、特定の請求書又は注文確認に対する支払い認証が失敗したことを助言するためにｅメールの通知を購入者／支払人１１０及び供給者／受取人１３０に送信する。ステップ９２０において、購入者／支払人１１０及び供給者／受取人１３０は、特定の請求書又は注文確認の詳細を「認証失敗」要約ビューから見ることを選択でき、この場合、「認証失敗」として請求書にフラグが立てられる。これによって、ＭＳゲートウェイ１７０ａを通じて取得され又は供給者／受取人１３０によって入力された拒否の理由を、請求書又は注文確認の詳細ビューの一部及び理由を説明するとともに拒否の理由を解決するガイダンスを提供する他の情報として購入者／支払人１１０及び／又は供給者／受取人１３０に提示する。
【００６３】
「認証失敗」状態の請求書又は注文確認の詳細ビューの一部として、購入者／支払人１１０は、「現状のままで再実行」又は「支払方法を無効にする」オプションも提供する。購入者及び供給者は、「認証失敗」に対するあり得る理由及び救済策にアクセスするために互いに調べることを選択できる。
【００６４】
ステップ９２５において、購入者／支払人１１０は、支払い処理のために特定の請求書又は注文確認を「現状のままで再実行」することを選択できる。これは、ＥＩＰＰ１２０ａ又は外部調査を通じて取得した拒否の理由がそのような方向に影響を及ぼす場合に生じうる。ステップ９３０において、請求書又は注文確認状態は「支払い処理」に変更される。供給者／支払人１３０をＭＳゲートウェイ１７０ａから取得した場合、ステップ９３５において、ＭＳゲートウェイ１７０ａの認証及び決済手順が実行される。供給者／受取人１３０がＭＳゲートウェイ１７０ａによって取得されない場合、ステップ９４０において、「マニュアル認証待機」として請求書にフラグが立てられ、ステップ９４５において、請求書がマニュアル認証待機であることを助言するためにｅメールが供給者／受取人１３０に送信され、マニュアル認証プロセスが実行される。
【００６５】
ステップ９２５において、購入者／支払人１１０は、請求書又は注文確認に対する元の認証要求に関連した支払方法を無効にすることを選択できる。これは、例えば、ＥＩＰＰ１２０ａ又は外部調査を通じて取得した拒否の理由がそのような方向に影響を及ぼす場合に生じうる。「無効支払い方法」オプションが選択された場合、ステップ９５０において、購入者／支払人１１０は、好適には、一つ以上の他の支払方法を選択するためのビューが提示される。購入者／支払人１１０は、他の購入カードを含む利用できる支払方法のいずれかを関連付けることを選択できる。支払い方法を選択すると、ステップ９５５において、購入者／支払人１１０は、処理のために請求書又は注文確認を送出することができる。ステップ９６０において、請求書又は注文確認状態は「支払い処理」に変更される。
【００６６】
ステップ９５０において、選択された支払い方法が購入カードでない場合、好適には、「既存」システムで規定されるような方法で処理が継続する。選択された支払い方法が購入カードである場合、及び、供給者／受取人１３０がＭＳゲートウェイ１７０ａによって取得された場合、ステップ９３５において、ＭＳゲートウェイ１７０ａの認証及び決済プロセスを開始することができる。供給者／受取人１３０がＭＳゲートウェイ１７０ａによって取得されなかった場合、ステップ９４０において、「マニュアル認証待機」として請求書にフラグが立てられる。ステップ９４５において、請求書がマニュアル認証待機であることを助言するためにｅメールを供給者／受取人１３０に送信し、マニュアル認証プロセスを開始する。ステップ９２５において、請求書又は注文確認の拒否の詳細を見る際に、購入者／支払人１１０は、請求書に関連した購入カード情報を変更ＰＯ取引を通じて変更することを選択できる。これは、例えば、購入者／支払人１１０が全ての関連する請求書又は注文確認に反映した変更を有したい場合又は選択のために購入者／支払人１１０に対して他の支払方法を利用できない場合に生じうる。好適には、これは、ＥＩＰＰ１２０ａ内の請求書に関連したＰＯが存在する場合のみ生じる。
【００６７】
ステップ９６５において、購入者／支払人１１０は、「変更ＰＯ」又は「変更購入カード情報」要求を発する。ステップ９７０において、ＰＯに関連した購入カード情報は、変更ＰＯ要求の情報によって更新される。ステップ９７５において、情報は、まだ「支払済み」状態でない請求書に対して発生した請求書又は注文確認に提供される。ステップ９８０において、「認証失敗」状態にある請求書に対して、状態が「支払い処理」にリセットされる。供給者／受取人１３０がＭＳゲートウェイ１７０ａによって取得された場合、ステップ９３５において、ＭＳゲートウェイ１７０ａの認証及び決済プロセスを開始することができる。供給者／受取人１３０がＭＳゲートウェイ１７０ａによって取得されなかった場合、ステップ９４０において、「マニュアル認証待機」として請求書にフラグが立てられる。ステップ９４５において、請求書がマニュアル認証待機であることを助言するためにｅメールが供給者／受取人１３０に送信され、マニュアル認証プロセスが開始される。
【００６８】
以下の表は、認証及び決済取引をＭＳゲートウェイに送出するためにＥＤＩ８１０フォーマットを利用する方法の一例である。
【００６９】
【表１−１】
2008511085.tif 000003
【００７０】
【表１−２】
2008511085.tif 000004
【００７１】
【表１−３】
2008511085.tif 000005
【００７２】
【表１−４】
2008511085.tif 000006
【００７３】
【表１−５】
2008511085.tif 000007
【００７４】
【表１−６】
2008511085.tif 000008
【００７５】
【表１−７】
2008511085.tif 000009
【００７６】
【表１−８】
2008511085.tif 000010
【００７７】
【表１−９】
2008511085.tif 000011
【００７８】
【表１−１０】
2008511085.tif 000012
【００７９】
【表１−１１】
2008511085.tif 000013
【００８０】
【表１−１２】
2008511085.tif 000014
【００８１】
【表１−１３】
2008511085.tif 000015
【００８２】
【表１−１４】
2008511085.tif 000016
【００８３】
以下の表は、認証応答をソフトウェアプロバイダ１７０に戻すためにＥＤＩ８２４フォーマットをＭＳゲートウェイ１７０ａによって利用する方法の一例を示す。本例では、要求のフォーマットが適切であるか否かを確認するためにＥＤＩ９９７がＭＳゲートウェイ１７０ａによって送出される。
【００８４】
【表２−１】
2008511085.tif 000017
【００８５】
【表２−２】
2008511085.tif 000018
【００８６】
【表２−３】
2008511085.tif 000019
【００８７】
【表２−４】
2008511085.tif 000020
【００８８】
【表２−５】
2008511085.tif 000021
【００８９】
【表２−６】
2008511085.tif 000022
【００９０】
【表２−７】
2008511085.tif 000023
【００９１】
【表２−８】
2008511085.tif 000024
【００９２】
【表２−９】
2008511085.tif 000025
【００９３】
以下の表は、本発明によるＭＳゲートウェイ１７０ａの応答／理由コードの例を説明する。以下の表において、“＊＊”は、ＭＳゲートウェイ１７０ａの発生した応答を表す。
【００９４】
【表３−１】
2008511085.tif 000026
【００９５】
【表３−２】
2008511085.tif 000027
【００９６】
【表３−３】
2008511085.tif 000028
【００９７】
【表３−４】
2008511085.tif 000029
【００９８】
本発明を、所定の好適な実施の形態を参照して説明したが、添付した請求の範囲によって規定したように、種々の変更、変形及び置換は、本発明の範囲を逸脱することなく当業者に既知又は明らかである。
【図面の簡単な説明】
【００９９】
【図１】支払いが支払人によって開始される支払いカード取引の自動化された支払い認証及び決済を行うシステムの一例を示すブロック図である。
【図２】支払いが支払人によって開始される支払いカード取引の自動化された支払い認証及び決済を行う方法の一例を示すフローチャートである。
【図３】支払いが受取人によって開始される支払いカード取引の自動化された支払い認証及び決済を行うシステムの一例を示すブロック図である。
【図４】支払いが受取人によって開始される支払いカード取引の自動化された支払い認証及び決済を行う方法の一例を示すフローチャートである。
【図５】本発明の実施の形態による購入注文を開始した購入カード取引の即時決済を表すフローチャートである。
【図６】本発明の実施の形態による購入注文を開始した購入カード取引の遅延決済を表すフローチャートである。
【図７】本発明の実施の形態によるＰＯのない購入カード取引の遅延決済を表すフローチャートである。
【図８】本発明によるＭＳゲートウェイ認証及び決済のプロセスの一例を示すフローチャートである。
【図９】本発明によるＭＳ認証失敗の処理のプロセスの一例を示すフローチャートである。
【図１】
2008511085.tif 000030
【図２】
2008511085.tif 000031
【図３】
2008511085.tif 000032
【図４】
2008511085.tif 000033
【図５】
2008511085.tif 000034
【図６】
2008511085.tif 000035
【図７】
2008511085.tif 000036
【図８】
2008511085.tif 000037
【図９】
2008511085.tif 000038
【国際調査報告】
2008511085.tif 000039