JP7790193B2 - 情報処理システム、及び情報処理方法 - Google Patents

Description

本発明は、情報処理システム、及び情報処理方法に関する。

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

このような電子通知サービスでは、Ｗｅｂサイトへのリンクを含むメッセージを通知する場合がある。例えば、「登録内容の確認はこちらから」等の文言と共に、当該登録内容を確認することができるＷｅｂサイトへのリンクを示すメッセージを通知する。これより、メッセージを簡潔にしつつ、詳細な内容をＷｅｂサイトで把握できるようにして、ユーザの利便性を向上させたサービスを提供することができる。

また、電子通知サービスには、通信事業者によって提供される携帯電話番号を宛先とするメッセージサービスがある。携帯電話番号を宛先とするメッセージサービスには、例えば、ＲＣＳ（Rich Communication Services）、ＳＭＳ（Short Message Service）等がある。ＳＭＳとＲＣＳとでは仕様が異なり、例えばＳＭＳがテキストのみのメッセージを送信できるのに対しＲＣＳでは画像などを含むメッセージを送信することができる。

ユーザの携帯電話にはＲＣＳに対応しているものとＲＣＳに対応していないものがあるため、携帯電話番号を宛先とするメッセージサービスでは、例えば２種類のメッセージを用意する。一方はＲＣＳを用いて送信するＲＣＳメッセージであり、他方はＳＭＳを用いて送信するＳＭＳメッセージである。そして、ＲＣＳに対応している携帯電話にはＲＣＳメッセージを送信し、ＲＣＳに対応していない携帯電話にはＳＭＳメッセージを送信するよう通信事業者に依頼する。これにより、通知先の相手のメールアドレスが不明であってもメッセージを送信することができ、また、ＲＣＳに対応しているか否かに対応することもできる。

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

しかしながら、リンクを含むメッセージをＲＣＳ又はＳＭＳを用いて送信した場合、リンク先にアクセスした通信端末が、ＲＣＳ又はＳＭＳの何れのメッセージからアクセスしてきたのか不明である。ＲＣＳとＳＭＳでは仕様が異なる。例えば、ＲＣＳであればメッセージに対して既読に対応する操作がされたことが判るがＳＭＳでは判らない。リンク先へのアクセスがあった場合、既読等の操作がなされたことが判るＲＣＳメッセージと、判らないＳＭＳメッセージとを区別して異なる対応を行うことができるほうが望ましい。

本発明は、このような事情に鑑みてなされたもので、その目的は、リンクが示されたメッセージをＲＣＳ又はＳＭＳを用いて送信した場合において、当該リンク先にアクセスした通信装置が、ＲＣＳ又はＳＭＳの何れを用いたメッセージにあるリンクからアクセスしたか判定することができる情報処理システム、及び情報処理方法を提供することにある。

上述した課題を解決するために、本発明に係る情報処理システムは、通信事業者を介して、ＲＣＳ（Rich Communication Services）に対応している利用者端末にＲＣＳを用いた第１メッセージを送信し、ＲＣＳに対応していない利用者端末にＳＭＳ（Short Message Service）を用いた第２メッセージを送信する情報処理システムであって、ＵＲＩ（Uniform Resource Identifier）に第１識別子及びＲＣＳ識別子を付与した情報が対応づけられたコンテンツを含む前記第１メッセージ、及び前記ＵＲＩに第２識別子を付与した情報を含む前記第２メッセージを生成する生成部と、前記ＵＲＩへのアクセスが実行された場合、当該アクセスされたＵＲＩに前記ＲＣＳ識別子が付与されているか否かを判定し、前記ＲＣＳ識別子が付与されていれば第１処理を行い、前記ＲＣＳ識別子が付与されていなければ前記第１処理とは異なる第２処理を行う振分処理部と、を備える。

また、上述した課題を解決するために、本発明に係る情報処理方法は、通信事業者を介して、ＲＣＳ（Rich Communication Services）に対応している利用者端末にＲＣＳを用いた第１メッセージを送信し、ＲＣＳに対応していない利用者端末にＳＭＳ（Short Message Service）を用いた第２メッセージを送信する情報処理方法であって、生成部が、ＵＲＩ（Uniform Resource Identifier）に第１識別子及びＲＣＳ識別子を付与した情報が対応づけられたコンテンツを含む前記第１メッセージ、及び前記ＵＲＩに第２識別子を付与した情報を含む前記第２メッセージを生成し、振分処理部が、前記ＵＲＩへのアクセスが実行された場合、当該アクセスされたＵＲＩに前記ＲＣＳ識別子が付与されているか否かを判定し、前記ＲＣＳ識別子が付与されていれば第１処理を行い、前記ＲＣＳ識別子が付与されていなければ前記第１処理とは異なる第２処理を行う。

本発明によれば、リンクが示されたメッセージをＲＣＳ又はＳＭＳを用いて送信した場合において、当該リンク先にアクセスした通信装置が、ＲＣＳ又はＳＭＳの何れを用いたメッセージにあるリンクからアクセスしたか判定することができる。

実施形態に係る情報処理システム１の構成例を示すブロック図である。 実施形態に係る配信情報１２０の例を示す図である。 実施形態に係る応答情報１２１の例を示す図である。 実施形態に係る利用者端末３０に表示されるＲＣＳメッセージの例を示す図である。 実施形態に係る利用者端末３０に表示されるＲＣＳメッセージの例を示す図である。 実施形態に係るボタンＢに対応づけられた情報Ｂ＃の例を示す図である。 実施形態に係るＷｅｂｈｏｏｋ情報ＷＨの例を示す図である。 実施形態に係る利用者端末３０に表示されるＳＭＳメッセージの例を示す図である。 実施形態に係る情報処理システム１が行う処理の流れを示すシーケンス図である。 実施形態に係る情報処理システム１が行う処理の流れを示すシーケンス図である。 実施形態に係る配信サーバ１０が行う処理の流れを示すフロー図である。 実施形態に係る配信サーバ１０が行う処理の流れを示すフロー図である。 実施形態に係る配信サーバ１０が行う処理の流れを示すフロー図である。 実施形態に係る配信サーバ１０が行う処理の流れを示すフロー図である。 実施形態に係るＷｅｂサーバ４０が行う処理の流れを示すフロー図である。

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

図１は、実施形態に係る情報処理システム１の構成例を示すブロック図である。情報処理システム１は、例えば、配信サーバ１０と、通信事業者サーバ２０と、利用者端末３０と、Ｗｅｂサーバ４０とを備える。情報処理システム１におけるこれらの構成要素（配信サーバ１０と、通信事業者サーバ２０と、利用者端末３０と、Ｗｅｂサーバ４０）は、通信ネットワークＮＷを介して通信可能に接続されている。

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

通信事業者サーバ２０は、通信事業者によって管理されるサーバ装置である。通信事業者は、例えば、自らが保有又は運用する通信回線を用いて、電話番号を利用した通信サービスを利用者端末３０に提供するＭＮＯ（Mobile Network Operator、移動体通信事業者）である。通信サービスには、ＲＣＳ及びＳＭＳを用いた通信が含まれる。
通信事業者サーバ２０は、配信サーバ１０からの送信リクエストに応じて、ＲＣＳメッセージ又はＳＭＳメッセージを利用者端末３０に送信する。
通信事業者サーバ２０は、ＲＣＳに対応している利用者端末３０にＲＣＳメッセージを送信し、ＲＣＳに対応していない利用者端末３０にＳＭＳメッセージを送信する。
ＲＣＳを用いた通信サービスでは、利用者端末３０に送信したＲＣＳメッセージに対するＷｅｂｈｏｏｋ（ウェブフック）情報が、通信事業者サーバ２０を介して配信サーバ１０に送信される。Ｗｅｂｈｏｏｋ情報は、ＲＣＳメッセージのステータス、例えば、利用者端末３０にＲＣＳメッセージが受信された、或いはＲＣＳメッセージにあるボタンが操作された等の状態を示す情報である。

