JP3096457B2 - 非ネイティブ・ステーションまたは非ネイティブ・アプリケーションを適応させる方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は一般に、パーソナル
・コンピュータ及びネットワークの分野に関して、特
に、ネットワーク・コンピュータの新たな発展的な分野
に関して、そこではデスクトップ・コンピュータ・ユー
ザが、企業イントラネットやインターネットなどのネッ
トワークに、またはネットワーク若しくはインターネッ
ト・サービス・プロバイダ（ＩＳＰ）に接続されるパー
ソナル・コンピュータ（ディスクレスも可能）を用い
て、アプリケーションへのアクセスを獲得し、次にその
アプリケーションが、デスクトップ・コンピュータ上で
実行される。より詳細には、本発明は、サーバから検索
され、デスクトップ・コンピュータ上で実行されるソフ
トウェアに対するソフトウェア選択（構成データ）のサ
ーバ・ベースの記憶に関する。

【０００２】

【従来の技術】ネットワーク・コンピュータの分野は、
現在幼年期である。しかしながら、それは多くの理由か
ら、特に企業環境において急速に発展することが予想さ
れる。この予想は、企業及び、ことによると個々のユー
ザについても、ハードウェア及びソフトウェアのアップ
グレードの時期に達しているので、従来式にディスク装
備コンピュータや、局所的に記憶及び管理されるソフト
ウェア・アプリケーションをアップグレードするのでは
なく、この新たな分野に移行することが、より効率的で
廉価であることに由来する。例えば、企業環境では、ユ
ーザは、インターネットのＴＣＰ／ＩＰプロトコル及び
ＨＴＴＰプロトコルを用いて、企業イントラネットに接
続され、ソフトウェア・アプリケーションが必要なと
き、それらをネットワーク・サーバからデスクトップ・
コンピュータに直接ダウンロードする。アプリケーショ
ンは従来通り、ユーザによりデスクトップ上で実行さ
れ、有用な作業を実行する。この構成の利点は、ネット
ワーク・コンピュータが実質的に、従来のディスク装備
コンピュータよりも廉価であることである。また、ユー
ザにとって、必要な数のソフトウェア・ライセンスの購
入が、個々のソフトウェアのコピーを購入するよりも廉
価となろう。もちろん、非常に多くの企業ユーザが参加
するソフトウェア管理問題も、実質的に軽減され得る。
現時点では、しばしば、ディスク装備コンピュータまた
はワークステーションの各ユーザが、事実上、自分自身
のシステム管理者であり、専門知識の欠如により、しば
しば過度な資源を消費する。多くのユーザがソフトウェ
ア導入、アップグレード、及びコンピュータ管理の問題
に奮闘するのではなく、少数のサーバ管理専門家に問題
を効果的に委ねることにより、この問題を排除すること
が有利であると予想される。

【０００３】前述のように、パーソナル・コンピュータ
の将来のこの見通しは、現在ではその幼年期にある。結
果として、現在、既存のシステムにおいては、多くの問
題及び欠点が存在する。

【０００４】通常、ネットワーク・コンピュータ・シス
テムでは、管理者がネットワーク・サーバ上に記憶され
るユーザ・プロファイルを作成する。プロファイルは異
なるタイプの情報を含み、それらには、ユーザ・デスク
トップ選択（preferences）や、サーバ上に存在し得る
異なるソフトウェア・アプリケーションへのアクセスの
ためのユーザ許可などが含まれる。ユーザがシステムに
ログオンするとき、ユーザは自分自身であることをサー
バに識別し、サーバはユーザのプロファイルを突き止
め、それをユーザ・コンピュータに送信する。すると、
プロファイルがユーザ・コンピュータを構成し、デスク
トップを生成する。デスクトップは、ユーザがおそらく
アクセスを有するであろうアプリケーションを表す多数
のアイコンを含み得る。プロファイルはまた、コンピュ
ータ及びデスクトップの他の属性も含み得て、それらは
例えば、デスクトップの背景色や、デスクトップ上で使
用される文字フォント及びポイント・サイズ、或いはデ
ータ・ファイル探索経路など、ユーザにとって固有の属
性である。プロファイルはユーザ変更可能であったり、
変更不能であったりする。

【０００５】ユーザが彼ら自身のプロファイルを変更で
きる環境では、ログオフ時に、変更されたプロファイル
がサーバに逆にアップロードされ、そこでプロファイル
は、ユーザが次にログオンし、検索するときのために記
憶される。一部の従来システムでは、私たちが知る限
り、ユーザは自分自身のデスクトップ上に、自分が希望
するアプリケーション・アイコンの任意の構成を、それ
らがサーバ上に存在するか否かに関わらず、更にユーザ
がサーバ上のアプリケーションに対するアクセス許可を
実際に有するか否かに関わらず生成できる。Lotus Work
place Desktop（以前はKona Desktopと呼ばれた）シス
テムは、このタイプのオペレーションの例である。他の
システムでは、サーバがユーザに対して、サーバが有す
る全てのアプリケーションのリストを提供し、ユーザは
そこから選択することができる。この場合、ユーザがデ
スクトップ上のリストから選択されるアプリケーション
に対するアクセス許可を実際に有する保証はない。Sun
Hot Java Viewシステムは、このタイプのシステムの例
である。換言すると、従来のシステムは、ユーザがデス
クトップ・アプリケーション・アイコンのセットとして
構成可能なものと、ユーザが実際にアクセス許可を有す
るアプリケーションとの間を相関付けない。こうした場
合では、ユーザがアイコンをクリックし、アプリケーシ
ョンを実行するとき、アクセス許可が存在しなければ、
エラー・メッセージ（無許可アクセス・メッセージな
ど）が発生するか、更に不具合な場合には、ユーザのコ
ンピュータがクラッシュし得る。

【０００６】既存の技術の別の制限は、フラット・デー
タ構造が、ユーザ、ユーザ・グループ、端末及び端末の
グループをモデル化するために使用されることである。
コンピュータ資源に対するユーザ・アクセスを管理する
一般的な方法に従ってモデル化され、既知のネットワー
ク・コンピュータの実施例（例えばLotus Administrati
on Facility for Desktops、Microsoft Windows NT Pro
files and Policies、及びSun Hot Java Views）は、サ
ーバ上で様々な状況において、ソフトウェア選択（また
は属性）を管理するためのフラットな"グループ"構造を
実現する。ここでは用語"状況（context）"は、個々の
ユーザ、ユーザ・グループ、端末または端末グループを
指し示す。サーバ上でソフトウェア選択を管理するグル
ープ化構造は、管理者が個々のユーザの他に、異なるユ
ーザのグループの選択属性を定義することを可能にす
る。しかしながら、フラット・システムは多くの環境に
おいて、特に多数のユーザを有する環境において柔軟性
を欠く。従って、選択情報を階層構造に編成することを
サポートする管理ツールを提供することが望ましい。

【０００７】既存のシステムの別の制限は、管理者及び
ユーザがワークステーション・デスクトップのユーザ構
成を実行する方法が制限されることである。例えば、管
理者は現在、ユーザ・アプリケーションとは別の、しか
しながらそれに関連付けられる構成プログラムを用い、
ユーザ選択を構成するように要求される。ベンダが１つ
のアプリケーションだけを提供することを許可すること
が望ましい。ベンダからエンド・ユーザ・アプリケーシ
ョンだけを要求することは、中央管理機構がユーザまた
はユーザ・グループの状況において、エンド・ユーザ・
アプリケーションを実行できることを必要とする。従来
技術は、オペレーションのこの管理柔軟性を可能にしな
い。換言すると、従来技術では、私たちの知る限り、管
理者がユーザの状況において、ユーザ・アプリケーショ
ンを実行し、そのユーザ及びアプリケーションに対する
選択をセットする能力を有さない。更に、従来技術で
は、管理者がユーザのグループの状況において、ユーザ
・アプリケーションを実行し、選択をセットすることは
できない。

【０００８】本発明者が知るところの従来技術の更に別
の制限は、従来技術がサーバ永久記憶空間を区分化し、
サーバ上の異なるアプリケーションに関連するユーザ選
択を記憶するために、固有の空間が確保されるように保
証する方法である。本発明者の知る限りでは、オブジェ
クトを固有に識別し、他のクラスから区別する完全修飾
クラス名が問い合わされるオブジェクト指向システムに
おいて、記憶装置内で異なるアプリケーションの選択情
報の衝突を回避する問題が、次のように、すなわち第１
の中央当局がベンダに当てはまる固有の指定を割当て、
次にベンダにおける第２の当局が、各ベンダ・アプリケ
ーションに対して、第１の指定に関連する第２の指定を
割当てることにより解決される。例えば、ベンダＡは第
１の当局によりベンダＡ指定を割当てられ、その指定が
第１の当局が作用するアーキテクチャ内で固有であるこ
とが保証される。次に、ベンダＡの第２の当局が、その
アーキテクチャ内のアプリケーションの各々に対して、
第２の指定を割当てる。例えば、ベンダＡのアプリケー
ションの１つが、vendorA. App1と指定され、別のアプ
リケーションがvendorA. App2と指定される。従来技術
は、システム内の各アプリケーションに対する固有の指
定を、システムの永久記憶装置のある位置にマップし、
異なるアプリケーションに対するその選択データが、記
憶装置内で衝突しないように保証する。アプリケーショ
ンは実行中に、ネットワーク・コンピュータ・サーバに
その固有記憶位置を知らせ、サーバは異なる状況におい
て選択情報が衝突しないように、状況（ユーザ、ユーザ
・グループ、端末または端末グループ）に従い、開始位
置において選択情報を記憶する領域を区分化する。明ら
かに、記憶空間を管理するこの方法は不便で、好ましく
ない。記憶装置内での選択情報の衝突を回避するため
に、中央当局に固有の指定を割当てさせることに頼るこ
となく、また記憶位置情報をアプリケーションにコーデ
ィングすることなく、前述のオブジェクト指向アプリケ
ーションにおいて、選択情報を記憶する固有の記憶位置
を自動的に生成する方法を提案することが望まれる。

【０００９】従来技術の更に別の制限は、既存のハード
ウェア及びアプリケーションの変更を要求することな
く、それらを集中的に管理されるネットワーク・コンピ
ュータの世界の新たな環境に移行するための準備に欠け
る点である。ネットワーク環境内の既存のハードウェ
ア、例えば端末は、ブートアップ時に、サーバ上に配置
される特定の形式のファイルから、その構成情報を獲得
する。端末はその構成ファイルのアクセス方法を知るよ
うにプログラムされる。端末は特定の識別子を用い、サ
ーバからファイルをアクセスする。固有の識別子はしば
しば、端末の媒体アクセス制御（ＭＡＣ）アドレスであ
る。しかしながら、端末が設計されたのとは異なるプロ
トコル及びＡＰＩに関わる新たな集中管理型環境では、
その端末は新たな環境において選択情報をアクセスでき
ず、端末はその構成ファイルを、それが設計されたよう
にアクセスできるだけである。これは重大な問題であ
る。なぜなら、こうした多くの既存の装置が使用されて
いるからである。新たなシステムにおいてそれらを使用
できないことは、実質的にユーザが新たなシステムに移
行しようとするインセンティブを妨げるものである。

