JP7494651B2 - 顧客情報管理サーバ、顧客情報管理方法、及びプログラム - Google Patents

Description

本発明は、顧客情報管理サーバ、顧客情報管理方法、及びプログラムに関する。

インターネット上では、インターネットバンキング、インターネット証券、クレジットカードの利用明細等の提供、インターネットショッピングなど様々なサービスが提供されている。こうしたサービスを利用する顧客は、各々のサービスを提供する事業者に対して、自らの氏名や住所等の顧客情報を登録しなければならない。顧客情報は、各々のサービスを提供する事業者のデータベースに格納され、管理されるのが原則であるためである。

このように、顧客情報が各々のサービスを提供する事業者毎に管理されている場合、多くのサービスを利用する顧客は、各々の事業者毎に顧客情報を登録しなければならない。このため、その手続きが非常に煩雑となる。特に、転居等によって住所が変わった際には、顧客情報として登録されている住所の変更を各々の事業者に対して届け出なければならない。このような顧客情報の登録や変更の手続きで発生する顧客の負担を軽減するために、複数の事業者に登録されている顧客情報の変更の届出等を一括して受け付け、受け付けた情報を各々の事業者に提供する技術が開示されている（例えば、特許文献１－３参照）。

特開２００２－２１５８４４号公報 特開２００２－３６６８７２号公報 特開２００４－１３４２８号公報

事業者への情報の登録や更新を代行するサービスとして、例えば、顧客の携帯電話の電話番号を利用する態様が考えられる。携帯電話を契約する際に、携帯キャリアでは、厳格な本人確認を条件に、携帯電話を利用する契約を締結していることから、携帯キャリアを介して顧客の携帯電話の有効性を確認することにより顧客の本人確認の確実性が担保されることが期待できる。しかしながら、電話番号は、解約される場合があり得る。したがって、顧客の携帯電話の電話番号が有効なものであるかを定期的に管理し、メンテナンスする仕組みが求められている。

本発明は、このような状況に鑑みてなされたもので、顧客の携帯電話の電話番号が有効なものであるかを定期的に管理することができる顧客情報管理サーバ、顧客情報管理方法、及びプログラムを提供することを目的とする。

本発明の上述した課題を解決するために、本発明は、顧客端末から通知された情報に基づいて、顧客の個人情報である顧客情報を管理する顧客情報管理サーバであって、前記顧客情報と、前記顧客情報から削除する候補となる顧客の個人情報である削除候補ＤＢを記憶する記憶部と、携帯キャリアが提供するアプリケーションを利用する顧客であって、当該アプリケーションにおいて提供される前記顧客情報を管理するサービスに登録された顧客の電話番号を示す電話番号リストを取得する電話番号リスト取得部と、前記電話番号リストを用いて、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在するか否かを判定し、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在しないと判定した場合、当該存在しないと判定した顧客の前記顧客情報のうちの少なくとも電話番号を削除候補ＤＢに記憶させる顧客情報メンテナンス部と、を備える顧客情報管理サーバである。

また、本発明は、上述の顧客情報管理サーバにおいて、前記顧客情報メンテナンス部は、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在しないと判定した場合、当該存在しないと判定した顧客の前記顧客情報を削除するようにしてもよい。

また、本発明は、上述の顧客情報管理サーバにおいて、前記電話番号リスト取得部は、定期的に前記電話番号リストを取得し、前記顧客情報メンテナンス部は、今回取得した電話番号リストに存在し、かつ前記削除候補ＤＢに登録されている復活電話番号が存在するか否かを判定し、前記復活電話番号が存在する場合には、前記削除候補ＤＢに登録されている前記復活電話番号を前記削除候補ＤＢから削除する。

また、本発明は、上述の顧客情報管理サーバにおいて、前記電話番号リスト取得部は、定期的に前記電話番号リストを取得し、前記顧客情報メンテナンス部は、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在するか否かを判定し、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在しないと判定した場合、当該存在しないと判定した顧客の前記顧客情報を削除候補ＤＢに記憶させ、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在しないと判定した場合、当該存在しないと判定した顧客の前記顧客情報を削除し、前記顧客情報を削除候補ＤＢに記憶させた時点よりも後に取得した電話番号リストに基づいて、当該電話番号リストに存在し、かつ前記顧客情報に登録されていない復活候補電話番号が存在するか否かを判定し、前記復活候補電話番号が前記削除候補ＤＢに登録されている場合には、前記削除候補ＤＢに記憶させた前記顧客情報を復活させ、前記復活させた前記顧客情報を前記削除候補ＤＢから削除する。

また、本発明は、顧客端末から通知された情報に基づいて、顧客の個人情報である顧客情報を管理する顧客情報管理サーバであって、前記顧客情報と、前記顧客情報から削除する候補となる顧客の個人情報である削除候補ＤＢを記憶する記憶部顧客情報管理サーバの顧客情報管理方法であって、電話番号リスト取得部が、携帯キャリアが提供するアプリケーションを利用する顧客であって、当該アプリケーションにおいて提供される前記顧客情報を管理するサービスに登録された顧客の電話番号を示す電話番号リストを取得し、顧客情報メンテナンス部が、前記電話番号リストを用いて、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在するか否かを判定し、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在しないと判定した場合、当該存在しないと判定した顧客の前記顧客情報のうちの少なくとも電話番号を削除候補ＤＢに記憶させる、顧客情報管理方法である。

また、本発明は、コンピュータを、上記に記載の顧客情報管理サーバとして動作させるためのプログラムであって、前記コンピュータを前記顧客情報管理サーバが備える各部として機能させるためのプログラムである。

本発明によれば、顧客の携帯電話の電話番号が有効なものであるかを定期的に管理することができる。

