JP2013170900A - 経路案内方法、経路案内装置、及びコンピュータプログラム - Google Patents

Abstract

【課題】現実の運行状況の案内およびそれに基づく経路探索を可能にする。
【解決手段】列車に乗車中の携帯端末５０から端末位置の変位を表す端末変位情報と、ダイヤ情報と各駅の位置を含む運行情報とを取得する。経路探索サーバ１０は、取得した端末変位情報と運行情報とを照合することにより当該ユーザが乗車中の列車の駅間の動きを特定し、これにより当該時刻以降のダイヤからの変更を表すダイヤ変更情報を、当該列車が現実に到着又は出発した駅毎に生成し、このダイヤ変更情報を更新自在に記録する。その後、携帯端末５０からの経路探索要求に応じて運行情報および最新のダイヤ変更情報による経路探索を行い、探索結果を携帯端末５０へ提供する。
【選択図】図１

Description

本発明は、列車、バス等の公共交通機関を利用して、任意の出発地から目的地に至る経路を探索する経路探索技術に関し、特に、現実の電車等の運行状況に基づくリアルタイムの経路探索を可能にする技術に関する。

目的地まで短時間で公共交通機関を利用して移動する、或いは運賃が安くなるように移動する、といったユーザの希望する条件を満たす経路を探索してユーザに提供するサービスは、ホームページや市販されているソフトウェアにて提供されている。これらのサービスの多くは、予め各交通機関が提示している運行予定に基づいて、ユーザが指定する出発地から目的地までの経路を、希望到着時刻や出発時刻等のユーザの指定する条件を満たすように探索して、ユーザに提示するものである。

上記サービスは、公共交通機関が定時運行することが前提となっている。しかし、ユーザが実際に移動するときは、事故や混雑により定時運行できずに、遅延が発生することがある。このような場合には、交通機関のホームページやメール配信サービス等により、運行状況を確認して各自対処することになるが、遅延の発生がわかっても、その時点の列車の運行本数や目的地までの所要時間まではわからない。そのため、探索結果により得られた路線を利用した場合の目的地への到着時刻が予測できず、遠回りしてでも、迂回経路を利用すべきかどうかの判断に迷うことがある。

特許文献１には、このような場合の運行状況を考慮して経路探索を行い、ユーザに最適な経路探索結果を提供する経路案内システムが開示されている。特許文献１のシステムでは、運行状況を最新の列車の運行状況を保持する列車情報基地局から取得して、経路探索を行う。

特開２００３−９０７３３号公報（段落０００６）

列車情報基地局から取得する運行状況は、公式には最新の情報である。しかし、現実には、現場との間にタイムラグが生じたり、再開の見通しが不明の車両点検等が突発的に発生したりする。そのため、列車に乗車中のユーザ、特に目的地まで早く到着したいユーザにとっては、必ずしも有益な情報であるとは限らない。このようなユーザに有益となるのは、現実の運行状況に即した情報である。

また、従来、迂回路の経路探索は、ユーザが駅の改札の外にいることが前提となる。そのため、運行障害により当該駅で停車中の列車にいる場合に、その列車の運行経路を強制的に利用不可とするような経路探索が行われてしまうという問題がある。
本発明は、上記の問題を解決し、現実の運行状況に応じた交通機関の経路案内を可能にする経路案内の手法を提供することを主たる課題とする。

上記課題を解決するため、本発明は、経路案内方法および装置、コンピュータプログラムを提供する。
本発明の経路案内方法は、電車、列車、バスのいずれかの交通機関に乗車中のユーザが所持する携帯端末から、端末位置およびその変位を表す端末変位情報を取得する。また、交通機関のダイヤ情報と、各交通機関が到着又は出発するノードの配置情報とを含む運行情報が記録されたデータベースから前記運行情報を取得する。そして、前記端末変位情報と前記運行情報とを照合することにより前記ユーザが乗車中の交通機関のノード間の動きを特定し、これにより当該時刻以降の前記ダイヤ情報からの変更を表すダイヤ変更情報を、変更が生じた交通機関が現実に到着又は出発したノード毎に生成し、生成したダイヤ変更情報を更新自在に所定のメモリに記録しておく。前記携帯端末から経路探索要求を受信したときは、その経路探索要求に応じて前記運行情報および最新の前記ダイヤ変更情報による経路探索を実行し、実行結果を当該携帯端末へ提供する。

本発明の経路案内装置は、以下の構成を備えて成る交通機関の現実の運行状況を反映した経路案内装置である。
（１）端末位置およびその変位情報を表す端末変位情報を発信する１つ以上の携帯端末との間で通信を行う通信制御手段、
（２）電車、列車、バスの少なくとも一種類の交通機関のダイヤ情報と各交通機関が到着又は出発するノードの配置情報とを含む運行情報が記録されたデータベースにアクセスする情報アクセス手段、
（３）現在時刻を取得する時刻取得手段、
（４）前記交通機関に乗車中のユーザが所持する前記携帯端末から前記端末変位情報を取得するとともに、前記データベースから前記運行情報を取得し、取得した前記端末変位情報と前記運行情報とを照合することにより当該ユーザが乗車中の交通機関のノード間の動きを特定し、これにより当該時刻以降の前記ダイヤ情報からの変更を表すダイヤ変更情報を、変更が生じた交通機関が現実に到着又は出発したノード毎に生成し、生成したダイヤ変更情報を更新自在に所定のメモリに記録する変更情報管理手段、
（５）前記携帯端末からの経路探索要求に応じて前記運行情報および最新の前記ダイヤ変更情報による経路探索を実行し、実行結果を当該携帯端末へ提供する経路探索手段。

本発明のコンピュータプログラムは、コンピュータを現実の列車の運行状況を反映した経路案内装置として動作させるためのコンピュータ読取可能なプログラムであって、前記コンピュータを、上記（１）〜（５）のように機能させるものである。

本発明によれば、交通機関に乗車中のユーザが所持する携帯端末から取得した端末変位情報とデータベースから取得した運行情報とに基づいて当該時刻（各情報を取得した時刻）以降のダイヤ変更情報を、変更が生じた交通機関が現実に到着又は出発したノード毎に生成することができる。これにより、携帯端末からの経路探索要求に応じて運行情報および最新のダイヤ変更情報による経路探索を実行することができるため、乗車中の交通機関に事故等が発生した場合に、迂回経路を利用した方がよいかどうかの判断が容易となるという格別の効果を奏することができる。

本実施形態の経路案内システムの概要図。 駅の列車停車位置で観測される列車の加速度の状態遷移の例示図。 図３（ａ）は途中停車駅における状態遷移図、図３（ｂ）は始発駅における状態遷移図、図３（ｃ）は終着駅における状態遷移図、図３（ｄ）は、通過駅における状態遷移図。 経路探索サーバの全体構成図。 運行状況の更新処理の手順図。 運行状況の更新処理の手順図。 運行状況ＤＢの例示図。 遅延検出処理の手順図。 遅延チェック配列の例示図。 遅延チェック配列の例示図。 遅延チェック配列の例示図。 遅延検出履歴ＤＢの例示図。 到着時刻予測処理の手順図。 加速度を用いない運行状況の更新処理の手順図。 加速度を用いない運行状況の更新処理の手順図。 加速度を用いない経路案内システムの概要図。 遅延チェック配列の例示図。 遅延チェック配列の例示図。

