JP2013200798A - 生体認証システム、生体認証方法、生体認証プログラム - Google Patents

Abstract

【課題】アプリケーションには固定された情報を埋め込むことなく、かつ認証精度を低下させることなく、適時、確実な本人認証を実施することができる生体認証システムを得る。
【解決手段】ＰＣ１０側からアプリケーションを要求するときに取得した初期生体認証データをサーバー１００側へ送出し、認証結果が成功したときにアプリケーションデータの提供を受けるシステムにおいて、当該成功した初期生体認証データを、アプリケーションに埋め込んでＰＣ側へ送り、この埋め込まれた初期生体認証データと、定期的、不定期、或いはアプリケーション実行中の所定の契機に新規生体認証データを取得し、これらの生体認証を実行することで、アプリケーションを要求したユーザと、実行しているユーザとの同一性を常に確保することができ、セキュリティ性を向上することができる。
【選択図】図１０

Description

開示の技術は、生体認証システム、生体認証方法、生体認証プログラムに関する。

企業の情報システムにおいて、セキュリティを向上させる目的でクライアント側の端末装置では必要最小限の処理をさせながらサーバー側で業務アプリケーションを実行する、「シンクライアント」と呼ばれるシステムアーキテクチャがある。このアーキテクチャでは業務アプリケーション実行中にネットワークの接続性が確保されていることが前提となるため、常時安定的なネットワークへの接続が期待できないような、例えばモバイル用途の端末では使いにくいといった側面がある。

こういった状況に対応するためには、アプリケーションの転送時と実行時に確実な本人認証が必要となる。確実な本人認証の方法としては予め登録された照合用の生体認証データと本人から採取した生体認証データとを照合する生体認証が広く知られている。

ところが、前述のネットワーク接続性の問題を考慮すると、アプリケーションの転送はサーバーで実行するものの、アプリケーション自体はクライアント側の端末装置で実行する必要がある。従って、クライアント側の端末装置とサーバーとの間の生体認証データの整合性を確保しながら、同時にクライアント側の端末装置におけるアプリケーション実行時の安全性を高めなければならない。

生体情報からユーザ固有の暗号鍵を生成して、ユーザのアクセスする情報に対する安全性を高めることを目的とする暗号鍵生成装置が提案されている。この暗号鍵生成装置では、生体情報から生成した生体コードとパスワードから暗号鍵を生成して、これを使用した情報の暗号化及び複合化を可能としている。

しかしながら、生体情報に基づいて同一の本人からは同一の鍵が得られるように精度を落としつつ、他人と同一のコードが得られたときのためにパスワードを併用する構成となっている。従って、これをアプリケーションに埋め込む場合、毎回同一のコードが埋め込まれることになる。

これは固定鍵が埋め込まれた状態と同じであり安全面に問題がある。さらには、前述のように精度を落とすことに起因して類似した生体情報を持つ他人を誤って受け入れる可能性に対しては、安全性がパスワード依存となってしまうという課題がある。

また、高い認証精度で操作の実行中複数回認証を行って、操作者が操作の間で変わっていないことを保証しながらも利用者の負担を増やさないような生体認証を用いた認証方式が提案されている。

この認証システムでは、初期認証に合格したものについて利用者に負担無くその時点での生体情報を取得し格納しておき、初期認証実行後にアクセスしている任意の時点で情報を再取得して格納した生体情報と照合することを可能としている。

しかしながら、最初に初期認証サブシステムにて認証を実施し、認証に成功したら任意時点認証システムが自動で登録処理を行い、その登録データを用いて任意の時点で認証を実施する。この初期認証は、ＩＣカードや暗証番号のほか生体認証も利用可能であるが、生体認証を行う場合は認証強度を落とす必要があり、ＩＣカードなどを併用する構成となっている。

従って、任意時点認証システムに登録された生体情報が本人の生体情報であることを前提としており、システムとして本人の生体情報であることを保証しているわけではないという問題がある。さらに、生体情報の入力を利用者が意識する指紋認証や静脈認証などの方式では適用が困難であるうえに、任意時点認証システムは未検証の登録データを用いており、必ずしも品質の良い生体情報を登録できるとは限らないという問題もある。

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

開示の技術は、認証精度を低下させることなく、適時、確実な本人認証を実施することができる生体認証システム、生体認証方法、生体認証プログラムを得ることが目的である。

開示の技術は、生体認証システムとして、サーバーと端末装置を備える。

サーバーは、アプリケーションの提供が依頼されるときに、依頼元の個人の初期生体認証データを受信する。受信した初期生体認証データと、予め登録された参照生体データとを照合し、生体認証の可否を判定する。生体認証が成功の場合に、依頼されたアプリケーションに前記受信機能で受信した初期生体認証データを埋め込む。初期生体認証データが埋め込まれたアプリケーションを、前記依頼元へ提供する。

端末装置は、認証を必要とする個人の生体認証データを取得する。アプリケーションの提供を依頼するときに、初期生体認証データを付加して送信する。生体認証データに基づく認証が成功であることを条件に、生体認証が成功している初期生体認証データが埋め込まれたアプリケーションを受領する。アプリケーションに埋め込まれた初期生体認証データを参照生体データとして、新たに取得した新規生体認証データと照合し、改めて生体認証の可否を判定する。

開示の技術は、認証精度を低下させることなく、適時、確実な本人認証を実施することができる、という効果を有する。

本実施の形態に係るＰＣとサーバーとの間で、生体認証を踏まえてアプリケーションの授受を実行するための制御を実行する機能ブロックである。 本実施の形態に係る通信回線網を中心としたネットワークシステム構築図である。 サーバーのハード構成を示すブロック図である。 ＰＣのハード構成を示すブロック図である。 生体認証に関する説明であり、（Ａ）〜（Ｃ）は指の指紋の正面図、（Ｄ）は指紋の特徴点を示す拡大図である。 生体認証に関する説明であり、（Ａ）は採取した生体認証データの特徴情報を示す特性図、（Ｂ）は参照生体データの特徴情報を示す特性図、（Ｃ）は、（Ａ）及び（Ｂ）の特性情報の比較を示す図表である。 本実施の形態に係るＰＣ側での、アプリケーション要求、並びに受領の流れを示す制御フローチャートである。 本実施の形態に係るＰＣ側における、アプリケーション実行中の生体認証（再認証）制御の流れを示すフローチャートである。 本実施の形態に係るサーバーにおける、生体認証制御ルーチンを示すフローチャートである。 本実施の形態に係るＰＣとサーバーとの間で実行される生体認証を含むアプリケーション授受のための通信プロトコル図である。

図１は、本実施の形態に係る生体認証をＰＣ１０とサーバー１００との間で実行するシステム図である。

ＰＣ１０は、生体認証センサ１６、生体認証データ取得部３２、要求アプリケーション特定部３４、データ結合部３６、データ送信部３８、アプリケーションデータ受領部４０、アプリケーション実行制御部４２を備える。また、ＰＣ１０は、初期生体認証データ抽出部４４、参照生体データ格納部４６、継続認証時期判別部４８、認証判定部５０、アプリケーション継続可否判定部５２、利用頻度監視部５４を備える。

サーバー１００は、データ受信部１０２、データ解析部１０４、初期生体認証データ抽出部１０６、要求アプリケーションデータ読出部１０８、認証判定部１１０、参照生体データ格納部１１２を備える。また、サーバー１００は、アプリケーション提供可否判定部１１４、埋込部１１６、アプリケーションデータ格納部１１８、アプリケーションデータ提供部１２０を備える。

（ＰＣ１０の機能）
ＰＣ１０に接続された前記生体認証センサ１６は、生体認証データ取得部３２に接続されている。

この生体認証データ取得部３２には、要求アプリケーション特定部３４が接続されている。この要求アプリケーション特定部３４は、ユーザからアプリケーションの要求指示があると、生体認証データ取得部３２を起動し、ユーザに対しては、生体認証データ取得部３２での生体認証の実行を促す報知を行う。報知の形態は、図示は省略したが、例えば、モニタ部１０Ｇ（図４参照）にメッセージを表示すればよい。

これにより、ユーザは、生体認証センサ１６のセンサ部に、ユーザ自身の指を置くことでスキャンされるようになっている。当該スキャンされた生体認証データ（指紋データ）は、生体認証データ取得部３２で取得して、データ結合部３６へ送出されるようになっている。

データ結合部３６には、前記要求アプリケーション特定部３４が接続されている。データ結合部３６では、当該アプリケーションを特定するデータ（通信プロトコルを含むアプリケーション特定データ）と前記生体認証データとを結合するようになっている。結合されたデータは、データ送信部３８から、後述するサーバー１００のデータ受信部１０２に送出される。なお、データ送信部３８とデータ受信部１０２との間では、通信回線を開くための通信プロトコルが実行される場合がある。

ＰＣ１０は、アプリケーションデータ受領部４０を備えている。アプリケーションデータ受領部４０では、前記要求したアプリケーションに基づくデータを受領するが、その条件として、サーバー１００での「生体認証の成功」が必要となる。

言い換えれば、生体認証が失敗した場合は認証失敗通知を受けることになり、生体認証が成功している場合は前記アプリケーションデータ受領部４０によってアプリケーションデータを受領することになる。

ここで、アプリケーションデータには、サーバー１００側での生体認証で成功に至った生体認証データ（以下、「初期生体認証データ」という）が埋め込まれている。

アプリケーションデータ受領部４０は、アプリケーション実行制御部４２及び初期生体認証データ抽出部４４が接続されている。

アプリケーション実行制御部４２は、前記アプリケーションデータ受領部４０で受領したアプリケーションデータに基づいて、アプリケーションを実行する。

また、初期生体認証データ抽出部４４では、アプリケーションデータに埋め込まれている初期生体認証データを抽出する。初期生体認証データ抽出部４４は、参照生体データ格納部４６に接続されており、抽出した初期生体認証データを参照生体データとして格納する。

前記アプリケーション実行制御部４２は、継続認証時期判別部４８に接続され、定期的又は不定期、或いは予め定められたプログラムの実行が開始されるとき等の所定の契機に、生体認証を指示（再認証の指示）する。

継続認証時期判別部４８では、アプリケーション実行制御部４２から再認証の指示を受けると、前記生体認証データ取得部３２に対して生体認証データの取得（再取得）を指示するようになっている。また、継続認証時期判別部４８は、認証判定部５０に接続され、再認証の判定を指示する。

前記生体認証データ取得部３２では、再取得の指示に基づき、ユーザに生体認証センサ１６による生体認証データ（指紋データ）の採取を促す。ここで、前記生体認証データ取得部３２で再取得した生体認証データ（以下、「新規生体認証データ」という）は、認証判定部５０へ送出される。

認証判定部５０では、前記継続認証時期判別部４８からの再認証の判定指示に基づき、前記生体認証データ取得部３２で取得した新規生体認証データと、前記参照生体データ格納部４６に格納されている参照生体データ（初期生体認証データ）とを照合する。

認証判定部５０は、アプリケーション継続可否判定部５２に接続され、認証の結果を送出する。アプリケーション継続可否判定部５２では、アプリケーション実行制御部４２に接続されている。アプリケーション継続可否判定部５２は、再認証の結果が成功の場合は、アプリケーション実行制御部４２に対して実行継続許可信号を出力する。この結果、アプリケーション実行制御部４２ではアプリケーションの実行が継続される。

一方、アプリケーション継続可否判定部５２は、再認証の結果が失敗の場合は、アプリケーション実行制御部４２に対して実行継続不可信号を出力する。この結果、アプリケーション実行制御部４２ではアプリケーションの実行が中断（中止）される。

また、前記アプリケーション受領部４０は、利用頻度監視部５４に接続されている。利用頻度監視部５４では、アプリケーションデータに予め付されている利用の頻度を監視し、当該利用の頻度が制限を超えた場合に、アプリケーション実行制御部４２に対して、実行継続不可信号を出力する。この結果、アプリケーション実行制御部４２ではアプリケーションの実行が中断（中止）される。

本実施の形態では、利用頻度監視部５４で監視する前記利用頻度の情報が、利用期限日であり、期限日を過ぎると、アプリケーションの実行が不可能となる。

（サーバー１００の機能）
前記ＰＣ１０のデータ送信部３８と接続されたデータ受信部１０２は、データ解析部１０４に接続されている。データ解析部１０４は、受信したデータを解析して、初期生体認証データと、要求されたアプリケーションを特定するデータとに分類する。

データ解析部１０４は、初期生体認証データ抽出部１０６及び要求アプリケーションデータ読出部１０８に接続されている。初期生体認証データ抽出部１０６では、データ解析部１０４で分離された初期生体認証データを抽出する。

抽出された初期生体認証データは、認証判定部１１０に送出されるようになっている。認証判定部１１０には、参照生体データ格納部１１２が接続されている。参照生体データ格納部１１２には、予め登録されたユーザの生体認証データである複数の参照生体データが格納されている。

