データ認証装置
【課題】本発明はデータ認証装置に関し、バイオデータの読み取り機能と同一種類の認証データが登録されていれば認証することができるデータ認証装置を提供することを目的としている。
【解決手段】クライアントから登録された認証データを保持するサーバと、そのサーバに接続しているクライアントで構成され、クライアントは認証のためのデータ読み取り手段を有し、予め設定された認証のタイミングにおいて、認証データ入力手段から入力された認証データを認証サーバに転送し、クライアントから送信されてきた認証データと照合し、その結果をクライアントに送信するシステムにおいて、1度サーバで認証し本人と同一と判断した場合、サーバに登録されている認証データをクライアントに送信し、クライアントではそのデータを保持し、それ以降の認証時はクライアントで保持した認証データと入力した認証データを比較するように構成する。
【解決手段】クライアントから登録された認証データを保持するサーバと、そのサーバに接続しているクライアントで構成され、クライアントは認証のためのデータ読み取り手段を有し、予め設定された認証のタイミングにおいて、認証データ入力手段から入力された認証データを認証サーバに転送し、クライアントから送信されてきた認証データと照合し、その結果をクライアントに送信するシステムにおいて、1度サーバで認証し本人と同一と判断した場合、サーバに登録されている認証データをクライアントに送信し、クライアントではそのデータを保持し、それ以降の認証時はクライアントで保持した認証データと入力した認証データを比較するように構成する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明はデータ認証装置に関し、更に詳しくはバイオ認証データに基づいてユーザを認証するようにしたバイオ認証装置に関する。
【背景技術】
【0002】
従来の複数種類のバイオデータによる認証を行なうシステムにおいては、ユーザとクライアントの対応が一義的に決められている。このため、複数種類のバイオデータによる認証が可能であっても、予めユーザに認証時のバイオデータの種類が決められていた。
【0003】
従来のこの種の技術としては、指紋、顔相などの身体的特徴のライブパターンを読取装置により読み取ったライブパターンデータと、記録している特徴の基準パターンデータとを照合する照合手段と、照合手段の前又は後において、完全一致またはタイムスタンプの一致または履歴との一致によりライブパターンが不正なデータであるか否かを判断するシステムが知られている(例えば特許文献1参照)。また、生体情報を利用して個人認証する生体認証システムに関し、生体情報検出時の不安定さがあっても、照合精度の低下を防止するシステムが知られている(例えば特許文献2参照)
【特許文献1】特開2003−308302号公報
【特許文献2】特開2006−6753号公報
【発明の開示】
【発明が解決しようとする課題】
【0004】
従来システムでは、認証のために設定された以外の種類のバイオデータ読み取り手段では認証データが登録されていても認証ができなかった。このため、設定された種類以外のバイオデータの読み取り手段しか持たないクライアントでは、認証が行えないという問題があった。
【0005】
本発明はこのような課題に鑑みてなされたものであって、いずれのクライアントであっても、そのクライアントが持つバイオデータの読み取り機能と同一種類の認証データが登録されていれば認証することができるデータ認証装置を提供することを目的としている。
【課題を解決するための手段】
【0006】
(1)請求項1記載の発明は、クライアントから登録された認証データを保持するサーバと、そのサーバにネットワークで接続しているクライアントで構成されるシステムにおいて、クライアントは認証のためのデータ読み取り手段を有し、予め設定された認証のタイミングにおいて、認証データ入力手段から入力された認証データを認証サーバに転送し、クライアントから送信されてきた認証データと照合し、その結果をクライアントに送信するシステムにおいて、1度サーバで認証し本人と同一と判断した場合、サーバに登録されている認証データをクライアントに送信し、クライアントではそのデータを保持し、それ以降の認証時はクライアントで保持した認証データと入力した認証データを比較するようにしたことを特徴とする。
【発明の効果】
【0007】
(1)請求項1記載の発明によれば、認証サーバ及びネットワークにおける過大な負荷を軽減することができる。
【発明を実施するための最良の形態】
【0008】
以下、図面を参照して本発明の実施の形態例を詳細に説明する。
図1は本発明の一実施の形態例を示すブロック図である。この実施の形態例は、クライアント20側にデータベースを設けることにより、サーバの必要なくデータ照合が行なえるようにしたものである。図において、22はバイオセンサードライバ、23はバイオデータ照合部、24はバイオデータ変換部、26はプログラム制御部、40はアプリケーション、50はデータベースである。データベース50には、バイオ認証データ登録テーブル41と、ユーザテーブル42が含まれている。
【0009】
このように構成されたシステムにおける動作を図2を用いて説明する。図2は本発明の第1の処理フローを示す図である。先ず、アプリケーション40から照合要求を行なう(S1)。この結果、プログラム制御部26が起動される(S2)。各バイオセンサー(バイオ読取装置)は、バイオセンサードライバ22で駆動され、バイオデータを出力する(S3)。
【0010】
バイオデータ変換部24は、バイオデータを受けて、特徴部分を抽出する処理を行なう(S4)。次に、バイオデータ照合部23は、バイオセンサーで測定されたバイオデータと、バイオ認証データ登録テーブル41に記憶されている認証データを読み出し、認証データとの照合を行なう(S5)。次に、照合結果の判定を行なう(S6)。次に、プログラム制御部26が動作し(S7)、アプリケーション40を通じて結果を通知する(S8)。
【0011】
図3は第1のデータの流れ説明図である。図において、10はサーバ、30は該サーバ10と接続されたデータベースである。該データベース30には、認証用データが#1〜#NまでN個設けられており、それぞれの認証用データには、ユーザ用認証データがユーザ毎に設けられている。20’は複数のバイオ読取装置(バイオセンサー)付きのクライアントであり、#1〜#NまでのN個の読取装置が取り付けられている。20は単機能の読取機能が設けられたクライアントであり、単機能の読取装置付クライアントである。60は、認証データを用いてユーザの認証を行なう認証サーバプログラムであり、サーバ10内に設けられている(以下同じ)。以下の動作は、この認証サーバプログラム60が主体となって行なうものである。
1)複数のバイオ読取装置付クライアント20’からN種類のバイオデータを読み込む。ここで、ユーザが複数いる場合には、ユーザ毎にN種類のバイオデータを読み込むことになる。その結果、データベース30に示すように、それぞれの認証用データがユーザ毎に求まり、データベース30に記憶されることになる。
2)ここで、任意のクライアント20からサーバ10に対して認証要求を行なう。この場合において、データベース30には、ユーザ毎に複数の種類の認証データが記憶されているため、どのクライアントからも認証要求を行なうことが可能になる。
3)認証サーバプログラム60は、クライアント20から送られてきたデータと対応する認証用データとの照合を行なう。この場合において、認証用データは、ユーザ毎に記憶されているので、認証にあたっては、どのユーザであるのかを示すユーザIDの入力が必要となる。
4)認証サーバプログラム60は、各クライアント20に対して照合結果を送信する。
【0012】
この実施の形態例によれば、サーバ10は必要に応じてバイオデータと認証データとの照合を行ない、その結果をクライアント20に通知することができる。
図4は本発明の第1の処理説明図である。この実施の形態例は、重要度に応じて照合結果の論理条件をとって最終の認証を決定するものである。例えば、図に示すように、重要度が小さい場合には、N個のバイオデータの内の何れか一つが照合すれば、認証OKと判定する。つまり、この場合には、各認証結果のオアをとるものである。このような場合としては、例えばWindows(マイクロソフト社の登録商標)ログオンのように、単にWindowsにアクセスするだけである場合には、(指紋一致)OR(声紋致一致)OR(顔形一致)という具合に一つでも照合するものがあれば、認証OKとする。
【0013】
これに対して重要度が大きくなれば(例えばワークフロー業務の決済)、照合がOKとなる条件をきつくする。即ち、N個のバイオデータの全てが照合した時に認証OKとするものである。具体的には、(指紋一致)AND(声紋一致)AND(顔形一致)という具合に全てが照合した場合に、認証OKとする。
【0014】
図5は本発明の第2の処理フローを示す図である。先ず、重要度が小さい場合の動作について説明する。この場合には、先ず第1の認証を要求する(S1)。これにより、第1の認証を開始する(S2)。認証がOKの場合には、即本人と判断する(S3)。認証がNGの場合には、ステップS1に戻り、次の認証データの認証要求を行なう処理に入る。全ての認証がNGの場合、又は認証がキャンセルされた場合には、他人と判断する(S4)。
【0015】
次に、重要度が一番大きい場合の動作について説明する。先ず、第1の認証要求をし(S10)、第1の認証を開始する(S11)。認証がOKの場合には、第2の認証要求をする(S12)。そして、第2の認証を開始する(S13)。この認証がOKの場合には、第3の認証要求をする。以上のような処理を第Nの認証まで行なう。即ち、第Nの認証要求を行ない(S14)、第Nの認証を開始する(S15)。そして、第Nの認証の結果OKの場合には本人と判断する(S16)。ここで、ステップS15において、第Nの認証がOKであったということは第1〜第Nまでの全ての認証がOKであったことを示している。以上の処理において、認証がNGの場合には、ステップS10に戻り最初から認証をやりなおす。それぞれの認証工程において認証がキャンセルされた場合には、他人と判断する(S17)。
【0016】
この実施の形態例によれば、複数のバイオ認証を組み合わせて、用途に応じて認証度の高低を設定することができる。また、高額な決済処理を行なう電子稟議やインターネットにおける高額商品を取り扱うシステムにおいては厳密な本人認証を行なうことができる。
【0017】
次に、認証種類の組み合わせ情報を用いた認証方法について説明する。認証種類の組み合わせは、サーバ側にもクライアント側にも持つことができる。
図6は本発明の第3の処理フローを示す図である。システムとしては、図28を用いる。図28は本発明の他の実施の形態例を示すブロック図である。図1に示す実施の形態例と比較して、サーバ10とクライアント20が接続されている点が異なる。サーバ10は通信手段11を介してクライアント20の通信手段21と接続されている。サーバ10側にもバイオデータ照合部12が設けられている。13はプログラム制御部、30はデータベースである。該データベース30には、バイオ認証データ登録テーブル31と、ユーザテーブル32が設けられている。クライアント20側において、25はデータを記憶する記憶部で、25aはサーバ10からのデータを一時記憶するキャッシュメモリである。
【0018】
アプリケーション40から照合要求があると(S1)、制御がプログラム制御部26に移行する(S2)。次に、認証バイオの決定又は認証要求回数の決定が行われる(S3)。次に、どのようなバイオセンサーが設けられているか、バイオセンサーの検索を行なう(S4)。
【0019】
バイオセンサーが設けられている場合、使用するバイオセンサーを決定する(S5)。バイオセンサーが決定したら、バイオセンサードライバでバイオデータを測定する(S6)。そして、バイオデータを読み込む(S7)。読み込んだバイオデータに対して、バイオデータ変換部24で特徴部分を抽出するバイオデータ変換を行なう(S8)。次に、読み込んだバイオデータとデータベースに記憶されている認証データとの照合を行なう(S9)。
【0020】
次に、照合結果の判定を行なう(S10)。そして、照合結果が判定されたら、プログラム制御部26に制御を移し(S11)、アプリケーション40を通して結果を通知する(S12)。ステップS4でバイオセンサーが検索できない場合、プログラム制御部26に制御を渡す(S13)。そして、アプリケーション40を通して結果を通知する(S14)。
【0021】
図7は、認証種類の組み合わせ情報をサーバ側に持たせた場合のアプリケーション情報テーブルの構成例を示す図である。図に示すように、アプリケーション名毎に、バイオ認証データが記憶されている。例えば、アプリケーション1におけるバイオ認証データ1においては、バイオ認証データはバイオ#1データである。
【0022】
図8は、認証種類の組み合わせ情報をアプリケーション側で持つ場合の、アプリケーションで保持する認証種類の組み合わせ情報を示す図である。
図9は第2のデータの流れ説明図である。図3と同一のものは、同一の符号を付して示す。図において、33aは図7に示すアプリケーション情報テーブルである。
1)設定クライアント20よりアプリケーションとバイオ認証との設定情報をアプリケーション情報テーブル33に登録する。なお、アプリケーション情報テーブル33aは、複数のバイオデータを設定可能である。例えば、バイオ1+バイオ2等。
2)ユーザはアプリケーション1を通して認証の要求を行なう。
3)アプリケーション1又はNからアプリケーション情報テーブル33aへ、アプリケーションとバイオの関連情報を登録する。
4)アプリケーション1へアプリケーションとバイオの関連情報を返す。
5)アプリケーション1からバイオ1の認証を返す。
【0023】
後は、読み取られたバイオデータをバイオ認証サーバ10へ送り、照合する。図10は一連認証の処理フローを示す図で、クライアント側の動作を示している。認証の要求を行なうと(S1)、バイオデータの読み取りを行ない、認証手段を決定する(S2)。次に、第1の認証要求を行なうと(S3)、第1の認証が開始される(S4)。そして以下の処理を順次繰り返していく。そして、認証の要求を行ない(S5)、バイオデータの読み取りを行ない、認証手段を決定する(S6)。そして、第Nの認証要求を行ない(S7)、第Nの認証を開始する(S8)。そして、認証がOKの場合、本人と判断する(S9)。
【0024】
ここで、ステップS4において第1の認証がNGの場合、再度認証するかどうかチェックする(S10)。再度認証する場合には、ステップS1に戻り、認証しない場合には、他人と判断する(S11)。ステップS12の場合も、再度認証するかどうかチェックし(S12)、認証する場合にはステップS1に戻り、認証しない場合には他人と判断する(S13)。ここで、それぞれの認証開始時に認証がキャンセルされた場合には、他人と
判断して(S14)、処理を終了する。
【0025】
この実施の形態例によれば、複数マルチバイオを呼び出す仕組みを予め設定しておくことで、プログラムの汎用性を確保することができる。サーバ管理は、本人のバイオ情報品質や運用に合わせて認証種類を固定にできる場合に有効で、認証種類の組み合わせ情報を一元管理可能とすることができる。また、アプリケーション側管理は、要求セキュリティ強度に合わせて個別調整が可能である。
【0026】
図11は個別認証チャートの処理フローを示す図で、クライアント側の動作を示している。この処理フローは、図9に示すシステムで、個別認証チャートで認証を行なうようにしたものである。先ず、認証の要求を行なうと(S1)、バイオデータの読み取りを行ない、認証手段を決定する(S2)。次に、第1の認証要求を行なう(S3)。そして、第1の認証を開始する(S4)。第1の認証がOKであった場合には、次に進む。
【0027】
ステップS4において、認証がNGの場合には、再度認証するかどうかをチェックする(S5)。再度認証する場合には、ステップS1に戻って認証要求からやり直す。再度認証をしない場合には、他人と判断する(S6)。このようなシーケンスを認証手段の数だけ繰り返す。そして、その都度、認証がNGの時のステップS5とS6の処理を繰り返す。
【0028】
第1の認証がOKの場合、認証の要求を行なう(S7)。そして、バイオデータの読み取りを行ない、認証手段を決定する(S8)。そして、第Nの認証要求を行ない(S9)、第Nの認証を開始する(S10)。第Nの認証結果がOKの場合には、本人と判断する(S11)。認証結果がNGの場合には、再度認証するかどうかチェックする(S13)。再度認証する場合には、ステップS7に戻って認証要求からやり直す。再度認証しない場合には、他人と判断する(S14)。なお、認証でキャンセルする場合には、何れも他人と判断される(S12)。この実施の形態例におけるデータの流れ説明図(第3のデータの流れ説明図)は、図9に示す第2のデータの流れ説明図と同じである。
【0029】
この実施の形態例によれば、本人のバイオ情報品質や運用に合わせて認証種類を固定にできる場合に有効で、認証種類の組み合わせ情報を一元管理可能とすることができる。また、アプリケーション側管理は、要求セキュリティ強度に合わせて個別調整が可能となる。
【0030】
次に、次の実施の形態例について説明する。以下の実施の形態例は、クライアント毎に検出する手段を決めておき、クライアント毎に検出手段を1種類のみとし、認証時間を固定にすることで、クライアント側からの不正アクセス防止を行ない、認証時間を短縮するようにしたものである。
【0031】
図12はこの実施の形態例で用いるクライアント情報テーブルの構成例を示す図である。クライアント毎に、認証できる種類が固定されている。例えば、バイオ認証データ1の場合、クライアント1で認証できるのはバイオ#1データのみである。
【0032】
図13は第3のデータの流れ説明図である。
1)設定クライアント20よりクライアントとバイオ認証との設定情報をクライアント情報テーブル34に登録する。ここで、クライアント情報テーブル34は、複数のバイオデータを設定可能である。例えば、バイオ1+バイオ2等。
2)ユーザは、アプリケーション1を通して認証の要求を行なう。
3)アプリケーション1又はNからクライアント情報テーブル34へクライアントとバイオの関連情報を取得する。
4)アプリケーション1へクライアントとバイオの関連情報を返す。
5)アプリケーション1からバイオ1の認証を返す。
【0033】
後は、読み取られたバイオデータをバイオ認証サーバ10へ送り、照合する。
この実施の形態例によれば、認証手段を固定にすることで、クライアントからの不正アクセス防止を行なうことができる。また、遠隔地又は通信速度が遅い場所等、アクセス時間がかかる場合の認証時間を短縮することができる。
【0034】
図14は第4のデータの流れ説明図である。この実施の形態例は、個別認証チャートにより認証するようにしたものである。図13と同一のものは、同一の符号を付して示す。1)設定クライアント20よりクライアントとバイオ認証との設定情報をクライアント情報テーブル34に登録する。クライアント情報テーブル34は、複数のバイオデータを設定可能である。例えば、バイオ1+バイオ2等。
2)ユーザはアプリケーション1を通して認証の要求を行なう。
3)アプリケーション1又はNからクライアント情報テーブル34へクライアントとバイオとの関連情報を取得する。
4)アプリケーション1へクライアントとバイオとの関連情報を返す。
5)アプリケーション1からバイオ1の認証を返す。
【0035】
後は、読み取られたバイオデータをバイオ認証サーバへ送り、照合する。
この実施の形態例によれば、認証手段を固定にすることで、クライアントからの不正アクセス防止を行なうことができる。
【0036】
次に、データ照合時の認識率に認証精度を設けるようにした場合について説明する。図15はバイオ認証データ登録テーブルの構成例を示す図である。このテーブルでは、バイオデータ毎に、認証率(認証精度)を変えている。図19はバイオ認証ユーザ情報テーブルの構成例を示す図である。このテーブルは、ユーザ毎に該当するバイオの認証精度を設けるようにしたものである。例えば、ユーザIDが1の場合のバイオ#1の認証データの認証精度は70%、バイオ#Nの認証データの認証精度は85%にそれぞれ設定してある。ここで、バイオ認証データ登録テーブルを35、バイオ認証ユーザ情報テーブルを36とする。これらテーブルは、サーバ10側のデータベース30側に設けられる。或いは、各クライアント側に設けるようにしてもよい。
【0037】
図17は、第5のデータの流れ説明図である。37は照合時の認証精度を記憶しておく認証精度ログである。
1)設定クライアント20より、それぞれのバイオデータに関する認証データを定義する。
2)それぞれのクライアントからID単位で照合要求を行なう。
3)照合結果を判定し、サーバ10で定義されている認証データと比較を行なう。
その際、認証精度を認証データに対応して記憶する。この場合において、照合時の認証精度の求め方は以下の通りである。即ち、照合時の認証データの一致数をA、認証数をBとして、100A/B(%)で求める。このようにして求めた認証精度は、認証精度ログ37に記憶しておく。
4)クライアント20に、認証結果と共に、認証データを送信する。
5)次回照合要求時、バイオ認証サーバ10から認証精度ログを読み出し、予め決められた認証精度を保持していない場合、認証要求クライアント20に対して、認証データ更新要求又は使用不可通知を行なう。
【0038】
この実施の形態例によれば、生体の経年変化による認証データの精度の低下による誤認識を防止することができる。
図18は、第6のデータの流れ説明図である。ユーザ1が設定クライアント20からサーバ10にアクセスする場合の動作を示している。
1)ユーザ1がバイオ1データを持って、登録要求を行なう。
2)認証サーバプログラム60は、ユーザ1におけるバイオ1データで照合を行なう。この場合、最初のバイオデータの照合にはシステム管理者が立ち会う。
3)認証サーバプログラム60から、クライアント20に向けて照合結果が返される。
4)認証された場合、バイオデータNへの登録許可が与えられ、ユーザ1のバイオデータNをデータベース30に登録する。認証されなかった場合、ユーザ1へのバイオNデータは登録できない。
【0039】
この実施の形態例によれば、マルチバイオシステムにおいて、2個目以降のバイオデータを登録する際、システム管理者を必要とせずにバイオデータの登録を行なうため、登録の煩雑さを避けることができる。
【0040】
次の実施の形態例は、照合時にユーザにバイオデータの種類を選択をしなくてもすむようにしたものである。このために、図19に示すようなバイオ認証ユーザ照合順序テーブルを用いる。このテーブルでは、ユーザID毎に、照合順序が決められている。例えば、ユーザ1の場合、第1番目にバイオデータ1を用いた照合を行ない、次にバイオデータ2を用いた照合を行なう。最後に、バイオデータNを用いた照合を行なう。ユーザ2の場合には、第1番目にバイオデータ2を用いた照合を行ない、第2番目にバイオデータ4を用いた照合を行ない、最後にバイオデータ1を用いた照合を行なう。
【0041】
図20は第7のデータの流れ説明図である。図において、38は前述したバイオ認証ユーザ照合順序テーブルであり、データベース30内に設けられている。
1)バイオデータの登録を行なう際、ユーザID毎に照合するバイオデータの順序を定義する。
2)クライアント20より照合要求を行なう。
3)認証サーバプログラム60が、送られてきたユーザIDを基に照合順序テーブル38よりマルチバイオの照合順序を決定し3)−1)、クライアント20側に返す3)−2)。
4)クライアント20は、照合順序に従い、クライアント20にあるバイオセンサーを検索し、バイオデータを読み込み、照合要求を行なう。
5)サーバ10側では、送られてきたバイオデータの照合を行ない、照合結果をクライアント20に通知する。
【0042】
この実施の形態例によれば、マルチバイオ装置を扱うシステムにおいて、照合するバイオ認識装置を選択する手間が省ける。また、マルチバイオ装置を扱うシステムにおいて、照合する順序を一度設定すれば、全てのクライアントで同じ設定を共有できる。更に、マルチバイオ装置を扱うシステムにおいて、照合する順序のプライオリティを設定することができる。
【0043】
次の実施の形態例について説明する。上述した照合方法は1:1照合という。即ち、ユーザIDを入力後、そのユーザIDを基に登録されているバイオデータと照合し、そのIDの本人性を確かめる照合方法である。
【0044】
これに対して、1:N照合とは、照合要求のあったバイオデータと、登録されているバイオデータ全てを照合し、そのバイオデータから本人を特定する照合方法である(バイオデータのみで本人を特定するもの)。
【0045】
図21は、認証画面例を示す図である。ユーザ名を入力する部分(ユーザIDフィール
ド)があり、認証ボタン、キャンセルボタン、終了ボタン等が設けられている。先の1:1照合の場合には、ユーザIDフィールドにユーザIDを入れる必要がある。図22は、システムログインへの組み込みの説明図である。ユーザIDフィールドにユーザIDを書き込むことにより、ログインする。
【0046】
図23は照合処理の動作を示すフローチャートである。システムとしては、図1を用いる。先ず、アプリケーション40より認証の要求を行なう(S1)。この結果、制御がプログラム制御部26に移る。クライアント20は、バイオデータの読み取りを行なう(S3)。次に、クライアント20はIDが入力されているかどうか判断する(S4)。
【0047】
IDが入力されている場合、サーバ10はIDを基に事前に登録されているバイオデータを検索する(S5)。そして、読み取ったバイオデータとステップS5で検索された登録されているバイオデータと照合を行なう(S6)。次に、照合結果の判定を行なう(S7)。そして、照合結果を要求アプリケーション40へ返す(S8)。
【0048】
ステップS4において、IDが入力されていない場合、IDが特定できない。そこで、事前に登録されている全てのバイオデータとステップS3で読み取ったバイオデータの照合を行ない(S9)、ステップS7に進む(1:N照合)。
【0049】
この実施の形態例によれば、照合における検索時間を短縮できるため、マルチバイオシステムにおける照合において、バイオ読み取り装置検索の効率化並びに照合の効率化を行なうことができる。
【0050】
また、ユーザIDが通知されない場合には、事前に登録されている全てのバイオデータとの照合を行なうことにより、ユーザIDがない時にも、本人を特定することができる。
次の実施の形態例は、前回一致したバイオデータの種類の登録データから照合を行なうようにしたものである。前回の照合履歴を見るために、図24に示すようなバイオ認証ログデータテーブル39が用いられる。このテーブルには、ユーザID毎にバイオ認証データと、操作年月日と、操作の種類と、結果が記憶されている。このバイオ認証ログデータテーブル39を参照して、照合結果がOKであった場合の認証データを用いるものである。
【0051】
図25は第8のデータの流れ説明図である。図において、39がバイオ認証ログデータテーブルで、データベース30内に設けられている。
1)ユーザ1が、認証サーバプログラム60に照会要求を行なう。
2)認証サーバプログラム60は、バイオ認証ログデータテーブル39を検索し、前回一致したユーザ1のバイオ認証種類情報を取得する。
3)認証サーバプログラム60は、バイオデータNと照合を行なう。
4)照合結果をクライアント20に通知する。
【0052】
この実施の形態例によれば、複数種類のバイオデータによる組み合わせの認証の場合、照合における検索時間を短縮することができる。
次の実施の形態例は、クライアントからサーバに照合要求をする場合に、バイオデータに加えてバイオ読取装置情報も一緒に転送するようにしたものである。図26は第9のデータの流れ説明図である。図において、70は読取装置情報データテーブルであり、読取装置毎に対応するバイオデータを記憶しておくものである。
1)バイオデータを読み取る際、バイオ読み取り装置情報も読み取り、認証サーバプログラム60に照合要求を行なう。
2)サーバ10は、読み取り装置情報データテーブル70を参照して、読み取られたバイオデータを判断し、認証サーバプログラム60にバイオ認証種類データを返す。
3)2)より返された情報を基に、認証データと測定したバイオデータとの照合を行なう。
4)照合結果は、クライアント20に通知される。
【0053】
この実施の形態例によれば、照合における検索時間を短縮できるため、マルチバイオシステムにおける照合において、バイオ読み取り装置検索の効率化並びに照合の効率化を行なうことができる。
【0054】
次の実施の形態例について説明する。この実施の形態例は、本来サーバ側で保持している認証データを、クライアント側に転送し、クライアント側で認証データを保持するようにして、クライアントのみでデータの照合を行なうことができるようにしたものである。
【0055】
図27は、第10のデータの流れ説明図である。この実施の形態例では、クライアント20側に記憶装置80を設け、この記憶装置にデータベース30からのバイオデータを日付データと共に記憶させるようにしたものである。
1)クライアント20は、バイオデータ1で照合要求をする。
2)サーバ10側の照合結果がクライアント20側に通知される。
3)認証サーバ10は、サーバの日付データとクライアント側の日付データとを比較する。
4)サーバ10上の日付データがクライアント20側の日付データより新しい場合、クライアント20に照合要求ユーザのバイオデータをダウンロード(キャッシュ)する。同一の場合には、ダウンロードしない。
【0056】
この実施の形態例によれば、認証サーバ及びネットワークにおける過大な負荷を軽減することができる。
このように、本発明によれば、いずれのクライアントであっても、そのクライアントが持つバイオデータの読み取り機能と同一種類の認証データが登録されていれば認証することができるデータ認証方法及びデータ認証装置を提供することができる。
【図面の簡単な説明】
【0057】
【図1】本発明の一実施の形態例を示すブロック図である。
【図2】本発明の第1の処理フローを示す図である。
【図3】第1のデータの流れ説明図である。
【図4】本発明の第1の処理説明図である。
【図5】本発明の第2の処理フローを示す図である。
【図6】本発明の第3の処理フローを示す図である。
【図7】アプリケーション情報テーブルの構成例を示す図である。
【図8】アプリケーションで保持する認証種類の組み合わせ情報を示す図である。
【図9】第2のデータの流れ説明図である。
【図10】一連認証の処理フローを示す図である。
【図11】個別認証チャートの処理フローを示す図である。
【図12】クライアント情報テーブルの構成例を示す図である。
【図13】第3のデータの流れ説明図である。
【図14】第4のデータの流れ説明図である。
【図15】バイオ認証データ登録テーブルの構成例を示す図である。
【図16】バイオ認証ユーザ情報テーブルの構成例を示す図である。
【図17】第5のデータの流れ説明図である。
【図18】第6のデータの流れ説明図である。
【図19】バイオ認証ユーザ照合順序テーブルの構成例を示す図である。
【図20】第7のデータの流れ説明図である。
【図21】認証画面例を示す図である。
【図22】システムログインへの組み込みの説明図である。
【図23】照合処理の動作を示すフローチャートである。
【図24】バイオ認証ログデータテーブルの構成例を示す図である。
【図25】第8のデータの流れ説明図である。
【図26】第9のデータの流れ説明図である。
【図27】第10のデータの流れ説明図である。
【図28】本発明の他の実施の形態例を示すブロック図である。
【符号の説明】
【0058】
20 クライアント
22 バイオセンサードライバ
23 バイオデータ照合部
24 バイオデータ変換部
25 バイオセンサードライバ
26 プログラム制御部
40 アプリケーション
41 バイオ認証データ登録テーブル
42 ユーザテーブル
50 データベース
【技術分野】
【0001】
本発明はデータ認証装置に関し、更に詳しくはバイオ認証データに基づいてユーザを認証するようにしたバイオ認証装置に関する。
【背景技術】
【0002】
従来の複数種類のバイオデータによる認証を行なうシステムにおいては、ユーザとクライアントの対応が一義的に決められている。このため、複数種類のバイオデータによる認証が可能であっても、予めユーザに認証時のバイオデータの種類が決められていた。
【0003】
従来のこの種の技術としては、指紋、顔相などの身体的特徴のライブパターンを読取装置により読み取ったライブパターンデータと、記録している特徴の基準パターンデータとを照合する照合手段と、照合手段の前又は後において、完全一致またはタイムスタンプの一致または履歴との一致によりライブパターンが不正なデータであるか否かを判断するシステムが知られている(例えば特許文献1参照)。また、生体情報を利用して個人認証する生体認証システムに関し、生体情報検出時の不安定さがあっても、照合精度の低下を防止するシステムが知られている(例えば特許文献2参照)
【特許文献1】特開2003−308302号公報
【特許文献2】特開2006−6753号公報
【発明の開示】
【発明が解決しようとする課題】
【0004】
従来システムでは、認証のために設定された以外の種類のバイオデータ読み取り手段では認証データが登録されていても認証ができなかった。このため、設定された種類以外のバイオデータの読み取り手段しか持たないクライアントでは、認証が行えないという問題があった。
【0005】
本発明はこのような課題に鑑みてなされたものであって、いずれのクライアントであっても、そのクライアントが持つバイオデータの読み取り機能と同一種類の認証データが登録されていれば認証することができるデータ認証装置を提供することを目的としている。
【課題を解決するための手段】
【0006】
(1)請求項1記載の発明は、クライアントから登録された認証データを保持するサーバと、そのサーバにネットワークで接続しているクライアントで構成されるシステムにおいて、クライアントは認証のためのデータ読み取り手段を有し、予め設定された認証のタイミングにおいて、認証データ入力手段から入力された認証データを認証サーバに転送し、クライアントから送信されてきた認証データと照合し、その結果をクライアントに送信するシステムにおいて、1度サーバで認証し本人と同一と判断した場合、サーバに登録されている認証データをクライアントに送信し、クライアントではそのデータを保持し、それ以降の認証時はクライアントで保持した認証データと入力した認証データを比較するようにしたことを特徴とする。
【発明の効果】
【0007】
(1)請求項1記載の発明によれば、認証サーバ及びネットワークにおける過大な負荷を軽減することができる。
【発明を実施するための最良の形態】
【0008】
以下、図面を参照して本発明の実施の形態例を詳細に説明する。
図1は本発明の一実施の形態例を示すブロック図である。この実施の形態例は、クライアント20側にデータベースを設けることにより、サーバの必要なくデータ照合が行なえるようにしたものである。図において、22はバイオセンサードライバ、23はバイオデータ照合部、24はバイオデータ変換部、26はプログラム制御部、40はアプリケーション、50はデータベースである。データベース50には、バイオ認証データ登録テーブル41と、ユーザテーブル42が含まれている。
【0009】
このように構成されたシステムにおける動作を図2を用いて説明する。図2は本発明の第1の処理フローを示す図である。先ず、アプリケーション40から照合要求を行なう(S1)。この結果、プログラム制御部26が起動される(S2)。各バイオセンサー(バイオ読取装置)は、バイオセンサードライバ22で駆動され、バイオデータを出力する(S3)。
【0010】
バイオデータ変換部24は、バイオデータを受けて、特徴部分を抽出する処理を行なう(S4)。次に、バイオデータ照合部23は、バイオセンサーで測定されたバイオデータと、バイオ認証データ登録テーブル41に記憶されている認証データを読み出し、認証データとの照合を行なう(S5)。次に、照合結果の判定を行なう(S6)。次に、プログラム制御部26が動作し(S7)、アプリケーション40を通じて結果を通知する(S8)。
【0011】
図3は第1のデータの流れ説明図である。図において、10はサーバ、30は該サーバ10と接続されたデータベースである。該データベース30には、認証用データが#1〜#NまでN個設けられており、それぞれの認証用データには、ユーザ用認証データがユーザ毎に設けられている。20’は複数のバイオ読取装置(バイオセンサー)付きのクライアントであり、#1〜#NまでのN個の読取装置が取り付けられている。20は単機能の読取機能が設けられたクライアントであり、単機能の読取装置付クライアントである。60は、認証データを用いてユーザの認証を行なう認証サーバプログラムであり、サーバ10内に設けられている(以下同じ)。以下の動作は、この認証サーバプログラム60が主体となって行なうものである。
1)複数のバイオ読取装置付クライアント20’からN種類のバイオデータを読み込む。ここで、ユーザが複数いる場合には、ユーザ毎にN種類のバイオデータを読み込むことになる。その結果、データベース30に示すように、それぞれの認証用データがユーザ毎に求まり、データベース30に記憶されることになる。
2)ここで、任意のクライアント20からサーバ10に対して認証要求を行なう。この場合において、データベース30には、ユーザ毎に複数の種類の認証データが記憶されているため、どのクライアントからも認証要求を行なうことが可能になる。
3)認証サーバプログラム60は、クライアント20から送られてきたデータと対応する認証用データとの照合を行なう。この場合において、認証用データは、ユーザ毎に記憶されているので、認証にあたっては、どのユーザであるのかを示すユーザIDの入力が必要となる。
4)認証サーバプログラム60は、各クライアント20に対して照合結果を送信する。
【0012】
この実施の形態例によれば、サーバ10は必要に応じてバイオデータと認証データとの照合を行ない、その結果をクライアント20に通知することができる。
図4は本発明の第1の処理説明図である。この実施の形態例は、重要度に応じて照合結果の論理条件をとって最終の認証を決定するものである。例えば、図に示すように、重要度が小さい場合には、N個のバイオデータの内の何れか一つが照合すれば、認証OKと判定する。つまり、この場合には、各認証結果のオアをとるものである。このような場合としては、例えばWindows(マイクロソフト社の登録商標)ログオンのように、単にWindowsにアクセスするだけである場合には、(指紋一致)OR(声紋致一致)OR(顔形一致)という具合に一つでも照合するものがあれば、認証OKとする。
【0013】
これに対して重要度が大きくなれば(例えばワークフロー業務の決済)、照合がOKとなる条件をきつくする。即ち、N個のバイオデータの全てが照合した時に認証OKとするものである。具体的には、(指紋一致)AND(声紋一致)AND(顔形一致)という具合に全てが照合した場合に、認証OKとする。
【0014】
図5は本発明の第2の処理フローを示す図である。先ず、重要度が小さい場合の動作について説明する。この場合には、先ず第1の認証を要求する(S1)。これにより、第1の認証を開始する(S2)。認証がOKの場合には、即本人と判断する(S3)。認証がNGの場合には、ステップS1に戻り、次の認証データの認証要求を行なう処理に入る。全ての認証がNGの場合、又は認証がキャンセルされた場合には、他人と判断する(S4)。
【0015】
次に、重要度が一番大きい場合の動作について説明する。先ず、第1の認証要求をし(S10)、第1の認証を開始する(S11)。認証がOKの場合には、第2の認証要求をする(S12)。そして、第2の認証を開始する(S13)。この認証がOKの場合には、第3の認証要求をする。以上のような処理を第Nの認証まで行なう。即ち、第Nの認証要求を行ない(S14)、第Nの認証を開始する(S15)。そして、第Nの認証の結果OKの場合には本人と判断する(S16)。ここで、ステップS15において、第Nの認証がOKであったということは第1〜第Nまでの全ての認証がOKであったことを示している。以上の処理において、認証がNGの場合には、ステップS10に戻り最初から認証をやりなおす。それぞれの認証工程において認証がキャンセルされた場合には、他人と判断する(S17)。
【0016】
この実施の形態例によれば、複数のバイオ認証を組み合わせて、用途に応じて認証度の高低を設定することができる。また、高額な決済処理を行なう電子稟議やインターネットにおける高額商品を取り扱うシステムにおいては厳密な本人認証を行なうことができる。
【0017】
次に、認証種類の組み合わせ情報を用いた認証方法について説明する。認証種類の組み合わせは、サーバ側にもクライアント側にも持つことができる。
図6は本発明の第3の処理フローを示す図である。システムとしては、図28を用いる。図28は本発明の他の実施の形態例を示すブロック図である。図1に示す実施の形態例と比較して、サーバ10とクライアント20が接続されている点が異なる。サーバ10は通信手段11を介してクライアント20の通信手段21と接続されている。サーバ10側にもバイオデータ照合部12が設けられている。13はプログラム制御部、30はデータベースである。該データベース30には、バイオ認証データ登録テーブル31と、ユーザテーブル32が設けられている。クライアント20側において、25はデータを記憶する記憶部で、25aはサーバ10からのデータを一時記憶するキャッシュメモリである。
【0018】
アプリケーション40から照合要求があると(S1)、制御がプログラム制御部26に移行する(S2)。次に、認証バイオの決定又は認証要求回数の決定が行われる(S3)。次に、どのようなバイオセンサーが設けられているか、バイオセンサーの検索を行なう(S4)。
【0019】
バイオセンサーが設けられている場合、使用するバイオセンサーを決定する(S5)。バイオセンサーが決定したら、バイオセンサードライバでバイオデータを測定する(S6)。そして、バイオデータを読み込む(S7)。読み込んだバイオデータに対して、バイオデータ変換部24で特徴部分を抽出するバイオデータ変換を行なう(S8)。次に、読み込んだバイオデータとデータベースに記憶されている認証データとの照合を行なう(S9)。
【0020】
次に、照合結果の判定を行なう(S10)。そして、照合結果が判定されたら、プログラム制御部26に制御を移し(S11)、アプリケーション40を通して結果を通知する(S12)。ステップS4でバイオセンサーが検索できない場合、プログラム制御部26に制御を渡す(S13)。そして、アプリケーション40を通して結果を通知する(S14)。
【0021】
図7は、認証種類の組み合わせ情報をサーバ側に持たせた場合のアプリケーション情報テーブルの構成例を示す図である。図に示すように、アプリケーション名毎に、バイオ認証データが記憶されている。例えば、アプリケーション1におけるバイオ認証データ1においては、バイオ認証データはバイオ#1データである。
【0022】
図8は、認証種類の組み合わせ情報をアプリケーション側で持つ場合の、アプリケーションで保持する認証種類の組み合わせ情報を示す図である。
図9は第2のデータの流れ説明図である。図3と同一のものは、同一の符号を付して示す。図において、33aは図7に示すアプリケーション情報テーブルである。
1)設定クライアント20よりアプリケーションとバイオ認証との設定情報をアプリケーション情報テーブル33に登録する。なお、アプリケーション情報テーブル33aは、複数のバイオデータを設定可能である。例えば、バイオ1+バイオ2等。
2)ユーザはアプリケーション1を通して認証の要求を行なう。
3)アプリケーション1又はNからアプリケーション情報テーブル33aへ、アプリケーションとバイオの関連情報を登録する。
4)アプリケーション1へアプリケーションとバイオの関連情報を返す。
5)アプリケーション1からバイオ1の認証を返す。
【0023】
後は、読み取られたバイオデータをバイオ認証サーバ10へ送り、照合する。図10は一連認証の処理フローを示す図で、クライアント側の動作を示している。認証の要求を行なうと(S1)、バイオデータの読み取りを行ない、認証手段を決定する(S2)。次に、第1の認証要求を行なうと(S3)、第1の認証が開始される(S4)。そして以下の処理を順次繰り返していく。そして、認証の要求を行ない(S5)、バイオデータの読み取りを行ない、認証手段を決定する(S6)。そして、第Nの認証要求を行ない(S7)、第Nの認証を開始する(S8)。そして、認証がOKの場合、本人と判断する(S9)。
【0024】
ここで、ステップS4において第1の認証がNGの場合、再度認証するかどうかチェックする(S10)。再度認証する場合には、ステップS1に戻り、認証しない場合には、他人と判断する(S11)。ステップS12の場合も、再度認証するかどうかチェックし(S12)、認証する場合にはステップS1に戻り、認証しない場合には他人と判断する(S13)。ここで、それぞれの認証開始時に認証がキャンセルされた場合には、他人と
判断して(S14)、処理を終了する。
【0025】
この実施の形態例によれば、複数マルチバイオを呼び出す仕組みを予め設定しておくことで、プログラムの汎用性を確保することができる。サーバ管理は、本人のバイオ情報品質や運用に合わせて認証種類を固定にできる場合に有効で、認証種類の組み合わせ情報を一元管理可能とすることができる。また、アプリケーション側管理は、要求セキュリティ強度に合わせて個別調整が可能である。
【0026】
図11は個別認証チャートの処理フローを示す図で、クライアント側の動作を示している。この処理フローは、図9に示すシステムで、個別認証チャートで認証を行なうようにしたものである。先ず、認証の要求を行なうと(S1)、バイオデータの読み取りを行ない、認証手段を決定する(S2)。次に、第1の認証要求を行なう(S3)。そして、第1の認証を開始する(S4)。第1の認証がOKであった場合には、次に進む。
【0027】
ステップS4において、認証がNGの場合には、再度認証するかどうかをチェックする(S5)。再度認証する場合には、ステップS1に戻って認証要求からやり直す。再度認証をしない場合には、他人と判断する(S6)。このようなシーケンスを認証手段の数だけ繰り返す。そして、その都度、認証がNGの時のステップS5とS6の処理を繰り返す。
【0028】
第1の認証がOKの場合、認証の要求を行なう(S7)。そして、バイオデータの読み取りを行ない、認証手段を決定する(S8)。そして、第Nの認証要求を行ない(S9)、第Nの認証を開始する(S10)。第Nの認証結果がOKの場合には、本人と判断する(S11)。認証結果がNGの場合には、再度認証するかどうかチェックする(S13)。再度認証する場合には、ステップS7に戻って認証要求からやり直す。再度認証しない場合には、他人と判断する(S14)。なお、認証でキャンセルする場合には、何れも他人と判断される(S12)。この実施の形態例におけるデータの流れ説明図(第3のデータの流れ説明図)は、図9に示す第2のデータの流れ説明図と同じである。
【0029】
この実施の形態例によれば、本人のバイオ情報品質や運用に合わせて認証種類を固定にできる場合に有効で、認証種類の組み合わせ情報を一元管理可能とすることができる。また、アプリケーション側管理は、要求セキュリティ強度に合わせて個別調整が可能となる。
【0030】
次に、次の実施の形態例について説明する。以下の実施の形態例は、クライアント毎に検出する手段を決めておき、クライアント毎に検出手段を1種類のみとし、認証時間を固定にすることで、クライアント側からの不正アクセス防止を行ない、認証時間を短縮するようにしたものである。
【0031】
図12はこの実施の形態例で用いるクライアント情報テーブルの構成例を示す図である。クライアント毎に、認証できる種類が固定されている。例えば、バイオ認証データ1の場合、クライアント1で認証できるのはバイオ#1データのみである。
【0032】
図13は第3のデータの流れ説明図である。
1)設定クライアント20よりクライアントとバイオ認証との設定情報をクライアント情報テーブル34に登録する。ここで、クライアント情報テーブル34は、複数のバイオデータを設定可能である。例えば、バイオ1+バイオ2等。
2)ユーザは、アプリケーション1を通して認証の要求を行なう。
3)アプリケーション1又はNからクライアント情報テーブル34へクライアントとバイオの関連情報を取得する。
4)アプリケーション1へクライアントとバイオの関連情報を返す。
5)アプリケーション1からバイオ1の認証を返す。
【0033】
後は、読み取られたバイオデータをバイオ認証サーバ10へ送り、照合する。
この実施の形態例によれば、認証手段を固定にすることで、クライアントからの不正アクセス防止を行なうことができる。また、遠隔地又は通信速度が遅い場所等、アクセス時間がかかる場合の認証時間を短縮することができる。
【0034】
図14は第4のデータの流れ説明図である。この実施の形態例は、個別認証チャートにより認証するようにしたものである。図13と同一のものは、同一の符号を付して示す。1)設定クライアント20よりクライアントとバイオ認証との設定情報をクライアント情報テーブル34に登録する。クライアント情報テーブル34は、複数のバイオデータを設定可能である。例えば、バイオ1+バイオ2等。
2)ユーザはアプリケーション1を通して認証の要求を行なう。
3)アプリケーション1又はNからクライアント情報テーブル34へクライアントとバイオとの関連情報を取得する。
4)アプリケーション1へクライアントとバイオとの関連情報を返す。
5)アプリケーション1からバイオ1の認証を返す。
【0035】
後は、読み取られたバイオデータをバイオ認証サーバへ送り、照合する。
この実施の形態例によれば、認証手段を固定にすることで、クライアントからの不正アクセス防止を行なうことができる。
【0036】
次に、データ照合時の認識率に認証精度を設けるようにした場合について説明する。図15はバイオ認証データ登録テーブルの構成例を示す図である。このテーブルでは、バイオデータ毎に、認証率(認証精度)を変えている。図19はバイオ認証ユーザ情報テーブルの構成例を示す図である。このテーブルは、ユーザ毎に該当するバイオの認証精度を設けるようにしたものである。例えば、ユーザIDが1の場合のバイオ#1の認証データの認証精度は70%、バイオ#Nの認証データの認証精度は85%にそれぞれ設定してある。ここで、バイオ認証データ登録テーブルを35、バイオ認証ユーザ情報テーブルを36とする。これらテーブルは、サーバ10側のデータベース30側に設けられる。或いは、各クライアント側に設けるようにしてもよい。
【0037】
図17は、第5のデータの流れ説明図である。37は照合時の認証精度を記憶しておく認証精度ログである。
1)設定クライアント20より、それぞれのバイオデータに関する認証データを定義する。
2)それぞれのクライアントからID単位で照合要求を行なう。
3)照合結果を判定し、サーバ10で定義されている認証データと比較を行なう。
その際、認証精度を認証データに対応して記憶する。この場合において、照合時の認証精度の求め方は以下の通りである。即ち、照合時の認証データの一致数をA、認証数をBとして、100A/B(%)で求める。このようにして求めた認証精度は、認証精度ログ37に記憶しておく。
4)クライアント20に、認証結果と共に、認証データを送信する。
5)次回照合要求時、バイオ認証サーバ10から認証精度ログを読み出し、予め決められた認証精度を保持していない場合、認証要求クライアント20に対して、認証データ更新要求又は使用不可通知を行なう。
【0038】
この実施の形態例によれば、生体の経年変化による認証データの精度の低下による誤認識を防止することができる。
図18は、第6のデータの流れ説明図である。ユーザ1が設定クライアント20からサーバ10にアクセスする場合の動作を示している。
1)ユーザ1がバイオ1データを持って、登録要求を行なう。
2)認証サーバプログラム60は、ユーザ1におけるバイオ1データで照合を行なう。この場合、最初のバイオデータの照合にはシステム管理者が立ち会う。
3)認証サーバプログラム60から、クライアント20に向けて照合結果が返される。
4)認証された場合、バイオデータNへの登録許可が与えられ、ユーザ1のバイオデータNをデータベース30に登録する。認証されなかった場合、ユーザ1へのバイオNデータは登録できない。
【0039】
この実施の形態例によれば、マルチバイオシステムにおいて、2個目以降のバイオデータを登録する際、システム管理者を必要とせずにバイオデータの登録を行なうため、登録の煩雑さを避けることができる。
【0040】
次の実施の形態例は、照合時にユーザにバイオデータの種類を選択をしなくてもすむようにしたものである。このために、図19に示すようなバイオ認証ユーザ照合順序テーブルを用いる。このテーブルでは、ユーザID毎に、照合順序が決められている。例えば、ユーザ1の場合、第1番目にバイオデータ1を用いた照合を行ない、次にバイオデータ2を用いた照合を行なう。最後に、バイオデータNを用いた照合を行なう。ユーザ2の場合には、第1番目にバイオデータ2を用いた照合を行ない、第2番目にバイオデータ4を用いた照合を行ない、最後にバイオデータ1を用いた照合を行なう。
【0041】
図20は第7のデータの流れ説明図である。図において、38は前述したバイオ認証ユーザ照合順序テーブルであり、データベース30内に設けられている。
1)バイオデータの登録を行なう際、ユーザID毎に照合するバイオデータの順序を定義する。
2)クライアント20より照合要求を行なう。
3)認証サーバプログラム60が、送られてきたユーザIDを基に照合順序テーブル38よりマルチバイオの照合順序を決定し3)−1)、クライアント20側に返す3)−2)。
4)クライアント20は、照合順序に従い、クライアント20にあるバイオセンサーを検索し、バイオデータを読み込み、照合要求を行なう。
5)サーバ10側では、送られてきたバイオデータの照合を行ない、照合結果をクライアント20に通知する。
【0042】
この実施の形態例によれば、マルチバイオ装置を扱うシステムにおいて、照合するバイオ認識装置を選択する手間が省ける。また、マルチバイオ装置を扱うシステムにおいて、照合する順序を一度設定すれば、全てのクライアントで同じ設定を共有できる。更に、マルチバイオ装置を扱うシステムにおいて、照合する順序のプライオリティを設定することができる。
【0043】
次の実施の形態例について説明する。上述した照合方法は1:1照合という。即ち、ユーザIDを入力後、そのユーザIDを基に登録されているバイオデータと照合し、そのIDの本人性を確かめる照合方法である。
【0044】
これに対して、1:N照合とは、照合要求のあったバイオデータと、登録されているバイオデータ全てを照合し、そのバイオデータから本人を特定する照合方法である(バイオデータのみで本人を特定するもの)。
【0045】
図21は、認証画面例を示す図である。ユーザ名を入力する部分(ユーザIDフィール
ド)があり、認証ボタン、キャンセルボタン、終了ボタン等が設けられている。先の1:1照合の場合には、ユーザIDフィールドにユーザIDを入れる必要がある。図22は、システムログインへの組み込みの説明図である。ユーザIDフィールドにユーザIDを書き込むことにより、ログインする。
【0046】
図23は照合処理の動作を示すフローチャートである。システムとしては、図1を用いる。先ず、アプリケーション40より認証の要求を行なう(S1)。この結果、制御がプログラム制御部26に移る。クライアント20は、バイオデータの読み取りを行なう(S3)。次に、クライアント20はIDが入力されているかどうか判断する(S4)。
【0047】
IDが入力されている場合、サーバ10はIDを基に事前に登録されているバイオデータを検索する(S5)。そして、読み取ったバイオデータとステップS5で検索された登録されているバイオデータと照合を行なう(S6)。次に、照合結果の判定を行なう(S7)。そして、照合結果を要求アプリケーション40へ返す(S8)。
【0048】
ステップS4において、IDが入力されていない場合、IDが特定できない。そこで、事前に登録されている全てのバイオデータとステップS3で読み取ったバイオデータの照合を行ない(S9)、ステップS7に進む(1:N照合)。
【0049】
この実施の形態例によれば、照合における検索時間を短縮できるため、マルチバイオシステムにおける照合において、バイオ読み取り装置検索の効率化並びに照合の効率化を行なうことができる。
【0050】
また、ユーザIDが通知されない場合には、事前に登録されている全てのバイオデータとの照合を行なうことにより、ユーザIDがない時にも、本人を特定することができる。
次の実施の形態例は、前回一致したバイオデータの種類の登録データから照合を行なうようにしたものである。前回の照合履歴を見るために、図24に示すようなバイオ認証ログデータテーブル39が用いられる。このテーブルには、ユーザID毎にバイオ認証データと、操作年月日と、操作の種類と、結果が記憶されている。このバイオ認証ログデータテーブル39を参照して、照合結果がOKであった場合の認証データを用いるものである。
【0051】
図25は第8のデータの流れ説明図である。図において、39がバイオ認証ログデータテーブルで、データベース30内に設けられている。
1)ユーザ1が、認証サーバプログラム60に照会要求を行なう。
2)認証サーバプログラム60は、バイオ認証ログデータテーブル39を検索し、前回一致したユーザ1のバイオ認証種類情報を取得する。
3)認証サーバプログラム60は、バイオデータNと照合を行なう。
4)照合結果をクライアント20に通知する。
【0052】
この実施の形態例によれば、複数種類のバイオデータによる組み合わせの認証の場合、照合における検索時間を短縮することができる。
次の実施の形態例は、クライアントからサーバに照合要求をする場合に、バイオデータに加えてバイオ読取装置情報も一緒に転送するようにしたものである。図26は第9のデータの流れ説明図である。図において、70は読取装置情報データテーブルであり、読取装置毎に対応するバイオデータを記憶しておくものである。
1)バイオデータを読み取る際、バイオ読み取り装置情報も読み取り、認証サーバプログラム60に照合要求を行なう。
2)サーバ10は、読み取り装置情報データテーブル70を参照して、読み取られたバイオデータを判断し、認証サーバプログラム60にバイオ認証種類データを返す。
3)2)より返された情報を基に、認証データと測定したバイオデータとの照合を行なう。
4)照合結果は、クライアント20に通知される。
【0053】
この実施の形態例によれば、照合における検索時間を短縮できるため、マルチバイオシステムにおける照合において、バイオ読み取り装置検索の効率化並びに照合の効率化を行なうことができる。
【0054】
次の実施の形態例について説明する。この実施の形態例は、本来サーバ側で保持している認証データを、クライアント側に転送し、クライアント側で認証データを保持するようにして、クライアントのみでデータの照合を行なうことができるようにしたものである。
【0055】
図27は、第10のデータの流れ説明図である。この実施の形態例では、クライアント20側に記憶装置80を設け、この記憶装置にデータベース30からのバイオデータを日付データと共に記憶させるようにしたものである。
1)クライアント20は、バイオデータ1で照合要求をする。
2)サーバ10側の照合結果がクライアント20側に通知される。
3)認証サーバ10は、サーバの日付データとクライアント側の日付データとを比較する。
4)サーバ10上の日付データがクライアント20側の日付データより新しい場合、クライアント20に照合要求ユーザのバイオデータをダウンロード(キャッシュ)する。同一の場合には、ダウンロードしない。
【0056】
この実施の形態例によれば、認証サーバ及びネットワークにおける過大な負荷を軽減することができる。
このように、本発明によれば、いずれのクライアントであっても、そのクライアントが持つバイオデータの読み取り機能と同一種類の認証データが登録されていれば認証することができるデータ認証方法及びデータ認証装置を提供することができる。
【図面の簡単な説明】
【0057】
【図1】本発明の一実施の形態例を示すブロック図である。
【図2】本発明の第1の処理フローを示す図である。
【図3】第1のデータの流れ説明図である。
【図4】本発明の第1の処理説明図である。
【図5】本発明の第2の処理フローを示す図である。
【図6】本発明の第3の処理フローを示す図である。
【図7】アプリケーション情報テーブルの構成例を示す図である。
【図8】アプリケーションで保持する認証種類の組み合わせ情報を示す図である。
【図9】第2のデータの流れ説明図である。
【図10】一連認証の処理フローを示す図である。
【図11】個別認証チャートの処理フローを示す図である。
【図12】クライアント情報テーブルの構成例を示す図である。
【図13】第3のデータの流れ説明図である。
【図14】第4のデータの流れ説明図である。
【図15】バイオ認証データ登録テーブルの構成例を示す図である。
【図16】バイオ認証ユーザ情報テーブルの構成例を示す図である。
【図17】第5のデータの流れ説明図である。
【図18】第6のデータの流れ説明図である。
【図19】バイオ認証ユーザ照合順序テーブルの構成例を示す図である。
【図20】第7のデータの流れ説明図である。
【図21】認証画面例を示す図である。
【図22】システムログインへの組み込みの説明図である。
【図23】照合処理の動作を示すフローチャートである。
【図24】バイオ認証ログデータテーブルの構成例を示す図である。
【図25】第8のデータの流れ説明図である。
【図26】第9のデータの流れ説明図である。
【図27】第10のデータの流れ説明図である。
【図28】本発明の他の実施の形態例を示すブロック図である。
【符号の説明】
【0058】
20 クライアント
22 バイオセンサードライバ
23 バイオデータ照合部
24 バイオデータ変換部
25 バイオセンサードライバ
26 プログラム制御部
40 アプリケーション
41 バイオ認証データ登録テーブル
42 ユーザテーブル
50 データベース
【特許請求の範囲】
【請求項1】
クライアントから登録された認証データを保持するサーバと、そのサーバにネットワークで接続しているクライアントで構成されるシステムにおいて、クライアントは認証のためのデータ読み取り手段を有し、予め設定された認証のタイミングにおいて、認証データ入力手段から入力された認証データを認証サーバに転送し、クライアントから送信されてきた認証データと照合し、その結果をクライアントに送信するシステムにおいて、
1度サーバで認証し本人と同一と判断した場合、サーバに登録されている認証データをクライアントに送信し、クライアントではそのデータを保持し、それ以降の認証時はクライアントで保持した認証データと入力した認証データを比較するようにしたことを特徴とするデータ認証装置。
【請求項1】
クライアントから登録された認証データを保持するサーバと、そのサーバにネットワークで接続しているクライアントで構成されるシステムにおいて、クライアントは認証のためのデータ読み取り手段を有し、予め設定された認証のタイミングにおいて、認証データ入力手段から入力された認証データを認証サーバに転送し、クライアントから送信されてきた認証データと照合し、その結果をクライアントに送信するシステムにおいて、
1度サーバで認証し本人と同一と判断した場合、サーバに登録されている認証データをクライアントに送信し、クライアントではそのデータを保持し、それ以降の認証時はクライアントで保持した認証データと入力した認証データを比較するようにしたことを特徴とするデータ認証装置。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【公開番号】特開2008−10016(P2008−10016A)
【公開日】平成20年1月17日(2008.1.17)
【国際特許分類】
【出願番号】特願2007−234389(P2007−234389)
【出願日】平成19年9月10日(2007.9.10)
【分割の表示】特願2006−67814(P2006−67814)の分割
【原出願日】平成13年7月30日(2001.7.30)
【出願人】(598057291)株式会社富士通エフサス (147)
【Fターム(参考)】
【公開日】平成20年1月17日(2008.1.17)
【国際特許分類】
【出願日】平成19年9月10日(2007.9.10)
【分割の表示】特願2006−67814(P2006−67814)の分割
【原出願日】平成13年7月30日(2001.7.30)
【出願人】(598057291)株式会社富士通エフサス (147)
【Fターム(参考)】
[ Back to top ]