JP6921654B2 - 情報処理装置、方法、及びプログラム - Google Patents

Description

本発明は、生体認証を前提としたサービスを利用する際の制御に関する。

近年、スマートフォンやタブレットコンピューターなどの携帯型の機器が急速に普及してきている。また、これらの機器などの情報処理装置に搭載されるディスプレイ、センサー、プロセッサーなどの部品デバイスの技術開発も急速に進んでいる。

近年、スマートフォンなどには、機器の背面のなどに指紋センサーが標準的にされるようになってきており、ユーザーにとって、生体認証という認証手段が身近で、頻繁に利用されるようになってきている。また、スマートフォン、タブレットコンピューターなどは、タッチパネルディスプレイによるユーザーインターフェース（ＵＩ）を標準的に備えており、ユーザーは主に指によってこれらのコンピューターを操作可能である。

スマートフォン、タブレットコンピューターなどでは、広く使われているパスワード方式などのレガシー認証手段の代替手段として、セキュリティ・利便性を向上させる認証方式として生体認証を用いている。例えば、アプリストアでアプリケーションを購入する場合、１．購入指示（ＵＩ操作）、２．認証（レガシー認証または生体認証）、３．購入処理結果表示、のような手続きがある。このステップ２では、レガシー認証を基本として、その代替手段として生体認証も利用可能である。

特許文献１では、医療システムと医療関係者とインターフェース接続するためのダイナミックディスプレイ及びタッチスクリーン入力を備えたユーザーインターフェースにおいて、ダイナミックディスプレイの裏側に１以上の指紋スキャナを可動式に配置するなどして指紋読取器を構成している。このユーザーインターフェースに対してタッチ操作が入力された場合に、タッチ位置を特定して、特定された位置に移動した指紋スキャナにより読取られた指紋を用いて、ユーザー識別及び認証を提供する技術が開示されている。

特表２００８−５２３４６０

スマートフォン、タブレットコンピューターなどの端末に対して認証が必要なウェブサービスを提供する際にも、生体認証を利用することがある。上述の例では、購入指示のタイミングで生体認証が要求される。生体認証を要求するウェブサービスについては、ユーザーの入力を受け付けるために端末に表示されるいくつかのオブジェクト（ボタンなどのＵＩコントロール）への操作の中で、起動や購入などの特定の処理のための操作が行われる場合に認証が要求される。そして、その操作に限り、端末内での認証が完了するまでユーザーの生体情報の入力を意図的に行わせるための操作性の高い仕組みが必要となる。とくに、本発明は、特許文献１では考慮されていない、生体認証を要求するウェブサービスの利用する際して、操作性について改善を行うことを目的とする。

本発明は、生体認証のための認証モジュールと、該認証モジュールにより認証処理を行う際に必要なユーザーの生体情報を格納する耐タンパー性を備える記憶手段と、ユーザーの生体情報を読み取る生体情報センサーと、ディスプレイと、を有する情報処理装置であって、前記情報処理装置とネットワークを介して通信するサーバーシステムから受信した表示に用いるデータに含まれる命令の中の、ユーザー操作を受け付けるためのコントロールに関する命令に従い、生体認証が要求されていることを示す情報を付加して該コントロールを、前記ディスプレイに表示する表示手段と、ユーザーの前記コントロールに対する操作に従い、前記サーバーシステムに対して、処理要求を行う要求手段と、前記コントロールが表示される位置での該コントロールに対するユーザーの操作によって前記生体情報センサーで読み取った生体情報を用いた前記認証モジュールでの生体認証の結果に基づくデータを生成する生成手段と、を有し、前記処理要求および前記生成されたデータに基づいて、前記コントロールに係る情報が前記ディスプレイに表示されることを特徴とする。

本発明では、従来技術に比べて、ユーザーのコントロールへの操作入力にあわせて生体認証を行う際の操作性が向上する。

本発明におけるシステム構成例 情報処理装置のハードウェア構成の例を示す図 本発明におけるシステム内の各装置のソフトウェアおよびハードウェア構成の例を示す図 コンピューター１１１で提供されるユーザーインターフェースの例 図４で示すユーザーインターフェースの実現例の説明のための図 図４で示すユーザーインターフェースの生成処理を説明するためのフローチャート コンピューター１１１のユーザーインターフェース画面遷移の例 コンピューター１１１と、サーバー１２１とにおける処理全体のシーケンス コンピューター１１１のハードウェア仕様に依存したユーザーインターフェースの例 変形例２のユーザーインターフェース画面遷移の例 変形例２のコンピューター１１１と、サーバー１２１とにおける処理全体のシーケンス 本発明の応用例のユーザーインターフェースの実現例の説明のための図 生体認証の実行設定画面 応用例のコンピューター１１１と、サーバー１２１とにおける処理全体のシーケンス

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

図１は、本発明におけるシステム構成の一例を示している。

１０１は、インターネット・イントラネットなどのネットワークである。１０５は、プライベートネットワークあるいはローカルエリアネットワーク（ＬＡＮ）などのネットワークである。１０５は、コンピューター等の機器を接続する末端のネットワークであるが、有線通信のネットワークに限らず、無線ＬＡＮや携帯電話通信ネットワークなどの無線通信網の場合もある。１１１はコンピューターである。コンピューター１１１としては、パーソナルコンピューター、ラップトップコンピューター、タブレットコンピューター、スマートフォンなどの形態・種別が存在する。また、コンピューター１１１としては、デジタルカメラやプリンターや車載器（カーナビ）、ホームアシスタントや介護などの用途のロボットといった、ウェブサービスと通信し、タッチパネルを備えるような機器も含まれる。１２１はネットワークを介してウェブ（Ｗｅｂ）サイトやウェブアプリケーションなどのウェブサービスを提供するサーバーである。

図２（ａ）はコンピューター１１１、図２（ｂ）はサーバー１２１を構成する情報処理装置のハードウェアのモジュール構成の例を示している。

