JPH0981520A - ネットワーク上の認証に用いられる照合サーバ - Google Patents

Abstract

(57)【要約】 【課題】 ネットワーク上で利用者の認証を容易に行
う。 【解決手段】 ユーザホスト２０から送出されてきた認
証データを、アプリケーションサーバ１０は、照合サー
バ３０に送出する。照合サーバ３０は、「正しい」認証
データを予めデータベースに保持しており、送出されて
きた認証データと、「正しい」認証データとを比較照合
する。そして、この照合の結果がアプリケーションサー
バ１０に返送される。アプリケーションサーバ１０はこ
の結果に基づき、利用者に認証を与える。この結果、ア
プリケーションサーバの構成が簡易化される。照合サー
バ３０は、複数のアプリケーションサーバ１０から利用
することができ、ネットワーク上の資源の運用の効率化
を図ることができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、アプリケーション
利用者の認証を行う方法に関する。特に、ネットワーク
上における利用者の認証に関する。

【０００２】

【従来の技術】銀行などのサービス業では、取引に際し
て、相手が本人であるか否かを確認すること、すなわち
認証は極めて重要な問題である。これは、他人が本人に
なりすまして口座からお金を引き出してしまったり、お
金を振り込んでしまったりすることを防止するためであ
る。

【０００３】この認証のためには、古典的には例えば、
運転免許証や、一定の身分証明書等を提出してもらい、
本人であるか否かを確認している。近年、現金自動引き
出し器等の発達により、磁気カードやパスワードなどに
よって、本人の認証を行う方法が広く採用されている。

【０００４】このような「認証」は、銀行以外でも必要
とされる場合は多い。例えば、研究機関などにおいて
は、秘密漏洩を防止すべく、一定の区域へは許可された
者のみ入場を許し、それ以外の者に対しては入場を制限
する場合が多い。また、会員制クラブ等でも会員である
ことを何らかの方法で確認しなければならない。この研
究機関や会員制クラブにおいても、上記磁気カードやパ
スワード、若しくは会員証等を用いることも好適であ
る。しかし、磁気カードや会員証は紛失してしまう可能
性があるし、また、パスワードも忘れてしまう可能性も
決して小さくはない。そのため、本人を確認する方法と
して、指紋や、網膜パターン等のいわゆるバイオメトリ
ックな物理量を認証のためのデータ（以下、認証データ
という）として用いる方法も提案されている。

【０００５】企業内の電子ドキュメント承認プロセスで
は、署名を用いて本人であることを確認し、承認するこ
とが自然である。また近年、企業ではＣＡＤの利用が一
般化しており、その承認のプロセスでは署名データの形
状をイメージデータとしてＣＡＤデータにはりつけるこ
ともできる。

【０００６】

【発明が解決しようとする課題】近年、ネットワークの
発達により、このネットワーク上で種々のサービスの提
供が行われるようになった。例えば、いわゆるインター
ネットにおいては、ＷＷＷ（World Wide Web）等による
マルチメディアタイトルの提供サービスが広く行われて
いる。このようなサービスの提供においては、一般の銀
行等におけるサービスと同様に、一定の資格者にのみア
クセスを認める場合もある。このようなネットワーク上
のサービスにおいても、従来のサービスと同様に、「認
証」はきわめて重要な問題である。

【０００７】しかしながら、ネットワーク上で本人であ
るか否かの認証をする場合に、上述したバイオメトリッ
クな認証データを用いることは一般にきわめて困難であ
る。例えば網膜パターンや指紋、あるいは掌紋等を入力
する装置を各端末に備える必要があり、また、このよう
な物理量をネットワークを介して伝送するための仕組み
も新たに必要となってしまう。

【０００８】そのため、ネットワーク上で用いられるバ
イオメトリックな物理量として、署名データを用いるこ
とが注目されている。この署名データは、いわゆるタブ
レットにより容易に入力することができ、かつ平面の２
次元データだけではなく、筆圧の変化や署名を書くスピ
ードもデータとしているため、本人であるか否かを確認
するための認証データとして優れた特性を有している。
更に、タブレットは一般に安価に構成できるので、端末
のコストも安く抑えることができるという特徴を有して
いる。

【０００９】以上述べたように、パスワードなどの認証
データの他、署名データ等のバイオメトリックな認証デ
ータがネットワーク上における「認証」に利用されてい
る。

