JP2006510098A - 分散デスクトップ・パッケージを使用してデスクトップ・コンポーネントを復元するためのシステムおよび方法 - Google Patents

Abstract

【課題】 組織全体に渡って配置されたサーバに事前に送信されたコンポーネント・ファイルを管理者が回復できるようにし、デスクトップ・パッケージを中央管理するシステムおよび方法を提供することにある。
【解決手段】 アプリケーションはユーザおよびワークステーションに割り当てられる。内蔵タイプのデスクトップ・パッケージはサーバに伝送される。次にサーバはデスクトップ・パッケージをクライアントに提供する。パッケージと、パッケージに含まれるコンポーネントは、パッケージおよびコンポーネントを識別するために使用される固有のＩＤを含む。内蔵タイプのデスクトップ・ファイルのそれぞれに含まれる個々のコンポーネントを詳述するマニフェストが維持される。災害イベントが管理者のコンピュータ・システムで発生すると、管理者は、そのパッケージが事前に伝送されたサーバから内蔵タイプのデスクトップ・ファイルを検索する。管理者は、内蔵タイプのデスクトップ・ファイルからコンポーネントをアンパックすることにより、コンポーネント・ライブラリを再取込みする。管理者は、追加の内蔵タイプのパッケージ・ファイルを他のサーバから検索する必要があるかどうかを判別するためにマニフェストを使用する。

Description

本発明は、デスクトップ・コンポーネントを復元するためのシステムおよび方法に関する。特に、本発明は、内蔵タイプの（self-contained）パッケージ・データを使用して分散コンピュータからデスクトップ・コンポーネントを回復するためのシステムおよび方法に関する。

今日の最新のコンピュータ・ソフトウェア・システムは、組織全体に渡って分散式に編成されたエンタープライズ・システムである場合が多い。組織内の様々な人は、ユーザの職務記述に応じて、コンピュータ・システムを使用してそれぞれ異なる役割を実行する。銀行業務の一例では、あるユーザは出納係（teller）であり、したがって、銀行業務の顧客に対応するために、出納係アプリケーションを必要とする可能性がある。もう１人のユーザは融資担当者（loan officer）であり、融資を申請している顧客に対応するために融資担当者アプリケーションにアクセスする必要がある可能性がある。第３のユーザは支店長（branch manager）であり、銀行の支店を管理するために使用されるコンピュータ機能にアクセスする必要がある可能性がある。組織は、その分散共用システムを中央管理するための能力を所望する場合が多い。

伝統的なコンピュータ・システムは、概して、各コンピュータにより、たとえば、コンピュータ・ネットワークを使用して必要な機能にアクセスすることにより、すべての必要な機能を提供するように設計されているか、またはシステムは、個々のワークステーションが特定の役割を実行し、したがって、特定の１人または１組のユーザによって使用されるように設計されている。これは、複数ユーザが同じクライアント・コンピュータ・システムを使用する組織において課題を提起するものである。この銀行業務の例では、勤務時間、曜日、または特定のワークステーションにどの出納係がたまたま割り当てられるかに応じて、複数の出納係が同じクライアント・コンピュータ・システムを共用する可能性がある。

すべての組織機能が同じワークステーションから提供される場合、特定の機能を実行することを許可されていないユーザは、許可されていない機能を偶発的にまたは故意に実行する可能性がある。たとえば、出納係は、融資担当者または支店長の機能が出納係のワークステーションから使用可能である場合に、その機能を偶発的にまたは故意に実行する可能性がある。伝統的なシステムが許可を処理する方法の１つは、各ワークステーションで各職務の役割を処理するためのソフトウェア・コンポーネントをインストールするが、ユーザ・ログインに基づいてアクセスを制限することによるものである。しかし、この手法の課題は、任意の所与のワークステーションからこのような機能性を必要とする可能性のある任意のユーザにとって使用可能なものにするために、各ワークステーションが任意の新規または変更したソフトウェア・コンポーネントを受信する必要があることである。この手法のもう１つの課題は、すべてのワークステーションを変更しなければならないことである。

ユーザが実行する機能のうちのいくつかはクライアント／サーバ機能である可能性があるが、他の機能は、ユーザのワークステーションにインストールされているソフトウェア・システムの使用を伴う可能性がある。ユーザのワークステーションにインストールされたソフトウェア・システムとしては、レガシー・ソフトウェア・アプリケーションと、特定のオペレーティング・システム環境向けに作成されたその他のソフトウェアを含む可能性がある。

特定の機能を実行するために必要なコンポーネントを含む内蔵タイプのデスクトップ・パッケージの集中管理を行うシステムおよび方法は、組織全体に渡って実行されるコンピューティング機能を編成し管理する際に有用である。中央で作成し管理するコンポーネントを使用することの課題は、中央管理者によって作成された役割の価値が増加することと、中央管理者によって維持されるファイルが破棄された場合に組織にとって潜在的な損失が発生することである。

したがって、必要であるのは、組織全体に渡って配置されたサーバおよびクライアントに事前に送信されたコンポーネント・ファイルを中央管理者が回復できるようにするシステムおよび方法である。加えて、必要であるのは、様々なコンポーネントならびにそのコンポーネントの複数リリースを識別するためにコンポーネント・ファイルを一意的に識別するシステムおよび方法である。

デスクトップ・パッケージを中央管理するシステムおよび方法を使用して前述の課題が解決されることが発見された。このシステムにより、中央管理者は、組織全体に渡って配置されたサーバおよびクライアントに事前に送信されたコンポーネント・ファイルを回復することができる。

管理者は、ユーザおよびワークステーションにアプリケーションを割り当てる。管理者は、特定の職務の役割に必要なデスクトップ・コンポーネントを選択し、そのコンポーネントを内蔵タイプのデスクトップ・パッケージ・ファイルにパッケージ化する。この内蔵タイプのデスクトップ・パッケージは、特定のワークステーションを使用しているユーザに送信される。システムは、そのユーザに割り当てられている１つまたは複数の役割を識別し、識別された役割と、ワークステーションに割り当てられている１つまたは複数の役割とを突き合わせる。ワークステーションとユーザの両方に許可されている役割は、そのワークステーションを使用してそのユーザが使用するために使用可能になる。

一実施形態では、コンポーネントは種々の内蔵タイプのデスクトップ・パッケージ・セットにパッケージ化され、各パッケージはそれぞれ異なる１つの役割に対応する。銀行業務の一例では、出納係、融資担当者、および支店長などのユーザによって実行される各銀行業務の役割ごとに、それぞれ異なるデスクトップ・パッケージが作成されることになるであろう。このような内蔵タイプのデスクトップ・パッケージのそれぞれは、対応する機能を実行するために必要なコンポーネントを含む。たとえば、現金引出し（cash drawer）を操作するために使用されるデスクトップ・コンポーネントは出納係パッケージとともに含まれることになり、銀行の融資アプリケーション・ソフトウェアにアクセスするために使用されるデスクトップ・コンポーネントは融資担当者パッケージとともに含まれることになるであろう。複数の役割に共通のコンポーネントは、それが必要とされる各パッケージに含まれる。たとえば、顧客口座にアクセスするために使用されるコンポーネントは、出納係パッケージと融資担当者パッケージの両方に含まれる可能性がある。

内蔵タイプのデスクトップ・パッケージはサーバに伝送または「公開」される。次にサーバは内蔵タイプのデスクトップ・パッケージをクライアントに提供する。パッケージと、パッケージに含まれるコンポーネントは、パッケージおよびコンポーネントを識別するために使用される固有のＩＤを含む。加えて、内蔵タイプのデスクトップ・ファイルのそれぞれに含まれる個々のコンポーネントを詳述するマニフェストが維持される。

火災またはドライブ障害などの災害イベントが管理者のコンピュータ・システムで発生すると、管理者は、そのパッケージが事前に伝送されたサーバから内蔵タイプのデスクトップ・ファイルを検索する。管理者は、内蔵タイプのデスクトップ・ファイルからコンポーネントをアンパックすることにより、コンポーネント・ライブラリを再取込みする（repopulate）。管理者は、追加の内蔵タイプのパッケージ・ファイルを他のサーバから検索する必要があるかどうかを判別するためにマニフェストを使用する。

上記は要約であり、したがって、必要に迫られて、詳細の単純化、一般化、および省略を含み、その結果として、当業者は、その要約が例示的なものにすぎず、いずれにしても制限的なものになることは意図されていないことが分かるであろう。特許請求の範囲によってのみ定義されるように、本発明のその他の態様、発明の特徴、および利点は、以下に示した非制限的な詳細説明で明らかになるであろう。

本発明は、添付図面を参照することによって、より適切に理解することができ、その多数の目的、特徴、および利点は当業者にとって明らかなものにすることができる。異なる図面で同じ参照記号を使用する場合、同様または同一の項目を示す。

以下は、本発明の一例の詳細説明を提供するためのものであり、本発明自体を制限するものであると解釈すべきではない。むしろ、任意の数の変形例が、この説明後に特許請求の範囲で定義される本発明の範囲に含まれる可能性がある。

図１は、内蔵タイプのデスクトップを使用するネットワーク化コンピュータ・システムのネットワーク図である。管理者１００は、イメージ１１５と、アプリケーション拡張１２０と、各国語変換１２５と、クライアント構成ファイル１３０と、サーバ構成ファイル１３５と、デスクトップ・プロファイル情報１４０とを組み合わせることにより、内蔵タイプのデスクトップ１１０を作成する。内蔵タイプのデスクトップ１１０は、あるクライアントがそのクライアントの特定の役割を与えられたクライアントのワークステーション上でコンポーネントを使用するために必要なすべての情報を含む。

内蔵タイプのデスクトップ１１０は、クライアントへの普及のために１つまたは複数のサーバ１５０に伝送される。サーバ１５０は、ユーザの役割１５５とワークステーションの役割１６０とを組み合わせて、どの内蔵タイプのデスクトップをクライアントに送信すべきかを判別する。クライアント１６５は、ログインを実現するために、ユーザＩＤとパスワードが収集され、サーバ１５０に伝送されるログイン機能１７０を実行する。クライアント１６５は、許可デスクトップのリストを受信するために、ユーザＩＤとマシンＩＤが収集され、サーバ１５０に伝送されるログイン機能１７０を実行する。

サーバ１５０は、クライアントからユーザＩＤ、パスワード、およびマシンＩＤを受信し、そのクライアントによって使用されている特定のユーザＩＤおよび特定のワークステーションに対応するユーザの役割１５５およびワークステーションの役割１６０に基づいて、どの内蔵タイプのデスクトップをクライアントに送信すべきかを判別する。それに応答して、識別された内蔵タイプのデスクトップがサーバ１５０からクライアント１６５に伝送される。

クライアント１６５は、クライアント・ワークステーション上にシェル・アプリケーション１８０をロードするために、ロード・シェル・プロセス１７５を実行する。このシェル・プロセスは、Ｊａｖａ仮想マシン（ＪＶＭ）などのミドルウェア・アプリケーション上にロードされるアプリケーションである。このように、シェル・アプリケーションは、クライアント・ワークステーションによって使用されているオペレーティング・システム・プラットフォームにかかわらず、一貫性があり、実質的に同様と思われる。シェル・アプリケーション１８０は、内蔵タイプのデスクトップ１９０を検索し表示するように適合される。クライアント１６５は、ユーザＩＤとワークステーションＩＤとの共通部分（intersection）に基づいて、内蔵タイプのデスクトップを受信する。内蔵タイプのデスクトップは、プロセス１８５を使用して受信され表示される。したがって、所与のクライアントは複数の内蔵タイプのデスクトップを使用することができる。これらの内蔵タイプのデスクトップは、ユーザと通信するために使用されるツールバーと、メニューと、その他のグラフィカル・ユーザ・インターフェース項目とを含む。これらのユーザ・インターフェースのうちのいくつかは、サーバ１５０によってホストされるサーバ・アプリケーションと通信する機能性を含む。その他のユーザ・インターフェースは、クライアントベースのアプリケーション１９５にマッピングされる拡張機能を含む。クライアントベースのアプリケーションにマッピングされるデスクトップ・コンポーネントをユーザがクリックすると、そのクライアントベースのアプリケーションを呼び出すかまたはそれを使用するための機能性が内蔵タイプのデスクトップ内に存在する。あるクライアントが自分の自由になる内蔵タイプのデスクトップを複数有する場合、ユーザは、シェル・アプリケーション１８０によって提供されるメニューを使用することにより、様々な内蔵タイプのデスクトップ間で切り替えることができる。たとえば、銀行業務環境では、あるユーザが融資担当者であるとともに支店長でもある場合、ワークステーションがこれらの役割の両方を実行できるのであれば、これらの役割について対応する内蔵タイプのデスクトップが両方ともシェル１８０にロードされることになるであろう。融資担当者機能を実行するために、ユーザはシェル・アプリケーション１８０から融資担当者デスクトップを選択する。同様に、支店長機能を実行するために、ユーザはシェル・アプリケーション１８０から支店長デスクトップを選択する。加えて、最初に表示されるデスクトップがそのユーザの主な役割またはデフォルトの役割に対応するように、デフォルトの役割を設けることができる。

図２は、内蔵タイプのデスクトップを提供する際に含まれるコンポーネントのブロック図である。管理者２００は、トポロジ、ユーザ定義、サイト定義、およびデスクトップ定義を定義する。管理者２００は、ワークステーション定義２０５を提供することによりトポロジを定義する。ワークステーション定義２０５は、どの役割またはデスクトップが様々なワークステーション上での使用が許可されるかを定義するワークステーション・アドレス２１０と許可デスクトップ２１５とを含む。たとえば、銀行業務環境では、出納係の窓口に配置されたワークステーションは、出納係ボックスなどの特殊機器を有する可能性があり、したがって、そのワークステーションは出納係機能を実行することができるかまたはそれを実行することが許可される。おそらく出納係エリアから離れたデスクにある他のワークステーションは、出納係機能を実行することができない可能性がある。

ユーザ定義２２０は、システムのユーザおよびこのようなユーザが実行する役割を定義するために使用される。ユーザ定義２２０は、ユーザ・データ２２５と、割当てグループ・データ２３０とを含む。ユーザ・データ２２５は、ユーザＩＤと、ユーザ・パスワードとを含む。割当てグループ・データ２３０は、特定のユーザが実行することを許可されている役割を含む。たとえば、支店長は、支店長機能、融資担当者機能、および出納係機能を実行することを許可される可能性があるが、出納係は出納係機能を実行することが許可されるだけである可能性がある。

サイト定義２３５は、特定のサイトに関する情報を含む。銀行業務環境では、サイトはその銀行の支店である可能性がある。サイト定義２３５は、特定のサイトのユーザのための共通デスクトップを提供するグループ・デスクトップ・マップ２４０ならびにそのサイトに関する詳細を提供するサイト情報２４５を含む。

デスクトップ定義２５０は、クライアントによって使用される内蔵タイプのデスクトップを作成するために使用されるコンポーネントを含む。デスクトップ定義２５０は、内蔵タイプのデスクトップ上に表示されるイメージ２５２と、内蔵タイプのデスクトップからアクセス可能なクライアントベースのアプリケーションに関する詳細を提供するアプリケーション拡張２５４とを含む。また、デスクトップ定義２５０は、各国語変換２５６などのリソースも含み、したがって、ユーザは、それぞれの必要に最も適合する言語設定（language preference）などのリソースを選択することができる。また、デスクトップ定義２５０は、クライアント構成２５８と、サーバ構成２６０も含む。これらの構成は、特定の内蔵タイプのデスクトップとともに含まれるコンポーネントに関する情報を含む。

