JP2023119857A - 情報処理装置、情報処理方法、及びプログラム - Google Patents

Abstract

【課題】宛先とされたユーザ以外にメッセージが届いてしまうことを抑制する情報処理装置、情報処理方法及びプログラムを提供する。【解決手段】配信サーバと、通信事業者サーバと、通信端末と、Ｗｅｂサーバと、を含むメッセージ配信システムにおいて、配信サーバ１は、通信部１１と、記憶部１２と、制御部１３と、を備える。通信部１１は、メッセージを送信する送信先の電話番号に対応する通信端末にインストールされたメッセージアプリを用いて、電話番号の契約者がメッセージを送信する宛先のユーザであるかを認証する認証方法を指定してもらうための候補が示されたＵＲＩへのリンクを送信する。制御部１３は、候補から指定された認証方法に基づくユーザ認証が行われた結果に応じて、メッセージを送信可否の判定を行うための制御をする。【選択図】図２

Description

本発明は、情報処理装置、情報処理方法、及びプログラムに関する。

オンラインで情報を通知する電子通知サービスがある。特許文献１では、通知先のユーザがすぐに見ることのできる確率が高いメールアドレスに情報を送信する技術が開示されている。

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

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

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

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

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

また、上述した課題を解決するために、本発明に係る情報処理方法は、コンピュータが行う情報処理方法であって、送信部が、メッセージを送信する送信先の電話番号に対応する通信端末にインストールされたメッセージアプリを用いて、前記電話番号の契約者が前記メッセージを送信する宛先のユーザであるかを認証する認証方法を指定してもらうための候補が示されたＵＲＩ（Uniform Resource Identifier）へのリンクを送信し、制御部が、前記候補から指定された認証方法に基づくユーザ認証が行われた結果に応じて、前記メッセージを送信可否の判定を行うための制御をする。

また、上述した課題を解決するために、本発明は、コンピュータを、上記に記載の情報処理装置として動作させるためのプログラムであって、前記コンピュータを前記情報処理装置が備える各部として機能させるためのプログラムである。

本発明によれば、宛先とされたユーザ以外にメッセージが届いてしまうことを抑制することができる。

実施形態に係るメッセージ配信システムＳの構成例を示すブロック図である。 実施形態に係る配信サーバ１の機能を説明するブロック図である。 実施形態に係る配信情報１２０の例を示す図である。 実施形態に係る応答情報１２１の例を示す図である。 実施形態に係る通信端末４に表示されるメッセージの例を示す図である。 実施形態に係るコンテンツＢに対応づけられた情報Ｂ＃の例を示す図である。 実施形態に係る通信端末４に表示される認証方法の選択肢が表示されたＷｅｂページの例を示す図である。 第１の実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 第１の実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 第２の実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 第２の実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 第３の実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 第３の実施形態に係る配信サーバ１が行う処理の流れを示すフロー図である。 第３の実施形態に係る配信サーバ１が行う処理の流れを示すフロー図である。 第３の実施形態に係る配信サーバ１が行う処理の流れを示すフロー図である。 第３の実施形態に係る配信サーバ１が行う処理の流れを示すフロー図である。 第４の実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 第５の実施形態に係る配信情報１２０Ａの例を示す図である。 第５の実施形態に係る通信端末４に表示されるメッセージの例を示す図である。 第５の実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 第５の実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。 第５の実施形態に係るＷｅｂサーバ６が行う処理の流れを示すフロー図である。

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

図１は、実施形態に係るメッセージ配信システムＳの構成例を示すブロック図である。メッセージ配信システムＳは、例えば、配信サーバ１と、通信事業者サーバ３と、通信端末４と、Ｗｅｂサーバ６とを含む。

配信サーバ１は、通信端末４に対するメッセージを送信するサービスを提供する事業者が管理するサーバ装置である。配信サーバ１は、通信端末４に対するメッセージを、通信事業者サーバ３を介して送信（配信）する。配信サーバ１は、電話番号を宛先とするメッセージサービスであるＲＣＳ（Rich Communication Services）を用いたＲＣＳメッセージを送信する。配信サーバ１は、企業サーバ２、及び通信事業者サーバ３との間で無線通信又は有線通信をする。

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

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

通信端末４は、スマートフォン又は携帯電話など、電話番号を対応づけることが可能な通信装置である。通信端末４は、ユーザ等によって、通信事業者サーバ３の事業者と、通信端末４を用いた通信サービスを利用するための契約がなされる。通信端末４は、契約している通信事業者が提供する通信サービスを用いて通信することが可能である。通信端末４には電話番号が割り当てられており、この電話番号を送信先とした通信、すなわちＲＣＳを用いた通信を行う機能を有する。
通信端末４は、例えば、液晶ディスプレイ等の表示部と、ユーザによる操作を受け付けるタッチパネル等の操作部を有する。通信端末４は、通信事業者サーバ３及び通信端末４を通信相手として通信ネットワークＮＷを用いた通信をする。ユーザは、例えば生活者である。

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

Ｗｅｂサーバ６は、Ｗｅｂサイトを運営する事業者によって管理されるサーバ装置である。ＷｅｂサイトにはＵＲＬ（Uniform Resource Locator）が対応づけられている。Ｗｅｂサーバ６は、Ｗｅｂサイトにアクセスしてきた通信装置に対し、Ｗｅｂサイトの画面に対して行われた操作に応じた画面を表示させる。ＵＲＬは「ＵＲＩ（Uniform Resource Identifier）」の一例である。

図２に示すように、配信サーバ１は、通信部１１と、記憶部１２と、制御部１３とを備える。通信部１１は、通信事業者サーバ３、及びＷｅｂサーバ６と通信を行う。記憶部１２は、各種情報、例えば、配信情報１２０、応答情報１２１、照合情報１２２を記憶する。

図３は、実施形態に係る配信情報１２０の例を示す図である。配信情報１２０は、メッセージごとに生成される。配信情報１２０は、例えば、案件特定識別子、配信単位特定識別子、個人特定識別子、及びボタン（ボタン１、ボタン２、…）のそれぞれの項目に対応する情報を含む。案件特定識別子は、送信するメッセージのカテゴリを特定するＩＤ（Identification）である。配信単位特定識別子は、送信するメッセージを特定するＩＤである。個人特定識別子は、ユーザが特定可能な情報であり、例えば、メッセージの送信先である電話番号である。個人特定識別子は、少なくともユーザが特定可能な情報であればよく、電話番号に限定されることはない。例えば、電話番号に紐づけられたキー情報、或いは、ユーザを特定できる情報を、個人特定識別子として用いることができる。
ボタンは、メッセージに含めることができるコンテンツであり、ユーザが操作できるコンテンツである。ボタンには、例えば、ボタンＩＤ、ＵＲＬ、及びポストバックデータのそれぞれに対応する情報が含まれる。ボタンＩＤは、メッセージに設定されたボタンを特定するＩＤである。ＵＲＬは、ボタンが操作されることによりアクセスされるＵＲＬである。ＵＲＬは「ＵＲＩ（Uniform Resource Identifier）」の一例である。ポストバックデータはＷｅｂｈｏｏｋ情報に含まれる情報である。つまり、ボタンが操作されることにより、通信事業者サーバ２０から配信サーバ１０にＷｅｂｈｏｏｋ情報が送信され、そのＷｅｂｈｏｏｋ情報には、ここで設定したポストバックデータが含まれる。

