分散型メッシュネットワーク
【課題】分散型メッシュネットワークを実施するためのデバイス、方法、およびシステムを提供する。
【解決手段】メッシュネットワーク内にのコンピューティングデバイスは、当該コンピューティングデバイスがウェイク状態にある場合に動作する第１のストレージデバイスと、ウェイク状態であろうとスリープ状態であろうと動作する第２のストレージデバイスを備える。第１のストレージデバイスは、メッシュネットワーク内の既知のピアコンピューティングデバイスの最新リストを格納する。第２のストレージデバイスは、コンピューティングデバイスが提供するリソースのリスト、および、コンピューティングデバイスが確認したメッシュネットワーク内のコンピューティングデバイスのリストを格納するローカルブロックを有する。第２のストレージデバイスはさらに、メッシュネットワーク内の未確認のコンピューティングデバイスのリモートリストを格納する。
【解決手段】メッシュネットワーク内にのコンピューティングデバイスは、当該コンピューティングデバイスがウェイク状態にある場合に動作する第１のストレージデバイスと、ウェイク状態であろうとスリープ状態であろうと動作する第２のストレージデバイスを備える。第１のストレージデバイスは、メッシュネットワーク内の既知のピアコンピューティングデバイスの最新リストを格納する。第２のストレージデバイスは、コンピューティングデバイスが提供するリソースのリスト、および、コンピューティングデバイスが確認したメッシュネットワーク内のコンピューティングデバイスのリストを格納するローカルブロックを有する。第２のストレージデバイスはさらに、メッシュネットワーク内の未確認のコンピューティングデバイスのリモートリストを格納する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ピア・ツー・ピアネットワークの実施に関する。
【背景技術】
【０００２】
ピア・ツー・ピア分散型ネットワークは一般的に、他の種類のネットワークとは違って、集中管理サーバを多く利用することを要件とすることなくネットワーク機能を実現する。各コンピュータでの電力効率の改善の必要性が益々高まっている。大規模なネットワーク上に所与の時間に存在するコンピュータの数を考えると、コンピュータ１台当たりの電力を低減する方法およびデバイスを実現することによって、会社および／または産業全体では大幅な電力削減につながる。
【図面の簡単な説明】
【０００３】
本発明の例を図面に図示するが、本発明は図面に限定されるものではない。図面では、同様の参照番号は同様の構成要素を示すものとする。図面は以下の通りである。
【図１】メッシュネットワークに含まれるコンピューティングデバイスの実施形態を示す図である。
【図２】メッシュネットワークの実施形態を示す図である。
【図３】メッシュネットワークにおけるノード間親密度の実施形態を示す図である。
【図４】ローカルノードのメッシュネットワーク情報を更新する方法の実施形態を示すフローチャートである。
【図５】ローカルノードがメッシュネットワーク内の別のノードを確認して当該別のノードと関連メッシュネットワーク情報のやり取りを行う方法の実施形態を示すフローチャートである。
【図６】ローカルノードが第三者サーバに接触して当該第三者サーバによってリーダーノードにアップグレードされる方法の実施形態を示すフローチャートである。
【発明を実施するための形態】
【０００４】
分散型メッシュネットワークを実施するためのデバイス、方法、およびシステムの実施形態を説明する。
【０００５】
分散型メッシュネットワークは、多くのピア・ツー・ピアノードを備える。各ノードは、当該ノードが起きている（ウェイク）状態でも、寝ている（スリープ）状態であっても、メッシュネットワーク上のほかのノードにも利用可能な格納位置およびロジックを含む。２つのノードがやり取りを行う場合、メッシュネットワークへの参入が許可されていることを１以上の認証手順を経て互いに確認するとしてよい。両ノードは、各ノードが持つリソースに関する情報および各ノードがメッシュネットワーク上で存在を認識しているノードのリストである既知ノードリストを交換するとしてよい。第１のノードは、自身が既に認識しているノードのそれぞれから既知ノードリストを取得することによって、メッシュネットワークを通り抜けるとしてよい。こうして、第１のノードは、自身が本来所有していた既知ノードリストに基づき認識するにようになった任意の新しいノードと接触することができるようになる。
【０００６】
また、メッシュネットワークの外部の第三者サーバが、メッシュネットワークと第三者サーバとの間に通信トンネルを形成する指定リーダーノードを用いて、当該メッシュネットワークに存在するその他のノード全てに関する各ノード情報を提供するとしてよい。多くの実施形態に係るメッシュネットワークは、当該メッシュネットワーク内のノードの多くをスリープ状態としたまま、任意の１つのノードに当該メッシュネットワーク内の任意のほかのノードからリソースを取得させることができるので、当該メッシュネットワーク全体で電力が削減される。リソースを要求する要求ノードは、第三者サーバに要求を送り、第三者サーバは、リーダーノードを介して、リソースが要求されているターゲットノードに目覚め（ウェイクアップ）コマンドを送る。こうして、ターゲットノードはウェイク状態になり、要求ノードにリソースを提供して、スリープ状態に戻るとしてよい。
【０００７】
以下に記載する説明および請求項では、開示技術の「一実施形態」または「実施形態」と記載することがあるが、これは当該実施形態に関連付けて説明した特定のフィーチャ、構造、または特性が、開示技術の少なくとも１つの実施形態に含まれることを意味するものである。このため、本明細書では何度も「一実施形態」という記載が見られるが、必ずしも全てが同じ実施形態に言及しているとは限らない。以下に記載する説明および請求項では、「備える」、「含む」および「有する」といった用語を用いる場合があるが、意味は同じである。
【０００８】
図１は、メッシュネットワークに含まれるコンピューティングデバイスの実施形態を示す図である。コンピュータデバイスは、ノードと呼ばれることもあり、特にローカルノード１００と呼ばれることもある。ローカルノード１００は、コンピューティングデバイスとして構成されるとしてよい。例えば、ローカルノード１００は、デスクトップコンピュータ、ラップトップコンピュータ、ワークステーションコンピュータ、サーバ、ハンドヘルドコンピューティングデバイス、ゲーム機、テレビ用セットトップボックス、別のデバイスに一体化して設けられているコンピュータ（例えば、自動車ダッシュボード用コンピュータ）、または、別の形態のコンピューティングデバイスであってよい。ローカルノード１００は、システムメモリ１０２を備える。システムメモリ１０２は、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）等の揮発性メモリであってもよいし、または、フラッシュメモリ等の不揮発性メモリであってもよい。
【０００９】
ローカルノードは、数種類のストレージ、例えば、ディスクストレージ１０４（例えば、ハードドライブ）およびフラッシュストレージ１０６（例えば、フラッシュメモリ、フラッシュメモリドライブ等）を備えるとしてよい。ディスクストレージ１０４およびフラッシュストレージ１０６は、不揮発性ストレージデバイスであり、複数の電力サイクルにわたって情報を保存することができる。つまり、ローカルノードの電源が切られたり、または、スリープ状態になった場合でも、ディスクストレージ１０４およびフラッシュストレージ１０６は、次にローカルノードの電源が入った時に当該情報を利用可能な状態に情報を保持するとしてよい。
【００１０】
多くの実施形態において、ローカルノードはさらに、アウトオブバンド（ＯＯＢ）管理ロジック１０８を備える。ＯＯＢ管理ロジック１０８は、ローカルノード１００のほかの部分がスリープ状態または電源が入っていない状態において、動作する回路を有するとしてよい。ＯＯＢ管理ロジックの一例を挙げると、Ｉｎｔｅｌ（登録商標）社のアクティブ・マネジメント・テクノロジー（ＡＭＴ）がある。ＯＯＢ管理ロジック１０８には多くの用途があり、例えば、ハードウェア障害あるいはソフトウェア障害が発生したことによって、または、ローカルノード１００がスリープ状態にある等の多くの理由によってローカルノード１００が動作していない場合に、ローカルノード１００の少なくとも一部分に対するリモートアクセスを可能とする。多くの実施形態によると、ＯＯＢ管理ロジック１０８は、ローカルノード１００が標準的なインバンド管理方式を利用していないときにローカルノード１００が管理する方式であるアウトオブバンド方式でローカルノード１００を管理する。例えば、ローカルノード１００が電力供給が完全に行われている状態で通常動作状態にある場合、ローカルノード１００の中央プロセッサ（不図示）がシステムメモリ１０２内にあるオペレーティングシステム（ＯＳ）用の命令を実行しているとしてよい。これは、リモードノードがローカルノード１００と通信を実行する場合、ローカルオペレーティングシステムを介した標準通信チャネルが利用され得るので、インバンド動作と呼ばれることがある。一方、ローカルノード１００がスリープ状態である場合、中央プロセッサに対する電力供給は１００％でなくオペレーティングシステムは動作していないので、ローカルノード１００との間で利用可能な唯一の通信方法は、ローカルノード１００のほかの部分が動作していない場合に動作するＯＯＢ管理ロジック１０８を介したアウトオブバンド通信となり得る。
【００１１】
入出力（Ｉ／Ｏ）インターフェース１１０は、ローカルノード１００とノード外部の任意の実体との間の通信に用いられる。Ｉ／Ｏインターフェース１１０は、有線ネットワークインターフェース、アンテナを利用する無線ネットワークインターフェース、および／または、ローカルノード１００と１以上のその他の外部デバイスとの間のＩ／Ｏ通信を実現し得る１以上のその他のネットワークインターフェース方法のうち１以上を含むとしてよい。多くの実施形態によると、Ｉ／Ｏインターフェース１１０は、ローカルネットワーク２００に結合されている。ローカルネットワーク２００は、有線ネットワークまたは無線ネットワークであってよく、そして、インターネットに結合されているとしてもよいし、または、結合されていないとしてもよい。
【００１２】
ＯＯＢ管理ロジック１０８は、ローカルノード１００がアウトオブバンドモードにあり、ＯＯＢ管理ロジック１０８と他のコンピューティングデバイスとの間で通信を行うことが可能である場合に、Ｉ／Ｏインターフェース１１０の一部または全てを利用するとしてよい。他の実施形態によると、ＯＯＢ管理ロジック１０８は、外部と通信を行うために、別個に動作する集積化Ｉ／Ｏインターフェースを有する。
【００１３】
多くの実施形態によると、フラッシュストレージ１０６の少なくとも一部は、ＯＯＢ管理ロジック１０８専用である。このように、フラッシュストレージ１０６は、アウトオブバンド動作時、例えば、ローカルノード１００の他の部分がスリープ状態の場合には、ＯＯＢ管理ロジック１０８が利用可能およびアクセス可能である。
【００１４】
ローカルノード１００はさらに、ローカルフラッシュブロック１１２、リモートフラッシュブロック１１６、ディスクストレージブロック１１８、および、ＯＳメッシュエージェント１１４を備える。これらの構成要素は、図２を参照しつつ詳細に後述する。
【００１５】
図２は、メッシュネットワークの実施形態を示す図である。メッシュネットワークは、複数のノード（ノードＡ ２０２、ノードＢ ２０４、ノードＣ ２０６、ノードＤ ２０８、ノードＥ ２１０、および、ノードＦ ２１２）を備える。多くの実施形態によると、ノードＡからＦのうちいずれも、図１に示したローカルノード１００であってよい。つまり、ノードＡからＦは、図１に詳細を示したローカルノード１００が備える構成要素を全て有するとしてよい。例えば、ローカルノード１００の各構成要素は、一部を上記で説明したが、ノードＡ ２０２の詳細図に示している。図２に示した複数のノードは、ローカルネットワーク２００を介して互いに結合されている。ローカルネットワークは、複数のノードが互いに通信し合うことができるような通信ネットワークであればどのような形態であってもよい。ローカルネットワーク２００の例を挙げると、イーサネット（登録商標）有線ネットワーク、ＩＥＥＥ８０２．１１ベースの無線ネットワーク、セルラーネットワーク、ＷｉＭＡＸ等の広範囲無線ネットワーク、または、他の種類のネットワークがある。当該ネットワークは、ファイヤーウォール２１６を介して、インターネット２１４に結合されるとしてよい。ファイヤーウォール２１６は、ローカルネットワーク２００のゲートウェイコンピュータによって保持されるとしてよい。ゲートウェイコンピュータは、ローカルネットワーク２００とインターネット２１４との間で特定の種類の情報の通信を禁止するセキュリティプロトコルを含む。このため、ノードＡからＦは、全てローカルネットワーク２００のメンバーであるので互いに自由に通信し合うことができるが、ノードＡからＦの任意のノードと、リモートノード、例えば、ローカルネットワーク２００にインターネット２１４を介して通信可能に結合されているノードとの間の通信については、ファイヤーウォール２１６が実施するセキュリティ処理によって制限されることもある。
【００１６】
多くの実施形態によると、ローカルネットワーク２００は、分散型「メッシュ」ネットワークである。メッシュネットワークでは、当該ネットワーク内のノードがいずれも、ほかの全てのノードについて認識している必要はない。また、メッシュネットワークでは、全てのノードに関する情報を持つ中央ノードが必ず設けられているわけではない。メッシュネットワーク内の各ノードは、当該メッシュネットワークに含まれるノードのうち自身が知っているノードのリストを保持している（既知ノードは、知人ノードとも呼ばれるとしてよい）。この知人ノードリストは、フラッシュストレージ１０６内に保持されているローカルフラッシュブロック１１２に格納されるとしてよい。多くの実施形態によると、知人ノードリストの各項目は、対応する知人ノードのＩＰ（インターネットプロトコル）アドレスを含む。２つのノードは、互いを認識しており悪意のない実体であると互いに認めている場合、相手を「友人」と呼ぶとしてよい。各ノードは、ネットワーク内の他のノードに広告する一意的なメッシュ証明書を所有しているとしてよい。多くの実施形態によると、２つのノードが友人関係を構築するためには、ネットワークへの参入が許可されていることを証明する正当なメッシュ証明書を交換する必要がある。この交換は、さまざまな方式のうちいずれかで行われるとしてよいが、公開鍵であるメッシュ証明書と各ノードに一意的に設定されている秘密鍵とを組み合わせるハッシュアルゴリズム等の認証手順を含むとしてよい。
【００１７】
対照的に、第１のノードが第２のノードを認識しているが、第２のノードがメッシュ証明書の生成に失敗した場合、第１のノードは第２のノードを「敵ノード」と見なすとしてよい。第２のノードが友人ノードであっても敵ノードであっても、第１のノードが第２のノードを認識すると、第２のノードは第１のノードの知人ノードになるとしてよい。一部の実施形態では、ノードが保持している知人ノードリストは、各ノードと直接接触した最新時を示す時間スタンプを含むとしてよい。多くの実施形態によると、知人ノードリスト自体には、リストが更新される度に、バージョン番号および時間スタンプが付与される。知人ノードリストの更新では、ネットワークに新しく参加したノードの追加、ネットワークから抜けたノードの削除、ノードの友人／敵ステータスの変更等を行う。メッシュネットワーク内の各ノードは、リストに記載されており認識しているノードを全て監視することができる。所与のノードがメッシュ証明書を提示していない場合、この証明書なしのノードの知人ノードは、知人ノードリストに、証明書が無いことに関する警告を追加するとしてよい。
【００１８】
２つのノード間に信頼関係を構築するためには、メッシュ証明書を用いたセキュリティハンドシェイクを実行する必要があるとしてよい。一部の実施形態によると、ノードは別のノードとまず知人関係を構築し、この知人ノードを友人ノードに昇格させるためには、メッシュ証明書によるセキュリティ証明が必要となるとしてよい。他の実施形態では、第１のノードが、第２のノードを友人ノードと見なしている場合、第２ノードの友人であるノードは自動的にいずれのノードも自身の友人ノードと見なすとしてよい（つまり、友人の友人もまた友人）。これは、友人ノード間で予め定められている安全検査レベルのためであり、ある１つのノードが新しい知人ノードを新しい友人ノードと認証すると、他の友人ノードは全て、利用するメッシュ証明書ハンドシェイクの安全検査のレベルが同一であるので、この新しい知人ノードは自身の友人でもあると見なすことができる。
【００１９】
図３は、メッシュネットワークにおけるノード間親密度の実施形態を示す図である。ノードＡ ３００は、ノードＢ ３０２、ノードＣ ３０４、および、ノードＤ ３０６について知っているが、ノードＥ ３０８およびノードＦ ３１０については知らない。しかし、ノードＣ ３０４は、ノードＡ ３００の友人ノードであり、ノードＥ ３０８およびノードＦ ３１０を知っている。この場合、ノードＡ ３００は、ノードＥ ３０８およびノードＦ ３１０に関する情報について友人ノードであるノードＣ ３０４に要求して、既知の友人ノードのリストにこれら２つのノードを入れるとしてよい。
【００２０】
図２に戻って説明を続けると、各ノードは、既知の知人ノードのリストを保持する以外に、メッシュネットワーク内のほかのノードに提供することができるリソースのリストも保持している。リソースのリストは、ファイルメタデータ、例えば、全ての共有ファイルおよびファイルフラグメントの名称、サイズ、および、作成日時を含むとしてよい。他の実施形態によると、リソースには、ファイルメタデータ以外にも、ノードが提供可能なサービスおよび機能のリストが含まれるとしてよい。例えば、ノードＡ ２０２は、他のノードに関連するデータセットの一部分を格納しているとしてよい。これは、メッシュネットワークの各ノードがファイルの一部分を格納しており、自身が保有する部分を他のノードに提示するピア・ツー・ピアのファイル共有環境では一般的であるとしてよい。他の実施形態では、所与のノードが、リストに記載されているファイルを、ファイルの一部分ではなく、全て格納するとしてよい。
【００２１】
多くの実施形態によると、各ノードはＯＳメッシュエージェント１１４を有する。ＯＳメッシュエージェント１１４は、ノードがウェイク状態で１００％の状態で機能している場合に、ロードされるとしてよい。ＯＳメッシュエージェント１１４は、ＯＳが動作状態にある場合にバックグラウンドで実行されるプロセスであってよい。ＯＳメッシュエージェント１１４が提供する機能は、ＯＯＢ管理ロジック１０８が提供する機能の一部と同じであるとしてよい。つまり、ノードがスリープ状態にある場合、ＯＯＢ管理ロジック１０８がノード間通信およびリスト管理を実行して、ノードがウェイク状態にある場合、ＯＳメッシュエージェント１１４がノード間通信およびリスト管理を実行する。多くの実施形態によると、ＯＯＢ管理ロジック１０８が無いノードにＯＳメッシュエージェント１１４がロードされるとしてもよく、この場合、当該ノードがウェイク状態の場合にノード間通信を可能とするが、ＯＯＢ管理ロジック１０８がないノードは、スリープ状態の場合、ノード間通信を実行することができない。
【００２２】
所与のノードは、各友人ノードに接触して、各友人ノードから知人ノードのリストを受信して、知人ノードリストに含まれるノードに接触して、メッシュネットワーク内のナビゲーションを実現するとしてよい。このため、ＯＳメッシュエージェント１１４は、各友人ノードのローカルフラッシュブロックに保持されている知人ノードリストを読み出すとしてよい。このナビゲーションは、ノードがウェイク状態であろうとスリープ状態であろうと発生するとしてよい。これは、ナビゲーションを行うノードは、メッシュネットワーク内の別のノードがウェイク状態であろうとスリープ状態であろうと、この別のノードが、ＯＯＢ管理ロジック１０８によってスリープ状態でも保持されるローカルフラッシュブロックを含む限りにおいて、この別のノードに接触できるためである。多くの実施形態によると、ウェイク状態ではＯＳメッシュエージェント１１４が訪問ノードにローカル情報を提供し、スリープ状態ではＯＯＢ管理ロジック１０８が訪問ノードにローカル情報を提供する。一部の実施形態では、ノードが備えるＯＳメッシュエージェント１１４およびＯＯＢ管理ロジック１０８の両方が、ローカルフラッシュブロックから知人ノード情報およびリソース情報を取得して、訪問ノードに提供する。一部の実施形態によると、このノードがウェイク状態の場合に、知人ノード情報およびリソース情報をローカルフラッシュブロック１１２から取得されるとしてよい。このようにして、多くの実施形態において、所与のノードは、他のノードがウェイク状態かスリープ状態かに関わらず、メッシュネットワーク内のナビゲーションを完遂することができるとしてよい。
【００２３】
また、多くの実施形態では、所与のノードは、ネットワーク内をナビゲーションする場合、知人ノードリストおよびリソースリストを、訪問する各ノードに残すとしてもよい。訪問する側のノードは、訪問される側のノードのフラッシュストレージ１０６のリモートフラッシュブロック１１６にこの情報（リソースおよび知人ノード）を入れるとしてよい。一部の実施形態によると、訪問される側のノードがスリープ状態である場合、ウェイク状態になるまで、この情報はリモートフラッシュブロック１１６内にそのまま格納されるとしてよい。
【００２４】
訪問された側のノードがウェイク状態になると、このノードのＯＳメッシュエージェント１１４が、リモートフラッシュブロック１１６から情報を読み出して、訪問したノードが入れた情報を処理するとしてよい。この処理において、ＯＳメッシュエージェント１１４は、訪問したノードが入れた情報を、訪問したノードが残した知人ノードリストを比較することによって、確認するとしてよい。両方のリストに共通している知人ノードは、ローカルノードで既に確認されたノードである。訪問したノードの知人ノードのうちローカルノードの知人ノードリストに無い知人ノードがあれば、このような未知の知人ノードを確認するための処理をさらに実行するとしてよい。具体的には、訪問したノードの知人ノードリストに、ローカルノードのローカルフラッシュブロック１１２に保持されている知人ノードリストにはない知人ノードが１以上ある場合、ＯＳメッシュエージェント１１４は、未知の知人ノードに接触して、１以上の新たなノードとメッシュ証明書を交換して、１以上の新しいノードをローカルフラッシュブロック１１２が格納している知人ノードのローカルリストに追加するとしてよい。
【００２５】
さらに、新しい知人ノードのリソース情報は、ＯＳメッシュエージェント１１４によって利用されるとしてもよい。ローカルディスクストレージ１０４が格納しているディスクストレージブロック１１８は、メッシュネットワーク２００内の既知のノード全てについて既知の情報を全て格納しているとしてよい。例えば、ディスクストレージブロック１１８は、既知のノードそれぞれのＩＰアドレスおよび各ノードのリソースリストを含むとしてよい。多くの実施形態によると、各ノードについてほかの情報も同様に格納されるとしてよい。例えば、各知人ノードに対する平均ネットワークピング（ｐｉｎｇ）レイテンシが格納されているとしてよい。所与のノードのＯＳメッシュエージェント１１４は時折（当該ノードがウェイク状態である場合に）、メッシュネットワーク２００内のノードについて既知の情報をメンテナンスする目的で更新するとしてよい。具体的には、知人ノードリストに含まれている各ノードに接触して、各知人ノードに関して保有している情報を更新する。他のノードに関する情報の一部は、訪問ノードがリモートフラッシュブロック１１６に格納している情報から取得されるとしてよい。他のノードに関する他の情報は、ＯＳメッシュエージェント１１４が別のノードと積極的に接触する際に、メッシュネットワーク内のほかのノードから直接取得されるとしてよい。
【００２６】
所与のノードについて、ローカルフラッシュブロック１１２および／またはディスクストレージブロック１１８に格納されている知人ノード情報を、当該ノードがスリープ状態からウェイク状態に移行する度に、訪問ノードがリモートフラッシュブロックに格納した知人ノード情報と比較するとしてよい。訪問ノードが格納したリストが新しいノードのＩＰアドレスを含む場合（つまり、ＯＳメッシュエージェント１１４が保持している知人ノードリストにこの新しいノードが含まれていない場合）、ＯＳメッシュエージェント１１４は、新しいノードと接触して、新しいノードとメッシュ証明書を交換して新しいノードを確認して、ローカルの知人ノードリストに追加するとしてよい。
【００２７】
多くの実施形態によると、インターネット２１４には第三者（３Ｐ）サーバ２１８が結合されている。３Ｐサーバ２１８は、メッシュネットワーク内の全てのノードを記載したリストを保持しているとしてよい。当該リストは、各ノードのＩＰアドレスと、各ノードが提供するリソースを含む。３Ｐサーバ２１８は、ファイヤーウォール２１６の外側に位置しているので、当該サーバとメッシュネットワーク２００内の任意の所与のノードとの間でやり取りすることができる情報の量は、非常に限定される可能性がある。このようなファイヤーウォールに関連する通信の問題を解決するべく、多くの実施形態では、メッシュネットワーク２００内にリーダーノードを設けている。リーダーノードは、ネットワーク内の任意の所与のノードであってよい。多くの実施形態において、ＯＳメッシュエージェント１１４および／またはＯＯＢ管理ロジック１０８は、ネットワーク内の全ての（または少なくとも大半の）ノードに設けられており、これらのノードをリーダーノードへと昇格させるためのリーダーロジックをさらに有するとしてよい。あるノード（例えば、ノードＡ ２００）がリーダーノードへと昇格させられると、３Ｐサーバ２１８との間に二方向通信トンネル２２０を形成するとしてよい。この二方向通信トンネルは、ファイヤーウォール２１６が課しているセキュリティ上の制限を回避することができるので、リーダーノードは３Ｐサーバ２１８と自由に通信することができるようになる。
【００２８】
一部の実施形態によると、リーダーロジックは、メッシュネットワーク内の所与のノードをウェイク状態にする機能を持つとしてよい。対照的に、リーダーノード以外のノードは、この機能を持たないとしてよい。
【００２９】
上述したように、３Ｐサーバ２１８は、メッシュネットワーク２００に含まれる全てのノードを記載したリストおよび各ノードが提供するリソースのリストを格納している。この情報は、ネットワーク内のどのノードからも自由に読み出せるとしてよい。例えば、３Ｐサーバ２１８に格納されているこの情報は、簡単なＨＴＭＬ（ハイパーテキストマークアップ言語）ファイルとして読み出されるとしてよい。尚、ＨＴＭＬファイルは通常、ファイヤーウォール２１６を介して読み出すことが容認されている情報である。
【００３０】
また、所与のノード（例えば、ノードＣ ２０６）は、メッシュネットワーク２００内の別のノード（例えば、ノードＥ ２１０）が維持しているリソースリストが、ノードＣ ２０６がアクセスする必要があるリソースを含むことを発見するとしてよい。ノードＥ ２１０のこのリソースリストは、ノードＥ ２１０のローカルフラッシュブロックに保持されているとしてよい。ノードＥ ２１０のリソースリストは、３Ｐサーバ２１８にも保有されているとしてよい。ノードＣ ２０６は、ノードＥ ２１０をウェイク状態にするよう要求する通信内容を３Ｐサーバ２１８に送って、リストに記載されている必要なリソースを取得するとしてよい。多くの実施形態では、３Ｐサーバは、ノードＣ ２０６に対するウェイク状態への移行要求を、構築された二方向通信トンネル２２０を介してノードＡ ２０２に送るとしてよい。リーダーノードＡ ２０２は、この要求を受信して、メッシュネットワーク２００内のノードＥ ２１０と直接接触して、ノードＥ ２１０をウェイク状態へと移行させるとしてよい。また、リーダーノードＡ ２０２は、ノードＥ ２１０にリソース要求を送って、ノードＥ ２１０から本来のリソース要求者であるノードＣ ２０６へと必要なリソースを提供させるとしてよい。
【００３１】
このような通信制御プロセスは、二方向通信トンネル２２０が構築されている場合、ネットワーク内の任意のノードに関してリーダーノードが実行するプロセスであるとしてよい。３Ｐサーバ２１８は、ファイヤーウォール２１６のセキュリティ処理のためにこの要求をターゲットノードに直接送ることはできないが、二方向通信トンネルを用いてリーダーノードを介してこの要求を送ることができる。
【００３２】
メッシュネットワーク２００の各ノードがローカルフラッシュブロック内に保持する知人ノードリストは、リスト内のどのノードがリーダーノードであるかを記述する情報をさらに含むとしてよい。ＯＳメッシュエージェント１１４および／またはＯＯＢ管理ロジック１０８は、メッシュネットワーク２００内のノードをリーダーノードも含めて全て含むノードリストを取得するべく、３Ｐサーバ２１８のＩＰアドレスを保持するとしてよい。ある状況下では、リーダーノードが存在しない場合があるとしてよい。例えば、リーダーノードが何らかの理由でメッシュネットワーク２００から切断されると、メッシュネットワーク２００内にはリーダーノードが存在しないことになる。このような状況では、３Ｐサーバ２１８と接触するノードが自動的にリーダーノードに昇格されるとしてよい。尚、これが可能なノードはリーダーロジックが設けられているノードのみである。３Ｐサーバ２１８は、継続的に二方向通信トンネルをモニタリングするとしてよく、このトンネルが遮断されると、フラグ（例えば、「リーダーポジション空きフラグ」）を設定して、３Ｐサーバ２１８と次に接触するノードにリーダーノードに昇格するように指示するとしてよい。このため、３Ｐサーバ２１８と接触する最初のノード（例えば、ノードＢ ２０４）は、フラグを参照してリーダーノードへと昇格する。ノードＢ ２０４は、リーダーノードに昇格することによって、ウェイク状態移行要求を用いて他のノードをウェイク状態に移行させることができるようになる。また、ノードＢ ２０４は、リーダーノードに昇格することによって、３Ｐサーバ２１８との間に新たに二方向通信トンネルを構築することができる。
【００３３】
メッシュネットワークに新しいノードが追加されると、新しく追加されたノードは、メッシュネットワーク上でブロードキャストメッセージを用いて他のローカルノードに自らの存在を公表するとしてよい。続いて、メッシュネットワーク内の少なくとも１つのノードが新しいノードと接触して、ネットワークへの参入を承認するためのセキュリティ認証手順を実行するとしてよい。この後、新しく追加されたノードは、接触したノードの知人ノードリストを利用して、メッシュネットワーク内のナビゲーションを開始するとしてよい。これに代えて、新しく追加されたノードは、ネットワーク管理部からメッシュネットワーク内のローカルノードのＩＰアドレス、または、３ＰサーバのＩＰアドレスを単に与えられるのみとしてもよい。新しく追加されたノードは、３ＰサーバのＩＰアドレスが与えられる場合、３ＰサーバからローカルノードのＩＰアドレスを取得するとしてよい。そして、新しく追加されたノードは、ローカルノードとの間で、最初のメッシュ証明書交換認証手順を実行するとしてよい。多くの実施形態によると、新しく追加されるノードにおいて、ＯＯＢ管理ロジックは、デフォルト設定ではディセーブルになっているとしてよい。このため、新しく追加されたノードと最初に接触するメッシュネットワーク内のノードであるローカルノードは、新しく追加されたノード内にＯＯＢ管理ロジックを最初に設定するために必要な最初の高信頼性接続を形成するとしてよい。ＯＯＢ管理ロジックを最初に設定するためには、新しく追加されたノードの正当性（および、メッシュネットワーク内のローカルノードの正当性）を認証するための１以上の公開鍵および秘密鍵を用いたセキュリティハンドシェイクが必要となるとしてよい。メッシュネットワーク内のローカルノードとの間に高信頼性接続が構築されると、ＯＯＢ管理ロジックがイネーブルされて、新しく追加されたノードはメッシュネットワーク内のナビゲーションを開始して他のノードに関する情報を収集するとしてよい。
【００３４】
図４は、ローカルノードのメッシュネットワーク情報を更新する方法の実施形態を示すフローチャートである。
【００３５】
同図に示す方法は、ハードウェア（例えば、汎用コンピュータの回路）、ソフトウェア（例えば、ＯＳまたはソフトウェアアプリケーションコード）、ファームウェア（例えば、マイクロコードまたは基本入出力システム（ＢＩＯＳ）コード）、または、このような形態の処理ロジックのうち任意の２つ以上を組み合わせたものを含む処理ロジックによって実行される。多くの実施形態によると、図４の処理ロジックは、メッシュネットワークのローカルノードに設けられている。また、当該方法では、メッシュネットワーク内の別のノードがローカルノードのリモートブロックに自分の知人ノードリストを格納しているものと仮定されている。当該方法は、処理ロジックが「現在ノード」変数を、ローカルノードのリモートブロックに格納されている知人ノードリストの最初に記載されているノードを指し示すように設定することから開始される（処理ブロック４００）。
【００３６】
続いて、処理ロジックは、リモートブロックの知人リストに記載されている現在ノードが、ローカルブロックの知人ノードリストにも含まれているか否かを判断する（処理ブロック４０２）。現在ノードが含まれていない（つまり、ローカルノードは現在ノードを認識していない）場合、処理ロジックは現在ノードの確認を試みる（処理ブロック４０４）。確認手順は、さまざまな実施形態において利用されるノードを確認／認証するための多くの種類の手順のうちいずれかであってよい。確認手順の一例を図５を参照しつつ後述する。
【００３７】
ローカルノードと現在ノードとの間で確認手順が無事に完了すると仮定すると、処理ロジックはその後、現在ノードの情報を自分のローカルブロックの知人ノードリストおよびディスクストレージブロックに保存するとしてよい（処理ブロック４０６）。この保存される情報には、現在ノードのＩＰアドレス、認証が完了した時間を示すタイムスタンプ等の情報が含まれるとしてよい。処理ロジックはこの後、現在ノードのリソースリストを自分のディスクストレージブロックに保存することができる（処理ブロック４０８）。例えば、リソースリストは、現在ノードがメッシュネットワークに対して提供している全てのファイルおよび部分ファイルのメタデータを含むとしてよい。そして、処理ロジックは、処理しているリモートブロックの知人ノードリストの最後であるか否か、または、リスト内にノードが残っているか否かを判断する（処理ブロック４１２）。リストの最後であれば、リストの処理は終了する。リストの最後でなければ、処理ロジックは現在ノードをリスト内の次のノードにインクリメントして（処理ブロック４１４）、ブロック４０２に戻って処理を続ける。
【００３８】
ブロック４０２に戻って、現在ノードがローカルノードのローカルブロック内にある知人ノードリストに含まれていれば（つまり、ローカルノードが既に現在ノードを認識していれば）、処理ロジックは、ローカルノードのディスクストレージブロックに格納されている現在ノードのリソース情報が最新のものであるか否かを判断する（処理ブロック４１０）。例えば、リソース情報は、現在ノードが最後にリソース情報リストを更新した正確な時刻を示すタイムスタンプを含むリストであるとしてよい。このため、現在ノードが、ローカルブロック格納位置に格納されているリソース情報リスト内に他のノードに提供しているとして記載されているリソースを更新すれば、リスト全体のタイムスタンプもまた更新される。リソース情報リストは、タイムスタンプと共に、他のノード（のディスクストレージブロック）に格納されている。例えば、ローカルノードが、ディスクストレージブロックに格納しているリストにおいて現在ノードのリソース情報が変更されたか否かを調べたい場合、自分が格納しているタイムスタンプと、現在ノードがローカルブロックに現在保有しているタイムスタンプとを比較することができる。これら２つのタイムスタンプが一致すれば、ローカルノードは、保有しているリソース情報リストが現在のものであると結論付ける。これら２つのタイムスタンプが一致しない場合、ローカルノードは、保有しているリソース情報リストが古いものであると結論付ける。
【００３９】
処理ロジックは、リソース情報リストが最新のものでない場合、現在ノードのリソースリストを自分のディスクストレージブロックに保存する（処理ブロック４０８）。処理ロジックはその後、処理しているリモートブロックの知人ノードリストの最後であるか否か、または、リスト内にノードが残っているか否かを判断する（処理ブロック４１２）。リストの最後であれば、リストの処理は終了する。リストの最後でなければ、処理ロジックは現在ノードをリスト内の次のノードにインクリメントして（処理ブロック４１４）、ブロック４０２に戻って処理を続ける。
【００４０】
ブロック４１０に戻って、処理ロジックは、リソース情報リストが最新のものであれば、処理しているリモートブロックの知人ノードリストの最後であるか否か、または、リスト内にノードが残っているか否かを判断する（処理ブロック４１２）。リストの最後であれば、リストの処理は終了する。リストの最後でなければ、処理ロジックは現在ノードをリスト内の次のノードにインクリメントして（処理ブロック４１４）、ブロック４０２に戻って処理を続ける。
【００４１】
図５は、ローカルノードがメッシュネットワーク内の別のノードを確認して当該別のノードと関連メッシュネットワーク情報のやり取りを行う方法の実施形態を示すフローチャートである。
【００４２】
同図に示す方法は、ハードウェア（例えば、汎用コンピュータの回路）、ソフトウェア（例えば、ＯＳまたはソフトウェアアプリケーションコード）、ファームウェア（例えば、マイクロコードまたは基本入出力システム（ＢＩＯＳ）コード）、または、このような形態の処理ロジックのうち任意の２つ以上を組み合わせたものを含む処理ロジックによって実行される。多くの実施形態によると、図５の処理ロジックは、メッシュネットワークのローカルノードに設けられている。
【００４３】
当該方法は、ローカルノード（例えば、第１のノード）に設けられている処理ロジックが、メッシュネットワーク内の別のノード（例えば、第２のノード）に接触することによって開始される（処理ブロック５００）。「接触する」プロセスでは、第１のノードが第２のノードのＩＰアドレス（または、位置情報を与える別の種類のアドレス）を保有していることが要件となる。接触が行われると、第１のノードの処理ロジックは、第２のノードとの間でメッシュ証明書確認手順を実行するとしてよい（処理ブロック５０２）。メッシュ証明書確認手順では、第１のノードが自分のメッシュ証明書を第２のノードに提供して、第２のノードが自分のメッシュ証明書を第１のノードに提供するとしてよい。確認手順が完了すると、確認手順が成功したと仮定して、第１のノードの処理ロジックは、第２のノードの知人ノードリストを第２のノードのローカルブロック格納位置から取得するとしてよい（処理ブロック５０４）。
【００４４】
最後に、処理ロジックは、第１のノードの知人ノードリストを第２のノードのリモートブロックに格納する（処理ブロック５０６）。この結果、第１のノードの既知の知人ノード情報は第２のノードに渡される。この手順全体が終了すると、第１のノードおよび第２のノードにおいて、確認手順前には各ノードが別個に保有していた知人ノード情報がまとめられる。
【００４５】
図６は、ローカルノードが第三者サーバに接触して当該第三者サーバによってリーダーノードにアップグレードされる方法の実施形態を示すフローチャートである。
【００４６】
同図に示す方法は、ハードウェア（例えば、汎用コンピュータの回路）、ソフトウェア（例えば、ＯＳまたはソフトウェアアプリケーションコード）、ファームウェア（例えば、マイクロコードまたは基本入出力システム（ＢＩＯＳ）コード）、または、このような形態の処理ロジックのうち任意の２つ以上を組み合わせたものを含む処理ロジックによって実行される。多くの実施形態によると、図６の処理ロジックは、メッシュネットワークのローカルノードに設けられている。
【００４７】
当該方法は、ローカルノード内の処理ロジックが第三者サーバに接触することによって開始される（処理ブロック６００）。第三者サーバのＩＰアドレスは、メッシュネットワーク内の別のノードによって、または、メッシュネットワーク管理部によって、ローカルノードに提供されるとしてよい。続いて、処理ロジックが第三者サーバに、メッシュネットワーク内のリーダーポジションが空いているか否かを問い合わせる（処理ブロック６０２）。リーダーポジションが空いているのは、リーダーポジションが空いていることを意味するグローバル可視フラグを第三者サーバが設定している場合であるとしてよい。リーダーポジションが空いていて、且つ、ローカルノードがリーダーへと昇格する機能を持つ場合、ローカルノードは専用の二方向通信トンネルを第三者サーバとの間に構築する（処理ブロック６０４）。このような専用トンネルによって、ローカルノードは、第三者サーバから、詳細な情報およびコマンドを受信することができるようになる。ファイヤーウォール等のセキュリティ手順がメッシュネットワークに対して設けられているので、トンネルがなければ、ローカルノードは第三者サーバからコマンドを受信することが不可能になってしまうこともある。多くの実施形態によると、トンネル構築前に、ローカルノードと第三者サーバとの間でセキュアな確認手順を実行して、互いに認証し合うとしてよい。リーダーポジションが空いていない場合、処理を終える（つまり、メッシュネットワーク内の別のノードが既にリーダーノードとして設定されており、この別のノードが現在動作していることになる）。
【００４８】
分散型メッシュネットワークを実施するためのデバイス、方法、およびシステムの実施形態を説明した。上述した実施形態は、具体的な実施形態例を参照しつつ説明している。本明細書に記載した実施形態を広く解釈した場合の思想および範囲を逸脱することなく、本開示内容に基づき上記の実施形態をさまざまな点で変形および変更し得ることは、明らかである。したがって、本明細書および添付図面は、本発明を限定するものではなく例示するものと解されたい。
【技術分野】
【０００１】
本発明は、ピア・ツー・ピアネットワークの実施に関する。
【背景技術】
【０００２】
ピア・ツー・ピア分散型ネットワークは一般的に、他の種類のネットワークとは違って、集中管理サーバを多く利用することを要件とすることなくネットワーク機能を実現する。各コンピュータでの電力効率の改善の必要性が益々高まっている。大規模なネットワーク上に所与の時間に存在するコンピュータの数を考えると、コンピュータ１台当たりの電力を低減する方法およびデバイスを実現することによって、会社および／または産業全体では大幅な電力削減につながる。
【図面の簡単な説明】
【０００３】
本発明の例を図面に図示するが、本発明は図面に限定されるものではない。図面では、同様の参照番号は同様の構成要素を示すものとする。図面は以下の通りである。
【図１】メッシュネットワークに含まれるコンピューティングデバイスの実施形態を示す図である。
【図２】メッシュネットワークの実施形態を示す図である。
【図３】メッシュネットワークにおけるノード間親密度の実施形態を示す図である。
【図４】ローカルノードのメッシュネットワーク情報を更新する方法の実施形態を示すフローチャートである。
【図５】ローカルノードがメッシュネットワーク内の別のノードを確認して当該別のノードと関連メッシュネットワーク情報のやり取りを行う方法の実施形態を示すフローチャートである。
【図６】ローカルノードが第三者サーバに接触して当該第三者サーバによってリーダーノードにアップグレードされる方法の実施形態を示すフローチャートである。
【発明を実施するための形態】
【０００４】
分散型メッシュネットワークを実施するためのデバイス、方法、およびシステムの実施形態を説明する。
【０００５】
分散型メッシュネットワークは、多くのピア・ツー・ピアノードを備える。各ノードは、当該ノードが起きている（ウェイク）状態でも、寝ている（スリープ）状態であっても、メッシュネットワーク上のほかのノードにも利用可能な格納位置およびロジックを含む。２つのノードがやり取りを行う場合、メッシュネットワークへの参入が許可されていることを１以上の認証手順を経て互いに確認するとしてよい。両ノードは、各ノードが持つリソースに関する情報および各ノードがメッシュネットワーク上で存在を認識しているノードのリストである既知ノードリストを交換するとしてよい。第１のノードは、自身が既に認識しているノードのそれぞれから既知ノードリストを取得することによって、メッシュネットワークを通り抜けるとしてよい。こうして、第１のノードは、自身が本来所有していた既知ノードリストに基づき認識するにようになった任意の新しいノードと接触することができるようになる。
【０００６】
また、メッシュネットワークの外部の第三者サーバが、メッシュネットワークと第三者サーバとの間に通信トンネルを形成する指定リーダーノードを用いて、当該メッシュネットワークに存在するその他のノード全てに関する各ノード情報を提供するとしてよい。多くの実施形態に係るメッシュネットワークは、当該メッシュネットワーク内のノードの多くをスリープ状態としたまま、任意の１つのノードに当該メッシュネットワーク内の任意のほかのノードからリソースを取得させることができるので、当該メッシュネットワーク全体で電力が削減される。リソースを要求する要求ノードは、第三者サーバに要求を送り、第三者サーバは、リーダーノードを介して、リソースが要求されているターゲットノードに目覚め（ウェイクアップ）コマンドを送る。こうして、ターゲットノードはウェイク状態になり、要求ノードにリソースを提供して、スリープ状態に戻るとしてよい。
【０００７】
以下に記載する説明および請求項では、開示技術の「一実施形態」または「実施形態」と記載することがあるが、これは当該実施形態に関連付けて説明した特定のフィーチャ、構造、または特性が、開示技術の少なくとも１つの実施形態に含まれることを意味するものである。このため、本明細書では何度も「一実施形態」という記載が見られるが、必ずしも全てが同じ実施形態に言及しているとは限らない。以下に記載する説明および請求項では、「備える」、「含む」および「有する」といった用語を用いる場合があるが、意味は同じである。
【０００８】
図１は、メッシュネットワークに含まれるコンピューティングデバイスの実施形態を示す図である。コンピュータデバイスは、ノードと呼ばれることもあり、特にローカルノード１００と呼ばれることもある。ローカルノード１００は、コンピューティングデバイスとして構成されるとしてよい。例えば、ローカルノード１００は、デスクトップコンピュータ、ラップトップコンピュータ、ワークステーションコンピュータ、サーバ、ハンドヘルドコンピューティングデバイス、ゲーム機、テレビ用セットトップボックス、別のデバイスに一体化して設けられているコンピュータ（例えば、自動車ダッシュボード用コンピュータ）、または、別の形態のコンピューティングデバイスであってよい。ローカルノード１００は、システムメモリ１０２を備える。システムメモリ１０２は、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）等の揮発性メモリであってもよいし、または、フラッシュメモリ等の不揮発性メモリであってもよい。
【０００９】
ローカルノードは、数種類のストレージ、例えば、ディスクストレージ１０４（例えば、ハードドライブ）およびフラッシュストレージ１０６（例えば、フラッシュメモリ、フラッシュメモリドライブ等）を備えるとしてよい。ディスクストレージ１０４およびフラッシュストレージ１０６は、不揮発性ストレージデバイスであり、複数の電力サイクルにわたって情報を保存することができる。つまり、ローカルノードの電源が切られたり、または、スリープ状態になった場合でも、ディスクストレージ１０４およびフラッシュストレージ１０６は、次にローカルノードの電源が入った時に当該情報を利用可能な状態に情報を保持するとしてよい。
【００１０】
多くの実施形態において、ローカルノードはさらに、アウトオブバンド（ＯＯＢ）管理ロジック１０８を備える。ＯＯＢ管理ロジック１０８は、ローカルノード１００のほかの部分がスリープ状態または電源が入っていない状態において、動作する回路を有するとしてよい。ＯＯＢ管理ロジックの一例を挙げると、Ｉｎｔｅｌ（登録商標）社のアクティブ・マネジメント・テクノロジー（ＡＭＴ）がある。ＯＯＢ管理ロジック１０８には多くの用途があり、例えば、ハードウェア障害あるいはソフトウェア障害が発生したことによって、または、ローカルノード１００がスリープ状態にある等の多くの理由によってローカルノード１００が動作していない場合に、ローカルノード１００の少なくとも一部分に対するリモートアクセスを可能とする。多くの実施形態によると、ＯＯＢ管理ロジック１０８は、ローカルノード１００が標準的なインバンド管理方式を利用していないときにローカルノード１００が管理する方式であるアウトオブバンド方式でローカルノード１００を管理する。例えば、ローカルノード１００が電力供給が完全に行われている状態で通常動作状態にある場合、ローカルノード１００の中央プロセッサ（不図示）がシステムメモリ１０２内にあるオペレーティングシステム（ＯＳ）用の命令を実行しているとしてよい。これは、リモードノードがローカルノード１００と通信を実行する場合、ローカルオペレーティングシステムを介した標準通信チャネルが利用され得るので、インバンド動作と呼ばれることがある。一方、ローカルノード１００がスリープ状態である場合、中央プロセッサに対する電力供給は１００％でなくオペレーティングシステムは動作していないので、ローカルノード１００との間で利用可能な唯一の通信方法は、ローカルノード１００のほかの部分が動作していない場合に動作するＯＯＢ管理ロジック１０８を介したアウトオブバンド通信となり得る。
【００１１】
入出力（Ｉ／Ｏ）インターフェース１１０は、ローカルノード１００とノード外部の任意の実体との間の通信に用いられる。Ｉ／Ｏインターフェース１１０は、有線ネットワークインターフェース、アンテナを利用する無線ネットワークインターフェース、および／または、ローカルノード１００と１以上のその他の外部デバイスとの間のＩ／Ｏ通信を実現し得る１以上のその他のネットワークインターフェース方法のうち１以上を含むとしてよい。多くの実施形態によると、Ｉ／Ｏインターフェース１１０は、ローカルネットワーク２００に結合されている。ローカルネットワーク２００は、有線ネットワークまたは無線ネットワークであってよく、そして、インターネットに結合されているとしてもよいし、または、結合されていないとしてもよい。
【００１２】
ＯＯＢ管理ロジック１０８は、ローカルノード１００がアウトオブバンドモードにあり、ＯＯＢ管理ロジック１０８と他のコンピューティングデバイスとの間で通信を行うことが可能である場合に、Ｉ／Ｏインターフェース１１０の一部または全てを利用するとしてよい。他の実施形態によると、ＯＯＢ管理ロジック１０８は、外部と通信を行うために、別個に動作する集積化Ｉ／Ｏインターフェースを有する。
【００１３】
多くの実施形態によると、フラッシュストレージ１０６の少なくとも一部は、ＯＯＢ管理ロジック１０８専用である。このように、フラッシュストレージ１０６は、アウトオブバンド動作時、例えば、ローカルノード１００の他の部分がスリープ状態の場合には、ＯＯＢ管理ロジック１０８が利用可能およびアクセス可能である。
【００１４】
ローカルノード１００はさらに、ローカルフラッシュブロック１１２、リモートフラッシュブロック１１６、ディスクストレージブロック１１８、および、ＯＳメッシュエージェント１１４を備える。これらの構成要素は、図２を参照しつつ詳細に後述する。
【００１５】
図２は、メッシュネットワークの実施形態を示す図である。メッシュネットワークは、複数のノード（ノードＡ ２０２、ノードＢ ２０４、ノードＣ ２０６、ノードＤ ２０８、ノードＥ ２１０、および、ノードＦ ２１２）を備える。多くの実施形態によると、ノードＡからＦのうちいずれも、図１に示したローカルノード１００であってよい。つまり、ノードＡからＦは、図１に詳細を示したローカルノード１００が備える構成要素を全て有するとしてよい。例えば、ローカルノード１００の各構成要素は、一部を上記で説明したが、ノードＡ ２０２の詳細図に示している。図２に示した複数のノードは、ローカルネットワーク２００を介して互いに結合されている。ローカルネットワークは、複数のノードが互いに通信し合うことができるような通信ネットワークであればどのような形態であってもよい。ローカルネットワーク２００の例を挙げると、イーサネット（登録商標）有線ネットワーク、ＩＥＥＥ８０２．１１ベースの無線ネットワーク、セルラーネットワーク、ＷｉＭＡＸ等の広範囲無線ネットワーク、または、他の種類のネットワークがある。当該ネットワークは、ファイヤーウォール２１６を介して、インターネット２１４に結合されるとしてよい。ファイヤーウォール２１６は、ローカルネットワーク２００のゲートウェイコンピュータによって保持されるとしてよい。ゲートウェイコンピュータは、ローカルネットワーク２００とインターネット２１４との間で特定の種類の情報の通信を禁止するセキュリティプロトコルを含む。このため、ノードＡからＦは、全てローカルネットワーク２００のメンバーであるので互いに自由に通信し合うことができるが、ノードＡからＦの任意のノードと、リモートノード、例えば、ローカルネットワーク２００にインターネット２１４を介して通信可能に結合されているノードとの間の通信については、ファイヤーウォール２１６が実施するセキュリティ処理によって制限されることもある。
【００１６】
多くの実施形態によると、ローカルネットワーク２００は、分散型「メッシュ」ネットワークである。メッシュネットワークでは、当該ネットワーク内のノードがいずれも、ほかの全てのノードについて認識している必要はない。また、メッシュネットワークでは、全てのノードに関する情報を持つ中央ノードが必ず設けられているわけではない。メッシュネットワーク内の各ノードは、当該メッシュネットワークに含まれるノードのうち自身が知っているノードのリストを保持している（既知ノードは、知人ノードとも呼ばれるとしてよい）。この知人ノードリストは、フラッシュストレージ１０６内に保持されているローカルフラッシュブロック１１２に格納されるとしてよい。多くの実施形態によると、知人ノードリストの各項目は、対応する知人ノードのＩＰ（インターネットプロトコル）アドレスを含む。２つのノードは、互いを認識しており悪意のない実体であると互いに認めている場合、相手を「友人」と呼ぶとしてよい。各ノードは、ネットワーク内の他のノードに広告する一意的なメッシュ証明書を所有しているとしてよい。多くの実施形態によると、２つのノードが友人関係を構築するためには、ネットワークへの参入が許可されていることを証明する正当なメッシュ証明書を交換する必要がある。この交換は、さまざまな方式のうちいずれかで行われるとしてよいが、公開鍵であるメッシュ証明書と各ノードに一意的に設定されている秘密鍵とを組み合わせるハッシュアルゴリズム等の認証手順を含むとしてよい。
【００１７】
対照的に、第１のノードが第２のノードを認識しているが、第２のノードがメッシュ証明書の生成に失敗した場合、第１のノードは第２のノードを「敵ノード」と見なすとしてよい。第２のノードが友人ノードであっても敵ノードであっても、第１のノードが第２のノードを認識すると、第２のノードは第１のノードの知人ノードになるとしてよい。一部の実施形態では、ノードが保持している知人ノードリストは、各ノードと直接接触した最新時を示す時間スタンプを含むとしてよい。多くの実施形態によると、知人ノードリスト自体には、リストが更新される度に、バージョン番号および時間スタンプが付与される。知人ノードリストの更新では、ネットワークに新しく参加したノードの追加、ネットワークから抜けたノードの削除、ノードの友人／敵ステータスの変更等を行う。メッシュネットワーク内の各ノードは、リストに記載されており認識しているノードを全て監視することができる。所与のノードがメッシュ証明書を提示していない場合、この証明書なしのノードの知人ノードは、知人ノードリストに、証明書が無いことに関する警告を追加するとしてよい。
【００１８】
２つのノード間に信頼関係を構築するためには、メッシュ証明書を用いたセキュリティハンドシェイクを実行する必要があるとしてよい。一部の実施形態によると、ノードは別のノードとまず知人関係を構築し、この知人ノードを友人ノードに昇格させるためには、メッシュ証明書によるセキュリティ証明が必要となるとしてよい。他の実施形態では、第１のノードが、第２のノードを友人ノードと見なしている場合、第２ノードの友人であるノードは自動的にいずれのノードも自身の友人ノードと見なすとしてよい（つまり、友人の友人もまた友人）。これは、友人ノード間で予め定められている安全検査レベルのためであり、ある１つのノードが新しい知人ノードを新しい友人ノードと認証すると、他の友人ノードは全て、利用するメッシュ証明書ハンドシェイクの安全検査のレベルが同一であるので、この新しい知人ノードは自身の友人でもあると見なすことができる。
【００１９】
図３は、メッシュネットワークにおけるノード間親密度の実施形態を示す図である。ノードＡ ３００は、ノードＢ ３０２、ノードＣ ３０４、および、ノードＤ ３０６について知っているが、ノードＥ ３０８およびノードＦ ３１０については知らない。しかし、ノードＣ ３０４は、ノードＡ ３００の友人ノードであり、ノードＥ ３０８およびノードＦ ３１０を知っている。この場合、ノードＡ ３００は、ノードＥ ３０８およびノードＦ ３１０に関する情報について友人ノードであるノードＣ ３０４に要求して、既知の友人ノードのリストにこれら２つのノードを入れるとしてよい。
【００２０】
図２に戻って説明を続けると、各ノードは、既知の知人ノードのリストを保持する以外に、メッシュネットワーク内のほかのノードに提供することができるリソースのリストも保持している。リソースのリストは、ファイルメタデータ、例えば、全ての共有ファイルおよびファイルフラグメントの名称、サイズ、および、作成日時を含むとしてよい。他の実施形態によると、リソースには、ファイルメタデータ以外にも、ノードが提供可能なサービスおよび機能のリストが含まれるとしてよい。例えば、ノードＡ ２０２は、他のノードに関連するデータセットの一部分を格納しているとしてよい。これは、メッシュネットワークの各ノードがファイルの一部分を格納しており、自身が保有する部分を他のノードに提示するピア・ツー・ピアのファイル共有環境では一般的であるとしてよい。他の実施形態では、所与のノードが、リストに記載されているファイルを、ファイルの一部分ではなく、全て格納するとしてよい。
【００２１】
多くの実施形態によると、各ノードはＯＳメッシュエージェント１１４を有する。ＯＳメッシュエージェント１１４は、ノードがウェイク状態で１００％の状態で機能している場合に、ロードされるとしてよい。ＯＳメッシュエージェント１１４は、ＯＳが動作状態にある場合にバックグラウンドで実行されるプロセスであってよい。ＯＳメッシュエージェント１１４が提供する機能は、ＯＯＢ管理ロジック１０８が提供する機能の一部と同じであるとしてよい。つまり、ノードがスリープ状態にある場合、ＯＯＢ管理ロジック１０８がノード間通信およびリスト管理を実行して、ノードがウェイク状態にある場合、ＯＳメッシュエージェント１１４がノード間通信およびリスト管理を実行する。多くの実施形態によると、ＯＯＢ管理ロジック１０８が無いノードにＯＳメッシュエージェント１１４がロードされるとしてもよく、この場合、当該ノードがウェイク状態の場合にノード間通信を可能とするが、ＯＯＢ管理ロジック１０８がないノードは、スリープ状態の場合、ノード間通信を実行することができない。
【００２２】
所与のノードは、各友人ノードに接触して、各友人ノードから知人ノードのリストを受信して、知人ノードリストに含まれるノードに接触して、メッシュネットワーク内のナビゲーションを実現するとしてよい。このため、ＯＳメッシュエージェント１１４は、各友人ノードのローカルフラッシュブロックに保持されている知人ノードリストを読み出すとしてよい。このナビゲーションは、ノードがウェイク状態であろうとスリープ状態であろうと発生するとしてよい。これは、ナビゲーションを行うノードは、メッシュネットワーク内の別のノードがウェイク状態であろうとスリープ状態であろうと、この別のノードが、ＯＯＢ管理ロジック１０８によってスリープ状態でも保持されるローカルフラッシュブロックを含む限りにおいて、この別のノードに接触できるためである。多くの実施形態によると、ウェイク状態ではＯＳメッシュエージェント１１４が訪問ノードにローカル情報を提供し、スリープ状態ではＯＯＢ管理ロジック１０８が訪問ノードにローカル情報を提供する。一部の実施形態では、ノードが備えるＯＳメッシュエージェント１１４およびＯＯＢ管理ロジック１０８の両方が、ローカルフラッシュブロックから知人ノード情報およびリソース情報を取得して、訪問ノードに提供する。一部の実施形態によると、このノードがウェイク状態の場合に、知人ノード情報およびリソース情報をローカルフラッシュブロック１１２から取得されるとしてよい。このようにして、多くの実施形態において、所与のノードは、他のノードがウェイク状態かスリープ状態かに関わらず、メッシュネットワーク内のナビゲーションを完遂することができるとしてよい。
【００２３】
また、多くの実施形態では、所与のノードは、ネットワーク内をナビゲーションする場合、知人ノードリストおよびリソースリストを、訪問する各ノードに残すとしてもよい。訪問する側のノードは、訪問される側のノードのフラッシュストレージ１０６のリモートフラッシュブロック１１６にこの情報（リソースおよび知人ノード）を入れるとしてよい。一部の実施形態によると、訪問される側のノードがスリープ状態である場合、ウェイク状態になるまで、この情報はリモートフラッシュブロック１１６内にそのまま格納されるとしてよい。
【００２４】
訪問された側のノードがウェイク状態になると、このノードのＯＳメッシュエージェント１１４が、リモートフラッシュブロック１１６から情報を読み出して、訪問したノードが入れた情報を処理するとしてよい。この処理において、ＯＳメッシュエージェント１１４は、訪問したノードが入れた情報を、訪問したノードが残した知人ノードリストを比較することによって、確認するとしてよい。両方のリストに共通している知人ノードは、ローカルノードで既に確認されたノードである。訪問したノードの知人ノードのうちローカルノードの知人ノードリストに無い知人ノードがあれば、このような未知の知人ノードを確認するための処理をさらに実行するとしてよい。具体的には、訪問したノードの知人ノードリストに、ローカルノードのローカルフラッシュブロック１１２に保持されている知人ノードリストにはない知人ノードが１以上ある場合、ＯＳメッシュエージェント１１４は、未知の知人ノードに接触して、１以上の新たなノードとメッシュ証明書を交換して、１以上の新しいノードをローカルフラッシュブロック１１２が格納している知人ノードのローカルリストに追加するとしてよい。
【００２５】
さらに、新しい知人ノードのリソース情報は、ＯＳメッシュエージェント１１４によって利用されるとしてもよい。ローカルディスクストレージ１０４が格納しているディスクストレージブロック１１８は、メッシュネットワーク２００内の既知のノード全てについて既知の情報を全て格納しているとしてよい。例えば、ディスクストレージブロック１１８は、既知のノードそれぞれのＩＰアドレスおよび各ノードのリソースリストを含むとしてよい。多くの実施形態によると、各ノードについてほかの情報も同様に格納されるとしてよい。例えば、各知人ノードに対する平均ネットワークピング（ｐｉｎｇ）レイテンシが格納されているとしてよい。所与のノードのＯＳメッシュエージェント１１４は時折（当該ノードがウェイク状態である場合に）、メッシュネットワーク２００内のノードについて既知の情報をメンテナンスする目的で更新するとしてよい。具体的には、知人ノードリストに含まれている各ノードに接触して、各知人ノードに関して保有している情報を更新する。他のノードに関する情報の一部は、訪問ノードがリモートフラッシュブロック１１６に格納している情報から取得されるとしてよい。他のノードに関する他の情報は、ＯＳメッシュエージェント１１４が別のノードと積極的に接触する際に、メッシュネットワーク内のほかのノードから直接取得されるとしてよい。
【００２６】
所与のノードについて、ローカルフラッシュブロック１１２および／またはディスクストレージブロック１１８に格納されている知人ノード情報を、当該ノードがスリープ状態からウェイク状態に移行する度に、訪問ノードがリモートフラッシュブロックに格納した知人ノード情報と比較するとしてよい。訪問ノードが格納したリストが新しいノードのＩＰアドレスを含む場合（つまり、ＯＳメッシュエージェント１１４が保持している知人ノードリストにこの新しいノードが含まれていない場合）、ＯＳメッシュエージェント１１４は、新しいノードと接触して、新しいノードとメッシュ証明書を交換して新しいノードを確認して、ローカルの知人ノードリストに追加するとしてよい。
【００２７】
多くの実施形態によると、インターネット２１４には第三者（３Ｐ）サーバ２１８が結合されている。３Ｐサーバ２１８は、メッシュネットワーク内の全てのノードを記載したリストを保持しているとしてよい。当該リストは、各ノードのＩＰアドレスと、各ノードが提供するリソースを含む。３Ｐサーバ２１８は、ファイヤーウォール２１６の外側に位置しているので、当該サーバとメッシュネットワーク２００内の任意の所与のノードとの間でやり取りすることができる情報の量は、非常に限定される可能性がある。このようなファイヤーウォールに関連する通信の問題を解決するべく、多くの実施形態では、メッシュネットワーク２００内にリーダーノードを設けている。リーダーノードは、ネットワーク内の任意の所与のノードであってよい。多くの実施形態において、ＯＳメッシュエージェント１１４および／またはＯＯＢ管理ロジック１０８は、ネットワーク内の全ての（または少なくとも大半の）ノードに設けられており、これらのノードをリーダーノードへと昇格させるためのリーダーロジックをさらに有するとしてよい。あるノード（例えば、ノードＡ ２００）がリーダーノードへと昇格させられると、３Ｐサーバ２１８との間に二方向通信トンネル２２０を形成するとしてよい。この二方向通信トンネルは、ファイヤーウォール２１６が課しているセキュリティ上の制限を回避することができるので、リーダーノードは３Ｐサーバ２１８と自由に通信することができるようになる。
【００２８】
一部の実施形態によると、リーダーロジックは、メッシュネットワーク内の所与のノードをウェイク状態にする機能を持つとしてよい。対照的に、リーダーノード以外のノードは、この機能を持たないとしてよい。
【００２９】
上述したように、３Ｐサーバ２１８は、メッシュネットワーク２００に含まれる全てのノードを記載したリストおよび各ノードが提供するリソースのリストを格納している。この情報は、ネットワーク内のどのノードからも自由に読み出せるとしてよい。例えば、３Ｐサーバ２１８に格納されているこの情報は、簡単なＨＴＭＬ（ハイパーテキストマークアップ言語）ファイルとして読み出されるとしてよい。尚、ＨＴＭＬファイルは通常、ファイヤーウォール２１６を介して読み出すことが容認されている情報である。
【００３０】
また、所与のノード（例えば、ノードＣ ２０６）は、メッシュネットワーク２００内の別のノード（例えば、ノードＥ ２１０）が維持しているリソースリストが、ノードＣ ２０６がアクセスする必要があるリソースを含むことを発見するとしてよい。ノードＥ ２１０のこのリソースリストは、ノードＥ ２１０のローカルフラッシュブロックに保持されているとしてよい。ノードＥ ２１０のリソースリストは、３Ｐサーバ２１８にも保有されているとしてよい。ノードＣ ２０６は、ノードＥ ２１０をウェイク状態にするよう要求する通信内容を３Ｐサーバ２１８に送って、リストに記載されている必要なリソースを取得するとしてよい。多くの実施形態では、３Ｐサーバは、ノードＣ ２０６に対するウェイク状態への移行要求を、構築された二方向通信トンネル２２０を介してノードＡ ２０２に送るとしてよい。リーダーノードＡ ２０２は、この要求を受信して、メッシュネットワーク２００内のノードＥ ２１０と直接接触して、ノードＥ ２１０をウェイク状態へと移行させるとしてよい。また、リーダーノードＡ ２０２は、ノードＥ ２１０にリソース要求を送って、ノードＥ ２１０から本来のリソース要求者であるノードＣ ２０６へと必要なリソースを提供させるとしてよい。
【００３１】
このような通信制御プロセスは、二方向通信トンネル２２０が構築されている場合、ネットワーク内の任意のノードに関してリーダーノードが実行するプロセスであるとしてよい。３Ｐサーバ２１８は、ファイヤーウォール２１６のセキュリティ処理のためにこの要求をターゲットノードに直接送ることはできないが、二方向通信トンネルを用いてリーダーノードを介してこの要求を送ることができる。
【００３２】
メッシュネットワーク２００の各ノードがローカルフラッシュブロック内に保持する知人ノードリストは、リスト内のどのノードがリーダーノードであるかを記述する情報をさらに含むとしてよい。ＯＳメッシュエージェント１１４および／またはＯＯＢ管理ロジック１０８は、メッシュネットワーク２００内のノードをリーダーノードも含めて全て含むノードリストを取得するべく、３Ｐサーバ２１８のＩＰアドレスを保持するとしてよい。ある状況下では、リーダーノードが存在しない場合があるとしてよい。例えば、リーダーノードが何らかの理由でメッシュネットワーク２００から切断されると、メッシュネットワーク２００内にはリーダーノードが存在しないことになる。このような状況では、３Ｐサーバ２１８と接触するノードが自動的にリーダーノードに昇格されるとしてよい。尚、これが可能なノードはリーダーロジックが設けられているノードのみである。３Ｐサーバ２１８は、継続的に二方向通信トンネルをモニタリングするとしてよく、このトンネルが遮断されると、フラグ（例えば、「リーダーポジション空きフラグ」）を設定して、３Ｐサーバ２１８と次に接触するノードにリーダーノードに昇格するように指示するとしてよい。このため、３Ｐサーバ２１８と接触する最初のノード（例えば、ノードＢ ２０４）は、フラグを参照してリーダーノードへと昇格する。ノードＢ ２０４は、リーダーノードに昇格することによって、ウェイク状態移行要求を用いて他のノードをウェイク状態に移行させることができるようになる。また、ノードＢ ２０４は、リーダーノードに昇格することによって、３Ｐサーバ２１８との間に新たに二方向通信トンネルを構築することができる。
【００３３】
メッシュネットワークに新しいノードが追加されると、新しく追加されたノードは、メッシュネットワーク上でブロードキャストメッセージを用いて他のローカルノードに自らの存在を公表するとしてよい。続いて、メッシュネットワーク内の少なくとも１つのノードが新しいノードと接触して、ネットワークへの参入を承認するためのセキュリティ認証手順を実行するとしてよい。この後、新しく追加されたノードは、接触したノードの知人ノードリストを利用して、メッシュネットワーク内のナビゲーションを開始するとしてよい。これに代えて、新しく追加されたノードは、ネットワーク管理部からメッシュネットワーク内のローカルノードのＩＰアドレス、または、３ＰサーバのＩＰアドレスを単に与えられるのみとしてもよい。新しく追加されたノードは、３ＰサーバのＩＰアドレスが与えられる場合、３ＰサーバからローカルノードのＩＰアドレスを取得するとしてよい。そして、新しく追加されたノードは、ローカルノードとの間で、最初のメッシュ証明書交換認証手順を実行するとしてよい。多くの実施形態によると、新しく追加されるノードにおいて、ＯＯＢ管理ロジックは、デフォルト設定ではディセーブルになっているとしてよい。このため、新しく追加されたノードと最初に接触するメッシュネットワーク内のノードであるローカルノードは、新しく追加されたノード内にＯＯＢ管理ロジックを最初に設定するために必要な最初の高信頼性接続を形成するとしてよい。ＯＯＢ管理ロジックを最初に設定するためには、新しく追加されたノードの正当性（および、メッシュネットワーク内のローカルノードの正当性）を認証するための１以上の公開鍵および秘密鍵を用いたセキュリティハンドシェイクが必要となるとしてよい。メッシュネットワーク内のローカルノードとの間に高信頼性接続が構築されると、ＯＯＢ管理ロジックがイネーブルされて、新しく追加されたノードはメッシュネットワーク内のナビゲーションを開始して他のノードに関する情報を収集するとしてよい。
【００３４】
図４は、ローカルノードのメッシュネットワーク情報を更新する方法の実施形態を示すフローチャートである。
【００３５】
同図に示す方法は、ハードウェア（例えば、汎用コンピュータの回路）、ソフトウェア（例えば、ＯＳまたはソフトウェアアプリケーションコード）、ファームウェア（例えば、マイクロコードまたは基本入出力システム（ＢＩＯＳ）コード）、または、このような形態の処理ロジックのうち任意の２つ以上を組み合わせたものを含む処理ロジックによって実行される。多くの実施形態によると、図４の処理ロジックは、メッシュネットワークのローカルノードに設けられている。また、当該方法では、メッシュネットワーク内の別のノードがローカルノードのリモートブロックに自分の知人ノードリストを格納しているものと仮定されている。当該方法は、処理ロジックが「現在ノード」変数を、ローカルノードのリモートブロックに格納されている知人ノードリストの最初に記載されているノードを指し示すように設定することから開始される（処理ブロック４００）。
【００３６】
続いて、処理ロジックは、リモートブロックの知人リストに記載されている現在ノードが、ローカルブロックの知人ノードリストにも含まれているか否かを判断する（処理ブロック４０２）。現在ノードが含まれていない（つまり、ローカルノードは現在ノードを認識していない）場合、処理ロジックは現在ノードの確認を試みる（処理ブロック４０４）。確認手順は、さまざまな実施形態において利用されるノードを確認／認証するための多くの種類の手順のうちいずれかであってよい。確認手順の一例を図５を参照しつつ後述する。
【００３７】
ローカルノードと現在ノードとの間で確認手順が無事に完了すると仮定すると、処理ロジックはその後、現在ノードの情報を自分のローカルブロックの知人ノードリストおよびディスクストレージブロックに保存するとしてよい（処理ブロック４０６）。この保存される情報には、現在ノードのＩＰアドレス、認証が完了した時間を示すタイムスタンプ等の情報が含まれるとしてよい。処理ロジックはこの後、現在ノードのリソースリストを自分のディスクストレージブロックに保存することができる（処理ブロック４０８）。例えば、リソースリストは、現在ノードがメッシュネットワークに対して提供している全てのファイルおよび部分ファイルのメタデータを含むとしてよい。そして、処理ロジックは、処理しているリモートブロックの知人ノードリストの最後であるか否か、または、リスト内にノードが残っているか否かを判断する（処理ブロック４１２）。リストの最後であれば、リストの処理は終了する。リストの最後でなければ、処理ロジックは現在ノードをリスト内の次のノードにインクリメントして（処理ブロック４１４）、ブロック４０２に戻って処理を続ける。
【００３８】
ブロック４０２に戻って、現在ノードがローカルノードのローカルブロック内にある知人ノードリストに含まれていれば（つまり、ローカルノードが既に現在ノードを認識していれば）、処理ロジックは、ローカルノードのディスクストレージブロックに格納されている現在ノードのリソース情報が最新のものであるか否かを判断する（処理ブロック４１０）。例えば、リソース情報は、現在ノードが最後にリソース情報リストを更新した正確な時刻を示すタイムスタンプを含むリストであるとしてよい。このため、現在ノードが、ローカルブロック格納位置に格納されているリソース情報リスト内に他のノードに提供しているとして記載されているリソースを更新すれば、リスト全体のタイムスタンプもまた更新される。リソース情報リストは、タイムスタンプと共に、他のノード（のディスクストレージブロック）に格納されている。例えば、ローカルノードが、ディスクストレージブロックに格納しているリストにおいて現在ノードのリソース情報が変更されたか否かを調べたい場合、自分が格納しているタイムスタンプと、現在ノードがローカルブロックに現在保有しているタイムスタンプとを比較することができる。これら２つのタイムスタンプが一致すれば、ローカルノードは、保有しているリソース情報リストが現在のものであると結論付ける。これら２つのタイムスタンプが一致しない場合、ローカルノードは、保有しているリソース情報リストが古いものであると結論付ける。
【００３９】
処理ロジックは、リソース情報リストが最新のものでない場合、現在ノードのリソースリストを自分のディスクストレージブロックに保存する（処理ブロック４０８）。処理ロジックはその後、処理しているリモートブロックの知人ノードリストの最後であるか否か、または、リスト内にノードが残っているか否かを判断する（処理ブロック４１２）。リストの最後であれば、リストの処理は終了する。リストの最後でなければ、処理ロジックは現在ノードをリスト内の次のノードにインクリメントして（処理ブロック４１４）、ブロック４０２に戻って処理を続ける。
【００４０】
ブロック４１０に戻って、処理ロジックは、リソース情報リストが最新のものであれば、処理しているリモートブロックの知人ノードリストの最後であるか否か、または、リスト内にノードが残っているか否かを判断する（処理ブロック４１２）。リストの最後であれば、リストの処理は終了する。リストの最後でなければ、処理ロジックは現在ノードをリスト内の次のノードにインクリメントして（処理ブロック４１４）、ブロック４０２に戻って処理を続ける。
【００４１】
図５は、ローカルノードがメッシュネットワーク内の別のノードを確認して当該別のノードと関連メッシュネットワーク情報のやり取りを行う方法の実施形態を示すフローチャートである。
【００４２】
同図に示す方法は、ハードウェア（例えば、汎用コンピュータの回路）、ソフトウェア（例えば、ＯＳまたはソフトウェアアプリケーションコード）、ファームウェア（例えば、マイクロコードまたは基本入出力システム（ＢＩＯＳ）コード）、または、このような形態の処理ロジックのうち任意の２つ以上を組み合わせたものを含む処理ロジックによって実行される。多くの実施形態によると、図５の処理ロジックは、メッシュネットワークのローカルノードに設けられている。
【００４３】
当該方法は、ローカルノード（例えば、第１のノード）に設けられている処理ロジックが、メッシュネットワーク内の別のノード（例えば、第２のノード）に接触することによって開始される（処理ブロック５００）。「接触する」プロセスでは、第１のノードが第２のノードのＩＰアドレス（または、位置情報を与える別の種類のアドレス）を保有していることが要件となる。接触が行われると、第１のノードの処理ロジックは、第２のノードとの間でメッシュ証明書確認手順を実行するとしてよい（処理ブロック５０２）。メッシュ証明書確認手順では、第１のノードが自分のメッシュ証明書を第２のノードに提供して、第２のノードが自分のメッシュ証明書を第１のノードに提供するとしてよい。確認手順が完了すると、確認手順が成功したと仮定して、第１のノードの処理ロジックは、第２のノードの知人ノードリストを第２のノードのローカルブロック格納位置から取得するとしてよい（処理ブロック５０４）。
【００４４】
最後に、処理ロジックは、第１のノードの知人ノードリストを第２のノードのリモートブロックに格納する（処理ブロック５０６）。この結果、第１のノードの既知の知人ノード情報は第２のノードに渡される。この手順全体が終了すると、第１のノードおよび第２のノードにおいて、確認手順前には各ノードが別個に保有していた知人ノード情報がまとめられる。
【００４５】
図６は、ローカルノードが第三者サーバに接触して当該第三者サーバによってリーダーノードにアップグレードされる方法の実施形態を示すフローチャートである。
【００４６】
同図に示す方法は、ハードウェア（例えば、汎用コンピュータの回路）、ソフトウェア（例えば、ＯＳまたはソフトウェアアプリケーションコード）、ファームウェア（例えば、マイクロコードまたは基本入出力システム（ＢＩＯＳ）コード）、または、このような形態の処理ロジックのうち任意の２つ以上を組み合わせたものを含む処理ロジックによって実行される。多くの実施形態によると、図６の処理ロジックは、メッシュネットワークのローカルノードに設けられている。
【００４７】
当該方法は、ローカルノード内の処理ロジックが第三者サーバに接触することによって開始される（処理ブロック６００）。第三者サーバのＩＰアドレスは、メッシュネットワーク内の別のノードによって、または、メッシュネットワーク管理部によって、ローカルノードに提供されるとしてよい。続いて、処理ロジックが第三者サーバに、メッシュネットワーク内のリーダーポジションが空いているか否かを問い合わせる（処理ブロック６０２）。リーダーポジションが空いているのは、リーダーポジションが空いていることを意味するグローバル可視フラグを第三者サーバが設定している場合であるとしてよい。リーダーポジションが空いていて、且つ、ローカルノードがリーダーへと昇格する機能を持つ場合、ローカルノードは専用の二方向通信トンネルを第三者サーバとの間に構築する（処理ブロック６０４）。このような専用トンネルによって、ローカルノードは、第三者サーバから、詳細な情報およびコマンドを受信することができるようになる。ファイヤーウォール等のセキュリティ手順がメッシュネットワークに対して設けられているので、トンネルがなければ、ローカルノードは第三者サーバからコマンドを受信することが不可能になってしまうこともある。多くの実施形態によると、トンネル構築前に、ローカルノードと第三者サーバとの間でセキュアな確認手順を実行して、互いに認証し合うとしてよい。リーダーポジションが空いていない場合、処理を終える（つまり、メッシュネットワーク内の別のノードが既にリーダーノードとして設定されており、この別のノードが現在動作していることになる）。
【００４８】
分散型メッシュネットワークを実施するためのデバイス、方法、およびシステムの実施形態を説明した。上述した実施形態は、具体的な実施形態例を参照しつつ説明している。本明細書に記載した実施形態を広く解釈した場合の思想および範囲を逸脱することなく、本開示内容に基づき上記の実施形態をさまざまな点で変形および変更し得ることは、明らかである。したがって、本明細書および添付図面は、本発明を限定するものではなく例示するものと解されたい。
【特許請求の範囲】
【請求項１】
メッシュネットワークに含まれる第１のコンピューティングデバイスであって、
前記第１のコンピューティングデバイスがウェイク状態の場合に動作し、前記メッシュネットワークに含まれる既知のピアコンピューティングデバイスの最新リストを格納する第１のストレージデバイスと、
少なくとも、前記第１のコンピューティングデバイスが提供するリソースのリスト、および、前記メッシュネットワークに含まれる、前記第１のコンピューティングデバイスが確認済のコンピューティングデバイスのリストを格納するローカルブロックと、前記メッシュネットワークに含まれる、未確認のコンピューティングデバイスのリモートリストを格納するリモートブロックとを有し、前記コンピューティングデバイスの任意の中央演算処理装置がウェイク状態かスリープ状態かに関係なく動作する第２のストレージデバイスと
を備える第１のコンピューティングデバイス。
【請求項２】
前記未確認のコンピューティングデバイスのリストは、前記メッシュネットワークに含まれる第２のコンピューティングデバイスが提供する、既知のコンピューティングデバイスのリモートリストのローカルコピーを含む請求項１に記載の第１のコンピューティングデバイス。
【請求項３】
スリープ状態からウェイク状態へと移行すると、前記第１のコンピューティングデバイスの前記ローカルブロックに格納されている、前記メッシュネットワークに含まれる確認済のコンピューティングデバイスの第１のリストと、前記第１のコンピューティングデバイスの前記リモートブロックに格納されている、前記既知のコンピューティングデバイスのリモートリストとを比較し、
前記第１のコンピューティングデバイスの前記リモートブロックに格納されているリストに含まれているコンピューティングデバイスのうち、前記第１のコンピューティングデバイスのローカルブロックに格納されているリストに含まれていない任意のコンピューティングデバイスを確認し、
前記第１のコンピューティングデバイスの前記ローカルブロックに格納されている前記確認済のコンピューティングデバイスのリストを、前記第１のコンピューティングデバイスの前記リモートブロックに格納されているリストのうち新たに確認された任意のコンピューティングデバイスで更新する
請求項２に記載の第１のコンピューティングデバイス。
【請求項４】
前記第１のストレージデバイスに格納されている前記既知のピアコンピューティングデバイスの最新リストを、前記確認済のコンピューティングデバイスのリストに更新された、新たに確認された任意のコンピューティングデバイスで更新する請求項３に記載の第１のコンピューティングデバイス。
【請求項５】
前記第１のストレージデバイスに格納されている、前記メッシュネットワークに含まれる前記既知のピアコンピューティングデバイスの最新リストに含まれるピアコンピューティングデバイスのそれぞれについて、それぞれのピアコンピューティングデバイスが提供するリソースのリストをさらに格納する請求項１に記載の第１のコンピューティングデバイス。
【請求項６】
前記第１のコンピューティングデバイスの前記ローカルブロックに格納されている前記確認済のコンピューティングデバイスのリストに含まれる第２のコンピューティングデバイスと接触して、
前記第２のコンピューティングデバイスのローカルブロックに格納されているコンピューティングデバイスの確認済のリストを読み出し、
前記確認済のコンピューティングデバイスのリストを前記第２のコンピューティングデバイスのリモートブロックに格納する
請求項１に記載の第１のコンピューティングデバイス。
【請求項７】
前記第１のコンピューティングデバイスの正当性を前記第２のコンピューティングデバイスにセキュアに確認させるための前記第１のコンピューティングデバイスの第１のメッシュ証明書を、前記第２のコンピューティングデバイスに供給して、
前記第２のコンピューティングデバイスの正当性を前記第１のコンピューティングデバイスにセキュアに確認させるための前記第２のコンピューティングデバイスの第２のメッシュ証明書を、前記第２のコンピューティングデバイスから受信する
請求項６に記載の第１のコンピューティングデバイス。
【請求項８】
複数のコンピューティングデバイスを含む前記メッシュネットワークのリーダーに指名され、前記リーダーであるコンピューティングデバイスは、前記メッシュネットワークの外部のリモートサーバとの間に二方向通信トンネルを構築する請求項１に記載の第１のコンピューティングデバイス。
【請求項９】
前記リモートサーバから要求されると、前記メッシュネットワークに含まれる第２のコンピューティングデバイスをウェイク状態とする請求項８に記載の第１のコンピューティングデバイス。
【請求項１０】
前記リモートサーバ上のリーダーポジション空きフラグを読み出して、
前記フラグが設定されている場合、前記リモートサーバとの間に前記二方向通信トンネルを構築し、
前記フラグが設定されていない場合、前記リモートサーバとの間に非二方向通信を維持する
請求項８に記載の第１のコンピューティングデバイス。
【請求項１１】
前記メッシュネットワークに新たに結合される第２のコンピューティングデバイスとの間に高信頼性の接続を構築し、前記高信頼性の接続によって、前記第２のコンピューティングデバイスにアウトオブバンド管理ロジックを実現する請求項１に記載の第１のコンピューティングデバイス。
【請求項１２】
第１のコンピューティングデバイスに設けられているストレージデバイスのローカルブロックに、メッシュネットワークに前記第１のコンピューティングデバイスから提供されるリソースのリスト、および、前記メッシュネットワークに含まれており前記第１のコンピューティングデバイスが確認済であるコンピューティングデバイスのリストを格納する段階と、
前記ストレージデバイスのリモートブロックに、前記メッシュネットワークに含まれており未確認のコンピューティングデバイスのリモートリストを格納する段階と
を備え、
前記未確認のコンピューティングデバイスのリストは、前記メッシュネットワークに含まれる第２のコンピューティングデバイスが提供する、既知のコンピューティングデバイスのリモートリストのローカルコピーを含む方法。
【請求項１３】
前記第１のコンピューティングデバイスがスリープ状態からウェイク状態に移行すると、前記第１のコンピューティングデバイスの前記ローカルブロックに格納されている前記メッシュネットワークに含まれる前記確認済のコンピューティングデバイスの第１のリストと、前記第１のコンピューティングデバイスの前記リモートブロックに格納されている前記既知のコンピューティングデバイスのリモートリストとを比較する段階と、
前記第１のコンピューティングデバイスの前記リモートブロックに格納されている前記リストに含まれているコンピューティングデバイスのうち、前記第１のコンピューティングデバイスの前記ローカルブロックに格納されている前記リストに含まれていない任意のコンピューティングデバイスを確認する段階と、
前記第１のコンピューティングデバイスの前記ローカルブロックの前記確認済のコンピューティングデバイスのリストを、前記第１のコンピューティングデバイスの前記リモートブロックに格納されているリストのうち新たに確認された任意のコンピューティングデバイスで更新する段階と
をさらに備える請求項１２に記載の方法。
【請求項１４】
前記第１のコンピューティングデバイスのローカルブロックに格納されている前記確認済のコンピューティングデバイスのリストに含まれる第２のコンピューティングデバイスと接触する段階と、
前記第２のコンピューティングデバイスのローカルブロックに格納されているコンピューティングデバイスの確認済のリストを読み出す段階と、
前記第２のコンピューティングデバイスのリモートブロックに前記確認済のコンピューティングデバイスのリストを格納する段階と
をさらに備える請求項１２に記載の方法。
【請求項１５】
前記第１のコンピューティングデバイスの正当性を前記第２のコンピューティングデバイスにセキュアに確認させるための前記第１のコンピューティングデバイスの第１のメッシュ証明書を、前記第２のコンピューティングデバイスに供給する段階と、
前記第２のコンピューティングデバイスの正当性を前記第１のコンピューティングデバイスにセキュアに確認させるための前記第２のコンピューティングデバイスの第２のメッシュ証明書を、前記第２のコンピューティングデバイスから受信する段階と
をさらに備える請求項１３に記載の方法。
【請求項１６】
前記第１のコンピューティングデバイスを、複数のコンピューティングデバイスを含む前記メッシュネットワークのリーダーに指名する段階
をさらに備え、
前記リーダーであるコンピューティングデバイスは、前記メッシュネットワークの外部のリモートサーバとの間に二方向通信トンネルを構築する請求項１２に記載の方法。
【請求項１７】
第１のコンピューティングデバイスを含む複数のコンピューティングデバイスを有するメッシュネットワークと、
リモートサーバと
を備え、
前記第１のコンピューティングデバイスは、
前記第１のコンピューティングデバイスの電源が入ると動作し、前記メッシュネットワークに含まれる既知のピアコンピューティングデバイスの最新ローカルリストを格納する大容量ストレージデバイスと、
前記第１のコンピューティングデバイスの電源が入っているか否かとは無関係に動作するフラッシュメモリと
を持ち、
前記フラッシュメモリは少なくとも、
前記第１のコンピューティングデバイスが提供するリソースのリスト、および、前記メッシュネットワークに含まれる確認済のコンピュータシステムのリストを格納するローカルブロックと、
前記メッシュネットワークに含まれる未確認のコンピュータシステムのリストを格納するリモートブロックと
を持ち、
前記リモートサーバは、
前記メッシュネットワークに含まれるピアコンピューティングデバイスのグローバルリストを格納し、
前記メッシュネットワークに含まれる前記複数のコンピューティングデバイスのうち１つをリーダーコンピューティングデバイスに指名するシステム。
【請求項１８】
前記未確認のコンピューティングデバイスのリストは、前記メッシュネットワークに含まれる第２のコンピューティングデバイスが提供する、既知のコンピューティングデバイスのリモートリストのローカルコピーを含む請求項１７に記載のシステム。
【請求項１９】
前記第１のコンピューティングデバイスは、
スリープ状態からウェイク状態に移行すると、前記第１のコンピューティングデバイスの前記ローカルブロックに格納されている、前記メッシュネットワークに含まれる確認済のコンピューティングデバイスの第１のリストと、前記第１のコンピューティングデバイスの前記リモートブロックに格納されている前記既知のコンピューティングデバイスのリモートリストとを比較し、
前記第１のコンピューティングデバイスの前記リモートブロックに格納されている前記リストに含まれているコンピューティングデバイスのうち、前記第１のコンピューティングデバイスの前記ローカルブロックに格納されている前記リストに含まれていない任意のコンピューティングデバイスを確認し、
前記第１のコンピューティングデバイスの前記ローカルブロックに格納されている前記確認済のコンピューティングデバイスのリストを、前記第１のコンピューティングデバイスの前記リモートブロックに格納されている前記リストのうち新たに確認された任意のコンピューティングデバイスで更新する請求項１８に記載のシステム。
【請求項２０】
前記第１のコンピューティングデバイスは、
前記第１のコンピューティングデバイスの前記ローカルブロックに格納されている前記確認済のコンピューティングデバイスのリストに含まれる第２のコンピューティングデバイスと接触して、
前記第２のコンピューティングデバイスのローカルブロックに格納されているコンピューティングデバイスの確認済のリストを読み出し、
前記確認済のコンピューティングデバイスのリストを前記第２のコンピューティングデバイスのリモートブロックに格納する
請求項１７に記載のシステム。
【請求項１】
メッシュネットワークに含まれる第１のコンピューティングデバイスであって、
前記第１のコンピューティングデバイスがウェイク状態の場合に動作し、前記メッシュネットワークに含まれる既知のピアコンピューティングデバイスの最新リストを格納する第１のストレージデバイスと、
少なくとも、前記第１のコンピューティングデバイスが提供するリソースのリスト、および、前記メッシュネットワークに含まれる、前記第１のコンピューティングデバイスが確認済のコンピューティングデバイスのリストを格納するローカルブロックと、前記メッシュネットワークに含まれる、未確認のコンピューティングデバイスのリモートリストを格納するリモートブロックとを有し、前記コンピューティングデバイスの任意の中央演算処理装置がウェイク状態かスリープ状態かに関係なく動作する第２のストレージデバイスと
を備える第１のコンピューティングデバイス。
【請求項２】
前記未確認のコンピューティングデバイスのリストは、前記メッシュネットワークに含まれる第２のコンピューティングデバイスが提供する、既知のコンピューティングデバイスのリモートリストのローカルコピーを含む請求項１に記載の第１のコンピューティングデバイス。
【請求項３】
スリープ状態からウェイク状態へと移行すると、前記第１のコンピューティングデバイスの前記ローカルブロックに格納されている、前記メッシュネットワークに含まれる確認済のコンピューティングデバイスの第１のリストと、前記第１のコンピューティングデバイスの前記リモートブロックに格納されている、前記既知のコンピューティングデバイスのリモートリストとを比較し、
前記第１のコンピューティングデバイスの前記リモートブロックに格納されているリストに含まれているコンピューティングデバイスのうち、前記第１のコンピューティングデバイスのローカルブロックに格納されているリストに含まれていない任意のコンピューティングデバイスを確認し、
前記第１のコンピューティングデバイスの前記ローカルブロックに格納されている前記確認済のコンピューティングデバイスのリストを、前記第１のコンピューティングデバイスの前記リモートブロックに格納されているリストのうち新たに確認された任意のコンピューティングデバイスで更新する
請求項２に記載の第１のコンピューティングデバイス。
【請求項４】
前記第１のストレージデバイスに格納されている前記既知のピアコンピューティングデバイスの最新リストを、前記確認済のコンピューティングデバイスのリストに更新された、新たに確認された任意のコンピューティングデバイスで更新する請求項３に記載の第１のコンピューティングデバイス。
【請求項５】
前記第１のストレージデバイスに格納されている、前記メッシュネットワークに含まれる前記既知のピアコンピューティングデバイスの最新リストに含まれるピアコンピューティングデバイスのそれぞれについて、それぞれのピアコンピューティングデバイスが提供するリソースのリストをさらに格納する請求項１に記載の第１のコンピューティングデバイス。
【請求項６】
前記第１のコンピューティングデバイスの前記ローカルブロックに格納されている前記確認済のコンピューティングデバイスのリストに含まれる第２のコンピューティングデバイスと接触して、
前記第２のコンピューティングデバイスのローカルブロックに格納されているコンピューティングデバイスの確認済のリストを読み出し、
前記確認済のコンピューティングデバイスのリストを前記第２のコンピューティングデバイスのリモートブロックに格納する
請求項１に記載の第１のコンピューティングデバイス。
【請求項７】
前記第１のコンピューティングデバイスの正当性を前記第２のコンピューティングデバイスにセキュアに確認させるための前記第１のコンピューティングデバイスの第１のメッシュ証明書を、前記第２のコンピューティングデバイスに供給して、
前記第２のコンピューティングデバイスの正当性を前記第１のコンピューティングデバイスにセキュアに確認させるための前記第２のコンピューティングデバイスの第２のメッシュ証明書を、前記第２のコンピューティングデバイスから受信する
請求項６に記載の第１のコンピューティングデバイス。
【請求項８】
複数のコンピューティングデバイスを含む前記メッシュネットワークのリーダーに指名され、前記リーダーであるコンピューティングデバイスは、前記メッシュネットワークの外部のリモートサーバとの間に二方向通信トンネルを構築する請求項１に記載の第１のコンピューティングデバイス。
【請求項９】
前記リモートサーバから要求されると、前記メッシュネットワークに含まれる第２のコンピューティングデバイスをウェイク状態とする請求項８に記載の第１のコンピューティングデバイス。
【請求項１０】
前記リモートサーバ上のリーダーポジション空きフラグを読み出して、
前記フラグが設定されている場合、前記リモートサーバとの間に前記二方向通信トンネルを構築し、
前記フラグが設定されていない場合、前記リモートサーバとの間に非二方向通信を維持する
請求項８に記載の第１のコンピューティングデバイス。
【請求項１１】
前記メッシュネットワークに新たに結合される第２のコンピューティングデバイスとの間に高信頼性の接続を構築し、前記高信頼性の接続によって、前記第２のコンピューティングデバイスにアウトオブバンド管理ロジックを実現する請求項１に記載の第１のコンピューティングデバイス。
【請求項１２】
第１のコンピューティングデバイスに設けられているストレージデバイスのローカルブロックに、メッシュネットワークに前記第１のコンピューティングデバイスから提供されるリソースのリスト、および、前記メッシュネットワークに含まれており前記第１のコンピューティングデバイスが確認済であるコンピューティングデバイスのリストを格納する段階と、
前記ストレージデバイスのリモートブロックに、前記メッシュネットワークに含まれており未確認のコンピューティングデバイスのリモートリストを格納する段階と
を備え、
前記未確認のコンピューティングデバイスのリストは、前記メッシュネットワークに含まれる第２のコンピューティングデバイスが提供する、既知のコンピューティングデバイスのリモートリストのローカルコピーを含む方法。
【請求項１３】
前記第１のコンピューティングデバイスがスリープ状態からウェイク状態に移行すると、前記第１のコンピューティングデバイスの前記ローカルブロックに格納されている前記メッシュネットワークに含まれる前記確認済のコンピューティングデバイスの第１のリストと、前記第１のコンピューティングデバイスの前記リモートブロックに格納されている前記既知のコンピューティングデバイスのリモートリストとを比較する段階と、
前記第１のコンピューティングデバイスの前記リモートブロックに格納されている前記リストに含まれているコンピューティングデバイスのうち、前記第１のコンピューティングデバイスの前記ローカルブロックに格納されている前記リストに含まれていない任意のコンピューティングデバイスを確認する段階と、
前記第１のコンピューティングデバイスの前記ローカルブロックの前記確認済のコンピューティングデバイスのリストを、前記第１のコンピューティングデバイスの前記リモートブロックに格納されているリストのうち新たに確認された任意のコンピューティングデバイスで更新する段階と
をさらに備える請求項１２に記載の方法。
【請求項１４】
前記第１のコンピューティングデバイスのローカルブロックに格納されている前記確認済のコンピューティングデバイスのリストに含まれる第２のコンピューティングデバイスと接触する段階と、
前記第２のコンピューティングデバイスのローカルブロックに格納されているコンピューティングデバイスの確認済のリストを読み出す段階と、
前記第２のコンピューティングデバイスのリモートブロックに前記確認済のコンピューティングデバイスのリストを格納する段階と
をさらに備える請求項１２に記載の方法。
【請求項１５】
前記第１のコンピューティングデバイスの正当性を前記第２のコンピューティングデバイスにセキュアに確認させるための前記第１のコンピューティングデバイスの第１のメッシュ証明書を、前記第２のコンピューティングデバイスに供給する段階と、
前記第２のコンピューティングデバイスの正当性を前記第１のコンピューティングデバイスにセキュアに確認させるための前記第２のコンピューティングデバイスの第２のメッシュ証明書を、前記第２のコンピューティングデバイスから受信する段階と
をさらに備える請求項１３に記載の方法。
【請求項１６】
前記第１のコンピューティングデバイスを、複数のコンピューティングデバイスを含む前記メッシュネットワークのリーダーに指名する段階
をさらに備え、
前記リーダーであるコンピューティングデバイスは、前記メッシュネットワークの外部のリモートサーバとの間に二方向通信トンネルを構築する請求項１２に記載の方法。
【請求項１７】
第１のコンピューティングデバイスを含む複数のコンピューティングデバイスを有するメッシュネットワークと、
リモートサーバと
を備え、
前記第１のコンピューティングデバイスは、
前記第１のコンピューティングデバイスの電源が入ると動作し、前記メッシュネットワークに含まれる既知のピアコンピューティングデバイスの最新ローカルリストを格納する大容量ストレージデバイスと、
前記第１のコンピューティングデバイスの電源が入っているか否かとは無関係に動作するフラッシュメモリと
を持ち、
前記フラッシュメモリは少なくとも、
前記第１のコンピューティングデバイスが提供するリソースのリスト、および、前記メッシュネットワークに含まれる確認済のコンピュータシステムのリストを格納するローカルブロックと、
前記メッシュネットワークに含まれる未確認のコンピュータシステムのリストを格納するリモートブロックと
を持ち、
前記リモートサーバは、
前記メッシュネットワークに含まれるピアコンピューティングデバイスのグローバルリストを格納し、
前記メッシュネットワークに含まれる前記複数のコンピューティングデバイスのうち１つをリーダーコンピューティングデバイスに指名するシステム。
【請求項１８】
前記未確認のコンピューティングデバイスのリストは、前記メッシュネットワークに含まれる第２のコンピューティングデバイスが提供する、既知のコンピューティングデバイスのリモートリストのローカルコピーを含む請求項１７に記載のシステム。
【請求項１９】
前記第１のコンピューティングデバイスは、
スリープ状態からウェイク状態に移行すると、前記第１のコンピューティングデバイスの前記ローカルブロックに格納されている、前記メッシュネットワークに含まれる確認済のコンピューティングデバイスの第１のリストと、前記第１のコンピューティングデバイスの前記リモートブロックに格納されている前記既知のコンピューティングデバイスのリモートリストとを比較し、
前記第１のコンピューティングデバイスの前記リモートブロックに格納されている前記リストに含まれているコンピューティングデバイスのうち、前記第１のコンピューティングデバイスの前記ローカルブロックに格納されている前記リストに含まれていない任意のコンピューティングデバイスを確認し、
前記第１のコンピューティングデバイスの前記ローカルブロックに格納されている前記確認済のコンピューティングデバイスのリストを、前記第１のコンピューティングデバイスの前記リモートブロックに格納されている前記リストのうち新たに確認された任意のコンピューティングデバイスで更新する請求項１８に記載のシステム。
【請求項２０】
前記第１のコンピューティングデバイスは、
前記第１のコンピューティングデバイスの前記ローカルブロックに格納されている前記確認済のコンピューティングデバイスのリストに含まれる第２のコンピューティングデバイスと接触して、
前記第２のコンピューティングデバイスのローカルブロックに格納されているコンピューティングデバイスの確認済のリストを読み出し、
前記確認済のコンピューティングデバイスのリストを前記第２のコンピューティングデバイスのリモートブロックに格納する
請求項１７に記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１１−１７２２０４（Ｐ２０１１−１７２２０４Ａ）
【公開日】平成２３年９月１日（２０１１．９．１）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１０−２３４６４３（Ｐ２０１０−２３４６４３）
【出願日】平成２２年１０月１９日（２０１０．１０．１９）
【出願人】（５９１００３９４３）インテル・コーポレーション (1,101)
【Ｆターム（参考）】
【公開日】平成２３年９月１日（２０１１．９．１）
【国際特許分類】
【出願番号】特願２０１０−２３４６４３（Ｐ２０１０−２３４６４３）
【出願日】平成２２年１０月１９日（２０１０．１０．１９）
【出願人】（５９１００３９４３）インテル・コーポレーション (1,101)
【Ｆターム（参考）】
[ Back to top ]