特許 7554298 電子商取引決済の精算代行システムおよびその方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-09-10

(45)【発行日】2024-09-19

(54)【発明の名称】電子商取引決済の精算代行システムおよびその方法

(51)【国際特許分類】

   G06Q 20/08 20120101AFI20240911BHJP

   G06Q 30/0601 20230101ALI20240911BHJP

【ＦＩ】

G06Q20/08 302

G06Q30/0601

【請求項の数】 10

(21)【出願番号】P 2023013973

(22)【出願日】2023-02-01

(65)【公開番号】P2024109261

(43)【公開日】2024-08-14

【審査請求日】2023-02-01

(73)【特許権者】

【識別番号】397077955

【氏名又は名称】株式会社三井住友銀行

(73)【特許権者】

【識別番号】594103301

【氏名又は名称】三井住友カード株式会社

(74)【代理人】

【識別番号】110001243

【氏名又は名称】弁理士法人谷・阿部特許事務所

(72)【発明者】

【氏名】多木 幹雄

(72)【発明者】

【氏名】立石 崇士

(72)【発明者】

【氏名】渡辺 成彦

(72)【発明者】

【氏名】山田 知義

【審査官】松田 岳士

(56)【参考文献】

【文献】特開２００６－２４４４５９（ＪＰ，Ａ）

【文献】特開２００３－２７１８８９（ＪＰ，Ａ）

【文献】特開２００１－１０９２２４（ＪＰ，Ａ）

【文献】特開２００１－２５６３６７（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

ショッピングサイト利用のＥＣ決済においてサイト経営者およびサイト出店者の各会計システムの間で精算金支払を代行するための精算代行システムであって、
前記サイト経営者の会計システムからデータ送受信部で受信されたＦＢシステム行きの総合振込データの送信済み通知に基づいて、前記総合振込データに含まれる前記サイト出店者別の精算金額データを精算金管理データベースに格納するとともに、前記精算金管理データベースから抽出された前記精算金額データに基づいて振込依頼データを生成し、前記データ送受信部を介して前記ＦＢシステムへ前記振込依頼データを送信する精算金支払処理部と、
前記ＦＢシステムから前記データ送受信部で受信された振込結果データの通知に基づいて、精算金の実振込額に対応する立替金データを生成して立替金管理データベースに格納するとともに、前記立替金管理データベースから抽出された前記立替金データに基づいて請求書データを生成し、前記データ送受信部を介して前記サイト経営者の会計システムへ前記請求書データを送信する立替金受取処理部と
を備えることを特徴とする、精算代行システム。

【請求項2】

前記精算代行システムの保有者は、前記サイト経営者が前記サイト出店者へ支払う必要がある精算金を債務とする併存的債務引受契約を前記サイト経営者と締結する引受人に相当することを特徴とする、請求項１記載の精算代行システム。

【請求項3】

前記ＦＢシステムは、前記引受人が使用契約を金融機関と締結するファームバンキングシステムであり、前記サイト経営者および前記サイト出店者の各会計システムに対して各種の取引情報サービスおよびデータ伝送サービスを提供することを特徴とする、請求項２記載の精算代行システム。

【請求項4】

前記精算金支払処理部は、前記振込依頼データを生成する以前に、前記サイト経営者の会計システムから前記データ送受信部を介して随時受信された総精算金予定額または総精算金確定額を前記精算金管理データベースに格納することを特徴とする、請求項１記載の精算代行システム。

【請求項5】

前記精算金支払処理部は、前記振込依頼データを生成する以前に、前記総精算金予定額または総精算金確定額と、前記サイト経営者から入金されたデポジット金額とを照合することにより、前記振込依頼データの生成用の承認行為を保証することを特徴とする、請求項４記載の精算代行システム。

【請求項6】

前記精算金支払処理部は、前記振込依頼データを生成する以前に、前記総精算金予定額または総精算金確定額に相当する送金承諾書データを、前記データ送受信部を介して前記ＦＢシステムへ送信することを特徴とする、請求項４記載の精算代行システム。

【請求項7】

前記立替金受取処理部は、前記請求書データを生成した以後に、前記サイト経営者の会計システムから前記データ送受信部で受信された立替金の送金予約確証の通知に基づいて、送金予約内容を前記立替金管理データベースに反映することを特徴とする、請求項１記載の精算代行システム。

【請求項8】

