JP2020035151A

JP2020035151A - 運転手認証装置及び運行管理システム

Info

Publication number: JP2020035151A
Application number: JP2018160610A
Authority: JP
Inventors: 優一加藤; Yuichi Kato; 尚己龍口; Naomi Tatsuguchi
Original assignee: Dai Nippon Printing Co Ltd
Current assignee: Dai Nippon Printing Co Ltd
Priority date: 2018-08-29
Filing date: 2018-08-29
Publication date: 2020-03-05
Anticipated expiration: 2038-08-29
Also published as: JP7151280B2

Abstract

【課題】運転手の個人認証を簡単に行う。【解決手段】本実施形態に係る運転手認証装置は、ＩＣチップを内蔵した運転免許証と通信を行い、暗証番号の入力なしにデータを読み取る読取部と、運転免許証の種類毎に、前記データに含まれる情報のうち、識別情報の生成に使用する情報を規定したテーブルと、複数のドライバーの識別情報を含むドライバー情報と、を記憶する記憶部と、前記テーブルを参照し、前記読取部が通信を行った前記運転免許証の種類を特定する特定部と、前記テーブルを参照し、前記特定された種類に対応する情報を前記データから抽出し、抽出した情報を所定の関数に入力して識別情報を生成する生成部と、前記生成部が生成した識別情報と、前記ドライバー情報に含まれる識別情報とを照合する照合部と、を備える。【選択図】図１

Description

本発明は、運転手認証装置及び運行管理システムに関する。

近年、車両の運行に関する情報を記録するドライブレコーダやデジタルタコグラフを搭載する車両が増えてきている。また、ドライブレコーダと携帯電話端末とを組み合わせ、携帯電話端末がドライブレコーダから受信した運転状況データをサーバへ転送する技術が知られている（例えば特許文献１参照）。

タクシー、バス、トラックなどの営業用車両を所有する企業は、運行管理を行うために、配車情報やドライバーからの申告をもとに、各車両を誰がいつ運転したかを示す運行スケジュールを作成し、この運行スケジュールと、ドライブレコーダが記録した運転状況データとを対応付けて保存していた。

運行スケジュールは、ドライバーが車両に乗車する際に、ドライブレコーダ等の車載器で個人認証を行うことでも作成可能である。従来、車載器にＩＣ社員証をかざしたり、ドライバー番号をテンキー入力したりして、個人の認証を行っていた。しかし、ＩＣ社員証の作製はコストがかかっていた。また、ドライバー番号の入力は手間がかかっていた。

各ドライバーが所有する運転免許証にはＩＣチップが内蔵されており、このＩＣチップから氏名等の個人情報を読み取ることで、個人認証を行うことができる。しかし、ＩＣ免許証は、事前に設定されている暗証番号を入力しないと、ＩＣチップから個人情報が取得できないようになっている。そのため、ドライバーが暗証番号を忘れている場合、ＩＣチップから個人情報が読み取れず、個人認証を行えなかった。また、暗証番号の入力は手間がかかると共に、同乗者に見られ得ることに対する抵抗が強かった。

特開２０１０−２３８２１４号公報

本発明は、運転手の個人認証を簡単に行うことができる運転手認証装置及び運行管理システムを提供することを課題とする。

本発明による運転手認証装置は、ＩＣチップを内蔵した運転免許証と通信を行い、暗証番号の入力なしにデータを読み取る読取部と、運転免許証の種類毎に、前記データに含まれる情報のうち、識別情報の生成に使用する情報を規定したテーブルと、複数のドライバーの識別情報を含むドライバー情報と、を記憶する記憶部と、前記テーブルを参照し、前記読取部が通信を行った前記運転免許証の種類を特定する特定部と、前記テーブルを参照し、前記特定された種類に対応する情報を前記データから抽出し、抽出した情報を所定の関数に入力して識別情報を生成する生成部と、前記生成部が生成した識別情報と、前記ドライバー情報に含まれる識別情報とを照合する照合部と、を備えるものである。

本発明の一態様では、前記運転手認証装置が搭載された車両に乗車したドライバーの顔を撮影して顔画像を生成する撮影部と、前記ドライバー情報に含まれる各ドライバーの顔画像と、前記撮影部により生成された顔画像とを比較する顔画像比較部と、をさらに備える。

