特開 2024-103187 配信サーバ、配信方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024103187

(43)【公開日】2024-08-01

(54)【発明の名称】配信サーバ、配信方法、及びプログラム

(51)【国際特許分類】

   H04M 11/00 20060101AFI20240725BHJP

   H04L 67/303 20220101ALI20240725BHJP

【ＦＩ】

H04M11/00 302

H04L67/303

【審査請求】未請求

【請求項の数】5

【出願形態】ＯＬ

(21)【出願番号】P 2023007383

(22)【出願日】2023-01-20

(71)【出願人】

【識別番号】000003193

【氏名又は名称】ＴＯＰＰＡＮホールディングス株式会社

(74)【代理人】

【識別番号】100149548

【弁理士】

【氏名又は名称】松沼 泰史

(74)【代理人】

【識別番号】100139686

【弁理士】

【氏名又は名称】鈴木 史朗

(74)【代理人】

【識別番号】100169764

【弁理士】

【氏名又は名称】清水 雄一郎

(74)【代理人】

【識別番号】100147267

【弁理士】

【氏名又は名称】大槻 真紀子

(72)【発明者】

【氏名】佐藤 義輝

(72)【発明者】

【氏名】小松 嵩実

(72)【発明者】

【氏名】林 明穂

【テーマコード（参考）】

5K201

【Ｆターム（参考）】

5K201BA05

5K201CA07

5K201CB05

5K201CC01

5K201DC02

5K201EC06

(57)【要約】

【課題】宛先となる通信端末についてＲＣＳに対応しているか否かを確認した上で遅延なくメッセージを送信する。
【解決手段】通信事業者を介してＲＣＳ（Rich Communication Services）を用いたメッセージを通信端末に送信する配信サーバであって、前記メッセージにおける送信予定日までの日数が閾値以上ある場合、前記メッセージの宛先となる通信端末がＲＣＳに対応しているか否かを前記通信事業者により提供されるＡＰＩ（Application Programming Interface）を用いて確認するＲＣＳ対応確認を、前記送信予定日の日前に実行する。
【選択図】図１

【特許請求の範囲】

【請求項1】

通信事業者を介してＲＣＳ（Rich Communication Services）を用いたメッセージを通信端末に送信する配信サーバであって、
前記メッセージにおける送信予定日までの日数が閾値以上ある場合、前記メッセージの宛先となる通信端末がＲＣＳに対応しているか否かを前記通信事業者により提供されるＡＰＩ（Application Programming Interface）を用いて確認するＲＣＳ対応確認を、前記送信予定日の日前に実行する、
配信サーバ。

【請求項2】

前記メッセージの配信に関する配信情報を記憶する記憶部と、
前記送信予定日を含む前記メッセージの配信要求を取得し、取得した前記配信要求に基づいて、前記メッセージの配信予約を、前記配信情報として記憶させる登録部と、
前記配信予約が記憶された登録日から前記送信予定日までの日数が閾値以上である場合、前記ＲＣＳ対応確認を行うためのＲＣＳ確認キューに、前記メッセージの宛先を特定可能なＲＣＳ確認対象情報を格納する事前設定部と、
前記ＲＣＳ確認キューに格納された前記メッセージの前記ＲＣＳ確認対象情報に基づいて、前記メッセージに対する前記ＲＣＳ対応確認を実行し、前記ＲＣＳ対応確認の確認結果を、前記配信情報として記憶させるＲＣＳ対応確認部と、
前記配信予約が記憶された前記メッセージについて、前記配信情報に前記メッセージに対する前記確認結果が記憶されている場合には、前記確認結果に応じて前記メッセージを前記通信端末に送信するための処理を行い、前記配信情報に前記メッセージに対する前記確認結果が記憶されていない場合には、前記ＲＣＳ確認キューに前記メッセージの前記ＲＣＳ確認対象情報を格納する配信処理部と、
を備える請求項１に記載の配信サーバ。

【請求項3】

前記ＲＣＳ対応確認部は、前記事前設定部によって設定された前記メッセージにおける前記ＲＣＳ対応確認を、前記送信予定日の前日以前の日において配信が行われない時間帯に実行する、
を備える請求項２に記載の配信サーバ。

【請求項4】

通信事業者を介してＲＣＳ（Rich Communication Services）を用いたメッセージを通信端末に送信する配信サーバが行う配信方法であって、
前記メッセージにおける送信予定日までの日数が閾値以上ある場合、前記メッセージの宛先となる通信端末がＲＣＳに対応しているか否かを前記通信事業者により提供されるＡＰＩ（Application Programming Interface）を用いて確認するＲＣＳ対応確認を、前記送信予定日の日前に実行する、
配信方法。

【請求項5】

コンピュータを、請求項１から請求項３の何れか一項に記載の配信サーバとして動作させるためのプログラムであって、前記コンピュータを前記配信サーバが備える各部として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、配信サーバ、配信方法、及びプログラムに関する。

【背景技術】

【0002】