【００１０】ところが、ネットワークの拡大にともな
い、サービスの提供者であるアプリケーションサーバの
種類が増え、かつそのサービスの提供を受けるクライア
ントの数もきわめて膨大なものとなっている。そのた
め、各アプリケーションサーバがそれぞれ別個に認証を
行う際の負担が過大になってきている。特に、インター
ネットのように世界規模で拡がっている場合には、アプ
リケーションサーバとそのサービスの提供を受けるクラ
イアントとの間がきわめて遠距離となる場合も多い。こ
のような場合に、認証データのやりとりをすることがネ
ットワーク上のトラフィックの増大に結びついてしまう
ことも考えられる。

【００１１】本発明は、このような課題を解決するため
になされたものであり、その目的は、ネットワーク上の
クライアントの認証のための照合の機能をアプリケーシ
ョンサーバと独立してネットワーク上に設けることによ
って、アプリケーションサーバの負荷を減少させるとと
もに、クライアントの認証を容易に行うことを可能とす
ることである。

【００１２】

【課題を解決するための手段】第１の本発明は、上記課
題を解決するために、ネットワーク上の利用者の正しい
認証データを記憶する記憶手段と、外部からの所定の利
用者の認証データに関する照合要求に応じて、前記記憶
手段から前記所定の利用者の正しい認証データを取り出
す検索手段と、前記照合要求に応じて、前記検索手段が
取り出した前記正しい認証データと、前記照合要求に係
る認証データとを比較照合する照合手段と、前記照合の
結果を送出する送出手段と、を含み、前記認証データが
前記所定の利用者の認証データであるか否か照合を行う
照合サーバである。

【００１３】このような構成により、認証データの照合
動作を集中的に行わせることが可能となり、利用者の認
証を行う必要なる所定のアプリケーションサーバから適
宜利用することが可能となる。

【００１４】その結果、従来各アプリケーションサーバ
などが個々に有していた照合機能をネットワーク上で集
中して管理することができるので、資源の有効な活用が
可能となる。

【００１５】第２の本発明は、上記課題を解決するため
に、上記第１の本発明の照合サーバにおいて、前記記憶
手段は、前記利用者の識別データと、前記利用者の前記
認証データと、さらに、前記利用者に関して照合サーバ
が要求する所定のデータと、から成るテーブル手段を備
え、前記検索手段は、前記利用者の識別データに基づ
き、前記記憶手段から前記正しい認証データを取り出し
うるとともに、前記所定のデータに基づいても、前記記
憶手段から前記正しい認証データを取り出しうることを
特徴とする照合サーバである。

【００１６】このように、「正しい」認証データを取り
出すためのインデックスが利用者の識別データだけでな
く所定のデータによっても構成されているため、利用者
が識別データを忘れてしまった場合においても、その他
のデータから認証データを取り出すことが可能である。

【００１７】例えば、上記所定のデータとしては、利用
者の名前や、電話番号、生年月日などを利用するのが好
適である。また、その利用者の識別するのにある程度寄
与するものであれば血液型等も利用可能である。

【００１８】第３の本発明は、上記課題を解決するため
に、上記第１の本発明の照合サーバにおいて、照合準備
要求に応じて、前記利用者の正しい認証データを記憶手
段から読み出し、前記記憶手段より読み出し速度の速い
キャッシュ手段に予め格納しておくキャッシュ制御手
段、を含むことを特徴とする照合サーバである。

【００１９】第３の本発明においては、照合準備要求に
応じて予め「正しい」認証データをキャッシュに読み出
しておいたので、所定の利用者の認証データが実際に送
られてきたときに迅速に照合動作を開始することが可能
である。

【００２０】そのため、認証動作の高速化を図ることが
可能である。

【００２１】

【発明の実施の形態】以下、本発明の好適な実施の形態
を、図面に基づいて説明する。

【００２２】図１には、本実施の形態において、ネット
ワーク上に設けられているアプリケーションサーバ（Ａ
ｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ）１０のサービス
を利用するユーザホスト（Ｕｓｅｒ Ｈｏｓｔ）２０
と、ユーザホスト２０の認証の際に利用される照合サー
バ（Ｓｅｒｖｅｒ）３０とがネットワーク上に配置され
ている様子が示されている。

【００２３】本実施の形態において特徴的なことは、ユ
ーザホスト２０の認証の際の照合動作が、アプリケーシ
ョンサーバ１０において行われるのではなく、アプリケ
ーションサーバ１０とは別体にネットワーク上に設けら
れている照合サーバ３０を用いて行われていることであ
る。このように、照合動作を行う照合サーバ３０をアプ
リケーションサーバ１０と独立にネットワーク上に設け
ることにより、個々のアプリケーションサーバ１０はユ
ーザホスト２０の認証のための「正しい」認証データを
保持したり、照合のための機能を有する必要がなくな
る。また、図１においてはアプリケーションサーバ１０
としてひとつの構成しか示されていないが、ネットワー
ク上に複数のアプリケーションサーバ１０を設けること
も好適であり、この場合にはその複数のアプリケーショ
ンサーバ１０から１個の照合サーバ３０を利用して「照
合」動作を委託することができ、複数のアプリケーショ
ンサーバ１０において従来重複して備えられていた認証
データの照合機能を一つにまとめることができ、効率的
な資源の運用が可能となる。

