JP2005280524A - 利用者支援システム - Google Patents

Abstract

【課題】 予めなされた予約等の計画を状況に応じて自動的に変更する利用者支援システムにおいて、現在位置から計画を遂行する場所へ至る経路に鉄道区間を含む場合に、この鉄道区間の所要時間を運行状況に応じて予測することで、計画を変更するか否かの判断の信頼性をより高いものとし、より適切な計画支援を実現すること。
【解決手段】 ダイヤ予測システム２０は、通常ダイヤ或いは過去の事故復旧実績に対する統計演算結果に基づいて駅間の所要時間を確率的に算出する。代行システム４０は、位置検出システム３０により検出された利用者端末５０の位置から到達場所に至る行程を設定し、この行程に含まれる鉄道区間の所要時間をダイヤ予測システム２０に照会する。そして、回答された所要時間に基づいて、到達場所への到達時刻までの到達可能性を “可能”、“可能性高い”、“可能性低い”或いは“不可能”と段階的に判断する。
【選択図】 図１

Description

本発明は、利用者支援システムに関する。

利用者の行動に対する様々な支援を行う利用者支援システムの１つとして、利用者の現在の状況に応じて代替計画の立案を支援する状況適応型計画支援システムが知られている。かかるシステムでは、事前に行った予約等の計画内容を記憶しておく。そして、この計画の遂行上の問題となる状況情報を逐次収集し、収集した情報と計画とを比較することにより該計画を変更すべきかを判断する。その結果、変更すべきと判断した場合には、代替計画に関係する情報を収集して代替計画を立案し、現在の計画を取消してこの立案した代替計画を記憶する（例えば、特許文献１）。
国際公開第９７／００８６３６号パンフレット

上述のような従来の支援システムでは、計画を変更するかの判断を利用者の現在の状況に応じて行っている。即ち、利用者の位置を検出し、検出した位置から利用者が置かれている現在の状況を判断して計画の遂行が可能であるか、具体的には、利用者が、計画を遂行する場所に遂行する時刻までに到達できるかによって判断している。

例えば利用者の現在位置から計画を遂行する場所までの経路が鉄道である場合、経路に該当する鉄道区間の運行状況を収集し、列車の遅れの度合が予め設定されている、計画を遂行する場所に遂行する時間までに到達できないと判断される条件値を満たす場合に計画を変更すると判断する。つまり、単に現時点での遅れの程度によって到達が可能／不可能を判断しているに過ぎず、現在の運行状況が不通であればどの程度の時間で復旧するのか、復旧した後は到達までにどの程度の時間を要するのかといったことを予測して判断しているものではない。このため、計画を変更すべきかの判断に対する信頼性が充分であるとはいえなかった。

上記事情に鑑み、本発明は、予めなされた予約等の計画を状況に応じて自動的に変更する利用者支援システムにおいて、現在位置から計画を遂行する場所へ至る経路に鉄道区間を含む場合に、この鉄道区間の所要時間を運行状況に応じて予測することで、計画を変更するか否かの判断の信頼性をより高いものとし、より適切な計画支援を実現することを目的としている。

上記課題を解決するために、第１の発明は、
鉄道事故についての復旧実績情報を蓄積した事故データベース（例えば、図３の事故ＤＢ２６２）と、前記事故データベースに蓄積された復旧実績情報に基づいて、事故が発生した場合の駅間の予測所要時間を所定の統計演算により算出する予測手段（例えば、図３の予測所要時間算出部２４８）と、列車ダイヤデータベースと、前記列車ダイヤデータベースに基づいて通常ダイヤの場合の駅間の通常所要時間を算出する算出手段（例えば、図３の通常所要時間算出部２４６）と、を備え、現在の運行状況に応じて、前記予測手段により算出される予測所要時間及び前記算出手段により算出される通常所要時間の何れか一方又は両方を所要時間として出力する所要時間算出システム（例えば、図１のダイヤ予測システム２０及び運行管理システム１０）と、
利用者端末と通信を行うことで前記利用者端末の位置を検出する位置検出システム（例えば、図１の位置検出システム３０）と、
利用者の代わりに外部システム（例えば、図１の外部システム６０）と通信を行って前記外部システムに所定の処理を実行させる代行システム（例えば、図１の代行システム４０）と、
を具備する利用者支援システム（例えば、図１の利用者支援システム１０００）であって、
前記代行システムは、
到達場所及び到達必須時刻を記憶する記憶手段（例えば、図９の記憶部４４０）と、
前記位置検出システムにより検出された利用者端末の位置から前記到達場所に至る鉄道区間を含む行路を設定する行路設定手段（例えば、図９の到達可能性判断部４２４）と、
前記行路設定手段により設定された行路に含まれる鉄道区間の所要時間を前記所要時間算出システムに照会し、回答された所要時間に基づいて、前記到達必須時刻までに前記到達場所へ到達する到達可能性を判断する判断手段（例えば、図９の到達可能性判断部４２４）と、
前記判断手段による判断結果に基づいて前記外部システムとの通信の実行を制御する制御手段（例えば、図９の代行制御部４２８）と、
を備えることを特徴としている。

この第１の発明によれば、利用者支援システムにおいて、代行システムは、位置検出手段によって検出された利用者端末の位置から到達場所に至る鉄道区間を含む行路を設定し、設定した行路に含まれる鉄道区間の所要時間を所要時間算出システムに照会する。すると、所要時間算出システムは、列車ダイヤデータベースに基づいて通常ダイヤの場合の駅間の通常所要時間を算出するとともに、事故データベースに蓄積されている鉄道事故についての復旧実績情報に基づいて、事故が発生した場合の駅間の予測所要時間を所定の統計演算によって算出し、現在の運行状況に応じて、算出した通常所要時間及び予測所要時間の何れか一方又は両方を所要時間として回答する。そして、代行システムは、この回答された所要時間に基づいて到達必須時刻までに到達場所へ到達する到達可能性を判断し、判断結果に基づいて外部システムとの通信を行って所定の処理を実行させることができる。

従って、事故が発生した場合の鉄道区間の予測所要時間を、例えば該事故に状況が類似した過去の事故の復旧実績情報に基づいて統計的に算出することができるため、算出する所要時間の信頼性を高めることが可能となる。そして、この所要時間に基づいて到達可能性を判断し、判断結果に基づいて外部システムに所定の処理を実行させることができるため、例えば計画の変更といった所定の処理を実行させるかの判断をより信頼性が高いものとし、より適切な計画支援を実現することが可能となる。

第２の発明は、第１の発明の利用者支援システムであって、
前記所要時間算出システムは、現在の運行状況が事故発生状況である場合、前記予測手段により算出される予測所要時間及び前記算出手段により算出される通常所要時間の両方を出力するシステムであり、
前記判断手段は、前記所要時間算出システムから回答された予測所要時間及び通常所要時間のどちらであっても前記到達必須時刻までに前記到達場所へ到達できない場合に、到達不可能と判断する手段であることを特徴としている。

この第２の発明によれば、第１の発明と同様の効果を奏するとともに、所要時間算出システムは、現在の運行状況が事故発生状況である場合、算出した予測所要時間及び通常所要時間の両方を所要時間として回答する。そして、代行システムは、この回答された予測所要時間及び通常所要時間のどちらであっても到達必須時刻までに到達場所に到達できない場合に到達不可能と判断することができる。

第３の発明は、第１又は第２の発明の利用者支援システムであって、
前記予測手段は、所定の確度に対する予測所要時間を算出する手段であり、
前記判断手段は、前記所要時間算出システムから回答された所要時間が予測所要時間であった場合に、回答された予測所要時間及び前記所定の確度に基づいて、少なくとも到達可能性が高い又は低いの２段階で到達可能性の程度を判断する手段である、
ことを特徴としている。

この第３の発明によれば、第１又は第２の発明の利用者支援システムと同様の効果を奏するとともに、所要時間算出システムは、所定の確度に対する予測所要時間を算出し、代行システムは、回答された予測所要時間及び所定の確度に基づいて、少なくとも到達可能性が高い又は低いの２段階で到達可能性の程度を判断することができる。

即ち、予測所要時間の算出に用いた確度が大きい程、この算出した予測所要時間の信頼性が高くなるので、到達可能性を単に到達可能／不可能として判断するのではなく、例えば予測所要時間の算出に用いた確度の値の大小に応じて到達可能性を段階的な程度で判断することができる。従って、予測所要時間の算出に用いる確度を適当に変化させることで、外部システムの間で所定の通信処理を実効するか否かといった判断を、利用者が求める適度な信頼性の下で行うことが可能となる。

また、第４の発明は、第２の発明の利用者支援システムであって、
前記外部システムは、場所と日時とが指定された電子チケットの予約を管理するチケット管理システム（例えば、図１のチケット管理システム６２）であり、
前記記憶手段は、前記チケット管理システムに予約された電子チケットの場所を到達場所とし、日時を必須到達時刻として記憶する手段であり、
前記制御手段は、前記判断手段により到達不可能と判断された場合に、前記チケット管理システムに予約された電子チケットをキャンセルさせるように前記チケット管理システムと通信を行う手段である、
ことを特徴としている。

この第４の発明によれば、第２の発明と同様の効果を奏するとともに、外部システムが場所と日時が指定された電子チケットの予約を管理するチケット管理システムである場合、代行システムは、予約した電子チケットの場所を到達場所とし、日時を到達必須時刻として到達可能性を判断するとともに、到達可能と判断した場合に、チケット管理システムに予約された電子チケットをキャンセルさせることができる。

また、第５の発明は、第３の発明の利用者支援システムであって、
前記外部システムは、場所と日時とが指定された電子チケットの予約を管理するチケット管理システムであり、
前記記憶手段は、前記チケット管理システムに予約された電子チケットの場所を到達場所とし、日時を必須到達時刻として記憶する手段であり、
前記制御手段は、前記判断手段により到達可能性が低いと判断された場合に、前記チケット管理システムに予約された電子チケットを日時を変更した電子チケットに変更させるように前記チケット管理システムと通信を行う手段である、
ことを特徴としている。

この第５の発明によれば、第３の発明と同様の効果を奏するとともに、外部システムが場所と日時が指定された電子チケットの予約を管理するチケット管理システムである場合、代行システムは、予約した電子チケットの場所を到達場所とし、日時を到達必須時刻として到達可能性を判断するとともに、到達可能性が低いと判断した場合に、チケット管理システムに予約された電子チケットを日時を変更した電子チケットに変更させることができる。

第６の発明は、第２の発明の利用者支援システムであって、
前記外部システムは、予め設定された時刻に所定の処理の実行を開始するシステム（例えば、図１の家電制御システム６４）であり、
前記制御手段は、前記判断手段により到達不可能と判断された場合に、前記所定の処理の実行を中止させるように前記外部システムと通信を行う手段である、
ことを特徴としている。