オンラインで情報を通知する電子通知サービスがある。特許文献１では、通知先の相手がすぐに見ることのできる確率が高いメールアドレスに情報を送信する技術が開示されている。このような電子通知サービスのうち、通信事業者を介するものとして携帯電話番号を宛先とするメッセージサービスがあり、例えば、ＲＣＳ（Rich Communication Services）がある。

【0003】

ＲＣＳを用いた場合、メッセージの宛先となる電話番号に対応する通信端末が、ＲＣＳに対応しているか否かを、通信事業者を介して事前に確認する処理（ケイパビリティチェック）を行うことができる。これにより、宛先となる通信端末がＲＣＳに対応していない場合、ＲＣＳでないメッセージサービス、例えばＳＭＳ（ショートメッセージサービス）に対応したメッセージを通信端末に送信するような対応を行うことができる。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００７－２４１７３２号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかしながら、ＲＣＳに対応しているか否かの確認には時間がかかる。通信事業者によって提供されるＡＰＩ（Application Programming Interface）を用いて確認を行う場合、単位時間あたりに処理可能な件数はそのＡＰＩに依存する。バッチ処理などにおいて一度に大量のメッセージを送信するような場合であっても、宛先となる通信端末のそれぞれについてＲＣＳに対応しているか否かを確認した上で、遅延なくメッセージが送信されることが望ましい。

【0006】

本発明は、このような事情に鑑みてなされたもので、その目的は、宛先となる通信端末についてＲＣＳに対応しているか否かを確認した上で遅延なくメッセージを送信することができる配信サーバ、配信方法、及びプログラムを提供することにある。

【課題を解決するための手段】

【0007】

上述した課題を解決するために、本発明に係る配信サーバは、通信事業者を介してＲＣＳ（Rich Communication Services）を用いたメッセージを通信端末に送信する配信サーバであって、前記メッセージにおける送信予定日までの日数が閾値以上ある場合、前記メッセージの宛先となる通信端末がＲＣＳに対応しているか否かを前記通信事業者により提供されるＡＰＩ（Application Programming Interface）を用いて確認するＲＣＳ対応確認を、前記送信予定日の日前に実行する。

【0008】

また、本発明に係る配信方法は、通信事業者を介してＲＣＳ（Rich Communication Services）を用いたメッセージを通信端末に送信する配信サーバが行う配信方法であって、前記メッセージにおける送信予定日までの日数が閾値以上ある場合、前記メッセージの宛先となる通信端末がＲＣＳに対応しているか否かを前記通信事業者により提供されるＡＰＩ（Application Programming Interface）を用いて確認するＲＣＳ対応確認を、前記送信予定日の日前に実行する。

【0009】

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

【発明の効果】

【0010】

本発明によれば、宛先となる通信端末についてＲＣＳに対応しているか否かを確認した上で遅延なくメッセージを送信することができる。

【図面の簡単な説明】

【0011】

【図1】実施形態に係る配信システム１の構成例を示すブロック図である。

【図2】実施形態に係る配信情報１１０の例を示す図である。

【図3】実施形態に係る配信システム１が行う処理を説明するための図である。

【図4】実施形態に係る配信システム１が行う処理を説明するための図である。

【図5】実施形態に係る配信サーバ１０が行う処理の流れを示すフローチャートである。

【発明を実施するための形態】

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

通信事業者サーバ３０は、通信事業者によって管理されるサーバ装置である。通信事業者は、例えば、自らが保有又は運用する通信回線を用いて、電話番号を利用した通信サービスを通信端末４０に提供するＭＮＯ（Mobile Network Operator、移動体通信事業者）である。通信サービスには、ＲＣＳを用いた通信が含まれる。通信事業者サーバ３０は、配信サーバ１０、及び通信端末４０との間で無線通信又は有線通信をする。通信事業者サーバ３０は、配信サーバ１０からの配信リクエストに応じて、ＲＣＳを用いたメッセージを通信端末４０に送信する。

【0017】

通信端末４０は、スマートフォン又は携帯電話など、電話番号を対応づけることが可能な通信装置である。通信端末４０は、ユーザ等によって、通信事業者サーバ３０の事業者と、通信端末４０を用いた通信サービスを利用するための契約がなされる。通信端末４０は、契約している通信事業者が提供する通信サービスを用いて通信することが可能である。通信端末４０には電話番号が割り当てられており、この電話番号を送信先とした通信、すなわちＲＣＳを用いた通信を行う機能を有する。

【0018】

通信端末４０は、例えば、液晶ディスプレイ等の表示部と、ユーザによる操作を受け付けるタッチパネル等の操作部を有する。通信端末４０は、通信事業者サーバ３０及び通信端末４０を通信相手として通信ネットワークＮＷを用いた通信をする。ユーザは、例えば生活者である。

【0019】

ここで、ＲＣＳ対応確認について説明する。ＲＣＳ対応確認とは、メッセージの宛先となる通信端末４０が、ＲＣＳに対応しているかを確認することである。

【0020】

