図面 (/)

技術 ドライバ認証のための方法ならびにそのシステム、およびその記録媒体

出願人 エヌ・ティ・ティ・コムウェア株式会社
発明者 長岡亨坂田雅史小林和恵北岡勝也大室久子大鶴暢彦
出願日 2000年9月25日 (20年1ヶ月経過) 出願番号 2000-291120
公開日 2002年4月2日 (18年7ヶ月経過) 公開番号 2002-096715
状態 特許登録済
技術分野 車両用盗難防止 特定用途計算機 暗号化・復号化装置及び秘密通信 医療・福祉事務
主要キーワード 付加情報要求 免許情報 サービス提供許可 サービス提供機器 画面メニュー 本人証明 病院システム 利用対象
関連する未来課題
重要な関連分野

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

図面 (7)

課題

車輌ドライバの認証システムを搭載することにより、ネットワーク上の認証システムとの連携を可能とし、車輌盗難の防止をはかる。

解決手段

車載機2において、車輌に搭乗しようとするドライバに対し、本人認証のために用いる電子証明書提示を促す。車載機2は提示された電子証明書を基に、認証機関3へ認証情報DB8に予め登録されたドライバの個人情報との照合による認証を要求する。車載機2は、認証に成功したドライバにのみ前記車輌の運転許可する。また、認証機関3は外部接続されるネットワーク5経由で付加情報を取得し、その組み合わせによって認証を行い、運転可否の判断に反映させる。

概要

背景

車輌は、ドライバが鍵をドアに差し込むことにより、あるいはキーレスエントリであればリモコンを検知部に向かってONすることによって開錠され、搭乗後、更にイグニッションスイッチに鍵を差込み、イグニッションON位置まで廻すことによってエンジン始動し、運転が可能となる。ところで、搭乗したドライバが運転可能か否かの判断は搭乗時に行なわれることはなく、必要が生じた際に運転免許証を確認することによってのみ行なわれる。従って、鍵を所有さえすれば、正規のドライバか、あるいは盗難者であるかにかかわらず、誰でも車輌を開錠し、運転が可能であった。

一方、オンラインショッピング等の普及に伴い、インターネット上で行われる本人認証では、例えば、認証機関から発行された電子証明書パーソナルコンピュータ上のブラウザ等にインポートし、インターネットを介して相手提示することによって本人認証を行っている。また、利用の際に認証を必要とする設備機器では、磁気カードICカード等を用い、これらの設備・機器に設置されたカードリーダから利用者登録情報を読み込ませたり、あるいは、利用者自身が、登録されたパスワード等の入力を行い本人認証を行っている。

概要

車輌にドライバの認証システムを搭載することにより、ネットワーク上の認証システムとの連携を可能とし、車輌盗難の防止をはかる。

車載機2において、車輌に搭乗しようとするドライバに対し、本人認証のために用いる電子証明書の提示を促す。車載機2は提示された電子証明書を基に、認証機関3へ認証情報DB8に予め登録されたドライバの個人情報との照合による認証を要求する。車載機2は、認証に成功したドライバにのみ前記車輌の運転を許可する。また、認証機関3は外部接続されるネットワーク5経由で付加情報を取得し、その組み合わせによって認証を行い、運転可否の判断に反映させる。

目的

本発明は、上記の点に鑑みてなされたもので、車輌にドライバの認証システムを搭載することにより、ネットワーク上の認証システムとの連携を可能とし、車輌の盗難防止をはかった、ドライバ認証のための方法ならびにその車載システム、およびその記録媒体を提供するものである。

効果

実績

技術文献被引用数
3件
牽制数
2件

この技術が所属する分野

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

請求項1

車輌搭乗しようとするドライバに対し、本人認証のために用いる電子証明書提示を促し、前記提示された電子証明書と、あらかじめ登録されたドライバの個人情報との照合を行い、前記照合に成功したドライバにのみ前記車輌の運転許可する、ことを特徴とするドライバ認証のための方法。

請求項2

前記個人情報が登録されるドライバは、あらかじめ車輌の所有者によって搭乗を許可されたドライバであることを特徴とする請求項1に記載のドライバ認証のための方法。

請求項3

ネットワークを介して外部接続される警察情報ステムに対し、前記搭乗ドライバの免許情報を要求し、送信される前記搭乗ドライバの免許情報によっては前記車輌の運転を不許可とすることを特徴とする請求項1または2に記載のドライバ認証のための方法。

