(57)【要約】【課題】運賃誤収受などの障害が判明した場合に、過去の事例の中から該当する障害事例を容易に検索することが可能な検索システムを提供する。【解決手段】乗車履歴管理システム１と障害事例抽出システム２とにより運賃計算障害事例検索システムが構成される。乗車履歴管理システム１は、改札機３からの一件明細情報４に基づいて作成された乗車履歴情報５の集合を過去事例として蓄積した乗車履歴情報データベース２５を備える。障害事例抽出システム２は、不具合修正前と不具合修正後の２つのバージョンの運賃計算シミュレータ６，７を備える。乗車履歴情報データベース２５の全ての乗車履歴情報５に対して、運賃計算シミュレータ６，７による運賃計算のシミュレーションを行ない、双方の運賃計算結果に差異がある事例を運賃計算障害事例８として抽出する。【選択図】図１
2007272281.tif 000002
【特許請求の範囲】
【請求項１】
入力情報に対して所定の計算ソフトウェアを用いて計算処理を行なう装置で発生した障害事例を検索するためのシステムであって、
過去に計算ソフトウェアに基づいて計算処理を実行したときの入力情報の集合を過去事例として蓄積した蓄積手段と、
前記蓄積手段に蓄積された過去事例を入力とし、障害に対する不具合を修正する前の計算ソフトウェアと、障害に対する不具合を修正した後の計算ソフトウェアとを用いて、過去事例について計算処理を実行する計算処理実行手段と、
前記計算処理実行手段が実行した不具合修正前の計算ソフトウェアに基づく計算結果と、不具合修正後の計算ソフトウェアに基づく計算結果とを比較する比較手段と、
前記比較手段による比較の結果、双方の計算結果に差異がある場合の過去事例を障害事例として抽出する抽出手段と、
を備えたことを特徴とする障害事例検索システム。
【請求項２】
乗車媒体から読み取った情報を入力情報として運賃計算プログラムおよび運賃データを用いて運賃計算を行ない当該運賃を徴収する駅務機器で発生した運賃計算障害事例を検索するためのシステムであって、
過去に運賃計算プログラムおよび運賃データに基づいて運賃計算を実行したときの入力情報の集合を過去事例として蓄積した蓄積手段と、
前記蓄積手段に蓄積された過去事例を入力とし、障害に対する不具合を修正する前の運賃計算プログラムおよび運賃データと、障害に対する不具合を修正した後の運賃計算プログラムおよび運賃データとを用いて、過去事例について運賃を計算する運賃計算手段と、
前記運賃計算手段が計算した不具合修正前の運賃計算プログラムおよび運賃データに基づく運賃計算結果と、不具合修正後の運賃計算プログラムおよび運賃データに基づく運賃計算結果とを比較する比較手段と、
前記比較手段による比較の結果、双方の運賃計算結果に差異がある場合の過去事例を運賃計算障害事例として抽出する抽出手段と、
を備えたことを特徴とする運賃計算障害事例検索システム。
【請求項３】
乗車媒体から読み取った情報を入力情報として運賃計算プログラムおよび運賃データを用いて運賃計算を行ない当該運賃を徴収する駅務機器で発生した運賃計算障害事例を検索するためのシステムであって、
過去の乗車履歴情報を管理する乗車履歴管理システムと、前記乗車履歴情報に基づいて運賃計算の障害事例を抽出する障害事例抽出システムとからなり、
前記乗車履歴管理システムは、各駅の駅務機器から送られてくる一件明細情報に基づいて作成された乗車履歴情報の集合を過去事例として蓄積した乗車履歴情報データベースを備え、
前記障害事例抽出システムは、
前記乗車履歴情報データベースに蓄積された過去事例を入力とし、障害に対する不具合を修正する前の運賃計算プログラムおよび運賃データに基づき過去事例について運賃計算のシミュレーションを行なう第１の運賃計算シミュレータと、
前記乗車履歴情報データベースに蓄積された過去事例を入力とし、障害に対する不具合を修正した後の運賃計算プログラムおよび運賃データに基づき過去事例について運賃計算のシミュレーションを行なう第２の運賃計算シミュレータとを備え、
前記第１、第２の運賃計算シミュレータによる運賃計算結果を比較し、双方の運賃計算結果に差異がある場合の過去事例を運賃計算障害事例として抽出することを特徴とする運賃計算障害事例検索システム。
【請求項４】
請求項３に記載の運賃計算障害事例検索システムにおいて、
前記乗車履歴情報は、入場駅から出場駅に至る乗車経路を表した複数の駅名を含んでおり、
前記第１、第２の運賃計算シミュレータは、初回のシミュレーション実行時に、入場駅について運賃計算のシミュレーションを行なって、当該入場駅で乗車媒体に書き込まれる媒体書込情報を出力し、２回目以降のシミュレーション実行時に、前回のシミュレーションで得られた媒体書込情報と次の駅名とを入力として運賃計算のシミュレーションを行なうことを特徴とする運賃計算障害事例検索システム。
【請求項５】
請求項２ないし請求項４のいずれかに記載の運賃計算障害事例検索システムにおいて、
前記運賃計算障害事例は、当該障害による損害を被った利用者を特定するための利用者情報と、前記損害の金額とを含むことを特徴とする運賃計算障害事例検索システム。
【請求項６】
所定の取引に基づく入力情報に対して料金計算プログラムおよび料金データを用いて料金計算を行ない当該料金を徴収する取引処理装置で発生した料金計算障害事例を検索するためのシステムであって、
過去に料金計算プログラムおよび料金データに基づいて料金計算を実行したときの入力情報の集合を過去事例として蓄積した蓄積手段と、
前記蓄積手段に蓄積された過去事例を入力とし、障害に対する不具合を修正する前の料金計算プログラムおよび料金データと、障害に対する不具合を修正した後の料金計算プログラムおよび料金データとのそれぞれを用いて、過去事例について料金を計算する料金計算手段と、
前記料金計算手段が計算した不具合修正前の料金計算プログラムおよび料金データに基づく料金計算結果と、不具合修正後の料金計算プログラムおよび料金データに基づく料金計算結果とを比較する比較手段と、
前記比較手段による比較の結果、双方の料金計算結果に差異がある場合の過去事例を料金計算障害事例として抽出する抽出手段と、
を備えたことを特徴とする料金計算障害事例検索システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、駅の自動改札機や自動精算機で徴収した運賃に誤りがあったことが事後的に判明した場合に、損害を被った利用者に差額を弁済するために過去の障害事例を検索するシステムに関する。
【背景技術】
【０００２】
鉄道の駅に設置される自動改札機や自動精算機などの自動運賃収受機器は、運賃を計算するためのソフトウェア（運賃計算プログラムおよび運賃データ）が搭載されており、プリペイドカードや、定期券とプリペイドカードの機能を併せ持つ複合券などの乗車媒体が投入されると、上記ソフトウェアを用いて運賃計算を行い、算出した運賃を乗車媒体の残額から引き去って徴収するようにしている。しかるに、ソフトウェアの欠陥が原因で、運賃の計算に誤りが発生し、正規の運賃よりも高い運賃を徴収してしまうことがある。このような障害が発生した場合、鉄道事業者は、障害の内容を所轄官庁に報告するとともに、一般利用者に対して告知を行い、損害を受けた利用者に対して差額を払い戻す。
【０００３】
しかしながら、従来は、上記のような払い戻しを受けるには、利用者が鉄道事業者に対して自己申告しなければならず、利用者が障害発生により損害を受けたことに気づかなかった場合は、払い戻しを受けることができない。このため、損害を受けた全ての利用者に対して、完全かつ自動的に弁済を行なうことは困難であった。
【０００４】
これに対し、過去の乗車履歴情報と運賃計算結果とを合わせた過去事例が保存されている場合は、過去事例の乗車履歴情報を用いて修正後の運賃計算プログラムおよび運賃データに基づく運賃計算を行った結果と、過去事例の運賃計算結果とを比較し、両者に差異がある事例を障害事例として抽出する方法が考えられる。しかしながら、この方法では、今回発生した障害事例だけでなく、過去に発生した障害事例についても運賃計算結果に差異が生じるため、過去の障害事例全てが抽出される結果となり、膨大な障害事例の中から今回の障害事例だけを抽出することが困難となる。
【０００５】
一方、下記の特許文献１には、運賃の誤収受があった場合のリカバリー処理について記載されている。本文献においては、誤収受処理がされた乗車媒体のＩＤ情報がセンタサーバのデータベースに登録される。センタサーバは、このＩＤ情報をネガデータとして各駅務機器に配信する。駅務機器は、投入された乗車媒体から読み取ったＩＤ情報が、センタサーバから配信されたネガデータと一致するか否かを判別し、一致する場合は、乗車媒体を駅の窓口へ持参するよう利用者に対して案内を行なう。利用者は、乗車媒体を窓口へ持参し、過徴収された金額を乗車媒体にチャージしてもらうことで払い戻しを受ける。
【特許文献１】特開２００４−１８５２１０号公報（段落００８５〜００９８）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記特許文献１は、制御ボードに搭載されているハードウエアの一部に不具合が発生した場合に誤った運賃が算出されるという課題を解決するものである。したがって、運賃を算出するソフトウェア自体の不具合が原因で、誤った運賃が算出され誤収受が発生した場合、ソフトウェアの不具合が判明してプログラムやデータの修正が行なわれた後であれば、特許文献１の技術を用いて利用者に弁済を行なうことは可能であるが、ソフトウェアの修正前に発生した運賃誤収受により損害を受けた利用者に対しては、過去に遡って弁済を行なうことはできなかった。
【０００７】
本発明は、上述した問題点に鑑み、運賃誤収受などの障害が判明した場合に、過去の事例の中から該当する障害事例を容易に検索することが可能な検索システムを提供することを目的としている。
【課題を解決するための手段】
【０００８】
最初に、本発明の基本的な考え方について説明する。本発明では、障害に対する不具合を修正する前および修正した後の２つのバージョンのソフトウェアと、過去の事例とを用いて障害事例を抽出する。ここでいう「事例」とは、駅務システムの場合を例にとると、１人の乗客が乗車駅で入場してから降車駅で出場するまでの乗車履歴情報のことである。このような事例を入力として、不具合修正前と不具合修正後の各ソフトウェアにより計算処理を実行し、計算結果を出力すると、不具合修正前のソフトウェアにより計算処理を実行した場合は、
（１）障害を起こさない事例であれば、正しい計算結果が得られる。
（２）障害を起こす事例であれば、誤った計算結果が得られる。
一方、不具合修正後のソフトウェアにより計算を実行した場合は、
（３）障害を起こさない事例であれば、正しい計算結果が得られる。
（４）障害を起こす事例であっても、正しい計算結果が得られる。
したがって、上記（１）〜（４）により、双方のソフトウェアによる計算結果が一致しない事例は、障害を起こす事例である。そこで、過去の全ての事例に対して計算結果の一致・不一致の検証を行い、不一致のものを障害事例と判別することで、過去の事例集合の中から障害事例を容易に抽出することができる。
【０００９】
上記原理に基づき、本発明に係る障害事例検索システムは、入力情報に対して所定の計算ソフトウェアを用いて計算処理を行なう装置で発生した障害事例を検索するためのシステムであって、過去に計算ソフトウェアに基づいて計算処理を実行したときの入力情報の集合を過去事例として蓄積した蓄積手段と、この蓄積手段に蓄積された過去事例を入力とし、障害に対する不具合を修正する前の計算ソフトウェアと、障害に対する不具合を修正した後の計算ソフトウェアとを用いて、過去事例について計算処理を実行する計算処理実行手段と、この計算処理実行手段が実行した不具合修正前の計算ソフトウェアに基づく計算結果と、不具合修正後の計算ソフトウェアに基づく計算結果とを比較する比較手段と、この比較手段による比較の結果、双方の計算結果に差異がある場合の過去事例を障害事例として抽出する抽出手段とを備える。ここでいうソフトウェアは、プログラムとデータとの組であってもよいし、プログラム単体であってもよい。
【００１０】
このように、不具合修正前の計算ソフトウェアと不具合修正後の計算ソフトウェアという２つのバージョンのソフトウェアを用いて、過去事例について計算処理を実行し、それらの計算結果を比較して、計算結果に差異があるものを障害事例と判別することにより、今回発生した障害事例のみが自動的に抽出される。このため、過去の事例の中から該当する障害事例を迅速かつ容易に検索することができる。また、障害かどうかを判別する特別なパターン照合を必要とせずに、判別の自動化が容易に実現できる。
【００１１】
次に、本発明に係る運賃計算障害事例検索システムは、乗車媒体から読み取った情報を入力情報として運賃計算プログラムおよび運賃データを用いて運賃計算を行ない当該運賃を徴収する駅務機器で発生した運賃計算障害事例を検索するためのシステムであって、過去に運賃計算プログラムおよび運賃データに基づいて運賃計算を実行したときの入力情報の集合を過去事例として蓄積した蓄積手段と、この蓄積手段に蓄積された過去事例を入力とし、障害に対する不具合を修正する前の運賃計算プログラムおよび運賃データと、障害に対する不具合を修正した後の運賃計算プログラムおよび運賃データとを用いて、過去事例について運賃を計算する運賃計算手段と、この運賃計算手段が計算した不具合修正前の運賃計算プログラムおよび運賃データに基づく運賃計算結果と、不具合修正後の運賃計算プログラムおよび運賃データに基づく運賃計算結果とを比較する比較手段と、この比較手段による比較の結果、双方の運賃計算結果に差異がある場合の過去事例を運賃計算障害事例として抽出する抽出手段とを備える。
【００１２】
このように、不具合修正前の運賃計算プログラムおよび運賃データと、不具合修正後の運賃計算プログラムおよび運賃データという２つのバージョンのソフトウェアを用いて、過去事例について運賃計算処理を実行し、それらの計算結果を比較して、計算結果に差異があるものを障害事例と判別することにより、今回発生した障害事例のみが自動的に抽出される。このため、過去の事例の中から該当する障害事例を迅速かつ容易に検索することができる。また、障害かどうかを判別する特別なパターン照合を必要とせずに、判別の自動化が容易に実現できる。
【００１３】
本発明の運賃計算障害事例検索システムは、過去の乗車履歴情報を管理する乗車履歴管理システムと、乗車履歴情報に基づいて運賃計算の障害事例を抽出する障害事例抽出システムとから構成することができる。乗車履歴管理システムは、各駅の駅務機器から送られてくる一件明細情報に基づいて作成された乗車履歴情報の集合を過去事例として蓄積した乗車履歴情報データベースを備える。障害事例抽出システムは、運賃計算のシミュレーションを行なう２つの運賃計算シミュレータを備える。第１の運賃計算シミュレータは、乗車履歴情報データベースに蓄積された過去事例を入力とし、障害に対する不具合を修正する前の運賃計算プログラムおよび運賃データに基づき過去事例について運賃計算のシミュレーションを行なう。第２の運賃計算シミュレータは、乗車履歴情報データベースに蓄積された過去事例を入力とし、障害に対する不具合を修正した後の運賃計算プログラムおよび運賃データに基づき過去事例について運賃計算のシミュレーションを行なう。障害事例抽出システムは、第１、第２の運賃計算シミュレータによる運賃計算結果を比較し、双方の運賃計算結果に差異がある場合の過去事例を運賃計算障害事例として抽出する。
【００１４】
本発明の典型的な実施形態では、上記の運賃計算障害事例検索システムにおいて、乗車履歴情報が、入場駅から出場駅に至る乗車経路を表した複数の駅名を含んでいる。そして、第１、第２の運賃計算シミュレータは、初回のシミュレーション実行時に、入場駅について運賃計算のシミュレーションを行なって、当該入場駅で乗車媒体に書き込まれる媒体書込情報を出力し、２回目以降のシミュレーション実行時に、前回のシミュレーションで得られた媒体書込情報と次の駅名とを入力として運賃計算のシミュレーションを行なう。このように、乗車経路に従って順次運賃計算のシミュレーションを行ない、各回で得られた媒体書込情報を次のシミュレーションに反映させることにより、入場駅から出場駅までの各駅で投入される実際の乗車媒体の記録情報を簡単に再現することができる。
【００１５】
本発明の運賃計算障害事例検索システムにより出力される運賃計算障害事例は、当該障害による損害を被った利用者を特定するための利用者情報と、損害の金額とを含むことが好ましい。これによると、損害を受けた利用者全員に対して、損害額の弁済を漏れなく確実に行なうことができる。
【００１６】
次に、本発明に係る料金計算障害事例検索システムは、所定の取引に基づく入力情報に対して料金計算プログラムおよび料金データを用いて料金計算を行ない当該料金を徴収する取引処理装置で発生した料金計算障害事例を検索するためのシステムであって、過去に料金計算プログラムおよび料金データに基づいて料金計算を実行したときの入力情報の集合を過去事例として蓄積した蓄積手段と、この蓄積手段に蓄積された過去事例を入力とし、不具合を修正する前の料金計算プログラムおよび料金データと、障害に対する不具合を修正した後の料金計算プログラムおよび料金データとのそれぞれを用いて、過去事例について料金を計算する料金計算手段と、この料金計算手段が計算した不具合修正前の料金計算プログラムおよび料金データに基づく料金計算結果と、不具合修正後の料金計算プログラムおよび料金データに基づく料金計算結果とを比較する比較手段と、この比較手段による比較の結果、双方の料金計算結果に差異がある場合の過去事例を料金計算障害事例として抽出する抽出手段とを備える。
【００１７】
このように、不具合修正前の料金計算プログラムおよび料金データと、不具合修正後の料金計算プログラムおよび料金データという２つのバージョンのソフトウェアを用いて、過去事例について料金計算処理を実行し、それらの計算結果を比較して、計算結果に差異があるものを障害事例と判別することにより、今回発生した障害事例のみが自動的に抽出される。このため、過去の事例の中から該当する障害事例を迅速かつ容易に検索することができる。また、障害かどうかを判別する特別なパターン照合を必要とせずに、判別の自動化が容易に実現できる。
【発明の効果】
【００１８】
本発明によれば、過去の事例の中から該当する障害事例を容易に検索することができるので、運賃誤収受などの障害が発生した場合でも、過去に遡って弁済を行なうなどの措置をとることが可能となる。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の障害事例検索システムの実施形態につき、図面を参照しながら説明する。
【００２０】
図１は、本発明を運賃計算障害事例の検索システムに適用した場合の実施形態を示す概略構成図である。本検索システムは、大別して、過去の乗車履歴情報を管理する乗車履歴管理システム１と、乗車履歴情報に基づいて運賃計算の障害事例を抽出する障害事例抽出システム２とからなる。３は各駅に設置された改札機である。なお、駅務機器としては改札機に限らず、精算機や窓口処理機なども対象となるが、以下では簡単のために改札機のみを例に挙げる。また、乗車媒体としては、定期券とプリペイドカードの両機能を併せ持つ複合券を想定する。
【００２１】
乗車履歴管理システム１は、一件明細情報データベース（以下、「一件明細情報ＤＢ」と記す。）２４と、乗車履歴情報データベース（以下、「乗車履歴情報ＤＢ」と記す。）２５を備えている。４は一件明細情報ＤＢ２４に蓄積される一件明細情報、５は乗車履歴情報ＤＢ２５に蓄積される乗車履歴情報である。これらの詳細については後述する。
【００２２】
障害事例抽出システム２は、運賃計算シミュレータ６と、運賃計算シミュレータ７を備えている。運賃計算シミュレータ６は、障害に対する不具合を修正する前の運賃計算プログラム３８および運賃データ３９からなるソフトウェアである。運賃計算シミュレータ７は、障害に対する不具合を修正した後の運賃計算プログラム４０および運賃データ４１からなるソフトウェアである。これらの運賃計算シミュレータ６，７の詳細については後述する。８は障害事例抽出システム２により抽出された運賃計算障害事例を表している。この詳細についても後述する。
【００２３】
次に、図１の検索システムにおける処理手順の概要を説明する。乗車履歴管理システム１は、随時、各駅の改札機３から送られてくる一件明細情報４を受信する。なお、図１では図示を省略しているが、実際には、各改札機からの一件明細情報４は上位装置（駅サーバおよびセンタサーバ）に集められ、ここから乗車履歴管理システム１へ送信される。一件明細情報４は、改札機３に乗車媒体が投入されたときに改札機３が処理した情報、すなわち乗車媒体から読み取られた情報および乗車媒体に書き込まれた情報であり、改札機３での１回の接客動作（乗車媒体の投入）により、１つの一件明細情報４が生成される。受信された一件明細情報４は、一件明細情報ＤＢ２４に蓄積される。乗車履歴管理システム１では、この一件明細情報４に基づいて乗車履歴情報５を作成する。乗車履歴情報５は、ある乗客が乗車駅で入場して降車駅で精算・出場するまでの履歴を表した情報である。作成された乗車履歴情報５は、乗車履歴情報ＤＢ２５に蓄積される。
【００２４】
運賃の誤収受が発生したことが判明して該当事例を検索する場合は、障害事例抽出システム２を起動させ、乗車履歴情報ＤＢ２５から取得した乗車履歴情報５をもとに、２つの運賃計算シミュレータ６，７により、各駅の改札機での運賃計算のシミュレーションを行なう。運賃計算シミュレータ６では、不具合修正前のプログラムとデータを用いた運賃計算が行なわれ、運賃シミュレータ７では、不具合修正後のプログラムとデータを用いた運賃計算が行なわれる。障害事例抽出システム２は、それぞれの運賃計算シミュレータ６，７で得られた計算結果を比較し、計算結果に差がなければ、その事例は障害事例に該当しないと判定し、計算結果に差があれば、その事例は障害事例に該当すると判定する。そして、計算結果に差がある事例を運賃計算障害事例８として抽出する。この障害事例８には、利用者や誤収受金額などに関する情報が含まれており、これによって損害を受けた利用者や金額を特定することができる。
【００２５】
図２は、乗車履歴管理システム１の具体的な構成を示したブロック図である。２０は通信制御装置であって、ネットワーク１０を介して、改札機３の上位装置や障害事例抽出システム２との間でデータの授受を行なう。２１はＲＯＭやＲＡＭ等から構成されるメモリ、２２は演算装置であるＣＰＵ、２３および２６は例えばハードディスクから構成される記憶装置である。記憶装置２３には、前述の一件明細情報４が蓄積された一件明細情報ＤＢ２４と、前述の乗車履歴情報５が蓄積された乗車履歴情報ＤＢ２５が格納されている。記憶装置２６には、一件明細情報管理プログラム２７と、乗車履歴情報生成プログラム２８と、乗車履歴情報管理プログラム２９とが格納されている。
【００２６】
一件明細情報管理プログラム２７は、受信した全ての一件明細情報４を一件明細情報ＤＢ２４に蓄積して管理する。乗車履歴情報生成プログラム２８は、一件明細情報４に基づいて、乗車媒体ごとの乗車履歴情報５を生成する。乗車履歴情報管理プログラム２９は、生成された乗車履歴情報５を乗車履歴情報ＤＢ２５に蓄積して管理する。
【００２７】
なお、ここでは便宜上、データベース２４，２５を格納する記憶装置２３と、プログラム２７〜２９を格納する記憶装置２６とを別々に設けたが、１つの記憶装置に上述したデータベースとプログラムを格納してもよい。
【００２８】
以上の乗車履歴管理システム１において、乗車履歴情報５の集合が過去事例として蓄積される乗車履歴情報ＤＢ２５は、本発明における蓄積手段を構成する。
【００２９】
図３は、一件明細情報４の具体的な内容を示した図である。ここでは、一件明細情報の一部を抜粋して図示してあり、実際にはこれ以外の情報も含まれている。「ＩＤ」は乗車媒体ごとに割り当てられた識別番号であって、定期券やプリペイドカード等の発行時にこれらに記録される。このＩＤにより、乗車媒体の所有者が特定される。「乗降駅」は、利用者が乗車媒体を改札機に投入した駅である。「種別」は、乗降駅が入場駅か出場駅か、あるいは乗継駅かを表す情報である。「精算金額」は、精算区間の運賃に相当する金額である。「残額」は、乗車媒体に記録されている金額から精算金額を減額した後の金額である。「利用日時」は、乗車媒体が改札機で使用された日時である。
【００３０】
図３の例は、利用区間がＡ駅−Ｂ駅である定期券（プリペイドカード機能を持つ複合券）でＡ駅の改札機を通って入場し（図３（ａ））、Ｂ駅で改札機を通って他社線に乗り継ぎ（図３（ｂ））、他社線のＣ駅の改札機を通って出場（図３（ｃ））した場合の一件明細情報４を示している。このように、改札機を１回通るたびに、１つの一件明細情報４が生成される。本例では、Ｂ駅−Ｃ駅間が精算区間となり、Ｃ駅の改札機での出場時に、定期券の残額から精算金額が減額される。
【００３１】
図４は、乗車履歴情報５の具体的な内容を示した図である。乗車履歴情報５は、前述のように、一件明細情報４に基づいて作成される。この場合、個々の一件明細情報４には、図３で示したように乗車媒体のＩＤが含まれているので、同じＩＤを持つ一件明細情報４が集められて一件明細リストが作成され、このリストに基づいて乗車履歴情報５が作成される。乗車履歴情報５の詳細な作成手順については後述する。
【００３２】
図４のように、乗車履歴情報５には、乗車媒体のＩＤと、乗車経路を表す駅名リストとが含まれている。駅名リストには、利用者が入場した駅と、乗り継ぎをした駅と、最後に精算を行なって出場した駅が時系列的に記録される。実際には、これらの駅名は線区駅順コードとして記録される。線区駅順コードは、鉄道サイバネ規格により駅ごとに付与されたコードである。図４の例からもわかるように、駅名リストの最初に記録されるのは、入場駅（Ａ駅）の線区駅順コードであり、２番目以降に記録されるのは、乗継駅（Ｂ駅）の線区駅順コードであり、最後に記録されるのは、出場駅（Ｃ駅）の線区駅順コードである。この乗車履歴情報５は、すでに述べたように、一人の乗客が入場して出場するまでの履歴を表す情報であって、これにより当該乗客の乗車経路を特定することができる。なお、乗車履歴情報５には、ＩＤや駅名のほか、乗車日や大人／小人の区別などの情報も記録される。
【００３３】
図５は、乗車履歴情報生成プログラム２８（図２）による乗車履歴情報５の作成手順を示したフローチャートである。この乗車履歴情報生成プログラム２８は、毎日あるいは毎週など定期的に実行され、一件明細情報ＤＢ２４から一日あるいは一週間などの一定期間内に出力された一件明細情報４を取り出して、それらに基づき乗車履歴情報５を生成する。
【００３４】
乗車履歴情報生成プログラム２８がスタートすると、最初に、一件明細情報ＤＢ２４から同一ＩＤを持つ一件明細情報４を集めて、ＩＤごとに一件明細リストを作成する（ステップＳ１）。この一件明細リストは、図３で示したような同一ＩＤの一件明細情報４を日時でソーティングして時系列的に並べたものである。１つのＩＤにつき、１つの一件明細リストが作成され、各ＩＤについて作成された一件明細リストにより、リストの集合が形成される。
【００３５】
次に、リスト集合からＮ番目のＩＤの一件明細リストを取り出す（ステップＳ２）。初回はＮ＝１であり、例えば最も番号の古いＩＤの一件明細リストが取り出される。続いて、取り出した一件明細リストが空か否か、すなわちリスト内に一件明細情報４があるか否かを判定する（ステップＳ３）。最初は、リスト内に一件明細情報４があるので（ステップＳ３：ＮＯ）、一件明細リストから一件明細情報４を１つ取り出す（ステップＳ４）。この場合、最も古い利用日時の記録されている一件明細情報４が取り出される。
【００３６】
次に、取り出した一件明細情報４が最初の一件明細情報か否か、または後述するトリップ切断があった後の一件明細情報か否かを判定する（ステップＳ５）。今の場合は、取り出した一件明細情報４は最初のものであるから（ステップＳ５：ＹＥＳ）、ステップＳ６へ移って乗車履歴情報が新規に作成される。例えば、ステップＳ４で取り出した最初の一件明細情報が図３（ａ）の一件明細情報４であったとすると、図６（ａ）に示すように、駅名リストにＡ駅が記録された乗車履歴情報５が作成される。
【００３７】
ステップＳ６を実行した後、ステップＳ４へ戻って、一件明細リストから次の一件明細情報４を１つ取り出す。そして、ステップＳ５の判定を行なうが、今回は最初でもなくトリップ切断後でもないので（ステップＳ５：ＮＯ）、ステップＳ７へ移行し、乗車履歴情報５の内容を更新する。具体的には、乗車履歴情報５の駅名リストに駅名を追加する。例えば、ステップＳ４で２回目に取り出した一件明細情報が図３（ｂ）の一件明細情報４であったとすると、図６（ｂ）に示すように、駅名リストにＢ駅が追加された乗車履歴情報５が作成される。
【００３８】
その後、ステップＳ８に移って、乗り継ぎ判定を行なう。乗り継ぎ判定とは、他社線または自社線への乗り継ぎを行なう乗継駅の改札機を通過する際に、これまでの乗車経路をその乗継駅で切って精算を行うのか、あるいは精算を行わずに乗り継ぎ後も乗車経路として継続するのかを判定する処理をいう。出場用の改札機を通った場合は、その駅で乗車経路が断たれて精算が行われる。この場合を以下では「トリップ切断」という。一方、乗継用の改札機を通った場合は、乗車経路は断たれず精算も行われない。この場合を以下では「トリップ継続」という。
【００３９】
ステップＳ８では、Ｂ駅の改札機での処理が出場ではなく乗継であるので、「トリップ継続」と判定される。したがって、ステップＳ４へ移行して、一件明細リストから次の一件明細情報４を１つ取り出す。そして、ステップＳ５の判定を行なうが、今回も最初でもなくトリップ切断後でもないので（ステップＳ５：ＮＯ）、ステップＳ７へ移行し、乗車履歴情報５の駅名リストに駅名を追加して、乗車履歴情報５の内容を更新する。例えば、ステップＳ４で３回目に取り出した一件明細情報が図３（ｃ）の一件明細情報４であったとすると、図６（ｃ）に示すように、駅名リストにＣ駅が追加された乗車履歴情報５が作成される。
【００４０】
その後、ステップＳ８に移って乗り継ぎ判定を行なうが、今回はＣ駅の改札機での処理が出場であるので、乗り継ぎ判定の結果は「トリップ切断」となる。トリップ切断があった場合は、１つの乗車履歴情報５が完結するので、ステップＳ９に移って、完結した乗車履歴情報５を乗車履歴情報ＤＢ２５（図２）に格納する。
【００４１】
ステップＳ９を実行した後は、ステップＳ３に戻り、一件明細リストが空か否かを判定する。リスト内に一件明細情報４があれば（ステップＳ３：ＮＯ）、一件明細リストから一件明細情報４を１つ取り出す（ステップＳ４）。この場合、取り出される一件明細情報４は、最初のもの（最も古いもの）ではないが、前回の乗車履歴情報５の作成時にステップＳ８でトリップ切断が行なわれているので、ステップＳ５では、取り出された一件明細情報４はトリップ切断後の一件明細情報であると判定され（ステップＳ５：ＹＥＳ）、ステップＳ６で新たな次の乗車履歴情報５が作成される。なお、この場合のステップＳ５での判定は、前回にステップＳ８でトリップ切断と判定したときにセットされるトリップ切断フラグに基づいて行なわれる。
【００４２】
その後、ステップＳ４、Ｓ５、Ｓ７〜Ｓ９を前記の手順に従って実行し、リストから取り出した一件明細情報４に基づいて新たに作成した乗車履歴情報５を乗車履歴情報ＤＢ２５に追加して、ステップＳ３に戻る。以後、同様の手順を繰り返して、１番目のＩＤについての乗車履歴情報５を順次作成してゆく。そして、一件明細リストから一件明細情報４が全て取り出されると、一件明細リストは空となるので（ステップＳ３：ＹＥＳ）、ステップＳ１０へ移行して、全てのＩＤについて乗車履歴情報の作成が終了したか否かを判定する。判定の結果、全ＩＤについて終了してなければ（ステップＳ１０：ＮＯ）、ステップＳ２へ移行し、Ｎ＝２として、２番目のＩＤの一件明細リストを取り出す。その後は、前記と同様にして、ステップＳ３以降を実行し、２番目のＩＤについての乗車履歴情報５を順次作成し、乗車履歴情報ＤＢ２５に追加してゆく。そして、最終のＩＤについて乗車履歴情報を作成するまで、同様の手順を繰り返し実行し、全ＩＤについて乗車履歴情報の作成が終了すると（ステップＳ１０：ＹＥＳ）、乗車履歴情報生成プログラム２８は終了する。
【００４３】
図７は、障害事例抽出システム２の具体的な構成を示したブロック図である。３０は通信制御装置であって、ネットワーク１０を介して、前述の乗車履歴管理システム１や、社局のセンターにあるサーバ（図示省略）との間でデータの授受を行なう。３１はＲＯＭやＲＡＭ等から構成されるメモリ、３２は演算装置であるＣＰＵ、３３および３５は例えばハードディスクから構成される記憶装置である。記憶装置３３には、後述する運賃計算障害事例が蓄積された運賃計算障害事例データベース（以下、「運賃計算障害事例ＤＢ」と記す。）３４が格納されている。記憶装置３５には、障害事例抽出プログラム３６、運賃計算シミュレータプログラム３７、運賃計算プログラム３８、運賃データ３９、運賃計算プログラム４０、運賃データ４１が格納されている。
【００４４】
障害事例抽出プログラム３６は、障害事例を抽出するための一連の動作を管理する基本プログラムである。運賃計算シミュレータプログラム３７は、運賃計算シミュレータにより運賃計算のシミュレーションを行なうためのプログラムである。運賃計算プログラム３８は、図１でも述べたように、障害に対する不具合を修正する前の運賃計算プログラムであり、運賃計算プログラム４０は、不具合修正後の運賃計算プログラムである。運賃データ３９は不具合修正前の運賃データであり、運賃データ４１は不具合修正後の運賃データである。運賃計算プログラム３８と運賃データ３９は、図１の運賃計算シミュレータ６を構成し、運賃計算プログラム４０と運賃データ４１は、図１の運賃計算シミュレータ７を構成する。
【００４５】
なお、ここでは便宜上、データベース３４を格納する記憶装置３３と、プログラム３６〜３８，４０およびデータ３９，４１を格納する記憶装置３５とを別々に設けたが、１つの記憶装置に上述したデータベースとプログラムおよびデータを格納してもよい。
【００４６】
以上の障害事例抽出システム２において、運賃計算シミュレータ６は、本発明における第１の運賃計算シミュレータを構成し、運賃計算シミュレータ７は、本発明における第２の運賃計算シミュレータを構成する。また、これらの運賃計算シミュレータ６，７は、本発明における計算処理実行手段および運賃計算手段を構成する。また、本発明における比較手段および抽出手段は、障害事例抽出プログラム３６の一部の機能として実現される。
【００４７】
図８は、障害事例抽出プログラム３６による運賃計算障害事例の抽出手順を示したフローチャートである。この障害事例抽出プログラム３６は、運賃誤収受などの障害があったことが判明し、その障害に対して不具合が修正されたプログラムやデータがリリースされた後に実行される。その処理においては、全ての乗車履歴情報に対して運賃計算のシミュレーションを行ない、運賃計算プログラムおよび運賃データの修正前バージョンと修正後バージョンを実行してそれぞれの運賃計算結果を出力し、双方の計算結果に差異がある場合に、その乗車履歴情報を障害事例として抽出する。以下、フローチャートに従って更に詳しく説明する。
【００４８】
障害事例抽出プログラム３６がスタートすると、最初に、全ての乗車履歴情報について処理が終了したか否かを判定する（ステップＳ２１）。この段階では、まだ全乗車履歴情報の処理は終了していないので（ステップＳ２１：ＮＯ）、ステップＳ２２へ進み、乗車履歴情報ＤＢ２５から乗車履歴情報５を１つ取り出す。そして、取り出した乗車履歴情報５を運賃計算シミュレータ６，７（図１）に入力し、運賃計算シミュレータプログラム３７（図７）により、運賃計算のシミュレーションを行う。
【００４９】
運賃計算シミュレータプログラム３７は、ステップＳ２３〜Ｓ２６の処理を実行する。ステップＳ２３では、乗車履歴情報５の駅名リスト（図４）が空か否かを判定する。最初は、駅名リストは空ではないので（ステップＳ２３：ＮＯ）、ステップＳ２４へ進み、駅名リストから駅名すなわち線区駅順コードを１つ取り出す。このとき取り出される線区駅順コードは、駅名リストに最初に記録されている駅、すなわち入場駅の線区駅順コードである。
【００５０】
次に、取り出した線区駅順コードを入力として、ステップＳ２５、ステップＳ２６で運賃計算プログラムを実行する。ステップＳ２５では、不具合修正前の運賃計算プログラム３８と運賃データ３９とを用いて運賃計算を行う。ステップＳ２６では、不具合修正後の運賃計算プログラム４０と運賃データ４１とを用いて運賃計算を行う。これらの運賃計算処理は並行して行われる。なお、初回は運賃計算の対象が入場駅であり、この時点ではまだ運賃が確定していないので、実際にはステップＳ２５、Ｓ２６での運賃計算の結果は０となる。なお、後述するように、運賃計算シミュレータ６，７は、単に運賃を算出するだけでなく、乗車媒体が実際に改札機に投入された場合に乗車媒体に書き込まれる媒体書込情報と同じ情報を生成する。
【００５１】
次に、ステップＳ２５で実行された不具合修正前の運賃計算結果と、ステップＳ２６で実行された不具合修正後の運賃計算結果とを比較して、双方の計算結果に差異があるか否かを判定する（ステップＳ２７）。計算結果に差異がなければ（ステップＳ２７：ＮＯ）、障害事例に該当しないと判断してステップＳ２３へ戻り、駅名リストが空か否かを判定し、空でなければ（ステップＳ２３：ＮＯ）、駅名リストから次の線区駅順コードを取り出す（ステップＳ２４）。そして、この線区駅順コードと、前回のシミュレーションで得られた媒体書込情報とを入力として、運賃計算シミュレータプログラム３７による運賃計算を実行する（ステップＳ２５、Ｓ２６）。この場合、媒体書込情報には入場駅の線区駅順コードが含まれているので、運賃計算シミュレータ６，７は、この入場駅の線区駅順コードと、今回の線区駅順コードとに基づいて運賃の計算を行う。
【００５２】
その後、ステップＳ２５、Ｓ２６での運賃計算結果に差異があるか否かを判定し（ステップＳ２７）、計算結果に差異がなければ（ステップＳ２７：ＮＯ）、障害事例に該当しないと判断してステップＳ２３へ戻り、上述した処理を繰り返す。一方、計算結果に差異がある場合は（ステップＳ２７：ＹＥＳ）、障害事例に該当すると判断してステップＳ２８へ移行し、乗車履歴情報と運賃計算結果に基づいて、運賃計算障害事例を作成する。
【００５３】
図９は、運賃計算障害事例８の一例を示している。運賃計算障害事例８には、乗車媒体のＩＤ、利用者の氏名・住所・電話番号等の利用者情報、乗車履歴、誤収受金額などが記録される。利用者情報は、ＩＤをもとにしてセンターのサーバから取得する。誤収受金額は、不具合修正前のシミュレーションで算出された運賃と、不具合修正後のシミュレーションで算出された運賃との差額である。
【００５４】
このようにして作成された運賃計算障害事例８は、図７における運賃計算障害事例ＤＢ３４に格納される（ステップＳ２９）。運賃計算障害事例８を格納した後は、ステップＳ２３へ戻って、駅名リストが空か否かを判定し、空でなければ（ステップＳ２３：ＮＯ）、ステップＳ２４以下の手順を前記と同じ要領で繰り返し実行する。
【００５５】
駅名リストにおける最後の駅、すなわち出場駅の線区駅順コードに対する処理が終了すると、ステップＳ２３において駅名リストは空となり（ステップＳ２３：ＹＥＳ）、ステップＳ２１へ移行して、全ての乗車履歴情報について処理が終了したか否かを判定する。処理が終了してなければ（ステップＳ２１：ＮＯ）、ステップＳ２２へ進み、乗車履歴情報ＤＢ２５から次の乗車履歴情報５を取り出す。そして、取り出した乗車履歴情報５に対して、上述した運賃計算のシミュレーションを行い（ステップＳ２３〜Ｓ２６）、計算結果に差異がなければ（ステップＳ２７：ＮＯ）、ステップＳ２３へ戻り、計算結果に差異があれば（ステップＳ２７：ＹＥＳ）、運賃計算障害事例８を作成し（ステップＳ２８）、運賃計算障害事例ＤＢ３４へ格納（ステップＳ２９）した後にステップＳ２３へ戻る処理を、駅名リストが空になるまで繰り返し実行する。そして、駅名リストが空になると（ステップＳ２３：ＹＥＳ）、全ての乗車履歴情報について処理が終了したか否かを判定し（ステップＳ２１）、終了してなければ（ステップＳ２１：ＮＯ）、乗車履歴情報ＤＢ２５から次の乗車履歴情報５を取り出して（ステップＳ２２）、ステップＳ２３以下の手順を前記と同じ要領で繰り返し実行する。
【００５６】
このようにして、乗車履歴情報ＤＢ２５から乗車履歴情報５を順次取り出して、シミュレータ６，７により運賃計算のシミュレーションを繰り返し行い、双方の計算結果に差異のある乗車履歴情報を運賃計算障害事例８として抽出し、運賃計算障害事例ＤＢ３４に蓄積してゆく。そして、乗車履歴情報ＤＢ２５の全乗車履歴情報についてシミュレーションが終了すると（ステップＳ２１：ＹＥＳ）、障害事例抽出プログラム３６は終了する。
【００５７】
以上のように、不具合修正前の運賃計算プログラム３８および運賃データ３９と、不具合修正後の運賃計算プログラム４０および運賃データ４１という２つのバージョンのソフトウェアを用いて、過去事例について運賃計算処理を実行し、それらの計算結果を比較して、計算結果に差異があるものを障害事例と判別することにより、今回発生した障害事例のみが自動的に抽出される。このため、過去の事例の中から該当する障害事例を迅速かつ容易に検索することができる。また、障害かどうかを判別する特別なパターン照合を必要とせずに、判別の自動化が容易に実現できる。
【００５８】
図１０は、運賃計算シミュレータ６，７で行われる処理を更に詳細に示した図である。ここでは、有効区間が乙駅−丙駅である定期券（プリペイドカード機能を有する複合券）を使用して、甲駅で入場し、乙駅で乗り継ぎ、丙駅で出場した場合の乗車履歴情報５０に対してシミュレーションを行う場合を例に挙げている。運賃計算シミュレータ６，７には、乗車履歴情報５０のほかに、初期状態媒体情報５２と定期券有効区間情報５３が入力される。初期状態媒体情報５２は、乗車媒体を有効なものと認識させて使用可能にするために必要な情報であって、乗車媒体の発売時に実際に媒体に記録される情報と同じ情報である。定期券有効区間情報５３は、使用した定期券の有効区間（ここでは乙駅−丙駅）を表す情報であって、乗車履歴情報におけるＩＤに基づいて、センターのカード情報データベース５１から取得する。この定期券有効区間情報５３には、有効区間における経由駅の線区駅順コードも含まれている。
【００５９】
運賃計算シミュレータ６，７は、上述した初期状態媒体情報５２や定期券有効区間情報５３、あるいは後述する媒体書込情報５７に基づいて乗車媒体情報５４を作成するとともに、乗車履歴情報５０に基づいて設置駅５５の設定を行う。そして、これらの乗車媒体情報５４および設置駅５５を運賃計算部５６に入力し、甲駅・乙駅・丙駅での改札機通過に対応させて、運賃計算プログラムを３回実行する。運賃計算部５６は、各回のプログラム実行ごとに、媒体書込情報５７と一件明細情報５８を出力する。以下、さらに詳細に説明する。
【００６０】
１回目のシミュレーションにおいては、乗車媒体情報５４は初期状態媒体情報５２と定期券有効区間情報５３とに基づいて作成され、乙駅−丙駅の区間が乗車媒体情報５４に記録される。また、設置駅５５には、乗車履歴情報５０の最初に記録されている甲駅（入場駅）が設定される。そして、この条件のもとに運賃計算部５６で運賃計算プログラムが実行され、その結果が媒体書込情報５７および一件明細情報５８として出力される。このときの媒体書込情報５７は、有効区間が乙駅−丙駅の定期券を甲駅の改札機に投入した場合に、甲駅の改札機で定期券に実際に書き込まれる情報（駅名、入場ビット、日時など）と同じ情報である。一件明細情報５８には、上記媒体書込情報のほか、定期券のＩＤ、精算金額、残額などが記録される。但し、１回目のシミュレーションでは精算金額がまだ確定していないので、一件明細情報５８に精算金額は記録されず、運賃計算結果５９も出力されない。
【００６１】
２回目のシミュレーションにおいては、乗車媒体情報５４が１回目のシミュレーションで生成された媒体書込情報５７により更新される。すなわち、入場駅として甲駅が追加される。また、設置駅５５には、乗車履歴情報５０の２番目の駅である乙駅（乗継駅）が設定される。そして、この条件のもとに運賃計算部５６で運賃計算プログラムが実行され、その結果が媒体書込情報５７および一件明細情報５８として出力される。このときの媒体書込情報５７は、甲駅の改札機を通った有効区間が乙駅−丙駅の定期券を乙駅の改札機に投入した場合に、乙駅の改札機で定期券に実際に書き込まれる情報（駅名、乗継ビット、日時など）と同じ情報である。一件明細情報５８には、上記乗車券書込情報のほか、定期券のＩＤ、精算金額、残額などが記録される。２回目のシミュレーションでは、甲駅−乙駅間が精算対象となり、運賃計算プログラムと運賃データとに基づいて精算金額が計算され、一件明細情報５８に記録される。運賃計算シミュレータ６，７は、一件明細情報５８の内容に基づき、運賃計算結果５９を出力する。
【００６２】
３回目のシミュレーションにおいては、乗車媒体情報５４が２回目のシミュレーションで生成された媒体書込情報５７により更新される。すなわち、乗継駅として乙駅が追加される。また、設置駅５５には、乗車履歴情報５０の３番目の駅である丙駅（出場駅）が設定される。そして、この条件のもとに運賃計算部５６で運賃計算プログラムが実行され、その結果が媒体書込情報５７および一件明細情報５８として出力される。このときの媒体書込情報５７は、甲駅および乙駅の改札機を通った有効区間が乙駅−丙駅の定期券を丙駅の改札機に投入した場合に、丙駅の改札機で定期券に実際に書き込まれる情報（駅名、乗継ビット、日時など）と同じ情報である。一件明細情報５８には、上記媒体書込情報のほか、定期券のＩＤ、精算金額、残額などが記録される。３回目のシミュレーションでは、甲駅−丙駅間が精算対象となり（但し、乙駅−丙駅間は定期券区間なので課金されない）、運賃計算プログラムと運賃データとに基づいて精算金額が計算され、一件明細情報５８に記録される。運賃計算シミュレータ６，７は、一件明細情報５８の内容に基づき、運賃計算結果５９を出力する。
【００６３】
以上のように、図１０の例では、初回のシミュレーション実行時に、入場駅（甲駅）について運賃計算のシミュレーションを行なって、当該入場駅で乗車媒体（定期券）に書き込まれる媒体書込情報５７を出力し、２回目以降のシミュレーション実行時に、前回のシミュレーションで得られた媒体書込情報５７と次の駅名とを入力として運賃計算のシミュレーションを行なっている。このように、乗車経路に従って順次運賃計算のシミュレーションを行ない、各回で得られた媒体書込情報５７を次のシミュレーションに反映させることにより、入場駅から出場駅までの各駅で投入される実際の乗車媒体の記録情報を簡単に再現することができる。このため、過去に改札機で実際に乗車媒体にエンコードした情報を必要とせずに運賃計算のシミュレーションを行なうことが可能となり、改札機から送信するデータの通信コストや送受信処理コスト、データベース容量を低減することができる。
【００６４】
図１１は、運賃誤収受が発生してから利用者に対する補償を行なうまでの一連の手順を示している。例えば、改札機の運賃計算プログラムや運賃データに不具合があり、３社線連絡定期券を使用してＰ鉄道の駅で入場してＱ鉄道の駅で出場した場合に、改札機での引き去り金額（精算金額）が１００円多いという障害が発生したとする（ステップＳ３１）。このような障害のあったことが判明すると、本障害の事例に対して引き去り金額を正しく算出することができるように、運賃計算プログラムや運賃データの改修を行なう（ステップＳ３２）。この改修により、３社線連絡定期券を使用してＰ鉄道の駅で入場してＱ鉄道の駅で出場したという事例に対しては、修正前の運賃計算プログラムおよび運賃データによる運賃計算結果と、修正後の運賃計算プログラムおよび運賃データによる運賃計算結果との間で、引き去り金額に１００円の差異が生じることになる。
【００６５】
プログラムやデータの改修が行なわれた後、本発明の運賃計算障害事例検索システムにより、過去の全ての乗車履歴情報を用いて運賃計算障害事例を検索する（ステップＳ３３）。すなわち、乗車履歴情報５が過去事例として蓄積されている乗車履歴情報ＤＢ２５から、乗車履歴情報５を順次取り出し、過去の全ての乗車履歴情報に対して、運賃計算シミュレータ６，７により運賃計算のシミュレーションを実行する。そして、双方の運賃計算結果の間で引き去り金額に１００円の差異がある事例を全て抽出し、これらを運賃計算障害事例８としてリストアップする（ステップＳ３４）。
【００６６】
リストアップされた運賃計算障害事例８においては、図９からわかるように、利用者情報から利用者を特定することができ、また損害額として誤収受金額も算出されているので、鉄道事業者から利用者に対して補償の措置がとられる（ステップＳ３５）。例えば、郵便や電子メールなどにより、利用者へ損害額弁済の通知が送られる。弁済の方法としては、駅の窓口での現金払いや口座振込のほか、乗車媒体への金額チャージなども考えられる。また、利用者への通知の方法も、郵便や電子メールに代えて、前掲の特許文献１に記載されているように、誤収受のあった乗車媒体のＩＤをセンターに登録しておき、乗車媒体が改札機に投入されたときに、窓口への持参を案内するような方法を採用してもよい。
【００６７】
本発明では、以上述べた以外にも種々の実施形態を採用することができる。例えば、上記実施形態で挙げた改札機や、精算機、窓口処理機のほか、券売機や定期券発行機などの駅務機器で運賃計算の障害が発生した場合にも、本発明を適用することができる。また、上記実施形態では、定期券にプリペイドカードの機能を持たせた複合券を例に挙げたが、本発明はプリペイドカード単体を用いた場合にも適用することができる。さらに、本発明の乗車媒体はプリペイド方式のものに限らず、銀行口座からの引き落しにより料金を徴収するポストペイド方式の乗車媒体であってもよい。また、乗車媒体は接触式でも非接触式でもよく、非接触式の場合は、カードに限らず、決済機能を有する携帯電話機のようなモバイル機器でもよい。
【００６８】
本発明は、上述した駅務システムに限らず、カードなどの取引媒体を用いて取引処理を行なうＰＯＳ（Point of Sales）システムにおいて料金計算の障害事例を検索する場合にも適用することができる。図１２は、この場合の料金計算障害事例検索システムの概略構成図を示している。このシステムでは、図１の改札機３がＰＯＳ端末機１０３に置き換わり、乗車履歴管理システム１が取引情報管理システム１０１に置き換わり、一件明細情報ＤＢ２４および乗車履歴情報ＤＢ２５が取引情報データベース（以下、「取引情報ＤＢ」と記す。）１２５に置き換わり、乗車履歴情報５が取引情報１０５に置き換わる。また、障害事例抽出システム１０２においては、図１の運賃計算シミュレータ６，７が料金計算シミュレータ１０６，１０７に置き換わり、運賃計算プログラム３８，４０が料金計算プログラム１３８，１４０に置き換わり、運賃データ３９，４１が料金データ１３９，１４１に置き換わる。また、障害事例１０８においては、図１の乗車履歴が取引内容に置き換わる。
【００６９】
図１２では、取引に基づいて図示しないカードリーダやバーコードスキャナからＰＯＳ端末機１０３に入力される情報が本発明における入力情報に相当し、取引情報ＤＢ１２５が本発明における蓄積手段に相当し、料金計算シミュレータ１０６，１０７が本発明における計算処理実行手段および料金計算手段に相当する。また、本発明における比較手段および抽出手段は、障害事例抽出プログラム（図示省略）の一部の機能として実現される。
【００７０】
図１２の料金計算障害事例検索システムで障害事例を抽出する原理は、基本的に図１の運賃計算障害事例検索システムの場合と同様である。取引情報管理システム１０１は、各店舗のＰＯＳ端末機１０３から送られてくる取引情報１０５を受信して、取引情報ＤＢ１２５に蓄積する。取引情報１０５は、ＰＯＳ端末機１０３で取引決済が行なわれるたびに生成される情報である。料金計算プログラムや料金データの不具合により料金の誤収受があったことが判明して該当事例を検索する場合は、障害事例抽出システム１０２を起動させ、取引情報ＤＢ１２５から取得した取引情報１０５をもとに、２つの料金計算シミュレータ１０６，１０７により、過去の全ての取引について料金計算のシミュレーションを行なう。料金計算シミュレータ１０６では、不具合修正前の料金計算プログラム１３８と料金データ１３９を用いた料金計算が行なわれ、料金計算シミュレータ１０７では、不具合修正後の料金計算プログラム１４０と料金データ１４１を用いた料金計算が行なわれる。そして、それぞれの料金計算シミュレータ１０６，１０７で得られた計算結果を比較し、計算結果に差異がある事例を料金計算障害事例１０８として抽出する。この障害事例１０８にも、利用者や誤収受金額などに関する情報が含まれており、これによって損害を受けた利用者や金額を特定することができる。
【００７１】
上記のような料金計算障害事例検索システムによれば、不具合修正前の料金計算プログラム１３８および料金データ１３９と、不具合修正後の料金計算プログラム１４０および料金データ１４１という２つのバージョンのソフトウェアを用いて、過去事例について料金計算処理を実行し、それらの計算結果を比較して、計算結果に差異があるものを障害事例と判別することにより、今回発生した障害事例のみが自動的に抽出される。このため、過去の事例の中から該当する障害事例を迅速かつ容易に検索することができる。また、障害かどうかを判別する特別なパターン照合を必要とせずに、判別の自動化が容易に実現できる。
【００７２】
図１２では、取引処理装置としてＰＯＳ端末機１０３を例に挙げたが、ＰＯＳ端末機１０３をカード式の自動販売機（図示省略）に置き換えても、上記と同様の機能を有する料金計算障害事例検索システムを実現することができる。
【００７３】
また、本発明の料金計算障害事例検索システムは、ＰＯＳシステムや自動販売機システムだけでなく、ホテルや病院などにおける料金精算システムにも適用することができる。
【００７４】
本発明は、上述した例のほかにも、計算処理全般に適用できる障害事例検索システムとして実現することができる。図１３はその一例であって、企業での経理処理の障害事例を検索するためのシステムを示している。図１３において、経理情報管理システム２０１は、各部門の経理処理用の端末コンピュータ２０３から送られてくる経理情報２０５を受信して、経理情報ＤＢ２２５に蓄積する。障害事例抽出システム２０２は、経理情報ＤＢ２２５から取得した経理情報２０５をもとに、２つの計算シミュレータ２０６，２０７により、過去の全ての経理情報２０５について計算のシミュレーションを行なう。計算シミュレータ２０６では、不具合修正前の計算プログラム２３８を用いた計算が行なわれ、計算シミュレータ２０７では、不具合修正後の計算プログラム２４０を用いた計算が行なわれる。そして、それぞれの計算シミュレータ２０６，２０７で得られた計算結果を比較し、計算結果に差異がある事例を計算障害事例２０８として抽出する。
【００７５】
図１３では、端末コンピュータ２０３に入力されるデータが本発明における入力情報に相当し、経理情報ＤＢ２２５が本発明における蓄積手段に相当し、計算シミュレータ２０６，２０７が本発明における計算処理実行手段に相当する。また、本発明における比較手段および抽出手段は、障害事例抽出プログラム（図示省略）の一部の機能として実現される。
【００７６】
上記のような障害事例検索システムによれば、不具合修正前の計算プログラム２３８と、不具合修正後の計算プログラム２４０という２つのバージョンのソフトウェアを用いて、過去事例について計算処理を実行し、それらの計算結果を比較して、計算結果に差異があるものを障害事例と判別することにより、今回発生した障害事例のみが自動的に抽出される。このため、過去の事例の中から該当する障害事例を迅速かつ容易に検索することができる。また、障害かどうかを判別する特別なパターン照合を必要とせずに、判別の自動化が容易に実現できる。
【００７７】
以上述べた実施形態では、いずれも金額の計算を行なう場合を例に挙げたが、本発明は、金額以外の各種データに対して計算処理を行なう装置において障害事例を検索する場合にも適用することができる。
【図面の簡単な説明】
【００７８】
【図１】本発明の実施形態に係る障害事例検索システムの概略構成図である。
【図２】乗車履歴管理システムの具体的な構成を示したブロック図である。
【図３】一件明細情報の具体的な内容を示した図である。
【図４】乗車履歴情報の具体的な内容を示した図である。
【図５】乗車履歴情報生成プログラムによる乗車履歴情報の作成手順を示したフローチャートである。
【図６】駅名リストの作成を説明する図である。
【図７】障害事例抽出システムの具体的な構成を示したブロック図である。
【図８】障害事例抽出プログラムによる運賃計算障害事例の抽出手順を示したフローチャートである。
【図９】運賃計算障害事例の一例を示した図である。
【図１０】運賃計算シミュレータで行われる処理を詳細に示した図である。
【図１１】運賃誤収受が発生してから利用者に対する補償を行なうまでの一連の手順を示す図である。
【図１２】本発明の他の実施形態に係る障害事例検索システムの概略構成図である。
【図１３】本発明の他の実施形態に係る障害事例検索システムの概略構成図である。
【符号の説明】
【００７９】
１  乗車履歴管理システム
２  障害事例抽出システム
３  改札機
４  一件明細情報
５  乗車履歴情報
６，７  運賃計算シミュレータ
８  運賃計算障害事例
２４  一件明細情報データベース
２５  乗車履歴情報データベース
３８，４０  運賃計算プログラム
３９，４１  運賃データ
５０  乗車履歴情報
５７  媒体書込情報
５８  一件明細情報
５９  運賃計算結果
１０１  取引情報管理システム
１０２  障害事例抽出システム
１０３  ＰＯＳ端末機
１０５  取引情報
１０６，１０７  料金計算シミュレータ
１０８  料金計算障害事例
１２５  取引情報データベース
２０１  経理情報管理システム
２０２  障害事例抽出システム
２０３  端末コンピュータ
２０５  経理情報
２０６，２０７  計算シミュレータ
２０８  計算障害事例
２２５  経理情報データベース
【図１】
2007272281.tif 000003
【図２】
2007272281.tif 000004
【図３】
2007272281.tif 000005
【図４】
2007272281.tif 000006
【図５】
2007272281.tif 000007
【図６】
2007272281.tif 000008
【図７】
2007272281.tif 000009
【図８】
2007272281.tif 000010
【図９】
2007272281.tif 000011
【図１０】
2007272281.tif 000012
【図１１】
2007272281.tif 000013
【図１２】
2007272281.tif 000014
【図１３】
2007272281.tif 000015