認証判定部１１０では、前記初期生体認証データ抽出部１０６で抽出した初期生体認証データが、前記参照生体データ格納部１１２に格納されている参照生体データの何れかと合致するか否か（成功の可否）を判定する。認証判定部１１０では、生体認証の成功の可否をアプリケーション提供可否判定部１１４へ送出する。

アプリケーション提供可否判定部１１４では、認証判定部１１０から受けた生体認証の結果が成功の場合に、前記初期生体認証データ抽出部１０６から初期生体認証データを受け取り、埋込部１１６へ送出する。また、アプリケーション提供可否判定部１１４では、前記生体認証の結果が成功の場合、前記要求アプリケーションデータ読出部１０８に対して、アプリケーションに関するデータの読み出しを指示する。

要求アプリケーションデータ読出部１０８には、アプリケーションデータ格納部１１８が接続されており、要求されたアプリケーションに関するデータ（アプリケーションデータ）を読み出し、前記埋込部１１６へ送出する。

一方、アプリケーション提供可否判定部１１４では、前記生体認証の結果が失敗の場合、前記要求アプリケーションデータ読出部１０８に対して、アプリケーションの読み出しを禁止すると共に、図示は省略したが、認証が失敗に終わったことをＰＣ１０に通知する。

前記埋込部１１６では、前記要求アプリケーションデータ読出部１０８で読み出したアプリケーションデータに、初期生体認証データを埋め込む。

なお、この埋め込みの際、利用の頻度を設定する情報（利用頻度情報）を付加する場合がある。本実施の形態では、利用頻度情報として、利用期限日を付加している。

前記埋込部１１６は、アプリケーションデータ提供部１２０に接続されており、初期生体認証データの埋め込みが完了したアプリケーションデータをアプリケーションデータ提供部１２０へ送出する。

アプリケーションデータ提供部１２０は、前記ＰＣ１０のアプリケーションデータ受領部４０へアプリケーションデータを送出する。

図２には、本実施の形態に係る通信回線網１２を中心としたネットワークシステムが示されている。

図２に示される如く、通信回線網１２には、本実施の形態に係る複数台（図２では、３台のデスクトップ型と１台のラップトップ型）のＰＣ（パーソナルコンピュータ）１０が接続されている。図２では、４台のＰＣ１０が接続されているが、この数は限定されるものではなく、１台〜３台でもよいし、５台以上であってもよい。

また、通信回線網１２には、端末装置としてのＰＣ１０（各種モバイルデバイスを含む）との間で、無線通信デバイス１４を介して無線によって情報を送受信するシステムを構築してもよい。

図２に示される如く、この通信回線網１２には、アプリケーション管理装置１００（以下、単に「サーバー１００」という場合がある。）が接続されている。サーバー１００は、主として、通信回線網１２に接続されているＰＣ１０から文書情報を受け付けて保存し、一括管理する役目を有している。サーバー１００の詳細な機能については省略する。

図３に示される如く、サーバー１００は、ＣＰＵ１００Ａ、ＲＡＭ１００Ｂ、ＲＯＭ１００Ｃ、Ｉ／Ｏ１００Ｄ及びこれらを相互に接続するデータバスやコントロールバス等のバス１００Ｅを備えたマイクロコンピュータを含んでいる。

Ｉ／Ｏ１００Ｄには、キーボードやマウス等の入力装置１００Ｆと、モニタ１００Ｇが接続されている。また、Ｉ／Ｏ１００Ｄには、Ｉ／Ｆ１００Ｈを介して前記通信回線網１２に接続されている。

なお、サーバー１００は、基本的には、データの送受信が行われればよく、入力装置１００Ｆやモニタ１００Ｇは必須ではない。例えば、メンテナンス時では、専用又は汎用のＩ／ＦにＰＣ等を接続して、入力装置１００Ｆやモニタ１００Ｇを代行するようにすればよい。

サーバー１００側で実行される生体認証プログラムは、データ受信プロセス１０２Ｐ、データ解析プロセス１０４Ｐ、初期生体認証データ抽出プロセス１０６Ｐを備える。

また、サーバー１００側で実行される生体認証プログラムは、要求アプリケーションデータ読出プロセス１０８Ｐ、認証判定プロセス１１０Ｐ、参照生体データ格納プロセス１１２Ｐを備える。

また、サーバー１００側で実行される生体認証プログラムは、アプリケーション提供可否判定プロセス１１４Ｐ、埋込プロセス１１６Ｐ、アプリケーションデータ格納プロセス１１８Ｐ、アプリケーションデータ提供プロセス１２０Ｐを備える。

データ受信プロセス１０２Ｐは、図１に示すデータ受信部１０２として動作する。データ解析プロセス１０４Ｐは、図１に示すデータ解析部１０４として動作する。

初期生体認証データ抽出プロセス１０６Ｐは、図１に示す初期生体認証データ抽出部１０６として動作する。

要求アプリケーションデータ読出プロセス１０８Ｐは、図１に示す要求アプリケーションデータ読出部１０８として動作する。

認証判定プロセス１１０Ｐは、図１に示す認証判定部１１０として動作する。

参照生体データ格納プロセス１１２Ｐは、図１に示す参照生体データ格納部１１２として動作する。

また、アプリケーション提供可否判定プロセス１１４Ｐは、図１に示すアプリケーション提供可否判定部１１４として動作する。

埋込プロセス１１６Ｐは、図１に示す埋込部１１６として動作する。

アプリケーションデータ格納プロセス１１８Ｐは、図１に示すアプリケーションデータ格納部１１８として動作する。

アプリケーションデータ提供プロセス１２０Ｐは、図１に示すアプリケーションデータ提供部１２０として動作する。

図４に示される如く、ＰＣ１０は、ＣＰＵ１０Ａ、ＲＡＭ１０Ｂ、ＲＯＭ１０Ｃ、Ｉ／Ｏ１０Ｄ及びこれらを相互に接続するデータバスやコントロールバス等のバス１０Ｅを備えたマイクロコンピュータを含んでいる。

Ｉ／Ｏ１０Ｄには、入力装置１０Ｆ、モニタ部１０Ｇ、ＵＳＢに代表される外部デバイスとの接続端であるＩ／Ｆ１０Ｈ、無線（または有線）による通信Ｉ／Ｆ１０Iが接続されている。

ＰＣ１０側で実行される生体認証プログラムは、生体認証データ取得プロセス３２Ｐ、要求アプリケーション特定プロセス３４Ｐ、データ結合プロセス３６Ｐを備える。

