JP6816633B2 - 制御プログラム、制御方法及び制御装置 - Google Patents

Description

本発明は、制御プログラム、制御方法及び制御装置に関する。

各種の情報源から提供される災害情報を端末装置に通知する災害情報システムが知られている。例えば、災害情報は、災害が検知された時点から第１報、第２報、・・・、最終報の順に情報源により更新される。これにより、先行して通知される災害情報の精度が後続して通知される災害情報により補われる。このため、端末装置は、第１報が通知された後にも、端末装置に設定された周期にしたがって最新の災害情報を災害情報システムにリクエストする。

特開２００４−５４５７９号公報 特開２００６−２４４３３６号公報

しかしながら、上記の技術では、災害発生時の通信トラフィックの増大を抑制できない場合がある。

すなわち、端末装置が災害情報のリクエストを行う周期は、端末装置のユーザの設定に委ねられる。このため、ネットワーク上の通信トラフィックとは無関係に災害情報のリクエストが行われることになる。それ故、災害情報のリクエスト、ひいては災害情報のダウンロードが短期に集中する。この結果、災害発生時の通信トラフィックが増大し、ネットワークが輻輳状態に陥る場合がある。

１つの側面では、本発明は、災害発生時の通信トラフィックの増大を抑制できる制御プログラム、制御方法及び制御装置を提供することを目的とする。

一態様では、制御プログラムは、災害情報を取得し、災害の規模と端末装置に災害情報のリクエストを実行させる周期とが対応付けられた周期データを参照して、取得した災害情報により定まる災害の規模に対応する周期を前記災害情報のリクエストを行う端末装置に設定する、処理をコンピュータに実行させる。

災害発生時の通信トラフィックの増大を抑制できる。

図１は、実施例１に係る災害情報システムの構成例を示す図である。 図２は、実施例１に係るサーバ装置の機能的構成を示すブロック図である。 図３は、周期データの一例を示す図である。 図４は、ネットワーク使用率と補正値の対応関係の一例を示す図である。 図５は、ＣＰＵ使用率と補正値の対応関係の一例を示す図である。 図６は、メモリ使用率と補正値の対応関係の一例を示す図である。 図７は、データベースコネクション使用率と補正値の対応関係の一例を示す図である。 図８は、ストレージアクセス使用率と補正値の対応関係の一例を示す図である。 図９は、実施例１に係る周期決定処理の手順を示すフローチャートである。 図１０は、実施例１に係る通知処理の手順を示すフローチャートである。 図１１は、実施例１及び実施例２に係る制御プログラムを実行するコンピュータのハードウェア構成例を示す図である。

以下に添付図面を参照して本願に係る制御プログラム、制御方法及び制御装置について説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

図１は、実施例１に係る災害情報システムの構成例を示す図である。図１に示す災害情報システム１は、災害情報をクライアント端末３０Ａ〜３０Ｃに通知する災害情報の通知サービスを提供するものである。

このような通知サービスを実施する環境下で、災害情報システム１は、一側面として、災害の規模ごとにクライアント端末３０Ａ〜３０Ｃに災害情報をリクエストさせる周期が定められた周期データを参照して、発生した災害の規模に対応する周期をリクエストを行うクライアント端末に設定する制御を実現する。これにより、災害発生時の通信トラフィックの増大を抑制する。

図１に示すように、災害情報システム１には、サーバ装置１０と、情報源装置２０と、クライアント端末３０Ａ〜３０Ｃとが含まれる。以下では、クライアント端末３０Ａ〜３０Ｃのことを「クライアント端末３０」と記載する場合がある。

これらサーバ装置１０、情報源装置２０及びクライアント端末３０の間は、所定のネットワークＮＷを介して接続される。このネットワークＮＷは、有線または無線を問わず、インターネット、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の種類の通信網により構築することができる。

サーバ装置１０は、上記の災害情報の通知サービスを提供するコンピュータである。このサーバ装置１０は、制御装置の一例である。

一実施形態として、サーバ装置１０は、パッケージソフトウェア又はオンラインソフトウェアとして、上記の通知サービスを含む機能を実現する制御プログラムを所望のコンピュータにインストールさせることによって実装できる。例えば、サーバ装置１０は、上記の通知サービスを提供するＷｅｂサーバとして実装することとしてもよいし、アウトソーシングによって上記の通知サービスを提供するクラウドとして実装することとしてもかまわない。

ここでは、あくまで一例として、クライアント端末３０に災害情報を通知する通知機能およびクライアント端末３０に災害情報のリクエストの周期を設定する設定機能をサーバ装置１０が併せ持つ場合を例示するが、実装はこれに限定されない。例えば、通知機能および設定機能ごとにハードウェアを分散して設けることもできれば、通知機能および設定機能ごとに仮想マシンを１又は複数の物理マシン上で動作させることにより、災害情報システム１を実装できる。

情報源装置２０は、災害情報の情報源が災害情報の提供に用いる装置である。ここで言う「情報源」とは、サーバ装置１０の事業者に対する情報源を指す。例えば、災害が地震である場合、緊急地震速報などの災害情報を配信する気象庁などが情報源に該当する。この情報源は狭義の情報源を意味せず、必ずしも災害情報の一次ソースでなくともよい。例えば、ポータルサイトなどの二次ソース以降の情報源を本実施例で言う「情報源」とすることもできる。