この第６の発明によれば、第２の発明と同様の効果を奏するとともに、
外部システムが予め設定された時刻に所定に処理の実行を開始するシステムである場合、代行システムは、到達不可能と判断した場合に、外部システムに所定の処理の実行を中止させることができる。

第７の発明は、第３の発明の利用者支援システムであって、
前記外部システムは、予め設定された時刻に所定の処理の実行を開始するシステムであり、
前記制御手段は、前記判断手段により到達可能性が低いと判断された場合に、前記予め設定された時刻を変更させるように前記外部システムと通信を行う手段である、
ことを特徴としている。

この第７の発明によれば、第３の発明と同様の効果を奏するとともに、外部システムが予め設定された時刻に所定の処理の実行を開始するシステムである場合、代行システムは、到達可能性が低いと判断した場合に、外部システムに予め設定された時刻を変更させることができる。

第８の発明は、第１〜第７の何れかの発明の利用者支援システムであって、
前記復旧実績情報には、事故発生から仮復旧までの仮復旧時間情報と、事故発生から完全復旧までの完全復旧時間情報と、仮復旧から完全復旧までの仮復旧期間における駅間の所要時間情報とが含まれ、
前記予測手段は、前記復旧実績情報に含まれる仮復旧時間情報、完全復旧時間情報及び所要時間情報それぞれに対する所定の統計演算を行うことにより、予測仮復旧時間、予測完全復旧時間及び駅間の予測所要時間を算出する手段である、
ことを特徴としている。

この第８の発明によれば、第１〜第７の何れかの発明と同様の効果を奏するとともに、
所要時間算出システムが備える事故データベースに蓄積される復旧実績情報には、事故発生から仮復旧までの仮復旧時間情報と、事故発生から完全復旧までの完全復旧時間情報と、仮復旧から完全復旧までの仮復旧期間における駅間の所要時間情報とが含まれており、前記復旧実績情報に含まれる仮復旧時間情報、完全復旧時間情報及び所要時間情報それぞれに対する所定の統計演算を行うことにより、予測仮復旧時間、予測完全復旧時間及び駅間の予測所要時間を算出することができる。

本発明によれば、予めなされた予約等の計画を状況に応じて自動的に変更する利用者支援システムにおいて、現在位置から計画を遂行する場所へ至る経路に鉄道区間を含む場合に、この鉄道区間の所要時間を運行状況に応じて予測することで、計画を変更するか否かの判断をより信頼性の高いものにできる。

以下、図面を参照して本発明を実施するための最良の形態を説明する。

［構成］
先ず、構成を説明する。
図１は、本実施形態の概略構成を示すブロック図である。同図に示すように、本実施形態は、利用者支援システム１０００と、複数の利用者端末５０と、外部システム６０と、を備えている。また、利用者支援システム１０００は、運行管理システム１０と、ダイヤ予測システム２０と、位置検出システム３０と、代行システム４０と、を備えている。

＜運行管理システム＞
運行管理システム１０は、鉄道事業者によって運営される鉄道システム１１００に含まれるシステムであり、列車の運行管理や進路制御、運行案内、運転整理等をコンピュータを用いて集中制御する、いわゆるＣＴＣシステム（列車集中制御システム）として実現される。また、運行管理システム１０は、ダイヤ予測システム２０と専用線等で接続されており、ダイヤ予測システム２０からの要求に応じて、通常ダイヤや運転整理案（回復ダイヤ）等のダイヤ情報、最新の運行状況情報等をダイヤ予測システム２０に送信する。

列車の運行状況は、図２に示すように、“正常運行”、“非復旧”、“仮復旧”及び“回復”の４つの状況（状態）に分類される。

“正常運行”は、列車がダイヤ通りに運行している状態である。事故発生を契機として、“正常運行”から“非復旧”の状態に遷移する。

“非復旧”は、発生事故の影響により列車が運行していない状態（不通状態）である。仮復旧を契機として“非復旧 ”から“仮復旧”の状態に遷移する。

“仮復旧”は、事故要因が解消されて列車の運行が再開されたが、運行に乱れがあり、ダイヤ通りに運行していない状態である。“仮復旧”における駅間の所要時間（駅での停車時間を含む）は、基本的には“正常運行”における所要時間以上である。この“非復旧”と“仮復旧”とが“事故発生状況”である。そして、完全復旧を契機として“仮復旧”から“回復”の状態に遷移する。

“回復”は、通常ダイヤに復帰するために作成された運転整理案（回復ダイヤ）通りに列車が運行している状態である。“回復”では、回復ダイヤ通りに列車が運行しているが、運行間隔や運行本数等が“正常運行”とは異なっている。“回復”の後、“正常運行”に遷移する。

＜ダイヤ予測システム＞
ダイヤ予測システム２０は、鉄道システム１１００に含まれるシステムであり、専用線等で接続された運行管理システム１０とともに所要時間算出システムを構成する。そして、ダイヤ予測システム２０は、運行管理システム１０から取得した運行状況情報やダイヤ情報等に基づいて駅間の所要時間を算出する。また、ダイヤ予測システム２０は、代行システム４０とも接続されており、代行システム４０から要求（照会）された駅間の所要時間を算出し、算出した所要時間を代行システム４０に送信（回答）する。

図３は、ダイヤ予測システム２０の機能構成を示すブロック図である。同図に示すように、ダイヤ予測システム２０は、機能的には、操作入力部２１０と、表示部２２０と、通信部２３０と、処理部２４０と、記憶部２５０と、を備えて構成される。

操作入力部２１０は、オペレータ等による操作指示を受け付け、なされた操作に応じた操作信号を処理部２４０に出力する。この機能は、例えばボタンスイッチやレバー、ダイヤル、マウス、キーボード、各種センサ、タッチパネル等によって実現される。

表示部２２０は、処理部２４０からの表示制御信号に従って、例えばＤＢ検索条件を入力するためのＤＢ検索条件入力画面等を表示する。この機能は、例えばＣＲＴ、ＥＬＤ、ＰＤＰ等によって実現される。

通信部２３０は、処理部２４０からの通信制御信号に従って所与の通信回線に接続し、例えば運行管理システム１０や代行システム４０等の外部装置とのデータ通信を行う。この機能は、例えば無線通信モジュール、モデム、ＴＡ等によって実現される。

処理部２４０は、ダイヤ予測システム２０全体の制御を行う。この機能は、例えばＣＰＵ等の演算装置やＩＣメモリ等の記憶装置、その制御プログラム等によって実現される。また、処理部２４０は、統計演算部２４２と、所要時間算出部２４４と、を含む。

統計演算部２４２は、鉄道システム１１００の管轄区間内で事故が発生した場合に、事故ＤＢ２６２を参照して、該発生した事故に発生状況が類似している過去の事故に関する情報に基づく統計演算を行う。

事故ＤＢ２６２は、図４に示すように、過去に発生した事故に関する情報である事故情報２６３を多数蓄積している。尚、事故ＤＢ２６２に蓄積されている事故情報２６３は復旧済みの事故に関する情報であり、事故が完全復旧した後に、該事故に関する事故情報２６３が追加・蓄積されていく。

同図によれば、事故情報２６３は、事故の発生状況に関する情報である発生状況情報２６４と、復旧実績に関する情報である復旧実績情報２６５と、を含んでいる。

発生状況情報２６４は、事故種別（２６４ａ）と、規模（２６４ｂ）と、発生場所（２６４ｃ）と、発生時刻（２６４ｄ）と、支障線区（２６４ｅ）と、を格納している。

また、復旧実績情報２６５は、図５に示すように、ダイヤ予測システム２０の管轄区間内の駅（以下、「管轄駅」と称する。）それぞれについての復旧実績情報２６５−１、２６５−２、・・・、から構成される。即ち、管轄駅の数だけの復旧実績情報２６５が用意される。同図では、これらの復旧実績情報２６５の内、「Ｉ駅」についての復旧実績情報２６５が一番手前に示されている。

同図によれば、復旧実績情報２６５は、駅の別を示す駅名（２６５ａ）と、仮復旧時間（２６５ｂ）と、完全復旧時間（２６５ｃ）と、所要時間テーブル（２６５ｄ）と、を格納する。

仮復旧時間（２６５ｂ）は、事故発生から仮復旧までに要した時間であり、事故の発生時刻から仮復旧時刻までの経過時間に相当する。ここで、「仮復旧」とは、事故の発生によって該駅に停車していた列車が出発した時点、或いは、事故発生後、該駅に最初に列車が到達した時点を意味する。

完全復旧時間（２６５ｃ）は、事故発生から完全復旧までに要した時間であり、事故の発生時刻から完全復旧時刻までの経過時間に相当する。ここで、「完全復旧」とは、事故発生後、該駅を発車した列車が通常の所要時間で運行可能となった（通常ダイヤと同様の運行に戻った）時点を意味する。

所要時間テーブル（２６６）は、仮復旧からの時間経過に対する該駅から各管轄駅までの所要時間を格納する。即ち、所要時間テーブル（２６６）は、仮復旧からの経過時間（２６６ａ）と、該駅から各管轄駅までの所要時間（２６６ｂ）と、を対応付けて格納する。所要時間（２６６ｂ）の内、該駅（同図では「Ｉ駅」）については停車時間を格納する。また、所要時間テーブル（２６６）は、仮復旧から完全復旧までの期間（仮復旧期間）における所定時間毎の所要時間を格納する。

例えば同図の場合、「Ｉ駅」での仮復旧時間は「２０分」であり、完全復旧時間は「２００分」である。即ち、仮復旧から完全復旧までの時間は「１８０分」である。そして、所要時間テーブル（２６６）には、仮復旧の時点に相当する「０分」から完全復旧の時点に相当する「１８０分」までの仮復旧期間における、「１０分」毎のＩ駅から他の各管轄駅（即ち、Ａ駅、Ｂ駅、・・・、Ｈ駅、Ｊ駅、・・・、Ｚ駅）までの所要時間及びＩ駅での停車時間が格納されている。例えば、仮復旧直後（仮復旧からの経過時間が「０分」）でのＩ駅からＡ駅までの所要時間は「１２０分」である。

このように構成される事故ＤＢ２６２に基づいて、統計演算部２４２は、次の手順で統計演算を行う。

先ず、事故の発生状況に基づくＤＢ検索条件が操作入力部２１０から入力される。このＤＢ検索条件の入力は、例えばオペレータが、表示部２２０に表示される所定のＤＢ検索条件入力画面において、項目毎に予め定められた複数の選択肢の内から適当なものを条件値として選択することで実現される。ＤＢ検索条件として条件値が入力される項目は、事故情報２６３の発生状況情報２６４に格納される各項目であり、具体的には、“事故種別”、“規模”、“発生場所”、“発生時刻”及び“支障線区”の項目である。

