JP2024084228A - メッセージ配信装置、メッセージ配信方法、及び、メッセージ配信プログラム - Google Patents

Abstract

【課題】メッセージの配信依頼を受けて通信キャリアにメッセージの配信をなるべく遅滞することがないよう依頼するメッセージ配信装置、方法及びプログラムを提供する。【解決手段】通信システムにおいて、メッセージ配信装置１００は、第一顧客から配信の対象となるメッセージを受け付ける受付部、メッセージの配信を実行する１以上の通信キャリアを特定する配信キャリア特定部、特定した通信キャリアへ配信を要求する第二の顧客を特定する配信先特定部、特定した通信キャリアに対してメッセージの第二顧客への配信を要求する第１要求部及び配信が完了していない未完了タスクのうち、特定した通信キャリア毎の配信要求数の個数が所定閾値を超える場合に、受け付られた新たなメッセージのうち、所定閾値を超えた通信キャリアへの配信要求を、他のアグリゲーターサービス事業者のメッセージ配信装置を介して、第二顧客への配信を要求する第２要求部を備える。【選択図】図２

Description

本発明は、多数のメッセージの配信を依頼された場合のメッセージ配信を行うメッセージ配信装置、及びそのメッセージ配信方法、メッセージ配信プログラムに関する。

近年、ＳＭＳ等のメッセージサービスを利用したマーケティング等を目的としたメッセージを多数の顧客に配信するためのメッセージ配信サービスがある。特許文献１には、そのような技術の一例が示されている。

特開２０１５－１２６０２号公報

ところで、このようなメッセージの配信はなるべく遅延が発生することなく実行されることが好ましい。しかし、多数の異なるメッセージの配信依頼を受けた場合には、配信の遅延が発生する可能性がある。

そこで、本発明は上記問題に鑑みてなされたものであり、多数のメッセージの配信を依頼されたとしても、なるべく、配信の遅延が発生しないようにメッセージを配信することができるメッセージ配信装置、メッセージ配信方法、および、メッセージ配信プログラムを提供することを目的とする。

上記課題を解決するために、本発明の一態様に係るメッセージ配信装置は、第一の顧客から配信の対象となるメッセージを受け付ける受付部と、メッセージの配信を実行する１以上の通信キャリアを複数の通信キャリアの中から特定する配信キャリア特定部と、配信キャリア特定部で特定された通信キャリアへ配信を要求する第二の顧客を特定する配信先特定部と、配信キャリア特定部で特定された通信キャリアに対してメッセージの第二の顧客への配信を要求する第１要求部と、一つのメッセージについての配信状況を一つのタスクとして管理する管理部と、各タスクについて配信が完了していない未完了タスクのうち、特定された通信キャリアごとの配信要求数の個数が所定閾値を超えるか否かを判定する判定部と、未完了タスクのうち、特定された通信キャリアごとの配信要求数の個数が所定閾値を超える場合に、受付部が受け付けた新たなメッセージの配信のうち、少なくとも所定閾値を超えた通信キャリアへの配信要求は、他のアグリゲーターサービス事業者のメッセージ配信装置を介して第二の顧客へのメッセージの配信を要求する第２要求部と、を備える。

上記メッセージ配信装置において、管理部は、第２要求部が他のアグリゲーターサービス事業者のメッセージ配信装置に依頼した配信についても一つのタスクとして管理することとしてもよい。

上記メッセージ配信装置において、管理部は、一つの配信の対象となるメッセージについて第１要求部が要求した通信キャリア全てからの第二の顧客に対する配信状況を管理するとともに、第２要求部が要求した他のアグリゲーターサービス事業者からの第二の顧客に対する配信状況を管理することとしてもよい。

上記メッセージ配信装置において、管理部は、第１要求部が要求した一つのタスクとしての配信の要求先である通信キャリア全てから配信完了の報告を受けている場合に当該一つのタスクが完了したものとして管理し、第２要求部が要求した一つのタスクとしての配信の要求先である他のアグリゲーターサービス事業者から配信完了の報告を受けている場合に当該一つのタスクが完了したものとして管理することとしてもよい。

また、本発明の一態様に係るメッセージ配信方法は、コンピュータが、第一の顧客から配信の対象となるメッセージを受け付ける受付ステップと、メッセージの配信を実行する１以上の通信キャリアを複数の通信キャリアの中から特定する配信キャリア特定ステップと、配信キャリア特定ステップで特定された通信キャリアへ配信を要求する第二の顧客を特定する配信先特定ステップと、配信キャリア特定ステップで特定された通信キャリアに対してメッセージの第二の顧客への配信を要求する第１要求ステップと、一つのメッセージについての配信状況を一つのタスクとして管理する管理ステップと、各タスクについて配信が完了していない未完了タスクのうち、特定された通信キャリアごとの配信要求数の個数が所定閾値を超えるか否かを判定する判定ステップと、未完了タスクのうち、特定された通信キャリアごとの配信要求数の個数が所定閾値を超える場合に、受付ステップが受け付けた新たなメッセージの配信のうち、少なくとも所定閾値を超えた通信キャリアへの配信要求は、他のアグリゲーターサービス事業者のメッセージ配信装置を介して第二の顧客へのメッセージの配信を要求する第２要求ステップと、を実行する。

また、本発明の一態様に係るメッセージ配信プログラムは、コンピュータに、第一の顧客から配信の対象となるメッセージを受け付ける受付機能と、メッセージの配信を実行する１以上の通信キャリアを複数の通信キャリアの中から特定する配信キャリア特定機能と、配信キャリア特定機能で特定された通信キャリアへ配信を要求する第二の顧客を特定する配信先特定機能と、配信キャリア特定機能で特定された通信キャリアに対してメッセージの第二の顧客への配信を要求する第１要求機能と、一つのメッセージについての配信状況を一つのタスクとして管理する管理機能と、各タスクについて配信が完了していない未完了タスクのうち、特定された通信キャリアごとの配信要求数の個数が所定閾値を超えるか否かを判定する判定機能と、未完了タスクのうち、特定された通信キャリアごとの配信要求数の個数が所定閾値を超える場合に、受付機能が受け付けた新たなメッセージの配信のうち、少なくとも所定閾値を超えた通信キャリアへの配信要求は、他のアグリゲーターサービス事業者のメッセージ配信装置を介して第二の顧客へのメッセージの配信を要求する第２要求機能と、を実現させる。

本発明の一態様に係るメッセージ配信装置は、メッセージの配信を依頼された場合に、その依頼元から依頼されている配信依頼について、未完了の件数が所定件数を超える場合に他のアグリゲーターサービス事業者のメッセージ配信装置に配信を依頼することで、メッセージが第二の顧客に到達するまでの間で遅延がなるべく発生しないようにすることができる。

通信システムの構成例を示すシステム図である。 メッセージ配信装置の構成例を示すブロック図である。 タスク管理情報のデータ構成例を示すデータ概念図である。 通信システムにおける各アカウントの情報を示すユーザ情報のデータ構成例を示すデータ概念図である。 通信システムにおける各装置間のやり取りの例を示すシーケンス図である。 メッセージ配信装置の動作例を示すフローチャートである。

