(57)【要約】  本技術は、特別に通信することなく多くのユーザーの嗜好情報を構築することができるようにする情報処理装置および情報処理方法に関する。複数の他の情報処理装置にネットワークを介して配信されるコンテンツを管理する情報処理装置において、取得部により、複数の他の情報処理装置にリクエストに応じて配信されたコンテンツのコンテンツ情報が取得され、構築部により、取得されたコンテンツ情報に基づいて複数の他の情報処理装置の注視情報が構築される。本技術は、例えば、サーバから端末装置にネットワークを介してコンテンツを配信する配信システムに適用することができる。
2018128097.tif 000002
【特許請求の範囲】
【請求項１】
複数の他の情報処理装置にネットワークを介して配信されるコンテンツを管理する情報処理装置であって、
複数の前記他の情報処理装置にリクエストに応じて配信された前記コンテンツのコンテンツ情報を取得する取得部と、
取得された前記コンテンツ情報に基づいて複数の前記他の情報処理装置の注視情報を構築する構築部と
を備える情報処理装置。
【請求項２】
前記コンテンツ情報は、前記コンテンツを時間的に分割したセグメントのセグメントファイル情報である
請求項１に記載の情報処理装置。
【請求項３】
前記セグメントファイル情報は、対応するセグメントファイルのURLと、前記セグメントファイルが配信された回数を含む
請求項２に記載の情報処理装置。
【請求項４】
前記注視情報は、注視領域の時系列と前記注視領域が配信された回数を含む
請求項３に記載の情報処理装置。
【請求項５】
前記注視情報は地域ごとに構築される
請求項４に記載の情報処理装置。
【請求項６】
前記セグメントファイル情報は一定の時刻ごとに取得される
請求項３に記載の情報処理装置。
【請求項７】
前記注視領域は、DASH SRD規格で記述される
請求項４に記載の情報処理装置。
【請求項８】
前記注視情報に基づいて、複数の前記他の情報処理装置に配信されるお薦め情報を生成する
請求項４に記載の情報処理装置。
【請求項９】
前記お薦め情報は、配信された回数が最も多い前記注視領域の時系列とされる
請求項８に記載の情報処理装置。
【請求項１０】
前記お薦め情報は、timed metadata trackに記述される
請求項９に記載の情報処理装置。
【請求項１１】
前記お薦め情報は、前記情報処理装置から出力されるMPDファイルのsegment listに記述される
請求項９に記載の情報処理装置。
【請求項１２】
複数の他の情報処理装置にネットワークを介して配信されるコンテンツを管理する情報処理装置が、
複数の前記他の情報処理装置にリクエストに応じて配信された前記コンテンツのコンテンツ情報を取得する取得ステップと、
取得された前記コンテンツ情報に基づいて複数の前記他の情報処理装置の注視情報を構築する構築ステップと
を含む情報処理方法。
【請求項１３】
複数の他の情報処理装置にネットワークを介して配信されるコンテンツを管理する情報処理装置であって、
複数の前記他の情報処理装置にリクエストに応じて配信された前記コンテンツのコンテンツ情報を取得する取得部と、
取得された前記コンテンツ情報に基づいて複数の前記他の情報処理装置の注視情報を構築する構築部と、
前記注視情報に基づいて、複数の前記他の情報処理装置に配信されるお薦め情報を生成する生成部と
を備える情報処理装置。
【請求項１４】
複数の他の情報処理装置にネットワークを介して配信されるコンテンツを管理する情報処理装置が、
複数の前記他の情報処理装置にリクエストに応じて配信された前記コンテンツのコンテンツ情報を取得する取得ステップと、
取得された前記コンテンツ情報に基づいて複数の前記他の情報処理装置の注視情報を構築する構築ステップと、
前記注視情報に基づいて、複数の前記他の情報処理装置に配信されるお薦め情報を生成する生成ステップと
を含む情報処理方法。
【請求項１５】
ネットワークを介して他の情報処理装置からコンテンツの配信を受ける情報処理装置であって、
前記他の情報処理装置にリクエストして配信されてきた前記コンテンツのコンテンツ情報に基づいて生成されたお薦め情報を、前記他の情報処理装置から取得する取得部と、
前記お薦め情報に基づいて再生を行う再生部と
を備える情報処理装置。
【請求項１６】
ネットワークを介して他の情報処理装置からコンテンツの配信を受ける情報処理装置が、
前記他の情報処理装置にリクエストして配信されてきた前記コンテンツのコンテンツ情報に基づいて生成されたお薦め情報を、前記他の情報処理装置から取得する取得ステップと、
前記お薦め情報に基づいて再生を行う再生ステップと
を含む情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、情報処理装置および情報処理方法に関し、特に特別に通信することなく多くのユーザーの嗜好情報を構築することができるようにした情報処理装置および情報処理方法に関する。
【背景技術】
【０００２】
高解像度、広視野角の映像(パノラマ映像、ＶＲ（virtual Reality）映像等)では、実際の視聴領域がコンテンツ映像の一部になることがある。ネットワーク帯域に適した、最高品質の映像を伝送するために、高解像度、広視野角の映像を複数のストリーム（stream）に分割して伝送することが知られている（DASH SRD規格(ISO/IEC23009-1/2014 AMD2)）。【０００３】
映像を複数のストリームに分割して伝送する際には、全体の映像の情報と分割したストリームの位置関係を示す情報が伝送される。端末装置は、その情報を基に、ユーザーの視聴に必要なストリームをサーバーにリクエストする。サーバーはリクエストされたストリームを端末装置に伝送し、端末装置はそれを表示する。【０００４】
このような高解像度、広視野角の映像を複数の分割されたストリームで配信するシステムにおいて、次のようなことが提案されている。すなわち、ストリームを受信する端末装置が、視聴者の視聴累積頻度表を作成し、それをサーバーに送信する。サーバーは複数の視聴者の視聴履歴を合算して最頻度経路を作成し、それを視聴者に推薦する（例えば特許文献１）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開2013-183209号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、視聴者の視聴累積頻度表を作成し、それをそのための特別の通信によりサーバーに送信するのは端末装置にとって負担となる。また、それだけネットワークが混雑する。【０００７】
本技術はこのような状況に鑑みてなされたものであり、特別に通信することなく多くのユーザーの嗜好情報を構築することができるようにするものである。
【課題を解決するための手段】
【０００８】
本技術の一側面は、複数の他の情報処理装置にネットワークを介して配信されるコンテンツを管理する情報処理装置であって、複数の前記他の情報処理装置にリクエストに応じて配信された前記コンテンツのコンテンツ情報を取得する取得部と、取得された前記コンテンツ情報に基づいて複数の前記他の情報処理装置の注視情報を構築する構築部とを備える情報処理装置である。【０００９】
前記コンテンツ情報は、前記コンテンツを時間的に分割したセグメントのセグメントファイル情報であることができる。【００１０】
前記セグメントファイル情報は、対応するセグメントファイルのURLと、前記セグメントファイルが配信された回数を含むことができる。【００１１】
前記注視情報は、注視領域の時系列と前記注視領域が配信された回数を含むことができる。【００１２】
前記注視情報は地域ごとに構築されることができる。【００１３】
前記セグメントファイル情報は一定の時刻ごとに取得されることができる。【００１４】
前記注視領域は、DASH SRD規格で記述されることができる。【００１５】
前記注視情報に基づいて、複数の前記他の情報処理装置に配信されるお薦め情報を生成することができる。【００１６】
前記お薦め情報は、配信された回数が最も多い前記注視領域の時系列とされることができる。【００１７】
前記お薦め情報は、timed metadata trackに記述されることができる。【００１８】
前記お薦め情報は、前記情報処理装置から出力されるMPDファイルのsegment listに記述されることができる。【００１９】
本技術の一側面は、複数の他の情報処理装置にネットワークを介して配信されるコンテンツを管理する情報処理装置が、複数の前記他の情報処理装置にリクエストに応じて配信された前記コンテンツのコンテンツ情報を取得する取得ステップと、取得された前記コンテンツ情報に基づいて複数の前記他の情報処理装置の注視情報を構築する構築ステップとを含む情報処理方法である。【００２０】
本技術の一側面は、複数の他の情報処理装置にネットワークを介して配信されるコンテンツを管理する情報処理装置であって、複数の前記他の情報処理装置にリクエストに応じて配信された前記コンテンツのコンテンツ情報を取得する取得部と、取得された前記コンテンツ情報に基づいて複数の前記他の情報処理装置の注視情報を構築する構築部と、前記注視情報に基づいて、複数の前記他の情報処理装置に配信されるお薦め情報を生成する生成部とを備える情報処理装置である。【００２１】
本技術の一側面は、複数の他の情報処理装置にネットワークを介して配信されるコンテンツを管理する情報処理装置が、複数の前記他の情報処理装置にリクエストに応じて配信された前記コンテンツのコンテンツ情報を取得する取得ステップと、取得された前記コンテンツ情報に基づいて複数の前記他の情報処理装置の注視情報を構築する構築ステップと、前記注視情報に基づいて、複数の前記他の情報処理装置に配信されるお薦め情報を生成する生成ステップとを含む情報処理方法である。【００２２】
本技術の一側面は、ネットワークを介して他の情報処理装置からコンテンツの配信を受ける情報処理装置であって、前記他の情報処理装置にリクエストして配信されてきた前記コンテンツのコンテンツ情報に基づいて生成されたお薦め情報を、前記他の情報処理装置から取得する取得部と、前記お薦め情報に基づいて再生を行う再生部とを備える情報処理装置である。【００２３】
本技術の一側面は、ネットワークを介して他の情報処理装置からコンテンツの配信を受ける情報処理装置が、前記他の情報処理装置にリクエストして配信されてきた前記コンテンツのコンテンツ情報に基づいて生成されたお薦め情報を、前記他の情報処理装置から取得する取得ステップと、前記お薦め情報に基づいて再生を行う再生ステップとを含む情報処理方法である。【００２４】
本技術の一側面においては、複数の他の情報処理装置にネットワークを介して配信されるコンテンツを管理する情報処理装置において、複数の他の情報処理装置にリクエストに応じて配信されたコンテンツのコンテンツ情報が取得され、取得されたコンテンツ情報に基づいて複数の他の情報処理装置の注視情報が構築される。
【発明の効果】
【００２５】
以上のように、本技術の一側面によれば、特別に通信することなく多くのユーザーの嗜好情報を構築することができる。
なお、本明細書に記載された効果はあくまで例示であって、限定されるものではなく、また付加的な効果があってもよい。
【図面の簡単な説明】
【００２６】
【図１】タイルによるストリーミングを説明する図である。
【図２】配信システムの構成を示すブロック図である。
【図３】コンテンツ管理サーバの構成を示すブロック図である。
【図４】DASHキャッシュサーバの構成を示すブロック図である。
【図５】DASHクライアントの構成を示すブロック図である。
【図６】画面の分割を説明する図である。
【図７】SRD記述の例を示す図である。
【図８】分割されたファイルの配置を説明する図である。
【図９】MPDファイルの例を示す図である。
【図１０】図９に続くMPDファイルの例を示す図である。
【図１１】MPDファイルの例を示す図である。
【図１２】図１１に続くMPDファイルの例を示す図である。
【図１３】画面の分割を説明する図である。
【図１４】MPDファイルの例を示す図である。
【図１５】図１４に続くMPDファイルの例を示す図である。
【図１６】図１５に続くMPDファイルの例を示す図である。
【図１７】端末装置の処理を説明するフローチャートである。
【図１８】DASHキャッシュサーバの処理を説明するフローチャートである。
【図１９】コンテンツ管理サーバの処理を説明するフローチャートである。
【図２０】コンテンツの注視情報の例を説明する図である。
【図２１】コンテンツの注視情報の例を説明する図である。
【図２２】コンテンツ管理サーバの処理を説明するフローチャートである。
【図２３】端末装置の処理を説明するフローチャートである。
【図２４】コンテンツのお薦め情報の例を説明する図である。
【図２５】コンテンツのお薦め情報の例を説明する図である。
【図２６】タイムドメタデータの例を示す図である。
【図２７】タイムドメタデータの例を示す図である。
【図２８】MPDファイルの例を示す図である。
【図２９】図２８に続くMPDファイルの例を示す図である。
【図３０】タイムドメタデータの例を示す図である。
【図３１】タイムドメタデータの例を示す図である。
【図３２】コンテンツ管理サーバの処理を説明するフローチャートである。
【図３３】端末装置の処理を説明するフローチャートである。
【図３４】MPDファイルの例を示す図である。
【図３５】図３４に続くMPDファイルの例を示す図である。
【図３６】コンピュータのハードウエアの構成例を示すブロック図である。
【発明を実施するための形態】
【００２７】
以下、本技術を実施するための実施の形態について説明する。なお、説明は以下の順序で行う。
１．タイルドストリーミングの例（図１）
２．第１の実施の形態
（１）配信システムの構成（図２〜図１６）
（２）配信システムのコンテンツ配信処理（図１７〜図２１）
３．第２の実施の形態
配信システムのお薦め配信処理（図２２〜図３５）
４．本開示を適用したコンピュータの説明（図３６）
５．その他
【００２８】
＜タイルドストリーミングの例（図１）＞
本技術においては、タイルドストリーミング（tiled streaming）が利用されるので、最初にタイルドストリーミングの例について説明する。図１は、タイルによるストリーミングを説明する図である。
【００２９】
図１の例においては、左側に，上から順番に８ｋ（7680ｘ4320画素）の画像、４ｋ（3840x2160画素）の画像、ＨＤ(high-definition)（1920ｘ1080）の画像が、それぞれの画素数の違いが判るように示されている。８ｋの画像は４ｘ３個の領域（タイル）に分割され、４ｋとＨＤの画像は、２ｘ２個の領域に分割されている。ＨＤの画像の１つの分割領域がＡ１、４ｋの画像の１つの分割領域がＢ１、８ｋの画像の１つの分割領域がＣ１である。ＨＤ画像の全体の領域Ａ２のうちの分割領域Ａ１の視聴範囲が、４ｋの画像の分割領域Ｂ１の視聴範囲に対応し、４ｋの画像の分割領域Ｂ１のうちの領域Ｂ２の視聴範囲が、８ｋの画像の分割領域Ｃ１の視聴範囲に対応する。
【００３０】
図１の右側には、１つの表示画面におけるズームの様子が示されている。ＨＤ画像の領域Ａ１１（左側のＨＤ画像の領域Ａ２に対応する）を視聴している場合において、ズーミングを行うことで、領域Ｂ１１の画像が表示される。つまり、左側の４ｋの分割領域Ｂ１の画像が拡大表示される。さらにズーミングを行うことで、左側の８ｋの分割領域Ｃ１の画像が、領域Ｃ１１の画像として拡大表示される。
【００３１】
DASH SRD規格(ISO/IEC23009-1/2014 AMD2)（DASH:Dynamic Adaptive Streaming over HTTP,SRD：Spatial Relationship Description）によれば、このように、高解像度、広視野角の画像でズーミングを行うことができる。そして視聴者は、広視野角の全体の画像のうちの一部の注視する領域の画像を指定し、解像度の高い鮮明な画像のままで視聴することができる。
【００３２】
＜第１の実施の形態＞
＜配信システムの構成（図２〜図１６）＞
図２は、配信システムの構成を示すブロック図である。配信システム１１は、いずれも情報処理装置である２１、CDN(contents delivery network)サーバ２２、および端末装置２３により構成されている。それらはお互いにインターネットに代表されるネットワーク５１を介して相互に接続されている。
【００３３】
図２には、CDNサーバ２２と端末装置２３は１台のみが示されているが、実際には、１台のCDNサーバ２２に複数の端末装置２３が接続されている。１台のコンテンツ管理サーバ２１にも複数のCDNサーバ２２を接続することができる。
【００３４】
CDNサーバ２２は、DASHオリジンサーバ３１と、それにネットワーク５１を介して接続されている複数のDASHキャッシュサーバ３２−１，３２−２，３２−３・・・により構成されている。これらも情報処理装置である。なお、以下においては、DASHキャッシュサーバ３２−１，３２−２，３２−３等を個々に区別する必要がない場合、これらを単にDASHキャッシュサーバ３２と記述する。
【００３５】
コンテンツ管理サーバ２１はコンテンツを保持し、システム全体を管理する。DASHキャッシュサーバ３２は端末装置２３からのリクエストに応じてコンテンツを端末装置２３に供給する。DASHキャッシュサーバ３２は、端末装置２３から要求されたコンテンツを保持していない場合、DASHオリジンサーバ３１に要求し、供給を受けて保持し、端末装置２３に配信する。DASHオリジンサーバ３１は、コンテンツ管理サーバ２１からコンテンツの提供を受け、保持している。
【００３６】
クライアントとしての端末装置２３は、DASHクライアント４１、表示装置４２、ユーザー４４により使用されるGUI（Graphical User Interface）/姿勢角検出装置４３により構成されている。DASHクライアント４１は、DASHキャッシュサーバ３２に必要なコンテンツを要求し、取得したコンテンツを表示装置２３に供給し、表示させる。
【００３７】
表示装置４２は例えばヘッドマウントディスプレイ（HMD）やテレビジョン受像機等により構成される。GUI/姿勢角検出装置４３は、ユーザー４４によるリモートコントローラ、画面上の操作、視点の動き、頭の動き等から、ユーザー４４による注視領域を検出し、検出結果をDASHクライアント４１に供給する。DASHクライアント４１は、ユーザー４４の指定する注視領域の画像を選択し、表示装置４２に供給し、表示させる。
【００３８】
なお、コンテンツ管理サーバ２１はCDNサーバ２２と一体に構成することも可能である。
【００３９】
図３は、コンテンツ管理サーバの構成を示すブロック図である。コンテンツ管理サーバ２１は、判定部６１、要求部６２、取得部６３、更新部６４、構築部６５、出力部６６、記憶部６７および生成部６８の機能ブロックを有している。
【００４０】
判定部６１は、所定の時刻になったか等、各種の判定処理を行う。要求部６２は、DASHキャッシュサーバ３２に対してセグメントファイル情報をリクエストする等、各種の要求を行う。取得部６３は、セグメントファイル情報を受信したり、注視情報を取得する等、各種の情報を取得する。更新部６４はセグメントファイル情報の更新、timed metadataの内容の更新、segment listの内容の更新等、各種の更新処理を行う。構築部６５は、コンテンツの注視情報を構築する。構築部６５はまた、お薦め情報としてのお薦めtimed metadataやお薦めsegment listを生成する。出力部６６は、timed metadataファイルやMPDファイルをアップロードする等、各種の情報を出力する。記憶部６７は、DASHオリジンサーバ３１に供給するコンテンツの他、コンテンツの注視情報、お薦めtimed metadata、お薦めsegment list等を記憶する。生成部は、お薦め情報を生成する。
【００４１】
図４は、DASHキャッシュサーバの構成を示すブロック図である。DASHキャッシュサーバ３２は、要求部８１、送受信部８２、更新部８３、判定部８４、および記憶部８５により構成されている。
【００４２】
要求部８１は、セグメントファイルのリクエスト等、各種の要求処理を行う。送受信部８２は、セグメントファイルを送信したり、蓄積した情報を送信したり、セグメントファイルのリクエストを受信する等、各種の送受信処理を行う。更新部８３は、セグメントファイル情報を更新する等、各種の更新処理を行う。判定部８４は、データ送信のリクエストがあったか等、各種の判定処理を行う。記憶部８５は、コンテンツ、セグメントファイル情報等を記憶する。
【００４３】
図示は省略するが、DASHオリジンサーバ３１も、図４に示したDASHキャッシュサーバ３２と同様の構成を有している。
【００４４】
図５は、DASHクライアントの構成を示すブロック図である。DASHクライアント４１は、アクセス部１０１、MPD解析部１０２、およびメディアプレーヤ１０３を有している。
【００４５】
アクセス部１０１は、所定の時刻になったかを判定したり、MPDファイルを取得したり、セグメントファイルをリクエストしたり、セグメントファイルを取得する等、各種のアクセス処理を行う。MPD解析部１０２は、適切なbitrate（符号化速度）のセグメントファイルを決定したり、timed metadataを取得する等、各種の解析処理を行う。メディアプレーヤ１０３は、コンテンツを再生したり、再生中であるかを判定したり，お薦めを再生するかを判定する等、各種の再生関連処理を実行する。
【００４６】
本技術においては、配信システム１１のCDNサーバ２２から端末装置２３に、領域ごとに分割されたファイルが、一定時刻ごとに配信され、対応する画像が表示される。そこで配信システム１１の動作を説明する前に、分割されたファイルについて次に説明する。
【００４７】
図６は、画面の分割を説明する図である。図６には、本技術において配信される画像が示されている。この例においては、１つの画面が２ｘ２個の領域に分割されている。左上の分割領域が領域Ａ、右上の分割領域が領域Ｂ、左下の分割領域が領域Ｃ、右下の分割領域が領域Ｄとされている。
【００４８】
本技術においては、これらの領域Ａ乃至領域Ｄは、例えば図７に示されるように、SRDで記述される。図７は、SRD記述の例を示す図である。
【００４９】
図７に示されるように、各領域は、次のように記述される。
領域AのSRD記述
<SupplementalProperty
schemeIdUri＝"urn:mpeg:dash:srd:2014" value＝"0,0,0,1,1,2,2"/>
領域BのSRD記述
<SupplementalProperty
schemeIdUri＝"urn:mpeg:dash:srd:2014" value＝"0,1,0,1,1,2,2"/>
領域CのSRD記述
<SupplementalProperty
schemeIdUri＝"urn:mpeg:dash:srd:2014" value＝"0,0,1,1,1,2,2"/>
領域DのSRD記述
<SupplementalProperty
schemeIdUri＝"urn:mpeg:dash:srd:2014" value＝"0,1,1,1,1,2,2"/>
【００５０】
valueの６個の数字は、それぞれ各領域のグルーピング、ｘ座標、ｙ座標、width、height、全体のwidth、全体のheightを、相対値で表している。すなわち、これらの領域Ａ乃至領域Ｄは、いずれもグループ０に属する。領域Ａの（ｘ，ｙ）座標は、（０，０）、領域Ｂの（ｘ，ｙ）座標は、（１，０）、領域Ｃの（ｘ，ｙ）座標は、（０，１）、領域Ｄの（ｘ，ｙ）座標は、（１，１）となる。
【００５１】
領域Ａの幅は、画面全体の幅が２だとして、その半分の１である。その高さも、画面全体の高さが２であるとして、その半分の１である。領域Ｃ乃至領域Ｄにおいても同様である。
【００５２】
このように画像は２ｘ２個の領域に分割されるとともに、時間ごとに分割されて配信される。図８は、この様子を表している。図８は、分割されたファイルの配置を説明する図である。図８の縦軸は、画面の領域を表し、横軸は時刻を表している。すなわち、領域は、領域Ａ乃至領域Ｄの４つに分割されている。時刻は２秒ごとに分割されている。
【００５３】
例えば領域Ａにおいては、時刻Ｔ＝０ｓ、すなわち０秒から始まる２秒間の画像が、Segment_a_1.mp4という名称のファイル（セグメントファイル）として配信される。時刻Ｔ＝２ｓ、すなわち２秒から始まる２秒間の画像は、Segment_a_2.mp4という名称のセグメントファイルとして配信される。時刻Ｔ＝４ｓ、すなわち４秒から始まる２秒間の画像は、Segment_a_3.mp4という名称のセグメントファイルとして配信される。以下同様に、Ｔ＝６ｓ、Ｔ＝８ｓ、Ｔ＝１０ｓ、Ｔ＝１２ｓの画像は、Segment_a_4.mp4, Segment_a_5.mp4, Segment_a_6.mp4, Segment_a_7.mp4という名称のセグメントファイルとして配信される。
【００５４】
領域Ｂにおいては、時刻Ｔ＝０ｓ、すなわち０秒から始まる２秒間の画像が、Segment_b_1.mp4という名称のセグメントファイルとして配信される。時刻Ｔ＝２ｓ、すなわち２秒から始まる２秒間の画像は、Segment_b_2.mp4という名称のセグメントファイルとして配信される。時刻Ｔ＝４ｓ、すなわち４秒から始まる２秒間の画像は、Segment_b_3.mp4という名称のセグメントファイルとして配信される。以下同様に、Ｔ＝６ｓ、Ｔ＝８ｓ、Ｔ＝１０ｓ、Ｔ＝１２ｓの画像は、Segment_b_4.mp4, Segment_b_5.mp4, Segment_b_6.mp4, Segment_b_7.mp4という名称のセグメントファイルとして配信される。
【００５５】
例えば領域Ａにおいて、media＝"$Bandwidth%/Segment_a_$Number$.mp4" と記述され、領域Ｂにおいて、media＝"$Bandwidth%/Segment_b_$Number$.mp4"と記述されている。すなわち、ファイル名は、bitrate（符号化速度）を意味するBandwidthとSegment_a_$Number$.mp4、またはBandwidthとSegment_b_$Number$.mp4として記述されている。
【００５６】
このように、ファイル名Segment_R_j.mp4のうち、Ｒ（a,b等）は、領域を表し、ｊ（1,2,3等）は、再生時刻を表す。従って、領域Ｃと領域Ｄにおいては、Rの位置に、ｃまたはｄが記述され、ｊの位置に、対応する時刻を表す数字１，２，３等が記述される。
【００５７】
このように、セグメントファイル名が領域の情報（Ｒ＝ａ，ｂ，ｃ，ｄ）と、時刻情報（ｊ＝１，２，３等）を含んでいる。領域の情報は、その領域がユーザー４４により注視されている領域である場合には、注視領域の情報となる。
【００５８】
なお、同一領域（AdaptationSet）において、複数のビットレート（bitrate）のsegment（Representation）が配信される場合には、注視領域は同一となる。
【００５９】
図６に示されるように画面が４分割されている場合における、SRDが相対記述であるMPDフィルの構成例について、図９と図１０を参照して説明する。図９とそれに続く図１０は、MPDファイルの例を示す図である。
【００６０】
profileはon-demandではなく、liveとされている。領域Ａ乃至領域Ｄに対応してtile A乃至tile DのAdaptationSetが記述されている。tile A乃至tile Dにおいては、AdaptationSetにSRDが次のように相対的に記述されている。
<EssentialProperty schemeIdUri＝”urn:mpeg:dash:srd:2014”value＝”0,0,0,1,1,2,2”/>
<EssentialProperty schemeIdUri＝”urn:mpeg:dash:srd:2014”value＝”0,1,0,1,1,2,2”/>
<EssentialProperty schemeIdUri＝”urn:mpeg:dash:srd:2014”value＝”0,0,1,1,1,2,2”/>
<EssentialProperty schemeIdUri＝”urn:mpeg:dash:srd:2014”value＝”0,1,1,1,1,2,2”/>
【００６１】
SegmentTemplateの生成規則により、duration＝2、すなわち２秒ごとのsegment fileが、以下のURL(Uniform Resource Locator)から取得される。
領域Ａの場合
http://cdn1.example.com/video/5000000/Segment_a_1.mp4
http://cdn1.example.com/video/5000000/Segment_a_2.mp4
http://cdn1.example.com/video/5000000/Segment_a_3.mp4
http://cdn1.example.com/video/5000000/Segment_a_4.mp4
領域Ｂの場合
http://cdn1.example.com/video/5000000/Segment_b_1.mp4
http://cdn1.example.com/video/5000000/Segment_b_2.mp4
http://cdn1.example.com/video/5000000/Segment_b_3.mp4
http://cdn1.example.com/video/5000000/Segment_b_4.mp4
領域Ｃと領域Ｄについても同様である。
なお、5000000は、bitrate（符号化速度）が、５Mbpsであることを表す。
【００６２】
図９と図１０は、SRDが相対的記述であったが、絶対的記述とすることもできる。図１１と図１２は、この場合のMPDファイルの例を示している。図１１とそれに続く図１２は、MPDファイルの例を示す図である。
【００６３】
図１１と図１２においては、領域Ａ乃至領域Ｄに対応してtile A乃至tile DのAdaptationSetが記述されている。tile A乃至tile Dにおいては、AdaptationSetにSRDが次のように絶対的に記述されている。
<EssentialProperty schemeIdUri＝”urn:mpeg:dash:srd:2014”value＝”0,0,0,1920,1080,3840,2160”/>
<EssentialProperty schemeIdUri＝”urn:mpeg:dash:srd:2014”value＝”0,1920,0,1920,1080,3840,2160”/>
<EssentialProperty schemeIdUri＝”urn:mpeg:dash:srd:2014”value＝”0,0,1080,1920,1080,3840,2160”/>
<EssentialProperty schemeIdUri＝”urn:mpeg:dash:srd:2014”value＝”0,1920,1080,1920,1080,3840,2160”/>
【００６４】
ｘ座標とｙ座標は、各領域の左上の画素の座標を表している。例えば領域Ａは（0,0）、領域Ｂは（1920,0）、領域Ｃは（0,1080）、領域Ｄは（1920,1080）である。各領域の幅は1920画素、高さは1080画素、全体の幅は3840画素、全体の高さは2160画素である。
【００６５】
次に、画面が４ｘ４個に分割されている場合のMPDファイルについて説明する。図１３は、画面の分割を説明する図である。この例においては、画面が、領域Ａ乃至領域Ｐの１６個に分割されている。一番上の行においては、左から順番に、領域Ａ、領域Ｂ、領域Ｃ、領域Ｄとされ、第２番目の行においては、左から順番に、領域Ｅ、領域Ｆ、領域Ｇ、領域Ｈとされている。同様に、第３番目の行においては、左から順番に、領域Ｉ、領域Ｊ、領域Ｋ、領域Ｌとされ、一番下の行においては、左から順番に、領域Ｍ、領域Ｎ、領域Ｏ、領域Ｐとされている。
【００６６】
図１３に示すように画面が分割された場合のMPDファイルの例を、図１４乃至図１６を参照して説明する。図１４、それに続く図１５、さらにそれに続く図１６は、MPDファイルの例を示す図である。図１４乃至図１６においては、tile A乃至tile PのAdaptationSetが記述されている。ただし、冗長になるので、一部の記載は省略されている。
【００６７】
図１４乃至図１６における<EssentialProperty schemeIdUri＝"urn:mpeg:dash:coordinates:201X" value＝"equirectangular"/>は、このadaptationSetが正距円筒プロジェクションであることを示す。 <EssentialProperty schemeIdUri＝"urn:mpeg:dash:srd:2014" value＝"0, 3, 3, 1, 1, 4, 4"/>は、このSRD情報は、正距円筒の2次元画像座標での一部分であることを示す。
【００６８】
この例においても、SRDは相対座標で表されている。例えば領域Ａにおいて、（ｘ,ｙ）座標は（０，０）、幅は全体の幅４の１／４の１とされ、高さも全体の高さ４の１／４の１とされている。
【００６９】
領域Ｄにおいて、（ｘ,ｙ）座標は（３，０）、幅は全体の幅４の１／４の１とされ、高さも全体の高さ４の１／４の１とされている。
【００７０】
領域Ｐにおいて、（ｘ,ｙ）座標は（３，３）、幅は全体の幅４の１／４の１とされ、高さも全体の高さ４の１／４の１とされている。
【００７１】
なお、図示は省略するが、図１４乃至図１６の２次元画像座標のSRD情報は、マッピングする前の球面のＶＲ画像の３次元座標で表すことができる。
【００７２】
＜配信システムのコンテンツ配信処理（図１７〜図２１）＞
次に図１７乃至図１９を参照して、配信システム１１のコンテンツ配信処理を、端末装置２３、DASHキャッシュサーバ３２、およびコンテンツ管理サーバ２１の処理として説明する。
【００７３】
最初に図１７を参照して、端末装置２３の処理について説明する。図１７は、端末装置の処理を説明するフローチャートである。
【００７４】
ステップＳ１１においてメディアプレーヤ１０３は、コンテンツの再生を開始する。例えばHTML（HyperText Markup Language）で記述されたwebページのコンテンツのアイコンをユーザー４４が選択したとき、GUI/姿勢角検出装置４３がその操作を検出する。アクセス部１０１はそのアイコン操作に対応するURLにアクセスし、DASHキャッシュサーバ３２の記憶部８５に記憶されており、送受信部８２から送信されたコンテンツのMPDファイルを取得する。メディアプレーヤ１０３は、そのコンテンツを再生し、表示装置４２に表示させる。
【００７５】
あるいは有料のコンテンツの場合、課金処理を終えた後に、URLが提供されるので、アクセス部１０１は、そのURLに基づいて、DASHキャッシュサーバ３２にコンテンツを要求する。DASHキャッシュサーバ３２の送受信部８２はそのURLを受信する。記憶部８５のそのURLに記憶されているコンテンツのMPDファイルが読み出され、送受信部８２から送信される。アクセス部１０１はこれを取得し、メディアプレーヤ１０３が、そのコンテンツを再生し、表示装置４２に表示させる。
【００７６】
ステップＳ１２においてGUI/姿勢角検出装置４３は、ユーザーのリモートコントローラの操作、GUI操作、HMD等で姿勢角を検出する。すなわちユーザー４４が、表示装置４２に表示されている画像の所定の領域を注視領域として指定した場合、それが検出される。
【００７７】
ステップＳ１３においてMPD解析部１０２は、再生に必要な領域の適切なビットレートのセグメントファイルを決定する。この決定は、注視している領域の情報と、現在のネットワーク５１の帯域に応じて、ステップＳ１１で取得されたMPDファイルに記述されている情報に基づいて行われる。各セグメントのbitrateは、Bandwidthから得ることができる。
【００７８】
ステップＳ１４においてアクセス部１０１は、HTTPでそのセグメントファイルをリクエストする。すなわち、ステップＳ１３で決定された所定の注視領域のセグメントファイルが、DASHキャッシュサーバ３２に要求される。DASHキャッシュサーバ３２の送受信部８２は、後述する図１８のステップＳ３１で、この要求を受信する。記憶部８５に記憶されているセグメントファイルが読み出され、図１８のステップＳ３２の処理で送受信部８２より端末装置２３に送信される。
【００７９】
ステップＳ１５においてDASHクライアント４１のアクセス部１０１は、DASHキャッシュサーバ３２から送信されてくるセグメントファイルを取得する。すなわち、ステップＳ１４においてリクエストされたセグメントファイルがHTTPで取得される。
【００８０】
ステップＳ１６においてメディアプレーヤ１０３は、ステップＳ１５で取得されたセグメントファイルを再生し、表示装置４２に表示させる。
【００８１】
ステップＳ１７においてメディアプレーヤ１０３は、コンテンツを再生中であるかを判定し、まだ再生中である場合、処理はステップＳ１２に戻り、それ以降の処理が繰り返される。ステップＳ１７においてコンテンツの再生中ではないと判定された場合、処理は終了される。
【００８２】
以上のようにして端末装置２３において、ユーザー４４が注視した領域の画像が表示される。
【００８３】
このように、端末装置２３においてユーザー４４が注視する領域のコンテンツの再生が行われている場合、DASHキャッシュサーバ３２は、端末装置２３に配信したセグメントファイルを蓄積する処理を行う。この場合の処理について、図１８を参照して説明する。
【００８４】
図１８は、DASHキャッシュサーバの処理を説明するフローチャートである。ステップＳ３１においてDASHキャッシュサーバ３２の送受信部８２は、端末装置２３からHTTPによるセグメントファイルのリクエストを受信する。すなわち、上述したように、図１７のステップＳ１４でDASHクライアント４１のアクセス部１０１は、HTTPでセグメントファイルをリクエストする。このリクエストがここで受信される。
【００８５】
ステップＳ３２において記憶部８５は、リクエストされたセグメントファイルを読み出す。送受信部８２は、その読み出されたセグメントファイルを端末装置２３に送信する。この送信されたセグメントファイルが、上述した図１７のステップＳ１５において端末装置２３により受信され、ステップＳ１６で表示される。つまり、ユーザー４４により指定された注視領域のコンテンツ（セグメントファイル）が端末装置２３に供給され、表示される。
【００８６】
ステップＳ３３において更新部８３は、送信に伴ってセグメントファイル情報を更新する。すなわち、記憶部８５には過去に端末装置２３に送信したセグメントファイルのセグメントファイル情報が記憶されている。その記憶が最新の情報に更新される。
【００８７】
ここでセグメントファイル情報について説明する。上述したように、セグメントファイルは、注視領域の情報と時刻情報を有している。セグメントファイル情報は、例えば、XML（ExtensibleMarkupLanguage）のデータで、このセグメントファイルのURL（時系列になっている）と、そのセグメントファイルを端末装置２３に送出した回数とで構成される。URLについては、図９と図１０のMPDファイルの例で説明した。CDNサーバ２２の構成により、HTTPのリクエストを受け取ったサーバーから実際にセグメントファイルを送出する別のサーバーにリダイレクトされることがあるので、送出の回数が記録される。すなわち、リクエストの回数を計数すると、リダイレクトのような場合、回数が２重に計数され、不正確になるので、リクエストの回数ではなく、セグメントファイルの送出回数が計数される。CDNサーバ２２の構成によってはリクエストの回数を計数するようにすることもできる。
【００８８】
ステップＳ３４において判定部８４は、データ送信のリクエストがあったかを判定する。すなわち、図１９を参照して後述するように、コンテンツ管理サーバ２１は、一定の時刻になったとき、ステップＳ５２において、セグメントファイルの送信をリクエストしてくる。このリクエストを受けたかが判定される。
【００８９】
コンテンツ管理サーバ２１からこのリクエストをまだ受けていない場合、処理はステップＳ３１に戻り、それ以降の処理が繰り返される。コンテンツ管理サーバ２１からセグメントファイル情報の送信のリクエストを受けた場合、ステップＳ３５において送受信部８２は、コンテンツ管理サーバ２１に、蓄積したセグメントファイル情報を送信する。すなわち記憶部８５に記憶されているセグメントファイル情報が読み出され、送受信部８２から送信される。その後、処理はステップＳ３１に戻り、それ以降の処理が繰り返される。
【００９０】
なお、この例では、コンテンツ管理サーバ２１からのリクエストに応じてセグメントファイル情報を送信するようにした。しかし予め定められている一定時刻ごとにDASHキャッシュサーバ３２の方からコンテンツ管理サーバ２１にセグメントファイル情報を送信するようにすることもできる。
【００９１】
セグメントファイルは、ユーザーの注視領域と時刻情報を有するセグメントファイル情報のURLと回数を有するので、ユーザー４４のROI（Region of Interest）情報である。
【００９２】
なお、説明は省略するが、DASHオリジンサーバ３１も図１８の処理を実行し、セグメントファイル情報をコンテンツ管理サーバ２１に送信する。
【００９３】
このように、端末装置２３からリクエストされたセグメントに関するセグメントファイル情報を、リクエストを受けたDASHキャッシュサーバ３２が収集、蓄積するだけである。従って、DASHキャッシュサーバ３２から端末装置２３に対して注視領域情報を収集するために特別の処理や通信が要求されることがない。
【００９４】
以上のように、DASHキャッシュサーバ３２とDASHオリジンサーバ３１により、つまりCDNサーバ２２により、セグメントファイル情報をコンテンツ管理サーバ２１に送信する処理が実行される。これに対応して、コンテンツ管理サーバ２１はセグメントファイル情報を蓄積し、注視情報を構築する処理を実行する。以下、このコンテンツ管理サーバ２１の処理について、図１９を参照して説明する。
【００９５】
図１９は、コンテンツ管理サーバの処理を説明するフローチャートである。ステップＳ５１においてコンテンツ管理サーバ２１の判定部６１は、一定時刻になったかを判定する。すなわち予め定められている所定の時刻になったかが判定される。まだ一定の時刻になっていない場合、ステップＳ５１の判定処理が繰り返される。すなわち、コンテンツ管理サーバ２１はその時刻になるまで待機する。
【００９６】
一定の時刻になった場合、ステップＳ５２において要求部６２は、DASHオリジンサーバ３１とDASHキャッシュサーバ３２に対して、セグメントファイル情報をリクエストする。すなわち、DASHオリジンサーバ３１とDASHキャッシュサーバ３２が図１８のステップＳ３３の処理でそれまで更新し、蓄積してきたセグメントファイル情報の送信が要求される。
【００９７】
なお、上述したように、所定の時刻になった場合、DASHオリジンサーバ３１およびDASHキャッシュサーバ３２の方がセグメントファイル情報を送信してくる場合には、ステップＳ５１とステップＳ５２の処理は省略される。
【００９８】
上述したように、DASHオリジンサーバ３１とDASHキャッシュサーバ３２は、セグメントファイル情報のリクエストを受け取ると、図１８のステップＳ３５において、それまで蓄積していたセグメントファイル情報を送信してくる。コンテンツ管理サーバ２１の取得部６３は図１９のステップＳ５３において、このセグメントファイル情報を受信し、取得する。記憶部６７はこのセグメントファイル情報を記憶する。
【００９９】
ステップＳ５４において更新部６４は、すべてのサーバのセグメントファイル情報を更新する。すなわち、すべてのDASHオリジンサーバ３１とDASHキャッシュサーバ３２から送られてきたセグメントファイル情報が更新される。この場合、例えば地域ごと等、１つまたは複数のサーバーごとにセグメントファイル情報を更新するようにすることもできる。あるいは、ユーザー４４のプロファイルごとにセグメントファイル情報を更新するようにしてもよい。
【０１００】
ステップＳ５５において構築部６５は、MPDファイルを解析し、注視情報を構築する。この注視情報は、例えばコンテンツの注視領域の時系列、時刻情報、および送出された回数を含むように構成されている。どの領域が何回再生されたかの情報は、ステップＳ５４で更新されたセグメントファイル情報から得ることができる。注視領域の時系列と時刻情報については、セグメントファイル情報に含まれているURL（時系列を含む）に基づいてMPDファイルからセグメントファイルのファイル名を検索し、そのファイル名からえることができる。セグメントファイルのMPDファイルは、全てのコンテンツを管理するコンテンツ管理サーバ２１の記憶部６７に予め記憶されている。なお、同じ領域において複数のbitrateのセグメントファイルが配信された場合には、同一の注視領域として回数が計数される。
【０１０１】
このようにして、コンテンツ管理サーバ２１において複数の端末装置２３のセグメントファイル情報が収集、蓄積されるので、嗜好情報としての注視情報のデータベースを構築することができる。
【０１０２】
次に、以上のようにしてコンテンツ管理サーバ２１に構築される注視情報の例について、図２０と図２１を参照して説明する。図２０と図２１は、コンテンツの注視情報の例を説明する図である。
【０１０３】
図２０の例にいては、画面が２ｘ２個に分割された場合におけるセグメントファイルが時系列に配信されている。その配信は図６に示した場合と同一である。すなわち、領域Ａにおいては、時刻Ｔ＝０ｓ乃至時刻Ｔ＝１２ｓのタイミングで、セグメントファイルSegment_a_1.mp4乃至Segment_a_7.mp4が配信されている。領域Ｂにおいては、時刻Ｔ＝０ｓ乃至時刻Ｔ＝１２ｓのタイミングで、セグメントファイルSegment_b_1.mp4乃至Segment_b_7.mp4が配信されている。領域Ｃにおいては、時刻Ｔ＝０ｓ乃至時刻Ｔ＝１２ｓのタイミングで、セグメントファイルSegment_c_1.mp4乃至Segment_c_7.mp4が配信されている。領域Ｄにおいては、時刻Ｔ＝０ｓ乃至時刻Ｔ＝１２ｓのタイミングで、セグメントファイルSegment_d_1.mp4乃至Segment_d_7.mp4が配信されている。すなわち、各領域のSRDの記述は、図７に示した場合と同一である。
【０１０４】
そして、領域Ａの時刻Ｔ＝０ｓ乃至時刻Ｔ＝１２ｓのタイミングのセグメントファイル（領域）の再生回数はそれぞれ、１０，１０，１００，１００，１０，１０，１０となっている。領域Ｂの時刻Ｔ＝０ｓ乃至時刻Ｔ＝１２ｓのタイミングのセグメントファイルの再生回数はそれぞれ、１００，１０，１０，１０，１００，１００，１０となっている。また、領域Ｃの時刻Ｔ＝０ｓ乃至時刻Ｔ＝１２ｓのタイミングのセグメントファイルの再生回数はそれぞれ、１０，１００，１０，１０，１０，１０，１０となっている。領域Ｄの時刻Ｔ＝０ｓ乃至時刻Ｔ＝１２ｓのタイミングのセグメントファイルの再生回数はそれぞれ、１０，１０，１０，１０，１０，１０，１００となっている。
【０１０５】
このように、領域ごとに１つのbitrateのセグメントファイルが配信されている場合、セグメントファイル名で領域情報と時刻情報を兼ねることができる。
【０１０６】
図２１の例においては、コンテンツの注視情報が、領域ごとに、時刻情報とセグメントファイル（領域）の送出回数で構成されている。具体的な送出回数は、図２０における場合と同様である。
【０１０７】
＜第２の実施の形態＞
＜配信システムのお薦め配信処理（図２２〜図３５）＞
以上のようにして注視情報を構築したコンテンツ管理サーバ２１は、その注視情報に基づいて、お薦め情報を生成し、端末装置２３に配信する。そこでこの場合の処理例として、以下、第１乃至第３の処理例を記載する。
【０１０８】
最初に、第１の処理例について、図２２と図２３を参照して説明する。第１の処理例においては、Timed metadata trackが、MPDと一緒にお薦めTimed metadata track を含む、AdaptationSetにより配信され、端末装置２３でtimed metadata trackの情報を基に注視領域のsegmentを取得することでお薦めの再生が実現される。
【０１０９】
最初に図２２を参照して、コンテンツ管理サーバ２１の処理について説明する。図２２は、コンテンツ管理サーバの処理を説明するフローチャートである。ステップＳ７１において判定部６１は、minimumUpdatePeriodであるかを判定する。すなわち、お薦め情報を更新する更新周期が予め定められており、その更新周期が経過したかが判定される。その更新周期がまだ経過していない場合には、経過するまでステップＳ７１の処理が繰り返される。
【０１１０】
更新周期（例えば１０秒間）が経過した場合、ステップＳ７２において取得部６３は、最新のコンテンツの注視情報を取得する。すなわち、構築部６５は、コンテンツの注視情報を記憶しており、その内容は図１９に示した処理で周期的に更新されている。そして最新のものが、読み出され、取得される。
【０１１１】
ステップＳ７３において更新部６４は、お薦めtimed metadataの内容を更新する。すなわち生成部６８により生成されたお薦め情報であるお薦めtimed metadataが記憶部６７に保持されており、その内容が、ステップＳ７２で更新された注視情報に対応するように更新される。お薦め情報については、図２４と図２５を参照して、またお薦めtimed metadataにつては、図２６と図２７を参照して後述する。
【０１１２】
ステップＳ７４において出力部６６は、timed metadataファイルをDASHオリジンサーバ３１にアップロードする。アップロードされたお薦めtimed metadataは、DASHキャッシュサーバ３２を介して端末装置２３に供給される。この点については,図２３を参照して後述する。その後処理はステップＳ７１に戻り、それ以降の処理が繰り返される。
【０１１３】
以上のようにして、お薦め情報（お薦めtimed metadataファイル）が周期的にDASHオリジンサーバ３１にアップロードされる。
【０１１４】
なお、この例の場合、MPDファイルには、timed metadata trackにアクセスするための情報が記述されているだけなので、実際のMPDファイルを書き換える必要はなく、書き換えたtimed metadata trackを更新するだけでよい。
【０１１５】
一方、端末装置２３は、お薦め情報を次のようにして利用する。この場合の処理について、図２３を参照して説明する。
【０１１６】
ステップＳ９１において端末装置２３のDASHクライアント４１のアクセス部１０１は、minimumUpdatePeriodであるかを判定する。すなわち、図２２のステップＳ７４において説明したように、コンテンツ管理サーバ２１は、お薦め情報の更新周期が経過するとtaimed metadataqを送信してくる。そこで更新周期がまだ経過していない場合には、経過するまでステップＳ９１の処理が繰り返される。
【０１１７】
更新周期が経過した場合、ステップＳ９２においてアクセス部１０１は、最新のMPDファイルをサーバーから取得する。例えば後述する図２８と図２９に示されるMPDファイルが取得される。すなわち、コンテンツ管理サーバ２１が図２２のステップＳ７４でDASHオリジンサーバ３１にアップロードしたお薦めtimed mediadataは、DASHキャッシュサーバ３２に供給されている。そこでこのお薦めtimed mediadataにアクセス可能な最新のMPDファイルがDASHキャッシュサーバ３２から取得される。以上のようにして、端末装置２３においては、例えば１０秒ごとに、後述する図２８と図２９に示されるような、最新のMPDファイルが取得される。
【０１１８】
ステップＳ９３においてメディアプレーヤ１０３は、お薦めを再生するかを判定する。この判定はユーザー４４からの指示に基づいて行われる。ユーザー４４から再生が指示されていない場合、処理はステップＳ９１に戻り、それ以降の処理が繰り返される。
【０１１９】
ステップＳ９３においてお薦めを再生すると判定された場合、ステップＳ９４においてMPD解析部１０２は、最新のtimed metadataファイルを取得する。最新のtimed metadataファイルは、ステップＳ９２で取得された最新のMPDファイルに基づいて取得される。上述したように、コンテンツ管理サーバ２１の図２２のステップＳ７４の処理により、DASHオリジンサーバ３１に（従ってDASHキャッシュサーバ３２に）アップロードされ、保持されているtimed metadataファイルは、周期的に最新のものに更新されている。
【０１２０】
ステップＳ９５においてメディアプレーヤ１０３は、現在時刻より後は、お薦めtimed metadataに沿って再生を行う。新しいお薦め情報であるお薦めtimed metadataは、ステップＳ９４で取得されたものである。その後、処理はステップＳ９１に戻り、それ以降の処理が繰り返される。
【０１２１】
以上のようにして、コンテンツ管理サーバ２１により収集、構築された注視情報に基づき生成されたお薦め情報が端末装置２３に配信され、それに沿ってコンテンツが再生される。
【０１２２】
コンテンツ管理サーバ２１によりコンテンツの注視情報に基づき生成されるお薦め情報は、例えば次のように構成されている。図２４は、コンテンツのお薦め情報の例を説明する図である。
【０１２３】
図２４の例は、図２０の注視情報に基づき生成されたお薦め情報を表している。すなわち、図２０に示される場合と同様に、４つの領域Ａ乃至領域Ｄのセグメントファイルが、時系列に沿って、各セグメントに記載されている回数だけ配信されている。このお薦め情報では、最も再生回数が多い領域を時系列に配置したものが、複数のユーザー４４が注目する領域のお薦め情報とされる。すなわち、再生回数が１００回の次のセグメント（領域）の時系列がお薦め情報とされる。
Ｔ＝０ｓ    Segment_b_1.mp4
Ｔ＝２ｓ    Segment_c_2.mp4
Ｔ＝４ｓ    Segment_a_3.mp4
Ｔ＝６ｓ    Segment_a_4.mp4
Ｔ＝８ｓ    Segment_b_5.mp4
Ｔ＝１０ｓ  Segment_b_6.mp4
Ｔ＝１２ｓ  Segment_d_7.mp4
【０１２４】
図２５は、コンテンツのお薦め情報の例を説明する図である。図２５の例は、図２１の注視情報に基づき生成されたお薦め情報を表している。すなわち、図２１に示される場合と同様に、４つの領域Ａ乃至領域Ｄのセグメントファイルの再生回数が時系列に配置されている。このお薦め情報でも、最も再生回数が多い領域を時系列に配置したものが、複数のユーザー４４が注目する領域のお薦め情報とされる。すなわち、再生回数が１００回の次のセグメント（領域）の時系列がお薦め情報とされる。
Ｔ＝０ｓ      領域Ｂ
Ｔ＝２ｓ      領域Ｃ
Ｔ＝４ｓ      領域Ａ
Ｔ＝６ｓ      領域Ａ
Ｔ＝８ｓ      領域Ｂ
Ｔ＝１０ｓ    領域Ｂ
Ｔ＝１２ｓ    領域Ｄ
【０１２５】
次に、図２２のステップＳ７３で更新され、ステップＳ７４でアップロードされるtimed metadataの例について図２６と図２７を参照して説明する。図２６と図２７は、タイムドメタデータの例を示す図である。
【０１２６】
図２６のMP4ファイルの例においては、TrackのSample Entryが’meta’とされている。これは、このトラックがメタデータトラックであることを表している。またSample Entryのproperty boxが”recommend”とされている。これはこのtrackがお薦め情報のtrackであることを示している。このtrackに対応するmdat領域には、お薦めmetadataが配置されている。すなわち、時系列にセグメントファイルの名称がSample dataとして格納されている。この例では、２秒間隔（Δ２ｓ）のセグメントファイルの名称が、領域ＢのSegment_b_1.mp4, 領域ＣのSegment_c_2.mp4, 領域ＡのSegment_a_3.mp4・・・と時系列に記述されている。つまり、領域ごとのセグメントファイル名が時間ごとに記述される。この時系列は、図２４の場合と同一である。
【０１２７】
図２７のMP4ファイルの例においても、TrackのSample Entryが’meta’とされ、Sample Entryのproperty boxが”recommend”とされている。このトラックに対応するmdat領域には、お薦めmetadataが配置されている。すなわち、時系列に領域情報として、DASH SRDパラメータが、Sample dataとして格納される。
【０１２８】
つまり、図２７の例では、領域の情報としてSRD情報が、timed metadataとして格納される。従って、１つの領域にbitrate（符号化速度）が異なる２以上のrepresentationを配信する場合には、領域情報だけを伝送することで、端末装置２３側で、同一の領域で、任意のbitrateのrepresentationを選択することが可能になる。
【０１２９】
なお、お薦め情報は、ISOBMFF（ISO Base Media File Format）の他のレイヤーに配置することもできる。
【０１３０】
次に、４分割した領域をSRDで記述するとともに、お薦めtrackを記述したMPDファイルの例を図２８と図２９に示す。図２８とそれに続く図２９は、MPDファイルの例を示す図である。
【０１３１】
図２９の最後のお薦めAdaptationSetには、<Role schemeIdUri＝"urn:mpeg:dash:role:201X" value＝"recommend"/>と記述されている。このRole descriptorは、このAdaptationSetがお薦め情報に関するものであることを表している。ここには、お薦め情報を記述したファイルsegment_recommend.mp4が記述されている。
【０１３２】
<Representation id＝"5" bandwidth＝"10000"dependencyId＝"1,2,3,4">は、Representation id＝1,2,3,4の4つの領域（tile A,tile B,Tile C,tile DのAdaptationSetで示されている領域）のお薦めであることを示している。
【０１３３】
minimumUpdatePeriod＝"PT10S"は、MPDファイルを更新する時間周期を明示している。つまりこの例では、１０秒置きに、MPDファイルが更新される（図２２のステップＳ７１、図２３のステップＳ９１）。従って、端末装置２３は、その時間経過後に、新しいMPDファイルを取得する（図２３のステップＳ９２）。コンテンツ管理サーバ２１は、最新のお薦め情報が記述されているsegment_recommend.mp4に更新する（図２２のステップＳ７４）。
【０１３４】
<EssentialProperty schemeIdUri＝"urn:mpeg:dash:MPDupdate:201X" value＝"segment,true"/>は、このAdaptationSetのsegmentの内容がMPDupdateにより更新されることを示す。
【０１３５】
ここで、図３０と図３１を参照して、trackのSampleにアクセスする概念について説明する。図３０と図３１は、タイムドメタデータの例を示す図である。図２６と図２７に示したMP4ファイルにおいては、MP4ファイルの仕組みとして、trackのSample Table boxを用いて、任意の時間のSampleにアクセスすることができる。
【０１３６】
すなわち、図２６に対応する図３０に示されるように、MP4ファイルにおいては、Sample Entryを含むSample Table Box内の時刻とアドレス情報に基づいて、mdat領域のSampleにアクセスすることができる。つまり、お薦め情報であるsegment_b_1.mp4, segment_c_2.mp4, segment_a_3.mp4等にアクセスすることができる。
【０１３７】
図２７に対応する図３１に示される場合においても、Table Box内の時刻とアドレス情報に基づいて、mdat領域に含まれるSample、つまり領域の情報であるSRD情報にアクセスすることができる。
【０１３８】
次に、コンテンツ管理サーバ２１が、構築した注視情報に基づいて、お薦め情報を生成し、端末装置２３に配信する場合の第２の処理例について、図３２と図３３を参照して説明する。図２２と図２３を参照して説明した第１の処理例においては、timed metadata trackによりお薦め情報を配信するようにしたが、この第２の処理例では、MPDファイルにお薦めsegmentの再生順序が列挙される。
【０１３９】
第２の処理例では、MPDファイルに時系列のsegment listを含む、お薦めAdaptationSetが配信され、端末装置２３側でsegment listの順序で取得することで注視領域のお薦めの再生が実現される。
【０１４０】
最初に図３２を参照して、コンテンツ管理サーバ２１の処理について説明する。ステップＳ１１１において判定部６１は、minimumUpdatePeriodであるかを判定する。すなわち、お薦め情報を更新する更新周期が経過したかが判定される。その更新周期がまだ経過していない場合には、経過するまでステップＳ１１１の処理が繰り返される。
【０１４１】
更新周期が経過した場合、ステップＳ１１２において取得部６３は、最新のコンテンツの注視情報を取得する。すなわち、構築部６５は、コンテンツの注視情報を記憶しており、そのうちの最新のものが、読み出され、取得される。
【０１４２】
ステップＳ１１３において更新部６４は、お薦めsegment listの内容を更新する。すなわち生成部６８により生成されたお薦め情報であるお薦めsegment listが記憶部６７に保持されており、その内容が、ステップＳ１１２で取得された最新の注視情報に対応するように更新される。お薦め情報については、図２４と図２５を参照して説明したとおりである。またお薦めsegment listにつては、図３５を参照して後述する。
【０１４３】
ステップＳ１１４において出力部６６は、更新されたMPDファイルをアップロードする。このアップロードもDASHオリジンサーバ３１に対して行われる。アップロードされたMPDファイルは、DASHキャッシュサーバ３２を介して端末装置２３に供給される。この点については,図３３を参照して後述する。その後処理はステップＳ１１１に戻り、それ以降の処理が繰り返される。
【０１４４】
以上のようにして、segment listが周期的にアップロードされる。
【０１４５】
なお、MPDファイルを更新せずに、ある時刻の固定のお薦めのAdaptaionSetを格納してもよい。その場合は、MPDファイルには type＝“static”と設定される。
【０１４６】
一方、端末装置２３は、お薦め情報が記述されたsegment listを次のようにして利用する。この場合の処理について、図３３を参照して説明する。
【０１４７】
ステップＳ１３１においてアクセス部１０１は、minimumUpdatePeriodであるかを判定する。すなわち、図３２のステップＳ１１１において説明したように、コンテンツ管理サーバ２１は、お薦め情報を更新する更新周期が経過するとMPDファイルを送信してくる。そこで更新周期がまだ経過していない場合には、経過するまでステップＳ１３１の処理が繰り返される。
【０１４８】
更新周期が経過した場合、ステップＳ１３２においてアクセス部１０１は、最新のMPDファイルをサーバーから取得する。すなわち、コンテンツ管理サーバ２１が図３２のステップＳ１１４でDASHオリジンサーバ３１にアップロードしたお薦めMPDファイルは、DASHキャッシュサーバ３２に供給されている。そこでお薦め情報が記述されたMPDファイルがDASHキャッシュサーバ３２から取得される。
【０１４９】
ステップＳ１３３においてメディアプレーヤ１０３は、お薦めを再生するかを判定する。ユーザー４４から再生が指示されていな場合、処理はステップＳ１３１に戻り、それ以降の処理が繰り返される。
【０１５０】
ステップＳ１３３においてお薦めを再生すると判定された場合、ステップＳ１３４においてメディアプレーヤ１０３は、新しいお薦め情報であるsegment listに沿って再生を行う。この再生は、現在再生時刻以降行われる。新しいお薦め情報であるお薦めsegment listは、ステップＳ１３２で取得されたMPDファイルに記述されているものである。その後、処理はステップＳ１３１に戻り、それ以降の処理が繰り返される。
【０１５１】
以上のようにして、コンテンツ管理サーバ２１により収集、構築された注視情報に基づき生成されたお薦め情報が端末装置２３に配信され、それに沿ってコンテンツが再生される。
【０１５２】
図３２のステップＳ１１４でアップロードされる、segment listが記述されたMPDファイルの例を,図３４と図３５を参照して説明する。図３４とそれに続く図３５は、MPDファイルの例を示す図である。
【０１５３】
図３５の最後のお薦めAdaptationSetには、<Role schemeIdUri＝"urn:mpeg:dash:role:201X" value＝"recommend"/>と記述されている。このRole descriptorは、このAdaptationSetがお薦め情報に関するものであることを表している。ここには、お薦め情報としてのsegment listが次のように記述されている。
＜SegmentList duration＝”2”>
＜SegmentURL media＝”segment_b_1.mp4”/>
＜SegmentURL media＝”segment_c_2.mp4”/>
＜SegmentURL media＝”segment_a_3.mp4”/>
＜SegmentURL media＝”segment_a_4.mp4”/>
＜SegmentURL media＝”segment_b_5.mp4”/>
＜SegmentURL media＝”segment_b_6.mp4”/>
＜SegmentURL media＝”segment_d_7.mp4”/>
・
・
・
【０１５４】
すなわちこの例では、時間の経過とともに、領域Ｃ、領域Ｃ、領域Ａ、領域Ａ、領域Ｂ、領域Ｂ、領域Ｄが、順次注目領域とされている。
【０１５５】
Representation id＝"5" bandwidth＝"10000"dependencyId＝"1,2,3,4">は、Representation id＝1,2,3,4の4つの領域のお薦めであることを示す。
【０１５６】
minimumUpdatePeriod＝"PT10S"は、１０秒置きに、MPDが更新されることを示す（図３２のステップＳ１１１）。従って端末装置２３は、その時間経過後に、新しいMPDファイルを取得する（図３３のステップＳ１３１,Ｓ１３２）。コンテンツ管理サーバ２１は、最新の<SegmentList duration＝"2">の内容に更新する（図３２のステップＳ１１３）。
【０１５７】
実際に行われる端末装置２３からCDNサーバ２２へのROIに応じたセグメントファイルのリクエスト情報を用いて、コンテンツ管理サーバ２１側でROI情報を蓄積するようにした。従って、端末装置２３とコンテンツ管理サーバ２１の間で、注視情報を収集するための特別な通信を行うことなく、嗜好情報をコンテンツ管理サーバ２１で構築可能になる。
【０１５８】
DASHキャッシュサーバ３２の配置等から配信地域を同定することが可能である。また、サービスにおいて、端末装置２３の情報を取得可能な場合、たとえば、年齢、性別、個人の嗜好などの情報ごとにデータを構築することもできる。
【０１５９】
コンテンツ管理サーバ２１が、注視情報に基づいて、お薦め情報を生成し、端末装置２３に配信する場合の第３の処理例について説明する。例えばCDNサーバ２２と端末装置２３との間で、MPDファイルのリクエスト時、あるいはセグメントファイルのリクエスト時に、お薦めパラメータを付加し、CDNサーバ２２はコンテンツ管理サーバ２１が生成したお薦め情報に基づいて、お薦めセグメントを送出することで自主的にお薦め情報の再生を実現する。
【０１６０】
MPDファイルのリクエストの場合、HTTPでMPDリクエストの際に、HTTPクエリ-に”RECCOMED”を付加する。CNDサーバ２２は、お薦めのセグメントを順次プッシュする。
【０１６１】
セグメントファイルのリクエストの場合、HTTPでセグメントファイルのリクエストの際に、HTTPクエリ-に”RECCOMED”を付加する。CDNサーバ２２は、お薦めのセグメントを順次プッシュする。例えば１０セグメントのように数が指定された場合は、その数のセグメントファイルだけpushする。例えばある値以下にbitrateが指定される等した場合は、その範囲で最適なbitrateのお薦めsegmentを順次プッシュする。
【０１６２】
このようにして、コンテンツ全体で注目されている領域のお薦め情報が伝送される。
【０１６３】
なお本技術は、その本質を逸脱しない範囲において、種々の変形例が存在しうる。
【０１６４】
＜本開示を適用したコンピュータの説明（図３６）＞
上述した一連の処理は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
【０１６５】
図３６は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
【０１６６】
コンピュータ２００において、CPU（Central Processing Unit）２０１，ROM（Read Only Memory）２０２，RAM（Random Access Memory）２０３は、バス２０４により相互に接続されている。
【０１６７】
バス２０４には、さらに、入出力インタフェース２０５が接続されている。入出力インタフェース２０５には、入力部２０６、出力部２０７、記憶部２０８、通信部２０９、及びドライブ２１０が接続されている。
【０１６８】
入力部２０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部２０７は、ディスプレイ、スピーカなどよりなる。記憶部２０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部２０９は、ネットワークインタフェースなどよりなる。ドライブ２１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア２１１を駆動する。
【０１６９】
以上のように構成されるコンピュータ２００では、CPU２０１が、例えば、記憶部２０８に記憶されているプログラムを、入出力インタフェース２０５及びバス２０４を介して、RAM２０３にロードして実行することにより、上述した一連の処理が行われる。
【０１７０】
コンピュータ２００（CPU２０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア２１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
【０１７１】
コンピュータ２００では、プログラムは、リムーバブルメディア２１１をドライブ２１０に装着することにより、入出力インタフェース２０５を介して、記憶部２０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部２０９で受信し、記憶部２０８にインストールすることができる。その他、プログラムは、ROM２０２や記憶部２０８に、あらかじめインストールしておくことができる。
【０１７２】
なお、コンピュータ２００が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
【０１７３】
また、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
【０１７４】
さらに、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
【０１７５】
また、本開示の実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。
【０１７６】
例えば、push-media-adapted指令において、符号化ビットレート以外の属性の範囲が指定されてもよい。
【０１７７】
なお、本開示は、以下のような構成もとることができる。
【０１７８】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１７９】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０１８０】
＜その他＞
本技術は、以下のような構成もとることができる。
（１）
複数の他の情報処理装置にネットワークを介して配信されるコンテンツを管理する情報処理装置であって、
複数の前記他の情報処理装置にリクエストに応じて配信された前記コンテンツのコンテンツ情報を取得する取得部と、
取得された前記コンテンツ情報に基づいて複数の前記他の情報処理装置の注視情報を構築する構築部と
を備える情報処理装置。
（２）
前記コンテンツ情報は、前記コンテンツを時間的に分割したセグメントのセグメントファイル情報である
前記（１）に記載の情報処理装置。
（３）
前記セグメントファイル情報は、対応するセグメントファイルのURLと、前記セグメントファイルが配信された回数を含む
前記（１）または（２）に記載の情報処理装置。
（４）
前記注視情報は、注視領域の時系列と前記注視領域が配信された回数を含む
前記（１）乃至（３）のいずれかに記載の情報処理装置。
（５）
前記注視情報は地域ごとに構築される
前記（１）乃至（４）のいずれかに記載の情報処理装置。
（６）
前記セグメントファイル情報は一定の時刻ごとに取得される
前記（１）乃至（５）のいずれかに記載の情報処理装置。
（７）
前記注視領域は、DASH SRD規格で記述される
前記（１）乃至（６）のいずれかに記載の情報処理装置。
（８）
前記注視情報に基づいて、複数の前記他の情報処理装置に配信されるお薦め情報を生成する
前記（１）乃至（７）のいずれかに記載の情報処理装置。
（９）
前記お薦め情報は、配信された回数が最も多い前記注視領域の時系列とされる
前記（１）乃至（８）のいずれかに記載の情報処理装置。
（１０）
前記お薦め情報は、timed metadata trackに記述される
前記（１）乃至（９）のいずれかに記載の情報処理装置。
（１１）
前記お薦め情報は、前記情報処理装置から出力されるMPDファイルのsegment listに記述される
前記（１）乃至（１０）のいずれかに記載の情報処理装置。
（１２）
複数の他の情報処理装置にネットワークを介して配信されるコンテンツを管理する情報処理装置が、
複数の前記他の情報処理装置にリクエストに応じて配信された前記コンテンツのコンテンツ情報を取得する取得ステップと、
取得された前記コンテンツ情報に基づいて複数の前記他の情報処理装置の注視情報を構築する構築ステップと
を含む情報処理方法。
（１３）
複数の他の情報処理装置にネットワークを介して配信されるコンテンツを管理する情報処理装置であって、
複数の前記他の情報処理装置にリクエストに応じて配信された前記コンテンツのコンテンツ情報を取得する取得部と、
取得された前記コンテンツ情報に基づいて複数の前記他の情報処理装置の注視情報を構築する構築部と、
前記注視情報に基づいて、複数の前記他の情報処理装置に配信されるお薦め情報を生成する生成部と
を備える情報処理装置。
（１４）
複数の他の情報処理装置にネットワークを介して配信されるコンテンツを管理する情報処理装置が、
複数の前記他の情報処理装置にリクエストに応じて配信された前記コンテンツのコンテンツ情報を取得する取得ステップと、
取得された前記コンテンツ情報に基づいて複数の前記他の情報処理装置の注視情報を構築する構築ステップと、
前記注視情報に基づいて、複数の前記他の情報処理装置に配信されるお薦め情報を生成する生成ステップと
を含む情報処理方法。
（１５）
ネットワークを介して他の情報処理装置からコンテンツの配信を受ける情報処理装置であって、
前記他の情報処理装置にリクエストして配信されてきた前記コンテンツのコンテンツ情報に基づいて生成されたお薦め情報を、前記他の情報処理装置から取得する取得部と、
前記お薦め情報に基づいて再生を行う再生部と
を備える情報処理装置。
（１６）
ネットワークを介して他の情報処理装置からコンテンツの配信を受ける情報処理装置が、
前記他の情報処理装置にリクエストして配信されてきた前記コンテンツのコンテンツ情報に基づいて生成されたお薦め情報を、前記他の情報処理装置から取得する取得ステップと、
前記お薦め情報に基づいて再生を行う再生ステップと
を含む情報処理方法。
【符号の説明】
【０１８１】
１１  配信システム，  ２１  コンテンツ管理サーバ，  ２２  CDNサーバ，  ２３  端末装置，  ３１  DASHオリジンサーバ，  ３２−１乃至３２−３  DASHキャッシュサーバ，  ４１  DASHクライアント，  ４２  表示装置，  ４３  GUI/姿勢角検出装置
【図１】
2018128097.tif 000003
【図２】
2018128097.tif 000004
【図３】
2018128097.tif 000005
【図４】
2018128097.tif 000006
【図５】
2018128097.tif 000007
【図６】
2018128097.tif 000008
【図７】
2018128097.tif 000009
【図８】
2018128097.tif 000010
【図９】
2018128097.tif 000011
【図１０】
2018128097.tif 000012
【図１１】
2018128097.tif 000013
【図１２】
2018128097.tif 000014
【図１３】
2018128097.tif 000015
【図１４】
2018128097.tif 000016
【図１５】
2018128097.tif 000017
【図１６】
2018128097.tif 000018
【図１７】
2018128097.tif 000019
【図１８】
2018128097.tif 000020
【図１９】
2018128097.tif 000021
【図２０】
2018128097.tif 000022
【図２１】
2018128097.tif 000023
【図２２】
2018128097.tif 000024
【図２３】
2018128097.tif 000025
【図２４】
2018128097.tif 000026
【図２５】
2018128097.tif 000027
【図２６】
2018128097.tif 000028
【図２７】
2018128097.tif 000029
【図２８】
2018128097.tif 000030
【図２９】
2018128097.tif 000031
【図３０】
2018128097.tif 000032
【図３１】
2018128097.tif 000033
【図３２】
2018128097.tif 000034
【図３３】
2018128097.tif 000035
【図３４】
2018128097.tif 000036
【図３５】
2018128097.tif 000037
【図３６】
2018128097.tif 000038
【手続補正書】
【提出日】平成30年6月13日(2018.6.13)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】００１８
【補正方法】変更
【補正の内容】
【００１８】
処理はステップＳ３１に戻り、それ以降の処理が繰り返される。コンテンツ管理サーバ２１からセグメントファイル情報の送信のリクエストを受けた場合、ステップＳ３５において送受信部８２は、コンテンツ管理サーバ２１に、蓄積したセグメントファイル情報を送信する。すなわち記憶部８５に記憶されているセグメントファイル情報が読み出され、送受信部８２から送信される。その後、処理はステップＳ３１に戻り、それ以降の処理が繰り返される。
［００９０］
なお、この例では、コンテンツ管理サーバ２１からのリクエストに応じてセグメントファイル情報を送信するようにした。しかし予め定められている一定時刻ごとにＤＡＳＨキャッシュサーバ３２の方からコンテンツ管理サーバ２１にセグメントファイル情報を送信するようにすることもできる。
［００９１］
セグメントファイル情報は、ユーザーの注視領域と時刻情報を有するセグメントファイルのＵＲＬと回数を有するので、ユーザー４４のＲＯＩ（Ｒｅｇｉｏｎ  ｏｆ  Ｉｎｔｅｒｅｓｔ）情報である。
［００９２］
なお、説明は省略するが、ＤＡＳＨオリジンサーバ３１も図１８の処理を実行し、セグメントファイル情報をコンテンツ管理サーバ２１に送信する。
［００９３］
このように、端末装置２３からリクエストされたセグメントに関するセグメントファイル情報を、リクエストを受けたＤＡＳＨキャッシュサーバ３２が収集、蓄積するだけである。従って、ＤＡＳＨキャッシュサーバ３２から端末装置２３に対して注視領域情報を収集するために特別の処理や通信が要求されることがない。
［００９４］
以上のように、ＤＡＳＨキャッシュサーバ３２とＤＡＳＨオリジンサーバ３１により、つまりＣＤＮサーバ２２により、セグメントファイル情報をコンテンツ管理サーバ２１に送信する処理が実行される。これに対応して、コンテンツ管理サーバ２１はセグメントファイル情報を蓄積し、注視情報を構築する処理を実行する。以下、このコンテンツ管理サーバ２１の処理について、図１９を参照して説明する。
［００９５］
図１９は、コンテンツ管理サーバの処理を説明するフローチャートである
【国際調査報告】
2018128097.tif 000039
2018128097.tif 000040
2018128097.tif 000041
2018128097.tif 000042