ＤＢ検索条件の各項目の条件値が入力・設定されると、統計演算部２４２は、事故ＤＢ２６２を検索して、設定されたＤＢ検索条件に適合する事故情報２６３を抽出する。具体的には、発生状況情報２６４の各項目のデータ値がＤＢ検索条件の対応する項目の条件値を満たす事故情報２６３を抽出する。

尚ここで、抽出した事故情報２６３の件数が所定数（例えば、１５件）以下の場合には、条件をゆるめるようにＤＢ検索条件を再設定しても良い。具体的には、例えば“発生時刻”の項目については、当初設定された「12：00〜13：00」を「11：00〜14：00」に変更するといったように、時間帯の幅を広げるように再設定する。このＤＢ検索条件の再設定は、統計演算部２４２が自動的に行うが、オペレータ等によりなされることととしても良い。

次いで、統計演算部２４２は、抽出したこれらの事故情報２６３を対象とした統計演算を行う。具体的には、管轄駅毎に、抽出した事故情報２６３に含まれる復旧実績情報２６５の内、該駅についての復旧実績情報２６５に格納されている仮復旧時間（２６５ｂ）、完全復旧時間（２６５ｃ）及び所要時間テーブル（２６６）のそれぞれに対する統計演算を行う。統計演算としては種々あるが、ここでは、正規分布関数Ｆ（Ｘ）に従う統計演算を行い、それぞれについての平均μ及び分散σを算出する。

統計演算部２４２による演算結果は、統計演算結果情報２６８に格納される。図６に、統計演算結果情報２６８のデータ構成の一例を示す。同図に示すように、統計演算結果情報２６８は、各管轄駅についての統計演算結果情報２６８−１、２６８−２、・・・、から構成される。即ち、管轄駅の数だけの統計演算結果情報２６８が用意される。同図では、これらの統計演算結果情報２６８の内、「Ｉ駅」についての統計演算結果情報２６８が一番手前に示されている。

同図によれば、統計演算結果情報２６８は、駅の別を示す駅名（２６８ａ）と、復旧時間算出結果テーブル（２６９）と、所要時間算出結果テーブル（２７１）と、を格納する。

復旧時間算出結果テーブル（２６９）は、統計演算の対象である（抽出された）事故情報２６３に含まれる復旧実績情報２６５の内、該駅についての復旧実績情報２６５に格納されている仮復旧時間（２６５ｂ）及び完全復旧時間（２６５ｃ）に対する統計演算結果を格納する。即ち、復旧時間算出結果テーブル（２６９）は、仮復旧時間（２６９ａ）と、完全復旧時間（２６９ｂ）と、のそれぞれについての平均μ及びσを格納する。

所要時間算出結果テーブル（２７１）は、統計演算の対象である事故情報２６３に含まれる復旧実績情報２６５の内、該駅についての復旧実績情報２６５に格納されている所要時間テーブル（２６６）に対する統計演算結果、詳細には、所要時間テーブル（２６６）に格納されている各データ値（例えば、仮復旧からの経過時間が「０分」での「Ａ駅」までの所要時間「１２０分」）に対する統計演算結果を格納するデータテーブルである。即ち、所要時間算出結果テーブル（２７１）は、仮復旧からの経過時間（２７１ａ）と、該駅から各管轄駅までの所要時間（２７１ｂ）についての平均μ及び分散σと、を対応付けて格納する。尚、所要時間（２７１ｂ）の内、該駅（同図では「Ｉ駅」）については、停車時間の平均μ及び分散σを格納する。

図３において、所要時間算出部２４４は、代行システム４０から駅間の所要時間を要求（照会）された場合に、運行管理システム１０から取得したダイヤ情報や統計演算結果情報２６８等に基づいて、要求された駅間の所要時間を算出する。ここで算出する所要時間には、ダイヤ情報に基づいて算出した通常所要時間と、統計演算結果情報２６８に基づいて統計的に算出した予測所要時間と、があり、何れの所要時間を算出するかは、要求された駅間の現在の運行状況に依存する。即ち、要求された駅間の現在の運行状況が“正常運行”或いは“回復”ならば通常所要時間を算出し、“非復旧”或いは“仮復旧”ならば通常所要時間及び予測所要時間を算出する。そして、算出した所要時間を、要求された駅間の現在の運行状況とともに代行システム４０に送信（回答）する。また、所要時間算出部２４４は、通常所要時間算出部２４６と、予測所要時間算出部２４８と、を含む。

通常所要時間算出部２４６は、運行管理システム１０から取得したダイヤ情報に基づいて要求された駅間の通常所要時間を算出する。具体的には、要求された駅間の現在の運行状況が“正常運行”、“非復旧”或いは“仮復旧”である場合には、該駅間を含む路線の通常ダイヤに基づいて、該駅間の起点駅に基準時刻ｔ０にいると仮定した場合の所要時間を算出し、通常所要時間とする。また、要求された駅間の現在の運行状況が“回復”である場合には、該駅間を含む路線の回復ダイヤに基づいて、起点駅に基準時刻ｔ０にいると仮定した場合の所要時間を算出し、通常所要時間とする。尚、通常ダイヤ及び回復ダイヤは、所要時間算出部２４４が運行管理システム１０に要求し、取得する。

予測所要時間算出部２４８は、統計演算結果情報２６８に基づいて要求された駅間の予測所要時間を算出する。具体的には、要求された駅間の現在の運行状況が“非復旧”或いは“仮復旧”である場合に、該駅間の起点駅についての統計演算結果情報２６８に基づいて、該起点駅に基準時刻ｔ０にいると仮定した場合の所要時間を算出し、予測所要時間とする。

図７は、要求された駅間の現在の運行状況が“非復旧”である場合の予測所要時間Ｔの算出を説明するための図であり、時間軸に対する事象の発生とその時刻ｔとの関係を示している。

同図に示すように、先ず、事故発生から仮復旧までの仮復旧時間Ａを算出する。具体的には、統計演算結果情報２６８の復旧時間算出結果テーブル（２６９）に格納されている仮復旧時間（２６９ａ）についての平均μ及び分散σを用いて、事故発生から時間Ｘだけ経過した時点で仮復旧している確率（仮復旧確率）Ｆ（Ｘ）が所定の確率Ｎとなる時間（仮復旧時間）Ｘ＝Ａを算出する。

次いで、算出した仮復旧時間Ａを事故の発生時刻ｔ１に加算して予測される仮復旧時刻ｔ２を算出する。即ち、仮復旧時刻ｔ２は次式（１）で与えられる。
ｔ２＝ｔ１＋Ａ ・・・（１）

そして、算出した仮復旧時刻ｔ２と基準時刻ｔ０との関係に応じて、起点駅から終点駅までの所要時間Ｂを算出する。

即ち、仮復旧時刻ｔ２が基準時刻ｔ０よりも遅い（ｔ２＞ｔ０）場合には、図７（ａ）に示すように、統計演算結果情報２６８の所要時間算出結果テーブル（２７１）に格納されている、仮復旧からの経過時間（２７１ａ）が「０」に対応する所要時間（２７１ｂ）の内、終点駅までの所要時間についての平均μ及びσを用いて、時間Ｘだけ経過した時点で終着駅に到達している確率（到達確率）Ｆ（Ｘ）が所定の確率Ｎとなる所要時間Ｘ＝Ｂ１を算出する。

また、基準時刻ｔ０から仮復旧時刻ｔ２までの経過時間Ａ１を算出する。経過時間Ａ１は次式（２）で与えられる。
Ａ１＝ｔ２−ｔ１ ・・・（２）

そして、算出した経過時間Ａ１に所要時間Ｂ１を加算することで要求された駅間の予測所要時間Ｔを算出する。従って、予測所要時間Ｔは次式（３）で与えられる。
Ｔ＝Ａ１＋Ｂ１ ・・・（３）

一方、仮復旧時刻ｔ２が基準時刻ｔ０よりも早い或いは等しい（ｔ２≦ｔ０）場合には、同図（ｂ）に示すように、仮復旧時刻ｔ２から基準時刻ｔ０までの経過時間Ａ２を算出する。経過時間Ａ２は次式（４）で与えられる。
Ａ２＝ｔ０−ｔ２ ・・・（４）

次いで、統計演算結果情報２６８の所要時間算出テーブル（２７１）に格納されている、仮復旧時間からの経過時間（２７１ａ）が算出した経過時間Ａ２に対応する所要時間（２７１ｂ）の内、終点駅までの所要時間についての平均μ及びσを用いて、時間Ｘだけ経過した時点で終着駅に到達している到達確率Ｆ（Ｘ）が所定の確率Ｎとなる所要時間Ｘ＝Ｂ２を算出する。そして、算出した所要時間Ｂ２を予測所要時間Ｔとする。従って、予測所要時間Ｔは次式（５）で与えられる。
Ｔ＝Ｂ２ ・・・（５）

また、図８は、要求された駅間の現在の運行状況が“仮復旧”である場合の予測所要時間Ｔの算出を説明するための図であり、図７と同様に、時間軸に対する事象の発生とその時刻ｔとの関係を示している。

同図によれば、先ず、仮復旧時刻ｔ３から基準時刻ｔ０までの経過時間Ｃを算出する。経過時間Ｃは次式（６）で与えられる。
Ｃ＝ｔ０−ｔ３ ・・・（６）

次いで、統計演算結果情報２６８の所要時間算出結果テーブル（２７１）に格納されている、仮復旧時間からの経過時間（２７１ａ）が算出した経過時間Ｃに対応する所要時間（２７１ｂ）の内、終点駅までの所要時間についての平均μ及びσを用いて、時間Ｘだけ経過した時点で終着駅に到達している到達確率Ｆ（Ｘ）が所定の確率Ｎとなる所要時間Ｘ＝Ｄを算出する。そして、算出した所要時間Ｄを要求された駅間の予測所要時間Ｔとする。従って、予測所要時間Ｔは次式（７）で与えられる。
Ｔ＝Ｄ ・・・（７）

図３において、記憶部２５０は、処理部２４０にダイヤ予測システム２０を統合的に制御させるためのプログラムやデータ等を記憶する。具体的には、プログラムとして、処理部２４０を統計演算部２４２として機能させるための統計演算プログラム２５２と、所要時間算出部２４４として機能させるための所要時間算出プログラム２５４と、を記憶する。また、所要時間算出プログラム２５４は、通常所要時間算出部２４６として機能させるための通常所要時間算出プログラム２５６と、予測所要時間算出部２４８として機能させるための予測所要時間算出プログラム２５８と、を含む。また、データとしては、事故ＤＢ２６２と、統計演算結果情報２６８と、を記憶する。