以下、本発明の一実施態様に係るメッセージ配信装置について、図面を参照しながら詳細に説明する。

＜実施の形態＞
図１は、実施の形態に係るメッセージ配信システムのシステム構成例を示すシステム図である。図１に示すメッセージ配信システムは、メッセージの配信を依頼する配信者端末２００（２００ａ、２００ｂ、２００ｃ。本実施形態において特に区別する必要がない場合には、配信者端末２００と記載する。）からの依頼を受けて、各通信キャリア３００（３００ａ、３００ｂ、３００ｃ、３００ｄ。本実施形態において特に区別する必要がない場合には、通信キャリア３００と記載する。）に対して、当該依頼に基づくメッセージの配信を指定の配信先である情報処理端末４００（４００ａ、４００ｂ、４００ｃ、４００ｄ、４００ｅ。本実施形態において特に区別する必要がない場合には、情報処理端末４００と記載する。）への配信の依頼を振り分けるメッセージ配信装置１００を含む。メッセージは、顧客（配信者端末２００）が自身の顧客や他のユーザに対して伝達したい事項を含む情報であればよく、文字や画像、音声、動画を含んでもよく、一例として、顧客の広告情報などであってよい。メッセージは、ＳＭＳ（Short Message Service）によるメッセージであってよいが、これに限定するものではない。メッセージは、例えば、文字数が制限されていないメッセージや、メール、チャットサービスによるメッセージ等も含まれてよく、これ以外の形態のメッセージも含まれてよい。メッセージ配信装置１００は、各通信キャリア３００に対して、当該通信キャリア３００から情報処理端末４００への配信がなるべく遅滞なく配信されるよう配信を依頼する。ここで、通信キャリア３００は、所謂電気通信事業者のことであり、固定電話や携帯電話等の電気通信サービスを提供する事業者のことであってよい。メッセージ配信装置１００は、顧客（配信者端末２００）から多数のメッセージの配信を依頼された場合に、他のメッセージ配信装置である配信代行装置５００に対して、配信者端末２００から依頼されたメッセージの配信依頼の実行を依頼する。ここで配信代行装置５００は、実質的には、メッセージ配信装置１００と同等の機能を有する装置であるが、メッセージ配信装置１００と区別するべく配信代行装置５００と呼称する。配信代行装置５００は、メッセージ配信装置１００を運用する運用体（企業等）とは異なる運用体（企業等）により運用される装置であってよい。メッセージ配信装置１００及び配信代行装置５００は、メッセージの配信依頼を受けて通信キャリアを介して多数の情報処理端末４００に対して配信を依頼する配信業者であるアグリゲーターサービス事業者の端末であってよい。配信代行装置５００は、メッセージの配信の依頼をメッセージ配信装置１００から受け付けると、メッセージ配信装置１００と同様に、各通信キャリア３００に対して、メッセージの配信依頼を振り分ける。このようにすることで、メッセージ配信装置１００は、多数のメッセージ配信依頼を受け付けて、メッセージ配信装置１００の処理能力内で処理しきれずに配信に遅延が発生すると想定されるような場合には、同様の機能を有する他のメッセージ配信装置（他のアグリゲーターサービス事業者のメッセージ配信装置）、即ち、配信代行装置５００に受けた配信依頼の代行を依頼することで、メッセージの配信遅延を抑制する。メッセージ配信装置１００や配信代行装置５００に対して単位時間当たりに各通信キャリアに対してメッセージの配信を依頼できるメッセージ数（あるいは、メッセージ量）の上限が定められているところ、配信依頼が多くなるとメッセージの配信の遅延が発生する可能性があるものの、メッセージ配信装置１００は、それを他のアグリゲーターサービス事業者のメッセージ配信装置である配信代行装置５００に依頼することで、当該可能性を回避することができる。

以下、本実施の形態においては、上述のようなメッセージ配信を実現するメッセージ配信装置１００について詳細に説明する。

なお、図１に示す各装置間の通信を行うための通信ネットワークは、各種の機器との間を相互に接続させるためのネットワークであり、例えば、無線ネットワークや有線ネットワークである。具体的には、ネットワークは、ワイヤレスＬＡＮ（ｗｉｒｅｌｅｓｓ ＬＡＮ：ＷＬＡＮ）や広域ネットワーク（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ：ＷＡＮ）、ＩＳＤＮｓ（ｉｎｔｅｇｒａｔｅｄ ｓｅｒｖｉｃｅ ｄｉｇｉｔａｌ ｎｅｔｗｏｒｋｓ）、無線ＬＡＮｓ、ＬＴＥ（ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ）、ＬＴＥ－Ａｄｖａｎｃｅｄ、第４世代（４Ｇ）、第５世代（５Ｇ）、第６世代（６Ｇ）、ＣＤＭＡ（ｃｏｄｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）、ＷＣＤＭＡ（登録商標）、イーサネット（登録商標）などである。また、ネットワークは、これらの例に限られず、例えば、公衆交換電話網（Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ：ＰＳＴＮ）やブルートゥース（Ｂｌｕｅｔｏｏｔｈ（登録商標））、ブルートゥースローエナジー（Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ）、光回線、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）回線、衛星通信網などであってもよく、どのようなネットワークであってもよい。ネットワークは、ユーザの住居に備えられる場合には、ホームネットワークと呼称されることもある。また、ネットワークは、例えば、ＮＢ－ＩｏＴ（Ｎａｒｒｏｗ Ｂａｎｄ ＩｏＴ）や、ｅＭＴＣ（ｅｎｈａｎｃｅｄ Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）であってもよい。なお、ＮＢ－ＩｏＴやｅＭＴＣは、ＩｏＴ向けの無線通信方式であり、低コスト、低消費電力で長距離通信が可能なネットワークである。また、ネットワークは、これらの組み合わせであってもよい。また、ネットワークは、これらの例を組み合わせた複数の異なるネットワークを含むものであってもよい。例えば、ネットワークは、ＬＴＥによる無線ネットワークと、閉域網であるイントラネットなどの有線ネットワークとを含むものであってもよい。

＜メッセージ配信装置１００の構成例＞
図２は、メッセージ配信装置１００の構成例を示すブロック図である。

メッセージ配信装置１００は、配信者端末２００からのメッセージを情報処理端末４００に送信するために各通信キャリアに配信を依頼する（振り分ける）サーバ装置である。メッセージ配信装置１００は、サーバ装置、ＰＣ、ノートＰＣ、タブレット端末などにより実現されるコンピュータシステムであるが、これらに限定するものではない。

図２に示すように、メッセージ配信装置１００は、通信部１１０と、入力部１２０と、制御部１３０と、記憶部１４０と、出力部１５０と、を備える。通信部１１０と、入力部１２０と、制御部１３０と、記憶部１４０と、出力部１５０とは、接続線１６０を介して互いに通信可能に構成されてよい。

