JP2023028942A - 情報処理装置、情報処理方法 - Google Patents

Abstract

【課題】宛先とされたユーザ以外にメッセージが届いてしまうことを抑制することができる情報処理装置を提供する。【解決手段】メッセージを送信する送信先の電話番号の送信先に対応する通信端末に対して、前記電話番号の契約者が前記メッセージを送信する宛先のユーザであるかを認証する認証方法を指定してもらうための候補を送信する送信部と、前記候補から指定された認証方法に基づくユーザ認証が行われた結果に応じて、前記メッセージを送信可否の判定を行うための制御をする制御部とを有する。【選択図】図１

Description

本発明は、情報処理装置、情報処理方法に関する。

オンラインで情報を通知する電子通知サービスが提供されている。
特許文献１では、顧客に通知を行う際、顧客がすぐに見ることのできる確率が高いアドレスに情報を送信する技術が開示されている。

このような電子通知サービスのうち、携帯電話番号を宛先とするメッセージサービスが広く普及している。携帯電話番号を宛先とするメッセージサービスには、例えば、ＲＣＳ（Rich Communication Services）等がある。携帯電話番号を宛先とすることにより、通知先の相手のメールアドレスが不明であっても、メッセージを送信することができる。

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

しかしながら、携帯電話番号を宛先としてメッセージを送信する場合、ユーザが携帯電話番号を提供する通信事業者との契約を終了していた場合には、その携帯電話番号が他のユーザに割り当てられている場合がある。そうすると、メッセージは、送信対象としていたユーザに届かず、別のユーザに届いてしまう。メッセージの内容によっては重要度が高いものもあるため、送信対象としていたユーザに届くことが望ましい。

本発明は、このような事情に鑑みてなされたもので、その目的は、宛先とされたユーザ以外にメッセージが届いてしまうことを抑制することができる情報処理装置、情報処理方法を提供することにある。

上述した課題を解決するために、本発明の一態様は、メッセージを送信する送信先の電話番号の送信先に対応する通信端末に対して、前記電話番号の契約者が前記メッセージを送信する宛先のユーザであるかを認証する認証方法を指定してもらうための候補を送信する送信部と、前記候補から指定された認証方法に基づくユーザ認証が行われた結果に応じて、前記メッセージを送信可否の判定を行うための制御をする制御部とを有する情報処理装置である。

また、本発明の一態様は、コンピュータにより実行される情報処理方法であって、メッセージを送信する送信先の電話番号の送信先に対応する通信端末に対して、前記電話番号の契約者が前記メッセージを送信する宛先のユーザであるかを認証する認証方法を指定してもらうための候補を送信し、前記候補から指定された認証方法に基づくユーザ認証が行われた結果に応じて、前記メッセージを送信可否の判定を行うための制御をすることを含む情報処理方法である。

以上説明したように、この発明によれば、認証方法を指定してもらうための候補を通信端末に送信し、指定された認証方法に基づくユーザ認証が行われた結果に応じて、メッセージの送信可否の判定を行うようにした。これにより、宛先とされたユーザ以外にメッセージが届いてしまうことを抑制することができる。

この発明の一実施形態によるメッセージ配信システムＳの構成を示す概略ブロック図である。 配信サーバ１の機能を説明する概略機能ブロック図である。 認証方法の選択肢が表示された場合の表示画面の例を示す図である。 選択された認証方法に基づいて本人確認において本人であることの確認がとれた場合の表示画面の例を示す図である。 クレジットカードの有効期限の到来に応じてクレジットカードを更新する案内をメッセージとして送信する場合に活用した例の表示画面を示す。 所定口座から引き落とされる金額を案内するためのメッセージを配信サーバ１から送信する場合に活用した例の表示画面を示す。 本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。

以下、本発明の一実施形態による情報処理装置を用いたメッセージ配信システムについて図面を参照して説明する。
図１は、この発明の一実施形態によるメッセージ配信システムＳの構成を示す概略ブロック図である。
メッセージ配信システムＳは、配信サーバ１、企業サーバ２、通信事業者サーバ３（３ａ、３ｂ）、通信端末４、署名検証サーバ５を含む。

配信サーバ１は、通信端末４に対するメッセージを通信事業者サーバ３を介して送信をする。
配信サーバ１は、企業サーバ２の企業からメッセージの送信依頼を受け付け通信事業者サーバ３を介して通信端末４にメッセージを送信するサービスを提供する事業者が管理する情報処理装置である。配信サーバ１を管理する事業者は、企業サーバ２の企業と同じであってもよい。配信サーバ１は、企業サーバ２によって配信が依頼されたメッセージを送信するための制御を行う。配信サーバ１は、企業サーバ２及び通信事業者サーバ３との間で、無線通信又は有線通信をする。

企業サーバ２は、送信先ユーザに対するメッセージの配信をメッセージ配信システムＳに依頼する依頼者が管理するサーバ装置である。依頼者は、例えば、送信先ユーザに対して情報を提供する企業や団体等（例えば、銀行、保険会社等）である。企業サーバ２は、配信サーバ１との間で、無線通信又は有線通信をする。

通信事業者サーバ３（３ａ，３ｂ）は、通信事業者によって管理されるサーバ装置である。通信事業者は、例えば、自らが保有又は運用する通信回線を用いた、電話番号を利用した通信サービスを通信端末４に対して提供するＭＮＯ（Mobile Network Operator、移動体通信事業者）である。通信事業者サーバ３は、通信端末４を利用する契約を締結したユーザとの契約に関するキャリア契約情報を記憶部に記憶している。
キャリア契約情報は、例えば、ユーザの電話番号、氏名、住所、生年月日、年齢等が含まれる。また、キャリア契約情報は、通信事業者と契約ユーザとが契約をしている契約期間を含んでもよい。また、キャリア契約情報は、ユーザが利用するメッセージングサービス等のサービスに対して登録された、当該ユーザに関する顧客情報であってもよい。通信事業者サーバ３は、配信サーバ１及び通信端末４との間で、無線通信又は有線通信をする。
ここでは、通信事業者が複数ある場合には、通信事業者サーバ３も通信事業者毎に設けられる。通信事業者サーバ３ａは、第１通信事業者によって管理され、通信事業者サーバ３ｂは、第２通信事業者によって管理される。以下、特に通信事業者サーバを識別しない場合には、通信事業者サーバ３と称する。

通信端末４は、例えばスマートフォン、タブレット端末、パーソナルコンピュータ等のうちいずれかの端末装置である。
通信端末４は、ユーザによって、通信事業者サーバ３の通信事業者と、通信端末４を用いた通信サービスを利用するための契約がなされる。通信端末４は、契約をしている通信事業者が提供する通信サービスを用いて通信をすることが可能である。通信端末４には電話番号が割り当てられており、この電話番号を送信先とした通信を行う機能を有する。
通信端末４は、情報を表示する液晶ディスプレイ等の表示部と、ユーザによる操作を受け付けるタッチパネル等の操作部とを有する。通信端末４は、通信事業者サーバ３を通信相手とし、無線通信又は有線通信をする。ユーザは、例えば生活者である。

署名検証サーバ５は、例えば、Ｊ-ＬＩＳ（地方公共団体情報システム機構）によって運営される公的個人認証サービスを提供するサーバ装置である。

図２は、配信サーバ１の機能を説明する概略機能ブロック図である。
配信サーバ１は、通信部１１、記憶部１２、制御部１３を有する。
通信部１１は、企業サーバ２、通信事業者サーバ３、署名検証サーバ５と通信を行う。

記憶部１２は、各種情報を記憶する。
例えば、記憶部１２は、照合情報を記憶する。照合情報は、本人確認を行う際の基準となる正解情報である。照合情報は、例えばユーザに関する情報であるユーザ情報を用いることができ、例えば、電話番号、アカウントＩＤ、氏名、住所、生年月日、性別等である。
電話番号は、通信事業者サーバ３の通信事業者とユーザとが通信端末４を利用する契約を締結する際に利用する対象の電話番号として定められた番号である。
アカウントＩＤは、ＲＣＳによるメッセージ配信サービスを用いたアプリケーションソフトウェアを利用するユーザ（生活者）に対して割り当てられた識別情報である。
記憶部１２は、照合情報を記憶することができるが、この照合情報は企業サーバ２に記憶するようにしてもよい。また、照合情報は、配信サーバ１と企業サーバ２とは別のサーバに記憶されてもよい。照合情報が配信サーバ１以外に記憶される場合、記憶部１２は、照合情報を記憶していなくてもよい。

記憶部１２は、記憶媒体、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、フラッシュメモリ、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ ｒｅａｄ／ｗｒｉｔｅ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、またはこれらの記憶媒体の任意の組み合わせによって構成される。
この記憶部１２は、例えば、不揮発性メモリを用いることができる。

制御部１３は、データ処理部１３１、メッセージ制御部１３２、照合部１３３を含む。
制御部１３は、例えばＣＰＵ（Central Processing Unit）等のプロセッサであり、記憶部１２に記憶されたプログラムを実行することにより、通信部１１、データ処理部１３１、メッセージ制御部１３２及び照合部１３３として機能する。制御部１３の機能の少なくとも一部は電気回路によって実行されてもよい。また、制御部１３の機能の少なくとも一部は、制御部１３がネットワーク経由で実行されるプログラムを実行することによって実現されてもよい。

データ処理部１３１は、各種データ処理を行う。例えばデータ処理部１３１は、企業サーバ２から受信したユーザ情報を記憶部１２に書き込む。ユーザ情報が記憶部１２に書き込まれることで、このユーザ情報を照合情報として用いることが可能となる。

メッセージ制御部１３２は、企業サーバ２からメッセージの送信依頼を受信すると、各種メッセージを生成し、通信部１１によって、通信事業者サーバ３を介して通信端末４にメッセージを送信する。
メッセージには、通信端末４に通知する内容が含まれる。通知する内容には、例えば、テキスト、イラストなどの図や写真を含む静止画像や動画像、及び音などのデータが含まれる。メッセージを送信するにあたり、企業サーバ２は、配信サーバ１に対してメッセージの送信要求を送信することで、配信サーバ１から通信事業者サーバ３を介して、通信端末４にメッセージを送信することができる。

また、メッセージ制御部１３２は、メッセージを送信する送信先の電話番号に対応する通信端末に対して、電話番号の契約者がメッセージを送信する宛先のユーザであるかを認証する認証方法を複数の中から指定してもらうための候補を含むメッセージを生成し、通信部１１から送信させる。ここで生成されるメッセージは、複数の認証方式の中からいずれかを指定してもらうための候補を含むメッセージであってもよいが、いずれかの単一の認証方式による認証を開始することを説明するメッセージであってもよいし、いずれかの単一の認証方式を開始してよいか否かを確認するためのメッセージであってもよい。