【００２４】また、この照合サーバ３０は、ネットワー
ク上に複数個設けることも好適である。そして、各アプ
リケーションサーバ１０は、認証の内容に応じて、好適
な照合サーバを利用することが可能となる。例えば、認
証データとして署名データが用いられる場合と、認証デ
ータとして指紋データが用いられる場合とにおいて利用
する照合サーバ３０を変えることも考えられる。もしく
は、各利用者が自分の認証データを保持している照合サ
ーバ３０を自ら指定することも考えられよう。

【００２５】図１に示されているように、照合サーバ３
０をアプリケーションサーバ１０と独立にネットワーク
上に設けることにより、認証の際のメッセージのやりと
りは例えば図１において矢印で示されるようになる。図
１（ａ）に示されているように、まず、アプリケーショ
ンサーバ１０がユーザホスト２０に対して認証データを
送るように要求する（図１（ａ）においてａで示され
る）。この認証データは、古典的にはパスワードや会員
番号を利用することもできるが、バイオメトリックな物
理量、例えば署名データ等を用いることが好適である。
特に、上述したように、署名データは、ユーザホスト２
０に安価なタブレットを準備するだけで容易に入力する
ことが可能である。

【００２６】ユーザホスト２０は、ａの要求に対して利
用者の署名データをタブレットから入力し、利用者の識
別データ（例えば会員番号や利用者名）と共にアプリケ
ーションサーバ１０に返送する（図１（ａ）においてｂ
で示される）。アプリケーションサーバ１０において
は、この認証データを予め記憶しておいて「正当な」認
証データと照合し、ユーザホスト２０が正しい利用者で
あるか否かを判断するわけであるが、この照合作用を外
部の照合サーバ３０にいわば委託しているのである。こ
のため、アプリケーションサーバ１０はユーザホスト２
０から送られてきた認証データと識別データを含むメッ
セージを照合サーバ３０に送出し、照合を依頼する（図
１（ａ）においてｃで示される）。

【００２７】照合サーバ３０は、アプリケーションサー
バ１０から送られてきた認証データと識別データを含む
メッセージを受信すると、その認証データが正当な認証
データであるか否かを検査する。照合サーバ３０はユー
ザホスト２０が本人であると主張する利用者名と、その
利用者の正しい認証データとをデータベースとして内部
に保持している。そして、このデータベースを検索する
ことにより、ユーザホスト２０が本人であると主張する
利用者についての正しい認証データ、本実施の形態にお
いては例えば署名データ、を取り出す。そして、この取
り出された認証データとアプリケーションサーバ１０か
ら送られてきた認証データとを比較・照合し、その結果
をアプリケーションサーバ１０に返送する（図１（ａ）
においてｄで示されている）。アプリケーションサーバ
１０は、この照合サーバ３０から返送されてきた照合結
果に基づいてユーザホスト２０に対して認証を行うので
ある。

【００２８】本実施の形態においては、このように照合
の動作を行う部分を、アプリケーションサーバ１０と独
立にネットワーク上に設けたので、複数のアプリケーシ
ョンサーバ１０に共通に重複して設けられていた照合機
能を節約することができるとともに、認証動作の確実さ
を担保することが可能である。

【００２９】尚、図１（ａ）においては、ユーザホスト
２０が送出する署名データ（認証データ）はアプリケー
ションサーバ１０を介して照合サーバ３０に供給された
が、ユーザホスト２０から直接照合サーバ３０に送出す
ることも好適である。

【００３０】図１（ｂ）には、ユーザホスト２０から直
接照合サーバ３０に認証データを送出する場合の例が示
されている。図１（ｂ）に示されている例によれば、ま
ず、アプリケーションサーバ１０がユーザホスト２０に
対して、認証データを照合サーバ３０に送るように要求
する（図１（ｂ）においてｅで示される）。

