JP5847191B2 - コンテンツ共有を行う中間ノード及びコンテンツリクエスト端末並びにそれらのコンテンツ共有方法 - Google Patents

Description

本発明は、コンテンツ指向ネットワーキング（ＣＯＮ）環境における端末と中間ノード、及びそれらの通信方法に関する。

ユーザは、特定の相手側装置との接続を所望するのではなく、相手側が有するコンテンツそのものを所望する。しかし、現在のインタネット構造のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）に基づくエンド・ツー・エンド（ｅｎｄ−ｔｏ−ｅｎｄ、終端間）接続技術を用いてコンテンツを共有するためには、ユーザ装置が相手側装置のアドレス、即ち、相手側装置のＩＰを把握しなければならない。そして、相手側装置のＩＰとユーザ装置のＩＰとの間に接続リンクが生成されなければならない。そして、ユーザ装置は、コンテンツ共有のために第３者サーバを活用しなければならない。従って、ＩＰベースのエンド・ツー・エンド接続技術は、コンテンツ自身に基づきコンテンツを共有するサービスのサポートが困難である。

これに対してコンテンツ指向ネットワーキング（Ｃｏｎｔｅｎｔ Ｏｒｉｅｎｔｅｄ Ｎｅｔｗｏｒｋｉｎｇ、ＣＯＮ）が活発に研究されているが、この研究はユーザの所望するコンテンツ自体の共有に重点を置く研究である。代表的な技術として、コンテンツ中心ネットワーク（Ｃｏｎｔｅｎｔ Ｃｅｎｔｒｉｃ Ｎｅｔｗｏｒｋ、ＣＣＮ）が挙げられる。

本発明の一実施形態に係る中間ノードのコンテンツ共有方法は、コンテンツ指向ネットワーキング（Ｃｏｎｔｅｎｔ Ｏｒｉｅｎｔｅｄ Ｎｅｔｗｏｒｋ、ＣＯＮ）に基づいた中間ノードの、複数のデータセグメントを含むコンテンツの共有方法において、コンテンツリクエスト端末からコンテンツ名を含む前記コンテンツに対する共有代行リクエストメッセージを受信するステップと、前記共有代行リクエストメッセージの受信に応答して、前記コンテンツに対応する前記複数のデータセグメント各々に対するデータセグメントリクエストメッセージを生成するステップと、前記データセグメントを所有している少なくとも１つの端末に前記データセグメントリクエストメッセージを送信するステップと、前記少なくとも１つの端末から前記データセグメントを受信するステップと、前記受信されたデータセグメントに基づいて前記コンテンツリクエスト端末に集合化されたデータ送信方式を用いて前記コンテンツを送信するステップと、前記コンテンツリクエスト端末に前記コンテンツの送信を失敗した場合、前記コンテンツリクエスト端末に前記コンテンツを受信できるようにするための準備をリクエストするメッセージを送信するステップとを含むことを特徴とする。

前記コンテンツに対する共有代行リクエストメッセージを受信するステップは、セッション開始プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、ＳＩＰ）を用いて前記コンテンツに対する前記共有代行リクエストメッセージを受信するステップを含んでもよい。
前記コンテンツに対する共有代行リクエストメッセージは、前記コンテンツリクエスト端末及び前記中間ノードの間のセキュリティのための公開キーベースの前記コンテンツリクエスト端末の識別情報を含んでもよい。
前記データセグメントリクエストメッセージ各々は、前記コンテンツ名及び該当するデータセグメントに対する識別情報を含んでもよい。
前記データセグメントリクエストメッセージを送信するステップは、前記中間ノードから前記データセグメントを所有している少なくとも１つの端末へのルーティング経路を決定するステップと、前記ルーティング経路に基づいて前記データセグメントを所有している少なくとも１つの端末に前記データセグメントリクエストメッセージを送信するステップと、を含んでもよい。
前記中間ノードがコンテンツリクエストに対するキャッシュで用いられるように前記受信されたデータセグメントを格納するステップをさらに含んでもよい。
前記コンテンツリクエスト端末に集合化されたデータ送信方式を用いて前記コンテンツを送信するステップは、前記データセグメントリクエストメッセージに対応する前記複数のデータセグメントの受信が完了した場合、前記コンテンツリクエスト端末に集合化されたデータ送信方式を用いて前記コンテンツを送信するステップであってもよい。
前記コンテンツリクエスト端末に集合化されたデータ送信方式を用いて前記コンテンツを送信するステップは、前記コンテンツリクエスト端末に前記コンテンツの受信をリクエストするステップと、前記コンテンツの受信リクエストに対する応答に基づいて前記コンテンツリクエスト端末に前記コンテンツを送信するステップと、を含んでもよい。
前記コンテンツリクエスト端末に集合化されたデータ送信方式を用いて前記コンテンツを送信するステップは、前記コンテンツリクエスト端末からコンテンツ送信リクエストを受信する場合、前記コンテンツリクエスト端末に前記コンテンツを送信するステップを含んでもよい。
前記コンテンツリクエスト端末に前記コンテンツを再送信するステップをさらに含んでもよい。

前記共有代行リクエストメッセージは、前記共有代行リクエストメッセージが有効な時間を示すライフタイム情報を含んでもよい。

本発明の一実施形態に係るコンテンツリクエスト端末のコンテンツ共有方法は、コンテンツ指向ネットワーキングに基づいたコンテンツリクエスト端末の、複数のデータセグメントを含むコンテンツの共有方法において、中間ノードがコンテンツ名に対応する前記複数のデータセグメント各々に対するデータセグメントリクエストメッセージを生成し、前記データセグメントリクエストメッセージを用いて前記コンテンツを取得するように前記中間ノードに前記コンテンツ名を含む前記コンテンツに対する共有代行リクエストメッセージを送信するステップと、前記中間ノードから集合化されたデータ送信方式を用いて前記データセグメントに基づく前記コンテンツの受信を失敗した場合、前記中間ノードから前記コンテンツを受信できるようにするための前記コンテンツリクエスト端末の状態の変更をリクエストするメッセージを受信するステップと、前記中間ノードから前記コンテンツを受信するステップとを含むことを特徴とする。