ここで、認証方法の候補は、例えば、公的個人認証、オンライン個人認証、キャリア認証、顧客マスタ認証等がある。
公的個人認証は、公的な証明書である個人カードを用いて本人確認を行う認証方法である。
より具体的には、公的個人認証は、ＪＰＫＩ（公的個人認証サービス）を利用した認証方法である。この公的個人認証では、個人カードを用いる。個人カードは、例えば、個人情報を記憶可能なＩＣ（integrated circuit card）カードである。個人カードとして、より具体的には、マイナンバーカードである。
公的個人認証を行う場合、電子署名を利用するためのパスワードをユーザに入力してもらい、マイナンバーカードを通信端末４によって読み取らせることで、署名検証サーバ５において公的個人認証の処理が行われ、有効性の確認が取れた場合に、ユーザの氏名、住所、生年月日、性別等の基本４情報を得ることができる。また、マイナンバーカードにおいて用いられる電子証明書のシリアル番号やその代替情報を利用して、その有効性を確認することで本人確認をするようにしてもよい。

オンライン個人認証は、個人カードとは異なる情報であって少なくとも本人の容貌（例えば、顔）の画像を含む情報に基づいてオンラインによって本人確認を行う認証方法である。オンライン個人認証は、「その他の公的書類を用いたオンライン身元確認」とも称する。また、オンライン個人認証を行う技術は、ｅＫＹＣ（electronic Know Your Customer）であってもよい。また、オンライン個人認証では、上述したマイナンバーカードを用いて、ＩＣチップに埋め込まれている情報（基本４情報）を得るようにしてもよい。

キャリア認証は、電話番号を利用した通信サービスを提供する通信端末の通信事業者と契約ユーザとの契約に関するキャリア契約情報を用いて本人確認を行う認証方法である。

顧客マスタ認証は、メッセージの送信元である企業によって管理される顧客マスタを用いて本人確認を行う認証方法である。顧客マスタ認証は、「登録ＩＤを用いた認証」とも称する場合がある。

メッセージ制御部１３２は、重要な通知内容を含むメッセージを通信端末４に送信する前に、本人確認を促すためのメッセージを生成して通信端末４に送信する。そして、メッセージ制御部１３２は、本人確認が行われ、本人であることの確認が取れた後、重要な通知内容を含むメッセージを通信端末４に送信する。ここでは、メッセージ制御部１３２は、本人確認を促すためのメッセージに、認証方法の候補から選択可能な選択肢を含むようにしてメッセージを生成する。
ここで、認証方法の候補が複数ある場合、複数の候補の中からユーザによって候補を示す選択肢を指定する操作入力をしてもらうことができる。これにより、ユーザは、候補の中から自分が実施しやすい認証方法を指定することができ、本人確認の要求があった場合でも、対応がしやすくなる。

照合部１３３は、選択肢から選択された認証方法に基づくユーザ認証が行われた結果に 応じて、メッセージの送信可否の判定を行う。
照合部１３３は、照合情報と認証情報とを照合し、確認条件を満たすか否かを判定することで、メッセージの送信可否を判定することができる。認証情報は、通信端末４のユーザがメッセージを送信する宛先のユーザであるか否かの本人確認をするために、ユーザの操作入力に応じて得られるユーザに関する情報である。
ここで確認条件は、例えば、照合情報に含まれる項目のうち氏名、住所、生年月日、性別等のいずれかの所定項目の内容が、認証情報に含まれる項目のうち、当該所定項目の内容と一致することであってもよい。
照合部１３３は、確認条件を満たすと判定した場合には、本人確認が取れたと判定することができる。すなわち、メッセージを送信する送信先の電話番号の契約者と、メッセージを送信する宛先のユーザとが一致し、本人であることが確認できたと見なすことができる。
この照合は、配信サーバ１が行う場合もあるが、企業サーバ２または通信事業者サーバ３が照合を行うようにしてもよい。この場合、制御部１３は、選択肢から選択された認証方法に基づくユーザ認証が行われた結果に応じて、メッセージを送信可否の判定を行うための制御をする。

ここで、公的個人認証を用いて照合を行う場合、認証情報は、例えば、公的個人認証によって得られるユーザの個人情報が用いられる。個人情報は、例えば、ユーザの氏名、住所、生年月日、性別の４つの項目が用いられる。この場合の照合情報は、配信サーバ１の記憶部１２に記憶されたユーザ情報または企業サーバ２のデータベースに記憶されたユーザ情報を用いることができる。

顧客マスタ認証（登録ＩＤを用いた認証）を用いて照合を行う場合、認証情報は、例えば、通信端末４を介してユーザから入力される情報が用いられる。この場合の認証情報は、例えば、確認したい対象のユーザのみ知り得る情報を用いる。より具体的には、ユーザに対して発行される認証コードを用いる。認証コードは、ＲＣＳアプリとは別のアプリケーションソフトウェアや、電子メール等を介してユーザに通知される。ＲＣＳアプリとは別の経路を利用して認証コードをユーザに通知するため、メッセージの送信先であるユーザとは別のユーザは、認証コードを知ることができない。認証コードは、１つまたは複数の数字や文字が含まれる情報である。また、認証情報は、ユーザの郵便番号、住所、氏名（カナ）、生年月日であってもよい。

顧客マスタ認証を用いて照合を行う場合、照合情報は、企業サーバ２に記憶されたユーザ情報（顧客マスタ）または配信サーバ１に記憶されたユーザ情報（顧客マスタ）を用いる。企業サーバ２の企業は、顧客に顧客登録してもらうことで、顧客に関する情報（氏名、住所、生年月日、性別、電話番号、電子メールアドレス等）を顧客マスタとしてデータベースにユーザ情報として登録している。例えば、企業が銀行である場合には、口座開設の際にユーザの情報を登録してもらい、顧客マスタに記憶することができる。企業が保険会社である場合、ユーザが保険に加入する際に、ユーザの情報を登録してもらい、顧客マスタに登録することができる。認証情報として認証コードが用いられる場合、認証コードが発行されたことに応じて、認証コードが顧客マスタに記憶される。
配信サーバ１に記憶される顧客マスタは、企業サーバ２からユーザ情報を取得し、記憶部１２に記憶されることで顧客マスタとして用いることができる。

顧客マスタ認証では、メッセージの送信元の企業が、自社が参照可能な顧客マスタと、ユーザから入力された情報とを利用し、ユーザの本人確認を行う。
ここで、顧客マスタ認証においては、顧客マスタに登録された情報を用いるが、ユーザ登録の際に登録された個人情報であってもよいし、確認したい対象のユーザのみ知り得る認証情報であってもよい。

キャリア認証を用いて照合を行う場合、認証情報は、キャリアにおける各種サービスをユーザに提供するためにユーザ毎に発行されたアカウント情報を用いる。アカウント情報としては、例えば、ユーザＩＤとパスワードである。ユーザＩＤは、電話番号を用いられる場合があってもよい。
キャリア認証を用いて照合を行う場合、照合情報は、通信事業者サーバ３を運営する通信事業者が管理するキャリア契約情報が用いられる。

オンライン個人認証を用いて照合を行う場合、認証情報は、例えば、自動車運転免許証や、健康保険証等のような公的書類に基づく情報を用いる。また、オンライン個人認証では、ユーザの顔を撮影したカメラ画像や、ユーザの生体情報（指紋、虹彩等）を認証情報として用いるようにしてもよい。
オンライン個人認証を用いて照合を行う場合、照合情報は、顧客マスタに記憶された情報を用いる。

図３は、通信端末４の表示画面に情報が表示された場合の一例を示す図である。図３における表示画面は、ＲＣＳに係るアプリケーションプログラム（ＲＣＳアプリ）が通信端末４においてインストールされた、ＲＣＳアプリが実行された場合のメッセージ表示画面の一例を示す。

図３Ａは、認証方法の選択肢が表示された場合の表示画面の例を示す図である。
通信端末４の表示画面においては、企業サーバ２から依頼されたメッセージが表示される前に、本人確認を促すメッセージ（符号Ｍ０１）が表示されるとともに、認証方法を選択する選択肢（Ｍ０２）が表示される。選択肢は、少なくとも１つ表示される。この図の例では、４つの選択肢が表示された場合が図示されている。
ユーザは、この選択肢のなかから認証方法を選び、希望する認証方式の選択肢を画面上においてタップ（操作入力）する。これにより、選択肢のなかから認証方式を選択することができる。
この画面においては、４つの選択肢が表示される場合について図示されているが、選択肢が１つのみの場合であってもよいし、選択肢が４つ以外の複数であってもよい。

図３Ｂは、選択された認証方法に基づいて本人確認において本人であることの確認がとれた場合の表示画面の例を示す図である。
例えば、ユーザによって選択肢のうち「マイナンバー認証を行う」が選択されると、その選択された選択肢が表示され（符号Ｍ１１）、マイナンバーカードを用いた公的個人認証が行われる。その上で、本人であることの確認が取れた場合には、通信端末４の表示画面に、本人確認が取れたことを示すメッセージである「本人確認が完了しました。」という文字列が表示される（符号Ｍ１２）。そして、送信要求されていたメッセージが表示される（符号Ｍ１３）。送信要求されていたメッセージとしては、例えば「今月の○○サービスの利用料は、○○円です。」のような文字列が表示される。この送信要求されたメッセージは、メッセージの送信先として設定された宛先のユーザ自身に閲覧して欲しいメッセージのように、重要度が高い内容であっても、本人確認を行った上で表示される。このため、送信先のユーザであることを確認できた上で、メッセージが送信され、表示画面に表示される。これにより、ユーザはメッセージを閲覧することができる。

図４は、通信端末４の表示画面に情報が表示された場合の一例を示す図である。
図４Ａは、クレジットカードの有効期限の到来に応じてクレジットカードを更新する案内をメッセージとして送信する場合に活用した例の表示画面を示す。
クレジットカードを更新する場合には、更新期間が到来するまでの間に、ユーザの氏名や住所が変更される場合がある。そのため、更新後のクレジットカードを発行する前に、ユーザに対して、ユーザに関する情報に変更がないか確認しておくことが望ましい。そこで、クレジットカードの更新前に、ＲＣＳアプリを利用してユーザに更新に関する案内のメッセージを送信する。ユーザの通信端末４の画面には、クレジットカードの更新に関する案内のメッセージが表示されるとともに（符号Ｍ２１）、住所変更があった場合に、住所を変更する手続を促すためのメッセージが表示される（符号Ｍ２２）。
また、認証方法を選択する選択肢についても表示画面に表示される（符号Ｍ２４）。ここでは、クレジットカードの更新を行うにあたり、本人確認を行うとともに、住所変更等の手続も併せて行うことが可能である。