ここで、情報源装置２０からサーバ装置１０への災害情報の通知には、任意の通信形態を採用することができる。例えば、災害が地震である場合、緊急地震速報などの既存の情報提供の仕組みを利用できる。この情報提供の仕組みの一例として、情報源が発行するアカウントを持つユーザに対し、災害情報がＸＭＬ（Extensible Markup Language）のフォーマットで記述された電子メールを配信する仕組みがある。この仕組みを利用し、サーバ装置１０の事業者がアカウント登録を行うことにより、情報源装置２０からサーバ装置１０への災害情報の通知を実現することができる。

クライアント端末３０は、上記の災害情報の通知サービスの提供を受けるコンピュータである。

一実施形態として、クライアント端末３０には、スマートフォン、携帯電話機やＰＨＳ（Personal Handyphone System）などの移動体通信端末のみならず、タブレット端末やスレート端末などが対応する。このようにハンドヘルド型の携帯端末装置に限定されず、ヘッドマウントディスプレイ、スマートグラスやスマートウォッチなどのウェアラブルデバイスの他、あらゆるＩｏＴ（Internet of Things）デバイスがクライアント端末３０対応する。なお、ここでは、あくまで携帯端末装置の例を挙げたが、クライアント端末３０は、ノート型またはラックトップ型の情報処理装置、例えばパーソナルコンピュータ等であってもかまわない。

例えば、クライアント端末３０では、クライアント端末３０にインストールされた防災用のアプリケーションプログラムやブラウザなどのフロントエンドを通じて、サーバ装置１０から災害情報が通知される。以下では、防災用のアプリケーションプログラムのことを「防災Ａｐｐ」と略記する場合がある。

［サーバ装置１０の構成］
次に、本実施例に係るサーバ装置１０の機能的構成について説明する。図２は、実施例１に係るサーバ装置１０の機能的構成を示すブロック図である。図２には、データの入出力の関係を表す実線が示されているが、これは、説明の便宜上、上記の通知機能および上記の設定機能に関する一部について示されているに過ぎない。すなわち、各機能部に関するデータの入出力は、図示の例に限定されず、図示以外のデータの入出力、例えば機能部及び機能部の間、機能部及びデータの間、並びに、機能部及び外部装置の間のデータの入出力が行われることとしてもかまわない。また、図２には、上記の通知機能および上記の設定機能に関連する機能部が抜粋して示されているに過ぎず、既存のコンピュータが有する機能部であれば、図示以外の機能部がサーバ装置１０に備わることを妨げない。例えば、入力デバイス、表示デバイスや音声出力デバイスなどのハードウェアに対応する機能部がサーバ装置１０に備わってもよい。これら既存のコンピュータが有する汎用の機能部の中には図示が省略されているものもあるが、上記の通知機能および上記の設定機能を実現する上で有用である機能部は図示が省略されたとしてもサーバ装置１０に備わることは妨げない。

図２に示すように、サーバ装置１０は、通信Ｉ／Ｆ（InterFace）部１１と、記憶部１３と、制御部１５とを有する。

通信Ｉ／Ｆ部１１は、他の装置との間で通信制御を行うインタフェースである。

一実施形態として、通信Ｉ／Ｆ部１１には、ＬＡＮカードなどのネットワークインタフェースカードが対応する。例えば、通信Ｉ／Ｆ部１１は、情報源装置２０から災害情報を受信する。また、通信Ｉ／Ｆ部１１は、クライアント端末３０から災害情報のリクエストを受信したり、また、災害情報や災害情報をリクエストする周期の設定などをクライアント端末３０へ送信したりする。

記憶部１３は、制御部１５で実行されるＯＳ（Operating System）を始め、上記の通知機能や設定機能を実現する制御プログラムなどの各種プログラムに用いられるデータを記憶する記憶デバイスである。

一実施形態として、記憶部１３は、サーバ装置１０における補助記憶装置として実装される。例えば、補助記憶装置には、ＨＤＤ（Hard Disk Drive）、光ディスクやＳＳＤ（Solid State Drive）などが対応する。この他、ＥＰＲＯＭ（Erasable Programmable Read Only Memory)などのフラッシュメモリも補助記憶装置に対応する。

記憶部１３は、制御部１５で実行されるプログラムに用いられるデータの一例として、災害情報１３ａと、周期データ１３ｂとを記憶する。この災害情報１３ａ及び周期データ１３ｂ以外にも、他の電子データを記憶することもできる。例えば、記憶部１３には、上記の通知サービスの提供を受けるユーザのアカウント情報を始め、クライアント端末３０にダウンロードさせる防災用のアプリケーションプログラムなどを記憶することができる。なお、災害情報１３ａ及び周期データ１３ｂの説明は、実際に記憶部１３からデータの登録または参照が実行される機能部の説明と併せて行うこととする。

制御部１５は、サーバ装置１０の全体制御を行う処理部である。

一実施形態として、制御部１５は、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などのハードウェアプロセッサにより実装することができる。ここでは、プロセッサの一例として、ＣＰＵやＭＰＵを例示したが、汎用型および特化型を問わず、任意のプロセッサにより実装することができる。この他、制御部１５は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などのハードワイヤードロジックによって実現されることとしてもかまわない。

制御部１５は、図示しない主記憶装置として実装されるＤＲＡＭ（Dynamic Random Access Memory）やＳＲＡＭ（Static Random Access Memory）などのＲＡＭのワークエリア上に、上記の視点選択支援機能を実現する視点選択支援プログラムを展開することにより、下記の処理部を仮想的に実現する。

制御部１５は、図２に示すように、取得部１５ａと、算出部１５ｂと、決定部１５ｃと、補正部１５ｄと、受付部１５ｅと、通知部１５ｆと、設定部１５ｇとを有する。

