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

Abstract

【課題】顧客の携帯電話の電話番号が有効なものであるかを定期的に管理し、最新の情報を事業者に通知することができる顧客情報管理サーバを提供する。【解決手段】顧客情報を記憶する記憶部と、携帯キャリアが提供するアプリケーションを利用する顧客であって、当該アプリケーションにおいて提供される前記顧客情報を管理するサービスに登録された顧客の電話番号を示す電話番号リストを取得する電話番号リスト取得部と、前記電話番号リストを用いて、前記顧客情報から削除する候補となる削除候補電話番号、及び前記顧客情報から削除する削除電話番号を、段階的に抽出する顧客情報メンテナンス部と、前記顧客の意思に基づいて、前記顧客情報メンテナンス部によって抽出された前記削除候補電話番号又は前記削除電話番号を示す情報のうち少なくとも一方を、前記顧客が利用するサービスを提供する利用機関システムに提供する顧客情報提供部と、を備える。【選択図】図６

Description

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

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

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

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

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

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

本発明の上述した課題を解決するために、本発明は、顧客端末から通知された情報に基づいて、顧客の個人情報である顧客情報を管理する顧客情報管理サーバであって、前記顧客情報を記憶する記憶部と、携帯キャリアが提供するアプリケーションを利用する顧客であって、当該アプリケーションにおいて提供される前記顧客情報を管理するサービスに登録された顧客の電話番号を示す電話番号リストを取得する電話番号リスト取得部と、前記電話番号リストを用いて、前記顧客情報から削除する候補となる削除候補電話番号、及び前記顧客情報から削除する削除電話番号を、段階的に抽出する顧客情報メンテナンス部と、前記顧客の意思に基づいて、前記顧客情報メンテナンス部によって抽出された前記削除候補電話番号又は前記削除電話番号を示す情報のうち少なくとも一方を、前記顧客が利用するサービスを提供する利用機関システムに提供する顧客情報提供部と、を備える顧客情報管理サーバである。

また、本発明は、上述の顧客情報管理サーバにおいて、前記記憶部は、前記顧客情報から削除する候補となる顧客の個人情報である削除候補ＤＢを記憶し、前記電話番号リスト取得部は、定期的に前記電話番号リストを取得し、前記顧客情報メンテナンス部は、前記電話番号リストを用いて、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在するか否かを判定し、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在しないと判定した場合、当該存在しないと判定した顧客の電話番号を前記削除候補電話番号として、前記削除候補電話番号を示す情報を前記削除候補ＤＢに記憶させ、前記削除候補ＤＢに前記削除候補電話番号を示す情報が記憶された時点から所定期間が経過した後に取得された前記電話番号リストに、前記削除候補電話番号が存在しない場合、当該存在しない前記削除候補電話番号を示す情報を前記削除候補ＤＢから削除すると共に、前記削除候補電話番号を示す情報に対応する前記顧客情報を削除し、前記顧客情報提供部は、前記削除電話番号を示す情報を、前記利用機関システムに提供する。

また、本発明は、上述の顧客情報管理サーバにおいて、前記顧客情報メンテナンス部は、前記削除候補ＤＢに前記削除候補電話番号を示す情報が記憶された時点以降に取得された電話番号リストに、前記削除候補電話番号を示す情報に対応する電話番号が存在するか否かを判定し、該当する電話番号が存在する場合、該当する電話番号に対応する前記削除候補電話番号を示す情報を前記削除候補ＤＢから削除する。

また、本発明は、上述の顧客情報管理サーバにおいて、前記記憶部は、前記顧客情報から削除する候補となる顧客の個人情報である削除候補ＤＢを記憶し、前記電話番号リスト取得部は、定期的に前記電話番号リストを取得し、前記顧客情報メンテナンス部は、前記電話番号リストを用いて、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在するか否かを判定し、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在しないと判定した場合、当該存在しないと判定した顧客の電話番号を前記削除候補電話番号とし、前記削除候補電話番号を示す情報を前記削除候補ＤＢに記憶させ、前記顧客情報提供部は、前記削除候補電話番号を示す情報を、前記利用機関システムに提供する。

