JP2020142762A - 認証装置及び管理システム - Google Patents

Abstract

【課題】生体認証により認証されなかった場合にも、当該車両を利用できるようにする。【解決手段】車両５０に搭載された認証装置２０は、記憶部２３１と、生体読取部Ｓ７７０と、生体認証部Ｓ７８０と、救済認証部Ｓ８１０と、利用許可部Ｓ７９０，Ｓ９５０と、を備える。記憶部は、登録生体情報及び登録救済情報が記憶される。生体読取部は、ユーザの生体情報を読取生体情報として読み取る。生体認証部は、生体読取部により読み取られた読取生体情報と記憶部に記憶された登録生体情報とが一致した場合に成立したと判定する生体認証を行う。救済認証部は、生体認証が不成立であった場合に、あらかじめ決められた認証を行う。利用許可部は、生体認証又は救済認証が成立した場合に、車両の利用を可能とする。【選択図】図１８

Description

本開示は、車両に搭載される認証装置及び当該認証装置を有する管理システムに関する。

特許文献１には、車両に搭載され、ユーザの認証用情報を取得し、取得した認証用情報と記憶した認証用情報とが異なる場合に、当該車両を利用不可状態にロックする技術が記載されている。ここで、認証用情報として、利用が許可された者の生体情報を用いる生体認証が行われることにより、利用が許可された者以外の者が車両を利用することを防ぐことができる。

特開２０１７−１８６０１０号公報

しかしながら、生体認証を行う際の周囲環境や生体情報を取得するセンサの汚れなどにより正規のユーザが生体認証を行っているにもかかわらず、生体情報が正しく取得できない場合がある。そして、生体情報が正しく取得できないことにより、利用不可状態にロックされるとユーザは車両を利用することができない可能性がある。

本開示の１つの局面は、生体認証により認証されなかった場合にも、当該車両を利用できるようにすることを目的とする。

本開示の一態様は、車両（５０）に搭載された認証装置（２０）であって、記憶部（２３１）と、生体読取部（Ｓ７７０）と、生体認証部（Ｓ７８０）と、救済認証部（Ｓ８１０）と、利用許可部（Ｓ７９０，Ｓ９５０）と、を備える。車両を利用するユーザのうち、あらかじめ登録されたユーザを登録ユーザとする。登録ユーザの生体情報を登録生体情報とする。登録ユーザの生体情報以外のあらかじめ決められた情報を登録救済情報とする。記憶部は、登録生体情報及び登録救済情報が記憶されるように構成される。生体読取部は、ユーザの生体情報を読取生体情報として読み取るように構成される。生体認証部は、生体読取部により読み取られた読取生体情報と記憶部に記憶された登録生体情報とが一致した場合に成立したと判定する生体認証を行うように構成される。救済認証部は、生体認証が不成立であった場合に、救済情報を用いたあらかじめ決められた認証を行うように構成される。利用許可部は、生体認証又は救済認証が成立した場合に、車両の利用を可能とするように構成される。

本開示の一態様は、管理システムであって、認証装置（２０）と、サーバ（１０）と、を備える。認証装置は、車両（５０）に搭載される。サーバは、認証装置と通信可能である。また、サーバは、車両を利用するユーザのうち、あらかじめ登録されたユーザを登録ユーザとする。管理システムは、生体記憶部（１２１ａ）と、入力記憶部（１２１ａ）と、を備える。生体記憶部は、登録ユーザの生体情報が登録生体情報として記憶されるように構成される。入力記憶部は、登録ユーザの入力操作により入力される入力情報が登録入力情報として記憶されるように構成される。認証装置は、生体取得部と、生体読取部（Ｓ７７０）と、生体認証部（Ｓ７８０）と、入力取得部と、入力読取部（Ｓ９３０，Ｓ９７０）と、入力認証部（Ｓ９４０，Ｓ９８０）と、利用許可部（Ｓ７９０，Ｓ９５０）と、を備える。生体取得部は、生体記憶部に記憶された登録生体情報を取得するように構成される。生体読取部は、車両に搭載された生体センサ（５３）からユーザの生体情報を読取生体情報として読み取るように構成される。生体認証部は、生体読取部により読み取られた読取生体情報と生体取得部により取得された登録生体情報とが一致した場合に成立したと判定する生体認証を行うように構成される。入力取得部は、入力記憶部に記憶された登録入力情報を取得するように構成される。入力読取部は、車両に搭載された入力器（５５，５７）から、ユーザにより入力される入力情報を読取入力情報として読み取るように構成される。入力認証部は、入力読取部により読み取られた読取入力情報と入力記憶部に記憶された登録入力情報とが一致した場合に成立したと判定する認証を入力認証として、生体認証が不成立であった場合に、入力認証を行うように構成される。利用許可部は、生体認証又は入力認証が成立した場合に、車両の利用を可能とするように構成される。

このような構成によれば、生体認証を用いた生体認証が不成立であったとしても、救済認証又は入力認証が成立した場合に車両の利用が可能となるため、車両を利用することができる。

管理システムの構成を表したブロック図である。 サーバの構成を表したブロック図である。 サーバ情報領域を表したブロック図である。 スケジュール情報の例を表した図である。 通常スケジュール情報の例を表した図である。 複数の登録車両に関するスケジュール情報の例を表した図である。 登録車両の構成を表したブロック図である。 認証装置の構成を表したブロック図である。 ユーザ端末の構成を表したブロック図である。 オーナー端末の構成を表したブロック図である。 車両登録処理を表したフローチャートである。 ユーザ登録処理を表したフローチャートである。 スケジュール登録処理を表したフローチャートである。 利用予約処理を表したフローチャートである。 キー発行処理を表したフローチャートである。 端末Ｖキー、端末識別情報及び認証Ｖキーのイメージを表した図である。 キー送信処理を表したフローチャートである。 車両利用処理を表したフローチャートである。 救済認証処理を表したフローチャートである。

以下、図面を参照しながら、本開示の実施形態を説明する。
［１．構成］
図１に示す管理システム１は、時間帯ごとに許可された複数の者が利用するシェアカーやレンタカーなどに適用されるシステムである。

図１に示すように管理システム１は、サーバ１０、認証装置２０、ユーザ端末３０及びオーナー端末４０を備える。管理システム１を構成するサーバ１０、認証装置２０、ユーザ端末３０及びオーナー端末４０は、インターネットなどの同一のネットワーク上に配置され、互いに通信可能に接続される。なお、通信可能に接続された機器の相互間での情報の送信は、一方から他方へ送信するものを含み、更に、一方が他方に情報の送信を要求し、要求に応じて情報が送信される態様で行われてもよい。

また、認証装置２０は車両ごとに１つ搭載される。認証装置２０が搭載され、後述する車両登録処理により管理システム１に登録された車両を、以下では登録車両５０ともいう。なお、認証装置２０と当該認証装置２０が搭載される登録車両５０とは、あらかじめ対応付けられる。すなわち、登録車両５０を特定した場合に、当該登録車両５０に搭載された認証装置２０が特定できるように設定される。なお、当該対応付けは、例えば登録車両５０の製造時など認証装置２０が登録車両５０に搭載される際に行われてもよい。
また、図１では、サーバ１０、認証装置２０、ユーザ端末３０、オーナー端末４０及び登録車両５０は、１つずつ記載しているが、管理システム１に含まれる各構成は、複数存在していてもよい。

サーバ１０は、あらかじめ決められた情報が記憶される装置である。サーバ１０は、認証装置２０、ユーザ端末３０、オーナー端末４０から情報の書き込み及び読み出し可能に構成されるネットワークサーバである。ここでいう情報の書き込みは、サーバ１０に記憶された情報を変更又は削除すること等をいい、情報の読み出しは、サーバ１０に記憶された情報を取得することをいう。

認証装置２０は、登録車両５０を利用しようとする者（以下、ユーザともいう）が利用を許可された者であるか否かを認証する。
認証装置２０は、認証が成立した場合、すなわち、ユーザが登録車両５０の利用を許可された者である場合には、登録車両５０を利用できる状態にする装置である。なお、ここで登録車両５０を利用可能にするとは、登録車両５０のドアを解錠する制御や、登録車両５０のイグニッションスイッチ５２をオンにする制御をいう。

ユーザ端末３０は、登録車両５０のユーザが所有する通信端末である。ユーザ端末３０は、例えば、いわゆるスマートフォンやタブレット端末などであってもよい。
オーナー端末４０は、登録車両５０の所有者（以下、オーナーともいう）が所有する通信端末である。オーナー端末４０は、ユーザ端末３０と同様、例えば、いわゆるスマートフォンやタブレット端末などであってもよい。

登録車両５０は、いわゆるシェアカーやレンタカーなどに用いられる車両である。
また、ユーザ端末３０及び認証装置２０、オーナー端末４０及び認証装置２０は、それぞれ、近接通信を行うことができるように構成される。ここでいう近接通信は、ユーザ端末３０及びオーナー端末４０がそれぞれ認証装置２０を中心としたあらかじめ決められた距離の範囲内である通信範囲内に存在する場合に、ユーザ端末３０及びオーナー端末４０と認証装置２０とが行うことができる通信である。ここで通信範囲内とは例えば、認証装置２０を中心として１０メートル程度の範囲をいう。

＜サーバ１０＞
図２に示すようにサーバ１０は、サーバネットモジュール１１、サーバメモリ１２及びサーバＣＰＵ１３を備える。

