JP7621409B2 - 決済管理システム、決済管理方法および決済管理プログラム - Google Patents

Description

この発明は、銀行振込による、商品またはサービスの代金の決済に関する、決済管理システム、決済管理方法および決済管理プログラムに関する。

従来、銀行振込による、商品またはサービスの代金の決済状況（支払い状況）を管理するためのシステムの一例として、商品の購入代金および当該商品の購入代金に係る振込金額を取得し、購入代金を実際に入金された振込金額分減額して更新することにより、過不足金額を管理することができる入金確認通知システムが提案されている（特許文献１参照）。

特許文献１記載の入金確認通知システムでは、過不足金額を検出し、購入者から振り込まれた振込金額が購入代金より少ない場合に、金額が不足している旨を通知するとともに、引き続き、指定口座への不足金額の入金を待機することができる。

しかしながら、特許文献１記載の入金確認通知システムでは、金額が不足している場合に、消費者視点では単に金額が不足している旨の通知が来るだけであり、事業者視点では不足金額の入金を待機するだけであるので、事業者および消費者の双方から見て利便性の観点で改善の余地がある。

特開２０１３－１１４３８９号公報

この発明は、上述の問題に鑑みて、銀行振込による、商品またはサービスの代金の決済に関し、事業者および消費者双方の利便性を向上させることができる、決済管理システム、決済管理方法および決済管理プログラムを提供することを目的とする。

この発明は、商品またはサービスを提供する事業者が使用する事業者端末と、前記商品または前記サービスの提供を受ける利用者が使用する利用者端末と、前記商品または前記サービスの提供に係る取引における代金の振込元となる仕向口座を有する仕向銀行が管理する仕向銀行サーバと、前記代金の振込先となる被仕向口座を有する被仕向銀行が管理する被仕向銀行サーバと、前記利用者端末、前記仕向銀行サーバおよび前記被仕向銀行サーバのそれぞれと通信可能であって、前記仕向口座から前記被仕向口座への前記代金の支払いに係る入金金額を管理する管理サーバとを備え、前記管理サーバは、前記代金に係る請求金額および当該代金の支払い期限を取得する取得手段と、前記支払い期限が到来したときに前記代金の支払いに係る前記入金金額が前記請求金額に対し決済条件を満たしているかどうかを判断する判断手段と、前記判断手段で前記決済条件を満たしていないと判断した場合に、前記利用者端末に金額不足通知を行う金額不足通知手段と、前記金額不足通知を行った場合に前記利用者に金額不足理由を入力させるための理由入力手段と、前記理由入力手段により入力された金額不足理由を前記事業者端末に通知する理由通知手段とを備えた決済管理システム、決済管理方法および決済管理プログラムであることを特徴とする。

この発明により、銀行振込による、商品またはサービスの代金の決済に関し、事業者および消費者双方の利便性を向上させることができる。

この発明の決済管理システムの構成の一例を示す説明図。 利用者端末の構成の一例を示すブロック図。 事業者端末の構成の一例を示すブロック図。 銀行サーバの構成の一例を示すブロック図。 決済管理サーバの構成の一例を示すブロック図。 金額不足処理のフロー図。 金額不足通知画面の画面構成例を示す説明図。 理由入力画面の画面構成例を示す説明図。 延長申請画面の画面構成例を示す説明図。 延長通知画面の画面構成例を示す説明図。 理由通知画面の画面構成例を示す説明図。 変形例の金額判定処理のフロー図。

以下、この発明の一実施形態を図面と共に説明する。
＜システム構成＞

図１は、本発明の決済管理システム１のシステム構成の一例を示すブロック図である。本発明の決済管理システム１は、銀行振込による、商品またはサービスの提供に係る取引における代金の決済（支払い）に関する決済管理サービスを提供するためのシステムである。取引の代金を決済する態様としては、一時的に提供される商品またはサービスの代金を決済する都度決済や、定期的に継続して提供される商品またはサービスの代金を決済する継続決済などがある。本発明の決済管理システム１では、都度決済または継続決済に係る取引において、銀行振込によって代金が支払われる場合を想定している。

図１に示すように、決済管理システム１は、利用者端末２、事業者端末３、銀行サーバ４、および決済管理サーバ５を有している。利用者端末２は、事業者から商品またはサービスの提供を受ける利用者（消費者）が使用する端末である。事業者端末３は、利用者に対し商品またはサービスを提供する事業者（商品販売者またはサービス提供者）が使用する端末である。銀行サーバ４は、商品またはサービスの代金の送金元または送金先となる口座を有している銀行などの金融機関が管理するサーバである。決済管理サーバ５は、決済管理サービスを提供するためのサーバである。

利用者端末２、事業者端末３、銀行サーバ４、および決済管理サーバ５のそれぞれは、インターネット等の通信回線６を介して、相互に通信可能に接続される。ただし、決済管理システム１は、複数の銀行サーバ４を有しており、複数の銀行サーバ４の間（銀行間）の通信は銀行データ通信用の専用回線が使用されることがある。

また、商品またはサービスの代金の送金元となる口座を有している金融機関を仕向銀行といい、商品またはサービスの代金の送金先となる口座を有している金融機関を被仕向銀行という。さらに、本発明では、説明の便宜上、仕向銀行が管理する銀行サーバ４を仕向銀行サーバ４ａといい、被仕向銀行が管理する銀行サーバ４を被仕向銀行サーバ４ｂという。なお、仕向銀行サーバ４ａ，被仕向銀行サーバ４ｂのそれぞれを特に区別しない場合には単に「銀行サーバ４」ということがある。