取得部１５ａは、災害情報を取得する処理部である。

一実施形態として、取得部１５ａは、情報源装置２０からネットワークＮＷを介して災害情報を取得する。例えば、災害が地震である場合、取得部１５ａは、緊急地震速報の電子メールを受信することにより、当該電子メールに記述されたコンテンツを災害情報として取得することができる。このように情報源装置２０から取得される災害情報には、震度速報、震源・震度に関する情報および各地の震度に関する情報のうち少なくともいずれか１つが含まれる。さらに、取得部１５ａは、地震が検知された時点から順に第１報、第２報、・・・、最終報の災害情報を時間経過にしたがって取得することができる。このように災害情報が取得された場合、取得部１５ａは、当該災害情報を記憶部１３に登録すると共に、当該災害情報を算出部１５ｂへ出力する。

算出部１５ｂは、取得部１５ａにより取得された災害情報に基づいて災害の規模を算出する処理部である。以下では、一例として、災害が地震である場合を想定して災害の規模の算出について説明する。

一側面として、算出部１５ｂは、取得部１５ａにより取得された災害情報に含まれる被災レベルのうち最高の被災レベルに基づいて災害の規模を算出する。例えば、災害が地震である場合、震度などの被災レベルが所定値、例えば「３」以上である被災地を含む災害情報が取得部１５ａにより取得される。この災害情報を利用して、算出部１５ｂは、被災地で観測された震度のうち最高震度を地震の規模として算出する。なお、ここでは、一例として、最高震度のそのものを地震の規模として導出する場合を例示したが、任意の統計手法にしたがって最高震度を正規化することにより指標として算出することもできる。

他の側面として、算出部１５ｂは、取得部１５ａにより取得された災害情報に含まれる被災地の人口密度に基づいて災害の規模を算出することもできる。例えば、災害が地震である場合、震度などの被災レベルが所定値、例えば「３」以上である被災地を含む災害情報が取得部１５ａにより取得される。この被災地の地域を識別する区分は、情報源により予め公開されている。このため、被災地ごとに当該被災地の人口密度が対応付けられた人口密度データを準備しておくことができる。この人口密度データを参照して、算出部１５ｂは、災害情報に含まれる被災地ごとに当該被災地に対応する人口密度を検索する。そして、算出部１５ｂは、被災地ごとに検索された人口密度を合計することにより求まる被災人口を地震の規模として算出する。なお、ここでは、一例として、被災人口のそのものを地震の規模として導出する場合を例示したが、任意の統計手法にしたがって正規化することにより指標として算出することもできる。例えば、被災人口を被災地の地域の総数で除算することにより正規化することができる。これにより、過去の地震との間で被災人口の比較が容易になる。

更なる側面として、算出部１５ｂは、被災地の人口密度に当該被災地で観測される被災レベル度を重みとして付与する重み付けを行うことにより、災害の規模を算出することもできる。例えば、算出部１５ｂは、被災地ごとに検索された人口密度に当該被災地で観測された震度を重みとして付与する。その上で、算出部１５ｂは、被災地ごとに重み付けが行われた人口密度を合計することにより、地震の規模を算出することができる。なお、ここでは、一例として、重み付けが行われた人口密度の合計そのものを地震の規模として導出する場合を例示したが、任意の統計手法にしたがって正規化することにより指標として算出することもできる。例えば、重み付けが行われた人口密度の合計を被災地の地域の総数で除算することにより正規化することができる。これにより、過去の地震との間で数値の比較が容易になる。

決定部１５ｃは、算出部１５ｂにより算出された災害の規模に対応する周期を決定する処理部である。

一実施形態として、決定部１５ｃは、災害の規模とクライアント端末３０に災害情報のリクエストを実行させる周期とが対応付けられた周期データ１３ｂを参照することにより、クライアント端末３０が災害情報をサーバ装置１０にリクエストする周期を決定する。図３は、周期データ１３ｂの一例を示す図である。図３には、災害の規模が最高震度で表される場合が示されている。図３に示す周期データ１３ｂの例で言えば、算出部１５ｂにより算出された最高震度が「７」である場合、クライアント端末３０が３００秒の周期で災害情報のリクエストをサーバ装置１０に行う設定が実施されることを意味する。また、算出部１５ｂにより算出された最高震度が「６」である場合、クライアント端末３０が２４０秒の周期で災害情報のリクエストをサーバ装置１０に行う設定が実施されることを意味する。この他の災害の規模においても、クライアント端末３０に設定される周期の値が異なる他は同様の認識をコンピュータに行わせることができる。このような周期データ１３ｂを参照して、決定部１５ｃは、算出部１５ｂにより災害情報から算出された災害の規模に対応する周期をクライアント端末３０のリクエストの周期の設定時に後述の設定部１５ｅにより参照される内部メモリのワークエリアに保存する。以下では、決定部１５ｃにより決定された周期のことを後述の補正部１５ｄにより補正された周期との間で区別する観点から「周期の基本値」と記載する場合がある。

なお、上記の周期の決定は、必ずしも災害情報が取得される度に実行されずともかまわない。すなわち、第１報の災害情報が後続の災害情報よりも精度が劣る傾向があるとは言え、的外れなほどの精度の違いが生じるケースは少ないと考えられる。このため、第１報の災害情報が取得された場合に絞って周期の決定を実施することも一案とすることができる。

補正部１５ｄは、クライアント端末３０に災害情報のリクエストを実行させる周期を補正する処理部である。