サーバネットモジュール１１は、認証装置２０、ユーザ端末３０及びオーナー端末４０とインターネットを通じた通信を行うためのモジュールである。
サーバメモリ１２は、サーバ情報領域１２１及びサーバ制御領域１２２を有する。

図３に示すように、サーバ情報領域１２１は、更に登録ユーザ領域１２１ａ、登録車両領域１２１ｂ及びスケジュール領域１２１ｃに分けられる。
登録ユーザ領域１２１ａには、あらかじめ登録されたユーザに関する情報である登録ユーザ情報及びユーザ連絡先情報が記憶される。

登録ユーザ情報には、ユーザの端末識別情報、個人識別情報及びランク情報が含まれる。
端末識別情報は、ユーザが利用するユーザ端末３０ごとに固有に割り当てられる端末の情報をいう。端末識別情報には、例えば、端末識別番号、端末の電話番号、ＭＡＣアドレスなどが用いられる。また、端末識別番号は、ＩＭＥＩとも言われる。なお、ここでいうＩＭＥＩとはＩｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｅｑｕｉｐｍｅｎｔ Ｉｄｅｎｔｉｔｙの略である。

個人識別情報は、認証装置２０により読み取られることによりユーザを識別するための情報をいう。個人識別情報には、生体情報、動作パターン情報及びパスワードが含まれる。
生体情報は、生体認証に用いられる情報であり、ここでは、指紋の情報をいう。

動作パターン情報とは、身体の動作のパターンを表した情報である。動作パターン情報は、具体的には、手を所定の回数振るなどといった動作を表した情報などであってもよい。
パスワードは、あらかじめユーザにより設定された英数字及び記号などの文字列をいう。

ランク情報は、各ユーザに設定される運転ランクに関する情報である。ここで、各ユーザに設定される運転ランクは、例えば、運転技能の高さを点数化したものであってもよい。具体的には、各ユーザに設定される運転ランクは、いわゆるゴールド免許を所持しているか否かなどの優良運転者であるか否かの情報に基づいて点数化されてもよい。また、運転ランクは、運転歴の情報に基づいて点数化されてもよい。

なお、登録ユーザ情報は、登録ユーザ領域１２１ａに記憶される際に端末識別情報と個人識別情報及びランク情報とが対応付けて記憶される。
ユーザ連絡先情報は、ユーザの連絡先情報である。ここでいう連絡先情報は、インターネットを通じたデータ又は通知を受け取ることができる連絡先を表す。例えば、連絡先は、メールアドレスであってもよい。また、連絡先は、ＳＭＳを利用できる電話番号であってもよい。なお、ここでいうＳＭＳとはショートメッセージサービスの略である。

登録車両領域１２１ｂには、登録車両５０それぞれに関する情報である車両情報が記憶される。
車両情報には、各登録車両５０のオーナー情報、許可ランク情報及び車両スペック、貸出返却位置が含まれる。

オーナー情報には、オーナー端末４０の連絡先情報であるオーナー連絡先情報が含まれる。
許可ランク情報は、各登録車両５０を利用するユーザが登録車両５０を利用が許可されるために必要な運転ランクを表した情報である。ここでいう運転ランクは、上記登録ユーザ領域１２１ａにおいて記憶されるランク情報と対応する。

車両スペックとしては、例えば、各登録車両５０の定員、車種、燃費などを表した情報が含まれる。
貸出返却位置は、登録車両５０の利用を開始、終了する位置をいう。貸出返却位置は、例えば、登録車両５０が通常保管されている場所を示すものであってもよい。すなわち、登録車両５０を利用するユーザは、貸出返却位置に駐車された登録車両５０を利用し、利用後、貸出返却位置に駐車する。なお、貸出返却位置は、貸出位置と返却位置がそれぞれ設定されていてもよく、貸出位置と返却位置とが別の位置に設定されるものであってもよい。

スケジュール領域１２１ｃには、各登録車両５０が利用される時間帯を表したスケジュール情報が記憶される。
スケジュール情報は、例えば図４に示すように、登録車両５０について、登録車両５０を利用するユーザ及びオーナーと、ユーザ及びオーナーが登録車両５０を利用する時間帯と、通常スケジュール情報とを表した情報を含む。図４の例の場合、登録車両５０は、８：００から１０：００まで及び１８：００から２０：００まで登録車両５０のオーナーが利用し、１３：００から１５：００までユーザＡが利用し、１５：００から１７：００までユーザＢが利用する。

また、通常スケジュール情報は、各登録車両５０に対して、ユーザ及びオーナーの予約が無ければ利用できる時間帯を指す。各登録車両５０の通常スケジュール情報は、各登録車両５０のオーナーにより設定される。具体的には、通常スケジュール情報が表す時間帯は、図５に示すように斜線で表した時間帯をいう。図５に示す例では、登録車両５０は、通常６：００から２１：００まで利用可能であることを示している。すなわち、図５に示した通常スケジュール情報に各ユーザ及びオーナーの利用予定時間が書き込まれることにより図４に示すようなスケジュール情報が設定される。

複数の登録車両５０のスケジュール情報が登録された場合、例えば図６に示すように、各登録車両５０に対して、利用するユーザ及びオーナーと、ユーザ及びオーナーが利用する時間帯と通常スケジュール情報とを表した情報を含む。図６の場合、登録車両Ａは、８：００から１０：００まで及び１８：００から２０：００まで登録車両Ａのオーナーが利用し、１３：００から１５：００までユーザＡが利用し、１５：００から１７：００までユーザＢが利用する。また、登録車両Ｂは、１６：００から１８：００までユーザＣが利用する。登録車両Ｃは８：００から１０：００までユーザＣが利用する。すなわち、ユーザＣのように、同じ日に異なる登録車両５０である登録車両Ｂ及び登録車両Ｃを予約することができるように構成されてもよい。

サーバ制御領域１２２には、あらかじめ決められたプログラムが記憶される。ここで、あらかじめ決められたプログラムには、後述するキー発行処理及びキー送信処理を実行するためのプログラムが含まれる。

サーバＣＰＵ１３は、サーバ制御領域１２２に記憶されたプログラムを実行する。
なお、登録ユーザ領域１２１ａが端末記憶部、スケジュール領域１２１ｃが予約記憶部に相当する。

＜登録車両５０＞
図７に示すように、登録車両５０は、ドアロック５１、イグニッションスイッチ５２、着座センサ５３、生体センサ５４、カメラモジュール５５、車両ディスプレイ５６、車両タッチパネル５７及び車両スピーカー５８を搭載する。

ドアロック５１は、登録車両５０の運転席のドアを含む、登録車両５０に配置されたドアの施錠及び解錠を行う。
イグニッションスイッチ５２は、エンジンの始動及び停止を切り替える。ここでは、イグニッションスイッチ５２のオン状態はエンジン動作中、イグニッションスイッチ５２のオフ状態はエンジン停止中を表すものとする。

着座センサ５３は、運転席の座面等に設置され、運転席に着座した者がいるか否かをあらわす信号を出力する。着座センサ５３は、具体的には、あらかじめ決められた重量以上の重量を検知した場合に、運転席に着座した者がいるという信号を出力する重量センサであってもよい。なお、以下では運転席に着座した者を運転者ともいう。

生体センサ５４は、運転者の生体情報を読み取る。ここでは、生体情報とは指紋情報をいう。生体センサ５４は、例えば、登録車両５０の内部の運転席付近に配置されてもよい。具体的には、生体センサ５４は、登録車両５０のステアリングホイールにおいて、運転者が握る部分に配置されてもよい。

カメラモジュール５５は、運転者を少なくとも撮像するモジュールである。カメラモジュール５５は、例えば、登録車両５０のルームミラー付近に配置され、運転席に着座した運転者を撮像するように運転席を向いて設置される。

車両ディスプレイ５６は、画像や文字を表示することにより運転者に情報を提示するディスプレイのモジュールである。
車両タッチパネル５７は、車両ディスプレイ５６の表示画面に重畳して配置され、運転者などのタッチ操作を入力可能な装置である。

車両スピーカー５８は、音声を出力する装置である。
なお、登録車両５０に搭載される各構成は、登録車両５０に搭載される各装置と共用されるものであってもよい。例えば車両ディスプレイ５６及び車両タッチパネル５７は、登録車両５０に搭載されたカーナビゲーションシステムの画面と共用されてもよい。

また、カメラモジュール５５及び車両タッチパネル５７が入力器に相当する。
＜認証装置２０＞
認証装置２０は、図８に示すように、認証ネットモジュール２１、認証近接モジュール２２、認証メモリ２３及び認証ＣＰＵ２４を備える。

認証ネットモジュール２１は、インターネットを通じてサーバ１０と通信を行うためのモジュールである。
認証近接モジュール２２は、近接通信により、認証装置２０の近傍に存在するユーザ端末３０又はオーナー端末４０と通信を行うためのモジュールである。ここで認証近接モジュール２２は、例えばいわゆるキーレスエントリーの通信を行うためのモジュールであってもよい。また、認証近接モジュール２２は、ＲＦ又はＬＦと呼ばれる周波数の電波を用いた通信を行うモジュールであってもよい。なお、ここでいうＲＦはＲａｄｉｏ Ｆｒｅｑｕｅｎｃｙの略であり、ＬＦはＬｏｗ Ｆｒｅｑｕｅｎｃｙの略である。さらに、認証近接モジュール２２は、Ｗｉ−ＦｉやＢｌｕｅｔｏｏｔｈに準拠した通信方式を採用した無線ＬＡＮにより通信を行うモジュールであってもよい。なお、Ｗｉ−Ｆｉ及びＢｌｕｅｔｏｏｔｈは、それぞれ登録商標である。