本発明の一態様では、前記運転手認証装置が搭載された車両の運転可否を判定する判定部をさらに備え、前記記憶部は、前記車両の車格を含む車両情報を記憶し、前記ドライバー情報は、運転免許証の有効期限及びドライバーの運転資格を含み、前記判定部は、前記ドライバー情報を参照し、前記生成部が生成した識別情報に対応するドライバーの運転資格が前記車両情報に含まれる車格に対応しているか否か判定すると共に、このドライバーの運転免許証が有効期限内か否かを判定する。

本発明の一態様では、前記読取部が読み取るデータは、前記読取部が前記運転免許証に少なくとも２回送信したＲＥＱＢコマンド又はＷＵＰＢコマンドに対する応答として受信したＡＴＱＢコマンドと、アプリケーションフリー領域情報とを含む。

本発明の一態様では、車両の運行に関する運行履歴情報を取得する情報取得部と、前記運行履歴情報と、前記車両を運転するドライバーの識別情報とを送信する通信部と、をさらに備える。

本発明による運行管理システムは、本発明の運転手認証装置と、前記運転手認証装置から前記運行履歴情報及び前記識別情報を受信し、車両の運行管理を行う管理サーバと、を備えるものである。

本発明による運転手認証装置は、運転免許証の暗証番号の入力を受け付ける入力部と、前記暗証番号を用いてＩＣチップを内蔵した運転免許証と通信を行い、免許番号を含む個人情報を読み取る読取部と、複数のドライバーの個人情報を記憶する記憶部と、前記読取部が読み取った個人情報と、前記記憶部に記憶されている個人情報とを照合する照合部と、を備えるものである。

本発明によれば、運転手の個人認証を簡単に行うことができる。

本発明の実施形態に係る運行管理システムの概略図である。管理サーバのハードウェア構成図である。リクエスト応答信号のデータ構造を示す図である。データ選択テーブルの例を示す図である。ＩＤ番号生成プログラムを実行することで実現される機能ブロック図である。同実施形態に係るＩＤ番号生成処理を説明するフローチャートである。運転手認証装置のハードウェア構成図である。運転手認証プログラムを実行することで実現される機能ブロック図である。同実施形態に係る運転手認証方法を説明するフローチャートである。

以下、本発明の実施の形態を図面に基づいて説明する。本実施形態に係る運行管理システムは、管理サーバ１と、車両Ｃに搭載された運転手認証装置２とを備え、例えば、複数の車両Ｃを保有し、複数のドライバーを雇用している企業が、各車両Ｃを運転するドライバー及び運行履歴の管理を行う際に利用されるものである。

各ドライバーはＩＣチップ内蔵の運転免許証を所有している。ＩＣチップには、ドライバーの氏名、生年月日、住所、免許証番号等の個人情報が格納されている。この個人情報の読み取りには、事前（免許証発行時）に設定された暗証番号の入力が求められる仕様となっている。

管理サーバ１には、各車両Ｃの車両情報、及びドライバー情報が事前に登録されている。車両情報は、例えば車格等の車検証記載情報である。ドライバー情報は、各ドライバーについての、氏名、生年月日、免許番号、免許の有効期限、免許証の種類、運転資格、免許条件、顔画像等である。例えば、登録担当者が、各ドライバーの免許証の記載事項を確認してキーボード等を用いて情報を入力する。顔画像は、ドライバーをデジタルカメラで撮影した撮影画像データを登録してもよいし、免許証の顔写真部分をスキャナで読み取って登録してもよい。

このドライバー情報では、各ドライバーに運転時の個人認証用のＩＤ番号（識別情報）が割り当てられている。管理サーバ１は、事前に、運転免許証のＩＣチップから暗証番号の入力無しに読み取ることができる情報を用いてＩＤ番号を生成する。ＩＤ番号の生成方法については後述する。

管理サーバ１は、各車両Ｃの運転手認証装置２へ、ドライバー情報と、その車両Ｃの車両情報とを送信する。