以下、本発明を、交通機関の一例である列車の現実の運行状況を反映したネットワーク型の経路案内システムに適用した場合の実施の形態例を説明する。交通機関のノードは「駅」である。

＜概要＞
この実施形態に係る経路案内システムの概要を図１に示す。図１には、Ａ駅を出発し、Ｂ駅へ到着して停車する列車が示されている。この列車は、Ａ駅を発車するときに加速度が正（加速）となり、Ｂ駅に到着するときに加速度が負（減速）となる。停止中の加速度に変化はない。この実施形態では、列車に乗車中のユーザが、現在位置を表す端末位置情報を、当該現在位置における加速度および端末ＩＤと共に発信することができる携帯端末５０を所持していることを前提とし、この携帯端末５０より取得した情報に基づいて、そのユーザが乗車している列車の駅への到着、停止中、出発その他の動きを検出する。

携帯端末５０は、データ処理機能を有する携帯電話、スマートフォン、タブレット等であり、ＧＰＳ（Global Positioning System）あるいはＷｉＦｉ（Wireless Fidelity）のアクセスポイントを利用した端末位置特定機能と、加速度センサを用いた加速度検出機能と、経路探索サーバ１０との間の通信制御機能とを有するコンピュータ装置である。
端末位置特定機能および加速度検出機能は、携帯端末５０の製造メーカあるいは通信環境プロバイダが提供する公知の機能を利用することができる。常にそのようにする必要はないが、本実施形態では、これらの機能をいわゆる「常駐アプリ」として稼働できるようにしておき、上記端末位置および加速度を端末ＩＤと共に一定の時間間隔で経路探索サーバ１０へ送信するように設定する。なお、通信制御機能は公知の機能である。

経路探索サーバ１０は、ユーザの携帯端末５０から、正の加速度（加速）を得たときは、当該列車が駅を出発したと認識し、その後に送信されてくる端末位置と共に負の加速度（減速）を得たときは当該列車が駅に到着してくると認識する。加速度に変化がないときは当該列車が駅に停止中であると認識する。そして、この認識結果と端末位置および運行情報とに基づいて、到着待ち、停止中、出発済を表す状態フラグを駅毎に生成し、これらの状態フラグ、特に、到着待ちの状態フラグおよび出発済の状態フラグと、運行情報および現在時刻とに基づいて、当該列車が、今、どの駅を出発し、通過し、到着し、あるいはどこに停車しているかを特定することができる。この処理を、当該列車が関わる路線のすべての駅について繰り返し、処理結果を記録することで、列車追跡を行い、当該列車のダイヤ情報からの変更、例えば遅延時間や運転見合わせ等の運行状況を把握することができる。
経路探索サーバ１０は、このようにして把握した最新の運行状況を反映させた経路案内およびそれに基づく経路探索サービスを各ユーザに提供するものである。

駅の列車停車位置で観測される列車の加速度の状態変化を図２に示す。通常は、まず減速して駅に到着し、しばらくその駅で停車した後、加速して出発する。但し、始発駅では減速の部分がなく、終着駅では加速の部分がない。通過駅では、ほぼ一定速度で、加速度も、ほぼ０である。なお、加減速の変化を連続して捉えるには、加速度を取得する時間間隔（図２ではｔ秒）を短くすればよい。

図３は、経路探索サーバ１０で把握する、列車の状態遷移を表す図である。図中、「０」は到着待ち、「１」は停車中、「２」は出発済みの状態フラグを表す。
図３（ａ）は、停車駅における状態遷移図である。経路探索サーバ１０は、停車駅において、到着待ち時に負の加速度を受信することで停車駅に列車が停車すると認識する。その後、正の加速度を受信することで、列車が出発したと認識する。
図３（ｂ）は、始発駅における状態遷移図である。経路探索サーバ１０は、始発駅において、到着待ち時に正の加速度を受信することで列車が出発したと認識する。
図３（ｃ）は、終着駅における状態遷移図である。経路探索サーバ１０は、終着駅において、到着待ち時に負の加速度を受信することで終着駅に列車が停車したと認識する。なお、停止しているにも関わらず、終着駅では、状態フラグを「１」ではなく「２」とするのは、「１」では停車後に出発するのかどうかが不明となるため、便宜上、出発済みとして扱うためである。
図３（ｄ）は、通過駅における状態遷移図である。経路探索サーバ１０は、通過駅において加速度が０であることを受信して、列車が駅を通過したと認識する。

＜経路探索サーバ＞
次に、経路探索サーバ１０の構成について説明する。図４は、経路探索サーバ１０の全体構成図であり、特徴的な機能部分を掲示してある。
経路探索サーバ１０は、ハードウエアとしては、インターネット等のディジタルネットワークＮに接続されるサーバ本体と外部記憶装置とを有する。そして、サーバ本体が外部記憶装置に格納されている本発明のコンピュータプログラムを実行することにより、外部記憶装置に、駅情報ＤＢ（ＤＢはデータベースの略、以下同じ）１３１、運行情報ＤＢ１３２、列車停車位置ＤＢ１３３、乗車ユーザＤＢ１３４、運行状況ＤＢ１３５、及び遅延検出履歴ＤＢ１３６を構築するとともに、サーバ本体を、データ通信用インターフェース１００、経路探索ツール１１０、及び運行状況管理部１２０として機能させる。

駅情報ＤＢ１３１には、交通機関の駅の情報、例えば駅の出入口（北口、南口、Ａ出口、Ｂ出口等：「駅出入口」、以下、単に出入口という）の位置（緯度・経度等）、出入口に繋がる改札、改札から到達可能なホーム、ホーム間の連絡通路、利用制限条件等のデータが蓄積される。
運行情報ＤＢ１３２は、経路探索用の運行情報、例えばダイヤ情報（路線、時刻表を含む）と、必要に応じて、駅周辺の地図等が蓄積されている。

列車停車位置ＤＢ１３３は、上記の駅情報とリンクして、停車する駅毎に、停車番線、列車停車位置が記録される。駅は「駅ＩＤ」で識別され、停車番線（あるいはホーム）は「番線ＩＤ」で識別される。列車停車位置は、線路上に設定した矩形領域（列車の面積）の角部（右上、右下、左上、左下）の緯度、経度、高度で表される。

乗車ユーザＤＢ１３４は、揮発性のメモリであり、経路探索サーバ１０に、端末位置及び加速度を送信したユーザが乗車中の列車及び該ユーザが所有する携帯端末５０の情報が一時的に記録される。つまり、後述するように携帯端末５０の情報は、状態フラグを生成する際に重複して生成されることを回避するために記録しておくものなので、記録しておく必要がなくなった時点で消去される。ユーザが乗車する列車は、「列車ＩＤ」で識別され、携帯端末５０は「端末ＩＤ」で識別される。