認証メモリ２３には、登録車両５０を利用可能とする車両利用処理を実行するためのデータが記憶される。
認証メモリ２３は、認証情報領域２３１と認証制御領域２３２とを備える。

認証情報領域２３１には、車両利用処理に用いられるデータである登録ユーザ情報が記憶される。なお、認証情報領域２３１に記憶される登録ユーザ情報の数は１つである。また、認証情報領域２３１において、登録ユーザ情報が記憶される際、登録ユーザ情報に含まれる端末識別情報と個人識別情報及びランク情報が対応付けて記憶される。なお、認証情報領域２３１には、登録ユーザ情報に含まれる端末識別情報、個人識別情報、ランク情報のうち、端末識別情報及び個人識別情報のみが記憶されるものであってもよい。

認証制御領域２３２には、認証ＣＰＵ２４により実行されるプログラムが少なくとも記憶される。ここで、認証制御領域２３２に記憶されるプログラムには、後述する車両利用処理及び救済認証処理を実行するためのプログラムが少なくとも含まれる。

認証ＣＰＵ２４は、認証制御領域２３２に記憶されたプログラムを実行する。
なお、認証情報領域２３１が記憶部に相当する。
＜ユーザ端末３０＞
図９に示すように、ユーザ端末３０は、ユーザディスプレイ３１、ユーザタッチパネル３２、ユーザ生体センサ３３、ユーザカメラモジュール３４、ユーザネットモジュール３５、ユーザ近接モジュール３６、ユーザメモリ３７及びユーザＣＰＵ３８を備える。

ユーザディスプレイ３１は、表示画面を有し、当該表示画面に表示を行うディスプレイのモジュールである。
ユーザタッチパネル３２は、ユーザディスプレイ３１の表示画面に重畳するように配置され、タッチ操作を入力可能とするモジュールである。

ユーザ生体センサ３３は、ユーザ端末３０の所有者であるユーザの生体情報を読み取るモジュールである。ここでいう生体情報は指紋情報である。
ユーザカメラモジュール３４は、撮像を行うモジュールである。

ユーザネットモジュール３５は、サーバ１０とインターネットを用いた通信を行うモジュールである。
ユーザ近接モジュール３６は、ユーザ端末３０の近傍に存在する認証装置２０と近接通信を行うモジュールである。すなわち、ユーザ近接モジュール３６は認証近接モジュール２２と同様の通信方式で通信を行うモジュールである。

ユーザメモリ３７には、あらかじめ決められた情報が記憶される。ユーザメモリ３７は、ユーザ情報領域３７１及びユーザ制御領域３７２を備える。
ユーザ情報領域３７１には、ユーザ情報領域３７１には、認証装置２０による認証に用いられる情報が少なくとも記憶される。また、ユーザ情報領域３７１には、端末識別情報が少なくとも含まれる。

ユーザ制御領域３７２には、ユーザＣＰＵ３８により実行されるプログラムが少なくとも記憶される。なお、ユーザ制御領域３７２には、後述するユーザ登録処理を実行するためのプログラムであるユーザ登録アプリ及び利用予約処理を実行するためのプログラムである利用予約アプリが記憶される。

ユーザＣＰＵ３８は、ユーザ制御領域３７２に記憶されたプログラムを実行する。
＜オーナー端末４０＞
図１０に示すように、オーナー端末４０は、オーナーディスプレイ４１、オーナータッチパネル４２、オーナー生体センサ４３、オーナーカメラモジュール４４、オーナーネットモジュール４５、オーナー近接モジュール４６、オーナーメモリ４７及びオーナーＣＰＵ４８を備える。オーナー端末４０の基本的な構成はユーザ端末３０と同様である。

すなわち、オーナーディスプレイ４１はユーザディスプレイ３１と、オーナータッチパネル４２はユーザタッチパネル３２と、オーナー生体センサ４３はユーザ生体センサ３３と、オーナーカメラモジュール４４はユーザカメラモジュール３４と基本的には同様の構成である。また、オーナーネットモジュール４５はユーザネットモジュール３５と、オーナー近接モジュール４６はユーザ近接モジュール３６と、オーナーメモリ４７はユーザメモリ３７と、オーナーＣＰＵ４８はユーザＣＰＵ３８と、基本的には同様の構成である。

オーナーメモリ４７は、オーナー認証領域４７１及びオーナー制御領域４７２を備える。
オーナー認証領域４７１には、認証装置２０による認証に用いられる情報が少なくとも記憶される。

オーナー制御領域４７２には、オーナーＣＰＵ４８により実行されるプログラムが少なくとも記憶される。
なお、オーナー制御領域４７２には、後述する車両登録処理を実行するためのプログラムである車両登録アプリ及びスケジュール登録処理を実行するためのプログラムであるスケジュール登録アプリが記憶される。また、オーナー制御領域４７２には、ユーザ制御領域３７２に記憶されるプログラムも記憶される。すなわち、オーナー制御領域４７２には、後述するユーザ登録処理及び利用予約処理を実行するためのプログラムを含む。言い換えると、オーナーもオーナー端末４０を、ユーザが所有するユーザ端末３０と同じように利用することができる。

［２．処理］
＜車両登録処理＞
次に、オーナーＣＰＵ４８が実行する車両登録処理について図１１のフローチャートを用いて説明する。

車両登録処理は、管理システム１において管理される登録車両５０に関する情報をサーバ１０に登録するための処理である。
なお、車両登録処理は、オーナーがオーナー端末４０を操作し、オーナーＣＰＵ４８によりオーナー制御領域４７２に記録された車両登録アプリが実行されることにより開始される。

Ｓ１１０で、オーナーＣＰＵ４８は、オーナーが登録を希望する車両の車両情報及び通常スケジュール情報を取得する。具体的には、オーナー端末４０の操作者であるオーナーに、オーナーが登録を希望する車両の車両情報及び通常スケジュール情報を入力するよう促し、入力された情報を取得する。なお、車両情報及び通常スケジュール情報は、入力されることにより取得されるものに限定されるものではなく、あらかじめ記憶された情報を取得してもよい。

Ｓ１２０で、オーナーＣＰＵ４８は、Ｓ１１０で入力された車両情報及び通常スケジュール情報をサーバ１０に送信し、車両登録処理を終了する。サーバＣＰＵ１３は、受信した車両情報をサーバ１０の登録車両領域１２１ｂに書き込む。また、サーバＣＰＵ１３は、受信した通常スケジュール情報をスケジュール領域１２１ｃに書き込む。

＜ユーザ登録処理＞
次に、ユーザＣＰＵ３８が実行するユーザ登録処理について図１２のフローチャートを用いて説明する。

ユーザ登録処理は、登録車両５０を利用するために、登録車両５０を利用する前に、ユーザの情報をサーバ１０に登録する処理である。
ユーザ登録処理は、ユーザがユーザ端末３０を操作し、ユーザＣＰＵ３８がユーザ制御領域３７２に記録されたユーザ登録アプリを実行することにより開始される。

Ｓ２１０で、ユーザＣＰＵ３８は、ユーザの指紋情報を生体情報として取得する。具体的には、ユーザ端末３０の操作者であるユーザに、ユーザ生体センサ３３を用いてユーザの指紋情報を入力するよう促し、入力された指紋情報をユーザの生体情報として取得する。

Ｓ２２０で、ユーザＣＰＵ３８は、ユーザによる入力操作により入力されるユーザの動作パターン情報を取得する。具体的には、ユーザの動作パターン情報を入力するようユーザに促し、入力された情報をユーザの動作パターン情報として取得する。動作パターン情報は、例えば、ユーザ端末３０に搭載されたユーザカメラモジュール３４により取得される映像から読み取ってもよい。

Ｓ２３０で、ユーザＣＰＵ３８は、ユーザによる入力操作により入力されるパスワードを取得する。具体的には、ユーザが任意に設定する文字列を入力するようユーザに促し、入力された文字列をユーザにより設定されたパスワードとして取得する。パスワードの入力は、例えばユーザタッチパネル３２を用いて入力されてもよい。

Ｓ２４０で、ユーザＣＰＵ３８は、ランク情報を生成する。ランク情報は、各ユーザの運転ランクを表した情報であり、運転ランクは運転技能の高さを点数化したものである。ユーザＣＰＵ３８は、まず、ユーザのランク関連情報を取得する。具体的には、ユーザの運転技能についての情報を入力するようユーザに促し、入力された情報をランク関連情報として取得する。ここでいう、ユーザの運転技能についての情報とは、例えば、優良運転者であるか否か、及び、運転歴に関する情報などをいう。そして、ユーザＣＰＵ３８は、ランク関連情報に基づいて運転ランクを算出する。算出される運転ランクが表す点数は、運転技能が高いほど高い値が設定される。そして、算出された運転ランクをランク情報として生成する。

Ｓ２５０で、ユーザＣＰＵ３８は、ユーザ連絡先情報を取得する。なお、ここで取得いうユーザ連絡先情報は、ユーザの連絡先情報をいう。具体的には、例えば、ユーザにユーザ端末３０に入力を促してユーザ連絡先情報を取得してもよいし、ユーザ端末３０にあらかじめ記憶されたユーザ連絡先情報を取得してもよい。

