JP2006004100A - 鉄道情報配信システム - Google Patents

Abstract

【課題】 鉄道事業者が、乗客の意向、即ち乗客自身はこうしたいと思っていること、を直接知ることができるようにして乗客と鉄道事業者の意識のギャップを埋め、双方に利益をもたらす情報配信サービスを提供する。
【解決手段】 利用者の意向に応じた情報サービスを提供すると共に意向を運行管理に利用する。鉄道事業者側から乗客側への一方通行であった情報の流れを双方向にし、乗客側の意向を鉄道事業者側に伝えることを可能にするため、情報配信サーバが乗客に提供する情報の中に乗客の意向を返信する手段を設け、乗客にはその意向に基づいたサービスを提供する一方、情報配信サーバは運行管理システムに、集められた乗客の意向を送る。
【選択図】 図１

Description

本発明は、利用者の意向に応じた情報配信サービスを提供すると共に、利用者の意向を運行管理に利用する鉄道情報配信システムに関するものである。

通勤や通学等で日常的に鉄道を利用する人にとって最大の関心事は、事故や故障などで鉄道の運行が停止したり遅延したりした場合に、その状況をいかに早く、正確に把握するか、ということになる。

最近、インターネット等への情報アクセスが可能な携帯電話が普及し、鉄道等の交通機関の運行状況を、携帯電話を使っていつでもどこでも調べることが一般的になってきている。現在このような情報配信サービスは、運行管理システムに接続され、運行管理システムから得られる制御情報を加工して鉄道会社や情報配信サービス業者に提供する運行情報提供システムを介して行われている。運行情報提供システムの実現手段に関しては特許文献１に記載のような技術がある。

現在実用化されている情報サービスには、利用者自らが情報提供サイトにアクセスして必要な情報を検索するものの他に、利用者があらかじめ登録した路線に遅延が発生すると携帯電話でメールを受け取れるといったものもあるが、あくまで情報は一方的に提供されるものであり、提供される情報も一律的で自分が真に必要としている情報を必ずしも入手できるわけではない。

一方、鉄道の運行管理において、事故や故障等で乱れた運行ダイヤを正常なダイヤに回復させるために運転区間や運転間隔を変更することを運転整理と呼ぶが、運転整理の手法は未だ確立されておらず、どのように列車の運行を変更するかは、現状では運転指令員の経験によって決められる場合が多い。運転整理によるダイヤの収束を効率的に行い、待たされている乗客の不満をより早く解消するためには、各列車や各駅のホームにどれくらいの乗客がいるかを推定することが必要であり、特許文献２記載のような運転整理支援技術も考案されている。しかし、このような技術が実用化され、運転指令員がどこでどのくらいの乗客が待たされているかがわかったとしても、待たされている乗客の希望や感情を吸い上げることはできず、たくさん人が待っているのだから不満も大きいのだろうなどと推測をするしかない。
特開2000‐127973号公報 特開2001‐55145号公報

このように、従来の技術による鉄道情報サービスでは、情報の流れは運行管理側から乗客側への一方通行であり、乗客の意向を直接汲み上げることはできなかったという不都合があった。

そこで、本発明は、列車の運行情報に対する乗客の意向情報を反映したサービスを提供すると共に、運転指令員に代表される鉄道事業者が、乗客の意向、即ち乗客自身はこうしたいと思っていることを直接知ることができるようにする鉄道情報配信システムを提供することを目的とするものである。

上記課題を解決し、本発明の目的を達成するため、サーバは、列車の運行情報を各端末に配信すると共に、各端末において運行情報に対する利用者の意向情報の入力を促し、端末は、利用者が入力した運行情報に対する利用者の意向情報をサーバに返信し、サーバは、意向情報に応じた列車又は他のサービス情報を端末に配信する。

これにより、鉄道事業者側から乗客側への一方通行であった情報の流れを双方向にし、乗客側の意向情報を鉄道事業者側に伝えることを可能にするので、情報配信サーバが乗客に提供する情報の中に列車の運行情報に対する乗客の意向情報を返信し、乗客にはその意向情報に基づいたサービス情報を提供する。