また、本発明は、上述の顧客情報管理サーバにおいて、前記顧客情報メンテナンス部は、前記削除候補ＤＢに前記削除候補電話番号を示す情報が記憶された時点以降に取得された電話番号リストに、前記削除候補ＤＢに記憶されている前記削除候補電話番号を示す情報に対応する電話番号が存在するか否かを判定し、該当する電話番号が存在する場合、該当する前記削除候補電話番号を示す情報を前記削除候補ＤＢから削除し、前記顧客情報提供部は、前記顧客情報メンテナンス部によって前記削除候補ＤＢから削除された前記削除候補電話番号を示す情報を、削除候補から除外された電話番号を示す情報として前記利用機関システムに提供する。

また、本発明は、顧客端末から通知された情報に基づいて、顧客の個人情報である顧客情報を管理する顧客情報管理サーバであって、前記顧客情報を記憶する記憶部を備える顧客情報管理サーバの顧客情報管理方法であって、電話番号リスト取得部が、携帯キャリアが提供するアプリケーションを利用する顧客であって、当該アプリケーションにおいて提供される前記顧客情報を管理するサービスに登録された顧客の電話番号を示す電話番号リストを取得し、顧客情報メンテナンス部が、前記電話番号リストを用いて、前記顧客情報から削除する候補となる削除候補電話番号、及び前記顧客情報から削除する削除電話番号を、段階的に抽出し、顧客情報提供部が、前記顧客の意思に基づいて、前記顧客情報メンテナンス部によって抽出された前記削除候補電話番号又は前記削除電話番号を示す情報のうち少なくとも一方を、前記顧客が利用するサービスを提供する利用機関システムに提供する、顧客情報管理方法である。

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

本発明によれば、顧客の携帯電話の電話番号が有効なものであるかを定期的に管理し、最新の情報を事業者に通知することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

顧客情報管理サーバ１００は、例えば、電話番号リスト取得部１１０と、顧客情報メンテナンス部１２０と、記憶部１３０と、顧客情報提供部１４０とを備える。なお、本実施形態では、第１の実施形態における顧客情報提供部１７と、本実施形態の顧客情報提供部１４０を異なる符号を付して区別して説明するが、顧客情報提供部１４０が顧客情報提供部１７の機能を備えるようにしてもよい。

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

顧客情報メンテナンス部１２０は、電話番号リスト、及び後述する登録ＤＢ１３２と削除候補ＤＢ１３３とを用いて顧客情報の管理（メンテナンス）を行い、顧客情報１３１を最新の情報に更新する。顧客情報メンテナンス部１２０が、顧客情報１３１を最新の情報に更新する方法については後で詳しく説明する。

記憶部１３０は、例えば、ＨＤＤ、フラッシュメモリ等により構成される。記憶部１３０は、顧客情報１３１と、登録ＤＢ１３２と、削除候補ＤＢ１３３とを記憶する。

顧客情報１３１は、顧客端末２０から受信した顧客の個人情報である。顧客情報管理サーバ１０は、顧客が顧客情報管理サービスの利用登録を行う際に入力した氏名などの情報を、顧客情報として顧客端末２０から受信する。顧客情報管理サーバ１０は、顧客情報管理サービスの利用登録時に顧客端末２０から受信した情報を、顧客情報１３１として顧客情報処理部１３に記憶させる。

登録ＤＢ１３２は、顧客情報管理サービスのアカウントをフォローしている顧客の電話番号を示す情報である。登録ＤＢ１３２は、定期的に取得される電話番号リストに対応して、顧客情報メンテナンス部１２０によって作成及び更新される。顧客情報メンテナンス部１２０が、登録ＤＢ１３２を作成及び更新する方法については後で詳しく説明する。

削除候補ＤＢ１３３は、顧客情報１３１のうち、そこに登録された電話番号が何らかの理由により削除される可能性がある顧客に関する情報である。削除候補ＤＢ１３３は、電話番号リスト、顧客情報１３１、及び登録ＤＢ１３２に基づいて、顧客情報メンテナンス部１２０によって作成及び更新される。顧客情報メンテナンス部１２０が、削除候補ＤＢ１３３を作成及び更新する方法については後で詳しく説明する。