前記コンテンツに対する共有代行リクエストメッセージを送信するステップは、セッション開始プロトコルを用いて前記コンテンツに対する前記共有代行リクエストメッセージを送信するステップであり、前記コンテンツを受信するステップは、セッション開始プロトコルを用いて前記コンテンツを受信するステップであってもよい。
前記共有代行リクエストメッセージは、前記コンテンツリクエスト端末及び前記中間ノードの間の通信セキュリティのための公開キーベースの前記コンテンツリクエスト端末の識別情報を含んでもよい。
前記共有代行リクエストメッセージは、前記共有代行リクエストメッセージが有効な時間を示すライフタイム情報を含んでもよい。
前記コンテンツを受信するステップは、前記中間ノードから前記コンテンツの受信がリクエストされるステップと、前記中間ノードに前記コンテンツの受信リクエストに対して応答するステップと、前記応答に応じて前記中間ノードが送信する前記コンテンツを受信するステップとを含んでもよい。
前記コンテンツを受信するステップは、前記コンテンツの送信を前記中間ノードにリクエストするステップと、前記コンテンツの送信を前記中間ノードにリクエストすることによって前記中間ノードが送信する前記コンテンツを受信するステップとを含んでもよい。

本発明の一実施形態に係るコンテンツ共有を行う中間ノードは、コンテンツ指向ネットワーキングに基づいて、複数のデータセグメントを含むコンテンツの共有を行う中間ノードにおいて、コンテンツリクエスト端末からコンテンツ名を含む前記コンテンツに対する共有代行リクエストメッセージを受信する受信部と、前記共有代行リクエストメッセージの受信に応答して、前記コンテンツに対応する前記複数のデータセグメント各々に対するデータセグメントリクエストメッセージを生成する処理部と、前記データセグメントを所有している少なくとも１つの端末に前記データセグメントリクエストメッセージを送信する送信部と、を備え、前記受信部は、前記少なくとも１つの端末から前記データセグメントを受信し、前記送信部は、前記受信されたデータセグメントに基づいて前記コンテンツリクエスト端末に集合化されたデータ送信方式を用いて前記コンテンツを送信し、前記コンテンツリクエスト端末に前記コンテンツの送信を失敗した場合、前記コンテンツリクエスト端末に前記コンテンツを受信できるようにするための前記コンテンツリクエスト端末の状態の変更をリクエストするメッセージを送信することを特徴とする。

前記受信部は、セッション開始プロトコルを用いて前記コンテンツに対する前記共有代行リクエストメッセージを受信し、前記送信部は、セッション開始プロトコルを用いて前記コンテンツを送信してもよい。
前記データセグメントリクエストメッセージ各々は、前記コンテンツ名及び該当のデータセグメントに対する識別情報を含んでもよい。
前記処理部は、前記中間ノードから前記データセグメントを所有している少なくとも１つの端末へのルーティング経路を決定し、前記送信部は、前記ルーティング経路に基づいて前記データセグメントを所有している少なくとも１つの端末に前記データセグメントリクエストメッセージを送信してもよい。
前記送信部は、前記データセグメントリクエストメッセージに対応する前記複数のデータセグメントの受信が完了した場合、前記コンテンツリクエスト端末に集合化されたデータ送信方式を用いて前記コンテンツを送信してもよい。
前記送信部は、前記コンテンツリクエスト端末に前記コンテンツの受信をリクエストし、前記コンテンツの受信リクエストに対する応答に基づいて前記コンテンツリクエスト端末に前記コンテンツを送信してもよい。
前記共有代行リクエストメッセージは、前記共有代行リクエストメッセージが有効な時間を示すライフタイム情報を含んでもよい。

本発明の一実施形態に係るコンテンツリクエスト端末は、コンテンツ指向ネットワーキングに基づいてコンテンツ共有を行うコンテンツリクエスト端末は、コンテンツ指向ネットワーキングに基づいて、複数のデータセグメントを含むコンテンツの共有を行うコンテンツリクエスト端末において、コンテンツ名を含む前記コンテンツに対する共有代行リクエストメッセージを生成する共有代行リクエストメッセージ生成部と、中間ノードに前記コンテンツに対する前記共有代行リクエストメッセージを送信する送信部と、前記中間ノードからの前記データセグメントに基づく前記コンテンツの受信を失敗した場合、前記中間ノードから前記コンテンツを受信できるようにするための前記コンテンツリクエスト端末の状態の変更をリクエストするメッセージを受信し、前記中間ノードから前記コンテンツを受信する受信部と、前記中間ノードから受信したコンテンツを格納する格納部と、を備えることを特徴とする。

前記中間ノードは、前記コンテンツリクエスト端末に送信された前記データセグメントを集合化してもよい。
前記共有代行リクエストメッセージは、前記共有代行リクエストメッセージが有効な時間を示すライフタイム情報を含んでもよい。

その他の特徴及びの側面は次の詳細な説明、図面及び請求項によって明確になる。

一般的なＣＣＮにおける中間ノードの動作を示す図である。 一般的なＣＣＮでインタレスト及びデータが送信される方法を示すフローチャートである。 本発明の一実施形態に係るセッション開始プロトコルを用いたコンテンツ共有代行方法を示す動作フローチャートである。 本発明の一実施形態に係る共有代行リクエストメッセージを用いたコンテンツ共有代行方法を示す動作フローチャートである。 本発明の一実施形態に係るＣＣＮにおける中間ノードの動作を示す図である。 本発明の一実施形態に係るＣＣＮに基づいた中間ノードのコンテンツ共有方法を示す動作フローチャートである。 本発明の一実施形態に係るＣＣＮに基づいたコンテンツリクエスト端末のコンテンツ共有方法を示す動作フローチャートである。 本発明の一実施形態に係るＣＣＮに基づいてコンテンツ共有を行う中間ノードの機能ブロック図である。 本発明の一実施形態に係るＣＣＮに基づいてコンテンツ共有を行うコンテンツリクエスト端末の機能ブロック図である。

以下、本発明の実施形態について添付の図面を参照しながら詳細に説明する。
本発明の実施形態を説明する際に、関連する公知の機能又は構成に対する具体的な説明が本発明の要旨を却って曖昧にすると判断される場合にはその詳細な説明を省略する。そして、本明細書で用いられる用語（ｔｅｒｍｉｎｏｌｏｇｙ）は本発明の好適な実施形態を適切に表現するために用いられた用語として、これはユーザ、運用者の意図又は本発明が属する分野の慣例などによって変わり得る。従って、本用語に対する定義は本明細書の全般にわたった内容に基づいて下されなければならない。各図面に提示された同一の参照符号は同一の部材を示す。