請求項4

ネットワークを介して外部接続される病院情報システムに対し、前記搭乗ドライバの病院治療情報を要求し、送信される前記搭乗ドライバの病院治療情報によっては前記車輌の運転を不許可とすることを特徴とする請求項1または2に記載のドライバ認証のための方法。

請求項5

車輌に搭乗しようとするドライバの認証を行い、運転が許可されたドライバにのみ前記車輌の運転を許可するドライバ認証システムであって、前記車輌に搭乗しようとするドライバから本人認証のために用いる電子証明書の提示を受け、前記提示された電子証明書とあらかじめ登録されたドライバの個人情報との照合を促し、前記照合に成功したドライバにのみ前記車輌の運転を許可する認証制御部を備えたことを特徴とするドライバ認証システム。

請求項6

前記認証制御部は、ネットワークを介して外部接続される情報システムに対し、前記ドライバ認証に必要な付加情報の送信を要求する付加情報要求部と、前記付加情報を得、前記ドライバ認証部による登録ドライバの認証に前記付加情報を反映させる付加情報反映部とを更に備えることを特徴とする請求項5に記載のドライバ認証システム。

請求項7

認証機関が持つ認証システムとはネットワークを介して接続されるドライバ認証システムに用いられるドライバ認証プログラムが記録されたコンピュータ読み取り可能な記録媒体であって、前記ドライバ認証プログラムは、搭乗ドライバに対して本人認証のための電子証明書の提示を要求するステップと、前記提示された電子証明書を前記認証機関が持つ認証システムに転送して認証要求を行うステップと、前記認証機関から本人認証の結果を受信して前記搭乗ドライバによる運転の可否を判断するステップと、をコンピュータに実行させるドライバ認証プログラムを記録した記録媒体。

請求項8

前記ドライバ認証プログラムは、更に、前記ネットワークを介して外部接続される情報システムから前記認証機関を介して到来する免許情報もしくは病院治療情報を、前記搭乗ドライバによる運転可否の判断に反映させるステップを含むことを特徴とする請求項7に記載のコンピュータ読み取り可能な記録媒体。

技術分野

0001

本発明は、車輌車載コンピュータを搭載し、ネットワーク上の認証システムとの連携を行うことによりドライバ認証を行う、ドライバ認証のための方法ならびにその車載システム、およびその記録媒体に関する。

背景技術

0002

車輌は、ドライバが鍵をドアに差し込むことにより、あるいはキーレスエントリであればリモコンを検知部に向かってONすることによって開錠され、搭乗後、更にイグニッションスイッチに鍵を差込み、イグニッションON位置まで廻すことによってエンジン始動し、運転が可能となる。ところで、搭乗したドライバが運転可能か否かの判断は搭乗時に行なわれることはなく、必要が生じた際に運転免許証を確認することによってのみ行なわれる。従って、鍵を所有さえすれば、正規のドライバか、あるいは盗難者であるかにかかわらず、誰でも車輌を開錠し、運転が可能であった。

0003

一方、オンラインショッピング等の普及に伴い、インターネット上で行われる本人認証では、例えば、認証機関から発行された電子証明書パーソナルコンピュータ上のブラウザ等にインポートし、インターネットを介して相手提示することによって本人認証を行っている。また、利用の際に認証を必要とする設備機器では、磁気カードICカード等を用い、これらの設備・機器に設置されたカードリーダから利用者登録情報を読み込ませたり、あるいは、利用者自身が、登録されたパスワード等の入力を行い本人認証を行っている。

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

0004

インターネット上で、認証機関から発行された電子証明書をパーソナルコンピュータ上のブラウザ等にインポートする方式の場合、そのパーソナルコンピュータ上のみでしか電子証明書を使用できず、また利用対象もインターネット上のサイトに限定されている。また、利用の際に認証を必要とする設備・機器において、これらの設備・機器に設置されたカードリーダから利用者のカードに記録された登録情報を読み込ませたり、あるいは、利用者自身が、登録されたパスワード等の入力を行い本人認証を行う場合、これらの入力を、所定の入力装置に接触して直接入力を行うことになる。従って、上記したいずれの方法もドライバ認証に流用するには無理があり、特に、盗難防止等に対応でき、更に、警察病院等、既に構築された情報システムとの連携を持った車輌用のドライバ認証システムの登場が望まれていた。