一般に、ＳＭＳ（ショートメッセージサービス）についてはほとんどの通信端末４０が対応しているが、ＲＣＳについては対応しているものと対応していないものがある場合が多い。例えば、通信端末４０にＲＣＳのアプリケーションがインストールされ、且つ、ＲＣＳを用いた通信に関する利用規約の同意などを含むアクティベーションが行われた場合、その通信端末４０はＲＣＳに対応している端末である。一方、通信端末４０にＲＣＳのアプリケーションがインストールされていない、又は、ＲＣＳのアプリケーションがインストールされているがアクティベーションが行われていない場合、その通信端末４０はＲＣＳに対応していない端末である。

【0021】

このように、通信端末４０によってはＲＣＳに対応していない場合があることから、ＲＣＳを用いた通信サービスでは、メッセージの宛先となる通信端末４０が、ＲＣＳに対応しているか否かを確認するためのＡＰＩ（Application Programming Interface）が、通信事業者から提供される。

【0022】

例えば、ＲＣＳを用いた通信サービスでは、通信事業者サーバ３０は、配信サーバ１０から、ＲＣＳ対応確認の依頼を受け付ける。具体的に、配信サーバ１０は、メッセージの宛先となる通信端末４０の電話番号を含む宛先情報を通信事業者サーバ３０に通知し、宛先情報に含まれる電話番号に対応する通信端末４０がＲＣＳに対応しているか否かを確認するように依頼する。通信事業者サーバ３０は、配信サーバ１０からの依頼に応じて、ＲＣＳ対応確認を実行し、ＲＣＳ対応確認の確認結果を配信サーバ１０に通知する。

【0023】

これにより、配信サーバ１０は、ＲＣＳ対応確認の確認結果に応じて、通信端末４０が対応可能となる態様にて、メッセージを送信することができる。例えば、ＲＣＳ対応確認をした結果、宛先となる通信端末４０がＲＣＳに対応している場合、配信サーバ１０はＲＣＳに対応したメッセージを通信端末４０に送信するように、通信事業者サーバ３０に対して配信リクエストを行う。一方、ＲＣＳ対応確認をした結果、宛先となる通信端末４０がＲＣＳに対応していない場合、ＲＣＳでないメッセージサービス、例えばＳＭＳ（ショートメッセージサービス）に対応したメッセージを通信端末４０に送信するように、通信事業者サーバ３０に対して配信リクエストを行う。

【0024】

ここで、ＲＣＳに対応しているか否かの確認には時間がかかり、単位時間あたりに処理可能な件数はそのＡＰＩに依存する。バッチ処理などにおいて一度に大量のメッセージを送信するような場合であっても、宛先となる通信端末のそれぞれについてＲＣＳに対応しているか否かを確認した上で、遅延なくメッセージが送信されることが望ましい。

【0025】

そこで、本実施形態では、ＲＣＳ対応確認を事前に行うようにした。ここで、「事前にＲＣＳ対応確認を行う」とは、メッセージを配信する直前ではなく、メッセージを送信する日前に、ＲＣＳ対応確認を行うことである。具体的に、本実施形態では、送信予定日までの日数に余裕があるメッセージについてはＲＣＳ対応確認を事前に行うようにした。一方、送信予定日までの日数に余裕がないメッセージについては、配信予定日にＲＣＳ対応確認を行うようにした。より具体的には、ＲＣＳ対応確認をメッセージの送信予定日の日前に実行するか否かを、送信予定日までの日数に応じて決定するようにした。これにより、バッチ処理などにおいて一度に大量のメッセージを送信するような場合であっても、メッセージを配信する直前に、大量のＲＣＳ対応確認を行う事態を回避することが可能となる。以下、ＲＣＳ対応確認を事前に行う方法について説明する。

【0026】

図１に示すように、配信サーバ１０は、例えば、記憶部１１と、登録部１２と、事前設定部１３と、ＲＣＳ対応確認部１４と、配信処理部１５とを備える。

【0027】

ここで、登録部１２と、事前設定部１３と、ＲＣＳ対応確認部１４と、配信処理部１５とは、信号処理を行う機能部である。機能部は、配信サーバ１０がハードウェアとして備えるＣＰＵ（Central Processing Unit）にプログラムを実行させることによって実現される。

【0028】

記憶部１１は、記憶媒体、例えば、ＨＤＤ（Hard Disk Drive）、フラッシュメモリ、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）、ＲＡＭ（Random Access read/write Memory）、ＲＯＭ（Read Only Memory）、または、これらの記憶媒体の任意の組み合わせによって構成される。記憶部１１は、配信サーバ１０の各種の処理を実行するためのプログラム、及び各種の処理を行う際に利用される一時的なデータを記憶する。

【0029】