なお、複数の銀行サーバ４は、利用者のために開設された口座、および／または事業者のために開設された口座を有している銀行が管理することが可能なものである。したがって、複数の銀行サーバ４のそれぞれは、取引の内容に応じて仕向銀行サーバ４ａまたは被仕向銀行サーバ４ｂとしての立場が入れ替わることがある。また、各銀行における口座のうち事業者のために開設された口座としては、事業者のために開設された振込入金専用の仮想口座（バーチャル口座）であることが好ましい。バーチャル口座は、取引毎または利用者毎に口座を割り当てることができる。したがって、被仕向銀行サーバ４ｂにおいて振込（入金）があった場合に取引や利用者を特定することができる。

なお、利用者端末２、事業者端末３、および銀行サーバ４（仕向銀行サーバ４ａ，被仕向銀行サーバ４ｂ）については、説明の便宜上それぞれ１つずつ図示しているが、本発明の決済管理システム１は、複数の利用者、複数の事業者、複数の仕向銀行、複数の被仕向銀行が利用することができ、複数の利用者端末２、複数の事業者端末３、仕向銀行サーバ４ａ、および被仕向銀行サーバ４ｂを有していても良い。

利用者端末２および事業者端末３は、利用者が使用する汎用のコンピュータ（ユーザ端末）である。たとえば、デスクトップＰＣ、ノート（ラップトップ）ＰＣ、タブレットＰＣ、スマートフォン、およびフィーチャーフォン等である。銀行サーバ４および決済管理サーバ５のそれぞれは、汎用のサーバコンピュータ（コンピューティングデバイス）で構成されている。なお、銀行サーバ４および決済管理サーバ５のそれぞれは、１台（単一）のコンピューティングデバイスで構成されていてもよいし、複数のコンピューティングデバイスで構成されていてもよい。また、銀行サーバ４および決済管理サーバ５のそれぞれの一部または全部がクラウドサーバで構成されていてもよい。

図２は利用者端末２の構成の一例を示すブロック図である。図３は事業者端末３の構成の一例を示すブロック図である。図４は銀行サーバ４の構成の一例を示すブロック図である。図５は決済管理サーバ５の構成の一例を示すブロック図である。

図２に示すように、利用者端末２は、制御部２１、入力部２２、表示部２３、通信部２４、および補助記憶部２５を備える。入力部２２、表示部２３、通信部２４、および補助記憶部２５のそれぞれは、制御部２１に通信可能に接続されている。利用者端末２の制御部２１は、演算部２６および主記憶部２７を有しており、利用者端末２における各種演算および制御動作を実行する。

図３に示すように、事業者端末３は、制御部３１、入力部３２、表示部３３、通信部３４、および補助記憶部３５を備える。入力部３２、表示部３３、通信部３４、および補助記憶部３５のそれぞれは、制御部３１に通信可能に接続されている。事業者端末３の制御部３１は、演算部３６および主記憶部３７を有しており、事業者端末３における各種演算および制御動作を実行する。

図４に示すように、銀行サーバ４は、制御部４１、通信部４２、および補助記憶部４３を備える。通信部４２、および補助記憶部４３のそれぞれは、制御部４１に通信可能に接続されている。銀行サーバ４の制御部４１は、演算部４４および主記憶部４５を有しており、銀行サーバ４における各種演算および制御動作を実行する。

図５に示すように、決済管理サーバ５は、制御部５１、通信部５２、および補助記憶部５３を備える。通信部５２、および補助記憶部５３のそれぞれは、制御部５１に通信可能に接続されている。決済管理サーバ５の制御部５１は、演算部５６および主記憶部５７を有しており、決済管理サーバ５における各種演算および制御動作を実行する。

図２～５に示す各演算部（２６、３６、４４、５６）は、ＣＰＵまたはＭＰＵなどを含む演算処理部である。各主記憶部（２７、３７、４５、５７）は、ＲＡＭ（ＤＲＡＭ）などを有している。ＲＡＭは、演算部（２６、３６、４４、５６）のワーク領域およびバッファ領域として用いられる。

図２および図３に示す入力部（２２、３２）は、利用者端末２または事業者端末３の使用者（利用者または事業者の担当者）の操作入力を受け付ける入力部品、および入力部品と制御部（２１、３１）との間に介在する入力検出回路を有している。入力部品は、たとえばタッチパネルまたは／およびハードウェアの操作キーである。タッチパネルとしては、静電容量方式、電磁誘導方式、抵抗膜方式、赤外線方式など、任意の方式のものを用いることができる。入力検出回路は、各入力部品の操作に応じた操作信号ないし操作データ（操作入力データ）を制御部（２１、３１）に出力する。

表示部（２３、３３）は、ディスプレイ、およびディスプレイと制御部（２１、３１）との間に介在する表示制御回路を有している。ディスプレイとしては、たとえばＬＣＤ（液晶ディスプレイ）または有機ＥＬディスプレイなどを用いることができる。