管理者２００は、内蔵タイプのデスクトップを作成し、クライアントによってアクセス可能な１つまたは複数のサーバ２６５上にその内蔵タイプのデスクトップを公開する。サーバ２６５は、永続的ストレージ（persistent storage）２７０と、認証機能２８０とを含む。永続的ストレージ２７０は、ユーザ・データ２７２と、トポロジ情報２７４と、内蔵タイプのデスクトップ２７６とを含む。ユーザ・データおよびトポロジ・データは、所与のワークステーションを使用する所与のクライアントがどの内蔵タイプのデスクトップ２７６を使用することを許可されているかを判別するために使用される。サーバ２６５は、特定のユーザ／ワークステーションについて許可されているデスクトップをクライアント２９０に提供する。内蔵タイプのデスクトップは、クライアントによって受信され、プラットフォーム独立シェル２９５上に表示される。このように、サーバ２６５は、クライアントによって使用されている特定のオペレーティング・システム・プラットフォームと無関係に、識別されたデスクトップをクライアント２９０に送信する。

図３は、内蔵タイプのデスクトップを提供するために管理者によって実行されるステップを示す高レベル流れ図である。管理者処理は３００から始まり、その後、管理者はユーザを定義する（事前定義プロセス３１０、詳細については図５を参照されたい）。また、管理者は、システムのユーザによって使用されるワークステーションも定義する（事前定義プロセス３２０、詳細については図６を参照されたい）。

各国語変換など、クライアントが必要とするリソースは、そのリソースを内蔵タイプのデスクトップに含めることができるようにセットアップされる（事前定義プロセス３３０）。ワークステーションから使用可能なアプリケーションに対応するアプリケーション拡張が定義される（事前定義プロセス３４０、詳細については図７を参照されたい）。特定の職務の役割を実行するために必要なすべてのコンポーネントを含む内蔵タイプのデスクトップがパッケージ化される（事前定義プロセス３５０、処理の詳細については図８を参照されたい）。

新規サイトが追加されるかどうかに関する判別が行われる（判断３６０）。新規サイトが追加される場合、判断３６０は「Ｙｅｓ」分岐３６５に分岐し、その後、新規サイトが定義される（事前定義プロセス３７０、処理の詳細については図４を参照されたい）。これに対して、新規サイトが追加されない場合、判断３６０は「Ｎｏ」分岐３７５に分岐し、ステップ３７０を迂回する。

定義されたデスクトップは、１つまたは複数のサイトおよび１つまたは複数の役割にマッピングされる（事前定義プロセス３８０）。このように、単一デスクトップは、複数のサイトで複数の役割のために使用することができる。逆に、各サイトでそれぞれの役割ごとに異なるデスクトップを定義し使用することができる。デスクトップ・コンポーネントは１つの内蔵タイプのデスクトップにパッケージ化され、その内蔵タイプのデスクトップは様々なクライアントへの普及のために１つまたは複数のサーバに公開される（事前定義プロセス３９０、処理の詳細については図９を参照されたい）。管理者処理は３９５で終了する。

図４は、特定のサイトをセットアップするために実行される管理者ステップを示す流れ図である。処理は４００から始まり、その後、固有のＩＤがサイトに割り当てられる（ステップ４０５）。そのサイトの親サイトが識別される（ステップ４１０）。たとえば、支店は親サイト用の地方事務所を有する場合がある。このように、新規サイトは、特性および属性が一貫性があり、各サイトごとに再入力する必要がないように、親サイトから特性および属性を継承することができる。親サイトが識別されたかどうかに関する判別が行われる（判断４１５）。親サイトが識別された場合、判断４１５は「Ｙｅｓ」分岐４１８に分岐し、その後、その親に関するポリシーおよびデスクトップが検索される（ステップ４２０）。これに対して、親サイトが識別されていない場合、判断４１５は「Ｎｏ」分岐４２２に分岐し、その後、管理者はポリシーおよびデスクトップをそのサイト用のデフォルト値に設定する（ステップ４２５）。

特定のサイトについて検索または設定されたポリシーは、その特定のサイトの必要に応じて変更することができる（ステップ４３０）。このように、あるサイトは、親サイトのポリシーとはわずかに異なるポリシーを有することができる。サイトは、そのサイトで働くユーザによって実行される１つまたは複数の役割を有する。銀行業務環境では、支店サイトは、出納係、融資担当者、および支店長などの役割を有することができる。このサイトの第１の役割が選択される（ステップ４３５）。その役割を変更する必要があるかどうかに関する判別が行われる（判断４４０）。その役割を変更する必要がある場合、判断４４０は「Ｙｅｓ」分岐４４５に分岐し、その後、その役割に関する内蔵タイプのデスクトップが選択される（ステップ４５０）。これに対して、その役割に関するデスクトップを変更する必要がない場合、判断４４０は「Ｎｏ」分岐４５５に分岐し、ステップ４５０を迂回する。このように、子サイトは特定の役割のために親サイトと同じデスクトップを使用するが、管理者は所与の役割について子サイトに異なるデスクトップを割り当てるための柔軟性を有する。

そのサイト用の役割がそれ以上存在するかどうかに関する判別が行われる（判断４６０）。役割がそれ以上存在する場合、判断４６０は「Ｙｅｓ」分岐４６５に分岐し、その後、そのサイトの次の役割が選択され（ステップ４７０）、処理はループバックして次の役割を処理する。このループは、そのサイト用の役割がそれ以上存在しなくなるまで継続し、その時点で判断４６０は「Ｎｏ」分岐４７５に分岐し、その後、そのサイトについて選択されたデスクトップおよびその他のデータが保管される（ステップ４８０）。次に処理は４９５で復帰する。

図５は、新規ユーザを定義するために管理者によって実行されるステップを示す流れ図である。処理は５００から始まり、その後、ユーザＩＤなどの固有のユーザＩＤがそのユーザに割り当てられる（ステップ５０５）。また、初期パスワードもそのユーザに割り当てられる（ステップ５１０）。また、そのユーザ用のユーザ名あるいはユーザ記述またはその両方も入力される（ステップ５１５）。そのユーザ用の各国語設定が選択される（ステップ５２０）。

管理者によって作成され、データ・ストア５３０に保管された役割のリストから、そのユーザ用の役割が選択される（ステップ５２５）。選択された役割がそのユーザ用のデフォルトの役割であるかどうかに関する判別が行われる（判断５４０）。選択された役割がそのユーザ用のデフォルトの役割である場合、判断５４０は「Ｙｅｓ」分岐５４５に分岐し、その後、選択された役割はそのユーザ用のデフォルトの役割として割り当てられる（ステップ５５０）。これに対して、選択された役割がデフォルトの役割ではない場合、判断５４０は「Ｎｏ」分岐５５５に分岐し、ステップ５５０を迂回する。

そのユーザに割り当てるべき役割がそれ以上存在するかどうかに関する判別が行われる（判断５６０）。そのユーザに割り当てるべき役割がそれ以上存在する場合、判断５６０は「Ｙｅｓ」分岐５６５に分岐し、それがループバックして、そのユーザ用の次の役割を選択し処理する。このループは、そのユーザに割り当てるべき役割がそれ以上存在しなくなるまで継続し、その時点で判断５６０は「Ｎｏ」分岐５７０に分岐し、その後、そのユーザに割り当てられた役割が保管される（ステップ５８０）。次に処理は５９５で復帰する。

図６は、ワークステーションをセットアップするために管理者によって実行されるステップを示す流れ図である。処理は６００から始まり、その後、ワークステーション用のＭＡＣアドレスなどのＩＤが入力される（ステップ６１０）。ＭＡＣアドレスは、コンピュータ・ネットワークの各ノードを一意的に識別するハードウェア・アドレスであるメディア・アクセス制御アドレスである。ホストまたはサーバがそのワークステーションに割り当てられる（ステップ６２０）。そのワークステーション用のＩＰアドレスが割り当てられるかまたは検索される（ステップ６３０）。また、そのワークステーション用のワークステーション記述も入力される（ステップ６４０）。ワークステーション記述は、そのワークステーションが銀行出納係引出しを含むかどうかなどのワークステーションの機能の記述を含むことができる。

管理者によって作成され、データ・ストア６６０に保管された役割のリストから、そのワークステーション用の第１の役割が選択される（ステップ６５０）。たとえば、銀行業務環境では、役割としては、出納係、融資担当者、および支店長を含むことができる。１つのワークステーションは３つの役割すべてを実行できる可能性があるが、他のワークステーションは３つの役割のうちの１つまたは２つを実行できるだけである。さらに、他のワークステーションが機密または重要機能を物理的に実行できる可能性がある場合でも、このような機能が特定のワークステーションに制限される可能性がある。そのワークステーションに割り当てるべき役割がそれ以上存在するかどうかに関する判別が行われる（判断６７０）。そのワークステーションに割り当てるべき役割がそれ以上存在する場合、判断６７０は「Ｙｅｓ」分岐６７５に分岐し、その後、そのワークステーション用の次の役割が選択される（ステップ６８０）。このループは、そのワークステーションに割り当てるべき役割がそれ以上存在しなくなるまで継続し、その時点で判断６７０は「Ｎｏ」分岐６８５に分岐する。割り当てられた役割およびワークステーション・データは不揮発性ストレージ・エリアに保管される（ステップ６９０）。次に処理は６９５で復帰する。

図７は、アプリケーション拡張をセットアップするために管理者によって実行されるステップを示す流れ図である。アプリケーション拡張は、クライアントベースのレガシー・アプリケーションなどのアプリケーション・プログラムへのアクセスを可能にするデスクトップ・コンポーネントである。処理は７００から始まり、その後、拡張ＩＤが特定のアプリケーション拡張に割り当てられる（ステップ７０５）。対応するアプリケーションを記述するアプリケーション記述が入力される（ステップ７１０）。また、そのアプリケーション拡張用のクライアント・クラスも入力される（ステップ７１５）。

その拡張がシステムによって提供されるのかまたはユーザによって提供されるのかに関する判別が行われる（判断７２０）。その拡張がユーザによって提供される場合、判断７２０はユーザ分岐７２５に分岐し、その後、その拡張に対応するＪａｖａアーカイブ（ＪＡＲ）ファイル名が入力される（ステップ７３０）。これに対して、その拡張がシステム提供される場合、判断７２０はシステム分岐７３５に分岐し、ステップ７３０を迂回する。

管理者オブジェクト指向クラスが必要であるかどうかに関する判別が行われる（判断７４０）。管理者クラスが必要である場合、判断７４０は「Ｙｅｓ」分岐７４５に分岐し、その後、管理者クラス名が入力される（ステップ７５０）。これに対して、管理者クラスが必要ではない場合、判断７４０は「Ｎｏ」分岐７５５に分岐し、ステップ７５０を迂回する。

そのアプリケーション拡張は、提供された情報を使用して作成される（ステップ７６０）。そのアプリケーション拡張用の任意のデフォルト・プロパティが存在するかどうかに関する判別が行われる（判断７７０）。デフォルト・プロパティが存在する場合、判断７７０は「Ｙｅｓ」分岐７７５に分岐し、その後、そのアプリケーション拡張用のデフォルト・プロパティが入力される（ステップ７８０）。これに対して、そのアプリケーション拡張用のデフォルト・プロパティがまったく存在しない場合、判断７７０は「Ｎｏ」分岐７８５に分岐し、ステップ７８０を迂回する。

そのアプリケーション拡張は、任意のデフォルト・プロパティとともに、不揮発性ストレージ・エリアに保管される（ステップ７９０）。次に処理は７９５で復帰する。

図８は、アプリケーション参照をセットアップするために実行される管理者ステップを示す流れ図である。処理は８００から始まり、その後、そのアプリケーション参照に対応する参照のタイプ（すなわち、拡張タイプ）が選択される（ステップ８１０）。固有のアプリケーション参照ＩＤがそのアプリケーション参照に割り当てられる（ステップ８２０）。また、そのアプリケーション参照用のアプリケーション記述も提供される（ステップ８３０）。また、アイコン・タイトルおよびアイコン・ファイル名などのアイコン属性も提供される（ステップ８４０）。また、そのアプリケーション拡張のタイプに固有のプロパティも入力される（ステップ８５０）。次に、アプリケーション参照が不揮発性ストレージ・エリアに保管され（ステップ８６０）、処理は８９５で復帰する。

図９は、内蔵タイプのデスクトップを作成するために管理者によって実行されるステップを示す流れ図である。処理は９００から始まり、その後、固有のデスクトップＩＤがその内蔵タイプのデスクトップに割り当てられる（ステップ９０５）。そのデスクトップ用のデスクトップ・タイトルあるいはデスクトップ記述またはその両方が入力される（ステップ９１０）。そのデスクトップ用の画面およびアイコンの外観が入力される（ステップ９１５）。次に管理者は、デスクトップ上に表示するために、アイコン、背景などのイメージを選択する（ステップ９２０）。これらのイメージはデスクトップ・コンポーネント・ライブラリ９２５から選択される。デスクトップ・コンポーネント・ライブラリ９２５は、背景およびその他のイメージ９３０と、アイコン９３５と、アプリケーション参照９４５と、リソース９５５とを含む。

デスクトップから使用可能になるアプリケーション参照は、デスクトップ・コンポーネント・ライブラリ９２５に含まれるアプリケーション参照９４５から選択される（ステップ９４０）。銀行業務環境では、出納係のデスクトップは、顧客の銀行預金残高を調べ、出納係の現金引出しを操作するためのアプリケーション参照を含むことができ、融資担当者のデスクトップは、銀行の融資承認ソフトウェア・アプリケーションへのアクセスを可能にするアプリケーション参照を含むことができる。サポートされるロケールごとに、テキストおよびリソースなどの各国語データが提供される（ステップ９５０）。これらのリソースは、デスクトップ・コンポーネント・ライブラリ９２５に含まれるリソース９５５から選択される。

そのデスクトップとともに含まれるファイルおよびリソースを詳述するデスクトップ構成が保管される（ステップ９６０）。そのデスクトップを記述するクライアント構成ファイルが作成され、デスクトップ・データがパッケージ化され（ステップ９７０）、その結果、内蔵タイプのデスクトップ９７５が得られる。結果として得られる内蔵タイプのデスクトップは、そのデスクトップをサーバ９９０に伝送することにより、クライアントがアクセス可能なサーバに公開される（ステップ９８０）。次に処理は９９５で復帰する。

図１０は、内蔵タイプのデスクトップをクライアントに送達するためにサーバによって実行されるステップを示す流れ図である。処理は１０００から始まり、その後、サーバがユーザ・ログインおよびワークステーションＩＤを受信する（ステップ１００５）。ユーザ・ログインは、ユーザを認証するために使用されるユーザＩＤとユーザ・パスワードとを含む。そのユーザに割り当てられた役割は、ユーザ・ディレクトリ・データ・ストア１０１５から検索される（ステップ１０１０）。そのワークステーションに割り当てられた役割は、トポロジ・ディレクトリ１０２５から検索される（ステップ１０２０）。