第１の実施形態に係る顧客情報管理サーバ１０が適用される管理システム１の構成の例を示す概略図である。 第１の実施形態に係る顧客情報管理サーバ１０の構成の例を示すブロック図である。 第１の実施形態に係る管理システムにおける処理を説明する図である。 第１の実施形態に係る顧客情報管理サーバ１０が行う処理の流れを示すフローチャートである。 第１の実施形態に係る顧客情報管理サーバ１０が行う処理の流れを示すフローチャートである。 第２の実施形態に係る顧客情報管理サーバ１００が適用される管理システム１の構成の例を示す概略図である。 第２の実施形態に係る顧客情報１３１の構成の例を示す図である。 第２の実施形態に係る登録ＤＢ１３２の構成の例を示す図である。 第２の実施形態に係る削除候補ＤＢ１３３の構成の例を示す図である。 第２の実施形態に係る顧客情報管理サーバ１００が行う処理の流れを示すフローチャートである。

以下、発明の実施形態について図面を参照しながら説明する。

図１は、第１の実施形態に係る顧客情報管理サーバ１０が適用される管理システム１の概要を示している。図１に示すように、顧客情報管理サーバ１０は、スマートフォン等の顧客端末２０からインターネットなどの通信ネットワークＮＷを介してアクセス可能に接続される。また、顧客情報管理サーバ１０は、及び利用機関システム５０（この例では、Ａ銀行システム、Ｂ銀行システムＣ証券システム、及びＤ生命システム等）とアクセス可能に接続される。

銀行や証券会社等の利用機関システム５０の顧客が、顧客端末２０で携帯キャリア（携帯電話事業者）が提供するメッセージアプリ（対話型メッセンジャーが好適である。）等のアプリケーションプログラムによって、携帯キャリアサーバ３０に接続する。この場合に顧客端末２０に表示される当該アプリケーションプログラムのチャットルーム等の所定のページには、手続きが共通化された顧客情報の登録や更新を要求する際に選択されるメニューやリンクを示す情報が示される。顧客は、それらのメニュー等を選択し、登録や更新に必要な本人確認書類や口座情報等のデータを送信する操作を行う。すると、顧客情報管理サーバ１０に、顧客端末２０から送信されたデータが通知される。顧客情報管理サーバ１０は、顧客端末２０から通知されたデータに基づいて、例えば、統合ＡＴＭネットワーク（不図示）への照会等を行う。ここでの統合ＡＴＭネットワークとは、銀行間のＡＴＭ等を相互接続するネットワークである。このネットワークに照会することによって、預金口座の存在やその有効性を確認することが可能である。顧客情報管理サーバ１０は、統合ＡＴＭネットワークを利用することによって、本人確認や口座確認等の所定の確認処理を行う。

顧客情報管理サーバ１０は、これらの確認処理が終了すると、顧客情報管理サーバ１０において管理されている顧客情報が登録又は更新される。また、顧客情報管理サーバ１０は、顧客本人の同意を得た上で、顧客が関係する利用機関システム５０に、その利用機関システム５０における口座などに紐づく顧客情報の登録又は更新に必要な情報を送信する。利用機関システム５０は、顧客情報管理サーバ１０から受信した情報に基づく承認等を経て、利用機関システム５０における顧客情報の登録又は更新の処理を行い、処理が完了すると、顧客端末２０に顧客情報の登録又は更新の処理が完了したことを通知する。

このように、第１の実施形態では、携帯キャリアが提供するメッセージアプリ等のアプリケーションプログラムを用いて、顧客端末２０から顧客情報の登録や更新が要求される。すなわち、顧客が日常的に利用している携帯キャリアが提供するアプリケーションプログラムをインターフェースとして、顧客情報の登録や更新の要求が行われる。このため、顧客情報の登録や更新を行う際の顧客の操作性を向上させることができる。また、本実施形態では、携帯キャリアサーバ３０を経由することで、携帯キャリアによる認証を経て顧客情報の登録や更新の要求を受け付ける。携帯キャリアでは、厳格な本人確認を条件に、携帯電話を利用する契約を締結している。したがって、本実施形態の顧客情報管理サーバ１０による顧客情報の管理において、顧客の本人確認の確実性が担保される仕組みとなっている。なお、親が購入した携帯電話を子供が使用するケース等においては、携帯契約時のキャリアの本人確認のみでは本人確認の確実性は担保されない場合もあり得る。

図２は、第１の実施形態に係る顧客情報管理サーバ１０の構成の一例を示すブロック図である。図２に示すように、顧客情報管理サーバ１０は、顧客端末２０、及び携帯キャリアサーバ３０と、汎用或いは専用のネットワーク等を介して接続される。

顧客情報管理サーバ１０は、ＣＰＵ、メインメモリ、ＨＤＤ等の補助記憶装置を備え、インターネットを含む通信ネットワークＮＷとの接続機能を有するコンピュータが用いられる。顧客情報管理サーバ１０が備える各種の機能は、補助記憶装置に格納されたプログラムがメインメモリに読みだされ、ＣＰＵで演算処理が実行されることによって実現される。

顧客情報管理サーバ１０を構成するコンピュータの物理的な構成は、特に限定されるものではない。本実施形態における顧客情報の管理機能以外の機能が、同一のコンピュータに備えられるものであってもよいし、別個のコンピュータに備えられるものであってもよい。また、本実施形態に必要な種々の機能は、物理的に一台のコンピュータによって実現されるものであってもよいし、複数台のコンピュータを用いて実現されるものであってもよい。

顧客情報管理サーバ１０のワンタイムＵＲＬ生成部１１、顧客情報処理部１３、本人確認部１４、口座確認部１５、顧客情報提供部１７、及び通知送信部１８などの各機能部は、機能として限定されるものである。顧客情報管理サーバ１０の各機能部は、例えば、ＣＰＵが演算処理のプログラム（ソフトウェア）を実行することによって実現されるが、これに限定されることはなく、ＬＳＩなどのハードウェアによって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。

顧客情報管理サーバ１０のワンタイムＵＲＬ記憶部１２、顧客情報格納部１６には、ＨＤＤ等の補助記憶装置の所定の記憶領域が割り当てられる。これらの記憶領域は、物理的に一台のコンピュータに設けられることを要件とするものではなく、データベースサーバを構成するコンピュータ等の複数のコンピュータに設けられるものであってもよい。