通信部１１０は、他の装置と通信を実行するための機能を有する通信インターフェースである。通信部１１０は、他の装置と通信可能であれば、いずれの通信プロトコルにより通信を行ってもよく、有線、無線のいずれでの通信であってよい。通信部１１０は制御部１３０からの指示にしたがって、配信者端末２００や、通信キャリア３００との通信を行う。通信部１１０は、例えば、配信者端末２００からの配信依頼を受信して、制御部１３０に伝達する。また、通信部１１０は、例えば、通信キャリア３００からの依頼された配信を完了したことを示す完了情報を受信して、制御部１３０に伝達する。また、通信部１１０は、例えば、制御部１３０からの指示にしたがって、通信キャリア３００に、配信を依頼したい内容を含む配信依頼を送信する。また、通信部１１０は、例えば、制御部１３０からの指示にしたがって、配信代行装置５００に対して、配信者端末２００から依頼された配信依頼の代行を依頼する。

入力部１２０は、メッセージ配信装置１００のオペレータ等からの入力を受け付けて、制御部１３０に伝達する機能を有する入力インターフェースである。入力部１２０は、タッチパネル等のソフトキーにより実現されてもよいし、ハードキーにより実現されてもよい。また、あるいは、入力部１２０は、音声入力を受け付けるためのマイクであってもよい。

記憶部１４０は、メッセージ配信装置１００が動作上必要とする各種のプログラム及びデータを記憶する機能を有する。記憶部１４０は、例えば、ＨＤＤ（Hard Disc Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等により実現することができる。記憶部１４０は、各配信者端末２００から依頼された配信依頼についての配信を通信キャリア３００あるいは配信代行装置５００に振り分けるとともに当該配信依頼の配信状況を管理するためのプログラムや、依頼された配信依頼を自身で振り分けるか配信代行装置５００に依頼するかを判断ためのプログラムを記憶する。また、記憶部１４０は、各配信依頼の配信状況を一つのタスクとして管理するためのタスク管理情報１４１や、顧客（配信者端末２００）についての情報を示す顧客情報１４２を記憶していてよい。なお、これらの情報は、クラウドストレージに記憶されていてよく、メッセージ配信装置１００は、クラウドストレージに記憶されているプログラムやデータを利用するように構成されてもよい。タスク管理情報１４１、顧客情報１４２の詳細については後述する。

出力部１５０は、制御部１３０からの指示にしたがって、指定された情報を出力する機能を有する。出力部１５０による出力は、画像信号、音声信号のいずれでの出力であってもよい。画像信号による出力の場合、メッセージ配信装置１００に接続された（又はメッセージ配信装置１００が備える）モニタへの出力であってよい。また、音声信号による出力の場合、メッセージ配信装置１００に接続された（又はメッセージ配信装置１００が備える）スピーカーへの出力であってよい。出力部１５０は、例えば、配信者端末２００から依頼された配信の内容を出力（表示）してもよいし、配信の状況を確認するためにタスク管理情報１４１を出力（表示）してもよい。

制御部１３０は、メッセージ配信装置１００の各部を制御する機能を有するプロセッサである。制御部１３０は、シングルコアにより実現されても、マルチコアにより実現されてもよい。

制御部１３０は、制御部１３０が実現する機能として、受付部１３１と、配信キャリア特定部１３２と、配信先特定部１３３と、第１要求部１３４と、管理部１３５と、判定部１３６と、第２要求部１３７と、を備える。

受付部１３１は、第一の顧客である配信者端末２００から配信の対象となるメッセージ（配信の内容を含む情報）を受け付ける。受付部１３１は、受け付けたメッセージを第１要求部１３４または第２要求部１３７に伝達する。当該メッセージは、メッセージの配信の対象となる配信先を特定可能な情報を含んでよく、当該情報は、一例として、メールアドレスや電話番号であってもよいし、配信先の第二の顧客の属性（年齢や性別、嗜好など）を示す情報などであってもよい。ここで、第一の顧客は、メッセージの配信を依頼するものであれば誰であってもよく、メッセージ配信装置１００が契約を結んでいる顧客であってもよいし、結んでいない一時的な顧客であってもよい。また、第二の顧客は、単なる配信の受け取り手である。

配信キャリア特定部１３２は、配信者端末２００から依頼された配信依頼の対象となるメッセージの配信を依頼する１以上の通信キャリア３００を、複数の通信キャリア３００の中から特定する。配信キャリア特定部１３２は、配信依頼をした配信者端末２００からの配信依頼に、配信先を示す情報が含まれている場合に、当該配信先に対応する通信キャリア３００を特定することとしてよい。また、配信キャリア特定部１３２は、配信者端末２００との間で、配信先を予め定めている場合には、当該情報にしたがって通信キャリア３００を特定することとしてよい。当該情報は、配信者端末２００それぞれについて定めてあってもよく、一つの配信者端末２００について、複数の配信先を定めた情報が含まれてもよい。即ち、配信依頼の内容に応じて、異なる通信キャリア３００が指定されていてもよい。配信キャリア特定部１３２は、判定部１３６により配信依頼をした顧客（配信者端末２００）の配信依頼のうち未完了の件数（以下、滞留件数と呼称する）が所定の閾値以下であると判定された場合に、通信キャリアの特定を行うこととしてよい。配信キャリア特定部１３２は、特定した通信キャリア３００の情報を第１要求部１３４に伝達する。

配信先特定部１３３は、配信者端末２００から依頼された配信依頼のメッセージの送信先（配信先）を特定する。配信先は、メッセージ毎に配信者端末２００により指定されていてもよいし、予め定められていてもよい。配信先は、配信先となる情報処理端末４００のメールアドレスや電話番号であってよい。また、配信先は、情報処理端末４００のユーザの属性を指定する情報であってもよく、例えば、４０代男性というような指定によりなされてもよい。ユーザの属性を指定する情報である場合には、当該属性に基づいて情報処理端末４００を特定するための情報として、情報処理端末４００のユーザの属性情報を、メッセージ配信装置１００または通信キャリア３００のいずれかが保持していることが必要となる。配信先の特定は、通信キャリア３００が実行することとしてもよい。

第１要求部１３４は、配信キャリア特定部１３２が特定した１以上の通信キャリア３００各々に対して、配信者端末２００から依頼された配信依頼に基づく、メッセージの配信を依頼する。当該依頼には、配信するメッセージの内容を示す情報と、配信先の情報処理端末４００を特定可能な情報を含む。第１要求部１３４は、１以上の通信キャリア３００各々に対して配信を依頼すると、配信先の通信キャリア３００と配信を依頼したメッセージを特定可能な情報（メッセージＩＤ（Identifier））と、を管理部１３５に伝達する。第１要求部１３４から特定した１以上の通信キャリア３００に対するメッセージの配信の要求は１つであるが実質的に多数の情報処理端末４００に対する配信依頼が含まれる。