顧客情報提供部１４０は、顧客情報メンテナンス部１２０によって最新の情報となった顧客情報１３１を、前記顧客の意思に基づいて利用機関システム５０に提供（通知）する。例えば、顧客情報提供部１４０は、顧客情報１３１に変更が生じた場合に、変更が生じた顧客情報１３１を、利用機関システム５０に通知してよい旨の了承を顧客から得た上で、利用機関システム５０に送信する。或いは、顧客情報提供部１４０は、顧客情報１３１が最新の情報に更新される度に、変更の有無にかかわらず、利用機関システム５０に通知してよい旨の了承を顧客から得た上で、最新の顧客情報１３１を利用機関システム５０に送信するようにしてもよい。顧客情報提供部１４０が、利用機関システム５０に最新の顧客情報を通知する態様については、例えば、顧客情報管理サービスにおける利用機関システム５０との取り決めによって決定される。

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

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

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

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

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

なお、本実施形態では、顧客情報管理サービスのアカウントをフォローした顧客の電話番号が登録ＤＢ１３２に記憶される。その後、アカウントをフォローした顧客により、顧客情報管理サービスの利用登録がなされると、利用登録の過程で入力された顧客の氏名等が顧客情報管理サーバ１０に通知される。これに伴い。顧客情報管理サーバ１０は、通知された顧客の氏名等に基づいて、顧客の個人情報を顧客情報１３１に記憶させる。

このため、顧客情報管理サービスのアカウントがフォローされてから、利用登録がなされるまでの間、顧客情報管理サーバ１０には、顧客の登録ＤＢ１３２が記憶されているが、その顧客の顧客情報１３１が記憶されない状態となる。顧客情報１３１を最新の情報に更新するために、同一顧客の顧客情報１３１と登録ＤＢ１３２とは連携させておく必要がある。このため、顧客情報管理サーバ１０は、電話番号リストに基づいて、新規に登録ＤＢ１３２を作成する際に、例えば、新規の識別キーを発行する。その後、同一顧客から利用登録がなされた際に、顧客情報管理サーバ１０は、その顧客の登録ＤＢ１３２に対応付けられた識別キーを用いた顧客情報１３１を作成する。

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

ここで、顧客情報メンテナンス部１２０が、顧客情報１３１を最新の情報に更新する方法について説明する。

上述したように、電話番号リストは、顧客情報管理サービスのアカウントをフォローしている顧客の電話番号を示すリストである。電話番号リストに今まで存在していた顧客の電話番号が存在しなくなるケースとして、以下のケースが考えられる。

ケース１：アカウントのフォローが解除された場合
電話番号リストは、顧客情報管理サービスのアカウントをフォローしている顧客の電話番号を示すリストである。このため、顧客が当該アカウントのフォローを解除した場合、その後に通知される電話番号リストには、その顧客の電話番号が存在しなくなる。この場合、顧客の電話番号に変更はないため、顧客情報１３１に記憶された顧客の電話番号を変更する必要はない。

ケース２：携帯電話が解約された場合
顧客が、顧客情報管理サービスのアカウントをフォローしていた携帯電話を解約した場合、その解約後に通知される電話番号リストには、それまで存在していた顧客の電話番号が存在しなくなる。この場合、顧客の電話番号が変更されるため、顧客情報１３１に記憶された顧客の電話番号を変更する必要がある。

ケース３：携帯電話の携帯キャリアが、ＭＮＰ（携帯電話番号ポータビリティ）制度を利用して変更された場合
顧客が、ＭＮＰ制度を利用して携帯キャリアを変更した場合、その変更後に通知される電話番号リストには、それまで存在していた顧客の電話番号が存在しなくなる。しかしながら、ＭＮＰを利用した携帯キャリア変更の場合、顧客の携帯電話番号は維持され、変更されない。この場合、顧客情報１３１に記憶された顧客の電話番号を変更する必要はない。

