JP2023119857A - 情報処理装置、情報処理方法、及びプログラム - Google Patents
情報処理装置、情報処理方法、及びプログラム Download PDFInfo
- Publication number
- JP2023119857A JP2023119857A JP2022022958A JP2022022958A JP2023119857A JP 2023119857 A JP2023119857 A JP 2023119857A JP 2022022958 A JP2022022958 A JP 2022022958A JP 2022022958 A JP2022022958 A JP 2022022958A JP 2023119857 A JP2023119857 A JP 2023119857A
- Authority
- JP
- Japan
- Prior art keywords
- message
- information
- communication terminal
- authentication
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000010365 information processing Effects 0.000 title claims abstract description 18
- 238000003672 processing method Methods 0.000 title claims abstract description 8
- 238000004891 communication Methods 0.000 claims abstract description 234
- 238000000034 method Methods 0.000 claims abstract description 98
- 230000005540 biological transmission Effects 0.000 claims abstract description 34
- 238000009826 distribution Methods 0.000 abstract description 174
- 230000004044 response Effects 0.000 abstract description 47
- 238000003860 storage Methods 0.000 abstract description 40
- 238000012795 verification Methods 0.000 description 75
- 230000008569 process Effects 0.000 description 46
- 238000012545 processing Methods 0.000 description 38
- 238000012790 confirmation Methods 0.000 description 27
- 238000010586 diagram Methods 0.000 description 27
- 238000002716 delivery method Methods 0.000 description 12
- 230000000694 effects Effects 0.000 description 7
- 230000006870 function Effects 0.000 description 7
- 239000000284 extract Substances 0.000 description 6
- 239000000969 carrier Substances 0.000 description 3
- 238000010079 rubber tapping Methods 0.000 description 3
- 230000008520 organization Effects 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】宛先とされたユーザ以外にメッセージが届いてしまうことを抑制する情報処理装置、情報処理方法及びプログラムを提供する。【解決手段】配信サーバと、通信事業者サーバと、通信端末と、Webサーバと、を含むメッセージ配信システムにおいて、配信サーバ1は、通信部11と、記憶部12と、制御部13と、を備える。通信部11は、メッセージを送信する送信先の電話番号に対応する通信端末にインストールされたメッセージアプリを用いて、電話番号の契約者がメッセージを送信する宛先のユーザであるかを認証する認証方法を指定してもらうための候補が示されたURIへのリンクを送信する。制御部13は、候補から指定された認証方法に基づくユーザ認証が行われた結果に応じて、メッセージを送信可否の判定を行うための制御をする。【選択図】図2
Description
本発明は、情報処理装置、情報処理方法、及びプログラムに関する。
オンラインで情報を通知する電子通知サービスがある。特許文献1では、通知先のユーザがすぐに見ることのできる確率が高いメールアドレスに情報を送信する技術が開示されている。
このような電子通知サービスでは、通信事業者によって提供される携帯電話番号を宛先とするメッセージサービスがある。携帯電話番号を宛先とするメッセージサービスには、例えば、RCS(Rich Communication Services)等がある。携帯電話番号を宛先とすることにより通知先の相手のメールアドレスが不明であってもメッセージを送信することができる。
携帯電話番号を宛先としてメッセージを送信する場合、ユーザが携帯電話番号を提供する通信事業者との契約を終了していた場合には、その携帯電話番号が他のユーザに割り当てられている場合がある。そうすると、メッセージは、送信対象としていたユーザに届かず、別のユーザに届いてしまう。メッセージの内容によっては重要度が高いものもあるため、送信対象としていたユーザに届くことが望ましい。
本発明は、このような事情に鑑みてなされたもので、その目的は、宛先とされたユーザ以外にメッセージが届いてしまうことを抑制することができる情報処理装置、情報処理方法を提供することにある。
上述した課題を解決するために、本発明の一態様は、メッセージを送信する送信先の電話番号に対応する通信端末にインストールされたメッセージアプリを用いて、前記電話番号の契約者が前記メッセージを送信する宛先のユーザであるかを認証する認証方法を指定してもらうための候補が示されたURI(Uniform Resource Identifier)へのリンクを送信する送信部と、前記候補から指定された認証方法に基づくユーザ認証が行われた結果に応じて、前記メッセージを送信可否の判定を行うための制御をする制御部を有する情報処理装置である。
また、上述した課題を解決するために、本発明に係る情報処理方法は、コンピュータが行う情報処理方法であって、送信部が、メッセージを送信する送信先の電話番号に対応する通信端末にインストールされたメッセージアプリを用いて、前記電話番号の契約者が前記メッセージを送信する宛先のユーザであるかを認証する認証方法を指定してもらうための候補が示されたURI(Uniform Resource Identifier)へのリンクを送信し、制御部が、前記候補から指定された認証方法に基づくユーザ認証が行われた結果に応じて、前記メッセージを送信可否の判定を行うための制御をする。
また、上述した課題を解決するために、本発明は、コンピュータを、上記に記載の情報処理装置として動作させるためのプログラムであって、前記コンピュータを前記情報処理装置が備える各部として機能させるためのプログラムである。
本発明によれば、宛先とされたユーザ以外にメッセージが届いてしまうことを抑制することができる。
以下、本発明の一実施形態について図面を参照して説明する。
図1は、実施形態に係るメッセージ配信システムSの構成例を示すブロック図である。メッセージ配信システムSは、例えば、配信サーバ1と、通信事業者サーバ3と、通信端末4と、Webサーバ6とを含む。
配信サーバ1は、通信端末4に対するメッセージを送信するサービスを提供する事業者が管理するサーバ装置である。配信サーバ1は、通信端末4に対するメッセージを、通信事業者サーバ3を介して送信(配信)する。配信サーバ1は、電話番号を宛先とするメッセージサービスであるRCS(Rich Communication Services)を用いたRCSメッセージを送信する。配信サーバ1は、企業サーバ2、及び通信事業者サーバ3との間で無線通信又は有線通信をする。
企業サーバ2は、送信先ユーザに対するRCSメッセージの配信をメッセージ配信システムSに依頼する依頼者が管理するサーバ装置である。依頼者は、例えば、送信先ユーザに対して情報を提供する企業や団体等(例えば、銀行、保険会社等)である。企業サーバ2は、配信サーバ1との間で、無線通信又は有線通信をする。
通信事業者サーバ3(3a,3b)は、通信事業者によって管理されるサーバ装置である。通信事業者は、例えば、自らが保有又は運用する通信回線を用いた、電話番号を利用した通信サービスを通信端末4に対して提供するMNO(Mobile Network Operator、移動体通信事業者)である。
通信サービスには、RCSを用いた通信が含まれる。通信事業者サーバ3は、配信サーバ1からの送信リクエストに応じて、RCSメッセージを通信端末4に送信する。RCSを用いた通信サービスでは、通信端末4に送信したRCSメッセージに対するWebhook(ウェブフック)情報が、通信事業者サーバ20を介して配信サーバ1に送信される。Webhook情報は、RCSメッセージのステータス、例えば、通信端末4にRCSメッセージが受信された、或いはRCSメッセージにあるボタンが操作された等の状態を示す情報である。
通信事業者サーバ3は、通信端末4を利用する契約を締結したユーザとの契約に関するキャリア契約情報を記憶部に記憶している。キャリア契約情報は、例えば、ユーザの電話番号、氏名、住所、生年月日、年齢等が含まれる。また、キャリア契約情報は、通信事業者と契約ユーザとが契約をしている契約期間を含んでもよい。また、キャリア契約情報は、ユーザが利用するメッセージングサービス等のサービスに対して登録された、当該ユーザに関する顧客情報であってもよい。通信事業者サーバ3は、配信サーバ1及び通信端末4との間で、無線通信又は有線通信をする。
ここでは、通信事業者が複数ある場合には、通信事業者サーバ3も通信事業者毎に設けられる。通信事業者サーバ3aは、第1通信事業者によって管理され、通信事業者サーバ3bは、第2通信事業者によって管理される。以下、特に通信事業者サーバを識別しない場合には、通信事業者サーバ3と称する。
通信サービスには、RCSを用いた通信が含まれる。通信事業者サーバ3は、配信サーバ1からの送信リクエストに応じて、RCSメッセージを通信端末4に送信する。RCSを用いた通信サービスでは、通信端末4に送信したRCSメッセージに対するWebhook(ウェブフック)情報が、通信事業者サーバ20を介して配信サーバ1に送信される。Webhook情報は、RCSメッセージのステータス、例えば、通信端末4にRCSメッセージが受信された、或いはRCSメッセージにあるボタンが操作された等の状態を示す情報である。
通信事業者サーバ3は、通信端末4を利用する契約を締結したユーザとの契約に関するキャリア契約情報を記憶部に記憶している。キャリア契約情報は、例えば、ユーザの電話番号、氏名、住所、生年月日、年齢等が含まれる。また、キャリア契約情報は、通信事業者と契約ユーザとが契約をしている契約期間を含んでもよい。また、キャリア契約情報は、ユーザが利用するメッセージングサービス等のサービスに対して登録された、当該ユーザに関する顧客情報であってもよい。通信事業者サーバ3は、配信サーバ1及び通信端末4との間で、無線通信又は有線通信をする。
ここでは、通信事業者が複数ある場合には、通信事業者サーバ3も通信事業者毎に設けられる。通信事業者サーバ3aは、第1通信事業者によって管理され、通信事業者サーバ3bは、第2通信事業者によって管理される。以下、特に通信事業者サーバを識別しない場合には、通信事業者サーバ3と称する。
通信端末4は、スマートフォン又は携帯電話など、電話番号を対応づけることが可能な通信装置である。通信端末4は、ユーザ等によって、通信事業者サーバ3の事業者と、通信端末4を用いた通信サービスを利用するための契約がなされる。通信端末4は、契約している通信事業者が提供する通信サービスを用いて通信することが可能である。通信端末4には電話番号が割り当てられており、この電話番号を送信先とした通信、すなわちRCSを用いた通信を行う機能を有する。
通信端末4は、例えば、液晶ディスプレイ等の表示部と、ユーザによる操作を受け付けるタッチパネル等の操作部を有する。通信端末4は、通信事業者サーバ3及び通信端末4を通信相手として通信ネットワークNWを用いた通信をする。ユーザは、例えば生活者である。
通信端末4は、例えば、液晶ディスプレイ等の表示部と、ユーザによる操作を受け付けるタッチパネル等の操作部を有する。通信端末4は、通信事業者サーバ3及び通信端末4を通信相手として通信ネットワークNWを用いた通信をする。ユーザは、例えば生活者である。
署名検証サーバ5は、例えば、J-LIS(地方公共団体情報システム機構)によって運営される公的個人認証サービスを提供するサーバ装置である。
Webサーバ6は、Webサイトを運営する事業者によって管理されるサーバ装置である。WebサイトにはURL(Uniform Resource Locator)が対応づけられている。Webサーバ6は、Webサイトにアクセスしてきた通信装置に対し、Webサイトの画面に対して行われた操作に応じた画面を表示させる。URLは「URI(Uniform Resource Identifier)」の一例である。
図2に示すように、配信サーバ1は、通信部11と、記憶部12と、制御部13とを備える。通信部11は、通信事業者サーバ3、及びWebサーバ6と通信を行う。記憶部12は、各種情報、例えば、配信情報120、応答情報121、照合情報122を記憶する。
図3は、実施形態に係る配信情報120の例を示す図である。配信情報120は、メッセージごとに生成される。配信情報120は、例えば、案件特定識別子、配信単位特定識別子、個人特定識別子、及びボタン(ボタン1、ボタン2、…)のそれぞれの項目に対応する情報を含む。案件特定識別子は、送信するメッセージのカテゴリを特定するID(Identification)である。配信単位特定識別子は、送信するメッセージを特定するIDである。個人特定識別子は、ユーザが特定可能な情報であり、例えば、メッセージの送信先である電話番号である。個人特定識別子は、少なくともユーザが特定可能な情報であればよく、電話番号に限定されることはない。例えば、電話番号に紐づけられたキー情報、或いは、ユーザを特定できる情報を、個人特定識別子として用いることができる。
ボタンは、メッセージに含めることができるコンテンツであり、ユーザが操作できるコンテンツである。ボタンには、例えば、ボタンID、URL、及びポストバックデータのそれぞれに対応する情報が含まれる。ボタンIDは、メッセージに設定されたボタンを特定するIDである。URLは、ボタンが操作されることによりアクセスされるURLである。URLは「URI(Uniform Resource Identifier)」の一例である。ポストバックデータはWebhook情報に含まれる情報である。つまり、ボタンが操作されることにより、通信事業者サーバ20から配信サーバ10にWebhook情報が送信され、そのWebhook情報には、ここで設定したポストバックデータが含まれる。
ボタンは、メッセージに含めることができるコンテンツであり、ユーザが操作できるコンテンツである。ボタンには、例えば、ボタンID、URL、及びポストバックデータのそれぞれに対応する情報が含まれる。ボタンIDは、メッセージに設定されたボタンを特定するIDである。URLは、ボタンが操作されることによりアクセスされるURLである。URLは「URI(Uniform Resource Identifier)」の一例である。ポストバックデータはWebhook情報に含まれる情報である。つまり、ボタンが操作されることにより、通信事業者サーバ20から配信サーバ10にWebhook情報が送信され、そのWebhook情報には、ここで設定したポストバックデータが含まれる。
本実施形態では、配信情報120におけるポストバックデータに識別子を設定する。識別子は、(案件特定識別子、配信単位特定識別子、ボタンID、個人特定識別子)の組合せを特定する情報である。これにより、ボタンが操作された場合に、ここで設定した識別子を含むWebhook情報が通信事業者サーバ20から配信サーバ10に送信される。配信サーバ10は、識別子を含むWebhook情報を受信することにより、利用者端末30に送信した何れのメッセージにおける、何れのボタンが操作されたのかを把握することができる。
また、本実施形態では、配信情報120におけるURLに、ポストバックデータと同様な情報、すなわち、(案件特定識別子、配信単位特定識別子、ボタンID、個人特定識別子)の組合せを特定する識別子を付与する。これにより、URLを指定してアクセスしてきた通信端末が、利用者端末30に送信したメッセージに設定されたURLを用いてアクセスしてきたか否かを把握することができる。
また、本実施形態では、配信情報120におけるURLに、ポストバックデータと同様な情報、すなわち、(案件特定識別子、配信単位特定識別子、ボタンID、個人特定識別子)の組合せを特定する識別子を付与する。これにより、URLを指定してアクセスしてきた通信端末が、利用者端末30に送信したメッセージに設定されたURLを用いてアクセスしてきたか否かを把握することができる。
なお、ポストバックデータにおける識別子と、URLに付与される識別子は、少なくとも(案件特定識別子、配信単位特定識別子、ボタンID、個人特定識別子)の組合せを特定できる情報であればよい。ポストバックデータにおける識別子と、URLに付与される識別子は、同一の情報であってもよいし、異なる情報であってもよい。
図4は、実施形態に係る応答情報121の例を示す図である。応答情報121は、利用者端末30に送信したメッセージに対する反応がある、つまり、メッセージに含まれるボタンが操作されるごとに生成される。応答情報121は、例えば、電話番号、ポストバックデータ、タイムスタンプのそれぞれの項目に対応する情報を含む。応答情報121におけるこれらの情報、つまり、電話番号、ポストバックデータ、及びタイムスタンプのそれぞれの項目に対応する情報は、Webhook情報に含まれる。
電話番号は、ボタンの操作が行われた通信装置の電話番号である。ポストバックデータは、操作が行われたボタンに対応づけられているポストバックデータである。タイムスタンプは、ボタンの操作が行われた時刻を示す情報である。
電話番号は、ボタンの操作が行われた通信装置の電話番号である。ポストバックデータは、操作が行われたボタンに対応づけられているポストバックデータである。タイムスタンプは、ボタンの操作が行われた時刻を示す情報である。
照合情報122は、例えばユーザに関する情報であるユーザ情報を用いることができ、例えば、電話番号、アカウントID、氏名、住所、生年月日、性別等である。
電話番号は、通信事業者サーバ3の通信事業者とユーザとが通信端末4を利用する契約を締結する際に利用する対象の電話番号として定められた番号である。
アカウントIDは、RCSによるメッセージ配信サービスを用いたアプリケーションソフトウェアを利用するユーザ(生活者)に対して割り当てられた識別情報である。
記憶部12は、照合情報を記憶することができるが、この照合情報は企業サーバ2に記憶するようにしてもよい。また、照合情報は、配信サーバ1と企業サーバ2とは別のサーバに記憶されてもよい。照合情報が配信サーバ1以外に記憶される場合、記憶部12は、照合情報を記憶していなくてもよい。
電話番号は、通信事業者サーバ3の通信事業者とユーザとが通信端末4を利用する契約を締結する際に利用する対象の電話番号として定められた番号である。
アカウントIDは、RCSによるメッセージ配信サービスを用いたアプリケーションソフトウェアを利用するユーザ(生活者)に対して割り当てられた識別情報である。
記憶部12は、照合情報を記憶することができるが、この照合情報は企業サーバ2に記憶するようにしてもよい。また、照合情報は、配信サーバ1と企業サーバ2とは別のサーバに記憶されてもよい。照合情報が配信サーバ1以外に記憶される場合、記憶部12は、照合情報を記憶していなくてもよい。
記憶部12は、記憶媒体、例えば、HDD(Hard Disk Drive)、フラッシュメモリ、EEPROM(Electrically Erasable Programmable Read Only Memory)、RAM(Random Access read/write Memory)、ROM(Read Only Memory)、またはこれらの記憶媒体の任意の組み合わせによって構成される。記憶部12は、例えば、不揮発性メモリを用いることができる。
図2の説明に戻り、制御部13は、例えば、取得部130と、生成部131と、判定部132と、表示制御部133と、照合部134とを備える。
取得部130は、各種の情報を取得する。例えば、取得部130は、後述する生成部131によって生成されたRCSメッセージに関する情報を取得し、取得した情報を記憶部12に記憶させる。これらRCSメッセージに関する情報が記憶部12に書き込まれることで、これらの情報を配信情報120として用いることが可能となる。
取得部130は、通信事業者サーバ3から受信したWebhook情報を取得し、取得したWebhook情報を記憶部12に記憶させる。Webhook情報が記憶部12に書き込まれることで、このWebhook情報を応答情報121として用いることが可能となる。
取得部130は、企業サーバ2から受信したユーザ情報を記憶部12に書き込む。ユーザ情報が記憶部12に書き込まれることで、このユーザ情報を照合情報122として用いることが可能となる。
取得部130は、各種の情報を取得する。例えば、取得部130は、後述する生成部131によって生成されたRCSメッセージに関する情報を取得し、取得した情報を記憶部12に記憶させる。これらRCSメッセージに関する情報が記憶部12に書き込まれることで、これらの情報を配信情報120として用いることが可能となる。
取得部130は、通信事業者サーバ3から受信したWebhook情報を取得し、取得したWebhook情報を記憶部12に記憶させる。Webhook情報が記憶部12に書き込まれることで、このWebhook情報を応答情報121として用いることが可能となる。
取得部130は、企業サーバ2から受信したユーザ情報を記憶部12に書き込む。ユーザ情報が記憶部12に書き込まれることで、このユーザ情報を照合情報122として用いることが可能となる。
生成部131は、企業サーバ2からメッセージの送信依頼を受信すると、RCSメッセージを生成し、通信部11によって、通信事業者サーバ3を介して通信端末4にRCSメッセージを送信する。RCSメッセージには、通信端末4に通知する内容が含まれる。通知する内容には、例えば、テキスト、イラストなどの図や写真を含む静止画像や動画像、及び音などのデータが含まれる。メッセージを送信するにあたり、企業サーバ2は、配信サーバ1に対してメッセージの送信要求を送信することで、配信サーバ1から通信事業者サーバ3を介して、通信端末4にメッセージを送信することができる。
生成部131は、RCSメッセージを送信する送信先の電話番号に対応する通信端末4に対して、電話番号の契約者がRCSメッセージを送信する宛先のユーザであるかを認証する認証方法を複数の中から指定してもらうための候補を含むWebサイトへのリンクを含むRCSメッセージを生成し、通信部11から送信させる。ここでのWebサイトは、複数の認証方法の中からいずれかを指定してもらうための候補を含むものであってもよいが、いずれかの単一の認証方法による認証を開始することを説明するものであってもよいし、いずれかの単一の認証方法を開始してよいか否かを確認するためのものであってもよい。
ここで、認証方法の候補は、例えば、顧客マスタ認証、公的個人認証等がある。
顧客マスタ認証は、メッセージの送信元である企業によって管理される顧客マスタを用いて本人確認を行う認証方法である。顧客マスタ認証は、「登録IDを用いた認証」とも称する場合がある。
公的個人認証は、公的な証明書である個人カードを用いて本人確認を行う認証方法である。より具体的には、公的個人認証は、JPKI(公的個人認証サービス)を利用した認証方法である。この公的個人認証では、個人カードを用いる。個人カードは、例えば、個人情報を記憶可能なIC(integrated circuit)カードである。個人カードとして、より具体的には、マイナンバーカードである。公的個人認証を行う場合、電子署名を利用するためのパスワードをユーザに入力してもらい、マイナンバーカードを通信端末4によって読み取らせることで、署名検証サーバ5において公的個人認証の処理が行われ、有効性の確認が取れた場合に、ユーザの氏名、住所、生年月日、性別等の基本4情報を得ることができる。また、マイナンバーカードにおいて用いられる電子証明書のシリアル番号やその代替情報を利用して、その有効性を確認することで本人確認をするようにしてもよい。
顧客マスタ認証は、メッセージの送信元である企業によって管理される顧客マスタを用いて本人確認を行う認証方法である。顧客マスタ認証は、「登録IDを用いた認証」とも称する場合がある。
公的個人認証は、公的な証明書である個人カードを用いて本人確認を行う認証方法である。より具体的には、公的個人認証は、JPKI(公的個人認証サービス)を利用した認証方法である。この公的個人認証では、個人カードを用いる。個人カードは、例えば、個人情報を記憶可能なIC(integrated circuit)カードである。個人カードとして、より具体的には、マイナンバーカードである。公的個人認証を行う場合、電子署名を利用するためのパスワードをユーザに入力してもらい、マイナンバーカードを通信端末4によって読み取らせることで、署名検証サーバ5において公的個人認証の処理が行われ、有効性の確認が取れた場合に、ユーザの氏名、住所、生年月日、性別等の基本4情報を得ることができる。また、マイナンバーカードにおいて用いられる電子証明書のシリアル番号やその代替情報を利用して、その有効性を確認することで本人確認をするようにしてもよい。
なお、認証方法の候補としてオンライン個人認証、キャリア認証が含まれていてもよい。オンライン個人認証は、本人の容貌(例えば、顔)を示す画像を含む情報に基づいてオンラインによって本人確認を行う認証方法であり、例えば、eKYC(electronic Know Your Customer)である。キャリア認証は、電話番号を利用した通信サービスを提供する通信端末の通信事業者と契約ユーザとの契約に関するキャリア契約情報を用いて本人確認を行う認証方法である。
生成部131は、重要な通知内容を含むRCSメッセージを通信端末4に送信する前に、本人確認を促すためのRCSメッセージを生成して通信端末4に送信する。そして、配信サーバ1は、本人確認が行われ、本人であることの確認が取れた後、重要な通知内容を含むRCSメッセージを通信端末4に送信する。ここでは、生成部131は、本人確認を促すためのRCSメッセージに、認証方法の候補から選択可能な選択肢を示すWebサイト(以下、認証サイトともいう)へのリンクを含むようにしてRCSメッセージを生成する。
ここで生成部131が、本人確認を促すためのRCSメッセージを生成する方法について、図5及び図6を用いて説明する。
図5は、実施形態に係る通信端末4に表示される、本人確認を促すためのRCSメッセージの例を示す図である。通信端末4の表示画面には、企業サーバ2から依頼されたメッセージが表示される前に、本人確認を促す内容(符号M01)が表示されるとともに、認証サイトへのリンクを示すURLが表示される。
図5の例に示すように、生成部131は、本人確認を促すためのRCSメッセージとして、RCSで利用可能なメッセージ、例えば、リッチカード及びチップリストなどが利用できるコンテンツ、例えばボタンBに、認証サイトへのリンクを示すURLを対応づけたRCSメッセージを生成する。
図5の例に示すように、生成部131は、本人確認を促すためのRCSメッセージとして、RCSで利用可能なメッセージ、例えば、リッチカード及びチップリストなどが利用できるコンテンツ、例えばボタンBに、認証サイトへのリンクを示すURLを対応づけたRCSメッセージを生成する。
図6は、実施形態に係るボタンBに対応づけられた情報B#の例を示す図である。図6には、図5に示すボタンBに対応づけられた情報の例が、情報B#として示されている。情報B#は、例えば、URL及びポストバックデータのそれぞれの項目に対応する情報を含む。URLは特定のWebサイト(例えば、認証サイト)を示す情報である。URLには、識別子が付与されている。識別子は、(案件特定識別子、配信単位特定識別子、ボタンID、個人特定識別子)の組合せを特定する情報である。ポストバックデータには識別子が含まれる。
図6の例に示すように、生成部131は、ボタンBに、識別子を付与した認証サイトのURL、及び識別子を含むポストバックデータを対応づけたRCSメッセージを生成する。
図6の例に示すように、生成部131は、ボタンBに、識別子を付与した認証サイトのURL、及び識別子を含むポストバックデータを対応づけたRCSメッセージを生成する。
図2の説明に戻り、判定部132は、認証サイトへアクセスしてきた通信装置が、RCSメッセージを送信した通信端末4であるか否かを判定する。認証サイトのURLを対応づけたRCSメッセージを通信端末4に送信した場合において認証サイトのURLが他のユーザに知られてしまい、他のユーザによって認証サイトが閲覧されてしまうような不当なアクセスがなされる可能性がある。判定部132が、認証サイトへアクセスしてきた通信装置が、RCSメッセージを送信した通信端末4であるか否かを判定することにより、このような不当なアクセスを抑制することができる。判定部132が判定を行う具体的な方法については後で詳しく説明する。
表示制御部133は、通信装置に表示させる内容を制御する。ここでの通信装置は、通信端末4、及び他のユーザの端末装置を含む。表示制御部133は、判定部132による判定結果に基づいて、認証サイトへアクセスしてきた通信装置が、RCSメッセージを送信した通信端末4である場合、通信端末4に認証サイトに対応する画面を表示させる。一方、表示制御部133は、判定部132によって認証サイトへアクセスしてきた通信装置がメッセージを送信した通信端末4でないと判定された場合、その通信端末4ではない通信装置にエラー画面を表示させる。エラー画面は、例えば、認証サイトにアクセスできないことを示す画面である。
照合部134は、認証サイトに示された選択肢から選択された認証方法に基づくユーザ認証が行われた結果に応じて、重要な通知内容を含むRCSメッセージの送信可否の判定を行う。
照合部134は、照合情報122と認証情報とを照合し、確認条件を満たすか否かを判定することで、重要な通知内容を含むRCSメッセージの送信可否を判定することができる。認証情報は、通信端末4のユーザがメッセージを送信する宛先のユーザであるか否かの本人確認をするために、ユーザの操作入力に応じて得られるユーザに関する情報である。
ここで確認条件は、例えば、照合情報に含まれる項目のうち氏名、住所、生年月日、性別等のいずれかの所定項目の内容が、認証情報に含まれる項目のうち、当該所定項目の内容と一致することであってもよい。
照合部134は、確認条件を満たすと判定した場合には、本人確認が取れたと判定することができる。すなわち、メッセージを送信する送信先の電話番号の契約者と、メッセージを送信する宛先のユーザとが一致し、本人であることが確認できたと見なすことができる。
この照合は、配信サーバ1が行う場合もあるが、企業サーバ2または通信事業者サーバ3、或いは署名検証サーバ5が照合を行うようにしてもよい。この場合、制御部13は、選択肢から選択された認証方法に基づくユーザ認証が行われた結果に応じて、重要な通知内容を含むRCSメッセージの送信可否の判定を行うための制御をする。
照合部134は、照合情報122と認証情報とを照合し、確認条件を満たすか否かを判定することで、重要な通知内容を含むRCSメッセージの送信可否を判定することができる。認証情報は、通信端末4のユーザがメッセージを送信する宛先のユーザであるか否かの本人確認をするために、ユーザの操作入力に応じて得られるユーザに関する情報である。
ここで確認条件は、例えば、照合情報に含まれる項目のうち氏名、住所、生年月日、性別等のいずれかの所定項目の内容が、認証情報に含まれる項目のうち、当該所定項目の内容と一致することであってもよい。
照合部134は、確認条件を満たすと判定した場合には、本人確認が取れたと判定することができる。すなわち、メッセージを送信する送信先の電話番号の契約者と、メッセージを送信する宛先のユーザとが一致し、本人であることが確認できたと見なすことができる。
この照合は、配信サーバ1が行う場合もあるが、企業サーバ2または通信事業者サーバ3、或いは署名検証サーバ5が照合を行うようにしてもよい。この場合、制御部13は、選択肢から選択された認証方法に基づくユーザ認証が行われた結果に応じて、重要な通知内容を含むRCSメッセージの送信可否の判定を行うための制御をする。
図7は、通信端末4の表示画面に認証サイトが表示された場合の一例を示す図である。通信端末4の表示画面には、認証方法を選択する選択肢(符号M02)が表示される。選択肢は、少なくとも1つ表示される。この図の例では、4つの選択肢が表示された場合が図示されている。ユーザは、この選択肢のなかから認証方法を選び、希望する認証方法の選択肢を画面上においてタップ(操作入力)する。これにより、選択肢のなかから認証方法を選択することができる。この画面においては、4つの選択肢が表示される場合について図示されているが、選択肢が1つのみの場合であってもよいし、選択肢が4つ以外の複数であってもよい。選択肢が1つのみ表示される場合、当該1つの選択肢をユーザに選択させるようにしてもよいし、ユーザに選択させることなく、直接、当該1つの選択肢に基づく認証を始めるようにしてもよい。
[メッセージ配信方法のシーケンス]
以下、メッセージ配信方法のシーケンスについて説明する。以下の実施形態においては、企業サーバ2と配信サーバ1とが別の装置であって、異なる企業によって運用される場合について説明するが、配信サーバ1の機能が搭載された企業サーバ2を、企業が運用するようにしてもよい。この場合、企業サーバ2の企業は、配信サーバ1の事業者を介することなく、通信事業者サーバ3と通信し、RCSメッセージを送信することができる。
また、企業サーバ2の機能が搭載された配信サーバ1を、配信サーバ1の事業者が運用するようにしてもよい。この場合、配信サーバ1の事業者は、外部の企業からの依頼を受けていなくても、配信サーバ1の事業者の意向に応じてRCSメッセージの配信を行うことができる。
以下、メッセージ配信方法のシーケンスについて説明する。以下の実施形態においては、企業サーバ2と配信サーバ1とが別の装置であって、異なる企業によって運用される場合について説明するが、配信サーバ1の機能が搭載された企業サーバ2を、企業が運用するようにしてもよい。この場合、企業サーバ2の企業は、配信サーバ1の事業者を介することなく、通信事業者サーバ3と通信し、RCSメッセージを送信することができる。
また、企業サーバ2の機能が搭載された配信サーバ1を、配信サーバ1の事業者が運用するようにしてもよい。この場合、配信サーバ1の事業者は、外部の企業からの依頼を受けていなくても、配信サーバ1の事業者の意向に応じてRCSメッセージの配信を行うことができる。
[第1実施形態:顧客マスタ認証,照合情報を配信サーバが持つ場合]
図8A、図8Bは、本実施形態に係るメッセージ配信システムSが実行するメッセージ配信方法のシーケンス図である。
本実施形態では、顧客マスタとして予め記憶された情報と、ユーザから入力される情報とを用いて本人確認を行う。
なお、顧客マスタは、メッセージの送信元である企業によって管理される情報に限定されない。例えば、メッセージの送信元とは異なる他の企業によって管理される情報を顧客マスタとして利用するようにしてもよい。ここでのメッセージの送信元とは異なる他の企業とは、例えば、GAFA等と呼ばれるような、比較的多くのユーザが利用するサービスを提供する企業である。このように、送信元ではない他の企業にて登録されたアカウント(顧客マスタ情報)を利用した顧客マスタ認証が行われてもよい。
図8A、図8Bは、本実施形態に係るメッセージ配信システムSが実行するメッセージ配信方法のシーケンス図である。
本実施形態では、顧客マスタとして予め記憶された情報と、ユーザから入力される情報とを用いて本人確認を行う。
なお、顧客マスタは、メッセージの送信元である企業によって管理される情報に限定されない。例えば、メッセージの送信元とは異なる他の企業によって管理される情報を顧客マスタとして利用するようにしてもよい。ここでのメッセージの送信元とは異なる他の企業とは、例えば、GAFA等と呼ばれるような、比較的多くのユーザが利用するサービスを提供する企業である。このように、送信元ではない他の企業にて登録されたアカウント(顧客マスタ情報)を利用した顧客マスタ認証が行われてもよい。
企業サーバ2は、ユーザにメッセージを送信する際に利用する送信データを生成する。この送信データは、送信するメッセージ本文を生成するために必要な情報と、ユーザに関する情報が含まれる。
企業サーバ2は、送信データを生成するにあたり、メッセージ本文について、企業サーバ2に記憶された情報に基づいて生成する。メッセージ本文は、例えば、あるサービスを利用したことに応じてユーザに対して費用を請求する請求金額を知らせる内容であり、通信端末4の表示画面等において出力される内容である。より具体的には、「今月の○○サービスの利用料は、○○円です。」等の内容である。
企業サーバ2は、送信データを生成するにあたり、ユーザに関する情報について、企業サーバ2に記憶されたユーザ情報を読み出す。
ユーザ情報は、例えば、電話番号、アカウントID、氏名、住所、生年月日、性別等を含む。ユーザ情報に含まれる少なくとも一部の情報を、本人確認を行う上で照合に用いる照合情報122として利用することができる。
企業サーバ2は、送信データを生成するにあたり、メッセージ本文について、企業サーバ2に記憶された情報に基づいて生成する。メッセージ本文は、例えば、あるサービスを利用したことに応じてユーザに対して費用を請求する請求金額を知らせる内容であり、通信端末4の表示画面等において出力される内容である。より具体的には、「今月の○○サービスの利用料は、○○円です。」等の内容である。
企業サーバ2は、送信データを生成するにあたり、ユーザに関する情報について、企業サーバ2に記憶されたユーザ情報を読み出す。
ユーザ情報は、例えば、電話番号、アカウントID、氏名、住所、生年月日、性別等を含む。ユーザ情報に含まれる少なくとも一部の情報を、本人確認を行う上で照合に用いる照合情報122として利用することができる。
また、ここでは、メッセージ本文は必須ではないがユーザにメッセージを送信する場合には、伝える内容として一般的には含まれる。また、送信データには、ユーザ情報を含むようにしても良い。
本実施形態においては、顧客マスタを記憶するデータベースは、配信サーバ1と企業サーバ2とのいずれに備えられていてもよいが、配信サーバ1に備えられた場合について説明する。
企業サーバ2は、送信先ユーザの電話番号と、照合情報と、送信先ユーザに対して送信するメッセージ本文を生成するために必要な情報とを含む配信依頼を、配信サーバ1に送信する(ステップS1101)。配信サーバ1の通信部11は、企業サーバ2から、電話番号、照合情報及びメッセージ本文を生成するために必要な情報を含む配信依頼を受信する。
ここでは、企業サーバ2からメッセージを送信対象の人数が1人である場合について説明するが、複数のユーザにそれぞれ送信することもできる。
ここでは、企業サーバ2からメッセージを送信対象の人数が1人である場合について説明するが、複数のユーザにそれぞれ送信することもできる。
配信サーバ1は、企業サーバ2から送信された送信データを受信し、データ処理を行う(ステップS1201)。配信サーバ1は、データ処理として、送信データに含まれる照合情報の抽出をし、送信データに含まれる、メッセージ本文を生成するために必要な情報の抽出をする。その後、配信サーバ1は、抽出された照合情報を記憶部12に書き込む(ステップS1202)。
ここで記憶部12に記憶される情報は、例えば、電話番号、アカウントID、氏名、生年月日、住所、性別である。このアカウントIDは、企業サーバ2において付与された番号であってもよいし、配信サーバ1の事業者によって付与された番号であってもよい。
ここで記憶部12に記憶される情報は、例えば、電話番号、アカウントID、氏名、生年月日、住所、性別である。このアカウントIDは、企業サーバ2において付与された番号であってもよいし、配信サーバ1の事業者によって付与された番号であってもよい。
配信サーバ1は、抽出されたメッセージ本文を生成するために必要な情報と、照合情報に含まれる電話番号とに基づいてメッセージを生成する(ステップS1203)。メッセージは、送信先を示す電話番号と、メッセージ本文等を含むデータである。配信サーバ1の生成部131は、企業サーバ2から受信したメッセージ本文に対して、本人認証を促すための文章や、認証サイトへのリンクを示すURLを付加する。
認証サイトにて示される本人認証を行う認証方法を選択するための選択肢は、任意の選択肢であってもよいが、企業サーバ2の企業、配信サーバ1の事業者、通信事業者サーバ3のキャリア等のうちいずれかによって決められていてもよいし、企業サーバ2から配信サーバ1に送信される送信データに予め含まれていてもよい。
認証サイトにて示される本人認証を行う認証方法を選択するための選択肢は、任意の選択肢であってもよいが、企業サーバ2の企業、配信サーバ1の事業者、通信事業者サーバ3のキャリア等のうちいずれかによって決められていてもよいし、企業サーバ2から配信サーバ1に送信される送信データに予め含まれていてもよい。
配信サーバ1は、本人確認を要求する内容を含むメッセージを生成すると、RCSを利用し、電話番号を送信先として送信する(ステップS1204)。ここでは、配信サーバ1は、複数あるキャリアのうち、RCSメッセージに設定された電話番号に対応するキャリアの通信事業者サーバ3を介して通信端末4に送信する。
通信端末4は、配信サーバ1から通信事業者サーバ3を介し、本人確認を促す内容を含むRCSメッセージを受信する(ステップS1401)。ここで、通信端末4は、RCSに係るアプリケーションプログラム(RCSアプリ)がインストールされており、配信サーバ1からRCSメッセージを受信できる。本人確認を促す内容を含むRCSメッセージには、本人確認を促す内容、例えば、「重要なお知らせがありますので、本人確認をお願いいたします。」という文字列と共に、認証サイトへのリンクを示すURLが画面に表示される。
通信端末4は、受信したRCSメッセージに示された認証サイトのURLがユーザによってタップされることによって、認証サイト(Webサーバ6)にアクセスする(ステップS1402)。これにより、Webサーバ6から認証サイトに係る情報が通信端末4に送信され、認証サイトに係る情報が通信端末4の表示画面に表示される。認証サイトに認証方法を選択する選択肢も含まれている場合には、その選択肢が表示される。例えば、「登録IDを用いた認証を行う」、「マイナンバー認証を行う」、「キャリア認証を行う」、「その他の公的書類を用いたオンライン身元確認を行う」の4つの選択肢が表示される。ここで「登録IDを用いた認証」は、顧客マスタ認証に対応する。また、「マイナンバー認証」は、公的個人認証に対応する。
通信端末4は、ユーザによって入力される、本人確認をする認証方法を選択するための選択肢に対する操作入力を受け付ける(ステップS1403)。ユーザによってタッチパネル上の「登録IDを用いた認証」のボタンに対してタップされると、通信端末4は、「登録IDを用いた認証」の操作入力を受け付け、受け付けた操作入力を用いてWebサーバ6と通信を行い、Webサーバ6から受信した情報に基づいて認証情報の入力を受け付ける認証画面を表示する(ステップS1404)。例えば、「認証情報を入力して下さい」等の認証情報の入力を促すための内容を表す文字列を表示する。
認証情報を入力してもらう機能は、RCSアプリとは別のアプリケーションソフトウェアによって実現するようにしてもよいし、ブラウザによって実現してもよい。また、対話式メッセンジャーアプリケーションを用いる、あるいは、RCSのシナリオ内において完結できるようにRCSメッセージ内において、「生年月日は?」、「認証コードは?」等のように、認証情報についてユーザに質問をし、ユーザに回答として認証情報を入力してもらうようにしてもよい。質問は、1つでも複数でもよい。質問が複数である場合には、各質問を順次行い、全ての質問にそれぞれ回答してもらってから、回答が正しいかを照合するようにしてもよいし、質問に対する回答が得られる毎に、回答が正しいかを照合するようにしてもよい。RCSのシナリオとは、RCSメッセージ内において、ユーザに対する質問をし、ユーザから入力される回答の入力を受け付けることができるものであって、質問の内容と質問の順序が予め準備されたメッセージである。
ここで、ステップS1403において「登録IDを用いた認証」のボタンがタップされた後、ステップS1404の認証画面を表示する場合について説明するが、この認証画面を表示しないようにしてもよい。例えば、「登録IDを用いた認証」のボタンがタップされた後、RCSアプリが、認証情報を入力するための質問事項を表示し、ユーザから回答として認証情報を入力してもらうようにしてもよい。
ここで、ステップS1403において「登録IDを用いた認証」のボタンがタップされた後、ステップS1404の認証画面を表示する場合について説明するが、この認証画面を表示しないようにしてもよい。例えば、「登録IDを用いた認証」のボタンがタップされた後、RCSアプリが、認証情報を入力するための質問事項を表示し、ユーザから回答として認証情報を入力してもらうようにしてもよい。
ここで、認証情報は、本人確認をする対象のユーザのみ知り得る情報であることが望ましい。認証情報としては、例えば、パスワード、認証コード、郵便番号、生年月日、氏名等の情報のうち、少なくとも1つを用いるようにしてもよい。
パスワードは、ユーザに関する情報を顧客マスタに登録する際にユーザに対して発行されたあるいはユーザから指定してもらった文字列である。
パスワードは、ユーザに関する情報を顧客マスタに登録する際にユーザに対して発行されたあるいはユーザから指定してもらった文字列である。
ユーザは、認証情報の入力画面が表示されると、認証情報を入力する(ステップS1406)。通信端末4は、回答が入力されると、入力された回答である認証情報と、通信端末4に割り当てられている電話番号とをWebサーバ6に送信する(ステップS1407)。
Webサーバ6は、通信端末4から認証情報と電話番号とを受信すると、認証情報と電話番号とを配信サーバ1に送信(中継)する(ステップS1601)。
配信サーバ1は、Webサーバ6から認証情報と電話番号とを受信すると(ステップS1208)、ステップS1202において記憶部12に記憶された照合情報のうち受信した電話番号に対応付けられた照合情報と、受信した認証情報とが対応関係にあるか照合をし(ステップS1209)、確認条件を満たすか否かを判定する(ステップS1210)。
ここで確認条件としては、照合情報と認証情報とが一致することである。認証情報として、氏名と生年月日が用いられる場合、ユーザから入力された氏名及び生年月日と、照合情報に含まれる氏名及び生年月日がそれぞれ一致するか否かである。
また、認証情報としてパスワードを用いる場合には、ユーザから入力されたパスワードと、照合情報として記憶されているパスワードとが一致することである。また、認証情報として認証コードを用いる場合には、ユーザから入力された認証コードと、別の経路でメッセージの送信先のユーザに対して発行された認証コードとが一致することである。
配信サーバ1は、Webサーバ6から認証情報と電話番号とを受信すると(ステップS1208)、ステップS1202において記憶部12に記憶された照合情報のうち受信した電話番号に対応付けられた照合情報と、受信した認証情報とが対応関係にあるか照合をし(ステップS1209)、確認条件を満たすか否かを判定する(ステップS1210)。
ここで確認条件としては、照合情報と認証情報とが一致することである。認証情報として、氏名と生年月日が用いられる場合、ユーザから入力された氏名及び生年月日と、照合情報に含まれる氏名及び生年月日がそれぞれ一致するか否かである。
また、認証情報としてパスワードを用いる場合には、ユーザから入力されたパスワードと、照合情報として記憶されているパスワードとが一致することである。また、認証情報として認証コードを用いる場合には、ユーザから入力された認証コードと、別の経路でメッセージの送信先のユーザに対して発行された認証コードとが一致することである。
配信サーバ1は、確認条件を満たしていないと判定した場合には(ステップS1210-NG)、確認条件を満たしていないことを表すメッセージを生成する(ステップS1211)。その後、第1実施形態のステップS1212、ステップS1409と同様の処理が行われる。これにより、通信端末4は、確認条件を満たしていないことを表すメッセージを表示画面に表示する。なお、確認条件を満たしていないと判定された場合に、確認条件を満たしていないことを表すメッセージを配信サーバ1から通信端末4に送信しなくてもよい。また、通信端末4は、確認条件を満たしていないことを表すメッセージを表示しなくてもよい。
配信サーバ1は、確認条件を満たしていると判定した場合には(ステップS1210-OK)には、送信データに含まれるメッセージ本文を生成するために必要な情報に基づくメッセージを生成する(ステップS1213)。その後、第1実施形態のステップS1214、ステップS1410と同様の処理が行われる。これにより、通信端末4は、配信サーバ1から送信されたメッセージを表示する。通信端末4は、メッセージを表示するとともに、確認が完了したこと(確認条件を満たしていること)を表示してもよい。
[本実施形態の効果]
本実施形態によれば、配信サーバ1に顧客マスタとして記憶された照合情報を利用して本人確認を行うことができる。そのため、本人確認を行うにあたり、他の機器と連携しなくても本人確認をすることができる。
なお、上述した実施形態では配信サーバ1が照合及び確認条件を満たしているか否かを判定する場合を例示して説明したがこれに限定されない。例えば、Webサーバ6が照合情報を備え、Webサーバ6が照合及び確認条件を満たしているか否かを判定し、確認条件を満たしている場合にその旨を配信サーバ1に通知することにより、メッセージ本文を配信する指示を行うように構成されてもよい。
本実施形態によれば、配信サーバ1に顧客マスタとして記憶された照合情報を利用して本人確認を行うことができる。そのため、本人確認を行うにあたり、他の機器と連携しなくても本人確認をすることができる。
なお、上述した実施形態では配信サーバ1が照合及び確認条件を満たしているか否かを判定する場合を例示して説明したがこれに限定されない。例えば、Webサーバ6が照合情報を備え、Webサーバ6が照合及び確認条件を満たしているか否かを判定し、確認条件を満たしている場合にその旨を配信サーバ1に通知することにより、メッセージ本文を配信する指示を行うように構成されてもよい。
[第2実施形態:公的個人認証を用いる場合]
図9A、図9Bは、本実施形態に係るメッセージ配信システムSが実行するメッセージ配信方法のシーケンス図である。
この実施形態では、署名検証サーバ5における公的個人認証を利用して得られる個人情報と照合情報とを用いて本人確認をする場合について説明する。
図9A、図9Bは、本実施形態に係るメッセージ配信システムSが実行するメッセージ配信方法のシーケンス図である。
この実施形態では、署名検証サーバ5における公的個人認証を利用して得られる個人情報と照合情報とを用いて本人確認をする場合について説明する。
この第2実施形態において、ステップS1101、ステップS1201からS1204、ステップS1401、ステップS1402までの処理は、第1実施形態と同じであるので、同一の符号を付し、その説明を省略する。
ステップS1403Aにおいて、通信端末4は、通信端末4を利用している契約ユーザによって操作入力される、本人確認をする認証方法を選択する選択肢に対する操作入力を受け付ける(ステップS1403A)。ユーザによってタッチパネル上の「公的個人認証を行う」のボタンに対してタップされると、通信端末4は、「公的個人認証を行う」の操作入力を受け付け、受け付けた操作入力を用いてWebサーバ6と通信を行い、Webサーバ6から受信した情報に基づいて公的個人認証を行うためのアプリケーションソフトウェア(以下、公的個人認証アプリ)を実行し、公的個人認証を行うための画面を表示する(ステップS1404A)。ここでは、「パスワードを入力し、個人カードを端末に読み取らせてください」等のように、パスワードの入力と個人カードの読み取りを促す文字列が表示される。
ユーザによってパスワードが入力され、通信端末4のリーダに個人カードが近づけられると、通信端末4は、パスワードの入力を受け付け、個人カードに対してパスワードを送信する。入力されたパスワードが個人カードに記憶されたパスワードと一致する場合(ステップS1406A-OK)、個人カードは、個人カードに記憶された電子証明書を通信端末4に出力する。通信端末4は、個人カードから出力される電子証明書を受信する。
一方、入力されたパスワードが個人カードに記憶されたパスワードと一致しない場合(ステップS1406A-NG)、個人カードは、パスワードが一致しないことを表す応答信号を通信端末4に出力する。通信端末4は、この応答信号を受信すると、表示画面に「パスワードが一致しませんでした。パスワードを入力し直してください」等の文字列を表示し、ステップS1405に移行する。なお、パスワードを入力しなおしても一致しない回数が一定数に到達した場合には、個人カードの利用が停止(ロック)される場合もある。
一方、入力されたパスワードが個人カードに記憶されたパスワードと一致しない場合(ステップS1406A-NG)、個人カードは、パスワードが一致しないことを表す応答信号を通信端末4に出力する。通信端末4は、この応答信号を受信すると、表示画面に「パスワードが一致しませんでした。パスワードを入力し直してください」等の文字列を表示し、ステップS1405に移行する。なお、パスワードを入力しなおしても一致しない回数が一定数に到達した場合には、個人カードの利用が停止(ロック)される場合もある。
ここでは通信端末4が公的個人認証処理を行う場合、公的個人認証アプリを実行する場合について説明したが、アプリケーションソフトウェアを実行するのではなく、ブラウザによって公的個人認証サービスを提供するサイトにアクセスし、パスワードの入力や個人カードの読み取り等を行うことで、公的個人認証処理を行うようにしてもよい。また、公的個人認証アプリとは別のアプリケーションソフトウェアを実行し、パスワードの入力の受け付けや、パスワードの一致判定を行い、判定結果を公的個人認証アプリに戻すようにしてもよい。
また、ここでは通信端末4が個人カードと通信を行い、電子証明書を取得する場合について説明したが、個人カードに記憶された情報を通信端末4に設けられたメモリに記憶させておき、個人カードを読み取るのではなく、このメモリにアクセスするようにしてもよい。例えば、通信端末4は、ユーザからパスワードが入力されると、内部のメモリを参照し、パスワードが一致する場合には、電子証明書をメモリから読み出すようにしてもよい。
また、ここでは通信端末4が個人カードと通信を行い、電子証明書を取得する場合について説明したが、個人カードに記憶された情報を通信端末4に設けられたメモリに記憶させておき、個人カードを読み取るのではなく、このメモリにアクセスするようにしてもよい。例えば、通信端末4は、ユーザからパスワードが入力されると、内部のメモリを参照し、パスワードが一致する場合には、電子証明書をメモリから読み出すようにしてもよい。
また、パスワードを用いた認証の代わりに、生体認証を行うようにしてもよい。生体認証としては、例えば、指紋認証、顔認証、虹彩認証等であってもよい。
通信端末4は、入力されたパスワードが個人カードに記憶されたパスワードと一致することで個人カードから電子証明書を受信すると、受信した電子証明書をWebサーバ6に送信する(ステップS1407A)。ここでは、通信端末4は、電子証明書を送信するだけでなく、この電子証明書がどのユーザの電子証明書であるかを識別可能な情報を関連付け情報(紐付けキー)として、電子証明書とともに送信する。紐付けキーとしては、例えば、通信端末4に割り当てられた電話番号や、公的個人認証アプリにおいて割り当てられたアカウントIDであってもよいし、トークン情報(例えばワンタイムパスワード等)であってもよい。ただし、電子証明書の送信元がいずれの通信端末4であるかを識別できるのであれば、必ずしも紐付けキーを送信しなくてもよい。
Webサーバ6は、通信端末4から電子証明書と紐付けキーとを受信すると、電子証明書と紐付けキーとを署名検証サーバ5に送信(中継)する(ステップS1601A)。
ここでは、電子証明書と紐付けキーとについて、通信端末4からWebサーバ6に送信し、Webサーバ6が署名検証サーバ5に送信する場合について説明したが、Webサーバ6による中継を行わず、通信端末4が署名検証サーバ5に電子証明書と紐付けキーとを送信するようにしてもよい。Webサーバ6による中継を行わない場合、通信端末4は、署名検証サーバ5に電子証明書と紐付けキーとともに、認証結果の通知先がWebサーバ6であることを示す情報も送信する。
ここでは、電子証明書と紐付けキーとについて、通信端末4からWebサーバ6に送信し、Webサーバ6が署名検証サーバ5に送信する場合について説明したが、Webサーバ6による中継を行わず、通信端末4が署名検証サーバ5に電子証明書と紐付けキーとを送信するようにしてもよい。Webサーバ6による中継を行わない場合、通信端末4は、署名検証サーバ5に電子証明書と紐付けキーとともに、認証結果の通知先がWebサーバ6であることを示す情報も送信する。
署名検証サーバ5は、配信サーバ1から電子証明書と紐付けキーとを受信すると、電子証明書が有効であるか否かに基づく認証処理を行う(ステップS1501)。署名検証サーバ5は、電子証明書が有効であると判定した場合には(ステップS1502-OK)、電子証明書に対応する個人情報を記憶部から読み出し、個人情報と紐付けキーとを配信サーバ1に送信し、認証処理において電子証明書が無効であると判定した場合には(ステップS1502-NG)、無効である旨の応答信号をWebサーバ6に送信する。ここでは、署名検証サーバ5からWebサーバ6に確認結果や基本4情報を送信する場合について説明するが、Webサーバ6から署名検証サーバ5へ基本4情報を取得しにいってもよい。
ここで送信される個人情報は例えば、ユーザの氏名、住所、生年月日、性別(基本4情報)を含む。
ここで送信される個人情報は例えば、ユーザの氏名、住所、生年月日、性別(基本4情報)を含む。
Webサーバ6は、電子証明書が無効である旨の応答信号を署名検証サーバ5から受信すると、応答信号を配信サーバ1に送信(中継)する(ステップS1602)。配信サーバ1は、応答信号をWebサーバ6から受信すると、電子証明書が無効であることを表すメッセージを生成し(ステップS1206)、生成されたメッセージを通信端末4に対してRCSによって送信する(ステップS1207)。ここで生成されるメッセージは、電子証明書が無効であることを表す内容を含むようにしてもよいし、電子証明書が無効であることと再度認証をしてもらうように促す内容とを含むようにしてもよい。
通信端末4は、配信サーバ1からメッセージを受信すると(ステップS1408)、受信したメッセージを表示画面に表示する。例えば表示画面には、「本人確認ができませんでした。再度認証を行ってください」等の文字列が表示される。
通信端末4は、配信サーバ1からメッセージを受信すると(ステップS1408)、受信したメッセージを表示画面に表示する。例えば表示画面には、「本人確認ができませんでした。再度認証を行ってください」等の文字列が表示される。
配信サーバ1は、電子証明書が有効であると判定されたことに応じて、署名検証サーバ5から公的個人認証の結果として、個人情報(基本4情報)と紐付けキーとを受信すると(ステップS1208A)、ステップS1202において記憶部12に記憶された照合情報と、受信した個人情報とが対応関係にあるか照合をする(ステップS1209A)。ここでは、記憶部12に複数のユーザについての照合情報が記憶されているが、今回署名検証サーバ5からWebサーバ6を介して受信した紐付けキーに基づいて、記憶部12から照合する対象の照合情報を読み出し、読み出した照合情報と個人情報とを照合することができる。
また、個人カードがマイナンバーカードである場合、署名検証サーバ5から得られる情報(基本4情報:住所、氏名、生年月日、性別)は、最新の情報である。すなわち、引っ越しがあった場合であっても、ユーザが地方自治体に対して引っ越しの手続(転出届、転入届等)を行うことで、引っ越しされた後の新しい住所が署名検証サーバ5に登録される。そのため、配信サーバ1は、最新の住所を得ることができる。また、ユーザの氏名に変更があった場合、ユーザが地方自治体に対して氏名に関する変更の手続きを行うことで、変更後の氏名が署名検証サーバ5に登録される。そのため、配信サーバ1は、最新の氏名を得ることができる。
また、個人カードがマイナンバーカードである場合、署名検証サーバ5から得られる情報(基本4情報:住所、氏名、生年月日、性別)は、最新の情報である。すなわち、引っ越しがあった場合であっても、ユーザが地方自治体に対して引っ越しの手続(転出届、転入届等)を行うことで、引っ越しされた後の新しい住所が署名検証サーバ5に登録される。そのため、配信サーバ1は、最新の住所を得ることができる。また、ユーザの氏名に変更があった場合、ユーザが地方自治体に対して氏名に関する変更の手続きを行うことで、変更後の氏名が署名検証サーバ5に登録される。そのため、配信サーバ1は、最新の氏名を得ることができる。
配信サーバ1は、照合情報と個人情報とを照合し、確認条件を満たすか否かを判定する(ステップS1210A)。
ここで確認条件としては、例えば、照合情報に含まれる項目のうち氏名、住所、生年月日、性別等のいずれかの所定項目の内容が、個人情報に含まれる項目のうち、当該所定項目の内容と一致することであってもよい。例えば、4つの項目についてそれぞれ一致する場合であってもよいし、一部の項目が一致することであってもよい。一部の項目としては、例えば、生年月日と氏名であってもよい。住所は引っ越し等があったことにより、企業サーバ2において記憶された住所と、署名検証サーバ5において記憶された住所が一致していない状態となる場合があるからである。また、氏名については、姓名の全てを条件として用いてもよいし、姓名のうち姓が変更される場合があるため、姓名の一部(例えば名)が一致するか否かを条件として用いてもよい。
ここで確認条件としては、例えば、照合情報に含まれる項目のうち氏名、住所、生年月日、性別等のいずれかの所定項目の内容が、個人情報に含まれる項目のうち、当該所定項目の内容と一致することであってもよい。例えば、4つの項目についてそれぞれ一致する場合であってもよいし、一部の項目が一致することであってもよい。一部の項目としては、例えば、生年月日と氏名であってもよい。住所は引っ越し等があったことにより、企業サーバ2において記憶された住所と、署名検証サーバ5において記憶された住所が一致していない状態となる場合があるからである。また、氏名については、姓名の全てを条件として用いてもよいし、姓名のうち姓が変更される場合があるため、姓名の一部(例えば名)が一致するか否かを条件として用いてもよい。
配信サーバ1は、照合情報と個人情報とを照合し、確認条件を満たしていないと判定した場合には(ステップS1210A-NG)、確認条件を満たしていないことを表すメッセージを生成し(ステップS1211)、生成されたメッセージを通信端末4にRCSによって送信する(ステップS1212)。ここで生成されるメッセージは、照合情報と個人情報とが合致しないことを表す内容を含むようにしてもよし、照合情報と個人情報とが合致しないことと再度認証をしてもらうように促す内容とを含むようにしてもよい。ここで確認条件を満たしていないと判定された場合に、確認条件を満たしていないことを表すメッセージを配信サーバ1から通信端末4に送信する場合について説明するが、このメッセージを送信しなくてもよい。また、通信端末4は、確認条件を満たしていないことを表すメッセージを表示しなくてもよい。
通信端末4は、配信サーバ1からメッセージを受信すると(ステップS1409)、受信したメッセージを表示画面に表示する。例えば表示画面には、「メッセージの受け取り人と個人情報とが一致しませんでした。再度認証を行ってください」等の文字列が表示される。ここでは、ステップS1402において受信した、認証方法の選択肢が複数あり、まだ選択していない選択肢が残っている場合には、残りの選択肢を表示しつつ、選択肢を選択するように促す文字列も表示してもよい。これにより、他の認証方法によって本人確認をやり直すことも可能となる。
通信端末4は、配信サーバ1からメッセージを受信すると(ステップS1409)、受信したメッセージを表示画面に表示する。例えば表示画面には、「メッセージの受け取り人と個人情報とが一致しませんでした。再度認証を行ってください」等の文字列が表示される。ここでは、ステップS1402において受信した、認証方法の選択肢が複数あり、まだ選択していない選択肢が残っている場合には、残りの選択肢を表示しつつ、選択肢を選択するように促す文字列も表示してもよい。これにより、他の認証方法によって本人確認をやり直すことも可能となる。
また、配信サーバ1は、ステップS1209Aにおける照合をし、確認条件を満たさないと判定されたあと、他の認証方法がユーザによって選択され、その認証方法に基づく主照合を行っても、確認条件を満たさないことが所定の回数まで到達した場合には、メッセージの送信依頼元である企業サーバ2に対して、エラーとして通知するようにしてもよい。ここでいうエラーは、メッセージが未着である(企業サーバ2の企業から指定された送信先のユーザの通信端末には届かなかった)旨の内容であってもよい。
また、配信サーバ1は、ステップS1207において本人確認を要求する内容を含むメッセージを送信し、一定期間が経過したにもかかわらず、認証方法の選択入力がされない場合や、公的個人認証アプリを用いた認証を行ってもらえない場合に、エラーとして通知するようにしてもよい。ここでいうエラーは、メッセージが未着である(企業サーバ2の企業から指定された送信先のユーザの通信端末には届かなかった)旨の内容であってもよい。
また、配信サーバ1は、ステップS1207において本人確認を要求する内容を含むメッセージを送信し、一定期間が経過したにもかかわらず、認証方法の選択入力がされない場合や、公的個人認証アプリを用いた認証を行ってもらえない場合に、エラーとして通知するようにしてもよい。ここでいうエラーは、メッセージが未着である(企業サーバ2の企業から指定された送信先のユーザの通信端末には届かなかった)旨の内容であってもよい。
配信サーバ1は、照合情報と個人情報とを照合し、確認条件を満たしていると判定した場合には(ステップS1210A-OK)、送信データに含まれるメッセージ本文を生成するために必要な情報に基づくメッセージを生成し(ステップS1213)、生成されたメッセージを当該送信データに含まれる送信先の電話番号を宛先としてRCSによって送信する(ステップS1214)。ここで生成されるメッセージは、重要度が高い内容を含むものであり、本人確認が取れた場合に表示させる内容を含む。
通信端末4は、ステップS1214において配信サーバ1からメッセージが送信されると、送信されたメッセージを受信し(ステップS1410)、受信したメッセージを表示画面に表示する。例えば表示画面には、「今月の○○サービスの利用料は、○円です。」等のメッセージを表す文字列が表示される。
配信サーバ1は、通信端末4に対するメッセージの送信が完了した場合に、送信が完了したことを企業サーバ2に通知するようにしてもよい。また、配信サーバ1は、ステップS1209において、個人情報の一部を用いて確認条件を満たしていた場合、署名検証サーバ5から送信された個人情報を企業サーバ2に送信するようにしてもよい。これにより、企業サーバ2において、ユーザに関する情報を最新の情報に更新することができる。なお、個人情報を企業サーバ2に送信する場合には、個人情報を企業サーバ2に送信することについて、事前にユーザの同意を得ておくことが望ましい。
[本実施形態の効果]
本実施形態によれば、企業サーバ2に格納されたユーザに関する情報に基づく照合情報と、公的個人認証サービスによって得られた情報とを用いて照合し、確認条件を満たす場合に、送信データに基づくメッセージを送信するようにした。これにより、企業サーバ2の企業が把握しているユーザに関する情報と、通信端末4を利用しているユーザの個人情報が対応関係にある場合には、企業がメッセージの宛先として送信しようとしている電話番号の利用者が、メッセージを届けたい相手であるかの確認がとれた場合に、メッセージを送信することができる。これにより、企業サーバ2の企業から指定された送信先のユーザが通信端末4のユーザ本人ではない場合にはメッセージが送信されないようにすることができ、メッセージが別のユーザに届いてしまうことを防止することができる。
本実施形態によれば、企業サーバ2に格納されたユーザに関する情報に基づく照合情報と、公的個人認証サービスによって得られた情報とを用いて照合し、確認条件を満たす場合に、送信データに基づくメッセージを送信するようにした。これにより、企業サーバ2の企業が把握しているユーザに関する情報と、通信端末4を利用しているユーザの個人情報が対応関係にある場合には、企業がメッセージの宛先として送信しようとしている電話番号の利用者が、メッセージを届けたい相手であるかの確認がとれた場合に、メッセージを送信することができる。これにより、企業サーバ2の企業から指定された送信先のユーザが通信端末4のユーザ本人ではない場合にはメッセージが送信されないようにすることができ、メッセージが別のユーザに届いてしまうことを防止することができる。
以上説明した第2実施形態においては、署名検証サーバ5を用いる場合について説明したが、個人カードを用いない方法による本人認証を行う場合や、署名検証を行う必要がない本人認証を行う場合については、メッセージ配信システムSに署名検証サーバ5が含まれていなくてもよい。
[通信端末4がWebサーバ6にアクセスするシーケンス]
以下、Webサーバ6にアクセスするシーケンスについて説明する。以下の実施形態においては、RCSメッセージにあるURLにアクセスしてきた通信端末4が、当該RCSメッセージを受信した通信端末4であるか否かを判定する。そして、URLにアクセスしてきた通信端末4がRCSメッセージを送信した通信端末4である場合に、URLへのアクセスを許可する。これにより、RCSメッセージにあるURLが送信先のユーザとは異なる他のユーザに知られてしまい、他のユーザによって認証サイトが閲覧されてしまうことを抑制する。
以下、Webサーバ6にアクセスするシーケンスについて説明する。以下の実施形態においては、RCSメッセージにあるURLにアクセスしてきた通信端末4が、当該RCSメッセージを受信した通信端末4であるか否かを判定する。そして、URLにアクセスしてきた通信端末4がRCSメッセージを送信した通信端末4である場合に、URLへのアクセスを許可する。これにより、RCSメッセージにあるURLが送信先のユーザとは異なる他のユーザに知られてしまい、他のユーザによって認証サイトが閲覧されてしまうことを抑制する。
[第3実施形態:認証サイトへリダイレクトさせる場合]
図10~図14は、本実施形態に係るメッセージ配信システムSが実行する認証サイトにアクセスする処理の流れを示す図である。
この実施形態では、配信サーバ1によってリダイレクト処理が行われることにより、通信端末4による認証サイトへのアクセスが実行される場合について説明する。
図10~図14は、本実施形態に係るメッセージ配信システムSが実行する認証サイトにアクセスする処理の流れを示す図である。
この実施形態では、配信サーバ1によってリダイレクト処理が行われることにより、通信端末4による認証サイトへのアクセスが実行される場合について説明する。
図10に示すように、配信サーバ1は、RCSメッセージを生成する(ステップS1)。配信サーバ1は、ボタンBに、識別子が付与されたURL、及び識別子を含むポストバックデータを対応づけたRCSメッセージを生成する。配信サーバ1は、通信事業者サーバ3に対してメッセージ送信リクエストを行う(ステップS2)。具体的には、配信サーバ1は、RCSメッセージを通信事業者サーバ3に送信し、当該RCSメッセージを通信端末4に送信するように要求する。
通信事業者サーバ3は、配信サーバ1から受信した、メッセージ送信リクエストに応じて、メッセージ配信処理を行う(ステップS3)。具体的には、通信事業者サーバ3は、配信サーバ1から受信したRCSメッセージを、通信端末4に送信する。通信端末4は、通信事業者サーバ3からRCSメッセージを受信する(ステップS4)。これにより、通信端末4の表示画面にRCSメッセージが表示される。ユーザは、RCSメッセージに設けられたボタンBをタップする等して操作する(ステップS5)。これにより、通信端末4から、ボタンBが操作された旨の制御情報(Webhook情報)が通信事業者サーバ3に送信される。
通信事業者サーバ3は、ボタンBが操作された旨のWebhook情報を受信すると、受信したWebhook情報を配信サーバ1に送信する(ステップS6)。配信サーバ1は、通信事業者サーバ3からWebhook情報を受信すると、受信したWebhook情報から抽出した、電話番号、ポストバックデータ、タイムスタンプのそれぞれを応答情報121として記憶部12に記憶させる(ステップS7)。
一方、ステップS5に示す処理において、ボタンBが操作されると、ボタンBに対応づけられているURLに応じた認証サイトへのアクセスが実行される。この図の例では、認証サイトにアクセスする代わりに、配信サーバ1が有する特定のサイト(或いはリソース)に一時的に誘導する。すなわち、URLには、配信サーバ1が有するサイト(或いはリソース)が設定される。このように、ボタンBに認証サイトへのアクセスを対応づける場合において、URLの代わりに、一時的に使用するリソースのURI(Uniform Resource Identifier)が設定されてもよい。
配信サーバ1は、配信サーバ1が有する特定のサイト或いはリソース(以下、サイト等という)へのアクセスを受信すると、そのアクセス時刻を記憶部12に記憶させる(ステップS8)。配信サーバ1は、受信したアクセスに対応するURLから、当該URLに付与された識別子を抽出する(ステップS9)。配信サーバ1は、抽出した識別子に基づいて、対応する応答情報121を参照し、判定処理を実行する(ステップS10)。判定処理は、アクセスしてきた通信端末4に対し認証サイトへのリダイレクトを実行するか否かを判定する処理である。配信サーバ1は、アクセスしてきた通信装置がRCSメッセージの送信先とした通信端末4である場合、通信端末4の表示画面に認証サイトを表示させると判定する。一方、配信サーバ1は、アクセスしてきた通信装置がRCSメッセージの送信先とした通信端末4でない場合、通信端末4の表示画面に認証サイトを表示させないと判定する。認証サイト表示判定で行う処理の詳細は後で詳しく説明する。
配信サーバ1は、判定処理の判定結果が、OKであるかNGであるかを判定する(ステップS11)。ここでのOKは、通信端末4の表示画面に認証サイトを表示させることである。ここでのNGは、通信端末4の表示画面に認証サイトを表示させないことである。配信サーバ1は、判定処理の判定結果がNGである場合、通信端末4にエラー画面を表示させる(ステップS12)。エラー画面は、認証サイトにアクセスすることができない旨を表示する画面である。
配信サーバ1は、判定処理の判定結果がOKである場合、通信端末4にリダイレクトを要求する(ステップS13)。具体的には、配信サーバ1は、認証サイトのURLを通信端末4に送信して、送信したURLにアクセスするように通信端末4に要求する。通信端末4は、配信サーバ1からのリダイレクト要求を受信すると、リダイレクト処理を行う(ステップS14)。具体的には、通信端末4は、配信サーバ1から受信したリダイレクト要求に示されていたURLにアクセスする。これにより、通信端末4は、Webサーバ6における認証サイトへのアクセスを実行する。Webサーバ6は、配信サーバ1から受信したアクセスに応じた応答を行う(ステップS15)。具体的には、Webサーバ6は、認証サイトを示す画面を通信端末4の表示画面に表示させる。これにより、通信端末4に、例えば、1又は複数の認証方法を選択する選択肢が表示される(ステップS16)。
図11には、図10のステップS10に示す判定処理を実行する処理の流れが示されている。まず、配信サーバ1は、応答情報を取得する処理を実行する(ステップS100)。次に、配信サーバ1は、電話番号を照合する処理を実行する(ステップS101)。そして、配信サーバ1は、操作時刻とアクセス時刻を比較する処理を実行し(ステップS102)、処理を終了させてステップS11に進む。ここでの操作時刻は、ボタンBが操作された時刻である。アクセス時刻は、サイト等へのアクセスを配信サーバ1が受信した時刻である。
図12には、図11のステップS100に示す応答情報を取得する処理を実行する処理の流れが示されている。ここでは、ボタンBに対応づけられたサイト等へのアクセスに対応する応答情報121が取得される。
ここで、ボタンBに対する操作と、ボタンBに対応づけられたサイト等へのアクセスはほぼ同時に行われる。すなわち、配信サーバ1が、ボタンBに対する操作が行われたことに起因して通信事業者サーバ3からWebhook情報を受信するタイミングと、配信サーバ1が有する特定のサイト等へのアクセスを受信するタイミングとはほぼ同時刻となる可能性が高い。例えば、通信事業者サーバ3によるWebhook情報の生成に時間を要した、或いは、通信事業者サーバ3と配信サーバ1との間の通信回線が混雑していた等の理由により、配信サーバ1がWebhook情報を受信するタイミングが遅れる場合があり得る。この場合、配信サーバ1は、通信事業者サーバ3がWebhook情報を受信する前に、サイト等へのアクセスを受信する可能性がある。
Webhook情報を受信する前に、サイト等へのアクセスを受信した場合、アクセスに対応する応答情報121が記憶部12に記憶されていない時間が存在することになる。この場合、配信サーバ1は、Webhook情報を受信するタイミングが遅れたことに起因して対応する応答情報121が記憶部12に記憶されていないのか、或いは、ボタンBに対する操作が行われなかったことに起因して対応する応答情報121が記憶部12に記憶されていないのか区別することが困難となる。
この対策として、本実施形態では、配信サーバ1は、アクセスに対応する応答情報121が記憶されていない場合には、所定の待ち時間(例えば、1秒間)が経過した後に、再度、記憶部12を参照し、アクセスに対応する応答情報121が記憶されているか否かを確認するリトライを実行する。リトライを実行した結果、記憶部12に対応する応答情報121が記憶されていた場合には、配信サーバ1は、その対応する応答情報121を取得する。これにより、Webhook情報を受信する前にアクセスが実行された場合であっても、アクセスに対応する応答情報121を取得することができる。
リトライの回数があらかじめ定めた閾値(例えば、3回)以上となっても、記憶部12に対応する応答情報121が記憶されていない場合、配信サーバ1は、ボタンBに対する操作が行われず、対応する応答情報121が記憶部12に記憶されていないと判定する。これにより、他のユーザの通信装置によりURLがアクセスされた可能性が高い場合、不正なアクセスとみなしてこれを抑制することができる。
この対策として、本実施形態では、配信サーバ1は、アクセスに対応する応答情報121が記憶されていない場合には、所定の待ち時間(例えば、1秒間)が経過した後に、再度、記憶部12を参照し、アクセスに対応する応答情報121が記憶されているか否かを確認するリトライを実行する。リトライを実行した結果、記憶部12に対応する応答情報121が記憶されていた場合には、配信サーバ1は、その対応する応答情報121を取得する。これにより、Webhook情報を受信する前にアクセスが実行された場合であっても、アクセスに対応する応答情報121を取得することができる。
リトライの回数があらかじめ定めた閾値(例えば、3回)以上となっても、記憶部12に対応する応答情報121が記憶されていない場合、配信サーバ1は、ボタンBに対する操作が行われず、対応する応答情報121が記憶部12に記憶されていないと判定する。これにより、他のユーザの通信装置によりURLがアクセスされた可能性が高い場合、不正なアクセスとみなしてこれを抑制することができる。
図12に示すように、まず、配信サーバ1は、変数としてのリトライ回数を0(ゼロ)として初期化する(ステップS1001)。次に、配信サーバ1は、URLから抽出した識別子に基づいて記憶部12を参照し、対応する応答情報121が記憶されているか否かを判定する(ステップS1002)。対応する応答情報121が記憶されている場合、配信サーバ1は処理を終了させ、ステップS101に進む。対応する応答情報121が記憶されていない場合、配信サーバ1は、リトライ回数をインクリメントする(S1003)。配信サーバ1は、リトライ回数が閾値未満であるか否かを判定する(ステップS1004)。配信サーバ1は、リトライ回数が閾値未満である場合、待ち時間が経過したか否かを判定する(ステップS1005)。待ち時間が経過した場合、配信サーバ1は、ステップS1002に戻る。一方、ステップS1004において、リトライ回数が閾値以上である場合、配信サーバ1は、判定結果をNGとし(ステップS1006)、処理を終了させ、ステップS11に進む。
図13には、図11のステップS101に示す電話番号を照合する処理を実行する処理の流れが示されている。ここでは、Webhook情報に含まれる電話番号と、URLに付与された識別子に含まれる電話番号(個人特定識別子)とを突合させることにより照合が行われる。なお、ここでの電話番号又は個人特定識別子は、少なくともユーザが特定可能な情報であればよく、電話番号に限定されることはない。例えば、電話番号に紐づけられたキー情報、或いは、ユーザを特定できる情報を、個人特定識別子として用いることができる。
まず、配信サーバ1は、URLに付与された識別子に対応する応答情報121を抽出する(ステップS1011)。具体的には、配信サーバ1は、記憶部12を参照し、応答情報121として記憶された情報のうち、URLに付与された識別子に対応する識別子を有するポストバックデータを含む応答情報121を抽出する。配信サーバ1は、電話番号が一致するか否かを判定する(ステップS1012)。配信サーバ1は、抽出した応答情報121における電話番号と、URLに付与された識別子に含まれる電話番号(生産管理番号)とを突合させる。例えば、配信サーバ1は、二つの電話番号が一致するか否かを判定する。電話番号が一致した場合、配信サーバ1は処理を終了させ、ステップS102に進む。電話番号が一致しない場合、配信サーバ1は判定結果をNGとし(ステップS1013)、処理を終了させ、ステップS11に進む。
或いは、ステップS1012において、配信サーバ10は、又は個人特定識別子Webhook情報に含まれる個人特定識別子(第1情報という)と、URIに付与された識別子に含まれる電話番号に対応する情報(第2情報という)とが同じユーザに紐づく情報であることを示しているか否かを判定するようにしてもよい。第1情報と第2情報とが整合し、同じユーザに紐づく情報であることが示されている場合、配信サーバ10は処理を終了させ、ステップS102に進む。電話番号が一致しない場合、配信サーバ10は判定結果をNGとし(ステップS1013)、処理を終了させ、ステップS11に進む。
或いは、ステップS1012において、配信サーバ10は、又は個人特定識別子Webhook情報に含まれる個人特定識別子(第1情報という)と、URIに付与された識別子に含まれる電話番号に対応する情報(第2情報という)とが同じユーザに紐づく情報であることを示しているか否かを判定するようにしてもよい。第1情報と第2情報とが整合し、同じユーザに紐づく情報であることが示されている場合、配信サーバ10は処理を終了させ、ステップS102に進む。電話番号が一致しない場合、配信サーバ10は判定結果をNGとし(ステップS1013)、処理を終了させ、ステップS11に進む。
図14には、図11のステップS102に示す操作時刻とアクセス時刻を比較する処理を実行する処理の流れが示されている。ここでは、ボタンBが操作された操作時刻と、サイト等がアクセスされたアクセス時刻とが比較される。
まず、配信サーバ1は、アクセス時刻を取得する(ステップS1021)。配信サーバ1は、記憶部12を参照し、ステップS8で記憶させたアクセス時刻を取得する。配信サーバ1は、ステップS1011で取得した応答情報121におけるタイムスタンプに示された操作時刻を取得する(ステップS1022)。配信サーバ1は、アクセス時刻が操作時刻より後の時刻であるか否かを判定する(ステップS1023)。アクセス時刻が操作時刻より後の時刻である場合、配信サーバ1は、アクセス時刻が(操作時刻+許容時間)より前の時刻であるか否かを判定する(ステップS1024)。アクセス時刻が(操作時刻+許容時間)より前の時刻である場合、配信サーバ1は、判定結果をOKとし(ステップS1025)、処理を終了させ、ステップS11に進む。一方、配信サーバ1は、ステップS1023においてアクセス時刻が操作時刻より前の時刻であると判定した場合、及びステップS1024においてアクセス時刻が(操作時刻+許容時間)より後の時刻であると判定した場合、判定結果をNGとし(ステップS1026)、処理を終了させ、ステップS11に進む。
[本実施形態の効果]
本実施形態によれば、配信サーバ1が、アクセスに用いられたURLと、ボタンBに対する操作に対応するWebhook情報とを用いてRCSメッセージに含まれるURLへのアクセスを実行した通信端末が、RCSメッセージの送信先とした通信端末4であるか否かを判定するようにした。これにより、配信サーバ1は、RCSメッセージに含まれるURLへのアクセスを実行した通信端末が、RCSメッセージの送信先とした通信端末4であるか否かを判定することができる。したがって、認証サイトへのリンクを含むRCSメッセージを通信端末4に通知した場合において、そのリンクにあるURLが他のユーザに知られてしまう等して他のユーザによって認証サイトへのアクセスが実行された場合であっても認証サイトへのリダイレクトさせないようにすることができ、他のユーザに認証サイトが閲覧されてしまうことを抑制することができる。
本実施形態によれば、配信サーバ1が、アクセスに用いられたURLと、ボタンBに対する操作に対応するWebhook情報とを用いてRCSメッセージに含まれるURLへのアクセスを実行した通信端末が、RCSメッセージの送信先とした通信端末4であるか否かを判定するようにした。これにより、配信サーバ1は、RCSメッセージに含まれるURLへのアクセスを実行した通信端末が、RCSメッセージの送信先とした通信端末4であるか否かを判定することができる。したがって、認証サイトへのリンクを含むRCSメッセージを通信端末4に通知した場合において、そのリンクにあるURLが他のユーザに知られてしまう等して他のユーザによって認証サイトへのアクセスが実行された場合であっても認証サイトへのリダイレクトさせないようにすることができ、他のユーザに認証サイトが閲覧されてしまうことを抑制することができる。
[第4実施形態:Webサーバ6が認証サイトへアクセスを許可する場合]
図15は、本実施形態に係るメッセージ配信システムSが実行する認証サイトにアクセスする処理の流れを示す図である。
この実施形態では、Webサーバ6によって認証サイトへのアクセスを許可するか否かが判定される場合について説明する。
図15は、本実施形態に係るメッセージ配信システムSが実行する認証サイトにアクセスする処理の流れを示す図である。
この実施形態では、Webサーバ6によって認証サイトへのアクセスを許可するか否かが判定される場合について説明する。
図15のステップS21~S27に示す処理は、図10のステップS1~S7に示す処理と同等であるためその説明を省略する。
図15に示すように、Webサーバ6は、通信端末4によるURLへのアクセスが実行された場合、アクセス時刻を、Webサーバ6の記憶部に記憶させる(ステップS28)。Webサーバ6は、受信したURLに付与された識別子を抽出し、抽出した識別子を、配信サーバ1に送信する(ステップS29)。
配信サーバ1は、Webサーバ6から受信した識別子に基づいて記憶部12を参照し、当該識別子に対応する応答情報121を取得する。配信サーバ1は、取得した応答情報121の全部または一部を、Webサーバ6に送信する(ステップS30)。
Webサーバ6は、通信端末4から受信した応答情報121に基づいて、判定処理を実行する(ステップS31)。判定処理は、アクセスしてきた通信端末4に対し認証サイトの情報を通信端末4の表示画面に表示させるか否かを判定する処理である。Webサーバ6は、アクセスしてきた通信装置が、RCSメッセージを送信した送信先の通信端末4である場合、通信端末4の表示画面に認証サイトを表示させると判定する。一方、配信サーバ1は、アクセスしてきた通信装置が、RCSメッセージを送信した送信先の通信端末4でない場合、通信端末4の表示画面に認証サイトを表示させないと判定する。表示判定処理で行う処理は、ステップS11に示す判定処理と同等であるためその説明を省略する。
Webサーバ6は、判定処理の判定結果がNGである場合、通信端末4に、エラー画面を表示させる(ステップS33)。一方、表示制御部432は、判定処理の判定結果がOKである場合、通信端末4に、Webサーバ6における認証サイトの画面を表示させる(ステップS34)。
図15に示すように、Webサーバ6は、通信端末4によるURLへのアクセスが実行された場合、アクセス時刻を、Webサーバ6の記憶部に記憶させる(ステップS28)。Webサーバ6は、受信したURLに付与された識別子を抽出し、抽出した識別子を、配信サーバ1に送信する(ステップS29)。
配信サーバ1は、Webサーバ6から受信した識別子に基づいて記憶部12を参照し、当該識別子に対応する応答情報121を取得する。配信サーバ1は、取得した応答情報121の全部または一部を、Webサーバ6に送信する(ステップS30)。
Webサーバ6は、通信端末4から受信した応答情報121に基づいて、判定処理を実行する(ステップS31)。判定処理は、アクセスしてきた通信端末4に対し認証サイトの情報を通信端末4の表示画面に表示させるか否かを判定する処理である。Webサーバ6は、アクセスしてきた通信装置が、RCSメッセージを送信した送信先の通信端末4である場合、通信端末4の表示画面に認証サイトを表示させると判定する。一方、配信サーバ1は、アクセスしてきた通信装置が、RCSメッセージを送信した送信先の通信端末4でない場合、通信端末4の表示画面に認証サイトを表示させないと判定する。表示判定処理で行う処理は、ステップS11に示す判定処理と同等であるためその説明を省略する。
Webサーバ6は、判定処理の判定結果がNGである場合、通信端末4に、エラー画面を表示させる(ステップS33)。一方、表示制御部432は、判定処理の判定結果がOKである場合、通信端末4に、Webサーバ6における認証サイトの画面を表示させる(ステップS34)。
[本実施形態の効果]
本実施形態によれば、Webサーバ6が、アクセスに用いられたURLに基づいてボタンBに対する操作に対応するWebhook情報を取得するようにした。これにより、Webサーバ6は、RCSメッセージに含まれるURLへのアクセスを実行した通信端末が、RCSメッセージの送信先とした通信端末4であるか否かを判定することができる。したがって、他のユーザによって認証サイトへのアクセスが実行された場合には認証サイトへのアクセスを許可しないようにすることができ、他のユーザに認証サイトが閲覧されてしまうことを抑制することができる。
本実施形態によれば、Webサーバ6が、アクセスに用いられたURLに基づいてボタンBに対する操作に対応するWebhook情報を取得するようにした。これにより、Webサーバ6は、RCSメッセージに含まれるURLへのアクセスを実行した通信端末が、RCSメッセージの送信先とした通信端末4であるか否かを判定することができる。したがって、他のユーザによって認証サイトへのアクセスが実行された場合には認証サイトへのアクセスを許可しないようにすることができ、他のユーザに認証サイトが閲覧されてしまうことを抑制することができる。
[第5実施形態:RCSメッセージ以外の通知手段を含む場合]
図16、図17、図18(図18A、図18B)、及び図19は、本実施形態に係るメッセージ配信システムSが実行する認証サイトにアクセスする処理の流れを示す図である。
この実施形態では、配信サーバ1によってRCSメッセージ以外の通知が実行される場合について説明する。RCSメッセージ以外の通知とは、例えば、SMS(Short Message Service)を用いたSMSメッセージによる通知である。
図16、図17、図18(図18A、図18B)、及び図19は、本実施形態に係るメッセージ配信システムSが実行する認証サイトにアクセスする処理の流れを示す図である。
この実施形態では、配信サーバ1によってRCSメッセージ以外の通知が実行される場合について説明する。RCSメッセージ以外の通知とは、例えば、SMS(Short Message Service)を用いたSMSメッセージによる通知である。
通信端末4はSMSに対応しているが、RCSについては対応しているものと対応していないものがある。例えば、RCSのアプリケーションがインストールされ、且つRCSを用いた通信に関する利用規約の同意などを含むアクティベーションが行われた場合、通信端末4はRCSに対応している端末である。一方、RCSのアプリケーションがインストールされていない、又は、RCSのアプリケーションがインストールされているがアクティベーションが行われていない場合、通信端末4はRCSに対応していない端末である。
このような観点から、本実施形態のメッセージ配信システムSは、RCSに対応している通信端末4にRCSメッセージを送信し、RCSに対応していない通信端末4にSMSメッセージを送信するようにした。これにより、RCSに対応していない利用者端末30にもメッセージを送信することが可能となる。
このような観点から、本実施形態のメッセージ配信システムSは、RCSに対応している通信端末4にRCSメッセージを送信し、RCSに対応していない通信端末4にSMSメッセージを送信するようにした。これにより、RCSに対応していない利用者端末30にもメッセージを送信することが可能となる。
具体的には、配信サーバ1は、通信端末4を送信先とするメッセージについて、RCSメッセージ及びSMSメッセージの2つのメッセージを生成する。配信サーバ1は、RCSメッセージとして、例えば、上述した実施形態と同様に、リッチカード或いはチップリストなどにボタンBなどのコンテンツを設け、ボタンBに認証サイトのURLを対応づけたメッセージを生成する。配信サーバ1は、SMSメッセージとして、例えば認証サイトのURLを含むテキストからなるメッセージを生成する。
配信サーバ1は、作成した2つのメッセージを用いて通信事業者サーバ3に送信リクエストを行う。通信事業者サーバ3は、RCSに対応している通信端末4にRCSメッセージを送信し、RCSに対応していない通信端末4にSMSメッセージを送信する。
配信サーバ1は、作成した2つのメッセージを用いて通信事業者サーバ3に送信リクエストを行う。通信事業者サーバ3は、RCSに対応している通信端末4にRCSメッセージを送信し、RCSに対応していない通信端末4にSMSメッセージを送信する。
配信サーバ1が2つのメッセージを生成する方法について、図16を用いて説明する。
図16は、第5の実施形態に係る配信情報120Aの例を示す図である。配信情報120Aは、メッセージごとに生成される。配信情報120Aは、例えば、案件特定識別子、配信単位特定識別子、個人特定識別子、及びRCSとSMSのそれぞれの項目に対応する情報を含む。案件特定識別子は、送信するメッセージのカテゴリを特定するID(Identification)である。
配信単位特定識別子は、送信するメッセージを特定するIDである。個人特定識別子は、ユーザが特定可能な情報であり、例えば、メッセージの送信先である電話番号である。
個人特定識別子は、少なくともユーザが特定可能な情報であればよく、電話番号に限定されることはない。例えば、電話番号に紐づけられたキー情報、或いは、ユーザを特定できる情報を、個人特定識別子として用いることができる。
RCSの項目には、通信端末4にRCSメッセージを送信する場合におけるメッセージの内容を示す情報が記憶される。SMSの項目には、通信端末4にSMSメッセージを送信する場合におけるメッセージの内容を示す情報が記憶される。
図16は、第5の実施形態に係る配信情報120Aの例を示す図である。配信情報120Aは、メッセージごとに生成される。配信情報120Aは、例えば、案件特定識別子、配信単位特定識別子、個人特定識別子、及びRCSとSMSのそれぞれの項目に対応する情報を含む。案件特定識別子は、送信するメッセージのカテゴリを特定するID(Identification)である。
配信単位特定識別子は、送信するメッセージを特定するIDである。個人特定識別子は、ユーザが特定可能な情報であり、例えば、メッセージの送信先である電話番号である。
個人特定識別子は、少なくともユーザが特定可能な情報であればよく、電話番号に限定されることはない。例えば、電話番号に紐づけられたキー情報、或いは、ユーザを特定できる情報を、個人特定識別子として用いることができる。
RCSの項目には、通信端末4にRCSメッセージを送信する場合におけるメッセージの内容を示す情報が記憶される。SMSの項目には、通信端末4にSMSメッセージを送信する場合におけるメッセージの内容を示す情報が記憶される。
RCSに記憶される情報には、例えば、ボタン(ボタン1、ボタン2、…)の項目に対応する情報が含まれる。 ボタンは、メッセージに含めることができるコンテンツであり、ユーザが操作できるコンテンツである。ボタンには、例えば、ボタンID、URL、及びポストバックデータのそれぞれに対応する情報が含まれる。ボタンIDは、メッセージに設定されたボタンを特定するIDである。URLは、ボタンが操作されることによりアクセスされるURLである。ポストバックデータはWebhook情報に含まれる情報である。つまり、ボタンが操作されることにより、通信事業者サーバ3から配信サーバ1にWebhook情報が送信され、そのWebhook情報には、ここで設定したポストバックデータが含まれる。
本実施形態では、ボタンに対応づけられたポストバックデータに第1識別子を設定する。第1識別子は、(案件特定識別子、配信単位特定識別子、ボタンID、個人特定識別子)の組合せを特定する情報である。これにより、ボタンが操作された場合に、第1識別子を含むWebhook情報が通信事業者サーバ3から配信サーバ1に送信される。配信サーバ1は、第1識別子を含むWebhook情報を受信することにより、通信端末4に送信した何れメッセージにおける、何れのボタンが操作されたのかを把握することができる。
また、本実施形態では、ボタンに対応づけられたURLに、第1識別子を付与する。第1識別子は、ポストバックデータに設定される第1識別子と同等な情報であって、(案件特定識別子、配信単位特定識別子、ボタンID、個人特定識別子)の組合せを特定する情報である。RCS識別子は、RCSを用いて送信されたメッセージであることを特定する情報である。
なお、ポストバックデータにおける第1識別子と、URLに付与される第1識別子は、少なくとも(案件特定識別子、配信単位特定識別子、ボタンID、個人特定識別子)の組合せを特定できる情報であればよい。ポストバックデータにおける第1識別子と、URLに付与される第1識別子は、同一の情報であってもよいし、異なる情報であってもよい。
URLに、ポストバックデータと同等な情報(第1識別子)が付与されることにより、第1識別子を手掛かりとして、URLにアクセスしてきた通信端末がRCSメッセージのボタンを操作することによりアクセスしてきた端末であるか否かを、Webhook情報を用いて把握することができる。
なお、ポストバックデータにおける第1識別子と、URLに付与される第1識別子は、少なくとも(案件特定識別子、配信単位特定識別子、ボタンID、個人特定識別子)の組合せを特定できる情報であればよい。ポストバックデータにおける第1識別子と、URLに付与される第1識別子は、同一の情報であってもよいし、異なる情報であってもよい。
URLに、ポストバックデータと同等な情報(第1識別子)が付与されることにより、第1識別子を手掛かりとして、URLにアクセスしてきた通信端末がRCSメッセージのボタンを操作することによりアクセスしてきた端末であるか否かを、Webhook情報を用いて把握することができる。
さらに、本実施形態では、ボタンに対応づけられたURLに、RCS識別子を付与する。URLに、RCS識別子が付与されることにより、Webhook情報を用いなくとも、URLを指定してアクセスしてきた通信端末が、RCSメッセージに設定されたURLを用いてアクセスしてきたか否かを把握することができる。
SMSに記憶される情報には、例えば、テキスト、及びURLのそれぞれの項目に対応する情報が含まれる。テキストは、送信するメッセージの内容を示すテキスト情報である。URLは、メッセージの中で示されるURLであって、そのURLが操作されることによりアクセスされるURLである。
本実施形態では、SMSメッセージの中で示されるURLに、第2識別子が付与される。第2識別子は、URLが改ざんされていないことを判定可能な情報であって、例えば、URLのチェックデジットである。チェックデジットは、URLの誤りを検知するために付加される検査用のコードであり、URLを用いて特定の演算を行うことにより算出されるコードである。
URLに第2識別子が付与されることにより、SMSメッセージを介してURLにアクセスしてきた通信端末が、改ざんされたURLを用いてアクセスしてきた不正な端末でないか判定することができる。
本実施形態では、SMSメッセージの中で示されるURLに、第2識別子が付与される。第2識別子は、URLが改ざんされていないことを判定可能な情報であって、例えば、URLのチェックデジットである。チェックデジットは、URLの誤りを検知するために付加される検査用のコードであり、URLを用いて特定の演算を行うことにより算出されるコードである。
URLに第2識別子が付与されることにより、SMSメッセージを介してURLにアクセスしてきた通信端末が、改ざんされたURLを用いてアクセスしてきた不正な端末でないか判定することができる。
本実施形態では、RCSメッセージにて通知するURLにRCS識別子を付与し、SMSメッセージにて通知するURLに、SMSメッセージであることを特定する識別子(SMS識別子)を付与しない。これは、SMSメッセージにて通知可能な文字数が制限される場合があるためである。例えば、一部の古い機種では、SMSメッセージが、所定の文字数(例えば、70文字)ごとに分割されて通知される。このため、SMSメッセージで比較的長い文字数を有するURLを通知した場合、その通知するURLを示す文字列が複数の文字列に分割されて通知される可能性がある。このように文字数に制限があったり、分割されたりする可能性があるSMSメッセージにおいては、なるべく文字数が少ないメッセージを通知するほうがよい。このため、本実施形態では、SMSメッセージにて通知するURLにSMS識別子を付与しないようにした。
なお、上述した実施形態ではSMSメッセージにSMS識別子を付与しない場合を例示して説明したがこれに限定されない。サービスの運用形態に応じて、SMSメッセージにSMS識別子を付与するように構成されてもよい。
なお、上述した実施形態ではSMSメッセージにSMS識別子を付与しない場合を例示して説明したがこれに限定されない。サービスの運用形態に応じて、SMSメッセージにSMS識別子を付与するように構成されてもよい。
本実施形態で送信されるSMSメッセージについて、図17を用いて説明する。図17は、実施形態に係る利用者端末30に表示されるSMSメッセージの例を示す図である。図17に示すように、SMSメッセージでは、テキストにてメッセージが示される。この図では、「IR情報が開示されました。」などの文言とともに、末尾にURLが示されている。また、図17に示すように、本実施形態におけるSMSメッセージに示されるURLには第2識別子が付与されている(符号T)。
図18(図18A、図18B)には、本実施形態に係るメッセージ配信システムSが実行する認証サイトにアクセスする処理の流れが示されている。
配信サーバ1は、メッセージ(RCSメッセージ及びSMSメッセージ)を生成する(ステップS31)。配信サーバ1は、ボタンBに、第1識別子及びRCS識別子が付与されたURL、及び第1識別子を含むポストバックデータを対応づけたRCSメッセージを生成する。また、配信サーバ1は、第2識別子が付与されたURLを含むSMSメッセージを生成する。配信サーバ1は生成したRCSメッセージ及びSMSメッセージを配信情報120として記憶部12に記憶させる。
配信サーバ1は、通信事業者サーバ3に対してメッセージ送信リクエストを行う(ステップS32)。具体的には、配信サーバ1は、配信情報120を通信事業者サーバ3に送信し、通信端末4にメッセージを送信するように要求する。
配信サーバ1は、通信事業者サーバ3に対してメッセージ送信リクエストを行う(ステップS32)。具体的には、配信サーバ1は、配信情報120を通信事業者サーバ3に送信し、通信端末4にメッセージを送信するように要求する。
通信事業者サーバ3は、配信サーバ1から受信した、メッセージ送信リクエストに応じて、メッセージ配信処理を行う(ステップS33)。具体的には、通信事業者サーバ3は、通信端末4がRCSに対応しているか否かを判定し、RCSに対応している通信端末4にはRCSメッセージを送信する。RCSに対応していない通信端末4にはSMSメッセージを送信する。
RCSに対応している通信端末4は、通信事業者サーバ3からRCSメッセージを受信する(ステップS34)。これにより、通信端末4の表示画面にRCSメッセージが表示される。ステップS35~S44に示す処理は、第3の実施形態におけるステップS5~S14に示す処理と同様であるため、その説明を省略する。ステップS44以降の処理(符号Y)の流れについては図18Bで説明する。
RCSに対応している通信端末4は、通信事業者サーバ3からRCSメッセージを受信する(ステップS34)。これにより、通信端末4の表示画面にRCSメッセージが表示される。ステップS35~S44に示す処理は、第3の実施形態におけるステップS5~S14に示す処理と同様であるため、その説明を省略する。ステップS44以降の処理(符号Y)の流れについては図18Bで説明する。
ステップS33において、RCSに対応していないと判定された通信端末4は、通信事業者サーバ3からSMSメッセージを受信する(ステップS45)。これにより、通信端末4の表示画面にSMSメッセージが表示される。ユーザは、SMSメッセージに示されたURLをタップする等して操作する(ステップS46)。これにより、通信端末4は、URLに示されたサイト等へのアクセスを実行する。ステップS46以降の処理(符号X)の流れについては図18Bで説明する。
図18Bに示すように、ステップS44又はステップS46が実行されることにより(符号X、Y)、Webサーバ6は、通信端末4によるURLへのアクセスを受信すると、URL改ざん判定処理を行う(ステップS47)。URL改ざん判定処理は、アクセスしてきた端末から通知されたURLが改ざんされていないか判定する処理である。URL改ざん判定処理の詳細は後で詳しく説明する。Webサーバ6は、URL改ざん判定処理の判定結果がOKであるか否かを判定する(ステップS48)。Webサーバ6は、URLが改ざんされていない場合、URL改ざん判定処理の判定結果がOKであると判定する。Webサーバ6は、URLが改ざんされている場合、URL改ざん判定処理の判定結果がNGであると判定する。URL改ざん判定処理の判定結果がOKである場合、Webサーバ6は、認証サイトを示す画面を通信端末4の表示画面に表示させる。これにより、通信端末4に、認証サイトが表示される(ステップS49)。一方、URL改ざん判定処理の判定結果がNGである場合、Webサーバ6は、エラー画面を通信端末4の表示画面に表示させる(ステップS50)。これにより、1又は複数の認証方法を選択する選択肢が表示される。
図19には、図18BのステップS47に示すURL改ざん判定処理の流れが示されている。ここでは、SMSメッセージを介してURLへのアクセスが実行された場合、そのURLが改ざんされていないか判定する。一方、RCSメッセージを介してURLへのアクセスが実行された場合、そのURLが改ざんされていないか判定しない。もしくは、簡易的な確認として、SMSメッセージに対して実施する判定処理とは異なる判定処理を実施するようにしてもよい。RCSメッセージを介してURLへのアクセスが実行された場合、上述したステップS10に示す判定処理が実行され、RCSメッセージに設けられたボタンが操作されることによってURLへのアクセスが実行されたことが検証済みであり、URL改ざん判定処理は不要であると考えられるためである。
なお、RCSメッセージを介してURLへのアクセスが実行された場合、SMSメッセージの場合と同様に、そのURLが改ざんされていないか判定するようにしてもよい。この場合、例えば、RCSメッセージに示されるURLに、URLのチェックデジットが付与される。
なお、RCSメッセージを介してURLへのアクセスが実行された場合、SMSメッセージの場合と同様に、そのURLが改ざんされていないか判定するようにしてもよい。この場合、例えば、RCSメッセージに示されるURLに、URLのチェックデジットが付与される。
まず、Webサーバ6は、アクセスしてきた通信端末が通知したURLを取得する(ステップS470)。Webサーバ6は、取得したURLにRCS識別子が付与されているか否かを判定する(ステップS471)。URLにRCS識別子が付与されていない場合、Webサーバ6は、URLが改ざんされているか判定する(ステップS472)。Webサーバ6は、URLに付与された第2識別子を用いて、URLが改ざんされているか判定する。具体的には、Webサーバ6は、URLのチェックデジットを算出し、算出したチェックデジットと第2識別子とを比較する。チェックデジットと第2識別子が一致した場合、Webサーバ6は、URLが改ざんされていないと判定する。一方、チェックデジットと第2識別子が一致しない場合、Webサーバ6は、URLが改ざんされていると判定する。URLが改ざんされている場合、Webサーバ6は、URL改ざん判定処理判定結果をNGとし(ステップS473)、処理を終了させ、ステップS48に進む。
一方、ステップS471においてURLにRCS識別子が付与されている場合、又は、ステップS472においてURLが改ざんされていないと判定された場合、Webサーバ6は、URL改ざん判定処理判定結果をOKとし(ステップS474)、処理を終了させ、ステップS48に進む。
一方、ステップS471においてURLにRCS識別子が付与されている場合、又は、ステップS472においてURLが改ざんされていないと判定された場合、Webサーバ6は、URL改ざん判定処理判定結果をOKとし(ステップS474)、処理を終了させ、ステップS48に進む。
[本実施形態の効果]
本実施形態によれば、RCSメッセージを通知した場合にはRCSメッセージに含まれるURLへのアクセスを実行した通信端末が、RCSメッセージの送信先とした通信端末4であるか否かを判定するようにした。SMSメッセージを通知した場合にはSMSメッセージに含まれるURLへのアクセスが実行されたURLが改ざんされていないか判定するようにした。これにより、RCSメッセージ及びSMSメッセージのいずれかを通信端末4に通知するような混在環境においても、他のユーザに認証サイトが閲覧されてしまうことを抑制することができる。
本実施形態によれば、RCSメッセージを通知した場合にはRCSメッセージに含まれるURLへのアクセスを実行した通信端末が、RCSメッセージの送信先とした通信端末4であるか否かを判定するようにした。SMSメッセージを通知した場合にはSMSメッセージに含まれるURLへのアクセスが実行されたURLが改ざんされていないか判定するようにした。これにより、RCSメッセージ及びSMSメッセージのいずれかを通信端末4に通知するような混在環境においても、他のユーザに認証サイトが閲覧されてしまうことを抑制することができる。
なお、上述した各実施形態において、本人確認が行われ本人であることが確認できた後については、通信端末4に記憶されている生体情報を用いて本人確認を行うようにしてもよい。
また、メッセージの通知内容の重要度に応じて、認証方法を設定してもよい。例えば、メッセージの通知内容の重要度が所定の高さである場合に公的個人認証を行えるように予め定めておいてもよい。
また、本人確認を過去に行ったことがあるユーザについては、前回行った認証方法とは別の認証方法を設定するようにしてもよい。例えば、本人確認を一度もしたことがないユーザについては、公的個人認証またはキャリア認証のどちらかをユーザに選択してもらい、その後、同じユーザに対して2回目以降の本人確認を行う場合には、いずれかの認証方法の選択肢から選択してもらうようにしてもよい。すなわち、重要度や、過去に本人確認が取れたことがあったか否かに応じて、選択肢が決められていてもよい。
また、メッセージの通知内容の重要度に応じて、認証方法を設定してもよい。例えば、メッセージの通知内容の重要度が所定の高さである場合に公的個人認証を行えるように予め定めておいてもよい。
また、本人確認を過去に行ったことがあるユーザについては、前回行った認証方法とは別の認証方法を設定するようにしてもよい。例えば、本人確認を一度もしたことがないユーザについては、公的個人認証またはキャリア認証のどちらかをユーザに選択してもらい、その後、同じユーザに対して2回目以降の本人確認を行う場合には、いずれかの認証方法の選択肢から選択してもらうようにしてもよい。すなわち、重要度や、過去に本人確認が取れたことがあったか否かに応じて、選択肢が決められていてもよい。
なお、上述した各実施形態において、企業サーバ2からメッセージを送信する場合について説明したが、企業サーバ2は、銀行や保険会社のような企業であってもよいし、電子私書箱を運営する企業であってもよい。電子私書箱を運営する企業は、その他の種々の企業からメッセージを受け付け、宛先であるユーザに対して閲覧可能となるように送信してもよい。例えば、電子私書箱を運営する企業が、異なる複数の企業からそれぞれメッセージの送信依頼を受信し、そのメッセージを配信サーバ1に対して送信依頼をするようにしてもよい。その際、上述したように、メッセージの重要性に応じて、認証方法を選択する選択肢を通信端末4に表示し、認証方法をユーザに選択してもらうようにしてもよい。
また、上述した実施形態における本人確認が取れた場合に、メッセージを電子的に送信する場合について説明したが、メッセージを電子的に送信するのではなく、紙等の印刷媒体をユーザに送付するようにしてもよい。例えば、本人確認や契約継続の意思確認を上述した実施形態により電子的に実施し、本人確認が取れたという結果をもって、契約締結完了書類や最新のクレジットカードなどを送付(郵送、宅配等)するようにしてもよい。
また、上述した実施形態では、認証サイトにて認証を行う場合を例示したが、認証サイトに代えて任意のWebサイトが適用されてよい。例えば、メッセージに含まれるリンク先のURLが認証を行わないサイトのURLであってもよい。
上述した実施形態におけるメッセージ配信システムS、配信サーバ1の全部又は一部をコンピュータで実現するようにしてもよい。その場合、この機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、OSや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD-ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよく、FPGA(Field Programmable Gate Array)等のプログラマブルロジックデバイスを用いて実現されるものであってもよい。
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
S…メッセージ配信システム、1…配信サーバ、2…企業サーバ、3…通信事業者サーバ、4…通信端末、5…署名検証サーバ、6…Webサーバ、11…通信部、12…記憶部、120…配信情報、121…応答情報(Webhook情報)、122…照合情報、13…制御部、130…取得部、131…生成部、132…判定部、133…表示制御部、134…照合部
Claims (4)
- メッセージを送信する送信先の電話番号に対応する通信端末にインストールされたメッセージアプリを用いて、前記電話番号の契約者が前記メッセージを送信する宛先のユーザであるかを認証する認証方法を指定してもらうための候補が示されたURI(Uniform Resource Identifier)へのリンクを送信する送信部と、
前記候補から指定された認証方法に基づくユーザ認証が行われた結果に応じて、前記メッセージを送信可否の判定を行うための制御をする制御部
を有する情報処理装置。 - 前記メッセージアプリは、通信事業者を介してRCS(Rich Communication Services)を用いたメッセージを送受信するアプリケーションプログラムであり、
前記送信部は、前記電話番号に対応づけられたキー情報を付与した前記リンクを送信し、
前記メッセージアプリを用いて送信したメッセージにあるコンテンツが操作された場合に前記通信事業者から通知されるWebhook情報であって、前記コンテンツが操作された操作時刻を示すタイムスタンプ、及び前記コンテンツが操作された通信端末の電話番号を含むWebhook情報を取得する取得部と、
前記リンクへのアクセスが実行された場合、前記リンクへのアクセスが実行されたアクセス時刻、前記アクセスされたリンクに付与されている前記キー情報、及び前記Webhook情報に基づいて、前記アクセスを実行した通信端末が、前記メッセージを受信した通信端末であるか否かを判定する判定部を更に備える、
請求項1に記載の情報処理装置。 - コンピュータが行う情報処理方法であって、
送信部が、メッセージを送信する送信先の電話番号に対応する通信端末にインストールされたメッセージアプリを用いて、前記電話番号の契約者が前記メッセージを送信する宛先のユーザであるかを認証する認証方法を指定してもらうための候補が示されたURI(Uniform Resource Identifier)へのリンクを送信し、
制御部が、前記候補から指定された認証方法に基づくユーザ認証が行われた結果に応じて、前記メッセージを送信可否の判定を行うための制御をする
情報処理方法。 - コンピュータを、請求項1又は請求項2に記載の情報処理装置として動作させるためのプログラムであって、前記コンピュータを前記情報処理装置が備える各部として機能させるためのプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2022022958A JP2023119857A (ja) | 2022-02-17 | 2022-02-17 | 情報処理装置、情報処理方法、及びプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2022022958A JP2023119857A (ja) | 2022-02-17 | 2022-02-17 | 情報処理装置、情報処理方法、及びプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2023119857A true JP2023119857A (ja) | 2023-08-29 |
Family
ID=87778209
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2022022958A Pending JP2023119857A (ja) | 2022-02-17 | 2022-02-17 | 情報処理装置、情報処理方法、及びプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2023119857A (ja) |
-
2022
- 2022-02-17 JP JP2022022958A patent/JP2023119857A/ja active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6959860B2 (en) | System for automatic connection to a network | |
US7275685B2 (en) | Method for electronic payment | |
US8443200B2 (en) | Biometric verification for electronic transactions over the web | |
US20210042804A1 (en) | Data security system and method | |
HRP20020180A2 (en) | Methods and apparatus for conducting electronic transactions | |
WO2005024645A1 (ja) | 情報処理サーバ及び情報処理方法 | |
CN106875177A (zh) | 订单处理方法、装置及支付服务器 | |
JP6524205B1 (ja) | 取引管理システム、取引管理装置、取引管理方法及び取引管理プログラム | |
US9596228B2 (en) | Methods and systems for handling trusted content from various service providers | |
EP2538349A2 (en) | Server, inter-business enterprise information control method and computer program | |
JP2007041672A (ja) | 電子チケット発行システムとそれを実現するためのコンピュータプログラムとその方法 | |
JP2020166601A (ja) | 仲介サーバ、プログラム、及び情報処理方法 | |
JP3917128B2 (ja) | 情報処理方法、情報処理システム、プログラムおよび記録媒体 | |
JP2023119857A (ja) | 情報処理装置、情報処理方法、及びプログラム | |
US20030191691A1 (en) | Computer system for forming a database | |
KR101024370B1 (ko) | 개인자산관리 시스템을 이용한 통합 메신저 뱅킹 방법 | |
JP5220909B2 (ja) | 法人インターネットバンキング利用者に対する緊急時atm振込支援システムおよび方法 | |
JP2000194618A (ja) | 手書き認証通信システム、手書き認証通信方法、手書き認証サーバ及び手書き入力装置 | |
JP7322129B2 (ja) | サービス管理システム、取引サーバ及びサービス管理方法 | |
JP7516896B2 (ja) | カード提供方法、サーバ及びコンピュータプログラム | |
JP2023119856A (ja) | 情報処理システム、及び情報処理方法 | |
JP2023028942A (ja) | 情報処理装置、情報処理方法 | |
JP7314720B2 (ja) | 情報処理システム、情報処理装置、及び情報処理プログラム | |
JP4601227B2 (ja) | 属性情報管理装置、属性情報利用装置および属性情報認証装置 | |
JP2024042294A (ja) | 情報管理システム、及び情報管理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20240209 |