JP7066366B2 - システム、及びその方法 - Google Patents

Description

本発明は、ネットワークを介したサービス提供のための認証技術に関する。

近年、移動体デバイス（車両、ドローン、ロボットなど）がマルチユーザーに対してサービスを提供することがある。

例えば、移動体デバイスとしての車両によるシェアカーサービスである。契約顧客の予約に従い、その予約に対応する時間帯にその予約顧客のみが車両を解錠し、車両を利用できるといったサービスである。

他にも、マルチユーザーに利用される移動体デバイスとしてのドローンを用いた宅配サービスなどもある。このサービスでは、宅配先のユーザーについて本人確認された場合に、品物を引き渡すといったことが想定される。ロボットも同様に、案内サービスや行政サービスなど、マルチユーザーから選択的に利用され得る。

ここで、特許文献１では、車両の解錠のためにユーザーの持つ端末で生成した公開鍵を外部サーバーに保存する。ユーザーが車両に対して解錠指示を行った場合に、車両は外部サーバーに対して、ユーザーから送信された指示の検証を依頼し、検証結果に応じて解錠の可否を判断するという開示がある。

特開２０１６－２０８４９４号公報

例えば車両においては、車両自身の位置が可変であるため、例えば携帯電話網の接続可能範囲を超えた場所に移動された場合など、特許文献１に記載されるような外部サーバーと通信できずに解錠できない可能性があり得る。更には、外部サーバーが停止してしまっている場合なども同様に解錠できないため、ユーザービリティが大きく低下してしまう。車両に限らず、移動体デバイスに対してユーザーなど、個別識別をしたうえでサービスを提供するシステムの場合には、同様の課題をもつ。

そこで本発明では、ユーザーが利用する対象デバイスを管理するネットワーク上の外部システムと一時的に接続できない場合であっても、認証した上でその対象デバイスを用いたサービス提供を受けることが可能なシステムを提供することを目的とする。

そこで、本発明におけるシステムは、認証処理を行う際に必要なユーザーの生体情報を格納する耐タンパー性を備える記憶手段と、ユーザーの生体情報を読み取る生体情報センサーと、を有する携帯端末、ユーザーにデバイスの利用のためのサービスを提供するサービス提供システム、及び、前記サービス提供システムにより管理されるデバイス、を含むシステムであって、
前記携帯端末は、前記生体情報センサーにより読み取ったユーザーの生体情報に対応する秘密鍵と公開鍵のペアを生成する第１生成手段と、前記生体情報センサーにより読み取ったユーザーの生体情報と、前記生成された秘密鍵と、を紐付けて前記記憶手段に格納する格納手段と、前記生成された秘密鍵のペアとなる公開鍵を前記サービス提供システムに登録するために送信する登録手段と、を有し、
前記サービス提供システムは、前記携帯端末から受信した前記公開鍵と、前記携帯端末のユーザーが利用すべきデバイスのデバイス情報と、を紐付けて管理する管理手段と、前記管理されたデバイス情報が示すデバイスに対して、該デバイス情報に紐付けて管理されている公開鍵を送信する送信手段と、を有し、
前記デバイスは、前記サービス提供システムと通信できた際に、当該サービス提供システムから受信した公開鍵を保持する保持手段と、前記デバイスに対する操作要求が発生した場合に、検証用のパラメータを生成する第２生成手段と、接続されている前記携帯端末に対して、前記生成されたパラメータを含む認証要求を送信する要求手段と、を有し、
前記携帯端末は、さらに、前記認証要求の受信した場合に、前記生体情報センサーにより読み取られたユーザーの生体情報と、前記記憶手段に格納された生体情報と、を用いた生体認証を実行する認証手段と、前記生体認証に成功した場合には、該生体認証に用いた生体情報に紐付けて前記記憶手段に格納されている秘密鍵と、前記受信した認証要求に含まれるパラメータとを用いて署名データを生成する第３生成手段と、前記生成された署名データを含むレスポンスを前記デバイスに送信する応答手段と、を有し、
前記デバイスは、さらに、前記保持している公開鍵と前記認証要求に含めたパラメータとを用いた、前記レスポンスに含まれる署名データの検証を実行する検証手段と、前記検証に成功した場合に、前記デバイスに対する操作要求を実行する実行手段と、を有し、
前記デバイスに対する操作要求の発生時に、前記保持手段で予め前記公開鍵が保持されていれば、前記サービス提供システムとの通信に失敗する場合であっても、前記認証要求の送信に応じた前記レスポンスに含まれる署名データの検証が実行されることを特徴とする。

本発明によれば、ユーザーが利用する対象デバイスを管理するネットワーク上の外部システムと一時的に接続できない場合であっても、認証した上でその対象デバイスを用いたサービス提供を受けることが可能となる。

本発明に係るシステム全体の構成例を示す図 本発明に係る機器のハードウェアの構成例を示す図 本発明に係る機器のソフトウェアモジュールの構成例を示す図 実施例１における車両操作処理を説明するためのシーケンス 実施例１における車両返却処理を説明するためのシーケンス 実施例１における携帯端末に表示されるＵＩ例 実施例２におけるデバイス利用の開始処理を説明するためのフローチャート 本発明に適用可能なデバイスとしてのドローンのハードウェア構成の一例を示す図

以下、本発明を実施するための最良の形態について図面を用いて説明する。

近年、生体認証を含む新たな認証システムとして、ＦＩＤＯ（Ｆａｓｔ ＩｄｅｎｔｉｔｙＯｎｌｉｎｅの略）が注目されている。生体認証で用いられる指紋や静脈といった生体情報は、外部に情報が流出してしまった場合に、ＩＤ／パスワード認証におけるパスワードと異なり情報を書き換えることができないため、情報漏洩が致命的になる。これに対して、ＦＩＤＯは認証作業を、インターネットを経由してサーバー上で行うのではなく、ユーザーの手元にある端末上で行うため、生体情報がネットワーク上に流れることがなく、情報漏洩のリスクが少ないと言える。

本発明では、ネットワーク接続状態などが変化し、また、マルチユーザーに対してサービスを提供する移動体デバイス（車両、ドローン、ロボットなど）について、ユーザー個別にサービス提供する事前処理に際して、ＦＩＤＯに相当するような認証技術を適用する場合を考える。例えば、車両がシェアカーサービスを実施する場合の解錠処理に際して、本発明に特有な認証システムを適用する。他にも、ドローンなどで宅配サービスを実施する場合に、宅配物を顧客に引き渡す際にも本発明に特有な認証システムを適用することができる。

以降の実施例においては、とくに、車両に本発明に特有な認証システムを適用するケースについて具体的に説明を行うものとする。

（実施例１）
図１は、本発明に係るシステム全体の構成例を示す図である。

本システムは、携帯端末１０１、管理サーバー１０２、認証管理システム１０３、管理対象デバイス１０４及びネットワーク１０５から構成されている。携帯端末１０１、管理サーバー１０２、認証管理システム１０３、管理対象デバイス１０４はネットワーク１０５に接続され、相互に通信することが可能である。

本発明においては、管理サーバー１０２及び認証管理システム１０３が連携することで、管理対象デバイス１０４を携帯端末１０１のユーザーが利用できるサービス提供を実現する。よって、管理サーバー１０２及び認証管理システム１０３を含むシステムを、サービス提供システムと呼ぶ。

ネットワーク１０５は、例えばインターネットなどのＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれであり。またはこれらの組み合わせにより実現される、いわゆる通信ネットワークである。更には、携帯端末１０１と管理対象デバイス１０４は、例えばＢｌｕｅｔｏｏｔｈ（登録商標）やＮＦＣに代表される、近距離無線通信により相互通信することが可能な構成を取る。

管理対象デバイス１０４は、前述したマルチユーザーに利用され得る移動体デバイスであり、本実施例においては、特に車両として説明を行う。

図２は、本発明に係る機器のハードウェアの構成例を示す図。

図２（ａ）は、携帯端末１０１のハードウェア構成図である。