Ｓ２６０で、ユーザＣＰＵ３８は、ユーザ端末３０の端末識別情報をユーザ情報領域３７１から取得する。
Ｓ２７０で、ユーザＣＰＵ３８は、Ｓ２１０からＳ２４０まで及びＳ２６０の処理により取得及び生成された情報を登録ユーザ情報としてサーバ１０に送信する。すなわち、登録ユーザ情報には、端末識別情報、生体情報、動作パターン情報、パスワード及びランク情報が含まれる。なお、生体情報、動作パターン情報及びパスワードを個人識別情報ともいう。また、Ｓ２７０で、ユーザＣＰＵ３８はＳ２６０で取得されたユーザ連絡先情報をサーバ１０に送信する。登録ユーザ情報及びユーザ連絡先情報を受信したサーバ１０のサーバＣＰＵ１３は、登録ユーザ領域１２１ａに当該登録ユーザ情報及びユーザ連絡先情報を書き込む。書き込まれた登録ユーザ情報に対応するユーザを以下では登録ユーザともいう。なお、動作パターン情報及びパスワードが登録入力情報及び登録救済情報に相当する。

Ｓ２７０が端末識別送信部としての処理に相当する。
＜スケジュール登録処理＞
次にオーナーＣＰＵ４８が実行するスケジュール登録処理について図１３のフローチャートを用いて説明する。

スケジュール登録処理は、スケジュール情報に、オーナーが使用するため他のユーザが利用できない時間帯を登録する処理である。
スケジュール登録処理は、１週間ごと又は１日ごと等のあらかじめ決められた周期でスケジュール登録アプリが実行されることにより開始されてもよい。また、当該周期は、オーナーによりスケジュール登録アプリにおいて設定されてもよい。

Ｓ３１０で、オーナーＣＰＵ４８は、オーナースケジュールを取得する。具体的には、オーナーの予定について入力するよう促し、入力された情報をオーナースケジュールとして取得する。

Ｓ３２０で、オーナーＣＰＵ４８は、Ｓ３１０で取得したオーナースケジュールをサーバ１０に送信する。サーバＣＰＵ１３は、スケジュール領域１２１ｃに記憶されたスケジュール情報にオーナースケジュールを書き込み、スケジュール登録処理を終了する。これによりオーナーが登録車両５０を利用する時間帯がスケジュール情報に登録される。

＜利用予約処理＞
次に、ユーザＣＰＵ３８が実行する利用予約処理について、図１４のフローチャートを用いて説明する。

利用予約処理は、登録車両５０の利用を希望する登録ユーザが、利用を希望する登録車両５０と利用を希望する時間をサーバ１０に書き込むことにより予約を行う処理である。
利用予約処理は、登録ユーザがユーザ端末３０を操作し、ユーザＣＰＵ３８がユーザ制御領域３７２に記録された利用予約アプリを実行することにより開始される。

Ｓ４１０で、ユーザＣＰＵ３８は、希望情報を取得する。希望情報は、登録ユーザが利用を希望する登録車両５０に関する車両情報を示す。希望情報には、例えば、利用を希望する車の車両スペック及び利用を希望する時間、貸出返却位置に関する情報を含む。希望情報の取得は、例えば、ユーザディスプレイ３１にユーザタッチパネル３２を用いて希望情報を入力するように登録ユーザに促し、入力された情報を希望情報として取得してもよい。

Ｓ４２０で、ユーザＣＰＵ３８は希望情報を満たす登録車両５０の一覧をユーザディスプレイ３１に表示し、表示された登録車両５０の一覧の中から予約を希望する登録車両５０を選択するように促す。なお、希望情報を満たす登録車両５０の情報は、サーバ１０の登録車両領域１２１ｂから取得する。また、希望情報を満たすか否かは、例えば、車両情報領域１２１ｂに記憶された車両情報を元に判定されてもよい。さらに、登録ユーザのランク情報が許可ランクを満たす登録車両５０を絞り込み、一覧で表示される。

Ｓ４３０で、ユーザＣＰＵ３８は、Ｓ４２０において選択された登録車両５０が予約可能であるか否かを判定する。具体的には、ユーザＣＰＵ３８は、Ｓ４１０で登録ユーザにより入力された希望情報に含まれる利用を希望する時間において、Ｓ４２０において選択された登録車両５０のスケジュール情報が表すスケジュールが空いている場合には、予約可能であると判定する。一方、当該スケジュールが空いていない場合には、予約不可であると判定する。

ユーザＣＰＵ３８は、Ｓ４３０で、Ｓ４２０において選択された登録車両５０が予約不可であると判定した場合、Ｓ４１０に処理を移行し、以降の処理を実行する。
すなわち、希望情報の入力を再度促し、入力された希望情報を満たす登録車両５０の一覧を表示する。

一方、ユーザＣＰＵ３８は、Ｓ４３０で、Ｓ４２０において選択された登録車両５０が予約可能であると判定した場合、Ｓ４４０に処理を移行する。
Ｓ４４０で、ユーザＣＰＵ３８はサーバ１０に予約情報、ユーザ端末３０の端末識別情報及びユーザ連絡先情報を送信する。サーバＣＰＵ１３は、スケジュール領域１２１ｃに受信した予約情報、ユーザ端末３０の端末識別情報及びユーザ連絡先情報を書き込む。ここで、予約情報には、利用する登録車両５０及び利用予定日時が含まれる。

Ｓ４４０が予約情報送信部としての処理に相当する。
＜キー発行処理＞
次に、サーバＣＰＵ１３が実行するキー発行処理について、図１５のフローチャートを用いて説明する。

キー発行処理は、予約情報及びユーザ端末３０の端末識別情報を元に、あらかじめ決められた文字列で表される仮想的なキーであるバーチャルキー（以下、Ｖキーともいう）を生成する処理である。

キー発行処理は、利用予約処理のＳ４４０により、サーバ情報領域１２１に予約情報が書き込まれたタイミングで実行される。
Ｓ５１０で、サーバＣＰＵ１３は、端末識別情報及び予約情報に応じてＶキーを生成する。具体的には、サーバＣＰＵ１３により生成されるＶキーには、各ユーザ端末３０用の端末Ｖキーと認証装置２０用の認証Ｖキーとが含まれる。図１６に示すように端末Ｖキーは、予約情報に応じて生成される。また、認証Ｖキーは、予約情報に加えて端末識別情報に応じて生成される。

Ｖキーの生成はあらかじめ決められたアルゴリズムを用いて生成される。当該アルゴリズムは、予約情報及び端末識別情報ごとにＶキーを生成するアルゴリズムである。すなわち、予約情報又は端末識別情報が異なる場合、異なるＶキーが生成される。つまり、Ｖキーは、予約情報及び端末識別情報に対してユニークに生成される。

当該Ｖキーを生成するアルゴリズムは、予約情報及び端末識別情報を暗号化し、Ｖキーを生成してもよい。なお、暗号化の方式は限定されるものではなく、認証を行うことができれば、Ｖキーを構成する文字列の桁数や文字列の種類は特に限定されない。

Ｓ５２０で、サーバＣＰＵ１３は、Ｓ５１０で生成した端末Ｖキーを、Ｓ４４０で受信されたユーザ連絡先情報が表すユーザ端末３０に送信する。なお、ユーザＣＰＵ３８は、ユーザ端末３０から端末Ｖキーを受信すると、ユーザ情報領域３７１に受信した端末Ｖキーの情報を書き込む。ユーザＣＰＵ３８が当該ユーザ情報領域３７１に受信した端末Ｖキーの情報を書き込む処理が端末キー取得部としての処理に相当する。

Ｓ５１０が端末キー生成部及び認証キー生成部としての処理に相当する。Ｓ５２０が端末キー送信部としての処理に相当する。
＜キー送信処理＞
次に、サーバＣＰＵ１３が実行するキー送信処理について、図１７のフローチャートを用いて説明する。

キー送信処理は、キー発行処理が終了したタイミングで実行される。なお、キー送信処理が実行されるタイミングは、キー発行処理が終了したタイミングに限定されるものではなく、例えば、キー発行処理のＳ５１０で認証Ｖキーが生成された時点で、実行されてもよい。

Ｓ６１０で、サーバＣＰＵ１３は、Ｓ５１０で生成された認証Ｖキー及び当該認証Ｖキーが生成する際に用いられた端末識別情報に対応付けられた登録ユーザ情報を登録ユーザ領域１２１ａから呼び出す。

Ｓ６２０で、サーバＣＰＵ１３は、当該利用予約がされている登録車両５０に対応付けられた認証装置２０にＳ６１０で呼び出した認証Ｖキー及び当該認証Ｖキーに対応付けられた登録ユーザ情報を送信する。なお、認証ＣＰＵ２４は、サーバ１０から認証Ｖキー及び当該認証Ｖキーに対応付けられた登録ユーザ情報を受信すると、受信した認証Ｖキー及び当該認証Ｖキーに対応した登録ユーザ情報を認証情報領域２３１に書き込む。当該認証ＣＰＵ２４が認証情報領域２３１に受信した認証Ｖキー及び当該認証Ｖキーに対応付けられた登録ユーザ情報を書き込む処理が、認証キー取得部としての処理に相当する。

なお、Ｓ６２０で、サーバＣＰＵ１３は、登録ユーザ情報を認証装置２０に送信すると当該認証装置２０に対応した登録車両５０のオーナーのオーナー端末４０に予約がなされた旨を連絡してもよい。

なお、端末Ｖキーと認証Ｖキーとがそれぞれ、端末キー及び認証キーに相当する。またＳ６２０が認証キー送信部としての処理に相当する。
＜車両利用処理＞
次に認証ＣＰＵ２４が実行する車両利用処理について、図１８のフローチャートを用いて説明する。

なお、車両利用処理は、認証装置２０により、ユーザが当該登録車両５０の利用が許可された者であるか否か判定し、利用を許可されたユーザであった場合に登録車両５０を利用できる状態にする処理である。また、ドアロック５１が施錠された状態である場合に適用し、以下説明する。

また、車両利用処理は、例えば登録車両５０に搭載されたドアロック５１を解錠するための操作が行われた際に開始する。ここで、ドアロック５１を解錠する操作とは、例えば、登録車両５０のドアの外側に配置されたドアノブを開ける方向に動かすことをいう。また、ドアロック５１を解錠するための操作は、他にも、登録車両５０のドアの外側などに解錠するボタンを備え、当該ボタンを押下する操作であってもよい。言い換えれば、キーレスエントリーの機能を搭載した車両に対してドアロック５１を解錠する際に行われる操作であってもよい。

Ｓ７１０で、認証ＣＰＵ２４は、ユーザ端末３０のユーザ情報領域３７１に記憶された端末Ｖキーと端末識別情報をユーザ端末３０から取得する。具体的には、認証ＣＰＵ２４は、例えば、ユーザ情報領域３７１に記憶された端末Ｖキー及び端末識別情報を、ユーザ近接モジュール３６を用いて送信するようにユーザ端末３０に要求する。そして、認証ＣＰＵ２４は、送信された端末Ｖキー及び端末識別情報を、認証近接モジュール２２を用いて受信する。これにより当該端末Ｖキー及び端末識別情報を取得する。以下では、ユーザ端末３０により送信される端末Ｖキー及び端末識別情報をまとめて、端末送信情報ともいう。また、ユーザ端末３０が端末送信情報を送信する処理が、端末認証送信部としての処理に相当する。

Ｓ７２０で、認証ＣＰＵ２４は、端末認証が成立したか否かを判定する。具体的には、図１６に示すように、認証ＣＰＵ２４は、取得した端末識別情報を、アルゴリズムを用いて変換する。図１６中「ｚｚｚｚ」で示したものが変換前の端末識別情報であり、「ＺＺＺＺ」で示したものが変換後の端末識別情報である。また、ここでいうアルゴリズムは、サーバ１０において端末識別情報から認証Ｖキーの端末識別情報に対応する部分を生成するアルゴリズムと同様である。すなわち、端末送信情報を送信したユーザ端末３０と記憶されたユーザ端末３０の登録ユーザ情報とが同一であれば、変換された端末識別情報と、記憶された端末識別情報が一致するようにアルゴリズムが設定される。認証ＣＰＵ２４は、Ｓ７１０で取得した端末Ｖキー及び上記アルゴリズムにより変換された端末識別情報を組み合わせたものと認証情報領域２３１に記憶された認証Ｖキーとが一致するか否かを判定することにより端末認証を行う。すなわち、認証ＣＰＵ２４は、Ｓ７１０で取得した端末Ｖキー及び変換された端末識別情報と、認証情報領域２３１に記憶された認証Ｖキーとが一致する場合には、端末認証が成立したと判定し、一致しない場合には、端末認証が不成立であると判定する。

認証ＣＰＵ２４は、Ｓ７２０で、端末認証が不成立であると判定した場合には、車両利用処理を終了する。すなわち、ドアロック５１を解錠することなく、施錠した状態を維持する。

認証ＣＰＵ２４は、Ｓ７２０で、端末認証が成立したと判定した場合には、Ｓ７３０に処理を移行する。
Ｓ７３０で、認証ＣＰＵ２４は、ドアロック５１を解錠する。すなわち、認証ＣＰＵ２４は、当該ドアロック５１の解錠により、ユーザが登録車両５０のドアを開けて、運転席に着座可能な状態にする。

Ｓ７４０で、認証ＣＰＵ２４は、ユーザが運転席に着座したか否か判定する。ここで、ユーザが運転席に着座したか否かは着座センサ５３を用いて判定する。なお、着座したユーザを以下では運転者ともいう。

認証ＣＰＵ２４は、Ｓ７４０で、ユーザが運転席に着座するまで、着座したか否か判定を行う。
一方、認証ＣＰＵ２４は、Ｓ７４０で、ユーザが運転席に着座したと判定すると、Ｓ７５０に処理を移行する。

Ｓ７５０で、認証ＣＰＵ２４は、運転者の認証を行う旨を、車両スピーカー５８を用いて運転者に報知する。
なお、運転者の認証を行う旨の報知は、車両スピーカー５８を用いたものに限定されるものではなく、登録車両５０に搭載された車両ディスプレイ５６を用いてもよい。また、他にも登録車両５０に搭載されるメータなどに表示されてもよい。

Ｓ７６０で、認証ＣＰＵ２４は、認証情報領域２３１に記憶され、認証Ｖキーと対応付けられた登録ユーザ情報に含まれる登録生体情報の呼出を行う。
Ｓ７７０で、認証ＣＰＵ２４は、運転者の生体情報を取得する。具体的には、運転者に対して生体センサ５４に指紋を読み取らせるように促し、登録車両５０に搭載された生体センサ５４を用いて運転者の指紋を生体情報として取得する。

Ｓ７８０で、認証ＣＰＵ２４は、生体認証が成立したか否かを判定する。具体的には、そして、Ｓ７７０で取得した生体情報と、Ｓ７６０で呼び出した登録生体情報とを照合し、一致するか否かを判定する。取得した生体情報と登録生体情報とが一致した場合、生体認証が成立したと判定し、取得した生体情報と登録生体情報とが不一致である場合、生体認証が不成立であると判定する。

認証ＣＰＵ２４は、生体認証が成立したと判定した場合、Ｓ７９０に処理を移行する。
Ｓ７９０で、認証ＣＰＵ２４は、登録車両５０のイグニッションスイッチ５２をオンにし、登録車両５０のエンジンを始動する。

一方、認証ＣＰＵ２４は、生体認証が不成立であると判定した場合、Ｓ８００に処理を移行する。
Ｓ８００で、Ｓ７８０での生体認証をあらかじめ決められた回数である認証回数だけ実行したか否か判定する。ここで、認証回数は、読取の失敗を許容する回数である。すなわち、例えば生体情報の読取をする際の周囲の環境などにより、センサによる生体情報の読取が正しくできず、読取が失敗する可能性がある。そのため、認証回数は、その生体情報の読取の失敗を許容する回数を表す。

認証ＣＰＵ２４はＳ８００での処理を認証回数だけ実行していないと判定した場合には、Ｓ７８０に戻り、生体認証を実行する。すなわち、認証回数だけ実行するまで、Ｓ８００の処理が繰り返し実行される。

一方、Ｓ７９０で、認証ＣＰＵ２４はＳ７８０での処理を認証回数だけ既に実行したと判定した場合には、Ｓ８１０に処理を移行する。
すなわち、認証ＣＰＵ２４は、生体認証を認証回数だけ実行するうちに、認証が成立した場合には、Ｓ７９０に処理を移行し、そうでない場合には、Ｓ８１０に処理を移行する。

Ｓ８１０で、認証ＣＰＵ２４は、救済認証処理を実行する。救済認証処理は、Ｓ７８０での生体認証に認証回数失敗した場合に、イグニッションスイッチ５２がオンにならない状態から、運転者を救済するための処理である。すなわち、救済認証処理は、生体認証が成立しなかったとしても、救済認証処理で認証が成立した場合には、イグニッションスイッチ５２をオンにする処理を実行するための処理である。救済認証処理の詳細は後述する。

Ｓ８２０で、認証ＣＰＵ２４は、Ｓ８１０での救済認証処理により認証が成立したか否か判定する。
認証ＣＰＵ２４はＳ８２０で、Ｓ８１０での救済認証処理により認証が成立したと判定した場合にはＳ７９０に処理を移行し、以降の処理を実行する。すなわち、イグニッションスイッチ５２がオンとなる。

一方、認証ＣＰＵ２４はＳ８２０で、Ｓ８１０での救済認証処理により認証が不成立だったと判定した場合にはＳ８３０に処理を移行する。
Ｓ８３０で、認証ＣＰＵ２４は、警報送信を実行し車両利用処理を終了する。すなわち、イグニッションスイッチ５２をオフの状態で維持する。さらに、警報送信とは、登録車両５０が不正利用されようとしている可能性があることをサーバ１０及びオーナー端末４０等に送信することをいう。

Ｓ７１０が端末取得部としての処理に相当し、Ｓ７２０が端末認証部としての処理に相当する。Ｓ７３０がドア解錠部としての処理に相当し、Ｓ７７０が生体取得部としての処理に相当し、Ｓ７８０が生体認証部としての処理に相当する。Ｓ７９０が利用許可部及びイグニッション部としての処理に相当する。Ｓ８１０が救済認証部としての処理に相当する。

＜救済認証処理＞
次に認証ＣＰＵ２４が車両利用処理のＳ８１０で実行する救済認証処理について、図１９のフローチャートを用いて説明する。