図２～５に示す通信部（２４、３４、４２，５２）は、通信回線６に接続するための通信回路を有している。通信回路は、有線通信回路または無線通信回路であり、演算部（２６、３６、４４、５６）からの指示に従って、通信回線６を介して、外部コンピュータと通信する。また、利用者端末２、事業者端末３、銀行サーバ４および決済管理サーバ５のそれぞれの通信部（２４、３４、４２，５２）は、通信回線６を介さずに、専用回線等で直接相互に通信することも可能である。特に、銀行サーバ４の通信部４２は、銀行データ通信用の専用回線で通信することも可能である。

補助記憶部（２５、３５、４３、５３）は、ＨＤＤ、ＳＳＤ、フラッシュメモリ、ＥＥＰＲＯＭなどの不揮発性メモリで構成され、各演算部（２６、３６、４４、５６）が利用者端末２、事業者端末３、銀行サーバ４、および決済管理サーバ５のそれぞれの動作を制御するためのプログラムおよび本システムの利用に必要な各種データなどを記憶する。

図２に示すように、利用者端末２の補助記憶部２５は、利用者の操作入力に応じて本システムにおける利用者端末２の各種動作を実行するための利用者用プログラム２５ａと、本システムの利用に必要な利用者用データ２５ｂとを記憶している。利用者用プログラム２５ａおよび利用者用データ２５ｂは、必要に応じて補助記憶部２５から読み出され主記憶部２７に記憶される（展開される）。利用者端末２の動作は、演算部２６が主記憶部２７に展開された利用者用プログラム２５ａを実行することによって実現される。

利用者用プログラム２５ａは、少なくとも、外部コンピュータ（たとえば事業者端末３、銀行サーバ４、および決済管理サーバ５）にアクセス（外部コンピュータとの通信を確立）するための通信プログラム、表示部２３に種々の画面を表示させるための表示プログラム、入力部２２を介して利用者からの入力操作を受け付けるための入力プログラム、および利用者端末２が備える各種の機能を選択および実行するためのプログラム等を有している。利用者用データ２５ｂは、少なくとも、本システムにおいて必要な利用者のデータを含む。

図３に示すように、事業者端末３の補助記憶部３５は、事業者端末３の各種動作を実行するための事業者用プログラム３５ａと、本システムの利用に必要な事業者用データ３５ｂとを記憶している。事業者用プログラム３５ａおよび事業者用データ３５ｂは、必要に応じて補助記憶部３５から読み出され主記憶部３７に記憶される（展開される）。事業者端末３の動作は、演算部３６が主記憶部３７に展開された事業者用プログラム３５ａを実行することによって実現される。

事業者用プログラム３５ａは、少なくとも、外部コンピュータ（たとえば利用者端末２、銀行サーバ４、および決済管理サーバ５）にアクセス（外部コンピュータとの通信を確立）するための通信プログラム、取引毎の代金（請求金額）のデータ（請求金額データ）を決済管理サーバ５に通知する請求金額通知プログラム、請求金額データに紐づけられた取引毎の代金の支払い期限のデータ（期限データ）を決済管理サーバ５に通知する期限通知プログラム、入力部３２を介して事業者の担当者（事業者端末３の使用者）からの入力操作を受け付けるための入力プログラム、および事業者端末３が備える各種の機能を選択および実行するためのプログラム等を有している。

図４に示すように、銀行サーバ４の補助記憶部４３は、銀行サーバ４の各種動作を実行するための銀行用プログラム４３ａと、本システムの利用に必要な銀行用データ４３ｂとを記憶している。銀行用プログラム４３ａおよび銀行用データ４３ｂは、必要に応じて補助記憶部４３から読み出され主記憶部４５に記憶される（展開される）。事業者端末３の動作は、演算部４４が主記憶部４５に展開された銀行用プログラム４３ａを実行することによって実現される。

銀行用プログラム４３ａは、少なくとも、外部コンピュータ（たとえば利用者端末２、事業者端末３、他の銀行サーバ４および決済管理サーバ５）にアクセス（外部コンピュータとの通信を確立）するための通信プログラム、利用者の依頼に基づいて他の銀行（被仕向銀行）に対し送金（銀行振込）を行う送金プログラム、他の銀行から振り込まれた（送金された）金額（入金金額）のデータ（入金金額データ）を取引毎に決済管理サーバ５に通知する入金金額通知プログラム、および銀行サーバ４が備える各種の機能を選択および実行するためのプログラム等を有している。

図５に示すように、決済管理サーバ５の補助記憶部５３は、決済管理サーバ５の各種動作を実行するための決済管理用プログラム５４と、本システムの利用に必要な決済管理用データ５５とを記憶している。決済管理用プログラム５４および決済管理用データ５５は、必要に応じて補助記憶部５３から読み出され主記憶部５７に一時的に記憶される。決済管理サーバ５の動作は、演算部５６が主記憶部５７に一時的に記憶された決済管理用プログラム５４を実行することによって実現される。

決済管理用プログラム５４は、少なくとも、決済管理サーバ５が備える各種の機能を選択および実行するためのメイン処理プログラム５４ａ、事業者端末３から通知された請求金額データを管理するための請求金額管理プログラム５４ｂ、銀行サーバ４から通知された入金金額データを管理するための入金金額管理プログラム５４ｃ、請求金額と入金金額とを対比して取引毎に支払い完了（入金完了）かどうかを判断するための金額判断プログラム５４ｄ、取引毎に入金完了の旨や金額不足の旨を利用者（利用者端末２）に通知するための利用者通知プログラム５４ｅ、金額不足の場合に利用者から取引毎に金額不足の理由を取得するための理由取得プログラム５４ｆ、および、入金完了の旨や金額不足の場合に取引毎に金額不足の理由を事業者に通知する事業者通知プログラム５４ｇ等を有している。