本実施形態では、配信情報１２０におけるポストバックデータに識別子を設定する。識別子は、（案件特定識別子、配信単位特定識別子、ボタンＩＤ、個人特定識別子）の組合せを特定する情報である。これにより、ボタンが操作された場合に、ここで設定した識別子を含むＷｅｂｈｏｏｋ情報が通信事業者サーバ２０から配信サーバ１０に送信される。配信サーバ１０は、識別子を含むＷｅｂｈｏｏｋ情報を受信することにより、利用者端末３０に送信した何れのメッセージにおける、何れのボタンが操作されたのかを把握することができる。
また、本実施形態では、配信情報１２０におけるＵＲＬに、ポストバックデータと同様な情報、すなわち、（案件特定識別子、配信単位特定識別子、ボタンＩＤ、個人特定識別子）の組合せを特定する識別子を付与する。これにより、ＵＲＬを指定してアクセスしてきた通信端末が、利用者端末３０に送信したメッセージに設定されたＵＲＬを用いてアクセスしてきたか否かを把握することができる。

なお、ポストバックデータにおける識別子と、ＵＲＬに付与される識別子は、少なくとも（案件特定識別子、配信単位特定識別子、ボタンＩＤ、個人特定識別子）の組合せを特定できる情報であればよい。ポストバックデータにおける識別子と、ＵＲＬに付与される識別子は、同一の情報であってもよいし、異なる情報であってもよい。

図４は、実施形態に係る応答情報１２１の例を示す図である。応答情報１２１は、利用者端末３０に送信したメッセージに対する反応がある、つまり、メッセージに含まれるボタンが操作されるごとに生成される。応答情報１２１は、例えば、電話番号、ポストバックデータ、タイムスタンプのそれぞれの項目に対応する情報を含む。応答情報１２１におけるこれらの情報、つまり、電話番号、ポストバックデータ、及びタイムスタンプのそれぞれの項目に対応する情報は、Ｗｅｂｈｏｏｋ情報に含まれる。
電話番号は、ボタンの操作が行われた通信装置の電話番号である。ポストバックデータは、操作が行われたボタンに対応づけられているポストバックデータである。タイムスタンプは、ボタンの操作が行われた時刻を示す情報である。

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

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

図２の説明に戻り、制御部１３は、例えば、取得部１３０と、生成部１３１と、判定部１３２と、表示制御部１３３と、照合部１３４とを備える。
取得部１３０は、各種の情報を取得する。例えば、取得部１３０は、後述する生成部１３１によって生成されたＲＣＳメッセージに関する情報を取得し、取得した情報を記憶部１２に記憶させる。これらＲＣＳメッセージに関する情報が記憶部１２に書き込まれることで、これらの情報を配信情報１２０として用いることが可能となる。
取得部１３０は、通信事業者サーバ３から受信したＷｅｂｈｏｏｋ情報を取得し、取得したＷｅｂｈｏｏｋ情報を記憶部１２に記憶させる。Ｗｅｂｈｏｏｋ情報が記憶部１２に書き込まれることで、このＷｅｂｈｏｏｋ情報を応答情報１２１として用いることが可能となる。
取得部１３０は、企業サーバ２から受信したユーザ情報を記憶部１２に書き込む。ユーザ情報が記憶部１２に書き込まれることで、このユーザ情報を照合情報１２２として用いることが可能となる。

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

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

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

なお、認証方法の候補としてオンライン個人認証、キャリア認証が含まれていてもよい。オンライン個人認証は、本人の容貌（例えば、顔）を示す画像を含む情報に基づいてオンラインによって本人確認を行う認証方法であり、例えば、ｅＫＹＣ（electronic Know Your Customer）である。キャリア認証は、電話番号を利用した通信サービスを提供する通信端末の通信事業者と契約ユーザとの契約に関するキャリア契約情報を用いて本人確認を行う認証方法である。

生成部１３１は、重要な通知内容を含むＲＣＳメッセージを通信端末４に送信する前に、本人確認を促すためのＲＣＳメッセージを生成して通信端末４に送信する。そして、配信サーバ１は、本人確認が行われ、本人であることの確認が取れた後、重要な通知内容を含むＲＣＳメッセージを通信端末４に送信する。ここでは、生成部１３１は、本人確認を促すためのＲＣＳメッセージに、認証方法の候補から選択可能な選択肢を示すＷｅｂサイト（以下、認証サイトともいう）へのリンクを含むようにしてＲＣＳメッセージを生成する。

ここで生成部１３１が、本人確認を促すためのＲＣＳメッセージを生成する方法について、図５及び図６を用いて説明する。

図５は、実施形態に係る通信端末４に表示される、本人確認を促すためのＲＣＳメッセージの例を示す図である。通信端末４の表示画面には、企業サーバ２から依頼されたメッセージが表示される前に、本人確認を促す内容（符号Ｍ０１）が表示されるとともに、認証サイトへのリンクを示すＵＲＬが表示される。
図５の例に示すように、生成部１３１は、本人確認を促すためのＲＣＳメッセージとして、ＲＣＳで利用可能なメッセージ、例えば、リッチカード及びチップリストなどが利用できるコンテンツ、例えばボタンＢに、認証サイトへのリンクを示すＵＲＬを対応づけたＲＣＳメッセージを生成する。

図６は、実施形態に係るボタンＢに対応づけられた情報Ｂ＃の例を示す図である。図６には、図５に示すボタンＢに対応づけられた情報の例が、情報Ｂ＃として示されている。情報Ｂ＃は、例えば、ＵＲＬ及びポストバックデータのそれぞれの項目に対応する情報を含む。ＵＲＬは特定のＷｅｂサイト（例えば、認証サイト）を示す情報である。ＵＲＬには、識別子が付与されている。識別子は、（案件特定識別子、配信単位特定識別子、ボタンＩＤ、個人特定識別子）の組合せを特定する情報である。ポストバックデータには識別子が含まれる。
図６の例に示すように、生成部１３１は、ボタンＢに、識別子を付与した認証サイトのＵＲＬ、及び識別子を含むポストバックデータを対応づけたＲＣＳメッセージを生成する。

図２の説明に戻り、判定部１３２は、認証サイトへアクセスしてきた通信装置が、ＲＣＳメッセージを送信した通信端末４であるか否かを判定する。認証サイトのＵＲＬを対応づけたＲＣＳメッセージを通信端末４に送信した場合において認証サイトのＵＲＬが他のユーザに知られてしまい、他のユーザによって認証サイトが閲覧されてしまうような不当なアクセスがなされる可能性がある。判定部１３２が、認証サイトへアクセスしてきた通信装置が、ＲＣＳメッセージを送信した通信端末４であるか否かを判定することにより、このような不当なアクセスを抑制することができる。判定部１３２が判定を行う具体的な方法については後で詳しく説明する。

表示制御部１３３は、通信装置に表示させる内容を制御する。ここでの通信装置は、通信端末４、及び他のユーザの端末装置を含む。表示制御部１３３は、判定部１３２による判定結果に基づいて、認証サイトへアクセスしてきた通信装置が、ＲＣＳメッセージを送信した通信端末４である場合、通信端末４に認証サイトに対応する画面を表示させる。一方、表示制御部１３３は、判定部１３２によって認証サイトへアクセスしてきた通信装置がメッセージを送信した通信端末４でないと判定された場合、その通信端末４ではない通信装置にエラー画面を表示させる。エラー画面は、例えば、認証サイトにアクセスできないことを示す画面である。

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