＜位置検出システム＞
位置検出システム３０は、利用者端末５０と所定の通信を行うことで該利用者端末５０の位置を検出する。また、位置検出システム３０は、代行システム４０と接続されており、検出した位置（検出位置）を、位置を検出した時刻（検出時刻）及び検出した利用者端末５０を識別する利用者端末ＩＤとともに、位置検出情報として代行システム４０に送信する。ここで検出された利用者端末５０の位置が、代行システム４０では該利用者端末５０を所有する利用者の“位置”として扱われる。また、検出時刻は、何月何日の何時何分といった日付を含む時分単位で表現されている。

また、位置検出システム３０は、利用者端末５０の形態に応じたシステムとして実現される。具体的には、例えば利用者端末５０が携帯電話機で実現される場合、この携帯電話機が通話やデータ通信の際に接続する基地局を判断し、この判断した基地局の設置位置（或いは、接続可能な所定範囲）を利用者端末５０の位置として検出する。

また、利用者端末５０がＩＣタグを内蔵している場合、利用者支援システム１０００の支援可能範囲内の各地に設置されている読取装置が該ＩＣタグに記憶されている情報を読み取ることで、該読取装置が設置されている場所を利用者端末５０の位置として検出することとしても良い。

また、例えばＳｕｉｃａ（登録商標）等の改札システムによって実現することも可能である。即ち、各駅に設置されている改札装置が、利用者が有するＳｕｉｃａカード或いは利用者端末５０に内蔵されている非接触型のＩＣチップに記憶されている情報を読み取ることで、利用者の改札の通過を検出することができる。

更に、利用者端末５０がＧＰＳ機能を有している場合には、該利用者端末５０によって位置検出システム３０を実現することとしても良い。

＜代行システム＞
代行システム４０は、外部システム６０と接続されており、利用者の代わりに外部システム６０と通信を行って外部システム６０に所定の処理を実行させる。また、代行システム４０は、ダイヤ予測システム２０、位置検出システム３０、利用者端末５０及び外部システム６０と接続されている。そして、代行システム４０は、位置検出システム３０から受信した位置検出情報やダイヤ予測システム２０から受信した所要時間情報等に基づいて、予め登録されている代行処理を行うか否か（実行の要否）を判断し、その判断結果に応じて、外部システム６０と通信を行って予め登録されている代行処理内容に従った代行処理を行う。

図９は、代行システム４０の機能構成を示すブロック図である。同図に示すように、代行システム４０は、機能的には、通信部４１０と、処理部４２０と、記憶部４４０と、を備えて構成される。

通信部４１０は、処理部４２０からの通信制御信号に従って所与の通信回線に接続し、例えばダイヤ予測システム２０や位置検出システム３０、利用者端末５０、外部システム６０等の外部装置とのデータ通信を行う。この機能は、例えば無線通信モジュール、モデム、ＴＡ等によって実現される。

処理部４２０は、代行システム４０全体の制御等の各種演算処理を行う。この機能は、例えばＣＰＵ等の演算装置やＩＣメモリ等の記憶装置、その制御プログラム等によって実現される。また、処理部４２０は、利用者監視部４２２と、支援計画登録部４３２と、を含む。

利用者監視部４２２は、利用者情報４５４及び登録支援計画情報４５６を参照し、位置検出システム３０から受信した位置検出情報に基づいて利用者の行動を監視し、監視した利用者の行動に応じて予め登録されている代行処理を実行する。また、利用者監視部４２２は、到達可能性判断部４２４と、代行要否判断部４２６と、代行制御部４２８と、を含む。

利用者情報４５４は、利用者支援システム１０００による支援を受ける利用者に関する情報である。図１０に、利用者情報４５４のデータ構成の一例を示す。同図によれば、利用者情報４５４は、利用者毎に、利用者を識別する利用者ＩＤ（４５４ａ）と、所有している利用者端末５０を識別する利用者端末ＩＤ（４５４ｂ）と、連絡先情報（４５４ｃ）と、登録行動情報（４５４ｄ）と、を対応付けて格納する。

連絡先情報（４５４ｃ）は、代行システム４０から利用者への連絡先に関する情報を格納する。ここでは、利用者が取得している電子メールアドレスとする。

登録行動情報（４５４ｄ）は、利用者が登録している支援を受けたい予定行動に関する情報を格納する。具体的には、予定行動内容及びこれに対応する代行処理内容を含む支援計画を識別する支援計画ＩＤを格納する。ここでは、複数の支援計画を登録可能である。そして、登録されている支援計画が完了すると、その時点で該当する支援計画ＩＤが削除される。

例えば同図の場合、「利用者１」は、利用者端末５０として「携帯電話機１」を所有し、支援計画として「支援計画１」を登録している。また、「利用者２」は、利用者端末５０として「携帯電話機２」を所有し、支援計画として「支援計画２」及び「支援計画３」を登録している。

登録支援計画情報４５６は、利用者によって登録されている支援計画に関する情報である。一の支援計画につき一の登録支援計画情報４５６が生成される。即ち、登録支援計画情報４５６は、現在登録されている支援計画の総数だけ記憶されている。

図１１〜１３は、登録支援計画情報４５６のデータ構成の一例を示す図である。同図によれば、登録支援計画情報４５６は、支援計画ＩＤ（４５６ａ）と、予定行動情報（４５６ｂ）と、代行処理情報（４５６ｇ）と、を格納する。

予定行動情報（４５６ｂ）は、利用者の予定行動に関する情報を格納する。具体的には、種別（４５６ｃ）と、場所（４５６ｄ）と、日時（４５６ｅ）と、その他情報（４５６ｆ）と、を含む。

種別（４５６ｃ）は、予定行動の種別（種類）であり、例えば「待ち合わせ」や「電子チケット予約」、「家電制御」等である。即ち、図１１は、予定行動の種別が「待ち合わせ」である支援計画についての登録支援計画情報４５６であり、図１２は、種別が「電子チケット予約」である支援計画についての登録支援計画情報４５６であり、図１３は、種別が「家電制御」である支援計画についての登録支援計画情報４５６である。

場所（４５６ｄ）は、予定行動を実行する場所であり、地図上でその位置が特定できるよう、具体的な名称や住所、緯度経度等で表現される。また、日時（４５６ｅ）は、予定行動を実行する日時であり、何月何日の何時何分といった日付を含む時分単位で表現されている。

その他情報（４５６ｆ）は、種別（４５６ｃ）に応じて予定行動に必要な各種の情報を格納する。例えば種別（４５６ｃ）が「待ち合わせ」の場合には、図１１に示すように、待ち合わせの相手や同行者の氏名といった情報を格納する。

また、種別（４５６ｃ）が「電子チケット予約」の場合には、図１２に示すように、例えば映画やコンサートといったイベント予約であればそのイベントの種類や名称、宿泊予約であれば宿泊先の名称、飛行機や鉄道等の交通機関の座席予約であればその交通機関の名称や便名といった、電子チケットの予約対象の名称や、チケットＩＤといった情報を格納する。

また、種別（４５６ｃ）が「家電制御」場合には、図１３に示すように、「風呂」や「空調」といった制御対象となる家電の名称、設定時刻といった情報を格納する。

代行処理情報（４５６ｇ）は、必要に応じて実行されるべき代行処理の内容に関する情報（処理手順が記述されたプログラムの一種）を格納する。この代行処理情報（４５６ｇ）は、種別（４５６ｃ）に応じた内容となる。

例えば、種別（４５６ｃ）が「待ち合わせ」である場合には、図１１に示すように、代行処理として、（１）待ち合わせ相手に電子メールを送信する、といった処理内容を格納する。また、この処理（１）の実行に必要な情報として、（ａ）電子メールの宛先（待ち合わせ相手である「Ｃさん」の電子メールアドレス）、（ｂ）電子メールの内容（ここでは、待ち合わせ時刻に遅れる旨、予測到達時刻、利用者の連絡先である電子メールアドレス）、といった情報を格納する。

また、種別（４５６ｃ）が「電子チケット予約」である場合には、図１２に示すように、代行処理の内容として、（１）電子チケットの予約を管理するチケット管理システム６２に接続する、（２）電子チケットの予約変更を要請する、といった処理内容を格納する。また、この処理（２）の実行に必要な情報として、（ａ）変更希望日時（ここでは、第１希望日時として「3／3 18：00」、第２希望日時として「3／4 13：00」）、といった情報を格納する。

また、種別（４５６ｃ）が「家電制御」である場合には、図１３に示すように、代行処理の内容として、（１）家電を制御する家電制御システム６４に接続する、（２）該当機器の設定時刻を変更する、といった処理内容を格納する。また、この処理（２）の実行に必要な情報として、（ａ）変更希望時刻（ここでは、予測到達時刻の１０分後）、といった情報を格納する。

図９において、到達可能性判断部４２４は、利用者情報４５４及び登録支援計画情報４５６を参照し、位置検出システム３０から取得した位置検出情報及びダイヤ予測システム２０から取得した所要時間情報等に基づいて、利用者が、予め登録している登録している場所（到達場所）へ日時（到達必須時刻）までに到達する可能性（到達可能性）を判断する。

具体的には、先ず、利用者の現在位置を判断する。利用者の現在位置は、位置検出システム３０から受信した位置検出情報に基づく。即ち、位置検出情報には、利用者端末ＩＤと、検出位置と、検出時刻とが含まれるが、利用者が所有する利用者端末５０に該当する位置検出情報に含まれる検出位置を該利用者の“現在位置”とするとともに、検出時刻を判断の基準となる“現在時刻”とする。

次いで、到達場所及び到達必須時刻を判断する。具体的には、登録支援計画情報４５６に格納されている場所（４５６ｄ）を到達場所とし、日時（４５６ｅ）を到達必須時刻とする。

続いて、現在位置から到達場所までの行程を設定する。具体的には、図１４に示すように、地図情報４６２を参照して、利用者の現在位置の最寄駅を乗車駅とするとともに、到達場所の最寄駅を降車駅とする。そして、鉄道システム１１００から取得した鉄道路線情報に基づいて乗車駅から降車駅までの所要時間が最短となる経路（経由駅、路線、列車種別等）を判断して、現在位置から到達位置までの行程を設定する。

そして、この設定した行程に沿って利用者が移動したと仮定した場合に予測される到達場所への到達時刻（予測到達時刻）を算出する。

図１５は、予測到達時刻の算出を説明するための図であり、時間軸に対する事象の発生とその時刻との関係を示している。同図によれば、先ず、現在位置から乗車駅までの所要時間Ｅ１を、この区間での移動手段に応じて算出する。具体的には、例えば移動手段が“徒歩”であれば、地図情報４６２を参照して現在位置から乗車駅までの地図上の距離（道のり）を算出し、これに徒歩での移動速度（例えば、70［ｍ／分］）を乗することで算出する。

