JP2002049641A - 複数プロファイル管理装置，管理方法，複数プロファイル管理用プログラム記録媒体および複数プロファイル管理用プログラム - Google Patents
複数プロファイル管理装置，管理方法，複数プロファイル管理用プログラム記録媒体および複数プロファイル管理用プログラムInfo
- Publication number
- JP2002049641A JP2002049641A JP2001136860A JP2001136860A JP2002049641A JP 2002049641 A JP2002049641 A JP 2002049641A JP 2001136860 A JP2001136860 A JP 2001136860A JP 2001136860 A JP2001136860 A JP 2001136860A JP 2002049641 A JP2002049641 A JP 2002049641A
- Authority
- JP
- Japan
- Prior art keywords
- data element
- profiler
- access
- name
- profile
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Abstract
(57)【要約】
【課題】 アクセスプロトコルとデータ表現形式の異な
る複数のプロファイラを統合することにより，新規サー
ビス導入に伴うサービス提供者とサービス利用者双方に
おけるプロファイルデータ管理の負担を軽減する。 【解決手段】 統合アクセス部２は，各プロトコル毎の
統合アクセスインタフェース20を介して各サービスに対
して定められたアクセスプロトコルによりプロファイラ
に対するアクセス要求を受け付け，名前管理部３は，ア
クセス要求において指定されたデータ要素名を，プロフ
ァイラにおける実際の格納場所に関する情報に変換す
る。プロファイルアクセス部４は，変換された格納場所
の情報に基づき，該当するプロファイルアクセスインタ
フェース40を介してプロファイラにアクセスし，結果を
返送する。
る複数のプロファイラを統合することにより，新規サー
ビス導入に伴うサービス提供者とサービス利用者双方に
おけるプロファイルデータ管理の負担を軽減する。 【解決手段】 統合アクセス部２は，各プロトコル毎の
統合アクセスインタフェース20を介して各サービスに対
して定められたアクセスプロトコルによりプロファイラ
に対するアクセス要求を受け付け，名前管理部３は，ア
クセス要求において指定されたデータ要素名を，プロフ
ァイラにおける実際の格納場所に関する情報に変換す
る。プロファイルアクセス部４は，変換された格納場所
の情報に基づき，該当するプロファイルアクセスインタ
フェース40を介してプロファイラにアクセスし，結果を
返送する。
Description
【０００１】
【発明の属する技術分野】本発明は，ネットワークで接
続された複数のコンピュータにおいて，アクセスプロト
コル，データ表現形式が異なる複数のプロファイラを統
合する目的で利用される複数プロファイル管理装置に関
する。
続された複数のコンピュータにおいて，アクセスプロト
コル，データ表現形式が異なる複数のプロファイラを統
合する目的で利用される複数プロファイル管理装置に関
する。
【０００２】プロファイラとは，例えばネットワークに
接続される情報端末を使ってネットワーク上のサービス
を受けるユーザに対して，ユーザ毎にカスタマイズされ
たサービスを提供するために必要な，サービスの設定情
報あるいは個人情報を格納および参照するデータ記憶装
置あるいはデータ記憶プログラムを意味する。本発明
は，１台のユーザの情報端末上に，複数のサービスと複
数のプロファイラが存在し，各種のサービスを提供する
場合を含む。
接続される情報端末を使ってネットワーク上のサービス
を受けるユーザに対して，ユーザ毎にカスタマイズされ
たサービスを提供するために必要な，サービスの設定情
報あるいは個人情報を格納および参照するデータ記憶装
置あるいはデータ記憶プログラムを意味する。本発明
は，１台のユーザの情報端末上に，複数のサービスと複
数のプロファイラが存在し，各種のサービスを提供する
場合を含む。
【０００３】
【従来の技術】従来，サービスを提供するプログラムが
そのサービスを利用するユーザ毎の好みに合わせたカス
タマイズサービスを提供する場合には，図９に示すよう
に，各サービス１，２，…，ｎ毎に独自のプロファイラ
１，２，…，ｎを用意し，それぞれのプロファイラ１，
２，…，ｎによってサービスの設定情報を管理してい
た。サービスとそのサービスが利用するプロファイラと
の関係は，古典的にはコンピュータで動作するアプリケ
ーションプログラムとその初期設定ファイルとの関係に
相当する。
そのサービスを利用するユーザ毎の好みに合わせたカス
タマイズサービスを提供する場合には，図９に示すよう
に，各サービス１，２，…，ｎ毎に独自のプロファイラ
１，２，…，ｎを用意し，それぞれのプロファイラ１，
２，…，ｎによってサービスの設定情報を管理してい
た。サービスとそのサービスが利用するプロファイラと
の関係は，古典的にはコンピュータで動作するアプリケ
ーションプログラムとその初期設定ファイルとの関係に
相当する。
【０００４】一般に，ユーザは目的に応じてこれらのサ
ービスを使い分けているが，サービス（特にネットワー
クサービス）に必要な設定情報は規格化されたものが多
くなってきている。異なるサービスでも，一部共通の情
報要素を設定情報として使う場合が増えている。ここ
で，異なるアプリケーションが使う共通の情報要素の例
としては，自分のメール・アドレスや電話番号，ウェブ
・プロキシ，メールサーバ，ニュースサーバなどの各種
サーバ・アドレス，ウェブ・ブックマークやアドレスブ
ックなどが想定される。
ービスを使い分けているが，サービス（特にネットワー
クサービス）に必要な設定情報は規格化されたものが多
くなってきている。異なるサービスでも，一部共通の情
報要素を設定情報として使う場合が増えている。ここ
で，異なるアプリケーションが使う共通の情報要素の例
としては，自分のメール・アドレスや電話番号，ウェブ
・プロキシ，メールサーバ，ニュースサーバなどの各種
サーバ・アドレス，ウェブ・ブックマークやアドレスブ
ックなどが想定される。
【０００５】しかし，現状ではサービス毎に設定情報を
格納するプロファイラが独立しているため，ユーザが新
しいサービスを使い始めるときには，必ず設定情報を入
力する必要があった。また，複数のサービスで既に設定
され共通に使われている設定情報を変更する場合には，
それらのサービスが使っているプロファイラの該当する
情報要素を個別に変更する必要があった。
格納するプロファイラが独立しているため，ユーザが新
しいサービスを使い始めるときには，必ず設定情報を入
力する必要があった。また，複数のサービスで既に設定
され共通に使われている設定情報を変更する場合には，
それらのサービスが使っているプロファイラの該当する
情報要素を個別に変更する必要があった。
【０００６】
【発明が解決しようとする課題】本発明は，既存のサー
ビスおよびプロファイラにできるだけ影響を与えること
なく，サービス毎に独立に存在するプロファイラを統合
し，アクセスプロトコル，データ表現形式を統一的なイ
ンタフェースにし，サービス設定情報や個人情報を利用
するユーザやサービス提供者の管理上の負担を軽減する
ことを目的とする。
ビスおよびプロファイラにできるだけ影響を与えること
なく，サービス毎に独立に存在するプロファイラを統合
し，アクセスプロトコル，データ表現形式を統一的なイ
ンタフェースにし，サービス設定情報や個人情報を利用
するユーザやサービス提供者の管理上の負担を軽減する
ことを目的とする。
【０００７】
【課題を解決するための手段】本発明では，既存のサー
ビスとそのプロファイラの間に複数プロファイルを管理
する装置を設け，複数プロファイル管理機能を利用する
サービスからは，アクセス手段の異なるプロファイラを
統合した１つの仮想プロファイラとして見えるようにす
る。
ビスとそのプロファイラの間に複数プロファイルを管理
する装置を設け，複数プロファイル管理機能を利用する
サービスからは，アクセス手段の異なるプロファイラを
統合した１つの仮想プロファイラとして見えるようにす
る。
【０００８】すなわち，本発明は，既存のプロファイラ
を統合し，１つの仮想的なプロファイラ（統合プロファ
イラ）を提供する。これにより，既存のサービスは，専
用のプロファイラと同じプロトコルと同じデータ要素名
を使って設定情報や個人情報にアクセスできるうえ，さ
らに，他のサービスが利用している設定情報や個人情報
にも，そのサービス専用のプロトコルを使ってアクセス
することができる。このため，サービスの機能拡張の際
に必要となるユーザとサービス提供者の負担が軽減され
る。
を統合し，１つの仮想的なプロファイラ（統合プロファ
イラ）を提供する。これにより，既存のサービスは，専
用のプロファイラと同じプロトコルと同じデータ要素名
を使って設定情報や個人情報にアクセスできるうえ，さ
らに，他のサービスが利用している設定情報や個人情報
にも，そのサービス専用のプロトコルを使ってアクセス
することができる。このため，サービスの機能拡張の際
に必要となるユーザとサービス提供者の負担が軽減され
る。
【０００９】また，既存のプロファイラの統合により，
異なるサービスで利用される共通の設定情報や個人情報
に変更の必要が生じた場合に，ユーザは仮想の統合プロ
ファイラを１度だけ変更すればよい。ここで，仮想の統
合プロファイラとは，各サービスおよびユーザからプロ
ファイラを見た場合に，物理的に複数のプロファイラが
存在しても，それらが統一された一つのプロファイラと
して見えるようなアクセス手段が付随するプロファイラ
を意味している。
異なるサービスで利用される共通の設定情報や個人情報
に変更の必要が生じた場合に，ユーザは仮想の統合プロ
ファイラを１度だけ変更すればよい。ここで，仮想の統
合プロファイラとは，各サービスおよびユーザからプロ
ファイラを見た場合に，物理的に複数のプロファイラが
存在しても，それらが統一された一つのプロファイラと
して見えるようなアクセス手段が付随するプロファイラ
を意味している。
【００１０】
【発明の実施の形態】図１は，本発明に係る装置のブロ
ック構成図である。複数プロファイル管理装置１は，統
合アクセス部２，名前管理部３，データ要素対応テーブ
ル記憶部３０，プロファイルアクセス部４およびデータ
要素対応テーブル作成部５から構成される。
ック構成図である。複数プロファイル管理装置１は，統
合アクセス部２，名前管理部３，データ要素対応テーブ
ル記憶部３０，プロファイルアクセス部４およびデータ
要素対応テーブル作成部５から構成される。
【００１１】プロファイルアクセス部４は，複数のプロ
ファイルアクセスインタフェース４０を備え，これらの
各々はプロファイラ５０の異なるアクセスプロトコル毎
に用意され，名前管理部３に対して１種類のプロファイ
ルアクセスのためのインタフェースを提供する。例え
ば，プロファイラ５０Ａに対してプロファイルアクセス
インタフェース４０Ａが用意され，同様に，プロファイ
ラ５０Ｂに対してプロファイルアクセスインタフェース
４０Ｂが，プロファイラ５０Ｚに対してプロファイルア
クセスインタフェース４０Ｚが用意される。各プロファ
イルアクセスインタフェース４０Ａ−４０Ｚは，それぞ
れ独立したモジュールとして組み込み可能であり，新た
な種類のプロファイラ５０Ｘの接続に対して，そのプロ
ファイラ５０Ｘに対するアクセスプロトコルに応じたプ
ロファイルアクセスインタフェース４０Ｘを簡単に組み
込むことができる。
ファイルアクセスインタフェース４０を備え，これらの
各々はプロファイラ５０の異なるアクセスプロトコル毎
に用意され，名前管理部３に対して１種類のプロファイ
ルアクセスのためのインタフェースを提供する。例え
ば，プロファイラ５０Ａに対してプロファイルアクセス
インタフェース４０Ａが用意され，同様に，プロファイ
ラ５０Ｂに対してプロファイルアクセスインタフェース
４０Ｂが，プロファイラ５０Ｚに対してプロファイルア
クセスインタフェース４０Ｚが用意される。各プロファ
イルアクセスインタフェース４０Ａ−４０Ｚは，それぞ
れ独立したモジュールとして組み込み可能であり，新た
な種類のプロファイラ５０Ｘの接続に対して，そのプロ
ファイラ５０Ｘに対するアクセスプロトコルに応じたプ
ロファイルアクセスインタフェース４０Ｘを簡単に組み
込むことができる。
【００１２】統合アクセス部２は，各サービス１０がプ
ロファイラ５０を利用する時のプロトコルを理解し，プ
ロファイラ５０中のデータ要素に対する追加，削除，参
照，更新リクエストを翻訳して，名前管理部３にサービ
ス１０からのリクエストを伝える統合アクセスインタフ
ェース２０を提供する。
ロファイラ５０を利用する時のプロトコルを理解し，プ
ロファイラ５０中のデータ要素に対する追加，削除，参
照，更新リクエストを翻訳して，名前管理部３にサービ
ス１０からのリクエストを伝える統合アクセスインタフ
ェース２０を提供する。
【００１３】統合アクセスインタフェース２０は，サー
ビス１０とプロファイラ５０がある特定のプロトコルを
使って既に運用されている場合に，そのサービス１０と
プロファイラ５０の実装を変更せずに複数プロファイル
管理機能を付加する場合に役に立つ。
ビス１０とプロファイラ５０がある特定のプロトコルを
使って既に運用されている場合に，そのサービス１０と
プロファイラ５０の実装を変更せずに複数プロファイル
管理機能を付加する場合に役に立つ。
【００１４】名前管理部３は，統合アクセス部２の統合
アクセスインタフェース２０を通じてサービス１０から
のプロファイルアクセス要求を受け取り，データ要素対
応テーブル記憶部３０を参照して，要求のパラメータに
含まれる仮想データ要素名から物理的なプロファイラ名
（プロファイラの物理アドレス）と実際のデータ要素名
との対データを求め，仮想データ要素名をその対データ
に変換し，プロファイルアクセス要求を対応するプロフ
ァイルアクセス部４のプロファイルアクセスインタフェ
ース４０に転送する。
アクセスインタフェース２０を通じてサービス１０から
のプロファイルアクセス要求を受け取り，データ要素対
応テーブル記憶部３０を参照して，要求のパラメータに
含まれる仮想データ要素名から物理的なプロファイラ名
（プロファイラの物理アドレス）と実際のデータ要素名
との対データを求め，仮想データ要素名をその対データ
に変換し，プロファイルアクセス要求を対応するプロフ
ァイルアクセス部４のプロファイルアクセスインタフェ
ース４０に転送する。
【００１５】データ要素対応テーブル記憶部３０は，仮
想データ要素名と，プロファイラ名およびデータ要素名
からなる対データとの対応テーブルを記憶する。図１の
例では，対応テーブルとして，すべてのサービスとユー
ザとに共通に使われる共通対応テーブル３１と，ユーザ
毎にカスタマイズされるユーザ用対応テーブル３２と，
サービス毎に管理するサービス用対応テーブル３３とが
ある。これらは，ユーザ用対応テーブル３２，サービス
用対応テーブル３３，共通対応テーブル３１の優先順位
で参照されるが，少なくともこれらのうちの１つのテー
ブルがあれば本発明の実施には十分である。
想データ要素名と，プロファイラ名およびデータ要素名
からなる対データとの対応テーブルを記憶する。図１の
例では，対応テーブルとして，すべてのサービスとユー
ザとに共通に使われる共通対応テーブル３１と，ユーザ
毎にカスタマイズされるユーザ用対応テーブル３２と，
サービス毎に管理するサービス用対応テーブル３３とが
ある。これらは，ユーザ用対応テーブル３２，サービス
用対応テーブル３３，共通対応テーブル３１の優先順位
で参照されるが，少なくともこれらのうちの１つのテー
ブルがあれば本発明の実施には十分である。
【００１６】また，これらの対応テーブルの複数を階層
的に組み合わせたテーブル構成とすることも可能であ
る。図２の例では，すべてのサービスとユーザとに共通
に使われる共通対応テーブル３１のほかに，各ユーザ毎
にユーザ用対応テーブル３２−１，３２−２，…が設け
られ，各ユーザ用対応テーブルは，さらに各サービス毎
に，仮想データ要素名と，プロファイラ名とデータ要素
名とからなる対データとの対応情報を保持している。
的に組み合わせたテーブル構成とすることも可能であ
る。図２の例では，すべてのサービスとユーザとに共通
に使われる共通対応テーブル３１のほかに，各ユーザ毎
にユーザ用対応テーブル３２−１，３２−２，…が設け
られ，各ユーザ用対応テーブルは，さらに各サービス毎
に，仮想データ要素名と，プロファイラ名とデータ要素
名とからなる対データとの対応情報を保持している。
【００１７】これらの対応テーブルを複数プロファイル
管理装置１の内部に持たずに，外部の記憶装置もしくは
外部のサーバ装置内に持つようにしてもよい。
管理装置１の内部に持たずに，外部の記憶装置もしくは
外部のサーバ装置内に持つようにしてもよい。
【００１８】また，データ要素対応テーブル記憶部３０
には，新しいプロファイラ５０の作成もしくは既存のプ
ロファイラ５０の変更時に，対応テーブルを自動作成／
変更するための対応テーブル作成ルール３４を格納して
おくこともできる。データ要素対応テーブル作成部５
は，システム管理者，ユーザまたはサービス提供者から
の指示により，必要に応じて対応テーブル作成ルール３
４を用いて，共通対応テーブル３１，ユーザ用対応テー
ブル３２またはサービス用対応テーブル３３の作成，変
更を行う。
には，新しいプロファイラ５０の作成もしくは既存のプ
ロファイラ５０の変更時に，対応テーブルを自動作成／
変更するための対応テーブル作成ルール３４を格納して
おくこともできる。データ要素対応テーブル作成部５
は，システム管理者，ユーザまたはサービス提供者から
の指示により，必要に応じて対応テーブル作成ルール３
４を用いて，共通対応テーブル３１，ユーザ用対応テー
ブル３２またはサービス用対応テーブル３３の作成，変
更を行う。
【００１９】図１に示す装置の作用は，以下のとおりで
ある。名前管理部３は，統合アクセス部２の統合アクセ
スインタフェース２０から，データ要素の追加，削除，
参照または更新リクエストを受け取ると，そのリクエス
トのパラメータに物理的なプロファイラ名（プロファイ
ラの物理アドレス）が含まれるかどうかをチェックす
る。プロファイラ名が含まれる場合には，それに対応す
るプロファイルアクセス部４のプロファイルアクセスイ
ンタフェース４０に対して，追加，削除，参照または更
新リクエストを送信する。
ある。名前管理部３は，統合アクセス部２の統合アクセ
スインタフェース２０から，データ要素の追加，削除，
参照または更新リクエストを受け取ると，そのリクエス
トのパラメータに物理的なプロファイラ名（プロファイ
ラの物理アドレス）が含まれるかどうかをチェックす
る。プロファイラ名が含まれる場合には，それに対応す
るプロファイルアクセス部４のプロファイルアクセスイ
ンタフェース４０に対して，追加，削除，参照または更
新リクエストを送信する。
【００２０】リクエストにプロファイラ名が含まれない
場合には，リクエスト情報（送信元アドレスや認証情報
など）からユーザ名とサービス名を取得し，それらに対
応するデータ要素対応テーブル（ユーザ用対応テーブル
３２またはサービス用対応テーブル３３）がデータ要素
対応テーブル記憶部３０に存在するかどうかをチェック
する。もし，該当するテーブルがなかった場合，あるい
は該当するテーブルにおいて指定された仮想データ要素
名が検索されなかった場合には，共通対応テーブル３１
を仮想データ要素名をキーにして検索し，プロファイラ
名と実際のデータ要素名を取得する。
場合には，リクエスト情報（送信元アドレスや認証情報
など）からユーザ名とサービス名を取得し，それらに対
応するデータ要素対応テーブル（ユーザ用対応テーブル
３２またはサービス用対応テーブル３３）がデータ要素
対応テーブル記憶部３０に存在するかどうかをチェック
する。もし，該当するテーブルがなかった場合，あるい
は該当するテーブルにおいて指定された仮想データ要素
名が検索されなかった場合には，共通対応テーブル３１
を仮想データ要素名をキーにして検索し，プロファイラ
名と実際のデータ要素名を取得する。
【００２１】名前管理部３は，プロファイラ名と実際の
データ要素名が取得できたら，そのプロファイラ５０に
対応するプロファイルアクセス部４のプロファイルアク
セスインタフェース４０に対して，取得された実際のデ
ータ要素名に対する追加，削除，参照，更新リクエスト
を送信し，リクエスト結果を待つ。リクエスト結果が返
送されたら，その結果を統合アクセス部２に転送する。
データ要素名が取得できたら，そのプロファイラ５０に
対応するプロファイルアクセス部４のプロファイルアク
セスインタフェース４０に対して，取得された実際のデ
ータ要素名に対する追加，削除，参照，更新リクエスト
を送信し，リクエスト結果を待つ。リクエスト結果が返
送されたら，その結果を統合アクセス部２に転送する。
【００２２】次に，具体例に従って本発明の実施の形態
をさらに詳しく説明する。サービスが利用するプロファ
イラとしては，各サービスに閉じた独自の実装のものか
ら標準的なプロトコルを利用したものまで各種存在す
る。標準的なプロトコルとしては，ディレクトリサーバ
として知られるＬＤＡＰ(Lightweight Directory Acces
s Protocol）や多くのデータベースが採用しているＳＱ
Ｌ(Structured Query Language）およびＯＤＢＣ（Open
DataBase Connectivity）等のインタフェースが例とし
て挙げられる。また，Ｗｅｂサービスの多くはＨＴＴＰ
プロトコルによるプロファイルアクセスを独自に実装し
ている場合もある。
をさらに詳しく説明する。サービスが利用するプロファ
イラとしては，各サービスに閉じた独自の実装のものか
ら標準的なプロトコルを利用したものまで各種存在す
る。標準的なプロトコルとしては，ディレクトリサーバ
として知られるＬＤＡＰ(Lightweight Directory Acces
s Protocol）や多くのデータベースが採用しているＳＱ
Ｌ(Structured Query Language）およびＯＤＢＣ（Open
DataBase Connectivity）等のインタフェースが例とし
て挙げられる。また，Ｗｅｂサービスの多くはＨＴＴＰ
プロトコルによるプロファイルアクセスを独自に実装し
ている場合もある。
【００２３】以下で説明する例では，統合アクセス部２
において統合アクセスインタフェース２０ＢがＨＴＴＰ
を実装しており，また，プロファイルアクセス部４にお
いてプロファイルアクセスインタフェース４０ＢがＳＱ
Ｌを実装しているものとする。サービス１０Ｂは，統合
アクセスインタフェース２０Ｂ，名前管理部３，プロフ
ァイルアクセスインタフェース４０Ｂを通じて，データ
ベースに格納されたプロファイル情報にアクセスする。
において統合アクセスインタフェース２０ＢがＨＴＴＰ
を実装しており，また，プロファイルアクセス部４にお
いてプロファイルアクセスインタフェース４０ＢがＳＱ
Ｌを実装しているものとする。サービス１０Ｂは，統合
アクセスインタフェース２０Ｂ，名前管理部３，プロフ
ァイルアクセスインタフェース４０Ｂを通じて，データ
ベースに格納されたプロファイル情報にアクセスする。
【００２４】統合アクセス部２の統合アクセスインタフ
ェース２０Ｂは，例えば以下のようなフォーマットのＨ
ＴＴＰリクエストを受け取る。
ェース２０Ｂは，例えば以下のようなフォーマットのＨ
ＴＴＰリクエストを受け取る。
【００２５】http://host/UserProfile/?uid=28539&com
mand=read&name=a このＨＴＴＰリクエストに対して，統合アクセスインタ
フェース２０Ｂは，uid=28539 はユーザ名，command=re
adは参照要求，name=aは仮想データ要素名が“ａ”であ
ることを示すため，以下のような情報を抽出する。
mand=read&name=a このＨＴＴＰリクエストに対して，統合アクセスインタ
フェース２０Ｂは，uid=28539 はユーザ名，command=re
adは参照要求，name=aは仮想データ要素名が“ａ”であ
ることを示すため，以下のような情報を抽出する。
【００２６】｛command:参照, name:"a", user:"28539
｝ 名前管理部３は，プロファイラ５０Ｂの物理アドレスと
そのプロファイラ内データ要素の実名とからなる対デー
タと，複数プロファイル管理装置１で利用される仮想デ
ータ要素名との対応情報を，共通対応テーブル３１，ユ
ーザ用対応テーブル３２またはサービス用対応テーブル
３３としてデータ要素対応テーブル記憶部３０内に管理
している。
｝ 名前管理部３は，プロファイラ５０Ｂの物理アドレスと
そのプロファイラ内データ要素の実名とからなる対デー
タと，複数プロファイル管理装置１で利用される仮想デ
ータ要素名との対応情報を，共通対応テーブル３１，ユ
ーザ用対応テーブル３２またはサービス用対応テーブル
３３としてデータ要素対応テーブル記憶部３０内に管理
している。
【００２７】名前管理部３は，仮想データ要素名〔nam
e:"a"〕をキーにデータ要素対応テーブル記憶部３０中
の対応テーブルを参照することにより，物理的なプロフ
ァイラ５０Ｂのアドレス〔Ｐ１〕を取得し，以下のよう
な情報に変換する。
e:"a"〕をキーにデータ要素対応テーブル記憶部３０中
の対応テーブルを参照することにより，物理的なプロフ
ァイラ５０Ｂのアドレス〔Ｐ１〕を取得し，以下のよう
な情報に変換する。
【００２８】｛command:参照, profile:"P1", name:"
a", user:"28539 ｝ 対応テーブルから得た“Ｐ１”は物理的なプロファイラ
名を示し，これにより対応するプロファイルアクセス部
４のプロファイルアクセスインタフェース４０Ｂが選択
されることになる。
a", user:"28539 ｝ 対応テーブルから得た“Ｐ１”は物理的なプロファイラ
名を示し，これにより対応するプロファイルアクセス部
４のプロファイルアクセスインタフェース４０Ｂが選択
されることになる。
【００２９】ここで，選択されたプロファイルアクセス
インタフェース４０Ｂが，以下のようにＳＱＬコマンド
によるデータベースアクセスをＪａｖａ言語で実装して
いたとする。
インタフェース４０Ｂが，以下のようにＳＱＬコマンド
によるデータベースアクセスをＪａｖａ言語で実装して
いたとする。
【００３０】connection = DriverManager.getConnecti
on("jdbc：odbc：//host/profile",null, null) ;state
ment = connection.prepareStatement("SELECT ? FROM
? WHERE USER=?");statement.setString(1,"a");statem
ent.setString(2,"P1");statement.setString(3,"2853
9");result = statement.executeQuery();return resul
t.getString("a");これによって，プロファイルアクセ
スインタフェース４０Ｂは，名前管理部３から得た情報
にもとづき，データベース“Ｐ１”に格納されたユーザ
“２８５３９”のデータ要素“ａ”を取得する。
on("jdbc：odbc：//host/profile",null, null) ;state
ment = connection.prepareStatement("SELECT ? FROM
? WHERE USER=?");statement.setString(1,"a");statem
ent.setString(2,"P1");statement.setString(3,"2853
9");result = statement.executeQuery();return resul
t.getString("a");これによって，プロファイルアクセ
スインタフェース４０Ｂは，名前管理部３から得た情報
にもとづき，データベース“Ｐ１”に格納されたユーザ
“２８５３９”のデータ要素“ａ”を取得する。
【００３１】［名前管理部における変換例（その１）］
図３に，要素名“ａ”，“ｂ”，“ｅ”，“ｆ”を持つ
プロファイラ５０Ａと，要素名“ｃ”，“ｄ”，
“ｅ”，“ｆ”を持つプロファイラ５０Ｂが存在した場
合の，複数プロファイル管理装置１におけるデータ要素
対応テーブル記憶部３０のテーブルの例を示す。この例
では，共通対応テーブル３１だけ存在し，ユーザ用対応
テーブル３２およびサービス用対応テーブル３３は存在
しないものとする。
図３に，要素名“ａ”，“ｂ”，“ｅ”，“ｆ”を持つ
プロファイラ５０Ａと，要素名“ｃ”，“ｄ”，
“ｅ”，“ｆ”を持つプロファイラ５０Ｂが存在した場
合の，複数プロファイル管理装置１におけるデータ要素
対応テーブル記憶部３０のテーブルの例を示す。この例
では，共通対応テーブル３１だけ存在し，ユーザ用対応
テーブル３２およびサービス用対応テーブル３３は存在
しないものとする。
【００３２】ここで，あるサービスが複数プロファイル
管理装置１に対して，要素名“ａ”の値を要求した場
合，名前管理部３において要素名“ａ”に対応するデー
タとして｛Ａ，”ａ”｝が取得され，要求元のサービス
はプロファイラ５０Ａを指定せずに要素名“ａ”の指定
だけで，プロファイラ５０Ａからそのデータ要素の値
“１０００”を取得することができる。
管理装置１に対して，要素名“ａ”の値を要求した場
合，名前管理部３において要素名“ａ”に対応するデー
タとして｛Ａ，”ａ”｝が取得され，要求元のサービス
はプロファイラ５０Ａを指定せずに要素名“ａ”の指定
だけで，プロファイラ５０Ａからそのデータ要素の値
“１０００”を取得することができる。
【００３３】また，あるサービスが複数プロファイル管
理装置１に対して，要素名“ｅ”の値を“Ｔｏｓｈｉ”
に更新する要求を出した場合，名前管理部３において，
データ要素対応テーブル記憶部３０における対応データ
として｛Ａ，”ｅ”｝と｛Ｂ，”ｅ”｝の２つが取得さ
れる。このため，プロファイラ５０Ａのデータ要素
“ｅ”とプロファイラ５０Ｂのデータ要素“ｅ”は共
に，“Ｆｕｊｉ”から“Ｔｏｓｈｉ”に書き換えられ
る。現実的には，このような複数箇所の同時書き換えを
安全に行うためには，一般によく知られたトランザクシ
ョン機能を名前管理部３が持つ必要がある。
理装置１に対して，要素名“ｅ”の値を“Ｔｏｓｈｉ”
に更新する要求を出した場合，名前管理部３において，
データ要素対応テーブル記憶部３０における対応データ
として｛Ａ，”ｅ”｝と｛Ｂ，”ｅ”｝の２つが取得さ
れる。このため，プロファイラ５０Ａのデータ要素
“ｅ”とプロファイラ５０Ｂのデータ要素“ｅ”は共
に，“Ｆｕｊｉ”から“Ｔｏｓｈｉ”に書き換えられ
る。現実的には，このような複数箇所の同時書き換えを
安全に行うためには，一般によく知られたトランザクシ
ョン機能を名前管理部３が持つ必要がある。
【００３４】［対応テーブル作成ルールの例］データ要
素対応テーブル記憶部３０に記憶する対応テーブルを自
動生成するための対応テーブル作成ルール３４として，
以下のような定義が例として考えられる。ここで同期と
は，複数のプロファイラに存在するデータ要素が実質的
に一つのものとして扱われ，それらの一つが更新される
と他の関連するデータ要素も同じように更新される操作
を意味する。
素対応テーブル記憶部３０に記憶する対応テーブルを自
動生成するための対応テーブル作成ルール３４として，
以下のような定義が例として考えられる。ここで同期と
は，複数のプロファイラに存在するデータ要素が実質的
に一つのものとして扱われ，それらの一つが更新される
と他の関連するデータ要素も同じように更新される操作
を意味する。
【００３５】ｒｕｌｅ１＝値が同じデータ要素は同期す
る ｒｕｌｅ２＝データ要素名が一致する場合は同期する ｒｕｌｅ３＝例外：“ｆ”→｛Ｂ，“ｆ”｝ … … このルール定義により，データ要素対応テーブル作成部
５では，例えば，図３に示す共通対応テーブル３１を，
プロファイラ５０Ａとプロファイラ５０Ｂの内容を調べ
ることにより自動生成することができる。なお，対応テ
ーブル作成ルール３４は，共通対応テーブル３１，ユー
ザ用対応テーブル３２およびサービス用対応テーブル３
３のそれぞれに対して，別々に用意しておくことができ
る。
る ｒｕｌｅ２＝データ要素名が一致する場合は同期する ｒｕｌｅ３＝例外：“ｆ”→｛Ｂ，“ｆ”｝ … … このルール定義により，データ要素対応テーブル作成部
５では，例えば，図３に示す共通対応テーブル３１を，
プロファイラ５０Ａとプロファイラ５０Ｂの内容を調べ
ることにより自動生成することができる。なお，対応テ
ーブル作成ルール３４は，共通対応テーブル３１，ユー
ザ用対応テーブル３２およびサービス用対応テーブル３
３のそれぞれに対して，別々に用意しておくことができ
る。
【００３６】［名前管理部における変換例（その２）］
図４に，ユーザ毎あるいはサービス毎にデータ要素名と
各プロファイラのデータ要素とのユーザ用対応テーブル
あるいはサービス用対応テーブルを独自に用意して，カ
スタマイズ可能にした場合のテーブルの使用例を示す。
この例は，ユーザＵ１とユーザＵ２がサービス１０Ａを
使ってデータ要素名“ｆ”を参照しようとした場合の例
である。
図４に，ユーザ毎あるいはサービス毎にデータ要素名と
各プロファイラのデータ要素とのユーザ用対応テーブル
あるいはサービス用対応テーブルを独自に用意して，カ
スタマイズ可能にした場合のテーブルの使用例を示す。
この例は，ユーザＵ１とユーザＵ２がサービス１０Ａを
使ってデータ要素名“ｆ”を参照しようとした場合の例
である。
【００３７】ユーザ用対応テーブル３２が存在する場
合，名前管理部３は，ユーザ用対応テーブル３２を共通
対応テーブル３１よりも優先してデータ要素名のマッピ
ングに使用する。したがって，ユーザＵ１からのデータ
要素名“ｆ”を指定した要求に対して，データ要素名
“ｆ”は，ユーザ（Ｕ１）用対応テーブル３２−１の参
照により｛Ａ，“ｆ”｝，｛Ｂ，“ｆ”｝に変換され，
ユーザＵ１のデータ要素“ｆ”に対する参照リクエスト
は，プロファイラ５０Ａまたはプロファイラ５０Ｂのデ
ータ要素“ｆ”への参照となる。更新リクエストの場
合，これら２つのデータ要素は常に同期的に更新される
ように振る舞う。
合，名前管理部３は，ユーザ用対応テーブル３２を共通
対応テーブル３１よりも優先してデータ要素名のマッピ
ングに使用する。したがって，ユーザＵ１からのデータ
要素名“ｆ”を指定した要求に対して，データ要素名
“ｆ”は，ユーザ（Ｕ１）用対応テーブル３２−１の参
照により｛Ａ，“ｆ”｝，｛Ｂ，“ｆ”｝に変換され，
ユーザＵ１のデータ要素“ｆ”に対する参照リクエスト
は，プロファイラ５０Ａまたはプロファイラ５０Ｂのデ
ータ要素“ｆ”への参照となる。更新リクエストの場
合，これら２つのデータ要素は常に同期的に更新される
ように振る舞う。
【００３８】一方，ユーザＵ２が同じようにデータ要素
“ｆ”に対するアクセスを行った場合，ユーザ２のユー
ザ（Ｕ２）用対応テーブル３２−２には，データ要素名
“ｆ”に対するマッピングのエントリがないため，リク
エストのパラメータで指定されたデータ要素“ｆ”は，
各ユーザおよび各サービスが共用する共通対応テーブル
３１から，プロファイル５０Ｂのデータ要素“ｆ”への
参照にマッピングされ，プロファイル５０Ａの“ｆ”と
は独立に扱われるようになる。
“ｆ”に対するアクセスを行った場合，ユーザ２のユー
ザ（Ｕ２）用対応テーブル３２−２には，データ要素名
“ｆ”に対するマッピングのエントリがないため，リク
エストのパラメータで指定されたデータ要素“ｆ”は，
各ユーザおよび各サービスが共用する共通対応テーブル
３１から，プロファイル５０Ｂのデータ要素“ｆ”への
参照にマッピングされ，プロファイル５０Ａの“ｆ”と
は独立に扱われるようになる。
【００３９】ユーザＵ１のように，１対多のマッピング
を行う具体的な例としては，ＬＤＡＰサーバで管理され
ている自分の電話番号とデータベースで管理されている
自分の電話番号を同期して管理したい場合などがこれに
当たる。
を行う具体的な例としては，ＬＤＡＰサーバで管理され
ている自分の電話番号とデータベースで管理されている
自分の電話番号を同期して管理したい場合などがこれに
当たる。
【００４０】また図４の例では，ユーザＵ２からは，デ
ータ要素“ａ”とデータ要素名“ｃ”は共にプロファイ
ラ５０Ｂのデータ要素“ｃ”にマッピングされるように
カスタマイズされている。このような多対１へのマッピ
ングの具体的な使用例としては，例えばユーザＵ２が２
つのメールアドレスを持っており，それら２つのメール
アドレスに届いたメールを１つのメールボックスで管理
したいような場合がこれに当たる。
ータ要素“ａ”とデータ要素名“ｃ”は共にプロファイ
ラ５０Ｂのデータ要素“ｃ”にマッピングされるように
カスタマイズされている。このような多対１へのマッピ
ングの具体的な使用例としては，例えばユーザＵ２が２
つのメールアドレスを持っており，それら２つのメール
アドレスに届いたメールを１つのメールボックスで管理
したいような場合がこれに当たる。
【００４１】図５に，統合プロファイル・カスタマイズ
のための画面表示例を示す。図５の画面例に示されるよ
うに，ある要素名を物理的なプロファイルにマッピング
（対応付け）する場合に，要素名マッピングテーブルか
ら変更したい要素の行を１または複数行選択し，選択し
た行を画面右側の利用可能プロファルのアイコンのいず
れかにドラッグ・アンド・ドロップする。既に１つ以上
のプロファイルへの対応が存在する状態でこの操作を行
うと，複数プロファイルへのマッピングを追加すること
になる。各要素のプロファイルのマッピングを変更する
場合には，変更したい要素の行を選択し，編集ボタンを
押すことにより表示される編集ダイアログ上で処理を行
う。要素名や要素値などを変更する場合にも同様に編集
ダイアログ上で処理を行う。
のための画面表示例を示す。図５の画面例に示されるよ
うに，ある要素名を物理的なプロファイルにマッピング
（対応付け）する場合に，要素名マッピングテーブルか
ら変更したい要素の行を１または複数行選択し，選択し
た行を画面右側の利用可能プロファルのアイコンのいず
れかにドラッグ・アンド・ドロップする。既に１つ以上
のプロファイルへの対応が存在する状態でこの操作を行
うと，複数プロファイルへのマッピングを追加すること
になる。各要素のプロファイルのマッピングを変更する
場合には，変更したい要素の行を選択し，編集ボタンを
押すことにより表示される編集ダイアログ上で処理を行
う。要素名や要素値などを変更する場合にも同様に編集
ダイアログ上で処理を行う。
【００４２】図６に，名前管理部３の処理フローを示
す。名前管理部３では，統合アクセス部２からのデータ
要素の追加，削除，参照，更新リクエストを待ち（ステ
ップＳ１），リクエストを受け取ると，そのリクエスト
のパラメータに物理的なプロファイラ名（プロファイラ
の物理アドレス）が含まれるかどうかをチェックする
（ステップＳ２）。物理的なプロファイラ名が含まれる
場合には，ステップＳ１０へ進む。
す。名前管理部３では，統合アクセス部２からのデータ
要素の追加，削除，参照，更新リクエストを待ち（ステ
ップＳ１），リクエストを受け取ると，そのリクエスト
のパラメータに物理的なプロファイラ名（プロファイラ
の物理アドレス）が含まれるかどうかをチェックする
（ステップＳ２）。物理的なプロファイラ名が含まれる
場合には，ステップＳ１０へ進む。
【００４３】リクエストにプロファイラ名が含まれない
場合には，リクエスト情報（送信元アドレスや認証情報
など）からユーザ名とサービス名を取得し（ステップＳ
３），それらに対応するユーザ用対応テーブル３２（ま
たはサービス用対応テーブル３３）がデータ要素対応テ
ーブル記憶部３０に存在するかどうかをチェックする
（ステップＳ４）。該当するテーブルがあれば，ユーザ
用対応テーブル３２をリクエストの仮想データ要素名を
キーにして検索する（ステップＳ５）。検索した結果，
ユーザ用対応テーブル３２に該当する仮想データ要素名
があれば（ステップＳ６），ステップＳ９へ進む。
場合には，リクエスト情報（送信元アドレスや認証情報
など）からユーザ名とサービス名を取得し（ステップＳ
３），それらに対応するユーザ用対応テーブル３２（ま
たはサービス用対応テーブル３３）がデータ要素対応テ
ーブル記憶部３０に存在するかどうかをチェックする
（ステップＳ４）。該当するテーブルがあれば，ユーザ
用対応テーブル３２をリクエストの仮想データ要素名を
キーにして検索する（ステップＳ５）。検索した結果，
ユーザ用対応テーブル３２に該当する仮想データ要素名
があれば（ステップＳ６），ステップＳ９へ進む。
【００４４】もし，該当するユーザ用対応テーブル３２
がなかった場合（ステップＳ４），あるいは該当するユ
ーザ用対応テーブル３２に該当する仮想データ要素名が
なかった場合には（ステップＳ６），共通対応テーブル
３１を仮想データ要素名をキーにして検索する（ステッ
プＳ７）。検索した結果，共通対応テーブル３１に該当
する仮想データ要素名があれば（ステップＳ８），ステ
ップＳ９へ進み，共通対応テーブル３１にも該当する仮
想データ要素名がなければ，要素名なしの理由でエラー
情報を送信元の統合アクセス部２に送信する（ステップ
Ｓ１６）。
がなかった場合（ステップＳ４），あるいは該当するユ
ーザ用対応テーブル３２に該当する仮想データ要素名が
なかった場合には（ステップＳ６），共通対応テーブル
３１を仮想データ要素名をキーにして検索する（ステッ
プＳ７）。検索した結果，共通対応テーブル３１に該当
する仮想データ要素名があれば（ステップＳ８），ステ
ップＳ９へ進み，共通対応テーブル３１にも該当する仮
想データ要素名がなければ，要素名なしの理由でエラー
情報を送信元の統合アクセス部２に送信する（ステップ
Ｓ１６）。
【００４５】ステップＳ９では，ユーザ用対応テーブル
３２もしくは共通対応テーブル３１から，プロファイラ
名と実データ要素名を取得し（ステップＳ９），ステッ
プＳ１０へ進む。
３２もしくは共通対応テーブル３１から，プロファイラ
名と実データ要素名を取得し（ステップＳ９），ステッ
プＳ１０へ進む。
【００４６】ステップＳ１０では，Ｎ＝実データ要素名
の数およびｉ＝０を設定する。次に，プロファイラ名に
対応するプロファイルアクセス部４のプロファイルアク
セスインタフェース４０に対して，追加，削除，参照お
よび更新リクエストを実データ要素名をパラメータにし
て送信し（ステップＳ１１），リクエスト結果を待つ
（ステップＳ１２）。リクエスト結果がきたらｉを１カ
ウントアップし（ステップＳ１３），ｉが実データ要素
名の数Ｎになるまで，ステップＳ１１〜Ｓ１３を繰り返
す（ステップＳ１４）。その後，リクエスト結果を統合
アクセス部２に返送する（ステップＳ１５）。以上の処
理の後，ステップＳ１へ戻り，次のリクエストを待つ。
の数およびｉ＝０を設定する。次に，プロファイラ名に
対応するプロファイルアクセス部４のプロファイルアク
セスインタフェース４０に対して，追加，削除，参照お
よび更新リクエストを実データ要素名をパラメータにし
て送信し（ステップＳ１１），リクエスト結果を待つ
（ステップＳ１２）。リクエスト結果がきたらｉを１カ
ウントアップし（ステップＳ１３），ｉが実データ要素
名の数Ｎになるまで，ステップＳ１１〜Ｓ１３を繰り返
す（ステップＳ１４）。その後，リクエスト結果を統合
アクセス部２に返送する（ステップＳ１５）。以上の処
理の後，ステップＳ１へ戻り，次のリクエストを待つ。
【００４７】図７に，統合アクセス部の処理フローを示
す。統合アクセス部２では，サービス１０からのデータ
要素の追加，削除，参照，更新リクエストを待ち（ステ
ップＳ２０），リクエストを受け取ると，リクエストか
らデータ要素名，データ要素値などのパラメータを抽出
し，名前管理部３に送信して（ステップＳ２１），名前
管理部３からのリクエスト結果を待つ（ステップＳ２
２）。リクエスト結果が返送されてきたら，そのリクエ
スト結果を該当するサービス１０に返送する（ステップ
Ｓ２３）。
す。統合アクセス部２では，サービス１０からのデータ
要素の追加，削除，参照，更新リクエストを待ち（ステ
ップＳ２０），リクエストを受け取ると，リクエストか
らデータ要素名，データ要素値などのパラメータを抽出
し，名前管理部３に送信して（ステップＳ２１），名前
管理部３からのリクエスト結果を待つ（ステップＳ２
２）。リクエスト結果が返送されてきたら，そのリクエ
スト結果を該当するサービス１０に返送する（ステップ
Ｓ２３）。
【００４８】図８に，プロファイルアクセス部４の処理
フローを示す。プロファイルアクセス部４では，名前管
理部３からのデータ要素の追加，削除，参照，更新リク
エストを待ち（ステップＳ３０），リクエストを受け取
ると，コマンド，データ要素名，データ要素値をもと
に，プロファイラ５０のＡＰＩ(Application Programmi
ng Interface）に合わせてリクエストを発行し（ステッ
プＳ３１），プロファイラ５０からのリクエスト結果を
待つ（ステップＳ３２）。リクエスト結果が返送されて
きたら，そのリクエスト結果を名前管理部３に返送する
（ステップＳ３３）。
フローを示す。プロファイルアクセス部４では，名前管
理部３からのデータ要素の追加，削除，参照，更新リク
エストを待ち（ステップＳ３０），リクエストを受け取
ると，コマンド，データ要素名，データ要素値をもと
に，プロファイラ５０のＡＰＩ(Application Programmi
ng Interface）に合わせてリクエストを発行し（ステッ
プＳ３１），プロファイラ５０からのリクエスト結果を
待つ（ステップＳ３２）。リクエスト結果が返送されて
きたら，そのリクエスト結果を名前管理部３に返送する
（ステップＳ３３）。
【００４９】以上説明したように，複数プロファイル管
理装置１は，アクセスプロトコル，データ表現形式およ
び各データ名が異なる複数のプロファイラのインタフェ
ースの統一とデータ要素の名前管理を行うことにより，
仮想的な１つの統合プロファイラを提供する。特に，異
なるプロファイラに問い合わせを行うプロファイルアク
セスインタフェース４０を分離して設けることにより，
新たな種類のプロファイラの接続を容易に実現すること
ができる。
理装置１は，アクセスプロトコル，データ表現形式およ
び各データ名が異なる複数のプロファイラのインタフェ
ースの統一とデータ要素の名前管理を行うことにより，
仮想的な１つの統合プロファイラを提供する。特に，異
なるプロファイラに問い合わせを行うプロファイルアク
セスインタフェース４０を分離して設けることにより，
新たな種類のプロファイラの接続を容易に実現すること
ができる。
【００５０】また，名前管理部３では，プロファイラの
物理アドレスとそのプロファイラ内データ要素の実名と
からなる対データと，複数プロファイル管理機能で利用
される仮想データ要素名とのデータ要素対応テーブルを
管理する。これにより，プロファイラの物理アドレスを
指定せずに，仮想データ要素名を指定するだけで目的の
データにアクセスすることが可能となる。
物理アドレスとそのプロファイラ内データ要素の実名と
からなる対データと，複数プロファイル管理機能で利用
される仮想データ要素名とのデータ要素対応テーブルを
管理する。これにより，プロファイラの物理アドレスを
指定せずに，仮想データ要素名を指定するだけで目的の
データにアクセスすることが可能となる。
【００５１】また，名前管理部３では，プロファイラの
物理アドレスとそのプロファイラ内データ要素の実名と
からなる複数の対データと，１つの仮想データ要素名と
を対応付けることを許容する。このため，これに該当す
るデータ要素名の更新要求が発生した時には，対応する
複数のデータ要素を同期して更新することが可能にな
る。
物理アドレスとそのプロファイラ内データ要素の実名と
からなる複数の対データと，１つの仮想データ要素名と
を対応付けることを許容する。このため，これに該当す
るデータ要素名の更新要求が発生した時には，対応する
複数のデータ要素を同期して更新することが可能にな
る。
【００５２】また，複数プロファイル管理装置１におい
て，対応テーブル作成ルール３４を用意し，データ要素
対応テーブル作成部５が対応テーブル作成ルール３４を
評価する機能を持つ。これにより，新たなプロファイル
が複数プロファイル管理装置１に接続されたとき，ある
いは，新たなデータ要素が追加された時，自動的にデー
タ要素対応テーブルの書き換えを行うことが可能とな
る。
て，対応テーブル作成ルール３４を用意し，データ要素
対応テーブル作成部５が対応テーブル作成ルール３４を
評価する機能を持つ。これにより，新たなプロファイル
が複数プロファイル管理装置１に接続されたとき，ある
いは，新たなデータ要素が追加された時，自動的にデー
タ要素対応テーブルの書き換えを行うことが可能とな
る。
【００５３】また，複数プロファイル管理装置１では，
データ要素対応テーブル記憶部３０中の対応テーブル
を，共通用とユーザ用とに分離し，ユーザ用対応テーブ
ルはユーザによる書き換えを許容する。これにより，プ
ロファイルをアクセスするユーザ毎にデータ要素の対応
関係をカスタマイズすることが可能になる。
データ要素対応テーブル記憶部３０中の対応テーブル
を，共通用とユーザ用とに分離し，ユーザ用対応テーブ
ルはユーザによる書き換えを許容する。これにより，プ
ロファイルをアクセスするユーザ毎にデータ要素の対応
関係をカスタマイズすることが可能になる。
【００５４】同様に，複数プロファイル管理装置１で
は，データ要素対応テーブルを，共通用とサービス用と
に分離して構成することもでき，複数プロファイル管理
機能を利用するサービス毎にデータ要素の対応関係が異
なるようにすることも可能である。
は，データ要素対応テーブルを，共通用とサービス用と
に分離して構成することもでき，複数プロファイル管理
機能を利用するサービス毎にデータ要素の対応関係が異
なるようにすることも可能である。
【００５５】複数プロファイル管理装置１は，ハードウ
ェアとしては，図示省略するが例えば１または複数のＣ
ＰＵと，主記憶装置と，ハードディスク等の外部記憶装
置と，それらを接続するバス等からなるコンピュータに
よって実現される。このコンピュータを複数プロファイ
ル管理装置１として機能させるためのソフトウェアプロ
グラムは，コンピュータが読み取り可能な可搬媒体メモ
リ，半導体メモリ，ハードディスクなどの適当な記録媒
体に格納することができる。
ェアとしては，図示省略するが例えば１または複数のＣ
ＰＵと，主記憶装置と，ハードディスク等の外部記憶装
置と，それらを接続するバス等からなるコンピュータに
よって実現される。このコンピュータを複数プロファイ
ル管理装置１として機能させるためのソフトウェアプロ
グラムは，コンピュータが読み取り可能な可搬媒体メモ
リ，半導体メモリ，ハードディスクなどの適当な記録媒
体に格納することができる。
【００５６】
【発明の効果】以上述べたように，本発明を適用するこ
とにより，各種サービスが利用するプロファイラが独立
に運用されているものであっても，１つの仮想的なプロ
ファイラとして扱うことができ，重複した内容のデータ
を１回のアクセスで同期して扱うことが可能となる。
とにより，各種サービスが利用するプロファイラが独立
に運用されているものであっても，１つの仮想的なプロ
ファイラとして扱うことができ，重複した内容のデータ
を１回のアクセスで同期して扱うことが可能となる。
【００５７】また，従来サービスが使用していたアクセ
スプロトコルと同じプロトコルを統合アクセス部として
用意することにより，各サービスは従来のプロトコルの
まま統合されたプロファイラにアクセスすることがで
き，既存サービスに対する影響が小さい。このようなプ
ロファイルの共有により，新規サービスを追加した場合
のサービス提供者とユーザの双方の負担を軽減できる効
果は大きい。
スプロトコルと同じプロトコルを統合アクセス部として
用意することにより，各サービスは従来のプロトコルの
まま統合されたプロファイラにアクセスすることがで
き，既存サービスに対する影響が小さい。このようなプ
ロファイルの共有により，新規サービスを追加した場合
のサービス提供者とユーザの双方の負担を軽減できる効
果は大きい。
【図１】本発明に係る装置のブロック構成図である。
【図２】データ要素対応テーブル記憶部の構成例を示す
図である。
図である。
【図３】データ要素対応テーブル記憶部のテーブルの具
体例を示す図である。
体例を示す図である。
【図４】データ要素対応テーブル記憶部のテーブルの具
体例を示す図である。
体例を示す図である。
【図５】統合プロファイル・カスタマイズのための画面
表示例を示す図である。
表示例を示す図である。
【図６】名前管理部の処理フロー図である。
【図７】統合アクセス部の処理フロー図である。
【図８】プロファイルアクセス部の処理フロー図であ
る。
る。
【図９】従来技術の説明図である。
【符号の説明】 １ 複数プロファイル管理装置 ２ 統合アクセス部 ３ 名前管理部 ４ プロファイルアクセス部 ５ データ要素対応テーブル作成部 １０ サービス ２０ 統合アクセスインタフェース ３０ データ要素対応テーブル記憶部 ３１ 共通対応テーブル ３２ ユーザ用対応テーブル ３３ サービス用対応テーブル ３４ 対応テーブル作成ルール ４０ プロファイルアクセスインタフェース ５０ プロファイラ
フロントページの続き (72)発明者 高田 裕志 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 Ｆターム(参考） 5B075 KK03 NK02 PQ05 5B082 GA15 HA07
Claims (9)
- 【請求項１】 アクセスプロトコル，データ表現形式ま
たは各データ要素名が異なる複数のプロファイラを接続
する複数プロファイル管理装置であって，各サービスに
対して定められたアクセスプロトコルにより前記プロフ
ァイラに対するアクセス要求を受け付ける統合アクセス
部と，前記アクセス要求において指定されたデータ要素
名を，前記プロファイラにおける実際の格納場所に関す
る情報に変換する名前管理部と，前記名前管理部によっ
て変換された格納場所の情報に基づき，前記プロファイ
ラにアクセスするプロファイルアクセス部とを備えるこ
とを特徴とする複数プロファイル管理装置。 - 【請求項２】 請求項１記載の複数プロファイル管理装
置において，前記プロファイルアクセス部は，前記複数
のプロファイラにアクセスする複数のプロファイルアク
セスインタフェースからなり，新たな種類のプロファイ
ラの接続に対して新たなプロファイルアクセスインタフ
ェースを追加可能に構成されていること特徴とする複数
プロファイル管理装置。 - 【請求項３】 請求項１または請求項２記載の複数プロ
ファイル管理装置において，サービスが使用するプロフ
ァイラのデータ要素名と，そのデータ要素名に対応する
プロファイラの物理アドレスおよびそのプロファイラ内
データ要素の実名との対応情報を保持するデータ要素対
応情報記憶部を備え，前記名前管理部は，前記データ要
素対応情報記憶部を参照し，前記アクセス要求で指定さ
れたデータ要素名から目的とするデータの格納場所を特
定することを特徴とする複数プロファイル管理装置。 - 【請求項４】 請求項３記載の複数プロファイル管理装
置において，前記データ要素対応情報記憶部は，サービ
スが使用するプロファイラの１つのデータ要素名に対し
て，プロファイラの物理アドレスおよびそのプロファイ
ラ内データ要素の実名からなる複数の対データを対応付
け可能に構成され，これに該当するデータ要素名の更新
要求が発生したときには，前記名前管理部および前記プ
ロファイルアクセス部により，対応する複数のデータ要
素を同期して更新することを特徴とする複数プロファイ
ル管理装置。 - 【請求項５】 請求項３または請求項４記載の複数プロ
ファイル管理装置において，前記データ要素対応情報記
憶部は，全ユーザに対して共通に適用する対応情報のテ
ーブルと，各ユーザ別または／および各サービス別に適
用する対応情報のテーブルとを記憶し，前記名前管理部
は，前記各ユーザ別または／および各サービス別に適用
する対応情報のテーブルを，前記全ユーザに対して共通
に適用する対応情報のテーブルよりも優先的に用いるこ
とを特徴とする複数プロファイル管理装置。 - 【請求項６】 アクセスプロトコル，データ表現形式ま
たは各データ要素名が異なる複数のプロファイラを接続
する複数プロファイル管理装置であって，サービスが使
用するプロファイラのデータ要素名と，そのデータ要素
名に対応するプロファイラの物理アドレスおよびそのプ
ロファイラ内データ要素の実名との対応情報を保持する
データ要素対応情報記憶部と，各サービスに対して定め
られたアクセスプロトコルにより前記プロファイラに対
するアクセス要求を受け付ける統合アクセス部と，前記
アクセス要求で指定されたデータ要素名を，前記データ
要素対応情報記憶部を参照して前記プロファイラにおけ
る実際の格納場所に関する情報に変換する名前管理部
と，前記名前管理部によって変換された格納場所の情報
に基づき，前記プロファイラにアクセスするプロファイ
ルアクセス部と，新たなプロファイラの接続またはプロ
ファイラに対する新たなデータ要素の追加に対して，前
記データ要素対応情報記憶部に記憶する対応情報を，あ
らかじめ入力された対応情報作成ルールに従って作成す
るデータ要素対応情報作成部とを備えることを特徴とす
る複数プロファイル管理装置。 - 【請求項７】 アクセスプロトコル，データ表現形式ま
たは各データ要素名が異なる複数のプロファイラを接続
する装置における複数プロファイル管理方法であって，
各サービスに対して定められたアクセスプロトコルに応
じて用意された統合アクセスインタフェースによって前
記プロファイラに対するアクセス要求を受け付ける過程
と，前記アクセス要求において指定されたデータ要素名
を，あらかじめ登録されているデータ要素対応情報に基
づいて前記プロファイラにおける実際の格納場所に関す
る情報に変換する過程と，前記変換された格納場所の情
報に基づき，前記プロファイラに対するアクセスプロト
コルに応じたプロファイルアクセスインタフェースを用
いて，該当するプロファイラにアクセスする過程とを有
することを特徴とする複数プロファイル管理方法。 - 【請求項８】 アクセスプロトコル，データ表現形式ま
たは各データ要素名が異なる複数のプロファイラを接続
する複数プロファイル管理装置を実現するためのプログ
ラムを記録した記録媒体であって，各サービスに対して
定められたアクセスプロトコルにより前記プロファイラ
に対するアクセス要求を受け付ける処理と，前記アクセ
ス要求で指定されたデータ要素名を，前記プロファイラ
における実際の格納場所に関する情報に変換する処理
と，前記格納場所の情報に基づき，前記プロファイラに
アクセスする処理とを，コンピュータに実行させるため
のプログラムを記録したことを特徴とする複数プロファ
イル管理用プログラム記録媒体。 - 【請求項９】 アクセスプロトコル，データ表現形式ま
たは各データ要素名が異なる複数のプロファイラを接続
する複数プロファイル管理装置を実現するためのプログ
ラムであって，各サービスに対して定められたアクセス
プロトコルにより前記プロファイラに対するアクセス要
求を受け付ける処理と，前記アクセス要求で指定された
データ要素名を，前記プロファイラにおける実際の格納
場所に関する情報に変換する処理と，前記格納場所の情
報に基づき，前記プロファイラにアクセスする処理と
を，コンピュータに実行させるための複数プロファイル
管理用プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001136860A JP4343457B2 (ja) | 2000-05-24 | 2001-05-08 | プロファイル管理装置，管理方法，プロファイル管理用プログラム記録媒体およびプロファイル管理用プログラム |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000-152367 | 2000-05-24 | ||
| JP2000152367 | 2000-05-24 | ||
| JP2001136860A JP4343457B2 (ja) | 2000-05-24 | 2001-05-08 | プロファイル管理装置，管理方法，プロファイル管理用プログラム記録媒体およびプロファイル管理用プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002049641A true JP2002049641A (ja) | 2002-02-15 |
| JP4343457B2 JP4343457B2 (ja) | 2009-10-14 |
Family
ID=26592436
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001136860A Expired - Fee Related JP4343457B2 (ja) | 2000-05-24 | 2001-05-08 | プロファイル管理装置，管理方法，プロファイル管理用プログラム記録媒体およびプロファイル管理用プログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4343457B2 (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004234658A (ja) * | 2003-01-28 | 2004-08-19 | Fisher Rosemount Syst Inc | プロセス制御システムおよび安全システムを備えるプロセスプラントにおける統合型コンフィギュレーション |
| JP2010079690A (ja) * | 2008-09-26 | 2010-04-08 | Casio Hitachi Mobile Communications Co Ltd | 端末装置及びプログラム |
| JP2012128495A (ja) * | 2010-12-13 | 2012-07-05 | Ntt Docomo Inc | 管理装置、管理方法及びプログラム |
| JP2012198910A (ja) * | 2004-01-07 | 2012-10-18 | Nokia Corp | 認可方法 |
-
2001
- 2001-05-08 JP JP2001136860A patent/JP4343457B2/ja not_active Expired - Fee Related
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004234658A (ja) * | 2003-01-28 | 2004-08-19 | Fisher Rosemount Syst Inc | プロセス制御システムおよび安全システムを備えるプロセスプラントにおける統合型コンフィギュレーション |
| JP2012198910A (ja) * | 2004-01-07 | 2012-10-18 | Nokia Corp | 認可方法 |
| US8954033B2 (en) | 2004-01-07 | 2015-02-10 | Nokia Corporation | Method of authorization for a cellular system |
| JP2010079690A (ja) * | 2008-09-26 | 2010-04-08 | Casio Hitachi Mobile Communications Co Ltd | 端末装置及びプログラム |
| JP2012128495A (ja) * | 2010-12-13 | 2012-07-05 | Ntt Docomo Inc | 管理装置、管理方法及びプログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4343457B2 (ja) | 2009-10-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0745238B1 (en) | A method and apparatus for controlling access to a database | |
| JP4771321B2 (ja) | データをジャバ・システム・データベース・エントリ及びｌｄａｐディレクトリ・サービスの間で交換するための方法及びデータ・フォーマット | |
| Howes et al. | Understanding and deploying LDAP directory services | |
| US6685090B2 (en) | Apparatus and method for multi-profile managing and recording medium storing multi-profile managing program | |
| US6636875B1 (en) | System and method for synchronizing related data elements in disparate storage systems | |
| US6411956B1 (en) | Method for distributed transaction support using JDBC 1.0 drivers | |
| JP3484779B2 (ja) | 名前サービス方式及び名前サービス方法 | |
| US8326899B2 (en) | Method and system for improving write performance in a supplemental directory | |
| US6970873B2 (en) | Configurable mechanism and abstract API model for directory operations | |
| US7593951B2 (en) | Application programming interface for centralized storage of principal data | |
| WO1997034244A1 (en) | System for integrating access to proprietary and internet resources | |
| US7421480B2 (en) | Personal computing environment using mozilla | |
| JPH07210442A (ja) | ディレクトリサービスのファイルシステムサービスとの統一 | |
| JP2001056810A (ja) | データベースアクセスシステム | |
| JPH11331245A (ja) | ネットワ―ク・ディレクトリ・アクセス機構及び方法 | |
| KR100974160B1 (ko) | 모바일 디바이스 사용자 설정을 유지하기 위한 방법, 시스템 및 컴퓨터 판독가능한 저장 매체 | |
| US7194472B2 (en) | Extending role scope in a directory server system | |
| US8458176B2 (en) | Method and system for providing a directory overlay | |
| US8321486B2 (en) | Method and system for configuring a supplemental directory | |
| US20070106699A1 (en) | Method and system for automatic registration of attribute types | |
| US20070112791A1 (en) | Method and system for providing enhanced read performance for a supplemental directory | |
| JP2002049641A (ja) | 複数プロファイル管理装置，管理方法，複数プロファイル管理用プログラム記録媒体および複数プロファイル管理用プログラム | |
| US6292824B1 (en) | Framework and method for facilitating client-server programming and interactions | |
| WO2004097591A2 (en) | Personal computing environment system using mozilla | |
| JP3374320B2 (ja) | ステートレスプロトコルによるデータベースアクセス方法及びシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060926 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20090408 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090414 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090615 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20090615 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20090615 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090707 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090709 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120717 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120717 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130717 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |