JP2019133347A - 認証システムおよび認証方法 - Google Patents

Abstract

【課題】専用回線を介したアクセスをもとに本人認証を行うシステムにおいて、公衆回線を使用する環境からのアクセスに基づいて本人認証を行う。【解決手段】認証システムの中間サーバは、利用者の生体情報をコード化した登録用のコード化データと利用者の生体情報とを対応付けて予め格納している格納部を有する。また、中間サーバは、公衆回線を介してクライアント端末から利用者の生体情報をコード化した認証用のコード化データを含む認証依頼を受信すると、この認証用のコード化データと登録用のコード化データとを照合して利用者を特定する認証処理部を有する。また、中間サーバは、認証処理部による利用者の特定が成功すると、専用回線を介して、登録用のコード化データと対応付けられた生体情報を連携先システムへ送信し、利用者の認証を連携先システムに依頼する認証依頼部を有する。【選択図】図２

Description

本発明は、認証システムおよび認証方法に関する。

従来より、手のひら静脈の特徴量データ等の生体情報を用いて本人認証を行う認証システムがある。生体情報を用いる認証システムでは、認証対象の利用者の生体情報のみで本人認証を行うことができる利便性を有する一方、生体情報が利用者の生体部位に依存して自由に変更することができないことから、慎重に取扱われる。例えば特許文献１には、生体情報を暗号化して送受信する技術が開示されている。また、例えば特許文献２には、クライアント端末から符号化された静脈データ等のバイオメトリック情報を受信した照合装置が、このバイオメトリック情報をもとに利用者認証を行う技術が開示されている。

生体情報は慎重に扱う必要があるため、生体情報を用いて本人認証を行う認証システムは専用回線を使って構築されている。

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

しかしながら、上述の技術では、情報漏洩リスクの高い公衆回線を介した環境で認証システムを利用するためのセキュリティが万全ではない。すなわち、専用回線を介したアクセスをもとに本人認証を行う認証システムにおいて、公衆回線を使用する環境からのアクセスに基づいて本人認証を行うことができないという問題がある。

本願の開示技術は、上記に鑑みてなされたもので、例えば、専用回線を介したアクセスをもとに本人認証を行うシステムにおいて、公衆回線を使用する環境からのアクセスに基づいて本人認証を行う認証システムおよび認証方法を提供することを目的とする。

開示技術の一例では、認証システムは、端末と、中間サーバとを有する。前記端末は、利用者の生体情報をコード化した認証用のコード化データを生成する生成部と、公衆回線を介して、前記認証用のコード化データを前記中間サーバへ送信し、前記利用者の認証を前記中間サーバに依頼する第１の認証依頼部とを含む。前記中間サーバは、前記利用者の生体情報をコード化した登録用のコード化データと前記利用者の生体情報とを対応付けて予め格納している格納部と、前記公衆回線を介して、前記第１の認証依頼部から前記認証用のコード化データを受信すると、受信した前記認証用のコード化データと前記登録用のコード化データとを照合して前記利用者を特定する認証処理部とを含む。また、前記中間サーバは、前記認証処理部による前記利用者の特定が成功すると、専用回線を介して、前記登録用のコード化データと対応付けられた前記生体情報を連携先システムへ送信し、前記利用者の認証を前記連携先システムに依頼する第２の認証依頼部を含む。

開示技術の一例によれば、専用回線を介したアクセスをもとに本人認証を行うシステムにおいて、公衆回線を使用する環境からのアクセスに基づいて本人認証を行うことができる。

図１は、実施例にかかる認証システムの概要を説明するための図である。 図２は、実施例にかかる認証システムの構成を示す図である。 図３は、実施例にかかる管理情報テーブルの構成の一例を示す図である。 図４は、実施例にかかるコード化データ（登録用）テーブルの構成の一例を示す図である。 図５は、実施例にかかる連携データテーブルの構成の一例を示す図である。 図６は、実施例にかかる生体情報（登録用）テーブルの構成の一例を示す図である。 図７は、実施例にかかるコード化データ登録時の処理を示すフローチャートである。 図８は、実施例にかかるコード化データ認証時の処理を示すフローチャートである。 図９は、コンピュータのハードウェア構成の一例を示す図である。

以下に、本願の開示技術にかかる認証システムおよび認証方法の実施例を図面に基づいて詳細に説明する。以下の実施例によって、本願の開示技術が限定されるものではない。例えば、以下の実施例では、手のひら静脈の特徴データを生体データとして用いる場合を示すが、これに限られず、手のひら表皮データ（掌紋データ）、指紋データ、虹彩データ等、その他の生体データであっても、開示技術は適用可能である。以下の実施例および変形例の説明において、既出の構成要素および処理については、同一名称または同一符号を付与し、説明を省略する。また、以下の実施例および変形例は、矛盾しない範囲でその一部または全部を組合せて実施できる。

以下において、認証用データとは、認証依頼を行う際に都度生成される、生体部分の生体情報または生体情報に基づくデータである。また、登録用データとは、認証装置または認証システムにおいて予め登録されている、認証用データと照合される生体部分の生体情報または生体情報に基づくデータである。

（認証システムの概要）
図１は、実施例にかかる認証システムの概要を説明するための図である。実施例にかかる認証システムは、クライアント端末、中間サーバ、１以上の連携先システムを有する。クライアント端末と中間サーバとは、インターネット等の公衆回線で接続されている。中間サーバと連携先システムとは、一定のセキュリティが確保された専用回線でそれぞれ接続されている。

中間サーバは、公衆回線に接続されたクライアント端末から、生体情報で本人認証を行う連携先システムが使用できるよう、クライアント端末と連携先システムとの間に設置される。中間サーバは、事前登録された、コード化データ（登録用）と、生体情報を用いて本人認証を行うシステムと互換性がある生体情報（認証用）とを対応付けて保持している。

連携先システムは、例えば、本人認証を経て利用者のコンピュータにリモートアクセスを許可する閉域網を管理するシステムや、金融機関の決済システムやＡＴＭ（Automatic Teller Machine）等である。連携先システムは、事前準備された生体情報（登録用）を保持している。コード化データ（登録用）は、後述のコード化データ（認証用）と照合を行うための登録用データである。生体情報（登録用）は、コード化データ（認証用）とコード化データ（登録用）との照合により特定された利用者の生体情報（認証用）と照合を行うための登録用データである。

クライアント端末は、生体認証用デバイスを使用して利用者の生体情報を読み取り、読み取った生体情報からその特徴を特徴コードとして抽出し生成したコード化データ（認証用）を、公衆回線を介して中間サーバへ送信する。そして、中間サーバおよび連携先システムは、次の２段階認証を行う。

