JP3974796B2 - 通報方法、通報サーバ、およびプログラム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、交通情報の報知技術に関するものである。
【０００２】
【従来の技術】
今日の社会では、鉄道、自動車、船舶、または航空機等の交通機関が発達し、日常生活において不可欠のものとして利用されている。このような交通機関では、移動速度の向上、安全性向上、あるいは、乗り心地の良さの向上を図るため積極的な技術革新が図られてきた。したがって、特に都市圏では、交通機関が高度に発達し、通勤や通学の利便性が著しく向上した。
【０００３】
しかし、例えば、通勤等で列車を利用するため駅に行くと、事故で列車が止まっているようなことがある。このような場合、仕方なく運行開始を待つか、代替手段を探して別なルートで移動したりする。また、花火大会等のイベントで非常に混雑して電車に乗れなかったりすることもある。
【０００４】
【発明が解決しようとする課題】
このように、従来、交通機関の利用に際し、その利用者へ交通機関の状況を示す情報を発信し、利用者の便宜を図るという配慮は少なかった。また、従来でも、テレビ、ラジオ等で交通機関の運行状況や渋滞状況等が放送されているし、インターネット上のウェブサイト等でそのような状況を掲示するサービスも存在する。
【０００５】
しかし、利用者は、テレビやラジオ等の放送に常に注意を払う必要があり、利用者は交通機関を利用する前に、能動的にそのようなテレビ、ラジオ、ウェブサイト等を確認する必要があった。したがって、時間に追われているような場合、そのような情報を見落としてしまうことがあり、結果的に交通機関の障害や道路の渋滞等の影響を回避できない場合があった。
【０００６】
また、このような状況に対して、交通機関を利用する経路と障害の発生している期間とに依存し、強く影響を受ける利用者と影響の少ない利用者が存在する。したがって、上記のような放送やウェブサイトを確認した場合でも、利用者が自身の利用経路と利用時間との関係からどの程度の影響を受けるかを推定しなければならなかった。
【０００７】
本発明はこのような従来の技術の問題点に鑑みてなされたものである。すなわち、本発明の課題は、利用者の能動的な意思によらないで、交通機関の障害による利用者への影響を軽減させる技術を提供することにある。
【０００８】
【課題を解決するための手段】
本発明は前記課題を解決するために、以下の手段を採用した。すなわち、本発明は、利用者に交通機関の状況を通報する通報サーバであり、
利用者ごとに交通機関を利用する経路および利用する時期に係る情報の設定を受ける手段と、
上記交通機関の運行を阻害する事象の種類、およびその事象の発生時刻を収集する手段と、
上記事象の解消時刻を推定する手段と、
上記交通機関利用時における前記事象による影響の有無を利用者ごとに判定する手段と、
上記影響があると判定される利用者にその旨を報知する報知手段とを備えるものである。
【０００９】
ここで、利用時期に係る情報とは、例えば、交通機関を利用する利用開始時刻または利用時間帯等である。また、交通機関の運行を阻害する事象とは、例えば、鉄道、道路、船舶、航空機、港湾、空港等における事故、各種のイベント、または、ストライキ等である。
【００１０】
このように、利用者が交通機関を利用する経路および時間と、上記事象の発生時刻および解消推定時刻とに基づき、その事象による各利用者への影響が判断され、影響があると判断された利用者にその旨が通知される。したがって、利用者の能動的な意思によらず、そのような事象からの影響を利用者に認識させることができる。
【００１１】
好ましくは、上記報知手段は、上記事象による影響が少ない代替経路をさらに報知するものでもよい。
【００１２】
好ましくは、上記報知手段は、上記事象の解消予定時刻またはその事象が解消した旨を報知してもよい。
【００１３】
好ましくは、上記通報サーバは、上記代替経路の選択を促す手段と、
選択された代替経路において交通機関の利用許可を示す許可情報を利用者の端末に出力させる手段とをさらに備えてもよい。
【００１４】
ここで、許可情報とは、例えば、上記代替経路の交通機関の振替切符等である。このように、本通報サーバによれば、利用者に代替経路が報知され、利用者が代替経路を利用するための許可情報をスムーズに利用者に配布することができる。
【００１５】
すなわち、本通報サーバによれば、上記事象が発生した交通手段の情報を影響を受ける利用者に通知し、代替経路の提案や解決予想時間が提示されるので、利用者は、そのような事象に対応することが可能になる。本通報サーバは、例えば、通勤時間帯に発生した事故等の情報をその通勤経路および時間帯で影響のある利用者に通知し、代替ルート等の解決案を提案する。
【００１６】
【発明の実施の形態】
以下、本発明の一実施の形態を図１から図１９の図面に基づいて説明する。
【００１７】
図１は、本実施の形態に係る情報システムのシステム構成図であり、図２は、図１に示した利用者マスタ２のデータ例であり、図３は、電車事故マスタ３のデータ例であり、図４は、道路事故マスタ４のデータ例であり、図５は、ストマスタ５のデータ例であり、図６は、イベントマスタ６のデータ例であり、図７は、事故通知マスタ７のデータ例であり、図８は、図１に示したサーバ１の処理を示す処理フロー図であり、図９は、本発明の一実施例における利用者マスタ２の例であり、図１０は、本実施例における電車事故マスタ３の例であり、図１１は、事故発生時のサーバ１の処理フロー図であり、図１２は、事故発生時に利用者の携帯電話１１や端末１２等に表示される画面構成とサーバ１が有するデータとの関連図であり、図１３は、事故情報の更新後における電車事故マスタ３の例であり、図１４は、事故情報の更新後のサーバ１の処理フロー図であり、図１５は、事故処理後の電車事故マスタ３の例であり、図１６は、事故処理後のサーバ１の処理フロー図であり、図１７は、本情報システムの変形例において日単位で複数ルートを設定するルート設定画面２５の例であり、図１８は、本情報システムの変形例において週単位で複数ルートを設定するルート設定画面２６の例であり、図１９は、本情報システムの変形例における解決時間マスタのデータ例である。
【００１８】
＜システム構成＞
図１に、本情報システムのシステム構成図を示す。この情報システムは、サービス提供会社のサーバ１と、電話回線またはネットワークを介してサーバ１からサービスの提供を受ける携帯電話１１または端末１２と、ネットワークを介してサーバ１に情報を提供する交通機関の管理システムとから構成される。
【００１９】
このサーバ１は、交通情報を収集し、登録されている利用者に交通機関の利用経路に対する影響を報知するサービスを提供する（本実施形態では、経路をルートともいう）。具体的には、サーバ１は、携帯電話１１や端末１２等により入力された利用者の情報、例えば、通勤時間帯や利用経路を記録しておく。また、サーバ１は、交通機関の管理システム等から提供される各種交通情報を収集する。各種交通情報とは、交通機関の運行の障害となる虞のある情報、例えば、事故情報等である。そして、サーバ１は、得られた各種交通情報に基づき、交通機関の利用に影響が及ぶ利用者を抽出し、その旨を抽出した利用者に報知する。
【００２０】
このような機能を提供するためサーバ１は、不図示のＣＰＵ、メモリ、ハードディスク、および通信インターフェース等を有している。また、サーバ１は、上記情報を蓄積するため、利用者マスタ２、電車事故マスタ３、道路事故マスタ４、ストマスタ５、イベントマスタ６、および通知マスタ７等のデータベースをハードディスクに有している。また、サーバ１は、通信インターフェースによりネットワークに接続され、利用者の携帯電話１１、端末１２または、交通機関の管理システム等と通信する。
【００２１】
利用者は、手持ちの携帯電話１１や端末１２を使用し、サービス提供の申込みを行う。この申込みでは、利用者の電子メールアドレス、使用する交通機関、経路、利用時間帯等が指定される。
【００２２】
本実施形態では、携帯電話１１には、ＰＨＳ（Personal Handyphone System）を含むものとする。また、端末１１は、ノート型やデスクトップ型のパーソナルコンピュータ、携帯情報端末（Personal Digital(Data) Assistants,PDA ）等である。
【００２３】
上記のような申込みを行った利用者は、利用者マスタ２に登録される。そして、サーバ１は、交通機関の管理システムから事故等の交通情報を受信したとき、その交通情報により影響を受ける利用者を特定し、その旨を報知する。
【００２４】
本実施形態において交通機関は、例えば、鉄道会社（駅）、道路の管理組織（例えば、道路公団等）、バス会社、航空会社、船舶会社等である。これらの交通機関は、鉄道の駅、鉄道会社の管理センタ、道路公団の管理センタ、バス会社の管理センタ、空港のカウンタ、航空会社の管理センタ、支店等に管理システムを備えている。
【００２５】
管理システムは、鉄道、道路等の事故情報、天候、各種イベント、ストライキ等によるダイヤの混乱等の発生をネットワークを通じてサーバ１に報知する。管理システムは、不図示のＣＰＵ、メモリ、ハードディスク、および通信インターフェース等を有するコンピュータである。ただし、このような管理システムをインターネットからアクセス可能なデータセンタ等に設けてもよい。
【００２６】
サーバ１は、そのような交通情報等をネットワークを介して受信し、電車事故マスタ３、道路事故マスタ４、ストマスタ５、イベントマスタ６等に蓄積する。
【００２７】
また、そのような交通情報をＶＩＣＳ（Vehicle Information Communication System：道路交通情報通信システム）センターに収集し、ＶＩＣＳセンターからＦＭ波等を介してサーバ１に配信するようにしてもよい。
【００２８】
また、サーバ１は、発生した交通情報等（事故、天候、ストライキ、イベント等の事象による運行の混乱）の収束時刻を収集する。サーバ１は、そのような事象の発生と収束の時間関係を統計処理し、各事象の種類ごとに解決時間の予測値（これを解決予測時間と呼ぶ）を算出する。そして、サーバ１は、収集した交通情報と、対応する解決予測時間に基づき、影響を受ける利用者を特定し、その利用者にその旨を報知する。
【００２９】
＜データ構造＞
図２は、利用者マスタ２のデータ例である。利用者マスタ２には、利用者に関する各種の情報を格納する。図２の表の各行が１レコードを示し、１人の利用者に対応する。
【００３０】
図２のように、利用者マスタ２の各レコードは、個人ＮＯ、名前、メールアドレス、外出時間、出発駅、経路、退社時間、帰着駅、便名、手段、一定時間、および定期有効期限の各フィールドを有している。
【００３１】
個人ＮＯのフィールドには、個人を識別する番号を格納する。名前のフィールドには、各利用者を識別する名称を格納する。メールアドレスのフィールドには、その利用者の電子メールの宛先アドレスを格納する。外出時間のフィールドには、各利用者が自宅を出発する時間、例えば、通勤や通学の出発時間を格納する。
【００３２】
出発駅のフィールドには、各利用者が鉄道に乗車する駅の駅名やバスに乗車するバス停車場の名称を格納する。なお、図２では、鉄道とバスの場合を例示したが、船舶に乗船する港湾、埠頭名、または航空機に搭乗する空港名等を出発駅のフィールドに格納してもよい。
【００３３】
経路のフィールドには、出発駅から帰着駅までの経路上の駅名を格納する。退社時間のフィールドには、各利用者が帰宅時に職場を出発する時間を格納する。本実施形態では、退社時間としたが、この中には、通学時の退出時間を含めてもよい。
【００３４】
帰着駅のフィールドには、通勤や通学の帰着時に、利用者が鉄道に乗車する駅の駅名やバスに乗車するバス停車場の名称を格納する。ただし、出発駅と同様、船舶に乗船する港湾、埠頭名、または航空機に搭乗する空港名等を出発駅のフィールドに格納してもよい。便名のフィールドには、列車、バス、船舶、または航空機等の便名等を格納する。手段のフィールドには、交通機関の種類を格納する。
【００３５】
一定時間のフィールドには、交通機関の事故処理完了後の経過時間を設定する。この一定時間とは、事故処理完了後、交通機関の運行が正常状態に回復するまでの見込み時間である。事故処理が完了しても、直ちにダイヤが正常に復旧し混雑が緩和するとは限らないからである。この一定時間のフィールドには、利用者ごとに個別に上記時間を設定できる。
【００３６】
定期有効期限とは、各利用者が有する定期券の有効期限である。この定期有効期限のフィールドには、その有効期限かまたは”無効”の文字列が設定される。無効とは、有効期限がないことを示す。サーバ１は、事故等が発生し、本来有効な定期券の経路を利用できない利用者に迂回経路の乗車券をオンラインで発行する。
【００３７】
図３は、電車事故マスタ３のデータ例である。電車事故マスタ３には、電車事故発生時の情報を格納する。図３の表の各行が１レコードを示し、１つの事故に対応する。
【００３８】
図３のように、電車事故マスタ３の各レコードは、ＩＤ、年月日、駅名、路線、事故発生時間、解決予想時間、ストップ区間、解決時間、原因、状況、および更新時間の各フィールドを有している。
【００３９】
ＩＤは、電車事故マスタ３の各レコードをユニークに識別する情報である。したがって、このＩＤは、各電車事故を特定する情報となる。年月日は、電車事故の発生年月日である。
【００４０】
駅名は、事故発生地点最寄りの駅名である。事故発生時刻は、当該事故の発生時刻である。解決予想時間は、その事故処理の完了予想時間である。この解決予想時間は、過去の事故の種類ごとに、解決時間の実績を統計処理した結果である。
【００４１】
ストップ区間は、その事故により鉄道の運行が停止している線路の区間である。解決時間は、その事故処理の実際の完了年月日および時刻である。原因は、事故の発生原因であり、例えば、車両事故、人身事故、または強風等の自然災害等である。
【００４２】
状況のフィールドには、現在の状況を記録する。例えば、土砂取り作業中等が記録される。また、更新時間のフィールドには、当該レコードが更新された最後の年月日時刻を記録する。
【００４３】
図４は、道路事故マスタ４のデータ例である。道路事故マスタ４には、道路事故発生時の情報を格納する。図４の表の各行が１レコードを示し、１つの事故に対応する。
【００４４】
図４のように、道路事故マスタ４の各レコードは、ＩＤ、年月日、道路、会社、事故発生時間、解決予想時間、ストップ区間、解決時間、原因、状況、および更新時間の各フィールドを有している。
【００４５】
これらのうち、ＩＤ、年月日、事故発生時間、解決予想時間、解決時間、原因、状況、および更新時間の各フィールドは、電車事故マスタ３の場合と同様であるので、その説明を省略する。
【００４６】
また、道路のフィールドには、当該事故が発生した道路の名称を記録する。また、会社のフィールドには、その道路においてバスやタクシー等車両の運行を管理する交通機関の会社名を記録する。
【００４７】
また、ストップ区間のフィールドには、道路の通行が禁止されている区間の両端の地点の地名を格納する。ただし、高速道路や自動車専用道路については、ストップ区間として、通行が禁止されている区間の両端のインターチェンジの名称を格納すればよい。
【００４８】
図５は、ストマスタ５のデータ例である。ストマスタ５には、ストライキ発生時の情報を格納する。図５の表の各行が１レコードを示し、１つのストライキに対応する。
【００４９】
図５のように、ストマスタ５の各レコードは、ＩＤ、年月日、会社名、区間、開始、解決予想時間、終了、および更新時間の各フィールドを有している。
【００５０】
これらのうち、ＩＤ、年月日、解決予想時間、および更新時間の各フィールドは、電車事故マスタ３や道路事故マスタ４の場合と同様であるので、その説明を省略する。
【００５１】
また、会社名のフィールドには、ストライキが発生した会社名またはその会社の運行する鉄道の名称、船舶会社の航路名、航空会社の航路名を記録する。区間は、ストライキの対象区間である。ストライキが特定の区間で実施される場合、区間のフィールドには、その区間を挟む両端の駅名、バス停車場名、航路の出発地と目的地等が設定される。
【００５２】
開始のフィールドには、ストライキへ突入した年月日および時刻を記録する。ただし、時刻に代えて、ストライキの対象となる最初の便名、例えば、”始発”等を記録してもよい。また、終了のフィールドには、ストライキが解除された年月日および時刻を記録する。
【００５３】
図６は、イベントマスタ６のデータ例である。イベントマスタ６には、交通機関に影響を及ぼすイベントの情報を格納する。図６の表の各行が１レコードを示し、１つのイベントに対応する。
【００５４】
図６のように、イベントマスタ６の各レコードは、ＩＤ、年月日、イベント、開始時間、終了時間、路線番号、備考、駅名および更新時間の各フィールドを有している。
【００５５】
これらのうち、ＩＤ、年月日、および更新時間の各フィールドは、電車事故マスタ３、道路事故マスタ４、またはストマスタ５の場合と同様であるので、その説明を省略する。
【００５６】
イベントのフィールドには、イベントの名称を格納する。イベントは、例えば、花火大会、競馬、競輪またはサッカー等の競技会等である。
【００５７】
また、開始時間のフィールドには、イベントの開始予定時刻を記録する。また、終了時刻のフィールドには、イベントの終了予定時刻を記録する。
【００５８】
路線番号は、イベントの影響を受ける交通機関の路線である。路線番号は、例えば、鉄道の路線名、バスの路線、船舶や航空機の航路等である。備考の欄には、増発情報等を記録する。駅名は、上記路線のうち、イベントの影響を受ける駅名、バス停車場名、港湾、空港名等である。
【００５９】
図７は、事故通知マスタ７のデータ例である。事故通知マスタ７には、交通機関に影響を及ぼす事故やイベント等の障害が発生したときに、その旨の通知を受ける利用者、すなわち、サーバ１からのサービスを受ける利用者を、各障害ごとに記憶する。ただし、一度事故通知をして、その後の情報を必要ないとした利用者は、事故通知マスタ７には記憶されない。なお、本実施形態では、本来の事故の他、イベント、ストライキ等、交通機関の各種障害となる事項を事故と呼ぶことにする。
【００６０】
図７の表の各行が１レコードを示し、１つの事故および１人の利用者に対応する。図７のように、事故通知マスタ７の各レコードは、ＩＤ、個人ＮＯ、通知の各フィールドを有している。
【００６１】
ＩＤのフィールドには、電車事故マスタ３、道路事故マスタ４、ストマスタ５、またはイベントマスタ６のＩＤが設定される。ＩＤは、事故通知マスタ７の当該行がどの事故情報と関連するかを明示する。
【００６２】
また、個人ＮＯのフィールドには、当該事故に対して事故情報の通知を受ける利用者を識別する番号を設定する。通知のフィールドには、上記通知を毎回受けるか、解決時にのみ受けるかを設定する。
【００６３】
例えば、通知のフィールドにＹＥＳが設定されると、その利用者には事故ＩＤに関連する事故情報が毎回通知される。また、通知のフィールドに”解決時のみ”が設定されると、その利用者には、事故の解決時にのみ、その旨が通知される。
【００６４】
＜サーバ１の処理＞
図８に、本実施形態におけるサーバ１の処理フローを示す。サーバ１は、交通機関等から事故情報等を受信すると図８の処理を実行する。
【００６５】
事故情報等を受信すると、まず、サーバ１は、その事故情報を電車事故マスタ３や道路事故マスタ４等に登録する（Ｓ１）。次に、サーバ１は、解決時間の予測値（解決予想時間）を算出し、電車事故マスタ３（図３）または道路事故マスタ４（図４）の解決予想時間のフィールドに格納する（Ｓ２）。
【００６６】
解決予想時間の算出は、過去の類似する事故について、電車事故マスタ３または道路事故マスタ４における事故発生から解決までの時間の実績値を集計し、所定の統計処理を行う処理である。ただし、報道機関の発表による予測時間、気象庁等の天気予報等を解決時間として用いてもよい。例えば、悪天候による鉄道、道路の不通、航路運行見合わせのような場合である。
【００６７】
次に、サーバ１は、利用者マスタ２を順次検索する。そして、各利用者の交通機関の利用経路（例えば、図８では、通勤路とされている）とその事故とが関係するか否かをチェックする（Ｓ３）。
【００６８】
その利用者の利用経路が事故の地点と関係する場合（Ｓ４でＹＥＳの場合）、サーバ１は、その事故がその利用者の利用時間帯（通勤時間帯）に関係するか否かをチェックする（Ｓ５）。
【００６９】
その事故がその利用者の利用時間帯に関係するとは、例えば、実行発生時刻から解決予想時間経過までの間に、その利用者の出発時間や帰着時間が含まれている場合等をいう。また、出発時間や帰着時間からさらに、その事故地点まで移動する移動後の時刻が、事故発生時刻から解決予想時間経過までの間に含まれている場合をもいう。
【００７０】
このとき、出発や帰着から所定時間（図２の利用者マスタ２に示した一定時間のフィールドに設定された時間）の範囲内ですでに解決している事故をも報知の対象としてもよい。電車や道路の事故では、事故処理後にダイヤの乱れや道路の渋滞等が発生し、スムーズに交通機関が運行されるとは限らないからである。
【００７１】
利用経路と利用時間帯の両方がその事故と関係する場合（Ｓ６でＹＥＳの場合）、サーバ１は、当該利用者にその旨の電子メールを送信する（Ｓ７）。この電子メールには、事故情報そのものの他、代替ルート、解決見込み時間も通知すればよい。また、サーバ１は、代替経路を選択した場合、振替切符を利用者の携帯電話１１に送信する。
【００７２】
以上のＳ３からＳ５の処理は、利用者マスタ２に登録したすべての利用者に順次実施される。
【００７３】
さらに、サーバ１は、事故通知マスタ７に事故ＩＤと事故を通知した個人ＮＯを登録し、交通状況に変化があった場合、その都度通知し、解決するまで通知を続ける（Ｓ８）。ただし、別手段や別経路で目的地に到達し、通知が不要になった場合には、オプションでメールによる通知を停止させてもよい。そのため、メールによる通知を停止させる停止ボタン等を送信するメールの電文内に設ければよい。
【００７４】
＜実施例＞
図９から図１６により、本発明の一実施例を説明する。図９のように、本実施例では、例えば、青木さんは、外出時間が７時であり、Ｋ鉄線調布を出発駅とし、新宿経由で□鉄恵比寿駅まで通勤する。また、青木さんの退社時間は、通常１８時である。
【００７５】
また、例えば、笠原さんは、外出時間が８時であり、Ｋ鉄線調布を出発駅とし、新宿経由で□鉄恵比寿駅まで通勤する。また、笠原さんの退社時間は、通常１９時３０分である。
【００７６】
今、図１０のように、Ｋ鉄線笹塚駅において、１７時３０分に人身事故が発生し、笹塚〜明大前の間の運行がストップしていると仮定する（笹塚駅と明大前は、ともに調布と新宿の間にある）。
【００７７】
この場合のサーバ１の処理例を図１１に示す。事故が発生すると、サーバ１は、まず、電車事故マスタ３に事故のデータを登録する（Ｓ１０）。
【００７８】
次に、サーバ１は、利用者マスタ２の手段、経路、出発駅、帰着駅からこの事故の影響を受ける利用者（影響者）を特定する（Ｓ１１）。
【００７９】
そして、サーバ１は、利用者マスタ２において影響を受けると判定された利用者（影響者）の出社・退社時刻と、電車事故マスタの事故の発生時間、解決予想時間とを比較し、通知すべきか否かを判定する（Ｓ１２）。そして、サーバ１は、通知すべき利用者に事故情報を通知し、事故マスタ７に登録する（Ｓ１３）。
【００８０】
例えば、図９の利用者マスタ２において、青木さん（個人ＮＯは０００１）の退社時間は、１８時であり、事故発生の１７時３０分から解決予想時間（６０分）後の１８時３０分までの間に含まれる。したがって、青木さんは、影響を受けると判断される。
【００８１】
一方、笠原さん（個人ＮＯは０００２）の退社時間は、１９時３０分であり、事故発生の１７時３０分から解決予想時間（６０分）後の１８時３０分までの間に含まれない。したがって、笠原さんは、影響を受けないと判断される。したがって、青木さんには事故の旨が通知され、笠原さんには通知がされない。
【００８２】
利用者は、この通知に対して、さらに、継続して通知を受けるか、以降の通知が不要であるか、あるいは、事故解決時のみ通知を受けるかを指定する。サーバ１は、そのような利用者の指定にしたがい、事故通知マスタ７の各利用者の通知のフィールドに、ＹＥＳ（継続して通知を受信）、または、”解決時のみ”（事故解決時のみ、通知を受信）を設定する。
【００８３】
図１２は、事故発生時に利用者の携帯電話１１や端末１２等表示される画面構成とサーバ１が有するデータとの関連図である。図１２の画面２０は、事故情報を通知する電子メールの表示例である。
【００８４】
この例では、＜事故情報＞というタイトル以下に、場所（路線と最寄り駅）、ストップ区間、事故の発生時間、解決予想時間、事故の原因、発生現場、その他の情報、例えば、現状の運転状況等、代替輸送機関、および”今後も情報が必要か？”という問い合わせ等が表示されている。
【００８５】
また、画面内には詳細ボタン、代替ルートボタン、ＹＥＳボタン、ＮＯボタンおよび”解決時のみ”というラベルが付されたボタンが配置されている。ユーザが詳細ボタンを選択すると、詳細画面２１へのリクエストがサーバ１に送信される。ここで、選択とは、携帯電話に附属の不図示のスクロールボタン等で項目を指定し、不図示の決定ボタン等でその指定を確定するような操作をいう。また、利用者が端末１２を使用する場合には、マウス、タッチパネル、スティック形状、または静電式等のポインティングデバイスで押下操作することをいう。
【００８６】
サーバ１は、そのリクエストに応答して、詳細画面２１のデータを携帯電話１１等に送信し、詳細画面２１を表示させる。詳細画面２１には、事故の詳細情報や関連情報のリンク先等が表示される。このようなサーバ１と携帯電話１１等の間の通信手順としては、例えば、ＨＴＴＰ（HyperText Transfer Protocol ）が広く知られている。
【００８７】
また、利用者が代替ルートボタンを選択すると、同様の手順で、代替ルート画面２２が表示される。代替ルート画面２２には、事故の発生した路線に代わる経路（経由する駅のリスト等）、利用する交通機関の種類、例えば、電鉄会社名、バス会社名等、および振替切符ボタンが表示される。
【００８８】
利用者が振替切符ボタンを選択すると、携帯電話１１や端末１２からサーバ１２に振替切符画面２３表示のリクエストが発信される。
【００８９】
サーバ１は、このリクエストに対して、利用者マスタ２を参照し、その利用者の定期券が有効か否かを判定する。そして、利用者の定期券が有効な場合、振替切符画面２３を構成するデータを携帯電話１１等に送信し、携帯電話１１等に振替切符画面２３を表示させる。
【００９０】
利用者は、携帯電話１１等の振替切符画面２３に表示された振替切符を改札で表示すればよい。また、振替切符ボタンが選択されたときに、携帯電話１１のアンテナから自動改札機へ振替切符データを微弱電波で送信し、自動改札を通過できるようにしてもよい。また、携帯電話１１に、ＩＣカード型の定期券と同様のアンテナを具備しておき、振替切符が表示されている状態では、携帯電話１１がＩＣカード型の定期券と同様の電磁波を発信し、自動改札を通過できるようにしてもよい。
【００９１】
また、利用者が”今後も情報が必要か？”という問い合わせに対して、ＹＥＳボタンを選択すると、携帯電話１１や端末１２からサーバ１に所定の書き込み指令が送信される。この書き込み指令には、事故等を特定するＩＤおよび利用者を特定する情報と、事故通知マスタ７の当該ＩＤおよび当該利用者の行にＹＥＳを設定させる指示が含まれている。この指令に対し、サーバ１は、事故通知マスタ７の当該ＩＤおよび当該利用者の行にＹＥＳを設定する。これにより、所定期間ごと、または、状況の変化ごとの利用者への通知が継続される。このような指令は、事故情報を表示する携帯電話１１の表示プログラムとサーバ１との専用の通信手順で授受してもよい。または、上記ＹＥＳボタンの押下により、上記指令を含む電子メールを携帯電話１１等からサーバ１に発信するように構成してもよい。
【００９２】
一方、利用者がＮＯボタンを選択すると、事故通知マスタ７から該当する事故ＩＤの当該利用者の行を削除する。また、利用者が”解決時のみ”というラベルの付されたボタンを選択すると、事故通知マスタ７の当該ＩＤおよび当該利用者の行に”解決時のみ”という文字列が設定され、以降の通知は、事故処理の完了まで停止される。
【００９３】
図１３に、事故情報更新後の電車事故マスタ３の例を示す。この例では、図１０の場合と比較して、解決予想時間は９０分に延長され、状況のフィールドに、”現場検証が難航しており・・・”という文字列が設定されている。
【００９４】
図１４に、この場合のサーバ１の処理例を示す。事故情報の更新を受信するか、または、所定の期間ごとに、サーバは、図１４に示す処理を実行する。この処理のうち、Ｓ２０〜Ｓ２２は、事故発生時のサーバ１の処理フロー（図１１）と同様である。
【００９５】
すなわち、利用者マスタ２の情報と、電車事故マスタ３の情報との関係から該当する利用者を特定した後（Ｓ２２）、サーバ１は、更新された事故情報のＩＤで事故通知マスタ７を検索し、レコードが存在した場合に、その利用者の通知継続の意思を確認をする（Ｓ２３）。そして、当該事故の影響を受けると判定され、さらに、通知継続の意思が確認された利用者に事故の更新情報が通知される（Ｓ２４）。
【００９６】
この例では、解決予想時間が９０分に延長されたため、処理結果は、図１１の場合とは相違する。すなわち、１７時３０分に事故が発生し、解決予想時間が９０分なので、１９時まで電車が止まることになる。
【００９７】
すると、図９の利用者マスタ２において、青木さん（個人ＮＯが０００１）の退社時間は、１８時であり、事故発生の１７時３０分から解決予想時間（９０分）後の１９時までの間に含まれる。したがって、青木さんは、影響を受けると判断される。これは、事故情報の更新前と同様である。ただし、事故通知マスタ７の青木さんの行（個人ＮＯが０００１）には、”解決時のみ”との指定がされているため、青木さんには、通知はされない（Ｓ２４）。
【００９８】
一方、笠原さん（個人ＮＯが０００２）の退社時間は、１９時３０分であり、事故発生の１７時３０分から解決予想時間（９０分）後の１９時までの間に含まれない。ただし、笠原さんは、一定時間のフィールドが３０分とされており、退社３０分前までの事故情報を通知するように指定している。したがって、笠原さんは、退社の３０分前である１９時から影響を受けると判断されるので、笠原さんには事故情報が通知され、事故通知マスタに登録される（個人ＮＯが０００２）。
【００９９】
図１５に、事故処理後の電車事故マスタ３の例を示す。この例では、図１３の例と比較して、解決時間が１９時３０分と記録されており、事故処理が完了している。
【０１００】
図１６に、事故処理後のサーバ１の処理フローを示す。事故処理が完了すると、サーバ１は、図１６の処理を実行する。この処理では、サーバ１は、まず、更新された事故情報のＩＤで事故通知マスタ７を検索し、レコードの存在を確認をする（Ｓ３０）。
【０１０１】
そして、サーバ１は、該当者に事故情報（解決した旨）を通知する（Ｓ３１）。例えば、図１６に示すように、事故通知マスタ７において、当該電車事故（ＩＤ＝ＩＤ１で特定される）について、解決時のみ事故情報の通知を要求する青木さん（個人ＮＯが０００１）に、事故情報が通知される。
【０１０２】
次に、サーバ１は、事故通知マスタ７から解決した事故のＩＤ（＝ＩＤ１）のレコードを削除する（Ｓ３２）。
【０１０３】
このように、本実施形態のサーバ１は、本来通知が必要な利用者（影響者）を抽出し、そのような利用者に通知が送信される。したがって、事故の影響を受ける利用者は、能動的に検索しなくてもサーバ１からの通知により事故の発生に気づくことができる。一方、事故の影響を受けない利用者には通知がされないので、不要な通知を受けることが少なくなる。
【０１０４】
また、本サーバ１によれば、事故発生後の通知において、利用者に以降継続して通知を受けるか、以降の通知が不要か、または、事故の解決時にのみ通知を受けるかを選択させる。したがって、利用者は、自身の都合や希望に応じて、通知の受信可否を指定できる。
【０１０５】
また、本サーバ１によれば、事故の影響を受ける経路に対する代替ルートを利用者に表示する。そして、利用者が代替ルートの利用を選択したときに、その代替ルートを形成する交通機関を利用するための振替切符を携帯電話１１等に表示し、または、自動改札用の電磁波を出力する。したがって、事故発生時、振替切符をスムーズに配布することができる。
【０１０６】
＜ルート設定の変形例＞
上記実施形態では、利用者マスタ２に、利用者ごとに、通常の外出時間、経路、帰着時間等を半固定的に設定し、当該利用者が事故の影響を受けるか否かを判定した。すなわち、上記実施形態では、主として、通勤や通学等、長期に渡って継続的に行う利用者の行動に基づき、事故情報を通知する利用者を特定した。しかし、本発明の実施は、このような構成や手順には限定されない。
【０１０７】
例えば、日単位や週単位のような短期の行動予定を予めサーバ１に登録しておき、そのような短期の行動予定に基づいて、事故の影響を受ける利用者を抽出するようにしてもよい。
【０１０８】
図１７は、携帯電話１１または端末１２において表示される、日単位に複数ルートを設定するルート設定画面２５の例である。この画面では、外出時間、出発駅、経路、帰着駅を１つのスケジュールの単位として、複数のスケジュールを設定することができる。例えば、午前と午後とで、異なる出張先へ出張する等の場合において、上記のような設定がされる。設定内容は、上記実施形態と同様、サーバ１のデータベースに蓄積すればよい。
【０１０９】
サーバ１は、事故情報受信時、利用者の日単位のスケジュールを検索し、その事故の影響を受ける利用者を抽出すればよい。
【０１１０】
図１８は、携帯電話１１または端末１２において表示される、週単位に複数ルートを設定するルート設定画面２６の例である。この画面では、横方向に外出時間、出発駅、経路、退社時間、および帰着駅からなるカラムが構成されている。また、この画面の上下方向には、上記カラムが月曜日〜日曜日まで１週間分配置されている。
【０１１１】
利用者は、携帯電話１１または端末１２において、ルート設定画面２６により、１週間分のスケジュールを設定する。設定内容は、上記実施形態の場合と同様、サーバ１のデータベースに蓄積すればよい。
【０１１２】
サーバ１は、事故情報受信時、利用者の週単位のスケジュールを検索し、その事故の影響を受ける利用者を抽出すればよい。
【０１１３】
＜その他の変形例＞
上記実施形態では、利用者の帰着時刻と事故の発生時刻の関係から、サーバ１の処理を例示した。このような処理は、出発時刻に対しても同様に実行される。また、単純に、帰着時刻や出発時刻と、事故の発生時刻を比較するだけでなく、帰着時刻や出発時刻に事故地点までの移動時間を加算した時刻と、事故の発生時刻を比較するようにしてもよい。事故地点までの移動時間は、各交通機関から発表され、インターネット上のウェブページ等に掲載されたダイヤから検索することができる。
【０１１４】
上記実施形態では、事故等が発生した場合、サーバ１が事故情報を受信し、関連する利用者に電子メールで報知した。しかし、本発明の実施は、このような手順には限定されない。例えば、出発地と目的地等を入力し、その間の経路における事故情報や交通情報等を随時検索するようにしてもよい。
【０１１５】
上記実施形態では、事故発生時に、サーバ１が電車事故マスタ３や道路事故マスタ４に保持されている解決時間の実績データを集計し、解決予測時間を算出した。しかし、本発明の実施はそのような手順には限定されない。
【０１１６】
例えば、事故処理が完了し、利用者への通知完了後に、そのような解決時間の実績を集計してもよい。また、所定の時期に定期的にそのような解決時間の実績を集計する処理プログラムを起動するようにしてもよい。そのような集計の結果に基づき、解決予想時間を算出し、データベースに保持しておけばよい。
【０１１７】
図１９は、そのような解決予想時間を保持する解決時間マスタのデータ例である。解決時間マスタは、交通機関に影響を及ぼす事故の原因ごとに、その事故処理が完了する解決時間の予測値を保持する。
【０１１８】
図１９の表の各行が１レコードを示し、１つの事故原因に対応する。図１９のように、解決時間マスタの各レコードは、事故マスタ種別、原因、および解決時間の各フィールドを有している。
【０１１９】
このうち、事故マスタ種別のフィールドには、当該事故を記録する事故マスタの種別、例えば、電車事故、道路事故等を記録する。また、原因のフィールドには、各事故の原因を記録する。
【０１２０】
解決時間のフィールドには、各事故原因の事故が発生したときに、その事故処理が完了する解決時間の予測値を記録する。この予測値は、電車事故マスタ３、道路事故マスタ４等の事故発生時間から解決までの経過時間（解決時間）の実績値を収集し、統計処理したものである。
【０１２１】
統計処理とは、例えば、平均値、最大値、または、解決時間の分布における比率に基づく処理、例えば、当該原因による全事故数の解決時間の分布に対して、その解決時間以内の事故数が９５％となるような解決時間を求める処理等である。
【０１２２】
事故発生時に、サーバ１は、逐一解決時間を算出するのではなく、事故の種類（事故マスタの種類）と事故原因とに基づき、解決時間マスタを参照すればよい。このような手順により、事故発生時の通知を迅速に実行できる。
【０１２３】
上記実施例では、電車事故を例に、サーバ１の機能を説明した。しかし、このような機能は、道路事故によるバスの運行停止、天候不良による船舶の出航停止、航空機の発着停止、各種イベントによる交通機関の遅延、ストライキによる交通機関の停止時等においても利用できる。
【０１２４】
上記実施形態では、利用者マスタ２（図２）に示したように、利用者の外出時間、または退社時間のように、交通機関を利用するための出発時間に基づき、電車事故等による影響を判定した。しかし、本発明の実施は、そのような手順には限定されない。例えば、利用者マスタ２において、交通機関を利用する利用時間帯（例えば、通勤時間帯として午前７時〜８時、帰着時間帯として午後６時〜７時等）を記録するようにしてもよい。サーバ１は、そのような利用時間帯、事故の発生時刻および解決予想時間により、事故の影響を判定するようにしてもよい。
【０１２５】
＜コンピュータ読み取り可能な記録媒体＞
コンピュータに上記いずれかの機能を実現させるプログラムをコンピュータ読み取り可能な記録媒体に記録することができる。そして、コンピュータに、この記録媒体のプログラムを読み込ませて実行させることにより、その機能を提供させることができる。
【０１２６】
ここで、コンピュータ読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータから読み取ることができる記録媒体をいう。このような記録媒体のうちコンピュータから取り外し可能なものとしては、例えばフロッピーディスク、光磁気ディスク、CD-ROM、CD-R/W、DVD、DAT、８mmテープ、メモリカード等がある。
【０１２７】
また、コンピュータに固定された記録媒体としてハードディスクやＲＯＭ（リードオンリーメモリ）等がある。
【０１２８】
＜搬送波に具現化されたデータ通信信号＞
また、上記プログラムは、コンピュータのハードディスクやメモリに格納し、通信媒体を通じて他のコンピュータに配布することができる。この場合、プログラムは、搬送波によって具現化されたデータ通信信号として、通信媒体を伝送される。そして、その配布を受けたコンピュータに上記機能を提供させることができる。
【０１２９】
ここで通信媒体としては、有線通信媒体、例えば、同軸ケーブルおよびツイストペアケーブルを含む金属ケーブル類、光通信ケーブル等、または、無線通信媒体例えば、衛星通信、地上波無線通信等のいずれでもよい。
【０１３０】
また、搬送波は、データ通信信号を変調するための電磁波または光である。ただし、搬送波は、直流信号でもよい。この場合、データ通信信号は、搬送波がないベースバンド波形になる。したがって、搬送波に具現化されたデータ通信信号は、変調されたブロードバンド信号と変調されていないベースバンド信号（電圧０の直流信号を搬送波とした場合に相当）のいずれでもよい。
【０１３１】
＜その他＞
さらに、本実施の形態は以下の発明を開示する。
（付記１） コンピュータが、利用者ごとに交通機関を利用する経路および利用する時期に係る情報の設定を受けるステップと、
前記交通機関の運行を阻害する事象の種類、およびその事象の発生時刻を収集するステップと、
前記事象の解消時刻を推定するステップと、
前記交通機関利用時における前記事象による影響の有無を利用者ごとに判定するステップと、
前記影響があると判定される利用者にその旨を報知するステップとを実行する通報方法。（１）
（付記２） 前記事象による影響が少ない代替経路を報知するステップをさらに実行する付記１記載の通報方法。（２）
（付記３） 前記報知するステップでは、前記事象の解消予定時刻またはその事象が解消した旨が報知される付記１記載の通報方法。（３）
（付記４） 前記代替経路の選択を促すステップと、
選択された代替経路において交通機関の利用許可を示す許可情報を利用者の端末に出力させるステップとをさらに実行する付記２記載の通報方法。（４）
（付記５） コンピュータに、利用者ごとに交通機関を利用する経路および利用する時期に係る情報の設定を受けるステップと、
前記交通機関の運行を阻害する事象の種類、およびその事象の発生時刻を収集するステップと、
前記事象の解消時刻を推定するステップと、
前記交通機関利用時における前記事象による影響の有無を利用者ごとに判定するステップと、
前記影響があると判定される利用者にその旨を報知するステップとを実行させるプログラム。（５）
（付記６） 利用者ごとに交通機関を利用する経路および利用する時期に係る情報の設定を受ける手段と、
前記交通機関の運行を阻害する事象の種類、およびその事象の発生時刻を収集する手段と、
前記事象の解消時刻を推定する手段と、
前記交通機関利用時における前記事象による影響の有無を利用者ごとに判定する手段と、
前記影響があると判定される利用者にその旨を報知する報知手段とを備える通報サーバ。
【０１３２】
【発明の効果】
以上説明したように、本発明によれば、利用者の能動的な意思によらないで、交通機関の障害による利用者への影響を軽減させることができる。
【図面の簡単な説明】
【図１】 本発明の一実施の形態に係る情報システムのシステム構成図
【図２】 利用者マスタ２のデータ例
【図３】 電車事故マスタ３のデータ例
【図４】 道路事故マスタ４のデータ例
【図５】 ストマスタ５のデータ例
【図６】 イベントマスタ６のデータ例
【図７】 事故通知マスタ７のデータ例
【図８】 サーバ１の処理を示す処理フロー図
【図９】 本発明の実施例における利用者マスタ２の例
【図１０】本発明の実施例における電車事故マスタ３の例
【図１１】事故発生時のサーバ１の処理フロー図
【図１２】事故発生時に利用者の携帯電話１１や端末１２等表示される画面構成とサーバ１が有するデータとの関連図
【図１３】事故情報の更新後の電車事故マスタ３の例
【図１４】事故情報の更新後のサーバ１の処理フロー図
【図１５】事故処理後の電車事故マスタ３の例
【図１６】事故処理後のサーバ１の処理フロー図
【図１７】日単位で複数ルートを設定するルート設定画面の例
【図１８】週単位で複数ルートを設定するルート設定画面の例
【図１９】解決時間マスタ７のデータ例
【符号の説明】
１ サーバ
２ 利用者マスタ
３ 電車事故マスタ
４ 道路事故マスタ
５ ストマスタ
６ イベントマスタ
７ 通知マスタ
１１ 携帯電話
１２ 端末
２０ 画面
２２ 代替ルート画面
２３ 振替切符画面