一方、サーバは、列車の運行情報を各端末に配信すると共に、各端末において運行情報に対する利用者の意向情報の入力を促し、端末は、利用者が入力した運行情報に対する利用者の意向情報をサーバに返信し、サーバは、意向情報を集計し、集計結果を運行情報を管理する運行管理システムに送信する。

これにより、情報配信サーバは運行管理システムに、集められた列車の運行情報に対する乗客の意向情報を送るので、運行管理システムは、集められた列車の運行情報に対する乗客の意向情報に基づいて、列車の運行管理を行うと共に、新たな列車の運行情報を提供する。

本発明によれば、従来、鉄道事業者側が乗客の意向を直接知る手段が無かったために生じている、乗客側と鉄道事業者側の意識のギャップを埋めることができ、双方に利益をもたらす情報配信サービスを提供することが可能になる。

詳細な実施形態例を説明する前に先ず本発明の基本的な処理の流れを説明する。図１は本発明における基本的な鉄道情報配信システム構成を表した図であり、
図１に示す鉄道情報配信サービスシステムは、運行管理システム２０と、情報配信サーバ１０と、運行管理システム２０と、無線基地局４１をつなぐネットワーク４０と、複数（ｎ台）の端末３０１〜３０ｎとから成る。

情報配信サーバ１０は、利用者の複数（ｎ台）の端末３０１〜３０ｎから送られてきた意向情報を記憶するための集計情報記憶手段１０１と、運行情報や各店舗のサービス情報を記憶するための提供情報記憶手段１０２を持ち、利用者の複数（ｎ台）の端末３０１〜３０ｎに情報を提供するためにネットワーク４０及び無線基地局４１を介して複数（ｎ台）の端末３０１〜３０ｎと接続されている。

運行管理システム２０は列車の運行を管理すると共に、運行情報を情報配信サーバ１０に送る。情報配信サーバ１０は、運行管理システム２０から送られてきた運行情報を提供情報記憶手段１０２に記憶し、ネットワーク４０を介して利用者が持つ端末３０１〜３０ｎに配信する。端末３０１〜３０ｎは現状のインターネットアクセス可能な携帯電話端末を想定しているが、少なくともメール送受信機能及びＷｅｂブラウザ機能を持つものであればよい。

これにより、鉄道事業者の運行管理システム２０及び情報配信サーバ１０側から利用者の複数（ｎ台）の端末３０１〜３０ｎ側への一方通行であった情報の流れを双方向にし、乗客側の意向情報を鉄道事業者側に伝えることを可能にするので、情報配信サーバ１０が乗客に提供する情報の中に列車の運行情報に対する乗客の意向情報を返信し、乗客にはその意向情報に基づいたサービス情報を提供することができる。

また、情報配信サーバ１０は運行管理システム２０に、集められた列車の運行情報に対する乗客の意向情報を送るので、運行管理システム２０は、集められた列車の運行情報に対する乗客の意向情報に基づいて、乗客の意向情報を反映した列車の運行管理を行うと共に、乗客の意向情報を反映した新たな列車の運行情報を提供することができる。

図２は本発明によって提供される鉄道情報配信サービスにおける、基本的な処理の流れを各装置間での情報及びサービスの受け渡しと共に示したものであり、縦の矢印(上から下)は時間の経過を表す。
図２において、Ｔ１時点で、列車の遅延などの運行情報が運行管理システム２０から情報配信サーバ１０に送られると、Ｔ２時点で、情報配信サーバ１０はその情報を端末３０１〜３０ｎに配信する。Ｔ３〜Ｔ５時点で、情報配信サーバ１０は各端末から利用者の意向が入力された返信を受け取る。すると、Ｔ４〜Ｔ６時点で、情報配信サーバ１０は各意向に沿ったサービスを利用者に提供する。

これと共に、Ｔ３〜Ｔ６時点で、情報配信サーバ１０は意向情報を集計処理する。その後に、Ｔ７時点で、情報配信サーバ１０はその集計処理された意向情報を集計情報記憶手段１０１に記憶し、運行管理システム２０に送る。