【００１０】従来技術の更に別の制限は、管理者と構成
管理システムとの間のインタフェースに関する。管理機
構内で、様々なユーザ及びユーザ・グループ、及び端末
及び端末グループに対して選択情報を構成するために、
ソフトウェアを構成するとき、管理ソフトウェアが、機
構を実行している管理者によりセットされる状況（ユー
ザ、ユーザ・グループ、端末または端末グループ）にお
いて始動する。管理者がアプリケーションが実行されい
ている状況を変更するとき、アプリケーションは新たな
状況に対する構成情報をロードするために、再始動され
る必要がある。状況が変更される都度、ソフトウェアを
再始動するプロセスは、管理者にとって時間がかかり、
不便であり、このことは特に多くのユーザを有するシス
テムにおいて当てはまる。こうしたシステムでは、管理
者がアプリケーションを構成する間に、何度も状況を変
更することが予想される。

【００１１】

【発明が解決しようとする課題】中央アプリケーション
管理を有し、既存のハードウェア及びアプリケーション
をシステムに適応させるエクスポート・エージェント機
能を提供するクライアント−サーバ・システムを提供す
ることである。

【００１２】

【課題を解決するための手段】ここで述べられるシステ
ムは、クライアント−サーバ環境において、ユーザ及び
アプレットのための情報を構成する共通のリポジトリを
提供する。これはクライアント・プロファイル管理と呼
ばれる。本システムはユーザが放浪（roam）すること、
すなわちいつでもシステム内の任意のコンピュータから
ログインし、それを実行時に、ユーザのためにサーバに
記憶された選択に従い自動的に構成することを可能にす
る。好適な実施例はＪａｖａ（Ｊａｖａはサン社の商
標）ベースのシステムであり、クライアント・コンピュ
ータが、Ｊａｖａアプリケーションを実行するように編
成されたウェブ・ブラウザ・インタフェースを使用す
る。従って、好適な実施例では、ユーザ・アプレット及
びデスクトップ・アプレットがＪａｖａアプレットと仮
定される。しかしながら、このことは本発明をＪａｖａ
環境に制限することを意図するものではない。局所的に
記憶されたアプリケーションのための選択は、従来通り
局所的に記憶され得、サーバ・ベースのアプレットのた
めの選択が、ここで述べられるように処理され得る。

【００１３】本発明は、既存のハードウェア及びソフト
ウェアのベンダが、ハードウェアを新たなファームウェ
アにより改造する必要なく、または既存のソフトウェア
を再設計する必要なく、ハードウェアまたはソフトウェ
アを集中管理ネットワーク・コンピュータ・システムの
環境に統合することを可能にする手段を提供する。本シ
ステムは、システム管理者が、既存のハードウェアまた
はソフトウェアが期待する形式で、構成ファイルを生成
し、既存のハードウェアまたはソフトウェアがその設計
に従いファイルをアクセスする通り、ファイルをサーバ
に記憶することを可能にするエクスポート・サービスを
提供する。エクスポート・サービスを利用するために、
ハードウェア・ベンダ、例えば既存の端末のベンダは、
特殊な構成アプリケーション及びエクスポート・エージ
ェント・モジュールを作成する。特殊な構成アプリケー
ションがシステム管理者ステーションにおいて実行さ
れ、管理者がハードウェアのための構成情報を作成する
ことを可能にする。エクスポート・エージェント・モジ
ュールがサーバ上に存在する。ベンダ供給される構成ア
プリケーションが管理者により実行され、構成アプリケ
ーションにより生成された構成情報をサーバ上に保管す
る要求が発行されるとき、サーバに対する保管呼び出し
が、サーバに指定エクスポート・エージェントを呼び出
すように命令するエクスポート・タグ・パラメータを含
む。エクスポート・エージェントは、構成アプリケーシ
ョンから構成情報を受け取り、その形式をハードウェア
により要求される形式に変更する。更に、構成される状
況がエクスポート・エージェントに転送される。状況
は、構成されるハードウェアの特定のインスタンスに固
有の情報を含み、これは通常、ハードウェアの媒体アク
セス制御アドレスであり、エクスポート・エージェント
に、変更された構成を含むファイルを記憶する場所を示
す情報を提供する。従って、ファイルはハードウェアの
他のインスタンスに対する類似の情報と衝突せず、設計
通りに、ハードウェアの一部により、サーバから直接ア
クセスされ得る。既存のソフトウェア・アプリケーショ
ンもまた同様に、再設計無しに、システム内に改造され
得る。

【００１４】好適な実施例では、システムがサーバ及び
複数のユーザ・ステーションを相互接続するネットワー
クを含む。サーバは、ユーザ・ステーションにダウンロ
ードされる複数のエンド・ユーザ・アプリケーションを
記憶し、更に、ユーザの異なるグループ及びサブグルー
プの状況における、エンド・ユーザ・アプリケーション
に対する構成選択を記憶する。プロファイル・マネージ
ャが、管理者ステーションにおいて提供される。プロフ
ァイル・マネージャは、非ネイティブ・ステーションま
たはアプリケーションに対して、構成アプリケーション
を実行するように編成され、それにより管理者は、シス
テム・ユーザの異なるグループ及びサブグループの状況
において、非ネイティブ・ステーションまたはアプリケ
ーションに対する構成選択を指定できる。構成アプリケ
ーションに対応するエクスポート・エージェントもま
た、サーバに提供される。エクスポート・エージェント
は、プロファイル・マネージャにより、非ネイティブ・
ステーションまたはアプリケーションに対して、選択情
報をサーバ上に記憶する要求が発行されるとき呼び出さ
れる。エクスポート・エージェントは選択情報を、非ネ
イティブ・ステーションまたはアプリケーションと互換
の形式に再フォーマットし、再フォーマットされた情報
を、非ネイティブ・ステーションまたはアプリケーショ
ンによる直接アクセスのために、非ネイティブ・ステー
ションまたはアプリケーションに知られたサーバ上の位
置に記憶する。

【００１５】

【発明の実施の形態】ここで述べられるシステムは、ク
ライアント−サーバ環境内の全てのユーザ及びアプレッ
トの構成情報の共通のリポジトリを提供する。これはク
ライアント・プロファイル管理と呼ばれる。本システム
はユーザが放浪（roam）すること、すなわちいつでもシ
ステム内の任意のコンピュータからログインし、それを
実行時に、サーバに記憶された選択に従い自動的に構成
することを可能にする。好適な実施例はＪａｖａ（Ｊａ
ｖａはサン社の商標）ベースのシステムであり、クライ
アント・コンピュータがＪａｖａプログラムを実行する
ように編成されたウェブ・ブラウザ・インタフェースを
使用する。

【００１６】用語"アプレット（applet）"及び"サーブ
レット（servlet）"は、Ｊａｖａプログラミング言語に
おいて確立された用語であり、当業者には理解できるの
で、本明細書において使用することにする。"アプレッ
ト"は、Ｊａｖａにより動作するウェブ・ブラウザ内で
実行される独立のソフトウェア・モジュールを指し示
す。"サーブレット"は、Ｊａｖａにより動作するウェブ
・サーバ上に存在するソフトウェア・モジュールを指し
示す。ここでの"アプレット"及び"サーブレット"の使用
は、少しも本発明を制限することを意図するものでな
い。明確化のため、ここでは語句"構成アプレット"が、
ワード・プロセッサやデータベース・マネージャなど
の、エンド・ユーザ・ソフトウェア・アプリケーション
の選択を構成するために使用されるソフトウェア・モジ
ュールを指し示すために使用される。ソフトウェア・ア
プリケーションもまた、Ｊａｖａ環境内の"アプレット"
であるので、ここでは語句"ユーザ・アプレット"または
単に"アプレット"が、エンド・ユーザ・アプリケーショ
ンを指し示すために使用される。

【００１７】好適な実施例では、ユーザ・アプレット及
びデスクトップ・アプレットがＪａｖａアプレットと仮
定される。しかしながら、本発明はＪａｖａ環境に制限
されるものではなく、任意のクライアント−サーバ・シ
ステムにおいて使用され得る。例えば、本システムは要
望に従い、プロプラエタリ（proprietary）通信プロト
コル、及び任意の所望のプログラミング言語で作成さ
れ、コンパイルされたアプリケーションを使用するよう
に設計され得る。更に、好適なＪａｖａベースの環境で
あっても、ディスク・ベースのコンピュータが一部のア
プリケーションを局所的にアクセスし、他のアプレット
をサーバからアクセスできる。局所的に記憶されたアプ
リケーションの選択が、従来通り、局所的に記憶され、
サーバ・ベースのアプレットの選択が、ここで述べられ
るように処理され得る。しかしながら、好適には、局所
的に記憶されたアプリケーションの選択が、ここで述べ
られるサーバ・ベースのアプレットの選択に加え、プロ
ファイル管理属性ＡＰＩを用いて、サーバ上に記憶され
る。

【００１８】アプレットがユーザまたは管理者により実
行されるとき、ＡＰＩに作成されたアプレットが、選択
データを容易に記憶及び検索することを単純なアプリケ
ーション・プログラム・インタフェース（ＡＰＩ）が可
能にする。アプレット許可及びユーザ選択が、グループ
・メンバーシップ及び個々の識別にもとづき定義され得
る。

【００１９】クライアント・プロファイル管理は次のサ
ービスを含む。すなわち、 ・ログオン・サポート−ユーザ・プロファイルへのマッ
ピング。 ・ユーザ・サポート−ユーザ識別を作成し、サービス及
び選択を直接ユーザに提供する管理能力。 ・ユーザ・グループ・サポート−ユーザの階層グループ
を作成し、グループ・メンバーシップにもとづき、サー
ビス及び選択を提供する管理能力。 ・ユーザ・アプレット状況透過性−ユーザ・アプレット
実行の状況の自動決定。すなわち、ユーザ・アプレット
実行に当てはまるユーザ・プロファイルまたはグループ
・プロファイルの決定、及びプロファイル環境の自動確
立。 ・ユーザ・アプレット選択リポジトリ−ユーザ・アプレ
ット構成データのための状況依存（context-sensitiv
e）サーバ記憶装置。 ・動的ユーザ・アプレット選択継承−継承のオブジェク
ト指向プリンシパルを介する、ユーザ・アプレット選択
の階層ロード時間の合体。 ・ユーザ・アプレット・アクセス制御−グループ・デフ
ォルト・メンバーシップ特権にもとづく、ユーザ・アプ
レット実行の制御。管理者はデフォルト・グループ特権
をオーバライドし、個々のユーザのための追加のアクセ
ス特権を許可または拒否する。

【００２０】プロファイル管理は、これらのタスクが実
行されるフレームワークを提供する。一部のタスク、例
えばユーザ／グループ管理、アプレット・リスト、状況
切替え、及び選択継承などは、プロファイル管理により
直接サポートされる一方、ユーザ・アプレット特有の構
成サービスは通常、クライアント・プロファイル管理環
境内でシステム管理者により呼び出される別々の構成ア
プレットによりサポートされる。一部のエンド・ユーザ
・アプレットは、構成機能をエンド・ユーザ・アプレッ
トの一部として提供する。この場合、管理者は（別々の
構成アプレットではなく）エンド・ユーザ・アプレット
を、個々のユーザ及びグループの状況において実行し、
それらのユーザ及びグループの構成選択をセットする。

【００２１】図１は、本発明を実現するように意図され
た環境のハイ・レベル図である。ネットワーク１００
は、デスクトップ・パーソナル・コンピュータ１０２、
モバイル・ラップトップ・コンピュータ１０４、ワーク
ステーション１０６（例えばＲＩＳＣコンピュータ）、
管理者のステーション１０８及びサーバ１１０などの、
複数のユーザ・ステーションを相互接続するために提供
される。１実施例では、ネットワーク１００はローカル
・エリア・ネットワークである。別の実施例では、ネッ
トワーク１００は、地理的に転置された地点をシステム
内に含んで有する企業などのエンティティのための広域
ネットワークを含み得る。本発明が実現され得る環境を
制限する意図はなく、実際、多くのタイプのステーショ
ンを相互接続する任意のタイプのネットワークが考えら
れる。

