JP2002259219A

JP2002259219A - 通信ネットワーク上の利用者識別方法及び識別システム

Info

Publication number: JP2002259219A
Application number: JP2001054804A
Authority: JP
Inventors: Yasushi Abe; 靖阿部
Original assignee: e-machitown Co Ltd
Current assignee: e-machitown Co Ltd
Priority date: 2001-02-28
Filing date: 2001-02-28
Publication date: 2002-09-13

Abstract

(57)【要約】【課題】ｅ-mailアドレスや、公開ＷｅｂページのＵＲ
Ｌ、ＩＰアドレス、携帯電話番号といったインターネッ
ト上で使用されたアドレスが変更されても、その個人を
見失わず継続的に利用者を認識できる方法及びシステム
を提供する。【解決手段】利用者が任意に特定可能なニックネーム
と、通信ネットワーク上での利用者管理システムにより
割り振られた当該管理システムから利用者への一方向性
を有する利用者チェック情報とを組み合わせて利用者に
対してネットワーク上で一意の利用者識別子を付与し、
当該利用者識別子と利用者の個人情報とを関連付け、利
用者識別子から特定された利用者の個人情報から利用者
を識別可能とする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本願発明は、ネットワーク上
における利用者の識別を一意に特定できる方法及びシス
テムに関する。特に本願発明は、特にインターネット上
のｅ−ｍａｉｌやＷｅｂ提供者等のネット利用者の識別
を可能とする方法及びシステムに関する。

【０００２】

【従来の技術】近年、インターネットを代表とするネッ
トワークの利用者が急増している。ネットワークを利用
する場合には、その利用者の固有の識別情報を取得し、
その識別情報をもとに利用者を特定する。

【０００３】例えば、インターネットを利用する場合、
通常ＴＣＰ/ＩＰプロトコルに従い付されたこの個人識
別情報としてのＩＰアドレスをネット利用者が保有し、
そのＩＰアドレスを利用して自己を特定し、ｅ−ｍａｉ
ｌやＷｅｂ上へのホームページの掲載等の利用を図って
いる。

【０００４】ＩＰアドレスは、利用者固有の識別情報と
して、一般に４バイトの数値の集合として付与されたも
のであることから、実際の利用者にとってもわかりずら
く、不便でもある。このことから、e-ｍａｉｌアドレス
等、利用者が容易に認識しやすい一意の名前がＩＰアド
レスに対応して付され、実際の使用においては利用者は
その名前を利用することとなるため、利用者は特に意識
をする必要がない。

【０００５】しかしながら、利用するプロバイダーを変
える等の様々な原因から、このｅ−ｍａｉｌアドレスや
ＩＰアドレスが変更される場合が少なくない。このよう
な変更がされると、ｅ−ｍａｉｌアドレスやＩＰアドレ
スをもとにしたネットワーク上での利用者の特定が不可
能となり、これまでその利用者と情報の授受を行ってい
たサービス業者や個人は、ネットワーク上からその利用
者を見失い、相互のコミュニケーション手段が絶たれ、
それまで蓄えられていたその利用者に関するプロファイ
ルや利用履歴といった様々な貴重な情報の活用もできな
くなるといった問題を生じていた。

【０００６】ここで近年、電子メールアドレスやＩＰア
ドレスの他、住所、性別、電話番号、勤務先、所属等の
個人のプロファイルに関するものを、インターネット上
で利用できるようにするディレクトリサービスが関心を
持たれている。

【０００７】このようなディレクトリサービスとして、
例えば、Ｘ．５００プロトコルやそのサブセットである
ＬＤＡＰプロトコルに従ったディレクトリサービスの利
用がある。

【０００８】

【発明が解決しようとする課題】しかしながら、このよ
うなディレクトリサービスの利用によっても、尚まだネ
ットワーク上において個人を特定するために基本的な識
別情報であるＩＰアドレスやｅ−ｍａｉｌアドレス、ド
メイン名、ＵＲＬといった情報が変更されると、ネット
ワーク上での個人が行方不明となり、継続的なコミュニ
ケーション及び継続的な情報の活用が図れないといった
問題点を有していた。