そして、算出した所要時間Ｅ１を現在時刻ｔｎに加算することで乗車駅への到達時刻ｔ１２を算出する。即ち、乗車駅への到達時刻ｔ１２は次式（８）で与えられる。
ｔ１２＝ｔ１１＋Ｅ１ ・・・（８）

また、降車駅から到達場所までの所要時間Ｅ２を、所要時間Ｅ１と同様に、地図情報４６２を参照することによって算出する。

次いで、乗車駅を起点駅とし、降車駅を終点駅とする駅間（鉄道利用区間）の所要時間Ｆをダイヤ予測システム２０に要求する。このとき、算出した乗車駅への到達時刻ｔ１２を基準時刻ｔ０とするとともに、運行状況が“非復旧”或いは“仮復旧”である場合に仮復旧時間及び駅間の所要時間を算出するための所定の確率Ｎの値を指定して要求する。

ここで、「所定の確率Ｎ」は、上述のように、ダイヤ予測システム２０が予測所要時間の算出の際に用いる値、詳細には、仮復旧時間Ｘを算出する際の仮復旧確率Ｆ（Ｘ）、及び、駅間の所要時間Ｘを算出する際の到達確率Ｆ（Ｘ）に相当するものであり、算出した仮復旧時間Ｘ及び所要時間Ｘの確度（確率）を示すものである。即ち、この所定の確率Ｎの値が大きい程、算出された予測所要時間に対する信頼性が高いとみなすことができる。

すると、ダイヤ予測システム２０からは、要求した乗車駅から降車駅までの駅間（鉄道利用区間）の所要時間Ｆが、該区間の現在の運行状況とともに送信されてくる。即ち、該区間の現在の運行状況が“正常”或いは“回復”であれば、通常ダイヤ或いは回復ダイヤに基づいた通常所要時間が送信され、運行状況が“非復旧状態”或いは“仮復旧”であれば、通常ダイヤに基づいた通常所要時間及び統計演算結果情報２６８に基づいた予測所要時間が送信されてくる。

そして、鉄道利用区間の現在の運行状況が“正常運行”或いは“回復”の場合には、受信した通常所要時間を鉄道利用区間の所要時間Ｆとし、運行状況が“非復旧”或いは“仮復旧”の場合には、受信した予測所要時間を鉄道利用区間の所要時間Ｆとする。そして、現在時刻ｔ１１に、所要時間Ｅ１、Ｆ、Ｅ２を加算することで、到達場所への予測到達時刻ｔ１４を算出する。従って、予測到達時刻ｔ１４は次式（９）で与えられる。
ｔ１４＝ｔ１１＋Ｅ１＋Ｆ＋Ｅ２ ・・・（９）

また、鉄道利用区間の現在の運行状況が“非復旧”或いは“仮復旧”の場合には、更に、現在時刻ｔ１１に所要時間Ｅ１、Ｅ２及び受信した通常所要時間Ｆ´を加算することで、鉄道利用区間の運行状況が“正常運行”であると仮定した場合の到達場所への通常時予測到達時刻ｔ１５を算出する。従って、通常時予測到達時刻ｔ１５は次式（１０）で与えられる。
ｔ１５＝ｔ１１＋Ｅ１＋Ｆ´＋Ｅ２ ・・・（１０）

尚、現在位置が駅或いは駅間（列車に乗車中）の場合には、予測到達時刻を算出する際に、現在位置から乗車駅までの所要時間Ｅ１が不要となる。また、現在位置に相当する駅或いは最近接する駅を起点駅とし、降車駅を終点駅とする駅間の所要時間を、現在時刻を基準時刻としてダイヤ予測システム２０に要求し、受信した所要時間Ｇ及び降車駅から到達場所までの所要時間Ｅ２を現在時刻ｔ１１に加算することで予測到達時刻ｔ１４´を算出する。従って、この場合の予測到達時刻ｔ１４´は次式（１１）で与えられる。
ｔ１４´＝ｔ１１＋Ｇ＋Ｅ２ ・・・（１１）

予測到達時刻を算出すると、算出した予測到達時刻及び行程に含まれる鉄道利用区間の現在の運行状況に基づいて、利用者の到達必須時刻までの到達場所への到達可能性を判断する。

具体的には、行程に含まれる鉄道利用区間の運行状態が“正常運行”或いは“回復”である場合には、図１６（ａ）に示す到達可能性判断テーブル５１０Ａに従って到達可能性を判断する。到達可能性判断テーブル５１０Ａは、条件（５１０ａ）と、判断する到達可能性（５１０ｂ）と、を対応付けて格納している。

従って、同図（ａ）によれば、予測到達時刻が到達必須時刻よりも早い或いは一致する（予測到達時刻≦到達必須時刻）場合には、到達可能性を“可能”と判断し、予測到達時刻が到達必須時刻よりも遅い（予測到達時刻＞到達必須時刻）場合には、到達可能性を“不可能”と判断する。

また、鉄道利用区間の運行状態が“非復旧”或いは“仮復旧状態”である場合には、同図（ｂ）に示す到達可能性判断テーブル５１０Ｂに従って到達可能性を判断する。到達可能性判断テーブル５１０Ｂは、条件（５１０ａ）と、判断する到達可能性（５１０ｂ）と、を対応付けて格納している。

従って、同図（ｂ）によれば、通常時予測到達時刻が到達必須時刻よりも遅い（通常時予測到達時刻＞到達必須時刻）場合には、到達可能性を“不可能”と判断する。一方、通常時予測到達時刻が到達必須時刻よりも早い或いは一致し、且つ、予測到達時刻が到達必須時刻よりも早い或いは一致する（通常時予測到達時刻≦到達必須時刻、且つ、予測到達時刻≦到達必須時刻）場合には、到達可能性を“可能性高い”と判断し、通常時予測到達時刻が到達必須時刻よりも早い或いは一致し、且つ、予測到達時刻が到達必須時刻よりも遅い（通常時予測到達時刻≦到達必須時刻、且つ、予測到達時刻＞到達必須時刻）場合には、到達可能性を“可能性低い”と判断する。

ここで、「通常時予測到達時刻」とは、鉄道利用区間の運行状態が“非復旧”或いは“仮復旧”であるときに、該区間が“正常運行”であると仮定した場合の到達場所への予測到達時刻である。即ち、通常時予測到達時刻が到達必須時刻よりも遅い場合には、鉄道利用区間の運行状態（“非復旧”或いは“仮復旧”）に関わらず、到達不可能と判断している。

運行状況が“非復旧”或いは“仮復旧”である場合には、ダイヤが確定しておらず、ダイヤ予測システム２０は過去の事例（事故ＤＢ２６２）に基づいて駅間の予測所要時間を確率的に算出している。このため、予測所要時間を用いて算出した予測到達時刻も確率的な値となり、到達可能性を“可能”或いは“不可能”とは判断できないが、予測所要時間の算出に用いた所定の確率Ｎの値によって到達可能性の程度を判断することは可能である。

つまり、所定の確率Ｎの値が大きい程、算出された予測所要時間の確度（精度、信頼性）が高いとみなすことができる。このため、ある程度の確度を保証できる所定の確率Ｎ（例えば、Ｎ＝「0.85」）で算出した予測所要時間を用いて算出した予測到達時刻を到達必須時刻と比較することで、到達可能性の程度を判断することができる。

図９において、代行要否判断部４２６は、到達可能性判断部４２４によって判断された到達可能性（“可能”、“可能性が高い”、“可能性が低い”或いは“不可能”）に基づき、代行要否判断テーブル５２０に従って代行処理の実行要否を判断する。

図１７は、代行要否判断テーブル５２０のデータ構成の一例を示す図である。同図によれば、代行要否判断テーブル５２０は、到達可能性（５２０ａ）と、代行処理の実行要否（５２０ｂ）と、を対応付けて格納している。

従って、同図によれば、到達可能性が“可能”である場合には、代行処理の実行を“不要”と判断し、到達可能性が“不可能”である場合には、代行処理の実行を“要”と判断する。

また、到達可能性が“可能性高い”である場合には、利用者からの「実行指示」が有れば代行処理の実行を“要”と判断し、「実行指示」が無ければ“不要”と判断する。

ここで、利用者からの「実行指示」の有無は次のように得られる。即ち、到達可能性が“可能性高い”である場合に、到達場所までの鉄道区間にダイヤ乱れが発生しているが到達可能性が“高い”ことを知らせる旨、及び、代行処理の実行を要するかを問う旨を内容とする電子メールを、利用者の連絡先として登録されている電子メールアドレス宛に送信する。そして、所定時間以内に、この送信メールに対する返信メールとして、代行処理の実行を要する旨を内容とする電子メールが受信されたならば「実行指示」有りとみなし、受信されなければ「実行指示」無しとみなす。

また、到達可能性が“可能性低い”である場合には、利用者からの「不要指示」が有れば代行処理の実行を“不要”と判断し、「実行指示」が無ければ“要”と判断する。

ここで、利用者からの「不要指示」の有無は次のように得られる。即ち、到達可能性が“可能性低い”である場合に、到達場所までの鉄道区間にダイヤ乱れが発生しており到達可能性が“低い”ことを知らせる旨、及び、代行処理の実行が不要であるかを問う旨を内容とする電子メールを、利用者の連絡先として登録されている電子メールアドレス宛に送信する。そして、所定時間以内に、この送信メールに対する返信メールとして、代行処理の実行が不要である旨を内容とする電子メールが受信されたならば「不要指示」有りとみなし、受信されなければ「不要指示」無しとみなす。

代行制御部４２８は、代行要否判断部４２６によって代行処理の実行が“要”と判断された場合に、予め登録されている代行処理を実行する。即ち、登録支援計画情報４５６に格納されている代行処理情報（４５６ｇ）に従った代行処理を実行する。そして、代行処理を実行した後、代行処理の結果に応じて予定行動情報（４５６ｂ）を更新するとともに、代行処理を実行した旨及びその処理結果を内容とする電子メール（報告メール）を、利用者への連絡先として予め登録されている電子メールアドレス宛に送信する。

具体的には、例えば図１１に示した登録支援計画情報４５６の場合には、待ち合わせ相手である「Ｃさん」の電子メールアドレス宛に、待ち合わせ時刻に遅れる旨、予測到達時刻及び利用者の連絡先として登録されている電子メールアドレスを内容とする電子メールを送信する。そして、待ち合わせ相手に電子メールを送信した旨を内容とする電子メール（報告メール）を、利用者の連絡先として登録されている電子メールアドレスに送信する。