【００２２】プロファイル管理の管理動作環境のハイ・
レベル図が、図２に示される。管理クライアント・ネッ
トワーク・コンピュータ２００が図の左側に、またシス
テムのためのサーバ２０２が右側に示される。クライア
ントとサーバは、２０３で示されるネットワークを介し
て通信する。図２の特定の例では、クライアント・コン
ピュータがシステム管理者のコンピュータであることを
想定する。

【００２３】クライアント側のプロファイル・マネージ
ャ２０６は、管理者がユーザ・レベル及びグループ・レ
ベルの両方において、ユーザ・アプレット選択を構成す
ることを可能にする。管理者は新たなユーザ階層及びグ
ループ階層を作成し、ユーザを異なるグループに追加
し、各グループ及び個々のユーザに対して、アプレット
許可を指定する。そして管理者は個々のユーザまたはグ
ループの状況において、アプレットを構成することがで
きる。管理者はユーザのパスワードを追加、消去及びリ
セットすることができる。プロファイル管理サポート
は、一般ユーザにとって透過的である。管理者は任意の
ユーザまたはグループの状況において、プロファイル・
マネージャ２０６を呼び出す。管理者だけが自分の状況
から変化し、クライアント（ユーザ）及びグループを管
理することができる。サーバは管理権限の無いユーザ
が、状況を切り替えることを可能にしない。要求がサー
バに到来すると、サーバはこの機能をアクセスしようと
しているユーザの認証ＩＤを問い合わせる。ユーザが管
理権限を所有しない場合（すなわち、AllUsers. Admini
stratorグループのメンバでない場合）、プロファイル
・マネージャ・サーブレット２１４がこの要求を拒絶す
る。

【００２４】プロファイル・マネージャ２０６は、図２
に示されるように、アプレット１（２０８）などの他の
アプレットを呼び出す。この例では、アプレット１はユ
ーザ・デスクトップに関連する選択を構成する管理アプ
レットである。或いは、アプレット１は、エディタ、ワ
ード・プロセッサ、データベースなどの、エンド・ユー
ザ・アプレットに関連する構成ユーティリティである。
２０８などの構成アプレットが、それらの対応するユー
ザ・アプレットとは別のモジュールとして存在すること
が好ましい。図２の状況では、アプレット１は通常、ユ
ーザ・アプレットのための構成アプレットである。すな
わち、管理者がグループ状況の下で、構成アプレットで
あるアプレット１を実行し、グループ選択及び許可デフ
ォルト指定をセットするか、ユーザ状況において、ユー
ザ・アプレット構成を個人用にカストマイズする。アプ
レット１をそのユーザ・アプレットとは別のモジュール
として実現することにより、性能が向上される。なぜな
ら、構成アプレット１はユーザ・アプレットに比較し
て、おそらく小さいからである。また、別の構成アプレ
ットは、エンド・ユーザがユーザ・アプレットを構成す
る能力を、管理者が制御することを可能にする。

【００２５】従来の独立型コンピュータは、ユーザ・ア
プレット構成情報をそのユーザ・アプレットと関連し
て、局所的に記憶する。従来の独立型Ｊａｖａベースの
コンピュータは、ユーザ・アプレット構成情報を、jav
a. util. Propertiesクラスにより提供されるフォーマ
ットを用いて記憶する。両者の構造は、ユーザ・アプレ
ットが、そのユーザ・アプレットに関連する構成情報を
記憶するローカル・ファイルの名前を指定することを要
求する。換言すると、コンピュータとその上にロードさ
れるユーザ・アプレット間の関係が要求される。ここで
述べられるプロファイル管理は、実際のjava. util. Pr
opertiesオブジェクトの既知の機能に加え、ユーザ放浪
機能をサポートする追加の機構、及び強力な管理フレー
ムワーク（プロファイル・マネージャ）へのシームレス
な接続可能性を提供する。

【００２６】プロファイル管理属性（ProfileManagemen
tProperties）Ｐ（２１０）は、アプレット１の属性オ
ブジェクトであり、アプレット１とサーバ間のＡＰＩを
提供し、これはサーバがユーザ及びグループの状況にお
いて、アプレット１の構成情報を記憶する場所を決定す
ることを可能にする。プロファイル管理属性オブジェク
ト・クラスは、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グループがAl
lUsers. GroupXの親である）からのアプレットに対する
選択の合体セットである。グループが親を有さない（す
なわち、トップ・レベルAllUsersグループである）場
合、そのグループに対するデフォルト指定は存在しな
い。ある状況において、アプレットに対する選択を合体
するために、その状況にて明示的に記憶されたアプレッ
トの選択が、その状況におけるアプレットのデフォルト
選択を上書きする。従って、グループ状況において、選
択をアプレットのデフォルト・セットに合体するため
に、各グループ・ノードからAllUsersグループに至るま
で、アプレットに対する各親の選択のセットを要求する
再帰呼び出しが発行される。次の例を示す図３を参照さ
れたい。例えば、状況がAllUsers. GroupY. GroupY1の
場合、アプレットに対するそのデフォルト選択を要求す
る呼び出しが、GroupＹ１の親、すなわちGroupＹに発行
される。GroupＹ１はその親であるAllUsersに、再帰呼
び出しを発行する。AllUsersは親を有さないので、Grou
pＹからの呼び出しに対して、AllUsersはアプレットに
対する選択のセットを返却する。この選択のセットは、
GroupＹにアプレットに対して記憶される選択が存在す
れば、それにより変更される。これが今後、GroupＹ１
の状況における、アプレットに対する選択のデフォルト
・セットとなる。このデフォルト選択のセットが、Grou
pＹ１からGroupＹへの再帰呼び出しの結果として、Grou
pＹ１に返却され、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選択が、選択ツリーのAllUser
s. GroupX分岐から獲得された、デフォルト指定のＢＧ
＝Blue選択をオーバライドするからである。

【００３６】例３：User１の状況における、com. ibm.
App6に対する選択の合体。

【００３７】この例は、最も高い優先グループの状況
が、User１の状況における合体選択を含まないことを示
す。再度、User１に対する最も高い優先グループはGrou
pＸである。このグループ及びその親AllUsersは、Ａｐ
ｐ６に対する選択を含まない。従って、次に高い優先グ
ループが探索される。User１に対する次に高い優先グル
ープは、GroupＹ１である。選択セットがＡｐｐ６に対
するこのグループから獲得され得る。選択の合体が例１
で述べたように進行する。再帰呼び出しがGroupＹ１か
らツリーを遡り、ルートAllUsersグループに発行され、
選択セットが再帰呼び出しの下流に返却されて、途中変
更され、デフォルト・セットが形成される。デフォルト
・セットが次に、GroupＹ１に記憶された選択により変
更され、この状況に当てはまる選択の合体セットを形成
する。要するに、AllUsersはＡｐｐ６に対する選択を有
さないので、選択のヌル・セットを返却する。GroupＹ
はこのヌル・セット値をａ＝１及びｂ＝２により変更
し、このセットをデフォルト・セットとしてGroupＹ１
に返却する。GroupＹ１はデフォルト・セットをａ＝３
３により変更する。このセットがUser１状況に返却さ
れ、そのデフォルト・セットとして使用される。User１
状況には、Ａｐｐ６に対する選択は記憶されていないの
で、選択ツリーのGroupＹ１分岐から獲得されるデフォ
ルト指定は、Ａｐｐ６に対する完全に合体された選択セ
ットを表す。従って、選択の実際のセットは、この状況
に対してａ＝３３、ｂ＝２となる。

【００３８】前述の３つの例は、特定のソフトウェア部
分としてのload（）に応答して、選択を収集することに
ついて述べた。選択情報がソフトウェア部分に対して保
管されるとき、保管される状況にて明示的に作成された
あらゆる選択が、ソフトウェアが実行されている状況
と、選択が記憶されているソフトウェアのキーとの組み
合わせにより指定される、データ記憶装置２１２内の位
置に書込まれる。

【００３９】許可も同様に動作する。すなわち、新たな
グループは、グループ自体により許可される全てのアプ
レット名へのアクセスの他に、そのスーパグループによ
り許可される全てのアプレットへのアクセスを有する。
しかしながら、プログラマがスーパクラス・メソッドを
オーバライドすることをＪａｖａが可能にするのと同
様、プロファイル管理は、システム管理者が継承された
許可をオーバライドすることを可能にする。これは許可
のオーバライドと呼ばれる。

【００４０】Ｊａｖａの継承形式同様、プロファイル管
理の選択及び許可継承の形式は、単一継承と呼ばれる。
単一継承は、各プロファイル管理グループが１つのスー
パグループだけを有することを意味する（任意の所与の
スーパグループが複数のサブグループを有し得る）。

【００４１】プロファイル管理ユーザ（葉ノード）は、
複数のグループ内のメンバーシップを要求できる。従っ
て、機構は、グループ間分岐合体により導入される非互
換の可変サブセットの導入による、不正な構成の機会を
最小化するために、選択継承を単一の階層グループに制
限することを要求される。ユーザのグループ・メンバー
シップの優先順位付けを可能にすることにより、プロフ
ァイル管理は探索順序に従い、特定のアプレットに関連
する選択を探索する。換言すると、探索は最も高い優先
順位のグループから開始し、その選択をロードしようと
しているアプレットの構成データを含むことが判明した
最初のグループで停止する。

【００４２】ユーザはグループ・メンバーシップからソ
フトウェア許可を継承する。慎重な企業モデル化によ
り、管理者はパネルを移動する必要無しに、１度に１ユ
ーザのペースでソフトウェア・アクセスを多くのユーザ
に割当てる。プロファイル管理は、ウェブ・サーバがア
プレットへのアクセスを許可／拒否するようにプログラ
ムすることにより、アクセスを制御する。ウェブ・サー
バはアクセス制御を実施する。プロファイル・マネージ
ャ・サーブレットもまた、ウェブ・サーバが認証の目的
で、ウェブ・サーバへのユーザＩＤ及びパスワードの転
送を要求することにより保護される。ユーザ・パスワー
ドを催促することは、標準のブラウザ機能である。

【００４３】図５は、図２のシステムの詳細を示す。構
成アプレットであるアプレット１が、プロファイル管理
フレームワーク内の管理者により呼び出される。アプレ
ット１は、その動作環境に関する情報（例えば、照会状
況、状況変更事象、この状況のための照会アクセス制御
リストなど）を問い合わし、プロファイル管理フレーム
ワーク内でしっかり統合するための、アプリケーション
・プログラム・インタフェース（ＡＰＩ）５１５を実現
できる。しかしながら、これは構成アプレットに対する
要求ではない。いずれにしろ、アプレット１の設計者
は、java. util.Propertiesオブジェクト内にまたはそ
こから、選択情報を獲得するために使用されるjava. ut
il. Propertiesオブジェクトの基本メソッドに加え、基
本ＡＰＩメソッド、すなわちenablePersistence（）、l
oad（）、及びsave（）を理解するだけでよい。ＡＰＩ
５１５は更に、list（）メソッド及びgetContext（）メ
ソッドを提供する。アプレット１は、プロファイル管理
属性クラスに登録され、これらのメソッドを適宜呼び出
すだけでよい。load（）メソッドは、管理者により選択
されるユーザまたはグループの状況において構成される
ユーザ・アプレットに対する、選択の現状態を検索する
ために呼び出される。管理者は次に、選択を望まれるよ
うに変更し、それらをアプレットにより提供される構成
保管機能（プロファイル管理属性オブジェクトのsav
e（）メソッド）を用いて記憶する。同様に、アプレッ
ト１が、ユーザによるアクセスに対して許可されたユー
ザ・アプレットのリストを必要とする場合、それはlist
（）メソッドを用い、サーバからリストを獲得する。ge
tContext（）メソッドは、アプレットが実行されている
状況の名前を表示するために、或いはアプレットが特定
の状況においてのみ実行されることを保証するために使
用される。（すなわち、アプレットがエクスポート・エ
ージェントを用い、サーバ上でサービスを構成したい場
合、アプレットはそれ自身がAllUsers状況においてのみ
実行されることを可能にする。なぜなら、エクスポート
される構成が、ユーザ特有ではなしに、サーバ特有であ
るからである。）アプレット１がプロファイル管理フレ
ームワーク内で実行されるために要求される全てのこと
は、アプレットがプロファイル管理属性５１０に登録さ
れ、java.util. Propertiesクラスの拡張であるプロフ
ァイル管理属性クラスを実現することである。

