JP2008047140A - データ認証方法 - Google Patents

Abstract

【課題】本発明はデータ認証方法に関し、いずれのクライアントであっても、そのクライアントが持つバイオデータの読み取り機能と同一種類の認証データが登録されていれば認証することができるデータ認証方法を提供することを目的としている。
【解決手段】バイオ認証サーバとクライアントが接続されたシステムにおいて、クライアント毎に認証手段を１種類のみとし、認証時間を固定するように構成する。このように構成すれば、複数の認証を行なわないため、認証手段を固定にすることで、クライアントからの不正アクセス防止を行なうことができる。また、遠隔地又は通信速度が遅い場所等、アクセス時間がかかる場合の認証時間を短縮することができる。
【選択図】図１

Description

本発明はデータ認証方法に関し、更に詳しくはバイオ認証データに基づいてユーザを認証するようにしたデータ認証方法に関する。

従来の複数種類のバイオデータによる認証を行なうシステムにおいては、ユーザとクライアントの対応が一義的に決められている。このため、複数種類のバイオデータによる認証が可能であっても、予めユーザに認証時のバイオデータの種類が決められていた。

従来のこの種の技術としては、指紋、顔相などの身体的特徴のライブパターンを読取装置により読み取ったライブパターンデータと、記録している特徴の基準パターンデータとを照合する照合手段と、照合手段の前又は後において、完全一致またはタイムスタンプの一致または履歴との一致によりライブパターンが不正なデータであるか否かを判断するシステムが知られている（例えば特許文献１参照）。また、生体情報を利用して個人認証する生体認証システムに関し、生体情報検出時の不安定さがあっても、照合精度の低下を防止するシステムが知られている（例えば特許文献２参照）
特開２００３−３０８３０２号公報 特開２００６−６７５３号公報

従来システムでは、認証のために設定された以外の種類のバイオデータ読み取り手段では認証データが登録されていても認証ができなかった。このため、設定された種類以外のバイオデータの読み取り手段しか持たないクライアントでは、認証が行えないという問題があった。

本発明はこのような課題に鑑みてなされたものであって、いずれのクライアントであっても、そのクライアントが持つバイオデータの読み取り機能と同一種類の認証データが登録されていれば認証することができるデータ認証方法を提供することを目的としている。

（１）請求項１記載の発明は、バイオ認証サーバとクライアントが接続されたシステムにおいて、クライアント毎に認証手段を１種類のみとし、認証時間を固定にしたことを特徴とする。
（２）請求項２記載の発明は、前記システムにおいて、個別認証チャートにより認証することを特徴とする。

（１）請求項１記載の発明によれば、複数の認証を行なわないため、認証手段を固定にすることで、クライアントからの不正アクセス防止を行なうことができる。また、遠隔地又は通信速度が遅い場所等、アクセス時間がかかる場合の認証時間を短縮することができる。
（２）請求項２記載の発明によれば、認証手段を固定にすることで、クライアントからの不正アクセスを防止することができる。

以下、図面を参照して本発明の実施の形態例を詳細に説明する。
図１は本発明の一実施の形態例を示すブロック図である。この実施の形態例は、クライアント２０側にデータベースを設けることにより、サーバの必要なくデータ照合が行なえるようにしたものである。図において、２２はバイオセンサードライバ、２３はバイオデータ照合部、２４はバイオデータ変換部、２６はプログラム制御部、４０はアプリケーション、５０はデータベースである。データベース５０には、バイオ認証データ登録テーブル４１と、ユーザテーブル４２が含まれている。

このように構成されたシステムにおける動作を図２を用いて説明する。図２は本発明の第１の処理フローを示す図である。先ず、アプリケーション４０から照合要求を行なう（Ｓ１）。この結果、プログラム制御部２６が起動される（Ｓ２）。各バイオセンサー（バイオ読取装置）は、バイオセンサードライバ２２で駆動され、バイオデータを出力する（Ｓ３）。

バイオデータ変換部２４は、バイオデータを受けて、特徴部分を抽出する処理を行なう（Ｓ４）。次に、バイオデータ照合部２３は、バイオセンサーで測定されたバイオデータと、バイオ認証データ登録テーブル４１に記憶されている認証データを読み出し、認証データとの照合を行なう（Ｓ５）。次に、照合結果の判定を行なう（Ｓ６）。次に、プログラム制御部２６が動作し（Ｓ７）、アプリケーション４０を通じて結果を通知する（Ｓ８）。