また、図１２に示した登録支援計画情報４５６の場合には、チケット管理システム６２に接続して、チケットＩＤ及び変更希望日時とともに電子チケットの予約日時の変更を要請する。その結果、何れの希望日時への変更も不可能であれば、予約のキャンセルを要請する。そして、予定行動情報（４５６ｂ）の日時（４５６ｅ）を変更後の予約日時に変更し、その他情報（４５６ｆ）のチケットＩＤを変更後のチケットＩＤに変更する。また、利用者の連絡先として登録されている電子メールアドレスに、予約日時の変更を要請した旨及びその結果（予約変更がなされたならば、変更後の新たな予約日時及び予約ＩＤであり、キャンセルされたならばその旨である）を内容とする電子メール（報告メール）を送信する。

また、図１３に示した登録支援計画情報４５６の場合には、家電制御システム６４に接続して、制御対象となっている機器の名称（機器ＩＤ）及び変更希望時刻とともに、設定時刻の変更を要請する。同図では、予測到達時刻の「１０分」後の時刻を、変更希望日時として要請する。そして、予定行動情報（４５６ｂ）のその他情報（４５６ｆ）の設定時刻を変更後の時刻に変更するとともに、利用者の連絡先として登録されている電子メールアドレスに、設定時刻を変更した旨及び変更後の設定時刻を内容とする電子メール（報告メール）を送信する。

到達可能性判断部４２４及び代行要否判断部４２６による処理結果は、利用者支援情報４５８に格納される。図１８に、利用者支援情報４５８のデータ構成の一例を示す。同図に示すように、利用者支援情報４５８は、各利用者についての利用者支援情報４５８−１、４５８−２、・・・、から構成される。即ち、利用者支援情報４５８は利用者の人数だけ用意されている。

同図によれば、利用者支援情報４５８は、利用者ＩＤ（４５８ａ）と、現在位置（４５８ｂ）と、現在時刻（４５８ｃ）と、支援状況情報（４５９）と、を格納する。

現在位置（４５８ｂ）は、到達可能性の判断の際に利用者の“現在位置”とみなした、位置検出システム３０から受信した位置検出情報に含まれる検出位置である。また、現在時刻（４５８ｃ）は、到達可能性の判断の際に“現在時刻”とみなした、位置検出システム３０から受信した位置検出情報に含まれる検出時刻である。

支援状況情報（４５９）は、利用者が登録している支援計画に対する支援状況に関する情報を格納する。登録している支援計画１つにつき１つの支援状況情報（４５９）が格納される。即ち、支援状況情報（４５９）は、利用者が登録している支援計画の数だけ用意される。支援状況情報（４５９）は、支援計画ＩＤ（４５９ａ）と、算出された予測到達時刻（４５９ｂ）と、受信した鉄道利用区間の運行状況（４５９ｃ）と、判断した到達可能性（４５９ｄ）と、判断した代行処理の実行要否（４５９ｅ）と、を格納する。

この利用者支援情報４５８は、到達可能性判断部４２４による到達可能性の判断及び代行要否判断部４２６による代行処理の要否の判断が行われる毎に更新される。

図９において、支援計画登録部４３２は、利用者からの要求に応じて新たな支援計画を登録する。具体的には、要求された内容に基づいて新たな登録支援計画情報４５６を作成するとともに、該支援計画に割り当てた支援計画ＩＤを、利用者情報４５４の該利用者に対応する登録行動情報（４５４ｄ）に追加する。

利用者の支援計画の登録要求方法としては、ここでは、利用者が利用者端末５０を用いて、支援を受けたい予定行動の内容（場所、時刻）及び代行処理の内容を含む電子メールを代行システム４０の電子メール宛に送信することとする。そして、代行システム４０は、受信した電子メールの内容に従って登録支援計画情報４５６を作成することになる。また、他の登録要求方法として、利用者端末５０がブラウザ機能を有する場合には、該利用者端末５０を用いて代行システム４０が開設する支援計画を登録するためのホームページにアクセスし、このホームページ上において必要項目を入力・送信することとしても良い。

記憶部４４０は、処理部４２０に代行システム４０を統合的に制御させるためのプログラムやデータ等を記憶する。具体的には、プログラムとして、処理部４２０を利用者監視部４２２として機能させるための利用者監視プログラム４４２と、支援計画登録部４３２として機能させるための支援計画登録プログラム４５２と、を記憶する。また、利用者監視プログラム４４２は、到達可能性判断部４２４として機能させるための到達可能性判断プログラム４４４と、代行要否判断部４２６として機能させるための代行要否判断プログラム４４６と、代行制御部４２８として機能させるための代行制御プログラム４４８と、を含む。また、データとして、利用者情報４５４と、登録支援計画情報４５６と、利用者支援情報４５８と、鉄道システム１１００の管轄区間の範囲を含んでいる地図情報４６２と、を記憶する。

＜利用者端末＞
利用者端末５０は、利用者支援システム１０００による支援を受ける利用者が所有する携帯型の情報端末装置であり、例えば携帯電話機やＰＤＡ、ノート型パソコン等で実現される。また、この利用者端末５０は、所定の通信回線に接続して代行システム４０等の外部装置との無線データ通信を行う無線データ通信機能及び電子メールの送受信を行う電子メール機能を有している。

＜外部システム＞
外部システム６０は、代行システム４０と接続され、代行システム４０が利用者に代わって所定の処理を行わせる対象となるシステムである。ここでは、外部システム６０として、電子チケットの予約を管理するチケット管理システム６２や、「風呂」、「空調」、「防犯システム」といった各種家電を制御する家電制御システム６４が含まれる。

［処理の流れ］
次に、本実施形態における処理の流れを説明する。
本実施形態では、利用者を支援するための処理として、所定時間毎に代行システム４０が利用者監視処理を実行するとともに、この利用者監視処理において、ダイヤ予測システム２０が所要時間算出処理を実行する。また、代行システム４０は、利用者端末５０を通じて利用者から支援計画の登録要求を受ける毎に支援計画登録処理を実行するとともに、ダイヤ予測システム２０は、鉄道システム１１００の管轄区間内で事故が発生した場合に該発生した事故を対象とする統計演算処理を実行する。

＜利用者監視処理＞
図１９は、利用者監視処理の流れを示すフローチャートである。この処理は、代行システム４０が所定時間毎（例えば、３０分毎）に実行する処理であり、利用者監視部４２２が利用者監視プログラム４４２を実行することで実現される。

同図によれば、利用者監視部４２２は、支援対象となっている各利用者を対象としてループＡの処理を実行する（ステップＡ１１）。

ループＡでは、先ず、対象となっている利用者の現在位置を取得する。即ち、位置検出システム３０から受信した、該利用者が所有する利用者端末５０についての位置検出情報に含まれる検出位置を利用者の“現在位置”とし、検出時刻を“現在時刻”とする（ステップＡ１２）。次いで、利用者が登録している各支援計画を対象としてループＢの処理を実行する（ステップＡ１３）。

ループＢでは、到達可能性判断部４２４が到達可能性判断処理を実行する（ステップＡ１４）。

図２０、図２１は、到達可能性判断処理の流れを示すフローチャートである。この処理は、到達可能性判断部４２４が到達可能性判断プログラム４４４を実行することで実現される。

図２０によれば、到達可能性判断部４２４は、該当する登録支援計画情報４５６を参照して、予定行動情報（４５６ｂ）に格納されている場所（４５６ｄ）を到達場所とし、日時（４５６ｅ）を到達必須時刻とする。そして、図１４を参照して説明したように、利用者の現在位置から到達場所に至る行程を設定する（ステップＢ１１）。

次いで、到達可能性判断部４２４は、設定した行程中に鉄道区間が含まれるか否かを判断し、含まれない場合には（ステップＢ１２：ＮＯ）、現在位置から到達場所までの予測所要時間を、その移動手段に応じて算出する（ステップＢ１３）。例えば移動手段が徒歩であれば、地図情報４６２を参照して利用者の現在位置から到達場所までの距離（道のり）を算出し、これに徒歩による移動速度を乗することで予測到達時刻を算出する。そして、ステップＢ２１に移行する。

一方、設定した行程中に鉄道区間が含まれる場合には（ステップＢ１２：ＹＥＳ）は、到達可能性判断部４２４は、図１５を参照して説明したように、現在位置から乗車駅までの所要時間Ｅ１、及び、降車駅から到達場所までの所要時間Ｅ２を、その移動手段に応じて算出する（ステップＢ１４）。

次いで、算出した所要時間Ｅ１を現在時刻に加算した時刻を基準時刻として、行程中に含まれる鉄道区間の所要時間をダイヤ予測システム２０に要求する（ステップＢ１５）。そして、ダイヤ予測システム２０から送信（回答）される該鉄道区間の所要時間及び現在の運行状況を受信する（ステップＢ１６）。ここで、運行状況が“正常運行”或いは“回復”ならば、所要時間として通常所要時間を受信し、運行状況が“非復旧”或いは“仮復旧”ならば、所要時間として予測所要時間及び通常所要時間を受信することになる。

続いて、到達可能性判断部４２４は、受信した鉄道区間の運行状態が“正常運行”或いは“回復”であるならば（ステップＢ１７：ＹＥＳ）、現在時刻に、算出した所要時間Ｅ１、Ｅ２と、受信した通常所要時間を加算することで、到達場所への予測到達時刻を算出する（ステップＢ１８）。

そして、到達可能性判断テーブル５１０Ａに従って到達可能性を判断する。即ち、算出した予測到達時刻と到達必須時刻とを比較し、予測到達時刻が到達必須時刻より遅いならば（ステップＢ２１：ＹＥＳ）、到達可能性を“不可能”と判断する（ステップＢ２２）。一方、予測到達時刻が到達必須時刻より早い或いは一致するならば（ステップＢ２１：ＮＯ）、到達可能性を“可能”と判断する（ステップＢ２３）。

一方、ステップＢ１７において、受信した鉄道区間の運行状況が“非復旧”或いは“仮復旧”であるならば（ステップＢ１７：ＮＯ）、現在時刻に、算出した所要時間Ｅ１、Ｅ２と、受信した予測所要時間とを加算して、到達場所への予測到達時刻を算出する（ステップＢ１９）。また、現在時刻に、算出した所要時間Ｅ１、Ｅ２と、受信した通常所要時間とを加算して、到達場所への通常時予測到達時刻を算出する（ステップＢ２０）。

そして、到達可能性判断テーブル５１０Ｂに従って到達可能性を判断する。即ち、算出した通常時予測到達時刻と到達必須時刻とを比較し、通常時予測到達時刻が到達必須時刻より遅いならば（ステップＢ２４：ＹＥＳ）、到達可能性を“不可能”と判断する（ステップＢ２５）。