前記立替金受取処理部は、前記請求書データを生成した以後に、前記ＦＢシステムから前記データ送受信部で受信された立替金の実振込データの通知に基づいて、前記実振込データを前記立替金管理データベースに振込結果内容として反映することを特徴とする、請求項１記載の精算代行システム。

【請求項9】

精算代行システムにおいて、ショッピングサイト利用のＥＣ決済に関してサイト経営者およびサイト出店者の各会計システムの間で精算金支払を代行するための方法であって、
前記精算代行システムによる実行処理の手順として、
前記サイト経営者の会計システムから受信されたＦＢシステム行きの総合振込データの送信済み通知に基づいて、前記総合振込データに含まれる前記サイト出店者別の精算金額データを精算金管理データベースに格納するステップと、
前記精算金管理データベースから抽出された前記精算金額データに基づいて振込依頼データを生成し、前記ＦＢシステムへ前記振込依頼データを送信するステップと、
前記ＦＢシステムから受信された振込結果データの通知に基づいて、精算金の実振込額に対応する立替金データを生成して立替金管理データベースに格納するステップと、
前記立替金管理データベースから抽出された前記立替金データに基づいて請求書データを生成し、前記サイト経営者の会計システムへ前記請求書データを送信するステップと
を備えることを特徴とする、方法。

【請求項10】

前記精算代行システムの保有者は、前記サイト経営者が前記サイト出店者へ支払う必要がある精算金を債務とする併存的債務引受契約を前記サイト経営者と締結する引受人に相当することを特徴とする、請求項９記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、電子商取引（Electronic Commerce：ＥＣ）の決済を支援するファームバンキング（Firm Banking：ＦＢ）またはエレクトロニックバンキング（Electronic Banking：ＥＢ）に関連する。より詳細には、ＥＣ決済においてサイト経営者および金融機関の間で商品購入代金の立替払として精算金支払代行を実施する精算代行システムおよびその方法に関する。

【背景技術】

【0002】

ＥＣとしての取引は一般に広く普及しており、オンラインショッピングモール型の各種ショッピングサイトが運営されている。これらのショッピングサイトにおいては、多数のショッピングストアが各小売業者によってそれぞれ出店されており、それらのショッピングストア内に展開された各種の商品がエンドユーザー（一般消費者）によって各種の決済方法（例えば、クレジットカード決済、コンビニ決済、代金引換、キャリア決済、銀行振込、電子マネーなど）を通して購入されている。

【0003】

図１は、ショッピングサイト利用のＥＣ決済における従来の形態を概念的に示す図である。図１に示されるように、一般公開のＷｅｂサイトとして構築されたショッピングサイト上に、多数のサイト出店者１１０がショッピングストアをそれぞれ展開しており、そのショッピングストア内に展示される各種商品が、多数のエンドユーザー１２０によって選択的に購入される。その際、商品購入代金の支払いとして、各種の決済機関１３０による決済を経由して間接的に、または、サイト経営者１４０に対して直接的に行うための手続きが実施される。

【0004】

その後、ショッピングサイトのプラットフォーマーであるサイト経営者１４０は、当月間に該当するサイト出店者別の精算金支払データを多数の金融機関１５０に対して指定日（例えば、当月末３営業日前など）までに送付する。続いて、各金融機関１５０は、指定日（例えば、当月末２営業日前など）にサイト出店者別の金融機関口座へ各精算金の振込を実行する。さらに、サイト経営者１４０は、指定日（例えば、翌月初など）に決済機関１３０を経由する購入代金を回収する。

【0005】

また、電子商取引システムとして、モール経営者と小売商店との間における商品代金回収に関する従来技術が開示されている（特許文献１）。この電子商取引システムにおいて、小売商店から購入者が購入した商品の代金回収がモール経営者側で実施されており、そこから手数料等を控除した残金を精算金として、金融機関を介して支払い手続きが行われている。

【先行技術文献】

【特許文献】

【0006】

【文献】特開２００１－２５６３６７号公報

【発明の概要】

【発明が解決しようとする課題】

【0007】

図１に示すようなショッピングサイト利用のＥＣ決済においては、サイト経営者が多数のサイト出店者に代わって商品購入代金を回収する以前に、サイト経営者が商品購入代金の総額として各サイト出店者に対して月毎に支払うことになる。しかしながら、その精算金の金額が比較的多額（例えば、数百億円のスケールなど）に達するため、サイト経営者は、財務的に大きな負担を継続的に強いられることになる。