運行状況ＤＢ１３５には、路線毎に各列車が遅延しているか否か、遅延している場合にはどの程度遅延しているか、運転見合わせなのか等、ダイヤ情報からの変更情報が記録される。具体的には、後述する運行状況管理部１２０（運行状況更新部１２１）により、上述の駅の番線および列車のほか、各列車が所属する路線を識別する路線、列車の進行方向を表す方向、列車の該路線の停車駅、通過駅、各停車駅における列車の出発予定時刻、列車が各停車駅を現実に出発した実出発時刻、各駅および番線における列車の状態、および遅延時間が記録され、随時更新される。
番線は「番線ＩＤ」、列車は「列車ＩＤ」、路線は「路線ＩＤ」で識別する。方向は、例えば、上り列車を「１０」、下り列車を「１１」、内周りを「１２」、外回りを「１３」で識別する。但し、数値以外の英数・文字・記号であってもよい。停車駅は「停車駅ＩＤ」、通過駅は「通過駅ＩＤ」で識別する。出発予定時刻はダイヤ上の時刻、実出発時刻は実際に出発した時刻が蓄積される。終着駅の場合は、出発予定時刻を到着予定時刻、実出発時刻を実到着時刻と読み替える。

列車の状態は、上述した状態フラグ、すなわち到着待ちを表す状態フラグ「０」、停車中を表す状態フラグ「１」、出発済を表す状態フラグ「２」である。状態フラグの初期値は「０」である。なお、状態フラグは、サーバ本体が、これらを区別できれば良いので、数値でなく、英数・文字・記号で識別してもよい。

遅延時間は、状態フラグが「２」の場合、すなわち列車が出発済の場合は、その列車の予定出発時刻から実出発時刻がどの程度遅延しているかを表す数値（分）で表される。
始発駅の場合の遅延時間は、例えば、［（列車の実出発時刻）−（１つ前の列車の実出発時刻）−｛（列車の出発予定時刻）−（１つ前の列車の出発予定時刻）｝］の式で算出される。始発駅以外の駅の場合の遅延時間は、例えば、［（当該停車駅の実出発時刻）−（１つ前の停車駅の実出発時刻）−｛（当該停車駅の出発予定時刻）−（１つ前の停車駅の出発予定時刻）｝］の式で算出される。

遅延検出履歴ＤＢ１３６には、路線、方向、登録時刻、遅延時間、駅間の遅延時間、列車の運行状況の状態フラグが記録される。対象となる路線は「路線ＩＤ」、方向は列車の進行方向を表す数値で識別する。登録時刻は遅延時間を登録した時刻、遅延時間は最初に遅延が発生した停車駅において算出された遅延時間、駅間の遅延時間は駅間の所要時間の遅れの算出値である。
列車の運行状況の状態フラグは、例えば、平常通りの場合は「０」、遅延が発生している場合は「１」、運転見合わせの場合は「２」が記録される。なお、これらの状態フラグは、携帯端末５０に向けて、それぞれ該当するメッセージを作成する際に参照されるものなので、到着待ち等の状態フラグとは区別して認識される。もちろん、他の数値と代えてもよく、あるいは英数・文字・記号であってもよい。

携帯端末５０は、データ通信及びデータ処理機能を有してダイレクトに、ディジタルネットワークＮに接続することができる。本実施形態では、携帯端末５０から経路探索のための情報の他に、端末位置及び加速度を一定の時間間隔で送出する。

サーバ本体に形成される機能を、より具体的に説明する。
データ通信用インターフェース１００は、携帯端末５０との双方向通信を可能にするとともに、アクセスしてきた携帯端末５０に、階層ページ画面を提供する。この階層ページ画面は、現在の運行状況の案内や経路探索のＷｅｂサービスを行なうためのもので、案内画面や経路探索条件の精緻な指定をシステム側とユーザとの間でインタラクティブに行なうことにより、ダイヤ変更情報の案内および経路探索を行なう環境をユーザに提供する。経路探索結果の表示も、このページ画面で行なうことができる。
なお、本実施形態における「ダイヤ変更情報」は、運行情報ＤＢ１３２に記録されている本来のダイヤ情報から変更されていることを表す情報全般、例えば、到着予定時刻、出発予定時刻、駅間所要時間からの遅延発生の事実および遅延時間、あるいは、運転見合わせ等の発生事実等をいう。

経路探索ツール１１０は、探索条件受付部１１１、条件生成部１１２及び経路探索エンジン１１３を含む。探索条件受付部１１１は、出発地、目的地、利用時刻（指定の無い場合は現在時刻）を含む経路探索条件を受け付ける。出発地と目的地の少なくとも一方については、ユーザが直接入力（指定）したものをそのまま経路探索条件として特定してもよく、予め登録されるものを提示して選択させることで特定するようにしてもよい。条件生成部１１２は、出発地から出発地条件、目的地から目的地条件を生成し、必要に応じて出入口や改札の利用制限情報を付加する。

経路探索エンジン１１３は、経路探索条件および条件生成部１１２で生成された条件（省略される場合もある）に従い、出発地から目的地に向かって各ノード（駅等）に順次リンクを張ることを繰り返すことにより、１又は複数の経路候補を探索し、経路探索条件に最も適合するものを最適経路候補とする。

経路探索エンジン１１３は、公知の推論エンジンも搭載しており、経路探索途中で、つまり各ノードにリンクを張り付けていく過程で、所要時間が現実的でなくなる経路となることが判明した場合、例えば予めメモリに記憶された閾値と比べて大きくなった場合は、その時点でその経路候補についての次のノード以降の探索を止める。経路探索エンジン１１３は、また、複数の経路候補の各々について、出発地から目的地に至るまでの総移動コスト、例えば時間を移動コストと捉える観点からは総所要時間を算出し、算出された総所要時間の小さい順に、複数の経路をソートする。経路中にその利用が制限される出入口や改札がある場合には、当該経路を除外したうえで、経路候補を特定する。
なお、経路探索エンジン１１３の基本機能部分は、本出願人が提供している経路探索ソフトウェア「駅すぱあと」（登録商標）を使用することができる。

運行状況管理部１２０は、主として、運行情報ＤＢ１３２に記録されている運行情報、特にダイヤ情報からの変更情報の管理手段として機能する。すなわち、端末変位情報と運行情報とを照合することによりユーザが乗車中の列車の駅間の動きを特定し、これにより上述したダイヤ変更情報を、変更が生じた列車が現実に到着又は出発した駅毎に生成し、生成したダイヤ変更情報を、上述した乗車ユーザＤＢ１３４，運行状況ＤＢ１３５および遅延検出履歴ＤＢ１３６に更新自在に記録しておく。

運行状況管理部１２０は、より詳しくは、運行状況更新部１２１、遅延検出部１２２、運行状況案内部１２３、到着時刻予測部１２４、不通路線設定部１２５の機能を実現し、さらに、経路探索サーバ１０内の図示しない時刻取得部から現在時刻を取得する機能も実現する。

