JP6213914B2 - 通信端末、およびコンテンツ出版方法 - Google Patents

Description

本発明は、コンテンツ中心型ネットワークを構成する通信端末、転送端末、および、コンテンツ中心型ネットワークにおけるコンテンツ出版方法に関する。

近年、非特許文献１に記載のＣＣＮ（Content Centric Network：コンテンツ中心型ネットワーク）と呼ばれる技術が、注目されている。ＣＣＮは、コンテンツを、コンテンツの名前に基づいて管理するコンテンツ配信基盤である。

ＣＣＮでは、以下のようにして、コンテンツの取得が行われる。まず、コンテンツを取得しようとする通信端末は、コンテンツの名前を指定したインタレストパケット（Interest Packet）を送出する。送出されたインタレストパケットは、ＣＣＮに網目状に配置された多数の転送端末により、該当する名前のコンテンツを格納する通信端末へと転送される。インタレストパケットを受け取った当該通信端末は、該当する名前のコンテンツのデータを、パケットに格納して送出する。送出されたデータパケットは、多数の転送端末によりインタレストパケットとは逆方向に転送され、インタレストパケットを送出した通信端末へと到達する。

ここで、ＣＣＮの特徴の１つとして、転送端末による、データのキャッシュ機能およびインタレストパケットに対する応答機能がある。ルータ等の転送端末は、転送したデータの複製をキャッシュする。そして、転送端末は、当該データの名前を指定したインタレストパケットを受け取ったとき、インタレストパケットの転送を行わずに、キャッシュしたデータを、インタレストパケットの送信元へ返信する。

このような転送端末の機能により、ＣＣＮは、ネットワークの伝送負荷を低く抑え、コンテンツを効率的に配信することができるというメリットを有する。したがって、ＣＣＮは、インターネット等の公共通信ネットワークへの適用が期待されている。

インターネット等の既存の通信ネットワークでは、音楽コンテンツや映像コンテンツ等、実時間ストリームデータのコンテンツ（以下、単に「コンテンツ」という）を配信することが、広く行われている。そこで、ＣＣＮにおいても、このようなコンテンツがより効率良く配信されることが望ましい。

そこで、コンテンツを構成する複数のブロックのそれぞれがどのデバイスに格納されているかを管理する技術が、例えば、特許文献１に記載されている。また、コンテンツを取得する処理を、コンテンツにおける各ブロックの位置を示すインデックス情報へのアクセスと、インデックス情報に基づく各ブロックへのアクセスという、２段階の処理に分ける技術が、例えば、非特許文献１に記載されている。これらの従来技術によれば、コンテンツを構成する複数のブロックのそれぞれを効率良く取得することを可能にし、全体として、コンテンツを効率良く配信することを可能にする。

ところで、従来、コンテンツを配信したユーザとは別のユーザが、配信された当該コンテンツを編集して配信することが行われている。編集後のコンテンツは、例えば、長時間の映像を短くまとめたダイジェスト版の映像や、この映像を更に画像編集した映像である。このような編集後コンテンツについても、ＣＣＮにおいて効率良く配信されることが望ましい。

そこで、編集後コンテンツに、編集後コンテンツの基となったコンテンツ（以下「オリジナルコンテンツ」という）と共通する内容が含まれている場合に、オリジナルコンテンツのキャッシュを、編集後コンテンツの配信に活用することが考えられる。

米国特許出願公開第２０１２／０１５８９７３号明細書

Derek Kulinsk et al., "NDNVideo: Random-access Live and Pre-recorded Streaming using NDN", Technical Report NDN-0007, 2012

しかしながら、従来技術において、編集後コンテンツは、オリジナルコンテンツと共通する内容を含んでいたとしても、オリジナルコンテンツとは別のコンテンツとして扱われる。したがって、従来技術では、オリジナルコンテンツのキャッシュを、編集後コンテンツの配信に活用することができないという課題を有する。

本発明の目的は、オリジナルコンテンツのキャッシュが編集後コンテンツの配信に活用されるようにすることができる、通信端末、転送端末、およびコンテンツ出版方法を提供することである。

本開示の通信端末は、コンテンツ中心型ネットワークを構成する通信端末であって、名前を有するオリジナルブロックにより構成されるオリジナルコンテンツを取得するオリジナルコンテンツ取得部と、前記オリジナルコンテンツから、編集後ブロックにより構成される編集後コンテンツを生成するコンテンツ編集部と、前記編集後コンテンツの名前および前記編集後ブロックの名前を決定する名前決定部と、前記編集後コンテンツのインデックス情報と前記編集後ブロックとを出版する出版部と、を有し、前記名前決定部は、前記編集後ブロックの内容が前記オリジナルブロックの内容と同一であるとき、前記オリジナルブロックの前記名前を、前記編集後ブロックの名前として決定する。

本開示のコンテンツ出版方法は、コンテンツ中心型ネットワークにおけるコンテンツ出版方法であって、名前を有するオリジナルブロックにより構成されるオリジナルコンテンツを取得するステップと、前記オリジナルコンテンツから、編集後ブロックにより構成される編集後コンテンツを生成するステップと、前記編集後コンテンツの名前および前記編集後ブロックの名前を決定するステップと、前記編集後コンテンツのインデックス情報と前記編集後ブロックとを出版するステップと、を有し、前記編集後ブロックの名前を決定するステップは、前記編集後ブロックの内容が前記オリジナルブロックの内容と同一であるとき、前記オリジナルブロックの前記名前を、前記編集後ブロックの名前として決定する。

本開示によれば、オリジナルコンテンツのキャッシュが編集後コンテンツの配信に活用されるようにすることができる。

本発明の実施の形態１に係る通信端末の構成の一例を示すブロック図 本発明の実施の形態２に係る通信端末を含む通信システムの構成を示すシステム構成図 本実施の形態２における編集後コンテンツの概要の一例を示す図 本実施の形態２における名前空間の設計例を示す図 本実施の形態２における編集端末の構成の一例を示すブロック図 本実施の形態２における転送端末の構成の一例を示すブロック図 本実施の形態２における編集端末の動作の一例を示すフローチャート 本実施の形態２におけるコンテンツ取得処理の一例を示すフローチャート 本実施の形態２におけるコンテンツ編集処理の一例を示すフローチャート 本実施の形態２におけるインタレストパケット応答処理の一例を示すフローチャート 本実施の形態２における転送端末の動作の一例を示すフローチャート 本実施の形態２におけるＦＩＢ部の内容の一例を示す図 本実施の形態２におけるＣＳ部の内容の一例を示す図 本実施の形態２におけるインタレストパケット対応処理の一例を示すフローチャート 本実施の形態２におけるパケットのやり取りの流れの一例を示すシーケンス図 本発明の実施の形態３に係る通信システムの構成の一例を示すシステム構成図 本実施の形態３における名前空間の設計例を示す図 本実施の形態３における編集端末の構成の一例を示すブロック図 本実施の形態３における転送端末の構成の一例を示すブロック図 本実施の形態３における転送端末のインタレストパケット対応処理の一例を示すフローチャート

以下、本発明の各実施の形態について、図面を参照して詳細に説明する。

（実施の形態１）
本発明の実施の形態１は、本発明の基本的態様の一例である。

図１は、本実施の形態に係る通信端末の構成の一例を示すブロック図である。

図１において、通信端末５００は、オリジナルコンテンツ取得部５２０、コンテンツ編集部５４０、名前決定部５５０、および出版部５７０を有する。

オリジナルコンテンツ取得部５２０は、名前を有するオリジナルブロックにより構成されるオリジナルコンテンツを取得する。

コンテンツ編集部５４０は、オリジナルコンテンツから、編集後ブロックにより構成される編集後コンテンツを生成する。

名前決定部５５０は、編集後コンテンツの名前および編集後ブロックの名前を決定する。但し、名前決定部５５０は、編集後ブロックの内容がオリジナルブロックの内容と同一であるとき、オリジナルブロックの名前を、編集後ブロックの名前として決定する。

出版部５７０は、編集後コンテンツのインデックス情報と編集後ブロックとを出版する。

また、通信端末５００は、図示しないが、例えば、ＣＰＵ（central processing unit）、制御プログラムを格納したＲＯＭ（read only memory）等の記憶媒体、ＲＡＭ（random access memory）等の作業用メモリ、および通信回路を有する。この場合、上記した各部の機能は、ＣＰＵが制御プログラムを実行することにより実現される。

以上のように、本実施の形態に係る通信端末５００は、編集後ブロックの内容がオリジナルブロックの内容と同一であるとき、オリジナルブロックの名前をそのまま用いて、編集後コンテンツのインデックス情報と編集後ブロックとを出版する。

これにより、編集後コンテンツのインデックス情報に基づいて編集後ブロックを探索する際に、同一内容のオリジナルブロックのキャッシュにヒットし、これを取得することが可能となる。

したがって、本実施の形態に係る通信端末５００は、オリジナルコンテンツのキャッシュが編集後コンテンツの配信に活用されるようにすることができる。

（実施の形態２）
本発明の実施の形態２は、コンテンツが実時間ストリームデータを含む場合の、本発明の具体的態様の一例である。

＜用語の定義＞
まず、本実施の形態において用いられる主な用語の定義について説明する。

「コンテンツ」とは、ネットワークによる配信の対象となる、音声および映像等の実時間ストリームデータである。コンテンツには、オリジナルコンテンツ（オリジナルデータ）と、オリジナルコンテンツを編集して得られた編集後コンテンツ（編集後データ）とがある。

「コンテンツ名」とは、所定の名前空間におけるコンテンツの名前である。

「ブロック」とは、コンテンツを構成するデータを時間軸に沿って分割したときの、分割されたデータの一まとまりであり、映像音声などのデータをアクセスする単位である。具体的には、ブロックは、例えば、ＭＰＥＧ２−ＴＳのパケットを複数集めた一まとまり、ＲＦＣ３９８４で規定されるＨ．２６４のパケット、あるいは、ＲＦＣ３５５１で規定されるＲＴＰのパケットまたはそのペイロードを複数集めた一まとまりである。

「ブロック名」とは、上記所定の名前空間におけるブロックの名前である。なお、各ブロックには、そのデータの一部として、ブロック名が付与される。

「インデックス情報」（Index）とは、コンテンツ毎に、コンテンツ名と、コンテンツを構成するブロックのコンテンツにおける位置と、コンテンツを構成するブロックのブロック名との対応関係を示す情報である。コンテンツにおける位置とは、例えば、実時間ストリームデータの時間軸における再生時刻である。

「データパケット」とは、インデックス情報、あるいは、ブロックの一部または全部を格納したパケットである。

「ＣＣＮ」とは、コンテンツ中心型ネットワーク（Content Centric Network）の略語であり、コンテンツの配信をコンテンツ名に基づいて管理するコンテンツ配信基盤を指す。本実施の形態において、ＣＣＮは、コンテンツの配信を要求する通信端末によって、インデックス情報へのアクセスとブロックへのアクセスという２段階の処理が行われることにより、コンテンツの配信を実現する。

「インタレストパケット」（Interest Packet）とは、データの返信を要求するパケットである。インタレストパケットには、インデックス情報の返信を要求するパケットと、ブロックの返信を要求するパケットとがある。

「出版」とは、あるデータについて、当該データを指定したインタレストパケットに対する応答（データパケット）を送信する能力がある事実を、ＣＣＮに登録することである。すなわち、「出版」とは、データを、そのデータの名前を指定したインタレストパケットの発行によって取得することが可能な状態にすることであり、ＣＣＮ網の他の端末に対して、特定の名前空間のインタレストパケットの送信を依頼する動作を指す。具体的には、ある通信端末が、近接する他の端末に接続した際に、他の端末に自動生成される仮想インタフェイス（非特許文献１では、「フェイス」と表現されているもの）の属性として、特定の名前空間以下のインタレストパケットを通信端末へ転送するような情報を、他の端末に登録する行為を指す。ＣＣＮ網は、かかる情報を、ＦＩＢ（Forwarding Information Base）に登録すると共に、所定の経路制御プロトコル（例えば、ＯＳＰＦＮ）により、ＣＣＮ網内の各端末間に伝搬流通させる。すなわち、上記登録には、コンテンツ名のプレフィックスを他の端末に通知する処理が含まれる。

＜通信システムの概要＞
次に、本実施の形態に係る通信端末を含む通信システムの構成について説明する。

図２は、本実施の形態に係る通信端末を含む通信システムの構成を示すシステム構成図である。

