図面 (/)

技術 駅務機器における組合せ認証方法、組合せ認証装置及び認証システム

出願人 株式会社日立製作所
発明者 川崎健治金田悦雄岡村徳政
出願日 2015年2月25日 (5年1ヶ月経過) 出願番号 2015-034695
公開日 2016年9月1日 (3年6ヶ月経過) 公開番号 2016-157277
状態 特許登録済
技術分野 制御地点における料金又はチケットをチェックする装置、タクシーメータ、郵便料金計器
主要キーワード リスク査定 シンクライアント型 ゲート閉 個人認証サーバ ゲート開 認証ステータス 対応付けテーブル チケット種別
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2016年9月1日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (15)

課題

シンクライアント型駅務機器において、高速かつセキュアに処理ができることを特徴とする、認証方法および装置を提供する。

解決手段

チケット購入処理後にリスク査定を行い、リスクレベルが小さければホワイトリストを作成して駅サーバへ配信する。改札出場時は、ブラックリストに該当レコードがあれば認証失敗としてゲートを閉じる。またホワイトリストに該当レコードがあれば駅サーバで運賃計算を行い、チケット料金が不足していなければ認証成功としてゲートを開く。ホワイトリストに該当レコードがなければリスク査定を行い、リスクレベルが大きければ各認証サーバに対して認証要求を行う。認証が全て成功ならばゲートを開く。

概要

背景

近年、ネットワーク技術や仮想化技術発展に伴い、クラウドコンピューティングシンクライアント型業務システムが普及しつつある。同様に、鉄道などの公共交通機関において、自動改札機券売機などの駅務機器をシンクライアント型で実現することが考えられる。本構成では例えば、ICカードからのデータの読み取りのみをクライアント側の駅務機器で行い、その他の処理は全てサーバ側で行う。シンクライアント型の自動改札機においては、通勤ラッシュ時でも改札混雑しないようにするために高速な処理を実現することや、不正な乗車を防ぐためにセキュア認証処理を実現することが重要である。

シンクライアント型の自動改札機を実現するための技術の一つとして、駅務機器が担う様々な処理をサーバ側で行う方法がある(例えば特許文献1参照)。

一方、セキュアな電子チケットを実現するための技術の一つとして、ICカード固有情報チケット情報を用いて認証情報を作成・照合する方法がある(例えば特許文献2)。

概要

シンクライアント型の駅務機器において、高速かつセキュアに処理ができることを特徴とする、認証方法および装置を提供する。チケット購入処理後にリスク査定を行い、リスクレベルが小さければホワイトリストを作成して駅サーバへ配信する。改札出場時は、ブラックリストに該当レコードがあれば認証失敗としてゲートを閉じる。またホワイトリストに該当レコードがあれば駅サーバで運賃計算を行い、チケット料金が不足していなければ認証成功としてゲートを開く。ホワイトリストに該当レコードがなければリスク査定を行い、リスクレベルが大きければ各認証サーバに対して認証要求を行う。認証が全て成功ならばゲートを開く。

目的

特開2012−94053号公報
特開2007−79915号公報






上記特許文献1はサーバ側で改札処理を行う仕組みを、特許文献2は電子チケットの安全性および信頼性を向上する仕組みを、それぞれ提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

組合認証装置と認証装置とを備える認証システムであって、前記組合せ認証装置は、交通機関を利用するための電子チケットに関する電子チケット情報に基づいて、リスク査定し、前記リスクを含めたリストを作成する登録処理部と、前記登録処理部が作成したリストを用いて改札入場の際に査定した前記リスクに応じて認証要求を行い、前記登録処理部が作成したリストを用いて改札出場の際に査定した前記リスクに応じて認証要求を行う認証要求部と、を備え、前記認証要求を受けた前記認証装置は、認証を行う認証部を備えることを特徴とする認証システム。

請求項2

前記電子チケット情報とは、電子チケットの金額又は電子チケットの種類であり、前記登録処理部は、前記電子チケットの金額又は電子チケットの種類に応じてリスクレベルを査定することを特徴とする、請求項1記載の認証システム。

請求項3