運行状況更新部１２１は、携帯端末５０から取得した端末変位情報（端末位置、加速度）と、運行情報ＤＢ１３２より取得した運行情報（特にダイヤ情報）から当該列車の現在の停車駅を特定する。そして、上述したとおり、列車が停車駅から出発したときは状態フラグ「２」、停車中のときは状態フラグ「１」を当該停車駅について生成し、生成した状態フラグを駅毎に運行状況ＤＢ１３５に更新自在に記録する。
運行状況更新部１２１は、上記状態フラグを生成する際に、上述したとおり、端末ＩＤを駅毎に乗車ユーザＤＢ１３４に一時的に記録し、当該駅について記録しておく必要がなくなった時点で端末ＩＤを削除する。これにより、端末ＩＤを記録した携帯端末５０からの最初の情報に基づいて状態フラグが生成され、同一内容の情報による状態フラグの重複生成が回避される。

遅延検出部１２２は、所定の時間間隔（例えば５分毎）で、運行情報ＤＢ１３２および運行状況ＤＢ１３５にアクセスして、現実に遅延や運転見合わせが生じている列車および路線を検出し、例えば縦軸に列車ＩＤ、横軸に停車駅を配列し、縦軸と横軸との交点のセルに遅延時間（実際の遅延時間ないし暫定的な遅延時間）を配した遅延マトリクス配列を生成し、これを遅延検出履歴ＤＢ１３６に更新自在に記録しておく。遅延マトリクス配列の例については、後述する。
列車が出発済の駅については遅延時間が確定しているため、遅延検出部１２２は、運行状況ＤＢ１３５に記録されている遅延時間を上記遅延マトリクス配列の該当セルに格納する。他方、列車の到着待ち又は停車中の駅については、その駅から列車がいつ出発するのかが未定であり、遅延時間（当該駅の実出発時刻−前駅の実出発時刻）が確定しない。そのため、遅延検出部１２２は、現在時刻から前駅の実出発時刻を差し引いた時間を暫定的な遅延時間として算出し、この暫定的な遅延時間を遅延チェック配列の該当セルに格納する。

運行状況案内部１２３は、遅延検出部１２２で検出（算出）された遅延時間を含む現実の運行状況、具体的には遅延検出履歴ＤＢ１３６に記録されている遅延チェック配列の内容等を携帯端末５０に案内する。例えば、遅延時間が基準値未満の交通機関の駅については「平常通り」、基準値以上の遅延時間が発生し、かつ最初の遅延が発生した駅で止まることなく、運行している駅については「遅延発生中」、基準値以上の遅延時間が発生し、かつ最初の遅延発生駅の後に運行していない駅については「運転見合わせ」を表す案内情報を生成し、この案内情報を携帯端末５０へ選択的に提供する。
運行状況案内部１２３は、「運転見合わせ」を表す案内情報を提供するときは、当該駅における遅延時間の累積時間を「運転見合わせ時間」として案内する。

到着時刻予測部１２４は、運行状況ＤＢ１３５および遅延検出履歴ＤＢ１３６にアクセスして、現実の運行状況に基づいた経路探索を経路探索エンジン１１３と協働で行う。
不通路線設定部１２５は、運転見合わせの路線を避けた迂回経路の探索を、経路探索エンジン１１３と協働で行う。到着時刻予測部１２４及び不通路線設定部１２５は、経路探索エンジン１１３に含まれていてもよい。

＜運用形態＞
次に、経路探索サーバ１０の運用形態例を説明する。
前提として、列車に乗車中の１名以上のユーザが、それぞれ上記の携帯端末５０を所持しており、この携帯端末５０が、ディジタルネットワークＮ、データ通信用インターフェース１００を介して、端末ＩＤと共に端末変位情報を定期的に経路探索サーバ１０に自動送信するものとする。

［ダイヤ変更情報の管理］
運行状況管理部１２０は、各ユーザが乗車している列車の運行状況、特に運行情報ＤＢ１３２に記録されているダイヤ情報からの変更情報を端末変位情報に基づいて随時更新する。図５、図６は、運行状況（ダイヤ変更情報）の更新処理の手順説明図である。以下の説明で「Ｓ」は処理ステップを表す。
図５を参照し、運行状況管理部１２０は、携帯端末５０から、端末変位情報（端末位置及び加速度）を取得すると（Ｓ１０１）、その携帯端末５０が存在する駅及びその番線を、列車停車位置ＤＢ１３３にアクセスすることにより特定する（Ｓ１０２）。

運行状況更新部１２１は、取得した端末変位情報に含まれる加速度が負の場合（Ｓ１０３：Ｙ）、発信元の携帯端末５０の端末ＩＤが乗車ユーザＤＢ１３４に登録されているか否かを確認する（Ｓ１０４）。登録されていない場合はそのまま処理を終了する（Ｓ１０４：Ｎ）。端末ＩＤが登録されている場合は、運行情報ＤＢ１３２および乗車ユーザＤＢ１３４にアクセスして、ユーザが乗車中の列車を特定し、Ｓ１０２で特定した駅及び番線がこの列車の終着駅であるか否かをダイヤ情報に基づいて確認する（Ｓ１０４：Ｙ、Ｓ１０５）。終着駅でない場合は、この列車の駅、番線の状態フラグを「１」（停車中）に設定する（Ｓ１０５：Ｎ、Ｓ１０６）。Ｓ１０２で特定した駅が終着駅の場合は、この列車の駅、番線の状態フラグを「２」（出発済）に設定して、実到着時刻と遅延時間を運行状況ＤＢ１３５等に記録する（Ｓ１０５：Ｙ、Ｓ１０７）。このように運行状況を更新した後、運行状況更新部１２１は、この列車に乗車するすべてのユーザの端末ＩＤを乗車ユーザＤＢ１３４から削除して処理を終了する（Ｓ１０８）。

Ｓ１０３で加速度が負でない場合、運行状況更新部１２１は、加速度が正か０かを確認する（Ｓ１０９）。加速度が正の場合は（Ｓ１０９：Ｙ）、発信元の端末ＩＤが乗車ユーザＤＢ１３４に登録されているか否かを確認する。登録されている場合には処理を終了する（Ｓ１１０：Ｙ）。端末ＩＤが乗車ユーザＤＢ１３４に登録されていない場合は、Ｓ１０２の駅、番線で状態フラグが「１」（停車中）の列車が存在するか否かを、運行状況ＤＢ１３５を参照することで確認する（Ｓ１１０：Ｎ、Ｓ１１１）

Ｓ１０２で特定した駅、番線で状態フラグが「１」の列車が存在する場合、運行状況更新部１２１は、当該列車のＳ１０２で特定した駅、番線における運行状況ＤＢ１３５の状態フラグを「２」（出発済）に設定して、実出発時刻とそのときの遅延時間を記録する（Ｓ１１１：Ｙ、Ｓ１１２）。遅延時間は、［（当該駅の実出発時刻）−（１つ前の駅の実出発時刻）−｛（当該駅の出発予定時刻）−（１つ前の駅の出発予定時刻）｝］の式により算出する。また、発信元の端末ＩＤを、当該列車に乗車しているユーザが所持するものとして、乗車ユーザＤＢ１３４に登録して処理を終了する（Ｓ１１３）。