ＣＰＵ２０１は、ＲＯＭ２０３に記憶されたプログラムや、記憶装置２０４からＲＡＭ２０２にロードされたＯＳ（オペレーティングシステム）や各種アプリケーション、後述するシーケンスを実現するための本発明に係るプログラムなどを実行する。すなわち、ＣＰＵ２０１が、読み取り可能な記憶媒体に格納された該プログラムを実行することにより、後述する各フローチャートの処理を実行する各処理部として機能する。ＲＡＭ２０２は、ＣＰＵ２０１のメインメモリであり、ワークエリア等として機能する。タッチパネル２０６は携帯端末１０１の入力機器であり、ＣＰＵ２０１はタッチパネル２０６への操作を検出して、プログラムの制御を行う。ディスプレイ２１１は携帯端末１０１の出力機器の一つであり、ＣＰＵ２０１は各種操作の結果等をディスプレイ２１１に表示することでその結果をユーザーに通知する。ネットワークＩ／Ｆ２０５はネットワーク１０５に対して接続され、ネットワークに接続された機器と相互通信する。近距離通信Ｉ／Ｆ２０７は、例えばＢｌｕｅｔｏｏｔｈなどの近距離通信の入出力を行うＩ／Ｆであり、接続された機器と相互通信を行う。Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ（ＴＰＭ）２０９は、ＯＳや他のハードウェアから独立して機能する耐タンパー性を備えたセキュリティチップで、機密情報を処理・格納するための記憶手段となる。本発明ではＴＰＭ２０９に、生体認証に利用するユーザーの生体情報（またはその特徴量）や、後述される認証処理に必要となる秘密鍵などが格納される。なお、本発明では、ＴＰＭの代替として、耐タンパー性を実現するために１チップ上で他から隔離して動作するセキュアなメモリ空間を確保して、そのメモリ空間でユーザーの生体情報（またはその特徴量）や、秘密鍵などを管理するための記憶手段を提供するといった方法でも実現できる。生体情報センサー２０８は、ユーザーの生体情報を読取るセンサーであり、例えばユーザーの指紋、虹彩、静脈の情報を読み取り信号に変換する。以降では、生体認証で利用される生体情報またはその特徴量については、生体情報を呼ぶ。携帯端末１０１の各構成要素は内部バス２１０に接続され、相互に通信を行うことが可能である。

携帯端末１０１は、ユーザーの所有するスマートフォンや携帯電話などを想定しているが、ＴＰＭ２０９、生体情報センサー２０８、後述の処理を実現するためのプログラムが実行できる環境をもつのであるならば、タブレットやノートＰＣ、ウェアラブル端末などであってもよい。

図２（ｂ）は、管理サーバー１０２、認証管理システム１０３を構成する情報処理装置のハードウェア構成図である。

ＣＰＵ２２１は、ハードディスク２２３からＲＡＭ２２２にロードされたＯＳやアプリケーション、後述するシーケンスを実現するための本発明に係るプログラムなどのプログラムを実行する。ＲＡＭ２２２は、ＣＰＵ２２１のメインメモリであり、ワークエリアなどとして機能する。入力コントローラ２２４は、キーボード２２５や図示しないポインティングデバイス（マウス、タッチパッド、トラックボール等）からの操作入力を制御する。ビデオコントローラ２２７は、ディスプレイ２２８などの表示出力を制御する。ネットワークＩ／Ｆ２２６はネットワーク１０５に接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。管理サーバー１０２、認証管理システム１０３の記憶装置としては、ハードディスク２２３以外にも、ネットワーク上のストレージサービスを利用することも可能である。

図２（ｃ）は、管理対象デバイス１０４のハードウェア構成図である。ここでは車両において、本発明に関連する構成を含む、主要な構成のみに絞って図示して説明している。

エンジンＥＣＵ２４３はエンジン２４４を管理し、エンジンの開始・停止及びエンジンの回転数などの制御を行う。ボディＥＣＵ２４５は例えばドアロックユニット２４６などを管理し、ドアロックユニットの解錠・施錠などの制御を行う。認証ＥＣＵ２４１はメモリ２４２を持ち、近距離通信モジュール２５１及びネットワークモジュール２４７を経由して要求された操作の妥当性を検証した後に、各ＥＣＵに対して操作要求を転送する役割を持つ。エンジンＥＣＵ２４３、ボディＥＣＵ２４５、認証ＥＣＵ２４１は各々ＲＯＭ（不図示）を有しており、ＲＯＭに格納されたプログラムを読み込み実行することにより、各ユニットの制御や、Ｃａｒ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＣＡＮ）２５５に代表されるような車載ネットワークとの通信制御等を行う。ネットワークモジュール２４７はネットワークＩ／Ｆ２４８の制御を行う。ネットワークＩ／Ｆ２４８は、ネットワーク１０５に接続され、ネットワークに接続された他の機器との通信制御処理を実行する。位置情報モジュール２４９は、例えばＧＰＳユニット２５０と接続され、要求に応じて現在の車両の位置情報を提供する。近距離通信モジュール２５１は、近距離通信Ｉ／Ｆ２５２の制御を行う。近距離通信Ｉ／Ｆ２５２は、所謂ＢｌｕｅｔｏｏｔｈやＮＦＣに代表されるような、近距離無線通信の送受信を行うＩ／Ｆである。本実施例においては、近距離通信Ｉ／Ｆ２５２を利用して、管理対象デバイス１０４及び携帯端末１０１が近接していることの確認、及び携帯端末１０１と管理対象デバイス１０４との相互通信を実現する。

センサーモジュール２５３は、各ＥＣＵからの要求に応じて、接続されるセンサーの制御や値の読み出しを行う。また、接続されるセンサーの出力変化を検知して、各種ＥＣＵに対してイベント形式で通知する。タッチセンサー２５４は、人体の接触を感知するためのセンサーである。本発明の実施例においては、ドアノブの裏にタッチセンサーを配し、ユーザーがドアノブに手をかけた事象を検知するために用いられる。

図３は、本発明に係る機器のソフトウェアモジュールの構成例を示す図である。本実施例において、各々の機能モジュール（図示された各ブロック）は、各機器のＣＰＵないしＥＣＵによって実行されるプログラムで実現される処理の主体として例示するものである。一例ではあるが、本実施例では、車両については、各ＥＣＵの処理をわけて図示している。

携帯端末１０１が有する各モジュールについて説明する。

キー生成部３０１は、認証処理に用いる生体情報に紐づく秘密鍵・公開鍵の組を生成する。生体認証部３０２は、生体情報センサー２０８が読み取ったユーザーの生体情報のＴＰＭ２０９への格納や、格納済みの生体情報を用いた生体認証などを制御する。携帯端末１０１のＴＰＭ２０９に格納されるデータの例を表Ａに示す。

表Ａでは、携帯端末１０１が生体認証により利用するサービスに対応する識別情報（ＲＰＩＤ）ごとに、生体情報を識別する認証情報ＩＤと秘密鍵と公開鍵のペアが関連付けて管理されている。認証情報ＩＤは、ＲＰＩＤと秘密鍵と生体情報ＩＤとの組合せに対して割り当てられた識別情報である。なお、ＲＰＩＤには認証が必要となるサービスを識別するためのＩＤが設定される。このＩＤとはサービスのトップレベルドメイン、セカンドレベルドメインの情報を示す。例えば、ショッピングサービスのＵＲＬがｈｔｔｐ：／／ｗｗｗ．ｓｈｏｐｐｉｎｇ．ｃｏｍであった場合に、サービスＩＤはｓｈｏｐｐｉｎｇ．ｃｏｍとなる。生体情報ＩＤは、ＴＰＭ２０９に格納されている生体情報に１対１に割り当てられたユニークな識別情報である。

操作要求部３０３は、携帯端末１０１での各種要求の実行、ネットワークＩ／Ｆ２０５を介したリクエストの送受信などを制御する。表示部３０４は、ディスプレイ２１１に、管理対象デバイス１０４の予約状況など、要求に基づく情報を表示する。表示部３０４は、ウェブブラウザーなどにより実現されるモジュールである。通信制御部３０５は、近距離通信Ｉ／Ｆ２０７などを利用した外部接続を制御する。