ここで、マイナンバーカードを用いて公的個人認証を行い、本人確認において本人であることが確認できた場合には、最新の基本４情報（基本４情報：住所、氏名、生年月日、性別）を得ることができる。そのため、選択肢のうち「公的個人認証によりお手続き」が選択された場合には、公的個人認証によって得られた情報をクレジットカードの発行会社に伝えることで、クレジットカードの発行会社に記憶されたユーザ情報をマイナンバーカードに登録された内容に更新することができる。一方、他の選択肢による認証方法が選択された場合には、本人確認を行うことが可能であるが、仮に住所に変更があった場合には、変更内容をユーザ自身に入力してもらう必要がある。そのため、公的個人認証を選択した場合には、クレジットカードの発行会社に対する住所変更の手続きを簡単に行うことができる旨の案内をするメッセージも含めて表示するようにしてもよい（符号Ｍ２３）。
このように、選択する認証方法によっては、その後の手続についてメリットが異なる場合があるため、選択された選択肢に応じて得られるメリットともに選択肢を表示するようにしてもよい。これにより、ユーザは、いずれの選択肢を選択するかの検討をしやすくなるメリットがある。
なお、本人確認を行うとともにサービスの提供を行う場合として、クレジットカードの更新のみではなく、生命保険会社における控除証明書の送付、生命保険会社からの年に１回等の通知、銀行または証券会社からの現況確認のための通知、公共料金や各種税納付等の公共機関からの通知等に活用するようにしてもよい。

図４Ｂは、クレジットカードによって支払いがなされたことに応じて所定口座から引き落とされる金額を案内するためのメッセージを配信サーバ１から送信する場合に活用した例の表示画面を示す。
クレジットカードの利用に応じた、口座からの引き落とし予定日については、あまり重要度が高くないため、本人確認を行うことなくメッセージとして送信され、表示画面に表示される（符号Ｍ３１）。引き落とし金額（利用金額）については、重要性が高いため、本人確認を行った場合に参照可能であることを示すとともに、本人確認を促すメッセージが表示される（符号Ｍ３２）。そして、本人確認を行う認証方法の選択肢が表示される（符号Ｍ３３）。ここでは、選択肢として、「マイページよりご確認」と「公的個人認証で確認」の２つの選択肢が表示されている。

そして、「公的個人認証で確認」の選択肢を示すボタンがユーザによってタップされると、公的個人認証を行うための処理が実行される。そして、公的個人認証によって本人確認が完了すると（本人であることの確認が取れると）、「本人確認が完了しました。」とのメッセージととともに、利用金額を参照することができるＵＲＬ（Uniform Resource Locator）がメッセージとして表示される。これにより、ユーザは、ＵＲＬをタップすることで、ＵＲＬが示すサイトにアクセスすることができ、利用金額を確認することができる。

また、マイナンバーカードから得られる情報をクレジットカードの発行会社に提供することに同意した場合には、基本４情報等がクレジットカードの発行会社に提供され、クレジットカードの発行会社が管理するユーザに関する情報を最新の情報に更新することができることを案内するメッセージも表示される（符号Ｍ３５）。また、このような案内をするメッセージが表示されるとともに、同意可否の選択肢が表示される（符号Ｍ３７）。
「基本４情報のお届けに同意する」に対してタップ操作がなされると、基本４情報をクレジットカードの発行会社に提供することについて同意することが配信サーバ１に送信され、「同意しない」に対してタップ操作がなされると、基本４情報をクレジットカードの発行会社に提供することを拒否することが配信サーバ１に送信される。
なお、利用金額を確認するためのサイトのサムネイル画像（符号Ｍ３６）も表示することができ、符号Ｍ３４におけるメッセージ中のＵＲＬではなく、このサムネイル画像をタップしても、利用金額を確認可能なサイトに遷移することができる。

［メッセージ配信方法のシーケンス］
以下、メッセージ配信方法のシーケンスについて説明する。以下の実施形態においては、企業サーバ２と配信サーバ１とが別の装置であって、異なる企業によって運用される場合について説明するが、配信サーバ１の機能が搭載された企業サーバ２を、企業が運用するようにしてもよい。この場合、企業サーバ２の企業は、配信サーバ１の事業者を介することなく、通信事業者サーバ３と通信し、メッセージを送信することができる。
また、企業サーバ２の機能が搭載された配信サーバ１を、配信サーバ１の事業者が運用するようにしてもよい。この場合、配信サーバ１の事業者は、外部の企業からの依頼を受けていなくても、配信サーバ１の事業者の意向に応じてメッセージの配信を行うことができる。

［第１実施形態：公的個人認証を用いる場合］
図５Ａ、図５Ｂは、本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。
この実施形態では、署名検証サーバ５における公的個人認証を利用して得られる個人情報と照合情報とを用いて本人確認をする場合について説明する。
企業サーバ２は、ユーザにメッセージを送信する際に利用する送信データを生成する。
この送信データは、送信するメッセージ本文を生成するために必要な情報と、ユーザに関する情報が含まれる。
企業サーバ２は、送信データを生成するにあたり、メッセージ本文について、企業サーバ２に記憶された情報に基づいて生成する。メッセージ本文は、例えば、あるサービスを利用したことに応じてユーザに対して費用を請求する請求金額を知らせる内容であり、通信端末４の表示画面等において出力される内容である。より具体的には、「今月の○○サービスの利用料は、○○円です。」等の内容である。
企業サーバ２は、送信データを生成するにあたり、ユーザに関する情報について、企業サーバ２に記憶されたユーザ情報を読み出す。
ユーザ情報は、例えば、電話番号、アカウントＩＤ、氏名、住所、生年月日、性別等を含む。ユーザ情報に含まれる少なくとも一部の情報を、本人確認を行う上で照合に用いる照合情報として利用することができる。

また、ここでは、メッセージ本文は必須ではないがユーザにメッセージを送信する場合には、伝える内容として一般的には含まれる。
また、送信データには、属性情報を含むようにしても良い。

企業サーバ２は、送信先ユーザの電話番号と、照合情報と、送信先ユーザに対して送信するメッセージ本文を生成するために必要な情報とを含む配信依頼を、配信サーバ１に送信する（ステップＳ１１０１）。配信サーバ１の通信部１１は、企業サーバ２から、電話番号、照合情報及びメッセージ本文を生成するために必要な情報を含む配信依頼を受信する。

ここでは、企業サーバ２からメッセージを送信対象の人数が１人である場合について説明するが、複数のユーザにそれぞれ送信することもできる。

配信サーバ１は、企業サーバ２から送信された送信データを受信し、データ処理を行う（ステップＳ１２０１）。配信サーバ１は、データ処理として、送信データに含まれる照合情報の抽出をし、送信データに含まれる、メッセージ本文を生成するために必要な情報の抽出をする。その後、配信サーバ１のデータ処理部１３１は、抽出された照合情報を記憶部１２に書き込む（ステップＳ１２０２）。
ここで記憶部１２に記憶される情報は、例えば、電話番号、アカウントＩＤ、氏名、生年月日、住所、性別である。このアカウントＩＤは、企業サーバ２において付与された番号であってもよいし、配信サーバ１の事業者によって付与された番号であってもよい。

配信サーバ１は、抽出されたメッセージ本文を生成するために必要な情報と、照合情報に含まれる電話番号とに基づいてメッセージを生成する（ステップＳ１２０３）。メッセージは、送信先を示す電話番号と、メッセージ本文と、管理情報とを含むデータである。配信サーバ１のメッセージ制御部１３２は、企業サーバ２から受信したメッセージ本文に対して、本人認証を促すための文章や、本人認証を行う認証方法を選択するための選択肢を付加する。
付加される選択肢は、任意の選択肢であってもよいが、企業サーバ２の企業、配信サーバ１の事業者、通信事業者サーバ３のキャリア等のうちいずれかによって決められていてもよいし、企業サーバ２から配信サーバ１に送信される送信データに予め含まれていてもよい。

配信サーバ１は、本人確認を要求する内容を含むメッセージを生成すると、ＲＣＳを利用し、電話番号を送信先として送信する（ステップＳ１２０４）。ここでは、配信サーバ１は、複数あるキャリアのうち、メッセージに設定された電話番号に対応するキャリアの通信事業者サーバ３を介して通信端末４に送信する。

通信端末４は、配信サーバ１から通信事業者サーバ３を介し、本人確認を促す内容を含むメッセージを受信する（ステップＳ１４０１）。ここで、通信端末４は、ＲＣＳに係るアプリケーションプログラム（ＲＣＳアプリ）がインストールされており、配信サーバ１からＲＣＳによって送信されるメッセージを受信できる。

ここで通信端末４は、受信したメッセージに認証方法を選択する選択肢も含まれている場合には、その選択肢についても受信する（ステップＳ１４０２）。そして通信端末４は、本人確認を促す内容とともに本人確認をする認証方法を選択する選択肢を表示画面に表示する。本人確認を促すメッセージとして、例えば、「重要なお知らせがありますので、本人確認をお願い致します。」という文字列が画面に表示されるとともに、「公的個人認証を行う」、「キャリア認証を行う」、「登録ＩＤを用いた認証を行う」、「その他の公的書類を用いたオンライン身元確認を行う」の４つの選択肢が表示される。この選択肢の数や組み合わせについては、これに限られるものではなく、上述したように、企業サーバ２の企業、配信サーバ１の事業者、通信事業者サーバ３のキャリア等のうちいずれかによって決められていてもよいし、企業サーバ２から配信サーバ１に送信される送信データに含まれているものであってもよい。また、ここでは、選択肢が複数の場合であるが、選択肢が１つの場合であってもよい。

通信端末４は、通信端末４を利用している契約ユーザによって操作入力される、本人確認をする認証方法を選択する選択肢に対する操作入力を受け付ける（ステップＳ１４０３）。ユーザによってタッチパネル上の「公的個人認証を行う」のボタンに対してタップされると、通信端末４は、「公的個人認証を行う」の操作入力を受け付け、公的個人認証を行うためのアプリケーションソフトウェア（以下、公的個人認証アプリ）を実行し、公的個人認証を行うための画面を表示する（ステップＳ１４０４）。ここでは、「パスワードを入力し、個人カードを端末に読み取らせてください」等のように、パスワードの入力と個人カードの読み取りを促す文字列が表示される。