運行状況更新部１２１は、Ｓ１０２の駅、番線で状態フラグが「１」（停車中）の列車が存在しない場合は、Ｓ１０２の駅、番線を出発する列車のうち状態フラグが「０」（到着待ち）で出発予定時刻が最も早い列車を、運行状況ＤＢ１３５にアクセスして特定する（Ｓ１１１：Ｎ、Ｓ１１４）。その後、Ｓ１１４で特定した列車のＳ１０２で特定した駅、番線における運行状況ＤＢ１３５の状態フラグを「２」（出発済）に設定し、実出発時刻とそのときの遅延時間を記録する（Ｓ１１５）。遅延時間は、［（列車の実出発時刻）−（１つ前の列車の実出発時刻）−｛（列車の出発予定時刻）−（１つ前の列車の出発予定時刻）｝］の式により算出する。さらに、運行状況更新部１２１は、Ｓ１０１で受信した端末ＩＤを当該列車に乗車するユーザが所持するものとして乗車ユーザＤＢ１３４に登録し、処理を終了する（Ｓ１１６）。

Ｓ１０９で加速度が正でない場合、すなわち加速度が０の場合、運行状況更新部１２１は、乗車ユーザＤＢ１３４にＳ１０１で受信した端末ＩＤが登録されているか否かを確認する（Ｓ１０９：Ｎ、Ｓ１１７）。登録されている場合には、Ｓ１１７で乗車ユーザＤＢ１３４より特定した列車のＳ１０２の駅、番線の状態フラグを「２」（出発済）に設定し、上記のようにして遅延時間を算出し、実出発時刻と共にこれを運行状況ＤＢ１３５に記録して処理を終了する（Ｓ１１８）。

図７は、このようにして更新される運行状況ＤＢ１３５の例示図である。ここでは、中央線下り方面の列車が東京駅（始発駅）の１番線を出発した後、神田駅の６番線に到着し、さらに神田駅を実際に出発するまでを例に、上記処理を具体的に説明する。

図７の例では、Ｓ１０１で取得した端末位置が東京駅の１番線に該当する。加速度は正なので、Ｓ１１４の処理を行う。東京駅の１番線から出発する列車のうち、状態フラグが「０」（到着待ち）で出発予定時刻が最も早いのは、列車ＩＤの欄にある列車９３５Ｔである。よって、Ｓ１１５により、列車９３５Ｔの東京駅での状態フラグが「２」（出発済）になる。また、端末位置を送信したユーザが列車９３５Ｔに乗車していることを把握するために、Ｓ１１６で、列車ＩＤと端末ＩＤとを乗車ユーザＤＢ１３４に記録する。端末位置の取得は一定間隔で行うため、先ほどと同じユーザから東京駅の１番線の端末位置を再び取得する可能性があるが、この場合はＳ１１０がＹとなるため、無視される。

列車９３５Ｔが神田駅の６番線に到着すると、Ｓ１０３およびＳ１０４がＹ、Ｓ１０５がＮとなるため、Ｓ１０６により列車９３５Ｔの神田駅の状態フラグが「１」（停車中）となる。その後、Ｓ１０８により、Ｓ１１６で記録した端末ＩＤが乗車ユーザＤＢ１３４から削除されるため、直後に神田駅の６番線の端末位置を同じユーザから再び取得しても、Ｓ１０４がＮとなり、無視される。同様に、列車９３５Ｔが神田駅で停車中の場合も、Ｓ１０３、Ｓ１０９およびＳ１１７がＮとなるため、無視される。
列車９３５Ｔが神田駅を出発すると、Ｓ１１１がＹのため、Ｓ１１２により列車９３５Ｔの神田駅の状態フラグが「２」（出発済）となる。また、Ｓ１１３により、神田駅を出発したユーザの端末ＩＤが乗車ユーザＤＢ１３４に記録される。

この列車が中央線の「中央特快」であったとする。この場合は、中野駅で乗車したユーザの端末ＩＤが乗車ユーザＤＢ１３４に記録された後、高円寺駅を一定速度で通過する際にＳ１１７がＹとなり、Ｓ１１８によって、この列車の高円寺駅の状態フラグが「２」（出発済）となる。

［遅延検出］
次に、遅延検出部１２２における遅延検出の処理について、より詳しく説明する。この処理の手順例を図８に示す。
遅延検出部１２２は、終着駅の状態フラグが「０」（到着待ち）で始発駅の出発予定時刻が現在の時刻より前の列車を、始発駅の出発予定時刻の早い順に取得する（Ｓ２０１）。その後、Ｓ２０１で取得した列車に対して遅延チェック配列を形成する（Ｓ２０２）。遅延チェック配列の例を図９、図１０、図１１に示す。図９は運転見合わせ時、図１０は運転再開直後、図１１は遅延発生中の場合の例である。これらの遅延チェック配列は、各列車の停車駅毎の遅延時間を示している。このように運行状況の監視対象、すなわち、まだ終着駅に到着しておらず、かつ始発駅を出発しているはず（出発予定時刻が現在時刻よりも前）の列車を縦軸、それらの列車の停車駅を横軸とした配列が遅延チェック配列である。

遅延検出部１２２は、遅延チェック配列で遅延時間が「ＮＵＬＬ」（値なし）の停車駅について、現在時刻が出発予定時刻を過ぎている場合、すなわち本来ならば既にその駅を出発済みのはずだが、実際には未だ出発していない（到着待ちまたは停車中）場合、現時点での遅延時間を暫定的な遅延時間として記録する（Ｓ２０３：Ｙ、Ｓ２０４）。その後、遅延検出部１２２は、遅延チェック配列に遅延時間が予め定めた基準値、例えば１分以上の列車が存在するかを確認する。存在しない場合、遅延検出履歴ＤＢ１３６に、「平常通り」の状態を記録して処理を終了する（Ｓ２０５：Ｎ、Ｓ２０６）。

遅延検出部１２２は、遅延時間が１分以上の列車が存在する場合、遅延チェック配列から各列車の最初の遅延発生駅の遅延時間の最大値を求める（Ｓ２０５：Ｙ、Ｓ２０７）。その後、遅延チェック配列の各列車において、最初の遅延発生駅より後の停車駅の状態フラグが「０」（到着待ち）か否かを判断する（Ｓ２０８）。状態フラグが「０」でない場合、遅延検出部１２２は、遅延チェック配列から各列車の最初の遅延発生駅より後の停車駅における遅延時間の最大値を求める（Ｓ２０８：Ｎ、Ｓ２０９）。
その後、遅延検出履歴ＤＢ１３６に遅延発生中であることを記録して処理を終了する（Ｓ２１０）。状態フラグが「０」（到着待ち）の場合、遅延検出部１２２は、遅延検出履歴ＤＢ１３６に運転見合わせであることを記録して処理を終了する（Ｓ２０８：Ｙ、Ｓ２１１）。図１２は、遅延検出履歴ＤＢ１３６の例示図である。

図９の遅延チェック配列は、Ａ駅からＦ駅までのすべての停車駅で運転が見合わせの状態である。運転見合わせの時間は、逐次累積される。そのため、運転見合わせ時間が長くなるほど、列車Ｒ００６や列車Ｒ００７のような始発駅を出発できない列車の本数が増える。図９の例では、それぞれの列車が遅延発生以降、次の停車駅に運行していないため、Ｓ２０８がＹとなり、遅延検出履歴ＤＢ１３６に、「運転見合わせ中」の状態が記録される。このときユーザには、Ｓ２０７で求めた遅延時間の最大値である１５分を運転見合わせ時間として案内する。

