(57)【特許請求の範囲】
【請求項１】
データを記憶するためにピア・ツー・ピアオーバーレイネットワークの発行ノードで動作可能な方法であって： 
前記発行ノードにおいて、リソース識別子を生成し、前記リソース識別子を第１のデータに関連付けることと、なお、前記リソース識別子は、前記発行ノードを識別する第１の文字列および前記第１のデータのための用途タイプに関連付けられた第２の文字列の組み合わせの関数であり、前記第１の文字列は記憶ノードによって独立して認証可能であり、前記リソース識別子は前記記憶ノードによって検証可能である； 
前記発行ノードにおいて、前記リソース識別子、前記第１の文字列、および記憶されるべき前記第１のデータを含む記憶要求を生成することと； 
前記記憶ノードに、前記オーバーレイネットワークを通して前記記憶要求を送信することと、なお、前記リソース識別子は、識別子スペースに対して責任を持つ前記記憶ノードにマッピングし、前記記憶要求は、前記記憶ノードによってサポートされる用途とは独立に前記記憶ノードによって許可され、前記記憶要求の許可は、プロトコル階層において用途レベルよりも下であるオーバーレイレベルで前記第１の文字列の認証可能な証明を提供することに基づいて検証可能である； 
を備える方法。 
【請求項２】
前記第２の文字列は任意の文字列である、請求項１の方法。 
【請求項３】
前記第２の文字列は前記オーバーレイネットワーク内のサービスについての既定の文字列である、請求項１の方法。
【請求項４】
複数の異なるリソース識別子を生成することをさらに備え、前記複数の異なるリソース識別子の各々は前記第１の文字列および異なる第２の文字列の組み合わせの関数である、請求項１の方法。 
【請求項５】
前記異なるリソース識別子を生成することは、異なる記憶ノードが異なる識別子スペースに対して責任を持つ前記オーバーレイネットワーク内にデータ記憶負荷拡散を引き起こす、請求項４の方法。 
【請求項６】
前記記憶要求は前記第１の文字列のインジケータも含む、請求項１の方法。
【請求項７】
前記記憶要求は前記第２の文字列のインジケータも含む、請求項１の方法。 
【請求項８】
前記第２の文字列は、前記記憶ノードに記憶されるべき前記第１のデータに関連付けられる前記用途を識別する既定の文字列である、請求項１の方法。
【請求項９】
ピア・ツー・ピアオーバーレイネットワークを通して通信するための通信インターフェースと； 
前記通信インターフェースに結合されたコンピュータプロセッサと； 
を備え、前記コンピュータプロセッサは、 
リソース識別子を生成し、前記リソース識別子を第１のデータに関連付けることと、なお、前記リソース識別子は、前記発行ノードを識別する第１の文字列および前記第１のデータのための用途タイプに関連付けられた第２の文字列の組み合わせの関数であり、前記第１の文字列は記憶ノードによって独立して認証可能であり、前記リソース識別子は前記記憶ノードによって検証可能である； 
前記リソース識別子、前記第１の文字列、および記憶されるべき前記第１のデータを含む記憶要求を生成することと； 
前記記憶ノードに、前記オーバーレイネットワークを通して前記記憶要求を送信することと、なお、前記リソース識別子は、識別子スペースに対して責任を持つ前記記憶ノードにマッピングし、前記記憶要求は前記記憶ノードによってサポートされる用途とは独立に前記記憶ノードによって許可され、前記記憶要求の許可はプロトコル階層において用途レベルよりも下であるオーバーレイレベルで前記第１の文字列の認証可能な証明を提供することに基づいて検証可能である； 
に適応される、発行ノードデバイス。
【請求項１０】
前記第２の文字列は任意の文字列である、請求項９の発行ノードデバイス。
【請求項１１】
前記第２の文字列は前記オーバーレイネットワーク内のサービスについての既定の文字列である、請求項９の発行ノードデバイス。
【請求項１２】
前記プロセッサは、複数の異なるリソース識別子を生成することにさらに適応され、前記複数の異なるリソース識別子の各々は前記第１の文字列および異なる第２の文字列の組み合わせの関数である、請求項１０の発行ノードデバイス。
【請求項１３】
前記異なるリソース識別子を生成することは、異なる記憶ノードが異なる識別子スペースに対して責任を持つ前記オーバーレイネットワーク内でデータ記憶負荷拡散を引き起こす、請求項１２の発行ノードデバイス。 
【請求項１４】
発行ノードにおいて、リソース識別子を生成し、前記リソース識別子を第１のデータに関連付けるための手段と、なお、前記リソース識別子は、前記発行ノードを識別する第１の文字列および前記第１のデータのための用途タイプに関連付けられた第２の文字列の組み合わせの関数であり、前記第１の文字列は記憶ノードによって独立して認証可能であり、前記リソース識別子は前記記憶ノードによって検証可能である； 
前記リソース識別子、前記第１の文字列、および記憶されるべき前記第１のデータを含む記憶要求を生成するための手段と； 
前記記憶ノードに、ピア・ツー・ピアオーバーレイネットワークを通して前記記憶要求を送信するための手段と、なお、前記リソース識別子は、識別子スペースに対して責任を持つ前記記憶ノードにマッピングし、前記記憶要求は前記記憶ノードによってサポートされる用途タイプとは独立に前記記憶ノードによって許可され、前記記憶要求の許可はプロトコル階層において用途レベルよりも下であるオーバーレイレベルで前記第１の文字列の認証可能な証明を提供することに基づいて検証可能である； 
を備える発行ノードデバイス。 
【請求項１５】
前記第２の文字列は、前記記憶ノードに記憶されるべき前記第１のデータに関連付けられる前記用途を識別する既定の文字列である、請求項１４の発行ノードデバイス。
【請求項１６】
記憶ノード上で動作可能な方法であって： 
前記記憶ノードにおいて、ピア・ツー・ピアオーバーレイネットワークにおける発行ノードのデータを記憶するために第１の記憶要求を受信することと、なお、前記第１の記憶要求は、第１のリソース識別子、前記発行ノードを識別する認証可能な第１の文字列、および記憶されるべき関連付けられた第１のデータを含み、前記第１のリソース識別子は前記第１の文字列と、前記第１のデータのための用途タイプに関連付けられた第２の文字列との組み合わせの関数である； 
前記記憶ノードにおいて、前記第１のリソース識別子を検証することによって、プロトコル階層のオーバーレイレベルで独立記憶許可を実行することと、なお、前記実行される独立記憶許可は、前記記憶ノードによってサポートされる用途とは独立に前記第１の文字列の認証可能な証明を提供することに基づき、前記オーバーレイレベルは、前記プロトコル階層において用途レベルよりも下である； 
前記第１のリソース識別子の検証に成功すると、前記記憶ノードにおいて、前記第１のデータを記憶し、それを前記第１のリソース識別子と関連付けることと； 
を備える方法。
【請求項１７】
前記オーバーレイレベルで独立記憶許可を実行することは： 
前記第１の文字列を認証することと； 
前記第１のリソース識別子が前記第１の文字列および前記第２の文字列の組み合わせの関数であるか否かを決定することと； 
を含む、請求項１６の方法。
【請求項１８】
前記第２の文字列は任意の文字列である、請求項１６の方法。 
【請求項１９】
前記第２の文字列は前記オーバーレイネットワーク内のサービスについての既定の文字列である、請求項１６の方法。
【請求項２０】
前記記憶された第１のデータに対するデータアクセス要求を受信することと； 
前記データアクセス要求が前記第１のリソース識別子および前記第１の文字列につていの知識を立証する場合に、前記記憶された第１のデータへのアクセスを認可することと； 
をさらに備える、請求項１６の方法。 
【請求項２１】
前記データアクセス要求が前記第１のリソース識別子についての知識を立証し、しかしながら前記第１の文字列についての知識を立証できない場合、前記記憶された第１のデータへの読み取り専用アクセスを認可することをさらに備える、請求項２０の方法。 
【請求項２２】
前記記憶された第１のデータへのアクセスを認可することは、第２のデータを用いた前記第１のデータの置き換えを許すことを含む、請求項２０の方法。 
【請求項２３】
前記第２の文字列は、前記第１のデータに関連付けられる前記用途を識別する既定の文字列である、請求項１６の方法。
【請求項２４】
ピア・ツー・ピアオーバーレイネットワークを通して通信するための通信インターフェースと； 
前記通信インターフェースに結合されたコンピュータプロセッサと； 
を備え、 
前記プロセッサは： 
前記ピア・ツー・ピアオーバーレイネットワークにおける発行ノードのデータを記憶するために第１の記憶要求を受信することと、なお、前記第１の記憶要求は、第１のリソース識別子、前記発行ノードを識別する認証可能な第１の文字列、および記憶されるべき関連付けられた第１のデータを含み、前記第１のリソース識別子は、前記第１の文字列および前記第１のデータのための用途タイプに関連付けられた第２の文字列の組み合わせの関数である； 
前記第１のリソース識別子を検証することによって、プロトコル階層のオーバーレイレベルで独立記憶許可を実行することと、なお、前記実行される独立記憶許可は、前記記憶ノードによってサポートされる用途とは独立に前記第１の文字列の認証可能な証明を提供することに基づき、前記オーバーレイレベルは、前記プロトコル階層において用途レベルよりも下である； 
前記第１のリソース識別子の検証が成功すると、前記第１のデータを記憶し、それを前記第１のリソース識別子と関連付けることと； 
に適応される、記憶ノードデバイス。
【請求項２５】
前記オーバーレイレベルで独立記憶許可を実行することは： 
前記第１の文字列を認証することと； 
前記第１のリソース識別子が前記第１の文字列および前記第２の文字列の組み合わせの関数であるか否かを決定することと； 
を含む、請求項２４の記憶ノードデバイス。 
【請求項２６】
前記プロセッサは： 
前記記憶された第１のデータに対してデータアクセス要求を受信することと； 
前記データアクセス要求が前記第１のリソース識別子および前記第１の文字列についての知識を立証する場合、前記記憶された第１のデータへのアクセスを認可することと； 
にさらに適応される、請求項２４の記憶ノードデバイス。
【請求項２７】
前記プロセッサは、前記データアクセス要求が前記第１のリソース識別子についての知識を立証し、しかしながら前記第１の文字列についての知識を立証できない場合、前記記憶された第１のデータへの読み取り専用アクセスを認可することにさらに適応される、請求項２６の記憶ノードデバイス。
【請求項２８】
前記記憶ノードにおいて、ピア・ツー・ピアオーバーレイネットワークにおける発行ノードのデータを記憶するための第１の記憶要求を受信するための手段と、なお、前記第１の記憶要求は、第１のリソース識別子、前記発行ノードを識別する認証可能な第１の文字列、および記憶されるべき関連付けられた第１のデータを含み、前記第１のリソース識別子は前記第１の文字列および前記第１のデータのための用途タイプに関連付けられた第２の文字列の組み合わせの関数である； 
前記第１のリソース識別子を検証することによって、プロトコル階層のオーバーレイレベルで独立記憶許可を実行するための手段と、なお、前記実行される独立記憶許可は、前記記憶ノードによってサポートされる用途とは独立に前記第１の文字列の認証可能な証明を提供することに基づき、前記オーバーレイレベルは、前記プロトコル階層において用途レベルよりも下である； 
前記第１のリソース識別子の検証に成功すると、前記第１のデータを記憶し、それを前記第１のリソース識別子と関連付けるための手段と； 
を備える、記憶ノードデバイス。
【請求項２９】
データを記憶するためにピア・ツー・ピアオーバーレイネットワークの発行ノードで動作可能な方法であって： 
前記発行ノードにおいて、第２の文字列の関数としてリソース識別子を生成することと、なお、前記リソース識別子は記憶ノードによって検証可能であり、前記第２の文字列は、前記記憶ノードに記憶されるべき第１のデータに関連付けられる用途タイプを識別する既定の文字列である； 
前記発行ノードにおいて、前記リソース識別子、記憶されるべき前記第１のデータ、および前記記憶ノードによって独立して認証可能な第１の文字列を含む記憶要求を生成することと； 
前記記憶ノードに、前記オーバーレイネットワークを通して前記記憶要求を送信することと、なお、前記リソース識別子は、識別子スペースに対して責任を持つ前記記憶ノードにマッピングし、前記オーバーレイネットワーク内の異なる発行ノードは、異なる対応する第１の文字列であるが、同一の用途タイプの異なるデータに対して同一のリソース識別子を含むデータ記憶要求を生成し、前記異なるデータ記憶要求は、前記異なる対応する第１の文字列を使用する用途レベル許可に基づいて互いに区別可能である； 
を備える方法。
【請求項３０】
前記第１の文字列は発行ノード識別子である、請求項２９の方法。
【請求項３１】
前記第１の文字列は、前記記憶ノードに記憶されるべき前記データに追加され、前記リソース識別子は、前記第１の文字列とは独立している、請求項３０記載の方法。
【請求項３２】
前記記憶要求に対する許可は、前記第１の文字列を使用してプロトコル階層の用途レベルで検証可能であり、前記用途レベルは前記プロトコル階層においてオーバーレイレベルよりも上である、請求項２９の方法。
【請求項３３】
ピア・ツー・ピアオーバーレイネットワークを通して通信するための通信インターフェースと； 
前記通信インターフェースに結合されたコンピュータプロセッサと； 
を備え、 
前記プロセッサは： 
第２の文字列の関数としてリソース識別子を生成することと、なお、前記リソース識別子は記憶ノードによって検証可能であり、前記第２の文字列は、前記記憶ノードに記憶されるべき第１のデータに関連付けられる用途タイプを識別する既定の文字列である； 
前記リソース識別子、記憶されるべき前記第１のデータ、および前記記憶ノードによって独立して認証可能な第１の文字列を含む記憶要求を生成することと； 
前記記憶ノードに、前記オーバーレイネットワークを通して前記記憶要求を送信することと、なお、前記リソース識別子は、識別子スペースに対して責任を持つ前記記憶ノードにマッピングし、前記オーバーレイネットワーク内の異なる発行ノードは、異なる対応する第１の文字列であるが、同一の用途タイプの異なるデータに対して同一のリソース識別子を含むデータ記憶要求を生成し、前記異なるデータ記憶要求は、前記異なる対応する第１の文字列を使用する用途レベル許可に基づいて互いに区別可能である； 
に適応される、発行ノード。
【請求項３４】
記憶ノード上で動作可能な方法であって： 
前記記憶ノードにおいて、ピア・ツー・ピアオーバーレイネットワークにおいてデータを記憶するために第１の記憶要求を受信することと、前記第１の記憶要求は、第１のリソース識別子、記憶されるべき第１のデータ、および第１の発行ノード識別子を含み、なお、前記第１のリソース識別子は、前記第１のデータに関連付けられた用途タイプに基づき、前記第１のリソース識別子は、識別子スペースに対して責任を持つ前記記憶ノードにマッピングする； 
前記記憶ノードにおいて、前記ピア・ツー・ピアオーバーレイネットワークにおいてデータを記憶するために第２の記憶要求を受信することと、前記第２の記憶要求は、同一の第１のリソース識別子、記憶されるべき第２のデータ、および第２の発行ノード識別子を含み、前記第１のリソース識別子は、前記第２のデータと関連付けられた同一の用途タイプに基づく； 
前記記憶ノードにおいて、前記第１のデータおよび前記第１の発行ノード識別子を記憶し、それらを前記第１のリソース識別子と関連付けることと； 
前記記憶ノードにおいて、前記第２のデータおよび前記第２の発行ノード識別子を記憶し、それらを前記第１のリソース識別子と関連付けることと； 
を備え、
前記第１および第２のデータは、前記同一の第１のリソース識別子を使用することによってアクセス可能であり、各アクセスは、対応する第１および第２の発行ノード識別子に基づいて独立して認証可能である、方法。
【請求項３５】
前記第１のリソース識別子は、記憶されるべきデータのタイプと関連付けられた用途文字列の関数である、請求項３４の方法。 
【請求項３６】
前記第１のリソース識別子は、前記オーバーレイネットワーク内のサービスについての既定の文字列の関数である、請求項３４の方法。 
【請求項３７】
プロトコル階層の用途レベルで前記第１のリソース識別子および対応する発行ノード識別子を使用して独立記憶許可を実行することをさらに備え、前記用途レベルは前記プロトコル階層においてオーバーレイレベルよりも上である、請求項３４の方法。
【請求項３８】
前記第１のリソース識別子と関連付けられたデータに対してデータアクセス要求を受信することと； 
前記記憶された第１のデータおよび第２のデータへの読み取り専用アクセスを認可することと； 
をさらに備える、請求項３４の方法。
【請求項３９】
前記データアクセス要求が前記第１の発行ノード識別子についての知識を立証すると、前記記憶された第１のデータへの書込アクセスを認可することと； 
前記データアクセス要求が前記第２の発行ノード識別子についての知識を立証すると、前記記憶された第２のデータへの書込アクセスを認可することと； 
をさらに備える、請求項３８の方法。
【請求項４０】
前記第１のリソース識別子は、前記第１の文字列とは独立している、請求項３４の方法。
【請求項４１】
ピア・ツー・ピアオーバーレイネットワークを通して通信するための通信インターフェースと； 
前記通信インターフェースに結合されたコンピュータプロセッサと； 
を備え、 
前記プロセッサは： 
前記ピア・ツー・ピアオーバーレイネットワークにおいてデータを記憶するために第１の記憶要求を受信することと、前記第１の記憶要求は、第１のリソース識別子、記憶されるべき第１のデータ、および第１の発行ノード識別子を含み、なお、前記第１のリソース識別子は、前記第１のデータに関連付けられた用途タイプに基づき、前記第１の識別子は、識別子スペースに対して責任を持つ前記記憶ノードにマッピングする； 
前記ピア・ツー・ピアオーバーレイネットワークにおいてデータを記憶するために第２の記憶要求を受信することと、前記第２の記憶要求は、同一の第１のリソース識別子、記憶されるべき第２のデータ、および第２の発行ノード識別子を含み、前記第１のリソース識別子は、前記第２のデータと関連付けられた同一の用途タイプに基づく； 
前記第１のデータおよび前記第１の発行ノード識別子を記憶し、それらを前記第１のリソース識別子と関連付けることと； 
前記第２のデータおよび前記第２の発行ノード識別子を記憶し、それらを前記第１のリソース識別子と関連付けることと； 
に適応され、
前記第１および第２のデータは、前記同一の第１のリソース識別子を使用することによってアクセス可能であり、各アクセスは、対応する第１および第２の発行ノード識別子に基づいて独立して認証可能である、記憶ノードデバイス。 
【請求項４２】
前記第１のリソース識別子は、前記第１の文字列とは独立している、請求項４１の記憶ノードデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
様々な特徴は分散された通信および／または記憶システムに関する。少なくとも１つの態様は、ピア・ツー・ピアオーバーレイネットワークにおいて記憶を許可するための方法に関する。
【背景技術】
【０００２】
オーバーレイネットワークなどの構成されたピア・ツー・ピアネットワークは、典型的に、クエリのスケーラビリティおよび決定性ルーティング(deterministic routing)のために分散ハッシュテーブル（Distributed Hash Tables ; ＤＨＴ）を使用する。分散ハッシュテーブル（ＤＨＴ）は、ハッシュテーブルに類似したルックアップサービスを提供する非集中型分散システムの１つのクラスで、ノード名、識別子値の対がＤＨＴに記憶され、任意の関与ノードが所与のノード名と関連付けられた識別子値を効率的に検索することができる。各ノードはＤＨＴにおいて一意的なアイデンティティを有し、同様に、ネットワークに記憶された各サービスまたはオブジェクトは一意的なアイデンティティを有する。全てのアイデンティティは同一の識別子スペース、それは衝突を避けるために通常きわめて大きい、の一部である。アイデンティティを管理すること（例えば、ノード名から識別子値ＩＤにマッピングすること）に対する責任は、関与ノードのセットにおける変更が引き起こす妨害が最小となるように、ノード間で分散される。これは、ＤＨＴが極端に多数のノードに拡大すること、および、継続的なノードの到着、出発、および失敗を処理することを可能にする。ＤＨＴは、分散ファイルシステム、ピア・ツー・ピアファイル共有とコンテンツ配信システム、協調ウェブキャッシング、マルチキャスト、エニーキャスト、ドメイン名サービス、並びにインスタントメッセージングのような、より複雑なサービスを構築するために使用可能なインフラストラクチャを形成する。
【０００３】
特に、データを記憶および検索し、サービスインスタンスを発行し、それに加入する分散ハッシュテーブルを実行するそのような分散システムにおいては、どのエンティティがどこで発行するかについてのいなかる制御も存在しない。ゆえに、ノードがどこにデータを記憶しうるかを決定するために、ノードのアイデンティティが単独でまたはサービスエンティティとの組み合わせで使用されうるメカニズムが必要とされる。
【０００４】
そのようなシステムにおいて、記憶ノードに、データの所有者が実際その特定のノードまたはリソースＩＤで記憶する権限があることを検証させることは難しい。データが所与のノードによって記憶されうるロケーションの数をオーバーレイネットワークが制限できない場合、単一の有害ノードは、故意であろうと故意でなかろうと、オーバーレイネットワークにおいて利用可能な分散割り当てに悪影響を及す可能性がある。しかしながら、１つのノードに対応する記憶ロケーションを厳密に１つに制限することもまた問題になりうる。これがなければ、ヘビーユーザからの記憶されるべき大量のデータは所与のノードに負担をかけ、それは、また、選択されたロケーションアタックのために特定のリソースＩＤをターゲットにする動機を攻撃者に提供するであろう。
【０００５】
データの所有者が、特定のリソースＩＤを書込、変更、または削除することをどのノード／ユーザが許可されるかについて制御可能な方法を提供することは貴重であろう。これが無い場合、任意のノードが、潜在的に所与のリソースＩＤのコンテンツを上書きしうる。
【発明の概要】
【０００６】
ピア・ツー・ピアオーバーレイネットワーク上に記憶されたデータに対する記憶許可（storage authorization）およびアクセス制御に関する様々な特徴が本明細書において提供される。
【０００７】
１つの特徴によると、オーバーレイネットワーク上にデータを記憶するための方法が提供され、例えば、発行ノード（publishing node）、プロセッサ上で実施され、および／または、コンピュータ読み取り可能媒体に記憶される。リソース識別子は、第１の文字列および第２の文字列の組み合わせの関数として生成され、第１の文字列は記憶ノード（storage node）によって独立して認証可能であり、リソース識別子はその記憶ノードによって検証可能である。一例において、第１の文字列は発行ノード識別子であり、第２の文字列は任意の文字列である。別の例において、第１の文字列は発行ノード識別子であり、第２の文字列は、オーバーレイネットワーク内のサービスについての既定の文字列である。リソース識別子、記憶されるべきデータ、第１の文字列のインジケータ、および／または第２の文字列のインジケータを含む記憶要求（storage request）が生成される。記憶要求は、次に、リソース識別子を含む識別子スペースに対して責任を持つ記憶ノードで記憶されるように、オーバーレイネットワークを通して送信される。リソース識別子の構成のため、記憶要求に対する許可はプロトコル階層のオーバーレイレベルで検証可能であり、そのオーバーレイレベルはプロトコル階層において用途レベル（usage level）より下のレベルである。
【０００８】
複数の異なるリソース識別子は記述されるように生成され、複数の異なるリソース識別子の各々は第１の文字列および異なる第２の文字列の組み合わせの関数である。異なるリソース識別子が異なる第２の文字列を使用して生成されるため、これは、異なる記憶ノードが異なる識別子スペースに対して責任を負うオーバーレイネットワーク内でデータ記憶負荷拡散を引き起こす。
【０００９】
別の特徴によると、オーバーレイネットワーク上にデータを記憶するための方法が提供され、例えば、記憶ノード、プロセッサ上で実施され、および／またはコンピュータ読み取り可能媒体に記憶される。ピア・ツー・ピアオーバーレイネットワークにおいて、データを記憶するために第１の記憶要求が受信される。第１の記憶要求は、第１のリソース識別子および記憶されるべき第１のデータを含み、第１のリソース識別子は、認証されうる第１の文字列と、第２の文字列との組み合わせの関数である。
【００１０】
一例において、第１の文字列は発行ノード識別子であり、第２の文字列は任意の文字列である。別の例において、第１の文字列は発行ノード識別子であり、第２の文字列はオーバーレイネットワーク内のサービスについての既定の文字列である。独立した記憶許可が、第１のリソース識別子を検証することによって、プロトコル階層のオーバーレイレベルで実行される。第１のリソース識別子の検証に成功すると、第１のデータは記憶ノードによって記憶され、第１のリソース識別子と関連付けられる。一例において、独立した記憶許可をオーバーレイレベルで実行することは、（ａ）第１の文字列を認証すること、および／または（ｂ）第１のリソース識別子が第１の文字列と第２の文字列との組み合わせの関数であるか否かを決定することを含む。
【００１１】
記憶ノードは、続いて、記憶された第１のデータに対するデータアクセス要求を受信する。データアクセス要求が、第１のリソース識別子および第１の文字列についての知識を立証すると、記憶された第１のデータへのアクセスが認可（grant）される。データアクセス要求が、第１のリソース識別子についての知識は立証するが、第１の文字列についての知識は立証できなかった場合、記憶ノードは、記憶された第１のデータへの読み取り専用アクセスを認可する。記憶された第１のデータへのアクセスを認可することは、第１のデータを第２のデータで置き換えることを許すことを含む。
【００１２】
さらに別の特徴によると、ピア・ツー・ピアオーバーレイネットワーク上でデータを記憶するために発行ノード上で動作可能な別の方法が提供される。リソース識別子は第２の文字列の関数として生成され、リソース識別子は記憶ノードによって検証可能である。次に記憶要求が生成され、リソース識別子、記憶されるべきデータ、および、記憶ノードによって独立して認証可能な第１の文字列を含む。一例において、第１の文字列は発行ノード識別子であり、第２の文字列は任意の文字列である。別の例において、第１の文字列は発行ノード識別子であり、第２の文字列はオーバーレイネットワーク内のサービスについての既定の文字列である。
【００１３】
記憶要求は、リソース識別子を含む識別子スペースに対して責任を持つ記憶ノードで記憶されるために、オーバーレイネットワークを通して送信される。記憶要求に対する許可は、第１の文字列を使用して、プロトコル階層の用途レベルで検証可能であり、用途レベルはプロトコル階層においてオーバーレイレベルの上のレベルである。オーバーレイネットワーク内の異なる発行ノードは、同一のリソース識別子で異なる第１の文字列を有するデータ記憶要求を生成する。異なるデータ記憶要求は、異なる第１の文字列を使用する用途レベル許可に基づいて区別可能である。
【００１４】
さらに別の特徴によると、ピア・ツー・ピアオーバーレイネットワーク上でデータを記憶するために、記憶ノード上で動作可能な別の方法が提供される。第１の記憶要求は、ピア・ツー・ピアオーバーレイネットワークにおいてデータを記憶するために受信される。第１の記憶要求は、第１のリソース識別子、記憶されるべき第１のデータ、および第１の発行ノード識別子を含み、その記憶ノードは、第１のリソース識別子を含む識別子スペースに対して責任を持つ。ピア・ツー・ピアオーバーレイネットワークにおいてデータを記憶するために第２の記憶要求が受信される。第２の記憶要求は、第１のリソース識別子、記憶されるべき第２のデータ、および、第２の発行ノード識別子を含む。第１のデータおよび第１の発行ノード識別子は記憶ノードによって記憶され、第１のリソース識別子と関連付けられる。第２のデータおよび第２の発行ノード識別子は記憶ノードによって記憶され、第１のリソース識別子と関連付けられる。記憶ノードは独立した記憶許可をプロトコル階層の用途レベルで実行し、用途レベルはプロトコル階層においてオーバーレイレベルの上のレベルである。
【００１５】
続いて、記憶ノードは、第１のリソース識別子と関連付けられたデータに対してデータアクセス要求を受信する。記憶ノードは、記憶された第１のデータおよび第２のデータへの読み取り専用アクセスを認可する。しかし、データアクセス要求が第１の発行ノード識別子についての知識を立証すると、記憶ノードは記憶された第１のデータへの書込アクセスを認可する。同様に、データアクセス要求が第２の発行ノード識別子についての知識を立証すると、記憶ノードは記憶された第２のデータへの書込アクセスを認可する。
【００１６】
本態様の特徴、特性、および利点は、同一の参照符号が全体を通して同一のものを示す図面を参照すると、以下に示される発明の詳細な記述からより明らかとなる。
【図面の簡単な説明】
【００１７】
【図１】図１は、ＤＨＴが、ピア・ツー・ピアオーバーレイネットワークの動作を容易にするために、どのように動作するかを例示する図である。
【図２】図２は、集中型レジストラ（centralized registrar）（トラステッドオーソリティ）が、どのようにオーバーレイネットワーク内の複数のノードにノードＩＤを割り当てるために機能するかを例示するブロック図である。
【図３】図３は、ネットワーク内で実施されうるプロトコル階層の一例を示すブロック図である。
【図４】図４は、一例において、オーバーレイネットワークでのデータ記憶要求に用いられるメッセージヘッダアーキテクチャの例を示す図である。
【図５】図５は、分散データ記憶および許可がピア・ツー・ピアオーバーレイネットワークにおいてどのように実行されるかについての例を示すブロック図である。
【図６】図６は、分散データ記憶および許可がピア・ツー・ピアオーバーレイネットワークにおいてどのように実行されるかについての代替例を示すブロック図である。
【図７】図７は、２つの異なる発行ノードが、どのように、ピア・ツー・ピアオーバーレイネットワークにおいて同一のリソースＩＤを使用してデータを記憶しようとするかについての例を示すブロック図である。
【図８】図８は、発行ノードが、オーバーレイレベルのデータ記憶許可のために、オーバーレイネットワークにおいてリソースＩＤをどのように生成するかについての例を示すブロック図である。
【図９】図９は、記憶ノードが、オーバーレイレベルのデータ記憶許可のためにオーバーレイネットワークにおいてリソースＩＤをどのように検証するかについての例を示すブロック図である。
【図１０】図１０は、発行ノードが、用途レベルのデータ記憶許可のために、オーバーレイネットワークにおいてリソースＩＤをどのように生成するかについての代替例を示すブロック図である。
【図１１】図１１は、記憶ノードが、オーバーレイネットワークにおいて、用途レベルのデータ記憶許可のためにリソースＩＤをどのように検証するかについての例を示すブロック図である。
【図１２】図１２は、オーバーレイネットワークにおいてデータの記憶を要求することに適応している発行デバイスまたはノードの例を示す。
【図１３】図１３は、オーバーレイレベルで独立記憶許可を容易にするために、発行ノードにおいて動作可能な方法の例を示すフロー図である。
【図１４】図１４は、データ記憶許可を実行すると同時に、オーバーレイネットワークにおいてデータを記憶するための例示的な記憶ノードを示す。
【図１５Ａ】図１５Ａは、オーバーレイレベルで独立記憶許可を実行するために記憶ノードにおいて動作可能な方法の前半の例を示す。
【図１５Ｂ】図１５Ｂは、オーバーレイレベルで個々の記憶許可を実行するために記憶ノードにおいて動作可能な方法の後半の例を示す。
【図１６Ａ】図１６Ａは、用途レベルで独立記憶許可を実行するために記憶ノードにおいて動作可能な方法の前半の例を示す。
【図１６Ｂ】図１６Ｂは、用途レベルで独立記憶許可を実行するために記憶ノードにおいて動作可能な方法の後半の例を示す。
【発明の詳細な説明】
【００１８】
以下の記述において、複数の特定な詳細が実施形態の全体的な理解を提供するために示される。しかし、実施形態がこれらの特定な詳細なしに実施されうることは、当業者により理解されるであろう。例えば、回路は、不必要な詳細で実施形態を不明瞭にしないために、ブロック図で示される。別の例において、周知の回路、構造、および技術は、実施形態を不明瞭にしないために詳細に示される。
【００１９】
本明細書で使用されるように、「ノード」という用語は、ネットワーク内でアドレス指定可能な任意のデバイス、コンピュータ、処理ユニット等を指す。「識別情報（identification）」、「識別子（identifier）」、「ＩＤ」という用語は、ネットワーク内の特定のノードを識別することに役立つ値（例えば、数または文字列）を示すために、交換可能に使用される。「発行ノード」は、ネットワークにおいて別のノードに情報を記憶しようとするノードを指す。「記憶ノード」は、ネットワークにおいて発行ノードについての情報を記憶するノードを指す。「データ」（例えば、記憶されたデータ）という用語は、オーディオおよび／またはビデオコンテンツ、テキスト、画像など、任意のタイプの情報を含みうる。
【００２０】
概要
ピア・ツー・ピアオーバーレイネットワークにおいて、記憶されたデータまたは情報は、そのようなデータまたは情報がオーバーレイネットワークにおいて別のノードに潜在的にアクセスすることを可能にする特定の用途（例えば、オーバーレイサービス、機能、またはアプリケーション）と関連付けられる。オーバーレイネットワークにおいてデータを識別および記憶するために特定のリソース識別子（例えば、リソースＩＤ）が生成され、そのデータまたは情報と関連付けられる。ピア・ツー・ピアオーバーレイネットワークにおいて、データ記憶許可を容易にする様々な態様が提供される。
【００２１】
第１の実施形態によると、複数のノードを備えるピア・ツー・ピアオーバーレイネットワーク内において、発行ノードは、そのような記憶されたデータに対する許可制御を可能にしながら、データまたは情報を複数の異なる記憶ノードに記憶することが許可される。この実施形態において、データ記憶および／またはアクセスに対する許可制御は、プロトコル階層のオーバーレイレベルで実行され、オーバーレイレベルはプロトコル階層において用途レベルの下である。すなわち、データがオーバーレイネットワークの複数のノードロケーションをまたいで拡散されることを可能にする一方で、記憶ノードに記憶されたデータにアクセスし、それを変更し、および／またはそれを削除する許可が実施される。そのような許可を達成するための１つの方法は、第１の文字列および第２の文字列の組み合わせの関数として計算されるリソース識別子（リソースＩＤ）によって記憶されるべきデータを識別または関連付けることであり、第１の文字列は記憶ノードによって独立して認証可能であり、リソース識別子はその記憶ノードによって検証可能である。例えば、第１の文字列は発行ノード識別子であり、第２の文字列は用途タイプを示す任意または既定文字列である。一例において、発行ノード識別子（および／または発行ノードの公開キー）は、発行ノードによって記憶されているデータに署名するために使用されるプライベート証明書（private certificate）と関連付けられる。これにより、記憶ノードは、記憶されたデータの変更または修正を求める要求を提示するノードがそのようなプライベート証明書の知識を有するか否かを確かめることができる。特定の発行ノードが同一の第１の文字列および異なる第２の文字列（例えば、異なるタイプのデータまたは用途に対して）を使用するため、異なるリソースＩＤが生成され、その結果として、そのようなデータは、データ負荷の拡散を達成するために、おそらくピア・ツー・ピアネットワーク上の複数の異なる記憶ノードで記憶されるであろう。
【００２２】
記憶ノードは、特定のノードが、特定のリソースＩＤと関連付けられた記憶されたデータを修正または削除することができるか否かを決定する。すなわち、要求ノードが、発行ノードと関連付けられたリソース識別子、第１の文字列（例えば、発行ノード識別子）、および／またはプライベート証明書の知識を立証可能な場合にのみ、データアクセスおよび／または修正要求が許可される。そのような許可はプロトコル階層のオーバーレイレベルで実施され、そのオーバーレイレベルはプロトコル階層において用途レベルより下のレベルである。
【００２３】
代替の実施形態の特定の用途において、リソースＩＤを使用し、あるタイプのデータを探索することによって、ノードが記憶されたデータにアクセスできるようにすることが望まれる。しかし、そのような探索は、探索ノードが、記憶されたデータに関連付けられた第１の文字列（例えば、発行ノード識別子）を知らないため、リソースＩＤが第１の文字列（例えば、発行ノードに関連付けられた）および第２の文字列の両方に基づく場合に非実用的である。それゆえ、代替の実施形態においては、記憶されたデータについてのリソースＩＤは、第２の文字列にだけ基づく。そのような「第２の」文字列は、既定の文字列、既知の文字列、および／または知り得る文字列（例えば、各タイプの用途、アプリケーション、またはサービスにより）である。そのような文字列が各用途によって予め定義されるため、その用途と関連付けられたデータを探索する別のノードは、リソースＩＤを再生し（例えば、既知の文字列に基づいて）、オーバーレイネットワークにおいてリソースＩＤを探索する。このスキームによって、複数のノードがリソースＩＤのみを使用して特定のタイプのデータを探索することが可能になるだけでなく、複数の異なる発行ノードが同一のリソースＩＤを使用してデータを記憶することを可能にする。この実施形態において、データ記憶および／またはアクセスに対する許可制御は、プロトコル階層の用途レベルで実行され、その用途レベルはプロトコル階層においてオーバーレイレベルより下のレベルである。同一のリソースＩＤを使用する記憶されたデータの異なる複数のインスタンスを区別するために（例えば、それらが同一の文字列に基づくため）、記憶されたデータの各インスタンスは、また、用途レベルで検証される「第１の」文字列（例えば、発行ノードの識別子）と関連付けられる。記憶ノードは、また、記憶されたデータのインスタンスの変更または削除を要求するノードが、発行ノードＩＤと関連付けられた正しいプライベート証明書を有するか否かを確かめるために、その記憶されたデータのインスタンスと関連付けられた「第１の」文字列（例えば、発行ノードＩＤ）を使用する。
【００２４】
ＤＨＴオーバーレイネットワーク
オーバーレイネットワークは、別のネットワークの上に構築される通信ネットワークまたはデータネットワークである。オーバーレイ内のノードは、基盤ネットワークにおいて、おそらく多数の物理リンクを通るパスに各々が対応する仮想リンクまたは論理リンクによって結合されていると考えることができる。通信ネットワーク内で、各ネットワークノードは、ノードに、および／または、ノードからメッセージを送るために使用されるインターネットプロトコル（ＩＰ）アドレスを有する。そのようなネットワークＩＰ層の上で、各ノードに関するノード識別子（すなわち、ノードＩＤ）を使用するオーバーレイネットワークを実施することが可能である。したがって、ノードについてのＩＰアドレスが変更された場合であっても、そのノードＩＤはオーバーレイネットワークの場合に同じままである。かくして、オーバーレイネットワークは、ＩＰ層インフラストラクチャに頼らず、代わりに、複数のノード間のピア・ツー・ピア通信のためにノードＩＤを使用する。加えて、そのようなオーバーレイネットワークは、単一障害点がオーバーレイネットワークに不具合を生じさせないように、そのノードにわたって分散ハッシュテーブル（ＤＨＴ）を実施する。
【００２５】
一例において、Ｐ２ＰＳＩＰオーバーレイネットワークは、ＳＩＰ登録、ＳＩＰメッセージトランスポート、およびＰ２Ｐネットワークを使用する同様の機能を提供する複数のノードの結合、収束、および／または連合である。セッション開始プロトコル（ＳＩＰ）は、インターネットおよび別のネットワーク上で音声およびビデオ呼などのマルチメディア通信セッションを設定および解放するために広く使用されるシグナリングプロトコルである。ＳＩＰプロトコルは、ＳＩＰ要求の目的を解決し、ＳＩＰメッセージトランスポートを提供し、さらに、別のＳＩＰ関連機能を提供するためにピア・ツー・ピア（Ｐ２Ｐ）のネットワーク（すなわち、Ｐ２ＰＳＩＰ）に適応されている。
【００２６】
本明細書に記述される様々な態様は、集中型および／または分散型のピア・ツー・ピアオーバーレイネットワークアーキテクチャにおいて実施される。図１および２は、それぞれ、分散型および集中型のオーバーレイネットワークの例を示す。
【００２７】
図１は、ピア・ツー・ピアオーバーレイネットワークの動作を容易にするためにＤＨＴがどのように動作するかを示す図である。この例はオーバーレイネットワークを輪形で例示するが、これは単に簡潔さのためであり、別のオーバーレイネットワークアーキテクチャが可能であり、企図される。ピア・ツー・ピアオーバーレイネットワークＡ １００は、複数のノードＡ １０２、Ｂ １０４、Ｃ １０６、Ｄ １０８、Ｅ １１０、および／またはF １１２から形成されうる。各ノードは、オーバーレイネットワークＡ １００についてのＤＨＴの一部（例えば、ノード名、ノード識別子）を保持する。各ノードは、識別子スペースから選択される一意的なノード識別子（ノードＩＤ）をオーバーレイネットワーク１００のＤＨＴ １１４に有する。同様に、ネットワーク１００に記憶された各サービスまたはオブジェクトは、識別子スペースから選択された一意的な識別子を有する。全てのノードＩＤは、通常は衝突を避けるためにきわめて大きい、同じ識別子スペースの一部である。ノードＩＤの保持に対する責任（例えば、ノード名からノード識別子にマッピングすること）は、関与ノードのセットにおける変化が引き起こす妨害が最小量となるような方法で、ノード間で分散される。各ノードは、識別子スペースの一部、典型的に自己のノードＩＤから開始して１つ以上の隣接ノードのノードＩＤまで、に対して責任を持つ。ノードは、それが責任を持つ範囲内の任意のロケーションにマッピングするオブジェクトを記憶すること、および／または、オブジェクトに関するクエリに応答することに対して責任を持つ。各ノードは、別のノード（隣接ノードまたはルーティンググテーブル）への一連のリンクを保持する。同時に、これらのリンクはオーバーレイネットワークを形成する。ノードは、ネットワークのトポロジと呼ばれるある構造に従って隣接ノードを選び出す。
【００２８】
暗号ハッシュ関数(cryptographic hash function)が、識別子（ＩＤ）をオーバーレイネットワーク１００内のノード、オブジェクト、サービスのインスタンスに割り当てるために使用される。大抵のＤＨＴは、ハッシュキー（すなわち、識別子）をノードおよび／またはサービスにマッピングするために、コンシステント・ハッシュ法（consistent hashing）の変形を幾つか使用する。この技術は、ノード間の地理的距離またはネットワーク待ち時間とは無関係の、ｋ１からｋ２までの距離の抽象概念（abstract notion）を定義する関数δ（ｋ１、ｋ２）を用いる。各ノードは識別子（すなわち、ノードＩＤ）と呼ばれる単一のキーが割り当てられる。識別子値（ノードＩＤ）ｉを有するノードは、δに従って測定される、識別子ｉが最も近いＩＤである全てのキー（または、識別子）を所有する（または、それに対して責任を持つ）。ＤＨＴネットワークトポロジは、全てのキーkについて、ノードがｋを所有するか、あるいは、上で定義されたキースペース距離という観点において、ｋに近いノードへのリンクを有するプロパティのいくつかの変形を共有する。そのため、貪欲算法を使用して、メッセージを任意のキーｋ（すなわち、識別子）の所有者に送ることは比較的に単純である。例えば、各ノードにおいて、メッセージは、そのノードＩＤがキーｋに最も近い隣接ノードに送られる。そのような隣接ノードが存在しない場合（すなわち、他のどの隣接ノードもより近いノードＩＤを有さない場合）、メッセージが、上に定義されたように、キーｋの所有者である最も近いノードに到達したと仮定される。この方式のルーティンググは、時々、キーベースルーティングと呼ばれる。一例において、ＤＨＴは、キーを、円の上の点とみなし（図１に示されるように）、δ（ｋ１、ｋ２）は、円の周りを時計回りにｋ１からｋ２に移動する距離である。ゆえに、円形のキースペースは、そのエンドポイントがノード識別子（ノードＩＤ）である連続的な区分（segment）に分割される。ｉ１およびｉ２が隣接した２つのＩＤである場合、ＩＤ ｉ２を有するノードは、ｉ１からｉ２の範囲内にある全てのキーを所有する。このネットワークトポロジを実施することにおける効率性を考慮することにより、要求が迅速に完了するように任意の経路（経路長）における最大数のホップが少ないこと、および、管理オーバーヘッドが超過しないように、任意のノードの最大数の隣接ノード（最大ノード次数）が低いことを保証することが望ましい。１つのトレードオフは、より短い経路が各ノードに対して多数の隣接ノード（すなわち、より高い最大ノード次数）を要求することであることに注意されたい。
【００２９】
一例において、ノードＣ １０６は、１つ以上の先行ノード、および、１つ以上の後続ノードについてのノードＩＤを保有するＤＨＴ １１４を保持する。ＤＴＨ １１４は、単に、全てのノードＩＤのサブセット（すなわち、ノードＣ １０６のノードＩＤに近い複数のノードＩＤ）である。例えば、ノードＣ １０６のＤＨＴ １１４は、ノードＡ １０２およびノードＢ １０４のための前のノードＩＤ、並びに、ノードＤ １０８、Ｅ １１０、およびF １１２のための次のノードＩＤを保持する。ＤＨＴは、きわめて多数のノード（例えば、ネットワーク１００において２１６個のノード）まで拡大することができ、継続的なノードの到着、出発、および失敗を処理することができる。一例において、ＤＨＴは、ノードＩＤを円の上の点とみなし、δ（ノードＩＤ ｉ１、ノードＩＤ ｉ２）は、円の周りを時計回りに（例えば、ノードＣからいくつかのノードＩＤｘに）移動する距離である。このように、円状の識別子スペースは、そのエンドポイントがノード識別子（ノードＩＤ）である連続的な区分に分割される。ｉ１およびｉ２が隣接した２つのノードＩＤである場合、ＩＤ ｉ２を有するノードはｉ１からｉ２の範囲内にある全てのキーを所有する。結果として、ＤＨＴは、より複雑なサービス（例えば、分散ファイルシステム、ピア・ツー・ピアファイル共有とコンテンツ配信システム、協調ウェブキャッシング、マルチキャスト、エニーキャスト、ドメイン名サービス、およびインスタントメッセージング）を構築するために使用されうるインフラストラクチャを形成することができ、そのようなサービスの各々は円状の識別子スペース内の識別子と関連付けられる。特定のサービス識別子に最も近い値のノードＩＤを有するノードは、そのようなサービス（例えば、特定のファイルの記憶または「サービス」識別子によって識別されたサービスの提供など）を提供すると仮定される。例えば、ＤＨＴ １１４を参照すると、サービスが識別子値「７９」を有する場合、それがノードＣ １０６と関連付けられたノードＩＤ「７３」に最も近いため、そのようなサービスに対する任意の要求は、最後には、ノードＣ １０に着くであろう。
【００３０】
図２は、ノードＩＤをオーバーレイネットワーク内の複数のノードに割り当てるために、集中型レジストラ（トラステッドオーソリティ）がどのようにサービスするかを示すブロック図である。オーバーレイネットワーク１００について、集中型レジストラ２０２は、ＤＨＴ ２０４を形成するために複数のネットワークノード１０２、１０４、１０８、１１０、１１２、１１６、および／または１１８にノードＩＤを提供するように機能する。ネットワークノードがノードＩＤを獲得しようとする度に、それは集中型レジストラ２０２にノード識別子の割り当てを要求するメッセージを送信する。集中型レジストラ２０２は、次に、要求ノードに対するノードＩＤを計算し、それを要求ノードに割り当て、それを要求ノードに送信する。
【００３１】
いくつかの実施形態においては、集中型レジストラ２０２は任意のオーバーレイネットワーク動作に関与せず、それ自体では、別のノードによるノードＩＤ検証に到達することすらできない。そのような集中型レジストラ２０２の一例は、公開キーを要求ノードから受信し、ノードＩＤを割り当て、ノードへのノードＩＤのマッピングを行使する認証局（ＣＡ）を含む。例えば、ＣＡは、要求ノードの公開キーを使用して、ノードＩＤのマッピングに署名する。次に、要求ノードは、認可されたノードＩＤを別のノードに提示し、証明書に含まれる公開キーの所有権を立証する。ノードは、そのプライベートキーを用いて、ある送信コンテンツを署名することによって、この所有権を立証する。別のノードは、ノードの証明書によって認可された公開キーを使用して、結果として生じる署名済みコンテンツを検証する。オーバーレイネットワーク固有の集中型レジストラは、そのようなオーバーレイネットワークの採用を促進することに関心のある所与のオーバーレイネットワークまたはエンティティの作成者によって開発されるか、あるいは、それはネットワークオペレータによっても提供されうる。
【００３２】
集中型レジストラを使用する弱点の１つは、ピア・ツー・ピアオーバーレイネットワークの全ての潜在的なメンバー（例えば、ノード）にとって、集中型レジストラを所有および動作するたった一つのオーソリティを信用することが難しいという点である。いくつかの実施形態において、外部のオーソリティ（すなわち、集中型レジストラ）にノードＩＤの割り当てを完全に頼るオーバーレイネットワークノードよりはむしろ、その代わりとして、集中型レジストラ２０２はランダム入力をハッシュ関数に提供し、ノードはそれ自体が別のランダム入力をハッシュ関数に提供する。これら２つの入力の各々は、ノードＩＤがそれを主張するノードに属することを検証する際に検証器ノードによって使用されるであろう。
【００３３】
集中型レジストラは、単一のエンティティまたはノードが獲得することができるノードＩＤの数を制限する。例えば、オペレータ所有の集中型レジストラの場合、ノードＩＤは加入しているサービスと関連付けられる。
【００３４】
図３は、ネットワーク内で実施されるプロトコル階層の一例を示すブロック図である。この例において、オーバーレイネットワークは、トランスポート層３０６、ネットワーク層３０８、リンク層３１０、および／または物理層３１２を含むプロトコルスタック上に構築される。これらのベース層の上に、オーバーレイネットワーク層３０４が実装され、それは、Ｐ２Ｐおよび／またはＳＩＰプロトコルを含む。オーバーレイ層３０４の上に、それを通してサービスがサポートされる用途層（usage layer）３０２が構築される。用途層３０２は、また、アプリケーション層あるいはデータ層とも呼ばれる。「層」は「レベル」とも呼ばれる。別の考えられる実施形態は別の層または等価的な層を含みうること、および／または、いくつかの層を省略しうることに注意されたい。いくつかの点において、用途層３０２は、最上層、すなわち、他の層３０４〜３１２と比べて最も高い層であると考えられる。同様に、物理層３１２は、最下層、すなわち、他の層３０２〜３１０と比べて最も低い層であると考えられる。
【００３５】
ピア・ツー・ピア計算の性質は、オーバーレイが集合的により大きい機能を提供できるように、各ピアが別のピアにサービスを提供することである。Ｐ２ＰＳＩＰにおいて、ピアノードは、分散データベース機能および分散トランスポート機能が実施可能となるように、記憶およびトランスポートサービスを提供する。個々のピアもまた別のサービスを提供することが考えられる。別のサービス（例えば、ボイスメールサービス）は基礎のＰ２ＰＳＩＰ機能性への拡張であるが、オーバーレイネットワークが形成および動作することを可能にするために、これらの追加サービス（例えば、ＳＴＵＮサーバサービス）のうちのいくつかが要求される。オーバーレイネットワークのノードは、どのピアノードがどのサービスを提供するかについて、あるいは、各ピアノードがリストされたサービスの各々を配信するためにどの種類の容量を有するかについての情報を記憶する必要がある。
【００３６】
図１および図２に示されたノードは認証されたデータ記憶を実施することができる。例えば、発行ノードＡ １０２はリソースＩＤを生成し、それを記憶されるべきデータと関連付ける。例えば、リソースＩＤは、記憶ノードとして機能するノードＦ １１２にマッピングする。本明細書に記述された様々な特徴は、図１および図２のオーバーレイネットワーク、並びに、別のタイプのオーバーレイネットワークにおいて実施されうる。
【００３７】
分散Ｐ２Ｐネットワークにおけるデータ記憶および許可
ピア・ツー・ピア（Ｐ２Ｐ）オーバーレイネットワークの例はＰ２ＰＳＩＰ（セッション開始プロトコル）であり、それは、ＩＥＴＦ（インターネット技術特別調査委員会）によって標準化されている。本明細書に記述される様々なデータ記憶許可特徴は、Ｐ２ＰＳＩＰ対応のネットワークで実施されうる。Ｐ２ＰＳＩＰの一部として、用途がオーバーレインスタンシエイション上で定義されることを可能にするリソース割り当てが考慮される。用途は、それぞれの種類の対応データモデルを用いて様々な種類のデータを定義する。オーバーレイ内の特定のノードにデータを記憶するために、記憶されているデータのタイプまたは種類が識別され、認可されたユーザ名またはノードＩＤを使用して、リソースＩＤが計算される。ここで、関心のある証明書およびリソースＩＤ計算メカニズムは用途によって定義される。
【００３８】
これらの理由により、オーバーレイネットワーク内の全てのノードが、そのオーバーレイネットワーク上で提供されうる全ての用途をサポートする必要がある。さらに、用途がより新しいバージョンに進化すると、全てのノードが同じバージョンの全ての用途をサポートすることが必要となる。分散ネットワーク（例えば、集中型ノードオーソリティが利用可能でない場所）において、これは、全てのノードを更新するために「ｎ日」を要求する。しかし、更新日があることは厄介で、通常、実用的なネットワーク実施形態にとって非現実的である。
【００３９】
その結果として、記憶およびオーバーレイレベルのデータ許可を、用途非依存型（usage agnostic）（例えば、特定の用途、データタイプ等のから独立して）に保つ必要がある。そうすることによって、オーバーレイネットワークは異種の（heterogeneous）用途をサポートすることができ、加えて、時間にわたって進化するようにアップグレードすることができる。その結果として、オーバーレイ層で提供されるプロパティおよびプリミティブ機能は、用途層から独立して保持または保存される。一例において、「オーバーレイ層（またはオーバーレイレベル）」という用語は、プロトコル階層において、用途層より低く、トランスポート層より高い層での動作を示すために使用される。「アプリケーション層」および／または「用途層」という用語は、プロトコル階層の用途層での動作を示すために使用される。
【００４０】
図４は、オーバーレイネットワークにおいてデータ記憶要求のために、一例で用いられるメッセージヘッダアーキテクチャの例を示す図である。しかし、別タイプのメッセージヘッダが使用され得る。メッセージの主要部（図示されない）は、メッセージヘッダアーキテクチャに続く。アーキテクチャは、構造の多くが４の倍数のバイト長のため、４バイト行（four-byte-row）で示される。バイトは、横軸（horizontal axis）上の主なハッシュマークである。ビットは、水平アクセス（horizontal access）上のマイナーなハッシュマークである。各メッセージ（すなわち、行）に対する開始バイト（ゼロから数える）は垂直アクセス（vertical access）上に示される。最初の４バイト４０２（第０〜第３のバイト）は、メッセージのタイプまたは種類を識別するために使用される。
【００４１】
第４のバイト４１０は、破棄される前にメッセージが経験するこができる反復数（すなわち、ホップ）を示すＴＴＬ（time-to-live）フィールドである。ＴＴＬフィールドはホップの度に減少し、メッセージは、ＴＴＬがゼロの場合、それ以上のホップで送られるべきではない。
【００４２】
第５のバイト４１２はルーティングであり、続くべきルーティングのタイプを示す。ルーティングは、例えば、プロキシまたはリダイレクトである。ＦＲＡＧフィールド４１４は、メッセージがフラグメントであるか否かを示すために使用される第６のバイト４１８の１ビットのフィールドである。ＬＦＲＧフィールド４１６は、これが完全なメッセージの最後のフラグメントか否かを特定するために使用される第６のバイトの１ビットのフィールドである。１４ビット（第６のバイトの６ビット４１８と第７のバイトの全８ビット４２０）は、フラグメントオフセットおよび全体の長さを示すためにリザーブされる。
【００４３】
ＥＸＰフィールド４２２は、使用されているプロトコルが経験的であるか否かを特定する１ビットのフィールドである。バージョンフィールド４２４は、使用されているＰ２ＰＳＩＰプロトコルのバージョンを示す７ビットのフィールドである。ＤＨＴフィールド４２６は、使用されているＤＨＴアルゴリズムを特定する８ビットのフィールドである。コード（Chord）ＤＨＴアルゴリズムが使用されうる。別のＤＨＴアルゴリズムも可能である。
【００４４】
ハッシュフィールド４２８は、ＩＤを生成するために使用されるハッシュアルゴリズムを特定する８ビットのフィールドである。オーバーレイに使用される全てのＩＤは、同一のアルゴリズムを使用して計算されるべきであり、あるいは、計算されなければならない。例示的なアルゴリズムは１６０ビットのハッシュ値を生成するＳＨＡ−１アルゴリズムであるが、別のハッシュアルゴリズムも使用されうる。セキュリテ４３０は、オーバーレイ内の関係者によって使用されているセキュリティメカニズムを示す８ビットのフィールドである。
【００４５】
Ｒ／ｒ ビット４３２は、これが要求か応答かを特定するために使用される１ビットのフィールドである。方法フィールド４３４は、メッセージ方法を示す７ビットのフィールドである。少なくとも４つの方法タイプが存在する：ピア、リソース、トランスポート、およびＤＨＴ特性。方法タイプは、方法４３４の最初の２ビットによって特定される。残りの５ビットは特定の方法を特定するために使用される。例示的な方法は、「ピアジョイン（peer-join）」、「ピアサーチ（peer-search）」、「リソース獲得（resource-get）」、「リソースプット（resource-put）」、「リソーストランスファ（resource-transfer）」、「トランスポートオープン（transport-open）」、および「トランスポートトンネル（transport-tunnel）」である。「ピア」という用語がオーバーレイネットワークにおいてノードを指すことに注意されたい。
【００４６】
長さフィールド４３５は、ヘッダを含まないメッセージサイズのバイトの数である。宛先ＩＤフィールド４３６は、宛先ノードまたはリソースを一意的に識別する１６０ビットの識別子（例えば、ノードＩＤまたはリソースＩＤ）である。ソースＩＤフィールド４３８は、送信元を一意的に識別する１６０ビットの識別子（例えば、ノードＩＤまたはリソースＩＤ）である。
【００４７】
トランザクションＩＤフィールド４４０は、トランザクションを識別し、また、要求および応答をランダム化するためにソルト（salt）またはシード（seed）として機能する一意的な６４ビットの数である。応答は、それらが対応する要求として、同一のトランザクションＩＤを使用する。オーバーレイＩＤフィールド４４２は、使用されているオーバーレイの３２ビットのチェックサムまたはハッシュである。チェックサムは、オーバーレイ名を表す可変長の文字列を、３２ビット値に変換するために使用されなければならず、または使用されるべきである。３２ビットのオーバーレイフィールドは完全性のチェックを提供する。それはオーバーレイ名を表すデジタル署名を提供し、それによって、ノードは、それらが指示されたオーバーレイネットワークとインタラクトしていることを検証可能である。
【００４８】
非依存型オーバーレイ行動
非常に根本的なレベルでは、ＤＨＴは、いくつかのアプリケーションが存在しうる上にキーベースのルーティングを提供する。オーバーレイプロトコルは、しばしば、記憶および検索語義を提供し、ノードのためにピア・ツー・ピア接続性を可能にする。広範囲のアプリケーションによって使用されうる、きわめて基本のプリミティブが存在する。Ｐ２ＰＳＩＰワーキンググループの範囲内にあるＳＩＰベースのアプリケーションクラスに対しても、オーバーレイ内の様々なノード上に存在しうるいくつかのアプリケーションが存在する。オーバーレイ内の全てのノードが同一のアプリケーションをサポートする必要はない。さらに、所与のアプリケーションは、より新しいバージョンがオーバーレイ上で記憶および検索されるべき新しい種類のデータを潜在的に定義する場合に、時間にわたって進化しうる。
【００４９】
用途とは独立した記憶機能などのオーバーレイプリミティブは、それらが、その用途に対応するデータを記憶するために所与の用途をサポートすることに対して、オーバーレイネットワーク内の全てのノードを要求しない点で有益である。用途は、当然、それらの用途をサポートするノードによって解釈されうる用途レベルでのさらなるメカニズムを提供するが、これはオーバーレイプリミティブから独立している。
【００５０】
異種の用途、および、同じ用途であってもその潜在的な進化を想定すると、オーバーレイネットワークは、オーバーレイプリミティブ上での動作が用途によって定義されうる場合、全てのノードをアップグレードするために旗の日（すなわち、同期化期間）を必要とする。次に、オーバーレイは、互換性がない用途が様々なノード上に存在する場合、使用できない状態に戻されるか、あるいは、予測不可能な行動に帰着するであろう。よって、用途はある入力を提供するためにオーバーレイ層とインターフェースでつながることが許可されるべきであるが、記憶などのオーバーレイプリミティブ上での動作が定義され、オーバーレイ層内に包含されるべきである。
【００５１】
例−トップレベルのデータ許可スキーム
ピア・ツー・ピアオーバーレイネットワークにおけるデータ許可の第１の例によると、リソース識別子は、第１の文字列および第２の文字列の組み合わせに基づいて生成され、第１の文字列は記憶ノードによって独立して認証可能であり、リソース識別子はその記憶ノードによって検証可能である。例えば、第１の文字列は発行ノードＩＤまたはその等価物である。第２の文字列は任意の文字列または既定の文字列である。発行ノードは、リソース識別子および記憶されるべきデータを含む記憶要求を生成する。記憶要求は、記憶ノードで記憶されるために、オーバーレイネットワークを通して送信され、その記憶ノードはリソース識別子を含む識別子スペースに対して責任を持つ。記憶ノードは、リソース識別子を検証することによって、プロトコル階層のオーバーレイレベルでの独立記憶許可を実行する。
【００５２】
図５は、ピア・ツー・ピアオーバーレイネットワークにおいて分配型のデータ記憶および許可がどのように実行されるかについての例を示すブロック図である。発行ノードＡ ５０２は、オーバーレイネットワークにおいて、データ名により識別されるデータ（すなわち、データ値）を記憶しようとする。発行ノードＡ ５０２は、発行ノードＩＤおよび公開キーＰｋ−Ａ（対応するプライベートキーＰｒｖ-Ａと共に）を有する。証明書Ｃｅｒｔ-Ａが、発行ノードＡ ５０２によって認証エンティティ５０８から獲得される。ここで、証明書Ｃｅｒｔ-Ａはその公開キーＰｋ-Ａの関数である。
【００５３】
発行ノードＡ ５０２がオーバーレイネットワークにおいてデータの記憶を望む場合、それは、第１の文字列と第２の文字列との関数として関連リソースＩＤを生成する。一例において、第１の文字列は発行ノードＩＤである。第２の文字列は、既定の文字列（例えば、データ、用途、またはデータタイプを説明する）、または、任意の文字列である。第２の文字列が既定の文字列である場合、それは階層的な構造の一部であるか、あるいは、文字列コンポーネントの連結である。様々な例において、第１および／または第２の文字列の各々は英字、英数字、および／または数で示される一続きの記号である。発行ノードＡ ５０２は、また、Ｃｅｒｔ-Ａおよび記憶されるべきデータの関数として署名Ｓｉｇ-Ａを生成する（例えば、Ｃｅｒｔ-Ａでデータ値を署名することによって）。
【００５４】
次に、記憶要求５０４が生成され、発行ノードＡ ５０２によって送信される。記憶要求５０４は、リソースＩＤ、データ名、データ値、第１の文字列、第２の文字列、公開キーＰｋ-Ａ、および署名Ｓｉｇ-Ａを含む。
【００５５】
この例において、リソースＩＤは、ノードＢ ５０６が責任を有するリソーススペースにマッピングする。記憶要求５０４を受信すると、記憶ノードＢ ５０６は、要求ノードが事実上発行ノードＡ ５０２であることを認証する。一例において、この認証は、公開キーＰｋ-Ａを含む証明書要求５１０を認証エンティティ５０８に送信することによって達成される。それに応じて、記憶ノードＢ ５０６は、公開キーＰｋ-Ａの関数である検証証明書Ｖｅｒ. Ｃｅｒｔ-Ａを備えた証明書応答５１２を受信する。受信された署名Ｓｉｇ-Ａが、Ｖｅｒ. Ｃｅｒｔ-Ａを用いて署名された受信データ値のローカルに生成された署名と適合する場合、記憶ノードＢ ５０６は、記憶要求５０４の真正性（authenticity）の検証に成功する。そうではなく、受信された署名Ｓｉｇ−Ａがローカルに生成された署名と適合しない場合は、記憶要求５０４は拒否または無視される。
【００５６】
Ｓｉｇ−Ａの検証に成功すると、記憶ノードＢ ５０６は受信データを記憶する。この例において、リソースＩＤフィールド５１６と、データ名、データ値、および第１の文字列を包含する第２のフィールド５１８とを含むデータ構造５１４が利用される。
【００５７】
図５に例示されたスキームが、ピア・ツー・ピアオーバーレイネットワークにおいてデータ記憶許可およびアクセスを実施するための様々な所望の特徴を提供することに注意されたい。
【００５８】
第１に、データ許可によって、記憶ノードＢ ５０６Ｂは、データの所有者（発行ノードＡ ５０２）が事実上その特定のリソースＩＤで記憶する権限を有することを検証することができる。一例において、記憶ノードＢ ５０６は、ローカルに生成されたリソースＩＤと、受信されたリソースＩＤを検証することによってこれを達成する。記憶ノードＢ ５０６が、第１の文字列（例えば、発行ノード識別子）および第２の文字列を知っているか、あるいは、それを獲得することができるため、受信されたリソースＩＤと比較するためにローカルリソースＩＤを再度計算することができる。発行ノードＡ ５０２によって使用される第２の文字列は記憶ノードＢ ５０６に知られている。例えば、第２の文字列は用途タイプ（記憶要求５０４において受信される）またはデータ名である。結果として、記憶ノードＢ ５０６は、ローカルバージョンのリソースＩＤを計算し、それを受信されたリソースＩＤと比較するために、記憶要求５０４において受信される第１の文字列および第２の文字列を使用することができる。これによって、オーバーレイネットワークは、データが所与のノードによって記憶されうる記憶ロケーションの数を制御することができ、それにより、オーバーレイにおいて利用可能な分散割り当てへの単一のノードのインパクトを制限する。
【００５９】
一般的センスでは、リソースＩＤ検証は、第１の文字列の認証可能な証明（例えば、発行ノード識別子の所有権の証明）を提供することに基づいており、第１の文字列と第２の文字列（例えば、用途タイプ）との周知の（または同意された）関数がストレージのＩＤスペースにマッピングすることを検証する。第１の文字列の認証可能な証明は、例えば、非対称のキー動作（例えば、公開／プライベートキーの対の使用）に基づく。検証リソース識別子を達成するいくつかの潜在的に独立した方法が存在する。第１の方法は、特定のタイプのサービス／用途（すなわち、第２の文字列）が許可されることを知るために、サービス発行記憶要求を受け入れる記憶ノードを予想することである。すなわち、サービス／用途は、オーバーレイネットワークの既定または周知のノードでありうる。第２の方法は、記憶ノードによって受け入れられるべき「第２の文字列」の全ての組み合わせを予想することである。第３の方法は、全てのノードによって認識されるオーソリティによって独立して署名された第２の文字列を有することである。
【００６０】
しかし、発行ノードＡ ５０２からオーバーレイネットワークの異なる記憶ノードの周りにデータを拡散する能力も、また望まれる。データ記憶を複数の記憶ノード間に拡散する能力がない場合、ヘビーな発行ノードからの全てのデータが所与の記憶ノードに負担をかける。リソースＩＤが第２の文字列に少なくとも一部基づく図５のスキームを利用することによって、発行ノードＡ ５０２からの異なるデータは、異なる第２の文字列を有し、それによって異なるリソースＩＤに帰着する。すなわち、第２の文字列は、異なるタイプのデータまたは用途に対して変化し、あるいは、任意の各時間である。結果として、異なる記憶ノードにマッピングし、異なる記憶ノード間にデータを拡散する異なるリソースＩＤが生成される。
【００６１】
第２に、データ許可によって、データの所有者は、どのノードがその特定のリソースＩＤに書き込み許可されるかを制御することができる。すなわち、記憶ノードＢ ５０６は、記憶要求５０４が、許可されたノードだけがそのような要求を作ることができることを検証することを認証する。例えば、図５において、発行ノードのみが、正しい署名Ｓｉｇ−Ａを生成できる正しい証明書Ｃｅｒｔ−Ａを有しているに違いない。記憶ノードＢ ５０６は、正しい署名が使用されたことを検証することができる（認証エンティティ５０８を使用することによって）。これがない場合、任意のノードは、潜在的に、所与のリソースＩＤのコンテンツを上書きする。
【００６２】
データ許可プロパティは用途に依存しない。すなわち、オーバーレイストレージに対するデータ許可は、用途にとらわれない方式で提供される。よって、オーバーレイネットワーク内の記憶ノードは、記憶されるべきデータが属する特定の用途／サービス／アプリケーションをサポートする必要はなく、別のノードからの記憶要求の許可を検証することができる。すなわち、記憶ノードが特定のタイプのサービスまたはアプリケーションをサポートするか否かに拘わらず、記憶されているあらゆるタイプのデータの許可検証を実施することが可能である。
【００６３】
図５に示されるように、データ許可は、許可されていないノードが、記憶ノードＢ ５０６に記憶されるリソースＩＤ内の特定のアイテム（例えば、データ値）のコンテンツを書込みまたは変更できないことを、データ所有者（例えば、発行ノードＡ ５０２）が確実にすることを可能にする。このデータ許可機能の確実性は、そのようなデータ許可機能を強いる記憶ノード（例えば、記憶ノードＢ ５０６）の協調に依存する。
【００６４】
許可された記憶要求は、オーバーレイネットワーク内の任意のノードによって独立して検証される。換言すると、リソースＩＤのコンテンツ（例えば、データ名、データ値）を検索するノードは、データの所有者（例えば、発行ノードＡ）がそのリソースＩＤで記憶する許可を受けたことを検証することができる。
【００６５】
図５に例示されるように、所与の発行ノード（例えば、ノードＡ ５０２）は、オーバーレイネットワークにおいて複数のノードロケーションで情報またはデータを記憶する。これは、ノードが、単一のノードに依存せずに、そのデータをオーバーレイネットワーク内の複数の記憶ノードにわたって拡散することを可能にし、それによって、異なる用途が記憶されている時に負荷分散を達成する。そのようなデータ記憶拡散を自然に提供するオーバーレイストレージプリミティブは、クエリおよび記憶自体を処理する際に内在的に有益である。
【００６６】
オーバーレイレベルでのデータ許可は、オーバーレイネットワークによって受け取られるオーバーレイレベル証明（例えば、認証エンティティ５０８によって提供される証明書Ｃｅｒｔ-Ａまたは自己署名証明書）に基づかなければならず、または、基づくことができる。用途固有証明書は、それらの用途をサポートしないノードによって受け取られることができず、よって、オーバーレイレベルのデータ許可に対して見込みのある候補ではない。
【００６７】
文字列およびオーセンチケータ名（authenticator name）の両方がリソースＩＤを生成するために使用されるトップレベルの許可スキームは、オーバーレイレベルでの記憶許可を容易にする。リソースＩＤを生成するために文字列（例えば、用途固有文字列）を利用することによって、特定のノードからの異なるデータが、記憶ノード間で分散または拡散されるようにし、それによって負荷分散機能を達成する。
【００６８】
例―より低レベルのデータ許可スキーム
オーバーレイネットワークは、サービスを提供するエンティティのノードＩＤ（またはユーザ名）ついての事前の知識なく、探索ノードに、サービス（例えば、用途、サービス、またはアプリケーションと関連付けられた記憶されたデータ）を調べる能力を提供する。例えば、ＴＵＲＮ（Traversal Using Relay ＮＡＴ）サービスを捜すノードは、対応するユーザ名またはノードＩＤを知っているとは現実的には予想されない。
【００６９】
リソースＩＤが、任意のタイプの用途、サービス、および／またはアプリケーションを識別するために利用されるように、リソースＩＤ計算が用途にとらわれない形式で実行される。いくつかの例において、用途は、用途固有入力をリソースＩＤ計算に提供することを許可される。すなわち、リソースＩＤは、用途（例えば、各特定のタイプの機能、サービス、および／またはアプリケーションの）によって提供される情報に（少なくとも一部）基づいて計算される。
【００７０】
これらの機能のいくつかを容易にするために、変更されたアプローチがリソースＩＤの生成に使用される。この変更されたアプローチにおいて、リソースＩＤは、「第２」の文字列にのみ基づき、「第１」の文字列（例えば、発行ノードＩＤ）に基づかない。しかし、データ許可は、依然として、記憶ノードデータ構造で、「第１」の文字列（例えば、発行ノードＩＤ）をリソースＩＤと関連付けることによって実行される。例えば、そのような許可は、オーバーレイレベルというよりはむしろプロトコル階層の用途レベルで実行される。
【００７１】
図６は、ピア・ツー・ピアオーバーレイネットワークにおいて分散型のデータ記憶およびデータ許可がどのように実行されるかについての代替例を示すブロック図である。発行ノードＡ ６０２は、オーバーレイネットワークにおいて、データ名により識別されうるデータ（例えば、データ値）を記憶しようとする。発行ノードＡ ６０２は、発行ノードＩＤおよび公開キーＰｋ-Ａ（対応するプライベートキーＰｒｖ-Ａと共に）を有する。証明書Ｃｅｒｔ-Ａが、発行ノードＡ ６０２によって認証エンティティ６０８から獲得される。ここで、証明書Ｃｅｒｔ-Ａはその公開キーＰｋ-Ａの関数である。
【００７２】
発行ノードＡ ６０２がオーバーレイネットワークにおいて、データの記憶を望む場合、それは、文字列の関数として関連リソースＩＤを生成する。「文字列」は、既定の文字列（例えば、データ、用途、またはデータタイプを示す）である。様々な例において、文字列は、英字、英数字、および／または数で示される一続きの記号である。文字列は、また、階層的な構造であり、または、文字列コンポーネントの連結でありうる。発行ノードＡ ５０２は、また、署名Ｓｉｇ−ＡをＣｅｒｔ-Ａと、記憶されるべきデータ（例えば、データ値をＣｅｒｔ-Ａで署名することによって）との関数として生成する。
【００７３】
次に、記憶要求６０４が生成され、発行ノードＡ ６０２によって送信される。記憶要求６０４は、リソースＩＤ、データ名、データ値、発行ノードＩＤ、公開キーＰｋ−Ａ、および署名Ｓｉｇ−Ａを含む。
【００７４】
この例において、リソースＩＤは、ノードＢ ６０６が責任をもつリソーススペースにマッピングする。記憶要求６０４を受信すると、記憶ノードＢ６０６は、それが事実上発行ノードＡ ６０２であるか否かを決定するために、要求ノードを認証する。これは、正しい証明書Ｃｅｒｔ-Ａが要求ノードに知られており、発行ノードＩＤと関連付けられていることを検証することによって達成される。証明書の検証に成功する（例えば、署名Ｓｉｇ-Ａを検証することによって）と、記憶ノードＢ ６０６は、受信されたデータを記憶する。この例において、リソースＩＤフィールド６１６、データ名およびデータ値を含む第２のフィールド６１８、並びに、発行ノードＩＤ含む第３のフィールド６２０を含むデータ構造６１４が利用される。
【００７５】
図６のこの例においては、リソースＩＤを生成するために「文字列」のみが使用されている。使用される「文字列」は、オーバーレイネットワーク上でデータタイプまたは用途と関連付けられる。結果として、オーバーレイネットワーク内の任意のノードは、リソースＩＤを生成することによって（例えば、所望の文字列を使用することで）、および、オーバーレイネットワーク内の同一のリソースＩＤを有する記憶されたインスタンスを探索することによって、そのような用途のための記憶されたデータを探索し、および／または見つけることができる。
【００７６】
記憶ノードＢ ６０６が、リソースＩＤ６１６およびデータ６１８と切り離された、または、プライベートな発行ノードＩＤ ６２０を保持することに注意されたい。従って、記憶ノードＢ ６０６が、リソースＩＤ ６１６を要求する探索ノードにデータ６１８へのアクセスを提供する一方で、それらが、関連付けられた発行ノードＩＤおよび／または認証された証明書Ｃｅｒｔ-Ａを知っていることを立証できない場合、それらのノードがデータ６１８を削除または変更することを防ぐ。
【００７７】
このより低いレベルの許可スキーム（認証器名AuthNameがリソースＩＤの一部ではなく、代わりとしてデータ部に追加される）は、複数のノードが同一のリソースＩＤを用いてデータを記憶することを可能にする利点を有する。次に、これは、オーバーレイネットワークにおいて探索ノードがこの記憶されたデータを見つけることを容易にし、それによって、様々なタイプのサービスを容易にする。加えて、リソースＩＤを生成するために用途固有文字列を利用することによって、これは、特定のノードからの異なるデータが記憶ノード間で分散または拡散されるようにし、それによって負荷分散機能を達成する。しかし、別のノードが特定の用途を容易に探索できるようにする柔軟性と引き換えに、データアクセス、記憶、および／または消去許可が、オーバーレイレベルというよりはむしろより低いレベル（例えば、データレベル）で実行される。
【００７８】
例−データ許可スキームを用いたリソースＩＤの共有
図６に示される例において、リソースＩＤが用途を表す既定の「文字列」に基づくため、異なるノードが異なるデータを記憶するために同一のリソースＩＤを生成することが可能である。リソースＩＤが特定のＩＤスペースにマッピングし、そのようなＩＤスペースがオーバーレイネットワークノード間で割り当てられるため、同一のノードは、同一のリソースＩＤの複数のインスタンスに対して記憶ノードとして動作しうる。
【００７９】
図７は、２つの異なる発行ノードが、ピア・ツー・ピアオーバーレイネットワークにおいて同一のリソースＩＤを使用して、どのようにデータを記憶しようとするかの例を示すブロック図である。図５および図６の例のように、第１の発行ノードＡ ７０２は、オーバーレイネットワークにおいて、データ（すなわち、データ名１およびデータ値１）を記憶しようする。発行ノードＡ ７０２は、発行ノードＩＤ １、公開キーＰｋ-Ａ（対応するプライベートキーPrv-Ａと共に）、および、証明書Ｃｅｒｔ−Ａ（公開キーＰｋ-Ａの関数であり、発行ノードＩＤ １と関連付けられる）を有する。発行ノードＡ ７０２がオーバーレイネットワークにおいてデータを記憶することを望む場合、それは関連リソースＩＤを文字列Ｘの関数として生成する。「文字列Ｘ」は既定の文字列（例えば、用途またはデータタイプを示す）である。様々な例において、文字列Ｘは、英字、英数字、および／または数で示される一続きの記号である。また、文字列Ｘは階層構造であり、あるいは、文字列コンポーネントの連結である。発行ノード Ａ ７０２は、また、署名Ｓｉｇ-ＡをＣｅｒｔ-Ａおよび記憶されるべきデータの関数（例えば、データ値１をＣｅｒｔ-Ａで署名することによって）として生成する。第１の記憶要求７０６が次に生成され、発行ノードＡ ７０２によって送信される。記憶要求７０６は、リソースＩＤ、データ名１、データ値１、発行ノードＩＤ１、公開キーＰｋ-Ａ、および署名Ｓｉｇ-Ａを含む。
【００８０】
同様の方法で、第２の発行ノードＣ ７０４は、発行ノードＩＤ ２、発行キーＰｋ-Ｃ（対応するプライベートキーＰｒｖ-Ｃと共に）、および証明書Ｃｅｒｔ-Ｃ（公開キーＰｋ-Ｃの関数であり、発行ノードＩＤ ２と関連づけられる）を有する。発行ノードＣ ７０４がオーバーレイネットワークにおいてデータを記憶することを望む場合、それは関連リソースＩＤを文字列Ｘの関数として生成する。第２の発行ノードＣ ７０４が第１の発行ノードＡ ７０２と同じ文字列Ｘを使用したため、それらのリソースＩＤが同じであることに注意されたい。発行ノードＣ ７０４は、また、Ｃｅｒｔ-Ｃと記憶されるべきデータとの関数（データ値１をＣｅｒｔ-Ｃで署名することによって）として署名Ｓｉｇ-Ｃを生成する。次に、第２の記憶要求７０８が発行ノードＡ ７０２によって生成および送信される。第２の記憶要求７０８は、リソースＩＤ、データ名２、データ値２、発行ノードＩＤ２、公開キーＰｋ-Ｃ、および署名Ｓｉｇ-Ｃを含む。
【００８１】
記憶ノードＢ ７１０は、記憶要求７０６および７０８の両方を受信し、発行ノード７０２および７０４を認証する。一度認証されると、記憶ノードＢ ７１０は、同一のリソースＩＤ７１４を有する異なるデータ７１６および７２０を記憶可能なデータ構造７１２に受信されたデータを記憶する。この例において、リソースＩＤ ７１４の各データインスタンス７１６および７２０は、そのデータインスタンスを所有するノードを示す関連発行ノード７１８および７２２を有する。そのため、記憶ノードＢ ７１０がデータインスタンス７１６および７２０へのアクセスを、リソースＩＤ ７１４を要求する探索ノードに提供する一方で、それらが、発行ノードＩＤ １ ７１８（データインスタンス７１６についての）および／または発行ノードＩＤ ２ ７２２（データインスタンス７２０についての）を知っている事を立証できない限り、ノードがデータ７１６および７２０を削除または変更することを防ぐ。
【００８２】
強化されたデータ許可
様々な実施形態において、リソースＩＤを生成するために使用される「文字列」は、特定の用途定義の文字列および／またはノード／ユーザ名、または識別子に基づく。一例において、リソースＩＤは、少なくとも部分的に、リソース名の関数のである。
【００８３】
図８は、オーバーレイレベルのデータ記憶許可のために、発行ノードがオーバーレイネットワークにおいてリソースＩＤをどのように生成しうるかについての例を示すブロック図である。一例において、データ許可は、リソース名を計算するために使用されている認可されたユーザ名またはノードＩＤに基づく。基本的に、リソースＩＤを生成するためのそのようなメカニズムの使用は、データの所有者（すなわち、発行ノード）がそのロケーションに記憶する許可を受けたことを、記憶ノードが検証することを可能にする。さらに、各用途は、また、データ許可のためにそれ自体のルールを定義することを可能にされる。これは、データ許可モデルを用途依存にさせ、同種の用途サポートとオーバーレイネットワークに対するアップグレード旗の日の使用の必要性に向かせる。
【００８４】
一実施形態において、データ許可は、オーバーレイレベルでの記憶許可の独立した動作を可能にする方法で達成される。第１に、発行ノードについての認可されたユーザ名またはノードＩＤなどの第１の文字列が定義される（８０２）。次に、第２の文字列（例えば、用途固有文字列（UsageString））が獲得される（８０４）。一例において、第２の文字列は、所与の用途によって提供され、またはユーザＩＤにデフォルトされる。
【００８５】
随意的に、２つの部分（第の文字列および第２の文字列）を含みるリソース名が次に獲得される（８０６）。一例において、２つの部分は区切り文字「:」によって分離され、あるいは、そうでない場合には組み合わされる。次にリソースＩＤが、リソースＩＤ＝ハッシュ（リソース名）＝ハッシュ（第１の文字列：第２の文字列）となるように、リソース名のハッシュとして生成される（８０８）。例として、リソースＩＤは、第１の文字列（例えば、発行ノード識別子）が「alice@example.dht.org」であり、第２の文字列が「sip」（例えば、用途タイプ）であるハッシュ（alice@example.dht.org:sip）である。発行ノードは、また、第１の文字列、第１の文字列および第２の文字列、または、第１の文字列および第２の文字列および別の値のデジタル署名Ｓｉｇ−Ｄを生成する（８１０）。
【００８６】
次に、発行ノードは、リソースＩＤ、記憶されるべきデータ、第１の文字列、およびデジタル署名Ｓｉｇ−Ｄを含む記憶要求を生成することができる（８１２）。別の情報もまた記憶要求の一部として含まれることに注意されたい。この記憶要求は、リソースＩＤに関するＩＤスペースに対して責任を持つオーバーレイネットワークにおいて、記憶ノードに送信され、または記憶ノードによって受信される。
【００８７】
図９は、オーバーレイレベルのデータ記憶許可について、記憶ノードがオーバーレイネットワークにおいてどのようにリソースＩＤを検証するかについての例を示すブロック図である。記憶ノードは、リソースＩＤ、データ、第１の文字列、および署名Ｓｉｇ−Ｄを含む記憶要求を受信する（９０２）。別の情報もまた記憶要求の一部として含まれうることに注意されたい。記憶要求９０２は図８に示されるように生成される。受信されたリソースＩＤが正確に生成されたことを検証するために、受信記憶ノードは、記憶されるべきデータと関連付けられた第１の文字列９０２（記憶要求において受信される）および第２の文字列（例えば、用途固有文字列）を獲得することによって（９０６）、リソースＩＤを検証することができる。次に、リソース名のローカルインスタンスが獲得された第１の文字列および第２の文字列を使用して生成される（９０８）。次に、リソースＩＤのローカルインスタンスがリソース名のハッシュから生成される（９１０）。受信されたリソースＩＤを検証するために（９１２）、リソースＩＤのローカルに計算されたインスタンスは、記憶要求において受信されたリソースＩＤと比較される（９１４）。それらが適合すると、記憶要求が受け入れられ、受信されたデータは記憶される（９１６）、さもなければ、記憶要求は否定される（９１８）。この形式のリソースＩＤ生成（ＡｕｔｈＮａｍｅおよびＵｓａｇｅＳｔｒｉｎｇの両方に依存する）を利用するデータアクセス許可は、データの記憶を認証するために必要とされる情報がリソースＩＤの一部として含まれることから、トップレベル許可と呼ばれることに注意されたい。
【００８８】
いくつかの例において、用途は、ユーザ名またはノードＩＤについての事前の知識なしに、そのデータに対するクエリまたは探索を許可することに関心をもつ。探索ノードが発行ノードの第１の文字列（例えば、ユーザ名および／またはノードＩＤ）を知らないため、リソースＩＤまたはリソース名の一部として第１の文字列を含まずにリソースＩＤを生成することが望まれる。
【００８９】
図１０は、用途レベルのデータ記憶許可のために発行ノードがオーバーレイネットワークにおいてどのようにリソースＩＤを生成するかについての代替例を示すブロック図である。この例において、データ許可はより低いレベルで提供される。すなわち、発行ノードがオーセンチケータ名AuthName １００２および用途固有文字列UsageString １００４を定義する一方で、リソース名１００６が、UsageStringの関数としてのみ生成される。次に、リソースＩＤ １００８がリソース名１００６の関数として生成される。この例においては、デジタル署名Ｓｉｇ-Ｄが、AuthNameおよび／またはUsageStringおよび／または別の値を署名することによって生成される。次に発行ノードは、リソースＩＤ、記憶されるべきデータ、オーセンチケータ名AuthName、およびデジタル署名Ｓｉｇ-Ｄを含む記憶要求１０１２を生成する。別の情報もまた記憶要求の一部として含まれうることに注意されたい。この記憶要求１０１２は、リソースＩＤに関するＩＤスペースに対して責任を持つオーバーレイネットワークにおいて記憶ノードに送信され、または記憶ノードによって受信される。
【００９０】
図１１は、用途レベルのデータ許可のために、記憶ノードがオーバーレイネットワークにおいてリソースＩＤをどのように検証するかについての例を示すブロック図である。記憶ノードは、リソースＩＤ、データ、オーセンチケータ名AuthNameおよび署名Ｓｉｇ-Ｄを含む記憶要求１１０２を受信する。別の情報もまた記憶要求の一部として含まれうることに注意されたい。記憶要求１１０２は、図１０に示されるように生成される。受信されたリソースＩＤが正確に生成されたことを検証するために、受信記憶ノードは、記憶されているデータの用途と関連づけられた用途固有文字列UsageString １１０４を獲得することによって、リソースＩＤを検証することができる。次に、リソース名のローカルインスタンス１１０６が用途文字列UsageStringを使用して生成される。次に、リソースＩＤのローカルインスタンス１１０８がリソース名のハッシュから生成される。受信されたリソースＩＤを検証する(１１１０)ために、リソースＩＤのローカルに計算されたインスタンスは、記憶要求において受信されたリソースＩＤと比較される（１１１４）。それらが適合しない場合、記憶要求は拒まれる（１１１８）。
【００９１】
記憶要求が現在記憶されており、同一のリソースＩＤと関連づけられているデータを上書き、削除、または変更しようと試みる場合、記憶ノードは、認証器の名前AuthNameをさらに検証する(１１１２)。すなわち、記憶ノードは、受信された記憶要求がそのようなデータを置き換える権限をもつパーティ（例えば、AuthNameまたは関連する認可された証明書を知るパーティ）からのものであることを検証する。現在の記憶要求が、同じリソースＩＤで前に記憶されたデータと同じ発行ノードからのものであると決定されると、新しく受信されたデータは、それが前に記憶されたデータを置き換え、またはそれを追加するように記憶される（１１１６）。さもなければ、現在の記憶要求が、同じリソースＩＤで前に記憶されたデータとは異なる発行ノードからのものであると決定されると、記憶要求は受け入れられるが、前に記憶されたデータを置き換え、変更、または削除することはできないであろう。その代わりに、新しいデータは、同一のリソースＩＤではあるが、記憶要求と関連付けられた異なるAurthNameで（図７に示されるように、データ構造７１２）記憶される（１１２０）この形式のリソースＩＤ生成（UsageStringに頼る）を使用するデータアクセス許可は、データの記憶を許可するために必要な情報がリソースＩＤの一部として含まれないため、低レベル（例えば、用途レベル、データレベル、または値レベル）許可と呼ばれることに注意されたい。
【００９２】
この低いレベル（または値レベル）のデータ許可を用いて、ユーザ名またはノードＩＤを知ることなく、オーバーレイネットワークにおけるデータ探索が実行され、それによって、データ発見を容易にする。この２重レベル許可（すなわち、より高いレベルでの用途ベースのリソースＩＤの許可、および、より低いレベルでの認証器名の許可）をサポートするために、プロトコル（例えば、記憶要求またはデータアクセス要求）は、使用される適切な許可タイプを信号送信することができる。
【００９３】
オーバーレイネットワークにおける記憶意味論(Storage Semantics)における改善
記憶および消去要求の処理
いくつかのオーバーレイネットワークサービスは、種類ＩＤ（これは要求の一部である）が記憶ノードに知られていること、および、対応するデータモデルが正確であることを、記憶／消去要求を受信する記憶ノードが検証することを要求する。これは、記憶ノードが、記憶要求のデータに関連付けられた全く同じ用途をサポートすることを仮定し、それが真である必要はない。本明細書に記述されたデータ記憶許可技術（記憶ノードが特定の用途をサポートする必要がない）に適応するために、記憶ノードは記憶要求内の種類 ＩＤチェックを無視しうる。記憶ノードは、ローカルポリシーに基づき、それがサポートする用途に対応するデータへの優先を提供する。しかし、そのようなローカル決定はオーバーレイプロトコル自体の範囲外である。
【００９４】
関連データの記憶および検索
本明細書に記述されるリソースＩＤ計算を使用して、所与の用途および所与のユーザ／ノードに対応するデータは特定のリソースＩＤ関連付けられ、そのようなリソースＩＤに対して責任を持つ記憶ノードで記憶される。用途は、リソース名の用途固有データに異なる語義を提供することによって、データ記憶を複数の記憶ノード間に拡散する。例えば、「sip:alice@example.dht.org」をリソース名として使用する代わりに、発行ノードは「sipaor:alice@example.dht.org」等をリソース名として利用する。この例において、用途固有語義「sip」が「sipaor」に変更される。いくつかのオーバーレイネットワークは、ユーザ名および／またはノードＩＤのハッシュに対応するリソースＩＤでユーザ名またはノードＩＤに対応する証明書を記憶することを可能にする。それ自体は有益であるが、それは、また、証明書がＳＩＰ ＡＯＲ（Address of Record）と同一の場所で記憶可能な場合に有益である。これが達成されうる２つの方法が存在する。ＳＩＰ用途が、同様にリソースＩＤで記憶される証明書の種類を特定する。あるいは、それは、リソースＩＤのターゲットストレージおよびそのリソースＩＤを所有しないノードでの対応する値として設計されうる。これは、複数の用途に対応するデータを同一のリソースＩＤで記憶しているノードが、（許可を有さないことを選択するため、あるいは、そのノード識別子またはオーセンチケータ名の単なるハッシュとしてそのリソースＩＤを計算したため）、複数の用途がそれを利用する場合でさえ、証明書の１つのインスタンスのみを記憶することを可能にするであろう。しかし、この時点で、それらのオブジェクトが比較的やすやすと同一のリソースＩＤで記憶されうるように、全ての要求される関連データの種類を定義するために各用途を予想することが妥当と思われる。
【００９５】
記憶要求を生成および送信することに適応した発行ノードの例
図１２は、オーバーレイネットワークにおいてデータの記憶を要求することに適応した発行デバイスまたはノード１２００の例を示す。発行ノード１２００は、例えば、図１のオーバーレイネットワークのノード１０４である。発行ノード１２００は、記憶デバイス１２５０に結合された記憶許可プロセッサ１２３０、および、ネットワーク通信インターフェース１２２０を含む。一例において、発行ノード１２００は、オーバーレイレベルでの独立した許可を可能するデータ記憶要求を生成する。別の例において、発行ノード１２００は、用途レベルでの独立した許可を可能にするデータ記憶要求を生成する。発行ノード１２００は、オーバーレイネットワーク上でデータ記憶デバイス１２５０からデータを記憶することを望む。データ記憶に対する要求は、記憶許可プロセッサ１２３０によって生成され、ネットワーク通信インターフェース１２２０を介し、オーバーレイネットワークを通して送信される。記憶許可プロセッサ１２３０は、リソースＩＤ生成器１２３４、署名生成器１２４０、オーセンチケータ名生成器１２４２、および許可タイプモジュール１２３２を含む。いくつかの実施形態において、記憶許可プロセッサ１２３０は、１つ以上のプロセッサ、処理回路、および／またはモジュールによって実施される。
【００９６】
許可タイプモジュール１２３２は、どのタイプの許可が特定の記憶要求（または、データアクセス要求）に対して適切であるかを決定し、その適切なタイプの許可に対しての手順を選択する。例えば、特定の用途はオーバーレイレベル許可（例えば、トップレベル許可）を要求し、別の用途は、用途レベルの許可（例えば、値レベルまたはデータレベル許可などの、より低いレベルの許可）を要求する。
【００９７】
オーバーレイレベルの許可が使用される場合、許可タイプモジュール１２３２は、リソースＩＤ生成器１２３４に、第１の文字列１２３８（例えば、発行ノードＩＤまたはオーセンチケータ名）および第２の文字列１２３６（例えば、用途文字列）に基づいてリソースＩＤを生成させる。生成されたリソースＩＤは、記憶要求で記憶されるべきデータを識別するために使用される。リソースＩＤは、また、オーバーレイネットワーク内のどの記憶ノードが記憶要求のデータを記憶するかを決定するように機能する。署名生成器１２４０は、第１／第２の文字列および／または記憶要求によって記憶されるべきデータを通して署名を生成するように機能する。生成された署名は記憶要求の一部として含まれうる。加えて、ノード認証モジュール１２５４は、発行ノード１２００を一意的に識別または認証する証明を生成するように機能する。いくつかの例において、ノード認証モジュール１２５４は、自己認証によって、あるいは、証明書エンティティを用いて外部の認証器プロセスを介して証明書を生成する。そのような証明書は記憶要求においてリソース識別子を確保し、続いて認証するように機能する。
【００９８】
用途レベル許可（例えば、データレベルまたは値レベル許可）が使用される場合、許可タイプモジュール１２３２は、リソースＩＤ生成器１２３４に、第１の文字列１２３８（例えば、発行ノード識別子またはオーセンチケータ名）は用いず、第２の文字列１２３６（例えば、用途文字列）にのみに基づいてリソースＩＤを生成させる。生成されたリソースＩＤは、記憶要求で記憶されるべきデータを識別するように使用される。このインスタンスにおいて、第１の文字列１２３８（例えば、発行ノード識別子、または許可名）はデータの一部として加えられる。
【００９９】
これらの例の両方において、許可インデックス（認可された発行ノードが記憶要求である許可していることを示す）は、記憶要求と共に、あるいは、それとは別々に記憶ノードに送信される。例えば、記憶要求において使用される証明書の公開キーまたは検証は記憶ノードによって獲得される。
【０１００】
図１３は、オーバーレイレベルでの独立した記憶許可を容易にするために発行ノードにおいて動作可能な方法の例を示すフロー図である。一例において、本明細書に記述されるステップは、図１２に示された１つ以上のモジュールまたはデバイスによって実行される。発行ノードは、発行ノード１３０２と関連付けられ認可された第１の文字列（例えば、ノード識別子またはオーセンチケータ名）を獲得する。発行ノードは、また、第２の文字列１３０４（例えば、任意の文字列、または、用途タイプあるいは記憶されるべきデータタイプと関連付けられた文字列）を獲得する。一例において、第２の文字列は、オーバーレイネットワーク内のサービスについて既定の文字列である。オーバーレイレベル許可が実施されると、リソース識別子は、第１の文字列および第２の文字列の関数として生成され（１３０６）、ここで、第１の文字列は記憶ノードによって独立して認証可能であり、リソース識別子はその記憶ノードによって検証可能である。記憶要求に対する許可は、プロトコル階層のオーバーレイレベルで検証可能であり、そのオーバーレイレベルはプロトコル階層において用途レベルより下のレベルである。あるいは、用途レベル許可が実施されると、リソース識別子は第２の文字列の関数として生成される（１３０８）。この場合、記憶ノードは、リソース識別子をオーバーレイレベルで検証するが、記憶要求に対する許可はプロトコル階層の用途レベルで検証可能である。ここで、用途レベルはプロトコル階層においてオーバーレイレベルより上のレベルである。すなわち、リソース識別子は第２の文字列だけの関数であり、複数の発行ノードは記憶されるべき異なるデータに対して同一のリソース識別子を生成する。その結果、記憶ノードは、リソース識別子が正しい第２の文字列に基づいて（オーバーレイレベルで）正確に生成されたことを検証するが、記憶されたデータと関連づけられた第１の文字列（それは発行ノードを識別子する）を使用して用途レベルで記憶許可を実行することができる（同一のリソース識別子を使用し、異なる発行ノードによって記憶されたデータを区別するために）。
【０１０１】
一例において、リソース識別子を生成するために使用される関数はハッシュ関数である。発行ノードは、また、発行ノード１３１０についての第１の文字列、第２の文字列、および／または、認証キー（例えば、証明書またはプライベートキー）を用いて署名された記憶されるべきデータに基づいて署名を生成する。一例において、認証キーは、プライベートキー、自己生成証明書、または、発行ノードを認証する第３者の証明書である。リソース識別子および記憶されるべきデータを含む記憶要求が、次に、生成される（１３１２）。記憶要求は、また、第１の文字列、第２の文字列、および／または署名を含む。記憶要求は、次に、オーバーレイネットワークを通して記憶ノードに送信され、その記憶ノードはリソース識別子を含む識別子スペースに対して責任を有する（１３１４）。
【０１０２】
加えて、発行ノードは、複数の異なるリソース識別子を生成し、その複数の異なるリソース識別子の各々は、第１の文字列および異なる第２の文字列（オーバーレイレベル許可の場合）の組み合わせ、または第２の文字列のみ（用途レベル許可の場合）の関数である。異なるリソース識別子を生成するために第２の文字列を使用することによって、データ記憶負荷拡散は、異なる記憶ノードが異なる識別子スペースに対して責任を持つオーバーレイネットワーク内で達成される。
【０１０３】
記憶要求を受信および許可することに適応した記憶ノードの例
図１４は、データ記憶許可を実行すると同時に、オーバーレイネットワークにおいてデータを記憶するための例示的な記憶ノードを示す。記憶ノード１４００は、オーバーレイレベルでのデータ記憶の独立許可を可能にする。記憶ノード１４００は、記憶許可プロセッサ１４３０、ネットワーク通信インターフェース１４２０、および記憶デバイス１４５０を含む。データ記憶に対する記憶要求は、オーバーレイネットワークにおいて、ネットワーク通信インターフェース１４２０を介して発行ノードから受信される。一例において、記憶要求は、リソースＩＤ、データ、オーセンチケータ名、および署名を含む。ネットワーク通信インターフェースは、記憶要求を送信する発行ノードが記憶ノード１４００でデータを記憶する許可を受けたか否かを決定するためにその要求をレビューする記憶許可プロセッサ１４３０に要求を伝達する。とりわけ、記憶許可プロセッサ１４３０は、許可タイプモジュール１４３２、リソースＩＤ検証器１４３４、署名検証器１４４０、およびオーセンチケータ名検証器１４４２を含む。
【０１０４】
許可タイプモジュール１４３２は、どのタイプの許可が特定の記憶要求に対して適切かを決定す。例えば、記憶要求は、記憶されているデータに利用されるべき許可のタイプを信号送信する。使用されうる少なくとも２つのタイプの許可が存在する：オーバーレイレベル許可およびデータまたは値レベル許可。
【０１０５】
オーバーレイレベル許可において、リソースＩＤは、第１の文字列（例えば、発行ノード識別子、オーセンチケータ名など）および第２の文字列（例えば、任意の文字列、既定の文字列など）と関連付けられ、あるいは、その関数である。その結果として、リソースＩＤ検証器１４３４は、その要求が許可されたか否かを決定するために、第１の文字列１４３８および／または第２の文字列１４３６（その両方が、記憶要求において受信されるか、そうでなければ、記憶ノード１４００に提供または指示される）を利用する。この場合、「許可」は、リソースＩＤが正確に生成されたこと、および、第１の文字列（例えば、発行ノード識別子またはオーセンチケータ名）が認証されたこと（例えば、記憶されたデータが一意的に発行ノードと関連付けられるように）をチェックすることを意味する。
【０１０６】
用途レベル許可（例えば、データまたは値レベル許可）において、リソースＩＤは、第２の文字列１４３６（それは、用途タイプまたは記憶されるべきデータタイプと関連付けられる）と関連付けられ、あるいは、それの関数である。結果として、リソースＩＤ検証器１４３４は、リソースＩＤが正確に生成されたか否かを決定するために第２の文字列１４３６を利用する。加えて、用途レベルでの記憶許可について、オーセンチケータ名検証器１４４２は、記憶要求についての第１の文字列（発行ノード識別子またはオーセンチケータ名）を検証する。第１の文字列が、前に記憶されたデータと同一のリソースＩＤを有する記憶要求が前に記憶されたデータを置換すべきか、それが別々に記憶されるべきかを決定するために利用されることに注意されたい。
【０１０７】
同様に、署名検証器１４４０は、記憶要求の署名を検証する。
【０１０８】
図１５（図１５Ａおよび１５Ｂを備える）は、オーバーレイレベルで、独立記憶許可を実行するために記憶ノードにおいて動作可能な方法の例を示す。記憶ノードは、ピア・ツー・ピアオーバーレイネットワークにおいてデータを記憶するために第１の記憶要求を受信し、その第１の記憶要求は第１のリソース識別子および記憶されるべき第１のデータ含み、第１のリソース識別子は、認証されうる第１の文字列と、第２の文字列の組み合わせの関数である（１５０２）。記憶要求は、例えば、リソース識別子、記憶されるべきデータ、第１の文字列（例えば、発行ノード識別子、オーセンチケータ名）、第２の文字列、および／または、第１／第２の文字列および／または記憶されているデータに対する署名を含む。使用されている許可タイプに依存して、リソース識別子は、第１の文字列および／または第２の文字列の関数である。一例において、第１の文字列は発行ノード識別子であり、第２の文字列は任意の文字列である。別の例において、第１の文字列は発行ノード識別子であり、オーバーレイネットワーク内のサービスについての第２の文字列は既定の文字列である。
【０１０９】
オーバーレイレベル許可において、リソース識別子は、第１の文字列および第２の文字列の関数として検証される（１５０６）。すなわち、記憶ノードは、受信されたリソース識別子を検証するためにローカルバージョンのリソース識別子を計算する。リソース識別子の検証に成功すると、第１のデータは記憶され、第１のリソース識別子と関連付けられる（１５０８）。そうでない場合、要求は拒まれる。一例において、独立記憶許可をオーバーレイレベルで実行することは、（a）第１の文字列を認証すること、および（ｂ）第１のリソース識別子が第１の文字列および第２の文字列の組み合わせの関数であるか否かを決定することを含む。
【０１１０】
記憶ノードは、続いて、記憶された第１のデータに対するデータアクセス要求を受信する（１５１０）。第１のデータへのアクセスレベルが次に決定される（１５１２）。データアクセス要求が、第１のリソース識別子および第１の文字列につていの知識を立証すると、記憶された第１のデータへのアクセスが認可される（１５１６）。そのようなアクセスは、第１のデータへの書込、変更、および／または、削除アクセスである。記憶された第１のデータへのアクセスを認可することは、第２のデータを用いた第１のデータの置き換えを許すことも含む。データアクセス要求が第１のリソース識別子についての知識を立証し、しかしながら第１の文字列につていの知識を立証できない場合、記憶された第１のデータへの読み取り専用アクセスが認可される（１５１４）。アクセス要求が、リソース識別子あるいは第１の文字列のいずれかの知識を立証できない場合、第１のデータへのアクセスは拒まれることに注意されたい。
【０１１１】
図１６（図１６Ａと１６Ｂからなる）は、用途レベルで独立記憶許可を実行するために記憶ノードにおいて動作可能な方法の例を示す。記憶ノードは、ピア・ツー・ピアオーバーレイネットワークにおいてデータを記憶するための第１の記憶要求を受信し、その第１の記憶要求は、第１のリソース識別子、記憶されるべき第１のデータ、第１の発行ノード識別子を含み、記憶ノードは第１のリソース識別子を含む識別子スペースに対して責任を持つ（１６０２）。第１のリソース識別子は、記憶されるべきデータのタイプと関連付けられた用途文字列の関数である。例えば、第１のリソース識別子は、オーバーレイネットワーク内のサービスにつていの既定の文字列の関数である。
【０１１２】
加えて、記憶ノードは、また、ピア・ツー・ピアオーバーレイネットワークにおいて、データを記憶するために第２の記憶要求を受信し、その第２の記憶要求は、第１のリソース識別子、記憶されるべき第２のデータ、および、第２の発行ノード識別子を含む（１６０４）。独立記憶許可は、プロトコル階層の用途レベルで実行され、用途レベルはプロトコル階層においてオーバーレイレベルよりも上のレベルである（１６０６）第１のデータおよび第１の発行ノード識別子が記憶され、第１のリソース識別子と関連付けられる（１６０８）。第２のデータおよび第２の発行ノード識別子も記憶され、第１のリソース識別子と関連付けられる（１６１０）。
【０１１３】
記憶ノードは、続いて、第１のリソース識別子と関連付けられたデータについてのデータアクセス要求を受信する（１６１２）。記憶されたデータへのアクセスレベルはデータアクセス要求に対して決定される（１６１４）。デフォルトで、記憶された第１のデータおよび第２のデータへの読み取り専用アクセスが認可される（１６１６）。しかし、データアクセス要求が第１の発行ノード識別子につていの知識を立証すると、記憶された第１のデータへの書き込みアクセスが認可される（１６１８）。同様に、データアクセス要求が第２の発行ノード識別子についての知識を立証すると、記憶された第２のデータへの書き込みアクセスが認可される（１６２０）。
【０１１４】
一般的に、本開示で記述された処理のほとんどが同様の方式で実施されうることは認識されるべきである。任意の回路または回路セクション、１つ以上のプロセッサを有する集積回路の一部として、単独で、または、組み合わせて実施されうる。１つ以上の回路は、集積回路、アドバンスＲＩＳＣマシン（ＡＲＭ）プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、汎用プロセッサ等で実施されうる。
【０１１５】
また、実施形態が、フローチャート、フロー図、概略図、またはブロック図として描写されるプロセスとして記述されうることに注意されたい。フローチャートは連続したプロセスとして動作を記述するが、大半の動作は、並行または同時に実行されることができる。加えて、動作の順序は再配列されうる。プロセスは、その動作が完了すると終了する。プロセスは、方法、機能、手順、サブルーティング、サブプログラム等に対応しうる。プロセスが機能に対応する場合、その終了は、機能が呼び出し機能または主機能に戻ることに対応する。
【０１１６】
本出願で使用されるように、「コンポーネント」、「モジュール」、「システム」、およびそのようなものは、ハードウェア、ファームウェア、ハードウェアとソフトウェアの組み合わせ、または実行中のソフトウェアのいずれかのコンピュータ関連エンティティを指すことを意図する。例えば、コンポーネントは、プロセッサで実行中のプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および／またはコンピュータであるが、それに限定されない。例として、計算デバイス上で実行中のアプリケーションと、その計算デバイスはコンポーネントでありうる。１つ以上のコンポーネントは、プロセスおよび／または実行スレッドに存在し、１つのコンポーネントは１つのコンピュータ上でローカル化され、および／または２つ以上のコンピュータ間で分散されうる。加えて、これらのコンポーネントは、それに記憶された様々なデータ構造を有する様々なコンピュータ読み取り可能媒体から実行することができる。コンポーネントは、例えば、１つ上のデータパケットを有する信号に従って、ローカルおよび／またはリモートプロセスによって通信しうる（例えば、ローカルシステム、分散システム内の別のコンポーネントと、および／またはインターネットのようなネットワークをまたいで信号を介して別のシステムとインタラクトする１つのコンポーネントからのデータ）。
【０１１７】
さらに、記憶媒体はデータを記憶するための１つ以上のデバイスを表し、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイスおよび／または、情報を記憶するための別の機械読み取り可能媒体を含む。「機械読み取り可能媒体」という用語は、ポータブルまたは固定記憶デバイス、光記憶デバイス、無線チャネル、および、命令および／またはデータを記憶、包含、または搬送することができる様々な別の媒体を含むがそれに限定されない。
【０１１８】
さらに、実施形態は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、それらの任意の組み合わせによって実施されうる。ソフトウェア、ファームウェア、ミドルウェア、またはマイクロコードに実施された場合、必要なタスクを実行するためのプログラムコードまたはコードセグメントは、記憶媒体または別のストレージのような機械読み取り可能媒体に記憶されうる。プロセッサはその必要なタスクを実行しうる。コードセグメントは、手順、機能、サブプログラム、プログラム、ルーティング、サブルーティング、モジュール、ソフトウェアパッケージ、クラス、または、命令、データ構造、あるいはプログラムステートメントの任意の組み合わせを表す。コードセグメントは、情報、データ、アーギュメント、パラメータ、またはメモリコンテンツを伝送および／または受信することによって、別のコードセグメントまたはハードウェア回路に結合されうる。情報、アーギュメント、パラメータ、データ等は、メモリ共有、メッセージパッシング、トークンパッシング、ネットワーク送信等を含む適切な手段のいずれかを介して伝達、伝送、または送信される。
【０１１９】
図に示されるコンポーネント、ステップ、および／または機能の１つ以上は、擬似ランダム数を生成する動作に影響を及ぼさずに、再配列され、および／または、１つのコンポーネント、ステップ、あるいは、機能に結合され、または、いくつかのコンポーネント、ステップまたは機能に組み込まれる。さらなるエレメント、コンポーネント、ステップ、および／または機能が、また、本発明の範囲を逸脱することなく追加される。図に示される装置、デバイス、および／またはコンポーネントは、図に記述される１つ以上の方法、特徴、またはステップを実行するように構成されうる。本明細書に記述された新しいアルゴリズムは、有効に、ソフトウェアで実施され、および／またはハードウェアに組み込まれる。
【０１２０】
当業者はさらに、本明細書に開示された実施形態と関連して記述されている様々な実例となる論理ブロック、モジュール、回路、アルゴリズムステップが電子ハードウェア、コンピュータソフトウェアまたは両方の組み合わせとして実施されることを認識するであろう。このハードウェアとソフトウェアの互換性を明確に示すために、様々な実例となるコンポーネント、ブロック、モジュール、回路、およびステップが、それらの機能性という観点から一般的に上に記述されている。ハードウェア、または、ソフトウェアとしてそのような機能性が実施されるか否かは、特定のアプリケーションとシステム全体に課された設計制約とに依存する。
【０１２１】
本明細書に記述された発明の様々な特徴は、本発明の範囲を逸脱することなく、異なるシステムで実施されることができる。例えば、本発明のいくつかの実施形態は、移動または固定通信デバイス（例えば、アクセス端末）および複数の移動または固定基地局（例えば、アクセスポイント）で実行されうる。
【０１２２】
前述の実施形態が単なる例であり、本発明を限定するとして解釈されないことに注意されたい。実施形態の記述は例示を目的とするものであり、特許請求の範囲の範囲を限定するものではない。このように、本教示は、別のタイプの装置に容易に適用されることができ、多くの代替、変更、および変形は当業者に明白であろう。
【図１】
0005215476.tif 000002
【図２】
0005215476.tif 000003
【図３】
0005215476.tif 000004
【図４】
0005215476.tif 000005
【図５】
0005215476.tif 000006
【図６】
0005215476.tif 000007
【図７】
0005215476.tif 000008
【図８】
0005215476.tif 000009
【図９】
0005215476.tif 000010
【図１０】
0005215476.tif 000011
【図１１】
0005215476.tif 000012
【図１２】
0005215476.tif 000013
【図１３】
0005215476.tif 000014
【図１４】
0005215476.tif 000015
【図１５Ａ】
0005215476.tif 000016
【図１５Ｂ】
0005215476.tif 000017
【図１６Ａ】
0005215476.tif 000018
【図１６Ｂ】
0005215476.tif 000019