ユーザによってパスワードが入力され、通信端末４のリーダに個人カードが近づけられると、通信端末４は、パスワードの入力を受け付け、個人カードに対してパスワード送信する。入力されたパスワードが個人カードに記憶されたパスワードと一致する場合（ステップＳ１４０６－ＯＫ）、個人カードは、個人カードに記憶された電子証明書を通信端末４に出力する。通信端末４は、個人カードから出力される電子証明書を受信する。
一方、入力されたパスワードが個人カードに記憶されたパスワードと一致しない場合（ステップＳ１４０６－ＮＧ）、個人カードは、パスワードが一致しないことを表す応答信号を通信端末４に出力する。通信端末４は、この応答信号を受信すると、表示画面に「パスワードが一致しませんでした。パスワードを入力し直してください」等の文字列を表示し、ステップＳ１４０５に移行する。なお、パスワードを入力しなおしても一致しない回数が一定数に到達した場合には、個人カードの利用が停止（ロック）される場合もある。

ここでは通信端末４が公的個人認証処理を行う場合、公的個人認証アプリを実行する場合について説明したが、アプリケーションソフトウェアを実行するのではなく、ブラウザによって公的個人認証サービスを提供するサイトにアクセスし、パスワードの入力や個人カードの読み取り等を行うことで、公的個人認証処理を行うようにしてもよい。また、公的個人認証アプリとは別のアプリケーションソフトウェアを実行し、パスワードの入力の受け付けや、パスワードの一致判定を行い、判定結果を公的個人認証アプリに戻すようにしてもよい。
また、ここでは通信端末４が個人カードと通信を行い、電子証明書を取得する場合について説明したが、個人カードに記憶された情報を通信端末４に設けられたメモリに記憶させておき、個人カードを読み取るのではなく、このメモリにアクセスするようにしてもよい。例えば、通信端末４は、ユーザからパスワードが入力されると、内部のメモリを参照し、パスワードが一致する場合には、電子証明書をメモリから読み出すようにしてもよい。

また、パスワードを用いた認証の代わりに、生体認証を行うようにしてもよい。生体認証としては、例えば、指紋認証、顔認証、虹彩認証等であってもよい。

通信端末４は、入力されたパスワードが個人カードに記憶されたパスワードと一致することで個人カードから電子証明書を受信すると、受信した電子証明書を配信サーバ１に送信する（ステップＳ１４０７）。ここでは、通信端末４は、電子証明書を送信するだけでなく、この電子証明書がどのユーザの電子証明書であるかを識別可能な情報を関連付け情報（紐付けキー）として、電子証明書とともに送信する。紐付けキーとしては、例えば、通信端末４に割り当てられた電話番号や、公的個人認証アプリにおいて割り当てられたアカウントＩＤであってもよいし、トークン情報（例えばワンタイムパスワード等）であってもよい。ただし、電子証明書の送信元がいずれの通信端末４であるかを識別できるのであれば、必ずしも紐付けキーを送信しなくてもよい。

配信サーバ１は、通信端末４から電子証明書と紐付けキーとを受信すると、電子証明書と紐付けキーとを署名検証サーバ５に送信（中継）する（ステップＳ１２０５）。
ここでは、電子証明書と紐付けキーとについて、通信端末４から配信サーバ１に送信し、配信サーバ１が署名検証サーバ５に送信する場合について説明したが、配信サーバ１による中継を行わず、通信端末４が署名検証サーバ５に電子証明書と紐付けキーとを送信するようにしてもよい。配信サーバ１による中継を行わない場合、通信端末４は、署名検証サーバ５に電子証明書と紐付けキーとともに、認証結果の通知先が配信サーバ１であることを示す情報も送信する。

署名検証サーバ５は、配信サーバ１から電子証明書と紐付けキーとを受信すると、電子証明書が有効であるか否かに基づく認証処理を行う（ステップＳ１５０１）。署名検証サーバ５は、電子証明書が有効であると判定した場合には（ステップＳ１５０２－ＯＫ）、電子証明書に対応する個人情報を記憶部から読み出し、個人情報と紐付けキーとを配信サーバ１に送信し、認証処理において電子証明書が無効であると判定した場合には（ステップＳ１５０２－ＮＧ）、無効である旨の応答信号を配信サーバ１に送信する。ここでは、署名検証サーバ５から配信サーバ１に確認結果や基本４情報を送信する場合について説明するが、配信サーバ１から署名検証サーバ５へ基本４情報を取得しにいってもよい。
ここで送信される個人情報は例えば、ユーザの氏名、住所、生年月日、性別（基本４情報）を含む。

配信サーバ１は、電子証明書が無効である旨の応答信号を署名検証サーバ５から受信すると、電子証明書が無効であることを表すメッセージを生成し（ステップＳ１２０６）、生成されたメッセージを通信端末４に対してＲＣＳによって送信する（ステップＳ１２０７）。ここで生成されるメッセージは、電子証明書が無効であることを表す内容を含むようにしてもよいし、電子証明書が無効であることと再度認証をしてもらうように促す内容とを含むようにしてもよい。
通信端末４は、配信サーバ１からメッセージを受信すると（ステップＳ１４０８）、受信したメッセージを表示画面に表示する。例えば表示画面には、「本人確認ができませんでした。再度認証を行ってください」等の文字列が表示される。

配信サーバ１は、電子証明書が有効であると判定されたことに応じて、署名検証サーバ５から公的個人認証の結果として、個人情報（基本４情報）と紐付けキーとを受信すると（ステップＳ１２０８）、ステップＳ１２０２において記憶部１２に記憶された照合情報と、受信した個人情報とが対応関係にあるか照合をする（ステップＳ１２０９）。ここでは、記憶部１２に複数のユーザについての照合情報が記憶されているが、今回署名検証サーバ５から受信した紐付けキーに基づいて、記憶部１２から照合する対象の照合情報を読み出し、読み出した照合情報と個人情報とを照合することができる。
また、個人カードがマイナンバーカードである場合、署名検証サーバ５から得られる情報（基本４情報：住所、氏名、生年月日、性別）は、最新の情報である。すなわち、引っ越しがあった場合であっても、ユーザが地方自治体に対して引っ越しの手続（転出届、転入届等）を行うことで、引っ越しされた後の新しい住所が署名検証サーバ５に登録される。そのため、配信サーバ１は、最新の住所を得ることができる。また、ユーザの氏名に変更があった場合、ユーザが地方自治体に対して氏名に関する変更の手続きを行うことで、変更後の氏名が署名検証サーバ５に登録される。そのため、配信サーバ１は、最新の氏名を得ることができる。

配信サーバ１は、照合情報と個人情報とを照合し、確認条件を満たすか否かを判定する（ステップＳ１２１０）。
ここで確認条件としては、例えば、照合情報に含まれる項目のうち氏名、住所、生年月日、性別等のいずれかの所定項目の内容が、個人情報に含まれる項目のうち、当該所定項目の内容と一致することであってもよい。例えば、４つの項目についてそれぞれ一致する場合であってもよいし、一部の項目が一致することであってもよい。一部の項目としては、例えば、生年月日と氏名であってもよい。住所は引っ越し等があったことにより、企業サーバ２において記憶された住所と、署名検証サーバ５において記憶された住所が一致していない状態となる場合があるからである。また、氏名については、姓名の全てを条件として用いてもよいし、姓名のうち姓が変更される場合があるため、姓名の一部（例えば名）が一致するか否かを条件として用いてもよい。

配信サーバ１は、照合情報と個人情報とを照合し、確認条件を満たしていないと判定した場合には（ステップＳ１２１０－ＮＧ）、確認条件を満たしていないことを表すメッセージを生成し（ステップＳ１２１１）、生成されたメッセージを通信端末４にＲＣＳによって送信する（ステップＳ１２１２）。ここで生成されるメッセージは、照合情報と個人情報とが合致しないことを表す内容を含むようにしてもよし、照合情報と個人情報とが合致しないことと再度認証をしてもらうように促す内容とを含むようにしてもよい。ここで確認条件を満たしていないと判定された場合に、確認条件を満たしていないことを表すメッセージを配信サーバ１から通信端末４に送信する場合について説明するが、このメッセージを送信しなくてもよい。また、通信端末４は、確認条件を満たしていないことを表すメッセージを表示しなくてもよい。
通信端末４は、配信サーバ１からメッセージを受信すると（ステップＳ１４０９）、受信したメッセージを表示画面に表示する。例えば表示画面には、「メッセージの受け取り人と個人情報とが一致しませんでした。再度認証を行ってください」等の文字列が表示される。ここでは、ステップＳ１４０２において受信した、認証方法の選択肢が複数あり、まだ選択していない選択肢が残っている場合には、残りの選択肢を表示しつつ、選択肢を選択するように促す文字列も表示してもよい。これにより、他の認証方法によって本人確認をやり直すことも可能となる。

また、配信サーバ１は、ステップＳ１２０９における照合をし、確認条件を満たさないと判定されたあと、他の認証方法がユーザによって選択され、その認証方法に基づく主照合を行っても、確認条件を満たさないことが所定の回数まで到達した場合には、メッセージの送信依頼元である企業サーバ２に対して、エラーとして通知するようにしてもよい。ここでいうエラーは、メッセージが未着である（企業サーバ２の企業から指定された送信先のユーザの通信端末には届かなかった）旨の内容であってもよい。
また、配信サーバ１は、ステップＳ１２０７において本人確認を要求する内容を含むメッセージを送信し、一定期間が経過したにもかかわらず、認証方法の選択入力がされない場合や、公的個人認証アプリを用いた認証を行ってもらえない場合に、エラーとして通知するようにしてもよい。ここでいうエラーは、メッセージが未着である（企業サーバ２の企業から指定された送信先のユーザの通信端末には届かなかった）旨の内容であってもよい。

配信サーバ１は、照合情報と個人情報とを照合し、確認条件を満たしていると判定した場合には（ステップＳ１２１０－ＯＫ）、送信データに含まれるメッセージ本文を生成するために必要な情報に基づくメッセージを生成し（ステップＳ１２１３）、生成されたメッセージを当該送信データに含まれる送信先の電話番号を宛先としてＲＣＳによって送信する（ステップＳ１２１４）。ここで生成されるメッセージは、重要度が高い内容を含むものであり、本人確認が取れた場合に表示させる内容を含む。

通信端末４は、ステップＳ１２１４において配信サーバ１からメッセージが送信されると、送信されたメッセージを受信し（ステップＳ１４１０）、受信したメッセージを表示画面に表示する。例えば表示画面には、「今月の○○サービスの利用料は、○円です。」等のメッセージを表す文字列が表示される。

配信サーバ１は、通信端末４に対するメッセージの送信が完了した場合に、送信が完了したことを企業サーバ２に通知するようにしてもよい。また、配信サーバ１は、ステップＳ１２０９において、個人情報の一部を用いて確認条件を満たしていた場合、署名検証サーバ５から送信された個人情報を企業サーバ２に送信するようにしてもよい。これにより、企業サーバ２において、ユーザに関する情報を最新の情報に更新することができる。なお、個人情報を企業サーバ２に送信する場合には、個人情報を企業サーバ２に送信することについて、事前にユーザの同意を得ておくことが望ましい。