決済管理用データ５５は、本システムを利用する利用者のデータである利用者データ５５ａ、本システムを利用する事業者のデータである事業者データ５５ｂ、事業者端末３から通知された取引毎の請求金額データ５５ｃ、取引毎の代金の支払い期限を示す期限データ５５ｄ、銀行サーバ４から通知された取引毎の入金金額データ５５ｅ、取引毎の金額不足の理由を示す理由データ５５ｆ等を有している。利用者データ５５ａは、予め登録されている口座振替用の銀行口座（振替口座）のデータを有している。なお、請求金額データ５５ｃ、期限データ５５ｄ、入金金額データ５５ｅ、および理由データ５５ｆのそれぞれは、取引毎の識別情報（ＩＤ）に紐づけられるなど、取引毎に区別できるような態様で記憶されており、バーチャル口座を用いる場合にはバーチャル口座番号も紐づけられている。

利用者データ５５ａは、利用者端末２と利用者（利用者端末２の使用者）とを紐づけるためのデータを有している。事業者データ５５ｂは、事業者端末３と事業者（事業者端末３の使用者）とを紐づけるためのデータを有している。

なお、上述した利用者端末２の構成、銀行サーバ４の構成、事業者端末３の構成および決済管理サーバ５の構成は、単なる一例であり、これに限定される必要はない。
＜システム動作例＞

以下、決済管理システム１の動作例を説明する。まず、決済管理システム１の動作例を説明する前提となる請求金額データ５５ｃの発生について簡単に説明する。事業者と利用者との間で商品またはサービスの提供に係る取引を行った場合、事業者端末３は、取引の代金（請求金額）のデータ（請求金額データ）および当該請求金額データに紐づけられた支払い期限のデータ（期限データ）を決済管理サーバ５に通知する。決済管理サーバ５は、事業者端末３から通知された請求金額データおよび期限データを請求金額データ５５ｃおよび期限データ５５ｄとして記憶する。また、利用者が自身の口座（仕向銀行の口座）などから取引の代金を支払うための事業者の口座（被仕向銀行の口座）に振込（送金）を行った場合、被仕向銀行サーバ４ｂは、仕向銀行の口座から振り込まれた（送金された）金額（入金金額）のデータ（入金金額データ）を決済管理サーバ５に通知する。決済管理サーバ５は、被仕向銀行サーバ４ｂから通知された入金金額データを入金金額データ５５ｅとして記憶する。なお、上述したように、請求金額データ５５ｃ、期限データ５５ｄ、および入金金額データ５５ｅは、取引毎に区別できるような態様で記憶されている。
＜金額不足処理＞

図６は金額不足処理のフロー図である。図７は通知メール１００の画面構成例を示す説明図である。図８は理由入力画面１１０の画面構成例を示す説明図である。図９は延長申請画面１２０の画面構成例を示す説明図である。図１０は延長通知画面１３０の画面構成例を示す説明図である。図１１は、理由通知画面１４０の画面構成例を示す説明図である。以下、図６～図１１を参照して利用者に金額不足の通知を行う金額不足処理について説明する。なお、金額不足の場合に実行する金額不足処理は、事業者の設定により支払い期限を所定期間だけ自動的に延長する自動延長処理と、利用者に延長申請された場合に所定期間だけ支払い期限を延長する手動延長処理がある。決済管理サーバ５（制御部５１）は、まず事業者により自動延長処理の設定がされているか確認し、されていれば自動的に所定期間だけ支払い期限を延長し、図１０の延長通知画面１３０を表示する。事業者により自動延長処理の設定がなされていなければ、図６に示す金額不足処理を実行する。

図６に示す金額不足処理は、利用者端末２、銀行サーバ４および事業者端末３等と連携して、決済管理サーバ５（制御部５１）で行われる処理である。金額不足処理は、或る取引の支払い期限が到来したときに当該取引の代金の支払いが決済条件を満たしていない場合に実行される。たとえば、決済条件は、当該取引の入金金額が請求金額以上の金額（同額を含む）であるかどうかであり、入金金額が請求金額以上であれば決済条件を満たしていると判断され、入金金額が請求金額未満であれば決済条件を満たしていないと判断される。なお、支払い期限が到来したときに決済条件を満たしていると判断された場合には、金額不足処理は実行されない。

図６に示すように、決済管理サーバ５は、金額不足処理を開始すると、金額不足を利用者（金額不足となった取引における被請求者）が使用する利用者端末２に通知し（ステップＳ１）、金額不足理由の入力に進むかどうかを判断する（ステップＳ２）。

たとえば、決済管理サーバ５は、ステップＳ１において、図７に示すような内容の通知メール１００を利用者（被請求者）の利用者端末２に通知する。通知メール１００は、不足通知部１０１と、理由入力用リンク１０２とを有している。