【００４４】プロファイル・マネージャ５０６はまた、
構成アプレットのための状況変更ＡＰＩ５１６を提供す
る。アプレット１は状況変更事象リスナ５１２を実現す
る。ＡＰＩ５１６及び事象リスナ５１２は、管理者が構
成アプレットを実行する間に、それを停止及び再始動す
る必要無しに、状況（ユーザまたはグループ）を変更す
ることを可能にする。例えば、アプレット・ユーザ選択
を構成するとき、管理者は構成の間に、おそらく状況を
何度も変更することであろう。構成アプレットがこうし
た事象のリスナとして登録される場合、プロファイル・
マネージャ５０６はＡＰＩ５１６を介して、リスナに状
況変更を知らせる。このことはアプレット１が各新たな
状況に対して、サーバからその選択をリフレッシュする
ことを可能にする。事象リスナＡＰＩ無しでは、新たな
状況に対する既存の選択情報を参照し、プロファイル管
理アプレットにより停止及び再始動されることを回避す
るために、アプレット１が管理者により終了され、新た
な状況が選択された後、再始動されなければならない。
登録のために、アプレット１はその属性オブジェクトで
あるプロファイル管理属性５１０上のメソッド、すなわ
ち状況変更リスナ追加（addContextChangeListener）
（ＡＰＩ５１６）を呼び出し、自身を登録する。管理者
が新たな状況をセットすると、プロファイル・マネージ
ャ５０６がオブジェクト５１０に状況セット呼び出し
（ＡＰＩ５１６）を実行し、オブジェクト５１０がそれ
に応答して、事象リスナ５１２上の再ロード・メソッド
（ＡＰＩ５１６）を呼び出す。事象リスナ５１２はその
属性オブジェクト５１０に属性ロード呼び出しを実行
し、新たな状況に対する新たな選択データをサーバから
獲得し、アプレット１に新たな選択情報を反映するよう
に、そのＧＵＩ変数及び内部変数を更新するように指示
する。

【００４５】前述の機能は、ネットワーク管理者が１状
況からデータを読出し、状況を変更し、新たな状況にお
いて構成変更を実行する以前に、load（）を意図したつ
もりが、うっかりsave（）により上書きする可能性を回
避する。

【００４６】リスナとして登録されないアプレットは、
管理者が状況変更を強制するとき、プロファイル・マネ
ージャ・アプレットにより停止され、破壊され、再ロー
ドされ、再始動される。

【００４７】プロファイル管理はまた、既存のハードウ
ェア及びソフトウェアを、このプロファイル管理環境に
容易に改造することを可能にする、"属性エクスポート"
・サービスを提供する。属性エクスポート・サービス
は、プロファイル・マネージャ５１４がユーザ・ワーク
ステーション（物理ハードウェア）と、ユーザ、グルー
プ、及びユーザ・アプリケーションをサポートすること
を可能にする。既存のワークステーションはプロファイ
ル管理属性５１０を認識しないので、エクスポート・サ
ービスは、ベンダ・アプレットがその選択情報を保管す
るとき、ワークステーション・ベンダが、サーバ上に呼
び出されるエクスポート・エージェント５２０を指定す
るワークステーション構成アプレットを作成することを
可能にする。エクスポート・タグは、ベンダ供給される
クラスのインスタンス（エクスポート・エージェント５
２０オブジェクト）の作成を指示し、エクスポート・メ
ソッドがオブジェクト上で呼び出されるように指示す
る。エクスポート・メソッドは、ワークステーション構
成情報が、構成されるワークステーションにより要求さ
れるプロプラエタリ・ファイル形式にて、ファイル位置
に保管されるように指定する。

【００４８】アプレット１が、現プロファイル管理シス
テムと非互換の既存の端末に対して、ベンダにより提供
される構成アプレットと仮定する。ベンダはまた、エク
スポート・エージェント５２０を供給する。管理者はプ
ロファイル・マネージャ５０６を実行することにより、
システム内でのオペレーションのために端末を構成し、
構成される端末に状況をセットし、ベンダ供給される構
成アプレット１を実行し、アプレットを構成することが
できる。管理者が構成を保管するとき、サーバに伝送さ
れる情報の一部が、構成される端末を識別する固有の識
別子である。通常、これは端末の媒体アクセス制御（Ｍ
ＡＣ）アドレスである。プロファイル・マネージャ・サ
ーブレット５１４は、エクスポート・エージェントがサ
ーバ上で指定されることを検出する。プロファイル・マ
ネージャ・サーブレット５１４はこれを、エクスポート
・エージェントの必要性を指定するために保管された選
択の１つから検出する。この選択はエクスポート・タグ
を、次のキー値対の形式で指定する。 XXXXEXPORT_AGENTXXXX={エクスポート・エージェントの
完全修飾クラス名}

【００４９】エクスポート・エージェントのエクスポー
ト（Context状況、config属性）・メソッドが、プロフ
ァイル・マネージャ・サーブレット５１４により呼び出
され、保管選択情報から、１つ以上のファイル５２２を
サーバ上に作成する。特定の１つのまたは複数のファイ
ルが、アプレット１から属性情報と共に到来した、端末
の固有の識別子により識別される。端末が後にブートア
ップするとき、端末はプロファイル管理システムとは独
立に、通常行うように、その固有の識別子を用い、その
構成情報をサーバ上で突き止め、ファイル５２２から検
索する。

【００５０】図６は、クライアント・コンピュータ上で
実行されるアプレット２を示す。アプレット２はワード
・プロセッサなどのエンド・ユーザ・アプレットであ
る。いずれにしろ、アプレット２は、図５に５１５で示
される同一のＡＰＩメソッドの一部へのアクセスを有す
る。アプレット２はロード・メソッドにより選択を検索
し、セーブ・メソッドにより、ユーザにより変更され得
るあらゆる選択を保管する。EnablePersistenceは、管
理者に関連して前述したように、アプレット２に対する
プロファイル管理属性オブジェクトを、ユーザに等しい
状況により初期化し、サーバ上の選択情報記憶位置を識
別する固有のキーを生成する。

【００５１】図７は、ユーザが自分のデスクトップを導
出する状況を示す。クライアント７００上のユーザは、
自分のウェブ・ブラウザを、サーバ上のデスクトップ・
アプレットのＵＲＬに差し向け、ステップ７０４で、メ
ッセージhttp://server/Desktop. htmlを送信する。Des
ktop. htmlはサーバが保護するファイルであるので、ス
テップ７０６で、クライアント上のウェブ・ブラウザに
呼び掛け（challenge）が返送される。クライアント上
のウェブ・ブラウザは、ユーザにユーザＩＤ及びパスワ
ードを催促することにより応答する。クライアントは次
にステップ７０８で、ユーザＩＤ及びパスワード情報を
サーバに送信する。ユーザＩＤ及びパスワードが、図８
のステップ７０８で太字で示される。これはこの情報
が、ウェブ・ブラウザ自身により転送されることを示
す。このタイプの命名法は、他の場所でも同一のことを
表すために使用される。おそらく、ユーザはデスクトッ
プ・アプレットを実行する許可を有するので、要求が遵
守される。

【００５２】デスクトップ・アプレットのコードが、サ
ーバからクライアントにロードされるとき、クライアン
トとサーバの間には、一連の対話（図示せず）が存在す
る。ステップ７１２で、デスクトップ・オブジェクトが
作成され、実行を開始する。デスクトップ・オブジェク
トは、その選択情報（すなわち構成情報）を必要とする
ので、オブジェクトはデスクトップを、それを呼び出し
ているエンド・ユーザのために、個別に適合化すること
ができる。この目的のために、デスクトップ・オブジェ
クトの初期化プロセスの一部として、デスクトップはス
テップ７１４で、プロファイル管理属性オブジェクトＰ
を作成し、これがデスクトップ・アプレットに対して、
サーバからユーザの選択情報のコピーをロード、獲得、
キャッシュ、セット、及び保管するために使用される。
デスクトップ・オブジェクトが次にステップ７１６で、
ＡＰＩ呼び出しP. enablePersistence（desktopObject
（applet））を実行する。これはステップ７１６のステ
ップ１で、プロファイル管理属性オブジェクトＰを、プ
ロファイル・マネージャ・サーブレット２１４のＵＲＬ
により初期化する。このＵＲＬは、以前にサーバからロ
ードされたデスクトップ・アプレットのＵＲＬから導出
される。プロファイル管理属性オブジェクトＰは、デス
クトップ・アプレットを実行するユーザの状況を獲得す
るために、要求７１８をプロファイル・マネージャ・サ
ーブレット２１４に送信する。この場合、状況は２つの
要素、すなわちユーザのＩＤに相当する状況名及び状況
タイプを含み、後者はこの場合、Userである。プロファ
イル・マネージャ・サーブレットが、要求７１８からユ
ーザのＩＤを獲得し、ステップ７１９でユーザ状況を返
却する。ステップ７１６のステップ２で、プロファイル
管理属性オブジェクトＰが、デスクトップを実行するユ
ーザの状況により初期化される。ステップ７１６のステ
ップ３で、プロファイル管理属性オブジェクトＰは、Ｊ
ａｖａデスクトップ・オブジェクトＰに、その完全修飾
クラス名を要求することにより、デスクトップ・ソフト
ウェアの固有のキーを生成する。全てのＪａｖａオブジ
ェクトは、それらのクラス名を知っている。この固有の
キーがユーザの状況情報と結合され、デスクトップ・ア
プレットに対するユーザ特有の選択情報を記憶する、デ
ータベース２１２内の固有の位置を指定するパラメータ
を提供する。任意の所望の方法が、完全修飾クラス名及
びユーザ状況情報を含むストリングを、データ記憶位置
にマップするために使用され得る。次に、デスクトップ
・アプレットに対して、ユーザに個別に適合化された選
択情報を獲得するために、要求７２０がプロファイル・
マネージャ・サーブレット２１４に送信される。状況及
びキーが要求７２０の一部として転送され、要求された
選択情報を識別する。プロファイル・マネージャ・サー
ブレット２１４は、ステップ７２２で、要求された選択
情報により応答し、これがプロファイル管理属性オブジ
ェクトＰ（６０４）内にキャッシュされる。