運転が再開すると、遅延チェック配列は、図９から図１０のように変化する。ダイヤが乱れている場合にユーザが知りたいのは、その時点の列車の運行本数や駅間の所要時間（つまり自分がいる駅に、あと何分後に到着するか）である。そのため、Ｓ２０９により駅間の所要時間の遅れを算出し、これをユーザに案内する。算出する所要時間を、ダイヤ情報における所要時間と区別するため、「所要実時間」という。図１０の例では、所要実時間の遅れは最大で１分である。これにより、当該駅を通常よりも１分遅れで出発したことをユーザに案内する。

［到着時刻予測］
ユーザへの案内は、ユーザがまず経路探索要求を行い、従来の処理により探索結果を得ることから始まる。ユーザは、探索結果から利用したい経路を選択する。その経路に遅延が発生している場合は、到着時刻予測により導き出される現実の運行状況に基づいた経路が案内される。運転見合わせの場合には、不通路線を避けた迂回経路が案内される。
図１３は、このような処理の処理手順図である。この処理は、到着時刻予測部１２４及び経路探索エンジン１１３が処理の中心となる。

到着時刻予測部１２４は、運行状況ＤＢ１３５から、遅延が発生している路線の利用開始駅を最後に出発した列車ａを特定し（Ｓ３０１）、また、特定した列車ａの次に、この利用開始駅を出発予定の列車ｂを特定する（Ｓ３０２）。到着時刻予測部１２４は、Ｓ３０２で特定した列車ｂが最後に出発した駅ｃを特定し（Ｓ３０３）、Ｓ３０１で特定した列車ａのＳ３０３で特定した駅ｃから利用開始駅までの所要時間ｄを算出する（Ｓ３０４）。そして、算出した所要時間ｄを、Ｓ３０２で特定した列車ｂがＳ３０３で特定した駅ｃを出発した時刻に加算して新たな時刻ｅを算出する（Ｓ３０５）。

次いで、到着時刻予測部１２４は、遅延が発生した路線の利用終了駅を最後に出発した列車ｆを特定し（Ｓ３０６）、特定した列車ｆの利用開始駅から利用終了駅までの所要時間ｇを算出する（Ｓ３０７）。到着時刻予測部１２４は、この算出した所要時間ｇをＳ３０５で生成した時刻ｅに加算して、新たな時刻ｈを算出する（Ｓ３０８）。経路探索エンジン１１３は、Ｓ３０８で算出した時刻ｈを、経路探索における出発時刻にして、利用終了駅からの経路を再探索する（Ｓ３０９）。

到着時刻予測部１２４は、利用開始駅の出発時刻をＳ３０５で算出した時刻ｅに置き換え、利用終了駅の到着時刻をＳ３０８で算出した時刻ｈに置き換える（Ｓ３１０）。また、利用終了駅からの経路をＳ３０９で探索された経路ｉに置き換える（Ｓ３１１）。到着時刻予測部１２４は、Ｓ３１０の出発時刻及び到着時刻と経路とＳ３１１の経路ｉの組み合わせを、現実の運行状況を考慮した経路として、ユーザに案内する（Ｓ３１２）。

以上の処理を具体的な例を挙げて説明する。
ダイヤ情報の乱れが図１１の状態になっていたとする。つまり、列車Ｒ００７がＢ駅で５５分間運転を見合わせ、その後、Ｂ駅からＣ駅には通常時よりも２分だけ余分に所要時間がかかり、さらにＣ駅からＤ駅までは、現時点で１分の遅れが発生しているが、まだＤ駅には到着していないので、それ以上の遅れが生じるかどうかは未定である。この路線を、ユーザがＤ駅からＦ駅まで利用する際の所要時間を算出すると、以下のようになる。但し、Ｄ駅では、列車Ｒ００６が既に出発しており、次にＤ駅に到着するのは列車Ｒ００７である。

まず、Ｄ駅で列車Ｒ００７の到着を待つ時間を算出する。列車Ｒ００７の１つ前にＤ駅を出発した列車Ｒ００６は、Ｃ駅を出発してからＤ駅を出発するまでに平常時よりも３分だけ余計に時間がかかっている。そのため、列車Ｒ００７がＣ駅を出発した時刻に、平常時のＣ駅からＤ駅までの所要時間に前述の超過時間（３分）を加算すれば、列車Ｒ００７がＤ駅に到着する時刻の目安がわかる。

次に、Ｄ駅からＦ駅までの所要時間を算出する。現時点でＦ駅を最後に出発したのは列車Ｒ００５である。列車Ｒ００５はＤ駅を出発してからＦ駅を出発するまでに平常時よりも５分（＝３分＋２分）余計に時間がかかっている。よって、この超過時間を平常時のＤ駅からＦ駅までの所要時間に加算すれば、Ｆ駅への到着予定時刻がわかる。

このようにして、現実の運行状況に基づいた列車の待ち時間と、目的地への到着予定時刻の目安をユーザに案内することができる。

［加速度を使わない例］
上記の説明では、列車に乗車しているユーザが、加速度センサを有する携帯端末５０を所持していることを前提とした。これは、近年、加速度センサが装備されている携帯端末５０が多い点に着目したものであるが、携帯端末５０が加速度センサを装備しなくとも、端末位置とその変位がわかる情報を発信することができれば、本発明は、実施が可能である。例えば、加速度に相当する情報は、端末位置の変化の方向および大きさから演算によって導出することができるし、そもそも、加速度そのものを使わなくとも、端末位置の変位に関わる情報を導出することもできる。

例えば、図１４、図１５は、加速度を使わない場合の実施例を示す。実行間隔は、加速度を使う場合と同様に図２のｔ秒とする。加速度を使う場合は、列車停車位置の範囲外から送信された端末位置は無視されるが、加速度を使わない場合は、図１６のように、出発直後位置から送信された端末位置を処理の対象とする。「出発直後位置」とは、列車停車位置の進行方向側と接する領域を指し、例えば列車停車位置と同じ面積をもつ。
列車停車位置と同様、出発直後位置も四隅の緯度、経度、高度が列車停車位置ＤＢ１３３に記録される。

加速度を使わない場合は、携帯端末５０より受信した端末位置を、列車停車位置、出発直後位置、その他に分類する。携帯端末５０より受信した端末位置がいずれかの駅・番線の列車停車位置または出発直後位置に該当する場合は、それらの駅・番線（Ｎ駅Ｋ番線とする）ごとに、図１４または図１５の処理を実行する。
列車停車位置に存在する携帯端末５０から端末位置を受信した後、出発直後位置からの端末位置を受信できない場合は、列車の到着を表す。この場合は、図１４の処理を実行する。また、出発直後位置からの端末位置を受信した場合には、列車の出発を表すので、列車停車位置からの端末位置の受信の有無にかかわらず、図１５の処理を実行する。列車停車位置及出発直後位置のいずれからも端末位置を受信できない場合は、いずれの処理も実行しない。