顧客情報メンテナンス部１２０は、定期的に取得する電話番号リストに基づいて、上述したケースを考慮して、顧客情報１３１が最新の情報となるように管理する。

例えば、電話番号リストに存在しなくなった電話番号を、直ちに顧客情報１３１から削除してしまうと、アカウントのフォローを一時的に解除した顧客や、ＭＮＰによる携帯キャリアの変更を行った顧客の電話番号が、電話番号が変更されていないにもかかわらず、削除されてしまうことになる。

アカウントのフォローを一時的に解除した顧客については、再度フォローすれば、電話番号リストにその電話番号が復活する。ＭＮＰによる携帯キャリアの変更を行った顧客の電話番号は、携帯キャリアサーバ３０から通知される電話番号リストに再び存在するようになる。この場合、顧客情報管理サーバ１０は、複数のキャリアの携帯キャリアサーバ３０のそれぞれと通信可能に接続され、それぞれの携帯キャリアサーバ３０から、定期的に、電話番号リストを取得する。或いは、１つの携帯キャリアサーバ３０が、顧客情報管理サーバ１０からの要求に応じて、複数のキャリアのそれぞれの電話番号リストをまとめて、顧客情報管理サーバ１０に通知するようにしてもよい。このように、一旦電話番号リストに存在しなくなった電話番号が、その後に復活する場合があり得る。

このような性質を利用して、顧客情報メンテナンス部１２０は、電話番号リストに存在しなくなった電話番号を、即時に顧客情報１３１から削除せず、一旦、削除候補ＤＢ１３３にその情報を記憶させておく。ここで、顧客情報メンテナンス部１２０が削除候補ＤＢ１３３に記憶させる電話番号は、顧客情報１３１から削除する候補となる電話番号であり、「削除候補電話番号」の一例である。そして、顧客情報メンテナンス部１２０は、一定期間（例えば、１週間、或いは１か月などの期間）が経過してもなお、電話番号リストにその電話番号が存在しない状態が継続した場合に、その電話番号に対応する顧客の顧客情報１３１を削除する。ここで、顧客情報メンテナンス部１２０が顧客情報１３１から削除した電話番号は、「削除電話番号」の一例である。このように、顧客情報メンテナンス部１２０は、まず、削除する候補となる電話番号を抽出し、その後候補の中から削除する電話番号を抽出する、という段階的な抽出を行う。これにより、削除候補とした電話番号がその後復活することを考慮しつつ、顧客情報１３１を、より正確に最新の情報に更新することが可能である。

このように、削除される可能性がある電話番号を、削除候補ＤＢ１３３に登録しておくことにより、顧客情報メンテナンス部１２０は、顧客の電話番号が本当に変更されたのか否かを段階的に見極めることが可能となる。例えば、顧客情報メンテナンス部１２０は、削除候補ＤＢ１３３に記憶された電話番号と、最新の電話番号リストと突合し、削除日（電話番号リストに電話番号が存在しなくなった日、すなわち、削除候補ＤＢ１３３に電話番号が登録された日）から一定期間が経過してもなお、電話番号リストに電話番号が存在しない状態が継続している場合に、対応する顧客情報１３１を削除する対応を行うことができる。

これにより、電話番号を解約した、又は、アカウントのフォローを（一時的ではなく）解除して顧客情報管理サービスを利用しない意思を表明した顧客の顧客情報１３１を削除することができる。したがって、顧客情報１３１を最新の情報に更新することが可能である。

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

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

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

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

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

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

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

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

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

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

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

（第２の実施形態における利用機関システム５０への通知のバリエーション）
ここで、第２の実施形態における利用機関システム５０への通知のバリエーションについて説明する。利用機関システム５０への通知は、顧客情報管理サーバ１０と利用機関システム５０との間の取り決めにより、任意に設定されてよい。例えば、顧客情報メンテナンス部１２０が顧客情報１３１から電話番号を削除した場合に、その電話番号（削除電話番号）を利用機関システム５０に通知する態様が考えられる（態様１）。