【００５３】図８の説明を続けると、ステップ８００
で、デスクトップ・オブジェクトがそのプロファイル管
理属性オブジェクトＰから、その選択情報を読出し、そ
れに従い、デスクトップの更新を開始する（すなわち、
画面色をブルーにセットし、アイコンの位置に関する情
報を獲得するなど）。デスクトップ・オブジェクトは、
そのプロファイル管理属性オブジェクトＰ上のメソッド
を呼び出し、ユーザがアクセス許可を有するソフトウェ
アのリストを獲得する。プロファイル管理属性オブジェ
クトＰは、ステップ８０２で、プロファイル・マネージ
ャ・サーブレット２１４から情報を要求する。すると、
後者がステップ８０４で、要求された情報により応答を
生成する。ユーザがアクセスを有する各こうしたアプレ
ットに対して、情報はユーザ・フレンドリな名前、アプ
レットのＵＲＬ、アプレットのためのアイコンのＵＲＬ
など（デスクトップがアプレットをデスクトップ上に表
現し、それをロード及び始動するために要求される情
報）、及び本発明に関連しない他の任意選択の資料を含
む。この情報がプロファイル管理属性オブジェクトＰ内
に記憶され、デスクトップ・オブジェクトに返却され
る。ステップ８０６で、デスクトップ・オブジェクトが
アプレット情報を用いて、アプレットのためのフォルダ
を形成し、ユーザがアクセスを有する各アプレットのア
イコン及びユーザ・フレンドリな名前を表示するウィン
ドウを生成する。

【００５４】ユーザによるデスクトップの以前の実行に
おいて、ユーザが前述したフォルダ内に表示される幾つ
かのソフトウェアのアイコンを、ドラッグ・アンド・ド
ロップしたと仮定する。この時点で、ユーザがもはや、
フォルダからデスクトップにドラッグ・アンド・ドロッ
プされたアプレットへのアクセスを有さない可能性があ
る。しかしながら、これらのデスクトップ・オブジェク
トは通常、最後の実行の間に保管され、依然デスクトッ
プ上に表示されるユーザ選択の一部であり得る。この状
況を回避するため、デスクトップはそのプロファイル管
理属性オブジェクトＰからその選択を調査し、ユーザが
アクセスを有する全てのアプレットを表示するために生
成される、ウィンドウの外側に現れるように構成される
アプレットをチェックする。図８は、生成されるアプレ
ット・ウィンドウの外側に、１つのアプレットだけが存
在することを仮定する。アプレット・ウィンドウの外側
に、２つ以上のこうしたアプレットが存在する場合、次
のプロシージャが各こうしたアプレットに対してループ
される。ステップ８１０で、デスクトップが、アプレッ
ト・ウィンドウの外側に現れるこれらのアプレットの各
々を、ユーザがアクセスを有するサーバからのアプレッ
トのリストと照合する。アプレットがリスト内に現れる
場合、ステップ８１０で、アプレットのアイコンがデス
クトップ上に、以前と同一の位置に配置される。ユーザ
がもはやアプレットへのアクセスを有さない場合、ステ
ップ８１４で、アプレットがデスクトップの選択から除
去され、プロファイル管理属性オブジェクトＰから除去
される。任意のアプレットがこのプロセスの一部として
除去される場合、ステップ８１６で、デスクトップがプ
ロファイル管理属性オブジェクトＰに、選択を保管する
ように命令する。プロファイル管理属性オブジェクトＰ
は、新たな選択情報をデータベース２１２に保管するた
めに、要求８１８を選択、キー及び状況情報と一緒に、
プロファイル・マネージャ・サーブレット２１４に送信
する。サーバは応答８２０をプロファイル管理属性オブ
ジェクトＰに送信し、プロファイル管理属性オブジェク
トＰに、要求が成功裡に完了したことを伝える。

【００５５】図９は、管理者が構成アプレットを実行
し、他のユーザまたはユーザのグループのために、選択
を構成する状況を示す。ここで述べる原理は一般に、端
末または端末のグループの構成にも当てはまる。クライ
アント９００上の管理者が、自分のウェブ・ブラウザ
を、実行されるべきサーバ上のプロファイル・マネージ
ャ・サーブレット２１４のＵＲＬに差し向ける。ステッ
プ９０４で、ＵＲＬがサーバに送信される。ProfileMan
ager. htmlはサーバが保護するファイルであるので、呼
び掛け９０６がクライアント上のウェブ・ブラウザに返
送される。ウェブ・ブラウザは、管理者にユーザＩＤ及
びパスワードを催促することにより応答する。ProfileM
anager. htmlを獲得する要求が、ステップ９０８で、メ
ッセージ内に含まれるユーザＩＤ及びパスワードと共
に、サーバに対して繰り返される。おそらく、管理者は
プロファイル・マネージャを実行する許可を有するの
で、要求が遵守され、ステップ９１０で、プロファイル
・マネージャ・アプレットが管理者端末にダウンロード
される。プロファイル・マネージャ・アプレットのコー
ドが、サーバからクライアントにロードされるとき、ク
ライアントとサーバの間には、一連の対話（図示せず）
が存在する。ステップ９１２で、プロファイル・マネー
ジャ・オブジェクトが作成され、実行を開始する。

【００５６】正規のプロファイル管理属性オブジェクト
の代わりに、プロファイル管理属性非状況浮動（Ｐ＿Ｎ
ＣＦ：ProfileManagementProperties_nonContextFloati
ng）オブジェクトが、プロファイル・マネージャにより
使用される。これは１つの例外を除き、プロファイル管
理属性オブジェクトと同様の振舞いを有する。すなわ
ち、選択がロードされ、保管されるとき、それらが管理
者が構成している状況（すなわちユーザまたはユーザ・
グループ）においてロード及び保管されるのではなく、
プロファイル・マネージャを実行している管理者の状況
において、ロード及び保管される。

【００５７】プロファイル・マネージャ・オブジェクト
は、その選択情報（すなわち構成情報）を必要とするの
で、それはプロファイル・マネージャを、それを呼び出
している管理者のために、個別に適合化することができ
る。この目的のために、プロファイル・マネージャ・オ
ブジェクトの初期化プロセスの一部として、プロファイ
ル・マネージャはステップ９１４で、プロファイル管理
属性非状況浮動オブジェクトＰ＿ＮＣＦを作成し、これ
がプロファイル・マネージャ・アプレットに対して、サ
ーバから管理者の選択情報のコピーをロード、獲得、キ
ャッシュ、セット、及び保管するために使用される。プ
ロファイル・マネージャ・オブジェクトが次にステップ
９１６で、P_NCF. enablePersistence（profileManager
Object（applet））を呼び出す。これはステップ９１６
のステップ１で、プロファイル管理属性非状況浮動オブ
ジェクトＰ＿ＮＣＦを、プロファイル・マネージャ・サ
ーブレット２１４のＵＲＬにより初期化する。このＵＲ
Ｌは、プロファイル・マネージャ・アプレットのＵＲＬ
から導出される。プロファイル管理属性非状況浮動オブ
ジェクトＰ＿ＮＣＦは、管理者の状況名（ＩＤ）及び状
況タイプ（ＵＳＥＲ）を獲得するために、要求９１８を
プロファイル・マネージャ・サーブレット２１４に送信
する。プロファイル・マネージャ・サーブレットが、要
求９１８から管理者のＩＤを獲得する。ウェブ・ブラウ
ザは、メッセージ内の管理者ＩＤ及びパスワードを、プ
ロファイル管理属性非状況浮動オブジェクトＰ＿ＮＣＦ
により送信される情報と一緒に転送する。ステップ９１
６のステップ２で、プロファイル管理属性非状況浮動オ
ブジェクトＰ＿ＮＣＦが、アプレットを実行する管理者
の状況により初期化される。ステップ９１６のステップ
３で、プロファイル管理属性非状況浮動オブジェクトＰ
＿ＮＣＦは、Ｊａｖａプロファイル・マネージャ・オブ
ジェクト（profileManagerObject）（enablePersistenc
e呼び出し内のパラメータとして転送される）に、その
完全修飾クラス名（profileManagerObject. getClas
s（）. getName（））を要求することにより、プロファ
イル・マネージャ・アプレットの固有のキーを生成す
る。この固有のキーが管理者の状況情報と結合され、プ
ロファイル・マネージャ・アプレットに対する管理者特
有の選択情報を記憶する、データベース２１２内の固有
の位置を指定するようにマップされる。

【００５８】管理者のために構成されるプロファイル・
マネージャ・アプレットに対して、個別に適合化された
選択情報を獲得するために、要求９２２がプロファイル
・マネージャ・サーブレット２１４に送信される。要求
９２２は、適切な状況名及び状況タイプ、及び適切な選
択情報を識別するキー情報を含む。プロファイル・マネ
ージャ・サーブレット２１４は、要求された選択情報９
２４により応答し、これがプロファイル管理属性非状況
浮動オブジェクトＰ＿ＮＣＦ内にキャッシュされる。プ
ロファイル・マネージャは、プロファイル管理属性非状
況浮動オブジェクトＰ＿ＮＣＦからその選択情報を読出
し、それに従い自分自身を更新する（すなわち、例えば
その背景色をブルーにセットする）。

【００５９】オペレーションは図１０に継続する。プロ
ファイル・マネージャは、既存のユーザ、ユーザ・グル
ープ、及びプロファイル・マネージャ・サーブレット２
１４からのソフトウェアに関する情報を要求し、ステッ
プ１００２で、プロファイル・マネージャ構成ウィンド
ウの左パネル内にツリーを生成する。管理者の左パネル
の例として、図１３乃至図２４を参照されたい。この時
点１００４で、管理者は左パネル・ツリーからユーザま
たはグループをクリックすることにより、構成のために
所望の状況を選択する。プロファイル・マネージャは、
P_NCF. setContext（選択状況）を呼び出すことによ
り、プロファイル管理属性オブジェクトの状況をセット
する。図１３は、全てのシステム・ユーザのグループを
示す"ユーザ・グループ"の選択状況を示す。或いは、図
１８では、"Development"のグループ状況が選択され、
図２１では、ユーザ状況"colleend"が選択される。次に
ステップ１００６で、管理者がサーバ上の全てのアプレ
ットのリストから、構成されるアプレットを選択する。
図１７は、アプレットを選択する例を示す。ステップ１
００８で、管理者は実行／カストマイズ・ボタンをクリ
ックし、構成のために選択されるアプレットを実行す
る。このアプレットは、エンド・ユーザ・アプレットと
は別の構成アプレットであっても、エンド・ユーザ・ア
プレット自身であってもよい。ステップ１００９で、選
択されたアプレットが要求され、ステップ１０１１でサ
ーバからロードされる。ステップ１０１０で、構成アプ
レット・オブジェクトが作成され、実行を開始し、その
プロファイル管理属性オブジェクトＰを生成する。

【００６０】アプレットがエンド・ユーザ・アプレット
とは別の構成アプレットと仮定すると、ステップ１０１
２で、アプレットがP. enablePersistence（構成アプレ
ット・オブジェクト、構成されるアプレットの完全修飾
クラス名）を呼び出す。他方、アプレットが別の構成ア
プレットではなくユーザ・アプレットの場合、呼び出し
はp. enablePersistence（エンド・ユーザ・アプレット
・オブジェクト）である。なぜなら、それは別のアプレ
ットの選択情報ではなく、それ自身の選択情報を構成し
たいからである。現状況は既に、プロファイル管理属性
オブジェクトＰにより知れている。なぜなら、それは以
前に管理者により、管理者のプロファイル管理属性非状
況浮動オブジェクトＰＭ＿ＮＣＦを介してセットされた
からである。プロファイル・マネージャ・サーブレット
２１４の位置は、enablePersistenceがプロファイル・
マネージャのプロファイル管理属性非状況浮動オブジェ
クトＰＭ＿ＮＣＦ上で呼び出されたとき、以前に生成さ
れた。構成アプレットの場合、アプレットの固有のキー
が生成される必要がない。なぜなら、それは構成アプレ
ットにより、enablePersistence呼び出し内のプロファ
イル管理属性オブジェクトＰに転送されるからである。