列車到着時の処理について、図１４を参照して説明する。
端末位置を携帯端末５０から受信すると、運行状況更新部１２１は、当該携帯端末５０の端末ＩＤが乗車ユーザＤＢ１３４に記録されているかどうかを確認する（Ｓ４０１）。記録されていない場合は、そのまま処理を終える（Ｓ４０１：Ｎ）。記録されている場合、運行状況更新部１２１は、当該端末位置で表される駅（Ｎ駅）が該ユーザが乗車中の列車の終着駅かどうかを、運行情報ＤＢ１３２、列車停車位置ＤＢ１３３、及び乗車ユーザＤＢ１３４により確認する（Ｓ４０１：Ｙ、Ｓ４０２）。終着駅でない場合、運行状況更新部１２１は、運行状況ＤＢ１３５の当該列車のＮ駅の状態フラグを「１」（停車中）にする（Ｓ４０２：Ｎ、Ｓ４０３）。終着駅の場合は、運行状況ＤＢ１３５の当該列車のＮ駅の状態フラグを「２」（出発済）にして、実到着時刻と遅延時間を記録する（Ｓ４０２：Ｙ、Ｓ４０４）。
運行状況更新部１２１は、運行状況ＤＢ１３５の更新後に、当該列車に乗車するすべてのユーザの端末ＩＤを乗車ユーザＤＢ１３４から削除する（Ｓ４０５）。

次に、列車出発時の処理について図１５を参照して説明する。
端末位置を携帯端末５０から受信すると、運行状況更新部１２１は、当該携帯端末５０の端末ＩＤが乗車ユーザＤＢ１３４に記録されているかどうかを確認する（Ｓ５０１）。記録されている場合は、そのまま処理を終える（Ｓ５０１：Ｙ）。記録されていない場合、運行状況更新部１２１は、当該端末位置で表される駅の番線（Ｎ駅Ｋ番線）で状態フラグが「１」（停車中）の列車の有無を運行状況ＤＢ１３５により確認する（Ｓ５０１：Ｎ、Ｓ５０２）。Ｎ駅Ｋ番線に停車中の列車がある場合、運行状況更新部１２１は、運行状況ＤＢ１３５の当該列車のＮ駅の状態フラグを「２」（出発済）にして、実出発時刻と遅延時間を記録する（Ｓ５０２：Ｙ、Ｓ５０３）。
Ｎ駅の状態フラグの変更後、運行状況更新部１２１は、Ｎ駅Ｋ番線の列車停車位置と出発直後位置とから送信された端末ＩＤを当該列車の乗車ユーザとして乗車ユーザＤＢ１３４に記録する（Ｓ５０４）。

Ｎ駅Ｋ番線に停車中の列車がない場合、運行状況更新部１２１は、Ｎ駅Ｋ番線を出発する列車のうち、状態が「０」（到着待ち）で出発予定時刻が最も早い列車を、運行状況ＤＢ１３５により確認する（Ｓ５０２：Ｎ、Ｓ５０５）。運行状況更新部１２１は、確認した列車のＮ駅の状態フラグを「２」（出発済）にして、実出発時刻と遅延時間を記録する（Ｓ５０６）。その後、運行状況更新部１２１は、Ｎ駅Ｋ番線の列車停車位置と出発直後位置とから送信された端末ＩＤを当該列車の乗車ユーザとして乗車ユーザＤＢ１３４に記録する（Ｓ５０７）。

図１６の例で各ユーザから送信された端末位置を分類すると、Ａ駅では図１４の処理が実行され（列車が到着）、Ｂ駅では図１５の処理が実行される（列車が出発）。Ａ駅に列車が到着した直後に列車停車位置から検出されるのは、先頭車両にいるユーザ２のみである。よって、Ｓ４０１の「端末位置の送信元端末ＩＤ」に該当するのはユーザ２の端末ＩＤのみであり、ユーザ１の端末ＩＤは該当しない。しかし、Ｓ４０５では、当該列車に乗車するすべてのユーザの端末ＩＤを乗車ユーザＤＢから削除する。これにより、ｔ秒後にユーザ１とユーザ２の両方から端末位置が送信されても、Ｓ４０１がＮとなり、同一列車の到着を重複して検出しないようになっている。

Ｂ駅から列車が出発した直後の出発直後位置から検出されるのは、先頭車両にいるユーザ６のみである。よって、Ｓ５０１の「端末位置の送信元端末ＩＤ」に該当するのはユーザ６の端末ＩＤのみであり、ユーザ５の端末ＩＤは該当しない。しかし、Ｓ５０４とＳ５０７では、出発直後位置と列車停車位置の両方から送信された端末ＩＤを乗車ユーザＤＢに記録する。これにより、ｔ秒後にユーザ５とユーザ６の両方から端末位置が送信されても、Ｓ５０１がＹとなり、同一列車の出発を重複して検出しないようになっている。

［他の交通機関への接続の場合］
地下鉄と私鉄とで直通運転が可能になっている場合がある。この場合、例えば地下鉄で運転見合わせになると、私鉄への直通運転が中止される。よって、私鉄の運行本数が、本来よりも直通運転の分、少なくなる。このような場合に遅延チェック配列は、図１７のようになる。すなわち、地下鉄から私鉄への直通運転が中止されている間、Ｅ駅に到着するのは私鉄のＡ駅からの列車しかないため、図５のＳ１０４がＹとなり、乗車ユーザＤＢ１３４を通じて、直通運転が停止される列車（列車ＩＤ）を特定することができる。図１７の例では、Ｅ駅において、列車Ｒ００４が２３分遅れ、列車Ｒ００９が７分遅れの状態で待機している（以後、遅れ時間が増加する）ことを表している。
列車が直通運転かどうかを表す項目を運行状況ＤＢ１３５に追加して、図８のＳ２０５で遅延時間がｔ分以上の列車を検出した際に、それらの列車がすべて直通運転であると判断できれば、直通運転を中止していることをユーザに案内することができる。

また、路線の途中で事故等により折り返し運転をする場合の遅延チェック配列は図１８のようになる。すなわち、折り返し駅であるＥ駅の遅延時間は次第に増加するが、ユーザの利用する区間がＡ駅からＥ駅の間であれば、図１３の処理手順により、当該路線を迂回しない経路の探索が可能となる。

［運用上の利点］
従来の運行状況の案内サービスは、運転を見合わせていた時間を遅延時間として案内しているため、運転を再開した場合に、何分間隔で列車が到着するのかがわからず、迂回経路を利用すべきかどうか判断に迷うことがあった。
本実施形態は、１名以上のユーザが列車に乗降する動きをリアルタイムに捉えることで、列車の運行本数や駅間の所要時間の目安を算出できるため、駅で列車の到着を待つユーザに対し、次の列車があと何分くらいで到着するのかを案内できるようになった。
また、ダイヤ情報が乱れていても、現実の駅間の所要時間を記録しておくことで、目的地までの到着時刻を予測できるようになった。
本実施形態は、端末位置特定手段を備えるスマートフォンの常駐アプリとして実施するため、ユーザに特別な操作をさせることなく列車の運行状況を監視できることが利点である。