そのユーザに割り当てられた任意の役割がそのワークステーションに割り当てられた任意の役割と一致するかどうかに関する判別が行われる（判断１０３０）。いかなる役割も共通しない場合、判断１０３０は「Ｎｏ」分岐１０３５に分岐し、その後、クライアントにエラーが返され（ステップ１０３８）、処理は１０９５で復帰する。これに対して、１つまたは複数の役割が共通する場合、判断１０３０は「Ｙｅｓ」分岐１０４０に分岐し、その後、選択された役割に関する第１のデスクトップがデスクトップ／役割マップ１０５０から検索され、対応する内蔵タイプのデスクトップがデータ・ストア１０５５から検索される。ユーザとワークステーションとの間で共通する役割がそれ以上存在するかどうかに関する判別が行われる（判断１０６０）。共通する役割がそれ以上存在する場合、判断１０６０は「Ｙｅｓ」分岐１０７０に分岐し、その後、次の共通の役割が選択され（ステップ１０８０）、処理はループバックして対応する内蔵タイプのデスクトップを検出する。このループは、ユーザとワークステーションとの間で共通する役割がそれ以上存在しなくなるまで継続し、その時点で判断１０６０は「Ｎｏ」分岐１０６５に分岐し、その後、検索されたデスクトップＩＤ（すなわち、ユーザとワークステーションの両方に共通するＩＤ）がクライアントに送信される（ステップ１０９０）。次に処理は１０９５で復帰する。

図１１は、新規サイトをセットアップするために管理者によって使用される画面の画面レイアウトである。管理者は、画面レイアウト１１００を使用して新規サイトを定義する。管理者は、テキスト・ボックス１１５０に固有のサイトＩＤを入力する。新規サイトがすでに作成されているサイトの子である場合、リスト・ボックス１１０５から親サイトが選択される。リスト・ボックス１１０５は、事前に定義されたサイトＩＤのリストを含む。フレーム１１１０は、そのサイトに使用されるポリシー情報を含む。ポリシー情報は、ポリシー名１１１５と、ポリシー値１１２０と、継承データ１１２５とを含む。継承データ１１２５は、継承値１１３０と、継承上位（inheritance ancestor）１１３５とを含む。図示の例では、ポリシー名は「新規ｂＤＣ」であり、ポリシーの値は親サイトから継承される。継承値は「許可（allow）」であり、継承上位はサイト階層内の「ルート」または最上位サイトである。

デスクトップ・フレーム１１４０は、そのサイトで使用可能な役割およびデスクトップに関する情報を含む。デスクトップ・フレーム１１４０は、役割データ１１５５と、デスクトップ・データ１１６０と、継承データ１１７０とを含む。継承データは、継承されたデスクトップ１１７５の名前と、そこからそのデスクトップが継承された上位１１８０の名前とを含む。図示の例では、そのサイトに含まれる役割としては、管理者、支店長、ゲスト、融資担当者、および出納係を含む。それぞれのデスクトップは、デスクトップ・フィールド用の「［継承済み（Inherited）］」という値によって示される通り、親サイトから継承される。管理者、支店長、および融資担当者のデスクトップは「支店Ａ」サイトから継承され、ゲストおよび出納係のデスクトップは「ルート」サイトから継承される。このように、内蔵タイプのデスクトップは、様々な親サイトから選択するかまたはその子サイト用に具体的に構成することができる。

新規サイト・データが入力されると、管理者は「サイトの作成」コマンド・ボタン１１９０を選択して新規サイトを作成する。管理者が間違いを犯し、値をリセットしたいと希望する場合、管理者は「値のリセット」コマンド・ボタン１１９５を選択することができる。

図１２は、所与のサイト用のデスクトップおよびマシンを管理するために管理者によって使用される画面の画面レイアウトである。管理者は画面レイアウト１２００を使用して、所与のサイト用のデスクトップを管理するとともに、そのサイトに対応するワークステーションを追加し管理する。画面レイアウト１２００の上半分は、図１１に示した新規サイト・レイアウトと同様である。リスト・ボックス１２０５は、そのサイトに割り当てるための親サイトを選択するために使用される。親サイトは、組織内の変更に対処するように変更することができる。ポリシー・フレーム１２１０は、ポリシーの名前１２１２と、ポリシー値１２１４と、継承データ１２１６とを含む。継承データは、継承値１２１８と上位値１２２０とを含む。図示の例では、ポリシー名は、「ルート」上位から継承された「新規ｂＤＣ」である。

デスクトップ・フレーム１２２５は、役割データ１２３０と、デスクトップ・データ１２３５と、デスクトップ継承データ１２４０とを含む。図１２に示した銀行業務の例では、このサイト用に含まれる役割は、管理者、支店長、ゲスト、融資担当者、および出納係からなる。デスクトップは、管理者、支店長、ゲスト、融資担当者、および出納係によって使用されるものである。それぞれの役割はデスクトップ・データ１２３５に示される。値のうちのいくつかは親サイトから継承され、その他の値は特定の内蔵タイプのデスクトップになるように指定される。デスクトップ継承データは、デスクトップ継承１２４２と、上位データ１２４４とを含む。図示の例では、管理者、支店長、および融資担当者はそれぞれ「支店Ａ」からデスクトップ・データを継承し、ゲストおよび出納係はそれぞれ「ルート」親からデスクトップ・データを継承する。

管理者がサイト・データを変更し、変更したサイト情報を保管したいと希望する場合、管理者は「変更の実行依頼」コマンド・ボタン１２４５を選択する。管理者がサイト値をリセットしたいと希望する場合、管理者は「値のリセット」コマンド・ボタン１２５０を選択する。管理者がそのサイトを削除したいと希望する場合、管理者は「サイトの削除」コマンド・ボタン１２５５を選択する。

管理者がそのサイトをサーバに公開する準備ができると、管理者は「公開」コマンド・ボタン１２６０を選択する。管理者がそのサイトの子である任意のサイトとともにそのサイトを公開したいと希望する場合、管理者は「子を伴う公開（Publish with Children）」コマンド・ボタン１２６５を選択する。

子サイト・フレーム１２７０は、そのサイトの子である任意のサイトに関するデータを含む。子サイト・データは、サイト名１２７２と、サイト・ポリシー１２７８とを含む。新規子サイトを作成するために、管理者は、管理者が新規子サイトを識別できるようにする「＜新規サイト＞」ハイパーリンク１２７５を選択することができる。

マシン・フレーム１２８０は、そのサイトに含まれるワークステーションに関するデータを含む。ワークステーション・データは、ワークステーションＩＤ１２８２と、ワークステーション用のホスト名１２８４と、ワークステーション・タイプ１２８６と、そのワークステーションによって提供される役割１２８８と、そのワークステーションのＩＰアドレス１２９０と、ワークステーション記述１２９２とを含む。そのサイトに新規マシン（ワークステーション）を追加するために、管理者は「＜新規マシン＞」ハイパーリンク１２９５を選択する。

図１３は、新規ユーザをセットアップするために管理者によって使用される画面の画面レイアウトである。画面レイアウト１３００は、新規ユーザの固有のＩＤを入力するためのテキスト・ボックス１３０５を含む。ユーザのフルネームはテキスト・ボックス１３１０に入力される。加えて、ユーザの記述はテキスト・ボックス１３１５に入力することができる。たとえば、ユーザＩＤは、このような頻度の低いユーザまたはパートタイム・ユーザのために新規ユーザＩＤを確立する必要なしに誰かが使用することができるゲストまたは出納係などの総称ＩＤとしてセットアップすることができる。このような総称目的に使用されるユーザＩＤは、記述テキスト・ボックス・フィールド１３１５を使用してさらに記述することができる。

そのユーザ用の新規初期パスワードはテキスト・ボックス１３２０に入力される。この新規初期パスワードは、そのパスワードをテキスト・ボックス１３２５に再入力することにより、管理者によって確認される。そのユーザ用のデフォルト・ロケールは、リスト・ボックス１３３０を使用して管理者によって選択される。図示の例では、ロケールは、米国英語を話すユーザのための米国ロケールになるように選択されている。しかし、そのユーザの１次言語がスペイン語またはその他の言語であった場合、適切なロケールはリスト・ボックス１３３０内に示されたリストから選択される。

フレーム１３３２は、そのユーザに対応する役割を選択するために管理者によって使用される。デフォルトの役割１３３５は、使用可能な役割のそれぞれに対応する、いくつかのラジオ・ボタンを含む。ラジオ・ボタンは、管理者がそのユーザ用のデフォルトの役割を１つだけ選択するように使用される。選択欄１３４０は、使用可能な役割のそれぞれに対応する、いくつかのチェック・ボックスを含む。管理者は、そのユーザが実行する各役割に対応する、それぞれのチェック・ボックスを選択する。名前欄１３４５は、使用可能な役割のそれぞれの名前を含む。図示の例では、使用可能な役割としては、管理者、支店長、ゲスト、融資担当者、および出納係を含む。管理者は、欄１３４０の対応するチェック・ボックスを選択することにより、これらの役割のうちの１つまたは複数を選択することができる。加えて、管理者は、「＜新規役割＞」ハイパーリンク１３５０を選択することにより、新規役割を確立することができる。

管理者が、ユーザ・データの入力と、そのユーザへの役割の割当てを終了すると、管理者は「ユーザの作成」コマンド・ボックス１３５５を選択して、ユーザ・データおよび割り当てられた役割を作成し保管する。管理者が間違いを犯し、値をリセットしたいと希望する場合、「値のリセット」コマンド・ボタン１３６０が選択される。

図１４は、１つまたは複数の内蔵タイプのデスクトップ内のコンポーネントとして使用可能であるアプリケーションをセットアップするために管理者によって使用される画面の画面レイアウトである。画面レイアウト１４００は、内蔵タイプのデスクトップに含めることができる新規アプリケーションを定義するために使用される。アプリケーションＩＤテキスト・ボックス１４０５は、定義中のアプリケーションに対応する固有のアプリケーションＩＤを入力するために管理者によって使用される。図１４に示した例では、定義中のアプリケーションのタイプは「ネイティブ」アプリケーションであり、換言すれば、そのアプリケーションの実行可能プログラムのうちの少なくともいくつかがクライアント・ワークステーション上に常駐するアプリケーションである。

定義中のアプリケーションの記述は、記述テキスト・ボックス１４１０に入力される。アイコン属性フレーム１４１５は、デスクトップ上に表示され、アプリケーションを選択するためにユーザによって使用されることになるアイコンに対応する属性を定義するために使用される。アイコン属性は、テキスト・ボックス１４２０に入力されるタイトルと、テキスト・ボックス１４２５に入力されるアイコン・ファイル名とを含む。

プラットフォーム・プロパティ・フレーム１４３０は、そこからアプリケーションを呼び出すことができるサポート・オペレーティング・システム・プラットフォームのそれぞれに関するデータを含む。Ｗｉｎ３２フレーム１４３５は、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（商標）オペレーティング・システム・プラットフォームからアプリケーションを呼び出して実行するために使用されるデータを含む。Ｗｉｎ３２データは、Ｗｉｎ３２環境でそのアプリケーションの実行可能形式を識別するパスおよびファイル名を含む。パスおよびファイル名はテキスト・ボックス１４４０に入力される。そのアプリケーションに必要な任意のパラメータは、パラメータ・テキスト・ボックス１４４５に提供される。そのアプリケーションに対応する作業ディレクトリは、必要であれば、テキスト・ボックス１４５５に入力される。

プラットフォーム・プロパティ・フレーム１４３０は、ＯＳ／２オペレーティング・システム・プラットフォームに関するデータも含み、そのためのフィールドはフレーム１４６０内に位置する。ＯＳ／２フィールドは、上述のＷｉｎ３２フィールドに対応する。これらは、パスおよびファイル名テキスト・ボックス１４６５と、パラメータ・テキスト・ボックス１４７０と、作業ディレクトリ・テキスト・ボックス１４７５とを含む。同様に、Ｌｉｎｕｘ用のフィールド・セットはフレーム１４８０内に設けられ、これが、パスおよびファイル名テキスト・ボックス１４８２と、パラメータ・テキスト・ボックス１４８４と、作業ディレクトリ・テキスト・ボックス１４８６とを含む。

アプリケーション情報が管理者によって入力されると、管理者は、「アプリケーションの作成」コマンド・ボタン１４９０を選択することにより、そのアプリケーションを作成することができる。管理者が間違いを犯した場合、「値のリセット」コマンド・ボタン１４９５を選択することにより、新規アプリケーション値をリセットすることができる。

図１５は、内蔵タイプのデスクトップをセットアップするために管理者によって使用される画面の画面レイアウトである。画面レイアウト１５００は、内蔵タイプのデスクトップの外観および機能性を定義するために使用される様々なフィールドを含む。事前に定義されたデスクトップＩＤはこの画面上に表示される。図示の例では、デスクトップＩＤは「ｂｄａ管理者」である。この内蔵タイプのデスクトップ用のタイトルはテキスト・ボックス１５０５に管理者によって入力される。図示の例では、タイトルは「管理者」である。この内蔵タイプのデスクトップ用の記述はテキスト・ボックス１５１０に入力される。図示の例では、入力された記述は「ＢＤＡ管理者用のデスクトップ」である。

この内蔵タイプのデスクトップ用の立上げモードは、リスト・ボックス１５１５を使用して管理者によって選択される。立上げモードは、デスクトップからコンポーネントを起動するために必要なマウス・クリックの数を示す。図示の例では、選択された立上げモードは「２」（すなわち、ダブルクリック）である。アイコン属性はフレーム１５２０に入力される。最大許容および表示可能アイコン・タイトル長は、適切なテキスト・ボックスに管理者によって入力される。

背景外観情報は、フレーム１５２５に管理者によって入力される。内蔵タイプのデスクトップの背景用のカラー、イメージ・ファイル、イメージ表示モードは、管理者によって提供される。たとえば、デスクトップ背景データは、組織の名前とロゴを含むことができる。アイコン外観情報は、フレーム１５３０に管理者によって入力される。アイコン外観データとしては、アイコンのテキスト・カラー、アイコンとともに使用されるフォント、アイコンとともに使用されるフォント・サイズ、アイコンに使用されるフォント・スタイル、アイコン・フロー、アイコン・フローの起点、およびアイコン・テキストのテキスト位置を含む。

管理者が内蔵タイプのデスクトップのセットアップを完了すると、管理者は「変更の実行依頼」コマンド・ボタン１５４０を選択して、デスクトップ設定を保管する。管理者が間違いを犯すかまたは値をリセットしたいと希望する場合、管理者は「値のリセット」コマンド・ボタン１５４５を選択する。管理者がその内蔵タイプのデスクトップ定義を削除したいと希望する場合、管理者は「デスクトップの削除」コマンド・ボタン１５５０を選択する。

ハイパーリンク１５６０は、内蔵タイプのデスクトップから使用可能な参照を追加、変更、または削除するために使用される。使用可能な参照は、アプリケーション１５７０と、フォルダ１５８０と、ツールバー１５９０とを含む。図示の例では、すでに含まれているアプリケーションは、「ａｃｒｏｒｅａｄ」、「電卓」、および「ブラウザ」からなる。含まれているフォルダは、１つのアプリケーション・フォルダと、２つの管理者フォルダからなる。また、１つのツールバーである管理者ツールバー（Admin Toolbar）も含まれている。

図１６は、ワークステーションを管理するために管理者によって使用される画面の画面レイアウトである。画面レイアウト１６００は、ネットワーク全体に渡って使用されるワークステーションまたはコンピュータ・システムを管理するために管理者によって使用される。ワークステーションのそれぞれについて維持されるデータとしては、欄１６１０にリストされるワークステーションＩＤ、欄１６２０にリストされ、そのワークステーションが属すサイト、欄１６３０にリストされ、そのワークステーションに割り当てられたホスト（またはサーバ）、欄１６４０にリストされ、そのワークステーションによって実行される機能のタイプ、欄１６５０にリストされ、そのワークステーションが実行することを許可されている役割、欄１６６０にリストされたそのワークステーションのＩＰアドレス、および欄１６７０にリストされたそのワークステーションに関する記述を含む。

