JP3899076B2

JP3899076B2 - 一時的ネットワーク

Info

Publication number: JP3899076B2
Application number: JP2003581458A
Authority: JP
Inventors: ウェズリー、アジャム; バーベック、ステフェン
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2002-03-27
Filing date: 2003-02-14
Publication date: 2007-03-28
Anticipated expiration: 2023-02-14
Also published as: CN100539602C; AU2003258902A1; TW200307440A; EP1491026B1; EP1491026A1; JP2005522103A; CN1643880A; TWI243569B; KR100656222B1; KR20040091675A; ATE524914T1; WO2003084186A1

Description

本発明は、コンピュータ・ネットワークに関し、より詳細には一時的ネットワーク環境で使用される方法、システム、およびコンピュータ・プログラム製品に関する。

ピアツーピア・ネットワークまたは「Ｐ２Ｐ」ネットワークでは、各通信ノードがネットワーク・プログラムを有しており、それによって各ノードはネットワーク・プログラムを有する他のノードと通信を始めることができる。ネットワークが非集中型であるので、各ノードは「ピア（peer）」とみなされ、各ノードは（Ｐ２Ｐ交換方式のための）同一の機能を有する。Ｐ２Ｐネットワークは、中央演算処理装置（「ＣＰＵ」）サイクル、メモリ、ストレージ・デバイスなどのリソースの浪費が避けられる、より効率的なネットワークとして期待されている。こうしたネットワークは、各ノードが自由にネットワークに参加し離脱できるという意味でアド・ホック（adhoc）である。したがって、Ｐ２Ｐネットワークは、「一時的な（transient）」ネットワークと特徴づけることができる。

従来技術のＰ２Ｐネットワーク・プログラムは、動的クエリーおよびピア発見の機能を提供する。しかし、既存の技術にはいくつかの欠点がある。永続的なネットワーク・アドレスがないことが、そのような欠点の１つである。動的アドレッシング方式で各ノードにネットワーク・アドレスが割り当てられるので、個々のノードは、Ｐ２Ｐネットワークに参加するたびに、通常異なるインターネット・プロトコル（「ＩＰ」）アドレスを有することになる（ダイアルアップ・アカウントを有するユーザは、ログインのたびに異なるＩＰアドレスを持つ。ある種のデジタル加入者線（digital subscriber line）すなわち「ＤＳＬ」など、一部の「常時接続」アカウントを有するユーザも、ログインの度に異なるＩＰアドレスを持つことがある）。このように永続的なアドレスがないために、各ノードは、どこで特定のサービスまたはコンテンツ・リソースが使用可能かを「記憶しておく（remember）」ことが困難になる。したがって、ノードがコンテンツまたはある種のサービスを必要とするときには、通常新たな発見要求を発行する必要があり、その上多数の応答の中からどのように選択するのかを決定しなければならないこともある。この通信は、膨大なトラフィックを発生することになる。

既存のＰ２Ｐネットワークのもう１つの欠点は、信頼モデル（trust model）がないこと、すなわちノードに永続的なネットワーク・アドレスがないので、どのノードが信頼でき、どのノードが信頼できないかを永続的に追跡する既存の方法がないことである。したがって、あるノード（またはそのノードのユーザ）がサービスまたはコンテンツをどのノードから得るかを選択する際に、動的クエリーに回答を寄せた１組のノードの中からどのように選択するのかを決定する上で使用できる「実績（trackrecord）」または履歴が存在しないことになる。このように信頼モデルがないことは、Ｐ２Ｐネットワークが、一時的コミュニティ（transientcommunity）のメンバ間の信頼できるトランザクションをサポートしないことを意味している。（サン・マイクロシステムズ社のＪＸＴＡプロジェクトは、「ピア・グループ」または「共用空間」の概念を提供するＰ２Ｐアーキテクチャであり、そこではピア・グループ内の各ノードがサービスを公開（publish）することができる。このサービスには、メンバーシップ、アクセス、リゾルバのサービスなど１組のコア・サービスが含まれる。そこで規定されたアプローチでは、認証、許可、およびネーミングについてクライアント／サーバ・モデルをピア・グループに適用するものである。すなわち、ピア・グループ・レベルだけではあるが、集中化の概念を維持している。このようなピア・グループを、一時的コミュニティとして特徴づけるのは適切ではない。同様に、グルーブ・ネットワークス社（GrooveNetworks, Inc.）のGroove（登録商標）製品もピア・コミュニティ内部の１組の「共用サービス」を提供する。また、このサービスの組には、セキュリティ、メンバ、およびアクセス・コントロールのサービスが含まれる。この場合のセキュリティ機構は、認証のための公開鍵インフラストラクチャ（「ＰＫＩ」）、および機密保持のための共用秘密鍵による鍵交換である。したがって、デジタル署名、デジタル認証、および共用セキュリティ・サービスを含むことになるこの要件は、一時的コミュニティの概念を否定する。）

よく知られたＰ２Ｐネットワークの１つに、「GnutellaNet」と呼ばれるものがある。GnutellaNetでは、ユーザが初めに「ダウンロード」ウェブ・サイトに行くことなく、ユーザのコンピュータのストレージ・デバイス・リソース間で直接ファイル交換を行うことが可能なプロトコルを使用している。「ナプスター（Napster）」は、もう一つのよく知られたＰ２Ｐネットワーク実装である。ナプスターでは、ユーザは、集中管理されたウェブ・サイトに接続してＭＰ３音楽ファイルを識別し、次いでそれらのファイルを他のユーザのコンピュータの１つからダウンロードすることができる。ナプスターは、特にＭＰ３ファイルに適合されているが、GnutellaNetを使用すればどのようなタイプのファイル・コンテンツでもダウンロード可能である。他にいくつかのＰ２Ｐネットワーク実装も存在する。

Ｐ２Ｐネットワークは、潜在的にクライアント／サーバ・ネットワークより、より効率的なネットワークになる可能性がある。この効率向上の可能性は、Ｐ２Ｐネットワークが中央のサーバを含まないことから生ずる。クライアント／サーバ・モデルでは、ほとんどの処理機能が中央のサーバ上に存在し、したがって処理負荷がこのサーバに集中する傾向がある。Ｐ２Ｐネットワークでは、ネットワーク中のあらゆるノードにタスクを分配することが可能であり、それによりネットワーク・リソースをより効率的に使用することができる。Ｐ２Ｐシステムの動的な性質、およびその効率的な負荷分配の能力が増強され、Ｐ２Ｐシステムは「ＩＴ（情報技術）」アーキテクチャにおける次の変革になった。しかし、上記のような制限のため、既存のＰ２Ｐネットワークは消費者および「無料の（for-free）」のマーケットに委ねられてきた。このため、Ｐ２Ｐシステムは（ｅビジネス・トランザクションまたはビジネスツービジネス・トランザクションなどの）大容量ビジネスの実施にはうまく適合していない。（また、上記のように、既存のＰ２Ｐ実装は、一時的コミュニティ内でのセキュアなトランザクションにもうまく適合していない。セキュアなトランザクションは、一般にｅビジネスにとって不可欠なものである。）

さらに、従来のＰ２Ｐシステムは無管理であり、また同質的（homogenous）である。そのため、様々な装置を管理可能な方法で相互運用できるようにする必要がある大規模で頑強なＩＴアーキテクチャー内でＰ２Ｐを実装することは非現実的である。
米国特許出願第０９／９５６，２７６号 http://www.research.ibm.com/autonomic/、「オートノミック・コンピューティング」に関する情報「Simple Object Access Protocol(SOAP) 1.1, W3C Note 08 May 2000」http://www.w3.org/TR/2000/NOTE-SOAP-20000508、ＳＯＡＰに関する詳細情報 http://www.w3.org/2000/xp、ＸＭＬプロトコルに関する詳細情報「Web Services Description Language(WSDL) 1.1, W3C Note 15 March 2001」、http://www.w3.org/TR/2001/NOTE-wsdl-20010315、ＷＳＤＬに関する詳細情報 http://www.uddi.org/specification.html、ＵＤＤＩに関する詳細情報ＩＥＴＦ発行のＲＦＣ２６１６「Hypertext TransferProtcol--HTTP/1. 1」、June 1999、ＨＴＴＰに関する詳細情報 Prof. Dr. F. Leymann、「Web ServicesFlow Language (WSFL 1. 0) 」（May 2001）、http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf、ＷＳＦＬの仕様書 http://XML.apache.org/axis/index.html、ApacheAXIS に関する詳細情報 XML Linking Language (XLink)Version 1.0、W3C Recommendation 27 June 2001、http://www.w3.org/TR/xlink/、XLinking言語の定義 Resource Description Framework,(RDF) Model and Syntax Specification, W3C Recommendation 22 February 1999、http://www.w3.org/TR/REC-rdf-syntax/、ＲＤＦに関する詳細情報 Keith Ballinger他、「Web ServicesInspection Language (WS-Inspection) 1. 0, (November 2001)」、http://www-106.ibm.com/developerworks/library/ws-wsilspec.html、ＷＳＩＬに関する詳細情報「SOAP Messages with Attachments,W3C Note 11 December 2000」、 http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211、添付ファイル付きＳＯＡＰメッセージに関する詳細情報

既存のアプローチの欠点および制限を回避しながら、Ｐ２Ｐネットワークの利点および潜在的な能力を活用するために使用できる技術を提供できれば望ましいであろう。

本発明は、ピアツーピア・コンピューティング・ネットワークを改良するための方法、システム、およびコンピュータ・プログラム製品を提供する。好ましい実施形態の一態様では、その改良点は、ネットワークを構成するノードの集合体が時間とともに変化し得る一時的ネットワーク・コミュニティを有するネットワークにおいて、永続的にノードを識別することを含む。好ましくは、この技術は、このネットワークへの各ノードの最初のエントリ時に各ノードに最初のネットワーク・アドレスを割り当てること、このネットワークへの各ノードの最初のエントリ時に各ノードの永続的なノード識別子を生成すること、この最初のネットワーク・アドレスと永続的なノード識別子との間のマッピングを格納すること、および各ノードのこのネットワークへのその後のエントリに際し、たとえ異なるネットワーク・アドレスがそのノードに割り当てられたとしても、永続的なノード識別子を使用してその識別を解決することを含む。

特定のノードに関する格納されたマッピングは、そのノードがネットワークに異なるネットワーク・アドレスで再入するたびに改訂され、そのノードに関するマッピングのネットワーク・アドレスをその異なるネットワーク・アドレスで置き換える。

特定のノードの永続的なノード識別子は、好ましくは、そのノードの最初のネットワーク・アドレス、ネットワークへの最初のエントリが発生した日付、必要ならばネットワークへの最初のエントリが発生した時間、および最初のエントリが発生したドメインを基にして生成される。

次に、永続的なノード識別子を使用して、このネットワークにおける各ノードの挙動（例えば、特定のノードが他のノードからの要求にどの程度良く応答するかなど）を追跡することもできるし、またネットワークにおけるコンテンツ・リソースがたどったネットワーク横断パスを追跡することもできる。

本発明の他の態様は、添付の特許請求の範囲の中で定義される。

次に、本発明の実施形態について、例として添付の図面を参照しながら説明する。全図面を通して、同じ参照番号は同一の要素を示す。

以下で説明する実施形態では、Ｐ２Ｐネットワーク・オペレーションを改良する技術を定義する。各ネットワーク参加者すなわちノードには、そのノードがネットワークを離れ、ネットワークに再入したときにもそのノードを識別できるように永続的な識別子が割り当てられる。ネットワークを横断するコンテンツがたどったパスも追跡され永続される。本明細書で開示するように、コンテンツ・パスおよびノードのコンテキスト情報を永続させることにより、複数の呼出しにわたってピア関係を維持することが可能になる。開示の技術は従来技術の欠点に対処するものであり、それを用いると、たとえ参加者が通信を行うコミュニティがその名の通り一時的なコミュニティであったとしても、ピア装置間の関係を単一のセッションを越えて永続させることが可能になる。

開示の技術は、Ｐ２Ｐネットワークの特性に対処する固有の動的ネットワークをサポートし、さらに異機種のネットワーク・ノードのサポートも提供する。永続される情報は、ネットワーク管理、トランザクション、およびセキュリティ・ポリシーのアプリケーションなどを含む企業運営をサポートするために利用できる。

さらに、開示の技術により自己修復ネットワークの提供が容易になる。自己修復ネットワークは、人間との対話あるいは別のコンピューティング・システムによる管理とは無関係に、ネットワークがランタイムでタスクの管理／モニタリングを行うものである。本明細書で開示の技術により、ノードはピアとの関係を深め、その情報を永続させることが可能になり、その結果、悪意のあるノードあるいは性能および機能の完全性に関して十分に機能していないノードを識別することができる（さらに、それが検出されたときには、ネットワークへの悪影響を防ぐことができる）。（http://www.research.ibm.com/autonomic/を参照されたい。このページでは、「オートノミック・コンピューティング（autonomiccomputing）」という表現を使用して、一般的な自己修復ネットワークの概念について論じている。そこに記載された技術は、集中化された権限のない一時的ネットワーク・コミュニティにおける自己修復については教示していない。）

本明細書で開示の技術により、Ｐ２Ｐネットワーク運用における効率の向上も容易になる。従来技術のＰ２Ｐネットワークがクエリーをサブネット全体にブロードキャストする必要があったのに対し、本発明は、ネットワークのノードの永続的な知識を利用して、生成されるネットワーク・トラフィックの量を削減する階層的ブロードキャスト技術（tiered broadcast technique）を開示する。

典型的なＰ２Ｐネットワークには、様々なピア・ノードが共存することになる。ピア・ネットワークそれ自体が、（例えば、サブサービス間の有向グラフとして定義できるサービスを含む、一連の関連するビジネス活動の実施など、）コンシューマ／サプライヤ関係における互いに対話する１組の垂直ピアを表すことができる。あるいは、このネットワークは、共通機能を提供する１組の水平ピアを表すこともできる。本発明の技術を使用して、そのようなノードに自動化と管理の機能を提供するようにＰ２Ｐアーキテクチャを増強することができる。

一例として、一群のピア・ノードが、ストレージ・エリア・ネットワーク（StorageArea Network）すなわち「ＳＡＮ」にストレージ・リソースを提供することもできる。ストレージ・サービス・プロバイダ（「ＳＳＰ」）は、顧客のために予約料金制あるいは利用回数料金制でＳＡＮを維持する。また通常は、それらの顧客に対するＳＳＰのサービス・コミットメントを指定するサービス・レベル契約（「ＳＬＡｓ」）が存在する。ＳＬＡコミットメントが満たされない場合には、顧客請求が悪影響を受けることもある。Ｐ２Ｐネットワークでは、ストレージを必要とするノードが動的ネットワーク・クエリーを発行して、その機能を提供する他のノードを見つけることができる。この種の動的クエリーやピアの発見は、従来技術のＰ２Ｐネットワークにおいても使用できる。しかし、前述のように、既存のＰ２Ｐネットワークには信頼モデルがなく、また「良好な（good）」ストレージを提供するノードをどのように選択するかを知る方法もない。本発明の技術を使用すると、ＳＳＰは、ストレージ要求が現在どの程度良く処理されているかを反映し、リアル・タイムで判断される評判を有するＰ２Ｐストレージ・ユーティリティとしてのオートノーマス・ストレージ・パーティション（autonomousstorage partitions）を管理することができる。この動的に計算される情報を使用すると、ストレージ要求に最も良く応答できるストレージ装置を決定することが可能になり、その結果、要求元（requester）へのストレージの動的割振りが容易になる。さらに、本発明の技術を使用して、特定のコンテンツ要求に応えることができる特定のストレージ・リソースをより容易に識別することができる。したがって、ＳＬＡの中での応答性と性能のコミットメントを、より一貫して実現することができる。（ストレージ・ノードがどれくらい良くストレージ要求を処理するかには、要求に対する応答の成功率、要求への応答に際しノードがどの程度効率的か、ノードの使用可能なストレージ容量、そのノードにおいてどのようなコンテンツが提供可能かなどを含めることができる。）

以下でより詳細に説明するが、たとえ１つまたは複数のノードがＰ２Ｐネットワークを離れ、その後そのネットワークに再入したとしても（この場合、Ｐ２Ｐネットワークでは、一般に再入するノードのネットワーク・アドレスが変わる）、コンテンツ・パスおよびノードのコンテキスト情報を永続させておくことによって、ピア・ノードは、それら相互の関係、およびそれら相互の知識を複数のセッションにわたって維持することができる。さらに、本明細書で開示の技術によれば、特定のノードに関するコンテキスト情報が得られるので、ノードは、本明細書で「評判（reputation）」と呼ばれるものを作成する。この評判は、さらに信頼モデルのベースとしても使用できる。評判については、以下でより詳細に説明する。（ノードの評判に使用するために永続させるのが好ましい情報の記述については、図５および図６の議論を参照されたい。）

図１に関連して説明するように、本発明の好ましい実施形態は、Ｗｅｂサービス・モデルおよびＰ２ＰネットワークへのＷｅｂサービス・アプローチを用いて展開されるが、開示の技術は他の環境においても同様に使用できるように適合させることができる。本発明の有利な技術は、この開示では主にファイル共用への適用（すなわち、どのコンテンツがどのノードから提供されるかを識別すること、特定のコンテンツがネットワークを横断するときたどったパスを記憶すること、ピアにコンテンツを要求すること、そのコンテンツを受信することなど）に関して論じる。しかし、これは例示のためであって、制限のためではない。開示の技術は、単純なファイル共用のための対話に加えてより複雑な対話にも使用できる。たとえば、当技術分野で知られているように、Ｗｅｂサービス・モデルを用いると複雑な対話の実施が容易になる。一般に「Ｗｅｂサービス」は、ネットワークにアクセス可能なオペレーションの集合体を記述するインタフェースである。Ｗｅｂサービスは、特定のタスクまたは１組のタスクを実施する。また、Ｗｅｂサービスは、１つまたは複数の他のＷｅｂサービスと相互運用可能な方式で連携して、Ｗｅｂサービスとして定義される複雑なワークフローまたはビジネス・トランザクションの担当部分を実施することもできる。一例として、複雑な購入オーダ・トランザクションを完成させるには、注文ビジネスにおける発注サービス（すなわち、発注ソフトウェア）とその１つまたは複数のビジネス・パートナーにおける注文調達サービスとの間の自動化された対話が必要になることがある。このプロセスがＷｅｂサービスとして記述されると、本発明の技術を使用するノードは、このサービスを実施できるピア・ノードを見つけ出し、特定のノードを選択する（例えば、ノードの評判に基づいて）。要求に応じて、見つけ出されたピア・ノードはサービス（通常、いくつかのサブサービスを含む）を実施し、次いでそのサービスの結果を要求ノードに返す。