記憶部１１は、配信情報１１０と、ＲＣＳ確認キュー１１１と、を記憶する。配信情報１１０は、通信端末４０に送信するメッセージに関する情報である。ＲＣＳ確認キュー１１１は、ＲＣＳ対応確認を行う対象とするメッセージの宛先となる電話番号が格納されるキュー（待ち行列）である。
なお、ＲＣＳ確認キュー１１１に格納される情報は、少なくともメッセージの宛先を特定可能な情報であればよい。ＲＣＳ確認キュー１１１に、メッセージの宛先となる電話番号そのものが格納されてもよいし、メッセージを特定可能なユニークＩＤが格納されるように構成されてもよい。ユニークＩＤは、送信先のユーザを特定する情報である。例えば、ＲＣＳ確認キュー１１１にユニークＩＤが格納される場合、そのユニークＩＤに基づいて配信情報１１０を参照することにより、メッセージの宛先となる電話番号を特定することができる。ここでの電話番号及びユニークＩＤは、「メッセージの宛先を特定可能なＲＣＳ確認対象情報」の一例である。

【0030】

登録部１２は、企業等から通信端末４０宛てに送信するように依頼されたメッセージを登録する。具体的に、登録部１２は、送信予定日を含むメッセージの配信要求を取得し、取得した配信要求に基づいて、メッセージの配信予約を、配信情報１１０として、記憶部１１に記憶させる。例えば、登録部１２は、企業等から通信端末４０宛てに送信するように依頼されたメッセージの配信予約を、企業サーバ２０を介して取得する。配信予約には、例えば、シナリオＩＤ、ユニークＩＤ、配信予定日時、宛先となる電話番号などを含む。登録部１２は、配信予約を、配信情報１１０として記憶部１１に記憶させる（図２参照）。シナリオＩＤは、配信する内容を特定する情報である。ユニークＩＤは、送信先のユーザを特定する情報である。

【0031】

ここで、登録部１２は、配信予約を配信情報１１０に記憶させる際に、登録日時を、配信情報１１０に記憶させるようにしてもよい（図２参照）。登録日時は、配信予約を配信情報１１０に記憶させた日時を示す情報である。

【0032】

登録部１２は、配信情報１１０に記憶されたメッセージについて、ＲＣＳ対応確認を、事前に行うか否かを判定する。例えば、登録部１２は、登録日から送信予定日までの日数が閾値以上ある場合、ＲＣＳ対応確認を事前に行うと判定する。一方、登録部１２は、登録日から、送信予定日までの日数が閾値未満である場合、ＲＣＳ対応確認を事前に行わないと判定する。ここでの登録日は、配信予約が登録された日付であり、配信予約に応じた配信情報１１０が記憶部１１に記憶された日付である。配信予定日は、配信予約に含まれている配信予定日時に応じた日付である。

【0033】

登録部１２は、例えば、以下の（１）式を用いて、ＲＣＳ対応確認を、事前に行うか否かを判定する。（１）式におけるＮは、事前にＲＣＳ対応確認を実行する場合における猶予日数であり、任意に設定される整数である。

【0034】

配信予定日－登録日≧Ｎ［日］ …（１）

【0035】

事前設定部１３は、登録部１２により判定された、ＲＣＳ対応を事前に行うか否かの判定結果に応じて、ＲＣＳ対応を事前に行う対象を、ＲＣＳ確認キュー１１１に格納する。事前設定部１３は、ＲＣＳ対応を事前に行うと判定したメッセージについて、そのメッセージの宛先となる電話番号を、ＲＣＳ確認キュー１１１に格納する。一方、事前設定部１３は、ＲＣＳ対応を事前に行わないと判定したメッセージについて、そのメッセージの宛先となる電話番号を、ＲＣＳ確認キュー１１１に格納しない。

【0036】

ここで、事前設定部１３は、ＲＣＳ対応を事前に行うと判定したメッセージの宛先である電話番号をＲＣＳ確認キュー１１１に格納する際に、ＲＣＳ対応の事前確認を、配信情報１１０に記憶させるようにしてもよい（図２参照）。ＲＣＳ対応の事前確認は、ＲＣＳ対応確認を事前に行う対象とするか否かを示す情報、及びＲＣＳ対応確認を事前に行う対象とする場合にはＲＣＳ対応確認を行う確認予定日時を示す情報を含む。

【0037】

なお、事前設定部１３は、ＲＣＳ対応確認を行う確認予定日時を決定しなくともよい。例えば、事前設定部１３は、ＲＣＳ対応を事前に行う対象とするメッセージの識別情報を、ＲＣＳ確認テーブルに書込んで登録する。ＲＣＳ確認テーブルは、ＲＳＣ確認を実行する対象となったメッセージの情報が登録されるテーブルである。事前設定部１３は、ＲＣＳ確認テーブルに登録を行う際に、ＲＣＳ対応確認を行う日時（確認予定日時）を算出したり、配信情報１１０に記憶させたりする処理を実行せず、識別情報をテーブルに登録する。その後、事前設定部１３とは別の機能部が、定期的、例えば夜間など配信が行われないか、又は配信する件数が少ない時間帯に、ＲＣＳ確認テーブルを参照し、ＲＣＳ確認テーブルに登録されているメッセージの電話番号を、ＲＣＳ確認キュー１１１に格納するようにしてもよい。