【０００９】本発明は、かかる問題点に着目してなされ
たものであり、ネットワーク上での利用者を識別するた
めの識別情報が変更されても、なおその利用者の特定が
可能であり、その結果、継続したコミュニケーションが
図られ、それまでネットワークの利用を介して得られた
その個人のプロファイルや従来使用してきたＩＰアドレ
ス、ｅ−ｍａｉｌアドレスいった様々な情報も無駄にす
ることなく、そのアドレスに付随して蓄えられた情報の
継続的な活用も図られる新たな方法及び手段を提供する
ものである。

【００１０】

【課題を解決するための手段】本願発明は、利用者が任
意に特定可能なニックネームと、通信ネットワーク上で
の利用者管理システムにより割り振られた当該管理シス
テムから利用者への一方向性を有する利用者チェック情
報とを組み合わせて利用者に対してネットワーク上で一
意の利用者識別子を付与し、当該利用者識別子と利用者
の個人情報とを関連付け、もって利用者識別子から特定
された利用者の個人情報によって、利用者を識別可能と
したものである。

【００１１】また、本願発明は、上記によって付与され
た利用者識別子の情報を有する管理サーバシステムから
なる利用者識別情報システムであって、その管理サーバ
システムは、利用者識別子とその値に対応して関連付け
られた個人情報とを格納し、当該システムは、利用者か
ら受けた利用者識別子に応じて個人を特定できるように
した通信ネットワーク上の利用者識別システムを提供す
る。

【００１２】好ましくは、上記利用者チェック情報は、
システムが同一のニックネームに対して個々に異なるよ
うにシステム内部で管理する個別情報を含む。

【００１３】更に好ましいのは、その利用者チェック情
報は、ニックネームから一方向関数によって導かれるニ
ックネーム依存情報を含み、例えば、ニックネームの符
号値の総和から所定の素数で割った余りである。

【００１４】オブジェクト形式でのインターネット上で
のディレクトリサービスを行うために、前記利用者識別
子と個人情報とを少なくとも属性とした利用者のオブジ
ェクトを定義し、前記利用者識別子をＬＤＡＰのＤＳＡ
に構築する。従って、管理サーバシステムは、ＬＤＡＰ
プロトコルに従ったディレクトリサービスとなる。

【００１５】一方、より大量の個人情報を追加更新可能
なシステムを提供するために、リレーショナルなデータ
デースを構築する。このリレーショナルデータベースの
属性には、前記利用者識別子と個人情報とを少なくとも
含むようにする。

【００１６】

【発明の実施の形態】以下、本願発明の実施の形態につ
いて説明する。

【００１７】利用者には、インターネットのＴＣＰ／Ｉ
Ｐプロトコルに従ったＩＰアドレスやそのＩＰアドレス
をベースにして構成されたｅ−ｍａｉｌアドレスやメー
リング名、利用者がネットワークを使用する際に必要と
されている識別子とは別の利用者固有の識別子（以下
“インターネットＩＤ(internetID)”という）が付与さ
れる。

【００１８】このインターネットＩＤは、ＩＰアドレス
には依存しないインターネット等のネットワーク上で一
意な名前であり、従って、利用者がインターネット上で
利用するプロバイダーやメールアドレスにも依存せず、
利用者個人を特定するための文字列の組み合わせからな
る識別子である。

【００１９】このインターネットＩＤには、システム上
で管理に使用するためのフルフォーマット形式のインタ
ーネットＩＤ（以下、省略して「フルインターネットＩ
Ｄ」（full-internetID）ともいう）と、利用者が一般
的に利用するためのサブセット形式のインターネットＩ
Ｄ（以下、省略して「サブセットインターネットＩＤ」
（subset-internetID）ともいう）の２種類が存在す
る。

【００２０】フルインターネットＩＤ（full-internetI
D）は、例えば、システム(systemID)、日付（date)、ニ
ックネーム(nickname)、チェックフラグ(checkflag)の
各属性から構成される。

【００２１】システム(systemID)は、利用するシステム
に応じて予め割り当てられる。

【００２２】ニックネーム(nickname)は、利用者が自己
を特定するために使用される任意の文字列からなる組み
合わせである。システム、ニックネームとも通常、アル
ファベット及び数字からなるＡＳＣＩＩキャラクタの組
み合わせを使用することができる。

【００２３】ここで、ニックネーム(nickname)は、利用
者が任意に指定することができる識別子であることか
ら、異なった利用者が同じニックネームを指定すること
があり得る。この場合に備えてチェックフラグ(checkfl
ag)が利用される。