以下図３から図２２を用いて本発明の第１の鉄道情報配信システムの例を説明する。
図３は本実施形態例における鉄道情報配信サービスシステムの全体構成を表した図であり、図３に示す鉄道情報配信サービスシステムは、図１の構成に加え、駅ホームの様子を撮影する監視カメラ７０、駅構内の店舗の販売管理パソコン８０、販売管理パソコンと接続されたキャッシュレジスター８１、及び、図１に示した情報配信サーバ１０及び運行管理システム２０と、監視カメラ７０及び販売管理パソコン８０をつなぐネットワーク５０と、から成る。

監視カメラ７０によって撮影された映像はネットワーク５０を介して運行管理システム２０及び情報配信サーバ１０に送られる。キャッシュレジスター８１から入力された売上データは販売管理パソコン８０に蓄えられ、必要に応じてネットワーク５０を介して情報配信サーバ１０に送られる。また、後述する各店舗のサービス情報なども販売管理パソコン８０からネットワーク５０を介して情報配信サーバ１０に送られる。

これにより、情報配信サーバ１０は、駅ホームの画像から混雑度を把握することができ、駅構内の店舗の利用状況を把握することができる。また、運行管理システム２０は、駅ホームの混雑度及び駅構内の店舗の利用状況に基づいた列車の運行を管理することができる。

図４は情報配信サーバ１０の内部構成を示した図である。
情報配信サーバ１０は、図１で説明した集計情報記憶手段１０１と、提供情報記憶手段１０２、に加え、会員登録した利用者に関する情報を記憶する会員情報記憶手段１０３と、中央処理装置（CPU）１０４と、ネットワーク４０と接続するためのネットワークインターフェース（I/F）１０５と、ネットワーク５０と接続するためのネットワークインターフェース（I/F）１０６と、から成る。

これにより、情報配信サーバ１０は、会員登録した利用者に対して、利用者に即した詳細な運行情報を配信することができると共に、利用者が提供を受けやすいサービス情報を提供することができる。

図５は運行管理システム２０の内部構成を示した図であり、各線区ごとに分かれた運行指令システム即ち、○○線区運行指令システム２０１、△△線区運行指令システム２０２、××線区運行指令システム２０３と、各線区共通の運行情報提供システム２０４、から成る。各システムは内部ネットワーク２０５によって接続され、内部ネットワーク２０５とネットワーク５０はゲートウェイ２０６によって接続されている。

これにより、運行管理システム２０は、各線区の運行指令システムの運行情報を集約して、情報配信サーバ１０に送ることができる。

図６は○○線区運行指令システム２０１における運行指令コンソールであり、この運行指令コンソールは、列車ダイヤ２０２１を表示する列車ダイヤ表示装置２０１１と、利用者意向集計データ２０２３とその統計データ２０２２を表示する運行状況表示装置２０１２、運転指令入力装置２０１３と、から成る。

運転指令員は、運転整理を行う場合、運行状況表示装置２０１２に示される利用者意向集計データ２０２３とその統計データ２０２２に基づいて、列車の遅れ時分、駅の混雑度、利用者の意向、及び事故や故障の現場状況を総合的に判断し、運転指令入力装置２０１３から各列車の運転士に対し、どの駅を何時何分に出発せよ、という運転指令を入力し、列車ダイヤ表示装置２０１１に示されている列車ダイヤを変更する。

また、△△線区運行指令システム２０２、××線区運行指令システム２０３も図６と同様の運行指令コンソールを持ち、各線区ごとに独立した指令を行う。

図７は運行情報提供システム２０４における情報提供コンソールであり、情報表示装置２０４１、運行情報入力装置２０４２、から成る。
情報提供担当者は、情報表示装置２０４１に表示される列車の遅れ時分情報２０５１、駅の混雑度情報２０５２、利用者の意向情報２０５３、各運行指令システム２０１〜２０３によって指示された図６に示した運転指令、等の情報から、運行情報２０５４として発信する文面を作成し、運行情報入力装置２０４２から入力する。入力された運行情報は内部ネットワーク２０５、ゲートウェイ２０６及びネットワーク５０を介して情報配信サーバ１０に送られる。

