(57)【特許請求の範囲】
【請求項１】
少なくとも一つのクライアントと、複数のリソース・コンピュータと、前記リソース・コンピュータによって制御される複数のリソースとを有する分散ネットワークであって、前記複数のリソースのそれぞれに対応する出生論理ロケーション・サーバ・プロセス（ＬＬＳＰ）が実行されている分散ネットワーク上のリソースを識別するためにリソース管理システムによって使用される前記リソースのそれぞれに一意のリソース識別名のデータであって、
前記リソースが生成されたところのコンピュータの現在のＬＬＳＰである、出生ＬＬＳＰを識別するためのＬＬＳＰフィールドと、
前記リソースが生成されたところの出生コンピュータを識別するための出生コンピュータ・フィールドと、
前記出生コンピュータで生成された複数のリソースから前記リソースを識別するためのＩＤフィールドと、
を含むことを特徴とするリソース識別名のデータを記憶した記録媒体であって、前記リソース管理システムは、
前記リソースが当該リソースの出生コンピュータによって制御されているかどうかを判定するために、前記出生コンピュータ・フィールド及び前記ＩＤフィールドに記憶された情報を使用して、前記リソースの出生コンピュータにメッセージを送信し、
前記リソースが前記出生コンピュータによって制御されていないと判定された場合に、前記リソースを制御しているコンピュータがいずれであるかを判定するために、前記クライアントに対応する論理ロケーション・サービス・プロセスにメッセージを送信し、
前記クライアントに対応する前記論理ロケーション・サービス・プロセスが前記リソースを制御しているコンピュータの情報を有しないと判定された場合、前記ＬＬＳＰフィールドに記憶された情報を使用して、前記リソースの前記出生論理ロケーション・サービス・プロセスにメッセージを送信することを特徴とするリソース識別名のデータを記憶した記録媒体。
【請求項２】
前記ＬＬＳＰフィールドと前記出生コンピュータ・フィールドとがいっしょになって、前記出生コンピュータの論理識別名を生成する、請求項１記載の記録媒体。
【請求項３】
前記出生コンピュータ・フィールドと前記ＩＤフィールドとがいっしょになって、共通の出生ＬＬＳＰを共用する各リソースを一意的に識別するための識別名を生成する、請求項１記載の記録媒体。
【請求項４】
少なくとも１つのクライアントと、
複数のリソース・コンピュータと、
それぞれが一意のリソース識別名を有する、前記リソース・コンピュータによって制御される複数のリソースと、
分散ロケーション・サービス・システムとを含む分散ネットワークであって、
前記分散ロケーション・サービス・システムが、
（ａ）リソースおよびリソース・コンピュータの分散ディレクトリであって、前記リソースのリソース識別名から当該リソースのリソース・コンピュータをマッピングする分散ディレクトリを含むリソース・コンピュータ複数の分散サーバ・プロセスと、
（ｂ）新たなリソースが生成されたことに応じて、当該リソースに割当てるために、リソース識別名を生成するためのリソース識別名生成機構と、
（ｃ）前記リソースの一つが移行したことに応じて、当該リソースに対応する論理ロケーション・サーバ・プロセスを更新するための更新機構であって、当該リソースの追跡が可能となるように、前記更新が、当該リソースの出生論理ロケーション・サーバ・プロセスに新たなリソース・コンピュータを示し、当該リソースを移行前に制御していた論理ロケーション・サーバ・プロセスに当該リソースが移行したことを示し、前記新たなリソース・コンピュータの論理ロケーション・サーバ・プロセスに当該リソースを制御していることを示すことを含む更新機構と、
（ｄ）前記分散ディレクトリを審査して、リソース識別名からリソース・コンピュータを見つけるロケーション機構であって、前記リソースの出生リソース・コンピュータが現在そのリソースを制御しているかどうかを検出するための第一の機構と、前記クライアントに対応する前記論理ロケーション・サーバ・プロセスが、どのリソース・コンピュータが現在そのリソースを制御しているかを知っているかどうかを検出するための第二の機構と、前記リソースの出生リソース・コンピュータに対応する前記論理ロケーション・サーバ・プロセスに対し、どのリソース・コンピュータが現在そのリソースを制御しているかを要求するための第三の機構と、を含むロケーション機構と、
を含むことを特徴とする分散ネットワーク。
【請求項５】
リソース、コンピュータおよびクライアントを含み、前記リソース、前記コンピュータおよび前記クライアントに対応する一意の現在の論理ロケーション・サービス・プロセスを有し、前記リソースに、当該リソースの出生コンピュータに関する情報、および当該リソースが生成されたところのコンピュータの現在の論理ロケーション・サービス・プロセスである出生論理ロケーション・サービス・プロセスに関する情報を含む一意のリソース識別名が割当てられている分散ネットワークにおいて、リソースをクライアントから見つけるための方法であって、
リソースが当該リソースの出生コンピュータによって制御されているかどうかを判定するために、前記リソース識別名に含まれる出生コンピュータに関する情報を使用して、前記リソースの出生コンピュータにメッセージを送信するステップと、
前記出生コンピュータからの返答をチェックするステップと、
前記リソースが前記出生コンピュータによって制御されていないと判定された場合に、前記リソースを制御しているコンピュータがいずれであるかを判定するために、前記クライアントに対応する論理ロケーション・サービス・プロセスにメッセージを送信するステップと、
前記クライアントに対応する論理ロケーション・サービス・プロセスからの返答をチェックするステップと、
前記クライアントに対応する前記論理ロケーション・サービス・プロセスが前記リソースを制御しているコンピュータの情報を有しないと判定された場合、前記リソース識別名に含まれる出生論理ロケーション・サービス・プロセスに関する情報を使用して、前記リソースの前記出生論理ロケーション・サービス・プロセスにメッセージを送信するステップと、
を含む方法。
【請求項６】
前記クライアントに対応する前記論理ロケーション・サービス・プロセスが前記リソースのロケーションを知ったとき、出生論理ロケーション・サービス・プロセスからの前記返答を前記クライアントに対応する前記論理ロケーション・サービス・プロセスに記憶するステップとさらに含む、請求項５に記載の方法。
【請求項７】
リソース、コンピュータおよびクライアントを含み、前記リソース、前記コンピュータおよび前記クライアントに対応する一意の現在の論理ロケーション・サービス・プロセスを有し、前記リソースに、当該リソースの出生コンピュータに関する情報、および当該リソースが生成されたところのコンピュータの現在の論理ロケーション・サービス・プロセスである出生論理ロケーション・サービス・プロセスに関する情報を含む一意のリソース識別名が割当てられている分散ネットワークにおいて、リソースをクライアントから見つけるためのプログラムを格納した記録媒体であって、前記プログラムがクライアントに、
リソースが当該リソースの出生コンピュータによって制御されているかどうかを判定するために、前記リソース識別名に含まれる出生コンピュータに関する情報を使用して、前記リソースの出生コンピュータにメッセージを送信するステップと、
前記出生コンピュータからの返答をチェックするステップと、
前記リソースが前記出生コンピュータによって制御されていないと判定された場合に、前記リソースを制御しているコンピュータがいずれであるかを判定するために、前記クライアントに対応する論理ロケーション・サービス・プロセスにメッセージを送信するステップと、
前記クライアントに対応する論理ロケーション・サービス・プロセスからの返答をチェックするステップと、
前記クライアントに対応する前記論理ロケーション・サービス・プロセスが前記リソースを制御しているコンピュータの情報を有しないと判定された場合、前記リソース識別名に含まれる出生論理ロケーション・サービス・プロセスに関する情報を使用して、前記リソースの前記出生論理ロケーション・サービス・プロセスにメッセージを送信するステップを実行させる、記録媒体。
【請求項８】
リソース、コンピュータおよびクライアントを含み、前記リソース、前記コンピュータおよび前記クライアントに対応する一意の現在の論理ロケーション・サービス・プロセスを有し、前記リソースに、当該リソースの出生コンピュータに関する情報、および当該リソースが生成されたところのコンピュータの現在の論理ロケーション・サービス・プロセスである出生論理ロケーション・サービス・プロセスに関する情報を含む一意のリソース識別名が割当てられている分散ネットワークにおいて、リソースを見つけるクライアントであって、
リソースが当該リソースの出生コンピュータによって制御されているかどうかを判定するために、前記リソース識別名に含まれる出生コンピュータに関する情報を使用して、前記リソースの出生コンピュータにメッセージを送信する手段と、
前記出生コンピュータからの返答をチェックする手段と、
前記リソースが前記出生コンピュータによって制御されていないと判定された場合に、前記リソースを制御しているコンピュータがいずれであるかを判定するために、前記クライアントに対応する論理ロケーション・サービス・プロセスにメッセージを送信する手段と、
前記クライアントに対応する論理ロケーション・サービス・プロセスからの返答をチェックする手段と、
前記クライアントに対応する前記論理ロケーション・サービス・プロセスが前記リソースを制御しているコンピュータの情報を有しないと判定された場合、前記リソース識別名に含まれる出生論理ロケーション・サービス・プロセスに関する情報を使用して、前記リソースの前記出生論理ロケーション・サービス・プロセスにメッセージを送信する手段を備えたクライアント。
【請求項９】
リソース、コンピュータおよびクライアントを含み、前記リソース、前記コンピュータおよび前記クライアントに対応する一意の現在の論理ロケーション・サービス・プロセスを有し、前記リソースに、当該リソースの出生コンピュータに関する情報、および当該リソースが生成されたところのコンピュータの現在の論理ロケーション・サービス・プロセスである出生論理ロケーション・サービス・プロセスに関する情報を含む一意のリソース識別名が割当てられているところの、ワールド・ワイド・ウェブのネットワーク上のリソースをクライアントから発見するための方法であって、
リソースが当該リソースの出生コンピュータによって制御されているかどうかを判定するために、前記リソース識別名に含まれる出生コンピュータに関する情報を使用して、前記リソースの出生コンピュータにメッセージを送信するステップと、
前記出生コンピュータからの返答をチェックするステップと、
前記リソースが前記出生コンピュータによって制御されていないと判定された場合に、前記リソースを制御しているコンピュータがいずれであるかを判定するために、前記クライアントに対応する論理ロケーション・サービス・プロセスにメッセージを送信するステップと、
前記クライアントに対応する論理ロケーション・サービス・プロセスからの返答をチェックするステップと、
前記クライアントに対応する前記論理ロケーション・サービス・プロセスが前記リソースを制御しているコンピュータの情報を有しないと判定された場合、前記リソース識別名に含まれる出生論理ロケーション・サービス・プロセスに関する情報を使用して、前記リソースの前記出生論理ロケーション・サービス・プロセスにメッセージを送信するステップを含む、方法。
【請求項１０】
前記クライアントに対応する前記論理ロケーション・サービス・プロセスが前記リソースのロケーションを知ったとき、前記出生論理ロケーション・サービス・プロセスからの前記返答を前記クライアントに対応する前記論理ロケーション・サービス・プロセスに記憶するステップとさらに含む、請求項９に記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本出願は、１９９６年１２月２０日に別個に出願された「Distributed Computing Using Logical Processes」と題する米国特許出願０８／７７２，６６３号に関連する。
本発明は、分散コンピュータ・ネットワークに関し、より具体的には、分散ネットワーク上でリソースを見つけるシステムおよび方法に関する。
【０００２】
【従来の技術】
今日の高度にネットワーク化されたコンピュータ環境では、分散コンピュータ処理がきわめて重要である。その理由は、分散コンピュータ処理は、比較的小さなコンピュータのリソースを合わせて、より強力な総合システムを提供することができるからである。分散コンピュータ処理は、データおよびプログラムを、ユーザに対して透過的なやり方で、異種類のコンピュータからなる巨大なネットワークに展開させる、すなわち分散させることができる。たとえば、一つのコンピュータに適合させるには大きすぎるデータを小さな断片に分割し、いくつかのコンピュータに格納することもできるし、多数のユーザにサービス提供するプロセスをネットワークに展開させて、エンドユーザに対し、より効率的にサービスを提供することもできる。
【０００３】
分散コンピュータ処理環境に関する融通性の必要のため、多数のロジスティック的問題が生じている。たとえば、そのようなネットワーク上のいずれか二つのコンピュータがネットワーク上で互いに通信することができるとき、通信費用は、関与するコンピュータおよび通信ネットワークの形態によって異なることがある。そのうえ、まったく易しいと思える動作（たとえば、ワールド・ワイド・ウェブ上でホームページを見つけるプロセス）が、環境が絶えず変化する状況（たとえば、ホームページが新たな物理的ロケーションに移動する）では、ロジスティック的に管理し難くなることがある。任意の分散環境においてリソースを見つけることに伴う問題は、特に関心の対象であり、本発明によって取り扱うものである。
【０００４】
典型的な分散コンピュータ処理環境は、クライアントと、リソース・コンピュータ（たとえばサーバ）と、リソースとを含む。リソースとは、コンピュータ・プロセスにとってその計算処理の一部として使用するのに利用可能な実体である。リソースは、物理的なもの（たとえばロボット・アーム）でもよいし、論理的なもの（たとえばデータベース）でもよい。リソースの他の例には、ＣＤ−ＲＯＭディスク、ネーム・サーバ・プロセス、オブジェクト指向プログラミング・オブジェクト、分散共用メモリ中のロケーションなどがある。
【０００５】
リソースは、ある別のリソースを‘含む'ならば、その含まれるリソースを所有することができる。リソースが別のリソースを含むとは、そのリソースに対して物理的操作を実行する（たとえば、それを破壊するなど）ことが、その別のリソースに対しても同じ操作を実行することになる場合である。たとえば、ファイルの総体を含む物理的ディスクが、そのディスク上のすべてのファイルを所有する、または、分散共用メモリの一領域が、そのメモリ領域に割り当てられたオブジェクト指向プログラミング・オブジェクトを所有する、などである。リソースが別のリソースを所有するためには、所有する側のリソースは、所有される側のリソースよりも抽象的であってはならない。たとえば、物理的リソース（たとえばコンピュータ）は、論理的リソース（たとえばネーム・サーバ・プロセス）を所有することができる。物理的リソース（たとえば、ディスク、ロボット・アームなど）は抽象的概念ではないため、それらが所有されることはない。
【０００６】
いかなる時点でも、分散コンピュータ処理環境中のコンピュータが各リソースを制御する。リソースを制御するコンピュータは、そのリソースが取り付けられているコンピュータであり、制御するコンピュータは、そのリソースに対する非局所的アクセスを媒介し、可能にする責任を負う。そのうえ、いかなる場合にも、リソースは制御される必要はない（たとえば、机の引き出しに入れたディスクの場合を考えてみる）。コンピュータが所与のリソースｒを管理するならば、そのコンピュータはまた、ｒによって所有されるすべてのリソースをも制御する。リソースは、そのリソースを初めに制御したコンピュータ上に生成される。
【０００７】
リソース・サーバとは、１個以上のリソースを制御し、分散コンピュータ処理環境中の他のコンピュータが、それが制御するリソースの空ではないサブセットにアクセスすることを可能にするコンピュータである。ここで重要なことは、リソース・サーバを介して他のコンピュータにアクセスすることが潜在的に可能になるリソースである。
【０００８】
移行とは、所与のリソースの所有者または制御者の持続的変化である。リソースの制御者は、それをあるコンピュータから切り離し、別のコンピュータに付け直す（たとえば、ディスケットをある機械のドライブから別の機械のドライブに物理的に移す）ことによって変更される。論理的リソースの所有者は、論理的リソースを破壊的に複写する（たとえば、分散共用メモリのある領域の補助記憶装置をあるデバイスから別のデバイスに移す）ことによって変更される。
【０００９】
上記のように、リソースを追跡し、見つけることは、移行が起こるような巨大な分散コンピュータ処理ネットワークにおいてはロジスティック的に困難になりうる。そのうえ、リソースが潜在的に移行することができる多数の場所を与えられると（ウェブを考えてみる）、リソースを見つけるのに伴う費用は、実施上、際限なく増すおそれがある。それにもかかわらず、分散システムにおいては、クライアントが、遠隔リソースを制御している機械をすばやく発見する必要がしばしばある。
【００１０】
リソースを見つける一つの方法は、リソース識別名（ＲＩＤ）を使用してリソースを識別することを含む。すなわち、各リソースが一意の識別名を有するならば、リソースのロケーションをＲＩＤの中にコード化することができる。しかし、融通性のある分散システムは、リソースを制御する機械を変更しなければならないときがあるため、移行を扱うシステムを用いなければならない。移行するおそれのあるリソースを発見するための以前の手法は、際限のない通信を要求する可能性、既存のＲＩＤを透過的に更新するための分散ゴミ収集をサポートする必要性、専用サーバを含める必要性またはリソースとそれを創造するサーバとの間に継続した接続を維持する必要性をはじめとする多数の欠点を抱えていた。
【００１１】
以下の各文書は何らかの形態のリソース追跡／発見を記載しているが、いずれも上述の問題のいくつかを抱えている。J. Chase、H. Levy、E. LazowskaおよびM. Baker-Harvey「Lightweight shared objects in a 64-bit operating system」OOPSLA 92: Conference on Object-Oriented Programming Systems, Languages and Applications, ACM/SIGPLAN 1992. p. 397、M. Day、B. Liskov、U. MaheshwariおよびA. Meyers「References to remote mobile objects in Thor.」ACM Letters on Programming Languages and Systems, 2(1-4), Mar.-Dec. 1993. p. 115、J. Ioannidis、D. DuchampおよびG. Maguire, Jr.「IP-based protocols for mobile internetworking」Technical Report CUCS-006-91, Department of Computer Science, Columbia University 1991ならびに「Universal Networked Objects」CORBA2.0/Interoperability, OMG TC Document 95.3.xx, March 20, 1995
【００１２】
【発明が解決しようとする課題】
分散コンピュータ処理環境は、インターネット、ワールド・ワイド・ウェブ、イントラネットおよび大企業ネットワークを含め、コンピュータ処理において支配的な役割を演じ続けるであろう。コンピュータ処理リソースの効率的な管理は、そのような環境がエンドユーザの必要性を満たすことを可能にする際に第一の課題となろう。したがって、リソースを追跡し、見つける効率的なシステムを提供する必要がある。なお、前記文献を引用例として本明細書に含める。
【００１３】
【課題を解決するための手段】
本発明は、分散コンピュータ処理環境においてリソースを管理する方法およびシステムを提供する。開示するものは、（１）リソース識別名（ＲＩＤ）を作成するためのシステムおよび手段、（２）コンピュータおよびリソースのロケーションに関する情報を管理するための分散プロセス構造ならびに（３）小さな限られた数のメッセージでＲＩＤからリソースを制御する機械へのマッピングを可能にするプロトコルのセットである。本明細書中、これらの機能的態様をまとめて「分散ロケーション・サービス」（ＤＬＳ）と呼ぶ。
【００１４】
本発明は、関連出願「Distributed Computing Using Logical Processes」に詳細に記載されている「論理プロセス」の概念を取り入れる。論理プロセスの開示は、とりわけ、リソース識別名を変更することなく、装置の物理アドレスを変更することを許す論理的なアドレス指定／マッピング手段を教示している。そのうえ、論理プロセスは、以下にさらに詳細に説明する、上述の分散プロセス構造またはＬＬＳＰを具現化するための融通性のある手段を提供する。本発明は、一般的な意味において開示するが、本発明が、ワールド・ワイド・ウェブ、インターネット、イントラネットなどをはじめとするいかなる分散コンピュータ処理環境にも応用できることが理解されよう。
【００１５】
上記にしたがって、本発明の利点は、移行するおそれのあるリソースを見つけるための高度にスケーラブルなシステムを提供することにある。
上記にしたがって、本発明のさらなる利点は、小さな限られた数のメッセージを提供してリソースの制御者を発見することにある。
上記にしたがって、本発明のさらなる利点は、創造する側のサーバとの接続を維持することなく、リソースの移行を考慮することにある。
上記にしたがって、本発明のさらなる利点は、ゴミ収集を要しないシステムを提供することにある。
上記にしたがって、本発明のさらなる利点は、局所リソースへのアクセスのためのオーバヘッドを要しないシステムを提供することにある。
上記にしたがって、本発明のさらなる利点は、最小限のメモリしか要しないシステムを提供することにある。
【００１６】
【発明の実施の形態】
Ａ．ＤＬＳ概要
１．ＬＬＳＰ
前記のとおり、本発明の根本的態様は、コンピュータおよびリソースのいくつかの管理態様を監督するための、本明細書では「論理ロケーション・サーバ・プロセス（ＬＬＳＰ）」と呼ぶ分散プロセス構造の使用である。本発明は、各物理プロセスが、論理プロセスで識別される、すなわち論理プロセスと対応しているものと仮定する。物理プロセスとは、実機械上で実行され、リソース（たとえばメモリ、ＣＰＵサイクルなど）を消費する従来のオペレーティング・システム・プロセスである。各論理プロセス（すなわちＬＬＳＰ）は、サーバの外観である抽象的概念である。ＬＬＳＰは、異なる時点で異なる機械上で実行される異なる数の物理プロセスによって具現化することができる。ＤＬＳは、ＬＬＳＰと、具現化される物理プロセスとの間に動的なマッピングを維持する。サーバとのすべての対話はＬＬＳＰを用いる。「Distributed Computing Using Logical Processes」と題する前記関連出願に記載のより低水準の機構は、論理プロセスと物理プロセスとの間にマッピングを維持するためのシステムを記載している。この関連の開示は、異なる時点で異なる物理的ロケーションに存在する必要があるかもしれないＬＬＳＰを管理するための融通性のある機構を提供している。説明するならば、クライアントは、物理アドレスを使用してプロセスを識別するのではなく、論理アドレスを使用して、ネットワーク上のリソースおよびコンピュータの動的分散に融通性を提供する。
【００１７】
ＤＬＳは、リソースのロケーションを知る‘責任'（以下さらに詳細に定義する）をＬＬＳＰの間で分割する。一般には、二つのＬＬＳＰが、各リソースのロケーションを追跡する‘責任'を分担し、一方は、リソースが創造されたところの近くで追跡し、もう一方は、現在リソースを制御している機械の近くで追跡する。さらには、クライアント（以下さらに詳細に定義する）に対応するＬＬＳＰもまた、何らかの記憶機構を介して、リソースのロケーションを知ることができる。リソースが移行するならば、その行き先に関し、（１）その出生コンピュータの近く、（２）そのリソースを使用するクライアント・コンピュータの近く、または（３）関連のない場所、という三つの可能性があることが確認されているため、ＤＬＳがこのように責任を分割する。コンピュータ・システム中のリソースの位置関係に関する経験から、最初の二つの選択肢が第三の選択肢よりもはるかに可能性が高いという結論に至る。それにもかかわらず、本発明によると、クライアントは、リソースを発見するのに、リソース識別名を有するだけでよい。リソースのロケーションが、そのリソースの出生コンピュータにも、具現態様によっては、クライアントのＬＬＳＰにもわからない場合、本来は、出生コンピュータのＬＬＳＰがリソースのロケーションを指し示す。リソースの出生コンピュータに関する情報は、そのＲＩＤの中にコード化されている。これは後でさらに詳細に論じる。
【００１８】
上記のとおり、論理ロケーション・サーバ・プロセス（ＬＬＳＰ）は、ＤＬＳサーバの外観である抽象的概念であり、ＤＬＳは、ＬＬＳＰと、そのＬＬＳＰを具現化する‘物理'プロセスとの間に動的なマッピングを維持する。いかなる時点でも、ＬＬＳＰは、多数の物理プロセスによって具現化することができる。たとえば、ＬＬＳＰにおける作業負荷が一つのプロセスが担うには大きすぎる場合、その作業を多数の物理プロセスに分担させることができる。あるいはまた、たとえば、ＬＬＳＰがあまり利用されていないならば、一つの物理プロセスが多数のＬＬＳＰを具現化することもできる。標準的な技術を使用して、ＬＬＳＰを具現化する物理プロセスを複写することにより、ＤＬＳの利用性を高めることができる。
【００１９】
物理プロセスとは違い、ＬＬＳＰは永久に存在する。したがって、すべてのＬＬＳＰのセットは単調に増大する。これは、ＬＬＳＰが抽象的概念であり、分散コンピュータ処理環境中の、その識別名以外の物理的リソースを直接には消費しないために可能である。各ＬＬＳＰは、すべてのＬＬＳＰのセットの中で普遍的に一意の識別名を有し、ＤＬＳサーバとのすべての通信はＬＬＳＰに送られる。論理−物理プロセス抽象的概念を具現化する機構がメッセージを適切な物理プロセスに送り直す。
【００２０】
以下、ＬＬＳＰに関連するいくつかの定義を記す。「コンピュータの現在のＬＬＳＰ」とは、コンピュータにもっとも近いＬＬＳＰ（すなわち、コンピュータに対応するＬＬＳＰ）をいう。直観的に、「もっとも近い」とは、コンピュータと、ＬＬＳＰを具現化する物理プロセスを所有することができるコンピュータとの間の通信の費用を捕らえるべきである。しかし、形式的には、管理者が、以下の制約、すなわち（１）コンピュータと現在のＬＬＳＰとの間のマッピングが多対一であり、（２）コンピュータの現在のＬＬＳＰが決して変わらない（この制約は、コンピュータが移動する場合について後で緩和されることに注意）という制約の下で、各コンピュータの現在のＬＬＳＰを指定する。したがって、距離と現在のＬＬＳＰの概念との間の関係を決定することは管理者次第である。
【００２１】
ある特定の場合における「リソースの現在のＬＬＳＰ」とは、その場合にリソースを制御しているコンピュータの現在のＬＬＳＰをいう。リソースの現在のＬＬＳＰの概念は、部分的分割を定義する。制御されるリソースだけが現在のＬＬＳＰを有し、いかなる時点でも、すべてのリソースが制御されるわけではない（たとえば、取り付けられていないディスクによって所有されているファイル）。
【００２２】
「コンピュータの出生ＬＬＳＰ」とは、コンピュータが最初に構成されたとき、そのコンピュータの現在のＬＬＳＰであったＬＬＳＰをいう。コンピュータを加えたり、取り外したりすることはできるが、移行させることはできないコンピュータ処理ネットワークの比較的静的な形態の下では、コンピュータの出生ＬＬＳＰと現在のＬＬＳＰとは常に同等である。コンピュータが移行する場合の扱いは、コンピュータ再構成に関して後で詳細に論じる。
【００２３】
リソースの「出生ＬＬＳＰ」とは、リソースが生成されたところのコンピュータの現在のＬＬＳＰをいう。注目すべきことに、（１）所与のコンピュータで生成されたすべてのリソースは同じ出生ＬＬＳＰを有し、（２）出生ＬＬＳＰへのリソースのマッピングがリソースの完全な分割を定義し、（３）リソースの出生ＬＬＳＰはそのリソースの生存期間中には決して変わらず、（４）リソースが移行したことがない場合、リソースの現在のＬＬＳＰと出生ＬＬＳＰとは同一である。
【００２４】
ＬＬＳＰは、リソースのＲＩＤからそのリソースを制御する（リソースが制御されていると仮定して）コンピュータへのマッピングを実行できることを保証されるならば、リソースの責任を負う。この責任は、出生ＬＬＳＰおよび現在のＬＬＳＰの概念を使用して、ＬＬＳＰの間で分担される。ＬＬＳＰは、それが出生ＬＬＳＰであるところのリソースに対して時不変性の責任を負う。ある特定の場合には、ＬＬＳＰは、それが現在のＬＬＳＰであるところのリソースに対して時変性の責任を負う。所与のリソースに対して時不変性の責任を負うＬＬＳＰは、リソースの生存期間中には決して変わらない。リソースに対して時変性の責任を負うＬＬＳＰは、特にリソースが移行した場合に変わるかもしれず、特にどのコンピュータもリソースを制御しない場合、どのＬＬＳＰもそのリソースに対して時変性の責任を負わないこともありうる。
【００２５】
出生ＬＬＳＰに基づく時不変性の責任を定義する（すなわち、ＬＬＳＰに近いコンピュータで生成されたすべてのリソースを追跡する）ことにより、出生ＬＬＳＰが知られている限り、いかなるリソースのロケーションをも常に確認することができる。出生ＬＬＳＰの識別は、ＲＩＤの中に出生ＬＬＳＰをコード化することによって達成される。このように、クライアントがＲＩＤからＬＬＳＰに容易にマッピングすることができるシステムが提供される。出生ＬＬＳＰに時不変性の責任を与える動機は、リソースは移行しないし、移行するとしても、可能性の高い行き先はそれらが生成されたところに近いという慣例的仮定から生じる。
【００２６】
移行するリソースを見つけるために、各ＬＬＳＰは、それが責任を負うリソースをデータ構造の中で追跡しなければならない。このためには、ＬＬＳＰは、現在ＬＬＳＰと対応しているリソースおよび以前にＬＬＳＰと対応していたリソースに関する情報を維持しなければならない。この情報の正確な性質および特徴は、具体的な具現態様に依存して異なる。詳細な例は後で提示する。
【００２７】
２．ＲＩＤ
すべてのリソースは、一意のリソース識別名（ＲＩＤ）を有する。ＲＩＤとリソースとの間には一対一のマッピングがある。ＲＩＤは、リソースを一意的に識別する値（たとえばバイトのシーケンス）である。変更することができる外的ラベルである名前とは違い、リソース識別名は、そのリソースと密に、かつ永久的に結合している。すべてのリソースは、リソースが生成されたときに割り当てられ、リソースが破壊されるまでリソースに結び付いたままであるＲＩＤを一つだけ有する。リソースがいずれかの時点で新たなＲＩＤを与えられるならば、新たなリソースが実際に生成され、旧リソースは実際に破壊される。複写されるリソースのすべてのレプリカは同じＲＩＤを有する。ＲＩＤは、生じたことがあるかもしれない移行にはかかわらず、オブジェクトを識別する。リソースは、その出生コンピュータによってそのＲＩＤを与えられる。
【００２８】
ＤＬＳは、ＲＩＤを、たとえば動的にタイプされたバイトのシーケンスとして構成するための拡張可能なアーキテクチャを定義する。システム中のすべてのＲＩＤは、この所定のアーキテクチャにしたがって構成されなければならない。各ＲＩＤに含まれる情報は、リソースの出生コンピュータ、コンピュータの出生ＬＬＳＰおよび出生コンピュータに生まれた各リソースを一意的に識別するための何らかの手段に関する情報を含むことができるが、これらに限定はされない。さらには、他の詳細（たとえば、他のフィールドの解釈方法を決めるバイトのシーケンス）を含めることもできる。上記のとおり、リソース識別名の構造は、ＲＩＤを割り当てる責任をリソースの出生コンピュータに委ねることを許す。したがって、ＲＩＤを割り当てるとき、ＤＬＳとの通信は不要である。
【００２９】
ＲＩＤのアーキテクチャによって暗示されるように、我々は、すべての物理的コンピュータが論理識別名を有するものと仮定する。コンピュータの論理識別名は、そのコンピュータ上で生成されたリソースのＲＩＤの一部であるため、ＲＩＤをこの識別名として使用することはできない。この論理識別名はコンピュータをずっと一意的に識別する。
【００３０】
各ＬＬＳＰが一意の識別名を外部的に与えられると仮定すると、コンピュータの出生ＬＬＳＰは、そのコンピュータに論理識別名を割り当てることができる。コンピュータを構成するとき、その識別名を求めてその出生ＬＬＳＰに接触する必要がある。ＬＬＳＰは、そのＬＬＳＰを出生ＬＬＳＰとして有するすべてのコンピュータの中で一意性を保証するような方法で（たとえば、ＬＬＳＰが新たなコンピュータに論理的ＩＤを割り当てるたびに単調にインクリメントされるカウンタを使用する）この識別名を構成すべきである。
【００３１】
３．プロトコル
本発明に必要とされるプロトコルまたはアルゴリズムが二つある。その一つは、リソースが移行すると実行され、もう一つは、クライアントが、所与のリソースのリソース・サーバを決定することを望むときに実行される。リソースが移行するときに用いられるプロトコルは、一般に、時変性のＬＬＳＰおよび時不変性のＬＬＳＰを更新することを含む。具体的には、出生ＬＬＳＰ、以前のＬＬＳＰおよび新たな（すなわち現在の）ＬＬＳＰのデータ構造を更新しなければならない。これは、図２を参照しながら後でさらに詳細に論じる。
【００３２】
注目すべきは、各ＬＬＳＰが、それが責任を負うところの移行したリソースを追跡するということである。リソースが一度も移行したことがないならば、いかなるＬＬＳＰ中にも、そのリソースに関するデータはない。ＤＬＳは、リソースが移行したときだけ知らされる。移行したことがないリソースに関しては、それらのリソース・サーバがそれらの出生コンピュータとして残る。したがって、ＤＬＳは、それ自体が情報を有しないＲＩＤを与えられると、そのリソースが、ＲＩＤの中にコード化されている出生コンピュータによって制御されるとみなす。
【００３３】
リソースを見つけるためのプロトコルを開始する前に、クライアントは、ＲＩＤをその構成部分に分割する。クライアントがリソースの出生コンピュータの論理識別名（ＲＩＤから取り出したもの）から同じコンピュータ上のリソース・サーバにマッピングするのに使用することができる別個の機構が存在すると仮定される。リソースを発見するのに好ましいプロトコル（少なくとも移行がめずらしい場合）は、一般に、まず、出生コンピュータを見て、それがリソースを制御しているかどうかを調べることからなる。うまくいかなければ、次に、クライアントの現在のＬＬＳＰを見て、それがリソースのロケーションまたは制御者を知っているかどうかを調べる。それでもうまくいかないならば、現在のＬＬＳＰが、出生コンピュータのＬＬＳＰに対し、だれがリソースを制御しているかを問う。この最後の段階が実行されるならば、システムはその返答をクライアントの現在のＬＬＳＰに記憶すべきである。
【００３４】
クライアントの現在のＬＬＳＰは、以下の理由のいずれかにより、リソースの現在の制御者を知っているかもしれない。まず、そのＬＬＳＰは、時不変性の責任を負うＬＬＳＰであるかもしれない。リソースは移行する傾向を示さず、それらが位置するところの近くで使用される傾向にあるため、これは当然あり得ることである。第二に、そのＬＬＳＰは、時変性の責任を負うＬＬＳＰであるかもしれない。リソースが、それらが使用されるところの近くに移行するという仮定の下では、これは当然あり得ることである。最後に、クライアントの現在のＬＬＳＰがリソースのロケーションをキャッシュに記憶してあるかもしれない。
【００３５】
したがって、リソースの制御者を発見するのに要するメッセージは、クライアントからその現在のＬＬＳＰに送られるメッセージと、クライアントの現在のＬＬＳＰから時不変性のＬＬＳＰに送られるメッセージとに限られる。この結果、リソースの制御者を発見するのに、二往復のメッセージだけで済む。大部分のアクセスが、移行したことのないリソースに対するものであるとしても、リソースの出生コンピュータに送られるメッセージが平均性能を高める。
【００３６】
Ｂ．詳細な説明
ここで図面を参照すると、図１は、分散ロケーション・サービス（ＤＬＳ）１４を含むネットワーキング・ステーション１０を表す。典型的な分散ネットワークは、複数のクライアントと、複数のリソース・コンピュータまたはサーバと、リソース・コンピュータによって制御される複数のリソースとを含む。図１の分散ネットワーク１２には、クライアント２０と、１対のリソース・コンピュータ２４と、多数のリソース２６とを備えたシステムの一部が示されている。加えて、各クライアント、リソース・コンピュータおよびリソースが論理ロケーション・サーバ・プロセス（ＬＬＳＰ）と対応していることが見てとれる。上記のとおり、ＬＬＳＰは、異なる時点に異なる機械上で実行される異なる数の物理プロセスによって具現化することができる抽象的概念である。ＤＬＳは、ＬＬＳＰと、具現化する物理プロセスとの間に動的なマッピングを維持する。この場合、二つのＬＬＳＰ１６および１８が示されている。第一のＬＬＳＰ１６はクライアントに対応し、一方、第二のＬＬＳＰはリソース・コンピュータ２４およびリソース２６に対応している。
【００３７】
各ＬＬＳＰは、それが責任を負うリソースを追跡するためのデータ構造２２をその中に含む。この好ましい実施態様では、各ＬＬＳＰは、このＬＬＳＰをそれらの出生ＬＬＳＰとして有するリソースのセットを含むデータ構造を維持しなければならない。このＬＬＳＰで生まれた各リソースについて、データ構造は、現在のＬＬＳＰの名前と、所有する側のリソースがあるならばその名前と、所有される側のリソースがあるならばその名前とを維持しなければならない。加えて、ＬＬＳＰデータ構造はまた、このＬＬＳＰをそれらの現在のＬＬＳＰとして有するコンピュータのセットを含まなければならない。これらのコンピュータそれぞれについて、データ構造は、そのコンピュータによって制御されるリソースのセットを含まなければならない。リソースごとに、データ構造は、各リソースの出生ＬＬＳＰと、所有する側のリソースがあるならばその出生ＬＬＳＰと、所有される側のリソースがあるならばその出生ＬＬＳＰとを含まなければならない。このデータの他にも、特定の具現態様では、各ＬＬＳＰは、さらなるデータを含むかもしれない（たとえば、ドメイン固有の知識を利用するため）。
【００３８】
加えて、この分散ネットワーク・システム１０中の各リソースがリソース識別名（ＲＩＤ）を含むことが見てとれる。上記のとおり、各リソースは、そのリソースを一意的に識別するリソース識別名を有している。ＲＩＤのアーキテクチャは、図３および４を参照しながら後でさらに詳細に論じる。
【００３９】
認識しておくべきは、ＤＬＳ１４は、ネットワーク上のどこかに存在する一つのサーバ・プロセスではなく、それどころか、ＬＬＳＰの形態でネットワークに分散したサーバのセットである。ＤＬＳは三つの基本機能を提供する。第一に、ＲＩＤからコンピュータの制御側リソース・サーバにマッピングするディレクトリを維持する。第二に、新たなリソース識別名またはＲＩＤを構成するためのアーキテクチャを提供する。最後に、リソースが移行したときにサーバを更新し、ＲＩＤからリソースを発見するためのプロトコルのセットを提供する。これらの機能のすべては、必要に応じてネットワーク内で記録、格納または実行される一つ以上のソフトウェア・プログラムとして存在することができる。そのうえ、専用のＤＬＳサーバを初めに使用して、必要なすべてのソフトウェアを投入し、その後で、必要に応じて種々の機能的態様をネットワークの他の部分に移してもよい。
【００４０】
次に図２を参照すると、分散ネットワークシステム３０における分散ロケーション・サービス３２の動作がより詳細に示されている。ここでは、ネットワーク・システム３０が、クライアント３４と、リソース・コンピュータ４０と、リソース・コンピュータ４６と、リソース４８とを含むことが見てとれる。この場合、リソース４８をリソースＸと呼ぶ。加えて、図２には三つのＬＬＳＰが示されている。第一のＬＬＳＰ３６は、クライアント３４の現在のＬＬＳＰである。第二のＬＬＳＰは、リソースＸの出生ＬＬＳＰである。第三のＬＬＳＰ５０は、リソースＸの現在のＬＬＳＰである。この仮定的な状況では、リソースＸは、初めに出生コンピュータ４０の下で生成された後、経路４４に沿ってその現在の制御側コンピュータ４６に移行したものである。したがって、リソースＸは、出生ＬＬＳＰ４２と、出生コンピュータ４０と、現在のＬＬＳＰ５０と、現在の制御側コンピュータ４６とを有している。図１に関して記したように、ＬＬＳＰ４２および５０はいずれも、リソースＸの現在のロケーションに関する情報をそれぞれのデータ構造に含むはずである。リソースＸについて、出生ＬＬＳＰ４２は時不変性の責任を負っているであろうが、現在のＬＬＳＰ５０は時変性の責任を負っているであろう。リソースＸが今後に新たなＬＬＳＰに移行するならば、ＬＬＳＰ５０は、リソースＸを維持または追跡する責任をもはや負わないであろう。しかし、出生ＬＬＳＰ４２は、リソースＸのロケーションに関する情報を常に維持しなければならない。
【００４１】
動作中、クライアント３４が分散ネットワーク３０上でリソースＸを見つけたいならば、クライアントは以下のプロトコルを使用することになる。まず、クライアント３４は、リソース出生システム上のリソース・サーバにメッセージを送って、そのリソース・サーバがリソースを制御しているかどうかを問う。この場合、クライアント３４は、出生コンピュータ４０にメッセージを送って、出生コンピュータ４０が今でもリソースＸを制御しているかどうかを調べる。今でも制御しているという返答が得られるならば、プロトコルは完了し、そのリソースは見つかる。注目すべきは、これら初めの二つのステップは機能の正しさにとって必ずしも不可欠ではないということである。しかし、これらは、移行がありそうにないという仮定を与えられる典型的な場合に性能を提供し、改善するためのものである。リソース・サーバが返答しないか、否定的な返答を示すならば、メッセージをクライアントの現在のＬＬＳＰ３６に送って、どの機械が現在リソースを制御しているかを問う。クライアントの現在のＬＬＳＰがリソース制御者を知っているならば、そのＬＬＳＰがその情報をクライアントに提供して、リソースの探索を終わらせるはずである。クライアントの現在のＬＬＳＰがリソースの制御者を知らないならば、そのＬＬＳＰは、ＲＩＤにコード化されている時不変性のＬＬＳＰ（すなわちリソースの出生ＬＬＳＰ）にメッセージを送って、だれがリソースを制御しているかを問う。上記のように、各ＬＬＳＰデータ構造は、そのＬＬＳＰで生まれたすべてのリソースの追跡記録を維持する。この時不変性のＬＬＳＰがクライアントの現在のＬＬＳＰに返答してリソースのロケーションを提供すると、クライアントの現在のＬＬＳＰは、その返答を記憶したのち、それをクライアントに転送する。したがって、次にこのリソースについて探索が始まったとき、クライアントのＬＬＳＰはその情報を有することができる。
【００４２】
リソースが一つのＬＬＳＰから別のＬＬＳＰに移行するとき、ＤＬＳは、以下のプロトコルを実行して、必要な情報をすべての該当するＬＬＳＰデータ構造に維持しなければならない。まず、ＤＬＳは、リソースの時不変性のＬＬＳＰ（ＲＩＤから決定される）に対し、新たなリソース・コンピュータがリソースを制御していることを知らせなければならない。次に、新たなリソース・コンピュータ（たとえばコンピュータ４６）の新たな、または現在のＬＬＳＰに対し、そのリソース・コンピュータが今やリソースを制御していることを知らせなければならない。すると、リソースの現在のＬＬＳＰは、リソースに対して時変性の責任を負うようになる。最後に、ＤＬＳは、以前にリソースを制御していたリソース・コンピュータの旧ＬＬＳＰに対し、そのリソース・コンピュータがもはやリソースを制御していないことを知らせなければならない。すると、リソース・コンピュータの旧ＬＬＳＰは、そのリソースについて時変性の責任を負うことを止める。認識すべきことは、システムが、通知される三つのＬＬＳＰが別個のものではない可能性が高いと推測することである。具現態様は、このことを調べ、全く同一のメッセージを送ることを避けなければならないであろう。
【００４３】
Ｃ．コンピュータ再構成
最後に、コンピュータ再構成の場合を考えてみる。ここまで説明したように、ＤＬＳは、コンピュータ・ネットワークの物理的構成によって意味的に実現されるのではない。コンピュータの物理的ロケーションにかかわらず、コンピュータの現在のＬＬＳＰがその出生ＬＬＳＰとして残る。しかし、コンピュータがその出生ＬＬＳＰから‘遠く'にまで移動するならば、これは性能の低下につながるおそれがある。
【００４４】
考慮すべき二つのケースがある。第一のケースは、小さなクライアント・コンピュータがそのユーザとともにしばしば短距離（たとえば仕事場から家）、またときには長距離を移動する、通常は可動性コンピュータ処理と考えられているものである。第二のケースは、非携帯式のコンピュータをある場所から別の場所に動かす場合である。この移動は、頻繁ではない可能性が高いが、分散コンピュータ処理環境の再構成および管理を可能にするためには重大である。
【００４５】
これら二つのケースを扱うため、我々は、コンピュータの現在のＬＬＳＰの定義を「ある特定の時点でコンピュータに‘近い'ＬＬＳＰ」と変更する。コンピュータの現在のＬＬＳＰは、コンピュータがネットワークと切断し、その後、ネットワークと再び接続するたびに変わることができる。我々の最初の定義と同様、「近い」とは、管理者の目から見た場合である。形式的には、コンピュータと現在のＬＬＳＰとのマッピングが多対一である場合、管理者が各コンピュータの現在のＬＬＳＰを指定する。
【００４６】
コンピュータの現在のＬＬＳＰがもはやその出生ＬＬＳＰに等しくなくてもよいことが理解されよう。移動した後には新たな現在のＬＬＳＰが割り当てられるため、リソース・ロケーション・プロトコルの中で接触されるクライアントに対応するコンピュータまたはＬＬＳＰは、特定の場合にクライアントに近いＬＬＳＰになり、その出生ＬＬＳＰにはならない。
【００４７】
ここまで定義したように、上記の変更は、クライアント・コンピュータが移動するときの性能の劣化を防ぐが、リソース・サーバが移動するならば、このシステムはなおも性能の劣化を被る。これに対処するため、リソース・サーバであるコンピュータが、その現在のＬＬＳＰが変わるよう、そのネットワーク接続機構を変更すると、リソース・サーバはさらなる論理識別名を割り当てられる。この論理識別名は、その新たな現在のＬＬＳＰと、ＬＬＳＰによって割り当てられた新たな一意の識別名とからなる。リソース・サーバは、将来のＲＩＤを割り当てる際にその新たな識別名を使用する。図４がこの構造の一つの可能な例を示す。
【００４８】
Ｄ．具体的な用途
１．ＳＡＳ／ＤＰＳ
ＤＬＳは、共用アドレス空間サービス／分散持続性記憶サービス（ＳＡＳ／ＤＰＳ）のロケーション・サーバとして機能することが想定される。ＳＡＳ／ＤＰＳは、ＤＬＳの観点から、持続性の分散共用メモリを具現化する。ＤＬＳの役割は、１３バイトＤＰＳアドレスをページに与えられる分散共用持続性メモリのページを制御しているコンピュータを発見することである。この場合、ＲＩＤが１３バイト・アドレスであり、リソースがページである。ＳＡＳ／ＤＰＳを持続性にするため、持続性媒体（たとえばディスク）が、ＳＡＳ／ＤＰＳ記憶の各ページを所有する。上述のＤＬＳアルゴリズムへの追加が、ページのセットをユニットとして扱うことを許す。
【００４９】
ＳＡＳ／ＤＰＳの一部として使用されるとき、ＤＬＳは、分散持続性記憶中に位置決めページのカバーの下で呼ばれる。ＤＰＳは、異なる機械のタスクが、ＳＡＳによって具現化される互いの機械有効範囲の持続性単一レベル記憶にアクセスすることを許す。ＳＡＳ／ＤＡＳを使用する機械がページ不在を示す時、ページ不在ハンドラが、そのページが障害中の機械によって制御されているかどうかを決定する。障害中の機械によって制御されているのではないならば、ページ不在ハンドラは、ＤＬＳに接触して、どの機械がページを制御しているかを決定する。ＤＬＳによって識別される制御側機械が障害中の機械によって連絡され、不在ページが記憶される。
【００５０】
ＳＡＳ／ＤＰＳで使用されるように、ＤＬＳの基本アーキテクチャは、ＲＩＤの最後のフィールドを設計することによって拡張される。コンピュータで生まれたリソースの正体を随意の一意値として扱う（図３に示す）代わりに、我々は、ＲＩＤの第四のフィールドを、それが二つのサブフィールドを有するように設計する。図４は、第四のフィールドがセグメント接頭語とセグメント内オフセットとに分割されていることを示す。ＲＩＤがセグメント・オフセットの値においてだけ異なるＳＡＳ／ＤＰＳページのセットは、ＤＬＳにより、グループとして移動すると仮定される。
【００５１】
２．ワールド・ワイド・ウェブ
ワールド・ワイド・ウェブとは、全世界的ハイパーテキスト・ドキュメントを提供するための機構である。ドキュメントは、実際にはドキュメントに対するポインタである統一リソース名（ＵＲＬ）を使用してリンクされる。現在、ＵＲＬの構造は、ドキュメントが容易に移行することができないような構造である。ＵＲＬは、リソースを制御している機械の記号名をコード化する。リソースの制御者が変わるならば、存在するＵＲＬは無効になる。
【００５２】
リソースの制御者の記号名をコード化するＵＲＬを使用する代わりに、上述したように、ＤＬＳおよびＲＩＤを使用することも考えられる。ＲＩＤは本質的にＵＲＬになる。これは、リソースへの既存のリンクを無効にすることなく、リソースの制御者を変更することを許す。現在、ＵＲＬの代わりに統一リソース名（ＵＲＮ）を用いる試みが成されている。現在、提案書および他の「インターネット草案」が存在する（たとえば、引用例として本明細書に含めるRFC 1737, K. Sollins, L. Masinter「Functional Requirements For Uniform Resource Names」12/20/94を参照すること）。
【００５３】
本明細書に述べた実施態様および実施例は、本発明およびその実際の用途を最良に説明し、それにより、当業者が本発明を構成し、使用することができるように提示したものである。しかし、当業者であれば、前記説明および実施例が例示のために示されたものにすぎないということを認識するであろう。前記説明は、すべてを網羅するものでもなく、本発明を開示したとおりの形態に限定しようとするものでもない。上記の教示を考慮すると、請求の範囲の趣旨および範囲を逸することなく、数多くの変更および変形が可能である。
【００５４】
まとめとして、本発明の構成に関して以下の事項を開示する。
（１）複数の論理サーバ・プロセスと、
前記論理サーバ・プロセスのうち、対応する一つを有するクライアント・コンピュータと、
それぞれが、前記論理サーバ・プロセスのうち、それに対応する一つを有する複数のリソース・コンピュータと、
それぞれが前記リソース・コンピュータによって制御される複数のリソースと、
それぞれが、前記リソースの一つを一対一方式で識別し、それぞれが、前記リソースが生成されたところのリソース・コンピュータに対応する論理サーバ・プロセスの論理アドレスを含む複数のリソース識別名と、
を含むことを特徴とする、リソースを見つけるためのシステムを含む分散ネットワーク。
（２）前記論理サーバ・プロセスそれぞれが、その特定の論理サーバ・プロセスに対応するリソース・コンピュータ上で生成されたものとして識別されるすべてのリソースのデータベースを含む上記（１）記載の分散ネットワーク。
（３）前記データベース中の各リソースについて現在の論理サーバ・プロセスのアドレスが提供されている上記（２）記載の分散ネットワーク。
（４）前記データベース中の各リソースについて所有する側のリソースが提供されている上記（２）記載の分散ネットワーク。
（５）前記データベース中の各リソースについて所有される側のリソースが提供されている上記（２）記載の分散ネットワーク。
（６）前記論理サーバ・プロセスそれぞれが、その特定の論理サーバ・プロセスに対応するすべてのリソース・コンピュータおよびそれらの制御されるリソースのデータベースを含む上記（１）記載の分散ネットワーク。
（７）前記制御される各リソースについて、前記データベースが、そのリソースが生成されたところのリソース・コンピュータに対応する論理サーバ・プロセスのアドレスをさらに含む上記（６）記載の論理サーバ・プロセス。
（８）前記制御される各リソースについて、前記データベースが、所有する側のリソースおよび所有される側のリソースに関する情報を含む上記（６）記載の論理サーバ・プロセス。
（９）記録可能媒体と、
前記記録可能媒体に記録されたリソース管理システムと、
を含み、前記リソース管理システムが、少なくとも一つのクライアントと、複数のリソース・コンピュータと、前記リソース・コンピュータによって制御される複数のリソースとを有する分散ネットワーク上で使用するためのものであり、前記リソース管理システムが、前記複数のリソースそれぞれを一意的に識別するリソース識別名を生成するための機構を含み、前記リソース識別名それぞれが、
前記リソースに対応する出生ＬＬＳＰを識別するためのＬＬＳＰフィールドと、
前記リソースに対応する出生コンピュータを識別するための出生コンピュータ・フィールドと、
前記出生コンピュータで生成されたすべてのリソースのセットの中から前記リソースを識別するためのＩＤフィールドと、
を含むことを特徴とするプログラム製品。
（１０）前記リソース識別名それぞれがタイプ・フィールドをさらに含み、前記タイプフィールドが、前記ＬＬＳＰフィールド、前記出生コンピュータ・フィールドおよび前記ＩＤフィールドを解釈するためのものである上記（９）記載のプログラム製品。
（１１）前記ＬＬＳＰフィールドと前記出生コンピュータ・フィールドとがいっしょになって前記出生コンピュータの論理識別名を生成する上記（９）記載のプログラム製品。
（１２）前記出生コンピュータ・フィールドと前記ＩＤフィールドとがいっしょになって、共通の出生ＬＬＳＰを共用する各リソースを一意的に識別するための識別名を生成する上記（９）記載のプログラム製品。
（１３）前記リソース・コンピュータそれぞれが、前記リソース・コンピュータの出生ＬＬＳＰの正体を含む論理識別名と、同じ出生ＬＬＳＰをもつすべてのリソース・コンピュータのセットの中から前記リソース・コンピュータを一意的に識別する値とを割り当てられる上記（９）記載のプログラム製品。
（１４）少なくとも一つのクライアントと、
複数のリソース・コンピュータと、
前記リソース・コンピュータによって制御される複数のリソースと、
それぞれが前記リソースの一つを一意的に識別する複数のリソース識別名と、
分散ロケーション・サービス・システムと、
を含み、前記分散ロケーション・サービス・システムが、
（ａ）すべてのリソースおよびリソース・コンピュータの分散ディレクトリを含む複数の分散サーバ・プロセスと、
（ｂ）新たなリソースが生成されるたびにリソース識別名を生成し、割り当てるためのリソース識別名生成機構と、
（ｃ）前記リソースの一つが移行したとき、該当する論理ロケーション・サーバ・プロセスを更新するための更新機構と、
（ｄ）前記分散ディレクトリを審査して、リソース識別名からリソース・コンピュータを見つけるロケーション機構と、
を含むことを特徴とする分散ネットワーク。
（１５）前記複数の分散サーバ・プロセスそれぞれが論理アドレスのセットおよび物理アドレスのセットを含み、前記分散ロケーション・サービス・システムがこれら２タイプのアドレスの間でマッピングを維持する上記（１４）記載の分散ネットワーク。
（１６）前記分散サーバ・プロセスそれぞれが、その分散サーバ・プロセスの下で生成されたすべてのリソースのデータベースと、現在その分散プロセスの中で制御されているすべてのリソースのデータベースとを含む上記（１４）記載の分散ネットワーク。
（１７）前記更新機構が、
前記移行するリソースの前記出生コンピュータに対応する分散サーバ・プロセス中のデータベースを修正して、新たな制御側コンピュータを示すための第一の機構と、
前記移行するリソースの責任を以前に負っていた分散サーバ・プロセス中のデータベースを修正して、前記移行するリソースが移動したことを示すための第二の機構と、
前記移行するリソースの責任を現在負っている分散サーバ・プロセス中のデータベースを修正するための第三の機構と、
を含む上記（１６）記載の分散ネットワーク。
（１８）前記ロケーション機構が、
前記リソースの出生リソース・コンピュータが現在そのリソースを制御しているかどうかを検出するための第一の機構と、
前記クライアントに対応する前記分散サーバ・プロセスが、どのリソース・コンピュータが現在そのリソースを制御しているかを知っているかどうかを検出するための第二の機構と、
前記リソースの出生リソース・コンピュータに対応する前記分散サーバ・プロセスに対し、どのリソース・コンピュータが現在そのリソースを制御しているかを要求するための第三の機構と、
を含む上記（１６）記載の分散ネットワーク。
（１９）前記ロケーション機構が、前記第三の機構から返された結果を記憶するための第四の機構をさらに含む上記（１８）記載の分散ネットワーク。
（２０）リソースが、それに対応する一意のリソース識別名を有し、クライアントが前記リソース識別名を知っており、各リソース、コンピュータおよびクライアントが、それに対応する一意の現在の論理ロケーション・サービス・プロセスを有し、前記リソース識別名が、前記リソースの出生コンピュータおよび出生論理ロケーション・サービス・プロセスに関する情報を含むところの、分散ネットワーク上のリソースをクライアントから見つけるための方法であって、
前記リソースの前記出生コンピュータにメッセージを送って、前記リソースが前記出生コンピュータによって制御されているかどうかを決定するステップと、
前記出生コンピュータからの返答をチェックするステップと、
前記リソースが前記出生コンピュータによって制御されていない場合、前記クライアントに対応する前記論理ロケーション・サービス・プロセスにメッセージを送って、だれが前記リソースを制御しているかをそれが知っているかどうかを決定するステップと、
前記クライアントに対応する前記論理ロケーション・サービス・プロセスからの返答をチェックするステップと、
前記クライアントに対応する前記論理ロケーション・サービス・プロセスが、前記リソースを制御しているコンピュータの実体を知らない場合、前記リソースの前記出生論理ロケーション・サービス・プロセスにメッセージを送って、だれが前記リソースを制御しているかを決定するステップと、
を含むことを特徴とする方法。
（２１）前記クライアントに対応する前記論理ロケーション・サービス・プロセスが前記リソースのロケーションを知っているとき、前記クライアントに対応する前記論理ロケーション・サービス・プロセスからの前記返答を記憶するステップをさらに含む上記（２０）記載の方法。
（２２）複数の論理ロケーション・サービス・プロセスと、
それぞれが、前記論理ロケーション・サービス・プロセスのうち、それに対応する一つを有する複数のクライアントと、
それぞれが、前記論理ロケーション・サービス・プロセスのうち、それに対応する一つを有する複数のリソース・コンピュータと、
それぞれが前記リソース・コンピュータの一つによって制御される複数のリソースと、
それぞれが、前記リソースの一つを一意的に識別し、それぞれが、前記リソースが生成されたところのリソース・コンピュータの正体と、前記リソースが生成されたところのリソース・コンピュータに対応する論理ロケーション・サービス・プロセスとを含む複数のリソース識別名と、
を含むことを特徴とする、統一リソース識別システムを有するインターネット。
（２３）前記リソース識別名それぞれが統一リソース名の一部として含まれる上記（２２）記載のインターネット。
（２４）前記論理ロケーション・サービス・プロセスそれぞれが、この論理ロケーション・サービス・プロセスを出生論理ロケーション・サービス・プロセスとして識別するすべてのリソースをリストするデータベースを含む上記（２２）記載のインターネット。
（２５）前記論理ロケーション・サービス・プロセスそれぞれが、この論理ロケーション・サービス・プロセスを現在の論理ロケーション・サービス・プロセスとして識別するすべてのリソース・コンピュータをリストするデータベースを含む上記（２２）記載のインターネット。
（２６）ワールド・ワイド・ウェブとして使用される上記（２２）記載のインターネット。
（２７）リソースが、それに対応する一意のリソース識別名を有し、クライアントが前記リソース識別名を知っており、ネットワークに対応する各リソース、コンピュータおよびクライアントが、それに対応する一意の現在の論理ロケーション・サービス・プロセスを有し、前記リソース識別名が、前記リソースの出生コンピュータおよび出生論理ロケーション・サービス・プロセスに関する情報を含むところの、ワールド・ワイド・ウェブのネットワーク上のリソースをクライアントから発見するための方法であって、
前記リソースの前記出生コンピュータにメッセージを送って、前記リソースが前記出生コンピュータによって制御されているかどうかを決定するステップと、
前記出生コンピュータからの返答をチェックするステップと、
前記リソースが前記出生コンピュータによって制御されていない場合、前記クライアントに対応する前記論理ロケーション・サービス・プロセスにメッセージを送って、だれが前記リソースを制御しているかをそれが知っているかどうかを決定するステップと、
前記クライアントに対応する前記論理ロケーション・サービス・プロセスからの返答をチェックするステップと、
前記クライアントに対応する前記論理ロケーション・サービス・プロセスが、前記リソースを制御しているコンピュータの実体を知らない場合、前記リソースの前記出生論理ロケーション・サービス・プロセスにメッセージを送って、だれが前記リソースを制御しているかを決定するステップと、
を含むことを特徴とする方法。
（２８）前記クライアントに対応する前記論理ロケーション・サービス・プロセスが前記リソースのロケーションを知っているとき、前記クライアントに対応する前記論理ロケーション・サービス・プロセスからの前記返答を記憶するステップをさらに含む上記（２７）記載の方法。
（２９）記録可能媒体と、
クライアントおよびサーバから構成されるネットワーク中でリソースを管理し、見つけるための、前記記録可能媒体に記録された分散ロケーション・サービス・プロセスと、
を含み、前記分散ロケーション・サービス・プロセスが、
リソースを追跡するための、分散サーバ・プロセスを創造するための第一の機構と、
リソース識別名を生成し、割り当てるための第二の機構と、
リソースが移行したとき、前記分散サーバ・プロセスを更新するための第三の機構と、
を含むことを特徴とするプログラム製品。
（３０）前記分散ロケーション・サービス・プロセスが、リソースを見つけるための第四の機構をさらに含む上記（２９）記載のプログラム製品。
（３１）インターネット上でリソースを見つけるためのプログラム製品において、
記録可能媒体と、
前記記録可能媒体に記録された分散ロケーション・システムと、
を含み、前記分散ロケーション・システムが、前記インターネット上のサーバの論理ロケーション・サーバ・プロセスを創造するための機構と、前記インターネット上のリソースにリソース識別名を割り当てるための機構と、リソースが移行したとき、前記論理ロケーション・サーバ・プロセスを更新するための機構とを含むことを特徴とする製品。
（３２）前記リソースを見つけるための機構をさらに含む上記（３１）記載のプログラム製品。
（３３）前記インターネットがワールド・ワイド・ウェブである上記（３１）記載のプログラム製品。
（３４）前記リソースがウェブ・ページである上記（３３）記載のプログラム製品。
（３５）前記リソースを見つけるための機構がウェブ・ブラウザによってアクセスされる上記（３１）記載のプログラム製品。
【図面の簡単な説明】
【図１】  本発明の好ましい実施態様による分散ロケーション・サービスを含む分散ネットワーク・システムのブロック図である。
【図２】  本発明の好ましい実施態様による分散ロケーション・サービスにおけるサーバ・プロセスをさらに定義する分散ネットワーク・システムのブロック図である。
【図３】  本発明の好ましい実施態様によるリソース識別名のアーキテクチャを示す図である。
【図４】  本発明によるリソース識別名の代替態様を示す図である。
【符号の説明】
１０  分散ネットワーク・システム
１２  分散ネットワーク
１４  分散ロケーション・サービス（ＤＬＳ）
１６、１８  論理ロケーション・サーバ・プロセス（ＬＬＳＰ）
２０  クライアント
２２  データ構造
２４  リソース・コンピュータ
２６  リソース
【図１】
0003777032.tif 000002
【図２】
0003777032.tif 000003
【図３】
0003777032.tif 000004
【図４】
0003777032.tif 000005