【００２４】チェックフラグ(checkflag)は、利用者が
指定したニックネーム(nickname)と、システムの管理者
が管理可能なデータとから一方向性の関数で導出できる
利用者チェック情報である。

【００２５】このニックネーム(nickname)とチェックフ
ラグ(checkflag)とを組み合わせて構成されるサブセッ
ト形式のインターネットＩＤ（subset-internetID）
は、利用するシステム上で一意の値を有するように構成
されており、利用者識別子となるインターネットＩＤ
（subset-internetID）を特定することで、利用者を識
別することが可能となる。

【００２６】サブセット形式のインターネットＩＤ（su
bset-internetID）を一意に保つために、システム内で
は、システムの管理者が管理可能なデータとして、例え
ば、ユニットナンバー(unitnumber)とチェックサム(che
cksum)が使用される。

【００２７】ユニットナンバー(unitnumber)は、同一の
ニックネーム(nickname)が複数あった場合に、システム
内で個別の異なる符号となるように設定される個別情報
である。

【００２８】チェックサム(checksum)は、ニックネーム
(nickname)に依存する情報であって、ニックネーム(nic
kname)から一意に導出できるが、チェックサムそれ自身
からニックネームへの反対方向には一意には導出できな
い、一方向性を有するように決められた符号であって、
例えばニックネーム(nickname)の符号値を基に得られた
値を更にある素数で割ったその余りの値である。

【００２９】そして、インターネットＩＤで使用される
チェックフラグ(checkflag)は、ユニットナンバー(unit
number)とチェックサム(checksum)とで構成されるよう
にしている。

【００３０】チェックサム(checksum)はニックネーム(n
ickname)に依存し、しかも、ユニットナンバー(unitnum
ber)は、同一のニックネームに応じて異なるように割り
振られているために、チェックフラグ(checkflag)とニ
ックネーム(nickname)から構成されるサブセット形式の
インターネットＩＤ（subset-internetID）は、一意の
値を示すこととなり、利用するシステム内での利用者の
識別が可能となる。

【００３１】更に、フルフォーマットのインターネット
ＩＤには、その値に応じて対応する日付(date)や個人情
報がシステム内で関連付けされている。

【００３２】日付(date)は、通常システム上において利
用者のインターネットＩＤがアサインされた日付や、限
定された使用期間、インターネットＩＤの利用が不可能
となる日付等のシステム管理上必要となるあるいは有用
な期間や期日等として定義され、その使用の目的に応じ
て複数の日付けを設けるようにしてもよい。

【００３３】個人情報は、例えば、e-mailアドレスや、
公開ＷｅｂページのＵＲＬ、ＩＰアドレス、携帯電話番
号、その他、住所や性別といった利用者固有のプロファ
イル情報やインターネットＩＤによって関連付け可能な
付随した情報等である。これらの情報は、インターネッ
トＩＤの使用目的に応じて選択され、追加され得る。

【００３４】図１は、本願発明を適用可能なシステム構
成の概要を示している。これによってインターネットＩ
Ｄ及びそこに含まれるニックネームとチェックフラグが
いかにシステム上で利用され、利用者を特定できるかと
いった相互の関係を明らかとする。

【００３５】利用者が利用するクライアントＰＣ（図示
せず）は、インターネットＩＤを管理する管理サーバ１
０にインターネットやその他の双方向通信ネットワーク
（図示せず）を介して接続可能である。

【００３６】管理サーバ１０は、フルフォーマットのイ
ンターネットＩＤとそれに対応する個人情報をディレク
トリファイル又はその他のファイル形式によってデータ
ベース（ＤＢ）として格納するためのディスク、半導体
メモリー等の記憶手段１１を有し、管理サーバシステム
１を構成している。

【００３７】また、管理サーバシステム１には、更に記
憶手段１１に格納されるインターネットＩＤの登録や関
連する情報の更新等を行うための処理部（図示せず）を
有したアカウントセンター１２と、そのインターネット
ＩＤを利用した各種サービスを提供するよう処理するサ
ービスサーバ１３を設けることができる。そして、アカ
ウントセンター１２とサービスサーバ１３には、認証モ
ジュール１５ａ、１５ｂがマウントされ、あるいは別個
の認証サーバ（図示せず）が設けられる。