欄１６１０に示したＩＤは、各ワークステーションごとに固有のものである。図１６に示した例では、ＩＤはワークステーションに対応するＭＡＣアドレスである。図１６に示したサイトは、「ルート」サイト、支店「Ａ」、または支店「Ｂ」のいずれかである。これらのサイトは、その組織内の物理的領域または論理的領域を表すことができる。ホスト名は、そのワークステーションによって使用されるサーバの名前である。そのワークステーションによって実行される機能のタイプとしては、管理機能、サーバ機能、およびクライアント機能を含む。「Ａ」で終わるタイプは管理機能に使用され、「Ｓ」で終わるタイプはサーバ機能に使用され、「Ｃ」で終わるタイプはクライアント機能に使用される。図１６で分かるように、いくつかのワークステーションは複数タイプの機能を実行する。たとえば、最初にリストされたワークステーションは、管理者機能とサーバ機能の両方を供する。役割は、そのワークステーション上で実行することが許可されている機能を示す。役割は概してクライアント機能に関連し、したがって、クライアント・タイプを備えていないワークステーションには役割が割り当てられていない。役割が割り当てられているワークステーションは複数の役割を有する場合が多い。たとえば、３番目にリストされたワークステーションは、そのワークステーション上で実行することが許可されている４つの役割（出納係、融資担当者、支店長、およびゲスト）を有する。しかし、４番目および５番目に示したワークステーションには、それぞれのワークステーション上で実行することが許可されている役割が１つしかない。ＩＰアドレスは、そのワークステーションに割り当てられたネットワーク・アドレスである。いくつかの環境ではＩＰアドレスは静的アドレスであり、他の環境ではＩＰアドレスが動的に割り当てられる。各ワークステーションの記述は任意選択であるが、特定のワークステーションと、このようなワークステーションが実行する役割を管理者がより適切に識別するのに役立つものである。

図１７は、内蔵タイプのデスクトップをサーバに配布するために実行されるステップを示す流れ図である。管理者デスクトップ配布処理は１７００から始まり、その後、配布用の第１のデスクトップが選択される（ステップ１７０５）。デスクトップ名と、ＣＲＣ値などの固有のシグニチャとを含む要求が作成される（ステップ１７１０）。作成されたデスクトップ要求は１つまたは複数のサーバに送信される（ステップ１７１５）。配布すべきデスクトップがそれ以上存在するかどうかに関する判別が行われる（判断１７２０）。配布すべきデスクトップがそれ以上存在する場合、判断１７２０は「Ｙｅｓ」分岐１７２２に分岐し、その後、処理は配布用の次のデスクトップを選択し（ステップ１７２５）、ループバックして要求を作成し、その要求をサーバに送信する。このループは、配布すべきデスクトップがそれ以上存在しなくなるまで継続し、その時点で判断１７２０は「Ｎｏ」分岐１７２８に分岐する。

事前に送信されたデスクトップ要求の結果として行われるサーバ応答は管理者によって受信される（ステップ１７３０）。その応答に基づいて、デスクトップがすでにサーバに存在するかどうかに関する判別が行われる（判断１７３５）。デスクトップがまだサーバに存在しない場合、判断１７３５は「Ｎｏ」分岐１７３８に分岐し、その後、識別されたデスクトップはデータ・ストリームとしてサーバに送信される（ステップ１７４０）。これに対して、デスクトップがすでにサーバに存在する場合、判断１７３５は「Ｙｅｓ」分岐１７４２に分岐し、ステップ１７４０を迂回する。

デスクトップ要求に関してサーバから受信すべき応答がそれ以上存在するかどうかに関する判別が行われる（判断１７４５）。応答がそれ以上存在する場合、判断１７４５は「Ｙｅｓ」分岐１７４６に分岐してループバックし、その応答を処理する。このループは、処理すべき応答がそれ以上存在しなくなるまで継続し、その時点で判断１７４５は「Ｎｏ」分岐１７４８に分岐し、管理者デスクトップ配布処理は１７５０で終了する。

サーバ・デスクトップ収集処理は１７５５から始まり、その後、サーバは管理者によって送信されたデスクトップ配布要求を受信する（ステップ１７６０）。管理者の要求に含まれるデスクトップ用の固有のＩＤは、現在、サーバ側が保有しているデスクトップ・データ１７６８と比較される（ステップ１７６５）。その比較に基づいて、サーバがそのデスクトップを必要とするかどうかに関する判別が行われる（判断１７７０）。そのデスクトップを必要としない（すなわち、そのデスクトップがすでにサーバに存在する）場合、判断１７７０は「Ｎｏ」分岐１７７２に分岐し、その後、サーバがそのデスクトップをすでに有していることを示すメッセージが管理者に送信され（ステップ１７７５）、サーバ処理は１７９５で終了する。

これに対して、サーバがまだそのデスクトップを有していない場合、判断１７７７０は「Ｙｅｓ」分岐１７７８に分岐し、その後、サーバはそのデスクトップを要求する（ステップ１７８０）。サーバは、その要求に応答してデスクトップ・データ・ストリームを受信する（ステップ１７８５）。次にサーバは、受信したデータ・ストリームから内蔵タイプのデスクトップ・ファイルを作成し、そのデスクトップ・ファイルをデスクトップ・データ・ストレージ・エリア１７６８に保管する（ステップ１７９０）。次にサーバ・デスクトップ収集処理は１７９８で終了する。

図１８は、内蔵タイプのデスクトップをサーバからクライアントに配布するために実行されるステップを示す流れ図である。クライアント・デスクトップ受信は１８００から始まり、その後、クライアントは、デスクトップ・リスト要求をサーバに送信する（ステップ１８０５）。デスクトップ・リスト要求は、クライアントのマシン（ワークステーション）ＩＤとクライアントのユーザＩＤとを含む。

サーバ・デスクトップ配布処理は１８４０から始まり、その後、サーバは、デスクトップ・リスト要求をクライアントから受信する（ステップ１８４５）。サーバは、ユーザ役割データ・ストア１８５２をサーチすることにより、ユーザに割り当てられている役割を調べる（ステップ１８５０）。また、サーバは、マシン役割データ・ストア１８５８をサーチすることにより、ユーザが使用しているワークステーションに割り当てられている役割も調べる（ステップ１８５５）。

サーバは、ユーザの役割とマシンの役割との共通部分またはオーバラップに基づくデスクトップ情報を検索し（ステップ１８６０）、デスクトップ・データ・ストア１８６２内でオーバラップする役割に対応するデスクトップを突き止める。検索されたデスクトップ情報は、デスクトップＩＤと、デスクトップを一意的に識別するために使用されるＣＲＣなどのデスクトップ・シグニチャとを含む。ユーザは、デフォルトの役割と、その役割に対応するデフォルト・デスクトップとを有することができる。ユーザがデフォルトの役割を有する場合、サーバはデフォルトの役割を判別する（ステップ１８６５）。

サーバは、有効な役割と、デスクトップ・シグニチャと、デフォルト・デスクトップＩＤ（適用可能な場合）と、デフォルトの役割（適用可能な場合）からなる応答ストリングを作成する（ステップ１８７０）。次にサーバは、その応答ストリングをクライアントに返す（ステップ１８７５）。

クライアントは、任意のデフォルトの役割およびデフォルト・デスクトップ情報とともに、ユーザとワークステーションの両方に割り当てられている役割を含むデスクトップ・リストをサーバから受信する（ステップ１８１０）。クライアントは、デスクトップ・リストに含まれるデスクトップを、クライアント・ワークステーション上ですでにキャッシュされているデスクトップと比較する（ステップ１８１５）。これは、事前にクライアント・ワークステーションに伝送されておらず、ワークステーションの揮発性または不揮発性ストレージ・エリアにキャッシュされていないデスクトップのみをクライアントが要求する必要があるように行われる。

クライアントは、まだクライアント・ワークステーション上にキャッシュされていないようなデスクトップまたはコンポーネントを識別することにより、追加のコンポーネントまたはデスクトップがサーバから必要とされているかどうかを判別する（判断１８２０）。追加のデスクトップ・コンポーネントがまったく必要とされていないとクライアントが判別した場合、判断１８２０は「Ｎｏ」分岐１８３２に分岐し（追加のデスクトップ情報を要求し検索するために使用されるステップを迂回する）、クライアント処理は１８３５で終了する。

これに対して、クライアントが追加のコンポーネントまたはデスクトップを必要とする場合、判断１８２０は「Ｙｅｓ」分岐１８２２に分岐し、その後、必要なデスクトップがサーバから要求される（ステップ１８２５）。この要求は、サーバ・ステップ１８８５でサーバによって受信される。サーバは、要求デスクトップ情報をデスクトップ・データ・ストア１８６２から検索し、それをクライアント・ワークステーションに返すことによって応答する（ステップ１８９０）。次にサーバ・デスクトップ配布処理は１８９５で終了する。

クライアント処理に戻ると、クライアントはステップ１８３０で要求したデスクトップ情報を受信してキャッシュし、クライアント・デスクトップ受信処理は１８３５で終了する。

図１９は、カスタム・アプリケーション拡張を作成するために実行されるステップを示す流れ図である。カスタム・アプリケーション拡張は、第三者が既存のオブジェクト指向クラスを拡張して、特定の組織の必要により適切に対応するようにサーバ・クラス・オブジェクトの動作（behavior）または属性を変更できるようにするものである。カスタム・アプリケーション拡張作成処理は１９００から始まり、その後、特定のコンポーネント・インターフェースを実現するクライアント・オブジェクト指向クラスが提供される（ステップ１９１０）。サーバ抽象クラスを拡張すべきかどうかに関する判別が行われる（判断１９２０）。抽象クラスを拡張しない場合、判断１９２０は「Ｎｏ」分岐１９２５に分岐し、その後、デフォルト・サーバ・コンポーネントがそのコンポーネント・インターフェースに使用される（ステップ１９３０）。これに対して、抽象クラスを拡張する場合、判断１９２０は「Ｙｅｓ」分岐１９３５に分岐し、その後、サーバ・コンポーネント抽象クラスを拡張するサーバ・クラスが提供される（ステップ１９４０）。

カスタム・アプリケーション拡張のために追加のリソースが必要であるかどうかに関する判別が行われる（判断１９５０）。追加のリソースが必要である場合、判断１９５０は「Ｙｅｓ」分岐１９５５に分岐し、その後、アプリケーション拡張によって使用される追加のリソースが提供される（ステップ１９６０）。追加のリソースとしては、アプリケーション拡張によって使用されるイメージ、プロパティ・ファイル、およびその他のクラス・ファイルを含むことができる。これに対して、追加のリソースが必要ではない場合、判断１９５０は「Ｎｏ」分岐１９６５に分岐し、ステップ１９６０を迂回する。

クライアント・クラス、サーバ・クラス、および任意の追加のリソースはＪａｖａアーカイブ（ＪＡＲ）ファイルにパッケージ化される（ステップ１９７０）。パッケージ化されたカスタム拡張はカスタム拡張ライブラリ１９８０に保管される。カスタム・アプリケーション拡張プロセスの作成は１９９５で終了する。

図２０は、アプリケーション拡張ライフサイクルを示す流れ図である。アプリケーション拡張ライフサイクルはステップ２０００から始まる。アプリケーション拡張ライフサイクルの第１のフェーズ中に、アプリケーション拡張は引数なしコンストラクタ（no-arg constructor）を使用する（ステップ２０２５）。引数なしコンストラクタは、そのＪａｖａインプリメンテーション・クラスをロードし、引数なしコンストラクタを呼び出すことにより、アプリケーション拡張コンポーネントを作成するために使用される。この時点で、アプリケーション拡張コンポーネントは、クライアント・デスクトップへの参照をまったく備えておらず、デスクトップ環境と相互作用することができない。このフェーズ中に、インスタンス変数およびデフォルト設定が初期化される。

アプリケーション拡張ライフサイクルの次のフェーズ中に、アプリケーション拡張が初期化する（ステップ２０５０）。この初期化フェーズ中に、アプリケーション拡張に対応する初期化済みメソッドがコンポーネント・インターフェースで定義される。また、コンポーネント構成項目への参照、初期ロケール情報、およびデスクトップ参照も提供される。デスクトップ参照は好ましくは、このフェーズ中にインスタンス変数として保管される。

アプリケーション拡張ライフサイクルの最終フェーズ中に、アプリケーション拡張に対応するｓｔａｒｔメソッドが呼び出される（ステップ２０７５）。ｓｔａｒｔメソッドはデスクトップによって呼び出される。たとえば、ｓｔａｒｔメソッドは、アプリケーション拡張に対応するアイコンがユーザによって選択されたときに呼び出すことができる。このフェーズ中に、アプリケーション拡張は、デスクトップ参照ならびに他のデスクトップ・コンポーネントへの参照を使用することができる。加えて、アプリケーション拡張はこの時点で、スレッドを開始し、入出力操作を実行することができる。

図２１は、管理者から複数クライアントに配布されるコンポーネントおよびリソースを示すブロック図である。管理者２１００は、パッケージを様々なサーバに伝送することにより、様々なデスクトップ・パッケージ２１１０にパッケージ化されたコンポーネントおよびリソース・ライブラリ２１０５を公開する。

図２１に示した例では、管理者からデスクトップ・パッケージを受信するサーバが３つ存在する。これらのサーバは、サーバ２１２０と、サーバ２１４０と、サーバ２１６０とを含む。それぞれのサーバは、管理者から受信したデスクトップ・パッケージを保管するための不揮発性ストレージ・エリアを含む。サーバ２１２０はデスクトップ・パッケージを保管するために不揮発性ストレージ・エリア２１２５を使用し、サーバ２１４０は不揮発性ストレージ・エリア２１４５を使用し、サーバ２１６０は不揮発性ストレージ・エリア２１６５を使用する。デスクトップ・パッケージは、図１７に記載したプロセスで管理者からサーバに配布される。これらのサーバは、様々なクライアントにデスクトップ・パッケージを提供するために使用される。

図２１に示した例では、それぞれのサーバからデスクトップ・パッケージを受信するクライアントが２つずつ存在する。クライアント２１３０および２１３５はサーバ２１２０からデスクトップを受信し、クライアント２１５０および２１５５はサーバ２１４０からデスクトップを受信し、クライアント２１７０および２１７５はサーバ２１６０からデスクトップを受信する。デスクトップは、図１８に記載したプロセスを使用してサーバからクライアントに配布される。このように、様々な内蔵タイプのデスクトップで使用されるコンポーネントおよびリソースは、システム全体に渡って管理者からサーバに、さらに最終的にクライアントに配布される。

