通知情報送信装置、通知情報送信プログラム及び通知情報送信方法
【課題】複数の端末に対して通知情報を適切な順序で送信する。
【解決手段】災害通知サーバ１０は、通知情報の送信先である複数の端末を登録したデータを格納する宛先テーブル５４と、登録された複数の端末に対して通知情報を送信する通知送信部１８と、通知情報を受信した端末から送信される受信応答を受信する確認応答受信部３２と、複数の端末のいずれかに対して通知送信部が通知情報を送信してから、確認応答受信部が受信応答を受信するまでの時間取得し、宛先テーブル５４のデータのうち、通知情報を送信した端末に対して、取得した時間の平均を関連付ける関連付け部（応答時間算出部３４，応答時間・平均値更新部３８）と、を備えており、通知送信部は、各端末に関連付けられている時間の平均に基づいて、複数の端末に対する通知情報の送信順序を決定する。
【解決手段】災害通知サーバ１０は、通知情報の送信先である複数の端末を登録したデータを格納する宛先テーブル５４と、登録された複数の端末に対して通知情報を送信する通知送信部１８と、通知情報を受信した端末から送信される受信応答を受信する確認応答受信部３２と、複数の端末のいずれかに対して通知送信部が通知情報を送信してから、確認応答受信部が受信応答を受信するまでの時間取得し、宛先テーブル５４のデータのうち、通知情報を送信した端末に対して、取得した時間の平均を関連付ける関連付け部（応答時間算出部３４，応答時間・平均値更新部３８）と、を備えており、通知送信部は、各端末に関連付けられている時間の平均に基づいて、複数の端末に対する通知情報の送信順序を決定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本件は、通知情報送信装置、通知情報送信プログラム及び通知情報送信方法に関する。
【背景技術】
【０００２】
最近では、地震の発生時や気象警報が発表された場合などにおいて、その内容をあらかじめ登録された利用者（端末）に対して通知するための緊急通報システムが開発・運用されてきている。
【０００３】
このような緊急通報システムでは、利用者が増えて登録数が多くなると、すべての利用者への通知が完了するまでに多大な時間を要することになる。従来においては、登録された順に利用者への通知を行ったり、あるいは、登録時に付加された情報（例えば役職、肩書きなど）に基づいて送信順序を決めていた。
【０００４】
また、特許文献１には、利用者の端末（受信装置）に操作ログを収集する操作ログ収集部と、情報配信装置からの要求に対して操作ログを送信する操作ログ送信部を設け、当該操作ログ送信部から送信される操作ログに基づいて、複数の受信装置に優先順位をつける技術が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−２６０２５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、登録されている端末の中には、種々の端末が含まれる。例えば、実際には既に利用されていない端末や、固定端末であって休日や夜間には電源が落ちるためその間は不通になる端末、通知を然程必要としないが継続して登録されている端末等である。このため、本当に通知を必要としている利用者の端末に対して、緊急通報が遅れて届くおそれがある。
【０００７】
なお、特許文献１では、端末に優先順位を付けることから、通知を必要とする端末に対して緊急通報が遅れて届くことが少なくなる。しかるに、特許文献１では、操作ログ収集部や操作ログ受信部を端末に設ける必要があるため、一般的な電話機や任意のパーソナルコンピュータなどを端末として利用（又は登録）することができない可能性が高い。
【０００８】
そこで本件は上記の課題に鑑みてなされたものであり、複数の端末に対して通知情報を適切な順序で送信することが可能な通知情報送信装置、通知情報送信プログラム及び通知情報送信方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本明細書に記載の通知情報送信装置は、通知情報の送信先である複数の端末を登録したデータを格納する格納部と、前記登録された複数の端末に対して通知情報を送信する送信部と、前記通知情報を受信した端末から送信される受信応答を受信する受信部と、前記複数の端末のいずれかに対して前記送信部が前記通知情報を送信してから、前記受信部が前記受信応答を受信するまでの時間を取得し、前記データのうち、前記送信部が前記通知情報を送信した端末に対して、前記取得した時間に基づく時間情報を関連付ける関連付け部と、を備えており、前記送信部が、各端末に関連付けられている前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定する通知情報送信装置である。
【００１０】
本明細書に記載の通知情報送信プログラムは、登録された複数の端末に対して通知情報を送信し、前記通知情報を受信した端末から送信される受信応答を受信し、前記複数の端末のいずれかに対して前記通知情報を送信してから、前記受信応答を受信するまでの時間を取得し、前記複数の端末が登録されているデータのうち、前記通知情報を送信した端末に対して、前記取得した時間に基づく時間情報を関連付ける処理、をコンピュータに実行させ、前記送信する処理では、各端末に関連付けられている前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定する通知情報送信プログラムである。
【００１１】
本明細書に記載の通知情報送信方法は、登録された複数の端末に対して通知情報を送信する送信工程と、前記通知情報を受信した端末から送信される受信応答を受信する受信工程と、前記複数の端末のいずれかに対して前記通知情報を送信してから、前記受信応答を受信するまでの時間を取得し、前記複数の端末が登録されているデータのうち、前記通知情報を送信した端末に対して、前記取得した時間に基づく時間情報を関連付ける関連付け工程と、をコンピュータが実行し、前記送信工程では、各端末に関連付けられている前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定する通知情報送信方法である。
【発明の効果】
【００１２】
本明細書に記載の通知情報送信装置、通知情報送信プログラム及び通知情報送信方法は、複数の端末に対して通知情報を適切な順序で送信することができるという効果を奏する。
【図面の簡単な説明】
【００１３】
【図１】一実施形態に係る緊急通報システムの構成を概略的に示す図である。
【図２】災害通知サーバのハードウェア構成を示す図である。
【図３】災害通知サーバの機能ブロック図である。
【図４】時間帯テーブルのデータ構造を示す図である。
【図５】宛先テーブルのデータ構造を示す図である。
【図６】送信処理部が実行する処理を示すフローチャートである。
【図７】受信処理部が実行する処理を示すフローチャートである。
【図８】未処理レコード処理部が実行する処理を示すフローチャートである。
【発明を実施するための形態】
【００１４】
以下、一実施形態について、図１〜図８に基づいて詳細に説明する。図１には、一実施形態にかかる緊急通報システム１００が模式的に示されている。図１に示すように、緊急通報システム１００は、事象検知装置７０と、災害通知サーバ１０と、複数の端末８０と、を備える。
【００１５】
事象検知装置７０は、地震計や雨量計、その他災害に関する事象を検知するセンサ等を含んでいる。事象検知装置７０では、事象を検知するセンサ等の検知結果が、所定の値（例えば、災害が発生する可能性が高い値）を超えていた場合に、その検知結果を災害通知サーバ１０に対して送信する。また、図示は略すが、事象検知装置７０は、気象庁が発表した気象警報，市町村が発表した避難勧告等の情報を受信して、災害通知サーバ１０に対して送信する場合もある。
【００１６】
端末８０には、種々の端末、例えば、携帯電話、デスクトップ型ＰＣ（Personal Computer）、ノート型ＰＣ、タブレット型端末、ＰＤＡ（Personal Digital Assistant）、ＰＨＳ（Personal Handy-phone System）、固定電話などが含まれる。端末８０は、ネットワーク等を介して、災害通知サーバ１０と接続されており、災害通知サーバ１０から送信される通知情報（災害が発生した、又は災害が発生する可能性があることを通知する情報）を受信することができる。端末８０では、通知情報を受信した場合に、何らかの確認応答（通知情報を受信又は確認したことを証明する応答）を返信する機能を有しているものとする。
【００１７】
例えば、端末８０が携帯電話であった場合には、利用者は、通知情報をメールなどで受信することができる。この場合、携帯電話では、メールを受信し、利用者が当該メールを見て確認ボタンを押したときに、確認応答として、災害通知サーバ１０にメールを返信することができる。また、端末８０が固定電話であった場合には、利用者は、通知情報を音声にて受けることができる。この場合、固定電話では、利用者が通知情報を全て聞いた後所定のプッシュボタンを押したときに、当該ボタンの情報（トーン）が、確認応答として災害通知サーバ１０に送られることになる。更には、端末８０がＰＣ等である場合には、通知情報をブラウザ上で確認できるようにすることができる。この場合、ＰＣの利用者が、ブラウザ上で所定の確認ボタンを押したときに、そのボタンの情報が確認応答として災害通知サーバ１０に返信される。
【００１８】
図２には、災害通知サーバ１０のハードウェア構成が示されている。図２に示すように、災害通知サーバ１０は、ＣＰＵ９０、ＲＯＭ９２、ＲＡＭ９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、入出力部９７等を備えている。災害通知サーバ１０の構成各部は、バス９８に接続されている。また、入出力部９７には、可搬型記憶媒体用ドライブ９９が接続されており、当該ドライブ９９において可搬型記憶媒体９１から読み出されたプログラム（通知情報送信プログラム）、又はＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（通知情報送信プログラム）をＣＰＵ９０が実行することにより、図３の各部の機能が実現される。
【００１９】
図３には、災害通知サーバ１０の機能ブロック図が示されている。図３に示すように、災害通知サーバ１０は、送信処理部５０、受信処理部６０、及び未処理レコード処理部４０として機能する。なお、図３には、ＨＤＤ９６に格納されているテーブル（時間帯テーブル５２及び格納部としての宛先テーブル５４）も図示されている。
【００２０】
ここで、時間帯テーブル５２と、宛先テーブル５４について、図４、図５に基づいて説明する。図４には、時間帯テーブル５２のデータ構造が示されている。図４に示すように、時間帯テーブル５２には、時間帯の名称（時間帯１、時間帯２、…）と、時間帯の開始タイミング（曜日及び時刻）と、時間帯の終了タイミング（曜日及び時刻）が格納されている。
【００２１】
図５には、宛先テーブル５４のデータ構造が示されている。宛先テーブル５４は、宛先ごとの、時間帯別の過去２回分の応答時間及びそれらの平均値を格納している。より具体的には、図５に示すように、宛先テーブル５４には、宛先、属性、送信日時、送信中フラグ、応答時間（秒）の項目が設けられている。宛先には、災害通知サーバ１０のサービスを受けたい利用者が登録した電話番号やメールアドレス、ＩＰアドレスなどが格納される。属性には、役職などが格納される。送信日時には、宛先に対して通知情報を送信した日時が格納される。送信中フラグには、１，０のいずれかが格納される。フラグが１の場合は、通知情報を宛先の端末に送信したものの受信応答が未だ返ってきていない場合を意味する。一方、フラグが０の場合は、通知情報を宛先に送信したことがない、又は通知情報を送信した後に受信応答が既に返ってきている状態を意味する。応答時間（秒）には、各時間帯における前回及び前々回の応答時間と、これらの平均（平均応答時間）の項目が含まれている。なお、以下においては、宛先テーブル５４の宛先毎のデータを、「レコード」と呼ぶものとする。
【００２２】
図３に戻り、送信処理部５０は、事象受信部１２と、時間帯判定部１４と、宛先取得部１６と、通知送信部１８と、送信日時更新部２０と、を有する。なお、宛先取得部１６と通知送信部１８とを含んで送信部が実現されている。
【００２３】
事象受信部１２は、事象検知装置７０から、事象（地震や大雨などの情報）を受信する。時間帯判定部１４は、事象を受信したとき（現在）の時刻と、時間帯テーブル５２（図４）と、に基づいて、時間帯（時間帯１，２…のうちのいずれか）を判定する。
【００２４】
宛先取得部１６は、宛先テーブル５４（図５参照）から、登録されている宛先の全てを取得する。この場合、宛先取得部１６は、時間帯判定部１４で判定された時間帯と、当該時間帯における応答時間（平均）とに基づいて、宛先をソートして（順番を入れ替えて）、全宛先を取得する。
【００２５】
通知送信部１８は、宛先テーブル５４に登録されている端末８０に対して、通知情報を送信する。この場合、通知送信部１８は、宛先取得部１６で取得された宛先順に、通知情報を送信する。すなわち、宛先取得部１６と通知送信部１８では、宛先テーブル５４において各端末に関連付けられている（紐付けられている）応答時間の平均から通知情報の送信順序を決定し、当該順序に従って、通知情報を送信している、といえる。
【００２６】
送信日時更新部２０は、宛先テーブル５４の送信日時を通知送信部１８が通知情報を送信した時刻（現在の時刻）で更新するとともに、送信中フラグをセット（フラグ＝１）する。
【００２７】
受信処理部６０は、受信部としての確認応答受信部３２と、応答時間算出部３４と、時間帯取得部としての時間帯判定部３６と、応答時間・平均値更新部３８と、を有する。なお応答時間算出部３４と、応答時間・平均値更新部３８とを含んで、関連付け部が実現されている。
【００２８】
確認応答受信部３２は、通知情報を受信した端末８０から送信されてくる確認応答を受信する。応答時間算出部３４は、通知送信部１８が通知情報を送信してから、確認応答受信部３２が確認応答を受信するまでに要した時間（応答時間）を算出する。時間帯判定部３６は、時間帯テーブル５２に基づいて、通知送信部１８が通知情報を送信した時刻の時間帯を判定する。
【００２９】
応答時間・平均値更新部３８は、時間帯判定部３６で判定された時間帯の応答時間のデータを、応答時間算出部３４で算出された応答時間で更新する。また、応答時間・平均値更新部３８は、今回の応答時間（図５では「前回」の時間）と、その前の応答時間（図５では「前々回」の時間）との平均を算出し、宛先テーブル５４を更新する。
【００３０】
次に、災害通知サーバ１０で実行される処理の詳細について、図６〜図８のフローチャートに沿って説明する。なお、図６〜図８の各処理は、同時並行的に行われる。
【００３１】
（送信処理部５０の処理）
まず、送信処理部５０の処理について、図６に基づいて説明する。図６は、送信処理部５０が実行する処理を示すフローチャートである。この図６の処理では、ステップＳ１０において、事象受信部１２が、通知対象の事象を受信するまで待機する。ここでは、事象受信部１２が、事象検知装置７０から送信されてくる通知対象の事象（地震や大雨などの情報）を受信した段階で、ステップＳ１２に移行する。
【００３２】
ステップＳ１２では、時間帯判定部１４が、現在日時を含む時間帯を判定する。すなわち、時間帯判定部１４は、現在日時を含む時間帯を時間帯テーブル５２から取得して対象時間帯とする。例えば、現在日時が月曜日の１１時であった場合には、時間帯判定部１４は、図４の時間帯テーブル５２を参照して、時間帯１を対象時間帯とする。
【００３３】
次いで、ステップＳ１４では、宛先取得部１６が、対象時間帯における平均応答時間が短い順というソート条件を指定して、宛先テーブル５４からすべての宛先を一括して取得する。すなわち、例えば対象時間帯が時間帯１である場合には、宛先取得部１６は、図５の宛先テーブル５４を、時間帯１の「平均」の行の値が小さい順になるように並べ替えて、全ての宛先を取得する。
【００３４】
次いで、ステップＳ１６では、通知送信部１８が、取得した宛先全てに対して通知情報（通知対象の事象に関する情報）を送信したか否かを判断する。ここでは、全ての宛先への通知情報の送信が完了し、ステップＳ１６の判断が肯定された場合には、図６の全処理を終了する。一方、全ての宛先に通知情報を送信していない場合には、ステップＳ１６の判断が否定されて、ステップＳ１８に移行する。
【００３５】
ステップＳ１８に移行した場合、通知送信部１８は、取得した宛先のうち、未送信で取得順が最も前の宛先に通知情報を送信する。すなわち、未送信の宛先のうち、平均応答時間が最も短い宛先に対して通知情報を送信する。
【００３６】
次いで、ステップＳ２０では、送信日時更新部２０が、宛先テーブル５４のうち、今回送信した宛先（宛先レコード）の送信日時を、現在日時で更新するとともに、送信中フラグをセットする（フラグ＝１）。ステップＳ２０の処理が終了した後は、ステップＳ１６に戻る。そして、ステップＳ１６の判断が肯定された段階で、図６の全処理が終了する。なお、図６の処理は、その後も繰り返し実行される。
【００３７】
（受信処理部６０の処理）
次に、図７に基づいて、受信処理部６０の処理について説明する。図７は、受信処理部６０が実行する処理を示すフローチャートである。
【００３８】
図７の処理では、まず、ステップＳ３０において、確認応答受信部３２が、端末８０から送信されてくる確認応答を受信するまで待機する。確認応答受信部３２は、確認応答を受信すると、ステップＳ３２に移行する。
【００３９】
ステップＳ３２では、応答時間算出部３４が、現在日時を確認日時とする。次いで、ステップＳ３４では、応答時間算出部３４が、確認応答を受信した宛先の送信日時を宛先テーブルから取得する。
【００４０】
次いで、ステップＳ３６では、時間帯判定部３６が、送信日時を含む時間帯を時間帯テーブル５２に基づいて判定する。すなわち、時間帯判定部３６は、時間帯テーブル５２を参照して、送信日時を含む時間帯を取得する。そして、時間帯判定部３６は、取得した時間帯を、対象時間帯とする。次いで、ステップＳ３８では、応答時間算出部３４が、送信日時と確認日時との差を求めて応答時間とする。応答時間算出部３４は、算出した応答時間を、応答時間・平均値更新部３８に送信する。
【００４１】
次いで、ステップＳ４０では、応答時間・平均値更新部３８が、宛先テーブルの、確認応答を受信した宛先の対象時間帯における前回応答時間として、ステップＳ３８で算出した応答時間をセットする。なお、ステップＳ４０を行う以前において、宛先テーブル５４の前回応答時間にセットされていた時間は、ステップＳ４０の際に前々回応答時間として新たにセットされるものとする。
【００４２】
次いで、ステップＳ４２では、応答時間・平均値更新部３８が、確認応答を受信した宛先の対象時間帯における前回応答時間と前々回応答時間の平均値を算出し、宛先テーブル５４の対象時間帯における「平均」の項目を更新する。
【００４３】
次いで、ステップＳ４４では、応答時間・平均値更新部３８が、宛先テーブル５４の、今回受信した宛先の送信中フラグをリセットする（フラグ＝０）。ステップＳ４４までの処理が終了すると、図７の全処理が終了することになる。なお、図７の処理は、その後も繰り返し実行される。
【００４４】
（未処理レコード処理部４０の処理）
次に、未処理レコード処理部４０の処理について、図８に基づいて説明する。図８は、未処理レコード処理部４０が実行する処理を示すフローチャートである。
【００４５】
図８の処理では、ステップＳ５０において、未処理レコード処理部４０が、所定時間経過したか否かを判断する。このステップＳ５０は、ステップＳ５２以降の処理を所定時間ごとに行うために必要なステップである。
【００４６】
所定時間が経過し、ステップＳ５２に移行すると、未処理レコード処理部４０は、送信中フラグがセットされているレコード（フラグが１であるレコード）を宛先テーブル５４から取得する。次いで、ステップＳ５４では、未処理レコード処理部４０が、取得したレコードの処理が全て終了したか否かを判断する。このステップＳ５４の判断が肯定された場合には、図８の全処理を終了する。一方、ステップＳ５４の判断が否定された場合には、ステップＳ５６に移行する。
【００４７】
ステップＳ５６に移行すると、未処理レコード処理部４０は、取得したレコードのうちの１つ（例えば最上段のレコード）に着目する。次いで、ステップＳ５８では、未処理レコード処理部４０が、着目したレコードの送信日時から一定時間以上経過しているか否かを判断する。ここでの判断が肯定されると、ステップＳ６０に移行する。
【００４８】
ステップＳ６０では、未処理レコード処理部４０が、着目したレコードの送信日時が属する時間帯を時間帯テーブル５２から取得して、対象時間帯とする。次いで、ステップＳ６２では、未処理レコード処理部４０が、着目したレコードの対象時間帯の前回応答時間として所定のみなし応答時間（例えば半日程度）を、宛先テーブル５４にセットする。次いで、ステップＳ６４では、未処理レコード処理部４０が、着目したレコードの対象時間帯における前回応答時間と前々回応答時間の平均値を算出して、宛先テーブル５４を更新する。そして、ステップＳ６６では、未処理レコード処理部４０が、宛先テーブル５４の、着目したレコードの送信フラグをリセットする（フラグ＝０）。なお、災害通知サーバ１０から情報が送信されてから、端末８０から確認応答が出されるまでに長時間を要する場合に、上記のようにみなし応答時間をセットするのは、応答時間が長時間更新されないと、その後の処理に影響が生じる可能性があるからである。
【００４９】
その後は、ステップＳ５４に戻り、未処理レコード処理部４０は、ステップＳ３４で取得したレコードの処理が全て終了したか否かを判断する。ここでの判断が否定された場合には、ステップＳ５６に移行し、取得したレコードのうち、これまでに着目していないレコードに着目する。その後は、ステップＳ５８に移行する。
【００５０】
なお、ステップＳ５８の判断が否定された場合には、着目しているレコードに対する処理を何も行わずに、ステップＳ５４に戻る。
【００５１】
そして、ステップＳ５４の判断が肯定された段階で、図８の全処理を終了する。なお、図８の処理は、その後も繰り返し実行される。
【００５２】
以上、詳細に説明したように、本実施形態によると、通知送信部１８が、宛先テーブル５４に登録されている複数の端末８０に対して通知情報を送信し、確認応答受信部３２が、通知情報を受信した端末８０から送信される受信応答を受信する。また、応答時間算出部３４が、通知送信部１８が通知情報を送信してから確認応答受信部３２が受信応答を受信するまでの応答時間を算出し、応答時間・平均値更新部３８が、当該応答時間及びそれ以前の応答時間の平均値で、宛先テーブル５４を更新する。そして、通知送信部１８は、宛先テーブル５４の応答時間の平均値に基づいて通知情報を送信する端末の送信順位を決定する、すなわち過去における応答時間が早い端末に対して、他の端末よりも優先して通知情報を送信する。ここで、過去に通知情報が送信されたときの端末の応答時間が短いほど、当該端末の利用者は、通知情報を必要としている人である可能性が高い。したがって、本実施形態では、過去に通知情報が送信されたときの端末の応答時間を考慮することで、通知情報を必要とする利用者の端末に対して、優先的に通知情報を送信することが可能となる。これにより、例えば、自治体の災害対策業務の担当者は、通知情報に対する応答時間が、他の人に比べて早いと考えられるが、このような担当者に対して早めに通知情報を送信することができるようになる。このため、災害対策の初動時間を短縮することが可能となる。
【００５３】
また、本実施形態によると、時間帯判定部３６が、通知送信部１８が通知情報を送信した時刻が含まれる時間帯を取得し、応答時間・平均値更新部３８は、取得された時間帯ごとに、応答時間を、宛先テーブル５４に登録する。そして、宛先取得部１６は、通知情報を送信する時刻が含まれる時間帯における応答時間に基づいて、端末８０に対する通知情報の送信順序を決定する。これにより、曜日や時間帯ごとに通知情報の必要性が変化する場合であっても、適切な送信順序で端末に対して通知情報を送信することができる。
【００５４】
なお、上記実施形態では、時間帯テーブル５２の時間帯を、図４のように、曜日と時刻とで定義する場合について説明したが、これに限られるものではない。例えば、平日の昼間と、その他の時間帯というように定義してもよい。あるいは、時刻のみで定義することとしてもよい。なお、上記実施形態では、時間帯を考慮して、通知情報の送信順序を決定する場合について説明したが、これに限らず、時間帯を考慮しなくてもよい。この場合、上記実施形態の時間帯に関する部分（時間帯判定部１４、３６、時間帯テーブル５２、宛先テーブル５４の時間帯ごとの応答時間管理など）を省略することができる。
【００５５】
なお、上記実施形態では、宛先テーブル５４において、応答時間の平均を、前回応答時間と前々回応答時間の平均とすることとしたが、これに限られるものではない。例えば、災害通知サーバ１０の稼動後の全応答時間の平均を用いてもよい。また、平均値として重み付け平均値を用いることとしても良い。この場合、例えば、現在に近い応答時間ほど、重みを大きくするなどすることができる。更には、平均を求めずに、前回応答時間のみを宛先テーブル５４に登録しておき、当該前回応答時間に基づいて、通知情報を送信する端末の順序を決定することとしてもよい。
【００５６】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。
【００５７】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【００５８】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【００５９】
上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
【００６０】
なお、以上の説明に関して更に以下の付記を開示する。
（付記１） 通知情報の送信先である複数の端末を登録したデータを格納する格納部と、前記登録された複数の端末に対して通知情報を送信する送信部と、前記通知情報を受信した端末から送信される受信応答を受信する受信部と、前記複数の端末のいずれかに対して前記送信部が前記通知情報を送信してから、前記受信部が前記受信応答を受信するまでの時間を取得し、前記データのうち、前記送信部が前記通知情報を送信した端末に対して、前記取得した時間に基づく時間情報を関連付ける関連付け部と、を備え、前記送信部は、各端末に関連付けられている前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする通知情報送信装置。
（付記２） 前記送信部が前記通知情報を送信した時刻が含まれる時間帯を取得する時間帯取得部を更に備え、前記関連付け部は、前記時間帯取得部により取得された時間帯ごとに、前記時間情報を、前記送信部が前記通知情報を送信した端末に関連付け、前記送信部は、前記通知情報を送信する時刻が含まれる時間帯における、前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする付記１に記載の通知情報送信装置。
（付記３） 前記時間情報は、前記送信部が前記通知情報を送信してから、前記受信部が前記受信応答を受信するまでの時間の平均値であり、前記送信部は、前記平均値が小さい端末ほど、前記情報を送信する順序を早くすることを特徴とする付記１又は２に記載の通知情報送信装置。
（付記４） 登録された複数の端末に対して通知情報を送信し、前記通知情報を受信した端末から送信される受信応答を受信し、前記複数の端末のいずれかに対して前記通知情報を送信してから、前記受信応答を受信するまでの時間を取得し、前記複数の端末が登録されているデータのうち、前記通知情報を送信した端末に対して、前記取得した時間に基づく時間情報を関連付ける処理、をコンピュータに実行させ、
前記送信する処理では、各端末に関連付けられている前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする通知情報送信プログラム。
（付記５） 前記コンピュータに、前記通知情報を送信した時刻が含まれる時間帯を取得する処理を更に実行させ、前記関連付ける処理では、前記時間帯ごとに、前記時間情報を、前記通知情報を送信した端末に関連付け、前記送信する処理では、前記通知情報を送信する時刻が含まれる時間帯における、前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする付記４に記載の通知情報送信プログラム。
（付記６） 前記時間情報は、前記通知情報を送信してから、前記受信応答を受信するまでの時間の平均値であり、前記送信する処理では、前記平均値が小さい端末ほど、前記情報を送信する順序を早くすることを特徴とする付記４又は５に記載の通知情報送信プログラム。
（付記７） 登録された複数の端末に対して通知情報を送信する送信工程と、前記通知情報を受信した端末から送信される受信応答を受信する受信工程と、前記複数の端末のいずれかに対して前記通知情報を送信してから、前記受信応答を受信するまでの時間を取得し、前記複数の端末が登録されているデータのうち、前記通知情報を送信した端末に対して、前記取得した時間に基づく時間情報を関連付ける関連付け工程と、をコンピュータが実行し、前記送信工程では、各端末に関連付けられている前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする通知情報送信方法。
（付記８） 前記コンピュータが、前記通知情報を送信した時刻が含まれる時間帯を取得する時間帯取得工程を更に実行し、前記関連付け工程では、前記時間帯ごとに、前記時間情報を、前記通知情報を送信した端末に関連付け、前記送信する処理では、前記通知情報を送信する時刻が含まれる時間帯における、前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする付記７に記載の通知情報送信方法。
（付記９） 前記時間情報は、前記通知情報を送信してから、前記受信応答を受信するまでの時間の平均値であり、前記送信工程では、前記平均値が小さい端末ほど、前記情報を送信する順序を早くすることを特徴とする付記７又は８に記載の通知情報送信方法。
【符号の説明】
【００６１】
１８ 通知送信部（送信部）
３２ 確認応答受信部（受信部）
３４ 応答時間算出部（関連付け部の一部）
３６ 時間帯判定部（時間帯取得部）
３８ 応答時間・平均値更新部（関連付け部の一部）
５４ 宛先テーブル（格納部）
【技術分野】
【０００１】
本件は、通知情報送信装置、通知情報送信プログラム及び通知情報送信方法に関する。
【背景技術】
【０００２】
最近では、地震の発生時や気象警報が発表された場合などにおいて、その内容をあらかじめ登録された利用者（端末）に対して通知するための緊急通報システムが開発・運用されてきている。
【０００３】
このような緊急通報システムでは、利用者が増えて登録数が多くなると、すべての利用者への通知が完了するまでに多大な時間を要することになる。従来においては、登録された順に利用者への通知を行ったり、あるいは、登録時に付加された情報（例えば役職、肩書きなど）に基づいて送信順序を決めていた。
【０００４】
また、特許文献１には、利用者の端末（受信装置）に操作ログを収集する操作ログ収集部と、情報配信装置からの要求に対して操作ログを送信する操作ログ送信部を設け、当該操作ログ送信部から送信される操作ログに基づいて、複数の受信装置に優先順位をつける技術が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−２６０２５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、登録されている端末の中には、種々の端末が含まれる。例えば、実際には既に利用されていない端末や、固定端末であって休日や夜間には電源が落ちるためその間は不通になる端末、通知を然程必要としないが継続して登録されている端末等である。このため、本当に通知を必要としている利用者の端末に対して、緊急通報が遅れて届くおそれがある。
【０００７】
なお、特許文献１では、端末に優先順位を付けることから、通知を必要とする端末に対して緊急通報が遅れて届くことが少なくなる。しかるに、特許文献１では、操作ログ収集部や操作ログ受信部を端末に設ける必要があるため、一般的な電話機や任意のパーソナルコンピュータなどを端末として利用（又は登録）することができない可能性が高い。
【０００８】
そこで本件は上記の課題に鑑みてなされたものであり、複数の端末に対して通知情報を適切な順序で送信することが可能な通知情報送信装置、通知情報送信プログラム及び通知情報送信方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本明細書に記載の通知情報送信装置は、通知情報の送信先である複数の端末を登録したデータを格納する格納部と、前記登録された複数の端末に対して通知情報を送信する送信部と、前記通知情報を受信した端末から送信される受信応答を受信する受信部と、前記複数の端末のいずれかに対して前記送信部が前記通知情報を送信してから、前記受信部が前記受信応答を受信するまでの時間を取得し、前記データのうち、前記送信部が前記通知情報を送信した端末に対して、前記取得した時間に基づく時間情報を関連付ける関連付け部と、を備えており、前記送信部が、各端末に関連付けられている前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定する通知情報送信装置である。
【００１０】
本明細書に記載の通知情報送信プログラムは、登録された複数の端末に対して通知情報を送信し、前記通知情報を受信した端末から送信される受信応答を受信し、前記複数の端末のいずれかに対して前記通知情報を送信してから、前記受信応答を受信するまでの時間を取得し、前記複数の端末が登録されているデータのうち、前記通知情報を送信した端末に対して、前記取得した時間に基づく時間情報を関連付ける処理、をコンピュータに実行させ、前記送信する処理では、各端末に関連付けられている前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定する通知情報送信プログラムである。
【００１１】
本明細書に記載の通知情報送信方法は、登録された複数の端末に対して通知情報を送信する送信工程と、前記通知情報を受信した端末から送信される受信応答を受信する受信工程と、前記複数の端末のいずれかに対して前記通知情報を送信してから、前記受信応答を受信するまでの時間を取得し、前記複数の端末が登録されているデータのうち、前記通知情報を送信した端末に対して、前記取得した時間に基づく時間情報を関連付ける関連付け工程と、をコンピュータが実行し、前記送信工程では、各端末に関連付けられている前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定する通知情報送信方法である。
【発明の効果】
【００１２】
本明細書に記載の通知情報送信装置、通知情報送信プログラム及び通知情報送信方法は、複数の端末に対して通知情報を適切な順序で送信することができるという効果を奏する。
【図面の簡単な説明】
【００１３】
【図１】一実施形態に係る緊急通報システムの構成を概略的に示す図である。
【図２】災害通知サーバのハードウェア構成を示す図である。
【図３】災害通知サーバの機能ブロック図である。
【図４】時間帯テーブルのデータ構造を示す図である。
【図５】宛先テーブルのデータ構造を示す図である。
【図６】送信処理部が実行する処理を示すフローチャートである。
【図７】受信処理部が実行する処理を示すフローチャートである。
【図８】未処理レコード処理部が実行する処理を示すフローチャートである。
【発明を実施するための形態】
【００１４】
以下、一実施形態について、図１〜図８に基づいて詳細に説明する。図１には、一実施形態にかかる緊急通報システム１００が模式的に示されている。図１に示すように、緊急通報システム１００は、事象検知装置７０と、災害通知サーバ１０と、複数の端末８０と、を備える。
【００１５】
事象検知装置７０は、地震計や雨量計、その他災害に関する事象を検知するセンサ等を含んでいる。事象検知装置７０では、事象を検知するセンサ等の検知結果が、所定の値（例えば、災害が発生する可能性が高い値）を超えていた場合に、その検知結果を災害通知サーバ１０に対して送信する。また、図示は略すが、事象検知装置７０は、気象庁が発表した気象警報，市町村が発表した避難勧告等の情報を受信して、災害通知サーバ１０に対して送信する場合もある。
【００１６】
端末８０には、種々の端末、例えば、携帯電話、デスクトップ型ＰＣ（Personal Computer）、ノート型ＰＣ、タブレット型端末、ＰＤＡ（Personal Digital Assistant）、ＰＨＳ（Personal Handy-phone System）、固定電話などが含まれる。端末８０は、ネットワーク等を介して、災害通知サーバ１０と接続されており、災害通知サーバ１０から送信される通知情報（災害が発生した、又は災害が発生する可能性があることを通知する情報）を受信することができる。端末８０では、通知情報を受信した場合に、何らかの確認応答（通知情報を受信又は確認したことを証明する応答）を返信する機能を有しているものとする。
【００１７】
例えば、端末８０が携帯電話であった場合には、利用者は、通知情報をメールなどで受信することができる。この場合、携帯電話では、メールを受信し、利用者が当該メールを見て確認ボタンを押したときに、確認応答として、災害通知サーバ１０にメールを返信することができる。また、端末８０が固定電話であった場合には、利用者は、通知情報を音声にて受けることができる。この場合、固定電話では、利用者が通知情報を全て聞いた後所定のプッシュボタンを押したときに、当該ボタンの情報（トーン）が、確認応答として災害通知サーバ１０に送られることになる。更には、端末８０がＰＣ等である場合には、通知情報をブラウザ上で確認できるようにすることができる。この場合、ＰＣの利用者が、ブラウザ上で所定の確認ボタンを押したときに、そのボタンの情報が確認応答として災害通知サーバ１０に返信される。
【００１８】
図２には、災害通知サーバ１０のハードウェア構成が示されている。図２に示すように、災害通知サーバ１０は、ＣＰＵ９０、ＲＯＭ９２、ＲＡＭ９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、入出力部９７等を備えている。災害通知サーバ１０の構成各部は、バス９８に接続されている。また、入出力部９７には、可搬型記憶媒体用ドライブ９９が接続されており、当該ドライブ９９において可搬型記憶媒体９１から読み出されたプログラム（通知情報送信プログラム）、又はＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（通知情報送信プログラム）をＣＰＵ９０が実行することにより、図３の各部の機能が実現される。
【００１９】
図３には、災害通知サーバ１０の機能ブロック図が示されている。図３に示すように、災害通知サーバ１０は、送信処理部５０、受信処理部６０、及び未処理レコード処理部４０として機能する。なお、図３には、ＨＤＤ９６に格納されているテーブル（時間帯テーブル５２及び格納部としての宛先テーブル５４）も図示されている。
【００２０】
ここで、時間帯テーブル５２と、宛先テーブル５４について、図４、図５に基づいて説明する。図４には、時間帯テーブル５２のデータ構造が示されている。図４に示すように、時間帯テーブル５２には、時間帯の名称（時間帯１、時間帯２、…）と、時間帯の開始タイミング（曜日及び時刻）と、時間帯の終了タイミング（曜日及び時刻）が格納されている。
【００２１】
図５には、宛先テーブル５４のデータ構造が示されている。宛先テーブル５４は、宛先ごとの、時間帯別の過去２回分の応答時間及びそれらの平均値を格納している。より具体的には、図５に示すように、宛先テーブル５４には、宛先、属性、送信日時、送信中フラグ、応答時間（秒）の項目が設けられている。宛先には、災害通知サーバ１０のサービスを受けたい利用者が登録した電話番号やメールアドレス、ＩＰアドレスなどが格納される。属性には、役職などが格納される。送信日時には、宛先に対して通知情報を送信した日時が格納される。送信中フラグには、１，０のいずれかが格納される。フラグが１の場合は、通知情報を宛先の端末に送信したものの受信応答が未だ返ってきていない場合を意味する。一方、フラグが０の場合は、通知情報を宛先に送信したことがない、又は通知情報を送信した後に受信応答が既に返ってきている状態を意味する。応答時間（秒）には、各時間帯における前回及び前々回の応答時間と、これらの平均（平均応答時間）の項目が含まれている。なお、以下においては、宛先テーブル５４の宛先毎のデータを、「レコード」と呼ぶものとする。
【００２２】
図３に戻り、送信処理部５０は、事象受信部１２と、時間帯判定部１４と、宛先取得部１６と、通知送信部１８と、送信日時更新部２０と、を有する。なお、宛先取得部１６と通知送信部１８とを含んで送信部が実現されている。
【００２３】
事象受信部１２は、事象検知装置７０から、事象（地震や大雨などの情報）を受信する。時間帯判定部１４は、事象を受信したとき（現在）の時刻と、時間帯テーブル５２（図４）と、に基づいて、時間帯（時間帯１，２…のうちのいずれか）を判定する。
【００２４】
宛先取得部１６は、宛先テーブル５４（図５参照）から、登録されている宛先の全てを取得する。この場合、宛先取得部１６は、時間帯判定部１４で判定された時間帯と、当該時間帯における応答時間（平均）とに基づいて、宛先をソートして（順番を入れ替えて）、全宛先を取得する。
【００２５】
通知送信部１８は、宛先テーブル５４に登録されている端末８０に対して、通知情報を送信する。この場合、通知送信部１８は、宛先取得部１６で取得された宛先順に、通知情報を送信する。すなわち、宛先取得部１６と通知送信部１８では、宛先テーブル５４において各端末に関連付けられている（紐付けられている）応答時間の平均から通知情報の送信順序を決定し、当該順序に従って、通知情報を送信している、といえる。
【００２６】
送信日時更新部２０は、宛先テーブル５４の送信日時を通知送信部１８が通知情報を送信した時刻（現在の時刻）で更新するとともに、送信中フラグをセット（フラグ＝１）する。
【００２７】
受信処理部６０は、受信部としての確認応答受信部３２と、応答時間算出部３４と、時間帯取得部としての時間帯判定部３６と、応答時間・平均値更新部３８と、を有する。なお応答時間算出部３４と、応答時間・平均値更新部３８とを含んで、関連付け部が実現されている。
【００２８】
確認応答受信部３２は、通知情報を受信した端末８０から送信されてくる確認応答を受信する。応答時間算出部３４は、通知送信部１８が通知情報を送信してから、確認応答受信部３２が確認応答を受信するまでに要した時間（応答時間）を算出する。時間帯判定部３６は、時間帯テーブル５２に基づいて、通知送信部１８が通知情報を送信した時刻の時間帯を判定する。
【００２９】
応答時間・平均値更新部３８は、時間帯判定部３６で判定された時間帯の応答時間のデータを、応答時間算出部３４で算出された応答時間で更新する。また、応答時間・平均値更新部３８は、今回の応答時間（図５では「前回」の時間）と、その前の応答時間（図５では「前々回」の時間）との平均を算出し、宛先テーブル５４を更新する。
【００３０】
次に、災害通知サーバ１０で実行される処理の詳細について、図６〜図８のフローチャートに沿って説明する。なお、図６〜図８の各処理は、同時並行的に行われる。
【００３１】
（送信処理部５０の処理）
まず、送信処理部５０の処理について、図６に基づいて説明する。図６は、送信処理部５０が実行する処理を示すフローチャートである。この図６の処理では、ステップＳ１０において、事象受信部１２が、通知対象の事象を受信するまで待機する。ここでは、事象受信部１２が、事象検知装置７０から送信されてくる通知対象の事象（地震や大雨などの情報）を受信した段階で、ステップＳ１２に移行する。
【００３２】
ステップＳ１２では、時間帯判定部１４が、現在日時を含む時間帯を判定する。すなわち、時間帯判定部１４は、現在日時を含む時間帯を時間帯テーブル５２から取得して対象時間帯とする。例えば、現在日時が月曜日の１１時であった場合には、時間帯判定部１４は、図４の時間帯テーブル５２を参照して、時間帯１を対象時間帯とする。
【００３３】
次いで、ステップＳ１４では、宛先取得部１６が、対象時間帯における平均応答時間が短い順というソート条件を指定して、宛先テーブル５４からすべての宛先を一括して取得する。すなわち、例えば対象時間帯が時間帯１である場合には、宛先取得部１６は、図５の宛先テーブル５４を、時間帯１の「平均」の行の値が小さい順になるように並べ替えて、全ての宛先を取得する。
【００３４】
次いで、ステップＳ１６では、通知送信部１８が、取得した宛先全てに対して通知情報（通知対象の事象に関する情報）を送信したか否かを判断する。ここでは、全ての宛先への通知情報の送信が完了し、ステップＳ１６の判断が肯定された場合には、図６の全処理を終了する。一方、全ての宛先に通知情報を送信していない場合には、ステップＳ１６の判断が否定されて、ステップＳ１８に移行する。
【００３５】
ステップＳ１８に移行した場合、通知送信部１８は、取得した宛先のうち、未送信で取得順が最も前の宛先に通知情報を送信する。すなわち、未送信の宛先のうち、平均応答時間が最も短い宛先に対して通知情報を送信する。
【００３６】
次いで、ステップＳ２０では、送信日時更新部２０が、宛先テーブル５４のうち、今回送信した宛先（宛先レコード）の送信日時を、現在日時で更新するとともに、送信中フラグをセットする（フラグ＝１）。ステップＳ２０の処理が終了した後は、ステップＳ１６に戻る。そして、ステップＳ１６の判断が肯定された段階で、図６の全処理が終了する。なお、図６の処理は、その後も繰り返し実行される。
【００３７】
（受信処理部６０の処理）
次に、図７に基づいて、受信処理部６０の処理について説明する。図７は、受信処理部６０が実行する処理を示すフローチャートである。
【００３８】
図７の処理では、まず、ステップＳ３０において、確認応答受信部３２が、端末８０から送信されてくる確認応答を受信するまで待機する。確認応答受信部３２は、確認応答を受信すると、ステップＳ３２に移行する。
【００３９】
ステップＳ３２では、応答時間算出部３４が、現在日時を確認日時とする。次いで、ステップＳ３４では、応答時間算出部３４が、確認応答を受信した宛先の送信日時を宛先テーブルから取得する。
【００４０】
次いで、ステップＳ３６では、時間帯判定部３６が、送信日時を含む時間帯を時間帯テーブル５２に基づいて判定する。すなわち、時間帯判定部３６は、時間帯テーブル５２を参照して、送信日時を含む時間帯を取得する。そして、時間帯判定部３６は、取得した時間帯を、対象時間帯とする。次いで、ステップＳ３８では、応答時間算出部３４が、送信日時と確認日時との差を求めて応答時間とする。応答時間算出部３４は、算出した応答時間を、応答時間・平均値更新部３８に送信する。
【００４１】
次いで、ステップＳ４０では、応答時間・平均値更新部３８が、宛先テーブルの、確認応答を受信した宛先の対象時間帯における前回応答時間として、ステップＳ３８で算出した応答時間をセットする。なお、ステップＳ４０を行う以前において、宛先テーブル５４の前回応答時間にセットされていた時間は、ステップＳ４０の際に前々回応答時間として新たにセットされるものとする。
【００４２】
次いで、ステップＳ４２では、応答時間・平均値更新部３８が、確認応答を受信した宛先の対象時間帯における前回応答時間と前々回応答時間の平均値を算出し、宛先テーブル５４の対象時間帯における「平均」の項目を更新する。
【００４３】
次いで、ステップＳ４４では、応答時間・平均値更新部３８が、宛先テーブル５４の、今回受信した宛先の送信中フラグをリセットする（フラグ＝０）。ステップＳ４４までの処理が終了すると、図７の全処理が終了することになる。なお、図７の処理は、その後も繰り返し実行される。
【００４４】
（未処理レコード処理部４０の処理）
次に、未処理レコード処理部４０の処理について、図８に基づいて説明する。図８は、未処理レコード処理部４０が実行する処理を示すフローチャートである。
【００４５】
図８の処理では、ステップＳ５０において、未処理レコード処理部４０が、所定時間経過したか否かを判断する。このステップＳ５０は、ステップＳ５２以降の処理を所定時間ごとに行うために必要なステップである。
【００４６】
所定時間が経過し、ステップＳ５２に移行すると、未処理レコード処理部４０は、送信中フラグがセットされているレコード（フラグが１であるレコード）を宛先テーブル５４から取得する。次いで、ステップＳ５４では、未処理レコード処理部４０が、取得したレコードの処理が全て終了したか否かを判断する。このステップＳ５４の判断が肯定された場合には、図８の全処理を終了する。一方、ステップＳ５４の判断が否定された場合には、ステップＳ５６に移行する。
【００４７】
ステップＳ５６に移行すると、未処理レコード処理部４０は、取得したレコードのうちの１つ（例えば最上段のレコード）に着目する。次いで、ステップＳ５８では、未処理レコード処理部４０が、着目したレコードの送信日時から一定時間以上経過しているか否かを判断する。ここでの判断が肯定されると、ステップＳ６０に移行する。
【００４８】
ステップＳ６０では、未処理レコード処理部４０が、着目したレコードの送信日時が属する時間帯を時間帯テーブル５２から取得して、対象時間帯とする。次いで、ステップＳ６２では、未処理レコード処理部４０が、着目したレコードの対象時間帯の前回応答時間として所定のみなし応答時間（例えば半日程度）を、宛先テーブル５４にセットする。次いで、ステップＳ６４では、未処理レコード処理部４０が、着目したレコードの対象時間帯における前回応答時間と前々回応答時間の平均値を算出して、宛先テーブル５４を更新する。そして、ステップＳ６６では、未処理レコード処理部４０が、宛先テーブル５４の、着目したレコードの送信フラグをリセットする（フラグ＝０）。なお、災害通知サーバ１０から情報が送信されてから、端末８０から確認応答が出されるまでに長時間を要する場合に、上記のようにみなし応答時間をセットするのは、応答時間が長時間更新されないと、その後の処理に影響が生じる可能性があるからである。
【００４９】
その後は、ステップＳ５４に戻り、未処理レコード処理部４０は、ステップＳ３４で取得したレコードの処理が全て終了したか否かを判断する。ここでの判断が否定された場合には、ステップＳ５６に移行し、取得したレコードのうち、これまでに着目していないレコードに着目する。その後は、ステップＳ５８に移行する。
【００５０】
なお、ステップＳ５８の判断が否定された場合には、着目しているレコードに対する処理を何も行わずに、ステップＳ５４に戻る。
【００５１】
そして、ステップＳ５４の判断が肯定された段階で、図８の全処理を終了する。なお、図８の処理は、その後も繰り返し実行される。
【００５２】
以上、詳細に説明したように、本実施形態によると、通知送信部１８が、宛先テーブル５４に登録されている複数の端末８０に対して通知情報を送信し、確認応答受信部３２が、通知情報を受信した端末８０から送信される受信応答を受信する。また、応答時間算出部３４が、通知送信部１８が通知情報を送信してから確認応答受信部３２が受信応答を受信するまでの応答時間を算出し、応答時間・平均値更新部３８が、当該応答時間及びそれ以前の応答時間の平均値で、宛先テーブル５４を更新する。そして、通知送信部１８は、宛先テーブル５４の応答時間の平均値に基づいて通知情報を送信する端末の送信順位を決定する、すなわち過去における応答時間が早い端末に対して、他の端末よりも優先して通知情報を送信する。ここで、過去に通知情報が送信されたときの端末の応答時間が短いほど、当該端末の利用者は、通知情報を必要としている人である可能性が高い。したがって、本実施形態では、過去に通知情報が送信されたときの端末の応答時間を考慮することで、通知情報を必要とする利用者の端末に対して、優先的に通知情報を送信することが可能となる。これにより、例えば、自治体の災害対策業務の担当者は、通知情報に対する応答時間が、他の人に比べて早いと考えられるが、このような担当者に対して早めに通知情報を送信することができるようになる。このため、災害対策の初動時間を短縮することが可能となる。
【００５３】
また、本実施形態によると、時間帯判定部３６が、通知送信部１８が通知情報を送信した時刻が含まれる時間帯を取得し、応答時間・平均値更新部３８は、取得された時間帯ごとに、応答時間を、宛先テーブル５４に登録する。そして、宛先取得部１６は、通知情報を送信する時刻が含まれる時間帯における応答時間に基づいて、端末８０に対する通知情報の送信順序を決定する。これにより、曜日や時間帯ごとに通知情報の必要性が変化する場合であっても、適切な送信順序で端末に対して通知情報を送信することができる。
【００５４】
なお、上記実施形態では、時間帯テーブル５２の時間帯を、図４のように、曜日と時刻とで定義する場合について説明したが、これに限られるものではない。例えば、平日の昼間と、その他の時間帯というように定義してもよい。あるいは、時刻のみで定義することとしてもよい。なお、上記実施形態では、時間帯を考慮して、通知情報の送信順序を決定する場合について説明したが、これに限らず、時間帯を考慮しなくてもよい。この場合、上記実施形態の時間帯に関する部分（時間帯判定部１４、３６、時間帯テーブル５２、宛先テーブル５４の時間帯ごとの応答時間管理など）を省略することができる。
【００５５】
なお、上記実施形態では、宛先テーブル５４において、応答時間の平均を、前回応答時間と前々回応答時間の平均とすることとしたが、これに限られるものではない。例えば、災害通知サーバ１０の稼動後の全応答時間の平均を用いてもよい。また、平均値として重み付け平均値を用いることとしても良い。この場合、例えば、現在に近い応答時間ほど、重みを大きくするなどすることができる。更には、平均を求めずに、前回応答時間のみを宛先テーブル５４に登録しておき、当該前回応答時間に基づいて、通知情報を送信する端末の順序を決定することとしてもよい。
【００５６】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。
【００５７】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【００５８】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【００５９】
上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
【００６０】
なお、以上の説明に関して更に以下の付記を開示する。
（付記１） 通知情報の送信先である複数の端末を登録したデータを格納する格納部と、前記登録された複数の端末に対して通知情報を送信する送信部と、前記通知情報を受信した端末から送信される受信応答を受信する受信部と、前記複数の端末のいずれかに対して前記送信部が前記通知情報を送信してから、前記受信部が前記受信応答を受信するまでの時間を取得し、前記データのうち、前記送信部が前記通知情報を送信した端末に対して、前記取得した時間に基づく時間情報を関連付ける関連付け部と、を備え、前記送信部は、各端末に関連付けられている前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする通知情報送信装置。
（付記２） 前記送信部が前記通知情報を送信した時刻が含まれる時間帯を取得する時間帯取得部を更に備え、前記関連付け部は、前記時間帯取得部により取得された時間帯ごとに、前記時間情報を、前記送信部が前記通知情報を送信した端末に関連付け、前記送信部は、前記通知情報を送信する時刻が含まれる時間帯における、前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする付記１に記載の通知情報送信装置。
（付記３） 前記時間情報は、前記送信部が前記通知情報を送信してから、前記受信部が前記受信応答を受信するまでの時間の平均値であり、前記送信部は、前記平均値が小さい端末ほど、前記情報を送信する順序を早くすることを特徴とする付記１又は２に記載の通知情報送信装置。
（付記４） 登録された複数の端末に対して通知情報を送信し、前記通知情報を受信した端末から送信される受信応答を受信し、前記複数の端末のいずれかに対して前記通知情報を送信してから、前記受信応答を受信するまでの時間を取得し、前記複数の端末が登録されているデータのうち、前記通知情報を送信した端末に対して、前記取得した時間に基づく時間情報を関連付ける処理、をコンピュータに実行させ、
前記送信する処理では、各端末に関連付けられている前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする通知情報送信プログラム。
（付記５） 前記コンピュータに、前記通知情報を送信した時刻が含まれる時間帯を取得する処理を更に実行させ、前記関連付ける処理では、前記時間帯ごとに、前記時間情報を、前記通知情報を送信した端末に関連付け、前記送信する処理では、前記通知情報を送信する時刻が含まれる時間帯における、前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする付記４に記載の通知情報送信プログラム。
（付記６） 前記時間情報は、前記通知情報を送信してから、前記受信応答を受信するまでの時間の平均値であり、前記送信する処理では、前記平均値が小さい端末ほど、前記情報を送信する順序を早くすることを特徴とする付記４又は５に記載の通知情報送信プログラム。
（付記７） 登録された複数の端末に対して通知情報を送信する送信工程と、前記通知情報を受信した端末から送信される受信応答を受信する受信工程と、前記複数の端末のいずれかに対して前記通知情報を送信してから、前記受信応答を受信するまでの時間を取得し、前記複数の端末が登録されているデータのうち、前記通知情報を送信した端末に対して、前記取得した時間に基づく時間情報を関連付ける関連付け工程と、をコンピュータが実行し、前記送信工程では、各端末に関連付けられている前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする通知情報送信方法。
（付記８） 前記コンピュータが、前記通知情報を送信した時刻が含まれる時間帯を取得する時間帯取得工程を更に実行し、前記関連付け工程では、前記時間帯ごとに、前記時間情報を、前記通知情報を送信した端末に関連付け、前記送信する処理では、前記通知情報を送信する時刻が含まれる時間帯における、前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする付記７に記載の通知情報送信方法。
（付記９） 前記時間情報は、前記通知情報を送信してから、前記受信応答を受信するまでの時間の平均値であり、前記送信工程では、前記平均値が小さい端末ほど、前記情報を送信する順序を早くすることを特徴とする付記７又は８に記載の通知情報送信方法。
【符号の説明】
【００６１】
１８ 通知送信部（送信部）
３２ 確認応答受信部（受信部）
３４ 応答時間算出部（関連付け部の一部）
３６ 時間帯判定部（時間帯取得部）
３８ 応答時間・平均値更新部（関連付け部の一部）
５４ 宛先テーブル（格納部）
【特許請求の範囲】
【請求項１】
通知情報の送信先である複数の端末を登録したデータを格納する格納部と、
前記登録された複数の端末に対して通知情報を送信する送信部と、
前記通知情報を受信した端末から送信される受信応答を受信する受信部と、
前記複数の端末のいずれかに対して前記送信部が前記通知情報を送信してから、前記受信部が前記受信応答を受信するまでの時間を取得し、前記データのうち、前記送信部が前記通知情報を送信した端末に対して、前記取得した時間に基づく時間情報を関連付ける関連付け部と、を備え、
前記送信部は、各端末に関連付けられている前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする通知情報送信装置。
【請求項２】
前記送信部が前記通知情報を送信した時刻が含まれる時間帯を取得する時間帯取得部を更に備え、
前記関連付け部は、前記時間帯取得部により取得された時間帯ごとに、前記時間情報を、前記送信部が前記通知情報を送信した端末に関連付け、
前記送信部は、前記通知情報を送信する時刻が含まれる時間帯における前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする請求項１に記載の通知情報送信装置。
【請求項３】
前記時間情報は、前記送信部が前記通知情報を送信してから、前記受信部が前記受信応答を受信するまでの時間の平均値であり、
前記送信部は、前記平均値が小さい端末ほど、前記情報を送信する順序を早くすることを特徴とする請求項１又は２に記載の通知情報送信装置。
【請求項４】
登録された複数の端末に対して通知情報を送信し、
前記通知情報を受信した端末から送信される受信応答を受信し、
前記複数の端末のいずれかに対して前記通知情報を送信してから、前記受信応答を受信するまでの時間を取得し、前記複数の端末が登録されているデータのうち、前記通知情報を送信した端末に対して、前記取得した時間に基づく時間情報を関連付ける処理、をコンピュータに実行させ、
前記送信する処理では、各端末に関連付けられている前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする通知情報送信プログラム。
【請求項５】
登録された複数の端末に対して通知情報を送信する送信工程と、
前記通知情報を受信した端末から送信される受信応答を受信する受信工程と、
前記複数の端末のいずれかに対して前記通知情報を送信してから、前記受信応答を受信するまでの時間を取得し、前記複数の端末が登録されているデータのうち、前記通知情報を送信した端末に対して、前記取得した時間に基づく時間情報を関連付ける関連付け工程と、をコンピュータが実行し、
前記送信工程では、各端末に関連付けられている前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする通知情報送信方法。
【請求項１】
通知情報の送信先である複数の端末を登録したデータを格納する格納部と、
前記登録された複数の端末に対して通知情報を送信する送信部と、
前記通知情報を受信した端末から送信される受信応答を受信する受信部と、
前記複数の端末のいずれかに対して前記送信部が前記通知情報を送信してから、前記受信部が前記受信応答を受信するまでの時間を取得し、前記データのうち、前記送信部が前記通知情報を送信した端末に対して、前記取得した時間に基づく時間情報を関連付ける関連付け部と、を備え、
前記送信部は、各端末に関連付けられている前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする通知情報送信装置。
【請求項２】
前記送信部が前記通知情報を送信した時刻が含まれる時間帯を取得する時間帯取得部を更に備え、
前記関連付け部は、前記時間帯取得部により取得された時間帯ごとに、前記時間情報を、前記送信部が前記通知情報を送信した端末に関連付け、
前記送信部は、前記通知情報を送信する時刻が含まれる時間帯における前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする請求項１に記載の通知情報送信装置。
【請求項３】
前記時間情報は、前記送信部が前記通知情報を送信してから、前記受信部が前記受信応答を受信するまでの時間の平均値であり、
前記送信部は、前記平均値が小さい端末ほど、前記情報を送信する順序を早くすることを特徴とする請求項１又は２に記載の通知情報送信装置。
【請求項４】
登録された複数の端末に対して通知情報を送信し、
前記通知情報を受信した端末から送信される受信応答を受信し、
前記複数の端末のいずれかに対して前記通知情報を送信してから、前記受信応答を受信するまでの時間を取得し、前記複数の端末が登録されているデータのうち、前記通知情報を送信した端末に対して、前記取得した時間に基づく時間情報を関連付ける処理、をコンピュータに実行させ、
前記送信する処理では、各端末に関連付けられている前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする通知情報送信プログラム。
【請求項５】
登録された複数の端末に対して通知情報を送信する送信工程と、
前記通知情報を受信した端末から送信される受信応答を受信する受信工程と、
前記複数の端末のいずれかに対して前記通知情報を送信してから、前記受信応答を受信するまでの時間を取得し、前記複数の端末が登録されているデータのうち、前記通知情報を送信した端末に対して、前記取得した時間に基づく時間情報を関連付ける関連付け工程と、をコンピュータが実行し、
前記送信工程では、各端末に関連付けられている前記時間情報に基づいて、前記複数の端末に対する前記通知情報の送信順序を決定することを特徴とする通知情報送信方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１２−１１８７０７（Ｐ２０１２−１１８７０７Ａ）
【公開日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願番号】特願２０１０−２６７１５５（Ｐ２０１０−２６７１５５）
【出願日】平成２２年１１月３０日（２０１０．１１．３０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願日】平成２２年１１月３０日（２０１０．１１．３０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]