【0038】

また、バッチ処理などにおいて一度に複数のメッセージを送信する場合、一度に（同じ送信時刻に）配信するメッセージ群（配信の束）毎にＲＣＳ対応を事前に行うか否かが判定されるようにしてもよい。この場合、登録部１２は、ショットＩＤごとに、ＲＣＳ対応を事前に行うか否かを判定する。ショットＩＤは、バッチ処理などにおいて一度に複数のメッセージを送信する場合における、一度に（同じ送信時刻に）配信するメッセージ群（配信の束）を識別する識別情報である。

【0039】

この場合、事前設定部１３は、例えば、ＲＣＳ対応を事前に行う対象とする配信の束を識別するショットＩＤを、ＲＣＳ確認テーブルに書込んで登録する。その後、事前設定部１３とは別の機能部が、定期的、例えば夜間などに、ＲＣＳ確認テーブルを参照し、ＲＣＳ確認テーブルに登録されているショットＩＤに該当するメッセージのそれぞれの電話番号を、ＲＣＳ確認キュー１１１に格納する。

【0040】

ＲＣＳ対応確認部１４は、ＲＣＳ確認キューに、宛先情報が設定されたメッセージにおけるＲＣＳ対応確認を実行する。例えば、ＲＣＳ対応確認部１４は、定期的にＲＣＳ確認キュー１１１を参照し、ＲＣＳ確認キュー１１１に格納されている電話番号を含む宛先情報を通信事業者サーバ３０に通知することによって、ＲＣＳ対応確認を依頼する。

【0041】

通信事業者サーバ３０は、配信サーバ１０からの依頼に応じてＲＣＳ対応確認を行い、その確認結果、つまりメッセージの宛先である電話番号に対応する通信端末４０がＲＣＳに対応しているか否かを示す情報を配信サーバ１０に通知する。

【0042】

ＲＣＳ対応確認部１４は、通信事業者サーバ３０から通知された確認結果を、ＲＣＳ対応の確認結果として、配信情報１１０に記憶させる（図２参照）。ＲＣＳ対応の確認結果は、ＲＣＳ対応確認が実行された日時を示す情報である確認日時、及び、ＲＣＳ対応確認の確認結果を示す情報を含む。

【0043】

なお、ＲＣＳ対応確認部１４は、ＲＣＳ対応確認を事前に行う場合、送信予定日の前日以前の日において配信が行われない時間帯、若しくは、配信する件数が少ない時間帯、例えば、深夜となる時間帯に、ＲＣＳ対応確認を実行するようにしてもよい。これにより、メッセージを送信しない時間帯にＲＣＳ対応確認を実行することができ、配信サーバ１０の処理が集中することを回避することができる。

【0044】

また、ＲＣＳ対応確認部１４は、ＲＣＳ対応確認を事前に行う場合において、配信予定日時になるべく近い日にＲＣＳ対応確認を行う方が良い。

【0045】

例えば、ＲＣＳのアプリケーションがインストールされ、且つ、アクティベーションが行われており、ＲＣＳに対応した通信端末４０があり、配信予定日の３日前に行ったＲＣＳ対応確認の確認結果では、ＲＣＳ対応ありであったとする。その後、配信予定日時の２日前にＲＣＳのアプリケーションがアンインストールされてしまう場合があり得る。このような場合、３日前に行ったＲＣＳ対応確認の確認結果に基づいて、通信端末４０にＲＣＳを用いたメッセージを送信してしまうと、そのメッセージは通信端末４０に受信されない。このような事態をなるべく回避するために、ＲＣＳ対応確認を事前に行う場合において、配信予定日時になるべく近い日にＲＣＳ対応確認を行うことが望ましい。

【0046】

この対策として、例えば、事前設定部１３は、電話番号をＲＣＳ確認キュー１１１に格納する際に、ＲＣＳ対応の事前確認における、確認予定日時を、送信予定日の前日において配信が行われない時間帯に、設定する。例えば、事前設定部１３は、以下の（２）式を用いて、配信予定日時のＸ［時間］前にＲＣＳ対応確認が実行されるように、確認予定日時を決定する。

【0047】

確認予定日時＝配信予定日時－Ｘ［時間］ …（２）

【0048】

（２）式におけるＸは、１から２４までの任意に設定される実数である。例えば、Ｘに１２を設定した場合、配信予定日時の１２［時間］前にＲＣＳ対応確認が実行される。この場合、配信が行われる昼間の時間帯を避け、かつ配信予定日時に近い前日の深夜の時間帯に、事前のＲＣＳ対応確認が実行される。

【0049】

配信処理部１５は、メッセージを、通信端末４０に送信するための処理を実行する。配信処理部１５は、送信対象であるメッセージの配信情報１１０の全部又は一部を通信事業者サーバ３０に通知し、通知した配信情報１１０に対応するメッセージを、宛先である通信端末４０に配信するように要求する配信リクエストを行うことによって、通信端末４０に送信するための処理を実行する。通信事業者サーバ３０は、配信リクエストに応じて、メッセージを、通信端末４０に送信する。

