(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】2021105776
(43)【公開日】20210726
(54)【発明の名称】カードレスクレジット決済
(51)【国際特許分類】
   G06Q 40/02 20120101AFI20210625BHJP
   G06Q 20/24 20120101ALI20210625BHJP
【FI】
   !G06Q40/02
   !G06Q20/24
【審査請求】未請求
【請求項の数】9
【出願形態】OL
【全頁数】13
(21)【出願番号】2019235853
(22)【出願日】20191226
(71)【出願人】
【識別番号】519463396
【氏名又は名称】協栄IT&ビジネスサービス株式会社
【住所又は居所】東京都千代田区神田北乗物町10−2
(74)【代理人】
【識別番号】100166589
【弁理士】
【氏名又は名称】植村 貴昭
(72)【発明者】
【氏名】及川 洋
【住所又は居所】東京都千代田区神田北乗物町10−2 協栄IT&ビジネスサービス株式会社内
【テーマコード(参考)】
5L055
【Fターム(参考)】
5L055AA52
5L055BB15
(57)【要約】
【課題】顧客の保険契約の保障開始を早めることを可能とする決済システムを提供する。
【解決手段】端末11から顧客情報が入力される第1サーバ12と、銀行口座を管理する第2サーバ13と、信販会社に管理される第3サーバ14とを備え、第1サーバ12は、第2サーバ13に対して、銀行口座が正当な場合に顧客情報及び口座振替承認依頼を送信するものであるとともに、第3サーバ14に対して、与信行為可否判定依頼を送信するものであり、第2サーバ13は、第1サーバ12から顧客情報及び口座振替承認依頼を受信すると、与信相当額の口座振替のための口座振替受付処理を行うものであり、第3サーバ14は、第1サーバ12から顧客情報及び与信行為可否判定依頼を受信すると、顧客情報に基づき与信行為の可否判定を行い、与信可能の場合、第1サーバ12に対し、与信承認番号、承認日、及び承認金額のデータを送信する。
【選択図】図1
【特許請求の範囲】
【請求項1】
端末から顧客情報が入力される第1サーバ(12)と、
信販会社に管理される第2サーバ(14)とを備え、
前記第1サーバは、前記第2サーバに対して、前記顧客情報及び与信行為可否判定依頼を送信し、
前記第2サーバは、前記第1サーバから前記顧客情報及び前記与信行為可否判定依頼を受信すると、前記顧客情報に基づき与信行為の可否判定を行い、与信可能の場合、前記第1サーバに対し、与信承認番号、承認日、及び承認金額のデータを送信する
ことを特徴とする決済システム。
【請求項2】
銀行口座を管理する第3サーバ(13)を備え、
前記第1サーバは、前記第3サーバに対して、与信相当額の口座振替のための前記銀行口座が正当か否かを判断し、前記銀行口座が正当な場合に前記顧客情報及び口座振替承認依頼を送信し、
前記第3サーバは、前記第1サーバから前記顧客情報及び前記口座振替承認依頼を受信すると、前記与信相当額の口座振替のための口座振替受付処理を行う
ことを特徴とする請求項1に記載の決済システム。
【請求項3】
前記第1サーバは、前記銀行口座が正当か否かを判断した結果及び前記与信結果を前記端末へ送信する
ことを特徴とする請求項2に記載の決済システム。
【請求項4】
端末から顧客情報が入力される第4サーバ(22)と、
前記4サーバから前記顧客情報が入力される第5サーバ(25)と、
信販会社に管理される第6サーバ(24)とを備え、
前記第5サーバは、前記第6サーバに対して、前記顧客情報及び与信行為可否判定依頼を送信し、
前記第6サーバは、前記第5サーバから前記顧客情報及び前記与信行為可否判定依頼を受信すると、前記顧客情報に基づき与信行為の可否判定を行い、与信可能の場合、前記第5サーバに対し、与信承認番号、承認日、及び承認金額のデータを送信し、
前記第5サーバは、前記データを前記第4サーバに送信する
ことを特徴とする決済システム。
【請求項5】
銀行口座を管理する第7サーバ(23)を備え、
前記第5サーバは、前記第7サーバに対して、与信相当額の口座振替のための前記銀行口座が正当か否かを判断し、前記銀行口座が正当な場合に前記顧客情報及び口座振替承認依頼を送信し、
前記第7サーバは、前記第5サーバから前記顧客情報及び前記口座振替承認依頼を受信すると、与信相当額の口座振替のための口座振替受付処理を行う
ことを特徴とする請求項4に記載の決済システム。
【請求項6】
前記第4サーバは、前記銀行口座が正当か否かを判断した結果及び前記与信結果を前記端末へ送信する
ことを特徴とする請求項5に記載の決済システム。
【請求項7】
それぞれ各端末から顧客情報が入力される複数の第8サーバ(22−1〜22−N)と、
前記第8サーバから前記顧客情報が入力される第9サーバ(26)と、
それぞれ各信販会社に管理される複数の第10サーバ(24−1〜24−M)とを備え、
前記第9サーバは、1つの前記第10サーバを選定し、前記顧客情報及び与信行為可否判定依頼を当該第10サーバに対して送信し、
前記選定された前記第10サーバは、前記第9サーバから前記顧客情報及び前記与信行為可否判定依頼を受信すると、前記顧客情報に基づき与信行為の可否判定を行い、与信可能の場合、前記第9サーバに対し、与信承認番号、承認日、及び承認金額のデータを送信し、
前記第9サーバは、前記選定された前記第10サーバが与信不可の場合、別の前記第10サーバを選定し、前記顧客情報及び前記与信行為可否判定依頼を当該第10サーバに対して送信し、与信可能となった時点で、前記データを前記第8サーバに送信する
ことを特徴とする決済システム。
【請求項8】
銀行口座を管理する第11サーバ(23)を備え、
前記第9サーバは、前記第11サーバに対して、与信相当額の口座振替のための前記銀行口座が正当か否かを判断し、前記銀行口座が正当な場合に前記顧客情報及び口座振替承認依頼を送信し、
前記第11サーバは、前記第9サーバから前記顧客情報及び前記口座振替承認依頼を受信すると、与信相当額の口座振替のための口座振替受付処理を行う
ことを特徴とする請求項7に記載の決済システム。
【請求項9】
前記第8サーバは、前記銀行口座が正当か否かを判断した結果及び前記与信結果を前記端末へ送信する
ことを特徴とする請求項8に記載の決済システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、保険料等の決済システムに関するものである。
【背景技術】
【0002】
現在、多くの生命保険会社では、初回保険料の徴収方法をキャッシュレス化する技術が採用されている。
【0003】
具体的には、デビットカードあるいはクレジットカードによる徴収方法、顧客が直接保険会社の口座に初回保険料を振り込む方法、保険会社が初回保険料を顧客の口座から振り替える方法等がある。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2002−230287号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
デビットカードあるいはクレジットカードによる徴収方法では、決済専用の高価なモバイル端末が必要となり費用がかかる。また、当該方法を利用できる顧客がデビットカードあるいはクレジットカードの保有者に限定されてしまう。
【0006】
顧客が直接保険会社の口座に初回保険料を振り込む方法では、休日または夜間の利用時間帯などの制限がある。また、顧客が銀行などに出向く必要がある。
【0007】
保険会社が初回保険料を顧客の口座から振り替える方法では、保険の申し込みから初回の保険料振り替えまでに時間がかかる。そして初回保険料の入金までの保障がない(又は特別な約款対応等が必要となる)。さらに、保険契約募集人(営業担当者)へのコミッションの支払いが通常より(2〜3ヶ月程度)遅れる。
【0008】
本発明は、上記技術的課題に鑑み、顧客にとって保険契約の保障開始を早めることを可能とする決済システムを提供することを目的とする。
【課題を解決するための手段】
【0009】
上記課題を解決するための第1の発明に係る決済システムは、
端末から顧客情報が入力される第1サーバ(12)と、
信販会社に管理される第2サーバ(14)とを備え、
前記第1サーバは、前記第2サーバに対して、前記顧客情報及び与信行為可否判定依頼を送信し、
前記第2サーバは、前記第1サーバから前記顧客情報及び前記与信行為可否判定依頼を受信すると、前記顧客情報に基づき与信行為の可否判定を行い、与信可能の場合、前記第1サーバに対し、与信承認番号、承認日、及び承認金額のデータを送信する
ことを特徴とする。
【0010】
上記課題を解決するための第2の発明に係る決済システムは、
上記第1の発明に係る決済システムにおいて、
銀行口座を管理する第3サーバ(13)を備え、
前記第1サーバは、前記第3サーバに対して、与信相当額の口座振替のための前記銀行口座が正当か否かを判断し、前記銀行口座が正当な場合に前記顧客情報及び口座振替承認依頼を送信し、
前記第3サーバは、前記第1サーバから前記顧客情報及び前記口座振替承認依頼を受信すると、前記与信相当額の口座振替のための口座振替受付処理を行う
ことを特徴とする。
【0011】
上記課題を解決するための第3の発明に係る決済システムは、
上記第2の発明に係る決済システムにおいて、
前記第1サーバは、前記銀行口座が正当か否かを判断した結果及び前記与信結果を前記端末へ送信する
ことを特徴とする。
【0012】
上記課題を解決するための第4の発明に係る決済システムは、
端末から顧客情報が入力される第4サーバ(22)と、
前記4サーバから前記顧客情報が入力される第5サーバ(25)と、
信販会社に管理される第6サーバ(24)とを備え、
前記第5サーバは、前記第6サーバに対して、前記顧客情報及び与信行為可否判定依頼を送信し、
前記第6サーバは、前記第5サーバから前記顧客情報及び前記与信行為可否判定依頼を受信すると、前記顧客情報に基づき与信行為の可否判定を行い、与信可能の場合、前記第5サーバに対し、与信承認番号、承認日、及び承認金額のデータを送信し、
前記第5サーバは、前記データを前記第4サーバに送信する
ことを特徴とする。
【0013】
上記課題を解決するための第5の発明に係る決済システムは、
上記第4の発明に係る決済システムにおいて、
銀行口座を管理する第7サーバ(23)を備え、
前記第5サーバは、前記第7サーバに対して、与信相当額の口座振替のための前記銀行口座が正当か否かを判断し、前記銀行口座が正当な場合に前記顧客情報及び口座振替承認依頼を送信し、
前記第7サーバは、前記第5サーバから前記顧客情報及び前記口座振替承認依頼を受信すると、与信相当額の口座振替のための口座振替受付処理を行う
ことを特徴とする。
【0014】
上記課題を解決するための第6の発明に係る決済システムは、
上記第5の発明に係る決済システムにおいて、
前記第4サーバは、前記銀行口座が正当か否かを判断した結果及び前記与信結果を前記端末へ送信する
ことを特徴とする。
【0015】
上記課題を解決するための第7の発明に係る決済システムは、
それぞれ各端末から顧客情報が入力される複数の第8サーバ(22−1〜22−N)と、
前記第8サーバから前記顧客情報が入力される第9サーバ(26)と、
それぞれ各信販会社に管理される複数の第10サーバ(24−1〜24−M)とを備え、
前記第9サーバは、1つの前記第10サーバを選定し、前記顧客情報及び与信行為可否判定依頼を当該第10サーバに対して送信し、
前記選定された前記第10サーバは、前記第9サーバから前記顧客情報及び前記与信行為可否判定依頼を受信すると、前記顧客情報に基づき与信行為の可否判定を行い、与信可能の場合、前記第9サーバに対し、与信承認番号、承認日、及び承認金額のデータを送信し、
前記第9サーバは、前記選定された前記第10サーバが与信不可の場合、別の前記第10サーバを選定し、前記顧客情報及び前記与信行為可否判定依頼を当該第10サーバに対して送信し、与信可能となった時点で、前記データを前記第8サーバに送信する
ことを特徴とする。
【0016】
上記課題を解決するための第8の発明に係る決済システムは、
上記第7の発明に係る決済システムにおいて、
銀行口座を管理する第11サーバ(23)を備え、
前記第9サーバは、前記第11サーバに対して、与信相当額の口座振替のための前記銀行口座が正当か否かを判断し、前記銀行口座が正当な場合に前記顧客情報及び口座振替承認依頼を送信し、
前記第11サーバは、前記第9サーバから前記顧客情報及び前記口座振替承認依頼を受信すると、与信相当額の口座振替のための口座振替受付処理を行う
ことを特徴とする。
【0017】
上記課題を解決するための第9の発明に係る決済システムは、
上記第8の発明に係る決済システムにおいて、
前記第8サーバは、前記銀行口座が正当か否かを判断した結果及び前記与信結果を前記端末へ送信する
ことを特徴とする。
【発明の効果】
【0018】
本発明に係る決済システムによれば、顧客にとって保険契約の保障開始を早めることが可能となると同時に、保険契約募集人への手数料支払いを早めることも可能になる。
【図面の簡単な説明】
【0019】
【図1】本発明の実施例1に係る決済システムを説明するブロック図である。
【図2】本発明の実施例1に係る決済システムを説明するフローチャートである。
【図3】本発明の実施例2に係る決済システムを説明するブロック図である。
【図4】本発明の実施例2に係る決済システムを説明するフローチャートである。
【図5】本発明の実施例3に係る決済システムを説明するブロック図である。
【発明を実施するための形態】
【0020】
以下、本発明に係る決済システムについて、実施例にて図面を用いて説明する。
【0021】
[実施例1]
本実施例に係る決済システムは、保険会社・信販会社提携による初回保険料の与信処理を行うシステムである。
【0022】
図1に示すように、本実施例に係る決済システム1は、互いにインターネット等のネットワークを介して通信可能な端末11、保険会社サーバ12、銀行サーバ13、及び信販会社サーバ14を備えている。
【0023】
端末11は、保険会社が管理し当該保険会社の営業担当者が所持するPC、スマートフォン、あるいはタブレット等であり、保険会社サーバ12に対し、営業担当者のコード及びパスワードを入力することでアクセス認証を受けてから、後述する各種入力を行うことができる。
【0024】
端末11は、アクセスした保険会社サーバ12に対し、顧客氏名、性別、生年月日、住所、電話番号、初回保険料(与信相当額)、本人確認手段、及び証券番号等、保険の契約に必要な顧客情報Aを入力することができる。
【0025】
ここで、本実施例に係る決済システム1においては、顧客が保険契約の申込書(営業担当者が所持している)にサインすることで、顧客と保険会社との保険契約を締結するとともに、顧客が端末11を用いて初回保険料の与信申し込み及び与信相当額の口座振替依頼を(保険会社サーバ12に対して)行うことで、顧客と信販会社との契約を締結する。
【0026】
このうち、初回保険料の与信申し込み及び与信相当額の口座振替依頼については、端末11から保険会社サーバ12に対し、銀行、支店、預金種目、口座番号、(口座名義人)、及び初回保険料(与信相当額)等、当該契約に必要な顧客情報Bを入力することで行われる。
【0027】
一方、保険会社サーバ12は保険会社が管理するサーバであり、銀行サーバ13に対して与信相当額の口座振替のための銀行口座の正当性を確認する(正当か否かを判断する)。
【0028】
そして、銀行口座が正当な場合には、銀行サーバ13に対して端末11から入力された各顧客情報A,B及び口座振替承認依頼Cを送信するとともに、端末11に対して振替口座確認済みの旨を通知する。口座が不当な場合には、端末11に対して振替口座の確認ができなかった旨を通知する。
【0029】
また、保険会社サーバ12は、信販会社サーバ14に対して各顧客情報A,B及び与信行為可否判定依頼Dを送信する。
【0030】
さらに、保険会社サーバ12は、端末11に対して、信販会社サーバ14から受信した与信結果を送信する。すなわち、与信可能の場合(信販会社サーバ14から与信承認番号、承認日、及び承認金額(=与信相当額)のデータを受信した場合)は、与信承認の旨及び与信承認メール(与信承認番号、承認日、及び承認金額のデータ)を端末11へ送信し、与信不可の場合(信販会社サーバ14から与信不可の旨を受信した場合)は、与信不可の旨を端末11へ送信する。
【0031】
銀行サーバ13は銀行(地銀CNS、都銀、又は信金)における口座を管理するサーバであり、保険会社サーバ12から各顧客情報A,B及び口座振替承認依頼Cを受信すると、与信相当額の口座振替のための口座振替受付処理を行う。
【0032】
信販会社サーバ14は信販会社が管理するサーバであり、保険会社サーバ12から各顧客情報A,B及び与信行為可否判定依頼Dを受信すると、信販会社サーバ14を管理する信販会社内で取り決めた所定条件と各顧客情報A,Bとを照らし合わせ、与信行為の可否判定を行う。
【0033】
与信可能の場合、与信承認、及び与信相当額の口座振替処理を行う。また、保険会社サーバ12に対し、与信承認明細(与信承認番号、承認日、及び承認金額のデータ)を送信する。一方、与信不可の場合にはその旨を保険会社サーバ12に通知する。
【0034】
そして、与信可能の場合、信販会社サーバ14を管理する信販会社から保険会社サーバ12を管理する保険会社に与信相当額(合計)の送金(与信相当額から信販会社の手数料を控除した金額)を行う。なお、与信承認明細は信販会社から保険会社に紙媒体で郵送するようにしてもよい。
【0035】
さらに、信販会社サーバ14は、銀行サーバ13が管理する銀行口座から与信相当額を引き去る。
【0036】
以上が、決済システム1の構成についての説明である。以下では、このような構成とした決済システム1の処理について、図2のフローチャートを用いて説明する。
【0037】
ステップS1では、顧客との保険契約を締結する。すなわち、端末11を用いて保険の契約に必要な顧客情報を入力し、また、顧客が保険契約の申込書にサインすることで、顧客と保険会社との保険契約を締結し、さらに、端末11を用いて初回保険料の与信申し込み及び与信相当額の口座振替依頼を行うことで、顧客と信販会社との契約を締結する。
【0038】
ステップS2では、保険会社サーバ12が銀行サーバ13に対して、与信相当額の口座振替のための銀行口座の正当性を確認する。正当であればステップS3Aへ、不当であればステップS3Bへそれぞれ移行する。
【0039】
ステップS3Aでは、保険会社サーバ12が、銀行サーバ13に対して端末11から入力された各顧客情報及び口座振替承認依頼を送信するとともに、端末11に対して振替口座確認済みの旨を通知する。これにより、営業担当者が振替口座確認済みの旨を把握することができる。
【0040】
ステップS3Bでは、保険会社サーバ12が端末11に対して振替口座の確認ができなかった旨(振替口座確認エラー)を通知する。これにより、営業担当者は振替口座確認ができなかった旨を把握することができる。
【0041】
ステップS4では、保険会社サーバ12が信販会社サーバ14に対して与信行為可否判定依頼を送信する。
【0042】
ステップS5では、信販会社サーバ14が与信行為の可否判定を行い、与信可能であればステップS6Aへ、与信不可であればステップS6Bへそれぞれ移行する。
【0043】
ステップS6Aでは、信販会社サーバ14が、与信承認及び与信相当額の口座振替処理を行うとともに、保険会社サーバ12に対し与信承認明細を送信する。なお、与信承認が為された時点で、顧客との各契約が成立したことになり保障が開始される。
【0044】
ステップS6Bでは、信販会社サーバ14が保険会社サーバ12に対し与信不可の旨を通知する。当該通知は保険会社サーバ12から端末11に転送される。これにより、営業担当者が与信不可の旨を把握することができる。
【0045】
ステップS7では、信販会社サーバ14から与信承認明細を受信した保険会社サーバ12が、端末11に与信承認の旨を通知する。また、併せて与信承認明細の内容を与信承認メールとして送信する。これにより、営業担当者が与信承認の旨を把握することができる。
【0046】
ステップS8では、信販会社サーバ14から保険会社サーバ12へ与信相当額を送金する。
【0047】
ステップS9では、信販会社サーバ14が銀行サーバ13の管理する銀行口座から与信相当額を引き去る。
以上が、上記構成とした決済システム1の処理についての説明である。
【0048】
本実施例によれば、信販会社サーバ14を管理する信販会社に次のような利点がある。
・保険会社の営業担当者により顧客の本人確認を行っているため、信販会社のリスクを低減することができる。
・保険会社の営業担当者により顧客の一次選択を行っているため、信販会社のリスクを低減することができる。
・信販会社から保険会社サーバ12を管理する保険会社の口座に直接送金するので、目的外利用の可能性がない。
・信販会社は、保険会社との特約締結により、顧客から与信金額の回収不能な場合は保険会社から回収可能である。
・保険会社等の法人との契約を基本としており、信用性が高い。
・個人単独での利用を排除しており、信頼性が高い。
【0049】
また本実施例によれば、顧客に対しデビットカードあるいはクレジットカードを発行する必要が無い。また、顧客が直接保険会社の口座に初回保険料を振り込む必要も無い。
【0050】
さらに本実施例では、信販会社が初回保険料を顧客の口座から振り替えるが、この場合は、信販会社に与信の承認が得られた時点から顧客の保障が開始される(振り替えは後から行っても良い)。
【0051】
さらに本実施例では、(初回保険料支払時に顧客情報を入力していることから、手続を簡略化できる為)継続保険料のクレジット払いの利用促進が可能となり、ひいては新規クレジット加入者の拡大を図ることができる。
【0052】
[実施例2]
図3に示すように、本実施例に係る決済システム2は、互いにインターネット等のネットワークを介して通信可能な端末21、保険会社サーバ22、銀行サーバ23、信販会社サーバ24、及び中間サーバ25を備えている。
【0053】
すなわち、本実施例に係る決済システム2は、実施例1に係る決済システム1に中間サーバ25を付加し、それに伴い端末11、保険会社サーバ12、銀行サーバ13、及び信販会社サーバ14を、それぞれ一部変更し、端末21、保険会社サーバ22、銀行サーバ23、及び信販会社サーバ24としたものである。以下、実施例1と重複する部分については極力省略し、異なる部分を中心に説明する。
【0054】
中間サーバ25は、金融取引システムを開設する会社が管理するサーバである。
【0055】
保険会社サーバ22は、中間サーバ25に対して、会社コード及びパスワードの入力を行うことで、中間サーバ25のアクセス認証を受けてから、端末21から入力された各顧客情報A,B(実施例1参照)を送信する。
【0056】
各顧客情報A,Bを受信した中間サーバ25は、銀行サーバ23に対して与信相当額の口座振替のための銀行口座の正当性を確認する(正当か否かを判断する)。
【0057】
そして、銀行口座が正当な場合には、銀行サーバ23に対して各顧客情報A,B及び口座振替承認依頼Cを送信するとともに、保険会社サーバ22に対して、振替口座確認済みの旨を通知する。口座が不当な場合には、保険会社サーバ22に対して振替口座の確認ができなかった旨を通知する。保険会社サーバ22はこれらの通知を端末21に転送する。
【0058】
また、中間サーバ25は、信販会社サーバ24に対して各顧客情報A,B及び与信行為可否判定依頼Dを送信する。
【0059】
さらに、中間サーバ25は、保険会社サーバ22に対して、信販会社サーバ24から受信した与信結果を送信する。すなわち、与信可能の場合(信販会社サーバ24から与信承認番号、承認日、及び承認金額のデータを受信した場合)は、与信承認の旨及び与信承認メール(与信承認番号、承認日、及び承認金額のデータ)を保険会社サーバ22へ送信し、与信不可の場合(信販会社サーバ24から与信不可の旨を受信した場合)は、与信不可の旨を保険会社サーバ22へ送信する。保険会社サーバ22はこれらの通知を端末21に転送する。
【0060】
銀行サーバ23は、中間サーバ25から各顧客情報A,B及び口座振替承認依頼Cを受信すると、与信相当額の口座振替のための口座振替受付処理を行う。
【0061】
信販会社サーバ24は、中間サーバ25から各顧客情報A,B及び与信行為可否判定依頼Dを受信すると、信販会社サーバ24を管理する信販会社内で取り決めた所定条件と各顧客情報A,Bとを照らし合わせ、与信行為の可否判定を行う。
【0062】
与信可能の場合、与信承認、及び与信相当額の口座振替処理を行う。また、中間サーバ25に対し、与信承認番号、承認日、及び承認金額のデータを送信する。一方、与信不可の場合にはその旨を中間サーバ25に通知する。
【0063】
そして与信可能の場合、信販会社サーバ24は中間サーバ25に対し、与信相当額(合計)の送金を行うとともに、与信相当額の与信承認明細を送信する。
【0064】
そして、中間サーバ25は、信販会社サーバ24から受信した与信承認番号、承認日、承認金額のデータ、及び与信相当額の与信承認明細を、保険会社サーバ22に送信する。
【0065】
以上が、決済システム2の構成についての説明である。以下では、このような構成とした決済システム2の処理について、図4のフローチャートを用いて説明する。
【0066】
ステップS11では、顧客との契約を締結する。すなわち、端末21を用いて保険の契約に必要な顧客情報を入力し、また、顧客が保険契約の申込書にサインすることで、顧客と保険会社との保険契約を締結し、さらに、端末21を用いて初回保険料の与信申し込み及び与信相当額の口座振替依頼を行うことで、顧客と信販会社との契約を締結する。
【0067】
ステップS12では、保険会社サーバ22が中間サーバ25の認証を取得し、中間サーバ25に対して、端末21から入力された各顧客情報を送信する。
【0068】
ステップS13では、中間サーバ25が銀行サーバ23に対して、与信相当額の口座振替のための銀行口座の正当性を確認する。正当であればステップS14Aへ、不当であればステップS14Bへそれぞれ移行する。
【0069】
ステップS14Aでは、中間サーバ25が、銀行サーバ23に対して各顧客情報及び口座振替承認依頼を送信するとともに、保険会社サーバ22に対して振替口座確認済みの旨を通知する。当該通知は、保険会社サーバ22から端末21へ転送される。これにより、営業担当者が振替口座確認済みの旨を把握することができる。
【0070】
ステップS14Bでは、中間サーバ25が保険会社サーバ22に対して振替口座の確認ができなかった旨(振替口座確認エラー)を通知する。当該通知は、保険会社サーバ22から端末21へ転送される。これにより、営業担当者は振替口座確認ができなかった旨を把握することができる。
【0071】
ステップS15では、中間サーバ25が信販会社サーバ24に対して与信行為可否判定依頼を送信する。
【0072】
ステップS16では、信販会社サーバ24が与信行為の可否判定を行い、与信可能であればステップS17Aへ、与信不可であればステップS17Bへそれぞれ移行する。
【0073】
ステップS17Aでは、信販会社サーバ24が、与信承認及び与信相当額の口座振替処理を行うとともに、中間サーバ25に対し、与信承認番号、承認日、及び承認金額のデータを送信する。なお、与信承認が為された時点で、顧客との各契約が成立したことになり保障が開始される。
【0074】
ステップS17Bでは、信販会社サーバ24が中間サーバ25に対し与信不可の旨を通知する。当該通知は中間サーバ25から保険会社サーバ22に転送され、さらに保険会社サーバ22から端末21に転送される。これにより、営業担当者が与信不可の旨を把握することができる。
【0075】
ステップS18では、中間サーバ25が保険会社サーバ22に対し、信販会社サーバ24から受信した上記データを転送し、保険会社サーバ22は、当該データを受信すると、端末21に与信承認メールを送信する。これにより、営業担当者が与信承認の旨を把握することができる。
【0076】
ステップS19では、信販会社サーバ24から中間サーバ25に与信承認明細を送信するとともに、信販会社サーバ24から保険会社サーバ22へ与信相当額を送金する。
【0077】
ステップS20では、信販会社サーバ24が銀行サーバ23の管理する銀行口座から与信相当額を引き去る。
【0078】
以上が、上記構成とした決済システム2の処理についての説明である。本実施例によれば実施例1と同様の作用効果を奏することができる。
【0079】
[実施例3]
図5に示すように、本実施例に係る決済システム3は、端末21−1,21−2,…21−N、保険会社サーバ22−1,22−2,…22−N、銀行サーバ23、信販会社サーバ24−1,24−2,…24−M、及び中間サーバ26を備えている。
【0080】
すなわち、本実施例に係る決済システム3は、実施例2に係る決済システム2の中間サーバ25に代えて中間サーバ25にハブとしての機能を持たせた中間サーバ26を備えるものである。以下、実施例2と重複する部分については極力省略し、異なる部分を中心に説明する。
【0081】
中間サーバ26は、保険会社サーバ22−1,22−2,…22−N、銀行サーバ23、及び信販会社サーバ24−1,24−2,…24−Mと、並行して接続することが可能である。
【0082】
保険会社サーバ22−n(1≦n≦N)から各顧客情報A,B(実施例1参照)を受信した中間サーバ26は、所定の基準に基づき、1つの信販会社サーバ24−m(1≦m≦M)を選定し、顧客情報A,B及び与信行為可否判定依頼Dを信販会社サーバ24−mに送信する。なお、ここでの所定の基準とは、例えば手数料の安さ等である。
【0083】
信販会社サーバ24−mが与信可能の場合、以降は実施例2における与信可能の場合と同一の処理を行う。一方で、信販会社サーバ24−mが与信不可の場合、中間サーバ26は、次の信販会社サーバ24−o(1≦o≦M,o≠m)を選定し(所定の基準に基づく次の優先順位)、顧客情報A,B及び与信行為可否判定依頼Dを信販会社サーバ24−oに送信する。
【0084】
中間サーバ26は、与信可能となるまでこの処理を行う。与信可能となった時点で、実施例2における与信可能の場合と同一の処理を行う。最終的に全ての信販会社サーバ24−1,24−2,…24−Mにおいて与信不可であった場合、実施例2における与信不可の場合と同一の処理を行う。
【0085】
このようにして本実施例では、システムとしての汎用性が向上し、保険会社にとってより良い信販会社に依頼することができる。
【0086】
なお、実施例1〜3では、保険会社サーバを保険会社の管理するサーバとし、端末を当該保険会社の営業担当者が所持するPC等とし、信販会社サーバを信販会社の管理するサーバとしたが、本発明はこれに限定されるものではない。
【0087】
例えば、保険会社サーバは百貨店等の運営会社が管理するサーバとし、端末は百貨店等の店舗のレジスタ装置に接続されるものとし、顧客は当該百貨店等で品物を分割払いで購入する購入者であるものとし、信販会社サーバは与信機能を有する金融機関(銀行等)としてもよい。
【0088】
すなわち、顧客が保険料ではなく現物を分割払いで購入する場合にも、本発明を適用することができる。
【産業上の利用可能性】
【0089】
本発明は、保険料等の決済システムとして好適である。
【符号の説明】
【0090】
1〜3 決済システム
11,21,21−1〜21−N 端末
12,22,22−1〜22−N 保険会社サーバ
13,23 銀行サーバ
14,24,24−1〜24−M 信販会社サーバ
【図1】
【図2】
【図3】
【図4】
【図5】