次に本実施形態例における、情報配信サーバ１０で行われる情報配信サービスにかかわる処理について説明する。
図８は、会員情報登録内容及び店舗サービス情報登録内容を表した図であり、図８（ａ）は会員情報登録内容、図８（ｂ）は店舗サービス情報登録内容である。
情報配信サーバ１０の会員情報記憶手段１０３には図８（ａ）の会員情報、提供情報記憶手段１０２には図８（ｂ）の店舗サービス情報があらかじめ登録されているものとする。

図８（ａ）の会員情報登録内容には、会員番号８０１、保有する定期券区間の自宅側の駅名８０２及びオフィス側の駅名８０３、定期券を使用する曜日を特定するための休日パターン８０４、定期券を使用する時間帯を特定するための出勤時間帯８０５，８０７及び退勤時間帯８０６，８０８、が含まれる。

図８（ｂ）の店舗サービス情報登録内容には、駅名８１１、場所区分８１２、店舗名８１３、特典の分類８１４、特典の内容を含んだメッセージ８１５、が含まれる。

図９は情報配信サーバ１０で行われる情報配信サービスの処理を示すフローチャートである。
情報配信サービスは運行情報配信処理９０１、利用者意向確認処理９０２、サービス情報配信処理９０３、意向集計結果送信処理９０４、サービス利用集計処理９０５、からなり、利用者意向確認処理９０２及びサービス情報配信処理９０３は、９０６で示すように、各利用者ごとに要求があるたびに繰り返す。以下、各処理について詳細に説明する。

図１０は運行情報配信処理９０１の詳細を示すフローチャートである。
図１０において、まず、事故や故障などが発生し、運行管理システム２０内の運行情報提供システム２０４から情報配信サーバ１０に運行情報が到着すると、その情報は提供情報記憶手段１０２に格納される（９０１１）。次に、路線名、発生した曜日及び時間帯を検索キーとして、会員情報記憶手段１０３から対象となる会員を抽出する（９０１２）。そこで、通知対象会員に運行情報メールを送信する（９０１３）。

図１１は運行情報提供システム２０４から情報配信サーバ１０に送られてくる運行情報の例である。
図１１において、運行情報は、運行情報が運行情報提供システム２０４に登録される登録時刻１１１、運行情報が発生した発生時刻１１２、路線１１３、場所１１４、分類１１５、状況１１６、及びメッセージ１１７を有している。

図１２は通知対象会員に送られる運行情報メールの例である。
図１２において、運行情報メールには、運行情報１２１に会員番号が付いたインターネットアドレス（URL）１２２が付随しており、会員はこのインターネットアドレス（URL）１２２にアクセスするだけで、容易に次のステップである利用者意向確認処理に進むことが出来る。

図１３は利用者意向確認処理９０２の詳細を示すフローチャートである。
図１３において、まず、アドレスに付随した会員番号を検索キーとして、会員情報記憶手段１０３から会員の定期券乗車区間を抽出する（９０２１）。次に、利用者の意向を確認するＷｅｂページを、定期券乗車区間から推定した現在地候補と共に表示する（９０２２）。

図１４は利用者意向入力欄及び、現在地入力欄の付いた利用者意向確認ページの例である。
図１４において、利用者は、これからの意向として「待つ」のか、「別経路検索」するのか、「何もしない」のかを端末の表示画面上の利用者意向入力欄１４２及び現在地入力欄１４３の入力を促すチェックボックスを選択状態にすることにより、容易に意向入力を選択することができる。また、現在地がどこであるかを現在地入力欄１４３の入力を促すチェックボックスを選択状態にすることにより、容易に現在地を入力することができる。

図１４は意向として「待つ」、現在地として「オフィス-Y駅の間」を選択した場合である。利用者は、利用者意向「送信」ボタン１４４を押すことにより、利用者の意向及び現在地が、会員番号と共に情報配信サーバ１０に送られる。