0005

本発明は、上記の点に鑑みてなされたもので、車輌にドライバの認証システムを搭載することにより、ネットワーク上の認証システムとの連携を可能とし、車輌の盗難防止をはかった、ドライバ認証のための方法ならびにその車載システム、およびその記録媒体を提供するものである。

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

0006

本発明のドライバ認証のための方法は、搭乗ドライバに本人認証のために用いる電子証明書の提示を促し、前記提示された電子証明書と、あらかじめ登録されたドライバの個人情報との照合を行い、前記照合の結果、一致が確認されたドライバにのみ当該車輌の運転を許可することを特徴とする。

0007

また、本発明のドライバ認証のための方法において、前記個人情報が登録されるドライバは、あらかじめ車輌の所有者によって搭乗を許可されたドライバであることを特徴とする。

0008

また、本発明のドライバ認証のための方法において、ネットワークを介して外部接続される警察情報システムに対し、前記搭乗ドライバの免許情報を要求し、送信される前記搭乗ドライバの免許情報によっては前記車輌の運転を不許可とすることを特徴とする。

0009

また、本発明のドライバ認証のための方法において、ネットワークを介して外部接続される病院情報システムに対し、前記搭乗ドライバの治療情報を要求し、送信される前記搭乗ドライバの治療情報によっては前記車輌の運転を不許可とすることを特徴とする。

0010

本発明のドライバ認証システムは、搭乗ドライバの認証を行い、運転が許可されたドライバにのみ車輌の運転を許可するドライバ認証システムであって、搭乗ドライバに本人認証のために用いる電子証明書の提示を促し、前記提示された電子証明書とあらかじめ登録されたドライバの個人情報との照合を行い、前記照合が成功したドライバにのみ当該車輌の運転を許可する認証制御を備えたことを特徴とする。

0011

また、本発明のドライバ認証システムにおいて、ネットワークを介して外部接続される情報システムに対し、前記ドライバ認証に必要な付加情報の送信を要求する付加情報要求部と、前記付加情報を得、前記ドライバ認証部による登録ドライバの認証に前記付加情報を反映させる付加情報反映部とを更に備えたことを特徴とする。上記構成により、例えば、警察システム、病院システム等外部情報システムとの連携がはかれ、単なるドライバの本人認証にとどまらず、免許の有無による運転の禁止、あるいは治療内容によっては運転の見合わせ等を促すことができる。

0012

本発明の記録媒体は、認証機関が持つ認証システムとはネットワークを介して接続される車載システムに用いられるドライバ認証プログラムであって、前記ドライバ認証プログラムは、搭乗ドライバに対して本人認証のための電子証明書の提示を要求するステップと、前記提示された電子証明書を前記認証機関が持つ認証システムに転送して認証要求を行うステップと、前記認証機関から本人認証の結果を受信して前記搭乗ドライバによる運転の可否を判断するステップとがプログラムされ記録されたことを特徴とする。

0013

また、本発明の記録媒体において、前記ドライバ認証プログラムは、更に、前記ネットワークを介して外部接続される情報システムから前記認証機関を介して到来する免許情報もしくは病院治療情報を、前記搭乗ドライバによる運転可否の判断に反映させるステップを含むことを特徴とする。

発明を実施するための最良の形態

0014

以下、本発明の実施の形態を、図面を参照して説明する。図1は、本発明のドライバ認証システムの接続形態を示すブロック図である。図1において、1は、携帯端末であり、車載機2との通信ならびに個人情報(電子証明書)の管理機能を有する。車載機2は、携帯端末1との通信を行う他、本人認証、車輌へのアクセス機能を持つ。また、車載機2は、無線LAN(Local Area Network )、もしくはインターネット4を介して認証機関3に接続される。認証機関3には、認証システムが構築され、認証情報DB8を内蔵し、当該認証情報DB8を参照することによって本人認証が行なわれ、また、警察システム6等、ネットワーク5を介して接続される他情報システムへの問い合わせ機能も持つ。警察システム6は、免許情報DB7を有し、認証機関3の要求に基づいて検索した結果を出力する。

0015

図2は、図1に示す本発明実施形態の動作の流れを説明するために引用したイベントフローである。以下、図2を参照しながら図1に示す本発明実施形態の動作について説明する。ここでは、車輌の所有者により、事前に車輌に搭乗が許可されるドライバの個人情報が認証情報DB8に設定登録されてあるものとして説明を行う。