図２において、通信システム１００は、第１〜第３の転送端末２００−１〜２００−３を配置した通信ネットワーク３００と、通信ネットワーク３００に接続されたオリジナル端末４００および第１〜第４の編集端末５００−１〜５００−４を有する。通信システム１００は、ＣＣＮ網を形成している。

なお、以下の説明において、第１〜第３の転送端末２００−１〜２００−３は、共通の構成を有しているため、適宜、「転送端末２００」と総称する。また、第１〜第４の編集端末５００−１〜５００−４は、共通の構成を有しているため、適宜、「編集端末５００」と総称する。

転送端末２００は、ＣＣＮに対応したルータである。転送端末２００は、インタレストパケットおよびデータパケットの転送を行うと共に、転送したデータパケットの複製をキャッシュする。そして、転送端末２００は、受信したインタレストパケットが指定するデータパケットをキャッシュしている場合、そのデータパケットを、インタレストパケットの送信元へ返信する。

オリジナル端末４００は、ＣＣＮに対応した通信端末のうち、実時間ストリームデータを含むオリジナルコンテンツを出版する端末である。すなわち、オリジナル端末４００は、オリジナルコンテンツの出版元（Publisher）である。オリジナル端末４００は、例えば、通信機能を有するパーソナルコンピュータである。

編集端末５００は、ＣＣＮに対応した通信端末のうち、オリジナル端末４００からオリジナルコンテンツを取得し、オリジナルコンテンツから編集後コンテンツを生成して出版する端末である。すなわち、編集端末５００は、編集後コンテンツの出版元である。編集端末５００は、例えば、通信機能を有するパーソナルコンピュータである。

このようなＣＣＮ網において、例えば、第１の編集端末５００−１が、既にオリジナルコンテンツを取得していたとする。この場合、オリジナル端末４００から第１の編集端末５００−１へと至る経路上に位置する第１および第２の転送端末２００−１、２００−２には、オリジナルコンテンツのデータがキャッシュされた状態となっている。

この状態で、第２の編集端末５００−２がオリジナルコンテンツの名前を指定したインタレストパケットを送信したとする。この場合、オリジナル端末４００よりも手前に位置する第２の転送端末２００−２から、オリジナルコンテンツのデータを格納したデータパケットが返信されることになる。

本実施の形態において、オリジナルコンテンツは、ある２時間の映画の映像音声ストリームデータである。そして、編集端末５００は、上記映画の予告版として、３分間のダイジェスト版（短縮版）の映像音声ストリーム（以下「ダイジェスト」という）を、編集後コンテンツとして出版する端末である。第１〜第４の編集端末５００−１〜５００−４の各ユーザは、例えば、オリジナル端末４００のユーザから、映画のダイジェスト版の作成および配信を請け負っている技術者である。

なお、以下の説明において、第１〜第４の編集端末５００−１〜５００−４のユーザは、それぞれ、第１〜第４の編集者という。また、第１〜第４の編集端末５００−１〜５００−４において生成される編集後コンテンツは、それぞれ、第１〜第４のダイジェストという。

図３は、第１〜第４の編集端末５００−１〜５００−４における編集後コンテンツの概要の一例を示す図である。

図３に示すように、オリジナルコンテンツである映画６１１は、シーンＡ〜Ｄから成る実時間ストリームデータである。編集後コンテンツである第１〜第４のダイジェスト６１２〜６１５は、それぞれ、映画６１１から短い複数の区間の実時間ストリームデータを抽出して連結したデータである。

第１〜第４のダイジェスト６１２〜６１５を構成する区間のパターンは、互いに異なっている。すなわち、映画６１１および第１〜第４のダイジェスト６１２〜６１５は、それぞれ、別のコンテンツとなっている。

一方で、実時間ストリームデータから抽出されたデータの内容に対する編集が行われない場合、映画６１１および第１〜第４のダイジェスト６１２〜６１５の間には、共通するデータ部分（以下「共通データ」という）が存在する。キャッシュされた共通データは、映画６１１および第１〜第４のダイジェスト６１２〜６１５のいずれの配信であるかによらず、活用されることが望ましい。

しかしながら、映画６１１および第１〜第４のダイジェスト６１２〜６１５のそれぞれは、出版元が異なるため、異なるコンテンツ名が付与される。そして、従来では、コンテンツを構成するブロックには、当該コンテンツのコンテンツ名に応じたブロック名が付与される。したがって、異なる出版元から出版された複数のコンテンツの間に、共通データが存在したとしても、かかる共通データを、複数のコンテンツの配信で活用するということができなかった。

そこで、本実施の形態に係る編集端末５００は、編集後ブロックの内容がオリジナルブロックの内容と同一であるとき、オリジナルブロックの名前をそのまま用いて、編集後コンテンツのインデックス情報および編集後ブロックを出版する。これにより、共通データのブロックは、その出版元が異なっていても、常に共通のブロック名を有するようになる。すなわち、異なる出版元から出版された複数のコンテンツの間に共通データが存在したときに、かかる共通データを、複数のコンテンツの配信で活用することが可能となる。

ここで、通信システム１００において用いられる名前空間について説明する。

図４は、通信システム１００において用いられる名前空間の設計例を示す図である。

通信システム１００には、例えば、図４に示すような、オリジナルコンテンツの名前空間６２０と、オリジナルブロックの名前空間６３０と、編集後コンテンツの名前空間６４０と、編集後ブロックの名前空間６５０とが、設定される。

オリジナルコンテンツの名前空間６２０は、サービスをＣＣＮ網内で特定するためのプレフィックス部６２１と、データそのものを格納するデータ部６２２、６２３と、から成る。

オリジナルコンテンツの名前空間６２０の「ｉｎｄｅｘ／」以下のデータ部６２３には、オリジナルブロックの再生時刻と当該オリジナルブロックのブロック名との組の集合が、格納される。ここで、再生時刻とは、オリジナルコンテンツの実時間ストリームデータの時間軸における、オリジナルブロックが再生されるべき時刻である。

例えば、データ部６２２、６２３において、「ｉｎｄｅｘ／ｔｉｍｅ００＿００＿０１」には、時刻０１（例：オリジナルコンテンツの開始時刻から１秒後の時刻）に再生されるべきオリジナルブロックのブロック名が格納される。すなわち、オリジナルコンテンツの名前空間６２０の名前にアクセスすることにより、オリジナルブロックとその再生時刻との組を得ることができるようになっている。

すなわち、オリジナルコンテンツの名前空間６２０のデータ部６２３に格納された情報は、オリジナルコンテンツのインデックス情報である。

また、図示しないが、「ｉｎｄｅｘ／」の名前空間には、「ｉｎｄｅｘ／」以下の名前空間にある全てのブロックのブロック名を格納する、「ｉｎｄｅｘ／ＡＬＬ」という特別な名前が定義されている。「ｉｎｄｅｘ／ＡＬＬ」を含むコンテンツ名を指定したインタレストパケットに対しては、「ｉｎｄｅｘ／」以下にあるブロック名を含むデータを生成し、応答するように定められている。

更に、図示しないが、「ｉｎｄｅｘ／」の名前空間には、「ｉｎｄｅｘ／」以下にある全てのブロックのうち、再生時刻が最も最近の（最も大きい）ブロックのブロック名を格納する、「ｉｎｄｅｘ／ＬＡＴＥＳＴ」という、別の特別な名前が定義されている。「ｉｎｄｅｘ／ＬＡＴＥＳＴ」を含むコンテンツ名を指定したインタレストパケットは、「ｉｎｄｅｘ／」以下にある全てのブロックのうち、再生時刻が最も最近のブロックのブロック名を指定したインタレストパケットと等価である。

例えば、２時間のコンテンツについて、「ｉｎｄｅｘ／ＡＬＬ」を指定したインタレストパケットに対し、「ｔｉｍｅ００＿００＿０１」〜「ｔｉｍｅ０２＿００＿００」とこれらの時刻に対応するブロック名とが返信される。一方で、「ｉｎｄｅｘ／ＬＡＴＥＳＴ」を指定したインタレストパケットに対しては、「ｔｉｍｅ０２＿００＿００」とこの時刻に対応するブロック名のみが返信される。

オリジナルブロックの名前空間６３０も、オリジナルコンテンツの名前空間６２０と同様に、プレフィックス部６３１と、データ部６３２、６３３と、から成る。但し、オリジナルブロックの名前空間６３０のデータ部６３２の名前空間は、「ｉｎｄｅｘ／」ではなく、「ｈａｓｈ／」で始まる。そして、「ｈａｓｈ／」以下のデータ部６３３には、オリジナルブロックのブロック名と当該オリジナルブロックのデータ本体との組が、格納される。

すなわち、編集端末５００は、オリジナルコンテンツを取得する際、まず、オリジナルコンテンツの名前空間６２０を用いてデータ部６２３にアクセスし、オリジナルコンテンツのインデックス情報を取得する。そして、編集端末５００は、取得したオリジナルコンテンツのインデックス情報に基づき、オリジナルブロックの名前空間６３０を用いてデータ部６３３にアクセスし、オリジナルブロックの実体を取得する。

なお、インデックス情報は、必ずしも、各オリジナルブロックの再生時刻を厳密に定義する必要はない。例えば、インデックス情報は、オリジナルブロックが属するシーンの開始時刻等、各オリジナルブロックの大まかな位置を定義するものであってもよい。この場合、「ｈａｓｈ／」以下のデータ部６３３は、オリジナルブロックの再生時刻に関する付加情報を、更に格納することが望ましい。かかる付加情報は、例えば、オリジナルコンテンツ全体における再生順序の番号（例えば、「００１」）や、インデックス情報に記述されたシーンの開始時刻に対するオリジナルブロックの再生時刻のオフセット値（例えば、「０.１秒後」）である。

編集後コンテンツの名前空間６４０は、オリジナルコンテンツの名前空間６２０と同様に、プレフィックス部６４１およびデータ部６４２、６４３を有する。また、編集後ブロックの名前空間６５０は、オリジナルブロックの名前空間６３０と同様に、プレフィックス部６５１およびデータ部６５２、６５３を有する。
の構成を有する。

但し、編集後コンテンツの名前空間６４０および編集後ブロックの名前空間６５０のサービス名（プレフィックス部６４１、６５１）は、オリジナルコンテンツの名前空間６２０およびオリジナルブロックの名前空間６３０のサービス名（プレフィックス部６２１、６３１）とは異なる。

上述の通り、本実施の形態に係る編集端末５００は、編集後ブロックの内容がオリジナルブロックの内容と同一であるとき、オリジナルブロックの名前をそのまま用いて、編集後コンテンツのインデックス情報および編集後ブロックを出版する。これは、編集後コンテンツの名前空間６４０のデータ部６４３に、オリジナルブロックのブロック名を、編集後ブロックのブロック名として格納することを意味する。

＜各端末の構成＞
次に、編集端末５００および転送端末２００の構成について説明する。

図５は、編集端末５００の構成の一例を示すブロック図である。

図５において、編集端末５００は、通信部５１０、オリジナルコンテンツ取得部５２０、オリジナルコンテンツ保管部５３０、コンテンツ編集部５４０、名前決定部５５０、編集後コンテンツ保管部５６０、および出版部５７０を有する。

通信部５１０は、ＣＣＮ網に接続し、他の端末との間で通信を行う。

オリジナルコンテンツ取得部５２０は、通信部５１０を介して、ＣＣＮ網からオリジナルコンテンツを取得する。そして、オリジナルコンテンツ取得部５２０は、取得したオリコンを、オリジナルコンテンツ保管部５３０へ出力する。

オリジナルコンテンツ保管部５３０は、オリジナルコンテンツ取得部５２０から入力されたオリジナルコンテンツを格納する。

コンテンツ編集部５４０は、ユーザからオリジナルコンテンツに対する編集を受け付けて、オリジナルコンテンツから編集後コンテンツを生成する。コンテンツ編集部５４０は、ブロックサイズ分割部５４１およびブロック編集部５４２を有する。

ブロックサイズ分割部５４１は、オリジナルコンテンツ保管部５３０に格納されたオリジナルコンテンツの実時間ストリームデータを、オリジナルブロックと同一の区間で分割して得られる、分割ブロックを取得する。すなわち、分割ブロックの内容は、オリジナルブロックの内容と同一である。