コンテンツ指向ネットワーキング（ＣＯＮ）方式は、インタレスト（Ｉｎｔｅｒｅｓｔ）／データ（Ｄａｔａ）に係わる送信方式を活用する。
コンテンツ指向ネットワーキング方式では、端末（移動端末、ユーザ、又はユーザ装置、など）が所望するコンテンツ名に基づいたコンテンツに対するインタレスト（即ち、リクエスト）を送信すると、当該コンテンツを有する中間ノードが当該コンテンツ（即ち、データ）を端末に送信する、「コンテンツリクエスト→コンテンツ送信」方式を用いる。
ここで、中間ノードは他の端末であるか、若しくは、ハブ、ルータ（ｒｏｕｔｅｒ）、又はこれに類似の機能を行う装置の何れかである。

中間ノードは、コンテンツ名を識別子とするルーティング表（Ｒｏｕｔｉｎｇ＿Ｔａｂｌｅ）を検索してインタレスト内のコンテンツ名と一致するルーティング目録の存在可否を判断する。中間ノードが当該コンテンツを保有している場合、中間ノードは当該データパケットをインタレストパケットが経由した経路の逆経路を用いて送信する。コンテンツは、送信単位に適するようにデータセグメント単位で格納又は送信される。
各インタレストパケットはコンテンツの特定データセグメントの番号を含み得る。その場合、各インタレストはコンテンツの当該データセグメントに対応する。

コンテンツをリクエストする端末がバッテリで駆動される移動端末である場合、インタレストパケットをセグメント単位で生成すれば、通信オーバヘッドが増大してパケット交換が頻繁になることによりバッテリ消耗が多くなる。

端末は、ドメイン名（ｄｏｍａｉｎ ｎａｍｅ）及びコンテンツ名を含むインタレストパケットを中間ノードに送信する。そして、当該コンテンツを保有する中間ノードはデータパケットを送信する。即ち、端末及び中間ノードが交換するメッセージは、インタレストという制御パケットとコンテンツを含むデータパケットとに区分される。

図１は、一般的なＣＣＮにおける中間ノードの動作を示す図である。
図１を参照すると、一般的なＣＣＮの中間ノードはコンテンツキャッシュ（Ｃｏｎｔｅｎｔ Ｃａｃｈｅ）、ＦＩＢ（Ｆｏｒｗａｒｄｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ、転送情報ベース）、及びＰＩＴ（Ｐｅｎｄｉｎｇ Ｉｎｔｅｒｅｓｔ Ｔａｂｌｅ、保留インタレスト表）を含む。中間ノードは各インタレストパケットを受信すれば、中間ノードのローカルキャッシュ（即ち、コンテンツキャッシュ）に当該コンテンツが存在するか否かを判断する。ローカルキャッシュに当該コンテンツが存在する場合、中間ノードはインタレストパケットが受信されたインタフェースを介して当該コンテンツを送信する。インタフェースは例えば、端末又は他の中間ノードと接続される。

ローカルキャッシュに当該コンテンツが存在しない場合、中間ノードはＰＩＴに、１）インタレストパケットが受信されたインタフェースに関する情報、及び２）当該コンテンツに関する情報を格納する。そして、中間ノードはＦＩＢを用いて１）インタレストパケットを送信するインタフェースを決定し、２）インタレストパケットを次の中間ノードに送信する。このような動作は、当該コンテンツを保有する中間ノードにインタレストパケットが到着するまで各中間ノードで繰り返される。

データＡ（即ち、データセグメントＡ）がインタフェース２を介して中間ノードに進入すれば、中間ノードはＰＩＴにデータ名称Ａが存在するかを確認する。ＰＩＴにデータ名称Ａが存在すれば、中間ノードはコンテンツキャッシュにデータＡを格納して（１１０）、データ名称Ａに対するインタレストが入ってきたインタフェース（例えば、この場合インタフェース０とする）を介してデータＡを転送（フォワーディング）しながら、ＰＩＴからデータ名Ａを削除する（１２０）。ＰＩＴにデータ名称Ａが存在しない場合はインタフェース２に入ってきたデータＡを削除する。

ＣＣＮ技術がＩＰベースのインタネットに適用された場合、対応するネットワークは、オーバレイネットワーク（ｏｖｅｒｌａｙ ｎｅｔｗｏｒｋ）形態を有する。即ち、データは、ＣＣＮ機能を有するノード間のトンネルを介していて送信される。

コンテンツをリクエストする端末が移動端末である場合、インタレスト／データに基づいたＣＣＮの送信構造はコンテンツを構成するデータセグメント単位による頻繁な処理過程を引き起こし、端末の常時オン「ａｌｗａｙｓ−ｏｎ」によるエネルギー急欠乏を招く。
そこで、１）ドメイン内ノードの状態及びネットワーク接続状態などを管理して、２）ドメイン内又はドメイン間の円滑なコンテンツ交換を可能にする、機能ノードがドメイン構成を容易にするために必要である。

図２は、一般的なＣＣＮでインタレスト及びデータが送信される方法を示すフローチャートである。
図２を参照すると、コンテンツリクエスト端末は、コンテンツ交換のためにコンテンツを構成するデータセグメント別にインタレストパケット（インタレスト１乃至インタレストＮ）を生成して中間ノード１に送信する。ここで、インタレストパケットは基地局を介して例えば中間ノード１に送信される。

中間ノード１はインタレストパケットを再び中間ノード２に伝達し、中間ノード２はコンテンツ所有端末にインタレストパケットを送信する。そして、データパケット（即ち、データセグメント各々（データ１乃至データＮ））はコンテンツ所有端末から中間ノード２及び中間ノード１を経てコンテンツリクエスト端末に送信される。

ところが、このようなコンテンツ（データセグメント）の交換中に、コンテンツリクエスト端末の状態が変更される場合（例えば、バッテリ限界、スリープモード（ｓｌｅｅｐ ｍｏｄｅ）への変更、電源オフ、など）、コンテンツリクエスト端末が状態変更によって、先に送信されたインタレストに対応するデータパケットを受信できないにも拘わらず、当該データパケットは不要かつ持続的にコンテンツリクエスト端末に送信される。従って、不要なデータの送信及びその結果として、高価な無線ネットワークリソースの浪費が発生する場合がある。