運転手認証装置２は、例えば、車両Ｃのダッシュボードやルーフ部分に設置され、運行情報を取得するドライブレコーダやデジタルタコグラフの機能、ＩＣチップから情報を読み取る読取部、ドライバーの顔を撮影する撮影部等を有している。撮影部は、車両Ｃに乗り込んだドライバーの顔を撮影する。運転手認証装置２は、ドライバー情報に含まれる各ドライバーの顔画像と、撮影部が撮影した顔画像との特徴点を比較し、一致するドライバーを検出する。

ドライバーは、車両Ｃの乗車時に運転手認証装置２に運転免許証をかざす。運転手認証装置２は、運転免許証のＩＣチップから情報を読み取る。ここで読み取られる情報は、暗証番号の入力無しに読み取ることができる情報である。

運転手認証装置２は、読取部が読み取った情報から管理サーバ１と同様の手法でＩＤ番号を生成し、顔画像が一致したドライバーのＩＤ番号と照合する。ＩＤ番号が一致した場合、運転手認証装置２は、このドライバーのドライバー情報から、運転免許証の有効期限が切れていないか、免許証の運転資格が車両Ｃの車格に対応しているか等を確認し、運行を許可する。

運転手認証装置２は、運転終了後、運行履歴情報を、ドライバーのＩＤ番号と共にサーバ装置１へ送信する。サーバ装置１は、運行履歴情報を保存する。

運転免許証のＩＣチップには氏名や免許番号等の個人情報が保存されており、この個人情報を利用して個人認証を行うことも考えられるが、個人情報の読み取りには暗証番号の入力が必要であるため、手間がかかる。また、ドライバーが暗証番号を忘れた場合、個人情報の読み取りができず、個人認証を行うことができなくなる。また、ディスプレイのテンキー画面で暗証番号を入力する場合、同乗者に見えてしまうおそれがある。

一方、本実施形態では、暗証番号の入力は不要であるため、運転免許証を運転手認証装置２にかざすだけでドライバーの個人認証を簡単に行い、運行管理を実施できる。

図２は管理サーバ１のブロック構成図である。管理サーバ１は、ＣＰＵ（中央処理装置）１０、メインメモリ１１、通信部１２、ディスク装置１３、読取装置１４及び入力装置１５を備える。入力装置１５は、マウス、キーボード、スキャナ等である。

ディスク装置１３は、例えばハードディスク装置等の記憶装置であり、データ選択テーブル、ＩＤ番号生成プログラム、車両情報、ドライバー情報、各車両Ｃの運行履歴情報等を格納している。

読取装置１４は非接触通信により各ドライバーの運転免許証のＩＣチップからデータを取得する。本実施形態では、読取装置１４とＩＣチップとの間の通信は、ＩＳＯ／ＩＥＣ７８１６（及びＩＳＯ／ＩＥＣ１４４４３）で標準化されているタイプＢに基づくものとする。

読取装置１４は、動作磁界内にタイプＢのＰＩＣＣ（近接型ＩＣカード）である運転免許証がかざされると、ＩＣチップが応答するようにリクエスト信号（リクエストコマンド、ＲＥＱＢ／ＷＵＰＢ）を送信する。ＩＣチップはリクエスト信号を受信すると、リクエスト応答信号（ＡＴＱＢ：ＡｎｓｗｅｒＴｏＲｅｑｕｅｓｔ、ＴｙｐｅＢ）を送信する。

図３にリクエスト応答信号のデータ構造を示す。リクエスト応答信号は、第１バイトにタグ“５０”が付された１４バイトのデータであり、第２〜第５バイトにＰＵＰＩ、第６〜第９バイトにアプリケーションデータ、第１０〜第１２バイトにプロトコル情報、第１３及び第１４バイトにＣＲＣ＿Ｂが定義されている。

ＰＵＰＩは、ＰＩＣＣの擬似固有識別子であり、衝突防止処理時にＰＩＣＣを識別するために使用され、一時的に発生された乱数、または固定値である。

アプリケーションデータは、ＰＩＣＣにどのようなアプリケーションが書き込まれているかを読取装置１４に伝えるために使用される。アプリケーションデータは、次項のプロトコル情報のＡＤＣ（アプリケーションデータ符号化）フィールドに従って規定され、ＣＲＣ＿Ｂ圧縮符号化、又は個別の符号化が適用されるかを規定する。ＣＲＣ＿Ｂ圧縮符号化が用いられる場合、アプリケーションデータは、ＡＦＩ、ＣＲＣ＿Ｂ（ＡＩＤ）及びアプリケーション数から構成される。