図２２は、管理者によるデータ喪失後にサーバから管理者によって回復されるコンポーネントおよびリソースを示すブロック図である。コンピュータ・クラッシュ、火災、または洪水などの災害イベントが発生すると、管理者は、様々な内蔵タイプのデスクトップを作成するために使用したコンポーネントおよびリソースがない状態で取り残される可能性がある。これらのファイルを回復するために、管理者２１００は、デスクトップ・パッケージを構成するコンポーネントを含むデスクトップ・パッケージを様々なサーバから要求する。図２１に記載したトポグラフィ（topography）を使用して、管理者はサーバ２１２０、２１４０、および２１６０からパッケージを要求する。サーバは、それぞれストレージ・エリア２１２５、２１４５、および２１６５から、デスクトップ・パッケージを含む内蔵タイプのデスクトップ・パッケージを検索する。デスクトップ情報は、様々なサーバから管理者に返送される。管理者は、復元したパッケージ・ライブラリ２１８０に、受信した内蔵タイプのデスクトップ・パッケージを保管する。内蔵タイプのデスクトップに含まれるコンポーネントおよびリソースは、デスクトップ・ファイルから抽出され、復元したコンポーネントおよびリソース・ライブラリ２１９０に保管される。このように、管理者は、事前に様々なサーバに公開されているコンポーネントおよびリソースを回復し復元することができる。この回復は、そのコンポーネントおよびリソースの個別のバックアップ・コピーを管理者に作成させる必要なしに実行される。コンポーネントおよびリソースは固有のＩＤを含むので、複数バージョンまたはレベルのコンポーネントおよびリソースも回復することができる。デスクトップ・データを回復するために管理者によって実行されるステップを示す流れ図は図２３に示されている。

図２３は、内蔵タイプのデスクトップを配布し、その後、災害イベント後に内蔵タイプのデスクトップを回復する際に管理者によって実行されるステップを示す流れ図である。管理者処理は２２００から始まり、その後、管理者は内蔵タイプのデスクトップに使用されるコンポーネントおよびリソースを作成する（ステップ２２０５）。これらのコンポーネントおよびリソースは、不揮発性ストレージ・エリア２２１０に保管されたライブラリに保管される。

コンポーネントおよびリソースは、ユーザの役割に基づいて様々なユーザによる使用のために様々な内蔵タイプのデスクトップにパッケージ化される（ステップ２２１５）。内蔵タイプのデスクトップは、内蔵タイプのデスクトップ・ライブラリ２２２５に保管される。内蔵タイプのデスクトップは、様々なサーバに配布される（ステップ２２２０）。管理者配布処理は２２３０で終了する。内蔵タイプのデスクトップの配布に関する詳細は、図１７に記載されている。

内蔵タイプのデスクトップのサーバ受信は２２３５から始まり、その後、サーバは内蔵タイプのデスクトップ・パッケージを受信し、受信したパッケージを不揮発性ストレージ・エリア２２４５に保管する（ステップ２２４０）。次にサーバは、必要に応じてクライアントに内蔵タイプのデスクトップを配布する（ステップ２２５０）。内蔵タイプのデスクトップの配布に関する詳細は、図１８に記載されている。

ある時点で、コンピュータ・システムからのパッケージ、リソース、およびコンポーネントと、管理者によって使用されるストレージ・デバイスを破壊する災害イベントが発生する（ステップ２２５５）。その場合、内蔵タイプのデスクトップ情報は、ステップ２２６０から始まる回復プロセスを使用して、管理者によって回復される。管理者は、破壊され、もはや管理者のコンピュータ・システム上に保管されていない固有のパッケージを識別する（ステップ２２６５）。識別されたパッケージは、様々なサーバから要求される（ステップ２２７０）。

サーバは管理者からデスクトップ・パッケージ要求を受信する（ステップ２２７５）。要求されたデスクトップ・パッケージは、サーバの不揮発性ストレージ・エリア２２４５から検索され、管理者のコンピュータ・システムに伝送され（ステップ２２８０）、サーバ回復処理は２２９５で終了する。

管理者コンピュータ・システムは、サーバによって送信された内蔵タイプのデスクトップ・パッケージを受信し、受信したデスクトップ・パッケージをパッケージ・ライブラリ２２２５に保管する（ステップ２２８５）。内蔵タイプのデスクトップ・パッケージはアンパックされ、内蔵タイプのデスクトップ・パッケージに含まれるコンポーネントおよびリソースは、コンポーネントおよびリソース・ライブラリ２２１０に再取込みするために使用される（ステップ２２９０）。この時点で、管理者によって事前に配布されたすべてのパッケージ、コンポーネント、およびリソースは、すでに回復され、適切なライブラリに保管されている。次に管理者回復処理は２２９８で終了する。

図２４は、組織内のクライアントの役割（複数も可）に基づいてデスクトップを受信し表示するためにクライアントによって実行されるステップを示す流れ図である。処理は２３００から始まり、その後、クライアント・マシンはサーバから第１のデスクトップを受信する（ステップ２３０５）。受信したデスクトップは、クライアントのローカル・ストレージ２３１５上の揮発性または不揮発性ストレージ・エリアに保管される（ステップ２３１０）。

受信したデスクトップがクライアント用のデフォルト・デスクトップであるかどうかに関する判別が行われる（判断２３２０）。受信したデスクトップがデフォルト・デスクトップである場合、判断２３２０は「Ｙｅｓ」分岐２３２５に分岐し、その後、受信したデスクトップがクライアントのディスプレイ装置上に表示される（ステップ２３３０）。これに対して、受信したデスクトップがデフォルト・デスクトップではない場合、判断２３２０は「Ｎｏ」分岐２３３５に分岐し、ステップ２３３０を迂回する。

クライアント・マシンがサーバから受信すべきデスクトップがそれ以上存在するかどうかに関する判別が行われる（判断２３４０）。受信すべきデスクトップがそれ以上存在する場合、判断２３４０は「Ｙｅｓ」分岐２３４５に分岐し、その後、処理はループバックして次のデスクトップを受信し（ステップ２３５０）、次のデスクトップがデフォルト・デスクトップであるかどうかを判別する。このループは、必要なデスクトップがすべてサーバから受信されるまで継続し、その時点で判断２３４０は「Ｎｏ」分岐２３５５に分岐する。

２つ以上のデスクトップがクライアントによってアクセス可能であるかどうかに関する判別が行われる（判断２３８０）。２つ以上のデスクトップがアクセス可能である場合、判断２３８０は「Ｙｅｓ」分岐２３８５に分岐し、その後、使用可能なデスクトップの記述は、クライアントによってアクセス可能なポップアップ選択ウィンドウ内の項目として挿入される（ステップ２３９０）。たとえば、ユーザは、それによりポップアップ・メニューを表示させることになる、マウスなどのポインティング・デバイスを使用して、デスクトップ・エリア内で「右」クリックすることができるであろう。次にユーザは、ポップアップ・メニューに示されたリストから所望のデスクトップを選択することができるであろう（デスクトップ画面およびポップアップ・メニューの一例については図２８を参照されたい）。たとえば、支店長が融資担当者の割当て役割も有する場合、支店長はポップアップ・メニューから融資担当者デスクトップを選択することができる。融資担当者デスクトップを選択した後、融資担当者機能に使用されるデスクトップ・コンポーネントが表示され、そのデスクトップ・エリアからアクセス可能になるであろう。これに対して、クライアントによってアクセス可能な２つ以上のデスクトップが存在しない場合、判断２３８０は「Ｎｏ」分岐２３９２に分岐し、ステップ２３９０を迂回する。次にデスクトップ表示処理は２３９５で終了する。

図２５は、ユーザの役割およびワークステーションの役割に基づいてデスクトップ情報をクライアントに提供するためにサーバによって実行されるステップを示す流れ図である。処理は２４００から始まり、その後、サーバはクライアント２４１０からデスクトップ要求を受信する（ステップ２４０５）。この要求は、クライアントのユーザＩＤと、パスワードと、クライアント・ワークステーションのＭＡＣアドレスとを含む。

サーバは、様々なワークステーション上で実行することを許可されている役割を含むワークステーション・テーブル２４２０からクライアントのＭＡＣアドレスを調べる（ステップ２４１５）。図示の例では、「１２３」というＭＡＣアドレスを備えたワークステーションは出納係機能と融資担当者機能の両方を実行することを許可されており、「４５６」というＭＡＣアドレスを備えたワークステーションは支店長機能のみを実行することを許可されている。

クライアントのＭＡＣアドレスがワークステーション・テーブルで見つかったかどうかに関する判別が行われる（判断２４２５）。そのＭＡＣアドレスが見つからなかった場合、判断２４２５は「Ｎｏ」分岐２４２８に分岐し、その後、クライアント・ワークステーション登録がシステムによって要求されているかどうかに関する判別が行われる（判断２４３０）。ワークステーション登録が要求されている場合、判断２４３０は「Ｙｅｓ」分岐２４３２に分岐し、その後、クライアントのワークステーションが登録されていないことを示すエラーがクライアントに返され（ステップ２４３５）、サーバ処理は２４４０で終了する。これに対して、ワークステーション登録が要求されていない場合、判断２４３０は「Ｎｏ」分岐２４４２に分岐し、処理は継続する。判断２４２５に戻り、クライアントのＭＡＣアドレスがワークステーション・テーブルで見つかった場合、判断２４２５は「Ｙｅｓ」分岐２４４５に分岐し、処理は継続する。

ユーザのＩＤに割り当てられている第１のデスクトップはユーザ・デスクトップ・テーブル２４５５から検索される（ステップ２４５０）。図示の例では、ユーザＩＤ「Ａｂｌｅ」は「出納係」の役割に割り当てられており、ユーザＩＤ「Ｊｏｎｅｓ」は「出納係」、「融資担当者」、および「支店長」の役割に割り当てられている。検索され、ユーザに割り当てられているデスクトップが、ユーザによって使用されているワークステーション上で使用することを許可されているかどうかに関する判別が行われる（判断２４６０）。そのデスクトップがワークステーション上で使用することを許可されている場合、判断２４６０は「Ｙｅｓ」分岐２４６５に分岐し、その後、そのデスクトップはクライアントに送信される（ステップ２４７０）。これに対して、検索されたデスクトップがワークステーション上で使用することを許可されていない場合、判断２４６０は「Ｎｏ」分岐２４７２に分岐し、ステップ２４７０を迂回する。

そのユーザに割り当てられている役割またはデスクトップがそれ以上存在するかどうかに関する判別が行われる（判断２４７５）。そのユーザに割り当てられている役割がそれ以上存在する場合、判断２４７５は「Ｙｅｓ」分岐２４８０に分岐し、その後、そのユーザに割り当てられている次のデスクトップが選択され（ステップ２４８５）、処理はループバックして、次のデスクトップをクライアントに設定すべきかどうかを判別する。このループは、そのユーザに割り当てられているすべてのデスクトップが処理されるまで継続し、その時点で判断２４７５は「Ｎｏ」分岐２４９０に分岐し、サーバ処理は２４９５で終了する。

図２６は、サーバによって実行される処理と、サーバ、クライアント、管理者間の相互作用とを示すブロック図である。サーバ２５００は、管理者２５７５から役割割当てを受信することにより、役割識別機能２５７０を実行する。役割割当ては、そのユーザに割り当てられている役割ならびにネットワーク全体に渡って配置されたワークステーションに割り当てられている役割を含む。ワークステーションの役割はワークステーションの役割データ・ストア２５６０に保管される。ユーザの役割はユーザの役割データ・ストア２５５５に保管される。

サーバ２５００は、管理者２５７５からデスクトップ情報を受信することにより、デスクトップ収集処理２５８０も実行する。デスクトップ情報はデスクトップ定義データ・ストア２５９０に保管される。デスクトップ情報は、クライアント２５２５による使用のためのデスクトップ・コンポーネントおよびリソースを含む内蔵タイプのデスクトップを含む。

サーバ２５００は、クライアントを認証するために使用される、ユーザＩＤおよびパスワードなどの認証情報をクライアント２５２５から受信する。サーバ２５００は、認証データ・ストア２５２０内に位置する認証データによってクライアントの認証情報をチェックすることにより、認証処理２５１０を実行する。クライアントが認証されると、クライアントは、サーバ２５００上に保管されているクライアントのデータ・ストレージ・エリア２５４０へのアクセス権を受信する。サーバは、ホーム・ディレクトリ・アクセス・プロセス２５３０を実行することにより、クライアントのデータ・ストレージへのアクセスを可能にする。このように、ユーザは、自分がどのワークステーションを使用しているかにかかわらず、自分のデータにアクセスすることができる。

サーバ２５００は、デスクトップ配布プロセス２５５０を実行して、どの内蔵タイプのデスクトップをクライアント２５２５に送信すべきかを判別する。デスクトップ配布プロセス２５５０は、ユーザの役割データ・ストア２５５５に保管されているユーザの役割をワークステーションの役割データ・ストア２５６０に保管されているワークステーションの役割と比較することによって実行される。ユーザとワークステーションの両方に割り当てられているデスクトップまたは役割はクライアントに配布される。サーバ２５００は、デスクトップ・データ・ストア２５９０からデスクトップ情報を検索し、そのデスクトップ情報をクライアント２５２５に伝送する。

図２７は、内蔵タイプのデスクトップを初期化し表示する際にクライアントによって実行されるステップを示す流れ図である。クライアント２６００は、対応する情報をサーバに送信することにより、認証要求、ホーム・ディレクトリ要求、およびパスワード更新を実行する。クライアント２６００は、基礎となるオペレーティング・システム・プラットフォーム２６１０を使用して、ネイティブ操作を実行する。ＪＳＬＬＩＢ２６８０は、ネイティブ操作を実行するために使用されるネイティブ・コマンドおよびプログラムを含むネイティブ・ライブラリである。

シェル２６０５は、このシステムで使用されるオペレーティング・システム・プラットフォーム（たとえば、Ｗｉｎｄｏｗｓ ＸＰ（商標）、ＯＳ／２（商標）、またはＬｉｎｕｘ（商標））のいずれかで実行されるように適合されたＪａｖａベースのアプリケーションである。シェルは、クライアント・ログインがサーバによりリモートで実行されるかまたはローカルで実行されるかに関する判別を行う（判断２６２０）。ログインがリモートで実行される場合、判断２６２０は「Ｙｅｓ」分岐２６２２に分岐し、その後、クライアントはサーバからデスクトップを受信する（ステップ２６２５）。一実施形態では、まずデスクトップのリストを受信し、次に個々のデスクトップをそのリストから検索することにより、デスクトップが受信される。

デスクトップのリストまたはマップは、クライアント・マシン上に位置するローカル・ストレージにキャッシュされる（ステップ２６３０）。受信したデスクトップもローカル・ストレージにキャッシュされる（ステップ２６３５）。判断２６２０に戻ると、そのデスクトップがリモートで検索されない場合、判断２６２０は「Ｎｏ」分岐２６３８に分岐し、ステップ２６２５、２６３０、および２６３５を迂回する。

ユーザとワークステーションの両方に割り当てられているデスクトップはローカル・ストレージから検索される（ステップ２６４０）。ローカル・ストレージは、ユーザ・デスクトップ・マップ２６６０とデスクトップ２６７０を保管するために使用される。デスクトップは、そのデスクトップを表示し実行するために必要なデスクトップ・コンポーネントおよびリソースを含む内蔵タイプのパッケージである。検索されたデスクトップ情報は、デスクトップ・オブジェクトを作成するために使用される（ステップ２６４５）。デスクトップ・クラス・ローダ２６５０は、デスクトップ・オブジェクトを作成するために使用される。各国語変換などのリソースはデスクトップ情報からロードされる（ステップ２６５５）。また、デスクトップ・クラス・ローダ２６５０は、必要なリソースをロードするためにも使用される。

