JPWO2015033453A1 - 料金払戻しシステムおよびその方法 - Google Patents

Abstract

時間、コスト、その他を払戻し料金に反映させる。料金払戻しシステムは、交通機関を利用する乗客の移動ログを収集し、収集した移動ログの中の、交通機関の通常時の移動ログに基づいて乗客の標準移動パターンを生成する標準移動パターン生成部、交通機関の輸送障害の発生に伴う障害影響エリア及び障害影響時間帯に関する情報を取得する輸送障害情報取得部、収集した移動ログの中に、輸送障害エリア及び障害影響時間帯の乗客の移動ログである影響移動ログの有無を判定する影響有無判定部、影響有無判定部により、影響移動ログが有と判定された場合、標準移動パターンと影響移動ログとの差に基づいて、輸送障害に伴う乗客の損失度を算出する損失度算出部、及び、算出した損失度に対応した、交通機関の輸送障害の発生に伴う払戻し料金を払戻す払戻部を有する。

Description

本発明は、鉄道やバスなどの公共交通機関において輸送障害に対応する料金払戻しシステムおよびその方法に関する。

鉄道やバスなどの公共交通機関は輸送力が大きいことから、災害や人身事故、故障などの輸送障害によって運行に変更が生じると、多数の乗客に大きな影響を与えてしまう。特に鉄道網の発達した主要都市などにおいては、事故発生リスクが必然的に高くなり、輸送障害による社会的影響をいかに抑えるかが課題となっている。輸送障害が発生した際に、交通事業者は乗客の混乱を抑え、適切に誘導を行うことが求められるが、現在は旅客案内や振替輸送などの一般的な対策となっている。

振替輸送とは鉄道を対象に、不通区間を含む乗車券を持っているなど所定の条件を満たしている乗客に対して、他の交通機関（鉄道、バス）を無料で利用できる制度である。但し、事故発生前に不通区間を含む乗車券などを購入していた乗客を対象とする場合がほとんどであり、誰もが払戻しのサービスを受けられるわけではない。また、乗客が振替輸送サービスを受けるためには各自が所持している乗車券、定期券、ＩＣカードなどを駅係員に提示し、振替乗車票を受け取ったり、もしくは後日、駅窓口などで運賃精算を行ったりしなければならないため、手間がかかるという問題がある。また、振替輸送で補償される金額は、あくまで本来の運賃からの差額のみとなっている。そのような事情から乗客の中には自己負担で迂回を行うような人も多い。 また、駅係員にとっても振替乗車票の配布および回収を人手で行わないとならないため、負担が大きいとともに、輸送障害の影響を受けた乗客の把握の精度の低さが課題となっている。

特許文献１には、振替輸送に要した費用を正確に求めることができる振替費用精算システムが開示されている。

特許文献２には、ＥＴＣにおける料金所通過時刻に基づいて事故や渋滞等の停滞事象の影響による所要時間の差を求め、遅延損害を算出するシステムが開示されている。

特許文献３には、計画ダイヤと実績ダイヤとの差異に基づいて絶対遅延時間、駅毎遅延時間、列車間隔不良本数、追越し余裕不良本数、払戻しコスト、運行中止列車数、あるいは顧客迷惑度等、予定の評価項目に関する評価結果を定量的に求め、この評価結果を正規化して得られた各評価項目の評価値を、時間の関数として３次元的に表示するシステムが開示されている。

特願２００５−２２３３１３号公報 特開２００９−６９８８２号公報 特開平７−１３２８３０号公報

特許文献１に記載の技術は、振替輸送を対象としており、乗客の振替輸送に伴う所要時間の増大などの要因は考慮されていない。特許文献２に記載の技術は、高速道路の利用者を対象としているため、基本的にある地点からある地点への移動経路は一種類であり、車両の平均的な所要時間に対する遅延時間に伴う損害が考慮されているが、代替の経路について考慮されていない。特許文献３に記載の技術は、列車の運行ダイヤと遅延情報などから乗客への影響度を計算する方法であり、乗客の移動行動について考慮されていない。

開示する料金払戻しシステムは、交通機関を利用する乗客の移動ログを収集し、収集した移動ログの中の、交通機関の通常時の移動ログに基づいて乗客の標準移動パターンを生成する標準移動パターン生成部、交通機関の輸送障害の発生に伴う障害影響エリア及び障害影響時間帯に関する情報を取得する輸送障害情報取得部、収集した移動ログの中に、輸送障害エリア及び障害影響時間帯の乗客の移動ログである影響移動ログの有無を判定する影響有無判定部、影響有無判定部により、影響移動ログが有と判定された場合、標準移動パターンと影響移動ログとの差に基づいて、輸送障害に伴う乗客の損失度を算出する損失度算出部、及び、算出した損失度に対応した、交通機関の輸送障害の発生に伴う払戻し料金を払戻す払戻部を有する。

本発明によれば、乗客の影響移動ログと標準移動パターンと比較した損失度により、時間、コスト、その他を払戻し料金に反映させることができる。

乗客が輸送障害により移動行動を変える様子を示す概略図である。 料金払戻しシステムの構成図である。 輸送障害により影響を受けた乗客の損失度を交通機関利用データから算出する流れを説明する図である。 ＩＣカードデータを示す図である。 位置データを示す図である。 駅・路線・経路の基本情報であるマスタデータを示す図である。 区間と経路の関係を説明する概略図である。 エリア定義リストを示す図である。 移動ログデータを示す図である。 移動ログを生成する処理手順を示す図である。 移動ログを生成する他の処理手順を示す図である。 標準移動パターンデータを示す図である。 標準移動パターンを抽出する処理手順を示す図である。 輸送障害情報をテーブル示す図である。 損失度計算結果テーブルを示す図である。 輸送障害により影響を受けた乗客を抽出する処理手順を示す図である。 輸送障害により影響を受けた乗客の損失度を計算する処理手順を示す図である。 補償料金表を示す図である。 払戻し料金を算出する処理手順を示す図である。 払戻し料金案内システムのログイン画面の例を示す図である。 払戻し処理を行う処理手順を示す図である。 払戻し料金の算出理由を説明する画面の例を示した図である。 払戻し料金の算出理由を説明する他の画面の例を示した図である。 複数の事故事例の損失度分布を比較する画面の例を示した図である。 事故事例の損失度の変化を区間毎に可視化した画面の例を示した図である。

図面を用いて、輸送障害により影響を受けた乗客（又は、利用者と呼ぶ）および損失度合を定量的に算出し、影響を受けた大きさに応じて払戻し料金を算出する料金払戻しシステムの例を説明する。

図１は、乗客が輸送障害（以下、単に障害と呼ぶことがある。）により移動行動を変える様子を示す概略図である。駅Ａ（０１）、駅Ｂ（０２）、駅Ｃ（０３）、駅Ｄ（０４）、駅Ｅ（０５）、駅Ｆ（０６）、駅Ｇ（０７）と、路線１（１１）、路線２（１２）、路線３（１３）、路線４（１４）が図１のように配置され、駅Ａ（０１）と駅Ｅ（０５）、駅Ｂ（０２）と駅Ｆ（０６）、駅Ｄ（０４）と駅Ｇ（０７）は、それぞれ徒歩で乗継可能な駅同士であるとする。ここでは説明を簡略化するため、鉄道網を例に挙げて説明するが、本実施形態の対象は鉄道に限らず、バスも含めた公共交通全体である。

駅Ａ（０１）から駅Ｂ（０２）までの通常時の標準的な移動の仕方（標準経路）として、駅Ａ（０１）から路線１（１１）で駅Ｃ（０３）に行き、路線４（１４）に乗り換えて駅Ｂ（０２）に向かう経路Ｓ（２１）が使われているとする。ここで、路線１（１１）においてＡ駅（０１）とＣ駅（０３）の間が障害により一時的に不通になった場合に、Ａ駅付近からＢ駅付近まで移動したい乗客にとって二つの選択肢が存在することになる。

一つは路線１（１１）の運行が再開されるまでＡ駅付近で待機し、標準経路と同じ経路Ａ（２２）を利用する方法である。この場合、事故などの障害による影響で通常時より所要時間が長くかかることが予想される。

もう一つはＥ駅（０５）から路線３（１３）でＤ駅（０４）に行き、Ｇ駅（０７）から路線２（１２）に乗り換えてＦ駅（０６）に向かう他の経路Ｂ（２３）を利用する方法である。このような経路を一般的に迂回経路と呼ぶが、通常時にはあまり使われていない迂回経路は所要時間や運賃などの面で不利益を被ることが多い。いずれのケースにおいても輸送障害が発生すると、乗客は通常時の移動と比べて、なんらかの損失を受けるであろうことが予想される。

