JP5438225B2 - 群知能を利用する大規模分散型システムにおける情報ルーティングのために枠組みを利用するシステムおよび方法 - Google Patents

Description

本発明の一実施形態は概して、ネットワークにおける情報ルーティング（つまり、ノードに、迅速に必要な情報を発見させて、ノードに、関連者（関連機器）に迅速に分散する技術）に係り、より詳しくは、特にクラウドコンピューティングアプリケーションにおける、群知能の枠組みの定義、および、ネットワークにおいて情報をルーティングするように定義された枠組みの利用に係る。

新たな「インターネット時代」には、ネットワークのリソースとなりうるもの（例えば利用可能なサービスおよび情報）は至る所に存在している。例えば、サーバクラウドコンピューティングアプリケーションでは、多数のデータセンター／サーバが協働して、クライアントにデータ格納／サービス／計算力を提供する。ネットワーク条件、ネットワークの振る舞い、およびアプリケーションの変化によって、リソース利用可能性は動的になる。データセンター／サーバを自動管理することで、クライアントのサービス要求ワークロード、信頼性、ロバストネス、およびパフォーマンス要件に対して迅速に応える必要がある。また、サーバ／クライアントセンターが提供するサービス／情報は、均質ではなく、リッチで多岐にわたる。サーバ／データセンターおよびクライアントが、これら多岐にわたる情報を効果的に管理して、動的な情報利用状況についていくことは容易ではない。ピアノード同士が協働して、サービスを提供したり消費したりするようなクライアント・クラウドコンピューティングアプリケーションでは、複数のクライアントマシンが起動したり停止したり、という動作を予測不可能に行う、という複雑性も加わる。従って、リソース管理システムは、各ノードの動的状況を把握して、ネットワークの残りのメンバーを更新するべく、かなり迅速に動く必要がある。

群知能を利用する技術については既に様々な研究がなされており、特に蟻の行動に基づく技術（ant-based technology）は、ネットワーク分散処理に纏わる課題の解決に多用されている。既存のネットワーク情報／リソース管理システムでは、集中型の手動モードを利用して、大規模ネットワークにおける情報／リソース分散／取得のサポートを試みる。このようなシステムでは、１つまたは一式のサーバがネットワークリソースを管理して、サーバは、常にクライアントが利用可能な状態を保つ努力をする必要がある。ネットワークが大型化を続ける昨今、ネットワークの動力学に遅れないで反応することは、益々難しくなってきている。

（１）Ｇｉａｎｎｉ Ｄｉ Ｃａｒｏ氏、Ｍａｒｃｏ Ｄｏｒｉｇｏ氏著の「蟻ネット：通信ネットワークの、分散された間接的なインタラクション（スティグメリ：Stigmergetic）による制御」人口知能研究ジャーナル（Journal of Artificial Intelligence Research）、９（１９９８）、３１７−３６５ページ、および（２）Ｒｕｕｄ Ｓｈｏｏｎｄｅｒｗｏｅｒｄ氏、Ｏｗｅｎ Ｈｏｌｌａｎｄ氏、Ｊａｎｅｔ Ｂｒｕｔｅｎ氏、Ｌｅｏｎ Ｒｏｔｈｋｒａｎｔｚ氏著の「電話通信ネットワークにおける蟻の行動を利用した負荷の均等化」、適応行動学論文誌（Adaptive Behavior）、５巻、２号、１９９６で、蟻の行動に基づくルーティングプロトコルを利用すると、大規模なネットワークにおいて効率的にルーティングを大まかにサポートすることができることが証明されている。

現在、群知能を利用したプロトコルに関する文献としては、Ｔａｏ Ｊｉａｎｇ氏およびＪｏｈｎ Ｓ．Ｂａｒａｓ氏による「ＭＡＮＥＴにおける蟻の行動を応用した適応的な信頼できる証拠の分散（Ant-Based Adaptive Trust Evidence Distribution in MANET）」、第２４回伝播コンピューティングシステム研究発表会報告書（ＩＣＤＣＳＷ'０４）２００４がある。この文献（以下「Ｊｉａｎｇ氏等」と称する）は、蟻の行動に基づく情報配信を提供する。この文献の著者たちは、蟻と見立てたエージェントを利用して、証明書（信頼できる証拠である）を暫定的なモバイルネットワーク（ＭＡＮＥＴ）から取得している。Ｊｉａｎｇ氏等の教示は、ルーティングテーブルによるルーティングではなくて、ノードが必要とする情報を直接探すためのシステムを教示している。ルーティングテーブルは、特定の情報を探すためのキーワードを利用する情報ルーティングテーブルで置き換えられている。探すべき唯一の情報は、対象となる実体が索引となっている証明書である。

本発明の特徴および利点は、以下の本発明の詳細な記載から明らかになる。

本発明の一実施形態における、蟻の行動に基づく情報分散ネットワークを提供するためのネットワークノードで見つかる基本コンポーネントのブロック図である。 本発明の一実施形態における、特定の機能パラメータを持つ情報またはサービスを提供するノードを特定するための情報ルーティングテーブルを例示する。 確率に関する情報を割り当てるためのビンの代表的な利用例を示す。 確率に関する情報を割り当てるためのビンの代表的な利用例を示す。 確率に関する情報を割り当てるためのビンの代表的な利用例を示す。 確率に関する情報を割り当てるためのビンの代表的な利用例を示す。 本発明の一実施形態における、ネットワーク上のクエリ蟻とクエリ応答蟻との間の通信を示すネットワーク上のノード例のブロック図である。 本発明の一実施形態における、ネットワーク全体のノードに対する情報／サービスの伝播を促すための追加情報を示す情報ルーティングテーブルの一例である。 本発明の一実施形態における、サービス／情報提供ノードによる、ネットワーク全体のノードに対する情報の伝播方法を示すフロー図である。 本発明の一実施形態における、確率と需要（popularity）尺度を示す追加エレメントを有するルーティングテーブルを表している。 本発明の一実施形態における、確率と需要（popularity）尺度を示す追加エレメントを有するルーティングテーブルを表している。 本発明の一実施形態における、情報／サービス提供ノードを探すべく、クエリ蟻をネットワーク全体に伝播させる方法を示すフロー図である。 本発明の一実施形態における、情報／サービス提供ノードを探すべく、クエリ蟻をネットワーク全体に伝播させる方法を示すフロー図である。 本発明の一実施形態において、ルーティングテーブルで各ノードの確率尺度の利用および需要尺度の利用に基づいて、ネットワークののどにクエリ蟻を伝播させる様子を示すグラフである。

本発明の一実施形態は、群知能を利用して、データ格納／コンピューティングリソースを必要としているクライアントと、必要なデータ格納／コンピューティングリソースを提供することのできるデータセンターとを１つにまとめることで、ネットワークでクラウドコンピューティングを可能とするシステムおよび方法である。Ｊｉａｎｇ氏等のプロトコルには幾つか課題があり、これを本発明の実施形態が解決している。Ｊｉａｎｇ氏等の技術では、証明書という１種類の情報しかサポートされていない。Ｊｉａｎｇ氏等の解決法は、特定の課題にしか利用できないが、本発明の実施形態では、複数の種類の情報にも対処できる柔軟な枠組みを提供している。さらに、本発明の実施形態では、Ｊｉａｎｇ氏等のプロトコルが実現していない、接続情報、ルーティングテーブル更新、および、古くなった情報等の他のデータ源を用いた情報テーブルの管理が提供される。

本発明の明細書における「一実施形態」といった言い回しは、その実施形態との関連で記載される特定の特徴、構造、または特性が、本発明の少なくとも１つの実施形態に含まれていることを示している。従って「一実施形態」といった言い回しは、明細書の随所に利用されていようとも、これらは必ずしも同じ実施形態のことを言っている場合ばかりではない。

説明の便宜上、特定の構成および詳細を述べて、本発明の完全な理解を促している。しかし当業者には明らかなように、本発明の実施形態は、記載されている特定の詳細がなくとも実施可能な場合がある。さらに、公知な特徴は省いたり簡略化して描いたりすることで、本発明を不当に曖昧にしないようにしている箇所もある。記載中には様々な例示を行う。これらは本発明の特定の実施形態を記載しているにすぎない。本発明の範囲はこれら例示に限定はされない。

既存の集中型の手動の情報分散／取得システムでは、大規模ネットワークにおける情報／リソース伝播／取得をサポートしたり、ユーザのロバストネスおよび信頼性要件に応えたりすることができない。本発明の実施形態は、蟻の行動に基づく方法を利用して、情報の発信および取得をサポートするために情報ルーティングテーブルを構築、維持、および利用する。これにより、ロバストネスの内在性および不良に強い性質といった利点が得られる。蟻の行動に基づくルーティングの本質により、ここに記載するプロトコルでは、複数の宛先が自然にサポートされるようになる。従って、機器の不良または悪意ある攻撃によって１つの宛先が不能になった場合でも、まだ別の宛先が複数選択可能である。自動ネットワーク負荷の均等化、および、トラフィックの混雑回避も行うことができるようになる。複数の宛先を確保すること、および、宛先選択を確率論的に行うことにより、異なる宛先の選択が可能となり、ネットワークの随所へトラフィックを伝播することができるようになる。このような構想により、トラフィックの混雑を回避できる。情報／サービスのダイバーシティも提供される。情報ルーティングテーブルは柔軟性に富み、多岐にわたる種類の情報を収容することができる。大規模分散ネットワークをサポートすることもできる。ネットワークの動力学の変化に効果的についていくことができるようになる。実施形態では、人口蟻の行う有効利用（exploitation）、探索（exploration）動作を組み合わせることで、ネットワークの変化に迅速に対応できる情報ルーティングテーブル更新メカニズムを記載している。蟻は、さらなる情報および高速サービスを受けるために、需要の高い（popular）ノードを利用する。どれが需要の高いノードかは、一定の時間窓においてパケットの最終目的ノードとして選択された回数を計測することにより判断することができる。また蟻エージェントは、ネットワークの変化を迅速に見つけるために、ネットワークをランダムに探索もする。

本発明の実施形態は、大規模な動的な分散型システムにおける情報発信をサポートするための枠組みを提唱する。ここで提唱されるメカニズムは、クラウドコンピューティング、クライアントクラウドコンピューティング等の複数の分野に応用することができる。情報／サービスを交換、消費、および提供する際に多数のノードを利用するような用途にはいずれであっても、ここで開示する枠組みを利用することができる。

本文献は、群知能に基づくコンピューティングに関してこれまで知られていなかった様々な新規なコンポーネントおよび特徴を開示する。分散型システムの多岐にわたる情報の管理をサポートする枠組みを開示する。また、情報を整理したり情報の発信を促したりするために、確率論的情報ルーティングテーブルを開示する。さらに、ネットワークから情報を取得するために利用される情報ルーティングテーブルが開示される。蟻エージェント、ノードメッセージ交換、ルーティングテーブル更新、および古くなるメカニズム（aging mechanism）を含む、記載される情報ルーティングテーブルの高速更新および管理のためのメカニズムも開示される。

実施形態によって、ネットワークが数千のノードを有することができ、ネットワークが非常にダイナミックなトポロジーを有することができ（例えばノードがネットワークに対する退出を迅速に行うことができる）、情報の配信および取得の制御に中央ポイントが不要であり、ネットワークのノードが、数多くの異なる種類の情報を提供することができ、複数のノードが同じ種類の情報またはサービスを提供することができ、また、情報／サービス利用が非常にダイナミックになる（つまり、変化が迅速になる）、といった特性がネットワークおよびサービスに提供される。加えて、本発明の実施形態による解決法は、有効性：新しい情報の更新を消費者に対して迅速に提供することができる、ロバストネス：ダイナミックなネットワーク変化に対する回復力が高い、効率性：情報ルーティングテーブルおよび情報ルーティングテーブルの管理により、各ノードおよびネットワークに対するオーバヘッドが比較的低くなる、といった要件を満たす。