利用者端末３０は、スマートフォン又は携帯電話など、電話番号を対応づけることが可能な通信装置である。利用者端末３０は、ユーザ等によって、通信事業者サーバ２０の事業者と、利用者端末３０を用いた通信サービスを利用するための契約がなされる。利用者端末３０は、契約している通信事業者が提供する通信サービスを用いて通信することが可能である。利用者端末３０には電話番号が割り当てられている。
利用者端末３０はＳＭＳに対応しているが、ＲＣＳについては対応しているものと対応していないものがある。例えば、ＲＣＳのアプリケーションがインストールされ、且つＲＣＳを用いた通信に関する利用規約の同意などを含むアクティベーションが行われた場合、利用者端末３０はＲＣＳに対応している端末である。一方、ＲＣＳのアプリケーションがインストールされていない、又は、ＲＣＳのアプリケーションがインストールされているがアクティベーションが行われていない場合、利用者端末３０はＲＣＳに対応していない端末である。
利用者端末３０は、例えば、液晶ディスプレイ等の表示部と、ユーザによる操作を受け付けるタッチパネル等の操作部を有する。利用者端末３０は、通信事業者サーバ２０及び利用者端末３０を通信相手として通信ネットワークＮＷを用いた通信をする。ユーザは、例えば生活者である。

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

図１に示すように、配信サーバ１０は、通信部１１と、記憶部１２と、制御部１３とを備える。通信部１１は、通信事業者サーバ２０、及びＷｅｂサーバ４０と通信を行う。記憶部１２は、各種情報、例えば、配信情報１２０及び応答情報１２１を記憶する。配信情報１２０は、利用者端末３０に送信するＲＣＳメッセージ及びＳＭＳメッセージに関する情報である。応答情報１２１は、利用者端末３０に送信したＲＣＳメッセージに対する応答に関する情報である。

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

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

生成部１３１は、ＲＣＳメッセージを生成する。ＲＣＳメッセージは、ＲＣＳに対応している利用者端末３０に送信される。生成部１３１は、ＲＣＳメッセージとして、ＲＣＳで利用可能なメッセージ、例えば、リッチカード（図４参照）、及びチップリスト（図５参照）など用い、これらを利用することができるコンテンツ、例えばボタンＢ１（図４参照）、又はボタンＢ２（図５参照）に、ＷｅｂサイトのＵＲＬを対応づけたＲＣＳメッセージを生成する。
生成部１３１は、ＳＭＳメッセージを生成する。ＳＭＳメッセージは、利用者端末３０がＲＣＳに対応していない場合に送信される。生成部１３１は、ＳＭＳメッセージとして、ＷｅｂサイトのＵＲＬを含むテキストからなるメッセージを生成する。
ＷｅｂサイトのＵＲＬを含むメッセージを送信することにより、ユーザの操作に応じて当該ＵＲＬを指定したＷｅｂサイトへのアクセスが実行される。生成部１３１がメッセージを生成する具体的な方法については後で詳しく説明する。

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

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

図１に示すように、Ｗｅｂサーバ４０は、例えば、通信部４１と、記憶部４２と、制御部４３とを備える。通信部４１は、通信ネットワークＮＷを介して、配信サーバ１０及び利用者端末３０と通信をする。記憶部４２は、記憶媒体によって構成され、Ｗｅｂサーバ４０の各種の処理を実行するためのプログラム、及び各種の処理を行う際に利用される一時的なデータを記憶する。制御部４３は、Ｗｅｂサーバ４０を統括的に制御する。制御部４３は、Ｗｅｂサイト処理部４３０と、振分処理部４３１を備える。Ｗｅｂサイト処理部４３０は、Ｗｅｂサイトが提供するサービスを実施する。例えば、Ｗｅｂサイト処理部４３０は、Ｗｅｂサイトの画面に対して行われた操作に応じて、当該操作に応じた画面を表示させるための情報を送信する。