この時点で、ワークステーション内でそのユーザに割り当てられているデスクトップは、シェル２６０５内で検索され、そのユーザにとって使用可能なものになっている。デスクトップ・オブジェクトおよびリソースは、内蔵タイプのデスクトップから抽出され、シェル２６０５によりそのユーザにとって使用可能なものになっている。

図２８は、クライアントにとって使用可能な他の内蔵タイプのデスクトップのポップアップ・メニューとともにクライアント・ワークステーション上に表示されるサンプル・デスクトップの画面レイアウトである。デスクトップ画面レイアウト２７００は、いくつかのオブジェクト２７５０を含む。オブジェクト２７５０は、デスクトップからアクセス可能なデスクトップ・コンポーネントを含む。各デスクトップ・コンポーネントは、マウスなどのポインティング・デバイスを使用してユーザによって選択可能な、アイコンなどの１つのグラフィカル・イメージに対応する。

ポップアップ・メニュー２７１０は、ユーザがデスクトップを変更するかまたはシェル・バージョンを表示できるようにする２つの項目を含む。「デスクトップの変更」という項目を選択すると、デスクトップ選択メニュー２７２０の表示が行われる。ユーザは、所望のデスクトップのそばのボックス内にチェック・マークを付けることにより、所望のデスクトップを選択する。図示の例では、デスクトップ選択メニュー２７２０に示されたチェック・マークによって明示する通り、クライアント・ディスプレイ上に「管理者」デスクトップが表示されている。ユーザがデスクトップを、たとえば、支店長デスクトップに変更したいと希望する場合、ユーザは単に、マウスなどのポインティング・デバイスを使用し、「支店長」メニュー項目の隣のボックス内にチェック・マークを付けるだけである。

コンポーネント２７５０は、選択されたデスクトップに応じて変化する可能性がある。たとえば、「管理者」デスクトップが選択されたので、「支店デスクトップ管理者」デスクトップ・コンポーネントが表示される。しかし、「出納係」デスクトップなどの他のデスクトップが選択された場合、「支店デスクトップ管理者」はもはや表示されなくなり、そのディスプレイからアクセス不能になる。このように、選択された役割用のコンポーネントは表示され、アクセス可能になり、異なる役割によって使用されるコンポーネントは表示されず、アクセス不能になる。その上、複数の役割によって使用されるコンポーネントはそれぞれ、その役割に対応する様々なデスクトップから使用可能である。

図２９は、デスクトップを表示し管理する際にクライアント・シェルによって使用されるディレクトリの階層図である。シェル・ホーム・ディレクトリ２８００は、デスクトップ機能を実行するためにクライアントによって使用されるいくつかのサブディレクトリを含む。一実施形態では、シェル・ホーム・ディレクトリおよびそのサブディレクトリは、クライアントによってアクセス可能なサーバ上に保管される。他の実施形態では、シェル・ホーム・ディレクトリおよびそのサブディレクトリは、クライアント・マシンにとってローカルの不揮発性ストレージ・デバイス上に保管される。ネイティブ・ライブラリ２８０５は、クライアントのオペレーティング・システム・プラットフォームとのインターフェースを取るために使用されるプログラムを保管するために使用されるサブディレクトリである。一実施形態では、ネイティブ・ライブラリ情報はＪａｖａアーカイブ（ＪＡＲ）ファイルに保管される。プロパティ・サブディレクトリ２８１０は、シェル・プログラムによって使用されるプロパティを保管するために使用されるサブディレクトリである。これらのプロパティとしては、シェル・プログラムによって使用される表示属性およびその他の構成項目を含むことができる。

デスクトップ・サブディレクトリ２８１５は、内蔵タイプのデスクトップ・ファイルが保管されるディレクトリである。一実施形態では、内蔵タイプのデスクトップ・ファイルはＪａｖａアーカイブ（ＪＡＲ）ファイルにパッケージ化される。このように、特定のデスクトップによって使用されるすべてのコンポーネントおよびリソースは、パッケージ化され、内蔵タイプのデスクトップＪＡＲファイルに含まれる。ログ・サブディレクトリ２８２０は、クライアントによって行われるアクションを詳述するクライアントベースのログを保管するために使用される。「構成（Conf）」サブディレクトリ２８２５は、シェル・アプリケーションによって使用される初期化情報を保管するために使用される。「ビン（Bin）」サブディレクトリ２８３０は、シェル・アプリケーションを立ち上げるために使用される、プログラム・ファイルなどの実行可能プログラムを保管するために使用される。

図３０は、シェル構成ファイルとともに含まれるセクションの階層図である。シェル構成ファイルはいくつかのセクションを含む。これらのセクションのそれぞれは、そのシェルの特定のアスペクトに関する情報を含む。一実施形態では、シェル構成ファイルは、いくつかのセクションを含むＸＭＬファイルである。このセクションは、シェル・アプリケーションによって使用される、各国語変換などのロケールに関する情報を含むロケール・セクション２８４０を含む。コンポーネント・セクション２８４５は、内蔵タイプのデスクトップとともに含まれるコンポーネントに関する情報を含む。コンポーネントとしては、ユーザが適切なアイコンまたはその他のコマンドを選択したときにそのデスクトップからアクセス可能なアプリケーションおよびその他のプログラムを含む。フォルダ・セクション２８５０は、そのデスクトップからアクセス可能な様々なフォルダに関する情報を含む。ツールバー・セクション２８５５は、表示され、そのデスクトップからアクセス可能な様々なツールバーに関する情報を含む。デスクトップ・セクション２８６０は、外観データおよびポリシー情報など、そのデスクトップに関する情報を含む。

図３１は、内蔵タイプのデスクトップ・ファイルに含まれるオブジェクトの階層図である。一実施形態では、内蔵タイプのデスクトップはＪａｖａアーカイブ（ＪＡＲ）ファイルである。内蔵タイプのデスクトップ・ファイル２８６５はいくつかのコンポーネントを含む。このコンポーネントは、内蔵タイプのデスクトップ・ファイルに含まれるオブジェクトを詳述するマニフェスト２８７０を含む。また、このコンポーネントは、シェル文書タイプ定義（ＤＴＤ）オブジェクト２８７５も含む。シェルＤＴＤオブジェクトは、シェルＸＭＬ文書内の内容を記述するためにどの種類の属性が使用されるかと、各タグが許可されている場所と、どのタグが他のタグ内に現れる可能性があるかを示す。クラス・オブジェクト２８８０は、そのデスクトップによって使用されるＪａｖａクラスを含む。リソース２８８５は、そのデスクトップによって使用される、各国語変換情報などのリソース情報を含む。ＪＡＲオブジェクト２８９０は、そのデスクトップによって必要とされ、他のＪＡＲファイルにパッケージ化される追加のオブジェクトを含む。ＸＭＬオブジェクト２８９５は、内蔵タイプのデスクトップを記述するために使用されるＸＭＬ文書を含む。

図３２は、クライアントのワークステーションを初期化して内蔵タイプのデスクトップを使用するために実行されるステップを示す流れ図である。処理は２９００から始まり、その後、ユーザ２９２０はユーザＩＤおよびパスワードの入力を促される（ステップ２９１０）。ユーザＩＤおよびパスワードがユーザから受信される（ステップ２９２５）。認証されると、Ｊａｖａ仮想マシン（ＪＶＭ）などの仮想マシンは、ＪＳＬによってクライアント・オペレーティング・システム・プラットフォーム上にロードされる（ステップ２９３０）。この仮想マシンは、Ｊａｖａアプリケーションなどのプラットフォーム中立コードを実行するように設計される。このように、複数の同じデスクトップをＪａｖａなどのプラットフォーム独立言語で作成し、必要な仮想マシンを実現している様々なプラットフォーム上でそれを実行することができる。

デスクトップ環境を提供し、クライアント・マシンによって使用されている基礎となるオペレーティング・システムにユーザがアクセスするのを防止するために、Ｊａｖａベースのロックダウン（lockdown）シェルが呼び出される（ステップ２９４０）。ワークステーションとユーザの両方に割り当てられているデスクトップがサーバから要求される（ステップ２９４５）。サーバ２９５０は、要求を受信し、内蔵タイプのデスクトップをクライアントに送信することによって応答する。クライアントは、サーバから応答を受信する（ステップ２９５５）。この応答は、エラーまたはデスクトップのリストになる可能性がある。

サーバからエラーが受信されたかどうかに関する判別が行われる（判断２９６０）。エラーが受信された場合、判断２９６０は「Ｙｅｓ」分岐２９６２に分岐し、その後、クライアントのディスプレイ装置上にエラー・メッセージが表示され（ステップ２９６５）、処理は２９９５で終了する。これに対して、エラーが受信されなかった場合、判断２９６０は「Ｎｏ」分岐２９６８に分岐し、その後、クライアントのディスプレイ装置上に表示すべきデスクトップが存在するかどうかに関する判別が行われる（判断２９７０）。クライアントのディスプレイ装置上に表示すべきデスクトップがまったく存在しない場合、判断２９７０は「Ｙｅｓ」分岐２９７２に分岐し、表示すべきデスクトップがまったくないことがユーザに通知され（ステップ２９７５）、処理は２９９５で終了する。これに対して、ユーザおよびワークステーションに割り当てられたデスクトップが存在する場合、判断２９７０は「Ｎｏ」分岐２９７８に分岐し、その後、クライアントのディスプレイ装置上にそのデスクトップが表示され（事前定義プロセス２９８０）、処理は２９９５で終了する。

図３３は、クライアント初期化中に実行されるステップを示す流れ図である。処理は３０００から始まり、その後、ネイティブ・ログイン・コードが実行される（ステップ３００５）。ログイン・データは、ユーザから収集され、処理のためにサーバに送信される（ステップ３０１０）。サーバは、ステップ３０１５で受信された応答をクライアントに返送する。

ユーザが認証されたかどうかに関する判別が行われる（判断３０２０）。ユーザが認証されなかった場合、判断３０２０は「Ｎｏ」分岐３０２５に分岐し、その後、処理は３０３０で終了する。これに対して、ユーザが認証された場合、判断３０２０は「Ｙｅｓ」分岐３０３５に分岐して初期化を継続する。

Ｊａｖａ仮想マシンなどの仮想マシン・アプリケーションはクライアント・ワークステーション上で呼び出される（ステップ３０４０）。シェルをロックし、ユーザがそのシェル環境を使用せずに基礎となるオペレーティング・システムを使用するのを防止するために、ロックダウン・プロセスがＪａｖａ環境で立ち上げられる（ステップ３０４５）。サーバは、ユーザ／ワークステーションに割り当てられているデスクトップについて照会される（ステップ３０５０）。クライアントは、使用可能なデスクトップのリストを受信し、リストされたデスクトップ情報を、クライアント・ワークステーション上にすでにキャッシュされているデスクトップ・データと比較する（ステップ３０６０）。リストに含まれているが、まだクライアント・ワークステーション上にキャッシュされていないデスクトップは、サーバから検索され、クライアント・ワークステーション上にキャッシュされる（ステップ３０７０）。受信したデスクトップは、クライアントがアクセス可能なキャッシュ３０７５に保管される。初期またはデフォルトのデスクトップは使用可能なデスクトップのリストから選択される（ステップ３０８０）。次に、デフォルト・デスクトップを構成するコンポーネントは、ポップアップ・ウィンドウによりユーザにとって使用可能なものになっている他の使用可能なデスクトップとともにクライアント・ディスプレイ装置上に表示される（事前定義プロセス３０９０、デスクトップ・ディスプレイの例については図２８を参照されたい）。次にクライアント初期化処理は３０９５で終了する。

図３４は、ネイティブ・オペレーティング・システム・ログイン中に実行されるステップを示す流れ図である。ネイティブ・オペレーティング・システム・ログイン処理は３１００から始まり、その後、使用可能なネットワーク・ドメインのリストがユーザに表示される（ステップ３１１０）。ユーザによってそのリストからドメインが選択される（ステップ３１２０）。クライアントをローカルで認証するかまたはリモートで認証するかに関する判別が行われる（判断３１３０）。クライアントがローカルで認証される場合、判断３１３０は「Ｙｅｓ」分岐３１３５に分岐し、その後、ユーザはローカル・マシンで認証される（ステップ３１４０）。これに対して、ユーザがローカルで認証されない場合、判断３１３０は「Ｎｏ」分岐３１４５に分岐し、その後、ユーザは、クライアントが接続されているサーバ上で認証される（ステップ３１５０）。

クライアントが認証されたかどうかに関する判別が行われる（判断３１６０）。ユーザが認証されなかった場合、判断３１６０は「Ｎｏ」分岐３１６５に分岐し、その後、クライアントのディスプレイ装置上にエラーが表示され（ステップ３１７０）、処理は３１９５で終了する。これに対して、ユーザが認証された場合、判断３１６０は「Ｙｅｓ」分岐３１７５に分岐し、その後、Ｊａｖａシェル・ランチャが呼び出され（事前定義プロセス３１８０、処理の詳細については図３５を参照されたい）、処理は３１９５で終了する。

図３５は、Ｊａｖａシェル・ランチャを呼び出すときに実行されるステップを示す流れ図である。Ｊａｖａシェル・ランチャ実行は３２００から始まり、その後、クラス・パスまたはディレクトリが設定される（ステップ３２１０）。クライアント・コンピューティング・デバイス上にＪａｖａ仮想マシン（ＪＶＭ）がロードされる（ステップ３２２０）。

Ｊｓｈｅｌｌアプリケーションがリモートで立ち上げられるかまたはローカルで立ち上げられるかに関する判別が行われる（判断３２３０）。Ｊｓｈｅｌｌアプリケーションがローカルで立ち上げられる場合、判断３２３０は「ローカル」分岐３２３５に分岐し、その後、パラメータとしてそのユーザのユーザＩＤが指定されたＪｓｈｅｌｌアプリケーションが立ち上げられる（ステップ３２４０）。これに対して、Ｊｓｈｅｌｌアプリケーションがリモートで立ち上げられる場合、判断３２３０は「リモート」分岐３２４５に分岐し、その後、パラメータとしてサーバ・ホスト名、ユーザＩＤ、およびプラットフォームＩＤを提供することにより、Ｊｓｈｅｌｌアプリケーションがリモートで立ち上げられる（ステップ３２５０）。

Ｊｓｈｅｌｌアプリケーションが立ち上げられた後、ＪＳＬはＯＳウィンドウ・リストを列挙して、Ｊａｖａシェルに対応するウィンドウを見つける（ステップ３２６０）。Ｊａｖａシェル・ウィンドウが必ず前景に存続するように、Ｊａｖａシェル・ウィンドウがオペレーティング・システム・ウィンドウのＺ−オーダ・リスト（Z-order list）の最下部にピン固定される（ステップ３２７０）。Ｊａｖａシェル・ウィンドウは表示画面に収まるように最大化され、最小化ボタンおよびサイズ変更ボタンなどのすべてのフレーム・コントロールがＪａｖａシェル・ウィンドウから除去される（ステップ３２８０）。このように、シェル・アプリケーションはディスプレイ上の前景ページとして表示され、ユーザはネイティブ・オペレーティング・システム・プラットフォームによって提供されるシェル・ページの使用が妨げられる。Ｊａｖａシェル立上げ処理は３２９５で終了する。