【0008】

また、ショッピングストアの各サイト出店者は各自の都合にしたがって様々な金融機関に取引口座を設定しているため、サイト経営者は、多種多様な金融機関口座に対して精算金を支払う振込手続を定期的に繰り返し行う必要がある。しかしながら、その振込に対する事務手続は巨額な精算金を多数の金融機関口座に対して分割指示することから、サイト経営者は、多数のシステム間でデータ連携するために手間や時間などにおいても大きな負担を継続的に強いられることになる。

【0009】

本発明は、このような課題を解決するためになされたものであり、サイト経営者が購入代金の回収以前に多数のサイト出店者に対して支払う必要のある精算金の立替払いによって、財務的に大きな負担を継続的に強いられるということがなくなる精算代行システムおよびその方法を提供することを目的とする。また、本発明は、サイト経営者が多数の金融機関に対して分割された各精算金に関する定期的な振込手続きによって、事務的な手間や時間などに大きな負担を継続的に強いられるということがなくなる精算代行システムおよびその方法を提供することを目的とする。

【課題を解決するための手段】

【0010】

上記の課題を解決するために、本発明の一態様として、ショッピングサイト利用のＥＣ決済においてサイト経営者およびサイト出店者の各会計システムの間で精算金支払を代行するための精算代行システムは、サイト経営者の会計システムからデータ送受信部で受信されたＦＢシステム行きの総合振込データの送信済み通知に基づいて、総合振込データに含まれるサイト出店者別の精算金額データを精算金管理データベースに格納するとともに、精算金管理データベースから抽出された精算金額データに基づいて振込依頼データを生成し、データ送受信部を介してＦＢシステムへ振込依頼データを送信する精算金支払処理部と、ＦＢシステムからデータ送受信部で受信された振込結果データの通知に基づいて、精算金の実振込額に対応する立替金データを生成して立替金管理データベースに格納するとともに、立替金管理データベースから抽出された立替金データに基づいて請求書データを生成し、データ送受信部を介してサイト経営者の会計システムへ請求書データを送信する立替金受取処理部とを備えることを特徴とする。なお、精算代行システムの保有者は、サイト経営者がサイト出店者へ支払う必要がある精算金を債務とする併存的債務引受契約をサイト経営者と締結する引受人に相当する。

【発明の効果】

【0011】

本発明によれば、サイト経営者が購入代金の回収以前に多数のサイト出店者に対して支払う必要のある巨額な精算金の立替払いを解消することができる。また、サイト経営者が多数の金融機関に対して分割された比較的少額の各精算金に関する定期的な振込手続きを簡易化することもできる。

【図面の簡単な説明】

【0012】

本明細書において開示される実施形態の詳細な理解は、添付図面に関連して例示される以下の説明から得ることができる。

【図1】ショッピングサイト利用のＥＣ決済における従来の形態を概念的に示す図である。

【図2】本発明の実施形態に係る精算代行システムに関連する各種システムの接続形態を示す構成図である。

【図3】本発明の実施形態に係る精算代行システムに関連する各種システムの処理連携を示す構成図である。

【図4】本発明の実施形態に係る精算代行システムの内部構成を示す構成図である。

【図5】本発明の実施形態に係る精算代行システムを含むシステム間で精算金支払および立替金受取を実行するプロセスを示すフロー図である。

【図6】本発明の実施形態に係る精算代行システムを含むシステム間における様々なデータおよび現金の各フローを示す図である。

【図7】ショッピングサイト利用のＥＣ決済における本発明の実施形態に係る諸当事者の関連を概念的に示す図である。

【発明を実施するための形態】

【0013】

以下に、図面を参照しながら、本発明の実施形態について詳細に説明する。なお、複数の図面において、同一の符号は同一の構成要素を表し、その説明を繰り返すことを省略する。

【0014】

（各種システムの接続形態）
図２は、本発明の一実施形態に係る精算代行システムに関連する各種システムの接続形態を示す構成図である。ここでは、オンラインショッピングモール型に代表されるようなショッピングサイトが、Ｗｅｂサイトとして構築されており、一般公衆に対して通信回線上で公開されて運営されている。そこには、多数の小売業者が、そのショッピングサイトの経営者と結ぶ出店契約に基づいて、ショッピングストアを電子商店としてそれぞれ出店している。各ショッピングストアにおいてＥＣとして売買された商品の購入代金の決済に関して、エンドユーザー（一般消費者）、決済機関、サイト経営者、金融機関およびサイト出店者などの各当事者を介在する電子決済が実施される。