0016

まず、車輌に搭乗しようとするドライバは、電子証明書を記憶した携帯端末1を用い、無線通信により車載機2に接続して認証依頼を行う()。次に、車載機2はその依頼を受けて証明書要求を携帯端末1へ返信する()。携帯端末1はその要求に応じて電子証明書を車載機2へ送信する()。このことにより、携帯端末1から電子証明書を受けた車載機2は、認証機関3にこの電子証明書を転送する()。そして、電子証明書を受けた認証機関3の認証システムは、認証情報DB8より認証情報を検索する()。次に、認証システムは、その検索結果を基に、当該搭乗ドライバがあらかじめ所有者によって搭乗許可を得たドライバであるか否かを認証し、その結果を認証機関3へ送信する()。更に、認証機関3は、当該ドライバが運転免許を取得しているか否かを問い合わせる免許情報要求について、ネットワーク5を介して警察システム6に送信する()。

0017

警察システム6は上記免許情報要求を基に免許DB7を検索する()。免許DB7は検索結果を警察システム6へ送信する()。次に、警察システム6は検索結果である免許情報を認証機関3へ通知する(a)。次に、認証機関3において、本人認証と搭乗ドライバの自動車免許に係る認証が正常に完了した場合、その認証結果を車載機2に送信する(b)。ここでは図示しないが、他に、ネットワーク5を介して病院システムが接続されていた場合、搭乗ドライバの病院治療データを問い合わせ、その認証結果を車載機2へ送信することもできる。また、接続されるのは病院システムに限らず搭乗ドライバの認証に用いて好適な情報を提供する種々のシステムであってもよく、その情報を基に認証結果を出力してもよい。

0018

車載機2は、上記した認証結果を受信すると、車輌のドアを開錠し、エンジンスタートを許可するか、あるいは、ドアの開錠を禁止すると共にそのドライバによる運転を不許可とする(c)。尚、認証機関3で不許可とされるドライバは、車輌の所有者によりあらかじめ乗車許可を得ていなか、乗車許可を得てあっても運転免許証が失効している、あるいは搭乗前に病院で手術投薬等を受け、運転が困難な場合等が考えられる。また、搭乗ドライバが予め乗車許可を得ていない(未登録ドライバ)であった場合、車の所有者もしくは、登録されているドライバに対して、メール等で通知することが可能である。

0019

図3に、上記したドライバ認証システムの動作概念図が示されている。上述したように、運転可能なドライバとは、あらかじめ当該車輌の所有者によって搭乗許可が得られたドライバであり、また、本人証明のための電子証明書を提示でき、更に、免許証、病院治療等の付加情報により運転が可能な状態にあると判断されたドライバである。従って、事前に運転可能なドライバの登録を要し、その認証情報および付加情報は、車載機2が持つローカルDB9、またはネットワーク上のDB、あるいはネットワーク上のASP(Application Service Provider)を介し、いずれかの形態で保管される。

0020

そして、ドライバが車輌に搭乗する際、携帯端末1を介してユーザID、パスワード等のユーザ識別情報Aを入力することにより、正当なドライバを特定するものであるか判断することでドライバの認証を行う登録ドライバ認証Bが行なわれ、電子証明書の使用が可能な状態となる。認証機関3に構築される認証システムは、車載機2からの認証要求C(無線通信による接続要求)により認証サービス受け付け(D)がなされ、電子証明書による本人認証が行なわれる(E)。また、このとき、免許情報、病院カルテ等付加情報による運転可能なドライバ認証への反映も行なわれる。ここでは、エージェントにより、ネットワーク経由で接続される警察システム、病院システム等からエージェントによりそのデータが自動収集されるものとする。

0021

エージェントの振る舞いはシナリオ記述によって定義される(F)。ここで定義された認証シナリオに従い、エージェント生成時に与えられたジョブ解析し、物理的な移動先を決定するためにネットワーク上のサービスを検索する(G、H)。そしてエージェントの移動先が決定され、その移動先にエージェント自身を送り込むことで所望の処理が実行される。なお、ASPとしてネットワークを介し提供されうる情報であれば複合的に追加利用することが可能である。

0022

認証機関3は、処理結果を受信し、本人認証に付加情報による認証が反映された統合情報に基づく認証結果を車載機2へ送信し(I、J)、車載機2は、その結果に基づいて車輌のドアを開錠してエンジンスタートを許可するか、あるいは、ドアの開錠を禁止すると共にそのドライバによる運転を不許可とする。

0023

図4は、図1に示すシステム構成のうち、ドライバを認証する部分のみ機能展開して示したブロック図である。図4において、携帯端末1は、使用者認証部11とサービスアクセス部12と証明書送信部13と、証明書格納部14とから成る。この携帯端末1は、例えば、携帯電話端末や、無線通信可能なPDA(Personal DigitalAssistants)等を用いて実現される。

0024

証明書格納部14は、認証機関3によって発行された電子証明書のデータ(以下、この電子証明書のデータを電子証明書と称す)と、携帯端末1において行う使用者認証用のデータ(個人識別情報)となるパスワード、指紋等の情報を格納している。証明書格納部14に格納される電子証明書は、所有者固有の情報をもち、例えば、個人識別するID(識別番号等)と証明書用のデータとからなる。また、証明書格納部14は、具体的には携帯端末1内の内蔵メモリや、携帯端末1に接続される着脱可能なメモリカード等の記憶媒体を用いて構成される。そしてまた、この証明書格納部14は、格納された情報の改竄を防止するため、任意の消去更新ができないように構成されている。また上記のように、証明書格納部14を着脱可能なメモリカードを用いて構成した場合、他の携帯端末に装着して利用することもできる。

0025

使用者認証部11は、電子証明書を使用しようとしている人が、電子証明書を使用できる本人であるかどうか、パスワードの入力や使用者の指紋の入力等により使用者を認証する機能をもつ。この認証により使用者が正当であることが確認されると電子証明書の使用が許可される。

0026

サービスアクセス部12は、車載機2に組み込まれるサービス受付部21への接続要求と、サービス受付部21から携帯端末1に送られる接続用アプリケーションプログラムの受信とその実行を行う機能をもつ。例えば、この接続用アプリケーションプログラムがJavaアプレットとして構成される場合、サービスアクセス部12には、JavaVM(Java Virtual Machine)が組み込まれ、このプログラムを実行する。この接続用アプリケーションプログラムにより、携帯端末1の表示部(図示せず)には、車載機2と通信し認証を行うためや、車載機2を操作するためあるいは車載機2が提供するサービスを享受するための、この車載機2に固有の画面メニューが表示される。そして、携帯端末1は車載機2に対応したリモコンのように機能する。そして、使用者により指定されたサービスを要求するサービス要求を車載機2に向け送信する。また、車載機2が複数あり、これらが同時に応答した場合、表示部にこれらのいずれかを選択するメニューを表示させ、ユーザに選択させる。

0027

証明書送信部13は、車載機2から送られる電子証明書要求の受信と、この電子証明書要求に応じて電子証明書を送信する機能をもつ。なお、電子証明書を送信する際に、暗号化を行うことにより、さらにセキュリティを高めることができる。またこの暗号化は、電子証明書の送信を無線通信により行うことから、電子証明書の送信毎に、暗号化の方式や暗号化に用いる暗号鍵等を異なるようにすることが望ましい。

0028

車載機2には、サービス受付部21と、認証制御部22が組み込まれる。サービス受付部21は、携帯端末1のサービスアクセス部12からの接続要求を受け付け、この接続要求に応じて、前述した接続用アプリケーションプログラムを送信する機能をもつ。この接続用アプリケーションプログラムを、携帯端末1からの接続要求に応じて送るのは、様々な車載機2を想定しているため、それぞれに固有の画面やメニューを携帯端末1に表示させるためである。認証制御部22は、携帯端末1に対する電子証明書の要求と、認証機関3の電子証明書の転送、認証機関による認証結果の受信、サービス提供許可・不許可の判定の機能をもつ。そのために、ドライバ認証に必要な付加情報の送信を要求する付加情報要求部221と、この付加情報を得、ドライバ認証部による登録ドライバの認証に付加情報を反映させる付加情報反映部222とを備える。なお、車載機2と携帯端末1間は、ここでは、近距離無線通信規格(Bluetooth)等により無線で接続されるものとする。

0029