顧客端末２０には、電話番号が割り当てられたスマートフォン等の携帯端末が用いられる。顧客端末２０では、携帯キャリアによって提供されるアプリケーションプログラムの利用が可能である。アプリケーションプログラムには、発信者の電話番号を認証して、顧客端末２０と交信する機能が備えられている。携帯キャリアサーバ３０の契約者情報格納部３１には、携帯キャリアサーバ３０に対応するコンピュータのＨＤＤ等の補助記憶装置の所定の記憶領域が割り当てられる。

利用機関システム５０－５２等では、例えば、銀行が運用する預金口座を管理するホストコンピュータを用いることができる。以下では、顧客情報管理サーバ１０との情報の送受信が、利用機関システム５０のような基幹系のコンピュータシステムと直接通信を行う場合を例に説明する。しかしながら、これに限定されることはない。顧客情報管理サーバ１０は、このような基幹系のコンピュータシステムと通信が可能なＰＣ等のネットワーク端末やＷｅｂサーバ等を介して、情報の送受信を行うものであってもよい。

以上の構成を前提にして、図３－図５を用いて、第１の実施形態における顧客情報管理サーバ１０による顧客情報の管理方法について説明する。

図３は、第１の実施形態において顧客情報の登録又は更新が行われる場合における、顧客情報管理サーバ１０と、周辺の外部機器（顧客端末２０、携帯キャリアサーバ３０、及び利用機関システム５０）との関係、及び顧客情報管理サーバ１０の内部におけるデータの流れの概要を示したものである。

図３に示すように、例えば、顧客は、顧客端末２０を用いて携帯キャリアが提供しているメッセージアプリを起動する操作を行う。顧客は、顧客情報管理サーバ１０によって提供されるサービスを利用して、自身と取引がある複数の事業者（ここでは、Ａ銀行、Ｂ銀行、Ｃ証券、Ｄ生命等）から要求される顧客情報（顧客本人の個人情報）の登録や更新を一括して行うために、メッセージアプリを起動する操作を行う。この場合において、顧客は、自らが契約者となって電話番号を割り当てられているスマートフォン等の顧客端末２０を用いて操作を行う。

このメッセージアプリは、発信者の電話番号によって認証される携帯キャリアが提供するアプリケーションプログラムであって、顧客端末２０にインストールされたものである。顧客端末２０でメッセージアプリが起動されると、携帯キャリアサーバ３０にアプリケーションプログラムの起動要求が送信される。携帯キャリアサーバ３０は、起動要求を受信すると、電話番号の認証を行う。ここでの、電話番号の認証では、発信者の電話番号（顧客端末２０に挿入されているＳＩＭカードから読み取られた電話番号）を、携帯電話契約者のデータベースである契約者情報格納部３１に格納されている有効な電話番号と照合する処理が行われる。携帯キャリアサーバ３０は、発信者の電話番号が、契約者情報格納部３１に格納されている有効な電話番号である場合には、契約者からの正当な起動要求を受信したと判定する。携帯キャリアサーバ３０は、契約者からの正当な起動要求を受信した場合、顧客端末２０によるメッセージアプリの起動を許可する。

顧客端末２０のメッセージアプリの操作画面には、図３に例示したように、「口座情報登録」や「住所変更」等を含むメニューの一覧が表示される。これらのメニューは、顧客情報管理サーバ１０によって提供されるサービスである。これらのメニューのうち、「口座情報登録」又は「住所変更」のいずれかが選択されると、携帯キャリアサーバ３０は、先に認証した顧客端末２０の電話番号とあわせて、「口座情報登録」や「住所変更」等のメニューが選択されたことを、顧客情報管理サーバ１０に通知する。

尚、ここで、携帯キャリアサーバ３０から顧客情報管理サーバ１０に、顧客の電話番号が通知される場合を例に説明したが、これに限定されない。携帯キャリアサーバ３０から顧客情報管理サーバ１０に通知される情報は、少なくとも、顧客端末２０を操作する顧客を識別することが可能な情報であればよい。例えば、顧客の電話番号に代えて、その電話番号と一意に関連付けられた顧客ＩＤ等の識別キーが、携帯キャリアサーバ３０から顧客情報管理サーバ１０に通知されるようにしてもよい。或いは、携帯キャリアサーバ３０から顧客情報管理サーバ１０に、顧客の電話番号が通知され、顧客情報管理サーバ１０は、その電話番号と一意に関連付けられた顧客ＩＤ等の識別キーを対応づけ、その識別キーを用いて、顧客情報の管理を行うようにしてもよい。セキュリティ面を考慮すると、電話番号そのものを用いずに電話番号と一意に関連付けられた顧客ＩＤ等の識別キーを用いることが好ましいとも考えられる。

図４のフローチャートは、第１の実施形態に係る顧客情報管理サーバ１０が行う顧客情報の登録又は更新に係る処理の流れを示す。図４に示すように、顧客情報管理サーバ１０は、携帯キャリアサーバ３０から、顧客の電話番号（又は、電話番号と一意に関連付けられた顧客ＩＤ等の識別キー）を受信する（ステップＳ０１）。顧客情報管理サーバ１０は、顧客端末２０においてメッセージアプリのメニューにおける「口座情報登録」や「住所変更」等が選択された旨の情報と共に、顧客の電話番号等を受信する。次に、顧客情報管理サーバ１０において、ワンタイムＵＲＬ生成部１１が起動され、ワンタイムＵＲＬが生成される（ステップＳ０２）。ワンタイムＵＲＬは、当該顧客が自身の顧客情報の登録や更新の際にアクセスするページに割り当てられる、ユニークなネットワークアドレスである。

ワンタイムＵＲＬ生成部１１で生成されたワンタイムＵＲＬは、携帯キャリアサーバ３０から受信した顧客の電話番号（又は、電話番号と一意に関連付けられた顧客ＩＤ等の識別キー）に紐づけて、ワンタイムＵＲＬ記憶部１２に一時記憶される（ステップＳ０３）。また、顧客情報管理サーバ１０は、ワンタイムＵＲＬ生成部１１で生成されたワンタイムＵＲＬを、携帯キャリアサーバ３０に送信する（ステップＳ０４）。