すなわち、中間サーバは、１段目認証として、受信したコード化データ（認証用）と事前に保持しているコード化データ（登録用）を用いた１：１認証または１：Ｎ認証により本人認証を実施し、１人の利用者を特定する。中間サーバは、コード化データ（認証用）を用いた本人認証が認証ＯＫとなると、中間サーバに事前に用意しておいた、特定した１人の利用者の生体情報（認証用）を抽出する。そして、中間サーバは、抽出した生体情報（認証用）を連携先システムへ専用回線を介して送信して利用者の認証依頼を行う。

連携先システムは、２段目認証として、受信した生体情報（認証用）と事前に保持している生体情報（登録用）を用いた１：１認証または１：Ｎ認証により、本人認証を行う。そして、連携先システムは、生体情報を用いた本人認証の認証結果を中間サーバへ専用回線を介して返却する。中間サーバは、連携先システムから受信した認証結果をクライアント端末へ公衆回線を介して転送する。

このように、中間サーバを、クライアント端末と連携先システムとの間に設ける。これにより、専用回線を介した直接的なアクセスに基づいて本人認証を行う連携先システムは、公衆回線を介したクライアント端末からの間接的なアクセスに基づいても本人認証を行うことができるようになる。

（実施例にかかる認証システムの構成）
図２は、実施例にかかる認証システムの構成を示す図である。実施例にかかる認証システム１は、中間サーバ１０、中間ＤＢ（Data Base）_２０、クライアント端末３０、連携先システムＡ_５０Ａ、連携先システムＢ５０Ｂ、連携先システムＣ_５０Ｃを有する。なお、クライアント端末および連携先システムの数は、図２の図示のように限られるものではない。また、図２では、中間サーバ１０と中間ＤＢ２０とは、別装置に実装される例を示すが、これに限られず、一つの装置に実装されてもよい。

中間サーバ１０は、インターネットや公衆無線ＬＡＮ（Local Area Network）等の公衆回線１００−１を介してクライアント端末３０と接続される。また、中間サーバ１０は、一定のセキュリティが確保された専用回線１００−２を介して連携先システムＡ_５０Ａ、連携先システムＢ_５０Ｂ、連携先システムＣ_５０Ｃそれぞれと接続される。なお、クライアント端末３０と連携先システムＡ_５０Ａ、連携先システムＢ_５０Ｂ、連携先システムＣ_５０Ｃとは、直接接続されず、中間サーバ１０を介在させて公衆回線１００−１と専用回線１００−２とを介して接続される。

中間サーバ１０は、プロセッサ等の処理装置を有するコンピュータである。中間サーバ１０は、登録処理部１１、認証処理部１２、認証依頼部１３を有する。また、中間サーバ１０は、公衆回線１００−１および専用回線１００−２の何れとも異なる専用回線１００−３を介して、中間ＤＢ２０が接続されている。中間ＤＢ２０は、中間サーバ１０が有するファイヤウォール等の機能により公衆回線１００−１から隔離され、公衆回線１００−１を介した不正アクセス等の脅威から保護される。

中間ＤＢ２０は、管理情報テーブル２１、コード化データ（登録用）テーブル２２、連携データテーブル２３、これらのテーブルに格納されているデータを管理するデータベース管理システム（ＤＢＭＳ：Data Base Management System、不図示）を有する。

（実施例にかかる管理情報テーブルの構成）
図３は、実施例にかかる管理情報テーブルの構成の一例を示す図である。実施例にかかる管理情報テーブル２１は、「管理ＩＤ」「氏名」「住所」「Tel」等の項目に関する情報を認証対象の利用者毎に管理するテーブルである。「Tel」は、連絡先電話番号である。「管理ＩＤ」に対応付けられた「氏名」「住所」「Tel」等の項目に関する情報を「管理情報」という。「管理ＩＤ」は、認証対象の利用者を一意に識別する情報である。「氏名」「住所」「Tel」等は、「管理ＩＤ」で識別される利用者の個人の属性情報である。図３では、例えば「管理ＩＤ」が“００００１”である利用者は、「氏名」が“Ｘ１”であり、「住所」が“Ｙ１”であり、「Tel」が“Ｚ１”である。

（実施例にかかるコード化データ（登録用）テーブルの構成）
図４は、実施例にかかるコード化データ（登録用）テーブルの構成の一例を示す図である。実施例にかかるコード化データ（登録用）テーブル２２は、「管理ＩＤ」「コード化データ（登録用）右手」「コード化データ（登録用）左手」等の項目に関する情報を認証対象の利用者毎に管理するテーブルである。「管理ＩＤ」に対応付けられた「コード化データ（登録用）右手」「コード化データ（登録用）左手」を「コード化データ（登録用）」という。図４では、「コード化データ（登録用）右手」および「コード化データ（登録用）左手」をＶ字状の記号で示している。「コード化データ（登録用）右手」は、「管理ＩＤ」で識別される利用者の右手の手のひらの特徴データ（生体情報）をコード化したコード化データ（登録用）である。「コード化データ（登録用）左手」は、「管理ＩＤ」で識別される利用者の左手の手のひらの特徴データ（生体情報）をコード化したコード化データ（登録用）である。

コード化データは、生体情報に対してハッシュ化などの技術を施して生成されたバイナリデータである。コード化データは、バイナリデータ化する際の変換条件を異ならせることにより異なるデータとなる。

図４は、例えば「管理ＩＤ」が“００００１”である利用者に対応付けて「コード化データ（登録用）右手」および「コード化データ（登録用）左手」の各コード化データ（登録用）が格納されていることを示す。なお、コード化データ（登録用）テーブル２２で「管理ＩＤ」で識別される利用者毎に管理されるコード化データ（登録用）は、「コード化データ（登録用）右手」および「コード化データ（登録用）左手」の両方に限られず、何れか一方であってもよい。

（実施例にかかる連携データテーブルの構成）
図５は、実施例にかかる連携データテーブルの構成の一例を示す図である。実施例にかかる連携データテーブル２３は、「管理ＩＤ」「生体情報（認証用）右手」「生体情報（認証用）左手」「連携先システムＡ」「連携先システムＢ」「連携先システムＣ」等の項目に関する情報を認証対象の利用者毎に管理するテーブルである。「管理ＩＤ」に対応付けられる「生体情報（認証用）右手」「生体情報（認証用）左手」「連携先システムＡ」「連携先システムＢ」「連携先システムＣ」を「連携データ」という。図５では、「生体情報（認証用）右手」および「生体情報（認証用）左手」をＶ字状の記号で示している。