ブロック編集部５４２は、分割ブロックと内容が同一の編集後ブロック、または、分割ブロックを編集して得られる編集後ブロックに基づいて、編集後コンテンツを生成する。そして、ブロック編集部５４２は、生成した編集後コンテンツを、名前決定部５５０へ出力する。

名前決定部５５０は、コンテンツ編集部５４０から入力された編集後コンテンツの名前と、当該編集後コンテンツを構成する編集後ブロックの名前とを決定する。但し、名前決定部５５０は、編集後ブロックの内容がオリジナルブロックの内容と同一であるとき、オリジナルブロックのブロック名を、その編集後ブロックのブロック名として決定する。編集後ブロックの内容がオリジナルブロックの内容と同一である場合とは、分割ブロックをそのまま編集後ブロックとして用いる場合である。また、名前決定部５５０は、編集後コンテンツのインデックス情報を生成する。そして、名前決定部５５０は、編集後コンテンツと、生成した編集後コンテンツのインデックス情報とを、編集後コンテンツ保管部５６０に格納する。

編集後コンテンツ保管部５６０は、入力された編集後コンテンツのインデックス情報および編集後コンテンツ（つまり、編集後ブロック）を、格納する。

出版部５７０は、編集後コンテンツ保管部５６０に格納された、編集後コンテンツのインデックス情報と編集後ブロックとを、通信部５１０を介して、ＣＣＮ網に出版する。

なお、編集端末５００は、キーボード、マウス、タッチパネル等の操作インタフェイスと、液晶ディスプレイあるいはプラズマディスプレイ等の表示インタフェイスを備えている。

このような編集端末５００は、編集後ブロックの内容がオリジナルブロックの内容と同一であるとき、オリジナルブロックの名前をそのまま用いて、編集後コンテンツのインデックス情報および編集後ブロックを出版することができる。

図６は、転送端末２００の構成の一例を示すブロック図である。

図６において、転送端末２００は、転送通信部２１０、データ転送部２２０、ＦＩＢ部２３０、ＣＳ（Contents Store）部２４０、およびインタレストパケット対応部２５０を有する。

転送通信部２１０は、ＣＣＮ網に接続し、他の端末との間で通信を行う。転送通信部２１０は、仮想インタフェイス（非特許文献１の「フェイス」）である、第１〜第３のインタフェイス２１１−１〜２１１−３を有する。第１〜第３のインタフェイス２１１−１〜２１１−３は、それぞれ識別番号１〜３が設定されており、例えば、順に、オリジナル端末４００、第１の編集端末５００−１、および第２の編集端末５００−２に接続されている。

データ転送部２２０は、転送通信部２１０を介して、転送端末２００へのインデックス情報およびブロックの出版を受け付け、第１〜第３のインタフェイス２１１−１〜２１１−３の属性を、ＦＩＢ部２３０に設定する。かかる属性は、インタレストパケットあるいはデータを受信したとき、当該インタレストパケットおよびデータを、どのインタフェイスから送出するか、を定義する情報である。そして、データ転送部２２０は、ＦＩＢ部２３０の設定内容に基づき、転送通信部２１０を介して、インタレストパケットの送信元とインタレストパケットが指定するデータを格納する相手先との間において、インタレストパケットおよびデータの転送を行う。

また、データ転送部２２０は、データを転送する毎に、当該データ（当該データを格納したデータパケット）の複製を、ＣＳ部２４０（データキャッシュ部）に格納させる。かかるデータには、オリジナルコンテンツのインデックス情報、オリジナルブロック、編集後コンテンツのインデックス情報、および編集後ブロックが含まれる。

インタレストパケット対応部２５０は、ＣＳ部２４０に編集後コンテンツのインデックス情報が格納され、編集後コンテンツのコンテンツ名を指定したインタレストパケットが送られてきたとき、編集後コンテンツのインデックス情報の複製を返信する。また、インタレストパケット対応部２５０は、ＣＳ部２４０に編集後ブロックが格納され、編集後ブロックのブロック名を指定したインタレストパケットが送られてきたとき、編集後ブロックの複製を返信する。インタレストパケット対応部２５０は、これらのインタレストパケットの受信およびデータの返信を、転送通信部２１０を介して行う。

なお、転送端末２００は、図示しないが、ＰＩＴ（Pending Interest Table）を有している。データ転送部２２０は、ＰＩＴを管理および参照することにより、同じインタレストパケットが複数回、上流に転送されることを抑止する。

このような転送端末２００は、ＣＣＮにおける、データのキャッシュ機能およびインタレストパケットに対する応答機能を発揮することができる。

なお、編集端末５００および転送端末２００は、図示しないが、例えば、ＣＰＵ、制御プログラムを格納したＲＯＭ等の記憶媒体、ＲＡＭ等の作業用メモリ、および通信回路を、それぞれ有する。この場合、上記した各部の機能は、ＣＰＵが制御プログラムを実行することにより実現される。

また、オリジナル端末４００は、例えば、編集端末５００と同様の構成を有する。但し、オリジナル端末４００は、オリジナルコンテンツの実時間ストリームデータを、その時間軸における所定の時刻を基準として、時間軸に沿って所定のサイズで分割して、オリジナルブロックを生成する。そして、オリジナル端末４００は、オリジナルコンテンツのインデックス情報およびオリジナルブロックの出版を行う。

以下の説明において、オリジナルコンテンツの実時間ストリームデータの時間軸は、「オリジナル時間軸」という。オリジナルブロックを生成する際の分割の基準となった所定の時刻は、以下、「分割基準時刻」という。オリジナルブロックを生成する際の分割のサイズは、「オリジナルブロックサイズ」という。

＜各端末の動作＞
次に、編集端末５００および転送端末２００の動作について説明する。

図７は、編集端末５００の動作の一例を示すフローチャートである。

まず、ステップＳ１１００において、オリジナルコンテンツ取得部５２０は、ユーザ操作等によりオリジナルコンテンツの取得を指示されたか否かを判断する。オリジナルコンテンツ取得部５２０は、オリジナルコンテンツの取得を指示された場合（Ｓ１１００：ＹＥＳ）、処理をステップＳ１２００へ進める。また、オリジナルコンテンツ取得部５２０は、オリジナルコンテンツの取得を指示されていない場合（Ｓ１１００：ＮＯ）、処理を後述のステップＳ１３００へ進める。

ステップＳ１２００において、オリジナルコンテンツ取得部５２０は、オリジナルコンテンツを取得する処理であるコンテンツ取得処理を行ってから、処理を後述のステップＳ１３００へ進める。

図８は、コンテンツ取得処理の一例を示すフローチャートである。

まず、ステップＳ１２１０において、オリジナルコンテンツ取得部５２０は、オリジナルコンテンツのコンテンツ名を取得する。

なお、オリジナル端末４００には、ユニークなサービス名が予め設定されている。例えば、オリジナル端末４００には、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ」というサービス名が設定されている。このサービス名は、オリジナルコンテンツのコンテンツ名として用いられる。すなわち、このサービス名は、オリジナルコンテンツの名前空間のプレフィックス部６２１（図４参照）である。したがって、例えば、オリジナルコンテンツ取得部５２０は、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ」を、オリジナルコンテンツのコンテンツ名として取得する。

そして、ステップＳ１２２０において、オリジナルコンテンツ取得部５２０は、オリジナルコンテンツのコンテンツ名を指定したインタレストパケットを生成し、ＣＣＮ網に送信する。このインタレストパケットに対する応答として、オリジナルコンテンツ取得部５２０は、オリジナル端末４００から、オリジナルコンテンツのインデックス情報を取得する。

例えば、オリジナルコンテンツ取得部５２０は、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｉｎｄｅｘ／」という名前空間を含むインタレストパケットを、送信する。具体的には、オリジナルコンテンツ取得部５２０は、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｉｎｄｅｘ／ｔｉｍｅ００＿００＿０１」を指定したインタレストパケットを発行する。そして、その応答として、オリジナルコンテンツ取得部５２０は、「ＨＡＳＨ１」というブロック名および再生時刻情報の組、すなわち、オリジナルコンテンツのインデックス情報を取得する。なお、再生時刻情報とは、ＲＴＰパケットのタイムスタンプのように特定の周波数で刻印された再生時刻であってもよいし、再生開始時刻からの相対時間のずれを表現したものであってもよい。

そして、ステップＳ１２３０において、オリジナルコンテンツ取得部５２０は、取得したインデックス情報に基づき、オリジナルブロックのブロック名を指定したインタレストパケットを生成し、ＣＣＮ網に送信する。このインタレストパケットに対する応答として、オリジナルコンテンツ取得部５２０は、オリジナル端末４００から、オリジナルブロックを取得する。

例えば、オリジナルコンテンツ取得部５２０は、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｈａｓｈ／ＨＡＳＨ１」という名前空間を指定したインタレストパケットを、送信する。そして、オリジナルコンテンツ取得部５２０は、当該名前空間に格納されたオリジナルブロックの実体を、取得する。

そして、ステップＳ１２４０において、オリジナルコンテンツ取得部５２０は、取得されたオリジナルブロックに基づいて、オリジナルコンテンツの実時間ストリームデータを復元する。すなわち、オリジナルコンテンツ取得部５２０は、取得された複数のオリジナルブロックを、再生順に並び替えて連結する。これは、ＣＣＮでは、ブロックの到着順序は、再生順序と必ずしも一致しないためである。なお、かかる復元は、オリジナルブロックをオリジナルコンテンツ補間部５３０に格納する毎に行われてもよいし、全てのオリジナルブロックが格納された後に行われてもよい。また、再生順序は、例えば、上述のオリジナルブロックの再生時刻に関する付加情報から取得することができる。

そして、ステップＳ１２５０において、オリジナルコンテンツ取得部５２０は、オリジナルコンテンツを構成する全てのオリジナルブロックを取得したか否かを判断する。オリジナルコンテンツ取得部５２０は、取得していないオリジナルブロックがある場合（Ｓ１２５０：ＮＯ）、処理をステップＳ１２３０へ戻し、取得していないオリジナルブロックの取得を行う。また、オリジナルコンテンツ取得部５２０は、全てのオリジナルブロックを取得した場合（Ｓ１２５０：ＹＥＳ）、処理を図７のフローチャートへ戻す。

例えば、オリジナル端末４００からは、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｈａｓｈ／ＨＡＳＨ１／」、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｈａｓｈ／ＨＡＳＨ２／」、・・・というブロック名の、オリジナルブロックが、返信される。また、これに先立って、オリジナル端末４００からは、これらのオリジナルブロックのブロック名およびオリジナルコンテンツにおける位置と、オリジナルコンテンツのコンテンツ名「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／」とを対応付けたインデックス情報とが、返信される。この結果、ＣＣＮ網は、各所（例えば、転送端末２００）に、これらのオリジナルブロックとインデックス情報とをキャッシュした状態となる。

また、オリジナルコンテンツ保管部５３０には、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｈａｓｈ／ＨＡＳＨ１／」、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｈａｓｈ／ＨＡＳＨ２／」、・・・というブロック名に対応する複数のオリジナルブロックを連結したデータが、オリジナルコンテンツとして格納された状態となる。

図７のステップＳ１３００において、コンテンツ編集部５４０は、ユーザ操作等により、オリジナルコンテンツの編集の開始を指示されたか否かを判断する。コンテンツ編集部５４０は、オリジナルコンテンツの編集の開始を指示された場合（Ｓ１３００：ＹＥＳ）、処理をステップＳ１４００へ進める。また、コンテンツ編集部５４０は、オリジナルコンテンツの編集の開始を指示されていない場合（Ｓ１３００：ＮＯ）、処理を後述のステップＳ１５００へ進める。

ステップＳ１４００において、コンテンツ編集部５４０は、オリジナルコンテンツを編集するコンテンツ編集処理を行ってから、処理を後述のステップＳ１５００へ進める。

図９は、コンテンツ編集処理の一例を示すフローチャートである。

まず、ステップＳ１４１０において、ブロックサイズ分割部５４１は、オリジナルコンテンツの実時間ストリームデータを、上述の分割基準時刻を基準としてオリジナル時間軸に沿ってオリジナルブロックサイズ（変数Ｂｓ）で分割して、分割ブロック（ＢＬＫＣｏｎｔｅｎｔ）を取得する。