図１は、本発明の一実施形態における、記載される情報ルーティング枠組みをサポートする各ノード１００に含まれている基本コンポーネントのブロック図である。一実施形態では、ルーティングテーブル１０１は、ノードアドレスを用いて、ネットワークの他のノードに到達するための情報を提供する。ここでは、ルーティングテーブルの利用が必要となる低レベルルーティングメカニズムがネットワークノードに存在することが想定されている。情報ルーティングテーブル１０３は、ここに開示する情報ルーティング枠組みの中核であり、本発明の実施形態における、群知能を利用する知性情報ルーティングを可能とする。情報ルーティングテーブル１０３は、データ利用可能性情報を提供する。サービス消費エージェント１０５は、情報ルーティングテーブルを利用して、所望のサービスおよびデータをネットワークから見つけたり、プルしたりする。サービス提供エージェント１０７は、ネットワークにサービスを提供し、自身のサービスを、他のノードの情報ルーティングテーブルのエントリという形態で広告する。これらコンポーネントについては後で詳述する。

一実施形態では、サービス消費エージェントおよびサービス提供エージェントは、「蟻」エージェント１１０と称されるものを利用することができる。エージェントを「蟻」と称する理由は、あたかも蟻が野原でするように、ネットワークを航行する性向がみられるからである。蟻は、適応性に富み、分権的であり、ロバストに課題を解決する社会的昆虫である。野原を探索した蟻は、自分の通った場所を示すためにフェロモンを残す。蟻同士は、環境への変更（例えばフェロモン）によって個体間が行う間接的な通信（スティグメリ（stigmery）と称される）によって通信を行う。蟻は、このスティグメリによって２地点間の最短経路を見つけることができる。

蟻は、フェロモン濃度に比例した確率で経路を選択する。フェロモン濃度の高い経路にいる蟻同士は、同じ領域を調査している（有効利用）。他の経路を利用する蟻は、新たな領域を探索している（探索）。

一実施形態では、情報ルーティングテーブル（ＩＲＴ）を、ネットワークを航行した蟻エージェントが残した情報のためのレポジトリとして利用する枠組みを提供する。つまり、ＩＲＴは、実際の蟻が残すフェロモンに等しい情報を含む。ノードは、クエリ蟻１１３を使って、必要なサービスまたは情報を探すためのネットワークに探索蟻を放すことができる。クエリＢ蟻１１５は、応答を送るために利用されてよい。情報蟻１１１は、サービスまたは情報を提供するノードが、自身が利用可能であることをアナウンスするために利用されてよい。

大規模ネットワークでは、各種類の情報／サービスが複数のノードにより提供されてよく、各ノードは、多数の種類の情報／サービスを提供することができる。図２は、情報ルーティングテーブル１０３の一実施形態の詳細を示している。情報ルーティングテーブルの特徴は、確率値を割り当てて、複数の提供ノードのランクとして示されている。図２では、情報ルーティングテーブル１０３が、現在のノードが興味を持っている情報／サービスの種類（Ｔ）２１０というエントリを含んでいる。Ｔは、情報ルーティングテーブルの情報／サービスの種類をインデックスする。各情報／サービスのタイプＴ_ｉ２１０について、最後のアクセスタイムスタンプ２１１を利用して、このサービスタイプに最後にアクセスしたときを記録する。タイムスタンプによって、まだ現在のノードがＴ_ｉに興味をもっているかを判断することができる。各情報／サービスタイプＴ_ｉについて、情報ルーティングテーブルは、Ｔ_ｉと、以下のような提供ノードの記述を提供する。
ｘ_ｉ：（提供ノードのアドレス２１５）。
Ｃ（ｘ_ｉ，Ｔ_ｉ）：（提供ノードの機能パラメータ２１７のセット）。ノードの機能を定量化するメトリックはすべてここで定義されてよい（例えば、計算力／メモリサイズおよび今利用可能な、計算力／メモリサイズ、待ち時間、コスト、セキュリティレベル等）。
Ｒｅｐ｛Ｘ_ｉ、Ｔ_ｉ｝：プロバイダの評価２２３により、過去の処理経験に基づいて、情報／サービス提供ノードの信頼度の尺度が提供される。パラメータは、移動時間窓における比率として計算されてよい（例えば、ある時間窓において成功した過去の処理数を過去の総処理数で除算して算出する）。加えて、信頼できるノード間の隣接するノード同士がこの情報を共有することで、より多くの情報を提供するようにしてもよい。これにより、利用したことがないノードであっても、プロバイダは評価を迅速に割り当てることができる。新たな情報／サービス提供ノードについてプロバイダの評価は、０．５またはその他の予め定められた格付けとすることができる。
最終更新タイムスタンプ：最終更新タイムスタンプ２１９は、このエントリが最後に更新されたときを記録する。最終更新タイムスタンプにより、現在のノードは、このエントリを廃れた（obsolete）情報で更新することがなくなる。
Ｐｒ｛ｘ_ｉ，Ｔ_ｉ｝：必要な情報／サービスを探す際に、同じ情報／サービスを提供する全てのノードからノードｘ_ｉを選択する確率２２１である。

Ｐｒ｛ｘ_ｉ，Ｔ_ｉ｝は、以下の要件を満たす。

ここでＸ_ｉ＝｛ｘ_１，ｘ_２，…，ｘ_ｍ｝は、情報タイプＴ_ｉを提供するノードセットである。この確率は、ノードの機能、プリバイダの評価、最終更新／エントリアクセス情報等の関数として計算される。ＩＲＴが情報／サービスタイプＴ_ｉを提供する全てのノードの情報を含むのではなく、代わりに、通信待ち時間、コスト、プロバイダの評価およびその他のメトリックに基づいて、ＩＲに記録するノードのサブセットを選択するようにしてもよい。この方法によると、ＩＲＴおよび検索動作を短くして、情報／タイプＴ_ｉを高速に、信頼性高く、安価且つ安全に提供することのできるノードのみを記録することができるようになる。高い機能、プロバイダの評価を有するノード、または、より最近更新されたノードは、通常、より高い確率値を有する。確率エントリ計算は、アプリケーション固有であって、変化してよい。確率計算方法の一例を示すが、これはあくまで例示である。

例示として、以下のメトリックを利用して、潜在的なサービスプロバイダセンターの評価方法を記述する、とする。メトリックとは、（１）サーバの処理能力、（２）メモリ／格納能力、（３）プロバイダの評価、（４）サービス提供ノードからサービス消費ノードまで移動するパケットの移動期間、（５）時間値Ｔ：エントリが最後に更新された時間である。言及したもののうち最初の４つのメトリックに対応する統計値は、ノードによって、Ｔ秒間の移動時間窓で得られた。実施形態では、４を超える数のメトリックがあっても、同じ方法を利用することができ、これに関して説明する。

まず、各メトリックを、最終的な確率値に組み合わせる前に処理する。以下の処理は、時間値Ｔを除いて、全てのメトリックを処理するために利用することができる。

先ず、最小と最大との間の間隔をＮビンで除算する。第２に、各ビンに、そのビンの嗜好度を示す値を割り当てる。例えば、処理能力に焦点を当てると、高い処理能力を有するビンが、低い処理能力のビンよりも高い値を割り当てられる。

メトリック値の処理に関しては、以下の記述を利用する。後述するように、情報蟻またはその他の手段がプッシュする情報により、過去Ｔ秒間に観察された最大サーバ処理能力がＰ_ｍａｘであり、Ｐ_ｍｉｎは、最小サーバ処理能力を示す。Ｐ_ｂｉｎ＝（Ｐ_ｍａｘ−Ｐ_ｍｉｎ）／Ｎ＿Ｐ＿間隔であり、ここでＮ＿Ｐ＿間隔は、処理能力を、Ｐ_ｍｉｎからＰ_ｍａｘまでの均一のサイズのＮ＿Ｐ＿間隔のバケットに分割する１０その他の数である。Ｐ_ｍｉｎからＰ_ｍａｘまでの間隔も、様々なサイズのバケットに分割することができる。Ｍ_ｍａｘは、過去Ｔ秒間に観察された最大格納サイズであり、Ｍ_ｍｉｎは、最小格納サイズである。Ｍ_ｂｉｎ＝（Ｍ_ｍａｘ−Ｍ_ｍｉｎ）／Ｎ＿Ｍ＿間隔であり、ここでＮ＿Ｍ＿間隔は、格納力を、Ｍ_ｍｉｎからＭ_ｍａｘまでの均一のサイズ（または可変サイズ）のＮ＿Ｍ＿間隔のバケットに分割する１０その他の数である。

Ｔ_ｍａｘは、過去Ｔ秒間に観察されたパケットが移動する最大移動期間であり、Ｍ_ｍｉｎは、最小移動期間である。Ｔ_ｂｉｎ＝（Ｔ_ｍａｘ−Ｔ_ｍｉｎ）／Ｎ＿Ｔ＿間隔であり、ここでＮ＿Ｔ＿間隔は、移動期間を、Ｔ_ｍｉｎからＴ_ｍａｘまでの均一のサイズ（または可変サイズ）のＮ＿Ｔ＿間隔のバケットに分割する１０その他の数である。Ｒｅｐ_ｍａｘは、過去Ｔ秒間に観察された様々な情報／サービスプロバイダについての、プロバイダの最大評価であり、Ｍ_ｍｉｎは、プロバイダの最小評価である。

Ｒｅｐ_ｂｉｎ＝（Ｒｅｐ_ｍａｘ−Ｒｅｐ_ｍｉｎ）／Ｎ＿Ｒｅｐ＿間隔であり、ここでＮ＿Ｒｅｐ＿間隔は、プロバイダの評価を、Ｒｅｐ_ｍｉｎからＲｅｐ_ｍａｘまでの均一のサイズ（または可変サイズ）のＮ＿Ｒｅｐ＿間隔のバケットに分割する１０その他の数である。図３では、各ビンにビン番号を割り当てている。各ビンに値が割り当てられている。処理能力、格納サイズ、および評価については、以下の関数を利用して銘々の各便に値が割り当てられている。関数とは、ビン値＝（ビン数×ビンの幅）^ｐ／（Ｎ＿Ｐ＿間隔またはＮ＿Ｍ＿間隔またはＮ＿Ｒｅｐ＿間隔×ビンの幅）^ｐであり、ｐ＞０であり、ｐ＝１および２のときのビン値が図４に示されている。

期間（またはその他の、小さな数が望ましいメトリック）については、ビン値の割り当てが以下のようになる。つまり、ビン値＝１−（ビン数）^ｐ／（Ｎ＿Ｔ＿間隔）^ｐであり、ｐ＞０であり、ｐ＝１および２のときのビン値は図５に示されている。ｐ＞０の場合、より多いビン数のほうが良いとされる傾向にある（時間においてはより少ないビン数のほうが良いとされる）。一実施形態では、以下の方法を利用して全てのメトリックを１つに組み合わせることができる。

値＝（α_１＊処理能力のビン値＋α_２＊格納サイズのビン値＋α_３＊プロバイダの評価のビン値＋α_４＊期間のビンの値）＊ｅｘｐ（−β＊（現在の時間−Ｔ））であり、α全部の合計＝１となる。αの正確な値は、その特定のメトリックの重要度に依存する。例えば、時間に感度を有する用途のノードでは、α_４を０．５に設定し、α_１＝０．０５、α_２＝０．０５、およびα_３＝０．４とする。他方で、βは、古くなっていくときの確率の低下を制御している（エントリが最近更新されたものではない場合）。図６は、βの値が、ｅｘｐ（−β＊（現在の時間−Ｔ））の値に及ぼす影響を捉えている。βの値が大きくなるにつれて、ｅｘｐ（−β＊（現在の時間−Ｔ））の値はより速く降下していることが分かるだろう。

いよいよ最終的な確率値を求めることができる。あくまで例として、ここではサービスタイプＴ_１について、５つのエントリがあると仮定して、５つの値を、値＿１、値＿２、値＿３、値＿４、および値＿５とする。ｎ番目のエントリの最終的な確率は、以下のようにして求められる。Ｐｒｏｂ＿ｎ＝値＿ｎ／（値＿１＋値＿２＋値＿３＋値＿４＋値＿５）。実施形態によっては、ある値に重みを乗せる、といった、他の確率計算方法を利用することもできる。