【００３１】ユーザホスト２０は、ｅの要求に対して利
用者の署名データをタブレットから入力し、照合サーバ
３０にこの署名データを送出する（図１（ｂ）において
ｆで示される）。アプリケーションサーバ１０は、ユー
ザホスト２０が正しい利用者であるか否かを判断するわ
けであるが、その認証の際に必要な「照合」作用を外部
の照合サーバ３０にいわば委託している。このため、照
合サーバ３０は、ユーザホスト２０から送出されてきた
認証データを予め記憶しておいて「正当な」認証データ
と照合する。図１（ａ）に示されている例と同様に、照
合サーバ３０はユーザホスト２０が本人であると主張す
る利用者名と、その利用者の正しい認証データとをデー
タベースとして内部に保持している。そして、このデー
タベースを検索することにより、ユーザホスト２０が本
人であると主張する利用者についての正しい認証データ
を取り出す。そして、この取り出された認証データとユ
ーザホスト２０から送られてきた認証データとを比較・
照合し、その結果をアプリケーションサーバ１０に送出
する（図１においてｇで示されている）。アプリケーシ
ョンサーバ１０は、この照合サーバ３０から返送されて
きた照合結果に基づいてユーザホスト２０に対して認証
を行うのである。

【００３２】なお、図１（ａ）、（ｂ）いずれの場合も
アプリケーションサーバ１０としては、インターネット
上における例えばＷＷＷサーバや、各種のデータベース
等、種々のサービスを提供するサーバが考えられる。

【００３３】図２には、図１に示されているユーザホス
ト２０やアプリケーションサーバ１０及び照合サーバ３
０の詳細な構成を表す構成ブロック図が示されている。
図２（ａ）は、図１（ａ）に対応する構成図である。図
２（ａ）に示されているように、ユーザホスト２０は、
パーソナルコンピュータ等の端末から構成されており、
インターネットに接続し、ＷＷＷサーバ４２に接続する
ためのネットスケープ（Ｎｅｔｓｃａｐｅ）５２を備え
ている。なお、本実施の形態ではネットスケープ５２が
用いられているが、これはモザイク（Ｍｏｓａｉｃ）
等、他のＷＷＷブラウザでもかまわない。ユーザホスト
２０はこのネットスケープ５２の他に、利用者が署名デ
ータを入力するためのタブレット（Ｔａｂｌｅｔ）５４
を備えている。また、このタブレット５４を制御し、署
名データを取り出すためのタブレットドライバプログラ
ム５６が備えられている。このタブレットドライバプロ
グラム５６は、アプリケーションサーバ１０から認証デ
ータを送出するように要求が来た場合に、その要求をネ
ットスケープ５２を介して受け取り、タブレット５４を
駆動して得られた認証データ（署名データ）をアプリケ
ーションサーバ１０に送出するのである。なお、図１
（ａ）に示されているメッセージのやりとりａ，ｂ，
ｃ，ｄと同一のメッセージのやりとりに対して同一の符
号ａ，ｂ，ｃ，ｄが図２（ａ）にも付されている。

【００３４】アプリケーションサーバ１０は、Ｕｎｉｘ
マシン上に構築される場合が多い。このアプリケーショ
ンサーバ１０には、図２（ａ）に示されているようにマ
ルチメディアタイトルを提供するＷＷＷサーバ４２と、
利用者の正当性を確認するための署名照合要求プログラ
ム４４とが備えられている。照合サーバ３０は、アプリ
ケーションサーバ１０と同様にＵｎｉｘ等のマシン上に
構築されており、正当な利用者とその利用者の認証デー
タとを登録した登録データ６２を有している。そして、
上記署名照合要求プログラム４４から送出されてくる利
用者名（利用者の識別コード）と、ユーザホスト２０か
ら送出されてきた認証データとに基づいて照合し、照合
結果をアプリケーションサーバ１０の署名照合要求プロ
グラム４４に返送する。

【００３５】尚、図１（ｂ）に対応する構成図は、図２
（ｂ）に示されている。図２（ｂ）におけるアプリケー
ションサーバ１０、ユーザホスト２０、及び照合サーバ
３０の構成は、図２（ａ）に示されている構成と全く同
様である。異なる点は、ユーザホスト２０のドライバプ
ログラムから照合サーバ３０に直接に照合の要求が出さ
れていることである。照合サーバが照合の対象となる認
証データをユーザホスト２０から受け取るのか、若しく
はアプリケーションサーバ１０を介して受け取るのかの
違いがあるだけで、その他の構成は図２（ａ）と（ｂ）
とは全く同様である。また、図２（ｂ）には図１（ｂ）
に対応して、やりとりされるメッセージにｅ，ｆ，ｇの
符号が付されている。