振分処理部４３１は、ＷｅｂサイトのＵＲＬを指定してアクセスしてきた通信装置に対し、当該通信装置がＲＣＳを用いたメッセージからアクセスしてきた装置であるか否かに応じた処理を行う。これにより、ＲＣＳを用いたメッセージからアクセスしてきた装置と、そうでない装置とで、Ｗｅｂサイトにおいて異なる対応を行うことが可能となる。例えば、ＲＣＳメッセージの状況については詳細に把握することができる場合には、ＲＣＳメッセージからアクセスしてきた装置を不正な装置ではないとみなしてその装置にＷｅｂサイトの画面を表示させるように対応することができる。一方、ＳＭＳメッセージの状況については詳細に把握することができない場合には、ＳＭＳメッセージからアクセスしてきた装置が不正な装置でないか判定し、不正な装置でないと判定した場合その装置にＷｅｂサイトの画面を表示させるように対応することができる。振分処理部４３１が、ＵＲＬを指定してアクセスしてきた通信装置に対し、ＲＣＳメッセージからアクセスしてきた装置であるか否かを判定する方法については後で詳しく説明する。

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

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

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

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

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

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

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

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

情報処理システム１で適用されるＲＣＳメッセージについて、図４～図７を用いて説明する。
図４及び図５は、実施形態に係る利用者端末３０に表示されるＲＣＳメッセージの例を示す図である。図４には、リッチカードを用いたＲＣＳメッセージの例が示されている。リッチカードには、「マイページ登録はこちら」との文言が示されたボタンＢ１が設定された例が示されている。図５には、チップリストを用いたＲＣＳメッセージの例が示されている。チップリストには「マイページへ（ログイン）」との文言が示されたボタンＢ２が設定された例が示されている。
このようなボタンＢ（ボタンＢ１、Ｂ２）には、ＵＲＬ及びポストバックデータなど情報を対応づけることができる。ボタンＢにＵＲＬが対応づけられている場合、ボタンＢがタップされる等して操作されると、ボタンＢに対応づけられたＵＲＬへのアクセスが実行される。ボタンＢにポストバックデータが対応づけられている場合、ボタンＢが操作されると、ボタンＢに対応づけられたポストバックデータを含むＷｅｂｈｏｏｋ情報が通信事業者サーバ２０から配信サーバ１０に送信される。
本実施形態では、生成部１３１によって、ボタンＢに、第１識別子及びＲＣＳ識別子が付与されたＵＲＬ、及び、第１識別子を含むポストバックデータを対応づけたＲＣＳメッセージが生成される。

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

図７は、実施形態に係るＷｅｂｈｏｏｋ情報ＷＨの例を示す図である。図７には、図６に示す情報Ｂ＃が対応づけられたボタンＢが操作された場合に、通信事業者サーバ２０から配信サーバ１０に送信されるＷｅｂｈｏｏｋ情報ＷＨの例が示されている。Ｗｅｂｈｏｏｋ情報ＷＨは、例えば、電話番号、ポストバックデータ、タイムスタンプ、及びＲＣＳメッセージＩＤのそれぞれの項目に対応する情報を含む。電話番号は、ボタンＢへの操作が行われた通信装置に割り当てられた電話番号である。ポストバックデータは、操作が行われたボタンＢに対応づけられているポストバックデータである。タイムスタンプは、ボタンＢへの操作が行われた時刻である。ＲＣＳメッセージＩＤは、ボタンＢへの操作が行われることによって利用者端末３０から通信事業者サーバ２０に通知されたＲＣＳメッセージを特定するＩＤである。ＲＣＳメッセージＩＤは、通信事業者によって付与される。

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