不足通知部１０１は、通知メール１００の本文となるものであり、入金金額が請求金額に対し不足している旨を通知するような内容の文によって構成される。不足通知部１０１には、入金金額が請求金額に対し不足している旨、不足金額、金額不足理由の入力を促す旨等の情報が含まれる。また、図７に示す例では、不足通知部１０１には、理由入力用リンク１０２の有効期限（回答期限）の情報が含まれる。この不足通知部１０１の通知は、振込手数料を事業者が負担しない場合は請求額から入金金額（被仕向け銀行への着金金額）を減算した不足金額を明示し、振込手数料を事業者が負担する場合はそれ以外の形式での不足の表示（例えば不足である旨、請求額から入金金額を減算した金額とそれに振込手数料を加算した金額の範囲を示す表示など）とすることができる。これにより、事業者側の都合に応じつつ、かつ利用者にできるだけわかりやすい通知とすることができる。

理由入力用リンク１０２は、決済管理サーバ５にアクセスし、金額不足理由を入力するためのＷＥＢページを表示させるためのハイパーリンクである。理由入力用リンク１０２は、ＷＥＢページを表示させるためのＵＲＬ等の文字を表示した文字リンクであってもよいし、画像リンクやボタン式のリンクであってもよい。

なお、通知メール１００に代えて、不足通知部１０１および理由入力用リンク１０２を有し通知メール１００に相当するポップアップ画面として利用者端末２に通知することもできる。

図６に戻って、決済管理サーバ５は、理由入力用リンク１０２が選択されない場合には金額不足理由の入力に進むと判断せず（ステップＳ２：ＮＯ）、金額不足理由の入力期限（回答期限）まで待機する。理由入力用リンク１０２が選択されないまま金額不足理由の入力期限（回答期限）が到来した場合には金額不足処理を終了する。

一方、決済管理サーバ５は、ステップＳ２において、たとえば理由入力用リンク１０２が選択された場合には金額不足理由の入力に進むと判断（ステップＳ２：ＹＥＳ）し、金額不足理由を入力するためのＷＥＢページを利用者端末２の表示部２３に表示させ（ステップＳ３）、金額不足理由が入力されたかどうかを判断する（ステップＳ４）。

たとえば、決済管理サーバ５は、ステップＳ３において、図８に示すような内容の理由入力画面１１０を利用者（被請求者）の利用者端末２に表示（通知）する。理由入力画面１１０は、通知部１１１と、理由入力部１１２と、入金完了予定日入力部１１３とを有している。

通知部１１１は、金額不足理由の入力を促すような通知文１１１ａおよび金額不足理由を入力できる期間の終期（回答期限または入力期限）を示す期限表示部１１１ｂによって構成される。

理由入力部１１２は、金額不足理由を入力するために設けられている。たとえば、理由入力部１１２は、予め設定された複数種類の金額不足理由の候補のそれぞれに対応した選択肢を提示する。

本実施形態では、理由入力部１１２は、複数種類の金額不足理由の候補のそれぞれに割り当てられた複数の選択ボタン１１２ａ～１１２ｃを有している。なお、選択ボタン１１２ａ～１１２ｃは、いわゆるソフトウェアキー（操作ボタン）として機能する。以下、ソフトウェアキーを単に「ボタン」という。具体的には、理由入力部１１２は、金額不足理由として利用者が振込金額を間違えた場合に相当する「振込金額の間違い」が割り当てられた選択ボタン１１２ａと、金額不足理由として振込金額に上限金額が設定されていた場合であって上限金額が請求金額未満であった場合に相当する「振込金額の上限制限」が割り当てられた選択ボタン１１２ｂと、金額不足理由として「振込金額の間違い」および「振込金額の上限制限」以外の理由に相当する「その他」が割り当てられた選択ボタン１１２ｃとを有している。なお、理由入力部１１２は、選択ボタン１１２ａ～１１２ｃに代えて、複数種類の金額不足理由の候補のそれぞれに割り当てられたチェックボックスまたはラジオボタン、若しくは金額不足理由を示す文字の入力を受け付けるテキストボックス（入力欄）を有していてもよい。入金完了予定日入力部１１３は、不足金額の入金完了予定日を入力するために設けられている。たとえば、入金完了予定日入力部１１３は、入金完了予定日の日付を入力するためのテキストボックス（入力欄）１１３ａを有している。ただし、入金完了予定日は、支払期限よりも前の日に限り設定することができる。

図６に戻って、決済管理サーバ５は、ステップＳ４において、金額不足理由が入力されない場合には（ステップＳ２：ＮＯ）、金額不足理由が入力されるまで待機する。ただし、金額不足理由が入力されないまま金額不足理由の入力期限（回答期限）が到来した場合には金額不足処理を終了する。

一方、理由入力部１１２において金額不足理由が入力された場合には、入力された金額不足理由を取得し（ステップＳ５）、支払い期限を延長するための延長申請画面を利用者端末２の表示部２３に表示させ（ステップＳ６）、延長申請があるかどうか（延長申請がされたかどうか）を判断する（ステップＳ７）。

たとえば、決済管理サーバ５は、ステップＳ６において、図９に示すような延長申請画面１２０を利用者（被請求者）の利用者端末２に表示（通知）する。延長申請画面１２０は、内容通知部１２１と、期限通知部１２２と、延長要否選択部１２３とを有している。

内容通知部１２１は、支払い期限の延長申請が可能であることを通知するような文によって構成されている。期限通知部１２２は、延長申請を行うことができる期限（延長申請期限）の日付と、延長後の支払い期限の日付とを通知する文字によって構成されている。延長申請を行うことができる期限および延長後の支払い期限のそれぞれの日付は、取引毎に事業者によって予め設定されている。