【００３６】照合サーバ３０の登録データ６２は、本実
施の形態においては、リレーショナルデータベース（以
下、ＲＤＢという）によって管理されている。この登録
データのＲＤＢ内の様子が図３に示されている。図３に
示されているように、登録データは各正当な利用者毎に
所定のデータを記録した表の形で記録されている。図に
示されているように、まずフラグ（ｆｌａｇ）は、シス
テムの種々の状態を表すためのフラグであり、例えば削
除フラグ（その利用者がシステムから削除されたか否か
を表す）等として用いられる。また、システムユニーク
キー（ＳｙｓＵｎｉｑ Ｋｅｙ）は、各利用者に与えら
れるシステムキーであり、照合サーバ３０におけるテー
ブル（図３に示されている）の中で唯一に定められる。
また、登録タブレットタイプは、その利用者が利用する
タブレットのタイプを表す。また、署名データ（Ｓｉｇ
ｎａｔｕｒｅ ｄａｔａ）は、タブレット上で動く電子
ペンの動きを表す時系列データである。この署名データ
には、二次元的な位置を表す情報だけではなく、筆圧
や、ペンの速度の情報も含まれているため、本人である
か否かの認証を精度よく行うことが可能である。

【００３７】このように、照合サーバ３０内部のＲＤＢ
には、システムユニークキーと、署名データとが登録さ
れているため、アプリケーションサーバ１０から送出さ
れた来た署名データ及び利用者を表すシステムユニーク
キーを用いて、この送られてきた署名データが正当なも
のであるか否かを判断することが可能である。この判断
の結果の内容については後で説明する。

【００３８】本実施の形態におけるＲＤＢにおいてはシ
ステムユニークキーと署名データの他に、システム要求
項目（Ｓｙｓｔｅｍ ｒｅｑｕｉｒｅｄ ｉｔｅｍｓ）
と呼ばれる登録項目が記憶されている。図３に示されて
いるように、システム要求項目としては、利用者の名前
（Ｎａｍｅ）、利用者の誕生日（Ｄａｔｅ ｏｆ ｂｉ
ｒｔｈ）及び利用者の電話番号（Ｐｈｏｎｅ＃）が登録
されている。これらのシステム要求項目は、システムユ
ニークキーの代わりに用いられるものである。すなわ
ち、システムユニークキーは後述するようにアプリケー
ションサーバと照合サーバとが保持している利用者を識
別するためのキーであるが、利用者は自分に与えられた
システムユニークキーを必ずしも覚えているとは限らな
い。そのため、利用者が登録されている署名データを確
認したい場合等において、システムユニークキー以外で
利用者を特定できる手段が存在した方が望ましい。この
ような場合にシステムユニークキー以外でも、利用者の
名前や誕生日、そして電話番号等で利用者を識別し得る
ようにしたのである。

【００３９】この本実施の形態におけるシステム要求項
目（Ｓｙｓｔｅｍ ｒｅｑｕｉｒｅｄ ｉｔｅｍｓ）
は、本願発明の「前記利用者に関して照合サーバ３０が
要求する所定のデータ」に相当する。また、本実施の形
態のシステムユニークキーは、本願発明の「利用者の識
別コード」に相当する。

【００４０】このように本実施の形態においては、「正
しい」認証データをシステムユニークキーだけでなく、
所定のデータでも読み出せるように構成したので、利用
者がシステムユニークキーを失念してしまった場合等に
おいても電話番号などから認証データの確認を行うこと
が可能である。

【００４１】更に、本実施の形態においては、図３に示
されているように、オプショナルフィールド（Ｏｐｔｉ
ｏｎａｌ ｆｉｅｌｄｓ）が設けられている。このオプ
ショナルフィールドに登録されているデータはいわゆる
システム監査用のデータであり、ネットワークの管理者
が照合サーバ３０の動作を管理する際に用いられる管理
データである。図３に示されているように、この管理用
のデータとしては、データの作成日（Ｃｒｅａｔｉｏｎ
ｄａｔｅ）、データの作成者（Ｃｒｅａｔｉｏｎ ｈ
ｏｓｔ）、また、最終アクセス日（Ｌａｓｔ ａｃｃ．
ｄａｔｅ）や、最終アクセス者（Ｌａｓｔ ａｃｃ．
ｂｙ）、その他アクセス回数（ａｃｃｅｓｓ ｃｏｕ
ｎｔ）や照合が失敗した回数（ｆａｉｌｕｒｅ ｃｏｕ
ｎｔ）等、種々のデータを登録することが可能である。

【００４２】また、アプリケーションサーバ１０にも照
合サーバ３０内のＲＤＢに対応して、利用者についての
情報を登録したＲＤＢが備えられている。このアプリケ
ーションサーバ１０内のＲＤＢに登録されている内容が
図４に示されている。図４に示されているように、各種
の登録データが個々の利用者毎に登録されている。図４
に示されているように、まず、「照合サーバ名」は、そ
の利用者が送ってきた認証データ（署名データ）がどの
照合サーバによって照合されるべきか否かを表すもので
ある。図１に示された構成図においては、照合サーバ３
０はひとつしか示していなかったが、ネットワーク内に
複数の照合サーバ３０が存在することも構成として可能
である。例えば、各利用者は、自分が連絡を取りやすい
照合サーバ３０を使用したいと思う場合もあるであろう
し、またアプリケーションサーバ１０が各利用者毎に照
合サーバを管理上の理由により変更したいと考える場合
もあるであろう。