Ｗｅｂサービス技術は、ＷＷＷ（ワールド・ワイド・ウェブ）などのクライアント／サーバ・ネットワークにおける分散アプリケーション統合（distributed application integration）の技術分野で知られている機構であり、それにより分散ネットワークが、これらのネットワークにおいてプログラム間オペレーションのためのソフトウェアにアクセスすることが可能になる。Ｗｅｂサービスは、ＨＴＴＰ、ＳＯＡＰまたはＸＭＬあるいはその組合せのプロトコル、ＷＳＤＬ（WebServices Description Language）、ＵＤＤＩ（Universal Description, Discovery, andIntegration）などいくつかのオープンＷｅｂベース標準を使用する。ＨＴＴＰは、一般にインターネットなどのＴＣＰ／ＩＰ（伝送制御プロトコル／インターネット・プロトコル）ネットワーク上でのメッセージ交換に使用される。ＳＯＡＰは、分散環境においてメソッドを呼び出すために使用されるＸＭＬベースのプロトコルである。ＸＭＬプロトコルは、Ｗ３Ｃ（WorldWide Web Consortium）により、アプリケーション間メッセージ交換を可能にするように設計されたアプリケーション層転送プロトコルの発展中の仕様である。ＸＭＬプロトコルはＳＯＡＰと一体化する可能性がある。ＷＳＤＬは分散ネットワーク・サービスを記述するためのＸＭＬフォーマットである。ＵＤＤＩはＸＭＬベースのレジストリ技術であり、それを用いて企業がサービスをリストすることができ、またそれを用いてサービスの要求元は特定のサービスを提供している企業を見つけることができる。

クライアント／サーバ・ネットワークにおける分散アプリケーション統合は、ＵＤＤＩ要求を発行してＵＤＤＩレジストリを介して分散サービスを見つけ、見つけたサービスに、サービス情報を使用して動的に要求元を結び付けることにより達成される。サービス情報は、ＳＯＡＰ／ＸＭＬプロトコルおよびＨＴＴＰメッセージを使用するプラットフォーム中立のＷＳＤＬフォーマットで伝えられる。（この場合のＳＯＡＰへの参照は、ＸＭＬプロトコルの意味的に類似したアスペクトを等価なものとして参照していると解釈すべきである。）これらのコンポーネントを使用することによって、たとえ要求されたプログラム・コンポーネントが要求元のものとは異なるオペレーティング・システム上で稼動していたとしても、また要求元のものとは異なるプログラミング言語で書かれていたとしても、Ｗｅｂサービスは、要求元に１つまたは複数の遠隔地に存在し得るそのプログラム・コンポーネントへの透過的なアクセスを供給する。（ＳＯＡＰに関する詳細な情報は「Simple Object Access Protocol (SOAP) 1.1, W3C Note 08 May 2000」http://www.w3.org/TR/2000/NOTE-SOAP-20000508を、ＸＭＬプロトコルに関する詳細情報はhttp://www.w3.org/2000/xpを、ＷＳＤＬに関する詳細情報は「WebServices Description Language (WSDL) 1.1, W3C Note 15 March 2001」、http://www.w3.org/TR/2001/NOTE-wsdl-20010315を、ＵＤＤＩに関する詳細情報はhttp://www.uddi.org/specification.htmlをそれぞれ参照されたい。ＨＴＴＰについては、ＩＥＴＦ（InternetEngineering Task Force）発行のＲＦＣ（Request For Comments）２６１６「Hypertext TransferProtcol--HTTP/1. 1」、June 1999に記載されている。）

次に、図１を参照すると、本明細書に開示の技術の好ましい実施形態においては、Ｐ２Ｐネットワーク内のノード間通信の基本的なサポートを提供するために、ＩＢＭのＷｅｂサービス相互運用性スタック１００が使用されている。しかし、これは例示のためのものであって、限定を意味するものではない。本明細書で開示される発明の概念から逸脱することなく、他のサポート機構を使用することもできる。次に、Ｗｅｂサービス相互運用性スタック１００の各コンポーネントについて説明する。

好ましくは、有向グラフを使用して、従来技術による技法を使用し、複数のサブサービスを含むＷｅｂサービスの実行に含まれるオペレーションをモデル化する。例えば、同一出願人による「Dynamic, Real-Time Integration of Software Resources throughServices of a Content Framework」という名称の米国特許（出願第０９／９５６，２７６号、２００１年９月１９日出願）を参照されたい。その特許に開示された技術では、グラフのノードがサービス実施時に実行されるオペレーションを表し（そこでは、これらのオペレーションがサブサービスと呼ばれることもある）、グラフのノードをリンクするエッジ（edge）は、あるサービス・オペレーションから別のサービス・オペレーションへの可能な移行を表す。これらのグラフ・エッジ、または「サービス・リンク」には、１つまたは複数の移行条件を与えることができる。また、適用可能な場合にはデータ・マッピング情報を与えることもできる。条件は、どのような条件の下で次にリンクされるサービスが呼び出されるかを指定する。これらの条件は、しばしば前のサービス呼出しの結果を使用して決定されることになる。データ・マッピングは、オペレーションをリンクし、あるオペレーションから別のオペレーションにデータを転送する有向グラフの能力を参照する。例えば、データ・マッピング情報は、あるサブサービスの出力パラメータが他のサブサービスの入力パラメータにマッピングされるように指示することができる。

「ＷＳＦＬ」（Web Services Flow Language）は、好ましくはこれらの有向グラフをサポートするために使用される。これは、図１にサービス・フロー・サポート１１０で示される。複雑なＷｅｂサービスを実施するために有向グラフがＷＳＦＬエンジンによってどのように処理されるかは本発明の理解には関係がなく、本明細書では詳細には説明しない。ＷＳＦＬの詳細な議論は、Prof.Dr. F. Leymannによる「Web Services Flow Language (WSFL 1. 0) 」（２００１年５月）と題するＷＳＦＬ仕様書に出ている。この文書はＩＢＭから入手可能であり、またインターネットのhttp://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdfからも入手可能である。

Ｗｅｂサービス（例えば、Ｐ２Ｐネットワークの各種のノードから提供されるＷｅｂサービス）の自動発見１２０および公開１３０は、好ましくはＵＤＤＩメッセージを使用してＵＤＤＩレジストリにアクセスするために提供される。ＷＳＤＬ層１４０はサービス記述ドキュメントをサポートする。ＳＯＡＰはＸＭＬベースのメッセージング１５０を提供するために使用できる。ＨＴＴＰ、ＦＴＰ（ファイル転送プロトコル）、電子メール、ＭＱ（メッセージ・キューイング）などのプロトコルは、ネットワーク・サポート１６０のために使用できる。ランタイム時には、サービスは、ＵＤＤＩサービス発見プロセスを使用してレジストリ内で見つけられ、それらサービスのＷＳＤＬ定義からの情報を使用して確定される。次いで、ＷＳＦＬランタイムがこれらの定義を使用してサービスを集約する。

本発明の好ましい実施形態によれば、ＵＤＤＩレジストリから取り出された情報を使用することによって、ファイル共用オペレーションが容易になる。また、より複雑なＷｅｂサービスも、同じ方法でサポートできる。（レジストリの使用についての詳細な情報は、後の図２についての議論を参照されたい。）

本実施形態では、Ｐ２Ｐネットワークにおけるノードを、ピアとして厳密にモデル化するのではなく、クラスとしてモデル化できる技術を開示する。例えば、本実施形態では「システム」ノードについて記述する。本明細書では、「システム・ノード」という用語は、従来のクライアント／サーバ・ネットワークにおいてシステム管理者によって管理されるタイプの機能を提供する、Ｐ２Ｐネットワーク内のノードを意味する。これらの機能には、ネットワーク管理、ロード・バランシング、モニタリング、セキュリティなどのネットワーク・オペレーションが含まれる。本発明を実施するノードを有するＰ２Ｐネットワークは、ローカル・エリア・ネットワークおよびエンタープライズに及ぶことができ、ワールド・ワイド・ウェブの範囲によってのみ制限される。（例えば、「スパイ（spy）」メッセージについての議論を参照されたい。「スパイ」メッセージを用いると、あるノードが例えば他のサブネット上にあるノードについて知ることが可能になる。一方、従来技術のＰ２Ｐでは、ＩＰアドレスを監視するフィルタの構成のために、一般にブロードキャスト・トラフィックはサブネット内のノードに制限される。）したがって、本明細書に開示の技術を使用すると、混乱なく（non-disruptive）様々なクラスのノードがネットワークに参加でき、新しいタイプのノードもネットワークに参加できる。

ノードのクラス、特にシステム・ノードについての概念は本発明のオプションの態様であり、Ｐ２Ｐネットワークのハイブリッド・フォームを生成するために使用できる。ハイブリッド・フォームでは、一部のノードが他のノードに指令を出し、あるいは他のノードが記憶する情報に影響を与える。システム・ノードが使用できる特別な機能については、本明細書中でより詳細に論じる。

好ましい実施形態によれば、本発明の１つまたは複数の態様を実装するノードは、「ＡＸＩＳ（Apache eXtensible Interaction System）」エンジンおよびＡＸＩＳチェーニング・フレームワークを利用するハンドラのコンテキスト内で稼動するＷｅｂサービス・モデルを使用する。（ApacheAXIS に関する詳細な情報はhttp://xml.apache.org/axis/index.htmlを参照されたい。Apache AXISはアパッチ・ソフトウェア財団（ApacheSoftware Foundation）によるＳＯＡＰプロトコルの実装である。）

「ＡＸＩＳ」はＳＯＡＰサービスのランタイム環境であり、そこではＷｅｂサービスはコンテナ・モデルを使用して稼動する。「ルータ（router）」と呼ばれるサーブレットは、インバウンドＳＯＡＰ要求メッセージ（inbound SOAP request message）を受信し、その要求を実施するためにどのコードが必要かを判断し、そのコードに必要なオブジェクトを非直列化（deserialize）し、そのコードを呼び出す。呼び出されたコードが実行を完了すると、ルータは結果を直列化（serialize）してアウトバウンドＳＯＡＰ応答メッセージ（outboundSOAP response message）にする。

「AXISチェーニング」という用語は、インバウンドおよびアウトバウンド・メッセージの実行の順序を指示するメッセージ・ハンドラの構成可能な「チェーン」、またはシーケンスを意味する。「ハンドラ」は特定の機能を実装する実行可能なコードであり、（チェーニング機構によって）他のハンドラの機能とリンクさせることができる。それらのハンドラは、ＳＯＡＰリクエストの前処理または後処理を実施する。デプロイメント記述子は、例えば特定のサービスで使用されるオブジェクトをどのように直列化／非直列化するか、またどのＡＸＩＳハンドラ・チェーンを使用するかなどそのサービスがどのように展開されるかを指定するために使用される。例えば、ＳＯＡＰメッセージ交換は暗号化されたデータを使用できる。暗号化されたデータを含むメッセージを受け取ると、復号ハンドラが（前処理ステップとして）データを復号し、それを適切なメッセージ処理コードに渡す。結果が返される場合には、他のＳＯＡＰメッセージの形で結果を送信する前に、暗号化ハンドラがその結果を（ポスト処理ステップとして）暗号化する。

ＡＸＩＳエンジンは３つのタイプのハンドラ・チェーンをサポートする。第１はトランスポート・チェーンであり、メッセージ移送機構（例えばＨＴＴＰなど）を指定する。第２はサービス依存チェーンである。例えば、特定のサービス「ＸＹＺ」に関して、サービスＸＹＺのためのメッセージが受信されたか、またはサービスＸＹＺによってメッセージが生成されたときに、サービス依存チェーンはどのハンドラを呼び出すかを指示する。第３のハンドラ・チェーンはグローバル・チェーンであり、あらゆるメッセージについて、呼び出すべきハンドラを指定する。

図２は、好ましい実施形態で使用されるコンポーネントを示す図であり、それらのコンポーネントがネットワーク環境中でどのように配置され、どのように相互接続されるかを抽象的に示している。次に、これらのコンポーネントについて説明する。

好ましい実施形態においてランタイム・エンジン２２０は、ＡＸＩＳ実行エンジン２２５；グローバル・ハンドラ・チェーン中の３つのＡＸＩＳハンドラ２３０、２３５、２４０；リンクベース・リポジトリ２４５；メタデータ・リポジトリ２５０；およびデジタル証明書リポジトリ２５５を含む。このランタイム・エンジン２２０は、好ましくは、Ｗｅｂサービス２００で示されるＷｅｂサービス内で実施される。Ｗｅｂサービスは、オプションでｔＭｏｄｅｌインスタンス２０５を実装することを選択できる。当技術分野で知られているように、ｔＭｏｄｅｌはＷｅｂサービスによって実施される挙動または仕様を指示する。ｔＭｏｄｅｌはＵＤＤＩレジストリ内に記憶され、特定のサービスを実施するためのレジストリのスキャンを容易にする。ｔＭｏｄｅｌは、Ｗｅｂサービスがサポートするクエリーのタイプを指定するために本発明の好ましい実施形態のコンテキスト内で使用できる。例えばコンテンツ・リポジトリ２１０によって示される１つまたは複数のコンテンツ・リポジトリは、ノードのローカル・コンテンツまたはリモートにあるコンテンツへの参照あるいはその両方を記憶する。

より詳細に説明すると、好ましい実施形態では３つのＡＸＩＳハンドラが使用され、それらを本明細書では「パス・インティメイタ（Path Intimater）」２３０、「ゴシップ・モンガ（Gossip Monger）」２３５、「デジタル署名（ＤＳＩＧ）」ハンドラ２４０と呼ぶ。

先に述べたように、本発明の１つまたは複数の態様は、ノードのコンテキスト情報およびＰ２Ｐネットワークのノードの間で共用されるコンテンツが横断したパスを永続させる技術を定義する。パス・インティメイタ２３０は永続コンテンツ・パスを管理する。永続コンテンツ・パスは、本明細書では有向グラフ・モデルを使用するものとして定義する。この有向グラフでは、グラフ・ノードが、コンテンツが通過したピア・ノードに相当し、グラフ・アーク（graph ark）が、各アークによって接続されたピア・ノード間を通過したコンテンツを表す。（これらの有向グラフは、先に論じた有向グラフと混同してはならない。先の有向グラフは、複雑なＷｅｂサービス対話を定義するために使用されるものであり、ＷＳＦＬを使用してサポートされる。）

好ましい実施形態によれば、ＸＭＬリンク（「XLink」）言語は、永続コンテンツ・パスを定義する有向グラフを表す手段として使用される。XLink言語は、「XMLLinking Language (XLink) Version 1.0、Ｗ３Ｃ勧告２００１年６月２７日」で定義されている。この勧告は、例えばインターネットのロケーション、http://www.w3.org/TR/xlink/に出ている。当技術分野で知られているように、XLinkシンタックスは単純なマークアップ・スタイルのリンク（リモートのリソースを指示するアウトバウンド・リンクおよびローカル・ノードにリンクされたリソースを識別するインバウンド・リンクを含む）、またはより複雑な「拡張（extended）」リンクを定義するために使用できる。（しかし、当技術分野では、本明細書に開示のXLinkのリンクを使用することは知られていない。）拡張リンクは、ノードおよびノード間のアークからなるグラフを表すために使用される。拡張リンクの１つのタイプが「サード・パーティ（thirdparty）」リンクである。サード・パーティXLinkは、リモートのリソースを関連づける。このことは、リンク仕様がリンクが結び付けるコンテンツとは別に格納されていることを意味する。後で説明する図９には、コンテンツの横断パス定義（より一般的には、メッセージの横断パス定義）を永続させるために、本発明の好ましい実施形態でXLinkがどのように活用できるかが示される。

本明細書の好ましい実施形態では、コンテンツ・リソースが通過したパスを記憶するために永続パス定義を使用するものとして説明しているが、これは例示のためであって限定のためではないことに留意されたい。サービス実行の結果など、他の情報のためにパス定義を永続させることもできる。したがって、本明細書で使用する「コンテンツ」という用語は、ノード間で送信される任意のタイプの情報を表すものと解釈できる。また特に「コンテンツ」は、すでに生成済みのコンテンツ、またはノードにサービスの実行を要求することによって生成され得るコンテンツを意味する省略表現として使用される。さらに、永続パスは、そのメッセージが運ぶ情報のタイプとは無関係に、メッセージのパスを表すものと解釈できる。

サード・パーティXLinkの集合体が、まとめてＸＭＬドキュメントに格納されるとき、その集合体は「リンクベース（linkbase）」または「リンクベース・ドキュメント」と呼ばれる。したがって、本明細書で使用する用語としてのリンクベースは、サード・パーティXLinkとして表された横断パス定義の集合体を意味する。リンクベース識別子は、Ｐ２Ｐネットワーク中のノードを一意に識別するために、本明細書で開示されるフォーマットを使用して定義される。（リンクベース識別子に関する詳細情報は、後に示される図５の議論を参照されたい。）

したがって、パス・インティメイタ２３０は、リンクベースとしての永続メッセージ・パスを管理する。これらのリンクベースはリンクセット（linkset）を含む。リンクセットは、特定のコンテンツ・リソースが通過するパスを定義するものである。これらのリンクベースについては、本明細書中でより詳細に論ずる。

パス・インティメイタ２３０は、コンテンツ通過情報を運ぶアウトバウンドＳＯＡＰメッセージに、図３に示した形式のＳＯＡＰヘッダを追加する役割を果たす。このヘッダ３００は、＜traversalPathRef＞タグ３０５（図３の例では、これに「パス（path）」のための名前空間識別子「ｐ」が前に付加されている）を含む。また、この＜traversalPathRef＞タグは、ピア・ネットワークにおける指定されたコンテンツの横断パスを記憶するリンクセットへの参照３１０を提供する。図３の例では、「href」属性３１０の値は、ＵＲＬ（UniformResource Locator）「http://9.56.34.12/linkbase/lb.xml」を使用してアクセス可能なリンクベース・ドキュメントに横断パス情報が格納されていることを示す。

受信側のパス・インティメイタ２３０は、＜traversalPathRef＞要素を有する着信ＳＯＡＰヘッダの受信時に、それに従って受信側のリンクベースを更新する役割を担う。この処理は、参照３１０によって識別された横断パスの終端で、アークの中に受信ノードのLBuuidを追加することを含む。（したがって、受信ノードが横断パスに関連したコンテンツを続いて転送する場合、図３を参照して説明したＳＯＡＰヘッダで識別される更新済みの横断パスは、適切に転送ノードを識別する。）横断パスがどのようにノード間のパスを識別するかについての詳細情報は、下の図９を参照されたい。

ゴシップ・モンガ２３５は、ノードに関するメタデータとしての評判を管理する。さらに、ゴシップ・モンガは、ノードの評判を受信したとき、コンテンツ・メタデータを処理し、そのコンテンツ・メタデータを評価する。本発明の好ましい実施形態では、「ＲＤＦ（Resource Description Framework）」表記を使用してコンテンツおよびノードを記述するメタデータを指定する。（ＲＤＦはＷｅｂベースのメタデータの指定のために設計された表記法である。ＲＤＦに関する詳細情報は、Ｗ３Ｃによってインターネット上のページ、http://www.w3.org/TR/REC-rdf-syntax/に提供された「ResourceDescription Framework, (RDF) Model and Syntax Specification、Ｗ３Ｃ勧告、１９９９年２月２２日」を参照されたい。）ここまで説明したように、Ｐ２Ｐネットワークが高度に分散され、ノードのＩＰアドレスが時間とともに変わり得るので、本明細書に開示のゴシップ・モンガは、信頼が時間とともに発展する発展的信頼モデル（evolutionarytrust model）を提供する。最初に、ノードはそれ自体を信頼する。時間の経過とともに、ノードはピアとの対話によって受信するコンテンツおよびそのコンテンツがたどったパスについてのメタデータを集める。この集められたメタデータは、一種の履歴または証跡を提供しているものと見なせる。特定のピアからポジティブな結果のコンテンツを受信すればするほど、そのピアとの信頼関係は強化されることになる。オプションで、ノードは、そのピアから入手した関係情報から信頼を導き出すこともできる。この関係情報は、そのノードのピアが（そのノード自体は、対話しなかったかもしれない）他のピア・ノードと実施した対話を記述したものである。