態様１を適用することにより、削除される可能性がある電話番号（削除候補電話番号）の削除が確定した場合に、その確定した情報を利用機関システム５０に通知することができ、より正確な情報を利用機関システム５０に通知することが可能である。

或いは、削除候補電話番号を、利用機関システム５０に通知する態様（態様２）が適用されてもよい。態様２は、例えば、顧客情報管理サーバ１０と利用機関システム５０との間で、「電話番号が削除される可能性があればいち早くその情報を通知する」と取り決めが行われ場合に適用される。

態様２では、顧客情報１３１に記憶された情報に変更はないが、削除候補ＤＢ１３３に記憶された情報に変更がある場合に、顧客情報管理サーバ１００は、その変更された情報を、利用機関システム５０に通知する。

具体的に、顧客情報管理サーバ１００は、図１０に示すステップＳ２４において、登録ＤＢ１３２から削除した電話番号を、削除候補ＤＢ１３３に追加する。この場合、顧客情報管理サーバ１００は、削除候補ＤＢ１３３に追加した電話番号を、「削除候補電話番号」として、利用機関システム５０に通知する。

また、顧客情報管理サーバ１００は、図１０に示すステップＳ２７において、電話番号リストにある電話番号が削除候補ＤＢ１３３に存在する場合に、その電話番号を削除候補ＤＢ１３３から削除する。この場合、顧客情報管理サーバ１００は、削除候補ＤＢ１３３から削除した電話番号を、削除の候補から除外された電話番号として、利用機関システム５０に通知する。

なお、顧客情報管理サーバ１００は、利用機関システム５０に電話番号を通知する代わりに、その電話番号に対応付けられた識別キーを利用機関システム５０に通知するようにしてもよい。

また、態様２において、顧客情報管理サーバ１００は、図１０のステップＳ２４において削除候補ＤＢ１３３に追加した電話番号を、顧客情報１３１に一定期間記憶させることなく、即削除するような運用としてもよい。

この場合、顧客情報管理サーバ１００は、削除候補ＤＢ１３３に追加し、顧客情報１３１から削除した電話番号を、「削除候補電話番号」として、利用機関システム５０に通知する。その後、図１０に示すステップＳ２７において、「削除候補電話番号」を削除候補ＤＢ１３３から削除した場合、顧客情報管理サーバ１００は、削除候補ＤＢ１３３から削除した電話番号を顧客情報１３１に復活させる。そして、顧客情報管理サーバ１００は、削除候補ＤＢ１３３から削除し、顧客情報１３１に復活させた電話番号を、「削除候補電話番号」から除外された電話番号として、利用機関システム５０に通知する。

以上、説明したとおり、第２の実施形態の顧客情報管理サーバ１００は、顧客端末２０から通知された情報に基づいて、顧客情報１３１を管理するサーバである。顧客情報１３１は、顧客の個人情報である。顧客情報管理サーバ１００は、記憶部１３０と、電話番号リスト取得部１１０と、顧客情報メンテナンス部１２０と、顧客情報提供部１４０とを備える。記憶部１３０は、顧客情報１３１を記憶する。電話番号リスト取得部１１０は、電話番号リストを取得する。電話番号リストは、顧客の電話番号が示された情報である。ここでの顧客は、携帯キャリアが提供するアプリケーションを利用する顧客であって、当該アプリケーションにおいて提供される顧客情報管理サービスに利用登録をした顧客である。顧客情報メンテナンス部１２０は、電話番号リストを用いて、顧客情報１３１から削除する候補となる「削除候補電話番号」、及び顧客情報１３１から削除する「削除電話番号」を、段階的に抽出する。顧客情報提供部１４０は、顧客の意思に基づいて、「削除候補電話番号」又は「削除電話番号」を示す情報のうち少なくとも一方を、利用機関システム５０に提供する。利用機関システム５０は、顧客が利用する銀行などのシステムである。