一実施形態として、補正部１５ｄは、決定部１５ｃにより内部メモリのワークエリアに周期が保存された後、最終報の災害情報が取得してから所定の期間が経過するまで、サーバ装置１０の処理負荷に基づいて上記の内部メモリのワークエリアに保存された周期を補正する処理を繰り返して実行する。例えば、補正部１５ｄは、サーバ装置１０の処理負荷として、ネットワークの使用率、ＣＰＵの使用率、メモリの使用率、データベースコネクションの数およびストレージへのアクセス数を計測する。そして、補正部１５ｄは、ネットワークの使用率、ＣＰＵの使用率、メモリの使用率、データベースコネクションの数およびストレージへのアクセス数の５項目うち負荷が最高である項目を選択する。その上で、補正部１５ｄは、負荷が最高である項目の数値に応じて上記の内部メモリのワークエリアに保存された周期を補正する。例えば、負荷が最高である項目の数値が高いほど、上記の内部メモリのワークエリアに保存された周期の値を大きい値に補正される一方で、負荷が最高である項目の数値が低いほど、上記の内部メモリのワークエリアに保存された周期の値を小さい値に補正される。

図４は、ネットワーク使用率と補正値の対応関係の一例を示す図である。図４には、一例として、ネットワーク使用率に関するルックアップテーブルが示されている。例えば、負荷が最高である項目がネットワーク使用率である場合、図４に示すルックアップテーブルを参照してネットワーク使用率に対応する補正値が決定される。このルックアップテーブルは、補正値の算出式「補正値（秒）＝ネットワーク使用率の計測値（％）−５０」にしたがって補正値が設定されている。

図４に示すルックアップテーブルを参照して補正を行う場合、ネットワーク使用率５０％に対応する補正値は０％である。この場合、上記の内部メモリのワークエリアに保存された周期には０％が加算されるので、ネットワーク使用率が５０％である場合、実質的には周期の数値は補正後も変わらない。また、ネットワーク使用率が５０％から１０％下がる度に、上記の内部メモリのワークエリアに保存された周期から減算される補正値も１０秒ずつ増加する。すなわち、ネットワーク使用率が４０％であれば上記の内部メモリのワークエリアに保存された周期から１０秒減算される。また、ネットワーク使用率が３０％であれば上記の内部メモリのワークエリアに保存された周期から２０秒減算される。最終的に、ネットワーク使用率が０％であれば上記の内部メモリのワークエリアに保存された周期から５０秒減算される。一方、ネットワーク使用率が５０％から１０％上がる度に、上記の内部メモリのワークエリアに保存された周期に加算される補正値も１０秒ずつ増加する。すなわち、ネットワーク使用率が６０％であれば上記の内部メモリのワークエリアに保存された周期に１０秒加算される。また、ネットワーク使用率が７０％であれば上記の内部メモリのワークエリアに保存された周期に２０秒加算される。最終的に、ネットワーク使用率が１００％であれば上記の内部メモリのワークエリアに保存された周期に５０秒加算される。

図５は、ＣＰＵ使用率と補正値の対応関係の一例を示す図である。図５には、一例として、ＣＰＵ使用率に関するルックアップテーブルが示されている。例えば、負荷が最高である項目がＣＰＵ使用率である場合、図５に示すルックアップテーブルを参照してＣＰＵ使用率に対応する補正値が決定される。このルックアップテーブルは、補正値の算出式「補正値（秒）＝ＣＰＵ使用率の計測値（％）−３０」にしたがって補正値が設定されている。

図５に示すルックアップテーブルを参照して補正を行う場合、ＣＰＵ使用率３０％に対応する補正値は０％である。この場合、上記の内部メモリのワークエリアに保存された周期には０％が加算されるので、ＣＰＵ使用率が３０％である場合、実質的には周期の数値は補正後も変わらない。また、ＣＰＵ使用率が３０％から１０％下がる度に、上記の内部メモリのワークエリアに保存された周期から減算される補正値も１０秒ずつ増加する。すなわち、ＣＰＵ使用率が２０％であれば上記の内部メモリのワークエリアに保存された周期から１０秒減算される。また、ＣＰＵ使用率が１０％であれば上記の内部メモリのワークエリアに保存された周期から２０秒減算される。最終的に、ＣＰＵ使用率が０％であれば上記の内部メモリのワークエリアに保存された周期から３０秒減算される。一方、ＣＰＵ使用率が３０％から１０％上がる度に、上記の内部メモリのワークエリアに保存された周期に加算される補正値も１０秒ずつ増加する。すなわち、ＣＰＵ使用率が４０％であれば上記の内部メモリのワークエリアに保存された周期に１０秒加算される。また、ＣＰＵ使用率が５０％であれば上記の内部メモリのワークエリアに保存された周期に２０秒加算される。最終的に、ＣＰＵ使用率が１００％であれば上記の内部メモリのワークエリアに保存された周期に７０秒加算される。

図６は、メモリ使用率と補正値の対応関係の一例を示す図である。図６には、一例として、メモリ使用率に関するルックアップテーブルが示されている。例えば、負荷が最高である項目がメモリ使用率である場合、図６に示すルックアップテーブルを参照してメモリ使用率に対応する補正値が決定される。このルックアップテーブルは、補正値の算出式「補正値（秒）＝メモリ使用率の計測値（％）−２０」にしたがって補正値が設定されている。