管理サーバー１０２が有する各モジュールについて説明する。

デバイス一覧取得部３１１は、ユーザーが利用（予約）可能なデバイスの一覧を含む情報を扱う。デバイス予約部３１２は、デバイスの利用（予約）状況を更新する。デバイス返却部３１３は、デバイスの利用状況について予約、利用などのステータスから返却済みといったステータス（終了状態）に更新する。デバイス管理部３１４は、管理対象のデバイスの機器情報や、各デバイスの利用状況を管理する。レガシー認証部３１６は、ユーザーにより入力されるユーザー情報（ユーザーＩＤ）、パスワードを用いた認証、ログインの処理を行う。

認証管理システム１０３が有する各モジュールについて説明する。

ユーザー登録部３２１は、認証対象となるユーザー毎の登録情報を保存、管理している。ここで管理されるデータの例を表Ｂにそれぞれ示す。例えば、携帯端末１０１のユーザー（ユーザーＩＤ：Ｕｓｅｒ００２）により登録されたデータとして、認証情報ＩＤと公開鍵が登録されている。これは、表Ａで前述した通り、認証情報ＩＤ“１ａｄｘ５ｅ４１ｚｄｄ２ｘ”に関連付けられて携帯端末１０１のＴＰＭ２０９で格納されている秘密鍵に対応する公開鍵が管理されていることがわかる。

検証部３２２は、ネットワーク上の機器（例えば携帯端末）で生成された署名データを、対応する公開鍵を用いて検証する。ユーザー参照部３２３は、管理されているユーザー毎の登録情報を参照し、外部に提供する。

管理対象デバイス（車両）１０４が有する各モジュールについて説明する。

操作要求処理部３３１は、各種要求を受付けて処理する。登録情報保持部３３２は、認証管理システム１０３から提供される利用者（予約者）用の公開鍵などの情報を管理対象デバイス１０４内で保持、管理する。検証部３３３は、認証管理システム１０３の検証部３２２に代わって、署名データを検証する。位置取得部３３４は、位置情報モジュール２４９から管理対象デバイス１０４の現在位置を取得する。通信制御部３３５は、近距離通信Ｉ／Ｆ２５２などを利用した外部接続を制御する。車載ユニット制御部３４１は、ドアロックユニット２４６などを制御し、解錠処理などを行う。操作検出部３４２は、タッチセンサー２５４を介した入力を検出する。

本実施例における機能は、大きく分けて、「携帯端末１０１からの生体情報登録処理」、「携帯端末１０１からの車両予約処理」、「携帯端末１０１からの車両制御処理」、及び「携帯端末１０１からの車両返却処理」の４つから構成される。以下では、これらの機能について、図３の各処理部を用いて説明する。

まず、「携帯端末１０１からの生体情報に基づく登録処理」について説明する。

ユーザーは携帯端末１０１を操作し、管理サーバー１０２が有するウェブサーバー（不図示）が提供するウェブサイトに接続する。携帯端末１０１では、表示部３０４を実現するウェブブラウザーが動作していることが前提である。表示部３０４で表示されるこのウェブサイトに対して、ユーザーはユーザーＩＤ、パスワードを入力すると、レガシー認証部３１６にこの入力情報が渡され、ユーザーのログイン処理が行われる。ここでユーザーＩＤとは、レガシー認証部３１６の認証結果により取得した、ユーザー毎に一意な固有の値を持つ文字列である。入力されたユーザーＩＤは、後述の処理で利用するために記憶媒体２０４に保存される。

次に、ユーザーは、管理サーバー１０２のウェブサイトを介して、クレデンシャルの登録指示を行う。この指示に応じて、管理サーバー１０２は認証管理システム１０３に、クレデンシャルの登録依頼を行う。認証管理システム１０３のユーザー登録部３２１は、この依頼に応じて、「Ｒｅｑｕｅｓｔ Ｐｒｏｖｉｄｅｒ（ＲＰ）ＩＤ」、「Ａｔｔｅｓｔａｔｉｏｎチャレンジ」を含むクレデンシャル作成要求を、携帯端末１０１に送信する。ＲＰＩＤは、サービスを提供する事業者固有のＩＤであり、一般的にはサービス提供事業者のＦＱＤＮが利用される。また、Ａｔｔｅｓｔａｔｉｏｎチャレンジは認証管理システムによって提示されるランダムなバイト列である。

携帯端末１０１では、生体認証部３０２が、クレデンシャル作成要求の受信に応じて、生体情報に基づくクレデンシャルの登録の同意を求める画面をディスプレイ２１１に表示する。ユーザーは、同意する際に、生体情報センサー２０８に対して生体情報（指紋など）を提示する。さらに、キー生成部３０１は、秘密鍵・公開鍵の組を生成する。生体認証部３０２は、クレデンシャル作成要求に含まれるＲＰＩＤ、生成された秘密鍵、生体情報センサー２０８で読み取った生体情報とその生体情報ＩＤ、これら組み合わせに対して割り当てた認証情報ＩＤなどを、ＴＰＭ２０９に格納する。その後、生体認証部３０２は、クレデンシャル作成要求に含まれるＡｔｔｅｓｔａｔｉｏｎチャレンジを秘密鍵で暗号化したデータ（ａｔｔｅｓｔａｔｉｏｎ）と、その秘密鍵に対応する公開鍵と、認証情報ＩＤと、秘密鍵と公開鍵のペアの作成に利用したアルゴリズムなどを含むクレデンシャルを作成する。ここで作成されたクレデンシャルは、操作要求部３０３により、ネットワークＩ／Ｆ２０５を介して、認証管理システム１０３に送信される。

認証管理システム１０３の検証部３２２は、クレデンシャルに含まれるａｔｔｅｓｔａｔｉｏｎを、同クレデンシャルに含まれる公開鍵で復号する。そして、クレデンシャル作成要求に含めたＡｔｔｅｓｔａｔｉｏｎチャレンジと一致するかどうかで、検証処理を実行する。両者が一致していた場合は、ユーザー登録部３２１は、前述のレガシー認証部３１６でログイン認証に用いたユーザーＩＤと、クレデンシャルに含まれる認証情報ＩＤ、公開鍵といった情報とを紐付けて、記憶装置に保存する。

次に、携帯端末１０１からのデバイス（車両）１０４の予約処理について説明する。

ユーザーは携帯端末１０１を操作し、管理サーバー１０２が有するウェブサーバー（不図示）が提供するウェブサイトに接続する。このウェブサイトは、車両予約や、予約状況などを確認するためのサイトであり、表示部３０４によりディスプレイ２１１に表示される。

このサイトから、ユーザーが車種などの条件を入力した上で、予約可能な車両の一覧の表示を指示すると、管理サーバー１０２のデバイス一覧取得部３１１は、デバイス管理部３１４に該条件に合致するデバイスの検索を依頼する。デバイス管理部３１４は、条件に合致する予約可能な車両の一覧を取得する。デバイス一覧取得部３１１は、取得できた一覧を前述のウェブサイトに反映する。

ユーザーは、表示が更新されたウェブサイト上の車両の一覧から予約したい車両を選択する。この選択に応じて、操作要求部３０３により管理サーバー１０２に対して予約対象の車両の情報が送信される。

管理サーバー１０２のデバイス予約部３１２は、選択された車両を予約する前に、携帯端末１０１に対して認証画面を提供する。この画面で、ユーザーが生体認証を選択した場合には、認証管理システム１０３に対して認証依頼が行われる。認証管理システム１０３は、「Ａｓｓｅｒｔｉｏｎチャレンジ」、「トランザクション」などを含む生体認証パラメータを携帯端末１０１に送信する。Ａｓｓｅｒｔｉｏｎチャレンジは、認証管理システム１０３の検証部３２２で生成された、チャレンジレスポンス認証をするために利用する検証用のパラメータである。ここでトランザクションとは、どのような操作が要求されているかをユーザーに提示するための文字列をＢａｓｅ６４でエンコードしたものである。

