(57)【要約】【課題】データベースとディレクトリにおいて個別に管理されている属性情報を、統合管理できるようにする。【解決手段】変換プログラム２０は、変更元変更情報と変換先書込先情報をパラメータとして入力し、それらの情報と変換テーブル７０の格納情報を基に、属性ＤＢ１及び属性ディレクトリ３で管理されている該変更元変更情報により指定された属性情報を、ＤＢ系マスタ変換エンジン１５及びディレクトリ変換エンジン１４により変更する。【選択図】　　　図２
2004046733.tif 000002
【特許請求の範囲】
【請求項１】
データベース及びディレクトリに個別に管理されている属性情報を統合管理するための変換ルールを格納している管理手段と、
該管理手段に格納されている変換ルールを参照して、前記データベースまたは前記ディレクトリに管理されている属性情報を変更する変換手段と、
を備えることを特徴とする属性情報統合管理装置。
【請求項２】
前記管理手段は、前記変換ルールを格納する変換テーブルを有し、
該変換テーブルは、前記変換ルールに関する情報として、
変換先のデータベースまたはディレクトリを識別するための情報、及び各データベース及び各ディレクトリの構造情報を格納し、
前記変換手段は、前記識別情報及び前記構造情報を基に、前記変換先のデータベースまたはディレクトリをアクセスすることを特徴とする請求項１記載の属性情報統合管理装置。
【請求項３】
前記変換テーブルは、前記変換ルールに関する情報として、さらに、各データベースまたは各ディレクトリにおいて必要な特殊処理の識別情報を格納し、
前記変換手段は、当該データベースまたは当該ディレクトリに対して前記識別情報により特定される特殊処理を実行することを特徴とすることを請求項２記載の属性情報統合管理装置。
【請求項４】
前記変換テーブルにおいて、対称範囲のデータベース及びディレクトリに共通な情報を一元的なキーとして定義し、
前記変換手段は、前記キーを基に、前記対称範囲のデータベースまたは前記ディレクトリの属性情報の追加または削除を行うことを特徴とする請求項２記載の属性情報統合管理装置。
【請求項５】
データベース及びディレクトリに個別に管理されている属性情報を統合管理するための変換ルールを格納し、
該変換ルールを参照して、前記データベースまたは前記ディレクトリに管理されている属性情報を変更する
ことを特徴とする属性情報統合管理方法。
【請求項６】
データベース及びディレクトリに個別に管理されている属性情報を統合管理するための変換ルールを格納する機能と、
該変換ルールを参照して、前記データベースまたは前記ディレクトリに管理されている属性情報を変更する機能を、
コンピュータに実行させるプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、名前、所属、及び役職などの属性情報を一元的に管理する属性情報管理技術に係わり、特に、電子認証システムのアクセス制御等に好適なものである。
【０００２】
【従来の技術】
例えば、電子認証システムにおいては、アクセス権を制御する判断情報として、名前、組織及び役職などの属性情報が使用される。その他にも、官庁における職員認証、民間企業における社員認証、電子申請におけるＰＫＩ（Ｐｕｂｌｉｃ　Ｋｅｙ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）　電子署名の認証、電子カルテにおけるＰＫＩ電子署名の認証等において属性情報が使用される。
【０００３】
図６は、従来の電子認証システムの構成を示す図である。
同図において、電子認証システム１００の認証サーバ１０２は、属性ＤＢ（属性データベース）１０１により電子認証データを管理しており、クライアント１０４はサーバ１０３にアクセスするためには、認証サーバ１０２から電子証明書を取得する必要がある。また、電子認証システム２００の認証サーバ２０６は、属性ディレクトリ２０１により電子認証データを管理しており、クライアント２０８は、サーバ２０７をアクセスするためには、認証サーバ２０６から電子証明書を取得する必要があるる。また、既存マスタ３０１は、属性ＤＢ１０１や属性ディレクトリ２０１と同様に、属性情報を管理しているファイルである。
【０００４】
同図に示す従来システムにおいては、属性情報は、属性ＤＢ（属性データベース）１０１、属性ディレクトリ２０１、及び既存マスタ３０１などにより、個別に管理されており、属性管理（組織、役職などの属性情報の管理）が一元化されていなかった。これら３種類の管理装置の内、２者を統合しようする場合は、一方を他方に合わせるか、または新規な管理装置を構築するなどの対応が必要であった。　ところで、ディレクトリについては、ディレクトリを一つに統合するメタディレクトリの概念があるが、これはディレクトリのみに対応しており、ＤＢ（データベース）には対応していない。また、これは、電子認証に特定のものではなく汎用的なものであり、電子認証システムに実際に利用するには、個別対応のプログラミングが必要であった。
【０００５】
【発明が解決しようとする課題】
従来システムのように、属性情報が個別の装置により管理されていると、例えば、組織変更や人事異動が発生する度に、多大の労力をかけて、個別の属性ＤＢ１０１や属性ディレクトリ２０１の管理情報を変更する必要があり、コストがかかる、該変更のための所要時間や変更作業に伴う間違いの発生などが問題となる。また、それぞれの属性ディレクトリ２０１または属性ＤＢ１０１を統合するには、既存のシステムに改造が発生し、改造が可能かどうかの問題も生じる。また、前記メタディレクトリの技術はＤＢには適用できず、属性ＤＢ１０１のシステムを統合できないという問題もあった。
【０００６】
本発明は、ＤＢ、ディレクトリ、及び既存マスタに個々に管理されている属性情報に変更が生じた場合、ＤＢ、ディレクトリ、及び既存マスタが管理している該属性情報を容易、高速、かつ確実に一括して変更でき、しかも、既存のシステムを変更することなく、この変更作業を実現可能とすることで、個々のＤＢやディレクトリに管理されている属性情報の一元的な統合管理を実現すると共に、改造コストの削減を図ることを目的とする。
【０００７】
【課題を解決するための手段】
本発明の属性情報統合管理装置は、データベース及びディレクトリに個別に管理されている属性情報を統合管理するための変換ルールを格納している管理手段と、該管理手段に格納されている変換ルールを参照して、前記データベースまたは前記ディレクトリに管理されている属性情報を変更する変換手段とを備える。
【０００８】
上記構成の属性情報統合管理装置において、例えば、前記管理手段は、前記変換ルールを格納する変換テーブルを有し、該変換テーブルは、前記変換ルールに関する情報として、変換先のデータベースまたはディレクトリを識別するための情報、及び各データベース及び各ディレクトリの構造情報を格納し、前記変換手段は、前記識別情報及び前記構造情報を基に、前記変換先のデータベースまたはディレクトリをアクセスするように構成にしてもよい。
【０００９】
また、上記構成の属性情報統合管理装置において、例えば、前記変換テーブルは、例えば、前記変換ルールに関する情報として、さらに、各データベースまたは各ディレクトリにおいて必要な特殊処理の識別情報を格納し、前記変換手段は、当該データベースまたは当該ディレクトリに対して前記識別情報により特定される特殊処理を実行するような構成にしてもよい。
【００１０】
また、上記構成の属性情報統合管理装置において、例えば、前記変換テーブルにおいて、対称範囲のデータベース及びディレクトリに共通な情報を一元的なキーとして定義し、前記変換手段は、前記キーを基に、前記対称範囲のデータベースまたは前記ディレクトリの属性情報の追加または削除を行う構成にしてもよい。
【００１１】
本発明の属性情報統合管理方法は、データベース及びディレクトリに個別に管理されている属性情報を統合管理するための変換ルールを格納し、該変換ルールを参照して、前記データベースまたは前記ディレクトリに管理されている属性情報を変更する。
【００１２】
本発明のプログラムは、データベース及びディレクトリに個別に管理されている属性情報を統合管理するための変換ルールを格納する機能と、該変換ルールを参照して、前記データベースまたは前記ディレクトリに管理されている属性情報を変更する機能をコンピュータに実行させる。
【００１３】
本発明は、データベース及びディレクトリに個別に管理されている属性情報を統合管理するための変換ルールを設け、該変換ルールを参照して、前記データベースまたは前記ディレクトリに管理されている属性情報を変更するようにする。このことにより、データベースとディレクトリに、それぞれ、個別に管理されている属性情報の一括変更が可能となり、データベースとディレクトリの統合管理を実現できる。
【００１４】
以下、図面を参照しながら、本発明の実施形態を説明する。
図１は、本発明の実施形態の属性情報管理装置を適用した電子認証システムのシステム構成を示す図である。
【００１５】
同図において、認証サーバ２は属性ＤＢ（属性データベース）１が管理している情報により、サーバ（アプリサーバ）９のアクセス制御の情報を管理している。認証サーバ５は、属性ディレクトリ３が管理している情報により、サーバ９のアクセス制御の情報を管理している。拡張メタディレクトリ７は、変換ルールにより、属性ＤＢ１、属性ディレクトリ３、及び既存マスタ６を統合して管理している。該変換ルールは、例えば、テーブル（変換テーブル）に記述される。
【００１６】
クライアント８は、サーバ９にアクセスする際は、認証サーバ５を介して属性ディレクトリ３の管理情報からアクセス権限レベルを取得し、サーバ９にそのアクセス権限レベルを渡すことにより、サーバ９で管理しているアクセス権限レベルで許可されている範囲のアクセスが可能となる。
【００１７】
また、拡張メタディレクトリ７により、属性ＤＢ１、属性ディレクトリ３、及び既存マスタ６の情報は等価されているので、クライアント８が認証サーバ２により認証された場合も、上述した認証サーバ５による認証の場合と同様の結果となる。但し、認証サーバ２が、固有の属性情報を管理して、アクセス権限レベルを独自に設定している場合は上記結果は該当しない。
【００１８】
図１と図６を比較すれば分かるように、本実施形態においては、図６の従来システムに拡張メタディレクトリ７を追加し、この拡張メタディレクトリ７が属性ＤＢ１、属性ディレクトリ３及び既存マスタ６を統合管理するような構成となっている。
【００１９】
図２は、図１のシステムのソフトウェア構成図である。
属性ディレクトリ３は、属性マスタ情報、ＰＫＩ（Ｐｕｂｌｉｃ　Ｋｅｙ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）　認証の場合の証明書及び失効リストなどを管理する。属性ＤＢ１は、人事マスタでの人事情報や属性マスタでの所属や役職などの情報を管理する。属性マスタで、過去の属性情報である世代情報を管理している場合もある。
【００２０】
拡張メタディレクトリ７は、属性ディレクトリ３や属性ＤＢ１の内容を更新するための変換ルールを格納している変換テーブル７０を有している。変換プログラム２０は、ディレクトリ変換エンジン１４とＤＢ系マスタ変換エンジン１５を有しており、これのエンジンを起動する。ディレクトリ変換エンジン１４は、ＬＡＰＤ（Ｌｉｇｈｔ　Ｗｅｉｇｈｔ　Ｄｉｒｅｃｔｏｒｙ　Ａｃｃｅｓｓ　Ｐｒｏｔｏｃｏｌ）　を用いて、属性ディレクトリ３の情報をアクセスする。ＤＢ系マスタ変換エンジン１５は、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅ　Ｑｕｅｒｙ　Ｌａｎｇｕａｇｅ）を用いて属性ＤＢ１の情報をアクセスする。
【００２１】
本実施形態の属性情報管理装置は、拡張メタディレクトリ７及び変換プログラム２０（ディレクトリ変換エンジン１４とＤＢ系マスタ変換エンジン１５を含んでいる）で構成される。
【００２２】
尚、認証サーバ２、アプリサーバ９、及びクライアント８は、本発明の実施形態の構成要素ではないので、認証サーバ２、アプリサーバ９のソフトウェア構成の説明は省略する。クライアント８は、ＰＫＩ対応Ｗｅｂブラウザ、メタディレクトリ及びＰＭＩ（Ｐｒｉｖｉｌｅｇｅ　Ｍａｎａｇｅｍｅｎｔ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）　機能に対応したマスタ管理ツール、及びＧＰＫＩ（Ｇｏｖｅｒｎｍｅｎｔ　ＰＫＩ）　対応ＩＣカードが装着されるＩＣカードリーダを備えている。
【００２３】
図３は、変換プログラム２０の入力値（パラメータ）である変換元変更情報の内容を示す図である。
同図に示す変換元変更情報７１は、どの属性情報を変更するか指定する変更属性項目と該変更される属性情報の変更前の情報（変更前情報）並びに変更後の情報（変更後情報）のセットをリストアップしたものであり、変換プログラム２０の入力となる。この変換元変更情報７１は、例えば、ＣＳＶ形式、エクセル（Ｅｘｃｅｌ）の表、ＤＢ、またはディレクトリの変更前情報と変更後情報が指定されたときに、変換プログラム２０に入力される。
【００２４】
尚、ＤＢ情報（属性ＤＢ１の情報）、ディレクトリ情報（属性ディレクトリ３の情報）が、そのまま、変換元変更情報７１となることもある。
図４は、変換テーブル７０の構成を示す図である。
【００２５】
同図（ａ）は、変換テーブル７０に格納される変換ルールを構成する項目を示す図である。
変換テーブル７０は、「変換ＩＤ７０ａ」、「変換先種別７０ｂ（ＤＢまたはディレクトリ）」、「変換先名称７０ｃ」、「ＤＢ及びディレクトリ構造情報７０ｄ」、及び「変換エンジンＩＤ７０ｅ」の５項目で構成されている。
【００２６】
変換ＩＤ７０ａは、各ＤＢまたは各ディレクトリ毎に設定され、変換の識別に用いられる識別子である。変換先種別７０ｂは、変換先がＤＢまたはディレクトリのいずれであるかを示す情報である。変換先名称７０ｃは、変換先であるＤＢまたはディレクトリの名称である。ＤＢ及びディレクトリ構造情報７０ｄは、変換先の属性ＤＢ１のデータベース構造や変換先の属性ディレクトリ３のディレクトリ構造を示す情報である。変換エンジンＩＤ７０ｅは、特殊処理を行う際の特殊処理の識別に用いられる識別子である。該特殊処理は、例えば、変換先のＤＢの構造が正規化されていなかった場合などに必要な処理である。このような場合には、１対１ではなく１対Ｎ（Ｎは２以上の自然数）の変換が必要になる。変換テーブル７０は、１対１の変換を基本としているので、１対Ｎの変換が必要な場合には、特殊処理によりＮ箇所に書き込むようにする。
【００２７】
同図（ｂ）は、前記変換テーブル７０に格納される「ＤＢ及びディレクトリ構造情報７０ｄ」の例を示す図である。同図（ｂ）には、属性ＤＢ１に属するマスタＤＢであるマスタＡ（人事マスタ），Ｂ（属性マスタ）と、属性ディレクトリ３の属性マスタであるディレクトリＡのそれぞれの構造情報が示されている。マスタＡは、例えば、人事マスタであり、そのレコードはキー、属性Ａ，Ｂの３フィールドからなる。また、マスタＢは、例えば、属性マスタであり、そのレコードはキー、属性Ａ，Ｂ，Ｄの４フィールドからなる。ディレクトリＡのオブジェクトは、キー、属性Ａ，Ｂ，Ｃからなる。変換テーブル７０の「変換ＩＤ７０ａ」が属性ＤＢ１のＩＤであれば、該変換テーブル７０の「ＤＢ及びディレクトリ構造情報７０ｄ」には、同図（ａ）に示すマスタＡ（人事マスタ）とマスタＢ（属性マスタ）の構造情報が格納される。
【００２８】
本実施形態では、対称範囲のＤＢ（属性ＤＢ１）及びディレクトリ（属性ディレクトリ３）に共通する一意の情報をキーとして定義する。同図（ｂ）の例では、名前ＩＤがキーとなっている。属性情報は、全てのＤＢ及びディレクトリに共通なものと、個々のＤＢまたはディレクトリに固有なものがある。
【００２９】
図５は、変換プログラム２０の処理の流れを示すフローチャートである。
変換プログラム２０は、変換元変更情報７１及び変換先書込先情報をパラメータとして指定された状態で、変換ＩＤ７０ａ（図４（ａ）参照）単位に、自動または手動で起動される。
【００３０】
まず、「変換情報の読み込み」で、人事異動や組織変更が発生した場合に、図３に示す変更元変更情報７１を読み込む（ステップＳ１）。変更情報は、データ列で示される場合やＤＢまたはディレクトリに格納された形式で示される場合がある。例えば、データ列の場合には、「００１１、山田太郎、職位、課長補佐、課長」のＣＳＶ形式で示される。また、ＤＢの場合には、
2004046733.tif 000003
で示される。
【００３１】また、ディレクトリの場合には、
変更前ディレクトリ　　名前ＩＤ　００１１　山田太郎−−−職位プロパティ課長補佐
変更後ディレクトリ　　名前ＩＤ　００１１　山田太郎−−−職位プロパティ課長
で示される。
【００３２】
この場合は、当該ＤＢまたは当該ディレクトリから、後述するステップＳ３で読み込む情報を基に自動生成する。すなわち、上記ＤＢ及び上記ディレクトリの例の場合には、変更前情報と変更後情報の差分計算を行い、
００１１　山田太郎　変更　職位　変更前　課長補佐　変更後　課長
の情報を自動作成する。
【００３３】
続いて、「変換テーブル読み込み」で、図４（ａ）に示す変換テーブル７０を読み込む（ステップＳ２）。そして、「変換先及び変換先の構造情報読込」で、変換テーブル７０から、「変換先種別７０ｂ」、「変換先名称７０ｃ」及び「ＤＢ及びディレクトリ構造情報７０ｄ」を読み込む（ステップＳ３）。
【００３４】
次に、「変換先書込先情報読込（一時領域など）」で、パラメータとして指定された変換先書込先情報を読み込み、この情報を基に、ステップＳ１で読み込んだ変換元変更情報７１の書き込み領域を特定する（ステップＳ４）。これは、属性情報は、情報の入替え時期が決まっている場合が多く、それ以前は、一時領域や決められた領域書き込んでおいて、指定した時期に運用する（前記変換先書込先情報で指定される領域に、実際に書き込む））ことが多いからである。
【００３５】
続いて、「キーの追加または削除」が有るか判断して、キーの追加または削除」が有る場合には、名前ＩＤをキーにしている場合は、当人が転出などでいなくなる場合または新規に転入する場合などは、ＤＢのレコード追加・削除、ディレクトリの属性追加を行う（ステップＳ６）。
【００３６】
ステップＳ５でキーの追加または削除が無いと判断された場合またはステップＳ６の処理の後に、「変換元変更情報及び構造情報から該当情報を変換先書込先に書込」で、ステップＳ１で読み込んだ変換元変更情報を基に、ステップＳ３で読み込んだ構造情報及びステップＳ４で読み込んだ変換先書き込み先情報を利用して、ステップＳ２で読み込んだ「変換先種別７０ｂ」（図４（ａ）参照）に従い、変換先がＤＢの場合は、ディレクトリ変換エンジン１４によりＬＤＡＰを用いて当該ディレクトリ（属性ディレクトリ３）の当該情報をアクセスし、変換先がＤＢの場合は、ＤＢ系マスタ変換エンジン１５によりＳＱＬを用いて当該ＤＢ（属性ＤＢ１）の当該情報をアクセスし、それらの当該情報を指定された変更後情報に変更する（ステップＳ７）。尚、このステップＳ７においては、必要に応じて、ディレクトリ変換エンジン１４とＤＢ系マスタ変換エンジン１５の両者が実行される。
【００３７】
そして、最後に、「変換エンジンＩＤ読込み特殊処理を実行」で、ステップＳ２で読み込んだ変換ＩＤ７０ａ（図４（ａ）参照）で指定された特殊処理がある場合には当該特殊処理を実行する（ステップＳ８）。前述したように、特殊処理は、変換先のＤＢの構造が正規化されていない場合などのように、１対Ｎの変換が必要な場合に行われる。したがって、変換元と変換先が１対１の場合には、特殊処理は不要である。
【００３８】
以上のようにして、ステップＳ７とＳ８の処理により、ディレクトリとＤＢの属性情報（両者に共通な属性情報）の一括変換がなされる。
この一括変換処理の具体例を、図４（ｂ）のマスタＡから、ディレクトリＡとマスタＢに一括変換する場合を取り上げて説明する。
【００３９】
属性Ａを職位とした場合、マスタＡの属性Ａは「課長」、ディレクトリＡとマスタＢの属性Ａは「課長補佐」になっているものとする。
この場合、変更前のマスタＡの属性Ａは「課長補佐」になっているので、
「００１１山田太郎　変更　職位　変更前　課長補佐　変更後　課長」
という情報を自動作成して、ディレクトリ変換エンジン１４でディレクトリＡの属性Ａを「課長」に、ＤＢ系マスタ変換エンジン１５でマスタＢの属性Ａを「課長」に書き換える。
【００４０】
尚、属性ＤＢ１の属性マスタＤＢ（図２参照）で管理されている世代情報を、ディレクトリ（属性ディレクトリ３）を参照しているサーバで参照したい場合には、予め、旧世代用の書き込み領域（変換先書込先）を用意して、ステップＳ１で読み込む変更元変更情報７１を入力元、ステップＳ４で読み込む変換先書込先を出力先として、変換プログラム２０を実行することにより、ディレクトリに上記世代情報が格納される。
【００４１】
本発明は、下記の属性管理等に適用できる。
１）　官庁における職員認証での属性管理
２）　民間企業における社員認証での社員の属性管理
３）　電子申請におけるＰＫＩ電子署名の認証対象者の属性管理
４）　電子入札におけるＰＫＩ電子署名の認証対象者の属性管理
５）　電子カルテにおけるＰＫＩ電子署名の認証対象者及びアクセス者の属性管
理
６）　電子商取引における参加企業または個人の属性管理
また、本実施形態の変換プログラム２０及び拡張メタディレクトリ７は、各種規格のＣＤ，各種規格のＤＶＤ，フレキシブルディスク、光ディスク、光磁気ディスク、メモリーカード、ＲＯＭカード等の可搬性の記録媒体により頒布することも可能である。また、有線または無線の通信を介して、頒布することも可能である。また、変換プログラム２０と拡張メタディレクトリ７は、別個の可搬記録媒体により頒布されてもよい。そして、このようにして頒布された変換プログラム２０及び拡張メタディレクトリ７は、コンピュータにより実行されて、上述した本実施形態の各機能をコンピュータに実行させる。
【００４２】
尚、本発明が適用されるデータベースは、リレーショナルデータベースに限定されず、本発明は、例えば、オブジェクト指向データベースなどの他の形態のデータベースで管理される属性情報の管理にも適用可能である。
【００４３】
【発明の効果】
以上説明したように、本発明によれば、ディレクトリとデータベースを統合して一括管理する拡張メタディレクトリに、該ディレクトリの情報と該データベースの情報を統合変換するための変換ルールを格納し、ディレクトリアクセス用の変換エンジンとデータベースアクセス用の変換エンジンにより、変更情報を、一括して当該ディレクトリと当該データベースに書き込むことにより、ディレクトリの管理する属性情報とデータベースの管理する属性情報の等価を図るので、ディレクトリとデータベースに共通する属性情報を、容易、高速、かつ確実に一括変更できる。また、既存のシステムに変更を加えることなく、ディレクトリの属性情報とデータベースの属性情報を統合管理でき、改造コストの削減を図ることができる。
【図面の簡単な説明】
【図１】本発明の実施形態を適用した電子署名システムの構成を示す図である。
【図２】図１の実施形態のソフトウェア構成を示す図である。
【図３】変更元変更情報のデータ構造を示す図である。
【図４】変換テーブルの構成を説明する図である。
【図５】変換プログラムの処理の流れを説明する図である。
【図６】従来の電子署名システムの構成を示す図である。
【符号の説明】
３　　　属性ディレクトリ
６　　　既存マスタ
７　　　拡張メタディレクトリ
１４　　ディレクトリ変換エンジン
１５　　ＤＢ系マスタ変換エンジン
２０　　変換プログラム
７０　　変換テーブル
７０ａ　　変換ＩＤ
７０ｂ　　変換先種別
７０ｃ　　変換先名称
７０ｄ　　ＤＢ及びディレクトリ構造情報
７０ｅ　　変換エンジンＩＤ
７１　　変更元変更情報
７２　　ＤＢ及びディレクトリ構造情報
７２ａ　　マスタＡ構造
７２ｂ　　ディレクトリＡ構造
７２ｃ　　マスタＢ構造
【図１】
2004046733.tif 000004
【図２】
2004046733.tif 000005
【図３】
2004046733.tif 000006
【図４】
2004046733.tif 000007
【図５】
2004046733.tif 000008
【図６】
2004046733.tif 000009
【手続補正書】
【提出日】平成14年7月25日(2002.7.25)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】００１４
【補正方法】変更
【補正の内容】
【００１４】
【発明の実施の形態】
以下、図面を参照しながら、本発明の実施形態を説明する。
図１は、本発明の実施形態の属性情報管理装置を適用した電子認証システムのシステム構成を示す図である。