図６に示すルックアップテーブルを参照して補正を行う場合、メモリ使用率２０％に対応する補正値は０％である。この場合、上記の内部メモリのワークエリアに保存された周期には０％が加算されるので、メモリ使用率が２０％である場合、実質的には周期の数値は補正後も変わらない。また、メモリ使用率が２０％から１０％下がる度に、上記の内部メモリのワークエリアに保存された周期から減算される補正値も１０秒ずつ増加する。すなわち、メモリ使用率が１０％であれば上記の内部メモリのワークエリアに保存された周期から１０秒減算される。また、メモリ使用率が０％であれば上記の内部メモリのワークエリアに保存された周期から２０秒減算される。一方、メモリ使用率が２０％から１０％上がる度に、上記の内部メモリのワークエリアに保存された周期に加算される補正値も１０秒ずつ増加する。すなわち、メモリ使用率が３０％であれば上記の内部メモリのワークエリアに保存された周期に１０秒加算される。また、メモリ使用率が４０％であれば上記の内部メモリのワークエリアに保存された周期に２０秒加算される。最終的に、メモリ使用率が１００％であれば上記の内部メモリのワークエリアに保存された周期に８０秒加算される。

図７は、データベースコネクション使用率と補正値の対応関係の一例を示す図である。図７には、一例として、データベースコネクション使用率に関するルックアップテーブルが示されている。例えば、負荷が最高である項目がデータベースコネクション使用率である場合、図７に示すルックアップテーブルを参照してメモリ使用率に対応する補正値が決定される。このルックアップテーブルは、補正値の算出式「補正値（秒）＝データベースコネクション使用率の計測値（％）−１０」にしたがって補正値が設定されている。

図７に示すルックアップテーブルを参照して補正を行う場合、データベースコネクション使用率１０％に対応する補正値は０％である。この場合、上記の内部メモリのワークエリアに保存された周期には０％が加算されるので、データベースコネクション使用率が１０％である場合、実質的には周期の数値は補正後も変わらない。また、データベースコネクション使用率が１０％から１０％下がる度に、上記の内部メモリのワークエリアに保存された周期から減算される補正値も１０秒ずつ増加する。すなわち、データベースコネクション使用率が０％であれば上記の内部メモリのワークエリアに保存された周期から１０秒減算される。一方、データベースコネクション使用率が１０％から１０％上がる度に、上記の内部メモリのワークエリアに保存された周期に加算される補正値も１０秒ずつ増加する。すなわち、データベースコネクション使用率が２０％であれば上記の内部メモリのワークエリアに保存された周期に１０秒加算される。また、データベースコネクション使用率が３０％であれば上記の内部メモリのワークエリアに保存された周期に２０秒加算される。最終的に、データベースコネクション使用率が１００％であれば上記の内部メモリのワークエリアに保存された周期に９０秒加算される。

図８は、ストレージアクセス使用率と補正値の対応関係の一例を示す図である。図８には、一例として、ストレージアクセス使用率に関するルックアップテーブルが示されている。例えば、負荷が最高である項目がストレージアクセス使用率である場合、図８に示すルックアップテーブルを参照してメモリ使用率に対応する補正値が決定される。このルックアップテーブルは、補正値の算出式「補正値（秒）＝ストレージアクセス使用率の計測値（％）−１０」にしたがって補正値が設定されている。

図８に示すルックアップテーブルを参照して補正を行う場合、ストレージアクセス使用率１０％に対応する補正値は０％である。この場合、上記の内部メモリのワークエリアに保存された周期には０％が加算されるので、ストレージアクセス使用率が１０％である場合、実質的には周期の数値は補正後も変わらない。また、ストレージアクセス使用率が１０％から１０％下がる度に、上記の内部メモリのワークエリアに保存された周期から減算される補正値も１０秒ずつ増加する。すなわち、ストレージアクセス使用率が０％であれば上記の内部メモリのワークエリアに保存された周期から１０秒減算される。一方、ストレージアクセス使用率が１０％から１０％上がる度に、上記の内部メモリのワークエリアに保存された周期に加算される補正値も１０秒ずつ増加する。すなわち、ストレージアクセス使用率が２０％であれば上記の内部メモリのワークエリアに保存された周期に１０秒加算される。また、ストレージアクセス使用率が３０％であれば上記の内部メモリのワークエリアに保存された周期に２０秒加算される。最終的に、ストレージアクセス使用率が１００％であれば上記の内部メモリのワークエリアに保存された周期に９０秒加算される。

なお、ここでは、図４〜図８に示すルックアップテーブルを補正に用いる場合を例示したが、必ずしもルックアップテーブルを用いずともかまわない。例えば、補正部１５ｄは、ルックアップテーブルを用いる代わりに、上記の補正値の算出式の関数に負荷が最高である項目の数値を引数として補正値を算出することにより、リクエストの周期の補正を実現することもできる。また、リクエストの周期の補正に必ずしも上記の５項目の全てを用いずともかまわず、上記の５項目を一部の項目に絞り込んでリクエストの周期の補正に用いることができるのは言うまでもない。

受付部１５ｅは、クライアント端末３０から災害情報のリクエストを受け付ける処理部である。

一実施形態として、受付部１５ｅは、クライアント端末３０上で動作するブラウザから災害情報のＷｅｂページに関するＨＴＴＰ（HyperText Transfer Protocol）リクエストを受け付けたり、また、クライアント端末３０上で動作する防災Ａｐｐから災害情報のリクエストに関するＷｅｂアクセスを受け付けたりする。

通知部１５ｆは、災害情報をクライアント端末３０に通知する処理部である。