図７は、通信端末４の表示画面に認証サイトが表示された場合の一例を示す図である。通信端末４の表示画面には、認証方法を選択する選択肢（符号Ｍ０２）が表示される。選択肢は、少なくとも１つ表示される。この図の例では、４つの選択肢が表示された場合が図示されている。ユーザは、この選択肢のなかから認証方法を選び、希望する認証方法の選択肢を画面上においてタップ（操作入力）する。これにより、選択肢のなかから認証方法を選択することができる。この画面においては、４つの選択肢が表示される場合について図示されているが、選択肢が１つのみの場合であってもよいし、選択肢が４つ以外の複数であってもよい。選択肢が１つのみ表示される場合、当該１つの選択肢をユーザに選択させるようにしてもよいし、ユーザに選択させることなく、直接、当該１つの選択肢に基づく認証を始めるようにしてもよい。

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

［第１実施形態：顧客マスタ認証，照合情報を配信サーバが持つ場合］
図８Ａ、図８Ｂは、本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。
本実施形態では、顧客マスタとして予め記憶された情報と、ユーザから入力される情報とを用いて本人確認を行う。
なお、顧客マスタは、メッセージの送信元である企業によって管理される情報に限定されない。例えば、メッセージの送信元とは異なる他の企業によって管理される情報を顧客マスタとして利用するようにしてもよい。ここでのメッセージの送信元とは異なる他の企業とは、例えば、ＧＡＦＡ等と呼ばれるような、比較的多くのユーザが利用するサービスを提供する企業である。このように、送信元ではない他の企業にて登録されたアカウント（顧客マスタ情報）を利用した顧客マスタ認証が行われてもよい。

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

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

本実施形態においては、顧客マスタを記憶するデータベースは、配信サーバ１と企業サーバ２とのいずれに備えられていてもよいが、配信サーバ１に備えられた場合について説明する。

企業サーバ２は、送信先ユーザの電話番号と、照合情報と、送信先ユーザに対して送信するメッセージ本文を生成するために必要な情報とを含む配信依頼を、配信サーバ１に送信する（ステップＳ１１０１）。配信サーバ１の通信部１１は、企業サーバ２から、電話番号、照合情報及びメッセージ本文を生成するために必要な情報を含む配信依頼を受信する。
ここでは、企業サーバ２からメッセージを送信対象の人数が１人である場合について説明するが、複数のユーザにそれぞれ送信することもできる。

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

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

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

通信端末４は、配信サーバ１から通信事業者サーバ３を介し、本人確認を促す内容を含むＲＣＳメッセージを受信する（ステップＳ１４０１）。ここで、通信端末４は、ＲＣＳに係るアプリケーションプログラム（ＲＣＳアプリ）がインストールされており、配信サーバ１からＲＣＳメッセージを受信できる。本人確認を促す内容を含むＲＣＳメッセージには、本人確認を促す内容、例えば、「重要なお知らせがありますので、本人確認をお願いいたします。」という文字列と共に、認証サイトへのリンクを示すＵＲＬが画面に表示される。

通信端末４は、受信したＲＣＳメッセージに示された認証サイトのＵＲＬがユーザによってタップされることによって、認証サイト（Ｗｅｂサーバ６）にアクセスする（ステップＳ１４０２）。これにより、Ｗｅｂサーバ６から認証サイトに係る情報が通信端末４に送信され、認証サイトに係る情報が通信端末４の表示画面に表示される。認証サイトに認証方法を選択する選択肢も含まれている場合には、その選択肢が表示される。例えば、「登録ＩＤを用いた認証を行う」、「マイナンバー認証を行う」、「キャリア認証を行う」、「その他の公的書類を用いたオンライン身元確認を行う」の４つの選択肢が表示される。ここで「登録ＩＤを用いた認証」は、顧客マスタ認証に対応する。また、「マイナンバー認証」は、公的個人認証に対応する。

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

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

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

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

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

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

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

［本実施形態の効果］
本実施形態によれば、配信サーバ１に顧客マスタとして記憶された照合情報を利用して本人確認を行うことができる。そのため、本人確認を行うにあたり、他の機器と連携しなくても本人確認をすることができる。
なお、上述した実施形態では配信サーバ１が照合及び確認条件を満たしているか否かを判定する場合を例示して説明したがこれに限定されない。例えば、Ｗｅｂサーバ６が照合情報を備え、Ｗｅｂサーバ６が照合及び確認条件を満たしているか否かを判定し、確認条件を満たしている場合にその旨を配信サーバ１に通知することにより、メッセージ本文を配信する指示を行うように構成されてもよい。

［第２実施形態：公的個人認証を用いる場合］
図９Ａ、図９Ｂは、本実施形態に係るメッセージ配信システムＳが実行するメッセージ配信方法のシーケンス図である。
この実施形態では、署名検証サーバ５における公的個人認証を利用して得られる個人情報と照合情報とを用いて本人確認をする場合について説明する。

この第２実施形態において、ステップＳ１１０１、ステップＳ１２０１からＳ１２０４、ステップＳ１４０１、ステップＳ１４０２までの処理は、第１実施形態と同じであるので、同一の符号を付し、その説明を省略する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

［通信端末４がＷｅｂサーバ６にアクセスするシーケンス］
以下、Ｗｅｂサーバ６にアクセスするシーケンスについて説明する。以下の実施形態においては、ＲＣＳメッセージにあるＵＲＬにアクセスしてきた通信端末４が、当該ＲＣＳメッセージを受信した通信端末４であるか否かを判定する。そして、ＵＲＬにアクセスしてきた通信端末４がＲＣＳメッセージを送信した通信端末４である場合に、ＵＲＬへのアクセスを許可する。これにより、ＲＣＳメッセージにあるＵＲＬが送信先のユーザとは異なる他のユーザに知られてしまい、他のユーザによって認証サイトが閲覧されてしまうことを抑制する。

［第３実施形態：認証サイトへリダイレクトさせる場合］
図１０～図１４は、本実施形態に係るメッセージ配信システムＳが実行する認証サイトにアクセスする処理の流れを示す図である。
この実施形態では、配信サーバ１によってリダイレクト処理が行われることにより、通信端末４による認証サイトへのアクセスが実行される場合について説明する。

図１０に示すように、配信サーバ１は、ＲＣＳメッセージを生成する（ステップＳ１）。配信サーバ１は、ボタンＢに、識別子が付与されたＵＲＬ、及び識別子を含むポストバックデータを対応づけたＲＣＳメッセージを生成する。配信サーバ１は、通信事業者サーバ３に対してメッセージ送信リクエストを行う（ステップＳ２）。具体的には、配信サーバ１は、ＲＣＳメッセージを通信事業者サーバ３に送信し、当該ＲＣＳメッセージを通信端末４に送信するように要求する。