Ｓ９１０で、認証ＣＰＵ２４は、認証情報領域２３１に記憶された認証Ｖキーと対応付けられた登録ユーザ情報の呼出を行う。
Ｓ９２０で、認証ＣＰＵ２４は、動作認証を行う旨を運転者に報知する。ここで、動作認証を行う旨の報知は、車両スピーカー５８を用いて行われる。ただし、動作認証を行う旨の報知は、車両スピーカー５８を用いて行われるものに限られるものではなく、登録車両５０に搭載された車両ディスプレイ５６を用いてもよい。また、他にも登録車両５０に搭載されるメータなどに表示されてもよい。認証ＣＰＵ２４は、登録ユーザ情報に含まれる登録動作情報と対応した動作を行うように促す。ここで、登録動作情報と対応した動作とは、例えば登録動作情報が表す動作と一致する動作をいう。

Ｓ９３０で、認証ＣＰＵ２４は、運転者の動作パターンを読み取る。運転者が行った動作パターンの読取は、例えば登録車両５０に搭載されたカメラモジュール５５を用いて行われてもよい。さらに、着座センサ５３を用いて運転者が行った動作パターンを読み取ってもよい。

Ｓ９４０で、認証ＣＰＵ２４は、動作認証を行う。動作認証とは、Ｓ９１０で呼び出した登録動作情報が表す動作パターンと、運転者が行い、Ｓ９３０で読み取られた動作パターンとを照合することにより行われる認証である。すなわち、登録動作情報が表す動作パターンと運転者が行った動作パターンとが一致する場合に動作認証が成立したと判定する。一方、登録動作情報が表す動作パターンと運転者が行った動作パターンとが異なる場合又は運転者が行った動作パターンが読み取れなかった場合に、動作認証が不成立であると判定する。

認証ＣＰＵ２４は、Ｓ９４０で動作認証が成立した場合、Ｓ９５０に処理を移行する。
Ｓ９５０で、認証ＣＰＵ２４は救済認証が成立したと判定し、救済認証処理を終了する。
一方、認証ＣＰＵ２４は、Ｓ９４０で、動作認証が成立しなかった場合、Ｓ９６０に処理を移行する。

Ｓ９６０で、認証ＣＰＵ２４は、運転者に対して、パスワード認証を行う旨を報知する。ここで、パスワード認証を行う旨の報知は、例えば、車両スピーカー５８を用いて行われる。また、車両ディスプレイ５６にパスワードを入力する入力画面を表示し、車両タッチパネル５７を用いたタッチ操作によりパスワードを入力するように運転者に促す。

Ｓ９７０で、認証ＣＰＵ２４は、Ｓ９６０で車両タッチパネル５７を用いて入力されたパスワードの読取を実行する。
Ｓ９８０で、認証ＣＰＵ２４は、Ｓ９７０で読み取られたパスワードが、Ｓ９１０で呼びだされた登録ユーザ情報に含まれる登録パスワードと一致するか否か判定する。これにより、認証ＣＰＵ２４は、パスワード認証が成立したか否か判定する。すなわち、認証ＣＰＵ２４は、Ｓ９７０で読み取られたパスワードと、登録パスワードとが一致した場合、パスワード認証が成立したと判定する。一方、認証ＣＰＵ２４は、Ｓ９７０で読み取られたパスワードと登録パスワードとが一致しなかった場合又はパスワードが読み取られなかった場合、パスワード認証が成立しなかったと判定する。

認証ＣＰＵ２４は、Ｓ９８０でパスワード認証が成立したと判定した場合、Ｓ９５０に処理を移行し、以降の処理を実行する。
一方、認証ＣＰＵ２４は、Ｓ９８０でパスワード認証が不成立であると判定した場合、Ｓ９９０に処理を移行する。

Ｓ９９０で、認証ＣＰＵ２４は、救済認証が不成立であるとして、救済認証処理を終了する。
Ｓ９２０及びＳ９６０が入力要求部としての処理に相当し、Ｓ９３０及びＳ９７０が入力読取部としての処理に相当し、Ｓ９４０及びＳ９８０が入力認証部としての処理に相当する。Ｓ９５０が救済判定部としての処理に相当する。

［３．効果］
以上詳述した実施形態によれば、以下の効果を奏する。
（１）上記実施形態によれば、車両利用処理において、生体認証が成立しなかった場合、救済認証処理が行われ、救済認証処理において認証が成立すれば、イグニッションをオンにすることができ、登録車両５０を利用することができる。

（２）上記実施形態によれば、利用予約処理のＳ４２０で、ユーザＣＰＵ３８は、許可ランクがユーザの運転ランク以下の登録車両５０に絞り込んで一覧で表示する。そして、当該表示された一覧の中からユーザは登録車両５０を選択する。つまり、登録車両５０のオーナーは、許可ランク情報以上の運転ランクを有するユーザに登録車両５０を貸し出すことができる。

（３）上記実施形態では、利用が許可されたユーザに発行される端末Ｖキーは物理的なキーではなく、ネットワークを通じて、サーバ１０からユーザ端末３０に送信される。このため、登録車両５０のオーナーが登録ユーザに直接物理的なキーを渡す必要がない。その結果、登録車両５０を利用するための鍵を受け渡す手間を省略することができる。

（４）上記実施形態では、車両利用処理のＳ８３０で、認証ＣＰＵ２４は、警報送信を実行する。すなわち、車両利用処理のＳ７２０で、端末認証が成立したにもかかわらず、生体認証又は救済認証が成立しない場合には、ユーザ端末３０が登録ユーザ以外の者により利用されている可能性があると判定し、警報送信を実行する。警報送信により、登録車両５０及びユーザ端末３０が不正に利用されることを抑制することができる。

［４．他の実施形態］
以上、本開示の実施形態について説明したが、本開示は上述の実施形態に限定されることなく、種々変形して実施することができる。

（１）上記実施形態では、ユーザ端末３０及びオーナー端末４０は、スマートフォンやタブレット端末などの通信端末であるとしたが、ユーザ端末３０及びオーナー端末４０は、スマートフォンやタブレット端末に限定されるものではない。たとえばパーソナルコンピュータなどであってもよい。また、ユーザ端末３０及びオーナー端末４０に搭載されるユーザ生体センサ３３及びオーナー生体センサ４３などの各モジュールは、ユーザ端末３０及びオーナー端末４０の外部から接続されるものであってもよい。

（２）上記実施形態では、ランク情報は、各ユーザに設定される運転ランクに関する情報であり、各ユーザに設定される運転ランクは、例えば、運転技能の高さを点数化したものであってもよい。しかし、運転ランクは、運転技能の高さを点数化したものに限定されるものではなく、ランク関連情報も運転技能の高さと関連する情報に限定されるものではない。具体的には、例えば、任意保険に入っているか否かなど、オーナーが登録車両５０を貸し出す上でユーザに安心して登録車両５０を貸し出せるか否かと関連するような情報であればよい。

（３）上記実施形態では、ランク情報は、登録ユーザの入力により生成される。しかし、ランク情報は登録ユーザの入力により生成されるものに限定されるものではない。すなわち、例えば、各登録車両５０に加速度センサなどを設け、登録ユーザが以前に利用した登録車両５０の加速度センサの値などから、運転技能を推定し、ランク情報として生成するものであってもよい。

（４）上記実施形態では、Ｓ４２０において、登録車両５０の許可ランクが登録ユーザのランク情報の表す運転ランク以下である登録車両５０を絞り込み、一覧で表示されるが、ランク情報による登録車両５０の絞り込みは行われなくてもよい。この場合、登録ユーザ情報にランク情報は含まれなくてもよく、また、登録車両５０に許可ランクが設定されていなくてもよい。

（５）上記実施形態では、管理システム１を構成するサーバ１０、認証装置２０、ユーザ端末３０及びオーナー端末４０は、インターネットなどの同一のネットワーク上に配置され、互いに通信可能に接続された。しかし、サーバ１０、認証装置２０、ユーザ端末３０及びオーナー端末４０の間の通信は、インターネットを通じて通信が行われるものに限定されるものではなく、例えば電話回線を通じて通信が行われてもよい。この場合、連絡先情報は、電話番号を表した情報であってもよい。

（６）上記実施形態では、取得する生体情報として指紋情報を例示したが、用いられる生体情報は、指紋情報に限定されるものではない。例えば虹彩の模様などの情報が用いられてもよい。取得する生体情報に虹彩の情報が含まれる場合、虹彩の情報の取得は、例えばユーザ端末３０、オーナー端末４０、登録車両５０に設けられたカメラモジュールを用いてなされてもよく、別途虹彩の情報の読み取りを行う専用のモジュールを搭載してもよい。あるいは、声紋の情報を生体情報として用いてもよい。この場合、ユーザ端末３０、オーナー端末４０、登録車両５０のそれぞれに音声を取得するマイクモジュールを備え、マイクモジュールを用いて声紋を取得する構成であってもよい。

つまり、ユーザ生体センサ３３、オーナー生体センサ４３及び生体センサ５４は、指紋センサに限られず、生体情報の種類に応じたセンサであってもよい。
また、上記実施形態では、ユーザ登録処理は、ユーザ端末３０を用いて行うがユーザ端末３０を用いた構成に限られるものではなく、例えば、登録車両５０に搭載された機材を用いてユーザ登録処理を行ってもよい。この場合、ユーザ端末３０はユーザ生体センサ３３を備えなくてもよい。同様にオーナー端末４０はオーナー生体センサ４３を備えなくてもよい。つまり、生体情報の登録と認証が行える構成であれば、ユーザ端末３０、オーナー端末４０及び登録車両５０それぞれに生体センサが搭載されていなくてもよい。