管理部１３５は、各配信者端末２００から依頼された配信依頼の実行状況を管理する。管理部１３５は、記憶部１４０に記憶されているタスク管理情報１４１を用いて、配信依頼の実行状況を管理する。管理部１３５は、第１要求部１３４または第２要求部１３７から配信の依頼を要求した旨を伝達されると、一つの配信依頼を一つのタスクとして、その完了、未完了を管理する。管理部１３５は、第１要求部１３４または第２要求部１３７から配信の依頼を要求した旨を伝達されると、その内容をタスク管理情報１４１に新たなタスクとして登録する。このとき、第１要求部１３４から伝達されている場合には、配信を依頼した各通信キャリアの情報を対応付けて登録する。第２要求部１３７から伝達されている場合には、配信を依頼した配信代行装置５００の情報を対応付けて登録する。管理部１３５は、通信キャリア３００または配信代行装置５００から配信の依頼の完了を受け付けると、対応するタスクにおける通信キャリア３００または配信代行装置５００それぞれの完了状況（後述の個別完了情報３０６）を「未完」から「完了」に変更する。管理部１３５は、配信代行装置５００から、配信依頼の完了を伝達された場合には、対応する一つのタスク全体が完了したもの（後述の完了情報３０４）としてタスク管理情報１４１を更新する。また、管理部１３５は、通信キャリア３００から、配信依頼の完了を伝達された場合には、同じタスクの配信を依頼した他の通信キャリアについての個別完了情報３０６が全て完了になっている場合には、そのタスク全体が完了したものとしてタスク管理情報１４１を更新する。

判定部１３６は、配信依頼を行った配信者端末２００についての滞留件数が所定件数を超えるか否かを判定する。所定件数は、配信者端末２００それぞれで固定であってもよいし、配信者端末２００毎に定められていてもよいし、配信者端末２００毎ではなく配信依頼全体で一つの値が設定されていてもよい。本実施形態では、各配信者端末２００に対して所定件数が設定されているものとする。判定部１３６は、タスク管理情報１４１において、配信者端末２００から依頼された配信依頼のうち完了情報３０４が「未完」となっている件数を滞留件数として計数する。判定部１３６は、滞留件数が所定件数を超える場合には、メッセージの配信の遅延が発生する可能性があると推定できる。換言すれば、滞留件数が所定件数以下である場合には、メッセージの配信について、メッセージ配信装置１００が対応可能な範囲内であり、メッセージの配信の遅延が発生する可能性が低いと推定できる。判定部１３６は、滞留件数が所定件数を超える場合には、その旨を第２要求部１３７に伝達する。また、判定部１３６は、滞留件数が所定件数以下である場合には、その旨を第１要求部１３４に伝達する。

第２要求部１３７は、判定部１３６から、配信者端末２００からの依頼された配信依頼の滞留件数が所定件数を超えると通知された場合に、当該配信依頼（滞留件数が所定件数を超えている状態でされた配信依頼）を、他のアグリゲーターサービス事業者の端末である配信代行装置５００に対して、自身で受けた配信依頼についての配信の代行を依頼する。第２要求部１３７は、配信代行装置５００に対して配信を依頼すると、依頼先の配信代行装置を示す情報と、配信を依頼したメッセージのメッセージＩＤと、を管理部１３５に伝達する。

以上が、メッセージ配信装置１００の構成例の説明である。

なお、配信者端末２００は、メッセージの配信を依頼するユーザの情報処理装置であり、ＰＣ、ノートＰＣ、タブレット端末、サーバ装置などによって実現することができるコンピュータシステムである。配信代行装置５００、情報処理端末４００、通信キャリア３００も同様である。情報処理端末４００は、所謂、スマートフォン、携帯電話などであってもよい。各装置は、他の装置と通信可能な一般的な情報処理装置であるので、詳細な説明については省略する。

なお、各通信キャリア３００は、メッセージ配信装置１００から依頼された配信を完了した場合には、メッセージ配信装置１００に対して、配信の完了を報告する。配信代行装置５００から依頼された場合も同様であり、通信キャリア３００は、配信代行装置５００から依頼された配信を完了した場合には、配信代行装置５００に対して、配信の完了を報告する。配信代行装置５００もまた、メッセージ配信装置１００から依頼された配信を完了している場合には、依頼された配信を完了している旨を、メッセージ配信装置１００に対して報告する。また、通信キャリア３００や配信代行装置５００は、メッセージ配信装置１００から配信を依頼された場合に、その依頼を実行することを示す応答信号を返してもよい。

＜データ＞
図３は、メッセージ配信装置１００の記憶部１４０に記憶されているタスク管理情報１４１のデータ構成例を示すデータ概念図である。タスク管理情報１４１は、メッセージ配信装置１００が、各配信者端末２００から依頼された各配信依頼を管理するために用いる情報であり、各配信依頼の完了、未完了を管理するために用いられる。

図３に示すように、タスク管理情報１４１は、タスクＩＤ３０１と、メッセージＩＤ３０２と、依頼者３０３と、完了情報３０４と、実行者情報３０５と、個別完了情報３０６と、が対応付けられた情報である。タスク管理情報１４１には、図３に示す情報以外の配信依頼のタスクを管理するために利用可能な情報が登録されていてもよい。

タスクＩＤ３０１は、各配信依頼を個別、一意に管理するために制御部１３０が付与する識別情報である。タスクＩＤ３０１は、配信者端末２００から依頼された配信依頼一つにつき、一つのＩＤが制御部１３０によって付与される。

メッセージＩＤ３０２は、対応するタスクＩＤ３０１に対応する配信者端末２００からの配信依頼がどれであるかを一意に特定するための識別情報である。メッセージＩＤ３０２は、各配信依頼を区別可能であれば、どのような形態の情報であってもよい。

依頼者３０３は、対応するタスクＩＤ３０１で示される配信依頼を誰が（どの配信者端末２００）が行ったかを示す情報である。依頼者３０３は、配信者端末２００を特定可能な情報であればよく、配信者端末２００の識別子、ＭＡＣアドレス、運用体の名称などであってよい。図３では、配信者端末２００が属する企業名を例にしている。

完了情報３０４は、対応するタスクＩＤ３０１で示される配信依頼が完了しているか否かを示す情報である。完了情報３０４は、管理部１３５によって、管理、更新される。図３では、配信依頼が完了している場合には「完了」、完了していない場合には「未完」と示している。

実行者情報３０５は、対応するタスクＩＤ３０１で示される配信依頼のうちの一部または全部を実行する実行主体であって、メッセージ配信装置１００が依頼された配信を振り分けた対象者を示す情報である。実行者情報３０５には、第１要求部１３４が依頼した通信キャリア３００、または、第２要求部１３７が依頼した配信代行装置５００の情報が登録される。

個別完了情報３０６は、対応するタスクＩＤ３０１で示される配信依頼において、対応する実行者情報３０５が、依頼された配信を完了しているか否かを示す情報である。即ち、実行者情報３０５毎に、配信を完了しているか否かを示す情報であり、図３では、配信依頼が完了している場合には「完了」、完了していない場合には「未完」と示している。一つのタスクについて、全ての実行者情報３０５の個別完了情報３０６が全て「完了」となっている場合には、タスクとしても完了、即ち、完了情報３０４が「完了」となり、それ以外の場合は、完了情報３０４は、「未完」のままとなる。