前記電子チケットの金額とは、前記電子チケットに関する電子マネー残高であり、前記電子チケットの種類とは、定期券の内容であり、前記登録処理部は、前記電子マネーの残高又は、前記定期券の内容に基づいて、リスクレベルを査定することを特徴とする請求項2記載の認証システム。

請求項4

前記登録処理部は、前記電子チケットの利用履歴データを記憶し、前記利用履歴データの内容に応じてリスクレベルを査定することを特徴とする請求項3記載の認証システム。

請求項5

前記登録処理部は、前記利用履歴データに記憶された電子チケットの購入時刻を取得し、前記購入時刻から一定時間以内に改札を入場する場合はリスクレベルが小さいと査定することを特徴とする請求項4記載の認証システム。

請求項6

交通機関を利用するための電子チケットに関する電子チケット情報に基づいて、リスクを査定し、前記リスクを含めたリストを作成する登録処理部と、前記登録処理部が作成したリストを用いて改札入場の際に査定した前記リスクに応じて認証要求を行い、前記登録処理部が作成したリスト改札出場の際に査定したリスクに応じて認証要求を行う認証要求部と、を備えることを特徴とする組合せ認証装置。

請求項7

前記電子チケット情報とは、電子チケットの金額又は電子チケットの種類であり、前記登録処理部は、前記電子チケットの金額又は電子チケットの種類に応じてリスクレベルを査定することを特徴とする、請求項6記載の組合せ認証装置。

請求項8

前記電子チケットの金額とは、前記電子チケットに関する電子マネーの残高であり、前記電子チケットの種類とは、定期券の内容であり、前記登録処理部は、前記電子マネーの残高又は、前記定期券の内容に基づいて、リスクレベルを査定することを特徴とする請求項7記載の組合せ認証装置。

請求項9

前記登録処理部は、前記電子チケットの利用履歴データを記憶し、前記利用履歴データの内容に応じてリスクレベルを査定することを特徴とする請求項8記載の組合せ認証装置。

請求項10

前記登録処理部は、前記利用履歴データに記憶された電子チケットの購入時刻を取得し、前記購入時刻から一定時間以内に改札を入場する場合はリスクレベルが小さいと査定することを特徴とする請求項9記載の組合せ認証装置。

請求項11

組合せ認証装置と認証装置とを備える認証方法であって、組合せ認証装置の登録処理部が、交通機関を利用するための電子チケットに関する電子チケット情報に基づいて、リスクを査定し、前記リスクを含めたリストを作成する第1のステップと、組み合わせ認証装置の認証要求部が、前記第1のステップで作成したリストを用いて改札入場の際に査定した前記リスクに応じて認証要求を行う第2のステップと、前記認証要求を受けた認証装置が、認証を行う第3のステップと、組み合わせ認証装置の認証要求部が、前記第1のステップで作成したリストを用いて改札出場の際に査定した前記リスクに応じて認証要求を行う第4のステップと、前記認証要求を受けた認証装置が、認証を行う第5のステップと、を有することを特徴とする組合せ認証方法。

請求項12

前記電子チケット情報とは、電子チケットの金額又は電子チケットの種類であり、前記登録処理部は、前記電子チケットの金額又は電子チケットの種類に応じてリスクレベルを査定することを特徴とする、請求項11記載の組合せ認証方法。

請求項13

前記電子チケットの金額とは、前記電子チケットに関する電子マネーの残高であり、前記電子チケットの種類とは、定期券の内容であり、前記登録処理部は、前記電子マネーの残高又は、前記定期券の内容に基づいて、リスクレベルを査定することを特徴とする請求項12記載の組合せ認証方法。

請求項14

前記登録処理部は、前記電子チケットの利用履歴データを記憶し、前記利用履歴データの内容に応じてリスクレベルを査定することを特徴とする請求項13記載の組合せ認証方法。

請求項15

前記登録処理部は、前記利用履歴データに記憶された電子チケットの購入時刻を取得し、前記購入時刻から一定時間以内に改札を入場する場合はリスクレベルが小さいと査定することを特徴とする請求項14記載の組合せ認証方法。

技術分野

0001

駅務機器における認証方法認証装置及び認証システムに関する。

背景技術

0002