一方、このようなネットワークリソースの浪費を防ぐためには、コンテンツリクエスト端末はコンテンツ受信を完了するまで状態変更を行ってはならない。しかし、このように状態変更を禁止すると、特にコンテンツリクエスト端末がバッテリ駆動の携帯端末の場合、その動作可能時間を大きく減少してしまう。

そこで本発明の実施形態は、コンテンツリクエスト端末の状態変更に備え、且つ、頻繁なデータ送信によるオーバヘッドの増加を抑制するために、コンテンツリクエスト端末のリクエストに応じて中間ノードがコンテンツ共有を代行する方法を提供する。中間ノードにコンテンツ共有の代行をリクエストする方法として、セッション開始プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、ＳＩＰ）を用いる方法と、拡張されたインタレストパケットを用いる方法（即ち、共有代行リクエストメッセージを用いる方法）がある。

図３は、本発明の一実施形態に係るＳＩＰ（セッション開始プロトコル）を用いたコンテンツ共有代行方法を示す動作フローチャートである。
まず、コンテンツリクエスト端末及び第１中間ノードの全てがＳＩＰを搭載していると仮定する。そして、ＳＩＰのコンテンツディスポジションエンティティ（ｃｏｎｔｅｎｔ ｄｉｓｐｏｓｉｔｉｏｎ ｅｎｔｉｔｙ）を含む「ＳＩＰ ＩＮＶＩＴＥ」（ＳＩＰインヴァイト）メッセージと、ＣＣＮ送信とがインターワーク（ｉｎｔｅｒｗｏｒｋ、相互作用）する。即ち、中間ノードは「ＳＩＰ ＩＮＶＩＴＥ」メッセージをアプリケーションプリミティブ（ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｉｍｉｔｉｖｅ）に認知することで中間ノードのＣＣＮデーモン（ｄａｅｍｏｎ）を駆動する。

「ＳＩＰ ＩＮＶＩＴＥ」メッセージは、「ｉｎｓｔａｎｔ」（即時）又は「ｓｔｏｒｅ＆ｆｏｒｗａｒｄ」（格納＆転送）の２種類の何れかのコンテンツディスポジションを有する。本発明の一実施形態で「ＳＩＰ ＩＮＶＩＴＥ」メッセージは「ｓｔｏｒｅ＆ｆｏｒｗａｒｄ」タイプを有し、中間ノードに共有代行をリクエストするコンテンツ名を含む。ただし、本発明の一実施形態に係る「ｓｔｏｒｅ＆ｆｏｒｗａｒｄ」タイプの意味は既存と異なり、これについては後述する。そして、コンテンツリクエスト端末は、共有代行をリクエストする「ＳＩＰ ＩＮＶＩＴＥ」メッセージを第１中間ノードに送信する（３１１）。

ここで、コンテンツリクエスト端末は、「ＳＩＰ ＩＮＶＩＴＥ」メッセージ内に例えば、メッセージ送信者を識別できるハッシュ値（ｈａｓｈｉｎｇ ｖａｌｕｅ）を含む。その場合、コンテンツリクエスト端末が依頼したコンテンツに対するサイン（ｓｉｇｎａｔｕｒｅ）又は暗号化（ｅｎｃｒｙｐｔｉｏｎ）などを含む処理を全て第１中間ノードが行うことによって、コンテンツリクエスト端末側でのコンテンツセキュリティ処理を最小化できる。従って、安定性が確保され、処理オーバヘッド及び遅延（ｌａｔｅｎｃｙ）を低減できる。

例えば、第１中間ノードは、コンテンツリクエスト端末にコンテンツを送信する前に身元を確認する過程を行う。例えば、第１中間ノードは、コンテンツをリクエストし、同時にコンテンツを中継（ｒｅｌａｙ）する。

第１中間ノードは、共有代行をリクエストする「ＳＩＰ ＩＮＶＩＴＥ」メッセージに対する応答（例えば、「２００ＯＫ」メッセージ）をコンテンツリクエスト端末に送信する（３２１）。

コンテンツは複数のデータセグメントを含むが、第１中間ノードは、共有代行がリクエストされたコンテンツに対応するデータセグメント各々に対するデータセグメントリクエストメッセージ（データセグメントリクエストメッセージ１乃至データセグメントリクエストメッセージｎ）を生成する（３２２）。

そして、データセグメントリクエストメッセージを第２中間ノードに送信する（３２３）。
すると、第２中間ノードは、データセグメントを所有しているコンテンツ所有端末にデータセグメントリクエストメッセージを伝達する（３３１）。
コンテンツ所有端末は、データセグメントリクエストメッセージの受信に応答して、データセグメント（データセグメント１乃至データセグメントｎ）を第２中間ノードに送信する（３４１）。

そして、第２中間ノードはデータセグメントを第１中間ノードに伝達する（３３２）。ここで、第１中間ノードは、受信したデータセグメントをすぐにコンテンツリクエスト端末に転送せず格納しておく。これは、データセグメントを個々に送信せず、データセグメントを集合化（集成、ａｇｇｒｅｇａｔｅ）した全体コンテンツを送信するためである。これに関する詳しい説明は後述する。

データセグメントを全て受信した第１中間ノードは、データセグメントが集合化（集成、ａｇｇｒｅｇａｔｅ）されたコンテンツをコンテンツリクエスト端末に送信する。
ところが、ステップ３１１以後にコンテンツリクエスト端末がアイドル（ｉｄｌｅ）モード又はスリープモードに変更されるなど、コンテンツリクエスト端末の状態変更が発生する場合がある（３１２）。この場合、第１中間ノードがコンテンツを送信してもコンテンツリクエスト端末はコンテンツを受信できない。

従って、第１中間ノードは、コンテンツリクエスト端末にコンテンツ受信をリクエストする「ＳＩＰ ＩＮＶＩＴＥ」メッセージを送信する（３２４）。そして、コンテンツリクエスト端末からの応答（３１３）に応じて、第１中間ノードは集合化された（ａｇｇｒｅｇａｔｅｄ）データ送信方式を用いてコンテンツリクエスト端末にコンテンツを送信する（３２４）。

集合化されたデータ送信方式を用いることは、データセグメントを個別に送信するのではなく、データセグメントを集めて１つのコンテンツとして送信することを意味する。即ち、コンテンツリクエスト端末と第１中間ノードとの間のインタレスト及びデータ交換が１回のみ行われるため、データセグメントを個別に送信する場合よりもコントロール・オーバヘッドを低減できる。