タスク管理情報１４１があることにより、メッセージ配信装置１００は、依頼されている配信依頼についての実行状況を管理することができ、各配信者端末２００について滞留件数がどれだけあるかを確認することができる。タスク管理情報１４１においては、配信代行装置５００に依頼した１つの配信依頼も、１以上の通信キャリア３００に対して依頼した配信依頼も、共に１つのタスクとして管理し、それらのうち未完了となっているタスクを滞留件数として特定することができるので、メッセージ配信装置１００は、配信依頼があった際に適切に、通信キャリア３００または配信代行装置５００にメッセージの配信を依頼することで、情報処理端末４００に到達するまでの間でなるべく遅延の発生しないメッセージの配信を実行することができる。

図４は、メッセージ配信装置１００の記憶部１４０に記憶されている顧客情報１４２のデータ構成例を示すデータ概念図である。顧客情報１４２は、メッセージ配信装置１００に対してメッセージの配信を依頼する配信者端末２００に係る各顧客について定めた情報である。より具体的には、顧客情報１４２は、各顧客について、メッセージの配信依頼を配信代行装置５００に依頼する場合の基準となる閾値を定めた情報である。

図４に示すように、顧客情報１４２は、ユーザ識別子３０１と、ユーザ名４０２と、ユーザアドレス４０３と、閾値４０４と、が対応付けられた情報であり、配信依頼を行う配信者に関する情報であれば、これ以外の情報が含まれてもよい。顧客情報１４２は、各配信者端末２００についてどれだけの滞留件数を許容できるかを特定可能な情報である。

ユーザ識別子４０１は、メッセージ配信装置１００において、各配信者端末２００を一意に区別するための識別情報である。

ユーザ名４０２は、対応するユーザ識別子４０１が示す顧客の名称を示す情報である。ユーザ名４０２については、顧客情報１４２に登録されていなくともよい。

ユーザアドレス４０３は、対応するユーザ識別子が示す顧客のメールアドレスを示す情報であり、メッセージ配信装置１００が受け付けた配信依頼がどの顧客からのものであるかを特定するために用いられる情報であってよい。ここでは、ユーザアドレス４０３は、メールアドレスとしているが、配信依頼の配信元を特定できる情報であれば、他の情報であってもよく、例えば、電話番号などであってもよい。

閾値４０４は、対応するユーザ識別子４０１が示す顧客に対して、当該顧客からの配信依頼のうち未完である滞留件数が何件まで許容可能であるかを定めた情報であり、基本的には、依頼されたメッセージの配信がなるべく遅延することがないよう配信されるかどうかを判断するために用いられる閾値である。したがって、対応する顧客からの配信依頼の滞留件数が閾値４０４で示される閾値を超える場合には、配信遅延が発生する可能性があると推定できる。図４においては、閾値４０４は、便宜的に、「ＴＡ」、「ＴＢ」、「ＴＣ」、「ＴＤ」と示しているが、これは、自然数である。

顧客情報１４２があることにより、メッセージ配信装置１００は、受信した配信依頼がどの顧客からであるかを特定できるとともに、受けている配信依頼について遅延が発生しそうかどうかの基準となる閾値を取得することができ、その判定を実行することができる。

＜動作＞
図５は、メッセージ配信システムに係る各装置間のやり取りの例を示すシーケンス図である。図５は、配信者端末２００からの配信依頼を受けたメッセージ配信装置１００がメッセージの配信を依頼する際のやり取りの例を示しており、上段（ステップＳ５０１～Ｓ５０５）は、滞留件数が所定件数を超えていない場合、下段（ステップＳ５０５～Ｓ５１２）は、滞留件数が所定件数を超えている場合を示している。

図５に示すように、配信者端末２００は、メッセージ配信装置１００に対して、配信内容を示す配信情報を送信し、配信依頼を行う（ステップＳ５０１）。

メッセージ配信装置１００は、配信依頼を行った配信者端末２００について、その配信依頼の滞留件数を確認する（ステップＳ５０２）。そして、滞留件数が所定件数以下である場合には、メッセージ配信装置１００は、配信を実行する１以上の通信キャリア３００と配信先（情報処理端末４００）を特定し、特定した通信キャリア３００に配信を依頼する（ステップＳ５０３）。即ち、メッセージ配信装置１００は、依頼されたメッセージの内容を示す情報と、配信先を示す情報とを通信キャリア３００に送信する。

通信キャリア３００は、指定された宛先（配信先）に受信したメッセージの内容で、各情報処理端末４００に配信を行う（ステップＳ５０４）。これにより、各情報処理端末４００は、配信者端末２００が依頼したメッセージを表示することができる。通信キャリア３００は、依頼された情報処理端末４００への配信を全て実行すると、配信が完了したことを示す情報を、メッセージ配信装置１００に報告（送信）する（ステップＳ５０５）。これにより、メッセージ配信装置１００は、一つの通信キャリア３００に対して割り振った分の配信が完了したことを認識でき、一つのタスクの中の一部（又は全部）についての配信状況を管理することができる。

メッセージ配信装置１００は、配信者端末２００から新たな配信依頼を受信する（ステップＳ５０６）。メッセージ配信装置１００は、配信依頼を行った配信者端末２００について、その配信依頼の滞留件数を確認する（ステップＳ５０７）。ここで、滞留件数が対応する配信者端末２００に対して設定されている閾値を超えていたとする。このような場合には、メッセージ配信装置１００が自機で処理を行った場合には配信遅延が発生する可能性があることになるので、メッセージ配信装置１００は、他のアグリゲーターサービス事業者である配信代行装置５００に対して、配信者端末２００からの配信依頼の代行を依頼する。即ち、メッセージ配信装置１００は、配信代行装置５００に対して、情報処理端末４００に対してメッセージが配信されるよう、各通信キャリア３００への振分けを依頼する（ステップＳ５０８）。

配信代行装置５００は、メッセージ配信装置１００と同様に、メッセージの配信を依頼する１以上の通信キャリア３００を選択し、選択した１以上の通信キャリア３００に対してメッセージの配信を依頼する（ステップＳ５０９）。

通信キャリア３００は、指定された宛先（配信先）に受信したメッセージの内容で、各情報処理端末４００に配信を行う（ステップＳ５１０）。これにより、各情報処理端末４００は、配信者端末２００が依頼したメッセージを表示することができる。通信キャリア３００は、依頼された情報処理端末４００への配信を全て実行すると、配信が完了したことを示す情報を、配信代行装置５００に報告（送信）する（ステップＳ５１１）。

当該報告を受けて、配信代行装置５００は、依頼されたメッセージの配信が完了したことを示す情報を、メッセージ配信装置１００に報告（送信）する（ステップＳ５１２）。これにより、メッセージ配信装置１００は、配信代行装置５００に対して依頼した分の配信が完了したことを認識でき、一つのタスクが完了したという配信状況を管理することができる。