［本実施形態の効果］
本実施形態によれば、企業サーバ２に格納されたユーザに関する情報に基づく照合情報と、公的個人認証サービスによって得られた情報とを用いて照合し、確認条件を満たす場合に、送信データに基づくメッセージを送信するようにした。これにより、企業サーバ２の企業が把握しているユーザに関する情報と、通信端末４を利用しているユーザの個人情報が対応関係にある場合には、企業がメッセージの宛先として送信しようとしている電話番号の利用者が、メッセージを届けたい相手であるかの確認がとれた場合に、メッセージを送信することができる。これにより、企業サーバ２の企業から指定された送信先のユーザが通信端末４のユーザ本人ではない場合にはメッセージが送信されないようにすることができ、メッセージが別のユーザに届いてしまうことを防止することができる。

以上説明した第１実施形態においては、署名検証サーバ５を用いる場合について説明したが、個人カードを用いない方法による本人認証を行う場合や、署名検証を行う必要がない本人認証を行う場合については、メッセージ配信システムＳに署名検証サーバ５が含まれていなくてもよい。

［第２実施形態：顧客マスタ認証，照合情報を配信サーバが持つ場合］
図６Ａ、図６Ｂは、本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。
第１実施形態においては、署名検証サーバ５から得られる情報を用いて照合したが、第２実施形態では、顧客マスタとして予め記憶された情報と、ユーザから入力される情報とを用いて本人確認をする点が異なる。
この第２実施形態においては、顧客マスタを記憶するデータベースは、配信サーバ１と企業サーバ２とのいずれに備えられていてもよいが、配信サーバ１に備えられた場合について説明する。
この第２実施形態において、ステップＳ１１０１、ステップＳ１２０１からＳ１２０４、ステップＳ１４０１、ステップＳ１４０２までの処理は、第１実施形態と同じであるので、同一の符号を付し、その説明を省略する。

ステップＳ１４０３Ａにおいて、通信端末４は、ユーザによって入力される、本人確認をする認証方法を選択するための選択肢に対する操作入力を受け付ける（ステップＳ１４０３Ａ）。ユーザによってタッチパネル上の「登録ＩＤを用いた認証」のボタンに対してタップされると、通信端末４は、「登録ＩＤを用いた認証」の操作入力を受け付けることで、認証情報の入力を受け付ける認証画面を表示する（ステップＳ１４０４Ａ）。例えば、「認証情報を入力して下さい」等の認証情報の入力を促すための内容を表す文字列を表示する。

認証情報を入力してもらう機能は、ＲＣＳアプリとは別のアプリケーションソフトウェアによって実現するようにしてもよいし、ブラウザによって実現してもよい。また、対話式メッセンジャーアプリケーションを用いたり、あるいは、ＲＣＳのシナリオ内において完結できるようにＲＣＳのメッセージ内において、「生年月日は？」、「認証コードは？」等のように、認証情報についてユーザに質問をし、ユーザに回答として認証情報を入力してもらうようにしてもよい。質問は、１つでも複数でもよい。質問が複数である場合には、各質問を順次行い、全ての質問にそれぞれ回答してもらってから、回答が正しいかを照合するようにしてもよいし、質問に対する回答が得られる毎に、回答が正しいかを照合するようにしてもよい。ＲＣＳのシナリオとは、ＲＣＳのメッセージ内において、ユーザに対する質問をし、ユーザから入力される回答の入力を受け付けることができるものであって、質問の内容と質問の順序が予め準備されたメッセージである。
ここで、ステップＳ１４０３Ａにおいて「登録ＩＤを用いた認証」のボタンがタップされた後、ステップＳ１４０４Ａの認証画面を表示する場合について説明するが、この認証画面を表示しないようにしてもよい。例えば、「登録ＩＤを用いた認証」のボタンがタップされた後、ＲＣＳアプリが、認証情報を入力するための質問事項を表示し、ユーザから回答として認証情報を入力してもらうようにしてもよい。

ここで、認証情報は、本人確認をする対象のユーザのみ知り得る情報であることが望ましい。認証情報としては、例えば、パスワード、認証コード、郵便番号、生年月日、氏名等の情報のうち、少なくとも１つを用いるようにしてもよい。
パスワードは、ユーザに関する情報を顧客マスタに登録する際にユーザに対して発行されたあるいはユーザから指定してもらった文字列である。

ユーザは、認証情報の入力画面が表示されると、認証情報を入力する（ステップＳ１４０６Ａ）。通信端末４は、回答が入力されると、入力された回答である認証情報と、通信端末４に割り当てられている電話番号とを配信サーバ１に送信する（ステップＳ１４０７Ａ）。

配信サーバ１は、通信端末４から認証情報と電話番号とを受信すると（ステップＳ１２０８）、ステップＳ１２０２において記憶部１２に記憶された照合情報のうち受信した電話番号に対応付けられた照合情報と、受信した認証情報とが対応関係にあるか照合をし（ステップＳ１２０９Ａ）、確認条件を満たすか否かを判定する（ステップＳ１２１０Ａ）。
ここで確認条件としては、照合情報と認証情報とが一致することである。認証情報として、氏名と生年月日が用いられる場合、ユーザから入力された氏名及び生年月日と、照合情報に含まれる氏名及び生年月日がそれぞれ一致するか否かである。
また、認証情報としてパスワードを用いる場合には、ユーザから入力されたパスワードと、照合情報として記憶されているパスワードとが一致することである。また、認証情報として認証コードを用いる場合には、ユーザから入力された認証コードと、別の経路でメッセージの送信先のユーザに対して発行された認証コードとが一致することである。

配信サーバ１は、確認条件を満たしていないと判定した場合には（ステップＳ１２１０Ａ－ＮＧ）、確認条件を満たしていないことを表すメッセージを生成する（ステップＳ１２１１）。その後、第１実施形態のステップＳ１２１２、ステップＳ１４０９と同様の処理が行われる。これにより、通信端末４は、確認条件を満たしていないことを表すメッセージを表示画面に表示する。なお、確認条件を満たしていないと判定された場合に、確認条件を満たしていないことを表すメッセージを配信サーバ１から通信端末４に送信しなくてもよい。また、通信端末４は、確認条件を満たしていないことを表すメッセージを表示しなくてもよい。

配信サーバ１は、確認条件を満たしていると判定した場合には（ステップＳ１２１０Ａ－ＯＫ）には、送信データに含まれるメッセージ本文を生成するために必要な情報に基づくメッセージを生成する（ステップＳ１２１３）。その後、第１実施形態のステップＳ１２１４、ステップＳ１４１０と同様の処理が行われる。これにより、通信端末４は、配信サーバ１から送信されたメッセージを表示する。通信端末４は、メッセージを表示するとともに、確認が完了したこと（確認条件を満たしていること）を表示してもよい。

［本実施形態の効果］
本実施形態によれば、配信サーバ１に顧客マスタとして記憶された照合情報を利用して本人確認を行うことができる。そのため、本人確認を行うにあたり、他の機器と連携しなくても本人確認をすることができる。

［第２実施形態の変形例：顧客マスタ認証，照合情報を企業サーバが持つ場合］
図７Ａ、図７Ｂは、本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。
第２実施形態においては、顧客マスタが配信サーバ１に備えられた場合について説明したが、第２実施形態の変形例では、顧客マスタが企業サーバ２に設けられる点が異なる。企業サーバ２に備えられる顧客マスタは、第２実施形態における配信サーバ１において記憶される顧客マスタと同様である。
この第２実施形態において、企業サーバ２は、配信依頼を配信サーバ１に送信する（ステップＳ１１０１）。このステップＳ１１０１の処理は、第１実施形態と同様である。
配信サーバ１は、企業サーバ２から送信された送信データを受信し、データ処理を行う（ステップＳ１２０１Ａ）。配信サーバ１は、データ処理として、送信データに含まれるメッセージ本文を生成するために使用する情報を抽出する。メッセージ本文を生成するために必要な情報が抽出されると、配信サーバ１は、メッセージを生成し（ステップＳ１２０３）、ＲＣＳを利用し、電話番号を送信先として送信する（ステップＳ１２０４）。このステップＳ１２０３、ステップＳ１２０４の処理は、第１実施形態と同様である。
その後、ステップＳ１４０１からステップＳ１４０７Ａの処理は、第２実施形態と同様である。

配信サーバ１は、通信端末４から電話番号と認証情報を受信すると、電話番号と認証情報を企業サーバ２に送信（中継）する（ステップＳ１２０５Ｂ）。
ここでは、配信サーバ１が、電話番号と認証情報とを通信端末４から受信し、企業サーバ２中継に送信する場合について説明したが、配信サーバ１による中継を行わず、通信端末４が電話番号と認証情報とを企業サーバ２に送信するようにしてもよい。
企業サーバ２は、認証情報を受信すると（ステップＳ１１０２）、企業サーバ２のデータベース（顧客マスタ）に記憶された照合情報のうち受信した電話番号に対応付けられた照合情報と、受信した認証情報とが対応関係にあるかを照合し（ステップＳ１１０３）、確認条件を満たすか否かを判定する（ステップＳ１２０４）。この照合処理と判定処理は、それぞれ、第２実施形態におけるステップＳ１２０９Ａ及びステップＳ１２１０Ａと同様であり、処理の主体が企業サーバ２であることが異なる。

企業サーバ２は、確認条件を満たしていないと判定した場合には（ステップＳ１１０４－ＮＧ）、確認条件を満たしていないことを示す制御信号を配信サーバ１に送信する。
配信サーバ１は、確認条件を満たしていないことを示す制御信号を受信すると、確認条件を満たしていないことを表すメッセージを生成する（ステップＳ１２１１）。その後、第１実施形態のステップＳ１２１２、ステップＳ１４０９と同様の処理が行われる。これにより、通信端末４は、確認条件を満たしていないことを表すメッセージを表示画面に表示する。なお、確認条件を満たしていないと判定された場合に、確認条件を満たしていないことを表すメッセージを配信サーバ１から通信端末４に送信しなくてもよい。また、通信端末４は、確認条件を満たしていないことを表すメッセージを表示しなくてもよい。
企業サーバ２は、確認条件を満たしていると判定した場合には（ステップＳ１１０４－ＯＫ）、確認条件を満たしていることを示す制御信号を配信サーバ１に送信する。
配信サーバ１は、確認条件を満たしていることを示す制御信号を受信すると、送信データに含まれるメッセージ本文を生成するために必要な情報に基づいてメッセージを生成する（ステップＳ１２１３）。その後、第１実施形態のステップＳ１２１４、ステップＳ１４１０と同様の処理が行われる。これにより、通信端末４は、配信サーバ１から送信されたメッセージを表示する。通信端末４は、メッセージを表示するとともに、確認が完了したこと（確認条件を満たしていること）を表示してもよい。