携帯キャリアサーバ３０は、顧客情報管理サーバ１０からワンタイムＵＲＬを受信すると、受信したワンタイムＵＲＬが埋め込まれたリンクが設定された、登録／更新ボタンを生成する（図３参照）。登録／更新ボタンは、顧客端末２０で起動されているメッセージアプリに表示させる操作画面のファイルに設けられる操作ボタンである。携帯キャリアサーバ３０は、操作ボタンが設けられた操作画面のファイルを、顧客端末２０に送信する。顧客端末２０は、操作画面のファイルを受信し、受信したファイルを画面に表示させる。これにより、顧客端末２０の画面には、ワンタイムＵＲＬへのリンクが設定された、顧客情報の登録や更新を要求するためのボタンが表示される。尚、ここでメッセージアプリに表示させる操作画面に、ワンタイムＵＲＬへのリンクを設定する方法は、画面に操作ボタンを表示して顧客に押下操作させる方法に限定されるものではない。テキストにハイパーリンクを設定するなど、操作ボタン以外の表示形式によるものであってもよい。

顧客は、顧客端末２０に表示された画面を視認し、必要に応じた操作を行う。例えば、顧客は、顧客情報管理サーバ１０により提供されるサービスを利用して、複数の利用期間で共用される顧客自身の顧客情報の登録や更新を行う場合を考える。この場合、顧客によって、本人確認等のために必要な本人確認書類等のデータ（図３の「本人確認データ」）や、登録又は更新する顧客自身の情報（図３の「登録／更新データ」）を入力する操作が行われる。データが入力されると、操作画面に表示されている顧客情報の登録や更新を要求する操作ボタンが押下される。

顧客によって操作ボタンが押下されると、顧客端末２０は、本人確認データ、登録／更新データを含む顧客情報の登録又は更新要求を、顧客情報管理サーバ１０に送信する。操作ボタンには、ワンタイムＵＲＬへのリンクが設定されている。このため、アドレスにワンタイムＵＲＬが指定されたリクエストが、顧客情報管理サーバ１０に送信される。なお、メッセージアプリのメニューにおける「口座情報登録」や「住所変更」等の操作ボタンが選択された後に表示される画面に表示される画像等には、ワンタイムＵＲＬへのリンクは設定されない。

顧客情報管理サーバ１０は、アドレスにワンタイムＵＲＬが指定されたリクエストを受信する。顧客情報管理サーバ１０は、このリクエストを受信すると、顧客情報処理部１３を起動させ、図５のフローチャートに示す処理が実行される。図５のフローチャートは、第１の実施形態に係る顧客情報管理サーバ１０が行う顧客情報の登録又は更新に係る処理の流れを示す。顧客情報管理サーバ１０は、更新要求、及び当該更新要求に伴うデータを受信する（ステップＳ１１）。ここでの更新要求は、ワンタイムＵＲＬがアドレスに指定された顧客情報の登録又は更新を要求する旨の通知である。ここでの更新要求に伴うデータは、本人確認データ及び登録／更新データである。顧客情報管理サーバ１０は、ワンタイムＵＲＬ記憶部１２に一時記憶されている情報を確認して、リクエストに指定されたワンタイムＵＲＬと関連付けて記憶されている顧客の電話番号（又は、電話番号と一意に関連付けられた顧客ＩＤ等の識別キー）を特定する（ステップＳ１２）。

本人確認部１４は、顧客端末２０から受信した本人確認データ等から、顧客の本人確認を行い（ステップＳ１３）、なりすましに該当しないかの確認（ステップＳ１４）を行う。口座確認部１５は、必要な場合には預金口座の存在と有効性の確認を行う（ステップＳ１５）。これらの確認によって登録又は更新に係る所定の要件を満たしていることが確認されると（ステップＳ１３－Ｓ１５がいずれもＹｅｓ）、顧客情報処理部１３は、顧客情報格納部１６に格納されている顧客情報のうち、ステップＳ１２で特定された電話番号（又は、電話番号と一意に関連付けられた顧客ＩＤ等の識別キー）により識別される顧客の顧客情報を、顧客端末２０から受信した顧客情報の登録又は更新要求に含まれる登録／更新データに基づいて更新する（ステップＳ１６）。

顧客情報管理サーバ１０は、顧客情報提供部１７を起動する。顧客情報提供部１７は、顧客情報が登録又は更新された顧客との取引があり、登録又は更新された顧客情報を必要とする利用機関システム５０－５２等に対して、顧客本人の同意や指示を得た上で、登録又は更新された顧客情報を、本人確認書類の画像ファイル等のその他に必要な情報とあわせて送信する（ステップＳ１７）。その後、送信先の利用機関システム５０－５２等による承認まで待機して、承認が得られたことを確認すると、顧客情報管理サーバ１０は、通知送信部１８を起動する。通知送信部１８は、顧客端末２０に顧客情報が登録又は更新された通知を送信する。

尚、本人確認部１４における顧客の本人確認（ステップＳ１３）や、なりすまし等に該当しないかの確認（ステップＳ１４）、又は口座確認部１５における預金口座の存在と有効性の確認（ステップＳ１５）において、いずれかの要件が満たされないことが確認されると（ステップＳ１３－Ｓ１５のいずれかがＮｏ）、顧客情報の登録又は更新処理は受け付けられず、エラー処理が行われる（ステップＳ１８）。

（第２の実施形態）
次に、第２の実施形態について説明する。本実施形態の顧客情報管理サーバ１００では、顧客情報のメンテナンスを行う点において、上述した実施形態と相違する。以下の説明では、上述した実施形態の顧客情報管理サーバ１０と同様の構成については、同じ符号を付してその説明を省略する。また、顧客情報管理サーバ１０と、顧客情報管理サーバ１００とを特に区別しない場合には、顧客情報管理サーバ１０（１００）などと記載する。