近年、ネットワーク技術や仮想化技術発展に伴い、クラウドコンピューティングシンクライアント型業務システムが普及しつつある。同様に、鉄道などの公共交通機関において、自動改札機券売機などの駅務機器をシンクライアント型で実現することが考えられる。本構成では例えば、ICカードからのデータの読み取りのみをクライアント側の駅務機器で行い、その他の処理は全てサーバ側で行う。シンクライアント型の自動改札機においては、通勤ラッシュ時でも改札混雑しないようにするために高速な処理を実現することや、不正な乗車を防ぐためにセキュア認証処理を実現することが重要である。

0003

シンクライアント型の自動改札機を実現するための技術の一つとして、駅務機器が担う様々な処理をサーバ側で行う方法がある(例えば特許文献1参照)。

0004

一方、セキュアな電子チケットを実現するための技術の一つとして、ICカード固有情報チケット情報を用いて認証情報を作成・照合する方法がある(例えば特許文献2)。

先行技術

0005

特開2012−94053号公報
特開2007−79915号公報

発明が解決しようとする課題

0006

上記特許文献1はサーバ側で改札処理を行う仕組みを、特許文献2は電子チケットの安全性および信頼性を向上する仕組みを、それぞれ提供するものであった。

0007

しかしながら特許文献1の方法では、セキュリティを向上するために認証処理を追加すると、処理が遅くなるという課題がある。

0008

また特許文献2の方法では、サーバ側で認証処理を行う方法については考慮されておらず、また高速な処理を実現することが難しいという課題がある。

0009

本発明は上記課題を解決するためになされたもので、その目的は、高速な改札処理と、セキュアな認証処理を両立できることを特徴とする、鉄道などの公共交通機関の自動改札機などの機器において認証処理を行う方法および装置を提供することである。

課題を解決するための手段

0010

上記の目的を達成するために、本発明によれば、交通機関を利用するための電子チケットにおいて、
電子チケット利用前に査定したリスクに応じてリストを作成する第1の手段と、
前記第1の手段で作成したリストを用いて改札入場時に査定したリスクに応じて認証処理を行う第2の手段と、
前記第1の手段で作成したリストを用いて改札出場時に査定したリスクに応じて認証処理を行う第3の手段を備えることができる。

発明の効果

0011

本発明によれば、駅務機器において、高速な改札処理と、セキュアな認証処理を両立して行うことができる。

図面の簡単な説明

0012

本発明の実施例のシステム構成例を示す図である。
駅サーバ1040のハードウェア構成例を示す図である。
組合認証サーバ1060のハードウェア構成例を示す図である。
登録処理プログラム3070の処理例を示すフローチャートである。
リスト配信プログラム3080の処理例を示すフローチャートである。
入場処理プログラム2070の在来線列車の改札の場合の処理例を示すフローチャートである。
入場処理プログラム2070の特急列車の改札の場合の処理例を示すフローチャートである。
出場処理プログラム2080の処理例を示すフローチャートである。
認証要求プログラム3090の処理例を示すフローチャートである。
ホワイトリストテーブル2090、3120の構成例を示す図である。
ブラックリストテーブル2100、3130の構成例を示す図である。
認証サーバリストテーブル3100の構成例を示す図である。
対応付けテーブル3110の構成例を示す図である。
駅員操作端末画面例を示す図である。

実施例

0013

以下、本発明における実施例について、図面を参照しながら詳細に説明する。

0014

図1は、本実施例のシステム構成例を示すブロック図である。自動改札機、券売機、駅員操作端末などの複数の駅務機器1020は、ネットワーク1030を経由して、駅サーバ1040に接続する。駅務機器1020は、交通ICカードやクレジットカードなどの媒体1010を識別し、データの読み取りや書き込みを行うことができる。媒体には、指紋、指静脈、目の網膜虹彩などの生体も含まれる。複数の駅サーバ1040は、ネットワーク1050を経由して、組合せ認証サーバ1060、個人認証サーバ1070、媒体認証サーバ1080、チケット認証サーバ1090に接続する。個人認証サーバ1070は、例えば利用者の氏名・性別年齢などの属性情報を管理する。また事前預け入れてあるSF(Stored Fare)残高も管理する。媒体認証サーバ1080は、例えば交通ICカードの発行元ステータス活性・非活性など)を管理する。チケット認証サーバ1090は、例えば電子チケット(乗車券)の発行元やステータス(発行前、発行、入場、出場、破棄など)を管理する。また、上記以外に例えばクレジットカード会社などの鉄道会社以外の会社が発行する媒体の与信・認証を行う認証サーバや、生体情報の管理・認証を行う認証サーバを接続しても良い。組合せ認証サーバ1060は、個人・媒体・チケットの組合せを管理し、該組合せが正しいか否かの認証を行う。