通信事業者サーバ３は、配信サーバ１から受信した、メッセージ送信リクエストに応じて、メッセージ配信処理を行う（ステップＳ３）。具体的には、通信事業者サーバ３は、配信サーバ１から受信したＲＣＳメッセージを、通信端末４に送信する。通信端末４は、通信事業者サーバ３からＲＣＳメッセージを受信する（ステップＳ４）。これにより、通信端末４の表示画面にＲＣＳメッセージが表示される。ユーザは、ＲＣＳメッセージに設けられたボタンＢをタップする等して操作する（ステップＳ５）。これにより、通信端末４から、ボタンＢが操作された旨の制御情報（Ｗｅｂｈｏｏｋ情報）が通信事業者サーバ３に送信される。

通信事業者サーバ３は、ボタンＢが操作された旨のＷｅｂｈｏｏｋ情報を受信すると、受信したＷｅｂｈｏｏｋ情報を配信サーバ１に送信する（ステップＳ６）。配信サーバ１は、通信事業者サーバ３からＷｅｂｈｏｏｋ情報を受信すると、受信したＷｅｂｈｏｏｋ情報から抽出した、電話番号、ポストバックデータ、タイムスタンプのそれぞれを応答情報１２１として記憶部１２に記憶させる（ステップＳ７）。

一方、ステップＳ５に示す処理において、ボタンＢが操作されると、ボタンＢに対応づけられているＵＲＬに応じた認証サイトへのアクセスが実行される。この図の例では、認証サイトにアクセスする代わりに、配信サーバ１が有する特定のサイト（或いはリソース）に一時的に誘導する。すなわち、ＵＲＬには、配信サーバ１が有するサイト（或いはリソース）が設定される。このように、ボタンＢに認証サイトへのアクセスを対応づける場合において、ＵＲＬの代わりに、一時的に使用するリソースのＵＲＩ（Uniform Resource Identifier）が設定されてもよい。

配信サーバ１は、配信サーバ１が有する特定のサイト或いはリソース（以下、サイト等という）へのアクセスを受信すると、そのアクセス時刻を記憶部１２に記憶させる（ステップＳ８）。配信サーバ１は、受信したアクセスに対応するＵＲＬから、当該ＵＲＬに付与された識別子を抽出する（ステップＳ９）。配信サーバ１は、抽出した識別子に基づいて、対応する応答情報１２１を参照し、判定処理を実行する（ステップＳ１０）。判定処理は、アクセスしてきた通信端末４に対し認証サイトへのリダイレクトを実行するか否かを判定する処理である。配信サーバ１は、アクセスしてきた通信装置がＲＣＳメッセージの送信先とした通信端末４である場合、通信端末４の表示画面に認証サイトを表示させると判定する。一方、配信サーバ１は、アクセスしてきた通信装置がＲＣＳメッセージの送信先とした通信端末４でない場合、通信端末４の表示画面に認証サイトを表示させないと判定する。認証サイト表示判定で行う処理の詳細は後で詳しく説明する。

配信サーバ１は、判定処理の判定結果が、ＯＫであるかＮＧであるかを判定する（ステップＳ１１）。ここでのＯＫは、通信端末４の表示画面に認証サイトを表示させることである。ここでのＮＧは、通信端末４の表示画面に認証サイトを表示させないことである。配信サーバ１は、判定処理の判定結果がＮＧである場合、通信端末４にエラー画面を表示させる（ステップＳ１２）。エラー画面は、認証サイトにアクセスすることができない旨を表示する画面である。

配信サーバ１は、判定処理の判定結果がＯＫである場合、通信端末４にリダイレクトを要求する（ステップＳ１３）。具体的には、配信サーバ１は、認証サイトのＵＲＬを通信端末４に送信して、送信したＵＲＬにアクセスするように通信端末４に要求する。通信端末４は、配信サーバ１からのリダイレクト要求を受信すると、リダイレクト処理を行う（ステップＳ１４）。具体的には、通信端末４は、配信サーバ１から受信したリダイレクト要求に示されていたＵＲＬにアクセスする。これにより、通信端末４は、Ｗｅｂサーバ６における認証サイトへのアクセスを実行する。Ｗｅｂサーバ６は、配信サーバ１から受信したアクセスに応じた応答を行う（ステップＳ１５）。具体的には、Ｗｅｂサーバ６は、認証サイトを示す画面を通信端末４の表示画面に表示させる。これにより、通信端末４に、例えば、１又は複数の認証方法を選択する選択肢が表示される（ステップＳ１６）。

図１１には、図１０のステップＳ１０に示す判定処理を実行する処理の流れが示されている。まず、配信サーバ１は、応答情報を取得する処理を実行する（ステップＳ１００）。次に、配信サーバ１は、電話番号を照合する処理を実行する（ステップＳ１０１）。そして、配信サーバ１は、操作時刻とアクセス時刻を比較する処理を実行し（ステップＳ１０２）、処理を終了させてステップＳ１１に進む。ここでの操作時刻は、ボタンＢが操作された時刻である。アクセス時刻は、サイト等へのアクセスを配信サーバ１が受信した時刻である。

図１２には、図１１のステップＳ１００に示す応答情報を取得する処理を実行する処理の流れが示されている。ここでは、ボタンＢに対応づけられたサイト等へのアクセスに対応する応答情報１２１が取得される。

ここで、ボタンＢに対する操作と、ボタンＢに対応づけられたサイト等へのアクセスはほぼ同時に行われる。すなわち、配信サーバ１が、ボタンＢに対する操作が行われたことに起因して通信事業者サーバ３からＷｅｂｈｏｏｋ情報を受信するタイミングと、配信サーバ１が有する特定のサイト等へのアクセスを受信するタイミングとはほぼ同時刻となる可能性が高い。例えば、通信事業者サーバ３によるＷｅｂｈｏｏｋ情報の生成に時間を要した、或いは、通信事業者サーバ３と配信サーバ１との間の通信回線が混雑していた等の理由により、配信サーバ１がＷｅｂｈｏｏｋ情報を受信するタイミングが遅れる場合があり得る。この場合、配信サーバ１は、通信事業者サーバ３がＷｅｂｈｏｏｋ情報を受信する前に、サイト等へのアクセスを受信する可能性がある。

Ｗｅｂｈｏｏｋ情報を受信する前に、サイト等へのアクセスを受信した場合、アクセスに対応する応答情報１２１が記憶部１２に記憶されていない時間が存在することになる。この場合、配信サーバ１は、Ｗｅｂｈｏｏｋ情報を受信するタイミングが遅れたことに起因して対応する応答情報１２１が記憶部１２に記憶されていないのか、或いは、ボタンＢに対する操作が行われなかったことに起因して対応する応答情報１２１が記憶部１２に記憶されていないのか区別することが困難となる。
この対策として、本実施形態では、配信サーバ１は、アクセスに対応する応答情報１２１が記憶されていない場合には、所定の待ち時間（例えば、１秒間）が経過した後に、再度、記憶部１２を参照し、アクセスに対応する応答情報１２１が記憶されているか否かを確認するリトライを実行する。リトライを実行した結果、記憶部１２に対応する応答情報１２１が記憶されていた場合には、配信サーバ１は、その対応する応答情報１２１を取得する。これにより、Ｗｅｂｈｏｏｋ情報を受信する前にアクセスが実行された場合であっても、アクセスに対応する応答情報１２１を取得することができる。
リトライの回数があらかじめ定めた閾値（例えば、３回）以上となっても、記憶部１２に対応する応答情報１２１が記憶されていない場合、配信サーバ１は、ボタンＢに対する操作が行われず、対応する応答情報１２１が記憶部１２に記憶されていないと判定する。これにより、他のユーザの通信装置によりＵＲＬがアクセスされた可能性が高い場合、不正なアクセスとみなしてこれを抑制することができる。