【００６１】ステップ１０１４で、構成アプレットが自
身をそのプロファイル管理属性オブジェクトＰに、状況
変更リスナとして登録する。前述のように、これはアプ
レットのプロファイル管理属性オブジェクトＰが、アプ
レットに、管理者が状況変更を行うか否かを知らせるこ
とを可能にする。従って、アプレットは新たな状況の選
択情報をロードし、アプレットが終了され、新たな状況
において再始動されることを要求すること無く、新たな
構成情報を反映するように、そのグラフィック・ユーザ
・インタフェースを更新できる。

【００６２】オペレーションは図１１に継続する。ステ
ップ１１０４で、構成アプレットがプロファイル管理属
性オブジェクトＰに、構成されるアプレットに対して、
現状況から選択をロードするように命令する。構成され
るアプレットに対して、管理者により以前に選択された
状況に対して個別に適合化された選択情報を獲得するた
めに、要求１１０５がプロファイル・マネージャ・サー
ブレット２１４に送信される。要求１１０５は、適切な
状況名（管理者が選択した状況）及び状況タイプ（USE
R、USER_GROUP、またはALL_USER_GROUP）、及び適切な
選択情報の位置を指定するキー情報を含む。プロファイ
ル・マネージャ・サーブレット２１４は、ステップ１１
０６で、要求された選択情報により応答し、これがプロ
ファイル管理属性オブジェクトＰ内にキャッシュされ
る。構成アプレットはプロファイル管理属性オブジェク
トＰから選択を獲得し、それに従いそのグラフィック・
ユーザ・インタフェースを更新する。

【００６３】管理者はステップ１１０７でアプレットを
構成し、例えばアプレットにより提供される保管ボタン
をクリックすることにより、変更された選択を保管す
る。このオペレーションの結果、構成アプレットが、そ
のプロファイル管理属性オブジェクトＰ上のsave（）メ
ソッドを呼び出す。プロファイル管理属性オブジェクト
Ｐは、選択、構成されるアプレットの固有のキー、及び
現状況を指定する情報をプロファイル・マネージャ・サ
ーブレット２１４に送信する。プロファイル・マネージ
ャ・サーブレットは、選択情報をデータベース２１２内
の、状況及びキーにより指定される位置に記憶する。

【００６４】ステップ１１０８は、現在状況を変更中の
管理者の例であり、一方構成アプレットは依然実行中で
ある。管理者はユーザまたはユーザ・グループをクリッ
クすることにより、新たな状況を選択する（図１８の管
理者左画面パネル内の新たな状況の例を参照）。状況変
更の結果、プロファイル・マネージャ５０６は、P_NCF.
setContext（選択された新たな状況）を呼び出すこと
により、セット状況メッセージをプロファイル管理属性
オブジェクトＰ（５１０）に送信し、これが次にオブジ
ェクトＰに、再ロード属性ＡＰＩ５１６を介して、事象
リスナ５１２に状況変更を知らせるように指示する。こ
れはステップ１１１０で発生する。ステップ１１１２
で、事象リスナ５１２がload（）呼び出しを実行し、新
たな状況に対する選択を検索し、ステップ１１１８で、
オブジェクトＰが新たな選択により更新される。管理者
は次に、希望に応じて新たな状況に対する新たな選択を
変更し、要求される場合、それらを保管し、必要に応じ
て前述のように新たな状況変更を継続する。

【００６５】図１２乃至図２４は、プロファイル・マネ
ージャ２０６の一部を実行している間の、管理者のワー
クステーションの実際の画面スナップショットを示す。

【００６６】主構成ウィンドウ１２００が図１２に示さ
れる。ウィンドウの左側のツリー図パネル１２０２は、
サーバ上で使用可能な幾つかのサービスの１つとして、
プロファイル管理１２０４を示す。図１２で示されるよ
うに、この項目１２０４が選択されるとき、主ウィンド
ウの右パネル１２０５が、プロファイル管理サービスの
歓迎メッセージを表示する。１２０８などの拡大アイコ
ン及び縮小アイコンが、左パネル内の項目下のサブ項目
の外観を制御するために使用される。１２０８内の"＋"
は"拡大アイコン"と呼ばれ、"プロファイル管理（Profi
le management）"下にサブ項目が存在することを示す。
管理者は拡大アイコン１２０８をクリックすることによ
り、これらのサブ項目を表示でき、その時このアイコン
は"縮小アイコン"（"−"）となる。

【００６７】図１３は、図１２のプロファイル管理項目
１２０４の拡大を示し、その結果、３つのデフォルト指
定のサブ項目、"アプレット（Applets）"１３００、"ユ
ーザ・グループ（User Groups）"１３０２、及び"ユー
ザ（Users）"１３０４が表示される。拡大アイコンはこ
れらの項目が更に拡大され得ることを示す。"アプレッ
ト"１３００は、管理者がサーバ２０２上で使用可能な
ユーザ・アプレットを定義することを可能にし、"ユー
ザ・グループ"１３０２は、管理者が図３のユーザ・グ
ループ・ツリーを作成及び分布させ、グループ選択をセ
ットすることを可能にする。"ユーザ"１３０４は管理者
が新たなユーザを作成し、それらの選択をセットする
か、既存のユーザに対する選択を変更することを可能に
する。図１３に示される例では、"アプレット"１３００
が選択されている。この項目が選択されると、ウィンド
ウの右側のパネル１３０５が、システムに既に定義され
たユーザ・アプレットのリスト１３０６を表示する。１
３０６内で選択されるアプリケーションの属性が、１３
０８に示される。管理者は１３０６内の＜ＮＥＷ＞を選
択し、要求される名前及び位置情報を１３０８内に入力
することにより、新たなアプレットを定義する。既存の
アプレット、"データベース・エクスプローラ（Databas
e Explorer）"が、１３０６内で選択されて示される。
１３０８において、"アプレット名（Applet name）"フ
ィールドがこのアプレット名を表示する。"ＵＲＬ"（ユ
ニバーサル・リソース・ロケータ）フィールドは、サー
バ２０２上のこのアプレットのイントラネットまたはイ
ンターネット・ウェブ・アドレスを表示する。フィール
ド"ｈｔｍｌファイルの完全経路（Complete path of ht
ml file）"は、サーバ２０２のディスク・ディレクトリ
構造内のディレクトリ経路、及びアプレットのファイル
名を表示する。フィールド"完全修飾クラス名（Fullyqu
alified class name）"は、アプレットの完全修飾クラ
ス名を表示する。フィールド"アイコンＵＲＬ"は、ユー
ザのデスクトップ上にアプレットのアイコンを生成する
ために使用される、イメージ・ファイルのウェブ・アド
レスを表示する。残りのフィールドは、呼び出し時にソ
フトウェアにより要求され得る任意選択情報のためのも
のである。コマンド・ボタン１３１０"ファイルからア
プレット・リストをインポート（Import Applet List f
rom File）"は、管理者が既存のテキスト・ファイルか
ら既存のリスト１３０６に、アプレットの定義を追加す
ることを可能にする。ボタン１３１０がクリックされる
と、図１４に示されるウィンドウがポップアップし、管
理者が、追加されるアプレット定義を含むテキスト・フ
ァイルの経路及びファイル名を入力することを可能にす
る。全ての保留の変更を保管するために、管理者はファ
イル１３１２をクリックし、次に保管（図示せず）をク
リックする。

【００６８】左パネル内において、ユーザ・グループ項
目１３０２は、図３の全ユーザ（AllUsers）・グループ
に対応する（"ユーザ・グループ"及び"全ユーザ"はここ
では互換に使用される）。図１５は、"ユーザ・グルー
プ"項目１３０２が選択されたときの、管理者ステーシ
ョンの右パネルを示す。図１５では、ノートブック・パ
ネルが右側に表示され、これは３つのタブ、メンバ・タ
ブ１５１４、サブグループ・タブ１５１６、及びアプレ
ット許可タブ１５１８を含む。図１５では、メンバ・タ
ブが選択されている。メンバ・パネルは、システムに定
義された全てのメンバのログオン識別のリスト１５２０
を含む。新たなユーザ（現在選択されているグループ状
況、すなわち"ユーザ・グループ"へのメンバーシップを
自動的に獲得する）を作成するために、管理者はリスト
１５２０から＜ＮＥＷ＞を選択し、リストの右側の入力
フィールド１５２２に適切な情報を入力し、作成（Crea
te）ボタン１５２３をクリックする。リスト１５２０か
ら既存のメンバが選択されるとき、そのユーザに対して
以前に保管された属性が、１５２２に表示される。これ
らの属性には、選択されたメンバのフル・ネーム、メン
バのシステムＩＤ、パスワード、及び所望のコメントが
含まれる。ＩＤを除く属性は編集可能で、変更は変更
（Modify）ボタン１５２４をクリックすることによりコ
ミットされる（しかし保管されない）。或いは消去（De
lete）ボタン１５２６をクリックすることにより、ユー
ザがシステムから完全に除去され得る。任意の保留の変
更が、リスト１５２０内のエントリを選択し、取り消し
（Undo）ボタン１５２８をクリックすることにより除去
され得る。

【００６９】図１６は、サブグループ（Subgroups）・
タブ１５１６が選択されたときに表示される、管理者の
右パネルを示す。サブグループ・リスト１６２０が、左
パネル内で選択された項目、この例では"ユーザ・グル
ープ"のサブグループである既存のグループを示す。従
って、リスト１６２０は、"全ユーザ"・グループの全て
の直接サブグループを表示する。左パネル内では、"ユ
ーザ・グループ"が拡大されて示される。リスト１６２
０内に示されるサブグループもまた、左パネル内の"ユ
ーザ・グループ"下の拡大項目である。リスト１６２０
内において、ステータス・フィールドは、各サブグルー
プの現ステータス、例えば"！消去（!delete）"、"！変
更（!Modify）"及び"！作成（!Create）"などを示す。
リスト１６２０内の空ステータス・フィールドは、サブ
グループが存在するが、保管される保留のアクションが
存在しないことを示す。"！"記号は、ステータスが保留
である（まだ保管されていない）ことを示す。リスト１
６２０内で選択されたサブグループの属性は、１６２２
内に表される。これらの属性には、サブグループ名及び
サブグループに関する所望のコメントが含まれる。新た
なサブグループを作成するために、管理者はリスト１６
２０から＜ＮＥＷ＞を選択し、１６２２内にサブグルー
プ名及び所望のコメントを入力し、作成（Create）ボタ
ン１６２８をクリックする。すると、"！作成＜サブグ
ループ名＞"（!create<subgroup name>）のエントリ
が、リスト１６２０内に保留のアクションとして現れ
る。全ての保留の変更を保管するために、管理者はトッ
プ・メニュー・バー内のファイル・ボタンをクリック
し、次に保管ボタン（図示せず）をクリックする。

