(57)【特許請求の範囲】
【請求項１】
コンピュータ・ネットワークを通じてデータを送信する前に前記データを準備する方法であって、
サーバ・コンピュータが、前記クライアント・コンピュータ及びサーバ・コンピュータの間の接続を確立し、
クライアント・コンピュータが、クライアント・プロフィールを前記サーバ・コンピュータへ送信し、
サーバ・コンピュータが、第１の複数のデータ・アイテムを含む第１データ・セットをサーバ・コンピュータ上で検索し、
サーバ・コンピュータが、第２の複数のデータ・アイテムを含む第２データ・セットをサーバ・コンピュータ上で検索し、
前記第１データ・セット及び第２データ・セットはクライアント・コンピュータに関連していることと、
サーバ・コンピュータが、前記第１データ・セット内のデータ・アイテムを前記第２データ・セット内のデータ・アイテムへ関連付けし、これによって、それぞれが前記第１データ・セットにおける一のデータ・アイテムと前記第２データ・セットにおける一のデータ・アイテムとの間の関連性を特定する複数のデータ・アイテム・コレスポンデンスを形成し、
サーバ・コンピュータが、前記クライアント・コンピュータと前記サーバ・コンピュータとの間でデータを交換するために用いられるソフトウェアのバージョンを決定し、
サーバ・コンピュータが、各データ・アイテム・コレスポンデンスにおいて特定された前記第１データ・セットにおける前記データ・アイテムおよび前記第２データ・セットにおける前記データ・アイテム間の優先順位を決定するために、一連のルールを前記複数のデータ・アイテム・コレスポンデンスへ適用し、
サーバ・コンピュータが、少なくとも前記第１データ・セットの一部と少なくとも前記第２データ・セットの一部とを組み合わせることにより、第３の複数のデータ・アイテムを含む第３データ・セットを導出することを含み、前記第３のデータセットには、前記各データ・アイテム・コレスポンデンスについて、前記優先順位に基づき前記第１データ・セットにおける前記データ・アイテムまたは前記第２データ・セットにおける前記データ・アイテムが含まれる、方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はコンピュータ・ソフトウェア及びコンピュータ・ネットワーク・アプリケーションに関する。より詳細には、本発明は、クライアント・サーバ・アプリケーションおよびコンピュータ・ネットワーク内の複数のコンピュータ間におけるコンフィギュレーション・データの交換に関する。
【０００２】
【従来の技術】
従来のコンピュータ・ネットワークの一類型では、クライアントと称される一連のパーソナル・コンピュータ（例：サン・スパーク・ワークステーションまたはＩＢＭパーソナル・コンピュータ）は、１つ以上のサーバ・コンピュータに対して接続する必要がある。クライアント・コンピュータは、一般的に独立しており、また、ユーザ・アプリケーションを実行すると共にネットワーク・オペレーションを実施するために必要な情報の殆どを自身のメモリ内に有する。即ち、クライアント・コンピュータはソフトウェア及びハードウェアの両方の機能及び要件に関する自身のコンフィギュレーションの情報を含む。ネットワーク・ソフトウェア・アプリケーションへのアクセス、電子メールの送受信及びネットワーク・データベースの情報の検索及び格納などの様々な理由から、クライアント・コンピュータはネットワーク・サーバへ一般的にアクセスする。しかし、一般的に、特定のクライアント・コンピュータ固有の情報は、そのクライアント・コンピュータ上に存在する。この情報には、例えば、メモリ容量、データバス種類数またはハードウェア仕様が含まれることが可能であり、ハードウェア仕様の例としては、データバスの種類または別のプロセッサの種類が挙げられる。クライアント・コンピュータは比較的に独立しており、かつ自身のコンフィギュレーション情報を格納している（従って、この情報はサーバ・コンピュータ上で入手できない）。このため、クライアント・コンピュータ上でのデータ管理及びアプリケーション管理のタスクは重荷になってきている。
【０００３】
ネットワークのサーバ上に存在するアプリケーションに対する小さな変更または調整を、クライアント・コンピュータへ伝播することは可能であるが、任意の大幅なアップグレード若しくは調整または新しいアプリケーションのインストールは、全てのクライアントが、ネットワーク管理者によって各クライアント・コンピュータがアクセスされると共に更新されることを要求する結果をもたらす。幾つかの企業では、ネットワークへ接続されたコンピュータの数は何万台にも及んでおり、アプリケーション・ソフトウェアまたは一般コンフィギュレーション・ソフトウェアに対する大幅な改訂またはアップグレードのインストールの負担は、高い費用を要する非能率的な長い時間を要する作業となっている。更に、殆どのクライアント・コンピュータは独立しているため、それぞれ異なる場所にある複数のクライアント・コンピュータを使用することを必要とする各ユーザが、アプリケーション及びコンフィギュレーション・データに関するパーソナル・プリファレンス（個人設定）を維持することは困難である。即ち、ユーザはパーソナル・プリファレンスを自分が常に使用するクライアント・コンピュータへデフォルトとしてインストール可能であるにもかかわらず、他のクライアント・コンピュータのデフォルトを変更することなくこれらのデフォルトを前記の他のクライアント・コンピュータへ複製できる。
【０００４】
別の種類のコンピュータ・ネットワーク・コンフィギュレーションは、メインフレーム・コンピュータへ一般的に接続されたダム・ターミナル、即ち、シン・クライアント（"thin" client）を使用している。この種のネットワークでは、ほぼ全ての処理及びデータはメインフレーム・コンピュータ上に存在する。シン・クライアントはこれらのアクティビティを一切遂行しない。この種のコンフィギュレーションでは、クライアントに関する全ての情報はメインフレーム・コンピュータのコントロール下にある。クライアント及びメインフレームの間の接続が終了した場合、全ての処理が停止し、クライアントは全てのアクティビティを実施できなくなる。
【０００５】
前記のように、従来のネットワーク・コンフィギュレーションでは、新しいソフトウェアまたは新しいアプリケーションをインストールするプロセスは静的プロセスである。このコンフィギュレーションでは、各パーソナル・コンピュータのコンフィギュレーション情報は各クライアント・マシン上で定義される。従って、ネットワーク管理者は各パーソナル・コンピュータ上の各コンフィギュレーションを静的に定義する必要がある。従来のコンピュータ・ネットワーク・コンフィギュレーションでは、特定の各サブシステム、即ち、クライアントのコンフィギュレーション情報は、このクライアント内でハードコードされている。更に、ネットワーク・サーバへ接続された複数の独立クライアントを使用する従来のネットワーク・コンフィギュレーションの場合、新バージョンのインストールまたはソフトウェアの大幅アップグレード（アップグレードはサブシステムのコンフィギュレーションに関する知識またはサブシステムのコンフィギュレーションへのアクセスを必要とする）などのアプリケーション・メインテナンスは、通常、アプリケーションまたはネットワークをダウンさせることを必要とする。
【０００６】
複数のクライアントと、クライアントが様々な理由から必要とする情報を有する１つのサーバとを備えた従来のコンピュータ・ネットワークの場合、クライアントが必要とするサーバ上の全データ、即ち、クライアントに関するサーバ上の全データは、サーバからクライアントへ転送されることが多い。一般的に、これは大量のデータの移動をともなう。これらのデータのうちの殆どはクライアントによって使用されない、即ち、クライアントのオペレーションに必要ない。全データをクライアントへ転送することは、非能率的であり、かつネットワーク・トラフィックを増大する。更に、クライアントはサーバから転送された自身に関連する全ての情報を格納する十分なメモリ及び記憶装置を有する必要がある。例えば、大容量の記憶装置を有さないＰＤＡ及びスマート・カードなどのデバイスは、自身に関連する可能性のあるコンフィギュレーション情報を含む全ての情報を自身のメモリ内に格納できない。
【０００７】
従って、この種のコンフィギュレーション情報を中央リポジトリに格納することによって、クライアント・コンフィギュレーションの分散管理をサポートするシステムを有することが望ましい。これは、ネットワーク管理者がサブシステムのコンフィギュレーションをサーバから管理することと、アプリケーションに対する全ての変更をサーバから伝播することを可能にする。ネットワーク・ユーザが異なる複数のクライアントへそれぞれログオンでき、かつ該ユーザーのパーソナル・プリファレンス及びプロフィールへネットワーク上の任意のクライアント上でアクセスできることが望ましい。更に、効率的で完全に機能するやり方で、データをサーバからクライアントへ転送することを可能にする方法を有することが望ましい。更に、クライアントが重複するデータを受信することがないように凝縮されたコンパクトなフォームのデータを、クライアントへ送信することが望ましい。
【０００８】
【発明の概要】
本発明の目的を達成すべく、ネットワーク内の複数のコンピュータ間におけるデータの格納及び交換を実施するためのデータ・フレームワーク及び関連するプロトコルを形成する方法、装置及びコンピュータ読み取り可能媒体を開示する。本発明の１つの態様に基づき、ルート・ノード層と、中間ノード層と、コンフィギュレーション・データを格納するデータ層とを含むｎ分岐ツリー構造を有するデータ・スキーマを開示する。中間ノード層はコンピュータ・ネットワークのコンポーネント及び様々な特徴に関するカテゴリカル情報を含む多数のノードを有する。ツリー構造において、各中間ノード及びルート・ノードは、その下に連なる複数のノードへの分岐を有する。これらの下位ノードは子ノードと称される。データ・ノード層はツリーの最下位に位置し、かつコンピュータ・ネットワークのコンポーネント及び他の特徴に関する実際の固有コンフィギュレーション・データを含む。複数の中間ノード及びデータ・ノードのうちの特定の一部は永続メモリ領域を形成している。永続メモリ領域を形成しているデータ・ノード内の実際の固有コンフィギュレーション・データは、クライアント・コンピュータまたはサーバ・コンピュータ上で変更され、かつサーバ・コンピュータ上に格納される。これによって、関連する固有情報は不揮発性となり、かつ多数のクライアント・コンピュータによるアクセスが可能である。
【０００９】
本発明の１つの実施形態では、データ・スキーマ、即ち、データ・フレームワークはクライアント・コンピュータ上に存在するクライアント・スキーマ・サブコンポーネントと、１つ以上のサーバ・コンピュータ上に存在するサーバ・スキーマ・サブコンポーネントとを含む。別の実施形態では、ユーザ・プリファレンス（ユーザ設定）及びプロフィールをサーバ・スキーマ内へ格納する。これによって、ネットワーク上のユーザはネットワーク上の複数のクライアント・コンピュータのうちの任意の１つを使用し、かつユーザ自身のプリファレンスへアクセスすることが可能になる。更に、クライアント・コンピュータ・プラットフォーム及びプロフィールの情報はサーバ・スキーマ内に格納される。更に別の実施形態では、前記の永続メモリ領域は多数のデータ・エントリを含み、各データ・エントリは名前と、関連するノードのリストと、プロパティ名と、関連するプロパティ値とを有する。
【００１０】
本発明の別の態様では、サーバ・コンピュータを有するコンピュータ・ネットワーク内のクライアント・コンピュータに関する情報をアレンジし、かつ格納するためのデータ・スキーマを開示する。データ・スキーマはルート・ノードと、中間ノードを有する多数の中間ノード・レベルとを含む。各中間ノードはコンピュータ・ネットワーク及びクライアント・コンピュータに関するカテゴリカル情報を示す、即ち、格納している。更に、スキーマは中間ノード内のカテゴリカル情報に対応する実際のコンフィギュレーション情報を含む。クライアント・コンピュータを起動し、かつネットワークへ接続した際に決定された様々なプロフィール及びプリファレンスに対するクライアント・コンピュータの適合を、クライアント・コンピュータ上に存在するカテゴリカル情報及びコンフィギュレーション情報は可能にする。
【００１１】
１つの実施形態では、多数の中間ノード・レベルは複数のトップ中間ノードを有するトップ中間ノード・レベルを含む。各トップ中間ノードは多数のデータ・エントリを有するデータスペースを形成している。別の実施形態では、複数のデータスペースのうちのソフトウェア・データスペースと称されるデータスペースは永続データスペースである。クライアント・コンピュータを切った際、即ち、機能停止した際、この永続データスペースはデータスペース内のデータ・エントリの保存を可能にする。
【００１２】
本発明の別の態様では、データ・スキーマを格納するサーバ・コンピュータを有するコンピュータ・ネットワーク内の多数のクライアント・コンピュータに関するコンフィギュレーション情報をアレンジし、かつ格納するためのデータ・スキーマを開示する。このデータ・スキーマはルート・ノードと、複数の中間ノードを有する多数の中間ノード・レベルとを含む。各中間ノードはコンピュータ・ネットワークと、このコンピュータ・ネットワーク上のクライアント・コンピュータとに関するカテゴリカル情報を示す、即ち、格納する。更に、データ・スキーマのデータ・レベル内に配置された中間ノード内のカテゴリカル情報に対応する実際のコンフィギュレーション情報をデータ・スキーマはさらに含む。カテゴリカル情報及びコンフィギュレーション情報は、サーバ・コンピュータ上に存在し、これによって、クライアント・コンピュータからのリクエストを受けた際、サーバ・コンピュータがクライアント・コンピュータ・プロフィール及びプリファレンスを伝播することを可能にする。
【００１３】
１つの実施形態では、多数の中間ノード・レベルは複数のトップ中間ノードを有するトップ中間ノード・レベルを含む。各トップ中間ノードは多数のデータ・エントリを有するデータスペースを形成している。別の実施形態では、２つのデータスペース、即ち、マシン・データスペース及びユーザ・データスペースが存在し、これら２つのデータスペースは永続データスペースである。クライアント・コンピュータを切った際、即ち、機能停止した際、これらの永続データスペースはその中に含まれるデータ・エントリの保存を可能にする。別の実施形態では、マシン・データスペースはネットワーク上に存在する多数のコンピュータ・タイプに関するコンピュータ・コンフィギュレーション・データを格納する。そして、ユーザ・データスペースはコンピュータ・ネットワークへアクセスするために登録した多数のユーザに関するユーザ・コンフィギュレーション・データを格納する。
【００１４】
本発明の別の態様では、コンピュータ・ネットワーク上で伝送するデータを準備するための方法、装置及びコンピュータ読み取り可能媒体を提供する。クライアント・コンピュータのプロフィール及びプラットフォームに関する値を含むデータ・セットを、サーバ・コンピュータ上で検索する。更に、クライアント・コンピュータを使用するユーザのユーザ・プリファレンス及びユーザ・グループに関する値を含む別のデータ・セットを、サーバ・コンピュータ上で検索する。これら２つのデータ・セットは特定のクライアント・コンピュータへログオンするユーザに対応している点で互いに関連している。２つのデータ・セット内のデータ・アイテムをプロパティ毎に関連付けすることによって、データ・アイテム・コレスポンデンス（data item correspondence）が形成される。複数のデータ・カテゴリ間における優先順位のリストを含む一連のルールを、データ・アイテム・コレスポンデンスへ適用する。ファイナル・データ・セットは前記の一連のルールをデータ・アイテム・コレスポンデンスへ適用することによって得られ、かつネットワークを通じて目的のコンピュータへ送信される。ファイナル・データ・セットをネットワークを通じて送信することによって、送信するデータ量を最初の２つのデータ・セットをそのまま全て送信した場合のデータ量よりも低減できる。
【００１５】
１つの実施形態では、接続がクライアント・コンピュータ及びサーバ・コンピュータの間で確立される。クライアント・プロフィールはクライアント・コンピュータからサーバ・コンピュータへ送信される。別の実施形態では、前記の一連のルールは、プリファレンスの順位を含む。最初の２つのデータ・セットにそれぞれ含まれるデータ・アイテムの中からファイナル・データ・セット内へ含めるデータ・アイテムを決定するために、この順位は使用される。別の実施形態では、クライアント・コンピュータはネットワーク・コンピュータである。
【００１６】
本発明の更に別の態様では、サーバ・コンピュータを有するネットワーク内のコンピュータのコンフィギュレーションを設定するための方法、装置及びコンピュータ読み取り可能媒体を提供する。プロフィールを有するコンピュータと、サーバ・コンピュータとの間の接続を確立する。前記のコンピュータのプロフィールをサーバへ送信する。次いで、サーバのコントロール下で格納されたコンフィギュレーション情報を、サーバは前記のプロフィールに基づいて検索する。サーバ上で検索され、かつコンピュータへ送信されたコンフィギュレーション情報に基づいて、コンピュータのコンフィギュレーションを設定する。これによって、サーバ・コンピュータによるコンフィギュレーション情報の中央集中管理を促進する。
【００１７】
１つの実施形態では、プロフィールはクライアント・コンピュータに関するハードウェア情報と、そのクライアント・コンピュータのユーザに関する情報とを含む。別の実施形態では、クライアント・コンピュータ及びサーバ・コンピュータは、これら２つのコンピュータ間でのデータ交換に使用するソフトウェアのバージョン情報を交換する。使用するソフトウェアの正確なバージョンはサーバ・コンピュータによって決定される。更に別の実施形態では、クライアント・コンピュータはネットワーク・コンピュータである。更に別の実施形態では、サーバ・コンピュータはネットワーク上の多数のクライアント・コンピュータと、クライアント・コンピュータを使用するために登録したユーザとに関するコンフィギュレーション情報を格納する。
【００１８】
本発明とその更なる効果は添付図面に基づく以下の説明から最もよく理解できる。
【発明の実施の形態】
本発明の好ましい実施形態を以下に詳述する。好ましい実施形態の一例を添付図面に示す。本発明を好ましい実施形態に関連して詳述するが、これは本発明を１つの好ましい実施形態に制限することを意図するものではない。逆に、請求の範囲に定義する本発明の趣旨及び範囲に含まれる変形例、改良例及び等価例を包含することを意図する。
【００１９】
データ・フレームワーク、即ち、データ・スキーマと、このデータ・スキーマ内のデータをコンピュータ・ネットワーク内の複数のコンピュータ間で交換するための関連するプロトコルとを複数の図面に示す。コンフィギュレーション情報及び関連情報をシステム・データベース内で表示し、かつ格納するための階層構造、即ち、データ・スキーマを、本発明は開示する。本発明の１つの実施形態を示す目的で、ジャバ・システム・データベース（Java system database、略してＪＳＤ）を検討する。別の好ましい実施形態では、このシステム・データベースは別の種類のプラットフォーム上でのオペレーションが可能である。本実施形態のＪＳＤは、少なくとも２つの主要サブコンポーネント、即ち、クライアント・スキーマ及びサーバ・スキーマと称されるサブスキーマを含む単一サブシステムである。本実施形態では、クライアントに関するデータは、クライアント・メモリ内に存在するクライアント・スキーマに格納される。各クライアントのコンフィギュレーション・データはネットワーク・サーバ上に存在するサーバ・スキーマに格納される。コンフィギュレーション・データはクライアント／サーバ・プロトコルを通じて２つのスキーマ、即ち、２つの階層構造間で交換される。正確な情報をサーバ・スキーマから取り出し、かつクライアント・マシン上のクライアント・スキーマへ転送、即ち、入力することと、逆に、情報をクライアント・スキーマからサーバ・スキーマへ転送することを、クライアント／サーバ・プロトコルは保証する。サブシステムとも称される各クライアントのコンフィギュレーション情報はサーバ・スキーマに格納される。これはクライアントに関するコンフィギュレーション情報をクライアント・マシン上でハードコードする、即ち、格納する従来のネットワークとは対照的である。ネットワーク管理者がネットワーク内の各コンピュータのコンフィギュレーション情報を単一サーバなどの中央リポジトリから管理することを、本発明のデータ・スキーマは可能にする。従って、サブシステム・コンフィギュレーションに関する知識及びサブシステム・コンフィギュレーションへのアクセスを必要とする任意のソフトウェアの更新、バージョン・アップグレードまたは新しいアプリケーションのインストールを、中央リポジトリから行い、かつ各クライアントへ伝播できる。アプリケーションの新しいアップグレードまたは新しいバージョンのインストールまたは伝播を目的としたメインテナンスを実施するために、クライアント・マシン上のユーザはアプリケーションを終了する必要がないうえ、ネットワークをダウンさせる必要もない。
【００２０】
図１はコンピュータ・ネットワーク・コンフィギュレーションのコンポーネントを示すブロック図であり、本発明の１つの実施形態に基づくシステムワイド・データ・スキーマを示す。本実施形態では、システムワイド・データ・スキーマを、ネットワーク１０７の一部を構成するクライアント・マシン１０５上に存在するクライアント・スキーマ１０３からなるジャバ・システム・データベースＪＳＤ（１０１）として説明する。サーバ・スキーマ１１１はネットワーク１０７の一部を構成するサーバ・コンピュータ１０９上に存在する。
【００２１】
図２は本発明の１つの実施形態に基づくクライアント・スキーマ階層構造１０３を表すｎ分岐ツリー構造を示す。クライアント・スキーマ階層構造１０３及びサーバ・スキーマ階層構造１１１はｎ分岐ツリーを用いて示す。ルート・エントリ２０１がツリーのルートに設けられている。ルート・エントリ２０１はデータを全く含んでいない。更に、この階層構造内では、ルート・エントリ２０１は自身を参照する唯一のノード・フレームワークである。クライアント・スキーマ１０３内のノードの第１レベル２０３に属する一連のノードは、汎用クライアント・スキーマ内のネームスペースをそれぞれ定義している。階層構造内の第１レベル２０３はルート・エントリ２０１の直下にあり、かつ複数のネームスペース・エントリを有する。
【００２２】
本実施形態では、６つのネームスペースが汎用クライアント・スキーマ１０３内に存在する。別の好ましい実施形態では、特定のネットワーク・コンフィギュレーションの要求に基づいて、これより更に多い数または更に少ない数のネームスペースを設け得る。本実施形態では、ＪＳＤクライアントの標準トップレベル・ネームスペースは、ソフトウェア（SOFTWARE）、デバイス（DEVICE）、インターフェース（INTERFACE）、ソフトウェア・コンフィギュレーション（SOFTWARE CONFIGURATION）、エイリアス（ALIAS）及びテンプ（TEMP.）である。例えば、ソフトウェア・ネームスペースはノード２０５に始まり、かつこのノード２０５から分岐する全てのノード及びデータを含む。階層構造の層２０３に属する固有エントリは固有ネームスペースを形成するサブツリーのルートである。ソフトウェアなどの１つのネームスペースに属する全てのエントリは、クライアント１０５のソフトウェア・アプリケーションのコンフィギュレーション・データに関するエントリである。本発明のデータ・スキーマに属する各エントリは固有名称と、子（任意のエントリの真下のエントリ）のリストと、一連の組（a set of tuples）とからなる。各組はプロパティ名及び関連するプロパティ値を含む。例えば、ワードプロセッシング・プログラムでは、プロパティ名を“フォント”とし、プロパティ値をパレンティノ（Palentino）とし得る。同様に、デバイス・ネームスペース２０７の下に位置する全てのエントリは、クライアント・スキーマ１０３を有するクライアント・マシン１０５のコンフィギュレーション情報に関するエントリである。階層構造内の各エントリはサブツリー内のエントリとして機能するとともに、下位エントリ、即ち、子ノードを有するサブツリーのルートとしても機能する。層２０３内の各ネームスペースは本願に対応する米国出願と同じ日に仮出願され、かつ同じ譲受人へ譲渡されたジャバ・システム・データベース（JAVA SYSTEM DATABASE）と称される出願に開示されており、この出願の内容は本開示をもって本明細書中に開示したものとする。
【００２３】
図２に示すように、ツリー内の各エントリは単一の親を有し、かつ幾つかの子ノードを有する。ソフトウェア・ネームスペース２０９などのネームスペースは、クライアント１０５などの特定のクライアントのソフトウェア上のコンフィギュレーション・データに関する複数のエントリを含む特別に指定されたサブツリーである。図２に示すように、本実施形態では、各ネームスペースはスーパー・ルートとも称されるルート・エントリの直下に常に位置する。別の好ましい実施形態では、ネームスペースを階層構造の別のレベルで形成可能であり、ネームスペースをルート２０１の直下に配置する必要はない。ＪＳＤスキーマ・クライアントの標準ネームスペースはクライアント・コンピュータのスタートアップ、即ち、ブーティング・プロシージャ中に形成される。本実施形態の各ネームスペースはジャバ・プラットフォームの全てのインプリメンテーションで使用可能である。６つのネームスペースはジャバ・プラットフォームが初期化する周知のネームスペースである。他の動的に構築されたネームスペースを標準データベース・ネームスペースへ初期化後に追加しても良い。
【００２４】
各ネームスペースはデフォルト・ネームスペース・マネージャによって管理される。ネームスペース・マネージャはエントリをネームスペース内で格納する方法及びこのエントリへアクセスする方法をコントロールする。更に、ネームスペース・マネージャはネームスペース内の任意のエントリのセキュリティ属性、記憶装置属性及びオーナーシップ属性をエクスポートする標準インターフェースを提供する。
【００２５】
例えば、ソフトウェア・ネームスペース２０９は、インストール済みシステム・サービス及び／または使用可能システム・サービスのリストを有する。このシステム・サービスの例としては、デバイス・ドライバ、ユーザー・アプリケーション及びユーザー・コンフィギュレーション情報が挙げられる。サーバがソフトウェア・ネームスペース内の全てのエントリに対するバックアップ・ストアを提供するため、ソフトウェア・ネームスペースはクライアント・スキーマ内の唯一の永続ネームスペースである。一時ネームスペースとは逆の意味を有する永続ネームスペース、即ち、永続エントリは永続記憶場所への保存を要するエントリである。永続エントリの例としては、永続記憶装置への格納を要するユーザ環境に関するコンフィギュレーション情報が挙げられる。ユーザがログオンする際、環境を再設定する手間を省くために、ユーザが前回保存した環境を検索する必要がある。永続エントリは永久記憶場所への保存及び永久記憶場所からの検索が可能なエントリである。ネームスペース形成時に、永続ネームスペース及び一時ネームスペースは静的に分離される。永続エントリが一時ネームスペース内に存在することと、一時エントリが永続ネームスペース内に存在することの少なくともいずれか一方は許されない。本実施形態では、永続エントリはリモートＪＳＤサーバに格納される。本実施形態では、４つのカテゴリ、即ち、アプリケーション（application）、システム（system）、サービス（service）及びパブリック（public）がソフトウェア・ネームスペースの下に存在する。ジャバ・プラットフォームを使用する本実施形態では、ソフトウェア・ネームスペースに含まれる幾つかのエントリはジャバ固有の命名法を使用して形成され、ジャバとは無関係な他のエントリは特定のアプリケーションに基づく命名法を使用して形成される。本実施形態では、アイ・ビー・エム（IMB）、サン（Sun）またはロータス（Lotus）などの企業名はそれぞれcom.IBM、com.Sun及びcom.Lotusなどの名前を与えられている。これらの企業名は企業固有情報を特徴づける。企業エントリの下のエントリ名は企業固有のものである。
【００２６】
前記のように、本実施形態では、ソフトウェア・ネームスペース２０９は６つのネームスペースのうちの永続記憶を有する唯一のネームスペースである。そして、デバイス・ネームスペース２０７等のその他のネームスペースは一時記憶を有する。クライアント・コンピュータの電源を切ると、これらのネームスペース内のエントリは消失する。これは本実施形態において事実であり、この理由としては、これら５つの一時ネームスペースがクライアント・コンピュータ固有のデータを格納する点が挙げられる。本実施形態では、ソフトウェア・ネームスペースはコンピュータを切った後での保存を要するアプリケーション・コンフィギュレーション情報を含んでいる。
【００２７】
４つのカテゴリ、即ち、アプリケーション、システム、サービス及びパブリックがソフトウェア・ネームスペースの下に設けられている。アプリケーション・カテゴリを例にとってみた場合、エントリcom.Netscape２１３は企業の固有名称（例：ネットスケープ（Netscape））を有し、ネットスケープの１つの製品であるネットスケープ・ナビゲータ（Netscape Navigator）のエントリがcom.Netscapeエントリ３１３の下に存在する。ネットスケープ・ナビゲータに関する企業固有情報２１７がエントリ２１５の下に存在する。
【００２８】
エントリ２１９，２２１，２２３は他のベンダのエントリであり、これらのエントリはエントリ２１５に類似したエントリをそれぞれ有する。本実施形態では、デバイス・ネームスペース２２５の構造は、クライアント上に存在する入出力バス及びデバイスのうちの幾つかまたは全てを示す。換言するならば、バス及びデバイスの物理的接続性は複数のエントリからなるツリーとして表される。そして、このツリーでは、特定のバスが親であり、複数のリーフ・エントリは複数のデバイス上のコンフィギュレーション・データをそれぞれ含む。
【００２９】
ソフトウェア・ネームスペースでは、階層構造のリーフ・ノード・レベルはデータ２２７を有する。データ２２７はコンフィギュレーション固有のデータである。そして、データ２２７は、アプリケーション（例：ネットスケープ・ナビゲータ）が望むリーフ・ノード・レベル内の特定のデータの順位に基づいて構成されている。ワードプロセッシング・アプリケーションの場合、リーフ・ノード・エントリは、フォント、辞書定義及び他のワードプロセッシング・タイプ・コンフィギュレーション・データなどの固有情報を含み得る。
【００３０】
ＪＳＤのサーバ・スキーマ・コンポーネント内の複数のネームスペースは永続記憶空間である。即ち、これらのネームスペースはクライアント・コンピュータを切った後でも存続する。本実施形態では、２つのネームスペース、即ち、マシン（machine）及びユーザ（user）がサーバ・スキーマ内に存在する。図３は本発明の１つの実施形態に基づくＪＳＤサーバ・スキーマの構造を示すブロック図である。このブロック図は図１のサーバ・コンピュータ１０９及びサーバ・スキーマ１１１の詳細を示す。ルート・エントリ３０１（ルート・エントリ３０１は本実施形態のコンフィギュレーション・ネームスペースも表している）がｎ分岐ツリーのトップに位置する。前記のように、２つのネームスペースがサーバ・スキーマ内に存在する。エリア３０３はマシン・ノード３０５を有するマシン・ネームスペースを表す。エリア３０７はユーザ・ノード３０９を有するユーザ・ネームスペースを表す。
【００３１】
本実施形態では、マシン・ネームスペース３０３は３つのカテゴリによって形成されている。別の好ましい実施形態では、ネットワークのプラットフォーム及び要件に基づいて、マシン・ネームスペース３０３は３つより更に多い数または更に少ない数のサブカテゴリを有し得る。３つのカテゴリ、即ち、サブレンジはプラットフォーム（Platform）３１１、識別子（identifier）３１３及びプロフィール（profile）３１５である。サンマイクロシステムズ及びＩＢＭコーポレイションなどの特定のコンピュータ製造業者を指す多数のエントリがプラットフォーム３１１の下に存在する。これは図４に詳細に示す。
【００３２】
図４はサーバ・スキーマ１１１内のマシン・ネームスペース３０３のツリー構造を示すブロック図である。前記のように、ベンダ固有サブレンジ４０１，４０３がプラットフォーム３１１のカテゴリの下に存在する。このレベルにおけるエントリの数はネットワーク内で使用されているコンピュータの製造業者の数に基づいている。エントリ４０５，４０７で示すような多数のエントリがcom.Sunなどの各製造業者の下に存在する。各エントリは製造業者が製造したコンピュータの特定のモデル、即ち、タイプを示す。例えば、コンピュータ・タイプＪＤＭ１がcom.Sunの下に存在し、コンピュータ・タイプＮＳ１０００及びＮＳ２０００がcom.IBMの下に存在する。各コンピュータ・タイプ、即ち、モデルの下には、このコンピュータのアプリケーション・コンフィギュレーションを特定するリーフ・ノード４０９が存在する。タイプ・サブカテゴリにおいて、リーフ・エントリ、即ち、リーフ・ノード内のアプリケーション・コンフィギュレーション情報は、特定のコンピュータ、即ち、親エントリに示されるコンピュータへ適用可能な全てのコンフィギュレーションを含む。
【００３３】
識別子ルート・エントリ３１３を有する識別子サブカテゴリの下には、ネットワーク１０７内の各コンピュータの固有識別子４１１を含むエントリが存在する。本実施形態では、各コンピュータのＭＡＣアドレスを固有識別子として使用する。特定のクライアント識別子４１１の下のデータ４１３は、このクライアント識別子４１１に対応する特定のコンピュータ固有のアプリケーション・コンフィギュレーション情報である。識別子４１１の下のコンフィギュレーション・データ４１３は特定のユーザがコンフィギュレーションを設定した特定のコンピュータへ適用される。このため、このコンフィギュレーション・データ４１３はプラットフォーム・カテゴリの下のコンフィギュレーション・データ４０９と区別し得る。本実施形態では、識別子カテゴリの下の複数の固有識別子４１１と、プラットフォーム・カテゴリの下の複数のエントリとの間には、相互参照（図示略）が存在する。即ち、特定の識別子から特定の種類のコンピュータへの参照、即ち、リファレンスが存在する。特定の固有識別子が示すプラットフォーム、即ち、コンピュータの種類をサーバが決定することを、これは可能にする。
【００３４】
プロフィール・ルート・エントリ３１５を有するプロフィール・カテゴリの下には、ネットワーク内のコンピュータの特定のカテゴリまたは用途を示す複数のエントリが存在する。企業内の部門などを示し得る特定のプロフィールに関するコンフィギュレーション情報はプロフィールのサブカテゴリの下に含まれ得る。これらの例としては、２つのノード４１５，４１７が挙げられ、これら２つのノード４１５，４１７はファイナンス（Finance)及びセールス（Sales）のプロフィールをそれぞれ表す。ファイナンス・ノード４１５の下には、ファイナンス・プロフィールに関するデータを含むアプリケーション固有データ４１９が存在する。固有識別子からプラットフォーム・エントリへのリファレンスと同じように、固有識別子からプロフィール・エントリへのリファレンスも存在する（適用可能な場合）。即ち、経理部で使用するコンピュータまたは受付係ターミナルとしてのみ使用するコンピュータなどのように、特定のコンピュータが特定のプロフィールを有する場合、このコンピュータの識別子から適切なプロフィール・エントリへのリファレンスが存在する。
【００３５】
図５は本発明の１つの実施形態に基づくユーザ・ネームスペースを示すブロック図である。本実施形態では、ユーザ・ネームスペース３０７は２つのカテゴリ、即ち、ユーザ（users）及びグループ（groups）を有する。ユーザ・ノード（users node）３１７はノード５０１，５０３，５０５などのコンピュータ・ネットワーク上の各ユーザの名前を表す。各ユーザのノードの下には、符号５０７で示すような各ユーザのパーソナル・プリファレンスを含む固有コンフィギュレーション・データが存在する。例えば、ワードプロセッシング・アプリケーションでは、特定のユーザ・プリファレンスはデフォルトのフォント及びドキュメントのサイズであり得る。各ユーザがネットワーク１０７上の任意のコンピュータを使用し、かつこのコンピュータ上で自身のパーソナル・コンフィギュレーションを使用することを、このカテゴリは可能にする。例えば、このユーザがワードプロセッシング・プログラムを起動した場合、そのユーザのプリファレンスがコンピュータの通常のユーザのデフォルトに代わってデフォルトとなる。ユーザ・ネームスペース内のもう一方のカテゴリはグループ・ノード（groups node）３１９を有するグループ・カテゴリである。このカテゴリは特定のユーザのグループに関するエントリを含む。グループは様々なカテゴリを含み得る。この例としては、ノード５０９，５１１に示すような企業内の部門、即ち、企業内の各従業員を他の従業員と区別するカテゴリが挙げられる。本実施形態では、ユーザ・カテゴリ３１７の下の各ユーザ５０３，５０５から１つ以上の特定のグループへの参照ポインタが存在する（適切な場合）。
【００３６】
本発明では、複数の図に示すクライアント／サーバ・プロトコルに基づいて、データはコンピュータ・ネットワーク内のクライアント及びサーバの間で交換される。図１のクライアント１０５及びサーバ１０９の間に位置する矢印１０８で示すこのプロトコルは、クライアント及びサーバの間における接続の確立及びデータの交換を行うための一連のルール及びプロシージャである。本実施形態におけるサーバは様々なプロトコルを使用する外部サービス及び記憶媒体との間におけるデータ交換及びコミュニケーションが可能である。ＪＳＤサーバがサポートするプロトコルは、サーバのバックエンドに位置する様々な永続プロトコルである。その一方、永続記憶装置、データ・レジストリ、ファイル・サーバ及びデータ・ディレクトリなどの外部エンティティ及びＪＳＤサーバの間のデータ交換を実施するために、ＪＳＤサーバは多数の様々なプロトコルをサポート可能であり、ＪＳＤクライアント及びＪＳＤサーバの間のクライアント／サーバ・プロトコルはこれらの様々なプロトコルをサポートする十分な汎用性及び幅を有する。このような状況において、クライアント／サーバ・プロトコルは小さな“フットプリント”を含むべく設計されている。サーバへ接続された外部エンティティとの間における通信に必要な複数のプロトコルを管理する複雑な仕組みを設けることにより、これらのプロトコルを管理する負担を各クライアントへ課することがなくなる。従って、以上詳述したモデルは２本タイヤ・モデルであり、第１タイヤはＪＳＤクライアント及びＪＳＤサーバの間における本発明のクライアント／サーバ・プロトコルであり、第２タイヤはＪＳＤサーバと、様々な外部サービス及びデータ記憶エンティティとがサポートする複数のプロトコルである。
【００３７】
図６〜図８はクライアント及びサーバの間の接続を確立し、次いで、コンフィギュレーション情報を交換する本発明の１つの実施形態に基づくプロセスを示すフローチャートである。図６のステップ６０１では、コンピュータ・ネットワーク内のクライアント・コンピュータは、ネットワークとの間のコミュニケーション・リンクの開設を試みる。このステップでは、サーバへ接続するために、クライアントはディスカバリ・パケットをネットワークへ送信する。本実施形態では、このデータ・パケットはクライアントの情報を含むＤＨＣＰ（ダイナミック・ホスト・コンフィギュレーション・プロトコル）ディスカバリ・パケットである。ステップ９０３では、ネットワーク・サーバはディスカバリ・パケットを受信する。本実施形態では、クライアント・コンピュータはクライアント・スキーマ１０３を有し、サーバ・コンピュータは図１において詳述したＪＳＤ１０１を全体で定義するサーバ・スキーマ１１１を有する。ステップ６０５では、サーバ・コンピュータはディスカバリ・パケットの送信者のＩＰアドレス（固有識別子の１つの例）を読み取る。本実施形態では、ＩＰアドレスはデータ・パケットを送信するクライアントの固有識別子として使用される。別の好ましい実施形態では、ＭＡＣ ＩＤなどの別の識別子を固有識別子として使用できる。
【００３８】
ステップ６０７では、クライアントがサーバとの間の接続を確立したことを告げるパケットを、サーバはクライアントへ送信する。クライアントがサーバと現在通信中であることを、サーバはクライアントへ実質的に伝える。ステップ６０９では、クライアントはネゴシエーション・データ・パケットをサーバへ送信する。このステップは図９において詳述する。ネゴシエーション・パケットの目的は、クライアント及びサーバ間の通信に使用するソフトウェアのバージョンを確定することにある。ソフトウェアのバージョンを確定した後、クライアントは自身の固有プロフィール情報をステップ６１１においてサーバへ送信する。多くの例において、一般的に、この固有プロフィール情報はクライアントのＰＲＯＭへハードコードされている。例えば、クライアントの固有プロフィール情報は、サンＪＤＭ１ワークステーションまたはＩＢＭ ＮＳ１０００コンピュータなどのコンピュータのタイプを含み得る。サーバがプロフィール情報をクライアントから受信した後、図３のステップ６１３において、サーバはこのプロフィールをプラットフォーム・サブカテゴリ３１１の下のマシン・ネームスペース３０３内の固有プロフィールとマッチさせることを試みる。サーバ・スキーマのマシン・ネームスペース３０３はプラットフォームのカテゴリ３１１を有する。プラットフォームのカテゴリ３１１はコンピュータ製造業者が製造した特定のタイプのコンピュータの固有プロフィール情報を格納する。図７のステップ６１３では、サーバはクライアントのプロフィールをマシン・ネームスペース内で探索する。ステップ６１５では、クライアントが固有プロフィールを有するか否かを決定するために、サーバはクライアント固有識別子を使用する。前記のように、マシン・ネームスペース内では、識別子のカテゴリはネットワーク内の全てのクライアントの固有識別子を含む。クライアントが受付係またはセールスなどの固有プロフィールを有する場合、固有識別子から対応するプロフィールへの参照ポインタが存在する。
【００３９】
ステップ６１７では、サーバはプロフィール・データ（もし存在する場合）と、プラットフォーム・データとを１つにまとめる、即ち、結合する。そして、サーバは１つにまとまったデータ・エントリ、即ち、合体データ・エントリをクライアントのソフトウェア・ネームスペースへ送信する。プロフィール・データ及びプラットフォーム・データを合体するプロセスは図１０及び図１１に詳細を示す。本実施形態では、コンピュータのプラットフォームに関するデータは、コンピュータ固有のプロフィール内のデータによってオーバーライドされる（このコンピュータのコンピュータ固有プロフィールが存在する場合）。ステップ６１９では、クライアントは、自身のクライアント・スキーマ１０３内のソフトウェア・ネームスペース２０９をサーバから送信された合体データ・エントリで占める。このポイントにおいて、クライアント・コンピュータのブートアップ・ステージは完了する。
【００４０】
ステップ６２１では、ユーザはクライアント・コンピュータへログオンし、これによって、ログオン・フェイズを開始する。このポイントにおいて、ユーザ名がサーバへ送信される。ステップ６２３では、サーバ・スキーマ内のユーザ・ネームスペース３０７内のコンフィギュレーションを検索するために、サーバはユーザ名を受け入れる。前記のように、本実施形態では、サーバ・スキーマ１１１は２つのネームスペース、即ち、マシン・ネームスペース３０３及びユーザ・ネームスペース３０７を有する。ユーザ・ネームスペースの下には、２つのカテゴリ、即ち、ユーザ３１７及びグループ３１９が存在する。ステップ６２３では、サーバはユーザ名を使用してユーザ・コンフィギュレーションを探索する。図８のステップ６２５では、ユーザ・エントリからグループ・カテゴリ内のエントリへの参照ポインタをチェックすることにより、サーバはユーザがグループ・ノード３１９によって表されるグループに属するか否かを決定する。ステップ６２７では、ユーザ・コンフィギュレーション・エントリ及びグループ・コンフィギュレーション・エントリは単一ユーザ・エントリへ合体され、かつクライアントへ送信される。本実施形態では、ユーザ・コンフィギュレーション・エントリ内のデータはユーザ・グループ・コンフィギュレーション・エントリ内の対応する全てのデータをオーバーライドする。ユーザ・エントリからのデータ及びグループ・エントリからのデータの合体のプロセスは図１０及び図１１に詳述する。ステップ６２９では、クライアントはユーザ・エントリを受信し、必要であれば、プラットフォーム／プロフィール・エントリが以前に占めていたクライアント・スキーマ内のソフトウェア・ネームスペース内のデータをオーバーライドする。本実施形態では、ステップ６２７においてクライアントへ送信されたユーザ・コンフィギュレーション・エントリは、ステップ６１９で送信された対応する全てのデータをオーバーライドする。本実施形態では、クライアント・スキーマ内のソフトウェア・ネームスペースは永続データを含む唯一のソフトウェア・ネームスペースであるため、このソフトウェア・ネームスペースのみがサーバから送信されたデータ、即ち、サーバ・コンピュータ上の永久記憶装置、即ち、不揮発性記憶装置内に存在するデータによって占められることに注意する必要がある。別の好ましい実施形態では、別のネームスペースはコンピュータ・ネットワークの要求に基づいて永続データを含み得る。ステップ６３１では、クライアント・コンピュータのユーザは特定のアプリケーションを開始可能である。このステージでは、特定のアプリケーションの適切なコンフィギュレーション・データを獲得するために、クライアント・コンピュータのクライアント・スキーマのソフトウェア・ネームスペースを探ることにより、クライアント・コンピュータは前記のアプリケーションを開始可能である。このステージにおいて、アプリケーションをクライアント・コンピュータ上で実行するために必要な全てのコンフィギュレーション・データがサーバからクライアントへ転送されている。更に、クライアント・コンピュータが使用するコンフィギュレーション・データのみが、サーバ上で実施された合体の結果としてサーバからクライアントへ転送される。
【００４１】
図９はクライアント及びサーバの間のコミュニケーション・リンクをネゴシエート、即ち、折衝するプロセスを示す本発明の１つの実施形態に基づくフローチャートである。このフローチャートは図６のステップ６０９の詳細を示す。ステップ７０１では、クライアントは自身のソフトウェアのバージョン情報をサーバへ通知する。このバージョン情報はクライアントのハードウェア・コンポーネントをさらに示し得る。このデータはＴＣＰ／ＩＰを通じてデータ・パケットとして送信される。このステップにおいて、クライアントは自身が使用するオペレーティング・ソフトウェアのバージョンをサーバへ単に通知する。ステップ７０３では、サーバはこのバージョン情報を調べ、次いで、サーバがサポートし得るオペレーティング・ソフトウェアのバージョンをクライアントへ通知する。これを行うことにより、コンフィギュレーション・データをクライアント及びサーバの間で交換するために使用するオペレーティング・ソフトウェアのバージョンをサーバは指令する。
【００４２】
図１０は図６のステップ６１７，６２７の詳細を示すフローチャートである。このフローチャートは特定のクライアントに関するサーバ上のコンフィギュレーション・データを合体する本実施形態のプロセスを示す。データ・エントリ内の特定のデータ・アイテムを別のネームスペースまたはカテゴリ内の対応するデータ・アイテムによってオーバーライドし得るため、データは図１１に示す階層構造に基づいて合体される。ステップ８０１では、サーバはプラットフォーム・エントリを自身のマシン・ネームスペース内のプラットフォーム・サブツリーから検索する。プラットフォーム・エントリはクライアント・コンピュータ・タイプに関する固有情報を含む。ステップ８０３では、クライアント・マシン固有識別子からプロフィール・カテゴリ内の特定のプロフィールへの参照ポインタが存在するか否かをチェックすることにより、サーバはクライアントが対応するプロフィール・エントリを有するか否かを決定する。クライアントがプロフィール・エントリを有する場合、サーバはこのプロフィール・エントリをステップ８０５で検索する。ステップ８０５では、このプロフィール・エントリ内の値及びプラットフォーム・エントリ内の値を合体する。これらのプロフィール・エントリ及びプラットフォーム・エントリ内に含まれるプロパティの値は、図１１の階層構造に基づいてプロパティ毎に合体される。本実施形態では、プラットフォーム・エントリ内にマッチするプロパティ値を有するプロフィール・エントリ内の値は、プロフィール・エントリ値によってオーバーライドされる。エントリの合体はプロパティ毎に実施される。ステップ８０３において、クライアントがプロフィール・エントリを有していないことが決定した場合、コントロールはステップ８０７へ移行する。
【００４３】
ステップ８０７において、サーバはユーザ・エントリをサーバ・スキーマ内のユーザ・ネームスペースから検索する。ステップ８０９では、ログオンしたユーザがグループ３１９のいずれかに属するか否かを、サーバは決定する。ステップ８１１では、サーバはグループ・エントリを検索する。しかし、ここでもサーバはグループ・エントリ内の値をユーザ・エントリ内の値によってプロパティ毎にオーバーライドする。ステップ８１３では、サーバはステップ８０５からのプロフィール／プラットフォーム・エントリ内の値を合体ユーザ・エントリ内の値によってオーバーライドする。ユーザがグループに属さないことをサーバがステップ８０９で決定した場合、ステップ８１３へ移行する。ステップ８１５では、クライアントへログオンするユーザに関する合体データ・エントリはクライアント・コンピュータへ送信され、プロセスは完了する。
【００４４】
図１１はデータを合体するために使用する本発明の１つの実施形態に基づく階層構造を示すブロック図である。最上位のランクに位置し、これによって、他の全てのエントリに優先するエントリは、ブロック８１７に示すユーザ・エントリである。このエントリの下には、次にランクの高いエントリ、即ち、ブロック８１９で示すユーザ・グループ・エントリが存在する。グループ・エントリに含まれるプロパティ内の値はユーザ・エントリ内のマッチするプロパティの値によってオーバーライドされる。ブロック８２１はクライアント・プロフィール・エントリである。グループ・エントリ内のプロパティの値はクライアント・プロフィール・エントリ内のマッチするプロパティ値をオーバーライドする。本実施形態の階層構造の最下位には、ブロック８２３に示すクライアント・プラットフォーム・エントリが存在する。このエントリ内の値は他の３つのカテゴリのうちのいずれか１つに含まれるマッチするプロパティの値によってオーバーライドされる。別の好ましい実施形態では、優先順位を変更可能であり、前記の実施形態のエントリの数より更に多い数または更に少ない数のエントリを階層構造内に含み得る。
【００４５】
クライアント／サーバ・プロトコルの１つの特徴は、ハートビート・メカニズムと称される。クライアント及びサーバの間の接続が切断または中断された際、クライアントまたはサーバが通知を受けることを、ハートビート・メカニズムは可能にする。図１２及び図１３はサーバ及びクライアントの間の接続が依然として生きていることを示すために、信号をサーバからクライアントへ周期的に送信する本発明の１つの実施形態に基づくプロセスを示すフローチャートである。一般的に、ハートビート・メカニズムはネゴシエーション・フェイズ（図９のステップ６０９）の直後に開始され、かつクライアント及びサーバの間の接続が続く限り継続される。クライアント及びサーバの間の接続が切断または中断された際、クライアントまたはサーバが通知を受けることは重要な特徴である。ステップ９０１では、サーバはデータ・パケットをクライアントへ送信する。これは一般的にネゴシエーション・フェイズの直後に最初に発生し、接続が続く限り一定のインターバルで送信される。本実施形態では、ハートビート・デーモンはクライアント及びサーバの両方で実行されるとともに、クライアント／サーバ・プロトコル内の実質的に１つのスレッドである。別の好ましい実施形態では、ハートビート・デーモンはサーバまたはクライアントで実行可能であるとともに、マルチスレッド・プロセスであり得る。サーバは接続の状態情報を維持し、かつデータ・パケットをクライアントへ送信した時刻等のデータを含む。ステップ９０３では、クライアントからのリターン・データ・パケット、即ち、ハートビートが存在するか否かを、サーバは決定する。ステップ９０５では、ハートビートが存在する場合、クライアントからのデータ・パケットはサーバへ送信される。ステップ９０１において、設定された時間間隔（例：１０分）の後で、サーバはデータ・パケットをクライアントへ再び送信する。別の好ましい実施形態では、時間間隔を、これより更に長くしたり、あるいは、更に短くすることができる。
【００４６】
クライアントがデータ・パケットをサーバへ送り返さなかったこと、即ち、ハートビートが存在しないことがステップ９０３で確定した場合、リターン・データ・パケットが存在しないことを表示するために、サーバは状態情報及びストラクチャ（ディレクトリ・キャッシュ）を使用する。これはステップ９０７で実施される。接続が切断されたことを表示するために、ダーティ・ビットを前記のストラクチャ内に配置する。ステップ９０９では、サーバ及びクライアントは再接続を試みる。この時点において、クライアント上での更新が必要か否かを確認するために、サーバは自身の状態ストラクチャ内のダーティ・ビットをチェックする。これはクライアントに関するサーバ上のコンフィギュレーション情報が変更された場合に発生し得る。ステップ９１１では、サーバはクライアント・コンフィギュレーションを更新する。クライアントはサーバ上のディレクトリ・キャッシュ状態ストラクチャに類似する状態情報を示すストラクチャをさらに有する。そして、このクライアントの状態ストラクチャは更新をクライアントからサーバへ送信すべきか否かを示すためのダーティ・ビットを含み得る。従って、ステップ９１３では、更新をサーバへ送信すべきか否かを確認するために、クライアントは自身のダーティ・ビットをチェックする。ステップ９１５では、クライアントはサーバ・スキーマを更新する。このポイントにおいて、クライアント及びサーバの間の再接続が確立され、ネゴシエーション・フェイズの完了後、ハートビート・メカニズムはオペレーションを再開する。
【００４７】
本発明のクライアント／サーバ・プロトコルの別の特徴としては、サーバ上で実施された特定のアプリケーションの更新を、このアプリケーションを使用するクライアントへ通知する能力が挙げられる。図１４は本発明の１つの実施形態に基づくクライアント／サーバ・プロトコル内のイベント通知のプロセスを示すフローチャートである。ステップ１３０１では、サーバ・スキーマをアプリケーションの調整、即ち、変更によって更新する。即ち、サーバ・スキーマを一般コンフィギュレーション更新によって変更する。ステップ１００３では、変更されたコンフィギュレーション・データを使用するクライアントを確認するために、即ち、サーバ・スキーマ内で実施された一般コンフィギュレーションの変更の通知を望む可能性のあるクライアントを確認するために、サーバは自身のキャッシュ・ディレクトリを調べる。サーバ・キャッシュ・ディレクトリはサーバに接続されているクライアントが使用するリストである。ステップ１００５では、サーバは更新、即ち、変更を適切なクライアントへ一斉同報する。ステップ１００７では、クライアントは更新の影響を受けるクライアント側のアプリケーションを決定する、即ち、クライアントは一般コンフィギュレーションの更新が自身に関連するか否かを決定する。ステップ１００９では、更新の影響を受けるアプリケーションが、全ての変更の通知を受けるための登録を行っているか否かを、クライアントは決定する。アプリケーションが通知を受けるべく登録されている場合、コントロールはステップ１０１１へ移行する。ステップ１０１１において、このアプリケーションは更新の通知を受ける。このステージにおいて、プロセスは完了する。アプリケーションが変更の通知を受けるべく登録されていない場合、このアプリケーションは変更、即ち、更新を無視し、通知を受けることなくオペレーションを継続する。
【００４８】
本発明のクライアント／サーバ・プロトコルの別の特徴としては、特定のオペレーションの実行または不実行を保証する能力が挙げられる。この特徴はクライアント／サーバ・プロトコルの原子性と称される。更新をクライアント・スキーマ及びサーバ・スキーマ内で行うための２フェイズ・コミット・プロシージャ（two-phase commit procedure）を、クライアント／サーバ・プロトコルは実行する。第１フェイズでは、スキーマのサブツリー内の複数のエントリのうちの１つを更新するために、このサブツリーのルートをロックする。第２フェイズでは、サブツリー内の複数のエントリのうちの１つを更新し、次いで、このサブツリーのルートをアンロックする。サブツリーのルートをロックすることにより、他のクライアントまたはアプリケーションはサブツリー内のルートの下に位置する全てのエントリ及びノードへアクセスできなくなる。ロックされたサブレンジ内のエントリの更新を試みる別のクライアント・アプリケーションはブロック・トランザクションまたはアンブロック・トランザクションを起こす。アンロックの発生を待ち、次いで、自身の更新をクライアント・アプリケーションが望む場合、トランザクションはブロック・トランザクションと称される。このシナリオでは、更新は待ち行列内へ配置される。アプリケーションがロックの除去を待つことを望まない場合、トランザクションはノンブロック・トランザクションと称され、トランザクションはアプリケーションへ戻される。このメカニズムを通じて、クライアント／サーバ・プロトコルは、リクエストされたオペレーション、即ち、更新を実施すること、即ち、トランザクションをブロックすることと、オペレーションを実施しないこと、即ち、トランザクションをブロックしないことのうちのいずれか一方をクライアント・アプリケーションに対し保証できる。
【００４９】
前記のように、コンピュータ・システム内に格納されたデータを使用する様々なコンピュータ実行オペレーションを本発明は用いる。これらのオペレーションは物理量の物理操作を必要とするオペレーションを含む（但し、このオペレーションに限定されない）。一般的に、必ずしも必要でないが、これらの量は格納、転送、結合、比較及び他の操作が可能な電気信号または磁気信号の形態をなす。本発明の一部を構成する本明細書中に開示するオペレーションは、効果的なマシン・オペレーションである。実施する操作は生成（producing)、識別（identifying）、実行（running）、決定（determining）、比較（comparing）、実行（executing）、ダウンローディング（downloading）または検出（detecting）等の用語で示されることが多い。特に、共通の用法を確立するために、これらの電気信号または磁気信号をビット、値、エレメント、変数、キャラクターまたはデータ等として示すと都合が良い。しかし、これらの用語またはこれらに類似する用語の全ては適切な物理量に関連すべきであり、かつこれらの物理量に適用された都合の良いラベルにすぎない点を覚えておく必要がある。
【００５０】
更に、本発明は前記のオペレーションを実施するためのデバイス、システムまたは装置に関する。システムは要求された目的のために特別に構築可能である。また、システムは汎用コンピュータとすることが可能である。汎用コンピュータに格納されたコンピュータ・プログラムによって、この汎用コンピュータは選択的に作動または設定される。前記の複数のプロセスは特定のコンピュータまたは他のコンピューティング装置に固有のものではない。特に、本明細書の開示内容に基づいて記述されたプログラムを様々な汎用コンピュータと併用可能である。これに代えて、要求されたオペレーションを実施するために、更に特別なコンピュータ・システムを形成することは更に都合が良い。
【００５１】
図１５は本発明の１つの実施形態に基づく処理の実施に適した汎用コンピュータ・システム１１００のブロック図である。図１５は汎用コンピュータ・システムの１つの例を示す。本発明の処理を実施するために、他のコンピュータ・システム・アーキテクチャ及びコンフィギュレーションを使用し得る。以下に詳述する様々なサブシステムからなるコンピュータ・システム１１００は少なくとも１つのマイクロプロセッサ・サブシステム（中央処理装置、即ち、ＣＰＵとも称される）１１０２を含む。即ち、ＣＰＵ１１０２はシングルチップ・プロセッサまたは複数のプロセッサによって実現し得る。ＣＰＵ１１０２はコンピュータ・システム１１００のオペレーションを制御する汎用デジタル・プロセッサである。メモリから検索した命令を使用して、ＣＰＵ１１０２は入力データの受信及び操作と、出力デバイス上でのデータの出力及び表示とを制御する。
【００５２】
ＣＰＵ１１０２は一般的にランダム・アクセス・メモリ（ＲＡＭ）からなる第１の一次記憶装置１１０４へメモリ・バス１１０８を通じて双方向接続されている。更に、ＣＰＵ１１０２は一般的にリード・オンリ・メモリ（ＲＯＭ）からなる第２の一次記憶装置１１０６へメモリ・バス１１０８を通じて単方向接続されている。当該技術分野でよく知られているように、一次記憶装置１１０４は汎用記憶領域及び作業メモリとして使用可能であり、さらには入力データ及び処理済みデータを格納するためにも使用できる。更に、ＣＰＵ１１０２上のオペレーションを処理するためのデータ及び命令を格納する以外に、一次記憶装置１１０４は例えばスレッド及びプロセスの形態でプログラミング命令及びデータを格納可能である。更に、データ及び命令をメモリ・バス１１０８を通じて双方向に高速転送するために、一次記憶装置１１０４は一般的に使用される。同様に、当該技術分野でよく知れられているように、ＣＰＵ１１０２がその機能を果たすために使用する基本オペレーティング命令、プログラム・コード、データ及びオブジェクトを一次記憶装置１１０６は一般的に含む。データ・アクセスが双方向または単方向のいずれを必要とするかなどの条件に基づいて、一次記憶装置１１０４，１１０６は以下に詳述する任意の適切なコンピュータ読み取り可能記憶媒体を含み得る。ＣＰＵ１１０２は頻繁に必要となるデータをキャッシュ・メモリ１１１０内へ超高速で直接検索し、かつ格納できる。
【００５３】
取り外し可能大容量記憶装置１１１２はコンピュータ・システム１１００のための別のデータ記憶能力を提供し、かつペリフェラル・バス１１１４を通じてＣＰＵ１１０２へ両方向または単方向に接続されている。例えば、ＣＤ−ＲＯＭとして一般的に知られている特定の取り外し可能大容量記憶装置はデータを単方向でＣＰＵ１１０２へ送信する。その一方、フロッピー・ディスクはデータをＣＰＵ１１０２へ双方向に送信し得る。記憶装置１１１２は磁気テープ、フラッシュ・メモリ、搬送波に組み込まれた信号、ＰＣカード、ポータブル大容量記憶装置、ホログラフィック記憶装置及び他の記憶装置等のコンピュータ読み取り可能媒体を更に含み得る。固定大容量記憶装置１１１６は別のデータ記憶能力を提供し、かつペリフェラル・バス１１１４を通じてＣＰＵ１１０２へ双方向に接続されている。大容量記憶装置１１１６の最も一般的な例としては、ハード・ディスク・ドライブが挙げられる。一般的に、これらの媒体へのアクセスは一次記憶装置１１０４，１１０６へのアクセスより遅い。ＣＰＵ１１０２が頻繁に使用しない他のプログラミング命令及びデータ等を大容量記憶装置１１１２，１１１６は一般的に格納する。必要に応じて、大容量記憶装置１１１２，１１１６内に保持された情報は、一次記憶装置１１０４（例：ＲＡＭ）の一部を構成するバーチャル・メモリとして標準的に組込み可能である。
【００５４】
記憶装置サブシステムへのＣＰＵ１１０２のアクセスを提供する以外に、ペリフェラル・バス１１１４は他のサブシステム及びデバイスへのアクセスを提供するために使用できる。本実施形態では、これらは、ディスプレイ・モニタ１１１８及びアダプタ１１２０、プリンタ・デバイス１１２２、ネットワーク・インターフェース１１２４、補助入出力装置インターフェース１１２６、サウンド・カード１１２８及びスピーカー１１３０、並びに必要とされる他のサブシステムを含む。
【００５５】
図示するように、ネットワーク接続を使用することにより、ネットワーク・インターフェース１１２４はＣＰＵ１１０２を別のコンピュータ、コンピュータ・ネットワークまたはテレコミュニケーション・ネットワークへ接続可能にする。前記の方法のステップを実行するうえで、ＣＰＵ１１０２はデータ・オブジェクトまたはプログラム命令などの情報を別のネットワークからネットワーク・インターフェース１１２４を通じて受信するか、または情報をネットワーク・インターフェース１１２４を通じて別のネットワークへ送信し得る。ＣＰＵで実行する複数の命令のシーケンスに代表される情報は、搬送波に組み込まれたコンピュータ・データ信号などの形態で別のネットワークに対して送受信可能である。インターフェース・カードまたはこれに類似するデバイスと、ＣＰＵ１１０２によって実行される適切なソフトウェアとは、コンピュータ・システム１１００を外部ネットワークへ接続し、かつデータを標準プロトコルに基づいて転送するために使用できる。即ち、本発明の方法はＣＰＵ１１０２上で単独で実行し得る。その一方、処理の一部を共有する遠隔ＣＰＵと協動することにより、本発明の方法をインターネット、イントラネットワーク若しくはローカル・エリア・ネットワーク等のネットワークを通じて実行し得る。別の大容量記憶装置（図示略）をネットワーク・インターフェース１１２４を通じてＣＰＵ１１０２へ接続し得る。
【００５６】
マイクロホン、タッチ・ディスプレイ、トランスデューサ・カード・リーダー、テープ・リーダー、音声認識装置、手書き文字認識装置、バイオメトリクス・リーダー、カメラ、ポータブル大容量記憶装置及び他のコンピュータ等の装置に対するＣＰＵ１１０２によるデータの送受信を可能にする汎用インターフェース及びカスタム・インターフェースを補助入出力装置インターフェース１１２６は表す。
【００５７】
キーボード１１３６またはポインタ・デバイス１１３８からの入力を受信し、さらにはデコードしたシンボルをキーボード１１３６またはポインタ・デバイス１１３８からＣＰＵ１１０２へ送信するために、キーボード・コントローラ１１３２がローカル・バス１１３４を通じてＣＰＵ１１０２へ接続されている。ポインタ・デバイスはマウス、スタイラス、トラック・ボールまたはタブレットであり得る。そして、ポインタ・デバイスはグラフィカル・ユーザー・インターフェースとのインターフェースに効果的である。
【００５８】
更に、本発明の実施形態は様々なコンピュータ実行オペレーションを実施するためのプログラム・コードを含むコンピュータ読み取り可能媒体を有するコンピュータ記憶装置に関する。コンピュータ読み取り可能媒体は、コンピュータ・システムによる後からの読み取りが可能なデータを格納し得る任意のデータ記憶装置である。媒体及びプログラム・コードは本発明の目的のために特別に設計され、かつ構築されたものであるか、またはコンピュータ・ソフトウェア技術分野の当業者によく知られたものであり得る。コンピュータ読み取り可能媒体の例としては、ハード・ディスク、フロッピー・ディスク及び磁気テープなどの磁気媒体と、ＣＤ−ＲＯＭディスクなどの光媒体と、光フロッピー・ディスクなどの磁気光媒体と、特定用途向け集積回路（ＡＳＩＣ）、プログラム可能論理回路（ＰＬＤ）、ＲＯＭデバイス及びＲＡＭデバイスなどの特別に構成されたハードウェア・デバイスとを含めた前記の全ての媒体が挙げられる（但し、これらに限定されない）。コンピュータ読み取り可能媒体は搬送波に組み込まれたデータ信号として結合コンピュータ・システムのネットワーク上に分散させ得る。従って、コンピュータ読み取り可能コードは分散した形態で格納及び実行できる。プログラム・コードの例としては、コンパイラなどによって形成されたマシン・コード、またはインタプリタを使用して実行できる高レベル・コードを含むファイルが挙げられる。
【００５９】
前記のハードウェア・エレメント及びソフトウェア・エレメントが標準的なデザイン及び構成を有することを当業者は認める。本発明に適した他のコンピュータ・システムは別のサブシステムまたは更に少ない数のサブシステムを含み得る。更に、メモリ・バス１１０８、ペリフェラル・バス１１１４及びローカル・バス１１３４は複数のサブシステムをリンクするために使用する任意の相互接続方式の実例である。例えば、ローカル・バスはＣＰＵを固定大容量記憶装置１１１６及びディスプレイ・アダプタ１１２０へ接続するために使用可能である。図１５に示すコンピュータ・システムは本発明に適したコンピュータ・システムの例である。本発明のクライアント・コンピュータまたはサーバ・コンピュータを実現するために、サブシステムの別のコンフィギュレーションを有する他のコンピュータ・アーキテクチャを使用し得る。本発明の別の好ましい実施形態では、クライアント・コンピュータはネットワーク・コンピュータ、即ち、ＮＣである。機能性及び記憶能力の点において、このコンピュータは独立型コンピュータとして機能し得る完全に独立したファット・クライアント・コンピュータ（"fat" client computer）と、サーバ・コンピュータ、即ち、メインフレーム・コンピュータにほぼ完全に依存するダム・クライアントとの間に位置する。更に別の好ましい実施形態では、パーソナル・デジタル・アシスタント（ＰＤＡ）及びハンドヘルド・コンピュータなどの限られたメモリ・ストレージを有するコンピュータ以外に、クライアント・スキーマはジャバ・プラットフォームを実行可能なスマート・カード及び他のスマート・アプライアンスなどの非コンピュータ・デバイス上に存在し得る。
【００６０】
以上、理解を容易にする目的で、本発明をある程度詳しく説明したが、特定の変更及び改良を本発明の請求の範囲を逸脱することなく実施しても良い。更に、本発明のプロセス及び装置の両方を実現する他の方法があることを認識する必要がある。従って、本明細書に開示した複数の実施形態は例示目的であって、限定目的ではない。更に、本発明は本明細書に開示する詳細部分に限定されることなく、請求の範囲及びそれに等価な範囲内で変更し得る。
【図面の簡単な説明】
【図１】コンピュータ・ネットワーク・コンフィギュレーションのコンポーネントを表すブロック図であり、本発明の１つの実施形態に基づくシステムワイド・データ・スキーマを示す。
【図２】本発明の１つの実施形態に基づくクライアント・スキーマ階層構造を示すｎ分岐ツリー構造を表す図である。
【図３】本発明の１つの実施形態に基づくＪＳＤサーバ・スキーマの構造を示すブロック図である。
【図４】サーバ・スキーマ内のマシン・ネームスペースのツリー構造を示すブロック図である。
【図５】本発明の１つの実施形態に基づくユーザ・ネームスペースを示すブロック図である。
【図６】クライアント及びサーバの間の接続を確立し、かつコンフィギュレーション情報を交換する本発明の１つの実施形態に基づくプロセスを示すフローチャートである。
【図７】クライアント及びサーバの間の接続を確立し、かつコンフィギュレーション情報を交換する本発明の１つの実施形態に基づくプロセスを示すフローチャートである。
【図８】クライアント及びサーバの間の接続を確立し、かつコンフィギュレーション情報を交換する本発明の１つの実施形態に基づくプロセスを示すフローチャートである。
【図９】本発明の１つの実施形態に基づくクライアント及びサーバの間のコミュニケーション・リンクをネゴシエートするプロセスを示すフローチャートである。
【図１０】図７および図８のステップ６１７，６２７の詳細を示すフローチャートである。
【図１１】データを合体するために使用する本発明の１つの実施形態に基づく階層構造を示すブロック図である。
【図１２】サーバ及びクライアントの間の接続が依然として生きていることを示すために、信号をサーバからクライアントへ周期的に送信する本発明の１つの実施形態に基づくプロセスを示すフローチャートである。
【図１３】サーバ及びクライアントの間の接続が依然として生きていることを示すために、信号をサーバからクライアントへ周期的に送信する本発明の１つの実施形態に基づくプロセスを示すフローチャートである。
【図１４】本発明の１つの実施形態に基づくクライアント／サーバ・プロトコル内のイベント通知のプロセスのフローチャートである。
【図１５】本発明の実施形態の実現に適する一般的なコンピュータ・システムのブロック図である。
【図１】
0004533474.tif 000002
【図２】
0004533474.tif 000003
【図３】
0004533474.tif 000004
【図４】
0004533474.tif 000005
【図５】
0004533474.tif 000006
【図６】
0004533474.tif 000007
【図７】
0004533474.tif 000008
【図８】
0004533474.tif 000009
【図９】
0004533474.tif 000010
【図１０】
0004533474.tif 000011
【図１１】
0004533474.tif 000012
【図１２】
0004533474.tif 000013
【図１３】
0004533474.tif 000014
【図１４】
0004533474.tif 000015
【図１５】
0004533474.tif 000016