図３は第１のデータの流れ説明図である。図において、１０はサーバ、３０は該サーバ１０と接続されたデータベースである。該データベース３０には、認証用データが＃１〜＃ＮまでＮ個設けられており、それぞれの認証用データには、ユーザ用認証データがユーザ毎に設けられている。２０’は複数のバイオ読取装置（バイオセンサー）付きのクライアントであり、＃１〜＃ＮまでのＮ個の読取装置が取り付けられている。２０は単機能の読取機能が設けられたクライアントであり、単機能の読取装置付クライアントである。６０は、認証データを用いてユーザの認証を行なう認証サーバプログラムであり、サーバ１０内に設けられている（以下同じ）。以下の動作は、この認証サーバプログラム６０が主体となって行なうものである。
１）複数のバイオ読取装置付クライアント２０’からＮ種類のバイオデータを読み込む。ここで、ユーザが複数いる場合には、ユーザ毎にＮ種類のバイオデータを読み込むことになる。その結果、データベース３０に示すように、それぞれの認証用データがユーザ毎に求まり、データベース３０に記憶されることになる。
２）ここで、任意のクライアント２０からサーバ１０に対して認証要求を行なう。この場合において、データベース３０には、ユーザ毎に複数の種類の認証データが記憶されているため、どのクライアントからも認証要求を行なうことが可能になる。
３）認証サーバプログラム６０は、クライアント２０から送られてきたデータと対応する認証用データとの照合を行なう。この場合において、認証用データは、ユーザ毎に記憶されているので、認証にあたっては、どのユーザであるのかを示すユーザＩＤの入力が必要となる。
４）認証サーバプログラム６０は、各クライアント２０に対して照合結果を送信する。

この実施の形態例によれば、サーバ１０は必要に応じてバイオデータと認証データとの照合を行ない、その結果をクライアント２０に通知することができる。
図４は本発明の第１の処理説明図である。この実施の形態例は、重要度に応じて照合結果の論理条件をとって最終の認証を決定するものである。例えば、図に示すように、重要度が小さい場合には、Ｎ個のバイオデータの内の何れか一つが照合すれば、認証ＯＫと判定する。つまり、この場合には、各認証結果のオアをとるものである。このような場合としては、例えばＷｉｎｄｏｗｓ（マイクロソフト社の登録商標）ログオンのように、単にＷｉｎｄｏｗｓにアクセスするだけである場合には、（指紋一致）ＯＲ（声紋致一致）ＯＲ（顔形一致）という具合に一つでも照合するものがあれば、認証ＯＫとする。

これに対して重要度が大きくなれば（例えばワークフロー業務の決済）、照合がＯＫとなる条件をきつくする。即ち、Ｎ個のバイオデータの全てが照合した時に認証ＯＫとするものである。具体的には、（指紋一致）ＡＮＤ（声紋一致）ＡＮＤ（顔形一致）という具合に全てが照合した場合に、認証ＯＫとする。

図５は本発明の第２の処理フローを示す図である。先ず、重要度が小さい場合の動作について説明する。この場合には、先ず第１の認証を要求する（Ｓ１）。これにより、第１の認証を開始する（Ｓ２）。認証がＯＫの場合には、即本人と判断する（Ｓ３）。認証がＮＧの場合には、ステップＳ１に戻り、次の認証データの認証要求を行なう処理に入る。全ての認証がＮＧの場合、又は認証がキャンセルされた場合には、他人と判断する（Ｓ４）。

次に、重要度が一番大きい場合の動作について説明する。先ず、第１の認証要求をし（Ｓ１０）、第１の認証を開始する（Ｓ１１）。認証がＯＫの場合には、第２の認証要求をする（Ｓ１２）。そして、第２の認証を開始する（Ｓ１３）。この認証がＯＫの場合には、第３の認証要求をする。以上のような処理を第Ｎの認証まで行なう。即ち、第Ｎの認証要求を行ない（Ｓ１４）、第Ｎの認証を開始する（Ｓ１５）。そして、第Ｎの認証の結果ＯＫの場合には本人と判断する（Ｓ１６）。ここで、ステップＳ１５において、第Ｎの認証がＯＫであったということは第１〜第Ｎまでの全ての認証がＯＫであったことを示している。以上の処理において、認証がＮＧの場合には、ステップＳ１０に戻り最初から認証をやりなおす。それぞれの認証工程において認証がキャンセルされた場合には、他人と判断する（Ｓ１７）。