【００４３】図４に示されているフラグ（ｆｌａｇ）と
システムユニークキー（Ｓｙｓ Ｕｎｉｑ Ｋｅｙ）と
は、図３におけるフラグ及びシステムユニークキーと同
一のものである。このシステムユニークキーは、上述し
たように、照合サーバ３０のＲＤＢの中で唯一に定めら
れているものである。換言すれば、照合サーバ３０が異
なる利用者については、同一のシステムユニークキーが
割り当てられる可能性も存在する。したがって、利用者
の識別は、厳密には、このシステムユニークキーと照合
サーバ名とを組み合わせることにより行われることにな
る。アプリケーションユーザキー（Ａｐｐ． ｕｓｅｒ
ｋｅｙ）は、そのアプリケーションサーバ１０の提供
するサービスを受けられるか否かを表すキーである。場
合によっては図４に示されているように追加アプリケー
ションユーザキー（Ａｄｄｉｔｉｏｎａｌ ａｐｐ．
ｕｓｅｒ ｋｅｙ）が設定される場合もある。更に、図
４に示されているように作成日（Ｃｒｅａｔｉｏｎ ｄ
ａｔｅ）や最終アクセス日（Ｌａｓｔ ａｃｃ． ｄａ
ｔｅ）、最終アクセス者（Ｌａｓｔ ａｃｃ． ｂ
ｙ）、アクセス回数（ａｃｃｅｓｓ ｃｏｕｎｔ）、照
合が失敗した回数（ｆａｉｌｕｒｅ ｃｏｕｎｔ）等が
図３に示されている照合サーバ３０内のＲＤＢに対応し
て登録されている。また、具体的な項目名は示されてい
ないが、アプリケーションオプショナルフィールド（Ａ
ｐｐｌｉｃａｔｉｏｎ ｏｐｔｉｏｎａｌｆｉｅｌｄ
ｓ）にアプリケーションが利用する所定の登録データを
登録することも好適である。

【００４４】図５には、本実施の形態に係る照合サーバ
３０がサポートするプロトコルの説明図が示されてい
る。図５に示されているように、まずプロトコル「キー
の登録」においては、アプリケーションサーバ１０が所
定の必須項目を含むメッセージを照合サーバ３０に送出
する。照合サーバはこれらの必須項目をＲＤＢに登録す
ると共に、システムユニークキーを生成する。このシス
テムユニークキーはＲＤＢに登録されると共に、アプリ
ケーションサーバ１０に返送される。このようにして、
利用者を識別するシステムユニークキーが照合サーバ３
０において生成される。このシステムユニークキーはア
プリケーションサーバ１０においてもＲＤＢ内に登録さ
れ、照合サーバ３０とアプリケーションサーバ１０との
間でシステムユニークキーの共有がなされる。

【００４５】次に、プロトコル「署名データの登録」に
おいては、アプリケーションサーバ１０が、システムユ
ニークキー、３個の署名データ、タブレットタイプ等
を、照合サーバ３０に送出し、「正しい」署名データを
照合サーバ３０内のＲＤＢに登録させる。ここで、３個
の署名データを送出するのは平均的な署名データの値を
照合サーバにおいて求めて、平均的な値をＲＤＢ内に登
録するためである。登録が正常に完了すれば、戻り値
「ｏｋ」をアプリケーションサーバ１０に返送し、既に
登録が行われている場合等には「ｅｒｒｏｒ」が戻り値
として返送される。また、３個の署名データが互いに著
しく異なりすぎている場合には、署名データとしての信
頼性が低いため、登録は行わずに「ｕｎｓｔａｂｌｅ」
を戻り値として返送する。

【００４６】プロトコル「照合準備」においては、アプ
リケーションサーバ１０が、システムユニークキーのみ
を照合サーバ３０に送出し、「正しい」認証データをＲ
ＤＢからキャッシュに呼び出させておく。このように、
実際の認証データとの照合プロトコルに先立って、認証
データを予め呼び出させておくことにより、後述するよ
うに迅速な照合処理が行えるのである。本プロトコル
は、処理の迅速化のために行われるのであり、迅速化が
必要でない場合には、本プロトコルを省略し、直接、後
述する「照合」プロトコルを発行してもよい。尚、「正
しい」認証データの呼び出しが正常に完了した場合には
メッセージＩＤがアプリケーションサーバ１０に返送さ
れるが、エラーが生じた場合には「ｅｒｒｏｒ」を戻り
値としてアプリケーションサーバ１０に返送する。