一方、通常時予測到達時刻が必達到達時刻より早い或いは一致するならば（ステップＢ２４：ＮＯ）、続いて、予測到達時刻と到達必須時刻とを比較する。そして、予測到達時刻が到達必須時刻より遅いならば（ステップＢ２６：ＹＥＳ）、到達可能性を“可能性低い”と判断し（ステップＢ２７）、予測到達時刻が到達必須時刻より早い或いは一致するならば（ステップＢ２６：ＮＯ）、到達可能性を“可能性高い”と判断する（ステップＢ２８）。

以上の処理を行うと、到達可能性判断部４２４は到達可能性判断処理を終了して図１９のステップＡ１５に戻る。

到達可能性判断処理が終了すると、続いて、代行要否判断部４２６が代行要否処理を実行する（ステップＡ１５）。

図２２は、代行要否判断処理の流れを示すフローチャートである。この処理は、代行要否判断部４２６が代行要否判断プログラム４４６を実行することで実現される。

同図によれば、代行要否判断部４２６は、判断された到達可能性が“可能性高い”であるならば（ステップＣ１１：ＹＥＳ）、到達可能性が“高い”ことを知らせる旨、及び、代行処理の実行を要するかを問う旨を内容とする電子メールを、利用者の連絡先として登録されている電子メールアドレス宛に送信する（ステップＣ１２）。

そして、所定時間以内に、この送信メールに対する返信メールとして、代行処理の実行を要する旨を内容とする電子メールが受信されたならば（ステップＣ１３：ＹＥＳ）、代行要否判断部４２６は、代行処理の実行要否を“要”と判断し（ステップＣ１４）、受信されないならば（ステップＣ１３：ＮＯ）、代行処理の実行要否を“不要”と判断する（ステップＣ１８）。

また、到達可能性が“可能性低い”ならば（ステップＣ１１：ＮＯ〜ステップＣ１５：ＹＥＳ）、代行要否判断部４２６は、到達可能性が“低い”ことを知らせる旨、及び、代行処理の実行が不要であるかを問う旨を内容とする電子メールを、利用者の連絡先として登録されている電子メールアドレス宛に送信する（ステップＣ１６）。

そして、所定時間以内に、この送信メールに対する返信メールとして、代行処理の実行が不要の旨を内容とする電子メールが受信されたならば（ステップＣ１７：ＹＥＳ）、代行要否判断部４２６は、代行処理の実行要否を“不要”と判断し（ステップＣ１８）、受信されないならば（ステップＣ１７：ＮＯ）、代行処理の実行要否を“要”と判断する（ステップＣ１４）。

また、到達可能性が“不可能”ならば（ステップＣ１５：ＮＯ〜ステップＣ１９：ＹＥＳ）、代行要否判断部４２６は、到達可能性が“不可能”であることを知らせる旨、及び、代行処理を実行する旨を内容とする電子メールを、利用者の連絡先として登録されている電子メールアドレス宛に送信する（ステップＣ２０）。そして、代行処理の実行要否を“要”と判断する（ステップＣ１４）。

また、到達可能性が“可能”ならば（ステップＣ１９：ＮＯ）、代行要否判断部４２６は、代行処理の実行要否を“不要”を判断する（ステップＣ１８）。

以上の処理を行うと、代行要否判断部４２６は代行要否判断処理を終了して図９のステップＡ１６に戻る。

代行要否判断処理が終了すると、続いて、判断された代行処理の実行要否が“要”であるならば（ステップＡ１６：ＹＥＳ）、代行制御部４２８が、該当する登録支援計画情報４５６に格納されている代行処理情報（４５６ｇ）に従って代行処理を実行する（ステップＡ１７）。

そして、利用者監視部４２２は、支援計画が完了したか否かを判断し、完了したと判断したならば（ステップＡ１８：ＹＥＳ）、該当する登録支援計画情報４５６を削除する（ステップＡ１９）。

以上の処理を、支援計画それぞれを対象として行う（ステップＡ２０）。そして、利用者それぞれを対象としたループＢが終了すると（ステップＡ２１）、利用者監視部４２２は利用者監視処理を終了する。

＜所要時間算出処理＞
図２３、図２４は、所要時間算出処理の流れを示すフローチャートである。この処理は、ダイヤ予測システム２０が、代行システム４０から所要時間が要求された場合（例えば、図２０のステップＢ１５）に実行する処理であり、所要時間算出部２４４が所要時間算出プログラム２５４を実行することで実現される。

図２３によれば、所要時間算出部２４４は、先ず、要求された駅間の現在の運行状況を運行管理システム１０に問い合わせる（ステップＤ１１）。

そして、取得した運行状況が“回復”ならば（ステップＤ１２：ＹＥＳ）、所要時間算出部２４４は、要求された駅間を含む路線の回復ダイヤを運行管理システム１０に要求する（ステップＤ１３）。次いで、通常所要時間算出部２４６が、取得された回復ダイヤに基づいて、基準時刻に要求された駅間の起点駅にいると仮定した場合の所要時間を算出し、算出した所要時間を通常所要時間とする（ステップＤ１４）。その後、所要時間算出部２４４は、算出された通常所要時間を、取得した運行状況（即ち、“回復”）とともに代行システム４０に送信する（ステップＤ１８）。

また、取得した運行状況が“正常運行”、“非復旧”或いは“仮復旧”ならば（ステップＤ１２：ＮＯ）、所要時間算出部２４４は、要求された駅間を含む路線の通常ダイヤを運行管理システム１０に要求する（ステップＤ１５）。次いで、通常所要時間算出部２４６が、取得された通常ダイヤに基づいて、基準時刻に起点駅にいると仮定した場合の所要時間を算出し、通常所要時間とする（ステップＤ１６）。

そして、運行状況が“正常運行”ならば（ステップＤ１７：ＹＥＳ）、所要時間算出部２４４は、算出された通常所要時間を、取得した運行状況（即ち、“正常運行”）とともに代行システム４０に送信する（ステップＤ１８）。

また、運行状況が“非復旧”ならば（ステップＤ１７：ＮＯ〜ステップＤ１９：ＹＥＳ）、予測所要時間算出部２４８が、図７を参照して説明したように、起点駅についての統計演算結果情報２６８に基づき、起点駅での仮復旧時間Ａの予測値を算出する。そして、算出した仮復旧時間Ａを事故発生時刻に加算することで、予測される仮復旧時刻を算出する（ステップＤ２０）。

次いで、予測所要時間算出部２４８は、算出した仮復旧時刻と基準時刻とを比較し、仮復旧時刻が基準時刻より遅いならば（ステップＤ２１：ＹＥＳ）、起点駅についての統計演算結果情報２６８に基づき、仮復旧直後（即ち、仮復旧からの経過時間が「０」）における終点駅までの所要時間Ｂ１を算出する（ステップＤ２２）。

また、予測所要時間算出部２４８は、基準時刻から仮復旧時刻までの経過時間Ａ１を算出する（ステップＤ２３）。そして、算出した経過時間Ａ１に所要時間Ｂ１を加算することで、要求された駅間の予測所要時間を算出する（ステップＤ２４）。

一方、仮復旧時刻が基準時刻より早い或いは一致するならば（ステップＤ２１：ＮＯ）、予測所要時間算出部２４８は、仮復旧時刻から基準時刻までの経過時間Ａ２を算出する（ステップＤ２５）。次いで、起点駅についての統計演算結果情報２６８に基づき、仮復旧からの経過時間Ａ２における終点駅までの所要時間Ｂ２を算出する（ステップＤ２６）。そして、算出した所要時間Ｂ２を、要求駅間の予測所要時間とする（ステップＤ２７）。

その後、所要時間算出部２４４は、算出された予測所要時間を、先に算出された通常所要時間及び取得した運行状況（即ち、“非復旧”）とともに、代行システム４０に送信する（ステップＤ３０）。

また、運行状況が“仮復旧”ならば（ステップＤ１７：ＮＯ〜Ｄ１９）、予測所要時間算出部２４８が、図８を参照して説明したように、仮復旧時刻から基準時刻までの経過時間Ｃを算出する（ステップＤ２８）。そして、起点駅についての統計演算結果情報２６８に基づいて、仮復旧からの経過時間Ｃにおける終点駅までの所要時間を算出し、算出した所要時間を予測所要時間とする（ステップＤ２９）。

その後、所要時間算出部２４４は、算出された予測所要時間を、先に算出された通常所要時間及び運行状況（即ち、“仮復旧”）とともに、代行システム４０に送信する（ステップＤ３０）。
以上の処理を行うと、所要時間算出部２４４は、所要時間算出処理を終了する。

＜支援計画登録処理＞
図２５は、支援計画登録処理の流れを示すフローチャートである。この処理は、代行システム４０が、利用者端末５０を通じて利用者から支援計画の登録が要求された場合に実行する処理であり、支援計画登録部４３２が支援計画登録プログラム４５２を実行することで実現される。

同図によれば、支援計画登録部４３２は、支援計画の登録要求を行った利用者端末５０を判別することで、登録を要求した利用者を判別する（ステップＥ１１）。次いで、該利用者端末５０から、登録を要求する予定行動や代行処理の内容を受信する（ステップＥ１２）。そして、受信した登録要求内容に、登録に必要な情報が全て含まれているかを判断する。ここで、登録に必要な情報としては、予定行動に含まれる場所及び時刻がある。

登録要求内容に必要な情報が全て含まれているならば（ステップＥ１３：ＹＥＳ）、支援計画登録部４３２は、受信した登録要求内容に基づく登録支援計画情報４５６を生成するともに、該支援計画に割り当てた支援計画ＩＤを利用者情報４５４の該当する項目に追加する（ステップＥ１４）。一方、登録に必要な情報が不足しているならば（ステップＥ１３：ＮＯ）、情報が不足している旨及び不足している情報の種類を内容とする電子メールを、該利用者の連絡先として登録されている電子メール宛に送信する（ステップＥ１５）。
以上の処理を行うと、支援計画登録部４３２は支援計画登録処理を終了する。

＜統計演算処理＞
図２６は、統計演算処理の流れを示すフローチャートである。この処理は、ダイヤ予測システム２０が、鉄道システム１１００の管轄区間内で事故が発生した場合に実行する処理であり、統計演算部２４２が統計演算プログラム２５２を実行することで実現される。

同図によれば、先ず、操作入力部２１０からＤＢ検索条件が入力される（ステップＦ１１）。すると、統計演算部２４２は、入力されたＤＢ検索条件に適合する事故情報２６３を事故ＤＢ２６２から検索して抽出する（ステップＦ１２）。そして、抽出した事故情報２６３に含まれる復旧実績情報２６５に対して、管轄駅毎に所定の統計演算を行う（ステップＦ１３）。以上の処理を行うと、統計演算部２４２は統計演算処理を終了する。