【0050】

配信処理部１５は、例えば、定期的に配信情報１１０を参照し、配信情報１１０の配信予約における配信予定日時に、そのメッセージが送信されるように、配信リクエストを行う。

【0051】

配信処理部１５は配信情報１１０にメッセージに対するＲＣＳ対応確認の確認結果が記憶されている場合には、その確認結果に応じて、メッセージを通信端末４０に送信するための処理（配信リクエスト）を行う。

【0052】

例えば、配信処理部１５は、確認結果としてＲＣＳ対応あり、つまり宛先となる通信端末４０がＲＣＳに対応している旨が示されている場合、ＲＣＳを用いたメッセージを通信端末４０に送信するための配信リクエストを行う。一方、配信処理部１５は、確認結果としてＲＣＳ対応なし、つまり宛先となる通信端末４０がＲＣＳに対応していない旨が示されている場合、ＲＣＳとは異なるメッセージングサービス、例えばＳＭＳを用いたメッセージを通信端末４０に送信するための配信リクエストを行う。

【0053】

一方、配信処理部１５は配信情報１１０にメッセージに対するＲＣＳ対応確認の確認結果が記憶されていない場合には、そのメッセージの宛先となる電話番号を、ＲＣＳ確認キュー１１１に格納する。

【0054】

例えば、配信処理部１５は、確認結果としてＲＣＳ対応あり、つまり宛先となる通信端末４０がＲＣＳに対応している旨が示されている場合、ＲＣＳを用いたメッセージを通信端末４０に送信するための配信リクエストを行う。一方、配信処理部１５は、確認結果としてＲＣＳ対応なし、つまり宛先となる通信端末４０がＲＣＳに対応していない旨が示されている場合、ＲＣＳとは異なるメッセージングサービス、例えばＳＭＳを用いたメッセージを通信端末４０に送信するための配信リクエストを行う。

【0055】

図１に示すように、通信事業者サーバ３０は、例えば、配信ＡＰＩ３１と、ＲＣＳ対応確認ＡＰＩ３２を備える。配信ＡＰＩ３１は、配信サーバ１０からの配信リクエストに応じたメッセージを宛先の通信端末４０に配信する。ＲＣＳ対応確認ＡＰＩ３２は、配信サーバ１０からの依頼に応じて、通信端末４０がＲＣＳに対応しているか否かを判定し、その結果を配信サーバ１０に送信する。

【0056】

図２は、実施形態に係る配信情報１１０の例を示す図である。配信情報１１０は、例えば、配信予約、登録日時、ＲＣＳ対応の事前確認、及び、ＲＣＳ対応の確認結果のそれぞれに対応する情報を記憶する。

【0057】

配信予約は、メッセージを送信する予約するための情報であり、例えば、企業などから依頼される配信要求に基づいて、登録部１２によって記憶される情報である。配信予約は、例えば、シナリオＩＤ、ユニークＩＤ、配信予定日時、及び、電話番号などを示す情報を含む。シナリオＩＤは、配信する内容を特定する情報である。ユニークＩＤは、送信先のユーザを特定する情報である。配信予定日時は、メッセージを送信する予定の日時を示す情報である。電話番号は、メッセージの宛先となる電話番号を示す情報である。

【0058】

登録日時は、登録部１２によって、配信予約が配信情報１１０に記憶された日時を示す情報である。例えば、登録部１２は、配信予約を配信情報１１０に記憶させる際に、その配信予約を記憶させた日時を、登録日時として、配信情報１１０に記憶させる。

【0059】

ＲＣＳ対応の事前確認は、事前のＲＣＳ対応確認を行うか否かを判定した結果を示す情報である。ＲＣＳ対応の事前確認は、事前確認の対象とするかを示す情報、及び、確認予定日時を示す情報を含む。事前設定部１３は、事前のＲＣＳ対応確認を行うか否かを判定し、その判定結果を、ＲＣＳ対応の事前確認として、配信情報１１０に記憶させる。

【0060】

ＲＣＳ対応の確認結果は、ＲＣＳ対応確認を行った結果である。ＲＣＳ対応の確認結果は、ＲＣＳ対応確認が行われた日時を示す情報、及び、ＲＣＳ対応確認の確認結果を示す情報を含む。ＲＣＳ対応確認部１４は、ＲＣＳ対応確認を行い、その確認結果を、ＲＣＳ対応の確認結果として、配信情報１１０に記憶させる。

【0061】

ここで、図３及び図４を用いて、配信システム１が行う処理の流れを説明する。図３及び図４は、実施形態に係る配信システム１が行う処理を説明するための図である。

【0062】

図３には、事前にＲＣＳ対応確認を行う対象とされたメッセージについて、配信システム１が行う処理の流れが示されている。

【0063】