ノードがある情報／サービスタイプＴ_ｉを必要とするとき、そのノードは、サービスＴ_ｉを提供するノードの情報ルーティングテーブルのエントリを確かめる。ノードのパフォーマンスメトリック要件を満たすエントリがない場合、サービスクエリは失敗する。ノードは、後述するように情報クエリプロセスを起動して、ネットワーク上で情報／サービスを積極的に探し始めてよい。あるアプリケーションについてノードのパフォーマンスメトリック要件を満たすエントリが情報ルーティングテーブルに少なくとも１つある場合、以下の処理を実行して、パフォーマンスメトリック要件を満たすノードの確率を正規化することができる。この処理により、情報／サービス提供ノードを、同じサービスを提供する全ての適格なノードから選択することができる。情報／サービスＴ_ｉのクエリが生成されるといつでも、最初に、情報ルーティングテーブル内の、情報／サービスＴ_ｉ用のＬ＿アクセス＿時間＿Ｔ_ｉを更新する。次に、パフォーマンスメトリック要件を満たすこれらのエントリの確率を、以下のようにして正規化する必要がある。

現在のサービス要求のパフォーマンスメトリック要件を満たす全ての提供ノードを、セットＸ'_ｉ⊆Ｘ_ｉとなり、Ｘ_ｉ＝｛ｘ_１、ｘ_２、…、ｘ_ｍ｝は、情報タイプＴ_ｉを提供するノードセットである。従って、ｘが現在のサービス要求のパフォーマンスメトリック要件を満たす場合に限って、各ノードｘについてｘ⊆Ｘ'ｉとなる。従って、各ノードｘの確率ｘ∈Ｘ' _ｉは以下のように正規化することができる。

サービス提供ノードは、Ｐｒ（ｘ，Ｔ_ｉ）^{ｎｏｒｍａｌｉｚｅｄ}を直接利用するか、または、Ｐｒ（ｘ，Ｔ_ｉ）^{ｎｏｒｍａｌｉｚｅｄ}の関数を利用することでランダムに選択することができる。乱数生成器またはその他の方法によって、計算された正規化確率を利用してノードをランダムに選択することができる。例えば、乱数生成器は、ゼロと１との間の数を生成する。２つのノードａおよびｂのみが、それぞれ例えば確率０．２５および０．７５で存在している場合、且つ、計算された乱数が０．６に戻った場合には、乱数が０．２５と１．０との間に位置することになるので、ノードｂを選択する。生成された乱数が０．１５であれば、ノードａを選択する。このように、ノードの確率は、範囲０．０から１．０の間で分割される。次いでサービス要求を選択されたノードに送信することができる。実際の選択基準はアプリケーションによる。現在のノードにサービス提供するノードは１または複数選択することができてよい。厳格なランク付けとは異なり、確率を利用する方法は、同じ少数のランクの高い提供ノードに全てのノードがサービスを受けるために殺到することによるトラフィックの混雑を回避することができる。

一実施形態では、ノードの情報ルーティングテーブルを更新するために幾つかの更新メカニズムが提供される。後述する更新メカニズムでは、群知能パラダイムを利用することで、効果的にネットワークの情報利用を伝播させて更新することができる。「人工蟻エージェント」がこの目的を達成するために利用されてよい。例えばクエリ蟻エージェントを利用して、ネットワークから情報を引き出す（プルする）ことができる。情報蟻エージェントは、新たな情報／サービスを積極的に推進（プッシュ）したり、情報／サービスを必要としているノードに情報／サービスの更新を行ったりするために利用することができる。

加えて、情報ルーティングテーブル更新は、（１）情報／サービスを提供するノードからのサービス応答メッセージ、および／または、（２）より低い層のルーティングテーブルからの更新情報、（３）情報ルーティングテーブルエントリが古くなること、によってトリガされてよい。

図７は、本発明の一実施形態における、ネットワーク上のクエリ蟻とクエリＢ応答蟻との間の通信を示すネットワーク上のノード例のブロック図である。サービス提供ノード７１０は、サービス要求７０１に応じて応答メッセージ７０３を送信することができる。この応答メッセージ７０３がネットワーク７３０を通るとき、要求を発したノード７２０に戻る間に遭遇する、各ノード上の情報ルーティングテーブル７２３の情報更新をトリガ（７０３ａ）することができる。中間ノード７４０は、サービス提供ノードの新たに利用可能なサービスを記録するために、既存のテーブルエントリを更新したり、新たなエントリを作成したりすることができる。加えて、同じ情報／サービスを提供する現在のノードの情報ルーティングテーブルの全てのエントリの確率値を更新して、確率値を再計算して新たな更新を反映するようにする。

ルーティングテーブル７２１は、ネットワーク接続またはトポロジーに変更があったときに更新される。ノードが到達不可能になった場合には、ノードのルーティングテーブルから除去してよい。到達不可能なノードは、情報／サービスを提供することができない。従い、ノードをルーティングテーブルから除去すると、自動的に情報ルーティングテーブル７２３からも除去される。到達不可能なノードに関するエントリは、情報ルーティングテーブル７２３から削除して、同じ情報／サービスを提供する全ての残りのノードの確率値を再計算する。

情報ルーティングテーブル７２３の古いエントリは、廃れて現在のネットワーク／デバイス条件を反映していないことがある。加えて、一定の期間アクセスされなかった情報／サービスタイプは、その情報／サービスタイプの興味レベルが低いことの反映である。確率エントリ更新関数は、更新タイムスタンプを考慮に入れているので、これら古いエントリの確率エントリは、古くなっていくに連れて降下していく。確率エントリが低い閾値に達すると、廃れたり、または、重要ではなくなったり、興味がなくなったりしたということなので、情報ルーティングテーブルから除去されてよい。同じ情報／サービスタイプの残りのエントリの確率値を、これら変更を反映するように再計算する。加えて、情報／サービスタイプが長期的にアクセスされず、アクセスタイムスタンプを反映している閾値を超えると、全情報／サービスタイプを情報ルーティングテーブルから除去してよい。そして、この情報／サービスタイプは、ノードには興味のないものになったと想定される。

ネットワークを経由してノードに情報を伝播する方法は色々ある。ノードのルーティングテーブルの新たなエントリの一部を以下に説明する。大規模ネットワークで情報／サービスを見つけることを助ける情報ルーティングテーブルについては上述した通りである。本発明の一実施形態では、追加のエントリを情報ルーティングテーブルに加えて、ネットワークを介したノードへの情報／サービスの伝播を促進する。

図８は、各既存の情報タイプまたは新たな情報タイプＴ_ｉについての４つの追加フィールドである、（１）サービスについて質問するソースノード８０１、（２）クエリ蟻生成時間８０７、（３）パフォーマンスメトリック要件８０３、および、（４）クエリ蟻到着時間８０５という４つを追加した情報ルーティングテーブルの一例を示す。ソースノード質問サービス８０１は、クエリ蟻（後述する）の送信元であるノードアドレスである。クエリ蟻生成時間は、情報ルーティングテーブルに、最新の情報を確実に含めさせる目的に利用される。あるノードに到着した、同じクエリを含み同じノードからの新たなクエリ蟻が、より最近の生成時間である場合には、この新たなクエリ蟻の情報で、既存のエントリを更新する。次にクエリ蟻を次の新たなノードに送る。他方で、新たに到着したクエリ蟻が古い場合には、このクエリ蟻は破棄して次のノードには送らない。パフォーマンスメトリック要件８０３は、ソースノードを満たすために必要なキャパシティ要件およびプロバイダの評価を記す。クエリ蟻到着時間８０５は、クエリ蟻を受信した時間を格納する。現在の時間とクエリ蟻到着時間との間の差異を比較して、時間制限を越えて古くなったエントリは、情報ルーティングテーブルから削除することができる。

情報蟻は、新たなエントリ８０１、８０３、８０５、および８０７を利用して、情報／サービス利用更新を送信するノードを決定することができる。

情報蟻エージェントは、ネットワークの他のノードに提供することができる情報／サービスを迅速に伝播するためにノードにより利用される。各ノードでは、情報蟻エージェントをネットワークに送り、（１）ネットワークに新たに参加したデバイスによって追加された新たな情報／サービス、（２）負荷の変更として生じた機能パラメータの主要な変化（必要が満たされたときのキャパシティ増加、または、より新たなサービス要求が受信されたときのキャパシティ減少）、および、（３）デバイス／ノードが適切に遮断されたときの、情報／サービスの削除、といった処理に対応する情報を伝播させることができる。一部の実施形態では、情報蟻は、定期的な間隔で送信されて、ネットワーク上の情報を最新に保つことができる。

一実施形態では、情報蟻エージェントは、情報（Ｄ，Ｓ，Ｔ）：｛Ｓ‖Ｔ‖ｉＣＴｉｍｅ‖Ｄ‖ＰＭ｛Ｓ，Ｔ｝‖ｈｏｐ‖Ｄ＿タイプ＿フラグ｝というフォーマットを有している。こここで、Ｄは、情報蟻が赴く宛先ノードであり、Ｓは、情報／サービスが利用可能なソースノードアドレスであり、Ｔは、ノードが提供する情報タイプであり、ｉＣＴｉｍｅは、Ｓと情報タイプＴとに関する情報蟻の生成時間を記録しており、Ｓは、ノードが生成する各情報タイプについて別個のｉＣＴｉｍｅを維持する。タイプＴの情報を更新するための１つのバッチの情報蟻は、同じｉＣＴｉｍｅで生成される。新たな更新が生成されるたびに、ｉＣＴｉｍｅ値を、該更新が生成された現在時間に更新する。ＰＭ｛Ｓ，Ｔ｝は、機能パラメータ、ソースノードＳで提供される情報タイプＴのプロバイダの評価を含む。ｈｏｐは、情報蟻が今まで移動した距離を特定するホップカウント値であり、初期値ｈｏｐ＝０である。Ｄ＿タイプ＿フラグは、情報蟻の宛先Ｄが設定される方法を特定している。一実施形態では、Ｄ＿タイプ＿フラグは、以下のように設定されてよい。

宛先Ｄは、情報ルーティングテーブルを利用してＤ＿タイプ＿フラグ＝Ｓに設定される。これは、宛先Ｄが過去に情報タイプＴについて積極的にクエリしたことを示唆しており、おそらくは、将来もこの情報タイプの更新を受け取りたいと思っていることを示唆している。

宛先Ｄを、ルーティングテーブルを利用して設定すると、Ｄ＿タイプ＿フラグ＝Ｐとなる。これは、宛先Ｄが、その需要尺度に基づいて選択されたことを示唆しており、この場合い、情報タイプＴには興味がある場合もあろうし、ない場合もある。従ってこのようにして選択された宛先は、後のホッピングにて、情報蟻を、情報更新を実際に必要とするノードにリダイレクトすることができる。

一実施形態では、図９に示すプロセスを利用して、ネットワーク上に情報を伝播することができる。ノードが、情報タイプＴを提供することを開始したり停止したり、情報タイプＴの提供に関してノードの機能パラメータが大幅に変更されたりすると、ノードは、ブロック９０１で情報蟻を送信することで、この情報の伝播を開始する。

ブロック９０３で、上述したような、情報（Ｄ_１，Ｓ，Ｔ）、情報（Ｄ_２，Ｓ，Ｔ）、…、情報（Ｄ_ｎ，Ｓ，Ｔ）というフォーマットのＮ個の情報蟻を生成するが、ここで、Ｄ_１，Ｄ_２，Ｄ_ｎは、宛先ノードを示す。なお、ネットワークの混雑度についての推定、どのくらい更新が差し迫って必要か、情報タイプに対する興味レベル等に基づいて、各ノードはＮについて異なる値を利用することができることを理解されたい。宛先ノードは、ブロック９０５で以下のように選択されてよい。いずれかの情報ルーティングテーブルが、パフォーマンスメトリックパラメータがソースノードの要件を満たす、またはこれを超えるような情報タイプＴについての質問を行うソースノードを含んでいる場合、これらソースノードを宛先アドレスに設定して、Ｄ＿タイプ＿フラグ＝Ｓとする。Ｎを超える数のソースノードが情報ルーティングテーブルにある場合には、Ｎ個の最も需要のあるソースノードを、ルーティングテーブルの需要尺度を利用して選択して、Ｄ＿タイプ＿フラグ＝Ｓとすることができる。情報ルーティングテーブルにある、この情報タイプに興味を持つソースノードの数がこれより少ない場合には、残りの情報蟻を、まだルーティングテーブルで選択されていない最も需要のあるノードに送信して、Ｄ＿タイプ＿フラグ＝Ｐとして、ソースまたは中間ノードの情報ルーティングテーブルで特定されているように、これらのノードが特にこの情報を要求しなかったことを示す。情報ルーティングテーブルで情報が発見されなかった場合、宛先ノードを、需要尺度に従って、ルーティングテーブルのＮ個の最も需要のある宛先に設定してよい。ルーティングテーブルにあるテーブル数がＮより少ない場合には、情報蟻の数を減らしたり、情報蟻を重複するアドレスに送信したりすることができる。重複するアドレスに送信する場合には、情報蟻は、後述するように中間ノードによるルーティングおよび再ルーティングにおけるいくらかのランダムネスのせいで、ネットワークの別の箇所を通って伝播される場合もあることを理解されたい。従って情報は最終的に、重複を禁止されている場合よりも多くのノードに到達することになる。

