(57)【要約】【課題】  ディレクトリサーバにおいて更新前後のデータを適切に管理及び利用する。【解決手段】  少なくとも第１の属性値を含み且つ特定のエントリへの属性の登録に関する第１の要求データを受信し、要求データ格納部に格納するステップと、要求データ格納部に格納された第１の要求データに基づき、少なくとも第１の属性値と当該第１の属性値の有効期間に関するデータとを含む第１の属性データを生成し、第１の属性テーブルに格納するステップと、第１の属性データが格納された第１の属性テーブルのアドレスを特定のエントリに対応する属性管理テーブルに格納するステップとを含む。これにより、属性には、属性値と属性値の有効期間に関するデータとが対応付けられ、どの属性値が現在有効かということや、特定の属性値が有効であった期間等を知ることができるようになる。【選択図】図３
2006004024.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも第１の属性値を含み且つ特定のエントリへの属性の登録に関する第１の要求データを受信し、要求データ格納部に格納するステップと、
前記要求データ格納部に格納された前記第１の要求データに基づき、少なくとも前記第１の属性値と当該第１の属性値の有効期間に関するデータとを含む第１の属性データを生成し、第１の属性テーブルに格納するステップと、
前記第１の属性データが格納された前記第１の属性テーブルのアドレスを前記特定のエントリに対応する属性管理テーブルに格納するステップと、
をディレクトリサーバに実行させるためのプログラム。
【請求項２】
少なくとも第２の属性値を含み且つ前記特定のエントリに登録されている前記特定の属性についての属性値の変更に関する第２の要求データを受信し、前記要求データ格納部に格納するステップと、
前記特定の属性につき現在有効な属性値を含む属性データに、属性値の有効期間の終了日時を登録する更新ステップと、
前記要求データ格納部に格納された前記第２の要求データに基づき、少なくとも前記第２の属性値と当該第２の属性値の有効期間の開始日時とを含む第２の属性データを生成し、第２の属性テーブルに格納する追加ステップと、
前記第２の属性データが格納された前記第２の属性テーブルのアドレスを前記特定のエントリに対応する前記属性管理テーブルに格納するステップと、
をさらにディレクトリサーバに実行させるための請求項１記載のプログラム。
【請求項３】
前記更新ステップが、
前記特定の属性につき現在有効な属性値を含む属性データを複製するステップと、
複製元の属性データにおける属性値の有効期間の終了日時を登録するステップと、
を含み、
前記追加ステップにおいて、複製された属性データを用いて前記第２の属性データを生成することを特徴とする
請求項２記載のプログラム。
【請求項４】
少なくとも日時の条件を含む検索要求データを受信し、検索要求データ格納部に格納するステップと、
前記検索要求データ格納部に格納された前記検索要求データに基づき、前記日時の条件に合致する有効期間に関するデータを含む属性データを抽出し、結果格納部に格納する検索ステップと、
前記結果格納部に格納された属性データに含まれる属性値を含む出力データを生成し、出力する出力ステップ
をさらにディレクトリサーバに実行させるための請求項１記載のプログラム。
【請求項５】
特定の属性について日時の条件指定を含む検索要求データを受信し、検索要求データ格納部に格納するステップと、
前記検索要求データ格納部に格納された前記検索要求データに従って、前記日時の条件に合致する有効期間に関するデータを含む第３の属性データを抽出し、第１結果格納部に格納するステップと、
前記検索要求データ格納部に格納された前記検索要求データに従って、前記特定の属性に係る第４の属性データを抽出し、第２結果格納部に格納するステップと、
前記第１結果格納部に格納された前記第３の属性データと前記第２結果格納部に格納された前記第４の属性データとに共通する属性データを、前記日時の条件を満たす前記特定の属性に係る属性データとして特定し、検索結果格納部に格納するステップと、
前記検索結果格納部に格納された属性データに含まれる属性値を含む出力データを生成し、出力する出力ステップと、
をさらにディレクトリサーバに実行させるための請求項１記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ディレクトリサーバに関し、より詳しくはディレクトリサーバにおけるデータ管理及びデータ操作技術に関するものである。
【背景技術】
【０００２】
情報処理技術の発達に伴い、データ管理の重要性が高まってきている。例えば、特開２０００−１１２８０３号公報には、データファイルの更新をクライアント端末に通知するための技術が開示されている。すなわち、データファイル及びそれを必要とするクライアント端末を管理する管理手段、データファイルの更新の有無を判断する更新判断手段、及び更新されたデータファイルに関する所定の情報をクライアント端末に転送する更新情報配信手段を有し、データファイルの更新が行われると、更新されたデータファイルを必要とするクライアント端末に、更新されたデータファイルに関する所定の情報を転送する。
【０００３】
また例えば、特開平１１−２１３００９号公報には、ユーザによる書類の更新履歴の破壊や業務プロセスの履歴の破壊を防止するための技術が開示されている。すなわち、複数の端末装置と、書類が格納される書類記憶領域、書類属性ファイルが格納される属性記憶領域、及び書類又は書類属性ファイルの作成更新情報が記憶される操作ログリスト記憶領域を含むデータベース（ＤＢ）記憶装置を有するホスト装置とから保存システムを構築し、何れかの端末装置において書類が新規に作成され、当該書類がＤＢ記憶装置の書類記憶領域にアップロードされるときは、各端末装置は、その書類の書類属性ファイルを作成し、ホスト装置は、書類を書類記憶領域に格納し、書類属性ファイルを書類に関連付けして属性記憶領域に格納し、操作ログリスト記憶領域に、書類および書類属性ファイルの作成日時情報からなるログ情報を追加する。
【特許文献１】特開２０００−１１２８０３号公報
【特許文献２】特開平１１−２１３００９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
一方、ユーザ情報等の管理には、データを階層的に管理するディレクトリサーバが用いられることが多い。なお、ディレクトリの特徴として、検索処理に適している反面、トランザクションをサポートしない等の理由から、頻繁に更新されるデータの管理には向いていないということが挙げられる。現在、ディレクトリサーバには、一般的にＬＤＡＰ（Lightweight Directory Access Protocol：RFC1777，RFC2251）が採用されているが、例えばデータの更新履歴を保持する仕組みについての規定はない。しかし、ＤＢの構成が異なることから、上記特許公開公報に示されているような技術をそのままＬＤＡＰ等のディレクトリサーバに適用することはできない。
【０００５】
従って、本発明の目的は、ディレクトリサーバにおいて更新前後のデータを適切に管理及び利用するための技術を提供することである。
【課題を解決するための手段】
【０００６】
本発明に係るデータ処理方法は、少なくとも第１の属性値を含み且つ特定のエントリへの属性の登録に関する第１の要求データを受信し、要求データ格納部に格納するステップと、要求データ格納部に格納された第１の要求データに基づき、少なくとも第１の属性値と当該第１の属性値の有効期間に関するデータとを含む第１の属性データを生成し、第１の属性テーブルに格納するステップと、第１の属性データが格納された第１の属性テーブルのアドレスを特定のエントリに対応する属性管理テーブルに格納するステップとを含む。
【０００７】
これにより、属性には、属性値と属性値の有効期間に関するデータとが対応付けられ、どの属性値が現在有効かということや、特定の属性値が有効であった期間等を知ることができるようになる。
【０００８】
また、少なくとも第２の属性値を含み且つ特定のエントリに登録されている特定の属性についての属性値の変更に関する第２の要求データを受信し、要求データ格納部に格納するステップと、特定の属性につき現在有効な属性値を含む属性データに、属性値の有効期間の終了日時を登録する更新ステップと、要求データ格納部に格納された第２の要求データに基づき、少なくとも第２の属性値と当該第２の属性値の有効期間の開始日時とを含む第２の属性データを生成し、第２の属性テーブルに格納する追加ステップと、第２の属性データが格納された第２の属性テーブルのアドレスを特定のエントリに対応する属性管理テーブルに格納するステップとをさらに含むようにしてもよい。
【０００９】
これにより、新たなエントリや新たな属性を追加することなく、更新前の属性値を保持することができる。従って、新たな属性を導入するものではなく記憶容量の増加も最小限に抑えているため、ディレクトリサーバへの導入が比較的容易になる。また、各属性値につき、有効期間の開始日時あるいは開始日時及び終了日時を知ることができる。
【００１０】
また、上記更新ステップが、特定の属性につき現在有効な属性値を含む属性データを複製するステップと、複製元の属性データにおける属性値の有効期間の終了日時を登録するステップとを含み、上記追加ステップにおいて、複製された属性データを用いて第２の属性データを生成するようにしてもよい。これにより、同一の属性について複数の属性データが保持されることになり、属性を指定した検索時に問題が生じにくくなる。
【００１１】
また、少なくとも日時の条件を含む検索要求データを受信し、検索要求データ格納部に格納するステップと、検索要求データ格納部に格納された検索要求データに基づき、日時の条件に合致する有効期間に関するデータを含む属性データを抽出し、結果格納部に格納する検索ステップと、結果格納部に格納された属性データに含まれる属性値を含む出力データを生成し、出力する出力ステップをさらに含むようにしてもよい。これにより、例えばユーザは、指定した日時に有効であった属性値を知ることができる。
【００１２】
また、特定の属性について日時の条件指定を含む検索要求データを受信し、検索要求データ格納部に格納するステップと、検索要求データ格納部に格納された検索要求データに従って、日時の条件に合致する有効期間に関するデータを含む第３の属性データを抽出し、第１結果格納部に格納するステップと、検索要求データ格納部に格納された検索要求データに従って、特定の属性に係る第４の属性データを抽出し、第２結果格納部に格納するステップと、第１結果格納部に格納された第３の属性データと第２結果格納部に格納された第４の属性データとに共通する属性データを、日時の条件を満たす特定の属性に係る属性データとして特定し、検索結果格納部に格納するステップと、検索結果格納部に格納された属性データに含まれる属性値を含む出力データを生成し、出力する出力ステップとをさらに含むようにしてもよい。これにより、例えばユーザは、特定の属性について、指定した日時に有効であった属性値を知ることができる。
【００１３】
なお、本発明に係る方法をコンピュータに実行させるためのプログラムを作成することも可能であって、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してデジタル信号として配信される場合もある。なお、処理途中のデータについては、メモリ等の記憶装置に一時保管される。
【発明の効果】
【００１４】
本発明によれば、ディレクトリサーバにおいて更新前後のデータを適切に管理及び利用することができるようになる。
【発明を実施するための最良の形態】
【００１５】
本発明の一実施の形態に係るシステム構成を図１に示す。例えばインターネットであるネットワーク１には、ＬＤＡＰサーバ５と、１又は複数のユーザ端末３とが、無線又は有線により接続されている。ＬＤＡＰサーバ５には、登録データ格納部５００と登録データ管理部５１１と検索処理部５１３と更新結果格納部５１５と処理要求データ格納部５１７と検索結果格納部５１９とインタフェース部５２１とが含まれている。登録データ管理部５１１は、処理要求データ格納部５１７を参照して処理を行い、登録データ格納部５００と更新結果格納部５１５とにデータを登録する。検索処理部５１３は、処理要求データ格納部５１７と登録データ格納部５００とを参照して処理を行い、検索結果格納部５１９にデータを登録する。また、インタフェース部５２１は、ネットワーク１を介してユーザ端末３との通信を行うための機能を有し、ユーザ端末３から受信したデータを処理要求データ格納部５１７に格納し、更新結果格納部５１５と検索結果格納部５１９とを参照して処理を行い、ユーザ端末３にデータを送信する。また、登録データ格納部５００には、エントリ情報テーブル５０１と属性管理テーブル５０３と属性値情報テーブル５０５とが含まれている。
【００１６】
ユーザ端末３には、ＬＤＡＰサーバ５を用いた処理を行うアプリケーション・プログラム３０が含まれている。アプリケーション・プログラム３０には、ＬＤＡＰサーバ５にアクセスするためのインタフェースであるＬＤＡＰインタフェース３１が含まれている。
【００１７】
なお、ＬＤＡＰサーバ５及びユーザ端末３は、図２に示すようなコンピュータ装置であって、メモリ２０１とＣＰＵ２０３とハードディスク・ドライブ（ＨＤＤ）２０５と表示装置２０９に接続される表示制御部２０７とリムーバブル・ディスク２１１用のドライブ装置２１３と入力装置２１５とネットワークに接続するための通信制御部２１７とがバス２１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施の形態における処理を実現するためのプログラムを含むアプリケーション・プログラムは、ＨＤＤ２０５に格納されており、ＣＰＵ２０３により実行される際にはＨＤＤ２０５からメモリ２０１に読み出される。必要に応じてＣＰＵ２０３は、表示制御部２０７、通信制御部２１７、ドライブ装置２１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２０１に格納され、必要があればＨＤＤ２０５に格納される。本発明の実施の形態における処理を実現するためのプログラムは例えばリムーバブル・ディスク２１１に格納されて頒布されドライブ装置２１３から、又はネットワーク及び通信制御部２１７を介して受信し、ＨＤＤ２０５にインストールされる。このようなコンピュータ装置は、上で述べたＣＰＵ２０３、メモリ２０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、以下で説明する各種機能を実現する。
【００１８】
図３に、本実施の形態におけるエントリの模式図を示す。図３は、dn（Distinguished Name）が「cn＝shimizu,ou＝sd開発,o＝tfl,c＝jp」であるエントリについて、属性「syozoku」の値を「１開発」から「２開発」に変更した場合の例を表している。なお、cnはCommon Name、ouはOrganization Unit、oはOrganization、cはcountryを表す。また、ＬＤＡＰでは、格納される個々のレコードをエントリと呼び、エントリの識別はdnで行われる。また、各エントリは例えば複数の属性を持つことができ、属性は値（属性値）を持つ。
【００１９】
処理方法については後に詳しく述べるが、エントリ３００における各属性には、属性値の有効期間の開始日時あるいは有効期間の開始日時及び終了日時が対応付けられている。そのため、任意の属性値に対する更新履歴を時間情報により管理することが可能となっている。例えば属性３０１及び属性３０２は、特定の日時において同一の属性値を示すものである。属性３０１には、更新前の値である「１開発」が示されており、さらに「１開発」の有効期間「20020411102126-20031112194312」が示されている。なお「20020411102126-20031112194312」は、２００２年４月１１日１０時２１分２６秒から２００３年１１月１２日１９時４３分１２秒までの期間を表している。
【００２０】
また、属性３０２には、更新後の値である「２開発」が示されており、さらに「２開発」の有効期間の開始日時「20031112194313-」が示されている。末尾のハイフンは、現在まで有効であることを表している。本実施の形態においては、このように、同一の属性（syozoku）について複数の属性値が有効期間毎に保持されるようになっている。
【００２１】
図４に、登録データ格納部５００のテーブル構成の模式図を示す。まず、エントリ情報テーブル５０１は、エントリ単位で生成され、エントリ名や属性管理アドレス等が登録される。なお、属性管理アドレスとは、当該エントリ情報テーブル５０１に対応する属性管理テーブル５０３のアドレスである。属性管理テーブル５０３は、エントリ単位で生成され、エントリが有する属性の属性値アドレスが登録される。なお、属性値アドレスとは、各属性値に対応する属性値情報テーブル５０５のアドレスである。同一の属性に複数の属性値が対応付けられている場合、属性値情報テーブル５０５及び属性値アドレスは複数の属性値の各々に対応して存在する。また、属性値単位で生成される属性値情報テーブル５０５には、属性名、属性値、作成時間及び更新時間等のデータが格納される。作成時間は、当該属性値情報テーブル５０５が作成された日時であって、属性値の有効期間の開始日時を意味する。更新時間は、当該属性値情報テーブル５０５が更新された日時であって、属性値の有効期間の終了日時を意味する。
【００２２】
図５乃至図１４を用いて、図１に示したシステムの処理について説明する。まず、ユーザ端末３のアプリケーション・プログラム３０は、ＬＤＡＰサーバ５の処理を要するユーザの操作を受け付ける（図５：ステップＳ１）。アプリケーション・プログラム３０は、処理要求データを生成し、ＬＤＡＰサーバ５に送信する（ステップＳ３）。なお、この処理にはＬＤＡＰインタフェース３１が用いられる。
【００２３】
ＬＤＡＰサーバ５のインタフェース部５２１は、ユーザ端末３から処理要求データを受信し、処理要求データ格納部５１７に格納する（ステップＳ５）。また、インタフェース部５２１は、処理要求データ格納部５１７に格納された処理要求データの処理種別を確認する（ステップＳ７）。ここで、処理種別は、属性値の更新及び検索のいずれかであるものとする。
【００２４】
なお、属性値の有効期間に関するデータの更新を行うこともできる。図６に、属性値の有効期間に関するデータの更新を行うためのＬＤＩＦ（LDAP Data Interchange Format）の例を示す。実際には、例えばサブコマンドには「replace」、属性には「syozoku」、日時には「20031224105648」といった値が指定される。「modtimestamp」という指定は、属性値の更新日時、すなわち属性値の有効期間の終了日時を更新することを意味する。属性値の作成日時、すなわち属性値の有効期間の開始日時を更新する場合には、「modtimestamp」の代わりに「addtimestamp」という指定がなされる。図６に示した例では、属性値が複数存在する場合、更新される日時は、例えば最新の作成日時又は更新日時である。すなわち、「addtimestamp」の指定がなされた場合には、現在有効な属性値の有効期間の開始日時が更新される。一方、現在有効な属性値には有効期間の終了日時が対応付けられていないため、「modtimestamp」の指定がなされた場合には、１世代前に有効であった属性値の有効期間の終了日時が更新される。なお、更新前後の値（日時）を指定可能とし、世代に関わりなく更新できるようにしてもよい。
【００２５】
図５の説明に戻り、ＬＤＡＰサーバ５のインタフェース部５２１は、処理種別が属性値の更新であったか判定する（図５：ステップＳ９）。属性値の更新であったと判定された場合（ステップＳ９：Ｙｅｓルート）、ＬＤＡＰサーバ５の登録データ管理部５１１は、属性値更新処理を行う（ステップＳ１１）。属性値更新処理の詳細については後に述べる。そして、ＬＤＡＰサーバ５のインタフェース部５２１は、更新処理の終了をユーザに確認させるための処理結果データを生成し、ワーク・メモリ領域等の記憶装置に一旦格納する（ステップＳ１３）。例えば確認メッセージや更新前後の属性値を含む出力用データが処理結果データとして生成される。
【００２６】
一方、属性値の更新ではなかったと判定された場合（ステップＳ９：Ｎｏルート）、ＬＤＡＰサーバ５の検索処理部５１３は、検索処理を行う（ステップＳ１５）。検索処理の詳細については後に述べるが、検索条件を満たす属性値情報テーブル５０５が抽出され、検索結果格納部５１９に格納される。
【００２７】
そして、ＬＤＡＰサーバ５のインタフェース部５２１は、ステップＳ１５の検索処理において抽出された属性値情報テーブル５０５と、処理要求データにおける日時表示指定の有無とに基づき処理結果データを生成し、ワーク・メモリ領域等の記憶装置に一旦格納する（ステップＳ１７）。後に具体例を示すが、検索の種類に応じて、属性値の有効期間に関する日時を出力するか否かが判断される。そして後に述べるステップＳ１９の処理に移行する。
【００２８】
また、インタフェース部５２１は、ステップＳ１３又はステップＳ１７において生成された処理結果データをユーザ端末３に送信する（ステップＳ１９）。ユーザ端末３のアプリケーション・プログラム３０は、ＬＤＡＰインタフェース３１を用いて処理結果データをＬＤＡＰサーバ５から受信し、表示装置に表示する（ステップＳ２１）。
【００２９】
このようにして、ＬＤＡＰサーバ５を利用した一連の処理が行われる。
【００３０】
図７を用いて、属性値更新処理（図５：ステップＳ１１）の詳細について説明する。まず、ＬＤＡＰサーバ５の登録データ管理部５１１は、システム時間等から現在日時を取得し、ワーク・メモリ領域等の記憶装置に一旦格納する（図７：ステップＳ３１）。また、登録データ管理部５１１は、更新種別を確認する（ステップＳ３３）。ここで、更新種別は、属性値の追加、削除及び変更のいずれかであるものとする。そして、登録データ管理部５１１は、更新種別が追加であったか判定する（ステップＳ３５）。更新種別が追加であったと判定された場合（ステップＳ３５：Ｙｅｓルート）、登録データ管理部５１１は、新たな属性値情報テーブル５０５を生成し、登録データ格納部５００に格納する（ステップＳ３７）。この際、新たに生成した属性値情報テーブル５０５のアドレスを属性管理テーブル５０３に登録する。また、登録データ管理部５１１は、新たに生成した属性値情報テーブル５０５に属性値を登録する（ステップＳ３９）。さらに、登録データ管理部５１１は、新たに生成した属性値情報テーブル５０５に作成日時を登録する（ステップＳ４１）。上でも述べたが、作成日時とは、属性値の有効期間の開始日時を意味する。例えばステップＳ３１において取得した現在日時を作成日時として登録する。そして元の処理に戻る。
【００３１】
一方、更新種別が追加ではなかったと判定された場合（ステップＳ３５：Ｎｏルート）、登録データ管理部５１１は、更新種別が変更であったか判定する（ステップＳ４３）。更新種別が変更ではなかった（削除であった）と判定された場合（ステップＳ４３：Ｎｏルート）、登録データ管理部５１１は、現在有効な属性値に対応する属性値情報テーブル５０５に、更新時間を登録する（ステップＳ４５）。上でも述べたが、更新日時とは、属性値の有効期間の終了日時を意味する。例えばステップＳ３１において取得した現在日時を更新日時として登録する。そして元の処理に戻る。
【００３２】
一方、更新種別が変更であったと判定された場合（ステップＳ４３：Ｙｅｓルート）、登録データ管理部５１１は、現在有効な属性値に対応する属性値情報テーブル５０５を複製し、登録データ格納部５００に格納する（ステップＳ４７）。そして、登録データ管理部５１１は、複製元の属性値情報テーブル５０５に更新時間を登録する（ステップＳ４９）。例えばステップＳ３１において取得した現在日時を更新日時として登録する。また、登録データ管理部５１１は、複製された属性値情報テーブル５０５に属性値を上書き登録する（ステップＳ５１）。さらに、登録データ管理部５１１は、複製された属性値情報テーブル５０５に作成日時を登録する（ステップＳ５３）。例えばステップＳ３１において取得した現在日時の１秒後の日時を作成日時として登録する。そして元の処理に戻る。
【００３３】
このようにして、属性値更新処理が行われる。図８Ａ乃至図８Ｄに、ステップＳ４７乃至ステップＳ５３（図７）におけるデータの状態を表すＬＤＩＦの例を示す。図８Ａの属性８１０は、１件の属性値情報テーブル５０５に対応しており、属性「syozoku」の現在有効な属性値が「１開発」であることが示されている。この属性値「１開発」を「２開発」に変更するという処理を行う場合、まず、属性８１０を複製する（ステップＳ４７）。すなわち、属性８１０に対応する属性値情報テーブル５０５を複製する。図８Ｂには、複製された属性８２０が示されている。そして、複製元の属性８１０に更新日時を登録する（ステップＳ４９）。図８Ｂには、複製元の属性８１０に更新日時が登録された様子が示されている。
【００３４】
次に、複製された属性８２０に、属性値「２開発」を上書き登録する（ステップＳ５１）。図８Ｃには、複製された属性８２０に、属性値「２開発」が上書き登録された様子が示されている。さらに、複製された属性８２０に、作成日時を登録する（ステップＳ５３）。図８Ｄには、複製された属性８２０に、作成日時が登録された様子が示されている。このようにして、属性値の変更がなされる。なお、更新前の属性８１０を複製することにより更新後の属性８２０を生成する例を示したが、更新後の属性８２０を新規生成するようにしてもよい。
【００３５】
図９を用いて、検索処理（図５：ステップＳ１５）の詳細について説明する。まず、ＬＤＡＰサーバ５の検索処理部５１３は、処理要求データ格納部５１７を参照し、今回の検索処理における属性及び日時に関する検索フィルタを確認する（図９：ステップＳ６１）。検索フィルタの具体例については後に示す。そして、検索処理部５１３は、属性及び日時の少なくともいずれかについての指定があるか判定する（ステップＳ６３）。属性及び日時の少なくともいずれかについての指定がなかったと判定された場合（ステップＳ６３：Ｎｏルート）、検索処理部５１３は、他の検索条件を満たす属性値情報テーブル５０５を抽出し、検索結果格納部５１９に格納する（ステップＳ６５）。なお、他の検索条件とは、cn等の指定を意味する。そして、元の処理に戻る。
【００３６】
一方、属性及び日時の少なくともいずれかについての指定があったと判定された場合（ステップＳ６３：Ｙｅｓルート）、検索処理部５１３は、属性についての指定があったか判定する（ステップＳ６７）。属性についての指定がなかった（日時についての指定があった）と判定された場合（ステップＳ６７：Ｎｏルート）、検索処理部５１３は、他の検索条件を満たす属性値情報テーブル５０５のうち、指定された日時に該当する属性値情報テーブル５０５を抽出し、検索結果格納部５１９に格納する（ステップＳ６９）。そして、元の処理に戻る。
【００３７】
一方、属性についての指定があった（日時についても指定があった）と判定された場合（ステップＳ６７：Ｙｅｓルート）、検索処理部５１３は、フィルタ分離処理を行う（ステップＳ７１）。すなわち、属性の指定と日時の指定とに分ける。そして、検索処理部５１３は、他の検索条件を満たす属性値情報テーブル５０５のうち、指定された日時に該当する第１の属性値情報テーブル５０５を特定し、ワーク・メモリ領域等の記憶装置に一旦格納する（ステップＳ７３）。また、検索処理部５１３は、他の検索条件を満たす属性値情報テーブル５０５のうち、指定された属性に関する第２の属性値情報テーブル５０５を特定し、ワーク・メモリ領域等の記憶装置に一旦格納する（ステップＳ７５）。さらに、検索処理部５１３は、上記第１の属性値情報テーブル５０５と第２の属性値情報テーブル５０５とに共通する属性値情報テーブル５０５を抽出し、検索結果格納部５１９に格納する（ステップＳ７７）。そして元の処理に戻る。
【００３８】
このようにして検索処理がなされ、ステップＳ６５、ステップＳ６９及びステップＳ７７のいずれかの処理によって検索結果格納部５１９に格納された属性値情報テーブル５０５に基づき、ユーザに提示するための処理結果データが生成される。
【００３９】
図１０乃至図１４に、具体的な検索フィルタ及び検索結果を表すＬＤＩＦの例を示す。図１０の検索コマンド１０００には「cn=shimizu」という検索条件と「timeperiod=*」という日時についての検索フィルタとが示されている。なお「*（アスタリスク）」は特定の値を指定しないことを意味し、このような日時の指定がなされた場合には、日時表示指定がなされたと判断される。また、属性の指定がなされていないことから、図９の処理フローではステップＳ６９を経由する。検索結果１０１０には、検索コマンド１０００に基づく検索処理の結果が示されている。すなわち「cn=shimizu」を満たす属性について、属性値及び当該属性値の有効期間に関するデータが示されている。例えば、属性「syozoku」については、属性値が、「３開発」から「１開発」に変更された後、「１開発」から「２開発」に変更され、現在有効な属性値は「２開発」であることが示されている。このように、例えばユーザは、更新前の属性値及び各属性値の有効期間について容易に知ることができる。なお、各属性値の有効期間については、日時表示指定がなされた場合に示されるようになっている。
【００４０】
図１１の検索コマンド１１００には「cn=shimizu」という検索条件が示されている。また、日時及び属性の指定がなされていないことから、図９の処理フローではステップＳ６５を経由する。検索結果１１１０には、検索コマンド１１００に基づく検索処理の結果が示されている。すなわち「cn=shimizu」を満たす属性について、現在有効な属性値が示されている。このように、例えば日時指定をサポートしていないアプリケーション・プログラムであっても、そのままＬＤＡＰサーバ５を利用することができる。
【００４１】
図１２の検索コマンド１２００には「cn=shimizu」という検索条件と「syozoku;timeperiod=20031011073241」という属性及び日時についての検索フィルタとが示されている。属性及び日時の指定がなされていることから、図９の処理フローではステップＳ７１乃至ステップＳ７７を経由する。まず、ステップＳ７１において属性指定の「syozoku=*」と日時指定の「timeperiod=20031011073241」とにフィルタが分離される。そして、ステップＳ７３において、「cn=shimizu」及び日時「20031011073241」を満たす属性値のデータが抽出される。例えば「syozoku;20020411102127-20031112194312:１開発」や「telephonenumber;19980425113201-20031112194302:23456」というデータが抽出される。
【００４２】
また、ステップＳ７５において、「cn=shimizu」及び属性「syozoku=*」を満たす属性値のデータが抽出される。例えば「syozoku;20031112194313-:２開発」、「syozoku;20020411102127-20031112194312:１開発」及び「syozoku;19980425113201-20020411102126:３開発」というデータが抽出される。さらに、ステップＳ７７において、ステップＳ７３において特定された属性値のデータとステップＳ７５において特定された属性値のデータとに共通する属性値のデータが抽出される。上の例では「syozoku;20020411102127-20031112194312:１開発」というデータが抽出される。
【００４３】
検索結果１２１０には、検索コマンド１２００に基づく検索処理の結果が示されている。すなわち「cn=shimizu」を満たす属性についての属性値が示されている。但し、属性「syozoku」については、指定された日時「20031011073241」に有効であった属性値「１開発」が示され、他の属性については現在有効な属性値が示されている。なお、ステップＳ７７（図９）では、例えば「syozoku;20020411102127-20031112194312:１開発」という１件のデータのみが抽出されるため、ステップＳ１７（図５）において、「cn=shimizu」を満たす他の属性について現在有効な属性値を特定し、処理結果データを生成する。例えば「telephonenumber;20031112194303-:12345」というデータから属性値「12345」を特定し、処理結果データの生成に用いる。このように、例えばユーザは、timeperiodが指定された属性については、その指定された時点において有効であった属性値を、そしてその属性以外の属性については現在有効な属性値を知ることができる。
【００４４】
図１３の検索コマンド１３００には「cn=shimizu」という検索条件と「timeperiod=20031011073241」という日時についての検索フィルタとが示されている。属性の指定がなされていないことから、図９の処理フローではステップＳ６９を経由する。検索結果１３１０には、検索コマンド１３００に基づく検索処理の結果が示されている。すなわち「cn=shimizu」を満たす属性について、指定された日時において有効であった属性値が示されている。図１２の検索結果１２１０と検索結果１３１０との違いは、属性「telephonenumber」の属性値に現れている。検索結果１２１０では現在有効な属性値の「12345」が示されているのに対し、検索結果１３１０では、指定された日時において有効であった属性値「23456」が示されている。このように、例えばユーザは、特定の時点において有効であった属性値を知ることができる。
【００４５】
図１４の検索コマンド１４００には「-X」というオプション・パラメタと「cn=shimizu」という検索条件と「timeperiod=20031011073241」という日時についての検索フィルタとが示されている。「-X」というオプション・パラメタは、日時表示の指定を意味する。また、属性の指定がなされていないことから、図９の処理フローではステップＳ６９を経由する。検索結果１４１０には、検索コマンド１４００に基づく検索処理の結果が示されている。すなわち「cn=shimizu」を満たす属性について、指定された日時において有効であった属性値及び当該属性値の有効期間が示されている。このように、例えばユーザは、特定の時点において有効であった属性値及び当該属性値の有効期間を知ることができる。
【００４６】
以上のようにして、図１に示したシステムの処理が行われる。これにより、ディレクトリサーバにおいて更新前後のデータを適切に管理及び利用することが可能となる。
【００４７】
なお、ＬＤＡＰサーバにおいて更新前のデータを保持する場合、以下に示す２つの方法も採用される可能性がある。
【００４８】
図１５に、第１の方法に係るエントリの模式図を示す。図１５は、dnが「cn＝shimizu,ou＝sd開発,o＝tfl,c＝jp」であるエントリについて、属性「syozoku」の値を「１開発」から「２開発」に変更した場合の例を表している。
【００４９】
処理方法としては、まず、更新対象の属性を保持するエントリを別のdn（例えば「cn＝shimizu_1,ou＝sd開発,o＝tfl,c＝jp」）を用いて複製する。ここで複製されたエントリが、図１５ではエントリ１５１０として示されている。エントリ１５１０の属性１５１２には更新前の値である「１開発」が示されている。また、ｃｎ値１５１４に示されているように、cnを「shimizu」から「shimizu_1」に変更することによりdnを変更している。すなわち、更新前のエントリを名前を変えて保存している。
【００５０】
そして、複製元のエントリの属性を更新する。ここで更新されたエントリが、図１５ではエントリ１５００として示されている。エントリ１５００の属性１５０２には更新後の値である「２開発」が示されている。また、ｃｎ値１５０４に示されているように、cnの値に変更はなく、同様にdnにも変更はない。このように、エントリのバックアップをとるような方法が第１の方法である。
【００５１】
図１６に、第２の方法に係るエントリの模式図を示す。図１６は、図１５と同様、dnが「cn＝shimizu,ou＝sd開発,o＝tfl,c＝jp」であるエントリについて、属性「syozoku」の値を「１開発」から「２開発」に変更した場合の例を表している。
【００５２】
処理方法としては、まず、更新対象の属性を別の属性として複製する。ここで複製された属性が、図１６では属性１６２０として示されている。属性１６２０には更新前の値である「１開発」が示されている。すなわち、更新前の属性を名前を変えて同一のエントリ１６００内に保存している。
【００５３】
そして、複製元の属性を更新する。ここで更新された属性が、図１６では属性１６１０として示されている。属性１６１０には更新後の値である「２開発」が示されている。このように、属性のバックアップをとるような方法が第２の方法である。
【００５４】
しかしながら、これら第１の方法及び第２の方法は、上で述べた実施の形態に比して以下のような問題がある。まず、図１５に示した第１の方法のように古い属性値を別エントリにおいて管理する場合、保持する古い属性値の個数分だけエントリが追加されることになる。一般的にＬＤＡＰサーバのライセンス費用はエントリ数で決まる場合が多く、エントリの数が増えるとライセンス費用が高くなってしまい、コストの増大につながる。さらに、ある１つの対象（例えばユーザ）について、２つ以上のエントリにおいて情報を保持することになる。この場合、データの更新処理が複雑になってしまい、問題が生じる恐れがある。
【００５５】
また、図１６に示した第２の方法のように、古い属性値を別属性において管理する場合、更新時にエントリの追加を伴うことはないが、参照が困難になる。すなわち、古い属性値を参照するためには検索時に別属性を指定する必要があり、例えば、何という属性（名前）で保存されているのかを知らないと、参照することができないという問題点がある。
【００５６】
従って、上で述べた実施の形態に示した方法を採用することにより、適切なデータの管理及び利用を行うことができるようになる。
【００５７】
以上本発明の一実施の形態について説明したが、本発明はこれに限定されるものではない。例えば、図４に示したテーブル構成は一例であって、同様のデータを格納するためであれば別の構成を採用するようにしてもよいし、必要に応じて項目を追加又は削除してもよい。また、図１に示したＬＤＡＰサーバ及びユーザ端末の機能ブロック構成は一例であって、実際のプログラム・モジュール構成とは異なる場合がある。同様に、図２に示したコンピュータの機能ブロック図も一例であって、実際のハードウェア構成とは異なる場合もある。また、ＬＤＡＰサーバが複数のサーバによって構成されている場合もある。また、図３、図１５及び図１６に示した模式図も一例であって、同様の内容を別の態様で表す場合もある。同様に、図６、図８Ａ乃至図８Ｄ、及び図１０乃至図１４に示したＬＤＩＦの記述も一例であって、同様の内容を別の態様で表す場合もある。さらに、図５、図７及び図９に示した処理フローも一例であって、同様の処理結果が得られる範囲において処理の順序を入れ替えてもよいし、必要に応じてステップを追加又は削除してもよい。
【００５８】
（付記１）
ディレクトリサーバにより管理されるデータ構造であって、
属性項目に関するデータを規定する属性データと、
同一のエントリに含まれる前記属性項目の各々に対応する前記属性データの記憶アドレスを規定する属性管理データと、
各エントリに対応する前記属性管理データの記憶アドレスを規定するエントリ管理データと、
を含み、
前記属性データが、少なくとも属性値と当該属性値の有効期間に関するデータとを含み、
同じ属性について複数の属性項目を定義する場合には、前記属性管理データが、前記属性項目の各々につき前記属性データの記憶アドレスを規定することを特徴とする
データ構造。
【００５９】
（付記２）
少なくとも第１の属性値を含み且つ特定のエントリへの属性の登録に関する第１の要求データを受信し、要求データ格納部に格納するステップと、
前記要求データ格納部に格納された前記第１の要求データに基づき、少なくとも前記第１の属性値と当該第１の属性値の有効期間に関するデータとを含む第１の属性データを生成し、第１の属性テーブルに格納するステップと、
前記第１の属性データが格納された前記第１の属性テーブルのアドレスを前記特定のエントリに対応する属性管理テーブルに格納するステップと、
をディレクトリサーバに実行させるためのプログラム。
【００６０】
（付記３）
少なくとも第２の属性値を含み且つ前記特定のエントリに登録されている前記特定の属性についての属性値の変更に関する第２の要求データを受信し、前記要求データ格納部に格納するステップと、
前記特定の属性につき現在有効な属性値を含む属性データに、属性値の有効期間の終了日時を登録する更新ステップと、
前記要求データ格納部に格納された前記第２の要求データに基づき、少なくとも前記第２の属性値と当該第２の属性値の有効期間の開始日時とを含む第２の属性データを生成し、第２の属性テーブルに格納する追加ステップと、
前記第２の属性データが格納された前記第２の属性テーブルのアドレスを前記特定のエントリに対応する前記属性管理テーブルに格納するステップと、
をさらにディレクトリサーバに実行させるための付記２記載のプログラム。
【００６１】
（付記４）
前記更新ステップが、
前記特定の属性につき現在有効な属性値を含む属性データを複製するステップと、
複製元の属性データにおける属性値の有効期間の終了日時を登録するステップと、
を含み、
前記追加ステップにおいて、複製された属性データを用いて前記第２の属性データを生成することを特徴とする
付記３記載のプログラム。
【００６２】
（付記５）
少なくとも日時の条件を含む検索要求データを受信し、検索要求データ格納部に格納するステップと、
前記検索要求データ格納部に格納された前記検索要求データに基づき、前記日時の条件に合致する有効期間に関するデータを含む属性データを抽出し、結果格納部に格納する検索ステップと、
前記結果格納部に格納された属性データに含まれる属性値を含む出力データを生成し、出力する出力ステップ
をさらにディレクトリサーバに実行させるための付記２記載のプログラム。
【００６３】
（付記６）
特定の属性について日時の条件指定を含む検索要求データを受信し、検索要求データ格納部に格納するステップと、
前記検索要求データ格納部に格納された前記検索要求データに従って、前記日時の条件に合致する有効期間に関するデータを含む第３の属性データを抽出し、第１結果格納部に格納するステップと、
前記検索要求データ格納部に格納された前記検索要求データに従って、前記特定の属性に係る第４の属性データを抽出し、第２結果格納部に格納するステップと、
前記第１結果格納部に格納された前記第３の属性データと前記第２結果格納部に格納された前記第４の属性データとに共通する属性データを、前記日時の条件を満たす前記特定の属性に係る属性データとして特定し、検索結果格納部に格納するステップと、
前記検索結果格納部に格納された属性データに含まれる属性値を含む出力データを生成し、出力する出力ステップと、
をさらにディレクトリサーバに実行させるための付記２記載のプログラム。
【００６４】
（付記７）
前記出力ステップにおいて、
属性値の有効期間に関するデータの出力指示データが前記検索要求データに含まれていた場合、前記結果格納部に格納された属性データに含まれる属性値と当該属性値の有効期間に関するデータとを含む出力データを生成し、出力することを特徴とする
付記５記載のプログラム。
【００６５】
（付記８）
少なくとも第１の属性値を含み且つ特定のエントリへの属性の登録に関する第１の要求データを受信し、要求データ格納部に格納するステップと、
前記要求データ格納部に格納された前記第１の要求データに基づき、少なくとも前記第１の属性値と当該第１の属性値の有効期間に関するデータとを含む第１の属性データを生成し、第１の属性テーブルに格納するステップと、
前記第１の属性データが格納された前記第１の属性テーブルのアドレスを前記特定のエントリに対応する属性管理テーブルに格納するステップと、
を含み、ディレクトリサーバにより実行されるデータ処理方法。
【００６６】
（付記９）
少なくとも第１の属性値を含み且つ特定のエントリへの属性の登録に関する第１の要求データを受信し、要求データ格納部に格納する手段と、
前記要求データ格納部に格納された前記第１の要求データに基づき、少なくとも前記第１の属性値と当該第１の属性値の有効期間に関するデータとを含む第１の属性データを生成し、第１の属性テーブルに格納する手段と、
前記第１の属性データが格納された前記第１の属性テーブルのアドレスを前記特定のエントリに対応する属性管理テーブルに格納する手段と、
を有するデータ管理装置。
【図面の簡単な説明】
【００６７】
【図１】本発明の一実施の形態におけるシステム構成図である。
【図２】本発明の一実施の形態におけるコンピュータの機能ブロックの概要を示す図である。
【図３】本発明の一実施の形態におけるエントリの模式図である。
【図４】登録データ格納部のテーブル構成の一例を示す図である。
【図５】本発明の一実施の形態における処理フローを示す図である。
【図６】属性値の有効期間に関するデータの更新を行うためのＬＤＩＦの一例を示す図である。
【図７】属性値更新処理の処理フローを示す図である。
【図８Ａ】データの状態を表すＬＤＩＦの一例を示す第１の図である。
【図８Ｂ】データの状態を表すＬＤＩＦの一例を示す第２の図である。
【図８Ｃ】データの状態を表すＬＤＩＦの一例を示す第３の図である。
【図８Ｄ】データの状態を表すＬＤＩＦの一例を示す第４の図である。
【図９】検索処理の処理フローを示す図である。
【図１０】検索フィルタ及び検索結果を表すＬＤＩＦの一例を示す第１の図である。
【図１１】検索フィルタ及び検索結果を表すＬＤＩＦの一例を示す第２の図である。
【図１２】検索フィルタ及び検索結果を表すＬＤＩＦの一例を示す第３の図である。
【図１３】検索フィルタ及び検索結果を表すＬＤＩＦの一例を示す第４の図である。
【図１４】検索フィルタ及び検索結果を表すＬＤＩＦの一例を示す第５の図である。
【図１５】第１の方法に係るエントリの模式図である。
【図１６】第２の方法に係るエントリの模式図である。
【符号の説明】
【００６８】
１    ネットワーク    ３  ユーザ端末    ５  ＬＤＡＰサーバ
３０  アプリケーション・プログラム
３１  ＬＤＡＰインタフェース
５００  登録データ格納部    ５０１  エントリ情報テーブル
５０３  属性管理テーブル    ５０５  属性値情報テーブル
５１１  登録データ管理部    ５１３  検索処理部
５１５  更新結果格納部      ５１７  処理要求データ格納部
５１９  検索結果格納部      ５２１  インタフェース部          
【図１】
2006004024.tif 000003
【図２】
2006004024.tif 000004
【図３】
2006004024.tif 000005
【図４】
2006004024.tif 000006
【図５】
2006004024.tif 000007
【図６】
2006004024.tif 000008
【図７】
2006004024.tif 000009
【図８Ａ】
2006004024.tif 000010
【図８Ｂ】
2006004024.tif 000011
【図８Ｃ】
2006004024.tif 000012
【図８Ｄ】
2006004024.tif 000013
【図９】
2006004024.tif 000014
【図１０】
2006004024.tif 000015
【図１１】
2006004024.tif 000016
【図１２】
2006004024.tif 000017
【図１３】
2006004024.tif 000018
【図１４】
2006004024.tif 000019
【図１５】
2006004024.tif 000020
【図１６】
2006004024.tif 000021