「生体情報（認証用）右手」は、「管理ＩＤ」で識別される利用者の右手の手のひらの特徴データ（生体情報）の認証用データである。「生体情報（認証用）左手」は、「管理ＩＤ」で識別される利用者の左手の手のひらの特徴データ（生体情報）の認証用データである。

「連携先システムＡ」は、「管理ＩＤ」で識別される利用者が連携先システムとして連携先システムＡ_５０Ａが設定されている場合に、その旨を示す情報（図５では“○”で概念的に示す）が格納される。また、「連携先システムＡ」は、「管理ＩＤ」で識別される利用者が連携先システムとして連携先システムＡ_５０Ａが設定され、連携先システムＡ_５０Ａにおいて１：１認証が行われる場合、１：１認証に用いられるＩＤも併せて格納される。図５では、ＩＤの格納状態を“○＋ＩＤ”で概念的に示している。

図５は、例えば「管理ＩＤ」が“００００１”である利用者に対応付けて「生体情報（認証用）右手」、「生体情報（認証用）左手」の各コード化データ格納されていることを示す。また、図５は、「管理ＩＤ」が“００００１”である利用者に対応付けて、連携先システムＡ_５０Ａが設定されており、かつ、連携先システムＡ_５０Ａで行われる１：１認証で用いられるＩＤが格納されていることを示す。また、図５は、「管理ＩＤ」が“００００１”である利用者に対応付けて、連携先システムＣ_５０Ｃが設定されていることを示す。

図２の説明に戻る。クライアント端末３０は、表示装置（不図示）が接続された、公衆回線１００−１に接続可能な可搬型または据置型のコンピュータ、タブレット端末もしくはスマートフォンである。クライアント端末３０は、受付部３１、コード化データ（認証用）生成部３２、認証依頼部３３を有する。

また、受付部３１には、タップ入力もしくはフリック入力のためのタッチパネル、音声入力のためのマイク、キー入力のためのキーボード、クリック入力のためのマウス等を含む入力部４１が接続される。また、受付部３１には、かざされた利用者の生体部分を撮影する生体部分撮影部４２が接続される。

連携先システムＡ_５０Ａは、認証処理部５１Ａ、生体情報（登録用）ＤＢ５２Ａを有する。さらに、生体情報（登録用）ＤＢ５２Ａは、生体情報（登録用）テーブル５２Ａ−１を有する。同様に、連携先システムＢ_５０Ｂは、認証処理部５１Ｂ、生体情報（登録用）ＤＢ５２Ｂを有する。さらに、生体情報（登録用）ＤＢ５２Ｂは、生体情報（登録用）テーブル５２Ｂ−１を有する。また、同様に、連携先システムＣ_５０Ｃは、認証処理部５１Ｃ、生体情報（登録用）ＤＢ５２Ｃを有する。さらに、生体情報（登録用）ＤＢ５２Ｃは、生体情報（登録用）テーブル５２Ｃ−１を有する。生体情報（登録用）ＤＢ５２Ａ〜５２Ｃは、生体情報（登録用）テーブル５２Ａ−１〜５２Ｃ−１に格納されているデータを管理するデータベース管理システム（ＤＢＭＳ、不図示）をそれぞれ有する。

（実施例にかかる生体情報（登録用）テーブル）
図６は、実施例にかかる生体情報（登録用）テーブルの構成の一例を示す図である。生体情報（登録用）テーブル５２Ｂ−１、生体情報（登録用）テーブル５２Ｃ−１は、生体情報（登録用）テーブル５２Ａ−１と同様であるので、生体情報（登録用）テーブル５２Ａ−１を図示して説明する。生体情報（登録用）テーブル５２Ｂ−１、生体情報（登録用）テーブル５２Ｃ−１の図示は、省略する。

実施例にかかる生体情報（登録用）テーブル５２Ａ−１は、「管理ＩＤ」「生体情報（登録用）右手」「生体情報（登録用）左手」等の項目に関する情報を認証対象の利用者毎に管理するテーブルである。「生体情報（登録用）右手」は、「管理ＩＤ」で識別される利用者の右手の手のひらの特徴データ（生体情報）の登録用データである。「生体情報（登録用）左手」は、「管理ＩＤ」で識別される利用者の左手の手のひらの特徴データ（生体情報）の登録用データである。図６では、「生体情報（登録用）右手」および「生体情報（登録用）左手」をＶ字状の記号で示している。生体情報（登録用）テーブル５２Ａ−１に格納される「生体情報（登録用）右手」「生体情報（登録用）左手」は、中間ＤＢ２０の連携データテーブル２３に格納される「生体情報（認証用）右手」「生体情報（認証用）左手」とは別で生成されたデータである。

なお、生体情報（登録用）テーブル５２Ａ−１で「管理ＩＤ」で識別される利用者毎に管理される生体情報（登録用）は、「生体情報（登録用）右手」および「生体情報（登録用）左手」の両方に限られず、何れか一方であってもよい。生体情報（登録用）テーブル５２Ｂ−１〜５２Ｃ−１も、生体情報（登録用）テーブル５２Ａ−１と同様に、「管理ＩＤ」「生体情報（登録用）右手」「生体情報（登録用）左手」等の項目に関する情報を認証対象の利用者毎に管理するテーブルである。

（中間サーバ、クライアント端末、連携先システムの各部の動作）
以下、図７および図８を参照して、中間サーバ１０、クライアント端末３０、連携先システムＡ_５０Ａ〜連携先システムＣ_５０Ｃの各部の動作について説明する。

（実施例にかかるコード化データ登録時の処理）
図７は、実施例にかかるコード化データ登録時の処理を示すフローチャートである。実施例にかかるコード化データ登録時の処理は、中間サーバ１０の登録処理部１１により実行される。中間サーバ１０は、セキュアに接続されたコンソール端末（不図示）と連携して、このコンソール端末から実行開始の指示を受けると、実施例にかかるコード化データ登録時の処理を実行する。

先ず、ステップＳ１１では、登録処理部１１は、コンソール端末からコード化データ登録開始の指示を受けて、管理ＩＤを採番する。次に、ステップＳ１２では、登録処理部１１は、コンソール端末を介して管理情報の入力を受け付け、ステップＳ１１で採番した管理ＩＤおよび管理情報を対応付けて、中間ＤＢ２０のワーク記憶領域（不図示）へ一時格納する。

次に、ステップＳ１３では、登録処理部１１は、生体部分撮影装置（不図示）により撮影された生体部分に基づく生体情報のコード化データ（登録用）を、ステップＳ１１で採番した管理ＩＤと対応付けて中間ＤＢ２０のワーク記憶領域（不図示）へ一時格納する。登録処理部１１は、ステップＳ１３の１回の処理で、左右何れか一方の手の生体部分に基づく生体情報がコード化されたコード化データ（登録用）を登録する。登録処理部１１は、「コード化データ（登録用）右手」および「コード化データ（登録用）左手」それぞれについて、ステップＳ１３を実行する。

次に、ステップＳ１４では、登録処理部１１は、ステップＳ１３で中間ＤＢ２０のワーク記憶領域（不図示）へ一時格納した「コード化データ（登録用）右手」および「コード化データ（登録用）左手」を用いて、登録確認のための認証を行う。具体的には、登録処理部１１は、「コード化データ（登録用）右手」と、生体部分撮影装置（不図示）により撮影された生体部分に基づく右手の生体情報のコード化データ（確認用）とを照合し、両者が一致するか否かを確認する。また、登録処理部１１は、「コード化データ（登録用）左手」と、生体部分撮影装置（不図示）により撮影された生体部分に基づく左手の生体情報のコード化データ（確認用）とを照合し、両者が一致するか否かを確認する。

登録処理部１１は、ステップＳ１４の処理がＹｅｓ（確認認証ＯＫ）の場合、ステップＳ１５へ処理を移す。一方、登録処理部１１は、ステップＳ１４の処理がＮＯ（確認認証ＮＧ）の場合、ステップＳ１３を繰り返し、確認認証ＮＧとなったコード化データ（登録用）の再登録を行う。

ステップＳ１５では、登録処理部１１は、左右の手について、ステップＳ１３のコード化データ（登録用）の登録が完了した否かを判定する。登録処理部１１は、左右の手について、ステップＳ１３のコード化データ（登録用）の登録が完了した場合（ステップＳ１５：Ｙｅｓ）、ステップＳ１６へ処理を移す。一方、登録処理部１１は、左右の手について、ステップＳ１３のコード化データ（登録用）の登録が完了していない場合（ステップＳ１５：Ｎｏ）、ステップＳ１３へ処理を移す。そして、登録処理部１１は、登録が完了していない手についてステップＳ１３のコード化データ（登録用）の登録処理を行う。

ステップＳ１６では、登録処理部１１は、コンソール端末からの入力による連携先システム（本実施例では連携先システムＡ_５０Ａ〜連携先システムＣ_５０Ｃのうちの１つ）の選択を受け付ける。そして、ステップＳ１７では、登録処理部１１は、ステップＳ１６で選択した連携先システムにおける認証方法が１：１認証であるか否かを判定する。登録処理部１１は、ステップＳ１６で選択した連携先システムにおける認証方法が１：１認証である場合（ステップＳ１７：Ｙｅｓ）、ステップＳ１８へ処理を移す。一方、登録処理部１１は、ステップＳ１６で選択した連携先システムにおける認証方法が１：Ｎ認証である場合（ステップＳ１７：Ｎｏ）、ステップＳ１９へ処理を移す。

ステップＳ１８では、登録処理部１１は、ステップＳ１６で選択した連携先システムを連携先システムにおける１：１認証で用いるＩＤの入力を受け付ける。そして、登録処理部１１は、ステップＳ１６で選択した連携先システムを連携先システムとする旨の情報と、この連携先システムにおける１：１認証で用いるＩＤとを関連付けた連携データを、中間ＤＢ２０のワーク記憶領域（不図示）へ一時格納する。図５の「管理番号」“００００１”の「連携先システムＡ」“○＋ＩＤ”は、連携データの格納例を示す。ステップＳ１８が終了すると、登録処理部１１は、ステップＳ１９へ処理を移す。

ステップＳ１９では、登録処理部１１は、連携先システムの選択を完了したか否かを判定する。登録処理部１１は、連携先システムの選択を完了した場合（ステップＳ１９：Ｙｅｓ）、ステップＳ２０へ処理を移す。一方、登録処理部１１は、連携先システムの選択を完了していない場合（ステップＳ１９：Ｎｏ）、ステップＳ１６へ処理を移し、連携先システムの選択をさらに受け付ける。

ステップＳ２０では、登録処理部１１は、連携先システムチェックカウンタをリセット（初期化）する。連携先システムチェックカウンタは、後述のステップＳ２１で撮影した生体情報（認証用）を用いて連携先システムにおける認証チェックを行った際、各連携先システムにおける認証がＯＫとなった場合にカウントアップされる。連携先システムチェックカウンタは、連携データテーブル２３において設定されている全ての連携先システムにおける認証チェックがＯＫとなった場合、当該生体情報（認証用）の連携先システムチェックを正常完了とするためのカウンタである。ステップＳ２０が終了すると、登録処理部１１は、ステップＳ２１へ処理を移す。

次に、ステップＳ２１では、登録処理部１１は、コンソール端末に接続されている生体部分撮影装置により生体部分に基づく生体情報（認証用）を撮影する。登録処理部１１は、ステップＳ２１の１回の処理で、左右何れか１方の手の生体情報（認証用）を撮影する。

次に、ステップＳ２２では、登録処理部１１は、ステップＳ１６で選択した連携先システムを１つ選択し、この連携先システムへ、ステップＳ２１で撮影した生体情報（認証用）を送信して認証依頼する。なお、ステップＳ２２では、登録処理部１１は、認証依頼を行う連携先システムが１：１認証を行う場合、連携データテーブル２３の「連携先システムＡ」〜「連携先システムＣ」に格納されている“ＩＤ”も生体情報（認証用）と併せて連携先システムへ送信する。中間サーバ１０から生体情報（認証用）を受信した連携先システムは、受信した生体情報（認証用）をもとに利用者の認証処理を行い、認証結果を中間サーバ１０へ返却する。例えば、連携先システムＡ_５０Ａが中間サーバ１０から生体情報（認証用）を受信すると、認証処理部５１Ａは、生体情報（登録用）ＤＢ５２Ａの生体情報（登録用）テーブル５２Ａ−１を参照して利用者の１：Ｎ認証を行う。そして、認証処理部５１Ａは、認証結果を中間サーバ１０へ返却する。なお、例えば、連携先システムＡ_５０Ａが中間サーバ１０から生体情報（認証用）およびＩＤを受信した場合には、認証処理部５１Ａは、利用者の１：１認証を行い、認証結果を中間サーバ１０へ返却する。