【0015】

図２に示されるように、このような電子決済において、各当事者によって個別に保有される関連システムが通信回線２００を経由してそれぞれ通信可能に接続されている。これらの関連システムとしては、サイト出店者の会計システム２１０、エンドユーザーのショッピングアプリケーション２２０、決済機関の決済システム２３０、サイト経営者の会計システム２４０、併存的債務引受人の精算代行システム２５０、および、金融機関のＦＢシステム２６０が該当する。なお、この通信回線２００は、例えば、電話通信やデータ通信などを実現する公衆回線型ネットワークであってよく、または、特定のシステム間のみを限定的に通信可能に接続する専用回線型ネットワークを一部として含むものであってもよい。また、ＦＢシステム２６０は、併存的債務引受人が使用契約を金融機関と締結するファームバンキングシステムであって、会計システム２１０、会計システム２４０、および精算代行システム２５０に対して各種の取引情報サービスおよびデータ伝送サービスを提供する。

【0016】

会計システム２１０は、各ショッピングストアを運営するサイト出店者が個別に保有するものであり、エンドユーザー（一般消費者）によって購入される商品の決済を管理する。ショッピングアプリケーション２２０は、エンドユーザーが個別に保有するスマートフォン、タブレット、およびパーソナルコンピュータなどに導入され、各ショッピングストアで展開される各種商品の購入用に利用可能なエンドユーザー向けのアプリケーションである。決済システム２３０は、各種決済機関によって運用され、ショッピングアプリケーション２２０において商品購入の代金支払向けの決済を管理するものであり、エンドユーザーに対して各種の決済方法（例えば、クレジットカード決済、コンビニ決済、代金引換、キャリア決済、銀行振込、電子マネーなど）を提供する。

【0017】

会計システム２４０は、ショッピングサイトを経営するサイト経営者が保有するものであり、ショッピングサイトにおける売上に関連する精算金支払、購入代金回収、および立替金支払を管理する。精算代行システム２５０は、サイト経営者と結ぶ併存的債務引受契約（民法４７０条参照）の引受人が保有するものであり、サイト経営者による精算金支払の代行実施を管理する。ＦＢシステム２６０は、併存的債務引受人と保証契約を結ぶ金融機関が展開する金融データ通信サービスであり、併存的債務引受人から各サイト出店者に対する精算金支払と、サイト経営者から併存的債務引受人に対する立替金支払とに必要な口座振込を管理する。なお、併存的債務引受人は、サイト経営者がサイト出店者へ支払う必要がある精算金を債務として、連帯債務関係に入る併存的債務引受契約をサイト経営者と締結している。

【0018】

（各種システムの処理連携）
図３は、本発明の一実施形態に係る精算代行システムに関連する各種システムの処理連携を示す構成図である。図３に示されるように、会計システム２４０は、サイト出店者別の当月分精算金支払のための総合振込データを、サイト経営者によって唯一選択された金融機関のＦＢシステム２６０に対して指定日（例えば、当月末３営業日前など）までに送付する。続いて、精算代行システム２５０は、送金承諾書データをＦＢシステム２６０に対して送付する。続いて、ＦＢシステム２６０は、指定日（例えば、当月末２営業日前など）に各サイト出店者によって指定された金融機関口座に対して、総合振込データに基づく各精算金額の振込を実行する。なお、このような精算金とは、ショッピングサイト利用契約を含む諸契約に基づく各種費用を商品購入代金の総額から差し引いた金額を指すものである。

【0019】

さらに、会計システム２４０は、ショッピングアプリケーション２２０からの購入代金支払、または、決済システム２３０からの購入代金回収により、指定日（例えば、翌月３営業日など）までにエンドユーザーまたは決済機関からサイト経営者への当月分購入代金を回収する。続いて、精算代行システム２５０は、当月分総精算金の実振込額に対応する請求書データを会計システム２４０に対して送付する。続いて、会計システム２４０は、指定日（例えば、翌月５営業日など）に請求書データに基づく立替金振込依頼をＦＢシステム２６０に対して実施する。続いて、ＦＢシステム２６０は、指定日（例えば、翌月５営業日など）に併存的債務引受人によって指定された金融機関口座に対して、前月分立替金額の振込を実行する。

【0020】