また、ＰＣ１０側で実行される生体認証プログラムは、データ送信プロセス３８Ｐ、アプリケーションデータ受領プロセス４０Ｐ、アプリケーション実行制御プロセス４２Ｐ、初期生体認証データ抽出プロセス４４Ｐを備える。

また、ＰＣ１０側で実行される生体認証プログラムは、参照生体データ格納プロセス４６Ｐ、継続認証時期判別プロセス４８Ｐ、認証判定プロセス５０Ｐ、アプリケーション継続可否判定プロセス５２Ｐ、利用頻度監視プロセス５４を備える。

生体認証データ取得プロセス３２Ｐは、図１に示す生体認証データ取得部３２として動作する。要求アプリケーション特定プロセス３４Ｐは、図１に示す要求アプリケーション特定部３４として動作する。

データ結合プロセス３６Ｐは、図１に示すデータ結合部３６として動作する。データ送信プロセス３８Ｐは、図１に示すデータ送信部３８として動作する。

アプリケーションデータ受領プロセス４０Ｐは、図１に示すアプリケーションデータ受領部４０として動作する。

アプリケーション実行制御プロセス４２Ｐは、図１に示すアプリケーション実行制御部４２として動作する。

また、初期生体認証データ抽出プロセス４４Ｐは、図１に示す初期生体認証データ抽出部４４として動作する。参照生体データ格納プロセス４６Ｐは、図１に示す参照生体データ格納部４６として動作する。

継続認証時期判別プロセス４８Ｐは、図１に示す継続認証時期判別部４８として動作する。認証判定プロセス５０Ｐは、図１に示す認証判定部５０として動作する。

アプリケーション継続可否判定プロセス５２Ｐは、図１に示すアプリケーション継続可否判定部５２として動作する。利用頻度監視プロセス５４は、図１に示す利用頻度監視部５４として動作する。

ここで、本実施の形態の前記Ｉ／Ｆ１０Ｈには、生体認証センサ１６が接続されている。

生体認証センサ１６では、当該生体認証センサ１６が取り付けられたＰＣ１０からサーバー１００に対して、例えば、アプリケーションのダウンロードの要求をするとき、ダウンロードを許可されているユーザか否かを判定（認証の成否）するために用いられる。

本実施の形態では、認証する生体の部位として指紋を適用する。このため、生体認証センサ１６として指紋認証センサを適用しているが、これに限定されるものではない。

すなわち、生体認証センサ１６は、検出する生体の部位によって選択されるものである。検出される生体の部位としては、指紋、顔、虹彩、網膜、静脈、掌形、ＤＮＡ、音声、署名、耳介等が挙げられる。

以下、それぞれの部位における認証についての概略を説明する。

指紋認証は、普及率が高く、導入コストが比較的低いが、傷や汚れに影響され易い。

顔認証は、センサから離れた位置で利用可能で、なじみやすいが、顔の変化により不安定である。

虹彩認証、網膜認証は、偽造が困難であるが、装置が比較的大型となる。

静脈認証は、精度が高く、偽造が難しいが、導入コストが比較的高い。

掌形認証は、心理的抵抗が少ないが、装置が大型となる。

ＤＮＡ認証は、識別精度が圧倒的に高いが、抽出、分析等に時間がかかる。

音声認証は、心理的抵抗が少ないが、体調や雑音の影響を受けやすい。

署名認証は、心理的抵抗が少なく、なじみやすいが、怪我などにより本人が署名不可能となる場合がある。

耳介認証は、形状が安定しており特徴が多いが、現状では研究開発段階。

以上のように、各部位の認証は、それぞれ一長一短がある。本実施の形態では、ＰＣ１０とサーバー１００との間で取り交わす認証システムとして、他の生体認証センサよりも装置として小型であり、コスト的にも優位である、指紋を選択した。

（指紋認証の概略）
指紋認証は周知の技術であるので、詳細な説明は省略するが、図５及び図６に従い、概略の仕組みを説明する。

指紋の特徴は、図５（Ａ）に示す蹄状紋（loop）の指紋パターン１８、図５（Ｂ）に示す渦状紋（whorl）の指紋パターン２０、図５（Ｃ）に示す弓状紋（arch）の指紋パターン２２などのパターンに分類される。また、図５（Ｄ）に示される如く、指紋には分岐点２４、端点２６、谷線２８、隆線３０等の特徴が見られ、これらの特徴を総称してマニューシャ（minutia）と呼ぶ場合がある。

生体認証センサ１６によって検出した指紋を用いた認証は、このマニューシャを用いて行う場合（マニューシャ方式）と、指紋画像を比較して行う場合（パターンマッチング方式）とがあり、適宜選択すればよい。

図６は、指紋等の認証処理における、採取した生体認証データ（照合用データ）と、予め登録しておいた参照生体データ（登録データ）との照合の原理を座標軸に置き換えて示したものである。

図６（Ａ）の座標軸は、採取した生体認証データの特徴点Ａ（１）、Ｂ（１）、Ｃ（１）、Ｄ（１）の位置を示し、当該特徴点Ａ（１）、Ｂ（１）、Ｃ（１）、Ｄ（１）の向きを矢印で示している。

一方、図６（Ｂ）の座標軸は、予め登録しておいた参照生体データの特徴点Ａ（０）、Ｂ（０）、Ｃ（０）、Ｄ（０）の位置を示し、当該特徴点Ａ（０）、Ｂ（０）、Ｃ（０）、Ｄ（０）の向きを矢印で示している。

図６（Ｃ）は、前記図６（Ａ）及び（Ｂ）の特徴点の位置（座標ｘ，ｙ）と、向き（x軸のプラス方向を０°とした角度）とを数値化した図表である。それぞれの特徴点は、例えば、前記図５（Ｄ）に示す端点２６であり、当該端点２６の位置と、延長する方向（向き）で特定することができる。

この図６（Ｃ）において、各特徴点Ａ〜Ｄの数値の差に基づいて、照合の成功、失敗を判断することになる。当然、数値差が少ない方が一致の精度が高いが、その誤差をどこまで許容するかは、目標とするセキュリティの度合いに基づいて設定すればよい。

（アプリケーションの授受）
ここで、本実施の形態では、ＰＣ１０からサーバー１００に対して、特定のアプリケーションの要求があると、当該要求を受けてサーバー１００からＰＣ１０へアプリケーションを提供する。

このとき、サーバー１００では、要求元のユーザが、アプリケーションを提供してもよいユーザであるかの認証を行っている。

すなわち、ＰＣ１０を所有（或いは操作）しているユーザが、サーバー１００に対してアプリケーションを要求する場合がある。このとき、ＰＣ１０に設けられている生体認証センサ（指紋センサ）１６によって指紋を採取し、前記アプリケーション要求に関する情報と結合してサーバー１００へ送信するようになっている。