分割基準時刻としては、例えば、オリジナル時間軸の開始時刻、つまり、実時間ストリームデータの先頭位置（映像のストリーム開始および音声のストリーム開始の、いずれか早い方の先頭の再生時刻）を採用することができる。また、分割基準時刻としては、特定のマーカが挿入された時刻等、他の特定の再生時刻や、編集端末５００が搭載しているＧＰＳ（図示せず）の時刻を参照時刻として、特定の時刻に受信したデータ位置を採用してもよい。

オリジナルブロックサイズとしては、例えば、１５００バイトといったイーサネット（登録商標）パケットのフレーム長や、１２８０バイトといったＶＰＮ（Virtual Private Network）で用いられるＭＴＵ（Maximum Transmission Unit）サイズを採用することができる。

ブロックサイズ分割部５４１は、通信システム１００の既定値として予め配布された分割基準時刻およびオリジナルブロックサイズを用いてもよい。あるいは、ブロックサイズ分割部５４１は、オリジナルコンテンツを取得する毎に、オリジナルコンテンツのメタデータから、分割基準時刻およびオリジナルブロックサイズを取得してもよい。

このように、分割基準時刻およびオリジナルブロックサイズを用いて分割ブロックを取得することにより、分割ブロックの内容を、オリジナルブロックの内容と同一とすることができる。

なお、コンテンツには、通常、実時間ストリームデータだけでなくメタデータが含まれる。したがって、ブロックサイズ分割部５４１は、実時間ストリームデータとメタデータとを分離する処理を行ってもよい。

そして、ステップＳ１４２０において、ブロック編集部５４２は、分割ブロックから編集後ブロックを生成し、編集後コンテンツを生成する。

ブロック編集部５４２は、分割ブロックと内容が同一の編集後ブロックと、分割ブロックを編集して得られる編集後ブロックとの、どちらを生成してもよい。

ブロック編集部５４２は、例えば、編集端末５００のユーザに対して、編集後コンテンツに含める対象となる分割ブロックの選択や、分割ブロックの映像音声に対する編集を行うための、編集操作画面を生成して表示する。編集操作画面は、例えば、編集点を提示する機能、ダイジェストの対象となる位置をマーキングする機能、および、オリジナルコンテンツから編集したい対象データを取得する機能等を有する。

分割ブロックに対する編集には、例えば、映像の色の変更、文字のオーバレイでの挿入、ナレータの解説の重層等の、映像加工および音声加工が含まれる。

このような編集操作画面におけるユーザの操作の結果、例えば、オリジナルブロックと内容が同一の編集後ブロックと、オリジナルブロックとは内容が異なる編集後ブロックとが混合する編集後コンテンツが生成される。

なお、編集端末５００には、ユニークなサービス名が予め設定されている。例えば、編集端末５００には、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ＥＤ１」というサービス名が設定されている。このサービス名は、編集後コンテンツのコンテンツ名として用いられる。すなわち、このサービス名は、編集後コンテンツの名前空間のプレフィックス部６４１（図４参照）である。

そして、ステップＳ１４３０において、名前決定部５５０は、編集後コンテンツから、編集後ブロックを１つ選択する。

そして、ステップＳ１４４０において、名前決定部５５０は、選択中の編集後ブロックの内容が、オリジナルブロックの内容と同一であるか否かを判断する。なお、かかる判断は、例えば、コンテンツ編集部５４０において、分割ブロックに対して変更を加えたか否かに基づいて行われてもよい。名前決定部５５０は、編集後ブロックの内容がオリジナルブロックの内容と同一ではない場合（Ｓ１４４０：ＮＯ）、処理をステップＳ１４５０へ進める。また、名前決定部５５０は、編集後ブロックの内容がオリジナルブロックの内容と同一である場合（Ｓ１４４０：ＹＥＳ）、処理をステップＳ１４６０へ進める。

ステップＳ１４５０において、名前決定部５５０は、選択中の編集後ブロックに対して、オリジナルブロックのブロック名とは異なるブロック名を決定する。具体的には、例えば、名前決定部５５０は、編集後ブロックに所定のハッシュ関数を適用して得られるハッシュ値（ＢＫＬ＿ＨＡＳＨ）を、選択中の編集後ブロックのブロック名に決定する。

所定のハッシュ関数は、通信システム１００に予め配布あるいは周知された、通信システム１００の各端末に共通のハッシュ関数である。このように所定のハッシュ関数を用いてブロック名を決定することは、特に、編集後コンテンツに取得者制限を設けるようにした場合にメリットがある。かかるメリットについては、後述の本発明の実施の形態３において詳しく説明する。

例えば、オリジナルブロックのブロック名が、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｈａｓｈ／ＨＡＳＨ１／」であったとする。この場合、編集後ブロックのブロック名は、少なくともプレフィックス部が変化し、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ＥＤ１／ｈａｓｈ／ＨＡＳＨ１／」となる。

一方、ステップＳ１４６０において、名前決定部５５０は、選択中の編集後ブロックに対して、オリジナルブロックのブロック名と同一のブロック名を決定する。

例えば、オリジナルブロックのブロック名が、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｈａｓｈ／ＨＡＳＨ２／」であったとする。この場合、編集後ブロックのブロック名も、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｈａｓｈ／ＨＡＳＨ２／」のままとなる。すなわち、編集後ブロックの名前は、従来は、オリジナルブロックのブロック名に対して、少なくともプレフィックス部が変化していたが、本実施の形態では変化しない。

そして、ステップＳ１４７０において、名前決定部５５０は、編集後コンテンツを構成する全ての編集後ブロックのブロック名を決定したか否かを判断する。名前決定部５５０は、ブロック名を決定していない編集後ブロックが存在する場合（Ｓ１４７０：ＮＯ）、処理をステップＳ１４３０へ戻し、ブロック名が決定されていない編集後ブロックを選択する。また、名前決定部５５０は、全ての編集後ブロックのブロック名を決定した場合（Ｓ１４７０：ＹＥＳ）、処理をステップＳ１４８０へ進める。

ステップＳ１４８０において、名前決定部５５０は、各編集後ブロックの編集後コンテンツにおける位置および名前に基づいて、編集後コンテンツのインデックス情報を生成する。そして、名前決定部５５０は、生成したインデックス情報と、編集後コンテンツ（編集後ブロック）とを、編集後コンテンツ保管部５６０へ格納する。なお、インデックス情報の生成および格納は、出版部５７０によって行われてもよい。

そして、ステップＳ１４９０において、出版部５７０は、編集後コンテンツ保管部５６０に格納された、編集後コンテンツのインデックス情報および編集後コンテンツを、ＣＣＮ網に出版し、処理を図７のフローチャートへ戻す。

例えば、編集後コンテンツ保管部５６０は、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ＥＤ１／ｈａｓｈ／ＨＡＳＨ１／」、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｈａｓｈ／ＨＡＳＨ２／」、・・・というブロック名の、編集後ブロックを、格納した状態となる。また、編集後コンテンツ保管部５６０は、これらの編集後ブロックのブロック名および編集後コンテンツにおける位置と、編集後コンテンツのコンテンツ名「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ＥＤ１／」とを対応付けたインデックス情報を、格納した状態となる。そして、ＣＣＮ網は、これらのインデックス情報および編集後ブロックが出版された状態となる。

図７のステップＳ１５００において、出版部５７０は、ＣＣＮ網からインタレストパケットを受信したか否かを判断する。出版部５７０は、インタレストパケットを受信した場合（Ｓ１５００：ＹＥＳ）、処理をステップＳ１６００へ進める。また、出版部５７０は、インタレストパケットを受信していない場合（Ｓ１５００：ＮＯ）、処理を後述のステップＳ１７００へ進める。

ステップＳ１６００において、出版部５７０は、応答すべきインタレストパケットに対して応答する処理であるインタレストパケット応答処理を行ってから、後述のステップＳ１７００へ処理を進める。

図１０は、インタレストパケット応答処理の一例を示すフローチャートである。

まず、ステップＳ１６１０において、出版部５７０は、受信したインタレストパケットが、編集後コンテンツ保管部５６０に格納された編集後コンテンツのコンテンツ名（つまり、編集後コンテンツ保管部５６０に格納されたインデックス情報）を指定しているか否かを判断する。出版部５７０は、インタレストパケットが当該コンテンツ名を指定している場合（Ｓ１６１０：ＹＥＳ）、処理をステップＳ１６２０へ進める。また、出版部５７０は、インタレストパケットが当該コンテンツ名を指定していない場合（Ｓ１６１０：ＮＯ）、処理をステップＳ１６３０へ進める。

ステップＳ１６２０において、出版部５７０は、インタレストパケットが指定するコンテンツ名の編集後コンテンツのインデックス情報を、編集後コンテンツ保管部５６０から読み出す。そして、出版部５７０は、読み出したインデックス情報を、インタレストパケットの送信元へ返信して、処理を図７のフローチャートへ戻す。

ステップＳ１６３０において、出版部５７０は、受信したインタレストパケットが、編集後コンテンツ保管部５６０に格納された編集後ブロックのブロック名を指定しているか否かを判断する。出版部５７０は、インタレストパケットが当該ブロック名を指定している場合（Ｓ１６３０：ＹＥＳ）、処理をステップＳ１６４０へ進める。また、出版部５７０は、インタレストパケットが当該ブロック名を指定していない場合（Ｓ１６３０：ＮＯ）、処理をステップＳ１６５０へ進める。

ステップＳ１６４０において、出版部５７０は、インタレストパケットが指定するブロック名の編集後ブロックを、編集後コンテンツ保管部５６０から読み出す。そして、出版部５７０は、読み出した編集後ブロックを、インタレストパケットの送信元へ返信して、処理を図７のフローチャートへ戻す。

ステップＳ１６５０において、出版部５７０は、受信したインタレストパケットを破棄して、処理を図７のフローチャートへ戻す。

例えば、インタレストパケットの送信元には、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ＥＤ１／ｈａｓｈ／ＨＡＳＨ１／」、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｈａｓｈ／ＨＡＳＨ２／」、・・・というブロック名の、編集後ブロックが、返信される。また、これに先立って、インタレストパケットの送信元には、これらの編集後ブロックのブロック名および編集後コンテンツにおける位置と、編集後コンテンツのコンテンツ名「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ＥＤ１／」とを対応付けたインデックス情報、が返信される。この結果、ＣＣＮ網は、各所（例えば、転送端末２００）に、これらの編集後ブロックおよびインデックス情報をキャッシュした状態となる。

なお、上述の通り、編集端末５００がオリジナルコンテンツを取得した時点で、ＣＣＮ網には、オリジナルブロックが既にキャッシュされている。したがって、オリジナルブロックと同一内容の編集後ブロックのブロック名を指定したインタレストパケットは、後述するように、当該オリジナルブロックをキャッシュする転送端末２００で処理され、編集端末５００に到達しないこともある。

図７のステップＳ１７００において、オリジナルコンテンツ取得部５２０は、ユーザ操作等により処理の終了を指示されたか否かを判断する。オリジナルコンテンツ取得部５２０は、処理の終了を指示されていない場合（Ｓ１７００：ＮＯ）、処理をステップＳ１１００へ戻す。また、オリジナルコンテンツ取得部５２０は、処理の終了を指示された場合（Ｓ１７００：ＹＥＳ）、一連の処理を終了する。なお、この判断処理は、編集端末５００の他の機能部において行われてもよい。

このような動作により、編集端末５００は、編集後ブロックの内容がオリジナルブロックの内容と同一であるとき、オリジナルブロックの名前をそのまま用いて、編集後コンテンツのインデックス情報および編集後ブロックを出版することができる。

図１１は、転送端末２００の動作の一例を示すフローチャートである。

まず、ステップＳ２１００において、データ転送部２２０は、他の端末（オリジナル端末４００あるいは編集端末５００）から、コンテンツ（オリジナルコンテンツあるいは編集後コンテンツ）のインデックス情報およびブロックの出版があるか否を判断する。データ転送部２２０は、インデックス情報およびブロックの出版がある場合（Ｓ２１００：ＹＥＳ）、処理をステップＳ２２００へ進める。また、データ転送部２２０は、インデックス情報およびブロックの出版がない場合（Ｓ２１００：ＮＯ）、処理を後述のステップＳ２３００へ進める。

ステップＳ２２００において、データ転送部２２０は、ＦＩＢ部２３０に、出版されるコンテンツのコンテンツ名のプレフィックスと、転送先フェイスとの組を、設定する。転送先フェイスは、例えば、コンテンツ名のプレフィックスの通知を受信した仮想インタフェイスである。

図１２は、ＦＩＢ部２３０の内容の一例を示す図である。