図２（ａ）において、２０２はネットワークインターフェースであり、ＬＡＮなどのネットワークに接続して、他のコンピューターやネットワーク機器との通信を行う。通信の方式としては、有線・無線のいずれでもよい。２０４は組込済みプログラムおよびデータが記録されているＲＯＭである。２０５は一時メモリ領域のＲＡＭである。２０６はＨＤＤやフラッシュメモリに代表されるような二次記憶装置である。２０３はＣＰＵであり、ＲＯＭ２０４、ＲＡＭ２０５、二次記憶装置２０６などから読み込んだプログラムを実行する。二次記憶装置２０６には、後述するフローチャートなどで説明する処理を実現するためのソフトウェアプログラムなども格納されることになる。２０１はユーザーインターフェースであり、キーボード、マウス、ボタンなどによる、情報や信号の入出力を行う。これらのハードウェアを備えないコンピューターは、リモートデスクトップやリモートシェルなどにより、他のコンピューターから接続・操作することも可能である。２１０は、同様にユーザーインターフェースの１つであるディスプレイである。２１１は、同様にユーザーインターフェースの１つであるタッチパネルである。タッチパネル２１１は、接触センサー・圧力センサー等によって、ユーザー操作の操作位置／方向・操作距離・操作圧力などを検出する。２１２は指紋・静脈・虹彩などに代表される生体情報を読み取るための生体情報センサーである。生体情報としては、ユーザーの指紋、静脈、虹彩、声紋、及び顔画像の少なくともいずれかに係る情報である。２２１は、Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ（ＴＰＭ）である。ＴＰＭ２２１は、Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍや他のハードウェアから独立して機能する耐タンパー性を備えたセキュリティチップで、機密情報を処理・格納するための記憶手段となる。本発明ではＴＰＭ２２１に、生体認証に利用するユーザーの生体情報（またはその特徴量）や、後述される認証処理に必要となる秘密鍵が格納される。なお、本発明では、ＴＰＭの代替として、耐タンパー性を実現するために１チップ上で他から隔離して動作するセキュアなメモリ空間を確保して、そのメモリ空間でユーザーの生体情報（またはその特徴量）や、秘密鍵などを管理するための記憶手段を提供するといった方法でも実現できる。各部は入出力インターフェース２０７を介して接続されている。

また、本発明におけるディスプレイ２１０、タッチパネル２１１及び生体情報センサー２１２を兼ねるように構成することも想定している。つまり、それらハードウェアを重ねて構成し、ディスプレイ２１０上のタッチ操作をタッチパネル２１１で検出し制御したり、タッチパネル２１１上の任意の位置に対する生体情報の入力（タッチによる指紋情報の読み取り）を生体情報センサー２１２で検出し制御したりすることを想定している。

図２（ｂ）においては、図２（ａ）と同様なハードウェア構成を備える。サーバー１２１として動作するために必要な構成のみを図示しており、それら機能は図２（ａ）の同じ符号で説明した構成と同様であるため説明を省略する。なお、図示したものは一例であり、ディスプレイなど、一般的なそのほかのハードウェア構成を備えることも可能である。

図３は、本システムの各装置のソフトウェアのモジュール構成やその概要を説明するための図である。一部、図２でも説明したハードウェア構成についても図示している。図示したソフトウェアのモジュール構成のそれぞれは、それぞれＣＰＵ２０３で本発明に特有なプログラムを実行することで実現され、ネットワーク接続の矢印で図示するように、相互に通信可能な構成となっている。

まず、サーバー１２１の構成について説明する。

３１１は、サーバー１２１にインストールされたＷｅｂアプリケーションである。３１２は、Ｗｅｂアプリケーション３１１によって提供されるＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ） ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）である。３１３は、Ｗｅｂアプリケーション３１１によって提供されるＷｅｂ ＵＩである。３１４は、Ｗｅｂアプリケーション３１１が使用するデータを保存・格納するデータストアである。Ｗｅｂアプリケーション３１１は、クライアントからのＨＴＴＰリクエストの内容に応じて、Ｗｅｂ ＵＩ３１３がＨＴＭＬやＪａｖａＳｃｒｉｐｔ（登録商標）などのコンテンツファイルを応答したり、ＲＥＳＴ ＡＰＩ３１２がＸＭＬやＪＳＯＮデータを応答したりする。

３２１は、サーバー１２１にインストールされた認証サーバーである。３２２は、認証サーバー３２１が使用するデータを保存・格納するデータストアである。認証サーバー３２１は、ユーザー等のアカウントごとに、そのアカウントで使用可能な認証方式（例えば、オーセンティケータ（Ａｕｔｈｅｎｔｉｃａｔｏｒ）の情報）を登録・管理し、認証アサーションを検証する。認証サーバー３２１はユーザーの生体情報（生体情報の特徴量）自体を直接的に保管して、管理するものではない。また、認証サーバー３２１はサーバー１２１の外部ネットワーク上に構築してもよい。

次に、コンピューター１１１の構成について説明する。

３５１は、コンピューター１１１にインストールされたＯｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ（以降、ＯＳ）である。ＯＳ３５１は、コンピューター１１１の各ハードウェアを管理・制御し、各種プログラムの実行管理を行う基本ソフトウェアである。３５２は、ＯＳ３５１が備えるＰｌａｔｆｏｒｍ ＡＰＩである。Ｐｌａｔｆｏｒｍ ＡＰＩ３５２は、ＯＳ３５１を介して各ハードウェアとのインタラクションを制御するためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）である。３５３は、ユーザーインターフェースの１つであるディスプレイ２１０を制御するグラフィックスドライバーである。３５４は、タッチパネル２１１からの接触・位置・圧力などの信号を検出・処理するタッチパネルコントローラーである。タッチパネルディスプレイの場合、ＯＳ３５１がディスプレイ２１０にＵＩコントロールを描画し、タッチパネル２１１がユーザーによるＵＩコントロールの操作を検出して、ＯＳ３５１にフィードバックする。

