(57)【要約】【課題】本発明は、複数のソースからのデータを統合する継ぎ目の無い手法を提供する。【解決手段】本発明は、複数データソースへの透明なインターフェイスを与える統一化されたユーザ・プロファイル（１１２）を生成する方法及び利用するシステムを含む。個性化サーバー（１１０）を通して動作して個性化データベース（１０４）にアクセスするために基本ユーザ・ジャバビーンが得られる。基本ユーザ・ジャバビーンは、それを介して内在的及び外在的な属性が検索されて更新できる透明なインターフェイスを与える。エンタプライズ・ジャバビーンが、透明なインターフェイスを介して外部ユーザ・データベースから内在的及び外在的属性がさらに検索されて更新できるように基本ユーザ・ジャバビーンを拡張するために生成される。【選択図】図１
2004537096.tif 000002
【特許請求の範囲】
【請求項１】
複数データソースへの透明なアクセスを可能にするため統一化されたユーザ・プロファイルを生成するシステムであって、
（ａ）第１データソースと、
（ｂ）第２データソースと、
（ｃ）前記第１及び第２データソースにアクセスするように適合され、前記第１及び第２データソースからのデータを統一化されたユーザ・プロファイルに集合するために意ιされたコンポーネントを含むサーバーと、
を有するシステム。
【請求項２】
前記第１データソースが、レガシー・データベース、企業データベース、及びユーザ・データ記憶からなるグループから選ばれたものである請求項１記載のシステム。
【請求項３】
前記第１データソースが、認証情報、ユーザ・リスト、グループ・リスト及びグループ・メンバーシップからなるグループから選ばれたデータを含む請求項１記載のシステム。
【請求項４】
前記第１及び第２データ源の少なくとも１つ中のデータの認証を可能にするように適合されたセキュリテイ領域をさらに含む請求項１記載のシステム。
【請求項５】
前記サーバーが、個性化サーバーである請求項１記載のシステム。
【請求項６】
前記コンポーネントが、エンタプライズ・ジャバビーンを含む請求項１記載のシステム。
【請求項７】
前記エンタプライズ・ジャバビーンが、ｇｅｔＰｒｏｐｅｒｔｙ（）及びｓｅｔＰｒｏｐｅｒｔｙ（）からなるグループから選択されたメソッドを使用して、前記第１及び第２データソースの少なくとも１つの中のデータを検索して更新する請求項６記載のシステム。
【請求項８】
前記コンポーネントが、拡張ジャバビーンを含む請求項１記載のシステム。
【請求項９】
前記コンポーネントが、内在的及び外在的な属性を検索し更新できる透明なインターフェイスを提供する請求項１記載のシステム。
【請求項１０】
前記コンポーネントが属性組を含み、前記属性組が前記内在的及び外在的な属性に名前空間資格を与えるように適合された請求項９記載のシステム。
【請求項１１】
前記コンポーネントが、属性の獲得及び設定を含む請求項１記載のシステム。
【請求項１２】
前記コンポーネントが、前記第１データ記憶及び第２データ記憶からデータを検索し記憶するように適合された透明なインターフェイスを提供する請求項１記載のシステム。
【請求項１３】
前記第２データソースが、個性化データベースである請求項１記載のシステム。
【請求項１４】
既存のユーザ・データへ透明にアクセスするために統一化されたユーザ・プロファイルを生成するアーキテクチャであって、
（ａ）前記既存のユーザ・データを組み込むために拡張できる基本ユーザ・エンタプライズ・ジャバビーンと、
（ｂ）前記既存のユーザ・データを含むように適合されたユーザ・データ記憶と、
（ｃ）前記既存のユーザ・データの透明な読出し及び書込みを与えるために適合されたユーザ特定エンタプライズ・ジャバビーンと、
を含むアーキテクチャ。
【請求項１５】
前記既存のユーザ・データの外部のデータを含むデータソースをさらに含む請求項１４記載のアーキテクチャ。
【請求項１６】
前記ユーザ特定エンタプライズ・ジャバビーンがさらに、前記データソース内の前記データへの透明な読出し及び書込みアクセスを可能にする請求項１５記載のアーキテクチャ。
【請求項１７】
前記統一化されたユーザ・プロファイルのユーザへ前記読出し及び書込みアクセスを与えるように適合されたサーバーをさらに含む請求項１４記載のアーキテクチャ。
【請求項１８】
前記サーバーが個性化サーバーである請求項１７記載のアーキテクチャ。
【請求項１９】
前記ユーザ・データ記憶が、レガシー・データベース、企業データベース、及び顧客データベースからなるグループから選択された内部データソース中のテーブルである請求項１４記載のアーキテクチャ。
【請求項２０】
前記ユーザ・データ記憶が、認証情報、ユーザ・リスト、グループ・リスト及びグループ・メンバーシップからなるグループから選択されたデータを含む請求項１４記載のアーキテクチャ。
【請求項２１】
前記ユーザ・データ記憶内のデータの認証を可能にするように適合されたセキュリテイ領域をさらに含む請求項１４記載のアーキテクチャ。
【請求項２２】
前記ユーザ特定エンタプライズ・ジャバビーンが属性組を使用し、前記属性組が前記既存のユーザ・データの内在的及び外在的な属性に名前空間資格を与えるように適合されている請求項１４記載のアーキテクチャ。
【請求項２３】
前記ユーザ特定エンタプライズ・ジャバビーンが属性獲得及び設定を使用する請求項１４記載のアーキテクチャ。
【請求項２４】
個性化データベース及び外部ユーザ・データベースへ透明なアクセスを提供するため統一化されたユーザ・プロファイルを生成する方法であって、
（ａ）前記個性化データベースにアクセスするために個性化サーバーを通じて動作するように適合され、それを介して個性化データベースから内在的及び外在的属性が検索されて更新できる透明なインターフェイスを与えるように適合された基本ユーザ・ジャバビーンを得るステップと、
（ｂ）外部のユーザ・データベースから前記内在的及び外在的属性がさらに検索されて更新できるように基本ユーザ・ジャバビーンを拡張するためにエンタプライズ・ジャバビーンを生成するステップと、
を含む方法。
【請求項２５】
拡張された前記基本ユーザ・ジャバビーンを通じて前記外部データベースへの透明な読出し及び書込みアクセスを生成するステップをさらに含む請求項２４記載の方法。
【請求項２６】
前記読出し及び書込みアクセスを与えるためにサーバーを構成するステップをさらに含む請求項２４記載の方法。
【請求項２７】
前記サーバーが、個性化サーバーである請求項２６記載の方法。
【請求項２８】
前記外部ユーザ・データベースが、レガシー・データベース、企業データベース、及び顧客データベースからなるグループから選択されたものである請求項２４記載の方法。
【請求項２９】
前記外部ユーザ・データベースが、認証情報、ユーザ・リスト、グループ・リスト及びグループ・メンバーシップからなるグループから選択されたデータを含む請求項２４記載の方法。
【請求項３０】
前記外部ユーザ・データベース及び前記個性化データベース内のデータの認証を可能にするように適合されたセキュリテイ領域を得るステップをさらに含む請求項２４記載の方法。
【請求項３１】
拡張された基本ユーザ・ジャバビーンが属性組を使用し、前記属性組が前記個性化データベース内の前記データの内在的及び外在的な属性に名前空間資格を与えるように適合されている請求項２４記載の方法。
【請求項３２】
前記内在的及び外在的属性が、属性獲得及び設定を含む請求項３１記載の方法。
【請求項３３】
複数のデータソースを透明にアクセスするための方法であって、
（ａ）内部データソースにアクセスするためにサーバーを通じて動作するように適合され、それを介して内在的及び外在的属性が検索されて更新できる透明なインターフェイスを与えるように適合された基本ユーザ・ジャバビーンを得るステップと、
（ｂ）少なくとも１つの外部のデータソースからそれを介して内在的及び外在的属性が検索されて更新できるよう透明なインターフェイスを与えるため前記基本ユーザ・ジャバビーンがさらに適合されるようにユーザ・ジャバビーンを拡張するステップと、
を含む方法。
【請求項３４】
前記透明なインターフェイスを操作するようにサーバーを構成するステップをさらに含む請求項３３記載の方法。
【請求項３５】
前記外部データソース及び前記内部データソース内のデータの認証を可能にするように適合されたセキュリテイ領域を得るステップをさらに含む請求項３３記載の方法。
【請求項３６】
拡張されたユーザ・ジャバビーンのために属性組を構成するステップをさらに含む請求項３３記載の方法。
【請求項３７】
前記属性組が、前記内部及び外部データソース内の前記データの内在的及び外在的な属性に名前空間資格を与えるように適合されている請求項３５記載の方法。
【請求項３８】
前記内在的及び外在的属性が、属性獲得及び設定を含む請求項３７記載の方法。
【請求項３９】
前記内部及び外部データソース内の前記データの属性が外在的であるかどうかを決定するためにレフレクションを使用するステップをさらに含む請求項３７記載の方法。
【請求項４０】
複数のデータソースへ透明にアクセスするためのシステムであって、
（ａ）複数のデータソースと、
（ｂ）前記データソースの各々と通信するサーバーと、
（ｃ）前記サーバーを通じて前記複数のデータソースへの透明なアクセスを与えるように適合された拡張されたユーザ・ジャバビーンと、
を含むシステム。
【請求項４１】
前記複数のデータソースの少なくとも１つが、レガシー・データベース、企業データベース、及びユーザ・データ記憶からなるグループから選択されたものである請求項４０記載のシステム。
【請求項４２】
前記複数のデータソースの少なくとも１つの中のデータの認証を可能にするように適合されたセキュリテイ領域をさらに含む請求項４０記載のシステム。
【請求項４３】
前記サーバーが個性化サーバーである請求項４０記載のシステム。
【請求項４４】
前記拡張されたユーザ・ジャバビーンが、ｇｅｔＰｒｏｐｅｒｔｙ（）及びｓｅｔＰｒｏｐｅｒｔｙ（）からなるグループから選択されたメソッドを使用して、前記複数のデータソースの少なくとも１つの中のデータを検索して更新する請求項４０記載のシステム。
【請求項４５】
前記拡張されたユーザ・ジャバビーンが、前記複数のデータソース内のデータの内在的及び外在的な属性を検索して更新できるように適合されている請求項４０記載のシステム。
【請求項４６】
前記拡張されたユーザ・ジャバビーンが属性組を使用し、前記属性組が前記内在的及び外在的な属性に名前空間資格を与えるように適合されている請求項４５記載のシステム。
【請求項４７】
前記内在的及び外在的属性が、属性獲得及び設定を含む請求項４５記載のシステム。
【請求項４８】
複数のデータソースを統一化するためのシステムであって、
（ａ）データソース中にデータをアクセスし記憶する際に使用される名前付けコンベンションと、
（ｂ）少なくとも１つのデータソースが前記名前付けコンベンションに従わないデータ・エントリを含む複数のデータソースと、
（ｃ）各識別子対は前記名前付けコンベンションに従わないデータ・エントリに対応していて、識別子対はエントリの名前及び名前付けコンベンションに従う対応する名前を含む一組の識別子対と、
（ｄ）各データソース及び一組の識別子対と通信し、前記名前付けコンベンションに従う要求によりデータソースへのアクセスを可能とするように適合されたサーバーと、
を含むシステム。
【請求項４９】
前記複数のデータソースの少なくとも１つが、レガシー・データベース、企業データベース、及びユーザ・データ記憶からなるグループから選択されたものである請求項４８記載のシステム。
【請求項５０】
前記複数のデータソースの少なくとも１つの中のデータの認証を可能にするように適合されたセキュリテイ領域をさらに含む請求項４８記載のシステム。
【請求項５１】
複数データソースへの透明なアクセスを可能にするように統一化されたユーザ・プロファイルを生成するシステムであって、
（ａ）第１データソースにアクセスするように適合された第１コンポーネントと、
（ｂ）第２データソースにアクセスするように適合された第２コンポーネントと、
（ｃ）第１及び第２データソースからのデータを統一化されたユーザ・プロファイル中に集合するように適合されたユーザ・コンポーネントと、
を含むサーバーを備えたシステム。
【請求項５２】
前記第１及び第２データソースの少なくとも１つの中のデータを認証するためセキュリテイ領域へアクセスするように適合されたコンポーネントをさらに含む請求項５１記載のシステム。
【請求項５３】
ユーザ・コンポーネントが、エンタプライズ・ジャバビーンを含む請求項５１記載のシステム。
【請求項５４】
ユーザ・コンポーネントが、ｇｅｔＰｒｏｐｅｒｔｙ（）及びｓｅｔＰｒｏｐｅｒｔｙ（）からなるグループから選択されたメソッドを使用して、前記第１及び第２データソースの少なくとも１つの中のデータを検索して更新する請求項５１記載のシステム。
【請求項５５】
ユーザ・コンポーネントが、それを介して内在的及び外在的属性が検索され更新できる透明なインターフェイスを与える請求項５１記載のシステム。
【請求項５６】
前記ユーザ・コンポーネントが属性組を含み、前記属性組が前記内在的及び外在的な属性に名前空間資格を与えるように適合されている請求項５５記載のシステム。
【請求項５７】
ユーザ・コンポーネントが、属性の獲得及び設定を含む請求項５１記載のシステム。
【請求項５８】
ユーザ・データへのアクセスを与えるよう適合されたプロファイルを生成するためのアーキテクチャであって、
（ａ）ユーザ・データを組み込むことが可能な基本ユーザ・エンタプライズ・ジャバビーンと、
（ｂ）ユーザ・データへの透明な読出し及び書込みアクセスを与えるように適合されたユーザ特有エンタプライズ・ジャバビーンと、
を含むアーキテクチャ。
【請求項５９】
ユーザ・データへの読出し及び書込みアクセスを与えるように適合されたサーバーをさらに含む請求項５８記載のアーキテクチャ。
【請求項６０】
前記ユーザ・データ記憶が、認証情報、ユーザ・リスト、グループ・リスト及びグループ・メンバーシップからなるグループから選択されたデータを含む請求項５８記載のアーキテクチャ。
【請求項６１】
前記ユーザ特有エンタプライズ・ジャバビーンが属性組を使用し、前記属性組がユーザ・データの内在的及び外在的な属性に名前空間資格を与えるように適合されている請求項５８記載のアーキテクチャ。
【請求項６２】
ユーザ特有エンタプライズ・ジャバビーンが、属性の獲得及び設定を含む請求項５９記載のアーキテクチャ。
【請求項６３】
サーバーにより実行される時にサーバーが次のステップを行う命令を含んだコンピュータ読み取り可能な記憶媒体であって、
（ａ）第１データベースにアクセスするためにサーバーを通じて動作し、それを介して第１データベースから内在的及び外在的な属性を検索し更新できる透明なインターフェイスを与えるように適合された基本ユーザ・ジャバビーンを得るステップと、
（ｂ）第２データベースから前記内在的及び外在的属性をさらに検索して更新できるように基本ユーザ・ジャバビーンを拡張するためにエンタプライズ・ジャバビーンを生成するステップと、
を含むコンピュータ読み取り可能な記憶媒体。
【請求項６４】
サーバーがさらに、拡張された前記基本ユーザ・ジャバビーンにより第２データベースへの透明な読出し及び書込みアクセスを生成するようにする請求項６３記載のコンピュータ読み取り可能な記憶媒体。
【請求項６５】
サーバーがさらに、第１データベース及び第２データベースの中のデータを認証するように適合されたセキュリテイ領域を得るようにする請求項６３記載のコンピュータ読み取り可能な記憶媒体。
【請求項６６】
拡張された基本ユーザ・ジャバビーンが属性組を使用し、前記属性組が前記第１データベース内の前記データの内在的及び外在的な属性に名前空間資格を与えるように適合されている請求項６３記載のコンピュータ読み取り可能な記憶媒体。
【請求項６７】
拡張された基本ユーザ・ジャバビーンが属性の獲得及び設定を使用する請求項６３記載のコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【０００１】
優先権の主張
本出願は、ここに参照により組み込まれる２００１年４月２５日出願の米国仮特許出願番号６０／２８６，４６６「個性化サーバー統一化ユーザ・プロファイル」の優先権を主張する。
【０００２】
著作権表示
この特許書類の開示の一部は著作権保護を受ける内容を含む。著作権所有者は、特許商標庁の特許ファイル及び記録に現れるような特許書類のファクシミリな複製については異議を持たないが、それ以外については全ての著作権を留保する。
【０００３】
技術分野
本発明は、一般的に、複数のソースからのデータを統合することに関する。
【０００４】
背景技術
企業は、第三者のソースから取得されるような見込みの顧客及び現在の顧客に関する情報など、新しいデータと彼等の既存のデータとを統合するためのより良い方法を絶えず探している。このような統合を効率的にするため、会社は統合プロセスを流線型にして、不必要なコスト又は購入を無くし、そして新データシステムを実現するために又は既存データ構造を修正するために典型的に必要とされる停止時間を無くすることができなければならない。
【０００５】
一例として、企業は彼等の確立したユーザ・データ中に追加のユーザ・プロファイルを組み込みたいと思うかもしれない。この追加のプロファイル・データは、個性化サーバーなどの別のソースにより構成され且つ維持される。企業は、しばしば、個性化サーバー範囲外の以前から存在する企業の顧客又はユーザを持つ。典型的に既存の企業のデータベース内に存在するこのデータは、各顧客に対する、名前、社会保障番号、及び／又は特定エアラインの乗客利用マイル数などの会社特定情報を含む。企業は、可能ならばデータ移動の困難性を回避して、このデータを継ぎ目無しに彼等の個性化ソリューションに統合化することを望むだろう。
【０００６】
従って、本発明の１つの目的は、既存データソースからのデータと外部ソースからのデータとを統合する継ぎ目の無い手法を開発することである。
【０００７】
発明の開示
本発明は、統一化されたユーザ・プロファイルを生成するためのシステムを含む。システムは、第１データソースと第２データソースとを含む。サーバーは第１及び第２データソースにアクセスするために使用される。サーバーは第１及び第２データソースからのデータを統一化されたユーザ・プロファイルに集合するように適合されたユーザ・コンポーネントを使用する。
【０００８】
また、本発明には統一化されたユーザ・プロファイルを生成するためのアーキテクチャが含まれる。このアーキテクチャは、既存のユーザ・データ記憶からのユーザ・データを組み込むことができるように拡張可能な、基本ユーザ・エンタプライズ・ジャバビーン上に構築できる。そして、ユーザ特有エンタプライズ・ジャバビーンが生成されて、既存のユーザ・データへの透明な読出し及び書込みアクセスを可能にする。
【０００９】
また、本発明は、統一化されたユーザ・プロファイルを生成するための方法を含む。１つの実施の形態では、個性化データベースへアクセスするために個性化サーバーを通じて動作するように適合された基本ユーザ・ジャバビーンが得られる。基本ユーザ・ジャバビーンは、それを介して内在的及び外在的な属性が検索して更新できる透明なインターフェイスを提供する。そして、内在的及び外在的な属性が外部ユーザ・データベースから検索して更新できるように基本ユーザ・ジャバビーンを拡張するためにエンタプライズ・ジャバビーンが生成される。
【００１０】
また、本発明には、複数のデータソースに透明にアクセスするための方法が含まれる。この方法では、内部データソースへアクセスするようサーバーを通じて動作するために適合された基本ユーザ・ジャバビーンが得られる。基本ユーザ・ジャバビーンは、それを介して内部データソースに対して内在的及び外在的な属性が検索して更新できる透明なインターフェイスを提供する。そして、それを介して内在的及び外在的な属性が少なくとも１つの外部データソースから検索して更新できる透明なインターフェイスを基本ユーザ・ジャバビーンがさらに提供するように、基本ユーザ・ジャバビーンは拡張される。
【００１１】
さらに、本発明は、複数のデータソースを透明にアクセスするためのシステムを含む。システムは複数データソースとの通信の際にサーバーを使用する。システムにはサーバーを通じてデータソースに透明にアクセスすることを提供するように適合された拡張ユーザ・ジャバビーンが含まれる。
【００１２】
発明の詳細な説明
上述の本発明の開示に従い、以下に現在最良のモードと考えられる本発明の実施の形態の詳細な説明をする。
【００１３】
本発明のアーキテクチャは、既存のユーザ・データがより動的に変化する個性化データと共に組み込まれる方法を定義する。特定のユーザ又はユーザのグループに対してコンテント又はサービスを個性化するのに使用される個性化サーバーなどのサーバーでは、システム・ユーザは典型的にユーザ・プロファイルにより表される。ユーザ・プロファイルは、ユーザのためのＩＤ及び年齢又は電子メール・アドレスなどのユーザの属性へのアクセスを提供する。属性値は単一値又は複数値であることができ、ｇｅｔＰｒｏｐｅｒｔ（）関数又は属性名をキーとして取る同様のメソッドを介して要求される。
【００１４】
本発明のユーザ・プロファイルの長所は、ユーザ情報を既存のデータソースから検索するために拡張しカスタマイズできることである。例えば、ユーザ・プロファイルは個性化サーバーなどのサーバー又はソリューションと共に送り、個性化サーバー・データベースからの属性などのユーザ属性をＬＤＡＰサーバー又はレガシー・データベースとして当業者に知られているものからのユーザ属性と結合して、アプリケーション内で使用するために単一のユーザ・プロファイルにする。従って、開発者及びシステム・ユーザは、異なる基礎のデータソースについて心配する必要がない。ユーザ・プロファイルはユーザ情報のために必要な唯一の場所である。
【００１５】
本発明の統一化されたユーザ・プロファイル（ＵＵＰ）は、既存のデータソースからの属性及び個性化サーバー・データベース・テーブルからの属性を単一のカスタマイズされたユーザ・プロファイルへ集合した集合を含む。より詳細には、ＵＵＰは既存のユーザ／顧客データをユーザ・コンポーネントの拡張により結合する。個性化サーバー・データベース・テーブルを既存のデータベース・インスタンスに組み入れてユーザ・インプレメンテーションを拡張することにより、開発者は既存データベースから属性を検索し、そして属性を記憶／更新できるカスタマイズされたＵＵＰを素早く生成できる。この融通性は、データの移動又はそのデータを使用する既存のアプリケーションの崩壊を無くして既存のデータにアクセスすることを可能にする。しかし、もし、所望ならば、既存データは別個の個性化サーバー・データベース・インスタンスに移動できることが理解される。
【００１６】
他のサーバー・ソリューションと比較してＵＵＰの主な長所は、ＵＵＰは顧客リレーショナル・データベース・マネージメント・システム（ＲＤＢＭＳ）などのデータ管理システム内でデータベース構造更新又はデータ移動を必要としないことである。ＵＵＰは好ましくは、データベース・テーブルを更新したり又はデータ移動スクリプトを実行したりするのではなく、拡張ＥＪＢを記述することにより生成される。従来のサーバーはしばしば追加のユーザ属性に対してユーザ・データベース・テーブル構造を更新する必要がある。
【００１７】
図１−４は、本発明のＵＵＰシステムの可能な構成を示す。図１の第１の構成１００では、企業のレガシー又は他の外部データベース１０２及び個性化サーバー・データベース１０４が属性データを個性化サーバー１１０へ提供する。また、個性化サーバー１１０は、認証情報、ユーザ・リスト、グループ・リスト、及びグループ・メンバーシップなどのユーザ・データ記憶１０６から情報を受け取る。ユーザ・データ記憶は、業界で知られているＬＤＡＰ、Ｕｎｉｘ（登録商標）、又はＮＴシステムなどのいずれの適当なシステムであってよい。また、ユーザ・データ記憶１０６は、認証のためのセキュリテイ領域１０８を含む。個性化サーバー・データベース１０４及びセキュリテイ領域１０８はこの構成では別個に維持されている。本発明の実施のためには必要ではないが、認証及び検索のこのような分離は望ましい。この構成は、ＬＤＡＰデイレクトリのようにユーザとグループがデータ記憶のあるタイプ中に既に存在する場合に使用される。そして、この既存のユーザ属性データは、個性化サーバー１１０により取られて、ＵＵＰ１１２を生成するために個性化データと併合される。
【００１８】
図２に示す第２の構成２２０は、ＬＤＡＰデイレクトリなどのユーザ・データ記憶２０４内に既にユーザ又はグループが存在し、そして既存のユーザ・データがＵＵＰ２１０内に組み込まれる必要がない場合に有用である。そして、全てのユーザ及びグループ属性データは好ましくは個性化サーバー２０２データベースのテーブル中に記憶される。この構成中の個性化サーバー２０８は好ましくはユーザ・データ記憶２０４のセキュリテイ領域２０８を利用する。
【００１９】
図３に示された第３の構成３００は、ユーザ又はグループの既存の記憶が存在しない場合に有用である。個性化サーバー・データベース３０２のテーブルは、全てのユーザ及びグループ・データを含み、そして好ましくは分離されたセキュリテイ領域３０４を収納する。そして、個性化サーバー３０６は、ＵＵＰ３０８を生成する際に単に個性化サーバー・データベースを見ることだけが必要である。
【００２０】
図４に示された第４の構成４００は、ユーザ、グループ、及び属性データが既存の企業、レガシー、又は他の外部データベース４０２中にあり、そして個性化サーバー４０８によりＵＵＰ４１０中に組み込まれなければならない場合に有用である。そして、顧客セキュリテイ領域４０４が、既存のユーザ及びグループを個性化サーバーと共に使用するために生成されなければならない。顧客セキュリテイ領域は、必ずしも外部データベース４０２と共に記憶される必要はないが、個性化データベース４０６内に組み込まれてもよい。また、検索及び認証領域は好ましくは分離される。
【００２１】
本発明のアーキテクチャの１つの実施の形態は、データをＵＵＰ中に組み込むために３つの主な寄与に依存している。（１）基本ユーザ・エンタプライズ・ジャバビーン（ＥＪＢ）、（２）ユーザ・データ記憶、及び（３）ユーザ特有エンタプライズ・ジャバビーン（ＥＪＢ）である。
【００２２】
基本ユーザＥＪＢは、既存のユーザ・データを個性化ソリューションへ組み込むために個性化顧客により好ましくは拡張されたジャバクラスである。
【００２３】
基本ユーザＥＪＢは、好ましくは、それを介して内在的属性及び外在的な属性の両方が検索又は更新できる単一で透明なインターフェイスを提供する。基本ユーザＥＪＢは、属性に名前空間資格を与えるため及び属性タイプ、可能な値等を定義するために使用できる属性組を利用する。属性組は、ユーザ属性に対してデータ構造のように動作する。ここで使用される透明とは、一般に、ユーザ又はアプリケーションがどこにデータが記憶されているか又はそのデータがどんな名前付けコンベンションを使用するかについて注意することなく呼び出し又は要求をできるという事実を言う。もし、データが個性化データベースの代わりにレガシー・データベース中にある場合、ＵＵＰはユーザ又はアプリケーションが名前又は場所について知る必要無くして要求を自動的に処理する。
【００２４】
本発明の１つの実施の形態では、基本ユーザＥＪＢのサブクラスは検索又は更新するために２つのメソッド：ｇｅｔＰｒｏｐｅｒｔｙ及びｓｅｔＰｒｏｐｅｒｔｙ、を使用する。これらのメソッドは、内在的及び外在的な属性の両方を検索及び／又は更新できる。メソッドは次のように設定できる。
【００２５】
【数１】
2004537096.tif 000003
【００２６】
これらのメソッドは好ましくは、２つの主な特性：ｐｒｏｐｅｒｔｙＳｅｔＮａｍｅ及びｐｒｏｐｅｒｔｙＮａｍｅ、を使用する。ｐｒｏｐｅｒｔｙＳｅｔＮａｍｅ特性は、呼び出しが適用されるデータ構造を指定する。このようにして、ｐｒｏｐｅｒｔｙＳｅｔＮａｍｅは、検索又は更新される属性のための名前空間として動作する。ｐｒｏｐｅｒｔｙＮａｍｅ特性は、更新又は検索される属性の名前を指定する。ｐｒｏｐｅｒｔｙＳｅｔＮａｍｅ−ｐｒｏｐｅｒｔｙＮａｍｅ対を使用する１つの長所は、１つのｐｒｏｐｅｒｔｙＮａｍｅを複数のアプリケーション又はサブ・アプリケーション範囲にわたって使用できることである。また、属性名の複数インスタンスは異なる定義に対応してもよい。基本ユーザ・ビーンから検索された属性は、内在的属性と呼ばれる。
【００２７】
組み込む前に存在するであろうユーザ・データ記憶は、典型的に、現在のユーザ又は顧客データに関するデータが保持されているデータベース又はテーブルである。このテーブルは、個性化サーバーのデータベース・インスタンス中にコロケートできる。既存のユーザ・データ記憶は、個性化サーバー・データベース・テーブルと独立に存在するユーザ・データを保持してもよい。個性化サーバーは、既存のユーザ・データ記憶が個性化サーバー・テーブルとして同じＲＤＢＭＳ内に存在することを要求するだろう。
【００２８】
表１に、「アクメ顧客」ＲＤＢＭＳのテーブルの例が示されている。このテーブルは、各顧客に対して３つの値を定義している。（１）Ｃｕｓｔｏｍｅｒ＿Ｎａｍｅ、（２）Ａｃｍｅ＿Ｐｏｉｎｔｓ、及び（３）Ａｃｍｅ＿Ｄｉｓｃｏｕｎｔである。Ｃｕｓｔｏｍｅｒ＿Ｎａｍｅは、各顧客の独特な識別子として使用される。この独特な識別子は、一旦、統合が完了すると、好ましくは、個性化サーバー中でユーザを独特に識別するために使用される。Ａｃｍｅ＿Ｐｏｉｎｔｓは、サンプル顧客値である。アクメ顧客は、アクメ製品を購入するとポイントを集めることができる。Ａｃｍｅ＿Ｄｉｓｃｏｕｎｔは、各アクメ製品の購入について受け取る割引である。
【００２９】
表１−アクメ顧客ＲＤＢＭＳテーブル
【表１】
2004537096.tif 000004
【００３０】
既存データ記憶が完全に理解されると、基本ユーザＥＪＢを拡張するＥＪＢを記述でき、透明な値検索と更新サービスを利用する。ジャバビーンを拡張する方法は、コンピュータ技術の当業者には良く知られている。
【００３１】
既存のユーザ・データを個性化サーバーに備えられた個性化テーブルと統合するために、ＥＪＢを個性化サーバーに備えられたユーザ・ビーンを拡張するよう記述できる。このビーンが完成すると、個性化サーバー・クライアントはユーザ特有データベース・テーブル（外在的な属性）に前に記憶された属性、及び、個性化サーバーの属性テーブル組（内在的な属性）に記憶されている属性、に対して透明な読出し及び書込みアクセスを有する。
【００３２】
「アクメ顧客」データ記憶の例を続けると、既存のテーブルに対してデータ更新と検索機構を提供するアクメユーザＥＪＢが記述できる。本発明の制限内で操作するために、アクメユーザＥＪＢは次のメソッドを定義することができる。
【００３３】
・  ｐｕｂｌｉｃ  ｌｏｎｇ  ｇｅｔＡｃｍｅＰｏｉｎｔｓ（）−顧客により本日まで収集されたアクメ・ポイント数を戻す。
・  ｐｕｂｌｉｃ  ｖｏｉｄ  ｓｅｔＡｃｍｅＰｏｉｎｔｓ（Ｌｏｎｇ  ｎｅｗＡｃｍｅＰｏｉｎｔｓＶａｌｕｅ）−顧客についてアクメ・ポイント数を更新する。
・  ｐｕｂｌｉｃ  Ｄｏｕｂｌｅ  ｇｅｔＡｃｍｅＤｉｓｃｏｕｎｔ（）−顧客について現在の割引を戻す。
・  ｐｕｂｌｉｃ  ｖｏｉｄ  ｓｅｔＡｃｍｅＤｉｓｃｏｕｎｔ（）−顧客のアクメ割引を更新する。
【００３４】
拡張されたユーザ・ビーンから検索される属性は、外在的な属性と呼ばれる。
【００３５】
拡張されたビーンのメソッドが実現されると、アクメ・ポイントとアクメ割引の両方が基本ユーザＥＪＢにより実現される固有のｇｅｔＰｒｏｐｅｒｔｙ（）及びｓｅｔＰｒｏｐｅｒｔｙ（）メソッドにより検索できる。
【００３６】
従って、例えば、ユーザｂｓｍｉｔｈについて、次の２つのメソッドは値５００００を含むロングを共に返す。
【００３７】
【数２】
2004537096.tif 000005
【００３８】
同様に、次のメソッドの各々は、ｂｓｍｉｔｈについてアクメ・ポイント値を６０，０００に更新する。
【００３９】
【数３】
2004537096.tif 000006
【００４０】
透明な属性の更新及び検索の実現の際、ＵＵＰは好ましくは属性を内在的と取り扱い属性組の概念を使用する前に、属性が外在的であるかどうかを決定するためにジャバ・リフレクションの概念を用いる。レフレクションは、ジャバ・プログラミング言語の特徴であり、プログラムの内部属性を操作するためにそれ自身を検査又は内観するのにジャバ・プログラムの実行を可能にする。外在的な属性は、もし、属性名が外在的な属性に対応しているならば、内在的な属性の前に好ましくは検索され又は更新される。この探索順序のため、もし、外在的な属性が更新又は検索されているならば、実際の属性組名は何も結果を生じない。
【００４１】
次の例は、既存の顧客データを利用するためにＵＵＰを使用する架空の会社を示す。例は、ユーザ・ビーンを拡張し、既存のデータベースからデータを検索する。この例は、相対的な容易さでもって、どのようにアプリケーションの永続性の必要性に合ったカスタマイズされたＵＵＰが生成できるかを示す。次の表２は、カスタムＵＵＰを生成するために何が拡張されるかを示す。
【００４２】
表２−カスタムＵＵＰを生成するためのサンプル拡張
2004537096.tif 000007
【００４３】
ＵＵＰが構成可能エンテイテイである事実は、ユーザ・プロファイルが属性を外在的に又は内在的に獲得して設定するという概念を有する。ここで使用される属性を外在的に設定するということは、属性について設定メソッドを直接的に呼び出すことを意味する。ここで使用される属性を内在的に設定するということは、外債的な設定メソッドが利用できない場合に属性をｓｅｔＰｒｏｐｅｒｔｙ（）メソッドを介して設定することを意味する。例えば、もし、ＵＵＰが「ユーザ・ポイント」属性を含む場合、ｓｅｔＵｓｅｒＰｏｉｎｔｓ（）を直接に呼び出すことは、ユーザ・ポイント属性を外在的に設定するだろう。「ユーザ・ポイント」キーと共にｓｅｔＰｒｏｐｅｒｔｙ（）を呼び出すことは、ユーザ・ポイント特性を内在的に設定するだろう。呼び出されると、ｓｅｔＰｒｏｐｅｒｔｙ（）は最初にｓｅｔＵｓｅｒＰｏｉｎｔｓ（）設定メソッドをユーザ・プロファイル内に呼ぶために探す。もし、このような設定メソッドが存在すると、メソッドは属性を設定しそして値の変更に関して必要などんなことも実行するために呼び出される。最終的に、外在的に設定された属性値をたとえそれがｓｅｔＰｒｏｐｅｒｔｙ（）を介して内在的に呼び出されても持続させることがＵＵＰ実現の責任である。好ましくは、構成可能エンテイテイが、外在的な設定メソッドが存在しない場合のみ、持続する内在的設定属性を処理する。
【００４４】
図５（ａ）及び５（ｂ）は、それぞれｓｅｔＵｓｅｒＰｏｉｎｔｓ（）への外在的５５０及び内在的５００呼び出しの両方を示す。両場合において、ユーザ・ポイント値を記憶するのはＵＵＰビーンの責任である。もし、ＵＵＰビーン中に、ｓｅｔＵｓｅｒＰｏｉｎｔｓ（）メソッドが存在していなければ、構成可能エンテイテイ実現がユーザ・ポイント値の記憶を処理しているだろう。図５ａ中の内在的な場合では、ｓｅｔＰｒｏｐｅｒｔｙ（）への呼び出しが行われる５０２。システムは、ｓｅｔＵｓｅｒＰｏｉｎｔｓ（）が存在するかどうかを見るために検査する５０６。もし、存在すると、ｓｅｔＵｓｅｒＰｏｉｎｔｓ（）５０６が呼び出される。もし、存在しないと、システムは続けてｓｅｔＰｒｏｐｅｒｔｙ５１０を実行し続ける。図５ｂの外在的な場合については、ｓｅｔＵｓｅｒＰｏｉｎｔｓ（）へ行われた呼び出し５５２は、単にｓｅｔＵｓｅｒＰｏｉｎｔｓ（）を呼び出す５５４。
【００４５】
この属性の内在的及び外在的設定の概念は、ＵＵＰ実現の際に追加の融通性を可能にする。もし、別の値の計算など、属性の設定又は獲得の際に特別なロジックが発生することが必要な場合、それはその属性に対する設定又は獲得メソッドを使用して行われる。ＵＵＰの外側の機能は、属性アクセスのためのｓｅｔＰｒｏｐｅｒｔｙ（）メソッド及びｇｅｔＰｒｏｐｅｒｔｙ（）メソッドを有することに依存して、属性がそれ自身の設定又は獲得メソッドを有するかどうかについて知る必要性を無くしている。例えば、＜ｕｍ：ｇｅｔｐｒｏｐｅｒｔｙ＞ＪＳＰタグは、たとえｇｅｔＵｓｅｒＰｏｉｎｔｓ（）メソッドがＵＵＰにより提供されたユーザ・ポイントを検索するための唯一の方法であっても、ユーザ・ポイント属性値を検索するであろう。これは、ＵＵＰのｇｅｔＰｒｏｐｅｒｔｙ（）メソッドが他を検査する前に最初にそれがｇｅｔＵｓｅｒＰｏｉｎｔｓ（）メソッドを有するどうかを検査するからである。外在的なｓｅｔＰｒｏｐｅｒｔｙＮａｍｅ（）及びｇｅｔＰｒｏｐｅｒｔｙＮａｍｅ（）メソッドを有する属性は、「外在的な属性」と呼ばれる。一方、ｓｅｔＰｒｏｐｅｒｔｙ（）への呼び出しを介してのみ設定できる属性は、「内在的な属性」と呼ばれる。
【００４６】
カスタムＵＵＰ  ＥＪＢを実現する時、ＵＵＰについて外在的な属性に対しては、外在的な獲得及び設定メソッドを実現することだけが必要である。そして、これらの設定及び獲得メソッドの実現は、既存のデータ記憶内の属性値を検索し設定する。
【００４７】
１つの実施の形態では、ｇｅｔＰｒｏｐｅｒｔｙＮａｍｅ（）／ｓｅｔＰｒｏｐｅｒｔｙＮａｍｅ（）手法がＵＵＰ内の全ての外在的な属性の設定と獲得に対して続く。もし、ＵＵＰが外在的なユーザ・ポイント属性を持つ場合、検索ＵｓｅｒＰｏｉｎｔｓ（）は動作しないため、外在的ｇｅｔＵｓｅｒＰｏｉｎｔｓ（）メソッドが与えられる。同様に、ユーザ・ポイントの設定が、ｓｅｔＵｓｅｒＰｏｉｎｔｓ（）メソッドにより行われる。この実施の形態では、ｇｅｔＰｒｏｐｅｒｔｙ（）及びｓｅｔＰｒｏｐｅｒｔｙ（）メソッドは内在的呼び出しを介して属性を獲得して設定する時にこのコンベンションに続く獲得と設定を探す。ｓｅｔＰｒｏｐｅｒｔｙ（）又はｇｅｔＰｒｏｐｅｒｔｙ（）の無効は許されない。外在的な特性の獲得及び設定は、獲得及び設定メソッドを介して行われる。外在的な獲得及び設定はオブジェクトを取りそして戻す。ロング及びフロートなどのプリミテイブは、構成可能エンテイテイのｇｅｔＰｒｏｐｅｒｔｙ（）及びｓｅｔＰｒｏｐｅｒｔｙ（）メソッドと両立する、ｊａｖａ．ｌａｎｇ．Ｌｏｎｇ及びｊａｖａ．ｌａｎｇ．Ｆｌｏａｔオブジェクトなどの中に包まれる。
【００４８】
もし、獲得メソッドが与えられる場合、設定メソッドを与えることは良いアイデアである。この逆も同じである。何故ならば、何時ユーザ又はアプリケーションが属性の設定又は獲得を試みるかは予測できないからである。例えば、もし、対応する設定がなくデータベース・テーブルから特性を検索する獲得が与えられた場合、ｓｅｔＰｒｏｐｅｒｔｙ（）への呼び出しはその属性を個性化サーバー・テーブル内に記憶する。これは値が１つの場所から検索されて別の場所に設定されるため、望ましくない。次にその属性が検索される時、それは設定された値ではなく、その元の値を持つであろう。もし、読出し専用属性が与えられる場合、空の設定メソッドが実現される。
構成可能エンテイテイのｇｅｔＰｒｏｐｅｒｔｙ（）メソッドの好ましい定義は次の通りである。
【００４９】
【数４】
2004537096.tif 000008
【００５０】
ｇｅｔＰｒｏｐｅｒｔｙ（）メソッドは好ましくは、特定の順序で属性を探索する。例えば、もし、ユーザについて属性が見つかなければ、グループが値について質問される。この場合、ユーザはグループからの属性値を引き継ぐ。構成可能エンテイテイ項目では、グループはユーザの「後継者」である。もし、属性が構成可能エンテイテイ中で見つかなければ、構成可能エンテイテイの後継者が質問される。このようにして、構成可能エンテイテイは親エンテイテイからの値を受け継ぎ上書きする。
【００５１】
後継者は、内在的又は外在的のいずれかであることができる。内在的な後継者は構成可能エンテイテイのデフォルトの後継者、又は、指定された属性組のために設定された後継者である。外在的な後継者は好ましくは、ｇｅｔＰｒｏｐｅｒｔｙ（）メソッドにパラメータとして送られる構成可能エンテイテイである。次は、好適な構成可能エンテイテイに存在するようなｇｅｔＰｒｏｐｅｒｔｙ（）属性探索の順序である。
【００５２】
・指定された属性組に対して属性についてエンテイテイ中を見る。
・デフォルト（無効）属性組内の属性についてエンテイテイ中を見る。
・予約された属性組（もし、ＬＤＡＰ領域を使用しているならば、ＬＤＡＰからの属性について）内の属性についてエンテイテイ中を見る。
・エンテイテイの外在的な後継者（もし、指定されれば）内の属性を探す。
・指定された属性組に対してエンテイテイの後継者内の属性を探す。
・エンテイテイのデフォルトの後継者内の属性を探す。
・もし属性組が指定されれば（無効でない）、属性組中に定義されるようなデフォルト値を探す。
・送られたデフォルト値をｇｅｔＰｒｏｐｅｒｔｙ（）メソッド中に戻す。
【００５３】
構成可能エンテイテイのｇｅｔＰｒｏｐｅｒｔｙ（）メソッドの好適な定義は、次の通りである。
【００５４】
【数５】
2004537096.tif 000009
【００５５】
この好適な方法で、もし、ｓｅｔＰｒｏｐｅｒｔｙ（）が属性組定義と一致しない属性組に対する属性を設定するために使用される場合、例外が投げられる。例えば、「統一化ユーザ例」属性組が整数タイプのユーザ・ポイント属性を有すると定義されたと仮定する。もし、誰かが「統一化ユーザ例」属性組に対してユーザ・ポイント属性を「ａｂｃ」と設定した場合、ユーザ・ポイントは整数タイプとして定義されそして「ａｂｃ」はテキストであるため、例外が投げられる。同様に、ブーリアン属性値を「バー」に設定すると、ブーリアン値はブーリアン・オブジェクトに制限されているため、例外が生ずる。
【００５６】
もし、ｓｅｔＰｒｏｐｅｒｔｙ（）が呼び出されて無効が属性組のために送られると、属性値がデフォルト属性組と呼ばれる無効属性組内に設定される。ｇｅｔＰｒｏｐｅｒｔｙ（）の探索順序において上述したように、「予約」属性組及び後継者内の属性値を探索する前に、デフォルト属性組が好ましくは探索される。
【００５７】
「予約」属性組は好ましくは、外部データ記憶からの属性値を保持するために使用される読出し専用属性組である。「予約」属性組は、属性がＬＤＡＰデイレクトリから検索される時など、個性化サーバー内で使用できる。「予約」属性組内に属性を設定する試みは、例外が投げられる結果となる。「予約」属性組内の属性及び予約属性組自身は、ユーザ管理ツールを介して編集できない。好適なユーザ管理ツールは、特性の仕様をＬＤＡＰ又はユーザとグループの他のサーバーから検索することを可能にする。これらの特性は実行時に検索できるものである。
【００５８】
属性は、存在しない指定された属性組と共にｓｅｔＰｒｏｐｅｒｔｙ（）を介して設定できる。これは望ましくないであろう。行われると、指定された属性組名に対して属性組が「飛行中」に生成されない。指定された属性組名は属性の名前空間としてのみの役割をする。同様に、既存の属性組に対してｓｅｔＰｒｏｐｅｒｔｙ（）を介して属性を、その属性組に対して存在しない属性を指定して、設定することは望ましくないであろう。これらのいずれの方法の属性組はユーザ管理ツールにより編集できない。一方、「無効」又は「デフォルト」属性組内の属性は編集可能である。
【００５９】
ｇｅｔＰｒｏｐｅｒｔｙ（）への呼び出しは、もし、ｓｅｔＰｒｏｐｅｒｔｙ（）がｊａｖａ．ｌａｎｇ整数オブジェクトを送るように呼び出されると、好ましくはｊａｖａ．ｌａｎｇ．Ｌｏｎｇオブジェクトを戻す。このような属性を検索するコードは、次のように書くことができる。
【００６０】
【数６】
2004537096.tif 000010
【００６１】
ｇｅｔＰｒｏｐｅｒｔｙ（）への呼び出しは、もし、ｓｅｔＰｒｏｐｅｒｔｙ（）がｊａｖａ．ｌａｎｇフロート・オブジェクトと共に呼び出されると、好ましくはｊａｖａ．ｌａｎｇ．Ｄｏｕｂｌｅオブジェクトを戻す。このような属性を検索するコードは、次のように書くことができる。
【００６２】
【数７】
2004537096.tif 000011
【００６３】
ユーザ・オブジェクトは好ましくは、ＵＵＰと個性化サーバーとの統合を容易にするＥＪＢ発見操作のための機能を提供する。図６は、ｅｊｂＦｉｎｄ（）操作のフローチャートを示す。拡張されたＵＵＰｅｊｂＦｉｎｄ（）は、既存データ記憶内の記録を探索する６０２。もし、成功すると、ユーザ・オブジェクトｅｊｂＦｉｎｄ（）、スーパーｅｊｂＦｉｎｄ（）への呼び出しが行われる６０４。もし、成功すると、ユーザ・オブジェクトｅｊｂＦｉｎｄ（）は個性化サーバー・データベース・テーブル内にもし存在しなければＵＵＰのための必要な記録を生成し６１０、そして適当な主キーを戻す。もし、ユーザ・オブジェクトｅｊｂＦｉｎｄ（）が失敗すると、それはユーザ名が有効なユーザに対応しているかどうかを決定するために下にあるセキュリテイ領域を検査する６０８。もし、対応するならば、ユーザ・オブジェクトｅｊｂＦｉｎｄ（）は必要な記録を生成し６１０、これにより発見者エラー及びユーザ・データを個性化サーバー・ユーザ・データベース・テーブルに最初に移動するのに必要な時間を無くする。もし、ｅｊｂＦｉｎｄ（）の失敗又は領域内にユーザが存在しないのいずれかであると、発見者エラーに遭遇する６０６。もし、発見者エラーに遭遇しなければ、適当な主キーが戻される６１２。
【００６４】
もし、領域がユーザの存在は確証できないが、ユーザを生成しなければならない構成である場合、最初に発見されなかったスーパークラス記録を生成するのがＥＪＢの責任である。
【００６５】
カスタムＵＵＰを生成する１つの実施の形態の最後のステップは、ユーザ管理ツール等により、ＵＵＰが個性化又は他のサーバーに登録されることを要求する。ＵＵＰを登録するため、好適なユーザ管理ツールは表３中の次を利用する。
【００６６】
表３−ＵＵＰ（例）登録
2004537096.tif 000012
【００６７】
ＵＵＰを個性化サーバーに登録することにより、＜ｕｍ：ｇｅｔｐｒｏｆｉｌｅ＞ＪＳＰタグ：
2004537096.tif 000013
により新プロファイル・タイプを要求することが可能となる。
【００６８】
そして、ＵＵＰと共に、＜ｕｍ：ｇｅｔｐｒｏｐｅｒｔｙ＞及び＜ｕｍ：ｓｅｔｐｒｏｐｅｒｔｙ＞ＪＳＰタグを使用することが可能になる。
【００６９】
ＬＤＡＰ属性検索支援
内在的及び外在的な属性の透明な検索／更新に加えて、統一化されたユーザ・プロファイル機構の１つの実施の形態は、個性化サーバー顧客からジャバコードの必要なくして、ＬＤＡＰサーバーからユーザ情報の検索を容易にする。管理ツール組は、アプリケーション実行時中の属性要求においてＬＤＡＰサーバーからユーザ及びグループ属性の仕様を検索することを可能にする。好ましくは、ＬＤＡＰを適当に検索するための個性化サーバー顧客のたった１つの要件は、顧客がＬＤＡＰセキュリテイ領域を使用することである。実行時に、ＵＵＰはＬＤＡＰセキュリテイ領域が現在使用中であるかどうかを検出するためにある構成情報を質問する。もし、使用中ならば、検索されるユーザ及びグループ属性の名前がＬＤＡＰ構成セッションＥＪＢから得られ、そして現在ユーザの適当な属性が検索される。顧客は、他のＵＵＰ能力の利益を受け取るためにＬＤＡＰセキュリテイ領域を使用することは必要でない。
【００７０】
本発明の他の特徴、観点及び目的が特許請求の範囲の記載と添付図面から得られる。本発明の他の実施の形態も開発でき、本発明及び特許請求の範囲の精神と範囲内にある。
【００７１】
上述した本発明の好適な実施の形態の記載は、説明目的のために提供された。開示された正確な形に本発明を限定する意図及び網羅的な意図はない。明らかに、当業者には多くの修正と変形が可能である。実施の形態は、本発明の原理を最適に説明し、それにより当業者が考える特定の用途に適したさまざまな実施の形態について本発明を理解するために、選ばれて記述された。本発明の範囲は特許請求の範囲の記載とその均等物により定義されることを意図している。
【図面の簡単な説明】
【００７２】
【図１】本発明の１つの実施の形態によるＵＵＰ構成を示す図。
【図２】本発明の１つの実施の形態によるＵＵＰ構成を示す図。
【図３】本発明の１つの実施の形態によるＵＵＰ構成を示す図。
【図４】本発明の１つの実施の形態によるＵＵＰ構成を示す図。
【図５（ａ）】本発明の１つの実施の形態による内在的及び外在的なケースのためのｓｅｔＵｓｅｒＰｏｉｎｔ（）メソッドを呼び出すためのステップを示すフローチャート。
【図５（ｂ）】本発明の１つの実施の形態による内在的及び外在的なケースのためのｓｅｔＵｓｅｒＰｏｉｎｔ（）メソッドを呼び出すためのステップを示すフローチャート。
【図６】本発明の１つの実施の形態によるｅｊｂＦｉｎｄルーチンを操作するためのステップを示すフローチャート。
【図１】
2004537096.tif 000014
【図２】
2004537096.tif 000015
【図３】
2004537096.tif 000016
【図４】
2004537096.tif 000017
【図５（ａ）】
2004537096.tif 000018
【図５（ｂ）】
2004537096.tif 000019
【図６】
2004537096.tif 000020
【国際公開パンフレット】
2004537096.tif 000021
2004537096.tif 000022
2004537096.tif 000023
2004537096.tif 000024
2004537096.tif 000025
2004537096.tif 000026
2004537096.tif 000027
2004537096.tif 000028
2004537096.tif 000029
2004537096.tif 000030
2004537096.tif 000031
2004537096.tif 000032
2004537096.tif 000033
2004537096.tif 000034
2004537096.tif 000035
2004537096.tif 000036
2004537096.tif 000037
2004537096.tif 000038
2004537096.tif 000039
2004537096.tif 000040
2004537096.tif 000041
2004537096.tif 000042
2004537096.tif 000043
2004537096.tif 000044
2004537096.tif 000045
2004537096.tif 000046
2004537096.tif 000047
2004537096.tif 000048
2004537096.tif 000049
2004537096.tif 000050
2004537096.tif 000051
2004537096.tif 000052
2004537096.tif 000053
2004537096.tif 000054
2004537096.tif 000055
2004537096.tif 000056
2004537096.tif 000057
2004537096.tif 000058
2004537096.tif 000059
2004537096.tif 000060
2004537096.tif 000061
2004537096.tif 000062
2004537096.tif 000063
【国際調査報告】
2004537096.tif 000064