図１２に示すように、ＦＩＢ部２３０に設定されるＦＩＢ６６０は、プレフィックス（Prefix）の最長一致（longest match）という名前空間６６１と、転送先フェイス（face）の識別情報６６２と、と対応付けて記述する。なお、ここでいうプレフィックスの最長一致とは、前方一致の範囲が最も長いものを指す。

データ転送部２２０は、通知されたプレフィックスに「／ｉｎｄｅｘ」を加えた名前空間６６１と、通知されたプレフィックスに「／ｈａｓｈ」を加えた名前空間６６２に対して、仮想インタフェイスの識別情報６６２を対応付ける。なお、これらの文字列の付加は、出版元によって行われてもよい。

例えば、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ＥＤ１／ｈａｓｈ」という名前空間６６１に対して、「２」という識別情報６６２が対応付けられている。これは、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ＥＤ１／ｈａｓｈ」という名前空間を指定したインタレストパケットを受信したとき、当該インタレストパケットを、第２のインタフェイス２１１−２から送出（転送）すべきことを意味する。

図１１のステップＳ２３００において、データ転送部２２０は、データパケットを受信したか否かを判断する。データ転送部２２０は、データパケットを受信した場合（Ｓ２３００：ＹＥＳ）、処理をステップＳ２４００へ進める。また、データ転送部２２０はデータパケットを受信していない場合（Ｓ２３００：ＮＯ）、処理を後述のステップＳ２５００へ進める。

ステップＳ２４００において、データ転送部２２０は、データパケットから、データパケットに格納されたデータおよび当該データの名前を取得する。そして、データ転送部２２０は、ＣＳ部２４０に、データパケットの複製を格納すると共に、取得したデータとその名前との組を設定する。そして、データ転送部２２０は、データパケットを、その宛先へと転送する。

データパケットに格納されるデータは、インデックス情報およびブロックを含む。したがって、データ転送部２２０は、例えば、オリジナルコンテンツのインデックス情報、オリジナルブロック、編集後コンテンツのインデックス情報、および編集後ブロックを取得し、ＣＳ部２４０にキャッシュする。

図１３は、ＣＳ部２４０の内容の一例を示す図である。

図１３に示すように、ＣＳ部２４０に設定されるＣＳ６７０は、名前（Name）の完全一致（exact match）という名前空間６７１と、データ（data）６７２とを、対応付けて記述する。

例えば、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｉｎｄｅｘ／ｔｉｍｅ００＿００＿０１」という名前空間６７１に対して、「ｏｒｉｇｉｎａｌ／ｈａｓｈ／ＨＡＳＨ１」というデータ６７２が対応付けられている。

「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｉｎｄｅｘ／ｔｉｍｅ００＿００＿０１」という名前空間は、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／」というコンテンツ名のオリジナルコンテンツの時間軸における、時刻０１の位置を示す。そして、「ｏｒｉｇｉｎａｌ／ｈａｓｈ／ＨＡＳＨ１」というデータは、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｈａｓｈ／ＨＡＳＨ１」というブロック名を示す。

すなわち、上記対応付けは、コンテンツ名と、ブロックの位置と、ブロック名との対応付けた、インデックス情報に相当する。

また、例えば、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｈａｓｈ／ＨＡＳＨ１」という名前空間６７１に対して、「ｖｉｄｅｏ１」というデータ６７２が対応付けられている。

「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｈａｓｈ／ＨＡＳＨ１」は、「ｖｉｄｅｏ１」というデータ本体のブロック名である。

すなわち、上記対応付けは、ブロックそのものに相当する。

なお、図１３において、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ＥＤ１／ｉｎｄｅｘ／ｔｉｍｅ００＿００＿０１」という名前空間６７１に対しても、「ｏｒｉｇｉｎａｌ／ｈａｓｈ／ＨＡＳＨ１」というデータ６７２が対応付けられている。これは、編集後ブロックに、元のオリジナルブロックと同一のブロック名が付与されたことを意味する。すなわち、編集後コンテンツの取得の際に、オリジナルブロックのブロック名が参照され、オリジナルブロックが取得され得ることを意味する。

図１１のステップＳ２５００において、インタレストパケット対応部２５０は、ＣＣＮ網からインタレストパケットを受信したか否かを判断する。インタレストパケット対応部２５０は、インタレストパケットを受信した場合（Ｓ２５００：ＹＥＳ）、処理をステップＳ２６００へ進める。また、インタレストパケット対応部２５０は、インタレストパケットを受信していない場合（Ｓ２５００：ＮＯ）、処理を後述のステップＳ２７００へ進める。

ステップＳ２６００において、インタレストパケット対応部２５０は、インタレストパケットに対して対応する処理であるインタレストパケット対応処理を行ってから、後述のステップＳ２７００へ処理を進める。

図１４は、インタレストパケット対応処理の一例を示すフローチャートである。

まず、ステップＳ２６１０において、インタレストパケット対応部２５０は、受信したインタレストパケットが指定する名前が、ＣＳ部２４０（図１３参照）に存在するか否かを判断する。インタレストパケット対応部２５０は、インタレストパケットが指定する名前がＣＳ部２４０に存在する場合（Ｓ２６１０：ＹＥＳ）、処理をステップＳ２６２０へ進める。インタレストパケット対応部２５０は、インタレストパケットが指定する名前がＣＳ部２４０に存在しない場合（Ｓ２６１０：ＮＯ）、処理をステップＳ２６３０へ進める。

ステップＳ２６２０において、インタレストパケット対応部２５０は、インタレストパケットが指定する名前に対応するデータを、ＣＳ部２４０から取得し、インタレストパケットの送信元へ返信する。そして、インタレストパケット対応部２５０は、受信したインタレストパケットを破棄して、処理を図１１のフローチャートへ戻す。

ステップＳ２６３０において、インタレストパケット対応部２５０は、受信したインタレストパケットが指定する名前のプレフィックスが、ＦＩＢ部２３０（図１２参照）に存在するか否かを判断する。インタレストパケット対応部２５０は、インタレストパケットが指定する名前のプレフィックスがＦＩＢ部２３０に存在する場合（Ｓ２６３０：ＹＥＳ）、処理をステップＳ２６４０へ進める。また、インタレストパケット対応部２５０は、インタレストパケットが指定する名前のプレフィックスがＦＩＢ部２３０に存在しない場合（Ｓ２６３０：ＮＯ）、処理をステップＳ２６５０へ進める。

ステップＳ２６４０において、インタレストパケット対応部２５０は、ＦＩＢ部２３０の設定内容に従って、受信したインタレストパケットを転送して、処理を図１１のフローチャートへ戻す。

ステップＳ２６５０において、インタレストパケット対応部２５０は、受信したインタレストパケットを破棄して、処理を図１１のフローチャートへ戻す。

図１１のステップＳ２７００において、インタレストパケット対応部２５０は、通信システム１００の管理サーバ（図示せず）等により処理の終了を指示されたか否かを判断する。インタレストパケット対応部２５０は、処理の終了を指示されていない場合（Ｓ２７００：ＮＯ）、処理をステップＳ２１００へ戻す。また、インタレストパケット対応部２５０は、処理の終了を指示された場合（Ｓ２７００：ＹＥＳ）、一連の処理を終了する。

例えば、転送端末２００に、図１２に示すＦＩＢ６６０および図１３に示すＣＳ６７０が設定されていたとする。

この状態において、転送端末２００は、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ＥＤ２／ｉｎｄｅｘ／ＡＬＬ」という名前空間を指定したインタレストパケットを受信したとする。

この名前空間は、ＣＳ６７０には存在しないが、ＦＩＢ６６０には存在し、「３」という転送先フェイスに対応付けられている。したがって、転送端末２００は、上記インタレストパケットを、第３のインタフェイス２１１−３から送出（転送）する。

また、転送端末２００は、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｉｎｄｅｘ／ＡＬＬ」という名前空間を指定したインタレストパケットを受信したとする。

この名前空間は、ＣＳ６７０に存在し、再生時刻毎に、「ｏｒｉｇｉｎａｌ／ｈａｓｈ／ＨＡＳＨ１」等のブロック名に対応付けられている。したがって、転送端末２００は、これらの対応関係を、インデックス情報として取得し、インタレストパケットの送信元へ返信する。

また、転送端末２００は、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ｏｒｉｇｉｎａｌ／ｈａｓｈ／ＨＡＳＨ１」という名前空間を指定したインタレストパケットを受信したとする。

この名前空間は、ＣＳ６７０に存在し、「ｖｉｄｅｏ１」というデータに対応付けられている。したがって、転送端末２００は、かかるデータ（ブロック）を取得し、インタレストパケットの送信元へ返信する。

また、「／ｅｄｉｔ＿ｓｅｒｖｉｃｅ／４ｋ＿ｍｏｖｉｅ／ｔｉｔｌｅ＿Ａ／ＥＤ３／ｉｎｄｅｘ／ＡＬＬ」という名前空間を指定したインタレストパケットを受信したとする。

この名前空間は、ＣＳ６７０およびＦＩＢ６６０のいずれにも存在しない。したがって、転送端末２００は、受信したインタレストパケットを破棄する。

このような動作により、転送端末２００は、ＣＣＮにおける、データのキャッシュ機能およびインタレストパケットに対する応答機能を発揮することができる。

なお、「ｉｎｄｅｘ／ＡＬＬ」という名前空間に対して、転送端末２００（および編集端末５００）は、まず、各ブロックの再生時刻を示す情報を返信し、再生時刻の指定を受けて、対応するブロック名を示す情報を返信するようにしてもよい。すなわち、転送端末２００は、インデックス情報の返信を、２段階に分けて行ってもよい。

図１５は、インデックス情報の返信を２段階に分けて行う場合の、編集端末５００とＣＣＮ網との間のパケットのやり取りの流れの一例を示すシーケンス図である。

まず、編集端末５００が、ＣＣＮ網に対して、コンテンツの「ｉｎｄｅｘ／ＡＬＬ」という名前空間を指定したインタレストパケットを送信する（Ｓ３１００）。これに対し、ＣＣＮ網の、該当するインデックス情報をキャッシュしている相手先（転送端末２００もしくはオリジナル端末４００）は、各ブロックの再生時刻のリストである、「ｔｉｍｅ００＿００＿０１」から「ｔｉｍｅ０１＿５９＿５９」を、返信する（Ｓ３２００）。

再生時刻のリストを受信した編集端末５００は、「ｉｎｄｅｘ／ｔｉｍｅ００＿００＿０１」等の、再生時刻の名前空間を指定したインタレストパケットを、ＣＣＮ網に送信する（Ｓ３３００）。これに対し、該当するインデックス情報をキャッシュしている相手先は、再生時刻に対応するブロックのブロック名である「ＨＡＳＨ１」を返信する（Ｓ３４００）。なお、この相手先は、再生時刻のリストを返信した相手先と同一とは限らない。

ブロック名を受信した編集端末５００は、「ｈａｓｈ／ＨＡＳＨ１」というブロック名を指定したインタレストパケットを、ＣＣＮ網に送信する（Ｓ３５００）。これに対し、該当するブロックをキャッシュしている相手先は、ブロック名に対応するブロックである「ｖｉｄｅｏ１」を返信する（Ｓ３６００）。なお、この相手先は、再生時刻のリストを返信した相手先や、ブロック名を返信した相手先と、同一とは限らない。

このように、インデックス情報およびブロック名に対応するデータパケットの伝送を２段階に分けて行うことにより、オリジナルブロックと編集後ブロックとが混在した編集後コンテンツを再生することが可能となる。

ここで、本実施の形態において、オリジナルコンテンツのキャッシュを編集後コンテンツの配信に活用される状況の一例について説明する。

図２において、まず、第１の編集端末５００−１が、オリジナル端末４００からオリジナルコンテンツである映画を取得し、オリジナルブロックをそのまま連結し直した編集後コンテンツである第１のダイジェストを生成したとする。そして、第３の編集端末５００−３が、この第１のダイジェストの取得を試みたとする。

この場合、映画は、第１の転送端末２００−１および第２の転送端末２００−２を伝送されたため、オリジナルブロックは、第２の転送端末２００−２に格納されている。そして、第１のダイジェストに含まれる編集後ブロックには、オリジナルブロックと同一の名前が付与されている。