Claims (10)

1. コンピュータが、公共交通機関を利用する利用者ごとに公共交通機関を利用する経路および利用する時期に係る情報の設定、前記利用者ごとに報知所定時間に係る情報の設定を受けるステップと、
   前記公共交通機関の運行を阻害する事象の種類、およびその事象の発生時刻を収集するステップと、
   前記事象の解消時刻を推定するステップと、
   前記公共交通機関利用時における前記事象による影響の有無を利用者ごとに判定するステップと、
   前記影響があると判定される利用者にその旨を報知するステップと、を実行し、
   前記判定するステップは、前記利用する時期から前記報知所定時間の範囲内に前記事象の解消時刻が含まれる場合、前記事象による影響があると判定する、
   通報方法。
2. コンピュータが、公共交通機関を利用する利用者ごとに公共交通機関を利用する経路および利用する時期に係る情報の設定、前記利用者ごとに継続通知の要否に係る情報の設定を受けるステップと、
   前記公共交通機関の運行を阻害する事象の種類、およびその事象の発生時刻を収集するステップと、
   前記事象の解消時刻を推定するステップと、
   前記公共交通機関利用時における前記事象による影響の有無を利用者ごとに判定するステップと、
   前記影響があると判定される利用者にその旨を報知するステップと、を実行し、
   前記報知するステップは、前記継続通知の要否に係る情報に基づいて、前記影響があると判定される利用者に継続的に前記事象による影響を通知する、
   通報方法。