情報処理システム１が行う処理について、図９～図１３を用いて説明する。図９（図９Ａ、図９Ｂ）は、実施形態に係る情報処理システム１が行う処理の流れを示すシーケンス図である。
配信サーバ１０は、メッセージを生成する（ステップＳ１）。配信サーバ１０は、ボタンＢに、第１識別子及びＲＣＳ識別子が付与されたＵＲＬ、及び第１識別子を含むポストバックデータを対応づけたＲＣＳメッセージを生成する。また、配信サーバ１０は、第２識別子が付与されたＵＲＬを含むＳＭＳメッセージを生成する。配信サーバ１０は生成したＲＣＳメッセージ及びＳＭＳメッセージを配信情報１２０として記憶部１２に記憶させる。
配信サーバ１０は、通信事業者サーバ２０に対してメッセージ送信リクエストを行う（ステップＳ２）。具体的には、配信サーバ１０は、配信情報１２０を通信事業者サーバ２０に送信し、利用者端末３０にメッセージを送信するように要求する。

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

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

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

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

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

配信サーバ１０は、Ｗｅｂサイト表示判定の判定結果がＯＫである場合、利用者端末３０にリダイレクトを要求する（ステップＳ１３）。具体的には、配信サーバ１０は、ＷｅｂサイトのＵＲＬを利用者端末３０に送信して、送信したＵＲＬにアクセスするように利用者端末３０に要求する。この場合において、配信サーバ１０は、利用者端末３０に送信するＷｅｂサイトのＵＲＬにＲＣＳ識別子を付与する。利用者端末３０は、配信サーバ１０からのリダイレクト要求を受信すると、リダイレクト処理を行う（ステップＳ１４）。具体的には、利用者端末３０は、ＵＲＬに示されたＷｅｂサイトへのアクセスを実行する。ステップＳ１４以降の処理（符号Ｙ）の流れについては図９Ｂで説明する。

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

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

本実施形態では、Ｗｅｂサイトを示す画面として、例えば、認証画面を用いることができる。認証画面は、アクセスしてきた通信端末の操作者が、ＲＣＳメッセージ又はＳＭＳメッセージを送信したユーザ本人であるかを認証する本人確認を行う画面である。

ここで、認証画面にて行う認証方法の候補は、例えば、公的個人認証、オンライン個人認証、キャリア認証、顧客マスタ認証等がある。

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

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

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

顧客マスタ認証は、例えばメッセージの送信元である企業によって管理される顧客マスタを用いて本人確認を行う認証方法である。顧客マスタ認証は、「登録ＩＤを用いた認証」とも称する場合がある。
なお、顧客マスタは、メッセージの送信元である企業によって管理される情報に限定されない。例えば、メッセージの送信元とは異なる他の企業によって管理される情報を顧客マスタとして利用するようにしてもよい。ここでのメッセージの送信元とは異なる他の企業とは、例えば、ＧＡＦＡ等と呼ばれるような、比較的多くのユーザが利用するサービスを提供する企業である。このように、送信元ではない他の企業にて登録されたアカウント（顧客マスタ情報）を利用した顧客マスタ認証が行われてもよい。

Ｗｅｂサイトにて、ユーザのマイページなどユーザの個人情報を含む画面を利用者端末３０に表示させる前に、本人確認を促す認証画面を表示させる。そして、本人確認が行われ、本人であることの確認が取れた後、ユーザのマイページなどを利用者端末３０に表示させる。

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

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

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

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

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

図１２は、実施形態に係る配信サーバ１０が行う処理の流れを示すフロー図である。図１２には、図１０のステップＳ１０１に示す電話番号を照合する処理を実行する処理の流れが示されている。ここでは、Ｗｅｂｈｏｏｋ情報に含まれる電話番号と、ＵＲＬに付与された識別子に含まれる電話番号又は、個人特定識別子とを突合させることにより照合が行われる。

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