上述したように、本実施形態において、顧客情報管理サーバ１０（１００）は、電話番号（又は、電話番号と一意に関連付けられた顧客ＩＤ等の識別キー）に基づいて、顧客情報の登録又は更新を行う。本実施形態の顧客情報管理サーバ１００は、顧客情報の登録又は更新に伴い、顧客情報１３１に顧客の属性情報を記憶（登録又は更新）させた場合、その顧客の電話番号を、登録ＤＢ１３２にも記憶させる。

しかしながら、電話番号は解約される場合がある。この場合、顧客情報管理サーバ１０の顧客情報に、顧客本人のものではない電話番号が登録され続けることとなる。さらに、電話番号が解約されると、解約された電話番号は、解約後に所定の期間が経過した後、他人のスマートフォン等の電話番号に割り当てられるのが一般的である。このため、顧客の電話番号が解約され、その解約された番号が他人に割り当てられてしまう場合があり得る。この場合、顧客情報管理サーバ１０の顧客情報に、ある顧客の電話番号（すでに解約済みだが更新手続きを怠っているもの）と、別の顧客の電話番号（新規に契約したもの）とが、同一の番号として登録されてしまう可能性がある。この場合、顧客情報管理サーバ１０が、利用機関システム５０－５２等に対して、ある顧客の顧客情報を、別の顧客の顧客情報として誤って送信してしまうような事態が発生する可能性がある。

この対策として、本実施形態では、顧客の電話番号が最新のものであるかを定期的に確認することによって、メンテナンスに係る処理を行う。

図６は、第２の実施形態の顧客情報管理サーバ１００が行うメンテナンスに係る処理を説明する図である。図６に示すように、顧客情報管理サーバ１００は、顧客端末２０から顧客情報を受信する。ここで受信する顧客情報は、メッセージアプリのメニュー等が顧客により操作されることによって、顧客情報の登録又は更新を要求する顧客の顧客端末２０から通知される情報である。

また、顧客情報管理サーバ１００は、顧客端末２０から受信した顧客情報を、顧客情報１３１として、記憶部１３０に記憶する。また、顧客情報管理サーバ１００は、顧客端末２０から受信した電話番号（又は識別キー）と共に、利用機関システム５０に対して、登録又は更新された顧客情報等を送信する。

顧客情報管理サーバ１００は、電話番号リスト取得部１１０によって、携帯キャリアサーバ３０に対して、定期的に（例えば、１日に１回）、電話番号リストを受信要求する。電話番号リストは、携帯キャリアに契約し、所定のメッセージアプリ上の「口座情報登録」等のサービス（以下、顧客情報管理サービスという）を利用している顧客の電話番号を示すリストである。ここでの所定のメッセージアプリとは、顧客情報管理サーバ１０が提供する顧客情報管理サービスに対応するメッセージアプリである。例えば、顧客端末２０は、所定のメッセージアプリにおいて、顧客情報管理サービスを提供する顧客情報管理サーバ１０のアカウントをフォローすることによって、当該顧客情報管理サービスを利用することが可能である。

そして、顧客情報管理サーバ１０は、顧客情報メンテナンス部１２０によって、電話番号リストを用いて顧客情報のメンテナンスに係る処理を行う。顧客情報メンテナンス部１２０が行うメンテナンスに係る処理については後で詳しく説明する。

顧客端末２０は、メッセージアプリ等を介して、携帯キャリアサーバ３０に電話番号を通知する。また、顧客端末２０は、メッセージアプリのメニュー等に表示される顧客情報の登録又は更新の操作ボタンが操作されることにより、顧客情報管理サーバ１００に顧客情報を通知する。携帯キャリアサーバ３０は、顧客情報管理サーバ１０からの要求に応じて、電話番号リストを顧客情報管理サーバ１００に送信する。

上述したように、電話番号リストは、携帯キャリアに契約し、所定のメッセージアプリを利用している顧客の電話番号を示すリストである。このため、顧客が携帯電話を解約した場合、その解約後に通知される電話番号リストには、解約された電話番号が存在していないことになる。本実施形態では、この性質を利用して、顧客情報のメンテナンスに係る処理を行う。例えば、顧客情報管理サーバ１００は、電話番号リストに存在しなくなった電話番号を顧客情報から削除することが考えられる。

しかしながら、携帯電話番号には、携帯電話番号ポータビリティ（Mobile Number Portability）という制度がある（以下、ＭＮＰという）。ＭＮＰでは携帯キャリアを変更しても携帯電話番号を変更する必要がない。

電話番号リストに存在しなくなった電話番号の中には、電話が解約されたことに起因するもの、所定のメッセージアプリ上の顧客情報管理サービスを利用しなくなった（フォローを解除した）ことに起因するもの、及びＭＮＰによる携帯キャリアの変更に起因するものがあると考えられる。このため、電話番号リストに存在しなくなった電話番号を、直ちに顧客情報から削除してしまうと、顧客情報管理サービスを利用しなくなった顧客や、ＭＮＰによる携帯キャリアの変更を行った顧客の電話番号が、電話番号が変更されていないにもかかわらず、削除されてしまうことになる。

この対策として、本実施形態では、顧客情報管理サーバ１００は、メンテナンスに係る処理を行う場合において、顧客情報１３１と、登録ＤＢ１３２と、削除候補ＤＢ１３３とを、記憶部１３０に記憶する。顧客情報１３１は、顧客本人の個人情報である。登録ＤＢ１３２は、顧客情報１３１に登録された顧客の電話番号を示す情報である。登録ＤＢ１３２は、顧客情報１３１をメンテナンスするために用いられる。削除候補ＤＢ１３３は、顧客情報１３１のうち、そこに登録された電話番号が何らかの理由により削除される可能性がある顧客に関する情報である。

このように、後に削除される可能性がある電話番号を削除候補ＤＢ１３３に登録しておくことにより、電話番号リストに存在しなくなった電話番号が、電話が解約されたことに起因するもの、所定のメッセージアプリ上の顧客情報管理サービスを利用しなくなった（フォローを解除した）ことに起因するもの、及びＭＮＰによる携帯キャリアの変更に起因するものかを見極めることが可能となる。例えば、削除候補ＤＢ１３３を定期的に監視し、削除日（電話番号リストに電話番号が存在しなくなった日）から一定期間（例えば、１週間、或いは１か月などの期間が考えられる）が経過した電話番号に対応する顧客情報１３１を削除するような処理を行うことができる。

