情報提供装置、情報提供システムおよび情報提供方法
【課題】
情報提供装置の処理負荷を軽減しながら、情報表示端末へ情報配信を可能にする。
【解決手段】
ネットワークを介して情報表示端末に情報の提供を行う情報提供装置であって、制御部と、情報を格納する記憶部と、情報表示端末と通信を行う通信処理部とを備え、通信処理部が、情報表示端末より情報の配信要求を受け付けると、制御部が、情報の更新予定時間を算出し、通信処理部が、情報を、算出した更新予定時間とともに情報表示端末へ送信し、情報の送信より更新予定時間が経過した後に、通信処理部が、情報表示端末が更新予定時間に基づいて再び送信した情報の配信要求を受け付けたとき、情報が前回送信時から更新されていない場合には、通信処理部が、情報が更新されるのを待って、更新された情報を情報表示端末に送信する。
情報提供装置の処理負荷を軽減しながら、情報表示端末へ情報配信を可能にする。
【解決手段】
ネットワークを介して情報表示端末に情報の提供を行う情報提供装置であって、制御部と、情報を格納する記憶部と、情報表示端末と通信を行う通信処理部とを備え、通信処理部が、情報表示端末より情報の配信要求を受け付けると、制御部が、情報の更新予定時間を算出し、通信処理部が、情報を、算出した更新予定時間とともに情報表示端末へ送信し、情報の送信より更新予定時間が経過した後に、通信処理部が、情報表示端末が更新予定時間に基づいて再び送信した情報の配信要求を受け付けたとき、情報が前回送信時から更新されていない場合には、通信処理部が、情報が更新されるのを待って、更新された情報を情報表示端末に送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報提供装置、情報提供システムおよび情報提供方法に関し、特に、ネットワークに接続された装置に対し情報を配信する技術に関する。
【背景技術】
【０００２】
近年、ＰＣやネット家電などの据え置き型の情報処理端末に加えて、携帯電話やＰＤＡなどのモバイル型の情報処理端末が普及し、これらの端末向けの各種情報サービスが一般化しつつある。その一つとして、列車やバスなどの公共交通機関の運行ダイヤが乱れた時に、遅延や振替等の状況を通知する運行情報案内サービスがある。例えば、特定の路線で一定時間以上の遅延が発生したか、または遅延の発生が見込まれる時に、ホームページ上で該情報を提供するサービスがある。
【０００３】
また、運行管理システムと連携して、鉄道および列車に関する詳細な情報をリアルタイムで携帯情報端末に提供する方法がある（例えば特許文献１を参照）。特許文献１では、列車情報配信サーバが、運行管理システム、ダイヤ管理システム、保守作業管理システムから受信した列車運行状況表示装置の情報、ダイヤデータ、保守作業計画データに基づいて列車情報提供サイトを開設し、携帯情報端末からのアクセスおよび入力操作に応じて、各種列車情報を表示した画面を送信する。
【０００４】
一方、インターネット上の通信プロトコルとして普及するＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）は、クライアントであるＷｅｂブラウザからの要求メッセージに応じて、Ｗｅｂサーバが応答メッセージを送るプル型の通信プロトコルであるが、サーバからプッシュ型でクライアントにメッセージを送信する技術がある（例えば非特許文献１を参照）。非特許文献１では、サーバがクライアントからの要求メッセージに対してすぐには応答せずに保留状態にしておくことで、サーバからクライアントへメッセージを送信したいタイミングでの送信を可能とする。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−３０８０９９号公報（第４頁、第１図）
【非特許文献】
【０００６】
【非特許文献１】Tomcat 6で実現！ Ajaxを超える通信技術Comet、[online]、アイティメディア株式会社、［２００９年１０月３０日検索］、インターネット<http://www.atmarkit.co.jp/fjava/rensai4/safetomcat_03/safetomcat_03_1.html>
【発明の概要】
【発明が解決しようとする課題】
【０００７】
特許文献１は、利用者端末から情報提供サイトのページへアクセスするプル型の情報提供であり、最新の運行情報を取得したい場合には、その都度利用者自身がサーバへのアクセス操作を何度も繰り返さなければならず、利用者にとって手間が掛かるという課題がある。また、利用者はいつ情報が更新されるかがわからないため、場合によっては情報が全く更新されていないにも関わらずサーバへのアクセス操作を繰り返し、その結果サーバの処理負荷が増大したり、サーバとクライアント間のネットワーク伝送負荷が大きくなるという課題がある。
【０００８】
また非特許文献１は、クライアントからの要求メッセージをサーバ側で保留状態にしておくため、多数のクライアントからの要求メッセージを受けると、サーバの処理負荷が増大するという課題がある。
【０００９】
本発明は上記課題を解決するためになされたもので、その目的は、情報提供装置の処理負荷を軽減しながら、情報表示端末へ情報配信することを可能にすることである。
【課題を解決するための手段】
【００１０】
本発明は、上記の課題の少なくとも１つを解決するために、ネットワークを介して情報表示端末に情報の提供を行う情報提供装置であって、制御部と、情報を格納する記憶部と、情報表示端末と通信を行う通信処理部とを備え、通信処理部が、情報表示端末より情報の配信要求を受け付けると、制御部が、情報の更新予定時間を算出し、通信処理部が、情報を、算出した更新予定時間とともに情報表示端末へ送信し、情報の送信より更新予定時間が経過した後に、通信処理部が、情報表示端末が更新予定時間に基づいて再び送信した情報の配信要求を受け付けたとき、情報が前回送信時から更新されていない場合には、通信処理部が、情報が更新されるのを待って、更新された情報を情報表示端末に送信することを特徴とする情報提供装置を提供する。
【発明の効果】
【００１１】
本発明によれば、情報提供装置の処理負荷を軽減しながら、情報表示端末へ情報配信することが可能になる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施例のシステム概要例を示す図である。
【図２】情報配信サーバ１０２０のハードウェア構成例を示す図である。
【図３】配信要求に対する処理例を示すフローチャートである。
【図４】配信要求管理テーブル２０８０の構成例を示す図である。
【図５】更新間隔算出手段１０７０の処理例を示すフローチャートである。
【図６】更新間隔判定テーブルの構成例を示す図である。
【図７】データ種別・内容条件テーブルの構成例を示す図である。
【図８】履歴データ条件テーブルの構成例を示す図である。
【図９】運行管理システム状態条件テーブルの構成例を示す図である。
【図１０】情報を配信する処理例を示すフローチャートである。
【図１１】情報表示端末１０３０の処理例を示すフローチャートである。
【図１２】情報表示端末１０３０の画面例を示す図である。
【図１３】コードテーブル２１３０の構成例を示す図である。
【図１４】取得履歴テーブル２１４０の構成例を示す図である。
【発明を実施するための形態】
【００１３】
以下、本発明における実施例について、図面を参照しながら詳細に説明する。
【００１４】
図１は、本実施例のシステム概要例を示すブロック図である。複数の情報表示端末１０３０の少なくとも１つが、情報受信・表示手段１０９０により情報配信サーバ１０２０に対し情報の配信要求を送信する。情報配信サーバ１０２０の配信要求受信手段１１００が、情報の配信要求を受信すると、制御情報取得手段１０６０が、受信した要求の内容に応じて、複数の運行管理システム１０１０の少なくとも１つから、ネットワーク１０４０を経由して、各種の情報を取得する。取得する情報は、例えば列車在線情報（路線名、列車番号、進行方向、列車位置、軌道回路番号、キロ程、列車速度など）やダイヤ情報、保守作業情報などである。更新間隔算出手段１０７０は、取得した情報の値が次に更新される更新予定時間を算出する。情報配信手段１０８０は、ネットワーク１０５０を介して複数の情報表示端末１０３０と接続し、取得した情報を、更新間隔算出手段１０７０が算出した該情報の更新予定時間とともに送信する。情報表示端末の情報受信・表示手段１０９０は、受信した情報を表示し、該情報の値が次に更新される時間が経過した後に、再び情報の要求メッセージを情報配信サーバへ送信する。
【００１５】
本構成例は、例えば運行管理システム１０１０と情報配信サーバ１０２０をパーソナルコンピュータやワークステーション等の計算機で、情報表示端末１０３０を携帯電話、ＰＤＡ、ノートＰＣ等のモバイル端末で、ネットワーク１０４０、１０５０をＥｔｈｅｒｎｅｔ（登録商標）や無線ＬＡＮで、制御情報取得手段１０６０、更新間隔算出手段１０７０、情報配信手段１０８０をＷｅｂサーバおよびＪａｖa（登録商標）プログラムで、情報受信・表示手段をＷｅｂブラウザおよびＪａｖａＳｃｒｉｐｔ（登録商標）でそれぞれ構成することにより、既知のシステム開発方法を用いて構築可能である。
【００１６】
図２は、情報配信サーバ１０２０のハードウェア構成例を示す図である。主制御部２０１０は、ハードウェアの制御とプログラムの実行処理を行う。入力部２０２０は、システム管理者からのプログラム実行開始指示や中止指示等の入力を行う。出力部２０３０は、プログラムの実行状態等の出力を行う。通信処理部２０４０は、他の計算機とのデータ交換を行う。記憶管理部２０５０は、プログラムやデータの読み出し、記録を行う。通信部２０６０は、各機能部間のデータ交換を行う。
【００１７】
記憶管理部２０５０には、配信要求受信手段１１００、制御情報取得手段１０６０、更新間隔算出手段１０７０、情報配信手段１０８０の処理を行う情報配信プログラム２０７０と、配信要求管理テーブル２０８０と、更新間隔判定テーブル２０９０と、データ種別・内容条件テーブル２１００と、履歴データ条件テーブル２１１０と、運行管理システム状態条件テーブル２１２０と、コードテーブル２１３０と、取得履歴テーブル２１４０が格納される。
【００１８】
上記構成は、例えば、主制御部２０１０をＣＰＵで、入力部２０２０をキーボードで、出力部２０３０を液晶ディスプレイで、通信処理部２０４０をＥｔｈｅｒｎｅｔ（登録商標）で、記憶管理部２０５０をハードディスクおよびメモリで、通信部２０６０をＢｕｓで実現することにより、従来から良く知られた装置で構成可能である。
【００１９】
なお、記憶管理部２０５０に格納されるとした各テーブルは、その一部を情報配信サーバ１０２０の外部に備え、必要に応じて情報配信サーバ１０２０が情報を取得することとしてもよい。例えば、取得履歴テーブル２１４０を備える代わりに、運行管理システムの情報を収集する別の装置から、適宜情報を取得することとしても良い。
【００２０】
本実施例における各機能部は、主制御部２０１０が、記憶管理部２０５０のハードディスクから読み出して実行する情報配信プログラムによって実現される。機能を実現するように、主制御部２０１０が通信処理部２０４０にデータの送受を行わせる。
【００２１】
以降に示す各処理は、当該処理を行う装置の主制御部が、ハードディスクから読み出して実行するプログラムによって実現される。そしてこれらのプログラムは、説明される各種の動作を行うためのコードから構成されている。
【００２２】
以下、本実施例における各機能部による処理について説明する。
【００２３】
例えば運行管理システムが自律分散システムとして実装されている場合、内容コードを付加した情報がデータフィールド上にブロードキャスト送信されている。
【００２４】
制御情報取得手段１０６０は、データフィールド上のブロードキャストデータを受信し、コードテーブル２１３０を参照して、データに付加された内容コードに含まれる項目名の値を取得し、取得履歴テーブルに登録する。
【００２５】
図１３に、コードテーブル２１３０の構成例を示す。本テーブルは、取得した情報の内容コード１３０１０、該内容コードのデータに含まれる項目名１３０２０からなる行のリストである。また、図１４に、取得履歴テーブル２１４０の構成例を示す。本テーブルは、情報の項目名１４０１０、該項目の複数の履歴データ１４０２０からなる行のリストである。
【００２６】
また、配信要求受信手段１１００が、情報表示端末１０３０より受信した配信要求の情報を配信要求管理テーブル２０８０に格納する。
【００２７】
図３を用いて、配信要求に対する処理の例を説明する。
【００２８】
主制御部２０１０が、配信要求の情報が格納された配信要求管理テーブル２０８０を読み込み、配信要求されている項目の値が、前回のチェック時から運行管理システム１０４０内で更新されているか否かを、取得履歴テーブル２１４０を参照して、対応する項目の履歴データから調べる（ステップ３０１０）。
【００２９】
図４に、配信要求管理テーブル２０８０の構成例を示す。本テーブルは、情報表示端末からの各配信要求の通信コネクションをプログラムで扱うためのソケットハンドル４０１０、要求されている各情報の項目名４０２０、各項目名に対応する最新の項目値４０３０、更新予定時間４０４０、該情報が最後に情報表示端末に配信されてから更新されたか否かを表す更新フラグ４０５０、情報表示端末からのＨＴＴＰリクエストメッセージの応答を保留状態にしているスレッド番号４０６０、各配信要求を受信した時刻を示す要求時刻４０７０、配信要求を受け付けているか否かを示す要求フラグ４０８０を含む行のリストであり、各情報表示端末から新たな項目に対する配信要求を受ける毎に行データを追加する。
【００３０】
なお、既に情報配信を行った項目に対する配信要求を、同じ情報表示端末１０３０から再度受け付けた場合には、該当する行データの要求時刻４０７０を上書きし、要求フラグ４０８０の値を１にする。
【００３１】
図３に戻って、要求フラグ４０８０の値が１である配信要求項目について、取得履歴テーブル２１４０の最新データを、項目値４０３０と比較した結果、両者が異なっており、前回の情報表示端末１０３０への情報送信時から運行管理システムの情報が更新されたと判断した場合、あるいは新たな項目に対する配信要求であって項目値４０３０にデータが記録されていない場合には、主制御部２０１０が配信要求管理テーブルの該当する項目名の最新の項目値４０３０に取得履歴テーブル２１４０の最新データを記録する（ステップ３０２０）。次に、更新間隔算出手段１０７０が、該項目値が次に更新される更新予定時間を算出し、更新予定時間４０４０に記録する（ステップ３０３０）。次に、該行の更新フラグ４０５０の値を１に変更し、情報配信手段１０８０が、更新フラグ４０５０の値が１である項目の情報を、配信要求を行った情報表示端末１０３０に送信する（ステップ３０４０）。ステップ３０１０に戻る。入力部２０２０によりシステム管理者からの終了操作を受け付けるまで、本処理を繰り返し行う。
【００３２】
続いて、更新間隔算出手段１０７０の処理例を、図５のフローチャートを用いて説明する。
最初に、項目値が次に更新される時間として、予め決められたデフォルト値（例えば１分など）を設定した後、更新間隔判定テーブル２０９０を読み込む（ステップ５０１０）。本デフォルト値は、該当する項目名がどの条件テーブルにも見つからなかった時に、更新予定時間として使用するものである。
【００３３】
図６に、更新間隔判定テーブルの構成例を示す。本テーブルは、情報の項目名６０１０、判定タイプ６０２０からなる行のリストである。本テーブルには、情報の各項目ごとに、項目値が次に更新される時間をどのようにして決定するかを設定する。本実施例では、後述するように、データ種別・内容から算出するか、履歴データから算出するか、運行管理システムの状態から算出するか、のいずれかを指定できる。システム管理者により予め設定可能であるとしてよい。
【００３４】
図５に戻って、次に、更新間隔判定テーブルに該当項目名があれば（ステップ５０２０）、主制御部２０１０が、対応する判定タイプから以降の処理を決定する（ステップ５０３０）。
判定タイプが「データ種別・内容から算出」であれば、データ種別・内容条件テーブル２１００を読み込み、該当するデータ種別・内容があるか否かを調べる（ステップ５０４０）。
【００３５】
図７に、データ種別・内容条件テーブルの構成例を示す。本テーブルは、データ種別・内容７０１０、更新間隔７０２０からなる行のリストである。情報の個々のデータ種別やデータ内容ごとに、更新間隔を設定できる。例えば、Ａ線の実施ダイヤ情報であれば３０秒間隔、といったようにデータ種別に応じて予め設定し、列車在線情報であれば区間毎に軌道回路の設置間隔が異なるため、区間ごとに適切な更新間隔を設定する。システム管理者により予め設定可能であるとしてもよい。データ種別・内容条件テーブルに該当データ種別やデータ内容があれば、対応する更新間隔を取得し（ステップ５０５０）、配信要求管理テーブル２０８０の更新予定時間４０４０に登録して本処理を終了する。
【００３６】
図５に戻って、判定タイプが「履歴データから算出」であれば、履歴データ条件テーブル２１１０を読み込み、該当する項目名があるか否かを調べる（ステップ５０６０）。
【００３７】
図８に、履歴データ条件テーブルの構成例を示す。本テーブルは、情報の項目名８０１０、算出方法８０２０からなる行のリストである。情報の項目毎の、値や更新間隔の履歴データの変動から、更新間隔を算出する方法を予め設定する。履歴データは、取得履歴テーブル２１４０を参照することによって取得できる。例えばＢ線の列車速度であれば、前ｎ回の履歴データおよび軌道回路上の位置から、駅に停車した直後であると判定される場合（例えば軌道回路Ｘ上（駅内）かつ前５回の速度値が時速10km/h以下）は、乗客の乗降が完了するまで発車しないので、例えば更新間隔を30秒とし、軌道回路Ｙ上（駅間）であれば、例えば過去３回の更新間隔の平均から次回の更新間隔を算出する。
【００３８】
図５に戻って、履歴データ条件テーブルに該当項目名があれば、履歴データから対応する更新間隔を算出し（ステップ５０７０）、配信要求管理テーブル２０８０の更新予定時間４０４０に登録して本処理を終了する。
【００３９】
また、判定タイプが「運行管理システムの状態から算出」であれば、運行管理システム状態条件テーブル２１２０を読み込み、該当する項目名があるか否かを調べる（ステップ５０８０）。
【００４０】
図９に、運行管理システム状態条件テーブルの構成例を示す。本テーブルは、情報の項目名９０１０、運行管理システム状態条件９０２０からなる行のリストである。情報の項目ごとに、運行管理システムの状態から更新間隔を算出する方法を設定する。例えば、運行管理システムが運転整理中の状態である場合は、列車の遅れ時間が何分以内の列車が何本存在するかに応じて、更新間隔を計算することとする。
【００４１】
図５に戻って、運行管理システム状態条件テーブルに該当項目名があれば、運行管理システムの状態から対応する更新間隔を算出し（ステップ５０９０）、計算した更新間隔を配信要求管理テーブル２０８０の該当行の更新予定時間４０４０に登録して、本処理を終了する。
【００４２】
更新間隔算出手段１０７０により算出される更新予定時間は、配信要求の処理に要する時間分を考慮して、実際に情報が更新される時間よりもやや短い方がより好適である。
【００４３】
続いて、情報を配信する処理の例を、図１０のフローチャートを用いて説明する。
図１０に示す通り、情報を配信するためにＡ、Ｂ２つのフローが並行して処理される。
【００４４】
まずフローＡについて、配信要求受信手段１１００が、情報表示端末１０３０からＨＴＴＰリクエストメッセージ（情報配信要求）を受信すると（ステップ１００１０）、配信要求管理テーブル２０８０に受信した配信要求に該当する行があるかを検索し、受信したのが新たな項目に対する配信要求であって該当する行が存在しない場合は、ＨＴＴＰリプライを保留するための新規スレッドを生成し、ソケットハンドル４０１０、要求された情報項目名４０２０、生成したスレッド番号４０６０、要求時刻４０７０を登録し、要求フラグ４０８０の値を１にする（ステップ１００２０）。なお、同じ情報表示端末１０３０から同じ項目に対する配信要求を既に受信し、情報配信を行っていて、該当する行が登録されている場合には、要求時刻４０７０を上書きで登録し、要求フラグの値を１にする。
【００４５】
主制御部２０１０は、ＨＴＴＰリクエストに対するＨＴＴＰリプライを保留状態にしておく（ステップ１００３０）。
【００４６】
また、フローＢについて、主制御部２０１０は、配信要求管理テーブル２０８０の更新フラグが１の行があるか否かを調べ（ステップ１００６０）、更新フラグが１の行があれば、該行の情報項目名４０２０、更新された最新の項目値４０３０、更新予定時間４０４０を含むＨＴＴＰリプライメッセージを行ごとに作成する（ステップ１００７０）。これらの値はＨＴＴＰリプライのヘッダまたはメッセージボディに格納する。更新フラグを調べるタイミングは、予め定められた一定時間ごとに繰り返し行うこととしてよい。
【００４７】
さらに、該行のスレッド番号４０６０のスレッドに対して、情報が更新されたことを通知し、作成したＨＴＴＰリプライメッセージを渡す（ステップ１０８０）。ここで、フローＡにおいて、ＨＴＴＰリプライを保留していたスレッドが、メッセージを受けて（ステップ１０４０）、ソケットハンドル４０１０を用いて該ＨＴＴＰリプライメッセージを要求元の情報表示端末１０３０に送信し、主制御部２０１０は配信要求管理テーブルの該当行の要求フラグおよび更新フラグを０にする（ステップ１００５０）。
【００４８】
フローＢにおいて、ステップ１００６０またはステップ１００８０の処理の後、主制御部２０１０は、配信要求管理テーブル２０８０に、要求時刻４０７０から現在時刻までに一定時間以上経過している行があるか否かを調べ（ステップ１００９０）、該当する行があれば、該行のスレッド番号４０６０のスレッドの処理を終了し、該行データを削除する（ステップ１０１００）。
【００４９】
これにより、情報表示端末１０３０の利用者からの入力操作により処理を終了した場合に、配信要求管理テーブルに不要な行データが永続的に残らないようにすることができる。要求フラグの値が１、すなわち情報受信・表示手段１０９０が情報配信手段１０８０からの応答を待っている途中で、情報表示端末１０３０が処理を終了した場合に対しても有効である。配信要求受信から行データ削除までの時間は、管理者により予め設定可能であることとしてもよい。
【００５０】
続いて、情報表示端末１０３０の処理例を、図１１のフローチャートを用いて説明する。なお、情報表示端末１０３０は、図１に示した情報受信・表示手段１０９０の他、配信要求を行う配信要求送信手段（図示せず）を備える。また、ハードウェア構成例としては、制御部、情報配信サーバ１０２０と通信を行う通信処理部、データ及びプログラムを格納する記憶部、利用者の入力操作を受け付ける入力部、および情報を表示する表示部を備える。以下に示す各処理は、制御部たるＣＰＵが、たとえば記憶部たるハードディスクから読み出して実行するプログラムによって実現される。そしてこれらのプログラムは、説明される各種の動作を行うためのコードから構成されている。
【００５１】
最初に、利用者からの情報配信の要求操作があると、まず、配信要求送信手段が、情報配信サーバ１０２０に対して情報を要求するメッセージをＨＴＴＰリクエストメッセージとして送信し、情報配信手段１０７０からのＨＴＴＰリプライメッセージの応答待ちを行う（ステップ１１０１０）。ここで、利用者の操作画面を構成するＷｅｂコンテンツ（ＪＰＥＧ画像など）はＨＴＴＰのプル型で要求し、情報が更新された場合に即座に取得したい情報のみをＨＴＴＰのプッシュ型で要求する。
【００５２】
利用者は、例えばチェックボックスやドロップダウンリストを用いて、各自が参照したい情報を選択できる。応答があれば該メッセージ中の情報を用いて表示画面を更新する（ステップ１１０２０）。
【００５３】
図１２に、利用者が配信要求を行う情報を選択する時の画面例１２０１０を示す。また、取得した情報の表示画面例を１２０２０に示す。
【００５４】
図１１に戻って、次に、該メッセージ中に該情報が次に更新される更新予定時間の情報が含まれているか否かを調べ（ステップ１１０３０）、該更新予定時間の情報が含まれていれば、該時間が経過するまで本処理をスリープする（ステップ１１０４０）。該時間の経過後、再び情報配信サーバ１０２０に対して情報配信を要求するメッセージをＨＴＴＰリクエストメッセージとして送信し（ステップ１１０５０）、ステップ１１０１０に戻る。利用者より終了操作を受け付けるまで、本処理により配信要求、情報取得、および情報表示を行う。
【００５５】
以上、本実施例では、更新間隔算出手段１０７０が、該情報が次に更新されるまでの時間間隔（例えば３分など）を算出して更新予定時間とする場合の処理例について説明した。しかしながらこれに限定されるものではなく、例えば該情報が次に更新される時刻（例えば１２時２０分３０秒など）を算出して情報表示端末１０３０に送信するようにしても良い。
【００５６】
また、本実施例では、履歴データ条件テーブル２１１０に記録した履歴データを用いて更新時間を算出する場合の処理例について説明した。しかしながらこれに限定されるものではなく、より大量の過去履歴データをデータベースに蓄積し、統計演算（例えば正規分布演算）によって更新予定時間を確率的に算出する（例えば、３分以内に更新される確率８０％など）ようにし、各情報表示端末１０３０で実際に要求メッセージを送信する時刻を該確率から決定するようにしても良い。
【００５７】
また、本実施例では、運行管理システムが保持する情報を更新されたタイミングで送信する場合の処理例について説明した。しかしながらこれに限定されるものではなく、更新時間が算出可能な情報であれば、運行管理システムの情報以外であっても、本方式を用いることによって、サーバの処理負荷を軽減しながら、端末に配信することが可能である。
【００５８】
また、本実施例では、サーバとクライアント間の通信プロトコルにＨＴＴＰを用いる場合の処理例について説明した。しかしながらＨＴＴＰに限定されるものではなく、クライアントからサーバに対してリクエストを送信するプル型の通信プロトコルであれば、本方式を用いることによって、サーバの処理負荷を軽減しながら、情報を配信することが可能である。
【産業上の利用可能性】
【００５９】
本発明は、情報処理装置を利用して情報配信を行う分野において利用可能である。
【符号の説明】
【００６０】
１０１０…運行管理システム、１０２０…情報配信サーバ、１０３０…情報表示端末、１０４０、１０５０…ネットワーク、１０６０…制御情報取得手段、１０７０…更新間隔算出手段、１０８０…情報配信手段、１０９０…情報受信・表示手段、１１００…配信要求受信手段、２０１０…主制御部、２０２０…入力部、２０３０…出力部、２０４０…通信処理部、２０５０…記憶管理部、２０６０…通信部、２０７０…情報配信プログラム、２０８０…配信要求管理テーブル、２０９０…更新間隔判定テーブル、２１００…データ種別・内容条件テーブル、２１１０…履歴データ条件テーブル、２１２０…運行管理システム状態条件テーブル、２１３０…コードテーブル、２１４０…取得履歴テーブル
【技術分野】
【０００１】
本発明は、情報提供装置、情報提供システムおよび情報提供方法に関し、特に、ネットワークに接続された装置に対し情報を配信する技術に関する。
【背景技術】
【０００２】
近年、ＰＣやネット家電などの据え置き型の情報処理端末に加えて、携帯電話やＰＤＡなどのモバイル型の情報処理端末が普及し、これらの端末向けの各種情報サービスが一般化しつつある。その一つとして、列車やバスなどの公共交通機関の運行ダイヤが乱れた時に、遅延や振替等の状況を通知する運行情報案内サービスがある。例えば、特定の路線で一定時間以上の遅延が発生したか、または遅延の発生が見込まれる時に、ホームページ上で該情報を提供するサービスがある。
【０００３】
また、運行管理システムと連携して、鉄道および列車に関する詳細な情報をリアルタイムで携帯情報端末に提供する方法がある（例えば特許文献１を参照）。特許文献１では、列車情報配信サーバが、運行管理システム、ダイヤ管理システム、保守作業管理システムから受信した列車運行状況表示装置の情報、ダイヤデータ、保守作業計画データに基づいて列車情報提供サイトを開設し、携帯情報端末からのアクセスおよび入力操作に応じて、各種列車情報を表示した画面を送信する。
【０００４】
一方、インターネット上の通信プロトコルとして普及するＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）は、クライアントであるＷｅｂブラウザからの要求メッセージに応じて、Ｗｅｂサーバが応答メッセージを送るプル型の通信プロトコルであるが、サーバからプッシュ型でクライアントにメッセージを送信する技術がある（例えば非特許文献１を参照）。非特許文献１では、サーバがクライアントからの要求メッセージに対してすぐには応答せずに保留状態にしておくことで、サーバからクライアントへメッセージを送信したいタイミングでの送信を可能とする。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−３０８０９９号公報（第４頁、第１図）
【非特許文献】
【０００６】
【非特許文献１】Tomcat 6で実現！ Ajaxを超える通信技術Comet、[online]、アイティメディア株式会社、［２００９年１０月３０日検索］、インターネット<http://www.atmarkit.co.jp/fjava/rensai4/safetomcat_03/safetomcat_03_1.html>
【発明の概要】
【発明が解決しようとする課題】
【０００７】
特許文献１は、利用者端末から情報提供サイトのページへアクセスするプル型の情報提供であり、最新の運行情報を取得したい場合には、その都度利用者自身がサーバへのアクセス操作を何度も繰り返さなければならず、利用者にとって手間が掛かるという課題がある。また、利用者はいつ情報が更新されるかがわからないため、場合によっては情報が全く更新されていないにも関わらずサーバへのアクセス操作を繰り返し、その結果サーバの処理負荷が増大したり、サーバとクライアント間のネットワーク伝送負荷が大きくなるという課題がある。
【０００８】
また非特許文献１は、クライアントからの要求メッセージをサーバ側で保留状態にしておくため、多数のクライアントからの要求メッセージを受けると、サーバの処理負荷が増大するという課題がある。
【０００９】
本発明は上記課題を解決するためになされたもので、その目的は、情報提供装置の処理負荷を軽減しながら、情報表示端末へ情報配信することを可能にすることである。
【課題を解決するための手段】
【００１０】
本発明は、上記の課題の少なくとも１つを解決するために、ネットワークを介して情報表示端末に情報の提供を行う情報提供装置であって、制御部と、情報を格納する記憶部と、情報表示端末と通信を行う通信処理部とを備え、通信処理部が、情報表示端末より情報の配信要求を受け付けると、制御部が、情報の更新予定時間を算出し、通信処理部が、情報を、算出した更新予定時間とともに情報表示端末へ送信し、情報の送信より更新予定時間が経過した後に、通信処理部が、情報表示端末が更新予定時間に基づいて再び送信した情報の配信要求を受け付けたとき、情報が前回送信時から更新されていない場合には、通信処理部が、情報が更新されるのを待って、更新された情報を情報表示端末に送信することを特徴とする情報提供装置を提供する。
【発明の効果】
【００１１】
本発明によれば、情報提供装置の処理負荷を軽減しながら、情報表示端末へ情報配信することが可能になる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施例のシステム概要例を示す図である。
【図２】情報配信サーバ１０２０のハードウェア構成例を示す図である。
【図３】配信要求に対する処理例を示すフローチャートである。
【図４】配信要求管理テーブル２０８０の構成例を示す図である。
【図５】更新間隔算出手段１０７０の処理例を示すフローチャートである。
【図６】更新間隔判定テーブルの構成例を示す図である。
【図７】データ種別・内容条件テーブルの構成例を示す図である。
【図８】履歴データ条件テーブルの構成例を示す図である。
【図９】運行管理システム状態条件テーブルの構成例を示す図である。
【図１０】情報を配信する処理例を示すフローチャートである。
【図１１】情報表示端末１０３０の処理例を示すフローチャートである。
【図１２】情報表示端末１０３０の画面例を示す図である。
【図１３】コードテーブル２１３０の構成例を示す図である。
【図１４】取得履歴テーブル２１４０の構成例を示す図である。
【発明を実施するための形態】
【００１３】
以下、本発明における実施例について、図面を参照しながら詳細に説明する。
【００１４】
図１は、本実施例のシステム概要例を示すブロック図である。複数の情報表示端末１０３０の少なくとも１つが、情報受信・表示手段１０９０により情報配信サーバ１０２０に対し情報の配信要求を送信する。情報配信サーバ１０２０の配信要求受信手段１１００が、情報の配信要求を受信すると、制御情報取得手段１０６０が、受信した要求の内容に応じて、複数の運行管理システム１０１０の少なくとも１つから、ネットワーク１０４０を経由して、各種の情報を取得する。取得する情報は、例えば列車在線情報（路線名、列車番号、進行方向、列車位置、軌道回路番号、キロ程、列車速度など）やダイヤ情報、保守作業情報などである。更新間隔算出手段１０７０は、取得した情報の値が次に更新される更新予定時間を算出する。情報配信手段１０８０は、ネットワーク１０５０を介して複数の情報表示端末１０３０と接続し、取得した情報を、更新間隔算出手段１０７０が算出した該情報の更新予定時間とともに送信する。情報表示端末の情報受信・表示手段１０９０は、受信した情報を表示し、該情報の値が次に更新される時間が経過した後に、再び情報の要求メッセージを情報配信サーバへ送信する。
【００１５】
本構成例は、例えば運行管理システム１０１０と情報配信サーバ１０２０をパーソナルコンピュータやワークステーション等の計算機で、情報表示端末１０３０を携帯電話、ＰＤＡ、ノートＰＣ等のモバイル端末で、ネットワーク１０４０、１０５０をＥｔｈｅｒｎｅｔ（登録商標）や無線ＬＡＮで、制御情報取得手段１０６０、更新間隔算出手段１０７０、情報配信手段１０８０をＷｅｂサーバおよびＪａｖa（登録商標）プログラムで、情報受信・表示手段をＷｅｂブラウザおよびＪａｖａＳｃｒｉｐｔ（登録商標）でそれぞれ構成することにより、既知のシステム開発方法を用いて構築可能である。
【００１６】
図２は、情報配信サーバ１０２０のハードウェア構成例を示す図である。主制御部２０１０は、ハードウェアの制御とプログラムの実行処理を行う。入力部２０２０は、システム管理者からのプログラム実行開始指示や中止指示等の入力を行う。出力部２０３０は、プログラムの実行状態等の出力を行う。通信処理部２０４０は、他の計算機とのデータ交換を行う。記憶管理部２０５０は、プログラムやデータの読み出し、記録を行う。通信部２０６０は、各機能部間のデータ交換を行う。
【００１７】
記憶管理部２０５０には、配信要求受信手段１１００、制御情報取得手段１０６０、更新間隔算出手段１０７０、情報配信手段１０８０の処理を行う情報配信プログラム２０７０と、配信要求管理テーブル２０８０と、更新間隔判定テーブル２０９０と、データ種別・内容条件テーブル２１００と、履歴データ条件テーブル２１１０と、運行管理システム状態条件テーブル２１２０と、コードテーブル２１３０と、取得履歴テーブル２１４０が格納される。
【００１８】
上記構成は、例えば、主制御部２０１０をＣＰＵで、入力部２０２０をキーボードで、出力部２０３０を液晶ディスプレイで、通信処理部２０４０をＥｔｈｅｒｎｅｔ（登録商標）で、記憶管理部２０５０をハードディスクおよびメモリで、通信部２０６０をＢｕｓで実現することにより、従来から良く知られた装置で構成可能である。
【００１９】
なお、記憶管理部２０５０に格納されるとした各テーブルは、その一部を情報配信サーバ１０２０の外部に備え、必要に応じて情報配信サーバ１０２０が情報を取得することとしてもよい。例えば、取得履歴テーブル２１４０を備える代わりに、運行管理システムの情報を収集する別の装置から、適宜情報を取得することとしても良い。
【００２０】
本実施例における各機能部は、主制御部２０１０が、記憶管理部２０５０のハードディスクから読み出して実行する情報配信プログラムによって実現される。機能を実現するように、主制御部２０１０が通信処理部２０４０にデータの送受を行わせる。
【００２１】
以降に示す各処理は、当該処理を行う装置の主制御部が、ハードディスクから読み出して実行するプログラムによって実現される。そしてこれらのプログラムは、説明される各種の動作を行うためのコードから構成されている。
【００２２】
以下、本実施例における各機能部による処理について説明する。
【００２３】
例えば運行管理システムが自律分散システムとして実装されている場合、内容コードを付加した情報がデータフィールド上にブロードキャスト送信されている。
【００２４】
制御情報取得手段１０６０は、データフィールド上のブロードキャストデータを受信し、コードテーブル２１３０を参照して、データに付加された内容コードに含まれる項目名の値を取得し、取得履歴テーブルに登録する。
【００２５】
図１３に、コードテーブル２１３０の構成例を示す。本テーブルは、取得した情報の内容コード１３０１０、該内容コードのデータに含まれる項目名１３０２０からなる行のリストである。また、図１４に、取得履歴テーブル２１４０の構成例を示す。本テーブルは、情報の項目名１４０１０、該項目の複数の履歴データ１４０２０からなる行のリストである。
【００２６】
また、配信要求受信手段１１００が、情報表示端末１０３０より受信した配信要求の情報を配信要求管理テーブル２０８０に格納する。
【００２７】
図３を用いて、配信要求に対する処理の例を説明する。
【００２８】
主制御部２０１０が、配信要求の情報が格納された配信要求管理テーブル２０８０を読み込み、配信要求されている項目の値が、前回のチェック時から運行管理システム１０４０内で更新されているか否かを、取得履歴テーブル２１４０を参照して、対応する項目の履歴データから調べる（ステップ３０１０）。
【００２９】
図４に、配信要求管理テーブル２０８０の構成例を示す。本テーブルは、情報表示端末からの各配信要求の通信コネクションをプログラムで扱うためのソケットハンドル４０１０、要求されている各情報の項目名４０２０、各項目名に対応する最新の項目値４０３０、更新予定時間４０４０、該情報が最後に情報表示端末に配信されてから更新されたか否かを表す更新フラグ４０５０、情報表示端末からのＨＴＴＰリクエストメッセージの応答を保留状態にしているスレッド番号４０６０、各配信要求を受信した時刻を示す要求時刻４０７０、配信要求を受け付けているか否かを示す要求フラグ４０８０を含む行のリストであり、各情報表示端末から新たな項目に対する配信要求を受ける毎に行データを追加する。
【００３０】
なお、既に情報配信を行った項目に対する配信要求を、同じ情報表示端末１０３０から再度受け付けた場合には、該当する行データの要求時刻４０７０を上書きし、要求フラグ４０８０の値を１にする。
【００３１】
図３に戻って、要求フラグ４０８０の値が１である配信要求項目について、取得履歴テーブル２１４０の最新データを、項目値４０３０と比較した結果、両者が異なっており、前回の情報表示端末１０３０への情報送信時から運行管理システムの情報が更新されたと判断した場合、あるいは新たな項目に対する配信要求であって項目値４０３０にデータが記録されていない場合には、主制御部２０１０が配信要求管理テーブルの該当する項目名の最新の項目値４０３０に取得履歴テーブル２１４０の最新データを記録する（ステップ３０２０）。次に、更新間隔算出手段１０７０が、該項目値が次に更新される更新予定時間を算出し、更新予定時間４０４０に記録する（ステップ３０３０）。次に、該行の更新フラグ４０５０の値を１に変更し、情報配信手段１０８０が、更新フラグ４０５０の値が１である項目の情報を、配信要求を行った情報表示端末１０３０に送信する（ステップ３０４０）。ステップ３０１０に戻る。入力部２０２０によりシステム管理者からの終了操作を受け付けるまで、本処理を繰り返し行う。
【００３２】
続いて、更新間隔算出手段１０７０の処理例を、図５のフローチャートを用いて説明する。
最初に、項目値が次に更新される時間として、予め決められたデフォルト値（例えば１分など）を設定した後、更新間隔判定テーブル２０９０を読み込む（ステップ５０１０）。本デフォルト値は、該当する項目名がどの条件テーブルにも見つからなかった時に、更新予定時間として使用するものである。
【００３３】
図６に、更新間隔判定テーブルの構成例を示す。本テーブルは、情報の項目名６０１０、判定タイプ６０２０からなる行のリストである。本テーブルには、情報の各項目ごとに、項目値が次に更新される時間をどのようにして決定するかを設定する。本実施例では、後述するように、データ種別・内容から算出するか、履歴データから算出するか、運行管理システムの状態から算出するか、のいずれかを指定できる。システム管理者により予め設定可能であるとしてよい。
【００３４】
図５に戻って、次に、更新間隔判定テーブルに該当項目名があれば（ステップ５０２０）、主制御部２０１０が、対応する判定タイプから以降の処理を決定する（ステップ５０３０）。
判定タイプが「データ種別・内容から算出」であれば、データ種別・内容条件テーブル２１００を読み込み、該当するデータ種別・内容があるか否かを調べる（ステップ５０４０）。
【００３５】
図７に、データ種別・内容条件テーブルの構成例を示す。本テーブルは、データ種別・内容７０１０、更新間隔７０２０からなる行のリストである。情報の個々のデータ種別やデータ内容ごとに、更新間隔を設定できる。例えば、Ａ線の実施ダイヤ情報であれば３０秒間隔、といったようにデータ種別に応じて予め設定し、列車在線情報であれば区間毎に軌道回路の設置間隔が異なるため、区間ごとに適切な更新間隔を設定する。システム管理者により予め設定可能であるとしてもよい。データ種別・内容条件テーブルに該当データ種別やデータ内容があれば、対応する更新間隔を取得し（ステップ５０５０）、配信要求管理テーブル２０８０の更新予定時間４０４０に登録して本処理を終了する。
【００３６】
図５に戻って、判定タイプが「履歴データから算出」であれば、履歴データ条件テーブル２１１０を読み込み、該当する項目名があるか否かを調べる（ステップ５０６０）。
【００３７】
図８に、履歴データ条件テーブルの構成例を示す。本テーブルは、情報の項目名８０１０、算出方法８０２０からなる行のリストである。情報の項目毎の、値や更新間隔の履歴データの変動から、更新間隔を算出する方法を予め設定する。履歴データは、取得履歴テーブル２１４０を参照することによって取得できる。例えばＢ線の列車速度であれば、前ｎ回の履歴データおよび軌道回路上の位置から、駅に停車した直後であると判定される場合（例えば軌道回路Ｘ上（駅内）かつ前５回の速度値が時速10km/h以下）は、乗客の乗降が完了するまで発車しないので、例えば更新間隔を30秒とし、軌道回路Ｙ上（駅間）であれば、例えば過去３回の更新間隔の平均から次回の更新間隔を算出する。
【００３８】
図５に戻って、履歴データ条件テーブルに該当項目名があれば、履歴データから対応する更新間隔を算出し（ステップ５０７０）、配信要求管理テーブル２０８０の更新予定時間４０４０に登録して本処理を終了する。
【００３９】
また、判定タイプが「運行管理システムの状態から算出」であれば、運行管理システム状態条件テーブル２１２０を読み込み、該当する項目名があるか否かを調べる（ステップ５０８０）。
【００４０】
図９に、運行管理システム状態条件テーブルの構成例を示す。本テーブルは、情報の項目名９０１０、運行管理システム状態条件９０２０からなる行のリストである。情報の項目ごとに、運行管理システムの状態から更新間隔を算出する方法を設定する。例えば、運行管理システムが運転整理中の状態である場合は、列車の遅れ時間が何分以内の列車が何本存在するかに応じて、更新間隔を計算することとする。
【００４１】
図５に戻って、運行管理システム状態条件テーブルに該当項目名があれば、運行管理システムの状態から対応する更新間隔を算出し（ステップ５０９０）、計算した更新間隔を配信要求管理テーブル２０８０の該当行の更新予定時間４０４０に登録して、本処理を終了する。
【００４２】
更新間隔算出手段１０７０により算出される更新予定時間は、配信要求の処理に要する時間分を考慮して、実際に情報が更新される時間よりもやや短い方がより好適である。
【００４３】
続いて、情報を配信する処理の例を、図１０のフローチャートを用いて説明する。
図１０に示す通り、情報を配信するためにＡ、Ｂ２つのフローが並行して処理される。
【００４４】
まずフローＡについて、配信要求受信手段１１００が、情報表示端末１０３０からＨＴＴＰリクエストメッセージ（情報配信要求）を受信すると（ステップ１００１０）、配信要求管理テーブル２０８０に受信した配信要求に該当する行があるかを検索し、受信したのが新たな項目に対する配信要求であって該当する行が存在しない場合は、ＨＴＴＰリプライを保留するための新規スレッドを生成し、ソケットハンドル４０１０、要求された情報項目名４０２０、生成したスレッド番号４０６０、要求時刻４０７０を登録し、要求フラグ４０８０の値を１にする（ステップ１００２０）。なお、同じ情報表示端末１０３０から同じ項目に対する配信要求を既に受信し、情報配信を行っていて、該当する行が登録されている場合には、要求時刻４０７０を上書きで登録し、要求フラグの値を１にする。
【００４５】
主制御部２０１０は、ＨＴＴＰリクエストに対するＨＴＴＰリプライを保留状態にしておく（ステップ１００３０）。
【００４６】
また、フローＢについて、主制御部２０１０は、配信要求管理テーブル２０８０の更新フラグが１の行があるか否かを調べ（ステップ１００６０）、更新フラグが１の行があれば、該行の情報項目名４０２０、更新された最新の項目値４０３０、更新予定時間４０４０を含むＨＴＴＰリプライメッセージを行ごとに作成する（ステップ１００７０）。これらの値はＨＴＴＰリプライのヘッダまたはメッセージボディに格納する。更新フラグを調べるタイミングは、予め定められた一定時間ごとに繰り返し行うこととしてよい。
【００４７】
さらに、該行のスレッド番号４０６０のスレッドに対して、情報が更新されたことを通知し、作成したＨＴＴＰリプライメッセージを渡す（ステップ１０８０）。ここで、フローＡにおいて、ＨＴＴＰリプライを保留していたスレッドが、メッセージを受けて（ステップ１０４０）、ソケットハンドル４０１０を用いて該ＨＴＴＰリプライメッセージを要求元の情報表示端末１０３０に送信し、主制御部２０１０は配信要求管理テーブルの該当行の要求フラグおよび更新フラグを０にする（ステップ１００５０）。
【００４８】
フローＢにおいて、ステップ１００６０またはステップ１００８０の処理の後、主制御部２０１０は、配信要求管理テーブル２０８０に、要求時刻４０７０から現在時刻までに一定時間以上経過している行があるか否かを調べ（ステップ１００９０）、該当する行があれば、該行のスレッド番号４０６０のスレッドの処理を終了し、該行データを削除する（ステップ１０１００）。
【００４９】
これにより、情報表示端末１０３０の利用者からの入力操作により処理を終了した場合に、配信要求管理テーブルに不要な行データが永続的に残らないようにすることができる。要求フラグの値が１、すなわち情報受信・表示手段１０９０が情報配信手段１０８０からの応答を待っている途中で、情報表示端末１０３０が処理を終了した場合に対しても有効である。配信要求受信から行データ削除までの時間は、管理者により予め設定可能であることとしてもよい。
【００５０】
続いて、情報表示端末１０３０の処理例を、図１１のフローチャートを用いて説明する。なお、情報表示端末１０３０は、図１に示した情報受信・表示手段１０９０の他、配信要求を行う配信要求送信手段（図示せず）を備える。また、ハードウェア構成例としては、制御部、情報配信サーバ１０２０と通信を行う通信処理部、データ及びプログラムを格納する記憶部、利用者の入力操作を受け付ける入力部、および情報を表示する表示部を備える。以下に示す各処理は、制御部たるＣＰＵが、たとえば記憶部たるハードディスクから読み出して実行するプログラムによって実現される。そしてこれらのプログラムは、説明される各種の動作を行うためのコードから構成されている。
【００５１】
最初に、利用者からの情報配信の要求操作があると、まず、配信要求送信手段が、情報配信サーバ１０２０に対して情報を要求するメッセージをＨＴＴＰリクエストメッセージとして送信し、情報配信手段１０７０からのＨＴＴＰリプライメッセージの応答待ちを行う（ステップ１１０１０）。ここで、利用者の操作画面を構成するＷｅｂコンテンツ（ＪＰＥＧ画像など）はＨＴＴＰのプル型で要求し、情報が更新された場合に即座に取得したい情報のみをＨＴＴＰのプッシュ型で要求する。
【００５２】
利用者は、例えばチェックボックスやドロップダウンリストを用いて、各自が参照したい情報を選択できる。応答があれば該メッセージ中の情報を用いて表示画面を更新する（ステップ１１０２０）。
【００５３】
図１２に、利用者が配信要求を行う情報を選択する時の画面例１２０１０を示す。また、取得した情報の表示画面例を１２０２０に示す。
【００５４】
図１１に戻って、次に、該メッセージ中に該情報が次に更新される更新予定時間の情報が含まれているか否かを調べ（ステップ１１０３０）、該更新予定時間の情報が含まれていれば、該時間が経過するまで本処理をスリープする（ステップ１１０４０）。該時間の経過後、再び情報配信サーバ１０２０に対して情報配信を要求するメッセージをＨＴＴＰリクエストメッセージとして送信し（ステップ１１０５０）、ステップ１１０１０に戻る。利用者より終了操作を受け付けるまで、本処理により配信要求、情報取得、および情報表示を行う。
【００５５】
以上、本実施例では、更新間隔算出手段１０７０が、該情報が次に更新されるまでの時間間隔（例えば３分など）を算出して更新予定時間とする場合の処理例について説明した。しかしながらこれに限定されるものではなく、例えば該情報が次に更新される時刻（例えば１２時２０分３０秒など）を算出して情報表示端末１０３０に送信するようにしても良い。
【００５６】
また、本実施例では、履歴データ条件テーブル２１１０に記録した履歴データを用いて更新時間を算出する場合の処理例について説明した。しかしながらこれに限定されるものではなく、より大量の過去履歴データをデータベースに蓄積し、統計演算（例えば正規分布演算）によって更新予定時間を確率的に算出する（例えば、３分以内に更新される確率８０％など）ようにし、各情報表示端末１０３０で実際に要求メッセージを送信する時刻を該確率から決定するようにしても良い。
【００５７】
また、本実施例では、運行管理システムが保持する情報を更新されたタイミングで送信する場合の処理例について説明した。しかしながらこれに限定されるものではなく、更新時間が算出可能な情報であれば、運行管理システムの情報以外であっても、本方式を用いることによって、サーバの処理負荷を軽減しながら、端末に配信することが可能である。
【００５８】
また、本実施例では、サーバとクライアント間の通信プロトコルにＨＴＴＰを用いる場合の処理例について説明した。しかしながらＨＴＴＰに限定されるものではなく、クライアントからサーバに対してリクエストを送信するプル型の通信プロトコルであれば、本方式を用いることによって、サーバの処理負荷を軽減しながら、情報を配信することが可能である。
【産業上の利用可能性】
【００５９】
本発明は、情報処理装置を利用して情報配信を行う分野において利用可能である。
【符号の説明】
【００６０】
１０１０…運行管理システム、１０２０…情報配信サーバ、１０３０…情報表示端末、１０４０、１０５０…ネットワーク、１０６０…制御情報取得手段、１０７０…更新間隔算出手段、１０８０…情報配信手段、１０９０…情報受信・表示手段、１１００…配信要求受信手段、２０１０…主制御部、２０２０…入力部、２０３０…出力部、２０４０…通信処理部、２０５０…記憶管理部、２０６０…通信部、２０７０…情報配信プログラム、２０８０…配信要求管理テーブル、２０９０…更新間隔判定テーブル、２１００…データ種別・内容条件テーブル、２１１０…履歴データ条件テーブル、２１２０…運行管理システム状態条件テーブル、２１３０…コードテーブル、２１４０…取得履歴テーブル
【特許請求の範囲】
【請求項１】
ネットワークを介して情報表示端末に情報の提供を行う情報提供装置であって、
制御部と、
前記情報を格納する記憶部と、
前記情報表示端末と通信を行う通信処理部とを備え、
前記通信処理部が、前記情報表示端末より前記情報の配信要求を受け付けると、
前記制御部が、前記情報の更新予定時間を算出し、
前記通信処理部が、前記情報を、算出した前記更新予定時間とともに前記情報表示端末へ送信し、
前記情報の送信より前記更新予定時間が経過した後に、前記通信処理部が、前記情報表示端末が前記更新予定時間に基づいて再び送信した前記情報の配信要求を受け付けたとき、前記情報が前回送信時から更新されていない場合には、
前記通信処理部が、前記情報が更新されるのを待って、更新された前記情報を前記情報表示端末に送信することを特徴とする情報提供装置。
【請求項２】
請求項１に記載の情報提供装置であって、
前記配信要求を再び受け付けた際、前記情報が前回送信時より更新されている場合は、
前記通信処理部が、前記更新された情報を前記情報表示端末へ送信することを特徴とする情報提供装置。
【請求項３】
請求項１または２に記載の情報提供装置であって、
前記制御部は、配信要求を受け付けた前記情報の種別に基づき、前記更新予定時間を算出することを特徴とする情報提供装置。
【請求項４】
請求項１ないし３のいずれか１つに記載の情報提供装置であって、
前記情報は、前記通信処理部が交通機関の運行管理システムから取得し、前記記憶部に格納した情報であることを特徴とする情報提供装置。
【請求項５】
請求項４に記載の情報提供装置であって、
前記記憶部は、前記情報表示端末に前回送信した情報を記憶し、
前記通信処理部が、前記情報表示端末から前記情報の配信要求を再び受信すると、
前記制御部が、取得した最新の情報と、前記前回送信した情報とを比較し、比較の結果、前記最新の情報が前記前回送信した情報と異なる場合に、前記情報が更新されたと判断し、
前記通信処理部が、前記最新の情報を前記情報表示端末に送信することを特徴とする情報提供装置。
【請求項６】
請求項４または５に記載の情報提供装置であって、
前記通信処理部は、前記運行管理システムのネットワークにブロードキャストされた前記情報を取得して前記記憶部に格納することを特徴とする情報提供装置。
【請求項７】
情報提供装置が、ネットワークを介して情報表示端末に情報の提供を行う情報提供システムであって、
前記情報表示端末が、前記情報提供装置に前記情報の配信要求を送信し、
前記情報提供装置は、前記配信要求を受信すると、前記情報の更新予定時間を算出し、前記情報を、算出した前記更新予定時間とともに前記情報表示端末へ送信し、
前記情報表示端末が、前記情報および前記更新予定時間を受信し、前記情報を受信して前記更新予定時間が経過した後に、前記更新予定時間に基づいて再び前記情報の配信要求を送信し、
前記情報提供装置が、前記配信要求を再度受信したとき、前記情報が前回送信時から更新されていない場合には、前記情報が更新されるのを待って、更新された前記情報を前記情報表示端末に送信することを特徴とする情報提供システム。
【請求項８】
情報提供装置が、ネットワークを介して情報表示端末に情報の提供を行う情報提供方法であって、
前記情報表示端末が、前記情報提供装置に前記情報の配信要求を送信し、
前記情報提供装置は、前記配信要求を受信すると、前記情報の更新予定時間を算出し、前記情報を、算出した前記更新予定時間とともに前記情報表示端末へ送信し、
前記情報表示端末が、前記情報および前記更新予定時間を受信し、前記情報を受信して前記更新予定時間が経過した後に、前記更新予定時間に基づいて再び前記情報の配信要求を送信し、
前記情報提供装置が、前記配信要求を再度受信したとき、前記情報が前回送信時から更新されていない場合には、前記情報が更新されるのを待って、更新された前記情報を前記情報表示端末に送信することを特徴とする情報提供方法。
【請求項１】
ネットワークを介して情報表示端末に情報の提供を行う情報提供装置であって、
制御部と、
前記情報を格納する記憶部と、
前記情報表示端末と通信を行う通信処理部とを備え、
前記通信処理部が、前記情報表示端末より前記情報の配信要求を受け付けると、
前記制御部が、前記情報の更新予定時間を算出し、
前記通信処理部が、前記情報を、算出した前記更新予定時間とともに前記情報表示端末へ送信し、
前記情報の送信より前記更新予定時間が経過した後に、前記通信処理部が、前記情報表示端末が前記更新予定時間に基づいて再び送信した前記情報の配信要求を受け付けたとき、前記情報が前回送信時から更新されていない場合には、
前記通信処理部が、前記情報が更新されるのを待って、更新された前記情報を前記情報表示端末に送信することを特徴とする情報提供装置。
【請求項２】
請求項１に記載の情報提供装置であって、
前記配信要求を再び受け付けた際、前記情報が前回送信時より更新されている場合は、
前記通信処理部が、前記更新された情報を前記情報表示端末へ送信することを特徴とする情報提供装置。
【請求項３】
請求項１または２に記載の情報提供装置であって、
前記制御部は、配信要求を受け付けた前記情報の種別に基づき、前記更新予定時間を算出することを特徴とする情報提供装置。
【請求項４】
請求項１ないし３のいずれか１つに記載の情報提供装置であって、
前記情報は、前記通信処理部が交通機関の運行管理システムから取得し、前記記憶部に格納した情報であることを特徴とする情報提供装置。
【請求項５】
請求項４に記載の情報提供装置であって、
前記記憶部は、前記情報表示端末に前回送信した情報を記憶し、
前記通信処理部が、前記情報表示端末から前記情報の配信要求を再び受信すると、
前記制御部が、取得した最新の情報と、前記前回送信した情報とを比較し、比較の結果、前記最新の情報が前記前回送信した情報と異なる場合に、前記情報が更新されたと判断し、
前記通信処理部が、前記最新の情報を前記情報表示端末に送信することを特徴とする情報提供装置。
【請求項６】
請求項４または５に記載の情報提供装置であって、
前記通信処理部は、前記運行管理システムのネットワークにブロードキャストされた前記情報を取得して前記記憶部に格納することを特徴とする情報提供装置。
【請求項７】
情報提供装置が、ネットワークを介して情報表示端末に情報の提供を行う情報提供システムであって、
前記情報表示端末が、前記情報提供装置に前記情報の配信要求を送信し、
前記情報提供装置は、前記配信要求を受信すると、前記情報の更新予定時間を算出し、前記情報を、算出した前記更新予定時間とともに前記情報表示端末へ送信し、
前記情報表示端末が、前記情報および前記更新予定時間を受信し、前記情報を受信して前記更新予定時間が経過した後に、前記更新予定時間に基づいて再び前記情報の配信要求を送信し、
前記情報提供装置が、前記配信要求を再度受信したとき、前記情報が前回送信時から更新されていない場合には、前記情報が更新されるのを待って、更新された前記情報を前記情報表示端末に送信することを特徴とする情報提供システム。
【請求項８】
情報提供装置が、ネットワークを介して情報表示端末に情報の提供を行う情報提供方法であって、
前記情報表示端末が、前記情報提供装置に前記情報の配信要求を送信し、
前記情報提供装置は、前記配信要求を受信すると、前記情報の更新予定時間を算出し、前記情報を、算出した前記更新予定時間とともに前記情報表示端末へ送信し、
前記情報表示端末が、前記情報および前記更新予定時間を受信し、前記情報を受信して前記更新予定時間が経過した後に、前記更新予定時間に基づいて再び前記情報の配信要求を送信し、
前記情報提供装置が、前記配信要求を再度受信したとき、前記情報が前回送信時から更新されていない場合には、前記情報が更新されるのを待って、更新された前記情報を前記情報表示端末に送信することを特徴とする情報提供方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１１−１００３７０（Ｐ２０１１−１００３７０Ａ）
【公開日】平成２３年５月１９日（２０１１．５．１９）
【国際特許分類】
【出願番号】特願２００９−２５５６８４（Ｐ２００９−２５５６８４）
【出願日】平成２１年１１月９日（２００９．１１．９）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２３年５月１９日（２０１１．５．１９）
【国際特許分類】
【出願日】平成２１年１１月９日（２００９．１１．９）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]