JP2004110651A - 金融機関から顧客へ連絡を行うために用いられる装置および方法、この方法をコンピュータに実行させるプログラム、このプログラムを記録した記録媒体 - Google Patents

Abstract

【課題】金融機関との契約者本人以外に対する連絡は行わないようにしつつ、契約者本人に死亡等の事故があった場合には、指定された連絡先への連絡を行う。
【解決手段】確認データベース２０には、各サービス対象口座について、確認メール送信先アドレス、確認連絡時期情報、および、事故発生時の連絡先情報が少なくとも記録される。これらの情報に基づき、各顧客宛に指定されたタイミングで確認メールが送信され、それに対する応答の有無に基づき、顧客に事故が起きたかどうかが判定される。事故が起きたと判定された顧客について、指定された事故時連絡先が出力され、その出力結果に基づいて連絡が行われる。
【選択図】　　　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、銀行・信用金庫や保険会社等の金融機関から顧客に連絡を行うのに用いられるシステムおよび方法、この方法をコンピュータに実行させるためのプログラム、並びに、このプログラムを記録した記録媒体に関する。
【０００２】
【発明の背景】
従来より、銀行や信用金庫（以下、単に銀行という）における預金口座の通知区分として、預金者へ連絡を取ることが禁止された通信禁止口座がある。通信禁止口座は、例えば、顧客が預金口座の存在を家族に知られたくないような場合に利用される。通常の預金口座（顧客への連絡が禁止されていない口座）であれば、例えば、口座振込における番号違いや、外貨による振込依頼があった場合等の問合せや、各種お知らせ等の郵便や電話による連絡が預金者の自宅宛に行われるが、通信禁止口座の場合には、そのような問い合せは一切行われないことになる。
【０００３】
【発明が解決しようとする課題】
通信禁止口座でない通常の口座であれば、上記のように、預金者の自宅宛に連絡が行われるので、預金者の家族が口座の存在を知っていることが多いと考えられる。このため、万一、預金者本人に死亡や意識不明等の連絡を行えない事態（本明細書において「事故」という）が起きても、家族がそのことを銀行に知らせて、解約等の手続を取ることができる。しかし、通信禁止口座では、家族が口座の存在自体を知らないため、預金者に事故があっても、そのことが家族から銀行へ通知されることはない。また、本人死亡後の相続時には、税務署によって預金口座の調査が行われることもある。しかし、通信禁止口座は、その存在を家族に悟られないように、自宅住所から離れた無関係な土地の支店に開設される場合が多いため、税務署調査によって口座の存在が発覚することも期待できない。
【０００４】
したがって、通信禁止口座の名義人に死亡等の事故があっても、銀行側では、そのことを知る術がなく、通信禁止口座を放置しておくしかない。しかし、それでは預金者にとって自分の預金資産が家族（あるいは家族以外の近親者）に相続されないこととなり不合理である。また、銀行にとっても、放置口座の存在は口座管理負担の増加の原因となるため事務効率上好ましくない。
【０００５】
また、生命保険等の保険契約においても、被保険者本人が家族に知られることなく保険に加入したいというニーズを持つことがある。その場合にも、被保険者宛に一切連絡をとれないとしたのでは、本人に不慮の事故があった場合に、保険金受取人である家族に保険の存在を知らせる術がない。
【０００６】
本発明は上記の点に鑑みてなされたものであり、金融機関との契約者本人以外に対する連絡は行わないようにしつつ、契約者本人に事故があった場合には、指定された連絡先への連絡を行えるようにすることを目的とする。
【０００７】
【課題を解決するための手段】
上記の目的を達成するため、本発明は、金融機関との間で所定の契約を結んだ顧客に対して連絡を行うのに用いられるシステムであって、
前記所定の契約を結んだ各顧客について、確認連絡の通信先を特定するための確認通信先情報、確認連絡を行う時期を特定するための確認連絡時期情報、および、顧客に事故が起きたときの連絡先を含む事故時連絡情報が少なくとも記録されたデータベースと、
前記各顧客に対して、前記データベースに記録された確認連絡時期情報により特定される時期に、前記データベースに記録された確認通信先情報により特定される通信先へ、所定の通信手段にて確認連絡を行う確認通信手段と、
前記確認連絡に対する応答の有無に基づいて、顧客に事故があったかどうかを判定する事故判定手段と、
顧客に事故があったと判定された場合に、当該顧客について前記データベースに記録された事故時連絡情報を出力する出力手段と、を備えることを特徴とする。
【０００８】
本発明によれば、顧客に対して、確認連絡時期情報により特定される時期に確認連絡を行う。顧客に何事もない場合は、この確認連絡に対する応答があることで、金融機関では顧客に事故は起きていないと判断できる。この場合、指定された連絡先へ連絡は行われないので、金融機関との間の上記所定の契約が顧客本人以外に知られることはない。一方、顧客に事故があって、確認連絡に対して応答できない状況になった場合には、顧客からの応答がないことをもって、顧客に事故があったと判断できる。その場合、事故時連絡情報で指定される連絡先へ連絡が行われることで、その連絡先（例えば顧客本人の家族や近親者等）に上記所定の契約が知らされる。
【０００９】
本発明において、前記金融機関は銀行または信用金庫であり、前記所定の契約は、預金口座についての契約であることとしてもよい。この場合、従来からの通信禁止口座と同様に、預金者に何事もない間は本人以外に口座の存在を知られることがない一方、本人に事故が起きた場合には家族等の連絡先に口座の存在を知らせることができる。このため、預金者にとっては、家族等に口座の預金を相続させることができ、また、銀行や信用金庫にとっても、預金者に連絡がとれないまま放置される口座を削減して口座管理負担を軽減できるというメリットがある。
【００１０】
また、前記金融機関は保険会社であり、前記所定の契約は保険加入契約であることとしてもよい。この場合、例えば、保険に加入したことを家族には知られたくないが、自分が死亡等した場合には家族に保険金が支払われるようにしたいという保険加入者のニーズを満足することができる。
【００１１】
また、本発明において、前記所定の通信手段は電子メールであり、前記確認通信先情報は電子メールアドレスであることとしてもよい。
【００１２】
この場合、前記事故判定手段は、前記確認連絡としての電子メールに対する返信メールが受信された場合に、前記確認連絡に対する応答があったと判別することとしてもよい。
【００１３】
あるいは、前記確認連絡としての電子メールには前記各顧客に固有のＷｅｂページへの接続先情報を含めておき、前記事故判定手段は、前記Ｗｅｂページへのアクセスがあった場合に、前記確認連絡に対する応答があったと判別することとしてもよい。
【００１４】
また、本発明において、前記データベースには、前記各顧客について、前記確認連絡に対する応答の有無に基づいて当該顧客に事故があったかどうかを判定するための判定基準が記録されており、前記事故判定手段は、当該判定基準に従って当該顧客に事故があったかどうかを判定することとしてもよい。
【００１５】
また、本発明において、顧客の端末から前記データベースに記録された情報の変更要求を受信する手段と、前記受信した変更要求に応じて、当該顧客について前記データベースに記録された情報を変更する手段とを備えることとしてもよい。
【００１６】
また、本発明において、顧客の端末から期間を指定したサービス休止要求を受信する手段を備え、該サービス休止要求を受信した場合に、当該顧客について前記指定された期間中、前記事故判定手段による判定処理を中止することとしてもよい。
【００１７】
本発明によれば、顧客が例えば長期出張等の長期不在により確認連絡への応答を行えない場合に、サービス休止要求を行っておくことで、不在中に連絡が行われてしまうのを防止できる。また、サービス休止期間を指定するようにしているので、サービスを休止したまま顧客本人に事故が起きて、そのまま連絡が行えなくなってしまうことを防止できる。
【００１８】
【発明の実施の形態】
以下、本発明の一実施形態について説明する。本実施形態では、ある銀行（あるいは信用金庫）Ａにおいて、通常時は預金者である顧客本人以外への連絡は行わないが、顧客に死亡等の事故があったと判断される場合（具体的には、顧客宛に送信した確認メールに対する返信がない場合）に、予め顧客が指定した連絡先へ連絡を行うというサービスが行われる。以下の説明では、このサービスを「事故時連絡サービス」と称し、また、事故時連絡サービスの対象となる口座を、「サービス対象口座」と称する。
【００１９】
図１は、本実施形態のネットワーク全体構成図である。同図に示すように、本実施形態において、銀行Ａが管理するサーバー１０が設けられている。サーバー１０はインターネット１２に接続されており、各顧客のメールアドレス宛に電子メールを送信するメールサーバー部１０ａ、インターネット１２を介してアクセスしてきた顧客端末１４との情報のやりとりを行うＷＥＢサーバー部１０ｂ、および、以下に述べる各種情報処理を行う処理サーバー部１０ｃとを有している。なお、これら各サーバー部１０ａ〜１０ｃは別個のコンピュータで構成されてもよいし、あるいは、サーバー１０全体が１個のコンピュータで構成されていてもよい。また、顧客端末１４は、適宜なプロバイダを介してインターネット１２に接続されたパーソナルコンピュータであってもよいし、あるいは、移動体通信網１６に設けられたゲートウエイサーバー１８を介してインターネット１２に接続された携帯電話機やＰＤＡ等の携帯端末であってもよい。
【００２０】
サーバー１０には、確認情報データベース２０が設けられている。確認情報データベース２０には、各サービス対象口座について、確認メールに係わる各種情報（以下、確認情報という）が記録されている。具体的には、図２に示すように、サービス対象口座毎に、確認情報として、口座情報（店番、口座科目、口座番号）、口座名義人氏名、確認メール送信先アドレス、確認メール送信時期、返信待機日数、事故判定基準、事故時対応処理、および、確認番号が記録されている。
【００２１】
確認メール送信時期は、確認メールの送信時期を特定するための情報であり、例えば、月単位のメール送信間隔と、メール送信日とで表される。例えば、メール送信間隔が「３ヶ月」、メール送信日が「１０日」であれば、３月１０日、６月１０日、９月１０日、・・・等のように確認メールが送信されることになる。ただし、確認メール送信時期の内容はこれに限らず、要するに、確認メールを送信すべきタイミングが特定できるものであればよい。
【００２２】
返信待機日数は、確認メールに対する返信を待機する日数である。確認メールの送信日からこの日数が経過しても返信がない場合に、確認メールへの返信無しと判断する。
【００２３】
事故判定基準は、確認メールへの返信の有無に基づいて顧客に事故があったかどうか判定するための基準である。例えば、▲１▼確認メールへの返信無しの場合に直ちに事故があったと判定する、▲２▼確認メールへの返信無しの場合に、更に、所定の間隔で所定回数だけ確認メールを送信し、それでも返信が無ければ事故があったと判定する、等のように設定される。また、後述するように、確認メールへの返信メールには確認番号の記載が必要とされるが、確認番号が記載されておらず、あるいは、誤った確認番号が記載されている返信メールが届いた場合の判断基準を別個に定めるようにしてもよい。例えば、再度確認メールを送信しても正しい確認番号が記載された返信メールが届かなかった場合に、事故があったと判定する等とする。
【００２４】
事故時対応処理は、顧客に事故があったと判定された場合の連絡方法等を表す。具体的には、連絡方法（郵便、電話、ＦＡＸ、電子メール等）、連絡先（住所、電話番号、ＦＡＸ番号、メールアドレス等）、連絡内容（連絡の文面）が指定される。なお、連絡内容としては、例えば、「（顧客名）様がお持ちの預金口座の内容をお知らせします・・・」、「（顧客名）様の所在がわからなくなりましたのでご連絡します・・・」、「（顧客名）様とご連絡をとれなくなりましたが何かございましたでしょうか・・・」等、複数の定型文から顧客が選べるようにしてもよいし、顧客が自由に連絡文を設定できるようにしてもよい。
【００２５】
確認番号は、本人確認のためのパスワードとしての機能を持つものであり、返信メールに正しい確認番号が記載されている場合に、顧客本人からの返信メールであると判断する。これにより、顧客本人以外の者が本人になりすまして返信メールを送信するのを防止できる。
【００２６】
確認情報データベース２０に登録された上記の確認情報は、顧客が銀行Ａにおいてサービス対象口座の開設手続をする際に指定する。また、口座開設後も、顧客端末１４からサーバー１０のＷｅｂサーバー部１０ｂへアクセスして、確認情報の変更を行うことができる。さらに、サービス対象口座を開設した顧客は、Ｗｅｂサーバー部１０ｂへアクセスして、事故時連絡サービスを一時中止することもできる。
【００２７】
すなわち、Ｗｅｂサーバー部１０ｂは、顧客端末１４からのアクセスがあると、顧客番号やパスワードによるユーザ認証のうえ、上記確認情報の設定・変更や、事故時連絡サービスの休止の申込および休止期間の入力を行うための画面を当該顧客端末１４へ送信する。そして、この画面で入力された内容に基づいて、当該顧客について確認情報データベース２０に記録された確認情報を更新し、あるいは、該当する確認情報について事故時連絡サービスの休止期間を確認情報データベース２０に記録する。
【００２８】
なお、顧客の希望により事故時連絡サービスを休止できるようにしているのは、例えば、出張等の長期不在により確認メールへの返信が行えないような場合に、事故時連絡サービスを休止して、確認メールへの返信が無くても事故が起きたと判断されないようにする必要があるからである。ただし、無期限に事故時連絡サービスを休止できるものとすると、このサービスを休止したまま顧客が死亡等した場合には、永久に連絡を取れなくなってしまう。そこで、事故時連絡サービスの休止は必ず期限付きで行うものとしている。
【００２９】
次に、本実施形態においてサーバー１０が実行する処理について説明する。
図３は、確認メールを送信すべくサーバー１０が実行する処理を表すフローチャートである。同図に示すように、先ず、確認情報データベース２０を参照して、事故時連絡サービスの休止期間中でなく、かつ、確認メールの送信時期が到来したサービス対象口座が抽出される（Ｓ１００）。そして、抽出された各サービス対象口座について、確認メール送信先アドレス宛に、確認メールが送信される（Ｓ１０２）。その際、確認メールの文面に、銀行Ａが提供する各種キャンペーン等のお知らせ文を含めるようにしてもよいし、あるいは、本人以外の者が万一確認メールを見てしまった場合にも何のメールか見当がつかないように、余計な文面が一切含まれないメールとしてもよい。また、これらのうち何れの確認メールにするかを顧客が選択できるようにしてもよい。
【００３０】
確認メールが送信されたサービス対象口座については、以後、返信メールの有無の監視対象とする必要がある。そこで、確認メールが送信されたサービス対象口座が、確認メールの送信日と共に返信監視対象リストに加えられる（Ｓ１０４）。
【００３１】
図４は、返信監視対象リストに含まれる各サービス対象口座について、返信メールの有無を判定すべくサーバー１０が実行する処理のフローチャートである。同図に示すように、返信監視対象リストに含まれる各サービス対象口座について、確認情報データベース２０を参照して、返信待機日数、事故判定基準、および、確認番号が取得される（Ｓ１１０）。次に、確認メールの送信日から返信待機日数内に、正しい確認番号が記載された返信メールが届いたかどうかの判定が行われる（Ｓ１１２）。そして、その判定結果に基づき、事故判定基準に従って、顧客に事故が起きたかどうかが判定される（Ｓ１１４）。例えば、返信がない場合に直ちに事故があったと判定する基準であれば、その通り、直ちに顧客に事故があったと判定される。また、確認メールを所定回数再送信して返信がなければ事故があったと判定するという基準であれば、事故判定基準で指定された回数だけ確認メールを送信する処理が行われ、それでも返信がなければ、顧客に事故があったと判定される。
【００３２】
上記の事故判定の結果、顧客に事故は起きていないと判定されたサービス対象口座は返信判定リストから削除される（Ｓ１１６）。一方、顧客に事故が起きていると判定されたサービス対象口座については、確認情報データベース２０から事故時対応処理（すなわち、連絡方法、連絡先、連絡内容等）が読み出され、その内容が口座情報や口座名義人氏名等と共に一覧リストとして出力される（Ｓ１１８）。銀行Ａの担当者は、この一覧リストを見て、事故時対応で指定された郵便や電話等の手段で、指定された連絡先への連絡を取る。なお、連絡手段として電子メールが指定されている場合には、人手によらずに自動的に電子メールでの連絡が行われるようにしてもよい。
【００３３】
以上説明したように、本実施形態によれば、サービス対象口座の名義人である顧客に死亡等の事故が起きていない場合は、顧客が確認メールへの返信を行うことで、従前の通信禁止口座と同様に、当該口座に関する連絡は一切行われず、家族等に口座の存在を知られることはない。一方、顧客に事故が起きた場合は、確認メールへの返信が途絶えることとなり、その場合には、予め指定された連絡先へ所定の連絡が行われる。このように、本実施形態のシステムによれば、通常時には、従前の通信禁止口座と同様に口座の存在を家族に知られないようにしつつ、本人に不慮の事故があった場合には、家族等に口座の存在を知らせることができる。このため、家族に預金口座の存在を隠したいが、万一のときには家族に相続してもらいたいという顧客のニーズを満足できる。また、銀行側にとっても、従前の通信禁止口座のように、顧客に連絡がとれなくなって口座を放置せざるを得ないということがなくなり、口座管理負担を軽減することが可能となる。
【００３４】
また、本実施形態では、顧客側から事故時連絡サービスを一時的に休止することができる。このため、顧客は長期不在により確認メールへの返信を行えない場合にサービスを休止しておくことで、指定した連絡先へ連絡が行われてしまうのを防止できる。また、このサービス休止は期間を限ってしか行えないようにしているので、サービス休止中に顧客に事故が起きた場合にも、銀行側では、サービス休止期間の経過後に確認メールに対する返信がないことで、顧客に事故があったことを知り、指定された連絡先へ連絡を行うことができる。
【００３５】
なお、上記実施形態では、確認メールに対して、確認番号を記載した返信メールの有無により、顧客に事故があったかどうかを判定するものとした。しかしながら、本発明はこれに限らず、次のようにして、確認メールへの応答の有無を検知し、その応答の有無に基づいて事故の判定を行うこととしてもよい。すなわち、各サービス対象口座に固有の確認番号入力用Ｗｅｂページ（以下、確認番号入力ページという）をＷｅｂサーバー部１０ｂに用意しておく。確認メールには確認番号入力ページのＵＲＬを含めておき、顧客が確認メールに含められたＵＲＬを選択することによりこの確認番号入力ページにアクセスして確認番号を入力できるようにする。そして、入力された確認番号が、確認情報データベース２０に記録された確認番号と合致する場合に、確認メールに対する応答があったものとし、この応答の有無に基づいて、顧客に事故が起きたかどうかの判定を行うのである。
【００３６】
また、上記実施形態では、本発明が、銀行における事故時連絡サービスとして適用された場合について説明したが、これに限らず、例えば生命保険会社や損害保険会社等の保険会社において、保険契約者への連絡を行う場合にも適用が可能である。例えば、生命保険に加入したことを家族に知らせたくはないが、自分が死亡した場合には家族が確実に保険金を受け取れるようにしたいという保険加入者側のニーズが存在する。このようなニーズを持つ保険契約者に対して、上記実施形態と同様に、定期的に確認メールを送信し、確認メールへの応答がなかった場合に、指定された連絡先（例えば保険受取人である家族や近親者）に連絡を行うようにする。これにより、被保険者本人に何事もない間は保険契約に係わる連絡が行われないため、家族に保険加入を知られることはなく、一方、本人が万一死亡した場合には、家族に保険契約に係わる連絡が行われて、保険金請求の手続を確実にとることができるようになる。
【００３７】
【発明の効果】
本発明によれば、金融機関との契約者本人以外に対する連絡は行わないようにしつつ、契約者本人に死亡等の事故があった場合には、指定された連絡先への連絡を行うことができる。
【図面の簡単な説明】
【図１】本発明の一実施形態であるシステムのネットワーク全体構成図である
【図２】確認情報データベースに記録された確認情報の内容を示す図である。
【図３】本実施形態において確認メールを送信すべくサーバーが実行する処理を表すフローチャートである。
【図４】本実施形態において、確認メールに対する返信メールの有無を判定すべくサーバーが実行する処理のフローチャートである
【符号の説明】
１０　サーバー
１０ａ　メールサーバー部
１０ｂ　ＷＥＢサーバー部
１０ｃ　処理サーバー部
１２　インターネット
１４　顧客端末
２０　確認情報データベース