携帯端末１０１の生体認証部３０２は、生体認証パラメータの受信に応じて、ユーザーに生体認証のための生体情報の提示を促す画面を、ディスプレイ２１１に表示する。生体認証部３０２は、生体情報センサー２０８で読み取った生体情報と、ＴＰＭ２０９に格納済みの生体情報とを用いた生体認証処理を実行する。認証に成功した場合には、認証に用いた生体情報の生体情報ＩＤに対応する秘密鍵をＴＰＭ２０９から取出し、生体認証パラメータに含まれるＡｓｓｅｒｔｉｏｎチャレンジ及びトランザクションを暗号化し、署名データを作成する。なお、暗号化対象をＡｓｓｅｒｔｉｏｎチャレンジのみとしてもよい。生体認証部３０２は、認証に用いた生体情報の生体情報ＩＤに対応する認証情報ＩＤと作成された署名データを含むアサーション（Ａｓｓｅｒｔｉｏｎ）をレスポンスとして生成する。ここで生成されたＡｓｓｅｒｔｉｏｎは、認証管理システム１０３に送信される。

認証管理システム１０３の検証部３２２は、返却されたレスポンスの認証情報ＩＤに対応する公開鍵を取出し、同レスポンスに含まれる署名データの検証を行う。具体的には、公開鍵及び署名データとから得られたデータと、生体認証パラメータに含まれたＡｓｓｅｒｔｉｏｎチャレンジ、トランザクションとを比較して、検証を行うことになる。検証に成功した場合に、その認証情報ＩＤに関連付けて登録されていたユーザーＩＤに対応するユーザーの認証が成功したと判定される。検証部３２２は、認証が成功したことをデバイス予約部３１２に対して通知する。

最後に、デバイス予約部３１２は、認証成功の判定後に、ユーザー選択した車両について、予約処理を依頼する。デバイス管理部３１４では、この依頼を受けて、ユーザー情報（ユーザーＩＤなど）、デバイス情報（車両ＩＤなど）と、ユーザーが入力した条件に含まれる予約開始から終了までの年月日時の情報を登録し、それら予約情報に位置に紐付く予約ＩＤを発行して管理する。デバイス管理部３１４は、予約ＩＤをデバイス予約部３１２に渡す。なお、この際に、ユーザーがウェブサイトから入力した条件に、同乗者の情報が含まれていた場合には、デバイス管理部３１４では、この情報も一緒に登録して管理することになる。予約の完了及び予約ＩＤは、デバイス予約部３１２により、ウェブサイトを介して、表示部３０４がディスプレイ２１１に表示する。

予約処理の完了後に、デバイス管理部３１４により、データベースなどに格納されるデータを表Ｃに示す。

次に、図４に記載の処理シーケンスを用いて、携帯端末１０１から予約車両（管理対象デバイス１０４）を利用する手続きを行う際の処理について詳しく説明する。この例では、一例として解錠処理についての説明を行うが、例えばエンジン始動処理等、デバイス１０４内の機能のいずれかを利用する際にも、同様の手順で実施可能である。携帯端末１０１には車両操作アプリケーションがインストールされ、該アプリケーションが提供する操作画面（ＵＩ）を介して、ユーザーは操作入力を行うことになる。また、車両操作アプリケーションには、前述の予約処理で用いたユーザーのユーザーＩＤなどのプロフィールが登録されているものとする。本処理は、携帯端末１０１上で車両操作アプリケーションが起動されているときに開始されることになる。また、車両操作アプリケーションは、携帯端末１０１内の通信制御部３０５や生体認証部３０３などと連携する。

Ｓ４０１で、携帯端末１０１の通信制御部３０５は、管理対象デバイス１０４の通信制御部３３５に対して接続要求を送信する。Ｓ４０２で、通信制御部３３５は、その要求に対して携帯端末１０１の通信制御部３０５との近距離通信を確立する。この手順で確立した通信路を利用して、携帯端末１０１は管理対象デバイス１０４を操作する。車両１台に対して複数台の携帯端末が接続されうるため、ここでの近距離通信は、例えばＢｌｕｅｔｏｏｔｈなどの、車両をマスターとしたスター型のネットワーク構成であるプロトコルが望ましい。しかし、その他のネットワーク構成を持つプロトコルであっても、本実施例に記載の操作を実施することは可能である。

Ｓ４０３でのユーザーによる管理対象デバイス１０４に対する解錠の操作入力の検出に応じて、Ｓ４０４で、操作要求部３０３は、管理対象デバイス１０４に対して操作要求を送信する。この要求には、要求する操作内容（解錠）の他に、要求を発行したユーザーのユーザーＩＤが含まれる。

Ｓ４５０で、管理対象デバイス１０４の操作要求処理部３３１は、管理サーバー１０２、認証管理システム１０３との少なくともいずれかとの通信が可能かどうか判定する。これは、専用の通信テストを行ってもよいし、後述する予約の照会要求や検証用の情報の取得要求に成功するかどうかで判定してもよい。通信可能な場合にはＳ４０５に進み、通信できない場合にはＳ４１０に進む。

Ｓ４０５で、操作要求処理部３３１は、管理サーバー１０２に対して、予約の照会要求を送信する。この要求にはユーザーＩＤ、管理対象デバイス１０４のＩＤ（車両ＩＤ）が含まれる。予約ＩＤがユーザーによって入力されていた場合には予約ＩＤが含まれていてもよい。Ｓ４０６で、管理サーバー１０２のデバイス管理部３１４は、予約ＩＤ、ユーザーＩＤ及び車両ＩＤを元に、前述の表Ｃを参照し、予約情報を特定する。Ｓ４０６で、デバイス管理部３１４は、特定された予約情報を管理対象デバイス１０４に対して応答する。

Ｓ４０７で、操作要求処理部３３１は、取得した予約情報に含まれるユーザーＩＤ及び、同乗者のユーザーＩＤに対応するユーザーの生体認証を検証するための情報を、認証管理システム１０３に要求する。Ｓ４０８で、認証管理システム１０３のユーザー参照部３２３は、表Ｂから、ユーザーＩＤ及び、同乗者のユーザーＩＤに関連付けて保存されている情報を特定し、管理対象デバイス１０４に対して応答する。ここで特定された情報には、認証情報ＩＤや公開鍵が含まれる。

なお、Ｓ４０７における検証用の情報の取得要求は、管理サーバー１０２に対して送信してもよい。その場合には、管理サーバー１０２が認証管理システム１０３に検証用の情報を問合せ、該当する情報を取得することで、管理サーバー１０２が検証用の情報を管理対象デバイス１０４に応答することになる。

Ｓ４０９で、ユーザー登録情報保持部３３２は、予約情報および検証用の情報をメモリ２４２に保存する。ここで保存される情報の一部を表Ｄに示す。図示しないが、認証情報ＩＤなど、その他の情報も表ＤでユーザーＩＤなどに紐付けて管理される。

本実施例では、表Ｄで管理される情報について、有効期限は、予約開始日時、予約終了日時より判断される。表Ｄで予約終了日時を過ぎてしまったレコードについては、ユーザー登録情報保持部３３２によって定期的、もしくは表参照時に削除されることになる。

Ｓ４１０で、操作要求処理部３３１は、表Ｄを参照し、登録情報保持部３３２内に、携帯端末１０１から送信されたユーザーのＩＤに紐づく公開鍵などの検証に必要な情報が保存されているか否か、さらに、その有効期限が有効期限内であるかを判定する。公開鍵の登録があっても、予約開始日時より前、または予約終了日時の経過後の管理対象デバイス１０４に対する操作指示は、有効な公開鍵が存在しないと判定される。有効な公開鍵などが既に保存されていた場合には、Ｓ４１１に進む。一方で、有効な公開鍵が存在しない場合は携帯端末１０１に対して予約なしと通知され、本シーケンスによる処理が終了する。