したがって、第１のダイジェストに含まれる編集後ブロックの名前を指定したインタレストパケットには、第２の転送端末２００−２のキャッシュがヒットする。これにより、第３の編集端末５００−３は、第１の編集端末５００−１ではなく、第１の編集端末５００−１よりも近くに位置する第２の転送端末２００−２から、編集後ブロックを取得することができる。

また、その後、第４の編集端末５００−４が、オリジナルコンテンツである映画の取得を試みたとする。

この場合、第１のダイジェストは、第２の転送端末２００−２および第３の転送端末２００−３を伝送されたため、オリジナルブロックと同一内容の編集ブロックが、第３の転送端末２００−３に格納されている。そして、そして、第１のダイジェストに含まれる編集後ブロックには、オリジナルブロックと同一の名前が付与されている。

したがって、映画に含まれるオリジナルブロックの名前を指定したインタレストパケットの少なくとも一部には、第３の転送端末２００−３のキャッシュがヒットする。これにより、第４の編集端末５００−４は、オリジナル端末４００ではなく、オリジナル端末４００よりも近くに位置する第３の転送端末２００−３から、オリジナルブロックを取得することができる。

＜効果＞
以上のように、本実施の形態に係る通信システム１００は、編集端末５００において、編集後ブロックの内容がオリジナルブロックの内容と同一であるとき、オリジナルブロックの名前をそのまま用いて、編集後コンテンツのインデックス情報と編集後ブロックとを出版する。これにより、編集後コンテンツのインデックス情報に基づいて編集後ブロックを探索する際に、同一内容のオリジナルブロックのキャッシュにヒットし、これを取得することが可能となる。したがって、本実施の形態に係る通信システム１００は、オリジナルコンテンツのキャッシュを、編集後コンテンツの配信に活用することができる。

このような通信システム１００は、複数の編集者が、通信ネットワークを介して映像音声ストリームデータの編集を行う、いわゆるクラウド（crowd）編集システムに、好適である。すなわち、通信システム１００は、コンテンツ編集の処理負荷を、ネットワーク上に分散させることができる。

なお、編集端末５００が出版した編集後コンテンツ（ダイジェスト）は、オリジナルコンテンツ（映画）の出版者や、オリジナルコンテンツに対する編集の権限を有する他の編集者のみが閲覧できるように、コンテンツ取得に制限を設けるようにしてもよい。

この場合、例えば、編集端末５００は、暗号化した編集後コンテンツ（インデックス情報、あるいは、ブロック）を出版し、オリジナルコンテンツの出版者や他の編集者に対して、復号鍵を別途入手させる。復号鍵の受け渡しの手法としては、所定の暗号ソフトウェアで暗号化した電子メールによる送付、オフラインの記憶媒体での受け渡し、および、特定のメンバのみがアクセスできるサーバを経由した受け渡し等を採用することができる。

このように、特定のユーザにコンテンツの閲覧を制限したい場合、通信システム１００は、コンテンツそのものを暗号化し復号化するための鍵を適切に配布管理することが望ましい。なお、通信システム１００は、ＣＣＮ網全体を閉囲網として管理し、閉囲網にアクセスできる者の全てが、全てのコンテンツにアクセスできるようにしてもよい。

（実施の形態３）
本発明の実施の形態３は、編集後コンテンツに取得者制限を設けつつ、私的複製データをネットワーク全体として圧縮保持するようにした場合の、本発明の具体的態様の一例である。

＜通信システムの概要＞
図１６は、本実施の形態に係る通信システムの構成の一例を示すシステム構成図であり、実施の形態２の図２に対応するものである。図２と対応する部分には同一の数字を用いた符号を付し、実施の形態２と共通する部分についての説明を適宜省略する。

図１６において、通信システム１００ａは、第１〜第３の転送端末２００ａ−１〜２００ａ−３を配置した通信ネットワーク３００ａと、通信ネットワーク３００ａに接続されたオリジナル端末４００ａおよび編集端末５００ａを有する。編集端末５００ａには、ディスプレイ装置７１０ａが接続されている。また、通信ネットワーク３００ａには、携帯端末７２０ａおよびフィルタ管理サーバ７３０ａが接続されている。なお、通信システム１００ａは、実施の形態２と同様に、ＣＣＮ網を形成している。

オリジナル端末４００ａは、決まった時間に、映像音声コンテンツを、ＣＣＮ網に放送する機能を有する、オリジナル端末４００ａは、例えば、いわゆるネット放送局のサーバである。

編集端末５００ａは、オリジナル端末４００ａから決まった時間に放送される映像音声コンテンツを取得、録画、および再生する機能を有する。編集端末５００ａは、例えば、ネット放送局の放送を受信してテレビジョン装置に出力するための、ＳＴＢ（Set Top Box）である。

なお、編集端末５００ａのユーザは、オリジナル端末４００ａが放送する映像音声コンテンツを取得し、私的複製を行う権限（以下、「コンテンツ利用権」という）を有しているものとする。コンテンツ利用権は、つまり、オリジナルコンテンツおよびこのオリジナルコンテンツから生成された編集後コンテンツを、取得、格納、および再生する権限である。

ディスプレイ装置７１０ａは、画像表示および音声出力を行う装置である。ディスプレイ装置７１０ａは、例えば、テレビジョン装置である。

携帯端末７２０ａは、編集端末５００ａが録画した映像音声コンテンツを、通信ネットワーク３００ａを介して編集端末５００ａから取得し、再生する装置である。携帯端末７２０ａは、例えば、編集端末５００ａのユーザ等、コンテンツ利用権を有するユーザが使用するスマートフォンあるいはタブレット型端末である。

フィルタ管理サーバ７３０ａは、編集端末５００ａが録画した映像音声コンテンツを、携帯端末７２０ａしか取得できないようにするフィルタを、第１〜第３の転送端末２００ａ−１〜２００ａ−３に対して動的に挿入する装置である。このフィルタの詳細については、後述する。

第１〜第３の転送端末２００ａ−１〜２００ａ−３は、実施の形態２の転送端末２００と同様に、ＣＣＮにおけるデータのキャッシュ機能およびインタレストパケットに対する応答機能を有する。但し、キャッシュ機能およびインタレストパケットに対する応答機能更に、フィルタ管理サーバ７３０ａにより設定されたフィルタを用いて、インタレストパケットに対する応答機能を制限する。

図１７は、通信システム１００ａにおいて用いられる編集後コンテンツの名前空間の設計例を示す図である。

通信システム１００ａには、例えば、図１７に示すような、編集後コンテンツの名前空間８１０と、編集後ブロックの名前空間８２０とが、設定される。

編集後コンテンツの名前空間８１０は、プレフィックス部８１１と、データ部８１２、８１３とから成る。また、編集後ブロックの名前空間８２０は、プレフィックス部８２１と、データ部８２２、８２３とから成る。但し、編集後ブロックの名前空間８２０のプレフィックス部８２１は、編集後コンテンツの名前空間８１０のプレフィックス部８１２とは異なっている。

このような通信システム１００ａは、コンテンツ利用権を有するユーザが、編集後コンテンツを格納する編集端末５００ａとは別の場所で、編集後コンテンツを取得して閲覧することを可能にする。また、通信システム１００ａは、編集後コンテンツの取得を、コンテンツ利用権を有するユーザのみに制限することができる。

但し、この制限を、例えば、インデックス情報に対するインタレストパケットと、ブロックに対するインタレストパケットとの両方に対するフィルタリングによって実現しようとすると、処理が煩雑化する。

一方で、ブロック名が推測困難なものであれば、インデックス情報の取得に制限を掛けさえすれば、編集後コンテンツの取得を、コンテンツ利用権を有するユーザのみに制限することができる。

また、同一内容のブロックに対して、同一のブロック名が付与されるようになっていれば、ブロックのキャッシュ率を向上させることができる。

更に、オリジナルブロックと編集後ブロックとで、同一の内容となる確率を上げれば、ブロックのキャッシュ率を更に向上させることができる。

そこで、本実施の形態に係る通信システム１００ａでは、オリジナル端末４００ａおよび編集端末５００ａの全てにおいて、実施の形態２と同様のルールで、オリジナルコンテンツの実時間ストリームを分割し、ブロック名を決定する。

＜ブロック名の決定手法＞
ここで、ブロック名の決定手法の詳細について説明する。

ブロック名の決定に用いられる所定のハッシュ関数は、ストリームの長さを勘案して、ブロック名の重複が発生する確率が十分小さくなる範囲で選択された、ハッシュ関数である。

例えば、所定のハッシュ関数は、１５００バイトのブロックから１２８バイトのハッシュ値を算出するというように、データ長を短くする性質を有するものが望ましい。ハッシュ値の長さは、ストリームの長さに応じて可変であってもよいが、全ての編集端末５００ａの間で、どのようなハッシュ関数を用いたかを示す情報が、別途、共有される必要がある。かかる情報共有は、例えば、ストリームのメタ情報等を用いて行われる。

オリジナル端末４００ａおよび編集端末５００ａは、具体的には、例えば、以下の手順で、ブロックのブロック名を決定し、インデックス情報およびブロックを出版する。なお、かかる手順は、勿論、実施の形態２にも適用することができる。

オリジナル端末４００ａおよび編集端末５００ａは、過去にブロック名として算出したハッシュ値（変数ＢＬＫ＿ＨＡＳＨ）を、メモリ上のデータベース（図示せず）に格納する。このとき、オリジナル端末４００ａおよび編集端末５００ａは、既に同一のハッシュ値（ＢＫＬ＿ＨＡＳＨ）が格納されている場合、メモリ上のフラグ（ＤＵＰ）を「１」に変更する。

オリジナル端末４００ａおよび編集端末５００ａは、算出されたハッシュ値（ＢＫＬ＿ＨＡＳＨ）を文字列に変換して、ブロック名（Ｂｌｋ＿ｎａｍｅ）として、記録する。このとき、オリジナル端末４００ａおよび編集端末５００ａは、フラグ（ＤＵＰ）が「１」の場合、ブロック名を、「ＤＵＰ／」＋［ｎ］＋「＿Ｂｌｋ＿ｎａｍｅ」とする。ここで、［ｎ］は、同じブロック名（Ｂｌｋ＿ｎａｍｅ）の出現する回数を記録した整数を、文字列に変換したものである。これにより、内容が同一の複数のブロックを、区別して扱うことが可能となる。

オリジナル端末４００ａおよび編集端末５００ａは、決定したブロック名と再生時刻との組の記録形式を決定し、ＣＣＮ網に出版する。すなわち、オリジナル端末４００ａおよび編集端末５００ａは、「ｉｎｄｅｘ／」の名前空間の要素である、「ｔｉｍｅ」＋［再生時刻］という形式の名前に対応するデータとして、ブロック名（Ｂｌｋ＿ｎａｍｅ）を保持する。そして、オリジナル端末４００ａおよび編集端末５００ａは、「ｉｎｄｅｘ／ＡＬＬ」の名前空間に対する応答や、「ｉｎｄｅｘ／ＬＡＴＥＳＴ」に対する応答を準備する。

なお、［再生時刻］は、実時間ストリームの再生時刻を文字列として表現したものであり、例えば、時間：分：秒：ミリ秒、といった形式の文字列である。「ＡＬＬ」を指定したインタレストパケットに対する応答としては、上述の通り、「ｉｎｄｅｘ／」の空間に格納された全ての「ｔｉｍｅ」＋［再生時刻］の名前のリストが返信される。また、「Ｉｎｄｅｘ／ＬＡＴＡＳＴ」を指定したインタレストパケットに対する応答としては、上述の通り、［再生時刻］の最大値に対応する名前が返信される。なお、ＡＬＬやＬＡＴＥＳＴといった特別な名前に対する応答には、転送端末上でのキャッシュを防ぐ特別なフラグを付与して伝送してもよい。そして、各転送端末（ルータ）は、そのフラグを解釈し、キャッシュを抑止してもよい。あるいは、転送端末の実装基準として、特別な名前に対する応答はキャッシュしないように規定されていてもよい。

＜各装置の構成および動作＞
次に、編集端末５００ａおよび転送端末２００ａの構成および動作について説明する。

図１８は、編集端末５００ａの構成の一例を示すブロック図であり、実施の形態２の図５に対応するものである。図５と同一部分には同一符号を付し、これについての説明を省略する。