ひとたび宛先ノードが情報パケット：情報（Ｄ，Ｓ，Ｔ）に設定されると、ブロック９０７で、ルーティングテーブルを利用して情報蟻をルーティングすることができる。各ホッピングで、情報蟻の受信ノードは、複数のアクションのいずれかを行うことができる。一例では、ノードｌが通信ルートにより宛先ノードｎに直接接続されない場合には、情報は、少なくとも１つの中間ノードｍを経由する必要がある。中間ノードｍは、ノードｌのルーティングテーブルで特定される。

一実施形態では、中間ノードは、一定の基準に基づいて、情報蟻の最終的な宛先アドレスを変更することができる。情報蟻の宛先アドレスは、Ｄ＿タイプ＿フラグ＝Ｐの場合に変更されてよい。Ｄ＿タイプ＿フラグ＝Ｐである情報（Ｄ，Ｓ，Ｔ）の情報蟻を受信すると、受信ノードは、自信の情報ルーティングテーブルを確かめる。Ｃ｛Ｓ，Ｔ｝およびＲｅｐ｛Ｓ，Ｔ｝を満たすパフォーマンスメトリック要件を有する情報タイプＴについて質問するソースノードが存在する場合には、宛先Ｄが、新たなソースノードにスイッチされ、Ｄ＿タイプ＿フラグ＝Ｓとしてよい。複数のソースノードが存在している場合には、最も需要のあるソースノードを宛先として選択してよい。同じ需要尺度を有する複数のソースノードについては、宛先をランダムに選択してよい。そして、中間ノードのルーティングテーブルを利用して情報蟻を宛先ノードに転送する。

受信ノードは、各｛Ｓ，Ｔ｝対について格納されているｉＣＴｉｍｅと、受信したｉＣＴｉｍｅ値とを比較して、情報蟻が新しいかを判断する（ブロック９０９）。受信したｉＣＴｉｍｅ値が保持しているｉＣＴｉｍｅ値以下であるとブロック９０９で判断されると、情報蟻を破棄する（ブロック９２１）。さもなくば、保持されているｉＣＴｉｍｅを、受信した値に更新して、蟻（情報）情報処理を続ける。

必要に応じて、新たなエントリ、または、情報ルーティングテーブルの既存のエントリの情報タイプＴに対する更新を、情報蟻に含まれている情報を使って行う（ブロック９１１）。次に情報タイプＴ_ｉについての確率値を再計算して、情報ルーティングテーブルのエントリに適用する。ブロック９１３で受信ノードが宛先ノードであると判断された場合には、更新は完了して、情報蟻を「キル（kill）」して、例えば更なる送信は行わない（ブロック９１５）。さもなくばＤ＿タイプ＿フラグをチェックして、蟻が需要尺度に従ってルーティングされたと示されているか（例えば、Ｄ＿タイプ＿フラグがＰに等しいか）を判断する（ブロック９２３）。

ブロック９２３でＤ＿タイプ＿フラグがＰに等しいと判断された場合には、適宜上述したように、情報蟻の宛先アドレスを変更して、Ｄ＿タイプ＿フラグをＳに設定する（ブロック９２５）。ホッピングカウントをブロック９１７で増分して、ホッピングカウントが最大閾値を超えているかを判断する（ブロック９１９）。ホッピングカウントが最大閾値を超えている場合には、蟻をキルして、転送は行わない（ブロック９２１）。ホッピングカウントが超えていない場合には、情報蟻を、ルーティングテーブルを利用して次のホッピングへとルーティングして（ブロック９０７）、宛先ノードに到達して、ホッピングカウントが最大閾値を越えるまで処理を続ける。ホッピングカウントを超えると、蟻をキルして（ブロック９２１）、転送は行わない。

ネットワークエージェント内のパラメータ数は、初期値に設定されており、後で、ネットワークのパフォーマンスに基づいて修正してよい。例えば、転送によりネットワークトラフィックの数が多くなりすぎた場合にはＮ（各情報更新について生成される情報蟻の数）を低減させて、ノードがタイムリーに蟻を受信していない場合には、増加させることができる。合理的な初期値は、Ｌｏｇ（ｎ）であり、ｎは、一部のネットワークでは、そのネットワークで到達可能なノード数である。最適なＮの値は、ネットワークの混雑度についての推定、どのくらい更新が差し迫って必要か、情報タイプに対する興味レベル等に基づいて決められてよい。ＨＯＰ＿ＭＡＸ（情報蟻が移動するノード数）は、ネットワークリソースに過度な負担をかけずに、より効果的に情報を伝播できるよう修正することができる。初期値は、ルーティングテーブルにより決定される、一番遠いノード（つまりネットワークの直径またはその一部）に到達するためのホッピング数であってよい。

上述した公表／サブスクライブまたはプル／プッシュという配信プロトコルにより、ネットワーク上のノードが、消費を希望する情報をサブスクライブできるようになる。ノードのサブスクリプション情報は、他のノードの情報ルーティングテーブルのエントリ同様に、ネットワーク上で利用可能である。従って、データまたはサービスが利用可能な場合、生成者は、データを効果的にサブスクライバに配信することができる。情報の生成者に積極的にネットワークのデータ利用情報をプッシュさせ、蟻エージェントを利用して情報クエリおよび発見を高速化することができる。本発明の実施形態は、蟻の行動を利用するメカニズムをノードで利用して、ネットワークに提供する利用可能情報／サービスを積極的且つ迅速にプッシュすることができる。情報蟻は、他のノードの情報ルーティングテーブルエントリを直接更新する。

この蟻の行動を利用する伝播によって、最近クエリを提供したノードへと情報蟻を積極的にリダイレクトすることで、最も情報を必要としているノードに情報宣伝を到達させることができる。情報／サービスを多く消費しているが、ソースノードの近隣にはないノードの情報発見は、クエリ蟻が移動した任意のノードの情報ルーティングテーブルに記録されている最近のクエリに基づいて、情報蟻の宛先を継続して調節しなおすことにより効率的に行うことができる。

情報ルーティングテーブルにクエリエントリが見つからない場合、需要尺度に基づいて最も需要のあるノードを情報蟻の宛先として選択することで、ネットワークにおける情報蟻の配信の範囲を増加させることができる。

一実施形態では、利用可能なリソースを探すために、日和見的にクエリ蟻を生成して転送することができる。情報蟻は、クエリ蟻を受信すると送信することができる。需要尺度をより低いレベルのルーティングテーブルに追加すると、クエリ蟻が、需要のあるノードに移動する確率を上げることができる。このフィーチャによると、クエリが需要のあるノードにより速く到達するので、情報クエリの効果および効率を高めることができる。ノードの需要は、ノードがある時間窓においてパケットの宛先ノードに設定される頻度を調べることで計測することができる。筆者は、需要のあるノードでは、情報の交換がより頻繁に行われると信じている。従って、需要のあるノードは、より多くの情報を提供することができ、情報がより頻繁に更新される。

共通のルーティングテーブルは、宛先ノードでインデックス化されて、各宛先ノードに到達する次のホッピングを特定する。蟻の行動を利用するルーティングアルゴリズムでは、各ノードにおけるルーティングテーブルには、各宛先ノードの複数のルートが記されていてよい。

図１０Ａは、一般的なルーティングテーブルを表す。なお、追加のエントリは、ルーティングテーブルを利用せねばならないレガシーコードが混乱しないように、追加テーブル等の別個のテーブルに格納したり、または、ルーティングテーブルに適切な索引とともに格納されたりしてよい。各エントリについて、宛先ノードに到達する方法に関する情報がある。ルーティングテーブル情報には、宛先ノード１００１、パケットを任意の宛先について転送できる次のホッピングノード１００３、任意の宛先について数多くの選択肢のなかから次のホッピングノードを選択する確率１００５、エントリのタイムスタンプ等が含まれてよい。同じ宛先ノードへと繋がる、次のホッピングノードの全ての確率エントリを合計すると、１になるべきである。ルーティングプロトコルによっては、実際のルーティングテーブルが、図１０Ａに示す以上の情報のサブセットを含みうるものもある。当業者であれば、元のエントリを修正せずに、ここで記載するようなルーティングテーブルに対する追加エントリに変更を加えることで、ネットワークまたはノードルーティングプロトコルが向上する場合もあることを理解する。

図１０Ｂは、元のルーティングテーブルに対する追加のエントリとして、需要尺度を示す。一実施形態では、ルーティングテーブルは、宛先の需要尺度として、追加のエントリ１００７を含んでいる。需要尺度は、そのノードがパケットの最終宛先として選ばれた頻度の関数として導出することができる。筆者は、需要のあるノードは宛先として選ばれる傾向が高いので、情報／サービスＴの情報ルーティングテーブルにより多い情報を含む傾向があることを観察している。より最新の情報である確率も高い。従って、クエリ蟻がこれらのノードを高い確率で訪れる場合には、より有用な情報に出会う確率も高くなる。これら需要のあるノードをクエリ蟻が訪れるよう影響を与えるために、一実施形態では、各宛先ノードについて追加のエントリをルーティングテーブルに追加する、という方法をとる。この新しいエントリが、その宛先ノードの需要尺度である。一例における需要尺度が、Ｃｏｕｎｔｅｒ（ｋ，Ｑ）１００７であり、これは、最近の時間窓のサイズＱで、ノードｋがパケットの最終宛先として選ばれた回数をカウントしたものである。なお、他の需要尺度を利用することもできる。

図１０Ｂに戻ると、テーブルエントリＰｒ｛Ａ，ｋ｝１０１１は、宛先ノードｋに到達するために次のホッピングノードＡを選択する確率を示している。クエリ蟻は、情報／サービスを必要とするノードにより送り出されるが、情報ルーティングテーブルに情報／サービスの需要を満たすだけの十分な情報がない。一実施形態では、クエリ蟻は、以下のフォーマットを利用する。クエリ｛Ｄ，Ｓ，Ｔ｝：｛Ｄ‖Ｓ‖ＣＴｉｍｅ‖Ｔ‖ＰＭ｛Ｓ，Ｔ｝‖ホッピング‖許可‖フラグ｝。ここでＤは、情報タイプＴを提供する宛先ノード実体またはアドレスであり、Ｓは、そのクエリを生成したソースノード実体またはアドレスであり、ＣＴｉｍｅは、Ｓに関連するクエリ蟻生成時間である。１つのバッチのクエリ蟻は、１つの同じＣＴｉｍｅを利用して生成される。新たなクエリが生成されるたびに、ＣＴｉｍｅをそのノードの現在の時間に更新する。Ｔは、要求されている情報／サービスを記述する情報タイプであり、ＰＭ｛Ｓ，Ｔ｝は、ソースノードＳが必要としている情報タイプＴのプロバイダの評価、機能パラメータを含んでおり、"ホッピング"は、クエリ蟻が今まで訪れたノードの数を特定するホッピングカウント値であり、開始時にはホッピング＝０である。"許可"は、このクエリ蟻の受信ノードが、Ｓの代わりに情報提供ノードに直接接続要求を出すことをノードＳが許可するか否かを示しており、"フラグ"は、このクエリ蟻の受信ノードが、クエリ蟻の宛先ノード実体／アドレスを変更することをノードＳが許可するか否かを示している。一実施形態では、ノードが情報／サービスタイプＴがネットワークに提供されている位置を見つける必要がある場合には、図１１Ａ−図１１Ｂに示すプロトコルを利用することができる。ソースノードが、ネットワーク上の別のノードからの情報／サービスに対する需要を発見した場合には、ソースノードは、ブロック１１０１で、情報／サービス提供ノード発見プロセスを開始する。