３５５は、生体情報センサー２１２から読み取った生体情報を元にユーザーを認証するオーセンティケータである。本発明では、オーセンティケータ３５５を認証モジュールとして定義する。なお、生体情報センサー２１２及びオーセンティケータ３５５の組合せを認証モジュールと呼ぶこともできる。オーセンティケータ３５５は、例えばＴＰＭ２１１のセキュア領域に暗号鍵を保管しておき、読み取った生体情報あるいはその特徴量などの機密情報をその暗号鍵で二次記憶装置２０６などに暗号化データとして保管する。ユーザーが生体認証を試みた際に、オーセンティケータ３５５は前記保管されている生体情報あるいはその特徴量とのマッチングを検証し、生体認証の成功・失敗を判定する。

３６１は、コンピューター１１１にインストールされたアプリケーションである。アプリケーション３６１として、Ｎａｔｉｖｅ ＡｐｐｌｉｃａｔｉｏｎとＢｒｏｗｓｅｒの大きく２つの種類がある。Ｎａｔｉｖｅ Ａｐｐｌｉｃａｔｉｏｎは、ＯＳ上で直接実行可能なコードで記述されたアプリケーションである。前記Ｎａｔｉｖｅ Ａｐｐｌｉｃａｔｉｏｎは、ＯＳ３５１が提供する各機能にＰｌａｔｆｏｒｍ ＡＰＩ３５２を介してアクセスする。Ｂｒｏｗｓｅｒは、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）やＪａｖａＳｃｒｉｐｔを表示・実行するアプリケーションである。３７２は、Ｂｒｏｗｓｅｒ上で実行されるＪａｖａＳｃｒｉｐｔである。前記Ｂｒｏｗｓｅｒは、ネットワークを介して、サーバー１２１で実行されるＷｅｂアプリケーション３１１からＨＴＭＬ，ＪａｖａＳｃｒｉｐｔ３７２等を取得・実行・表示する。３７３は、前記Ｂｒｏｗｓｅｒが備えるＢｒｏｗｓｅｒ ＡＰＩである。Ｂｒｏｗｓｅｒ ＡＰＩ３７３は、Ｂｒｏｗｓｅｒ上で実行されるＪａｖａＳｃｒｉｐｔ３７２からＯＳ３５１が提供する機能にアクセスできるように設けられているＡＰＩである。一方、Ｎａｔｉｖｅ Ａｐｐｌｉｃａｔｉｏｎもネットワーク上の機能・データを用いる場合は、Ｗｅｂアプリケーション３１１と接続し、ＲＥＳＴ ＡＰＩ３１２を介して、データを送受信する。

アプリケーション３６１がＷｅｂアプリケーション３１１と接続し、特定の機能やデータにアクセスするためにユーザー認証が必要なケースがある。本発明が想定する１つの認証方式であるＦＩＤＯ Ａｌｌｉａｎｃｅが策定しているＦａｓｔ ＩＤｅｎｔｉｔｙ Ｏｎｌｉｎｅ（ＦＩＤＯ）によれば、Ｗｅｂ認証に生体認証を用いるための標準仕様が公開されている。詳細な説明は省略するが、以下のような手順でＷｅｂ認証に用いる生体認証用オーセンティケータ３５５を認証サーバー３２１に登録する。

（１）アプリケーション３６１から、Ｗｅｂアプリケーション３１１にアクセスして、認証サーバー３２１でのレガシー認証（ユーザー名およびパスワード入力など）に従い、ログインする。（２）アプリケーション３６１から、Ｗｅｂアプリケーション３１１に登録開始要求を送信すると、認証サーバー３２１はＣｈａｌｌｅｎｇｅデータを生成し、アプリケーション３６１に返却する。（３）アプリケーション３６１は、オーセンティケータ３５５にクレデンシャル生成要求を送信する。（４）クレデンシャル生成要求に応答したユーザーの生体認証処理の成功に従い、オーセンティケータ３５５は秘密鍵・公開鍵のペアを生成する。（５）オーセンティケータ３５５で、秘密鍵・公開鍵のペアは、Ｗｅｂアプリケーション３１１にログインしたユーザー情報に紐付けられる。前記秘密鍵は、コンピューター１１１内のＴＰＭ２２１などのセキュアな領域に保管される。（６）オーセンティケータ３５５は登録用クレデンシャル情報を生成する。この登録用クレデンシャル情報には、オーセンティケータ３５５を個別に識別するためのクレデンシャルと前記公開鍵および前述のＣｈａｌｌｅｎｇｅから秘密鍵で生成した署名が含まれる。（７）生成した登録用クレデンシャル情報を認証サーバー３２１に送信する。（８）認証サーバー３２１は、受信した登録用クレデンシャル情報に含まれる公開鍵で同様に含まれる署名を検証し、オーセンティケータを識別する情報と公開鍵などを、ユーザー情報に紐付けて保存する。

この登録処理以降は、アプリケーション３６１からＷｅｂアプリケーション３１１にアクセスした際には、アプリケーション３６１には、認証サーバー３２１で生成された検証用データであるＣｈａｌｌｅｎｇｅを含み、ＲＰ ＩＤなどが指定された生体認証要求（アサーション要求）が送信される。その際には、コンピューター１１１内で対応するオーセンティケータが、生体認証を実行することで得られる秘密鍵とそのＣｈａｌｌｅｎｇｅ、を用いて署名を生成する。そしてこの署名が認証サーバー３２１で検証されることで、Ｗｅｂアプリケーション３１１へのログインのための認証処理が実現される。つまり、本仕様においては、ネットワーク上に認証のための生体情報が流れることが無い。また、登録処理以降は、パスワードなどを用いたレガシー認証も不要になる。

図４に、本発明における、コンピューター１１１のディスプレイ２１０に表示される生体認証を統合したＵＩコントロールの表示例を示す。