Claims (12)

1. 金融機関との間で所定の契約を結んだ顧客に対して連絡を行うのに用いられるシステムであって、
   前記所定の契約を結んだ各顧客について、確認連絡の通信先を特定するための確認通信先情報、確認連絡を行う時期を特定するための確認連絡時期情報、および、顧客に事故が起きたときの連絡先を含む事故時連絡情報が少なくとも記録されたデータベースと、
   前記各顧客に対して、前記データベースに記録された確認連絡時期情報により特定される時期に、前記データベースに記録された確認通信先情報により特定される通信先へ、所定の通信手段にて確認連絡を行う確認通信手段と、
   前記確認連絡に対する応答の有無に基づいて、顧客に事故があったかどうかを判定する事故判定手段と、
   顧客に事故があったと判定された場合に、当該顧客について前記データベースに記録された事故時連絡情報を出力する出力手段と、を備えることを特徴とするシステム。
2. 前記金融機関は銀行または信用金庫であり、前記所定の契約は、預金口座についての契約である請求項１記載のシステム。
3. 前記金融機関は保険会社であり、前記所定の契約は保険加入契約である請求項１記載のシステム。
4. 前記所定の通信手段は電子メールであり、前記確認通信先情報は電子メールアドレスである請求項１〜３のうち何れか１項記載のシステム。
5. 前記事故判定手段は、前記確認連絡としての電子メールに対する返信メールが受信された場合に、前記確認連絡に対する応答があったと判別する請求項４記載のシステム。
6. 前記確認連絡としての電子メールには前記各顧客に固有のＷｅｂページへの接続先情報を含めておき、前記事故判定手段は、前記Ｗｅｂページへのアクセスがあった場合に、前記確認連絡に対する応答があったと判別する請求項４記載のシステム。
7. 前記データベースには、前記各顧客について、前記確認連絡に対する応答の有無に基づいて当該顧客に事故があったかどうかを判定するための判定基準が記録されており、前記事故判定手段は、当該判定基準に従って当該顧客に事故があったかどうかを判定する請求項１〜６のうち何れか１項記載のシステム。
8. 顧客の端末から前記データベースに記録された情報の変更要求を受信する手段と、
   前記受信した変更要求に応じて、当該顧客について前記データベースに記録された情報を変更する手段とを備える請求項１〜７のうち何れか１項記載のシステム。