（精算代行システムの内部構成）
図４は、本発明の一実施形態に係る精算代行システムの内部構成を示す構成図である。図４に示されるように、精算代行システム２５０は、一般的なサーバ用途向けのコンピュータと同様に構成されるものであり、制御部４１０、主記憶部４２０、インターフェース部４３０、出力部４４０および補助記憶部４５０を備えて、これらがシステムバス４８０を介して相互に通信可能に接続されている。

【0021】

補助記憶部４５０の内部には、各種データの処理を取り扱うアプリケーションプログラムが構築されたデータ送受信部４６０、精算金支払処理部４６２および立替金受取処理部４６４が含まれており、これらに保持されるプログラムが制御部４１０からの呼出し指示に基づいて主記憶部４２０における各種演算を実行する。さらに、補助記憶部４５０の内部には、ファイル／データベースの形式でデータおよびプログラムなどを管理する精算金管理データベース４７０および立替金管理データベース４７２が含まれており、これらに保存されるデータおよびプログラムが制御部４１０の指示に基づいて主記憶部４２０にロードされて、各種演算の処理に使用される。

【0022】

制御部４１０は、中央演算処理装置（ＣＰＵ）として機能し、個別のシステム構成要素に対して動作の制御やデータの演算を実行するものであり、特に補助記憶部４５０に格納されたデータおよびプログラムを主記憶部４２０にロードして各種演算を実行する。主記憶部４２０は、メインメモリとして機能し、制御部４１０の指示に基づいてインターフェース部４３０および補助記憶部４５０から入力された各種データおよびプログラム、ならびに、コンピュータ実行可能な命令などを格納し、これらに対して演算処理された後のデータを保存する。

【0023】

インターフェース部４３０は、外部の会計システム２４０およびＦＢシステム２６０や内部の他システムおよび装置などとの間で各種データを送受信する際にインターフェースとして機能するとともに、システムオペレータから入力された各種コマンドおよびデータ（例えば、各種マスタおよびテーブルのデータなど）を受け付けるインターフェースを提供する。出力部４４０は、各種処理済みのデータをオペレータに表示するための出力データや当該データを印刷するための出力データなどを生成する。

【0024】

なお、精算代行システム２５０の内部構成としての実施形態は、一つのシステム構成体として機能するものであればよい。そのため、実施形態の例として、単体のサーバコンピュータの内部に配置され得るし、各システム構成要素を複数組のユニットとして並列分散化して構成され得るし、または、複数のサーバコンピュータを組み合わせてデータおよびプログラムを共有するように構成され得る。

【0025】

また、補助記憶部４５０において、データ送受信部４６０は、会計システム２４０から受信された当月分精算金額の総合振込データ送信済通知内の総合振込データを精算金管理データベース４７０に格納し、当月分精算金額に対応する送金承諾書データをＦＢシステム２６０へ送信し、前月分立替金額に対応する請求書データを会計システム２４０へ送信する。精算金支払処理部４６２は、精算金管理データベース４７０から抽出された当月分精算金の振込予定額または振込確定額に基づいて当月分精算金振込に関する送金可否を判定し、送金可能な場合に当月分精算金額に対応する送金承諾書データを生成し、そのデータをデータ送受信部４６０に出力する。立替金受取処理部４６４は、精算金管理データベース４７０から抽出された前月分総精算金に基づいて算出された立替金額データを生成して立替金管理データベース４７２に格納し、前月分立替金額に対応する請求書データを生成してデータ送受信部４６０に出力する。

【0026】

精算金管理データベース４７０は、会計システム２４０から受信された各月分精算金の振込予定額または振込確定額と、ＦＢシステム２６０から受信された各月分精算金の実振込額とを、サイト出店者別にそれぞれ管理する。立替金管理データベース４７２は、精算金管理データベース４７０に抽出された各月分精算金の実振込額に基づいて算出された各月分立替金の請求額と、ＦＢシステム２６０から受信された各月分立替金の入金額とを、それぞれ管理する。

【0027】

図５は、本発明の一実施形態に係る精算代行システムを含むシステム間で精算金支払および立替金受取を実行するプロセスを示すフロー図である。図６は、本発明の一実施形態に係る精算代行システムを含むシステム間における様々なデータおよび現金の各フローを示す図である。ここで、図５および６に基づいて、会計システム２４０、精算代行システム２５０およびＦＢシステム２６０の間で行われる当月分精算金支払に関連する各種処理について説明する。