図２は、輸送障害により影響を受けた乗客を判別し、それぞれの損失度に応じて補償額を算出し、乗客に対して払戻し処理を行う料金払戻しシステムの構成図である。近年、交通機関を利用する多くの利用者（１０１）は、非接触型ＩＣカードや、あるいは非接触型ＩＣカードと同等の機能を持つ携帯端末（１０３）を用いて、交通機関利用のための改札機や車内に設置された読み取り端末（１０２）を通過する。それらの改札機や車内端末で取得されたデータはネットワーク（１０５）を介して、それぞれの交通事業者が管理するサーバ群（１０６）へ送信される。

また、近年、急速に普及している高機能携帯端末などには一般的にＧＰＳなどによって位置情報を取得、送信できる機能が備えられており、利用者（１０４）の許諾の下で、そのような位置情報を交通事業者がネットワーク（１０５）を介してサーバ群（１０６）で収集することが可能である。実際、利用者の位置情報をもとに交通経路の案内を行うアプリケーションなども広く利用されている。さらに近年では駅構内や駅周辺などに監視カメラ（１０８）が設置されていることも多く、そのようなカメラによって撮影、録画された画像データからユーザを特定し、位置情報を推定、蓄積することも可能である。

輸送障害に伴う損失度を算出し、損失に応じた料金を払戻す料金払戻システム（１０７）は、データサーバ（１１１）、計算サーバ（１１２）、および情報配信サーバ（１１３）を含み、非接触型ＩＣカードあるいは同等の機能を備えている携帯端末（１０３）の利用データや利用者の位置情報、監視カメラ映像やモニタ調査から推定・集計した移動データを蓄積し、解析処理を行うものである。なお、本実施形態を説明する際に直接関係しない非接触ＩＣカード、改札機、監視カメラなどの機能や構成、画像処理技術については説明を省略する。

非接触型ＩＣカードや、非接触型ＩＣカードと同等の機能を持つ携帯端末（１０３）を所持した利用者（１０１）が改札機（１０２）を通過すると、非接触型ＩＣカードや、非接触型ＩＣカードと同等の機能を持つ携帯端末（１０３）を識別するユーザＩＤと、通過日時などを含む位置情報が改札機（１０２）内に蓄積され、元データとして交通事業者の管理するサーバ（１０６）に蓄積される。非接触型ＩＣカードや、非接触型ＩＣカードと同等の機能を持つ携帯端末（１０３）を、以下単にＩＣカード（１０３）と呼ぶ。非接触型ＩＣカードは、交通系ＩＣカードとも呼ばれる。ＩＣカード（１０３）は、ユーザＩＤなどのカードを識別する情報を持ち、改札機（１０２）などにより、その情報が読み取られる。改札機（１０２）などの読み取り機は、カードを識別する情報の読み取りに対応して、読み取り時刻（改札機の通過日時）と位置情報（改札機の位置）を読み取り機（改札機）に蓄積する。

利用者（１０４）の位置情報（たとえば、携帯端末のGPS機能により認識される位置情報）や監視カメラ（１０８）の映像データも同様である。それらのデータは蓄積と同時、もしくは一時間おきや一日おきなど適当なタイミングで必要な部分に関してデータサーバ（１１１）へ、ネットワーク（１０５）を介して送信される。データサーバ（１１１）と計算サーバ（１１２）、情報配信サーバ（１１３）のサーバ群による料金払戻しシステム（１０７）は、ネットワーク１０５に接続し、交通事業者、利用者（１１５、１１７）と通信することができる。なお、本実施形態では、データサーバ（１１１）、計算サーバ（１１２）、情報配信サーバ（１１３）のサーバ群として説明するが、１又は複数のサーバでこれらサーバ群の機能を実行できるように構成することも可能である。

データサーバ（１１１）は、改札機などＩＣカードリーダ端末（読み取り機）が読み取る利用者のデータや、携帯端末のＧＰＳ機能、監視カメラの映像などにより推定した位置データを、ネットワーク（１０５）を介して受信し、データ格納部（１２１）に記録する。収集、格納するデータには、ＩＣカードデータ（１２２）と、携帯端末のＧＰＳ機能、監視カメラの映像などにより推定した交通手段利用時の位置データ（１２３）、駅・バス停や路線に関連する基本的なマスタデータ（１２４）などが含まれている。さらにＩＣカードデータ（１２２）と、携帯端末のＧＰＳ機能、監視カメラの映像などにより推定した交通手段利用時の位置データ（１２３）などを一次加工した移動ログデータ（１２５）や、移動ログデータ（１２５）を集計・分析して生成される通常時の標準移動パターンデータ（１２６）、輸送障害により影響を受けた乗客の損失度データ（１２７）などが格納される。

駅や路線に関連する基本的なマスタデータ（１２４）については、変更があった場合や更新された場合には適宜、システムの外部から入力されて更新・記録される。これらのＩＣカードデータ（１２２）や携帯端末のＧＰＳ機能、監視カメラの映像などにより推定した交通手段利用時の位置データ（１２３）には利用者の位置情報が含まれるが、個人を特定できないように暗号化や匿名化を行うなど、プライバシーには十分配慮を行って格納する。

計算サーバ（１１２）では、データサーバ（１１１）に蓄積されたデータから移動ログを生成する処理、通常時の標準移動パターンデータを生成する処理、輸送障害により影響を受けた乗客の抽出および損失度を計算する処理などを行う。計算サーバ（１１２）は主にネットワークインタフェース（Ｉ／Ｆ（Ａ））（１３０）、ＣＰＵ（１３１）、メモリ（１３２）、記憶部（１３３）を有する。ネットワークインタフェースは、ネットワークに接続するためのインタフェースである。記憶部（１３３）には、移動ログ生成プログラム（１３４）、通常時の標準移動パターン計算プログラム（１３５）、障害の影響判別プログラム（１３６）、障害時の損失度算出プログラム（１３７）、補償金額計算プログラム（１３８）などのプログラム群と、計算処理の結果、得られた統計値や指標値などを格納するデータ格納部（１３９）が含まれている。記憶部は、例えばハードディスクドライブやＣＤ−ＲＯＭドライブ、フラッシュメモリなどである。なお、複数の記録装置に各種プログラム、各種データを分割して記録するようにしてもよい。

各プログラム群が実行される際は、分析対象となるデータをデータサーバ（１１１）から読み出してメモリ（１３２）へ一時的に格納し、ＣＰＵ（１３１）で各プログラム（１３４、１３５、１３６、１３７、１３８）をメモリに読み出して実行することにより各種機能を実現する。これらのプログラムの実行のタイミングは、例えば交通事業者（１１９）や乗客（１１５、１１７）のリクエストのタイミングやデータサーバ（１１１）に新規データが追加される度に行ってもよいし、またはバッチ処理として、毎日決められた時間に自動的に処理を行ってよい。

情報配信サーバ（１１３）は、ネットワークインタフェース（Ｉ／Ｆ（Ｂ））（１４５）および（Ｉ／Ｆ（Ｃ））（１４４）とＣＰＵ（１４６）とメモリ（１４７）と記録装置（１４８）を備える。ネットワークインタフェースは、ネットワークに接続するためのインタフェースである。記録装置は、各種プログラム、各種データを記録するものであり、例えば、ハードディスクドライブやＣＤ−ＲＯＭドライブ、フラッシュメモリなどである。なお、複数の記録装置に各種プログラム、各種データを分割して記録するようにしてもよい。

情報配信サーバ（１１３）は、乗客（１１５、１１７）が携帯情報端末（１１６）や、家庭用もしくは公共の情報端末（１１８）からインターネット（１１４）を介して、利用者の照合、影響を受けた障害の払戻し料金情報の検索、検索結果を参照するためのものである。利用者（１１５、１１７）は所有しているＩＣカード（１０３）をＩＣカードリーダにかざし、インターネット（１１４）を介して情報配信サーバ（１１３）に送信し、利用者確認プログラム（１４１）に渡すことで個人を特定してもよい。記録装置（１４８）には、利用者照合プログラム（１４１）、払戻し処理プログラム（１４２）、情報配信プログラム（１４３）が含まれる。ＣＰＵ（１４６）は、記録装置（１４８）に記録されている各種プログラムをメモリに読み出して実行することにより各種機能を実行する。具体的には、利用者確認プログラム（１４１）により、データサーバ（１１１）に蓄積されているデータのユーザＩＤ（又は、カードＩＤ）と照合し、照合データに基づいて検索処理プログラムを実行することにより、その利用者が影響を受けた障害による料金の払戻し処理を実行し、損失度計算結果情報を加工して利用者に提示する。これらの情報は、基本的に各利用者が能動的にアクセスしたタイミングで取得される。