この実施の形態例によれば、複数のバイオ認証を組み合わせて、用途に応じて認証度の高低を設定することができる。また、高額な決済処理を行なう電子稟議やインターネットにおける高額商品を取り扱うシステムにおいては厳密な本人認証を行なうことができる。

次に、認証種類の組み合わせ情報を用いた認証方法について説明する。認証種類の組み合わせは、サーバ側にもクライアント側にも持つことができる。
図６は本発明の第３の処理フローを示す図である。システムとしては、図２８を用いる。図２８は本発明の他の実施の形態例を示すブロック図である。図１に示す実施の形態例と比較して、サーバ１０とクライアント２０が接続されている点が異なる。サーバ１０は通信手段１１を介してクライアント２０の通信手段２１と接続されている。サーバ１０側にもバイオデータ照合部１２が設けられている。１３はプログラム制御部、３０はデータベースである。該データベース３０には、バイオ認証データ登録テーブル３１と、ユーザテーブル３２が設けられている。クライアント２０側において、２５はデータを記憶する記憶部で、２５ａはサーバ１０からのデータを一時記憶するキャッシュメモリである。

アプリケーション４０から照合要求があると（Ｓ１）、制御がプログラム制御部２６に移行する（Ｓ２）。次に、認証バイオの決定又は認証要求回数の決定が行われる（Ｓ３）。次に、どのようなバイオセンサーが設けられているか、バイオセンサーの検索を行なう（Ｓ４）。

バイオセンサーが設けられている場合、使用するバイオセンサーを決定する（Ｓ５）。バイオセンサーが決定したら、バイオセンサードライバでバイオデータを測定する（Ｓ６）。そして、バイオデータを読み込む（Ｓ７）。読み込んだバイオデータに対して、バイオデータ変換部２４で特徴部分を抽出するバイオデータ変換を行なう（Ｓ８）。次に、読み込んだバイオデータとデータベースに記憶されている認証データとの照合を行なう（Ｓ９）。

次に、照合結果の判定を行なう（Ｓ１０）。そして、照合結果が判定されたら、プログラム制御部２６に制御を移し（Ｓ１１）、アプリケーション４０を通して結果を通知する（Ｓ１２）。ステップＳ４でバイオセンサーが検索できない場合、プログラム制御部２６に制御を渡す（Ｓ１３）。そして、アプリケーション４０を通して結果を通知する（Ｓ１４）。

図７は、認証種類の組み合わせ情報をサーバ側に持たせた場合のアプリケーション情報テーブルの構成例を示す図である。図に示すように、アプリケーション名毎に、バイオ認証データが記憶されている。例えば、アプリケーション１におけるバイオ認証データ１においては、バイオ認証データはバイオ＃１データである。

図８は、認証種類の組み合わせ情報をアプリケーション側で持つ場合の、アプリケーションで保持する認証種類の組み合わせ情報を示す図である。
図９は第２のデータの流れ説明図である。図３と同一のものは、同一の符号を付して示す。図において、３３ａは図７に示すアプリケーション情報テーブルである。
１）設定クライアント２０よりアプリケーションとバイオ認証との設定情報をアプリケーション情報テーブル３３に登録する。なお、アプリケーション情報テーブル３３ａは、複数のバイオデータを設定可能である。例えば、バイオ１＋バイオ２等。
２）ユーザはアプリケーション１を通して認証の要求を行なう。
３）アプリケーション１又はＮからアプリケーション情報テーブル３３ａへ、アプリケーションとバイオの関連情報を登録する。
４）アプリケーション１へアプリケーションとバイオの関連情報を返す。
５）アプリケーション１からバイオ１の認証を返す。

後は、読み取られたバイオデータをバイオ認証サーバ１０へ送り、照合する。図１０は一連認証の処理フローを示す図で、クライアント側の動作を示している。認証の要求を行なうと（Ｓ１）、バイオデータの読み取りを行ない、認証手段を決定する（Ｓ２）。次に、第１の認証要求を行なうと（Ｓ３）、第１の認証が開始される（Ｓ４）。そして以下の処理を順次繰り返していく。そして、認証の要求を行ない（Ｓ５）、バイオデータの読み取りを行ない、認証手段を決定する（Ｓ６）。そして、第Ｎの認証要求を行ない（Ｓ７）、第Ｎの認証を開始する（Ｓ８）。そして、認証がＯＫの場合、本人と判断する（Ｓ９）。