一実施形態として、通知部１５ｆは、クライアント端末３０から受け付けたリクエストが防災ＡｐｐからのＷｅｂアクセスである場合、前回のＷｅｂアクセスを受け付けたリクエストにレスポンスを行った災害情報のバージョンと、記憶部１３に記憶された最新の災害情報のバージョンとの間に違いがあるか否かを判定する。このとき、通知部１５ｆは、バージョンに違いがない場合、災害情報の通知をスキップする。一方、通知部１５ｆは、クライアント端末３０から受け付けたリクエストがＨＴＴＰリクエストである場合、あるいは防災ＡｐｐからのＷｅｂアクセスであっても災害情報のバージョンに違いがない場合、記憶部１３に記憶された災害情報のうち最新の災害情報をクライアント端末３０に通知する。

設定部１５ｇは、クライアント端末３０に災害情報のリクエストの周期を設定する処理部である。

一実施形態として、設定部１５ｇは、クライアント端末３０から災害情報のリクエストを受け付けた場合、内部メモリのワークエリアを参照する。そして、設定部１５ｇは、災害情報のリクエストを行うクライアント端末３０に対し、内部メモリのワークエリアに保存された周期を設定する。例えば、クライアント端末３０上で動作するブラウザにリクエストの周期を設定する場合、設定部１５ｇは、ブラウザのＣｏｏｋｉｅに設定されたＷｅｂページのリロードの周期に内部メモリのワークエリアに保存された周期を上書きする。また、クライアント端末３０上で動作する防災Ａｐｐにリクエストの周期を設定する場合、設定部１５ｇは、防災Ａｐｐのコンフィグファイル等に内部メモリのワークエリアに保存された周期を上書きする。

［処理の流れ］
次に、本実施例に係るサーバ装置１０の処理の流れについて説明する。ここでは、サーバ装置１０により実行される（１）周期決定処理を説明した後に（２）通知処理を説明することとする。

（１）周期決定処理
図９は、実施例１に係る周期決定処理の手順を示すフローチャートである。この処理は、一例として、取得部１５ａにより災害情報が取得された場合に実行される。図９に示すように、取得部１５ａにより災害情報が取得されると（ステップＳ１０１）、算出部１５ｂは、ステップＳ１０１で取得された災害情報に基づいて災害の規模を算出する（ステップＳ１０２）。

続いて、決定部１５ｃは、災害の規模とクライアント端末３０に災害情報のリクエストを実行させる周期とが対応付けられた周期データ１３ｂを参照して、ステップＳ１０２で算出された災害の規模に対応する周期の基本値を、クライアント端末３０に災害情報のリクエストを実行させる周期として決定する（ステップＳ１０３）。

その後、最終報の災害情報が取得してから所定の期間が経過するまで（ステップＳ１０４Ｎｏ）、下記のステップＳ１０５〜ステップＳ１０７の処理が繰り返し実行される。すなわち、補正部１５ｄは、通信トラフィックが所定の閾値、例えば１００Ｍｂｐｓ以下であるか否かを判定する（ステップＳ１０５）。ここで通信トラフィックと比較する閾値には、一例として、クライアント端末３０からの災害情報のリクエストに対し、待機時間なしでレスポンスを行うことができる通信トラフィックの上限値を設定できる。

このとき、通信トラフィックが閾値以下である場合（ステップＳ１０５Ｙｅｓ）、現状の周期の設定で上記の通信サービスに支障が生じる可能性が低いと判断できる。この場合、ステップＳ１０６及びステップＳ１０７をスキップし、ステップＳ１０４の処理へ移行する。

一方、通信トラフィックが閾値以下でない場合（ステップＳ１０５Ｎｏ）、補正部１５ｄは、補正部１５ｄは、サーバ装置１０の処理負荷として、ネットワークの使用率、ＣＰＵの使用率、メモリの使用率、データベースコネクションの数およびストレージへのアクセス数を計測する（ステップＳ１０６）。

その上で、補正部１５ｄは、ネットワークの使用率、ＣＰＵの使用率、メモリの使用率、データベースコネクションの数およびストレージへのアクセス数の５項目うち負荷が最高である項目の数値に応じて上記の内部メモリのワークエリアに保存された周期を補正し（ステップＳ１０７）、ステップＳ１０４の処理へ移行する。

その後、最終報の災害情報が取得してから所定の期間が経過すると（ステップＳ１０４Ｙｅｓ）、図９に示す処理を終了する。

（２）通知処理
図１０は、実施例１に係る通知処理の手順を示すフローチャートである。この処理は、一例として、上記の通知サービスが運営する限り、繰り返し実行される。図１０に示すように、クライアント端末３０から災害情報のリクエストを受け付けた場合（ステップＳ３０１Ｙｅｓ）、通知部１５ｆは、ステップＳ３０１で受け付けたリクエストが防災ＡｐｐからのＷｅｂアクセスであるか否かを判定する（ステップＳ３０２）。

このとき、ステップＳ３０１で受け付けたリクエストが防災ＡｐｐからのＷｅｂアクセスである場合（ステップＳ３０２Ｙｅｓ）、通知部１５ｆは、前回のＷｅｂアクセスを受け付けたリクエストにレスポンスを行った災害情報のバージョンと、記憶部１３に記憶された最新の災害情報のバージョンとの間に違いがあるか否かを判定する（ステップＳ３０３）。なお、バージョンに違いがない場合（ステップＳ３０３Ｎｏ）、ステップＳ３０４の処理をスキップする。

また、ステップＳ３０１で受け付けたリクエストがＨＴＴＰリクエストである場合（ステップＳ３０２Ｎｏ）、あるいは防災ＡｐｐからのＷｅｂアクセスであっても災害情報のバージョンに違いがない場合（ステップＳ３０３Ｙｅｓ）、通知部１５ｆは、記憶部１３に記憶された災害情報のうち最新の災害情報をクライアント端末３０に通知する（ステップＳ３０４）。