輸送障害による損失度算出および料金払戻しシステム（１０７）を所有する交通事業者（１１９）は情報端末（１２０）を用いてネットワーク（１５１）を介し、各種の蓄積データの構成や状況、計算サーバの状況や計算結果、利用者からの検索リクエスト状況などを確認することができる。また、輸送障害データの入力や払戻しのための料金表テーブルなどの更新を行うことが可能である。

図３は、輸送障害により影響を受けた乗客の損失度を交通機関利用データから算出する処理の流れの概略図である。本実施形態の料金払戻しシステムは、乗客の交通行動情報を含む移動ログデータ（１２５）を用いて、通常時の標準経路情報（１２６）を基準値として、輸送障害時に利用した経路と比較することにより、輸送障害時に移動していた乗客が障害の影響を受けたかどうかを判定する（１６３）とともに障害による損失度、すなわち払戻し金額（１６４）を計算する。通常時の標準経路の計算および輸送障害の影響を受けた乗客を抽出するためには、いつどこで輸送障害が発生したかを表す輸送障害情報データ（１６１）が必要となる。輸送障害データ（１６１）には障害発生エリアおよび障害により運休が乱れた時間帯に関する情報（１６２）が含まれており、これらの情報を用いて運行が平常どおり行われていたエリアおよび時間帯を抽出し、移動ログを用いて通常時の標準経路情報（１２６）を生成する。

図３に示す処理を実行する処理部という観点から説明すると次のようになる。料金払戻しシステムは、交通機関を利用する乗客の移動ログを収集し、収集した移動ログの中の、交通機関の通常時の移動ログに基づいて乗客の標準移動パターンを生成する標準移動パターン生成部がある。標準移動パターン生成部は、乗客のＩＣカードデータを収集し、収集したＩＣカードデータから移動ログを生成する処理を含む。料金払戻しシステムは、さらに、交通機関の輸送障害の発生に伴う障害影響エリア及び障害影響時間帯に関する情報を取得する輸送障害情報取得部、収集した移動ログの中に、輸送障害エリア及び記障害影響時間帯の乗客の移動ログである影響移動ログの有無を判定する影響有無判定部、影響有無判定部により、影響移動ログが有と判定された場合、標準移動パターンと影響移動ログとの差に基づいて、輸送障害に伴う乗客の損失度を算出する損失度算出部、算出した損失度に対応した、交通機関の輸送障害の発生に伴う払戻し料金を払戻す払戻部を有する。ここで、影響移動ログとは、交通機関の輸送障害の発生に伴う障害影響エリアの中に、障害影響時間帯に存在した乗客の移動ログである。

図４は、データサーバ（１１１）内に格納される代表的なデータであるＩＣカードデータ（１２２）の構造について示した図である。まず、ＩＣカードデータ（１２２）はログＩＤ（２４１）、対象となるユーザＩＤ（２４２）、どのデータ読み取り端末を通過したかの情報から紐づけられる駅およびバス停のＩＤ（２４３）、その読み取り端末を通過した利用時刻（２４４）と、入場か出場かなどの利用種別（２４５）などの情報を含む。ここで利用種別とは、例えば改札機や入出場ゲートとなら「入場」や「出場」、物販用端末などであれば「購買」などの処理の種別を示す情報である。ＩＣカードデータ（１２２）は、新規にデータが生成される度に送信されてきてもよいし、または利用が少なくなる深夜に一括して送られてきてもよい。データサーバ（１１１）側では、その送信のタイミングに合わせて格納処理を行えばよい。
図５は、データサーバ（１１１）内に格納される代表的な位置データを示した図である。交通手段利用時の位置データ（１２３）はログＩＤ（２５１）、対象となるユーザＩＤ（２５２）、どの地点を通過したかの情報から紐づけられる緯度情報（２５３）と経度情報（２５４）、その地点を通過した通過時刻（２５５）などの情報を含む。ここでユーザＩＤとはＩＣカードのカードＩＤや携帯情報端末の機器ＩＤや、位置情報取得アプリケーションの会員ＩＤなどの利用者に紐づけられた情報である。交通手段利用時の位置データ（１２３）は例えば、電車や自動車、バスなどに乗っているときに手動もしくは、一定間隔のタイミングで自動的に取得・送信された緯度経度情報が蓄積されるようなデータである。一方、駅構内や駅周辺に設置された監視カメラの映像に、顔認識技術や人物追跡技術などを適用することで、あらかじめ顔画像などを登録してある利用者については、ある時刻にある場所にいたという事実を示す位置データへ変換することが可能である。すなわち、乗客の映像データから乗客を特定する情報（ユーザＩＤ）へ変換すると共に、乗客の映像データを取得した位置情報を対応付ける。

交通手段利用時の位置データ（１２３）は、新規にデータが生成される度に送信されてきてもよいし、または利用が少なくなる時間帯に一括して送られてきてもよい。データサーバ（１１１）側では、その送信のタイミングに合わせて格納処理を行えばよい。

図６は、データサーバ（１１１）内に格納されるマスタデータ（１２４）の種類とそれぞれのデータ構造について示した図である。まず、駅やバス停、道路など交通手段を利用できる場所に関する基本データである位置マスタ（３００）は、駅・バス停ＩＤ（３０１）、駅・バス停名（３０２）、所有会社（３０３）、住所などの所在地（３０４）、緯度経度の情報（３０５）などの情報を含む。駅、バス停や路線、道路の構成に変更があった場合には、随時データの追加や修正が行われる。

路線に関する基本データである路線マスタ（３１０）は、路線を識別する路線ＩＤ（３１１）、路線名（３１２）、運営会社（３１３）、鉄道路線かバス路線かを区別するような路線タイプ（３１４）などの情報を含む。

駅および路線を紐付けるための基本データである駅・バス停―路線関係マスタ（３２０）は路線を識別する路線ＩＤ（３２１）と、その路線に含まれる駅・バス停ＩＤ（３２２）と駅・バス停の順序を管理する順序番号（３２３）と、停車するか通過するかを識別する種別（３２４）と始点からの所要時間（３２５）などの情報が含まれる。始点は路線ごとに定められた起点であり、その路線の始発の駅やバス停である。

さらに経路に関する基本データである経路マスタ（３３０）は経路を識別する経路ＩＤ（３３１）と乗車駅・バス停ＩＤ（３３２）、降車駅・バス停ＩＤ（３３３）に加えて乗車する路線数分の路線ＩＤ（３３４、３３６、・・・）と乗換駅・バス停ＩＤ（３３５、・・・）の情報などを含む。乗車駅・バス停ＩＤ（３３２）から降車駅・バス停ＩＤ（３３３）に向かう時に１回だけ交通機関を利用する場合はどの路線に乗るかを識別する路線ＩＤ１（３３４）にデータが格納される。また、乗車駅・バス停ＩＤ（３３２）から降車駅・バス停ＩＤ（３３３）に向かう時に複数の交通機関を利用する場合は、どの路線に乗るかを識別する路線ＩＤ１（３３４）と乗換地点を識別する乗換駅・バス停ＩＤ１（３３５）、次に乗る路線を示す路線ＩＤ２（３３６）・・というように乗車路線数（３４１）の値に応じて順次、データが格納される。また、この経路の総合的な情報を示す乗車路線数（３４１）と標準所要時間（３４２）、料金（３４３）などの情報も含まれる。ここで乗車駅・バス停ＩＤ（３３２）と降車駅・バス停ＩＤ（３３３）の組み合わせに対応する経路が複数、存在する場合もあるが、ここでは一般的に最も利用頻度の高い経路を第一経路として割り当てることとする。乗車駅・バス停ＩＤ（３３２）と降車駅・バス停ＩＤ（３３３）の組み合わせに対応する経路を複数持たせる場合には、経路毎に利用率をもたせればよい。マスタデータ（１２４）は、例えば駅やバス停、路線や道路に変更があった場合に、その変更の度に図２に示すシステムの外部から入力および更新・記録される。

