【実施例1】
【0015】
図1には、本発明の保険管理アラートシステムの実施例1が示されている。同図において、保険管理アラートシステム10は、保険情報管理システム100を中心に構成されている。保険情報管理システム100は、インターネット12を介して、多数の保険契約者である登録者端末200や、家族等の連絡先である連絡先端末300に接続されている。なお、必ずしも保険金の支払先である必要はない。
【0016】
これらのうち、保険情報管理システム100は、管理サーバ110,保険情報管理データベース120,メールサーバ130を備えている。管理サーバ110は、日数カウントプログラム112,通知処理プログラム114,連絡処理プログラム116,ユーザ設定プログラム118を備えており、それらを実行することで、所定の起算日からの日数をカウントするとともに、所定の日数が経過したらその旨を該当する登録者端末200に通知し、所定の状況となったらその旨を該当する連絡先端末300に通知する機能を備えている。
【0017】
保険情報管理データベース120は、本アラートサービスを利用する登録者の保険に関する保険金額や支払先などの保険情報、安否確認を確認する当人である登録者の通知先、登録者の安否が確認できなかったときに連絡する縁故者等の未確認時連絡先、その他のデータが集積されている。
【0018】
メールサーバ130は、上述した登録者通知先の登録者端末200に対して安否を確認するための電子メール(以下単に「メール」という)を送信したり、登録者端末200から安否確認の応答があったときにそれを受領したり、安否が確認できなかったときに未確認時連絡先の連絡先端末300にメールを送信する機能を備えている。
【0019】
次に、登録者端末200は、スマートフォン,パソコン,タブレット端末など、各種の情報機器が使用可能であり、本アラートサービスを受けるための保険アプリ(保険プログラム)210がインストールされる。保険アプリ210は、保険情報管理システム100から安否確認のメールを受信したときに、音,光,振動などで登録者にその旨を知らせるとともに、登録者によるログインがあったときに安否を確認した旨の応答を保険情報管理システム100に対して送信する機能を備えている。連絡先端末300は、保険情報管理システム100から安否未確認のメール連絡を受けるためのもので、スマートフォン,パソコン,タブレット端末など、各種の情報機器が使用される。
【0020】
次に、本実施例の全体的な動作を、
図2のフローチャートも参照して説明する。本アラートサービスを受ける登録者は、加入している保険情報を、自分の端末のメールアドレスや、家族などの連絡先の端末のメールアドレスとともに、保険情報管理システム100に提供する。提供方法は、郵便,メール,ファクシミリなど、各種の方法としてよい。保険アプリ210を利用して、上述した保険情報等を保険情報管理システム100に提供するようにしてもよい。これらの情報は、保険情報管理データベース120に保存・登録される。また、登録者は、自分の端末に保険アプリをインストールする。このとき、必要があれば、家族などの連絡先に、本アラートサービスを受けている旨を事前に知らせておくようにしてもよい。
【0021】
更に、登録者が安否確認の回数や日数の設定を希望するときは、その旨を保険アプリ210を利用して保険情報管理システム100に要求する。すると、保険情報管理システム100では、ユーザ設定プログラム118が実行され、設定画面が登録者端末200に表示される。登録者は、設定画面を利用して、安否確認の回数や日数を設定することができる。登録者が設定しないときは、予め定めたデフォルトの回数や期日とする。以下の例では、契約日から30日,40日,50日目にそれぞれ安否確認を行うようにしている。
【0022】
保険情報の登録や安否確認日時の設定が終了すると、保険情報管理システム100では、管理サーバ110において日数カウントプログラム112が実行され、所定の起算日、例えば払込期月初日からの経過日数のカウントが開始される(ステップS10)。そして、30日目がカウントされると(ステップS12のYes)、管理サーバ110の通知処理プログラム114が実行されて、第1回目の安否確認通知がメールサーバ130から登録者端末200に対して行われる(ステップS14)。管理サーバ110は、予め定めた時間の間、応答待ちの状態となる(ステップS16)。
【0023】
一方、登録者は、その端末200で安否確認通知を受領すると(ステップS18)、保険アプリ210にログインし、通知を受け取ったことを応答する(ステップS20)。
【0024】
保険情報管理システム100では、メールサーバ130で登録者端末200による応答を受領すると(ステップS22,S24のYes)、登録者の安否が確認できたものと判断し、日数カウントプログラム112によって、再び最初の30日の日数カウントを繰り返す。このように、通常であれば、ステップS10〜S24の動作が繰り返され、30日毎に登録者の安否の確認が行われる。
【0025】
次に、上述した30日目の安否確認に対し、登録者が死亡していたり要介護状態となって、登録者端末200から応答がなかったときは(ステップS24のNo)、日数カウントプログラム112によって日数カウントが再開される(ステップS26)。そして、前記30日から更に10日経過した40日目がカウントされると(ステップS28のYes)、管理サーバ110の通知処理プログラム114が実行されて、第2回目の安否確認通知がメールサーバ130から登録者端末200に対して行われる(ステップS30)。管理サーバ110は、予め定めた時間の間、応答待ちの状態となる(ステップS32)。
【0026】
一方、登録者は、その端末200で安否確認通知を受領すると(ステップS34)、保険アプリ210にログインし、通知を受け取ったことを応答する(ステップS36)。保険情報管理システム100では、メールサーバ130で登録者端末200による応答を受領すると(ステップS38,S40のYes)、登録者の安否が確認できたものと判断し、通知処理プログラム114によって、再び最初の30日の日数カウントを繰り返す。
【0027】
次に、上述した40日目の安否確認に対して、登録者端末200から応答がなかったときは(ステップS40のNo)、日数カウントプログラム112によって日数カウントが再開される(ステップS42)。そして、前記40日から更に10日経過した50日目がカウントされると(ステップS44のYes)、管理サーバ110の通知処理プログラム114が実行されて、第3回目の安否確認通知がメールサーバ130から登録者端末200に対して行われる(ステップS46)。管理サーバ110は、予め定めた時間の間、応答待ちの状態となる(ステップS48)。
【0028】
一方、登録者は、その端末200で安否確認通知を受領すると(ステップS50)、保険アプリ210にログインし、通知を受け取ったことを応答する(ステップS52)。保険情報管理システム100では、メールサーバ130で登録者端末200による応答を受領すると(ステップS54,S56のYes)、登録者の安否が確認できたものと判断し、通知処理プログラム114によって、再び最初の30日の日数カウントを繰り返す。
【0029】
次に、上述した50日目の安否確認に対して、登録者端末200から応答がなかったときは(ステップS56のNo)、管理サーバ110は、登録者が死亡していたり要介護状態となっているものと判断する。そして、連絡処理プログラム116を実行し、該当する登録者の保険情報を参照して、メールサーバ130によるメール送信で、安否未確認の旨を該当する連絡先端末300に連絡する(ステップS58)。
【0030】
このように、本実施例によれば、50日が経過した時点で登録者の安否が確認できないときは、登録者が応答できないような状態、例えば死亡や要介護状態になったものと判断して、家族等にその旨が通知される。このため、家族等は、登録者が置かれている状況を確認し、保険料支払いなどの処理を行って、保険契約の失効を免れることができる。
【実施例2】
【0031】
次に、
図3を参照しながら、本発明の実施例2について説明する。一般的に、保険料は、月払いの場合、月ごとの契約応当日が属する払込期月の1日から末日までとなっていることが多い。そして、払込期月内に保険料の払い込みが行われなかった場合でも、多くの場合は払込猶予期間が1か月あるので、この期間内に保険料を払い込めば、保険契約の失効を免れることができる。
【0032】
上述した実施例1は、
図3(A)に示すように、払込期月と払込猶予期間の2か月を利用して、安否確認を行うようにした例である。この場合、例えば50日目に登録者の安否が確認できなかったとしてその旨が連絡先端末300に連絡されたとすると、連絡先の家族等は、残りの10日間のうちに保険料を支払うことになる。
【0033】
これに対し、本実施例では、同図(B)に示すように、払込期月内の15日,20日,25日で、それぞれ安否確認を行うようにしている。このようにすれば、払込期月内での保険料の支払いを促すことができ、仮にそれが行われなくても、その後の払込猶予期間内に保険料を支払うことで失効を防ぐことができる。ただし、登録者に対する安否確認の頻度は高くなる。
【0034】
なお、前記例では、払込期月の15日,20日,25日に安否確認を行ったが、例えば、登録者が1〜14日の間(あるいは16〜19日,21日〜24日)に、登録者が保険アプリ210にログインしているときは、安否を確認できたものと考えることができるので、それ以降の安否確認は行わず、次の払込期月の15日から再び安否確認を行うようにしてもよい。
【0035】
同図(C)の例は、同図(B)の変形例で、払込期月の25日目で安否確認ができなかったときに、50日目,すなわち払込猶予期間の10日前に、保険料を払ったかどうかの確認を連絡先端末300に対して行うようにしたものである。猶予期間の終了前に、念のため、保険料を払わないと失効する旨の通知を行うことで、保険契約の失効を防ぐようにしている。
【実施例3】
【0036】
次に、
図4を参照しながら、本発明の実施例3について説明する。この例は、登録者の安否未確認の連絡を受けた連絡先の家族などが保険料を支払った後の処理に関するものである。安否未確認の場合には、登録者がたまたま安否確認のログインを怠った場合もあろうし、登録者がログインできないような状況、例えば要介護状態となる場合も考えられる。そこで、本実施例では、連絡先端末300で安否未確認の連絡(ステップS58)を受け取った(ステップS60)後に、家族等が保険料を支払ったときは(ステップS62)、その旨を保険情報管理システム100に通知する(ステップS64)。
【0037】
これを保険情報管理システム100が受領すると(ステップS66)、保険情報管理システム100は、家族等の連絡や登録者への問合せを行って状況を把握し、以後の対応を決める。
a,登録者が生存しており、単に安否確認のログインを怠った場合は、前記実施例1又は2で示した登録者に対する安否確認を再び行うようにする(ステップS68a)。例えば、長期の海外旅行などで安否確認ができなかった場合、登録者端末200を交換したときに保険アプリ210のインストールを忘れてしまったような場合などが該当する。
b,登録者が要介護状態など、安否確認に対応できない状態となったときは、家族等の連絡先端末300に対して、前記実施例1又は2で示した安否確認を行うようにする(ステップS68b)。
c,登録者の死亡等により保険料の支払いが終了したときや、家族等が保険契約の終了を希望したときは、安否確認動作を終了する(ステップS68c)。
【0038】
このようにすることで、安否確認のサービスの継続性を確保し、ユーザに安心感を与えることができる。
【0039】
なお、本発明は、上述した実施例に限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加えることができる。例えば、以下のものも含まれる。
(1)前記実施例で示したカウント日数の30日,40日,50日ないし15日,20日,25日は一例であり、必要に応じて適宜変更してよい。また、前記実施例では、安否確認のための問い合わせを、合計3回行うこととしたが、回数も必要に応じて設定してよい。更に、ユーザが日数や回数を設定する場合でも、ユーザがすべてを自由に設定するのではなく、予め設定した制限の範囲内で期日や回数を設定するようにしてもよい。
(2)前記実施例では、50日目ないし25日目の安否確認ができなかったときに家族等に連絡することとしたが、30日目や40日目あるいは15日目や20日目に、安否が確認できたかどうかを連絡するようにしてもよい。このようにすることで、家族等は、登録者が通常通り生活していることを知ることができる。
(3)前記実施例では、安否確認や連絡にメールを使用したが、電話,ファクシミリ,携帯電話のショートメッセージ,メッセンジャーアプリなど、各種の通信機能を利用してよい。
(4)前記実施例では、主として保険料が月払いの場合を説明したが、半年払いや年払いの場合も同様である。