次に、図５および図６を参照すると、評判データを指定する好ましい技術および代替技術が示されている。好ましい実施形態では、あるノードの評判は、そのノードが提供するサービスまたはそのノードが提供するコンテンツあるいはその両方の指示、ならびにそのノードが提供するサービスの品質を含む。あるノードの評判は、好ましくはそのノードから送信され（かつ受信側で記憶され）るメッセージのメタデータとして具体化される。好ましい実施形態では、サービスの質は数値（「評価（stature）」値と呼ばれる）で指定される。この数値は、この特定のノードが、ネットワーク中の他のノードから受信するクエリーに応えることにどれぐらい成功するかを表す。あるノードの評判についてのサービス・コンポーネントの品質が、ある場合には、悪意のあるノード（例えば、不正を働くエージェントまたはリソースの供給源である傾向を示すノードなど）であることを指示することがある。評判を動的にアドレスが指定されるノードに関連づけることができると、非集中のＰ２Ｐ世界における信頼を得やすくなる。また、評判情報が使用できると、セキュリティ・ポリシーを使用する信頼モデルをＰ２Ｐ対話に適用することができる。したがって、Ｐ２Ｐネットワークにおけるe-ビジネスへの主要な阻害因子が除去される。（本明細書では、好ましい実施形態を、動的に得られる評判に関連して説明しているが、特定の実装においては、１つまたは複数のノードの評判を初期化する、すなわちあらかじめ設定することによって、例えばシステム管理者がシステム管理を容易に行えるようにすることが望ましいこともある。このような実装は、本発明の範囲に含まれるものと見なされることに留意されたい。このアプローチを使用して、選択されたノードに比較的高い評価値を与え、事実上それらのノードをシステム・ノードに指定することができる。）

好ましい実施形態によると、Ｐ２Ｐネットワークにおける一時的ノードは、リンクベース識別子（「ＩＤ」）すなわち「LBuuid」を使用して識別される。このLBuuidは次の形式を取る。
[IP_Address-Date-Time-Domain]（[ＩＰアドレス−日付−時間−ドメイン]）
また、LBuuidは一意に識別可能なＩＤすなわち「ＵＵＩＤ（UniversalUnique Identifiers）」の概念に基づいてモデル化される。当技術分野では、ＵＵＩＤはパブリックなインターネット上のオブジェクトまたはエンティティを一意に識別する技術として知られている。（しかし、LBuuidフォーマットについては知られていない。従来技術のＵＵＩＤは、一般にそのＵＵＩＤを生成したホストのＩＰアドレスへの参照、タイムスタンプ、および一意性を確保するためにランダムに生成されたコンポーネントを含む。）

本明細書で開示されるLBuuidの一例として、図５のドキュメント４００の例では、評判が表すノードは次のLBuuidを有する。
9.37.43.2-05/04/01-12:02:05:37-Netzero.net
これは、＜Description＞タグ４０５の「about」属性４１０の値として示されている。この例では、ＩＰアドレス・コンポーネントが「9.37.43.2」、日付コンポーネントが「05/04/01」、時間コンポーネントが「12:02:05:37」、そしてドメイン・コンポーネントが「Netzero.net」である。ここで定義された情報は、このノードのＰ２Ｐネットワークへの最初のエントリ時のオリジナルＩＰアドレスが「9.37.43.2」であり、このネットワークへの最初のエントリが、日付「05/04/01」、時間「12:02:05:37」にネットワーク・ドメイン「Netzero.net」で発生したことを示す。本明細書で開示するように、このLBuuidが今後この特定のノードを識別するために使用されるので、このノードの評判を永続させることが可能になり、またコンテンツ・パス横断定義中のこのノードの参照を解決することが可能になる。

所与の時点で、図５のLBuuidで表したノードの現在のＩＰアドレスが、LBuuidに示されたそのアドレスであることは保証されず、Ｐ２Ｐネットワークへの後のエントリに際して動的アドレス割当て機構から得られる別の値である可能性が高いことに留意されたい。あるノードを永続的に表すLBuuidは、リソース・セットに記憶されたマッピングによってノードの現在のＩＰアドレスと関連付けられる。（リソース・セットについては、後で図６に関連して説明する。）

＜Description＞タグ４０５は、このノードの評判情報をまとめて示したものである。この例では、＜QuerySet＞４１５という名称の子タグが指定され、「stature（評価値）」属性を有する。好ましい実施形態では、stature属性は、このノードがクエリーの実施にどの程度成功（または失敗）したかを示す数値を有する。stature属性値は、好ましくは−１から＋１の範囲の非整数値で指定される。ここで、負のstature値は悪意のあるノードを示す。好ましくは、対応する「totalQueries」属性も指定され、その値は、そのノードによって処理されたクエリーの総数を示す整数である。したがって図５の例では、ノードは２，１４５のクエリーを受信し、そのクエリーの３４パーセントの実施に成功したことになる。（この例には、オプションの「ID」属性が示されている。この属性は、従来のＵＵＩＤフォーマットを使用して、このクエリー・セット４１５を一意に識別するために使用できる値を提供する。）

代替実施形態においては、評価値（stature、すなわち成功率）情報を、クエリー・セット全体ではなく個々のクエリーに関連付けることができる。この代替実施形態は図６に示される。この場合、「stature」属性および「totalQueries」属性が、＜QuerySet＞タグではなく＜Query＞タグで指定される。明らかなことだが、本発明の概念から逸脱することなく評価値情報についての他の表現を使用することができる。例えば、「２１４５のうちの３４パーセント」または「３４，２１４５」の形の値を持つ単一の属性を使用してもよい。他の代替案として、−１から＋１の範囲の評価値を使用するのではなく、別々の属性を使用して、不成功（または悪意のある）結果と成功結果を示すことができる。あるいは、パーセンテージの代わりにカウンタを使用することもできる。

図５の議論に戻って、好ましい実施形態で使用されるシンタックスでは、＜QuerySet＞タグ４１５は１つまたは複数の＜Query＞子要素を有する。＜Query＞要素のこの集合体は、このノードが応えられる（好ましくは、正規表現で表された）クエリーの組を列挙したものである。この例では、ノードは３つの異なるクエリー４２０、４２５、４３０に応えることができる。

第１の＜Query＞タグ４２０の正規表現シンタックスは、このノードが「purchase_order999-9999-999」の形のクエリーを処理できることを示す。すなわち、テキスト文字列「purchase_order」に続く３桁の数値、ハイフン、４桁の数値、ハイフン、３桁の数値の形式である。（本明細書で使用する例では、これらの数値フィールドは、顧客番号を指定するように意図される。）

例示のクエリー・セットの第２の＜Query＞タグ４２５は、このノードがテキスト文字列「partnerprofile list」で表されるクエリーを処理できることを示す。第３の＜Query＞タグ４３０は、「-NDA. tiff」の形で終わるテキスト文字列であるクエリーを表す。

ノードの評判を判断するために、異なるまたは追加の情報をオプションで使用することができる。したがって、図５および６によって示される情報は、例示のためのものであり、限定を意味するものではない。例えば、ノードの効率を追跡することが有用なこともあり、その目的に評判データを使用することもできる。例えば、効率がクエリーを処理する応答時間で測定される場合、応答時間属性をこのノードの評判に（図６のアプローチを使用してクエリー固有の値として、あるいは図５のアプローチを使用してより一般的なかたちで）追加することもできる。先に述べたように、ノードの評判はゴシップ・モンガ・ハンドラによって処理される。したがって、本明細書に記載の評判処理を、必要に応じてハンドラによって拡張して追加のまたは異なるタイプの評判データをサポートすることができる。

ノードの効率を追跡することによって、従来技術のＰ２Ｐネットワークで使用できる選択より、より慎重にコンテンツ／サービスの提供元を選択することができるようになる。先に論じたＳＳＰ環境で使用されるとき、ノードの効率情報を使用するＳＳＰは、どのようにストレージ・リソースおよび供給ストレージ・リソース（provision storage resources）を選択するかについてランタイムで決定することができる。その結果、ＳＳＰはその顧客に対するサービスを改善し、ＳＬＡのコミットメントを満たす可能性を高める。

評判は、あるノードの能力に関するヒントをリモート・ノードに提供する。また、本明細書に記載したように、評判はノードのクエリーに応答する能力に関する情報を提供する。ファイル共用の目的で使用されるとき、あるノードに対してクエリーを発行することは「この記述（description）のファイルがありますか？」と尋ねることを意味する。応答ノードは、そのクエリーに応えられること（すなわち、要求されたファイルを供給できること）、ならびに過去にどのくらいファイルの供給に成功したか（図５のアプローチを使用）または過去にどのくらいその特定のファイルの供給に成功したか（図６のアプローチを使用）を要求元に知らせるために評判を提供する。

次に図７を参照すると、コンテンツ・メタデータ（すなわち、特定のコンテンツについての情報）を指定するための好ましい技術を示す例が示されている。この形式のメタデータ情報を使用すると、ノードはどのコンテンツ・クエリーに応答できるかをプログラムで決定することができる。好ましい実施形態では、評判メタデータに対して使用したのと同様の方法でＲＤＦを使用してコンテンツ・メタデータを指定する（図５および図６参照）。図７の例に示したように、＜Description＞タグ５０５の「about」属性５１０は、ドキュメント５００に記載されたコンテンツの識別子を指定している。好ましい実施形態によれば、「about」属性の値は、ファイル名を、あるいは特定のクエリーに応答するコンテンツが格納されている他のストレージのロケーションを指定する識別子である。したがってこの例では、このコンテンツは「purchase_order123-4567-890.xml」のロケーションに格納されることになる。この識別子は、コンテンツ・メタデータを実際のコンテンツと関連づけることができる永続的なコンテンツ・キーの役割を果たす。

例示のシンタックスにおける＜Description＞タグ５０５は、子タグである＜Creator＞５１５および＜synopsis＞５２０を有する。＜Creator＞タグは、好ましくはdate属性およびtime属性を有する。それらの値は記述されたコンテンツが生成された日付および時間を示す。（あるいは、日付と時間を組み合わせて「Date_Time」属性とすることもできる。）＜Creator＞タグ５１５の値は、（この例では）そのコンテンツを作成した人を識別する。あるいは、＜Creator＞タグの値として、コンテンツが発信されるＰ２ＰノードのLBuuidなどのプロセス識別子を使用することもできる。＜synopsis＞タグ５２０は、好ましくはフリー・テキスト値を有する。また、そのタグを使用して対応するコンテンツである人間可読の記述を提供できる。したがってこの例では、＜synopsis＞５２０は、「purchase_order123-4567-890.xml」に格納されたコンテンツがＡＭＥＸ顧客＃１２３−４５６７−８９０の注文書であることを示している。

＜Description＞要素またはその選択部分の情報を人間のユーザに提供して、例えば、そのユーザが複数の候補の中からコンテンツ／サービスの提供元を選択するのを支援することができる。より自動化された環境では、＜Description＞要素からの情報は、プログラムの選択プロセスで解析することもできる。当然のことながら、例に示したメタデータは、格納できる情報のタイプ、およびその情報が表現され得る形式の単なる例示に過ぎない。

ゴシップ・モンガは、アウトバウンドＳＯＡＰメッセージに図４に示された形式のＳＯＡＰヘッダを付加して受信ノードに評判情報を知らせる役割を担う。この付加された評判ヘッダ３５０は、（「href」属性３６０を使用して）評判レポジトリへの参照を提供する＜reputationRef＞タグ３５５を含む。評判レポジトリには、送信ノードの評判情報が格納される。（この格納された評判情報は、送信ノード自体に関するものであるが、好ましくはその送信ノードが知っているピア・ノードに関する評判情報も含む。）

受信側のゴシップ・モンガ２３５は、評判メタデータがインバウンドＳＯＡＰメッセージ内のヘッダ・フィールドであると識別し、その評判メタデータを処理する。評判メタデータについては本明細書中でさらに説明する。

デジタル署名ハンドラ２４０は、メッセージの完全性および送信者の認証を保証するために、メッセージのエンティティにデジタル処理で署名する。このハンドラは、好ましくはＷ３ＣのＳＯＡＰデジタル署名仕様に従い、ＰＫＩを使用して証明書を管理し、かつ署名を適用／検証する。ＳＯＡＰデジタル署名およびＰＫＩ技術については当技術分野で知られているので、本明細書では詳細には説明しない。

適切なＡＸＩＳハンドラまたはゴシップ・モンガの特権が与えらた場合、システム・ノードは実際にリモート・ピアのリンクベースおよびメタデータ・リポジトリを直接、読取り（read）／書込み（write）して、例えば強制的にそれらをピア・グループに加えたり、コンテンツ横断パス定義を挿入したり、ピアの評判を管理することができる。（例えば、ノードＸに格納された評判情報を修正して、ノードＸのピア・グループのメンバＺを悪意のあるものと識別することができる）。好ましくは、このタイプのシステム管理機能は新しいＡＸＩＳハンドラを使用して実装され、この場合、このシステム管理機能は他のゴシップ・モンガの機能をオーバライドできるという意味でスーパ・ゴシップ・モンガだと見なされる。あるいは、ノードの複数のクラスがサポートされるとき、クラスの識別子を認識し、かつ対応するノードがどのオペレーションにアクセスできるかを判断するように既存のＡＸＩＳハンドラを適合させることができる。例えば、「クラス０」ノード（すなわち、デフォルトのピア・ノード）は、クエリーを発行するとともに、自らの評判、横断パスなどを主張できるが、他の「クラスＮ」のノード（例えば、本明細書に記載のシステム・ノードなど）は、リンクベースおよびリポジトリの読取りおよび書込みが許されることもあり、それによってノードが維持するネットワーク・ビューを実質的に管理する。（追加のＡＸＩＳハンドラを使用してシステム管理機能を実装することに関する詳細情報は、図１９〜２２を参照されたい）

次に、リンクベースに格納されたコンテンツ・パスの議論に戻ると、本発明の好ましい実施形態によるリンクベースは、一時的コンポーネントと永続的なコンポーネントとからなる。一時的コンポーネントを本明細書では「リソース・セット（resource set）」と呼ぶ。また、永続的コンポーネントは横断パス定義の集合体である。リソース・セットは、図８のＸＭＬドキュメント６００によって例示される。このリソース・セットはXLinkロケータ・リンクの集合体として定義される。これらのリンクのうちのあるグループは、現在のノードが知っているあらゆるノードに対する、動的に割り当てられたネットワーク・アドレスと永続的LBuuid値との間のマッピングを定義するために使用される。これらのリンクは＜node＞要素として指定される。別のグループは、ダウンロードされたコンテンツの記述をそのコンテンツが現在存在するローカル・コンテンツ・リポジトリの中のロケーションにマッピングするリンクを定義するために使用される。これらのリンクは＜content＞要素として指定される。

リンクベース・リソース・セットは、好ましくはメモリ内テーブルとして記憶されマッピングの高速検索を可能にする。したがって、あるノードがあるピア・ノードと対話したい場合、そのノードはこのテーブルを調べてピア・ノードの現在のアドレスを見つけることができる。リソース・セットを格納するドキュメントのルート要素は＜ResourceSet＞であり、その要素は拡張XLinkとして定義される（６０５の「type」属性参照）。

図８に示したように、最初の３つの要素６１０、６３０、６４５は＜node＞要素であり、それらの要素は新しく解決されたネットワーク・エンドポイント（すなわちＵＲＬ）と永続的リンクベースＩＤの間のマッピングを定義する。＜node＞要素の「href」属性は新しいエンドポイントを識別し、「role」属性は永続LBuuidを識別する。第４の要素６６０は＜content＞要素であり、コンテンツ・リソースを指定し、ピア・ネットワークからダウンロードしたローカル・コンテンツを識別する。＜content＞要素の「href」属性はコンテンツの現在のストレージ・ロケーションを識別し、「role」属性は永続ストレージ・ロケーション識別子を識別する。

各＜node＞要素はlocator XLink（例えば、６１５の「type」属性参照）であり、その「href」属性はリンクベースを維持するノードのネットワーク・エンドポイントを示す。またそのリンクベースは「role」属性の値に等しいＩＤを有する。例えば、「href」属性６２０は値「http://9.56.34.12/soap/rpcrouter」を有する。要素６１５のマッピングによると、このURLは、永続的LBuuid「9.37.43.2-05/04/01-12:02:05:37-NetZero.net」を有するリンクベースを管理するノードを表す。第1の要素６１０は（「local」属性を有し、その値が「true」に設定されている）ローカル・ノードに関する。一方、他の要素６３０、６４５は（「local」属性を有し、その値が「false」に設定されている）リモート・ノードに関する。

＜content＞要素６６０もまたlocator XLinkである。このマッピングの「href」属性６６５は、ストレージ・ロケーション「file://usr/awesley/etc/downloads/purchase_order123-4567-890.xml」が現在「purchase_order 123-4567-890.xml」で識別されるローカル・コンテンツを格納するために使用されていることを指示する（「role」属性６７０参照）。

リンクベース（すなわち、横断パス定義）の永続的コンポーネントは、リソース・セット内の、あるノードから他のノードへの特定のコンテンツ・リソースの横断パスを示すアークの集合体によって表される。そこでは、ノードはそれぞれのリンクベースID(すなわちLBuuid)値によって識別される。

次に図9を参照すると、横断パス定義７００の例が示されている。この例は、コンテンツ・リソースがＰ２Ｐネットワークに入ってから通過したパスを追跡するために有向グラフがどのように使用されるかを示す。横断パスは＜traversalPath＞要素７０５を使用して指定される。例の中の要素７１０および７３５によって表される１つまたは複数の＜arc＞要素は、「type」属性として「arc」を有するXLink要素である。これらの「arc」属性値は、あるノードから他のノードへのコンテンツの動きを指定する。ArcXLink要素はリソースおよびロケータ・ノードの役割（role）を使用する。ロケータ・ノードは、図８に示したように、リソース・セット中で定義される。また、リソース・ノードは、図９の＜arc＞ノードの「resource」属性を使用して識別される。次に、これを＜ark＞リンク７１０で始まるパスを参照して説明する。この場合は、７２５で「purchase_order123-4567-890.xml」（図８の要素６７０によれば、ロケーション「file://usr/awesley/etc/downloads/purchase_order123-4567-890.xml」に現在格納されており、顧客123-4567-890の注文書を表す）として識別されるコンテンツが、「12.37.43.5-03/03/01-08:35:13:04-MindSpring.com」リンクベース（「from」属性７２０の値を参照のこと）を管理するノードによって生成された（または、少なくともそこでネットワークに入った）ことを指定する。次いで「total」属性７２５の値は、このコンテンツが
「12.37.43.5-03/02/01-03:45:23:02-MindSpring.com」リンクベースを管理するノードによってダウンロードされたことを示している。