0015

ここで、本実施例では改札通過時の処理を高速化するために、駅サーバを各駅に、組合せ認証サーバをセンタに配置することを想定している。しかしながらこれに限定されるものではなく、どちらかのサーバに機能を集約して、またはセンタに配置しても良い。また、駅サーバは1駅に1台に限定されるものではなく、大規模駅では1駅に複数台のサーバを配置したり、小規模駅では複数駅に1台のサーバを配置したりしても良い。

0016

本構成は、例えば媒体1010をICカードで、駅務機器1020と駅サーバ1040と組合せ認証サーバ1060と個人認証サーバ1070と媒体認証サーバ1080とチケット認証サーバ1090をパーソナルコンピュータワークステーション等の計算機で、ネットワーク1030、1050をEthernet(登録商標)でそれぞれ構成することにより実現できる。

0017

図2は、駅サーバ1040のハードウェア構成例を示す図である。2010は、ハードウェアの制御とプログラムの実行処理を行う主制御部である。2020は、システム管理者からのプログラム実行開始指示中止指示等の入力を行う入力部である。2030は、プログラムの実行状態等の出力を行う出力部である。2040は、他の計算機とのデータ交換を行う通信処理部である。2050は、プログラムやデータの読み出し、記録を行う記憶管理部である。2060は上記各部間のデータ交換を行う通信部である。記憶管理部2050には、入場処理プログラム2070、出場処理プログラム2080、ホワイトリストテーブル2090、ブラックリストテーブル2100が格納される。

0018

図3は、組合せ認証サーバ1060のハードウェア構成例を示す図である。3010は、ハードウェアの制御とプログラムの実行処理を行う主制御部である。3020は、システム管理者からのプログラム実行開始指示や中止指示等の入力を行う入力部である。3030は、プログラムの実行状態等の出力を行う出力部である。3040は、他の計算機とのデータ交換を行う通信処理部である。3050は、プログラムやデータの読み出し、記録を行う記憶管理部である。3060は上記各部間のデータ交換を行う通信部である。記憶管理部3050には、登録処理プログラム3070、リスト配信プログラム3080、認証要求プログラム3090、認証サーバリストテーブル3100、対応付けテーブル3110、ホワイトリストテーブル3120、ブラックリストテーブル3130が格納される。

0019

上記構成は、例えば、主制御部2010、3010をCPUで、入力部2020、3020をキーボードで、出力部2030、3030を液晶ディスプレイで、通信処理部2040、3040をEthernetや無線通信で、記憶管理部2050、3050をハードディスクフラッシュメモリで、通信部2060、3060をBusで実現することにより構成可能である。また入力部と出力部をタッチパネルで実現することにより構成することも可能である。

0020

続いて、登録処理プログラム3070の処理例を、図4のフローチャートを用いて説明する。本プログラムは、利用者が券売機などの駅務機器を用いてチケットを購入する時に実行するものとする。あるいは、交通ICカード機能付きの携帯電話などを用いてチケットを購入する時に実行するものとする。

0021

最初に、個人認証サーバと媒体認証サーバに対して認証要求を行い、正当な利用者、かつ正当な媒体であることを認証し、更に個人・媒体・チケットの組合せの妥当性を確認する組合せ認証処理を行う(ステップ4010)。媒体認証については、媒体の種類に応じてどの認証サーバに認証要求を送信するかを判断するために、認証サーバリストテーブルを読み込む。図12に、認証サーバリストテーブルの構成例を示す。本テーブルは、媒体種別12010、認証サーバアドレス12020からなる行のリストである。媒体種別には、交通ICカード、廉価タグ、クレジットカード、生体(指静脈)、生体(虹彩)などの媒体種別を登録できる。認証サーバアドレスには、該媒体種別の認証処理を行うことが可能なサーバのIPアドレス接続プロトコルインタフェース情報などを登録できる。組合せ認証は、例えば大人が利用する媒体に小人運賃のチケットを割り当てようとしている場合、認証失敗と判定する。個別認証および組合せ認証が成功であれば、利用者が指定したチケットの購入処理を行う(ステップ4020)。例えば、チケット認証サーバに対してチケット購入要求を行い、チケットが確保できたら、個人認証サーバに対して該チケット料金の精算要求を行い、チケット購入を完了する。チケット購入処理が完了したら、対応付けテーブルへの登録を行う(ステップ4030)。