（７）認証情報領域２３１には１つの登録ユーザ情報が記憶されるとしたが、認証情報領域２３１に記憶される登録ユーザ情報の数は１つに限られるものではなく、複数記憶されてもよい。このような場合、認証装置２０は、端末送信情報を取得した場合に複数の端末識別情報から端末送信情報に含まれる端末識別情報に対応付けられた１つの個人識別情報を選択し、認証に用いる構成を有していてもよい。また、認証情報領域２３１に記憶される登録ユーザ情報の数が複数である場合、利用が予定される複数の登録ユーザのユーザ情報が記憶されてもよい。

（８）端末Ｖキーは、利用する登録車両５０及び利用予定日時を用いて生成され、認証Ｖキーは、ユーザを特定する情報、利用する登録車両５０及び利用予定日時を用いて生成された。そして、ユーザ端末３０が端末識別情報と端末Ｖキーとを送信し、端末識別情報をユーザ端末３０が用いたアルゴリズムと同じアルゴリズムで変換し、端末Ｖキーと変換された端末識別情報と、認証Ｖキーとが一致するか否かを判定した。

しかし、端末Ｖキー及び認証Ｖキーの生成において、端末識別情報が用いられなくてもよい。このような場合、利用する登録車両５０及び利用予定日時の情報を用いて生成されてもよい。

また、端末Ｖキー及び認証Ｖキーの生成において、利用する登録車両５０及び利用予定日時の情報が用いられなくてもよい。このような場合、例えば、キーの発行のタイミングを利用開始時刻となったタイミング、利用開始時刻が迫ったタイミング又は予約された利用予定日時に、現在時刻が含まれるタイミングにキーが発行されるように設定されてもよい。

（９）ユーザ端末３０及びオーナー端末４０に搭載されるユーザカメラモジュール３４及びオーナーカメラモジュール４４は、３次元の動きを検出するいわゆる３Ｄカメラであってもよい。これにより、ユーザカメラモジュール３４及びオーナーカメラモジュール４４を用いて、光軸方向に沿った方向、言い換えると奥行き方向の動きも含めて３次元の動作パターンを登録する構成であってもよい。同様に、登録車両５０に搭載されるカメラモジュール５５もいわゆる３Ｄカメラであってもよい。３次元の動作パターンが登録され他場合には、車両利用処理において、カメラモジュール５５を用いて３次元の動作パターンを取得し、認証を行うことができる。

（１０）上記実施形態では、車両利用処理においてパスワードの入力は、車両タッチパネル５７を用いて入力するが、パスワードの入力方法はこのような方法に限定されるものではない。例えば、車両にマイクを備え、音声入力された言葉を音声認識することによりパスワードが正しいか否か判定されてもよい。

（１１）上記実施形態では、貸出返却位置は、車両情報に含まれ、当該車両情報は、あらかじめ車両登録処理において、登録される。しかしながら、貸出返却位置はあらかじめ登録されるものに限定されるものではない。例えば、貸出位置は、登録車両５０にＧＮＳＳ受信機が搭載されている場合、当該ＧＮＳＳ受信機からの情報を元に、登録車両５０の現在位置を表すものであってもよい。なお、ＧＮＳＳとは、Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｉｔｅ Ｓｙｓｔｅｍの略であり、ＧＮＳＳ受信機は、ＧＮＳＳ衛星からの電波を受信して、ＧＮＳＳ受信機の位置を取得する、衛星測位システムの受信機である。

（１２）上記実施形態において、利用予約処理において、Ｓ４３０で、Ｓ４２０において選択された登録車両５０が予約不可であると判定した場合、Ｓ４１０に処理を移行する。としたが、Ｓ４２０に処理を移行してもよい。すなわち、再度、Ｓ４１０で希望情報の入力を促すことなく、Ｓ４１０で入力された希望情報を維持し、維持した希望情報を満たす登録車両５０の一覧を検索結果としてＳ４２０で表示してもよい。

（１３）上記実施形態において車両利用処理において開始されるタイミングに行われる解錠操作はキーレスエントリーで用いられる操作であるとした。しかし、解錠操作は、ユーザ端末３０に記憶されたアプリにおいて所定の操作をすることにより実行されてもよい。

（１４）上記実施形態において、救済認証では、パスワード認証と、動作パターン認証とが実行されるが、いずれか一方のみが行われる構成であってもよい。また、いずれか一方がランダムに行われる構成であってもよい。

（１５）車両利用処理において端末Ｖキーの取得は、認証ＣＰＵ２４が、ユーザ情報領域３７１に記憶された端末Ｖキーを送信するようにユーザ端末３０に要求し、送信された端末Ｖキーを受信することにより当該端末Ｖキーを取得する。しかし、端末Ｖキーの取得はこのような方法に限定されるものではない。例えば、ユーザ端末３０がユーザ近接モジュール３６を用いて、端末Ｖキーと端末識別情報とをユーザ近接モジュール３６の送信範囲に送信し続ける構成であってもよい。

（１６）また、認証後、ユーザが変更された場合には、再度車両利用処理が実行されてもよい。具体的には、着座センサ５３により、一定時間以上、運転席に着座していないと判定された場合には、認証を要する旨通知されてもよい。これにより、ユーザが認証された後に、当該ユーザ以外の登録されていないユーザなどの別人が運転を代わってしまい、登録車両５０が意図しないユーザに運転されることを防ぐことができる。

さらに、着座センサ５３により、一定時間以上、運転席に着座していないと判定された場合に、認証を要する旨を通知するか否かを認証の種類により変更してもよい。例えば、カメラモジュール５５により顔認証を行い、顔認証を繰り返し実行する場合には、カメラモジュール５５での認証が行えるため、着座センサ５３により一定時間以上、運転席に着座していないと判定された場合に、認証を要する旨の通知をしなくてもよい。

（１７）上記実施形態では、サーバＣＰＵ１３は、キー発行処理又はキー発行処理のＳ５１０で認証Ｖキーが生成された時点でキー送信処理を実行する。しかし、キー送信処理が実行されるタイミングはこのようなタイミングに限定されるものではない。すなわち、利用開始時刻となった時点において認証装置２０に認証Ｖキー及び登録ユーザ情報を取得させてもよい。また、認証装置２０により車両利用処理が開始されたタイミング、すなわち、ユーザが登録車両５０を利用しようとして、ドアロック５１の解錠を行う動作が行われたタイミングで開始されてもよい。具体的には、以下のような順序で実行されてもよい。すなわち、車両利用処理が開始されたタイミングで、認証ＣＰＵ２４が、サーバＣＰＵ１３に、認証装置２０の情報を送信する。そして、サーバＣＰＵ１３が、当該認証装置２０と対応付けられた登録車両５０の当該要求を受けた時刻が利用予約時間に含まれるユーザに対応付けられた認証Ｖキー及び登録ユーザ情報を認証装置２０に送信し、認証装置２０に取得させてもよい。

このような場合、例えば、登録車両５０のドアロック５１を解錠する動作が行われた際に認証装置２０に電源を供給するように構成されてもよい。
（１８）上記実施形態では、ユーザ端末３０ごとに設定される端末識別情報と、ユーザ連絡先情報とを記載したが、ユーザ連絡先情報が例えば電話番号などの端末毎に１つ設定される場合、ユーザ連絡先情報を端末識別情報として利用してもよい。

（１９）上記実施形態では、認証装置２０及び登録車両５０の対応付けは、例えば登録車両５０の製造時など認証装置２０が登録車両５０に搭載される際に行われてもよいとしたが、対応付けが行われるタイミングはこのようなタイミングに限定されるものではない。すなわち、車両登録処理により登録車両５０を管理システム１に登録する際に行われてもよい。この場合、オーナー端末４０を用いて登録する車両情報を入力する際に、当該登録する車両に搭載された認証装置２０を特定する情報を併せて入力するように構成されてもよい。

（２０）上記実施形態において、車両登録処理、ユーザ登録処理、スケジュール登録処理、利用予約処理及びキー発行処理において、情報の送信が行われる。当該処理において、いわゆるフェールセーフとなる処理を含んでもよい。例えば、情報送信がなされなかった場合に、その旨を通知するように構成されていてもよい。また、情報送信が適切に送信されなかった場合に再度送信するように構成されていてもよい。さらに、送信された情報に基づいてメモリへの書き込みが行われなかった場合に、再度情報の送信を要求するように構成されていてもよい。

また、利用予約処理において、Ｓ４２０で、希望情報を満たす登録車両５０の一覧を表示する際に、希望情報を満たす登録車両５０が存在しない場合に、その旨を通知するように構成されていてもよい。

（２１）本開示に記載のサーバメモリ１２、サーバＣＰＵ１３、認証メモリ２３、認証ＣＰＵ２４、ユーザメモリ３７、ユーザＣＰＵ３８、オーナーメモリ４７、オーナーＣＰＵ４８（以下、まとめて制御ユニットともいう）及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の制御ユニット及びその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の制御ユニット及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されてもよい。制御ユニットに含まれる各部の機能を実現する手法には、必ずしもソフトウェアが含まれている必要はなく、その全部の機能が、一つあるいは複数のハードウェアを用いて実現されてもよい。