４０１は、コンピューター１１１に備えられたタッチパネル２１１を兼ねるディスプレイ２１０を示す例である。図にて黒塗りされたエリアがタッチパネルディスプレイの表示可能範囲およびタッチ操作検出可能エリアを示している。さらに、４０２は、ディスプレイ２１０と同一面における生体情報センサー２１２の生体情報（指紋など）の検出可能エリアを示している。４１０は、タッチパネルディスプレイ４０１上に表示されたアプリケーション３６１のＵＩ例を示している。４１１から４１４は、ＵＩ４１０に配置されたＵＩコントロール（ボタンオブジェクト）の例である。４１１から４１３が、生体認証を統合したＵＩコントロールである。４１４は、生体認証を必要としない、標準のＵＩコントロールである。生体認証を統合したＵＩコントロールは、生体情報センサー２１２の検出可能エリア４０２内の任意の位置に配置可能である。

図５、図６を用いて、図４で示すＵＩコントロールを表示する方法・処理フローの例を示す。

図５の５００は、アプリケーション３６１の一例であるウェブブラウザー（Ｂｒｏｗｓｅｒ）に表示するマークアップ言語（例えば、ＨＴＭＬ）で記述されたデータの一部を示している。５０１、５０２は、ＵＩコントロールの表示のための生成命令を示すＨＴＭＬ要素である。

５０２は、標準のＵＩコントロールに対応するＨＴＭＬ要素である。一方、５０１は、生体認証を統合したＵＩコントロールに対応するＨＴＭＬ要素である。生体認証の指定をするために、ＨＴＭＬ５のカスタムデータ属性ｄａｔａ−＊を利用した例を示す。カスタムデータ属性ｄａｔａ−ｂｉｏａｕｔｈ＝””ｒｅｑｕｉｒｅｄ”により、生体認証を統合したＵＩコントロールであることを示す。同様に、ｄａｔａ−ｂｉｏａｕｔｈ−ｒｐｉｄ属性に、Ｗｅｂアプリケーション３１１を識別するためのＲＰ ＩＤとしてドメイン名を指定する。

５１０は、ＢｒｏｗｓｅｒでのＨＴＭＬ５００のＵＩ表示結果である。５１１は、ＨＴＭＬ要素５０１によって指定された生体認証を統合したＵＩコントロールである。５１３は、ＨＴＭＬ要素５０２によって指定された標準のボタンコントロールである。５１２は、カスタムデータ属性ｄａｔａ−ｂｉｏａｕｔｈ＝””ｒｅｑｕｉｒｅｄ”によって、ＵＩコントロール５１１が生体認証用の特別なコントロールであることを示すための生体認証用アイコンである。ユーザーはこの生体認証用アイコン５１２により、生体認証が要求される操作であることが認識できる。なお、生体認証用アイコン５１２を含むＵＩコントロール５１１を操作する際には、通常のコントロールに対する操作（ボタン押下）に比べて、カメラやセンサーなどの生体情報センサー２１２による生体情報の読み取りが行われるために、ある程度の長押し操作が要求される場合がある。指紋情報を読み取る場合には、生体認証用アイコン５１２部分にタッチされている間にその指の指紋情報をセンターで読み取ることになる。顔画像認証などのための顔画像を読み取るためには、生体認証用アイコン５１２部分にタッチされている間にコンピューター１１１のカメラ（不図示）で操作者となるユーザーを撮影することで顔画像を読み取ることになる。読み取りが完了し、生体認証が成功した場合に、次の画面（購入手続き完了画面など）に遷移することになる。

図６は、図５で示したＨＴＭＬデータの読み出し、描画に係る処理を説明するためのフローチャートを示す。Ｂｒｏｗｓｅｒのためのアプリケーション３６１をＣＰＵ２０３が実行することで実現される処理である。

Ｓ６０１で、Ｂｒｏｗｓｅｒは、ＨＴＭＬ５００内のＨＴＭＬ要素を１つずつ読み出す。Ｓ６０２で、ＨＴＭＬ要素内に、属性ｄａｔａ−ｂｉｏａｕｔｈ＝””ｒｅｑｕｉｒｅｄ”で、生体認証を要求する指定があるかどうかを判定する。Ｓ６０２で生体認証を要求する指定がある（Ｙｅｓ）と判定された場合にはＳ６０３に進み、指定がない（Ｎｏ）と判定された場合にはＳ６０４に進む。

Ｓ６０３で、Ｂｒｏｗｓｅｒは、指定の座標・サイズでＯＳ３５１にＵＩコントロールの描画を要求する。ＯＳ３５１は、生体認証用アイコン５１２を含むＵＩコントロール５１１をディスプレイ２１０に描画する。Ｓ６０４で、Ｂｒｏｗｓｅｒは、ＯＳ３５１に標準コントロールの描画を要求し、ＯＳ３５１はそれを描画する。ＨＴＭＬ内のすべての要素が描画完了すると図示したループ処理を抜け、Ｓ６０５で、ＵＩ５１０にすべてのＵＩコントロールの表示が完了したことになる。

図５、６で示したのは、アプリケーション３６１がＢｒｏｗｓｅｒの場合の例であるが、アプリケーション３６１がＮａｔｉｖｅ Ａｐｐｌｉｃａｔｉｏｎの場合でも同様である。Ｎａｔｉｖｅ Ａｐｐｌｉｃａｔｉｏｎの場合は、プログラム内からＯＳ３５１が提供するＵＩコントロールを直接描画可能である。ＨＴＭＬのカスタムデータ属性を利用したように、ＯＳ３５１に対するＵＩコントロール描画命令に生体認証を示す属性を付加することによって、Ｎａｔｉｖｅ ＡｐｐｌｉｃａｔｉｏｎがＯＳ３５１に生体認証用の特別なコントロールを描画させるように要求する。

図７、８を用いて、生体認証が統合されたＵＩコントロールのユーザー操作に応じた処理フローを説明する。

図８は、ユーザー操作を含む、コンピューター１１１と、サーバー１２１とにおける処理全体のシーケンスを説明するための図である。