ＡＦＩは、アプリケーションの分野を規定する１バイトの値である。ＣＲＣ＿Ｂ（ＡＩＤ）は、ＲＥＱＢ／ＷＵＰＢコマンドに記述されるＡＦＩに一致するＰＩＣＣの中にあるＡＩＤのＣＲＣ＿Ｂ計算した結果を示す２バイトの値である。アプリケーション数は、ＰＩＣＣの中に存在する他のアプリケーション数を示す１バイトの値である。

例えば、アプリケーションデータの第１及び第２バイトはＩＣメーカごとの任意の値であり、第３バイトはＩＳＯ／ＩＥＣ７８１６−６Ａｍｅｎｄｍｅｎｔ１で規定されるＩＣメーカコードである。

プロトコル情報は、許容ビット伝送速度、最大フレームサイズ、プロトコルタイプ、ＦＷＩ、ＡＤＣ、ＦＯが定義される。許容ビット伝送速度は、運転免許証の通信速度に対応する能力を示す１バイトの値である。

最大フレームサイズは、運転免許証が受信可能な最大フレーム長を示す４ビットの値である。プロトコルタイプは、運転免許証がサポートしているプロトコルタイプを示す４ビットの値である。

ＦＷＩ（フレーム待ち時間係数）は、フレーム待ち時間（ＦＷＴ）を定義するために、整数値で符号化された４ビットの値である。ＦＷＴは、読取装置１４から送られたフレームの最後から運転免許証が応答を開始するまでの最大時間である。

ＡＤＣ（アプリケーションデータ符号化）は、運転免許証がサポートするアプリケーションデータ符号化を示す２ビットの値である。ＦＯ（フレームオプション）は、運転免許証がサポートするフレームオプションを示す２ビットの値である。

ＣＲＣ＿Ｂは、そのフレーム内のすべてのデータビット（ビット数）から計算される巡回冗長検査符号である。

リクエスト応答信号に含まれるＰＵＰＩが乱数であるか、または固定値であるかを判別するために、読取装置１４は、リクエスト信号の送信、及びリクエスト応答信号の受信を少なくとも２回行う。受信した複数のリクエスト応答信号に含まれるＰＵＰＩが同じ値であれば固定値、異なる値であれば乱数であると判別することができる。

また、読取装置１４は、アプリケーションのフリー領域情報を取得するためのリクエスト信号を送信し、運転免許証のＩＣチップからアプリケーションのフリー領域情報を取得する。このフリー領域情報は、例えば、運転免許証の発行年月日や有効期限を示す。

このように、読取装置１４は、運転免許証のＩＣチップから、暗証番号の入力無しで取得可能な、ＡＴＱＢ信号、及びアプリケーションのフリー領域情報を読み取る。

運転免許証の作製を行う業者が複数ある場合や、運転免許証に内蔵されたＩＣチップの仕様によって、ＡＴＱＢ信号に含まれるいくつかの情報は、運転免許証毎に異なる。

例えば、ＡＴＱＢ信号に含まれる情報のうち、ＰＵＰＩ、アプリケーションデータのＣＲＣ＿Ｂ（ＡＩＤ）、プロトコル情報のＦＷＩ、ＡＤＣ、ＦＯは運転免許証間で異なり得る特徴的な情報である。

運転免許証は、作製業者の違いや、内蔵されているＩＣチップの種類等によって、どの情報が特徴的な情報となるか、いくつかの種類に分類することができる。本実施形態では、運転免許証の種類を特定し、その運転免許証が送信するＡＴＱＢ信号の情報の中で特徴となる情報や、アプリケーションのフリー領域情報等を用いて、ドライバーを識別するＩＤ番号を生成する。

図４に、ディスク装置１３に格納されているデータ選択テーブルの例を示す。データ選択テーブルは、運転免許証の種類毎に、ＩＤ番号生成に適した情報の組み合わせを示す。データ選択テーブルは予め準備されている。

