(57)【特許請求の範囲】
【請求項１】
組合せ認証装置と認証装置とサーバとを備える認証システムであって、
前記組合せ認証装置は、
予め定められた規則に従って、交通機関を利用するためのチケットの種類に基づいて前記チケットのリスクレベルを査定し、
前記リスクレベルが所定値以下のチケットのチケットＩＤ、リスクレベル及び査定理由をリストに含め、
前記サーバは、
前記組合せ認証装置から前記リストを受信し、
前記リストに含まれている第１チケットの認証処理の方法を、予め定められた規則に従って、前記第１チケットのリスクレベル及び査定理由に基づき、決定し、
前記認証処理の方法によって、前記認証装置に前記第１チケットの認証要求を行い、
前記認証要求を受けた前記認証装置は、認証を行う
ことを特徴とする認証システム。
【請求項２】
組合せ認証装置と認証装置とサーバとを備える認証システムであって、
前記組合せ認証装置は、
予め定められた規則に従って、交通機関を利用するためのチケットの認証媒体の種類に基づいて、前記チケットのリスクレベルを査定し、
前記リスクレベルが所定値以下のチケットのチケットＩＤ、リスクレベル及び査定理由をリストに含め、
前記サーバは、
前記組合せ認証装置から前記リストを受信し、
前記リストに含まれている第１チケットの認証処理の方法を、予め定められた規則に従って、前記第１チケットのリスクレベル及び査定理由に基づき、決定し、
前記認証処理の方法によって、前記認証装置に前記第１チケットの認証要求を行い、
前記認証要求を受けた前記認証装置は、認証を行う
ことを特徴とする認証システム。
【請求項３】
組合せ認証装置と認証装置とサーバとを備える認証システムであって、
前記組合せ認証装置は、
交通機関を利用するためのチケットを購入した個人の電子マネーの残高が一定額以上である場合に低いリスクレベルを査定し、
前記リスクレベルが所定値以下のチケットのチケットＩＤ、リスクレベル及び査定理由をリストに含め、
前記サーバは、
前記組合せ認証装置から前記リストを受信し、
前記リストに含まれている第１チケットの認証処理の方法を、予め定められた規則に従って、前記第１チケットのリスクレベル及び査定理由に基づき、決定し、
前記認証処理の方法によって、前記認証装置に前記第１チケットの認証要求を行い、
前記認証要求を受けた前記認証装置は、認証を行う
ことを特徴とする認証システム。
【請求項４】
組合せ認証装置と認証装置とサーバとを備える認証システムであって、
前記組合せ認証装置は、
交通機関を利用するためのチケットが定期券である場合に低いリスクレベルを査定し、
前記リスクレベルが所定値以下のチケットのチケットＩＤ、リスクレベル及び査定理由をリストに含め、
前記サーバは、
前記組合せ認証装置から前記リストを受信し、
前記リストに含まれている第１チケットの認証処理の方法を、予め定められた規則に従って、前記第１チケットのリスクレベル及び査定理由に基づき、決定し、
前記認証処理の方法によって、前記認証装置に前記第１チケットの認証要求を行い、
前記認証要求を受けた前記認証装置は、認証を行う
ことを特徴とする認証システム。
【請求項５】
組合せ認証装置と認証装置とサーバとを備える認証システムであって、
前記組合せ認証装置は、
交通機関を利用するためのチケットの金額が一定額以上の場合に高いリスクレベルを査定し、
前記リスクレベルが所定値以下のチケットのチケットＩＤ、リスクレベル及び査定理由をリストに含め、
前記サーバは、
前記組合せ認証装置から前記リストを受信し、
前記リストに含まれている第１チケットの認証処理の方法を、予め定められた規則に従って、前記第１チケットのリスクレベル及び査定理由に基づき、決定し、
前記認証処理の方法によって、前記認証装置に前記第１チケットの認証要求を行い、  前記認証要求を受けた前記認証装置は、認証を行う
ことを特徴とする認証システム。
【請求項６】
組合せ認証装置と認証装置とサーバとを備える認証システムであって、
前記組合せ認証装置は、
交通機関を利用するためのチケットの購入及び利用の履歴データにおいて予め設定されたパターンが存在する場合に高いリスクレベルを査定し、
前記リスクレベルが所定値以下のチケットのチケットＩＤ、リスクレベル及び査定理由をリストに含め、
前記サーバは、
前記組合せ認証装置から前記リストを受信し、
前記リストに含まれている第１チケットの認証処理の方法を、予め定められた規則に従って、前記第１チケットのリスクレベル及び査定理由に基づき、決定し、
前記認証処理の方法によって、前記認証装置に前記第１チケットの認証要求を行い、
前記認証要求を受けた前記認証装置は、認証を行う
ことを特徴とする認証システム。
【請求項７】
組合せ認証装置と認証装置とサーバとを備える認証システムにおける認証方法であって、
前記組合せ認証装置が、
予め定められた規則に従って、交通機関を利用するためのチケットの種類に基づいて前記チケットのリスクレベルを査定し、
前記リスクレベルが所定値以下のチケットのチケットＩＤ、リスクレベル及び査定理由をリストに含め、
前記サーバが、
前記組合せ認証装置から前記リストを受信し、
前記リストに含まれている第１チケットの認証処理の方法を、予め定められた規則に従って、前記第１チケットのリスクレベル及び査定理由に基づき、決定し、
前記認証処理の方法によって、前記認証装置に前記第１チケットの認証要求を行い、
前記認証要求を受けた前記認証装置が、認証を行う
ことを特徴とする認証方法。
【請求項８】
組合せ認証装置と認証装置とサーバとを備える認証システムにおける認証方法であって、
前記組合せ認証装置が、
予め定められた規則に従って、交通機関を利用するためのチケットの認証媒体の種類に基づいて、前記チケットのリスクレベルを査定し、
前記リスクレベルが所定値以下のチケットのチケットＩＤ、リスクレベル及び査定理由をリストに含め、
前記サーバが、
前記組合せ認証装置から前記リストを受信し、
前記リストに含まれている第１チケットの認証処理の方法を、予め定められた規則に従って、前記第１チケットのリスクレベル及び査定理由に基づき、決定し、
前記認証処理の方法によって、前記認証装置に前記第１チケットの認証要求を行い、
前記認証要求を受けた前記認証装置が、認証を行う
ことを特徴とする認証方法。
【請求項９】
組合せ認証装置と認証装置とサーバとを備える認証システムにおける認証方法であって、
前記組合せ認証装置が、
交通機関を利用するためのチケットを購入した個人の電子マネーの残高が一定額以上である場合に低いリスクレベルを査定し、
前記リスクレベルが所定値以下のチケットのチケットＩＤ、リスクレベル及び査定理由をリストに含め、
前記サーバが、
前記組合せ認証装置から前記リストを受信し、
前記リストに含まれている第１チケットの認証処理の方法を、予め定められた規則に従って、前記第１チケットのリスクレベル及び査定理由に基づき、決定し、
前記認証処理の方法によって、前記認証装置に前記第１チケットの認証要求を行い、
前記認証要求を受けた前記認証装置が、認証を行う
ことを特徴とする認証方法。
【請求項１０】
組合せ認証装置と認証装置とサーバとを備える認証システムにおける認証方法であって、
前記組合せ認証装置が、
交通機関を利用するためのチケットが定期券である場合に低いリスクレベルを査定し、
前記リスクレベルが所定値以下のチケットのチケットＩＤ、リスクレベル及び査定理由をリストに含め、
前記サーバが、
前記組合せ認証装置から前記リストを受信し、
前記リストに含まれている第１チケットの認証処理の方法を、予め定められた規則に従って、前記第１チケットのリスクレベル及び査定理由に基づき、決定し、
前記認証処理の方法によって、前記認証装置に前記第１チケットの認証要求を行い、
前記認証要求を受けた前記認証装置が、認証を行う
ことを特徴とする認証方法。
【請求項１１】
組合せ認証装置と認証装置とサーバとを備える認証システムにおける認証方法であって、
前記組合せ認証装置が、
交通機関を利用するためのチケットの金額が一定額以上の場合に高いリスクレベルを査定し、
前記リスクレベルが所定値以下のチケットのチケットＩＤ、リスクレベル及び査定理由をリストに含め、
前記サーバが、
前記組合せ認証装置から前記リストを受信し、
前記リストに含まれている第１チケットの認証処理の方法を、予め定められた規則に従って、前記第１チケットのリスクレベル及び査定理由に基づき、決定し、
前記認証処理の方法によって、前記認証装置に前記第１チケットの認証要求を行い、
前記認証要求を受けた前記認証装置が、認証を行う
ことを特徴とする認証方法。
【請求項１２】
組合せ認証装置と認証装置とサーバとを備える認証システムにおける認証方法であって、
前記組合せ認証装置が、
交通機関を利用するためのチケットの購入及び利用の履歴データにおいて予め設定されたパターンが存在する場合に、高いリスクレベルを査定し、
前記リスクレベルが所定値以下のチケットのチケットＩＤ、リスクレベル及び査定理由をリストに含め、
前記サーバが、
前記組合せ認証装置から前記リストを受信し、
前記リストに含まれている第１チケットの認証処理の方法を、予め定められた規則に従って、前記第１チケットのリスクレベル及び査定理由に基づき、決定し、
前記認証処理の方法によって、前記認証装置に前記第１チケットの認証要求を行い、
前記認証要求を受けた前記認証装置が、認証を行う
ことを特徴とする認証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
駅務機器における認証方法、認証装置及び認証システムに関する。
【背景技術】
【０００２】
近年、ネットワーク技術や仮想化技術の発展に伴い、クラウドコンピューティングやシンクライアント型の業務システムが普及しつつある。同様に、鉄道などの公共交通機関において、自動改札機や券売機などの駅務機器をシンクライアント型で実現することが考えられる。本構成では例えば、ＩＣカードからのデータの読み取りのみをクライアント側の駅務機器で行い、その他の処理は全てサーバ側で行う。シンクライアント型の自動改札機においては、通勤ラッシュ時でも改札で混雑しないようにするために高速な処理を実現することや、不正な乗車を防ぐためにセキュアな認証処理を実現することが重要である。
【０００３】
シンクライアント型の自動改札機を実現するための技術の一つとして、駅務機器が担う様々な処理をサーバ側で行う方法がある（例えば特許文献１参照）。
【０００４】
一方、セキュアな電子チケットを実現するための技術の一つとして、ＩＣカード固有情報とチケット情報を用いて認証情報を作成・照合する方法がある（例えば特許文献２）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１２−９４０５３号公報
【特許文献２】特開２００７−７９９１５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上記特許文献１はサーバ側で改札処理を行う仕組みを、特許文献２は電子チケットの安全性および信頼性を向上する仕組みを、それぞれ提供するものであった。
【０００７】
しかしながら特許文献１の方法では、セキュリティを向上するために認証処理を追加すると、処理が遅くなるという課題がある。
【０００８】
また特許文献２の方法では、サーバ側で認証処理を行う方法については考慮されておらず、また高速な処理を実現することが難しいという課題がある。
【０００９】
本発明は上記課題を解決するためになされたもので、その目的は、高速な改札処理と、セキュアな認証処理を両立できることを特徴とする、鉄道などの公共交通機関の自動改札機などの機器において認証処理を行う方法および装置を提供することである。
【課題を解決するための手段】
【００１０】
上記の目的を達成するために、本発明によれば、交通機関を利用するための電子チケットにおいて、
電子チケット利用前に査定したリスクに応じてリストを作成する第１の手段と、
前記第１の手段で作成したリストを用いて改札入場時に査定したリスクに応じて認証処理を行う第２の手段と、
前記第１の手段で作成したリストを用いて改札出場時に査定したリスクに応じて認証処理を行う第３の手段を備えることができる。
【発明の効果】
【００１１】
本発明によれば、駅務機器において、高速な改札処理と、セキュアな認証処理を両立して行うことができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施例のシステム構成例を示す図である。
【図２】駅サーバ１０４０のハードウェア構成例を示す図である。
【図３】組合せ認証サーバ１０６０のハードウェア構成例を示す図である。
【図４】登録処理プログラム３０７０の処理例を示すフローチャートである。
【図５】リスト配信プログラム３０８０の処理例を示すフローチャートである。
【図６】入場処理プログラム２０７０の在来線列車の改札の場合の処理例を示すフローチャートである。
【図７】入場処理プログラム２０７０の特急列車の改札の場合の処理例を示すフローチャートである。
【図８】出場処理プログラム２０８０の処理例を示すフローチャートである。
【図９】認証要求プログラム３０９０の処理例を示すフローチャートである。
【図１０】ホワイトリストテーブル２０９０、３１２０の構成例を示す図である。
【図１１】ブラックリストテーブル２１００、３１３０の構成例を示す図である。
【図１２】認証サーバリストテーブル３１００の構成例を示す図である。
【図１３】対応付けテーブル３１１０の構成例を示す図である。
【図１４】駅員操作端末の画面例を示す図である。
【発明を実施するための形態】
【００１３】
以下、本発明における実施例について、図面を参照しながら詳細に説明する。
【００１４】
図１は、本実施例のシステム構成例を示すブロック図である。自動改札機、券売機、駅員操作端末などの複数の駅務機器１０２０は、ネットワーク１０３０を経由して、駅サーバ１０４０に接続する。駅務機器１０２０は、交通ＩＣカードやクレジットカードなどの媒体１０１０を識別し、データの読み取りや書き込みを行うことができる。媒体には、指紋、指静脈、目の網膜や虹彩などの生体も含まれる。複数の駅サーバ１０４０は、ネットワーク１０５０を経由して、組合せ認証サーバ１０６０、個人認証サーバ１０７０、媒体認証サーバ１０８０、チケット認証サーバ１０９０に接続する。個人認証サーバ１０７０は、例えば利用者の氏名・性別・年齢などの属性情報を管理する。また事前に預け入れてあるＳＦ（Ｓｔｏｒｅｄ  Ｆａｒｅ）残高も管理する。媒体認証サーバ１０８０は、例えば交通ＩＣカードの発行元やステータス（活性・非活性など）を管理する。チケット認証サーバ１０９０は、例えば電子チケット（乗車券）の発行元やステータス（発行前、発行、入場、出場、破棄など）を管理する。また、上記以外に例えばクレジットカード会社などの鉄道会社以外の会社が発行する媒体の与信・認証を行う認証サーバや、生体情報の管理・認証を行う認証サーバを接続しても良い。組合せ認証サーバ１０６０は、個人・媒体・チケットの組合せを管理し、該組合せが正しいか否かの認証を行う。
【００１５】
ここで、本実施例では改札通過時の処理を高速化するために、駅サーバを各駅に、組合せ認証サーバをセンタに配置することを想定している。しかしながらこれに限定されるものではなく、どちらかのサーバに機能を集約して、駅またはセンタに配置しても良い。また、駅サーバは１駅に１台に限定されるものではなく、大規模駅では１駅に複数台のサーバを配置したり、小規模駅では複数駅に１台のサーバを配置したりしても良い。
【００１６】
本構成は、例えば媒体１０１０をＩＣカードで、駅務機器１０２０と駅サーバ１０４０と組合せ認証サーバ１０６０と個人認証サーバ１０７０と媒体認証サーバ１０８０とチケット認証サーバ１０９０をパーソナルコンピュータやワークステーション等の計算機で、ネットワーク１０３０、１０５０をＥｔｈｅｒｎｅｔ（登録商標）でそれぞれ構成することにより実現できる。
【００１７】
図２は、駅サーバ１０４０のハードウェア構成例を示す図である。２０１０は、ハードウェアの制御とプログラムの実行処理を行う主制御部である。２０２０は、システム管理者からのプログラム実行開始指示や中止指示等の入力を行う入力部である。２０３０は、プログラムの実行状態等の出力を行う出力部である。２０４０は、他の計算機とのデータ交換を行う通信処理部である。２０５０は、プログラムやデータの読み出し、記録を行う記憶管理部である。２０６０は上記各部間のデータ交換を行う通信部である。記憶管理部２０５０には、入場処理プログラム２０７０、出場処理プログラム２０８０、ホワイトリストテーブル２０９０、ブラックリストテーブル２１００が格納される。
【００１８】
図３は、組合せ認証サーバ１０６０のハードウェア構成例を示す図である。３０１０は、ハードウェアの制御とプログラムの実行処理を行う主制御部である。３０２０は、システム管理者からのプログラム実行開始指示や中止指示等の入力を行う入力部である。３０３０は、プログラムの実行状態等の出力を行う出力部である。３０４０は、他の計算機とのデータ交換を行う通信処理部である。３０５０は、プログラムやデータの読み出し、記録を行う記憶管理部である。３０６０は上記各部間のデータ交換を行う通信部である。記憶管理部３０５０には、登録処理プログラム３０７０、リスト配信プログラム３０８０、認証要求プログラム３０９０、認証サーバリストテーブル３１００、対応付けテーブル３１１０、ホワイトリストテーブル３１２０、ブラックリストテーブル３１３０が格納される。
【００１９】
上記構成は、例えば、主制御部２０１０、３０１０をＣＰＵで、入力部２０２０、３０２０をキーボードで、出力部２０３０、３０３０を液晶ディスプレイで、通信処理部２０４０、３０４０をＥｔｈｅｒｎｅｔや無線通信で、記憶管理部２０５０、３０５０をハードディスクやフラッシュメモリで、通信部２０６０、３０６０をＢｕｓで実現することにより構成可能である。また入力部と出力部をタッチパネルで実現することにより構成することも可能である。
【００２０】
続いて、登録処理プログラム３０７０の処理例を、図４のフローチャートを用いて説明する。本プログラムは、利用者が券売機などの駅務機器を用いてチケットを購入する時に実行するものとする。あるいは、交通ＩＣカード機能付きの携帯電話などを用いてチケットを購入する時に実行するものとする。
【００２１】
最初に、個人認証サーバと媒体認証サーバに対して認証要求を行い、正当な利用者、かつ正当な媒体であることを認証し、更に個人・媒体・チケットの組合せの妥当性を確認する組合せ認証処理を行う（ステップ４０１０）。媒体認証については、媒体の種類に応じてどの認証サーバに認証要求を送信するかを判断するために、認証サーバリストテーブルを読み込む。図１２に、認証サーバリストテーブルの構成例を示す。本テーブルは、媒体種別１２０１０、認証サーバアドレス１２０２０からなる行のリストである。媒体種別には、交通ＩＣカード、廉価タグ、クレジットカード、生体（指静脈）、生体（虹彩）などの媒体種別を登録できる。認証サーバアドレスには、該媒体種別の認証処理を行うことが可能なサーバのＩＰアドレスや接続プロトコル、インタフェース情報などを登録できる。組合せ認証は、例えば大人が利用する媒体に小人運賃のチケットを割り当てようとしている場合、認証失敗と判定する。個別認証および組合せ認証が成功であれば、利用者が指定したチケットの購入処理を行う（ステップ４０２０）。例えば、チケット認証サーバに対してチケット購入要求を行い、チケットが確保できたら、個人認証サーバに対して該チケット料金の精算要求を行い、チケット購入を完了する。チケット購入処理が完了したら、対応付けテーブルへの登録を行う（ステップ４０３０）。
【００２２】
図１３に、対応付けテーブルの構成例を示す。本テーブルは、ユーザＩＤ１３０１０、媒体ＩＤ１３０２０、チケットＩＤ１３０３０、リスト作成フラグ１３０４０、利用日時１３０５０、属性情報１３０６０、リスク査定・理由１３０７０、認証情報１３０８０からなる行のリストである。リスト作成フラグは、ホワイトリストを作成済みか否かを判別するためのフラグであり、作成済みであれば１を、そうでなければ０を設定する。利用日時は、チケットの利用日時（例えば乗車する列車の発車日時）を設定する。属性情報は、個人認証に関連する属性（例えば年齢、ＳＦ残高、過去の利用履歴など）、媒体認証に関連する属性（例えば媒体種別、媒体の発行元、媒体の発行年、最終利用日時など）、チケット認証に関連する属性（例えばチケット発行元、発行日時、チケット種別、チケット金額など）を設定する。認証情報は、現在の認証ステータス（例えば発券時の認証済、入場時の認証済、認証失敗など）を設定する。本ステップでは、ユーザＩＤ、媒体ＩＤ、チケットＩＤ、利用日時、属性情報の値をそれぞれ設定し、リスト作成フラグには０を設定し、認証情報には発券時の認証済を設定する。ステップ４０３０が終了するか、ステップ４０１０で個別認証あるいは組合せ認証が失敗であれば、該処理結果を駅サーバに送信し（ステップ４０４０）、処理を終了する。
【００２３】
すなわち、組合せ認証装置１０６０は、交通機関を利用するための電子チケットに関する電子チケット情報に基づいて、リスクを査定し、前記リスクを含めたリストを作成する登録処理部（登録処理プログラム３０７０）と、登録処理部が作成したリストを用いて改札入場の際に査定したリスクに応じて認証要求を行い、登録処理部が作成したリストを用いて改札出場の際に査定したリスクに応じて認証要求を行う認証要求部（認証要求プログラム３０９０）と、を備える。認証要求を受けた認証装置（個人認証サーバ１０７０、媒体認証サーバ１０８０、チケット認証サーバ１０９０）は、認証を行う認証部を備える。
【００２４】
また、電子チケット情報とは、電子チケットの金額又は電子チケットの種類であり、登録処理部は、電子チケットの金額又は電子チケットの種類に応じてリスクレベルを査定しても良い。
【００２５】
更に、電子チケットの金額とは、電子チケットに関する電子マネーの残高であり、電子チケットの種類とは、定期券の内容であり、登録処理部は、電子マネーの残高又は、定期券の内容に基づいて、リスクレベルを査定しても良い。
【００２６】
また、登録処理部は、電子チケットの利用履歴データを記憶し、利用履歴データの内容に応じてリスクレベルを査定しても良い。
【００２７】
更に、登録処理部は、利用履歴データに記憶された電子チケットの購入時刻を取得し、購入時刻から一定時間以内に改札を入場する場合はリスクレベルが小さいと査定しても良い。
【００２８】
続いて、リスト配信プログラム３０８０の処理例を、図５のフローチャートを用いて説明する。本プログラムは、登録処理プログラムの実行終了後に、非同期で（例えば一定時間ごとに）実行するものとする。
【００２９】
最初に、対応付けテーブルを１レコードずつ順に読み込む（ステップ５０１０）。該テーブルに次レコードがあれば（ステップ５０２０）、該レコードの利用日時とリスト作成フラグを調べる（ステップ５０３０）。該レコードのリスト作成フラグが０で、かつ利用日時が現在日時から一定時間以内であれば、該チケット利用のリスクを査定し、リスク査定・理由１３０７０の列に該結果および査定日時を設定する（ステップ５０４０）。ここで、リスクの査定方法としては、例えば以下のような基準でリスクレベルを判定するものとする。
【００３０】
（１）チケット金額が一定額以上の場合、不正乗車された時のリスクが高いと判定する。
（２）チケット種別が新幹線や特急券の場合、不正乗車された時のリスクが高いと判定する。
（３）媒体の種類がセキュアな媒体や生体の場合、偽造されるリスクが低いと判定する。逆にセキュアでない廉価なタグ等の場合、偽造されるリスクが高いと判定する。
（４）利用者のＳＦ残高が一定額以上、あるいは定期券を保有している場合、乗車運賃を取りはぐれた時のリスクが低いと判定する。
（５）利用者のチケット購入・利用の過去履歴データから、不審であったり通常は稀であったりするパターンでチケット購入・利用を行っている（例えば購入してすぐ払い戻す行為を複数の駅で何回も行っている等）場合、チケット不正利用のリスクが高いと判定する。
【００３１】
リスクを査定した結果、リスクが一定レベルよりも小さいと判定された場合（ステップ５０５０）、ホワイトリストテーブルに該レコードの情報を登録する。図１０に、ホワイトリストテーブルの構成例を示す。本テーブルは、ユーザＩＤ１００１０、媒体ＩＤ１００２０、チケットＩＤ１００３０、リスク査定・理由１００４０、属性情報１００５０からなる行のリストである。登録後、ステップ５０２０に戻り次レコードがあるか否かを調べる。ステップ５０３０で該レコードのリスト作成フラグが１、または利用日時が現在日付から一定時間以内でない場合は、ステップ５０２０に戻る。またステップ５０５０でリスクが一定レベルよりも小さいと判定されなかった場合も、ステップ５０２０に戻る。ステップ５０２０で次レコードが無くなったら、作成したホワイトリストテーブルを駅サーバに送信し（ステップ５０７０）、対応付けテーブルの認証情報にホワイトリスト送信済を設定し、処理を終了する。送信先となる駅サーバは、例えば在来線列車の乗車チケットであれば出場駅の駅サーバへ送信し、特急列車の乗車チケットであれば入場駅・出場駅の駅サーバへ送信する。あるいは該乗車チケットで乗り換えの発生する駅や、途中下車可能な全ての駅の駅サーバへ送信しても良い。
【００３２】
続いて、認証要求プログラム３０９０の処理例を、図９のフローチャートを用いて説明する。本プログラムは、改札入場時や出場時に、駅サーバからの認証要求に応じて実行するものとする。
【００３３】
最初に、個人認証サーバと媒体認証サーバとチケット認証サーバに対して認証要求を行い、正当な利用者、かつ正当な媒体、かつ正当なチケットであることを認証し、更に個人・媒体・チケットの組合せの妥当性を確認する組合せ認証処理を行う（ステップ９０１０）。媒体認証については、媒体の種類に応じてどの認証サーバに認証要求を送信するかを判断するために、認証サーバリストテーブルを読み込む。個別認証および組合せ認証が成功であれば、処理結果を駅サーバに送信し（ステップ９０４０）、認証結果を対応付けテーブルの認証情報に登録し、処理を終了する。認証が失敗であり、該要求元が在来線改札の入場処理プログラムであれば（ステップ９０２０）、ブラックリストテーブルを作成し、出場駅候補の駅サーバに送信する（ステップ９０３０）。図１１に、ブラックリストテーブルの構成例を示す。本テーブルは、ユーザＩＤ１１０１０、媒体ＩＤ１１０２０、チケットＩＤ１１０３０からなる行のリストである。出場駅候補の抽出は、例えば乗車チケットの出場駅や乗り換え駅、通過駅などから抽出し、該駅の駅サーバへ送信する。あるいは、該利用者の過去のチケット利用履歴データから出場駅を予測して、該駅の周辺の駅サーバのみに送信しても良い。あるいは、全ての駅サーバへブラックリストテーブルを送信しても良い。ブラックリストテーブルの送信を完了、またはステップ９０２０で要求元が在来線改札の入場処理プログラム以外であれば、処理結果を駅サーバに送信し（ステップ９０４０）、認証結果を対応付けテーブルの認証情報に登録した後、処理を終了する。
【００３４】
続いて、在来線列車の改札入場時の駅サーバの入場処理プログラムの処理例を、図６のフローチャートを用いて説明する。在来線列車の場合、特急列車に比べて運賃が比較的低額のため、本実施例の入場処理ではリスクレベルに応じた認証処理を省略するものとする。本処理は、自動改札機などの駅務機器がＩＣカードなどの利用者の保有する媒体を認識した後、自動改札機から駅サーバに対して改札内への入場判定を要求するタイミングで実行するものとする。
【００３５】
最初に、ブラックリストテーブルに該当するＩＤが登録されているか否かを調べる（ステップ６０１０）。ブラックリストテーブルは、あらかじめ組合せ認証サーバから送信されているものとする。ここで、調べるＩＤは例えば媒体から読み取った媒体ＩＤを用いる。あるいは、媒体の記憶領域内に個人ＩＤやチケットＩＤを記憶しておき、該ＩＤを読み取って用いても良い。ブラックリストテーブルに該当するＩＤが登録されていれば、改札機に対して判定ＮＧを送信し（ステップ６０３０）、処理を終了する。ブラックリストテーブルに該当するＩＤが登録されていなければ、改札機に対して判定ＯＫを送信する（ステップ６０２０）。改札機は送信された判定結果に応じて、例えば判定ＯＫであればゲート開、判定ＮＧであればゲート閉の動作を行う。送信後、組合せ認証サーバの認証要求プログラムを呼び出し（ステップ６０４０）、処理を終了する。
【００３６】
続いて、特急列車の改札入場時の駅サーバの処理を、図７のフローチャートを用いて説明する。特急列車の場合、在来線列車に比べて運賃が比較的高額のため、入場処理でも基本的にリスクレベルに応じた認証処理を行うものとする。本処理は、自動改札機などの駅務機器がＩＣカードなどの利用者の保有する媒体を認識した後、自動改札機から駅サーバに対して改札内への入場判定を要求するタイミングで実行するものとする。
【００３７】
最初に、ブラックリストテーブルに該当するＩＤが登録されているか否かを調べる（ステップ７０１０）。ブラックリストテーブルは、あらかじめ組合せ認証サーバから送信されているものとする。ここで、調べるＩＤは例えば媒体から読み取った媒体ＩＤを用いる。あるいは、媒体の記憶領域内に個人ＩＤやチケットＩＤを記憶しておき、該ＩＤを読み取って用いても良い。ブラックリストに該当するＩＤが登録されていれば、改札機に対して判定ＮＧを送信し（ステップ７０３０）、処理を終了する。ブラックリストに該当するＩＤが登録されていなければ、次にホワイトリストテーブルに該当するＩＤが登録されており、かつ該レコード中の査定日時が現在日時から一定時間以内であるか否かを調べる（ステップ７０２０）。ホワイトリストテーブルは、あらかじめ組合せ認証サーバから送信されているものとする。査定日時から一定時間以上経過していれば再度リスク査定を行うことにより、セキュリティを向上できる。ステップ７０２０に該当するならば、リスクに応じた認証処理を実行し、該結果を改札機に送信（ステップ７０６０）し、認証結果を組合せ認証サーバの対応付けテーブルの認証情報に登録した後、処理を終了する。例えば、セキュアな媒体を利用しておりリスクが小さいと査定されている場合、媒体認証を省略し、個人認証とチケット認証のみを行う。あるいは、リスクが小さければ入場時は全ての認証処理を省略しても良い。ステップ７０２０に該当しなければ、該チケット利用のリスクを査定する（ステップ７０４０）。ここで、リスクの査定方法としては、例えば前記ステップ５０４０に記載した（１）〜（５）の方法に加えて、以下のような基準でリスクを判定するものとする。
【００３８】
（６）入場日時が、チケット購入日時から一定時間以内の場合、チケット偽造のリスクが低いと判定する。
【００３９】
リスクを査定した結果、リスクが一定レベルよりも小さいと判定された場合（ステップ７０５０）、リスクに応じた認証処理を実行し、該結果を改札機に送信（ステップ７０６０）した後、処理を終了する。リスクが一定レベルよりも小さくないと判定された場合は、組合せ認証サーバの認証要求プログラムを呼び出し、該認証結果を改札機に送信して（ステップ７０７０）、処理を終了する。改札機は送信された判定結果に応じて、例えば判定ＯＫであればゲート開、判定ＮＧであればゲート閉の動作を行う。
【００４０】
続いて、改札出場時の駅サーバの処理を、図８のフローチャートを用いて説明する。本処理は、自動改札機などの駅務機器がＩＣカードなどの利用者の保有する媒体を認識した後、自動改札機から駅サーバに対して改札外への出場判定を要求するタイミングで実行するものとする。
【００４１】
最初に、ブラックリストテーブルに該当するＩＤが登録されているか否かを調べる（ステップ８０１０）。ブラックリストテーブルは、あらかじめ組合せ認証サーバから送信されているものとする。ここで、調べるＩＤは例えば媒体から読み取った媒体ＩＤを用いる。あるいは、媒体の記憶領域内に個人ＩＤやチケットＩＤを記憶しておき、該ＩＤを読み取って用いても良い。ブラックリストに該当するＩＤが登録されていれば、改札機に対して判定ＮＧを送信し（ステップ８０３０）、処理を終了する。ブラックリストに該当するＩＤが登録されていなければ、次にホワイトリストテーブルに該当するＩＤが登録されており、かつ該レコード中の査定日時が現在日時から一定時間以内であるか否かを調べる（ステップ８０２０）。ホワイトリストテーブルは、あらかじめ組合せ認証サーバから送信されているものとする。査定日時から一定時間以上経過していれば再度リスク査定を行うことにより、セキュリティを向上できる。また査定日時に該チケット区間の平均乗車時間を加えて、該時間が現在日時から一定時間以内であるか否かを調べても良い。
【００４２】
ステップ８０２０に該当するならば、リスクに応じた認証処理を実行し、該結果を改札機に送信（ステップ８０６０）し、認証結果を組合せ認証サーバの対応付けテーブルの認証情報に登録した後、処理を終了する。例えば、チケット金額が少額のためリスクが小さいと査定されている場合、チケット認証を省略し、駅サーバで運賃計算を行って該運賃が該チケット金額以下であれば認証成功とする。ステップ８０２０に該当しなければ、該チケット利用のリスクを査定する（ステップ８０４０）。ここで、リスクの査定方法としては、例えば前記ステップ５０４０に記載した（１）〜（５）の方法を用いてリスクを判定するものとする。リスクを査定した結果、リスクが一定レベルよりも小さいと判定された場合（ステップ８０５０）、リスクに応じた認証処理を実行し、該結果を改札機に送信（ステップ８０６０）した後、処理を終了する。リスクが一定レベルよりも小さくないと判定された場合は、組合せ認証サーバの認証要求プログラムを呼び出し、該認証結果を改札機に送信して（ステップ８０７０）、処理を終了する。改札機は送信された判定結果に応じて、例えば判定ＯＫであればゲート開、判定ＮＧであればゲート閉の動作を行う。
【００４３】
続いて、図１４に駅員操作端末の画面例を示す。本画面は各ユーザＩＤ・媒体ＩＤ・チケットＩＤに対するリスク査定・理由や認証情報のリスト１４０１０、キーワードを指定して特定のレコードを検索するためのインタフェース１４０２０、ユーザ情報１４０３０、媒体情報１４０４０、チケット情報１４０５０から構成される。リスト１４０１０上の特定のレコードを指定すると、該レコードのユーザＩＤ、媒体ＩＤ、チケットＩＤに対応する属性情報を１４０３０、１４０４０、１４０５０に表示する。本画面は、駅員が操作する駅務機器１０２０が、組合せ認証サーバ１０６０上の対応付けテーブルを参照することにより表示できる。駅員は本画面を用いて、特定の利用者のチケット利用状態などを確認することができる。
【００４４】
以上、本実施例では改札入場時と改札出場時にリスク査定と認証処理を行う場合の処理例について説明した。しかしながらこれに限定されるものではなく、別の駅務機器（例えば乗車列車中の車掌携帯端末）を用いてリスク査定と認証処理を行うようにしても良い。あるいは、改札処理を高速化するために、改札入場時は認証処理の一部を行い、改札出場時や列車乗車中の車掌携帯端末で認証処理の続きを行うようにしても良い。この場合、例えば改札入場時は媒体認証、車掌携帯端末では個人認証、改札出場時はチケット認証、というように認証処理を分けても良い。あるいは、改札入場時にリスク査定を行い、リスクが一定レベルよりも大きい場合のみ、車掌携帯端末を用いて列車乗車中に追加認証の処理を行うようにしても良い。
【００４５】
本発明により、シンクライアント型の駅務機器において、高速かつセキュアに処理を行うことができる。これにより、通勤ラッシュ時などにおいても、改札前に人が並んで渋滞しないようにすることができる。さらにチケット偽造などによる不正な乗車を防ぐことができる。
【符号の説明】
【００４６】
１０１０…ＩＣカード、１０２０…駅務機器、１０３０、１０５０…ネットワーク、１０４０…駅サーバ、１０６０…組合せ認証サーバ、１０７０…個人認証サーバ、１０８０…媒体認証サーバ、１０９０…チケット認証サーバ、２０１０、３０１０…主制御部、２０２０、３０２０…入力部、２０３０、３０３０…出力部、２０４０、３０４０…通信処理部、２０５０、３０５０…記憶管理部
【図１】
0006368261.tif 000002
【図２】
0006368261.tif 000003
【図３】
0006368261.tif 000004
【図４】
0006368261.tif 000005
【図５】
0006368261.tif 000006
【図６】
0006368261.tif 000007
【図７】
0006368261.tif 000008
【図８】
0006368261.tif 000009
【図９】
0006368261.tif 000010
【図１０】
0006368261.tif 000011
【図１１】
0006368261.tif 000012
【図１２】
0006368261.tif 000013
【図１３】
0006368261.tif 000014
【図１４】
0006368261.tif 000015