なお、Ｓ４１０による判定処理は、Ｓ４５０の判定処理の前か、または、Ｓ４５０の判定処理でＹＥＳと判定された場合にも実行してよい。それら何れかの時点の判定で有効な公開鍵の存在が確認できた場合には、その判定からＳ４０９までの処理を省略してもよい。

Ｓ４１１で、管理対象デバイス１０４の検証部３３３は、Ａｓｓｅｒｔｉｏｎチャレンジ、トランザクションを生成して、Ｓ４１２でそれらを含む認証要求を携帯端末１０１に対して送信する。認証要求にはＲＰＩＤも含まれる。なお、ここで生成されるＡｓｓｅｒｔｉｏｎチャレンジ、トランザクションは、前述した認証管理システム１０３の検証部３２２が生成するものと同等である。ＲＰＩＤは、該公開鍵を携帯端末１０１が認証管理システム１０３に登録した際に利用されていたものと同一のＩＤである。このＲＰＩＤは、管理対象デバイス１０４内で予め管理しておいてもよいし、Ｓ４０６、Ｓ４０８などのタイミングで取得してもよい。

Ｓ４１３で、携帯端末１０１の生体認証部３０２は、認証要求の受信に応じて、ユーザーに生体認証のための生体情報の提示を促す画面を、ディスプレイ２１１に表示する。Ｓ４１４で、生体認証部３０２は、生体情報センサー２０８で読み取った生体情報と、ＴＰＭ２０９に格納済みの認証要求に含まれるＲＰＩＤに紐付く生体情報と、を用いた生体認証処理を実行する。認証に成功した場合には、Ｓ４１５で、生体認証部３０２は、認証に用いた生体情報の生体情報ＩＤに関連付けられている秘密鍵をＴＰＭ２０９から取出す。そして、生体認証部３０２は、認証要求に含まれるＡｓｓｅｒｔｉｏｎチャレンジ及びトランザクションを暗号化し、署名データを作成する。なお、暗号化対象をＡｓｓｅｒｔｉｏｎチャレンジのみとしてもよい。生体認証部３０２は、認証に用いた生体情報の生体情報ＩＤに対応する認証情報ＩＤと作成された署名データを含むアサーション（Ａｓｓｅｒｔｉｏｎ）をレスポンスとして生成する。Ｓ４１６で、携帯端末１０１の通信制御部３０５は、ここで生成されたＡｓｓｅｒｔｉｏｎを含むレスポンスを、管理対象デバイス１０４に送信する。

Ｓ４１７で、管理対象デバイス１０４の検証部３３３は、レスポンスに含まれるアサーションと、公開鍵とを用いて、検証処理を実行する。この検証処理は、前述した認証管理システム１０３の検証部３２２で行われるアサーションの検証処理と同じ処理である。検証に成功した場合には管理対象デバイス１０４を予約済みのユーザーＩＤに対応するユーザーの生体認証が成功したとみなされ、Ｓ４１８で、操作要求処理部３３１はボディＥＣＵ２４５の車載ユニット制御部３４１に対して、解錠処理を行うように通知する。これにより、管理対象デバイス１０４のドアが解錠される。Ｓ４１９で、通信制御部３３５は、操作結果（解錠成功）を通知する。Ｓ４２０で、携帯端末１０１の表示部３０４は、ディスプレイ２１１を介してユーザーに操作結果を通知する。

図６は、携帯端末１０１の車両操作アプリケーションが提供するＵＩの一例ある。図６（ａ）は、携帯端末１０１と管理対象デバイス１０４とが近距離通信を確立していない状態の、図６（ｂ）は、携帯端末１０１と管理対象デバイス１０４とが近距離通信を確立している状態でのＵＩを示す。

接続ステータス表示部６０１には、携帯端末１０１と管理対象デバイス１０４との接続状態が表示され、公開鍵取得ステータス表示部６０２には、管理対象デバイス１０４が接続しているユーザーの公開鍵を所持しているか否か、の情報を表示する。ボタン６０３～６０６はそれぞれ管理対象デバイス１０４及び管理サーバー１０２への操作指示を送信するためのボタンを有している。

図６（ａ）では、ボタン６０３、６０４、６０５は管理対象デバイス１０４に対して指示を送信するためのボタンであるため、管理対象デバイス１０４と近距離通信を確立していない場合においては無効であることがわかるように表示される。一方、図６（ｂ）に示すように、管理対象デバイス１０４との近距離通信が確立されている場合は、ボタン６０３、６０４、６０５が有効な表示に切り替えられる。ボタン６０３を押下することで、図４に記載の処理シーケンスが開始されることになる。また、ボタン６０６を押下することで、後述する図５に記載の処理シーケンスが開始されることになる。

また、図６（ｂ）で、管理対象デバイス１０４との近距離通信が確立されている場合は、公開鍵取得ステータス表示部６０２に、登録情報保持部３３２が予約ユーザーの公開鍵を複製して所持しているか否か、を表示することもできる。これにより、ユーザーは管理対象デバイス１０４がネットワークに接続していない時に操作できない状態であることを察知し、一度解錠処理を実施する等、対策を行うことが可能となる。

なお、管理対象デバイス１０４としての車両は、外部システムとネットワーク通信可能な所定の駐車場所に駐車され、返却されることを想定している。つまり、予約ユーザーがその所定の駐車場所に車両を取りに行き、初回利用を開始する時点では、外部システム（認証管理システム）と通信できる可能性が高く、予約情報や検証用の情報の管理対象デバイス１０４のメモリ２４２に保存することができる。その後、車両が移動した先で、外部システム（認証管理システム）と通信できない場合があり得る。その場合には、本シーケンスにより、有効な公開鍵などが予め管理対象デバイス１０４に既に登録済みなので、予約ユーザーの携帯端末における生体認証を検証することが可能となる。つまり、移動先で施錠した後の再解錠などの操作について、予約ユーザーの携帯端末の生体認証を車両内で検証することで、盗難防止など、セキュアな操作が適切に行えることになる。

管理対象デバイス１０４がドローンやロボットであっても同様である。宅配サービスなどにおいては、荷物の積み込み地点では外部システム（認証管理システム）と通信できる可能性が高い。このタイミングで、ドローンやロボットには利用者情報や検証用の情報（公開鍵など）が保存される。ここで、受け渡し先にドローンが到着した際に、外部システム（認証管理システム）と通信できない場合でも、ドローンやロボット内部で、利用者の携帯端末の生体認証を検証することができ、安全な受け渡しが可能となる。

次に、図５に示す処理のシーケンスを用いて、管理対象デバイス１０４（車両）の返却処理について説明する。携帯端末１０１には、前述の通り、車両操作アプリケーションがインストールされ、該アプリケーションが提供する操作画面を介して、ユーザーは操作入力を行うことになる。

Ｓ５０１で、携帯端末１０１は操作画面を介して、ユーザーによる車両の返却操作を検出する。Ｓ５０２で、操作要求部３０３は、管理サーバー１０２に対して管理対象デバイス１０４の返却要求を送信する。

Ｓ５０３で、管理サーバー１０２のデバイス返却部３１３は、認証管理システム１０３に認証の依頼を送信する。

Ｓ５０４で、認証管理システム１０３の検証部３２２は、Ａｓｓｅｒｔｉｏｎチャレンジ、トランザクションを生成して、Ｓ５０５でそれらを含む認証要求を携帯端末１０１に対して送信する。認証要求にはＲＰＩＤも含まれる。認証要求を受け取った携帯端末１０１における処理（Ｓ５０６～Ｓ５０９）は、図４のＳ４１３～Ｓ４１６の処理と同様であるための説明を省略する。図６（ｃ）は、Ｓ５０６で表示される、ユーザーに対して生体情報の提示を促すための画面の一例である。メッセージ表示部６１０には、トランザクションをＢａｓｅ６４デコードした文字列（６１１）及び、生体情報の入力を要求されている旨を表示している。