例えば、運転免許証は、作製業者の違いや、内蔵されているＩＣチップの種類等によってカード＃１〜＃４の４種類に分類される。カード＃１では、ＡＴＱＢ信号のＰＵＰＩ及びプロトコル情報が特徴的な値であり、これらとアプリケーションフリー領域の発行年月日及び有効期限とがＩＤ番号生成に適したものとなる。

カード＃２や＃４では、ＡＴＱＢ信号のＰＵＰＩがランダムであり、ＩＤ番号生成には不適当であることが示されている。

ＣＰＵ１０が、ディスク装置１３に格納されているＩＤ番号生成プログラムをメインメモリ１１にロードして実行することで、図５に示すように、応答信号取得部１７、カード種類特定部１８、及びＩＤ番号生成部１９が実現される。

応答信号取得部１７は、読取装置１４が運転免許証から読み取った情報を取得する。例えば、応答信号取得部１７は、少なくとも２回の読み取り分のリクエスト応答信号と、アプリケーションフリー領域情報とを取得する。

カード種類特定部１８は、データ選択テーブルを参照して、読取装置１４が情報を読み取った運転免許証のカード種類を特定する。例えば、２回の読み取り分のリクエスト応答信号のＰＵＰＩが異なっている場合、運転免許証の種類は、カード＃２又は＃４となる。さらにリクエスト応答信号のプロトコル情報がデータパターンＹである場合、運転免許証の種類は、カード＃２であると特定される。

ＩＤ番号生成部１９は、データ選択テーブルを参照して、カード種類特定部１８により特定されたカード種類で、ＩＤ番号の生成に使用する情報を確認する。ＩＤ番号生成部１９は、読取装置１４から取得したデータから、ＩＤ番号生成に使用する情報を取り出し、ハッシュ関数に入力してハッシュ値を算出する。このハッシュ値を、運転免許証を所有するドライバーのＩＤ番号として割り当てる。

例えば、運転免許証の種類がカード＃２であると特定された場合、リクエスト応答信号のアプリケーションデータのＣＲＣ＿Ｂ（ＡＩＤ）と、プロトコル情報のＦＷＩ、ＡＤＣ、ＦＯと、アプリケーションフリー領域情報とをハッシュ関数に入力してＩＤ番号が生成される。

図６はＩＤ番号生成処理を説明するフローである。管理サーバ１の読取装置１４は、運転免許証へリクエスト信号を送信し（ステップＳ１０１）、リクエスト応答信号を受信する（ステップＳ１０２）。リクエスト応答信号の取得は、さらにもう１回行われる（ステップＳ１０３，Ｓ１０４）。

続いて、読取装置１４は、運転免許証へアプリケーションフリー領域情報のリクエスト信号を送信し（ステップＳ１０５）、アプリケーションフリー領域情報を受信する（ステップＳ１０６）。

管理サーバ１のカード種類特定部１８は、リクエスト応答信号及びアプリケーションフリー領域情報を用いて運転免許証のカード種類を特定する（ステップＳ１０７）。管理サーバ１のＩＤ番号生成部１９は、データ選択テーブルを参照して、ＩＤ番号生成に用いるべき情報を抽出し、ハッシュ関数に入力して、ドライバーを識別するＩＤ番号を生成する（ステップＳ１０８）。

企業の登録担当者は、各ドライバーから提出された運転免許証を読取装置１４にかざしてＩＤ番号を生成し、運転免許証の券面記載事項を、キーボード等を用いて管理サーバ１に入力する。また、ドライバーをデジタルカメラで撮影した顔画像、又は運転免許証の顔写真をスキャナでスキャンした顔画像を管理サーバ１に入力する。そして、ＩＤ番号と、券面記載事項と、顔画像とを対応付けたドライバー情報を登録する。ドライバー情報の登録後、運転免許証はドライバーに返却される。

管理サーバ１は、通信部１２を用いて、各車両Ｃに搭載された運転手認証装置２と通信を行い、ドライバー情報やデータ選択テーブルを送信したり、運行履歴情報を受信したりする。運行履歴情報は、車両を運転していたドライバーのＩＤ番号と対応付けて、ディスク装置１３に格納される。

図７は、運転手認証装置２のブロック構成図である。運転手認証装置２は、ＣＰＵ２０、記憶部２１、無線通信機能を有する通信部２２、カードリーダ等の読取部２３、デジタルカメラ等の撮影部２４、及び情報取得部２５を備える。