先ず、ブロック１１０３で、ソースノードの情報ルーティングテーブルが、パフォーマンスメトリック要件を満たすタイプＴ_ｉの情報／サービスのエントリを含むかを判断する。判断結果が肯定的である場合には、処理はブロック１１２１に進み、以降の処理の詳細は後述する。判断結果が否定的である場合には、ソースノードは、ネットワーク上のノードからの情報を必要とするので、必要情報を要求するためにクエリ蟻を送信する準備をする。Ｎ個のクエリ蟻を送信する（ブロック１１０５）。Ｎ個の蟻は、クエリ（Ｄ_１，Ｓ，Ｔ）、クエリ（Ｄ_２，Ｓ，Ｔ）、…、クエリ（Ｄ_ｎ，Ｓ，Ｔ）というクエリプロトコルを利用して生成することができ、ここで、Ｄ_１、Ｄ_２、…、Ｄ_ｎは、需要尺度によるソースノードのルーティングテーブルにおけるＮ個の最も需要のある宛先である（１００７）。ルーティングテーブルにある宛先がＮ個未満である場合には、クエリ蟻の数を減らしてもよいし、クエリ蟻を重複するアドレスに送信することもできるが、これに関しては情報蟻に関して上述した通りである。情報蟻およびクエリ蟻について蟻の数を減らす、または、重複するアドレスへ赴かせる、という判断は、ユーザの好み次第で、同じであっても異なっていてもよい。

ブロック１１０７で、次のホッピング宛先ノードを特定するためにソースノードのルーティングテーブルを利用する。次に、ルーティングテーブルに基づいてクエリ蟻を次のノードに送り、ホッピングカウントを１増分する。クエリ蟻は、最終宛先（要求されている情報またはサービスを提供しているノード）に到達するまでに、中間ノードを通る場合がある。クエリ蟻を受けると、中間ノードは、クエリ蟻を次のホッピングに送るために必要な処理の一環として、"ホッピング"と"ＣＴｉｍｅ値"とを確かめる。

次のホッピングまたは中間ノードでは、この中間ノードの情報ルーティングテーブルが、クエリ蟻が要求しているパフォーマンスメトリック要件を満たす、要求されている情報を含んでいないかを判断する（ブロック１１０９）。含んでいない場合には、中間ノードは、ホッピング＞ＨＯＰ＿ＭＡＸである場合、または、ＣＴｉｍｅが古い場合、または、中間ノードが最終宛先である場合に、クエリ蟻を破棄する（ブロック１１１５）。これは、クエリ蟻が古すぎたり、廃れた情報を搬送したりしていることを示唆しているからである。従って、より古い、または廃れたクエリ蟻は、無限に（ad infinitum）ネットワークを伝播しないことになる。クエリ蟻をブロック１１１７で破棄して、一部の実施形態では、情報を送り返して、ソースノードにクエリ蟻を破棄したことを通知してもよい。

ブロック１１１５で、クエリ蟻がまだ新しい（fresh）であると判断されると、現在のノードでこのクエリ蟻にさらなる処理を加えて転送して、ソースノードの代わりに、情報／サービスを探させてよい（ブロック１１１９）。クエリされているサービスが中間ノードの情報ルーティングテーブルに見つからない場合には、中間ノードは、クエリ蟻のホッピングカウント値を調べる。もし、ホッピング＜ＨＯＰ＿ＭＡＸである場合には、ホッピングを１増分して、クエリ蟻を次のホッピングに渡す（ブロック１１０７）。

一実施形態では、例えば各ｋ番目のホッピングで、クエリ蟻内の宛先ノードアドレスを変更することができる。ｋの初期値は、そのネットワークの同系性を示す度合い（degrees of relatedness）の調査結果に基づいて、６または７に設定されていてよい。ｋの値は、ネットワークの直径の関数に設定することもできる。クエリ蟻内の"フラグ"は、中間ノードが宛先アドレスの修正を許可されているかを示している。修正された宛先アドレスは、中間ノードのルーティングテーブルにおけるノードの需要を示す値に基づいて変更することができる。宛先アドレスを、より需要のある、より頻繁にアクセスされるノードに変更することで、クエリを、必要とされている情報を含む可能性の高いノードに伝播させることができるようになる。クエリ蟻の宛先は、以下の手順を踏んで変更されてよい。クエリ蟻の宛先アドレスは、フラグ＝真である場合に、ｋ番目のホッピングごとに変更することができる。クエリ蟻のクエリ｛Ｄ，Ｓ，Ｔ｝を受けとると、受信ノードは、ホッピングがｋの倍数であるかを判断する。フラグ＝真であり、"ホッピング"がｋの倍数である場合には、受信ノードは、確率尺度Ｐ_ｋを計算して、確率Ｐ_ｋのクエリ蟻の宛先ノードを、受信ノードのルーティングテーブルにおいて最も需要のある宛先ノードで置き換える、という決断を下すことができる。同じ需要尺度を有するノードが複数見つかる場合には、一実施形態では、１つの宛先をランダムに選択することができる。当業者であれば、ランダムに選択するアルゴリズムを複数思いつく。他の選択基準を利用して、同じ需要尺度である場合、他の選択基準を利用して宛先を選択することもできる。例えば一実施形態では、ノードリストにおいて、より低い（または高い）インデックスを有するノードを選択することもできるし、他の区別方法を利用することもできる。

図１２は、図１０Ａおよび図１０Ｂに示すように、ルーティングテーブルの各ノードの確率尺度、および、需要尺度を利用して、クエリ蟻をネットワークの各ノードに伝播させる際のグラフを示す。クエリ蟻の宛先を潜在的に変えることにより、クエリ蟻にネットワークのより大きな領域を探索させることができる。一実施形態では、確率尺度を求める公式は、以下の関数とすることができる。Ｐ_ｋ←ｆ（ホッピング、カウンタ（Ｘ，Ｑ））、カウンタ（Ｘ，Ｑ）は、選択された宛先ノードの需要尺度である。従って、確率尺度は、Ｐ_ｋ＝（１−ｅｘｐ（−γ＊ホッピング））＊（カウンタ（Ｘ，Ｑ））／ルーティングテーブルの全てのカウンタの合計（Ｘ，Ｑ）値）として計算することができる。

ソースノード付近のノードでは、（１−ｅｘｐ（−γ＊ホッピング））の値が小さいので、Ｐ_ｋも低い。ソースノード付近のノードは、同様の需要尺度を有する可能性が高いと考えられる。従って、これらの中間ノードが、宛先ノードを付近のノードに変更することを許されている場合、クエリ蟻も同様の場所にルーティングされる可能性が高い。

図１１Ａから図１１Ｂを再度参照すると、一実施形態では、到着するクエリ蟻の情報を含んでいる中間ノードが、クエリの"許可"フィールドで、情報／サービスを提供するノードを有するソースノードに接続するサービス要求を開始することを許可する、として定義されている場合がある。中間ノードの情報ルーティングテーブルが必要な情報またはサービスを含む、とクエリのパフォーマンスメトリック要件が特定している場合（ブロック１１０９参照）、中間ノードが接続要求を開始することができるかを判断する（ブロック１１１１）。場合によっては、セキュアな接続が必要とされ、"許可"フラグがＦＡＬＳＥであることもある。"許可"が下りていない場合、クエリＢ蟻（情報を戻す蟻）を生成して、中間ノードからコピーした、情報ルーティングテーブルの必要な情報エントリとともに、ソースノードに戻して（ブロック１１１３）、ソースノードが自身の情報ルーティングテーブルを更新して、自身で接続要求を行うことができるようにする。

一実施形態では、クエリＢ蟻のフォーマットは、クエリＢ（Ｄ，Ｓ，Ｔ）：｛Ｄ‖Ｓ‖ＣＴｉｍｅ‖Ｔ‖Ｘ＿内容｝であり、Ｄは、サービス／情報タイプＴを提供する、選択されたノードであり、Ｓは、情報／サービスを含むソースノードアドレスであり、Ｘ＿内容は、現在のノードの情報ルーティングテーブルのエントリの内容であり、ＣＴｉｍｅは、このメッセージが応答している対応するクエリ蟻の生成時間である。クエリＢ蟻メッセージで戻されるノードアドレスＤは、確率尺度Ｐｒ（Ｄ，Ｔ_ｉ）^{ｎｏｒｍａｌｉｚｅｄ}を利用して、情報ルーティングテーブルにリストされている情報タイプＴを提供する数多くの宛先ノードＤ_ｉからランダムに選択されてよい。宛先ノードＤへのルーティングは、受信ノード（または現在のノード）のルーティングテーブルを利用して行う。

中間ノードが接続要求を開始することを許可されている場合、図１１Ｂに示すように処理をブロック１１２１に進めることができる。１を超える数のノードがパフォーマンスメトリック要件に合致している場合には、上述したように情報ルーティングテーブルの確率情報を利用して、可能性のあるノードのうち１つだけをサービス要求の宛先として選択する。従って、サービス要求それぞれは、確率係数に基づいて、それぞれ異なる利用可能なノードに接続することとなる。これにより、サービス要求に対して同じノードばかりを選択してしまいオーバロードが生じる、というようなことがなくなる。サービス要求は、選択されたノードに送られる（ブロック１１２３）。

サービス要求を受信するノード（宛先ノード）は、応答メッセージを送信してよく、これは、ノードの通常の（レガシー）ルーティングテーブルを介してルーティングされる（ブロック１１２５）。一実施形態では、応答メッセージは通常のルーティングテーブルプロトコルを介してネットワーク内をルーティングされるので、情報／サービスがローカル情報ルーティングテーブルに存在していない場合には、各中間ノードの情報ルーティングテーブルを更新するか、または、新たなエントリを追加する（ブロック１１２７）。

一実施形態では、要求を発しているノードが、情報／サービスの宛先ノードが到達不可能であると知り（例えば、応答を受信しない場合、または別のノードにより、要求を発しているノードに対して、宛先ノードがオフラインであると通知された場合等）ルーティングテーブルからそのノードを消去すると、要求を発しているノードは、エントリを完全に除去してしまうのではなくて、到達不可能なノードの情報ルーティングテーブルエントリの確率を少量、または閾値未満に下げるようにすることもできる。この場合、到達不可能なノードが短期間だけオフラインであるような場合（例えばメンテナンスのため等で）、前は到達不可能だったノードがオンラインに戻り、情報蟻を受けとり始めると、情報ルーティングテーブルの確率は徐々に上がる。需要のあるノードまたは付近のノードについては、多くの情報蟻が迅速に受けとられ始めるので、確率を前のレベルに上げる。到達不可能なノードの確率を調節した後で、要求を発するノードは、情報ルーティングテーブルで更新された確率値に基づいて情報／サービスのノードを選択する。到達不可能なノードが長時間オフラインである場合には、オンラインに戻るまで、または、古い情報を有しているためにこのエントリを削除するまでは、このノードの確率はゼロに近づく。ノードがオフラインになった場合、ルーティングテーブルのエントリが削除されていたとしても、情報ルーティングテーブルの情報は維持するほうが望ましいが、これは、オンラインに戻った際に、このノードが需要のあるノードであったり、特に高いパフォーマンスノードになったりする可能性があるからである。

一実施形態では、ソースノードＳがクエリＢ蟻またはサービス応答メッセージを、時間窓ｔ_１中にどのノードからも受け取らない場合、Ｓは、別のクエリ蟻のバッチを生成してもよい。クエリ蟻生成時間ＣＴｉｍｅは、ノードの現在の時間に変更することができる。ノードが、クエリ蟻の複数のバッチを送信した後の時間窓ｔ_２中に、いずれのクエリＢ蟻またはサービス応答メッセージも受け取らない場合には（ｔ_２≧ｔ_１）、情報クエリプロトコルを中止することができる。