図１２に示すように、まず、配信サーバ１は、変数としてのリトライ回数を０（ゼロ）として初期化する（ステップＳ１００１）。次に、配信サーバ１は、ＵＲＬから抽出した識別子に基づいて記憶部１２を参照し、対応する応答情報１２１が記憶されているか否かを判定する（ステップＳ１００２）。対応する応答情報１２１が記憶されている場合、配信サーバ１は処理を終了させ、ステップＳ１０１に進む。対応する応答情報１２１が記憶されていない場合、配信サーバ１は、リトライ回数をインクリメントする（Ｓ１００３）。配信サーバ１は、リトライ回数が閾値未満であるか否かを判定する（ステップＳ１００４）。配信サーバ１は、リトライ回数が閾値未満である場合、待ち時間が経過したか否かを判定する（ステップＳ１００５）。待ち時間が経過した場合、配信サーバ１は、ステップＳ１００２に戻る。一方、ステップＳ１００４において、リトライ回数が閾値以上である場合、配信サーバ１は、判定結果をＮＧとし（ステップＳ１００６）、処理を終了させ、ステップＳ１１に進む。

図１３には、図１１のステップＳ１０１に示す電話番号を照合する処理を実行する処理の流れが示されている。ここでは、Ｗｅｂｈｏｏｋ情報に含まれる電話番号と、ＵＲＬに付与された識別子に含まれる電話番号（個人特定識別子）とを突合させることにより照合が行われる。なお、ここでの電話番号又は個人特定識別子は、少なくともユーザが特定可能な情報であればよく、電話番号に限定されることはない。例えば、電話番号に紐づけられたキー情報、或いは、ユーザを特定できる情報を、個人特定識別子として用いることができる。

まず、配信サーバ１は、ＵＲＬに付与された識別子に対応する応答情報１２１を抽出する（ステップＳ１０１１）。具体的には、配信サーバ１は、記憶部１２を参照し、応答情報１２１として記憶された情報のうち、ＵＲＬに付与された識別子に対応する識別子を有するポストバックデータを含む応答情報１２１を抽出する。配信サーバ１は、電話番号が一致するか否かを判定する（ステップＳ１０１２）。配信サーバ１は、抽出した応答情報１２１における電話番号と、ＵＲＬに付与された識別子に含まれる電話番号（生産管理番号）とを突合させる。例えば、配信サーバ１は、二つの電話番号が一致するか否かを判定する。電話番号が一致した場合、配信サーバ１は処理を終了させ、ステップＳ１０２に進む。電話番号が一致しない場合、配信サーバ１は判定結果をＮＧとし（ステップＳ１０１３）、処理を終了させ、ステップＳ１１に進む。
或いは、ステップＳ１０１２において、配信サーバ１０は、又は個人特定識別子Ｗｅｂｈｏｏｋ情報に含まれる個人特定識別子（第１情報という）と、ＵＲＩに付与された識別子に含まれる電話番号に対応する情報（第２情報という）とが同じユーザに紐づく情報であることを示しているか否かを判定するようにしてもよい。第１情報と第２情報とが整合し、同じユーザに紐づく情報であることが示されている場合、配信サーバ１０は処理を終了させ、ステップＳ１０２に進む。電話番号が一致しない場合、配信サーバ１０は判定結果をＮＧとし（ステップＳ１０１３）、処理を終了させ、ステップＳ１１に進む。

図１４には、図１１のステップＳ１０２に示す操作時刻とアクセス時刻を比較する処理を実行する処理の流れが示されている。ここでは、ボタンＢが操作された操作時刻と、サイト等がアクセスされたアクセス時刻とが比較される。

まず、配信サーバ１は、アクセス時刻を取得する（ステップＳ１０２１）。配信サーバ１は、記憶部１２を参照し、ステップＳ８で記憶させたアクセス時刻を取得する。配信サーバ１は、ステップＳ１０１１で取得した応答情報１２１におけるタイムスタンプに示された操作時刻を取得する（ステップＳ１０２２）。配信サーバ１は、アクセス時刻が操作時刻より後の時刻であるか否かを判定する（ステップＳ１０２３）。アクセス時刻が操作時刻より後の時刻である場合、配信サーバ１は、アクセス時刻が（操作時刻＋許容時間）より前の時刻であるか否かを判定する（ステップＳ１０２４）。アクセス時刻が（操作時刻＋許容時間）より前の時刻である場合、配信サーバ１は、判定結果をＯＫとし（ステップＳ１０２５）、処理を終了させ、ステップＳ１１に進む。一方、配信サーバ１は、ステップＳ１０２３においてアクセス時刻が操作時刻より前の時刻であると判定した場合、及びステップＳ１０２４においてアクセス時刻が（操作時刻＋許容時間）より後の時刻であると判定した場合、判定結果をＮＧとし（ステップＳ１０２６）、処理を終了させ、ステップＳ１１に進む。

［本実施形態の効果］
本実施形態によれば、配信サーバ１が、アクセスに用いられたＵＲＬと、ボタンＢに対する操作に対応するＷｅｂｈｏｏｋ情報とを用いてＲＣＳメッセージに含まれるＵＲＬへのアクセスを実行した通信端末が、ＲＣＳメッセージの送信先とした通信端末４であるか否かを判定するようにした。これにより、配信サーバ１は、ＲＣＳメッセージに含まれるＵＲＬへのアクセスを実行した通信端末が、ＲＣＳメッセージの送信先とした通信端末４であるか否かを判定することができる。したがって、認証サイトへのリンクを含むＲＣＳメッセージを通信端末４に通知した場合において、そのリンクにあるＵＲＬが他のユーザに知られてしまう等して他のユーザによって認証サイトへのアクセスが実行された場合であっても認証サイトへのリダイレクトさせないようにすることができ、他のユーザに認証サイトが閲覧されてしまうことを抑制することができる。

［第４実施形態：Ｗｅｂサーバ６が認証サイトへアクセスを許可する場合］
図１５は、本実施形態に係るメッセージ配信システムＳが実行する認証サイトにアクセスする処理の流れを示す図である。
この実施形態では、Ｗｅｂサーバ６によって認証サイトへのアクセスを許可するか否かが判定される場合について説明する。