また、Ｓ５１０での認証管理システム１０３の検証部３２２のアサーションに含まれる署名データの検証処理も、前述された処理（例えば、Ｓ４１７）と同様であるため説明を省略する。Ｓ５１１で、検証部３２２は、検証結果を管理サーバー１０２に通知する。通知された結果が検証の成功を示していた場合には、Ｓ５１２で、位置取得部３３４は、返却要求で指定されるデバイスＩＤ（車両ＩＤ）に対応する管理対象デバイス１０４と通信を開始する。さらに、管理対象デバイス１０４に対して、位置情報の取得要求を送信する。

Ｓ５１３で、管理対象デバイス１０４の位置取得部３３４は、位置取得要求の受信に応じて位置情報モジュール２４９から管理対象デバイス１０４の現在位置を取得し、Ｓ５１４で取得した位置情報を応答する。ここで管理対象デバイス１０４の現在位置は、車両が確かに返却場所に存在することを検証するために利用される。本実施例では、ＧＰＳなどの測位システムを利用した結果を取得してその値を返すことを想定しているが、例えばＢｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙのビーコンなどを返却場所に設置し、車両がビーコンの信号を受信することにより返却場所に近接しているかを判断しても良い。

Ｓ５１５で、管理サーバー１０２のデバイス返却部３１３は、管理対象デバイス１０４に対して、公開鍵などの登録情報の削除依頼を送信する。削除依頼には、返却要求に含まれていたユーザーＩＤなどが含まれる。

Ｓ５１６で、登録情報保持部３３２は、削除依頼に従い、ユーザーＩＤに紐付く公開鍵などの登録情報をメモリ２４２から削除し、Ｓ５１７でその結果（削除完了）を、管理サーバー１０２に通知する。

Ｓ５１８で、管理サーバー１０２のデバイス返却部３１３は、返却要求で指定されるデバイスＩＤ（車両ＩＤ）とユーザーＩＤに該当する予約情報を参照し、当該デバイスＩＤ（車両ＩＤ）についての予約状況で示すステータスを返却済みに変更する。Ｓ５１９で、携帯端末１０１に対して処理結果（返却処理の完了）が通知され、Ｓ５２０で表示部３０４はディスプレイ２１１に処理結果を表示する。図６（ｄ）は、表示部３０４による操作結果の表示画面である。図６（ｃ）と同様にメッセージ表示部６１０を持ち、ユーザーが操作（返却処理）を行った結果をユーザーに対して通知することが可能となっている。

なお、本実施例では携帯端末１０１からの管理対象デバイス１０４に対する図４で示す操作が開始された際に、Ｓ４０５～Ｓ４０９で行われた公開鍵などの検証用の情報の管理対象デバイス１０４への登録（複製処理）が行われることを説明した。しかしながら、この複製処理はこのタイミングに限定されない。以下のようなタイミングでの処理も実行することにより、管理対象デバイス１０４に対する検証用の情報の登録が確実になる。

例えば、携帯端末１０１から管理サーバー１０２に対して車両予約処理を行う際に、デバイス予約部３１２が、予約が成功した管理対象デバイス１０４に対して、Ｓ４０５～Ｓ４０９で行われる処理を実行するように依頼してもよい。この依頼を受けて、操作要求処理部３３１が複製処理を実行する。

他にも、管理対象デバイス１０４の管理対象デバイス１０４が、携帯端末１０１や管理サーバー１０２からの依頼なしに、定期的に、近日中の予約情報を管理サーバー１０２に対して照会要求して、予約情報を取得するようにしてもよい。予約情報が取得できた場合は、Ｓ４０７～Ｓ４０９の処理を実行して、複製処理を実現する。これにより、管理サーバー１０２で予約情報（キャンセル、予約開始日時及び終了日時、公開鍵）の更新が行われた場合に、即座に対応することができる。

（実施例２）
実施例１では、携帯端末の車両操作アプリケーションからのユーザー操作を起点として解錠処理を実施する例を示した。本実施例においては、車両に対する操作を起点とした解錠処理を実施する例を示す。

図７は、実施例２における管理対象デバイス１０４（予約車両）の利用を開始する際の処理について説明するためのフローチャートである。この例では、図４と同様に、一例として解錠処理についての説明を行うが、例えばエンジン始動処理等、デバイス１０４内の機能のいずれかを利用する際にも、同様の手順で実施可能である。

なお、本処理においては、実施例１で説明したいずれかのタイミングで、予約ユーザーの予約情報や検証用の情報（公開鍵など）が、管理対象デバイス１０４のメモリ２４２に保存されているものとする。また、管理対象デバイス１０４には、１台以上の携帯端末が近距離接続されていてもよい。少なくとも、管理対象デバイス１０４の操作を行うデバイス付近に存在するユーザーの携帯端末は、（近距離）無線通信機能を有効にしていることを前提とする。

Ｓ７０１で、操作検出部３４２がタッチセンサー２５４を介したユーザーによる管理対象デバイス１０４の操作を検出する。具体的には、車両のドアノブに対する操作、ハンドルをグリップする操作などである。これらの検出に基づき、ドアの解錠やエンジンの始動処理を行うかどうかを以下の処理で判定する。

Ｓ７０２で、登録情報保持部３３２は、有効な公開鍵など、検証に必要な情報が認証管理システム１０３から複製され、管理対象デバイス１０４内のメモリで保存されているかを確認する。有効な公開鍵が存在している場合はＳ７０４に進み、そうでない場合にはＳ７０３に進む。Ｓ７０３では、近距離無線で接続されている携帯端末（少なくとも管理対象デバイス１０４を操作したユーザーの携帯端末が含む）に対して、予約なしを通知する。

Ｓ７０４で、検証部３３３は、Ｓ４１１と同様に、Ａｓｓｅｒｔｉｏｎチャレンジ及びトランザクションを生成する。そして、Ｓ７０５で、通信制御部３３５は、生成したデータを近距離無線で接続されている携帯端末（少なくとも管理対象デバイス１０４を操作したユーザーの携帯端末が含む）に対して、認証要求として送信する。

認証要求を受信した携帯端末では、Ｓ４１３～Ｓ４１６で前述した、生体認証を含む処理が実行される。

Ｓ７０６で、検証部３３３は、携帯端末からアサーションを含むレスポンスを受信する。Ｓ７０７で、検証部３３３は、アサーションに含まれる署名データの検証処理を実行する。これはＳ４１７で前述した処理と同様の処理である。検証処理では、自身のメモリ内に格納され、有効期限内である公開鍵を全て順番に利用して、検証に成功するものがあるか否かを試行してもよい。管理対象デバイス１０４内には、予約ユーザー、もしくはその同乗者のユーザーＩＤに対応する公開鍵のみが登録されているためである。

検証処理に成功、つまりは、予約ユーザーの携帯端末での生体認証の検証に成功した場合には、Ｓ７０８で、操作要求処理部３３１はボディＥＣＵ２４５の車載ユニット制御部３４１に対して、解錠処理を行うように通知することでドアを解錠する。

Ｓ７０９で、通信制御部３３５は、操作の実行結果（解錠成功）を、近距離無線で接続されている携帯端末（少なくとも管理対象デバイス１０４を操作したユーザーの携帯端末が含む）に対して送信する。

（応用例１）
本発明は、前述でも触れたが、管理対象デバイス１０４としてのドローンなどの飛行体デバイスが提供する宅配サービスにおいても応用できる。具体的には、ドローンにより実現した移動式の宅配ボックスで、１以上の顧客に宅配物を届けることを想定する。この場合にも、宅配物の受け渡しに際して、本発明における認証システムを適用できる。

ドローンによる宅配サービスを申請したユーザーは、認証管理システム１０３を含むサービス提供システムに対して検証用の情報（公開鍵など）を登録するものとする。登録時には、実施例１と同様に、宅配物の受け取り時に利用するユーザーの携帯端末による生体認証を前提としたクレデンシャルの登録処理が実行されることになる。

図８に、ドローンのハードウェア（ＨＷ）構成の一例を示す。ドローン８００のＨＷ構成は携帯端末１０１と似た構成を取る。携帯端末と同等の機能を有するものは同じ符号を付与し、説明を省略する。