【００３８】認証モジュール１５ａ、１５ｂはそれぞ
れ、アカウントセンター１２における情報の更新を行う
際の利用者や更新管理者の認証、サービスサーバによる
利用者の各種サービスの提供を行う際の利用者の認証を
行う。

【００３９】例えば、利用者が管理サーバ１０にアクセ
スすると、その利用の目的に応じて管理サーバ１０は、
認証モジュール１５ａ又は認証サーバにアクセスした利
用者から受けたパスワードと識別コードとを送信する。
認証モジュール１５ａ又は認証サーバは、その値と予め
登録した利用者のパスワード及び識別コードとを対比
し、夫々の一致性を検証する。そして、利用者の検証結
果を管理サーバ１０に返す。管理サーバ１０は、正当な
利用者に対してのみアクセスを許可し、利用者は先に示
したようなインターネットＩＤに応じた利用者の情報を
得ることが可能となる。

【００４０】この認証モジュール１５ａ、１５ｂ又は認
証サーバは、その要求するセキュリティに応じた認証方
法を採ることができ、また、認証レベルを設定し、利用
者に提供できる情報に差を設けるようにしてもよい。

【００４１】記憶手段１１内のインターネットＩＤに関
連する情報を含んだデータベース（ＤＢ）は、ニックネ
ームとチェックフラグとを含んだインターネットＩＤ、
更には個人情報を少なくとも含む。

【００４２】ディレクトリファイル形式で格納する場合
の一例としては、好ましくは、チェックサム(checksu
m)、ユニットナンバー(unitnumber)、及びニックネーム
とチェックフラグとを含んだフルフォーマットのインタ
ーネットＩＤ、更には個人情報とをディレクトリ構造に
構築する。このディレクトリ階層を辿ることで、利用者
は使用するサブセットのインターネットＩＤに基づき、
フルフォーマットのインターネットＩＤに付随した個人
情報を取得することが可能となる。

【００４３】データベース形式、特にその取り扱いが容
易なリレーショナルデータベース形式に基づく格納を行
う場合には、チェックサム(checksum)、ユニットナンバ
ー(unitnumber)、ニックネーム(nickname)、そしてフル
フォーマットのインターネットＩＤ及びそれに関連する
個人情報とをテーブルの属性として定義する。利用者
は、使用するサブセットのインターネットＩＤをキーと
して、フルフォーマットのインターネットＩＤに付随し
た個人情報を取得することが可能となる。

【００４４】このように、管理サーバ１０は、サブセッ
トのインターネットＩＤの構成要素であるニックネーム
(nickname)及びチェックフラグ（checkflag)から、ディ
レクトリファイル又はデータベースファイルをもとにし
て、フルフォーマットのインターネットＩＤを特定する
ことができる。

【００４５】また、ニックネーム(nickname)のみしかわ
からない場合でも、そのニックネームに関連するインタ
ーネットＩＤを抽出することも可能である。インターネ
ットＩＤには、その値に応じて個人情報が付随されてい
るために、例えばその付随情報をデータベースあるいは
ディレクトリベースの属性として持ち、そのインターネ
ットＩＤに応じた全ての付随情報、すなわち関連する利
用者を検索し、あるいは特定し、その結果利用者の識別
を図ることができる。

【００４６】

【実施例】次ぎに、インターネットＩＤによる利用者の
識別を行うための具体的実施例を説明する。

【００４７】フルフォーマット形式のインターネットＩ
Ｄ（full-internetID）と、サブセット形式のインター
ネットＩＤ（subset-internetID）の構文及び利用する
符号は、例えばＢＮＦ定義法によって以下のように定義
することができる。

【００４８】[符号の定義] <ALPHA> ::='a'|'b'|'c'|'d'|'e'|'f'|'g'|'h'|'i'|'j'
|'k'|'l'|'m'|'n'|'o'|'p'|'q'|'r'|'s'|'t'|'u'|'v'|'
w'|'x'|'y'|'z'|'A'|'B'|'C'|'D'|'E'|'F'|'G'|'H'|'I'
|'J'|'K'|'L'|'M'|'N'|'O'|'P'|'Q'|'R'|'S'|'T'|'U'|'
V'|'W'|'X'|'Y'|'Z' <ALPHA2> ::='a'|'b'|'c'|'d'|'e'|'f'|'g'|'h'|'k'|'
m'|'n'|'p'|'r'|'s'|'t'|'A'|'B'|'C'|'D'|'E'|'F'|'G'
|'H'|'K'|'M'|'N'|'P'|'R'|'S'|'T' <NUMBER>:=='0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'|'8'|'9' <HEX-DIGIT>:==<NUMBER>|'a'|'b'|'c'|'d'|'e'|'f'|'A'
|'B'|'C'|'D'|'E'|'F'尚、大文字、小文字ともシステム
内部では、全て小文字に変換されるよう使用される。