図１３は、実施形態に係る配信サーバ１０が行う処理の流れを示すフロー図である。図１３には、図１０のステップＳ１０２に示す操作時刻とアクセス時刻を比較する処理を実行する処理の流れが示されている。ここでは、ボタンＢが操作された操作時刻と、サイト等がアクセスされたアクセス時刻とが比較される。

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

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

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

以上説明したように、実施形態の情報処理システム１は、通信事業者を介して、ＲＣＳに対応している利用者端末にＲＣＳメッセージを（第１メッセージの一例）を送信し、ＲＣＳに対応していない利用者端末にＳＭＳメッセージ（第２メッセージの一例）を送信するシステムである。情報処理システム１は、生成部１３１と、振分処理部４３１とを備える。生成部１３１は、ボタン（コンテンツの一例）を含むＲＣＳメッセージを生成する。ボタンには、ＵＲＬ（ＵＲＩの一例）に第１識別子及びＲＣＳ識別子を付与した情報が対応づけられている。生成部１３１は、ＵＲＬに第２識別子を付与された情報を含むＳＭＳメッセージを生成する。振分処理部４３１は、ＵＲＬへのアクセスが実行された場合、当該アクセスにより通知されたＵＲＩに、ＲＣＳ識別子が付与されているか否かを判定する。振分処理部４３１は、ＵＲＬにＲＣＳ識別子が付与されていれば、Ｗｅｂサイトに対応する画面、例えば認証画面を表示させる処理（第１処理の一例）を行う。振分処理部４３１は、ＵＲＬにＲＣＳ識別子が付与されていなければ、ＵＲＬ改ざん判定処理（第２処理の一例）を行う。これにより、実施形態の情報処理システム１では、ＵＲＬにＲＣＳ識別子が付与されているか否かに基づいて、アクセスしてきた通信端末が、ＲＣＳ又はＳＭＳの何れを用いたメッセージにあるリンクからアクセスしたか判定することができる。したがって、リンクが示されたメッセージをＲＣＳ又はＳＭＳを用いて送信した場合において、当該リンク先にアクセスした通信装置が、ＲＣＳ又はＳＭＳの何れを用いたメッセージにあるリンクからアクセスしたか判定することができる。

また、実施形態の情報処理システム１では、第２識別子はＵＲＬから算出されるチェックデジットを含む。振分処理部４３１は、ＵＲＬ改ざん判定処理として、ＵＲＬからチェックデジットを算出し、当該算出したチェックデジットと、第２識別子に含まれるチェックデジットを比較することにより、ＵＲＬが改ざんされたか否かを判定する。これにより、実施形態の情報処理システム１では、ＳＭＳメッセージからＷｅｂサイトにアクセスしてきた場合において、リンク先として通知されたＵＲＬが改ざんされていないか判定することができる。

また、実施形態の情報処理システム１では、生成部１３１は、ボタンに、第１識別子を含むポストバックデータを対応づけたＲＣＳメッセージを生成する。このようなメッセージが作成されることにより、ＲＣＳメッセージにおけるボタンが操作された場合、通信事業者サーバ２０からボタンが操作された旨を示すＷｅｂｈｏｏｋ情報であって、ポストバックデータを含むＷｅｂｈｏｏｋ情報が通知される。情報処理システム１は、判定部１３２を更に備える。判定部１３２は、ＵＲＬへのアクセスが実行された場合、そのＵＲＬへのアクセスに対応するＷｅｂｈｏｏｋ情報が通知されたか否かを第１識別子に基づいて判定する。振分処理部４３１は、判定部１３２によってＵＲＬへのアクセスに対応するＷｅｂｈｏｏｋ情報が通知されたと判定された場合、第１処理として、ＵＲＬへのアクセスを実行した通信端末にＷｅｂサイトに対応する画面を表示させる。これにより、実施形態の情報処理システム１では、Ｗｅｂｈｏｏｋ情報を利用して、ＲＣＳメッセージにあるボタンが操作されることによりアクセスが行われたか否かを判定することができる。したがって、ＲＣＳメッセージを受信した利用者端末３０からのアクセスであることを精度よく判定することができる。

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

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