【００４７】プロトコル「照合」は、ユーザホスト２０
またはアプリケーションサーバ１０がシステムユニーク
キー、署名データ、タブレットタイプ、及びメッセージ
ＩＤを照合サーバ３０に送出し、照合動作を行わせるプ
ロトコルである。尚、メッセージＩＤは、先に「照合準
備」プロトコルが発行されている場合にその戻り値とし
て返送されたメッセージＩＤが用いられる。尚、後述す
るように、照合結果はアプリケーションサーバ１０に送
出されるが、その際、このメッセージＩＤはどの利用者
の認証であるかを識別するタグとして使用される。すな
わち、本実施の形態においては、このメッセージＩＤ
は、認証の識別用の番号であると共に、キャッシュに認
証データが既に呼び出されていることをも表すＩＤでも
ある。この場合メッセージＩＤの最初の作成は照合サー
バ３０が行い、照合準備要求に対する応答の時にメッセ
ージに付与されるのである。

【００４８】一方、もし「照合準備」プロトコルが発行
されていない場合には、このメッセージＩＤは、単にど
の利用者に対する認証であるのかを識別する識別子とし
ての役割しか果たさない。この場合はメッセージＩＤの
最初の作成はアプリケーションサーバ２０である。

【００４９】さて、照合サーバ３０は、このメッセージ
ＩＤが自己が付与したものか否かによって、認証データ
が既にキャッシュに読み出されているか否かを知ること
ができる。既に「正しい」認証データが呼び出されてい
る場合には、そのデータと、送られてきた認証データと
を比較・照合する。「正しい」認証データが呼び出され
ていない場合には、ＲＤＢから新たに「正しい」認証デ
ータが呼び出されて、比較・照合動作が行われる。

【００５０】比較・照合の結果、両者が非常に近く正し
い認証データであると判断される場合には、戻り値とし
て「ｙｅｓ」がアプリケーションサーバ１０に送出され
る。一方、送られてきた認証データが「正しい」認証デ
ータと全く異なったものである場合には戻り値として
「ｎｏ」が送出される。比較・照合の結果、正しい認証
データであるか否かが不明な場合は、戻り値として「ｍ
ａｙｂｅ」がアプリケーションサーバ１０に送出され
る。不明な場合の対処は、各アプリケーションサーバ１
０ごとに異なるであろうが、例えば、署名を利用者にや
り直させる等の処置が執られることになろう。また、比
較・照合をする「正しい」認証データが見つからなかっ
た場合等においては、戻り値として「ｅｒｒｏｒ」がア
プリケーションサーバ１０に返送される。

【００５１】次に、実際の利用者の認証が行われる様子
を図６に基づいて説明する。以下、この利用者のことを
アプリケーションクライアントと称する（図６）。ま
ず、アプリケーションクライアントは、ユーザホスト２
０を介してアプリケーションサーバ１０に対して、接続
要求を行う。

【００５２】これに応答してアプリケーションサーバ１
０は、アプリケーションクライアントに対して、アプリ
ケーションキーの入力を要求する。これに応答して、ユ
ーザホスト２０の表示装置上にはアプリケーションキー
の入力を促すプロンプトが表示される。

【００５３】アプリケーションクライアントがユーザホ
スト２０において所定のキーを入力すると、そのデータ
がアプリケーションサーバ１０に送出される。

【００５４】アプリケーションサーバ１０は、このキー
データを受信すると、署名データの照合準備の要求を照
合サーバ３０に送出する。この照合準備要求は、上述し
たように処理の迅速化のために行うものであり、省略す
ることも可能である。

【００５５】照合サーバ３０は照合準備要求を受信する
と、上述したように、認証データをＲＤＢから読み出
し、キャッシュに記憶させると共にアプリケーションサ
ーバ１０に対してメッセージＩＤ、暗号キーを送出す
る。暗号キーは通信データの暗号化に用いられるキーで
あり、暗号化が必要なければ送らなくともよい。

【００５６】上記メッセージＩＤ等を受信したアプリケ
ーションサーバ１０は、アプリケーションクライアント
に署名を入力させるため、署名入力要求を出力する。

【００５７】この署名入力要求に応じてサーバホスト２
０においては署名入力プログラムが起動する。このプロ
グラムの起動に基づき、アプリケーションクライアント
はユーザホスト２０に備えられているタブレット５４を
用いて署名を行う。