図１５のステップＳ２１～Ｓ２７に示す処理は、図１０のステップＳ１～Ｓ７に示す処理と同等であるためその説明を省略する。
図１５に示すように、Ｗｅｂサーバ６は、通信端末４によるＵＲＬへのアクセスが実行された場合、アクセス時刻を、Ｗｅｂサーバ６の記憶部に記憶させる（ステップＳ２８）。Ｗｅｂサーバ６は、受信したＵＲＬに付与された識別子を抽出し、抽出した識別子を、配信サーバ１に送信する（ステップＳ２９）。
配信サーバ１は、Ｗｅｂサーバ６から受信した識別子に基づいて記憶部１２を参照し、当該識別子に対応する応答情報１２１を取得する。配信サーバ１は、取得した応答情報１２１の全部または一部を、Ｗｅｂサーバ６に送信する（ステップＳ３０）。
Ｗｅｂサーバ６は、通信端末４から受信した応答情報１２１に基づいて、判定処理を実行する（ステップＳ３１）。判定処理は、アクセスしてきた通信端末４に対し認証サイトの情報を通信端末４の表示画面に表示させるか否かを判定する処理である。Ｗｅｂサーバ６は、アクセスしてきた通信装置が、ＲＣＳメッセージを送信した送信先の通信端末４である場合、通信端末４の表示画面に認証サイトを表示させると判定する。一方、配信サーバ１は、アクセスしてきた通信装置が、ＲＣＳメッセージを送信した送信先の通信端末４でない場合、通信端末４の表示画面に認証サイトを表示させないと判定する。表示判定処理で行う処理は、ステップＳ１１に示す判定処理と同等であるためその説明を省略する。
Ｗｅｂサーバ６は、判定処理の判定結果がＮＧである場合、通信端末４に、エラー画面を表示させる（ステップＳ３３）。一方、表示制御部４３２は、判定処理の判定結果がＯＫである場合、通信端末４に、Ｗｅｂサーバ６における認証サイトの画面を表示させる（ステップＳ３４）。

［本実施形態の効果］
本実施形態によれば、Ｗｅｂサーバ６が、アクセスに用いられたＵＲＬに基づいてボタンＢに対する操作に対応するＷｅｂｈｏｏｋ情報を取得するようにした。これにより、Ｗｅｂサーバ６は、ＲＣＳメッセージに含まれるＵＲＬへのアクセスを実行した通信端末が、ＲＣＳメッセージの送信先とした通信端末４であるか否かを判定することができる。したがって、他のユーザによって認証サイトへのアクセスが実行された場合には認証サイトへのアクセスを許可しないようにすることができ、他のユーザに認証サイトが閲覧されてしまうことを抑制することができる。

［第５実施形態：ＲＣＳメッセージ以外の通知手段を含む場合］
図１６、図１７、図１８（図１８Ａ、図１８Ｂ）、及び図１９は、本実施形態に係るメッセージ配信システムＳが実行する認証サイトにアクセスする処理の流れを示す図である。
この実施形態では、配信サーバ１によってＲＣＳメッセージ以外の通知が実行される場合について説明する。ＲＣＳメッセージ以外の通知とは、例えば、ＳＭＳ（Short Message Service）を用いたＳＭＳメッセージによる通知である。

通信端末４はＳＭＳに対応しているが、ＲＣＳについては対応しているものと対応していないものがある。例えば、ＲＣＳのアプリケーションがインストールされ、且つＲＣＳを用いた通信に関する利用規約の同意などを含むアクティベーションが行われた場合、通信端末４はＲＣＳに対応している端末である。一方、ＲＣＳのアプリケーションがインストールされていない、又は、ＲＣＳのアプリケーションがインストールされているがアクティベーションが行われていない場合、通信端末４はＲＣＳに対応していない端末である。
このような観点から、本実施形態のメッセージ配信システムＳは、ＲＣＳに対応している通信端末４にＲＣＳメッセージを送信し、ＲＣＳに対応していない通信端末４にＳＭＳメッセージを送信するようにした。これにより、ＲＣＳに対応していない利用者端末３０にもメッセージを送信することが可能となる。

具体的には、配信サーバ１は、通信端末４を送信先とするメッセージについて、ＲＣＳメッセージ及びＳＭＳメッセージの２つのメッセージを生成する。配信サーバ１は、ＲＣＳメッセージとして、例えば、上述した実施形態と同様に、リッチカード或いはチップリストなどにボタンＢなどのコンテンツを設け、ボタンＢに認証サイトのＵＲＬを対応づけたメッセージを生成する。配信サーバ１は、ＳＭＳメッセージとして、例えば認証サイトのＵＲＬを含むテキストからなるメッセージを生成する。
配信サーバ１は、作成した２つのメッセージを用いて通信事業者サーバ３に送信リクエストを行う。通信事業者サーバ３は、ＲＣＳに対応している通信端末４にＲＣＳメッセージを送信し、ＲＣＳに対応していない通信端末４にＳＭＳメッセージを送信する。

配信サーバ１が２つのメッセージを生成する方法について、図１６を用いて説明する。
図１６は、第５の実施形態に係る配信情報１２０Ａの例を示す図である。配信情報１２０Ａは、メッセージごとに生成される。配信情報１２０Ａは、例えば、案件特定識別子、配信単位特定識別子、個人特定識別子、及びＲＣＳとＳＭＳのそれぞれの項目に対応する情報を含む。案件特定識別子は、送信するメッセージのカテゴリを特定するＩＤ（Identification）である。
配信単位特定識別子は、送信するメッセージを特定するＩＤである。個人特定識別子は、ユーザが特定可能な情報であり、例えば、メッセージの送信先である電話番号である。
個人特定識別子は、少なくともユーザが特定可能な情報であればよく、電話番号に限定されることはない。例えば、電話番号に紐づけられたキー情報、或いは、ユーザを特定できる情報を、個人特定識別子として用いることができる。
ＲＣＳの項目には、通信端末４にＲＣＳメッセージを送信する場合におけるメッセージの内容を示す情報が記憶される。ＳＭＳの項目には、通信端末４にＳＭＳメッセージを送信する場合におけるメッセージの内容を示す情報が記憶される。

ＲＣＳに記憶される情報には、例えば、ボタン（ボタン１、ボタン２、…）の項目に対応する情報が含まれる。 ボタンは、メッセージに含めることができるコンテンツであり、ユーザが操作できるコンテンツである。ボタンには、例えば、ボタンＩＤ、ＵＲＬ、及びポストバックデータのそれぞれに対応する情報が含まれる。ボタンＩＤは、メッセージに設定されたボタンを特定するＩＤである。ＵＲＬは、ボタンが操作されることによりアクセスされるＵＲＬである。ポストバックデータはＷｅｂｈｏｏｋ情報に含まれる情報である。つまり、ボタンが操作されることにより、通信事業者サーバ３から配信サーバ１にＷｅｂｈｏｏｋ情報が送信され、そのＷｅｂｈｏｏｋ情報には、ここで設定したポストバックデータが含まれる。

本実施形態では、ボタンに対応づけられたポストバックデータに第１識別子を設定する。第１識別子は、（案件特定識別子、配信単位特定識別子、ボタンＩＤ、個人特定識別子）の組合せを特定する情報である。これにより、ボタンが操作された場合に、第１識別子を含むＷｅｂｈｏｏｋ情報が通信事業者サーバ３から配信サーバ１に送信される。配信サーバ１は、第１識別子を含むＷｅｂｈｏｏｋ情報を受信することにより、通信端末４に送信した何れメッセージにおける、何れのボタンが操作されたのかを把握することができる。

また、本実施形態では、ボタンに対応づけられたＵＲＬに、第１識別子を付与する。第１識別子は、ポストバックデータに設定される第１識別子と同等な情報であって、（案件特定識別子、配信単位特定識別子、ボタンＩＤ、個人特定識別子）の組合せを特定する情報である。ＲＣＳ識別子は、ＲＣＳを用いて送信されたメッセージであることを特定する情報である。
なお、ポストバックデータにおける第１識別子と、ＵＲＬに付与される第１識別子は、少なくとも（案件特定識別子、配信単位特定識別子、ボタンＩＤ、個人特定識別子）の組合せを特定できる情報であればよい。ポストバックデータにおける第１識別子と、ＵＲＬに付与される第１識別子は、同一の情報であってもよいし、異なる情報であってもよい。
ＵＲＬに、ポストバックデータと同等な情報（第１識別子）が付与されることにより、第１識別子を手掛かりとして、ＵＲＬにアクセスしてきた通信端末がＲＣＳメッセージのボタンを操作することによりアクセスしてきた端末であるか否かを、Ｗｅｂｈｏｏｋ情報を用いて把握することができる。

