JP4343457B2 - プロファイル管理装置,管理方法,プロファイル管理用プログラム記録媒体およびプロファイル管理用プログラム - Google Patents
プロファイル管理装置,管理方法,プロファイル管理用プログラム記録媒体およびプロファイル管理用プログラム Download PDFInfo
- Publication number
- JP4343457B2 JP4343457B2 JP2001136860A JP2001136860A JP4343457B2 JP 4343457 B2 JP4343457 B2 JP 4343457B2 JP 2001136860 A JP2001136860 A JP 2001136860A JP 2001136860 A JP2001136860 A JP 2001136860A JP 4343457 B2 JP4343457 B2 JP 4343457B2
- Authority
- JP
- Japan
- Prior art keywords
- profiler
- data element
- element name
- profile
- information
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
本発明は,ネットワークで接続された複数のコンピュータにおいて,アクセスプロトコル,データ表現形式が異なる複数のプロファイラを統合する目的で利用されるプロファイラ管理装置に関する。
【0002】
プロファイラとは,例えばネットワークに接続される情報端末を使ってネットワーク上のサービスを受けるユーザに対して,ユーザ毎にカスタマイズされたサービスを提供するために必要な,サービスの設定情報あるいは個人情報を格納および参照するデータ記憶装置あるいはデータ記憶プログラムを意味する。本発明は,1台のユーザの情報端末上に,複数のサービスと複数のプロファイラが存在し,各種のサービスを提供する場合を含む。
【0003】
【従来の技術】
従来,サービスを提供するプログラムがそのサービスを利用するユーザ毎の好みに合わせたカスタマイズサービスを提供する場合には,図9に示すように,各サービス1,2,…,n毎に独自のプロファイラ1,2,…,nを用意し,それぞれのプロファイラ1,2,…,nによってサービスの設定情報を管理していた。サービスとそのサービスが利用するプロファイラとの関係は,古典的にはコンピュータで動作するアプリケーションプログラムとその初期設定ファイルとの関係に相当する。
【0004】
一般に,ユーザは目的に応じてこれらのサービスを使い分けているが,サービス(特にネットワークサービス)に必要な設定情報は規格化されたものが多くなってきている。異なるサービスでも,一部共通の情報要素を設定情報として使う場合が増えている。ここで,異なるアプリケーションが使う共通の情報要素の例としては,自分のメール・アドレスや電話番号,ウェブ・プロキシ,メールサーバ,ニュースサーバなどの各種サーバ・アドレス,ウェブ・ブックマークやアドレスブックなどが想定される。
【0005】
しかし,現状ではサービス毎に設定情報を格納するプロファイラが独立しているため,ユーザが新しいサービスを使い始めるときには,必ず設定情報を入力する必要があった。また,複数のサービスで既に設定され共通に使われている設定情報を変更する場合には,それらのサービスが使っているプロファイラの該当する情報要素を個別に変更する必要があった。
【0006】
【発明が解決しようとする課題】
本発明は,既存のサービスおよびプロファイラにできるだけ影響を与えることなく,サービス毎に独立に存在するプロファイラを統合し,アクセスプロトコル,データ表現形式を統一的なインタフェースにし,サービス設定情報や個人情報を利用するユーザやサービス提供者の管理上の負担を軽減することを目的とする。
【0007】
【課題を解決するための手段】
本発明では,既存のサービスとそのプロファイラの間に複数プロファイルを管理する装置を設け,複数プロファイル管理機能を利用するサービスからは,アクセス手段の異なるプロファイラを統合した1つの仮想プロファイラとして見えるようにする。
【0008】
すなわち,本発明は,既存のプロファイラを統合し,1つの仮想的なプロファイラ(統合プロファイラ)を提供する。これにより,既存のサービスは,専用のプロファイラと同じプロトコルと同じデータ要素名を使って設定情報や個人情報にアクセスできるうえ,さらに,他のサービスが利用している設定情報や個人情報にも,そのサービス専用のプロトコルを使ってアクセスすることができる。このため,サービスの機能拡張の際に必要となるユーザとサービス提供者の負担が軽減される。
【0009】
また,既存のプロファイラの統合により,異なるサービスで利用される共通の設定情報や個人情報に変更の必要が生じた場合に,ユーザは仮想の統合プロファイラを1度だけ変更すればよい。ここで,仮想の統合プロファイラとは,各サービスおよびユーザからプロファイラを見た場合に,物理的に複数のプロファイラが存在しても,それらが統一された一つのプロファイラとして見えるようなアクセス手段が付随するプロファイラを意味している。
【0010】
【発明の実施の形態】
図1は,本発明に係る装置のブロック構成図である。複数プロファイル管理装置1は,統合アクセス部2,名前管理部3,データ要素対応テーブル記憶部30,プロファイルアクセス部4およびデータ要素対応テーブル作成部5から構成される。
【0011】
プロファイルアクセス部4は,複数のプロファイルアクセスインタフェース40を備え,これらの各々はプロファイラ50の異なるアクセスプロトコル毎に用意され,名前管理部3に対して1種類のプロファイルアクセスのためのインタフェースを提供する。例えば,プロファイラ50Aに対してプロファイルアクセスインタフェース40Aが用意され,同様に,プロファイラ50Bに対してプロファイルアクセスインタフェース40Bが,プロファイラ50Zに対してプロファイルアクセスインタフェース40Zが用意される。各プロファイルアクセスインタフェース40A−40Zは,それぞれ独立したモジュールとして組み込み可能であり,新たな種類のプロファイラ50Xの接続に対して,そのプロファイラ50Xに対するアクセスプロトコルに応じたプロファイルアクセスインタフェース40Xを簡単に組み込むことができる。
【0012】
統合アクセス部2は,各サービス10がプロファイラ50を利用する時のプロトコルを理解し,プロファイラ50中のデータ要素に対する追加,削除,参照,更新リクエストを翻訳して,名前管理部3にサービス10からのリクエストを伝える統合アクセスインタフェース20を提供する。
【0013】
統合アクセスインタフェース20は,サービス10とプロファイラ50がある特定のプロトコルを使って既に運用されている場合に,そのサービス10とプロファイラ50の実装を変更せずに複数プロファイル管理機能を付加する場合に役に立つ。
【0014】
名前管理部3は,統合アクセス部2の統合アクセスインタフェース20を通じてサービス10からのプロファイルアクセス要求を受け取り,データ要素対応テーブル記憶部30を参照して,要求のパラメータに含まれる仮想データ要素名から物理的なプロファイラ名(プロファイラの物理アドレス)と実際のデータ要素名との対データを求め,仮想データ要素名をその対データに変換し,プロファイルアクセス要求を対応するプロファイルアクセス部4のプロファイルアクセスインタフェース40に転送する。
【0015】
データ要素対応テーブル記憶部30は,仮想データ要素名と,プロファイラ名およびデータ要素名からなる対データとの対応テーブルを記憶する。図1の例では,対応テーブルとして,すべてのサービスとユーザとに共通に使われる共通対応テーブル31と,ユーザ毎にカスタマイズされるユーザ用対応テーブル32と,サービス毎に管理するサービス用対応テーブル33とがある。これらは,ユーザ用対応テーブル32,サービス用対応テーブル33,共通対応テーブル31の優先順位で参照されるが,少なくともこれらのうちの1つのテーブルがあれば本発明の実施には十分である。
【0016】
また,これらの対応テーブルの複数を階層的に組み合わせたテーブル構成とすることも可能である。図2の例では,すべてのサービスとユーザとに共通に使われる共通対応テーブル31のほかに,各ユーザ毎にユーザ用対応テーブル32−1,32−2,…が設けられ,各ユーザ用対応テーブルは,さらに各サービス毎に,仮想データ要素名と,プロファイラ名とデータ要素名とからなる対データとの対応情報を保持している。
【0017】
これらの対応テーブルを複数プロファイル管理装置1の内部に持たずに,外部の記憶装置もしくは外部のサーバ装置内に持つようにしてもよい。
【0018】
また,データ要素対応テーブル記憶部30には,新しいプロファイラ50の作成もしくは既存のプロファイラ50の変更時に,対応テーブルを自動作成/変更するための対応テーブル作成ルール34を格納しておくこともできる。データ要素対応テーブル作成部5は,システム管理者,ユーザまたはサービス提供者からの指示により,必要に応じて対応テーブル作成ルール34を用いて,共通対応テーブル31,ユーザ用対応テーブル32またはサービス用対応テーブル33の作成,変更を行う。
【0019】
図1に示す装置の作用は,以下のとおりである。名前管理部3は,統合アクセス部2の統合アクセスインタフェース20から,データ要素の追加,削除,参照または更新リクエストを受け取ると,そのリクエストのパラメータに物理的なプロファイラ名(プロファイラの物理アドレス)が含まれるかどうかをチェックする。プロファイラ名が含まれる場合には,それに対応するプロファイルアクセス部4のプロファイルアクセスインタフェース40に対して,追加,削除,参照または更新リクエストを送信する。
【0020】
リクエストにプロファイラ名が含まれない場合には,リクエスト情報(送信元アドレスや認証情報など)からユーザ名とサービス名を取得し,それらに対応するデータ要素対応テーブル(ユーザ用対応テーブル32またはサービス用対応テーブル33)がデータ要素対応テーブル記憶部30に存在するかどうかをチェックする。もし,該当するテーブルがなかった場合,あるいは該当するテーブルにおいて指定された仮想データ要素名が検索されなかった場合には,共通対応テーブル31を仮想データ要素名をキーにして検索し,プロファイラ名と実際のデータ要素名を取得する。
【0021】
名前管理部3は,プロファイラ名と実際のデータ要素名が取得できたら,そのプロファイラ50に対応するプロファイルアクセス部4のプロファイルアクセスインタフェース40に対して,取得された実際のデータ要素名に対する追加,削除,参照,更新リクエストを送信し,リクエスト結果を待つ。リクエスト結果が返送されたら,その結果を統合アクセス部2に転送する。
【0022】
次に,具体例に従って本発明の実施の形態をさらに詳しく説明する。サービスが利用するプロファイラとしては,各サービスに閉じた独自の実装のものから標準的なプロトコルを利用したものまで各種存在する。標準的なプロトコルとしては,ディレクトリサーバとして知られるLDAP(Lightweight Directory Access Protocol)や多くのデータベースが採用しているSQL(Structured Query Language)およびODBC(Open DataBase Connectivity)等のインタフェースが例として挙げられる。また,Webサービスの多くはHTTPプロトコルによるプロファイルアクセスを独自に実装している場合もある。
【0023】
以下で説明する例では,統合アクセス部2において統合アクセスインタフェース20BがHTTPを実装しており,また,プロファイルアクセス部4においてプロファイルアクセスインタフェース40BがSQLを実装しているものとする。サービス10Bは,統合アクセスインタフェース20B,名前管理部3,プロファイルアクセスインタフェース40Bを通じて,データベースに格納されたプロファイル情報にアクセスする。
【0024】
統合アクセス部2の統合アクセスインタフェース20Bは,例えば以下のようなフォーマットのHTTPリクエストを受け取る。
【0025】
このHTTPリクエストに対して,統合アクセスインタフェース20Bは,uid=28539 はユーザ名,command=readは参照要求,name=aは仮想データ要素名が“a”であることを示すため,以下のような情報を抽出する。
【0026】
名前管理部3は,プロファイラ50Bの物理アドレスとそのプロファイラ内データ要素の実名とからなる対データと,複数プロファイル管理装置1で利用される仮想データ要素名との対応情報を,共通対応テーブル31,ユーザ用対応テーブル32またはサービス用対応テーブル33としてデータ要素対応テーブル記憶部30内に管理している。
【0027】
名前管理部3は,仮想データ要素名〔name:"a"〕をキーにデータ要素対応テーブル記憶部30中の対応テーブルを参照することにより,物理的なプロファイラ50Bのアドレス〔P1〕を取得し,以下のような情報に変換する。
【0028】
対応テーブルから得た“P1”は物理的なプロファイラ名を示し,これにより対応するプロファイルアクセス部4のプロファイルアクセスインタフェース40Bが選択されることになる。
【0029】
ここで,選択されたプロファイルアクセスインタフェース40Bが,以下のようにSQLコマンドによるデータベースアクセスをJava言語で実装していたとする。
【0030】
これによって,プロファイルアクセスインタフェース40Bは,名前管理部3から得た情報にもとづき,データベース“P1”に格納されたユーザ“28539”のデータ要素“a”を取得する。
【0031】
[名前管理部における変換例(その1)]
図3に,要素名“a”,“b”,“e”,“f”を持つプロファイラ50Aと,要素名“c”,“d”,“e”,“f”を持つプロファイラ50Bが存在した場合の,複数プロファイル管理装置1におけるデータ要素対応テーブル記憶部30のテーブルの例を示す。この例では,共通対応テーブル31だけ存在し,ユーザ用対応テーブル32およびサービス用対応テーブル33は存在しないものとする。
【0032】
ここで,あるサービスが複数プロファイル管理装置1に対して,要素名“a”の値を要求した場合,名前管理部3において要素名“a”に対応するデータとして{A,”a”}が取得され,要求元のサービスはプロファイラ50Aを指定せずに要素名“a”の指定だけで,プロファイラ50Aからそのデータ要素の値“1000”を取得することができる。
【0033】
また,あるサービスが複数プロファイル管理装置1に対して,要素名“e”の値を“Toshi”に更新する要求を出した場合,名前管理部3において,データ要素対応テーブル記憶部30における対応データとして{A,”e”}と{B,”e”}の2つが取得される。このため,プロファイラ50Aのデータ要素“e”とプロファイラ50Bのデータ要素“e”は共に,“Fuji”から“Toshi”に書き換えられる。現実的には,このような複数箇所の同時書き換えを安全に行うためには,一般によく知られたトランザクション機能を名前管理部3が持つ必要がある。
【0034】
[対応テーブル作成ルールの例]
データ要素対応テーブル記憶部30に記憶する対応テーブルを自動生成するための対応テーブル作成ルール34として,以下のような定義が例として考えられる。ここで同期とは,複数のプロファイラに存在するデータ要素が実質的に一つのものとして扱われ,それらの一つが更新されると他の関連するデータ要素も同じように更新される操作を意味する。
【0035】
rule1=値が同じデータ要素は同期する
rule2=データ要素名が一致する場合は同期する
rule3=例外:“f”→{B,“f”}
… …
このルール定義により,データ要素対応テーブル作成部5では,例えば,図3に示す共通対応テーブル31を,プロファイラ50Aとプロファイラ50Bの内容を調べることにより自動生成することができる。なお,対応テーブル作成ルール34は,共通対応テーブル31,ユーザ用対応テーブル32およびサービス用対応テーブル33のそれぞれに対して,別々に用意しておくことができる。
【0036】
[名前管理部における変換例(その2)]
図4に,ユーザ毎あるいはサービス毎にデータ要素名と各プロファイラのデータ要素とのユーザ用対応テーブルあるいはサービス用対応テーブルを独自に用意して,カスタマイズ可能にした場合のテーブルの使用例を示す。この例は,ユーザU1とユーザU2がサービス10Aを使ってデータ要素名“f”を参照しようとした場合の例である。
【0037】
ユーザ用対応テーブル32が存在する場合,名前管理部3は,ユーザ用対応テーブル32を共通対応テーブル31よりも優先してデータ要素名のマッピングに使用する。したがって,ユーザU1からのデータ要素名“f”を指定した要求に対して,データ要素名“f”は,ユーザ(U1)用対応テーブル32−1の参照により{A,“f”},{B,“f”}に変換され,ユーザU1のデータ要素“f”に対する参照リクエストは,プロファイラ50Aまたはプロファイラ50Bのデータ要素“f”への参照となる。更新リクエストの場合,これら2つのデータ要素は常に同期的に更新されるように振る舞う。
【0038】
一方,ユーザU2が同じようにデータ要素“f”に対するアクセスを行った場合,ユーザ2のユーザ(U2)用対応テーブル32−2には,データ要素名“f”に対するマッピングのエントリがないため,リクエストのパラメータで指定されたデータ要素“f”は,各ユーザおよび各サービスが共用する共通対応テーブル31から,プロファイル50Bのデータ要素“f”への参照にマッピングされ,プロファイル50Aの“f”とは独立に扱われるようになる。
【0039】
ユーザU1のように,1対多のマッピングを行う具体的な例としては,LDAPサーバで管理されている自分の電話番号とデータベースで管理されている自分の電話番号を同期して管理したい場合などがこれに当たる。
【0040】
また図4の例では,ユーザU2からは,データ要素“a”とデータ要素名“c”は共にプロファイラ50Bのデータ要素“c”にマッピングされるようにカスタマイズされている。このような多対1へのマッピングの具体的な使用例としては,例えばユーザU2が2つのメールアドレスを持っており,それら2つのメールアドレスに届いたメールを1つのメールボックスで管理したいような場合がこれに当たる。
【0041】
図5に,統合プロファイル・カスタマイズのための画面表示例を示す。図5の画面例に示されるように,ある要素名を物理的なプロファイルにマッピング(対応付け)する場合に,要素名マッピングテーブルから変更したい要素の行を1または複数行選択し,選択した行を画面右側の利用可能プロファルのアイコンのいずれかにドラッグ・アンド・ドロップする。既に1つ以上のプロファイルへの対応が存在する状態でこの操作を行うと,複数プロファイルへのマッピングを追加することになる。各要素のプロファイルのマッピングを変更する場合には,変更したい要素の行を選択し,編集ボタンを押すことにより表示される編集ダイアログ上で処理を行う。要素名や要素値などを変更する場合にも同様に編集ダイアログ上で処理を行う。
【0042】
図6に,名前管理部3の処理フローを示す。名前管理部3では,統合アクセス部2からのデータ要素の追加,削除,参照,更新リクエストを待ち(ステップS1),リクエストを受け取ると,そのリクエストのパラメータに物理的なプロファイラ名(プロファイラの物理アドレス)が含まれるかどうかをチェックする(ステップS2)。物理的なプロファイラ名が含まれる場合には,ステップS10へ進む。
【0043】
リクエストにプロファイラ名が含まれない場合には,リクエスト情報(送信元アドレスや認証情報など)からユーザ名とサービス名を取得し(ステップS3),それらに対応するユーザ用対応テーブル32(またはサービス用対応テーブル33)がデータ要素対応テーブル記憶部30に存在するかどうかをチェックする(ステップS4)。該当するテーブルがあれば,ユーザ用対応テーブル32をリクエストの仮想データ要素名をキーにして検索する(ステップS5)。検索した結果,ユーザ用対応テーブル32に該当する仮想データ要素名があれば(ステップS6),ステップS9へ進む。
【0044】
もし,該当するユーザ用対応テーブル32がなかった場合(ステップS4),あるいは該当するユーザ用対応テーブル32に該当する仮想データ要素名がなかった場合には(ステップS6),共通対応テーブル31を仮想データ要素名をキーにして検索する(ステップS7)。検索した結果,共通対応テーブル31に該当する仮想データ要素名があれば(ステップS8),ステップS9へ進み,共通対応テーブル31にも該当する仮想データ要素名がなければ,要素名なしの理由でエラー情報を送信元の統合アクセス部2に送信する(ステップS16)。
【0045】
ステップS9では,ユーザ用対応テーブル32もしくは共通対応テーブル31から,プロファイラ名と実データ要素名を取得し(ステップS9),ステップS10へ進む。
【0046】
ステップS10では,N=実データ要素名の数およびi=0を設定する。次に,プロファイラ名に対応するプロファイルアクセス部4のプロファイルアクセスインタフェース40に対して,追加,削除,参照および更新リクエストを実データ要素名をパラメータにして送信し(ステップS11),リクエスト結果を待つ(ステップS12)。リクエスト結果がきたらiを1カウントアップし(ステップS13),iが実データ要素名の数Nになるまで,ステップS11〜S13を繰り返す(ステップS14)。その後,リクエスト結果を統合アクセス部2に返送する(ステップS15)。以上の処理の後,ステップS1へ戻り,次のリクエストを待つ。
【0047】
図7に,統合アクセス部の処理フローを示す。統合アクセス部2では,サービス10からのデータ要素の追加,削除,参照,更新リクエストを待ち(ステップS20),リクエストを受け取ると,リクエストからデータ要素名,データ要素値などのパラメータを抽出し,名前管理部3に送信して(ステップS21),名前管理部3からのリクエスト結果を待つ(ステップS22)。リクエスト結果が返送されてきたら,そのリクエスト結果を該当するサービス10に返送する(ステップS23)。
【0048】
図8に,プロファイルアクセス部4の処理フローを示す。プロファイルアクセス部4では,名前管理部3からのデータ要素の追加,削除,参照,更新リクエストを待ち(ステップS30),リクエストを受け取ると,コマンド,データ要素名,データ要素値をもとに,プロファイラ50のAPI(Application Programming Interface)に合わせてリクエストを発行し(ステップS31),プロファイラ50からのリクエスト結果を待つ(ステップS32)。リクエスト結果が返送されてきたら,そのリクエスト結果を名前管理部3に返送する(ステップS33)。
【0049】
以上説明したように,複数プロファイル管理装置1は,アクセスプロトコル,データ表現形式および各データ名が異なる複数のプロファイラのインタフェースの統一とデータ要素の名前管理を行うことにより,仮想的な1つの統合プロファイラを提供する。特に,異なるプロファイラに問い合わせを行うプロファイルアクセスインタフェース40を分離して設けることにより,新たな種類のプロファイラの接続を容易に実現することができる。
【0050】
また,名前管理部3では,プロファイラの物理アドレスとそのプロファイラ内データ要素の実名とからなる対データと,複数プロファイル管理機能で利用される仮想データ要素名とのデータ要素対応テーブルを管理する。これにより,プロファイラの物理アドレスを指定せずに,仮想データ要素名を指定するだけで目的のデータにアクセスすることが可能となる。
【0051】
また,名前管理部3では,プロファイラの物理アドレスとそのプロファイラ内データ要素の実名とからなる複数の対データと,1つの仮想データ要素名とを対応付けることを許容する。このため,これに該当するデータ要素名の更新要求が発生した時には,対応する複数のデータ要素を同期して更新することが可能になる。
【0052】
また,複数プロファイル管理装置1において,対応テーブル作成ルール34を用意し,データ要素対応テーブル作成部5が対応テーブル作成ルール34を評価する機能を持つ。これにより,新たなプロファイルが複数プロファイル管理装置1に接続されたとき,あるいは,新たなデータ要素が追加された時,自動的にデータ要素対応テーブルの書き換えを行うことが可能となる。
【0053】
また,複数プロファイル管理装置1では,データ要素対応テーブル記憶部30中の対応テーブルを,共通用とユーザ用とに分離し,ユーザ用対応テーブルはユーザによる書き換えを許容する。これにより,プロファイルをアクセスするユーザ毎にデータ要素の対応関係をカスタマイズすることが可能になる。
【0054】
同様に,複数プロファイル管理装置1では,データ要素対応テーブルを,共通用とサービス用とに分離して構成することもでき,複数プロファイル管理機能を利用するサービス毎にデータ要素の対応関係が異なるようにすることも可能である。
【0055】
複数プロファイル管理装置1は,ハードウェアとしては,図示省略するが例えば1または複数のCPUと,主記憶装置と,ハードディスク等の外部記憶装置と,それらを接続するバス等からなるコンピュータによって実現される。このコンピュータを複数プロファイル管理装置1として機能させるためのソフトウェアプログラムは,コンピュータが読み取り可能な可搬媒体メモリ,半導体メモリ,ハードディスクなどの適当な記録媒体に格納することができる。
【0056】
【発明の効果】
以上述べたように,本発明を適用することにより,各種サービスが利用するプロファイラが独立に運用されているものであっても,1つの仮想的なプロファイラとして扱うことができ,重複した内容のデータを1回のアクセスで同期して扱うことが可能となる。
【0057】
また,従来サービスが使用していたアクセスプロトコルと同じプロトコルを統合アクセス部として用意することにより,各サービスは従来のプロトコルのまま統合されたプロファイラにアクセスすることができ,既存サービスに対する影響が小さい。このようなプロファイルの共有により,新規サービスを追加した場合のサービス提供者とユーザの双方の負担を軽減できる効果は大きい。
【図面の簡単な説明】
【図1】本発明に係る装置のブロック構成図である。
【図2】データ要素対応テーブル記憶部の構成例を示す図である。
【図3】データ要素対応テーブル記憶部のテーブルの具体例を示す図である。
【図4】データ要素対応テーブル記憶部のテーブルの具体例を示す図である。
【図5】統合プロファイル・カスタマイズのための画面表示例を示す図である。
【図6】名前管理部の処理フロー図である。
【図7】統合アクセス部の処理フロー図である。
【図8】プロファイルアクセス部の処理フロー図である。
【図9】従来技術の説明図である。
【符号の説明】
1 複数プロファイル管理装置
2 統合アクセス部
3 名前管理部
4 プロファイルアクセス部
5 データ要素対応テーブル作成部
10 サービス
20 統合アクセスインタフェース
30 データ要素対応テーブル記憶部
31 共通対応テーブル
32 ユーザ用対応テーブル
33 サービス用対応テーブル
34 対応テーブル作成ルール
40 プロファイルアクセスインタフェース
50 プロファイラ
Claims (7)
- 複数のプロファイラヘのアクセスが可能なプロファイル管理装置であって,
利用者からのリクエストを受け付ける複数のインターフェイスと,
前記インターフェイスのいずれかが受けたリクエストに含まれるデータ要素名と,プロファイラを特定する情報およびプロファイラ内でアクセスされるデータ要素名との対応付関係を記憶した記憶部と,
前記記憶部を参照し,前記インターフェイスが受けたリクエストに含まれるデータ要素名に対応する,プロファイラを特定する情報とプロファイラ内でアクセスされるデータ要素名とを抽出する第1の抽出手段と,
前記第1の抽出手段により抽出されたプロファイラを特定する情報に対応するプロファイラに対し,前記第1の抽出手段により抽出したデータ要素名に対応するプロファイル情報へのアクセスを行うプロファイルアクセス手段と,
を有するプロファイル管理装置。 - 請求項1記載のプロファイル管理装置において,
前記記憶部が記憶したプロファイラを特定する情報およびプロファイラ内でアクセスされるデータ要素名は,該プロファイラの物理アドレスおよびそのプロファイラ内データ要素の実名である
ことを特徴とするプロファイル管理装置。 - 請求項1または請求項2記載のプロファイル管理装置において,
前記記憶部は,全ユーザに対して共通に適用する対応情報のテーブルと,各ユーザ別または/および各サービス別に適用する対応情報のテーブルとを記憶し,
前記第1の抽出手段は,前記各ユーザ別または/および各サービス別に適用する対応情報のテーブルを先に用いて,前記リクエストに含まれるデータ要素名に対応する,プロファイラを特定する情報とプロファイラ内でアクセスされるデータ要素名とを抽出し,該テーブルに該当するデータ要素名がなかった場合に,前記全ユーザに対して共通に適用する対応情報のテーブルを用いて,前記リクエストに含まれるデータ要素名に対応する,プロファイラを特定する情報とプロファイラ内でアクセスされるデータ要素名とを抽出する
ことを特徴とするプロファイル管理装置。 - 複数のプロファイラヘのアクセスが可能なプロファイル管理装置であって,
利用者からのリクエストを受け付ける複数のインターフェイスと,
前記インターフェイスのいずれかが受けたリクエストに含まれるデータ要素名と,プロファイラを特定する情報およびプロファイラ内でアクセスされるデータ要素名との対応付関係を記憶した記憶部と,
前記記憶部を参照し,前記インターフェイスが受けたリクエストに含まれるデータ要素名に対応する,プロファイラを特定する情報とプロファイラ内でアクセスされるデータ要素名とを抽出する第1の抽出手段と,
前記第1の抽出手段により抽出されたプロファイラを特定する情報に対応するプロファイラに対し,前記第1の抽出手段により抽出したデータ要素名に対応するプロファイル情報へのアクセスを行うプロファイルアクセス手段と,
新たなプロファイラの追加またはプロファイラに対する新たなデータ要素の追加に対して,あらかじめ入力された,値が同じデータ要素またはデータ要素名が一致するという条件のもとで,複数のプロファイラに存在するデータ要素が一つのものとして扱われ,それらの一つが更新されると他の関連するデータ要素も同じように更新される操作を意味する定義情報を含む対応情報作成ルールに従って,前記記憶部が記憶した対応付関係の情報を作成する対応情報作成手段と,
を有するプロファイル管理装置。 - 複数のプロファイラヘのアクセスが可能なプロファイル管理装置が実行するプロファイル管理方法であって,
利用者からのリクエストを受け付ける複数のインターフェイスのいずれかからリクエストを受け付ける過程と,
前記インターフェイスのいずれかが受けたリクエストに含まれるデータ要素名と,プロファイラを特定する情報およびプロファイラ内でアクセスされるデータ要素名との対応付関係を記憶した記憶部を参照し,前記インターフェイスから受け付けたリクエストに含まれるデータ要素名に対応する,プロファイラを特定する情報とプロファイラ内でアクセスされるデータ要素名とを抽出する抽出過程と,
前記抽出過程により抽出したプロファイラを特定する情報に対応するプロファイラに対し,前記抽出過程により抽出したデータ要素名に対応するプロファイル情報へのアクセスを行うプロファイルアクセス過程と,
を有するプロファイル管理方法。 - 複数のプロファイラヘのアクセスが可能なプロファイル管理方法を,コンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって,
利用者からのリクエストを受け付ける複数のインターフェイスのいずれかからリクエストを受け付ける手順と,
前記インターフェイスのいずれかが受けたリクエストに含まれるデータ要素名と,プロファイラを特定する情報およびプロファイラ内でアクセスされるデータ要素名との対応付関係を記憶した記憶部を参照し,前記インターフェイスから受け付けたリクエストに含まれるデータ要素名に対応する,プロファイラを特定する情報とプロファイラ内でアクセスされるデータ要素名とを抽出する抽出手順と,
前記抽出手順により抽出したプロファイラを特定する情報に対応するプロファイラに対し,前記抽出手順により抽出したデータ要素名に対応するプロファイル情報へのアクセスを行うプロファイルアクセス手順とを,
コンピュータに実行させるためのプログラムを記録したプロファイル管理用プログラム記録媒体。 - 複数のプロファイラヘのアクセスが可能なプロファイル管理方法を,コンピュータに実行させるためのプログラムであって,
利用者からのリクエストを受け付ける複数のインターフェイスのいずれかからリクエストを受け付ける手順と,
前記インターフェイスのいずれかが受けたリクエストに含まれるデータ要素名と,プロファイラを特定する情報およびプロファイラ内でアクセスされるデータ要素名との対応付関係を記憶した記憶部を参照し,前記インターフェイスから受け付けたリクエストに含まれるデータ要素名に対応する,プロファイラを特定する情報とプロファイラ内でアクセスされるデータ要素名とを抽出する抽出手順と,
前記抽出手順により抽出したプロファイラを特定する情報に対応するプロファイラに対し,前記抽出手順により抽出したデータ要素名に対応するプロファイル情報へのアクセスを行うプロファイルアクセス手順とを,
コンピュータに実行させるためのプロファイル管理用プログラム。
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 JP2002049641A (ja) | 2002-02-15 |
JP4343457B2 true 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) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7330768B2 (en) * | 2003-01-28 | 2008-02-12 | Fisher-Rosemount Systems, Inc. | Integrated configuration in a process plant having a process control system and a safety system |
GB0400270D0 (en) * | 2004-01-07 | 2004-02-11 | Nokia Corp | A method of authorisation |
JP5354648B2 (ja) * | 2008-09-26 | 2013-11-27 | Necカシオモバイルコミュニケーションズ株式会社 | 端末装置及びプログラム |
JP5612453B2 (ja) * | 2010-12-13 | 2014-10-22 | 株式会社Nttドコモ | 管理装置、管理方法及びプログラム |
-
2001
- 2001-05-08 JP JP2001136860A patent/JP4343457B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2002049641A (ja) | 2002-02-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11216422B2 (en) | Universal data management interface | |
US7269664B2 (en) | Network portal system and methods | |
US8117230B2 (en) | Interfaces and methods for group policy management | |
US5878219A (en) | System for integrating access to proprietary and internet resources | |
JP4771321B2 (ja) | データをジャバ・システム・データベース・エントリ及びldapディレクトリ・サービスの間で交換するための方法及びデータ・フォーマット | |
US8326899B2 (en) | Method and system for improving write performance in a supplemental directory | |
US6685090B2 (en) | Apparatus and method for multi-profile managing and recording medium storing multi-profile managing program | |
US6970873B2 (en) | Configurable mechanism and abstract API model for directory operations | |
JP2002055828A (ja) | コンピューティング環境において構成情報を保持する方法および装置 | |
JP2003518683A (ja) | ユーザにデータを提示する方法および装置 | |
US7327836B2 (en) | Architecture for unified messaging | |
US8185562B2 (en) | Business object browser for business query language | |
KR20060121803A (ko) | 모바일 디바이스 사용자 설정을 유지하기 위한 방법,시스템 및 프로그램 제품 | |
US8458176B2 (en) | Method and system for providing a directory overlay | |
US10747733B2 (en) | Generating category-based views of a directory | |
US8321486B2 (en) | Method and system for configuring a supplemental directory | |
US7315847B2 (en) | Method and system for providing access to a database | |
JP4343457B2 (ja) | プロファイル管理装置,管理方法,プロファイル管理用プログラム記録媒体およびプロファイル管理用プログラム | |
US20070112791A1 (en) | Method and system for providing enhanced read performance for a supplemental directory | |
JP2004287928A (ja) | コンテンツ管理プログラム | |
US20240036946A1 (en) | Event provisioning for high-level programing language platform | |
Zhou et al. | Using traders for loosely integrating heterogeneous database systems | |
Brown | The Development of LDAP-based Data Storage Library in the Common Data Security Architecture | |
Lin et al. | The Development of LDAP-based Data Storage Library in the Common Data Security Architecture | |
Hall et al. | The BERKOM Administration Infrastructure |
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 |