図７は、鉄道網およびバス路線網における駅、バス停、路線および区間と経路の関係を概略的に示したものである。一般的に鉄道網やバス路線網においては、複数の鉄道会社やバス会社の駅、バス停が近接している、いわゆる乗換駅というものが多数、存在する。例えば、駅１（７０１）の近くにバス停１（７０２）が、駅２（７０３）と駅４（７０４）とバス停３（７０５）が、駅３（７０７）とバス停２（７０６）が徒歩圏内にそれぞれ、隣接して存在しているとする。また、駅１（７０１）からは、鉄道路線１（７１１）を使って駅２（７０３）に行ける経路１と、バス路線１（７１３）を使ってバス停２（７０６）へ行き、駅３（７０７）で乗り換えて鉄道路線２（７１２）を使って駅４（７０４）へ到着する経路２が存在するとし、さらにバス停１（７０２）からはバス路線２（７１４）を使ってバス停３へ到着する経路３があるとする。ここで交通機関の利用者が駅１の付近から駅２の付近へ移動したい時、出発地エリアＡには駅１（７０１）とバス停１（７０２）の選択肢が、目的地エリアＢには駅２（７０３）、駅４（７０４）、バス停３（７０５）の選択肢が、そして、その間には経路１から経路３の３つの選択肢が存在することになる。ここでは、ある出発地エリアと目的地エリアを結ぶ線を区間とし、その間を移動できるルートを経路と定義する。駅やバス停単位ではなく、エリアとして扱うことで初めて、複数の経路を比較対象として扱うことが可能になる。

図８は、図７で説明した乗換可能な地点群を同じエリアとみなすためのエリア定義データを格納するデータ構造について示した図である。エリア定義リスト（８００）には、レコードを識別するエリアＩＤ（８０１）、そのエリアの中に含まれる代表駅・バス停ＩＤ（８０２）、この定義が有効である対象期間（８０３）、そのエリア内に含まれる駅やバス停の数（８０４）、エリア内に含まれる駅・バス停ＩＤ１（８０５）、駅・バス停ＩＤ２（８０６）、駅・バス停ＩＤ３（８０７）、駅・バス停ＩＤ４（８０８）などの情報が含まれる。駅やバス停、路線や道路など交通網は時代とともに変化していくため、交通網の変更に伴い、新しい定義を行うことが必要である。しかし、交通系データを分析する際には、そのデータの日付に対応しているエリア定義情報を読み出す必要がある。そのために定義の有効期間（８０３）を定めておくことが重要になる。どの駅・バス停がどのエリアに含まれるかといった情報は、駅・バス停マスタデータ（３００）の緯度経度情報と、距離に関する閾値をもとに自動的に作成してもよいし、交通事業者などが経験をもとに手動で設定してもよい。また、交通事業者毎に独自の定義を行ってもよい。

図９は、データサーバ（１１１）内に格納される移動ログデータ（１２５）を格納するためのデータ構造について示した図である。移動ログデータ（１２５）はログを識別するログＩＤ（３６１）と対象となるユーザＩＤ（３６２）、出発地点において交通手段の利用を開始した時刻を示す乗車日時（３６３）、到着地点において交通手段の利用を終了した時刻を示す降車日時（３６４）、出発地エリアＩＤ（３６５）、到着地エリアＩＤ（３６６）、移動にかかった料金を示す支払額（３６７）、経路ＩＤ１（３６８）、乗車駅・バス停ＩＤ１（３７１）、降車駅・バス停ＩＤ１（３７２）、経路ＩＤ２（３７３）、乗車駅・バス停ＩＤ２（３７４）、降車駅・バス停ＩＤ２（３７５）、経路ＩＤ３（３７６）などの情報が含まれる。この移動ログデータ（１２５）はＩＣカードデータ（１２２）、交通手段利用時の位置データ（１２３）を用いて生成される一次加工後のデータである。

図１０は、ＩＣカードデータ（１２２）から移動ログデータ（１２５）を生成し、データサーバ（１１１）に格納する手順（移動ログ生成処理）を説明する図である。ここではデータサーバ（１１１）への格納処理は毎日、決められた時刻に１回、バッチ処理で行うものとして、説明する。まず、新しく収集されたＩＣカードデータ（１２２）に含まれるユーザＩＤ（２４２）と利用時刻（２４４）を参照して全データをユーザＩＤ順および時刻順に並び替える（処理ステップ４００）。次に処理ステップ４００で並び替えたデータに対してユーザＩＤの数に応じて、以下の同じ処理を繰り返す（処理ステップ４０１）。

まず、乗車駅・バス停ＩＤ、乗車日時、降車駅・バス停ＩＤ、降車日時に対応するリスト型変数を初期化する（処理ステップ４０２）。次に時刻順に並んだデータに対して以下の同じ処理を繰り返す（処理ステップ４０３）。まず、利用種別（２４５）の値によって場合分けを行い、それぞれの処理を行う。利用種別（２４５）の値が入場である場合（処理ステップ４０４）には、まず、同じユーザかつ同一日のログの中で一つ前の出場ログを参照し（処理ステップ４０５）、その降車日時と、現ログの乗車日時の差があらかじめ定義されている閾値以内であるかどうかの判定を行う。この閾値は複数の交通機関の乗り継ぎを判定するための値であり、例えば数分から数十分の範囲で設けるのが望ましい。一つ前の出場ログの降車日時と、現ログの乗車日時の差が閾値以内であれば（処理ステップ４０６）、一連の移動が続いているとみなし、乗車駅・バス停ＩＤおよび乗車日時のリストに値を追加する（処理ステップ４０７）。閾値を超えた場合は、一つ前の移動から時間が十分空いているので、一つ前の移動情報はここで区切るべきと判定する。よって乗車駅・バス停ＩＤ、乗車日時、降車駅・バス停ＩＤ、降車日時の変数の値を参照し、経路マスタ（３３０）を用いて乗車駅・バス停ＩＤと降車駅・バス停ＩＤの組み合わせに一致した経路ＩＤを検索し、移動ログデータ（１２５）に格納する（処理ステップ４０８）。該当する一つ前の出場ログが存在しない場合は、上記の判定処理は省略し、乗車駅・バス停ＩＤおよび乗車日時のリストに値を追加する（処理ステップ４０９）。

利用種別（２４５）の値が出場である場合（処理ステップ４１０）は、降車駅・バス停ＩＤおよび降車日時の変数に値を追加する（処理ステップ４１１）。ここで、ログＩＤ（３６１）は通し番号として保持しておく。ここで一連の移動かどうかを判定するための閾値tは標準的な乗換時間として、あらかじめ設定しておくものとする。この閾値tにより、乗換え時間の許容範囲を調整することができる。標準的な乗換時間に関する閾値tは正の値であり、交通網全てに共通の値としてもよいし、エリア毎に異なる値を設けてもよい。

図１１は交通手段利用時の位置データ（１２３）から移動ログデータ（１２５）を生成し、データサーバ（１１１）に格納する手順を説明する図である。ここではデータサーバ（１１１）への格納処理は毎日、決められた時刻に１回、バッチ処理で行うものとして、説明する。まず、新しく収集された交通手段利用時の位置データ（１２３）に含まれるユーザＩＤ（２５２）と通過時刻（２５５）を参照して全データをユーザＩＤ順および時刻順に並び替える（処理ステップ５００）。次に処理ステップ５００で並び替えたデータに対してユーザＩＤの数に応じて、以下の同じ処理を繰り返す（処理ステップ５０１）。まず、駅・バス停ＩＤと通過時刻の連続データを格納するために通過駅・バス停ＩＤ、通過日時に対応するリスト型変数を初期化する（処理ステップ５０２）。次に時刻順に並んだデータに対して以下の同じ処理を繰り返す（処理ステップ５０３）。交通手段利用時の位置データ（１２３）に含まれる緯度情報（２５３）、経度情報（２５４）、通過時刻（２５５）を参照し、駅・バス停マスタ（３００）を用いて、距離情報をもとに駅またはバス停付近を通過したとみなせるログを抽出し、通過駅・バス停ＩＤと通過日時にそれぞれ値を追加する（処理ステップ５０４）。通過駅・バス停ＩＤと通過時刻の配列にデータが入っており、通過時刻の配列の最後のデータの値と、ログの通過時刻の差が閾値t以上である場合(処理ステップ５０５)には、連続した移動ではないとみなすことができる。さらに通過駅・バス停ＩＤのリストの順番をたどることにより、どのような経路で移動したのかが分かるため、その経路に一致する経路ＩＤや料金を経路マスタから抽出し(処理ステップ５０６)、移動ログデータ（１２５）に格納する。通過駅・バス停ＩＤと通過時刻の配列にデータが入っており、通過時刻の配列の最後のデータの値とログの通過時刻の差が閾値t未満である場合(処理ステップ５０７)には、連続した移動の最中であるので、通過駅・バス停ＩＤおよび通過時刻の変数に値を追加する（処理ステップ５０８）。ここで、移動ログデータ（１２６）のログＩＤ（３６１）は通し番号として保持しておく。ここでtの値は複数の移動の間の時間的な切れ目を表す値であり、あらかじめ設定しておくものとする。tの値により、移動の連続性の度合いを調整することができる。閾値tは正の値であり、交通手段や位置によらず共通の値としてもよいし、異なる値を設けてもよい。また、移動の区切りを判別するために、利用者がそれぞれ出発地や目的地を通過した際に、携帯端末上で明示的になにかしらの情報を入力してもらってもよい。

