(57)【要約】  本開示は、ファイルの欠損データの修復をより容易に行うことができるようにする情報処理装置および方法に関する。データが不完全なファイルに関する要求に対する応答として、そのファイルの修復状況に関する情報を要求元に提供するようにする。また、要求に対する応答として供給される、データが不完全なファイルの修復状況に関する情報を取得し、その取得された修復状況に関する情報に基づいて、そのファイルの取得に関する制御を行うようにする。本開示は、例えば、情報処理装置、受信装置、または再生装置等に適用することができる。
2018070268.tif 000002
【特許請求の範囲】
【請求項１】
データが不完全なファイルに関する要求に対する応答として、前記ファイルの修復状況に関する情報を要求元に提供する応答処理部
を備える情報処理装置。
【請求項２】
前記修復状況に関する情報は、
前記ファイルの修復処理のステータスと、
前記ファイルの修復されていない欠損データのブロック数を示す情報と
を含む
請求項１に記載の情報処理装置。
【請求項３】
前記ステータスは、
修復が開始されたか否かを示す情報と、
修復が完了したか否かを示す情報と、
修復が失敗したか否かを示す情報と
を含む
請求項２に記載の情報処理装置。
【請求項４】
前記修復状況に関する情報は、前記ファイルの修復されていない欠損データのバイト数を示す情報をさらに含む
請求項２に記載の情報処理装置。
【請求項５】
前記応答処理部は、前記ファイルの修復状況に関する情報を、HTTP（HyperText Transfer Protocol）ヘッダとして前記応答のヘッダに付加して前記要求元に提供する
請求項１に記載の情報処理装置。
【請求項６】
前記応答処理部は、前記ファイルの修復状況に関する情報をMPEG DASH（Moving Picture Experts Group Dynamic Adaptive Streaming over HyperText Transfer Protocol）のSAND（Server and network assisted DASH）メッセージとして前記要求元に提供する
請求項１に記載の情報処理装置。
【請求項７】
前記応答処理部は、前記SANDメッセージにより、要求されたセグメントのファイルの修復状況に関する情報に加えて、他のセグメントのファイルの修復状況に関する情報をさらに提供する
請求項６に記載の情報処理装置。
【請求項８】
前記応答処理部は、前記SANDメッセージのResourceStatusメッセージを用いて前記ファイルの修復状況に関する情報を提供する
請求項６に記載の情報処理装置。
【請求項９】
前記応答処理部は、前記SANDメッセージの拡張メッセージを用いて前記ファイルの修復状況に関する情報を提供する
請求項６に記載の情報処理装置。
【請求項１０】
データが不完全なファイルに関する要求に対する応答として、前記ファイルの修復状況に関する情報を要求元に提供する
情報処理方法。
【請求項１１】
要求に対する応答として供給される、データが不完全なファイルの修復状況に関する情報を取得する取得部と、
前記取得部により取得された前記修復状況に関する情報に基づいて、前記ファイルの取得に関する制御を行う制御部と
を備える情報処理装置。
【請求項１２】
前記制御部は、前記修復状況に関する情報に基づいて、前記ファイルの取得先を、前記ファイルの供給元にするか、前記ファイルの供給元から前記ファイルを供給された前記応答の供給元にするかを選択し、
前記取得部は、さらに、前記制御部により選択された取得先から前記ファイルを取得する
請求項１１に記載の情報処理装置。
【請求項１３】
前記制御部は、前記ファイルの修復されていない欠損データの割合に基づいて、前記ファイルの取得先を選択する
請求項１２に記載の情報処理装置。
【請求項１４】
前記制御部は、さらに、前記ファイルの修復されていない欠損データのブロック数に基づいて、前記ファイルの取得先を選択する
請求項１３に記載の情報処理装置。
【請求項１５】
前記ファイルの修復されていない欠損データを修復する修復部をさらに備え、
前記制御部により、前記ファイルの取得先として前記応答の供給元が選択された場合、
前記取得部が、前記応答の供給元から前記ファイルを取得し、さらに、前記ファイルの供給元から前記欠損データに対応するデータを取得し、
前記修復部が、前記取得部により取得された前記ファイルの欠損データを、前記取得部により取得された前記データを用いて修復するように構成される
請求項１２に記載の情報処理装置。
【請求項１６】
前記取得部は、HTTP（HyperText Transfer Protocol）ヘッダとして供給される前記修復状況に関する情報を取得する
請求項１１に記載の情報処理装置。
【請求項１７】
前記取得部は、MPEG DASH（Moving Picture Experts Group Dynamic Adaptive Streaming over HyperText Transfer Protocol）のSAND（Server and network assisted DASH）メッセージとして供給される前記修復状況に関する情報を取得する
請求項１１に記載の情報処理装置。
【請求項１８】
前記制御部は、前記ファイルの再生までの余裕時間に応じて待機してから前記ファイルを取得させる
請求項１７に記載の情報処理装置。
【請求項１９】
前記取得部は、HTTP（HyperText Transfer Protocol） HEAD Request、または、HTTP GET Requestに対する応答として供給される前記修復状況に関する情報を取得する
請求項１１に記載の情報処理装置。
【請求項２０】
要求に対する応答として供給される、データが不完全なファイルの修復状況に関する情報を取得し、
取得された前記修復状況に関する情報に基づいて、前記ファイルの取得に関する制御を行う
情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、情報処理装置および方法に関し、特に、ファイルの欠損データの修復をより容易に行うことができるようにした情報処理装置および方法に関する。
【背景技術】
【０００２】
従来、ISO base media file formatのファイルがモバイルネットワークのマルチキャスト/ブロードキャスト（MBMS（Multimedia Multicast and Broadcast Service））や放送（例えばATSC（Advanced Television Systems Committee）3.0）などのパケット・ロス等が考えられる伝送方式で伝送されることがある。その場合、受信側でのFEC（Forward Error Correction）処理などを経ても一部のデータが復元されず、一部データが欠損したファイル（パーシャルファイル（Partial File）とも称する）が生成されることがある。このようなファイルでは、データが欠損している部分を示す情報および修復のための情報（伝送元ファイルのURL（Uniform Resource Locator）など）が保持されることになる（例えば、非特許文献１参照）。【０００３】
さらに、その受信後、蓄積後にユニキャスト伝送によってデータ欠損部分を補う修復を行うことができ、その過程における修復状況をパーシャルファイル内に記録することも考えられた。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】Jean Le Feuvre, Telecom ParisTech, WD of Partial File Storage, INTERNATIONAL ORGANISATION FOR STANDARDISATION ORGANISATION INTERNATIONALE DE NORMALISATION ISO/IEC JTC1/SC29/WG11 CODING OF MOVING PICTURES AND AUDIO,ISO/IEC JTC1/SC29/WG11,N16167,June 2016
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、そのパーシャルファイルに対するアプリケーションクライアントからのリクエストに対して、そのパーシャルファイルの修復状況に関する情報を提供することができなかった。したがって、クライアントは、ファイル内のデータ欠損部分に関する情報を実際に処理（解読）するまでこれらの情報を得ることができなかった、そのため、そのファイルを利用するか他の代替ファイルを取得し直すかの判断を迅速に行うことができず、ファイルの欠損データの修復が困難になるおそれがあった。【０００６】
本開示は、このような状況に鑑みてなされたものであり、ファイルの欠損データの修復をより容易に行うことができるようにするものである。
【課題を解決するための手段】
【０００７】
本技術の一側面の情報処理装置は、データが不完全なファイルに関する要求に対する応答として、前記ファイルの修復状況に関する情報を要求元に提供する応答処理部を備える情報処理装置である。【０００８】
前記修復状況に関する情報は、前記ファイルの修復処理のステータスと、前記ファイルの修復されていない欠損データのブロック数を示す情報とを含むようにすることができる。【０００９】
前記ステータスは、修復が開始されたか否かを示す情報と、修復が完了したか否かを示す情報と、修復が失敗したか否かを示す情報とを含むようにすることができる。【００１０】
前記修復状況に関する情報は、前記ファイルの修復されていない欠損データのバイト数を示す情報をさらに含むようにすることができる。【００１１】
前記応答処理部は、前記ファイルの修復状況に関する情報を、HTTP（HyperText Transfer Protocol）ヘッダとして前記応答のヘッダに付加して前記要求元に提供することができる。【００１２】
前記応答処理部は、前記ファイルの修復状況に関する情報をMPEG DASH（Moving Picture Experts Group Dynamic Adaptive Streaming over HyperText Transfer Protocol）のSAND（Server and network assisted DASH）メッセージとして前記要求元に提供することができる。【００１３】
前記応答処理部は、前記SANDメッセージにより、要求されたセグメントのファイルの修復状況に関する情報に加えて、他のセグメントのファイルの修復状況に関する情報をさらに提供することができる。【００１４】
前記応答処理部は、前記SANDメッセージのResourceStatusメッセージを用いて前記ファイルの修復状況に関する情報を提供することができる。【００１５】
前記応答処理部は、前記SANDメッセージの拡張メッセージを用いて前記ファイルの修復状況に関する情報を提供することができる。【００１６】
本技術の一側面の情報処理方法は、データが不完全なファイルに関する要求に対する応答として、前記ファイルの修復状況に関する情報を要求元に提供する情報処理方法である。【００１７】
本技術の他の側面の情報処理装置は、要求に対する応答として供給される、データが不完全なファイルの修復状況に関する情報を取得する取得部と、前記取得部により取得された前記修復状況に関する情報に基づいて、前記ファイルの取得に関する制御を行う制御部とを備える情報処理装置である。【００１８】
前記制御部は、前記修復状況に関する情報に基づいて、前記ファイルの取得先を、前記ファイルの供給元にするか、前記ファイルの供給元から前記ファイルを供給された前記応答の供給元にするかを選択し、前記取得部は、さらに、前記制御部により選択された取得先から前記ファイルを取得することができる。【００１９】
前記制御部は、前記ファイルの修復されていない欠損データの割合に基づいて、前記ファイルの取得先を選択することができる。【００２０】
前記制御部は、さらに、前記ファイルの修復されていない欠損データのブロック数に基づいて、前記ファイルの取得先を選択することができる。【００２１】
前記ファイルの修復されていない欠損データを修復する修復部をさらに備え、前記制御部により、前記ファイルの取得先として前記応答の供給元が選択された場合、前記取得部が、前記応答の供給元から前記ファイルを取得し、さらに、前記ファイルの供給元から前記欠損データに対応するデータを取得し、前記修復部が、前記取得部により取得された前記ファイルの欠損データを、前記取得部により取得された前記データを用いて修復するように構成されるようにすることができる。【００２２】
前記取得部は、HTTP（HyperText Transfer Protocol）ヘッダとして供給される前記修復状況に関する情報を取得することができる。【００２３】
前記取得部は、MPEG DASH（Moving Picture Experts Group Dynamic Adaptive Streaming over HyperText Transfer Protocol）のSAND（Server and network assisted DASH）メッセージとして供給される前記修復状況に関する情報を取得することができる。【００２４】
前記制御部は、前記ファイルの再生までの余裕時間に応じて待機してから前記ファイルを取得させることができる。【００２５】
前記取得部は、HTTP（HyperText Transfer Protocol） HEAD Request、または、HTTP GET Requestに対する応答として供給される前記修復状況に関する情報を取得することができる。【００２６】
本技術の他の側面の情報処理方法は、要求に対する応答として供給される、データが不完全なファイルの修復状況に関する情報を取得し、取得された前記修復状況に関する情報に基づいて、前記ファイルの取得に関する制御を行う情報処理方法である。【００２７】
本技術の一側面の情報処理装置および方法においては、データが不完全なファイルに関する要求に対する応答として、そのファイルの修復状況に関する情報が要求元に提供される。【００２８】
本技術の他の側面の情報処理装置および方法においては、要求に対する応答として供給される、データが不完全なファイルの修復状況に関する情報が取得され、その取得された修復状況に関する情報に基づいて、そのファイルの取得に関する制御が行われる。
【発明の効果】
【００２９】
本開示によれば、情報を処理することができる。特に、ファイルの欠損データの修復をより容易に行うことができる。
【図面の簡単な説明】
【００３０】
【図１】通信システムの主な構成例を示す図である。
【図２】受信装置の主な構成例を示すブロック図である。
【図３】Partial FileContainer Boxの主な構成例を示す図である。
【図４】Partial File Block Map Boxのシンタクスの例を示す図である。
【図５】flagsおよびrecovered_flagsのセマンティクスの例を示す図である。
【図６】ファイル修復処理の主な流れの例を説明するフローチャートである。
【図７】応答処理の主な流れの例を説明するフローチャートである。
【図８】HTTPヘッダの例を示す図である。
【図９】MPEG DASHのSANDメッセージのResourceStatusメッセージに関する規定の例を示す図である。
【図１０】リクエストとResourceStatusメッセージを用いたレスポンスの例を示す図である。
【図１１】応答処理の主な流れの例を説明するフローチャートである。
【図１２】MPEG DASHのSANDメッセージのResourceRepairStatusメッセージに関する規定の例を示す図である。
【図１３】各ステータスのセマンティクスの例を示す図である。
【図１４】ResourceRepairStatusメッセージを用いたレスポンスの例を示す図である。
【図１５】ファイル取得処理の主な流れの例を説明するフローチャートである。
【図１６】ファイル取得処理の主な流れの例を説明するフローチャートである。
【図１７】ファイル取得処理の主な流れの例を説明するフローチャートである。
【図１８】コンピュータの主な構成例を示すブロック図である。
【発明を実施するための形態】
【００３１】
以下、本開示を実施するための形態（以下実施の形態とする）について説明する。なお、説明は以下の順序で行う。
１．第１の実施の形態（通信システム）
２．その他
【００３２】
＜１．第１の実施の形態＞
＜欠損データを含むファイル＞
従来、ISO base media file formatのファイルがモバイルネットワークのマルチキャスト/ブロードキャスト（MBMS（Multimedia Multicast and Broadcast Service））や放送（例えば ATSC（Advanced Television Systems Committee）3.0）などのパケット・ロス等が考えられる伝送方式で伝送されることがある。その場合、受信側でのFEC（Forward Error Correction）処理などを経ても一部のデータが復元されず、一部データが欠損したファイル（パーシャルファイル（Partial File）とも称する）が生成されることがある。例えば非特許文献１に記載のように、このようなファイルについて、データが欠損している部分を示す情報および修復のための情報（伝送元ファイルのURLなど）を保持することが考えられた。さらに、その受信後、蓄積後にユニキャスト伝送によってデータ欠損部分を補う修復を行うことができ、その過程における修復状況をパーシャルファイル内に記録することも考えられた。
【００３３】
ところで、3GPPでは、クライアント（Client）とプロキシ（Proxy）との間でのパーシャルファイルの取り扱いを想定して、以下のコンテントタイプ（content-type）をHTTP（HyperText Transfer Protocol）拡張ヘッダーで指定することが 規定されている（例えば、3GPP TS 26.247 http://www.arib.or.jp/english/html/overview/doc/STD-T63V12_00/5_Appendix/Rel13/26/26247-d20.pdf参照）。
【００３４】
Accept: application/3gpp-partial
Content-type: application/3gpp-partial
【００３５】
これらのうち前者は、クライアントからプロキシに対してパーシャルファイルを受け付ける（処理可能である）ことを示すために使われ、後者はプロキシからクライアントにそのレスポンスで返されるファイルがパーシャルファイルであることを示すために使われる。
【００３６】
また、MPEG DASH（Moving Picture Experts Group Dynamic Adaptive Streaming over HTTP）では、SAND（Server and Network Assisted DASH）において、この場合のプロキシやCDNエッジサーバがクライアントに対してDASHセグメント（segment）のキャッシュ状況（アベイラビリティ（availability））を知らせるステータス（status）メッセージが定義されている（例えば、ISO/IEC JTC 1/SC 29/WG 11, Information Technology - Dynamic adaptive streaming over HTTP (DASH) - Part 5: Server and network assisted DASH (SAND), FDIS ISO/IEC 23009-5, N15991, 2015-02-19参照)。
【００３７】
しかしながら、パーシャルファイルが修復処理中であることや、またどれだけのデータ欠損部分が残されているか等の、パーシャルファイルの修復状況に関する情報を、クライアントに提供することができなかった。したがって、クライアントは、ファイル内のデータ欠損部分に関する情報を実際に処理（解読）するまでこれらの情報を得ることができなかった、そのため、そのファイルを利用するか他の代替ファイルを取得し直すかの判断を迅速に行うことができず、ファイルの欠損データの修復が困難になるおそれがあった。
【００３８】
また、クライアントからリクエストされたファイルがMPEG DASHのメディア・セグメントであり、そのセグメントよりも時間的に後のセグメントがパーシャルファイルであるような場合に、それを事前にクライアントに知らせることができなかった。また、要求されたセグメントと同一アダプテーションセット（Adaptation Set）内の他のリプレゼンテーション（Representation）のメディア・セグメントがパーシャルファイルであるような場合にも、それを事前にクライアントに知らせることができなかった。
【００３９】
＜修復状況の通知＞
そこで、データが不完全なファイルに関する要求に対する応答として、そのファイルの修復状況に関する情報を要求元に提供するようにする。このようにすることにより、クライアントは、パーシャルファイルの修復状況に関する情報をより容易に取得することができるので、その情報に基づいて、ファイルの欠損データの修復をより容易に行うことができる。
【００４０】
＜通信システム＞
図１は、本技術を適用した通信システムの一実施の形態の主な構成例を示す図である。図１に示される通信システムは、画像や音声等のファイルを伝送し、伝送先で再生するシステムである。受信装置１００は、放送局１１から供給される画像や音声等のコンテンツのデータを受信し、再生する装置である。受信装置１００は、ローカルプロキシ（Local Proxy）１０１とアプリケーションクライアント（Application Client）１０２とを有する。ローカルプロキシ１０１は、本技術を適用した情報処理装置の一実施の形態であり、このコンテンツのデータの受信に関する処理を行う。アプリケーションクライアント１０２は、本技術を適用した情報処理装置の一実施の形態であり、ローカルプロキシ１０１により受信されたデータの再生に関する処理を行う。
【００４１】
ローカルプロキシ１０１は、放送局１１から送信される、コンテンツのデータを含むファイル２１を取得し、蓄積する。このファイル２１は、モバイルネットワークのマルチキャスト/ブロードキャスト（MBMS）や放送（例えばATSC3.0）などのパケット・ロス等が考えられる伝送方式で伝送される（lossy link）。したがって、ローカルプロキシ１０１が取得した時点で、このファイル２１の一部のデータが欠損していることがあり得る。
【００４２】
このように受信したファイル２１に欠損データ（例えば、図１のファイル２１の斜線部分）が生じた場合、ローカルプロキシ１０１は、その欠損した部分を修復することができる（repair client）。例えば、ローカルプロキシ１０１は、ファイル２１を提供するファイルサーバ１２（ソースサーバ（Source Server）とも称する）にアクセスし、そのファイル２１の欠損した部分のデータ２２（欠損データに対応するデータ）を取得する。そして、ローカルプロキシ１０１は、そのデータ２２を用いて、ファイル２１の欠損した部分を修復する。
【００４３】
これに対して、アプリケーションクライアント１０２は、適宜、ローカルプロキシ１０１にアクセスし、ローカルプロキシ１０１が蓄積しているファイルの中から再生するファイル（再生ファイル２３）を取得し、再生する。
【００４４】
このアプリケーションクライアント１０２の処理を、上述したローカルプロキシ１０１の修復処理とは独立に行うようにすると、アプリケーションクライアント１０２は、修復が完了していない再生ファイル２３（欠損データ（例えば図１の再生ファイル２３の斜線部分）を含む再生ファイル２３）を取得してしまう可能性がある。アプリケーションクライアントにおいても修復は可能であるが、ファイルを取得するまで修復状況を把握することができないので、修復が遅くなってしまう可能性がある。場合によっては、修復が間に合わず、正しく再生することができなくなる可能性がある。
【００４５】
そこで、ローカルプロキシ１０１は、アプリケーションクライアント１０２からの再生ファイルの要求に対して、そのファイルの修復状況に関する情報を提供する。アプリケーションクライアント１０２は、その修復状況に関する情報に基づいて、そのファイルの取得や修復を制御する。
【００４６】
＜ローカルプロキシ＞
図２は、受信装置１００の主な構成例を示すブロック図である。図２に示されるように、ローカルプロキシ１０１は、データ受信部１１１、蓄積部１１２、修復処理部１１３、ファイル情報生成部１１４、およびHTTPサーバ１１５を有する。データ受信部１１１は、放送局１１からのファイルの受信に関する処理を行う。蓄積部１１２は、任意の記憶媒体を有し、データ受信部１１１により受信されたファイルを蓄積（記憶）する。蓄積部１１２は、記憶しているファイルを必要に応じて任意の処理部に供給する。修復処理部１１３は、ファイルの欠損データの修復に関する処理を行う。ファイル情報生成部１１４は、アプリケーションクライアント１０２に提供するファイルに関する情報（ファイル情報）の生成に関する処理を行う。例えば、ファイル情報生成部１１４は、アプリケーションクライアント１０２から要求されたファイルに関する情報、若しくは、そのファイルに関連するファイルに関する情報、またはその両方を蓄積部１１２より取得し、それらの情報を用いて、アプリケーションクライアント１０２からの要求に対する応答（レスポンス（Response））に含めるレスポンスヘッダ、若しくは、SANDメッセージやSANDヘッダ、またはその両方を生成し、それらをHTTPサーバ１１５に供給する。HTTPサーバ１１５は、本技術を適用した応答処理部の一実施の形態であり、アプリケーションクライアント１０２（HTTPクライアント１２１）との通信に関する処理を行う。
【００４７】
＜アプリケーションクライアント＞
また、図２に示されるように、アプリケーションクライアント１０２は、HTTPクライアント１２１、取得ファイル判断部１２２、修復処理部１２３、および再生部１２４を有する。HTTPクライアント１２１は、本技術を適用した取得部の一実施の形態であり、ローカルプロキシ１０１（HTTPサーバ１１５）やファイルサーバ１２との通信に関する処理を行う。取得ファイル判断部１２２は、本技術を適用した制御部の一実施の形態であり、ファイルの取得先の設定に関する処理を行う。修復処理部１２３は、本技術を適用した修復部の一実施の形態であり、ファイルの欠損データの修復に関する処理を行う。再生部１２４は、ファイルの再生に関する処理を行う。
【００４８】
＜データの受信と修復＞
データ受信部１１１は、放送局１１等から供給されるファイルを受信する。このファイルの伝送方式は任意であるが、このファイル伝送において、ファイルにデータの欠損が生じる可能性があるものとする。例えば、モバイルネットワークのマルチキャスト/ブロードキャスト（MBMS）や放送（例えば ATSC3.0）などのようにパケット・ロス等の発生が起こり得る伝送方式により伝送されるものとする。また、このファイルに含まれるデータはどのようなものであってもよい。例えば、画像データや音声データであってもよいし、それら以外のデータであってもよい。また、フォーマットも任意である。
【００４９】
データ受信部１１１は、このファイルを受信すると、それを蓄積部１１２に供給し、記憶させる。蓄積部１１２に蓄積されるファイルに欠損データが存在する（データに欠損部分が存在する）場合、修復処理部１１３は、そのファイルの修復を行うことができる。
【００５０】
＜Partial File Container Box＞
蓄積部１１２に蓄積されるファイルは、ISO base media file format(ISO/IEC 14496-12)に準拠して、欠損が発生したファイルデータをカプセル化するPartial File Storageという手法でカプセル化される。この手法では、欠損データが存在するファイルは、図３に示されるように、ISO base media file formatのBox構造のPartial File Container Boxによりカプセル化される。
【００５１】
具体的には、Partial File Container Boxは、Top Level Box Index Box, Original Source URL Box, Partial File Block Map Box、およびfile_dataにより構成される最上位のBoxである。
【００５２】
Top Level Box Index Boxには、所定のレベルのBoxの位置を示す情報が記述される。Original Source URL Boxには、修復用ファイルの取得先情報としてURL情報が記述される。Partial File Block Map Boxには、欠損データの位置とサイズを表す欠損情報や、その修復に関する情報である修復情報等が記述される。file_dataは、データ受信部１１１により受信されたファイルの欠損データ（Corrupted data）の部分にダミーデータが配置された放送データである。従って、file_dataのサイズは、データ受信部１１１により受信されるべきファイルのサイズと同一である。
【００５３】
＜シンタクス＞
図４に示されるシンタクス１５１は、図３のPartial File Block Map Boxのシンタクスの例を示す。図４のシンタクス１５１に示されるように、データ欠損部に関する情報は、欠損が生じているデータブロックごとに１つのエントリを持つ。そして、それぞれがファイルの先頭からのバイト・オフセットとサイズを持つだけでなく、修復の状況を表す２種類のステータスフラグを持つ。そのうちの一方のステータスフラグ（flags）はファイル全体の修復状況（修復処理のステータス）を表すものであり、他方のステータスフラグ（recovered_flags）は各エントリごとの修復状況（修復処理のステータス）を表すものである。
【００５４】
＜セマンティクス＞
図５のセマンティクス１５２は、これらのフラグ（flags, recovered_flags）のセマンティクスの例を示す。セマンティクス１５２に示されるように、ステータスフラグ（flags）は、２進数の１桁目において修復が開始されたか否かを示し、２桁目において修復が完了したか否かを示し、３桁目において修復が失敗したか否かを示す。また、ステータスフラグ（recovered_flags）は、２進数の１桁目において修復が行われたか否かを示し、２桁目において修復が失敗したか否かを示す。
【００５５】
＜ファイル修復処理の流れ＞
次に、このローカルプロキシ１０１によるファイルの修復について説明する。ローカルプロキシ１０１は、ファイル修復処理を実行して、蓄積部１１２に蓄積されているファイルの欠損データの修復を行う。図６のフローチャートを参照してそのファイル修復処理の流れの例を説明する。
【００５６】
ファイル修復処理が開始されると、修復処理部１１３は、ステップＳ１０１において、Partial File Block Map Boxのstarted_repair_process flagを立てる。例えば、修復処理部１１３は、ステータスフラグ（flags）の２進数の１桁目の値を「１」にセットする。また、ステップＳ１０２において、修復処理部１１３は、変数iを「１」（初期値）にセットする。
【００５７】
ステップＳ１０３において、修復処理部１１３は、その変数iがエントリカウント（entry_count）の値以下であるか否かを判定する。エントリカウント（entry_count）は、欠損データの数（エントリ数）を示す変数である。変数iがエントリカウント（entry_count）の値以下である場合、処理はステップＳ１０４に進む。
【００５８】
ステップＳ１０４において、修復処理部１１３は、ｉ番目のエントリ（entry）のステータスフラグ（recovered_flags）の値が0x01または0x02であるか否かを判定する。ｉ番目のエントリのステータスフラグ（recovered_flags）の値が0x01でなく、かつ、0x02でないと判定された場合、すなわち、ｉ番目のエントリのステータスフラグ（recovered_flags）の値が0x00である（修復が行われていない）と判定された場合、処理はステップＳ１０５に進む。
【００５９】
ステップＳ１０５において、修復処理部１１３は、そのi番目のエントリの修復を試みる。例えば、修復処理部１１３は、ファイルサーバ１２にアクセスし、その欠損データ（i番目のエントリ）に対応するデータ（修正データ）を要求する。ファイルサーバ１２（HTTPサーバとも称する）は、放送局１１が供給するファイルのデータを提供するサーバであり、修復処理部１１３からの修正データ要求に対する応答として、その要求された修正データを修復処理部１１３に供給する。修復処理部１１３は、その修正データを取得し、その修正データをi番目のエントリのダミーデータと置き換える。
【００６０】
ステップＳ１０６において、修復処理部１１３は、以上のような修復が成功したか否かを判定する。ダミーデータを正しいデータに置き換えることができ、修復が成功したと判定された場合、処理はステップＳ１０７に進む。ステップＳ１０７において、修復処理部１１３は、そのi番目のエントリのステータスフラグ（recovered_flags）に値「0x01」（Recovered（has been repaired））をセットする。ステップＳ１０７の処理が終了すると処理はステップＳ１１０に進む。
【００６１】
また、ステップＳ１０６において、修復が失敗したと判定された場合、処理はステップＳ１０８に進む。ステップＳ１０８において、修復処理部１１３は、そのi番目のエントリのステータスフラグ（recovered_flags）に値「0x02」（Fail_to_repair）をセットする。そして、ステップＳ１０９において、修復処理部１１３は、Partial File Block Map Boxのsome entries failed to repair flagを立てる。例えば、修復処理部１１３は、ステータスフラグ（flags）の２進数の３桁目の値を「１」にセットする。ステップＳ１０９の処理が終了すると処理はステップＳ１１０に進む。
【００６２】
ステップＳ１１０において、修復処理部１１３は、データ修復を中止するか否かを判定する。例えば、アプリケーションクライアント１０２からファイルの要求を受ける等して、データ修復を中止すると判定された場合、データの修復が中止され、ファイル修復処理が終了する。
【００６３】
また、ステップＳ１１０において、データ修復を継続すると判定された場合、処理はステップＳ１１１に進む。また、ステップＳ１０４において、ｉ番目のエントリのステータスフラグ（recovered_flags）の値が0x01または0x02であると判定された場合、すなわち、ｉ番目のエントリの修復の試みが行われた（成功したか否かには関わらない）と判定された場合、処理はステップＳ１１１に進む。つまり、このエントリに対する修復の試みは省略される。ステップＳ１１１において、修復処理部１１３は、変数iをインクリメント（i＋＋）し、処理対象を次のエントリに更新する。ステップＳ１１１の処理が終了すると、処理はステップＳ１０３に戻り、新たな処理対象のエントリに対して、それ以降の処理が行われる。
【００６４】
そして、ステップＳ１０３において、変数iがエントリカウント（entry_count）の値より大きいと判定された場合、処理はステップＳ１１２に進む。ステップＳ１１２において、修復処理部１１３は、Partial File Block Map Boxのhave been finished repair process flagを立てる。例えば、修復処理部１１３は、ステータスフラグ（flags）の２進数の２桁目の値を「１」にセットする。ステップＳ１１２の処理が終了するとファイル修復処理が終了する。
【００６５】
以上のように、欠損データの修復状況に応じて、ステータスフラグ（flags）と、各エントリのステータスフラグ（recovered_flags）が更新される。したがって、これらのステータスフラグによりどこまでの修復が完了したか、すなわち、修復状況が示される。
【００６６】
＜ファイルの要求と応答１＞
HTTPサーバ１１５は、アプリケーションクライアント１０２のHTTPクライアント１２１と通信を行い、そのHTTPクライアント１２１からの要求を受け付け、その要求に対する応答を返す。例えば、HTTPクライアント１２１が、蓄積部１１２に蓄積されているファイルの取得要求（ファイル要求）をHTTPサーバ１１５に対して供給すると、HTTPサーバ１１５はそのファイル要求を受け付ける。ファイル情報生成部１１４は、その要求に対する応答のヘッダを作成する。例えば、ファイル情報生成部１１４は、アプリケーションクライアント１０２から要求されたファイルに関する情報を蓄積部１１２より取得する。このファイルに関する情報は任意であるが、例えば、そのファイルの欠損情報や修復情報、より具体的には、修復処理のステータス、欠損データのブロック数やバイト数等の修復状況に関する情報が含まれる。ファイル情報生成部１１４は、これらの情報を用いて、レスポンスヘッダを生成する。つまり、ファイル情報生成部１１４は、要求されたファイルの修復状況に関する情報を含むレスポンスヘッダを生成する。ファイル情報生成部１１４は、生成したレスポンスヘッダをHTTPサーバ１１５に供給する。HTTPサーバ１１５は、要求されたファイルを蓄積部１１２から取得し、その取得したファイルと、ファイル情報生成部１１４により生成されたレスポンスヘッダとを用いてアプリケーションクライアント１０２からの要求に対する応答を生成し、その応答をHTTPクライアント１２１に返す。つまり、この応答には、例えば、要求されたファイルの他、そのファイルに関する情報や、そのファイルの修復状況に関する情報等が含まれる。
【００６７】
例えば、ローカルプロキシ１０１の修復処理部１１３が上述のようにパーシャルファイルの修復処理中に、HTTPサーバ１１５が、そのファイルを利用しようとするアプリケーションクライアント１０２（HTTPクライアント１２１）からのファイル取得要求、具体的にはそのファイルのURLに対するHTTP Requestを受信したとする。ここで、そのリクエストに「パーシャルファイル取得可」の指定がされていたものとする。
【００６８】
ローカルプロキシ１０１は、応答処理を実行し、その要求（HTTP Request）に対する応答を行う。図７のフローチャートを参照して、この応答処理の流れの例を説明する。応答処理が開始されると、HTTPサーバ１１５は、ステップＳ１３１において、要求（HTTP Request）において指定されたファイルが欠損データを含むパーシャルファイル（Partial File）であるか否かを判定する。指定されたファイルがパーシャルファイルでないと判定された場合、処理はステップＳ１３２に進む。ステップＳ１３２において、HTTPサーバ１１５は、指定されたファイルを通常の応答（responce）としてHTTPクライアント１２１に転送する。つまり、要求されたファイルがアプリケーションクライアント１０２に供給される。なお、この応答のヘッダは、ファイル情報生成部１１４が生成するようにしてもよい。ステップＳ１３２の処理が終了すると、応答処理が終了する。
【００６９】
また、ステップＳ１３１において、指定されたファイルがパーシャルファイルであると判定された場合、処理はステップＳ１３３に進む。ステップＳ１３３において、HTTPサーバ１１５は、HTTPクライアント１２１から供給されたリクエスト（HTTP Request）にパーシャルファイル取得可指定があるか否かを判定する。パーシャルファイル取得可指定が無く、アプリケーションクライアント１０２がパーシャルファイルを取得不可能であると判定された場合、処理はステップＳ１３４に進む。ステップＳ１３４において、HTTPサーバ１１５は、要求に対する応答として、エラー通知（404 file not foundエラー）を返答する。ステップＳ１３４の処理が終了すると、応答処理が終了する。
【００７０】
また、ステップＳ１３３において、リクエスト（HTTP Request）にパーシャルファイル取得可指定があると判定された場合、処理はステップＳ１３５に進む。ステップＳ１３５において、ファイル情報生成部１１４は、蓄積部１１２からファイルに関する情報（修復状況に関する情報等）を取得し、それを用いてレスポンスヘッダを生成する。例えば、ファイル情報生成部１１４は、パーシャルファイルの欠損データ情報テーブルに基づいて修復処理のステータス、欠損データのブロック数やバイト数等の修復状況を表すヘッダを生成し、それをレスポンスヘッダに付加する。ファイル情報生成部１１４は、このように生成した、修復状況を表すヘッダを含むレスポンスヘッダを、HTTPサーバ１１５に供給する。HTTPサーバ１１５は、そのレスポンスヘッダに、蓄積部１１２から取得したパーシャルファイルを付加してレスポンスとして転送する。つまり、ファイル情報生成部１１４は、要求されたパーシャルファイルのPartial File Block Map Boxを参照し、ステータスフラグ（flags）や各エントリのステータスフラグ（recovered_flag）、またはそれに準ずる情報を含むヘッダを生成し、それをレスポンスヘッダに付加する。そして、HTTPサーバ１１５は、そのレスポンスヘッダを含む応答により、要求されたパーシャルファイルをHTTPクライアント１２１に供給する。つまり、HTTPサーバ１１５は、パーシャルファイルとともに、そのパーシャルファイルの修復状況に関する情報をHTTPクライアント１２１に供給する。
【００７１】
ステップＳ１３５の処理が終了すると、応答処理が終了する。
【００７２】
図８のHTTP拡張ヘッダ１５３は、図７のステップＳ１３５において転送されるヘッダの例を示すものである。
【００７３】
図８において、x-partial-file-statusは、HTTPの拡張ヘッダであり、パーシャルファイルの修復状況を表すヘッダである。また、recovery_statusは、パーシャルファイル内のPartialFileBlockMapBoxのステータスフラグ（flags）の値によって指定される情報であり、修復処理のステータスを示す。例えば、このrecovery_statusの値が0x000001の場合、修復（repair）が開始されているが完了していない状態、すなわち一部未修復であることを示す。また、このrecovery_statusの値が0x000003の場合、修復（repair）が開始（start）されて終了（finish）し、完全に修復済みであることを示す。また、このrecovery_statusの値が0x000007の場合、修復処理は完了したが、一部修復できなかった部分があることを示す。
【００７４】
また、「修復されていない欠損データ・ブロック数」は、パーシャルファイル内のPartialFileBlockMapBoxの各エントリーのステータスフラグ（recovered_flags）の値が0x00であるエントリの数（つまり、欠損データのブロック数）を示す。「修復されていない欠損データのバイト数」は、パーシャルファイル内のPartialFileBlockMapBoxの各エントリのステータスフラグ（recovered_flags）の値が0x00であるエントリのcorrupted_size値の合計（つまり、欠損データのバイト数）を示す。なお、この情報は、オプションであり、必ずしもヘッダに加えなくてもよい。
【００７５】
以上のように、ローカルプロキシ１０１が、要求に対する応答として、パーシャルファイルの修復状況に関する情報を要求元に供給することにより、その要求元であるアプリケーションクライアント１０２は、その修復状況に関する情報に基づいて、ファイルの取得や修復を適切に制御することができる。したがって、ファイルの欠損データの修復をより容易に行うことができる。
【００７６】
＜ファイルの要求と応答２＞
また、アプリケーションクライアント１０２からリクエストされたファイルがMPEG DASHのメディアセグメント（media segment）である場合、リクエストされたファイルの後続セグメント（segment）について、それが 修復の必要なパーシャルファイル（Partial File）であるのかどうかをローカルプロキシ１０１が事前に検証し、その結果得られた情報を現在リクエストされているファイルのレスポンスのヘッダに付加してアプリケーションクライアント１０２に伝えることにより、アプリケーションクライアント１０２が次のメディアセグメントを選択する際の手助けとなる。
【００７７】
具体的には、MPEG DASHの拡張であるSANDにおいて、DASH clientにProxyなどのサーバー上のリソースの状況を知らせるResourceStatusメッセ―ジが規定されている。図９に示される表は、そのMPEG DASHのSANDメッセージのResourceStatusメッセージに関する規定の例を示している。アプリケーションクライアント１０２からリクエストされたファイルがMPEG DASHのメディアセグメントである場合、ローカルプロキシ１０１は、このように規定されるResourceStatusメッセージを用いて上述のような後続のセグメントの修復ステータスをアプリケーションクライアント１０２に提供することができる。より具体的には、ResourceStatusメッセ―ジのreasonの内容として、各メディアセグメントのファイルの情報を記述することができる。
【００７８】
SANDメッセージはXML（Extensible Markup Language）表現されることが想定されている。例えば、図１０のＡに示されるような記述のHTTPリクエスト１６１が、アプリケーションクライアント１０２より供給されると、ファイル情報生成部１１４は、そのリクエストに対して、図１０のＢに示されるようなSANDメッセージ１６２を生成する。なおパーシャルファイルの修復状況はreasonアトリビュートの値（string値）として表現される。
【００７９】
例えば、図１０のＢに示されるSANDメッセージ１６２では、図１０のＡのリクエスト１６１において指定されたファイル（aa0000.mp4）のセグメントの後続のセグメントのファイル（aa0001.mp4）のstatusがアベイラブル（available）であることが示されている。また、さらに後続のセグメントのファイル（aa0002.mp4）のstatusがアンアベイラブル（unavailable）であることも示されている。そして、その理由（パーシャルファイルであること等）がreasonに示されている。
【００８０】
なお、このようなSANDメッセージ（message）は、HTTPレスポンスの拡張ヘッダで示されるURLにアプリケーションクライアント１０２が、HTTP GET等のリクエストを行うことで伝達される。図１０のＣに示されるSANDヘッダ１６３は、その例を示す。例えば、アプリケーションクライアント１０２がHTTP GET request（例えば図１０のＡのリクエスト１６１）（HTTP HEAD requestでもよいし、それらの両方でもよい）をローカルプロキシ１０１に供給すると、ローカルプロキシ１０１は、SANDヘッダ（例えば図１０のＣのSANDヘッダ１６３）を含むレスポンスをアプリケーションクライアント１０２に返す。アプリケーションクライアント１０２は、そのSANDヘッダ内で指定されるURLに対して、HTTP GETを行って、SANDメッセージ（例えば図１０のＢのSANDメッセージ１６２）を取得する。
【００８１】
＜応答処理の流れ＞
この場合の応答処理の流れの例を、図１１のフローチャートを参照して説明する。応答処理が開始されると、HTTPサーバ１１５は、ステップＳ１５１において、リクエストされたファイルがDASHメディアセグメント（DASH media segment）のファイルであるか否かを判定する。DASHメディアセグメントのファイルであると判定された場合、処理はステップＳ１５２に進む。ステップＳ１５２において、HTTPサーバ１１５は、リクエストにより指定されたファイルのセグメントに後続のセグメントが存在するか否かを判定する。存在すると判定された場合、処理はステップＳ１５３に進む。
【００８２】
ステップＳ１５３において、HTTPサーバ１１５は、指定されたファイルのリプレゼンテーション（Representation）が属するアダプテーションセット（AdaptationSet）に、複数のリプレゼンテーション（Representation）が存在するか否かを判定する。存在すると判定された場合、処理はステップＳ１５４に進む。
【００８３】
ステップＳ１５４において、ファイル情報生成部１１４は、他のリプレゼンテーション（例えば、他のビットレート（bitrate）のリプレゼンテーション）の後続のセグメントを抽出する。ステップＳ１５４の処理が終了すると、処理はステップＳ１５５に進む。また、ステップＳ１５３において、複数のリプレゼンテーション（Representation）が存在しないと判定された場合、ステップＳ１５４の処理が省略され、処理はステップＳ１５５に進む。
【００８４】
ステップＳ１５５において、ファイル情報生成部１１４は、後続のセグメントについて、パーシャルファイルであるか否かや修復状況等を検証し、その検証結果に基づいてSANDメッセージを作成し、そのSANDメッセージのURLを生成する。
【００８５】
ステップＳ１５６において、ファイル情報生成部１１４は、リクエストされたファイルについてのステータスを表すヘッダや、ステップＳ１５５において生成したURLを含むSANDヘッダを生成し、リクエストに対するレスポンスに付加する。ステップＳ１５６の処理が終了すると、処理はステップＳ１５８に進む。
【００８６】
また、ステップＳ１５１において、リクエストがDASHメディアセグメントでないと判定された場合、処理はステップＳ１５７に進む。また、ステップＳ１５２において、後続のセグメントが存在しないと判定された場合、処理はステップＳ１５７に進む。ステップＳ１５７において、ファイル情報生成部１１４やHTTPサーバ１１５は、リクエストされたファイルについてのレスポンスを生成する。ステップＳ１５７の処理が終了すると、処理はステップＳ１５８に進む。
【００８７】
ステップＳ１５８において、HTTPサーバ１１５は、生成したレスポンスをアプリケーションクライアント１０２（HTTPクライアント１２１）に供給する。ステップＳ１５８の処理が終了すると、応答処理が終了する。
【００８８】
以上のように応答処理を行うことにより、ローカルプロキシ１０１は、MPEG DASHのSANDメッセージを用いて、ファイルの修復状況に関する情報を要求元であるアプリケーションクライアント１０２に提供することができる。これにより、後続のセグメントについての修復状況に関する情報も容易に提供することができるようになる。したがって、アプリケーションクライアント１０２がより早期に修復状況に関する情報に基づいてファイルの取得や修復を制御することができるようになるので、ファイルの取得や修復を適切に制御することができる。したがって、ファイルの欠損データの修復をより容易に行うことができる。
【００８９】
なお、既存のSANDメッセージを用いて修復状況に関する情報を提供するようにすることにより、メッセージの汎用性の低減を抑制することができ、例えば、既存のHTTPクライアント等、より多様なクライアントに対して修復状況に関する情報を提供することができる。
【００９０】
＜ファイルの要求と応答３＞
なお、既存のSANDメッセージ（ResourceStatus）を用いずに、修復状況に関する情報を表すための新たなメッセージを定義するようにしてもよい。例えば、図１２に示される表のように、新たなメッセージ（ResouceRepairStatus）を定義し、このResouceRepairStatusメッセージを用いて修復状況に関する情報を提供するようにしてもよい。
【００９１】
この場合、base URLをリプレゼンテーション（Representation）のbase URLとすれば、そのリプレゼンテーションに属する各メディアセグメント（media segment）に関するstatusを１つのResourceRepairStatusエレメントによって表現することができる。また、ResourceRepairStatusを複数併記することで、リクエストされたリプレゼンテーションと同一のアダプテーションセット（AdaptationSet）内の他のリプレゼンテーションの後続セグメントに相当するファイルに関するstatusも伝達することができる。
【００９２】
そのstatusのセマンティクスの例を図１３に示す。図１３に示されるように、この場合、アベイラブル（available）、パーシャル（partial）、アンダーリペア（under_repair）のいずれかをstatusにセットすることができる。なお、パーシャル（partial）およびアンダーリペア（under_repair）ステータス時のreasonの内容は、上述のResourceStatusメッセージの場合と同様である。
【００９３】
図１４に示されるSANDメッセージ１８１は、このように拡張したSANDメッセージの例を示す。図１４の例の場合、リクエストにより指定されたセグメントの後続のセグメントのファイル（aa0001.mp4）のstatusがアベイラブル（available）であること、さらに後続のセグメントのファイル（aa0002.mp4）のstatusがアンダーリペア（under_repair）であることが示されている。また、その理由がreasonに示されている。なお、この場合も、SANDヘッダは、既存のSANDメッセージ（ResourceStatus）を用いる場合と同様でよい。
【００９４】
このようにSANDメッセージを拡張することにより、修復状況に関する情報をより効率よく（より少ない情報量により）提供することができる。したがって、この修復状況に関する情報の取得によるクライアント側の負荷の増大を抑制することができる。
【００９５】
＜ファイルの取得判断＞
次に、修復状況に関する情報を提供されるアプリケーションクライアント１０２の処理について説明する。アプリケーションクライアント１０２は、要求に対する応答として供給される、データが不完全なファイルの修復状況に関する情報を取得し、その取得された修復状況に関する情報に基づいて、ファイルの取得や修復に関する制御を行う。このようにすることにより、アプリケーションクライアント１０２は、その修復状況に関する情報に基づいてファイルの取得や修復を適切に制御することができる。したがって、ファイルの欠損データの修復をより容易に行うことができる。
【００９６】
＜ファイル取得処理の流れ１＞
例えば、アプリケーションクライアント１０２の取得ファイル判断部１２２は、その修復状況に関する情報に基づいて、ローカルプロキシ１０１からファイルを取得してそのまま使うか、ローカルプロキシ１０１から取得したパーシャルファイルを自分で修復（Repair）するか、ファイル全体を元データを持つファイルサーバ１２（HTTPサーバ）から取得するか、などの判断を行うようにしてもよい。
【００９７】
その際、HTTPクライアント１２１は、HTTPレスポンスのヘッダとして供給される修復状況に関する情報を取得し、取得ファイル判断部１２２は、そのHTTPレスポンスのヘッダに含まれる修復状況に関する情報に基づいて、ファイルの取得や修復に関する制御を行うようにしてもよい。
【００９８】
その場合、例えば、取得ファイル判断部１２２は、ファイルの修復されていない欠損データの割合に基づいて、そのファイルの取得先を選択するようにしてもよい。
【００９９】
その場合の、アプリケーションクライアント１０２により実行されるファイル取得処理の流れの例を、図１５のフローチャートを参照して説明する。ファイル取得処理が開始されると、アプリケーションクライアント１０２のHTTPクライアント１２１は、ステップＳ１７１において、HTTP HEAD request若しくはHTTP GET request、またはその両方により、所望のファイルのヘッダ（header）情報を取得する。
【０１００】
ステップＳ１７２において、取得ファイル判断部１２２は、HTTPクライアント１２１により取得されたHTTPヘッダ情報に含まれる欠損データのバイト数に関する情報等に基づいて、欠損データの割合が所定の閾値以下であるか否かを判定する。なお、欠損データの割合ｚは、以下の式（１）のように算出される。
【０１０１】
ｚ＝（欠損データのバイト数）／（ファイル全体のバイト数）
・・・（１）
【０１０２】
欠損データの割合ｚが所定の閾値以下であると判定された場合、処理はステップＳ１７３に進む。この場合、取得ファイル判断部１２２は、ローカルプロキシ１０１からファイルを取得するように判断し、そのようにHTTPクライアント１２１を制御する。つまり、ステップＳ１７３において、HTTPクライアント１２１は、その制御に従って、ローカルプロキシ１０１から、パーシャルファイルを取得する。
【０１０３】
ステップＳ１７４において、HTTPクライアント１２１は、取得したパーシャルファイルの欠損データに対応するデータを、ファイルサーバ１２に要求し、取得する。修復処理部１２３は、そのデータを、そのデータに対応する欠損データと置き換えることにより、パーシャルファイルの修復を行う。ステップＳ１７４の処理が終了すると、ファイル取得処理が終了する。
【０１０４】
また、ステップＳ１７２において、欠損データの割合ｚが所定の閾値より大きいと判定された場合、処理はステップＳ１７５に進む。この場合、取得ファイル判断部１２２は、ファイルサーバ１２から欠損していないファイル全体を取得するように判断し、そのようにHTTPクライアント１２１を制御する。つまり、ステップＳ１７５において、HTTPクライアント１２１は、その制御に従って、ファイルサーバ１２（source file server）からファイル全体を取得する。ステップＳ１７５の処理が終了すると、ファイル取得処理が終了する。
【０１０５】
以上のようにファイル取得処理を行うことにより、アプリケーションクライアント１０２は、HTTPレスポンスのヘッダに含まれる修復状況に関する情報に基づいて、ファイルの取得や修復を適切に制御することができる。したがって、ファイルの欠損データの修復をより容易に行うことができる。
【０１０６】
＜ファイル取得処理の流れ２＞
また、例えば、取得ファイル判断部１２２は、さらに、ファイルの修復されていない欠損データのブロック数に基づいて、そのファイルの取得先を選択するようにしてもよい。
【０１０７】
その場合の、アプリケーションクライアント１０２により実行されるファイル取得処理の流れの例を、図１６のフローチャートを参照して説明する。ファイル取得処理が開始されると、アプリケーションクライアント１０２のHTTPクライアント１２１は、ステップＳ１９１において、HTTP HEAD request若しくはHTTP GET request、またはその両方により、所望のファイルのヘッダ（header）情報を取得する。
【０１０８】
ステップＳ１９２において、取得ファイル判断部１２２は、HTTPクライアント１２１により取得されたHTTPヘッダ情報に含まれる欠損データのバイト数に関する情報等に基づいて、欠損データの割合が所定の閾値以下であるか否かを判定する。なお、この場合も、欠損データの割合ｚは、上述の式（１）のように算出される。
【０１０９】
欠損データの割合ｚが所定の閾値以下であると判定された場合、処理はステップＳ１９３に進む。ステップＳ１９３において、取得ファイル判断部１２２は、HTTPクライアント１２１により取得されたHTTPヘッダ情報に含まれる欠損データのブロック数に関する情報等に基づいて、欠損データのブロック数が所定の閾値以下であるか否かを判定する。欠損データのブロック数が所定の閾値以下であると判定された場合、処理はステップＳ１９４に進む。
【０１１０】
この場合、取得ファイル判断部１２２は、ローカルプロキシ１０１からファイルを取得するように判断し、そのようにHTTPクライアント１２１を制御する。つまり、ステップＳ１９４において、HTTPクライアント１２１は、その制御に従って、ローカルプロキシ１０１から、パーシャルファイルを取得する。
【０１１１】
ステップＳ１９５において、HTTPクライアント１２１は、取得したパーシャルファイルの欠損データに対応するデータを、ファイルサーバ１２に要求し、取得する。修復処理部１２３は、そのデータを、そのデータに対応する欠損データと置き換えることにより、パーシャルファイルの修復を行う。ステップＳ１９５の処理が終了すると、ファイル取得処理が終了する。
【０１１２】
また、ステップＳ１９２において、欠損データの割合ｚが所定の閾値より大きいと判定された場合、処理はステップＳ１９６に進む。また、ステップＳ１９３において、欠損データのブロック数が所定の閾値より大きいとされた場合、処理はステップＳ１９６に進む。この場合、取得ファイル判断部１２２は、ファイルサーバ１２から欠損していないファイル全体を取得するように判断し、そのようにHTTPクライアント１２１を制御する。つまり、ステップＳ１９６において、HTTPクライアント１２１は、その制御に従って、ファイルサーバ１２（source file server）からファイル全体を取得する。ステップＳ１９６の処理が終了すると、ファイル取得処理が終了する。
【０１１３】
このようなファイル取得処理の擬似コードは以下のようになる。ただし、欠損データの割合ｚの閾値を0.3とし、欠損データのブロック数の閾値を４としている。
【０１１４】
If (z<0.3 && y<4) {
Go to Proxy;
} else {
Go to source file server;
}
【０１１５】
以上のようにファイル取得処理を行うことにより、アプリケーションクライアント１０２は、HTTPレスポンスのヘッダに含まれる修復状況に関する情報に基づいて、ファイルの取得や修復を適切に制御することができる。したがって、ファイルの欠損データの修復をより容易に行うことができる。
【０１１６】
＜ファイル取得処理の流れ３＞
HTTPクライアント１２１は、MPEG DASHのSANDメッセージとして供給される修復状況に関する情報を取得するようにしてもよい。また、その場合、取得ファイル判断部１２２は、ファイルの再生までの余裕時間に応じて、待機してからそのファイルを取得させるようにしてもよい。
【０１１７】
MPEG DASHのストリーミングにおいて一連のセグメントファイル（Segment File）を取得しようとするアプリケーションクライアント１０２は、SANDメッセージによって与えられたローカルプロキシ１０１に蓄積されたファイルのステータスに応じて、後続のメディアセグメントの取得先を決定することができる。
【０１１８】
基本的には上述のHTTP headerによって得られた情報の場合と同様な判断となるが、SANDメッセージでは将来リクエストすることになるメディアセグメント（media segment）ファイルについての情報も得られるため、それに応じた判断も可能である。例えば、すぐ次のセグメントに対してパーシャル（partial）またはアンダーリペア（under_repair）ステータスであることが判明した場合、予めファイルサーバ１２にセグメントを取得しに行くが、しばらく先のセグメントの場合、アンダーリペア（under_repair）ステータスであっても修復が必要なデータ量がある一定以下であるときは、実際にそのセグメントを取得するまでの間に修復が完了することを期待して別途ファイルサーバ１２からの取得を試みない、などの判断が可能である。
【０１１９】
この場合のファイル取得処理の流れの例を、図１７のフローチャートを参照して説明する。ファイル取得処理が開始されると、アプリケーションクライアント１０２のHTTPクライアント１２１は、ステップＳ２１１において、HTTP HEAD request若しくはHTTP GET request、またはその両方により、SANDヘッダを取得し、そのSANDヘッダに記述されているURLに対してHTTP GET requestを行うことによりSANDメッセージ（SAND message）を取得する。ステップＳ２１２において、取得ファイル判断部１２２は、HTTPクライアント１２１により取得されたSANDメッセージから、後続のセグメントのステータスを把握する。
【０１２０】
ステップＳ２１３において、取得ファイル判断部１２２は、未処理のセグメントの中から処理対象を選択する。ステップＳ２１４において、取得ファイル判断部１２２は、処理対象セグメントのファイルがパーシャルファイルであるか否かを判定する。パーシャルファイルであると判定された場合、処理は、ステップＳ２１５に進む。
【０１２１】
ステップＳ２１５において、取得ファイル判断部１２２は、処理対象のセグメントのファイルの欠損データの割合ｚが所定の閾値以下であるか否かを判定する。欠損データの割合ｚが所定の閾値以下であると判定された場合、処理はステップＳ２１６に進む。ステップＳ２１６において、取得ファイル判断部１２２は、処理対象のセグメントのファイルの再生までの余裕時間が所定の閾値以上であるか否かを判定する。余裕時間が所定の閾値以上であると判定された場合、処理はステップＳ２１７に進む。
【０１２２】
この場合、取得ファイル判断部１２２は、実際にそのセグメントを取得するまでの間に修復が完了することを期待してファイルサーバ１２からの取得を試みずに待機させる。そして、再生タイミングに応じたタイミングでそのファイルをローカルプロキシ１０１から取得させるように判断し、そのようにHTTPクライアント１２１を制御する。つまり、ステップＳ２１７において、HTTPクライアント１２１は、その制御に従って、所定の時間待機後、ローカルプロキシ１０１から、パーシャルファイルを取得する。
【０１２３】
ステップＳ２１８において、HTTPクライアント１２１は、取得したパーシャルファイルの欠損データに対応するデータを、ファイルサーバ１２に要求し、取得する。修復処理部１２３は、そのデータを、そのデータに対応する欠損データと置き換えることにより、パーシャルファイルの修復を行う。ステップＳ２１８の処理が終了すると、処理はステップＳ２２２に進む。
【０１２４】
また、ステップＳ２１４において、処理対象セグメントのファイルがパーシャルファイルでないと判定された場合、処理はステップＳ２１９に進む。また、ステップＳ２１６において、再生までの余裕時間が閾値より短いと判定された場合、処理はステップＳ２１９に進む。
【０１２５】
この場合、取得ファイル判断部１２２は、処理対象セグメントのファイルをローカルプロキシ１０１から取得させるように判断し、そのようにHTTPクライアント１２１を制御する。
【０１２６】
つまり、ステップＳ２１９において、HTTPクライアント１２１は、その制御に従って、ローカルプロキシ１０１からファイルを取得する。そして、その取得したファイルがパーシャルファイルである場合、ステップＳ２２０において、HTTPクライアント１２１は、そのパーシャルファイルの欠損データに対応するデータを、ファイルサーバ１２に要求し、取得する。修復処理部１２３は、そのデータを、そのデータに対応する欠損データと置き換えることにより、パーシャルファイルの修復を行う。ステップＳ２２０の処理が終了すると、処理はステップＳ２２２に進む。なお、ローカルプロキシ１０１から取得したファイルがパーシャルファイルで無い場合は、ステップＳ２２０の処理が省略される。
【０１２７】
また、ステップＳ２１５において、欠損データの割合ｚが所定の閾値より大きいと判定された場合、処理はステップＳ２２１に進む。
【０１２８】
この場合、取得ファイル判断部１２２は、処理対象セグメントのファイル全体をファイルサーバ１２から取得するように判断し、そのようにHTTPクライアント１２１を制御する。つまり、ステップＳ２２１において、HTTPクライアント１２１は、その制御に従って、ファイルサーバ１２（source file server）からファイル全体を取得する。ステップＳ２２１の処理が終了すると、処理はステップＳ２２２に進む。
【０１２９】
ステップＳ２２２において、HTTPクライアント１２１は、全てのセグメントを処理したか否かを判定する。未処理のセグメントが存在すると判定された場合、処理はステップＳ２１３に戻り、それ以降の処理が繰り返される。すなわち、各セグメントに対して、ステップＳ２１３乃至ステップＳ２２２の各処理が実行される。そして、ステップＳ２２２において、処理対象とすることができる全てのセグメントを処理したと判定された場合、ファイル取得処理が終了する。
【０１３０】
以上のようにファイル取得処理を行うことにより、アプリケーションクライアント１０２は、MPEG DASHのSANDメッセージを用いて提供される、ファイルの修復状況に関する情報を取得することができる。これにより、後続のセグメントや他のリプレゼンテーションのセグメント等についての修復状況に関する情報も容易に取得することができるようになる。したがって、アプリケーションクライアント１０２は、より早期に修復状況に関する情報に基づいてファイルの取得や修復を制御することができるようになるので、ファイルの取得や修復をより適切に制御することができるようになる。したがって、ファイルの欠損データの修復をより容易に行うことができる。
【０１３１】
なお、上述したように、既存のSANDメッセージを用いてファイルの修復状況に関する情報を伝送するようにしてもよいし、SANDメッセージを拡張して修復状況に関する情報を表すための新たなメッセージを定義し、その新たなメッセージを用いてファイルの修復状況に関する情報を伝送するようにしてもよい。既存のSANDメッセージを用いる場合は、アプリケーションクライアント１０２が、既存のSANDメッセージを理解することができる機能を有していればよく、SANDメッセージを拡張する場合は、アプリケーションクライアント１０２が、その拡張メッセージも理解することができる機能を有していればよい。
【０１３２】
＜２．その他＞
＜応用例＞
以上においては、受信装置１００内のローカルプロキシ１０１とアプリケーションクライアント１０２との間の通信として説明したが、本技術は、これに限らず、例えば装置間の通信にも適用することができる。つまり、ローカルプロキシ１０１とアプリケーションクライアント１０２が、互いに異なる任意の装置に構成されるようにしてもよい。
【０１３３】
例えば、LAN（Local Area Network）において、ローカルプロキシ１０１が、ローカルサーバ、ルータ、ハブ、放送波受信機、中継装置、アクセスポイント等に構成されるようにし、アプリケーションクライアント１０２がユーザにより操作される端末装置に構成されるようにしてもよい。また、LANに限らず、例えば、ローカルプロキシ１０１が、インターネット上のCDN（Contents Delivery Network）エッジサーバ等に構成されるようにし、アプリケーションクライアント１０２が、ローカルサーバ、ルータ、ハブ、放送波受信機、中継装置、アクセスポイント、端末装置等に構成されるようにしてもよい。以上のような装置間の通信に本技術を適用する場合であっても、第１の実施の形態において説明した場合と同様の作用効果を得ることができる。
【０１３４】
なお、ローカルプロキシ１０１とアプリケーションクライアント１０２の数はそれぞれ任意であり、１対１でなくてもよい。例えば、複数のアプリケーションクライアント１０２が単数のローカルプロキシ１０１にアクセスするようにしてもよい。逆に、単数のアプリケーションクライアント１０２が複数のローカルプロキシ１０１にアクセスするようにしてもよい。つまり、任意の数のアプリケーションクライアント１０２が任意の数のローカルプロキシ１０１にアクセスすることができるようにしてもよい。
【０１３５】
また、伝送するファイルに格納されるデータは任意である。例えば、画像データであってもよいし、音声データであってもよいし、例えばテキストデータ等、画像や音声以外のデータであってもよい。また、例えば画像データと音声データとそれらのメタデータ等のように、複数種類のデータが１つのファイルに格納されるようにしてももちろんよい。また、データのフォーマットも任意である。
【０１３６】
また、アプリケーションクライアント１０２は、修復したファイルを再生せずに、他の装置や他の処理部に供給したり、記憶部に記憶させたりするようにしてもよい。例えば、第１の実施の形態においては、ローカルプロキシ１０１やアプリケーションクライアント１０２が受信装置１００に形成されるように説明したが、ローカルプロキシ１０１やアプリケーションクライアント１０２が、例えば、CDNエッジサーバやローカルサーバ等の任意のサーバに形成されるようにしてもよいし、ルータ、ハブ、中継装置、アクセスポイント等の任意の通信装置に形成されるようにしてもよい。
【０１３７】
＜本技術の適用分野＞
本技術を適用したシステム、装置、処理部等は、例えば、交通、医療、防犯、農業、畜産業、鉱業、美容、工場、家電、気象、自然監視等、任意の分野に利用することができる。
【０１３８】
例えば、本技術は、鑑賞の用に供される画像を伝送するシステムやデバイスにも適用することができる。また、例えば、本技術は、交通の用に供されるシステムやデバイスにも適用することができる。さらに、例えば、本技術は、セキュリティの用に供されるシステムやデバイスにも適用することができる。また、例えば、本技術は、スポーツの用に供されるシステムやデバイスにも適用することができる。さらに、例えば、本技術は、農業の用に供されるシステムやデバイスにも適用することができる。また、例えば、本技術は、畜産業の用に供されるシステムやデバイスにも適用することができる。さらに、本技術は、例えば火山、森林、海洋等の自然の状態を監視するシステムやデバイスにも適用することができる。また、本技術は、例えば天気、気温、湿度、風速、日照時間等を観測する気象観測システムや気象観測装置に適用することができる。さらに、本技術は、例えば鳥類、魚類、ハ虫類、両生類、哺乳類、昆虫、植物等の野生生物の生態を観測するシステムやデバイス等にも適用することができる。
【０１３９】
＜コンピュータ＞
上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここでコンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータ等が含まれる。
【０１４０】
図１８は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
【０１４１】
図１８に示されるコンピュータ８００において、CPU（Central Processing Unit）８０１、ROM（Read Only Memory）８０２、RAM（Random Access Memory）８０３は、バス８０４を介して相互に接続されている。
【０１４２】
バス８０４にはまた、入出力インタフェース８１０も接続されている。入出力インタフェース８１０には、入力部８１１、出力部８１２、記憶部８１３、通信部８１４、およびドライブ８１５が接続されている。
【０１４３】
入力部８１１は、例えば、キーボード、マウス、マイクロホン、タッチパネル、入力端子などよりなる。出力部８１２は、例えば、ディスプレイ、スピーカ、出力端子などよりなる。記憶部８１３は、例えば、ハードディスク、RAMディスク、不揮発性のメモリなどよりなる。通信部８１４は、例えば、ネットワークインタフェースよりなる。ドライブ８１５は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブルメディア８２１を駆動する。
【０１４４】
以上のように構成されるコンピュータ８００では、CPU８０１が、例えば、記憶部８１３に記憶されているプログラムを、入出力インタフェース８１０およびバス８０４を介して、RAM８０３にロードして実行することにより、上述した一連の処理が行われる。RAM８０３にはまた、CPU８０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０１４５】
コンピュータ８００が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア８２１に記録して適用することができる。その場合、プログラムは、リムーバブルメディア８２１をドライブ８１５に装着することにより、入出力インタフェース８１０を介して、記憶部８１３にインストールすることができる。また、このプログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することもできる。その場合、プログラムは、通信部８１４で受信し、記憶部８１３にインストールすることができる。その他、このプログラムは、ROM８０２や記憶部８１３等に、あらかじめインストールしておくこともできる。
【０１４６】
＜その他＞
本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０１４７】
例えば、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、全ての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
【０１４８】
また、例えば、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
【０１４９】
また、例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
【０１５０】
また、例えば、上述したプログラムは、任意の装置において実行することができる。その場合、その装置が、必要な機能（機能ブロック等）を有し、必要な情報を得ることができるようにすればよい。
【０１５１】
また、例えば、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。換言するに、１つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を１つのステップとしてまとめて実行することもできる。
【０１５２】
なお、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が上述した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
【０１５３】
また、上述した各ステップの処理は、上述した各装置、または、上述した各装置以外の任意の装置において、実行することができる。その場合、その処理を実行する装置が、上述した、その処理を実行するのに必要な機能（機能ブロック等）を有するようにすればよい。また、処理に必要な情報を、適宜、その装置に伝送するようにすればよい。
【０１５４】
なお、本明細書において複数説明した本技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、上述した任意の本技術の一部または全部を、上述していない他の技術と併用して実施することもできる。
【０１５５】
なお、本技術は以下のような構成も取ることができる。
（１）  データが不完全なファイルに関する要求に対する応答として、前記ファイルの修復状況に関する情報を要求元に提供する応答処理部
を備える情報処理装置。
（２）  前記修復状況に関する情報は、
前記ファイルの修復処理のステータスと、
前記ファイルの修復されていない欠損データのブロック数を示す情報と
を含む
（１）に記載の情報処理装置。
（３）  前記ステータスは、
修復が開始されたか否かを示す情報と、
修復が完了したか否かを示す情報と、
修復が失敗したか否かを示す情報と
を含む
（２）に記載の情報処理装置。
（４）  前記修復状況に関する情報は、前記ファイルの修復されていない欠損データのバイト数を示す情報をさらに含む
（２）または（３）に記載の情報処理装置。
（５）  前記応答処理部は、前記ファイルの修復状況に関する情報を、HTTP（HyperText Transfer Protocol）ヘッダとして前記応答のヘッダに付加して前記要求元に提供する
（１）乃至（４）のいずれかに記載の情報処理装置。
（６）  前記応答処理部は、前記ファイルの修復状況に関する情報をMPEG DASH（Moving Picture Experts Group Dynamic Adaptive Streaming over HyperText Transfer Protocol）のSAND（Server and network assisted DASH）メッセージとして前記要求元に提供する
（１）乃至（５）のいずれかに記載の情報処理装置。
（７）  前記応答処理部は、前記SANDメッセージにより、要求されたセグメントのファイルの修復状況に関する情報に加えて、他のセグメントのファイルの修復状況に関する情報をさらに提供する
（６）に記載の情報処理装置。
（８）  前記応答処理部は、前記SANDメッセージのResourceStatusメッセージを用いて前記ファイルの修復状況に関する情報を提供する
（６）または（７）に記載の情報処理装置。
（９）  前記応答処理部は、前記SANDメッセージの拡張メッセージを用いて前記ファイルの修復状況に関する情報を提供する
（６）または（７）に記載の情報処理装置。
（１０）  データが不完全なファイルに関する要求に対する応答として、前記ファイルの修復状況に関する情報を要求元に提供する
情報処理方法。
（１１）  要求に対する応答として供給される、データが不完全なファイルの修復状況に関する情報を取得する取得部と、
前記取得部により取得された前記修復状況に関する情報に基づいて、前記ファイルの取得に関する制御を行う制御部と
を備える情報処理装置。
（１２）  前記制御部は、前記修復状況に関する情報に基づいて、前記ファイルの取得先を、前記ファイルの供給元にするか、前記ファイルの供給元から前記ファイルを供給された前記応答の供給元にするかを選択し、
前記取得部は、さらに、前記制御部により選択された取得先から前記ファイルを取得する
（１１）に記載の情報処理装置。
（１３）  前記制御部は、前記ファイルの修復されていない欠損データの割合に基づいて、前記ファイルの取得先を選択する
（１２）に記載の情報処理装置。
（１４）  前記制御部は、さらに、前記ファイルの修復されていない欠損データのブロック数に基づいて、前記ファイルの取得先を選択する
（１３）に記載の情報処理装置。
（１５）  前記ファイルの修復されていない欠損データを修復する修復部をさらに備え、
前記制御部により、前記ファイルの取得先として前記応答の供給元が選択された場合、
前記取得部が、前記応答の供給元から前記ファイルを取得し、さらに、前記ファイルの供給元から前記欠損データに対応するデータを取得し、
前記修復部が、前記取得部により取得された前記ファイルの欠損データを、前記取得部により取得された前記データを用いて修復するように構成される
（１２）乃至（１４）のいずれかに記載の情報処理装置。
（１６）  前記取得部は、HTTP（HyperText Transfer Protocol）ヘッダとして供給される前記修復状況に関する情報を取得する
（１１）乃至（１５）のいずれかに記載の情報処理装置。
（１７）  前記取得部は、MPEG DASH（Moving Picture Experts Group Dynamic Adaptive Streaming over HyperText Transfer Protocol）のSAND（Server and network assisted DASH）メッセージとして供給される前記修復状況に関する情報を取得する
（１１）乃至（１６）のいずれかに記載の情報処理装置。
（１８）  前記制御部は、前記ファイルの再生までの余裕時間に応じて待機してから前記ファイルを取得させる
（１７）に記載の情報処理装置。
（１９）  前記取得部は、HTTP（HyperText Transfer Protocol） HEAD Request、または、HTTP GET Requestに対する応答として供給される前記修復状況に関する情報を取得する
（１１）乃至（１８）のいずれかに記載の情報処理装置。
（２０）  要求に対する応答として供給される、データが不完全なファイルの修復状況に関する情報を取得し、
取得された前記修復状況に関する情報に基づいて、前記ファイルの取得に関する制御を行う
情報処理方法。
【符号の説明】
【０１５６】
１００  受信装置，  １０１  ローカルプロキシ，  １０２  アプリケーションクライアント，  １１１  データ受信部，  １１２  蓄積部，  １１３  修復処理部，  １１４  ファイル情報生成部，  １１５  HTTPサーバ，  １２１  HTTPクライアント，  １２２  取得ファイル判断部，  １２３  修復処理部，  １２４  再生部
【図１】
2018070268.tif 000003
【図２】
2018070268.tif 000004
【図３】
2018070268.tif 000005
【図４】
2018070268.tif 000006
【図５】
2018070268.tif 000007
【図６】
2018070268.tif 000008
【図７】
2018070268.tif 000009
【図８】
2018070268.tif 000010
【図９】
2018070268.tif 000011
【図１０】
2018070268.tif 000012
【図１１】
2018070268.tif 000013
【図１２】
2018070268.tif 000014
【図１３】
2018070268.tif 000015
【図１４】
2018070268.tif 000016
【図１５】
2018070268.tif 000017
【図１６】
2018070268.tif 000018
【図１７】
2018070268.tif 000019
【図１８】
2018070268.tif 000020
【手続補正書】
【提出日】平成30年2月21日(2018.2.21)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ファイルに関する要求に対する応答として、前記ファイルの、修復処理のステータスと修復されていない欠損データのブロック数を示す情報とを含む修復状況に関する情報を、前記要求の要求元に提供する応答処理部
を備える情報処理装置。
【請求項２】
前記ステータスは、
修復が開始されたか否かを示す情報と、
修復が完了したか否かを示す情報と、
修復が失敗したか否かを示す情報と
を含む
請求項１に記載の情報処理装置。
【請求項３】
前記応答処理部は、ＭＰＥＧ  ＤＡＳＨ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ  Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）のＳＡＮＤ（Ｓｅｒｖｅｒ  ａｎｄ  ｎｅｔｗｏｒｋ  ａｓｓｉｓｔｅｄ  ＤＡＳＨ）メッセージのＲｅｓｏｕｒｃｅＳｔａｔｕｓメッセージを用いて、要求されたセグメントおよび他のセグメントのファイルの前記修復状況に関する情報を前記要求元に提供する
請求項２に記載の情報処理装置。
【請求項４】
前記応答処理部は、ＭＰＥＧ  ＤＡＳＨ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ  Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）のＳＡＮＤ（Ｓｅｒｖｅｒ  ａｎｄ  ｎｅｔｗｏｒｋ  ａｓｓｉｓｔｅｄ  ＤＡＳＨ）メッセージの拡張メッセージを用いて、要求されたセグメントおよび他のセグメントのファイルの前記修復状況に関する情報を前記要求元に提供する
請求項２に記載の情報処理装置。
【請求項５】
前記拡張メッセージは、ｂａｓｅ  ＵＲＬをリプレゼンテーションのｂａｓｅ  ＵＲＬとすることにより、前記リプレゼンテーションに属する各メディアセグメントに関するｓｔａｔｕｓを表現する
請求項４に記載の情報処理装置。
【請求項６】
前記拡張メッセージを複数併記することにより、要求されたリプレゼンテーションと同一のアダプテーションセット内の他のリプレゼンテーションの後続セグメントに相当するファイルに関するｓｔａｔｕｓも伝達する
請求項４に記載の情報処理装置。
【請求項７】
前記修復状況に関する情報は、前記ファイルの修復されていない欠損データのバイト数を示す情報をさらに含む
請求項１に記載の情報処理装置。
【請求項８】
前記応答処理部は、前記修復状況に関する情報を、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）ヘッダとして前記応答のヘッダに付加して前記要求元に提供する
請求項１に記載の情報処理装置。
【請求項９】
ファイルに関する要求に対する応答として、前記ファイルの、修復処理のステータスと修復されていない欠損データのブロック数を示す情報とを含む修復状況に関する情報を、前記要求の要求元に提供する
情報処理方法。
【請求項１０】
ファイルに関する要求に対する応答として供給される、前記ファイルの、修復処理のステータスと修復されていない欠損データのブロック数を
示す情報とを含む修復状況に関する情報を取得する取得部と、
前記取得部により取得された前記修復状況に関する情報に基づいて、前記ファイルの取得に関する制御を行う制御部と
を備える情報処理装置。
【請求項１１】
前記制御部は、前記修復状況に関する情報に基づいて、前記ファイルの取得先を、前記ファイルの供給元にするか、前記ファイルの供給元から前記ファイルを供給された前記応答の供給元にするかを選択し、
前記取得部は、さらに、前記制御部により選択された取得先から前記ファイルを取得する
請求項１０に記載の情報処理装置。
【請求項１２】
前記制御部は、前記ファイルの修復されていない欠損データの割合に基づいて、前記ファイルの取得先を選択する
請求項１１に記載の情報処理装置。
【請求項１３】
前記制御部は、さらに、前記ファイルの修復されていない欠損データのブロック数に基づいて、前記ファイルの取得先を選択する
請求項１２に記載の情報処理装置。
【請求項１４】
前記ファイルの修復されていない欠損データを修復する修復部をさらに備え、
前記制御部により、前記ファイルの取得先として前記応答の供給元が選択された場合、
前記取得部が、前記応答の供給元から前記ファイルを取得し、さらに、前記ファイルの供給元から前記欠損データに対応するデータを取得し、
前記修復部が、前記取得部により取得された前記ファイルの欠損データを、前記取得部により取得された前記データを用いて修復するように構成される
請求項１１に記載の情報処理装置。
【請求項１５】
前記取得部は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）ヘッダとして供給される前記修復状況に関する情報を取得する
請求項１０に記載の情報処理装置。
【請求項１６】
前記取得部は、ＭＰＥＧ  ＤＡＳＨ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ  Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）のＳＡＮＤ（Ｓｅｒｖｅｒ  ａｎｄ  ｎｅｔｗｏｒｋ  ａｓｓｉｓｔｅｄ  ＤＡＳＨ）メッセージとして供給される前記修復状況に関する情報を取得する
請求項１０に記載の情報処理装置。
【請求項１７】
前記制御部は、前記ファイルの再生までの余裕時間に応じて待機してから前記ファイルを取得させる
請求項１６に記載の情報処理装置。
【請求項１８】
前記取得部は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）ＨＥＡＤ  Ｒｅｑｕｅｓｔ、または、ＨＴＴＰ  ＧＥＴ  Ｒｅｑｕｅｓｔに対する応答として供給される前記修復状況に関する情報を取得する
請求項１０に記載の情報処理装置。
【請求項１９】
ファイルに関する要求に対する応答として供給される、前記ファイルの、修復処理のステータスと修復されていない欠損データのブロック数を示す情報とを含む修復状況に関する情報を取得し、
取得された前記修復状況に関する情報に基づいて、前記ファイルの取得に関する制御を行う
情報処理方法。
【請求項２０】
（削除）
【国際調査報告】
2018070268.tif 000021
2018070268.tif 000022