【００５８】上記図１（ａ）に対応した構成では、ユー
ザホスト２０は、タブレット５４から入力された署名デ
ータをアプリケーションサーバ１０に送信する。そし
て、アプリケーションサーバ１０は受信した署名データ
を含んだ照合要求を照合サーバ３０に対して発行する。
一方、上記図１（ｂ）に対応した構成では、ユーザホス
ト２０は、タブレット５４から入力された署名データを
照合サーバ３０に送出する（照合要求）。この際、図６
に示されているように、キーデータやメッセージＩＤが
署名データと共に、照合サーバ３０に送出される。

【００５９】照合サーバ３０は、照合要求に基づき、照
合を行い、その結果をアプリケーションサーバ１０に返
送する。照合要求がアプリケーションサーバ１０から送
出されてきた場合には、照合結果の送出先はその照合要
求を出したアプリケーションサーバ１０である。一方、
照合要求がユーザホスト１０から送出されてきた場合に
は、照合要求の際に同時に送られてきたメッセージＩＤ
等に基づいて、照合結果を送出すべきアプリケーション
サーバ１０を特定することになる。

【００６０】アプリケーションサーバ１０は照合結果に
基づき、認証を行う。このときの動作は各アプリケーシ
ョンサーバ１０により異なるが、認証データが一致した
場合には「認証」を与えることになり、一致しない場合
は「認証」を与えない、若しくは署名をやり直させるこ
とになろう。

【００６１】以上述べたように、本実施の形態によれ
ば、認証の際に行われる照合動作を外部の照合サーバに
委託したので、アプリケーションサーバの負荷を減らす
と共に照合動作の簡明化を図ることができ、複数のアプ
リケーションサーバが単一の照合サーバを利用すること
で、ネットワーク上の資源のより効果的な利用につなが
る。

【００６２】

【発明の効果】以上述べたように、第１の本発明によれ
ば、従来各アプリケーションサーバなどが個別に照合動
作を行っていたのに対し、照合サーバで集中的に照合動
作を行ったので、各アプリケーションサーバなどの構成
を簡易にすることができる。そのため、ネットワーク上
の資源の有効活用が図れるとともに、利用者の認証デー
タの集中管理も実現できるという効果を奏する。

【００６３】また、第２の照合サーバによれば、利用者
の識別データだけでなく、所定の他のデータからも認証
データにアクセス可能であるため、識別データを紛失し
ても認証データの確認ができる効果を奏する。

【００６４】また、第３の本発明によれば、迅速な照合
動作の可能な照合サーバが得られる。

【図面の簡単な説明】

【図１】 本発明の実施の形態の構成を表す構成図であ
る。

【図２】 本発明の実施の形態の構成の詳細を表す説明
図である。

【図３】 照合サーバ内のＲＤＢの構成を表す説明図で
ある。

【図４】 アプリケーションサーバ内のＲＤＢの構成を
表す説明図である。

【図５】 照合サーバがサポートするプロトコルを表す
説明図である。

【図６】 本実施の形態におけるメッセージの交換を表
す説明図である。

【符号の説明】

１０ アプリケーションサーバ、２０ ユーザホスト、
３０ 照合サーバ、４２ ＷＷＷサーバ、４４ 署名照
合要求プログラム、５２ ネットスケープ、５４ タブ
レット、５６ タブレットドライバプログラム、６２
登録データ。

Claims (3)

【特許請求の範囲】
1. 【請求項１】 ネットワーク上の利用者の正しい認証デ
   ータを記憶する記憶手段と、 外部からの所定の利用者の認証データに関する照合要求
   に応じて、前記記憶手段から前記所定の利用者の正しい
   認証データを取り出す検索手段と、 前記照合要求に応じて、前記検索手段が取り出した前記
   正しい認証データと、前記照合要求に係る認証データと
   を比較照合する照合手段と、 前記照合の結果を送出する送出手段と、 を含み、前記認証データが前記所定の利用者の認証デー
   タであるか否か照合を行う照合サーバ。
2. 【請求項２】 請求項１記載の照合サーバにおいて、 前記記憶手段は、前記利用者の識別データと、前記利用
   者の前記認証データと、さらに、前記利用者に関して照
   合サーバが要求する所定のデータと、から成るテーブル
   手段を備え、 前記検索手段は、前記利用者の識別データに基づき、前
   記記憶手段から前記正しい認証データを取り出しうると
   ともに、前記所定のデータに基づいても、前記記憶手段
   から前記正しい認証データを取り出しうることを特徴と
   する照合サーバ。
3. 【請求項３】 請求項１記載の照合サーバにおいて、 照合準備要求に応じて、前記利用者の正しい認証データ
   を記憶手段から読み出し、前記記憶手段より読み出し速
   度の速いキャッシュ手段に予め格納しておくキャッシュ
   制御手段、 を含むことを特徴とする照合サーバ。