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

通信端末、およびコンテンツ出版方法 Download PDF

Info

Publication number
JP6213914B2
JP6213914B2 JP2013201724A JP2013201724A JP6213914B2 JP 6213914 B2 JP6213914 B2 JP 6213914B2 JP 2013201724 A JP2013201724 A JP 2013201724A JP 2013201724 A JP2013201724 A JP 2013201724A JP 6213914 B2 JP6213914 B2 JP 6213914B2
Authority
JP
Japan
Prior art keywords
content
block
original
edited
name
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2013201724A
Other languages
English (en)
Other versions
JP2015069314A (ja
Inventor
衛一 村本
衛一 村本
孝弘 米田
孝弘 米田
一暢 小西
一暢 小西
遼太 大西
遼太 大西
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Management Co Ltd
Original Assignee
Panasonic Intellectual Property Management Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Management Co Ltd filed Critical Panasonic Intellectual Property Management Co Ltd
Priority to JP2013201724A priority Critical patent/JP6213914B2/ja
Priority to US14/491,030 priority patent/US20150095483A1/en
Publication of JP2015069314A publication Critical patent/JP2015069314A/ja
Application granted granted Critical
Publication of JP6213914B2 publication Critical patent/JP6213914B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management
    • G06Q10/101Collaborative creation, e.g. joint development of products or services
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Economics (AREA)
  • Theoretical Computer Science (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)

Description

本発明は、コンテンツ中心型ネットワークを構成する通信端末、転送端末、および、コンテンツ中心型ネットワークにおけるコンテンツ出版方法に関する。
近年、非特許文献1に記載のCCN(Content Centric Network:コンテンツ中心型ネットワーク)と呼ばれる技術が、注目されている。CCNは、コンテンツを、コンテンツの名前に基づいて管理するコンテンツ配信基盤である。
CCNでは、以下のようにして、コンテンツの取得が行われる。まず、コンテンツを取得しようとする通信端末は、コンテンツの名前を指定したインタレストパケット(Interest Packet)を送出する。送出されたインタレストパケットは、CCNに網目状に配置された多数の転送端末により、該当する名前のコンテンツを格納する通信端末へと転送される。インタレストパケットを受け取った当該通信端末は、該当する名前のコンテンツのデータを、パケットに格納して送出する。送出されたデータパケットは、多数の転送端末によりインタレストパケットとは逆方向に転送され、インタレストパケットを送出した通信端末へと到達する。
ここで、CCNの特徴の1つとして、転送端末による、データのキャッシュ機能およびインタレストパケットに対する応答機能がある。ルータ等の転送端末は、転送したデータの複製をキャッシュする。そして、転送端末は、当該データの名前を指定したインタレストパケットを受け取ったとき、インタレストパケットの転送を行わずに、キャッシュしたデータを、インタレストパケットの送信元へ返信する。
このような転送端末の機能により、CCNは、ネットワークの伝送負荷を低く抑え、コンテンツを効率的に配信することができるというメリットを有する。したがって、CCNは、インターネット等の公共通信ネットワークへの適用が期待されている。
インターネット等の既存の通信ネットワークでは、音楽コンテンツや映像コンテンツ等、実時間ストリームデータのコンテンツ(以下、単に「コンテンツ」という)を配信することが、広く行われている。そこで、CCNにおいても、このようなコンテンツがより効率良く配信されることが望ましい。
そこで、コンテンツを構成する複数のブロックのそれぞれがどのデバイスに格納されているかを管理する技術が、例えば、特許文献1に記載されている。また、コンテンツを取得する処理を、コンテンツにおける各ブロックの位置を示すインデックス情報へのアクセスと、インデックス情報に基づく各ブロックへのアクセスという、2段階の処理に分ける技術が、例えば、非特許文献1に記載されている。これらの従来技術によれば、コンテンツを構成する複数のブロックのそれぞれを効率良く取得することを可能にし、全体として、コンテンツを効率良く配信することを可能にする。
ところで、従来、コンテンツを配信したユーザとは別のユーザが、配信された当該コンテンツを編集して配信することが行われている。編集後のコンテンツは、例えば、長時間の映像を短くまとめたダイジェスト版の映像や、この映像を更に画像編集した映像である。このような編集後コンテンツについても、CCNにおいて効率良く配信されることが望ましい。
そこで、編集後コンテンツに、編集後コンテンツの基となったコンテンツ(以下「オリジナルコンテンツ」という)と共通する内容が含まれている場合に、オリジナルコンテンツのキャッシュを、編集後コンテンツの配信に活用することが考えられる。
米国特許出願公開第2012/0158973号明細書
Derek Kulinsk et al., "NDNVideo: Random-access Live and Pre-recorded Streaming using NDN", Technical Report NDN-0007, 2012
しかしながら、従来技術において、編集後コンテンツは、オリジナルコンテンツと共通する内容を含んでいたとしても、オリジナルコンテンツとは別のコンテンツとして扱われる。したがって、従来技術では、オリジナルコンテンツのキャッシュを、編集後コンテンツの配信に活用することができないという課題を有する。
本発明の目的は、オリジナルコンテンツのキャッシュが編集後コンテンツの配信に活用されるようにすることができる、通信端末、転送端末、およびコンテンツ出版方法を提供することである。
本開示の通信端末は、コンテンツ中心型ネットワークを構成する通信端末であって、名前を有するオリジナルブロックにより構成されるオリジナルコンテンツを取得するオリジナルコンテンツ取得部と、前記オリジナルコンテンツから、編集後ブロックにより構成される編集後コンテンツを生成するコンテンツ編集部と、前記編集後コンテンツの名前および前記編集後ブロックの名前を決定する名前決定部と、前記編集後コンテンツのインデックス情報と前記編集後ブロックとを出版する出版部と、を有し、前記名前決定部は、前記編集後ブロックの内容が前記オリジナルブロックの内容と同一であるとき、前記オリジナルブロックの前記名前を、前記編集後ブロックの名前として決定する。
本開示のコンテンツ出版方法は、コンテンツ中心型ネットワークにおけるコンテンツ出版方法であって、名前を有するオリジナルブロックにより構成されるオリジナルコンテンツを取得するステップと、前記オリジナルコンテンツから、編集後ブロックにより構成される編集後コンテンツを生成するステップと、前記編集後コンテンツの名前および前記編集後ブロックの名前を決定するステップと、前記編集後コンテンツのインデックス情報と前記編集後ブロックとを出版するステップと、を有し、前記編集後ブロックの名前を決定するステップは、前記編集後ブロックの内容が前記オリジナルブロックの内容と同一であるとき、前記オリジナルブロックの前記名前を、前記編集後ブロックの名前として決定する。
本開示によれば、オリジナルコンテンツのキャッシュが編集後コンテンツの配信に活用されるようにすることができる。
本発明の実施の形態1に係る通信端末の構成の一例を示すブロック図 本発明の実施の形態2に係る通信端末を含む通信システムの構成を示すシステム構成図 本実施の形態2における編集後コンテンツの概要の一例を示す図 本実施の形態2における名前空間の設計例を示す図 本実施の形態2における編集端末の構成の一例を示すブロック図 本実施の形態2における転送端末の構成の一例を示すブロック図 本実施の形態2における編集端末の動作の一例を示すフローチャート 本実施の形態2におけるコンテンツ取得処理の一例を示すフローチャート 本実施の形態2におけるコンテンツ編集処理の一例を示すフローチャート 本実施の形態2におけるインタレストパケット応答処理の一例を示すフローチャート 本実施の形態2における転送端末の動作の一例を示すフローチャート 本実施の形態2におけるFIB部の内容の一例を示す図 本実施の形態2におけるCS部の内容の一例を示す図 本実施の形態2におけるインタレストパケット対応処理の一例を示すフローチャート 本実施の形態2におけるパケットのやり取りの流れの一例を示すシーケンス図 本発明の実施の形態3に係る通信システムの構成の一例を示すシステム構成図 本実施の形態3における名前空間の設計例を示す図 本実施の形態3における編集端末の構成の一例を示すブロック図 本実施の形態3における転送端末の構成の一例を示すブロック図 本実施の形態3における転送端末のインタレストパケット対応処理の一例を示すフローチャート
以下、本発明の各実施の形態について、図面を参照して詳細に説明する。
(実施の形態1)
本発明の実施の形態1は、本発明の基本的態様の一例である。
図1は、本実施の形態に係る通信端末の構成の一例を示すブロック図である。
図1において、通信端末500は、オリジナルコンテンツ取得部520、コンテンツ編集部540、名前決定部550、および出版部570を有する。
オリジナルコンテンツ取得部520は、名前を有するオリジナルブロックにより構成されるオリジナルコンテンツを取得する。
コンテンツ編集部540は、オリジナルコンテンツから、編集後ブロックにより構成される編集後コンテンツを生成する。
名前決定部550は、編集後コンテンツの名前および編集後ブロックの名前を決定する。但し、名前決定部550は、編集後ブロックの内容がオリジナルブロックの内容と同一であるとき、オリジナルブロックの名前を、編集後ブロックの名前として決定する。
出版部570は、編集後コンテンツのインデックス情報と編集後ブロックとを出版する。
また、通信端末500は、図示しないが、例えば、CPU(central processing unit)、制御プログラムを格納したROM(read only memory)等の記憶媒体、RAM(random access memory)等の作業用メモリ、および通信回路を有する。この場合、上記した各部の機能は、CPUが制御プログラムを実行することにより実現される。
以上のように、本実施の形態に係る通信端末500は、編集後ブロックの内容がオリジナルブロックの内容と同一であるとき、オリジナルブロックの名前をそのまま用いて、編集後コンテンツのインデックス情報と編集後ブロックとを出版する。
これにより、編集後コンテンツのインデックス情報に基づいて編集後ブロックを探索する際に、同一内容のオリジナルブロックのキャッシュにヒットし、これを取得することが可能となる。
したがって、本実施の形態に係る通信端末500は、オリジナルコンテンツのキャッシュが編集後コンテンツの配信に活用されるようにすることができる。
(実施の形態2)
本発明の実施の形態2は、コンテンツが実時間ストリームデータを含む場合の、本発明の具体的態様の一例である。
<用語の定義>
まず、本実施の形態において用いられる主な用語の定義について説明する。
「コンテンツ」とは、ネットワークによる配信の対象となる、音声および映像等の実時間ストリームデータである。コンテンツには、オリジナルコンテンツ(オリジナルデータ)と、オリジナルコンテンツを編集して得られた編集後コンテンツ(編集後データ)とがある。
「コンテンツ名」とは、所定の名前空間におけるコンテンツの名前である。
「ブロック」とは、コンテンツを構成するデータを時間軸に沿って分割したときの、分割されたデータの一まとまりであり、映像音声などのデータをアクセスする単位である。具体的には、ブロックは、例えば、MPEG2−TSのパケットを複数集めた一まとまり、RFC3984で規定されるH.264のパケット、あるいは、RFC3551で規定されるRTPのパケットまたはそのペイロードを複数集めた一まとまりである。
「ブロック名」とは、上記所定の名前空間におけるブロックの名前である。なお、各ブロックには、そのデータの一部として、ブロック名が付与される。
「インデックス情報」(Index)とは、コンテンツ毎に、コンテンツ名と、コンテンツを構成するブロックのコンテンツにおける位置と、コンテンツを構成するブロックのブロック名との対応関係を示す情報である。コンテンツにおける位置とは、例えば、実時間ストリームデータの時間軸における再生時刻である。
「データパケット」とは、インデックス情報、あるいは、ブロックの一部または全部を格納したパケットである。
「CCN」とは、コンテンツ中心型ネットワーク(Content Centric Network)の略語であり、コンテンツの配信をコンテンツ名に基づいて管理するコンテンツ配信基盤を指す。本実施の形態において、CCNは、コンテンツの配信を要求する通信端末によって、インデックス情報へのアクセスとブロックへのアクセスという2段階の処理が行われることにより、コンテンツの配信を実現する。
「インタレストパケット」(Interest Packet)とは、データの返信を要求するパケットである。インタレストパケットには、インデックス情報の返信を要求するパケットと、ブロックの返信を要求するパケットとがある。
「出版」とは、あるデータについて、当該データを指定したインタレストパケットに対する応答(データパケット)を送信する能力がある事実を、CCNに登録することである。すなわち、「出版」とは、データを、そのデータの名前を指定したインタレストパケットの発行によって取得することが可能な状態にすることであり、CCN網の他の端末に対して、特定の名前空間のインタレストパケットの送信を依頼する動作を指す。具体的には、ある通信端末が、近接する他の端末に接続した際に、他の端末に自動生成される仮想インタフェイス(非特許文献1では、「フェイス」と表現されているもの)の属性として、特定の名前空間以下のインタレストパケットを通信端末へ転送するような情報を、他の端末に登録する行為を指す。CCN網は、かかる情報を、FIB(Forwarding Information Base)に登録すると共に、所定の経路制御プロトコル(例えば、OSPFN)により、CCN網内の各端末間に伝搬流通させる。すなわち、上記登録には、コンテンツ名のプレフィックスを他の端末に通知する処理が含まれる。
<通信システムの概要>
次に、本実施の形態に係る通信端末を含む通信システムの構成について説明する。
図2は、本実施の形態に係る通信端末を含む通信システムの構成を示すシステム構成図である。
図2において、通信システム100は、第1〜第3の転送端末200−1〜200−3を配置した通信ネットワーク300と、通信ネットワーク300に接続されたオリジナル端末400および第1〜第4の編集端末500−1〜500−4を有する。通信システム100は、CCN網を形成している。
なお、以下の説明において、第1〜第3の転送端末200−1〜200−3は、共通の構成を有しているため、適宜、「転送端末200」と総称する。また、第1〜第4の編集端末500−1〜500−4は、共通の構成を有しているため、適宜、「編集端末500」と総称する。
転送端末200は、CCNに対応したルータである。転送端末200は、インタレストパケットおよびデータパケットの転送を行うと共に、転送したデータパケットの複製をキャッシュする。そして、転送端末200は、受信したインタレストパケットが指定するデータパケットをキャッシュしている場合、そのデータパケットを、インタレストパケットの送信元へ返信する。
オリジナル端末400は、CCNに対応した通信端末のうち、実時間ストリームデータを含むオリジナルコンテンツを出版する端末である。すなわち、オリジナル端末400は、オリジナルコンテンツの出版元(Publisher)である。オリジナル端末400は、例えば、通信機能を有するパーソナルコンピュータである。
編集端末500は、CCNに対応した通信端末のうち、オリジナル端末400からオリジナルコンテンツを取得し、オリジナルコンテンツから編集後コンテンツを生成して出版する端末である。すなわち、編集端末500は、編集後コンテンツの出版元である。編集端末500は、例えば、通信機能を有するパーソナルコンピュータである。
このようなCCN網において、例えば、第1の編集端末500−1が、既にオリジナルコンテンツを取得していたとする。この場合、オリジナル端末400から第1の編集端末500−1へと至る経路上に位置する第1および第2の転送端末200−1、200−2には、オリジナルコンテンツのデータがキャッシュされた状態となっている。
この状態で、第2の編集端末500−2がオリジナルコンテンツの名前を指定したインタレストパケットを送信したとする。この場合、オリジナル端末400よりも手前に位置する第2の転送端末200−2から、オリジナルコンテンツのデータを格納したデータパケットが返信されることになる。
本実施の形態において、オリジナルコンテンツは、ある2時間の映画の映像音声ストリームデータである。そして、編集端末500は、上記映画の予告版として、3分間のダイジェスト版(短縮版)の映像音声ストリーム(以下「ダイジェスト」という)を、編集後コンテンツとして出版する端末である。第1〜第4の編集端末500−1〜500−4の各ユーザは、例えば、オリジナル端末400のユーザから、映画のダイジェスト版の作成および配信を請け負っている技術者である。
なお、以下の説明において、第1〜第4の編集端末500−1〜500−4のユーザは、それぞれ、第1〜第4の編集者という。また、第1〜第4の編集端末500−1〜500−4において生成される編集後コンテンツは、それぞれ、第1〜第4のダイジェストという。
図3は、第1〜第4の編集端末500−1〜500−4における編集後コンテンツの概要の一例を示す図である。
図3に示すように、オリジナルコンテンツである映画611は、シーンA〜Dから成る実時間ストリームデータである。編集後コンテンツである第1〜第4のダイジェスト612〜615は、それぞれ、映画611から短い複数の区間の実時間ストリームデータを抽出して連結したデータである。
第1〜第4のダイジェスト612〜615を構成する区間のパターンは、互いに異なっている。すなわち、映画611および第1〜第4のダイジェスト612〜615は、それぞれ、別のコンテンツとなっている。
一方で、実時間ストリームデータから抽出されたデータの内容に対する編集が行われない場合、映画611および第1〜第4のダイジェスト612〜615の間には、共通するデータ部分(以下「共通データ」という)が存在する。キャッシュされた共通データは、映画611および第1〜第4のダイジェスト612〜615のいずれの配信であるかによらず、活用されることが望ましい。
しかしながら、映画611および第1〜第4のダイジェスト612〜615のそれぞれは、出版元が異なるため、異なるコンテンツ名が付与される。そして、従来では、コンテンツを構成するブロックには、当該コンテンツのコンテンツ名に応じたブロック名が付与される。したがって、異なる出版元から出版された複数のコンテンツの間に、共通データが存在したとしても、かかる共通データを、複数のコンテンツの配信で活用するということができなかった。
そこで、本実施の形態に係る編集端末500は、編集後ブロックの内容がオリジナルブロックの内容と同一であるとき、オリジナルブロックの名前をそのまま用いて、編集後コンテンツのインデックス情報および編集後ブロックを出版する。これにより、共通データのブロックは、その出版元が異なっていても、常に共通のブロック名を有するようになる。すなわち、異なる出版元から出版された複数のコンテンツの間に共通データが存在したときに、かかる共通データを、複数のコンテンツの配信で活用することが可能となる。
ここで、通信システム100において用いられる名前空間について説明する。
図4は、通信システム100において用いられる名前空間の設計例を示す図である。
通信システム100には、例えば、図4に示すような、オリジナルコンテンツの名前空間620と、オリジナルブロックの名前空間630と、編集後コンテンツの名前空間640と、編集後ブロックの名前空間650とが、設定される。
オリジナルコンテンツの名前空間620は、サービスをCCN網内で特定するためのプレフィックス部621と、データそのものを格納するデータ部622、623と、から成る。
オリジナルコンテンツの名前空間620の「index/」以下のデータ部623には、オリジナルブロックの再生時刻と当該オリジナルブロックのブロック名との組の集合が、格納される。ここで、再生時刻とは、オリジナルコンテンツの実時間ストリームデータの時間軸における、オリジナルブロックが再生されるべき時刻である。
例えば、データ部622、623において、「index/time00_00_01」には、時刻01(例:オリジナルコンテンツの開始時刻から1秒後の時刻)に再生されるべきオリジナルブロックのブロック名が格納される。すなわち、オリジナルコンテンツの名前空間620の名前にアクセスすることにより、オリジナルブロックとその再生時刻との組を得ることができるようになっている。
すなわち、オリジナルコンテンツの名前空間620のデータ部623に格納された情報は、オリジナルコンテンツのインデックス情報である。
また、図示しないが、「index/」の名前空間には、「index/」以下の名前空間にある全てのブロックのブロック名を格納する、「index/ALL」という特別な名前が定義されている。「index/ALL」を含むコンテンツ名を指定したインタレストパケットに対しては、「index/」以下にあるブロック名を含むデータを生成し、応答するように定められている。
更に、図示しないが、「index/」の名前空間には、「index/」以下にある全てのブロックのうち、再生時刻が最も最近の(最も大きい)ブロックのブロック名を格納する、「index/LATEST」という、別の特別な名前が定義されている。「index/LATEST」を含むコンテンツ名を指定したインタレストパケットは、「index/」以下にある全てのブロックのうち、再生時刻が最も最近のブロックのブロック名を指定したインタレストパケットと等価である。
例えば、2時間のコンテンツについて、「index/ALL」を指定したインタレストパケットに対し、「time00_00_01」〜「time02_00_00」とこれらの時刻に対応するブロック名とが返信される。一方で、「index/LATEST」を指定したインタレストパケットに対しては、「time02_00_00」とこの時刻に対応するブロック名のみが返信される。
オリジナルブロックの名前空間630も、オリジナルコンテンツの名前空間620と同様に、プレフィックス部631と、データ部632、633と、から成る。但し、オリジナルブロックの名前空間630のデータ部632の名前空間は、「index/」ではなく、「hash/」で始まる。そして、「hash/」以下のデータ部633には、オリジナルブロックのブロック名と当該オリジナルブロックのデータ本体との組が、格納される。
すなわち、編集端末500は、オリジナルコンテンツを取得する際、まず、オリジナルコンテンツの名前空間620を用いてデータ部623にアクセスし、オリジナルコンテンツのインデックス情報を取得する。そして、編集端末500は、取得したオリジナルコンテンツのインデックス情報に基づき、オリジナルブロックの名前空間630を用いてデータ部633にアクセスし、オリジナルブロックの実体を取得する。
なお、インデックス情報は、必ずしも、各オリジナルブロックの再生時刻を厳密に定義する必要はない。例えば、インデックス情報は、オリジナルブロックが属するシーンの開始時刻等、各オリジナルブロックの大まかな位置を定義するものであってもよい。この場合、「hash/」以下のデータ部633は、オリジナルブロックの再生時刻に関する付加情報を、更に格納することが望ましい。かかる付加情報は、例えば、オリジナルコンテンツ全体における再生順序の番号(例えば、「001」)や、インデックス情報に記述されたシーンの開始時刻に対するオリジナルブロックの再生時刻のオフセット値(例えば、「0.1秒後」)である。
編集後コンテンツの名前空間640は、オリジナルコンテンツの名前空間620と同様に、プレフィックス部641およびデータ部642、643を有する。また、編集後ブロックの名前空間650は、オリジナルブロックの名前空間630と同様に、プレフィックス部651およびデータ部652、653を有する。
の構成を有する。
但し、編集後コンテンツの名前空間640および編集後ブロックの名前空間650のサービス名(プレフィックス部641、651)は、オリジナルコンテンツの名前空間620およびオリジナルブロックの名前空間630のサービス名(プレフィックス部621、631)とは異なる。
上述の通り、本実施の形態に係る編集端末500は、編集後ブロックの内容がオリジナルブロックの内容と同一であるとき、オリジナルブロックの名前をそのまま用いて、編集後コンテンツのインデックス情報および編集後ブロックを出版する。これは、編集後コンテンツの名前空間640のデータ部643に、オリジナルブロックのブロック名を、編集後ブロックのブロック名として格納することを意味する。
<各端末の構成>
次に、編集端末500および転送端末200の構成について説明する。
図5は、編集端末500の構成の一例を示すブロック図である。
図5において、編集端末500は、通信部510、オリジナルコンテンツ取得部520、オリジナルコンテンツ保管部530、コンテンツ編集部540、名前決定部550、編集後コンテンツ保管部560、および出版部570を有する。
通信部510は、CCN網に接続し、他の端末との間で通信を行う。
オリジナルコンテンツ取得部520は、通信部510を介して、CCN網からオリジナルコンテンツを取得する。そして、オリジナルコンテンツ取得部520は、取得したオリコンを、オリジナルコンテンツ保管部530へ出力する。
オリジナルコンテンツ保管部530は、オリジナルコンテンツ取得部520から入力されたオリジナルコンテンツを格納する。
コンテンツ編集部540は、ユーザからオリジナルコンテンツに対する編集を受け付けて、オリジナルコンテンツから編集後コンテンツを生成する。コンテンツ編集部540は、ブロックサイズ分割部541およびブロック編集部542を有する。
ブロックサイズ分割部541は、オリジナルコンテンツ保管部530に格納されたオリジナルコンテンツの実時間ストリームデータを、オリジナルブロックと同一の区間で分割して得られる、分割ブロックを取得する。すなわち、分割ブロックの内容は、オリジナルブロックの内容と同一である。
ブロック編集部542は、分割ブロックと内容が同一の編集後ブロック、または、分割ブロックを編集して得られる編集後ブロックに基づいて、編集後コンテンツを生成する。そして、ブロック編集部542は、生成した編集後コンテンツを、名前決定部550へ出力する。
名前決定部550は、コンテンツ編集部540から入力された編集後コンテンツの名前と、当該編集後コンテンツを構成する編集後ブロックの名前とを決定する。但し、名前決定部550は、編集後ブロックの内容がオリジナルブロックの内容と同一であるとき、オリジナルブロックのブロック名を、その編集後ブロックのブロック名として決定する。編集後ブロックの内容がオリジナルブロックの内容と同一である場合とは、分割ブロックをそのまま編集後ブロックとして用いる場合である。また、名前決定部550は、編集後コンテンツのインデックス情報を生成する。そして、名前決定部550は、編集後コンテンツと、生成した編集後コンテンツのインデックス情報とを、編集後コンテンツ保管部560に格納する。
編集後コンテンツ保管部560は、入力された編集後コンテンツのインデックス情報および編集後コンテンツ(つまり、編集後ブロック)を、格納する。
出版部570は、編集後コンテンツ保管部560に格納された、編集後コンテンツのインデックス情報と編集後ブロックとを、通信部510を介して、CCN網に出版する。
なお、編集端末500は、キーボード、マウス、タッチパネル等の操作インタフェイスと、液晶ディスプレイあるいはプラズマディスプレイ等の表示インタフェイスを備えている。
このような編集端末500は、編集後ブロックの内容がオリジナルブロックの内容と同一であるとき、オリジナルブロックの名前をそのまま用いて、編集後コンテンツのインデックス情報および編集後ブロックを出版することができる。
図6は、転送端末200の構成の一例を示すブロック図である。
図6において、転送端末200は、転送通信部210、データ転送部220、FIB部230、CS(Contents Store)部240、およびインタレストパケット対応部250を有する。
転送通信部210は、CCN網に接続し、他の端末との間で通信を行う。転送通信部210は、仮想インタフェイス(非特許文献1の「フェイス」)である、第1〜第3のインタフェイス211−1〜211−3を有する。第1〜第3のインタフェイス211−1〜211−3は、それぞれ識別番号1〜3が設定されており、例えば、順に、オリジナル端末400、第1の編集端末500−1、および第2の編集端末500−2に接続されている。
データ転送部220は、転送通信部210を介して、転送端末200へのインデックス情報およびブロックの出版を受け付け、第1〜第3のインタフェイス211−1〜211−3の属性を、FIB部230に設定する。かかる属性は、インタレストパケットあるいはデータを受信したとき、当該インタレストパケットおよびデータを、どのインタフェイスから送出するか、を定義する情報である。そして、データ転送部220は、FIB部230の設定内容に基づき、転送通信部210を介して、インタレストパケットの送信元とインタレストパケットが指定するデータを格納する相手先との間において、インタレストパケットおよびデータの転送を行う。
また、データ転送部220は、データを転送する毎に、当該データ(当該データを格納したデータパケット)の複製を、CS部240(データキャッシュ部)に格納させる。かかるデータには、オリジナルコンテンツのインデックス情報、オリジナルブロック、編集後コンテンツのインデックス情報、および編集後ブロックが含まれる。
インタレストパケット対応部250は、CS部240に編集後コンテンツのインデックス情報が格納され、編集後コンテンツのコンテンツ名を指定したインタレストパケットが送られてきたとき、編集後コンテンツのインデックス情報の複製を返信する。また、インタレストパケット対応部250は、CS部240に編集後ブロックが格納され、編集後ブロックのブロック名を指定したインタレストパケットが送られてきたとき、編集後ブロックの複製を返信する。インタレストパケット対応部250は、これらのインタレストパケットの受信およびデータの返信を、転送通信部210を介して行う。
なお、転送端末200は、図示しないが、PIT(Pending Interest Table)を有している。データ転送部220は、PITを管理および参照することにより、同じインタレストパケットが複数回、上流に転送されることを抑止する。
このような転送端末200は、CCNにおける、データのキャッシュ機能およびインタレストパケットに対する応答機能を発揮することができる。
なお、編集端末500および転送端末200は、図示しないが、例えば、CPU、制御プログラムを格納したROM等の記憶媒体、RAM等の作業用メモリ、および通信回路を、それぞれ有する。この場合、上記した各部の機能は、CPUが制御プログラムを実行することにより実現される。
また、オリジナル端末400は、例えば、編集端末500と同様の構成を有する。但し、オリジナル端末400は、オリジナルコンテンツの実時間ストリームデータを、その時間軸における所定の時刻を基準として、時間軸に沿って所定のサイズで分割して、オリジナルブロックを生成する。そして、オリジナル端末400は、オリジナルコンテンツのインデックス情報およびオリジナルブロックの出版を行う。
以下の説明において、オリジナルコンテンツの実時間ストリームデータの時間軸は、「オリジナル時間軸」という。オリジナルブロックを生成する際の分割の基準となった所定の時刻は、以下、「分割基準時刻」という。オリジナルブロックを生成する際の分割のサイズは、「オリジナルブロックサイズ」という。
<各端末の動作>
次に、編集端末500および転送端末200の動作について説明する。
図7は、編集端末500の動作の一例を示すフローチャートである。
まず、ステップS1100において、オリジナルコンテンツ取得部520は、ユーザ操作等によりオリジナルコンテンツの取得を指示されたか否かを判断する。オリジナルコンテンツ取得部520は、オリジナルコンテンツの取得を指示された場合(S1100:YES)、処理をステップS1200へ進める。また、オリジナルコンテンツ取得部520は、オリジナルコンテンツの取得を指示されていない場合(S1100:NO)、処理を後述のステップS1300へ進める。
ステップS1200において、オリジナルコンテンツ取得部520は、オリジナルコンテンツを取得する処理であるコンテンツ取得処理を行ってから、処理を後述のステップS1300へ進める。
図8は、コンテンツ取得処理の一例を示すフローチャートである。
まず、ステップS1210において、オリジナルコンテンツ取得部520は、オリジナルコンテンツのコンテンツ名を取得する。
なお、オリジナル端末400には、ユニークなサービス名が予め設定されている。例えば、オリジナル端末400には、「/edit_service/4k_movie/title_A/original」というサービス名が設定されている。このサービス名は、オリジナルコンテンツのコンテンツ名として用いられる。すなわち、このサービス名は、オリジナルコンテンツの名前空間のプレフィックス部621(図4参照)である。したがって、例えば、オリジナルコンテンツ取得部520は、「/edit_service/4k_movie/title_A/original」を、オリジナルコンテンツのコンテンツ名として取得する。
そして、ステップS1220において、オリジナルコンテンツ取得部520は、オリジナルコンテンツのコンテンツ名を指定したインタレストパケットを生成し、CCN網に送信する。このインタレストパケットに対する応答として、オリジナルコンテンツ取得部520は、オリジナル端末400から、オリジナルコンテンツのインデックス情報を取得する。
例えば、オリジナルコンテンツ取得部520は、「/edit_service/4k_movie/title_A/original/index/」という名前空間を含むインタレストパケットを、送信する。具体的には、オリジナルコンテンツ取得部520は、「/edit_service/4k_movie/title_A/original/index/time00_00_01」を指定したインタレストパケットを発行する。そして、その応答として、オリジナルコンテンツ取得部520は、「HASH1」というブロック名および再生時刻情報の組、すなわち、オリジナルコンテンツのインデックス情報を取得する。なお、再生時刻情報とは、RTPパケットのタイムスタンプのように特定の周波数で刻印された再生時刻であってもよいし、再生開始時刻からの相対時間のずれを表現したものであってもよい。
そして、ステップS1230において、オリジナルコンテンツ取得部520は、取得したインデックス情報に基づき、オリジナルブロックのブロック名を指定したインタレストパケットを生成し、CCN網に送信する。このインタレストパケットに対する応答として、オリジナルコンテンツ取得部520は、オリジナル端末400から、オリジナルブロックを取得する。
例えば、オリジナルコンテンツ取得部520は、「/edit_service/4k_movie/title_A/original/hash/HASH1」という名前空間を指定したインタレストパケットを、送信する。そして、オリジナルコンテンツ取得部520は、当該名前空間に格納されたオリジナルブロックの実体を、取得する。
そして、ステップS1240において、オリジナルコンテンツ取得部520は、取得されたオリジナルブロックに基づいて、オリジナルコンテンツの実時間ストリームデータを復元する。すなわち、オリジナルコンテンツ取得部520は、取得された複数のオリジナルブロックを、再生順に並び替えて連結する。これは、CCNでは、ブロックの到着順序は、再生順序と必ずしも一致しないためである。なお、かかる復元は、オリジナルブロックをオリジナルコンテンツ補間部530に格納する毎に行われてもよいし、全てのオリジナルブロックが格納された後に行われてもよい。また、再生順序は、例えば、上述のオリジナルブロックの再生時刻に関する付加情報から取得することができる。
そして、ステップS1250において、オリジナルコンテンツ取得部520は、オリジナルコンテンツを構成する全てのオリジナルブロックを取得したか否かを判断する。オリジナルコンテンツ取得部520は、取得していないオリジナルブロックがある場合(S1250:NO)、処理をステップS1230へ戻し、取得していないオリジナルブロックの取得を行う。また、オリジナルコンテンツ取得部520は、全てのオリジナルブロックを取得した場合(S1250:YES)、処理を図7のフローチャートへ戻す。
例えば、オリジナル端末400からは、「/edit_service/4k_movie/title_A/original/hash/HASH1/」、「/edit_service/4k_movie/title_A/original/hash/HASH2/」、・・・というブロック名の、オリジナルブロックが、返信される。また、これに先立って、オリジナル端末400からは、これらのオリジナルブロックのブロック名およびオリジナルコンテンツにおける位置と、オリジナルコンテンツのコンテンツ名「/edit_service/4k_movie/title_A/original/」とを対応付けたインデックス情報とが、返信される。この結果、CCN網は、各所(例えば、転送端末200)に、これらのオリジナルブロックとインデックス情報とをキャッシュした状態となる。
また、オリジナルコンテンツ保管部530には、「/edit_service/4k_movie/title_A/original/hash/HASH1/」、「/edit_service/4k_movie/title_A/original/hash/HASH2/」、・・・というブロック名に対応する複数のオリジナルブロックを連結したデータが、オリジナルコンテンツとして格納された状態となる。
図7のステップS1300において、コンテンツ編集部540は、ユーザ操作等により、オリジナルコンテンツの編集の開始を指示されたか否かを判断する。コンテンツ編集部540は、オリジナルコンテンツの編集の開始を指示された場合(S1300:YES)、処理をステップS1400へ進める。また、コンテンツ編集部540は、オリジナルコンテンツの編集の開始を指示されていない場合(S1300:NO)、処理を後述のステップS1500へ進める。
ステップS1400において、コンテンツ編集部540は、オリジナルコンテンツを編集するコンテンツ編集処理を行ってから、処理を後述のステップS1500へ進める。
図9は、コンテンツ編集処理の一例を示すフローチャートである。
まず、ステップS1410において、ブロックサイズ分割部541は、オリジナルコンテンツの実時間ストリームデータを、上述の分割基準時刻を基準としてオリジナル時間軸に沿ってオリジナルブロックサイズ(変数Bs)で分割して、分割ブロック(BLKContent)を取得する。
分割基準時刻としては、例えば、オリジナル時間軸の開始時刻、つまり、実時間ストリームデータの先頭位置(映像のストリーム開始および音声のストリーム開始の、いずれか早い方の先頭の再生時刻)を採用することができる。また、分割基準時刻としては、特定のマーカが挿入された時刻等、他の特定の再生時刻や、編集端末500が搭載しているGPS(図示せず)の時刻を参照時刻として、特定の時刻に受信したデータ位置を採用してもよい。
オリジナルブロックサイズとしては、例えば、1500バイトといったイーサネット(登録商標)パケットのフレーム長や、1280バイトといったVPN(Virtual Private Network)で用いられるMTU(Maximum Transmission Unit)サイズを採用することができる。
ブロックサイズ分割部541は、通信システム100の既定値として予め配布された分割基準時刻およびオリジナルブロックサイズを用いてもよい。あるいは、ブロックサイズ分割部541は、オリジナルコンテンツを取得する毎に、オリジナルコンテンツのメタデータから、分割基準時刻およびオリジナルブロックサイズを取得してもよい。
このように、分割基準時刻およびオリジナルブロックサイズを用いて分割ブロックを取得することにより、分割ブロックの内容を、オリジナルブロックの内容と同一とすることができる。
なお、コンテンツには、通常、実時間ストリームデータだけでなくメタデータが含まれる。したがって、ブロックサイズ分割部541は、実時間ストリームデータとメタデータとを分離する処理を行ってもよい。
そして、ステップS1420において、ブロック編集部542は、分割ブロックから編集後ブロックを生成し、編集後コンテンツを生成する。
ブロック編集部542は、分割ブロックと内容が同一の編集後ブロックと、分割ブロックを編集して得られる編集後ブロックとの、どちらを生成してもよい。
ブロック編集部542は、例えば、編集端末500のユーザに対して、編集後コンテンツに含める対象となる分割ブロックの選択や、分割ブロックの映像音声に対する編集を行うための、編集操作画面を生成して表示する。編集操作画面は、例えば、編集点を提示する機能、ダイジェストの対象となる位置をマーキングする機能、および、オリジナルコンテンツから編集したい対象データを取得する機能等を有する。
分割ブロックに対する編集には、例えば、映像の色の変更、文字のオーバレイでの挿入、ナレータの解説の重層等の、映像加工および音声加工が含まれる。
このような編集操作画面におけるユーザの操作の結果、例えば、オリジナルブロックと内容が同一の編集後ブロックと、オリジナルブロックとは内容が異なる編集後ブロックとが混合する編集後コンテンツが生成される。
なお、編集端末500には、ユニークなサービス名が予め設定されている。例えば、編集端末500には、「/edit_service/4k_movie/title_A/ED1」というサービス名が設定されている。このサービス名は、編集後コンテンツのコンテンツ名として用いられる。すなわち、このサービス名は、編集後コンテンツの名前空間のプレフィックス部641(図4参照)である。
そして、ステップS1430において、名前決定部550は、編集後コンテンツから、編集後ブロックを1つ選択する。
そして、ステップS1440において、名前決定部550は、選択中の編集後ブロックの内容が、オリジナルブロックの内容と同一であるか否かを判断する。なお、かかる判断は、例えば、コンテンツ編集部540において、分割ブロックに対して変更を加えたか否かに基づいて行われてもよい。名前決定部550は、編集後ブロックの内容がオリジナルブロックの内容と同一ではない場合(S1440:NO)、処理をステップS1450へ進める。また、名前決定部550は、編集後ブロックの内容がオリジナルブロックの内容と同一である場合(S1440:YES)、処理をステップS1460へ進める。
ステップS1450において、名前決定部550は、選択中の編集後ブロックに対して、オリジナルブロックのブロック名とは異なるブロック名を決定する。具体的には、例えば、名前決定部550は、編集後ブロックに所定のハッシュ関数を適用して得られるハッシュ値(BKL_HASH)を、選択中の編集後ブロックのブロック名に決定する。
所定のハッシュ関数は、通信システム100に予め配布あるいは周知された、通信システム100の各端末に共通のハッシュ関数である。このように所定のハッシュ関数を用いてブロック名を決定することは、特に、編集後コンテンツに取得者制限を設けるようにした場合にメリットがある。かかるメリットについては、後述の本発明の実施の形態3において詳しく説明する。
例えば、オリジナルブロックのブロック名が、「/edit_service/4k_movie/title_A/original/hash/HASH1/」であったとする。この場合、編集後ブロックのブロック名は、少なくともプレフィックス部が変化し、「/edit_service/4k_movie/title_A/ED1/hash/HASH1/」となる。
一方、ステップS1460において、名前決定部550は、選択中の編集後ブロックに対して、オリジナルブロックのブロック名と同一のブロック名を決定する。
例えば、オリジナルブロックのブロック名が、「/edit_service/4k_movie/title_A/original/hash/HASH2/」であったとする。この場合、編集後ブロックのブロック名も、「/edit_service/4k_movie/title_A/original/hash/HASH2/」のままとなる。すなわち、編集後ブロックの名前は、従来は、オリジナルブロックのブロック名に対して、少なくともプレフィックス部が変化していたが、本実施の形態では変化しない。
そして、ステップS1470において、名前決定部550は、編集後コンテンツを構成する全ての編集後ブロックのブロック名を決定したか否かを判断する。名前決定部550は、ブロック名を決定していない編集後ブロックが存在する場合(S1470:NO)、処理をステップS1430へ戻し、ブロック名が決定されていない編集後ブロックを選択する。また、名前決定部550は、全ての編集後ブロックのブロック名を決定した場合(S1470:YES)、処理をステップS1480へ進める。
ステップS1480において、名前決定部550は、各編集後ブロックの編集後コンテンツにおける位置および名前に基づいて、編集後コンテンツのインデックス情報を生成する。そして、名前決定部550は、生成したインデックス情報と、編集後コンテンツ(編集後ブロック)とを、編集後コンテンツ保管部560へ格納する。なお、インデックス情報の生成および格納は、出版部570によって行われてもよい。
そして、ステップS1490において、出版部570は、編集後コンテンツ保管部560に格納された、編集後コンテンツのインデックス情報および編集後コンテンツを、CCN網に出版し、処理を図7のフローチャートへ戻す。
例えば、編集後コンテンツ保管部560は、「/edit_service/4k_movie/title_A/ED1/hash/HASH1/」、「/edit_service/4k_movie/title_A/original/hash/HASH2/」、・・・というブロック名の、編集後ブロックを、格納した状態となる。また、編集後コンテンツ保管部560は、これらの編集後ブロックのブロック名および編集後コンテンツにおける位置と、編集後コンテンツのコンテンツ名「/edit_service/4k_movie/title_A/ED1/」とを対応付けたインデックス情報を、格納した状態となる。そして、CCN網は、これらのインデックス情報および編集後ブロックが出版された状態となる。
図7のステップS1500において、出版部570は、CCN網からインタレストパケットを受信したか否かを判断する。出版部570は、インタレストパケットを受信した場合(S1500:YES)、処理をステップS1600へ進める。また、出版部570は、インタレストパケットを受信していない場合(S1500:NO)、処理を後述のステップS1700へ進める。
ステップS1600において、出版部570は、応答すべきインタレストパケットに対して応答する処理であるインタレストパケット応答処理を行ってから、後述のステップS1700へ処理を進める。
図10は、インタレストパケット応答処理の一例を示すフローチャートである。
まず、ステップS1610において、出版部570は、受信したインタレストパケットが、編集後コンテンツ保管部560に格納された編集後コンテンツのコンテンツ名(つまり、編集後コンテンツ保管部560に格納されたインデックス情報)を指定しているか否かを判断する。出版部570は、インタレストパケットが当該コンテンツ名を指定している場合(S1610:YES)、処理をステップS1620へ進める。また、出版部570は、インタレストパケットが当該コンテンツ名を指定していない場合(S1610:NO)、処理をステップS1630へ進める。
ステップS1620において、出版部570は、インタレストパケットが指定するコンテンツ名の編集後コンテンツのインデックス情報を、編集後コンテンツ保管部560から読み出す。そして、出版部570は、読み出したインデックス情報を、インタレストパケットの送信元へ返信して、処理を図7のフローチャートへ戻す。
ステップS1630において、出版部570は、受信したインタレストパケットが、編集後コンテンツ保管部560に格納された編集後ブロックのブロック名を指定しているか否かを判断する。出版部570は、インタレストパケットが当該ブロック名を指定している場合(S1630:YES)、処理をステップS1640へ進める。また、出版部570は、インタレストパケットが当該ブロック名を指定していない場合(S1630:NO)、処理をステップS1650へ進める。
ステップS1640において、出版部570は、インタレストパケットが指定するブロック名の編集後ブロックを、編集後コンテンツ保管部560から読み出す。そして、出版部570は、読み出した編集後ブロックを、インタレストパケットの送信元へ返信して、処理を図7のフローチャートへ戻す。
ステップS1650において、出版部570は、受信したインタレストパケットを破棄して、処理を図7のフローチャートへ戻す。
例えば、インタレストパケットの送信元には、「/edit_service/4k_movie/title_A/ED1/hash/HASH1/」、「/edit_service/4k_movie/title_A/original/hash/HASH2/」、・・・というブロック名の、編集後ブロックが、返信される。また、これに先立って、インタレストパケットの送信元には、これらの編集後ブロックのブロック名および編集後コンテンツにおける位置と、編集後コンテンツのコンテンツ名「/edit_service/4k_movie/title_A/ED1/」とを対応付けたインデックス情報、が返信される。この結果、CCN網は、各所(例えば、転送端末200)に、これらの編集後ブロックおよびインデックス情報をキャッシュした状態となる。
なお、上述の通り、編集端末500がオリジナルコンテンツを取得した時点で、CCN網には、オリジナルブロックが既にキャッシュされている。したがって、オリジナルブロックと同一内容の編集後ブロックのブロック名を指定したインタレストパケットは、後述するように、当該オリジナルブロックをキャッシュする転送端末200で処理され、編集端末500に到達しないこともある。
図7のステップS1700において、オリジナルコンテンツ取得部520は、ユーザ操作等により処理の終了を指示されたか否かを判断する。オリジナルコンテンツ取得部520は、処理の終了を指示されていない場合(S1700:NO)、処理をステップS1100へ戻す。また、オリジナルコンテンツ取得部520は、処理の終了を指示された場合(S1700:YES)、一連の処理を終了する。なお、この判断処理は、編集端末500の他の機能部において行われてもよい。
このような動作により、編集端末500は、編集後ブロックの内容がオリジナルブロックの内容と同一であるとき、オリジナルブロックの名前をそのまま用いて、編集後コンテンツのインデックス情報および編集後ブロックを出版することができる。
図11は、転送端末200の動作の一例を示すフローチャートである。
まず、ステップS2100において、データ転送部220は、他の端末(オリジナル端末400あるいは編集端末500)から、コンテンツ(オリジナルコンテンツあるいは編集後コンテンツ)のインデックス情報およびブロックの出版があるか否を判断する。データ転送部220は、インデックス情報およびブロックの出版がある場合(S2100:YES)、処理をステップS2200へ進める。また、データ転送部220は、インデックス情報およびブロックの出版がない場合(S2100:NO)、処理を後述のステップS2300へ進める。
ステップS2200において、データ転送部220は、FIB部230に、出版されるコンテンツのコンテンツ名のプレフィックスと、転送先フェイスとの組を、設定する。転送先フェイスは、例えば、コンテンツ名のプレフィックスの通知を受信した仮想インタフェイスである。
図12は、FIB部230の内容の一例を示す図である。
図12に示すように、FIB部230に設定されるFIB660は、プレフィックス(Prefix)の最長一致(longest match)という名前空間661と、転送先フェイス(face)の識別情報662と、と対応付けて記述する。なお、ここでいうプレフィックスの最長一致とは、前方一致の範囲が最も長いものを指す。
データ転送部220は、通知されたプレフィックスに「/index」を加えた名前空間661と、通知されたプレフィックスに「/hash」を加えた名前空間662に対して、仮想インタフェイスの識別情報662を対応付ける。なお、これらの文字列の付加は、出版元によって行われてもよい。
例えば、「/edit_service/4k_movie/title_A/ED1/hash」という名前空間661に対して、「2」という識別情報662が対応付けられている。これは、「/edit_service/4k_movie/title_A/ED1/hash」という名前空間を指定したインタレストパケットを受信したとき、当該インタレストパケットを、第2のインタフェイス211−2から送出(転送)すべきことを意味する。
図11のステップS2300において、データ転送部220は、データパケットを受信したか否かを判断する。データ転送部220は、データパケットを受信した場合(S2300:YES)、処理をステップS2400へ進める。また、データ転送部220はデータパケットを受信していない場合(S2300:NO)、処理を後述のステップS2500へ進める。
ステップS2400において、データ転送部220は、データパケットから、データパケットに格納されたデータおよび当該データの名前を取得する。そして、データ転送部220は、CS部240に、データパケットの複製を格納すると共に、取得したデータとその名前との組を設定する。そして、データ転送部220は、データパケットを、その宛先へと転送する。
データパケットに格納されるデータは、インデックス情報およびブロックを含む。したがって、データ転送部220は、例えば、オリジナルコンテンツのインデックス情報、オリジナルブロック、編集後コンテンツのインデックス情報、および編集後ブロックを取得し、CS部240にキャッシュする。
図13は、CS部240の内容の一例を示す図である。
図13に示すように、CS部240に設定されるCS670は、名前(Name)の完全一致(exact match)という名前空間671と、データ(data)672とを、対応付けて記述する。
例えば、「/edit_service/4k_movie/title_A/original/index/time00_00_01」という名前空間671に対して、「original/hash/HASH1」というデータ672が対応付けられている。
「/edit_service/4k_movie/title_A/original/index/time00_00_01」という名前空間は、「/edit_service/4k_movie/title_A/original/」というコンテンツ名のオリジナルコンテンツの時間軸における、時刻01の位置を示す。そして、「original/hash/HASH1」というデータは、「/edit_service/4k_movie/title_A/original/hash/HASH1」というブロック名を示す。
すなわち、上記対応付けは、コンテンツ名と、ブロックの位置と、ブロック名との対応付けた、インデックス情報に相当する。
また、例えば、「/edit_service/4k_movie/title_A/original/hash/HASH1」という名前空間671に対して、「video1」というデータ672が対応付けられている。
「/edit_service/4k_movie/title_A/original/hash/HASH1」は、「video1」というデータ本体のブロック名である。
すなわち、上記対応付けは、ブロックそのものに相当する。
なお、図13において、「/edit_service/4k_movie/title_A/ED1/index/time00_00_01」という名前空間671に対しても、「original/hash/HASH1」というデータ672が対応付けられている。これは、編集後ブロックに、元のオリジナルブロックと同一のブロック名が付与されたことを意味する。すなわち、編集後コンテンツの取得の際に、オリジナルブロックのブロック名が参照され、オリジナルブロックが取得され得ることを意味する。
図11のステップS2500において、インタレストパケット対応部250は、CCN網からインタレストパケットを受信したか否かを判断する。インタレストパケット対応部250は、インタレストパケットを受信した場合(S2500:YES)、処理をステップS2600へ進める。また、インタレストパケット対応部250は、インタレストパケットを受信していない場合(S2500:NO)、処理を後述のステップS2700へ進める。
ステップS2600において、インタレストパケット対応部250は、インタレストパケットに対して対応する処理であるインタレストパケット対応処理を行ってから、後述のステップS2700へ処理を進める。
図14は、インタレストパケット対応処理の一例を示すフローチャートである。
まず、ステップS2610において、インタレストパケット対応部250は、受信したインタレストパケットが指定する名前が、CS部240(図13参照)に存在するか否かを判断する。インタレストパケット対応部250は、インタレストパケットが指定する名前がCS部240に存在する場合(S2610:YES)、処理をステップS2620へ進める。インタレストパケット対応部250は、インタレストパケットが指定する名前がCS部240に存在しない場合(S2610:NO)、処理をステップS2630へ進める。
ステップS2620において、インタレストパケット対応部250は、インタレストパケットが指定する名前に対応するデータを、CS部240から取得し、インタレストパケットの送信元へ返信する。そして、インタレストパケット対応部250は、受信したインタレストパケットを破棄して、処理を図11のフローチャートへ戻す。
ステップS2630において、インタレストパケット対応部250は、受信したインタレストパケットが指定する名前のプレフィックスが、FIB部230(図12参照)に存在するか否かを判断する。インタレストパケット対応部250は、インタレストパケットが指定する名前のプレフィックスがFIB部230に存在する場合(S2630:YES)、処理をステップS2640へ進める。また、インタレストパケット対応部250は、インタレストパケットが指定する名前のプレフィックスがFIB部230に存在しない場合(S2630:NO)、処理をステップS2650へ進める。
ステップS2640において、インタレストパケット対応部250は、FIB部230の設定内容に従って、受信したインタレストパケットを転送して、処理を図11のフローチャートへ戻す。
ステップS2650において、インタレストパケット対応部250は、受信したインタレストパケットを破棄して、処理を図11のフローチャートへ戻す。
図11のステップS2700において、インタレストパケット対応部250は、通信システム100の管理サーバ(図示せず)等により処理の終了を指示されたか否かを判断する。インタレストパケット対応部250は、処理の終了を指示されていない場合(S2700:NO)、処理をステップS2100へ戻す。また、インタレストパケット対応部250は、処理の終了を指示された場合(S2700:YES)、一連の処理を終了する。
例えば、転送端末200に、図12に示すFIB660および図13に示すCS670が設定されていたとする。
この状態において、転送端末200は、「/edit_service/4k_movie/title_A/ED2/index/ALL」という名前空間を指定したインタレストパケットを受信したとする。
この名前空間は、CS670には存在しないが、FIB660には存在し、「3」という転送先フェイスに対応付けられている。したがって、転送端末200は、上記インタレストパケットを、第3のインタフェイス211−3から送出(転送)する。
また、転送端末200は、「/edit_service/4k_movie/title_A/original/index/ALL」という名前空間を指定したインタレストパケットを受信したとする。
この名前空間は、CS670に存在し、再生時刻毎に、「original/hash/HASH1」等のブロック名に対応付けられている。したがって、転送端末200は、これらの対応関係を、インデックス情報として取得し、インタレストパケットの送信元へ返信する。
また、転送端末200は、「/edit_service/4k_movie/title_A/original/hash/HASH1」という名前空間を指定したインタレストパケットを受信したとする。
この名前空間は、CS670に存在し、「video1」というデータに対応付けられている。したがって、転送端末200は、かかるデータ(ブロック)を取得し、インタレストパケットの送信元へ返信する。
また、「/edit_service/4k_movie/title_A/ED3/index/ALL」という名前空間を指定したインタレストパケットを受信したとする。
この名前空間は、CS670およびFIB660のいずれにも存在しない。したがって、転送端末200は、受信したインタレストパケットを破棄する。
このような動作により、転送端末200は、CCNにおける、データのキャッシュ機能およびインタレストパケットに対する応答機能を発揮することができる。
なお、「index/ALL」という名前空間に対して、転送端末200(および編集端末500)は、まず、各ブロックの再生時刻を示す情報を返信し、再生時刻の指定を受けて、対応するブロック名を示す情報を返信するようにしてもよい。すなわち、転送端末200は、インデックス情報の返信を、2段階に分けて行ってもよい。
図15は、インデックス情報の返信を2段階に分けて行う場合の、編集端末500とCCN網との間のパケットのやり取りの流れの一例を示すシーケンス図である。
まず、編集端末500が、CCN網に対して、コンテンツの「index/ALL」という名前空間を指定したインタレストパケットを送信する(S3100)。これに対し、CCN網の、該当するインデックス情報をキャッシュしている相手先(転送端末200もしくはオリジナル端末400)は、各ブロックの再生時刻のリストである、「time00_00_01」から「time01_59_59」を、返信する(S3200)。
再生時刻のリストを受信した編集端末500は、「index/time00_00_01」等の、再生時刻の名前空間を指定したインタレストパケットを、CCN網に送信する(S3300)。これに対し、該当するインデックス情報をキャッシュしている相手先は、再生時刻に対応するブロックのブロック名である「HASH1」を返信する(S3400)。なお、この相手先は、再生時刻のリストを返信した相手先と同一とは限らない。
ブロック名を受信した編集端末500は、「hash/HASH1」というブロック名を指定したインタレストパケットを、CCN網に送信する(S3500)。これに対し、該当するブロックをキャッシュしている相手先は、ブロック名に対応するブロックである「video1」を返信する(S3600)。なお、この相手先は、再生時刻のリストを返信した相手先や、ブロック名を返信した相手先と、同一とは限らない。
このように、インデックス情報およびブロック名に対応するデータパケットの伝送を2段階に分けて行うことにより、オリジナルブロックと編集後ブロックとが混在した編集後コンテンツを再生することが可能となる。
ここで、本実施の形態において、オリジナルコンテンツのキャッシュを編集後コンテンツの配信に活用される状況の一例について説明する。
図2において、まず、第1の編集端末500−1が、オリジナル端末400からオリジナルコンテンツである映画を取得し、オリジナルブロックをそのまま連結し直した編集後コンテンツである第1のダイジェストを生成したとする。そして、第3の編集端末500−3が、この第1のダイジェストの取得を試みたとする。
この場合、映画は、第1の転送端末200−1および第2の転送端末200−2を伝送されたため、オリジナルブロックは、第2の転送端末200−2に格納されている。そして、第1のダイジェストに含まれる編集後ブロックには、オリジナルブロックと同一の名前が付与されている。
したがって、第1のダイジェストに含まれる編集後ブロックの名前を指定したインタレストパケットには、第2の転送端末200−2のキャッシュがヒットする。これにより、第3の編集端末500−3は、第1の編集端末500−1ではなく、第1の編集端末500−1よりも近くに位置する第2の転送端末200−2から、編集後ブロックを取得することができる。
また、その後、第4の編集端末500−4が、オリジナルコンテンツである映画の取得を試みたとする。
この場合、第1のダイジェストは、第2の転送端末200−2および第3の転送端末200−3を伝送されたため、オリジナルブロックと同一内容の編集ブロックが、第3の転送端末200−3に格納されている。そして、そして、第1のダイジェストに含まれる編集後ブロックには、オリジナルブロックと同一の名前が付与されている。
したがって、映画に含まれるオリジナルブロックの名前を指定したインタレストパケットの少なくとも一部には、第3の転送端末200−3のキャッシュがヒットする。これにより、第4の編集端末500−4は、オリジナル端末400ではなく、オリジナル端末400よりも近くに位置する第3の転送端末200−3から、オリジナルブロックを取得することができる。
<効果>
以上のように、本実施の形態に係る通信システム100は、編集端末500において、編集後ブロックの内容がオリジナルブロックの内容と同一であるとき、オリジナルブロックの名前をそのまま用いて、編集後コンテンツのインデックス情報と編集後ブロックとを出版する。これにより、編集後コンテンツのインデックス情報に基づいて編集後ブロックを探索する際に、同一内容のオリジナルブロックのキャッシュにヒットし、これを取得することが可能となる。したがって、本実施の形態に係る通信システム100は、オリジナルコンテンツのキャッシュを、編集後コンテンツの配信に活用することができる。
このような通信システム100は、複数の編集者が、通信ネットワークを介して映像音声ストリームデータの編集を行う、いわゆるクラウド(crowd)編集システムに、好適である。すなわち、通信システム100は、コンテンツ編集の処理負荷を、ネットワーク上に分散させることができる。
なお、編集端末500が出版した編集後コンテンツ(ダイジェスト)は、オリジナルコンテンツ(映画)の出版者や、オリジナルコンテンツに対する編集の権限を有する他の編集者のみが閲覧できるように、コンテンツ取得に制限を設けるようにしてもよい。
この場合、例えば、編集端末500は、暗号化した編集後コンテンツ(インデックス情報、あるいは、ブロック)を出版し、オリジナルコンテンツの出版者や他の編集者に対して、復号鍵を別途入手させる。復号鍵の受け渡しの手法としては、所定の暗号ソフトウェアで暗号化した電子メールによる送付、オフラインの記憶媒体での受け渡し、および、特定のメンバのみがアクセスできるサーバを経由した受け渡し等を採用することができる。
このように、特定のユーザにコンテンツの閲覧を制限したい場合、通信システム100は、コンテンツそのものを暗号化し復号化するための鍵を適切に配布管理することが望ましい。なお、通信システム100は、CCN網全体を閉囲網として管理し、閉囲網にアクセスできる者の全てが、全てのコンテンツにアクセスできるようにしてもよい。
(実施の形態3)
本発明の実施の形態3は、編集後コンテンツに取得者制限を設けつつ、私的複製データをネットワーク全体として圧縮保持するようにした場合の、本発明の具体的態様の一例である。
<通信システムの概要>
図16は、本実施の形態に係る通信システムの構成の一例を示すシステム構成図であり、実施の形態2の図2に対応するものである。図2と対応する部分には同一の数字を用いた符号を付し、実施の形態2と共通する部分についての説明を適宜省略する。
図16において、通信システム100aは、第1〜第3の転送端末200a−1〜200a−3を配置した通信ネットワーク300aと、通信ネットワーク300aに接続されたオリジナル端末400aおよび編集端末500aを有する。編集端末500aには、ディスプレイ装置710aが接続されている。また、通信ネットワーク300aには、携帯端末720aおよびフィルタ管理サーバ730aが接続されている。なお、通信システム100aは、実施の形態2と同様に、CCN網を形成している。
オリジナル端末400aは、決まった時間に、映像音声コンテンツを、CCN網に放送する機能を有する、オリジナル端末400aは、例えば、いわゆるネット放送局のサーバである。
編集端末500aは、オリジナル端末400aから決まった時間に放送される映像音声コンテンツを取得、録画、および再生する機能を有する。編集端末500aは、例えば、ネット放送局の放送を受信してテレビジョン装置に出力するための、STB(Set Top Box)である。
なお、編集端末500aのユーザは、オリジナル端末400aが放送する映像音声コンテンツを取得し、私的複製を行う権限(以下、「コンテンツ利用権」という)を有しているものとする。コンテンツ利用権は、つまり、オリジナルコンテンツおよびこのオリジナルコンテンツから生成された編集後コンテンツを、取得、格納、および再生する権限である。
ディスプレイ装置710aは、画像表示および音声出力を行う装置である。ディスプレイ装置710aは、例えば、テレビジョン装置である。
携帯端末720aは、編集端末500aが録画した映像音声コンテンツを、通信ネットワーク300aを介して編集端末500aから取得し、再生する装置である。携帯端末720aは、例えば、編集端末500aのユーザ等、コンテンツ利用権を有するユーザが使用するスマートフォンあるいはタブレット型端末である。
フィルタ管理サーバ730aは、編集端末500aが録画した映像音声コンテンツを、携帯端末720aしか取得できないようにするフィルタを、第1〜第3の転送端末200a−1〜200a−3に対して動的に挿入する装置である。このフィルタの詳細については、後述する。
第1〜第3の転送端末200a−1〜200a−3は、実施の形態2の転送端末200と同様に、CCNにおけるデータのキャッシュ機能およびインタレストパケットに対する応答機能を有する。但し、キャッシュ機能およびインタレストパケットに対する応答機能更に、フィルタ管理サーバ730aにより設定されたフィルタを用いて、インタレストパケットに対する応答機能を制限する。
図17は、通信システム100aにおいて用いられる編集後コンテンツの名前空間の設計例を示す図である。
通信システム100aには、例えば、図17に示すような、編集後コンテンツの名前空間810と、編集後ブロックの名前空間820とが、設定される。
編集後コンテンツの名前空間810は、プレフィックス部811と、データ部812、813とから成る。また、編集後ブロックの名前空間820は、プレフィックス部821と、データ部822、823とから成る。但し、編集後ブロックの名前空間820のプレフィックス部821は、編集後コンテンツの名前空間810のプレフィックス部812とは異なっている。
このような通信システム100aは、コンテンツ利用権を有するユーザが、編集後コンテンツを格納する編集端末500aとは別の場所で、編集後コンテンツを取得して閲覧することを可能にする。また、通信システム100aは、編集後コンテンツの取得を、コンテンツ利用権を有するユーザのみに制限することができる。
但し、この制限を、例えば、インデックス情報に対するインタレストパケットと、ブロックに対するインタレストパケットとの両方に対するフィルタリングによって実現しようとすると、処理が煩雑化する。
一方で、ブロック名が推測困難なものであれば、インデックス情報の取得に制限を掛けさえすれば、編集後コンテンツの取得を、コンテンツ利用権を有するユーザのみに制限することができる。
また、同一内容のブロックに対して、同一のブロック名が付与されるようになっていれば、ブロックのキャッシュ率を向上させることができる。
更に、オリジナルブロックと編集後ブロックとで、同一の内容となる確率を上げれば、ブロックのキャッシュ率を更に向上させることができる。
そこで、本実施の形態に係る通信システム100aでは、オリジナル端末400aおよび編集端末500aの全てにおいて、実施の形態2と同様のルールで、オリジナルコンテンツの実時間ストリームを分割し、ブロック名を決定する。
<ブロック名の決定手法>
ここで、ブロック名の決定手法の詳細について説明する。
ブロック名の決定に用いられる所定のハッシュ関数は、ストリームの長さを勘案して、ブロック名の重複が発生する確率が十分小さくなる範囲で選択された、ハッシュ関数である。
例えば、所定のハッシュ関数は、1500バイトのブロックから128バイトのハッシュ値を算出するというように、データ長を短くする性質を有するものが望ましい。ハッシュ値の長さは、ストリームの長さに応じて可変であってもよいが、全ての編集端末500aの間で、どのようなハッシュ関数を用いたかを示す情報が、別途、共有される必要がある。かかる情報共有は、例えば、ストリームのメタ情報等を用いて行われる。
オリジナル端末400aおよび編集端末500aは、具体的には、例えば、以下の手順で、ブロックのブロック名を決定し、インデックス情報およびブロックを出版する。なお、かかる手順は、勿論、実施の形態2にも適用することができる。
オリジナル端末400aおよび編集端末500aは、過去にブロック名として算出したハッシュ値(変数BLK_HASH)を、メモリ上のデータベース(図示せず)に格納する。このとき、オリジナル端末400aおよび編集端末500aは、既に同一のハッシュ値(BKL_HASH)が格納されている場合、メモリ上のフラグ(DUP)を「1」に変更する。
オリジナル端末400aおよび編集端末500aは、算出されたハッシュ値(BKL_HASH)を文字列に変換して、ブロック名(Blk_name)として、記録する。このとき、オリジナル端末400aおよび編集端末500aは、フラグ(DUP)が「1」の場合、ブロック名を、「DUP/」+[n]+「_Blk_name」とする。ここで、[n]は、同じブロック名(Blk_name)の出現する回数を記録した整数を、文字列に変換したものである。これにより、内容が同一の複数のブロックを、区別して扱うことが可能となる。
オリジナル端末400aおよび編集端末500aは、決定したブロック名と再生時刻との組の記録形式を決定し、CCN網に出版する。すなわち、オリジナル端末400aおよび編集端末500aは、「index/」の名前空間の要素である、「time」+[再生時刻]という形式の名前に対応するデータとして、ブロック名(Blk_name)を保持する。そして、オリジナル端末400aおよび編集端末500aは、「index/ALL」の名前空間に対する応答や、「index/LATEST」に対する応答を準備する。
なお、[再生時刻]は、実時間ストリームの再生時刻を文字列として表現したものであり、例えば、時間:分:秒:ミリ秒、といった形式の文字列である。「ALL」を指定したインタレストパケットに対する応答としては、上述の通り、「index/」の空間に格納された全ての「time」+[再生時刻]の名前のリストが返信される。また、「Index/LATAST」を指定したインタレストパケットに対する応答としては、上述の通り、[再生時刻]の最大値に対応する名前が返信される。なお、ALLやLATESTといった特別な名前に対する応答には、転送端末上でのキャッシュを防ぐ特別なフラグを付与して伝送してもよい。そして、各転送端末(ルータ)は、そのフラグを解釈し、キャッシュを抑止してもよい。あるいは、転送端末の実装基準として、特別な名前に対する応答はキャッシュしないように規定されていてもよい。
<各装置の構成および動作>
次に、編集端末500aおよび転送端末200aの構成および動作について説明する。
図18は、編集端末500aの構成の一例を示すブロック図であり、実施の形態2の図5に対応するものである。図5と同一部分には同一符号を付し、これについての説明を省略する。
図18において、編集端末500aは、図5の構成に加えて、ディスプレイインタフェイス(IF)部580aおよび録画予約情報保持部590aを有する。なお、本実施の形態において、編集端末500aは、必ずしも、編集後コンテンツの内容を、オリジナルコンテンツとは異なる内容に編集しなくてもよい。例えば、編集後コンテンツの内容は、オリジナルコンテンツの内容と全く同一ということもあり得る。
この場合、編集端末500aは、単に、オリジナルコンテンツの複製として、編集後コンテンツを生成する。そして、名前決定部550は、編集後コンテンツ(つまり、オリジナルコンテンツのコピー)のコンテンツ名を、オリジナルコンテンツのコンテンツ名から変更し、オリジナルブロックのブロック名を、編集後ブロックのブロック名としてそのまま転用する。
ディスプレイインタフェイス部580aは、ディスプレイ装置710a(図16参照)に接続し、映像音声ストリームの映像データおよび音声データを、ディスプレイ装置710aに送信する。ディスプレイインタフェイス部580aは、例えば、HDMI(High-Definition Multimedia Interface、登録商標)インタフェイスを含む。
録画予約情報保持部590aは、オリジナル端末400a(図16参照)が放送する予定のオリジナルコンテンツ(映像音声プログラム)に関する情報(以下「オリジナルコンテンツ情報」という)を、通信部510を介してCCN網から取得し、保持する。
オリジナルコンテンツ情報は、オリジナルコンテンツのコンテンツ名、実時間ストリームの長さ、タイトル、放送時間帯、および内容の概要を説明する文章等を含むデータ群である。オリジナルコンテンツ情報は、例えば、従来のテレビジョン放送で用いられているEPG(Electronic Program Guide)に記載されている情報に類似したものである。
録画予約情報保持部590aは、編集端末500aのユーザ(以下、単に「ユーザ」という)に対し、例えばディスプレイインタフェイス部580aを介して、オリジナルコンテンツ情報を提示する。録画予約情報保持部590aは、ユーザから、録画すべきオリジナルコンテンツを決定する操作を受け付ける。そして、録画予約情報保持部590aは、決定されたオリジナルコンテンツのコンテンツ名を、取得の対象となるコンテンツのコンテンツ名として設定する。また、録画予約情報保持部590aは、決定されたオリジナルコンテンツの放送時間帯から、録画開始時刻および録画終了時刻を設定する。
そして、録画予約情報保持部590aは、設定した録画開始時刻が到来すると、オリジナルコンテンツ取得部520に対し、オリジナルコンテンツの取得開始を指示する。また、録画予約情報保持部590aは、設定した録画終了時刻が到来すると、オリジナルコンテンツ取得部520に対し、オリジナルコンテンツの取得終了を指示する。
なお、編集端末500aの各部は、オリジナルコンテンツの取得中(映像音声プログラムの進行中)に、適宜、オリジナルコンテンツの表示、および、編集後コンテンツの生成(つまり、複製)を行ってもよい。
また、録画予約情報保持部590aは、例えば、出版部570に対して、オリジナルコンテンツの取得中、あるいは、取得完了後等の所定のタイミングで、編集後コンテンツの出版を指示してもよい。
出版部570は、編集後コンテンツのインデックス情報を出版する毎に、元のオリジナルコンテンツのコンテンツ利用権に関する情報を、当該インデックス情報と対応付けて、フィルタ管理サーバ730aに送信することが望ましい。
コンテンツ利用権に関する情報は、例えば、ユーザの識別情報と、編集後コンテンツの識別情報(例えば、コンテンツ名)と、を含む。ユーザの識別情報とは、例えば、ユーザに割り当てられた米国のソーシャルセキュリティ番号や、ユーザが所有するクレジットカードのカード番号である。
図16の携帯端末720aは、例えば、録画ブロックデータ取得部およびコンテンツ取得表示部を有する(図示せず)。
録画ブロックデータ取得部は、ユーザ操作等を受けて、編集後コンテンツのコンテンツ名を指定したインタレストパケットをCCN網に送信し、編集後コンテンツの編集後ブロックを取得する。編集後ブロックの取得手順は、実施の形態2で説明したオリジナルブロックの取得手順と同様である。
但し、録画ブロックデータ取得部は、ユーザの識別情報を保持している。そして、録画ブロックデータ取得部は、編集後コンテンツの取得に先立ち、フィルタ管理サーバ730a(図16参照)に対して、携帯端末720aが直接的あるいは間接的に接続している転送端末200aに、上述のフィルタを挿入することを要求する。この要求は、コンテンツ利用権に関する情報(ユーザの識別情報および編集後コンテンツの識別情報)の送信を含む。
その後、録画ブロックデータ取得部は、編集後コンテンツのインデックス情報の返信を要求するインタレストパケットに対応付けて、かかる情報をCCN網に送信する。例えば、録画ブロックデータ取得部は、上記インタレストパケットのヘッダ部分に、暗号化したユーザの識別情報を記述する。
コンテンツ取得表示部は、取得された編集後ブロックを、ユーザが閲覧(視聴)することが可能な状態の編集後コンテンツに組み立て、当該編集後コンテンツを再生する。
フィルタ管理サーバ730aは、上述の携帯端末720aからの要求に応じて、携帯端末720aが接続している転送端末200aに対し、特定の名前空間へのインタレストパケットの通過を許可するフィルタを挿入するように指示する。この際、フィルタ管理サーバ730aは、かかる要求が適切か否かを判断し、適切である場合にのみ、上記フィルタの挿入を行う。携帯端末720aからの要求が適切である場合とは、例えば、携帯端末720aから受信したコンテンツ利用権に関する情報と、編集端末500aから受信したコンテンツ利用権に関する情報とが、一致している場合である。
そして、フィルタ管理サーバ730aは、上述の携帯端末720aからの要求が適切である場合、転送端末200aにフィルタを追加(挿入)する。かかるフィルタは、すなわち、編集後コンテンツのindex部の対応関係が正しい場合に、録画コンテンツのindex部のインタレストパケットを通過させるようなフィルタである。具体的には、フィルタ管理サーバ730aは、例えば、コンテンツ利用権に関する情報(ユーザの識別情報および編集後コンテンツの識別情報)を、転送端末200aへ送信する。
図19は、転送端末200aの構成の一例を示すブロック図であり、実施の形態2の図6に対応するものである。図6と同一部分には同一符号を付し、これについての説明を省略する。
図19において、転送端末200aは、図6の構成に加えて、フィルタ部260aを有する。
フィルタ部260aは、転送通信部210と、データ転送部220およびインタレストパケット対応部250との間に配置されている。フィルタ部260aは、フィルタ管理サーバ730aからの、上記フィルタの挿入を受け、挿入されたフィルタを使用する。具体的には、フィルタ部260aは、フィルタ管理サーバ730aから、コンテンツ利用権に関する情報(ユーザの識別情報および編集後コンテンツの識別情報)を受信し、かかる情報に基づいて、上記フィルタの機能を発揮する。
なお、本実施の形態において、このフィルタは、上述の通り、編集端末500aが録画した映像音声コンテンツを、携帯端末720aしか取得できないようにするフィルタである。すなわち、フィルタは、転送あるいは応答するインタレストパケットの条件として、インタレストパケットが要求する編集後コンテンツの識別情報と、当該インタレストパケットに付与されているユーザの識別情報との正しい組み合わせを、定義するものである。この条件を満たすインタレストパケットは、編集後コンテンツのコンテンツ利用権を有するユーザによって送信されたパケットである。
なお、ユーザ以外の第三者が、ユーザの識別情報を不正に用いて、編集後コンテンツのコンテンツ名を指定したインタレストパケットを送信する可能性がある。したがって、フィルタ部260aは、イングレスフィルタリング等の送信元認証技術を用いて、このような不正に送信されたインタレストパケットを判別し、廃棄することが望ましい。
図20は、転送端末200aのインタレストパケット対応処理の一例を示すフローチャートであり、実施の形態2の図14に対応するものである。図14と同一部分には同一ステップ番号を付し、これについての説明を省略する。
まず、ステップS2601aにおいて、フィルタ部260aは、受信したインタレストパケットが編集後コンテンツのコンテンツ名を指定するものであるか否かを判断する。すなわち、フィルタ部260aは、編集後コンテンツのインデックス情報の返信を要求するインタレストパケットを受信したかどうかを判断する。
フィルタ部260aは、受信したインタレストパケットが編集後コンテンツのコンテンツ名を指定するものではない場合(S2601a:NO)、受信したインタレストパケットをインタレストパケット対応部250へ出力し、処理をステップS2610へ進める。編集後コンテンツのコンテンツ名を指定するものではない場合とは、例えば、編集後コンテンツを構成する編集後ブロックのブロック名を指定する場合である。また、フィルタ部260aは、受信したインタレストパケットが編集後コンテンツのコンテンツ名を指定するものである場合(S2601a:YES)、処理をステップS2602aへ進める。
ステップS2602aにおいて、フィルタ部260aは、編集後コンテンツのインデックス情報の要求元のユーザが、編集後コンテンツのコンテンツ利用権を有するか否かを判断する。すなわち、転送端末200aは、受信したインタレストパケットが要求する編集後コンテンツの識別情報と、当該インタレストパケットに付与されているユーザの識別情報との組が、フィルタの条件にマッチするか否かを判断する。
フィルタ部260aは、編集後コンテンツのインデックス情報の要求元のユーザが、編集後コンテンツのコンテンツ利用権を有する場合(S2602a:YES)、処理をステップS2610へ進める。また、フィルタ部260aは、編集後コンテンツのインデックス情報の要求元のユーザが、編集後コンテンツのコンテンツ利用権を有しない場合(S2602a:NO)、処理をステップS2650へ進める。
そして、処理がステップS2610へ進んだ場合、インタレストパケット対応部250は、フィルタ部260aを介して、実施の形態2で説明したインタレストパケット対応処理を行う。また、処理がステップS2650へ進んだ場合、インタレストパケット対応部250は、受信したインタレストパケットを破棄する。なお、このインタレストパケットの破棄は、フィルタ部260aで行われてもよい。
このように、転送端末200aは、インデックス情報を要求するインタレストパケットについては、コンテンツ利用権に基づくフィルタリングを行い、編集後ブロックを要求するインタレストパケットについては、かかるフィルタリングを行わない。
上述の通り、編集端末500aは、編集後ブロック(分割ブロックのままのものを含む)に対して、ブロックの内容に応じて一意に決まるブロック名を決定する。更に、かかるブロック名は、ブロックを取得したことのある端末(ユーザ)にしか推測することができない名前となっている。
したがって、既にオリジナルコンテンツ、編集後コンテンツ、あるいはインデックス情報を取得してない限り、編集後ブロックを取得することは困難である。これにより、通信システム100aは、インデックス情報を要求するインタレストパケットについてのフィルタリングのみで、簡易な構成および処理によって、編集後コンテンツに取得者制限を設けることができる。
また、上述の通り、編集端末500aは、編集後ブロックの基となる分割ブロックを、オリジナルブロックと同一の内容となるように生成する。そして、編集端末500aは、編集後ブロック(分割ブロックのままのものを含む)に対して、オリジナルブロックのブロック名と同一のルールで、ブロックの内容に応じて一意に決まるブロック名を決定する。
したがって、複数のユーザがそれぞれコンテンツ利用権を有するコンテンツに、内容が同一のブロックが共通して含まれる可能性が高くなり、かかるブロックに対するキャッシュヒット率が向上する。これにより、通信システム100aは、編集後コンテンツに取得者制限を設けつつ、コンテンツのキャッシュが活用される頻度を向上させ、編集後コンテンツが効率よく配信されるようにすることができる。
以上のように、本実施の形態に係る通信システム100aは、編集後ブロックを、オリジナルブロックと同一の内容となるように生成し、オリジナルブロックのブロック名と同一のルールで、ブロックの内容に応じて一意に決まるブロック名を決定する。また、本実施の形態に係る通信システム100aは、インデックス情報を要求するインタレストパケットに対してのみ、コンテンツ利用権に基づくフィルタリングを行う。
これにより、本実施の形態に係る通信システム100aは、編集後コンテンツに取得者制限を設ける場合であっても、オリジナルコンテンツ(および他の編集後コンテンツ)のキャッシュが、編集後コンテンツの配信に活用されるようにすることができる。
すなわち、本実施の形態に係る通信システム100aは、一つの動画コンテンツを様々なカットシーンの組み合わせとして編集したノンリニア編集した結果をネットワークで共有するようなユースケースにおいて、CCN網側で高効率にキャッシュヒットすることが期待できる。また、一つのコンテンツを多数の受信者が私的複製するようなユースケースにおいても、同様である。この結果、本実施の形態に係る通信システム100aは、ルータ上のキャッシュ容量やネットワークの回線帯域を節約することができ、全体として高効率なシステムを構成することができる。
なお、インデックス情報を要求するインタレストパケットに対するフィルタリングの手法およびその設定手法は、上述の例に限定されない。例えば、オリジナル端末400aあるいは編集端末500aが、各転送端末200aに直接にフィルタを設定してもよい。
なお、以上説明した各実施の形態において、編集後コンテンツは、他の編集後コンテンツのオリジナルコンテンツとして扱うことが可能である。このような場合でも、元のオリジナルコンテンツのブロック名は、編集後コンテンツを編集して得られる他の編集後コンテンツにおいても、維持され得ることになる。
また、オリジナルコンテンツおよび編集後コンテンツの種別は、上述の例に限定されない。オリジナルコンテンツおよび編集後コンテンツは、例えば、静画像データ、3次元空間データ、あるいは、テキストデータであってもよい。
本開示の通信端末は、コンテンツ中心型ネットワークを構成する通信端末であって、名前を有するオリジナルブロックにより構成されるオリジナルコンテンツを取得するオリジナルコンテンツ取得部と、前記オリジナルコンテンツから、編集後ブロックにより構成される編集後コンテンツを生成するコンテンツ編集部と、前記編集後コンテンツの名前および前記編集後ブロックの名前を決定する名前決定部と、前記編集後コンテンツのインデックス情報と前記編集後ブロックとを出版する出版部と、を有し、前記名前決定部は、前記編集後ブロックの内容が前記オリジナルブロックの内容と同一であるとき、前記オリジナルブロックの前記名前を、前記編集後ブロックの名前として決定する。
なお、上記通信端末は、前記編集後コンテンツの前記インデックス情報と前記編集後ブロックとを格納する編集後コンテンツ保管部、を更に有し、前記出版部は、前記編集後コンテンツの前記名前を指定したインタレストパケットが送られてきたとき、前記編集後コンテンツの前記インデックス情報を返信し、前記編集後ブロックの前記名前を指定したインタレストパケットが送られてきたとき、前記編集後ブロックを返信してもよい。
また、上記通信端末において、前記オリジナルコンテンツ取得部は、オリジナルコンテンツの名前を指定したインタレストパケットを送信して、前記オリジナルコンテンツのインデックス情報を取得し、前記オリジナルコンテンツの前記インデックス情報に含まれる前記オリジナルブロックの前記名前を指定したインタレストパケットを送信して、前記オリジナルブロックを取得し、上記通信端末は、取得した前記オリジナルブロックを格納するオリジナルコンテンツ保管部、を更に有してもよい。
また、上記通信端末において、前記コンテンツ編集部は、ユーザから前記オリジナルコンテンツに対する編集を受け付けて、前記編集後コンテンツを生成してもよい。
また、上記通信端末において、前記オリジナルコンテンツは、実時間ストリームデータを含み、前記コンテンツ編集部は、前記オリジナルコンテンツの前記実時間ストリームデータを、前記オリジナルブロックと同一のサイズで分割して得られる、分割ブロックを取得するブロックサイズ分割部と、前記分割ブロックと内容が同一の前記編集後ブロック、または、前記分割ブロックを編集して得られる前記編集後ブロックに基づいて、前記編集後コンテンツを生成するブロック編集部と、を有してもよい。
また、上記通信端末において、前記オリジナルブロックは、前記オリジナルコンテンツの前記実時間ストリームデータを、前記実時間ストリームデータの時間軸における所定の時刻を基準として、前記時間軸に沿って所定のサイズで分割して得られるデータであり、前記オリジナルコンテンツ取得部は、前記オリジナルコンテンツを構成する全ての前記オリジナルブロックを取得し、前記ブロックサイズ分割部は、前記オリジナルコンテンツの前記実時間ストリームデータを、前記所定の時刻を基準として前記時間軸に沿って前記所定のサイズで分割して、前記分割ブロックを取得してもよい。
また、上記通信端末において、前記ブロック編集部は、前記ユーザから前記分割ブロックに対する編集を受け付けて、前記編集後ブロックを生成し、前記ユーザから前記編集後ブロックの配置の決定を受け付けて、前記編集後コンテンツを生成してもよい。
また、上記通信端末において、前記名前決定部は、前記編集後ブロックの内容が前記オリジナルブロックの内容と同一ではないとき、前記編集後ブロックに対して所定のハッシュ関数を適用して得られるハッシュ値を、前記編集後ブロックの前記名前として決定してもよい。
本開示の転送端末は、上記通信端末に記載の通信端末を含む前記コンテンツ中心型ネットワークを構成する転送端末であって、インタレストパケットの送信元と前記インタレストパケットが指定するデータを格納する相手先との間において、前記インタレストパケットおよび前記データの転送を行うデータ転送部と、前記データ転送部によって前記データが転送されとき、当該データの複製を格納するデータキャッシュ部と、前記データキャッシュ部に前記編集後コンテンツの前記インデックス情報が格納され、前記編集後コンテンツの前記名前を指定したインタレストパケットが送られてきたとき、前記編集後コンテンツの前記インデックス情報を返信し、前記データキャッシュ部に前記編集後ブロックが格納され、前記編集後ブロックの前記名前を指定したインタレストパケットが送られてきたとき、前記編集後ブロックを返信するインタレストパケット対応部と、前記データ転送部における、前記編集後コンテンツの前記名前を指定した前記インタレストパケットの転送、および、前記インタレストパケット対応部における、当該インタレストパケットに対する前記編集後コンテンツの前記インデックス情報の返信を、当該インタレストパケットの前記送信元のユーザが前記編集後コンテンツを取得する権限を有する場合にのみ行われるように制限するフィルタ部と、を有する。
本開示のコンテンツ出版方法は、コンテンツ中心型ネットワークにおけるコンテンツ出版方法であって、名前を有するオリジナルブロックにより構成されるオリジナルコンテンツを取得するステップと、前記オリジナルコンテンツから、編集後ブロックにより構成される編集後コンテンツを生成するステップと、前記編集後コンテンツの名前および前記編集後ブロックの名前を決定するステップと、前記編集後コンテンツのインデックス情報と前記編集後ブロックとを出版するステップと、を有し、前記編集後ブロックの名前を決定するステップは、前記編集後ブロックの内容が前記オリジナルブロックの内容と同一であるとき、前記オリジナルブロックの前記名前を、前記編集後ブロックの名前として決定する。
本発明は、オリジナルコンテンツのキャッシュが編集後コンテンツの配信に活用されるようにすることができる、通信端末、転送端末、およびコンテンツ出版方法として有用である。
100、100a 通信システム
200、200a 転送端末
210 転送通信部
211 インタフェイス
220 データ転送部
230 FIB部
240 CS部
250 インタレストパケット対応部
260a フィルタ部
300、300a 通信ネットワーク
400、400a オリジナル端末
500、500a 編集端末(通信端末)
510 通信部
520 オリジナルコンテンツ取得部
530 オリジナルコンテンツ保管部
540 コンテンツ編集部
541 ブロックサイズ分割部
542 ブロック編集部
550 名前決定部
560 編集後コンテンツ保管部
570 出版部
580a ディスプレイインタフェイス部
590a 録画予約情報保持部
710a ディスプレイ装置
720a 携帯端末
730a フィルタ管理サーバ

Claims (7)

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

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2013201724A JP6213914B2 (ja) 2013-09-27 2013-09-27 通信端末、およびコンテンツ出版方法
US14/491,030 US20150095483A1 (en) 2013-09-27 2014-09-19 Communications terminal, transfer terminal, and content publication method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013201724A JP6213914B2 (ja) 2013-09-27 2013-09-27 通信端末、およびコンテンツ出版方法

Publications (2)

Publication Number Publication Date
JP2015069314A JP2015069314A (ja) 2015-04-13
JP6213914B2 true JP6213914B2 (ja) 2017-10-18

Family

ID=52741256

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013201724A Active JP6213914B2 (ja) 2013-09-27 2013-09-27 通信端末、およびコンテンツ出版方法

Country Status (2)

Country Link
US (1) US20150095483A1 (ja)
JP (1) JP6213914B2 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017022034A1 (ja) * 2015-07-31 2017-02-09 富士通株式会社 情報処理装置、情報処理方法、及び、情報処理プログラム
US10263965B2 (en) * 2015-10-16 2019-04-16 Cisco Technology, Inc. Encrypted CCNx
US10356209B2 (en) * 2015-11-30 2019-07-16 Futurewei Technologies, Inc. System and method to support context-aware content requests in information centric networks
US10587515B2 (en) * 2017-02-07 2020-03-10 Futurewei Technologies, Inc. Stateless information centric forwarding using dynamic filters
CN110581883B (zh) * 2019-08-22 2021-05-04 北京邮电大学 内容分发方法、内容发布装置、内容请求装置及路由节点
KR20220041394A (ko) 2020-09-25 2022-04-01 삼성전자주식회사 비 파괴 편집 컨텐츠 관리 방법 및 장치

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7149974B2 (en) * 2002-04-03 2006-12-12 Fuji Xerox Co., Ltd. Reduced representations of video sequences
CN101365128A (zh) * 2007-08-10 2009-02-11 中兴通讯股份有限公司 综合视频业务对等网络系统
US8812565B2 (en) * 2010-10-15 2014-08-19 Microsoft Corporation Optimizing browser caching through deterministic marking of files
WO2013136792A1 (ja) * 2012-03-15 2013-09-19 パナソニック株式会社 コンテンツ処理装置、コンテンツ処理方法およびプログラム
US20130275618A1 (en) * 2012-04-17 2013-10-17 Alcatel-Lucent Bell Labs France Method and apparatus for reducing content redundancy in content-centric networking
US9237190B2 (en) * 2012-04-18 2016-01-12 Samsung Electronics Co., Ltd. Node and method for generating shortened name robust against change in hierarchical name in content-centric network (CCN)
US9307293B2 (en) * 2012-05-30 2016-04-05 Palo Alto Research Center Incorporated Collaborative video application for remote servicing
US9400800B2 (en) * 2012-11-19 2016-07-26 Palo Alto Research Center Incorporated Data transport by named content synchronization
KR102100710B1 (ko) * 2012-11-26 2020-04-16 삼성전자주식회사 컨텐츠 중심 네트워크에서 컨텐츠 소유자 및 노드의 패킷 전송 방법
KR101965794B1 (ko) * 2012-11-26 2019-04-04 삼성전자주식회사 Ip 라우팅 호환을 위한 패킷의 구조, 네트워크 노드의 통신 방법 및 그 네트워크 노드
US9575635B2 (en) * 2013-01-04 2017-02-21 Apple Inc. Return to sender
KR102134454B1 (ko) * 2013-06-11 2020-07-15 삼성전자주식회사 컨텐츠 중심 네트워크에서 컨텐츠를 엿듣는 노드의 통신 방법 및 그 노드
US9454541B2 (en) * 2013-09-24 2016-09-27 Cyberlink Corp. Systems and methods for storing compressed data in cloud storage

Also Published As

Publication number Publication date
US20150095483A1 (en) 2015-04-02
JP2015069314A (ja) 2015-04-13

Similar Documents

Publication Publication Date Title
JP6213914B2 (ja) 通信端末、およびコンテンツ出版方法
JP7015617B2 (ja) コンテンツの送受信方法及び装置
US10135767B2 (en) Method and system for sender-controlled messaging and content sharing
Pantos et al. HTTP live streaming
CN109417544B (zh) 提供流式内容的系统及其方法
US8843744B2 (en) Method and devices for distributing media contents and related computer program product
TWI465088B (zh) 使用位元組範圍請求之視訊資料之網路串流
US9794240B2 (en) System and method for signaling and verifying URL signatures for both URL authentication and URL-based content access authorization in adaptive streaming
US9954717B2 (en) Dynamic adaptive streaming over hypertext transfer protocol as hybrid multirate media description, delivery, and storage format
US9342668B2 (en) Signaling and handling content encryption and rights management in content transport and delivery
JP4850075B2 (ja) データ格納方法、データ再生方法、データ記録装置、データ再生装置および記録媒体
JP5557897B2 (ja) デジタルメディアコンテンツ保護システム及び方法
KR20060116255A (ko) 콘텐츠-위치 정보의 저장
JP2007525759A5 (ja)
CN110798714B (zh) 一种基于hls的本地视频播放系统及播放方法
JP2017204706A (ja) コンテンツ流通システム、コンテンツ流通方法、コンテンツ生成装置及びコンテンツ生成プログラム
US20160182466A1 (en) TransDRM for Streaming Media
CN113678126B (zh) 使用多个加密数字签名分离授权内容访问和内容交付
CN106411996B (zh) 内容中心网络中的内容协商
JP5350021B2 (ja) ファイル生成装置、ファイル再生装置およびコンピュータプログラム
CN101216869B (zh) 用于管理元数据的方法
KR20040106961A (ko) 인터넷 환경에서의 콘텐츠 불법복제 및 유통을 막기 위한 콘텐츠 파일의 암호화 방법
May RFC 8216: HTTP Live Streaming
IOP DASH-IF Implementation Guidelines: Content Protection Information Exchange Format (CPIX)
KR20070061286A (ko) 다수의 동영상으로부터 새로운 동영상 생성 시 인덱스를이용한 drm 시스템 및 방법

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160316

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170330

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170418

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170516

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170905

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170911

R151 Written notification of patent or utility model registration

Ref document number: 6213914

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151