【0028】

（精算金額通知のプロセス）
図５および６に示されるように、当月間の日々においてサイト出店者とエンドユーザーとの間で商品売買契約が成立する毎に、サイト出店者側の会計システム２１０からサイト経営者側の会計システム２４０へ売上明細通知データが送信されることにより、会計システム２４０にサイト出店者別の当月分売上金額が保存される。まず、ステップ５１０において、指定日（例えば、当月初４営業日など）までにサイト出店者別の当月分売上金額に基づく総精算金予定額「１日データ反映額」データが、会計システム２４０から精算代行システム２５０へ送信される。続いて、ステップ５１２において、ＰＤＦファイルのＥメール送信または定型データ転送処理などを介して、精算代行システム２５０のデータ受信部４６０で受信された「１日データ反映額」データが、精算金管理データベース４７０へ即時に格納される。

【0029】

次に、ステップ５１４において、指定日（例えば、当月暦日１６日の翌営業日など）までにサイト出店者別の当月分売上金額に基づく総精算金予定額「１６日データ反映額」データが、会計システム２４０から精算代行システム２５０へ送信される。続いて、ステップ５１６において、ＰＤＦファイルのＥメール送信または定型データ転送処理などを介して、精算代行システム２５０のデータ受信部４６０で受信された「１６日データ反映額」データが、精算金管理データベース４７０へ即時に格納される。なお、このとき、当月分の総精算金予定額としては、「１日データ反映額」および「１６日データ反映額」の合計が相当する。

【0030】

次に、ステップ５１８において、指定日（例えば、当月末４営業日前など）までにサイト出店者別の当月分売上金額に基づく総精算金確定額データが、会計システム２４０から精算代行システム２５０へ送信される。続いて、ステップ５２０において、ＰＤＦファイルのＥメール送信または定型データ転送処理などを介して、精算代行システム２５０のデータ受信部４６０で受信された総精算金確定額データが、精算金管理データベース４７０へ即時に格納される。

【0031】

（精算金支払準備のプロセス）
次に、ステップ５３０において、当月分の総精算金確定額が所定の概算金額を超過する、または、所定の極度額を超過する場合、指定日（例えば、月末３営業日など）までに超過金額（Deposit：デポジット）に対応する振込依頼データが、会計システム２４０からＦＢシステム２６０へ送信される。続いて、ステップ５３２において、定型データ転送処理を介してＦＢシステム２６０で受信された振込依頼データに基づいて、併存的債務引受人側によって指定された金融機関口座へ当該超過金額が即時に入金される。

【0032】

次に、ステップ５３４において、指定日（例えば、当月末３営業日前など）までに当月分の総精算金確定額に基づくサイト出店者別の総合振込データが、会計システム２４０からＦＢシステム２６０へ送信される。続いて、ステップ５３６において、定型データ転送処理を介して総合振込データがＦＢシステム２６０で受信された後に、総合振込データの受信通知データがＦＢシステム２６０から会計システム２４０へ即時に送信される。続いて、ステップ５３８において、定型データ転送処理を介して総合振込データの受信通知データが会計システム２４０で受信された後に、総合振込データの送信済通知データが会計システム２４０から精算代行システム２５０へ即時に送信される。

【0033】

次に、ステップ５４０において、ＰＤＦファイルのＥメール送信または定型データ転送処理などを介して、精算代行システム２５０のデータ受信部４６０で受信された総合振込データ送信済通知データが、精算金管理データベース４７０へ即時に格納される。ここで、併存的債務引受人側で総合振込データの送信内容およびデポジット金額の入金状況などが確認された後に、当月分総精算金確定額の送金実施が承認される。より詳細には、総精算金予定額または総精算金確定額と、サイト経営者から入金されたデポジット金額とを照合することにより、振込依頼データ生成用の承認行為が保証される。

【0034】

次に、ステップ５４２において、精算代行システム２５０の精算金支払処理部４６２によって精算金管理データベース４７０から抽出された当月分精算金データに基づいて生成された総精算金確定額に対応する送金承諾書データが、ＦＢシステム２６０へ送信される。続いて、ステップ５４４において、ＰＤＦファイルのＥメール送信、ＦＡＸ送信、または定型データ転送処理などを介して、総精算金確定額の送金承諾書データがＦＢシステム２６０で即時に受信される。

【0035】