図３６は、スマート・グラフィカル・コンポーネントの一例を示す画面レイアウトである。実際のコンテナ・タイプは、Ｃ＋＋およびＪａｖａのクラスまたはＣの構造体などのインプリメンテーション構成体（implementation construct）に対応する。このインプリメンテーション構成体はクラスタイプ（classtype）と呼ぶことにする。スマート・コンポーネントは、ランタイムでその親コンポーネント（たとえば、コンテナ）のクラスタイプを判別しようと試みる。識別されたクラスタイプが、そのコンポーネントが認識するタイプである場合、そのコンポーネントは識別されたクラスタイプに応じてその動作および外観を変更する。この動作および外観の変更は、スマート・コンポーネント内にプログラマチックに組み込むかまたは構成ファイルから読み取ることができる。親のクラスタイプが認識されない場合、そのコンポーネントは、認識されたコンテナが見つかるまでその親階層を上昇するようにプログラミングすることができる。このように、そのコンポーネントは、不明クラスタイプのコンテナ内部に配置することができるが、親コンテナ自体が既知のクラスタイプの他のコンテナ内部にある場合、そのコンポーネントは、既知のコンテナ・クラスタイプ内に直接配置されている場合と同様にそれ自体を構成することができる。

スマート・コンポーネントの外観および動作は、その親コンテナのクラスタイプによって判別される。たとえば、スマート・アイコンは、その親クラスタイプがデスクトップである場合にテキスト記述を表示することになる。しかし、同じスマート・アイコンは、その親クラスタイプがツールバーである場合にテキスト記述を表示しない。さらに、スマート・アイコン動作は、親コンテナの対応に応じて異なる可能性がある。たとえば、アイコンがツールバー内に配置されている場合、そのアイコンは、ユーザがマウス・ポインタをその上に置いたときに、それ自体の周りにボーダを描画するようにプログラミングすることができる。しかし、同じアイコンがデスクトップ上に配置されている場合、そのアイコンは、ポインタがその上を通過したときに、ボーダを表示しないようにプログラミングすることができる。加えて、スマート・アイコンは、それが属しているコンテナのタイプに応じて、起動時にそのコンポーネントに関する異なるコードを実行するようにプログラミングすることができる。

画面イメージ３３００は、タイム・クロック（timeclock ）の形のスマート・グラフィカル・コンポーネントの２つの例を含む。タイム・クロック３３０５は、ツールバー・コンテナ内に配置されたコンポーネントである。タイム・クロック３３３０は同じコンポーネントであるが、このときのタイム・クロックはデスクトップ・コンテナ内に配置されている。そのオブジェクトの外観および動作は、そのオブジェクトが属している親オブジェクトまたはコンテナのタイプに応じて変化する。図示の例では、タイム・クロック３３０５は、親ツールバー・コンテナ内で使用可能なエリアの方が小さいために、ディジタル時間として表示される。逆に、タイム・クロック３３３０は、デスクトップ・コンテナ内で使用可能なエリアの方が大きいために、アナログ時間を表示する。加えて、タイム・クロック３３３０は、アナログ・クロック・イメージの下にディジタル時間と日付などの追加の情報を表示する。さらに、タイム・クロック３３３０は、オブジェクトの下にそのオブジェクトの名前（すなわち、「クロック」）を表示する。

ユーザがツールバー内に位置するタイム・クロック３３０５を選択すると、ポップアップ・ウィンドウ３３２０が表示される。ポップアップ・ウィンドウ３３２０は、曜日、日付を表示し、時間／日付を調整するためのメニュー項目および通知を設定するためのメニュー項目を有する。

図３７は、スマート・グラフィカル・コンポーネントの第２の例を示す画面レイアウトである。画面イメージ３３５０は、図３６に示した画面イメージと同様のものであるが、図３７では、タイム・クロック３３３０はすでに選択されており、ポップアップ・メニュー３３９０が表示されている。図３７に示した表示されたポップアップ・メニューの動作は、図３６に示した同じタイム・クロック・コンポーネントについて示したものとは異なる。特に、図３７では、ユーザは、ディジタル・タイム・クロック、曜日、および日付表示をアナログ・クロックとともに示すべきかどうかに関する表示オプションを有する。これらの追加の表示オプションは、ツールバー・コンテナ内よりデスクトップ・コンテナ内の方がアイコンを示すために使用可能なサイズがより大きいために、使用可能になっている。

図３８は、様々なデスクトップ・オブジェクトを示す階層図である。デスクトップ・オブジェクト３４００は、階層図の最上部にあり、コンポーネント・オブジェクト３４１０とコンテナ・オブジェクト３４７０とを含む。コンポーネント・オブジェクト３４１０は、ビジュアル・コンポーネント３４２０と非ビジュアル・コンポーネント３４４０の両方を含む。ビジュアル・コンポーネント・オブジェクトとしては、アイコン３４２５、フォルダ３４３０、およびツールバー３４３５を含む。非ビジュアル・コンポーネント・オブジェクトとしては、アプリケーション拡張コード３４４５およびアプリケーション定義３４５０を含む。

名前が示す通り、コンテナ・オブジェクト３４７０は、他のオブジェクトを含むかまたは保持することができるオブジェクトを含む。コンテナ・オブジェクトとしては、フォルダ３４８０およびツールバー３４９０を含む。アイコンなどのビジュアル・コンポーネントは、コンテナ・オブジェクトに含めることができる。

図３９は、スマート・グラフィカル・コンポーネントを初期化する際に実行されるステップを示す流れ図である。スマート・グラフィカル・コンポーネント初期化処理は３５００から始まり、その後、コンポーネントについてオブジェクト指向の親オブジェクトが選択される（ステップ３５１０）。選択された親オブジェクト用のオブジェクト指向クラスタイプが検索される（ステップ３５２０）。検索されたクラスタイプがフォルダまたはツールバーなどの認識されたクラスタイプであるかどうかに関する判別が行われる（判断３５２５）。検索されたクラスタイプが認識されない場合、判断３５２５は「Ｎｏ」分岐３５４５に分岐し、その後、オブジェクト階層内に親がそれ以上存在するかどうかに関する判別が行われる（判断３５５０）。オブジェクト階層内に親がそれ以上存在する場合、最後に選択されたオブジェクトの親（すなわち、最後の親の親または対象オブジェクトの祖父母（grandparent））が選択され（ステップ３５６０）、処理はループバックして、新たに選択された親が認識されたクラスタイプであるかどうかを判別する。このループは、認識されたクラスタイプが見つかるかまたはオブジェクト階層内に親がそれ以上存在しなくなるまで継続する。認識されたクラスタイプが見つかった場合、判断３５２５は「Ｙｅｓ」分岐３５３０に分岐し、その後、認識されたクラスタイプが選択される（ステップ３５４０）。これに対して、オブジェクト階層内に親がそれ以上存在しない場合、判断３５５０は「Ｎｏ」分岐３５６５に分岐し、その後、そのオブジェクトについてデフォルト・クラスタイプが選択される（ステップ３５７０）。

アイコン・サイズおよびその他の表示特性などのコンポーネント外観データは、選択されたクラスタイプに対応するオブジェクト動作特性とともに検索される（ステップ３５７５）。たとえば、検索されたクラスタイプがツールバーである場合、アイコン・サイズおよび表示特性は、ツールバー内に表示されるアイコンに使用可能なエリアの方が小さいことに基づくものになるであろう。しかし、検索されたクラスタイプがデスクトップである場合、アイコン・サイズおよび表示特性は、デスクトップ内で使用可能なエリアの方が大きいことに基づくものである。

コンポーネントは、クラスタイプに対応する検索された外観データを使用して表示される。システムは、そのコンポーネントが呼び出されるのを待つ（ステップ３５８５、すなわち、そのコンポーネントがユーザによって選択されるまで待つ）。コンポーネントが呼び出されると、そのコンポーネントは、クラスタイプに対応する動作属性を使用して実行される（ステップ３５９０）。

図４０は、スマート・グラフィカル・コンポーネント用の表示属性を処理する際に実行されるステップを示す流れ図である。スマート・デスクトップ処理は３６００から始まり、その後、クラスタイプがツールバーであるかどうかに関する判別が行われる（判断３６０５）。クラスタイプがツールバーである場合、判断３６０５は「Ｙｅｓ」分岐３６１０に分岐し、その後、そのコンポーネント用のツールバー・アイコンが検索され、ツールバーに表示され（ステップ３６１５）、ツールバー内のアイコンの周りにボーダが描画され（ステップ３６２０）、処理は３６２５で終了する。

クラスタイプがツールバーではない場合、判断３６０５は「Ｎｏ」分岐３６３０に分岐し、その後、クラスタイプがフォルダであるかどうかに関する判別が行われる（判断３６３５）。クラスタイプがフォルダである場合、判断３６３５は「Ｙｅｓ」分岐３６４０に分岐し、その後、そのコンポーネント用のフォルダ・アイコンが検索され、フォルダに表示され（ステップ３６４５）、そのアイコンの下に短いコンポーネント記述が表示され（ステップ３６５０）、処理は３６５５で終了する。

クラスタイプがツールバーまたはフォルダではない場合、判断３６３５は「Ｎｏ」分岐３６６０に分岐し、その後、クラスタイプがデスクトップであるかどうかに関する判別が行われる（判断３６６５）。クラスタイプがデスクトップである場合、判断３６６５は「Ｙｅｓ」分岐３６６８に分岐し、その後、より大きいアイコンが検索され、デスクトップ上に表示され（ステップ３６７０）、そのアイコンの下により長いコンポーネント記述が表示され（ステップ３６７５）、処理は３６８０で終了する。

クラスタイプがツールバー、フォルダ、またはデスクトップではない場合、判断３６６５は「Ｎｏ」分岐３６８２に分岐し、その後、デフォルト・アイコンが検索され表示され（ステップ３６８５）、その他のデフォルト表示特性が検索され、そのアイコンに適用され（ステップ３６９０）、処理は３６９５で終了する。

図４１は、スマート・グラフィカル・コンポーネント用の動作属性を処理する際に実行されるステップを示す流れ図である。スマート・デスクトップ処理は３７００から始まり、その後、呼び出されたコンポーネントがツールバー・クラスタイプを備えた親を有するかどうかに関する判別が行われる（判断３７０５）。呼び出されたコンポーネントがツールバー親クラスタイプを有する場合、判断３７０５は「Ｙｅｓ」分岐３７１０に分岐し、その後、コンポーネントのツールバー動作が検索され（ステップ３７１５）、検索されたツールバー動作が実行され（ステップ３７２０）、処理は３７２５で終了する。

呼び出されたコンポーネントがツールバー・クラスタイプを備えた親を有していない場合、判断３７０５は「Ｎｏ」分岐３７３０に分岐し、その後、呼び出されたコンポーネントがフォルダ・クラスタイプを備えた親を有するかどうかに関する判別が行われる（判断３７３５）。呼び出されたコンポーネントがフォルダ親クラスタイプを有する場合、判断３７３５は「Ｙｅｓ」分岐３７４０に分岐し、その後、コンポーネントのフォルダ動作が検索され（ステップ３７４５）、実行され（ステップ３７５０）、処理は３７５５で終了する。

呼び出されたコンポーネントがツールバー・クラスタイプまたはフォルダ・クラスタイプを備えた親を有していない場合、判断３７３５は「Ｎｏ」分岐３７６０に分岐し、その後、呼び出されたコンポーネントがデスクトップ・クラスタイプを備えた親を有するかどうかに関する判別が行われる（判断３７６５）。呼び出されたコンポーネントがデスクトップ親クラスタイプを有する場合、判断３７６５は「Ｙｅｓ」分岐３７６８に分岐し、その後、コンポーネントのデスクトップ動作が検索され（ステップ３７７０）、実行され（ステップ３７７５）、処理は３７８０で終了する。

呼び出されたコンポーネントがツールバー、フォルダ、またはデスクトップのクラスタイプを備えた親を有していない場合、判断３７６５は「Ｎｏ」分岐３７８２に分岐し、その後、コンポーネント・デフォルト動作が検索され（ステップ３７８５）、実行され（ステップ３７９０）、処理は３７９５で終了する。

図４２は、本明細書に記載した操作を実行可能なコンピュータ・システムの単純化した一例である情報処理システム３８０１を示している。コンピュータ・システム３８０１は、ホスト・バス３８０５に結合されたプロセッサ３８００を含む。また、レベル２（Ｌ２）キャッシュ・メモリ３８１０もホスト・バス３８０５に結合される。ホスト／ＰＣＩブリッジ（Host-to-PCI bridge）３８１５は、メイン・メモリ３８２０に結合され、キャッシュ・メモリおよびメイン・メモリ制御機能を含み、ＰＣＩバス３８２５、プロセッサ３８００、Ｌ２キャッシュ３８１０、メイン・メモリ３８２０、およびホスト・バス３８０５間の転送を処理するためのバス制御を提供する。ＰＣＩバス３８２５は、たとえば、ＬＡＮカード３８３０を含む様々なデバイス用のインターフェースを提供する。ＰＣＩ／ＩＳＡブリッジ３８３５は、ＰＣＩバス３８２５とＩＳＡバス３８４０、ユニバーサル・シリアル・バス（ＵＳＢ）機能３８４５、ＩＤＥデバイス機能３８５０、およびパワー・マネージメント機能３８５５間の転送を処理するためのバス制御を提供し、リアルタイム・クロック（ＲＴＣ）、ＤＭＡ制御、割込みサポート、およびシステム管理バス・サポートなど、図示していない他の機能エレメントを含むことができる。周辺装置および入出力（Ｉ／Ｏ）装置は、様々なインターフェース３８６０（たとえば、ＩＳＡバス３８４０に結合されたパラレル・インターフェース３８６２、シリアル・インターフェース３８６４、赤外線（ＩＲ）インターフェース３８６６、キーボード・インターフェース３８６８、マウス・インターフェース３８７０、ハード・ディスク（ＨＤＤ）３８７２）に接続することができる。代わって、多くの入出力装置は、ＩＳＡバス３８４０に接続されたスーパ入出力コントローラ（図示せず）によって対処することができる。

ＢＩＯＳ３８８０は、ＩＳＡバス３８４０に結合され、様々な低レベル・システム機能およびシステム・ブート機能に必要なプロセッサ実行可能コードを組み込んでいる。ＢＩＯＳ３８８０は、磁気ストレージ・メディア、光ストレージ・メディア、フラッシュ・メモリ、ランダム・アクセス・メモリ、読取り専用メモリ、および命令をエンコードする信号（たとえば、ネットワークからの信号）を搬送する通信メディアを含む、任意のコンピュータ可読メディアに保管することができる。コンピュータ・システム３８０１を他のコンピュータ・システムに接続してネットワークによりファイルをコピーするために、ＬＡＮカード３８３０がＰＣＩバス３８２５およびＰＣＩ／ＩＳＡブリッジ３８３５に結合される。同様に、コンピュータ・システム３８０１をＩＳＰに接続して、電話回線接続を使用してインターネットに接続するために、モデム３８７５がシリアル・ポート３８６４およびＰＣＩ／ＩＳＡブリッジ３８３５に接続される。

図４２に記載したコンピュータ・システムは本明細書に記載した本発明を実行可能であるが、このコンピュータ・システムは単にコンピュータ・システムの一例にすぎない。当業者であれば、多くの他のコンピュータ・システム設計が本明細書に記載した本発明を実行可能であることが分かるであろう。