ここで、ステップＳ４において第１の認証がＮＧの場合、再度認証するかどうかチェックする（Ｓ１０）。再度認証する場合には、ステップＳ１に戻り、認証しない場合には、他人と判断する（Ｓ１１）。ステップＳ１２の場合も、再度認証するかどうかチェックし（Ｓ１２）、認証する場合にはステップＳ１に戻り、認証しない場合には他人と判断する（Ｓ１３）。ここで、それぞれの認証開始時に認証がキャンセルされた場合には、他人と
判断して（Ｓ１４）、処理を終了する。

この実施の形態例によれば、複数マルチバイオを呼び出す仕組みを予め設定しておくことで、プログラムの汎用性を確保することができる。サーバ管理は、本人のバイオ情報品質や運用に合わせて認証種類を固定にできる場合に有効で、認証種類の組み合わせ情報を一元管理可能とすることができる。また、アプリケーション側管理は、要求セキュリティ強度に合わせて個別調整が可能である。

図１１は個別認証チャートの処理フローを示す図で、クライアント側の動作を示している。この処理フローは、図９に示すシステムで、個別認証チャートで認証を行なうようにしたものである。先ず、認証の要求を行なうと（Ｓ１）、バイオデータの読み取りを行ない、認証手段を決定する（Ｓ２）。次に、第１の認証要求を行なう（Ｓ３）。そして、第１の認証を開始する（Ｓ４）。第１の認証がＯＫであった場合には、次に進む。

ステップＳ４において、認証がＮＧの場合には、再度認証するかどうかをチェックする（Ｓ５）。再度認証する場合には、ステップＳ１に戻って認証要求からやり直す。再度認証をしない場合には、他人と判断する（Ｓ６）。このようなシーケンスを認証手段の数だけ繰り返す。そして、その都度、認証がＮＧの時のステップＳ５とＳ６の処理を繰り返す。

第１の認証がＯＫの場合、認証の要求を行なう（Ｓ７）。そして、バイオデータの読み取りを行ない、認証手段を決定する（Ｓ８）。そして、第Ｎの認証要求を行ない（Ｓ９）、第Ｎの認証を開始する（Ｓ１０）。第Ｎの認証結果がＯＫの場合には、本人と判断する（Ｓ１１）。認証結果がＮＧの場合には、再度認証するかどうかチェックする（Ｓ１３）。再度認証する場合には、ステップＳ７に戻って認証要求からやり直す。再度認証しない場合には、他人と判断する（Ｓ１４）。なお、認証でキャンセルする場合には、何れも他人と判断される（Ｓ１２）。この実施の形態例におけるデータの流れ説明図（第３のデータの流れ説明図）は、図９に示す第２のデータの流れ説明図と同じである。

この実施の形態例によれば、本人のバイオ情報品質や運用に合わせて認証種類を固定にできる場合に有効で、認証種類の組み合わせ情報を一元管理可能とすることができる。また、アプリケーション側管理は、要求セキュリティ強度に合わせて個別調整が可能となる。

次に、次の実施の形態例について説明する。以下の実施の形態例は、クライアント毎に検出する手段を決めておき、クライアント毎に検出手段を１種類のみとし、認証時間を固定にすることで、クライアント側からの不正アクセス防止を行ない、認証時間を短縮するようにしたものである。

図１２はこの実施の形態例で用いるクライアント情報テーブルの構成例を示す図である。クライアント毎に、認証できる種類が固定されている。例えば、バイオ認証データ１の場合、クライアント１で認証できるのはバイオ＃１データのみである。

図１３は第３のデータの流れ説明図である。
１）設定クライアント２０よりクライアントとバイオ認証との設定情報をクライアント情報テーブル３４に登録する。ここで、クライアント情報テーブル３４は、複数のバイオデータを設定可能である。例えば、バイオ１＋バイオ２等。
２）ユーザは、アプリケーション１を通して認証の要求を行なう。
３）アプリケーション１又はＮからクライアント情報テーブル３４へクライアントとバイオの関連情報を取得する。
４）アプリケーション１へクライアントとバイオの関連情報を返す。
５）アプリケーション１からバイオ１の認証を返す。

後は、読み取られたバイオデータをバイオ認証サーバ１０へ送り、照合する。
この実施の形態例によれば、認証手段を固定にすることで、クライアントからの不正アクセス防止を行なうことができる。また、遠隔地又は通信速度が遅い場所等、アクセス時間がかかる場合の認証時間を短縮することができる。