Ｓ８０１で、ユーザーは、アプリケーション３６１を操作して、アプリケーションを起動、あるいは、画面表示を要求する。Ｓ８０２で、操作対象のアプリケーション３６１であるＢｒｏｗｓｅｒが、Ｗｅｂアプリケーション３１１にＷｅｂコンテンツリクエストを送信する。

Ｓ８０３で、Ｗｅｂアプリケーション３１１は、ＷｅｂコンテンツとしてＨＴＭＬデータやＪａｖａＳｃｒｉｐｔを応答する。生体認証が必要なＵＩコントロールについては、図５で前述したようなカスタムデータ属性を付加する。操作対象のアプリケーション３６１がＮａｔｉｖｅ Ａｐｐｌｉｃａｔｉｏｎの場合は、Ｓ８０２、Ｓ８０３の代わりに、プログラム内で描画するＵＩコントロールを指定することになる。

Ｓ８０４で、アプリケーション３６１は、ＨＴＭＬデータをタッチパネルディスプレイ２１０上に描画処理を行う。アプリケーション３６１は、ＵＩコントロールについて、Ｐｌａｔｆｏｒｍ ＡＰＩ３５２を介してＯＳ３５１に座標・サイズなどを指定して描画を要求する。この際に、生体認証の指定をＡＰＩの拡張パラメーターなどを利用して指定する。Ｓ８０５で、ＯＳ３５１は、アプリケーション３６１上に要求されたＵＩコントロールを表示する。この際に、生体認証が統合されたＵＩコントロールには、生体認証用アイコン５１２を表示する。Ｓ８０６で、アプリケーション３６１は、ＯＳ３５１に対し当該ＵＩコントロールのイベントリスナーを設定する。この際に、生体認証が統合されたＵＩコントロールには、指定されたＷｅｂアプリケーション３１１のＲＰ ＩＤをイベントリスナーの拡張パラメーターとして付加する。また、ＯＳ３５１は、ＲＰ ＩＤをＯＳ３５１ローカルの記憶領域に記録する。

ここまでの処理で、コンピューター１１１のタッチパネルディスプレイ２１０上に図７のＳ７０１のアプリケーション３６１のＵＩ画面が表示されることになる。

Ｓ８０７で、ユーザーが、図７のＳ７０１で示す画面上のいずれかのＵＩコントロールを操作する。具体的には、図７のＳ７０２に示すように、生体認証が統合されたＵＩコントロールを、ユーザーの生体（指）にてタッチ（押下）する。

Ｓ８０８で、ＯＳ３５１は、いずれかのＵＩコントロールへの操作を検出した場合、ワンタイムの乱数Ｎｏｎｃｅを生成し、ＯＳ３５１ローカルの記憶領域に記録する。このＮｏｎｃｅは、生体認証がどのＵＩコントロールを起点として実行されたかを追跡・検証するための検証用データとして使用される。Ｓ８０９で、ＯＳ３５１は、アプリケーション３６１にＵＩコントロール操作イベントを通知する。この際に、前記生成したＮｏｎｃｅをイベントに付加する。

Ｓ８１０で、アプリケーション３６１は、ＯＳ３５１から受信したイベントを解析し、生体認証要求の指定があるコントロールに対する操作イベントかどうかを判定する。Ｓ８１１で、Ｓ８１０の判定がＮｏの場合は、通常のＵＩコントロール操作イベントとして処理する。図７の例ではキャンセルボタンが操作されたケースであるので、生体認証などを行わず、初期画面に遷移するといった処理が行われることになる。一方で、Ｓ８１０の判定がＹｅｓの場合は、Ｓ８１２へ進む。

Ｓ８１２で、アプリケーション３６１は、Ｓ８０７で検出された、Ｓ７０２で示すユーザー操作によって要求された処理を行うＵＲＬを宛先として、Ｗｅｂアプリケーション３１１に対する処理要求として、認証開始リクエストを送信する。この際に、ＯＳ３５１から受け取ったＮｏｎｃｅをリクエストに付加する。

Ｓ８１３で、Ｗｅｂアプリケーション３１１は、認証開始リクエストの受信に応じて、認証サーバー３２１に認証開始トリガーを送信する。認証サーバー３２１は、Ｓ８１４で検証用データであるＣｈａｌｌｅｎｇｅを生成し、Ｓ８１５で生成したＣｈａｌｌｅｎｇｅをＷｅｂアプリケーション３１１に応答する。Ｓ８１６で、Ｗｅｂアプリケーション３１１は、アプリケーション３６１に生成したＣｈａｌｌｅｎｇｅ，ＲＰ ＩＤ，Ｎｏｎｃｅを応答する。本発明では、認証サーバー３２１からＷｅｂアプリケーション３１１経由で送信される認証要求（アサーション要求）に、Ｃｈａｌｌｅｎｇｅ，ＲＰ ＩＤに加えてＮｏｎｃｅが追加されている。

Ｓ８１７で、アプリケーション３６１は、認証要求の受信に応じて、Ｐｌａｔｆｏｒｍ ＡＰＩ３５２を介してＯＳ３５１にＡｓｓｅｒｔｉｏｎ要求を送信する。この際に、Ｃｈａｌｌｅｎｇｅ，ＲＰ ＩＤ，Ｎｏｎｃｅを要求に付加する。

Ｓ８１８で、ＯＳ３５１は、Ｓ８１７で受け取ったＲＰ ＩＤとＮｏｎｃｅが、Ｓ８０６およびＳ８０８で記録済みのものと一致するか判定する。Ｓ８１８の判定結果が一致しない（Ｎｏ）の場合には、Ｓ８１９でアプリケーション３６１にエラー応答を表示させて処理を中断する。Ｓ８１８の判定結果が一致する（Ｙｅｓ）の場合にはＳ８２０に進む。Ｓ８２０で、ＯＳ３５１は、オーセンティケータ３５５にＣｈａｌｌｅｎｇｅを含む生体認証リクエストを送信する。この際に、拡張パラメーターとして、当該ＵＩコントロールの表示領域に相当する生体情報センサーのエリアを指定する。