［本実施形態の効果］
本実施形態によれば、企業サーバ２に顧客マスタとして記憶された照合情報を利用して本人確認を行うことができる。そのため、企業サーバ２の外部に顧客マスタを保存せずに本人確認を行うことができる。

［第３実施形態：キャリア認証，フィルインの場合］
図８Ａ、図８Ｂは、本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。
第１実施形態においては、署名検証サーバ５から得られる情報を用いる場合、第２実施形態では、配信サーバ１または企業サーバ２に備えられた顧客マスタを用いて本人確認を行う場合について、説明したが、第３実施形態では、通信事業者が管理する契約者データベースを利用して本人確認を行う場合について説明する。
通信事業者が管理する契約者データベースを利用して本人確認を行う場合、フィルインの場合と、マッチングの場合がある。

フィルインは、配信サーバ１が通信事業者サーバ３に対して対象の電話番号を送信し、通信事業者サーバ３が、契約者データベースに記憶された情報に基づいて、その電話番号に対応するユーザの情報（例えば、ユーザの住所、氏名、生年月日等）を読み出して配信サーバ１に送信する。このようにして、キャリア契約情報の一部を通信事業者サーバ３から配信サーバ１が受信することができ、本人確認を行うことができる。

マッチングは、配信サーバ１に備えられたユーザに関する情報を通信事業者サーバ３に送信し、通信事業者サーバ３において、通信事業者サーバ３が管理する契約者データベースに記憶された情報と、配信サーバ１から送信されたユーザに関する情報とを照合することで、配信サーバ１は照合結果を得ることができ、本人確認を行うことができる。
このように、第３の実施形態においては、配信サーバ１が通信事業者サーバ３から得られる情報が、キャリア契約情報であるか、照合結果であるかにおいて異なる。

この第３実施形態においては、フィルインの場合について説明する。
この第３実施形態において、ステップＳ１１０１からステップＳ１４０２までの処理は、第２実施形態と同様であるので、説明を省略する。
ここで、受信されたメッセージと選択肢が表示画面に表示されると、通信端末４は、通信端末４を利用している契約ユーザによって操作入力される、本人確認をする認証方法を選択する選択肢に対する操作入力を受け付ける（ステップＳ１４０３Ｃ）。ユーザによってタッチパネル上の「キャリア認証を行う」のボタンに対してタップされると、通信端末４は、「キャリア認証を行う」の操作入力を受け付け、通信事業者サーバへ接続し、通信事業者サーバ３から、認証情報の入力を受け付ける認証画面のデータを受信し、受信した認証画面を表示する（ステップＳ１４０４Ｃ）。例えば、「キャリアのアカウント情報を入力して下さい」等の認証情報の入力を促すための内容を表す文字列を表示する。

この「キャリア認証を行う」のボタンがタップされた際や、認証情報の入力を促すための内容を表す文字列が表示された際に、「個人情報を本人確認のため外部サーバに送信してもよいですか？」等の確認画面を表示し、ユーザから同意をする旨の入力操作がなされてから、次の処理に進めるようにしてもよい。また、ユーザがどのキャリアに所属しているかをユーザに選択させてから、次の処理に進めるようにしてもよい。
また、ここで、各キャリアでは、そのキャリアにおける各種サービスを受けるためのアカウント情報がユーザ毎に割り当てられている。アカウント情報としては、例えば、ユーザＩＤとパスワードである。ユーザＩＤは、電話番号を用いられる場合があってもよい。
通信端末４のユーザは、キャリアのアカウント情報としてログインＩＤとパスワードを認証情報として入力する（ステップＳ１４０６Ｃ）。
通信端末４は、入力された認証情報（ログインＩＤとパスワード）を通信事業者サーバ３に送信する（ステップＳ１４０７Ｃ）。

ここで、ステップＳ１４０４ＣからステップＳ１４０７Ｃについては、ＲＣＳアプリとは別のアプリケーションソフトウェアによって実現するようにしてもよいし、ブラウザによって実現してもよい。キャリア認証を行う場合、認証情報を入力する工程は、キャリアにもよるが、ブラウザが用いられる場合が多い。

通信事業者サーバ３は、通信端末４から電話番号と認証情報を受信すると、通信事業者サーバ３の事業者によって管理されている契約者データベースに記憶された契約者情報（照合情報に相当）と、受信した認証情報とが対応関係にあるか照合をする（ステップＳ１３０１）。ここでは、契約者データベースに複数のユーザについての契約者情報が記憶されていたとしても、通信端末４から受信した電話番号に基づいて、ユーザＩＤとパスワードを契約者データベースから読み出すことができ、読み出したユーザＩＤ及びパスワードと、認証情報とを照合することができる。

通信事業者サーバ３は、契約者情報と認証情報とを照合すると、照合結果が確認条件を満たすか否かを判定する（ステップＳ１３０２）。
ここで確認条件としては、例えば、契約者データベースに記憶されたユーザＩＤ及びパスワードが、認証情報として入力されたユーザＩＤ及びパスワードと一致することである。

通信事業者サーバ３は、契約者情報と認証情報とを照合し、確認条件を満たしていないと判定した場合には（ステップＳ１３０２－ＮＧ）、確認条件を満たしていないことを表す制御信号を生成し、通信端末４に送信する。
通信端末４は、この制御信号を受信すると、認証情報の再入力を促す画面を表示し、認証情報の入力を受け付ける（ステップＳ１４０６Ｃ）。

通信事業者サーバ３は、契約者情報と認証情報とを照合し、確認条件を満たしていると判定した場合には（ステップＳ１３０２－ＯＫ）、認可コードを生成し、通信端末４を経由して（ステップＳ１４０８Ｃ）、配信サーバ１へ送信する。ここで、認可コードは、ユーザが、携帯電話のキャリアの認証画面（例えば、ステップＳ１４０４ＣまたはステップＳ１４０６Ｃ等）において、個人情報を通信事業者サーバ３の外部に送信することについて同意が得られた場合に通信事業者サーバ３（携帯キャリアのサーバ）から発行される一意のコードである。この認可コードは、通信事業者サーバ３（携帯キャリア）からユーザ情報を取得する際に必要なトークンで利用する。認可コードは、発行されてから所定の期間（短期間）が経過すると無効となり、１回のみ利用可能とすることも可能であり、漏洩のリスクを軽減することができる。

配信サーバ１は、送信された認可コードを取得し（ステップＳ１２０８Ｃａ）、この認可コードを通信事業者サーバ３に送信するとともに、通信事業者サーバ３にアクセス用トークンの払い出しを要求する（ステップＳ１２０８Ｃｂ）。
通信事業者サーバ３は、配信サーバ１から送信された認可コードに応じてトークンを払い出し、配信サーバ１に送信する（ステップＳ１３０３Ｃａ）。
配信サーバ１は、送信されたトークンを取得すると（ステップＳ１２０８Ｃｃ）、このトークンを通信事業者サーバ３に送信するとともに、通信事業者サーバ３に電話番号とキャリア契約情報を要求する（ステップＳ１２０８Ｃｄ）。
通信事業者サーバ３は、配信サーバ１から受信したトークンが正当である場合には、トークンに応じた電話番号とキャリア契約情報とを配信サーバ１に送信する（ステップＳ１３０３Ｃｂ）。ここでは、キャリア契約情報は、認証情報としての役割も兼ねている。

配信サーバ１は、通信事業者サーバ３から電話番号とキャリア契約情報を取得すると（ステップＳ１２０８Ｃｅ）、記憶部１２に記憶された照合情報のうち受信した電話番号に対応付けられた照合情報と、受信したキャリア契約情報とが対応関係にあるか照合をし（ステップＳ１２０９Ｃ）、確認条件を満たすか否かを判定する（ステップＳ１２１０Ｃ）。
ここで確認条件としては、照合情報とキャリア契約情報（認証情報）とが一致することである。キャリア契約情報として、氏名、住所、生年月日が含まれる場合、配信サーバ１の記憶部１２に記憶された氏名、住所、生年月日と、それぞれ一致するか否かである。ここでは、住所は引っ越し等があったことにより、配信サーバ１において記憶された住所と、キャリア契約情報に含まれる住所が一致していない状態となる場合や、氏名については姓名のうち姓が変更される場合がある。そのため、キャリア契約情報の一部（例えば、生年月日と氏名のうちの名）が一致するか否かを条件として用いてもよい。

配信サーバ１は、確認条件を満たしていないと判定した場合には（ステップＳ１２１０Ｃ－ＮＧ）、確認条件を満たしていないことを表すメッセージを生成する（ステップＳ１２１１）。その後、第１実施形態のステップＳ１２１２、ステップＳ１４０９と同様の処理が行われる。これにより、通信端末４は、確認条件を満たしていないことを表すメッセージを表示画面に表示する。なお、確認条件を満たしていないと判定された場合に、確認条件を満たしていないことを表すメッセージを配信サーバ１から通信端末４に送信しなくてもよい。また、通信端末４は、確認条件を満たしていないことを表すメッセージを表示しなくてもよい。

配信サーバ１は、確認条件を満たしていると判定した場合には（ステップＳ１２１０Ｃ－ＯＫ）には、送信データに含まれるメッセージ本文を生成するために必要な情報に基づくメッセージを生成する（ステップＳ１２１３）。その後、第１実施形態のステップＳ１２１４、ステップＳ１４１０と同様の処理が行われる。これにより、通信端末４は、配信サーバ１から送信されたメッセージを表示する。通信端末４は、メッセージを表示するとともに、確認が完了したこと（確認条件を満たしていること）を表示してもよい。

なお、第３実施形態において、照合を行う場合、配信サーバ１に備えられた記憶部１２と認証情報（キャリア契約情報）とを照合するようにしたが、企業サーバ２に備えられたデータベース（顧客マスタ）と認証情報（キャリア契約情報）とを照合するようにしてもよい。

［本実施形態の効果］
本実施形態によれば、通信事業者サーバ３が管理するキャリア契約情報と、照合情報とを照合するようにしたので、ユーザが個人情報そのものを直接入力するのではなく、通信事業者が提供するサービスサイトにログインする場合と同様に、ユーザＩＤとパスワードとを入力すればよいので、個人情報を直接入力する場合に比べて心理的な負担を軽減することができる。また、通信事業者サーバ３の通信事業者とユーザとの間においてキャリア契約を締結する場合には、本人認証が行われた上でキャリア契約情報として登録されるため、信頼性の高いキャリア契約情報を利用して照合することができる。

