JP3670965B2

JP3670965B2 - ユーザ及びユーザ・グループ又は端末及び端末グループのコンテキストに従って階層データ構造におけるアプリケーション・プリファレンスを維持するためのクライアント／サーバ・システム

Info

Publication number: JP3670965B2
Application number: JP2000547744A
Authority: JP
Inventors: ヘイズ、ケント、フィルモア、ジュニア
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1998-05-05
Filing date: 1998-12-21
Publication date: 2005-07-13
Anticipated expiration: 2018-12-21
Also published as: DE69828202D1; CA2324396C; CN1292965A; WO1999057862A1; US6105063A; IL138133A; PL343688A1; IL138133A0; JP2003505745A; DE69828202T2; EP1076973A1; EP1076973B1; CN1120606C; CA2324396A1; TW444181B

Description

【０００１】
本発明は、概して云えば、パーソナル・コンピューティング及びネットワーキングの分野に関するものである。詳しく云えば、本発明は、デスクトップ・コンピュータのユーザが、企業のイントラネット、インターネットのようなネットワークに接続された、又はそのデスクトップ・コンピュータ上で実行されるアプリケーションへのアクセスを得るためにネットワーク又はインターネット・サービス・プロバイダ（ＩＳＰ）に接続された、ディスクレスでもよいパーソナル・コンピュータを使用するという新規な、しかも発展段階にあるネットワーク・コンピューティングの分野に関するものである。更に詳しく云えば、本発明は、サーバから検索され、デスクトップ・コンピュータにおいて実行されるソフトウエアに対するソフトウエア・プリファレンス（コンフィギュレーション・データ）のサーバ・ベースの記憶装置に関するものである。
【０００２】
ネットワーク・コンピュータの分野は、現在、それの幼年期にある。しかし、それは、多くの理由により、特に企業環境において急速に発展することが期待されている。その期待は、企業及び、場合によっては個人ユーザが、ハードウエア及びソフトウエアのアップグレード時期に達する時、ディスク搭載型コンピュータによって及びローカル的に記憶され且つ管理されたソフトウエア・アプリケーションによって伝統的な方法でアップグレードするよりも、この新しい分野への移行がもっと効率的な且つもっと安価なものになるであろうと、いうことである。例えば、企業環境においては、ユーザは、例えば、インターネットのＴＣＰ／ＩＰ及びＨＴＴＰプロトコルを使用して企業のイントラネットに接続されることが可能であり、ソフトウエア・アプリケーションが必要とされる時には、それらのソフトウエア・アプリケーションをネットワーク・サーバからデスクトップ・コンピュータにダウンロードすることが可能である。或るアプリケーションは、有用な仕事を遂行するために、デスクトップにおいてユーザによる伝統的な方法で実行される。このコンフィギュレーションの利点は、ネットワーク・コンピュータが伝統的なディスク搭載型コンピュータよりもかなり安価であるということである。又、各ユーザに対してソフトウエアの個々のコピーを購入するよりも、それらのユーザに対して必要な数のソフトウエア・ライセンスを購入する方が少ない費用で済むかも知れない。確かに、多数の企業ユーザに伴うソフトウエア管理の問題はかなり減少するであろう。現時点では、ディスク搭載型コンピュータ又はワークステーションの各ユーザは事実上ユーザ自身のシステム・アドミニストレータであることが多く、専門的な知識の欠如のために過度にリソースを浪費することが多い。多くのユーザをソフトウエアの導入、アップグレード、及びコンピュータ管理という問題と苦闘させるよりも、少数のサーバ管理の専門家にその問題の負担を事実上譲ることによってこの問題を排除する方が大変有利であると考えられる。
【０００３】
上記のように、このようなパーソナル・コンピューティングの将来に関する見方は現時点では幼年期にある。その結果、現時点では、既存のシステムに伴う多くの問題点及び欠点が存在する。
【０００４】
一般には、ネットワーク・サーバにおいて記憶されるユーザ・プロファイルをアドミニストレータが作成する。それらのプロファイルは、ユーザのデスクトップ・プリファレンス及びサーバにおいて常駐し得る種々のソフトウエア・アプリケーションへのアクセスに対するユーザの許可のような種々のタイプの情報を含み得るものである。ユーザがシステムをログ・オンする時、ユーザはサーバに対して自分自身を識別し、サーバはそのユーザに対するプロファイルを見つけ、それをユーザのコンピュータに送る。ユーザのコンピュータでは、それがコンピュータを環境設定するために及びデスクトップを汎用化するために使用される。デスクトップは、そのユーザがアクセスすると思われるアプリケーションを表す多数のアイコンを持っていてもよい。プロファイルは、例えば、そのユーザに特有のデスクトップのバックグラウンド・カラー、デスクトップにおいて使用される文字のフォント及びポイント・サイズ、又はデータ・ファイル・サーチ・パス等のようなそのコンピュータ及びデスクトップに関するその他の属性を含むこともある。プロファイルは、ユーザが修正可能なものであってもよく、或いは修正不可能なものであってもよい。
【０００５】
ユーザが自分自身のプロファイルを修正することができる環境では、修正されたプロファイルがログ・オフ時にサーバにアンロードされ、ユーザの次のログ・オン時における検索に備えて記憶される。或る従来技術のシステムにおいては、我々の知っている限りでは、ユーザは、そのユーザがサーバにおいて存在しても或いは存在していなくても、及びそのユーザがサーバにおけるアプリケーションに対するアクセス許可を持っていても或いは持っていなくても、アプリケーション・アイコンの任意のコンフィギュレーションを自分のデスクトップ上に発生することでできる。ロータス・ワークプレース・デスクトップ"Lotus Workplace Desktop"（以前は、コナ・デスクトップ "Kona Desktop"と呼ばれた）システムはこのタイプのオペレーションの一例である。別のシステムでは、サーバが持っていて且つユーザが選出することができるすべてのアプリケーションのリストをサーバがユーザに表示する。この場合、デスクトップに組み込むためにそのリストから選択されるアプリケーションに対するアクセス許可をそのユーザが実際に持っているという保証はない。サン・ホットＪａｖａビューズ（Sun Hot Java Views）システムはこのタイプのシステムの一例である。換言すれば、従来技術のシステムは、ユーザがデスクトップ・アプリケーション・アイコンのセットに対して環境設定することが可能であるものとユーザが実際にアクセス許可を持っているアプリケーションとの間には相関関係はない。そのような場合、ユーザが或るアプリケーションを実行するためにアイコンをクリックする時、アクセス許可が存在しない場合には（無許可アクセス・メッセージのような）エラー・メッセージが生じることがあり、或いは、更に悪い場合にはユーザのコンピュータがクラッシュすることがある。
【０００６】
既存の技術に関するもう１つの制限事項は、ユーザ、ユーザ・グループ、端末、及び端末のグループをモデルとするためにフラットなデータ構造が使用されるということである。コンピュータ・リソースに対するユーザ・アクセスを管理するための一般的なスキームをモデルとして、既知のネットワーク・コンピュータ・インプリメンテーション（例えば、デスクトップ用ロータス管理機構（Lotus Administration Facility for Desktop）、マイクロソフト・ウィンドウズＮＴプロファイル及びポリシー（Microsoft Windows NT Profiles and Policies）、及びサン・ホットＪａｖａビューズ）は、種々なコンテキストでソフトウエア・プリファレンス（又はアトリビュート）を管理するためにサーバにおいてフラットな「グループ」構造をインプリメントしている。本願において使用される「コンテキスト」は、個々のユーザ、ユーザ・グループ、端末、又は端末グループを指す。サーバにおいてソフトウエア・プリファレンスを管理するための如何なるグループ化構造も、アドミニストレータがユーザの種々なグループ及び個々のユーザに対するプリファレンス・アトリビュートを定義することを可能にする。しかし、フラットなシステムは多くの環境において、特に、多数のユーザを有する環境において融通性がない。プリファレンス情報の編成を支援する管理ツールを階層構造の中に設けることが望ましい。
【０００７】
既存のシステムに関するもう１つの制限事項は、アドミニストレータ及びユーザがワークステーション・デスクトップのユーザ・コンフィギュレーションを行わなければならないという点でそれらが制限されるということである。例えば、アドミニストレータは、現時点では、ユーザ・アプリケーションとは別個の、しかしそのユーザ・アプリケーションと関連したコンフィギュレーション・プログラムを使用してユーザ・プリファレンスを環境設定することを要求される。ベンダが単一のアプリケーションしか提供しないことを可能にすることが望ましい。ベンダからのエンド・ユーザ・アプリケーションしか必要としないということは、中央の管理機構がユーザ又はユーザ・グループに関連したエンド・ユーザ・アプリケーションを実行することができるということを必要とする。従来技術は、オペレーションに関するこの管理上の融通性を許容するものではない。換言すれば、従来技術では、我々の知っている限りでは、アドミニストレータは、ユーザに関連してユーザ・アプリケーションを走らせてそのユーザ及びアプリケーションに対するプリファレンスを設定するという能力を持つものではない。更に、従来技術では、アドミニストレータは、１つのユーザ・グループのコンテキストにおいてプリファレンスを設定するためにユーザ・アプリケーションを走らせることができない。
【０００８】
発明者が知っている従来技術における更にもう１つの制限事項は、サーバにおける種々のアプリケーションに関連したユーザ・プリファレンスを記憶するための独特の空間が予約されることを保証するために、サーバの永続記憶空間を区分するという方法である。発明者が知る限りでは、１つのオブジェクトがそれの完全に修飾されたクラス名（そのクラス名は独特に自己識別し、それを他のクラス名から区別する）に関して照会されることがあるというオブジェクト指向のシステムにおける衝突を防ぐという問題は、ベンダに適用する独特の呼称を中央の第１権限者に割り当てさせることによって、及び各ベンダ・アプリケーションに対するその第１呼称に関連した第２呼称をベンダにおける第２権限者に割り当てさせることによって解決される。例えば、ベンダＡは第１権限者によってベンダＡという呼称を割り当てられることがあり、その呼称は、第１権限者が活動しているアーキテクチャにおいては独特のものであることを保証する。次に、ベンダＡにおける第２権限者がそのアーキテクチャにおけるそれのアプリケーションの各々に対して第２呼称を割り当てる。例えば、ベンダＡのアプリケーションの１つは「ベンダＡアプリケーション１（vendorA.App1）」と指定されてもよく、他のアプリケーションは「ベンダＡアプリケーション２（vendorA.App2）」と指定されてもよい。従来技術は、種々のアプリケーションに対するプリファレンス・データが記憶装置において衝突しないことを保証するために、システムにおける各アプリケーションに対して独特の呼称をそのシステムの永続記憶装置におけるロケーションにマップする。アプリケーションは、それが走っている時、ネットワーク・コンピュータ・サーバにそれの独特の記憶ロケーションを知らせる。しかも、プリファレンス情報を記憶するためのコンテキスト（ユーザ、ユーザ・グループ、端末、又は端末グループ）に従って開始ロケーションにおけるエリアを区分して、異なるコンテキストにおけるプリファレンス情報と衝突しないようにすることはユーザの責任である。明らかに、記憶空間を管理するというこの方法は扱いにくく、望ましくない。プリファレンス情報の記憶装置における衝突を防ぐという目的で独特の呼称を中央の権威者に割り当てさせるという要求事項に頼ることなく、及び記憶ロケーション情報をアプリケーションにコード化することなく、前述のオブジェクト指向アプリケーションに対するプリファレンス情報を記憶するための独特の記憶ロケーションを自動的に生成するための方法を工夫することが望ましい。
【０００９】
従来技術における更にもう１つの制限事項は、既存のハードウエア及びアプリケーションに対する変更を必要とすることなく、既存のハードウエア及びアプリケーションを、集中管理されたネットワーク・コンピューティング・ワールドの環境に移行させるための何らかの対策の欠如にある。既存のハードウエア、例えば、ネットワーク環境における端末は、起動時に、サーバに設けられた特定のフォーマットのファイルからそれのコンフィギュレーション情報を得る。端末は、それのコンフィギュレーションファイルをアクセスする方法を知るようにプログラムされている。端末は、サーバからそのファイルをアクセスするために独特の識別子を使用する。その独特の識別子は、端末のメディア・アクセス・コントロール（ＭＡＣ）アドレスであることが多い。しかし、端末が指定されるものとは異なるプロトコル及びＡＰＩを伴う新しい集中管理された環境では、端末はその新しい環境においてプリファレンス情報をアクセスすることができず、それが指定される方法でそれの環境ファイルをアクセスすることができるだけである。数多くのそのような既存の装置が使用されているので、これは深刻な問題である。新しいシステムにおいてそれらを使用することができないということは、ユーザが新しいシステムに移行しようとする動機を大いに妨げることになる。
【００１０】
従来技術における更にもう１つの制限事項は、アドミニストレータとコンフィギュレーション・マネージメント・システムとの間のインターフェースに関連する。種々のユーザ及びユーザ・グループ並びに端末及び端末グループに対するプリファレンス情報を環境設定するように管理機構においてソフトウエアを環境設定する時、管理ソフトウエアは、その機構で走っているアドミニストレータによって設定されたコンテキスト（ユーザ、ユーザ・グループ、端末、及び端末グループ）において立ち上げる。アプリケーションを走らせているコンテキストをアドミニストレータが変更する時、アプリケーションは、その新しいコンテキストに対するコンフィギュレーション情報をロードするために再び立ち上げられる必要がある。コンテキストが変更される度にソフトウエアを再び立ち上げるというプロセスは時間浪費するものであり、特に、多くのユーザを持つシステムにおけるアドミニストレータにとっては不便である。そのようなシステムでは、アプリケーションを環境設定している時、アドミニストレータが何回もコンテキストを変更することが予想される。
【００１１】
１つの局面によれば、本発明は、１つのサーバと複数のユーザ・ステーションとを相互接続するネットワークを含み、サーバはユーザ・ステーションにダウンロードするための複数のユーザ・アプリケーションを記憶するというネットワーク・システムにおいて、ユーザ・ステーションおいて実行されるアプリケーションに対するユーザ・コンフィギュレーション・プリファレンスを管理する方法を提供する。
【００１２】
その方法は、すべてのシステム・ユーザを含む全ユーザ・グループ・ノードと、複数の下位グループ・ノードにして各々がそれらのユーザのうちの下位グループ・ノードによって表されたグループに属する選択されたユーザを含む複数の下位グループ・ノードとからなるツリー階層でそのシステムのすべてのユーザを表すステップであって、各ノードがそのシステムにおける使用可能なアプリケーションのうちの選択されたアプリケーションに対するコンフィギュレーション・プリファレンスを含む、ステップと、
複数のグループのメンバである各ユーザに対してグループ優先順位を割り当てるステップと、
選択されたアプリケーションの実行をリクエストする任意の所定のユーザに関して、そのユーザに対するグループ優先順位を決定するステップと、
その選択されたアプリケーションに対する一組のプリファレンスを取り出し得るグループ優先順位リストから第１グループを決定すること、
全ユーザ・グループ・ノードから第１グループにツリーをトラバースすることによってプリファレンスをその選択されたアプリケーションに対するセットに合体させること、
その選択されたアプリケーションに対する各ノードにおいて指定されたプリファレンスを収集すること、
各ノードが、その選択されたアプリケーションに対する当該ノードにおいて指定されたプリファレンスによってトラバースされる時、その収集されたプリファレンスを修正すること、
によってツリーから一組のコンフィギュレーション・プリファレンスを形成するステップと、
を含む。
【００１３】
第２の局面によれば、本発明は、１つのサーバ及び複数のユーザ・ステーションを相互接続するネットワークを含み、サーバは、ユーザ・ステーションにダウンロードするための複数のユーザ・アプリケーションをサーバが記憶するというネットワーク・システムにおいて、ユーザ・ステーションにおいて実行されるアプリケーションに対するユーザ・コンフィギュレーション・プリファレンスを管理するための装置を提供する。
【００１４】
前記装置は、すべてのシステム・ユーザを含む全ユーザ・グループ・ノードと複数の下位グループ・ノードにして各々がそれらのユーザのうちの下位グループ・ノードによって表されたグループに属する選択されたユーザを含む複数の下位グループ・ノードとからなるツリー階層でそのシステムのすべてのユーザを表すための手段であって、各ノードがそのシステムにおける使用可能なアプリケーションのうちの選択されたアプリケーションに対するコンフィギュレーション・プリファレンスを含む、手段と、
複数のグループのメンバである各ユーザに対してグループ優先順位を割り当てるための手段と、
選択されたアプリケーションの実行をリクエストする任意の所定のユーザに関して、そのユーザに対するグループ優先順位を決定するための手段と、
その選択されたアプリケーションに対する一組のプリファレンスを取り出し得るグループ優先順位リストから第１グループを決定すること、
全ユーザ・グループ・ノードから第１グループにツリーをトラバースすることによってプリファレンスをその選択されたアプリケーションに対するセットに合体させること、
その選択されたアプリケーションに対する各ノードにおいて指定されたプリファレンスを収集すること、及び
各ノードが、その選択されたアプリケーションに対する当該ノードにおいて指定されたプリファレンスによってトラバースされる時、その収集されたプリファレンスを修正すること、
によってツリーから一組のコンフィギュレーション・プリファレンスを形成するための手段と、
より成る。
【００１５】
第３の局面によれば、本発明は、１つのサーバ及び複数のユーザ・ステーションを相互接続するネットワークを含み、サーバは、ユーザ・ステーションにダウンロードするための複数のユーザ・アプリケーションを記憶するというネットワーク・システムにおいて、ユーザ・ステーションにおいて実行されるアプリケーションに対するユーザ・コンフィギュレーション・プリファレンスを管理する方法をコンピュータ上でランする時に実行するためのコンピュータ読み取り可能な記憶媒体に記憶されたコンピュータ・プログラム製品を提供する。
【００１６】
上記方法は、すべてのシステム・ユーザを含む全ユーザ・グループ・ノードと、複数の下位グループ・ノードにして各々がそれらのユーザのうちの下位グループ・ノードによって表されたグループに属する選択されたユーザを含む複数の下位グループ・ノードとからなるツリー階層でそのシステムのすべてのユーザを表すステップであって、各ノードがそのシステムにおける使用可能なアプリケーションのうちの選択されたアプリケーションに対するコンフィギュレーション・プリファレンスを含む、ステップと、
複数のグループのメンバである各ユーザに対してグループ優先順位を割り当てるステップと、
選択されたアプリケーションの実行をリクエストする任意の所定のユーザに関して、そのユーザに対するグループ優先順位を決定するステップと、
その選択されたアプリケーションに対する一組のプリファレンスを取り出し得るグループ優先順位リストから第１グループを決定すること、
全ユーザ・グループ・ノードから第１グループにツリーをトラバースすることによってプリファレンスをその選択されたアプリケーションに対するセットに合体させること、
その選択されたアプリケーションに対する各ノードにおいて指定されたプリファレンスを収集すること、及び
各ノードが、その選択されたアプリケーションに対する当該ノードにおいて指定されたプリファレンスによってトラバースされる時、その収集されたプリファレンスを修正すること、
によってツリーから一組のコンフィギュレーション・プリファレンスを形成するステップと、
を含む。
【００１７】
本願において開示されるシステムは、クライアント／サーバ環境においてユーザ及びアプレットのためのコンフィギュレーション情報に対して共通のリポジトリを提供する。これは、クライアント・プロファイル管理と呼ばれる。システムは、ユーザがローミングすること、即ち、任意の時間にシステムにおける任意のコンピュータからログ・インすること及びそのユーザのためにサーバに記憶されたプリファレンスに従って任意の時間にそれを自動的に環境設定させることを可能にする。望ましい実施例はＪａｖａベースのシステムであり、クライアント・コンピュータがＪａｖａアプリケーションを実行するように配列されたウェブ・ブラウザ・インターフェースを使用する（Ｊａｖａは、サン社（Sun Inc.）の商標である）。従って、望ましい実施例では、ユーザ・アプレット及びデスクトップ・アプレットはＪａｖａアプレットであると仮定する。しかし、それは、本発明をＪａｖａ環境に限定することを意図するものではない。ローカル的に記憶されたアプリケーションに対するプリファレンスは伝統的な方法でローカル的に記憶されてもよく、一方、サーバ・ベースのアプレットに対するプリファレンスは本願において開示された方法で処理されてもよい。
【００１８】
本発明は、システムのユーザ、ユーザ・グループ、端末、及び端末グループのユーザを１つの階層としてモデル化すること、並びに各グループ及び個々のユーザに対するデスクトップ及びユーザ・アプリケーション・プリファレンスを別々に設定することを可能にする。或る選択されたグループ・コンテキスト、例えば、システムのすべてのユーザのグループ、又は一組の選択されたユーザを含む或るサブグループに対して、或る選択されたユーザ・アプレットに対するプリファレンスのデフォルト・セットが決定される。そこで、そのデフォルト・セットは、選択されたグループにおいて特定的に示されたプリファレンスに従って修正される。しかる後、これらのプリファレンスは、本質的にそのユーザに属する一組のプリファレンスによって再び修正される。
【００１９】
望ましい実施例では、システムのすべてのユーザが１つのツリー階層で表される。なお、そのツリー階層は、すべてのシステム・ユーザを含む全ユーザ・グループ・ノードと、複数の下位グループ・ノードにして、各々がその下位グループ・ノードによって表されたグループに属する一組の選択されたユーザを含む下位グループ・ノードとより成る。各ノードは、そのシステムにおいて使用可能であるアプリケーションのうちの選択されたアプリケーションに対するコンフィギュレーション・プリファレンスも含む。アドミニストレータは、複数のグループのメンバである各ユーザに対してグループ優先順位を割り当てる。アプリケーションが１つのユーザによって実行される時、そのアプリケーションはサーバからのそれのプリファレンスをリクエストする。先ず、そのユーザに対するグループ優先順位が決定される。しかる後、選択されたアプリケーションに対する一組のプリファレンスを取り出し得るグループ優先順位リストから第１グループを決定すること及びそれらのプリファレンスを合体してその選択されたアプリケーションに対するセットにすることによって、一組のコンフィギュレーション・プリファレンスが形成される。その合体は、ツリーを全ユーザ・グループ・ノードから第１グループまでトラバースすること、各ノードにおいて指定されたその選択されたアプリケーションに対するプリファレンスを収集すること、及びそのノードにおいて指定されたその選択されたアプリケーションに対するプリファレンスに関して各ノードがトラバースされる時にその収集されたプリファレンスを修正することによって遂行される。
【００２０】
本発明は、非階層構造が提供し得る編成上の融通性及び管理上の能力よりもずっと多くの編成上の融通性及び管理上の能力を提供することができる。階層構造は、ほとんどの企業の編成をより正確に記述することができる。モデル化される企業が大きければ大きい程、階層的に編成する能力は重要である。
【００２１】
本願において開示されるシステムは、クライアント／サーバ環境におけるすべてのユーザ及びアプレットに対するコンフィギュレーション情報のための共通のリポジトリを提供する。これは、クライアント・プロファイル・マネージメントと呼ばれる。システムは、ユーザがローミングすること、即ち、任意の時間にそのシステムにおける任意のコンピュータからログインすること及びサーバに記憶されたプリファレンスに従って実行時にそれを自動的に環境設定させることを可能にする。望ましい実施例はＪａｖａベースのシステムであり、クライアント・コンピュータがＪａｖａプログラムを実行するように調整されたウェブ・ブラウザ・インターフェースを使用する。
【００２２】
用語「アプレット（applet）」及び「サーブレット（servlet）」はＪａｖａプログラミング言語の分野における確立された用語であり、それらの用語は当業者にとっては意味を持つものであるので、本願においても使用される。「アプレット」は、Ｊａｖａイネーブルド・ウェブ・ブラウザにおいて走る独立したソフトウエア・モジュールを指す。「サーブレット」は、Ｊａｖａイネーブルド・ウェブ・サーバに常駐するソフトウエア・モジュールを指す。本願における用語「アプレット」及び「サーブレット」の使用が如何なる意味においても本発明を限定しようとするものではないことは当然である。説明の便宜上、本願では、語句「コンフィギュレーション・アプレット」は、ワード・プロセッサ、データベース・マネージャ等のようなエンド・ユーザのソフトウエア・アプリケーションに対するプリファレンスを環境設定するために使用されるソフトウエア・モジュールを指すために使用される。ソフトウエア・アプリケーションもＪａｖａ環境では「アプレット」であるので、本願では、エンド・ユーザのアプリケーションを指すためには、語句「ユーザ・アプレット」又は単なる「アプレット」が使用される。
【００２３】
望ましい実施例では、ユーザ・アプレット及びデスクトップ・アプレットはＪａｖａアプレットであると仮定される。しかし、本発明はＪａｖａ環境に限定されないことは勿論である。本発明は任意のクライアント／サーバ・システムにおいて使用可能である。例えば、望ましい場合には、システムは、財産権のある通信プロトコルを使用するように及び任意の所望のプログラミング言語で書かれそしてコンパイルされたアプリケーションを使用するように設計可能である。更に、望ましいＪａｖａベースの環境において、ディスク・ベースのコンピュータは或るアプリケーションをローカル的にアクセスされてもよく、他のアプリケーションをサーバからアクセスしてもよい。ローカル的に記憶されたアプリケーションに対するプリファレンスは伝統的な方法でローカル的に記憶されてもよく、一方、サーバ・ベースのアプレットに対するプリファレンスは本願において開示された方法で処理可能である。しかし、望ましくは、ローカル的に記憶されたアプリケーションに対するプリファレンスは、本願において開示されたサーバ・ベースのアプレットに対するプリファレンスに加えて、プロファイル・マネージメント・プロパティＡＰＩを使用してサーバに記憶される。
【００２４】
簡単なアプリケーション・プログラム・インターフェース（ＡＰＩ）は、そのＡＰＩに対して書かれたアプレットがユーザ又はアドミニストレータによって実行される時、そのアプレットがプリファレンス・データを容易に記憶すること及び検索することを可能にする。アプレット・パーミッション及びユーザ・プリファレンスは、グループ・メンバーシップ及び個々のアイデンティティに基づいて定義されることが可能である。
【００２５】
クライアント・プロファイル・マネージメントは次のようなサービスを含む。
ログオン・サポート：ユーザ・プロファイルへのマッピング。
ユーザ・サポート：ユーザ識別情報を作成し、ユーザにサービス及びプリファレンスを直接に提供するための管理的機能。
ユーザ・グループ・サポート：ユーザの階層グループを作成し、グループ・メンバーシップに基づいてサービス及びプリファレンスを提供するための管理的機能。
ユーザ・アプレット・コンテキストの透明性：ユーザ・アプレットの実行のコンテキストの自動的な決定。即ち、ユーザ・アプレットの実行及びプロファイル環境の自動的な確立に適用するユーザ及び／又はグループ・プロファイルの決定。
ユーザ・アプレット・プリファレンス・リポジトリ：ユーザ・アプレット・コンフィギュレーション・データのためのコンテキスト・センシティブなサーバ記憶装置。
ダイナミック・ユーザ・アプレット・プリファレンス継承：継承のオブジェクト指向プリンシパルを介したユーザ・アプレット・プリファレンスの階層的なロード時の合体。
ユーザ・アプレット・アクセス制御：グループ・デフォルト・メンバーシップ特権に基づくユーザ・アプレットの制御。アドミニストレータはデフォルト・グループ特権をオーバーライドし、個々のユーザに対する更なるアクセス特権を許可又は拒否することができる。
【００２６】
プロファイル・マネージメントは、これらのタスクが遂行されるフレームワークを提供する。或るタスクは、例えば、ユーザ／グループ・マネージメント、アプレット・リスト、コンテキスト・スイッチング、プリファレンス継承等をプロファイル・マネージメントによって直接にサポートされる。一方、ユーザ・アプレットに特有のコンフィギュレーション・サービスは、通常、クライアント・プロファイル・マネージメント環境においてシステム・アドミニストレータにより呼び出された別のコンフィギュレーション・アプレットによってサポートされる。或るエンド・ユーザ・アプレットは、コンフィギュレーション機能をそのエンド・ユーザ・アプレットの一部として提供することがあり得る。この場合、アドミニストレータは、個々のユーザ及びグループのコンテキストにおいて、それらのユーザ及びグループに対するプリファレンスをセットするために、（別のコンフィギュレーション・アプレットとは対照的に）エンド・ユーザ・アプレットを走らせることができる。
【００２７】
第１図は、本発明を実施するための意図された環境に関する１つの高レベルの構成図を示す。ネットワーク１００が、デスクトップ・パーソナル・コンピュータ１０２、モバイル・ラップトップ・コンピュータ１０４、ワークステーション１０６（例えば、ＲＩＳＣコンピュータ）のような複数のユーザ・ステーション、アドミニストレータのステーション１０８、及びサーバ１１０を相互接続するために設けられる。１つの実施例では、ネットワーク１００はローカル・エリア・ネットワークであってもよい。もう１つの実施例では、ネットワーク１００は、地理的に変位したサイト（依然としてそのシステムに含まれる）を有する会社のようなエンティティのための広域ネットワーキングを含んでもよい。本発明を実施し得る環境を限定する意図は全くない。むしろ、多くのタイプのステーションを相互接続する任意のタイプのネットワークが想定される。
【００２８】
第２図には、プロファイル・マネージメント管理操作環境の高レベル・ブロック図が示される。アドミニストレータ・クライアント・ネットワーク・コンピュータ２００がその図の左側に表示され、そのシステムに対するサーバ２０２が右側に表示される。クライアント及びサーバは、参照番号２０３として表されたネットワークを介してコミュニケーションを行う。第２図の特定の例は、クライアント・コンピュータがシステム・アドミニストレータのコンピュータであると仮定する。
【００２９】
クライアント側におけるプロファイル・マネージャ２０６は、アドミニストレータがユーザ・レベル及びグループ・レベルの両方においてユーザ・アプレット・プリファレンスを環境設定することを可能にする。アドミニストレータは、新しいユーザ及びグループ階層を作成すること、ユーザを種々のグループに加えること、各グループ及び個々のユーザに対するアプレット・パーミッションを指定することができる。しかも、アドミニストレータは、個々のユーザ又はグループのコンテキストにおいてアプレットを環境設定することができる。アドミニストレータは、ユーザのためのパスワードを追加、削除、及びリセットすることができる。プロファイル・マネージメント・サポートは一般的なユーザにとって透明である。アドミニストレータは、いずれのユーザ又はグループのコンテキストにおいてもプロファイル・マネージャ２０６を呼び出すことができる。アドミニストレータだけが、自分のコンテキストからアドミニストレータ・クライアント（ユーザ）及びグループに変わることができる。サーバは、管理的な権限のないユーザがコンテキストを切り替えることを許さないであろう。リクエストがサーバに到達する時、それはこの機能をアクセスしようとするユーザの認証されたＩＤを照会するであろう。ユーザが管理的な権限を持っていない場合（即ち、全ユーザ・アドミニストレータ・グループのメンバではない場合）、プロファイル・マネージャ・サーブレット２１４はそのリクエストを拒否するであろう。
【００３０】
第２図に示されるように、プロファイル・マネージャ２０６はアプレット１（２０８）のような他のアプレットを呼び出す。この例では、アプレットは、ユーザ・デスクトップに関連したプリファレンスを環境設定するための管理的アプレットであってもよい。即ち、アプレット１は、エディタ、ワードプロセッサ、データベース等のようなエンド・ユーザ・アプレットに関連したコンフィギュレーション・ユーティリティであってもよい。アプレット１（２０８）のようなコンフィギュレーション・アプレットがそれらの対応するユーザ・アプレットとは別個のモジュールとして存在することは望ましいが、必要なことではない。第２図のコンテキストでは、アプレット１は、一般には、ユーザ・アプレットのためのコンフィギュレーション・アプレットである。アドミニストレータは、グループ・コンテキストの下でコンフィギュレーション・アプレット、即ち、アプレット１を走らせてグループ・プリファレンス及びパーミッション・デフォルトをセットするか又はユーザ・コンテキストにおいて個人に対するユーザ・アプレット・コンフィギュレーションをカスタマイズする。アプレット１をユーザ・アプレットとは別個のモジュールとして実装することによって、パフォーマンスが強化される。それは、コンフィギュレーション・アプレット１がユーザ・アプレットに比べて小さそうであるためである。又、別のコンフィギュレーション・アプレットは、アドミニストレータがエンド・ユーザの能力を制御してユーザ・アプレットを環境設定することを可能にする。
【００３１】
伝統的な独立型コンピュータは、それのユーザ・アプレットに関連してユーザ・アプレット・コンフィギュレーション情報をローカル的に記憶する。伝統的な独立型のＪａｖａベースのコンピュータは、Ｊａｖａユーティリティ・プロパティ・クラスによって提供されるフォーマットを使用してユーザ・アプレット・コンフィギュレーション情報を記憶する。両方の構成とも、ユーザ・アプレットに関連するコンフィギュレーション情報を記憶すべきローカル・ファイルの名前を指定する。換言すれば、コンピュータとそれにロードされたユーザ・アプレットとの間には或る関係が必要である。本願において開示されるようなプロファイル・マネージメントは、リアルＪａｖａユーティリティ・プロファイル・オブジェクトに関するよく知られている機能と、ユーザ・ローミング機能及び強力な管理的フレームワーク（プロファイル・マネージャ）へのシームレス・プラガビリティ（pluggability）をサポートする付加的な機構とを提供する。
【００３２】
ProfileManagementProperties P（２１０）はアプレット１に対するプロパティ・オブジェクトであり、アプレット１に対するコンフィギュレーション情報をユーザ及びグループのコンテキストにおけるどこに記憶すべきかをサーバが決定することを可能にするＡＰＩをアプレット１及びサーバの間に与える。ProfileManagementProperties のオブジェクト・クラスは、永続記憶装置からのソフトウエアに対するコンフィギュレーション情報の作成、保存、及び検索を提供するための更なる能力をＪａｖａユーティリティ・プロパティ・クラスのすべての機能に与える。そのような情報を中央のロケーションに記憶することは、ユーザ及びグループ・コンフィギュレーションのマネージメントを可能にする。
【００３３】
ユーザがアドミニストレータの役割をする時、ProfileManagementProperties ２１０は、アドミニストレータがコンフィギュレーション・アプレット１に対応するユーザ・アプレットを環境設定すること又はアプレット１がエンド・ユーザ・アプレットである場合、アプレット１を環境設定することを可能にし、コンフィギュレーション情報をサーバにおける適正な位置に適正なコンテキストで記憶する。これは、伝統的なシステムにおけるようなユーザ・アプレットとコンピュータとの間ではなく、ユーザ・アプレットとユーザとの間に或る関係を確立することを可能にする。
【００３４】
ProfileManagementProperties ２１０はＪａｖａユーティリティ・プロパティ・クラスの拡張である。その拡張は、プロパティ・オブジェクトのプリファレンス情報に関するキー／値のペアが、Ｊａｖａユーティリティ・プロパティを関連付けられるストリームとは対照的に１つのキーと関連付けられることを可能にする。次に、これは、アプリケーション開発者がそのキーを使用して、ファイル名及びパスではなくプリファレンス情報に対するコンテキストに関する独特なロケーションを指定することを可能にする。ProfileManagementProperties ２１０は自動的にそのキーを決定する。そのキーの生成に関しては、第８図及び第９図に関連して更に説明する。Ｊａｖａユーティリティ・プロパティ・クラスの後に ProfileManagementProperties ２１０をモデル化することによって、システムは再帰的クラス／デフォルト評価を通してプリファレンス継承を利用することができる。従って、この拡張されたクラスは、第３図に関して説明したように、現在のコンテキストで始まるプリファレンスを累積すること及びデフォルトに対するコンテキストの階層をトラバースすることによって「グループ・デフォルト」機能を提供する。
【００３５】
サーバ２０２は、ユーザ及びグループ・プリファレンス及びユーザ・アプレット・アクセス許可のようなユーザ・データ及びグループ・データを記憶するデータベース２１２を含む。ウェブ・サーバ２１８は、Ｊａｖａアプレットに対するサポートを持った代表的なウェブ・サーバを表す。プロファイル・マネージャ・サーブレット２１４は、プリファレンス・データに対するユーザ及びグループ識別情報をマップする。それは、更に、サーバにおけるアプリケーションへのユーザ・アクセスを管理するために、アクセス制御リストも維持する。
【００３６】
第３図に示されるように、ユーザ及びグループ・プリファレンスがツリー階層として記憶される。そのシステムのすべてのユーザがトップ・グループ「全ユーザ（AllUsers）」に自動的に属する。すべてのユーザが「全ユーザ」グループに属する。このグループは、サーバにおける或るユーザ・アプレット又はすべてのユーザ・アプレットに対するデフォルト・プリファレンスを含む。第３図では、サーバは、App3、App4、及び App5 として識別される少なくとも３つのユーザ・アプレットを含むものと仮定する。「全ユーザ」グループにおいて示されるように、App3に対するデフォルト・バックグラウンド（ＢＧ）は、ＢＧ＝ブルー（blue）である。ｘ、ｙ、及びｚと表された他の例示的プリファレンスは、それぞれ、１、２、及び３のデフォルト値を持つものとして示される。用語ｘ、ｙ、及びｚは任意の所望のプリファレンスを表すことを意図され、値１、２、及び３は任意のものであり、単にポイントを表すために使用される。ｘプリファレンスは、例えば、デスクトップに対するスクリーン・フォントであってもよく、値ｘ＝１が、Times-Roman というフォントを要求してもよい。同様に、すべてのユーザのための App4 に対するデフォルト・プリファレンスは、ＢＧ＝グレイ（Grey）、ｘ＝２、ｙ＝２、及びｚ＝２である。
【００３７】
「全ユーザ」グループにおけるデフォルト値は、他のユーザ・グループ及び個々のユーザに対するような他のコンテキストに対する任意の望ましい方法で修正可能である。例えば、第３図における「全ユーザ」のコンテキストに加えて、４つの他のグループ（グループＸ（GroupX）、グループＹ（GroupY）、グループＹ１（GroupY1）、及びグループＹ２（GroupY2））が示される。更に、２つの個人、即ち、ユーザ１（User1）及びユーザ２（User2）が示される。ユーザは複数のグループのメンバであってもよい。第３図では、ユーザ１は全ユーザ、グループＸ、及びグループＹのメンバであり、ユーザＮ（UserN）は全ユーザ及びグループＹ２のメンバである。ユーザが複数のグループ（全ユーザの他の別のグループ）のメンバである場合、それらのグループは、そのユーザのための所与のアプレットに対するプリファレンスを選択する目的で優先順位付けされる。アドミニストレータはユーザに対するグループ優先順位を環境設定する。第４図にはそのグループ優先順位が示される。第４において、ユーザ１は、グループＸ（そのユーザの最高優先順位グループに対して全ユーザ・グループＸ（AllUsers.GroupX）という完全に修飾された名前によって識別される）を有する。ユーザ１の次の最高優先順位グループはグループＹ１である（AllUsers.GroupY.GroupY1）。ユーザ１の最低優先順位グループは「全ユーザ」グループである。ユーザ、例えば、ユーザ１が１つのアプレット、即ち、アプレット３を走らせるように要求する時、そのユーザが属するグループに従って、第３図のツリーからプリファレンスが合体させられ、それに従って、そのユーザ・アプレットがユーザ・デスクトップにおいて環境設定される。
【００３８】
任意のコンテキストに対するプリファレンスを合体する場合の第１ステップはデフォルトを得ることである。ユーザに対するデフォルトが存在する場合、そのデフォルトは、アプレットに対するプリファレンス情報を得ることができる最高の優先順位グループからのアプレットに対するプリファレンスの合体したセットである。グループに対するデフォルトが存在する場合、そのデフォルトは、グループ・ペアレントからのアプレットに対するプリファレンスの合体したセットである（即ち、全ユーザ（AllUsers）グループは全ユーザ・グループＸ（AllUsers.GroupX）のペアレントである)。グループがペアレントを持たない場合（即ち、トップ・レベルの全ユーザ・グループである場合）、そのグループに対するデフォルトは存在しない。コンテキストにおけるアプレットに対するプリファレンスを合体させるために、そのコンテキストにおいて明確に記憶されたアプレットに対するプリファレンスが、コンテキストのためのそのアプレットに対するデフォルト・プリファレンスをオーバライトする。従って、プリファレンスを合体させてグループ・コンテキストにおけるアプレットに対するデフォルト・セットにするために、各グループ・ノードから全ユーザ・グループまで、アプレットに対するプリファレンスの各ペアレント・セットを要求する再帰コールが行われる。次の例を説明するために第３図を参照してほしい。例えば、コンテキストが全ユーザ・グループＹ・グループＹ１（AllUsers.GroupY.GroupY1）である場合、グループＹであるグループＹ１のペアレントに対して、アプレットに対するそれのデフォルト・プリファレンスを要求するコールが行われる。グループＹ１は、全ユーザであるそれのペアレントに対して再帰コールを行う。全ユーザはペアレントを持たないので、全ユーザはアプレットに対するそれのプリファレンスのセットをグループＹからのコールに戻す。このプリファレンスのセットは、グループＹに記憶されたそのアプレットに対するプリファレンスがある場合、それによって修正される。これは、今や、グループＹ１のコンテキストのためのアプレットに対するプリファレンスのデフォルト・セットである。デフォルト・プリファレンスのこのセットは、グループＹ１からグループＹへの再帰コールの結果としてグループＹ１に戻され、この場合に使用されるべきプリファレンスの実際のセットとなるように、アプレットに対するグループＹ１におけるプリファレンスがある場合、そのプリファレンスによって修正される。デフォルトが得られるグループ・コンテキストを最初に確立するために、ユーザに対するプリファレンス情報を得ることができる最高の優先順位グループが使用されるということを除けば、ユーザのコンテキストに対するプリファレンスのセットが同じ方法で形成される。そこで、ユーザ及びそのユーザによってリクエストされたアプレットに対するプリファレンスの実際のセットを形成するために、上記の再帰手順が使用される。
【００３９】
次の例は上記のプリファレンス合体を示すものであり、第３図と関連して説明される。
【００４０】
例１：全ユーザ・グループＸ（AllUsers.GroupX）というグループに対するプリファレンスを設定するために、アドミニストレータが App3 に対するコンフィギュレーション・アプレットを走らせる。
【００４１】
全ユーザ・グループＸのコンテキストにおいて App3 に対するプリファレンスを設定するためには、現在のプリファレンス・セットが決定されなければならない。全ユーザ．グループＸはそれのペアレントである全ユーザに対するデフォルトをリクエストする。全ユーザはトップ・レベル・グループであるので、それは App3 に対するそれのプリファレンスをグループＸに戻す。これらは、グループＸのコンテキストにおける App3 に対するデフォルト・プリファレンスである。グループＸが App3 に対するプリファレンスを持たない場合、全ユーザからのデフォルト・セットは、使用されるべきプリファレンスの実セットである。この例では、全ユーザ・グループからのこれらのプリファレンスは、BG=青（blue）、x=1、y=2、z=3 である。今や、アドミニストレータは、合体されたプリファレンスを任意の望ましい方法で修正するようにコンフィギュレーション・アプレットの使用を修正することができる。
【００４２】
例２：ユーザ１が com.ibm.App3 の実行をリクエストする。com.ibm.App3 に対するプリファレンスがユーザ１のコンテキストにおいて合体されなければならない。
【００４３】
第４図は、ユーザ１に対する最高優先順位グループが全ユーザ・グループＸ（AllUsers.GroupX）であることを示す。グループ階層のこの分岐が App3 に関連するプリファレンス情報に関して最初にチェックされるであろう。この点から、合体されたプリファレンス・セットがユーザのワーク・ステーションにおいて App3 を環境設定するために使用されるということ除けば、この例は上記の例１と本質的に同じである。ユーザ１のための App3 に対するプリファレンスは、BG=緑（Green）、x=1、y=2、z=3 である。それは、ユーザ１のコンテキストに記憶された App3 に対する BG=緑（Green）のプリファレンスがプリファレンス・ツリーの全ユーザ．グループＸ分岐から得られたデフォルト BG=青（Blue）プリファレンスをオーバライドするためである。
【００４４】
例３：ユーザ１のコンテキストにおける com.ibm.App6 に対するプリファレンスの合体。
【００４５】
この例は、最高の優先順位グループがユーザ１のコンテキストに対する合体したプリファレンスを含まないという状況を示す。再び、ユーザ１に対する最高優先順位グループはグループＸである。このグループ及びそれのペアレントの全ユーザは App6 に対するプリファレンスを全く含まない。従って、次の最高優先順位グループがサーチされる。App6 に対する一組のプリファレンスをこのグループから得ることができる。プリファレンスの合体は例１において説明したように進行する。ツリー上のグループＹ１からルートの全ユーザ・グループまでの再帰コールが行われ、そしてプリファレンス・セットが再帰コールの下に戻され、デフォルト・セットを形成するための方法に従って修正される。そこで、デフォルト・セットは、このコンテキストに適用するプリファレンスの合体セットを形成するように、グループＹ１に記憶されたプリファレンスでもって修正される。要するに、「全ユーザ」は、それが App6 に対するプリファレンスを持たないので、ナル・セットのプリファレンスを戻す。グループＹはこのナル・セットを値 a=1 及びb=2 でもって修正し、このセットをデフォルト・セットとしてグループＹ１に戻す。グループＹ１はそのデフォルト・セットを a=33 でもって修正する。このセットは、その後の使用のために、ユーザ１にそれのデフォルト・セットとして戻される。ユーザ１コンテキストは App6 に対するプリファレンスが記憶されてないので、プリファレンス・ツリーのグループＹ１分岐から得られたデフォルトは、App6 に対するプリファレンスの完全に合体したセットを表す。従って、このコンテキストに対するプリファレンスの実セットは a=33、b=2 となる。
【００４６】
上記の３つの例は、特定のソフトウエア・ピースに対する load() に応答してプリファレンスを収集することを説明した。１つのソフトウエア・ピースに対するプリファレンス情報が保存される時、保存されるコンテキストにおいて明示的に書かれている如何なるプリファレンスも、そのソフトウエアを走らせているコンテキストと記憶されるべきプリファレンスを持ったソフトウエアに対するキーとの結合によって指定されたロケーションにおいてデータ記憶装置２１２に書き込まれるであろう。
【００４７】
パーミッションが同様に動作する：新しいグループが、そのグループ自体によって許可されたすべてのアプレット名に対するアクセス及びそれのスーパーグループによって許可されたすべてのアプレットに対するアクセスを有する。しかし、プログラマがスーパークラス方法をオーバライドすることをＪａｖａが許容した時点で、プロファイル・マネージメントは、継承されたパーミッションをシステム・アドミニストレータがオーバライドすることを可能にする。これは、パーミッションのオーバライドと呼ばれる。
【００４８】
Ｊａｖａの継承の形式に関するように、プロファイル・マネージメントのプリファレンス及びパーミッション継承の形式はシングル継承と呼ばれる。シングル継承は、各プロファイル・マネージメント・グループが１つのスーパーグループしか持つことができない（しかし、所与のいずれのスーパグループも複数のサブグループを持つことができる）ことを意味する。
【００４９】
プロファイル・マネージメント・ユーザ（リーフ・ノード）は複数のグループにおけるメンバシップを要求することがあり得るので、クロス・グループ・ブランチが合体することにより引き起こされる非互換性の可変サブセットの導入によって、コンフィギュレーションを破壊する機会を最小にするために、プリファレンス継承を単一の階層グループに制限するための機構が必要である。ユーザのグループ・メンバシップが優先順位付けられることを可能にすることによって、プロファイル・マネージメントは、特定のアプレットに関連したプリファレンスを捜す時、サーチの順序に従うことが可能である。換言すれば、サーチは、最高優先順位を持ったグループでもって開始し、自分のプリファレンスをロードしようとしているアプレットに対するコンフィギュレーション・データを含むことがわかった第１グループにおいて停止するであろう。
【００５０】
ユーザは、グループ・メンバシップからのソフトウエア・パーミッションを継承する。注意深い企業モデル化によって、アドミニストレータは、パネルを通してナビゲートすることを必要とせずに、多くのユーザに対して、一時に１つのユーザにソフトウエア・アクセスを割り当てることができる。プロファイル・マネージメントは、アプレットへのアクセスを許容する／拒否するようにウェブ・サーバをプログラムすることによってアクセスを制御する。ウェブ・サーバはそのアクセス制御を強化する。プロファイル・マネージャ・サーブレットは、ユーザＩＤ及びパスワードが認証目的で送られて来ることを必要とするウェブサーバによっても保護される。必要に応じてユーザ・パスワードに関してプロンプト指示することは標準のブラウザ機能である。
【００５１】
第５図は第２図のシステムを更に詳細に示す。コンフィギュレーション・アプレットであるアプレット１がプロファイル・マネージメント・フレームワーク内にアドミニストレータによって呼び出される。アプレット１は、それの動作環境に関する情報（例えば、照会コンテキスト、コンテキスト変更イベント、このコンテキストに対する照会アクセス制御リスト等）を照会してプロファイル・マネージメント・フレームワーク内にしっかりと統合するようにアプリケーション・プログラム・インターフェース（ＡＰＩ）５１５をインプリメントすることができる。如何なる場合でも、アプレット１の設計者は、基本的なＡＰＩメソッド、即ち、Ｊａｖａユーティリティ・プロパティ・オブジェクトへのプリファレンス情報及びそのオブジェクトからのプリファレンス情報を得るために使用されるＪａｖａユーティリティ・プロパティ・オブジェクトの基本メソッドの他に enablePersistence()、load()、及び save() を理解することしか必要ない。ＡＰＩ５１５は、更に、list() 及び getContext() メソッドを提供する。アプレット１は、ProfileManagementProperties クラスでもって登録すること及びこれらのメソッドを適宜にコールすることしか必要ない。load() メソッドは、アドミニストレータによって選択されたユーザ又はグループのコンテキストにおいて環境設定されるユーザ・アプレットに対するプリファレンスの現在の状態を検索するために呼び出し可能である。そこで、アドミニストレータは所望のプリファレンスを修正し、アプレットによって与えられるコンフィギュレーション保存機能（それの ProfileManagementProperties オブジェクトの save()メソッドを使用する）を使ってそれらを記憶することができる。同様に、アプレット１がユーザによるアクセスに対して許可されたユーザ・アプレットのリストを必要とする場合、それは、サーバからそのリストを得るために list() メソッドを使用することができる。getContext() メソッドは、それが走っているコンテキストの名前を表示するために、或いはそれが所定のコンテキストにおいて走るだけであるということを保証するためにもアプレットによって使用されることがあり得る（即ち、アプレットがエクスポート・エージェントを使用してサーバにおけるサービスを環境設定することを望む場合、エクスポートされるコンフィギュレーションはユーザ特有であるのとは対照的にサーバ特有であるので、それは、それ自身が「全ユーザ」コンテキストにおいて走らされることを可能にするだけであろう）。アプレット１がプロファイル・マネージメント・フレームワークにおいて走るためには、必要とされることは、アプレットが ProfileManagementProperties ４１０に登録すること及び ProfileManagementProperties クラス、即ち、Ｊａｖａユーティリティ・プロパティ・クラスの拡張をインプリメントすることである。
【００５２】
プロファイル・マネージャ５０６も、コンフィギュレーション・アプレットのためにコンテキスト変更ＡＰＩ５１６を提供する。アプレット１は、コンテキスト変更イベント・リスナ５１２をインプリメント可能である。ＡＰＩ５１６及びイベント・リスナ５１２は、アドミニストレータが、コンフィギュレーション・アプレットを停止及び再始動させることを必要とせずに、それを走らせながらコンテキスト（ユーザ又はグループ）を変更することを可能にする。例えば、アプレット・ユーザ・プリファレンスを環境設定する時、恐らく、アドミニストレータはコンフィギュレーション時に何回もコンテキストを変更するであろう。コンフィギュレーション・アプレットがそのようなイベントに対するリスナとして登録される場合、プロファイル・マネージャ５０６は、ＡＰＩ５１６を介してそれにコンテキスト変更を知らせるであろう。これは、アプレット１が新しい各コンテキストに対するそれのプリファレンスをサーバからリフレッシュすることを可能にする。イベント・リスナＡＰＩがない場合、アプレット１はアドミニストレータによって終了させられなければならず、新しいコンテキストに対する既存のプリファレンス情報を参照するために及びプロファイル・マネージメント・アプレットによって停止及び再始動させられることを回避するためにその新しいコンテキストが選択された後に再始動されなければならない。登録するためには、アプレット１は、それのプロパティ・オブジェクトである ProfileManagementProperties ５１０関するメソッド、即ち、「コンテキスト変更リスナを加える（addContextChangeListener）」（ＡＰＩ５１６）をコールし、それ自身を登録する。アドミニストレータが新しいコンテキストを設定する時、ファイル・マネージャ５０６がオブジェクト５１０に対してセット・コンテキスト・コールを遂行し（ＡＰＩ５１６）、それに応答して、オブジェクト５１０はイベント・リスナ５１２を介して再ロード・メソッドをコールする（ＡＰＩ５１６）。次に、イベント・リスナ５１２はそれのプロパティ・オブジェクト５１０へのロード・プロパティ・コールを遂行して新しいコンテキストに対する新しいプリファレンス・データをサーバから取得し、新しいプリファレンス情報を反映するようにアプレット１にそれのＧＵＩ及び内部変数を更新させる。
【００５３】
上記の機能は、ネットワーク・アドミニストレータが１つのコンテキストからデータを読み取る可能性、コンテキストを変更する可能性、及び新しいコンテキストにおいてコンフィギュレーション変更を行う前に load() を意図している時に偶発的に save() でもってオーバライトする可能性を回避する。
【００５４】
リスナとして登録しないアプレットは、アドミニストレータがコンテキスト変更を強制する時、プロファイル・マネージャ・アプレットによって停止させられ、破壊され、再ロードされ、及び再始動させられる。
【００５５】
プロファイル・マネージメントは、更に、既存のハードウエア及びソフトウエアを容易に改造することを可能にするために「プロパティ・エクスポート」サービスも提供する。そのプロパティ・エクスポート・サービスは、プロファイル・マネージャ・サーブレット５１４がユーザ、グループ及びユーザ・アプリケーションと同様にユーザ・ワークステーション（物理的なハードウエア）をサポートすること可能にする。既存のワークステーションは ProfileManagementProperties ５１０に関して何もわかっていないので、そのエクスポート・サービスは、ベンダ・アプレットがそれのプリファレンス情報を保存する時、サーバにおいて呼び出されるべきエクスポート・エージェント５２０を指定するワークステーション／コンフィギュレーション・アプレットをワークステーション・ベンダが作成することを可能にする。エクスポート・タグは、ベンダ供給のクラスのインスタンス（エクスポート・エージェント５２０のオブジェクト）が作成されるようにし、環境設定されるワークステーションが必要とするどのような財産的価値のあるファイル・フォーマットにおいても及び／又はどのようなファイル・ロケーション内にもワークステーション・コンフィギュレーション情報が保存されることを指定するために、エクスポート・メソッドがオブジェクト上に呼び出されるようにする。
【００５６】
アプレット１はそのプロファイル・マネージメント・システムと互換性のない既存の端末に対するベンダによって供給されたコンフィギュレーション・アプレットであると仮定する。ベンダはエクスポート・エージェント５２０も供給する。アドミニストレータは、プロファイル・マネージャ５０６を走らせることによってこのシステムにおけるオペレーションのために端末を環境設定すること、環境設定される端末にコンテキストを設定すること、ベンダ供給のコンフィギュレーション・アプレット１を走らせること、及びそのアプレットを環境設定することができる。アドミニストレータがそのコンフィギュレーションを保存する時、サーバに送られる情報の一部は、環境設定される端末を指定する独特の識別子である。一般に、これは端末のメディア・アクセス・コントロール（ＭＡＣ）アドレスである。プロファイル・マネージャ・サーブレット５１４は、エクスポート・エージェントがその保存時に指定されるということを検出する。プロファイル・マネージャ・サーブレット５１４は、保存されるプリファレンスのうちの、エクスポート・エージェントに対する必要性を指定するプリファレンスからこれを検出する。そのプリファレンスは、エクスポート・タグを次のようなキー値の対という形式で指定する。
XXXXEXPORT_AGENTXXXX={エクスポートエージェントの完全に修飾されたクラス名}
【００５７】
エクスポート・エージェントのエクスポート（コンテキスト・コンテキスト、コンフィギュレーション・プロパティ）メソッドがプロファイル・マネージャ・サーブレット５１４によってコールされ、保存プリファレンス情報から１つ又は複数のファイル５２２をサーバにおいて作成させる。アプレット１からプロパティ情報と共に生じた端末に関する独特の識別子によって特定のファイルが識別される。その後、端末がブート・アップする時、それは、ファイル・マネージメント・システムに関係なく、それの独特の識別子を使用して、いつも行っていた方法と同じ方法でそれのコンフィギュレーション情報を位置指定し、サーバ上のファイル５２２からそれを検索する。
【００５８】
第６図はクライアント・コンピュータ上で走るアプレット２を示す。アプレット２は、ワードプロセッサのようなエンド・ユーザ・アプレットであってもよい。如何なる場合でも、アプレット２は、第５図の参照番号５１５において示されるように、同じＡＰＩメソッドのうちの或るものに対するアクセスを、それが望ましい場合に、有する。アプレット２はプリファレンスを検索するためにロード・メソッドを使用し、ユーザによって変更されることがあり得る何らかのプリファレンスを保存するために保存メソッドを使用する。イネーブル・パーシステンス（enablePersistence）はユーザに等しいコンテキストを持ったアプレット２に対する ProfileManagementProperties オブジェクトを初期設定し、アドミニストレータに関して上述したように、サーバにおけるプリファレンス情報記憶ロケーションを識別するための独特のキーを生成する。
【００５９】
第７図は、ユーザが自分のデスクトップを立ち上げる時の状況を示す。クライアント７００におけるユーザは、サーバ７０２におけるデスクトップ・アプレットのＵＲＬにおいて自分のウェブ・ブラウザを指示し、ステップ７０４においてメッセージ http://server/Desktop.html)を送る。Desktop.html はサーバが保護しているファイルであるので、ステップ７０６においてクライアントにおけるウェブ・ブラウザにチャレンジが返送される。クライアントにおけるウェブ・ブラウザは、ユーザＩＤ及びパスワードに関してユーザをプロンプト指示することによって応答する。そこで、クライアントは、ステップ７０８においてユーザＩＤ及びパスワード情報をサーバに送る。そのユーザＩＤ及びパスワード情報は、この情報がウェブ・ブラウザ自身によって送られることを表すために、第７図のステップ７０８として肉太文字で示される。同じことを表すために、このタイプの表記が他の場所においても使用される。恐らく、ユーザはデスクトップ・アプレットを走らせるための許可を持っているので、リクエストは受け入れられるであろう。
【００６０】
デスクトップ・アプレットに対するコードがサーバからクライアントにロードされる場合、クライアントとサーバとの間に一連の対話が存在する（図示されてない）。ステップ７１２において、デスクトップ・オブジェクトが作成され、実行を始める。デスクトップ・オブジェクトはそれのプリファレンス情報（即ち、コンフィギュレーション情報）を必要とし、従って、それはそれを呼び出そうとするエンド・ユーザに対してデスクトップを修正することができる。この目的のために、ステップ７１４において、デスクトップ・オブジェクトの初期設定プロセスの一部として、デスクトップは ProfileManagementProperties オブジェクト P を作成する。そのオブジェクトＰは、デスクトップ・アプレットに対する、そのサーバからのユーザのプリファレンス情報のコピーをロード、取得、キャッシュ、及び保存するために使用される。そこで、デスクトップ・オブジェクトは、ステップ７１６においてＡＰＩコール、即ち、P.enablePersistence（desktopObject（アプレット））を遂行する。それは、ステップ７１６のステップ１において、プロファイル・マネージャ・サーブレット２１４のＵＲＬでもって ProfileManagementProperties オブジェクト P を初期設定する。このＵＲＬは、前にサーバからロードされたデスクトップ・アプレットのＵＲＬから取り出される。ProfileManagementProperties オブジェクト P は、デスクトップ・アプレットを走らせているユーザに対するコンテキストを得るために、リクエスト７１８をプロファイル・マネージャ・サーブレット２１４に送る。この場合、コンテキストは、２つのコンポーネント、即ち、ユーザのＩＤであるコンテキスト名及びこの場合には User であるコンテキスト・タイプより成る。プロファイル・マネージャ・サーブレットは、リクエスト７１８からユーザのＩＤを取得し、ステップ７１９においてユーザ・コンテキストを戻す。ボックス７１６のステップ２において、ProfileManagementProperties オブジェクト P は、デスクトップを走らせているユーザのコンテキストを初期設定される。ステップ７１６のステップ３において、ProfileManagementProperties オブジェクト P は、Ｊａｖａデスクトップオブジェクト P にそれの完全に修飾されたクラス名を求めることによってデスクトップ・ソフトウエアに対する独特のキーを生成する。すべてのＪａｖａオブジェクトがそれらのクラス名を知っている。この独特のキーはユーザのコンテキスト情報と結合されて、デスクトップ・アプレットに対するユーザ特有のプリファレンス情報を記憶するためのデータベース２１２における独特のロケーションを指定するパラメータを提供する。完全に修飾されたクラス名及びユーザ・コンテキスト情報より成るストリングをデータ記憶ロケーションにマップすることによって、任意の望ましい方法を使用することが可能になる。次に、ユーザのための修正されたデスクトップ・アプレットに対するプリファレンス情報を得るために、プロファイル・マネージャ・サーブレット２１４にリクエスト７２０が送られる。リクエストされたプリファレンス情報を識別するために、コンテキスト及びキーがリクエスト７２０の一部として送られる。ステップ７２２において、プロファイル・マネージャ・サーブレット２１４がそのリクエストされたプリファレンス情報でもって応答し、それは ProfileManagementProperties オブジェクト P（６０４）においてキャッシュされる。
【００６１】
動作は第８図に継続する。ステップ８００において、デスクトップ・オブジェクトはそれのプリファレンス情報を ProfileManagementProperties オブジェクト P から読み出し、それに従ってデスクトップを更新し始める（即ち、それはスクリーン・カラーをブルーにセットし、アイコンの位置に関する情報を得る、等を行ってもよい）。デスクトップ・オブジェクトは、ユーザがアクセス許可を有するソフトウエアのリストを得るために、それの ProfileManagementProperties オブジェクト P に関するメソッドをコールする。ProfileManagementProperties オブジェクト P は、ステップ８０２において、プロファイル・マネージャ・サーブレット２１４からのその情報をリクエストする。プロファイル・マネージャ・サーブレット２１４は、ステップ８０４において、そのリクエストされた情報を持った応答を発生する。ユーザがアクセスを有するそのような各アプレットに対して、その情報は、ユーザ・フレンドリな名前、アプレットのＵＲＬ、アプレットに対するアイコンのＵＲＬ等（デスクトップにおいてそのアプレットを表すために及びそれをロード及び立ち上げるためにデスクトップに対して要求される情報）並びに本発明に関連しない他の任意選択的な資料を含む。その情報は ProfileManagementProperties オブジェクト P に記憶され、デスクトップ・オブジェクトに戻される。ステップ８０６において、デスクトップ・オブジェクトは、そのアプレット情報を使用してアプレットに対するフォルダを形成し、アイコン及びユーザがアクセスを有する各アプレットに対してユーザ・フレンドリな名前を表示するウインドウを生成する。
【００６２】
ユーザによるデスクトップにおける前の実行において、ユーザは、上述のフォルダで表示されたいくつかのソフトウエアに対するアイコンをドラッグ・アンド・ドロップしたと仮定する。この時、ユーザは、フォルダからデスクトップにドラッグ・アンド・ドロップされたアプレットへのアクセスを最早持っていないということが起こり得る。しかし、これらのデスクトップ・オブジェクトは、通常、最後の実行時に保存されたユーザ・プリファレンスの一部であろうし、依然としてデスクトップ上に表示されるであろう。この状況を回避するために、デスクトップは、ユーザがアクセスを有するすべてのアプレットを表示するために生成されるウインドウの外に、環境設定されるアプレットが現れるかどうかをチェックするために、それの ProfileManagementProperties オブジェクト P からのそれのプリファレンスを検査する。第８図は、生成されるアプレット・ウインドウの外に１つのアプレットしか存在しないものと仮定している。アプレット・ウインドウの外に複数のそのようなアプレットが存在する場合、そのような各アプレットに対して次のような手順がループするであろう。ステップ８１０において、デスクトップは、ユーザがアクセスを有するサーバからのアプレットのリストに抗してアプレット・ウインドウの外に現れるこれらのアプレットの各々をチェックする。アプレットがそのリストに現れる場合、ステップ８１０において、アプレットに対するアイコンがデスクトップ上の前と同じ位置に置かれる。ユーザが、最早、アプレットへのアクセスを持たない場合、ステップ８１４において、そのアプレットはデスクトップのプリファレンスから除去され、ProfileManagementProperties オブジェクト P から除去される。このプロセスの一部として、いずれかのアプレットが除去される場合、ステップ８１６において、デスクトップは、プリファレンスを保存するように ProfileManagementProperties オブジェクト P に命ずる。ProfileManagementProperties オブジェクト P は、プリファレンス、キー、及びコンテキスト情報と共にリクエスト８１８をプロファイル・マネージャ・サーブレット２１４に送り、新しいプリファレンス情報をデータベース２１２に保存させる。サーバは、リクエストが成功裏に終了したことを ProfileManagementProperties オブジェクト P に知らせる応答８２０を ProfileManagementProperties オブジェクト P に送る。
【００６３】
第９図は、他のユーザ又はユーザのグループのためのアプレットに対するプリファレンスを環境設定するためにアドミニストレータがコンフィギュレーション・アプレットを走らせる状況を示す。ここで説明される原理は、一般的に端末のコンフィギュレーション又は端末のグループのコンフィギュレーションにも適用することは勿論である。クライアント９００におけるアドミニストレータは、自分のブラウザに、走らされるべきサーバにおけるプロファイル・マネージャ・アプレット２１４のＵＲＬを指し示させる。ステップ９０４において、ＵＲＬがサーバに送られる。ProfileManager.html は、そのサーバが保護しているファイルであるので、チャレンジ９０６はクライアントにおけるウェブ・ブラウザに返送される。そのウェブ・ブラウザは、アドミニストレータにユーザＩＤ及びパスワードを促すことによって応答する。そこで、ステップ９０８において、メッセージに含まれたユーザＩＤ及びパスワード情報と共に、ProfileManager.html を得るためのリクエストが、サーバに対して反復される。恐らく、アドミニストレータはプロファイル・マネージャを走らせる許可を持っているので、リクエストは受け入れられ、ステップ９１０においてプロファイル・マネージャ・アプレットがアドミニストレータ端末にダウンロードされる。プロファイル・マネージャが・アプレットに対するコードがサーバからクライアントにロードされる場合、クライアントとサーバとの間で一連の対話（図示されてない）が存在する。ステップ９１２において、プロファイル・マネージャ・オブジェクトが作成され、実行を開始する。
【００６４】
ProfileManagementProperties_nonContextFloating が正規の ProfileManagementProperties オブジェクトに代わってプロファイル・マネージャによって使用される。それは１つの例外を除いて ProfileManagementProperties オブジェクトと同じ行為をする。その例外とは、プリファレンスがロード及び保存される時、それらは、アドミニストレータが初期設定しようとしているコンテキスト（即ち、ユーザ又はユーザ・グループ）へのロード及びそのコンテキストからの保存とは反対に、ファイル・マネージャを走らせようとしているアドミニストレータのコンテキストにロードされ、そのコンテキストから保存される。
【００６５】
プロファイル・マネージャ・オブジェクトはそれのプリファレンス情報（即ち、コンフィギュレーション情報）を必要とするので、それを呼び出そうとしているアドミニストレータに対するプロファイル・マネージャを手直しすることができる。このために、プロファイル・マネージャ・オブジェクトの初期設定プロセスの一部として、ステップ９１４において、プロファイル・マネージャは ProfileManagementProperties_nonContextFloating オブジェクト P_NCF を作成する。そのオブジェクト P_NCF は、プロファイル・マネージャ・アプレットに対するサーバからのアドミニストレータのプリファレンス情報のコピーをロードし、取得し、キャッシュし、設定し、及び保存するために使用される。そこで、プロファイル・マネージャ・オブジェクトは P_NCF.enablePersistence（profileManagerObject（アプレット））をコールする。それは、ステップ９１６におけるステップ１において、ProfileManagementProperties_nonContextFloating オブジェクト P_NCF をプロファイル・マネージャ・サーブレット２１４のＵＲＬでもって初期設定する。このＵＲＬはプロファイル・マネージャ・アプレットのＵＲＬから取り出される。ProfileManagementProperties_nonContextFloating オブジェクト P_NCF は、アドミニストレータのコンテキスト名及びコンテキスト・タイプ（ＵＳＥＲ）を得るためにプロファイル・マネージャ・サーブレット２１４にリクエスト９１８を送る。プロファイル・マネージャ・サーブレットはリクエスト９１８からアドミニストレータのＩＤを得る。ウェブ・ブラウザは、ProfileManagementProperties_nonContextFloating オブジェクト P_NCF によって送られた情報と共にアドミニストレータのＩＤ及びパスワードをメッセージで送る。ProfileManagementProperties_nonContextFloating オブジェクト P_NCF は、ステップ９１６におけるステップ２において、アプレットを走らせているアドミニストレータのコンテキストによって初期設定される。ステップ９１６のステップ３において、ProfileManagementProperties_nonContextFloating オブジェクト P_NCF は、プロファイル・マネージャの完全に修飾されたクラス名（即ち、profileManagerObject.getClass().getName()）をJava profileManagementObject オブジェクト（enablePersistence コールとして送られた）に要求することによって、そのプロファイル・マネージャ・アプレットに対する独特のキーを生成する。この独特のキーは、アドミニストレータのコンテキスト情報と結合されて、プロファイル・マネージャ・アプレットに対するアドミニストレータの特定のプリファレンス情報に対してデータベース２１２における独特のロケーションを指定するようにマップされる。
【００６６】
アドミニストレータに関して環境設定されるようにプロファイル・マネージャ・アプレットに対する修正されたプリファレンス情報を得るために、リクエスト９２２がプロファイル・マネージャ・サーブレット２１４に送られる。そのリクエスト９２２は、適切なプリファレンス情報を識別するための適切なコンテキスト名及びタイプ、並びにキー情報を含む。プロファイル・マネージャ・サーブレット２１４は ProfileManagementProperties_nonContextFloating オブジェクト P_NCF においてキャッシュされるリクエストされたプリファレンス情報でもって応答する（９２４）。プロファイル・マネージャは ProfileManagementProperties_nonContextFloating からそれのプリファレンス情報を読み出し、それに従ってそれ自身を更新する（即ち、それのバックグラウンド・カラーを、例えば、ブルーに設定する）。
【００６７】
オペレーションは第１０図に続く。ステップ１００２において、プロファイル・マネージャは、既存のユーザ、ユーザ・グループ、及びプロファイル・マネージャ・サーブレット２１４からのソフトウエアに関する情報をリクエストし、プロファイル・マネージャ環境設定ウインドウの左パネルにおいてツリーを形成する。例えば、アドミニストレータの左パネルに関して第１３図乃至第２４図を参照してほしい。この時点、即ち、ステップ１００４において、アドミニストレータは、左パネルのツリーから、ユーザ又はグループをクリックすることによって、環境設定するための所望のコンテキストを選択する。プロファイル・マネージャは、P_NCF.setContext（選択されたコンテキスト）をコールすることによって ProfileManagementProperties オブジェクトに対するコンテキストを設定する。すべてのシステム・ユーザのグループを参照する「User Groups」という選択されたコンテキストに関しては第１３図を参照し、「Development」というグループ・コンテキストが選択される場合には第１８図を参照し、或いは、「colleend」というユーザ・コンテキストが選択される場合には第２１図を参照してほしい。次に、ステップ１００６において、アドミニストレータは、サーバにおけるすべてのアプレットのリストから環境設定されるべきアプレットを選択する。アプレットを選択する例に関しては第１７図を参照してほしい。ステップ１００８において、アドミニストレータは、ラン／カスタマイズ・ボタンをクリックしてコンフィギュレーションのための選択されたアプレットを走らせる。このアプレットは、エンド・ユーザ・アプレットに対する別個のコンフィギュレーション・アプレットであってもよく、或いはエンド・ユーザ・アプレット自体であってもよい。ステップ１００９及び１０１１において、その選択されたアプレットがサーバからリクエストされ、ロードされる。ステップ１０１０において、コンフィギュレーション・アプレット・オブジェクトが作成され、それのProfileManagementProperties オブジェクトＰを実行及び生成し始める。
【００６８】
アプレットがエンド・ユーザ・アプレットに対する別個のコンフィギュレーション・アプレットである場合、ステップ１０１２において、そのアプレットは p.enablePersistence（configAppletObject,fullyQualifiedClassNameOfAppletBeingConfigured）をコールする。一方、そのアプレットがユーザ・アプレットである場合、コールは p.enablePersistence（endUserAppletObject）であるであろう。これは、それが他のアプレットに対するプリファレンス情報とは対照的にそれ自身のプリファレンス情報を環境設定することを望んでいるためである。現在のコンテキストは、それがアドミニストレータの ProfileManagementProperties_nonContextFloating オブジェクト PM_NCP を介してアドミニストレータによって前に設定されていたので、ProfileManagementProperties オブジェクト P によって既に知られている。プロファイル・マネージャ・サーブレット２１４のロケーションは、前に、enablePersistence がプロファイル・マネージャ上に ProfileManagementProperties_nonContextFloating オブジェクト PM_NCF をコールされた時に生成された。コンフィギュレーション・アプレットの場合、そのアプレットに対する独特キーが生成される必要はない。これは、それが enablePersistence コールにおいて ProfileManagementProperties オブジェクト P に、そのコンフィギュレーション・アプレットによってパスされるためである。
【００６９】
ステップ１０１４において、コンフィギュレーション・アプレットがそれの ProfileManagementProperties オブジェクト P と共にそれ自身をコンテキスト変更リスナとして登録する。前述のように、これは、そのアプレットが新しいコンテキストに対するプリファレンス情報をロードできるように及び新しいコンフィギュレーション情報を反映すべくそれのグラフィカル・ユーザ・インターフェースを更新できるように、アプレットが終了しそして新しいコンテキストにおいて再立ち上げされることを必要とすることなく、アドミニストレータがコンテキスト変更を行うかどうかを、そのアプレットの ProfileManagementProperties オブジェクト P がそのアプレットに知らせることを可能にする。
【００７０】
オペレーションは第１１図に続く。ステップ１１０４において、コンフィギュレーション・アプレットは、環境設定されるアプレットに対する現在のコンテキストからプリファレンスをロードするように ProfileManagementProperties オブジェクト P に命じる。アドミニストレータによって前に選択されたコンテキストに対して調整されたプリファレンス情報を得るために、リクエスト１１０５がプロファイル・マネージャ・サーブレット２１４に送られる。そのリクエスト１１０５は、適切なコンテキスト名（アドミニストレータが選択したコンテキスト）及びコンテキスト・タイプ（適宜、USER、USER_GROUP、又は ALL_USERS_GROUP）並びにキー情報を含み、適切なプリファレンス情報のロケーションを指定する。ステップ１１０６において、プロファイル・マネージャ・サーブレット２１４がそのリクエストされたプリファレンス情報でもって応答する。なお、その情報は ProfileManagementProperties オブジェクト P においてキャッシュされる。コンフィギュレーション・アプレットは ProfileManagementProperties オブジェクト P からプリファレンスを取得し、それに従って、それのグラフィカル・ユーザ・インターフェースを更新する。
【００７１】
ステップ１１０７において、アドミニストレータはアプレットを環境設定し、例えば、そのアプレットにより与えられる保存（save）ボタンをクリックすることによって、その修正されたプリファレンスを保存する。このオペレーションの結果、コンフィギュレーション・アプレットは、それの ProfileManagementProperties オブジェクト P における save()メソッドをコールする。ProfileManagementProperties オブジェクト P は、プリファレンス及び環境設定されるアプレットに対する独特のキー、並びに現在のコンテキストを指定する情報をプロファイル・マネージャ・サーブレット２１４に送る。そのプロファイル・マネージャ・サーブレット２１４は、コンテキスト及びキーによって指定されたデータベース２１２におけるロケーションにそのプリファレンス情報を記憶する。
【００７２】
ステップ１１０８は、アドミニストレータ・アプレットがまだ走っている間に、アドミニストレータがコンテキストを変更するという例である。アドミニストレータは、ユーザ又はユーザ・グループをクリックすることによって新しいコンテキストを選択する（第１８図を、アドミニストレータの左スクリーン・パネルにおける新しいコンテキストの例として参照してほしい）。コンテキスト変更の結果、プロファイル・マネージャ５０６は、P_NCF.setContext（選択された新しいコンテキスト）をコールすることによってセット・コンテキスト・メッセージを ProfileManagementProperties オブジェクトＰ（５１０）に送る。一方、P_NCF.setContext は、オブジェクトＰに、その再ロードされたプロパティＡＰＩ５１５を介してそのコンテキスト変更をイベント・リスナ５１２へ通知させる。これはステップ１１１０において生じる。ステップ１１１２において、イベント・リスナ５１２は、新しいコンテキストに対するプリファレンスを検索するように load() コールを遂行し、ステップ１１１８において、オブジェクトＰは新しいプリファレンスでもって更新される。今や、アドミニストレータは、新しいコンテキストに対する新しいプリファレンスの修正が望ましい場合にはそれを修正し、そしてそれらの保存が望ましい場合にはそれを保存し、しかる後、新しいコンテキスト変更を進行させる必要がある場合にはそれを進行させることができる。
【００７３】
残りの第１２図乃至第２４図は、プロファイル・マネージャ２０６の一部分を走らせている時の、アドミニストレータのワークステーションの実際のスクリーン・スナップ写真を示す。
【００７４】
第１２図には、メイン・コンフィギュレーション・ウインドウ１２００が示される。ウインドウの左側におけるツリー・ビュー・パネル１２０２はサーバにおいて利用可能ないくつかのサービスの１つとしてプロファイル・マネージメント（Profile management）１２０４を示す。第１２図に示されるように、このアイテム１２０４が選択される時、そのメイン・ウインドウの右側パネル１２０５はプロファイル・マネージメント・サービスに対する歓迎メッセージを表示する。左側パネルにおけるアイテムの下にサブ・アイテムが存在する場合、それの出現を制御するために、参照番号１２０８のようなエクスパンド（expand）／コントラクト（contract）アイコンが使用される。アイコン１２０８における "＋" は「エクスパンド・アイコン」と呼ばれ、その「プロファイル・マネージメント」の下にサブ・アイテムが存在することを表す。アドミニストレータはエクスパンド・アイコンをクリックすることによってこれらのサブ・アイテムを表示することができ、その後、そのエクスパンド・アイコンは「コントラクト・アイコン」"−" になる。
【００７５】
第１３図は、第１２図における「プロファイル・マネージメント」アイテム１２０８の展開を示す。その結果、第１３図における３つのデフォルト・サブ・アイテム、即ち、「アプレット（Applets）」１３００，「ユーザ・グループ（User Groups）」１３０２、及び「ユーザ（Users）」１３０４の表示が生じる。これらのアイテムも展開され得ることをエクスパンド・アイコンが表している。「アプレット」１３００は、アドミニストレータがサーバ２０２における使用可能なユーザ・アプレットを定義することを可能にし、「ユーザ・グループ」１３０２は、アドミニストレータが第３図のユーザ・グループ・ツリーを作成してそれを移植すること及びグループ・プリファレンスを設定することを可能にする。「ユーザ」１３０４は、アドミニストレータが新しいユーザを作成してそれらのプリファレンスを設定するか又は既存のユーザに対するプリファレンスを変更することを可能にする。第１３図の例では、「アプレット」１３００が選択される。このアイテムが選択される時、ウインドウの右側におけるパネル１３０５が、既にそのシステムに対して定義されているユーザ・アプレットのリスト１３０６を表示する。参照番号１３０６において選択されたアプリケーションのアトリビュートが参照番号１３０８で示される。アドミニストレータは、１３０６において＜NEW＞を選択すること及び１３０８においてリクエストされた名前及びロケーション情報を入れることによって新しいアプレットを定義する。既存のアプレット「データベース・エクスプローラ（Database Explorer）」は１３０６では選択された状態で示される。１３０８において、「アプレット名（Applet name）」フィールドはこのアプレット名を表示する。「ＵＲＬ（ユニバーサル・リソース・ロケータ"Universal Resource Locator"）」フィールドは、サーバ２０２におけるこのアプレットのイントラネット又はインターネット・ウェブ・アドレスを表示する。フィールド「html ファイルの完全なパス（Complete path of html file）」は、サーバ２０２のディスク・ディレクトリ構造におけるアプレットのディレクトリ・パス及びファイル名を表示する。フィールド「完全に修飾されたクラス名（Fully qualified class name）」は、アプレットの完全に修飾されたクラス名を表示する。フィールド「アイコンＵＲＬ（Icon URL）」は、ユーザ・デスクトップにおけるアプレットのためのアイコンを発生するために使用されるイメージ・ファイルのウェブ・アドレスを表示する。残りのフィールドは、呼び出し時にソフトウエアによって要求されることのある任意選択的な情報のためのものである。コマンド・ボタン「ファイルからアプレット・リストをインポートする（Import Applet List from File）」１３１０は、アドミニストレータが既存のテキスト・ファイルから既存のリスト１３０６にアプレットの定義を付加することを可能にする。コマンド・ボタン１３１０がクリックされる時、第１４図に示されたウインドウがポップアップし、アドミニストレータが付加されるべきアプレット定義を含むテキスト・ファイルのパス及びファイル名を入れることを可能にする。すべての保留の変更を保存するために、アドミニストレータはファイル（File）１３１２を、しかる後、「保存（Save）」（図示されてない）をクリックする。
【００７６】
左側パネルでは、ユーザ・グループ（User Group）アイテム１３０２が第３図の全ユーザ（AllUsers）グループに対応する。（本願では、「ユーザ・グループ」及び「全ユーザ」は相互交換可能に使用される）。第１５図は、「ユーザ・グループ」アイテム１３０２が選択される時のアドミニストレータ・ステーションの右側パネルを示す。第１５図には、その右側に、３つのタブ、即ち、メンバ・タブ（Members）１５１４、サブグループ・タブ（Subgroups）１５１６、及びアプレット・パーミッション・タブ（Applet Permissions）１５１８を含むノートブック・パネルが示される。第１５図では、メンバ・タブが選択される。メンバー・パネルは、そのシステムに対して定義されているすべてのメンバのログ・オン識別のリスト１５２０を含む。新しいユーザ（現在選択されたグループ・コンテキスト「ユーザ・グループ」までメンバシップを進めるであろう）を作成するために、アドミニストレータはリスト１５２０から＜NEW＞を選択し、適切な情報をそのリストの右側のエントリ・フィールドに入れ、しかる後、作成（Create）ボタン１５２２をクリックする。既存のメンバがリスト１５２０から選択される時、そのユーザに対して前に保存されたアトリビュートが１５２４において表示される。これらのアトリビュートは選択されたメンバのフル・ネーム、そのメンバのシステムＩＤ、パスワード、任意の所望のコメントを含む。ＩＤを除くアトリビュートは編集可能であり、修正（Modify）ボタン１５２５をクリックすることによってコミットされた（しかし、保存されない）変更又はユーザは削除（Delete）ボタン１５２６をクリックすることによって完全にシステムから除去可能である。如何なる保留の変更も、リスト１５２０におけるエントリを選択すること及び取り消し（Undo）ボタン１５２８をクリックすることによって除去可能である。
【００７７】
第１６図は、第１５図のサブグループ・タブ（Subgroup）１５１６が選択された時に表示されるアドミニストレータの右側パネルを示す。サブグループ・リスト１６２０は、この例では「ユーザ・グループ（User Groups）」である、左側パネルにおいて選択されたアイテムのサブグループである既存のグループを示す。従って、リスト１６２０は、「全ユーザ（AllUsers）」グループのすべての当面のサブグループを示す。左側パネルには、「ユーザ・グループ（User Groups）」が展開されている。リスト１６２０に示されたサブグループは、左側パネルにおける「ユーザ・グループ」の下の展開されたアイテムでもある。リスト１６２０では、ステータス（Status）フィールドは「削除（! delete）」、「修正（! modify）」、「作成（! create）」のような各サブグループの現在のステータスを示す。リスト１６２０における空白のステータス・フィールドは、そのサブグループが存在すること及び保存されるべき保留状態のアクションがないことを表す。「!」の記号は、そのステータスが（未だ保存されてない）保留状態であることを表す。リスト１６２０における選択されたサブグループに対するアトリビュートが１６２２において現れる。これらのアトリビュートはサブグループ名及びそのサブグループに関する所望のコメントである。新しいサブグループを作成するためには、アドミニストレータはリスト１６２０から <NEW> を選択し、１６２２においてサブグループ名及び所望のコメントを入れ、「作成（Create）」ボタン１６２８をクリックする。そこで、リスト１６２０には、「! create <subgroup name>」のエントリが保留のアクションとして現れる。すべての保留の変更を保存するために、アドミニストレータは最上部のメニュー・バーにおけるファイル（File）ボタンをクリックし、しかる後、保存（Save）ボタン（図示されてない）をクリックする。
【００７８】
第１７図は、アプレット・パーミッション・タブ（Applet Permission）１５１８が選択された時に表示される右パネルを示す。リスト１７２０は、そのシステムに対して定義されているすべてのアプレットのすべての名前及び左パネルにおいて選択されたグループ又はサブグループに対する各アプレットに割り当てられたパーミッション・ステータス（アクセスを許可する（permit）又は拒否する（deny））を示す。前述の他のノートブック・ページの場合のように、感嘆符（！）は、示されたステータスが保存を保留している変更であることを表す。第１７図では、第３図に示された「全ユーザ（AllUsers）」グループに対応する、左パネルに示されたツリーにおけるグループ「ユーザ・グループ（User Groups）」が選択される。そのシステムのすべてのユーザが「ユーザ・グループ」というグループにおけるメンバシップを有するので、リスト１７２０は、そのシステムに対して定義された各アプレットに関するすべてのシステム・ユーザに対するグローバル・デフォルト・パーミッションを示す。例えば、アプレット「データベース・エクスプローラ（Database Explorer）」は「全ユーザ（AllUsers）」グループに対して「許可（permit）」（アクセスが許可されることを意味する）であり、同様に、アプレットＴＦＴＰに対する全ユーザに関するデフォルト・パーミッション・ステータスは「拒否（deny）」（アクセスが拒否される）である。アドミニストレータは、リスト１７２０におけるアプレットのパーミッション・ステータスを選択すること及び「グループ・アクセスを許可する（Permit group access）」ボタン１７３０又は「グループ・アクセスを拒否する（Deny group access）」１７３２をクリックすることによってパーミッション・ステータスを変更することができる。更に、選択されたコンテキストに対するアプレットのパーミッション・ステータスに関係なく、アドミニストレータは、１７２０からアプレットを選択し、「ラン／カストマイズ（Run/Customize）」ボタン１７３４をクリックしてその選択されたコンテキストに属するユーザ・アプレットを実行させることができる。そこで、現在のコンテキストに対するノートブックを前に示しているパネル領域が実行中のユーザ・アプレットによって占有される。そのユーザ・アプレットが他のソフトウエアに対するコンフィギュレーション・アプレットであるということが生じる場合、アドミニストレータは、（この機能に対して与えられたコンフィギュレーション・アプレット独特のファシリティを通して）ソフトウエア・プリファレンスを保存することができる。その後、それは、選択されたコンテキストに対するそのソフトウエアのデフォルト・プリファレンスとして保存されるであろう。アプレットがエンド・ユーザ・アプレットである場合、エンド・ユーザ・アプレットが別のソフトウエア・ピースに対するプリファレンスではなくそれ自身のプリファレンスをロード及び保存することを除けば、それらの機能は同じである。
【００７９】
第１８図は、「ユーザ・グループ（User Groups）」の下のアドミニストレータの左パネル・サブグループ・ツリーの完全な展開を示す。「ユーザ・グループ」のすぐ下には、２つのサブグループ、即ち、除去することができないデフォルト・サブグループである「アドミニストレータ（Administrators）」及びアドミニストレータによって定義されたサブグループである「IBM」がある。「IBM」サブグループも展開され、３つのサブグループ「ハードウエア（Hardware）」、「サービス（Services）」、及び「ソフトウエア（Software）」を含む。「ソフトウエア」サブグループは展開されており、「開発（Development）」と呼ばれる少なくとも１つのサブグループを含む。「開発」サブグループは「NCoD」と呼ばれる少なくとも１つのサブグループを含む。サブグループ「NCoD」は、子サブグループを持たない ConfigFW のような数多くのサブグループを含む。更に、この例では、サブグループ「開発」が展開ツリーにおいて選択される。サブグループ「開発」はツリー階層（「全ユーザ」グループ）のトップにはないので、右側パネルに示されたノートブックは、「ユーザ・グループ」が選択された時の第１５図におけるノートブックとはわずかに異なっている。それは、すべてのユーザが「ユーザ・グループ」のメンバであるので、すべてのユーザが自動的には「開発」のメンバにならないためである。リスト１８２０は、すべてのシステム・メンバのログ・オン・システムＩＤを表示する。リスト１８２０における各ユーザＩＤのそばのステータスは、ユーザが「開発」サブグループにおけるメンバシップを持っているかどうかを示す。「イエス（yes）」というステータスは、ユーザが「開発」サブグループのメンバであることを表す。「ノー（no）」は、ユーザが「開発」サブグループのメンバではないことを表し、「継承（inherited ）」は、ユーザがツリーにおける更に下の開発のサブグループのうちの少なくとも１つに属することによって「開発」グループにおけるメンバシップを継承することを表す。サブグループに対するユーザのメンバシップ・ステータスは、リスト１８２０におけるユーザを選択することによって、及び「グループへの追加（Add to Group）」ボタン１８３６又は「グループからの排除（Remove from group）」ボタン１８３８をクリックすることによってアドミニストレータにより修正される。アドミニストレータが新しいシステム・ユーザを作成すること又は既存のメンバを修正又は削除することを望む場合、アドミニストレータは、「ユーザを作成／修正／削除する（Create/Modify/Delete Users）」ボタン１８４０をクリックする。このアクションは、第１９図に示されたノートブック・ページを生じさせる。第１９図の右パネルは第１５図のそれと同じであり、アドミニストレータがリスト１９２０における <NEW> を選択すること、しかる後、「作成（Create）」ボタンをクリックすることによって新しいシステム・ユーザを作成することを可能にする。同様に、アドミニストレータは、リスト１９２０において適正なユーザを選択すること及び適正なボタン「修正（Modify）」又は「削除（Delete）」を選択することによって既存のシステム・ユーザを修正又は削除することができる。任意のサブグループ・コンテキスト（例えば、「開発」）において作成されたユーザは、「ユーザ・グループ」における必要なメンバシップを与えるのみならず、選択されたサブグループの自動的に作られたメンバである。システム・ユーザ・リストに対する変更は、右パネルの最上部のメニュー・バーにおける「ファイル（File）」をクリックすること、しかる後、「保存（Save）」（図示されてない）をクリックすることによって保存される。
【００８０】
第２０図は、第１９図に示されたグループ及びサブグループ・ルートを介さずに、編集のためにシステム・ユーザ・リストに達するための直接的な方法を示す。第２０図に達するためには、アドミニストレータは、例えば、第１３図の左パネルにおける「ユーザ（Users）」１３０４を選択する。そこで、第２０図に示された右側パネルにおいて、既に説明したように、アドミニストレータは、グループ又はサブグループのテキストになくても、新しいユーザを作成すること及び既存のユーザを修正及び削除することができる。
【００８１】
第２１図では、「colleend」というＩＤを持ったユーザに対応する情報をアドミニストレータが直接に操作することを望んでいる。これを行うために、アドミニストレータは、例えば、第２１図の左側パネルにおける「ユーザ（Users）」を展開し、しかる後、図示のように「colleend」を選択する。そこで、colleend のシステム情報に専用の右側パネルが現れる。右側パネルは３つのタブを含む。第１のタブである「ユーザ情報（User Information）」はデフォルトによって選択される。このタブでは、アドミニストレータは colleend に関連する名前、ＩＤ、パスワード、及びコメントを修正することができる。
【００８２】
第２２図は、アドミニストレータが第２タブである「グループ・メンバシップ（Group Memberships）」を選択する時の右側パネルを示す。リスト２２２０は、colleend がメンバとなっているすべてのサブグループを示す。それらのサブグループは、このリストでは、colleend に対するサブグループ優先順位の順序で示される。アドミニストレータは、１つのサブグループを選択すること及びその選択されたサブグループを望みどおりにリストの上方又は下方に移動させるためにリスト２２２０の右の上下の矢印を使用することによって、colleend のサブグループ優先順位を変更することができる。アドミニストレータが第２２図における「グループ・メンバシップを追加／削除する（Add/Remove Group Memberships）」ボタン２２４２をクリックする場合、右側パネルは第２３図の内容を示す。第２３図の右パネルは、colleend がメンバであるサブグループをアドミニストレータが修正することを可能にする。アドミニストレータは、所望のサブグループに対応した適正なボックスをクリックすることによってこれを行う。そのボックスがクリア状態である（colleend が現時点ではメンバではないことを意味する）場合、colleend をそのサブグループに含ませるために、チェック・マークがそのボックスに付加される。それとは逆に、サブグループ・ボックスが既にチェックされている場合、そのボックスをクリックすることはチェック・マークをクリアし、そのサブグループから colleend を除去する。
【００８３】
第２４図は、第２２図のアプレット・パーミッション・タブ（Applet Permissions）がアドミニストレータによって選択された時の右側パネルを示す。このパネルでは、リスト２４２０は、そのシステムにおいて定義されたすべてのアプレットを表示する。アドミニストレータは、リスト２４２０におけるアプレットを選択すること、しかる後、「ユーザ・アクセスを許可する（Permit user access）」ボタン２４３０をクリックすることによって colleend によるアプレットへのアクセスを許可することができる。或いは、「ユーザ・アクセスを拒否する（Deny user access）」ボタン２４３２をクリックすることによって colleend によるアクセスは拒否される。アドミニストレータは、「ラン／カストマイズ（Run/Customize）」ボタン２４３４をクリックすることによって colleend のコンテキストにおけるアプレットを立ち上げることもできる。これが行われる時、リスト２４２０における選択されたアプレットが右側パネルにおいて立ち上げられる。そこで、アドミニストレータは、アプレットが許容するいずれのプリファレンスも修正することができ、そのアプレットによって与えられた方法でそれらのプリファレンスを保存することもできる。本願における代表的なシナリオは、アドミニストレータがコンフィギュレーション・アプレットを立ち上げ、しかる後、種々のプリファレンス・フィールドにおいてそれを満足させることである。しかし、別のコンフィギュレーションがユーザ・アプレットに対して与えられない場合、アドミニストレータは、ユーザのコンテキストにおいてユーザ・アプレットを立ち上げ、そのユーザ・アプレットからプリファレンスを設定することができる。本願における代表的なシナリオは、アドミニストレータがグループ又はユーザ・コンテキストを選択し、しかる後、前述のようにユーザ・アプレットを立ち上げることである。そこで、アドミニストレータは、一般には、オプション・メニューからプリファレンスを修正し、ユーザ・アプレットによって与えられた任意の方法でそれらを保存することができる。例えば、一般には、オプションの対話が終了した時にユーザ・プリファレンスが保存されるか、又はユーザ・アプレットがプリファレンスを保存する他の方法を提供してもよい。如何なる場合も、アドミニストレータはこの例においては colleend というコンテキストにおいてアプレットを走らせているので、ユーザ・アプレットを介してアドミニストレータにより設定されたプリファレンスは、colleend が、アプレットを走らせることによって自分で直接にそれらを入れたかのようにサーバにおいて保存される。
【００８４】
ユーザ・アプレットに関連するいくつかのプリファレンスをユーザが修正することができるというシナリオは図面に示されていない。例えば、ユーザ・アプレットは、ユーザがウインドウのバックグラウンド・カラー又はフォント及びフォント・サイズを選択することを可能にし得るので、各システム・ユーザは、ユーザ・アプレットがユーザのデスクトップ上で実行される時、アプレットを或る範囲まで個性化することができる。この場合、ユーザが修正したプリファレンスは、アドミニストレータがユーザ・アプレットを走らせる時と同じ方法で保存される。しかし、１つの相違点は、アドミニストレータがグループ・コンテキストにプリファレンスを設定するためにユーザ・アプレットを走らせることができ、一方、ユーザはそれらの個々のコンテキストに対するプリファレンスにのみ影響を与えることができるということである。
【図面の簡単な説明】
【図１】本発明を実施し得るアドミニストレータのステーションを含む例示的なネットワーク及びユーザ・ステーションを示す。
【図２】サーバとコミュニケートするアドミニストレータのステーション並びに中央のプロファイル・マネージメント及びプリファレンス管理を行うためのアドミニストレータのステーション及びサーバのコンポーネントの例示的なブロック図を示す。
【図３】システムのユーザ・グループ及びユーザの１つの例示的な階層編成を示す。その例示的な階層編成は個々の端末及び端末グループを含んでもよい。しかし、簡単にするために、これらは省略されている。
【図４】ユーザ及びそのユーザによって実行される特定のアプリケーションに適用する第３図の階層編成から一組のプリファレンスを決定するために使用される個々のユーザ及びグループ優先順位に関する１つの例示的リストを示す。
【図５】第２図のアドミニストレータのステーション及びサーバの更に詳細な図を示す。
【図６】ユーザ・アプリケーションとそのアプリケーション及び他のコンポーネント（アプリケーションの実行時にユーザ・プリファレンスをユーザの端末として確立するように共同する）の間のＡＰＩとを含むユーザの端末におけるソフトウエア・オブジェクトの例示的な図を示す。
【図７】ユーザ・ログオンのための及びユーザ端末においてデスクトップ・プリファレンスを含むユーザのデスクトップを最初に確立するための、ユーザの端末及びサーバの両方における例示的なオペレーションを示す。
【図８】ユーザ・ログオンのための及びユーザ端末においてデスクトップ・プリファレンスを含むユーザのデスクトップを最初に確立するための、ユーザの端末及びサーバの両方における例示的なオペレーションを示す。
【図９】アドミニストレータのユーザ・ログオン、アドミニストレータのデスクトップの設定のための、並びに、例えば、アプリケーションの選択及び環境設定のためのコンテキストの選択ための、アドミニストレータの端末及びサーバの両方における例示的なオペレーションを示す。その例は、環境設定時のコンテキストの変化、ユーザのデスクトップ、及びその結果生じるオペレーションも示す。
【図１０】アドミニストレータのユーザ・ログオン、アドミニストレータのデスクトップの設定のための、並びに、例えば、アプリケーションの選択及び環境設定のためのコンテキストの選択ための、アドミニストレータの端末及びサーバの両方における例示的なオペレーションを示す。その例は、環境設定時のコンテキストの変化、ユーザのデスクトップ、及びその結果生じるオペレーションも示す。
【図１１】アドミニストレータのユーザ・ログオン、アドミニストレータのデスクトップの設定のための、並びに、例えば、アプリケーションの選択及び環境設定のためのコンテキストの選択ための、アドミニストレータの端末及びサーバの両方における例示的なオペレーションを示す。その例は、環境設定時のコンテキストの変化、ユーザのデスクトップ、及びその結果生じるオペレーションも示す。
【図１２】第３図がその一例を表す階層の確立、ユーザの作成及び削除、アプリケーションに対するアプリケーション・プリファレンスの確立、及びプリファレンス確立時のコンテキストの変化を含むアプリケーション管理の種々のフェーズにおける種々の実際のアドミニストレータスクリーンのスナップショットを示す。
【図１３】第３図がその一例を表す階層の確立、ユーザの作成及び削除、アプリケーションに対するアプリケーション・プリファレンスの確立、及びプリファレンス確立時のコンテキストの変化を含むアプリケーション管理の種々のフェーズにおける種々の実際のアドミニストレータスクリーンのスナップショットを示す。
【図１４】第３図がその一例を表す階層の確立、ユーザの作成及び削除、アプリケーションに対するアプリケーション・プリファレンスの確立、及びプリファレンス確立時のコンテキストの変化を含むアプリケーション管理の種々のフェーズにおける種々の実際のアドミニストレータスクリーンのスナップショットを示す。
【図１５】第３図がその一例を表す階層の確立、ユーザの作成及び削除、アプリケーションに対するアプリケーション・プリファレンスの確立、及びプリファレンス確立時のコンテキストの変化を含むアプリケーション管理の種々のフェーズにおける種々の実際のアドミニストレータスクリーンのスナップショットを示す。
【図１６】第３図がその一例を表す階層の確立、ユーザの作成及び削除、アプリケーションに対するアプリケーション・プリファレンスの確立、及びプリファレンス確立時のコンテキストの変化を含むアプリケーション管理の種々のフェーズにおける種々の実際のアドミニストレータスクリーンのスナップショットを示す。
【図１７】第３図がその一例を表す階層の確立、ユーザの作成及び削除、アプリケーションに対するアプリケーション・プリファレンスの確立、及びプリファレンス確立時のコンテキストの変化を含むアプリケーション管理の種々のフェーズにおける種々の実際のアドミニストレータスクリーンのスナップショットを示す。
【図１８】第３図がその一例を表す階層の確立、ユーザの作成及び削除、アプリケーションに対するアプリケーション・プリファレンスの確立、及びプリファレンス確立時のコンテキストの変化を含むアプリケーション管理の種々のフェーズにおける種々の実際のアドミニストレータスクリーンのスナップショットを示す。
【図１９】第３図がその一例を表す階層の確立、ユーザの作成及び削除、アプリケーションに対するアプリケーション・プリファレンスの確立、及びプリファレンス確立時のコンテキストの変化を含むアプリケーション管理の種々のフェーズにおける種々の実際のアドミニストレータスクリーンのスナップショットを示す。
【図２０】第３図がその一例を表す階層の確立、ユーザの作成及び削除、アプリケーションに対するアプリケーション・プリファレンスの確立、及びプリファレンス確立時のコンテキストの変化を含むアプリケーション管理の種々のフェーズにおける種々の実際のアドミニストレータスクリーンのスナップショットを示す。
【図２１】第３図がその一例を表す階層の確立、ユーザの作成及び削除、アプリケーションに対するアプリケーション・プリファレンスの確立、及びプリファレンス確立時のコンテキストの変化を含むアプリケーション管理の種々のフェーズにおける種々の実際のアドミニストレータスクリーンのスナップショットを示す。
【図２２】第３図がその一例を表す階層の確立、ユーザの作成及び削除、アプリケーションに対するアプリケーション・プリファレンスの確立、及びプリファレンス確立時のコンテキストの変化を含むアプリケーション管理の種々のフェーズにおける種々の実際のアドミニストレータスクリーンのスナップショットを示す。
【図２３】第３図がその一例を表す階層の確立、ユーザの作成及び削除、アプリケーションに対するアプリケーション・プリファレンスの確立、及びプリファレンス確立時のコンテキストの変化を含むアプリケーション管理の種々のフェーズにおける種々の実際のアドミニストレータスクリーンのスナップショットを示す。
【図２４】第３図がその一例を表す階層の確立、ユーザの作成及び削除、アプリケーションに対するアプリケーション・プリファレンスの確立、及びプリファレンス確立時のコンテキストの変化を含むアプリケーション管理の種々のフェーズにおける種々の実際のアドミニストレータスクリーンのスナップショットを示す。