【００４９】[データ定義] <internetID>::==<systemID>'−'<date>'−'<nickname
>'−'<checkflag>|<subset-internetID>:==<nickname>'
−'<checkflag> ここで、“|”前がフルインターネットＩＤであり、
“|”後がサブセットインターネットＩＤを示してい
る。

【００５０】<YEAR>:==<NUMBER><NUMBER><NUMBER><NUMB
ER> <MONTH>:==<NUMBER><NUMBER> <DATE>:==<NUMBER><NUMBER> <systemID>:==<ALPHA><HEX-DIGIT><HEX-DIGIT> <date>:==<YEAR><MONTH><DATE> <nickname>:==<ALPHA>*32 <chekflag>:==<unitnumber><checksum> <unitnumber>:==<ALPHA2><ALPHA2><NUMBER> 上記実施例では、ニックネーム(nickname)は、最低３個
から最高３２個までのＡＳＣＩＩキャラクタで構成され
ることを示しており、利用者によって任意に選択し決定
することができる。但し、一度決定されたニックネーム
(nickname)は、その後その利用者個人に付随し、利用者
のｅ−ｍａｉｌアドレスやｗｅｂ上の公開ＵＲＬ等の利
用者に付随する情報内容が更新されたり追加されるなど
の変更があっても原則として変わることがない。

【００５１】利用者が利用するサブセットインターネッ
トＩＤに含まれることとなるチェックフラグ(checkfla
g)は、ユニットナンバー(unitnumber)とニックネーム(n
ickname)に応じて計算されるチェックサム(checksum)と
から構成される。

【００５２】ここで、ユニットナンバー(unitnumber)
は、同一のニックネーム(nickname)がシステム上で複数
存在する場合に、個人を特定するためにサブセットイン
ターネットＩＤが一意になるよう定められる。ここで
は、“aa0”から始まり“tt9”までの２２５０個の組み
合わせが可能であることを示している。従って、２２５
０個の同一のニックネーム(nickname)をシステム上に収
納する事が可能となる。

【００５３】チェックサム(checksum)はニックネーム(n
ickname)とユニットナンバー(unitnumber)の実際の入力
値を確認し、その値の妥当性を検証することを目的とす
るものである。具体的なチェックサムの計算は、ニック
ネーム(nickname)で使用されるＡＳＣＩＩ値を総和し、
その総和を素数１３で割った余りである。これによっ
て、ニックネーム(nickname)とユニットナンバー(unitn
umber)の入力値の間違いを検査し、事前にインターネッ
トＩＤの妥当性を判断することができる。

【００５４】更に、システム内で管理使用するフルイン
ターネットＩＤ（full-internetID）には、利用者に付
随するｅ−ｍａｉｌアドレスや、ＵＲＬ、インターネッ
ト利用を可能とする携帯電話にアサインされたＩＰアド
レスやその携帯電話番号、顧客のプロファイル情報、利
用者同士のリレーション情報等の個人情報を関連させる
ことができるため、サブセットインターネットＩＤから
利用者の個人情報を検索することが可能となる。

【００５５】[ＬＤＡＰによるディレクトリサービスへ
の適用］図１で示したよう管理サーバシステム１は、
Ｘ．５００やＸ．５００のサブセットであるＬＤＡＰの
ディレクトリサーバシステムのＤＳＡ（ディレクトリシ
ステムエージェント）として上記インターネットＩＤに
関連する情報を収納し管理することができる。管理サー
バ１１のデータベース（ＤＢ）には、そのためのディレ
クトリ情報を格納している。以下、ディレクトリサーバ
というときには、データベースを含めたＬＤＡＰディレ
クトリサーバを意味する。

【００５６】ディレクトリサーバには、インターネット
ＩＤに関する基本属性スキーマとして、システム“crfh
lidsystemID”、ニックネーム“crfhlidnickname”、ユ
ニットナンバー“crfhlidunitnumberValue”、チェック
サム“crfhlidchecksumValue”の他、個人情報“crfhlh
iduserInfo”、インターネットＩＤが使用可能かどうか
を表すイネーブル“crflidenable”、利用者認証のため
のパスワード“crfhlidpassword”に関する属性が定義
される。尚、“”で囲まれたパラメータが夫々の属性を
表しており、各属性の頭の“crfhlid”は、この利用者
識別のためのＬＤＡＰディレクトリサービスの運用に使
用するために属性スキーマで定義された属性であること
を示している。

【００５７】インターネットＩＤのエントリ構造スキー
マに基づくオブジェクト定義においては、スーパクラス
であるインターネットＩＤ(internetID）、更にユニッ
トナンバー(unitnumber)及びチェックサム(checksum)に
関する識別名（ＤＮ）がそれぞれ定義される。

【００５８】スーパークラスであるインターネットＩＤ
には、先の属性スキーマで定義した“crfhlidsystemI
D”、“crfhlidunitnumberValue”、“crfhlidchecksum
Value”を属性として含んでいる。

【００５９】ユニットナンバー(unitnumber)及びチェッ
クサム(checksum)に関する属性リストは、それぞれ“cr
fhlidunitnumberValue”、“crfhlidchecksumValue”で
ある。

【００６０】ディレクトリ構造スキーマとしては、ディ
レクトリサーバ２３には、例えば図２に示すようなツリ
ーの階層構造をなすディレクトリ情報が格納されてい
る。

【００６１】最上位のｒｏｏｔ（ルート）の下には、ｃ
＝ｊｐ＠ｏ＝ｐｅｏｐｌｅの階層構造を有し、そのオル
ガニゼーションをトップとして、チェックサム(checksu
m)、ユニットナンバー（unitnumber）が配置され、更に
その下層にインターネットＩＤ(internetID）、更にそ
の下層にそのフルフォーマット形式のインターネットＩ
Ｄ(internetID）に応じて関連付けされた利用者の個人
情報がディレクトリとして構成される。この個人情報
は、既に説明したｅ−ｍａｉｌアドレスや、ＵＲＬ等の
利用者に関連する多様な情報を含む。尚、フルフォーマ
ットのインターネットＩＤには、システム（systemID)
が特定できることから、それによってディレクトリサー
ビスにおいて利用されるシステムが明らかとなる。

【００６２】ｏｕ＝ｐｅｏｐｌｅの下の比較的上層の階
層において、チェックサム(checksum)及びユニットナン
バー（unitnumber）を配置しているのは、これらはサブ
セットのｉｎｔｅｒｎｅｔＩＤに含まれる情報であるこ
とから、その情報を使用することで比較的浅い階層での
検索を可能とし、その結果、最下層までのエントリへの
検索を節約することができるからである。また、ディレ
クトリエントリが肥大化した場合でも、ユニットナンバ
ー（unitnumber）毎のディレクトリ分割や、あるいは同
一ユニットナンバー（unitnumber）内でチェックサムや
その他のエントリに応じた分割を行うことで、検索のた
めの深さを一定に保ち、検索で参照することとなるサー
バの数を押さえることができる。

【００６３】更に、チェックサム(checksum)を第１のツ
リーにしているのは、チェックサム値の分布によるデー
タの均一化を図るものである。すなわち、チェックサム
は、１３の素数で分割したその余りを示したものである
ことから、０〜１２までの値は均等化されるため、ｃ＝
ｊｐ＠ｏ＝ｐｅｏｐｌｅの下位のディレクトリへのアク
セスが平均化される。一方、ユニットナンバーをチェッ
クサムの代わりに配置した場合には、ユニットナンバー
＝ａａ０〜ｔｔ９までの２２５０個のディレクトリ情報
のうちの一部の特定のユニットナンバーのアクセスが集
中し、一利用者にかかる検索コストが平均化されないお
それがある。尚、この例では、チェックサムの下位にユ
ニットナンバー（unitnumber）を配置しているが、ディ
レクトリ情報が肥大化した場合には、別なディレクトリ
構造を採るようにしてもよい。

【００６４】いま、ＬＤＡＰ検索フィルタによるインタ
ーネットＩＤのエントリ検索を考える。例えば、 RDN search=`(&(objectclass=internetID)(ou=poeple)
(unitnumber=aa0)(chekusum=1)(internetID=hogehoge-a
a01))' による検索の場合には、インターネットＩＤ(internetI
D)=hogehoge-aa01に関連するエントリを検索することが
できる。

【００６５】一方、ニックネーム(nickname)しかわから
ない場合でも、 RDN search=`(&(objectclass=internetID)(ou=poeple)
(nickname=hogehoge))' による検索式によって、hogehogeのニックネームを有す
る全てのエントリを検索することができる。また、ユニ
ットナンバー(unitnumber)=aa0、とチェックサム(check
sum)=1、はわかっているが、ニックネームのうちの一
部、例えばhogeのみしかわからない場合でも、 RDN search=`(&(objectclass=internetID)(ou=poeple)
(unitnumber=aa0)(chekusum=1)(nickname=hoge*))' による検索式でこれに関連するエントリを取得すること
ができる。

【００６６】尚、上記例による検索式では、ｉｎｔｅｒ
ｎｅｔＩＤのみを使用しているが、その他の個人情報等
を使用することで、該当する可能性のある利用者を特定
する事が可能であることは明らかであろう。

【００６７】［リレーショナルデータベースへの適用］
図３は、管理サーバシステム１における記憶手段１１に
格納されたリレーショナルデータベース構造の一例を示
している。

【００６８】リレーショナルデータベースシステムは、
目的に応じて属性を組み合わせ、関連する情報をテーブ
ル形式に構成したものである。そしてそのテーブルは、
絶対的なものでないことから、幾つかのテーブルを更に
追加し、相互に関連づけて統合するいわゆるデータベー
スモデルを構築することができる。

【００６９】従って、図３に示したテーブル構造も、そ
の目的やシステム環境に応じて適宜異なる。

【００７０】データベースで使用される属性は、ＬＤＡ
Ｐと同様に、この例では、システム“crfhlidsystemI
D”、ニックネーム“crfhlidnickname”、ユニットナン
バー“crfhlidunitnumberValue”、チェックサム“crfh
lidchecksumValue”の他、個人情報“crfhliduserInf
o”、インターネットＩＤが使用可能かどうかを表すイ
ネーブル“crfhlidenable”、利用者認証のためのパス
ワード“crfhlidpassword”に関する属性を定義するこ
とができる。尚、“”で囲まれたパラメータが夫々の属
性を表している。

【００７１】但し、データベースの検索を比較的容易に
するために、フルフォーマットインターネットＩＤとし
て、“crfhlidsystemID”、日付“date”、ニックネー
ム“crfhlidnickname”、ユニットナンバー“crfhlidun
itnumberValue”、及びチェックサム“crfhlidchecksum
Value”の各属性をあわせた“crfhlidfull-internetI
D”の属性を定義することで、フルフォーマットのイン
ターネットＩＤを示すようにしてもよい。

【００７２】また、ニックネーム“crfhlidnickname”
とユニットナンバー“crfhlidunitnumberValue”及びチ
ェックサム“crfhlidchecksumValue”をあわせた属性を
“crfhlidsubsetinternetID”と定義し、サブセットフ
ォーマットのインターネットＩＤを示す新たな属性とし
てもよい。

【００７３】全ての情報を一つのデータベースで管理す
ることは、データベースシステムの負荷を増大させるこ
ととなる。従って、ＬＤＡＰでチェックサムに応じてデ
ィレクトリ分割する考えをデータベースの構築において
も適用する。図３は、チェックサム(checksum)＝０〜１
２の異なる値に応じて、データベースを分割したデータ
ベース構造の概要図である。

【００７４】この分割したデータベース（ｔａｂｌｅ１
〜ｔａｂｌｅ１３）を一つのデータベースとして扱うた
めに、ビュー（ｖｉｅｗ）を使用することができる。分
割した上部に形成されたテーブル（ｔａｂｌｅ）は、そ
のビュー、すなわち仮想的なテーブルを示している。

【００７５】サブセットのインターネットＩＤ情報によ
って目的とする個人情報を検索するには、例えば、サブ
セットのインターネットＩＤが“hogehogeaa01”の場合
には、 select crfhliduserInfo from tablewhere crfhlidsubs
etinternetID=hogehogeaa01 としたＳＱＬ文を生成すればよい。

【００７６】ここで、「ｔａｂｌｅ」はビューによって
生成された仮想テーブル名を表す。

【００７７】これによって、求める個人情報をサブセッ
トのインターネットＩＤによって求めることが可能とな
る。

【００７８】また、ニックネームしか判らない場合や一
部のニックネームしか判らない場合であっても、比較的
に簡単に該当する個人の個人情報を検索することが可能
となる。

【００７９】尚、ここでは、個人情報を単一の属性であ
る“crfhliduserInfo”で定義しているが、これは例示
であり、複数の個人情報毎に異なる属性として定義して
同一のテーブル又は別のテーブルに関連づけて検索でき
るようにしてもよい。

【図面の簡単な説明】

【図１】本願発明を適用可能なシステム構成例である。

【図２】システムが管理する情報のディレクトリツリー
構造の一例を示す。

【図３】分割されたリレーショナルデータベース構造の
一例を示す。

Claims

【特許請求の範囲】

【請求項１】利用者が任意に特定可能なニックネーム
と、通信ネットワーク上での利用者管理システムにより
割り振られた当該管理システムから利用者への一方向性
を有する利用者チェック情報とを組み合わせて利用者に
対してネットワーク上で一意の利用者識別子を付与し、当該利用者識別子と利用者の個人情報とを関連付け、も
って前記利用者識別子から特定された利用者の個人情報
によって、利用者を識別可能とした通信ネットワーク上
の利用者識別方法。
【請求項２】前記利用者チェック情報は、システムが
同一のニックネームに対して個々に異なるようにシステ
ム内部で管理する個別情報を含むようにした請求項１に
記載の通信ネットワーク上の利用者識別方法。
【請求項３】前記利用者チェック情報は、ニックネー
ムから一方向関数によって導かれるニックネーム依存情
報を含むようにした請求項１に記載の通信ネットワーク
上の利用者識別方法。
【請求項４】前記ニックネーム依存情報は、ニックネ
ームの符号値の総和から所定の素数で割った余りである
請求項３に記載の通信ネットワーク上の利用者識別方
法。
【請求項５】前記利用者識別子と個人情報とを少なく
とも属性とした利用者のオブジェクトを定義し、前記利用者識別子をＬＤＡＰのＤＳＡに構築する、請求
項１に記載の通信ネットワーク上の利用者識別方法。
【請求項６】前記利用者識別子と個人情報とを少なく
とも属性としたリレーショナルデータベースに利用者に
関する情報を構築する、請求項１に記載の通信ネットワ
ーク上の利用者識別方法。
【請求項７】利用者が任意に特定可能なニックネーム
と、通信ネットワーク上での利用者管理システムにより
割り振られた当該管理システムから利用者への一方向性
を有する利用者チェック情報とを組み合わせて利用者に
対してネットワーク上で一意となるよう付与された利用
者識別子の情報を有する管理サーバシステムからなる利
用者識別情報システムであって、前記管理サーバシステムは、前記利用者識別子とその値
に対応して関連付けられた個人情報とを格納し、当該システムは、利用者から受けた利用者識別子に応じ
て個人を特定できるようにした通信ネットワーク上の利
用者識別システム。
【請求項８】前記利用者チェック情報は、システムが同
一のニックネームに対して個々に異なるようにシステム
内部で管理する個別情報を含むようにした請求項７に記
載の通信ネットワーク上の利用者識別システム。
【請求項９】前記利用者チェック情報は、ニックネーム
から一方向関数によって導かれるニックネーム依存情報
を含むようにした請求項７に記載の通信ネットワーク上
の利用者識別システム。
【請求項１０】前記ニックネーム依存情報は、ニックネ
ームの符号値の総和から所定の素数で割った余りである
請求項９に記載の通信ネットワーク上の利用者識別シス
テム。
【請求項１１】前記利用者識別子と個人情報とを少なく
とも属性とした利用者のオブジェクトを定義し、前記管理サーバシステムはＬＤＡＰに従ったＤＳＡであ
って、ＤＳＡに前記オブジェクトのディレクトリ情報が
構築されている、請求項７に記載の通信ネットワーク上
の利用者識別システム。
【請求項１２】前記利用者識別子と個人情報とを少な
くとも属性としたリレーショナルデータベースが管理サ
ーバシステムの記憶手段に格納されている請求項７に記
載の通信ネットワーク上の利用者識別方法。