次に、ステップＳ２３では、登録処理部１１は、ステップＳ２２で生体情報（認証用）を送信し認証依頼を行った連携先システムにおける認証結果がＯＫであるか否かを判定する。登録処理部１１は、ステップＳ２２で生体情報（認証用）を送信し認証依頼を行った連携先システムにおける認証結果がＯＫである場合（ステップＳ２３：Ｙｅｓ）、ステップＳ２４へ処理を移す。一方、登録処理部１１は、ステップＳ２２で生体情報（認証用）を送信し認証依頼を行った連携先システムにおける認証結果がＮＧである場合（ステップＳ２３：Ｎｏ）、ステップＳ２０へ処理を戻す。そして、登録処理部１１は、連携先システムチェックカウンタをリセット（初期化）し（ステップＳ２０）、生体情報（認証用）を再度撮影する（ステップＳ２１）。

ステップＳ２４では、登録処理部１１は、連携先システムチェックカウンタをカウントアップする。次に、ステップＳ２５では、登録処理部１１は、連携データテーブル２３において設定されている全ての連携先システムにおける認証チェックが完了したか否かを判定する。具体的には、ステップＳ２５では、登録処理部１１は、連携データテーブル２３においてステップＳ１１で採番された管理ＩＤに対応付けられて設定されている連携先システムの数と、連携先システムチェックカウンタの値とが一致するか否かを判定する。

登録処理部１１は、連携データテーブル２３においてステップＳ１１で採番された管理ＩＤに対応付けられて設定されている連携先システムの数と、連携先システムチェックカウンタの値とが一致する場合（ステップＳ２５：Ｙｅｓ）、ステップＳ２６へ処理を移す。一方、登録処理部１１は、連携データテーブル２３においてステップＳ１１で採番された管理ＩＤに対応付けられて設定されている連携先システムの数と、連携先システムチェックカウンタの値とが一致しない場合（ステップＳ２５：Ｎｏ）、ステップＳ２２へ処理を移す。そして、登録処理部１１は、未だ認証チェックがＯＫとなっていない連携先システムに対して生体情報を送信し、認証チェックを行う。

ステップＳ２６では、登録処理部１１は、左右の手について、ステップＳ２１の生体情報（認証用）の撮影が完了した否かを判定する。登録処理部１１は、左右の手について、ステップＳ２１の生体情報（認証用）の撮影が完了した場合（ステップＳ２６：Ｙｅｓ）、ステップＳ２７へ処理を移す。一方、登録処理部１１は、左右の手について、ステップＳ２１の生体情報（認証用）の撮影が完了していない場合（ステップＳ２６：Ｎｏ）、ステップＳ２０へ処理を移す。

ステップＳ２７では、登録処理部１１は、ステップＳ１２で中間ＤＢ２０のワーク記憶領域（不図示）へ一時格納した管理ＩＤおよび管理情報を、管理情報テーブル２１へ保存する。次に、ステップＳ２８では、登録処理部１１は、ステップＳ１３で中間ＤＢ２０のワーク記憶領域（不図示）へ一時格納した管理ＩＤおよびコード化データ（登録用）を、コード化データ（登録用）テーブル２２へ保存する。次に、ステップＳ２９では、登録処理部１１は、ステップＳ１８で中間ＤＢ２０のワーク記憶領域（不図示）へ一時格納した連携データを、連携データテーブル２３へ保存する。ステップＳ２９が終了すると、登録処理部１１は、実施例にかかるコード化データ登録時の処理を終了する。

（実施例にかかるコード化データ認証時の処理）
図８は、実施例にかかるコード化データ認証時の処理を示すフローチャートである。実施例にかかるコード化データ認証時の処理は、中間サーバ１０の認証処理部１２および認証依頼部１３により実行される。図８に示すコード化データ認証時の処理は、１：Ｎ認証である場合を例とするが、１：１認証でも同様の処理となる。中間サーバ１０は、コンソール端末（不図示）から実行開始を指示されると、公衆回線１００−１を介して接続されたクライアント端末３０と専用回線１００−２を介して接続された連携先システムＡ_５０Ａ〜連携先システムＣ_５０Ｃと連携させて処理を実行する。

先ず、ステップＳ５１では、認証処理部１２は、コード化データ（登録用）テーブル２２から全てのコード化データ（登録用）を取得し、中間サーバ１０のワーク記憶領域（不図示）へ格納する。次に、ステップＳ５２では、認証処理部１２は、クライアント端末３０からの認証依頼を待ち合わせる。

次に、ステップＳ５３では、認証処理部１２は、コンソール端末（不図示）から終了要求を受付けたか否かを判定する。認証処理部１２は、コンソール端末（不図示）から終了の指示を受付けた場合（ステップＳ５３：Ｙｅｓ）、実施例にかかるコード化データ認証時の処理を終了する。一方、認証処理部１２は、コンソール端末（不図示）から終了の指示を受付けていない場合（ステップＳ５３：Ｎｏ）、ステップＳ５４へ処理を移す。

ステップＳ５４では、認証処理部１２は、クライアント端末３０の認証依頼部３３から、コード化データ（認証用）および連携先システム情報とともに認証依頼を受け付けたか否かを判定する。このコード化データ（認証用）は、生体部分撮影部４２により撮影された生体部分をもとにコード化データ（認証用）生成部３２により生成されたデータである。認証処理部１２は、クライアント端末３０の認証依頼部３３から認証依頼を受け付けた場合（ステップＳ５４：Ｙｅｓ）、ステップＳ５５へ処理を移す。一方、認証処理部１２は、クライアント端末３０の認証依頼部３３から認証依頼を受け付けていない場合（ステップＳ５４：Ｎｏ）、ステップＳ５２へ処理を戻す。

ステップＳ５５では、認証処理部１２は、ステップＳ５４で受け付けた認証依頼に応じて、コード化データに基づく１：Ｎ認証を実施する。具体的には、認証処理部１２は、ステップＳ５４で受け付けたコード化データ（認証用）と、中間サーバ１０のワーク記憶領域（不図示）へ格納している全てのコード化データ（登録用）とを１：Ｎ認証を実施する。

なお、ステップＳ５４で中間サーバ１０が受け付けたコード化データ（認証用）は、ステップＳ５５での１：Ｎ認証の規模に応じた、この１：Ｎ認証の実施に必要な情報量を有する。また、ステップＳ５５では、１：Ｎ認証に限られず、ＩＤ等を併用する１：１認証が行われてもよい。ステップＳ５５で１：１認証を実施する場合、コード化データ（認証用）および連携先システム情報の他に管理ＩＤをクライアント端末３０の認証依頼部３３から受け付ける。