図１４は第４のデータの流れ説明図である。この実施の形態例は、個別認証チャートにより認証するようにしたものである。図１３と同一のものは、同一の符号を付して示す。１）設定クライアント２０よりクライアントとバイオ認証との設定情報をクライアント情報テーブル３４に登録する。クライアント情報テーブル３４は、複数のバイオデータを設定可能である。例えば、バイオ１＋バイオ２等。
２）ユーザはアプリケーション１を通して認証の要求を行なう。
３）アプリケーション１又はＮからクライアント情報テーブル３４へクライアントとバイオとの関連情報を取得する。
４）アプリケーション１へクライアントとバイオとの関連情報を返す。
５）アプリケーション１からバイオ１の認証を返す。

後は、読み取られたバイオデータをバイオ認証サーバへ送り、照合する。
この実施の形態例によれば、認証手段を固定にすることで、クライアントからの不正アクセス防止を行なうことができる。

次に、データ照合時の認識率に認証精度を設けるようにした場合について説明する。図１５はバイオ認証データ登録テーブルの構成例を示す図である。このテーブルでは、バイオデータ毎に、認証率（認証精度）を変えている。図１９はバイオ認証ユーザ情報テーブルの構成例を示す図である。このテーブルは、ユーザ毎に該当するバイオの認証精度を設けるようにしたものである。例えば、ユーザＩＤが１の場合のバイオ＃１の認証データの認証精度は７０％、バイオ＃Ｎの認証データの認証精度は８５％にそれぞれ設定してある。ここで、バイオ認証データ登録テーブルを３５、バイオ認証ユーザ情報テーブルを３６とする。これらテーブルは、サーバ１０側のデータベース３０側に設けられる。或いは、各クライアント側に設けるようにしてもよい。

図１７は、第５のデータの流れ説明図である。３７は照合時の認証精度を記憶しておく認証精度ログである。
１）設定クライアント２０より、それぞれのバイオデータに関する認証データを定義する。
２）それぞれのクライアントからＩＤ単位で照合要求を行なう。
３）照合結果を判定し、サーバ１０で定義されている認証データと比較を行なう。
その際、認証精度を認証データに対応して記憶する。この場合において、照合時の認証精度の求め方は以下の通りである。即ち、照合時の認証データの一致数をＡ、認証数をＢとして、１００Ａ／Ｂ（％）で求める。このようにして求めた認証精度は、認証精度ログ３７に記憶しておく。
４）クライアント２０に、認証結果と共に、認証データを送信する。
５）次回照合要求時、バイオ認証サーバ１０から認証精度ログを読み出し、予め決められた認証精度を保持していない場合、認証要求クライアント２０に対して、認証データ更新要求又は使用不可通知を行なう。

この実施の形態例によれば、生体の経年変化による認証データの精度の低下による誤認識を防止することができる。
図１８は、第６のデータの流れ説明図である。ユーザ１が設定クライアント２０からサーバ１０にアクセスする場合の動作を示している。
１）ユーザ１がバイオ１データを持って、登録要求を行なう。
２）認証サーバプログラム６０は、ユーザ１におけるバイオ１データで照合を行なう。この場合、最初のバイオデータの照合にはシステム管理者が立ち会う。
３）認証サーバプログラム６０から、クライアント２０に向けて照合結果が返される。
４）認証された場合、バイオデータＮへの登録許可が与えられ、ユーザ１のバイオデータＮをデータベース３０に登録する。認証されなかった場合、ユーザ１へのバイオＮデータは登録できない。

この実施の形態例によれば、マルチバイオシステムにおいて、２個目以降のバイオデータを登録する際、システム管理者を必要とせずにバイオデータの登録を行なうため、登録の煩雑さを避けることができる。

次の実施の形態例は、照合時にユーザにバイオデータの種類を選択をしなくてもすむようにしたものである。このために、図１９に示すようなバイオ認証ユーザ照合順序テーブルを用いる。このテーブルでは、ユーザＩＤ毎に、照合順序が決められている。例えば、ユーザ１の場合、第１番目にバイオデータ１を用いた照合を行ない、次にバイオデータ２を用いた照合を行なう。最後に、バイオデータＮを用いた照合を行なう。ユーザ２の場合には、第１番目にバイオデータ２を用いた照合を行ない、第２番目にバイオデータ４を用いた照合を行ない、最後にバイオデータ１を用いた照合を行なう。