図３に示すように、まず、配信サーバ１０の登録部１２は、配信要求に基づいて、配信予約を配信情報１１０に記憶させる（ステップＳ１）。事前設定部１３は、配信予約に含まれる配信予定日と、登録日とに基づいて、事前のＲＣＳ対応確認を行う対象とするか否かを判定する（ステップＳ２）。事前設定部１３は、事前のＲＣＳ対応確認を行う対象とするメッセージの宛先となる電話番号を、ＲＣＳ確認キュー１１１に格納する（ステップＳ３）。

【0064】

ＲＣＳ対応確認部１４は、ＲＣＳ確認キュー１１１を参照し、ＲＣＳ確認キュー１１１に格納されている電話番号を取得する（ステップＳ４）。ＲＣＳ対応確認部１４は、取得した電話番号を含む宛先情報を通信事業者サーバ３０に送信してＲＣＳ対応確認を依頼し、ＲＣＳ対応確認ＡＰＩ３２からＲＣＳ対応確認の確認結果を受信する（ステップＳ５）。ＲＣＳ対応確認部１４は、ＲＣＳ対応確認ＡＰＩ３２から通知されたＲＣＳ対応確認の確認結果を、配信情報１１０に記憶させる（ステップＳ６）。

【0065】

配信処理部１５は、配信情報１１０を参照し、配信予定日時において通信端末４０に送信するメッセージの配信情報１１０を取得する（ステップＳ７）。ここで、配信情報１１０には、ステップＳ６にて実行されたＲＣＳ対応確認の確認結果が記憶されている。配信処理部１５は、取得した配信情報１１０に確認結果が記憶されていることから、その確認結果に基づいて、ＲＣＳに対応している通信端末４０にはＲＣＳを用いたメッセージを送信するための配信リクエストを、通信事業者サーバ３０に対して行う（ステップＳ８）。一方、ＲＣＳに対応していない通信端末４０にはＳＭＳを用いたメッセージを送信するための配信リクエストを、通信事業者サーバ３０に対して行う。これにより、配信ＡＰＩ３１によってメッセージが通信端末４０に送信される。

【0066】

図４には、事前にＲＣＳ対応確認を行う対象外とされたメッセージについて、配信システム１が行う処理の流れが示されている。

【0067】

図４に示すように、まず、配信サーバ１０の登録部１２は、配信要求に基づいて、配信予約を配信情報１１０に記憶させる（ステップＳ１０）。このとき、事前設定部１３は、配信予約に含まれる配信予定日と、登録日とに基づいて、メッセージを、事前のＲＣＳ対応確認を行う対象外と判定する。

【0068】

配信処理部１５は、配信情報１１０を参照し、配信予定日時において通信端末４０に送信するメッセージの配信情報１１０を取得する（ステップＳ１１）。ここで、配信情報１１０には、ＲＣＳ対応確認の確認結果が記憶されていない。配信処理部１５は、取得した配信情報１１０に確認結果が記憶されていないことから、このメッセージの宛先となる電話番号を、ＲＣＳ確認キュー１１１に格納する（ステップＳ１２）。

【0069】

ステップＳ１３～Ｓ１７に示す処理は、図３のステップＳ４～Ｓ８に示す処理と同等であるため、その説明を省略する。

【0070】

ここで、配信サーバ１０が行う処理について、図５を用いて説明する。図５は、実施形態に係る配信サーバ１０が行う処理の流れを示すフローチャートである。

【0071】

配信サーバ１０は、企業サーバ２０から、メッセージの配信要求を取得する（ステップＳ２０）。配信サーバ１０は、取得した配信要求に基づいて、メッセージの配信予約を配信情報１１０に記憶させる（ステップＳ２１）。配信サーバ１０は、メッセージについて、事前にＲＣＳ対応確認する対象とするか否かを判定する（ステップＳ２２）。配信サーバ１０は、メッセージの配信予約に含まれる配信予定日と登録日との差分である猶予日数が、閾値以上であれば、そのメッセージを、事前にＲＣＳ対応確認する対象とする。

【0072】

配信サーバ１０は、事前にＲＣＳ対応確認する対象とする場合、配信情報１１０に、そのメッセージにおける「ＲＣＳ対応の事前確認」を記憶させる（ステップＳ２３）。また、配信サーバ１０は、事前にＲＣＳ対応確認する対象とする場合、そのメッセージの宛先となる電話番号をＲＣＳ確認キュー１１１に格納する（ステップＳ２４）。

【0073】

ＲＣＳ対応確認のタイミングが到来した場合（ステップＳ２５、ＹＥＳ）、配信サーバ１０は、ＲＣＳ対応確認を実行する（ステップＳ２６）。配信サーバ１０は、ＲＣＳ対応確認の対象とするメッセージに対応する宛先情報を通信事業者サーバ３０に送信することにより、ＲＣＳ対応確認を依頼し、通信事業者サーバ３０から確認結果を受信する。配信サーバ１０は、通信事業者サーバ３０から受信した確認結果を、配信情報１１０の「ＲＣＳ対応の確認結果」として記憶させる（ステップＳ２７）。