次に、ステップＳ５６では、認証処理部１２は、ステップＳ５５での１：Ｎ認証において、クライアント端末３０から受け付けたコード化データ（認証用）と一致するコード化データ（登録用）の候補（一致候補）が存在するか否かを判定する。認証処理部１２は、ステップＳ５５での１：Ｎ認証において、クライアント端末３０から受け付けたコード化データ（認証用）の一致候補が存在する場合（ステップＳ５６：Ｙｅｓ）、ステップＳ５７へ処理を移す。一方、認証処理部１２は、ステップＳ５５での１：Ｎ認証において、クライアント端末３０から受け付けたコード化データ（認証用）の一致候補が存在しない場合（ステップＳ５６：Ｎｏ）、ステップＳ６６へ処理を移す。

ステップＳ５７では、認証処理部１２は、ステップＳ５５での１：Ｎ認証において、クライアント端末３０から受け付けたコード化データ（認証用）の一致候補が複数存在するか否かを判定する。認証処理部１２は、ステップＳ５５での１：Ｎ認証において、クライアント端末３０から受け付けたコード化データ（認証用）の一致候補が複数存在する場合（ステップＳ５７：Ｙｅｓ）、ステップＳ６６へ処理を移す。一方、認証処理部１２は、ステップＳ５５での１：Ｎ認証において、クライアント端末３０から受け付けたコード化データ（認証用）の一致候補が１つのみ存在する場合（ステップＳ５７：Ｎｏ）、ステップＳ５８へ処理を移す。

ステップＳ５８では、認証処理部１２は、ステップＳ５７でコード化データ（認証用）の唯一の一致候補とされた（認証ＯＫとなった）コード化データ（登録用）の管理ＩＤを取得する。次に、ステップＳ５９では、認証処理部１２は、ステップＳ５８で取得した管理ＩＤをもとに連携データテーブル２３を参照し、認証ＯＫとなった管理ＩＤに対応するレコードを取得する。

次に、ステップＳ６０では、認証処理部１２は、ステップＳ５９で取得した連携データテーブル２３のレコードにクライアント端末３０から受け付けた連携先システム情報と一致する連携先システムの登録があるか否かを判定する。“連携先システムの登録がある”とは、例えば図５に示すように、「管理ＩＤ」に対応付けられて「連携先システムＡ」〜「連携先システムＣ」の何れかに“○”や“○＋ＩＤ”が格納されていることをいう。認証依頼部１３は、ステップＳ５９で取得した連携データテーブル２３のレコードに連携先システムの登録がある場合（ステップＳ６０：Ｙｅｓ）、ステップＳ６１へ処理を移す。一方、認証依頼部１３は、ステップＳ５９で取得した連携データテーブル２３のレコードに連携先システムの登録がない場合（ステップＳ６０：Ｎｏ）、ステップＳ６７へ処理を移す。

ステップＳ６１では、認証依頼部１３は、ステップＳ６０で登録ありとされた連携先システムへ認証依頼を送信する。認証依頼部１３は、ステップＳ６１で認証依頼を送信する際、コード化データ（認証用）の唯一の一致候補とされたコード化データ（登録用）と同じ側の手の生体情報（認証用）を送信する。認証依頼部１３は、連携先システムへ依頼する認証が１：１認証である場合には、連携データテーブル２３に格納されているＩＤを認証依頼に含めて連携先システムへ送信する。

例えば、認証依頼部１３は、認証対象の利用者の右手についてコード化データ（認証用）の唯一の一致候補のコード化データ（登録用）が存在した場合、連携データテーブル２３における右手の生体情報（認証用）を含んだ認証依頼を送信する。例えば、連携先システムＡ_５０Ａの認証処理部５１Ａは、中間サーバ１０から受信した認証依頼に含まれる生体情報（認証用）と、生体情報（登録用）テーブル５２Ａ−１に格納されている生体情報（認証用）とを照合することにより、利用者を認証する。そして、認証処理部５１Ａは、中間サーバ１０へ認証結果を送信する。連携先システムＢ_５０Ｂ、連携先システムＣ_５０Ｃについても、連携先システムＡ_５０Ａと同様である。

なお、認証依頼部１３は、ステップＳ６１で連携先システムへ認証依頼を送信する際、依頼元である中間サーバ１０へ連携先システムによる認証結果が返却されるように、認証依頼に中間サーバ１０のネットワーク識別情報等を含める。

次に、ステップＳ６２では、認証依頼部１３は、ステップＳ６１で認証依頼を送信した連携先システムからの認証結果の受信を待ち合わせる。次に、ステップＳ６３では、認証依頼部１３は、ステップＳ６１で認証依頼を送信した連携先システムから認証結果を受信したか否かを判定する。認証依頼部１３は、ステップＳ６１で認証依頼を送信した連携先システムから認証結果を受信した場合（ステップＳ６３：Ｙｅｓ）、ステップＳ６４へ処理を移す。一方、認証依頼部１３は、ステップＳ６１で認証依頼を送信した連携先システムから認証結果を受信していない場合（ステップＳ６３：Ｎｏ）、ステップＳ６２へ処理を移し、連携先システムからの認証結果の受信を待ち合わせる。

ステップＳ６４では、認証依頼部１３は、ステップＳ６３で認証結果を受信したと判定した連携先システムからの認証結果（認証ＯＫ（成功）または認証ＮＧ（失敗））を、ステップＳ５４で受け付けた認証依頼の送信元であるクライアント端末３０へ返却する。次に、認証依頼部１３は、コンソール端末（不図示）から終了要求を受付けたか否かを判定する。認証依頼部１３は、コンソール端末（不図示）から終了要求を受付けた場合（ステップＳ６５：Ｙｅｓ）、実施例にかかるコード化データ認証時の処理を終了する。一方、認証依頼部１３は、コンソール端末（不図示）から終了要求を受付けていない場合（ステップＳ６５：Ｎｏ）、ステップＳ５２へ処理を移す。

他方、ステップＳ６６では、認証処理部１２は、認証ＮＧをステップＳ５４で受け付けた認証依頼の送信元であるクライアント端末３０へ返却する。ステップＳ６６が終了すると、認証処理部１２は、ステップＳ５２へ処理を移す。また、ステップＳ６７では、認証処理部１２は、ステップＳ５９で取得した連携データテーブル２３における連携先システム登録なしを、ステップＳ５４で受け付けた認証依頼の送信元であるクライアント端末３０へ返却する。ステップＳ６７が終了すると、認証処理部１２は、ステップＳ５２へ処理を移す。

