(57)【要約】【課題】ユーザが指定した経路について、簡便な設定により、日中の運行状況を的確に取得し、事故等発生時には運行回復状況をユーザ端末にメールで送信することにより、ユーザの便宜を図る。【解決手段】交通機関の運行状況を提供する運行情報管理サーバから取得した運行状況をユーザ端末に通知する交通機関の運行状況案内サーバにおいて、所定の時間間隔で運行情報管理サーバから登録経路に関して運行状況を取得し、運行状況が平常の場合には、第１通知時刻に一又は複数の路線の最新の運行状況をユーザ端末に送信し、一又は複数の路線で事象が発生した場合には、第２通知時刻に運行状況をユーザ端末に送信する。【選択図】図１
2016018364.tif 000002
【特許請求の範囲】
【請求項１】
交通機関の運行状況を提供する運行情報管理サーバから取得した運行状況をユーザ端末に通知する交通機関の運行状況案内サーバにおいて、
プログラムを実行してデータを処理するデータ処理部と、
プログラム及び各種のＤＢを格納する記憶部を有し、
を備え、
該記憶部は、
予め該ユーザにより指定された、第１地点と第２地点の駅名と、該２地点間の一又は複数の路線名と、経由する駅名と、平常時の通知希望時刻である第１通知時刻と、事象発生時の通知希望時刻である第２通知時刻と、を含む経路（登録経路）に関する情報を記憶した
ユーザ経路情報ＤＢと、
交通機関の運行状況を格納する運行状況ＤＢと、を有し、
該データ処理部は、
所定の時間間隔で該運行情報管理サーバから該登録経路に関する運行状況を取得して該運行状況ＤＢを更新し、
該運行状況が平常の場合には、第1通知時刻に、該一又は複数の路線の該運行状況を該ユーザ端末に送信し、
該一又は複数の路線で事象が発生した場合には、第２通知時刻に、該一又は複数の路線の該運行状況を該ユーザ端末に送信することを特徴とする交通機関の運行状況案内サーバ。
【請求項２】
前記運行状況案内サーバは、２地点間の乗換経路を検索する乗換案内検索サーバに接続され、
前記データ処理部は、
前記一又は複数の路線で事象が発生した場合、
前記ユーザ端末のＧＰＳ制御部から該ユーザ端末の現在位置を取得し、
該現在位置が前記登録経路内にあるか否かを判定し、
前記登録経路内にあると判定した場合には、
該現在位置から第1地点及び第２地点までの、前記登録経路以外の別経路を該乗換案内検索サーバにより検索し、
第２通知時刻に、該検索の結果及び前記運行状況を前記ユーザ端末に送信し、
該現在位置が前記登録経路内にないと判定した場合には、
第２通知時刻に、前記運行状況を該ユーザ端末に送信することを特徴とする請求項１に記載の交通機関の運行状況案内サーバ。
【請求項３】
前記データ処理部は、
前記ユーザ端末の現在位置が前記登録経路内にないと判定した場合には、
前記事象が復旧するまで、第２通知時刻に、前記運行状況を前記ユーザ端末に送信することを特徴とする請求項２に記載の交通機関の運行状況案内サーバ。
【請求項４】
前記運行状況ＤＢは、
前記登録経路内の各路線の名称と、その交通機関の会社名と、平日運行か休日運行かの区別と、列車の番号と、上りか下りかの区別と、各駅の到着時刻か又は出発時刻と、運行状況の詳細内容と、を含み、
前記データ処理部は、
所定の時間間隔で前記運行情報管理サーバから前記登録経路に関する運行状況を取得して前記運行状況ＤＢのうち、各駅の到着時刻か又は出発時刻と、運行状況の詳細内容と、を更新することを特徴とする請求項１ないし３のいずれかの項に記載の交通機関の運行状況案内サーバ。
【請求項５】
交通機関の運行状況を提供する運行情報管理サーバから取得した運行状況をユーザ端末に通知する交通機関の運行状況案内サーバによる交通機関の運行状況案内方法において、
運行状況案内サーバのデータ処理部は、プログラムを実行して、
所定の時間間隔で該運行情報管理サーバから、該ユーザにより予め登録された２地点間の所定の経路に関する運行状況を取得し、
該運行状況が平常の場合には、該ユーザにより予め登録された平常時の通知希望時刻に該運行状況を該ユーザ端末に送信し、
該一又は複数の路線で事象が発生した場合、該ユーザにより予め登録された事象発生時の通知希望時刻に該運行状況を該ユーザ端末に送信することを特徴とする交通機関の運行状況案内方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、交通機関の運行状況案内サーバ及び方法に関する。
【背景技術】
【０００２】
近年、交通機関による目的地までの経路を検索する場合、Ｗｅｂサイトやソフトが充実し、出発地、到着地、出発時間、到着時間をユーザが入力すれば、経路を検索して結果を提示してくれるものが多数存在する。更に、交通機関の事故等による遅延情報やユーザの現在位置も考慮して経路の検索をし直してくれる特許文献１に開示されるような技術が提案されている。
【０００３】
特許文献１には、最初に出発地、到着地、出発時間、到着時間をユーザが端末から入力し、検索サーバが経路を検索して、ユーザが最適経路を決定した後、その経路につき事故等による運行状況の変化があった場合、ユーザの現在位置も考慮して、最新の運行状況に基づき経路の検索をし直し、ユーザ端末に変更経路の候補及び運行情報を送信するサーバが開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−９０７３３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
日常において、通勤、通学経路のように出発地、到着地が固定された経路について、交通機関の運行情報の日中の経過を逐次知りたいという要求がある。また、ある特定の経路について、事象発生後、運行が回復するまでの状況を知りたいという要望が強い。しかし、特許文献１によれば、これらについては言及していないため、その都度、ユーザが２地点を含む項目を入力して検索を行う必要がある。また、対象サーバは、ユーザが端末から入力した出発時間、到着時間近辺の列車運行情報しかユーザに送信しないため、ユーザは固定された経路についての長期間にわたる運行状況を把握することができない。
【０００６】
従って、本発明の目的は、ユーザが指定した経路について、簡便な設定により、日中の運行状況を的確に取得し、事故等発生時には運行回復状況を逐次ユーザ端末にメールで送信することにより、ユーザの便宜を図ることである。
【課題を解決するための手段】
【０００７】
本発明は、交通機関の運行状況を提供する運行情報管理サーバから取得した運行状況をユーザ端末に通知する交通機関の運行状況案内サーバにおいて、データの処理と交通機関の運行状況案内サーバの動作プログラムとを実行するデータ処理部と、プログラム及び各種のＤＢを格納する記憶部と、を備え、記憶部は、予めユーザの情報を登録したユーザ情報ＤＢと、交通機関の運行状況を格納する運行状況ＤＢと、を有し、ユーザ情報ＤＢは、ユーザにより登録された、第１地点と第２地点の駅名と、２地点間の一又は複数の路線名と、経由する駅名と、平常時の通知希望時刻である第１通知時刻と、事象発生時の通知希望時刻である第２通知時刻と、を含む経路（登録経路）に関する情報を有し、データ処理部は、所定の時間間隔で運行情報管理サーバから登録経路に関する運行状況を取得して運行状況ＤＢを更新し、運行状況が平常の場合には、第１通知時刻に、一又は複数の路線の該運行状況をユーザ端末に送信し、一又は複数の路線で事象が発生した場合には、第２通知時刻に、一又は複数の路線の運行状況をユーザ端末に送信することを特徴とする交通機関の運行状況案内サーバとして実現することができる。
【０００８】
また、上記交通機関の運行状況案内サーバによる交通機関の運行状況案内方法として実現することもできる。
【発明の効果】
【０００９】
本発明によれば、ユーザ指定の経路に関する定常的な運行状況及び事故等からの回復状況を的確に取得し、ユーザの便宜を図ることができる。特に、通勤、通学のような固定経路について、最初に通知条件の設定をしておけば、設定を解除するまで、運行情報のメールが自動的に届くため、ユーザの検索の手間を省き、ユーザに対する利便性が高い。
【図面の簡単な説明】
【００１０】
【図１】一実施例にかかる交通機関の運行状況案内システムの構成を示す図である。
【図２】一実施例にかかる交通機関の運行状況案内サーバの処理フローを示す図である。
【図３】一実施例にかかる別経路検索フローを示す図である。
【図４】一実施例にかかるユーザ情報ＤＢの内容を示す図である。
【図５】一実施例にかかる運行ダイヤＤＢを示す図である。
【図６】一実施例にかかる運行状況ＤＢを示す図である。
【図７Ａ】一実施例にかかるユーザ端末に対するメール文面の１頁目を示す図である。
【図７Ｂ】一実施例にかかるユーザ端末に対するメール文面の２頁目を示す図である。
【発明を実施するための形態】
【００１１】
本発明の一実施例にかかる交通機関の運行状況案内システムの構成を図１に従って説明する。本実施例による交通機関の運行状況案内システムは、鉄道会社の定期券等のユーザ端末１０と、鉄道会社がユーザに対するサービスとして運用する交通機関の運行状況案内サーバ２０と、Ｗｅｂに公開されている運行情報管理サーバ３０と、乗換案内検索サーバ５０と、これらを接続するネットワーク４０とから構成される。ユーザ端末１０は、キーボード、マウス等の入力部１２０と、交通機関の運行状況案内サーバ２０からのメールの内容を表示する表示部１３０と、ユーザ端末１０の位置を取得するＧＰＳ制御部１４０とから構成される。ユーザ端末１０として、スマートホン、タブレット端末、パソコン等を利用することができる。交通機関の運行状況案内サーバ２０は、データの処理と本システムの動作プログラムを実行するデータ処理部２１０と、ユーザ端末１０及び各サーバとの間でデータの通信を行う通信部２２０と、プログラムとＤＢを格納する記憶部２４０と、現在時刻とタイマの管理を行う計時部２５０と、から構成される。
【００１２】
記憶部２４０は、運行案内処理プログラム２６０と、列車の時刻表である運行ダイヤＤＢ２０５と、列車の現在の運行状況を示す運行状況ＤＢ２１５と、鉄道会社の定期券ユーザのユーザ情報ＤＢ２２５と、交通機関の運行状況案内サーバ２０がユーザ端末１０に送信する運行状況案内メールの文面を記録したメール内容ＤＢ２３５と、事故等の事象が発生した時にデータ処理部２１０がＯＮにする事象発生フラグ２４５と、を格納する。ユーザ情報ＤＢ２２５は、ユーザが定期券購入時に登録する定期券ユーザ情報を鉄道会社の定期券情報サーバ(図示せず)から定期的にダウンロードしたものである。
【００１３】
次に、ユーザ情報ＤＢ２２５の内容を図４に従って説明する。４０１はユーザを識別するユーザＩＤであり、４０２はユーザの氏名、４０３はユーザが利用する路線名、４０４はユーザが利用する自宅付近の駅である第１地点、４０５はユーザの学校や勤務地等の付近の駅である第２地点、４０６は定期券のユーザが、通勤又は通学経路内の交通機関の運行状況に関するメール通知を希望するか否かを示すメール通知希望有無の項目であり、４０７はユーザのメールアドレス、４０８は本システムによるメールの通知期間であり、４０９はその始期、４１０はその終期、４１１はメールの通知時刻であり、４１２は平常時の通知時刻（第１通知時刻）、４１３は事象発生時の通知時刻（第２通知時刻）である。
【００１４】
第１通知時刻は３０分単位で設定でき、第２通知時刻は５分単位で設定できるものとする。また、レコード４２０は、氏名４０２の欄がＡとなっているユーザＡのユーザ情報であり、レコード４３０は、氏名４０２の欄がＢとなっているユーザＢのユーザ情報である。
【００１５】
次に、ユーザＡのユーザ情報であるレコード４２０について説明する。メール通知希望有無４０６が〇となっているため、ユーザＡは本システムの通知対象者となる。ユーザＡの利用路線名４０３は東海道本線であり、自宅に近い第１地点は大船駅、会社に近い第２地点は東京駅である。また、ユーザＡの端末１０に対する通知期間４０８は始期４０９が２０１４年の４月１日で、終期が２０１４年の９月３０日である。メールの通知時刻４１１は、６時〜２１時の間１時間おきに通知するよう登録してあり、事象発生後は１０分おきに通知するよう４１３に登録してある。なお、路線４０３内の第１地点４０４と第２地点４０５の間の経路を登録経路と呼ぶことにする。
【００１６】
なお、レコード４３０で示されるユーザＢのユーザ情報は、メール通知希望有無の欄が「−」となっており、メール通知を希望していないため、本システムによるメール通知の対象外となる。
【００１７】
次に、運行ダイヤＤＢ２０５の内容を図５に従って説明する。５０１は鉄道の会社名を記載した鉄道会社名、５０２は路線の名前を記載した路線名、５０２ａは平日のダイヤか休日かを示す平日／休日の項目、５０３は列車の上りか下りかを記載した列車の方向、５０４は列車の連続番号を記載した列車ＮＯ.であり、５０５は出発／到着時刻であり、その路線の始発駅の場合には列車の出発時刻であり、それ以外の場合は列車の到着時刻を示す。５０６〜５１０はその路線の途中駅の名前である。
【００１８】
本実施例で、某日、東海道本線で以下に述べる人身事故が発生したと想定する。図５のレコード５２０に示される東海道本線の列車ＮＯ.がＴ００８である列車に関して、川崎駅５０８と品川駅５０９の間で７：５７に人身事故が発生して全線不通となる場合を想定する。また、ユーザＡは、人身事故発生時に、Ｔ００８の次の列車であるＴ００９に乗車しており、通勤途中であったものとする。
【００１９】
人身事故が発生したＴ００８の列車は、レコード５２０で示されるように、ダイヤ上は事故区間の川崎に７：５３に到着し、品川に８：０３に到着するスケジュールとなっている。また、ユーザＡが乗車しているＴ００９は、横浜に７：４９に到着し、川崎に８：００に到着するスケジュールとなっている。
【００２０】
次に、運行状況ＤＢ２１５の内容を図６に従って説明する。運行状況ＤＢ２１５は、運行ダイヤＤＢ２０５と比べて、６１０の運行状況の項目が追加されている点が異なるだけで、他の項目は全く同じである。図６の（Ａ）は、列車の運行が平常通りである場合、（Ｂ）は上述の人身事故が発生して列車に遅れが生じた場合を示す。（Ｂ）の場合、Ｔ００８の列車は、川崎に予定通り７：５３に到着しているが、品川に向かう途中の７：５７に人身事故が発生し、事故地点で停車状態を続けるため、品川以降の駅の欄には「列車停止中」と記載してある。
【００２１】
一方、Ｔ００９の列車は、横浜に予定通り７：４９に到着しているが、横浜から川崎に向かう途中で、７：５７に１本前のＴ００８に人身事故が発生した影響で、速度を落とし、川崎駅に到着したのは予定より１２分遅れの８：１２であったとする。そして、Ｔ００９も川崎駅で停車状態を続けるものとする（図６（Ｂ）の６７０）。
【００２２】
また、事象発生フラグ２４５は、事故等の事象が発生したときにデータ処理部２１０がＯＮとするフラグである。
【００２３】
次に、交通機関の運行状況案内サーバ２０の処理フローについて、図２に従って説明する。データ処理部２１０が、記憶部２４０に格納されている運行案内処理プログラム２６０の命令を実行することにより本フローの各ステップを処理する。本フローによる処理は、サーバ点検等の非定常時を除いて常時稼動しており、タイマにより設定される所定の時間間隔でデータ処理部２１０が処理を繰り返すものとする。
【００２４】
電源ＯＮ等による本フロー開始時に、計時部２５０はタイマをセットしてカウントを開始する（Ｓ２０２０）。本タイマの値は１分で固定としたが、可変とすることもできる。その後、運行情報管理サーバ３０から運行情報を取得し、運行状況ＤＢ２１５を更新する（Ｓ２０２５）。この時点ではまだ何も事象が発生していないと仮定すると、ここで更新された運行状況ＤＢ２１５の内容を示す図６の（Ａ）は、図５に示す運行ダイヤＤＢ２０５の内容と比べて、列車の運行ダイヤの変更はない。
【００２５】
次に、データ処理部２１０は、運行情報管理サーバ３０から運行情報を取得して運行状況ＤＢ２１５を更新した（Ｓ２０２５）結果により、事象が発生したか否かを判定し（Ｓ２０３０）、その結果、事象が発生していれば、データ処理部２１０は、処理をＳ２０４０へ進め、発生していなければＳ２０８５へ進める。
【００２６】
まだ事象が発生していないと仮定すると、データ処理部２１０はＳ２０８５へ処理を進め、各ユーザごとにメールの第１通知時刻が経過しているか否かを判定する。具体的には、データ処理部２１０が、計時部２５０から現在時刻を取得して、ユーザ情報ＤＢ２２５に登録してある各ユーザに対するメールの第１通知時刻（図４の４１２）を参照し、これを現在時刻が経過したか否かを判定する。その結果、第１通知時刻４１２を経過しているユーザに対して、通信部２２０は、運行状況が平常通りである旨のメールをユーザの端末１０に送信し（Ｓ２１００）、ユーザ端末１０の表示部１３０にその内容を表示させる。ユーザＡの端末１０に対する本メールの文面例を図７Ａの（Ａ）に示す。
【００２７】
次に、データ処理部２１０は、計時部２５０のタイマ（１分）がアップするまで時間待ちを行い（Ｓ２１１０）、アップすると新たにタイマをセットし、計時部２５０はカウントを開始する（Ｓ２１２０）。そして、データ処理部２１０は、事象発生フラグ２４５がＯＮか否かを判定し（Ｓ２１３０）、ＯＮであれば、Ｓ２１４０へ進み、ＯＮでなければＳ２０２５へ戻る。まだ事象が発生していないと仮定すると、事象発生フラグ２４５がＯＮでないため、データ処理部２１０はＳ２０２５に戻る。そして、事象が発生するまで、Ｓ２０２５〜Ｓ２０３０及びＳ２０９５〜Ｓ２１３０の処理を繰り返す。
【００２８】
その後、上述の人身事故が発生したと想定する。事故が発生した直後に、Ｓ２０２５において、データ処理部２１０は、運行情報管理サーバ３０から運行情報を取得して運行状況ＤＢ２１５を更新した（Ｓ２０２５）結果により、事象が発生したか否かを判定し（Ｓ２０３０）、東海道本線に人身事故が発生した事実を認識する。そして、データ処理部２１０は、事象発生フラグ２４５をＯＮにする（Ｓ２０４０）。
【００２９】
その後、データ処理部２１０は、各ユーザ端末１０のＧＰＳ制御部１４０から現在のユーザの端末１０の位置情報を取得して（Ｓ２０６０）、各ユーザ端末１０の現在位置は各ユーザの登録経路内であるか否かを判定し（Ｓ２０７０）、登録経路内に位置するユーザ端末１０に関する処理についてＳ２０８０に進み、登録経路内に位置しないユーザ端末１０に関する処理についてＳ２０９０に進む。
【００３０】
ここで、ユーザＡ端末１０に関する処理を例にとると、上述のように、ユーザＡは人身事故発生時に東海道本線の列車Ｔ００９に乗車しており、横浜駅と川崎駅の間に位置するので、ユーザＡの登録経路内に位置するため、データ処理部２１０は、Ｓ２０７０でユーザＡの端末１０の位置が登録経路内と判定し、Ｓ２０８０に進む。
【００３１】
そして、Ｓ２０８０において、データ処理部２１０は、乗換案内検索サーバ５０により、ユーザＡについて、登録経路以外の別経路の検索を行うが、この詳細を図３の別経路検索フローにより説明する。まず、データ処理部２１０は、ユーザ端末１０のＧＰＳ制御部１４０からユーザ端末１０の位置情報を取得し、今どこにいるのかを判別する（Ｓ３０１０）。その結果、登録経路内のいずれかの駅（Ｃ駅とする）に位置することが判明した場合、Ｃ駅から第１地点までの登録経路以外の別経路を乗換案内検索サーバ５０により検索する（Ｓ３０４０）。続いて、Ｃ駅から第２地点までの登録経路以外の別経路を乗換案内検索サーバ５０により検索する（Ｓ３０５０）。ここで、Ｃ駅から、第１地点と第２地点の両方向に対する経路を検索する理由は、ユーザが乗車している列車が停止しているため、列車の進行方向を判別するのが困難なためである。
【００３２】
もし、ユーザ端末１０が、隣接する２駅の中間に位置する場合には、データ処理部２１０はＳ３０２０へ進む。そして、２駅のうち第１地点に近い駅をＡ駅、第２地点に近い駅をＢ駅とすると、まずＡ駅から第１地点までの、登録経路以外の別経路を乗換案内検索サーバ５０により検索する（Ｓ３０２０）。次に、Ｂ駅から第２地点までの、登録経路以外の別経路を乗換案内検索サーバ５０により検索する（Ｓ３０３０）。ここでも、Ａ駅から第１地点までと、Ｂ駅から第２地点までと、両方向に対する経路を検索する理由は、事故で列車が停止している可能性も高く、列車の進行方向を判別するのが困難なためである。
【００３３】
ユーザＡ端末１０の場合には、人身事故発生時は、上述のように、横浜駅と川崎駅の中間に位置するため、データ処理部２１０は、Ｓ３０１０の判定の結果、Ｓ３０２０に進み、Ａ駅である横浜駅から第１地点である大船駅までの別経路を検索する。次に、Ｂ駅である川崎駅から第２地点である東京駅までの別経路を検索する（Ｓ３０３０）。
【００３４】
そして、図２に戻って、ユーザＡの端末１０に対するメールの第２通知時刻が経過したか否かを判定し（Ｓ２０９０）、経過していない場合には、データ処理部２１０はＳ２１１０に進む。経過している場合には、データ処理部２１０は、通信部２２０からユーザＡの端末１０に対して、事象が発生した旨（図７Ａの（Ｂ））及びＳ２０８０で検索した別経路検索結果（図７Ａの（Ｃ）と図７Ｂの（Ｄ））をユーザＡ端末１０のメールアドレス（図４の４０７）宛にメールで送信する。なお、別経路の検索結果は、毎回の通知時に、各別経路について直近の連続した３ダイヤを送信することとする。
【００３５】
次に、データ処理部２１０は、タイマがアップするまで待った（Ｓ２１１０）後、タイマを設定し直して、計時部２５０でカウントを開始する（Ｓ２１２０）。そして、データ処理部２１０は、事象発生フラグ２４５がＯＮであるか否かを判定して（Ｓ２１３０）、ＯＮであればＳ２１４０に進み、ＯＮでなければＳ２０２５に戻る。
【００３６】
ここでは、既に人身事故が発生して事象発生フラグ２４５はＯＮしているため、データ処理部２１０はＳ２１４０に進み、運行情報管理サーバ３０から最新の運行情報を取得して運行状況ＤＢ２１５を更新する（Ｓ２１４０）。その後、データ処理部２１０は、Ｓ２１４０で取得した運行情報に基づいて事象が復旧したか否かを判定して（Ｓ２１５０）、復旧した場合にはＳ２１６０に移動して、事象発生フラグ２４５をＯＦＦし、復旧していない場合には、Ｓ２０６０に移動する。
【００３７】
そして、ユーザＡの端末１０の位置が登録経路から外れない限り、復旧するまで、データ処理部２１０は、Ｓ２０６０〜Ｓ２１５０のステップを繰り返すことにより、通知時刻の各時点でのユーザＡ端末１０の位置からの別経路検索結果を送信し続けて、ユーザＡの便宜を図っている。
【００３８】
もし、ユーザＡの端末１０の位置が登録経路から外れた場合には、Ｓ２０７０の判定の後、別経路を検索する（Ｓ２０８０）ことなく、Ｓ２０９０に移動し、ユーザＡ端末１０に対するメール送信時刻の判定（Ｓ２０９０）と送信の処理（Ｓ２１００）を行う。
【００３９】
本実施例によれば、ユーザが希望する時刻に、登録した経路に関する定常的な運行状況及び事故等からの回復状況を的確に取得してユーザに通知することにより、ユーザの便宜を図ることができる。特に、ユーザは、事象が発生した後の第２通知時刻を平常時の第１通知時刻より細かく設定して登録しておくことにより、事象発生時から復旧までの詳細な経過を逐次把握することができる。
【００４０】
更に、事象発生時にユーザが登録経路内に位置する場合には、登録経路以外の別経路を案内することにより、ユーザの目的地到達を強力に支援することができる。また、通勤、通学のような固定経路について、ユーザが最初に通知条件の設定をしておけば、設定を解除するまで、運行情報のメールが自動的に届くため、ユーザの検索の手間を省き、ユーザに対する利便性が高い。
【００４１】
なお、本実施例において、交通機関の運行状況案内サーバ２０は、特定の鉄道会社がユーザに対するサービスとして運用する場合を想定したが、不特定多数のユーザに対する一般公開のＷｅｂサーバが複数の鉄道会社の路線にまたがった経路に関する運行状況案内サービスを提供する場合にも、本発明を適用することができる。
【符号の説明】
【００４２】
１０  ：ユーザ端末、  ２０  ：交通機関の運行状況案内サーバ、
３０  ：運行情報管理サーバ、４０  ：ネットワーク、
５０  ：乗換案内検索サーバ、１４０：ＧＰＳ制御部、
２０５：運行ダイヤＤＢ、２１０：データ処理部、２４０：記憶部、
２４５：事象発生フラグ、２５０：計時部、２６０：運行案内処理プログラム
【図１】
2016018364.tif 000003
【図２】
2016018364.tif 000004
【図３】
2016018364.tif 000005
【図４】
2016018364.tif 000006
【図５】
2016018364.tif 000007
【図６】
2016018364.tif 000008
【図７Ａ】
2016018364.tif 000009
【図７Ｂ】
2016018364.tif 000010