一方、コンテンツリクエスト端末が共有代行リクエストのための「ＳＩＰ ＩＮＶＩＴＥ」メッセージを送信して予め決定された時間が経過した場合、コンテンツリクエスト端末は、第１中間ノードからのコンテンツ受信をリクエストする「ＳＩＰ ＩＮＶＩＴＥ」メッセージの送信（３２４）を待たずに、第１中間ノードにコンテンツ送信をリクエストし（３１３）、これに応答して第１中間ノードがコンテンツリクエスト端末にコンテンツを送信する（３２５）。

また、コンテンツリクエスト端末の状態変更などでコンテンツ送信が失敗した場合、第１中間ノードは、コンテンツリクエスト端末にコンテンツを受信できるように状態変更をリクエストし、コンテンツを再送信する。

今まで説明した方法は、第２中間ノードが存在しない場合や第２中間ノードとコンテンツ所有端末との間に他の中間ノードが存在する場合にも適用されることは勿論である。

図４は、本発明の一実施形態に係る共有代行リクエストメッセージを用いたコンテンツ共有代行方法を示す動作フローチャートである。
図４を参照すると、コンテンツリクエスト端末は、共有代行リクエストメッセージを第１中間ノードに送信する（４１１）。共有代行リクエストメッセージは、コンテンツに含まれるデータセグメント各々に対するインタレストが統合された一種の拡張されたインタレストパケットである。

共有代行リクエストメッセージは、コンテンツリクエスト端末が希望するコンテンツ名を含む。そして、共有代行リクエストメッセージは、共有代行リクエストに対するライフタイム（ｌｉｆｅｔｉｍｅ）を含んでもよい。共有代行リクエストに対するライフタイムは、第１中間ノードでコンテンツ共有代行が有効に行われ得る時間を意味する。即ち、共有代行リクエストに対するライフタイムは、第１中間ノードで当該共有代行リクエストメッセージに対するＰＩＴのライフタイム欄（図１参照）にエントリして使用される。従って、ライフタイムが経過すれば、コンテンツリクエスト端末がコンテンツを受信できなくても、第１中間ノードは共有代行によって受信したコンテンツの格納代行を終了する。

共有代行リクエストメッセージを第１中間ノードが受信した後の過程中に図３に示す場合と類似部分についてはその説明を省略する。
第１中間ノードは、データセグメントごとのデータセグメントリクエストメッセージを生成し（４２１）、第２中間ノードに送信する（４２２）。第２中間ノードは、データセグメントリクエストメッセージをコンテンツ所有端末に伝達し（４３１）、コンテンツ所有端末はデータセグメントを第２中間ノードに送信する（４４１）。そして、第２中間ノードは、データセグメントを第１中間ノードに送信する（４３２）。

ここで、データセグメントを受信する第１中間ノードは、データセグメントをすぐにコンテンツリクエスト端末に転送せず格納しておく。これはデータセグメントを個別に送信せず、データセグメントが集合化された全体コンテンツを送信するためである。これに関する詳しい説明は後述する。

データセグメントを全て受信した第１中間ノードは、データセグメントが集合化された全体コンテンツをコンテンツリクエスト端末に送信する（４２３）。
ところが、ステップ４１１の後にコンテンツリクエスト端末がアイドルモード、又はスリープモードに変更されるなど、コンテンツリクエスト端末の状態変更が発生する場合がある（４１２）。この場合、第１中間ノードがコンテンツを送信してもコンテンツリクエスト端末はコンテンツを受信できない。

このように、コンテンツリクエスト端末の状態変更などによってコンテンツ送信が失敗した場合、第１中間ノードは、コンテンツリクエスト端末にコンテンツ受信のための準備をリクエストするメッセージを送信する（４２４）。コンテンツ受信のための準備とは、コンテンツリクエスト端末がコンテンツを受信できるようにアイドルモード又はスリープモードから動作モード（ａｃｔｉｖｅ ｍｏｄｅ）にコンテンツリクエスト端末の状態を変更することを意味する。
コンテンツ受信のための準備をリクエストするメッセージは、例えば、ＳＭＳ（ｓｈｏｒｔ ｍｅｓｓａｇｅ ｓｅｒｖｉｃｅ）メッセージである。即ち、第１中間ノードは、ＳＭＳメッセージを用いてコンテンツリクエスト端末又はコンテンツリクエスト端末のユーザに動作モードへの状態変更をリクエストする。その場合、コンテンツリクエスト端末は、第１中間ノードのコンテンツ受信のための準備をリクエストするメッセージに対する応答を第１中間ノードに送信する。

そして、第１中間ノードは、コンテンツリクエスト端末にコンテンツを再送信する（４２５）。
勿論、図３に示すように、第１中間ノードはコンテンツ送信前にコンテンツリクエスト端末にコンテンツの受信をリクエストしてもよく、コンテンツリクエスト端末が共有代行リクエストメッセージ送信の後に一定時間が経過した時に第１中間ノードにコンテンツの送信をリクエストしてもよい。

図５は、本発明の一実施形態に係るＣＣＮにおける中間ノードの動作を示す図である。
図５を参照して、図３及び図４で第１中間ノードがデータセグメントを受信する過程（ステップ３３２及びステップ４３２）について具体的に説明する。本発明の一実施形態に係る中間ノード（即ち、第１中間ノード）は、データＡ（即ち、データセグメントＡ）がインタフェース２を介して入ってくれば、ＰＩＴにデータ名称Ａが存在するかを確認する。

ＰＩＴにデータ名称Ａが存在すれば、中間ノードはコンテントキャッシュ（コンテンツキャッシュ）にデータＡを格納し（５１０）、ＰＩＴからデータ名称Ａを削除する（５２０）。ここで、図１と異なって、中間ノードはデータ名称Ａに対応するコンテンツに対するリクエストが入ってきたインタフェース０にデータＡを送信（即ち、転送）せずに待機する。即ち、中間ノードは、セグメント単位の送信ではなく、コンテンツ単位の送信のために、データ名称Ａに対応するコンテンツに含まれる全てのデータセグメントが受信されるまでデータＡを送信せずに待機する。そして、中間ノードは全てのデータセグメントが受信されれば、データセグメントが集成されたコンテンツをコンテンツリクエスト端末に送信する。ＰＩＴにデータ名称Ａが存在しない場合は、インタフェース２に入ってきたデータＡを削除する。