0022

図13に、対応付けテーブルの構成例を示す。本テーブルは、ユーザID13010、媒体ID13020、チケットID13030、リスト作成フラグ13040、利用日時13050、属性情報13060、リスク査定・理由13070、認証情報13080からなる行のリストである。リスト作成フラグは、ホワイトリスト作成済みか否かを判別するためのフラグであり、作成済みであれば1を、そうでなければ0を設定する。利用日時は、チケットの利用日時(例えば乗車する列車の発車日時)を設定する。属性情報は、個人認証に関連する属性(例えば年齢、SF残高、過去の利用履歴など)、媒体認証に関連する属性(例えば媒体種別、媒体の発行元、媒体の発行年、最終利用日時など)、チケット認証に関連する属性(例えばチケット発行元、発行日時チケット種別チケット金額など)を設定する。認証情報は、現在の認証ステータス(例えば発券時の認証済、入場時の認証済、認証失敗など)を設定する。本ステップでは、ユーザID、媒体ID、チケットID、利用日時、属性情報の値をそれぞれ設定し、リスト作成フラグには0を設定し、認証情報には発券時の認証済を設定する。ステップ4030が終了するか、ステップ4010で個別認証あるいは組合せ認証が失敗であれば、該処理結果を駅サーバに送信し(ステップ4040)、処理を終了する。

0023

すなわち、組合せ認証装置1060は、交通機関を利用するための電子チケットに関する電子チケット情報に基づいて、リスクを査定し、前記リスクを含めたリストを作成する登録処理部(登録処理プログラム3070)と、登録処理部が作成したリストを用いて改札入場の際に査定したリスクに応じて認証要求を行い、登録処理部が作成したリストを用いて改札出場の際に査定したリスクに応じて認証要求を行う認証要求部(認証要求プログラム3090)と、を備える。認証要求を受けた認証装置(個人認証サーバ1070、媒体認証サーバ1080、チケット認証サーバ1090)は、認証を行う認証部を備える。

0024

また、電子チケット情報とは、電子チケットの金額又は電子チケットの種類であり、登録処理部は、電子チケットの金額又は電子チケットの種類に応じてリスクレベルを査定しても良い。

0025

更に、電子チケットの金額とは、電子チケットに関する電子マネーの残高であり、電子チケットの種類とは、定期券の内容であり、登録処理部は、電子マネーの残高又は、定期券の内容に基づいて、リスクレベルを査定しても良い。

0026

また、登録処理部は、電子チケットの利用履歴データを記憶し、利用履歴データの内容に応じてリスクレベルを査定しても良い。

0027

更に、登録処理部は、利用履歴データに記憶された電子チケットの購入時刻を取得し、購入時刻から一定時間以内に改札を入場する場合はリスクレベルが小さいと査定しても良い。

0028

続いて、リスト配信プログラム3080の処理例を、図5のフローチャートを用いて説明する。本プログラムは、登録処理プログラムの実行終了後に、非同期で(例えば一定時間ごとに)実行するものとする。

0029

最初に、対応付けテーブルを1レコードずつ順に読み込む(ステップ5010)。該テーブルに次レコードがあれば(ステップ5020)、該レコードの利用日時とリスト作成フラグを調べる(ステップ5030)。該レコードのリスト作成フラグが0で、かつ利用日時が現在日時から一定時間以内であれば、該チケット利用のリスクを査定し、リスク査定・理由13070の列に該結果および査定日時を設定する(ステップ5040)。ここで、リスクの査定方法としては、例えば以下のような基準でリスクレベルを判定するものとする。

0030