図１５はサービス情報配信処理９０３の詳細を示すフローチャートである。
図１５において、まず、利用者から送られてきた意向及び現在地情報を抽出し（９０３１）、集計情報記憶手段１０１に格納する（９０３２）。そして、情報配信サーバ１０は場所及び意向に応じた情報サービスＷｅｂページを表示する（９０３３）。

図１６は、利用者の意向が「待つ」場合の情報サービス例を示す図であり、図１６（ａ）は待機条件入力画面、図１６（ｂ）は「○○カフェ」サービス表示画面、図１６（ｃ）は「駅ビルＹ」サービス表示画面である。ここでも、各入力欄の入力を促すチェックボックスを選択状態にすることにより、選択された各入力欄に対応する項目の入力が可能となる。
図１６（ａ）は、図１４のように意向として「待つ」、現在地として「オフィス-Y駅の間」を選択した場合の情報サービス例である。待機条件入力画面１６１において「待つ」場所として「Y駅」付近の店舗情報が検索され、候補としてあがっている。１６２に示すように、場所として「○○カフェ」を選択して「送信」ボタンを押すと、図１６（ｂ）の「○○カフェ」サービス表示画面１６３に示すような「○○カフェ」の割引クーポンが発行される。

１６４に示すように、場所として「駅ビルＹ」を選択して「送信」ボタンを押すと、図１６（ｃ）の「駅ビルＹ」サービス表示画面１６５に示すようなクレジットカード利用時の特典クーポンが発行される。どのようなサービスが受けられるかは、提供情報記憶手段１０２に記憶されている店舗サービス情報登録内容に従う。また、「待つ」を選択した利用者は、運行再開時に再びメールを送信するため、会員番号と対応付けられた「待ちリスト」（図示せず）が集計情報記憶手段１０１に記憶される。

図１７は、利用者の意向が「別経路検索」をする場合の情報サービス例を示す図であり、図１７（ａ）は別経路検索画面、図１７（ｂ）は経路検索結果表示画面である。ここでも、各入力欄の入力を促すチェックボックスを選択状態にすることにより、選択が可能となる。
図１７（ａ）は、図１４の画面で意向として「別経路検索」、現在地として「オフィス-Y駅の間」を選択した場合の情報サービス例である。別経路検索画面１７１において、経路検索の起点としては現在地情報から「Y駅」、終点としては会員情報記憶手段１０３から抽出された「X駅」がデフォルトで選ばれている。出発時刻を選択して「検索」ボタン１７３を押すと情報配信サーバ１０が経路検索を行い、図１７（ｂ）の経路検索結果表示画面１７２に示すような検索結果を表示する。この例では乗り換えにかなりの時間がかかるという検索結果であったため、「待つことにする」として「送信」ボタンを押して返信する。そうすると図１６と同じ画面に推移する。

図１８は意向集計結果送信処理９０４の詳細を示したフローチャートである。
図１８において、まず、集計情報記憶手段１０１に格納された、利用者の意向及び現在地情報を定期的に集計し（９０４１）、次に、運行管理システム２０に集計データを送信する（９０４２）。

図１９は利用者意向集計データの例である。
図１９において、線区内の駅名１９１単位に会員数１９２及び選択された利用者意向の、待ち１９３、別経路１９４、その他１９５の割合がまとめられている。この情報は運行状況表示装置２０１２や情報表示装置２０４１に表示され、運転指令員が運転整理を行う場合に参照できる。

図２０はサービス利用集計処理９０５の詳細を示したフローチャートである。
図２０において、まず、利用者が実際に構内店舗の割引などのサービスを受けた場合、サービスを行った店舗はその利用状況を、キャッシュレジスター８１、販売管理パソコン８０及びネットワーク５０を介して情報配信サーバ１０に送信する。次に、情報配信サーバ１０は利用状況を集計情報記憶手段１０１に格納し（９０５１）、そして、定期的に集計データを更新する（９０５２）。この集計データは利用者意向集計情報と共に経営判断に利用される。