さらに、本実施形態では、ボタンに対応づけられたＵＲＬに、ＲＣＳ識別子を付与する。ＵＲＬに、ＲＣＳ識別子が付与されることにより、Ｗｅｂｈｏｏｋ情報を用いなくとも、ＵＲＬを指定してアクセスしてきた通信端末が、ＲＣＳメッセージに設定されたＵＲＬを用いてアクセスしてきたか否かを把握することができる。

ＳＭＳに記憶される情報には、例えば、テキスト、及びＵＲＬのそれぞれの項目に対応する情報が含まれる。テキストは、送信するメッセージの内容を示すテキスト情報である。ＵＲＬは、メッセージの中で示されるＵＲＬであって、そのＵＲＬが操作されることによりアクセスされるＵＲＬである。
本実施形態では、ＳＭＳメッセージの中で示されるＵＲＬに、第２識別子が付与される。第２識別子は、ＵＲＬが改ざんされていないことを判定可能な情報であって、例えば、ＵＲＬのチェックデジットである。チェックデジットは、ＵＲＬの誤りを検知するために付加される検査用のコードであり、ＵＲＬを用いて特定の演算を行うことにより算出されるコードである。
ＵＲＬに第２識別子が付与されることにより、ＳＭＳメッセージを介してＵＲＬにアクセスしてきた通信端末が、改ざんされたＵＲＬを用いてアクセスしてきた不正な端末でないか判定することができる。

本実施形態では、ＲＣＳメッセージにて通知するＵＲＬにＲＣＳ識別子を付与し、ＳＭＳメッセージにて通知するＵＲＬに、ＳＭＳメッセージであることを特定する識別子（ＳＭＳ識別子）を付与しない。これは、ＳＭＳメッセージにて通知可能な文字数が制限される場合があるためである。例えば、一部の古い機種では、ＳＭＳメッセージが、所定の文字数（例えば、７０文字）ごとに分割されて通知される。このため、ＳＭＳメッセージで比較的長い文字数を有するＵＲＬを通知した場合、その通知するＵＲＬを示す文字列が複数の文字列に分割されて通知される可能性がある。このように文字数に制限があったり、分割されたりする可能性があるＳＭＳメッセージにおいては、なるべく文字数が少ないメッセージを通知するほうがよい。このため、本実施形態では、ＳＭＳメッセージにて通知するＵＲＬにＳＭＳ識別子を付与しないようにした。
なお、上述した実施形態ではＳＭＳメッセージにＳＭＳ識別子を付与しない場合を例示して説明したがこれに限定されない。サービスの運用形態に応じて、ＳＭＳメッセージにＳＭＳ識別子を付与するように構成されてもよい。

本実施形態で送信されるＳＭＳメッセージについて、図１７を用いて説明する。図１７は、実施形態に係る利用者端末３０に表示されるＳＭＳメッセージの例を示す図である。図１７に示すように、ＳＭＳメッセージでは、テキストにてメッセージが示される。この図では、「ＩＲ情報が開示されました。」などの文言とともに、末尾にＵＲＬが示されている。また、図１７に示すように、本実施形態におけるＳＭＳメッセージに示されるＵＲＬには第２識別子が付与されている（符号Ｔ）。

図１８（図１８Ａ、図１８Ｂ）には、本実施形態に係るメッセージ配信システムＳが実行する認証サイトにアクセスする処理の流れが示されている。

配信サーバ１は、メッセージ（ＲＣＳメッセージ及びＳＭＳメッセージ）を生成する（ステップＳ３１）。配信サーバ１は、ボタンＢに、第１識別子及びＲＣＳ識別子が付与されたＵＲＬ、及び第１識別子を含むポストバックデータを対応づけたＲＣＳメッセージを生成する。また、配信サーバ１は、第２識別子が付与されたＵＲＬを含むＳＭＳメッセージを生成する。配信サーバ１は生成したＲＣＳメッセージ及びＳＭＳメッセージを配信情報１２０として記憶部１２に記憶させる。
配信サーバ１は、通信事業者サーバ３に対してメッセージ送信リクエストを行う（ステップＳ３２）。具体的には、配信サーバ１は、配信情報１２０を通信事業者サーバ３に送信し、通信端末４にメッセージを送信するように要求する。

通信事業者サーバ３は、配信サーバ１から受信した、メッセージ送信リクエストに応じて、メッセージ配信処理を行う（ステップＳ３３）。具体的には、通信事業者サーバ３は、通信端末４がＲＣＳに対応しているか否かを判定し、ＲＣＳに対応している通信端末４にはＲＣＳメッセージを送信する。ＲＣＳに対応していない通信端末４にはＳＭＳメッセージを送信する。
ＲＣＳに対応している通信端末４は、通信事業者サーバ３からＲＣＳメッセージを受信する（ステップＳ３４）。これにより、通信端末４の表示画面にＲＣＳメッセージが表示される。ステップＳ３５～Ｓ４４に示す処理は、第３の実施形態におけるステップＳ５～Ｓ１４に示す処理と同様であるため、その説明を省略する。ステップＳ４４以降の処理（符号Ｙ）の流れについては図１８Ｂで説明する。

ステップＳ３３において、ＲＣＳに対応していないと判定された通信端末４は、通信事業者サーバ３からＳＭＳメッセージを受信する（ステップＳ４５）。これにより、通信端末４の表示画面にＳＭＳメッセージが表示される。ユーザは、ＳＭＳメッセージに示されたＵＲＬをタップする等して操作する（ステップＳ４６）。これにより、通信端末４は、ＵＲＬに示されたサイト等へのアクセスを実行する。ステップＳ４６以降の処理（符号Ｘ）の流れについては図１８Ｂで説明する。

図１８Ｂに示すように、ステップＳ４４又はステップＳ４６が実行されることにより（符号Ｘ、Ｙ）、Ｗｅｂサーバ６は、通信端末４によるＵＲＬへのアクセスを受信すると、ＵＲＬ改ざん判定処理を行う（ステップＳ４７）。ＵＲＬ改ざん判定処理は、アクセスしてきた端末から通知されたＵＲＬが改ざんされていないか判定する処理である。ＵＲＬ改ざん判定処理の詳細は後で詳しく説明する。Ｗｅｂサーバ６は、ＵＲＬ改ざん判定処理の判定結果がＯＫであるか否かを判定する（ステップＳ４８）。Ｗｅｂサーバ６は、ＵＲＬが改ざんされていない場合、ＵＲＬ改ざん判定処理の判定結果がＯＫであると判定する。Ｗｅｂサーバ６は、ＵＲＬが改ざんされている場合、ＵＲＬ改ざん判定処理の判定結果がＮＧであると判定する。ＵＲＬ改ざん判定処理の判定結果がＯＫである場合、Ｗｅｂサーバ６は、認証サイトを示す画面を通信端末４の表示画面に表示させる。これにより、通信端末４に、認証サイトが表示される（ステップＳ４９）。一方、ＵＲＬ改ざん判定処理の判定結果がＮＧである場合、Ｗｅｂサーバ６は、エラー画面を通信端末４の表示画面に表示させる（ステップＳ５０）。これにより、１又は複数の認証方法を選択する選択肢が表示される。