［第３実施形態の変形例：キャリア認証，マッチングの場合］
図９Ａ、図９Ｂは、本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。
この第３実施形態の変形例においては、マッチングの場合について説明する。
この第３実施形態の変形例において、ステップＳ１１０１からステップＳ１３０２までの処理は、第３実施形態と同様であるので、説明を省略する。

通信事業者サーバ３は、契約者情報と認証情報とを照合し、確認条件を満たしていないと判定した場合には（ステップＳ１３０２Ｄ－ＮＧ）、確認条件を満たしていないことを表す制御信号を生成し、通信端末４に送信する。この後、ステップＳ１４０６Ｃと同様の処理が行われる。
一方、通信事業者サーバ３は、契約者情報と認証情報とを照合し、確認条件を満たしていると判定した場合には（ステップＳ１３０２Ｄ－ＯＫ）、認可コードを生成し、生成された認可コードを配信サーバ１に送信する。

配信サーバ１は、通信事業者サーバ３から認可コードを受信すると（ステップＳ１２０８Ｄａ）、この認可コードを通信事業者サーバ３に送信するとともに、通信事業者サーバ３にアクセス用トークンの払い出しを要求する（ステップＳ１２０８Ｄｂ）。
通信事業者サーバ３は、配信サーバ１から送信された認可コードに応じてトークンを払い出し、配信サーバ１に送信する（ステップＳ１３０３Ｄａ）。
配信サーバ１は、通信事業者サーバ３からトークンを取得する（ステップＳ１２０８Ｄｃ）。配信サーバ１は、記憶部１２に記憶された照合情報のうち、今回の照合対象である電話番号に対応付けられた照合情報を読み出し（ステップＳ１２０９Ｄａ）、読み出した照合情報と、通信事業者サーバ３から取得したトークンとを通信事業者サーバ３に送信する（ステップＳ１２０９Ｄｂ）。ここで送信される照合情報は、記憶部１２に記憶された氏名、住所、生年月日等が用いられる。また、ここで送信される照合情報は、通信端末４にて入力された氏名、住所、生年月日等を用いることもできる。

通信事業者サーバ３は、配信サーバ１から照合情報とトークンとを受信すると、トークンが正しいか否かを判定し、トークンが正しい場合には、照合情報と、契約者データベースに記憶されたキャリア契約情報とが対応関係にあるか照合する（ステップＳ１３０４）。そして通信事業者サーバ３は、照合結果を配信サーバ１に送信する。
通信事業者サーバ３は、この照合を行う場合、照合情報に含まれる各項目の内容が、それぞれキャリア契約情報における対応する項目の内容と一致するか否かの照合を行う。ここでは、照合情報とキャリア契約情報における氏名が一致し、住所が一致せず、生年月日が一致する場合、通信事業者サーバ３は、「氏名が一致、住所が不一致、生年月日が一致」であることを示す照合結果を配信サーバ１に送信する。

配信サーバ１は、通信事業者サーバ３から照合結果を取得すると（ステップＳ１２０９Ｄｃ）、照合結果に基づいて、確認条件を満たすか否かを判定する（ステップＳ１２１０Ｄ）。
ここで確認条件としては、照合情報とキャリア契約情報（認証情報）とにおいて、全ての項目が一致することであってもよいし、少なくとも一部の項目について一致することであってもよい。例えば、住所が不一致であったとしても、氏名と生年月日がそれぞれ一致である場合には、確認条件を満たすと判定してもよい。住所については、引っ越しによって変更される場合があり、契約者データベースと配信サーバ１の記憶部１２との両方の住所について必ずしも最新に更新されているとは限らない場合があるためである。

配信サーバ１は、確認条件を満たしていないと判定した場合には（ステップＳ１２１０Ｄ－ＮＧ）、確認条件を満たしていないことを表すメッセージを生成する（ステップＳ１２１１）。その後、第１実施形態のステップＳ１２１２、ステップＳ１４０９と同様の処理が行われる。これにより、通信端末４は、確認条件を満たしていないことを表すメッセージを表示画面に表示する。なお、確認条件を満たしていないと判定された場合に、確認条件を満たしていないことを表すメッセージを配信サーバ１から通信端末４に送信しなくてもよい。また、通信端末４は、確認条件を満たしていないことを表すメッセージを表示しなくてもよい。

配信サーバ１は、確認条件を満たしていると判定した場合には（ステップＳ１２１０Ｄ－ＯＫ）には、送信データに含まれるメッセージ本文を生成するために必要な情報に基づくメッセージを生成する（ステップＳ１２１３）。その後、第１実施形態のステップＳ１２１４、ステップＳ１４１０と同様の処理が行われる。これにより、通信端末４は、配信サーバ１から送信されたメッセージを表示する。通信端末４は、メッセージを表示するとともに、確認が完了したこと（確認条件を満たしていること）を表示してもよい。

なお、第３実施形態において、照合を行う場合、ステップＳ１２０９Ｄａにおいて配信サーバ１に備えられたデータベースから照合情報を読み出すようにしたが、企業サーバ２に備えられたデータベースから照合情報を読み出し、通信事業者サーバ３に送信するようにしてもよい。

［本実施形態の効果］
本実施形態によれば、第３実施形態における効果と同様の効果が得られる他に、契約者データベースに記憶されたキャリア契約情報そのものを通信事業者サーバ３の外部に送信するのではなく、キャリア契約情報に含まれる項目毎に、一致するか否かの照合結果を送信するようにしたので、よりセキュリティを向上させることができる。

［第４実施形態：オンライン個人認証（ｅＫＹＣ），照合情報を配信サーバが持つ場合］
図１０Ａ、図１０Ｂは、本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。
第１実施形態では、署名検証サーバ５から得られる情報を用いて本人確認を行う場合、第２実施形態では、配信サーバ１または企業サーバ２に備えられた顧客マスタを用いて本人確認を行う場合、第３実施形態においては通信事業者サーバ３において管理されたキャリア契約情報を用いて本人確認を行う場合について説明したが、第４実施形態では、ｅＫＹＣの技術を利用して本人確認をする場合について説明する。
ここで、ｅＫＹＣを利用して本人確認をする場合、照合情報として配信サーバ１に備えられた記憶部１２を利用する場合と、企業サーバ２に備えられたデータベースを利用する場合とがある。

この第４実施形態においては、照合情報として配信サーバ１に備えられた記憶部１２を利用する場合について説明する。
この第４実施形態において、ステップＳ１１０１からステップＳ１４０２までの処理は、第２実施形態と同様であるので、説明を省略する。
この第４実施形態において、ステップＳ１１０１、ステップＳ１２０１からＳ１２０４、ステップＳ１４０１、ステップＳ１４０２までの処理は、第１実施形態と同じであるので、同一の符号を付し、その説明を省略する。

ステップＳ１４０３Ｅにおいて、通信端末４は、ユーザによって入力される、本人確認をする認証方法を選択するための選択肢に対する操作入力を受け付ける（ステップＳ１４０３Ｅ）。ユーザによってタッチパネル上の「その他の公的書類を用いたオンライン身元確認」のボタンに対してタップされると、通信端末４は、「その他の公的書類を用いたオンライン身元確認」の操作入力を受け付け、認証情報の入力を受け付ける認証画面を表示する（ステップＳ１４０４Ｅ）。例えば、「認証情報を入力して下さい」等の認証情報の入力を促すための内容を表す文字列を表示する。ここで入力される認証情報は、公的書類に基づくデータであればよい。公的書類としては、例えば、自動車運転免許証や、健康保険証等のように本人であることを証明することができる証明書であれば、いずれの公的書類を用いてもよい。また、各種の公的書類のうちユーザが任意の種類の公的書類を選択できてもよいし、ユーザに対して利用可能な公的書類を限定（指定）するようにしてもよい。ここでは、自動車運転免許証を用いる場合を例として説明する。
通信端末４は、公的書類として自動車運転免許証を用いる場合、認証情報の入力を受け付ける認証画面において、「認証情報を入力します。運転免許証の表面と裏面をそれぞれカメラで撮像して下さい。」等のように自動車運転免許証の券面の撮影を促すメッセージを表示するとともに、通信端末４のカメラ機能を起動する。

ここで、自動車運転免許証の撮影のみではなく、自分の顔を通信端末４のカメラ機能によって撮影したセルフィー画像とともに送信するようにしてもよい。
そして、ユーザによって自動車運転免許証の表面が撮影されると、撮影画像を認証情報として入力を受け付け（ステップＳ１４０６Ｅ）、電話番号とともに、受け付けた情報をｅＫＹＣ情報（認証情報）として配信サーバ１に送信する（ステップＳ１４０７Ｅ）。ここでは、アカウントＩＤも通信端末４から配信サーバ１に送信するようにしてもよい。

ここで、公的書類の撮影機能や、撮影結果の送信機能については、ＲＣＳアプリとは別のアプリケーションソフトウェアによって実現するようにしてもよいし、ブラウザによって実現してもよし、また、ｅＫＹＣの機能のサービスを提供する外部のシステムを利用してもよい。

配信サーバ１は、通信端末４からｅＫＹＣ情報（認証情報）と電話番号とを受信すると（ステップＳ１２０８Ｅ）、ステップＳ１２０２において記憶部１２に記憶された照合情報のうち受信した電話番号に対応付けられた照合情報と、受信した認証情報とが対応関係にあるか照合をし（ステップＳ１２０９Ｅ）、確認条件を満たすか否かを判定する（ステップＳ１２１０Ｅ）。

ここで確認条件としては、ｅＫＹＣ情報に含まれる情報を利用し、本人確認がとれたか否かである。具体例としては、ｅＫＹＣ情報に含まれる撮像画像からＯＣＲ（Optical Character Recognition：光学文字認識）の機能によって、券面に記述された氏名、住所、生年月日等を抽出し、抽出された内容と、配信サーバ１の記憶部１２に記憶された情報とが一致するか否かである。これらの各項目における内容がそれぞれ一致する場合に本人確認がとれたと判定してもよいし、各項目のうち一部の項目（例えば氏名と生年月日）が一致する場合に本人確認が取れたと判定してもよい。また、ｅＫＹＣ情報のうち、自動車運転免許証から抽出される顔写真と、セルフィー画像との一致度合いに基づいて、同一人物であるか否かを判定する判定項目を確認条件として用いることもできる。顔写真と、セルフィー画像との一致度合いの判定は、画像処理技術を用いることで実現することができる。

