(57)【要約】コンピュータ化されたマネージャがコンピュータ資源を複数のユーザに透過的に割り当てることを可能にする方法である。コンピュータ資源を適応させまたはデータを記憶するために複数のコンピュータまたはサーバを設ける。かかるコンピュータ資源およびデータは階層リポジトリとして配置する。ユーザとコンピュータまたはサーバとの間のインターフェースとしてルート・コンピュータを用いる。ルート・コンピュータはユーザ、コンピュータ、またはサーバと通信し、コンピュータまたはサーバを制御し、マネージャがコンピュータ資源をユーザに割り当てることを可能にする。コンピュータまたはサーバ内に、ローカルのリポジトリ内に、またはコンピュータまたはサーバのシステム・ファイル内に情報を記憶する。必要に応じて、記憶された情報をコンピュータまたはサーバから検索し、マネージャはルート・コンピュータを介して、ユーザの連続的な動作を本質的に妨げずに、ユーザ毎に要求されたコンピュータ資源を動的に割り当てる。【特許請求の範囲】
【請求項１】
コンピュータ化されたマネージャがコンピュータ資源を複数のユーザに透過的に割り当てることを可能にする方法であって、
ａ．  前記コンピュータ資源を適応させまたはデータを記憶するための複数のコンピュータまたはサーバを設け、前記コンピュータ資源および前記データを階層リポジトリとして配置し、
ｂ．  前記ユーザと前記コンピュータまたはサーバとの間のインターフェースであるルート・コンピュータを設け、前記ルート・コンピュータは、
（１）  前記ユーザと通信し、
（２）  前記コンピュータまたはサーバと通信し、
（３）  前記コンピュータまたはサーバを制御し、
（４）  前記マネージャがコンピュータ資源を前記ユーザに割り当てることを可能にする、
機能を有し、
ｃ．  前記コンピュータまたはサーバ内に、ローカルのリポジトリ内に、または前記コンピュータまたはサーバのシステム・ファイル内に情報を記憶し、
ｄ．  必要に応じて、記憶された情報を前記コンピュータまたはサーバから検索し、
ｅ．  前記マネージャは前記ルート・コンピュータを介して、前記ユーザの連続的な操作を本質的に妨げずに、前記ユーザ毎に要求されるコンピュータ資源を動的に割り当てる、
ことを含む、コンピュータ資源を割り当てる方法。
【請求項２】
コンピュータまたはサーバ、コンピュータ資源、データ、ユーザに関する情報、およびこれらに関連する経路はリポジトリ内に配置し、前記リポジトリの階層構造は前記ユーザに見えるが、前記リポジトリ内の情報の内部編成は前記ユーザに透過的である、請求項１記載のコンピュータ資源を割り当てる方法。
【請求項３】
前記ルート・コンピュータは１次エージェントを更に含み、次のどの活動も行う、すなわち、
ａ．  ユーザから要求を受け、
ｂ．  前記要求を処理し、
ｃ．  前記リポジトリ内の前記要求された資源を探し、
ｄ．  必要であれば、前記資源を用いて前記要求を実行し、
ｅ．  必要であれば、前記要求に対する回答を前記ユーザに送る、
前記請求項のいずれか一項に記載のコンピュータ資源を割り当てる方法。
【請求項４】
各サーバは、前記１次エージェントから要求を受けて要求を前記サーバで実行するための２次エージェントを更に含む、請求項３記載のコンピュータ資源を割り当てる方法。
【請求項５】
前記ユーザと前記ルート・コンピュータとの間、および前記ルート・コンピュータと前記コンピュータまたはサーバとの間の通信は、ＴＣＰインターネット通信プロトコル（ＴＣＰ／ＩＰ）を用いて実現する、請求項２記載のコンピュータ資源を割り当てる方法。
【請求項６】
前記リポジトリは１つのＸＭＬファイルにより保持される、請求項２記載のコンピュータ資源を割り当てる方法。
【請求項７】
前記リポジトリは複数のＸＭＬファイルにより保持され、各ＸＭＬファイルは前記リポジトリの異なる部分を保持する、請求項２記載のコンピュータ資源を割り当てる方法。
【請求項８】
前記リポジトリは複数のデータベース・テーブルにより保持され、各データベース・テーブルは前記リポジトリの異なる部分を保持する、請求項２記載のコンピュータ資源を割り当てる方法。
【請求項９】
各コンピュータまたはサーバは前記リポジトリに関連する単一ＸＭＬファイルで構成する、請求項２記載のコンピュータ資源を割り当てる方法。
【請求項１０】
テンプレートの利用を更に含み、各テンプレートは少なくとも２つのノードが共用するデータに関連し、また１つ以上のリンクにより前記ノードからアクセスすることができる、請求項２記載のコンピュータ資源を割り当てる方法。
【請求項１１】
前記リンクは、必要に応じて、前記１次エージェントにより、または前記２次エージェントにより活動化される、請求項３、４、１０のいずれか一項に記載のコンピュータ資源を割り当てる方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はコンピュータ資源管理の分野に関するものである。特に、本発明は、ウエブ・ホストが管理する複数のクライアント／ユーザに関連しまたハードウエア（ＣＰＵ、ディスク・スペース、帯域幅など）とサービス（ＦＴＰ、ウエブなど）の両方を含むコンピュータ資源の割当てなどに関する情報を、記憶し、更新し、検索するための方法に関するものである。
【背景技術】
【０００２】
ここでは本発明の可能なユーザとしてウエブ・ホスティング会社について述べるが、本発明は他の種類の情報を検索するのにも用いてよく、ウエブ・ホスティング会社は単なる例として取り上げたことに注意していただきたい。
【０００３】
ウエブ・ホスティング会社（ＷＨＣ）とは、多くの強力なコンピュータを所有し、管理し、消費者に割り当てる会社である。そのビジネスはその会社のコンピュータ資源を小さなクライアントに販売することであり、クライアントはかかる資源を自分のビジネスに用いる。各ＷＨＣのクライアントは専用のドメインやウエブサイトや電子メール・アドレスなどを与えられる。ＷＨＣの仕事は、各クライアントがＷＨＣから購入したサービスのレベルに従って、そのコンピュータ資源をそのクライアントに割り当てることである。この割当ては資源に対する或る制限を含んでよい。このため、ＷＨＣのどのクライアントも自分が支払った以上のＷＨＣのコンピュータの資源を使うことはできないので、同じ機械を使う他のクライアントは各自が支払っただけの資源を使えることが保証される。しかし、或るＷＨＣはその資源の実際の使用を監視して、使用に応じてクライアントに請求書を送るだけである。
【０００４】
また、より多くのコンピュータを持って、多数のＷＨＣにそれを賃貸または販売して利益を得る会社がある。かかる会社は、その資源をＷＨＣの間に割り当てるという同じ目的も有する。より大きなＷＨＣから資源を買って、これを自分のクライアントに売るＷＨＣを再販業者（resellers）と呼ぶ。
【０００５】
コンピュータ資源を効率的に管理するには、ＷＨＣマネージャはコンピュータ資源の使用可能性に関する情報を容易に検索しかつ更新することができるようにアクセスが容易でなければならない。この情報は静的（例えば、或るクライアントに割り当てられたＣＰＵ資源の量）または動的（例えば、そのクライアントの現在のＣＰＵの使用）であり、これが必要な理由はいくつかある。
【０００６】
第１の理由は、ＷＨＣマネージャが、或るクライアントが或る期間中に資源をどのくらい用いたかを知り、この情報を用いてこのユーザへの請求書を作れるからである。この請求方法は任意の形式でよいが、一般的な方法はコンピュータ資源の或る固定パッケージの料金を支払うことであり、使用がこのパッケージを越えた場合は、クライアントはこの固定パッケージを越えた量について追加料金（単価が高い）を支払う。１人のクライアントが資源を使い過ぎるのを防ぐために、使ってよい追加の資源は制限される。例えば、ディスク・メモリの１パッケージが２０ギガバイト当たり２００ドルとすると、余分に使えるのは最大２０ギガバイトまでで、追加の１ギガバイト毎に１５ドルが加算される。この例は、ＷＨＣがクライアントのコンピュータ資源の使用を分析して、クライアントにいくら請求するか決定する場合を示す。逆に、クライアントはこの情報を用いて或る期間中にコンピュータ資源をどのくらい使用したかを知って、請求書が正しいかどうかチェックすることができる。
【０００７】
第２の理由は、この情報は或るクライアントへのコンピュータ資源の割当てを変える必要があるかどうかをＷＨＣマネージャに示すことができるからである。例えば、或るクライアントが毎月１０ギガバイトのディスク・メモリを買っているが実際にはその半分しか使っていない場合は、ＷＨＣマネージャは、より小さなパッケージを買った方がよさそうだとクライアントに知らせることができる。これにより、使用されていないメモリを、必要とする他のクライアントのために空けることができる。この種の操作はＷＨＣマネージャに利益をもたらす。例えば、このクライアントが購入した１０ＧＢパッケージの価格が１５ドルであり、５ＧＢのパッケージの価格が１０ドルの場合、１人のクライアントに１０ＧＢを与えるより、２人のクライアントに５ＧＢずつ与える方が利益が大きい。
【０００８】
第３の理由は、資源の使用の統計を持てば、ＷＨＣマネージャがそのコンピュータの性能を改善し、事故を防ぎ、使用効率を高める方法を知るのに役に立つからである。かかる統計は種々の形式（例えば、ＦＴＰトラフィックのデータの週間処理量）でよく、これを用いてコンピュータ性能の種々の態様を分析することができる。
【０００９】
コンピュータ資源に関する全ての情報の編成はリポジトリ(repository)を用いて行う。情報技術では、リポジトリとはデータの集合を組織的に保持し、保全し、管理するための中央の場所である。リポジトリはユーザが直接アクセスできるものでよく、またはネットワーク内で再配置または分配するために特定のデータベースやファイルや文書を得る場所でよい。データベースは、その内容に容易にアクセスし、管理し、更新することができるように編成されたデータの集合である。一般にリポジトリは階層的である。例えばネットワークは、それぞれが自分の構成とユーザのリストとを有するコンピュータのグループで構成してよい。そしてリスト上の各ユーザは自分の構成（例えば、ディスク割当て、許可）などを有する。
【００１０】
ツリー構造はリポジトリ内で階層データ・エンティティを設置し、場所を示すための方法である。ツリー内のノード(node)（または決定点）は無制限の数のブランチ（branch）（「子」とも呼ぶ）を有してよい。ただし通常は、大きなものでも数ダース以下、小さいものは１ブランチである。端点をリーフ（leaves）と呼ぶ。データはノードとリーフの両方に記憶してよい。開始点をルート（root）と呼ぶ。ノード当たりの子の最大数を、通常、「ツリーのオーダー」と呼ぶ。
【００１１】
或るノード／リーフはネットワーク・オブジェクトに対してローカル的な情報を反映することができる。例えば、現在のＣＰＵ負荷はツリー上のリーフでよい。最新の値を反映するため、このリーフは頻繁に更新しなければならない。
ノードとリーフとは拡張マークアップ言語（Extensible Markup Language ＸＭＬ）タグ（定義は後で示す）で表してよく、ＸＭＬ構造を階層データベースとして用いてよい。この概念はＷＯ  ０１３３４３３に開示されている。
【００１２】
ＸＭＬは、ワールド・ワイド・ウエブ・コンソーシアム（Ｗ３Ｃ）の公式勧告に従う、共通の情報フォーマットを作成するための柔軟な方法である。これはウエブ・ページ内容を生成するのに用いられる周知のＨＴＭＬ言語と同様である。ＸＭＬもＨＴＭＬもページまたはファイルの内容を記述するためのマークアップ・シンボルを含む。しかし、ＨＴＭＬはウエブ・ページ（主としてテキストと画像）を図的にどのように表示するかだけを記述するが、ＸＭＬはページ内の情報の実際の内容（ＣＰＵ使用を表す数など）を記述する。
【００１３】
本発明で後で説明するが、ＸＭＬ構造で情報を保存するといくつかの利点がある。
・  ＸＭＬ構造はリポジトリの階層構造をサポートする。これによりオペレータ（例えば、ＷＨＣマネージャ）は、個別のコンピュータにアクセスしまた個別のコンピュータから情報を検索するのではなく、同じリポジトリに関連する全てのコンピュータに関する情報に１つの場所（すなわち、ルート）からアクセスすることができる。ルート・コンピュータを含むコンピュータはＬＡＮの一部でよい。この方法はより容易で、より高速で、より一般的である。なぜなら、複数のコンピュータではなく１つのコンピュータだけを処理すればよいからである。
【００１４】
・  拡張性  −  既存の情報を変更することなく新しいノードや情報を追加することができる。
・  人が読めるフォーマットで情報を保持するので、任意のブラウザを用いて情報を閲覧したり探したりすることができる。
・  決定された情報  −  各情報エンティティを設置する場所（およびフォーマット）は特定の要素のＸＭＬの一部として定義される。
【００１５】
・  ツリーの深さは制限ない。なぜなら、既存のレベルの下に新しいレベルを追加することができるからである。
・  現在、ＸＭＬファイルを読んだり書いたりするための種々のツールが市販されているので、情報の管理はユーザが書くことのできる外部プログラムを用いて行うことができる。
【００１６】
ＸＭＬベースのリポジトリは単一ファイルとして記憶することができるが、以下の理由から、これを実現するときはより小さな複数のファイルを用いる方がよい。
・  より小さなファイルの方がファイルを更新するときの計算負荷が小さい。データベースを含むＸＭＬファイルはかなりの量のデータを含むので、かかるファイルを更新する計算負荷はかなり大きい。したがって、データベースからのデータを更新し、追加し、または削除するプロセスは非常に遅いことがある。また、ＸＭＬファイルは順次編成ファイルである。データ処理の観点からすると、順次編成ファイルはいくつかの欠点を有する。例えば、レコードのサイズは異なってよいので、変更するのは余り簡単ではない。したがって、ファイルのサイズが小さいほど、ファイルを更新する計算負荷は小さくなる。
【００１７】
・  情報の完全性を保証する仕組みを有するリレーショナル・データベースとは異なり、ＸＭＬファイルは標準のシステム・ファイルであるから、更新プロセス中にシステム・クラッシュにより破壊する可能性がある。ファイルが小さければかかるクラッシュの可能性が小さくなる。
・  ＸＭＬファイルを処理するには全ファイルを高速アクセス・メモリ内にロードする必要がある。したがって、データが多くの小さなファイルに分割されているＸＭＬベースのデータベースを処理すれば、必要なメモリ資源の量は非常に小さい。
【００１８】
呼出しアプリケーション(calling application)は、コンピュータの資源や構成に関する必要な情報を検索または更新するためにリポジトリにアクセスする外部プログラムである。これはＷＨＣマネージャ側とクライアント側の両方から来る。例えば、これは使用した資源についてクライアントに請求書を送るプログラムでよい。このプログラムは、リポジトリに要求を送って各クライアントに関する情報を検索する。逆に、請求書が正しいかどうかクライアントがチェックしたいとき、自分のプログラムを用いてリポジトリ内の自分の勘定をチェックすることができる。通常、呼出しアプリケーションは、必要な情報を検索するリポジトリの正確な場所に導かなければならない。
【００１９】
ＸＭＬを階層データベースとして用いることはこの技術で周知であるが、現在の方法はいくつかの欠点を有する。例えば、操作が容易でなく、また情報を記憶するための単なるツールとして以外の機能がほとんどない。かかるＸＭＬデータベースに欠けている１つの重要な機能は、オペレータに透過的な方法で情報にアクセスする能力である。言い換えると、この種のデータベースでは、オペレータ（すなわち、ユーザ）は必要なデータを検索するためにデータベース内の正確な位置にアクセスするというプロセスを直接行わなければならない。このプロシージャはコンピュータ時間に関しては無駄であって、硬直性と厄介とを引き起こす。なぜなら、呼出しアプリケーションはデータベース内の情報を単に求めるのではなく、どこを探すかを常に知る必要があるからである。別の大きな欠点は、或るコンピュータ内に含まれるデータにアクセスするにはそのコンピュータ自体にアクセスする必要があることであり、要求を処理する１台の中央コンピュータがない。これは複数のコンピュータから情報を検索しようとするときに問題になる。なぜなら、１台毎に１つの要求を行う必要があるからである。
【００２０】
ＳＮＭＰ（単純ネットワーク管理プロトコル  Simple Network Management Protocol）はＸＭＬベースのデータベースと同様の目的で用いられる。これは広く用いられているネットワーク管理プロトコルである。ＳＮＭＰはアプリケーション・レベルで設計され、ＮＭＳ（ネットワーク管理システム）とネットワーク装置内に設けられた「エージェント」との間で管理に関する情報を転送することを可能にする。エージェントはネットワーク装置からこの情報を集め、また関係するネットワーク装置に対して管理操作（パラメータの設定など）を行う。ＳＮＭＰを用いることにより、ネットワーク・マネージャはネットワークに関する情報にアクセスすることができる。これは、管理されるオブジェクトに関する情報を記憶するリポジトリと、リポジトリ（遠方のコンピュータ上に存在してよい）を管理するプログラムとを用いる。中央の場所から複数の装置を制御するには、管理するコンピュータの間でネットワークのコンピュータに関する情報を送る経路となる「ルート」コンピュータも必要である。
【００２１】
しかしＳＮＭＰはいくつかの欠点を有する。
・  リポジトリを管理するコンピュータと「ルート」コンピュータとの間で交換される情報はテキストそのもの（暗号化されていない）で送られる。したがって、情報が悪用される危険がある。
・  ＳＮＭＰリポジトリのツリー・レベルは制限されるので、表される情報も制限される。
【００２２】
・  ＳＮＭＰプロトコルはユーザ定義プロトコル（ＵＤＰ）を用いる。これは「引渡しが保証され」ない通信プロトコルである。すなわち、発信源から送られた情報が宛先に届くことを保証する仕組みがなく、また伝送失敗を表す失敗メッセージが戻されない。
【００２３】
・  ＳＮＭＰはＡＳＮ．１フォーマットを用いる。これは変更すべき要素を記述するために特有の番号を各プロパティに割り当てる。このフォーマットはテキスト・ベースのコマンドと名ではなくて番号を用いるので、ＳＮＭＰコマンドを理解するのは非常に困難である。また、ユーザは簡単なコマンド・ラインを書くのではなく、ＳＮＭＰ操作毎に、簡単なものではあるが厄介なツールを用いなければならない。
・  ＳＮＭＰはポート１６０と１６１とを用いる。データ・センタでコンピュータの前にファイアウォールが設けられると、これらは閉じられる。したがって、ユーザは自分のホーム・コンピュータから自分の情報にアクセスすることができない。
【００２４】
・  ＳＮＭＰは１つのコンピュータから別のコンピュータに切替えることができない。言い換えると、本発明が提案するようなＸＭＬの階層ツリー特性をサポートしない。したがって、複数のコンピュータにアクセスするとき、全てのコマンドをまとめてルートに送るのではなく、各コマンドをその関係するコンピュータに送らなければならない。またこのために、呼び出しアプリケーションが関係するコンピュータにアクセスできるようにするには、各コンピュータは自分の固有のＩＰアドレスを有しなければならない。後者の機能は勧められない。なぜなら、かかる国際的ＩＰは少なくなりつつあるからである。この問題を解決するには、ロード・バランサ(load-balancer)を用いて、単一ＩＰアドレスの下で複数のコンピュータの間の情報のトラフィックを調整すればよい。しかし、管理されるコンピュータがロード・バランサの背後にある場合は、これはローカルのアドレスだけを有するのでＳＮＭＰを用いることができない。したがって、ＳＮＭＰは単一コンピュータ・レベルの場合にだけ用いられる技術である。
【００２５】
ＳＯＡＰ（シンプル・オブジェクト・アクセス・プロトコル）は、情報を交換する仕組みとしてＨＴＴＰおよびＸＭＬを用いて、異なるコンピュータまたはオペレーティング・システム上で走るプログラムの間で通信できるようにするためのプロトコルである。ＳＯＡＰはＨＴＴＰヘッダとＸＭＬファイルとを正確に符号化する方法を指定するので、１つのコンピュータ内のプログラムは別のコンピュータ内のプログラムを呼び出して情報を交換することができる。またこのようにして接触したプログラムが応答する方法も指定する。しかしＳＯＡＰでは情報を暗号化することができず、また要求の中の情報のためにＸＭＬを排他的に用いることができない。更に、或るコンピュータに関する情報の要求はこのコンピュータに直接送らなければならないので、複数のコンピュータから情報を集めるには複数の要求を行う必要がある。
【発明の開示】
【発明が解決しようとする課題】
【００２６】
上に述べた解決策はコンピュータ資源を容易にかつ効率的に管理するという問題、または同様の他の問題に対する満足できる解決策ではない。
本発明の１つの目的は、データ・メモリと処理時間の両方について、遠方のユーザが使用するコンピュータ資源を効率的に管理する方法を与えることである。
【００２７】
本発明の別の目的は、１台だけの（すなわち、中央の）コンピュータと通信しながら、複数のコンピュータの間に分散されているコンピュータ資源をユーザが利用することを可能にする方法を与えることである。
本発明の更に別の目的は、ユーザに割り当てられたコンピュータ資源をコンピュータ・システム・マネージャが動的に変更するときにこの変更をユーザに透過的にする方法を与えることである。
【００２８】
本発明の更に別の目的は、遠方のユーザが使用するコンピュータ資源を管理する方法を与えて、呼出しアプリケーションが管理に必要なデータに容易にかつ簡単にアクセスすることを可能にすることである。
本発明の他の目的や利点は説明が進むに従って明らかになる。
【課題を解決するための手段】
【００２９】
本発明は、コンピュータ化されたマネージャがコンピュータ資源を複数のユーザに透過的に割り当てることを可能にする方法に関するもので、この方法は、
ａ．  前記コンピュータ資源を適応させまたはデータを記憶するための複数のコンピュータまたはサーバを設け、前記コンピュータ資源および前記データを階層リポジトリとして配置し、
ｂ．  前記ユーザと前記コンピュータまたはサーバとの間のインターフェースであるルート・コンピュータを設け、前記ルート・コンピュータは、
（１）  前記ユーザと通信し、
（２）  前記コンピュータまたはサーバと通信し、
（３）  前記コンピュータまたはサーバを制御し、
（４）  前記マネージャがコンピュータ資源を前記ユーザに割り当てることを可能にする、
機能を有し、
ｃ．  前記コンピュータまたはサーバ内に、ローカルのリポジトリ内に、または前記コンピュータまたはサーバのシステム・ファイル内に情報を記憶し、
ｄ．  必要に応じて、記憶された情報を前記コンピュータまたはサーバから検索し、
ｅ．  前記マネージャは前記ルート・コンピュータを介して、前記ユーザの連続的な操作を妨げずに、前記ユーザ毎に要求されたコンピュータ資源を動的に割り当てる、
ことを含む。
【００３０】
好ましくは、コンピュータ／サーバ、コンピュータ資源、記憶された情報、ユーザ、および関連する経路は全て階層リポジトリとして配置し、階層リポジトリの階層構造はこれとインターフェースするユーザに見えるが、この階層リポジトリ内の情報の内部編成（すなわち、どの情報がどのサーバに保持されているかについて）はユーザに透過的である。また、ルート・コンピュータは好ましくは１次エージェントであって、次のどの活動も行う。すなわち、
ａ．  ユーザから要求を受け、
ｂ．  前記要求を処理し、
ｃ．  前記リポジトリ内の要求された資源を探し、
ｄ．  必要であれば、前記資源で前記要求を実行し、
ｅ．  必要であれば、前記要求に対する回答を前記ユーザに送る。
また、各サーバは好ましくは２次エージェントを含む。この２次エージェントは１次エージェントから要求を受け、サーバでユーザのために要求を実行する。
【００３１】
ユーザとルート・コンピュータとの間、および前記ルート・コンピュータとコンピュータ／サーバとの間の通信は、好ましくはＴＣＰインターネット通信プロトコル（ＴＣＰ／ＩＰ）で実現する。
【００３２】
リポジトリには好ましくはＸＭＬフォーマットの要求を用いてアクセスする。これは、情報を保持する１つのファイル、またはそれぞれがリポジトリの異なる部分を処理する複数のファイルにアクセスする。オプションであるが、コンピュータ／サーバ内の各コンピュータはリポジトリに関連する単一ＸＭＬファイルを含む。リポジトリは、それぞれがリポジトリの異なる部分を処理する複数のデータベース・テーブルで処理することもできる。
【００３３】
またメモリ・スペースを節約するために、この方法はテンプレートを使用することを含む。各テンプレートは少なくとも２つのノードが共用するデータに関連し、リンクによりこれらのノードからアクセスすることができる。これらのリンクは存在する１次または２次エージェントにより、必要に応じて活動化してよい。
【実施例】
【００３４】
図１は、本発明の好ましい実施の形態に係る、コンピュータ・ネットワークの例示的な階層構造を示す。対応する（すなわち、割り当てられた）コンピュータ資源（例えば、ＣＯＭＰ１  １１０のＣＰＵ）や、（種々の）アプリケーション・ソフトウエア（例えば、ＣＯＭＰ１  １１０内に存在するＡｕｔｏＣａｄアプリケーション）や、対応する結果ファイルと、ユーザ（例えば、ＵＳＥＲ１  １０７）とを関連づけるデータは、コンピュータ資源マネージャ１０９（以後、資源サービス・プロバイダ（ＲＳＰ）と呼ぶ）が管理する階層リポジトリ（１００）に編成される。ルート・コンピュータ１０１を用いることにより、ＲＳＰ１０９はリポジトリに対してユーザを追加／削除したり、資源割当てを（随意に）変えたりすることができる。リポジトリ１００により、コンピュータ資源を容易にかつ動的に再配分することや、結果ファイルを容易にリポジトリ内で検索し、再配置し、分散することが可能になり、ＲＳＰのコンピュータ資源を完全に利用することができる。活動がユーザに透過的であることや、コンピュータ資源を変更することや、リポジトリ１００内のファイルを再配置および／または分配することは、ユーザの通常の活動を妨げない。
【００３５】
ＲＳＰ１０９は、最初は契約に従ってコンピュータ資源をユーザに割り当てるが、各ユーザの特定の必要に従って割当てを変更してよい。また、ユーザ／クライアントによるコンピュータ資源の実際の使用を反映する統計的評価基準を用いて、割当てプロセスはＲＳＰ１０９が自動的に行ってよい。例えば、ＵＳＥＲ２がその割り当てられたメモリの５０％しか使用しない場合は、残りのメモリ容量の一部または全部を、追加のメモリを要求する例えばＵＳＥＲ１に割り当ててよい。ＵＳＥＲ１とＵＳＥＲ２とは資源の再配分の変化を認識せず、またこの変化により妨害されることはない。
【００３６】
ユーザが利用可能な資源とは異なり、実際のユーザのアカウントは好ましくはポジトリ内で分散され、各サーバは自分のユーザを有する。例えば、サーバＣＯＭＰ１（１１０）はＵＳＥＲ１（１０７）とＵＳＥＲ２（１１３）のアカウントを保持する。これらのユーザはこのサーバにログインし、そこで動作することができる。容易な方法でユーザを管理するために、トップ・レベルの「ＡＬＬＵＳＥＲＳ」ノード（１０３）（リポジトリの外部）で表される中央リストが全ての機械上の全てのユーザに関する情報を保持する。これはいくつかの方法で実現することができる。
・  実際のノードとして。ユーザが各サーバに追加または削除されるとこれを更新しなければならない。この方法は、更新する度に追加の計算と通信とを行う必要がある。したがって、この情報の問合せが比較的少ない場合は非効率的である。この方法は多くの問合せが行われる（情報がローカルで検索され、通信する必要がない）場合に適している。
【００３７】
・  「仮想ノード」として。これについては後で説明する。これは、ルート・ノード（１０１）から情報が要求されると各サーバに問い合わせることを意味する。この方法では通信と操作は更新毎には行わないが、問合せ毎には必要である。したがって、問合せが比較的少なく、更新が比較的多い場合に効率的である。
【００３８】
両方の実施の形態はそれぞれの利点を有するので、システム内の代表的な動作に従って最良の方法を取るべきである。標準的な解決策はどちらかの方法に従って情報を保存する必要があり、方法を変えるとクライアント・ソフトウエアも変える必要がある。
【００３９】
リポジトリ内のアプリケーションを活動化するには、ユーザはリポジトリ１００ｂを管理する１次エージェントを含むルート・コンピュータ１０１に「要求」を送る。要求を解釈することは、要求を送った者（すなわち、ユーザ）のＩＤと、そのユーザが要求した情報とを識別し、次に１次エージェントはユーザのために情報を検索するか、または情報を供給することのできるサーバ上の２次エージェントに階層リポジトリを介してユーザを導くことを含む。ユーザは２次エージェントの場所（すなわち、コンピュータＩＤ）も、自分のファイルが記憶されているメモリ位置も知らない（すなわち、後者のプロセスはユーザに透過的である）。
【００４０】
ＡＬＬＵＳＥＲＳ１０３は仮想ノードであり、ルート・コンピュータ１０１のシステムの完全に内部に存在する。仮想ノードの仕事は、各ユーザに関連するコンピュータ資源の処理を容易にするために、全てのユーザ（例えば、ＵＳＥＲ１  １０４）を含むリストを保持することである。仮想ノードはプロシージャを含んでよい。この場合、プロシージャはユーザから要求を受け付けてリポジトリからデータを取り出すよう形成される。
【００４１】
コンピュータ１１０（すなわち、ＣＯＭＰ１）のＩＰアドレス１２０は「＼ＣＯＭＰＵＴＥＳ＼ＣＯＭＰ１＼ＩＰ」で探し出すことができる。左の第１の文字「＼」はルート・コンピュータ１０１を表し、その後にノード、ＣＯＭＰＵＴＥＲＳ（１０２）とＣＯＭＰ１（１１０）が続く。最後のエンティティ「＼ＩＰ」はＣＯＭＰ１（１１０）のＩＰアドレスを表すアドレス・ノード１２０を指す。各コンピュータ（例えば、ＣＯＭＰ１  １１０）はこの階層方式でその情報（ホスト名、ＩＰアドレスなど）を保持することができる。
【００４２】
図２は、本発明の好ましい実施の形態に係る、図１に示すリポジトリをＸＭＬフォーマットで示す。リポジトリの階層構造が、ツリーのより下位のノードを表す、よりインデントされた項目で示されている。「．．．」はＸＭＬ構文の一部ではなく、不特定のテキストを示すために挿入しただけである。
【００４３】
ＸＭＬベースのリポジトリを単一ファイル内に記憶することに関連する、上に説明した問題を避けるための種々の方法がある。本発明では、単一ファイルを用いるのではなく、リポジトリを複数のファイルに分割してよい。例えば、各ノードおよび／またはリーフを別個のファイル内に置いてよい。したがって、データ・エンティティは小さなファイルであって、高速処理（ファイルにアクセスし、レコードを更新し、削除し、追加すること）が保証される。
【００４４】
本発明の別の実施の形態では、各コンピュータはリポジトリに関連する単一ＸＭＬファイルを含む。これはホスト・コンピュータに関するリポジトリ情報の一部を保持する。例えば、ＣＯＭＰ１（１１０）に関する情報はローカルにＣＯＭＰ１サーバ上に保存され、ＣＯＭＰ２（１１１）に関する情報はローカルにＣＯＭＰ２サーバ上に保存される、など。
【００４５】
本発明に開示されたＸＭＬベースのリポジトリは、いくつかの重要な機能を追加することにより、既存のリポジトリ管理手法の操作の容易さと効率とを増強する。第１の機能は隠蔽(encapsulation)である。
【００４６】
隠蔽
本発明は呼出しアプリケーションから情報源を隠蔽する。この機能は、呼出しアプリケーションが要求する情報を検索するための正確な位置をリポジトリに指定する役目を呼出しアプリケーションから除く。
【００４７】
データ・ネットワークのマネージャが、任意のネットワーク・コンピュータのソースと構成に関連するデータを要求すると（すなわち、対応する呼出しアプリケーションおよびＡＰＩ（後で説明する）を用いて）、この要求はルート・コンピュータ内に存在する「エージェント」（以後、「１次エージェント」と呼ぶ）に送られる。エージェントの仕事はこの要求を処理することである。要求の「処理」は呼出しアプリケーションが要求したデータを識別し（すなわち、要求を分析することにより）、ツリー構造のリポジトリ内の要求されたデータを探し、データを検索し、データをマネージャに送ることを含む。呼出しアプリケーションとエージェントとの間のデータの交換は当業者に周知の機能である。
【００４８】
本発明では、呼出しアプリケーションはどの情報を要求するかをエージェントに指定するだけでよく、その後エージェントはその情報を見つけて検索する。呼出しアプリケーションはリポジトリ内の要求されたデータの位置を知る必要はない。この「ルート」すなわち１次エージェントは、要求されたデータを３つの可能な場所から検索する。
（１）  自分の本体から、すなわち、ルート・コンピュータ内に存在するリポジトリから、
（２）  別のコンピュータ内に存在するリポジトリから、
（３）  オペレーティング・システム内の仮想メモリから（後で説明する）。
【００４９】
本発明の好ましい実施の形態では、各コンピュータは「２次エージェント」を有する。その仕事はそのコンピュータに関連する必要なデータを得ることと、１次エージェントと通信することである。したがって、要求が１次エージェントに送られると、１次エージェントは要求を分析し、ツリー構造のリポジトリ内の要求されたデータの位置を見つけ、対応する２次エージェントにアドレス指定する（すなわち、通信する）。２次エージェントはこれに応えて、要求された情報をその関連するコンピュータから検索し、検索された情報を１次エージェント（すなわち、要求者）に送る。１次エージェントは、要求されたデータを受けるとこのデータを呼出しアプリケーション（すなわち、ネットワーク・マネージャ）に送る。
【００５０】
ここでの顕著な利点は、情報が実際にどこから検索されたかを呼出しアプリケーションが知らないことである。したがって、この隠蔽機能により呼出しアプリケーションをより柔軟に用いることができるし（絶えず変える必要がないので）、必要に応じて、外部のユーザ／要求者に透過的に、コンピュータ内で情報を動かすことができる。例えば、ルート・ノード（１０１）上の特定のコンピュータに関する或る情報（ＣＰＵの数など）も保存するとする（この情報が滅多に変わらないので）。この場合は、＼ＣＯＭＰＵＴＥＲＳ＼ＣＯＭＰ１＼ｎｕｍｂｅｒ−ｏｆ−ｃｐｕｓに関する問合せは１次エージェント（１０１）で行われ、特定の２次サーバ（１１０）には送られない。別のオプションは、その値をサーバ自体の１次エージェント内に保存し、要求の度に検索をしないことである。第３の選択肢は、もちろん、情報が必要なときにサーバ１１０のハードウエアに実際に問い合わせることである。どのオプションを選択しても、ユーザとのインターフェースは変わらない。
【００５１】
本発明の１つの態様では、ネットワーク内のユーザもネットワーク・マネージャと実質的に同じ方法でリポジトリからデータを得てよいことである。このため、ユーザは対応する呼出しアプリケーションを用いてルート・コンピュータに要求を送り、その１次エージェントは上述と実質的に同じ方法で反応する。すなわち、要求を分析し、リポジトリ内の要求されたデータを探すかまたはネットワーク・マネージャから得て、得られたデータを要求したユーザに送る。しかし、ネットワーク・マネージャとネットワーク・ユーザとの間には本質的な差がある。マネージャは、対応するコマンドをルート・コンピュータに送ることにより、ユーザが用いることのできるコンピュータ源を操作することもできる。ユーザができるのは、そのコンピュータ源に関するデータを得て（すなわち、読み取って）、例えば、コンピュータの使用に関連する請求書が正しいかどうかをチェックすることだけである。
【００５２】
最初にデータを要求したエンド・ユーザからルート・コンピュータまでと、ルート・コンピュータからネットワーク内の残りのコンピュータまでの、上に述べたプロセスに関わる全ての通信は、情報の安全な転送を保証するＴＣＰ／ＩＰプロトコルで行われる。
【００５３】
仮想リーフ／ノード
本発明の１つの態様では、或る情報はファイル内に記憶せずに「仮想メモリ」の場所から検索する。これは仮想ノードを用いて行う。仮想ノードは、頻繁に求められる（そして、ローカルのリポジトリ内にデフォールトで記憶されていない）情報かまたは埋込みアプリケーション（リポジトリ内に保存されるのではなくルート・コンピュータのオペレーティング・システムの一部である特性を検索しまた設定する）を含む。仮想ノードの値は必要に応じて設定／検索される。
【００５４】
ＸＭＬファイルで実現される「コンスタント・メモリ」とは異なり、仮想ノードはプロシージャにより操作する。全てのプロシージャは、選択されたコンピュータまたはコンピュータ・サービスと対話し、必要に応じて、予め定められた評価基準に従ってそこからデータを得、そして得られたデータをルート・コンピュータに送ることができるよう形成される。要求されたデータは１次エージェントのリポジトリ内のどこかに存在するのではなく、要求されたときに（すなわち、ルート・コンピュータによりプロシージャが「活動化された」ときに）生成される。各プロシージャの出力（すなわち、得られたデータ）は所定の時刻にルート・コンピュータが要求したデータに従って動的に変化し、前に生成されてすでに関係がなくなったデータは消去される。
【００５５】
通常、表の名や列の名などを用いてエージェントがリポジトリを探して関係するレコードを検索すると、情報が検索される。解決策の１つの態様では、エージェントは別のオプションを有する。エージェントはそのプログラムされた論理を用いて、リポジトリから情報を検索すべきかまたは仮想ノード（もしあれば）から検索すべきか判定する。上に述べた隠蔽機能により、呼出しアプリケーションはこの情報が実際に記憶されている正確な位置を知らない。
【００５６】
ある例示的なプロセスでは、コンピュータのオペレーティング・システムは許可されたユーザのリストをファイル内に保持する。再び図１を参照して、ＵＳＥＲ１が定義されているサーバ（１１０）のエージェントは発呼者からの要求を受けてＵＳＥＲ１（１０７）のパラメータを検索するが、またシステム呼出しを行って、ＵＳＥＲ１の情報が存在するオペレーティング・システム内の関係する場所からこのデータを検索する。要求されたデータは、リポジトリの一部であるかのように発呼者に戻される。このプロセスは発呼者に透過的である。ルート（＼）コンピュータ１０１の子であるノードＡＬＬＵＳＥＲＳ（１０３）は、ネットワーク内の全てのユーザを表す仮想ノードを象徴する。これは更に特定の仮想ノードに分割される。ＵＳＥＲ１（１０４）を表すリーフに見られるように、各仮想ノードはノード１０３の子である特定のユーザに関する情報を含む。このリーフは、実際に別のサーバ（１０７）上にあるノードを記述する。
【００５７】
同様にして、ユーザはネットワーク内の全てのユーザに関する情報を要求してよい。ユーザが要求するこの全体リストをエージェントがユーザに示すと、ユーザには、このリストはまさにルート・コンピュータ「＼」（１０１）の下にあり、エージェントは単にこれをそこから取るように見える。しかし実際には次のことが起こる。外部ユーザが「ＡＬＬＵＳＥＲＳ」（１０３）を要求すると、「＼」（１０１）上のエージェントは「ＡＬＬＵＳＥＲＳ」仮想ノード１０３が指定するプロセスを実行し、エージェントは「ＣＯＭＰ１」（１１０）に行ってその「ＡＬＬＵＳＥＲＳ」リスト１３０を要求する。エージェントは同じことを全ての他のコンピュータ（ＣＯＭＰ１  １１０を除く）に対して行い、集積されたリストを返す。呼出しアプリケーションは後者のプロセスを認識しない。上に述べたように、ユーザには全体ユーザ・リストがそのままが「＼」（１０１）の下にあるように見える。
【００５８】
次の例はリポジトリより仮想ノードを用いる方がよいことを示す。ユーザがそのコンピュータの現在のＣＰＵの使用量を得たいとする（これは絶えず変化する値である）。１つの方法は、後者の値を或る時間間隔毎に得てリポジトリ内に記憶するためのプロセスを有することである。しかし、これは滅多に用いられない操作のためにコンピュータ資源を浪費する原因になる。より優れた方法（そして、より正確な方法）は、要求されたときだけその値を得ることである。しかし、ユーザはＸＭＬリポジトリにアクセスするときと同じインターフェースを用いることが望ましい。仮想ノードが重要な役割を演じるのはここである。ユーザの呼出しアプリケーションが１次エージェントにこの値を要求すると、１次エージェントはオペレーティング・システム内の、ＣＰＵの使用量を得るプロセスを実行する仮想ノード１０５に連絡する。この値が得られると、１次エージェントはリポジトリから取ったかのようにこれをユーザに送る。
【００５９】
システムが上に説明した隠蔽機能を有するときは、仮想ノードは、システムから情報を検索してしかもリポジトリからこの情報を検索したかのように見せる方法の１つの例である。仮想ノード内に情報を保存してそこから検索すると（実際にコンピュータ自体にアクセスするのではなく）、情報源は変えるが呼出しアプリケーションは変えないことが可能になる。これにより情報にアクセスする単一の統一された方法が得られるので、この情報へのアクセスが簡単になる。
【００６０】
データへのアクセスを速くすることに加えて、仮想ノードはこれに関する活動も行う。例えば、操作が情報をＸＭＬデータベース内に記憶することだけである場合、ユーザを追加しようとすると呼出しアプリケーションはユーザを追加するための関係するオペレーティング・システム・ツールを走らせる必要がある。リポジトリは種々のオペレーティング・システムにより処理してよいので、呼出しシステムのライタは自分が用いるオペレーティング・システムの種類とそれを活動化する方法を知らないことがあるし、また自分をシステムに認証しなければならない。仮想ノードを用いるとこの仕事を行わなくてよく、またこの仕事を行う方法を知る必要もない。両側（すなわち、ＷＨＣとそのクライアント）が同意すれば、必要に応じて新しい仮想ノードを追加することができる。
【００６１】
或るリポジトリ・データは同時に仮想的および物理的なものとして保持することができる。例えば、許可されたユーザに関する情報はオペレーティング・システムのファイル内とリポジトリ内に同時に保存される。このようにすれば、或る操作はシステム・ユーティリティにアクセスせずに実行することができる。例えば、該当するシステム・ファイルではなくリポジトリから直接情報を受けることにより、ユーザのリストを検索することができる。これらのノードは、情報にアクセスする両方法の利点を用いる必要がある（或るときにはプロセス時間を節約することがより重要であり、また或るときにはコンピュータ資源がより重要である）とユーザが決定したときに用いることができる。
【００６２】
テンプレート
同じ種類で同じ構成の多数のコンピュータを接続するネットワークを考える。通常、各コンピュータの構成はリポジトリ内のそれぞれの場所に記憶される。本発明の１つの態様では、リポジトリ内の１つの表に１つの構成だけを記憶して他のコンピュータのレコードがこの表を指すようにすれば、かなりのスペースを節約することができる。言い換えると、この構成を記憶するためにリポジトリ内の各コンピュータのレコード内にスペースを割り当てるのではなく、各コンピュータのレコードは共用する表へのリンクを含む。もちろん、これが行われるのは、この共用構成がこれを用いる全てのコンピュータに共通である場合だけである。これをリポジトリ内のテンプレート特性と呼ぶ。
【００６３】
１つのコンピュータ内の構成の或るフィールドを、共用構成内のものとは異なる値に変える必要がある場合は、このフィールドをリポジトリ内のこの特定のコンピュータのレコードに追加して、新しい値を割り当てる。例えば、或る量のメモリを１つのコンピュータに追加すると、フィールド「ＭＥＭＯＲＹ」がこれに追加され、その新しい値は共用構成内のデフォールト値を無効にする。
【００６４】
或るフィールドがそのデフォールト値に戻されると、新しい値をリポジトリ内に記憶するかまたはそのフィールドを関係するレコードから消去する。するとその新しい値が再び共用構成内のデフォールト値になる。後者の方法は時間がかかるが、かなりのスペースが節約になる。
【００６５】
テンプレートはその中に２つ以上のフィールドを含んでよく、またコンピュータのレコードはテンプレートへの２つ以上のリンクを含んでよい。或るコンピュータの構成内の或るフィールドを探すときは、まず、このコンピュータのレコード内のフィールドを走査する。探すフィールドがそこにない場合は、このレコードが用いる全てのテンプレートを、このフィールドがその中の１つで見つかるまでその順序に従って走査する。
【００６６】
図３は、本発明の好ましい実施の形態に係る、ＣＯＭＰ１の下のネットワークの構造の詳細な例示的なテンプレート特性を示す。コンピュータＣＯＭＰ１（３０２）は、対応するノード「ＵＳＥＲ１」から「ＵＳＥＲ  Ｎ」（それぞれ、３１１から３１４）で表されるＮ個のユーザと、ノード「ＢＯＳＳ」（３１５）で表されるボスとを有する。ボスを含むこれらのノードの全てのレコードに、ユーザの名３２１というフィールドがある。ボスのレコードは、フィールド「ＤＩＳＫ  ＱＵＯＴＡ」３２２（その値はＱ１）と「ＰＥＲＭＩＳＳＯＮ」３２３（その値はＰ１）も含む。他のユーザ（すなわち、「正規の」ユーザである「ＵＳＥＲ３１１」から「ＵＳＥＲ  Ｎ」）には、より少ないディスク割当てＱ２と、より少ない許可レベルＰ２とが割り当てられる。しかし、ボスとは異なり、これらのレコードはこれらの２つのフィールドを含まない。その代わりに、値Ｑ２とＰ２とは全ての正規のユーザに共通なので、効率化のために、これらのレコードはこれらのフィールドを含むテンプレート３２５へのリンク「ＲＥＧ．ＵＳＥＲ  ＴＥＭＰＬＡＴＥ」（３２４）を含む。このテンプレート（３２５）内では、「ＤＩＳＫ  ＱＵＯＴＡ」３２６と「ＰＥＲＭＩＳＳＯＮ」３２７のフィールドにそれぞれの値であるＱ２とＰ２が割り当てられる。同様に、ＣＯＭＰ１（３０２）が同じルートの下の多くの他のコンピュータと同じ構成を有する場合は、別の対応するテンプレートを用いて構成の詳細を記憶してよく、この場合はこのテンプレートは「ＣＯＭＰＵＴＥＲＳ」ノード（３０１）の子でよく、「ＣＯＭＰ１  ３０２」の「ＣＯＮＦ」ノード３０３がそれへのリンクを含んでよい。
【００６７】
ＡＰＩの実現
ＡＰＩ（アプリケーション・プログラミング・インターフェース）はアプリケーション・プログラムがオペレーティング・システムまたはその他のサービスにアクセスするためのインターフェースである。ＡＰＩはソース・コード・レベルで定義される。
【００６８】
本発明の１つの実施の形態では、リポジトリにアクセスするためのＡＰＩはノード／リーフを追加し、削除し、更新し、検索するためのコマンドを含まなければならない。例えば、
・  追加：  新しいノード／リーフをリポジトリに追加する。例えば、新しいユーザを既存のコンピュータに追加する。
・  削除：  既存のノード／リーフを、その下の全てのノード／リーフと共に削除する。例えば、コンピュータを削除する。
・  更新：  既存のリーフ内の情報を更新する。例えば、ユーザのディスク割当てを増やす。
・  取得：  特定のノード／リーフに関する情報を検索する。例えば、コンピュータのＩＰ。
・  取得リスト：  ツリー内の同じレベルのリポジトリ内の複数のノード／リーフの情報を検索する。例えば、ユーザのリスト。
本発明の１つの実施の形態では、ＡＰＩはＸＭＬ構文に対応する。
【００６９】
図４は、本発明の１つの態様に係る例示的なＡＰＩコマンド・コードを示す。この例は図１に関係する。ＡＰＩコマンド・コード（コマンド・コード４００など）は少なくとも次の要素を含まなければならない。
・  操作の種類（この例では「ＣＭＤ４０１」）
・  オブジェクト・ノード／リーフ（この例では「ＫＥＹＳ＿ＰＡＴＨ４０２」）
【００７０】
コマンド・コード４００は要求番号４０３も含む。これは応答（リポジトリからの）と、対応する要求および追加のパラメータとを関連付ける特有のＩＤである。
この例では、コマンド４００は新しいユーザ「ＵＳＥＲ４」（４０５）をコンピュータ「ＣＯＭＰ１」（４０６）に追加するようエージェントに命令する。ユーザの名は「Ｄａｖｉｄ」（４０５）であり、彼のディスク割当ては２０（４０８）である。
【００７１】
図５は、本発明の１つの態様に係る、図４に示す要求への応答の例示的な結果を示す。応答（この例では「ＲＥＳＵＬＴ」フィールド５０１に示す）は「ＯＫ」である。
【００７２】
図６は、本発明の好ましい実施の形態に係る、ユーザ・リストを検索するための要求への例示的な応答を示す。この例は前の図に示すリポジトリを参照する。回答では各レコードは「＜ＮＯＤＥ」タグ（６０１）として返される。
【００７３】
図７は、本発明の１つの態様に係る、例示的な「誤り」応答を示す。応答（７００）はコマンドのＩＤ番号７０１、誤り番号７０２、誤りの記述７０３、および結果７０４を含む。図５の場合と異なり、ここで返される結果は「ＥＲＲＯＲ」（７０４）である。
【００７４】
もちろん、要求は複数のコマンドを含んでよい。かかる場合は、要求内にはコマンドを保持する１つの「ルート」ノードがある。本発明の１つの態様では、コマンドが失敗した場合は、複数の選択肢で適応してよい。すなわち、
・  他のコマンドの実行を続ける。
・  残りのコマンドの実行を停止するが、これまで完了した操作の結果は保存する。
残りのコマンドの実行を停止して、全ての前のコマンドの結果を取り消す。
【００７５】
本発明のいくつかの実施の形態について例を用いて説明したが、本発明は、本発明の精神から逸れたりクレームの範囲を超えたりすることなく、当業者の範囲内の多くの修正や変更や適応を用いて、また種々の同等のまたは代替の方法を用いて実行することができる。
【図面の簡単な説明】
【００７６】
本発明の上述の特徴および利点は、添付の図面を参照して好ましい実施の形態の例示的で非制限的な詳細な説明を読めばよく理解される。
【図１】本発明の好ましい実施の形態に係る、コンピュータ・ネットワークの例示的な階層構造を示す略図である。
【図２】図１に示す階層構造の実際のＸＭＬフォーマットを示す。
【図３】テンプレートの使用を示す、図１に示す例示的なコンピュータ・ネットワークの部分図の略図である。
【図４】本発明の好ましい実施の形態に係る、ＡＰＩコマンドを示す。
【図５】本発明の１つの態様に係る、図４に示す要求に対する応答（成功を示す）を示す。
【図６】本発明の１つの態様に係る、ユーザのリストの検索の要求に対する応答を示す。
【図７】本発明の１つの態様に係る、誤りを報告する応答を示す。
【図１】
2006504177.tif 000002
【図２】
2006504177.tif 000003
【図３】
2006504177.tif 000004
【図４】
2006504177.tif 000005
【図５】
2006504177.tif 000006
【図６】
2006504177.tif 000007
【図７】
2006504177.tif 000008
【国際調査報告】
2006504177.tif 000009
2006504177.tif 000010
2006504177.tif 000011