これにより、第２の実施形態の顧客情報管理サーバ１００では、電話番号リスト取得部１１０により定期的に取得される電話番号リストを基に、顧客情報メンテナンス部１２０によって顧客の携帯電話の電話番号を、段階的に最新の情報に更新することができる。そして、顧客情報提供部１４０により、利用機関システム５０に、「削除候補電話番号」又は「削除電話番号」を提供することが可能である。したがって、顧客の携帯電話の電話番号が有効なものであるかを定期的に管理し、削除されそうな電話番号や削除された電話番号を事業者に通知することにより、最新の情報を通知することができる。

また、第２の実施形態の顧客情報管理サーバ１００では、記憶部１３０は、削除候補ＤＢ１３３を記憶する。削除候補ＤＢ１３３は、顧客情報１３１から削除する候補となる顧客の個人情報である。電話番号リスト取得部１１０は、定期的に電話番号リストを取得する。顧客情報メンテナンス部１２０は、電話番号リストを用いて、顧客情報１３１に登録された顧客の電話番号が電話番号リストに存在するか否かを判定する。顧客情報メンテナンス部１２０は、顧客情報１３１に登録された顧客の電話番号が、電話番号リストに存在しないと判定した場合、当該存在しないと判定した顧客の顧客情報１３１を一意に識別する識別キーを、「削除候補電話番号」の識別キーとして、削除候補ＤＢ１３３に記憶させる。この場合、識別キーは「削除候補電話番号を示す情報」の一例である。また、この場合において、識別キーの代わりに削除候補電話番号そのものが削除候補ＤＢ１３３に記憶されてもよい。この場合における削除候補電話番号は「削除候補電話番号を示す情報」の一例である。顧客情報メンテナンス部１２０は、削除候補ＤＢ１３３に識別キーが記憶された時点から所定期間が経過した後に取得された電話番号リストに、識別キーに対応する電話番号が存在しない場合、識別キーに対応する電話番号を、「削除電話番号」として顧客情報１３１から削除する。この場合、識別キーは「削除電話番号を示す情報」の一例である。また、この場合において、識別キーの代わりに、或いは識別キーと共に、削除電話番号が顧客情報１３１から削除される。この場合における削除電話番号は「削除電話番号を示す情報」の一例である。顧客情報提供部１４０は、「削除電話番号」を示す情報（すなわち、削除電話番号そのもの又は削除電話番号に対応する識別キー）を、利用機関システム５０に提供する。

これにより、第２の実施形態の顧客情報管理サーバ１００では、顧客の電話番号が本当に変更されたのか否かを、まず「削除候補電話番号」を抽出し、次に「削除候補電話番号」から「削除電話番号」を抽出するという段階的な処理で見極めることができ、電話番号を解約した、又は、アカウントのフォローを（一時的ではなく）解除して顧客情報管理サービスを利用しない意思を表明した蓋然性の高い顧客の電話番号を削除し、削除した電話番号を示す情報を利用機関システム５０に通知することができる。したがって、より確度の高い最新の情報を利用機関システム５０に通知することが可能となる。

また、第２の実施形態の顧客情報管理サーバ１００では、顧客情報メンテナンス部１２０は、削除候補ＤＢ１３３に識別キーが記憶された時点以降に取得された電話番号リストに、削除候補ＤＢ１３３に記憶されている識別キーに対応する電話番号が存在するか否かを判定する。顧客情報メンテナンス部１２０は、該当する電話番号が存在する場合、その該当する識別キーを削除候補ＤＢから削除する。これにより、第２の実施形態の顧客情報管理サーバ１００では、顧客の電話番号が本当に変更されたのか否かを見極め、ＭＮＰを利用して携帯キャリアの変更をした顧客、又は、アカウントのフォローを一時的に解除したがその後再フォローした顧客、すなわち電話番号に変更がない顧客について、その顧客情報１３１を維持することができる。したがって、一旦削除した顧客情報１３１を、その直後に復活させたりする手間をかけることなく、顧客情報１３１を最新の情報に更新することが可能となる。