【0074】

メッセージを配信するタイミングが到来した場合（ステップＳ２８、ＹＥＳ）、配信サーバ１０は、配信の対象とするメッセージの配信情報１１０に、「ＲＣＳ対応の確認結果」が記憶されているか否かを判定する（ステップＳ２９）。

【0075】

配信サーバ１０は、配信の対象とするメッセージの配信情報１１０に、「ＲＣＳ対応の確認結果」が記憶されている場合、その確認結果に応じて、そのメッセージを配信するための配信リクエストを行う（ステップＳ３０）。

【0076】

一方、配信サーバ１０は、配信の対象とするメッセージの配信情報１１０に、「ＲＣＳ対応の確認結果」が記憶されていない場合、そのメッセージの宛先となる電話番号をＲＣＳ確認キュー１１１に格納する（ステップＳ３１）。この場合、ＲＣＳ対応確認のタイミングが到来した場合にステップＳ２５においてＲＣＳ対応確認が実行され、メッセージを配信するタイミングが到来した場合にステップＳ２９及びＳ３０にて配信リクエストが実行される。

【0077】

なお、図５のフローでは、ステップＳ２５の実施タイミングが到来した時点（深夜に実行されるバッチやタスクが起動した時点）において、ステップＳ２３及びＳ２４が実行されるように構成されても良い。

【0078】

以上説明したように、実施形態の配信サーバ１０は、通信事業者を介してＲＣＳを用いたメッセージを通信端末４０に送信する配信サーバである。配信サーバ１０は、メッセージにおける送信予定日までの日数が閾値以上ある場合、ＲＣＳ対応確認を、その送信予定日の日前に実行する。ＲＣＳ対応確認は、メッセージの宛先となる通信端末４０がＲＣＳに対応しているか否かを、通信事業者により提供されるＡＰＩを用いて確認する処理である。これにより、実施形態の配信サーバ１０は、送信予定日までの日数に余裕がある場合に、事前にＲＣＳ対応確認を行うことができる。このため、メッセージの宛先となる通信端末についてＲＣＳに対応しているか否かを確認した上で遅延なくメッセージを送信することができる。

【0079】

また、実施形態の配信サーバ１０は、記憶部１１と、登録部１２と、事前設定部１３と、ＲＣＳ対応確認部１４と、配信処理部１５を備える。記憶部１１は、配信情報１１０を記憶する。登録部１２は、送信予定日を含むメッセージの配信要求を取得し、取得した配信要求に基づいて、メッセージの配信予約を、配信情報１１０として、記憶部１１に記憶させる。事前設定部１３は、配信予約が記憶された登録日から、送信予定日までの日数が閾値以上である場合、ＲＣＳ確認キュー１１１（ＲＣＳ対応確認を行うためのＲＣＳ確認キュー）に、電話番号（メッセージの宛先を特定可能なＲＣＳ確認対象情報）を格納する。ＲＣＳ対応確認部１４は、ＲＣＳ確認キュー１１１に格納された電話番号に基づいて、そのメッセージに対するＲＣＳ対応確認を実行する。ＲＣＳ対応確認部１４は、ＲＣＳ対応確認の確認結果を、配信情報１１０として記憶部１１に記憶させる。配信処理部１５は、配信情報１１０において配信予約が記憶されたメッセージについて、配信情報１１０にメッセージに対するＲＣＳ対応確認の確認結果が記憶されている場合には、その確認結果に応じて配信リクエスト（メッセージを前記通信端末に送信するための処理）を行う。配信処理部１５は、配信情報１１０にメッセージに対するＲＣＳ対応確認の確認結果が記憶されていない場合には、ＲＣＳ確認キュー１１１にそのメッセージの宛先となる電話番号を格納する。これにより、実施形態の配信サーバ１０は、上述した効果と同様の効果を奏する。

【0080】

また、実施形態の配信サーバ１０では、ＲＣＳ対応確認部１４は、事前設定部１３によって設定されたメッセージにおけるＲＣＳ対応確認を、送信予定日の前日の深夜の時間帯（前日以前の日において配信が行われない時間帯）に実行する。これにより、実施形態の配信サーバ１０では、事前のＲＣＳ対応確認を、メッセージを送信しない時間帯に実行することができ配信が集中する時間帯を避けて配信サーバ１０の処理が集中することを回避することができる。また、事前のＲＣＳ対応確認を前日の深夜に行うことにより、通信端末４０がＲＣＳに対応しているか否かを、より正確に確認することができる。

【0081】

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

【0082】

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

【符号の説明】

【0083】

１…配信システム、１０…配信サーバ、２０…企業サーバ、３０…通信事業者サーバ、４０…通信端末４０、１１０…配信情報、１１１…ＲＣＳ確認キュー、１２…登録部、１３…事前設定部、１４…ＲＣＳ対応確認部、１５…配信処理部

【図1】

【図2】

【図3】

【図4】

【図5】