（実施例による効果の一例）
生体情報は生体の固有情報であることから、情報漏洩してしまうと利用者の認証を行う情報として用いることはできない。そのため、情報漏洩のリスクが高い公衆回線１００−１を介して生体情報を送受信することは、認証システムのセキュリティの観点から危険である。

しかし、実施例では、生体情報で利用者の認証を行う連携先システムでの認証に先立って、中間サーバ１０は、生体情報がコード化されたコード化データ（認証用）を公衆回線１００−１を介してクライアント端末３０から受信する。そして、中間サーバ１０は、受信したコード化データ（認証用）に基づく利用者の認証を行う。中間サーバ１０は、コード化データ（認証用）に基づく認証がＯＫとなった場合、コード化データ（認証用）に対応付けられて中間サーバ１０に格納されている生体情報（認証用）を専用回線を介して連携先システムＡ_５０Ａ〜連携先システムＣ_５０Ｃへ送信する。そして、連携先システムＡ_５０Ａ〜連携先システムＣ_５０Ｃは、中間サーバ１０から受信した生体情報（認証用）に基づく利用者の認証を行う。

つまり、実施例では、専用回線１００−２のみを介して接続され、生体情報で認証する連携先システムＡ_５０Ａ〜連携先システムＣ_５０Ｃへ中間サーバ１０を介して接続させることで、公衆回線に接続する環境から連携先システムＡ_５０Ａ〜連携先システムＣ_５０Ｃを利用できる。そして、連携先システムＡ_５０Ａ〜連携先システムＣ_５０Ｃが既存システムであればその認証機能を変更することなく利用可能であり、既存システムよりさらに高度なセキュリティの認証を提供するとともに、利用者の利便性を向上させることができる。例えば、連携先システムＡ_５０Ａ〜連携先システムＣ_５０Ｃが大規模な１：Ｎ認証を行う場合にも機能変更を要しない。また、連携先システムＡ_５０Ａ〜連携先システムＣ_５０Ｃが新規システムであれば、コード化データを用いた認証のみでは確保できない高度なセキュリティの認証を利用者に提供できる。

また、コード化データは、バイナリデータ化しているため生体情報と互換性がないため、生体情報を用いて利用者の認証を高精度で行う連携先システムＡ_５０Ａ〜連携先システムＣ_５０Ｃでの認証（例えば大規模な１：Ｎ認証）に用いることができない。しかし、実施例によれば、連携先システムＡ_５０Ａ〜連携先システムＣ_５０Ｃが中間サーバ１０で取得されたコード化データに対応する生体情報を用いて認証を行う。よって、利用者は、クライアント端末３０から公衆回線１００−１を介して中間サーバ１０へコード化データを送信するのみで、連携先システムＡ_５０Ａ〜連携先システムＣ_５０Ｃの認証機能による認証を受け、認証機能に応じたサービスを受けることができる。また、コード化データは、生体情報に対してハッシュ化などの技術を施してバイナリデータ化していることから、コード化データから元の生体情報を推定することは困難であり、情報漏洩した際のダメージを低減できる。

また、中間サーバ１０での認証も生体情報から生成したコード化データで行うため、なりすましはできず、セキュリティが確保される。さらに、中間サーバ１０および連携先システムＡ_５０Ａ〜連携先システムＣ_５０Ｃでの２段階の認証を行うため、セキュリティを向上させることができる。また、公衆回線１００−１で送受信されるコード化データは、１つの生体情報から複数生成できるため、万が一情報漏洩してしまった場合でも異なるコード化データを新たに生成することができる。新たに生成されたコード化データを用いることで、サービス提供の継続性を高めることが可能である。このように、実施例によれば、公衆回線１００−１を送受信されるコード化データ（認証用）と、中間ＤＢ２０に格納されているコード化データ（登録用）とをセキュリティの脅威から保護することができる。

（変形例）
（１）複数のコード化データ
実施例では、管理番号毎の「コード化データ（登録用）右手」「コード化データ（登録用）左手」（図４参照）は、それぞれ１つのデータのみを有するとした。しかし、これに限られず、コード化データは、それぞれ複数のデータを有してもよい。つまり、１つの生体情報（認証用）（図５の「生体情報（認証用）右手」「生体情報（認証用）左手」それぞれ）に対して複数のコード化データ（登録用）（図４の「コード化データ（登録用）右手」「コード化データ（登録用）左手」）が対応付けられてもよい。例えば、コード化データは、「コード化データ（登録用）右手１」「コード化データ（登録用）右手２」のように、管理番号毎に、それぞれ異なる方法により生成された２つのデータを有してもよい。ここで、「コード化データ（登録用）右手１」と「コード化データ（認証用）右手１」とが対応し、「コード化データ（登録用）右手２」と「コード化データ（認証用）右手２」とが対応する。左手も同様である。

例えば、中間サーバ１０は、初期段階では「コード化データ（登録用）右手１」を用いてコード化データによる認証を行う。そして、中間サーバ１０は、「コード化データ（認証用）右手１」が公衆回線１００−１で情報漏洩した場合、「コード化データ（登録用）右手１」を無効とする。もしくは、中間サーバ１０は、「コード化データ（登録用）右手１」が中間ＤＢ２０に対する攻撃で情報漏洩した場合、「コード化データ（登録用）右手１」を無効とする。

そして、中間サーバ１０は、「コード化データ（登録用）右手１」から切り替えて「コード化データ（登録用）右手２」を用いてコード化データによる認証を行う。中間サーバ１０では、無効とした「コード化データ（登録用）右手１」に代わる予備用の新しいコード化データ（登録用）が、適切なタイミングで再登録される。同一の生体部分に対応する異なる方法により生成されたコード化データを予め複数準備しておくことで、中間サーバ１０は、コード化データ（認証用）の情報漏洩に迅速に対処し、セキュリティ低下を回避するとともに、サービスの継続性を維持することができる。

（２）連携データについて
実施例では、中間サーバ１０が何れの連携先システムＡ_５０Ａ〜連携先システムＣ_５０Ｃへ認証依頼を行うかは、連携データテーブル２３に格納される「連携データ」の「連携先システムＡ」「連携先システムＢ」「連携先システムＣ」の情報に基づくとした。しかし、これに限られず、中間サーバ１０が何れの連携先システムＡ_５０Ａ〜連携先システムＣ_５０Ｃへ認証依頼を行うかの情報は事前に登録せず、コード化データ（認証用）とともにクライアント端末３０から送信されてもよい。また、クライアント端末３０は、認証依頼を行う連携先システムＡ_５０Ａ〜連携先システムＣ_５０Ｃが１：１認証を行う場合には、１：１認証で用いるＩＤも併せて送信してもよい。