＜arc＞ノード７３５に関して続けると、「resource」属性７５０の値は「resource」属性７３０の値と同じであり、「from」属性７４０は以前の＜arc＞要素７１０の「to」属性７２５と同じ値を有する。このことは、同じコンテンツの異なる横断であることを示している。したがって、最後の「to」属性７５０は、このコンテンツが現在のノードによってダウンロードされたことを示している。７５０で識別されたリンクベースを読み取るアプリケーションが、７５０で指定されたコンテンツにアクセスしようとする場合、リソース・セットで定義された＜content＞XLinkを活用してそれを実施できる。参照番号６６０を参照すると、対応する＜content＞要素が定義されている。「resource」属性７５０の値を「role」属性６７０の値に一致させることによって、この＜content＞要素６６０がリソース・セットから選択され、次いでその要素の「href」属性を使用することによってそのコンテンツの実際のロケーションが見つけられる。したがって、一般の場合には、横断パス定義中の＜arc＞要素によって表される永続アークは、リソース・セット中の＜content＞要素の「resource」属性値および「role」属性値によってリンクベースを接続する。ここで、この＜content＞要素は永続コンテンツ・リソースのロケーションを提供する。

本発明の好ましい実施形態では、ここでは７つのステージを有するものとして記述されているブートストラップ・フローを使用して、ロード時にネットワーク上のすべてのノード（システム・ノードが実装されているときは、それを含む）を初期化する。次に、図１０を参照してこのフローを説明する。最初のステージ（ブロック８００）では、対象となるノードがそれ自体のＩＰアドレスを解決する。このノードが静的ＩＰアドレスを有していないと想定すると、好ましくはこのために従来技術の動的アドレス割当て技術（「ＤＨＣＰ（Dynamic Host Configuration Protocol）」、あるいはＡｕｔｏＩＰプロトコルなど）が使用される（ノードが静的ＩＰアドレスを有する場合は、このステージは省ける）。

第２ステージの前段階として、このノードがすでに本明細書で開示された形のLBuuidを有しているかどうかの判断が行われる（ブロック８１０）。この判断の結果がＮｏの場合は、第２ステージでノードのリンクベースのためのLBuuidが生成される（ブロック８２０）。このＮｏの結果は、ピア・ノードを最初に呼び出したときに発生する。このときは、リンクベースも初期化しなければならない。このステージで生成されるLBuuidは、そのノードのリンクベースのＵＵＩＤとなる。この場合、LBuuidは以下の形となる。
LBuuid = f (current_IP_Address,current_Date, current_Time, a)

好ましくは、パラメータ「a」は、先に説明したように、ＩＰアドレスの提供元のインジケータ（例えば、そのドメイン・ネーム）である。あるいは、「a」は従来技術のＵＵＩＤで使用されるパラメータであってもよく、その場合は乱数が使用される。どのようなＵＵＩＤ生成アルゴリズムを使用してもよいが、上述のように責任能力およびトラッキングを考慮すると、生成された値はリンクベースをその所有者までたどり、それによってコンテンツ・リソースをその生成元（およびそれをダウンロードしたピア・ノード）まで追跡する能力を提供する形式のものであることが好ましい。

リンクベースを初期化するとき、そのノードのローカル・コンテンツがネットワークをどのように横断したかを表す１組のアークが生成される（図９参照。そこでは、いくつかの例が論じられている）。

ノードのリンクベースにLBuuidが使用できるようになると、第３のステージでそのノードから「アライブ（alive）」メッセージのブロードキャストが始まる（ブロック８３０）。アライブ・メッセージはネットワーク上でのノードの存在を知らせる。本発明の好ましい実施形態では、アライブ・メッセージはＨＴＴＭＵ上のＳＯＡＰを使用する。ＨＴＴＭＵはＨＴＴＰのＵＤＰマルチキャストベース・バージョンであり、それを用いるとサブネット上のすべてのノードにアライブ・メッセージを送ることができる。アライブ・メッセージの例を図１１に示す。この図では、＜notification＞要素９０５は、「alive」に設定された「type」属性９１０を有する。好ましい実施形態によれば、アライブ・メッセージはまた、そのノードのリンクベースのLBuuid値（９２５の＜linkBaseID＞要素参照）、およびそのノード自体の評判に関するそのノードのバージョンへの参照を指定する（９３０の＜reputationRef＞要素参照）。評判情報は、図９では「href」属性９３５によって識別される、ドキュメントへの単純なリンクによって提供されるものとして示されている。この属性の値は、ノードの評判情報を永続させるＵＲＬを提供する。したがって、アライブ・メッセージは、ピア・ノードに送信ノードの永続識別子およびその評判のロケーションをどのように見つけるかを知らせる。アライブ・メッセージはまた、好ましくは、応答メッセージのためのコールバック・アドレス（「callback」属性９２０参照）を指示する、相手ノードの現在のＩＰアドレスを提供するコール・バック情報、および以下の１つを指定する他の属性９１５を含む。

１）ＵＤＤＩレジストリを指す照会（inquiry）ＵＲＩ（UniformResource Indicator）、およびこのノードから使用可能なファイル共用サービスについての結合キー。したがって、ＵＤＤＩレジストリでＷｅｂサ−ビス・モデルを使用するとき、このオプションのアライブ・メッセージは、このサービスについての公開（publish）および照会ＡＰＩ（ApplicationProgramming Interface）を保持するレジストリ、およびこのファイル共用システムについての結合キーを識別する。

２）ＷＳＩＬ（Web Services Inspection Language）参照など、ノードのファイル共用サービスを見つける何らかの非ＵＤＤＩ（NON-UDDI）による方法。ＷＳＩＬは、利用可能なサービスを提供するサイトを調査するのを助け、調査に関連した情報をどのように消費のために利用可能にすべきかを指示する１組のルールを指定するように設計された記法である。ＷＳＩＬは、ＩＢＭおよびマイクロソフトによって定義され、ＩＢＭの「ＡＤＳ」およびマイクロソフトの「ＤＩＳＣＯ」と呼ばれる初期の活動で見つけられた概念を統合したものである。（ＷＳＩＬに関する詳細情報については、ＩＢＭがインターネット上のhttp://www-106.ibm.com/developerworks/library/ws-wsilspec.htmlに提供している、Keith Ballingerらによる「Web Services Inspection Language (WS-Inspection) 1.0, (November 2001)」を参照されたい。）

図１１の例では、第２のオプションが選択されており、したがって属性９１５は、ＷＳＩＬ情報が格納されているＵＲＬを指定する「wsil」属性である。

（ブロック８４０で表される）第４ステージに続いて、ノードは、ブロック８３０で送信されたアライブ・メッセージを受信したピアによって送信されるはずの、ＨＴＴＰ応答上のＳＯＡＰをリスン（listen）する。好ましい実施形態によれば、これら各リモート・ノードからの応答メッセージもまたアライブ・メッセージであり、リモート・ピアのLBuuid、およびリモート・ノードの自己管理による評判情報をどこで見つけるかを識別するＵＲＬを指定する。先に述べたように、ノードの評判は、そのノードがクエリーの処理にどの程度成功するかを表す評価値を含む。（図５および６に関連して論じたように、評価値はそのノードのクエリーのすべてについて表すことも、クエリー固有の値を提供することもできる。）

ローカル（受信）・ノードが、リモート・ノードの評判についてのローカル・ノード自体のバージョンを有している場合、好ましくはこの２つの評判は併合され、ローカル・ノードが知っているリモート・ノード（すなわち、ローカル・ノードのリソース・セット内のリモート・ノード）を表すためにローカル・ノードが生成したローカル・レポジトリ（メモリ内テーブルなど）に記憶される。好ましい実施形態によれば、リモート・ノードに関するローカル・ノードのビューが、その評判に関するリモート・ノードのビューと異なっているときは、このマージ操作は、ローカル・ノードの情報の上にリモート・ノードからの入力をコピーすることを含む。（ローカル・ノードがある期間ネットワークを離れ、その間にリモート・ノードの評判が改訂されたとき、あるいは、ローカル・ノードが他の理由でリモート・ノードの活動の何らかの伝搬を逃し、そのリモート・ノードについての知識において遅れをとった可能性があるとき、この方法が適切なこともある）。しかし、ローカル・ノードがそのリモート・ノードを悪意のあるノードだと識別していた場合には、好ましくは、（通常）ローカル・ノードはリモート・ノードの評判に関する着信ビューを無視する。本発明の範囲を逸脱することなく、リモート・ノードに対するローカルの評価値を導き出す他の技術を使用することができる。例えば、ローカルのビューとリモート・ノードのビューを平均化する方法や、外捜（例えば、他のノードの対話について、ローカル・ノードが知っていること、および知らないことを組み込む）などである。

システムレベルのゴシップ・モンガが定義され、ピア・ノードが維持するレポジトリに評判情報を書き込む許可を有するとき、ローカルのゴシップ・モンガが有するリモート・ノードの評判に関するビューは、システムレベルのゴシップ・モンガによって上書きされていることがある。

（ブロック８５０で表される）ステージ５において、ローカル・ノードは本明細書で「スパイ」メッセージと呼ぶものを発行する。好ましくは、このスパイ・メッセージは、ローカル・ノードの最初の「アライブ」要求に（ブロック８４０で）応答したすべてのピアに直接送信され、基本的に、各ピアにそのピアが知っているネットワーク上の各ノードにアライブ要求を伝搬するよう要求する。このとき、マルチホーム・ピア（すなわち、複数のネットワーク接続をサポートするピア）は、現在のサブネットの外部にあるピアにアライブ要求を転送することがある。次いで、これらのピア・ノードはそのピア自体のアライブ応答メッセージで応答するので、ローカル・ノードは動的にＰ２Ｐネットワークのトポロジーを知ることができる。ローカル・ノードは、返ってきたアライブ・メッセージから集められた情報を使用してＵＲＬマッピングへのLBuuidを（ローカル・ノードのリソース・セットの中に）構築し、その結果、ピア・ノードのＩＤを解決できるようになる。

スパイ・メッセージがオプションだと考えられていること、およびスパイ・メッセージの伝達の深さ（depth）は、好ましくは必要とするアプリケーションによって決まることに留意されたい。スパイ・メッセージは、オプションで深さ属性を持つことができる。深さ属性は、連続する転送の最大数を決定するものである。スパイ・メッセージは、好ましくはスパイ・メッセージの再帰処理を避けるためにメッセージのＵＵＩＤを提供する。再帰処理は無限ループのきっかけとなる。

図１２は、ＳＯＡＰメッセージ１０００内にどのようにスパイ・メッセージ１００５を組み込めるかを示す例である。この例では、「ＵＵＩＤ」属性１０１０は、再帰転送を避けるように指定されている。（例の中の「[LBuuid]」シンタックスは、ローカル・ノードの実際のLBuuidで置き換えられる。）

図１０の議論に戻って、（ブロック８６０で表される）ステージ６において、ローカル・ノードは、それ自体のアライブ・メッセージの応答（および実装されているときには、スパイ・メッセージの応答）として受信したアライブ・メッセージを使用して、ネットワーク・エンドポイントをリモート・ノードのリンクベースＩＤにマッピングするメモリ内テーブル・エントリを更新する。これらのエントリの集合体は、図８の例に示したように、ローカルのリンクベースのリソース・セット中に＜node＞要素を含む。更新プロセスに、必要に応じてＵＲＬの更新が含まれるので、メモリ内テーブルで、各LBuuidに関するノードの現在のロケーションを識別できる。（リソース・セットはＸＭＬドキュメントであり、好ましくは、それが「ＤＯＭ（DocumentObject Model）」ツリーを使用して記憶されるので、新しいエントリの追加が新しいＤＯＭツリー・ノードの作成に対応することに留意されたい。ＸＭＬシンタックス要素からＤＯＭツリー・ノードを作成する技術は、当技術分野では周知である。）

ノードは、スパイ・メッセージに応答してアライブ・メッセージを返したリモート・ノードに関して、ローカルに格納された評判情報を更新することもできる。ブロック８４０の議論を参照されたい。そこでの議論では、この評判の更新が、このノード自体のアライブ・メッセージに応答したノードに関して説明してある。

最後に、ステージ７（ブロック８７０）で、ローカル・ノードは、好ましくは予約されたＨＴＴＰＭＵチャネル上で、他のピア・ノードからのアライブ・メッセージをリスンし、それに応答してアライブ・メッセージを送信する（これは、ブロック８４０に関して説明したアライブ応答メッセージに類似したものである）。このリスニング・プロセスは好ましくは常時オンであり、それによりノードは、Ｐ２Ｐネットワーク上のピアについての知識を維持することができ、そのノードの（LBuuidとURLsの相互関係をキャッシュする）リソース・セットを、したがってローカルに格納されたピアの評判情報を改訂することが可能になる。

図１３は、ピアにコンテンツを要求したノードが使用できるフローを示すフローチャートである。このプロセスはブロック１１００で始まり、そこでユーザは関心事についてのクエリーを作成する。クエリーは、好ましくはクエリー・ストリングとして表現される。それは例えば、ユーザが入力したもの、ユーザがメニューから選択したもの、ユーザが識別したファイルから読み込んだものなどである。一般にユーザは人間であるが、あるいはプログラムによる処理でクエリーを判断し、クエリー・ストリングを供給することもできる。例えば、顧客番号123-4567-890の注文書を要求するためには、前の例で示したように、クエリー・ストリングは「purchase_order123-4567-890」の形にフォーマットされる。

ブロック１１１０で、好ましくは最適化プロセスが実施される。このプロセスによって、ノードはピア・ノードの評判を評価して、本明細書で「ブロードキャスト層（broadcast tiers）」と呼ぶものを解決する。これらのブロードキャスト層はクエリー解決への階層的アプローチを指定し、各層におけるピア・ノードが、そのクエリーに答える永続的能力をベースに選択される。この階層的アプローチでは、ネットワークを横断するクエリー要求メッセージおよび応答メッセージの数を削減するよう努める。好ましくは、パターン・マッチング・アプローチを使用し、各ノードの評判に＜QuerySet＞を使用して、特定のクエリーにどのノードが答えることができるかを決定する。図５および６を参照されたい。例えば、特定のノードが４２０のシンタックスを使用して表される「purchase_order999-9999-999」クエリー・パターンに答えられない場合は、この特定のノードにその形のクエリーを送信するのは非効率的である。その代わりに、このクエリーをサポートすることを示す評判を有し、かつ比較的高い評価値を有するノードが、最初のブロードキャスト層として選択される。

このパターン・マッチング操作のオプションの機能強化として、サイト・サマリを活用できる。「サイト・サマリ」とはＲＤＦを使用して提供されるコンテンツ・シンジケーション技術（content syndication technique）のことであり、当技術分野では「ＲＳＳ」と呼ばれる。サイト・サマリは、特定のサイトから使用可能なコンテンツ／サービスについて記述した、１組のコンテンツ記述（すなわち、ノードのクエリー・セット）を含むことができる。例えば、サイトに新たなコンテンツを加えるために１組の記述を変更するとき、ＲＳＳを使用したコンテンツのシンジケータ（syndicator）に変更済みの記述を積極的にプッシュすることができる。ノードはまず、先に論じたように、アライブ・メッセージによって互いの評判について知る。ノードが他のノードとの対話に参加すると、通常（ノードの評価値やクエリー・セットの可能性など）ノードの評判は変わる。あるノードが他のノードと頻繁には対話しないため、互いの評判についてのそれらのノードのビューが期限切れになることが起こり得る。したがって、有利にはサイト・サマリを使用してネットワークのノード間で周期的に評判情報を伝える。

ブロック１１２０で、要求が、識別された「プライオリティ・プロバイダ（priorityproviders）」に送信される。好ましくは、クエリーは指示された（ＨＴＴＰ上の）「ブロードキャスト」アプローチで送信され、その場合、結果セット（resultset）を使用して各ターゲット・ノードの現在のＩＰアドレスが決定される。（ブロードキャスト層を使用しない場合には、クエリー・メッセージのターゲットは、例えばリソース・セットに示されるすべてのピアにメッセージを送信するなど他の方法で決定される）。ＳＯＡＰメッセージ１２００で実施されるクエリーの例を図１４に示す。この例に示したように、＜query＞タグ１２０５は、その値１２１０としてクエリーのテキスト・ストリング表現を有しており、この場合入力パラメータ値として対象のアカウント番号（「123-4567-890」）が提供されている。（このクエリーが、受信ピアによって一種の調査と解釈されることに留意されたい。すなわち、それによって受信ピアが実際にこのクエリーをサポートするかどうか、およびそのクエリーに答えることについてのそれらの現在の評価値として何を主張するかを判断するために問合せを受けていることになる。１１２０で送信されるメッセージは、実際のコンテンツ要求ではない。）

第１の層でどのノードからも満足できる応答が受信できなかった場合（すなわち、問合せを受けたピアのどれもが受け入れられる評価値でそのクエリーに応えられない場合）は、制御はブロック１１１０に戻り、そこで次善のピアの組からなる第２の層が識別される。（好ましくは、時間間隔を使用して問合せを受けたピアが応答するのを待つための時間を制限する。時間間隔は設定可能なこともある。）この第２層は、好ましくは、やはりこのクエリーをサポートするが、第１層より低い評価値を有するピアを含む。次いで、ブロック１１２０で要求が再び送信される。

様々な層のピアにクエリー要求を送信するこのプロセスは、悪意がないピア・ノードのすべてに問合せを送るまで、あるいはそのクエリー要求についての満足できる応答を受信するまで続けられる。次いで、制御はブロック１１３０に至る。

場合によっては、そのクエリーに対するサポートを指示していないノードにもクエリー要求を送信することが結局は生産的となることがあることに留意されたい。ネットワークにアド・ホックな性質があるために、ローカルのノードは通常、そのすべてのピアの（そのクエリー・セットも含めた）評判についての最新情報を常に知っている訳ではないからである。したがって、たとえローカルのノードの情報で、そのピアがよい候補であると示されなくても、要求したクエリーへの応答をうまくやり遂げるピア・ノードが見つかる可能性がある。