認証機関3に構築される認証システムは、認証実行部31と、個人情報格納部32とから成る。認証実行部31は、車載機2に組み込まれたサービス受付部21から転送された電子証明書の受信とその復号化を行い、電子証明書に含まれる個人情報と個人情報格納部32に保存されている個人情報との照合を行う。そして、その照合結果を車載機2の認証制御部22へ送信する機能をもつ。個人情報格納部32は、電子証明書を発行した個人の情報(個人情報)を蓄積し管理する機能をもつ。この個人情報格納部32に格納される個人情報は、個人を識別するID(識別番号等)、電子証明書照合用データ、氏名、性別年齢住所電話番号、その他所有者に属する情報からなっている。なお、個人情報格納部32は、ハードディスク光磁気ディスク等の不揮発性記録装置により構成される。

0030

また、上記携帯端末1の使用者認証部11とサービスアクセス部12と証明書送信部13、車載機2のサービス受付部21と認証制御部22、そして認証システム3の認証実行部31の各機能は、メモリおよびCPU(中央演算装置)等により構成される処理部により、これらの各機能を実現するためのプログラム(図示せず)をメモリにロードして実行することによりその機能が実現されるものとする。

0031

次に、このように構成された本人認証機能を有する携帯端末1および車載機2とさらに認証機関3の認証システムから成るシステムの利用時における動作について、図5および図6に示すフローチャートを参照して説明する。

0032

はじめに、車輌に搭乗しようとするドライバは、パスワード、指紋情報等の本人を特定することができる個人識別情報を、携帯端末1に入力する。上記個人識別情報が入力されると、使用者認証部11は、入力された情報が、正当なユーザを特定するものであるか否か判断する(ステップS1)。そして、この判断で、正当なドライバを特定するものであると判定された場合(ステップS1の判断でYESの判定)、電子証明書を使用可能な状態とする(ステップS2)。ステップS1の判断でNOの判定された場合、電子証明書の使用を不許可にする(ステップS3)。

0033

次に、携帯端末1のサービスアクセス部12は、ドライバからの操作に応じて、車載機2のサービス受付部21に接続要求を無線通信により送信する(ステップS4)。次に、サービス受付部21は、携帯端末1から接続要求を受けると(ステップS5)、接続用アプリケーションプログラムを携帯端末1のサービスアクセス部12に送信する(ステップS6)。そして、サービスアクセス部12は、接続用アプリケーションプログラムを受信するとこのプログラムを実行する(ステップS7)。この接続用アプリケーションプログラムにより、携帯端末1は、車載機2から所望のサービスを受けるためのサービス要求を、サービス受付部21へ送ることができる。

0034

接続用アプリケーションプログラムを実行したサービスアクセス部12は、さらにユーザからの操作を受け、この操作に応じて、サービス受付部21にサービス要求を出す(ステップS8)。次に、サービス受付部21がサービスアクセス部12から送信されたサービス要求を受信すると(ステップS9)、認証制御部22が携帯端末1の電子証明書を要求する証明書要求を送信する(ステップS10)。

0035

証明書送信部13は、この証明書要求を受信すると(ステップS11)、証明書格納部14から電子証明書を取得し暗号化する(ステップS12)。安全のため一度ユーザ(ドライバ)の確認を取った上で、この電子証明書を認証制御部22に送信する(ステップS13)。尚、この電子証明書の送信にあたり、前述したように、暗号化を行うことが望ましいがこの限りではない。以下では、この電子証明書が暗号化され送信されるものとする。次に、認証制御部22は、暗号化された電子証明書を受信すると(ステップS14)、認証機関3の認証システムに備わる認証実行部31に電子証明書をそのまま転送する(ステップS15)。

0036

認証実行部31は、暗号化された電子証明書を受信すると(ステップS16)、受信した電子証明書を復号化し(ステップS17)、その情報と個人情報格納部32に格納されたユーザの個人情報とを照合した上(ステップS18)、その結果(照合結果)を認証制御部22に返す(ステップS19)。ここで返信される照合結果には、本人性肯定否定の判定結果と個人情報の一部(例えば、住所等)を含む。認証制御部22は、上記照合結果を受けると(ステップS20)、この照合結果を判定し(ステップS21)、本人性が保証された場合(ステップS21の判断でOKと判定された場合)はサービス開始を許可し(ステップS22)、本人性が保証されなかった場合(ステップS21の判断でNOと判定された場合)は、その本人性を否定する通知(NG)を証明書送信部13に送信する(ステップS23)。

0037