Ｓ８０７〜Ｓ８２０までの間のわずかな期間、図７のＳ７０２で示すＵＩコントロールに対するユーザー操作が行われれている。この間、コンピューター１１１に対してユーザーは生体情報を入力していることになる。

Ｓ８２１で、オーセンティケータ３５５は、拡張パラメーターとして指定されたＵＩコントロールの表示領域に対応するエリアにおける生体情報センサー２１２によって読取った生体情報による生体認証の結果を取得する。生体認証は、予めＴＰＭ２２１に格納された生体情報（またはその特徴量）と、生体情報センサー２１２によって読取った生体情報（またはその特徴量）との一致度が高い場合に認証が成功したと判定される。Ｓ８２３で、オーセンティケータ３５５は、認証結果を検証し、成功であった場合にはＴＰＭ２２１から、該生体情報に対応する秘密鍵を取り出す。Ｓ８２４で、オーセンティケータ３５５は、取り出した秘密鍵と、Ｓ８２０で受け取ったＣｈａｌｌｅｎｇｅとを用いて署名データを生成する。Ｓ８２５で、オーセンティケータ３５５は、認証レスポンスとして生成した署名データを含むＡｓｓｅｒｔｉｏｎをＯＳ３５１に返却する。Ｓ８２６で、ＯＳ３５１は、認証レスポンスとして生成した署名データを含むＡｓｓｅｒｔｉｏｎアプリケーション３６１に返却する。

Ｓ８２７で、アプリケーション３６１は、Ｗｅｂアプリケーション３１１に、Ｓ８２４で生成された署名データを含むＡｓｓｅｒｔｉｏｎを送信する。

Ｓ８２８で、Ｗｅｂアプリケーション３１１は、認証サーバー３２１に受信したＡｓｓｅｒｔｉｏｎを送信し、検証を要求する。

Ｓ８２９で、認証サーバー３２１は、オーセンティケータ登録時に保管した公開鍵を使用して、Ａｓｓｅｒｔｉｏｎに含まれる署名データを検証する。Ｓ８３０で、認証サーバー３２１は、Ｓ８２９のＡｓｓｅｒｔｉｏｎ検証に基づき、認証結果として成功・失敗を応答する。具体的には、、認証サーバー３２１は、公開鍵を使用して署名データからＣｈａｌｌｅｎｇｅを取り出して、Ｓ８１４で生成したものと同一であるかを確認する。確認結果においてそれらが一致していた場合には、認証結果として成功をＷｅｂアプリケーション３１１に通知する。

Ｓ８３１で、Ｗｅｂアプリケーション３１１は、認証成功時はＳ８１２のリクエスト内容を処理する。例えば、Ｓ７０２の例では、ユーザーに操作されたＵＩコントロールで指定された商品の注文処理などである。

Ｓ８３２で、Ｗｅｂアプリケーション３１１は、アプリケーション３６１に、認証結果を応答する。認証結果が成功の場合は、Ｓ８３１の認証成功時の処理結果（を含むコンテンツデータ）が提供されることになる。

Ｓ８３３で、アプリケーション３６１は、認証結果および処理結果をユーザーに通知するために、それらの情報を含むコンテンツはコンピューター１１１のタッチパネルディスプレイ２１０上に表示する。この表示は図７のＳ７０３に示す通りであり、Ｓ７０２の注文処理要求に対する処理結果を表示している。

（変形例１）
図９は、図４の構成とは異なり、生体情報センサーのエリアがタッチパネルディスプレイエリア内の一部に存在する場合の構成例を示している。

図９（ａ）で、９０１は生体情報センサー２１２の検出可能エリアを示している。タッチパネルディスプレイの表示可能範囲およびタッチ操作検出可能エリア４０１のうち、高さＨまでの部分が生体情報センサー２１２の検出可能エリアである。

９１０は、アプリケーション３６１のＵＩ例である。９１１から９１３がＵＩコントロールの例である。９１１は、前記生体情報センサー２１２の検出可能エリア外であるため、標準ＵＩコントロールが配置されている。９１２、９１３は、前記生体情報センサー２１２の検出可能エリア内であるため、生体認証を統合したＵＩコントロールが配置可能である。

（変形例２）
図９（ｂ）で、９２１は生体情報センサー２１２の検出可能エリアが、より限定的な例を示している。

９３０は、アプリケーション３６１のＵＩ例である。９３１は、９１２や９１３同様、生体認証を統合したＵＩコントロールである。このように生体情報センサー２１２の検出可能エリアが限定的な場合は、生体認証を統合したＵＩコントロールを配置可能な位置や数が限られることになる。

生体情報センサー２１２の検出可能エリアが限定されている場合、あるいは、生体情報センサー２１２がタッチパネルディスプレイ４０１とは無関係の位置に独立して備えてある場合は、次の問題がある。所望の位置に生体認証を統合したＵＩコントロールを配置できず、図７、８で説明した生体認証を統合したＵＩコントロール処理を適用することが困難となるケースが出てくる。これは、コンピューター１１１の生体情報センサー２１２の取り付け位置や検出可能エリアといったハードウェア仕様によって異なってくるものである。

図１０、１１は、このようなコンピューター１１１のハードウェア仕様の違いによって、生体認証を統合したＵＩコントロールを使用できない（実現が困難な）場合の代替処理フローについて説明する。

図１１は、ユーザー操作を含む、変形例２で示すコンピューター１１１と、サーバー１２１とにおける処理全体のシーケンスを説明するための図である。

Ｓ１１０１で、ユーザーは、アプリケーション３６１を操作して、アプリケーションの起動、あるいは、画面表示を要求する。Ｓ１１０２からＳ１１０４は、図８で説明したＳ８０２からＳ８０４と同様のため、説明を省略する。

Ｓ１１０５で、ＯＳ３５１は、コンピューター１１１のハードウェア仕様として、生体認証を統合されたＵＩコントロールの表示エリアに生体情報センサー２１２があるかを判定する。Ｓ１１０５の判定がＮｏ（生体認証を統合されたＵＩコントロールの表示エリアに生体情報センサー２１２がない）の場合、Ｓ１１０６で、アプリケーション３６１にＵＩコントロール描画要求に対してエラー応答を返す。