図７は、第２の実施形態に係る顧客情報１３１の構成の例を示す図である。顧客情報１３１は、例えば、識別キーと、属性情報などの項目を備える。識別キーは、電話番号と一意に関連付けられた顧客を識別する識別情報である。属性情報は、顧客の属性を示す情報であって、顧客端末２０から通知される顧客情報や、携帯キャリアサーバ３０から通知される顧客の電話番号で構成される。属性情報は、例えば、氏名、住所、生年月日、電話番号、マイナンバー、免許証番号、口座番号等の項目を備える。

この例では、属性情報として、氏名がＴＦ太郎、住所が東京都千代田区、生年月日が１９９１年８月１４日、電話番号が０９０－１２３４－５６７８であること等が示されている。なお、この例では、属性情報としてマイナンバーの項目がある。このように、顧客情報管理サーバ１０は、顧客のマイナンバーを、顧客情報１３１に登録可能な構成を備えていてもよい。マイナンバーカードに銀行の口座情報を紐づける機運の高まりがあるためである。

すなわち、マイナンバーカードと銀行の口座情報を紐づける法案が整備されつつある。マイナンバーカードへの銀行の口座情報の紐づけが義務化された場合、利用機関システム５０（主に銀行）が保有する顧客情報には、マイナンバーが記憶される必要がある。この場合、例えば、顧客情報管理サーバ１００を介した顧客情報の登録がなされると、顧客情報管理サーバ１００は、登録／更新データとして顧客のマイナンバーの提供を要求し、顧客端末２０から受信したマイナンバーを、顧客情報として利用機関システム５０に通知する。

一方、マイナンバーカードへの銀行の口座情報の紐づけが義務化された場合であっても、銀行以外の第三者がマイナンバーを保有することは禁止される可能性がある。このような場合、顧客のマイナンバーを、顧客情報１３１に登録することはできない。この場合、顧客情報管理サーバ１００は、例えば、顧客端末２０から受信した個人情報に基づいてマイナンバーを利用機関システム５０に通知した後、当該顧客情報のうちマイナンバーを除いた情報を、顧客情報１３１に記憶させるようにする。

図８は、第２の実施形態に係る登録ＤＢ１３２の構成の例を示す図である。登録ＤＢ１３２は、例えば、識別キーと、電話番号と、追加日と、更新日などの項目を備える。識別キーは顧客情報１３１における識別キーと同様である。電話番号は、識別キーに対応付けられている電話番号である。追加日は、顧客の属性情報等が追加された日付である。更新日は、顧客の属性情報等が更新された日付である。追加日や更新日は、個々の属性情報ごとに設定されていてもよい。

図９は、第２の実施形態に係る削除候補ＤＢ１３３の構成の例を示す図である。削除候補ＤＢ１３３は、例えば、識別キーと、電話番号と、削除日などの項目を備える。識別キーは顧客情報１３１における識別キーと同様である。電話番号は、識別キーに対応付けられている電話番号である。削除日は、電話番号リストに存在しなくなった電話番号が顧客情報１３１から直ちに削除される場合には、識別キーに対応する顧客情報が顧客情報１３１から削除された日付である。或いは、電話番号リストに存在しなくなった電話番号を顧客情報１３１から直ちに削除することなく削除候補ＤＢ１３３に登録しておき、一定期間、当該電話番号を顧客情報１３１に保持する場合には、削除日は、識別キーに対応する顧客情報が電話番号リストに存在しなくなった日付である。

ここで、顧客情報管理サーバ１００が行うメンテナンスに係る処理について、図１０を用いて説明する。図１０は、第２の実施形態の顧客情報管理サーバ１００が行う顧客情報のメンテナンスに係る処理の流れを示すフローチャートである。

顧客情報管理サーバ１００は、携帯キャリアサーバ３０から電話番号リストを取得する（ステップＳ２０）。顧客情報管理サーバ１００は、取得した電話番号リストと、顧客情報管理サーバ１０で記憶している登録ＤＢ１３２とを比較する（ステップＳ２１）。

顧客情報管理サーバ１００は、比較した結果、電話番号が、電話番号リストに存在しており、かつ登録ＤＢ１３２にも存在する場合、その電話番号が有効なものであるとして登録ＤＢ１３２を更新する（ステップＳ２２）。ここでの更新とは、登録ＤＢ１３２に記憶されている情報が最新である旨が確認されたことを更新するものであり、例えば、登録ＤＢ１３２の更新日を更新するものである。すなわち、登録ＤＢ１３２の電話番号の内容に変更はない。

顧客情報管理サーバ１００は、比較した結果、電話番号が電話番号リストに存在しないが、登録ＤＢ１３２に存在する場合、その電話番号を登録ＤＢ１３２から削除する（ステップＳ２３）。また、顧客情報管理サーバ１００は、登録ＤＢ１３２から削除した電話番号を、削除候補ＤＢ１３３に追加する（ステップＳ２４）。

顧客情報管理サーバ１００は、比較した結果、電話番号が電話番号リストに存在しているが、登録ＤＢ１３２に存在していない場合、その電話番号が削除候補ＤＢ１３３に存在するか否かを判定する（ステップＳ２５）。

顧客情報管理サーバ１００は、電話番号が削除候補ＤＢ１３３に存在しない場合には、その電話番号を登録ＤＢ１３２に追加する（ステップＳ２６）。ここでの追加とは、登録ＤＢ１３２に新たに情報を追加するもの（新規登録）である。或いは、電話番号が過去に顧客情報１３１に登録された実績がある（その後に削除された）ものであれば、ここでの追加は、削除後の復活となる。一方、顧客情報管理サーバ１００は、電話番号が削除候補ＤＢ１３３に存在する場合には、その電話番号を削除候補ＤＢ１３３から削除する（ステップＳ２７）。そして、顧客情報管理サーバ１００は、削除候補ＤＢ１３３から削除した電話番号を、登録ＤＢ１３２に追加する（ステップＳ２８）。ここでの追加とは、ステップＳ２３で削除した情報を再び登録ＤＢ１３２に追加するもの（復活登録）である。