証明書送信部13が、本人性を否定する通知を受信すると、サービスアクセス部12は、車載機2における本人認証において、本人性が確認されなかったことをユーザに伝えるメッセージを表示させる(ステップS24)。

0038

以上、本人認証機能を有する携帯端末1および車載機2とさらに認証機関3の認証システムからなるシステムの利用時における動作について説明した。なお、上記で説明した動作フローチャートは一例であり、上記の処理の流れに限定されるものではない。本実施の形態では、携帯端末1を使って本人認証(個人の認証)を行っているが、使用者認証部11とサービスアクセス部12と証明書送信部13と証明書格納部14を車載機2に組み込んで、その認証を行うようにしてもよい。

0039

本実施の形態の基となる特許請求の範囲に記載した発明は、現実世界で本人認証のために用いられている各種証明書を電子化し、個人で使用できる携帯端末に記憶させて使用するという発想のもとになされた。この発明は、近距離無線通信、組み込みOS・Java等の技術を用いることにより、あらゆる機器に認証のためのインターフェースを設け実施することが可能であり、携帯電話端末などの携帯端末も接続用アプリケーションプログラムの実行やサービス提供機器側との会話的な通信が可能となる。よって、ユーザは上記発明による携帯端末さえ持ち歩けば、本人認証を必要とする様々なサービス提供機器を相手に、簡単な操作のみで確実な本人認証を行うことができる。

0040

なお、図4に示す携帯端末1の使用者認証部11とサービスアクセス部12と証明書送信部13の機能を実現するためのプログラムと、車載機2のサービス受付部21と認証制御部22の機能を実現するためのプログラムを、それぞれコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムを、それぞれ携帯端末1に対応するコンピュータシステムと車載機2に対応するコンピュータシステムに読み込ませ、実行することにより人認証機能を有する携帯端末1および車載機2からなるシステムを構成してもよい。なお、ここでいう「コンピュータシステム」とは、OSや周辺機器等のハードウェアを含むものとする。

0041

また、「コンピュータシステム」は、WWWシステムを利用している場合であれば、ホームページ提供環境(あるいは表示環境)も含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フロッピー(登録商標ディスク、光磁気ディスク、ROM、CD−ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバクライアントとなるコンピュータシステム内部の揮発性メモリ(RAM)のように、一定時間プログラムを保持しているものも含むものとする。

0042

また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク(通信網)や電話回線等の通信回線(通信線)のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル差分プログラム)であっても良い。

0043

以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

発明の効果

0044

以上説明のように本発明によれば、個人的に使用される携帯端末に本人性を保証する電子証明書を記憶させることにより、場所に縛られることなく、認証を伴うサービスの提供と享受を実現することができる。また、車輌に認証システムを搭載したことにより、ネットワーク上の認証システムとの連携が可能となり、更に、免許情報、病院治療情報等ネトワークを介した他の情報システムから収集した情報を統合させて認証を行うことにより、信頼性の高いドライバ認証のための方法ならびにドライバ認証システムを提供できる。また、事前に登録したドライバしか車輌の運転が許可されないため、車輌の盗難防止にもつながる。更に、認証機関は、認証を伴うサービスの普及が進み、利用者の増加につながる。本発明では、携帯端末上で使用者の本人認証を行い、さらに車載機において認証機関による本人認証を行う二重の認証により、本人認証を確実なものとしている。

図面の簡単な説明

0045

図1本発明のドライバ認証システムの接続形態を示すブロック図である。
図2図1に示す本発明実施形態の動作の流れを説明するために引用したイベントフローである。
図3本発明のドライバ認証システムの動作概念を示す動作概念図である。
図4図1に示すシステム構成のうち、ドライバを認証する部分のみ機能展開して示したブロック図である。
図5図4に示す実施形態の動作を説明するために引用したフローチャートである。
図6図4に示す実施形態の動作を説明するために引用したフローチャート図5続きのフローである。

--

0046

1…携帯端末、2…車載機、3…認証機関、4…無線LAN(インターネット)、5…ネットワーク、11…使用者認証部、12…サービスアクセス部、13…証明書送信部、14…証明書格納部、21…サービス受付部、22…認証制御部、31…認証実行部、32…個人情報格納部、221…付加情報要求部、222…付加情報反映部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

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

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

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

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

関連性が強い人物一覧

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

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

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

関連する公募課題一覧

astavision 新着記事

サイト情報について

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

主たる情報の出典

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