再び図１３に戻って、問合せを受けた１つまたは複数のピアが、実際にそのクエリーをサポートすると答えたと想定すると、ブロック１１３０で、ローカルのゴシップ・モンガ・ハンドラが応答したノードからのメタデータを処理する。すなわち、リモート・ピアからの応答メッセージは、リモート・ノードのコンテンツ・リポジトリ内で最も良くその要求を満たすコンテンツを記載するメタデータを含むことになる。また、この応答メッセージの情報は、好ましくはブロック１１４０での処理のためにローカルにキャッシュされる。図１５の、ＳＯＡＰ応答メッセージ１３００の例を参照すると、この場合はＳＯＡＰヘッダ中の＜content-meta-data＞タグ１３０５がコンテンツ・メタデータのロケーションを指すsimpleのXLink要素を提供する。この例では、「href」属性１３１０の値が、「purchase_order_123-4567-890.rdf」として識別される情報が＜queryResponse＞要素の第１の子要素としてここに組み込まれることを示している（１３１５のポインタ・シンタックスを参照のこと）。＜queryResponse＞要素は１３２０で示されており、応答ノードからのコンテンツ・メタデータ（１３２５参照）のＲＤＦ仕様を含む。この例に示したように、応答側は、それが返すことになるドキュメントの名前（１３３０の「about」属性値参照）、作成の日付と時間および作成者の名前（＜Creator＞要素１３３５参照）、ならびに指名されたドキュメントに関する概要（＜synopsis＞要素１３４０参照）を示す。

次に、応答ノードの集合体からのコンテンツ・メタデータがユーザによって評価される。先に述べたように、このユーザ評価は、人間またはプログラム処理によって実施される。ユーザが人間のとき、＜synopsis＞要素１３４０の値は、好ましくはＧＵＩ（graphical user interface）パネル上に表示される。また、必要なら、＜Description＞要素１３２５の他の値も表示できる。コンテンツ・メタデータを解析した後、ユーザは、どのピアがそのクエリーを最も良く満たすかのユーザ選択を識別し、次いでコンテンツの要求をＳＯＡＰＰＯＳＴ要求として発行する（ブロック１１４０）。

図１６に、好ましい実施形態による、コンテンツ要求を送信するためのＳＯＡＰＰＯＳＴ要求１４００の例を示す。この例では、ＳＯＡＰエンベロープは＜getContent＞要素１４０５を含み、この要素は「ＩＤ」属性１４１０の値として（図１４のクエリー要求メッセージの形で送信された）ユーザのコンテンツ要求のテキストを有する。あるいは、応答メッセージの「about」属性１３３０で受信した値を、「ＩＤ」属性１４１０の値として使用することもできる。

ピア・ノードは、好ましくは「multipart ＭＩＭＥ（multipartMulti-purpose Internet Mail Extensions）」構造でＳＯＡＰ応答メッセージとしてエンコードされた要求コンテンツを返す。要求コンテンツを受信すると、受信ノードはそのコンテンツを処理する（ブロック１１６０）。Ｗ３Ｃによって公布された、「SOAPMessages with Attachments, Ｗ３Ｃ覚書２０００年１２月１１日」と題する仕様書（http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211を参照のこと）では、添付ファイルを送信するためにmultipart ＭＩＭＥ構造を使用して、ＳＯＡＰメッセージを１つまたは複数のネイティブ形式の添付に関連づける標準の方法を記載している。ＳＯＡＰ応答メッセージの例は図１７の１５００で示され、そこではコンテンツ要求への応答が、参照番号１５２０によって表されるような形でＭＩＭＥ添付が指定されている。好ましい実施形態によると、ＳＯＡＰ応答はまた、このコンテンツのピア・ネットワークに入ってからの横断パス（１５０５参照）および要求を満たすリモート・ピア（１５１０参照）を指示し、好ましくはそれ自体の評判についてのそれ自体の表示を識別するＵＲＬも提供するヘッダを有する。

ブロック１１５０で実施される処理は、（必要なら、最初に復号ハンドラを使用してメッセージを復号した後に）横断パスおよびリモートの評判情報を抽出することを含む。

次に、デジタル署名ハンドラはこのメッセージ上のすべてのデジタル署名を検証する（ブロック１１６０）。送信者の認証に失敗するか、あるいはメッセージの完全性チェックに失敗した場合、ピアの評判に悪影響が及び、好ましくはそのピア・ノードが主張する評判は無視される。（あるいは、特定の実装においては、このような状況下でのローカル・バージョンのそのピア・ノードに関する評判を下げるのが望ましいであろう。）

コンテンツ要求１４００が発行されたすべてのピア・ノードに関するローカルに維持された評判は、そのクエリーに応えることに関する評判の成功率を反映するように更新される（ブロック１１７０）。好ましくは、この更新は「totalQueries」属性の値をインクリメントすること、成功カウントを特定の応答者に合わせて適宜インクリメントするまたはしないこと、続いて評価値を再計算することを含む。好ましい実施形態では、評価値は成功カウントをtotalQueries値で割ることによって計算される。次いで、これらの更新値はローカルに記憶される。代替実施形態では、評価値は他の方法で計算することができる。

ブロック１１８０において、このピアが認証に成功したと想定すると、そのピアの応答メッセージから得られた横断パス情報（図１７のドキュメント１５００の参照番号１５０５を参照のこと）はローカルに記憶され、新たに受信するコンテンツに関連づけられる。（一例として、図８のリソース・セット６００の＜content＞要素６６０を参照のこと）。さらに、横断パスは、有向グラフ中の最新のターゲット・ノードとして現在のノードを含むように（すなわち、図９の７３５で示される形の新しい＜arc＞要素を生成することによって）拡張される。

最後に、受信したコンテンツがアプリケーションに提供され（ブロック１１９０）、次いでアプリケーションはそれ固有の方法でそのコンテンツを処理する。次いで、このコンテンツ要求についての、図１３の要求元フローは終了する。

図１３に示された処理のオプションの拡張として、ユーザは、そのコンテンツが最終的にユーザの要求を満足させたかどうかについてのフィードバックを提供できること、またそれを提供ノードの評価値に反映させることができることに留意されたい。

ここで図１８に戻って、（リモートの）ピア・ノードがコンテンツ要求を評価し応答するための提供元フローについての好ましい実施形態について説明する。このプロセスはブロック１６００で始まり、そこでピア・ノードはクエリーを受信し、受信したクエリーからクエリー・ストリングを抽出する。

ブロック１６１０において、ピア・ノードはパターン・マッチング操作を実施して抽出されたクエリー・ストリングをそれ自体のコンテンツ・メタデータとマッチさせ、このクエリーに答えることができるかどうかを判断する。（図５および６を参照のこと。この場合は、例示の＜QuerySet＞要素が、特定のノードがサポートできるクエリーを識別する）。先に、クエリー・メッセージのターゲット・ノード識別に関して説明したように、本発明の特定の実装では、サイト・サマリを使用してこのパターン・マッチング・プロセスを迅速に処理できることに留意されたい。

このピア・ノードが要求されたクエリーを実行できる場合には、そのノードは、（要求元ノードが潜在的コンテンツ提供元からの応答を受信することについて論じた）ブロック１１３０に関して先に説明した形式のＳＯＡＰ応答メッセージを生成し、そのメッセージを要求元に返す（ブロック１６２０）。上で論じたように、この応答メッセージはＳＯＡＰエンベロープを含み、そのエンベロープは、このピア・ノードがクエリー要求を満たすために提供するコンテンツを記載するメタデータを有するＲＤＦメッセージを含む。

ある場合には、ブロック１６２０で送信された応答メッセージが複数のＲＤＦメッセージを含む可能性があることに留意されたい。これは、特定のノードがクエリーを複数の方法でサポートできるときに生じる。さらに、（ブロック１１２０に関連して説明したように送信された）ＳＯＡＰヘッダ１２００を使用して指定されたクエリー要求が、（例えば、複数の＜query＞タグ１２０５としてフォーマットされた）複数のクエリー・パターンを含むことも起こり得る。応答は、この場合も複数のＲＤＦメッセージを含むことができる。

応答メッセージを発行した後、提供元ノードは要求元ノードからのコンテンツ要求の着信をリスンする（ブロック１６３０）。ブロック１６１０で受信した「このクエリーがサポートできますか」というメッセージではなく、ここで待つコンテンツ要求は「このクエリーを実施してください」という要求である。好ましい実施形態によれば、そのノードは設定された時間間隔の間、コンテンツ要求の着信をリスンする。待っている要求を受信することなく時間が経過した場合は、このコンテンツ要求についての処理は完了したものと見なされる。したがって制御はブロック１６００に戻り、次の「このクエリーをサポートできますか」の要求メッセージを待つものとして示される。（明らかなことだが、好ましくはノードが着信要求を常時監視できるように別個のスレッドが使用される。）一方、待っている「このクエリーを実施してください」の要求メッセージを受信した場合には、処理はブロック１６３０から１６４０に移る。

ブロック１６４０では、要求されたクエリーについての処理を呼び出し、結果を（図１７に関して先に説明したような）multipart ＭＩＭＥ添付を使用したＳＯＡＰ応答メッセージとしてフォーマットする。

ブロック１６５０で、提供元ノードのパス・インティメイタは、アウトバウンド・メッセージのＳＯＡＰヘッダとしてコンテンツ横断パスへの参照を先頭に付加する。図１７を参照されたい。この場合は、ＳＯＡＰヘッダ１５０５が、図３に示したような横断パス定義情報を提供する。（先に説明したように、ヘッダ・ドキュメント３００の＜traversalPathRef＞タグ３０５が、ピア・ネットワーク内の指定されたコンテンツの横断パスを記憶するリンクセットへの参照３１０を提供する。）本発明は、（例えば、このノードによって特定の日付および時間に生成された、あるいはこのノードによって特定の日付および時間に転送されたなど、必要に応じて）ローカルに記憶されたコンテンツ横断パス定義を更新する。

次いで、提供元ノードのゴシップ・モンガはノードのローカルの評判を更新し（ブロック１６６０）、更新された情報を格納し、アウトバウンド・メッセージのＳＯＡＰヘッダに評判情報を組み込む。（再び図１７を参照されたい。そこではＳＯＡＰヘッダ１５１０が、図４に示したような応答ノードのバージョンの評判を含む。）その評判を更新するとき、「このクエリーを実施してください」の要求を受信することなく時間間隔が切れた場合には、提供元ノードは、好ましくはその対話をそのコンテンツ要求を満たすことに失敗したものとしてカウントする。その要求を受信した場合には、提供元ノードは好ましくはこの対話を成功としてカウントする。成功または失敗の結果を考慮に入れ、先に図１３のブロック１１７０に関して論じたように、「stature」属性が再計算される。（失敗の処理は、ブロック１６３０のＮＯの結果として実施されることに留意されたい。）

次いで、生成された応答メッセージは、（ＳＯＡＰヘッダおよび添付も含めて）デジタル署名ハンドラによってデジタル署名される（ブロック１６７０）。次に、応答メッセージが要求元に返される。

図１９〜２１は、本明細書で説明してきたオプションのシステム管理機能で使用できるヘッダの例を示す。好ましくは、追加のＡＸＩＳハンドラをノードに提供してそれを管理する。また、管理「権限」を有する１つまたは複数のノードが管理情報を伝え、受信ノードのＡＸＩＳハンドラがそれを処理する。システム管理機能を提供する追加のＡＸＩＳハンドラを本明細書では「管理ハンドラ（Management handler）」と呼ぶ。本発明の好ましい実施形態では、集中化された管理ノードがないので、管理ノード（例えば、何らかの方法で他のピア・ノードに指示を出すノード）として機能できるノードは、好ましくは比較的高い評価値レベルを有するノードである。

本明細書で開示する発展的信頼モデルにより、どのようなノードも潜在的に管理評価値を達成できる可能性があり、したがってシステム・ノードとして動作できる可能性がある。したがって、必要なら、ネットワーク上のすべてのノード、あるいは複数のノードがシステム管理機能を展開できる。システム・ノードの管理コードは、好ましくは認証局によって認証される。その結果、そのコードが発行したメッセージを他のノードが信頼できるようになる。すなわち、そのメッセージ上のデジタル署名により、受信ノードの管理ハンドラはメッセージのソースを確認することができるようになる。

好ましい実施形態では、管理ハンドラが２つの新たなヘッダ・タイプをサポートする。それらを、本明細書では「ピーク（peek）」および「アクセス（access）」と呼ぶ。ピーク・ヘッダを使用して、そのトラフィックがシステム・ノードに監視されていることをノードに知らせることができる。アクセス・ヘッダを使用して、ノードのリンクベース、評判リポジトリ、またはコンテンツ・リポジトリを読み書きすることができる。

図１９はピーク・ヘッダの一例を示す。システム・ノードがピーク・メッセージを送信して、受信ノードの管理ハンドラにＳＯＡＰメッセージを指定したシステム・ノードに複写するよう知らせる。したがって、要素１７００として示されるヘッダは、メッセージの送信元（すなわち、システム・ノード）を識別するアドレス１７１０を指定するsimpleのXLinkである。次に、受信ノードはこのアドレスを使用してそのＳＯＡＰトラフィックを複写する。オプションで、＜peek＞要素で属性を指定して、複写されるＳＯＡＰメッセージのカテゴリを受信側に知らせることもできる。デフォルトでは、好ましくはすべてのＳＯＡＰメッセージが複写されることになっている。

図２０および２１にアクセス・コマンドを示す。上記のように、アクセス・コマンドは、受信ノードのシステム・リソースにアクセスするために使用できる。コマンド・フォーマットは、「command」属性の対応する値によってwriteオペレーションまたはreadオペレーションのいずれかに指定できる。図２０の＜access＞ヘッダ１７３０の例はwriteオペレーションを示しているが、ここでは、システム・ノードが受信ノードの管理ハンドラに、カプセル化された評判参照１７５０に新しい評判情報が提供されていることを教示している。次に、管理ハンドラは、同じ場所にあるゴシップ・モンガ・ハンドラにこの情報を転送することができる。この例では、評判参照１７５０で、主張された評判情報を見つけることができる評判レポジトリの位置を識別する。受信ノードは、評判のコピーを取り出し、ローカルに格納することを選択することも、あるいは、リンクを格納し、情報が必要なときにレポジトリの評判にアクセスすることを選択することもできる。あるいは、シンタックス・フォーム（図示せず）を使用することによって、評判そのものを（ピア・ノード、その主張された評価値、およびオプションでそのクエリー・セットのLBuuidを識別するための属性を含む）ヘッダ内にカプセル化することができる。「href」属性１７４０はシステム・ノードのアドレスを提供し、それによって受信ノードがヘッダの送信元を識別できるようにする。

図２１の＜access＞ヘッダ１７６０の例は、readオペレーションを例示したものである。このコマンドは、システム・ノードがアクセスしようとするリンクベースを識別するための「linkBaseURI」属性１７８０を提供する。この例では、この属性の値がxpointer表記を使用して、＜content＞要素を＜ResourceSet＞ドキュメント内に置くべきであることを示す。この場合は、例示のドキュメントが「http://9.56.34.12/linkbase/lb.xml」に格納されている。その代わりとして、評判レポジトリまたはコンテンツ・レポジトリにアクセスするための、アクセス・コマンド上に属性を提供することもできる。「href」属性１７７０はシステム・ノードのアドレスを提供し、それによって受信ノードは、ヘッダの送信元を識別すること、およびreadコマンドの場合には、要求された情報を返すことが可能になる。

好ましくは、受信ノードは送信元を確認するプロセスでシステム・ノードの評価値を確認して、その送信システム・ノードが管理機能を実施するのに十分な信頼を得ているかどうかを判断する。管理ハンドラによって追加されるデジタル署名は、好ましくはヘッダ・メッセージが対応するシステム・ノードから発信されたものであることを保証するために検証される。オプションで、受信ノードは、送信元のＩＤを確認するためにチャレンジ（challenge）を送信元に発行することもできる。このことは、図１９〜２１の例に示したように、送信システム・ノードを識別する「href」属性を使用することによって容易に実施できる。

次に、図２２を参照すると、システム・ノードがシステム管理機能（例えば、ピア・コミュニティの監視および管理）を実施するために実装できる管理フローが示されている。ブロック１８００で、システム・ノードはピーク・オペレーションを呼び出す。好ましくは、ノードがネットワークに参加したとき（このことは、先に図１０に関して説明したように、参加ノードの「alive」メッセージの発行によって検出される）、それらにピーク・ヘッダを送信する。

ピア・ノードがシステム・ノードにそれらのＳＯＡＰトラフィックを複写し始めると、システム・ノードはそのトラフィックを監視する（ブロック１８１０）。特に、システム・ノードは、好ましくは評判およびコンテンツのあらゆる送信を監視する。したがってシステム・ノードは、各ピア・ノードがそれ自体の評判を、それらの評判リポジトリへの参照を含めてどう主張しているかを観察することができる。また、システム・ノードは、特定のノードからのコンテンツが成功した対話を構成するものとして受け入れられているかどうかも観察できる。

ブロック１８２０では、システム・ノードは、セキュリティ・イベントを検出するための監視トラフィックを評価するものとして示されている。好ましくは、システム・ノードは、偽りの評判情報が主張されたとき、また汚染されたコンテンツが広められたときにもセキュリティ・イベントを起動する。例えば、あるノードが高い正の評価値を有すると主張しているが、多数のピアがこのノードからのコンテンツを拒否していることにシステム・ノードが気付いた場合、システム・ノードはその主張をしているノードを悪意のあるノードだと判断することができる。同様に、システム・ノードは、ピア・ノードが特定のコンテンツを拒否していることを検出し、そのコンテンツが汚染されていると判断することもできる。好ましくは、この場合も同様にセキュリティ・イベントが起動される。

検出されたセキュリティ・イベントが偽りの評判を含んでいる場合（ブロック１８３０参照）、システム・ノードでの管理フローはブロック１８４０に移り、そこで、システム・ノードはそのノードの評判にアクセスするためのアクセス・コマンドを発行する（好ましくは、writeオペレーションを使用して、受信ノードに評判についてのシステム・ノードのビューを上書きする）。システム・ノードがあるノードに、そのノード自体の評判を知らせることもできるし、他のピア・ノードの評判を知らせることもできることに留意されたい。評判リポジトリ内に予約領域を設けることができ（この予約領域に、悪意のあるノードが上書きすることはできない）、この予約領域にwriteオペレーションによって情報を書き込むこともできる。悪意のあるノードがリポジトリのこの領域に書き込んで、偽って高い評価値を設定するのを防ぐことができる。その後、あるノードがこの評判リポジトリにアクセスしたとき、好ましくは、そのノードは予約領域に記憶された情報を、その同じ評判に関する他のデータより優先するものと解釈する。あるいは、予約領域を使用しない場合には、システム・ノードがアクセス・ヘッダ上で送信する情報を、非予約ストレージに書き込むこともできる。（すでに説明したように、ピア・ノードが、評判参照の形で、あるいは評判情報を含むメッセージの形で、互いに評判情報を送り合うこともできることに留意されたい。）

ブロック１８５０でのテストによって、セキュリティ・イベントが汚染されたコンテンツに関係するものであったかどうかを判断する。関係していた場合には、処理はブロック１８６０に移り、そこでシステム・ノードは、あるピアに格納されているコンテンツが汚染されていると主張するアクセス・コマンドを発行する（例えば、横断パスを修正するために、リンクベース・データにアクセスし、上書きする）。リンクベースもまた予約領域を使用することができ、システム・ノードはそこにコンテンツ・パス横断情報を書き込むことができる。