延長要否選択部１２３は、延長申請を行うかどうかを選択するために設けられている。たとえば、延長要否選択部１２３は、延長申請を行う場合と延長申請を行わない場合のそれぞれに対応した選択肢を提示する。本実施形態では、延長要否選択部１２３は、延長申請を行う場合に割り当てられた選択ボタン１２３ａと、延長申請を行わない場合に割り当てられた選択ボタン１２３ｂを有している。なお、延長要否選択部１２３は、選択ボタン１２３ａ，１２３ｂに代えて、延長申請を行う場合と延長申請を行わない場合のそれぞれに割り当てられたチェックボックスまたはラジオボタンを有していてもよい。

図６に戻って、決済管理サーバ５は、ステップＳ７において、延長要請がないと判断すれば、利用者に代金の支払い意志が無いものとして未収金（未回収代金）回収処理へ移行し（ステップＳ８）、金額不足処理を終了する。ここで、延長要請がない場合とは、延長要否選択部１２３で延長申請を行わない場合に割り当てられた選択肢（本実施形態では選択ボタン１２３ｂ）が選択された場合や、延長申請を行うことができる期限までに延長申請を行う場合に割り当てられた選択肢が選択されなかった場合等がある。ここで、被仕向口座がバーチャル口座の場合は、決済管理サーバ５が仕向銀行サーバ４ａまたは被仕向銀行サーバ４ｂにバーチャル口座を削除するよう削除指示する。これにより未収金回収処理を進めている間に入金されてしまうことを防止できる。また、未収金回収処理に移行すると、通常の支払い方法とは別の方法で未収金（未回収代金）の回収を行う。なお、未収金回収処理の具体的な方法については本発明の本質的部分ではないことと、取引毎に個別に払込票を利用者に郵送する等、公知の方法を用いることができるため、詳しい説明は省略する。

ステップＳ７において、延長要請があると判断すれば、すなわち、延長申請を行うことができる期限までに延長申請を行う場合に割り当てられた選択肢（本実施形態では選択ボタン１２３ａ）が選択された場合には、支払い期限を延長する（ステップＳ９）。そして、支払い期限を延長すると（ステップＳ９）、延長後の支払い期限を利用者端末２に通知し（ステップＳ１０）、入金完了予定日、金額不足理由、および延長後の支払い期限を事業者端末３に通知し（ステップＳ１１）、金額不足処理を終了する。被仕向口座がバーチャル口座の場合は、決済管理サーバ５が延長後の支払い期限までは削除しないように仕向銀行サーバ４ａまたは被仕向銀行サーバ４ｂに継続指示をする。なお、バーチャル口座開設時にバーチャル口座の開設期間を延長後の支払い期限も含むように長く設定されていた場合は特に継続指示をしない構成としてもよい。また、延長後の支払い期限が到来したときに当該取引の代金の支払いが決済条件を満たしていない場合には、金額不足処理は実行されず、未収金回収処理に移行する。

ここで、決済管理サーバ５は、ステップＳ９において、電子メールまたはポップアップ画面等によって延長後の支払い期限を利用者（被請求者）の利用者端末２に表示（通知）する。たとえば、決済管理サーバ５は、ステップＳ９において、図１０に示すような内容の延長通知画面１３０を利用者（被請求者）の利用者端末２に通知する。延長通知画面１３０は、支払い期限が延長されたことを通知する延長通知部１３１と、延長後の支払い期限の日付を通知する延長期限通知部１３２と、請求金額を通知する金額通知部１３３とを有している。

また、決済管理サーバ５は、ステップＳ１０において、電子メールまたはポップアップ画面等によって入金完了予定日、金額不足理由、および延長後の支払い期限を事業者（請求者）の事業者端末３に表示（通知）する。たとえば、決済管理サーバ５は、ステップＳ１０において、図１１に示すような内容の理由通知画面１４０を事業者（請求者）の事業者端末３に通知する。理由通知画面１４０は、金額不足理由を通知する理由通知部１４１と、延長後の支払い期限を通知する延長期限通知部１４２と、入金完了予定日を通知する入金予定通知部１４３とを有している。

以上のように、本発明の決済管理システム１では、支払い期限が到来したときに代金の支払いに係る入金金額が請求金額未満の場合（金額不足の場合）に、利用者（被請求者）によって入力された金額不足理由を取得し、金額不足理由を事業者（請求者）に通知する。従来では、金額不足の場合には、事業者の担当者が利用者に訪問、電話または電子メール等により問い合わせを行い、金額不足理由や入金完了予定日を人為的に取得していたが、本発明によればこのような手間を省くことができる。

また、本発明によれば、予め設定された複数種類の金額不足理由の候補のそれぞれに対応した選択肢を利用者に提示するので、利用者は選択肢を選択するだけでよく、利用者の利便性を向上させることができる。

さらに、本発明によれば、入金金額が請求金額に対し不足していると判断された場合に、支払い期限の延長要請の要否を利用者に選択させ、支払い期限の延長要請があった場合に、支払い期限を所定期間延長するので、利用者の利便性を向上させることができる。また、金額不足の場合に自動的に支払い期限を延長すると事業者によって設定されていた場合は、利用者に問い合わせずに自動的に支払い期限を所定期間延長する。この場合は、利用者が延長申請せずとも延長された支払い期限内に入金が可能となるため、利用者の利便性が向上するとともに、事業者の利便性も向上する。
＜変形例の金額判断処理＞