図１２は移動ログから通常時の標準移動パターンを算出し、格納するためのデータ構造を示した図である。通常時の標準移動パターンデータ（１２６）には、ユーザＩＤ（２６１）、区間を識別する区間ＩＤ（２６２）、出発地を示す出発地エリアＩＤ（２６３）、到着地を示す到着地エリアＩＤ（２６４）、集計対象となった対象期間（２６５）、集計対象となった時間帯（２６６）、この区間を移動した合計利用回数（２６７）、この区間を移動したパターン、すなわち経路数（２６８）、一つめの経路ＩＤ（２７１）、一つめの経路の利用率（２７２）、一つめの経路の平均移動時間（２７３）、一つめの経路の運賃（２７４）、一つめの経路の乗換回数（２８１）、一つめの経路の列車平均待ち時間（２８２）、二つめの経路ＩＤ（２９１）、二つめの経路の利用率（２９２）などの情報が含まれる。各経路の特性情報は平均移動時間、運賃、乗換回数、列車平均待ち時間に限ったものではなく、できる限り収集することが望ましい。

図１３は移動ログから各乗客の移動パターンを抽出し、通常時の標準移動パターンデータテーブル（１２６）に格納するための処理手順を示した図である。まず、移動ログデータ（１２５）から、あらかじめ設定された対象期間および時間帯に該当するログを抽出し（処理ステップ１０００）、ユーザＩＤ（３６２）および出発地エリア（３６５）および到着地エリア（３６６）の組み合わせである区間毎にソートする（処理ステップ１００１）。標準移動経路の集計結果を格納するために、経路ＩＤと利用件数についてリスト型変数を用意し、初期化する（処理ステップ１００２）。ここで対象期間や時間帯の値についてはあらかじめ外部で設定されているものとし、設定された全てのデータ対象期間および時間帯の組み合わせ分に応じて同じ処理を行うことになるが、ここでは一つのデータ対象期間および時間帯が決まった場合の処理の例を示す。抽出した移動ログの全レコードに対してユーザＩＤおよび区間毎に以下の処理を繰り返す（処理ステップ１００３）。ここで対象期間内に対象区間を移動した回数が十分多いユーザについては、ユーザ毎に集計処理を行ない、集計結果にユーザＩＤ情報を付けた状態で通常時の標準パターンデータテーブルに格納すればよい。しかし、対象期間内には、ほとんど交通機関を利用せず、障害発生時に偶然、交通機関を利用し、輸送障害の影響を受けてしまうような乗客が存在するであろうことを想定すると、全ユーザの移動ログを対象とした通常時の移動パターンデータをあらかじめ、作成しておくことがのぞましい。比較対象となる通常時の移動パターンデータが存在しない場合には、輸送障害の影響を受けた乗客を正しく抽出することが困難になるためである。この全ユーザを対象とした標準移動パターンデータの作成については、集計結果には実在のユーザＩＤではなく、全ユーザを対象としていることがわかるような特定のユーザＩＤを割りあてるか、ユーザＩＤデータを空にした状態で、通常時の標準パターンデータテーブルに格納する。次にユーザＩＤおよび区間毎に抽出・ソートした移動ログについて、順々に経路情報（３６８、３７３、３７６など）を参照し(処理ステップ１００４)、経路毎に利用回数を集計する（処理ステップ１００５）。集計後、各経路毎に平均移動時間、平均待ち時間、乗換回数、運賃などの情報を算出またはマスタデータの検索により、生成する（処理ステップ１００６）。ここで平均移動時間や平均待ち時間（乗換場所での待ち時間）は各移動ログに含まれる乗車日時および降車日時のデータを用いればよい。乗換回数や運賃などは移動ログを参照してもよいし、経路マスタデータ（３３０）を検索してもよい。ＩＣカードデータ以外にも駅構内に設置されている監視カメラ映像や、列車毎に取り付けられている応荷重データなどを使うことができれば、駅構内や車両内の混雑率を計算することができるため、混雑による移動経路毎の不効用値などを算出することが可能になる。このようにして、経路毎の特徴量を求めた後、経路毎の利用件数に関する集計結果をもとに、各経路の利用率（各経路の利用件数÷対象区間の合計利用件数×１００）を計算し、利用率が大きい順に経路情報をソートする（処理ステップ１００７）。最後にソート済みのデータを通常時の標準移動パターンデータテーブルに格納し（処理ステップ１００８）、変数を初期化後、次の区間の集計処理を行う（処理ステップ１００９）。ここではある対象区間内に利用した回数の多い経路を通常時の標準経路と定義したが定期保有者については定期区間情報を取り入れてもよい。またできる限り正確に通常時の標準移動パターンを計算するためには、輸送障害がいつどこで発生したかという情報を参照し、輸送が安定していた場所・時間帯のデータを用いることが望ましい。

図１４は鉄道事業者などによって入力される輸送障害の情報を格納するためのデータ構造を示した図である。輸送障害データテーブル（１１００）は事故（障害）ＩＤ（１１０１）、日付（１１０２）、発生時刻（１１０３）、事故（障害）が発生した路線（１１０４）、駅や駅間など事故（障害）が発生した場所（１１０５）、運転再開時刻（１１０６）、事故（障害）の原因・対応（１１０７）などの情報を含む。輸送障害情報は、鉄道会社の担当者がＰＣ端末などから入力してもよいし、運行管理システムなどに蓄積されている実績ダイヤ情報を用いて運休情報や遅延状況を機械的に抽出し、格納してもよい。

図１５は輸送障害により影響を受けた乗客の移動データを分析して求めた損失度を格納するためのデータ構造を示した図である。損失度計算結果データテーブル（１２７）は、事故ＩＤ（９０１）、ユーザＩＤ（９０２）、損失度（９０３）、払戻し処理に関するフラグ（９０４）、因子１（９０５）、因子２（９０６）、因子３（９０７）などの情報を含む。払戻し処理に関するフラグは、その処理が完遂しているか否かを示す二値の情報である。また、ここでは説明を簡略化するため、因子１を移動時間、因子２を運賃、因子３を乗換回数として以下の説明を行うが、因子の順番および因子数も３つに限定するものではなく、多ければ多いほど多角的に損失度を計算することが可能になる。