その後、設定部１５ｇは、ステップＳ３０１で災害情報のリクエストを行うクライアント端末３０に対し、内部メモリのワークエリアに保存された周期を設定し（ステップＳ３０５）、ステップＳ３０１の処理へ移行する。

［効果の一側面］
上述してきたように、本実施例に係るサーバ装置１０は、災害の規模ごとにクライアント端末３０に災害情報をリクエストさせる周期が定められた周期データを参照して、発生した災害の規模に対応する周期をリクエストを行うクライアント端末３０に設定する制御を実現する。したがって、本実施例に係るサーバ装置１０によれば、災害発生時の通信トラフィックの増大を抑制できる。

さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。

［周期の設定の応用例］
上記の実施例１では、周期データ１３ｂを用いて周期の基本値を決定する場合を例示したが、他の方法により、周期の基本値を決定することもできる。例えば、サーバ装置１０は、サーバ装置１０の処理負荷に基づいて周期の基本値を決定することもできる。この場合、補正部１５ｄが使用するルックアップテーブルにおける補正値の代わりに基本値を設定しておくこととすればよい。

［災害の応用例］
上記の実施例１では、災害情報の一例として、地震に関する災害情報を例示したが、上記の通知サービスの適用範囲は地震に限定されない。すなわち、地震以外にも、津波、台風、洪水などの天災の他、ミサイルなどを含む災害全般に上記の通知サービスを適用できる。

［分散および統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されておらずともよい。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、取得部１５ａ、算出部１５ｂ、決定部１５ｃ、補正部１５ｄ、受付部１５ｅ、通知部１５ｆまたは設定部１５ｇをサーバ装置１０の外部装置としてネットワーク経由で接続するようにしてもよい。また、取得部１５ａ、算出部１５ｂ、決定部１５ｃ、補正部１５ｄ、受付部１５ｅ、通知部１５ｆまたは設定部１５ｇを別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記のサーバ装置１０の機能を実現するようにしてもよい。また、記憶部に記憶される災害情報１３ａまたは周期データ１３ｂの全部または一部を別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記のサーバ装置１０の機能を実現するようにしてもかまわない。

［制御プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１１を用いて、上記の実施例と同様の機能を有する制御プログラムを実行するコンピュータの一例について説明する。

図１１は、実施例１及び実施例２に係る制御プログラムを実行するコンピュータのハードウェア構成例を示す図である。図１１に示すように、コンピュータ１００は、操作部１１０ａと、スピーカ１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ１７０と、ＲＡＭ１８０とを有する。これら１１０〜１８０の各部はバス１４０を介して接続される。

ＨＤＤ１７０には、図１１に示すように、上記の実施例１で示した取得部１５ａ、算出部１５ｂ、決定部１５ｃ、補正部１５ｄ、受付部１５ｅ、通知部１５ｆ及び設定部１５ｇと同様の機能を発揮する制御プログラム１７０ａが記憶される。この制御プログラム１７０ａは、図２に示した取得部１５ａ、算出部１５ｂ、決定部１５ｃ、補正部１５ｄ、受付部１５ｅ、通知部１５ｆ及び設定部１５ｇの各構成要素と同様、統合又は分離してもかまわない。すなわち、ＨＤＤ１７０には、必ずしも上記の実施例１で示した全てのデータが格納されずともよく、処理に用いるデータがＨＤＤ１７０に格納されればよい。

このような環境の下、ＣＰＵ１５０は、ＨＤＤ１７０から制御プログラム１７０ａを読み出した上でＲＡＭ１８０へ展開する。この結果、制御プログラム１７０ａは、図１１に示すように、制御プロセス１８０ａとして機能する。この制御プロセス１８０ａは、ＲＡＭ１８０が有する記憶領域のうち制御プロセス１８０ａに割り当てられた領域にＨＤＤ１７０から読み出した各種データを展開し、この展開した各種データを用いて各種の処理を実行する。例えば、制御プロセス１８０ａが実行する処理の一例として、図９〜図１０に示す処理などが含まれる。なお、ＣＰＵ１５０では、必ずしも上記の実施例１で示した全ての処理部が動作せずともよく、実行対象とする処理に対応する処理部が仮想的に実現されればよい。

なお、上記の制御プログラム１７０ａは、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶されておらずともかまわない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に制御プログラム１７０ａを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から制御プログラム１７０ａを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに制御プログラム１７０ａを記憶させておき、コンピュータ１００がこれらから制御プログラム１７０ａを取得して実行するようにしてもよい。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）災害情報を取得し、
災害の規模と端末装置に災害情報のリクエストを実行させる周期とが対応付けられた周期データを参照して、取得した災害情報により定まる災害の規模に対応する周期を前記災害情報のリクエストを行う端末装置に設定する、
処理をコンピュータに実行させることを特徴とする制御プログラム。

（付記２）前記災害情報を前記端末装置に提供する提供装置の処理負荷に基づいて、前記算出した災害の規模に対応する周期を補正する処理をさらにコンピュータに実行させ、
前記設定する処理は、補正後の周期を前記災害情報のリクエストを行う端末装置に設定することを特徴とする付記１に記載の制御プログラム。

（付記３）前記処理負荷は、ネットワークの使用率、プロセッサの使用率、メモリの使用率、データベースコネクションの数およびストレージへのアクセス数のうち少なくともいずれか１つであることを特徴とする付記２に記載の制御プログラム。

