知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024048824
(43)【公開日】2024-04-09
(54)【発明の名称】配信サーバ、及び配信方法
(51)【国際特許分類】
H04L 51/226 20220101AFI20240402BHJP
H04M 11/00 20060101ALI20240402BHJP
【ＦＩ】
H04L51/226
H04M11/00 302
【審査請求】未請求
【請求項の数】5
【出願形態】ＯＬ
(21)【出願番号】P 2022154945
(22)【出願日】2022-09-28
(71)【出願人】
【識別番号】000003193
【氏名又は名称】ＴＯＰＰＡＮホールディングス株式会社
(74)【代理人】
【識別番号】100149548
【弁理士】
【氏名又は名称】松沼 泰史
(74)【代理人】
【識別番号】100139686
【弁理士】
【氏名又は名称】鈴木 史朗
(74)【代理人】
【識別番号】100169764
【弁理士】
【氏名又は名称】清水 雄一郎
(74)【代理人】
【識別番号】100147267
【弁理士】
【氏名又は名称】大槻 真紀子
(72)【発明者】
【氏名】佐藤 義輝
(72)【発明者】
【氏名】小松 嵩実
(72)【発明者】
【氏名】小野田 千紘
(72)【発明者】
【氏名】林 明穂
【テーマコード（参考）】
5K201
【Ｆターム（参考）】
5K201BA05
5K201CA09
(57)【要約】 （修正有）
【課題】バッチ処理による大量の配信情報が配信キューに格納された場合であっても、オンデマンド配信及び配信済みのメッセージの状況に応じて配信される２通目以降のメッセージを遅延なく配信する配信サーバ及び配信方法を提供する。
【解決手段】配信システム１において、配信サーバ１０は、バッチ処理により配信するメッセージを標準配信キュー１３に格納し配信リクエストに応じてオンデマンド配信するメッセージを優先配信キュー１４に格納する振分処理部１５と、優先配信キュー１４に格納されていない場合に標準配信キュー１３に格納されたメッセージを配信するための処理を実行する配信処理部１７と、配信処理部によって配信された配信済メッセージの状況を示す状況情報に基づいて配信する２通目以降のメッセージに関する第３配信情報を生成して優先配信キュー１４に格納する受付処理部１８と、を備える。
【選択図】図１
【解決手段】配信システム１において、配信サーバ１０は、バッチ処理により配信するメッセージを標準配信キュー１３に格納し配信リクエストに応じてオンデマンド配信するメッセージを優先配信キュー１４に格納する振分処理部１５と、優先配信キュー１４に格納されていない場合に標準配信キュー１３に格納されたメッセージを配信するための処理を実行する配信処理部１７と、配信処理部によって配信された配信済メッセージの状況を示す状況情報に基づいて配信する２通目以降のメッセージに関する第３配信情報を生成して優先配信キュー１４に格納する受付処理部１８と、を備える。
【選択図】図１
【特許請求の範囲】
【請求項1】
バッチ処理により配信するメッセージに関する第１配信情報を標準配信キューに格納し、配信リクエストに応じてオンデマンド配信するメッセージに関する第２配信情報を前記標準配信キューとは異なる優先配信キューに格納する振分処理部と、
前記優先配信キューに前記第２配信情報が格納されているか否かを判定し、前記第２配信情報が格納されている場合、前記第２配信情報に対応するメッセージを配信するための処理を実行し、前記優先配信キューに前記第２配信情報が格納されていない場合に前記標準配信キューに格納された前記第１配信情報に対応するメッセージを配信するための処理を実行する配信処理部と、
前記配信処理部によって配信された配信済メッセージの状況を示す状況情報に基づいて、前記状況に応じて配信する２通目以降のメッセージに関する第３配信情報を生成し、生成した前記第３配信情報に対応する前記配信済メッセージが前記バッチ処理により配信されたメッセージであるか前記オンデマンド配信されたメッセージであるかに関わらず、前記第３配信情報を前記優先配信キューに格納する受付処理部と、
を備える配信サーバ。
前記優先配信キューに前記第２配信情報が格納されているか否かを判定し、前記第２配信情報が格納されている場合、前記第２配信情報に対応するメッセージを配信するための処理を実行し、前記優先配信キューに前記第２配信情報が格納されていない場合に前記標準配信キューに格納された前記第１配信情報に対応するメッセージを配信するための処理を実行する配信処理部と、
前記配信処理部によって配信された配信済メッセージの状況を示す状況情報に基づいて、前記状況に応じて配信する２通目以降のメッセージに関する第３配信情報を生成し、生成した前記第３配信情報に対応する前記配信済メッセージが前記バッチ処理により配信されたメッセージであるか前記オンデマンド配信されたメッセージであるかに関わらず、前記第３配信情報を前記優先配信キューに格納する受付処理部と、
を備える配信サーバ。
【請求項2】
前記配信サーバは、通信事業者サーバを介して、ＲＣＳ（Rich Communication Services）を利用したメッセージを配信し、
前記配信処理部は、前記通信事業者サーバを介してメッセージを配信し、
前記受付処理部は、前記配信処理部によって配信されたメッセージが配信先に受信されたことに伴って前記通信事業者サーバから通知されるＷｅｂｈｏｏｋ情報を前記状況情報として取得し、取得したＷｅｂｈｏｏｋ情報に基づいて前記第３配信情報を生成する、
請求項１に記載の配信サーバ。
前記配信処理部は、前記通信事業者サーバを介してメッセージを配信し、
前記受付処理部は、前記配信処理部によって配信されたメッセージが配信先に受信されたことに伴って前記通信事業者サーバから通知されるＷｅｂｈｏｏｋ情報を前記状況情報として取得し、取得したＷｅｂｈｏｏｋ情報に基づいて前記第３配信情報を生成する、
請求項１に記載の配信サーバ。
【請求項3】
前記配信サーバは、通信事業者サーバを介して、ＲＣＳ（Rich Communication Services）を利用したメッセージを配信し、
前記配信処理部は、メッセージに含まれるコンテンツに、前記コンテンツが操作されたことに対応して送信する次メッセージを示す情報を含むポストバックデータを設定したメッセージを、前記通信事業者サーバを介して配信し、
前記受付処理部は、前記コンテンツが操作されたことに伴って前記通信事業者サーバから通知されるＷｅｂｈｏｏｋ情報を前記状況情報として取得し、取得したＷｅｂｈｏｏｋ情報に含まれる前記ポストバックデータに示された前記次メッセージを示す情報に基づいて前記第３配信情報を生成する、
請求項１に記載の配信サーバ。
前記配信処理部は、メッセージに含まれるコンテンツに、前記コンテンツが操作されたことに対応して送信する次メッセージを示す情報を含むポストバックデータを設定したメッセージを、前記通信事業者サーバを介して配信し、
前記受付処理部は、前記コンテンツが操作されたことに伴って前記通信事業者サーバから通知されるＷｅｂｈｏｏｋ情報を前記状況情報として取得し、取得したＷｅｂｈｏｏｋ情報に含まれる前記ポストバックデータに示された前記次メッセージを示す情報に基づいて前記第３配信情報を生成する、
請求項１に記載の配信サーバ。
【請求項4】
メッセージの配信先である通信端末がＲＣＳに対応しているか否かを判定するための処理を行う判定処理部を更に備え、
前記配信処理部は、前記判定処理部が行った処理の結果に応じて前記通信端末がＲＣＳに対応していると判定された場合に、ＲＣＳを利用したメッセージを配信するための処理を行う、
請求項２又は請求項３に記載の配信サーバ。
前記配信処理部は、前記判定処理部が行った処理の結果に応じて前記通信端末がＲＣＳに対応していると判定された場合に、ＲＣＳを利用したメッセージを配信するための処理を行う、
請求項２又は請求項３に記載の配信サーバ。
【請求項5】
コンピュータが行う配信方法であって、
振分処理部が、バッチ処理により配信するメッセージに関する第１配信情報を標準配信キューに格納し、配信リクエストに応じてオンデマンド配信するメッセージに関する第２配信情報を前記標準配信キューとは異なる優先配信キューに格納し、
配信処理部が、前記優先配信キューに前記第２配信情報が格納されているか否かを判定し、前記第２配信情報が格納されている場合、前記第２配信情報に対応するメッセージを配信するための処理を実行し、前記優先配信キューに前記第２配信情報が格納されていない場合に前記標準配信キューに格納された前記第１配信情報に対応するメッセージを配信するための処理を実行し、
受付処理部が、前記配信処理部によって配信された配信済メッセージの状況を示す状況情報に基づいて、前記状況に応じて配信する２通目以降のメッセージに関する第３配信情報を生成し、生成した前記第３配信情報に対応する前記配信済メッセージが前記バッチ処理により配信されたメッセージであるか前記オンデマンド配信されたメッセージであるかに関わらず、前記第３配信情報を前記優先配信キューに格納する、
配信方法。
振分処理部が、バッチ処理により配信するメッセージに関する第１配信情報を標準配信キューに格納し、配信リクエストに応じてオンデマンド配信するメッセージに関する第２配信情報を前記標準配信キューとは異なる優先配信キューに格納し、
配信処理部が、前記優先配信キューに前記第２配信情報が格納されているか否かを判定し、前記第２配信情報が格納されている場合、前記第２配信情報に対応するメッセージを配信するための処理を実行し、前記優先配信キューに前記第２配信情報が格納されていない場合に前記標準配信キューに格納された前記第１配信情報に対応するメッセージを配信するための処理を実行し、
受付処理部が、前記配信処理部によって配信された配信済メッセージの状況を示す状況情報に基づいて、前記状況に応じて配信する２通目以降のメッセージに関する第３配信情報を生成し、生成した前記第３配信情報に対応する前記配信済メッセージが前記バッチ処理により配信されたメッセージであるか前記オンデマンド配信されたメッセージであるかに関わらず、前記第３配信情報を前記優先配信キューに格納する、
配信方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、配信サーバ、及び配信方法に関する。
【背景技術】
【0002】
オンラインで情報を通知するメッセージサービスがある（例えば、特許文献１）。このようなサービスでは、メッセージを配信する際に、まず、配信キューに配信情報がキューイング（格納）される。次に、配信キューに格納された配信情報が１つずつ取得され、取得された配信情報を配信する配信処理が行われる。配信処理の方法として、例えば、バッチ処理によるバルク配信と、オンデマンド配信の２つが存在する。前者は、バッチ処理のタイミングが到来する度に複数のメッセージを一括して配信する処理であり、例えば、１０時に１万件のメッセージを配信するような処理が行われる。後者のオンデマンド配信においては、個別に配信リクエストを受け付け、配信リクエストに応じてリアルタイムにメッセージを配信する。
【0003】
また、メッセージサービスでは、１通目のメッセージの状況に応じて、２通目以降のメッセージが配信される。例えば、「マイページの使い方について動画で詳しくご覧になりますか」などの案内文と共に、「はい」及び「いいえ」が示された操作ボタンを含むメッセージが配信されたとする。このメッセージに対し、「はい」が操作された場合、動画を含むメッセージが送信される。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開２００７－２４１７３２号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、バルク配信を行う場合、バッチ処理による大量の配信情報が配信キューに格納される。大量の配信情報が配信キューに格納されている状態で、オンデマンド配信による配信リクエストを受信した場合、オンデマンド配信による配信が遅延する可能性がある。オンデマンド配信においては、配信リクエストを受け付けてから遅延なくメッセージが配信される方がよい。また、配信済みのメッセージの状況に応じて配信される２通目以降のメッセージにおいても、返信を待っているユーザの期待に応えられるように、遅延なく配信されることが望ましい。
【0006】
本発明は、このような事情に鑑みてなされたもので、その目的は、バッチ処理による大量の配信情報が配信キューに格納された場合であっても、オンデマンド配信、及び配信済みのメッセージの状況に応じて配信される２通目以降のメッセージを遅延なく配信することができる配信サーバ、及び配信方法を提供することにある。
【課題を解決するための手段】
【0007】
上述した課題を解決するために、本発明に係る配信サーバは、バッチ処理により配信するメッセージに関する第１配信情報を標準配信キューに格納し、配信リクエストに応じてオンデマンド配信するメッセージに関する第２配信情報を前記標準配信キューとは異なる優先配信キューに格納する振分処理部と、前記優先配信キューに前記第２配信情報が格納されているか否かを判定し、前記第２配信情報が格納されている場合、前記第２配信情報に対応するメッセージを配信するための処理を実行し、前記優先配信キューに前記第２配信情報が格納されていない場合に前記標準配信キューに格納された前記第１配信情報に対応するメッセージを配信するための処理を実行する配信処理部と、前記配信処理部によって配信された配信済メッセージの状況を示す状況情報に基づいて、前記状況に応じて配信する２通目以降のメッセージに関する第３配信情報を生成し、生成した前記第３配信情報に対応する前記配信済メッセージが前記バッチ処理により配信されたメッセージであるか前記オンデマンド配信されたメッセージであるかに関わらず、前記第３配信情報を前記優先配信キューに格納する受付処理部と、を備える。
【0008】
また、本発明に係る配信方法は、コンピュータが行う配信方法であって、振分処理部が、バッチ処理により配信するメッセージに関する第１配信情報を標準配信キューに格納し、配信リクエストに応じてオンデマンド配信するメッセージに関する第２配信情報を前記標準配信キューとは異なる優先配信キューに格納し、配信処理部が、前記優先配信キューに前記第２配信情報が格納されているか否かを判定し、前記第２配信情報が格納されている場合、前記第２配信情報に対応するメッセージを配信するための処理を実行し、前記優先配信キューに前記第２配信情報が格納されていない場合に前記標準配信キューに格納された前記第１配信情報に対応するメッセージを配信するための処理を実行し、受付処理部が、前記配信処理部によって配信された配信済メッセージの状況を示す状況情報に基づいて、前記状況に応じて配信する２通目以降のメッセージに関する第３配信情報を生成し、生成した前記第３配信情報に対応する前記配信済メッセージが前記バッチ処理により配信されたメッセージであるか前記オンデマンド配信されたメッセージであるかに関わらず、前記第３配信情報を前記優先配信キューに格納する。
【発明の効果】
【0009】
本発明によれば、バッチ処理による大量の配信情報が配信キューに格納された場合であっても、オンデマンド配信、及び配信済みのメッセージの状況に応じて配信される２通目以降のメッセージを遅延なく配信することができる。
【図面の簡単な説明】
【0010】
【図1】実施形態に係る配信システム１の例を示すブロック図である。
【図2】実施形態に係る通信端末４０に表示されるメッセージの例を示す図である。
【図3】実施形態に係る配信情報記憶部１１に記憶される情報の例を示す図である。
【図4】実施形態に係る配信メッセージ履歴情報記憶部１２に記憶される情報の例を示す図である。
【図5】実施形態に係る配信システム１が行う処理の流れを示す図である。
【図6】実施形態に係る配信システム１が行う処理の流れを示す図である。
【図7】実施形態に係る配信システム１が行う処理の流れを示す図である。
【図8】実施形態に係る配信システム１が行う処理の流れを示す図である。
【図9】実施形態に係る配信システム１が行う処理の流れを示す図である。
【図10】実施形態に係る配信システム１が行う処理の流れを示す図である。
【図11】実施形態に係る配信情報記憶部１１に記憶される情報の例を示す図である。
【図12】実施形態に係る配信情報記憶部１１に記憶される情報の例を示す図である。
【発明を実施するための形態】
【0011】
以下、本発明の一実施形態について図面を参照して説明する。
【0012】
図１は、実施形態に係る配信システム１の例を示すブロック図である。配信システム１は、例えば、配信サーバ１０と、企業サーバ２０と、通信事業者サーバ３０と、通信端末４０とを備える。
【0013】
配信サーバ１０は、企業サーバ２０に対応する企業から依頼されたメッセージを配信する情報処理装置である。配信サーバ１０として、例えば、サーバ装置、パーソナルコンピューター（ＰＣ）などのコンピュータを適用することができる。配信サーバ１０は、企業サーバ２０、及び通信事業者サーバ３０との間で無線通信又は有線通信をする。
【0014】
配信サーバ１０は、企業サーバ２０から依頼されたメッセージを通信端末４０に配信するための制御を行う。例えば、配信サーバ１０は、電話番号を宛先とするメッセージサービスであるＲＣＳ（Rich Communication Services）利用したＲＣＳメッセージを配信する。
【0015】
配信サーバ１０は、企業サーバ２０に対応する企業からの依頼の内容に応じて、メッセージを配信する。配信サーバ１０は、例えば、企業からの依頼の内容に応じて、バッチ処理によるバルク配信と、オンデマンド配信の２つの配信方法によりメッセージを配信する。バルク配信は、バッチ処理のタイミングが到来する度に複数のメッセージを一括して配信する処理であり、例えば、１０時に１万件のメッセージを配信するような処理が行われる。オンデマンド配信は、配信リクエストに応じてリアルタイムにメッセージを配信する処理である。
【0016】
また、配信サーバ１０は、企業サーバ２０に対応する企業からの依頼の内容に応じて、シナリオに沿った一連のメッセージを送信する。ここでのシナリオは、配信済みの１通目のメッセージの状況、或いはメッセージに対するユーザのアクション（応答）に応じて、２通目以降に配信するメッセージが設定された情報である。
【0017】
例えば、シナリオにて、１通目のメッセージとして、「マイページ」などに対応する特定のページへのリンクが示されたカルーセル（第１メッセージという）を配信するような設定がされたとする。
この場合、２通目のメッセージが配信済みの１通目のメッセージの状況に応じて配信される。具体的には、例えば、１通目のメッセージが通信端末４０に受信された場合に、「マイページの使い方について動画で詳しくご覧になりますか」などの案内文と共に、「はい」及び「いいえ」が示された操作ボタンを含むメッセージ（第２メッセージという）を配信するような設定がされる。
また、３通目のメッセージが、２通目のメッセージに対するユーザのアクション（応答）に応じて配信される。具体的には、例えば、第２メッセージに対して「はい」が示された操作ボタンが操作された場合、動画を含むメッセージが次のメッセージとして設定される。
一方、第２メッセージに対して「いいえ」が示された操作ボタンが操作された場合、上記の動画とは異なるコンテンツ、例えば、マイページに対応するＵＲＬを含むメッセージが、３通目のメッセージとしてシナリオに設定される。
この場合、２通目のメッセージが配信済みの１通目のメッセージの状況に応じて配信される。具体的には、例えば、１通目のメッセージが通信端末４０に受信された場合に、「マイページの使い方について動画で詳しくご覧になりますか」などの案内文と共に、「はい」及び「いいえ」が示された操作ボタンを含むメッセージ（第２メッセージという）を配信するような設定がされる。
また、３通目のメッセージが、２通目のメッセージに対するユーザのアクション（応答）に応じて配信される。具体的には、例えば、第２メッセージに対して「はい」が示された操作ボタンが操作された場合、動画を含むメッセージが次のメッセージとして設定される。
一方、第２メッセージに対して「いいえ」が示された操作ボタンが操作された場合、上記の動画とは異なるコンテンツ、例えば、マイページに対応するＵＲＬを含むメッセージが、３通目のメッセージとしてシナリオに設定される。
【0018】
企業サーバ２０は、企業によって管理される情報処理装置である。企業サーバ２０として、例えば、サーバ装置、ＰＣなどのコンピュータを適用することができる。企業サーバ２０に対応する企業として、任意の企業及び団体、例えば、銀行、保険会社、旅行代理店、公共団体等を適用することができる。企業サーバ２０は、配信サーバ１０との間で、無線通信又は有線通信をする。企業サーバ２０は、通信端末４０にメッセージを配信するように配信サーバ１０を管理する企業に依頼する。
【0019】
通信事業者サーバ３０は、通信事業者によって管理されるサーバ装置である。通信事業者は、例えば、自らが保有又は運用する通信回線を用いた、電話番号を利用した通信サービスを通信端末４０に対して提供するＭＮＯ（Mobile Network Operator、移動体通信事業者）である。
【0020】
ここでの通信サービスには、ＲＣＳを用いた通信が含まれる。ＲＣＳを用いた通信においては、通信事業者サーバ３０は、配信サーバ１０からの配信リクエストに応じて、ＲＣＳに対応したメッセージを通信端末４０に送信する。ＲＣＳに対応したメッセージを利用した通信サービスでは、通信端末４０に送信したＲＣＳメッセージに対するＷｅｂｈｏｏｋ（ウェブフック）情報が、通信事業者サーバ３０を介して配信サーバ１０に送信される。Ｗｅｂｈｏｏｋ情報は、通信端末４０に配信したＲＣＳメッセージのステータス、例えば、通信端末４０にＲＣＳメッセージが受信された等を示す情報を含む。また、Ｗｅｂｈｏｏｋ情報は、ＲＣＳメッセージにあるコンテンツ、例えば操作ボタン等、が操作された等の状態を含む。通信事業者サーバ３０は、配信サーバ１０及び通信端末４０との間で、無線通信又は有線通信をする。
【0021】
通信端末４０は、ユーザ等によって使用される情報処理装置である。通信端末４０として、例えば、スマートフォン、携帯電話、ＰＣなどのコンピュータを適用することができる。通信端末４０は、情報を表示する液晶ディスプレイ等の表示部と、ユーザによる操作を受け付けるタッチパネル等の操作部とを有する。通信端末４０は、企業サーバ２０からのメッセージを、配信サーバ１０及び通信事業者サーバ３０を介して受信する。
【0022】
通信端末４０は、ユーザ等によって通信事業者サーバ３０に対応する通信事業者と、通信端末４０を用いた通信サービスを利用するための契約がなされる。通信端末４０は、契約をしている通信事業者が提供する通信サービスを用いて通信をすることが可能である。通信端末４０には電話番号が割り当てられており、この電話番号を宛先とする通信、すなわちＲＣＳを用いた通信を行う機能を有する。
【0023】
図２は、実施形態に係る通信端末４０に表示されるメッセージの例を示す図である。図２に示すように、例えば、企業「Ｃｄｅ株式会社」から企業の顧客であるユーザの通信端末４０に、シナリオＳＲに沿った一連のメッセージが配信される。この図では、１通目のメッセージとしてシーンＳＮ１、２通目のメッセージとしてシーンＳＮ２、３通目のメッセージとしてシーンＳＮ３がシナリオＳＲに沿って配信された例が示されている。
【0024】
この場合、例えば、シナリオＳＲには、シーンＳＮ１を配信すること、シーンＳＮ１が通信端末４０に受信されたらシーンＳＮ２を配信すること、シーンＳＮ２が通信端末４０に受信されたらシーンＳＮ３を配信すること、が示されている。また、シーンＳＮ３に含まれる特定のコンテンツ（例えば、「はい」、「いいえ」と記載された操作ボタン）がタップ操作されたら、当該操作に応じたシーンに対応するメッセージを配信すること、が示されている。
【0025】
例えば、配信システム１では、以下のような手順で、上記のシナリオＳＲに沿った配信が行われる。
【0026】
配信サーバ１０は、シナリオＳＲに沿って、まず、シーンＳＮ１に対応するメッセージを通信端末４０に配信するように、通信事業者サーバ３０に対して配信リクエストを通知する。通信事業者サーバ３０は、配信リクエストに応じて、通信端末４０にシーンＳＮ１に対応するメッセージを配信する。通信事業者サーバ３０は、配信したメッセージが通信端末４０に受信された場合、メッセージが通信端末４０に受信されたことを示すＷｅｂｈｏｏｋ情報（到達情報）を配信サーバ１０に送信する。
【0027】
配信サーバ１０は、通信事業者サーバ３０から到達情報を受信すると、シナリオＳＲに沿って、次の、シーンＳＮ２に対応するメッセージを通信端末４０に配信するように、通信事業者サーバ３０に対して配信リクエストを通知する。通信事業者サーバ３０は、配信リクエストに応じて、通信端末４０にシーンＳＮ２に対応するメッセージを配信する。通信事業者サーバ３０は、配信したメッセージが通信端末４０に受信された場合、メッセージが通信端末４０に受信されたことを示すＷｅｂｈｏｏｋ情報（到達情報）を配信サーバ１０に送信する。
配信サーバ１０は、通信事業者サーバ３０から到達情報を受信すると、シナリオＳＲに沿って、次の、シーンＳＮ３に対応するメッセージを通信端末４０に配信するように、通信事業者サーバ３０に対して配信リクエストを通知する。通信事業者サーバ３０は、配信リクエストに応じて、通信端末４０にシーンＳＮ３に対応するメッセージを配信する。通信事業者サーバ３０は、配信したメッセージが通信端末４０に受信された場合、メッセージが通信端末４０に受信されたことを示すＷｅｂｈｏｏｋ情報（到達情報）を配信サーバ１０に送信する。
また、通信事業者サーバ３０は、シーンＳＮ３に対応するメッセージにある特定のコンテンツ（例えば、「はい」、「いいえ」などが示された操作ボタン）が操作された場合、特定のコンテンツが操作されたことを示すＷｅｂｈｏｏｋ情報（アクション情報）を配信サーバ１０に送信する。
配信サーバ１０は、通信事業者サーバ３０から到達情報を受信すると、シナリオＳＲに沿って、次の、シーンＳＮ３に対応するメッセージを通信端末４０に配信するように、通信事業者サーバ３０に対して配信リクエストを通知する。通信事業者サーバ３０は、配信リクエストに応じて、通信端末４０にシーンＳＮ３に対応するメッセージを配信する。通信事業者サーバ３０は、配信したメッセージが通信端末４０に受信された場合、メッセージが通信端末４０に受信されたことを示すＷｅｂｈｏｏｋ情報（到達情報）を配信サーバ１０に送信する。
また、通信事業者サーバ３０は、シーンＳＮ３に対応するメッセージにある特定のコンテンツ（例えば、「はい」、「いいえ」などが示された操作ボタン）が操作された場合、特定のコンテンツが操作されたことを示すＷｅｂｈｏｏｋ情報（アクション情報）を配信サーバ１０に送信する。
【0028】
配信サーバ１０は、通信事業者サーバ３０からアクション情報を受信すると、シナリオＳＲに沿って、次の、シーンＳＮ４に対応するメッセージを通信端末４０に配信するように、通信事業者サーバ３０に対して配信リクエストを通知する。通信事業者サーバ３０は、配信リクエストに応じて、通信端末４０にシーンＳＮ４に対応するメッセージを配信する。
【0029】
図１に戻り、配信サーバ１０は、例えば、配信情報記憶部１１と、配信メッセージ履歴情報記憶部１２と、標準配信キュー１３と、優先配信キュー１４と、振分処理部１５と、対応判定部１６と、配信処理部１７と、受付処理部１８とを備える。
【0030】
配信情報記憶部１１と、配信メッセージ履歴情報記憶部１２と、標準配信キュー１３と、優先配信キュー１４とは、例えば、配信サーバ１０が備える記憶部（不図示）に設けられる。配信サーバ１０が備える記憶部は、記憶媒体、例えば、ＨＤＤ（Hard Disk Drive）、フラッシュメモリ、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）、ＲＡＭ（Random Access read/write Memory）、ＲＯＭ（Read Only Memory）、または、これらの記憶媒体の任意の組み合わせによって構成される。配信サーバ１０が備える記憶部は、配信サーバ１０の各種の処理を実行するためのプログラム、及び各種の処理を行う際に利用される一時的なデータを記憶する。
【0031】
配信情報記憶部１１は、配信情報を記憶する。配信情報は、ユーザに配信する一連のメッセージに関する情報である。
【0032】
図３は、配信情報記憶部１１に記憶される情報の例を示す図である。図３に示すように、例えば、配信情報記憶部１１は、配信情報を記憶する。配信情報には、例えば、案件ＩＤと、配信パターンと、配信単位ＩＤと、個別管理番号と、元メッセージＩＤと、シナリオＩＤと、シーンＩＤなどの項目に対応する情報を含む。
なお、この図では、配信情報に、シナリオを特定するための情報（後述する配信パターン、シナリオＩＤ、シーンＩＤなど）と、メッセージの通知先であるユーザを特定するための情報（後述する配信単位ＩＤ、個別管理番号など）が共に含まれる例が示されているが、この例に限定されることはない。配信情報におけるシナリオを特定するための情報と、ユーザを特定するための情報とが別々の情報として記憶されるように構成されてもよい。
なお、この図では、配信情報に、シナリオを特定するための情報（後述する配信パターン、シナリオＩＤ、シーンＩＤなど）と、メッセージの通知先であるユーザを特定するための情報（後述する配信単位ＩＤ、個別管理番号など）が共に含まれる例が示されているが、この例に限定されることはない。配信情報におけるシナリオを特定するための情報と、ユーザを特定するための情報とが別々の情報として記憶されるように構成されてもよい。
【0033】
案件ＩＤは、依頼元となる企業サーバ２０に対応する企業のアカウント（得意先アカウント）に紐付けられた識別情報である。
【0034】
配信パターンは、対応判定を行った後に配信をするパターンか、対応判定を行わずに配信をするパターンかを示す情報である。ここでの対応判定は、配信先となる通信端末４０がＲＣＳに対応しているか否かを判定することである。対応判定の結果、配信先となる通信端末４０がＲＣＳに対応している場合、例えば、配信サーバ１０はＲＣＳに対応したメッセージを通信端末４０に配信するように配信リクエストを行う。一方、対応判定の結果、配信先となる通信端末４０がＲＣＳに対応していない場合、ＲＣＳでないメッセージサービス、例えばＳＭＳ（ショートメッセージサービス）に対応したメッセージを通信端末４０に配信するように配信リクエストを行う。
【0035】
配信単位ＩＤは、配信の処理単位ごと付与された識別情報である。ここでの配信単位は、例えば、バッチ処理によるバルク配信の単位である。例えば、１０時に１万件のメッセージをバルク配信するような場合に、そのバルク配信に対してユニークな配信単位ＩＤが付与される。
【0036】
個別管理番号は、配信するメッセージを個別に識別するための識別情報である。個別管理番号として、例えば、配信単位ＩＤに配信先の電話番号などの宛先情報等を加えることによって、配信する個々のメッセージに対してユニークな識別情報が付与される。
【0037】
シナリオＩＤは、シナリオを識別するための識別情報である。シナリオＩＤとして、例えば「６７３０…」などの数字や文字からなるユニークな情報がシナリオ毎に付与される。
【0038】
シーンＩＤは、シナリオに含まれるメッセージに対応するシーンを識別するための識別情報である。例えば、シナリオにおいて最初（１通目）に通知するメッセージに対応するシーンＩＤは「ｓｔａｒｔ」、次（２通目）に通知するメッセージに対応するシーンＩＤは「ｎｅｘｔ」、その次（３通目）に通知するメッセージに対応するシーンＩＤは「ｎｅｘｔ＿１」などに設定される。
【0039】
元メッセージＩＤは、メッセージを配信するように通信事業者サーバ３０に配信リクエストを通知した際に、通信事業者サーバ３０によって付与されるＩＤであって、通信事業者サーバ３０が配信するメッセージを識別するための識別情報である。メッセージＩＤは、例えば、Ｗｅｂｈｏｏｋ情報に含まれて、通信事業者サーバ３０から配信サーバ１０に通知される。
【0040】
配信メッセージ履歴情報記憶部１２は、配信メッセージ履歴情報を記憶する。配信メッセージ履歴情報は、ユーザに配信したメッセージの履歴、例えば、メッセージが受信された、特定のコンテンツが操作された等の履歴を示す情報である。
【0041】
図４は、配信メッセージ履歴情報記憶部１２に記憶される情報の例を示す図である。図４に示すように、例えば、配信メッセージ履歴情報記憶部１２は、到達情報と、アクション情報などの項目に対応する情報を記憶する。
【0042】
到達情報は、配信サーバ１０による配信リクエストに対して通信事業者サーバ３０から通知されるＷｅｂｈｏｏｋ情報であって、メッセージが通信端末４０に受信されたことを示す情報である。到達情報には、例えば、メッセージＩＤとステータスなどの項目に対応する情報が記憶される。メッセージＩＤは、メッセージの配信リクエストに対して通信事業者サーバ３０によって付与されたＩＤである。ステータスは、配信したメッセージの状況を示す情報であり、例えば、メッセージが通信端末４０に受信された場合、「到達」などを示す情報がステータスとして設定される。
【0043】
アクション情報は、配信サーバ１０による配信リクエストに対して通信事業者サーバ３０から通知されるＷｅｂｈｏｏｋ情報であって、メッセージにある特定のコンテンツが操作されたことを示す情報である。アクション情報には、例えば、メッセージＩＤとポストバックデータなどの項目に対応する情報が記憶される。メッセージＩＤは、メッセージの配信リクエストに対して通信事業者サーバ３０によって付与されたＩＤである。ポストバックデータは、コンテンツ毎に、当該コンテンツが操作された場合に通知されるように予め配信サーバ１０によって設定された情報である。例えば、ポストバックデータには、例えば、シナリオＩＤ、シーンＩＤ、及び、次メッセージのシーンＩＤなどの項目に対応する情報が記憶される。或いは、ポストバックデータとして、コンテンツに表示されている除法、例えば「はい」「いいえ」などを示す情報が設定されてもよい。ここでのシナリオＩＤ及びシーンＩＤは、操作されたコンテンツに対応するシナリオＩＤ及びシーンＩＤである。次メッセージのシーンＩＤは、シナリオにて当該コンテンツが操作された場合に次に送信するように設定されたメッセージに対応するシーンＩＤである。
【0044】
図１に戻り、標準配信キュー１３は、バルク配信により配信するメッセージの配信情報が格納されるキュー（待ち行列）である。
【0045】
例えば、標準配信キュー１３は、対応判定標準キュー１３０と、ＲＣＳ標準キュー１３１と、ＳＭＳ標準キュー１３２とを備える。対応判定標準キュー１３０には、バルク配信のうち配信パターンとして対応判定を行うパターンが設定されたメッセージの配信情報が格納される。ＲＣＳ標準キュー１３１には、対応判定の結果、ＲＣＳに対応していると判定された通信端末４０に通知するメッセージの配信情報が格納される。ＳＭＳ標準キュー１３２には、対応判定の結果、ＲＣＳに対応していないと判定された通信端末４０に通知するメッセージの配信情報、及び、バルク配信のうち配信パターンとして対応判定を行わないパターンが設定されたメッセージの配信情報が格納される。
【0046】
優先配信キュー１４は、オンデマンド配信により配信するメッセージ、および配信済みのメッセージの状況や配信済みのメッセージに対するユーザのアクション（応答）に応じて配信する２通目以降メッセージが格納されるキュー（待ち行列）である。
【0047】
例えば、優先配信キュー１４は、対応判定優先キュー１４０と、対応判定後ＲＣＳ優先キュー１４１と、対応判定後ＳＭＳ優先キュー１４２と、ＳＭＳ優先キュー１４３と、ＲＣＳ優先キュー１４４を備える。対応判定優先キュー１４０には、オンデマンド配信のうち配信パターンとして対応判定を行うパターンが設定されたメッセージの配信情報が格納される。対応判定後ＲＣＳ優先キュー１４１には、対応判定の結果、ＲＣＳに対応していると判定された通信端末４０に通知するメッセージの配信情報が格納される。対応判定後ＳＭＳ優先キュー１４２には、対応判定の結果、ＲＣＳに対応していないと判定された通信端末４０に通知するメッセージの配信情報が格納される。ＳＭＳ優先キュー１４３には、オンデマンド配信のうち配信パターンとして対応判定を行わないパターンが設定されたメッセージの配信情報が格納される。ＲＣＳ優先キュー１４４には、１通目のメッセージの状況に応じて配信する２通目以降のメッセージの配信情報が格納される。
【0048】
ここで、振分処理部１５と、対応判定部１６と、配信処理部１７と、受付処理部１８とは、信号処理を行う機能部である。機能部は、配信サーバ１０がハードウェアとして備えるＣＰＵ（Central Processing Unit）にプログラムを実行させることによって実現される。
【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】
図６には、バッチ処理のうち、特に、対応判定を行う配信パターンが設定されたメッセージを配信する処理の流れが示されている。
【0082】
図６に示すように、まず、振分処理部１５は、バルク配信を行うタイミングが到来する（ステップＳ１０１）と、配信情報記憶部１１を参照して当該タイミングにて配信するメッセージ群の配信情報を取得する（ステップＳ１０２）。振分処理部１５は、取得した配信情報のうち、対応判定を行うように配信パターンが設定されたメッセージの配信情報を、対応判定標準キュー１３０に格納する（ステップＳ１０３）。
【0083】
対応判定部１６は、対応判定標準キュー１３０に格納された配信情報を取得し（ステップＳ１０４）、取得した配信情報の全部又は一部を通信事業者サーバ３０に通知することによって対応判定を依頼する（ステップＳ１０５）。通信事業者サーバ３０の対応判定ＡＰＩ３２は、配信サーバ１０から依頼に応じて対応判定を行い、その結果を配信サーバ１０に送信する（ステップＳ１０６）。
【0084】
対応判定部１６は、通信事業者サーバ３０から配信サーバ１０に通知された対応判定の判定結果を取得する。対応判定部１６は、取得した結果に応じて、対応判定標準キュー１３０に格納された配信情報を、ＲＣＳ標準キュー１３１又はＳＭＳ標準キュー１３２の何れかに格納する（ステップＳ１０７Ａ、Ｓ１０７Ｂ）。具体的に、配信サーバ１０は、対応判定標準キュー１３０に格納された配信情報のうち、配信情報に対応するメッセージの配信先である通信端末４０がＲＣＳに対応しているものを、ＲＣＳ標準キュー１３１に格納する（ステップＳ１０７Ａ）。一方、配信サーバ１０は、対応判定標準キュー１３０に格納された配信情報のうち、配信情報に対応するメッセージの配信先である通信端末４０がＲＣＳに対応していないものを、ＳＭＳ標準キュー１３２に格納する（ステップＳ１０７Ｂ）。
【0085】
配信処理部１７は、ＲＣＳ標準キュー１３１及びＳＭＳ標準キュー１３２に格納された配信情報を取得（ステップＳ１０８Ａ、Ｓ１０８Ｂ）する。具体的に、配信処理部１７は、ＲＣＳ標準キュー１３１に格納された配信情報を取得（ステップＳ１０８Ａ）し、取得した配信情報に基づいて配信情報記憶部１１を参照（ステップＳ１０９）する。配信処理部１７は、配信情報の全部又は一部を通信事業者サーバ３０に通知することによって、配信情報に対応するメッセージの配信リクエストを行う（ステップＳ１１０）。
【0086】
また、配信処理部１７は、ＳＭＳ標準キュー１３２に格納された配信情報を取得（ステップＳ１０８Ｂ）し、取得した配信情報に基づいて配信情報記憶部１１を参照（ステップＳ１０９）することによって、配信するメッセージの内容及び配信先の電話番号等を含む配信リクエストを生成する。配信処理部１７は、配信リクエストを通信事業者サーバ３０に通知することによって、配信情報に対応するメッセージを配信するように要求する（ステップＳ１１０）。
【0087】
通信事業者サーバ３０の配信ＡＰＩ３１は、配信リクエストを受け付けると、受け付けたメッセージに対応するメッセージＩＤを発行し、発行したメッセージＩＤを配信サーバ１０に通知する（ステップＳ１１１）。配信サーバ１０の配信処理部１７は、通信事業者サーバ３０から受信したメッセージＩＤを、配信メッセージ履歴情報記憶部１２に記憶させる（ステップＳ１１２）。
【0088】
図７には、バッチ処理のうち、特に、対応判定を行わない配信パターンが設定されたメッセージを配信する処理の流れが示されている。
【0089】
図７に示すように、まず、振分処理部１５は、バルク配信を行うタイミングが到来する（ステップＳ２０１）と、配信情報記憶部１１を参照して当該タイミングにて配信するメッセージ群の配信情報を取得する（ステップＳ２０２）。振分処理部１５は、取得した配信情報のうち、対応判定を行わない配信パターンが設定されたメッセージの配信情報を、ＳＭＳ標準キュー１３２に格納する（ステップＳ２０３）。
【0090】
配信処理部１７は、ＳＭＳ標準キュー１３２に格納された配信情報を取得（ステップＳ２０４）し、取得した配信情報に基づいて配信情報記憶部１１を参照（ステップＳ２０５）することによって配信リクエストを生成する。配信処理部１７は、配信リクエストを通信事業者サーバ３０に通知することによって、配信情報に対応するメッセージを配信するように要求する（ステップＳ２０６）。配信ＡＰＩ３１は、配信リクエストを受け付けると、受け付けたメッセージに対応するメッセージＩＤを発行し、発行したメッセージＩＤを配信サーバ１０に通知する（ステップＳ２０７）。配信処理部１７は、通信事業者サーバ３０から受信したメッセージＩＤを、配信メッセージ履歴情報記憶部１２に記憶させる（ステップＳ２０８）。
【0091】
図８には、オンデマンド処理のうち、特に、対応判定を行う配信パターンが設定されたメッセージを配信する処理の流れが示されている。
【0092】
図８に示すように、まず、振分処理部１５は、オンデマンド配信を行うように要求するオンデマンドリクエストを受信する（ステップＳ３０１）と、配信情報記憶部１１を参照してオンデマンドリクエストされたメッセージに対応する配信情報を取得する（ステップＳ３０２）。振分処理部１５は、取得した配信情報に対応するメッセージが、対応判定を行うように配信パターンが設定されたメッセージであれば、その配信情報を、対応判定優先キュー１４０に格納する（ステップＳ３０３）。
【0093】
対応判定部１６は、対応判定優先キュー１４０に格納された配信情報を取得し（ステップＳ３０４）、取得した配信情報の全部又は一部を通信事業者サーバ３０に通知することによって対応判定を依頼する（ステップＳ３０５）。通信事業者サーバ３０の対応判定ＡＰＩ３２は、配信サーバ１０から依頼に応じて対応判定を行い、その結果を配信サーバ１０に送信する（ステップＳ３０６）。
【0094】
対応判定部１６は、通信事業者サーバ３０から配信サーバ１０に通知された対応判定の判定結果を取得する。対応判定部１６は、取得した結果に応じて、対応判定優先キュー１４０に格納された配信情報を、対応判定後ＲＣＳ優先キュー１４１又は対応判定後ＳＭＳ優先キュー１４２の何れかに格納する（ステップＳ３０７Ａ、Ｓ３０７Ｂ）。具体的に、配信サーバ１０は、対応判定優先キュー１４０に格納された配信情報のうち、配信情報に対応するメッセージの配信先である通信端末４０がＲＣＳに対応しているものを、対応判定後ＲＣＳ優先キュー１４１に格納する（ステップＳ３０７Ａ）。一方、配信サーバ１０は、対応判定優先キュー１４０に格納された配信情報のうち、配信情報に対応するメッセージの配信先である通信端末４０がＲＣＳに対応していないものを、対応判定後ＳＭＳ優先キュー１４２に格納する（ステップＳ３０７Ｂ）。
【0095】
配信処理部１７は、対応判定後ＲＣＳ優先キュー１４１及び対応判定後ＳＭＳ優先キュー１４２に格納された配信情報を取得（ステップＳ３０８Ａ、Ｓ３０８Ｂ）する。具体的に、配信処理部１７は、対応判定後ＲＣＳ優先キュー１４１に格納された配信情報を取得し、取得した配信情報に基づいて配信情報記憶部１１を参照（ステップＳ３０９）することによって、配信するメッセージの内容及び配信先の電話番号等を含む配信リクエストを生成する。配信処理部１７は、配信情報の全部又は一部を通信事業者サーバ３０に通知することによって、配信情報に対応するメッセージの配信リクエストを行う（ステップＳ３１０）。
【0096】
また、配信処理部１７は、対応判定後ＳＭＳ優先キュー１４２に格納された配信情報を取得（ステップＳ３０８Ｂ）し、取得した配信情報に基づいて配信情報記憶部１１を参照（ステップＳ３０９）することによって、配信するメッセージの内容及び配信先の電話番号等を含む配信リクエストを生成する。配信処理部１７は、配信リクエストを通信事業者サーバ３０に通知することによって、配信情報に対応するメッセージを配信するように要求する（ステップＳ３１０）。
【0097】
通信事業者サーバ３０の配信ＡＰＩ３１は、配信リクエストを受け付けると、受け付けたメッセージに対応するメッセージＩＤを発行し、発行したメッセージＩＤを配信サーバ１０に通知する（ステップＳ３１１）。配信サーバ１０の配信処理部１７は、通信事業者サーバ３０から受信したメッセージＩＤを、配信メッセージ履歴情報記憶部１２に記憶させる（ステップＳ３１２）。
【0098】
図９には、オンデマンド処理のうち、特に、対応判定を行わない配信パターンが設定されたメッセージを配信する処理の流れが示されている。
【0099】
図９に示すように、まず、振分処理部１５は、オンデマンドリクエストを受信（ステップＳ４０１）と、配信情報記憶部１１を参照してオンデマンドリクエストされたメッセージに対応する配信情報を取得する（ステップＳ４０２）。振分処理部１５は、取得した配信情報に対応するメッセージが、対応判定を行わない配信パターンが設定されたメッセージであれば、その配信情報を、ＳＭＳ優先キュー１４３に格納する（ステップＳ４０３）。
【0100】
配信処理部１７は、ＳＭＳ優先キュー１４３に格納された配信情報を取得（ステップＳ４０４）し、取得した配信情報に基づいて配信情報記憶部１１を参照（ステップＳ４０５）することによって配信リクエストを生成する。配信処理部１７は、配信リクエストを通信事業者サーバ３０に通知することによって、配信情報に対応するメッセージを配信するように要求する（ステップＳ４０６）。配信ＡＰＩ３１は、配信リクエストを受け付けると、受け付けたメッセージに対応するメッセージＩＤを発行し、発行したメッセージＩＤを配信サーバ１０に通知する（ステップＳ４０７）。配信処理部１７は、通信事業者サーバ３０から受信したメッセージＩＤを、配信メッセージ履歴情報記憶部１２に記憶させる（ステップＳ４０８）。
【0101】
図１０には、配信したメッセージに対する応答が受信された場合において、２通目以降のメッセージを配信する処理の流れが示されている。
【0102】
図１０に示すように、通信事業者サーバ３０は、配信したメッセージに対し通信端末４０のユーザ等による操作が行われると、操作が行われた旨の制御情報を通信端末４０から受信する（ステップＳ５０１Ａ、Ｓ５０１Ｂ）。具体的に、通信端末４０に配信したメッセージ（「マイページログイン」等とのタイトルが示されたカルーセル）が受信されると、受付ＡＰＩ３３は、メッセージが受信されたことを示す制御情報を受信する（ステップＳ５０１Ａ）。また、通信端末４０に配信したメッセージに含まれる特定のコンテンツの操作ボタン（「はい」、「いいえ」等が示された操作ボタン）がタップ操作されると、受付ＡＰＩ３３は、当該コンテンツの操作ボタンが操作されたことを示す制御情報を受信する（ステップＳ５０１Ｂ）。
【0103】
受付ＡＰＩ３３は、通信端末４０から受信した制御情報に基づいてＷｅｂｈｏｏｋ情報を生成し、生成したＷｅｂｈｏｏｋ情報を配信サーバ１０に送信する（ステップＳ５０２）。具体的に、受付ＡＰＩ３３は、メッセージが受信された場合、ステップＳ５０１Ａにて受信した制御情報に基づくＷｅｂｈｏｏｋ情報（到達情報）を配信サーバ１０に送信する。一方、受付ＡＰＩ３３は、コンテンツが操作された場合、ステップＳ５０１Ｂにて受信した制御情報に基づくＷｅｂｈｏｏｋ情報（アクション情報）を配信サーバ１０に送信する。
【0104】
配信サーバ１０の受付処理部１８は、通信事業者サーバ３０から受信したＷｅｂｈｏｏｋ情報を取得すると、Ｗｅｂｈｏｏｋ情報で通知された内容に応じて配信するメッセージ（２通目以降のメッセージ）を生成する（ステップＳ５０３）。具体的に、受付処理部１８は、取得したＷｅｂｈｏｏｋ情報に対応するメッセージを特定し、特定したメッセージに対応する配信メッセージ履歴情報を配信メッセージ履歴情報記憶部１２から抽出する。また、受付処理部１８は、Ｗｅｂｈｏｏｋ情報にあるポストバックデータを参照し、操作に応じて２通目以降のメッセージを配信するか否かを判定する。受付処理部１８は、２通目以降のメッセージを配信する場合、ポストバックデータに基づいて配信情報記憶部１１を参照し、対応する配信情報を抽出する。受付処理部１８は、抽出した配信情報のシーンＩＤをインクリメントすることによって、２通目以降に配信するメッセージを設定する。なお、２通目以降に配信するメッセージを特定するアルゴリズムは任意に決定されてよい。例えば、シーンＩＤにおいて特定の位置、例えば先頭や特定記号の後等に示された数値、例えば、０１－ＸＸＸ、０２－ＸＸＸにおける「０１」、「０２」などの数値に基づいて、「０１」の次は「０２」を自動選択する等のアルゴリズムによって２通目以降に配信するメッセージを設定するようにしてもよい。
【0105】
受付処理部１８は、２通目以降に配信するメッセージに対応する配信情報を、ＲＣＳ優先キュー１４４に格納する（ステップＳ５０４）。
【0106】
配信処理部１７は、ＲＣＳ優先キュー１４４に格納された配信情報を取得（ステップＳ５０５）し、取得した配信情報に基づいて、配信情報記憶部１１及び配信メッセージ履歴情報記憶部１２を参照する（ステップＳ５０６）ことによって、配信するメッセージの内容及び配信先の電話番号等を含む配信リクエストを生成する。配信処理部１７は、配信リクエストを通信事業者サーバ３０に通知することによって、配信情報に対応するメッセージを配信するように要求する（ステップＳ５０７）。配信ＡＰＩ３１は、配信リクエストを受け付けると、受け付けたメッセージを通信端末４０に配信する（ステップＳ５０８）。
【0107】
ここで、図１１及び図１２を用いて、２通目以降のメッセージを配信する場合における配信情報についての例を示す図である。図１１及び図１２は、実施形態に係る配信情報記憶部１１に記憶される情報の例を示す図である。
【0108】
図１１には、図１０のステップＳ５０１Ａに示すような、メッセージが受信された場合に通知されるＷｅｂｈｏｏｋ情報（到達情報）に基づいて、当該到達情報に対応するメッセージの受信に応じて配信する２通目以降のメッセージに対応する配信情報の例が示されている。
【0109】
図１１に示すように、例えば、２通目以降のメッセージに対応する配信情報には、元メッセージＩＤとして、Ｗｅｂｈｏｏｋ情報にて通知されたメッセージＩＤが設定される。シナリオＩＤには、２通目以降に配信するメッセージに対応するシナリオのシナリオＩＤが設定される。シーンＩＤには、２通目以降に配信するメッセージのシーンＩＤに対応する「ｎｅｘｔ＿ｋ」（ｋは１以上の整数）が設定される。
【0110】
図１２には、図１０のステップＳ５０１Ｂに示すような、特定のコンテンツに含まれる操作ボタン（ここでは、「はい」が示された操作ボタン）対する操作が行われた場合に通知されるＷｅｂｈｏｏｋ情報（アクション情報）に基づいて、当該アクション情報に対応する操作に応じて配信する２通目以降のメッセージに対応する配信情報の例が示されている。
【0111】
図１２に示すように、例えば、２通目以降のメッセージに対応する配信情報には、元メッセージＩＤとして、Ｗｅｂｈｏｏｋ情報にて通知されたメッセージＩＤが設定される。シナリオＩＤには、２通目以降に配信するメッセージに対応するシナリオのシナリオＩＤが設定される。シーンＩＤには、２通目以降に配信するメッセージのシーンＩＤに対応する「ｙｅｓ」が設定される。このシーンＩＤは、「はい」が示された操作ボタンが操作された場合に配信するメッセージの識別情報を示している。
【0112】
なお、上記では、配信情報をキュー（標準配信キュー１３又は優先配信キュー１４）に格納する場合を例示して説明したがこれに限定されることはない。少なくともユーザに通知するメッセージに対応するシナリオが特定可能な情報がキューに格納されていればよい。例えば、配信情報そのものではなく、配信情報を識別するためのキー情報をキューに格納するようにしてもよい。
【0113】
以上説明した通り、実施形態の配信サーバ１０は、振分処理部１５と、配信処理部１７と、受付処理部１８とを備える。振分処理部１５は、バッチ処理により配信するメッセージに関する配信情報（第１配信情報）を標準配信キュー１３に格納する。振分処理部１５は、配信リクエストに応じてオンデマンド配信するメッセージに関する配信情報（第２配信情報）を優先配信キュー１４（標準配信キュー１３とは異なるキュー）に格納する。配信処理部１７は、優先配信キュー１４に第２配信情報が格納されているか否かを判定し、優先配信キュー１４に第２配信情報が格納されている場合、その第２配信情報に対応するメッセージを配信するための処理を実行する。配信処理部１７は、優先配信キュー１４に第２配信情報が格納されていない場合に、標準配信キュー１３に格納された第１配信情報に対応するメッセージを配信するための処理を実行する。受付処理部１８は、２通目以降のメッセージに関する配信情報（第３配信情報）を生成する。２通目以降のメッセージは、配信処理部１７によって配信された配信済メッセージの状況を示す状況情報に基づいて、その状況に応じて配信するメッセージである。受付処理部１８は、配信済メッセージが、バッチ処理により配信されたメッセージであるか、オンデマンド配信されたメッセージであるかに関わらず、２通目以降のメッセージに対応する第３配信情報を優先配信キュー１４に格納する。
【0114】
これにより、本実施形態の配信サーバ１０では、オンデマンド配信するメッセージを、バッチ処理により配信するメッセージとのは異なる優先配信キューに格納すること、及びオンデマンド配信するメッセージがキューに格納されていない場合にバッチ処理により配信するメッセージを配信することができる。したがって、バッチ処理により配信するメッセージが大量にキューに格納されている場合であっても、オンデマンド配信するメッセージを遅延させることなく配信することが可能となる。しかも、２通目以降のメッセージを配信する場合においては、１通目のメッセージがバッチ処理により配信されたメッセージであるか、オンデマンド配信されたメッセージであるかに関わらず、優先配信キューに格納することができる。このため、配信済みのメッセージの状況に応じて配信するメッセージを、バッチ処理により配信するメッセージが大量にキューに格納されている場合であっても遅延なく配信することが可能となる。したがって、バッチ処理による大量の配信情報が配信キューに格納された場合であっても、オンデマンド配信及びメッセージの状況に応じて配信する通目以降のメッセージを遅延なく配信することができる。これにより、１通目を受信した後、２通目以降のメッセージを待っているユーザ、或いは、受信したメッセージにある操作ボタンなどを操作して次のメッセージを待っているユーザの期待に応えることができる。
【0115】
また、実施形態の配信サーバ１０は、通信事業者サーバ３０を介して、ＲＣＳ（Rich Communication Services）を利用したメッセージを配信する。配信処理部１７は、通信事業者サーバ３０を介してメッセージを配信する。受付処理部１８は、配信済メッセージが通信端末４０（配信先）に受信されたことに伴って通信事業者サーバ３０から通知されるＷｅｂｈｏｏｋ情報を、状況情報として取得する。受付処理部１８は、取得したＷｅｂｈｏｏｋ情報に基づいて、２通目以降のメッセージに対応する配信情報（第３配信情報）を生成する。これにより、実施形態の配信サーバ１０は、ＲＣＳを利用したメッセージを配信すること、及びＷｅｂｈｏｏｋ情報を用いてメッセージが受信されたか否かを把握することが可能となる。したがって、メッセージが受信されたことに応じて、次のメッセージを配信することができる。
【0116】
また、実施形態の配信サーバ１０は、通信事業者サーバ３０を介して、ＲＣＳ（Rich Communication Services）を利用したメッセージを配信する。配信処理部１７は、メッセージに含まれるコンテンツ（例えば、「はい」又は「いいえ」を示す操作ボタン）に、そのコンテンツが操作されたことに対応して送信する次メッセージを示す情報を含むポストバックデータを設定する。配信処理部１７は、コンテンツに次メッセージを含むポストバックデータを設定したメッセージを、通信事業者サーバ３０を介して配信する。受付処理部１８は、コンテンツが操作されたことに伴って通信事業者サーバ３０から通知されるＷｅｂｈｏｏｋ情報を、状況情報として取得する。受付処理部１８は、取得したＷｅｂｈｏｏｋ情報に含まれるポストバックデータに示された次メッセージを示す情報に基づいて、２通目以降のメッセージに対応する配信情報（第３配信情報）を生成する。これにより、実施形態の配信サーバ１０では、ＲＣＳを利用したメッセージを配信すること、及びＷｅｂｈｏｏｋ情報を用いてコンテンツが操作されたか否かを把握することが可能となる。したがって、コンテンツが操作されたことに応じて、次のメッセージを配信することができる。
【0117】
また、実施形態の配信サーバ１０は、対応判定部１６を更に備える。対応判定部１６は、通信端末４０（メッセージの配信先）がＲＣＳに対応しているか否かを判定するための処理を行う。配信処理部１７は、対応判定部１６が行った処理の結果に応じて、通信端末４０がＲＣＳに対応していると判定された場合に、ＲＣＳを利用したメッセージを配信するための処理を行う。これにより、実施形態の配信サーバ１０では、メッセージを配信する前に、配信先である通信端末４０がＲＣＳに対応しているか否かを判定することができる。したがって、ＲＣＳに対応している通信端末４０にＲＣＳを利用したメッセージを配信し、ＲＣＳに対応していない通信端末４０にＲＣＳを利用したメッセージを配信しないようにすることができる。
【0118】
上述した実施形態における配信システム１、及び配信サーバ１０の全部又は一部をコンピュータで実現するようにしてもよい。その場合、この機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよく、ＦＰＧＡ（Field Programmable Gate Array）等のプログラマブルロジックデバイスを用いて実現されるものであってもよい。
【0119】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【符号の説明】
【0120】
１…配信システム、１０…配信サーバ、１１…配信情報記憶部、１２…配信メッセージ履歴情報記憶部、１３…標準配信キュー、１４…優先配信キュー、１５…振分処理部、１６…対応判定部、１７…配信処理部、１８…受付処理部、３０…通信事業者サーバ、４０…通信端末
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】