図１９には、図１８ＢのステップＳ４７に示すＵＲＬ改ざん判定処理の流れが示されている。ここでは、ＳＭＳメッセージを介してＵＲＬへのアクセスが実行された場合、そのＵＲＬが改ざんされていないか判定する。一方、ＲＣＳメッセージを介してＵＲＬへのアクセスが実行された場合、そのＵＲＬが改ざんされていないか判定しない。もしくは、簡易的な確認として、ＳＭＳメッセージに対して実施する判定処理とは異なる判定処理を実施するようにしてもよい。ＲＣＳメッセージを介してＵＲＬへのアクセスが実行された場合、上述したステップＳ１０に示す判定処理が実行され、ＲＣＳメッセージに設けられたボタンが操作されることによってＵＲＬへのアクセスが実行されたことが検証済みであり、ＵＲＬ改ざん判定処理は不要であると考えられるためである。
なお、ＲＣＳメッセージを介してＵＲＬへのアクセスが実行された場合、ＳＭＳメッセージの場合と同様に、そのＵＲＬが改ざんされていないか判定するようにしてもよい。この場合、例えば、ＲＣＳメッセージに示されるＵＲＬに、ＵＲＬのチェックデジットが付与される。

まず、Ｗｅｂサーバ６は、アクセスしてきた通信端末が通知したＵＲＬを取得する（ステップＳ４７０）。Ｗｅｂサーバ６は、取得したＵＲＬにＲＣＳ識別子が付与されているか否かを判定する（ステップＳ４７１）。ＵＲＬにＲＣＳ識別子が付与されていない場合、Ｗｅｂサーバ６は、ＵＲＬが改ざんされているか判定する（ステップＳ４７２）。Ｗｅｂサーバ６は、ＵＲＬに付与された第２識別子を用いて、ＵＲＬが改ざんされているか判定する。具体的には、Ｗｅｂサーバ６は、ＵＲＬのチェックデジットを算出し、算出したチェックデジットと第２識別子とを比較する。チェックデジットと第２識別子が一致した場合、Ｗｅｂサーバ６は、ＵＲＬが改ざんされていないと判定する。一方、チェックデジットと第２識別子が一致しない場合、Ｗｅｂサーバ６は、ＵＲＬが改ざんされていると判定する。ＵＲＬが改ざんされている場合、Ｗｅｂサーバ６は、ＵＲＬ改ざん判定処理判定結果をＮＧとし（ステップＳ４７３）、処理を終了させ、ステップＳ４８に進む。
一方、ステップＳ４７１においてＵＲＬにＲＣＳ識別子が付与されている場合、又は、ステップＳ４７２においてＵＲＬが改ざんされていないと判定された場合、Ｗｅｂサーバ６は、ＵＲＬ改ざん判定処理判定結果をＯＫとし（ステップＳ４７４）、処理を終了させ、ステップＳ４８に進む。

［本実施形態の効果］
本実施形態によれば、ＲＣＳメッセージを通知した場合にはＲＣＳメッセージに含まれるＵＲＬへのアクセスを実行した通信端末が、ＲＣＳメッセージの送信先とした通信端末４であるか否かを判定するようにした。ＳＭＳメッセージを通知した場合にはＳＭＳメッセージに含まれるＵＲＬへのアクセスが実行されたＵＲＬが改ざんされていないか判定するようにした。これにより、ＲＣＳメッセージ及びＳＭＳメッセージのいずれかを通信端末４に通知するような混在環境においても、他のユーザに認証サイトが閲覧されてしまうことを抑制することができる。

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

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

また、上述した実施形態における本人確認が取れた場合に、メッセージを電子的に送信する場合について説明したが、メッセージを電子的に送信するのではなく、紙等の印刷媒体をユーザに送付するようにしてもよい。例えば、本人確認や契約継続の意思確認を上述した実施形態により電子的に実施し、本人確認が取れたという結果をもって、契約締結完了書類や最新のクレジットカードなどを送付（郵送、宅配等）するようにしてもよい。

また、上述した実施形態では、認証サイトにて認証を行う場合を例示したが、認証サイトに代えて任意のＷｅｂサイトが適用されてよい。例えば、メッセージに含まれるリンク先のＵＲＬが認証を行わないサイトのＵＲＬであってもよい。

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

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

Ｓ…メッセージ配信システム、１…配信サーバ、２…企業サーバ、３…通信事業者サーバ、４…通信端末、５…署名検証サーバ、６…Ｗｅｂサーバ、１１…通信部、１２…記憶部、１２０…配信情報、１２１…応答情報（Ｗｅｂｈｏｏｋ情報）、１２２…照合情報、１３…制御部、１３０…取得部、１３１…生成部、１３２…判定部、１３３…表示制御部、１３４…照合部

Claims (4)

1. メッセージを送信する送信先の電話番号に対応する通信端末にインストールされたメッセージアプリを用いて、前記電話番号の契約者が前記メッセージを送信する宛先のユーザであるかを認証する認証方法を指定してもらうための候補が示されたＵＲＩ（Uniform Resource Identifier）へのリンクを送信する送信部と、
   前記候補から指定された認証方法に基づくユーザ認証が行われた結果に応じて、前記メッセージを送信可否の判定を行うための制御をする制御部
   を有する情報処理装置。
2. 前記メッセージアプリは、通信事業者を介してＲＣＳ（Rich Communication Services）を用いたメッセージを送受信するアプリケーションプログラムであり、
   前記送信部は、前記電話番号に対応づけられたキー情報を付与した前記リンクを送信し、
   前記メッセージアプリを用いて送信したメッセージにあるコンテンツが操作された場合に前記通信事業者から通知されるＷｅｂｈｏｏｋ情報であって、前記コンテンツが操作された操作時刻を示すタイムスタンプ、及び前記コンテンツが操作された通信端末の電話番号を含むＷｅｂｈｏｏｋ情報を取得する取得部と、
   前記リンクへのアクセスが実行された場合、前記リンクへのアクセスが実行されたアクセス時刻、前記アクセスされたリンクに付与されている前記キー情報、及び前記Ｗｅｂｈｏｏｋ情報に基づいて、前記アクセスを実行した通信端末が、前記メッセージを受信した通信端末であるか否かを判定する判定部を更に備える、
   請求項１に記載の情報処理装置。
3. コンピュータが行う情報処理方法であって、
   送信部が、メッセージを送信する送信先の電話番号に対応する通信端末にインストールされたメッセージアプリを用いて、前記電話番号の契約者が前記メッセージを送信する宛先のユーザであるかを認証する認証方法を指定してもらうための候補が示されたＵＲＩ（Uniform Resource Identifier）へのリンクを送信し、
   制御部が、前記候補から指定された認証方法に基づくユーザ認証が行われた結果に応じて、前記メッセージを送信可否の判定を行うための制御をする
   情報処理方法。
4. コンピュータを、請求項１又は請求項２に記載の情報処理装置として動作させるためのプログラムであって、前記コンピュータを前記情報処理装置が備える各部として機能させるためのプログラム。

Images