上述の実施形態では、決済条件は、取引の代金の支払いに係る入金金額が請求金額以上の金額であるかどうかとしたが、これに限定される必要は無く、柔軟に決済条件を設定することができる。

図１２は変形例の金額判定処理のフロー図である。図１２に示す金額判定処理は、利用者端末２、銀行サーバ４および事業者端末３等と連携して、決済管理サーバ５（制御部５１）で行われる処理である。

決済管理サーバ５は、金額判定処理を開始すると、被仕向銀行サーバ４ｂから直接的または間接的に入金金額を取得し（ステップＳ２１）、事業者が振込手数料を負担するかどうかを判断する（ステップＳ２２）。

たとえば、決済管理サーバ５は、ステップＳ２１において、入金がある度に入金金額を取得するか、あるいは支払い期限が到来したときにそれまで入金された金額の合計（合計金額）を入金金額として取得することができる。

また、決済管理サーバ５は、ステップＳ２２において、事業者が振込手数料を負担しないと判断した場合、請求金額を、決済条件を満たすかどうかを判定するための基準となる判定処理用の金額（判定金額）に設定し（ステップＳ２３）、後述するステップＳ２５に進む。一方、事業者が振込手数料を負担すると判断した場合、請求金額および振込手数料相当金額に基づく許容範囲を判定金額に設定し（ステップＳ２４）、ステップＳ２５に進む。なお、この許容範囲は事業者毎に任意の範囲に設定されており、その事業者の許容範囲を判定金額に設定する。

続いて、ステップＳ２５で、入金金額が判定金額以上かどうかを判断する。なお、ステップＳ２５では、ステップＳ２４にて許容範囲が判定金額に設定されている場合、入金金額が許容範囲の下限の金額以上かどうかを判断する。ステップＳ２５において、入金金額が判定金額以上でない、すなわち入金金額が判定金額未満であると判断した場合（ステップＳ２５：ＮＯ）、上述した金額不足処理（ステップＳ２６）に移行し、金額判定処理を終了する。

一方、ステップＳ２５において、入金金額が判定金額以上であると判断した場合（ステップＳ２５：ＹＥＳ）、入金金額が判定金額を超過しているかどうかを判断する（ステップＳ２７）。なお、ステップＳ２７では、ステップＳ２４にて許容範囲が判定金額に設定されている場合、入金金額が許容範囲の上限の金額を超過しているかどうかを判断する。

ステップＳ２７において、入金金額が判定金額を超過していると判断した場合（ステップＳ２７：ＹＥＳ）、超過分の金額を利用者に返金するための返金処理（ステップＳ２８）に移行し、金額判定処理を終了する。たとえば、返金処理では、事業者の担当者が利用者に返金金額および返金方法を連絡するか、あるいは、利用者（利用者端末２）に返金金額および返金方法を連絡する電子メールが決済管理サーバ５から自動的に送信される。利用者は、電子メールなどの適宜の方法で返金先口座を事業者に連絡する。

一方、ステップＳ２７において、入金金額が判定金額を超過していない、すなわち入金金額が判定金額に含まれているまたは入金金額が判定金額と一致すると判断した場合（ステップＳ２７：ＮＯ）、入金完了の旨を電子メールまたはポップアップ画面等によって利用者（被請求者）の利用者端末２に通知し（ステップＳ２９）し、金額判定処理を終了する。

以上のように、本発明の金額判定処理では、すなわち、事業者が振込手数料を負担する場合であれば、請求金額および振込手数料相当金額に基づく許容範囲内である場合に決済条件を満たしていると判断し、事業者が振込手数料を負担しない場合であれば、入金金額が請求金額と一致した場合に決済条件を満たしていると判断する。したがって、取引の実用に合わせて柔軟に決済条件を設定することができ、事業者および利用者の双方の利便性を向上させることができる。

また、従来では、利用者が振込を行った際、仕向銀行から「振込完了」の通知は来るが、被仕向銀行への「着金完了」通知は来なかった。これに対し、本発明の金額判定処理では、入金金額が判定金額に含まれているまたは入金金額が判定金額と一致すると判断した場合に、入金完了の旨を利用者に通知するので、被仕向銀行に送金できたか確認することができ、利用者の安心感につながるという利点がある。

この発明の管理サーバは上記実施形態の決済管理サーバ５に対応し、利用者端末は利用者端末２に対応し、事業者端末は事業者端末３に対応し、仕向銀行サーバは仕向銀行サーバ４ａに対応し、被仕向銀行サーバは被仕向銀行サーバ４ｂに対応し、管理サーバは、決済管理サーバ５に対応し、取得手段は、請求金額管理プログラム５４ｂおよびこれに従って動作する制御部５１に対応し、判断手段は、金額判断プログラム５４ｄおよびこれに従って動作する制御部５１に対応し、金額不足通知手段は、不足通知部１０１に対応し、理由入力手段は、理由入力部１１２に対応し、理由通知手段は、理由通知部１４１に対応し、入金完了通知手段は、ステップＳ２９に対応し、延長申請要否選択手段は、延長要否選択部１２３に対応し、支払い期限延長手段は、選択ボタン１２３ａに対応するが、この発明は本実施形態に限られず他の様々な実施形態とすることができる。また、上述の実施形態で挙げた画面および具体的な構成等は一例であり、実際の製品に応じて適宜変更することが可能である。