図１８において、編集端末５００ａは、図５の構成に加えて、ディスプレイインタフェイス（ＩＦ）部５８０ａおよび録画予約情報保持部５９０ａを有する。なお、本実施の形態において、編集端末５００ａは、必ずしも、編集後コンテンツの内容を、オリジナルコンテンツとは異なる内容に編集しなくてもよい。例えば、編集後コンテンツの内容は、オリジナルコンテンツの内容と全く同一ということもあり得る。

この場合、編集端末５００ａは、単に、オリジナルコンテンツの複製として、編集後コンテンツを生成する。そして、名前決定部５５０は、編集後コンテンツ（つまり、オリジナルコンテンツのコピー）のコンテンツ名を、オリジナルコンテンツのコンテンツ名から変更し、オリジナルブロックのブロック名を、編集後ブロックのブロック名としてそのまま転用する。

ディスプレイインタフェイス部５８０ａは、ディスプレイ装置７１０ａ（図１６参照）に接続し、映像音声ストリームの映像データおよび音声データを、ディスプレイ装置７１０ａに送信する。ディスプレイインタフェイス部５８０ａは、例えば、ＨＤＭＩ（High-Definition Multimedia Interface、登録商標）インタフェイスを含む。

録画予約情報保持部５９０ａは、オリジナル端末４００ａ（図１６参照）が放送する予定のオリジナルコンテンツ（映像音声プログラム）に関する情報（以下「オリジナルコンテンツ情報」という）を、通信部５１０を介してＣＣＮ網から取得し、保持する。

オリジナルコンテンツ情報は、オリジナルコンテンツのコンテンツ名、実時間ストリームの長さ、タイトル、放送時間帯、および内容の概要を説明する文章等を含むデータ群である。オリジナルコンテンツ情報は、例えば、従来のテレビジョン放送で用いられているＥＰＧ（Electronic Program Guide）に記載されている情報に類似したものである。

録画予約情報保持部５９０ａは、編集端末５００ａのユーザ（以下、単に「ユーザ」という）に対し、例えばディスプレイインタフェイス部５８０ａを介して、オリジナルコンテンツ情報を提示する。録画予約情報保持部５９０ａは、ユーザから、録画すべきオリジナルコンテンツを決定する操作を受け付ける。そして、録画予約情報保持部５９０ａは、決定されたオリジナルコンテンツのコンテンツ名を、取得の対象となるコンテンツのコンテンツ名として設定する。また、録画予約情報保持部５９０ａは、決定されたオリジナルコンテンツの放送時間帯から、録画開始時刻および録画終了時刻を設定する。

そして、録画予約情報保持部５９０ａは、設定した録画開始時刻が到来すると、オリジナルコンテンツ取得部５２０に対し、オリジナルコンテンツの取得開始を指示する。また、録画予約情報保持部５９０ａは、設定した録画終了時刻が到来すると、オリジナルコンテンツ取得部５２０に対し、オリジナルコンテンツの取得終了を指示する。

なお、編集端末５００ａの各部は、オリジナルコンテンツの取得中（映像音声プログラムの進行中）に、適宜、オリジナルコンテンツの表示、および、編集後コンテンツの生成（つまり、複製）を行ってもよい。

また、録画予約情報保持部５９０ａは、例えば、出版部５７０に対して、オリジナルコンテンツの取得中、あるいは、取得完了後等の所定のタイミングで、編集後コンテンツの出版を指示してもよい。

出版部５７０は、編集後コンテンツのインデックス情報を出版する毎に、元のオリジナルコンテンツのコンテンツ利用権に関する情報を、当該インデックス情報と対応付けて、フィルタ管理サーバ７３０ａに送信することが望ましい。

コンテンツ利用権に関する情報は、例えば、ユーザの識別情報と、編集後コンテンツの識別情報（例えば、コンテンツ名）と、を含む。ユーザの識別情報とは、例えば、ユーザに割り当てられた米国のソーシャルセキュリティ番号や、ユーザが所有するクレジットカードのカード番号である。

図１６の携帯端末７２０ａは、例えば、録画ブロックデータ取得部およびコンテンツ取得表示部を有する（図示せず）。

録画ブロックデータ取得部は、ユーザ操作等を受けて、編集後コンテンツのコンテンツ名を指定したインタレストパケットをＣＣＮ網に送信し、編集後コンテンツの編集後ブロックを取得する。編集後ブロックの取得手順は、実施の形態２で説明したオリジナルブロックの取得手順と同様である。

但し、録画ブロックデータ取得部は、ユーザの識別情報を保持している。そして、録画ブロックデータ取得部は、編集後コンテンツの取得に先立ち、フィルタ管理サーバ７３０ａ（図１６参照）に対して、携帯端末７２０ａが直接的あるいは間接的に接続している転送端末２００ａに、上述のフィルタを挿入することを要求する。この要求は、コンテンツ利用権に関する情報（ユーザの識別情報および編集後コンテンツの識別情報）の送信を含む。

その後、録画ブロックデータ取得部は、編集後コンテンツのインデックス情報の返信を要求するインタレストパケットに対応付けて、かかる情報をＣＣＮ網に送信する。例えば、録画ブロックデータ取得部は、上記インタレストパケットのヘッダ部分に、暗号化したユーザの識別情報を記述する。

コンテンツ取得表示部は、取得された編集後ブロックを、ユーザが閲覧（視聴）することが可能な状態の編集後コンテンツに組み立て、当該編集後コンテンツを再生する。

フィルタ管理サーバ７３０ａは、上述の携帯端末７２０ａからの要求に応じて、携帯端末７２０ａが接続している転送端末２００ａに対し、特定の名前空間へのインタレストパケットの通過を許可するフィルタを挿入するように指示する。この際、フィルタ管理サーバ７３０ａは、かかる要求が適切か否かを判断し、適切である場合にのみ、上記フィルタの挿入を行う。携帯端末７２０ａからの要求が適切である場合とは、例えば、携帯端末７２０ａから受信したコンテンツ利用権に関する情報と、編集端末５００ａから受信したコンテンツ利用権に関する情報とが、一致している場合である。

そして、フィルタ管理サーバ７３０ａは、上述の携帯端末７２０ａからの要求が適切である場合、転送端末２００ａにフィルタを追加（挿入）する。かかるフィルタは、すなわち、編集後コンテンツのｉｎｄｅｘ部の対応関係が正しい場合に、録画コンテンツのｉｎｄｅｘ部のインタレストパケットを通過させるようなフィルタである。具体的には、フィルタ管理サーバ７３０ａは、例えば、コンテンツ利用権に関する情報（ユーザの識別情報および編集後コンテンツの識別情報）を、転送端末２００ａへ送信する。

図１９は、転送端末２００ａの構成の一例を示すブロック図であり、実施の形態２の図６に対応するものである。図６と同一部分には同一符号を付し、これについての説明を省略する。

図１９において、転送端末２００ａは、図６の構成に加えて、フィルタ部２６０ａを有する。

フィルタ部２６０ａは、転送通信部２１０と、データ転送部２２０およびインタレストパケット対応部２５０との間に配置されている。フィルタ部２６０ａは、フィルタ管理サーバ７３０ａからの、上記フィルタの挿入を受け、挿入されたフィルタを使用する。具体的には、フィルタ部２６０ａは、フィルタ管理サーバ７３０ａから、コンテンツ利用権に関する情報（ユーザの識別情報および編集後コンテンツの識別情報）を受信し、かかる情報に基づいて、上記フィルタの機能を発揮する。

なお、本実施の形態において、このフィルタは、上述の通り、編集端末５００ａが録画した映像音声コンテンツを、携帯端末７２０ａしか取得できないようにするフィルタである。すなわち、フィルタは、転送あるいは応答するインタレストパケットの条件として、インタレストパケットが要求する編集後コンテンツの識別情報と、当該インタレストパケットに付与されているユーザの識別情報との正しい組み合わせを、定義するものである。この条件を満たすインタレストパケットは、編集後コンテンツのコンテンツ利用権を有するユーザによって送信されたパケットである。

なお、ユーザ以外の第三者が、ユーザの識別情報を不正に用いて、編集後コンテンツのコンテンツ名を指定したインタレストパケットを送信する可能性がある。したがって、フィルタ部２６０ａは、イングレスフィルタリング等の送信元認証技術を用いて、このような不正に送信されたインタレストパケットを判別し、廃棄することが望ましい。

図２０は、転送端末２００ａのインタレストパケット対応処理の一例を示すフローチャートであり、実施の形態２の図１４に対応するものである。図１４と同一部分には同一ステップ番号を付し、これについての説明を省略する。

まず、ステップＳ２６０１ａにおいて、フィルタ部２６０ａは、受信したインタレストパケットが編集後コンテンツのコンテンツ名を指定するものであるか否かを判断する。すなわち、フィルタ部２６０ａは、編集後コンテンツのインデックス情報の返信を要求するインタレストパケットを受信したかどうかを判断する。

フィルタ部２６０ａは、受信したインタレストパケットが編集後コンテンツのコンテンツ名を指定するものではない場合（Ｓ２６０１ａ：ＮＯ）、受信したインタレストパケットをインタレストパケット対応部２５０へ出力し、処理をステップＳ２６１０へ進める。編集後コンテンツのコンテンツ名を指定するものではない場合とは、例えば、編集後コンテンツを構成する編集後ブロックのブロック名を指定する場合である。また、フィルタ部２６０ａは、受信したインタレストパケットが編集後コンテンツのコンテンツ名を指定するものである場合（Ｓ２６０１ａ：ＹＥＳ）、処理をステップＳ２６０２ａへ進める。

ステップＳ２６０２ａにおいて、フィルタ部２６０ａは、編集後コンテンツのインデックス情報の要求元のユーザが、編集後コンテンツのコンテンツ利用権を有するか否かを判断する。すなわち、転送端末２００ａは、受信したインタレストパケットが要求する編集後コンテンツの識別情報と、当該インタレストパケットに付与されているユーザの識別情報との組が、フィルタの条件にマッチするか否かを判断する。

フィルタ部２６０ａは、編集後コンテンツのインデックス情報の要求元のユーザが、編集後コンテンツのコンテンツ利用権を有する場合（Ｓ２６０２ａ：ＹＥＳ）、処理をステップＳ２６１０へ進める。また、フィルタ部２６０ａは、編集後コンテンツのインデックス情報の要求元のユーザが、編集後コンテンツのコンテンツ利用権を有しない場合（Ｓ２６０２ａ：ＮＯ）、処理をステップＳ２６５０へ進める。

そして、処理がステップＳ２６１０へ進んだ場合、インタレストパケット対応部２５０は、フィルタ部２６０ａを介して、実施の形態２で説明したインタレストパケット対応処理を行う。また、処理がステップＳ２６５０へ進んだ場合、インタレストパケット対応部２５０は、受信したインタレストパケットを破棄する。なお、このインタレストパケットの破棄は、フィルタ部２６０ａで行われてもよい。

このように、転送端末２００ａは、インデックス情報を要求するインタレストパケットについては、コンテンツ利用権に基づくフィルタリングを行い、編集後ブロックを要求するインタレストパケットについては、かかるフィルタリングを行わない。

上述の通り、編集端末５００ａは、編集後ブロック（分割ブロックのままのものを含む）に対して、ブロックの内容に応じて一意に決まるブロック名を決定する。更に、かかるブロック名は、ブロックを取得したことのある端末（ユーザ）にしか推測することができない名前となっている。

したがって、既にオリジナルコンテンツ、編集後コンテンツ、あるいはインデックス情報を取得してない限り、編集後ブロックを取得することは困難である。これにより、通信システム１００ａは、インデックス情報を要求するインタレストパケットについてのフィルタリングのみで、簡易な構成および処理によって、編集後コンテンツに取得者制限を設けることができる。

また、上述の通り、編集端末５００ａは、編集後ブロックの基となる分割ブロックを、オリジナルブロックと同一の内容となるように生成する。そして、編集端末５００ａは、編集後ブロック（分割ブロックのままのものを含む）に対して、オリジナルブロックのブロック名と同一のルールで、ブロックの内容に応じて一意に決まるブロック名を決定する。

したがって、複数のユーザがそれぞれコンテンツ利用権を有するコンテンツに、内容が同一のブロックが共通して含まれる可能性が高くなり、かかるブロックに対するキャッシュヒット率が向上する。これにより、通信システム１００ａは、編集後コンテンツに取得者制限を設けつつ、コンテンツのキャッシュが活用される頻度を向上させ、編集後コンテンツが効率よく配信されるようにすることができる。