図２０は第７のデータの流れ説明図である。図において、３８は前述したバイオ認証ユーザ照合順序テーブルであり、データベース３０内に設けられている。
１）バイオデータの登録を行なう際、ユーザＩＤ毎に照合するバイオデータの順序を定義する。
２）クライアント２０より照合要求を行なう。
３）認証サーバプログラム６０が、送られてきたユーザＩＤを基に照合順序テーブル３８よりマルチバイオの照合順序を決定し３）−１）、クライアント２０側に返す３）−２）。
４）クライアント２０は、照合順序に従い、クライアント２０にあるバイオセンサーを検索し、バイオデータを読み込み、照合要求を行なう。
５）サーバ１０側では、送られてきたバイオデータの照合を行ない、照合結果をクライアント２０に通知する。

この実施の形態例によれば、マルチバイオ装置を扱うシステムにおいて、照合するバイオ認識装置を選択する手間が省ける。また、マルチバイオ装置を扱うシステムにおいて、照合する順序を一度設定すれば、全てのクライアントで同じ設定を共有できる。更に、マルチバイオ装置を扱うシステムにおいて、照合する順序のプライオリティを設定することができる。

次の実施の形態例について説明する。上述した照合方法は１：１照合という。即ち、ユーザＩＤを入力後、そのユーザＩＤを基に登録されているバイオデータと照合し、そのＩＤの本人性を確かめる照合方法である。

これに対して、１：Ｎ照合とは、照合要求のあったバイオデータと、登録されているバイオデータ全てを照合し、そのバイオデータから本人を特定する照合方法である（バイオデータのみで本人を特定するもの）。

図２１は、認証画面例を示す図である。ユーザ名を入力する部分（ユーザＩＤフィール
ド）があり、認証ボタン、キャンセルボタン、終了ボタン等が設けられている。先の１：１照合の場合には、ユーザＩＤフィールドにユーザＩＤを入れる必要がある。図２２は、システムログインへの組み込みの説明図である。ユーザＩＤフィールドにユーザＩＤを書き込むことにより、ログインする。

図２３は照合処理の動作を示すフローチャートである。システムとしては、図１を用いる。先ず、アプリケーション４０より認証の要求を行なう（Ｓ１）。この結果、制御がプログラム制御部２６に移る。クライアント２０は、バイオデータの読み取りを行なう（Ｓ３）。次に、クライアント２０はＩＤが入力されているかどうか判断する（Ｓ４）。

ＩＤが入力されている場合、サーバ１０はＩＤを基に事前に登録されているバイオデータを検索する（Ｓ５）。そして、読み取ったバイオデータとステップＳ５で検索された登録されているバイオデータと照合を行なう（Ｓ６）。次に、照合結果の判定を行なう（Ｓ７）。そして、照合結果を要求アプリケーション４０へ返す（Ｓ８）。

ステップＳ４において、ＩＤが入力されていない場合、ＩＤが特定できない。そこで、事前に登録されている全てのバイオデータとステップＳ３で読み取ったバイオデータの照合を行ない（Ｓ９）、ステップＳ７に進む（１：Ｎ照合）。

この実施の形態例によれば、照合における検索時間を短縮できるため、マルチバイオシステムにおける照合において、バイオ読み取り装置検索の効率化並びに照合の効率化を行なうことができる。

また、ユーザＩＤが通知されない場合には、事前に登録されている全てのバイオデータとの照合を行なうことにより、ユーザＩＤがない時にも、本人を特定することができる。
次の実施の形態例は、前回一致したバイオデータの種類の登録データから照合を行なうようにしたものである。前回の照合履歴を見るために、図２４に示すようなバイオ認証ログデータテーブル３９が用いられる。このテーブルには、ユーザＩＤ毎にバイオ認証データと、操作年月日と、操作の種類と、結果が記憶されている。このバイオ認証ログデータテーブル３９を参照して、照合結果がＯＫであった場合の認証データを用いるものである。

図２５は第８のデータの流れ説明図である。図において、３９がバイオ認証ログデータテーブルで、データベース３０内に設けられている。
１）ユーザ１が、認証サーバプログラム６０に照会要求を行なう。
２）認証サーバプログラム６０は、バイオ認証ログデータテーブル３９を検索し、前回一致したユーザ１のバイオ認証種類情報を取得する。
３）認証サーバプログラム６０は、バイオデータＮと照合を行なう。
４）照合結果をクライアント２０に通知する。