図６は、本発明の一実施形態に係るＣＣＮに基づいた中間ノードのコンテンツ共有方法を示す動作フローチャートである。
図６を参照すれば、まず、中間ノードはコンテンツリクエスト端末からコンテンツ名を含む、或るコンテンツに対する共有代行リクエストメッセージを受信する（６１０）。ここで、コンテンツは複数のデータセグメントを含む。そして、中間ノードは、例えばＳＩＰを用いて共有代行リクエストメッセージを受信する。

ここで、共有代行リクエストメッセージは例えば、コンテンツリクエスト端末及び中間ノード間の通信セキュリティのための公開キー（Ｐｕｂｌｉｃ Ｋｅｙ）ベースのコンテンツリクエスト端末の固有な識別情報を含む。その場合、共有代行リクエストメッセージは、コンテンツリクエスト端末の識別情報を含むことによってコンテンツリクエスト端末の存在を証明する。

中間ノードは共有代行リクエストメッセージの受信に応答して、コンテンツに対応する複数のデータセグメント各々に対するデータセグメントリクエストメッセージを生成する（６２０）。データセグメントリクエストメッセージ各々は例えば、コンテンツ名及び該当するデータセグメントに対する識別情報を含む。

中間ノードは、データセグメントを所有している少なくとも１つの端末にデータセグメントリクエストメッセージを送信する（６３０）。中間ノードは、中間ノードから前記データセグメントを所有している少なくとも１つの端末へのルーティング経路を決定し、決定されたルーティング経路に基づいてデータセグメントを所有している少なくとも１つの端末にデータセグメントリクエストメッセージを送信する。

中間ノードは、少なくとも１つの端末からデータセグメントを受信する（６４０）。そして、中間ノードは例えば、中間ノードがコンテンツリクエストに対するキャッシュ（ｃａｃｈｅ）として用いられるように、受信されたデータセグメントを中間ノードのメモリに格納する。

データセグメントリクエストメッセージに対応する前記複数のデータセグメントの受信が完了した場合、中間ノードは受信されたデータセグメントに基づいてコンテンツリクエスト端末に集合化されたデータ送信方式を用いてコンテンツを送信する（６５０）。

ここで例えば、中間ノードは、コンテンツリクエスト端末にコンテンツの受信をリクエストし、コンテンツリクエスト端末からの応答に基づいてコンテンツを送信する。
又は、中間ノードは、コンテンツリクエスト端末からコンテンツ送信リクエストを受信する場合、コンテンツリクエスト端末にコンテンツを送信する。

更に例えば、中間ノードは、コンテンツリクエスト端末に対するコンテンツの送信に失敗した場合、コンテンツリクエスト端末にコンテンツ受信のための準備をリクエストするメッセージを送信してコンテンツを再送信する。

図７は、本発明の一実施形態に係るＣＣＮに基づいたコンテンツリクエスト端末のコンテンツ共有方法を示す動作フローチャートである。
図７を参照すると、コンテンツリクエスト端末は、コンテンツに対する共有代行リクエストメッセージを生成する（７１０）。共有代行リクエストメッセージは、中間ノードがコンテンツに対応する複数のデータセグメント各々に対するデータセグメントリクエストメッセージを生成し、データセグメントリクエストメッセージを用いてコンテンツを取得するようにリクエストするメッセージである。共有代行リクエストメッセージは例えば、コンテンツリクエスト端末と中間ノードとの間のセキュリティのための公開キーベースのコンテンツリクエスト端末の識別情報と共有代行リクエストメッセージが有効な時間を示すライフタイム情報を含む。

そして、コンテンツリクエスト端末は中間ノードに、コンテンツ名を含む、コンテンツに対する共有代行リクエストメッセージを送信する（７２０）。
コンテンツリクエスト端末は、中間ノードから集合化されたデータ送信方式を用いてデータセグメントに基づくコンテンツを受信する（７３０）。

ここで例えば、コンテンツリクエスト端末は、中間ノードからコンテンツの受信がリクエストされ、中間ノードでコンテンツの受信リクエストに対して応答し、該応答を基づいて中間ノードが送信するコンテンツを受信する。

又は、コンテンツリクエスト端末は、コンテンツを送信することを前記中間ノードにリクエストし、中間ノードからコンテンツを受信する。
一方、コンテンツに対する共有代行リクエストメッセージの送信及びコンテンツの受信には例えば、セッション開始プロトコルが用いられる。

図８は、本発明の一実施形態に係るＣＣＮに基づいてコンテンツ共有を行う中間ノードの機能ブロック図である。
図８を参照すれば、本発明の一実施形態に係る中間ノードは、受信部８１０、処理部８２０、送信部８３０及びメモリ８４０を備える。

受信部８１０は、コンテンツリクエスト端末からコンテンツ名を含むコンテンツに対する共有代行リクエストメッセージを受信する。
処理部８２０は、共有代行リクエストメッセージの受信に応答して、コンテンツに対応する複数のデータセグメント各々に対するデータセグメントリクエストメッセージを生成する。

送信部８３０は、データセグメントを所有している少なくとも１つの端末にデータセグメントリクエストメッセージを送信する。
そして、受信部８１０は少なくとも１つの端末からデータセグメントを受信し、送信部８３０は、受信されたデータセグメントに基づいてコンテンツリクエスト端末に集合化されたデータ送信方式を用いてコンテンツを送信する。
メモリ８４０は、受信されたデータセグメントを格納する。

図９は、本発明の一実施形態に係るＣＣＮに基づいてコンテンツ共有を行うコンテンツリクエスト端末の機能ブロック図である。
図９を参照すると、本発明の一実施形態に係るコンテンツリクエスト端末は、共有代行リクエストメッセージ生成部９１０、送信部９２０、受信部９３０及びメモリ９４０を備える。

共有代行リクエストメッセージ生成部９１０は、コンテンツに対する共有代行リクエストメッセージを生成する。
送信部９２０は、中間ノードでコンテンツに対する共有代行リクエストメッセージを送信する。
受信部９３０は、中間ノードから集合化されたデータ送信方式を用いてデータセグメントに基づくコンテンツを受信する。
メモリ９４０は、中間ノードから受信されたコンテンツを格納する。