【００７０】図１７は、アプレット許可（Applet Permi
ssions）タブ１５１８が選択されたときに表示される、
右パネルを示す。リスト１７２０はシステムに定義され
た全てのアプレットの全ての名前と、左パネル内で選択
されるグループまたはサブグループ（現"状況"）に対し
て、各アプレットに割当てられる許可ステータス（アク
セスを許可または拒否）を示す。前述の他のノートブッ
ク・ページ同様、感嘆符は示されるステータスが、保管
を保留中の変更であることを示す。図１７では、グルー
プ・"ユーザ・グループ"が、左パネル内に示されるツリ
ー内で選択されており、これは図３に示される"全ユー
ザ（AllUsers）"・グループに対応する。システムの全
てのユーザが、"ユーザ・グループ"・グループ内のメン
バーシップを有するので、リスト１７２０は、システム
に定義される各アプレットに対して、全てのシステム・
ユーザに対して、グローバル・デフォルト許可を示す。
例えば、アプレット・"データベース・エクスプローラ"
に対するデフォルト許可ステータスは、"全ユーザ"・グ
ループに対して、"許可（permit）"（アクセスが許可さ
れることを意味する）である。同様に、アプレット"Ｔ
ＦＴＰ"に対する全ユーザのデフォルト許可ステータス
は、"拒否（deny）"（アクセスが拒否される）である。
管理者はアプレットの許可ステータスを、リスト１７２
０内でそれを選択し、"グループ・アクセス許可（Permi
t group access）"ボタン１７３０または"グループ・ア
クセス拒否（Deny group access）"ボタン１７３２をク
リックすることにより変更できる。更に、選択された状
況に対するアプレットの許可ステータスに関係無しに、
管理者はリスト１７２０からアプレットを選択し、"実
行／カストマイズ（Run/Customize）"・ボタン１７３４
をクリックすることにより、選択された状況の下で、ユ
ーザ・アプレットを実行できる。現状況に対して、以前
にノートブックを示したパネル領域が、実行されるユー
ザ・アプレットにより占有される。ユーザ・アプレット
がたまたま、他のソフトウェアのための構成アプレット
の場合、管理者は（この機能のために提供される構成ア
プレットの固有の機構を通じて、）ソフトウェア選択を
保管することができ、これが次に、選択された状況に対
する、ソフトウェアのデフォルト選択として保管され
る。アプレットがエンド・ユーザ・アプレットの場合、
エンド・ユーザ・アプレットが、別のソフトウェア部分
に対する選択ではなしに、自身の選択をロードし保管す
る以外は、機能は同様である。

【００７１】図１８は、"ユーザ・グループ"下の管理者
左パネル・サブグループ・ツリーの完全な拡大を示
す。"ユーザ・グループ"の直下には、２つのサブグルー
プ、すなわち除去され得ないデフォルト・サブグループ
である"管理者"と、管理者により定義されるサブグルー
プである"ＩＢＭ"とが存在する。"ＩＢＭ"サブグループ
は更に拡大されて、３つのサブグループ、"ハードウェ
ア（Hardware）"、"サービス（Services）"及び"ソフト
ウェア（Software）"を含む。"ソフトウェア"・サブグ
ループは拡大され、"開発（Development）"と呼ばれる
少なくとも１つのサブグループを含む。"開発"サブグル
ープは、ＮＣｏＤと呼ばれる少なくとも１つのサブグル
ープを含む。サブグループ"ＮＣｏＤ"は、子を有さない
ConfigＦＷ５８などの多数のサブグループを含む。この
例ではまた、サブグループ"開発"が拡大ツリー内で選択
されている。"開発"はツリー階層の最上部（"全ユーザ"
・グループ）ではないので、右パネル内に示されるノー
トブックは、"ユーザ・グループ"が選択されたときの図
１５のそれとは幾分異なる。なぜなら、全ユーザは"ユ
ーザ・グループ"のメンバであり、自動的に"開発"のメ
ンバではないからである。リスト１８２０は全システム
・メンバのログオン・システムＩＤを表示する。リスト
１８２０内の各ユーザＩＤの隣のステータスは、ユーザ
が"開発"サブグループ内のメンバーシップを所有するか
否かを示す。ステータス"ｙｅｓ"は、ユーザが"開発"サ
ブグループのメンバであることを示し、"ｎｏ"はユーザ
が"開発"サブグループのメンバでないことを示し、"継
承（inherited）"は、ユーザがツリーの更に下流の開発
のサブグループの少なくとも１つに属することによ
り、"開発"サブグループ内のメンバーシップを継承する
ことを示す。サブグループに対するユーザのメンバーシ
ップ・ステータスが、管理者がリスト１８２０内のユー
ザを選択し、"グループに追加（Add to group）"ボタン
１８３６または"グループから除去（Remove from grou
p）"ボタン１８３８をクリックすることにより変更され
る。管理者が新たなシステム・ユーザを作成したいか、
既存のメンバを変更または消去したい場合、管理者は"
作成／変更／消去（Create/Modify/Delete）ユーザ"・
ボタン１８４０をクリックする。このアクションは、図
１９に示されるノートブック・ページを導出する。図１
９の右パネルは、図１５のそれと類似であり、管理者が
リスト１９２０内の＜ＮＥＷ＞を選択し、次に"作成"ボ
タンをクリックすることにより、新たなシステム・ユー
ザを作成することを可能にする。同様に、管理者は、リ
スト１９２０内の適切なユーザを選択し、適切なボタ
ン"変更"または"消去"をクリックすることにより、既存
のシステム・ユーザを変更または消去することができ
る。任意のサブグループ状況（例えば"開発"）において
作成されたユーザは、"ユーザ・グループ"内の要求メン
バーシップを獲得するだけでなく、自動的に選択サブグ
ループのメンバを形成する。システム・ユーザ・リスト
の変更は、右パネルのトップ・メニュー・バー内の"フ
ァイル"をクリックし、次に"保管"（図示せず）をクリ
ックすることにより保管される。

【００７２】図２０は、図１９に示されるグループ経路
及びサブグループ経路を通じてではなく、直接システム
・ユーザ・リストに編集のために達する方法を示す。図
２０に至るために、管理者は例えば、図１３の左パネル
内の"ユーザ（Users）"１３０４を選択する。次に、図
２０に示される右パネル内において、管理者はグループ
またはサブグループの状況に留まることなく、前述した
ように、新たなユーザを作成し、既存のユーザを変更及
び消去することができる。

【００７３】図２１では、管理者が、"colleend"のＩＤ
を有するユーザに対応する情報に、直接働きかけること
を希望する。これを実行するため、管理者は図示のよう
に、例えば図２１の左パネル内で"ユーザ"を拡大し、次
に"colleend"を選択する。すると、colleendのシステム
情報に捧げられる右パネルが現れる。右パネルは３つの
タブを含む。第１のタブ"ユーザ情報（User infomatio
n）"は、デフォルト指定により選択される。このタブ内
で、管理者はcolleendに関わる名前、ＩＤ、パスワード
及びコメントを変更できる。

【００７４】図２２は、管理者が第２のタブ"グループ
・メンバーシップ（Group Memberships）"を選択すると
きの右パネルを示す。リスト２２２０は、colleendがメ
ンバである全てのサブグループを示す。サブグループが
このリスト内で、colleendに対するそれらの優先順位の
順に示される。管理者はサブグループを選択し、リスト
２２２０の右側の上矢印及び下矢印を用いて、選択され
たサブグループをリストの上方または下方に移動するこ
とにより、colleendのサブグループ優先順位を変更でき
る。管理者が、図２２内の"グループ・メンバーシップ
追加／除去（Add/Remove Group Memberships）"ボタン
２２４２をクリックすると、右パネルが図２３の内容を
示す。図２３の右パネルは、管理者がcolleendがメンバ
であるサブグループを変更することを可能にする。管理
者はこれを、所望のサブグループに対応する適切なボッ
クスをクリックすることにより実行する。ボックスが空
の場合（colleendが現在メンバでないことを意味す
る）、チェック・マークをボックスに追加することによ
り、colleendをサブグループ内に含む。逆に、サブグル
ープ・ボックスが既にチェックされている場合、ボック
スをクリックすると、チェック・マークがクリアされ、
colleendをサブグループから除去する。

【００７５】図２４は、図２２の"アプレット許可（App
let Permission）"タブが管理者により選択されるとき
の、右パネルを示す。この右パネル内において、リスト
２４２０はシステム内で定義される全てのアプレットを
表示する。管理者はリスト２４２０内のアプレットを選
択し、次に"ユーザ・アクセス許可（Permit user acces
s）"ボタン２４３０をクリックすることにより、collee
ndによるアプレットへのアクセスを許可することができ
る。或いは、"ユーザ・アクセス拒否（Deny user acces
s）"ボタン２４３２をクリックすることにより、collee
ndによるアクセスが拒否される。管理者はまた、"実行
／カストマイズ（Run/Customize）"・ボタン２４３４を
クリックすることにより、colleendの状況において、ア
プレットを始動できる。これが実行されるとき、リスト
２４２０内で選択されたアプレットが右パネル内で始動
される。管理者はこの時、アプレットが許可するあらゆ
る選択を変更し、アプレットにより提供される方法で選
択を保管できる。ここでの典型的な状況は、管理者が構
成アプレットを始動し、様々な選択フィールドを記入す
ることである。しかしながら、別の構成がユーザ・アプ
レットに対して提供されない場合、管理者はユーザの状
況においてユーザ・アプレットを始動し、ユーザ・アプ
レットから選択をセットできる。ここでの典型的な状況
は、管理者がグループ状況またはユーザ状況を選択し、
前述のようにユーザ・アプレットを始動することであ
る。管理者はこの時、通常、オプション・メニューから
選択を変更し、それらをユーザ・アプレットにより提供
される方法で保管することができる。例えば、通常、オ
プション・ダイアログが閉じられるとき、ユーザ選択が
保管されるか、ユーザ・アプレットが選択を保管する他
の方法を提供する。いずれにしろ、この例では、管理者
がcolleendの状況において、アプレットを実行している
ので、管理者によりユーザ・アプレットを通じてセット
アップされた選択が、あたかもcolleendがアプレットを
実行することにより、自身でそれらを直接入力したかの
ように、サーバ上に保管される。

【００７６】ユーザがユーザ・アプレットに関係する一
部の選択を変更できる状況は、図示されていない。例え
ば、ユーザ・アプレットはユーザがウィンドウの背景色
またはフォント及びフォント・サイズを選択することを
可能にする。従って、各システム・ユーザは、ユーザ・
アプレットがユーザのデスクトップ上で実行されると
き、アプレットをある程度個性化することができる。こ
の場合、ユーザ変更された選択が、管理者がユーザ・ア
プレットを実行するときと同様に保管される。しかしな
がら、１つの違いは、管理者がユーザ・アプレットを実
行し、グループ状況において選択をセットできるのに対
して、ユーザが彼らの個々の状況に対して、選択に影響
を及ぼすことができることである。

【００７７】まとめとして、本発明の構成に関して以下
の事項を開示する。

【００７８】（１）ユーザ・ステーションにダウンロー
ドされる複数のエンド・ユーザ・アプリケーションと、
ユーザの異なるグループ及びサブグループの状況におけ
る、前記エンド・ユーザ・アプリケーションに対する構
成選択とを記憶するサーバと、複数のユーザ・ステーシ
ョンとを相互接続するネットワークを含むネットワーク
・システムにおいて、非固有ステーションまたは非固有
アプリケーションを中央管理のためのシステム内に改造
する方法であって、管理者ステーションにおいてプロフ
ァイル・マネージャを提供するステップと、前記非固有
ステーションまたはアプリケーションに対して構成アプ
リケーションを実行するように、前記プロファイル・マ
ネージャを編成することにより、管理者がシステム・ユ
ーザの異なるグループ及びサブグループの状況におい
て、前記非固有ステーションまたはアプリケーションに
対して構成選択を指定するステップと、前記サーバにお
いて、前記構成アプリケーションに対応するエクスポー
ト・エージェントを提供するステップと、非固有端末ま
たはアプリケーションに対する選択情報を、前記サーバ
上に記憶する要求が、前記プロファイル・マネージャに
より発行されるとき、前記エクスポート・エージェント
を呼び出すステップと、前記選択情報を前記エクスポー
ト・エージェントにより、前記非固有端末またはアプリ
ケーションと互換の形式に再フォーマットするステップ
と、再フォーマットされた前記情報を、前記非固有端末
またはアプリケーションによる直接アクセスのために、
前記非固有端末またはアプリケーションにより知られた
前記サーバ上の位置に記憶するステップとを含む、方
法。