Claims

サーバ及び複数のユーザ・ステーションが相互接続され、ユーザ・ステーションにダウンロードするための複数のユーザ・アプリケーションがサーバに記憶された、ネットワーク・システムにおいて、ユーザ・ステーションで実行されるアプリケーションに対するユーザ・コンフィギュレーション・プリファレンスを管理する方法であって、
サーバのデータ記憶装置に記憶された、すべてのシステム・ユーザを含む全ユーザ・グループ・ノードとそれぞれ選択されたユーザを含む複数の下位グループ・ノードとからなるツリー階層構造のデータに基づいて、サーバのコンピュータにより、システムのすべてのユーザを前記ツリー階層構造に表すステップであって、前記選択されたユーザは、前記下位グループ・ノードによって表されるグループに属し、それぞれのノードのデータは前記システムで使用可能な選択されたアプリケーションに対するコンフィギュレーション・プリファレンスを含んでいる、前記ユーザをツリー階層構造に表すステップと、
複数のグループのメンバである各ユーザに対して、サーバのデータ記憶装置に記憶された前記ツリー階層構造に表されたユーザの順位のデータに基づいて、サーバのコンピュータにより、グループの優先順位を割り当てるステップと、
選択されたアプリケーションの実行をリクエストする任意の所定のユーザに関して、サーバのデータ記憶装置に記憶された前記割り当てられた優先順位のデータに基づいて、サーバのコンピュータにより、該ユーザに対するグループの優先順位を決定するステップと、
（ａ）サーバのコンピュータにより、前記選択されたアプリケーションに対する一組のプリファレンスを取り出し得る第１グループを、サーバのデータ記憶装置に記憶されたグループの優先順位リストから決定すること、
（ｂ）サーバのコンピュータにより、前記全ユーザ・グループから前記第１グループまで前記ツリーを、サーバのデータ記憶装置に記憶されたデータに基づいて、トラバースすることによって前記プリファレンスを前記選択されたアプリケーションに対するセットに合体させること、
（ｃ）サーバのコンピュータにより、前記選択されたアプリケーションに対する各ノードにおいて指定されたプリファレンスを、サーバのデータ記憶装置に記憶されたデータに基づいて、収集すること、及び
（ｄ）サーバのコンピュータにより、サーバのデータ記憶装置に記憶されたデータに基づき、ノードがトラバースされた時のプリファレンスを、前記選択されたアプリケーションに対する当該ノードにおいて指定された前記収集したプリファレンスでもって、修正すること、
によって前記ツリーから一組のコンフィギュレーション・プリファレンスを形成するステップと、
を含む前記の方法。
サーバ及び複数のユーザ・ステーションが相互接続され、ユーザ・ステーションにダウンロードするための複数のユーザ・アプリケーションがサーバに記憶された、ネットワーク・システムにおいて、ユーザ・ステーションで実行されるアプリケーションに対するユーザ・コンフィギュレーション・プリファレンスを管理するために、サーバのコンピュータに、
サーバのデータ記憶装置に記憶された、すべてのシステム・ユーザを含む全ユーザ・グループ・ノードとそれぞれ選択されたユーザを含む複数の下位グループ・ノードとからなるツリー階層構造のデータに基づいて、システムのすべてのユーザを前記ツリー階層構造に表すステップであって、前記選択されたユーザは、前記下位グループ・ノードによって表されるグループに属し、それぞれのノードのデータは前記システムで使用可能な選択されたアプリケーションに対するコンフィギュレーション・プリファレンスを含んでいる、前記ユーザをツリー階層構造に表すステップと、
複数のグループのメンバである各ユーザに対して、サーバのデータ記憶装置に記憶された前記ツリー階層構造に表されたユーザの順位のデータに基づいて、グループの優先順位を割り当てるステップと、
選択されたアプリケーションの実行をリクエストする任意の所定のユーザに関して、サーバのデータ記憶装置に記憶された前記割り当てられた優先順位のデータに基づいて、該ユーザに対するグループの優先順位を決定するステップと、
（ａ）前記選択されたアプリケーションに対する一組のプリファレンスを取り出し得る第１グループを、サーバのデータ記憶装置に記憶されたグループの優先順位リストから決定すること、
（ｂ）前記全ユーザ・グループから前記第１グループまで前記ツリーを、サーバのデータ記憶装置に記憶されたデータに基づいて、トラバースすることにより、前記プリファレンスを前記選択されたアプリケーションに対するセットに合体させること、
（ｃ）前記選択されたアプリケーションに対する各ノードにおいて指定されたプリファレンスを、サーバのデータ記憶装置に記憶されたデータに基づいて、収集すること、及び
（ｄ）サーバのデータ記憶装置に記憶されたデータに基づき、ノードがトラバースされた時のプリファレンスを、前記選択されたアプリケーションに対する当該ノードにおいて指定された前記収集したプリファレンスでもって、修正すること、
によって前記ツリーから一組のコンフィギュレーション・プリファレンスを形成するステップと、
を実行させるためのプログラムを記録したコンピュータ読み取り可能な記憶媒体。