(1)チケット金額が一定額以上の場合、不正乗車された時のリスクが高いと判定する。
(2)チケット種別が新幹線特急券の場合、不正乗車された時のリスクが高いと判定する。
(3)媒体の種類がセキュアな媒体や生体の場合、偽造されるリスクが低いと判定する。逆にセキュアでない廉価なタグ等の場合、偽造されるリスクが高いと判定する。
(4)利用者のSF残高が一定額以上、あるいは定期券を保有している場合、乗車運賃を取りはぐれた時のリスクが低いと判定する。
(5)利用者のチケット購入・利用の過去履歴データから、不審であったり通常は稀であったりするパターンでチケット購入・利用を行っている(例えば購入してすぐ払い戻す行為を複数の駅で何回も行っている等)場合、チケット不正利用のリスクが高いと判定する。

0031

リスクを査定した結果、リスクが一定レベルよりも小さいと判定された場合(ステップ5050)、ホワイトリストテーブルに該レコードの情報を登録する。図10に、ホワイトリストテーブルの構成例を示す。本テーブルは、ユーザID10010、媒体ID10020、チケットID10030、リスク査定・理由10040、属性情報10050からなる行のリストである。登録後、ステップ5020に戻り次レコードがあるか否かを調べる。ステップ5030で該レコードのリスト作成フラグが1、または利用日時が現在日付から一定時間以内でない場合は、ステップ5020に戻る。またステップ5050でリスクが一定レベルよりも小さいと判定されなかった場合も、ステップ5020に戻る。ステップ5020で次レコードが無くなったら、作成したホワイトリストテーブルを駅サーバに送信し(ステップ5070)、対応付けテーブルの認証情報にホワイトリスト送信済を設定し、処理を終了する。送信先となる駅サーバは、例えば在来線列車の乗車チケットであれば出場駅の駅サーバへ送信し、特急列車の乗車チケットであれば入場駅・出場駅の駅サーバへ送信する。あるいは該乗車チケットで乗り換えの発生する駅や、途中下車可能な全ての駅の駅サーバへ送信しても良い。

0032

続いて、認証要求プログラム3090の処理例を、図9のフローチャートを用いて説明する。本プログラムは、改札入場時や出場時に、駅サーバからの認証要求に応じて実行するものとする。

0033

最初に、個人認証サーバと媒体認証サーバとチケット認証サーバに対して認証要求を行い、正当な利用者、かつ正当な媒体、かつ正当なチケットであることを認証し、更に個人・媒体・チケットの組合せの妥当性を確認する組合せ認証処理を行う(ステップ9010)。媒体認証については、媒体の種類に応じてどの認証サーバに認証要求を送信するかを判断するために、認証サーバリストテーブルを読み込む。個別認証および組合せ認証が成功であれば、処理結果を駅サーバに送信し(ステップ9040)、認証結果を対応付けテーブルの認証情報に登録し、処理を終了する。認証が失敗であり、該要求元が在来線改札の入場処理プログラムであれば(ステップ9020)、ブラックリストテーブルを作成し、出場駅候補の駅サーバに送信する(ステップ9030)。図11に、ブラックリストテーブルの構成例を示す。本テーブルは、ユーザID11010、媒体ID11020、チケットID11030からなる行のリストである。出場駅候補の抽出は、例えば乗車チケットの出場駅や乗り換え駅通過駅などから抽出し、該駅の駅サーバへ送信する。あるいは、該利用者の過去のチケット利用履歴データから出場駅を予測して、該駅の周辺の駅サーバのみに送信しても良い。あるいは、全ての駅サーバへブラックリストテーブルを送信しても良い。ブラックリストテーブルの送信を完了、またはステップ9020で要求元が在来線改札の入場処理プログラム以外であれば、処理結果を駅サーバに送信し(ステップ9040)、認証結果を対応付けテーブルの認証情報に登録した後、処理を終了する。

0034

続いて、在来線列車の改札入場時の駅サーバの入場処理プログラムの処理例を、図6のフローチャートを用いて説明する。在来線列車の場合、特急列車に比べて運賃が比較的低額のため、本実施例の入場処理ではリスクレベルに応じた認証処理を省略するものとする。本処理は、自動改札機などの駅務機器がICカードなどの利用者の保有する媒体を認識した後、自動改札機から駅サーバに対して改札内への入場判定を要求するタイミングで実行するものとする。

0035

最初に、ブラックリストテーブルに該当するIDが登録されているか否かを調べる(ステップ6010)。ブラックリストテーブルは、あらかじめ組合せ認証サーバから送信されているものとする。ここで、調べるIDは例えば媒体から読み取った媒体IDを用いる。あるいは、媒体の記憶領域内に個人IDやチケットIDを記憶しておき、該IDを読み取って用いても良い。ブラックリストテーブルに該当するIDが登録されていれば、改札機に対して判定NGを送信し(ステップ6030)、処理を終了する。ブラックリストテーブルに該当するIDが登録されていなければ、改札機に対して判定OKを送信する(ステップ6020)。改札機は送信された判定結果に応じて、例えば判定OKであればゲート開、判定NGであればゲート閉の動作を行う。送信後、組合せ認証サーバの認証要求プログラムを呼び出し(ステップ6040)、処理を終了する。

0036

続いて、特急列車の改札入場時の駅サーバの処理を、図7のフローチャートを用いて説明する。特急列車の場合、在来線列車に比べて運賃が比較的高額のため、入場処理でも基本的にリスクレベルに応じた認証処理を行うものとする。本処理は、自動改札機などの駅務機器がICカードなどの利用者の保有する媒体を認識した後、自動改札機から駅サーバに対して改札内への入場判定を要求するタイミングで実行するものとする。

0037

最初に、ブラックリストテーブルに該当するIDが登録されているか否かを調べる(ステップ7010)。ブラックリストテーブルは、あらかじめ組合せ認証サーバから送信されているものとする。ここで、調べるIDは例えば媒体から読み取った媒体IDを用いる。あるいは、媒体の記憶領域内に個人IDやチケットIDを記憶しておき、該IDを読み取って用いても良い。ブラックリストに該当するIDが登録されていれば、改札機に対して判定NGを送信し(ステップ7030)、処理を終了する。ブラックリストに該当するIDが登録されていなければ、次にホワイトリストテーブルに該当するIDが登録されており、かつ該レコード中の査定日時が現在日時から一定時間以内であるか否かを調べる(ステップ7020)。ホワイトリストテーブルは、あらかじめ組合せ認証サーバから送信されているものとする。査定日時から一定時間以上経過していれば再度リスク査定を行うことにより、セキュリティを向上できる。ステップ7020に該当するならば、リスクに応じた認証処理を実行し、該結果を改札機に送信(ステップ7060)し、認証結果を組合せ認証サーバの対応付けテーブルの認証情報に登録した後、処理を終了する。例えば、セキュアな媒体を利用しておりリスクが小さいと査定されている場合、媒体認証を省略し、個人認証とチケット認証のみを行う。あるいは、リスクが小さければ入場時は全ての認証処理を省略しても良い。ステップ7020に該当しなければ、該チケット利用のリスクを査定する(ステップ7040)。ここで、リスクの査定方法としては、例えば前記ステップ5040に記載した(1)〜(5)の方法に加えて、以下のような基準でリスクを判定するものとする。

0038

(6)入場日時が、チケット購入日時から一定時間以内の場合、チケット偽造のリスクが低いと判定する。

0039

リスクを査定した結果、リスクが一定レベルよりも小さいと判定された場合(ステップ7050)、リスクに応じた認証処理を実行し、該結果を改札機に送信(ステップ7060)した後、処理を終了する。リスクが一定レベルよりも小さくないと判定された場合は、組合せ認証サーバの認証要求プログラムを呼び出し、該認証結果を改札機に送信して(ステップ7070)、処理を終了する。改札機は送信された判定結果に応じて、例えば判定OKであればゲート開、判定NGであればゲート閉の動作を行う。

0040

続いて、改札出場時の駅サーバの処理を、図8のフローチャートを用いて説明する。本処理は、自動改札機などの駅務機器がICカードなどの利用者の保有する媒体を認識した後、自動改札機から駅サーバに対して改札外への出場判定を要求するタイミングで実行するものとする。

0041