以上のように、本実施の形態に係る通信システム１００ａは、編集後ブロックを、オリジナルブロックと同一の内容となるように生成し、オリジナルブロックのブロック名と同一のルールで、ブロックの内容に応じて一意に決まるブロック名を決定する。また、本実施の形態に係る通信システム１００ａは、インデックス情報を要求するインタレストパケットに対してのみ、コンテンツ利用権に基づくフィルタリングを行う。

これにより、本実施の形態に係る通信システム１００ａは、編集後コンテンツに取得者制限を設ける場合であっても、オリジナルコンテンツ（および他の編集後コンテンツ）のキャッシュが、編集後コンテンツの配信に活用されるようにすることができる。

すなわち、本実施の形態に係る通信システム１００ａは、一つの動画コンテンツを様々なカットシーンの組み合わせとして編集したノンリニア編集した結果をネットワークで共有するようなユースケースにおいて、ＣＣＮ網側で高効率にキャッシュヒットすることが期待できる。また、一つのコンテンツを多数の受信者が私的複製するようなユースケースにおいても、同様である。この結果、本実施の形態に係る通信システム１００ａは、ルータ上のキャッシュ容量やネットワークの回線帯域を節約することができ、全体として高効率なシステムを構成することができる。

なお、インデックス情報を要求するインタレストパケットに対するフィルタリングの手法およびその設定手法は、上述の例に限定されない。例えば、オリジナル端末４００ａあるいは編集端末５００ａが、各転送端末２００ａに直接にフィルタを設定してもよい。

なお、以上説明した各実施の形態において、編集後コンテンツは、他の編集後コンテンツのオリジナルコンテンツとして扱うことが可能である。このような場合でも、元のオリジナルコンテンツのブロック名は、編集後コンテンツを編集して得られる他の編集後コンテンツにおいても、維持され得ることになる。

また、オリジナルコンテンツおよび編集後コンテンツの種別は、上述の例に限定されない。オリジナルコンテンツおよび編集後コンテンツは、例えば、静画像データ、３次元空間データ、あるいは、テキストデータであってもよい。

本開示の通信端末は、コンテンツ中心型ネットワークを構成する通信端末であって、名前を有するオリジナルブロックにより構成されるオリジナルコンテンツを取得するオリジナルコンテンツ取得部と、前記オリジナルコンテンツから、編集後ブロックにより構成される編集後コンテンツを生成するコンテンツ編集部と、前記編集後コンテンツの名前および前記編集後ブロックの名前を決定する名前決定部と、前記編集後コンテンツのインデックス情報と前記編集後ブロックとを出版する出版部と、を有し、前記名前決定部は、前記編集後ブロックの内容が前記オリジナルブロックの内容と同一であるとき、前記オリジナルブロックの前記名前を、前記編集後ブロックの名前として決定する。

なお、上記通信端末は、前記編集後コンテンツの前記インデックス情報と前記編集後ブロックとを格納する編集後コンテンツ保管部、を更に有し、前記出版部は、前記編集後コンテンツの前記名前を指定したインタレストパケットが送られてきたとき、前記編集後コンテンツの前記インデックス情報を返信し、前記編集後ブロックの前記名前を指定したインタレストパケットが送られてきたとき、前記編集後ブロックを返信してもよい。

また、上記通信端末において、前記オリジナルコンテンツ取得部は、オリジナルコンテンツの名前を指定したインタレストパケットを送信して、前記オリジナルコンテンツのインデックス情報を取得し、前記オリジナルコンテンツの前記インデックス情報に含まれる前記オリジナルブロックの前記名前を指定したインタレストパケットを送信して、前記オリジナルブロックを取得し、上記通信端末は、取得した前記オリジナルブロックを格納するオリジナルコンテンツ保管部、を更に有してもよい。

また、上記通信端末において、前記コンテンツ編集部は、ユーザから前記オリジナルコンテンツに対する編集を受け付けて、前記編集後コンテンツを生成してもよい。

また、上記通信端末において、前記オリジナルコンテンツは、実時間ストリームデータを含み、前記コンテンツ編集部は、前記オリジナルコンテンツの前記実時間ストリームデータを、前記オリジナルブロックと同一のサイズで分割して得られる、分割ブロックを取得するブロックサイズ分割部と、前記分割ブロックと内容が同一の前記編集後ブロック、または、前記分割ブロックを編集して得られる前記編集後ブロックに基づいて、前記編集後コンテンツを生成するブロック編集部と、を有してもよい。

また、上記通信端末において、前記オリジナルブロックは、前記オリジナルコンテンツの前記実時間ストリームデータを、前記実時間ストリームデータの時間軸における所定の時刻を基準として、前記時間軸に沿って所定のサイズで分割して得られるデータであり、前記オリジナルコンテンツ取得部は、前記オリジナルコンテンツを構成する全ての前記オリジナルブロックを取得し、前記ブロックサイズ分割部は、前記オリジナルコンテンツの前記実時間ストリームデータを、前記所定の時刻を基準として前記時間軸に沿って前記所定のサイズで分割して、前記分割ブロックを取得してもよい。

また、上記通信端末において、前記ブロック編集部は、前記ユーザから前記分割ブロックに対する編集を受け付けて、前記編集後ブロックを生成し、前記ユーザから前記編集後ブロックの配置の決定を受け付けて、前記編集後コンテンツを生成してもよい。

また、上記通信端末において、前記名前決定部は、前記編集後ブロックの内容が前記オリジナルブロックの内容と同一ではないとき、前記編集後ブロックに対して所定のハッシュ関数を適用して得られるハッシュ値を、前記編集後ブロックの前記名前として決定してもよい。

本開示の転送端末は、上記通信端末に記載の通信端末を含む前記コンテンツ中心型ネットワークを構成する転送端末であって、インタレストパケットの送信元と前記インタレストパケットが指定するデータを格納する相手先との間において、前記インタレストパケットおよび前記データの転送を行うデータ転送部と、前記データ転送部によって前記データが転送されとき、当該データの複製を格納するデータキャッシュ部と、前記データキャッシュ部に前記編集後コンテンツの前記インデックス情報が格納され、前記編集後コンテンツの前記名前を指定したインタレストパケットが送られてきたとき、前記編集後コンテンツの前記インデックス情報を返信し、前記データキャッシュ部に前記編集後ブロックが格納され、前記編集後ブロックの前記名前を指定したインタレストパケットが送られてきたとき、前記編集後ブロックを返信するインタレストパケット対応部と、前記データ転送部における、前記編集後コンテンツの前記名前を指定した前記インタレストパケットの転送、および、前記インタレストパケット対応部における、当該インタレストパケットに対する前記編集後コンテンツの前記インデックス情報の返信を、当該インタレストパケットの前記送信元のユーザが前記編集後コンテンツを取得する権限を有する場合にのみ行われるように制限するフィルタ部と、を有する。

本開示のコンテンツ出版方法は、コンテンツ中心型ネットワークにおけるコンテンツ出版方法であって、名前を有するオリジナルブロックにより構成されるオリジナルコンテンツを取得するステップと、前記オリジナルコンテンツから、編集後ブロックにより構成される編集後コンテンツを生成するステップと、前記編集後コンテンツの名前および前記編集後ブロックの名前を決定するステップと、前記編集後コンテンツのインデックス情報と前記編集後ブロックとを出版するステップと、を有し、前記編集後ブロックの名前を決定するステップは、前記編集後ブロックの内容が前記オリジナルブロックの内容と同一であるとき、前記オリジナルブロックの前記名前を、前記編集後ブロックの名前として決定する。

本発明は、オリジナルコンテンツのキャッシュが編集後コンテンツの配信に活用されるようにすることができる、通信端末、転送端末、およびコンテンツ出版方法として有用である。

１００、１００ａ 通信システム
２００、２００ａ 転送端末
２１０ 転送通信部
２１１ インタフェイス
２２０ データ転送部
２３０ ＦＩＢ部
２４０ ＣＳ部
２５０ インタレストパケット対応部
２６０ａ フィルタ部
３００、３００ａ 通信ネットワーク
４００、４００ａ オリジナル端末
５００、５００ａ 編集端末（通信端末）
５１０ 通信部
５２０ オリジナルコンテンツ取得部
５３０ オリジナルコンテンツ保管部
５４０ コンテンツ編集部
５４１ ブロックサイズ分割部
５４２ ブロック編集部
５５０ 名前決定部
５６０ 編集後コンテンツ保管部
５７０ 出版部
５８０ａ ディスプレイインタフェイス部
５９０ａ 録画予約情報保持部
７１０ａ ディスプレイ装置
７２０ａ 携帯端末
７３０ａ フィルタ管理サーバ

Claims (7)

1. コンテンツ中心型ネットワーク（Content Centric Network）を構成する通信端末であって、
   名前を有するオリジナルブロックにより構成されるオリジナルコンテンツを取得するオリジナルコンテンツ取得部と、
   前記オリジナルコンテンツから、編集後ブロックにより構成される編集後コンテンツを生成するコンテンツ編集部と、
   前記編集後コンテンツの名前および前記編集後ブロックの名前を決定する名前決定部と、
   前記編集後コンテンツのインデックス情報と前記編集後ブロックとを出版する出版部と、を有し、
   前記名前決定部は、
   前記編集後ブロックの内容が前記オリジナルブロックの内容と同一であるとき、前記オリジナルブロックの前記名前を、前記編集後ブロックの名前として決定する、
   通信端末。
2. 前記編集後コンテンツの前記インデックス情報と前記編集後ブロックとを格納する編集後コンテンツ保管部、を更に有し、
   前記出版部は、
   前記編集後コンテンツの前記名前を指定したインタレストパケットが送られてきたとき、前記編集後コンテンツの前記インデックス情報を返信し、前記編集後ブロックの前記名前を指定したインタレストパケットが送られてきたとき、前記編集後ブロックを返信する、
   請求項１に記載の通信端末。
3. 前記オリジナルコンテンツ取得部は、
   オリジナルコンテンツの名前を指定したインタレストパケットを送信して、前記オリジナルコンテンツのインデックス情報を取得し、前記オリジナルコンテンツの前記インデックス情報に含まれる前記オリジナルブロックの前記名前を指定したインタレストパケットを送信して、前記オリジナルブロックを取得し、
   取得した前記オリジナルブロックを格納するオリジナルコンテンツ保管部、を更に有する、
   請求項１に記載の通信端末。
4. 前記コンテンツ編集部は、
   ユーザから前記オリジナルコンテンツに対する編集を受け付けて、前記編集後コンテンツを生成する、
   請求項３に記載の通信端末。
5. 前記オリジナルコンテンツは、実時間ストリームデータを含み、
   前記コンテンツ編集部は、
   前記オリジナルコンテンツの前記実時間ストリームデータを、前記オリジナルブロックと同一のサイズで分割して得られる、分割ブロックを取得するブロックサイズ分割部と、
   前記分割ブロックと内容が同一の前記編集後ブロック、または、前記分割ブロックを編集して得られる前記編集後ブロックに基づいて、前記編集後コンテンツを生成するブロック編集部と、を有する、
   請求項４に記載の通信端末。
6. 前記オリジナルブロックは、前記オリジナルコンテンツの前記実時間ストリームデータを、前記実時間ストリームデータの時間軸における所定の時刻を基準として、前記時間軸に沿って所定のサイズで分割して得られるデータであり、
   前記オリジナルコンテンツ取得部は、
   前記オリジナルコンテンツを構成する全ての前記オリジナルブロックを取得し、
   前記ブロックサイズ分割部は、
   前記オリジナルコンテンツの前記実時間ストリームデータを、前記所定の時刻を基準として前記時間軸に沿って前記所定のサイズで分割して、前記分割ブロックを取得する、
   請求項５に記載の通信端末。
7. コンテンツ中心型ネットワーク（Content Centric Network）におけるコンテンツ出版方法であって、
   名前を有するオリジナルブロックにより構成されるオリジナルコンテンツを取得するステップと、
   前記オリジナルコンテンツから、編集後ブロックにより構成される編集後コンテンツを生成するステップと、
   前記編集後コンテンツの名前および前記編集後ブロックの名前を決定するステップと、
   前記編集後コンテンツのインデックス情報と前記編集後ブロックとを出版するステップと、を有し、
   前記編集後ブロックの名前を決定するステップは、
   前記編集後ブロックの内容が前記オリジナルブロックの内容と同一であるとき、前記オリジナルブロックの前記名前を、前記編集後ブロックの名前として決定する、
   コンテンツ出版方法。

Images