モーター８０１は、ＣＰＵ２０１により制御され、接続されているプロペラ８０２の回転数を制御する。回転数を増加させることでドローンは離陸、移動し、回転数を減少させることで着陸動作を行う。方位検知センサー８０３は、飛行しているドローン８００の方位を検知するために用いる。ジャイロセンサー８０４は、ドローン８００の傾きを検知するために用いる。加速度センサー８０５は、ドローン８００の加速度を検知するために用いる。ＧＰＳセンサー８０６は、ドローン８００が現在の自機の位置を検知するために用いる。これらのセンサーを利用することで、ドローン８００は自機の位置や現在の状態を把握し、自立して飛行することが可能となっている。ドローン８００は更に、荷物を格納するための格納庫８０８及び、格納庫の鍵であるキーロック８０７を有す。キーロックを解除する時に生体認証で本人確認を行うことにより、宅配を依頼した人物本人以外が荷物を受け取ることができない。そのため、ドローンによる宅配時であっても、現在宅配物を配送する人が確認する以上の本人確認方法を提供することが可能となる。

ドローンによる宅配時のシーケンスは、図４に示すものと同等である。図４のシーケンスにおいては、初回の解錠操作時に車両に公開鍵をコピーしたが、先に述べたように公開鍵の提供タイミングは初回解錠時に限定されない。ドローンを利用した宅配時には、荷物の配送先をドローンに入力する際に合わせて公開鍵を複製しても良い。有効な公開鍵を宅配前に事前にドローンに提供する事により、ユーザーの元に宅配物を送付した際に、インターネットに接続できない状態にあっても、ユーザーの持つ秘密鍵を検証することが可能となる。その結果ドローンの宅配結果がネットワーク状態に依存しなくなり、認証できない場合に荷物を持って引き返す、という事態が発生しなくなる。

車両の場合はＳ４１８において車両のドアロックの解錠などが行われたが、ドローンの場合はＳ４１８においてドローン８００のキーロック８０７を解錠するように制御される。

更に、ドローンで１顧客ずつ宅配することを想定した場合には、ユーザーの携帯端末との通信により解錠された後、宅配物が取り出された後などに、公開鍵などの検証用の情報を削除してもよい。また、公開鍵を宅配前に複製する際に、それ以前に保存された検証用の情報を削除してから、新しい公開鍵を複製しても良い。

（応用例２）
本発明は、公共施設やオフィスなどに設置され、複数の顧客などのユーザーに案内サービスなどを提供するロボットを管理対象デバイス１０４として応用できる。

案内ロボットについては、移動や災害などによりネットワーク接続状況が変化した場合であっても、特定のユーザーを安全に生体認証して、サービス提供することが求められる可能性がある。

さらに、本発明は、ユーザーの自宅、民泊などのシェアハウスの玄関や、金庫などの電子ロック機構を持つドアを含むデバイスも、管理対象デバイス１０４として応用できる。ホームネットワークとサービス提供システムとが通信できなくなった場合であっても、電子ロック機構を持つデバイスが、事前にサービス提供システムから検証に必要な公開鍵などの情報を複製しておくことで、正規のユーザーが保有する該ユーザーによる生体認証を検証した上で、解錠が可能となる。民泊などの場合は、実施例１で説明したシェアカーと同様に、顧客の予約した滞在期間が有効期限として利用されることになる。

（応用例３）
さらに、本発明の管理対象デバイス１０４としては、出力物の取出し部分に電子ロック機構を持つドアを備えているプリンターや複合機などの画像処理装置にも応用できる。また、画像処理装置において特殊な印刷などの処理を行う場合においても、その操作を実行する前に本発明における携帯端末による生体認証を行わせてもよい。この場合には、画像処理装置内の記憶手段に、認証管理システム１０３で管理される公開鍵などの検証に必要な情報が複製され、登録されていることになる。

（応用例４）
本発明は、さらに、セキュリティを考慮した機能を追加することも想定している。具体的には、本発明が適用された管理対象デバイス１０４（車両、ドローン、ロボットなど）は、解錠など生体認証に応じたサービス提供を行った際には、その日時や環境情報、認証ユーザーのＩＤやその操作履歴など、様々な情報を履歴として、デバイス内の記録装置に記録する。ネットワークに接続できた場合には、これら履歴情報は、管理サーバーに送信される。

さらに、履歴内には、管理対象デバイス１０４に設置されたカメラ（不図示）により撮影した撮影画像データや、不図示のセンサーによる検出情報も一緒に記録されることが望ましい。これにより、遠隔地で移動体がサービス提供する場合においても、その状況が後からトレース可能になり、本発明が提供する利便性に加えて、セキュリティも向上することになる。

（他の実施例）
本発明は、上述した実施形態を適宜組み合わせることにより構成された装置あるいはシステムやその方法も含まれるものとする。

ここで、本発明は、上述した実施形態の機能を実現する１以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の一つである。また、そのプログラムは、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給され、そのシステム或いは装置の１以上のコンピュータ（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の一つとして、さらにそのプログラム自体、あるいは該プログラムを格納したコンピュータにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。

１０１ 携帯端末
１０２ 管理サーバー
１０３ 認証管理システム
１０４ 車両
１０５ ネットワーク

Claims (16)

1. 認証処理を行う際に必要なユーザーの生体情報を格納する耐タンパー性を備える記憶手段と、ユーザーの生体情報を読み取る生体情報センサーと、を有する携帯端末、
   ユーザーにデバイスの利用のためのサービスを提供するサービス提供システム、及び、
   前記サービス提供システムにより管理されるデバイス、を含むシステムであって、
   前記携帯端末は、
   前記生体情報センサーにより読み取ったユーザーの生体情報に対応する秘密鍵と公開鍵のペアを生成する第１生成手段と、
   前記生体情報センサーにより読み取ったユーザーの生体情報と、前記生成された秘密鍵と、を紐付けて前記記憶手段に格納する格納手段と、
   前記生成された秘密鍵のペアとなる公開鍵を前記サービス提供システムに登録するために送信する登録手段と、を有し、
   前記サービス提供システムは、
   前記携帯端末から受信した前記公開鍵と、前記携帯端末のユーザーが利用すべきデバイスのデバイス情報と、を紐付けて管理する管理手段と、
   前記管理されたデバイス情報が示すデバイスに対して、該デバイス情報に紐付けて管理されている公開鍵を送信する送信手段と、を有し、
   前記デバイスは、
   前記サービス提供システムと通信できた際に、当該サービス提供システムから受信した公開鍵を保持する保持手段と、
   前記デバイスに対する操作要求が発生した場合に、検証用のパラメータを生成する第２生成手段と、
   接続されている前記携帯端末に対して、前記生成されたパラメータを含む認証要求を送信する要求手段と、を有し、
   前記携帯端末は、さらに、
   前記認証要求の受信した場合に、前記生体情報センサーにより読み取られたユーザーの生体情報と、前記記憶手段に格納された生体情報と、を用いた生体認証を実行する認証手段と、
   前記生体認証に成功した場合には、該生体認証に用いた生体情報に紐付けて前記記憶手段に格納されている秘密鍵と、前記受信した認証要求に含まれるパラメータとを用いて署名データを生成する第３生成手段と、
   前記生成された署名データを含むレスポンスを前記デバイスに送信する応答手段と、を有し、
   前記デバイスは、さらに、
   前記保持している公開鍵と前記認証要求に含めたパラメータとを用いた、前記レスポンスに含まれる署名データの検証を実行する検証手段と、
   前記検証に成功した場合に、前記デバイスに対する操作要求を実行する実行手段と、を有し、
   前記デバイスに対する操作要求の発生時に、前記保持手段で予め前記公開鍵が保持されていれば、前記サービス提供システムとの通信に失敗する場合であっても、前記認証要求の送信に応じた前記レスポンスに含まれる署名データの検証が実行されることを特徴とするシステム。