サーバー１００では、アプリケーションの要求があると、まず要求元のユーザの認証を行い、認証の結果が成功（提供可能なユーザであることが認証された）の場合に、要求されたアプリケーションを提供する。

なお、生体認証の準備として、ユーザの生体認証情報を予め取得しておき、ユーザの識別符号や属性情報等の必要の設定を行い、サーバー１００側に参照生体データとして登録しておくことが必要であるが、このような処理は実施済みであることを前提とする。

ここで、アプリケーションの提供までは、生体認証により認証結果が成功していることが前提である。しかし、アプリケーションを受領した後は、ＰＣ１０側で当該アプリケーションを実行するため、認証の整合性が維持されているかどうかを判定することができず、セキュリティの面で十分ではない場合がある。これは、シンクラアイントの環境下でも同様である。

そこで、本実施の形態では、サーバー１００において、認証に成功してアプリケーションをＰＣ１０に提供するときに、当該アプリケーションに認証に成功した初期生体認証データを埋め込んで提供するようにした。また、ＰＣ１０側では、アプリケーションの実行中に、前記埋め込まれた初期生体認証データを参照生体データとする。さらに、ＰＣ１０では、前記生体認証センサ１６を用いて、新たに生体認証データ（指紋データ）を採取する。

ＰＣ１０では、適宜時期、例えば、アプリケーションの実行中において定期的、或いは不定期に前記初期生体認証データ（参照生体データ）と、新規生体認証データとを照合するようにした。すなわち、サーバー１００側に設定した生体認証機能とは別に、ＰＣ１０側にも生体認証機能を設定した。

以下に本実施の形態の作用を説明する。

まず、ＰＣ１０、サーバー１００における、それぞれ独立した制御を説明する。

図７は、ＰＣ１０側での、アプリケーション要求、並びに受領の流れを示す制御フローチャートである。

ステップ２００では、要求アプリケーション特定部３４において、要求するアプリケーションを特定したか否かが判断され、否定判定された場合は、このルーチンは終了する。

また、ステップ２００で肯定判定されると、ステップ２０２へ移行して生体認証の実行を指示する報知を行い、ステップ２０４へ移行する。この報知は、例えば、モニタ部１０Ｇにメッセージ等を表示すればよい。

このメッセージ等を見たユーザは、生体認証センサ１６のセンサ部にユーザ自身の指を置き、スキャンすることで、指紋画像のデータ採取が完了する（ステップ２０４での肯定判定）。

次のステップ２０６では、生体認証センサ１６から採取した指紋画像から、生体認証データ取得部３２において初期生体認証データを生成し、ステップ２０８へ移行する。ステップ２０８では、データ結合部３６においてアプリケーション特定情報と初期生体認証データとを結合し、当該結合したデータを、データ送信部３８を用いてサーバー１００へ送信する（ステップ２１０）。ここまでは、ＰＣ１０におけるアプリケーション要求の流れである。

次のステップ２１２では、アプリケーション受領部４０においてアプリケーションを受領したか否かが判断される。ここで、アプリケーションを受領した場合は、生体認証に成功したことを意味する。このステップ２１２で否定判定された場合は、ステップ２１４へ移行して認証失敗通知があったか否かが判断される。このステップ２１４で否定判定された場合は、ステップ２１２へ戻り、上記ステップ２１２、２１４の何れかで肯定判定されるまで繰り返す。

ここで、ステップ２１４で肯定判定されると、生体認証に失敗したと判断され、このルーチンは終了する。この場合、アプリケーションの提供はされない。

また、ステップ２１２で肯定判定されると（生体認証の成功）、ステップ２１６へ移行して、初期生体認証データ抽出部４４において受領したアプリケーションデータに埋め込まれている初期生体認証データを抽出する。次いでステップ２１８では、移行して当該抽出した初期生体認証データを参照生体データ格納部４６へ参照生体データとして格納する。

次のステップ２２０では、利用頻度監視部５４において利用頻度情報を読み出し、次いで、ステップ２２２へ移行してアプリケーションを実行し、このルーチンは終了する。

図８は、ＰＣ１０側における、アプリケーション実行中の生体認証（再認証）制御の流れを示すフローチャートである。

ステップ２５０では、継続認証時期判別部４８において再認証時期（継続するか否か）が判断され、否定判定された場合は、ステップ２６８へ移行する。ステップ２６８以降については、後述する。

前記ステップ２５０で肯定判定された場合は、ステップ２５２へ移行して生体認証の再実行（再認証）を指示する報知を行う。この報知は、例えば、モニタ部１０Ｇにメッセージ等を表示すればよい。

このメッセージ等を見たユーザは、生体認証センサ１６のセンサ部にユーザ自身の指を置き、スキャンすることで、指紋画像のデータ採取（再取得）が完了する（ステップ２５４での肯定判定）。

次のステップ２５６では、採取した指紋画像から生体認証データ取得部３２において新規生体認証データを生成し、ステップ２５８へ移行する。ステップ２５８では、参照生体データ格納部４６から前記アプリケーションを受領したときに埋め込まれた初期生体認証データに基づいて設定された参照生体データを読み出し、ステップ２６０へ移行する。

ステップ２６０では、認証判定部５０において生体認証処理が実行される。生体認証処理の流れは、前述した図５及び図６に基づく処理であり、ここでの説明は省略するが、生体認証処理の結果、一致（成功）、不一致（失敗）の判定が下ることになる。

次のステップ２６２では、アプリケーション継続可否判定部５２において再認証の結果が成功したか否かが判断され、失敗したと判断された場合は、ステップ２６４へ移行して、アプリケーションの実行中止を指示して、このルーチンは終了する。

また、ステップ２６２で成功したと判断された場合は、ステップ２６６でアプリケーションの継続を許可し、ステップ２６８へ移行する。
ステップ２６８では、利用頻度監視部５４においてアプリケーションの利用頻度を算出し、次いでステップ２７０へ移行して、算出された利用頻度を、予め設定した利用の限度と比較する。

次のステップ２７２では、上記比較の結果、利用限度を超えたか否かが判断される。このステップ２７２で肯定判定された場合は、ステップ２６４へ移行する。ステップ２６４では、アプリケーション継続可否判定部５２に対してアプリケーションの実行中止を指示して、このルーチンは終了する。また、ステップ２７２で否定判定された場合は、このルーチンは終了する。

図９は、サーバー１００における、生体認証制御ルーチンを示すフローチャートである。