（２２）上記実施形態における１つの構成要素が有する複数の機能を、複数の構成要素によって実現したり、１つの構成要素が有する１つの機能を、複数の構成要素によって実現したりしてもよい。また、複数の構成要素が有する複数の機能を、１つの構成要素によって実現したり、複数の構成要素によって実現される１つの機能を、１つの構成要素によって実現したりしてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加又は置換してもよい。

（２３）上述した認証装置の他、当該認証装置を構成要素とするシステム、当該認証装置としてコンピュータを機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実態的記録媒体、認証方法など、種々の形態で本開示を実現することもできる。

１…管理システム、１０…サーバ、２０…認証装置、３０…ユーザ端末、４０…オーナー端末。

Claims (11)

1. 車両（５０）に搭載された認証装置（２０）であって、
   前記車両を利用するユーザのうち、あらかじめ登録された前記ユーザを登録ユーザとし、
   前記登録ユーザの生体情報を登録生体情報とし、
   前記登録ユーザの前記生体情報以外のあらかじめ決められた情報を登録救済情報として、
   前記登録生体情報及び前記登録救済情報が記憶されるように構成された記憶部（２３１）と、
   前記ユーザの前記生体情報を読取生体情報として読み取るように構成された生体読取部（Ｓ７７０）と、
   前記生体読取部により読み取られた前記読取生体情報と前記記憶部に記憶された前記登録生体情報とが一致した場合に成立したと判定する生体認証を行うように構成された生体認証部（Ｓ７８０）と、
   前記生体認証が不成立であった場合に、前記登録救済情報を用いたあらかじめ決められた認証である救済認証を行うように構成された救済認証部（Ｓ８１０）と、
   前記生体認証又は前記救済認証が成立した場合に、前記車両の利用を可能とするように構成された利用許可部（Ｓ７９０，Ｓ９５０）と、
   を備える、認証装置。
2. 請求項１に記載の認証装置であって、
   前記ユーザが所有する通信端末であるユーザ端末（３０）から前記認証装置に送信される情報を端末送信情報として取得するように構成された端末取得部（Ｓ７１０）と、
   前記記憶部には、前記登録ユーザが所有する前記ユーザ端末から送信される前記端末送信情報に対応付けられた認証キーがあらかじめ更に記憶され、
   前記端末取得部により取得された前記端末送信情報が、前記記憶部に記憶された前記認証キーと一致する場合に、前記ユーザの前記生体認証及び前記救済認証を実行するように構成された端末認証部（Ｓ７２０）と、
   を備える、認証装置。
3. 請求項２に記載の認証装置であって、
   前記端末送信情報には、当該端末送信情報を送信する前記ユーザ端末それぞれが有する固有の情報である端末識別情報を含み、
   前記認証キーには、前記端末識別情報と対応付けられた情報が含まれる、認証装置。
4. 請求項２又は請求項３に記載の認証装置であって、
   前記端末送信情報には、当該端末送信情報を送信する前記ユーザ端末の所有者である前記ユーザが利用を予定している前記車両及び利用を予定している時間の情報である予約情報に対応付けられた端末キーを含み、
   前記認証キーには、前記端末キーに対応付けられた情報が含まれる、認証装置。
5. 請求項２から請求項４までのいずれか１項に記載の認証装置であって、
   前記端末認証部による認証が成立した場合に、前記車両のドアを解錠するように構成されたドア解錠部（Ｓ７３０）を更に備える、認証装置。
6. 請求項１から請求項５までのいずれか１項に記載の認証装置であって、
   前記登録ユーザの入力操作により入力される入力情報を登録入力情報として、
   前記救済認証部は、
   前記ユーザの前記入力情報を読取入力情報として読み取るように構成された入力読取部（Ｓ９３０，Ｓ９７０）と、
   前記入力読取部により読み取られた前記読取入力情報と前記記憶部に記憶された前記登録入力情報とが一致した場合に成立したと判定する認証を入力認証として、前記入力認証を行うように構成された入力認証部（Ｓ９４０，Ｓ９８０）と、
   前記入力認証が成立した場合に前記救済認証が成立したと判定するように構成された救済判定部（Ｓ９５０）と、
   を備える、認証装置。
7. 請求項６に記載の認証装置であって、
   あらかじめ設定されたパスワード、あらかじめ決められた動きである動作パターンのうちの少なくとも１つを前記入力情報として、前記入力情報を、入力器（５５，５７）を用いて入力するよう要求するように構成された入力要求部（Ｓ９２０，Ｓ９６０）を更に備え、
   前記入力読取部は、前記入力器を用いて入力された前記入力情報を前記読取入力情報として読み取るように構成された、認証装置。
8. 請求項１から請求項７までのいずれか１項に記載の認証装置であって、
   前記生体読取部は、前記車両の内部の運転席付近に搭載された生体センサ（５４）を用いて前記生体情報を読み取るように構成された、認証装置。
9. 請求項１から請求項８までのいずれか１項に記載の認証装置であって、
   前記利用許可部は、
   前記生体認証部又は前記救済認証部による前記救済認証が成立した場合に、前記車両のイグニッションをオンにするように構成されたイグニッション部（Ｓ７９０）を更に備える、認証装置。
10. 車両（５０）に搭載された認証装置（２０）と、
    前記認証装置と通信可能であるサーバ（１０）と、
    を備え、
    前記サーバは、
    前記車両を利用するユーザのうち、あらかじめ登録された前記ユーザを登録ユーザとし、
    前記登録ユーザの生体情報が登録生体情報として記憶されるように構成された生体記憶部（１２１ａ）と、
    前記登録ユーザの入力操作により入力される入力情報が登録入力情報として記憶されるように構成された入力記憶部（１２１ａ）と、
    を備え、
    前記認証装置は、
    前記生体記憶部に記憶された前記登録生体情報を取得するように構成された生体取得部と、
    前記車両に搭載された生体センサ（５３）から前記ユーザの前記生体情報を読取生体情報として読み取るように構成された生体読取部（Ｓ７７０）と、
    前記生体読取部により読み取られた前記読取生体情報と前記生体取得部により取得された前記登録生体情報とが一致した場合に成立したと判定する生体認証を行うように構成された生体認証部（Ｓ７８０）と、
    前記入力記憶部に記憶された前記登録入力情報を取得するように構成された入力取得部と、
    前記車両に搭載された入力器（５５，５７）から、前記ユーザにより入力される前記入力情報を読取入力情報として読み取るように構成された入力読取部（Ｓ９３０，Ｓ９７０）と、
    前記入力読取部により読み取られた前記読取入力情報と前記入力記憶部に記憶された前記登録入力情報とが一致した場合に成立したと判定する認証を入力認証として、前記生体認証が不成立であった場合に、前記入力認証を行うように構成された入力認証部（Ｓ９４０，Ｓ９８０）と、
    前記生体認証又は前記入力認証が成立した場合に、前記車両の利用を可能とするように構成された利用許可部（Ｓ７９０，Ｓ９５０）と、
    を備える、管理システム。
11. 請求項１０に記載の管理システムであって、
    前記車両を利用する前記ユーザが所有し、かつ、前記サーバ及び前記認証装置と通信可能であるユーザ端末（３０）を更に備え、
    前記サーバは、
    前記登録ユーザが所有する前記ユーザ端末それぞれが有する固有の情報である端末識別情報が記憶されるように構成された端末記憶部（１２１ａ）と、
    前記登録ユーザが利用を予定している前記車両及び利用を予定している時間の情報である予約情報が記憶されるように構成された予約記憶部（１２１ｃ）と、
    前記予約記憶部に記憶された前記予約情報から端末キーを生成するように構成された端末キー生成部（Ｓ５１０）と、
    前記端末記憶部に記憶された前記端末識別情報及び前記予約記憶部に記憶された前記予約情報から認証キーを生成するように構成された認証キー生成部（Ｓ５１０）と、
    前記端末キー生成部により生成された前記端末キーを前記ユーザ端末に送信するように構成された端末キー送信部（Ｓ５２０）と、
    前記認証キー生成部により生成された前記認証キーを前記認証装置に送信するように構成された認証キー送信部（Ｓ６２０）と、
    を備え、
    前記ユーザ端末は、
    前記サーバに前記端末識別情報を送信するように構成された端末識別送信部（Ｓ２７０）と、
    当該ユーザ端末を所持する前記登録ユーザの前記予約情報を前記サーバに送信するように構成された予約情報送信部（Ｓ４４０）と、
    前記端末キー送信部により送信された前記端末キーを取得するように構成された端末キー取得部と、
    前記端末キー取得部により取得された前記端末キー及び前記端末識別情報を端末送信情報として、前記認証装置に送信するように構成された端末認証送信部（Ｓ７１０）と、
    を備え、
    前記認証装置は、
    前記認証キー送信部から送信された前記認証キーを取得するように構成された認証キー取得部と、
    前記端末認証送信部から送信された前記端末送信情報を取得するように構成された端末取得部（Ｓ７１０）と、
    前記端末取得部により取得された前記端末送信情報が、前記認証キーと一致する場合に成立したと判定する端末認証を行うように構成された端末認証部（Ｓ７２０）と、
    を備え、
    前記認証装置は、前記端末認証が成立した場合に、前記ユーザの前記生体認証及び前記入力認証を実行するように構成された、管理システム。

Images