この実施の形態例によれば、複数種類のバイオデータによる組み合わせの認証の場合、照合における検索時間を短縮することができる。
次の実施の形態例は、クライアントからサーバに照合要求をする場合に、バイオデータに加えてバイオ読取装置情報も一緒に転送するようにしたものである。図２６は第９のデータの流れ説明図である。図において、７０は読取装置情報データテーブルであり、読取装置毎に対応するバイオデータを記憶しておくものである。
１）バイオデータを読み取る際、バイオ読み取り装置情報も読み取り、認証サーバプログラム６０に照合要求を行なう。
２）サーバ１０は、読み取り装置情報データテーブル７０を参照して、読み取られたバイオデータを判断し、認証サーバプログラム６０にバイオ認証種類データを返す。
３）２）より返された情報を基に、認証データと測定したバイオデータとの照合を行なう。
４）照合結果は、クライアント２０に通知される。

この実施の形態例によれば、照合における検索時間を短縮できるため、マルチバイオシステムにおける照合において、バイオ読み取り装置検索の効率化並びに照合の効率化を行なうことができる。

次の実施の形態例について説明する。この実施の形態例は、本来サーバ側で保持している認証データを、クライアント側に転送し、クライアント側で認証データを保持するようにして、クライアントのみでデータの照合を行なうことができるようにしたものである。

図２７は、第１０のデータの流れ説明図である。この実施の形態例では、クライアント２０側に記憶装置８０を設け、この記憶装置にデータベース３０からのバイオデータを日付データと共に記憶させるようにしたものである。
１）クライアント２０は、バイオデータ１で照合要求をする。
２）サーバ１０側の照合結果がクライアント２０側に通知される。
３）認証サーバ１０は、サーバの日付データとクライアント側の日付データとを比較する。
４）サーバ１０上の日付データがクライアント２０側の日付データより新しい場合、クライアント２０に照合要求ユーザのバイオデータをダウンロード（キャッシュ）する。同一の場合には、ダウンロードしない。

この実施の形態例によれば、認証サーバ及びネットワークにおける過大な負荷を軽減することができる。
このように、本発明によれば、いずれのクライアントであっても、そのクライアントが持つバイオデータの読み取り機能と同一種類の認証データが登録されていれば認証することができるデータ認証方法及びデータ認証装置を提供することができる。

本発明の一実施の形態例を示すブロック図である。 本発明の第１の処理フローを示す図である。 第１のデータの流れ説明図である。 本発明の第１の処理説明図である。 本発明の第２の処理フローを示す図である。 本発明の第３の処理フローを示す図である。 アプリケーション情報テーブルの構成例を示す図である。 アプリケーションで保持する認証種類の組み合わせ情報を示す図である。 第２のデータの流れ説明図である。 一連認証の処理フローを示す図である。 個別認証チャートの処理フローを示す図である。 クライアント情報テーブルの構成例を示す図である。 第３のデータの流れ説明図である。 第４のデータの流れ説明図である。 バイオ認証データ登録テーブルの構成例を示す図である。 バイオ認証ユーザ情報テーブルの構成例を示す図である。 第５のデータの流れ説明図である。 第６のデータの流れ説明図である。 バイオ認証ユーザ照合順序テーブルの構成例を示す図である。 第７のデータの流れ説明図である。 認証画面例を示す図である。 システムログインへの組み込みの説明図である。 照合処理の動作を示すフローチャートである。 バイオ認証ログデータテーブルの構成例を示す図である。 第８のデータの流れ説明図である。 第９のデータの流れ説明図である。 第１０のデータの流れ説明図である。 本発明の他の実施の形態例を示すブロック図である。

符号の説明

２０ クライアント
２２ バイオセンサードライバ
２３ バイオデータ照合部
２４ バイオデータ変換部
２５ バイオセンサードライバ
２６ プログラム制御部
４０ アプリケーション
４１ バイオ認証データ登録テーブル
４２ ユーザテーブル
５０ データベース

Claims (2)

1. バイオ認証サーバとクライアントが接続されたシステムにおいて、クライアント毎に認証手段を１種類のみとし、認証時間を固定にしたことを特徴とするデータ認証方法。
2. 前記システムにおいて、個別認証チャートにより認証することを特徴とする請求項１記載のデータ認証方法。

Images