このようなやり取りにより、メッセージ配信システムにおいては、配信者端末２００から情報処理端末４００に対して、遅延なくメッセージが配信される。

図６は、図５に示すやり取りを実現するためのメッセージ配信装置１００の動作例を示すフローチャートである。図６に示すフローチャートは、メッセージ配信装置１００が何らかの情報（配信者端末２００からの配信依頼もしくは通信キャリア３００又は配信代行装置５００からの完了報告）を受信した場合の動作例を示している。

図６に示すように、メッセージ配信装置１００の制御部１３０は、通信部１１０を介して、配信者端末２００からの配信依頼である配信情報を受信しているかを判定する（ステップＳ６０１）。配信情報を受信している場合には（ステップＳ６０１のＹＥＳ）、制御部１３０の受付部１３１は、配信者端末２００からの配信依頼としての配信情報を受け付ける（ステップＳ６０２）。

制御部１３０の判定部１３６は、配信依頼を行った配信者端末２００から、これまでに依頼された配信依頼であって、配信が未完了の配信依頼である滞留件数を、タスク管理情報１４１を参照して特定する。判定部１３６は、タスク管理情報１４１の依頼者３０３が配依頼をした配信者端末２００を示すタスクを特定し、特定したタスクのうち、完了情報３０４「未完」であるタスクの件数を、滞留件数として計数する。また、判定部１３６は、配信依頼をした配信者端末２００に対して設定されている閾値４０４を、顧客情報１４２を参照して特定する。即ち、判定部１３６は、顧客情報１４２のユーザ名４０２が配信者端末２００を示す欄を特定し、対応する閾値４０４を特定する（ステップＳ６０３）。そして、判定部１３６は、特定した滞留件数が、特定した閾値を超えるか否かを判定する（ステップＳ６０４）。

滞留件数が閾値を超える場合には（ステップＳ６０４のＹＥＳ）、判定部１３６は、その旨を第２要求部１３７に伝達する。そして、第２要求部１３７は、配信者端末２００から依頼されたメッセージの配信を、他のアグリゲーターサービス事業者のメッセージ配信装置である配信代行装置５００に配信情報の配信、即ち、通信キャリア３００への振り分けを依頼する（ステップＳ６０５）。第２要求部１３７は、配信代行装置５００にメッセージの配信を依頼すると、その旨を、管理部１３５に伝達する。管理部１３５は、第２要求部１３７からメッセージの配信代行装置５００にメッセージの配信依頼を行ったことを示す情報を受け付けると、タスク管理情報１４１に、新たなタスクとして、実行者情報３０５に配信を依頼した配信代行装置５００を、完了情報３０４及び個別完了情報３０６を未完の状態にしたタスクを、登録して処理を終了する（ステップＳ６０６）。

一方で、滞留件数が閾値を超えない、即ち、閾値以下である場合には（ステップＳ６０４のＮＯ）、判定部１３６は、配信キャリア特定部１３２及び第１要求部１３４に対して、その旨を伝達する。

配信キャリア特定部１３２は、受け付けた配信依頼に基づくメッセージの配信を依頼する１以上の通信キャリア３００を特定する（ステップＳ６０７）。通信キャリア３００は、複数存在し、配信キャリア特定部１３２は、複数の通信キャリア３００の中から上述したように１以上の通信キャリアを特定する。配信キャリア特定部１３２は、特定した通信キャリア３００の情報を第１要求部１３４に伝達する。

また、配信先特定部１３３は、受け付けた配信依頼に基づくメッセージの配信先となる情報処理端末４００を特定する（ステップＳ６０８）。配信先特定部１３３は、特定した配信先（情報処理端末４００）の情報を第１要求部１３４に伝達する。

第１要求部１３４は、配信キャリア特定部１３２から伝達された通信キャリア３００に対して、配信先特定部１３３により特定された配信先である情報処理端末４００の情報と、配信の対象となる依頼されたメッセージの内容と、を通信部１１０を介して送信し、通信キャリア３００にメッセージの配信を依頼する（ステップＳ６０９）。第１要求部１３４は、メッセージの配信を依頼した１以上の通信キャリア３００の情報と依頼したメッセージを示す情報を、管理部１３５に伝達する。

管理部１３５は、第１要求部１３４から１以上の通信キャリア３００にメッセージの配信依頼を行ったことを示す情報を受け付けると、タスク管理情報１４１に、新たなタスクとして、実行者情報３０５に配信を依頼した１以上の通信キャリア３００を、完了情報３０４を未完の状態にし、１以上の通信キャリア各々に対応する個別完了情報３０６を未完の状態にしたタスクを、登録して処理を終了する（ステップＳ６０６）。

一方、メッセージ配信装置１００の制御部１３０は、通信部１１０を介して、配信者端末２００からの配信依頼である配信情報を受信していない場合には（ステップＳ６０１のＮＯ）、配信が完了したことを示す完了情報を受信しているか否かを判定する（ステップＳ６１１）。完了情報を受信している場合には（ステップＳ６１１のＹＥＳ）、管理部１３５は、完了情報を送信してきた装置（通信キャリア３００または配信代行装置５００）に対応するタスク管理情報１４１の個別完了情報３０６を「未完」から「完了」に更新する。そして、対応するタスクに対して設定されている実行者情報３０５全ての個別完了情報３０６が「完了」となっていた場合には、完了情報３０４を「未完」から「完了」に更新して、処理を終了する。完了情報を受信していない場合には（ステップＳ６１１のＮＯ）、処理を終了する。

このようにしてメッセージ配信装置１００は、依頼された配信依頼を通信キャリア３００や配信代行装置５００に振り分けるとともに、それぞれの配信依頼の完了、未完了を管理することができる。以上が、メッセージ配信装置１００の動作例である。

＜まとめ＞
上記実施形態に示したように、メッセージ配信装置１００は、配信者端末２００から配信依頼を受け付けた場合に、その配信者端末２００から依頼された配信依頼について未完了の滞留件数を利用して、配信遅延が発生しそうかどうかを判定することができる。滞留件数が多いということは、それだけ、まだ配信が完了していない配信依頼があるということであり、その件数が多い状態で新たな配信依頼についての振分けを通信キャリア３００に対して行った場合には、メッセージが情報処理端末４００に到達するまでの時間に、所定以上の遅延が見込まれることになる。そのようなメッセージの配信の遅延がないことが好ましいことから、本実施形態に係るメッセージ配信装置１００は、滞留件数が所定件数を超える場合には、他の同様の機能を有する配信代行装置５００に依頼することでメッセージの配信遅延がなるべく発生しないようにすることができる。例えば、メッセージの配信依頼が地震速報等の緊急性の高いメッセージの配信依頼などの場合には、配信遅延はないことが好ましいので、本実施形態に係るメッセージ配信装置１００によれば、そのような配信遅延を抑制することができる。

＜補足＞
上記実施形態に係るメッセージ配信システム（メッセージ配信装置１００）は、上記実施形態に限定されるものではなく、他の手法により実現されてもよいことは言うまでもない。以下、各種変形例について説明する。