アクセス・ヘッダ上の他の属性の使用に関して先に論じたように、特定の実装において必要なら、システム・ノードが、ノードのローカルに格納されたコンテンツを上書きするコマンドを発行できるようにすることもできる。コンテンツ・リポジトリに影響を与えるアクセス・コマンドの処理は、評判およびコンテンツ横断パスに影響を与えるコマンドについて説明した方法と類似の方法で実施できる。

セキュリティ・イベント処理が完了すると、制御はブロック１８１０に戻り、ピア・ノードのトラフィックのモニタを続行する。（明らかなことだが、セキュリティ処理は、好ましくは監視が中断されないように独立したスレッドで実施される。）

監視機能をセキュリティに関して説明してきたが、本発明の諸実装では、ピア・ノードのトラフィックを監視することによって集めた情報を他の目的に使用することもできる。他の使用の例には、フェイルオーバ（failover）および高可用性（high availability）のシナリオが含まれる。例えば、フェイルオーバ・シナリオでは、アクセス・コマンドを使用して、障害のあるノードへの参照をバックアップ・ノードへの参照で置き換えるか、あるいは障害を起こしたノードへの参照を削除することができる。これらの変更は、リソース・セットの障害ノードを識別し、そのノードのLBuuidを参照するエントリを置き換えるかまたは削除することによって行われる。高可用性シナリオでは、特定のピア・ノードが過負荷であること、あるいは他のノードのリソースが使用中であることをシステム・ノードが検出したとき、システム・ノードはアクセス・コマンドを使用して、そのコンテンツ（またはサービス）を参照するリンクベースを、そのコンテンツ（またはサービス）が代替の方法によって得られる別のノードにトラフィックがリダイレクトされるように修正することができる。

ここまで例証してきたように、本明細書に開示の技術により、管理されたピアツーピア・ネットワークのフレームワークが提供されるとともに、アド・ホック・コミュニティが形成されたとき、複数の呼出しに渡ってピア関係を維持し、その関係およびＩＤを再利用することが可能になる。上で論じたように、ピア・ノードは自由にネットワークに入り、出て行くことができる。また、本明細書に開示の技術を用いると、これらの一時的コミュニティのもとで、セキュリティ、管理、および他のシステムレベル機能を提供することが可能になる。開示の技術により、Ｐ２Ｐネットワークの一時的コミュニティを管理し、一時的コミュニティにおいてメッセージの完全性が保証できる、セキュアなトランザクションを交換することが可能になる。

マイクロソフト株式会社（Microsoft Corporation）のHailstormプロジェクト（「NetMy Services」とも呼ばれる）は、Ｐ２Ｐ技術と位置づけられてきた。しかし、そこでのＰ２Ｐサポートは、インスタント・メッセージに限られているようである。ＪＸＴＡなど、他の既存のＰ２Ｐネットワーキング製品は、前に論じたように、本明細書に開示の一時的コミュニティで用いられる機能を提供しない。

当業者なら理解するであろうが、本発明の実施形態は方法、システム、あるいはコンピュータ・プログラム製品として提供できる。したがって本発明は、全くのハードウェアによる実施形態、全くのソフトウェアによる実施形態、またはハードウェアおよびソフトウェアの態様を組み合わせた実施形態の形をとることができる。さらに本発明は、コンピュータが使できるプログラム・コードが書き込まれた、１つまたは複数のコンピュータが使用できる記憶媒体（例えば、ディスク記憶装置、ＣＤ−ＲＯＭ、光記憶装置などを含むが、これだけには限らない）で実施されたコンピュータ・プログラム製品の形をとることもできる。

好ましい実施形態を、本発明の実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品のフロー・ダイアグラムまたはブロック・ダイアグラムあるいはその両方に即して説明した。フロー・ダイアグラムまたはブロック・ダイアグラムあるいはその両方の各フローまたはブロックあるいはその両方、ならびにフロー・ダイアグラムまたはブロック・ダイアグラムあるいはその両方におけるフローまたはブロックあるいはその両方の組合せは、コンピュータ・プログラム命令として実装できることが理解されよう。これらのコンピュータ・プログラム命令を、汎用コンピュータ、専用コンピュータ、ならびにマシンを製造するための組込みプロセッサまたは他のプログラマブル・データ処理装置のプロセッサに提供して、コンピュータまたは他のプログラマブル・データ処理装置のプロセッサを介して実行される命令が、フロー・ダイアグラムのフローまたはブロック・ダイアグラムのブロックあるいはその両方に指定された機能を実現する手段を生成するようにすることができる。

これらのコンピュータ・プログラム命令は、コンピュータ可読のメモリ中に記憶することもでき、コンピュータまたは他のプログラマブル・データ処理装置に指示を出して特定の方式で機能させることもできる。その結果、コンピュータ可読のメモリ中に記憶された命令により、フロー・ダイアグラムのフローまたはブロック・ダイアグラムのブロックあるいはその両方に指定された機能を実施する命令手段を含む製造品の形に製造される。

コンピュータ・プログラム命令をコンピュータまたは他のプログラマブル・データ処理装置にロードして、一連の操作ステップがコンピュータまたは他のプログラマブル装置上で実施されるようにし、その結果、コンピュータまたは他のプログラマブル装置上で実行される命令が、フロー・ダイアグラムのフローまたはブロック・ダイアグラムのブロックあるいはその両方に指定された機能を実現するための諸ステップを提供するような、コンピュータ実施方式を生成することもできる。

本発明の好ましい実施形態について説明してきたが、本発明の基本的概念を知れば、当業者ならそれらの実施形態における追加の変形形態および修正形態を思い浮かべることができるはずである。好ましい実施形態をＷｅｂサービス・アプリケーションに則して説明したが、開示の技術が他のＰ２Ｐネットワーク環境においても使用できることに留意されたい。さらに本明細書では、好ましい実施形態をＳＯＡＰメッセージ、およびメッセージ・ヘッダ、ドキュメントなどに関する特定のシンタックスに則して説明したが、これは例示のためであり限定のためではない。すなわち、本発明の範囲を逸脱することなく、代替のメッセージ・フォーマットおよび代替のシンタックスを用いることもできる。さらに、本明細書では一時的ネットワークについて記載したが、ネットワーク・トポロジーが時間とともに安定化することは起こり得る。したがって、「一時的ネットワーク」という用語は、一時的なトポロジーをサポートするアーキテクチャを有するネットワークを意味するものと解釈できる。したがって、添付の特許請求の範囲は、好ましい実施形態、ならびに本発明の範囲に含まれるあらゆる変形形態および修正形態のどちらもを含むものと解釈すべきであることが意図される。

本発明の実装で利用できる、従来技術のＷｅｂサービス・スタックを示す図である。ネットワーク環境における構成要素の配置および相互接続の概略を含む、本発明の構成要素を示す図である。好ましい実施形態で、特定のコンテンツ・リソースの横断パスをどのように識別するかを説明するための「ＳＯＡＰ」（Simple Object Access Protocol）ヘッダの一例を示す図である。好ましい実施形態で、特定のノードの評判をどのように識別するかを説明するための「ＳＯＡＰ」ヘッダの一例を示す図である。好ましい実施形態および代替実施形態で、ノードの評判をノードのメタデータとしてどのように指定するかを説明するための「ＸＭＬ」（Extensible Markup Language）ドキュメントの例を示す図である。好ましい実施形態および代替実施形態で、ノードの評判をノードのメタデータとしてどのように指定するかを説明するための「ＸＭＬ」ドキュメントの例を示す図である。好ましい実施形態で、コンテンツのメタデータを使用してコンテンツのリソースをどのように記述するかを説明するためのＸＭＬドキュメントの一例を示す図である。好ましい実施形態で、永続的ノード識別子と現在のネットワーク・エンドポイントの間のマッピング、および永続的コンテンツ識別子とそのコンテンツの現在のストレージ・ロケーションの間のマッピングを記録するために好ましい実施形態に従って生成されたリソース・セットをどのように指定するかを説明するためのＸＭＬドキュメントの一例を示す図である。好ましい実施形態で、どのようにコンテンツ横断パス定義を指定し、特定のコンテンツ・リソースがＰ２Ｐネットワークに入ってからたどったパスを識別するかを説明するためのＸＭＬドキュメントの一例を示す図である。好ましい実施形態に従って、Ｐ２Ｐネットワークのノードが初期設定時に実行するブートストラップ・フローを示す図である。好ましい実施形態で、図１０のブートストラップ・フローの間に発行される「アライブ（alive）」通知メッセージの中で、どのように評判情報を伝えるかを示すＸＭＬドキュメントの一例を示す図である。好ましい実施形態で、Ｐ２Ｐネットワーク内に「アライブ（alive）」メッセージを伝えるために使用できる「スパイ（spy）」メッセージを示すＸＭＬドキュメントの一例を示す図である。好ましい実施形態に従って、あるノードがコンテンツ提供元またはサービス提供元を見つけ出し、コンテンツ／サービスを要求するために使用する要求元フローを示す図である。好ましい実施形態で、図１３の要求元フローの間にどのようにクエリーをブロードキャストするかを示すＳＯＡＰエンベロープの一例を示す図である。あるノードが図１４のクエリーにどのように応答できるかを示すＳＯＡＰエンベロープの一例を示す図である。好ましい実施形態で、図１３の要求元フローの中で選択されたノードに、どのようにコンテンツ／サービスの送達を要求するかを示すＳＯＡＰエンベロープを具体化した「ＨＴＴＰ（HyperText Transfer Protocol）」要求メッセージの一例を示す図である。要求されたコンテンツ、または要求されたサービスの結果が要求元にどのように送達できるかを示すＨＴＴＰ応答メッセージの一例を示す図である。好ましい実施形態に従って、あるノードが、要求元からのクエリーに応答し、その要求元によって選択された場合には、要求されたコンテンツまたは要求されたサービスの結果を返すために使用する提供元フローを示す図である。本明細書で開示された、オプションのシステム管理機能で使用できるヘッダの例を示す図である。本明細書で開示された、オプションのシステム管理機能で使用できるヘッダの例を示す図である。本明細書で開示された、オプションのシステム管理機能で使用できるヘッダの例を示す図である。オプションのシステム管理機能を提供するシステム・ノードが実施できる管理フローを示す図である。

Claims