Ｓ１１０７で、アプリケーション３６１は、生体認証用ＵＩコントロールの生成に成功したか判定する。ＯＳ３５１からエラー応答があった場合には、生体認証用ＵＩコントロールの生成に失敗したと判定（Ｎｏ）されることになる。Ｓ１１０７の判定がＮｏの場合には、Ｓ１１０８で、アプリケーション３６１はＯＳ３５１に、座標・サイズ等は同一のまま、標準ＵＩコントロールの描画を要求する。

Ｓ１１０９で、ＯＳ３５１は、標準ＵＩコントロールをタッチパネルディスプレイ２１０に描画する。

Ｓ１１１０で、アプリケーション３６１は、ＯＳ３５１に対し当該ＵＩコントロールのイベントリスナーを設定する。

ここまでの処理で、コンピューター１１１のタッチパネルディスプレイ２１０上に図１０のＳ１００１のアプリケーション３６１のＵＩ画面が表示されることになる。図７のＳ７０１で示す画面とは異なり、いずれのＵＩコントロールに対しても生体認証用アイコン５１２がないことがわかる。

Ｓ１１１１で、ユーザーが、図１０のＳ１００１で示す画面上のいずれかのＵＩコントロールを操作する。具体的には、図１０のＳ１００２に示すように、ＵＩコントロールをユーザーの指にてタッチ（押下）する。

Ｓ１１１２で、ＯＳ３５１は、アプリケーション３６１にＵＩコントロールへの操作イベントを通知する。Ｓ１１１３で、アプリケーション３６１は、イベント通知に応じて、ユーザー操作の対象となったＵＩコントロールに対応する処理を行うＵＲＬを宛先として、Ｗｅｂアプリケーション３１１に認証開始リクエストを送信する。

Ｓ１１１４からＳ１１１６までは、前記説明したＳ８１３からＳ８１５と同様のため、説明を省略する。Ｓ１１１７で、Ｗｅｂアプリケーション３１１は、アプリケーション３６１にＣｈａｌｌｅｎｇｅ，ＲＰ ＩＤを応答する。

Ｓ１１１８で、アプリケーション３６１は、Ｐｌａｔｆｏｒｍ ＡＰＩ３５２を介してＯＳ３５１にＡｓｓｅｒｔｉｏｎ要求を送信する。この際に、Ｃｈａｌｌｅｎｇｅ，ＲＰ ＩＤがこの要求に付加される。

Ｓ１１１９で、ＯＳ３５１は、オーセンティケータ３５５に生体認証リクエストを送信する。

Ｓ１１２０で、オーセンティケータ３５５は、図１０のＳ１００３で示すように、ユーザーに対して生体認証要求するための画面をコンピューター１１１のタッチパネルディスプレイ２１０上に追加表示する。図１０のＳ１００４で示すように、ユーザーは、コンピューター１１１の生体情報センサー２１２に生体（指紋）を読み取らせる。ユーザーの生体情報の入力作業に応じて、Ｓ１１２１で生体認証が実行される。以降は、図８のＳ８２３からＳ８３３と同様のフローのため、説明を省略する。本シーケンスでも、生体認証の結果、処理結果をＳ８３３と同様に、図１０のＳ１００５で示すように表示する。

（応用例）
次に、図１２、１３、１４を用いて、前記説明した生体認証を統合したＵＩコントロールの他のユースケースへの適用例を示す。

１２００は、コンピューター１１１のタッチパネルディスプレイ２１０上に、ＯＳ３５１が提供・表示するデスクトップあるいはホーム画面のＵＩである。１２０１、１２０２は、ボタン型ＵＩコントロールである。１２０１は、アプリケーション３６１の起動ボタンである。１２０２は、ＵＲＬショートカットの起動ボタンである。１２０３は、図５の５１２で説明した生体認証用アイコンである。生体認証用アイコン１２０３の有無により、アプリケーション起動ボタンあるいはＵＲＬショートカット起動ボタンが、生体認証が統合されたＵＩコントロールであるかどうかを示している。

１３００は、アプリケーション起動ボタンあるいはＵＲＬショートカット起動ボタンに対して、生体認証の実行設定を行うためのＵＩである。１３０１は、「Ａｐｐ１」というアプリケーション３６１の起動ボタンに対して、生体認証の実行設定を行っている例である。「Ａｐｐ１」というアプリケーション３６１が、Ｗｅｂアプリケーション３１１のドメイン“ｆｏｏ．ｃｏｍ”を、ＲＰ ＩＤとして生体認証フローが利用可能である。しかし、生体認証の実行設定がＯｆｆになっているため、ＵＩ１２００では「Ａｐｐ１」の起動ボタンには、生体認証用アイコン１２０３は表示されない。１３０２は、「ＵＲＬ３」というＵＲＬショートカットの起動ボタンに対して、生体認証の実行設定を行っている例である。１３０２「ＵＲＬ３」のショートカットの宛先ＵＲＬは、“ｈｔｔｐｓ：／／ｃｎ−ｓｈｏｐ．ｃｏｍ／ａｕｔｈｎ”である。生体認証の実行設定は、Ｏｎになっており、ＵＩ１２００では、「ＵＲＬ３」の起動ボタンには、生体認証用アイコン１２０３が表示されている。ほか、設定不可と表示されているアプリケーション起動ボタン、ＵＲＬショートカット起動ボタンは、生体認証を利用しないものである。

図１４にて、前記アプリケーション起動ボタンあるいはＵＲＬショートカット起動ボタンが、生体認証が統合されたＵＩコントロールとして処理される場合のフローを説明する。