［作用・効果］
以上、本実施形態によれば、代行システム４０は、位置検出システム３０により検出された利用者端末５０の位置を、該利用者端末５０を所有する利用者の“現在位置”とし、この現在位置から予め登録されている到達場所に至る行程を設定する。そして、この行程に含まれる鉄道区間の所要時間をダイヤ予測システム２０に要求（照会）する。ダイヤ予測システム２０は、要求された駅間の運行状況に応じて所要時間を算出し、算出した所要時間及び運行状況を代行システム４０に送信（回答）する。即ち、運行状況が“正常運行”或いは“回復”であれば、運行管理システム１０から取得した通常ダイヤ或いは回復ダイヤに基づいて通常所要時間を算出する。また、運行状況が“非復旧”或いは“仮復旧”であれば、運行管理システム１０から取得した通常ダイヤに基づいて通常所要時間を算出するとともに、統計演算結果情報２６８に基づいて確率的に予測所要時間を算出する。統計演算結果情報２６８は、事故ＤＢ２６２に蓄積されている事故情報２６３の内、該事故に類似する事故情報２６３に含まれる復旧実績情報２６５に対して所定の統計演算を行った結果の情報である。

そして、代行システム４０は、ダイヤ予測システム２０から受信した予測時間に基づいて到達場所への予測到達時刻を算出し、この予測到達時刻と予め登録されている到達必須時刻との比較結果、及び、受信した運行状況に基づいて、到達場所への到達時刻までの到達可能性を、“可能”、“可能性高い”、“可能性低い”或いは“不可能”と段階的に判断する。

従って、ダイヤ予測システム２０は、事故発生状況での鉄道区間の予測所要時間を統計的に算出しているため、この予測所要時間に対する信頼性、即ち所要時間に対する信頼性を高めることが可能となる。そして、代行システム４０は、この所要時間に基づいて到達可能性を判断し、判断結果に基づいて外部システムに所定の処理を実行させることができるため、例えば計画の変更といった所定の処理を実行させるかの判断を信頼性がより高いものとし、より適切な計画支援を実現することが可能となる。

［変形例］
尚、本発明の適用は、上述した実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で適宜変更可能である。例えば、上述した実施形態では、ダイヤ予測システム２０の予測所要時間算出部２４８が予測所要時間を算出する際に用いる所定の確度Ｎを１つとしたが、複数の確度Ｎ１、Ｎ２、・・・、を用いることとしても良い。この場合、予測所要時間算出部２４８は、これらの確率Ｎ１、Ｎ２、・・・、（但し、Ｎ１＜Ｎ２＜・・・）毎に予測所要時間Ｔ１、Ｔ２、・・、を算出し、算出したこれらの予測所要時間Ｔ１、Ｔ２、・・・、が代行システム４０に送信される。

そして、代行システム４０において、到達可能性判断部４２４は、受信した予測所要時間Ｔ１、Ｔ２、・・・、それぞれを用いて予測到達時刻ｔ１４ａ、ｔ１４ｂ、・・・、を算出し、到達必須時刻が予測到達時刻ｔ１４ａ、ｔ１４ｂ、・・、の内のどの時刻の間に位置するかに応じて、到達可能性を、例えば“可能性高い”、“可能性やや高い”、“可能性やや低い”或いは“可能性低い”といったように、到達可能性の程度を複数段階で判断する。一般的に、確率Ｎが大きい程算出される予測所要時間が大きく（長く）なり、予測到達時刻は、ｔ１４ａ、ｔ１４ｂ、・・・、の順で大きく（遅く）なる。このため、到達必須時刻が位置する前後の予測到達時刻が遅い程、到達可能性の程度が高くなるように判断する。

本実施形態の全体構成図。 運行状況の分類を説明する図。 ダイヤ予測システムの機能構成図。 事故ＤＢに蓄積される事故情報のデータ構成例。 事故情報に含まれる復旧実績情報のデータ構成例。 統計演算結果情報のデータ構成例。 運行状況が“非復旧”である場合の予測所要時間の算出を説明する図。 運行状況が“仮復旧”である場合の予測所要時間の算出を説明する図。 代行システムの機能構成図。 利用者情報のデータ構成例。 登録支援計画情報のデータ構成例（１）。 登録支援計画情報のデータ構成例（２）。 登録支援計画情報のデータ構成例（３）。 現在位置から到達場所に至る行程の設定を説明する図。 予測到達時刻の算出を説明する図。 到達可能性判断テーブルのデータ構成例。 代行要否判断テーブルのデータ構成例。 利用者支援情報のデータ構成例。 利用者監視処理の流れを示すフローチャート。 到達可能性判断処理の流れを示すフローチャート。 図２０のフローチャートの続き。 代行要否判断処理の流れを示すフローチャート。 所要時間予測処理の流れを示すフローチャート。 図２３のフローチャートの続き。 支援計画登録処理の流れを示すフローチャート。 統計演算処理の流れを示すフローチャート。

符号の説明

１０００ 利用支援システム
１１００ 鉄道システム
１０ 運行管理システム
２０ ダイヤ予測システム
２１０ 操作入力部
２２０ 表示部
２３０ 通信部
２４０ 処理部
２４２ 統計演算部
２４４所要時間算出部
２４６ 通常所要時間算出
２４８ 予測所要時間算出部
２５０ 記憶部
２５２ 統計演算プログラム
２５４ 所要時間算出プログラム
２５６ 通常所要時間算出プログラム
２５８ 予測所要時間算出プログラム
２６２ 事故ＤＢ
２６３ 事故情報
２６４ 発生状況情報
２６５ 復旧実績情報
２６８ 統計演算結果情報
３０ 位置検出システム
４０ 代行システム
４１０ 通信部
４２０ 処理部
４２２ 利用者監視部
４２４ 到達可能性判断部
４２６ 代行要否判断部
４２８ 代行制御部
４３２ 支援計画登録部
４４０ 記憶部
４４２ 利用者監視プログラム
４４４ 到達可能性判断プログラム
４４６ 代行要否判断プログラム
４４８ 代行制御プログラム
４５２ 支援計画登録プログラム
４５４ 利用者情報
４５６ 登録支援計画情報
４５８ 利用者支援情報
４６２ 地図情報
５０ 利用者端末
６０ 外部システム
６２ チケット管理システム
６４ 家電制御システム

Claims (8)

1. 鉄道事故についての復旧実績情報を蓄積した事故データベースと、前記事故データベースに蓄積された復旧実績情報に基づいて、事故が発生した場合の駅間の予測所要時間を所定の統計演算により算出する予測手段と、列車ダイヤデータベースと、前記列車ダイヤデータベースに基づいて通常ダイヤの場合の駅間の通常所要時間を算出する算出手段と、を備え、現在の運行状況に応じて、前記予測手段により算出される予測所要時間及び前記算出手段により算出される通常所要時間の何れか一方又は両方を所要時間として出力する所要時間算出システムと、
   利用者端末と通信を行うことで前記利用者端末の位置を検出する位置検出システムと、
   利用者の代わりに外部システムと通信を行って前記外部システムに所定の処理を実行させる代行システムと、
   を具備する利用者支援システムであって、
   前記代行システムは、
   到達場所及び到達必須時刻を記憶する記憶手段と、
   前記位置検出システムにより検出された利用者端末の位置から前記到達場所に至る鉄道区間を含む行路を設定する行路設定手段と、
   前記行路設定手段により設定された行路に含まれる鉄道区間の所要時間を前記所要時間算出システムに照会し、回答された所要時間に基づいて、前記到達必須時刻までに前記到達場所へ到達する到達可能性を判断する判断手段と、
   前記判断手段による判断結果に基づいて前記外部システムとの通信の実行を制御する制御手段と、
   を備えることを特徴とする利用者支援システム。
2. 前記所要時間算出システムは、現在の運行状況が事故発生状況である場合、前記予測手段により算出される予測所要時間及び前記算出手段により算出される通常所要時間の両方を出力するシステムであり、
   前記判断手段は、前記所要時間算出システムから回答された予測所要時間及び通常所要時間のどちらであっても前記到達必須時刻までに前記到達場所へ到達できない場合に、到達不可能と判断する手段であることを特徴とする請求項１に記載の利用者支援システム。
3. 前記予測手段は、所定の確度に対する予測所要時間を算出する手段であり、
   前記判断手段は、前記所要時間算出システムから回答された所要時間が予測所要時間であった場合に、回答された予測所要時間及び前記所定の確度に基づいて、少なくとも到達可能性が高い又は低いの２段階で到達可能性の程度を判断する手段である、
   ことを特徴とする請求項１又は２に記載の利用者支援システム。
4. 前記外部システムは、場所と日時とが指定された電子チケットの予約を管理するチケット管理システムであり、
   前記記憶手段は、前記チケット管理システムに予約された電子チケットの場所を到達場所とし、日時を必須到達時刻として記憶する手段であり、
   前記制御手段は、前記判断手段により到達不可能と判断された場合に、前記チケット管理システムに予約された電子チケットをキャンセルさせるように前記チケット管理システムと通信を行う手段である、
   ことを特徴とする請求項２に記載の利用者支援システム。
5. 前記外部システムは、場所と日時とが指定された電子チケットの予約を管理するチケット管理システムであり、
   前記記憶手段は、前記チケット管理システムに予約された電子チケットの場所を到達場所とし、日時を必須到達時刻として記憶する手段であり、
   前記制御手段は、前記判断手段により到達可能性が低いと判断された場合に、前記チケット管理システムに予約された電子チケットを日時を変更した電子チケットに変更させるように前記チケット管理システムと通信を行う手段である、
   ことを特徴とする請求項３に記載の利用者支援システム。
6. 前記外部システムは、予め設定された時刻に所定の処理の実行を開始するシステムであり、
   前記制御手段は、前記判断手段により到達不可能と判断された場合に、前記所定の処理の実行を中止させるように前記外部システムと通信を行う手段である、
   ことを特徴とする請求項２に記載の利用者支援システム。
7. 前記外部システムは、予め設定された時刻に所定の処理の実行を開始するシステムであり、
   前記制御手段は、前記判断手段により到達可能性が低いと判断された場合に、前記予め設定された時刻を変更させるように前記外部システムと通信を行う手段である、
   ことを特徴とする請求項３に記載の利用者支援システム。
8. 前記復旧実績情報には、事故発生から仮復旧までの仮復旧時間情報と、事故発生から完全復旧までの完全復旧時間情報と、仮復旧から完全復旧までの仮復旧期間における駅間の所要時間情報とが含まれ、
   前記予測手段は、前記復旧実績情報に含まれる仮復旧時間情報、完全復旧時間情報及び所要時間情報それぞれに対する所定の統計演算を行うことにより、予測仮復旧時間、予測完全復旧時間及び駅間の予測所要時間を算出する手段である、
   ことを特徴とする請求項１〜７の何れか一項に記載の利用者支援システム。

Images