(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024153321
(43)【公開日】2024-10-29
(54)【発明の名称】決済管理システム、決済管理方法および決済管理プログラム
(51)【国際特許分類】
G06Q 40/02 20230101AFI20241022BHJP
【FI】
G06Q40/02
【審査請求】有
【請求項の数】7
【出願形態】OL
(21)【出願番号】P 2023067136
(22)【出願日】2023-04-17
(71)【出願人】
【識別番号】306023808
【氏名又は名称】株式会社シーエスエス
(74)【代理人】
【識別番号】100135781
【弁理士】
【氏名又は名称】西原 広徳
(74)【代理人】
【識別番号】100217227
【弁理士】
【氏名又は名称】野呂 亮仁
(72)【発明者】
【氏名】前川 義信
(72)【発明者】
【氏名】森井 哲也
【テーマコード(参考)】
5L040
5L055
【Fターム(参考)】
5L040BB03
5L055BB03
(57)【要約】
【課題】銀行振込による、商品またはサービスの代金の決済に関し、事業者および消費者双方の利便性の向上を図る。
【解決手段】決済管理システム1は、事業者が使用する事業者端末3と、利用者が使用する利用者端末2と、代金の振込元となる仕向口座を有する仕向銀行サーバ4aと、代金の振込先となる被仕向口座を有する被仕向銀行サーバ4bと、代金の支払いに係る入金金額を管理する決済管理サーバ5とを備える。決済管理サーバ5は、支払い期限が到来したときに代金の支払いに係る入金金額が請求金額に対し決済条件を満たしていない場合に、利用者端末2に金額不足通知を行い利用者に金額不足理由を入力させ、利用者によって入力された金額不足理由を事業者端末3に通知する。
【選択図】
図6
【特許請求の範囲】
【請求項1】
商品またはサービスを提供する事業者が使用する事業者端末と、
前記商品または前記サービスの提供を受ける利用者が使用する利用者端末と、
前記商品または前記サービスの提供に係る取引における代金の振込元となる仕向口座を有する仕向銀行が管理する仕向銀行サーバと、
前記代金の振込先となる被仕向口座を有する被仕向銀行が管理する被仕向銀行サーバと、
前記利用者端末、前記仕向銀行サーバおよび前記被仕向銀行サーバのそれぞれと通信可能であって、前記仕向口座から前記被仕向口座への前記代金の支払いに係る入金金額を管理する管理サーバとを備え、
前記管理サーバは、
前記代金に係る請求金額および当該代金の支払い期限を取得する取得手段と、
前記支払い期限が到来したときに前記代金の支払いに係る前記入金金額が前記請求金額に対し決済条件を満たしているかどうかを判断する判断手段と、
前記判断手段で前記決済条件を満たしていないと判断した場合に、前記利用者端末に金額不足通知を行う金額不足通知手段と、
前記金額不足通知を行った場合に前記利用者に金額不足理由を入力させるための理由入力手段と、
前記理由入力手段により入力された金額不足理由を前記事業者端末に通知する理由通知手段とを備えた
決済管理システム。
【請求項2】
前記理由入力手段は、予め設定された複数種類の金額不足理由の候補のそれぞれに対応した選択肢を前記利用者に提示する
請求項1記載の決済管理システム。
【請求項3】
前記管理サーバは、
前記判断手段で前記決済条件を満たしていると判断された場合に、前記利用者端末に入金完了通知を行う入金完了通知手段をさらに備えた
請求項2記載の決済管理システム。
【請求項4】
前記判断手段は、
前記事業者が振込手数料を負担する場合であれば、前記入金金額および振込手数料相当金額に基づく金額の範囲内である場合に前記決済条件を満たしていると判断し、
前記事業者が振込手数料を負担しない場合であれば、前記入金金額が前記請求金額と一致した場合に前記決済条件を満たしていると判断する構成である
請求項1記載の決済管理システム。
【請求項5】
前記管理サーバは、
前記判断手段で前記入金金額が前記請求金額に対し不足していると判断された場合に、前記支払い期限の延長要請の要否を利用者に選択させるための延長申請要否選択手段と、
前記延長要請があった場合に、前記支払い期限を所定期間延長する支払い期限延長手段とをさらに備えた
請求項1ないし4のいずれかに記載の決済管理システム。
【請求項6】
商品またはサービスを提供する事業者が使用する事業者端末と、
前記商品または前記サービスの提供を受ける利用者が使用する利用者端末と、
前記商品または前記サービスの提供に係る取引における代金の振込元となる仕向口座を有する仕向銀行が管理する仕向銀行サーバと、
前記代金の振込先となる被仕向口座を有する被仕向銀行が管理する被仕向銀行サーバと、
前記利用者端末、前記仕向銀行サーバおよび前記被仕向銀行サーバのそれぞれと通信可能であって、前記仕向口座から前記被仕向口座への前記代金の支払いに係る入金金額を管理する管理サーバとを備えた決済管理システムにおける決済管理方法であって、
前記管理サーバを用い、
前記代金に係る請求金額および当該代金の支払い期限を取得し、
前記支払い期限が到来したときに前記代金の支払いに係る前記入金金額が前記請求金額に対し決済条件を満たしているかどうかを判断し、
前記決済条件を満たしていないと判断した場合に、前記利用者端末に金額不足通知を行い、
前記金額不足通知を行った場合に前記利用者に金額不足理由を入力させ、
入力された金額不足理由を前記事業者端末に通知する
決済管理方法。
【請求項7】
商品またはサービスを提供する事業者が使用する事業者端末と、前記商品または前記サービスの提供を受ける利用者が使用する利用者端末と、前記商品または前記サービスの提供に係る取引における代金の振込元となる仕向口座を有する仕向銀行が管理する仕向銀行サーバと、前記代金の振込先となる被仕向口座を有する被仕向銀行が管理する被仕向銀行サーバとのそれぞれと通信可能であって、前記仕向口座から前記被仕向口座への前記代金の支払いに係る入金金額を管理する管理サーバのコンピュータを、
前記代金に係る請求金額および当該代金の支払い期限を取得する取得手段と、
前記支払い期限が到来したときに前記代金の支払いに係る前記入金金額が前記請求金額に対し決済条件を満たしているかどうかを判断する判断手段と、
前記判断手段で前記決済条件を満たしていないと判断した場合に、前記利用者端末に金額不足通知を行う金額不足通知手段と、
前記金額不足通知を行った場合に前記利用者に金額不足理由を入力させるための理由入力手段と、
前記理由入力手段により入力された金額不足理由を前記事業者端末に通知する理由通知手段として機能させる
決済管理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
この発明は、銀行振込による、商品またはサービスの代金の決済に関する、決済管理システム、決済管理方法および決済管理プログラムに関する。
【背景技術】
【0002】
従来、銀行振込による、商品またはサービスの代金の決済状況(支払い状況)を管理するためのシステムの一例として、商品の購入代金および当該商品の購入代金に係る振込金額を取得し、購入代金を実際に入金された振込金額分減額して更新することにより、過不足金額を管理することができる入金確認通知システムが提案されている(特許文献1参照)。
【0003】
特許文献1記載の入金確認通知システムでは、過不足金額を検出し、購入者から振り込まれた振込金額が購入代金より少ない場合に、金額が不足している旨を通知するとともに、引き続き、指定口座への不足金額の入金を待機することができる。
【0004】
しかしながら、特許文献1記載の入金確認通知システムでは、金額が不足している場合に、消費者視点では単に金額が不足している旨の通知が来るだけであり、事業者視点では不足金額の入金を待機するだけであるので、事業者および消費者の双方から見て利便性の観点で改善の余地がある。
【先行技術文献】
【特許文献】
【0005】
【発明の概要】
【発明が解決しようとする課題】
【0006】
この発明は、上述の問題に鑑みて、銀行振込による、商品またはサービスの代金の決済に関し、事業者および消費者双方の利便性を向上させることができる、決済管理システム、決済管理方法および決済管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【0007】
この発明は、商品またはサービスを提供する事業者が使用する事業者端末と、前記商品または前記サービスの提供を受ける利用者が使用する利用者端末と、前記商品または前記サービスの提供に係る取引における代金の振込元となる仕向口座を有する仕向銀行が管理する仕向銀行サーバと、前記代金の振込先となる被仕向口座を有する被仕向銀行が管理する被仕向銀行サーバと、前記利用者端末、前記仕向銀行サーバおよび前記被仕向銀行サーバのそれぞれと通信可能であって、前記仕向口座から前記被仕向口座への前記代金の支払いに係る入金金額を管理する管理サーバとを備え、前記管理サーバは、前記代金に係る請求金額および当該代金の支払い期限を取得する取得手段と、前記支払い期限が到来したときに前記代金の支払いに係る前記入金金額が前記請求金額に対し決済条件を満たしているかどうかを判断する判断手段と、前記判断手段で前記決済条件を満たしていないと判断した場合に、前記利用者端末に金額不足通知を行う金額不足通知手段と、前記金額不足通知を行った場合に前記利用者に金額不足理由を入力させるための理由入力手段と、前記理由入力手段により入力された金額不足理由を前記事業者端末に通知する理由通知手段とを備えた決済管理システム、決済管理方法および決済管理プログラムであることを特徴とする。
【発明の効果】
【0008】
この発明により、銀行振込による、商品またはサービスの代金の決済に関し、事業者および消費者双方の利便性を向上させることができる。
【図面の簡単な説明】
【0009】
【
図1】この発明の決済管理システムの構成の一例を示す説明図。
【
図5】決済管理サーバの構成の一例を示すブロック図。
【
図7】金額不足通知画面の画面構成例を示す説明図。
【発明を実施するための形態】
【0010】
以下、この発明の一実施形態を図面と共に説明する。
<システム構成>
【0011】
図1は、本発明の決済管理システム1のシステム構成の一例を示すブロック図である。本発明の決済管理システム1は、銀行振込による、商品またはサービスの提供に係る取引における代金の決済(支払い)に関する決済管理サービスを提供するためのシステムである。取引の代金を決済する態様としては、一時的に提供される商品またはサービスの代金を決済する都度決済や、定期的に継続して提供される商品またはサービスの代金を決済する継続決済などがある。本発明の決済管理システム1では、都度決済または継続決済に係る取引において、銀行振込によって代金が支払われる場合を想定している。
【0012】
図1に示すように、決済管理システム1は、利用者端末2、事業者端末3、銀行サーバ4、および決済管理サーバ5を有している。利用者端末2は、事業者から商品またはサービスの提供を受ける利用者(消費者)が使用する端末である。事業者端末3は、利用者に対し商品またはサービスを提供する事業者(商品販売者またはサービス提供者)が使用する端末である。銀行サーバ4は、商品またはサービスの代金の送金元または送金先となる口座を有している銀行などの金融機関が管理するサーバである。決済管理サーバ5は、決済管理サービスを提供するためのサーバである。
【0013】
利用者端末2、事業者端末3、銀行サーバ4、および決済管理サーバ5のそれぞれは、インターネット等の通信回線6を介して、相互に通信可能に接続される。ただし、決済管理システム1は、複数の銀行サーバ4を有しており、複数の銀行サーバ4の間(銀行間)の通信は銀行データ通信用の専用回線が使用されることがある。
【0014】
また、商品またはサービスの代金の送金元となる口座を有している金融機関を仕向銀行といい、商品またはサービスの代金の送金先となる口座を有している金融機関を被仕向銀行という。さらに、本発明では、説明の便宜上、仕向銀行が管理する銀行サーバ4を仕向銀行サーバ4aといい、被仕向銀行が管理する銀行サーバ4を被仕向銀行サーバ4bという。なお、仕向銀行サーバ4a,被仕向銀行サーバ4bのそれぞれを特に区別しない場合には単に「銀行サーバ4」ということがある。
【0015】
なお、複数の銀行サーバ4は、利用者のために開設された口座、および/または事業者のために開設された口座を有している銀行が管理することが可能なものである。したがって、複数の銀行サーバ4のそれぞれは、取引の内容に応じて仕向銀行サーバ4aまたは被仕向銀行サーバ4bとしての立場が入れ替わることがある。また、各銀行における口座のうち事業者のために開設された口座としては、事業者のために開設された振込入金専用の仮想口座(バーチャル口座)であることが好ましい。バーチャル口座は、取引毎または利用者毎に口座を割り当てることができる。したがって、被仕向銀行サーバ4bにおいて振込(入金)があった場合に取引や利用者を特定することができる。
【0016】
なお、利用者端末2、事業者端末3、および銀行サーバ4(仕向銀行サーバ4a,被仕向銀行サーバ4b)については、説明の便宜上それぞれ1つずつ図示しているが、本発明の決済管理システム1は、複数の利用者、複数の事業者、複数の仕向銀行、複数の被仕向銀行が利用することができ、複数の利用者端末2、複数の事業者端末3、仕向銀行サーバ4a、および被仕向銀行サーバ4bを有していても良い。
【0017】
利用者端末2および事業者端末3は、利用者が使用する汎用のコンピュータ(ユーザ端末)である。たとえば、デスクトップPC、ノート(ラップトップ)PC、タブレットPC、スマートフォン、およびフィーチャーフォン等である。銀行サーバ4および決済管理サーバ5のそれぞれは、汎用のサーバコンピュータ(コンピューティングデバイス)で構成されている。なお、銀行サーバ4および決済管理サーバ5のそれぞれは、1台(単一)のコンピューティングデバイスで構成されていてもよいし、複数のコンピューティングデバイスで構成されていてもよい。また、銀行サーバ4および決済管理サーバ5のそれぞれの一部または全部がクラウドサーバで構成されていてもよい。
【0018】
図2は利用者端末2の構成の一例を示すブロック図である。
図3は事業者端末3の構成の一例を示すブロック図である。
図4は銀行サーバ4の構成の一例を示すブロック図である。
図5は決済管理サーバ5の構成の一例を示すブロック図である。
【0019】
図2に示すように、利用者端末2は、制御部21、入力部22、表示部23、通信部24、および補助記憶部25を備える。入力部22、表示部23、通信部24、および補助記憶部25のそれぞれは、制御部21に通信可能に接続されている。利用者端末2の制御部21は、演算部26および主記憶部27を有しており、利用者端末2における各種演算および制御動作を実行する。
【0020】
図3に示すように、事業者端末3は、制御部31、入力部32、表示部33、通信部34、および補助記憶部35を備える。入力部32、表示部33、通信部34、および補助記憶部35のそれぞれは、制御部31に通信可能に接続されている。事業者端末3の制御部31は、演算部36および主記憶部37を有しており、事業者端末3における各種演算および制御動作を実行する。
【0021】
図4に示すように、銀行サーバ4は、制御部41、通信部42、および補助記憶部43を備える。通信部42、および補助記憶部43のそれぞれは、制御部41に通信可能に接続されている。銀行サーバ4の制御部41は、演算部44および主記憶部45を有しており、銀行サーバ4における各種演算および制御動作を実行する。
【0022】
図5に示すように、決済管理サーバ5は、制御部51、通信部52、および補助記憶部53を備える。通信部52、および補助記憶部53のそれぞれは、制御部51に通信可能に接続されている。決済管理サーバ5の制御部51は、演算部56および主記憶部57を有しており、決済管理サーバ5における各種演算および制御動作を実行する。
【0023】
図2~5に示す各演算部(26、36、44、56)は、CPUまたはMPUなどを含む演算処理部である。各主記憶部(27、37、45、57)は、RAM(DRAM)などを有している。RAMは、演算部(26、36、44、56)のワーク領域およびバッファ領域として用いられる。
【0024】
図2および
図3に示す入力部(22、32)は、利用者端末2または事業者端末3の使用者(利用者または事業者の担当者)の操作入力を受け付ける入力部品、および入力部品と制御部(21、31)との間に介在する入力検出回路を有している。入力部品は、たとえばタッチパネルまたは/およびハードウェアの操作キーである。タッチパネルとしては、静電容量方式、電磁誘導方式、抵抗膜方式、赤外線方式など、任意の方式のものを用いることができる。入力検出回路は、各入力部品の操作に応じた操作信号ないし操作データ(操作入力データ)を制御部(21、31)に出力する。
【0025】
表示部(23、33)は、ディスプレイ、およびディスプレイと制御部(21、31)との間に介在する表示制御回路を有している。ディスプレイとしては、たとえばLCD(液晶ディスプレイ)または有機ELディスプレイなどを用いることができる。
【0026】
図2~5に示す通信部(24、34、42,52)は、通信回線6に接続するための通信回路を有している。通信回路は、有線通信回路または無線通信回路であり、演算部(26、36、44、56)からの指示に従って、通信回線6を介して、外部コンピュータと通信する。また、利用者端末2、事業者端末3、銀行サーバ4および決済管理サーバ5のそれぞれの通信部(24、34、42,52)は、通信回線6を介さずに、専用回線等で直接相互に通信することも可能である。特に、銀行サーバ4の通信部42は、銀行データ通信用の専用回線で通信することも可能である。
【0027】
補助記憶部(25、35、43、53)は、HDD、SSD、フラッシュメモリ、EEPROMなどの不揮発性メモリで構成され、各演算部(26、36、44、56)が利用者端末2、事業者端末3、銀行サーバ4、および決済管理サーバ5のそれぞれの動作を制御するためのプログラムおよび本システムの利用に必要な各種データなどを記憶する。
【0028】
図2に示すように、利用者端末2の補助記憶部25は、利用者の操作入力に応じて本システムにおける利用者端末2の各種動作を実行するための利用者用プログラム25aと、本システムの利用に必要な利用者用データ25bとを記憶している。利用者用プログラム25aおよび利用者用データ25bは、必要に応じて補助記憶部25から読み出され主記憶部27に記憶される(展開される)。利用者端末2の動作は、演算部26が主記憶部27に展開された利用者用プログラム25aを実行することによって実現される。
【0029】
利用者用プログラム25aは、少なくとも、外部コンピュータ(たとえば事業者端末3、銀行サーバ4、および決済管理サーバ5)にアクセス(外部コンピュータとの通信を確立)するための通信プログラム、表示部23に種々の画面を表示させるための表示プログラム、入力部22を介して利用者からの入力操作を受け付けるための入力プログラム、および利用者端末2が備える各種の機能を選択および実行するためのプログラム等を有している。利用者用データ25bは、少なくとも、本システムにおいて必要な利用者のデータを含む。
【0030】
図3に示すように、事業者端末3の補助記憶部35は、事業者端末3の各種動作を実行するための事業者用プログラム35aと、本システムの利用に必要な事業者用データ35bとを記憶している。事業者用プログラム35aおよび事業者用データ35bは、必要に応じて補助記憶部35から読み出され主記憶部37に記憶される(展開される)。事業者端末3の動作は、演算部36が主記憶部37に展開された事業者用プログラム35aを実行することによって実現される。
【0031】
事業者用プログラム35aは、少なくとも、外部コンピュータ(たとえば利用者端末2、銀行サーバ4、および決済管理サーバ5)にアクセス(外部コンピュータとの通信を確立)するための通信プログラム、取引毎の代金(請求金額)のデータ(請求金額データ)を決済管理サーバ5に通知する請求金額通知プログラム、請求金額データに紐づけられた取引毎の代金の支払い期限のデータ(期限データ)を決済管理サーバ5に通知する期限通知プログラム、入力部32を介して事業者の担当者(事業者端末3の使用者)からの入力操作を受け付けるための入力プログラム、および事業者端末3が備える各種の機能を選択および実行するためのプログラム等を有している。
【0032】
図4に示すように、銀行サーバ4の補助記憶部43は、銀行サーバ4の各種動作を実行するための銀行用プログラム43aと、本システムの利用に必要な銀行用データ43bとを記憶している。銀行用プログラム43aおよび銀行用データ43bは、必要に応じて補助記憶部43から読み出され主記憶部45に記憶される(展開される)。事業者端末3の動作は、演算部44が主記憶部45に展開された銀行用プログラム43aを実行することによって実現される。
【0033】
銀行用プログラム43aは、少なくとも、外部コンピュータ(たとえば利用者端末2、事業者端末3、他の銀行サーバ4および決済管理サーバ5)にアクセス(外部コンピュータとの通信を確立)するための通信プログラム、利用者の依頼に基づいて他の銀行(被仕向銀行)に対し送金(銀行振込)を行う送金プログラム、他の銀行から振り込まれた(送金された)金額(入金金額)のデータ(入金金額データ)を取引毎に決済管理サーバ5に通知する入金金額通知プログラム、および銀行サーバ4が備える各種の機能を選択および実行するためのプログラム等を有している。
【0034】
図5に示すように、決済管理サーバ5の補助記憶部53は、決済管理サーバ5の各種動作を実行するための決済管理用プログラム54と、本システムの利用に必要な決済管理用データ55とを記憶している。決済管理用プログラム54および決済管理用データ55は、必要に応じて補助記憶部53から読み出され主記憶部57に一時的に記憶される。決済管理サーバ5の動作は、演算部56が主記憶部57に一時的に記憶された決済管理用プログラム54を実行することによって実現される。
【0035】
決済管理用プログラム54は、少なくとも、決済管理サーバ5が備える各種の機能を選択および実行するためのメイン処理プログラム54a、事業者端末3から通知された請求金額データを管理するための請求金額管理プログラム54b、銀行サーバ4から通知された入金金額データを管理するための入金金額管理プログラム54c、請求金額と入金金額とを対比して取引毎に支払い完了(入金完了)かどうかを判断するための金額判断プログラム54d、取引毎に入金完了の旨や金額不足の旨を利用者(利用者端末2)に通知するための利用者通知プログラム54e、金額不足の場合に利用者から取引毎に金額不足の理由を取得するための理由取得プログラム54f、および、入金完了の旨や金額不足の場合に取引毎に金額不足の理由を事業者に通知する事業者通知プログラム54g等を有している。
【0036】
決済管理用データ55は、本システムを利用する利用者のデータである利用者データ55a、本システムを利用する事業者のデータである事業者データ55b、事業者端末3から通知された取引毎の請求金額データ55c、取引毎の代金の支払い期限を示す期限データ55d、銀行サーバ4から通知された取引毎の入金金額データ55e、取引毎の金額不足の理由を示す理由データ55f等を有している。利用者データ55aは、予め登録されている口座振替用の銀行口座(振替口座)のデータを有している。なお、請求金額データ55c、期限データ55d、入金金額データ55e、および理由データ55fのそれぞれは、取引毎の識別情報(ID)に紐づけられるなど、取引毎に区別できるような態様で記憶されており、バーチャル口座を用いる場合にはバーチャル口座番号も紐づけられている。
【0037】
利用者データ55aは、利用者端末2と利用者(利用者端末2の使用者)とを紐づけるためのデータを有している。事業者データ55bは、事業者端末3と事業者(事業者端末3の使用者)とを紐づけるためのデータを有している。
【0038】
なお、上述した利用者端末2の構成、銀行サーバ4の構成、事業者端末3の構成および決済管理サーバ5の構成は、単なる一例であり、これに限定される必要はない。
<システム動作例>
【0039】
以下、決済管理システム1の動作例を説明する。まず、決済管理システム1の動作例を説明する前提となる請求金額データ55cの発生について簡単に説明する。事業者と利用者との間で商品またはサービスの提供に係る取引を行った場合、事業者端末3は、取引の代金(請求金額)のデータ(請求金額データ)および当該請求金額データに紐づけられた支払い期限のデータ(期限データ)を決済管理サーバ5に通知する。決済管理サーバ5は、事業者端末3から通知された請求金額データおよび期限データを請求金額データ55cおよび期限データ55dとして記憶する。また、利用者が自身の口座(仕向銀行の口座)などから取引の代金を支払うための事業者の口座(被仕向銀行の口座)に振込(送金)を行った場合、被仕向銀行サーバ4bは、仕向銀行の口座から振り込まれた(送金された)金額(入金金額)のデータ(入金金額データ)を決済管理サーバ5に通知する。決済管理サーバ5は、被仕向銀行サーバ4bから通知された入金金額データを入金金額データ55eとして記憶する。なお、上述したように、請求金額データ55c、期限データ55d、および入金金額データ55eは、取引毎に区別できるような態様で記憶されている。
<金額不足処理>
【0040】
図6は金額不足処理のフロー図である。
図7は通知メール100の画面構成例を示す説明図である。
図8は理由入力画面110の画面構成例を示す説明図である。
図9は延長申請画面120の画面構成例を示す説明図である。
図10は延長通知画面130の画面構成例を示す説明図である。
図11は、理由通知画面140の画面構成例を示す説明図である。以下、
図6~
図11を参照して利用者に金額不足の通知を行う金額不足処理について説明する。なお、金額不足の場合に実行する金額不足処理は、事業者の設定により支払い期限を所定期間だけ自動的に延長する自動延長処理と、利用者に延長申請された場合に所定期間だけ支払い期限を延長する手動延長処理がある。決済管理サーバ5(制御部51)は、まず事業者により自動延長処理の設定がされているか確認し、されていれば自動的に所定期間だけ支払い期限を延長し、
図10の延長通知画面130を表示する。事業者により自動延長処理の設定がなされていなければ、
図6に示す金額不足処理を実行する。
【0041】
図6に示す金額不足処理は、利用者端末2、銀行サーバ4および事業者端末3等と連携して、決済管理サーバ5(制御部51)で行われる処理である。金額不足処理は、或る取引の支払い期限が到来したときに当該取引の代金の支払いが決済条件を満たしていない場合に実行される。たとえば、決済条件は、当該取引の入金金額が請求金額以上の金額(同額を含む)であるかどうかであり、入金金額が請求金額以上であれば決済条件を満たしていると判断され、入金金額が請求金額未満であれば決済条件を満たしていないと判断される。なお、支払い期限が到来したときに決済条件を満たしていると判断された場合には、金額不足処理は実行されない。
【0042】
図6に示すように、決済管理サーバ5は、金額不足処理を開始すると、金額不足を利用者(金額不足となった取引における被請求者)が使用する利用者端末2に通知し(ステップS1)、金額不足理由の入力に進むかどうかを判断する(ステップS2)。
【0043】
たとえば、決済管理サーバ5は、ステップS1において、
図7に示すような内容の通知メール100を利用者(被請求者)の利用者端末2に通知する。通知メール100は、不足通知部101と、理由入力用リンク102とを有している。
【0044】
不足通知部101は、通知メール100の本文となるものであり、入金金額が請求金額に対し不足している旨を通知するような内容の文によって構成される。不足通知部101には、入金金額が請求金額に対し不足している旨、不足金額、金額不足理由の入力を促す旨等の情報が含まれる。また、
図7に示す例では、不足通知部101には、理由入力用リンク102の有効期限(回答期限)の情報が含まれる。この不足通知部101の通知は、振込手数料を事業者が負担しない場合は請求額から入金金額(被仕向け銀行への着金金額)を減算した不足金額を明示し、振込手数料を事業者が負担する場合はそれ以外の形式での不足の表示(例えば不足である旨、請求額から入金金額を減算した金額とそれに振込手数料を加算した金額の範囲を示す表示など)とすることができる。これにより、事業者側の都合に応じつつ、かつ利用者にできるだけわかりやすい通知とすることができる。
【0045】
理由入力用リンク102は、決済管理サーバ5にアクセスし、金額不足理由を入力するためのWEBページを表示させるためのハイパーリンクである。理由入力用リンク102は、WEBページを表示させるためのURL等の文字を表示した文字リンクであってもよいし、画像リンクやボタン式のリンクであってもよい。
【0046】
なお、通知メール100に代えて、不足通知部101および理由入力用リンク102を有し通知メール100に相当するポップアップ画面として利用者端末2に通知することもできる。
【0047】
図6に戻って、決済管理サーバ5は、理由入力用リンク102が選択されない場合には金額不足理由の入力に進むと判断せず(ステップS2:NO)、金額不足理由の入力期限(回答期限)まで待機する。理由入力用リンク102が選択されないまま金額不足理由の入力期限(回答期限)が到来した場合には金額不足処理を終了する。
【0048】
一方、決済管理サーバ5は、ステップS2において、たとえば理由入力用リンク102が選択された場合には金額不足理由の入力に進むと判断(ステップS2:YES)し、金額不足理由を入力するためのWEBページを利用者端末2の表示部23に表示させ(ステップS3)、金額不足理由が入力されたかどうかを判断する(ステップS4)。
【0049】
たとえば、決済管理サーバ5は、ステップS3において、
図8に示すような内容の理由入力画面110を利用者(被請求者)の利用者端末2に表示(通知)する。理由入力画面110は、通知部111と、理由入力部112と、入金完了予定日入力部113とを有している。
【0050】
通知部111は、金額不足理由の入力を促すような通知文111aおよび金額不足理由を入力できる期間の終期(回答期限または入力期限)を示す期限表示部111bによって構成される。
【0051】
理由入力部112は、金額不足理由を入力するために設けられている。たとえば、理由入力部112は、予め設定された複数種類の金額不足理由の候補のそれぞれに対応した選択肢を提示する。
【0052】
本実施形態では、理由入力部112は、複数種類の金額不足理由の候補のそれぞれに割り当てられた複数の選択ボタン112a~112cを有している。なお、選択ボタン112a~112cは、いわゆるソフトウェアキー(操作ボタン)として機能する。以下、ソフトウェアキーを単に「ボタン」という。具体的には、理由入力部112は、金額不足理由として利用者が振込金額を間違えた場合に相当する「振込金額の間違い」が割り当てられた選択ボタン112aと、金額不足理由として振込金額に上限金額が設定されていた場合であって上限金額が請求金額未満であった場合に相当する「振込金額の上限制限」が割り当てられた選択ボタン112bと、金額不足理由として「振込金額の間違い」および「振込金額の上限制限」以外の理由に相当する「その他」が割り当てられた選択ボタン112cとを有している。なお、理由入力部112は、選択ボタン112a~112cに代えて、複数種類の金額不足理由の候補のそれぞれに割り当てられたチェックボックスまたはラジオボタン、若しくは金額不足理由を示す文字の入力を受け付けるテキストボックス(入力欄)を有していてもよい。入金完了予定日入力部113は、不足金額の入金完了予定日を入力するために設けられている。たとえば、入金完了予定日入力部113は、入金完了予定日の日付を入力するためのテキストボックス(入力欄)113aを有している。ただし、入金完了予定日は、支払期限よりも前の日に限り設定することができる。
【0053】
図6に戻って、決済管理サーバ5は、ステップS4において、金額不足理由が入力されない場合には(ステップS2:NO)、金額不足理由が入力されるまで待機する。ただし、金額不足理由が入力されないまま金額不足理由の入力期限(回答期限)が到来した場合には金額不足処理を終了する。
【0054】
一方、理由入力部112において金額不足理由が入力された場合には、入力された金額不足理由を取得し(ステップS5)、支払い期限を延長するための延長申請画面を利用者端末2の表示部23に表示させ(ステップS6)、延長申請があるかどうか(延長申請がされたかどうか)を判断する(ステップS7)。
【0055】
たとえば、決済管理サーバ5は、ステップS6において、
図9に示すような延長申請画面120を利用者(被請求者)の利用者端末2に表示(通知)する。延長申請画面120は、内容通知部121と、期限通知部122と、延長要否選択部123とを有している。
【0056】
内容通知部121は、支払い期限の延長申請が可能であることを通知するような文によって構成されている。期限通知部122は、延長申請を行うことができる期限(延長申請期限)の日付と、延長後の支払い期限の日付とを通知する文字によって構成されている。延長申請を行うことができる期限および延長後の支払い期限のそれぞれの日付は、取引毎に事業者によって予め設定されている。
【0057】
延長要否選択部123は、延長申請を行うかどうかを選択するために設けられている。たとえば、延長要否選択部123は、延長申請を行う場合と延長申請を行わない場合のそれぞれに対応した選択肢を提示する。本実施形態では、延長要否選択部123は、延長申請を行う場合に割り当てられた選択ボタン123aと、延長申請を行わない場合に割り当てられた選択ボタン123bを有している。なお、延長要否選択部123は、選択ボタン123a,123bに代えて、延長申請を行う場合と延長申請を行わない場合のそれぞれに割り当てられたチェックボックスまたはラジオボタンを有していてもよい。
【0058】
図6に戻って、決済管理サーバ5は、ステップS7において、延長要請がないと判断すれば、利用者に代金の支払い意志が無いものとして未収金(未回収代金)回収処理へ移行し(ステップS8)、金額不足処理を終了する。ここで、延長要請がない場合とは、延長要否選択部123で延長申請を行わない場合に割り当てられた選択肢(本実施形態では選択ボタン123b)が選択された場合や、延長申請を行うことができる期限までに延長申請を行う場合に割り当てられた選択肢が選択されなかった場合等がある。ここで、被仕向口座がバーチャル口座の場合は、決済管理サーバ5が仕向銀行サーバ4aまたは被仕向銀行サーバ4bにバーチャル口座を削除するよう削除指示する。これにより未収金回収処理を進めている間に入金されてしまうことを防止できる。また、未収金回収処理に移行すると、通常の支払い方法とは別の方法で未収金(未回収代金)の回収を行う。なお、未収金回収処理の具体的な方法については本発明の本質的部分ではないことと、取引毎に個別に払込票を利用者に郵送する等、公知の方法を用いることができるため、詳しい説明は省略する。
【0059】
ステップS7において、延長要請があると判断すれば、すなわち、延長申請を行うことができる期限までに延長申請を行う場合に割り当てられた選択肢(本実施形態では選択ボタン123a)が選択された場合には、支払い期限を延長する(ステップS9)。そして、支払い期限を延長すると(ステップS9)、延長後の支払い期限を利用者端末2に通知し(ステップS10)、入金完了予定日、金額不足理由、および延長後の支払い期限を事業者端末3に通知し(ステップS11)、金額不足処理を終了する。被仕向口座がバーチャル口座の場合は、決済管理サーバ5が延長後の支払い期限までは削除しないように仕向銀行サーバ4aまたは被仕向銀行サーバ4bに継続指示をする。なお、バーチャル口座開設時にバーチャル口座の開設期間を延長後の支払い期限も含むように長く設定されていた場合は特に継続指示をしない構成としてもよい。また、延長後の支払い期限が到来したときに当該取引の代金の支払いが決済条件を満たしていない場合には、金額不足処理は実行されず、未収金回収処理に移行する。
【0060】
ここで、決済管理サーバ5は、ステップS9において、電子メールまたはポップアップ画面等によって延長後の支払い期限を利用者(被請求者)の利用者端末2に表示(通知)する。たとえば、決済管理サーバ5は、ステップS9において、
図10に示すような内容の延長通知画面130を利用者(被請求者)の利用者端末2に通知する。延長通知画面130は、支払い期限が延長されたことを通知する延長通知部131と、延長後の支払い期限の日付を通知する延長期限通知部132と、請求金額を通知する金額通知部133とを有している。
【0061】
また、決済管理サーバ5は、ステップS10において、電子メールまたはポップアップ画面等によって入金完了予定日、金額不足理由、および延長後の支払い期限を事業者(請求者)の事業者端末3に表示(通知)する。たとえば、決済管理サーバ5は、ステップS10において、
図11に示すような内容の理由通知画面140を事業者(請求者)の事業者端末3に通知する。理由通知画面140は、金額不足理由を通知する理由通知部141と、延長後の支払い期限を通知する延長期限通知部142と、入金完了予定日を通知する入金予定通知部143とを有している。
【0062】
以上のように、本発明の決済管理システム1では、支払い期限が到来したときに代金の支払いに係る入金金額が請求金額未満の場合(金額不足の場合)に、利用者(被請求者)によって入力された金額不足理由を取得し、金額不足理由を事業者(請求者)に通知する。従来では、金額不足の場合には、事業者の担当者が利用者に訪問、電話または電子メール等により問い合わせを行い、金額不足理由や入金完了予定日を人為的に取得していたが、本発明によればこのような手間を省くことができる。
【0063】
また、本発明によれば、予め設定された複数種類の金額不足理由の候補のそれぞれに対応した選択肢を利用者に提示するので、利用者は選択肢を選択するだけでよく、利用者の利便性を向上させることができる。
【0064】
さらに、本発明によれば、入金金額が請求金額に対し不足していると判断された場合に、支払い期限の延長要請の要否を利用者に選択させ、支払い期限の延長要請があった場合に、支払い期限を所定期間延長するので、利用者の利便性を向上させることができる。また、金額不足の場合に自動的に支払い期限を延長すると事業者によって設定されていた場合は、利用者に問い合わせずに自動的に支払い期限を所定期間延長する。この場合は、利用者が延長申請せずとも延長された支払い期限内に入金が可能となるため、利用者の利便性が向上するとともに、事業者の利便性も向上する。
<変形例の金額判断処理>
【0065】
上述の実施形態では、決済条件は、取引の代金の支払いに係る入金金額が請求金額以上の金額であるかどうかとしたが、これに限定される必要は無く、柔軟に決済条件を設定することができる。
【0066】
図12は変形例の金額判定処理のフロー図である。
図12に示す金額判定処理は、利用者端末2、銀行サーバ4および事業者端末3等と連携して、決済管理サーバ5(制御部51)で行われる処理である。
【0067】
決済管理サーバ5は、金額判定処理を開始すると、被仕向銀行サーバ4bから直接的または間接的に入金金額を取得し(ステップS21)、事業者が振込手数料を負担するかどうかを判断する(ステップS22)。
【0068】
たとえば、決済管理サーバ5は、ステップS21において、入金がある度に入金金額を取得するか、あるいは支払い期限が到来したときにそれまで入金された金額の合計(合計金額)を入金金額として取得することができる。
【0069】
また、決済管理サーバ5は、ステップS22において、事業者が振込手数料を負担しないと判断した場合、請求金額を、決済条件を満たすかどうかを判定するための基準となる判定処理用の金額(判定金額)に設定し(ステップS23)、後述するステップS25に進む。一方、事業者が振込手数料を負担すると判断した場合、請求金額および振込手数料相当金額に基づく許容範囲を判定金額に設定し(ステップS24)、ステップS25に進む。なお、この許容範囲は事業者毎に任意の範囲に設定されており、その事業者の許容範囲を判定金額に設定する。
【0070】
続いて、ステップS25で、入金金額が判定金額以上かどうかを判断する。なお、ステップS25では、ステップS24にて許容範囲が判定金額に設定されている場合、入金金額が許容範囲の下限の金額以上かどうかを判断する。ステップS25において、入金金額が判定金額以上でない、すなわち入金金額が判定金額未満であると判断した場合(ステップS25:NO)、上述した金額不足処理(ステップS26)に移行し、金額判定処理を終了する。
【0071】
一方、ステップS25において、入金金額が判定金額以上であると判断した場合(ステップS25:YES)、入金金額が判定金額を超過しているかどうかを判断する(ステップS27)。なお、ステップS27では、ステップS24にて許容範囲が判定金額に設定されている場合、入金金額が許容範囲の上限の金額を超過しているかどうかを判断する。
【0072】
ステップS27において、入金金額が判定金額を超過していると判断した場合(ステップS27:YES)、超過分の金額を利用者に返金するための返金処理(ステップS28)に移行し、金額判定処理を終了する。たとえば、返金処理では、事業者の担当者が利用者に返金金額および返金方法を連絡するか、あるいは、利用者(利用者端末2)に返金金額および返金方法を連絡する電子メールが決済管理サーバ5から自動的に送信される。利用者は、電子メールなどの適宜の方法で返金先口座を事業者に連絡する。
【0073】
一方、ステップS27において、入金金額が判定金額を超過していない、すなわち入金金額が判定金額に含まれているまたは入金金額が判定金額と一致すると判断した場合(ステップS27:NO)、入金完了の旨を電子メールまたはポップアップ画面等によって利用者(被請求者)の利用者端末2に通知し(ステップS29)し、金額判定処理を終了する。
【0074】
以上のように、本発明の金額判定処理では、すなわち、事業者が振込手数料を負担する場合であれば、請求金額および振込手数料相当金額に基づく許容範囲内である場合に決済条件を満たしていると判断し、事業者が振込手数料を負担しない場合であれば、入金金額が請求金額と一致した場合に決済条件を満たしていると判断する。したがって、取引の実用に合わせて柔軟に決済条件を設定することができ、事業者および利用者の双方の利便性を向上させることができる。
【0075】
また、従来では、利用者が振込を行った際、仕向銀行から「振込完了」の通知は来るが、被仕向銀行への「着金完了」通知は来なかった。これに対し、本発明の金額判定処理では、入金金額が判定金額に含まれているまたは入金金額が判定金額と一致すると判断した場合に、入金完了の旨を利用者に通知するので、被仕向銀行に送金できたか確認することができ、利用者の安心感につながるという利点がある。
【0076】
この発明の管理サーバは上記実施形態の決済管理サーバ5に対応し、利用者端末は利用者端末2に対応し、事業者端末は事業者端末3に対応し、仕向銀行サーバは仕向銀行サーバ4aに対応し、被仕向銀行サーバは被仕向銀行サーバ4bに対応し、管理サーバは、決済管理サーバ5に対応し、取得手段は、請求金額管理プログラム54bおよびこれに従って動作する制御部51に対応し、判断手段は、金額判断プログラム54dおよびこれに従って動作する制御部51に対応し、金額不足通知手段は、不足通知部101に対応し、理由入力手段は、理由入力部112に対応し、理由通知手段は、理由通知部141に対応し、入金完了通知手段は、ステップS29に対応し、延長申請要否選択手段は、延長要否選択部123に対応し、支払い期限延長手段は、選択ボタン123aに対応するが、この発明は本実施形態に限られず他の様々な実施形態とすることができる。また、上述の実施形態で挙げた画面および具体的な構成等は一例であり、実際の製品に応じて適宜変更することが可能である。
【産業上の利用可能性】
【0077】
この発明は、銀行振込による、商品またはサービスの代金の決済に関する産業に利用することができる。
【符号の説明】
【0078】
1…決済管理システム
2…利用者端末
3…事業者サーバ
4…銀行サーバ
4a…仕向銀行サーバ
4b…被仕向銀行サーバ
5…決済管理サーバ
51…制御部