図１６は移動ログから輸送障害時の各乗客の移動パターンを抽出し、通常時の標準移動パターンデータと比較することで影響を受けたかどうかを判定し、その結果を損失度計算結果データテーブル（１２７）に格納するための処理手順を示した図である。まず、システム運用者などによって指定された事故ＩＤを取得し（処理ステップ１２００）、輸送障害情報データテーブル（１１００）から事故ＩＤをもとに事故（障害）の日付（１１０２）、発生時刻（１１０３）、事故（障害）発生路線（１１０４）、事故（障害）発生場所（１１０５）、運転再開時刻（１１０６）などの事故（障害）情報を検索する（処理ステップ１２０１）。移動ログデータテーブル（１２５）より、「乗車日時＜運転再開時刻+t1」かつ、「降車日時＞事故（障害）発生時刻 + t2」の条件を満たすログを全て抽出し（処理ステップ１２０２）、各ログに対して以下の処理を繰り返す（処理ステップ１２０３）。なお、t1は、事故（障害）発生からその影響が残っている時間、t2は、事故（障害）発生からその影響が顕在化するまでの時間である。上記の条件を設定することにより、明らかに事故とは関係のない時間帯で影響を受けた乗客について、あらかじめ損失度計算対象から外すことが可能になる。まず移動ログのユーザＩＤ（３６２）、出発地エリアＩＤ（３６５）、到着地エリアＩＤ（３６６）の情報から、通常時の標準移動パターンデータテーブル（１２６）を検索し、該当するレコードを抽出する（処理ステップ１２０４）。この時、該当するユーザＩＤのレコードがない場合には、通常時の標準移動パターンデータテーブルに格納されている全ユーザを対象として集計した標準移動パターンのレコードを取り出す。抽出したレコードの第一経路（２７２）が事故時の移動ログの経路情報（３６８、３７３、・・・）と照合して、一致している場合（処理ステップ１２０５）は、事故時の移動ログの所要時間（降車日時−乗車日時）と、標準移動パターンの平均移動時間（２７３）とを比較し、移動時間の差が閾値以上の場合（処理ステップ１２０６）は、ユーザＩＤおよび移動時間の差（事故時の移動ログと標準移動パターン情報との差）を求め、損失度計算結果データテーブル（１２７）に格納する（処理ステップ１２０７）。この閾値は交通事業者などが独自に設定するものとし、事故毎、事故発生路線毎に調整するなどしてもよい。一方、通常時の標準移動パターンデータ（１２６）から抽出したレコードの第一経路（２７２）が事故時の移動ログの経路情報（３６８、３７３、・・・）と照合して、一致していない場合（処理ステップ１２０８）は、通常時の標準移動パターンの各因子（移動時間、運賃、乗換回数など経路の特性）の値と、事故時の移動ログデータの各因子の値から、それぞれ差を求め、いずれかの因子について差が閾値以上であったレコードについて損失度計算結果データテーブル（１２７）に格納する（処理ステップ１２０９）。処理ステップ１２０７と同様に、閾値は交通事業者などが独自に設定するものとし、事故毎、事故発生路線毎に調整するなどしてもよい。また、どれか一つの因子について閾値のルールを適用してもよいし、複数の因子を組み合わせて、事故の影響を受けたと判定するルールを作ってもよい。通常時の標準移動パターンと事故時の移動ログの各因子の差を求めることで、この乗客が分析対象とする事故により、どのくらいの影響を受けたかを定量的に求めることができるようになる。計算対象とする因子は、これに限定したものではなく、例えば徒歩での移動距離や駅構内および列車内での混雑度など、定量的に求められるものは全て対象としてよい。因子が多ければ多いほど、各乗客が事故により受けた影響を多角的に分析可能となるため、精度や質をより向上させることができる。

図１７は、図１６に示す処理によって事故の影響を受けたと判断された乗客に対し、事故によって受けた損失度を求め、その結果を損失度計算結果データテーブル（１２７）に格納するための処理手順を示した図である。この処理は、図１６に示す処理が行われる度に続けて自動的に実行されるようにしてもよいし、損失度の計算方式の入れ替えなどに伴い、システム運用者の判断によって明示的に実行されてもよい。まず、システム運用者などによって指定された事故ＩＤを取得し（処理ステップ１３００）、損失度計算結果データテーブル（１２７）より、指定の事故ＩＤを含む全レコードを抽出する（処理ステップ１３０１）。抽出したレコードについて以下の処理を繰り返す（処理ステップ１３０２）。損失度計算結果データのレコードに含まれる因子１（９０５）、因子２（９０６）、因子３（９０７）などの情報と、交通事業者によって、あらかじめ定義されてある損失度計算式

とを用いて、各乗客の損失度を計算し（処理ステップ１３０３）、計算結果を損失度計算結果データテーブル内の該当レコードに格納する（処理ステップ１３０４）。損失度計算式は各因子から損失度を計算するための変換式の一例であるが、例えば因子毎に係数を決めておき、その線形和により、総合的な損失度を求める方法などがある。また各因子の係数を求める方法として、全ユーザの移動ログを用いて同じ区間を移動する複数の経路を平均所要時間や運賃の要素で比較し、それぞれの要素の重みを計算する手法がある。これはロジットモデルと呼ばれ、乗客がどの経路をどういう理由で利用しているかを説明する手法である。

因子は、これまでの説明から明らかなように、たとえば、損失度計算結果データテーブル（１２７）に含まれる因子１（９０５）は移動時間であり、因子２（９０６）は運賃であり、因子３（９０７）は乗り換え回数である。他に因子として想定できるのは、混雑度や、徒歩による乗り換え時分などがある。すなわち、時間に換算し、その時間（Ｘｉ）に対応して係数（損失度計算式のＣｉ）を乗じた損失度を求められる因子と、運賃のように直接的に求められる（Ｃｉ＝1、Ｘｉ＝運賃）因子と、状況を考慮してＣｉ、Ｘｉを決定しなければならない因子とがある。

図１８は、乗客の損失度に応じて払戻しを行うための換金表を格納するためのデータ構造を示した図である。補償料金表（１４００）には、曜日（１４０１）、路線ＩＤ（１４０２）、損失度（１４０３）、料金（１４０４）などの情報が含まれる。この補償料金表は交通事業者毎が定期的に更新するもので、曜日や路線毎に限らず、時間帯毎や運行停止時間や事故の発生原因毎に用意されてもよい。また、損失度を払戻し金額に換算する以外にも例えばＩＣカードやクレジットカードなどのポイントなどに変換する方法などもある。

図１９は、損失度から払戻し料金を計算する処理手順を示した図である。この処理は、図１６，１７に示す処理が行われる度に続けて自動的に実行されるようにしてもよいし、補償料金表テーブル（１４００）が更新されるタイミングや各乗客への払戻し処理が行われるタイミングで実行されてもよい。まず、システム運用者が実行したプロセスまたは乗客からのリクエストなどによって指定されたユーザＩＤおよび事故ＩＤの情報を取得する（処理ステップ１５００）。次に輸送障害情報データテーブル（１１００）から指定の事故ＩＤをキーとして事故情報を取得する（処理ステップ１５０１）。さらに損失度計算結果データテーブル（１２７）より指定のユーザＩＤをキーとして、該当する乗客の損失度を取得する（処理ステップ１５０２）。最後に補償料金表データテーブル（１４００）を参照し、事故ＩＤ、事故情報、損失度データを用いて払戻し料金を取得する（処理ステップ１５０３）。

図２０は、情報配信サーバ（１１３）によって、乗客向けに生成および配信される提示画面の一例でオンライン払戻し料金案内の例を示した図である。オンライ払戻し料金案内画面（２１００）では利用者（１１５、１１７）がユーザ名（２１０１）、検索対象の事故事例（２１０２）、日付（２１０３）などを入力またはプルダウンメニューなどで選択し、ログインボタン（２１０４）を押すことにより、情報配信サーバ（１１３）にリクエストが伝達される。これらの表示条件は利用者（１１５、１１７）が設定画面やマウス・キーボードなどの入力インタフェースを用いて設定・変更することが可能であるものとする。ここでユーザ名（２１０１）は、ＩＣカードのＩＤ番号でもよいし、それらのＩＤ番号と一意に紐づけられるアカウント名などでもよい。またあらかじめ、メールアドレスなどが登録されているユーザについては、オンライン払戻し料金案内で取得できる情報と同等のものを、自動的にメール配信することも可能である。事故事例（２１０２）の各選択肢は、事故対象路線と日付、時間帯など輸送障害情報が端的に表現された文字列情報が表示され、ユーザはそのリストの中から払戻し料金情報を調べたい事故対象を手動で選ぶ。ここでユーザ名（２１０１）が入力されたタイミングで、自動的に損失度計算結果データ（１２７）を参照し、入力されたユーザＩＤが含まれるレコードを抽出することで、そのユーザに関連のある払戻し対象の事故リストを作成してもよい。事故事例（２１０２）と日付（２１０３）の選択はどちらかでよい場合が多く、利用者が検索したい事故事例を特定できた段階で入力作業を終えてよい。入力されたユーザＩＤ（２１０１）は利用者（１１５、１１７）の初回アクセス時に情報配信サーバ（１１３）の方で記憶しておき、次回以降はその入力を省くなどしてもよい。

図２１は、乗客に対して払戻し処理を行う処理手順を示した図である。この処理は、利用者（１１５，１１７）からリクエストが発生したタイミング、もしくはなんらかの輸送障害が発生し、その事故についての損失度計算処理終了後に初めて利用者（１１５，１１７）が改札機や専用のＩＣカードリーダ、ＩＣカードリーダ／ライタ機能を有する高機能携帯電話などにＩＣカードをかざしたタイミングで実行される。まずオンライン払戻し料金案内画面（２１００）で入力されたユーザ名（２１０１）の情報を取得する(処理ステップ１６００)。次にユーザ名（２１０１）から変換されたユーザＩＤをキーにして損失度計算結果データテーブル（１２７）を検索し、払戻し処理フラグ（３９４）の情報を参照して払戻し処理が終了していない事故事例を抽出する（処理ステップ１６０１）。まだ払戻し処理が終了していない事故事例があった場合に、全ての事故事例について以下の処理を繰り返す（処理ステップ１６０２）。まず損失度計算結果データテーブル（１２７）のレコードに含まれる損失度と、補償料金表テーブル（１４００）から払戻し金額を算出し（処理ステップ１６０３）、利用者（１１５，１１７）が保有するＩＣカード内の残高記録を書き換える(処理ステップ１６０４)ことにより、払戻し処理を完了する。