一実施形態では、クエリ蟻について２つの時間制限ｔ_１、ｔ_２を設けている。これらの時間制限は、最初は初期値に設定されていてよい。例えば、別のクエリ蟻のバッチを送信するまで応答を待つ時間である時間制限ｔ_１は、最初７００ｍｓに設定されていてよい。この値は、筆者がＴＣＰ ＲＴＴネットワークに対して実証研究を行った結果、得られた値である。時間制限ｔ_２は、ノードが、クエリ手順を完全にキャンセルするまで、一連のクエリ蟻から応答を待つ期間である。この期間の値は、この情報ルーティングシステムを用いて利用可能なサービスを探すアプリケーションに依存している。アプリケーションで、サービスを探す際に１分の遅延を許容することができる場合には、この期間の値を、１分に設定することができる。最小でも、アプリケーションは、ネットワークの一定の量をカバーするために、２以上のクエリ蟻バッチを許容するべきであろう。この場合、ｔ_１の初期値である７００ｍｓに鑑みると、ｔ_２＝１５００ｍｓまたは２２００ｍｓが、妥当な値であると思われる。

実施形態では、ネットワークまたはノードの管理者が、ネットワークパフォーマンスに関する実証的なデータ、または、シミュレーション研究に基づいて、幾つかの変数の初期値を変更することができてよい。

各情報クエリで生成されるクエリ蟻の数であるＮの値は、必要とされている緊急度、ネットワークトラフィックの負荷等に基づいて決定されてよい。いつクエリ蟻が、データキューではなくて優先的なキューを利用することが許されるか、の条件についても、場合に応じて変更してよい。

ネットワークリソースに過度な負担をかけずに情報を効果的に発見するためにクエリ蟻が移動するホッピングの最大数であるＨＯＰ＿ＭＡＸの値も変更可能である。

"許可フラグ"は、受信ノードによる接続要求の開始を制御しているが、これも変更可能である。情報転送を開始させるためにハンドシェークを開始することのできる受信ノード量は、"許可フラグ"を真または偽に選択的に設定することで変更することができる。一実施形態では、クエリ蟻で迅速に（つまり少量のホッピングカウントで）発見される受信ノードには、宛先ノードへのハンドシェークの開始が許可されていてよい。一方で、より古い蟻が（つまり大量のホッピングカウントで）発見するノードには、他のノードが既にハンドシェークを開始してしまっている可能性が高いので、ハンドシェークの開始を許可しない。

蟻を新たにする、またはキルするまで、システムに伝播させるための時間窓ｔ_１、ｔ_２は、検索範囲の広がりとオーバヘッドの低減との間のトレードオフに基づいて変化させてよい。

一実施形態では、本発明は、群知能を利用してネットワーク上で情報をルーティングするシステムであって、ネットワーク上の複数のノードであって、各ノードは当該ノードの少なくとも１つの処理ユニットに連結されているメモリにルーティングテーブルを格納している、複数のノードと、複数のノードのうちの、ネットワーク上の第２のノードに、情報および／またはサービスの少なくとも一方を提供する少なくとも１つのプロバイダノードと、複数のノードのうちの、プロバイダノードの情報および／またはサービスを消費する少なくとも１つの消費ノードと、複数のノードのうちの複数の中間ノードと、を備え、ネットワーク上のノード間の通信は、直接ノード間通信、または、少なくとも１つの中間ノードを介した通信のいずれかであり、ノード間の通信の実際のルートは、各ノードに常駐しているルーティングテーブルにより駆動される。

ネットワーク内の各プロバイダノードおよび消費ノードはさらに、ネットワーク上のノードが提供するサービスおよび情報タイプＴを特定する情報と、ネットワーク上のノードが提供するサービスおよび情報に興味を持つ他のノードのリストと、サービス／情報Ｔを提供する特定のプロバイダノードを選択する確率とを含む情報ルーティングテーブルと、一のノードのルーティングテーブルに対応するルーティングテーブル拡張であって、ルーティングテーブルは標準ネットワークプロトコルを利用し、ルーティングテーブル拡張は、需要尺度またはルーティングテーブルの一のノードが現在のノードと宛先ノードとの間の通信経路にある確率尺度のうち少なくとも一方を含む、ルーティングテーブル拡張とを有する。

各プロバイダノードはさらに、情報蟻とも称される情報パケットをネットワーク上の受信ノードに送信して、プロバイダノードが提供する情報／サービスＴの利用可能性をアナウンスするサービス提供エージェントを有し、ネットワーク上の受信ノードが情報蟻を受信すると、受信ノードは、（１）情報／サービスＴ、プロバイダノードのアドレス、情報／サービスＴの機能に対応する情報を特定するエントリの情報ルーティングテーブルへの追加、（２）情報ルーティングテーブルの、情報／サービスＴ、プロバイダノードのアドレス、情報／サービスＴの機能に対応する情報を特定する既存のエントリの更新、の一方を行い、情報蟻の受信により、さらに、受信された情報蟻をネットワーク上の別の受信ノードに選択的に転送させ、転送は、一部には情報蟻の新しさと、受信ノードが宛先ノードであるか、とに基づいて行われ、受信ノードはさらに、新たなエントリの追加後、または、情報ルーティングテーブルの既存のエントリの更新後に、サービス／情報Ｔを提供する各プロバイダノードを情報ルーティングテーブルから選択する確率を更新する。

各消費ノードはさらに、受信ノードに対してクエリ蟻を生成して送信する第１のサービス消費エージェントであって、各クエリ蟻は、選択された情報／サービスＴに関する情報の要求をもってネットワークを伝播して、複数の中間ノードは、一部にはルーティングテーブルの需要尺度または確率尺度に基づいて受信したクエリ蟻を他のノードに選択的に転送する第１のサービス消費エージェントと、受信ノードが要求されている情報を有する場合、受信したクエリ蟻に対する応答を生成して送信する第２のサービス消費エージェントとを有する。

一部の実施形態では、いずれのノードもが、プロバイダノードおよび消費ノードになることができる。また、ネットワークのいずれのノードもが、そのノードが情報／サービスＴを提供している側か、消費する側か、に関わらず、情報蟻、クエリ蟻、または、クエリ応答蟻を転送する中間ノードとなることができる。

一部の実施形態では、情報ルーティングテーブルは、情報ルーティングテーブルの各情報／サービスタイプＴ_ｉエントリについて、各ノードｘ_ｉがＴ_ｉの１人のプロバイダに対応しているようなノードｘ_ｉのリストを含んでよく、Ｔ_ｉに対応するエントリは、さらに、機能パラメータ、プロバイダの評価、最終更新タイムスタンプ、ノードｘ_ｉを選択する確率、および、最終アクセスタイムスタンプを含む。一部の場合には、プロバイダの評価を利用せず、代わりに、需要、確率または機能係数を利用して、情報／サービスまたは情報の転送のためにどのノードにアクセスするかを決定することもできる。一部の実施形態では、これらエレメントの組み合わせを利用して決定を行ってもよい。ルーティングテーブルおよび情報ルーティングテーブルの両方における情報の組み合わせを利用して、情報蟻およびクエリ蟻の宛先を設定することもできる。

一部の実施形態では、受信した情報蟻の選択的な転送は、宛先ノードアドレスが変更された場合に行われてよく、情報蟻のＤ＿タイプ＿フラグがＰに等しい場合のみに許可されてよい。一部の実施形態では、宛先ノードアドレスの変更は、ルーティング中のｋ番目のホッピングごとに限定されていてよい。

一部の実施形態では、プロバイダノードは、オフラインまたは停止状態からオンライン状態に復帰したことに呼応して、または、機能パラメータの変更に応じて、新たに追加、削除された情報／サービスを含む、プロバイダノードが提供する情報／サービスの利用可能状態をアナウンスするために、情報蟻の送信を自動開始するよう設定されている。プロバイダノードは、所定の間隔で情報蟻を送信することができてよい。

一部の実施形態では、消費ノードは、情報ルーティングテーブルの、必要な機能を提供するプロバイダノードのリストから、プロバイダノードを選択することができてよい。２以上のプロバイダノードが必要な機能を提供している場合、最も需要のあるノードを過度に利用しないように、確率係数を利用して選択を行うことができる。プロバイダノードが情報ルーティングテーブルにない場合には、消費ノードは、要求されている情報／サービスの利用可能性のあるプロバイダノードを探すために、ネットワーク全体にＮ個のクエリ蟻を送信してよい。応答が所定の期間受け取られない場合には、さらにＮ個のクエリ蟻を送信することができる。

当業者であれば、上述した特徴を様々に組み合わせて、ネットワーク上に提供する情報／サービスに関する情報を伝播させ、所望の情報／サービスに対応するプロバイダノードに関する情報を格納して、且つ、ネットワーク上で利用可能な情報／サービスに関する情報を所望する他の消費ノードに関する情報を格納することで、情報伝播を最大化して、時折あまり需要のないノードも利用することで、プロバイダノードの帯域幅を向上させることができることを容易に理解する。

ここに記載する技術は、特定のハードウェアまたはソフトウェア構成に限定されず、いずれのコンピューティング、消費者エレクトロニクス、または処理環境でも利用可能である。技術は、ハードウェア、ソフトウェア、またはこれら２つの組み合わせで実装することができる。

シミュレーションでは、プログラムコードは、ハードウェア記述言語、または、本質的に設計されるハードウェアを実行することが予期されるモデルを提供する別の機能記述言語で表すことができる。プログラムコードは、アセンブリ言語または機械言語であってよく、または、コンパイル可能な、および／または、解釈可能なデータであってよい。さらに、当技術分野では、ソフトウェアが、様々な形態で特定のアクションをとったり結果を生じたりする、と表現することがある。このような表現は、プロセッサにあるアクションをとらせたり、結果を生成させたりする処理システムによるプログラム実行を記述する簡略化された表現であるにすぎない。

各プログラムは、処理システムと通信するために、高レベルのプロシージャまたはオブジェクト指向プログラミング言語で実装されてよい。しかし、プログラムは、それが適切である場合、アセンブリ言語または機械言語で実装することもできる。いずれにしても、言語はコンパイルまたは解釈可能であってよい。

プログラム命令を利用して、命令をプログラミングされた汎用または専用処理システムに、ここで記載する処理を実行させることができる。または、処理を実行するためのハードワイヤ論理を含む特定のハードウェアコンポーネントが処理を実行してもよいし、プログラミングされたコンピュータコンポーネントおよびカスタムハードウェアコンポーネントの組み合わせが処理を実行してもよい。ここに記載する方法は、処理システムその他の電子デバイスを、これら方法を実行させるようプログラミングするために利用することができる命令を格納した機械アクセス可能媒体を含んでよい。

プログラムコードまたは命令は、例えば揮発性および／または不揮発性メモリに格納されていてよく、これらメモリには、格納媒体、および／または、関連する機械可読または機械アクセス可能媒体（固体メモリ、ハードドライブ、フロッピー（登録商標）ディスク、光ストレージ、テープ、フラッシュメモリ、メモリスティック、デジタルビデオディスク、ＤＶＤ等）が含まれてよく、さらには、機械アクセス可能生物学的状態保存ストレージ等の、よりエキゾティックな媒体（exotic medium）が含まれてよい。機械可読媒体は、情報を、機械が読み取れる形で格納、送信、または受信する任意のメカニズムを含んでよく、媒体には、プログラムコードが符号化された電子、光、音響、または他の形態の伝播信号または搬送波がアンテナ、光ファイバ、通信インタフェース等を介して通る有形の媒体が含まれてよい。プログラムコードは、パケット、シリアルデータ、パラレルデータ、伝播信号等の形態で送信されてよく、圧縮または暗号化された形態で利用することもできる。