（１） 上記実施の形態において、メッセージ配信装置１００は、各配信者端末２００についての滞留件数を予測する滞留件数予測部を備え、予測された滞留件数に基づいて、通信キャリア３００にメッセージの配信を依頼するか、配信代行装置５００にメッセージの配信の代行を依頼するかを決定するようにしてもよい。即ち、上記実施形態においては、メッセージの配信依頼を受けた時点における現在の滞留件数に基づいて、通信キャリア３００か配信代行装置５００かの選択を行っていたが、現在の滞留件数に基づく選択の場合、すでに配信に遅延が発生してしまっている可能性がある。そこで、滞留件数予測部が予測した配信依頼時点から所定時間後の滞留件数に基づいて、通信キャリア３００か配信代行装置５００かの選択を行うようにしてもよい。事前の予測に基づく切替を行うことになるので、現時点で配信遅延が既に発生しているというような事態を抑制することができる。

滞留件数予測部は、滞留件数の予測にあたって、学習モデルを利用することとしてよい。当該学習モデルは、配信者端末２００ごとに用意されるものであって、配信者端末２００の過去の配信依頼の傾向（どういうタイミングあるいはどういう事象で、配信の依頼が多くなるか、あるいは、少なくなるかの傾向）や、過去の配信状況（配信が滞りなく行われているときの状況、滞っているときの状況）や、通信キャリア３００からの単位時間当たりのレスポンス応答件数（またはレスポンス応答件数に対する速度の比）等の情報に、その時（あるいはその所定時間後）の滞留件数を対応付けた情報を教師データとして学習した学習モデルであってよい。したがって、当該学習モデルは、現在のメッセージ配信装置１００や配信者端末２００の状況を示す情報を入力として、滞留件数を予測することができる。当該学習モデルは、一例としてｋ近傍法を用いて生成されたモデルであってもよい。また、時系列データに対する異常検知の手法としては、外れ値検知、異常部位検出、変化点検知などの手法を用いることもできる。ここで時系列データは、例えば、配信者端末２００からのメッセージの依頼件数の推移であってよい。このとき、外れ値検知の場合、一例として、当該時系列データの中で、他のアグリゲーターサービス事業者のメッセージ配信装置に対してメッセージの配信の依頼（代行）を依頼しなければならなくなる件数の検知を行うこととしてもよい。また、異常部位検出の場合は、そのメッセージの依頼件数の推移の中で、例えば、一か月単位、一年単位の推移の中での通常値と異なる推移を見せる部分（期間）の検知を行うこととしてもよい。あるいは、変化点検知の場合、時系列データの中で、他のアグリゲーターサービス事業者のメッセージ配信装置に対してメッセージの配信の依頼（代行）を行ったタイミング（行うべきタイミング）の検知を行うこととしてもよい。

（２） 上記実施の形態において、配信キャリア特定部１３２は、通信キャリア３００の現在状況に応じて、配信を依頼するかを決定するようにしてもよい。通信キャリア３００の現在状況を示す情報は、ＳＮＳや各種のニュースサイト等をクローリングすることにより取得することとしてよく、メッセージ配信装置１００はそのためのクローリング部を備えることとしてもよい。そして、配信キャリア特定部１３２は、得られた通信キャリア３００の現在状況を示す情報に基づいて通信キャリア３００に対するメッセージの配信を要求する通信キャリアを特定するようにしてもよい。通信キャリア３００の現在状況としては、例えば、何らかの原因による通信障害の情報などであってよい。通信障害が発生しているということは、その通信キャリア３００に配信を要求しても配信できないので、配信キャリア特定部１３２は、その通信キャリア３００に特定しないように構成してよい。また、クローリング部は、クローリングして得られた情報の中から通信に関わる情報がどの情報であるかを推定するように構成してもよい。クローリング部は、所謂形態素解析等を利用した自然言語解析により収集した情報の中から通信キャリア３００の状況を推定するようにしてもよいし、予め複数の情報について通信キャリア３００にとって通信が実行できない等を確認することができる情報を学習した学習モデルを用いて、通信キャリア３００の状況を推定するようにしてもよい。通信キャリア３００の現在状況の情報を利用することで、メッセージ配信装置１００は、通信キャリア３００の突発的な事故等による通信障害などにも左右されずに依頼されたメッセージの配信を実行することができる。

また、通信キャリア３００の状況については、通信キャリア３００からのレスポンス応答の精度等から推測することとしてもよい。例えば、通信キャリア３００からのレスポンス、即ち、配信依頼に対して、その配信依頼を実行することを示す応答信号の単位時間当たりの件数を用いて、推測することとしてもよい。当該件数が多い場合には、通信キャリア３００に通信のためのリソースが余っていることが予測できるのでより多くの配信依頼を依頼することが可能であると推測することができ、一方で、少ない場合には、通信のリソースに余裕がないことが予測できるので配信依頼を抑制することが好ましいと推測することができる。このような推測に基づいて、配信キャリア特定部１３２は、メッセージの配信を依頼する通信キャリア３００を特定するように構成されてもよい。

（３） 上記実施の形態において、配信者端末２００からの配信依頼、あるいは、配信者端末２００に対して、優先度が設定されていてもよい。優先度が高い配信依頼、あるいは、優先度が高い配信者端末２００からの配信依頼については、優先度が低く設定されている他の配信依頼よりも先に、通信キャリア３００または配信代行装置５００への振分けを行うように構成されてよい。また、優先度の高い配信依頼については、依頼先の通信キャリア３００または配信代行装置５００において未完の配信依頼がある場合には、第１要求部１３４または第２要求部１３７は、その未完の配信依頼に優先して配信を実行するよう要求してもよい。優先度の高い配信依頼としては、例えば、緊急通報、自然災害等の警告、自治体からの配信、認証系のトラフィック、メッセージ配信装置１００にとって重要な顧客である配信者端末２００からの配信依頼などがあってよいが、これらに限定するものではない。

（４） 上記実施の形態において、メッセージ配信装置１００は、トラフィックの混雑度合いを予測する混雑度予測部を備えてもよい。そして、上記実施形態における判定部１３６による判定の代わりに、混雑度予測部がトラフィックが所定以上に混雑すると予測したことをトリガとして、第２要求部１３７から配信代行装置５００に対してメッセージの配信を依頼するように構成してもよい。トラフィックの混雑の予測は、トラフィック状態をモニタし、その推移により推定するようにしてもよい。

（５） 上記実施の形態において、第２要求部１３７は、複数の配信代行装置５００が存在する場合には、複数の配信代行装置５００の中から、配信の代行を依頼する装置を選択するように構成してもよい。このとき、第２要求部１３７は、配信代行装置５００を選択するにあたって、過去に依頼した配信依頼の実行実績に基づいて選択するようにしてもよい。第２要求部１３７は、例えば、配信依頼の完了報告までの時間（あるいはその平均値）が短い配信代行装置５００や、配信の安定度（配信の達成率）の高い配信代行装置５００を選択するように構成されてよい。また、あるいは、第２要求部１３７は、配信の代行を依頼するにあたって、所定の料金を支払う必要がある場合には、その料金が他よりも安い配信代行装置５００を選択して、配信の代行を依頼するように構成されてもよい。