なお、上記では、顧客情報１３１と登録ＤＢ１３２とが別個のデータベースとして管理されている場合を例に説明した。しかしながらこれに限定されない。顧客情報１３１と登録ＤＢ１３２とが１つの統合データベースであってもよい。この場合、顧客情報１３１が、登録ＤＢ１３２を兼用する構成となる。この場合、削除候補ＤＢ１３３には、顧客情報１３１における顧客（削除候補者）の属性情報（住所や氏名等）と同じ項目が含まれる。また、顧客情報管理サーバ１０が、顧客情報１３１と登録ＤＢ１３２に、削除候補ＤＢ１３３を含めた情報を記憶する１つの統合データベースを備えるように構成されてもよい。この場合、統合データベースには、削除フラグの項目が含まれる。削除フラグは、削除候補であるか否かを示す情報である。これにより、統合データベースでは、削除フラグを用いて顧客の電話番号を管理することが可能となる。この場合、統合データベースは、「顧客情報」の一例であり、「登録ＤＢ」の一例であり、「削除候補ＤＢ」の一例である。

この場合、例えば、顧客情報管理サーバ１００は、ステップＳ２１において、電話番号リストと、顧客情報１３１とを比較する。顧客情報管理サーバ１００は、ステップＳ２２において、電話番号リストに存在し、かつ顧客情報１３１に存在しない電話番号を、顧客情報１３１に登録する。顧客情報管理サーバ１００は、ステップＳ２４において、電話番号リストに存在しないが、顧客情報１３１に存在している電話番号がある場合、その電話番号を削除候補ＤＢ１３３に追加する。この場合において、顧客情報管理サーバ１００は、その電話番号に対応付けられた顧客の属性情報（住所や氏名等）も併せて削除候補ＤＢ１３３に記憶させるようにする。

また、顧客情報管理サーバ１００は、削除候補ＤＢ１３３に追加した電話番号を、顧客情報１３１から即削除してもよいし、すぐには削除しないようにしてもよい。この場合、顧客情報管理サーバ１００は、例えば、一定期間（例えば、１週間、或いは一か月など）経過後に、その電話番号が削除候補ＤＢ１３３に存在していた場合に、顧客情報１３１から削除するようにしてもよい。

顧客情報管理サーバ１００は、ステップＳ２６において、ステップＳ２５の処理において電話番号が削除候補ＤＢ１３３に存在しないと判定された場合には、その電話番号が新規に所定のメッセージアプリ上の顧客情報管理サービスを利用した（フォローした）顧客端末２０の電話番号として顧客情報１３１に登録する。

一方、顧客情報管理サーバ１００は、ステップＳ２６において、ステップＳ２７の処理において、電話番号が削除候補ＤＢ１３３に存在しており、削除候補ＤＢ１３３からその電話番号を削除した場合には、その電話番号が、所定のメッセージアプリ上の顧客情報管理サービスを再度利用開始した（再度フォローした）顧客端末２０の電話番号とみなす。この場合、顧客情報１３１には、その電話番号がすでに登録されているため、顧客情報１３１にその電話番号を登録する処理を行わない。

以上、説明したとおり、第２の実施形態の顧客情報管理サーバ１００は、顧客端末２０から通知された情報に基づいて、顧客の個人情報である顧客情報１３１を管理する。顧客情報管理サーバ１００は、電話番号リスト取得部１１０と、顧客情報メンテナンス部１２０と、記憶部１３０を備える。記憶部１３０は、顧客情報１３１と、削除候補ＤＢ１３３を記憶する。電話番号リスト取得部１１０は、携帯キャリアが提供するアプリケーションを利用する顧客であって、当該アプリケーションにおいて提供される顧客情報１３１を管理するサービス（すなわち、顧客情報管理サービス）に登録された顧客の電話番号を示す電話番号リストを取得する。顧客情報メンテナンス部１２０は、電話番号リストを用いて、顧客情報１３１に登録された顧客の電話番号が電話番号リストに存在するか否かを判定し、顧客情報１３１に登録された顧客の電話番号が電話番号リストに存在しないと判定した場合、当該存在しないと判定した顧客の顧客情報１３１のうちの少なくとも電話番号を、削除の候補となる顧客の個人情報として削除候補ＤＢ１３３に記憶させる。この場合において、顧客情報管理サーバ１００は、顧客情報１３１に登録された顧客の電話番号が電話番号リストに存在しないと判定した場合、当該存在しないと判定した顧客の顧客情報１３１を削除するようにしてもよい。

これにより、第２の実施形態の顧客情報管理サーバ１００は、既に顧客情報１３１に登録済みの顧客の電話番号が、顧客情報管理サービスに登録されていない（例えば、電話番号が変更された、或いはアカウントのフォローが一時的に外された）状態となった場合に、その電話番号を削除候補ＤＢ１３３に追加することができる。これによって、顧客の電話番号が変更された可能性を考慮しつつ、その後の帰趨を監視することができる。したがって、第２の実施形態の顧客情報管理サーバ１００は、顧客の携帯電話の電話番号が有効なものであるかを定期的に管理することが可能である。例えば、利用機関システム５０に誤った顧客情報を通知してしまう事態を抑制すると共に、削除候補のその後の帰趨に応じて顧客情報１３１から削除可能な状態を維持することができる。すなわち、ＭＮＰにより顧客が契約する携帯キャリアが変更されたが、後に顧客の携帯電話番号に変更がなかった、或いはアカウントのフォローが一時的に外されたがその後再びフォローされたことが判明した場合などに顧客情報１３１を維持することができる。その一方で、所定の期間経過後でも電話番号リストにその電話番号が復活しない場合など顧客の携帯電話番号が変更された蓋然性が高い場合にその顧客の顧客情報１３１を削除することができる。