（付記４）前記取得した災害情報に含まれる被災レベルのうち最高の被災レベルに基づいて前記災害の規模を算出する処理を前記コンピュータにさらに実行させることを特徴とする付記１、２または３に記載の制御プログラム。

（付記５）前記取得した災害情報に含まれる被災地の人口密度に基づいて前記災害の規模を算出する処理を前記コンピュータにさらに実行させることを特徴とする付記１、２または３に記載の制御プログラム。

（付記６）災害情報を取得し、
災害の規模と端末装置に災害情報のリクエストを実行させる周期とが対応付けられた周期データを参照して、取得した災害情報により定まる災害の規模に対応する周期を前記災害情報のリクエストを行う端末装置に設定する、
処理をコンピュータが実行することを特徴とする制御方法。

（付記７）前記災害情報を前記端末装置に提供する提供装置の処理負荷に基づいて、前記算出した災害の規模に対応する周期を補正する処理をさらにコンピュータが実行し、
前記設定する処理は、補正後の周期を前記災害情報のリクエストを行う端末装置に設定することを特徴とする付記６に記載の制御方法。

（付記８）前記処理負荷は、ネットワークの使用率、プロセッサの使用率、メモリの使用率、データベースコネクションの数およびストレージへのアクセス数のうち少なくともいずれか１つであることを特徴とする付記７に記載の制御方法。

（付記９）前記取得した災害情報に含まれる被災レベルのうち最高の被災レベルに基づいて前記災害の規模を算出する処理を前記コンピュータがさらに実行することを特徴とする付記６、７または８に記載の制御方法。

（付記１０）前記取得した災害情報に含まれる被災地の人口密度に基づいて前記災害の規模を算出する処理を前記コンピュータがさらに実行することを特徴とする付記６、７または８に記載の制御方法。

（付記１１）災害情報を取得する取得部と、
災害の規模と端末装置に災害情報のリクエストを実行させる周期とが対応付けられた周期データを参照して、取得した災害情報により定まる災害の規模に対応する周期を前記災害情報のリクエストを行う端末装置に設定する設定部と、
を有することを特徴とする制御装置。

（付記１２）前記災害情報を前記端末装置に提供する提供装置の処理負荷に基づいて、前記算出した災害の規模に対応する周期を補正する補正部をさらに有し、
前記設定部は、補正後の周期を前記災害情報のリクエストを行う端末装置に設定することを特徴とする付記１１に記載の制御装置。

（付記１３）前記処理負荷は、ネットワークの使用率、プロセッサの使用率、メモリの使用率、データベースコネクションの数およびストレージへのアクセス数のうち少なくともいずれか１つであることを特徴とする付記１２に記載の制御装置。

（付記１４）前記取得した災害情報に含まれる被災レベルのうち最高の被災レベルに基づいて前記災害の規模を算出する算出部をさらに有することを特徴とする付記１１、１２または１３に記載の制御装置。

（付記１５）前記取得した災害情報に含まれる被災地の人口密度に基づいて前記災害の規模を算出する算出部をさらに有することを特徴とする付記１１、１２または１３に記載の制御装置。

１ 災害情報システム
１０ サーバ装置
１１ 通信Ｉ／Ｆ部
１３ 記憶部
１３ａ 災害情報
１３ｂ 周期データ
１５ 制御部
１５ａ 取得部
１５ｂ 算出部
１５ｃ 決定部
１５ｄ 補正部
１５ｅ 受付部
１５ｆ 通知部
１５ｇ 設定部
２０ 情報源装置
３０Ａ，３０Ｂ，３０Ｃ クライアント端末

Claims (7)

1. 災害情報を取得し、
   災害の規模と端末装置に災害情報のリクエストを実行させる周期とが対応付けられた周期データを参照して、取得した災害情報により定まる災害の規模に対応する周期を前記災害情報のリクエストを行う端末装置に設定する、
   処理をコンピュータに実行させることを特徴とする制御プログラム。
2. 前記災害情報を前記端末装置に提供する提供装置の処理負荷に基づいて、前記算出した災害の規模に対応する周期を補正する処理をさらにコンピュータに実行させ、
   前記設定する処理は、補正後の周期を前記災害情報のリクエストを行う端末装置に設定することを特徴とする請求項１に記載の制御プログラム。
3. 前記処理負荷は、ネットワークの使用率、プロセッサの使用率、メモリの使用率、データベースコネクションの数およびストレージへのアクセス数のうち少なくともいずれか１つであることを特徴とする請求項２に記載の制御プログラム。
4. 前記取得した災害情報に含まれる被災レベルのうち最高の被災レベルに基づいて前記災害の規模を算出する処理を前記コンピュータにさらに実行させることを特徴とする請求項１、２または３に記載の制御プログラム。
5. 前記取得した災害情報に含まれる被災地の人口密度に基づいて前記災害の規模を算出する処理を前記コンピュータにさらに実行させることを特徴とする請求項１、２または３に記載の制御プログラム。
6. 災害情報を取得し、
   災害の規模と端末装置に災害情報のリクエストを実行させる周期とが対応付けられた周期データを参照して、取得した災害情報により定まる災害の規模に対応する周期を前記災害情報のリクエストを行う端末装置に設定する、
   処理をコンピュータが実行することを特徴とする制御方法。
7. 災害情報を取得する取得部と、
   災害の規模と端末装置に災害情報のリクエストを実行させる周期とが対応付けられた周期データを参照して、取得した災害情報により定まる災害の規模に対応する周期を前記災害情報のリクエストを行う端末装置に設定する設定部と、
   を有することを特徴とする制御装置。

Images