記憶部２１には、通信部２２を用いて管理サーバ１から受信したドライバー情報、車両情報、及びデータ選択テーブルが格納されている。また、情報取得部２５が取得した運行履歴情報が記憶部２１に格納されている。

情報取得部２５は、車両Ｃの運行に関する運行履歴情報を取得するものであり、例えば、エンジンを制御するＥＣＵ（Electronic Control Unit）が出力する信号、ブレーキペダルユニットが出力する信号等の車両Ｃの各部の状態を示す情報、加速度検出部や位置検出部が検出する情報、内蔵又は外付けされた撮影部２４が撮影した車両Ｃの外部及び内部の少なくとも一方の映像等を取得する。

ＣＰＵ２０が、記憶部２１に格納されている運行管理プログラムを実行することで、図８に示すように、情報更新部２００、顔画像比較部２０１、応答信号取得部２０２、カード種類特定部２０３、ＩＤ番号生成部２０４、ＩＤ番号照合部２０５、判定部２０６及び運行履歴情報送信部２０７が実現される。

情報更新部２００は、管理サーバ１から最新のドライバー情報を受信して、記憶部２１内のドライバー情報を更新する。

顔画像比較部２０１は、車両Ｃの運転席に座ったドライバーを撮影部２４が撮影した顔画像と、ドライバー情報に含まれる顔画像とを比較し、一致するドライバーを特定する。

応答信号取得部２０２、カード種類特定部２０３、ＩＤ番号生成部２０４の機能は、上述した管理サーバ１の応答信号取得部１７、カード種類特定部１８、及びＩＤ番号生成部１９の機能と同様であり、読取部２３がドライバーからかざされた運転免許証から読み取ったデータを用いてＩＤ番号を生成する。

ＩＤ番号照合部２０５は、顔画像が一致したドライバーのドライバー情報に登録されているＩＤ番号と、ＩＤ番号生成部２０４が生成したＩＤ番号とを照合する。

判定部２０６は、ドライバー情報及び車両情報を用いて、ドライバーが車両Ｃを運転可能か否か判定する。例えば、判定部２０６は、このドライバーが運転可能なサイズの車両か、運転免許証の有効期限が切れていないか等を確認し、運転可否を判定する。

運行履歴情報送信部２０７は、通信部２２を用いて、運行履歴情報をドライバーのＩＤ番号と共に管理サーバ１へ送信する。

図９は、ドライバーが車両Ｃに乗り込んだ際の認証方法を説明するフローチャートである。ドライバーが運転席に座ると、撮影部２４がドライバーを撮影し、顔画像を生成する（ステップＳ１）。

顔画像比較部２０１が、撮影部２４が生成した顔画像と、記憶部２１に格納されたドライバー情報に含まれる顔画像とを比較する（ステップＳ２）。顔画像が一致し、登録済みのドライバーであることが確認されると（ステップＳ３＿Ｙｅｓ）、読取部２３が起動する。ドライバーが運転免許証を読取部２３にかざすと、読取部２３が運転免許証のＩＣチップからデータを読み取り（ステップＳ４）、ＩＤ番号が生成される（ステップＳ５）。データ読み取り及びＩＤ番号の生成は、図６に示すフローチャートのステップＳ１０１〜Ｓ１０８と同様であるため、説明を省略する。

ステップＳ３で顔画像が一致したドライバーのドライバー情報に登録されているＩＤ番号と、ステップＳ５で生成したＩＤ番号とを照合する。ＩＤ番号が一致した場合（ステップＳ６＿Ｙｅｓ）、ドライバーがこの車両を運転できるか否か判定する。運転可能な場合（ステップＳ７＿Ｙｅｓ）、ドライバーは運行を開始する（ステップＳ８）。

顔画像やＩＤ番号が一致しない場合（ステップＳ２＿Ｎｏ、ステップＳ６＿Ｎｏ）、車両を運転できないと判定された場合（ステップＳ７＿Ｎｏ）、音声や画面表示等で認証エラーを通知する（ステップＳ９）。