ステップ２８０では、データ受信部１０２においてＰＣ１０からデータを受信したか否かが判断され、否定判定された場合は、このルーチンは終了する。

また、ステップ２８０で肯定判定されると、ステップ２８２へ移行して、データ解析部１０４で解析した受信データから、初期生体認証データを抽出し（初期生体認証データ抽出部１０６）、ステップ２８４へ移行する。

ステップ２８４では、認証判定部１１０が参照生体データ格納部１１２から参照生体データを読み出し、次いでステップ２８６へ移行して、初期生体認証データ抽出部１０６から初期生体認証データを取り込み、生体認証処理を実行する。

生体認証処理の流れは、前述した図５及び図６に基づく処理であり、ここでの説明は省略するが、生体認証処理の結果、一致（成功）、不一致（失敗）の判定が下ることになる。

次のステップ２８８では、アプリケーション提供可否判定部１１４において生体認証の結果が成功したか否かが判断され、失敗したと判断された場合は、ステップ２９０へ移行して、ＰＣ１０に対して、認証失敗を通知して、このルーチンは終了する。

また、ステップ２８８で成功したと判断された場合は、ステップ２９２へ移行して、要求アプリケーションデータ読出部において、要求されたアプリケーションデータをアプリケーションデータ格納部１１８から読み出し、ステップ２９４へ移行する。

ステップ２９４では、埋込部１１６において前記読み出したアプリケーションデータに、前記認証に成功した初期生体認証データを埋め込む。

次のステップ２９６では、アプリケーションデータ提供部１２０において予め定めた利用頻度に関する情報を付加して、ステップ２９８へ移行し、ＰＣ１０へ当該アプリケーションデータを送信する。これにより、ＰＣ１０へのアプリケーションの提供が完了する。本実施の形態における、利用頻度に関する情報は、利用期限日であり、例えば、２週間を期限とするのであれば、提供当日から２週間後の日付が付加されることになる。

図１０は、ＰＣ１０とサーバー１００との間で実行される生体認証を含むアプリケーション授受のための通信プロトコルについて説明する。なお、ＰＣ１０とサーバー１００とのそれぞれの制御は、前記図７〜図９に示すフローチャートに準じるため、詳細な説明は省略し、処理の流れに沿って説明する。

ＰＣ１０側で、要求するアプリケーションが特定されると、指紋を採取して初期生体認証データを生成し、その後、アプリケーション要求のためのサーバー１００にアクセスする。

サーバー１００側では、ＰＣ１０側からアプリケーションの要求があると、同時に受信した初期生体認証データを抽出して、生体認証処理（照合）を行う。

この照合の結果、生体認証が成功すると、要求されたアプリケーションデータを準備し、生体認証が成功した初期生体認証データを埋め込む。さらに、利用頻度情報を付加した後、ＰＣ側へアプリケーションデータを送信（提供）する。

ＰＣ側では、受け取ったアプリケーションデータから初期生体認証データを抽出して、参照生体データとして格納すると共に、アプリケーションを実行する。

アプリケーションの実行中の適宜時期に、指紋を再度採取する（再取得）し、新規性体認証データを生成し、参照生体データを読み出して、両者を比較照合（生体認証処理）する。生体認証の結果が成功（一致）ならばアプリケーションは実行が許可され、失敗（不一致）ならばアプリケーションは実行が中止される。

また、利用頻度を監視しており、利用の限度を超えた場合にもアプリケーションは実行が中止される。

このように、ＰＣ１０側からアプリケーションを要求するときに取得した初期生体認証データをサーバー１００側へ送出し、認証結果が成功したときにアプリケーションデータの提供を受けるシステムを構築した。その手順は、前記成功した初期生体認証データを、アプリケーションに埋め込んでＰＣ側へ送る。この埋め込まれた初期生体認証データと、定期的、不定期、或いはアプリケーション実行中の所定の契機に新規生体認証データを取得する。これらの生体認証を実行することで、アプリケーションを要求したユーザと、実行しているユーザとの同一性を常に確保することができ、セキュリティ性を向上することができる。

なお、本実施の形態では、ＰＣ１０において、アプリケーションデータに埋め込まれた初期生体認証データを、常時、参照生体データ格納部４６に格納するようにした。しかし、適宜実行される再認証の際に採取する新規生体認証データを参照生体データとして更新するようにしてもよい。

（セキュリティ強化のための変形例）
本実施の形態では、サーバー１００において、初期生体認証データと参照生体データとの照合の結果が成功した場合、提供するアプリケーションデータに、初期生体認証データを埋め込んでいる。

これにより、ＰＣ１０側でのアプリケーション実行中の生体認証を維持できるようにしているが、さらに、セキュリティ性を高めるため、所謂「暗号鍵」を用いた管理システムを追加するようにしてもよい。

以下に、追加可能なセキュリティ強化のための管理システムを列挙する。

（変形例１）
サーバー１００に、初期生体認証データに基づいて、通信鍵を生成するサーバー側通信鍵生成部と、通信鍵を個人ごとに保持する通信鍵管理部とを設ける。

一方、ＰＣ１０に、初期生体認証データから通信鍵を生成するＰＣ側通信鍵生成部を設ける。

ＰＣ１０で生成した通信鍵を使用してサーバー１００との間で通信を開始する。

サーバー１０で、認証成功と判定した後に通信鍵を生成し、ＰＣ１０でアプリケーションデータを受領した後に、新たに通信鍵を生成する。このため、アプリケーションデータを受領した以降のすべて、もしくは一部の期間において新たな通信鍵でＰＣ１０とサーバー１００との間の通信行うことで、よりセキュアなシステムを実現することができる。

（変形例２）
サーバー１００に、初期生体認証データから秘密鍵と公開鍵を生成する鍵ペア生成部と、個人ごとの公開鍵を保持する公開鍵管理部と、秘密鍵を用いてデータを検証する署名検証部とを設ける。

一方、ＰＣ１０側に、秘密鍵を用いて署名する署名部を設ける。

サーバー１００で、生体認証が成功したと判定した後に、当該生体認証データから秘密鍵と公開鍵のペアを生成し、公開鍵については個人ごとに管理する。

ＰＣ１０では、アプリケーションデータを受領した以降のすべて、もしくは一部の期間において通信データのすべて、もしくは一部の期間に対して秘密鍵で署名を施す。これをサーバー１００で検証することでＰＣ１０とサーバー１００との間の通信データの一部、もしくはすべてを、よりセキュアにするシステムを実現することができる。