なお、ステップＳ１２０９Ｅにおける照合処理について、配信サーバ１において各種演算を行うことで実現してもよいが、少なくとも一部を人（確認担当者）が行うようにしてもよい。例えば、自動車運転免許証から抽出される顔写真と、セルフィー画像とに基づいて、同一人物であるか否かの判定を確認担当者が実施し、その結果を配信サーバ１に対して入力するようにしてもよいし、自動車運転免許証に記載された氏名、住所、生年月日と、記憶部１２に記憶された氏名、住所、生年月日をともに表示画面に表示し、それぞれが一致するか否かを確認担当者が確認するようにしてもよい。
また、照合に関する全部または少なくとも一部について、配信サーバ１の事業者とは異なる外部のサービス等を利用してもよい。

配信サーバ１は、確認条件を満たしていないと判定した場合には（ステップＳ１２１０Ｅ－ＮＧ）、確認条件を満たしていないことを表すメッセージを生成する（ステップＳ１２１１）。その後、第１実施形態のステップＳ１２１２、ステップＳ１４０９と同様の処理が行われる。これにより、通信端末４は、確認条件を満たしていないことを表すメッセージを表示画面に表示する。なお、確認条件を満たしていないと判定された場合に、確認条件を満たしていないことを表すメッセージを配信サーバ１から通信端末４に送信しなくてもよい。また、通信端末４は、確認条件を満たしていないことを表すメッセージを表示しなくてもよい。

配信サーバ１は、確認条件を満たしていると判定した場合には（ステップＳ１２１０Ｅ－ＯＫ）には、送信データに含まれるメッセージ本文を生成するために必要な情報に基づくメッセージを生成する（ステップＳ１２１３）。その後、第１実施形態のステップＳ１２１４、ステップＳ１４１０と同様の処理が行われる。これにより、通信端末４は、配信サーバ１から送信されたメッセージを表示する。通信端末４は、メッセージを表示するとともに、確認が完了したこと（確認条件を満たしていること）を表示してもよい。

［本実施形態の効果］
本実施形態によれば、公的書類に基づく情報をユーザから提供してもらい、ユーザから得られた情報（ｅＫＹＣ情報）と、照合情報とに基づいて本人確認を行うことができる。公的書類を利用して本人確認を行うことができるため、本人確認の信頼性を向上させることができる。

［第４実施形態の変形例：オンライン個人認証（ｅＫＹＣ），照合情報を企業サーバが持つ場合］
図１１Ａ、図１１Ｂは、本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。
上述の第４実施形態においては、照合情報として配信サーバ１に備えられた記憶部１２を利用する場合について説明したが、第４実施形態の変形例においては、照合情報として企業サーバ２に備えられたデータベースを利用する場合について説明する。
この第４実施形態において、ステップＳ１１０１、ステップＳ１２０１、ステップＳ１２０３からステップＳ１４０６Ｅまでの処理は、第４実施形態と同様であるので、説明を省略する。なお、第４実施形態においては、ステップＳ１２０２において配信サーバ１の記憶部１２に照合情報が記憶されるが、この第４実施形態の変形例では、配信サーバ１において照合情報を保有しないことから、ステップＳ１２０２の処理はスキップされる。

通信端末４は、ユーザによってｅＫＹＣ情報が入力されると、電話番号とともに、受け付けた情報をｅＫＹＣ情報（認証情報）として配信サーバ１に送信する（ステップＳ１４０７Ｆ）。ここでは、アカウントＩＤも通信端末４から配信サーバ１に送信するようにしてもよい。
配信サーバ１は、通信端末４から電話番号とｅＫＹＣ情報（認証情報）とを受信すると、電話番号とｅＫＹＣ情報（認証情報）とを企業サーバ２に送信（中継）する（ステップＳ１２０５Ｅ）。
ここでは、配信サーバ１が、通信端末４から電話番号とｅＫＹＣ情報（認証情報）とを受信し、企業サーバ２に対して中継する場合について説明したが、配信サーバ１による中継を行わない場合、通信端末４から企業サーバ２に対して、電話番号とｅＫＹＣ情報（認証情報）とを送信するようにしてもよい。

企業サーバ２は、電話番号とｅＫＹＣ情報（認証情報）を受信すると（ステップＳ１１０２Ｅ）、企業サーバ２のデータベースに記憶された照合情報のうち受信した電話番号に対応付けられた照合情報と、受信したｅＫＹＣ情報（認証情報）とが対応関係にあるか照合をし（ステップＳ１１０３Ｅ）、確認条件を満たすか否かを判定する（ステップＳ１１０４Ｅ）。ステップＳ１１０３Ｅにおける照合は、第４実施形態におけるステップＳ１２０９Ｅと同様であり、ステップＳ１１０４Ｅにおける確認条件を満たすか否かの判定は、第４実施形態におけるステップＳ１２１０Ｅと同様であるため、説明を省略する。

企業サーバ２は、確認条件を満たしていないと判定した場合には（ステップＳ１１０４Ｅ－ＮＧ）、確認条件を満たしていないことを示す制御信号を配信サーバ１に送信する。
配信サーバ１は、確認条件を満たしていないことを示す制御信号を受信すると、確認条件を満たしていないことを表すメッセージを生成する（ステップＳ１２１１）。その後、第１実施形態のステップＳ１２１２、ステップＳ１４０９と同様の処理が行われる。これにより、通信端末４は、確認条件を満たしていないことを表すメッセージを表示画面に表示する。なお、確認条件を満たしていないと判定された場合に、確認条件を満たしていないことを表すメッセージを配信サーバ１から通信端末４に送信しなくてもよい。また、通信端末４は、確認条件を満たしていないことを表すメッセージを表示しなくてもよい。
企業サーバ２は、確認条件を満たしていると判定した場合には（ステップＳ１１０４Ｅ－ＯＫ）、確認条件を満たしていることを示す制御信号を配信サーバ１に送信する。
配信サーバ１は、確認条件を満たしていることを示す制御信号を受信すると、送信データに含まれるメッセージ本文を生成するために必要な情報に基づくメッセージを生成する（ステップＳ１２１３）。その後、第１実施形態のステップＳ１２１４、ステップＳ１４１０と同様の処理が行われる。これにより、通信端末４は、配信サーバ１から送信されたメッセージを表示する。通信端末４は、メッセージを表示するとともに、確認が完了したこと（確認条件を満たしていること）を表示してもよい。

［本実施形態の効果］
本実施形態によれば、企業サーバ２のデータベースに記憶された情報を照合情報として用いつつ、公的書類に基づく情報をユーザから提供してもらい、ユーザから得られた情報（ｅＫＹＣ情報）と、照合情報とに基づいて本人確認を行うことができる。公的書類を利用して本人確認を行うことができるため、本人確認の信頼性を向上させることができる。また、配信サーバ１は、照合情報を保持する必要がない。

なお、上述した各実施形態において、本人確認が行われ本人であることが確認できた後については、通信端末４に記憶されている生体情報を用いて本人確認を行うようにしてもよい。
また、メッセージの通知内容の重要度に応じて、認証方法を設定してもよい。例えば、メッセージの通知内容の重要度が所定の高さである場合に公的個人認証を行いるように予め定めておいてもよい。
また、本人確認を過去に行ったことがあるユーザについては、前回行った認証方法とは別の認証方法を設定するようにしてもよい。例えば、本人確認を一度もしたことがないユーザについては、公的個人認証またはキャリア認証のどちらかをユーザに選択してもらい、その後、同じユーザに対して２回目以降の本人確認を行う場合には、いずれかの認証方法の選択肢から選択してもらうようにしてもよい。すなわち、重要度や、過去に本人確認が取れたことがあったか否かに応じて、選択肢が決められていてもよい。

なお、上述した各実施形態において、企業サーバ２からメッセージを送信する場合について説明したが、企業サーバ２は、銀行や保険会社のような企業であってもよいし、電子私書箱を運営する企業であってもよい。電子私書箱を運営する企業は、その他の種々の企業からメッセージを受け付け、宛先であるユーザに対して閲覧可能となるように送信してもよい。例えば、電子私書箱を運営する企業が、異なる複数の企業からそれぞれメッセージの送信依頼を受信し、そのメッセージを配信サーバ１に対して送信依頼をするようにしてもよい。その際、上述したように、メッセージの重要性に応じて、認証方法を選択する選択肢を通信端末４に表示し、認証方法をユーザに選択してもらうようにしてもよい。

また、上述した実施形態において、電話番号を宛先とするメッセージサービスとして、ＲＣＳを用いる場合について説明したが、ＳＭＳ（Short Message Service）を利用し、本人確認を促すためのメッセージや、重要度が高い内容を含むメッセージ（本人確認が取れた後に送るメッセージ）を送信するようにしてもよい。
また、上述した実施形態における本人確認が取れた場合に、メッセージを電子的に送信する場合について説明したが、メッセージを電子的に送信するのではなく、紙等の印刷媒体をユーザに送付するようにしてもよい。例えば、本人確認や契約継続の意思確認を上述した実施形態により電子的に実施し、本人確認が取れたという結果をもって、契約締結完了書類や最新のクレジットカードなどを送付（郵送、宅配等）するようにしてもよい。

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

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

１…配信サーバ、２…企業サーバ、３，３ａ，３ｂ…通信事業者サーバ、４…通信端末、５…署名検証サーバ、１１…通信部、１２…記憶部、１３…制御部、１３１…データ処理部、１３２…メッセージ制御部、１３３…照合部

Claims (3)

1. メッセージを送信する送信先の電話番号の送信先に対応する通信端末に対して、前記電話番号の契約者が前記メッセージを送信する宛先のユーザであるかを認証する認証方法を指定してもらうための候補を送信する送信部と、
   前記候補から指定された認証方法に基づくユーザ認証が行われた結果に応じて、前記メッセージを送信可否の判定を行うための制御をする制御部と
   を有する情報処理装置。
2. 前記候補は、
   公的な証明書である個人カードを用いた公的個人認証、
   前記個人カードとは異なる情報であって少なくとも本人の容貌の画像を含む情報に基づいてオンラインによって本人確認を行うオンライン個人認証、
   前記電話番号を利用した通信サービスを提供する通信端末の通信事業者と契約ユーザとの契約に関するキャリア契約情報を用いるキャリア認証、
   前記メッセージの送信元である企業によって管理される顧客マスタを用いる顧客マスタ認証
   のうち少なくともいずれか２つが含まれる
   請求項１に記載の情報処理装置。
3. コンピュータにより実行される情報処理方法であって、
   メッセージを送信する送信先の電話番号の送信先に対応する通信端末に対して、前記電話番号の契約者が前記メッセージを送信する宛先のユーザであるかを認証する認証方法を指定してもらうための候補を送信し、
   前記候補から指定された認証方法に基づくユーザ認証が行われた結果に応じて、前記メッセージを送信可否の判定を行うための制御をする
   ことを含む情報処理方法。

Images