図２２は、情報配信サーバ（１１３）によって、乗客向けに生成および配信される提示画面の一例で払戻し料金の算出理由を説明する画面（２２００）の例を示した図である。画面（２２００）は、例えば事故情報（２２０１）、損失度分布（２２０２）、払戻し額分布（２２０３）から構成され、事故の影響を受けた乗客が、各々の損失度とそれによっていくら払い戻されることになったかを、影響を受けた全乗客の相対値により、理解するための画面である。事故情報（２２０１）は輸送障害データテーブル（１１００）に含まれる事故情報や、損失度計算結果データテーブル（１２７）から全乗客の平均損失度を求めて表示するなどの表示方法がある。また、全乗客の中での相対値を示す方法として、損失度計算結果データテーブル（１２７）から対象事故によって影響を受けた全乗客のレコードを計算し、横軸に損失度、縦軸に人数を示すヒストグラムを作成し、表示する方法がある。さらに補償料金表テーブル（１４００）から払戻し額に関する情報を取得し、同一画面に表示することで、各乗客に損失度とそれに対応する払戻し金額を分かりやすく提示することができる。これらの画面はマウスやキーボードなどの入力インタフェースを用いて操作することが可能で、例えばホイールボタンなどでズームイン／ズームアウトを行ったり、マウスクリックで損失度ヒストグラムの間隔を変更することができる。また、グラフ形式も図の棒グラフに限定するものではなく、散布図や折れ線グラフなどで表示してもよい。

図２３は、情報配信サーバ（１１３）によって、乗客向けに生成および配信される提示画面の別の一例で払戻し料金の算出理由を詳細に説明する画面（２３００）の例を示した図である。事故による損失度および払戻し料金の算出結果を説明する方法として、例えば損失度計算結果データテーブル（１２７）を参照し、因子毎に通常時の標準移動パターンとの差をレーダーチャート上などにプロットするなどの方法がある。この時、事故により影響を受けた全乗客の因子毎の差分データを抽出し、各因子の平均差分値を求めた上で、各乗客が受けた損失度と比べて相対値をプロットすることが望ましい。例えば移動時間を示す因子は全乗客の平均値と比べて差が小さい場合でも運賃を示す因子が全乗客の平均値と比べて差が大きい場合に、移動時間の面ではほとんど損をしていないが運賃面ではかなり損を受けたため、払戻し金額が高くなったなどの理由を分かりやすく理解することができる。

図２４は、情報配信サーバ（１１３）によって、システム運用者や交通事業者の担当者向けに生成および配信される提示画面（２４００）の一例で、複数の輸送障害事例を一画面に表示し、事故事例毎に損失度分布を比較できるように可視化した例を示した図である。画面（２４００）は例えば、ある路線および方面などの事故発生場所や事故発生時間帯を指定し、条件が似ている事故事例を集めて一画面に表示し、それぞれの損失度分布を比較することで、事故時の運行対応などを振り返るための画面である。損失度分布のピーク値に注目することで、総影響人数は多いが一人あたりの損失は少なかったケースや、総影響人数は少ないが全体的に大きな損失を受けたケースなどを発見し、深く分析することが可能になる。

図２５は、情報配信サーバ（１１３）によって、システム運用者や交通事業者の担当者向けに生成および配信される提示画面（２５００）の一例で、ある輸送障害事例で乗客に与えた損失度を区間毎に詳細に分析できるように可視化した例を示した図である。画面（２５００）は様々な区間を利用した乗客の損失度の変化を時系列で表示し、事故発生からどのように影響が派生していったかを区間毎に観察することができる画面の例である。縦軸にとる値は各区間の利用者の中でどのくらいの人が事故の影響を受けたかという比率にしてもよいし、一人あたりの平均損失度や払戻し金額にしてもよい。どの区間をみるかという指定や、時間軸の表示解像度については、マウスなどで自由に操作可能にしてもよいし、この画面（２５００）に付随する形で設定・確認できる領域をもうけてもよい。交通機関の利用データをリアルタイムに収集することができる場合には、このような画面により、事故発生からの影響を時々刻々とモニタリングすることが可能であり、例えば損失の大きい駅や区間に注目して優先的に対策を打つなどの方法がある。

図２０、図２２、図２３、図２４の提示画面を生成するための情報は計算サーバ（１１２）の記憶部（１３３）に蓄積されており、システム運用者（１１９）や各交通事業者の担当者が所定のＷｅｂページにアクセスし、プルダウンメニューなどで項目を選択するなどして指定した条件に従って、利用者照合プログラム（１４１）や払戻し処理プログラム（１４２）が実行され、必要な情報が取得されるものとし、情報配信プログラム（１４３）により取得された情報を編集し、情報を配信する。

以上のように、交通手段利用者の移動データを分析し、輸送障害時に影響を受けた乗客の損失度を定量的に算出し、損失の大きさに応じて払戻し金額を計算し、払戻し処理を実行することで、乗客の不満を解消し、交通事業者の旅客サービスの向上を実現するとともに、駅業務員などの負担を軽減することが可能になる。

本実施形態によれば、乗客の影響移動ログと標準移動パターンと比較した損失度により、時間、コスト、その他を払戻し料金に反映させることができる。影響移動ログと標準移動パターンは、乗客対応に把握されるので、個々の乗客が影響を受けた実態を払戻し料金に反映することができる。

また本実施形態によれば、各乗客が輸送障害が解消後に、ＩＣカードを利用したタイミングで料金の払戻し処理が実行されるので、振替乗車票などを受け取るなどの払戻しに係る乗客の負担が軽減または解消される。
さらに本実施形態によれば、交通系ＩＣ乗車券データや位置情報データを用いて、輸送障害により影響を受けた乗客を機械的に抽出することができるので、駅係員の負担を軽減することができる。

以上、本発明の実施形態について説明したが、本発明は上記実施形態に限定されるものではなく、種々変形実施可能であり、上述した各実施形態を適宜組み合わせることが可能であることは、当業者に理解されよう。

