(57)【特許請求の範囲】
【請求項１】
配信サーバからネットワークを介して、コンテンツをチャンク単位で端末に対して配信するシステムにおいて、該コンテンツの再生・停止時間を推定するコンテンツ再生情報推定装置であって、
前記配信サーバと前記端末間に設けられ、
前記配信サーバと前記端末間で交換されるパケットデータ及びコンテンツリストを取得して、記憶手段に格納するパケットデータ取得手段と、
前記記憶手段から取得した前記パケットデータ、または、コンテンツリストのコンテンツの識別子、チャンクのデータから、前記端末の再生アプリケーションに渡される各チャンクの再生時間長を求めるチャンク時間長推定手段と、
前記記憶手段から前記パケットデータを取得して、前記端末の前記再生アプリケーションにチャンクが渡されるチャンク取得時刻を求めるチャンク取得時刻推定手段と、
予め、コンテンツの再生を開始する際の前記端末のバッファ中のチャンク数の閾値th_p、再生を停止するチャンク数の閾値th_s、再生を再開する際のチャンク数の閾値th_rを設定し、前記記憶手段の前記パケットデータと前記コンテンツリストを参照し、前記チャンク時間長推定手段で得られた前記チャンクの再生時間長と、前記チャンク取得時刻推定手段で得られた前記チャンク取得時刻から、現在前記端末のバッファに蓄積されているチャンク数を求め、該チャンク数と各閾値を比較して、端末の状態が再生状態、または、停止状態であるかを判定する再生状態推定手段と、
を有することを特徴とするコンテンツ再生情報推定装置。  
【請求項２】
前記再生状態推定手段は、
ｉ番目の受信チャンクのダウンロード終了時刻と、ｉ＋１番目の受信チャンクのダウンロード開始時刻との間の期間を基に、一時停止の要因に係る閾値との比較を実施する一時停止要因推定手段を含む
請求項１に記載のコンテンツ再生情報推定装置。
【請求項３】
前記再生状態推定手段は、
前記パケットデータ取得手段において、前記ネットワークから前記パケットデータの受信が終了し、前記チャンク取得時刻及び前記チャンクの再生時間長が求められた後に再生状態の推定を実行する
請求項１または２に記載のコンテンツ再生情報推定装置。
【請求項４】
前記チャンク時間長推定手段及び前記チャンク取得時刻推定手段は、
前記パケットデータ取得手段において、パケットデータを取得する度に処理を実行し、
前記再生状態推定手段は、
前記端末において再生状態にあるとき、前記端末のバッファ中のチャンクを消費したとき、または、再生が停止状態であるときに新たにチャンクのデータを取得した時点で再生状態の推定を実行する
請求項１または２に記載のコンテンツ再生情報推定装置。
【請求項５】
前記チャンク時間長推定手段は、
前記パケットデータの受信バイト量及び再生レートから前記チャンクの再生時間長を求める手段を含む
請求項１乃至４のいずれか1項に記載のコンテンツ再生情報推定装置。
【請求項６】
配信サーバからネットワークを介して、コンテンツをチャンク単位で端末に対して配信するシステムにおいて、該コンテンツの再生・停止時間を推定するコンテンツ再生情報推定方法であって、
前記配信サーバと前記端末間に設けられる装置において、パケットデータ取得手段が、前記配信サーバと前記端末間で交換されるパケットデータ及びコンテンツリストを取得して、記憶手段に格納するパケットデータ取得ステップと、
チャンク時間長推定手段が、前記記憶手段から取得した前記パケットデータ、または、コンテンツリストのコンテンツの識別子、チャンクのデータから、前記端末の再生アプリケーションに渡される各チャンクの再生時間長を求めるチャンク時間長推定ステップと、
チャンク取得時刻推定手段が、前記記憶手段から前記パケットデータを取得して、前記端末の前記再生アプリケーションにチャンクが渡されるチャンク取得時刻を求めるチャンク取得時刻推定ステップと、
再生状態推定手段が、予め、コンテンツの再生を開始する際の前記端末のバッファ中のチャンク数の閾値th_p、再生を停止するチャンク数の閾値th_s、再生を再開する際のチャンク数の閾値th_rを設定し、前記記憶手段の前記パケットデータと前記コンテンツリストを参照
し、前記チャンク時間長推定ステップで得られた前記チャンクの再生時間長と、前記チャンク取得時刻推定ステップで得られた前記チャンク取得時刻から、現在前記端末のバッファに蓄積されているチャンク数を求め、
該チャンク数と各閾値を比較して、端末の状態が再生状態、または、停止状態であるかを判定する再生状態推定ステップと、
を行う、ことを特徴とするコンテンツ再生情報推定方法。
【請求項７】
前記再生状態推定ステップにおいて、
ｉ番目の受信チャンクのダウンロード終了時刻と、ｉ＋１番目の受信チャンクのダウンロード開始時刻との間の期間を基に、一時停止の要因に係る閾値との比較を実施する一時停止要因推定ステップを行う
請求項６に記載のコンテンツ再生情報推定方法。
【請求項８】
コンピュータを、
請求項１乃至５のいずれか１項に記載のコンテンツ再生情報推定装置の各手段として機能させるためのコンテンツ再生情報推定プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツ再生情報推定装置及び方法及びプログラムに係り、特に、ネットワークを介してコンテンツデータを配信するシステムにおいて、映像等のプログレッシブダウンロード型のコンテンツの再生品質の推定を行うためのコンテンツ再生情報推定装置及び方法及びプログラムに関する。
【背景技術】
【０００２】
近年通信網の広帯域化が進んでおり、より多くのトラヒックがインターネットを介して流通するようになった。特に大きなファイルサイズを持つコンテンツをダウンロードしながらデータ処理を並行して行う、プログレッシブダウンロード型のコンテンツ配信システムが普及している。このようなコンテンツ配信形態では、ネットワークを介することによる遅延変動やパケットロス、再送等によりデータが一定速度で端末に到着せず、データの到着には送信タイミングに対して揺らぎが発生する。そのため、端末側でそのゆらぎを吸収するために、再生バッファを用意し、ネットワークの影響を上位アプリケーションに対して隠ぺいする仕組みが用いられることが多い。
【０００３】
このようなコンテンツ配信形態では、処理の開始までに一定量のバッファリング（初期バッファ量）を要することが特徴であるが、そのバッファ量を大きくすることでネットワークによる影響を軽減することができる一方、データ処理開始までの時間が長くなり、レスポンスが悪くなる。そのため、様々な状況を鑑みて適切な大きさの初期バッファ量を設定する必要がある。例えば、パケットの転送遅延時間をもとに初期バッファ量を動的に変更させる手法がある（例えば、非特許文献１参照）。
【０００４】
一方、一時的にネットワークのスループットがコンテンツデータの処理速度よりも低くなる場合には、再生バッファが一定量（再生停止閾値）を下回り、再生が停止されることがある。この再生停止は、当該コンテンツのユーザ体感品質に大きな影響を与えるが、従来技術では対応できないため、コンテンツの再生停止状態を推定し、把握する技術が必要とされる。
【０００５】
また、コンテンツの配信方法として、単一のコンテンツであっても、複数の単位に分割して配信を行う形態も多い。これらの配信方式では、分割された各単位をチャンクと呼び、チャンク単位で再生バッファに格納される。すなわち、当該再生バッファに対して、チャンクの個数または蓄積されたチャンクの再生時間長等でバッファの管理が行われる。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】Kouhei Fujimoto, Shingo Ata, Masayuki Murata, "Statistical Analysis of Packet delays in the Internet and Its Application to Playout Control for Streaming Applications," IEICE TRANSE. ON COMMUNICATION, VOL. E00-B, NO. 6 JUNE 2001
【発明の概要】
【発明が解決しようとする課題】
【０００７】
再生停止状態の推定を行う場合、端末の内部で行う場合と、外部で行う場合の２つのパターンが考えられる。
【０００８】
端末の中で行う場合には、実際に端末の内部でプログラムを動作させ、直接的なデータを取得し用いるため、精度を高くすることができるが、アプリケーションに合わせた作り込みや、クライアントプログラムの改変等が必要になることが想定される。この方法では対応アプリケーションを増やすことは難しく汎用性に欠ける。
【０００９】
一方、端末の外部から推定を行う場合、端末へ転送されるパケットデータから推定を行うため、任意のアプリケーションに適用することができるため、汎用性は高い。その一方で、クライアントプログラム内での処理を模擬した上で再生停止状態の推定を行う必要がある。特定のアプリケーションに合わせて推定精度を高める方法は考えられるが、外部からの推定を行う利点である汎用性が失われるという欠点がある。そのため，汎用性を保ったまま再生状態の精度を高くすることが課題となる。
【００１０】
また、キャプチャデータを基に再生停止と推定された場合において、再生停止の発生要因がネットワーク起因か、利用者の行動起因かを区別することができず、品質劣化要因の見極めが難しいという問題があり、例えば、ネットワークに問題がないにも関わらずネットワーク起因の品質劣化であると誤判定を行う可能性があった。このため、再生停止の推定にあたり、利用者が能動的に再生の一時停止を操作した状態か、ネットワークやサーバ等の機能低下等による自然な停止か否かの再生停止要因の識別を可能とすることが課題となる。
【００１１】
本発明は、上記の点に鑑みなされたもので、ネットワークを介して配信されたコンテンツデータを受信、再生するサービスを提供するシステムにおいて、コンテンツ配信システムの配信側（配信サーバ）、受信側（再生端末）に改変を加えることなく、配信経路上においてパケットキャプチャと分析を行うことで、当該システムにおいてコンテンツデータを受信、再生する端末における再生停止状態の推定を行うコンテンツ再生情報推定装置及び方法及びプログラムを提供することを目的とする。
【００１２】
また、本発明は、ネットワークを介して端末が受信するチャンク単位のコンテンツデータの再生停止状態の推定にあたり、再生停止要因を識別し、再生停止状態の推定に反映することが可能なコンテンツの再生情報推定装置及び方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１３】
【００１４】
【００１５】
また、本発明の一実施形態によれば、配信サーバからネットワークを介して、コンテンツをチャンク単位で端末に対して配信するシステムにおいて、該コンテンツの再生・停止時間を推定するコンテンツ再生情報推定装置であって、
前記配信サーバと前記端末間に設けられ、
前記配信サーバと前記端末間で交換されるパケットデータ及びコンテンツリストを取得して、記憶手段に格納するパケットデータ取得手段と、
前記記憶手段から取得した前記パケットデータ、または、コンテンツリストのコンテンツの識別子、チャンクのデータから、前記端末の再生アプリケーションに渡される各チャンクの再生時間長を求めるチャンク時間長推定手段と、
前記記憶手段から前記パケットデータを取得して、前記端末の前記再生アプリケーションにチャンクが渡されるチャンク取得時刻を求めるチャンク取得時刻推定手段と、
予め、コンテンツの再生を開始する際の前記端末のバッファ中のチャンク数の閾値th_p、再生を停止するチャンク数の閾値th_s、再生を再開する際のチャンク数の閾値th_rを設定し、
前記記憶手段の前記パケットデータと前記コンテンツリストを参照し、前記チャンク時間長推定手段で得られた前記チャンクの再生時間長と、前記チャンク取得時刻推定手段で得られた前記チャンク取得時刻から、現在前記端末のバッファに蓄積されているチャンク数を求め、該チャンク数と各閾値を比較して、端末の状態が再生状態、または、停止状態であるかを判定する再生状態推定手段と、を有することを特徴とするコンテンツ再生情報推定装置が提供される。
【発明の効果】
【００１６】
本発明の一実施形態によれば、コンテンツ配信システムの配信サーバと再生端末間の経路上においてパケットデータを取得し、その情報をもとに再生状態の推定を行うことで、配信システムへの改変を伴わずに、再生情報の取得を行うことができる。
【００１７】
これにより、コンテンツ配信システムの外部から取得することの困難であった再生情報の推定を行うことが可能となる。また、配信サーバや端末への改変を行わないため、配信経路上の任意地点に本システムを設置することで、様々なコンテンツ配信システムに対する再生情報の推定を行うことが可能となる。特に、ストリーミングデータの配信においては、再生停止時間の大小よりも、そもそも再生停止が発生しているかどうかが再生品質に与える影響が大きいため、本発明に係る技術による再生情報の推定により、再生品質の推定に資する情報を得ることが可能になる。また、再生停止状態の推定において、停止状態と判定された場合に、その状態がユーザ操作によるものか否かを切り分けることが可能となる。
【図面の簡単な説明】
【００１８】
【図１】実施の形態１のシステム構成図である。
【図２】実施の形態１−１における処理のフローチャートである。
【図３】実施の形態１−１におけるコンテンツ受信量推定部の演算結果例である。
【図４】実施の形態１−１における再生アプリケーションが再生開始後の各時間に消費するデータ量である。
【図５】実施の形態１−１における再生状態に関する情報の推定結果例である。
【図６】実施の形態１−２におけるシステム構成図である。
【図７】実施の形態１−２における処理のフローチャートである。
【図８】実施の形態１−３におけるシステム構成図である。
【図９】実施の形態１−３における処理のフローチャートである。
【図１０】実施の形態１−４におけるシステム構成図である。
【図１１】実施の形態１−４における処理のフローチャートである。
【図１２】実施の形態２におけるコンテンツ再生情報推定装置の構成図である。
【図１３】実施の形態２−１における動作の概要を示すフローチャートである。
【図１４】実施の形態２−１における停止推定手順のフローチャートである。
【図１５Ａ】実施の形態２における再生状態推定部の具体的な動作を説明するための図である。
【図１５Ｂ】実施の形態２における再生状態推定部の具体的な動作を説明するための図である。
【図１６】実施の形態２−２における停止推定手順のフローチャートである。
【図１７】実施の形態２−３における動作の概要を示す図である。
【発明を実施するための形態】
【００１９】
以下図面と共に、本発明の実施の形態を説明する。本実施の形態は、プログレッシブダウンロード型の映像配信サービスを対象としている。プログレッシブダウンロード型の映像配信サービスには、逐次型とチャンク型があり、以下、逐次型における実施の形態を実施の形態１とし、チャンク型における実施の形態を実施の形態２として説明する。また、実施の形態１は実施の形態１−１〜実施の形態１−５を含み、実施の形態２は、実施の形態２−１〜実施の形態２−４を含む。
【００２０】
なお、本実施の形態では、プログレッシブダウンロード型の映像配信サービスを対象としているが、本発明は、プログレッシブダウンロード型の映像配信サービスに限定されるわけではなく、様々なコンテンツ配信サービスに適用できる。
【００２１】
＜実施の形態１＞
以下図面と共に、本発明の実施の形態１を説明する。
【００２２】
本実施の形態１は、ネットワークを介して配信されたコンテンツデータを受信、再生するサービスを提供するコンテンツ配信システムにおいて、配信側、受信側のいずれのプログラムにも改変を加えることなく、配信経路上においてパケットキャプチャと分析を行うものである。
【００２３】
図１は、実施の形態１におけるシステム構成を示す。
【００２４】
同図に示すシステムにおいてコンテンツデータを受信、再生する端末における再生停止状態の推定を行うコンテンツ再生情報推定装置１００、再生端末２００、コンテンツ格納装置３００と、を有する。
【００２５】
コンテンツ再生情報推定装置１００は、パケット情報取得部１１０、コンテンツ受信量推定部１２０、再生開始時間推定部１３０、再生状態推定部１４０、再生停止時間推定部１５０を有する。
【００２６】
再生端末２００は、受信したコンテンツをバッファリングするための再生バッファ２１０を有する。
【００２７】
コンテンツ格納装置３００は、コンテンツをネットワークに送出するコンテンツ送出部３１０、送出するコンテンツを格納するコンテンツ格納部３２０を有する。
【００２８】
パケット情報取得部１１０は、ネットワークを介して送受信されるパケットのキャプチャ情報（パケット情報）を取得する。
【００２９】
コンテンツ受信量推定部１２０は、取得したキャプチャ情報から端末上の再生アプリケーションに渡されるデータ量の時系列情報の推定を行う。当該コンテンツ受信量推定部１２０は、再生端末２００上の論理的に区切られた個所に実装することも可能である。また、事業者ネットワーク等の通信経路上の任意の位置に実装することも可能である。
【００３０】
再生開始時間推定部１３０は、コンテンツ受信量推定部１２０で推定されたデータ量の時系列情報から再生開始時間を推定する。
【００３１】
再生状態推定部１４０は、再生開始時間推定部１３０によって推定された再生端末２００上の再生アプリケーションが再生開始後の各時間に消費するデータ量と、コンテンツ受信量推定部１２０によって推定された再生アプリケーションに渡されるデータ量の時系列情報とから、再生開始に要する時間や各時間における再生・停止状態の推定を行い、再生状態の推定を行う。
【００３２】
再生提示時間推定部１５０は、再生状態推定部１４０において、再生が停止された状態であると判定された場合に、再生が停止された時刻及び停止された時間を推定する。
【００３３】
以下、上記の構成における具体的な処理を説明する。
【００３４】
［実施の形態１−１］
以下、図１に示すシステムにおける再生停止時間推定処理について説明する。
【００３５】
本実施の形態では、コンテンツ格納装置３００を、複数のコンテンツデータを格納し、ネットワークを介してプログレッシブダウンロード型コンテンツデータを配信する手段を有するコンテンツデータ配信サーバ(以下、配信サーバと記す)として説明する。
【００３６】
再生端末２００は、配信サーバ３００から受信したコンテンツを再生バッファ２１０に蓄積しながら再生する手段を有する。
【００３７】
これらのコンテンツ再生情報推定装置１００、配信サーバ３００、再生端末２００からなるシステムにおいて、配信経路上でキャプチャしたパケットの分析を行い、再生端末２００の再生停止状態の推定を行うコンテンツ再生情報推定技術を以下に示す。
【００３８】
図２は、実施の形態１−１における処理のフローチャートである。
【００３９】
ステップ１０１） コンテンツデータの配信サーバ３００と再生端末２００の間に設置されたコンテンツ再生情報推定装置１００において、パケット情報取得部１１０は、配信サーバ３００と再生端末２００間で交換されるパケット情報（パケットデータ）の一部またはすべての情報を取得する。このパケット情報取得部１１０は、一般的なsniffer装置、プログラム等を用いることが可能である。また、パケット情報取得部１００を本発明に係るコンテンツ再生情報推定装置の外部に設置して、キャプチャされたパケット情報をコンテンツ受信量推定部１２０への入力としてもよい。
【００４０】
ステップ１０２） コンテンツ受信量推定部１２０は、パケット情報取得部１１０で取得したパケット情報の一部または全てから、再生端末２００上の再生アプリケーションに渡されるデータ量の時系列情報の推定を行い、再生開始時間推定部１３０に出力する。ここで、データ量の時系列情報は、例えば、RTPを用いた配信を行っている場合には、RTP(Real-time Transport Protocol)のシーケンス番号やタイムスタンプ情報を用いて受信バイト量の推定を行うことで取得できる。また、TCP(Transmission Control Protocol)を用いた場合でも、再生端末２００におけるTCPプロトコルの挙動を模擬し受信バイト量の推定を行うことができる。
【００４１】
パケット情報取得部１１０で受信したパケット情報を用いてコンテンツ受信量推定部１２０により推定されたデータ量と、所定の再生開始閾値との比較により再生が開始されたかどうかを判定し、開始される前である場合にはステップ１０３の処理に移行する。
【００４２】
コンテンツ受信量推定部１２０における受信量の推定結果の一例を図３に示す。
【００４３】
ステップ１０３） 再生開始時間推定部１３０では、コンテンツ受信量推定部１２０で推定されたデータ量の時系列情報から、再生開始に要する時間を推定する。例えば、再生開始に要する時間は、コンテンツが初めて再生を開始するバッファ量の閾値までデータを受信するのに要した時間とする。当該処理後、ステップ１０１の処理に戻る。
【００４４】
ステップ１０４） パケット情報取得部１１０で受信したパケット情報を用いてコンテンツ受信量推定部１２０により推定されたデータ量と、所定の再生開始閾値との比較により再生が開始されたかどうかを判定し、再生が開始された後であり、かつ、コンテンツデータのサイズがパケットデータ中に記載されており、再生が終了していないと判断された場合、または、フローが切断されていないと判断された場合には、再生状態推定部１４０は、再生端末２００上の再生アプリケーションが再生開始後の各時間に消費するデータ量から、再生端末２００の通信開始後の任意の時刻において、再生が継続されているかどうかを判定する。例えば、以下の手順で判定を行う。
【００４５】
再生アプリケーションにおけるバッファパラメータとして、コンテンツの再生を開始するバッファ量の閾値をThp，コンテンツの再生を停止するバッファ量の閾値をThsとする。このとき、コンテンツ受信量推定部１２０で得られた受信量の時系列データおよび再生アプリケーションの再生時間後の各時間に消費するデータ量を入力とし、バッファ量の増減を行う。すなわち再生上にある場合、ある時刻において受信量がΔB増えていた場合には、バッファ量をΔB増分し、再生アプリケーションで消費されるデータ量がΔC増えていた場合には、バッファ量をΔC減少させる。これらの演算の結果、バッファ量の残量がThsを下回った場合には「再生状態」から「停止状態」に遷移させる。
【００４６】
ここで、再生状態推定部１４０は、再生アプリケーションが再生開始後の各時間に消費するデータ量として、配信サーバ３００と再生端末２００間で交換されるパケット情報をもとに疑似的にデコードを行い、各再生時刻における必要データ量を求めてもよいし、予め定めた固定のビットレートで再生アプリケーションがデータを消費するとして算出してもよいが、これらに限るものではない。例えば、ビットレートが800kbps固定とした場合には、再生開始1秒後には、累積で100KBのデータ量を消費し、再生開始2秒後には累積で200KBのデータ量を消費すると考えられる。このように、再生端末２００上の再生アプリケーションが再生開始後の各時間に消費するデータ量を時系列で与える。
【００４７】
再生アプリケーションが再生開始後の各時間に消費するデータ量の一例を図４に示す。
【００４８】
ステップ１０５） パケット情報取得部１１０で受信したパケット情報を用いてコンテンツ受信量推定部１２０により推定されたデータ量と、所定の再生開始閾値との比較により再生が開始されたかどうかを判定し、再生が開始された後であり、かつ、コンテンツデータのサイズがパケットデータ中に記載されており、再生が終了していると判断された場合、または、フローが切断されている判断された場合に、再生状態推定部１４０による推定結果が「停止状態」と推定された場合には、再生停止時間推定部１５０は、再生が停止された時刻や時間などの再生状態に関する情報の推定を行う。
【００４９】
停止状態においてもバッファ量の増減を同様に行うが、再生端末２００でのコンテンツの再生は停止された状態にあるため、アプリケーションが消費するデータ量は0となり、受信量の増分が加わるのみとなる。ことのきバッファ量の残量がThpを上回った場合に、コンテンツの再生が開始されるものと判定を行う。
【００５０】
再生停止時間推定部１５０では、再生状態推定部１４０から取得した再生状態遷移情報から、再生が停止された時間およびその長さの推定を行う。なお、ここで、再生状態推定部１４０は、再生状態遷移情報として再生状態が遷移した時刻を内部のメモリ(図示せず)に記録しておき、再生提示時間推定部１５０が取得するものとする。
【００５１】
出力される推定結果の一例を図５に示す。なお、当該推定結果を加工することで、総停止時間や停止回数を出力することも可能である。
【００５２】
［実施の形態１−２］
図６は、実施の形態１−２におけるシステム構成を示す。同図において、図１の構成と同一構成部分には同一符号を付し、その説明を省略する。
【００５３】
図６に示すコンテンツ再生情報推定装置４００は、図１のコンテンツ再生情報推定装置１００の構成にバッファパラメータ推定部４１０を付加した構成である。
【００５４】
図７は、本発明の第２の実施の形態における処理のフローチャートであり、第１の実施の形態の図２のフローと同一の処理については同一ステップ番号を付す。
【００５５】
ステップ１０１） コンテンツ再生情報推定装置４００のパケット情報取得部１１０において、配信サーバ３００と再生端末２００間で交換されるパケット情報の一部またはすべての情報を取得する。
【００５６】
ステップ２０１） バッファパラメータ推定部４１０では、パケット情報取得部１１０で取得したネットワークを介して送受信されるパケット情報からバッファパラメータを推定する。バッファパラメータとして、コンテンツの再生を開始するバッファ量の閾値やコンテンツの再生を停止するバッファ量の閾値、映像の符号化レートなどが該当する。推定に当たっては、予め定められたパケット中のデータのパターンマッチングによって行う。例えば、コンテンツの再生を開始するバッファ量の閾値として、HTTP GETメッセージで、"bc"というパラメータで送受されるとした場合には、"bc="に引き続く数字列を当該バッファパラメータとする。
【００５７】
ステップ１０２） 次に、コンテンツ受信量推定部１２０において、パケット情報取得部１１０から取得したパケット情報の一部またはすべてから、再生端末２００上の再生アプリケーションに渡されるデータ量の時系列情報を推定し、再生開始時間推定部１３０に出力する。
【００５８】
ステップ１０３） 再生開始時間推定部１３０では、コンテンツ受信量推定部１２０で推定されたデータ量の時系列情報から、再生開始に要する時間を推定する。例えば、再生開始に要する時間は、バッファパラメータ推定部１３０で推定されたバッファパラメータ（コンテンツが再生を開始するバッファ量の閾値）までデータを受信するのに要した時間とする。
【００５９】
ステップ１０４） また、再生状態推定部１４０では、再生端末２００上の再生アプリケーションが再生開始後の各時間に消費するデータ量から、通信開始後の任意の時刻において、再生が継続されているかどうかを判定する。例えば、以下の手順で判定を行う。
【００６０】
バッファパラメータ推定部４１０で取得したバッファパラメータとして、コンテンツの再生を開始するバッファ量の閾値をthp、コンテンツの再生を停止するバッファ量の閾値をthsとする。このとき、コンテンツ受信量推定部１２０で得られた受信量の時系列データ及び再生アプリケーションの再生時間後の各時間に消費するデータ量を入力とし、バッファ量の増減を行う。すなわち再生上にある場合、ある時刻において受信量がΔB増えていた場合には、バッファ量をΔB増分し、再生アプリケーションで消費されるデータ量がΔC増えていた場合には、バッファ量をΔC減少させる。これらの演算の結果、バッファ量の残量がthsを下回った場合には、「再生状態」から「停止状態」に遷移させる。
【００６１】
なお、再生アプリケーションが再生開始後の各時間に消費するデータ量の求め方は前述の実施の形態１−１と同様である。
【００６２】
ステップ１０５） 再生状態推定部１４０で推定された再生状態が「停止状態」の場合には、再生停止時間推定部１５０において、再生が停止された時刻や時間などの再生状態に関する情報の推定を行う。「停止状態」においてもバッファ量の増減を同様に行うが、コンテンツは停止された状態にあるため、アプリケーションが消費するデータ量は0となり、受信量の増分が加わるのみとなる。ことのきバッファ量の残量がThpを上回った場合に、コンテンツの再生が開始されるものと判定を行う。
【００６３】
再生停止時間推定部１５０では、前記再生状態推定部１４０から、再生が停止された時刻及び停止されていた時間の推定を行う。
【００６４】
［実施の形態１−３］
図８は、実施の形態１−３におけるシステム構成を示す。
【００６５】
同図において、図１、図６と同一構成部分には同一符号を付す。
【００６６】
また、図９は、実施の形態１−３における処理のフローチャートであり、図２、図７と同様の処理については説明を省略する。
【００６７】
本実施の形態では、第１、第２の実施の形態において、ネットワークを介して送受信されるパケット情報から、再生端末２００にて受信したコンテンツデータの各再生時刻において再生バッファ２１０から読み出されるデータ量を推定する再生レート推定部５１０を有し、当該再生レート推定部５１０の推定結果を再生開始時間推定部１３０に入力することを特徴とする。
【００６８】
再生レート推定部５１０では、例えば、パケット情報取得部１１０で取得したパケット情報から配信サーバ３００−再生端末２００間で送受される情報を再構成し、再生端末２００で再生されるコンテンツを抽出し、符号化された映像・音声データから、各再生時刻におけるデコード量を推定し、それを再生開始後の各時間に消費するデータ量として、再生開始時間推定部１３０に入力する（ステップ３０１）。パケットの情報からコンテンツの再生情報を推定することで前記端末上のアプリケーションが各時間に消費するデータ量をより正確に推定することができる。
【００６９】
なお、再生レート推定部５１０以外の処理は前述の実施の形態と同様であるので、その説明を省略する。
【００７０】
［実施の形態１−４］
図１０は、実施の形態１−４におけるシステム構成を示す。同図において、前述の実施の形態１−１〜１−３における図１、図６、図８と同一構成部分には同一符号を付す。
【００７１】
図１１は、実施の形態１−４における処理のフローチャートである。
【００７２】
本実施の形態のコンテンツ再生情報推定装置６００では、実施の形態１−１、１−２において、ネットワークを介して送受信されるパケット情報から、再生端末２００にて受信したコンテンツデータの総量およびコンテンツの再生時間長を推定するコンテンツ情報推定部６１０を有し、当該コンテンツ情報推定部６１０の推定結果を、再生状態推定部１４０に入力する。
【００７３】
コンテンツ情報推定部６１０では、例えば、パケット情報取得部１１０で取得したHTTP GETメッセージの送受中に含まれるContent-Lengthヘッダや、TCPフローの生起および終了時のシーケンス番号の差分などの情報から、再生端末２００にて受信したコンテンツデータの総量を推定する。また、コンテンツの再生時間長の推定にあたっては、予め定められたパケット中のデータのパターンマッチングによって行う。例えば、HTTP GETメッセージで、"len"
というパラメータで送受されるとした場合には、"len="に引き続く数字列を当該バッファパラメータとして推定する（ステップ４０１）。
【００７４】
推測されたコンテンツデータの総量をB，コンテンツの時間長をlenとおくと，当該コンテンツの平均ビットレートはB/lenとして考えることができるため、再生端末３００上のアプリケーションが再生開始後の各時間に消費するデータ量をこの平均ビットレートから線形に算出し、再生状態推定部１４０への入力とする。
【００７５】
その他の構成要素の処理は、前述の実施の形態と同様であるので、その説明を省略する。
【００７６】
［実施の形態１−５］
本実施の形態におけるシステム構成は、実施の形態１−４と同様であるが、本実施の形態では、コンテンツ情報推定部６１０において、予め定められたコンテンツ毎の再生レート固定値と再生端末２００にて受信したコンテンツデータから、各再生時刻において再生バッファから読み出されるデータ量を推定し、推定結果を再生状態推定部１４０に入力する。このとき、再生端末２００で受信したコンテンツデータは、パケット情報取得部１１０を介してコンテンツ情報推定部６１０に入力される。
【００７７】
本実施の形態におけるコンテンツ情報推定部６１０では、例えば配信システムにおいて「高画質」「低画質」等の予め定められたコンテンツの画質情報等に基づき、再生レートを離散値として用意する。また、パケット情報から交換される情報からコンテンツ画質情報を推定し、該当する再生レートを当該コンテンツデータの平均ビットレートとする。この平均ビットレートを用いて，端末上のアプリケーションが再生開始後の各時間に消費するデータ量を線形に算出し、再生状態推定部への入力とする。
【００７８】
その他の処理は、前述の実施の形態１−４と同様であるのでその説明を省略する。
【００７９】
なお、上記の実施の形態１における図１、図６、図８、図１０の各コンテンツ再生情報推定装置の構成要素の動作をプログラムとして構築し、コンテンツ再生情報推定装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。
【００８０】
すなわち、実施の形態１における各コンテンツ再生情報推定装置は、コンピュータに、本実施の形態１で説明する処理内容を記述したプログラムを実行させることにより実現可能である。より詳細には、コンテンツ再生情報推定装置の各部が有する機能は、当該コンテンツ再生情報推定装置を構成するコンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、各部で実施される処理に対応するプログラムを実行することによって実現することが可能である。当該プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、当該プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。
【００８１】
＜実施の形態２＞
次に、図面と共に本発明の実施の形態２を説明する。
【００８２】
本実施の形態２は、ネットワークを介して配信されたコンテンツデータを受信、再生するサービスを提供するシステムにおいて、当該システムに改変を加えることなく、配信経路上においてパケットキャプチャと分析を行うことで、当該システムにおいてコンテンツデータを受信、再生する端末における再生停止状態の推定を行うものである。
【００８３】
図１２は、実施の形態２におけるコンテンツ再生情報推定装置の構成を示す。
【００８４】
同図に示すコンテンツ再生情報推定装置７００は、チャンク単位の配信を行う配信サーバ１０と端末２０に接続されており、パケットデータ取得部７１０、記憶部７２０、再生状態推定部７３０、チャンク状態推定部７４０から構成される。端末２０は、少なくとも再生バッファと再生アプリケーションを有する。
【００８５】
本実施の形態では、配信サーバ１０は、端末２０に対して、一つのコンテンツを複数のチャンク単位に分割して配信する。端末２０は、再生バッファを有し、当該再生バッファに、所定のチャンク数が蓄積されると、再生を開始し、再生中は、当該再生バッファから再生に必要なデータを読み出し、再生バッファに蓄積されたチャンク数が再生停止閾値を下回ると再生が停止し、再生開始閾値を上回ると再生が開始する機能を有する。
【００８６】
パケットデータ取得部７１０は、配信サーバ１０から端末２０に対してチャンク単位で配信されるパケットの情報を取得し、記憶部７２０に格納する。取得する情報として、パケットの情報（パケットデータ）、チャンク単位のパケットキャプチャ情報、コンテンツリスト等である。チャンク単位のパケットキャプチャ情報は、パケット単位のキャプチャデータをチャンク単位に分割して取得する。
【００８７】
チャンク状態推定部７４０は、チャンクの時間長推定部７４１とチャンクの取得時刻推定部７４２を有する。
【００８８】
チャンクの時間長推定部７４１は、記憶部７２０からチャンクの情報、またはあらかじめ既知のコンテンツ規則等を読み出して、各チャンクの再生時間長のリストを作成する。再生時間長のリストは、例えば1次元の配列として保持できるし、チャンク番号と対応させた2次元の配列として保持してもよい。
【００８９】
チャンクの取得時刻推定部７４２は、記憶部７２０からパケットキャプチャ情報を読み出して、各チャンクの送受信が完了した時刻を推定し、各チャンクの取得時刻のリストを作成する。取得時刻のリストは、例えば１次元の配列として保持できるし、チャンク番号と対応させた2次元の配列として保持してもよい。
【００９０】
再生状態推定部７３０は、チャンクの時間長推定部７４１で作成された各チャンクの再生時間長のリストおよびチャンクの取得時刻推定部７４２で作成された各チャンクの取得時刻のリストから、各時刻における再生バッファ中の残個数について推定し、現在コンテンツが再生状態にあるのか、または停止時状態にあるのか、また、再生開始に要する時間等の再生情報の推定を行う。
【００９１】
例えば、端末２０において、１つでもチャンクの受信を完了すると再生が開始され、チャンクの個数が０になると再生が停止するシステムを想定する。このとき、コンテンツ再生開始要求の直後に、パケットデータ取得部７１０において、３つのチャンクデータを受信しており、３つのチャンクデータで30秒のコンテンツ時間長を有していると仮定すると、再生開始直後に再生が開始され、再生状態が30秒継続する。また、この次のチャンクデータが到着しない間は、再生の停止状態が継続し、次のチャンクデータを受信完了した時点で再生が再開される。以降は同様に、受信完了したチャンクデータの残個数により、再生状態を推定する。
【００９２】
［実施の形態２−１］
以下では、コンテンツ再生情報推定装置として前述の図１２に基づいて説明する。
【００９３】
コンテンツデータの配信サーバ１０と端末２０の間に設置されたコンテンツ再生情報推定装置７００は、パケットデータ取得部７１０において、配信サーバ１０と端末２０間でチャンク単位に交換されるパケットデータの一部またはすべての情報を取得し、記憶部７２０に格納する。このパケットデータ取得部７１０は、一般的なパケットモニタ装置、プログラム等で代替可能である。また、キャプチャされたパケットデータを記憶部７２０に格納せずに、直接チャンクの時間長推定部７４１、またはチャンクの取得時間推定部７４２への入力としてもよい。本実施の形態では、記憶部７２０にパケットデータを格納し、チャンク状態推定部７４０において、パケットデータを読み出すものとして説明する。また、チャンクの時間長推定部７４１及びチャンクの取得時間推定部７４２は、メモリ（図示せず)を有し、チャンクの再生時間長のリストであるチャンク時間長リスト及びチャンクの取得時刻リストを格納するものとする。
【００９４】
図１３は、実施の形態２−１における動作の概要を示すフローチャートである。
【００９５】
本実施の形態では、同図に示すように、パケットデータが入力される度にパケットデータ取得部７１０において、記憶部７２０に格納し(ステップ５０１)、チャンクの再生時間長推定部７４１が記憶部７２０からパケットデータを読み出して、チャンクの再生時間長を推定し、チャンク時間長リストを更新する(ステップ５０２)。また、チャンクの取得時刻推定部７４２が記憶部７２０からパケットデータを読み出して、チャンクの取得時刻を推定し、チャンクの取得時刻リストの更新を行い(ステップ５０３)、フロー受信が終了した時点で(ステップ５０４,Yes)、再生状態推定部７３０による処理を行う（ステップ５０５）。
【００９６】
チャンクの時間長推定部７４１は、記憶部７２０に格納されたパケットデータ（チャンク番号と時間長）の一部またはすべてから、端末２０上の再生アプリケーションに渡される各チャンクの再生時間長を推定し、チャンク時間長リストとしてメモリ（図示せず）に格納する。各チャンクの再生時間長は、事前に決められたフォーマット等でコンテンツリスト（ファイルリスト）を配信サーバ１０と交換し、その中の時間長の記載から抽出してもよい。また、各チャンクの再生時間長は一定ではなく、コンテンツの識別子等から事前に取得したチャンクの再生時間長に該当する時間長としてもよい。また、各チャンクのエンコードされたデータをデコードし、対応するコーデックのタイムスタンプ等から時間長を推定してもよい。例えば、コンテンツリスト（ファイルリスト）として、HLS（HTTP Live Streaming）（R. Pantos, Ed., W. May, "HTTP Live Streaming," IETF Internet-Draft, Sept. 2011.参照）に準拠した形式であり、コンテンツリスト中に各チャンクファイルのURI（Unified Resource Indicator）および時間長が記載されているものを用いることができる。
【００９７】
チャンクの取得時刻推定部７４２は、記憶部７２０に格納されているパケットデータの一部またはすべてから、端末２０上の再生アプリケーションに渡される各チャンクの取得時刻をパケットデータから得られるチャンクの取得完了時刻から推定し、チャンクの取得時刻リストとしてメモリ（図示せず）に格納する。取得時刻は、各チャンクの取得が完了した時刻を指すが、取得完了時刻の取得が困難な場合には、取得開始時刻をその代替としてもよい。なお、ここで、取得開始時刻を用いると、微少なタイムラグがあるが、ネットワークの状態がある程度一定であると仮定すると、一定時間の相対的な差となるため、許容できる。なお、取得完了時刻と開始時刻の両者を用いて判定を行うプロセスにおいては、完了時刻を開始時刻で代替することはできない。
【００９８】
再生状態推定部７３０は、チャンクの時間長推定部７４１で推定、作成された各チャンクの再生時間長及びチャンクの取得時刻推定部７４２で推定、作成された各チャンクの取得時刻をもとに、コンテンツの再生状態の推定を行う。
【００９９】
例えば、以下の手順で推定を行う。
【０１００】
まず、再生アプリケーションにおけるバッファパラメータとして、
・コンテンツの再生を開始する際のバッファ中のチャンク数の閾値th_p；
・再生を停止するチャンク数の閾値th_s；
・再生を再開する際のチャンク数の閾値th_r；
を予め設定する。このとき、任意の時刻において端末２０のバッファに蓄積されているチャンク数の推定を、チャンク状態推定部７４０で推定された各チャンクの再生時間長（チャンクの再生時間長のリスト）及び各チャンクの取得時刻（各チャンクの取得時刻のリスト）をもとに行う。th_p個目のチャンクを取得した時刻をT_0として、推定された再生開始時刻とする。ここで、再生開始のチャンク数の閾値th_pを越えた時刻を再生開始時刻推定値とする。
【０１０１】
次に、再生中のチャンク番号を示す変数ｉを1に設定し、現在バッファに蓄積されているチャンク数をnとしてth_pを設定する。また、再生状態の推定を行う対象時刻TにT_0を設定する。ここで、コンテンツの最初のチャンクのチャンク番号ｉを1とし、以降、チャンクの再生順に1加算した値（ｉ＝ｉ＋１）をチャンク番号ｉに設定し、チャンクの再生時間長のリストの各ｉ番目のチャンクの再生時間長をlen_iとおき、チャンクの取得時刻リストの各チャンクの取得時刻を、コンテンツの最初のチャンクデータの取得開始の時刻を0とした相対値でt_iとおく。以下、本実施の形態では、特別の記述がない限り、時刻はすべて再生開始からの相対値として考える。
【０１０２】
ｉ番目のチャンク再生後に停止が発生するかを以下の手順で確認する。
【０１０３】
図１４は、実施の形態２−１における停止推定手順のフローチャートである。
【０１０４】
ステップ６００） カウンタｎ＝０，CNT＝０とする。
【０１０５】
ステップ６０１） 各チャンクの取得時刻を記録したリストにおいて、取得時刻が、前回バッファに蓄積されているチャンク数ｎを増加した時刻Tより大きく、T+len_i以下となる(T＜ｔ_i≦T+len_i)チャンクの個数（CNT）をカウントし、現在バッファに蓄積されているチャンク数nに加算する。
【０１０６】
ステップ６０２） 現在バッファに蓄積されているチャンク数ｎから1減少させる。
【０１０７】
ステップ６０３） 現在バッファに蓄積されているチャンク数ｎと再生を停止するチャンク数の閾値th_sを比較し、ｎが大きい場合には、再生状態にあるとし、ｎが等しいか、または小さい場合には、停止状態になったと推定する。
【０１０８】
ステップ６０４） また、各種変数に対し、Tをlen_i増加させ（T=T+len_i）、ｉを１増加させ(ｉ＝ｉ＋１)、更新する。
【０１０９】
ステップ６０５） コンテンツを構成するチャンクのうち、コンテンツリストに記載のファイル全てを処理していない、または、予め決められた個数のチャンクを処理していない場合は、未処理のチャンクがあると判定し、ステップ６０３で再生状態であると判断されている場合には、ステップ６０１に移行する。一方、未処理のチャンクがあり、ステップ６０３で停止状態であると判断されている場合は、ステップ６０６に移行する。すべてのチャンクを処理している場合には、ステップ６１０に移行する。なお、コンテンツリストには、少なくとも、コンテンツ識別子(ＩＤ)、当該コンテンツに含まれるチャンク毎のチャンク識別子（ＩＤ）が含まれているものとし、現在処理対象のチャンクが最終のチャンクでない場合は、未処理のチャンクがあるものと判断する。
【０１１０】
ステップ６０６） 未処理のチャンクがあり、停止状態の場合には、次のチャンクを取得した時刻までTを進め（Tの値を更新）、現在バッファに蓄積されているチャンク数nを1増加させる。
【０１１１】
ステップ６０７） 現在バッファに蓄積されているチャンク数nと再生を再開するチャンク数の閾値th_rを比較し、nがth_rより大きい場合には、ステップ６０８に移行し、nがth_rと等しいかまたはth_rより小さい場合には、ステップ６０９に移行する。
【０１１２】
ステップ６０８） 再生状態に遷移すると推定する。
【０１１３】
ステップ６０９） 引き続き停止状態にあると推定する。
【０１１４】
ステップ６１０） 以降を全て再生状態として、各時刻における再生状態の系列を出力する。
【０１１５】
上記のフローチャートの例を具体的な例を用いて示す。
【０１１６】
図１５Ａ、図１５Ｂに、具体例を示す。図１５Ａは、前提条件を示し、図１５Ｂは動作の遷移を示す。
【０１１７】
チャンク番号ｉがｉ＝１のとき、１番目のチャンク再生後の判断から開始するものとする。なお、開始の時点で、nはth_pと等しく、５である。
【０１１８】
［前回チャンク数を増加した時刻t_5（絶対値）＝10＜取得時刻(絶対値)≦T+len_1＝12］に該当するチャンク数をカウントし、t_6が該当するので、n=n+1＝6とする（ステップ６０１）。現在バッファに格納されているチャンク数６から１を引く（n＝6−1＝5）（ステップ６０２）。これにより、ｎ＝５であるので、th_s＝３より大きいため、再生状態と判定する（ステップ６０３、Yes）。T＝T＋len_1＝12、ｉ＝２とする(ステップ６０４)。未処理のチャンクがあり、再生状態と判定されているので、ステップ６０１の処理に戻る（ステップ６０５）。
【０１１９】
２回目の処理として、［前回チャンク数を増加した時刻t_6(絶対値)＝12＜取得時刻(絶対値)≦T＋len_2=14］に該当するチャンク数をカウントするが、t_7が該当しないケースであるのでチャンク数への加算を行わない(ステップ６０１)。n＝5−1＝4とし（ステップ６０２）、ｎ＝４であるため、th_s=3より大きいため、再生状態と判定する（ステップ６０３,Yes）。
【０１２０】
3回目の処理として、［前回のチャンク数を増加した時刻t_6（絶対値）＝12＜取得時刻(絶対値)≦T＋len_3＝16］に該当するチャンク数をカウントするが、t_7が該当しないケースであるのでチャンク数への加算を行わない（ステップ６０１）。n＝4−1＝3とし（ステップ６０２）、ｎ＝３であるため、th_s＝3と等しいため、停止状態と判定する(ステップ６０３,No)。T＝t＋len_3＝16，ｉ＝4とする(ステップ６０４)。ここで、未処理のチャンクがあるため、Tを次のチャンクの取得時間に更新する。この場合T=17となる。つまり、チャンク番号ｉ＝3は14〜16秒の間に再生されたが16秒において停止状態となった。
【０１２１】
停止状態となったため、次のチャンクを取得し、T＝t_7（絶対値）＝17、n＝n＋1＝3＋1＝4となる(ステップ６０６)。ｎ＝４であるため、再生を再開する際のチャンク数の閾値th_r(=４)と比較すると4≦４となり、等しいため停止状態と判定する（ステップ６０７）。
【０１２２】
次のチャンク取得時刻であるT＝18に更新し、次のチャンクを取得し、T＝t_8(絶対値)＝18であるので、n＝n＋1＝4＋1＝5とする（ステップ６０６）。n＝5でありth_r(=4)と比較すると、nのほうが大きいので、再生状態とする（ステップ６０７）。
【０１２３】
次にステップ６０１の処理に移行し、[前回チャンク数を増加した時刻t_8(絶対値)＝18＜取得時刻（絶対値）≦T+len_4=18]に該当するチャンク数をカウントするが、t_9が該当しないケースであるのでチャンク数への加算を行わない（ステップ６０１）。n=5−1=4とし（ステップ６０２）、n=4であり、4(n)＞3(th_s)となり、再生状態と判定する（ステップ６０３、Yes）。T=T+len_4=18，ｉ＝５とする（ステップ６０４）。未受信のチャンクがあり、再生状態であるので（ステップ６０５）、ステップ６０１の処理に移行する。
【０１２４】
ステップ６０１において、［前回チャンク数を増加した時刻t_8(絶対値)＝18＜取得時刻（絶対値）≦T+len_5=20］に該当するチャンク数をカウントし、n+2=7によりt_9,10が該当するケースであるので、ｎ＝7−1=6とする（ステップ６０１）。６(n)＞３（th_s）となるため、再生状態と判定する（ステップ６０３,Yes）。T=T+len_5＝20、ｉ＝６とする（ステップ６０４）。未受信のチャンクがあり、再生状態であるのでステップ６０１に移行する。
【０１２５】
上記のようにして導出された再生状態判定結果に基づいて、総停止時間や停止回数等の統計情報を求めることが可能となる。なお、統計情報を求めることは既存の技術を用いて実現可能であり、本発明の範囲外であるのでその説明は省略する。
【０１２６】
なお、各種の閾値は、再生状態や停止の回数等に応じて動的に変動する値でもよいものとする。
【０１２７】
また、チャンクの取得時刻指定部７４２において、パケットデータから時間長の取得が困難な場合には、チャンク取得の時間間隔から導出される値をチャンクの時間長としてもよい。
【０１２８】
［実施の形態２−２］
上記の実施の形態２−１では、取得済みのチャンク数の遷移を推定することで再生状態の推定を行うことができるが、キャプチャデータを基に再生停止と推定された場合において、再生停止の発生原因がネットワークに起因するものか、利用者の行動に起因するものかを区別することを考慮していない。
【０１２９】
本実施の形態では、再生停止の原因がネットワークか利用者の行動のいずれであるかを推定するために以下の処理を行う。
【０１３０】
図１６は、実施の形態２−２における停止推定手順のフローチャートである。
【０１３１】
ステップ７０１） カウンタｎとCNTを初期化し、n=0、CNT=0とする。
【０１３２】
ステップ７０２） 各チャンクの取得時刻を記録したリストにおいて、取得時刻が、前回バッファに蓄積されているチャンク数ｎを増加した時刻Tより大きく、T+len_i以下となる(T＜ｔ_i≦T+len_i)チャンクの個数をカウントし、現在バッファに蓄積されているチャンク数nに加算する。
【０１３３】
ステップ７０３） ステップ７０２で加算対象としたチャンクに対して、取得開始時刻を時系列でソートした際に、ｉ番目とｉ＋１番目のチャンク番号が不連続となっている（チャンク番号の増加数が１でない）か、を判定し、連続している場合はステップ７０４に移行し、チャンク番号が不連続の場合は、ユーザ操作により蓄積されているチャンクの範囲外への早送り、巻き戻し等が発生したものと判定し、ステップ７０１に移行し、各カウンタをリセットする。また、このフローにおける判定を打ち切り、検出した非連続な番号（ｉ＋１番目）から推定を開始する。
【０１３４】
ステップ７０４） ステップ７０２で加算対象とした各チャンクに対して、チャンクの取得開始時刻及び取得完了時刻から、チャンクの取得が完了してから次のチャンクの取得を開始するまでの時間ｔを算出する。
【０１３５】
ステップ７０５） ステップ７０４で算出された時刻ｔが直前に再生していたチャンクの再生時間長len_(i−１)よりも一定程度（α）大きい場合は、ユーザ操作により再生が一時停止されたものと判定し、ステップ７０６に移行する。
【０１３６】
ここで、一定程度(α)とは、推定された各チャンクの再生時間と実際の再生時間の誤差を吸収するための値であり、チャンクの再生時間の長さであるチャンクの再生時間長そのものを用いてもよいし、１．１倍などの固定の値を用いる方法や、一定時間長を用いたり、ネットワーク遅延時間の分散を考慮した値を用いてもよい。当該一定程度の時間をどのように決定するかにより精度が変化する。精度を向上させるには、想定されるチャンクの再生時間長と実際の時間長との誤差（ずれ）を許容できるような幅を持って設定する必要がある。一方で、ユーザ操作として識別したい最低の時間長より小さい誤差である必要がある。そのため、αとして、１秒程度の固定的な時間長を用いることが望ましい。また、サービス毎に検証を行い、最適値を定めてもよい。
【０１３７】
ステップ７０６） ステップ７０５において再生が一時停止状態と判定された場合には、バッファに蓄積されているデータ量の減少は行わない。また、バッファの減少を行わない時間の起点は、最後に受信したチャンクの取得開始時刻rr_jにチャンク時間長を加えた値から、最後に受信したチャンクの取得完了時刻rs_jにチャンク時間長を加えた値までの任意の時点としてもよい。例えば、rr_j−rs_jがチャンク時間長より小さい場合には、バッファの減少を行わない時刻の起点を、rs_j+チャンク時間長／２とし、大きい場合には、rr_iを採用する、などしてもよい。また、次に新たなチャンクの取得を開始された場合に、ステップ７０２に移行する。
【０１３８】
チャンクを用いた映像配信サービスでは、新たなチャンクの取得が再生状態と密接に関連する。特に、端末において再生前に蓄積可能なチャンク数や該当する再生時間長に上限がある場合、再生中のチャンクの再生が終了していない限り新たなチャンクの取得が行われないことが特徴である。そのため、チャンクのダウンロードが完了してから、次のチャンクのダウンロードが開始されるまでの時間に着目することで、当該チャンクの再生開始から再生終了までに要した時間が、当該チャンクの再生時間の長さにかかるチャンクの再生時間長よりも長い場合(ステップ７０５,Yes)には、ユーザ操作によって発生した一時停止と判定することが可能となる。
【０１３９】
また、ユーザ操作が関与しない場合には、コンテンツは予め定められた順番に再生される。そのため、チャンク番号は必ず連続になるため、チャンク番号が非連続となった場合（ステップ７０３,Yes）には、ユーザ操作が行われたものと判定できる。
【０１４０】
ステップ７０７） 現在バッファに蓄積されているチャンク数ｎから1減少させる。
【０１４１】
ステップ７０８） 現在バッファに蓄積されているチャンク数ｎと再生を停止するチャンク数の閾値th_sを比較し、ｎが大きい場合には、再生状態にあるとし、ｎがth_sと等しいか、または小さい場合には、停止状態になったと推定する。
【０１４２】
ステップ７０９） また、各種変数に対し、Tをlen_i増加させ（T=T+len_i）、ｉを１増加させ(ｉ＝ｉ＋１)、更新する。
【０１４３】
ステップ７１０） コンテンツを構成するチャンクのうち、コンテンツリストに記載のファイル全てを処理していない、または、予め決められた個数のチャンクを処理していない場合は、未処理のチャンクがあると判定し、ステップ７０８で再生状態であると判断されている場合には、ステップ７０２に移行する。一方、未処理のチャンクがあり、ステップ７０８で停止状態であると判断されている場合は、ステップ７１１に移行する。すべてのチャンクを処理している場合には、ステップ７１５に移行する。なお、コンテンツリストには、少なくとも、コンテンツ識別子(ＩＤ)、当該コンテンツに含まれるチャンク毎のチャンク識別子（ＩＤ）が含まれているものとし、現在処理対象のチャンクが最終のチャンクでない場合は、未処理のチャンクがあるものと判断する。
【０１４４】
ステップ７１１） 未処理のチャンクがあり、停止状態の場合には、次のチャンクを取得した時刻までTを進め（Tの値を更新）、現在バッファに蓄積されているチャンク数nを1増加させる。
【０１４５】
ステップ７１２） 現在バッファに蓄積されているチャンク数nと再生を再開するチャンク数の閾値th_rを比較し、nがth_rより大きい場合には、ステップ７１３に移行し、nがth_rと等しいかまたはth_rより小さい場合には、ステップ７１４に移行する。
【０１４６】
ステップ７１３） 再生状態に遷移すると推定する。
【０１４７】
ステップ７１４） 引き続き停止状態にあると推定する。
【０１４８】
ステップ７１５） 以降を全て再生状態として、各時刻における再生状態の系列を出力する。
【０１４９】
上記のフローチャートの例を具体的な例を、実施の形態２−１と同様に、前述の図１５Ａ、１５Ｂを用いて示す。
【０１５０】
実施の形態２−１と同様に、チャンク番号ｉがｉ＝１のとき、１番目のチャンク再生後の判断から開始するものとする。
【０１５１】
［前回チャンク数を増加した時刻t_5（絶対値）＝10＜取得時刻(絶対値)≦T+len_1＝12］に該当するチャンク数をカウントし、t_6が該当するので、n+1＝6とする（ステップ７０２）。現在バッファに格納されているチャンク数６から１を引く（n＝6−1＝5）（ステップ７０７）。これにより、ｎ＝５であるので、th_s＝３より大きいため、再生状態と判定する（ステップ７０８、Yes）。T＝T＋len_1＝12、ｉ＝２とする(ステップ７０９)。未処理のチャンクがあり、再生状態と判定されているので、ステップ７０２の処理に戻る（ステップ７１０）。
【０１５２】
２回目の処理として、［前回チャンク数を増加した時刻t_6(絶対値)＝12＜取得時刻(絶対値)≦T＋len_2=14］に該当するチャンク数をカウントするが、t_7が該当しないケースであるのでチャンク数への加算を行わない(ステップ７０２)。n＝5−1＝4とし（ステップ７０７）、ｎ＝４であるため、th_s=3より大きいため、再生状態と判定する（ステップ７０８,Yes）。
【０１５３】
3回目の処理として、［前回のチャンク数を増加した時刻t_6（絶対値）＝12＜取得時刻(絶対値)≦T＋len_3＝16］に該当するチャンク数をカウントするが、t_7が該当しないケースであるのでチャンク数への加算を行わない（ステップ７０２）。n＝4−1＝3とし（ステップ７０７）、ｎ＝３であるため、th_s＝3と等しいため、停止状態と判定する(ステップ７０８,No)。T＝t＋len_3＝16，ｉ＝4とする(ステップ７０９)。ここで、未処理のチャンクがあるため、Tを次のチャンクの取得時間に更新する。この場合T=17となる。つまり、チャンク番号ｉ＝3は14〜16秒の間に再生されたが16秒において停止状態となった。
【０１５４】
停止状態となったため、次のチャンクを取得し、T＝t_7（絶対値）＝17、n＝n＋1＝3＋1＝4となる(ステップ７１１)。ｎ＝４であるため、再生を再開する際のチャンク数の閾値th_r(=４)と比較すると4≦４となり、等しいため停止状態と判定する（ステップ７１２）。
【０１５５】
次のチャンク取得時刻であるT＝18に更新し、次のチャンクを取得し、T＝t_8(絶対値)＝18であるので、n＝n＋1＝4＋1＝5とする（ステップ７１１）。n＝5でありth_r(=４)と比較するとnのほうが大きいので、再生状態とする（ステップ７１２）。
【０１５６】
次にステップ７０２の処理に移行し、[前回チャンク数を増加した時刻t_8(絶対値)＝18＜取得時刻（絶対値）≦T+len_4=18]に該当するチャンク数をカウントするが、t_9が該当しないケースであるのでチャンク数に加算しない（ステップ７０２）。n=5−1=4とし（ステップ７０７）、n=4であり、4(n)＞3(th_s)となり、再生状態と判定する（ステップ７０８、Yes）。T=T+len_4=18，ｉ＝５とする（ステップ７０９）。未受信のチャンクがあり、再生状態であるので（ステップ７１０）、ステップ７０２の処理に移行する。
【０１５７】
ステップ７０２において、［前回チャンク数を増加した時刻t_8(絶対値)＝18＜取得時刻（絶対値）≦T+len_5=20］に該当するチャンク数をカウントする。n+2=7によりt_9,10が該当するケースであるので、ｎ＝7−1=6とする（ステップ７０２）。６(n)＞３（th_s）となるため、再生状態と判定する（ステップ７０８,Yes）。T=T+len_5＝20、ｉ＝６とする（ステップ７０９）。未受信のチャンクがあり、再生状態であるのでステップ７０２に移行する。
【０１５８】
上記のようにして導出された再生状態判定結果に基づいて、総停止時間や停止回数等の統計情報を求めることが可能となる。なお、統計情報を求めることは既存の技術を用いて実現可能であり、本発明の範囲外であるのでその説明は省略する。
【０１５９】
なお、各種の閾値は、再生状態や停止の回数等に応じて動的に変動する値でもよいものとする。
【０１６０】
また、チャンクの取得時刻指定部７４２において、パケットデータから時間長の取得が困難な場合には、チャンク取得の時間間隔から導出される値をチャンクの再生時間長としてもよい。
【０１６１】
チャンクを用いた映像のサービスでは、再生に先駆けてチャンクのダウンロードを行い、一定数のチャンクを蓄積することで再生を開始する。また、ひとたび再生が開始されると、既に取得した未再生のチャンクが一定数あれば再生を継続するが、一定数を下回ると再生が停止する。例えば、取得済みの未再生のチャンクが０であり、次に再生すべきチャンクをダウンロード中の場合には、再生を継続することができないため、一時停止状態となる。
【０１６２】
従って、取得済みのチャンク数の推移を推定することで、再生状態の推定を行うことが可能となる。取得済みのチャンク数が変化するタイミングは、新たにチャンクを取得完了した場合及び再生中のチャンクの再生を完了した場合の２つに限定される。そのため、キャプチャデータから前者を、コンテンツのビットレート及び経過時間で後者を推定することで、取得済みで未再生のチャンク数の推定を行う。
【０１６３】
［実施の形態２−３］
図１７は、実施の形態２−３の動作のフローチャートである。
【０１６４】
実施の形態２−１、２−２は、事前にキャプチャデータから時間長リスト、取得時刻リストを作成するものであったが、本実施の形態では、キャプチャデータの入力の度に当該２つのリストの更新を順不同で行い、T+len_iの再生時間が経過した時点で、再生状態推定部７３０の処理を行い、新たに再生状態の推定を行う対象時刻Tを更新する。図１７のフローチャートにおいて、「新たなチャンクを再生に使用」（ステップ８０４）とは、
・再生状態にあるときに、ｉをインクリメントして、再生バッファ中のチャンクを再生する；
・停止状態にあるときに、新たにチャンクのデータを取得；の２つの意味を含む。
【０１６５】
［実施の形態２−４］
実施の形態２−１、２−２のチャンクの時間長推定部７４１において、時間を直接出すのではなく、受信バイト量および再生レートからチャンクの再生時間長を推定する。なお、チャンクの受信バイト量は、パケット情報取得部７１０においてチャンク単位の情報を出力する際に容易に取得できる。また、再生レートは、予め定められた識別子（例えば、コンテンツリストやチャンクを示すURL中の画質サイズを表す文字列等）によって規定されたものでもよく、また、コンテンツリストに直接記載してあるものを用いてもよい。
【０１６６】
上記のように、本実施の形態２では、コンテンツ配信システムの配信サーバと再生端末間の経路上においてパケットデータを取得し、その情報をもとに再生情報の推定を行うことで、配信システムへの改変を伴わずに、再生情報の取得を行うことができる。
【０１６７】
なお、上記の図１２のコンテンツ再生情報推定装置の各構成要素の動作をプログラムとして構築し、コンテンツ再生情報推定装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。
【０１６８】
すなわち、図１２のコンテンツ再生情報推定装置は、コンピュータに、本実施の形態２で説明する処理内容を記述したプログラムを実行させることにより実現可能である。より詳細には、コンテンツ再生情報推定装置の各部が有する機能は、当該コンテンツ再生情報推定装置を構成するコンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、各部で実施される処理に対応するプログラムを実行することによって実現することが可能である。当該プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、当該プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。
【０１６９】
なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。
【０１７０】
本国際出願は２０１１年１１月２日に出願した日本国特許出願２０１１−２４１１７３号、２０１２年２月１５日に出願した日本国特許出願２０１２−３１１２５号、及び２０１２年７月４日に出願した日本国特許出願２０１２−１５０９２６号に基づく優先権を主張するものであり、日本国特許出願２０１１−２４１１７３号、日本国特許出願２０１２−３１１２５号、及び日本国特許出願２０１２−１５０９２６号の全内容を本国際出願に援用する。
【符号の説明】
【０１７１】
１００ コンテンツ再生情報推定装置
１１０ パケット情報取得部
１２０ コンテンツ受信量推定部
１３０ 再生開始時間推定部
１４０ 再生状態推定部
１５０ 再生停止時間推定部
２００ 再生端末
２１０ 再生バッファ
３００ コンテンツ格納装置
３１０ コンテンツ送出部
３２０ コンテンツ格納部
４００ コンテンツ再生情報推定装置
４１０ バッファパラメータ推定部
５００ コンテンツ再生情報推定装置
５１０ 再生レート推定部
６００ コンテンツ再生情報推定装置
６１０ コンテンツ情報推定部
１０   配信サーバ
２０   端末
７００ コンテンツ再生情報推定装置
７１０ パケットデータ取得部
７２０ 記憶部
７３０ 再生状態推定部
７４０ チャンク状態推定部
７４１ チャンクの時間長推定部
７４２ チャンクの取得時刻指定部
【図１】
0005875725.tif 000002
【図２】
0005875725.tif 000003
【図３】
0005875725.tif 000004
【図４】
0005875725.tif 000005
【図５】
0005875725.tif 000006
【図６】
0005875725.tif 000007
【図７】
0005875725.tif 000008
【図８】
0005875725.tif 000009
【図９】
0005875725.tif 000010
【図１０】
0005875725.tif 000011
【図１１】
0005875725.tif 000012
【図１２】
0005875725.tif 000013
【図１３】
0005875725.tif 000014
【図１４】
0005875725.tif 000015
【図１５Ａ】
0005875725.tif 000016
【図１５Ｂ】
0005875725.tif 000017
【図１６】
0005875725.tif 000018
【図１７】
0005875725.tif 000019