（６） 上記実施の形態においては、メッセージ配信装置１００によるメッセージの配信依頼の振分けの手法として、メッセージ配信装置１００のプロセッサがプログラム等を実行することにより、作成することとしているが、これは装置に集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって実現してもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、上記実施の形態に示した複数の機能部の機能は１つの集積回路により実現されることとしてもよい。ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。

また、上記プログラムは、プロセッサが読み取り可能な記録媒体に記録されていてよく、記録媒体としては、「一時的でない有形の媒体」、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムは、当該プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して上記プロセッサに供給されてもよい。つまり、例えば、スマートフォン等の情報処理機器を利用して、ネットワーク上からプログラムをダウンロードして実行する構成としてもよい。本発明は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。

なお、上記プログラムは、例えば、ActionScript、JavaScript（登録商標）などのスクリプト言語、Objective-C、Java（登録商標）、Ｃ＋＋、Ｐｙｔｈｏｎ、Ｒなどのオブジェクト指向プログラミング言語などを用いて実装できる。

（７） 上記実施の形態に示した各種の実施例は適宜組み合わせることとしてもよい。また、各フローチャートに示した各動作は、結果として矛盾がなければその実行順序を入れ替えたり、並列に実行したりすることとしてもよい。例えば、図６のステップＳ６０７とステップＳ６０８の処理は、その実行順序が前後してもよく、並列に実行されてもよい。

１００ メッセージ配信装置
１１０ 受信部
１２０ 入力部
１３０ 制御部
１３１ 受付部
１３２ 配信キャリア特定部
１３３ 配信先特定部
１３４ 第１要求部
１３５ 管理部
１３６ 判定部
１３７ 第２要求部
１４０ 記憶部
１５０ 出力部
２００、２００ａ、２００ｂ、２００ｃ 配信者端末
３００、３００ａ、３００ｂ、３００ｃ、３００ｄ 通信キャリア
４００、４００ａ、４００ｂ、４００ｃ、４００ｄ、４００ｅ 情報処理端末
５００ 配信代行装置

Claims (6)

1. 第一の顧客から配信の対象となるメッセージを受け付ける受付部と、
   前記メッセージの配信を実行する１以上の通信キャリアを複数の通信キャリアの中から特定する配信キャリア特定部と、
   前記配信キャリア特定部で特定された通信キャリアへ配信を要求する第二の顧客を特定する配信先特定部と、
   前記配信キャリア特定部で特定された通信キャリアに対して前記メッセージの前記第二の顧客への配信を要求する第１要求部と、
   一つのメッセージについての配信状況を一つのタスクとして管理する管理部と、
   各タスクについて配信が完了していない未完了タスクのうち、前記特定された通信キャリアごとの配信要求数の個数が所定閾値を超えるか否かを判定する判定部と、
   前記未完了タスクのうち、前記特定された通信キャリアごとの配信要求数の個数が前記所定閾値を超える場合に、前記受付部が受け付けた新たなメッセージの配信のうち、少なくとも前記所定閾値を超えた前記通信キャリアへの配信要求は、他のアグリゲーターサービス事業者のメッセージ配信装置を介して第二の顧客への前記メッセージの配信を要求する第２要求部と、
   を備えるメッセージ配信装置。
2. 前記管理部は、前記第２要求部が前記他のアグリゲーターサービス事業者のメッセージ配信装置に依頼した配信についても一つのタスクとして管理することを特徴とする請求項１に記載のメッセージ配信装置。
3. 前記管理部は、一つの前記配信の対象となるメッセージについて前記第１要求部が要求した前記通信キャリア全てからの第二の顧客に対する配信状況を管理するとともに、前記第２要求部が要求した前記他のアグリゲーターサービス事業者からの第二の顧客に対する配信状況を管理する
   ことを特徴とする請求項２に記載のメッセージ配信装置。
4. 前記管理部は、第１要求部が要求した一つのタスクとしての配信の要求先である通信キャリア全てから配信完了の報告を受けている場合に当該一つのタスクが完了したものとして管理し、
   第２要求部が要求した一つのタスクとしての配信の要求先である他のアグリゲーターサービス事業者から配信完了の報告を受けている場合に当該一つのタスクが完了したものとして管理する
   ことを特徴とする請求項３に記載のメッセージ配信装置。
5. コンピュータが、
   第一の顧客から配信の対象となるメッセージを受け付ける受付ステップと、
   前記メッセージの配信を実行する１以上の通信キャリアを複数の通信キャリアの中から特定する配信キャリア特定ステップと、
   前記配信キャリア特定ステップで特定された通信キャリアへ配信を要求する第二の顧客を特定する配信先特定ステップと、
   前記配信キャリア特定ステップで特定された通信キャリアに対して前記メッセージの前記第二の顧客への配信を要求する第１要求ステップと、
   一つのメッセージについての配信状況を一つのタスクとして管理する管理ステップと、
   各タスクについて配信が完了していない未完了タスクのうち、前記特定された通信キャリアごとの配信要求数の個数が所定閾値を超えるか否かを判定する判定ステップと、
   前記未完了タスクのうち、前記特定された通信キャリアごとの配信要求数の個数が前記所定閾値を超える場合に、前記受付ステップが受け付けた新たなメッセージの配信のうち、少なくとも前記所定閾値を超えた前記通信キャリアへの配信要求は、他のアグリゲーターサービス事業者のメッセージ配信装置を介して第二の顧客への前記メッセージの配信を要求する第２要求ステップと、
   を実行するメッセージ配信方法。
6. コンピュータに、
   第一の顧客から配信の対象となるメッセージを受け付ける受付機能と、
   前記メッセージの配信を実行する１以上の通信キャリアを複数の通信キャリアの中から特定する配信キャリア特定機能と、
   前記配信キャリア特定機能で特定された通信キャリアへ配信を要求する第二の顧客を特定する配信先特定機能と、
   前記配信キャリア特定機能で特定された通信キャリアに対して前記メッセージの前記第二の顧客への配信を要求する第１要求機能と、
   一つのメッセージについての配信状況を一つのタスクとして管理する管理機能と、
   各タスクについて配信が完了していない未完了タスクのうち、前記特定された通信キャリアごとの配信要求数の個数が所定閾値を超えるか否かを判定する判定機能と、
   前記未完了タスクのうち、前記特定された通信キャリアごとの配信要求数の個数が前記所定閾値を超える場合に、前記受付機能が受け付けた新たなメッセージの配信のうち、少なくとも前記所定閾値を超えた前記通信キャリアへの配信要求は、他のアグリゲーターサービス事業者のメッセージ配信装置を介して第二の顧客への前記メッセージの配信を要求する第２要求機能と、
   を実現させるメッセージ配信プログラム。

Images