次に、ステップ５４６において、サイト出店者別の精算金振込明細データがサイト経営者側の会計システム２４０から各サイト出店者側の会計システム２１０へそれぞれ送信される。ここでは、サイト出店者別の精算金振込明細の通知は、サイト経営者側がサイト運営用に展開するＷｅｂサイトシステムにおいて、各サイト出店者によって個別に閲覧可能に設定された専用ページに、精算金振込明細内容を入力表示することによって実施されてもよい。

【0036】

（精算金支払実施のプロセス）
次に、ステップ５５０において、指定日（例えば、当月末２営業日前など）に精算代行システム２５０の精算金支払処理部４６２によって生成されたサイト出店者別の当月分精算金額に対応する振込依頼データが、精算代行システム２５０からＦＢシステム２６０へ送信される。続いて、ステップ５５２において、定型データ転送処理を介してサイト出店者別精算金振込依頼データがＦＢシステム２６０で受信された後、各サイト出店者側によって指定された金融機関口座へサイト出店者別精算金の振込が実施される。ここでは、振込依頼元である振込人としては、併存的債務引受の契約内容に基づいてサイト経営者の名義に設定される。

【0037】

次に、ステップ５５４において、金融機関口座情報の不備その他の理由によって振込不能の事態が発生した場合、サイト出店者別の振込不能データがＦＢシステム２６０から精算代行システム２５０および会計システム２４０にそれぞれ送信される。続いて、ステップ５５６において、定型データ転送処理を介して、サイト出店者別の振込不能データが精算代行システム２５０のデータ送受信部４６０で受信された後に、精算金管理データベース４７０に格納される。また、ステップ５５８において、定型データ転送処理を介して、サイト出店者別の振込不能データが会計システム２４０で受信された後に、サイト出店者別に振込不能の原因・理由が確認される。ここで、サイト出店者別の振込不能原因の解消は、サイト経営者側がサイト運営用に展開するＷｅｂサイトシステムにおいて、各サイト出店者によって個別に編集可能に設定された専用ページに、精算金振込先指定の金融機関口座情報を入力表示することによって実施されてもよい。

【0038】

次に、ステップ５６０において、振込不能となったサイト出店者に対する再振込依頼データが、会計システム２４０からＦＢシステム２６０へ送信される。続いて、ステップ５６２において、定型データ転送処理を介して再振込依頼データがＦＢシステム２６０で受信された後、振込不能分の各サイト出店者側によって指定された金融機関口座へサイト出店者別精算金額の再振込が実施される。なお、この再振込用の資金としては、併存的債務引受の契約内容に基づいて、サイト経営者側の資金が利用されるように設定される。

【0039】

（立替金受取実施のプロセス）
次に、ステップ５７０において、指定日（例えば、翌月初１営業日など）に精算代行システム２５０の立替金受取処理部４６４によって精算金管理データベース４７０から抽出された前月分総振込金に基づいて算出された実振込額が前月分立替金額として生成されて立替金管理データベース４７２に格納された後に、前月分立替金額に対応する請求書データが、精算代行システム２５０のデータ送受信部４６０から会計システム２４０へ送信される。ここでは、立替金額としては、総精算金の振込額から振込不能分が差し引かれた実振込額に対して、サイト経営者のデポジット入金額をさらに減算し、消費税を含む精算代行手数料をさらに加算することにより、算出される金額が設定される。

【0040】

次に、ステップ５７２において、ＰＤＦファイルのＥメール送信または定型データ転送処理などを介して、前月分立替金額に対応する請求書データが会計システム２４０で即時に受信される。続いて、ステップ５７４において、指定日（例えば、翌月初４営業日など）までに、すなわち、立替金振込期日の前日までに、前月分立替金額に対応する送金予約確証データが、会計システム２４０から精算代行システム２５０へ送信される。続いて、ステップ５７６において、ＰＤＦファイルのＥメール送信または定型データ転送処理などを介して、前月分立替金額に対応する送金予約確証データが、精算代行システム２５０のデータ送受信部４６０で受信された後に、立替金管理データベース４７２に送金予約内容として格納される。

【0041】