ネットワークを構成するノードの集合体が時間とともに変化し得る一時的ネットワーク・コミュニティを有するネットワークにおいて前記ノードを永続的に識別する方法であって、
各ノードの前記ネットワークへの最初のエントリに際し、前記ノードに最初のネットワーク・アドレスを割り当てるステップと、
前記各ノードの前記ネットワークへの前記最初のエントリに際し、前記ノードの永続的ノード識別子を生成するステップと、
前記最初のネットワーク・アドレスと前記永続的ノード識別子との間のマッピングを格納するステップと、
前記各ノードのその後の前記ネットワークへのエントリに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記永続的ノード識別子を使用して各ノードの識別を解決するステップと
各ノードが前記ネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用すると前記挙動を前記ノードと関連づけることが可能になるステップと
特定のノードが異なるネットワーク・アドレスで前記ネットワークに再入するときはいつも、前記特定のノードに関する前記格納されたマッピングの前記ネットワーク・アドレスを前記異なるネットワーク・アドレスで置き換えるように、前記特定のノードに関する前記マッピングを改訂するステップと
を含む方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る一時的ネットワーク・コミュニティを有するネットワークにおいて前記ノードを永続的に識別する方法であって、
各ノードの前記ネットワークへの最初のエントリに際し、前記ノードに最初のネットワーク・アドレスを割り当てるステップと、
前記各ノードの前記ネットワークへの前記最初のエントリに際し、前記ノードの永続的ノード識別子を生成するステップと、
前記最初のネットワーク・アドレスと前記永続的ノード識別子との間のマッピングを格納するステップと、
前記各ノードのその後の前記ネットワークへのエントリに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記永続的ノード識別子を使用して各ノードの識別を解決するステップと
各ノードが前記ネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用すると前記挙動を前記ノードと関連づけることが可能になるステップと、
を含む方法であって、
各ノードが使用するリンクベースを前記ノードの前記永続的ノード識別子によって一意に識別してリンクを格納する前記方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る一時的ネットワーク・コミュニティを有するネットワークにおいて前記ノードを永続的に識別する方法であって、
各ノードの前記ネットワークへの最初のエントリに際し、前記ノードに最初のネットワーク・アドレスを割り当てるステップと、
前記各ノードの前記ネットワークへの前記最初のエントリに際し、前記ノードの永続的ノード識別子を生成するステップと、
前記最初のネットワーク・アドレスと前記永続的ノード識別子との間のマッピングを格納するステップと、
前記各ノードのその後の前記ネットワークへのエントリに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記永続的ノード識別子を使用して各ノードの識別を解決するステップと
各ノードが前記ネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用すると前記挙動を前記ノードと関連づけることが可能になるステップと、
を含む方法であって、
特定のノードの前記永続的ノード識別子が、前記特定のノードの前記最初のネットワーク・アドレスと、前記ネットワークへの前記最初のエントリが発生した日付と、前記ネットワークへの前記最初のエントリが発生した時間と、前記最初のエントリが発生したドメインの識別子である前記方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る一時的ネットワーク・コミュニティを有するネットワークにおいて前記ノードを永続的に識別する方法であって、
各ノードの前記ネットワークへの最初のエントリに際し、前記ノードに最初のネットワーク・アドレスを割り当てるステップと、
前記各ノードの前記ネットワークへの前記最初のエントリに際し、前記ノードの永続的ノード識別子を生成するステップと、
前記最初のネットワーク・アドレスと前記永続的ノード識別子との間のマッピングを格納するステップと、
前記各ノードのその後の前記ネットワークへのエントリに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記永続的ノード識別子を使用して各ノードの識別を解決するステップと
各ノードが前記ネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用すると前記挙動を前記ノードと関連づけることが可能になるステップと、
を含む方法であって、
前記永続的ノード識別子がＵＵＩＤ（Universal Unique Identifier）に基づいて生成される前記方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る一時的ネットワーク・コミュニティを有するネットワークにおいて前記ノードを永続的に識別する方法であって、
各ノードの前記ネットワークへの最初のエントリに際し、前記ノードに最初のネットワーク・アドレスを割り当てるステップと、
前記各ノードの前記ネットワークへの前記最初のエントリに際し、前記ノードの永続的ノード識別子を生成するステップと、
前記最初のネットワーク・アドレスと前記永続的ノード識別子との間のマッピングを格納するステップと、
前記各ノードのその後の前記ネットワークへのエントリに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記永続的ノード識別子を使用して各ノードの識別を解決するステップと
各ノードが前記ネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用すると前記挙動を前記ノードと関連づけることが可能になるステップと、
を含む方法であって、
特定のノードに関する前記マッピングが、前記特定のノードが知っている他のノードを永続的に識別するマッピングを有するリソース・セットに記憶される前記方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る一時的ネットワーク・コミュニティを有するネットワークにおいて前記ノードを永続的に識別する方法であって、
各ノードの前記ネットワークへの最初のエントリに際し、前記ノードに最初のネットワーク・アドレスを割り当てるステップと、
前記各ノードの前記ネットワークへの前記最初のエントリに際し、前記ノードの永続的ノード識別子を生成するステップと、
前記最初のネットワーク・アドレスと前記永続的ノード識別子との間のマッピングを格納するステップと、
前記各ノードのその後の前記ネットワークへのエントリに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記永続的ノード識別子を使用して各ノードの識別を解決するステップと
各ノードが前記ネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用すると前記挙動を前記ノードと関連づけることが可能になるステップと、
前記永続的ノード識別子を使用して前記ネットワークにおける各ノードの挙動を追跡するステップと
を含む方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る一時的ネットワーク・コミュニティを有するネットワークにおいて前記ノードを永続的に識別する方法であって、
各ノードの前記ネットワークへの最初のエントリに際し、前記ノードに最初のネットワーク・アドレスを割り当てるステップと、
前記各ノードの前記ネットワークへの前記最初のエントリに際し、前記ノードの永続的ノード識別子を生成するステップと、
前記最初のネットワーク・アドレスと前記永続的ノード識別子との間のマッピングを格納するステップと、
前記各ノードのその後の前記ネットワークへのエントリに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記永続的ノード識別子を使用して各ノードの識別を解決するステップと
各ノードが前記ネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用すると前記挙動を前記ノードと関連づけることが可能になるステップと、
前記永続的ノード識別子を使用して、コンテンツ・リソースが前記ネットワーク中でたどったネットワーク横断パスを追跡するステップと
を含む方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る一時的ネットワーク・コミュニティを有するネットワークにおいて前記ノードを永続的に識別する方法であって、
各ノードの前記ネットワークへの最初のエントリに際し、前記ノードに最初のネットワーク・アドレスを割り当てるステップと、
前記各ノードの前記ネットワークへの前記最初のエントリに際し、前記ノードの永続的ノード識別子を生成するステップと、
前記最初のネットワーク・アドレスと前記永続的ノード識別子との間のマッピングを格納するステップと、
前記各ノードのその後の前記ネットワークへのエントリに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記永続的ノード識別子を使用して各ノードの識別を解決するステップと
各ノードが前記ネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用すると前記挙動を前記ノードと関連づけることが可能になるステップと、
を含む方法であって、
前記マッピングがXlink表記を使用して指定される前記方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る一時的ネットワーク・コミュニティを有するネットワークにおいて前記ノードを永続的に識別する方法であって、
各ノードの前記ネットワークへの最初のエントリに際し、前記ノードに最初のネットワーク・アドレスを割り当てるステップと、
前記各ノードの前記ネットワークへの前記最初のエントリに際し、前記ノードの永続的ノード識別子を生成するステップと、
前記最初のネットワーク・アドレスと前記永続的ノード識別子との間のマッピングを格納するステップと、
前記各ノードのその後の前記ネットワークへのエントリに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記永続的ノード識別子を使用して各ノードの識別を解決するステップと
各ノードが前記ネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用すると前記挙動を前記ノードと関連づけることが可能になるステップと、
を含む方法であって、
前記ネットワークがピアツーピア・ネットワークである前記方法。
前記ノードのうちの特定の１つのノードについて、前記特定のノードの前記ネットワークへの前記その後のエントリに際し、前記特定のノードに前記異なるネットワーク・アドレスを割り当てるステップと、
前記異なるネットワーク・アドレスが割り当てられた後、前記特定のノードの前記永続的ノード識別子を使用して前記特定のノードの識別を解決するステップと
をさらに含む、請求項１乃至９のいずれかに記載の方法。
特定のノードについての前記挙動が、前記特定のノードが他のノードからの要求にどれぐらい良く応答できるかを含む、請求項６に記載の方法。
前記追跡ステップが、
特定のコンテンツ・リソースがどこで前記ネットワークに入ったか、あるいは前記ネットワークのどこで生成されたかを識別するステップと、
選択されたネットワーク横断パス上で前記特定のコンテンツ・リソースが通過した各ノードを識別するステップであって、前記識別ステップで、対応するノードの永続的ネットワーク識別子を使用するステップと
を含む、請求項７に記載の方法。
前記特定のノードの挙動が、前記特定のノードから送信されるアウトバウンド・メッセージ上で示される、請求項１１に記載の方法。
前記特定のコンテンツ・リソースの前記ネットワーク横断パスが、前記特定のコンテンツ・リソースを運ぶアウトバウンド・メッセージ上で示される、請求項１２に記載の方法。
前記ネットワークへの再入に際し、各ノードが、前記ノードの永続的ネットワーク識別子および前記ノードのネットワーク・アドレスの現在のバージョンを使用して前記ノードを識別するメッセージをブロードキャストするステップと、
前記ブロードキャスト・メッセージを前記ネットワーク中の他のノードが受信するステップと、
前記受信ノードが、前記再入ノードのネットワーク・アドレスの前記現在のバージョンを反映するようにそのノードに格納されたマッピングを改訂するステップと
をさらに含む、請求項１０に記載の方法。
前記格納されたマッピングを調べて、選択されたノードの以前の挙動を識別するステップをさらに含む、請求項１５に記載の方法。
前記格納されたマッピングを調べて、選択されたノードが生成した、または転送したコンテンツを追跡するステップをさらに含む、請求項１５に記載の方法。
ネットワークを構成するノードの集合体が時間とともに変化し得るアド・ホック・ネットワークにおいて前記ノードを永続的に識別するシステムであって、
各ノードの前記ネットワークへの最初のエントリに際し、前記ノードに最初のネットワーク・アドレスを割り当てる手段と、
前記ノードの前記ネットワークへの最初のエントリに際し、前記各ノードの永続的ノード識別子を生成する手段と、
前記最初のネットワーク・アドレスと前記永続的ノード識別子の間のマッピングを格納する手段と、
前記特定のノードが異なるネットワーク・アドレスで前記ネットワークに入った後、前記特定のノードの永続的ノード識別子を使用してそのノードの識別を解決する手段と
各ノードが前記ネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録する手段であって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用すると前記挙動を前記ノードと関連づけることが可能になる手段と
を含むシステムであって、
各ノードが使用するリンクベースを前記ノードの前記永続的ノード識別子によって一意に識別してリンクを格納する前記システム。
ネットワークを構成するノードの集合体が時間とともに変化し得る、一時的ネットワーク・コミュニティを有するネットワークにおいてノードの評判を永続させる方法であって、
各ノードが前記ネットワークに複数回入るに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記ネットワーク中の前記ノードの永続的ノード識別子を使用するステップと、
各ノードの前記永続的ノード識別子と前記ノードが使用する現在のネットワーク・アドレスとの間のマッピングを生成するステップと、
各ノードがネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用することによって前記挙動を前記ノードと関連づけることが可能になるステップと
を含む方法であって、
各ノードの前記記録結果が、他のノードからのクエリーへの応答に前記ノードがどの程度成功するかを示す前記方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る、一時的ネットワーク・コミュニティを有するネットワークにおいてノードの評判を永続させる方法であって、
各ノードが前記ネットワークに複数回入るに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記ネットワーク中の前記ノードの永続的ノード識別子を使用するステップと、
各ノードの前記永続的ノード識別子と前記ノードが使用する現在のネットワーク・アドレスとの間のマッピングを生成するステップと、
各ノードがネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用することによって前記挙動を前記ノードと関連づけることが可能になるステップと
を含む方法であって、
各ノードの前記記録結果が、他のノードからのクエリーへの応答における前記ノードの効率を示す前記方法。
前記効率が、前記クエリーへの前記応答の消費時間で評価される、請求項２０に記載の方法。
前記成功が、前記ノードが応答できる前記各クエリーごとに判断される、請求項１９に記載の方法。
前記成功が、前記ノードが応答できる前記クエリーのすべてを一括に判断される、請求項１９に記載の方法。
前記効率が、前記ノードが応答できる前記各クエリーごとに判断される、請求項２０に記載の方法。
前記効率が、前記ノードが応答できる前記クエリーのすべてを一括に判断される、請求項２０に記載の方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る、一時的ネットワーク・コミュニティを有するネットワークにおいてノードの評判を永続させる方法であって、
各ノードが前記ネットワークに複数回入るに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記ネットワーク中の前記ノードの永続的ノード識別子を使用するステップと、
各ノードの前記永続的ノード識別子と前記ノードが使用する現在のネットワーク・アドレスとの間のマッピングを生成するステップと、
各ノードがネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用することによって前記挙動を前記ノードと関連づけることが可能になるステップと
を含む方法であって、
前記ノードの評判が、前記ノードが応答できる１組のクエリー、および前記ノードがそれらのクエリーに応答したときの前記ノードの挙動の記録結果を含む前記方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る、一時的ネットワーク・コミュニティを有するネットワークにおいてノードの評判を永続させる方法であって、
各ノードが前記ネットワークに複数回入るに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記ネットワーク中の前記ノードの永続的ノード識別子を使用するステップと、
各ノードの前記永続的ノード識別子と前記ノードが使用する現在のネットワーク・アドレスとの間のマッピングを生成するステップと、
各ノードがネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用することによって前記挙動を前記ノードと関連づけることが可能になるステップと
を含む方法であって、
前記ノードの評判が、前記ノードから提供できる１組のサービス、および前記ノードがそれらのサービスを実施したときの前記ノードの挙動の記録結果を含む前記方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る、一時的ネットワーク・コミュニティを有するネットワークにおいてノードの評判を永続させる方法であって、
各ノードが前記ネットワークに複数回入るに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記ネットワーク中の前記ノードの永続的ノード識別子を使用するステップと、
各ノードの前記永続的ノード識別子と前記ノードが使用する現在のネットワーク・アドレスとの間のマッピングを生成するステップと、
各ノードがネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用することによって前記挙動を前記ノードと関連づけることが可能になるステップと
特定のノードの記録結果への参照を、前記特定のノードが送信するメッセージとともに転送するステップと
を含む方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る、一時的ネットワーク・コミュニティを有するネットワークにおいてノードの評判を永続させる方法であって、
各ノードが前記ネットワークに複数回入るに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記ネットワーク中の前記ノードの永続的ノード識別子を使用するステップと、
各ノードの前記永続的ノード識別子と前記ノードが使用する現在のネットワーク・アドレスとの間のマッピングを生成するステップと、
各ノードがネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用することによって前記挙動を前記ノードと関連づけることが可能になるステップと
特定のノードが、その特定のノードから提供できるコンテンツを求める要求を受信するステップと、
前記特定のノードが、前記要求されたコンテンツを前記特定のノードの評判を主張する情報とともに転送するステップであって、前記評判が前記特定のノードの記録結果を含むステップと
を含む方法。
前記特定のノードが、前記要求を受信し前記要求されたコンテンツを転送したことに応答して前記ノードの記録結果を改訂するステップをさらに含む、請求項２９に記載の方法。
前記転送されたコンテンツを受信ノードで受信するステップと、
前記受信ステップに応答して、前記受信ノードが前記特定のノードに関する評判のローカル・バージョンを格納するステップであって、前記ローカル・バージョンが、前記受信したコンテンツが前記受信ノードにとって満足できるものかどうかを反映するステップと
をさらに含む、請求項２９に記載の方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る、一時的ネットワーク・コミュニティを有するネットワークにおいてノードの評判を永続させる方法であって、
各ノードが前記ネットワークに複数回入るに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記ネットワーク中の前記ノードの永続的ノード識別子を使用するステップと、
各ノードの前記永続的ノード識別子と前記ノードが使用する現在のネットワーク・アドレスとの間のマッピングを生成するステップと、
各ノードがネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用することによって前記挙動を前記ノードと関連づけることが可能になるステップと
各ノードが前記ネットワークに入ったとき、前記ノードがメッセージをブロードキャストし、それによって前記ノードの評判の前記ノードのバージョンを通知するステップであって、前記評判が、前記ノードが前記ネットワーク中の他のノードとの対話にどの程度成功したかに関する前記ノードのビューを含むステップと
を含む方法。
前記評判が、前記ブロードキャスト・ノードから提供できるコンテンツをさらに含む、請求項３２に記載の方法。
前記評判が、前記ブロードキャスト・ノードから提供できるサービスをさらに含む、請求項３２に記載の方法。
前記ネットワーク中の他のノードが、前記ブロードキャスト・メッセージを受信するステップと、
前記受信ノードが前記ブロードキャスト・メッセージから前記ブロードキャスト・ノードの評判に関する前記ブロードキャスト・ノードのバージョンを取り出すステップと、
前記取り出した評判のローカル・コピーを格納するステップと
をさらに含む、請求項３２に記載の方法。
前記通知された評判が前記ブロードキャスト・ノードの評判に関する前記ブロードキャスト・ノードのバージョンへの参照であり、かつ
ネットワーク中の他のノードが、前記ブロードキャスト・メッセージを受信するステップと、
前記受信ノードが、前記ブロードキャスト・ノードから前記参照を取り出すステップと、
前記参照のローカル・コピーを格納するステップと
をさらに含む、請求項３２に記載の方法。
前記ローカル・コピーが、前記ブロードキャスト・ノードの評判に関する前記受信ノードのビューを反映する、請求項３５に記載の方法。
前記受信ノードが前記ブロードキャスト・ノードを信用できないものと見なした場合、前記ローカル・コピーで、前記ブロードキャスト・ノードの評判に関する前記ブロードキャストのビューが無視される、請求項３７に記載の方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る、一時的ネットワーク・コミュニティを有するネットワークにおいてノードの評判を永続させる方法であって、
各ノードが前記ネットワークに複数回入るに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記ネットワーク中の前記ノードの永続的ノード識別子を使用するステップと、
各ノードの前記永続的ノード識別子と前記ノードが使用する現在のネットワーク・アドレスとの間のマッピングを生成するステップと、
各ノードがネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用することによって前記挙動を前記ノードと関連づけることが可能になるステップと
特定のノードで、他のノードのコンテンツまたはサービスが必要であると判断するステップと、
前記ネットワーク中の他のノードのうちのどれが前記必要なコンテンツまたはサービスを提供できるかを判断するステップと、
前記必要なコンテンツまたはサービスを提供できる前記ノードに関する前記記録結果を評価して、それらの前記ノードのうちから選択するステップと
を含む方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る、一時的ネットワーク・コミュニティを有するネットワークにおいてノードの評判を永続させる方法であって、
各ノードが前記ネットワークに複数回入るに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記ネットワーク中の前記ノードの永続的ノード識別子を使用するステップと、
各ノードの前記永続的ノード識別子と前記ノードが使用する現在のネットワーク・アドレスとの間のマッピングを生成するステップと、
各ノードがネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用することによって前記挙動を前記ノードと関連づけることが可能になるステップと
を含む方法であって、
前記記録結果が、特定のノードが信頼できないと見なされたときその旨を指示する前記方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る、一時的ネットワーク・コミュニティを有するネットワークにおいてノードの評判を永続させる方法であって、
各ノードが前記ネットワークに複数回入るに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記ネットワーク中の前記ノードの永続的ノード識別子を使用するステップと、
各ノードの前記永続的ノード識別子と前記ノードが使用する現在のネットワーク・アドレスとの間のマッピングを生成するステップと、
各ノードがネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用することによって前記挙動を前記ノードと関連づけることが可能になるステップと
を含む方法であって、
前記記録結果が時間の経過とともに再計算され、それによってその記録結果が、前記ノードが前記ネットワーク中の他のノードの信頼を得ているかどうかを反映するようになる前記方法。
前記ネットワーク中の他のノードとの対話を望む特定のノードが、前記他のノードの記録結果を考慮して前記他のノードを信頼するかどうかを判断する、請求項４１に記載の方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る、一時的ネットワーク・コミュニティを有するネットワークにおいてノードの評判を永続させる方法であって、
各ノードが前記ネットワークに複数回入るに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記ネットワーク中の前記ノードの永続的ノード識別子を使用するステップと、
各ノードの前記永続的ノード識別子と前記ノードが使用する現在のネットワーク・アドレスとの間のマッピングを生成するステップと、
各ノードがネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用することによって前記挙動を前記ノードと関連づけることが可能になるステップと
を含む方法であって、
前記記録結果が時間の経過とともに再計算され、それによって、前記ノードが効率的にクエリーに応答すると前記ネットワーク中の他のノードに見なされているかどうかを反映するようになる前記方法。
前記ネットワーク中の他のノードとの対話を望む特定のノードが、複数の他のノードの前記記録結果を考慮して前記他のノードのうちのどれが最も効率的に前記対話を実施できるかを判断する、請求項４３に記載の方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る、一時的ネットワーク・コミュニティを有するネットワークにおいてノードの評判を永続させる方法であって、
各ノードが前記ネットワークに複数回入るに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記ネットワーク中の前記ノードの永続的ノード識別子を使用するステップと、
各ノードの前記永続的ノード識別子と前記ノードが使用する現在のネットワーク・アドレスとの間のマッピングを生成するステップと、
各ノードがネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録するステップであって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用することによって前記挙動を前記ノードと関連づけることが可能になるステップと
を含む方法であって、
特定のノードの記録結果が生成された後にたとえ前記特定のノードの前記現在のネットワーク・アドレスが変更されたとしても、各ノードの前記永続的ノード識別子を使用して前記特定のノードの前記記録結果が見つけられる前記方法。
前記ブロードキャスト・ノードが、前記ブロードキャスト・メッセージを受信した他のノードからの応答を受信するステップであって、前記応答が前記他のノードの評判に関する前記他のノードのバージョンを含むステップと、
前記ブロードキャスト・ノードが、前記応答の前記受信バージョンを使用して、前記他のノードの評判に関するローカル・ビューを決定するステップと
をさらに含む、請求項３２に記載の方法。
前記ブロードキャスト・ノードが、前記応答を返してきた前記他のノードのそれぞれに後続のメッセージを送信するステップであって、前記後続のメッセージが、ノードの識別を求める要求を伝搬するよう前記他のノードに要求し、それによって前記ブロードキャスト・ノードが他のサブネットにあるノードを知ること、および他のサブネットにあるそれらのノードと評判情報を交換することが可能になるステップをさらに含む、請求項４６に記載の方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る一時的ネットワーク・コミュニティを有するネットワークにおいてノードの評判を永続させるシステムであって、
各ノードが前記ネットワークに複数回入るに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記ネットワーク中の前記ノードの永続的ノード識別子を使用する手段と、
各ノードの前記永続的ノード識別子と前記ノードが使用する現在のネットワーク・アドレスとのマッピングを生成する手段と、
各ノードが前記ネットワーク中の他のノードと対話するときに、前記ノードの挙動の結果を記録する手段であって、たとえ前記ノードの現在のネットワーク・アドレスが変化したとしても、前記マッピングを使用することによって前記挙動を前記ノードと関連づけることが可能になる手段と
を含むシステムであって、
各ノードの前記記録結果が、他のノードからのクエリーへの応答における前記ノードの効率を示す前記システム。
ネットワークを構成するノードの集合体が時間とともに変化し得る、一時的ネットワーク・コミュニティを有するネットワークにおいてコンテンツを追跡する方法であって、
各ノードが前記ネットワークに複数回入るに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記ネットワーク中の前記ノードの永続的ノード識別子を使用するステップと、
各ノードの前記永続的ノード識別子と前記ノードが使用する現在のネットワーク・アドレスとの間のマッピングを生成するステップと、
前記永続的ノード識別子を前記ネットワーク中のノードのコンテンツ・リソースに関連づけるステップと、
有向グラフを使用して、前記コンテンツ・リソースのネットワーク横断パスを表すステップと
を含む方法。
前記各有向グラフのノードが、前記コンテンツ・リソースの１つが通過した、前記ネットワークのノードを表し、前記有向グラフのアークが、前記コンテンツが前記ネットワークのあるノードから他のノードに移動することを表す、請求項４９に記載の方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る、一時的ネットワーク・コミュニティを有するネットワークにおいてコンテンツを追跡する方法であって、
各ノードが前記ネットワークに複数回入るに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記ネットワーク中の前記ノードの永続的ノード識別子を使用するステップと、
各ノードの前記永続的ノード識別子と前記ノードが使用する現在のネットワーク・アドレスとの間のマッピングを生成するステップと、
前記永続的ノード識別子を前記ネットワーク中のノードのコンテンツ・リソースに関連づけるステップと、
各コンテンツ・リソースごとにメタデータを格納するステップであって、前記メタデータが前記コンテンツ・リソースの永続的識別子を含むステップと
を含む方法。
前記メタデータが前記コンテンツ・リソースの生成に関連する情報をさらに含む、請求項５１に記載の方法。
前記情報が、前記コンテンツ・リソースの作成者ならびに作成の日付および時間をさらに含む、請求項５２に記載の方法。
前記メタデータが、前記コンテンツ・リソースの前記ネットワークへのエントリと前記ネットワークへの前記エントリの日付および時間とに関連する情報をさらに含む、請求項５０に記載の方法。
前記メタデータが、前記コンテンツ・リソースの記述（description）をさらに含む、請求項５１に記載の方法。
前記記述が、前記コンテンツ・リソースが所望のものかどうかを評価するユーザに提供される、請求項５５に記載の方法。
前記コンテンツ・リソースの前記有向グラフを横断リポジトリ中に格納するステップをさらに含む、請求項５０に記載の方法。
前記コンテンツ・リソースの１つが前記ネットワークのあるノードから他のノードに転送されるたびに、前記有向グラフにノードとアークを追加するステップをさらに含む、請求項５０に記載の方法。
構造化マークアップ言語表記を使用して各コンテンツ・リソースの前記有向グラフを指定する、請求項５０に記載の方法。
前記有向グラフが、そのグラフのアークのエンドポイントを使用して指定される、請求項５７に記載の方法。
Xlink表記を使用して、各アークのエンドポイントを指定する請求項６０に記載の方法。
特定のコンテンツ・リソースの現在のロケーションと前記コンテンツ・リソースの永続的識別子をマッピングするコンテンツ・マッピングを格納するステップをさらに含む、請求項５０に記載の方法。
前記コンテンツ・リソースの前記永続的識別子が前記コンテンツ・リソースに関連するメタデータとして格納され、さらに前記関連するメタデータ中の前記永続的識別子を使用して前記コンテンツ・リソースの前記現在のロケーションを決定するステップを含む、請求項６２に記載の方法。
コンテンツ・リソースを転送する各メッセージ中に、前記転送されるコンテンツ・リソースの前記有向グラフへの参照を含めるステップをさらに含む、請求項６０に記載の方法。
選択されたコンテンツ・リソース、およびそのリソースの有向グラフへの前記参照を要求ノードで受信するステップと、
前記含められた参照を使用して前記有向グラフを見つけるステップと、
前記選択されたコンテンツ・リソースを転送した前記ノードおよび前記選択されたコンテンツ・リソースを受信した前記ノードを表すファイナル・アーク（final arc）が含まれるように前記見つけられた有向グラフを拡張するステップと
をさらに含む、請求項６４に記載の方法。
前記ファイナル・アークが前記選択されたコンテンツ・リソースの永続的識別子をさらに含み、さらに前記受信したコンテンツ・リソースをローカル・コンテンツ・リポジトリ内に格納するステップを含む、請求項６５に記載の方法。
前記受信したコンテンツ・リソースをローカル・コンテンツ・リポジトリ内に格納するステップをさらに含む、請求項６５に記載の方法。
前記ファイナル・アークが前記選択されたコンテンツ・リソースの永続的識別子をさらに含んでおり、さらに
前記受信したコンテンツ・リソースをローカル・コンテンツ・リポジトリに格納するステップと、
前記受信したコンテンツ・リソースのコンテンツ・マッピングを格納するステップであって、前記コンテンツ・マッピングが、前記ローカル・コンテンツ・リポジトリ内で前記受信したコンテンツ・リソースが格納されたロケーションと前記コンテンツ・リソースの永続的識別子とをマッピングするステップと
を含む、請求項６５に記載の方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る、一時的ネットワーク・コミュニティを有するネットワークにおいてコンテンツを追跡する方法であって、
各ノードが前記ネットワークに複数回入るに際し、たとえ前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記ネットワーク中の前記ノードの永続的ノード識別子を使用するステップと、
各ノードの前記永続的ノード識別子と前記ノードが使用する現在のネットワーク・アドレスとの間のマッピングを生成するステップと、
前記永続的ノード識別子を前記ネットワーク中のノードのコンテンツ・リソースに関連づけるステップと含む方法であって、、
前記ネットワークがピアツーピア・ネットワークである前記方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る一時的ネットワーク・コミュニティを有するネットワークにおいてコンテンツを追跡する方法であって、
各コンテンツ・リソースのネットワーク横断パスを表す有向グラフを格納するステップであって、前記有向グラフの各アークが、前記コンテンツ・リソースが前記ネットワークのあるノードから他のノードへと横断することを表すステップと、
各コンテンツ・リソースを保持するノードから前記コンテンツ・リソースを受信するノードへの前記コンテンツ・リソースの後続の横断を反映するように各コンテンツ・リソースの前記有向グラフを拡張するステップであって、永続的識別子が各コンテンツ・リソースと関連づけられ、特定のコンテンツ・リソースの前記有向グラフの各アークが前記関連づけられた永続的識別子を指定するステップと
を含む方法。
各ノードにローカルに格納された各コンテンツ・リソースの前記永続的識別子と前記ローカルに格納されたコンテンツ・リソースの現在のロケーションとの間のマッピングを前記ノードが格納するステップをさらに含む、請求項７０に記載の方法。
選択されたコンテンツ・リソースをその永続的識別子によって識別するステップと、
前記選択されたコンテンツ・リソースに関する前記格納されたマッピングを使用して、特定のノードにおける前記リソースの現在のロケーションを決定するステップと
をさらに含む、請求項７１に記載の方法。
選択されたコンテンツ・リソースをその永続的識別子によって識別するステップと、
前記選択されたコンテンツ・リソースに関する前記格納されたマッピングを使用して、前記リソースのネットワーク横断パスを決定するステップと
をさらに含む請求項７１に記載の方法。
前記ネットワーク中の各ノードが永続的ノード識別子を有しており、前記永続的ノード識別子を使用して、前記有向グラフの各アークに関する、特定のコンテンツ・リソースを保持する前記ノードおよび前記特定のコンテンツ・リソースを転送する前記ノードが識別される、請求項７０に記載の方法。
各ノードが、前記ネットワークに入ったときにメッセージをブロードキャストし、それによって前記ノードがどのようなコンテンツを保持しているかを通知するステップをさらに含む、請求項７０に記載の方法。
前記ブロードキャスト・メッセージを受信したノードが、前記ブロードキャスト・ノードに特定のコンテンツ・リソースを要求するステップと、
前記要求ノードで、前記要求したコンテンツ・リソースを前記コンテンツ・リソースの前記保持ノードの有向グラフへの参照とともに受信するステップと、
前記受信したコンテンツ・リソースをローカル・コンテンツ・リポジトリ内に格納するステップと、
前記受信したコンテンツ・リソースの前記有向グラフのローカル・コピーを格納するステップであって、前記ローカル・コピーが、前記保持ノードから前記受信ノードへの横断に関する拡張部分を含むステップと
をさらに含む、請求項７５に記載の方法。
前記コンテンツ・リソースが、前記ネットワークの各ノードの間で共用で使用可能なファイルを含む、請求項７０に記載の方法。
前記コンテンツ・リソースが、前記ネットワークのノードから提供できるサービスの結果を含む、請求項７０に記載の方法。
ネットワークを構成するノードの集合体が時間とともに変化し得る一時的ネットワーク・コミュニティを有するネットワークにおいてコンテンツを追跡するシステムであって、
前記ネットワークに複数回入るに際し、前記ノードに異なるネットワーク・アドレスが割り当てられたとしても、前記ネットワーク中の各ノードの永続的ノード識別子を使用する手段と、
各ノードの前記永続的ノード識別子と前記ノードが使用する現在のネットワーク・アドレスの間のマッピングを生成する手段と、
前記永続的ノード識別子を前記ネットワーク中のノードのコンテンツ・リソースに関連づける手段と、
各コンテンツ・リソースごとにメタデータを格納する手段であって、前記メタデータが前記コンテンツ・リソースの永続的識別子を含む手段と
を含むシステム。
非集中ネットワークにおいてストレージ・リソースを管理する方法であって、
前記ネットワークに入るに際し、各ノードに割り当てられる現在のネットワーク・アドレスがたとえエントリごとに変化したとしても、永続的ノード識別子を前記ネットワーク中の前記ノードに関連づけるステップと、
複数のストレージ・ノードの挙動を動的に評価するステップであって、前記ストレージ・ノードが要求に応じてストレージ・リソースを提供するノードであるステップと、
前記ネットワークにおける各ノードの前記現在のネットワーク・アドレスを前記ノードに関する永続的ノード識別子に関連づけるマッピングを使用して前記各ストレージ・ノードの識別を解決することによって、前記ストレージ・ノードの前記動的に評価される挙動の継続した知識を維持するステップと、
前記維持された知識を使用して、前記ストレージ・ノードの前記ストレージ・リソースを管理するステップとを含む方法であって、
前記各ストレージ・ノードの前記動的に評価される挙動が、前記ストレージ・ノードがどの程度効率的にストレージ要求を処理するかを含む前記方法。
を含む方法。
非集中ネットワークにおいてストレージ・リソースを管理する方法であって、
前記ネットワークに入るに際し、各ノードに割り当てられる現在のネットワーク・アドレスがたとえエントリごとに変化したとしても、永続的ノード識別子を前記ネットワーク中の前記ノードに関連づけるステップと、
複数のストレージ・ノードの挙動を動的に評価するステップであって、前記ストレージ・ノードが要求に応じてストレージ・リソースを提供するノードであるステップと、
前記ネットワークにおける各ノードの前記現在のネットワーク・アドレスを前記ノードに関する永続的ノード識別子に関連づけるマッピングを使用して前記各ストレージ・ノードの識別を解決することによって、前記ストレージ・ノードの前記動的に評価される挙動の継続した知識を維持するステップと、
前記維持された知識を使用して、前記ストレージ・ノードの前記ストレージ・リソースを管理するステップとを含む方法であって、
前記各ストレージ・ノードの前記動的に評価される挙動が、前記ストレージ・ノードがどれぐらい良くトレージ要求に応答するかを含む前記方法。
非集中ネットワークにおいてストレージ・リソースを管理する方法であって、
前記ネットワークに入るに際し、各ノードに割り当てられる現在のネットワーク・アドレスがたとえエントリごとに変化したとしても、永続的ノード識別子を前記ネットワーク中の前記ノードに関連づけるステップと、
複数のストレージ・ノードの挙動を動的に評価するステップであって、前記ストレージ・ノードが要求に応じてストレージ・リソースを提供するノードであるステップと、
前記ネットワークにおける各ノードの前記現在のネットワーク・アドレスを前記ノードに関する永続的ノード識別子に関連づけるマッピングを使用して前記各ストレージ・ノードの識別を解決することによって、前記ストレージ・ノードの前記動的に評価される挙動の継続した知識を維持するステップと、
前記維持された知識を使用して、前記ストレージ・ノードの前記ストレージ・リソースを管理するステップとを含む方法であって、
前記ストレージ・ノードがどれぐらい良くストレージ要求に応答するかが、前記ノードのストレージ・リソースの現在使用可能なストレージ容量を表す前記方法。
非集中ネットワークにおいてストレージ・リソースを管理する方法であって、
前記ネットワークに入るに際し、各ノードに割り当てられる現在のネットワーク・アドレスがたとえエントリごとに変化したとしても、永続的ノード識別子を前記ネットワーク中の前記ノードに関連づけるステップと、
複数のストレージ・ノードの挙動を動的に評価するステップであって、前記ストレージ・ノードが要求に応じてストレージ・リソースを提供するノードであるステップと、
前記ネットワークにおける各ノードの前記現在のネットワーク・アドレスを前記ノードに関する永続的ノード識別子に関連づけるマッピングを使用して前記各ストレージ・ノードの識別を解決することによって、前記ストレージ・ノードの前記動的に評価される挙動の継続した知識を維持するステップと、
前記維持された知識を使用して、前記ストレージ・ノードの前記ストレージ・リソースを管理するステップとを含む方法であって、
前記各ストレージ・ノードの前記動的に評価される挙動が、前記ストレージ・ノードが以前のストレージ要求に満足に応答したかどうかを示す成功指標を含む前記方法。
非集中ネットワークにおいてストレージ・リソースを管理する方法であって、
前記ネットワークに入るに際し、各ノードに割り当てられる現在のネットワーク・アドレスがたとえエントリごとに変化したとしても、永続的ノード識別子を前記ネットワーク中の前記ノードに関連づけるステップと、
複数のストレージ・ノードの挙動を動的に評価するステップであって、前記ストレージ・ノードが要求に応じてストレージ・リソースを提供するノードであるステップと、
前記ネットワークにおける各ノードの前記現在のネットワーク・アドレスを前記ノードに関する永続的ノード識別子に関連づけるマッピングを使用して前記各ストレージ・ノードの識別を解決することによって、前記ストレージ・ノードの前記動的に評価される挙動の継続した知識を維持するステップと、
前記維持された知識を使用して、前記ストレージ・ノードの前記ストレージ・リソースを管理するステップとを含む方法であって、
前記各ストレージ・ノードの前記動的に評価される挙動が、前記ストレージ・ノードから現在提供できるコンテンツの明細を含む前記方法。
非集中ネットワークにおいてストレージ・リソースを管理する方法であって、
前記ネットワークに入るに際し、各ノードに割り当てられる現在のネットワーク・アドレスがたとえエントリごとに変化したとしても、永続的ノード識別子を前記ネットワーク中の前記ノードに関連づけるステップと、
複数のストレージ・ノードの挙動を動的に評価するステップであって、前記ストレージ・ノードが要求に応じてストレージ・リソースを提供するノードであるステップと、
前記ネットワークにおける各ノードの前記現在のネットワーク・アドレスを前記ノードに関する永続的ノード識別子に関連づけるマッピングを使用して前記各ストレージ・ノードの識別を解決することによって、前記ストレージ・ノードの前記動的に評価される挙動の継続した知識を維持するステップと、
前記維持された知識を使用して、前記ストレージ・ノードの前記ストレージ・リソースを管理するステップと、
前記ネットワーク中のノードの１つが、ストレージ・リソースが必要であると判断するステップと、
前記ストレージ・ノードの前記挙動に関する前記継続した知識を使用して、前記必要なストレージ・リソースを現在提供できる前記ストレージ・ノードの１つを選択するステップと
を含む方法。
ストレージを必要とするノードが、コンテンツをストレージ・リソースに格納する必要があると判断するステップと、
前記ストレージ・ノードの前記挙動に関する前記継続した知識を使用して、前記ストレージを必要とするノードの前記コンテンツを格納するために現在使用可能な十分なストレージ容量をストレージ・リソースが有する前記ストレージ・ノードのうちの１つを選択するステップと
をさらに含む、請求項８２に記載の方法。
前記ストレージを必要とするノードが、前記選択されたストレージ・ノードに前記コンテンツの格納を求める要求を発行するステップをさらに含む、請求項８６に記載の方法。
前記ネットワーク中の前記ノードの１つが、ストレージ・リソースが必要であると判断するステップと、
前記ストレージ・ノードの前記挙動に関する前記継続した知識を使用して、前記必要とされるストレージ・リソースを効率的に提供できる前記ストレージ・ノードのうちの１つを選択するステップと
をさらに含む、請求項８０に記載の方法。
前記ネットワーク中の前記ノードの１つが、ストレージ・リソースが必要であると判断するステップと、
前記ストレージ・ノードの前記挙動に関する前記継続した知識を使用して、以前のストレージ要求に満足に応答したことを表す比較的高い成功指標を有する前記ストレージ・ノードのうちの１つを選択するステップと
をさらに含む、請求項８３に記載の方法。
コンテンツを必要とするノードが、ストレージ・リソースからコンテンツを取り出す必要があると判断するステップと、
前記ストレージ・ノードの前記挙動に関する前記継続した知識を使用して、前記コンテンツを必要とするノードが取り出す必要がある前記コンテンツを現在使用可能なコンテンツの明細が含むストレージ・ノードのうちの１つを選択するステップと
を含む、請求項８４に記載の方法。
アド・ホック・ネットワークにおいてストレージ・リソースを管理するシステムであって、
前記ネットワークに入るに際し、各ノードに割り当てられる現在のネットワーク・アドレスがたとえエントリごとに変化したとしても、永続的ノード識別子を前記ネットワーク中の各ノードに関連づける手段と、
ネットワーク中の各ノードの前記現在のネットワーク・アドレスを前記ノードの永続的ノード識別子に関連づけるマッピングを使用して前記各ストレージ・ノードの識別を解決することによって、複数のストレージ・ノードの動的に評価される挙動の継続した知識を維持する手段であって、前記ストレージ・ノードが必要に応じてストレージ・リソースを提供するノードである手段と、
前記維持された知識を使用して、前記ストレージ・ノードの前記ストレージ・リソースを管理する手段とを含むシステムであって、
前記各ストレージ・ノードの前記動的に評価される挙動が、前記ストレージ・ノードがどの程度効率的にストレージ要求を処理するかを含む前記システム。
非集中ネットワークにおいて管理機能を提供する方法であって、
前記ネットワークに入るに際し、たとえ各ノードに割り当てられる現在のネットワーク・アドレスがエントリごとに変化したとしても前記ノードの識別が解決できるように、永続的ノード識別子を前記ネットワーク中の前記ノードに関連づけるステップと、
特定のノードが管理機能を実施できると主張するステップと、
前記特定のノードの前記永続的識別子を使用して、前記特定のノードが前記管理機能を実施してもよいかどうかを検証するステップと
を含む方法。
前記各ノードに評判を関連づけるステップであって、各ノードの前記評判が前記ノードの永続的ノード識別子を使用して見つけられるステップをさらに含み、前記永続的ノード識別子を使用するステップが、
前記特定のノードの前記評判を前記ノードの永続的ノード識別子を使用して見つけるステップと、
前記特定のノードが適切な評判を有する場合には、前記特定のノードが管理機能を実施してもよいと結論づけるステップと
をさらに含む、請求項９２に記載の方法。
前記評判の前記適切性が、前記特定のノードのある期間にわたる挙動に基づいて判断される、請求項９３に記載の方法。
前記評判の前記適切性が、前記評判に格納された値が前記ネットワーク中の他のノードに比べて相対的に高いことに基づいて判断される、請求項９３に記載の方法。
前記値が外部的に決定された値で初期化され、次いで、その値が前記特定のノードと前記ネットワーク中の他のノードとの対話に基づいて動的に改訂される、請求項９５に記載の方法。
前記管理機能が、前記主張を受信した前記ノードに、トラフィックを前記特定のノードに複写するよう求める、請求項９２に記載の方法。
前記受信ノードが、前記特定のノードが前記管理機能を実施してもよいと結論づけた場合には、前記受信ノードのトラフィックを複写するステップをさらに含む、請求項９７に記載の方法。
前記管理機能が、前記主張を受信した前記ノードに、前記ノードのトラフィックの１つまたは複数のカテゴリを前記特定のノードに複写するよう求める、請求項９２に記載の方法。
前記管理機能が、前記主張を受信した前記ノードに、ノードの評判を含むあらゆるトラフィック、あるいはノード間のコンテンツを送信するあらゆるトラフィックを前記特定のノードに複写するよう求める、請求項９２に記載の方法。
前記管理機能が、前記主張を受信した前記ノードに、前記受信ノードに関する情報を前記特定のノードに返すよう求める請求項９２に記載の方法。
前記受信ノードが、前記特定のノードが前記管理機能を実施してもよいと結論づけた場合にのみ、前記要求された情報を返す、請求項１０１に記載の方法。
前記要求された情報が前記受信ノードに格納された評判である、請求項１０１に記載の方法。
前記要求された情報が前記受信ノードに格納されたコンテンツである、請求項１０１に記載の方法。
前記要求された情報が前記受信ノードに格納されたコンテンツの横断パスである、請求項１０１に記載の方法。
前記特定のノードが前記管理機能を実施してもよいと前記受信ノードが結論づけ、かつ前記受信ノードが発行したチャレンジに前記特定のノードが正常に応答した場合にのみ、前記受信ノードが前記要求された情報を返送する、請求項１０１に記載の方法。
前記特定のノードが前記管理機能を実施してもよいと前記受信ノードが結論づけ、かつ前記要求のデジタル署名で前記特定のノードが前記要求を送信したことが検証された場合にのみ、前記受信ノードが前記要求された情報を返送する、請求項１０１に記載の方法。
前記管理機能が、前記主張を受信した前記ノードに、前記受信ノードに格納された情報を変更するよう求める、請求項９２に記載の方法。
前記特定のノードが前記管理機能を実施してもよいと前記受信ノードが結論づけた場合にのみ、前記受信ノードが前記要求された変更を実施する、請求項１０８に記載の方法。
前記要求された変更が、前記受信ノードに格納された評判情報を上書きすることである、請求項１０８に記載の方法。
前記要求された変更が、前記受信ノードに格納されたコンテンツを上書きすることである、請求項１０８に記載の方法。
前記要求された変更が、前記受信ノードに格納されたコンテンツ横断パスを上書きすることである、請求項１０８に記載の方法。
非集中ネットワークにおいて管理機能を提供するシステムであって、
前記ネットワークに入るに際し、たとえ各ノードに割り当てられる現在のネットワーク・アドレスがエントリごとに変化したとしても前記ノードの識別が解決できるように、永続的ノード識別子を前記ネットワーク中の前記ノードに関連づける手段と、
評判を前記各ノードに関連づける手段であって、前記ノードの永続的ノード識別子を使用して各ノードの前記評判を見つける手段と、
特定のノードが、管理機能を実施できると主張する手段と、
前記特定のノード永続的ノード識別子を使用して前記ノードの前記評判を見つける手段と、
前記特定のノードが適切な評判を有する場合には、前記特定のノードが管理機能を実施してもよいと結論づける手段と
を含むシステム。
請求項１乃至１７、１９乃至４７、４９乃至７８、８０乃至８９、または、９１乃至１１２のいずれか１項に記載の方法の各ステップをコンピュータに実行させるためのコンピュータ・プログラム。