この発明は、銀行振込による、商品またはサービスの代金の決済に関する産業に利用することができる。

１…決済管理システム
２…利用者端末
３…事業者サーバ
４…銀行サーバ
４ａ…仕向銀行サーバ
４ｂ…被仕向銀行サーバ
５…決済管理サーバ
５１…制御部

Claims (7)

1. 商品またはサービスを提供する事業者が使用する事業者端末と、
   前記商品または前記サービスの提供を受ける利用者が使用する利用者端末と、
   前記商品または前記サービスの提供に係る取引における代金の振込元となる仕向口座を有する仕向銀行が管理する仕向銀行サーバと、
   前記代金の振込先となる被仕向口座を有する被仕向銀行が管理する被仕向銀行サーバと、
   前記利用者端末、前記仕向銀行サーバおよび前記被仕向銀行サーバのそれぞれと通信可能であって、前記仕向口座から前記被仕向口座への前記代金の支払いに係る入金金額を管理する管理サーバとを備え、
   前記管理サーバは、
   前記代金に係る請求金額および当該代金の支払い期限を取得する取得手段と、
   前記支払い期限が到来したときに前記代金の支払いに係る前記入金金額が前記請求金額に対し決済条件を満たしているかどうかを判断する判断手段と、
   前記判断手段で前記決済条件を満たしていないと判断した場合に、前記利用者端末に金額不足通知を行う金額不足通知手段と、
   前記金額不足通知を行った場合に前記利用者に金額不足理由を入力させるための理由入力手段と、
   前記理由入力手段により入力された金額不足理由を前記事業者端末に通知する理由通知手段とを備えた
   決済管理システム。
2. 前記理由入力手段は、予め設定された複数種類の金額不足理由の候補のそれぞれに対応した選択肢を前記利用者に提示する
   請求項１記載の決済管理システム。
3. 前記管理サーバは、
   前記判断手段で前記決済条件を満たしていると判断された場合に、前記利用者端末に入金完了通知を行う入金完了通知手段をさらに備えた
   請求項２記載の決済管理システム。
4. 前記判断手段は、
   前記事業者が振込手数料を負担する場合であれば、前記入金金額および振込手数料相当金額に基づく金額の範囲内である場合に前記決済条件を満たしていると判断し、
   前記事業者が振込手数料を負担しない場合であれば、前記入金金額が前記請求金額と一致した場合に前記決済条件を満たしていると判断する構成である
   請求項１記載の決済管理システム。
5. 前記管理サーバは、
   前記判断手段で前記入金金額が前記請求金額に対し不足していると判断された場合に、前記支払い期限の延長要請の要否を利用者に選択させるための延長申請要否選択手段と、
   前記延長要請があった場合に、前記支払い期限を所定期間延長する支払い期限延長手段とをさらに備えた
   請求項１ないし４のいずれかに記載の決済管理システム。
6. 商品またはサービスを提供する事業者が使用する事業者端末と、
   前記商品または前記サービスの提供を受ける利用者が使用する利用者端末と、
   前記商品または前記サービスの提供に係る取引における代金の振込元となる仕向口座を有する仕向銀行が管理する仕向銀行サーバと、
   前記代金の振込先となる被仕向口座を有する被仕向銀行が管理する被仕向銀行サーバと、
   前記利用者端末、前記仕向銀行サーバおよび前記被仕向銀行サーバのそれぞれと通信可能であって、前記仕向口座から前記被仕向口座への前記代金の支払いに係る入金金額を管理する管理サーバとを備えた決済管理システムにおける決済管理方法であって、
   前記管理サーバが、
   前記代金に係る請求金額および当該代金の支払い期限を取得し、
   前記支払い期限が到来したときに前記代金の支払いに係る前記入金金額が前記請求金額に対し決済条件を満たしているかどうかを判断し、
   前記決済条件を満たしていないと判断した場合に、前記利用者端末に通知する金額不足通知を行うための情報を生成し、
   前記利用者端末に前記金額不足通知を取得させて、前記利用者に金額不足理由を入力させ、
   入力された金額不足理由を前記事業者端末に通知する
   決済管理方法。
7. 商品またはサービスを提供する事業者が使用する事業者端末と、前記商品または前記サービスの提供を受ける利用者が使用する利用者端末と、前記商品または前記サービスの提供に係る取引における代金の振込元となる仕向口座を有する仕向銀行が管理する仕向銀行サーバと、前記代金の振込先となる被仕向口座を有する被仕向銀行が管理する被仕向銀行サーバとのそれぞれと通信可能であって、前記仕向口座から前記被仕向口座への前記代金の支払いに係る入金金額を管理する管理サーバのコンピュータを、
   前記代金に係る請求金額および当該代金の支払い期限を取得する取得手段と、
   前記支払い期限が到来したときに前記代金の支払いに係る前記入金金額が前記請求金額に対し決済条件を満たしているかどうかを判断する判断手段と、
   前記判断手段で前記決済条件を満たしていないと判断した場合に、前記利用者端末に金額不足通知を行う金額不足通知手段と、
   前記金額不足通知を行った場合に前記利用者に金額不足理由を入力させるための理由入力手段と、
   前記理由入力手段により入力された金額不足理由を前記事業者端末に通知する理由通知手段として機能させる
   決済管理プログラム。

Images