０１〜０７…駅、１１〜１４…路線、２１〜２３…経路、１０１…利用者、１０２…改札機、１０３…ＩＣカード、１０４…利用者、１０５…ネットワーク、１０６…データサーバ、１０７…輸送障害による損失度算出および料金払戻システム、１０８…監視カメラ、１１１…データサーバ、１１２…計算サーバ、１１３…情報配信サーバ、１１４…インターネット、１１５…利用者、１１６…携帯情報端末、１１７…利用者、１１８…情報端末、１１９…交通事業者、１２０…操作端末、１２１…データ格納部、１２２…ＩＣカードデータ、１２３…交通手段利用時の位置データ、１２４…マスタデータ、１２５…移動ログデータ、１２６…通常時の標準移動パターンデータ、１２７…損失度計算結果データ、１３０…ネットワークインタフェース、１３１…ＣＰＵ、１３２…メモリ、１３３…記憶部、１３４…移動ログ生成プログラム、１３５…安定輸送時の標準移動パターン計算プログラム、１３６…事故の影響判別プログラム、１３７…事故時の損失度算出プログラム、１３８…補償金額計算プログラム、１３９…データ格納部、１４１…利用者照合プログラム、１４２…払戻し処理プログラム、１４３…情報配信プログラム、１４５…ネットワークインタフェース、１４５…ネットワークインタフェース、１４６…ＣＰＵ、１４７…メモリ、１４８…記憶部、１５１…ネットワーク、１６１…輸送障害情報データ、１６２…障害エリアおよび障害時間帯、１６３…事故の影響を受けた乗客候補、１６４…事故による損失度、２４１…ログＩＤ、２４２…ユーザＩＤ、２４３…駅・バス停ＩＤ、２４４…利用時刻、２４５…利用種別、２５１…ログＩＤ、２５２…ユーザＩＤ、２５３…緯度、２５４…経度、２５５…通過時刻、２６１…ユーザＩＤ、２６２…区間ＩＤ、２６３…出発地エリアＩＤ、２６４…到着地エリアＩＤ、２６５…対象期間、２６６…時間帯、２６７…合計利用件数、２６８…経路数、２７１…第一経路、２７２…第一経路利用率、２７３…標準時間、２７４…運賃、２８１…乗換回数、２８２…列車の平均待ち時間、２９１…第二経路、２９２…第二経路利用率、３００…駅・バス停マスタ、３０１…駅・バス停ＩＤ、３０２…駅・バス停名、３０３…所有会社、３０４…所在地、３０５…緯度・経度、３１０…路線マスタ、３１１…路線ＩＤ、３１２…路線名、３１３…運営会社、３１４…路線タイプ、３２０…駅・バス停と路線関係マスタ、３２１…路線ＩＤ、３２２…駅・バス停ＩＤ、３２３…順序、３２４…種別、３２５…始点からの所要時間、３３０…経路マスタ、３３１…経路ＩＤ、３３２…出発駅・バス停ＩＤ、３３３…降車駅・バス停ＩＤ、３３４…路線ＩＤ１、３３５…乗換駅・バス停ＩＤ１、３３６…路線ＩＤ２、３４１…乗車路線数、３４２…標準所要時間、３４３…料金、３６１…ログＩＤ、３６２…ユーザＩＤ、３６３…乗車日時、３６４…降車日時、３６５…出発地エリアＩＤ、３６６…到着地エリアＩＤ、３６７…支払額、３６８…経路ＩＤ１、３７１…乗車駅・バス停ＩＤ１、３７２…降車駅・バス停ＩＤ１、３７３…経路ＩＤ２、３７４…乗車駅・バス停ＩＤ２、３７５…降車駅・バス停ＩＤ２、３７６…経路ＩＤ３、４００〜４１３…処理ステップ、５００〜５０８…処理ステップ、７０１…駅、７０２…バス停、７０３〜７０４…駅、７０５〜７０６…バス停、７０７…駅、７１１〜７１２…鉄道路線、７１３〜７１４…バス路線、８００…エリア定義リスト、８０１…エリアＩＤ、８０２…代表駅・バス停ＩＤ、８０３…対象期間、８０４…駅・バス停所数、８０５…駅・バス停ＩＤ１、８０６…駅・バス停ＩＤ２、８０７…駅・バス停ＩＤ３、８０８…駅・バス停ＩＤ４、９０１…事故ＩＤ、９０２…ユーザＩＤ、９０３…損失度、９０４…払戻し処理、９０５…因子１、９０６…因子２、９０７…因子３、１０００〜１００９…処理ステップ、１１００…輸送障害情報データ、１１０１…事故ＩＤ、１１０２…日付、１１０３…発生時刻、１１０４…路線、１１０５…発生場所、１１０６…運転再開時刻、１１０７…原因、１２００〜１２０９…処理ステップ、１３０１〜１３０４…交通手段利用可能場所、１４００…補償料金表データ、１４０１…曜日、１４０２…路線ＩＤ、１４０３…損失度、１４０４…料金、１５００〜１５０３…処理ステップ、１６００〜１６０４…処理ステップ、２１００…オンライン払戻し料金案内検索画面、２１０１…ユーザ名入力欄、２１０２…事故入力欄、２１０３…日付選択欄、２１０４…ログインボタン、２２００…損失度分布計算結果表示画面、２２０１…事故情報、２２０２…損失度分布、２２０３…払戻し料金表、２３００…損失度構成表表示画面、２４００…複数事故損失度比較画面、２５００…区間別損失度変化表示画面。

Claims (12)

1. 交通機関を利用する乗客の移動ログを収集し、収集した前記移動ログの中の、前記交通機関の通常時の移動ログに基づいて前記乗客の標準移動パターンを生成する標準移動パターン生成部、
   前記交通機関の輸送障害の発生に伴う障害影響エリア及び障害影響時間帯に関する情報を取得する輸送障害情報取得部、
   収集した前記移動ログの中に、前記輸送障害エリア及び前記障害影響時間帯の前記乗客の移動ログである影響移動ログの有無を判定する影響有無判定部、
   前記影響有無判定部により、前記影響移動ログが有と判定された場合、前記標準移動パターンと前記影響移動ログとの差に基づいて、前記輸送障害に伴う前記乗客の損失度を算出する損失度算出部、及び
   算出した前記損失度に対応した、前記交通機関の前記輸送障害の発生に伴う払戻し料金を払戻す払戻部を有することを特徴とする料金払戻しシステム。
2. 前記乗客の標準移動パターンは、前記乗客が前記交通機関を利用して所定の出発地から所定の到着地へ移動した経路を示す前記移動ログの中で、最も割合が多い移動ログが示す経路であることを特徴とする請求項１記載の料金払戻しシステム。
3. 前記標準移動パターン生成部は、前記乗客を特定するデータ及び前記乗客の位置情報に基づいて、前記乗客の前記移動ログを生成することを特徴とする請求項２記載の料金払戻しシステム。
4. 前記乗客を特定するデータ及び前記乗客の位置情報は、前記乗客のＩＣカードから読み取る前記乗客を特定するデータ、及び前記乗客を特定するデータを読み取る読み取り機の位置情報、並びに、前記乗客の映像データに基づいた前記乗客を特定するデータ、及び前記乗客の前記映像データを取得した位置情報、のいずれか一方であることを特徴とする請求項３記載の料金払戻しシステム。
5. 前記払戻部は、前記乗客の前記払戻し料金のオンライン払戻し料金案内画面情報、及び前記乗客の前記払戻し料金の算出理由を説明する画面情報を、前記乗客に向けて配信することを特徴とする請求項２記載の料金払戻しシステム。
6. 前記払戻部は、前記輸送障害を含む複数の輸送障害事例毎に前記損失度の分布画面情報、及び前記輸送障害が前記乗客を含む乗客の損失度を、前記交通機関が運行する区間毎に示す画面情報を、前記交通機関の事業者に向けて配信することを特徴とする請求項２記載の料金払戻しシステム。
7. 交通機関の輸送障害の発生に伴う払戻し料金を払戻す料金払戻しシステムにおける料金払戻し方法であって、前記料金払戻しシステムは、
   前記交通機関を利用する乗客の移動ログを収集し、収集した前記移動ログの中の、前記交通機関の通常時の移動ログに基づいて前記乗客の標準移動パターンを生成し、
   前記交通機関の前記輸送障害の発生に伴う障害影響エリア及び障害影響時間帯に関する情報を取得し、
   収集した前記移動ログの中に、前記輸送障害エリア及び前記障害影響時間帯の前記乗客の移動ログである影響移動ログの有無を判定し、
   前記判定の結果、前記影響移動ログが有と判定された場合、前記標準移動パターンと前記影響移動ログとの差に基づいて、前記輸送障害に伴う前記乗客の損失度を算出し、
   算出した前記損失度に対応した、前記交通機関の前記輸送障害の発生に伴う払戻し料金を払戻すことを特徴とする料金払戻し方法。
8. 前記乗客の標準移動パターンは、前記乗客が前記交通機関を利用して所定の出発地から所定の到着地へ移動した経路を示す前記移動ログの中で、最も割合が多い移動ログが示す経路であることを特徴とする請求項７記載の料金払戻し方法。
9. 前記料金払戻しシステムは、前記乗客を特定するデータ及び前記乗客の位置情報に基づいて、前記乗客の前記移動ログを生成することを特徴とする請求項８記載の料金払戻し方法。
10. 前記乗客を特定するデータ及び前記乗客の位置情報は、前記乗客のＩＣカードから読み取る前記乗客を特定するデータ、及び前記乗客を特定するデータを読み取る読み取り機の位置情報、並びに、前記乗客の映像データに基づいた前記乗客を特定するデータ、及び前記乗客の前記映像データを取得した位置情報、のいずれか一方であることを特徴とする請求項９記載の料金払戻し方法。
11. 前記料金払戻しシステムは、前記乗客の前記払戻し料金のオンライン払戻し料金案内画面情報、及び前記乗客の前記払戻し料金の算出理由を説明する画面情報を、前記乗客に向けて配信することを特徴とする請求項８記載の料金払戻し方法。
12. 前記料金払戻しシステムは、前記輸送障害を含む複数の輸送障害事例毎に前記損失度の分布画面情報、及び前記輸送障害が前記乗客を含む乗客の損失度を、前記交通機関が運行する区間毎に示す画面情報を、前記交通機関の事業者に向けて配信することを特徴とする請求項８記載の料金払戻し方法。

Images