図２１はサービス利用集計データの例である。
図２１において、駅名２１１、場所２１２における各店舗名２１３ごとに特典２１４の利用者数２１５による実績がまとめられている。

図２２は、運行再開時の情報配信内容及び駅構内の混雑具合確認の例を示す図であり、図２２（ａ）は運行再開メール、図２２（ｂ）は駅状況表示画面である。
図２２（ａ）は運行が再開された場合の運行情報配信内容である。
集計情報記憶手段１０１に記憶されている「待ちリスト」（図示せず）に登録された会員に対し、運行再開の時刻などを示したメール２２１を送信する。このとき、駅の混雑状況にアクセス可能なインターネットアドレス（URL）が付随しており、利用者はこのインターネットアドレス（URL）にアクセスするだけで、駅の状況を示す画面に進むことが出来る。

利用者は図２２（ｂ）のように、監視カメラ７０の駅の状況を示す画面２２２から駅構内の混雑具合を自分で確認し、乗車時間を調整することが出来る。利用者は「再読込」ボタンにより逐次更新される現在の画像を閲覧でき、また、「他の場所」ボタンにより駅の他の場所の画像を閲覧できる。

なお、本実施例では、情報サービスはあらかじめ登録した会員向けに行っており、「会員」と「利用者」は同義語として使っている。会員登録を行うことは、より個人のニーズに合った情報提供が可能になるという点では重要であるが、会員登録により個人を特定するか否かは本発明の本質ではなく、例えば駅構内の無線LAN等が普及し、ある特定の場所にいる乗客に一斉に情報を配信することが可能になれば、会員登録をすることなく本発明と同様の効果が得られる。

以下図２３から図２５を用いて本発明の第２の鉄道情報配信システムの例を説明する。
図２３は本実施形態例における鉄道情報配信サービスシステムの全体構成を表した図であり、第２の鉄道情報配信システムは、図３の構成に加え、走行中の列車と通信を行う無線基地局６０、列車に搭載された無線装置６１、列車の乗車人数を計測する重量センサー６２、から成る。無線基地局６０は、ネットワーク５０に接続されている。

重量センサー６２によって計測された乗車人数は、無線装置６１、無線基地局６０及びネットワーク５０を介して運行管理システム２０に送られる。この情報は列車の混雑度として図６に示した運行状況表示装置２０１２や図７に示した情報表示装置２０４１に表示され、運転指令員が運転整理を行う場合や、情報提供担当者が運行情報を作成する場合に参照できる。

図２４は、第２の例における利用者の意向が「待つ」場合の情報サービス例を示す図であり、図２４（ａ）は待機条件入力画面、図２４（ｂ）は「○○カフェ」サービス表示画面である。ここでも、各入力欄の入力を促すチェックボックスを選択状態にすることにより、選択された各入力欄に対応する項目の入力が可能となる。
図２４は第２の実施形態例におけるサービス情報配信処理９０３の中の情報サービス表示例を示し、図１６（ａ）及び図１６（ｂ）に対応するもので、本実施形態例では列車の混雑度が把握できるので、待機条件入力画面２４１において待機条件入力欄２４２で待機条件として「いつまで待つか」、即ち、「運行再開後すぐ」、「混雑解消傾向時」、「混雑解消時」、のいずれかが選択できる。

待機条件入力画面２４１において待機条件入力欄２４２で、２４３に示すように、「混雑解消傾向時」を選択したとき、「○○カフェ」サービス表示画面において「混雑解消傾向が見られたらメールを送信します。」というメッセージが表示される。

図２５は、第２の例における運行情報メール文面の例を示す図であり、図２５（ａ）は「運転再開後すぐ」を選択した場合、図２５（ｂ）は「混雑解消傾向時」を選択した場合、図２５（ｃ）は「混雑解消時」を選択した場合である。
図２５（ａ）〜図２５（ｃ）は待機条件の違いによる運行情報メール２５１，２５２，２５３の文面の違いを示すものである。当然これらは図２５（ａ）、（ｂ）、（ｃ）の順に状況が変化するごとに時間を置いて配信される。
その他の構成要素及び処理については第１の例と同じである。