3. 前記事象による影響が少ない代替経路を報知するステップをさらに実行する請求項１および２のいずれか１つに記載の通報方法。
4. 前記報知するステップでは、前記事象の解消予定時刻またはその事象が解消した旨が報知される請求項１および２のいずれか１つに記載の通報方法。
5. 前記代替経路の選択を促すステップと、
   選択された代替経路において公共交通機関の利用許可を示す許可情報を利用者の端末に出力させるステップと
   をさらに実行する請求項３に記載の通報方法。
6. 前記事象の解消時刻を推定するステップは、外部機関から事象の解消時刻を入手する、
   請求項１および２のいずれか１つに記載の通報方法。
7. コンピュータに、公共交通機関を利用する利用者ごとに公共交通機関を利用する経路および利用する時期に係る情報の設定、前記利用者ごとに報知所定時間に係る情報の設定を受けるステップと、
   前記公共交通機関の運行を阻害する事象の種類、およびその事象の発生時刻を収集するステップと、
   前記事象の解消時刻を推定するステップと、
   前記公共交通機関利用時における前記事象による影響の有無を利用者ごとに判定するステップと、
   前記影響があると判定される利用者にその旨を報知するステップとを実行させ、
   前記判定するステップは、前記利用する時期から前記報知所定時間の範囲内に前記事象の解消時刻が含まれる場合、前記事象による影響があると判定する、
   プログラム。