また、第２の実施形態の顧客情報管理サーバ１００では、電話番号リスト取得部１１０は、定期的に（最新の）電話番号リストを取得する。顧客情報メンテナンス部１２０は、今回取得した電話番号リストに存在し、かつ削除候補ＤＢ１３３に登録されている電話番号（復活電話番号）が存在するか否かを判定する。顧客情報メンテナンス部１２０は、該当する電話番号が存在する場合、その電話番号が削除候補ＤＢ１３３に登録されている場合には、その削除候補ＤＢ１３３に登録されている電話番号を、削除候補ＤＢ１３３から削除する。これにより、第２の実施形態の顧客情報管理サーバ１００では、顧客の携帯電話が変更された可能性が疑われたが、後に顧客の携帯電話番号に変更がなかったことが判明した場合に、顧客情報１３１を維持することができる。これにより、顧客の顧客情報１３１を削除した後、間もなく再度の登録を行うような手間のかかる処理を抑止することが可能となる。

尚、顧客情報管理サーバ１０は、顧客端末２０からの顧客情報の登録や更新の要求通知を受けない場合であっても、電話番号リストに基づいて、顧客の電話番号が解約されたことが確認された場合に、その旨を、銀行に対応する利用機関システム５０に通知するようにしてもよい。これにより、銀行側においても、顧客の電話番号が解約されたことを確認し、利用機関システム５０における顧客情報を更新することができる。

なお、上述した少なくとも一つの実施形態では、顧客情報管理サービスのアカウントをフォローした顧客の情報が顧客情報１３１に登録される場合を例に説明した。しかしながら、厳密には、顧客情報管理サービスのアカウントがフォローされた時点においては、顧客の電話番号が登録ＤＢ１３２のみに登録され、顧客情報１３１は登録されない。アカウントがフォローした時点においては、顧客の携帯電話番号のみが携帯キャリアサーバ３０を介して顧客情報管理サーバ１０に通知されるためである。

顧客情報管理サービスは、携帯キャリアが提供するアプリケーション上で提供されるサービスである。このため、顧客情報管理サービスのアカウントがフォローされると、携帯キャリアサーバ３０がそれを認知することができる。そして、顧客情報管理サービスの提供者である顧客情報管理サーバ１０は、例えば定期的に、携帯キャリアサーバ３０に問い合わせを行い、顧客情報管理サービスのアカウントをフォローした顧客の電話番号を取得する。顧客情報管理サーバ１０は、取得した電話番号に基づいて、顧客の登録ＤＢ１３２を作成する。

そして、顧客情報管理サービスのアカウントをフォローした顧客により、顧客情報管理サービスの利用登録がなされると、利用登録の過程で入力された顧客の氏名等が顧客情報管理サーバ１０に通知される。顧客情報管理サーバ１０は、通知された顧客の氏名等に基づいて、顧客の顧客情報１３１を作成する。

上述した実施形態における顧客情報管理サーバ１０（１００）の全部または一部をコンピュータで実現するようにしてもよい。その場合、この機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよく、ＦＰＧＡ等のプログラマブルロジックデバイスを用いて実現されるものであってもよい。

以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

１…管理システム
１０、１００…顧客情報管理サーバ
２０…顧客端末
３０…携帯キャリアサーバ
５０…利用機関システム
１１０…電話番号リスト取得部
１２０…顧客情報メンテナンス部
１３０…記憶部
１３１…顧客情報
１３２…登録ＤＢ
１３３…削除候補ＤＢ

Claims (5)

1. 顧客端末から通知された情報に基づいて、顧客の個人情報である顧客情報を管理する顧客情報管理サーバであって、
   前記顧客情報と、前記顧客情報から削除する候補となる顧客の個人情報である削除候補ＤＢを記憶する記憶部と、
   携帯キャリアが提供するアプリケーションを利用する顧客であって、当該アプリケーションにおいて提供される前記顧客情報を管理するサービスに登録された顧客の電話番号を示す電話番号リストを取得する電話番号リスト取得部と、
   前記電話番号リストを用いて、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在するか否かを判定し、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在しないと判定した場合、当該存在しないと判定した顧客の前記顧客情報のうちの少なくとも電話番号を削除候補ＤＢに記憶させる顧客情報メンテナンス部と、
   を備える顧客情報管理サーバ。
2. 前記顧客情報メンテナンス部は、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在しないと判定した場合、当該存在しないと判定した顧客の前記顧客情報を削除する、
   請求項１に記載の顧客情報管理サーバ。
3. 前記電話番号リスト取得部は、定期的に前記電話番号リストを取得し、
   前記顧客情報メンテナンス部は、今回取得した電話番号リストに存在し、かつ前記削除候補ＤＢに登録されている復活電話番号が存在するか否かを判定し、前記復活電話番号が存在する場合には、前記削除候補ＤＢに登録されている前記復活電話番号を、前記削除候補ＤＢから削除する、
   請求項１又は請求項２に記載の顧客情報管理サーバ。
4. 顧客端末から通知された情報に基づいて、顧客の個人情報である顧客情報を管理する顧客情報管理サーバであって、前記顧客情報と、前記顧客情報から削除する候補となる顧客の個人情報である削除候補ＤＢを記憶する記憶部を備える顧客情報管理サーバの顧客情報管理方法であって、
   電話番号リスト取得部が、携帯キャリアが提供するアプリケーションを利用する顧客であって、当該アプリケーションにおいて提供される前記顧客情報を管理するサービスに登録された顧客の電話番号を示す電話番号リストを取得し、
   顧客情報メンテナンス部が、前記電話番号リストを用いて、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在するか否かを判定し、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在しないと判定した場合、当該存在しないと判定した顧客の前記顧客情報のうちの少なくとも電話番号を削除候補ＤＢに記憶させる、
   顧客情報管理方法。
5. コンピュータを、請求項１から請求項３のいずれか一項に記載の顧客情報管理サーバとして動作させるためのプログラムであって、前記コンピュータを前記顧客情報管理サーバが備える各部として機能させるためのプログラム。

Images