以下図２６から図２７を用いて本発明の第３の鉄道情報配信システムの例を説明する。
図２６は本実施形態例における鉄道情報配信システムの基本構成を表した図であり、図１の構成に加え、GPS（Global Positioning System）衛星９０からの位置検出信号を受信し、自端末位置を計測し、メールやＷｅｂアクセスにおいて自端末位置を発信できる端末３０ｉから成る。

図２７は第３の実施形態例における利用者意向確認処理９０２の中の利用者意向確認ページ表示例を示し、図１４に対応するもので、本実施形態例の利用者意向確認ページ２７１では端末の位置がわかるため、現在地入力欄が不要となっている。ここでも、各入力欄の入力を促すチェックボックスを選択状態にすることにより、選択された各入力欄に対応する項目の入力が可能となる。
その他の構成要素及び処理については第１の実施形態例と同じである。

本発明による情報配信サービスは、鉄道をはじめとする路線バスや飛行機などの公共交通機関が最適な対象であるが、本来のサービス業務（鉄道ならば旅客輸送）の状況を利用者に提供する必要のある業種に広く適用することができる。

本発明における基本的な鉄道情報配信システムの構成を示す図である。 本発明における基本的な処理の流れを示す図である。 第１の鉄道情報配信システムの構成例を示す図である。 情報配信サーバの内部構成を示した図である。 運行管理システムの内部構成を示した図である。 運行指令システムにおける運行指令コンソールを表した図である。 運行情報提供システムにおける情報提供コンソールを表した図である。 会員情報登録内容及び店舗サービス情報登録内容を表した図であり、図８（ａ）は会員情報登録内容、図８（ｂ）は店舗サービス情報登録内容である。 情報配信サービスの処理を示したフローチャートである。 運行情報配信処理の詳細を示したフローチャートである。 運行情報の例を示す図である。 運行情報メールの例を示す図である。 利用者意向確認処理の詳細を示したフローチャートである。 利用者意向確認ページの例を示す図である。 サービス情報配信処理の詳細を示したフローチャートである。 利用者の意向が「待つ」場合の情報サービス例を示す図であり、図１６（ａ）は待機条件入力画面、図１６（ｂ）は「○○カフェ」サービス表示画面、図１６（ｃ）は「駅ビルＹ」サービス表示画面である。 利用者の意向が「別経路検索」をする場合の情報サービス例を示す図であり、図１７（ａ）は別経路検索画面、図１７（ｂ）は経路検索結果表示画面である。 意向集計結果送信処理の詳細を示したフローチャートである。 利用者意向集計データの例を示す図である。 サービス利用集計処理の詳細を示したフローチャートである。 サービス利用集計データの例を示す図である。 運行再開時の情報配信内容及び駅構内の混雑具合確認の例を示す図であり、図２２（ａ）は運行再開メール、図２２（ｂ）は駅状況表示画面である。 第２の鉄道情報配信システムの構成例を示す図である。 第２の例における利用者の意向が「待つ」場合の情報サービス例を示す図であり、図２４（ａ）は待機条件入力画面、図２４（ｂ）は「○○カフェ」サービス表示画面である。 第２の例における運行情報メール文面の例を示す図であり、図２５（ａ）は「運転再開後すぐ」を選択した場合、図２５（ｂ）は「混雑解消傾向時」を選択した場合、図２５（ｃ）は「混雑解消時」を選択した場合である。 第３の鉄道情報配信システムの構成例を示す図である。 第３の例における利用者意向確認ページ表示例を示す図である。

符号の説明

１０…情報配信サーバ、２０…運行管理システム、３０１〜３０ｎ…端末１〜ｎ、４０…ネットワーク、４１…無線基地局、５０…ネットワーク、６０…無線基地局、６１…無線装置、６２…重量センサー、７０…監視カメラ、８０…販売管理パソコン、８１…キャッシュレジスター、９０…GPS衛星、１０１…集計情報記憶手段、１０２…提供情報記憶手段、１０３…会員情報記憶手段、１０４…CPU、１０５〜１０６…ネットワークI/F、２０１〜２０３…運行指令システム、２０４…運行情報提供システム、２０５…内部ネットワーク、２０６…ゲートウェイ、２０１１…列車ダイヤ表示装置、２０１２…運行状況表示装置、２０１３…運転指令入力装置、２０４１…情報表示装置、２０４２…運行情報入力装置