最初に、ブラックリストテーブルに該当するIDが登録されているか否かを調べる(ステップ8010)。ブラックリストテーブルは、あらかじめ組合せ認証サーバから送信されているものとする。ここで、調べるIDは例えば媒体から読み取った媒体IDを用いる。あるいは、媒体の記憶領域内に個人IDやチケットIDを記憶しておき、該IDを読み取って用いても良い。ブラックリストに該当するIDが登録されていれば、改札機に対して判定NGを送信し(ステップ8030)、処理を終了する。ブラックリストに該当するIDが登録されていなければ、次にホワイトリストテーブルに該当するIDが登録されており、かつ該レコード中の査定日時が現在日時から一定時間以内であるか否かを調べる(ステップ8020)。ホワイトリストテーブルは、あらかじめ組合せ認証サーバから送信されているものとする。査定日時から一定時間以上経過していれば再度リスク査定を行うことにより、セキュリティを向上できる。また査定日時に該チケット区間の平均乗車時間を加えて、該時間が現在日時から一定時間以内であるか否かを調べても良い。

0042

ステップ8020に該当するならば、リスクに応じた認証処理を実行し、該結果を改札機に送信(ステップ8060)し、認証結果を組合せ認証サーバの対応付けテーブルの認証情報に登録した後、処理を終了する。例えば、チケット金額が少額のためリスクが小さいと査定されている場合、チケット認証を省略し、駅サーバで運賃計算を行って該運賃が該チケット金額以下であれば認証成功とする。ステップ8020に該当しなければ、該チケット利用のリスクを査定する(ステップ8040)。ここで、リスクの査定方法としては、例えば前記ステップ5040に記載した(1)〜(5)の方法を用いてリスクを判定するものとする。リスクを査定した結果、リスクが一定レベルよりも小さいと判定された場合(ステップ8050)、リスクに応じた認証処理を実行し、該結果を改札機に送信(ステップ8060)した後、処理を終了する。リスクが一定レベルよりも小さくないと判定された場合は、組合せ認証サーバの認証要求プログラムを呼び出し、該認証結果を改札機に送信して(ステップ8070)、処理を終了する。改札機は送信された判定結果に応じて、例えば判定OKであればゲート開、判定NGであればゲート閉の動作を行う。

0043

続いて、図14に駅員操作端末の画面例を示す。本画面は各ユーザID・媒体ID・チケットIDに対するリスク査定・理由や認証情報のリスト14010、キーワードを指定して特定のレコードを検索するためのインタフェース14020、ユーザ情報14030、媒体情報14040、チケット情報14050から構成される。リスト14010上の特定のレコードを指定すると、該レコードのユーザID、媒体ID、チケットIDに対応する属性情報を14030、14040、14050に表示する。本画面は、駅員が操作する駅務機器1020が、組合せ認証サーバ1060上の対応付けテーブルを参照することにより表示できる。駅員は本画面を用いて、特定の利用者のチケット利用状態などを確認することができる。

0044

以上、本実施例では改札入場時と改札出場時にリスク査定と認証処理を行う場合の処理例について説明した。しかしながらこれに限定されるものではなく、別の駅務機器(例えば乗車列車中の車掌携帯端末)を用いてリスク査定と認証処理を行うようにしても良い。あるいは、改札処理を高速化するために、改札入場時は認証処理の一部を行い、改札出場時や列車乗車中の車掌携帯端末で認証処理の続きを行うようにしても良い。この場合、例えば改札入場時は媒体認証、車掌携帯端末では個人認証、改札出場時はチケット認証、というように認証処理を分けても良い。あるいは、改札入場時にリスク査定を行い、リスクが一定レベルよりも大きい場合のみ、車掌携帯端末を用いて列車乗車中に追加認証の処理を行うようにしても良い。

0045

本発明により、シンクライアント型の駅務機器において、高速かつセキュアに処理を行うことができる。これにより、通勤ラッシュ時などにおいても、改札前に人が並んで渋滞しないようにすることができる。さらにチケット偽造などによる不正な乗車を防ぐことができる。

0046

1010…ICカード、1020…駅務機器、1030、1050…ネットワーク、1040…駅サーバ、1060…組合せ認証サーバ、1070…個人認証サーバ、1080…媒体認証サーバ、1090…チケット認証サーバ、2010、3010…主制御部、2020、3020…入力部、2030、3030…出力部、2040、3040…通信処理部、2050、3050…記憶管理部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