Ｓ１４０１で、ＯＳ３５１は、デスクトップあるいはホーム画面に表示するアプリケーションあるいはＵＲＬショートカットの起動ボタンを読み出し、かつ、１３００で示した生体認証の実行設定を読み出す。Ｓ１４０２で、ＯＳ３５１は、生体認証の実行設定がＯｎに設定されたボタンについては、生体認証用アイコン１２０３を含んだＵＩコントロールを、コンピューター１１１のタッチパネルディスプレイ２１０上に描画・表示する。表示結果が図１２の１２００となる。

Ｓ１４０３で、ユーザーは、アプリケーション起動ボタン１２０１あるいはＵＲＬショートカット起動ボタン１２０２を操作して、アプリケーションを起動、あるいは、ＢｒｏｗｓｅｒによってＵＲＬショートカットを開く要求をする。

Ｓ１４０４で、前記説明したＳ８０８同様に、ＯＳ３５１はＮｏｎｃｅを生成する。Ｓ１４０５で、ＯＳ３５１は、アプリケーション３６１にＵＩコントロール操作イベントを通知する。この際に、生成したＮｏｎｃｅをイベントに付加する。

Ｓ１４０６で、アプリケーション３６１は、１３００の生体認証実行設定に基づき、当該起動ボタンの生体認証の実行設定がＯｎの場合、Ｗｅｂアプリケーション３１１に処理要求としての認証開始リクエストを送信する。この際に、前記受け取ったＮｏｎｃｅをリクエストに付加する。以降は、図８で説明したＳ８１３からＳ８３３と同様のフローとなる。生体認証用アイコン１２０３の位置に対応する生体情報センサー２１２で読み取った生体情報による生体認証が成功し、認証サーバー３２１における検証にも成功した場合に、Ｓ１４０３でユーザーに指定されたアプリケーション３６１が起動され、初期画面が表示されることになる。

以上説明したように、タッチパネルディスプレイ内に生体認証センサーが内蔵された部品デバイスが使用可能な場合、ＵＩ操作と生体認証を、直感的で理解しやすい１つのＵＩ操作に統合する手段を提供できる。特に、指定のＵＩコントロール表示領域上における操作に対してのみ、同時に生体認証を実行する手段を提供できる。これらにより、生体認証操作を行う際のユーザーの利便性及び操作性を向上することができる。

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

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

１１１ コンピューター
２１０ ディスプレイ
２１１ タッチパネル
２１２ 生体情報センサー
２２１ Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ（ＴＰＭ）
３１１ Ｗｅｂアプリケーション
３２１ 認証サーバー

Claims (7)

1. 生体認証のための認証モジュールと、該認証モジュールにより認証処理を行う際に必要なユーザーの生体情報を格納する耐タンパー性を備える記憶手段と、ユーザーの生体情報を読み取る生体情報センサーと、ディスプレイと、を有する情報処理装置であって、
   前記情報処理装置とネットワークを介して通信するサーバーシステムから受信した表示に用いるデータに含まれる命令の中の、ユーザー操作を受け付けるためのコントロールに関する命令に従い、生体認証が要求されていることを示す情報を付加して該コントロールを、前記ディスプレイに表示する表示手段と、
   ユーザーの前記コントロールに対する操作に従い、前記サーバーシステムに対して、処理要求を行う要求手段と、
   前記コントロールが表示される位置での該コントロールに対するユーザーの操作によって前記生体情報センサーで読み取った生体情報を用いた前記認証モジュールでの生体認証の結果に基づくデータを生成する生成手段と、を有し、
   前記処理要求および前記生成されたデータに基づいて、前記コントロールに係る情報が前記ディスプレイに表示されることを特徴とする情報処理装置。
2. 前記処理要求には、前記ユーザーの前記コントロールへの操作に対応して生成された第１の検証用データが付加され、
   前記処理要求の要求先から当該第１の検証用データを含む認証要求があった場合に、前記認証モジュールにより生体認証が実行されることを特徴とする請求項１に記載の情報処理装置。
3. 前記記憶手段では生体情報を格納する際に生成された秘密鍵が格納され、
   前記生成手段により生成されたデータを検証するシステムでは前記秘密鍵に対応する公開鍵が登録されており、
   前記認証要求には前記システムで生成された第２の検証用データが含まれ、
   前記生成手段により生成されたデータには、前記認証モジュールにより実行された生体認証が成功した場合に前記記憶手段から取り出される前記秘密鍵と、前記第２の検証用データと、を用いて生成された署名データが含まれ、
   前記システムでは、前記公開鍵を用いて前記署名データの検証が行われることを特徴とする請求項２に記載の情報処理装置。
4. 前記生体情報センサーにより生体情報が読み取れない表示エリアで前記コントロールが表示される場合には、生体認証が要求されていることを示す情報を付加せずに当該コントロールが表示され、
   当該コントロールに対するユーザーの操作が検出された場合には、該操作の後に、ユーザーに生体認証を要求するための画面が追加で表示されることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記生体情報は、ユーザーの指紋に係る情報であることを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
6. 生体認証のための認証モジュールと、該認証モジュールにより認証処理を行う際に必要なユーザーの生体情報を格納する耐タンパー性を備える記憶手段と、ユーザーの生体情報を読み取る生体情報センサーと、ディスプレイと、を有する情報処理装置における方法であって、
   前記情報処理装置とネットワークを介して通信するサーバーシステムから受信した表示に用いるデータに含まれる命令の中の、ユーザー操作を受け付けるためのコントロールに関する命令に従い、生体認証が要求されていることを示す情報を付加して該コントロールを、前記ディスプレイに表示する表示工程と、
   ユーザーの前記コントロールに対する操作に従い、前記サーバーシステムに対して、処理要求を行う要求工程と、
   前記コントロールが表示される位置での該コントロールに対するユーザーの操作によって前記生体情報センサーで読み取った生体情報を用いた前記認証モジュールでの生体認証の結果に基づくデータを生成する生成工程と、を有し、
   前記処理要求および前記生成されたデータに基づいて、前記コントロールに係る情報が前記ディスプレイに表示されることを特徴とする方法。
7. 請求項１乃至５のいずれか１項に記載の各手段としてコンピューターを機能させることを特徴とするプログラム。

Images