9. 顧客の端末から期間を指定したサービス休止要求を受信する手段を備え、該サービス休止要求を受信した場合に、当該顧客について前記指定された期間中、前記事故判定手段による判定処理を中止する請求項１〜８のうち何れか１項記載のシステム。
10. 金融機関との間で所定の契約を結んだ顧客に対して連絡を行うために行われる方法であって、コンピュータが、
    前記所定の契約を結んだ各顧客について、確認連絡の通信先を特定するための確認通信先情報、確認連絡を行う時期を特定するための確認連絡時期情報、および、顧客に事故が起きたときの連絡先を含む事故時連絡情報が少なくとも記録されたデータベースを参照するステップと、
    前記各顧客に対して、前記データベースに記録された確認連絡時期情報により特定される時期に、前記データベースに記録された確認通信先情報により特定される通信先へ、所定の通信手段にて確認連絡を行うステップと、
    前記確認連絡に対する応答の有無に基づいて、顧客に事故があったかどうかを判定するステップと、
    顧客に事故があったと判定された場合に、当該顧客について前記データベースに記録された事故時連絡情報を出力するステップと、を実行することを特徴とする方法。
11. 請求項１０記載の方法をコンピュータに実行させるためのプログラム。
12. 請求項１１記載のプログラムを記録した記録媒体。

Images