【図面の簡単な説明】

【図１】本発明が実現され得る管理者のステーションを
含むネットワーク及びユーザ・ステーションを示す図で
ある。

【図２】サーバと通信する管理者のステーション、及び
中央プロファイル管理及び選択管理を提供する管理者の
ステーション及びサーバの構成要素をブロック図形式で
示す図である。

【図３】システムのユーザ・グループ及びユーザの階層
構成を示し、個々の端末及び端末グループは、単純化の
ために省略された図である。

【図４】個々のユーザと、図３の階層構成から、ユーザ
及びユーザにより実行される特定のアプリケーションに
当てはまる選択のセットを決定するために使用されるグ
ループ優先順位のリストを示す図である。

【図５】図２の管理者のステーション及びサーバの詳細
図である。

【図６】ユーザの端末としてアプリケーションの実行の
間にユーザ選択を確立するように協働する、ユーザ・ア
プリケーション及びアプリケーションと他の構成要素間
のＡＰＩを含む、ユーザの端末におけるソフトウェア・
オブジェクトを示す図である。

【図７】ユーザ・ログオン、及びユーザ端末において、
デスクトップ選択を含むユーザのデスクトップを初期に
確立するための、ユーザの端末及びサーバの両方におけ
るオペレーションを示す図である。

【図８】ユーザ・ログオン、及びユーザ端末において、
デスクトップ選択を含むユーザのデスクトップを初期に
確立するための、ユーザの端末及びサーバの両方におけ
るオペレーションを示す図である。

【図９】管理者ユーザ・ログオン、管理者のデスクトッ
プの確立、及び１例として構成のためのアプリケーショ
ン及び状況の選択ための、管理者の端末及びサーバの両
方におけるオペレーション、並びにユーザのデスクトッ
プの構成の間の状況変更及び結果のオペレーションを示
す図である。

【図１０】管理者ユーザ・ログオン、管理者のデスクト
ップの確立、及び１例として構成のためのアプリケーシ
ョン及び状況の選択ための、管理者の端末及びサーバの
両方におけるオペレーション、並びにユーザのデスクト
ップの構成の間の状況変更及び結果のオペレーションを
示す図である。

【図１１】管理者ユーザ・ログオン、管理者のデスクト
ップの確立、及び１例として構成のためのアプリケーシ
ョン及び状況の選択ための、管理者の端末及びサーバの
両方におけるオペレーション、並びにユーザのデスクト
ップの構成の間の状況変更及び結果のオペレーションを
示す図である。

【図１２】図３に１例が示される階層の生成、ユーザな
どの作成及び消去、アプリケーションに対するアプリケ
ーション選択の確立、及び選択確立の間の状況変更を含
む、アプリケーション管理の様々なフェーズでの、様々
な実際の管理者画面スナップショットを示す図である。

【図１３】図３に１例が示される階層の生成、ユーザな
どの作成及び消去、アプリケーションに対するアプリケ
ーション選択の確立、及び選択確立の間の状況変更を含
む、アプリケーション管理の様々なフェーズでの、様々
な実際の管理者画面スナップショットを示す図である。

【図１４】図３に１例が示される階層の生成、ユーザな
どの作成及び消去、アプリケーションに対するアプリケ
ーション選択の確立、及び選択確立の間の状況変更を含
む、アプリケーション管理の様々なフェーズでの、様々
な実際の管理者画面スナップショットを示す図である。

【図１５】図３に１例が示される階層の生成、ユーザな
どの作成及び消去、アプリケーションに対するアプリケ
ーション選択の確立、及び選択確立の間の状況変更を含
む、アプリケーション管理の様々なフェーズでの、様々
な実際の管理者画面スナップショットを示す図である。

【図１６】図３に１例が示される階層の生成、ユーザな
どの作成及び消去、アプリケーションに対するアプリケ
ーション選択の確立、及び選択確立の間の状況変更を含
む、アプリケーション管理の様々なフェーズでの、様々
な実際の管理者画面スナップショットを示す図である。

【図１７】図３に１例が示される階層の生成、ユーザな
どの作成及び消去、アプリケーションに対するアプリケ
ーション選択の確立、及び選択確立の間の状況変更を含
む、アプリケーション管理の様々なフェーズでの、様々
な実際の管理者画面スナップショットを示す図である。

【図１８】図３に１例が示される階層の生成、ユーザな
どの作成及び消去、アプリケーションに対するアプリケ
ーション選択の確立、及び選択確立の間の状況変更を含
む、アプリケーション管理の様々なフェーズでの、様々
な実際の管理者画面スナップショットを示す図である。

【図１９】図３に１例が示される階層の生成、ユーザな
どの作成及び消去、アプリケーションに対するアプリケ
ーション選択の確立、及び選択確立の間の状況変更を含
む、アプリケーション管理の様々なフェーズでの、様々
な実際の管理者画面スナップショットを示す図である。

【図２０】図３に１例が示される階層の生成、ユーザな
どの作成及び消去、アプリケーションに対するアプリケ
ーション選択の確立、及び選択確立の間の状況変更を含
む、アプリケーション管理の様々なフェーズでの、様々
な実際の管理者画面スナップショットを示す図である。

【図２１】図３に１例が示される階層の生成、ユーザな
どの作成及び消去、アプリケーションに対するアプリケ
ーション選択の確立、及び選択確立の間の状況変更を含
む、アプリケーション管理の様々なフェーズでの、様々
な実際の管理者画面スナップショットを示す図である。

【図２２】図３に１例が示される階層の生成、ユーザな
どの作成及び消去、アプリケーションに対するアプリケ
ーション選択の確立、及び選択確立の間の状況変更を含
む、アプリケーション管理の様々なフェーズでの、様々
な実際の管理者画面スナップショットを示す図である。

【図２３】図３に１例が示される階層の生成、ユーザな
どの作成及び消去、アプリケーションに対するアプリケ
ーション選択の確立、及び選択確立の間の状況変更を含
む、アプリケーション管理の様々なフェーズでの、様々
な実際の管理者画面スナップショットを示す図である。

【図２４】図３に１例が示される階層の生成、ユーザな
どの作成及び消去、アプリケーションに対するアプリケ
ーション選択の確立、及び選択確立の間の状況変更を含
む、アプリケーション管理の様々なフェーズでの、様々
な実際の管理者画面スナップショットを示す図である。

【符号の説明】

１００、２０３ ネットワーク １０２ デスクトップ・パーソナル・コンピュータ １０４ モバイル・ラップトップ・コンピュータ １０６ ワークステーション １０８ 管理者のステーション １１０、２０２、６０６、７０２、９０２ サーバ ２００ 管理クライアント・ネットワーク・コンピュー
タ ２０６、５０６、５１４ プロファイル・マネージャ ２０８、５０８ アプレット１ ２１２ データベース ２１４ プロファイル・マネージャ・サーブレット ２１８、５１８ ウェブ・サーバ ５１２ 状況変更事象リスナ ５１５、５１６ アプリケーション・プログラム・イン
タフェース ５２０ エクスポート・エージェント ６００ ユーザ ７００、９００ クライアント １２００ 主構成ウィンドウ １２０２ ツリー図パネル

フロントページの続き (56)参考文献 ”Ｔｈｉｎクライアントの死角”，日 経オープンシステム（1997年10月号）, Ｎｏ．55，ｐｐ．194−215 Ｔｏｍ Ｒ．Ｈａｌｆｈｉｌｌ著，" ネットワークの普及が引き起こす新ユー ザ・インタフェース革命”，日経バイ ト，（1997年９月号），ｐ．245−258 （原著：”Ｇｏｏｄ−ｂｙｅ，ＧＵ Ｉ，Ｈｅｌｌ，ＮＵＩ”，ＢＹＴＥ, （米）1997年６月号，ｐｐ．60−72) ｈｔｔｐ：／／ｗｗｗ．ｐｃ．ｉｂ ｍ．ｃｏｍ／ｕｓ／ｄｅｓｋｔｏｐ／ｌ ｃｃｍ／ ｈｔｔｐ：／／ｊａｖａ．ｓ ｕｎ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｈｏ ｔｊａｖａｖｉｅｗｓ/ ”ＮＣとＮｅｔＰＣ ウインドウズ用 ＺＡＫとＴＣＯのシステム管理費削減を 巡る情勢”，ＯＡビジネスパソコン Ｂ ＵＳＩＮＥＳＳ ＰＥＲＳＯＮＡＬ Ｃ ＯＭＰＵＴＩＮＧ ＡＧＥ，1997年８月 号，ｐｐ．70−76 ”「自由」から「束縛」へ ＰＣらし さを捨てる企業向け機”，日経バイト, 1997年８月号，ｐｐ．172−180 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 9/06 - 9/54 G06F 15/00 - 15/177 G06F 11/30 G06F 13/00

Claims (1)

(57)【特許請求の範囲】
1. 【請求項１】ユーザ・ステーションにダウンロードされ
   る複数のエンド・ユーザ・アプリケーションと、ユーザ
   の異なるグループ及びサブグループの状況における、前
   記エンド・ユーザ・アプリケーションに対する構成選択
   とを記憶するサーバと、複数のユーザ・ステーションと
   を相互接続するネットワークを含むネットワーク・シス
   テムにおいて、該ネットワーク・システムに本来適応し
   ない非ネイティブ・ステーションまたは非ネイティブ・
   アプリケーションを中央管理のために前記システムに適
   応させる方法であって、 前記サーバから前記ユーザ・ステーションの１つにプロ
   ファイル・マネージャをロードするステップと、 前記プロファイル・マネージャにより、前記エンド・ユ
   ーザ・アプリケーションに対して、該エンド・ユーザ・
   アプリケーションとは別の構成アプリケーションの実行
   を開始させるステップと、 前記構成アプリケーションの実行において、管理者がシ
   ステム・ユーザの異なるグループ及びサブグループの状
   況において、前記非ネイティブ・ステーションまたは非
   ネイティブ・アプリケーションに対する構成選択を指定
   することを許容するステップと、 前記サーバにおいて、前記構成アプリケーションに対応
   するエクスポート・エージェントを提供するステップ
   と、 非ネイティブ・ステーションまたは非ネイティブアプリ
   ケーションに対する選択情報を、前記サーバ上に記憶す
   る要求が、前記プロファイル・マネージャにより発行さ
   れるとき、前記エクスポート・エージェントを呼び出す
   ステップと、 前記選択情報を前記エクスポート・エージェントによ
   り、前記非ネイティブ・ステーションまたは非ネイティ
   ブアプリケーションと互換の形式に再フォーマットする
   ステップと、 再フォーマットされた前記情報を、前記非ネイティブ・
   ステーションまたは非ネイティブ・アプリケーションに
   よる直接アクセスのために、前記非ネイティブ・ステー
   ションまたは非ネイティブ・アプリケーションにより知
   られた前記サーバ上の位置に記憶するステップとを含
   む、方法。