プログラムコードは、それぞれプロセッサ、プロセッサが読み取れる揮発性および／または不揮発性メモリ、少なくとも１つの入力デバイスおよび／または１以上の出力デバイスを含む、移動型または固定型のコンピュータ、携帯情報端末、セットトップボックス、セルラーフォンおよびページャ、消費者エレクトロニクスデバイス（ＤＶＤプレーヤ、パーソナルビデオレコーダ、パーソナルビデオプレーヤ、衛星レシーバ、ステレオレシーバ、ケーブルＴＶレシーバを含む）その他の電子デバイス等のプログラミング可能マシン上で実装されるプログラムで実装されてよい。プログラムコードは、入力デバイスにより入力されるデータに適用されて、上述した実施形態を実行させ、出力情報を生成させることができる。出力情報は１以上の出力デバイスに適用されてよい。当業者であれば、開示されている主題の実施形態が、マルチプロセッサまたはマルチコアプロセッサシステム、ミニコンピュータ、メインフレームコンピュータ、および、実質的にどんなデバイスにも埋め込むことのできる広汎性または小型のコンピュータまたはプロセッサを含む様々なコンピュータシステム構成で実施可能であることを理解するであろう。開示されている主題の実施形態は、さらに、タスクまたは部分を、それぞれ通信ネットワークで繋がれた各遠隔処理デバイスが処理することのできる分散型のコンピューティング環境で実施することもできる。

各オペレーションは一例の処理として記載されている場合もあるが、オペレーションのなかには、実際には並列、コンカレント、および／または、分散型環境で実行されるものもあり、単一または複数のプロセッサマシンがアクセスできるローカルおよび／または遠隔格納されたプログラムコードで実施されるものもある。加えて、一部の実施形態では、オペレーションの順序を入れ替えたり、エレメントのサブセットを変更したりすることもできる。プログラムコードは、エンベデッドコントローラにより、またはこれと協働して利用されてもよい。

本発明を例である実施形態を参照して説明してきたが、本記載は限定的な意味合いはない。例示した実施形態の様々な変形例、および、本発明の他の実施形態も、当業者には明らかであり、これらも本発明の範囲内に含むことが意図されている。

Claims (37)

1. 群知能を利用してネットワーク上で情報をルーティングするシステムであって、
   前記ネットワーク上の複数のノードであって、各ノードは当該ノードの少なくとも１つの処理ユニットに連結されているメモリにルーティングテーブルを格納している、複数のノードと、
   前記複数のノードのうちの、前記ネットワーク上の第２のノードに、情報および／またはサービスの少なくとも一方を提供する少なくとも１つのプロバイダノードと、
   前記複数のノードのうちの、プロバイダノードの情報および／またはサービスを消費する少なくとも１つの消費ノードと、
   前記複数のノードのうちの複数の中間ノードと、
   を備え、
   前記ネットワーク上のノード間の通信は、直接ノード間通信、または、少なくとも１つの中間ノードを介した通信のいずれかであり、ノード間の通信の実際のルートは、各ノードに常駐している前記ルーティングテーブルにより駆動され、
   各プロバイダノードおよび消費ノードはさらに、
   前記ネットワーク上のノードが提供するサービスおよび情報のタイプを特定する情報と、前記ネットワーク上のノードが提供する前記サービスおよび情報に興味を持つ他のノードのリストと、サービス／情報のタイプを提供するために特定のプロバイダノードが選択される確率を示す確率尺度とを含む情報ルーティングテーブルと、
   一のノードの前記ルーティングテーブルに対応するルーティングテーブル拡張であって、前記ルーティングテーブルは標準ネットワークプロトコルを利用し、前記ルーティングテーブル拡張は、特定のノードが時間窓においてパケットの宛先ノードに設定される頻度の尺度である需要尺度または前記ルーティングテーブルの一のノードが現在のノードと宛先ノードとの間の通信経路にあり、特定のサービス／情報のタイプを提供するために特定のノードが選択される確率である確率尺度のうち少なくとも一方を含む、ルーティングテーブル拡張とを有し、
   各プロバイダノードはさらに、
   情報蟻とも称される情報パケットを前記ネットワーク上の受信ノードに送信して、前記プロバイダノードが提供する情報／サービスのタイプの利用可能性をアナウンスするサービス提供エージェントを有し、
   前記ネットワーク上の受信ノードが前記情報蟻を受信すると、前記受信ノードは、（１）前記情報／サービスのタイプ、前記プロバイダノードのアドレス、前記情報／サービスのタイプの機能に対応する情報を特定するエントリの前記情報ルーティングテーブルへの追加、（２）前記情報ルーティングテーブルの、前記情報／サービスのタイプ、前記プロバイダノードのアドレス、前記情報／サービスのタイプの機能に対応する情報を特定する既存のエントリの更新、の一方を行い、
   前記情報蟻の受信により、さらに、受信された前記情報蟻を前記ネットワーク上の別の受信ノードに選択的に転送させ、前記転送は、一部には前記情報蟻の新しさと、前記受信ノードが宛先ノードであるか、とに基づいて行われ、前記受信ノードはさらに、新たなエントリの追加後、または、前記情報ルーティングテーブルの既存のエントリの更新後に、前記サービス／情報のタイプを提供する各プロバイダノードを前記情報ルーティングテーブルから選択する確率を更新し、
   各消費ノードはさらに、
   受信ノードに対してクエリ蟻を生成して送信する第１のサービス消費エージェントであって、各クエリ蟻は、選択されたサービス／情報のタイプに関する情報の要求をもって前記ネットワークを伝播して、前記複数の中間ノードは、一部にはルーティングテーブルの需要尺度または確率尺度に基づいて前記受信したクエリ蟻を他のノードに選択的に転送する第１のサービス消費エージェントと、
   前記受信ノードが前記要求されている情報を有する場合、受信したクエリ蟻に対する応答を生成して送信する第２のサービス消費エージェントと
   を有するシステム。
2. 一のノードは消費ノードおよびプロバイダノードの両方となり、前記第２のサービス消費エージェントはさらに前記サービス提供エージェントを有する請求項１に記載のシステム。
3. 一のノードは、プロバイダノードおよび消費ノードの両方となる請求項１に記載のシステム。
4. 前記情報ルーティングテーブルは、前記情報ルーティングテーブルの各サービス／情報のタイプのエントリについて、各ノードｘ_ｉがサービス／情報のタイプの一のプロバイダに対応しているノードｘ_ｉのリストを含み、サービス／情報のタイプに対応するエントリは、機能パラメータ、プロバイダの評価、最終更新タイムスタンプ、ノードｘ_ｉを選択する確率、および、最終アクセスタイムスタンプを含み、
   情報蟻およびクエリ蟻の宛先の設定は、前記ルーティングテーブルおよび前記ルーティングテーブル拡張、並びに、前記情報ルーティングテーブルを利用して決定される請求項１から請求項３のいずれか１つに記載のシステム。
5. 受信した前記情報蟻またはクエリ蟻の選択的な転送は、当該蟻を次の宛先にルーティングする前に、前記情報蟻の宛先ノードのアドレスを変更することで行われる請求項１から請求項４のいずれか１つに記載のシステム。
6. 前記宛先ノードのアドレスは、前記クエリ蟻とともに送信される１以上のフラグの値に基づいて、前記クエリ蟻のｋ番目のホッピングごとに変更される請求項５に記載のシステム。
7. 前記プロバイダノードはさらに、オフラインまたは停止状態からオンライン状態に復帰すると、前記プロバイダノードが提供する情報／サービスの利用可能性をアナウンスするために情報蟻の送信を自動開始する請求項１から請求項６のいずれか１つに記載のシステム。
8. 前記プロバイダノードはさらに、所定の間隔で、前記プロバイダノードが提供する情報／サービスの利用可能性をアナウンスするために情報蟻の送信を自動開始する請求項７に記載のシステム。
9. 消費ノードは、所望のサービス／情報のタイプを提供するノードのリストからプロバイダノードを選択して、前記リストは、各ノードについて対応する確率係数とともに前記情報ルーティングテーブルに含まれており、エントリが存在しない場合には、サービス／情報のタイプのプロバイダノードを探すために前記ネットワークにＮ個のクエリ蟻を送信する請求項１から請求項８のいずれか１つに記載のシステム。
10. 前記消費ノードはさらに、プロバイダノードの前記確率係数とともに、前記プロバイダノードを選択するために利用される乱数を生成する請求項９に記載のシステム。
11. 群知能を利用してネットワーク上で情報をルーティングするシステムであって、
    プロバイダノード、消費ノード、中間ノードを有する、前記ネットワーク上の複数のノードであって、一のノードは、プロバイダノード、消費者ノード、および中間ノードの任意の組み合わせであり、各ノードは当該ノードの少なくとも１つの処理ユニットに連結されているメモリにルーティングテーブルを格納している、複数のノードと、
    前記複数のノードのうちの、前記ネットワーク上の第２のノードに、情報および／またはサービスの少なくとも一方を提供する少なくとも１つのプロバイダノードと、
    前記複数のノードのうちの、プロバイダノードの情報および／またはサービスを消費する少なくとも１つの消費ノードと
    を備え、
    各プロバイダノードおよび消費ノードはさらに、
    前記ネットワーク上のプロバイダノードから利用可能な情報／サービスに対応して受信した情報をセーブする手段であって、前記情報／サービスに興味のある他のノード、前記利用可能な情報／サービスに対応する前記プロバイダノードの機能、および、選択された情報／サービスのために消費ノードが特定のプロバイダノードを選択する確率を示す確率尺度を特定することを含む手段と、
    前記受信した情報の転送先である、前記ネットワーク上のノードを、一部には、送信元のノードのルーティングテーブルに含まれ、時間窓において特定のノードがパケットの宛先ノードに設定される頻度の尺度である需要尺度と、前記情報の新しさと、前記受信した情報をセーブする手段が特定する前記情報／サービスに興味のある他のノードの要求および格納されている嗜好とに基づいて選択する手段とを有するシステム。
12. 前記受信した情報をセーブする手段は、情報ルーティングテーブルを含み、
    前記情報ルーティングテーブルは、前記情報ルーティングテーブルの各情報／サービスのタイプのエントリについて、各ノードｘ_ｉが情報／サービスのタイプの一のプロバイダに対応しているノードｘ_ｉのリストを含み、情報／サービスのタイプに対応するエントリは、機能パラメータ、プロバイダの評価、最終更新タイムスタンプ、ノードｘ_ｉを選択する確率、および、最終アクセスタイムスタンプを含み、
    情報の転送先の設定は、前記ルーティングテーブルおよび前記情報ルーティングテーブルを両方とも利用して決定される請求項１１に記載のシステム。
13. 前記受信した情報の転送先である、前記ネットワーク上のノードを選択する手段は、宛先の修正が許可されているかを判断して、許可されている場合には、一部には、前記ルーティングテーブルで特定されるノードの需要尺度と、前記情報の新しさと、前記情報ルーティングテーブルで特定される前記情報／サービスに興味のある他のノードの要求および格納されている嗜好とに基づいてノードの宛先のアドレスを選択的に修正する論理を含み、前記需要尺度は、時間窓において特定のノードがパケットの宛先ノードに設定される頻度の尺度である、請求項１２に記載のシステム。
14. 前記ノードの宛先のアドレスは、前記情報とともに送信される１以上のフラグの値に基づいて、受信された前記情報の前記ネットワークでのｋ番目のホッピングごとに変更することを許可されている請求項１３に記載のシステム。
15. ネットワーク上の消費ノードであって、
    メモリに連結されている少なくとも１つのプロセッサユニットと、
    標準ネットワークプロトコルを利用し、前記メモリに格納されているルーティングテーブルであって、前記ルーティングテーブルの一のノードが、前記消費ノードと宛先ノードとの間の通信経路にあり、特定のノードが特定のサービス／情報のタイプを提供するために選択される確率である確率尺度または時間窓において特定のノードがパケットの宛先のノードに設定される頻度の尺度である需要尺度のうち少なくとも一方を含むルーティングテーブルと、
    前記ネットワーク上のプロバイダノードが提供するサービスおよび情報のタイプを特定する情報と、前記ネットワーク上のノードが提供する前記サービスおよび情報に興味を持つ他のノードのリストと、サービス／情報のタイプを提供するために特定のプロバイダノードが選択される確率を示す確率尺度とを含む、前記メモリに格納されている情報ルーティングテーブルと、
    受信ノードに対してクエリ蟻を生成して送信する第１のサービス消費エージェントであって、各クエリ蟻は、選択されたサービス／情報のタイプに関する情報の要求をもって前記ネットワークを伝播して、前記ネットワーク上の複数の中間ノードは、一部にはルーティングテーブルの需要尺度と確率尺度とに基づいて前記受信したクエリ蟻を他のノードに選択的に転送する、第１のサービス消費エージェントと、
    前記ノードが受信ノードであり、前記要求されている情報を有する場合、受信したクエリ蟻に対して応答を生成して送信する第２のサービス消費エージェントと
    を備える消費ノード。