Claims (13)

1. サーバから鉄道の運行情報をネットワークを介して複数の端末に提供する鉄道情報配信システムにおいて、
   前記サーバは、列車の運行情報を前記各端末に配信する手段と、各端末において前記運行情報に対する利用者の意向情報の入力を促す手段と、前記意向情報を受信する手段と、前記意向情報に応じた列車又は他のサービス情報を当該端末に配信する手段とを有し、
   前記端末は、前記列車の運行情報を受信する手段と、前記運行情報に対する利用者の意向情報を入力する手段と、利用者が入力した前記運行情報に対する利用者の意向情報を前記サーバに返信する手段と、前記意向情報に応じた列車又は他のサービス情報を受信する手段とを有し、
   前記サーバは、列車の運行情報を前記各端末に配信すると共に、各端末において前記運行情報に対する利用者の意向情報の入力を促し、前記端末から返信される利用者が入力した前記運行情報に対する利用者の意向情報に対応して、前記意向情報に応じた列車又は他のサービス情報を当該端末に配信することを特徴とする鉄道情報配信システム。
2. 前記サービス情報は、列車の遅延更新情報であることを特徴とする請求項１記載の鉄道情報配信システム。
3. 前記サービス情報は、利用者が他の列車の経路を選択可能な迂回情報であることを特徴とする請求項１記載の鉄道情報配信システム。
4. 前記サービス情報は、列車運行開始までの利用者の待機中に受けることができるサービスに関連する情報であることを特徴とする請求項１記載の鉄道情報配信システム。
5. 前記サーバは、登録された会員の端末に対して店舗サービス情報を配信することを特徴とする請求項１記載の鉄道情報配信システム。
6. 前記サーバは、駅構内又は周辺の利用者の端末に対して駅構内又は周辺の店舗サービス情報を配信することを特徴とする請求項１記載の鉄道情報配信システム。
7. 前記サーバは他の利用者の意向情報を任意の利用者が閲覧可能にすることを特徴とする請求項１記載の鉄道情報配信システム。
8. サーバから鉄道の運行情報をネットワークを介して複数の端末に提供する鉄道情報配信システムにおいて、
   前記サーバは、列車の運行情報を前記各端末に配信する手段と、各端末において前記運行情報に対する利用者の意向情報の入力を促す手段と、前記意向情報を受信する手段と、前記意向情報を集計する手段と、当該集計結果を前記運行情報を管理する運行管理システムに送信する手段とを有し、
   前記端末は、前記列車の運行情報を受信する手段と、前記運行情報に対する利用者の意向情報を入力する手段と、利用者が入力した前記運行情報に対する利用者の意向情報を前記サーバに返信する手段とを有し、
   前記サーバは、列車の運行情報を前記各端末に配信すると共に、各端末において前記運行情報に対する利用者の意向情報の入力を促し、前記端末から返信される利用者が入力した前記運行情報に対する利用者の意向情報意向情報を集計し、当該集計結果を前記運行情報を管理する運行管理システムに送信することを特徴とする鉄道情報配信システム。
9. 前記運行管理システムは、当該集計結果に基づいて前記運行情報を生成することを特徴とする請求項８記載の鉄道情報配信システム。
10. 前記運行管理システムは、当該集計結果の統計情報に基づいて列車の運行指令情報を生成することを特徴とする請求項８記載の鉄道情報配信システム。
11. 前記運行情報は、列車の遅延更新情報であることを特徴とする請求項９記載の鉄道情報配信システム。
12. 前記運行情報は、駅構内混雑度情報であることを特徴とする請求項９記載の鉄道情報配信システム。
13. 前記運行情報は、列車の事故情報であることを特徴とする請求項９記載の鉄道情報配信システム。

Images