本発明の好ましい実現例の１つは、たとえば、コンピュータのランダム・アクセス・メモリに常駐可能なコード・モジュール内のアプリケーション、すなわち、１組の命令（プログラム・コード）である。その１組の命令は、コンピュータによって要求されるまで、他のコンピュータ・メモリ内に、たとえば、ハード・ディスク・ドライブ上に、もしくは光ディスク（最終的にＣＤ−ＲＯＭで使用するため）あるいはフレキシブル・ディスク（最終的にフレキシブル・ディスク・ドライブで使用するため）などのリムーバブル・ストレージ内に保管するか、またはインターネットもしくはその他のコンピュータ・ネットワークを介してダウンロードすることができる。したがって、本発明は、コンピュータで使用するためのコンピュータ・プログラムとして実現することができる。加えて、上述の様々な方法はソフトウェアによって選択的に起動されるかまたは認識される汎用コンピュータにおいて都合よく実現されるが、当業者であれば、このような方法がハードウェア、ファームウェア、または必要な方法ステップを実行するように構築されたより専門化された装置で実行できることも認識するであろう。

本発明の特定の諸実施形態について図示し説明してきたが、本明細書の教示に基づいて、本発明およびそのより広範囲な諸態様を逸脱せずに、変更および修正が可能であり、したがって、特許請求の範囲は本発明の真の精神および範囲内にあるような変更および修正のすべてをその範囲内に包含するものであることは、当業者には明白になるであろう。

内蔵タイプのデスクトップを使用するコンピュータ・システムのネットワーク図である。 内蔵タイプのデスクトップを提供する際に含まれるコンポーネントのブロック図である。 内蔵タイプのデスクトップを提供するために実行される管理者ステップを示す高レベル流れ図である。 特定のサイトをセットアップするために実行される管理者ステップを示す流れ図である。 ユーザをセットアップするために実行される管理者ステップを示す流れ図である。 ワークステーションをセットアップするために実行される管理者ステップを示す流れ図である。 アプリケーション拡張をセットアップするために実行される管理者ステップを示す流れ図である。 アプリケーション参照をセットアップするために実行される管理者ステップを示す流れ図である。 内蔵タイプのデスクトップを作成するために実行される管理者ステップを示す流れ図である。 内蔵タイプのデスクトップをクライアントに送達するためにサーバによって実行されるステップを示す流れ図である。 新規サイトをセットアップするために管理者によって使用される画面の画面レイアウトである。 所与のサイト用のデスクトップおよびマシンを管理するために管理者によって使用される画面の画面レイアウトである。 新規ユーザをセットアップするために管理者によって使用される画面の画面レイアウトである。 １つまたは複数の内蔵タイプのデスクトップ内のコンポーネントとして使用可能であるアプリケーションをセットアップするために管理者によって使用される画面の画面レイアウトである。 ネイティブ・アプリケーションをセットアップするために管理者によって使用される画面の画面レイアウトである。 ワークステーションを管理するために管理者によって使用される画面の画面レイアウトである。 内蔵タイプのデスクトップをサーバに配布するために実行されるステップを示す流れ図である。 内蔵タイプのデスクトップをサーバからクライアントに配布するために実行されるステップを示す流れ図である。 カスタム・アプリケーション拡張を作成するために実行されるステップを示す流れ図である。 アプリケーション拡張ライフサイクルを示す流れ図である。 管理者から複数クライアントに配布されるコンポーネントおよびリソースを示すブロック図である。 管理者によるデータ喪失後にサーバから管理者によって回復されるコンポーネントおよびリソースを示すブロック図である。 内蔵タイプのデスクトップを配布し、その後、災害イベント後にサーバから内蔵タイプのデスクトップを回復する際に管理者によって実行されるステップを示す流れ図である。 デスクトップを受信し表示するためにクライアントによって実行されるステップを示す流れ図である。 ユーザの役割およびワークステーションの役割に基づいてデスクトップ情報をクライアントに提供するためにサーバによって実行されるステップを示す流れ図である。 サーバによって実行される処理と、サーバ、クライアント、管理者間の相互作用とを示すブロック図である。 内蔵タイプのデスクトップを初期化し表示する際にクライアントによって実行されるステップを示す流れ図である。 クライアントにとって使用可能な他の内蔵タイプのデスクトップのポップアップ・メニューとともにクライアント・ワークステーション上に表示されるサンプル・デスクトップの画面レイアウトである。 デスクトップを表示し管理する際にクライアント・シェルによって使用されるディレクトリの階層図である。 シェル構成ファイルとともに含まれるセクションの階層図である。 内蔵タイプのデスクトップ・ファイルに含まれるオブジェクトの階層図である。 クライアントを初期化して内蔵タイプのデスクトップを使用するために実行されるステップを示す流れ図である。 クライアント初期化中に実行されるステップを示す流れ図である。 ネイティブ・オペレーティング・システム・ログイン中に実行されるステップを示す流れ図である。 Ｊａｖａシェル・ランチャを呼び出すときに実行されるステップを示す流れ図である。 スマート・グラフィカル・コンポーネントの一例を示す画面レイアウトである。 スマート・グラフィカル・コンポーネントの第２の例を示す画面レイアウトである。 様々なデスクトップ・オブジェクトを示す階層図である。 スマート・グラフィカル・コンポーネントを初期化する際に実行されるステップを示す流れ図である。 スマート・グラフィカル・コンポーネント用の表示属性を処理する際に実行されるステップを示す流れ図である。 スマート・グラフィカル・コンポーネント用の動作属性を処理する際に実行されるステップを示す流れ図である。 本発明を実現可能な情報処理システムのブロック図である。

Claims (22)

1. 第１のコンピュータ・システムがコンポーネント・ファイルを回復するための方法において、前記方法が、
   １つまたは複数のコンポーネント・ファイルを１つまたは複数の内蔵タイプのパッケージ・ファイルにパッケージ化するステップと、
   前記内蔵タイプのパッケージ・ファイルをコンピュータ・ネットワークにより１つまたは複数の第２のコンピュータ・システムに伝送するステップと、
   前記コンポーネント・ファイルのうちの１つまたは複数がもはや前記第１のコンピュータ・システムから使用不能になる災害イベントを識別するステップと、
   前記識別された災害イベントに応答して、前記第２のコンピュータ・システムのうちの１つまたは複数から前記内蔵タイプのパッケージ・ファイルのうちの１つまたは複数を要求するステップと、
   前記要求に応答して前記第２のコンピュータ・システムのうちの１つまたは複数から内蔵タイプのパッケージ・ファイルを受信するステップと、
   前記受信した内蔵タイプのパッケージ・ファイルから前記コンポーネントをアンパックするステップと、
   前記第１のコンピュータ・システムからアクセス可能な不揮発性ストレージ・デバイス上に前記コンポーネントを保管するステップと、
   を有する、方法。
2. 前記内蔵タイプのパッケージ・ファイルのそれぞれに含まれる前記コンポーネント・ファイルを詳述するマニフェスト・ファイルを作成するステップと、
   前記マニフェスト・ファイルに含まれる前記コンポーネント・ファイルを、前記災害イベント後に存在する前記コンポーネント・ファイルと比較するステップと、
   前記比較に基づいて、前記第２のコンピュータ・システムから要求するための前記内蔵タイプのパッケージ・ファイルを識別するステップと、
   をさらに有する、請求項１に記載の方法。
3. 前記内蔵タイプのパッケージ・ファイルのそれぞれに関するマニフェスト・ファイルを作成するステップであって、前記マニフェスト・ファイルが前記内蔵タイプのパッケージ・ファイルに含まれる前記コンポーネント・ファイルを詳述するステップと、
   前記コンポーネント・ファイルとともに、前記マニフェスト・ファイルを前記内蔵タイプのパッケージ・ファイルにパッケージ化するステップと、
   をさらに有する、請求項１に記載の方法。
4. 前記コンポーネント・ファイルのそれぞれおよび前記内蔵タイプのパッケージ・ファイルのそれぞれに固有のＩＤを割り当てるステップ
   をさらに有する、請求項１に記載の方法。
5. 前記第２のコンピュータ・システムから前記固有のＩＤのリストを受信するステップと、
   前記受信した固有のＩＤのリストを、前記災害イベント後に前記第１のコンピュータ・システム上に存在する内蔵タイプのパッケージ・ファイルと比較するステップと、
   前記比較に基づいて、前記第２のコンピュータ・システムから要求するための前記内蔵タイプのパッケージ・ファイルを識別するステップと、
   をさらに有する、請求項４に記載の方法。
6. 前記内蔵タイプのパッケージ・ファイルを作成するために前記第１のコンピュータ・システムが管理者によって使用され、前記内蔵タイプのパッケージ・ファイルのそれぞれが組織内のユーザによって実行される役割に対応する、請求項１に記載の方法。
7. 前記第２のコンピュータ・システムが、クライアント・コンピュータ・システムのユーザによって実行される役割に基づいて、前記内蔵タイプのパッケージ・ファイルを１つまたは複数のクライアント・コンピュータ・システムに提供するサーバ・コンピュータ・システムである、請求項１に記載の方法。
8. 前記内蔵タイプのパッケージ・ファイルに含めるべき前記コンポーネント・ファイルを選択するステップであって、前記コンポーネント・ファイルのうちの少なくとも１つが、複数のオペレーティング・システム上で実行されるように適合されるデスクトップ・シェルから立ち上げられるように適合されるプログラミング・コードを含むステップと、
   前記内蔵タイプのパッケージ・ファイルをパッケージ・ファイルのライブラリに保管するステップであって、前記パッケージ・ファイルのそれぞれが、クライアント・コンピュータ・システムに伝送されるように適合されるステップと、
   をさらに有する、請求項１に記載の方法。
9. 前記コンポーネント・ファイルのうちの少なくとも１つが、アイコン・ファイル、イメージ・ファイル、アプリケーション拡張ファイル、画面外観ファイル、各国語変換ファイル、クライアント構成ファイル、およびサーバ構成ファイルからなるグループから選択される、請求項１に記載の方法。
10. 前記災害イベントが、不揮発性ストレージ・デバイス障害、１つまたは複数のコンポーネント・ファイルの削除、１つまたは複数の内蔵タイプのパッケージ・ファイルの削除、コンピュータ・システム障害、自然災害、火災、および洪水からなるグループから選択される、請求項１に記載の方法。
11. １つまたは複数のプロセッサと、
    前記プロセッサによってアクセス可能なメモリ・エリアと、
    前記プロセッサによってアクセス可能な不揮発性ストレージ・デバイスと、
    第１のコンピュータ・システムを管理するために前記プロセッサによって実行されるオペレーティング・システムと、
    第１のコンピュータ・システムをコンピュータ・ネットワークに接続するために前記プロセッサによってアクセス可能なネットワーク・インターフェースと、
    コンポーネント・ファイルを回復するための回復ツールであって、
    １つまたは複数のコンポーネント・ファイルを前記不揮発性ストレージ・デバイス上に保管された１つまたは複数の内蔵タイプのパッケージ・ファイルにパッケージ化するための手段と、
    前記内蔵タイプのパッケージ・ファイルを前記コンピュータ・ネットワークにより１つまたは複数の第２のコンピュータ・システムに伝送するための手段と、
    識別された災害イベントに応答して、前記コンピュータ・システムのうちの１つまたは複数から前記内蔵タイプのパッケージ・ファイルのうちの１つまたは複数を要求するための手段と、
    前記要求に応答して前記コンピュータ・システムのうちの１つまたは複数から内蔵タイプのパッケージ・ファイルを受信するための手段と、
    前記受信した内蔵タイプのパッケージ・ファイルから前記コンポーネントをアンパックするための手段と、
    前記不揮発性ストレージ・デバイス上に前記コンポーネントを保管するための手段と、
    を含む回復ツールと、
    を有する、情報処理システム。
12. 前記内蔵タイプのパッケージ・ファイルのそれぞれに含まれる前記コンポーネント・ファイルを詳述するマニフェスト・ファイルを作成するための手段と、
    前記マニフェスト・ファイルに含まれる前記コンポーネント・ファイルを、前記災害イベント後に存在する前記コンポーネント・ファイルと比較するための手段と、
    前記比較に基づいて、前記第２のコンピュータ・システムから要求するための前記内蔵タイプのパッケージ・ファイルを識別するための手段と、
    をさらに有する、請求項１１に記載の情報処理システム。
13. 前記内蔵タイプのパッケージ・ファイルのそれぞれに関するマニフェスト・ファイルを作成するための手段であって、前記マニフェスト・ファイルが前記内蔵タイプのパッケージ・ファイルに含まれる前記コンポーネント・ファイルを詳述する手段と、
    前記コンポーネント・ファイルとともに、前記マニフェスト・ファイルを前記内蔵タイプのパッケージ・ファイルにパッケージ化するための手段と、
    をさらに有する、請求項１１に記載の情報処理システム。
14. 前記コンポーネント・ファイルのそれぞれおよび前記内蔵タイプのパッケージ・ファイルのそれぞれに固有のＩＤを割り当てるための手段
    をさらに有する、請求項１１に記載の情報処理システム。
15. 前記第２のコンピュータ・システムから前記固有のＩＤのリストを受信するための手段と、
    前記受信した固有のＩＤのリストを、前記災害イベント後に前記第１のコンピュータ・システム上に存在する内蔵タイプのパッケージ・ファイルと比較するための手段と、
    前記比較に基づいて、前記第２のコンピュータ・システムから要求するための前記内蔵タイプのパッケージ・ファイルを識別するための手段と、
    をさらに有する、請求項１４に記載の情報処理システム。
16. 前記内蔵タイプのパッケージ・ファイルを作成するために前記第１のコンピュータ・システムが管理者によって使用され、前記内蔵タイプのパッケージ・ファイルのそれぞれが組織内のユーザによって実行される役割に対応する、請求項１１に記載の情報処理システム。
17. 前記第２のコンピュータ・システムが、クライアント・コンピュータ・システムのユーザによって実行される役割に基づいて、前記内蔵タイプのパッケージ・ファイルを１つまたは複数のクライアント・コンピュータ・システムに提供するサーバ・コンピュータ・システムである、請求項１１に記載の情報処理システム。
18. 前記内蔵タイプのパッケージ・ファイルに含めるべき前記コンポーネント・ファイルを選択するための手段であって、前記コンポーネント・ファイルのうちの少なくとも１つが、複数のオペレーティング・システム上で実行されるように適合されるデスクトップ・シェルから立ち上げられるように適合されるプログラミング・コードを含む手段と、
    前記内蔵タイプのパッケージ・ファイルを前記不揮発性ストレージ・デバイス上に保管されたパッケージ・ファイルのライブラリに保管するための手段であって、前記パッケージ・ファイルのそれぞれが、クライアント・コンピュータ・システムに伝送されるように適合される手段と、
    をさらに有する、請求項１１に記載の情報処理システム。
19. 前記コンポーネント・ファイルのうちの少なくとも１つが、アイコン・ファイル、イメージ・ファイル、アプリケーション拡張ファイル、画面外観ファイル、各国語変換ファイル、クライアント構成ファイル、およびサーバ構成ファイルからなるグループから選択される、請求項１１に記載の情報処理システム。
20. 前記災害イベントが、不揮発性ストレージ・デバイス障害、１つまたは複数のコンポーネント・ファイルの削除、１つまたは複数の内蔵タイプのパッケージ・ファイルの削除、コンピュータ・システム障害、自然災害、火災、および洪水からなるグループから選択される、請求項１１に記載の情報処理システム。
21. プログラムがコンピュータ・システム内で実行されるときに、請求項１ないし２０のいずれかに記載の方法のステップをコンピュータに実行させるコンピュータ・プログラム。
22. 請求項２１に記載の前記コンピュータ・プログラムを記録したコンピュータ可読メディア。

Images