次に、ステップ５７８において、指定日（例えば、翌月初５営業日など）に前月分立替金額に対応する振込依頼データが、会計システム２４０からＦＢシステム２６０へ送信される。続いて、ステップ５８０において、定型データ転送処理を介してＦＢシステム２６０で受信された振込依頼データに基づいて、併存的債務引受人側によって指定された金融機関口座へ前月分立替金額が即時に入金された後に、前月分立替金の実振込データがＦＢシステム２６０から精算代行システム２５０へ送信される。続いて、ステップ５８２において、定型データ転送処理を介して、立替金実振込データが、精算代行システム２５０のデータ送受信部４６０で受信された後に、立替金管理データベース４７２に振込結果内容として格納される。

【0042】

（ＥＣ決済に関連する当事者の連携関係）
図７は、ショッピングサイト利用のＥＣ決済における本発明の一実施形態に係る諸当事者の関連を概念的に示す図である。図７に示されるように、上記で説明された本発明の一実施形態においては、ショッピングサイト利用のＥＣ決済に関連する当事者の連携関係が従来とは異なるものとなる。特に、サイト経営者１４０と金融機関８２０との間には、サイト経営者１４０と併存的債務引受契約を締結する引受人８１０が介在している。

【0043】

この併存的債務引受人８１０は、サイト経営者１４０が商品購入代金を回収する以前に、従来とは異なって振込元として一元化された金融機関８２０を通じて、サイト経営者１４０に代行する形態として、商品購入代金を含む当月分総精算額を各サイト出店者１１０の指定口座に対する振込依頼を実施する。その後に、サイト経営者１４０は、エンドユーザー１２０または決済機関１３０を通して、商品購入代金を回収することが可能になる。そのため、サイト経営者１４０は、従来のように、商品購入代金の総額に相当する当月分精算金を各サイト出店者１１０に対して毎月毎に支払うことに要求される手間や時間などを低減させることがきる。

【0044】

さらにその後に、併存的債務引受人８１０は、前月分総精算金額を前月分立替金としてサイト経営者１４０に請求し、サイト経営者１４０は、前月分立替金を後払いとして金融機関８２０を通じて、併存的債務引受人８１０の指定口座に対する振込依頼を実施する。そのため、サイト経営者１４０は、当月分精算金が比較的多額に達する状況になった場合でも、支払資金が商品購入代金の回収によって充当された後に前月分立替金を支払うことができることから、収支タイミングのズレを回避することによって財務的に大きな負担を継続的に強いられる状況を低減させることができる。

【0045】

なお、ここまで、サイト経営者１４０側の会計システム２４０および併存的債務引受人８１０の精算代行システム２５０は、金融機関８２０のＦＢシステム２６０に対するサイト出店者１１０別の精算金振込データの取り扱いに関して、相互に連携するものの個別に独立して実施している。しかしながら、サイト経営者１４０と併存的債務引受人８１０との間に締結される併存的債務引受の契約内容に基づいて、サイト出店者１１０への弁済を円滑に実施することを目的として、併存的債務引受人８１０が契約するＦＢシステム２６０で使用されるＩＤおよびパスワード等のアカウント情報（例えば、企業コード、会社コード、通信暗証、送信暗証等を含む）を、サイト出店者１１０と共有することも可能となる。

【0046】

このように、本発明の実施形態によれば、精算代行システムおよびその方法は、サイト経営者が購入代金の回収以前に多数のサイト出店者に対して支払う必要のある巨額な精算金の立替払いを解消することができる。また、精算代行システムおよびその方法は、サイト経営者が多数の金融機関に対して分割された比較的少額の各精算金に関する定期的な振込手続きを簡易化することもできる。

【0047】

以上において、例示的な実施形態を参照しつつ本発明の原理を説明したが、本発明の趣旨および範囲を逸脱することなく、構成および細部において変更を受ける様々な実施形態を実現することが可能であることを、当業者は理解する必要がある。すなわち、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様を種々に取ることが可能である。

【符号の説明】

【0048】

１１０ サイト出店者
１２０ エンドユーザー
１３０ 決済機関
１４０ サイト経営者
１５０ 金融機関
２００ 通信回線
２１０ サイト出店者側の会計システム
２２０ ショッピングアプリケーション
２３０ 決済システム
２４０ サイト経営者側の会計システム
２５０ 精算代行システム
２６０ ＦＢシステム
４１０ 制御部
４２０ 主記憶部
４３０ インターフェース部
４４０ 出力部
４５０ 補助記憶部
４６０ データ送受信部
４６２ 精算金支払処理部
４６４ 立替金受取処理部
４７０ 精算金管理データベース
４７２ 立替金管理データベース
８１０ 併存的債務引受人
８２０ 金融機関

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】