16. 前記消費ノードは消費ノードおよびプロバイダノードの両方となり、前記第２のサービス消費エージェントはさらにサービス提供エージェントを有する請求項１５に記載の消費ノード。
17. サービス／情報のタイプを、サービス／情報のタイプの要求に応じて提供するプロバイダノードにさらに接続して、接続のための前記プロバイダノードの選択には、前記情報ルーティングテーブルに格納されている情報に基づいて行われ、前記情報には、要求されているパフォーマンス要件、前記プロバイダノードを選択する確率、プロバイダノードの評価、およびプロバイダノードの機能パラメータが含まれる請求項１５または請求項１６に記載の消費ノード。
18. 第２の消費ノードからサービス／情報のタイプについてクエリ蟻を受信すると、サービス／情報のタイプを提供するプロバイダノードに前記第２の消費ノードを接続し、接続のための前記プロバイダノードの選択は、前記情報ルーティングテーブルに格納されている情報に基づいて行われ、前記情報には、要求されているパフォーマンス要件、前記プロバイダノードを選択する確率、プロバイダノードの評価、およびプロバイダノードの機能パラメータが含まれ、前記接続の許可は、前記クエリ蟻の許可フラグに基づいて行われる請求項１５から請求項１７のいずれか１つに記載の消費ノード。
19. 前記情報ルーティングテーブルが前記要求されている情報を有さない場合には、受信したクエリ蟻を前記ネットワーク上の他のノードに選択的に転送し、前記情報ルーティングテーブルが前記要求されている情報を有する場合には、前記要求されている情報を含む情報応答蟻を、前記クエリ蟻を送信したノードに送信する請求項１５から請求項１８のいずれか１つに記載の消費ノード。
20. １以上のプロバイダノードが送信する情報蟻を受信すると、前記情報ルーティングテーブルのサービス／情報のタイプを提供および要求するノードに関する情報を更新する請求項１５から請求項１９のいずれか１つに記載の消費ノード。
21. 提供されたサービス／情報のタイプに対応する情報を有するプロバイダノードが送信した情報蟻を受信すると、前記情報ルーティングテーブルを更新する論理をさらに備える請求項１５から請求項２０のいずれか１つに記載の消費ノード。
22. 古い、廃れた（obsolete）受信情報およびクエリ蟻を破棄する論理をさらに備える請求項２１に記載の消費ノード。
23. ネットワーク上のプロバイダノードであって、
    メモリに連結されている少なくとも１つのプロセッサユニットと、
    標準ネットワークプロトコルを利用し、前記メモリに格納されているルーティングテーブルであって、前記ルーティングテーブルの一のノードが、消費ノードと宛先ノードとの間の通信経路にあり、特定のサービス／情報のタイプを提供するために特定のノードが選択される確率である確率尺度または時間窓において特定のノードがパケットの宛先ノードに設定される頻度の尺度である需要尺度のうち少なくとも一方を含むルーティングテーブルと、
    前記ネットワーク上のプロバイダノードが提供するサービスおよび情報のタイプを特定する情報と、前記ネットワーク上のノードが提供する前記サービスおよび情報に興味を持つ他のノードのリストと、サービス／情報のタイプを提供するために特定のプロバイダノードが選択される確率を示す確率尺度とを含む、前記メモリに格納されている情報ルーティングテーブルと、
    情報蟻とも称される情報パケットを前記ネットワーク上の受信ノードに送信して、前記プロバイダノードが提供するサービス／情報のタイプの利用可能性をアナウンスするサービス提供エージェントと
    を備え、
    前記ネットワーク上の受信ノードが前記情報蟻を受信すると、前記受信ノードは、（１）前記サービス／情報のタイプ、前記プロバイダノードのアドレス、前記サービス／情報のタイプの機能に対応する情報を特定するエントリを前記情報ルーティングテーブルに追加して、（２）前記情報ルーティングテーブルの、前記サービス／情報のタイプ、前記プロバイダノードのアドレス、前記サービス／情報のタイプの機能に対応する情報を特定する既存のエントリを更新し、
    前記情報蟻の受信により、さらに、受信された前記情報蟻を前記ネットワーク上の別の受信ノードに選択的に転送させ、前記転送は、一部には前記情報蟻の新しさと、前記受信ノードが宛先ノードであるか、とに基づいて行われ、前記受信ノードはさらに、新たなエントリの追加後、または、前記情報ルーティングテーブルの既存のエントリの更新後に、前記サービス／情報のタイプを提供する各プロバイダノードを前記情報ルーティングテーブルから選択する確率を更新するプロバイダノード。
24. 前記プロバイダノードは受信ノードを備え、さらに、他のサービス／情報のタイプに関して他のプロバイダノードから受信した情報を記録して、前記他のサービス／情報のタイプに関して受信した情報を、前記ネットワーク上の他の受信ノードに選択的に転送する請求項２３に記載のプロバイダノード。
25. 前記プロバイダノードは、前記ネットワーク上の第２のプロバイダノードから別のサービス／情報のタイプを消費する消費ノードを備える請求項２３または請求項２４に記載のプロバイダノード。
26. サービス／情報のタイプをネットワーク上の消費ノードに提供する、前記ネットワーク上のプロバイダノードから、サービス／情報のタイプに対応する情報蟻を、（ａ）前記プロバイダノードまたは前記プロバイダノードに対応する新たな情報／サービスが、オンラインになること、（ｂ）前記プロバイダノードの機能パラメータの変更、（ｃ）前記プロバイダノードがオフラインになる、または、前記情報／サービスが停止されることに起因して、前記プロバイダノードから情報／サービスが利用不可能になること、または、（ｄ）自動定期プッシュ要件のうち少なくとも１つに呼応してプッシュする段階と、
    前記ネットワーク上のノードにクエリ蟻を送信する段階、および前記ネットワーク上のノードからクエリ応答蟻を受信する段階を有し、消費ノードが前記ネットワーク上で利用可能な情報／サービスに対応する情報をプルする段階と、
    前記クエリ応答蟻、および、前記ネットワークを伝播する情報蟻から受信した情報で、情報ルーティングテーブルを更新する段階と、
    一部には前記情報ルーティングテーブルと、ルーティングテーブルに含まれ、時間窓において特定のノードがパケットの宛先のノードに設定される頻度の尺度である需要尺度とに基づいて、情報蟻、クエリ蟻、および、クエリ応答蟻を前記ネットワークに選択的に転送する段階と、
    消費ノードからサービス要求を受信した後に、プロバイダノードが送信する応答メッセージに含まれる情報により、中間ノードおよび消費ノードの前記情報ルーティングテーブルを更新する段階と
    を備える方法。
27. 前記情報ルーティングテーブルは、前記ネットワーク上のプロバイダノードが提供する情報／サービスのタイプを特定する情報と、前記ネットワーク上のノードが提供する前記サービスおよび情報に興味を持つ他のノードのリストと、情報／サービスのタイプを提供するために特定のプロバイダノードが選択される確率を示す確率尺度とを含む請求項２６に記載の方法。
28. 前記ルーティングテーブルは標準ネットワークプロトコルを利用し、前記ルーティングテーブルの一のノードが、前記消費ノードと宛先ノードとの間の通信経路にあり、特定のサービス／情報のタイプを提供するために特定のノードが選択される確率である確率尺度または時間窓において特定のノードがパケットの宛先ノードに設定される頻度の尺度である需要尺度のうち少なくとも一方を含む請求項２７に記載の方法。
29. プッシュされた情報蟻の宛先アドレスを新たな宛先アドレスに選択的に変更する段階をさらに備え、
    前記新たな宛先アドレスは、消費ノードの興味およびノードの需要の少なくとも一方に基づいて選択される請求項２６から請求項２８のいずれか１つに記載の方法。
30. 古い、廃れた受信情報およびクエリ蟻を破棄する段階をさらに備える請求項２６から請求項２９のいずれか１つに記載の方法。
31. 前記情報ルーティングテーブルを更新する段階は、
    前記受信されたクエリ応答蟻および情報蟻に関連付けられている前記情報／サービスのタイプに対応するノードに関連付けられている確率を更新する段階と、
    別のノードからのサービス要求に応じてプロバイダノードが送信する応答メッセージに関連付けられている前記情報／サービスのタイプに対応するノードに関連付けられている確率を更新する段階と
    を有する請求項２６から請求項３０のいずれか１つに記載の方法。
32. 機械に、
    情報／サービスのタイプをネットワーク上の消費ノードに提供する、前記ネットワーク上のプロバイダノードから、情報／サービスのタイプに対応する情報蟻を、（ａ）前記プロバイダノードまたは前記プロバイダノードに対応する新たな情報／サービスが、オンラインになること、（ｂ）前記プロバイダノードの機能パラメータの変更、（ｃ）前記プロバイダノードがオフラインになる、または、前記情報／サービスが停止されることに起因して、前記プロバイダノードから情報／サービスが利用不可能になること、または、（ｄ）自動定期プッシュ要件のうち少なくとも１つに呼応してプッシュする段階と、
    前記ネットワーク上のノードにクエリ蟻を送信する段階、および前記ネットワーク上のノードからクエリ応答蟻を受信する段階を有し、消費ノードが前記ネットワーク上で利用可能な情報／サービスに対応する情報をプルする段階と、
    前記クエリ応答蟻、および、前記ネットワークを伝播する情報蟻から受信した情報で、情報ルーティングテーブルを更新する段階と、
    一部には前記情報ルーティングテーブルと、ルーティングテーブルに含まれ、時間窓において特定のノードがパケットの宛先ノードに設定される頻度の尺度である需要尺度とに基づいて、情報蟻、クエリ蟻、および、クエリ応答蟻を前記ネットワークに選択的に転送する段階と、
    消費ノードからサービス要求を受信した後に、プロバイダノードが送信する応答メッセージに含まれる情報により、中間ノードおよび消費ノードの前記情報ルーティングテーブルを更新する段階と
    を実行させるためのプログラム。
33. 前記情報ルーティングテーブルは、前記ネットワーク上のプロバイダノードが提供する情報／サービスのタイプを特定する情報と、前記ネットワーク上のノードが提供する前記サービスおよび情報に興味を持つ他のノードのリストと、情報／サービスのタイプを提供するための特定のプロバイダノードが選択される確率を示す確率尺度とを含む請求項３２に記載のプログラム。
34. 前記ルーティングテーブルは標準ネットワークプロトコルを利用し、前記ルーティングテーブルの一のノードが、前記消費ノードと宛先ノードとの間の通信経路にあり、特定の情報／サービスのタイプを提供するために特定のノードが選択される確率である確率尺度または、時間窓において特定のノードがパケットの宛先ノードに設定される頻度の尺度である需要尺度のうち少なくとも一方を含む請求項３３に記載のプログラム。
35. プッシュされた情報蟻の宛先アドレスを新たな宛先アドレスに選択的に変更する段階をさらに実行させ、
    前記新たな宛先アドレスは、消費ノードの興味およびノードの需要の少なくとも一方に基づいて選択される請求項３２から請求項３４のいずれか１つに記載のプログラム。
36. 古い、廃れた受信情報およびクエリ蟻を破棄する段階をさらに実行させる請求項３２から請求項３５のいずれか１つに記載のプログラム。
37. 情報ルーティングテーブルを更新する段階は、
    前記受信されたクエリ蟻、クエリ応答蟻、および情報蟻に関連付けられている前記情報／サービスのタイプに対応するノードに関連付けられている確率を更新する段階と、
    別のノードからのサービス要求に応じてプロバイダノードが送信して受信された応答メッセージに関連付けられている前記情報／サービスのタイプに対応するノードに関連付けられている確率を更新する段階と
    をさらに実行させる請求項３２から請求項３６のいずれか１つに記載のプログラム。

Images