（コンピュータのハードウェア構成）
図９は、コンピュータのハードウェア構成の一例を示す図である。図９に示すコンピュータ１００は、プログラムが実行されることにより、中間サーバ１０、クライアント端末３０、または、連携先システムＡ_５０Ａ〜連携先システムＣ_５０Ｃが実装される。

コンピュータ１００は、バスを介して接続されている、プロセッサ１０１、内部記憶装置１０２、外部記憶装置１０３、通信インターフェース１０４、各種周辺装置１０５を有する。プロセッサ１０１は、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）、キャッシュメモリ等がワンチップに実装された処理装置である。内部記憶装置１０２は、ＲＡＭ（Random Access Memory）等の半導体記憶装置である。内部記憶装置１０２は、プロセッサ１０１と協働し、プロセッサ１０１が実行中のプログラムのプロセスや、プロセスの処理対象データを記憶する。

外部記憶装置１０３は、リムーバブルメディアや半導体記憶装置を記憶媒体とする不揮発性記憶装置である。コンピュータ１００は、外部記憶装置１０３のリムーバブルメディアや半導体記憶装置から実行対象のプログラムや処理対象データを取得してもよい。通信インターフェース１０４は、公衆網または閉域網を介してコンピュータを始めとする他の装置と通信を行うためのインターフェースである。コンピュータ１００は、他の装置から通信インターフェース１０４を介して実行対象のプログラムや処理対象データを取得してもよい。

各種周辺装置１０５は、入出力のためのユーザインターフェース（例えばキーボード、マウス、タッチパネル、ディスプレイ、スピーカ、ヘッドフォン等）を含む、コンピュータ１００に接続または内蔵される周辺装置である。

以上の実施例で例示した各部の構成は、開示技術にかかる認証システムおよび認証方法の技術範囲を逸脱しない程度に変更、追加、省略可能、統合または分散できる。また、実施例はあくまで例示に過ぎず、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の態様も、開示技術に含まれる。

１０・・・中間サーバ
１１・・・登録処理部
１２・・・認証処理部
１３・・・認証依頼部
２０・・・中間ＤＢ
２１・・・管理情報テーブル
２２・・・コード化データ（登録用）テーブル
２３・・・連携データテーブル
３０・・・クライアント端末
３１・・・受付部
３２・・・コード化データ（認証用）生成部
３３・・・認証依頼部
４１・・・入力部
４２・・・生体部分撮影部
５０Ａ・・・連携先システムＡ
５１Ａ・・・認証処理部
５２Ａ・・・生体情報（登録用）ＤＢ
５２Ａ−１・・・生体情報（登録用）テーブル
５０Ｂ・・・連携先システムＢ
５１Ｂ・・・認証処理部
５２Ｂ・・・生体情報（登録用）ＤＢ
５２Ｂ−１・・・生体情報（登録用）テーブル
５０Ｃ・・・連携先システムＣ
５１Ｃ・・・認証処理部
５２Ｃ・・・生体情報（登録用）ＤＢ
５２Ｃ−１・・・生体情報（登録用）テーブル
１００・・・コンピュータ
１００−１・・・公衆回線
１００−２・・・専用回線
１００−３・・・専用回線
１０１・・・プロセッサ
１０２・・・内部記憶装置
１０３・・・外部記憶装置
１０４・・・通信インターフェース
１０５・・・各種周辺装置

Claims (5)

1. 端末と、中間サーバとを有する認証システムであって、
   前記端末は、
   利用者の生体情報をコード化した認証用のコード化データを生成する生成部と、
   公衆回線を介して、前記認証用のコード化データを前記中間サーバへ送信し、前記利用者の認証を前記中間サーバに依頼する第１の認証依頼部と
   を含み、
   前記中間サーバは、
   前記利用者の生体情報をコード化した登録用のコード化データと前記利用者の生体情報とを対応付けて予め格納している格納部と、
   前記公衆回線を介して、前記第１の認証依頼部から前記認証用のコード化データを受信すると、受信した前記認証用のコード化データと前記登録用のコード化データとを照合して前記利用者を特定する認証処理部と、
   前記認証処理部による前記利用者の特定が成功すると、専用回線を介して、前記登録用のコード化データと対応付けられた前記生体情報を連携先システムへ送信し、前記利用者の認証を前記連携先システムに依頼する第２の認証依頼部と
   を含むことを特徴とする認証システム。
2. 前記格納部は、
   それぞれ異なる方法により生成された複数の前記登録用のコード化データと、１つの前記生体情報とを対応付けて予め格納している
   ことを特徴とする請求項１に記載の認証システム。
3. 前記中間サーバは、
   前記認証処理部と、前記第２の認証依頼部とを有し、前記公衆回線と接続されている第１のサーバと、
   前記格納部を有し、前記第１のサーバと専用回線で接続され、前記公衆回線から隔離されている第２のサーバと
   を含んだことを特徴とする請求項１または２に記載の認証システム。
4. 前記認証処理部は、前記認証処理部による前記利用者の特定が失敗すると、前記公衆回線を介して、認証失敗を前記端末へ返却し、
   前記第２の認証依頼部は、前記連携先システムにおける前記利用者の認証の成否を前記連携先システムから通知されると、該成否を前記端末へ転送する
   ことを特徴とする請求項１〜３の何れか１項に記載の認証システム。
5. 端末と、中間サーバとを有する認証システムにおける認証方法であって、
   前記端末が、
   利用者の生体情報をコード化した認証用のコード化データを生成し、
   公衆回線を介して、前記認証用のコード化データを前記中間サーバへ送信し、前記利用者の認証を前記中間サーバに依頼し、
   前記中間サーバが、
   前記利用者の生体情報をコード化した登録用のコード化データと前記利用者の生体情報とを対応付けて予め格納している格納部を含み、
   前記公衆回線を介して、前記端末から前記認証用のコード化データを受信すると、受信した前記認証用のコード化データと前記登録用のコード化データとを照合して前記利用者を特定し、
   前記利用者の特定が成功すると、専用回線を介して、前記登録用のコード化データと対応付けられた前記生体情報を連携先システムへ送信し、前記利用者の認証を前記連携先システムに依頼する
   ことを特徴とする認証方法。

Images