8. コンピュータに、公共交通機関を利用する利用者ごとに公共交通機関を利用する経路および利用する時期に係る情報の設定、前記利用者ごとに継続通知の要否に係る情報の設定を受けるステップと、
   前記公共交通機関の運行を阻害する事象の種類、およびその事象の発生時刻を収集するステップと、
   前記事象の解消時刻を推定するステップと、
   前記公共交通機関利用時における前記事象による影響の有無を利用者ごとに判定するステップと、
   前記影響があると判定される利用者にその旨を報知するステップとを実行させ、
   前記報知するステップは、前記継続通知の要否に係る情報に基づいて、前記影響があると判定される利用者に継続的に前記事象による影響を通知する、
   プログラム。
9. 公共交通機関を利用する利用者ごとに公共交通機関を利用する経路および利用する時期に係る情報の設定、前記利用者ごとに報知所定時間に係る情報の設定を受ける手段と、
   前記公共交通機関の運行を阻害する事象の種類、およびその事象の発生時刻を収集する手段と、
   前記事象の解消時刻を推定する手段と、
   前記公共交通機関利用時における前記事象による影響の有無を利用者ごとに判定する手段と、
   前記影響があると判定される利用者にその旨を報知する手段を備え、
   前記判定する手段は、前記利用する時期から前記報知所定時間の範囲内に前記事象の解消時刻が含まれる場合、前記事象による影響があると判定する、
   通報サーバ。
10. 公共交通機関を利用する利用者ごとに公共交通機関を利用する経路および利用する時期に係る情報の設定、前記利用者ごとに継続通知の要否に係る情報の設定を受ける手段と、
    前記公共交通機関の運行を阻害する事象の種類、およびその事象の発生時刻を収集する手段と、
    前記事象の解消時刻を推定する手段と、
    前記公共交通機関利用時における前記事象による影響の有無を利用者ごとに判定する手段と、
    前記影響があると判定される利用者にその旨を報知する手段とを備え、
    前記報知する手段は、前記継続通知の要否に係る情報に基づいて、前記影響があると判定される利用者に継続的に前記事象による影響を通知する、
    通報サーバ。

Images