１…情報処理システム、１０…配信サーバ、２０…通信事業者サーバ、３０…利用者端末、４０…Ｗｅｂサーバ、１１…通信部、１２…記憶部、１２０…配信情報、１２１…応答情報（Ｗｅｂｈｏｏｋ情報）、１３…制御部、１３０…取得部、１３１…生成部、１３２…判定部、１３３…表示制御部、４３１…振分処理部

Claims (4)

1. 通信事業者を介して、ＲＣＳ（Rich Communication Services）に対応している利用者端末にＲＣＳを用いた第１メッセージを送信し、ＲＣＳに対応していない利用者端末にＳＭＳ（Short Message Service）を用いた第２メッセージを送信する情報処理システムであって、
   ＵＲＩ（Uniform Resource Identifier）に第１識別子及びＲＣＳ識別子を付与した情報が対応づけられたコンテンツを含む前記第１メッセージ、及び前記ＵＲＩに第２識別子を付与した情報を含む前記第２メッセージを生成する生成部と、
   前記ＵＲＩへのアクセスが実行された場合、当該アクセスされたＵＲＩに前記ＲＣＳ識別子が付与されているか否かを判定し、前記ＲＣＳ識別子が付与されていれば第１処理を行い、前記ＲＣＳ識別子が付与されていなければ前記第１処理とは異なる第２処理を行う振分処理部と、
   を備える情報処理システム。
2. 前記第２識別子は前記ＵＲＩから算出されるチェックデジットを含み、
   前記振分処理部は、前記第２処理として、前記ＵＲＩからチェックデジットを算出し、当該算出したチェックデジットと、前記第２識別子に含まれるチェックデジットを比較することにより前記ＵＲＩが改ざんされたか否かを判定する、
   請求項１に記載の情報処理システム。
3. 前記生成部は、前記コンテンツに前記第１識別子を含むポストバックデータを対応づけた前記第１メッセージを生成し、
   前記第１メッセージにおける前記コンテンツが操作された場合、前記通信事業者から前記コンテンツが操作された旨を示すＷｅｂｈｏｏｋ情報であって、前記ポストバックデータを含むＷｅｂｈｏｏｋ情報が通知され、
   前記ＵＲＩへのアクセスが実行された場合、前記ＵＲＩへのアクセスに対応する前記Ｗｅｂｈｏｏｋ情報が通知されたか否かを前記第１識別子に基づいて判定する判定部を更に備え、
   前記振分処理部は、前記判定部によって前記ＵＲＩへのアクセスに対応する前記Ｗｅｂｈｏｏｋ情報が通知されたと判定された場合、前記第１処理として、前記ＵＲＩへのアクセスを実行した通信端末にＷｅｂサイトに対応する画面を表示させる、
   請求項１又は請求項２に記載の情報処理システム。
4. 通信事業者を介して、ＲＣＳ（Rich Communication Services）に対応している利用者端末にＲＣＳを用いた第１メッセージを送信し、ＲＣＳに対応していない利用者端末にＳＭＳ（Short Message Service）を用いた第２メッセージを送信する情報処理方法であって、
   生成部が、ＵＲＩ（Uniform Resource Identifier）に第１識別子及びＲＣＳ識別子を付与した情報が対応づけられたコンテンツを含む前記第１メッセージ、及び前記ＵＲＩに第２識別子を付与した情報を含む前記第２メッセージを生成し、
   振分処理部が、前記ＵＲＩへのアクセスが実行された場合、当該アクセスされたＵＲＩに前記ＲＣＳ識別子が付与されているか否かを判定し、前記ＲＣＳ識別子が付与されていれば第１処理を行い、前記ＲＣＳ識別子が付与されていなければ前記第１処理とは異なる第２処理を行う、
   情報処理方法。