変形例１、２において、鍵の生成については、毎回異なる照合用生体データをベースとして利用するからこそ、鍵自体も毎回異なり安全であるという特徴がある。

（利用頻度の監視体制の変形例）
本実施の形態では、サーバー１００からＰＣ１０へアプリケーションを提供した後、当該アプリケーションに対して利用の限度を設定すると共に、利用頻度監視部５４（図１参照）で適宜アプリケーションの実行の可否を監視するようにした。さらに、本実施の形態では、利用頻度監視部５４において、予めアプリケーションデータに付加された利用期限日と、アプリケーションの実行日時とを比較し、利用期限日が経過することで、アプリケーションの実行を禁止するようにした。

この利用頻度監視部５４における監視対象は、この利用期限日に限定されるものではない。以下、その変形例を示す。

（変形例３）
利用頻度を監視する対象を、アプリケーションの利用回数とする。

サーバー１００からアプリケーションデータを提供するとき、当該アプリケーションの利用可能回数を付加する。

ＰＣ１０の利用頻度監視部５４では、例えば、アプリケーションの実行回数が１００回を利用限度として監視することができる。

（変形例４）
利用頻度を監視する対象を、ネットワークセグメント情報とする。

サーバー１００からアプリケーションデータを提供するとき、アプリケーションの利用可能セグメント情報を付加する。

ＰＣ１０の利用頻度監視部５４では、予めシステムに設定された値、例えば社内ネットワークであるaa.bb.ccなどを設定すればよい。ＰＣ１０における再認証時にアプリケーションに埋め込まれたネットワークセグメント情報とＰＣ１０に設定されたＩＰアドレスからネットワークセグメントを取得し比較する。これにより、アプリケーション利用するネットワーク環境を判定することができる。

（変形例５）
利用頻度を監視する対象を、利用地点の範囲とする。

サーバー１００からアプリケーションデータを提供するとき、当該アプリケーションの利用可能地点情報を付加する。

ＰＣ１０の利用頻度監視部５４では、予めシステムに設定された値、例えば会社が存在する緯度と経度の範囲であるaa1,bb1, aa2, bb2などを設定すればよい。ＰＣ１０における再認証時にアプリケーションに付加された利用可能地点の範囲とＰＣ１０が存在する地点情報を取得し比較する。これにより、アプリケーションの利用可否を判定することができる。

地点情報は、出先での利用を出先ごとに管理できる点でセキュリティを向上させるという特徴がある。

（変形例６）
利用頻度を監視する対象を、連続失敗回数とする。

サーバー１００からアプリケーションデータを提供するとき、当該アプリケーションの許容失敗回数を付加する。

ＰＣ１０の利用頻度監視部５４では、予めシステムに設定された値、例えば５回などを設定すればよい。ＰＣ１０における再認証時にアプリケーションに付加された許容失敗回数と、現在の失敗回数を比較することで、アプリケーションの利用の可否を判定することができる。

なお、本実施の形態、並びに変形例３〜変形例６では、利用頻度の種類、並びに限度の設定を画一的に設定するようにした。しかし、生体認証要求のあったユーザ個人、或いは予め定めたグループ毎に、異なる利用頻度の種類、並びに限度の設定を行うようにしてもよい。

（アプリケーション実行中における生体再認証に基づく、運用上、適用可能な変形例）
（変形例７）
例えば、利用頻度を監視し、限度を超えた場合、アプリケーションの実行が禁止されることが前提である。しかし、ＰＣ１０とサーバー１００との間で無線通信回線を利用してアプリケーションを実行しているとき、無線環境によって、一時的に通信ができないことが起こり得る。

そこで、一時的に通信ができないことによる利用頻度のカウント（特に、アプリケーション実行回数等）を緩和することで、利便性を高めることができる。

（変形例８）
サーバー１００からアプリケーションを提供するとき、当該アプリケーションの許容簡易認証回数を付加する。例えば、予めシステムに設定された値、例えば５回などを設定する。

ＰＣ１０では、付加された許容簡易認証回数分だけ、初期生体認証データと新規生体認証データとの照合（再認証）の認証方法を簡易型に変更する。例えば、単純な数値や文字の羅列を入力するパスワード方式等がこれに該当する。ＰＣ１０では、初回の再認証時に認証方法を変更し、再認証の回数を記録するとともに許容簡易認証回数と比較することで、簡易認証方式の許容範囲を制御する。

簡易型とすることで、例えば、ＰＣ１０がモバイルデバイスのような場合、認証の都度、指紋を採取するといった不便さを一時的に解消することが可能となる。

変形例７，８において、限度の緩和については、こういった機能がないと出先での利用で困る人が出てくるため、現実的にはシステム管理部門の運用管理コストを低減させることが可能という特徴がある。

（変形例９）
ＰＣ１０において、利用頻度監視部５４の監視結果に応じて、アプリケーションデータを消去する。これにより、利用限度の到達後にアプリケーションデータが消去されるため、よりセキュリティを高めたアプリケーション実行環境を実現することができる。

アプリケーションの消去はセキュリティを向上させるうえで必要な機能である。

（変形例１０）
ＰＣ１０において、特定のアプリケーションに基づく生体認証の結果を、別のアプリケーションに通知するようにしてもよい。このような場合、例えば、アプリケーションには認証に関連する機能のみを搭載し、別の業務アプリケーションの実行可否を制御するような使い方が可能となる。

アプリケーション自体に認証機能を持たせることができない場合、認証インタフェースを実装するというやり方は今後想定される形態である。

（変形例１１）
ＰＣ１０において、再認証結果を履歴として保持しておき、この認証履歴をサーバー１００に送信するようにしてもよい。サーバー１００では、個人ごとの再認証履歴を把握可能としておく。

これにより、例えば、個人ごとに利用限度を調整するといった細かなシステムセキュリティの設定を実現することができる。

上記では、生体認証プログラムがＰＣ１０のＲＯＭ１０Ｃ、並びにサーバー１００のＲＯＭ１００Ｃに予め記憶されている態様を説明したが、生体認証プログラムは、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の記録媒体に記録されている形態で提供することも可能である。

また、上記ではＰＣ１０で実行される生体認証プログラムがＰＣ１０のＲＯＭ１０Ｃに予め記憶されている態様を説明したが、これに限定されるものではない。例えば、上記の生体認証プログラムを、図７に示した処理を行う第１のプログラムと、図８に示した処理を行う第２のプログラムとに分割する。第２のプログラムについては、アプリケーションプログラムに付加された状態で、サーバー１００からＰＣ１０に配信されるようにしてもよい。