2. 前記サービス提供システムの送信手段は、前記デバイスからの取得要求に応じて、該デバイス情報に紐付けて管理されている公開鍵を送信することを特徴とする請求項１に記載のシステム。
3. 前記デバイスは、前記デバイスに対する操作要求が発生した場合にも、前記取得要求を前記サービス提供システムに送信し、
   前記デバイスの保持手段は、前記取得要求に基づき前記サービス提供システムから公開鍵を取得できた場合には、当該公開鍵を保持することを特徴とする請求項２に記載のシステム。
4. 前記デバイスは、前記サービス提供システムからの削除依頼に従い、前記保持されている公開鍵を削除することを特徴とする請求項１乃至３のいずれか１項に記載のシステム。
5. 前記デバイスは、車両、ドローン、ロボット、および画像処理装置の少なくともいずれかを含むことを特徴とする請求項１乃至４のいずれか１項に記載のシステム。
6. 認証処理を行う際に必要なユーザーの生体情報を格納する耐タンパー性を備える記憶手段と、ユーザーの生体情報を読み取る生体情報センサーと、を有する携帯端末、
   ユーザーにデバイスの利用のためのサービスを提供するサービス提供システム、及び、
   前記サービス提供システムにより管理されるデバイス、を含むシステムにおける方法であって、
   前記携帯端末は、
   前記生体情報センサーにより読み取ったユーザーの生体情報に対応する秘密鍵と公開鍵のペアを生成する第１生成工程と、
   前記生体情報センサーにより読み取ったユーザーの生体情報と、前記生成された秘密鍵と、を紐付けて前記記憶手段に格納する格納工程と、
   前記生成された秘密鍵のペアとなる公開鍵を前記サービス提供システムに登録するために送信する登録工程と、を有し、
   前記サービス提供システムは、
   前記携帯端末から受信した前記公開鍵と、前記携帯端末のユーザーが利用すべきデバイスのデバイス情報と、を紐付けて管理する管理工程と、
   前記管理されたデバイス情報が示すデバイスに対して、該デバイス情報に紐付けて管理されている公開鍵を送信する送信工程と、を有し、
   前記デバイスは、
   前記サービス提供システムと通信できた際に、当該サービス提供システムから受信した公開鍵を前記デバイスの保持手段に保持する保持工程と、
   前記デバイスに対する操作要求が発生した場合に、検証用のパラメータを生成する第２生成工程と、
   接続されている前記携帯端末に対して、前記生成されたパラメータを含む認証要求を送信する要求工程と、を有し、
   前記携帯端末は、さらに、
   前記認証要求の受信した場合に、前記生体情報センサーにより読み取られたユーザーの生体情報と、前記記憶手段に格納された生体情報と、を用いた生体認証を実行する認証工程と、
   前記生体認証に成功した場合には、該生体認証に用いた生体情報に紐付けて前記記憶手段に格納されている秘密鍵と、前記受信した認証要求に含まれるパラメータとを用いて署名データを生成する第３生成工程と、
   前記生成された署名データを含むレスポンスを前記デバイスに送信する応答工程と、を有し、
   前記デバイスは、さらに、
   前記保持している公開鍵と前記認証要求に含めたパラメータとを用いた、前記レスポンスに含まれる署名データの検証を実行する検証工程と、
   前記検証に成功した場合に、前記デバイスに対する操作要求を実行する実行工程と、を有し、
   前記デバイスに対する操作要求の発生時に、前記保持手段で予め前記公開鍵が保持されていれば、前記サービス提供システムとの通信に失敗する場合であっても、前記認証要求の送信に応じた前記レスポンスに含まれる署名データの検証が実行されることを特徴とする方法。
7. ユーザーにデバイスの利用のためのサービスを提供するサービス提供システムにより管理されるデバイスであって、
   前記サービス提供システムと通信できた際に、当該サービス提供システムから受信した公開鍵を保持する保持手段と、
   前記デバイスに対する操作要求が発生した場合に、検証用のパラメータを生成する生成手段と、
   接続されている携帯端末に対して、前記生成されたパラメータを含む認証要求を送信する要求手段と、
   前記携帯端末から、該携帯端末において生体認証に成功した際に該生体認証に用いた生体情報に紐付く秘密鍵と前記認証要求に含まれるパラメータとを用いて生成された署名データを含むレスポンスを受信する受信手段と、
   前記保持している公開鍵と前記認証要求に含めたパラメータとを用いた、前記レスポンスに含まれる署名データの検証を実行する検証手段と、
   前記検証に成功した場合に、前記デバイスに対する操作要求を実行する実行手段と、を有し、
   前記デバイスに対する操作要求の発生時に、前記保持手段で予め前記公開鍵が保持されていれば、前記サービス提供システムとの通信に失敗する場合であっても、前記認証要求の送信に応じた前記レスポンスに含まれる署名データの検証が実行されることを特徴とするデバイス。
8. 前記サービス提供システムに対して公開鍵の取得要求を送信する送信手段をさらに有することを特徴とする請求項７に記載のデバイス。
9. 前記送信手段は、前記デバイスに対する操作要求が発生した場合にも、前記取得要求を前記サービス提供システムに送信し、
   前記保持手段は、前記取得要求に基づき前記サービス提供システムから公開鍵を取得できた場合には、当該公開鍵を保持することを特徴とする請求項８に記載のデバイス。
10. 前記デバイスは、前記サービス提供システムからの削除依頼に従い、前記保持されている公開鍵を削除することを特徴とする請求項７乃至９のいずれか１項に記載のデバイス。
11. 前記デバイスは、車両、ドローン、ロボット、および画像処理装置の少なくともいずれかを含むことを特徴とする請求項７乃至１０のいずれか１項に記載のデバイス。
12. 前記携帯端末は、認証処理を行う際に必要なユーザーの生体情報、及び前記秘密鍵を紐付けて格納する耐タンパー性を備える記憶手段と、ユーザーの生体情報を読み取る生体情報センサーと、を有し、
    前記携帯端末から前記サービス提供システムに対して、前記秘密鍵のペアとして生成された公開鍵が登録されることを特徴とする請求項７乃至１１のいずれか１項に記載のデバイス。
13. 前記デバイスに対する操作要求は、前記携帯端末から送信された、前記デバイスのドアロックユニットで制御される前記デバイスが備えるドアの解錠の指示であることを特徴とする請求項７乃至１２のいずれか１項に記載のデバイス。
14. 前記デバイスに対する操作要求が発生時に、前記保持手段で前記公開鍵が保持されておらず、さらに前記サービス提供システムとの通信に失敗する場合には、該操作要求が実行されないことを示す通知が行われることを特徴とする請求項７乃至１３のいずれか１項に記載のデバイス。
15. ユーザーにデバイスの利用のためのサービスを提供するサービス提供システムにより管理されるデバイスにおける方法であって、
    前記サービス提供システムと通信できた際に、当該サービス提供システムから受信した公開鍵を前記デバイスの保持手段に保持する保持工程と、
    前記デバイスに対する操作要求が発生した場合に、検証用のパラメータを生成する生成工程と、
    接続されている携帯端末に対して、前記生成されたパラメータを含む認証要求を送信する要求工程と、
    前記携帯端末から、該携帯端末において生体認証に成功した際に該生体認証に用いた生体情報に紐付く秘密鍵と前記認証要求に含まれるパラメータとを用いて生成された署名データを含むレスポンスを受信する受信工程と、
    前記保持している公開鍵と前記認証要求に含めたパラメータとを用いた、前記レスポンスに含まれる署名データの検証を実行する検証工程と、
    前記検証に成功した場合に、前記デバイスに対する操作要求を実行する実行工程と、を有し、
    前記デバイスに対する操作要求の発生時に、前記保持手段で予め前記公開鍵が保持されていれば、前記サービス提供システムとの通信に失敗する場合であっても、前記認証要求の送信に応じた前記レスポンスに含まれる署名データの検証が実行されることを特徴とする方法。
16. 請求項７乃至１４のいずれか１項に記載の手段としてコンピュータを機能させるためのプログラム。

Images