以上、本発明に係る中間ノード及びコンテンツリクエスト端末について説明した。本中間ノード及びコンテンツリクエスト端末には先の図１乃至図７に関連して多様な実施形態によって上述した内容がそのまま適用できるので、これ以上の詳細な説明は省略する。

本発明の実施形態に係る方法は例えば、多様なコンピュータ手段を介して様々な処理を実行できるプログラム命令の形態で実現され、コンピュータ読取可能な記録媒体に記録される。コンピュータ読取可能な媒体は、プログラム命令、データファイル、データ構造などのうち１つ又はその組合せを含む。媒体に記録されるプログラム命令は、本発明の目的のために特別に設計されて構成されたものであるか、又はコンピュータソフトウェア分野の技術を有する当業者にとって公知、且つ使用可能なものである。コンピュータ読取可能な記録媒体の例としては、ハードディスク、フロッピー（登録商標）ディスク及び磁気テープなどの磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤなどの光記録媒体、光ディスクなどの光磁気媒体、及びＲＯＭ、ＲＡＭ、フラッシュメモリなどのプログラム命令を保存して実行するように特別に構成されたハードウェア装置が含まれる。

上述したように、本発明を限定された実施形態と図面によって説明したが、本発明は上記の実施形態に限定されることなく、本発明が属する分野における通常の知識を有する者であれば、このような実施形態から多様な修正及び変形が可能であろう。

従って、本発明の範囲は、開示された実施形態に限定されるものではなく、特許請求の範囲だけではなく特許請求の範囲と均等なものなどによって定められるべきである。

８１０、９３０ 受信部
８２０ 処理部
８３０、９２０ 送信部
８４０、９４０ メモリ
９１０ 共有代行リクエストメッセージ生成部

Claims (27)

1. コンテンツ指向ネットワーキング（Ｃｏｎｔｅｎｔ Ｏｒｉｅｎｔｅｄ Ｎｅｔｗｏｒｋ、ＣＯＮ）に基づいた中間ノードの、複数のデータセグメントを含むコンテンツの共有方法において、
   コンテンツリクエスト端末からコンテンツ名を含む前記コンテンツに対する共有代行リクエストメッセージを受信するステップと、
   前記共有代行リクエストメッセージの受信に応答して、前記コンテンツに対応する前記複数のデータセグメント各々に対するデータセグメントリクエストメッセージを生成するステップと、
   前記データセグメントを所有している少なくとも１つの端末に前記データセグメントリクエストメッセージを送信するステップと、
   前記少なくとも１つの端末から前記データセグメントを受信するステップと、
   前記受信されたデータセグメントに基づいて前記コンテンツリクエスト端末に集合化されたデータ送信方式を用いて前記コンテンツを送信するステップと、
   前記コンテンツリクエスト端末に前記コンテンツの送信を失敗した場合、前記コンテンツリクエスト端末に前記コンテンツを受信できるようにするための準備をリクエストするメッセージを送信するステップとを含むことを特徴とする中間ノードのコンテンツ共有方法。
2. 前記コンテンツに対する共有代行リクエストメッセージを受信するステップは、セッション開始プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、ＳＩＰ）を用いて前記コンテンツに対する前記共有代行リクエストメッセージを受信するステップを含むことを特徴とする請求項１に記載の中間ノードのコンテンツ共有方法。
3. 前記コンテンツに対する共有代行リクエストメッセージは、前記コンテンツリクエスト端末及び前記中間ノードの間のセキュリティのための公開キーベースの前記コンテンツリクエスト端末の識別情報を含むことを特徴とする請求項１に記載の中間ノードのコンテンツ共有方法。
4. 前記データセグメントリクエストメッセージ各々は、前記コンテンツ名及び該当するデータセグメントに対する識別情報を含むことを特徴とする請求項１に記載の中間ノードのコンテンツ共有方法。
5. 前記データセグメントリクエストメッセージを送信するステップは、
   前記中間ノードから前記データセグメントを所有している少なくとも１つの端末へのルーティング経路を決定するステップと、
   前記ルーティング経路に基づいて前記データセグメントを所有している少なくとも１つの端末に前記データセグメントリクエストメッセージを送信するステップと、を含むことを特徴とする請求項１に記載の中間ノードのコンテンツ共有方法。
6. 前記中間ノードがコンテンツリクエストに対するキャッシュで用いられるように前記受信されたデータセグメントを格納するステップをさらに含むことを特徴とする請求項１に記載の中間ノードのコンテンツ共有方法。
7. 前記コンテンツリクエスト端末に集合化されたデータ送信方式を用いて前記コンテンツを送信するステップは、前記データセグメントリクエストメッセージに対応する前記複数のデータセグメントの受信が完了した場合、前記コンテンツリクエスト端末に集合化されたデータ送信方式を用いて前記コンテンツを送信するステップであることを特徴とする請求項１に記載の中間ノードのコンテンツ共有方法。
8. 前記コンテンツリクエスト端末に集合化されたデータ送信方式を用いて前記コンテンツを送信するステップは、
   前記コンテンツリクエスト端末に前記コンテンツの受信をリクエストするステップと、
   前記コンテンツの受信リクエストに対する応答に基づいて前記コンテンツリクエスト端末に前記コンテンツを送信するステップと、
   を含むことを特徴とする請求項１に記載の中間ノードのコンテンツ共有方法。
9. 前記コンテンツリクエスト端末に集合化されたデータ送信方式を用いて前記コンテンツを送信するステップは、前記コンテンツリクエスト端末からコンテンツ送信リクエストを受信する場合、前記コンテンツリクエスト端末に前記コンテンツを送信するステップを含むことを特徴とする請求項１に記載の中間ノードのコンテンツ共有方法。
10. 前記コンテンツリクエスト端末に前記コンテンツを再送信するステップをさらに含むことを特徴とする請求項１に記載の中間ノードのコンテンツ共有方法。
11. コンテンツ指向ネットワーキングに基づいたコンテンツリクエスト端末の、複数のデータセグメントを含むコンテンツの共有方法において、
    中間ノードがコンテンツ名に対応する前記複数のデータセグメント各々に対するデータセグメントリクエストメッセージを生成し、前記データセグメントリクエストメッセージを用いて前記コンテンツを取得するように前記中間ノードに前記コンテンツ名を含む前記コンテンツに対する共有代行リクエストメッセージを送信するステップと、
    前記中間ノードから集合化されたデータ送信方式を用いて前記データセグメントに基づく前記コンテンツの受信を失敗した場合、前記中間ノードから前記コンテンツを受信できるようにするための前記コンテンツリクエスト端末の状態の変更をリクエストするメッセージを受信するステップと、
    前記中間ノードから前記コンテンツを受信するステップとを含むことを特徴とするコンテンツリクエスト端末のコンテンツ共有方法。