運行終了後、ドライバーが終了ボタンを押すか、車両のエンジンが切れたことが検出されるか、又は撮影部２４による撮影画像からドライバーの降車が確認されると、運行履歴情報及びドライバーのＩＤ番号が管理サーバ１へ送信される。

このように、本実施形態によれば、暗証番号を入力しなくても、運転免許証をかざすだけでドライバーのＩＤ番号を生成し、個人認証を簡単に行い、運行管理できる。

上記実施形態では、暗証番号の入力が不要になるドライバー認証方法について説明したが、暗証番号の入力を行ってもよい。この場合、ドライバー情報の登録時にドライバーに暗証番号の入力を求め、運転免許証のＩＣチップから読み出した免許番号等の個人情報を用いてドライバー情報を作成・登録する。例えば免許番号が、ドライバーを識別するＩＤ番号となる。また、ＩＣチップには顔画像データが格納されており、この顔画像データをドライバー情報に使用する。

ドライバーが車両Ｃに乗車すると、撮影部２４がドライバーを撮影し、ドライバー情報に含まれる各ドライバーの顔画像と順に比較する。ドライバーは、運転手認証装置２に運転免許証をかざし（又は所定の場所に載置し）、暗証番号を入力する。運転手認証装置２は、運転免許証のＩＣチップから免許番号等の個人情報を読み出し、顔画像が一致したドライバーのドライバー情報に含まれる個人情報と照合する。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

１管理サーバ
２運転手認証装置

Claims

ＩＣチップを内蔵した運転免許証と通信を行い、暗証番号の入力なしにデータを読み取る読取部と、
運転免許証の種類毎に、前記データに含まれる情報のうち、識別情報の生成に使用する情報を規定したテーブルと、複数のドライバーの識別情報を含むドライバー情報と、を記憶する記憶部と、
前記テーブルを参照し、前記読取部が通信を行った前記運転免許証の種類を特定する特定部と、
前記テーブルを参照し、前記特定された種類に対応する情報を前記データから抽出し、抽出した情報を所定の関数に入力して識別情報を生成する生成部と、
前記生成部が生成した識別情報と、前記ドライバー情報に含まれる識別情報とを照合する照合部と、
を備える運転手認証装置。
前記運転手認証装置が搭載された車両に乗車したドライバーの顔を撮影して顔画像を生成する撮影部と、
前記ドライバー情報に含まれる各ドライバーの顔画像と、前記撮影部により生成された顔画像とを比較する顔画像比較部と、
をさらに備えることを特徴とする請求項１に記載の運転手認証装置。
前記運転手認証装置が搭載された車両の運転可否を判定する判定部をさらに備え、
前記記憶部は、前記車両の車格を含む車両情報を記憶し、
前記ドライバー情報は、運転免許証の有効期限及びドライバーの運転資格を含み、
前記判定部は、前記ドライバー情報を参照し、前記生成部が生成した識別情報に対応するドライバーの運転資格が前記車両情報に含まれる車格に対応しているか否か判定すると共に、このドライバーの運転免許証が有効期限内か否かを判定することを特徴とする請求項１又は２に記載の運転手認証装置。
前記読取部が読み取るデータは、前記読取部が前記運転免許証に少なくとも２回送信したＲＥＱＢコマンド又はＷＵＰＢコマンドに対する応答として受信したＡＴＱＢコマンドと、アプリケーションフリー領域情報とを含むことを特徴とする請求項１乃至３のいずれか１項に記載の運転手認証装置。
車両の運行に関する運行履歴情報を取得する情報取得部と、
前記運行履歴情報と、前記車両を運転するドライバーの識別情報とを送信する通信部と、
をさらに備えることを特徴とする請求項１乃至４のいずれか１項に記載の運転手認証装置。
請求項５に記載の運転手認証装置と、
前記運転手認証装置から前記運行履歴情報及び前記識別情報を受信し、車両の運行管理を行う管理サーバと、
を備える運行管理システム。
運転免許証の暗証番号の入力を受け付ける入力部と、
前記暗証番号を用いてＩＣチップを内蔵した運転免許証と通信を行い、免許番号を含む個人情報を読み取る読取部と、
複数のドライバーの個人情報を記憶する記憶部と、
前記読取部が読み取った個人情報と、前記記憶部に記憶されている個人情報とを照合する照合部と、
を備える運転手認証装置。