本明細書に記載された全ての文献、特許出願及び技術規格は、個々の文献、特許出願及び技術規格が参照により取り込まれることが具体的かつ個々に記載された場合と同程度に、本明細書中に参照により取り込まれる。

１２ 通信回線網
１０ ＰＣ
１０Ａ ＣＰＵ
１０Ｂ ＲＡＭ
１０Ｃ ＲＯＭ
１０Ｄ Ｉ／Ｏ
１０Ｅ バス
１０Ｆ 入力装置
１０Ｇ モニタ部
１０Ｈ Ｉ／Ｆ
１０Ｉ 通信Ｉ／Ｆ
１４ 無線通信デバイス
１６ 生体認証センサ
１８ 指紋パターン
２０ 指紋パターン
２２ 指紋パターン
２４ 分岐点
２６ 端点
２８ 谷線
３０ 隆線
３２ 生体認証データ取得部
３４ 要求アプリケーション特定部
３６ データ結合部
３８ データ送信部
４０ アプリケーションデータ受領部
４２ アプリケーション実行制御部
４４ 初期生体認証データ抽出部
４６ 参照生体データ格納部
４８ 継続認証時期判別部
５０ 認証判定部
５２ アプリケーション継続可否判定部
５４ 利用頻度監視部
１００ アプリケーション管理装置（サーバー）１００
１００Ａ ＣＰＵ
１００Ｂ ＲＡＭ
１００Ｃ ＲＯＭ
１００Ｄ Ｉ／Ｏ
１００Ｅ バス
１００Ｆ 入力装置
１００Ｇ モニタ
１００Ｈ Ｉ／Ｆ
１０２ データ受信部
１０４ データ解析部
１０６ 初期生体認証データ抽出部
１０８ 要求アプリケーションデータ読出部
１１０ 認証判定部
１１２ 参照生体データ格納部
１１４ アプリケーション提供可否判定部
１１６ 埋込部
１１８ アプリケーションデータ格納部
１２０ アプリケーションデータ提供部

Claims (8)

1. アプリケーションの提供が依頼されるときに、依頼元の個人の初期生体認証データを受信する受信部と、
   前記受信部で受信した初期生体認証データと、予め登録された参照生体データとを照合し、生体認証の可否を判定する初期生体認証部と、
   前記初期生体認証部による生体認証が成功の場合に、依頼されたアプリケーションに前記受信部で受信した初期生体認証データを埋め込む埋込部と、
   前記埋込部で初期生体認証データが埋め込まれたアプリケーションを、前記依頼元へ提供するアプリケーション提供部と、
   を備えたサーバーと、
   認証を必要とする個人の生体認証データを取得する生体認証データ取得部と、
   アプリケーションの提供を依頼するときに、前記生体認証データ取得部で取得した初期生体認証データを付加して送信する送信部と、
   前記送信部で送信された生体認証データに基づく認証が成功であることを条件に前記初期生体認証部で生体認証が成功している初期生体認証データが埋め込まれたアプリケーションを受領するアプリケーション受領部と、
   前記アプリケーションに埋め込まれた初期生体認証データを参照生体データとして、新たに前記生体認証データ取得部で取得した新規生体認証データと照合し、改めて生体認証の可否を判定する継続生体認証部と、
   を備えた端末装置と、
   を有する生体認証システム。
2. 前記サーバーが、初期生体認証データの品質を判定する第１の品質判定部をさらに備え、
   前記埋込部が、品質を判定した後の初期生体認証データを前記アプリケーションに埋め込む請求項1記載の生体認証システム。
3. 前記端末装置が、前記継続認証部による継続認証時に、新たに取得した新規生体認証データの品質を判定する第２の品質判定部と、
   前記アプリケーションに埋め込まれた初期生体認証データの品質を、新規生体認証データを取得する毎に更新する更新部と、
   をさらに有する請求項１又は請求項２記載の生体認証システム。
4. 前記継続生体認証部による、生体認証判定に限度を設ける請求項１〜請求項３の何れか１項記載の生体認証システム。
5. 認証を必要とする個人の生体認証データを取得する生体認証データ取得部を備えた端末装置からアプリケーションの提供が依頼された際に、前記生体認証データ取得部によって取得された個人の初期生体認証データを前記端末装置から受信する受信部と、
   前記受信部で受信した初期生体認証データと、予め登録された参照生体データとを照合し、生体認証の可否を判定する初期生体認証部と、
   前記初期生体認証部による生体認証が成功の場合に、前記端末装置から依頼され、前記端末装置を、前記アプリケーションに埋め込まれた初期生体認証データを参照生体データとして、新たに生体認証取得部で取得した新規生体認証データと照合し、改めて生体認証の可否を判定する継続生体認証部として機能させるための継続生体認証プログラムが付加されたアプリケーションに、前記受信部で受信した初期生体認証データを埋め込む埋込部と、
   前記継続生体認証プログラムが付加され、前記埋込部で初期生体認証データが埋め込まれたアプリケーションを、前記端末装置へ提供するアプリケーション提供部と、
   を生体認証装置。
6. 端末装置側で、個人の初期生体認証データを生成し、
   生成した生体認証データを付加した状態で、サーバー側へアプリケーションの提供を依頼し、
   サーバー側で、受信した初期生体認証データと、予め登録された参照生体データとを照合して生体認証の可否を判定し、
   生体認証が成功した場合に、依頼されたアプリケーションに、前記初期生体認証データを埋め込んで、依頼元へ提供し、
   端末装置側で、改めて取得した個人の新規生体認証データと、アプリケーションに埋め込まれた初期生体認証データとの照合により生体認証を行う生体認証方法。
7. コンピュータに、
   アプリケーションの提供が依頼されるときに、依頼元の個人の初期生体認証データを受信し、
   前記受信した初期生体認証データと、予め登録された参照生体データとを照合し、生体認証の可否を判定し、
   前記初期生体認証データの生体認証が成功の場合に、依頼されたアプリケーションに、当該初期生体認証データを埋め込み、
   前記初期生体認証データが埋め込まれたアプリケーションを、前記依頼元へ提供する処理を実行させる生体認証プログラム。
8. コンピュータに、
   認証を必要とする個人の生体認証データを取得し、
   アプリケーションの提供を依頼するときに、前記取得した初期生体認証データを付加して送信し、
   送信された生体認証データに基づく認証が成功であることを条件に前記初期生体認証データが埋め込まれたアプリケーションを受領し、
   前記アプリケーションに埋め込まれた初期生体認証データを参照生体データとして、新たに取得した新規生体認証データとを照合し、改めて生体認証の可否を判定する処理を実行させる生体認証プログラム。