12. 前記コンテンツに対する共有代行リクエストメッセージを送信するステップは、セッション開始プロトコルを用いて前記コンテンツに対する前記共有代行リクエストメッセージを送信するステップであり、
    前記コンテンツを受信するステップは、セッション開始プロトコルを用いて前記コンテンツを受信するステップであることを特徴とする請求項１１に記載のコンテンツリクエスト端末のコンテンツ共有方法。
13. 前記共有代行リクエストメッセージは、前記コンテンツリクエスト端末及び前記中間ノードの間の通信セキュリティのための公開キーベースの前記コンテンツリクエスト端末の識別情報を含むことを特徴とする請求項１１に記載のコンテンツリクエスト端末のコンテンツ共有方法。
14. 前記共有代行リクエストメッセージは、前記共有代行リクエストメッセージが有効な時間を示すライフタイム情報を含むことを特徴とする請求項１１に記載のコンテンツリクエスト端末のコンテンツ共有方法。
15. 前記コンテンツを受信するステップは、
    前記中間ノードから前記コンテンツの受信がリクエストされるステップと、
    前記中間ノードに前記コンテンツの受信リクエストに対して応答するステップと、
    前記応答に応じて前記中間ノードが送信する前記コンテンツを受信するステップと、
    を含むことを特徴とする請求項１１に記載のコンテンツリクエスト端末のコンテンツ共有方法。
16. 前記コンテンツを受信するステップは、
    前記コンテンツの送信を前記中間ノードにリクエストするステップと、
    前記コンテンツの送信を前記中間ノードにリクエストすることによって前記中間ノードが送信する前記コンテンツを受信するステップと、
    を含むことを特徴とする請求項１１に記載のコンテンツリクエスト端末のコンテンツ共有方法。
17. コンテンツ指向ネットワーキングに基づいて、複数のデータセグメントを含むコンテンツの共有を行う中間ノードにおいて、
    コンテンツリクエスト端末からコンテンツ名を含む前記コンテンツに対する共有代行リクエストメッセージを受信する受信部と、
    前記共有代行リクエストメッセージの受信に応答して、前記コンテンツに対応する前記複数のデータセグメント各々に対するデータセグメントリクエストメッセージを生成する処理部と、
    前記データセグメントを所有している少なくとも１つの端末に前記データセグメントリクエストメッセージを送信する送信部と、
    を備え、
    前記受信部は、前記少なくとも１つの端末から前記データセグメントを受信し、
    前記送信部は、前記受信されたデータセグメントに基づいて前記コンテンツリクエスト端末に集合化されたデータ送信方式を用いて前記コンテンツを送信し、
    前記コンテンツリクエスト端末に前記コンテンツの送信を失敗した場合、前記コンテンツリクエスト端末に前記コンテンツを受信できるようにするための前記コンテンツリクエスト端末の状態の変更をリクエストするメッセージを送信することを特徴とするコンテンツ共有を行う中間ノード。
18. 前記受信部は、セッション開始プロトコルを用いて前記コンテンツに対する前記共有代行リクエストメッセージを受信し、
    前記送信部は、セッション開始プロトコルを用いて前記コンテンツを送信することを特徴とする請求項１７に記載のコンテンツ共有を行う中間ノード。
19. 前記データセグメントリクエストメッセージ各々は、前記コンテンツ名及び該当のデータセグメントに対する識別情報を含むことを特徴とする請求項１７に記載のコンテンツ共有を行う中間ノード。
20. 前記処理部は、前記中間ノードから前記データセグメントを所有している少なくとも１つの端末へのルーティング経路を決定し、
    前記送信部は、前記ルーティング経路に基づいて前記データセグメントを所有している少なくとも１つの端末に前記データセグメントリクエストメッセージを送信することを特徴とする請求項１７に記載のコンテンツ共有を行う中間ノード。
21. 前記送信部は、前記データセグメントリクエストメッセージに対応する前記複数のデータセグメントの受信が完了した場合、前記コンテンツリクエスト端末に集合化されたデータ送信方式を用いて前記コンテンツを送信することを特徴とする請求項１７に記載のコンテンツ共有を行う中間ノード。
22. 前記送信部は、前記コンテンツリクエスト端末に前記コンテンツの受信をリクエストし、前記コンテンツの受信リクエストに対する応答に基づいて前記コンテンツリクエスト端末に前記コンテンツを送信することを特徴とする請求項１８に記載のコンテンツ共有を行う中間ノード。
23. 前記共有代行リクエストメッセージは、前記共有代行リクエストメッセージが有効な時間を示すライフタイム情報を含むことを特徴とする請求項１に記載の中間ノードのコンテンツ共有方法。
24. 前記共有代行リクエストメッセージは、前記共有代行リクエストメッセージが有効な時間を示すライフタイム情報を含むことを特徴とする請求項１７に記載のコンテンツ共有を行う中間ノード。
25. コンテンツ指向ネットワーキングに基づいて、複数のデータセグメントを含むコンテンツの共有を行うコンテンツリクエスト端末において、
    コンテンツ名を含む前記コンテンツに対する共有代行リクエストメッセージを生成する共有代行リクエストメッセージ生成部と、
    中間ノードに前記コンテンツに対する前記共有代行リクエストメッセージを送信する送信部と、
    前記中間ノードからの前記データセグメントに基づく前記コンテンツの受信を失敗した場合、前記中間ノードから前記コンテンツを受信できるようにするための前記コンテンツリクエスト端末の状態の変更をリクエストするメッセージを受信し、前記中間ノードから前記コンテンツを受信する受信部と、
    前記中間ノードから受信したコンテンツを格納する格納部と、を備えることを特徴とするコンテンツリクエスト端末。
26. 前記中間ノードは、前記コンテンツリクエスト端末に送信された前記データセグメントを集合化することを特徴とする請求項２５に記載のコンテンツリクエスト端末。
27. 前記共有代行リクエストメッセージは、前記共有代行リクエストメッセージが有効な時間を示すライフタイム情報を含むことを特徴とする請求項２５に記載のコンテンツリクエスト端末。

Images