(57)【特許請求の範囲】
【請求項１】
サーバと、複数のユーザ・ステーションを相互接続するネットワークを含む、ネットワークシステムで、ユーザ・ステーションにおいて実行されるアプリケーションの構成プリファレンスを管理する方法において、
前記ユーザ・ステーションから選択される管理者のステーションにおいて、プロファイル・マネージャを実行させるためのステップ（９１２）と、
前記管理者のステーションにおいて、ユーザ・アプリケーションを実行させ、ユーザ・グループまたはユーザの関係を表示するツリーを参照して構成される前記ユーザ・アプリケーションについての構成プリファレンスの選択を前記プロファイル・マネージャが受け付けるステップ（１００４）と、
前記管理者のステーションが、前記選択された前記ユーザ・アプリケーションについての構成プリファレンスを選択させるための構成アプレットを実行させるステップ（１００６）と、
前記選択した前記ユーザ・アプリケーションについての前記構成プリファレンスを、前記サーバに記憶させるステップ（１１０７）と、
ユーザが前記ユーザ・アプリケーションの実行をリクエストする場合、前記構成プリファレンスに対応するアプレット・リストを照合し（８１０）、前記ユーザ・アプリケーションを提供するためのユーザ・アプレットを実行させるアイコンをデスクトップ上に表示させ（８１２）、前記構成プリファレンスに対応した前記ユーザ・アプレットを、前記サーバから当該ユーザのワークステーションにダウンロードするステップと、を含む方法。
【請求項２】
サーバと、複数のユーザ・ステーションを相互接続するネットワークを含む、ネットワークシステムで、ユーザ・ステーションにおいて実行されるアプリケーションの構成プリファレンスを管理するシステムにおいて、管理者のステーションが、
前記ユーザ・ステーションから選択される管理者のステーションにおいて、プロファイル・マネージャを実行する手段と、
前記管理者のステーションにおいて、ユーザ・アプリケーションを実行させ、ユーザ・グループまたはユーザの関係を表示するツリーを参照して構成される前記ユーザ・アプリケーションについての構成プリファレンスの選択を前記プロファイル・マネージャが受け付ける手段と、
前記管理者のステーションにおいて前記選択された前記ユーザ・アプリケーションについての構成プリファレンスを選択させるための構成アプレットを実行させる手段と、
前記選択した前記ユーザ・アプリケーションについての前記構成プリファレンスを、前記サーバに記憶させる手段とを含み、
前記ユーザ・ステーションからユーザが前記ユーザ・アプリケーションの実行をリクエストする場合、前記構成プリファレンスに対応するアプレット・リストを照合し、前記ユーザ・アプリケーションを提供するためのユーザ・アプレットを実行させるアイコンをデスクトップ上に表示させ、前記構成プリファレンスに対応した前記ユーザ・アプレットを、前記サーバから当該ユーザのワークステーションにダウンロードする、システム。
【請求項３】
サーバと、複数のユーザ・ステーションを相互接続するネットワークを含む、ネットワークシステムにおいて、ユーザ・ステーションにおいて実行されるアプリケーションに対するユーザ・構成プリファレンスを管理するプログラムを記憶した記録媒体において、前記プログラムは、管理者のステーションに対し、
前記ユーザ・ステーションから選択される管理者のステーションにおいて、プロファイル・マネージャを実行するステップ（９１２）と、
前記管理者のステーションにおいて、ユーザ・アプリケーションを実行させ、ユーザ・グループまたはユーザの関係を表示するツリーを参照して構成される前記ユーザ・アプリケーションについての構成プリファレンスの選択を前記プロファイル・マネージャが受け付けるステップ（１００４）と、
前記管理者のステーションが、前記選択された前記ユーザ・アプリケーションについての構成プリファレンスを選択させるための構成アプレットを実行させるステップ（１００６）と、
前記選択した前記ユーザ・アプリケーションについての前記構成プリファレンスを、前記サーバに記憶させるステップ（１１０７）とを実行させ、
ユーザが前記ユーザ・アプリケーションの実行をリクエストする場合、前記構成プリファレンスに対応するアプレット・リストを照合し（８１０）、前記ユーザ・アプリケーションを提供するためのユーザ・アプレット実行させるためのアイコンをデスクトップ上に表示させ（８１２）、前記ユーザ・アプリケーションを提供するための前記ユーザ・アプレットを、前記サーバから当該ユーザのワークステーションにダウンロードさせる、
コンピュータ実行可能なプログラムを記録した記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は一般に、パーソナル・コンピュータ及びネットワークの分野に関して、特に、ネットワーク・コンピュータの新たな発展的な分野に関して、そこではデスクトップ・コンピュータ・ユーザが、企業イントラネットやインターネットなどのネットワークに、またはネットワーク若しくはインターネット・サービス・プロバイダ（ＩＳＰ）に接続されるパーソナル・コンピュータ（ディスクレスも可能）を用いて、アプリケーションへのアクセスを獲得し、次にそのアプリケーションが、デスクトップ・コンピュータ上で実行される。より詳細には、本発明は、サーバから検索され、デスクトップ・コンピュータ上で実行されるソフトウェアに対するソフトウェア選択（構成データ）のサーバ・ベースの記憶に関する。
【０００２】
【従来の技術】
ネットワーク・コンピュータの分野は、現在幼年期である。しかしながら、それは多くの理由から、特に企業環境において急速に発展することが予想される。この予想は、企業及び、ことによると個々のユーザについても、ハードウェア及びソフトウェアのアップグレードの時期に達しているので、従来式にディスク装備コンピュータや、局所的に記憶及び管理されるソフトウェア・アプリケーションをアップグレードするのではなく、この新たな分野に移行することが、より効率的で廉価であることに由来する。例えば、企業環境では、ユーザは、インターネットのＴＣＰ／ＩＰプロトコル及びＨＴＴＰプロトコルを用いて、企業イントラネットに接続され、ソフトウェア・アプリケーションが必要なとき、それらをネットワーク・サーバからデスクトップ・コンピュータに直接ダウンロードする。アプリケーションは従来通り、ユーザによりデスクトップ上で実行され、有用な作業を実行する。この構成の利点は、ネットワーク・コンピュータが実質的に、従来のディスク装備コンピュータよりも廉価であることである。また、ユーザにとって、必要な数のソフトウェア・ライセンスの購入が、個々のソフトウェアのコピーを購入するよりも廉価となろう。もちろん、非常に多くの企業ユーザが参加するソフトウェア管理問題も、実質的に軽減され得る。現時点では、しばしば、ディスク装備コンピュータまたはワークステーションの各ユーザが、事実上、自分自身のシステム管理者であり、専門知識の欠如により、しばしば過度な資源を消費する。多くのユーザがソフトウェア導入、アップグレード、及びコンピュータ管理の問題に奮闘するのではなく、少数のサーバ管理専門家に問題を効果的に委ねることにより、この問題を排除することが有利であると予想される。
【０００３】
前述のように、パーソナル・コンピュータの将来のこの見通しは、現在ではその幼年期にある。結果として、現在、既存のシステムにおいては、多くの問題及び欠点が存在する。
【０００４】
通常、ネットワーク・コンピュータ・システムでは、管理者がネットワーク・サーバ上に記憶されるユーザ・プロファイルを作成する。プロファイルは異なるタイプの情報を含み、それらには、ユーザ・デスクトップ選択（preferences）や、サーバ上に存在し得る異なるソフトウェア・アプリケーションへのアクセスのためのユーザ許可などが含まれる。ユーザがシステムにログオンするとき、ユーザは自分自身であることをサーバに識別し、サーバはユーザのプロファイルを突き止め、それをユーザ・コンピュータに送信する。すると、プロファイルがユーザ・コンピュータを構成し、デスクトップを生成する。デスクトップは、ユーザがおそらくアクセスを有するであろうアプリケーションを表す多数のアイコンを含み得る。プロファイルはまた、コンピュータ及びデスクトップの他の属性も含み得て、それらは例えば、デスクトップの背景色や、デスクトップ上で使用される文字フォント及びポイント・サイズ、或いはデータ・ファイル探索経路など、ユーザにとって固有の属性である。プロファイルはユーザ変更可能であったり、変更不能であったりする。
【０００５】
ユーザが彼ら自身のプロファイルを変更できる環境では、ログオフ時に、変更されたプロファイルがサーバに逆にアップロードされ、そこでプロファイルは、ユーザが次にログオンし、検索するときのために記憶される。一部の従来システムでは、私たちが知る限り、ユーザは自分自身のデスクトップ上に、自分が希望するアプリケーション・アイコンの任意の構成を、それらがサーバ上に存在するか否かに関わらず、更にユーザがサーバ上のアプリケーションに対するアクセス許可を実際に有するか否かに関わらず生成できる。Lotus Workplace Desktop（以前はKona Desktopと呼ばれた）システムは、このタイプのオペレーションの例である。他のシステムでは、サーバがユーザに対して、サーバが有する全てのアプリケーションのリストを提供し、ユーザはそこから選択することができる。この場合、ユーザがデスクトップ上のリストから選択されるアプリケーションに対するアクセス許可を実際に有する保証はない。Sun Hot Java Viewシステムは、このタイプのシステムの例である。換言すると、従来のシステムは、ユーザがデスクトップ・アプリケーション・アイコンのセットとして構成可能なものと、ユーザが実際にアクセス許可を有するアプリケーションとの間を相関付けない。こうした場合では、ユーザがアイコンをクリックし、アプリケーションを実行するとき、アクセス許可が存在しなければ、エラー・メッセージ（無許可アクセス・メッセージなど）が発生するか、更に不具合な場合には、ユーザのコンピュータがクラッシュし得る。
【０００６】
既存の技術の別の制限は、フラット・データ構造が、ユーザ、ユーザ・グループ、端末及び端末のグループをモデル化するために使用されることである。コンピュータ資源に対するユーザ・アクセスを管理する一般的な方法に従ってモデル化され、既知のネットワーク・コンピュータの実施例（例えばLotus Administration Facility for Desktops、Microsoft Windows NT Profiles and Policies、及びSun Hot Java Views）は、サーバ上で様々な状況において、ソフトウェア選択（または属性）を管理するためのフラットな"グループ"構造を実現する。ここでは用語"状況（context）"は、個々のユーザ、ユーザ・グループ、端末または端末グループを指し示す。サーバ上でソフトウェア選択を管理するグループ化構造は、管理者が個々のユーザの他に、異なるユーザのグループの選択属性を定義することを可能にする。しかしながら、フラット・システムは多くの環境において、特に多数のユーザを有する環境において柔軟性を欠く。従って、選択情報を階層構造に編成することをサポートする管理ツールを提供することが望ましい。
【０００７】
既存のシステムの別の制限は、管理者及びユーザがワークステーション・デスクトップのユーザ構成を実行する方法が制限されることである。例えば、管理者は現在、ユーザ・アプリケーションとは別の、しかしながらそれに関連付けられる構成プログラムを用い、ユーザ選択を構成するように要求される。ベンダが１つのアプリケーションだけを提供することを許可することが望ましい。ベンダからエンド・ユーザ・アプリケーションだけを要求することは、中央管理機構がユーザまたはユーザ・グループの状況において、エンド・ユーザ・アプリケーションを実行できることを必要とする。従来技術は、オペレーションのこの管理柔軟性を可能にしない。換言すると、従来技術では、私たちの知る限り、管理者がユーザの状況において、ユーザ・アプリケーションを実行し、そのユーザ及びアプリケーションに対する選択をセットする能力を有さない。更に、従来技術では、管理者がユーザのグループの状況において、ユーザ・アプリケーションを実行し、選択をセットすることはできない。
【０００８】
本発明者が知るところの従来技術の更に別の制限は、従来技術がサーバ永久記憶空間を区分化し、サーバ上の異なるアプリケーションに関連するユーザ選択を記憶するために、固有の空間が確保されるように保証する方法である。本発明者の知る限りでは、オブジェクトを固有に識別し、他のクラスから区別する完全修飾クラス名が問い合わされるオブジェクト指向システムにおいて、記憶装置内で異なるアプリケーションの選択情報の衝突を回避する問題が、次のように、すなわち第１の中央当局がベンダに当てはまる固有の指定を割当て、次にベンダにおける第２の当局が、各ベンダ・アプリケーションに対して、第１の指定に関連する第２の指定を割当てることにより解決される。例えば、ベンダＡは第１の当局によりベンダＡ指定を割当てられ、その指定が第１の当局が作用するアーキテクチャ内で固有であることが保証される。次に、ベンダＡの第２の当局が、そのアーキテクチャ内のアプリケーションの各々に対して、第２の指定を割当てる。例えば、ベンダＡのアプリケーションの１つが、vendorA. App1と指定され、別のアプリケーションがvendorA. App2と指定される。従来技術は、システム内の各アプリケーションに対する固有の指定を、システムの永久記憶装置のある位置にマップし、異なるアプリケーションに対するその選択データが、記憶装置内で衝突しないように保証する。アプリケーションは実行中に、ネットワーク・コンピュータ・サーバにその固有記憶位置を知らせ、サーバは異なる状況において選択情報が衝突しないように、状況（ユーザ、ユーザ・グループ、端末または端末グループ）に従い、開始位置において選択情報を記憶する領域を区分化する。明らかに、記憶空間を管理するこの方法は不便で、好ましくない。記憶装置内での選択情報の衝突を回避するために、中央当局に固有の指定を割当てさせることに頼ることなく、また記憶位置情報をアプリケーションにコーディングすることなく、前述のオブジェクト指向アプリケーションにおいて、選択情報を記憶する固有の記憶位置を自動的に生成する方法を提案することが望まれる。
【０００９】
従来技術の更に別の制限は、既存のハードウェア及びアプリケーションの変更を要求することなく、それらを集中的に管理されるネットワーク・コンピュータの世界の新たな環境に移行するための準備に欠ける点である。ネットワーク環境内の既存のハードウェア、例えば端末は、ブートアップ時に、サーバ上に配置される特定の形式のファイルから、その構成情報を獲得する。端末はその構成ファイルのアクセス方法を知るようにプログラムされる。端末は特定の識別子を用い、サーバからファイルをアクセスする。固有の識別子はしばしば、端末の媒体アクセス制御（ＭＡＣ）アドレスである。しかしながら、端末が設計されたのとは異なるプロトコル及びＡＰＩに関わる新たな集中管理型環境では、その端末は新たな環境において選択情報をアクセスできず、端末はその構成ファイルを、それが設計されたようにアクセスできるだけである。これは重大な問題である。なぜなら、こうした多くの既存の装置が使用されているからである。新たなシステムにおいてそれらを使用できないことは、実質的にユーザが新たなシステムに移行しようとするインセンティブを妨げるものである。
【００１０】
従来技術の更に別の制限は、管理者と構成管理システムとの間のインタフェースに関する。管理機構内で、様々なユーザ及びユーザ・グループ、及び端末及び端末グループに対して選択情報を構成するために、ソフトウェアを構成するとき、管理ソフトウェアが、機構を実行している管理者によりセットされる状況（ユーザ、ユーザ・グループ、端末または端末グループ）において始動する。管理者がアプリケーションが実行されいている状況を変更するとき、アプリケーションは新たな状況に対する構成情報をロードするために、再始動される必要がある。状況が変更される都度、ソフトウェアを再始動するプロセスは、管理者にとって時間がかかり、不便であり、このことは特に多くのユーザを有するシステムにおいて当てはまる。こうしたシステムでは、管理者がアプリケーションを構成する間に、何度も状況を変更することが予想される。
【００１１】
【発明が解決しようとする課題】
本発明の目的は、管理者がユーザ及びグループの状況において、エンド・ユーザ・アプリケーションを実行することにより、それらを構成することを可能にする中央アプリケーション管理を有するクライアント−サーバ・システムを提供することである。
【００１２】
【課題を解決するための手段】
ここで述べられるシステムは、クライアント−サーバ環境において、ユーザ及びアプレットのための情報を構成する共通のリポジトリを提供する。これはクライアント・プロファイル管理と呼ばれる。本システムはユーザが放浪（roam）すること、すなわちいつでもシステム内の任意のコンピュータからログインし、それを実行時に、ユーザのためにサーバに記憶された選択に従い自動的に構成することを可能にする。好適な実施例はＪａｖａ（Ｊａｖａはサン社の商標）ベースのシステムであり、クライアント・コンピュータが、Ｊａｖａアプリケーションを実行するように編成されたウェブ・ブラウザ・インタフェースを使用する。従って、好適な実施例では、ユーザ・アプレット及びデスクトップ・アプレットがＪａｖａアプレットと仮定される。しかしながら、このことは本発明をＪａｖａ環境に制限することを意図するものではない。局所的に記憶されたアプリケーションのための選択は、従来通り局所的に記憶され得、サーバ・ベースのアプレットのための選択が、ここで述べられるように処理され得る。
【００１３】
本発明は、管理者がアプリケーションを管理者の状況においてではなく、ユーザまたはユーザ・グループの状況において直接実行することにより、ユーザ・アプリケーションを構成する機能を提供する。すなわち、アプリケーションの構成がアプリケーションを実行し、その目的のためのアプリケーションにより提供されるオプションを用いて、アプリケーションを構成し、あたかも実際のユーザまたはグループがアプリケーションを実行しているかのように、構成を保管することにより達成される。
【００１４】
好適な実施例では、システムがサーバ及び複数のユーザ・ステーションを相互接続するネットワークを含む。サーバは、ユーザにダウンロードされる複数のユーザ・アプリケーションを記憶する。プロファイル・マネージャが、管理者ステーションにおいて提供される。プロファイル・マネージャは、第１のエンド・ユーザ・アプリケーションに対して、別の構成アプリケーションを実行するように編成され、それにより管理者は、システム・ユーザの異なるグループ及びサブグループの状況において、第１のエンド・ユーザ・アプリケーションのために構成選択を指定し、第１のエンド・ユーザ・アプリケーションのための構成選択をサーバ上に記憶することができる。プロファイル・マネージャは更に、ユーザの異なるグループ及びサブグループの状況において、第２のエンド・ユーザ・アプリケーションを実行し、異なるグループ及びサブグループの状況において、第２のエンド・ユーザ・アプリケーションのための構成選択を指定するように編成される。これは選択されたユーザまたはグループ状況において、管理者のステーションにおいて、第２のエンド・ユーザ・アプリケーションを実行し、次に第２のエンド・ユーザ・アプリケーションのための構成選択を、サーバ上に記憶することにより達成される。
【００１５】
従って、本発明は管理者が、ユーザとしてまたはユーザ・グループとして装う間に、エンド・ユーザ・アプリケーションを効果的に実行することにより、直接エンド・ユーザ・アプリケーションを構成することを可能にする。本発明の追加の利点は、管理者がユーザ・アプリケーションを実行し、ユーザが見るのと同一の画面を見れることである。このことは管理者が、管理者の構成ではなく、ユーザ構成にもとづくユーザの状況において、ユーザ・アプリケーションを実行することにより、ユーザ問題を診断することを支援する。
【００１６】
【発明の実施の形態】
ここで述べられるシステムは、クライアント−サーバ環境内の全てのユーザ及びアプレットの構成情報の共通のリポジトリを提供する。これはクライアント・プロファイル管理と呼ばれる。本システムはユーザが放浪（roam）すること、すなわちいつでもシステム内の任意のコンピュータからログインし、それを実行時に、サーバに記憶された選択に従い自動的に構成することを可能にする。好適な実施例はＪａｖａ（Ｊａｖａはサン社の商標）ベースのシステムであり、クライアント・コンピュータがＪａｖａプログラムを実行するように編成されたウェブ・ブラウザ・インタフェースを使用する。
【００１７】
用語"アプレット（applet）"及び"サーブレット（servlet）"は、Ｊａｖａプログラミング言語において確立された用語であり、当業者には理解できるので、本明細書において使用することにする。"アプレット"は、Ｊａｖａにより動作するウェブ・ブラウザ内で実行される独立のソフトウェア・モジュールを指し示す。"サーブレット"は、Ｊａｖａにより動作するウェブ・サーバ上に存在するソフトウェア・モジュールを指し示す。ここでの"アプレット"及び"サーブレット"の使用は、少しも本発明を制限することを意図するものでない。明確化のため、ここでは語句"構成アプレット"が、ワード・プロセッサやデータベース・マネージャなどの、エンド・ユーザ・ソフトウェア・アプリケーションの選択を構成するために使用されるソフトウェア・モジュールを指し示すために使用される。ソフトウェア・アプリケーションもまた、Ｊａｖａ環境内の"アプレット"であるので、ここでは語句"ユーザ・アプレット"または単に"アプレット"が、エンド・ユーザ・アプリケーションを指し示すために使用される。
【００１８】
好適な実施例では、ユーザ・アプレット及びデスクトップ・アプレットがＪａｖａアプレットと仮定される。しかしながら、本発明はＪａｖａ環境に制限されるものではなく、任意のクライアント−サーバ・システムにおいて使用され得る。例えば、本システムは要望に従い、プロプラエタリ（proprietary）通信プロトコル、及び任意の所望のプログラミング言語で作成され、コンパイルされたアプリケーションを使用するように設計され得る。更に、好適なＪａｖａベースの環境であっても、ディスク・ベースのコンピュータが一部のアプリケーションを局所的にアクセスし、他のアプレットをサーバからアクセスできる。局所的に記憶されたアプリケーションの選択が、従来通り、局所的に記憶され、サーバ・ベースのアプレットの選択が、ここで述べられるように処理され得る。しかしながら、好適には、局所的に記憶されたアプリケーションの選択が、ここで述べられるサーバ・ベースのアプレットの選択に加え、プロファイル管理属性ＡＰＩを用いて、サーバ上に記憶される。
【００１９】
アプレットがユーザまたは管理者により実行されるとき、ＡＰＩに作成されたアプレットが、選択データを容易に記憶及び検索することを単純なアプリケーション・プログラム・インタフェース（ＡＰＩ）が可能にする。アプレット許可及びユーザ選択が、グループ・メンバーシップ及び個々の識別にもとづき定義され得る。
【００２０】
クライアント・プロファイル管理は次のサービスを含む。すなわち、
・ログオン・サポート−ユーザ・プロファイルへのマッピング。
・ユーザ・サポート−ユーザ識別を作成し、サービス及び選択を直接ユーザに提供する管理能力。
・ユーザ・グループ・サポート−ユーザの階層グループを作成し、グループ・メンバーシップにもとづき、サービス及び選択を提供する管理能力。
・ユーザ・アプレット状況透過性−ユーザ・アプレット実行の状況の自動決定。すなわち、ユーザ・アプレット実行に当てはまるユーザ・プロファイルまたはグループ・プロファイルの決定、及びプロファイル環境の自動確立。
・ユーザ・アプレット選択リポジトリ−ユーザ・アプレット構成データのための状況依存（context-sensitive）サーバ記憶装置。
・動的ユーザ・アプレット選択継承−継承のオブジェクト指向プリンシパルを介する、ユーザ・アプレット選択の階層ロード時間の合体。
・ユーザ・アプレット・アクセス制御−グループ・デフォルト・メンバーシップ特権にもとづく、ユーザ・アプレット実行の制御。管理者はデフォルト・グループ特権をオーバライドし、個々のユーザのための追加のアクセス特権を許可または拒否する。
【００２１】
プロファイル管理は、これらのタスクが実行されるフレームワークを提供する。一部のタスク、例えばユーザ／グループ管理、アプレット・リスト、状況切替え、及び選択継承などは、プロファイル管理により直接サポートされる一方、ユーザ・アプレット特有の構成サービスは通常、クライアント・プロファイル管理環境内でシステム管理者により呼び出される別々の構成アプレットによりサポートされる。一部のエンド・ユーザ・アプレットは、構成機能をエンド・ユーザ・アプレットの一部として提供する。この場合、管理者は（別々の構成アプレットではなく）エンド・ユーザ・アプレットを、個々のユーザ及びグループの状況において実行し、それらのユーザ及びグループの構成選択をセットする。
【００２２】
図１は、本発明を実現するように意図された環境のハイ・レベル図である。ネットワーク１００は、デスクトップ・パーソナル・コンピュータ１０２、モバイル・ラップトップ・コンピュータ１０４、ワークステーション１０６（例えばＲＩＳＣコンピュータ）、管理者のステーション１０８及びサーバ１１０などの、複数のユーザ・ステーションを相互接続するために提供される。１実施例では、ネットワーク１００はローカル・エリア・ネットワークである。別の実施例では、ネットワーク１００は、地理的に転置された地点をシステム内に含んで有する企業などのエンティティのための広域ネットワークを含み得る。本発明が実現され得る環境を制限する意図はなく、実際、多くのタイプのステーションを相互接続する任意のタイプのネットワークが考えられる。
【００２３】
プロファイル管理の管理動作環境のハイ・レベル図が、図２に示される。管理クライアント・ネットワーク・コンピュータ２００が図の左側に、またシステムのためのサーバ２０２が右側に示される。クライアントとサーバは、２０３で示されるネットワークを介して通信する。図２の特定の例では、クライアント・コンピュータがシステム管理者のコンピュータであることを想定する。
【００２４】
クライアント側のプロファイル・マネージャ２０６は、管理者がユーザ・レベル及びグループ・レベルの両方において、ユーザ・アプレット選択を構成することを可能にする。管理者は新たなユーザ階層及びグループ階層を作成し、ユーザを異なるグループに追加し、各グループ及び個々のユーザに対して、アプレット許可を指定する。そして管理者は個々のユーザまたはグループの状況において、アプレットを構成することができる。管理者はユーザのパスワードを追加、消去及びリセットすることができる。プロファイル管理サポートは、一般ユーザにとって透過的である。管理者は任意のユーザまたはグループの状況において、プロファイル・マネージャ２０６を呼び出す。管理者だけが自分の状況から変化し、クライアント（ユーザ）及びグループを管理することができる。サーバは管理権限の無いユーザが、状況を切り替えることを可能にしない。要求がサーバに到来すると、サーバはこの機能をアクセスしようとしているユーザの認証ＩＤを問い合わせる。ユーザが管理権限を所有しない場合（すなわち、AllUsers. Administratorグループのメンバでない場合）、プロファイル・マネージャ・サーブレット２１４がこの要求を拒絶する。
【００２５】
プロファイル・マネージャ２０６は、図２に示されるように、アプレット１（２０８）などの他のアプレットを呼び出す。この例では、アプレット１はユーザ・デスクトップに関連する選択を構成する管理アプレットである。或いは、アプレット１は、エディタ、ワード・プロセッサ、データベースなどの、エンド・ユーザ・アプレットに関連する構成ユーティリティである。２０８などの構成アプレットが、それらの対応するユーザ・アプレットとは別のモジュールとして存在することが好ましい。図２の状況では、アプレット１は通常、ユーザ・アプレットのための構成アプレットである。すなわち、管理者がグループ状況の下で、構成アプレットであるアプレット１を実行し、グループ選択及び許可デフォルト指定をセットするか、ユーザ状況において、ユーザ・アプレット構成を個人用にカストマイズする。アプレット１をそのユーザ・アプレットとは別のモジュールとして実現することにより、性能が向上される。なぜなら、構成アプレット１はユーザ・アプレットに比較して、おそらく小さいからである。また、別の構成アプレットは、エンド・ユーザがユーザ・アプレットを構成する能力を、管理者が制御することを可能にする。
【００２６】
従来の独立型コンピュータは、ユーザ・アプレット構成情報をそのユーザ・アプレットと関連して、局所的に記憶する。従来の独立型Ｊａｖａベースのコンピュータは、ユーザ・アプレット構成情報を、java. util. Propertiesクラスにより提供されるフォーマットを用いて記憶する。両者の構造は、ユーザ・アプレットが、そのユーザ・アプレットに関連する構成情報を記憶するローカル・ファイルの名前を指定することを要求する。換言すると、コンピュータとその上にロードされるユーザ・アプレット間の関係が要求される。ここで述べられるプロファイル管理は、実際のjava. util. Propertiesオブジェクトの既知の機能に加え、ユーザ放浪機能をサポートする追加の機構、及び強力な管理フレームワーク（プロファイル・マネージャ）へのシームレスな接続可能性を提供する。
【００２７】
プロファイル管理属性（ProfileManagementProperties）Ｐ（２１０）は、アプレット１の属性オブジェクトであり、アプレット１とサーバ間のＡＰＩを提供し、これはサーバがユーザ及びグループの状況において、アプレット１の構成情報を記憶する場所を決定することを可能にする。プロファイル管理属性オブジェクト・クラスは、java. util. Propertiesクラスの全ての機能の他に、ソフトウェアの構成情報を作成し、永久記憶装置に保管及びそこから検索する追加の機能を提供する。中央位置にこうした情報を記憶することは、ユーザ構成及びグループ構成の管理を可能にする。ユーザが管理のための役割をする場合、プロファイル管理属性２１０は、管理者が構成アプレット１に対応するユーザ・アプレットを構成することを、或いはアプレット１がエンド・ユーザ・アプレットの場合、アプレット１を構成し、適切な状況において、構成情報をサーバ上の適切な場所に記憶することを可能にする。このことは従来システムの場合のように、ユーザ・アプレットとコンピュータ間の関係ではなく、ユーザ・アプレットとユーザ間の関係の確立を可能にする。プロファイル管理属性２１０は、java. util. Propertiesクラスの拡張である。この拡張は、java. util. Properties同様、属性オブジェクトの選択情報のキー／値の対が、ストリームにではなくキーに関連付けられることを可能にする。このことは代わりに、アプリケーション開発者がファイル名及び経路ではなしに、キーを用いて、選択情報の状況に関する固有の位置を指定することを可能にする。プロファイル管理属性２１０は、キーを自動的に決定する。キーの生成については、図８及び図９に関連して詳述する。java. util. Propertiesクラスの後、プロファイル管理属性２１０をモデル化することにより、システムは再帰クラス・デフォルト評価を通じて、選択継承を利用できる。従って、この拡張されたクラスは、図３に関連して述べるように、現状況にて開始する選択を蓄積し、デフォルト指定のための状況階層を横断することにより、"グループ・デフォルト"機能を提供する。
【００２８】
サーバ２０２はデータベース２１２を含み、これはユーザ選択及びグループ選択や、ユーザ・アプレット・アクセス許可などの、ユーザ・データ及びグループ・データを記憶する。ウェブ・サーバ２１８は、Ｊａｖａアプレットをサポートする典型的なウェブ・サーバを表す。プロファイル・マネージャ・サーブレット２１４は、ユーザ識別及びグループ識別を選択データにマップする。これはまた、サーバ上のアプリケーションへのユーザ・アクセスを管理するアクセス制御リストを保持する。
【００２９】
ユーザ選択及びグループ選択が、図３に示されるように、ツリー階層として記憶される。システムの全てのユーザが自動的に、トップ・グループAllUsersに属する。全てのユーザはAllUsersグループに属する。すなわち、このグループは、サーバ上の一部のまたは全てのユーザ・アプレットに対するデフォルト選択を含む。図３では、サーバがＡｐｐ３、Ａｐｐ４及びＡｐｐ５として識別される少なくとも３つのユーザ・アプレットを含むように仮定される。AllUsersグループ内で識別されるように、Ａｐｐ３のデフォルト・バックグラウンド（ＢＧ）は、ＢＧ＝blueである。ｘ、ｙ及びｚとしてラベル付けされる他の選択は、それぞれ１、２及び３のデフォルト値を有するように示される。用語ｘ、ｙ及びｚは、任意の所望の選択を表すように意図され、値１、２及び３は任意であり、単にポイントを表すために使用される。ｘ選択は例えば、デスクトップの画面フォントであり、値ｘ＝１はタイムズ−ローマンのデフォルト・フォントを要求する。同様に、全てのユーザに対するＡｐｐ４のデフォルト選択は、ＢＧ＝gray、ｘ＝２、ｙ＝２及びｚ＝２である。
【００３０】
AllUsersグループ内のデフォルト値は、任意の所望の方法により、他の状況、例えば他のユーザ・グループ及び個々のユーザなどに対して変更され得る。例えば、図３のAllUsersの状況に加え、４つの他のグループ（GroupＸ、GroupＹ、GroupＹ１及びGroupＹ２）が示される。更に、２人の個人User１及びUserＮが示される。ユーザは２グループ以上のメンバである。図３では、User１はAllUsers、GroupＸ及びGroupＹ１のメンバであり、UserＮはAllUsers及びGroupＹ２のメンバである。ユーザが２グループ以上（AllUsersの他に別のグループ）のメンバの場合、グループがそのユーザのための所与のアプレットの選択（preference）を選択するために優先順位付けされる。管理者がユーザのグループ優先順位を構成する。グループ優先順位が図４に示される。図４では、User１がGroupＸ（自分の最も高い優先グループの完全修飾名AllUsers. GroupXにより識別される）を有する。User１の次に高い優先グループは、GroupＹ１（AllUsers. GroupY. GroupY1）である。User１の最も低い優先グループは、AllUsersグループである。ユーザ、例えばUser１がアプレット、例えばＡｐｐ３の実行を要求すると、選択が図３のツリーから、ユーザが属するグループまたは複数のグループに従い合体され、それに従い、ユーザ・アプレットがユーザ・デスクトップ上に構成される。
【００３１】
任意の状況において選択を合体する第１のステップは、デフォルト指定を獲得することである。ユーザに対してデフォルト指定が存在する場合、それはアプレットの選択情報が獲得され得る最も高い優先グループからのアプレットに対する、選択の合体セットである。グループに対してデフォルト指定が存在する場合、それはグループの親（すなわち、AllUsersグループがAllUsers. GroupXの親である）からのアプレットに対する選択の合体セットである。グループが親を有さない（すなわち、トップ・レベルAllUsersグループである）場合、そのグループに対するデフォルト指定は存在しない。ある状況において、アプレットに対する選択を合体するために、その状況にて明示的に記憶されたアプレットの選択が、その状況におけるアプレットのデフォルト選択を上書きする。従って、グループ状況において、選択をアプレットのデフォルト・セットに合体するために、各グループ・ノードからAllUsersグループに至るまで、アプレットに対する各親の選択のセットを要求する再帰呼び出しが発行される。次の例を示す図３を参照されたい。例えば、状況がAllUsers. GroupY. GroupY1の場合、アプレットに対するそのデフォルト選択を要求する呼び出しが、GroupＹ１の親、すなわちGroupＹに発行される。GroupＹ１はその親であるAllUsersに、再帰呼び出しを発行する。AllUsersは親を有さないので、GroupＹからの呼び出しに対して、AllUsersはアプレットに対する選択のセットを返却する。この選択のセットは、GroupＹにアプレットに対して記憶される選択が存在すれば、それにより変更される。これが今後、GroupＹ１の状況における、アプレットに対する選択のデフォルト・セットとなる。このデフォルト選択のセットが、GroupＹ１からGroupＹへの再帰呼び出しの結果として、GroupＹ１に返却され、GroupＹ１においてアプレットに対する選択が存在すれば、それにより変更され、このインスタンス内で使用される実際の選択のセットとなる。ユーザの状況における選択のセットは、ユーザに対して選択情報が獲得され得る最も高い優先グループが、デフォルト指定が獲得されるグループ状況を最初に確立するために使用される以外は、同様にして生成される。次に、前述の再帰プロシージャが、ユーザに対する実際の選択のセット、及びユーザにより要求されたアプレットを生成するために使用される。
【００３２】
以下の例は、前述の選択合体を示し、図３に関連して参照されるべきである。
【００３３】
例１：管理者がＡｐｐ３の構成アプレットを実行し、グループAllUsers. GroupXに対する選択をセットする。
【００３４】
AllUsers. GroupXの状況において、Ａｐｐ３に対する選択をセットするために、現選択セットが決定されなければならない。AllUsers. GroupXは、その親であるAllUsersのデフォルト指定を要求する。AllUsersはトップ・レベル・グループであるので、それはＡｐｐ３に対する自分の選択を、GroupＸに返却する。GroupＸの状況において、Ａｐｐ３に対するデフォルト選択が存在する。GroupＸはＡｐｐ３に対する選択を有さないので、AllUsersからのデフォルト・セットが、使用される実際の選択セットとなる。この例では、AllUsersグループからのこれらの選択は、ＢＧ＝Blue、ｘ＝１、ｙ＝２、ｚ＝３である。管理者は今度、構成アプレットを使用し、合体された選択を所望の方法で変更できる。
【００３５】
例２：User１がcom. ibm. App3の実行を要求する。選択がUser１の状況において、com. ibm. App3のために合体されなければならない。
【００３６】
図４は、User１に対する最も高い優先グループが、Allusers. GroupXであることを示す。すなわち、グループ階層のこの分岐が、Ａｐｐ３に関する選択情報として最初にチェックされる。以下では、選択の合体セットが、ユーザのワークステーション上でＡｐｐ３を構成するために使用される以外は、示される例は本質的に前述の例１と同様である。User１に対するＡｐｐ３の選択は、ＢＧ＝Green、ｘ＝１、ｙ＝２、ｚ＝３である。なぜなら、User１の状況において、Ａｐｐ３に対して記憶されるＢＧ＝Green選択が、選択ツリーのAllUsers. GroupX分岐から獲得された、デフォルト指定のＢＧ＝Blue選択をオーバライドするからである。
【００３７】
例３：User１の状況における、com. ibm. App6に対する選択の合体。
【００３８】
この例は、最も高い優先グループの状況が、User１の状況における合体選択を含まないことを示す。再度、User１に対する最も高い優先グループはGroupＸである。このグループ及びその親AllUsersは、Ａｐｐ６に対する選択を含まない。従って、次に高い優先グループが探索される。User１に対する次に高い優先グループは、GroupＹ１である。選択セットがＡｐｐ６に対するこのグループから獲得され得る。選択の合体が例１で述べたように進行する。再帰呼び出しがGroupＹ１からツリーを遡り、ルートAllUsersグループに発行され、選択セットが再帰呼び出しの下流に返却されて、途中変更され、デフォルト・セットが形成される。デフォルト・セットが次に、GroupＹ１に記憶された選択により変更され、この状況に当てはまる選択の合体セットを形成する。要するに、AllUsersはＡｐｐ６に対する選択を有さないので、選択のヌル・セットを返却する。GroupＹはこのヌル・セット値をａ＝１及びｂ＝２により変更し、このセットをデフォルト・セットとしてGroupＹ１に返却する。GroupＹ１はデフォルト・セットをａ＝３３により変更する。このセットがUser１状況に返却され、そのデフォルト・セットとして使用される。User１状況には、Ａｐｐ６に対する選択は記憶されていないので、選択ツリーのGroupＹ１分岐から獲得されるデフォルト指定は、Ａｐｐ６に対する完全に合体された選択セットを表す。従って、選択の実際のセットは、この状況に対してａ＝３３、ｂ＝２となる。
【００３９】
前述の３つの例は、特定のソフトウェア部分としてのload（）に応答して、選択を収集することについて述べた。選択情報がソフトウェア部分に対して保管されるとき、保管される状況にて明示的に作成されたあらゆる選択が、ソフトウェアが実行されている状況と、選択が記憶されているソフトウェアのキーとの組み合わせにより指定される、データ記憶装置２１２内の位置に書込まれる。
【００４０】
許可も同様に動作する。すなわち、新たなグループは、グループ自体により許可される全てのアプレット名へのアクセスの他に、そのスーパグループにより許可される全てのアプレットへのアクセスを有する。しかしながら、プログラマがスーパクラス・メソッドをオーバライドすることをＪａｖａが可能にするのと同様、プロファイル管理は、システム管理者が継承された許可をオーバライドすることを可能にする。これは許可のオーバライドと呼ばれる。
【００４１】
Ｊａｖａの継承形式同様、プロファイル管理の選択及び許可継承の形式は、単一継承と呼ばれる。単一継承は、各プロファイル管理グループが１つのスーパグループだけを有することを意味する（任意の所与のスーパグループが複数のサブグループを有し得る）。
【００４２】
プロファイル管理ユーザ（葉ノード）は、複数のグループ内のメンバーシップを要求できる。従って、機構は、グループ間分岐合体により導入される非互換の可変サブセットの導入による、不正な構成の機会を最小化するために、選択継承を単一の階層グループに制限することを要求される。ユーザのグループ・メンバーシップの優先順位付けを可能にすることにより、プロファイル管理は探索順序に従い、特定のアプレットに関連する選択を探索する。換言すると、探索は最も高い優先順位のグループから開始し、その選択をロードしようとしているアプレットの構成データを含むことが判明した最初のグループで停止する。
【００４３】
ユーザはグループ・メンバーシップからソフトウェア許可を継承する。慎重な企業モデル化により、管理者はパネルを移動する必要無しに、１度に１ユーザのペースでソフトウェア・アクセスを多くのユーザに割当てる。プロファイル管理は、ウェブ・サーバがアプレットへのアクセスを許可／拒否するようにプログラムすることにより、アクセスを制御する。ウェブ・サーバはアクセス制御を実施する。プロファイル・マネージャ・サーブレットもまた、ウェブ・サーバが認証の目的で、ウェブ・サーバへのユーザＩＤ及びパスワードの転送を要求することにより保護される。ユーザ・パスワードを催促することは、標準のブラウザ機能である。
【００４４】
図５は、図２のシステムの詳細を示す。構成アプレットであるアプレット１が、プロファイル管理フレームワーク内の管理者により呼び出される。アプレット１は、その動作環境に関する情報（例えば、照会状況、状況変更事象、この状況のための照会アクセス制御リストなど）を問い合わし、プロファイル管理フレームワーク内でしっかり統合するための、アプリケーション・プログラム・インタフェース（ＡＰＩ）５１５を実現できる。しかしながら、これは構成アプレットに対する要求ではない。いずれにしろ、アプレット１の設計者は、java. util. Propertiesオブジェクト内にまたはそこから、選択情報を獲得するために使用されるjava. util. Propertiesオブジェクトの基本メソッドに加え、基本ＡＰＩメソッド、すなわちenablePersistence（）、load（）、及びsave（）を理解するだけでよい。ＡＰＩ５１５は更に、list（）メソッド及びgetContext（）メソッドを提供する。アプレット１は、プロファイル管理属性クラスに登録され、これらのメソッドを適宜呼び出すだけでよい。load（）メソッドは、管理者により選択されるユーザまたはグループの状況において構成されるユーザ・アプレットに対する、選択の現状態を検索するために呼び出される。管理者は次に、選択を望まれるように変更し、それらをアプレットにより提供される構成保管機能（プロファイル管理属性オブジェクトのsave（）メソッド）を用いて記憶する。同様に、アプレット１が、ユーザによるアクセスに対して許可されたユーザ・アプレットのリストを必要とする場合、それはlist（）メソッドを用い、サーバからリストを獲得する。getContext（）メソッドは、アプレットが実行されている状況の名前を表示するために、或いはアプレットが特定の状況においてのみ実行されることを保証するために使用される。（すなわち、アプレットがエクスポート・エージェントを用い、サーバ上でサービスを構成したい場合、アプレットはそれ自身がAllUsers状況においてのみ実行されることを可能にする。なぜなら、エクスポートされる構成が、ユーザ特有ではなしに、サーバ特有であるからである。）アプレット１がプロファイル管理フレームワーク内で実行されるために要求される全てのことは、アプレットがプロファイル管理属性５１０に登録され、java. util. Propertiesクラスの拡張であるプロファイル管理属性クラスを実現することである。
【００４５】
プロファイル・マネージャ５０６はまた、構成アプレットのための状況変更ＡＰＩ５１６を提供する。アプレット１は状況変更事象リスナ５１２を実現する。ＡＰＩ５１６及び事象リスナ５１２は、管理者が構成アプレットを実行する間に、それを停止及び再始動する必要無しに、状況（ユーザまたはグループ）を変更することを可能にする。例えば、アプレット・ユーザ選択を構成するとき、管理者は構成の間に、おそらく状況を何度も変更することであろう。構成アプレットがこうした事象のリスナとして登録される場合、プロファイル・マネージャ５０６はＡＰＩ５１６を介して、リスナに状況変更を知らせる。このことはアプレット１が各新たな状況に対して、サーバからその選択をリフレッシュすることを可能にする。事象リスナＡＰＩ無しでは、新たな状況に対する既存の選択情報を参照し、プロファイル管理アプレットにより停止及び再始動されることを回避するために、アプレット１が管理者により終了され、新たな状況が選択された後、再始動されなければならない。登録のために、アプレット１はその属性オブジェクトであるプロファイル管理属性５１０上のメソッド、すなわち状況変更リスナ追加（addContextChangeListener）（ＡＰＩ５１６）を呼び出し、自身を登録する。管理者が新たな状況をセットすると、プロファイル・マネージャ５０６がオブジェクト５１０に状況セット呼び出し（ＡＰＩ５１６）を実行し、オブジェクト５１０がそれに応答して、事象リスナ５１２上の再ロード・メソッド（ＡＰＩ５１６）を呼び出す。事象リスナ５１２はその属性オブジェクト５１０に属性ロード呼び出しを実行し、新たな状況に対する新たな選択データをサーバから獲得し、アプレット１に新たな選択情報を反映するように、そのＧＵＩ変数及び内部変数を更新するように指示する。
【００４６】
前述の機能は、ネットワーク管理者が１状況からデータを読出し、状況を変更し、新たな状況において構成変更を実行する以前に、load（）を意図したつもりが、うっかりsave（）により上書きする可能性を回避する。
【００４７】
リスナとして登録されないアプレットは、管理者が状況変更を強制するとき、プロファイル・マネージャ・アプレットにより停止され、破壊され、再ロードされ、再始動される。
【００４８】
プロファイル管理はまた、既存のハードウェア及びソフトウェアを、このプロファイル管理環境に容易に改造することを可能にする、"属性エクスポート"・サービスを提供する。属性エクスポート・サービスは、プロファイル・マネージャ５１４がユーザ・ワークステーション（物理ハードウェア）と、ユーザ、グループ、及びユーザ・アプリケーションをサポートすることを可能にする。既存のワークステーションはプロファイル管理属性５１０を認識しないので、エクスポート・サービスは、ベンダ・アプレットがその選択情報を保管するとき、ワークステーション・ベンダが、サーバ上に呼び出されるエクスポート・エージェント５２０を指定するワークステーション構成アプレットを作成することを可能にする。エクスポート・タグは、ベンダ供給されるクラスのインスタンス（エクスポート・エージェント５２０オブジェクト）の作成を指示し、エクスポート・メソッドがオブジェクト上で呼び出されるように指示する。エクスポート・メソッドは、ワークステーション構成情報が、構成されるワークステーションにより要求されるプロプラエタリ・ファイル形式にて、ファイル位置に保管されるように指定する。
【００４９】
アプレット１が、現プロファイル管理システムと非互換の既存の端末に対して、ベンダにより提供される構成アプレットと仮定する。ベンダはまた、エクスポート・エージェント５２０を供給する。管理者はプロファイル・マネージャ５０６を実行することにより、システム内でのオペレーションのために端末を構成し、構成される端末に状況をセットし、ベンダ供給される構成アプレット１を実行し、アプレットを構成することができる。管理者が構成を保管するとき、サーバに伝送される情報の一部が、構成される端末を識別する固有の識別子である。通常、これは端末の媒体アクセス制御（ＭＡＣ）アドレスである。プロファイル・マネージャ・サーブレット５１４は、エクスポート・エージェントがサーバ上で指定されることを検出する。プロファイル・マネージャ・サーブレット５１４はこれを、エクスポート・エージェントの必要性を指定するために保管された選択の１つから検出する。この選択はエクスポート・タグを、次のキー値対の形式で指定する。
XXXXEXPORT_AGENTXXXX={エクスポート・エージェントの完全修飾クラス名}
【００５０】
エクスポート・エージェントのエクスポート（Context状況、config属性）・メソッドが、プロファイル・マネージャ・サーブレット５１４により呼び出され、保管選択情報から、１つ以上のファイル５２２をサーバ上に作成する。特定の１つのまたは複数のファイルが、アプレット１から属性情報と共に到来した、端末の固有の識別子により識別される。端末が後にブートアップするとき、端末はプロファイル管理システムとは独立に、通常行うように、その固有の識別子を用い、その構成情報をサーバ上で突き止め、ファイル５２２から検索する。
【００５１】
図６は、クライアント・コンピュータ上で実行されるアプレット２を示す。アプレット２はワード・プロセッサなどのエンド・ユーザ・アプレットである。いずれにしろ、アプレット２は、図５に５１５で示される同一のＡＰＩメソッドの一部へのアクセスを有する。アプレット２はロード・メソッドにより選択を検索し、セーブ・メソッドにより、ユーザにより変更され得るあらゆる選択を保管する。EnablePersistenceは、管理者に関連して前述したように、アプレット２に対するプロファイル管理属性オブジェクトを、ユーザに等しい状況により初期化し、サーバ上の選択情報記憶位置を識別する固有のキーを生成する。
【００５２】
図７は、ユーザが自分のデスクトップを導出する状況を示す。クライアント７００上のユーザは、自分のウェブ・ブラウザを、サーバ上のデスクトップ・アプレットのＵＲＬに差し向け、ステップ７０４で、メッセージhttp://server/Desktop. htmlを送信する。Desktop. htmlはサーバが保護するファイルであるので、ステップ７０６で、クライアント上のウェブ・ブラウザに呼び掛け（challenge）が返送される。クライアント上のウェブ・ブラウザは、ユーザにユーザＩＤ及びパスワードを催促することにより応答する。クライアントは次にステップ７０８で、ユーザＩＤ及びパスワード情報をサーバに送信する。ユーザＩＤ及びパスワードが、図８のステップ７０８で太字で示される。これはこの情報が、ウェブ・ブラウザ自身により転送されることを示す。このタイプの命名法は、他の場所でも同一のことを表すために使用される。おそらく、ユーザはデスクトップ・アプレットを実行する許可を有するので、要求が遵守される。
【００５３】
デスクトップ・アプレットのコードが、サーバからクライアントにロードされるとき、クライアントとサーバの間には、一連の対話（図示せず）が存在する。ステップ７１２で、デスクトップ・オブジェクトが作成され、実行を開始する。デスクトップ・オブジェクトは、その選択情報（すなわち構成情報）を必要とするので、オブジェクトはデスクトップを、それを呼び出しているエンド・ユーザのために、個別に適合化することができる。この目的のために、デスクトップ・オブジェクトの初期化プロセスの一部として、デスクトップはステップ７１４で、プロファイル管理属性オブジェクトＰを作成し、これがデスクトップ・アプレットに対して、サーバからユーザの選択情報のコピーをロード、獲得、キャッシュ、セット、及び保管するために使用される。デスクトップ・オブジェクトが次にステップ７１６で、ＡＰＩ呼び出しP. enablePersistence（desktopObject（applet））を実行する。これはステップ７１６のステップ１で、プロファイル管理属性オブジェクトＰを、プロファイル・マネージャ・サーブレット２１４のＵＲＬにより初期化する。このＵＲＬは、以前にサーバからロードされたデスクトップ・アプレットのＵＲＬから導出される。プロファイル管理属性オブジェクトＰは、デスクトップ・アプレットを実行するユーザの状況を獲得するために、要求７１８をプロファイル・マネージャ・サーブレット２１４に送信する。この場合、状況は２つの要素、すなわちユーザのＩＤに相当する状況名及び状況タイプを含み、後者はこの場合、Userである。プロファイル・マネージャ・サーブレットが、要求７１８からユーザのＩＤを獲得し、ステップ７１９でユーザ状況を返却する。ステップ７１６のステップ２で、プロファイル管理属性オブジェクトＰが、デスクトップを実行するユーザの状況により初期化される。ステップ７１６のステップ３で、プロファイル管理属性オブジェクトＰは、Ｊａｖａデスクトップ・オブジェクトＰに、その完全修飾クラス名を要求することにより、デスクトップ・ソフトウェアの固有のキーを生成する。全てのＪａｖａオブジェクトは、それらのクラス名を知っている。この固有のキーがユーザの状況情報と結合され、デスクトップ・アプレットに対するユーザ特有の選択情報を記憶する、データベース２１２内の固有の位置を指定するパラメータを提供する。任意の所望の方法が、完全修飾クラス名及びユーザ状況情報を含むストリングを、データ記憶位置にマップするために使用され得る。次に、デスクトップ・アプレットに対して、ユーザに個別に適合化された選択情報を獲得するために、要求７２０がプロファイル・マネージャ・サーブレット２１４に送信される。状況及びキーが要求７２０の一部として転送され、要求された選択情報を識別する。プロファイル・マネージャ・サーブレット２１４は、ステップ７２２で、要求された選択情報により応答し、これがプロファイル管理属性オブジェクトＰ（６０４）内にキャッシュされる。
【００５４】
図８の説明を続けると、ステップ８００で、デスクトップ・オブジェクトがそのプロファイル管理属性オブジェクトＰから、その選択情報を読出し、それに従い、デスクトップの更新を開始する（すなわち、画面色をブルーにセットし、アイコンの位置に関する情報を獲得するなど）。デスクトップ・オブジェクトは、そのプロファイル管理属性オブジェクトＰ上のメソッドを呼び出し、ユーザがアクセス許可を有するソフトウェアのリストを獲得する。プロファイル管理属性オブジェクトＰは、ステップ８０２で、プロファイル・マネージャ・サーブレット２１４から情報を要求する。すると、後者がステップ８０４で、要求された情報により応答を生成する。ユーザがアクセスを有する各こうしたアプレットに対して、情報はユーザ・フレンドリな名前、アプレットのＵＲＬ、アプレットのためのアイコンのＵＲＬなど（デスクトップがアプレットをデスクトップ上に表現し、それをロード及び始動するために要求される情報）、及び本発明に関連しない他の任意選択の資料を含む。この情報がプロファイル管理属性オブジェクトＰ内に記憶され、デスクトップ・オブジェクトに返却される。ステップ８０６で、デスクトップ・オブジェクトがアプレット情報を用いて、アプレットのためのフォルダを形成し、ユーザがアクセスを有する各アプレットのアイコン及びユーザ・フレンドリな名前を表示するウィンドウを生成する。
【００５５】
ユーザによるデスクトップの以前の実行において、ユーザが前述したフォルダ内に表示される幾つかのソフトウェアのアイコンを、ドラッグ・アンド・ドロップしたと仮定する。この時点で、ユーザがもはや、フォルダからデスクトップにドラッグ・アンド・ドロップされたアプレットへのアクセスを有さない可能性がある。しかしながら、これらのデスクトップ・オブジェクトは通常、最後の実行の間に保管され、依然デスクトップ上に表示されるユーザ選択の一部であり得る。この状況を回避するため、デスクトップはそのプロファイル管理属性オブジェクトＰからその選択を調査し、ユーザがアクセスを有する全てのアプレットを表示するために生成される、ウィンドウの外側に現れるように構成されるアプレットをチェックする。図８は、生成されるアプレット・ウィンドウの外側に、１つのアプレットだけが存在することを仮定する。アプレット・ウィンドウの外側に、２つ以上のこうしたアプレットが存在する場合、次のプロシージャが各こうしたアプレットに対してループされる。ステップ８１０で、デスクトップが、アプレット・ウィンドウの外側に現れるこれらのアプレットの各々を、ユーザがアクセスを有するサーバからのアプレットのリストと照合する。アプレットがリスト内に現れる場合、ステップ８１２で、アプレットのアイコンがデスクトップ上に、以前と同一の位置に配置される。ユーザがもはやアプレットへのアクセスを有さない場合、ステップ８１４で、アプレットがデスクトップの選択から除去され、プロファイル管理属性オブジェクトＰから除去される。任意のアプレットがこのプロセスの一部として除去される場合、ステップ８１６で、デスクトップがプロファイル管理属性オブジェクトＰに、選択を保管するように命令する。プロファイル管理属性オブジェクトＰは、新たな選択情報をデータベース２１２に保管するために、要求８１８を選択、キー及び状況情報と一緒に、プロファイル・マネージャ・サーブレット２１４に送信する。サーバは応答８２０をプロファイル管理属性オブジェクトＰに送信し、プロファイル管理属性オブジェクトＰに、要求が成功裡に完了したことを伝える。
【００５６】
図９は、管理者が構成アプレットを実行し、他のユーザまたはユーザのグループのために、選択を構成する状況を示す。ここで述べる原理は一般に、端末または端末のグループの構成にも当てはまる。クライアント９００上の管理者が、自分のウェブ・ブラウザを、実行されるべきサーバ上のプロファイル・マネージャ・サーブレット２１４のＵＲＬに差し向ける。ステップ９０４で、ＵＲＬがサーバに送信される。ProfileManager. htmlはサーバが保護するファイルであるので、呼び掛け９０６がクライアント上のウェブ・ブラウザに返送される。ウェブ・ブラウザは、管理者にユーザＩＤ及びパスワードを催促することにより応答する。ProfileManager. htmlを獲得する要求が、ステップ９０８で、メッセージ内に含まれるユーザＩＤ及びパスワードと共に、サーバに対して繰り返される。おそらく、管理者はプロファイル・マネージャを実行する許可を有するので、要求が遵守され、ステップ９１０で、プロファイル・マネージャ・アプレットが管理者端末にダウンロードされる。プロファイル・マネージャ・アプレットのコードが、サーバからクライアントにロードされるとき、クライアントとサーバの間には、一連の対話（図示せず）が存在する。ステップ９１２で、プロファイル・マネージャ・オブジェクトが作成され、実行を開始する。
【００５７】
正規のプロファイル管理属性オブジェクトの代わりに、プロファイル管理属性非状況浮動（Ｐ＿ＮＣＦ：ProfileManagementProperties_nonContextFloating）オブジェクトが、プロファイル・マネージャにより使用される。これは１つの例外を除き、プロファイル管理属性オブジェクトと同様の振舞いを有する。すなわち、選択がロードされ、保管されるとき、それらが管理者が構成している状況（すなわちユーザまたはユーザ・グループ）においてロード及び保管されるのではなく、プロファイル・マネージャを実行している管理者の状況において、ロード及び保管される。
【００５８】
プロファイル・マネージャ・オブジェクトは、その選択情報（すなわち構成情報）を必要とするので、それはプロファイル・マネージャを、それを呼び出している管理者のために、個別に適合化することができる。この目的のために、プロファイル・マネージャ・オブジェクトの初期化プロセスの一部として、プロファイル・マネージャはステップ９１４で、プロファイル管理属性非状況浮動オブジェクトＰ＿ＮＣＦを作成し、これがプロファイル・マネージャ・アプレットに対して、サーバから管理者の選択情報のコピーをロード、獲得、キャッシュ、セット、及び保管するために使用される。プロファイル・マネージャ・オブジェクトが次にステップ９１６で、P_NCF. enablePersistence（profileManagerObject（applet））を呼び出す。これはステップ９１６のステップ１で、プロファイル管理属性非状況浮動オブジェクトＰ＿ＮＣＦを、プロファイル・マネージャ・サーブレット２１４のＵＲＬにより初期化する。このＵＲＬは、プロファイル・マネージャ・アプレットのＵＲＬから導出される。プロファイル管理属性非状況浮動オブジェクトＰ＿ＮＣＦは、管理者の状況名（ＩＤ）及び状況タイプ（ＵＳＥＲ）を獲得するために、要求９１８をプロファイル・マネージャ・サーブレット２１４に送信する。プロファイル・マネージャ・サーブレットが、要求９１８から管理者のＩＤを獲得する。ウェブ・ブラウザは、メッセージ内の管理者ＩＤ及びパスワードを、プロファイル管理属性非状況浮動オブジェクトＰ＿ＮＣＦにより送信される情報と一緒に転送する。ステップ９１６のステップ２で、プロファイル管理属性非状況浮動オブジェクトＰ＿ＮＣＦが、アプレットを実行する管理者の状況により初期化される。ステップ９１６のステップ３で、プロファイル管理属性非状況浮動オブジェクトＰ＿ＮＣＦは、Ｊａｖａプロファイル・マネージャ・オブジェクト（profileManagerObject）（enablePersistence呼び出し内のパラメータとして転送される）に、その完全修飾クラス名（profileManagerObject. getClass（）. getName（））を要求することにより、プロファイル・マネージャ・アプレットの固有のキーを生成する。この固有のキーが管理者の状況情報と結合され、プロファイル・マネージャ・アプレットに対する管理者特有の選択情報を記憶する、データベース２１２内の固有の位置を指定するようにマップされる。
【００５９】
管理者のために構成されるプロファイル・マネージャ・アプレットに対して、個別に適合化された選択情報を獲得するために、要求９２２がプロファイル・マネージャ・サーブレット２１４に送信される。要求９２２は、適切な状況名及び状況タイプ、及び適切な選択情報を識別するキー情報を含む。プロファイル・マネージャ・サーブレット２１４は、要求された選択情報９２４により応答し、これがプロファイル管理属性非状況浮動オブジェクトＰ＿ＮＣＦ内にキャッシュされる。プロファイル・マネージャは、プロファイル管理属性非状況浮動オブジェクトＰ＿ＮＣＦからその選択情報を読出し、それに従い自分自身を更新する（すなわち、例えばその背景色をブルーにセットする）。
【００６０】
オペレーションは図１０に継続する。プロファイル・マネージャは、既存のユーザ、ユーザ・グループ、及びプロファイル・マネージャ・サーブレット２１４からのソフトウェアに関する情報を要求し、ステップ１００２で、プロファイル・マネージャ構成ウィンドウの左パネル内にツリーを生成する。管理者の左パネルの例として、図１３乃至図２４を参照されたい。この時点１００４で、管理者は左パネル・ツリーからユーザまたはグループをクリックすることにより、構成のために所望の状況を選択する。プロファイル・マネージャは、P_NCF. setContext（選択状況）を呼び出すことにより、プロファイル管理属性オブジェクトの状況をセットする。図１３は、全てのシステム・ユーザのグループを示す"ユーザ・グループ"の選択状況を示す。或いは、図１８では、"Development"のグループ状況が選択され、図２１では、ユーザ状況"colleend"が選択される。次にステップ１００６で、管理者がサーバ上の全てのアプレットのリストから、構成されるアプレットを選択する。図１７は、アプレットを選択する例を示す。ステップ１００８で、管理者は実行／カストマイズ・ボタンをクリックし、構成のために選択されるアプレットを実行する。このアプレットは、エンド・ユーザ・アプレットとは別の構成アプレットであっても、エンド・ユーザ・アプレット自身であってもよい。ステップ１００９で、選択されたアプレットが要求され、ステップ１０１１でサーバからロードされる。ステップ１０１０で、構成アプレット・オブジェクトが作成され、実行を開始し、そのプロファイル管理属性オブジェクトＰを生成する。
【００６１】
アプレットがエンド・ユーザ・アプレットとは別の構成アプレットと仮定すると、ステップ１０１２で、アプレットがP. enablePersistence（構成アプレット・オブジェクト、構成されるアプレットの完全修飾クラス名）を呼び出す。他方、アプレットが別の構成アプレットではなくユーザ・アプレットの場合、呼び出しはp. enablePersistence（エンド・ユーザ・アプレット・オブジェクト）である。なぜなら、それは別のアプレットの選択情報ではなく、それ自身の選択情報を構成したいからである。現状況は既に、プロファイル管理属性オブジェクトＰにより知れている。なぜなら、それは以前に管理者により、管理者のプロファイル管理属性非状況浮動オブジェクトＰＭ＿ＮＣＦを介してセットされたからである。プロファイル・マネージャ・サーブレット２１４の位置は、enablePersistenceがプロファイル・マネージャのプロファイル管理属性非状況浮動オブジェクトＰＭ＿ＮＣＦ上で呼び出されたとき、以前に生成された。構成アプレットの場合、アプレットの固有のキーが生成される必要がない。なぜなら、それは構成アプレットにより、enablePersistence呼び出し内のプロファイル管理属性オブジェクトＰに転送されるからである。
【００６２】
ステップ１０１４で、構成アプレットが自身をそのプロファイル管理属性オブジェクトＰに、状況変更リスナとして登録する。前述のように、これはアプレットのプロファイル管理属性オブジェクトＰが、アプレットに、管理者が状況変更を行うか否かを知らせることを可能にする。従って、アプレットは新たな状況の選択情報をロードし、アプレットが終了され、新たな状況において再始動されることを要求すること無く、新たな構成情報を反映するように、そのグラフィック・ユーザ・インタフェースを更新できる。
【００６３】
オペレーションは図１１に継続する。ステップ１１０４で、構成アプレットがプロファイル管理属性オブジェクトＰに、構成されるアプレットに対して、現状況から選択をロードするように命令する。構成されるアプレットに対して、管理者により以前に選択された状況に対して個別に適合化された選択情報を獲得するために、要求１１０５がプロファイル・マネージャ・サーブレット２１４に送信される。要求１１０５は、適切な状況名（管理者が選択した状況）及び状況タイプ（USER、USER_GROUP、またはALL_USER_GROUP）、及び適切な選択情報の位置を指定するキー情報を含む。プロファイル・マネージャ・サーブレット２１４は、ステップ１１０６で、要求された選択情報により応答し、これがプロファイル管理属性オブジェクトＰ内にキャッシュされる。構成アプレットはプロファイル管理属性オブジェクトＰから選択を獲得し、それに従いそのグラフィック・ユーザ・インタフェースを更新する。
【００６４】
管理者はステップ１１０７でアプレットを構成し、例えばアプレットにより提供される保管ボタンをクリックすることにより、変更された選択を保管する。このオペレーションの結果、構成アプレットが、そのプロファイル管理属性オブジェクトＰ上のsave（）メソッドを呼び出す。プロファイル管理属性オブジェクトＰは、選択、構成されるアプレットの固有のキー、及び現状況を指定する情報をプロファイル・マネージャ・サーブレット２１４に送信する。プロファイル・マネージャ・サーブレットは、選択情報をデータベース２１２内の、状況及びキーにより指定される位置に記憶する。
【００６５】
ステップ１１０８は、現在状況を変更中の管理者の例であり、一方構成アプレットは依然実行中である。管理者はユーザまたはユーザ・グループをクリックすることにより、新たな状況を選択する（図１８の管理者左画面パネル内の新たな状況の例を参照）。状況変更の結果、プロファイル・マネージャ５０６は、P_NCF. setContext（選択された新たな状況）を呼び出すことにより、セット状況メッセージをプロファイル管理属性オブジェクトＰ（５１０）に送信し、これが次にオブジェクトＰに、再ロード属性ＡＰＩ５１６を介して、事象リスナ５１２に状況変更を知らせるように指示する。これはステップ１１１０で発生する。ステップ１１１２で、事象リスナ５１２がload（）呼び出しを実行し、新たな状況に対する選択を検索し、ステップ１１１８で、オブジェクトＰが新たな選択により更新される。管理者は次に、希望に応じて新たな状況に対する新たな選択を変更し、要求される場合、それらを保管し、必要に応じて前述のように新たな状況変更を継続する。
【００６６】
図１２乃至図２４は、プロファイル・マネージャ２０６の一部を実行している間の、管理者のワークステーションの実際の画面スナップショットを示す。
【００６７】
主構成ウィンドウ１２００が図１２に示される。ウィンドウの左側のツリー図パネル１２０２は、サーバ上で使用可能な幾つかのサービスの１つとして、プロファイル管理１２０４を示す。図１２で示されるように、この項目１２０４が選択されるとき、主ウィンドウの右パネル１２０５が、プロファイル管理サービスの歓迎メッセージを表示する。１２０８などの拡大アイコン及び縮小アイコンが、左パネル内の項目下のサブ項目の外観を制御するために使用される。１２０８内の"＋"は"拡大アイコン"と呼ばれ、"プロファイル管理（Profile management）"下にサブ項目が存在することを示す。管理者は拡大アイコン１２０８をクリックすることにより、これらのサブ項目を表示でき、その時このアイコンは"縮小アイコン"（"−"）となる。
【００６８】
図１３は、図１２のプロファイル管理項目１２０４の拡大を示し、その結果、３つのデフォルト指定のサブ項目、"アプレット（Applets）"１３００、"ユーザ・グループ（User Groups）"１３０２、及び"ユーザ（Users）"１３０４が表示される。拡大アイコンはこれらの項目が更に拡大され得ることを示す。"アプレット"１３００は、管理者がサーバ２０２上で使用可能なユーザ・アプレットを定義することを可能にし、"ユーザ・グループ"１３０２は、管理者が図３のユーザ・グループ・ツリーを作成及び分布させ、グループ選択をセットすることを可能にする。"ユーザ"１３０４は管理者が新たなユーザを作成し、それらの選択をセットするか、既存のユーザに対する選択を変更することを可能にする。図１３に示される例では、"アプレット"１３００が選択されている。この項目が選択されると、ウィンドウの右側のパネル１３０５が、システムに既に定義されたユーザ・アプレットのリスト１３０６を表示する。１３０６内で選択されるアプリケーションの属性が、１３０８に示される。管理者は１３０６内の＜ＮＥＷ＞を選択し、要求される名前及び位置情報を１３０８内に入力することにより、新たなアプレットを定義する。既存のアプレット、"データベース・エクスプローラ（Database Explorer）"が、１３０６内で選択されて示される。１３０８において、"アプレット名（Applet name）"フィールドがこのアプレット名を表示する。"ＵＲＬ"（ユニバーサル・リソース・ロケータ）フィールドは、サーバ２０２上のこのアプレットのイントラネットまたはインターネット・ウェブ・アドレスを表示する。フィールド"ｈｔｍｌファイルの完全経路（Complete path of html file）"は、サーバ２０２のディスク・ディレクトリ構造内のディレクトリ経路、及びアプレットのファイル名を表示する。フィールド"完全修飾クラス名（Fully qualified class name）"は、アプレットの完全修飾クラス名を表示する。フィールド"アイコンＵＲＬ"は、ユーザのデスクトップ上にアプレットのアイコンを生成するために使用される、イメージ・ファイルのウェブ・アドレスを表示する。残りのフィールドは、呼び出し時にソフトウェアにより要求され得る任意選択情報のためのものである。コマンド・ボタン１３１０"ファイルからアプレット・リストをインポート（Import Applet List from File）"は、管理者が既存のテキスト・ファイルから既存のリスト１３０６に、アプレットの定義を追加することを可能にする。ボタン１３１０がクリックされると、図１４に示されるウィンドウがポップアップし、管理者が、追加されるアプレット定義を含むテキスト・ファイルの経路及びファイル名を入力することを可能にする。全ての保留の変更を保管するために、管理者はファイル１３１２をクリックし、次に保管（図示せず）をクリックする。
【００６９】
左パネル内において、ユーザ・グループ項目１３０２は、図３の全ユーザ（AllUsers）・グループに対応する（"ユーザ・グループ"及び"全ユーザ"はここでは互換に使用される）。図１５は、"ユーザ・グループ"項目１３０２が選択されたときの、管理者ステーションの右パネルを示す。図１５では、ノートブック・パネルが右側に表示され、これは３つのタブ、メンバ・タブ１５１４、サブグループ・タブ１５１６、及びアプレット許可タブ１５１８を含む。図１５では、メンバ・タブが選択されている。メンバ・パネルは、システムに定義された全てのメンバのログオン識別のリスト１５２０を含む。新たなユーザ（現在選択されているグループ状況、すなわち"ユーザ・グループ"へのメンバーシップを自動的に獲得する）を作成するために、管理者はリスト１５２０から＜ＮＥＷ＞を選択し、リストの右側の入力フィールド１５２２に適切な情報を入力し、作成（Create）ボタン１５２３をクリックする。リスト１５２０から既存のメンバが選択されるとき、そのユーザに対して以前に保管された属性が、１５２２に表示される。これらの属性には、選択されたメンバのフル・ネーム、メンバのシステムＩＤ、パスワード、及び所望のコメントが含まれる。ＩＤを除く属性は編集可能で、変更は変更（Modify）ボタン１５２４をクリックすることによりコミットされる（しかし保管されない）。或いは消去（Delete）ボタン１５２６をクリックすることにより、ユーザがシステムから完全に除去され得る。任意の保留の変更が、リスト１５２０内のエントリを選択し、取り消し（Undo）ボタン１５２８をクリックすることにより除去され得る。
【００７０】
図１６は、サブグループ（Subgroups）・タブ１５１６が選択されたときに表示される、管理者の右パネルを示す。サブグループ・リスト１６２０が、左パネル内で選択された項目、この例では"ユーザ・グループ"のサブグループである既存のグループを示す。従って、リスト１６２０は、"全ユーザ"・グループの全ての直接サブグループを表示する。左パネル内では、"ユーザ・グループ"が拡大されて示される。リスト１６２０内に示されるサブグループもまた、左パネル内の"ユーザ・グループ"下の拡大項目である。リスト１６２０内において、ステータス・フィールドは、各サブグループの現ステータス、例えば"！消去（!delete）"、"！変更（!Modify）"及び"！作成（!Create）"などを示す。リスト１６２０内の空ステータス・フィールドは、サブグループが存在するが、保管される保留のアクションが存在しないことを示す。"！"記号は、ステータスが保留である（まだ保管されていない）ことを示す。リスト１６２０内で選択されたサブグループの属性は、１６２２内に表される。これらの属性には、サブグループ名及びサブグループに関する所望のコメントが含まれる。新たなサブグループを作成するために、管理者はリスト１６２０から＜ＮＥＷ＞を選択し、１６２２内にサブグループ名及び所望のコメントを入力し、作成（Create）ボタン１６２８をクリックする。すると、"！作成＜サブグループ名＞"（!create<subgroup name>）のエントリが、リスト１６２０内に保留のアクションとして現れる。全ての保留の変更を保管するために、管理者はトップ・メニュー・バー内のファイル・ボタンをクリックし、次に保管ボタン（図示せず）をクリックする。
【００７１】
図１７は、アプレット許可（Applet Permissions）タブ１５１８が選択されたときに表示される、右パネルを示す。リスト１７２０はシステムに定義された全てのアプレットの全ての名前と、左パネル内で選択されるグループまたはサブグループ（現"状況"）に対して、各アプレットに割当てられる許可ステータス（アクセスを許可または拒否）を示す。前述の他のノートブック・ページ同様、感嘆符は示されるステータスが、保管を保留中の変更であることを示す。図１７では、グループ・"ユーザ・グループ"が、左パネル内に示されるツリー内で選択されており、これは図３に示される"全ユーザ（AllUsers）"・グループに対応する。システムの全てのユーザが、"ユーザ・グループ"・グループ内のメンバーシップを有するので、リスト１７２０は、システムに定義される各アプレットに対して、全てのシステム・ユーザに対して、グローバル・デフォルト許可を示す。例えば、アプレット・"データベース・エクスプローラ"に対するデフォルト許可ステータスは、"全ユーザ"・グループに対して、"許可（permit）"（アクセスが許可されることを意味する）である。同様に、アプレット"ＴＦＴＰ"に対する全ユーザのデフォルト許可ステータスは、"拒否（deny）"（アクセスが拒否される）である。管理者はアプレットの許可ステータスを、リスト１７２０内でそれを選択し、"グループ・アクセス許可（Permit group access）"ボタン１７３０または"グループ・アクセス拒否（Deny group access）"ボタン１７３２をクリックすることにより変更できる。更に、選択された状況に対するアプレットの許可ステータスに関係無しに、管理者はリスト１７２０からアプレットを選択し、"実行／カストマイズ（Run/Customize）"・ボタン１７３４をクリックすることにより、選択された状況の下で、ユーザ・アプレットを実行できる。現状況に対して、以前にノートブックを示したパネル領域が、実行されるユーザ・アプレットにより占有される。ユーザ・アプレットがたまたま、他のソフトウェアのための構成アプレットの場合、管理者は（この機能のために提供される構成アプレットの固有の機構を通じて、）ソフトウェア選択を保管することができ、これが次に、選択された状況に対する、ソフトウェアのデフォルト選択として保管される。アプレットがエンド・ユーザ・アプレットの場合、エンド・ユーザ・アプレットが、別のソフトウェア部分に対する選択ではなしに、自身の選択をロードし保管する以外は、機能は同様である。
【００７２】
図１８は、"ユーザ・グループ"下の管理者左パネル・サブグループ・ツリーの完全な拡大を示す。"ユーザ・グループ"の直下には、２つのサブグループ、すなわち除去され得ないデフォルト・サブグループである"管理者"と、管理者により定義されるサブグループである"ＩＢＭ"とが存在する。"ＩＢＭ"サブグループは更に拡大されて、３つのサブグループ、"ハードウェア（Hardware）"、"サービス（Services）"及び"ソフトウェア（Software）"を含む。"ソフトウェア"・サブグループは拡大され、"開発（Development）"と呼ばれる少なくとも１つのサブグループを含む。"開発"サブグループは、ＮＣｏＤと呼ばれる少なくとも１つのサブグループを含む。サブグループ"ＮＣｏＤ"は、子を有さないConfigＦＷ５８などの多数のサブグループを含む。この例ではまた、サブグループ"開発"が拡大ツリー内で選択されている。"開発"はツリー階層の最上部（"全ユーザ"・グループ）ではないので、右パネル内に示されるノートブックは、"ユーザ・グループ"が選択されたときの図１５のそれとは幾分異なる。なぜなら、全ユーザは"ユーザ・グループ"のメンバであり、自動的に"開発"のメンバではないからである。リスト１８２０は全システム・メンバのログオン・システムＩＤを表示する。リスト１８２０内の各ユーザＩＤの隣のステータスは、ユーザが"開発"サブグループ内のメンバーシップを所有するか否かを示す。ステータス"ｙｅｓ"は、ユーザが"開発"サブグループのメンバであることを示し、"ｎｏ"はユーザが"開発"サブグループのメンバでないことを示し、"継承（inherited）"は、ユーザがツリーの更に下流の開発のサブグループの少なくとも１つに属することにより、"開発"サブグループ内のメンバーシップを継承することを示す。サブグループに対するユーザのメンバーシップ・ステータスが、管理者がリスト１８２０内のユーザを選択し、"グループに追加（Add to group）"ボタン１８３６または"グループから除去（Remove from group）"ボタン１８３８をクリックすることにより変更される。管理者が新たなシステム・ユーザを作成したいか、既存のメンバを変更または消去したい場合、管理者は"作成／変更／消去（Create/Modify/Delete）ユーザ"・ボタン１８４０をクリックする。このアクションは、図１９に示されるノートブック・ページを導出する。図１９の右パネルは、図１５のそれと類似であり、管理者がリスト１９２０内の＜ＮＥＷ＞を選択し、次に"作成"ボタンをクリックすることにより、新たなシステム・ユーザを作成することを可能にする。同様に、管理者は、リスト１９２０内の適切なユーザを選択し、適切なボタン"変更"または"消去"をクリックすることにより、既存のシステム・ユーザを変更または消去することができる。任意のサブグループ状況（例えば"開発"）において作成されたユーザは、"ユーザ・グループ"内の要求メンバーシップを獲得するだけでなく、自動的に選択サブグループのメンバを形成する。システム・ユーザ・リストの変更は、右パネルのトップ・メニュー・バー内の"ファイル"をクリックし、次に"保管"（図示せず）をクリックすることにより保管される。
【００７３】
図２０は、図１９に示されるグループ経路及びサブグループ経路を通じてではなく、直接システム・ユーザ・リストに編集のために達する方法を示す。図２０に至るために、管理者は例えば、図１３の左パネル内の"ユーザ（Users）"１３０４を選択する。次に、図２０に示される右パネル内において、管理者はグループまたはサブグループの状況に留まることなく、前述したように、新たなユーザを作成し、既存のユーザを変更及び消去することができる。
【００７４】
図２１では、管理者が、"colleend"のＩＤを有するユーザに対応する情報に、直接働きかけることを希望する。これを実行するため、管理者は図示のように、例えば図２１の左パネル内で"ユーザ"を拡大し、次に"colleend"を選択する。すると、colleendのシステム情報に捧げられる右パネルが現れる。右パネルは３つのタブを含む。第１のタブ"ユーザ情報（User infomation）"は、デフォルト指定により選択される。このタブ内で、管理者はcolleendに関わる名前、ＩＤ、パスワード及びコメントを変更できる。
【００７５】
図２２は、管理者が第２のタブ"グループ・メンバーシップ（Group Memberships）"を選択するときの右パネルを示す。リスト２２２０は、colleendがメンバである全てのサブグループを示す。サブグループがこのリスト内で、colleendに対するそれらの優先順位の順に示される。管理者はサブグループを選択し、リスト２２２０の右側の上矢印及び下矢印を用いて、選択されたサブグループをリストの上方または下方に移動することにより、colleendのサブグループ優先順位を変更できる。管理者が、図２２内の"グループ・メンバーシップ追加／除去（Add/Remove Group Memberships）"ボタン２２４２をクリックすると、右パネルが図２３の内容を示す。図２３の右パネルは、管理者がcolleendがメンバであるサブグループを変更することを可能にする。管理者はこれを、所望のサブグループに対応する適切なボックスをクリックすることにより実行する。ボックスが空の場合（colleendが現在メンバでないことを意味する）、チェック・マークをボックスに追加することにより、colleendをサブグループ内に含む。逆に、サブグループ・ボックスが既にチェックされている場合、ボックスをクリックすると、チェック・マークがクリアされ、colleendをサブグループから除去する。
【００７６】
図２４は、図２２の"アプレット許可（Applet Permission）"タブが管理者により選択されるときの、右パネルを示す。この右パネル内において、リスト２４２０はシステム内で定義される全てのアプレットを表示する。管理者はリスト２４２０内のアプレットを選択し、次に"ユーザ・アクセス許可（Permit user access）"ボタン２４３０をクリックすることにより、colleendによるアプレットへのアクセスを許可することができる。或いは、"ユーザ・アクセス拒否（Deny user access）"ボタン２４３２をクリックすることにより、colleendによるアクセスが拒否される。管理者はまた、"実行／カストマイズ（Run/Customize）"・ボタン２４３４をクリックすることにより、colleendの状況において、アプレットを始動できる。これが実行されるとき、リスト２４２０内で選択されたアプレットが右パネル内で始動される。管理者はこの時、アプレットが許可するあらゆる選択を変更し、アプレットにより提供される方法で選択を保管できる。ここでの典型的な状況は、管理者が構成アプレットを始動し、様々な選択フィールドを記入することである。しかしながら、別の構成がユーザ・アプレットに対して提供されない場合、管理者はユーザの状況においてユーザ・アプレットを始動し、ユーザ・アプレットから選択をセットできる。ここでの典型的な状況は、管理者がグループ状況またはユーザ状況を選択し、前述のようにユーザ・アプレットを始動することである。管理者はこの時、通常、オプション・メニューから選択を変更し、それらをユーザ・アプレットにより提供される方法で保管することができる。例えば、通常、オプション・ダイアログが閉じられるとき、ユーザ選択が保管されるか、ユーザ・アプレットが選択を保管する他の方法を提供する。いずれにしろ、この例では、管理者がcolleendの状況において、アプレットを実行しているので、管理者によりユーザ・アプレットを通じてセットアップされた選択が、あたかもcolleendがアプレットを実行することにより、自身でそれらを直接入力したかのように、サーバ上に保管される。
【００７７】
ユーザがユーザ・アプレットに関係する一部の選択を変更できる状況は、図示されていない。例えば、ユーザ・アプレットはユーザがウィンドウの背景色またはフォント及びフォント・サイズを選択することを可能にする。従って、各システム・ユーザは、ユーザ・アプレットがユーザのデスクトップ上で実行されるとき、アプレットをある程度個性化することができる。この場合、ユーザ変更された選択が、管理者がユーザ・アプレットを実行するときと同様に保管される。しかしながら、１つの違いは、管理者がユーザ・アプレットを実行し、グループ状況において選択をセットできるのに対して、ユーザが彼らの個々の状況に対して、選択に影響を及ぼすことができることである。
【００７８】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００７９】
（１）ユーザ・ステーションにダウンロードされる複数のユーザ・アプリケーションを記憶するサーバと、複数の前記ユーザ・ステーションとを相互接続するネットワークを含むネットワーク・システムにおいて、前記ユーザ・ステーションにおいて実行されるアプリケーションに対するユーザ構成選択を管理する方法であって、
管理者ステーションにおいて、プロファイル・マネージャを提供するステップと、
第１のエンド・ユーザ・アプリケーションに対して、別々の構成アプリケーションを実行するように、前記プロファイル・マネージャを編成することにより、管理者がシステム・ユーザの異なるグループ及びサブグループの状況において、前記第１のエンド・ユーザ・アプリケーションに対する構成選択を指定するステップと、
前記サーバ上に、前記第１のエンド・ユーザ・アプリケーションに対する前記構成選択を記憶するステップと、
ユーザの異なるグループまたはサブグループの状況において、第２のエンド・ユーザ・アプリケーションを実行するように、前記プロファイル・マネージャを編成することにより、前記管理者のステーションにおいて前記第２のエンド・ユーザ・アプリケーションを実行することにより、前記異なるグループ及びサブグループの状況において、前記第２のエンド・ユーザ・アプリケーションに対する構成選択を指定するステップと、
前記サーバ上に、前記第２のエンド・ユーザ・アプリケーションに対する前記構成選択を記憶するステップと
を含む、方法。
【図面の簡単な説明】
【図１】本発明が実現され得る管理者のステーションを含むネットワーク及びユーザ・ステーションを示す図である。
【図２】サーバと通信する管理者のステーション、及び中央プロファイル管理及び選択管理を提供する管理者のステーション及びサーバの構成要素をブロック図形式で示す図である。
【図３】システムのユーザ・グループ及びユーザの階層構成を示し、個々の端末及び端末グループは、単純化のために省略された図である。
【図４】個々のユーザと、図３の階層構成から、ユーザ及びユーザにより実行される特定のアプリケーションに当てはまる選択のセットを決定するために使用されるグループ優先順位のリストを示す図である。
【図５】図２の管理者のステーション及びサーバの詳細図である。
【図６】ユーザの端末としてアプリケーションの実行の間にユーザ選択を確立するように協働する、ユーザ・アプリケーション及びアプリケーションと他の構成要素間のＡＰＩを含む、ユーザの端末におけるソフトウェア・オブジェクトを示す図である。
【図７】ユーザ・ログオン、及びユーザ端末において、デスクトップ選択を含むユーザのデスクトップを初期に確立するための、ユーザの端末及びサーバの両方におけるオペレーションを示す図である。
【図８】ユーザ・ログオン、及びユーザ端末において、デスクトップ選択を含むユーザのデスクトップを初期に確立するための、ユーザの端末及びサーバの両方におけるオペレーションを示す図である。
【図９】管理者ユーザ・ログオン、管理者のデスクトップの確立、及び１例として構成のためのアプリケーション及び状況の選択ための、管理者の端末及びサーバの両方におけるオペレーション、並びにユーザのデスクトップの構成の間の状況変更及び結果のオペレーションを示す図である。
【図１０】管理者ユーザ・ログオン、管理者のデスクトップの確立、及び１例として構成のためのアプリケーション及び状況の選択ための、管理者の端末及びサーバの両方におけるオペレーション、並びにユーザのデスクトップの構成の間の状況変更及び結果のオペレーションを示す図である。
【図１１】管理者ユーザ・ログオン、管理者のデスクトップの確立、及び１例として構成のためのアプリケーション及び状況の選択ための、管理者の端末及びサーバの両方におけるオペレーション、並びにユーザのデスクトップの構成の間の状況変更及び結果のオペレーションを示す図である。
【図１２】図３に１例が示される階層の生成、ユーザなどの作成及び消去、アプリケーションに対するアプリケーション選択の確立、及び選択確立の間の状況変更を含む、アプリケーション管理の様々なフェーズでの、様々な実際の管理者画面スナップショットを示す図である。
【図１３】図３に１例が示される階層の生成、ユーザなどの作成及び消去、アプリケーションに対するアプリケーション選択の確立、及び選択確立の間の状況変更を含む、アプリケーション管理の様々なフェーズでの、様々な実際の管理者画面スナップショットを示す図である。
【図１４】図３に１例が示される階層の生成、ユーザなどの作成及び消去、アプリケーションに対するアプリケーション選択の確立、及び選択確立の間の状況変更を含む、アプリケーション管理の様々なフェーズでの、様々な実際の管理者画面スナップショットを示す図である。
【図１５】図３に１例が示される階層の生成、ユーザなどの作成及び消去、アプリケーションに対するアプリケーション選択の確立、及び選択確立の間の状況変更を含む、アプリケーション管理の様々なフェーズでの、様々な実際の管理者画面スナップショットを示す図である。
【図１６】図３に１例が示される階層の生成、ユーザなどの作成及び消去、アプリケーションに対するアプリケーション選択の確立、及び選択確立の間の状況変更を含む、アプリケーション管理の様々なフェーズでの、様々な実際の管理者画面スナップショットを示す図である。
【図１７】図３に１例が示される階層の生成、ユーザなどの作成及び消去、アプリケーションに対するアプリケーション選択の確立、及び選択確立の間の状況変更を含む、アプリケーション管理の様々なフェーズでの、様々な実際の管理者画面スナップショットを示す図である。
【図１８】図３に１例が示される階層の生成、ユーザなどの作成及び消去、アプリケーションに対するアプリケーション選択の確立、及び選択確立の間の状況変更を含む、アプリケーション管理の様々なフェーズでの、様々な実際の管理者画面スナップショットを示す図である。
【図１９】図３に１例が示される階層の生成、ユーザなどの作成及び消去、アプリケーションに対するアプリケーション選択の確立、及び選択確立の間の状況変更を含む、アプリケーション管理の様々なフェーズでの、様々な実際の管理者画面スナップショットを示す図である。
【図２０】図３に１例が示される階層の生成、ユーザなどの作成及び消去、アプリケーションに対するアプリケーション選択の確立、及び選択確立の間の状況変更を含む、アプリケーション管理の様々なフェーズでの、様々な実際の管理者画面スナップショットを示す図である。
【図２１】図３に１例が示される階層の生成、ユーザなどの作成及び消去、アプリケーションに対するアプリケーション選択の確立、及び選択確立の間の状況変更を含む、アプリケーション管理の様々なフェーズでの、様々な実際の管理者画面スナップショットを示す図である。
【図２２】図３に１例が示される階層の生成、ユーザなどの作成及び消去、アプリケーションに対するアプリケーション選択の確立、及び選択確立の間の状況変更を含む、アプリケーション管理の様々なフェーズでの、様々な実際の管理者画面スナップショットを示す図である。
【図２３】図３に１例が示される階層の生成、ユーザなどの作成及び消去、アプリケーションに対するアプリケーション選択の確立、及び選択確立の間の状況変更を含む、アプリケーション管理の様々なフェーズでの、様々な実際の管理者画面スナップショットを示す図である。
【図２４】図３に１例が示される階層の生成、ユーザなどの作成及び消去、アプリケーションに対するアプリケーション選択の確立、及び選択確立の間の状況変更を含む、アプリケーション管理の様々なフェーズでの、様々な実際の管理者画面スナップショットを示す図である。
【符号の説明】
１００、２０３  ネットワーク
１０２  デスクトップ・パーソナル・コンピュータ
１０４  モバイル・ラップトップ・コンピュータ
１０６  ワークステーション
１０８  管理者のステーション
１１０、２０２、６０６、７０２、９０２  サーバ
２００  管理クライアント・ネットワーク・コンピュータ
２０６、５０６、５１４  プロファイル・マネージャ
２０８、５０８  アプレット１
２１２  データベース
２１４  プロファイル・マネージャ・サーブレット
２１８、５１８  ウェブ・サーバ
５１２  状況変更事象リスナ
５１５、５１６  アプリケーション・プログラム・インタフェース
５２０  エクスポート・エージェント
６００  ユーザ
７００、９００  クライアント
１２００  主構成ウィンドウ
１２０２  ツリー図パネル
【図１】
0003940239.tif 000002
【図２】
0003940239.tif 000003
【図３】
0003940239.tif 000004
【図４】
0003940239.tif 000005
【図５】
0003940239.tif 000006
【図６】
0003940239.tif 000007
【図７】
0003940239.tif 000008
【図８】
0003940239.tif 000009
【図９】
0003940239.tif 000010
【図１０】
0003940239.tif 000011
【図１１】
0003940239.tif 000012
【図１２】
0003940239.tif 000013
【図１３】
0003940239.tif 000014
【図１４】
0003940239.tif 000015
【図１５】
0003940239.tif 000016
【図１６】
0003940239.tif 000017
【図１７】
0003940239.tif 000018
【図１８】
0003940239.tif 000019
【図１９】
0003940239.tif 000020
【図２０】
0003940239.tif 000021
【図２１】
0003940239.tif 000022
【図２２】
0003940239.tif 000023
【図２３】
0003940239.tif 000024
【図２４】
0003940239.tif 000025