また、第２の実施形態に係る顧客情報管理サーバ１００では、記憶部１３０は、削除候補ＤＢ１３３を記憶する。削除候補ＤＢ１３３は、顧客情報１３１から削除する候補となる顧客の個人情報である。電話番号リスト取得部１１０は、定期的に電話番号リストを取得する。顧客情報メンテナンス部１２０は、電話番号リストを用いて、顧客情報１３１に登録された顧客の電話番号が電話番号リストに存在するか否かを判定する。顧客情報メンテナンス部１２０は、顧客情報１３１に登録された顧客の電話番号が、電話番号リストに存在しないと判定した場合、当該存在しないと判定した顧客の顧客情報１３１を一意に識別する識別キーを、「削除候補電話番号」の識別キーとして、削除候補ＤＢ１３３に記憶させる。この場合、識別キーは「削除候補電話番号を示す情報」の一例である。また、この場合において、識別キーの代わりに削除候補電話番号そのものが削除候補ＤＢ１３３に記憶されてもよい。この場合における削除候補電話番号は「削除候補電話番号を示す情報」の一例である。顧客情報提供部１４０は、「削除候補電話番号」を示す情報（すなわち、削除候補電話番号そのもの又は削除候補電話番号に対応する識別キー）を、利用機関システム５０に提供する。

これにより、第２の実施形態に係る顧客情報管理サーバ１００では、顧客の電話番号が本当に変更される前に、まず「削除候補電話番号」を抽出し、変更される可能性がある電話番号として利用機関システム５０に通知することができる。したがって、変更される可能性がある電話番号いち早く利用機関システム５０に通知することが可能である。

また、第２の実施形態に係る顧客情報管理サーバ１００では、顧客情報メンテナンス部１２０は、削除候補ＤＢ１３３に識別キーが記憶された時点以降に取得された電話番号リストに、削除候補ＤＢ１３３に記憶されている識別キーに対応する電話番号が存在するか否かを判定する。この場合、識別キーは「削除候補電話番号を示す情報」の一例である。また、識別キーに対応する電話番号は、「削除候補電話番号」の一例である。顧客情報メンテナンス部１２０は、該当する電話番号が存在する場合、その該当する識別キー（或いは、「削除候補電話番号」そのもの）を削除候補ＤＢから削除する。顧客情報提供部１４０は、顧客情報メンテナンス部１２０によって削除候補ＤＢ１３３から削除された電話番号を示す情報（すなわち、「削除候補電話番号」或いは「削除候補電話番号」に対応する識別キー）を、削除候補から除外された電話番号を示す情報として利用機関システム５０に提供する。

これにより、第２の実施形態に係る顧客情報管理サーバ１００では、削除候補として通知した電話番号が、その後復活した場合に、削除候補から除外された旨を利用機関システム５０に通知することができる。したがって、変更される可能性がなくなった電話番号いち早く利用機関システム５０に通知することが可能である。

なお、上述した実施形態では、顧客情報１３１、或いは削除候補ＤＢ１３３を削除する構成について説明した。この場合における情報を削除する処理の態様は、論理削除であってもよいし、物理削除であってもよい。すなわち、実際にはデータを削除せずに、削除フラグを設定することで（論理的に）削除された情報とみなすようにしてもよいし、実際に（物理的に）データを削除するようにしてもよい。

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

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

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

Claims (7)

1. 顧客端末から通知された情報に基づいて、顧客の個人情報である顧客情報を管理する顧客情報管理サーバであって、
   前記顧客情報を記憶する記憶部と、
   携帯キャリアが提供するアプリケーションを利用する顧客であって、当該アプリケーションにおいて提供される前記顧客情報を管理するサービスに登録された顧客の電話番号を示す電話番号リストを取得する電話番号リスト取得部と、
   前記電話番号リストを用いて、前記顧客情報から削除する候補となる削除候補電話番号、及び前記顧客情報から削除する削除電話番号を、段階的に抽出する顧客情報メンテナンス部と、
   前記顧客の意思に基づいて、前記顧客情報メンテナンス部によって抽出された前記削除候補電話番号又は前記削除電話番号を示す情報のうち少なくとも一方を、前記顧客が利用するサービスを提供する利用機関システムに提供する顧客情報提供部と、
   を備える顧客情報管理サーバ。
2. 前記記憶部は、前記顧客情報から削除する候補となる顧客の個人情報である削除候補ＤＢを記憶し、
   前記電話番号リスト取得部は、定期的に前記電話番号リストを取得し、
   前記顧客情報メンテナンス部は、前記電話番号リストを用いて、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在するか否かを判定し、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在しないと判定した場合、当該存在しないと判定した顧客の電話番号を前記削除候補電話番号として、前記削除候補電話番号を示す情報を前記削除候補ＤＢに記憶させ、前記削除候補ＤＢに前記削除候補電話番号を示す情報が記憶された時点から所定期間が経過した後に取得された前記電話番号リストに、前記削除候補電話番号が存在しない場合、当該存在しない前記削除候補電話番号を示す情報を前記削除候補ＤＢから削除すると共に、前記削除候補電話番号を示す情報に対応する前記顧客情報を削除し、
   前記顧客情報提供部は、前記削除電話番号を示す情報を、前記利用機関システムに提供する、
   請求項１に記載の顧客情報管理サーバ。
3. 前記顧客情報メンテナンス部は、前記削除候補ＤＢに前記削除候補電話番号を示す情報が記憶された時点以降に取得された電話番号リストに、前記削除候補電話番号を示す情報に対応する電話番号が存在するか否かを判定し、該当する電話番号が存在する場合、該当する電話番号に対応する前記削除候補電話番号を示す情報を前記削除候補ＤＢから削除する、
   請求項２に記載の顧客情報管理サーバ。
4. 前記記憶部は、前記顧客情報から削除する候補となる顧客の個人情報である削除候補ＤＢを記憶し、
   前記電話番号リスト取得部は、定期的に前記電話番号リストを取得し、
   前記顧客情報メンテナンス部は、前記電話番号リストを用いて、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在するか否かを判定し、前記顧客情報に登録された顧客の電話番号が前記電話番号リストに存在しないと判定した場合、当該存在しないと判定した顧客の電話番号を前記削除候補電話番号とし、前記削除候補電話番号を示す情報を前記削除候補ＤＢに記憶させ、
   前記顧客情報提供部は、前記削除候補電話番号を示す情報を、前記利用機関システムに提供する、
   請求項１に記載の顧客情報管理サーバ。
5. 前記顧客情報メンテナンス部は、前記削除候補ＤＢに前記削除候補電話番号を示す情報が記憶された時点以降に取得された電話番号リストに、前記削除候補ＤＢに記憶されている前記削除候補電話番号を示す情報に対応する電話番号が存在するか否かを判定し、該当する電話番号が存在する場合、該当する前記削除候補電話番号を示す情報を前記削除候補ＤＢから削除し、
   前記顧客情報提供部は、前記顧客情報メンテナンス部によって前記削除候補ＤＢから削除された前記削除候補電話番号を示す情報を、削除候補から除外された電話番号を示す情報として前記利用機関システムに提供する、
   請求項４に記載の顧客情報管理サーバ。
6. 顧客端末から通知された情報に基づいて、顧客の個人情報である顧客情報を管理する顧客情報管理サーバであって、前記顧客情報を記憶する記憶部を備える顧客情報管理サーバの顧客情報管理方法であって、
   電話番号リスト取得部が、携帯キャリアが提供するアプリケーションを利用する顧客であって、当該アプリケーションにおいて提供される前記顧客情報を管理するサービスに登録された顧客の電話番号を示す電話番号リストを取得し、
   顧客情報メンテナンス部が、前記電話番号リストを用いて、前記顧客情報から削除する候補となる削除候補電話番号、及び前記顧客情報から削除する削除電話番号を、段階的に抽出し、
   顧客情報提供部が、前記顧客の意思に基づいて、前記顧客情報メンテナンス部によって抽出された前記削除候補電話番号又は前記削除電話番号を示す情報のうち少なくとも一方を、前記顧客が利用するサービスを提供する利用機関システムに提供する、
   顧客情報管理方法。
7. コンピュータを、請求項１から請求項５のいずれか一項に記載の顧客情報管理サーバとして動作させるためのプログラムであって、前記コンピュータを前記顧客情報管理サーバが備える各部として機能させるためのプログラム。

Images