［他の実施の形態例］
以上、列車を例に挙げて本発明の実施の形態例を説明したが、交通機関は、電車、バス、航空機あるいはこれらの組み合わせであってもよい。このときのノードは、駅であってもよいが、バス停あるいは、ターミナルのように読み替えてもよい。
また、以上の説明では、携帯端末５０が、インターネット等のディジタルネットワークＮを介して経路探索サーバ１０と通信を行うことを前提としたが、無線基地局を介して通信を行うようにしてもよい。

１０…経路探索サーバ、５０…携帯端末、１００…データ通信用インターフェース、１１０…経路探索ツール、１１１…探索条件受付部、１１２…条件生成部、１１３…経路探索エンジン、１２０…運行状況管理部、１２１…運行状況更新部、１２２…遅延検出部、１２３…運行状況案内部、１２４…到着時刻予測部、１２５…不通路線設定部、１３１…駅情報ＤＢ、１３２…運行情報ＤＢ、１３３…列車停車位置ＤＢ、１３４…乗車ユーザＤＢ、１３５…運行状況ＤＢ、１３６…遅延検出履歴ＤＢ

Claims (9)

1. 電車、列車、バスのいずれかの交通機関に乗車中のユーザが所持する携帯端末から、端末位置およびその変位を表す端末変位情報を取得するとともに、交通機関のダイヤ情報と、各交通機関が到着又は出発するノードの配置情報とを含む運行情報が記録されたデータベースから前記運行情報を取得し、
   前記端末変位情報と前記運行情報とを照合することにより前記ユーザが乗車中の交通機関のノード間の動きを特定し、これにより当該時刻以降の前記ダイヤ情報からの変更を表すダイヤ変更情報を、変更が生じた交通機関が現実に到着又は出発したノード毎に生成し、生成したダイヤ変更情報を更新自在に所定のメモリに記録しておき、
   前記携帯端末からの経路探索要求に応じて前記運行情報および最新の前記ダイヤ変更情報による経路探索を実行し、実行結果を当該携帯端末へ提供する、
   交通機関の現実の運行状況を反映した経路案内方法。
2. 端末位置およびその変位情報を表す端末変位情報を発信する１つ以上の携帯端末との間で通信を行う通信制御手段と、
   電車、列車、バスの少なくとも一種類の交通機関のダイヤ情報と各交通機関が到着又は出発するノードの配置情報とを含む運行情報が記録されたデータベースにアクセスする情報アクセス手段と、
   現在時刻を取得する時刻取得手段と、
   前記交通機関に乗車中のユーザが所持する前記携帯端末から前記端末変位情報を取得するとともに、前記データベースから前記運行情報を取得し、取得した端末変位情報と運行情報とを照合することにより当該ユーザが乗車中の交通機関のノード間の動きを特定し、これにより当該時刻以降の前記ダイヤ情報からの変更を表すダイヤ変更情報を、変更が生じた交通機関が現実に到着又は出発したノード毎に生成し、生成したダイヤ変更情報を更新自在に所定のメモリに記録する変更情報管理手段と、
   前記携帯端末からの経路探索要求に応じて前記運行情報および最新の前記ダイヤ変更情報による経路探索を実行し、実行結果を当該携帯端末へ提供する経路探索手段と、
   を備えて成る、交通機関の現実の運行状況を反映した経路案内装置。
3. 前記変更情報管理手段は、取得した前記端末変位情報がいずれかのノードからの出発済を表すときは出発済の状態フラグ、当該ノードへの到着を表すときは停車中の状態フラグをそれぞれ当該ノードについて生成し、生成したこれらの状態フラグにより当該端末変位情報を発信した携帯端末を所持するユーザが乗車した交通機関のノード間走行に要した所要実時間を算出するとともに、この所要実時間と前記ダイヤ情報における所要時間との差分を算出し、この差分に基づいて各交通機関のノード毎の遅延時間を表す遅延チェック配列を揮発性メモリに記録し、この遅延チェック配列に記録された遅延時間と前記ダイヤ情報とを照合することにより前記ダイヤ変更情報を生成する、
   請求項２記載の経路案内装置。
4. 前記変更情報管理手段は、前記差分に代えて、前記乗車した交通機関が最後に到着したノードから現実に出発するまでの遅延時間を、前記遅延チェック配列における当該ノードにおける遅延時間として記録する、
   請求項３記載の経路案内装置。
5. 前記変更情報管理手段は、前記携帯端末の識別情報を各交通機関のノード毎に一時的に記録し、その識別情報を記録した携帯端末からの最初の前記端末変位情報に基づいて前記状態フラグを生成することにより、同一内容の端末変位情報による前記状態フラグの重複生成を回避する、
   請求項３又は４記載の経路案内装置。
6. 前記変更情報管理手段は、前記状態フラグに基づき、出発予定時刻が現在時刻よりも前の交通機関のノード毎の遅延時間を算出し、算出した遅延時間が基準値未満の交通機関のノードについては「平常通り」、基準値以上の遅延時間が発生し、かつ最初の遅延が発生したノードの後も運行している交通機関のノードについては「遅延発生中」、基準値以上の遅延時間が発生し、かつ最初の遅延が発生したノードの後に運行していない交通機関のノードについては「運転見合わせ」を表す案内情報を生成し、この案内情報を前記携帯端末へ選択的に提供する、
   請求項５記載の経路案内装置。
7. 前記変更情報管理手段は、前記「運転見合わせ」を表す案内情報を提供するときは、当該ノードにおける遅延時間の累積時間を運転見合わせ時間として案内する、
   請求項６記載の経路案内装置。
8. 前記経路探索手段は、運転見合わせまたは遅延の路線が存在する場合は、当該路線を避けた迂回経路又は運行予測に基づく新たな経路を前記携帯端末へ案内する、
   請求項７記載の経路案内装置。
9. コンピュータを、現実の列車の運行状況を反映した経路案内装置として動作させるためのコンピュータ読取可能なプログラムであって、
   前記コンピュータを、
   端末位置およびその変位情報を表す端末変位情報を発信する１つ以上の携帯端末との間で通信を行う通信制御手段、
   電車、列車、バスの少なくとも一種類の交通機関のダイヤ情報と各交通機関が到着又は出発するノードの配置情報とを含む運行情報が記録されたデータベースにアクセスする情報アクセス手段、
   現在時刻を取得する時刻取得手段、
   前記交通機関に乗車中のユーザが所持する前記携帯端末から前記端末変位情報を取得するとともに、前記データベースから前記運行情報を取得し、取得した端末変位情報と運行情報とを照合することにより当該ユーザが乗車中の交通機関のノード間の動きを特定し、これにより当該時刻以降の前記ダイヤ情報からの変更を表すダイヤ変更情報を、変更が生じた交通機関が現実に到着又は出発したノード毎に生成し、生成したダイヤ変更情報を更新自在に所定のメモリに記録する変更情報管理手段、
   前記携帯端末からの経路探索要求に応じて前記運行情報および最新の前記ダイヤ変更情報による経路探索を実行し、実行結果を当該携帯端末へ提供する経路探索手段、
   として機能させるコンピュータプログラム。

Images