特許 7677424 データ中継装置、配信システム、データ中継方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2025-05-07

(45)【発行日】2025-05-15

(54)【発明の名称】データ中継装置、配信システム、データ中継方法、及びプログラム

(51)【国際特許分類】

   H04N 21/2387 20110101AFI20250508BHJP

   H04N 21/222 20110101ALI20250508BHJP

   H04N 21/61 20110101ALI20250508BHJP

【ＦＩ】

H04N21/2387

H04N21/222

H04N21/61

【請求項の数】 8

(21)【出願番号】P 2023531180

(86)(22)【出願日】2021-06-29

(86)【国際出願番号】 JP2021024478

(87)【国際公開番号】W WO2023275969

(87)【国際公開日】2023-01-05

【審査請求日】2023-12-15

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100103894

【弁理士】

【氏名又は名称】家入 健

(72)【発明者】

【氏名】向谷地 有

【審査官】川中 龍太

(56)【参考文献】

【文献】国際公開第２０２０／１５８８４４（ＷＯ，Ａ１）

【文献】特開２００９－２０６８４１（ＪＰ，Ａ）

【文献】国際公開第２０１１／０１８８６８（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ ２１／００ － ２１／８５８

(57)【特許請求の範囲】

【請求項1】

クライアント端末と、動画データを配信する配信サーバと、の間に配置され、前記配信サーバから配信された動画データを前記クライアント端末に送信するデータ中継装置であって、
前記クライアント端末から前記配信サーバに送信されるアップロードデータを受信し、前記アップロードデータが所定のアップロードデータであるか否かを判定する第１の判定部と、
前記判定された前記所定のアップロードデータの送信間隔に基づいて、前記クライアント端末で前記動画データの倍速再生が行われているか否かを判定する第２の判定部と、
前記第２の判定部による倍速再生の判定結果に基づいて、前記クライアント端末に送信する前記動画データの送信ビットレートをコントロールする制御部と、
を備える、データ中継装置。

【請求項2】

前記第１の判定部は、前記アップロードデータのデータサイズに基づいて、前記アップロードデータが前記所定のアップロードデータであるか否かを判定する、
請求項１に記載のデータ中継装置。

【請求項3】

前記第１の判定部は、前記クライアント端末から前記配信サーバに送信される前記アップロードデータのデータサイズに基づいて、前記アップロードデータが、前記動画データをリクエストするリクエストデータであるか、又は、前記動画データを受信したことを通知する確認応答データであるかを判定し、
前記所定のアップロードデータは、前記リクエストデータである、
請求項２に記載のデータ中継装置。

【請求項4】

前記第２の判定部は、前記クライアント端末で前記動画データの倍速再生が行われていると判定した場合は、前記リクエストデータの送信間隔に基づいて、前記クライアント端末で行われている倍速再生の再生速度をさらに判定する、
請求項３に記載のデータ中継装置。

【請求項5】

前記制御部は、前記第２の判定部による倍速再生の再生速度の判定結果に基づいて、前記クライアント端末に送信する前記動画データの送信ビットレートをコントロールする、
請求項４に記載のデータ中継装置。

【請求項6】

クライアント端末と、
動画データを配信する配信サーバと、
請求項１から５のいずれか１項に記載のデータ中継装置と、
を備える、配信システム。

【請求項7】

クライアント端末と、動画データを配信する配信サーバと、の間に配置され、前記配信サーバから配信された動画データを前記クライアント端末に送信するデータ中継装置によるデータ中継方法であって、
前記クライアント端末から前記配信サーバに送信されるアップロードデータを受信する受信ステップと、
前記アップロードデータが所定のアップロードデータであるか否かを判定する第１の判定ステップと、
前記判定された前記所定のアップロードデータの送信間隔に基づいて、前記クライアント端末で前記動画データの倍速再生が行われているか否かを判定する第２の判定ステップと、
前記倍速再生の判定結果に基づいて、前記クライアント端末に送信する前記動画データの送信ビットレートをコントロールする制御ステップと、
を含む、データ中継方法。

【請求項8】

クライアント端末と、動画データを配信する配信サーバと、の間に配置され、前記配信サーバから配信された動画データを前記クライアント端末に送信するコンピュータに、
前記クライアント端末から前記配信サーバに送信されるアップロードデータを受信する受信手順と、
前記アップロードデータが所定のアップロードデータであるか否かを判定する第１の判定手順と、
前記判定された前記所定のアップロードデータの送信間隔に基づいて、前記クライアント端末で前記動画データの倍速再生が行われているか否かを判定する第２の判定手順と、
前記倍速再生の判定結果に基づいて、前記クライアント端末に送信する前記動画データの送信ビットレートをコントロールする制御手順と、
を実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、データ中継装置、配信システム、データ中継方法、及びコンピュータ可読媒体に関する。

【背景技術】

【0002】

近年、動画配信の方式として、アダプティブビットレート（Adaptive Bitrate。以下、ＡＢＲと称す）を採用する動画配信サイトが増加している。ＡＢＲは、動画データを、視聴環境に合わせて、できるだけ高い画質でスムーズに再生できるようにするための動画配信技術である。動画配信に係る規格としては、複数の規格が存在する。代表的な規格としては、例えば、ＨＬＳ（HTTP（Hypertext Transfer Protocol）Live Streaming）、ＭＰＥＧ－ＤＡＳＨ（Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP）等がある。

【0003】

ＡＢＲでは、携帯電話機等であるクライアント端末（クライアント（Client）。以下、ＣＬと称す）の処理能力、解像度、回線速度等に応じて、動画データの画質を自動的に変更し、ＣＬで快適な動画データの視聴を可能としている。動画データの画質を動的に変えるため、動画データは、数秒～数十秒ごとに、セグメントとして分割され、複数の画質の動画データが配信サーバ（オリジンサーバ（Origin Server）。以下、ＯＳと称す）上に予め用意されている。ＣＬは、視聴環境に合わせて、取得するセグメントと画質を選択して、ＯＳに動画データをリクエストする。ＣＬがＯＳに動画データをリクエストする際には、ＨＴＴＰプロトコルが使われている。ＣＬは、ＨＴＴＰプロトコルを使用したリクエストデータ（ＨＴＴＰリクエストパケット）にセグメントと画質を指定して、そのリクエストデータをＯＳに送信し、ＯＳから、レスポンスデータとして、動画データを取得する。

【0004】

図１には、ＡＢＲの動画データの画質の時間変化の例が示されている。図１において、横軸は時間であり、縦軸は動画データの画質である。図１に示されるように、ＣＬは、００：００～００：１０の間は、画質が１０８０ｐのセグメントを選択し、００：１０～００：２０の間は、画質が４８０ｐのセグメントを選択し、００：２０～００：３０の間及び００：３０～００：４０の間は、画質が７２０ｐのセグメントを選択している。

【0005】

ＡＢＲの動画データの配信は、大きく２つのフェーズに分けられる。１つは、バッファリングフェーズ（buffering phase）であり、もう１つは、安定フェーズ（steady phase）である（図２）。図２には、ＣＬが、ＯＳから受信したデータ量の時系列変化の例が示されている。図２において、横軸は時間であり、縦軸はデータ量である。

【0006】

バッファリングフェーズでは、ＣＬとＯＳとの間のネットワークの状態を観測し、視聴環境に合った適切な動画の画質及び音声の音質が決定される。また、ＣＬ側で動画データの再生を開始するのに十分な動画データをバッファリングするために、ＯＳからバースト的に動画データが送られる。

【0007】

安定フェーズでは、バッファリングフェーズで動画の画質及び音声の音質が決定された後、ＣＬは、動画データの再生の進み具合に応じて、ＣＬ上にバッファリングされた動画データが枯渇しないように、一定の時間間隔で、ＯＳから分割された動画データ（セグメント）を取得する。

【0008】

図２に示されるように、ＣＬにおいて、動画データの再生を開始する際は、まず、バッファリングフェーズが開始され、その後、安定フェーズに移行する。また、安定フェーズに移行した後、再度、バッファリングフェーズに移行する場合もある。この再度のバッファリングは、再バッファと称される。例えば、ネットワークの状態が変化し、ＡＢＲの仕組みにより画質が変更された場合には、ＣＬ側で動画データを新たにダウンロードする必要があり、再バッファが発生する。ＣＬ側で再バッファが発生する要因となるものは、再バッファイベントと称される。

【0009】

近年、動画配信サイトでは、動画コンテンツのジャンルの多様化が進み、エンターテインメント系だけではなく、ビジネスや教育をテーマに扱った動画コンテンツも増加している。そんな中、視聴時間を短縮して効率的に動画を視聴したいユーザのニーズに応えるため、動画データの再生速度を速める倍速再生に対応する動画配信サイトも増えている。

【0010】

その一方、近年の動画トラフィックの増加に伴い、無駄なトラフィックを抑制して通信帯域を削減するために、ＣＬとＯＳとの間に配置されたデータ中継装置において、動画データの送信ビットレートをコントロールするトラフィック最適化の処理を行う関連技術が知られている（例えば、特許文献１を参照）。

【0011】

トラフィック最適化には、ＡＢＲの動画データの配信に対応するものも存在する。例えば、データ中継装置において、ＣＬに送信するＡＢＲの動画データの送信ビットレートをコントロールすると、ＡＢＲの仕組みにより、その送信ビットレートに合わせた画質がＣＬで選択される。このようにして、ＯＳからＣＬに配信される動画データの画質を変化させる。

【0012】

動画データの画質が高ければデータ量も大きく、動画データの画質が低ければデータ量も小さい。そのため、ＡＢＲの動画データの送信ビットレートをコントロールすることで、動画データの画質をコントロールし、ネットワーク上に流れる動画データのデータ量もコントロールする。

【0013】

図３には、データ中継装置によるＡＢＲの動画データのトラフィック最適化の例を説明するシーケンス図が示されている。
図３に示されるように、ＣＬ１０は、動画データをリクエストするリクエストデータ（画質、セグメント等が指定された、ＨＴＴＰプロトコルを使用したリクエストデータ）をＯＳ２０に送信する（ステップＳ１１）。データ中継装置３０は、ＣＬ１０からのリクエストデータをＯＳ２０に転送する（ステップＳ１２）。

【0014】

ＯＳ２０は、ＣＬ１０からリクエストされた動画データ（指定された画質のセグメント）を、レスポンスデータとして、ＣＬ１０に送信する（ステップＳ１３）。
データ中継装置３０は、ＯＳ２０からの動画データの送信ビットレートをコントロールしつつ、動画データをＣＬ１０に送信する（ステップＳ１４）。例えば、ネットワークが輻輳している場合には、データ中継装置３０からＣＬ１０に送信する動画データの送信ビットレートを下げて、ＡＢＲの仕組みにより、ＣＬ１０に低画質な動画データを選択させる。これにより、ＯＳ２０から配信される動画データのデータ量を減らしてネットワークの輻輳を緩和する。このような送信ビットレートのコントロールは、ペーシング（pacing）、シェーピング（shaping）、又はスロットリング（throttling）と称されるが、以下では、ペーシングと称す。

【0015】

ＣＬ１０は、ＡＢＲの仕組みにより、ステップＳ１４の動画データの送信ビットレートに合わせた画質を選択する。ここでは、ＣＬ１０は、より低い画質（小さいデータ量）を選択したとする。この場合、ＣＬ１０は、より低い画質の動画データをリクエストするリクエストデータをＯＳ２０に送信し（ステップＳ１５）、データ中継装置３０は、ＣＬ１０からのリクエストデータをＯＳ２０に転送する（ステップＳ１６）。

【0016】

ＯＳ２０は、ＣＬ１０からリクエストされた、より低い画質の動画データを、レスポンスデータとして、ＣＬ１０に送信する（ステップＳ１７）。データ中継装置３０は、ＯＳ２０からの、より低い画質の動画データをＣＬ１０に送信する（ステップＳ１８）。これにより、ＯＳ２０からＣＬ１０に配信される動画データの画質は、より低い画質に変化する。

【先行技術文献】

【特許文献】

【0017】

【文献】国際公開第２０１６／１８５９９８号

【発明の概要】

【発明が解決しようとする課題】

【0018】

ところで、図３に示されるようなペーシングの処理においては、動画データのターゲット画質に合わせて送信ビットレートを決定する。
ただし、ＣＬ１０で動画データを倍速再生する場合は、同じ画質でも動画データのダウンロード（download。以下、ＤＬと称す）速度が速くなる。

【0019】

図４には、ペーシング時にデータ中継装置３０からＣＬ１０へ送信される動画データの現状の送信ビットレートの例が示されている。図４において、横軸は時間であり、縦軸は動画データの送信ビットレートである。

【0020】

図４に示されるように、ＣＬ１０で同じ画質で倍速再生されても、データ中継装置３０が同じ送信ビットレート（図中の通常配信レート）でペーシングを行うと仮定する。この場合、動画データの倍速再生時に必要な配信レートに対して、データ中継装置３０からの送信ビットレートは低くなるため、送信ビットレートが不足する。その結果、ＣＬ１０では、ＤＬが追い付かず、動画データの再生停止や画質の低下が発生し、ユーザが体感するＱｏＥ（Quality of Experience）が悪化してしまう。

【0021】

そのため、ＱｏＥの悪化を防止しつつ、トラフィックを最適化するには、データ中継装置３０は、ＣＬ１０で動画データが倍速再生されているか否かを判定し、倍速再生されていれば、ＣＬ１０に送信する動画データの送信ビットレートを変化させる必要がある。

【0022】

図５には、ペーシング時にデータ中継装置３０からＣＬ１０へ送信される動画データの理想的な送信ビットレートの例が示されている。図５において、横軸及び縦軸は図４と同様である。

【0023】

図５に示されるように、データ中継装置３０は、ＣＬ１０で動画データが倍速再生されていることを判定できた場合には、ＣＬ１０に送信する動画データの送信ビットレートを上げる。これにより、ＣＬ１０では、倍速再生にＤＬが追いつけるようになるため、ＱｏＥの悪化を防止しつつ、トラフィックを最適化することが可能となる。

【0024】

しかし、データ中継装置３０では、ＣＬ１０で動画データが倍速再生されているか否かを判定することは困難である。その理由は、近年の動画データは、例えば、ＴＬＳ（Transport Layer Security）により暗号化されており、データ中継装置３０は、動画データの内容（ヘッダ情報のようなメタデータや動画データ自体）を参照することができないためである。現状では、データ中継装置３０が、ＣＬ１０からＯＳ２０に送信されるアップロードデータや、ＯＳ２０からＣＬ１０に送信されるレスポンスデータ（動画データ）について取得できるのは、これらデータのデータサイズや流量（ビットレート）のみである。データ中継装置３０において、これらの限られた情報から倍速再生を判定することは困難である。

【0025】

そこで本開示の目的は、上述した課題を解決し、データ中継装置において、クライアント端末で動画データが倍速再生されているか否かの判定を可能とするデータ中継装置、配信システム、データ中継方法、及びコンピュータ可読媒体を提供することにある。

【課題を解決するための手段】

【0026】

一態様によるデータ中継装置は、
クライアント端末と、動画データを配信する配信サーバと、の間に配置され、前記配信サーバから配信された動画データを前記クライアント端末に送信するデータ中継装置であって、
前記クライアント端末から前記配信サーバに送信されるアップロードデータを受信し、前記アップロードデータのデータサイズに基づいて、前記アップロードデータが所定のアップロードデータであるか否かを判定する第１の判定部と、
前記判定された前記所定のアップロードデータの送信間隔に基づいて、前記クライアント端末で前記動画データの倍速再生が行われているか否かを判定する第２の判定部と、
を備える。

【0027】

一態様による配信システムは、
クライアント端末と、
動画データを配信する配信サーバと、
前記データ中継装置と、
を備える。

【0028】

一態様によるデータ中継方法は、
クライアント端末と、動画データを配信する配信サーバと、の間に配置され、前記配信サーバから配信された動画データを前記クライアント端末に送信するデータ中継装置によるデータ中継方法であって、
前記クライアント端末から前記配信サーバに送信されるアップロードデータを受信する受信ステップと、
前記アップロードデータのデータサイズに基づいて、前記アップロードデータが所定のアップロードデータであるか否かを判定する第１の判定ステップと、
前記判定された前記所定のアップロードデータの送信間隔に基づいて、前記クライアント端末で前記動画データの倍速再生が行われているか否かを判定する第２の判定ステップと、
を含む。

【0029】

一態様によるコンピュータ可読媒体は、
クライアント端末と、動画データを配信する配信サーバと、の間に配置され、前記配信サーバから配信された動画データを前記クライアント端末に送信するコンピュータに、
前記クライアント端末から前記配信サーバに送信されるアップロードデータを受信する受信手順と、
前記アップロードデータのデータサイズに基づいて、前記アップロードデータが所定のアップロードデータであるか否かを判定する第１の判定手順と、
前記判定された前記所定のアップロードデータの送信間隔に基づいて、前記クライアント端末で前記動画データの倍速再生が行われているか否かを判定する第２の判定手順と、
を実行させるためのプログラムが格納された非一時的なコンピュータ可読媒体である。

【発明の効果】

【0030】

上述の態様によれば、データ中継装置において、クライアント端末で動画データが倍速再生されているか否かの判定を可能とするデータ中継装置、配信システム、データ中継方法、及びコンピュータ可読媒体を提供できるという効果が得られる。

【図面の簡単な説明】

【0031】

【図1】ＡＢＲの動画データの画質の時間変化の例を説明する図である。

【図2】ＣＬが、ＯＳから受信したデータ量の時系列変化の例を説明する図である。

【図3】データ中継装置によるＡＢＲの動画データのトラフィック最適化の例を説明するシーケンス図である。

【図4】ペーシング時にデータ中継装置からＣＬへ送信される動画データの現状の送信ビットレートの例を説明する図である。

【図5】ペーシング時にデータ中継装置からＣＬへ送信される動画データの理想的な送信ビットレートの例を説明する図である。

【図6】データ中継装置がＴＣＰ／ＵＤＰの通信を終端する例を説明する図である。

【図7】データ中継装置がＴＣＰ／ＵＤＰの通信を終端しない例を説明する図である。

【図8】ＣＬとＯＳとの間の動画データの送受信時のシーケンスの例を説明するシーケンス図である。

【図9】ＡＢＲの動画データのプロトコルスタックの例を説明する図である。

【図10】ＣＬで同じ画質の同じ動画データを異なる再生速度で再生している場合における、ＣＬからのリクエストデータを観察したグラフの例を説明する図である。

【図11】ＣＬで同じ画質の同じ動画データを異なる再生速度で再生している場合における、ＣＬからのリクエストデータを観察したグラフの例を説明する図である。

【図12】ＣＬで同じ画質の同じ動画データを異なる再生速度で再生している場合における、ＣＬからのリクエストデータを観察したグラフの例を説明する図である。

【図13】実施の形態１に係るデータ中継装置の構成例を示すブロック図である。

【図14】実施の形態１に係るデータ中継装置の動作例を説明する図である。

【図15】実施の形態１に係るデータ中継装置の動作例を説明するフロー図である。

【図16】実施の形態２に係るデータ中継装置の構成例を示すブロック図である。

【図17】実施の形態３に係るデータ中継装置のハードウェア構成例を示すブロック図である。

【発明を実施するための形態】

【0032】

以下、図面を参照して本開示の概要及び実施の形態について説明する。なお、以下の記載及び図面は、説明の明確化のため、適宜、省略及び簡略化がなされている。また、以下の各図面において、同一の要素には同一の符号が付されており、必要に応じて重複説明は省略されている。

【0033】

本開示の実施の形態を説明する前に、本開示の概要について説明する。
＜本開示の概要＞
本開示においては、本開示に係るデータ中継装置３０Ａが、ＣＬ１０からＯＳ２０へ送信されるアップロードデータのデータサイズ及び送信間隔を分析することで、ＣＬ１０でＡＢＲの動画データの倍速再生が行われているか否かを判定する手法を提案する。ここで、アップロードデータのデータサイズ及び送信間隔は、データ中継装置３０Ａでも取得可能な情報である。

【0034】

本提案手法は、データ中継装置３０Ａでも取得可能な情報から倍速再生を判定するため、ＡＢＲの動画データの暗号化／非暗号化に関わらず有効である。また、本提案手法は、動画プロトコルとしては、ＴＣＰ（Transmission Control Protocol）だけでなく、ＵＤＰ（User Datagram Protocol）（ＱＵＩＣ（Quick UDP Internet Connections）等）でも有効である。また、本提案手法は、データ中継装置３０ＡによりＴＣＰ／ＵＤＰの通信が終端されている／されていないに関わらず有効である。

【0035】

図６には、データ中継装置３０ＡがＴＣＰ／ＵＤＰの通信を終端している場合のイメージ例が示されている。
図６に示されるように、データ中継装置３０ＡがＴＣＰ／ＵＤＰの通信を終端している場合、ＣＬ１０とデータ中継装置３０Ａとの間、及び、データ中継装置３０ＡとＯＳ２０との間では、別々のＴＣＰセッションで通信が行われる。すなわち、データ中継装置３０Ａは、ＣＬ１０及びＯＳ２０と通信する際、それぞれにＴＣＰセッションを生成する。

【0036】

一方、図７には、データ中継装置３０ＡがＴＣＰ／ＵＤＰの通信を終端していない場合のイメージ例が示されている。
図７に示されるように、データ中継装置３０ＡがＴＣＰ／ＵＤＰの通信を終端していない場合、ＣＬ１０は、ＯＳ２０との間では直接のＴＣＰセッションでデータをやり取りし、データ中継装置３０Ａは、データを転送するのみである。すなわち、ＣＬ１０及びＯＳ２０が１つのＴＣＰセッションで直接通信を行い、データ中継装置３０Ａはデータを転送する。

【0037】

以下、本提案手法について説明する。
ＡＢＲの動画データの再生中に、ＣＬ１０からＯＳ２０に送信されるアップロードデータは、大きく２種類に分けられる。１つは、動画データをリクエストするリクエストデータ（ＨＴＴＰリクエストパケット）であり、もう１つは、動画データを受信したことを通知する確認応答データ（ＡＣＫ（ACKnowledgement）パケット）である。

【0038】

図８には、ＣＬ１０とＯＳ２０との間の動画データの送受信時のシーケンスが示されている。
図８に示されるように、まず、ＣＬ１０とＯＳ２０との間で、データ中継装置３０Ａを経由するセッションを確立する（ステップＳ２１）。

【0039】

次に、ＣＬ１０は、取得したい動画データをリクエストするリクエストデータ（ＨＴＴＰリクエストパケット）をＯＳ２０に送信する（ステップＳ２２）。次に、データ中継装置３０Ａは、ＣＬ１０からのリクエストデータをＯＳ２０に転送する（ステップＳ２３）。

【0040】

ＯＳ２０は、ＣＬ１０からデータ中継装置３０Ａ経由でリクエストデータを受信すると、そのリクエストデータに対するレスポンスデータ（ＨＴＴＰレスポンス）として、ＣＬ１０からリクエストされた動画データをＣＬ１０に送信する（ステップＳ２４）。次に、データ中継装置３０Ａは、ＯＳ２０からの動画データをＣＬ１０に転送する（ステップＳ２５）。

【0041】

ＣＬ１０は、ＯＳ２０からデータ中継装置３０Ａ経由で動画データを受信すると、その動画データを受信したことを通知するために、確認応答データ（ＡＣＫパケット）をＯＳ２０に送信する（ステップＳ２６）。次に、データ中継装置３０Ａは、ＣＬ１０からの確認応答データをＯＳ２０に転送する（ステップＳ２７）。
以降、セッションが切断されるまで、ステップＳ２４～Ｓ２７と同様のステップＳ２８～Ｓ３１が継続して行われる。

【0042】

図８に示されるように、ＯＳ２０は、ＣＬ１０からデータ中継装置３０Ａ経由で確認応答データを受信することで、動画データをＣＬ１０に送信できたことを確認する。この動作は、ＴＣＰ通信の信頼性確保ための動作である。この動作は、ＴＣＰ／ＩＰ（Internet Protocol）による通信だけでなく、近年増加傾向にあるＵＤＰ／ＩＰのプロトコルスタック上で動作するＱＵＩＣトラフィックでも行われる。

【0043】

図９には、ＡＢＲの動画データのプロトコルスタックの例が示されている。
図９に示されるように、ＱＵＩＣプロトコルは、ＴＣＰでなく、ＵＤＰを使用する。ただし、ＱＵＩＣプロトコルは、通信の信頼性を確保するために、ＴＣＰの機能に相当する再送制御、輻輳制御、ロスリカバリー等の機能を提供しており、ＴＣＰと同様に、確認応答データ（ＡＣＫパケット）が送信される。

【0044】

ＡＢＲの代表的規格（ＨＳＬやＭＰＥＧ－ＤＡＳＨ等）では、ＨＴＴＰプロトコルで動画の取得及び配信を制御する。ＡＢＲによるリクエストデータ（ＨＴＴＰリクエストパケット）のデータサイズは比較的大きくなる。ただし、ＴＣＰやＱＵＩＣプロトコルにおける確認応答データ（ＡＣＫパケット）のデータサイズは、リクエストデータ（ＨＴＴＰリクエストパケット）に比べて小さい。

【0045】

そのため、リクエストデータ（ＨＴＴＰリクエストパケット）と確認応答データ（ＡＣＫパケット）とは、そのデータサイズによって見分けることが可能である。
ＡＢＲの動画データの場合、リクエストデータには、取得する動画データの画質やセグメント等の情報が含まれている。そのため、１つのリクエストデータのデータサイズは少なくとも数百バイト以上になる。
一方、確認応答データは、複雑な情報は含まれず、そのデータサイズは、リクエストデータよりも十分小さくなる（１００バイト程度）。

【0046】

そこで本開示に係るデータ中継装置３０Ａは、ＣＬ１０からＯＳ２０に送信されるアップロードデータのデータサイズによって、そのアップロードデータが、リクエストデータであるか、又は、確認応答データであるかを判定する。なお、この手法は、アップロードデータの暗号化／非暗号化に関わらず、適用可能である。

【0047】

データ中継装置３０Ａは、上述した手法により、リクエストデータを判定した上で、そのリクエストデータがＣＬ１０からＯＳ２０に送信される送信間隔によって、ＣＬ１０で倍速再生が行われているか否かを判定する。

【0048】

図１０～図１２には、ＣＬ１０で同じ画質の同じ動画データを異なる再生速度で再生している場合における、ＣＬ１０からのリクエストデータを観察したグラフが示されている。図１０～図１２において、横軸は時間であり、縦軸はリクエストデータのデータサイズである。また、図１０は、１倍速での再生時のリクエストデータを示し、図１１は、１．５倍速での再生時のリクエストデータを示し、図１２は、２倍速での再生時のリクエストデータを示している。

【0049】

図１０～図１２に示されるように、ＣＬ１０からのリクエストデータの送信間隔は、１倍速での再生時に最も長くなり（図１０）、２倍速での再生時に最も短くなっている（図１２）。このことから、倍速の再生速度が大きいほど、リクエストデータが短い間隔でＣＬ１０から送信されていることがわかる。

【0050】

そのため、データ中継装置３０Ａは、ＣＬ１０からのリクエストデータの送信間隔に基づいて、ＣＬ１０で倍速再生が行われているか否かを判定する。

【0051】

以下、本開示の実施の形態について説明する。
＜実施の形態１＞
図１３には、本実施の形態１に係るデータ中継装置３０Ａの構成例が示されている。
図１３に示されるように、本実施の形態１に係るデータ中継装置３０Ａは、ＣＬ（Client）１０と、ＯＳ（Origin Server）２０と、の間に配置される。図１３に示される、ＣＬ１０、ＯＳ２０、及びデータ中継装置３０Ａによって配信システムが構成される。

【0052】

ＣＬ１０とデータ中継装置３０Ａとの間、及び、データ中継装置３０ＡとＯＳ２０との間は、それぞれ異なるネットワークで接続される。典型的には、ＣＬ１０とデータ中継装置３０Ａとの間は無線網で接続され、データ中継装置３０ＡとＯＳ２０との間は有線網で接続される。ただし、ネットワークの組み合わせは、これに限定されず、それ以外の組合せであっても良い。

【0053】

ＣＬ１０は、ＯＳ２０に対して動画データの送信をリクエストし、そのリクエストに対するレスポンスとして配信される動画データを受信するクライアント端末である。ＣＬ１０の具体例としては、スマートフォンを含む携帯電話機、タブレット端末、パーソナルコンピュータ、及びネットワーク接続機能付きテレビ等が挙げられる。
ＯＳ２０は、ＣＬ１０からのリクエストに対するレスポンスとして、動画データを配信する配信サーバである。

【0054】

本実施の形態１に係るデータ中継装置３０Ａは、ＣＬ１０とＯＳ２０間の通信を中継すると共に、トラッフィク最適化処理を適用する装置である。
本実施の形態１に係るデータ中継装置３０Ａは、通信処理部３０１と、ＡＢＲ動画判定部３０２と、倍速再生判定部３０３と、判定閾値データベース３０４と、最適化適用部３０５と、最適化ポリシーデータベース３０６と、を備えている。

【0055】

通信処理部３０１は、データ中継装置３０Ａ内で通信の中継を担う。データ中継装置３０ＡがＴＣＰ／ＵＤＰの通信を終端する場合は、通信処理部３０１は、ＯＳ２０に対するプロキシ（代理サーバ）として動作するアプリケーションに相当する。

【0056】

ＡＢＲ動画判定部３０２は、ＣＬ１０からのアップロードデータやＯＳ２０からのレスポンスデータに基づいて、ＣＬ１０とＯＳ２０との間で行われている通信が、ＡＢＲの動画データの配信に係る通信であるか否かを判定する。例えば、ＡＢＲ動画判定部３０２は、ヘッダ情報に含まれるＩＰアドレスの情報や、データサイズの情報等に基づいて、ＡＢＲの動画データの配信に係る通信であるか否かを判定する。ただし、判定方法はこれに限定されない。

【0057】

倍速再生判定部３０３は、ＣＬ１０からＯＳ２０へ送信されるアップロードデータを観測し、アップロードデータのデータサイズ及び送信間隔に基づいて、ＣＬ１０で動画データの倍速再生が行われているか否かを判定する。具体的には、倍速再生判定部３０３は、アップロードデータのデータサイズに基づいて、アップロードデータがリクエストデータであるか否かを判定し、さらに、リクエストデータの送信間隔に基づいて、倍速再生が行われているか否かを判定する。

【0058】

倍速再生判定部３０３の動作の詳細は以下の通りである。
すなわち、倍速再生判定部３０３は、ＡＢＲ動画判定部３０２により、ＡＢＲの動画データの配信に係る通信であると判定された通信を観察する。そして、倍速再生判定部３０３は、ＣＬ１０からＯＳ２０へ送信されるアップロードデータのデータサイズに基づいて、アップロードデータがリクエストデータであるか否かを判定する。

【0059】

また、倍速再生時のＣＬ１０からのリクエストデータの送信間隔は、ＯＳ２０毎に異なる。そのため、倍速再生判定部３０３は、判定閾値データベース３０４に対して、ＯＳ２０の情報をキー情報として渡して、そのＯＳ２０について、倍速再生を判定するためのリクエストデータの送信間隔の閾値を取得する。そして、倍速再生判定部３０３は、ＣＬ１０からのリクエストデータの送信間隔を、判定閾値データベース３０４から取得した閾値と比較することで、ＣＬ１０で倍速再生が行われているか否かを判定し、さらに、倍速再生が行われていると判定した場合には、倍速再生の再生速度も判定する。なお、倍速再生判定部３０３は、判定閾値データベース３０４からは、ＯＳ２０について、複数の閾値を取得し、ＣＬ１０からのリクエストデータの送信間隔が、複数の閾値によって区分される複数の範囲のうちのどの範囲に属するかで、ＣＬ１０で倍速再生が行われているか否かの判定や、再生速度の判定を行っても良い。

【0060】

倍速再生判定部３０３は、ＣＬ１０で倍速再生が行われていると判定した場合、倍速再生の再生速度を最適化適用部３０５に通知する。

【0061】

上述したように、倍速再生時のＣＬ１０からのリクエストデータの送信間隔は、ＯＳ２０毎に異なる。そのため、判定閾値データベース３０４は、ＯＳ２０毎に、倍速再生を判定するためのリクエストデータの送信間隔の閾値を保存しておく。判定閾値データベース３０４は、倍速再生判定部３０３からの問い合わせを受けた時に、ＯＳ２０の情報をキー情報として受け取り、そのＯＳ２０についての閾値を返却する。なお、判定閾値データベース３０４は、ＯＳ２０毎に複数の閾値を保存しておき、倍速再生判定部３０３からの問い合わせに対して、ＯＳ２０についての複数の閾値を返却しても良い。

【0062】

最適化適用部３０５は、ＯＳ２０からのレスポンスデータである動画データを通信処理部３０１から受け取り、その動画データに対して、送信ビットレートをコントロールするトラフィック最適化処理を実施する。

【0063】

最適化適用部３０５の動作の詳細は以下の通りである。
すなわち、最適化適用部３０５は、最適化ポリシーデータベース３０６に対して、ＣＬ１０とＯＳ２０との間で行われている通信の情報（ＣＬ１０やＯＳ２０のＩＰアドレス等）をキー情報として渡して、その通信に対して適用する最適化ポリシーを問い合わせる。また、最適化適用部３０５は、倍速再生判定部３０３から倍速再生の再生速度の通知を受けている場合は、最適化ポリシーデータベース３０６に対して、上述した通信の情報と共に倍速再生の再生速度の情報をキー情報として渡して、最適化ポリシーを問い合わせる。

【0064】

最適化適用部３０５は、最適化ポリシーデータベース３０６から、問い合わせの結果として、最適化ポリシーを取得する。この最適化ポリシーには、ＡＢＲの動画データの送信ビットレートの情報も含まれる。最適化適用部３０５は、最適化ポリシーデータベース３０６から取得した最適化ポリシーに基づいて、動画データのトラフィック最適化処理を実施する。

【0065】

最適化ポリシーデータベース３０６は、最適化適用部３０５からの、ＣＬ１０とＯＳ２０との間で行われている通信の情報（ＣＬ１０やＯＳ２０のＩＰアドレス等）を含む問い合わせに対して、その通信に適用する最適化ポリシーを決定し、決定した最適化ポリシーを最適化適用部３０５に返却する。また、最適化適用部３０５が倍速再生判定部３０３から倍速再生の再生速度の通知を受けている場合は、最適化ポリシーデータベース３０６は、最適化適用部３０５からの、上述した通信の情報と倍速再生の再生速度とを含む問い合わせに対して、その通信に適用する最適化ポリシーを決定し、決定した最適化ポリシーを最適化適用部３０５に返却する。

【0066】

図１４及び図１５には、本実施の形態１に係るデータ中継装置３０Ａの動作例を説明する図が示されている。なお、図１４及び図１５において、同じステップには、同じ符号が付されている。

【0067】

図１４及び図１５に示されるように、通信処理部３０１は、ＣＬ１０から、動画データのリクエストデータ（ＨＴＴＰリクエストパケット）を受信すると（ステップＳ４１）、ＣＬ１０とＯＳ２０との間で行われている通信の情報（ＣＬ１０やＯＳ２０のＩＰアドレス等）をＡＢＲ動画判定部３０２に渡す（ステップＳ４２）。

【0068】

ＡＢＲ動画判定部３０２は、通信処理部３０１から受け取った通信の情報に基づいて、ＣＬ１０とＯＳ２０との間で行われている通信が、ＡＢＲの動画データの配信に係る通信であるか否かを判定する（ステップＳ４３）。例えば、ＡＢＲ動画判定部３０２は、リクエストデータのヘッダ情報に含まれる宛先ＩＰアドレスに基づいて、リクエストデータの宛先がＯＳであることを特定した場合に、ＡＢＲの動画データの配信に係る通信であると判定しても良い。さらに、ＡＢＲ動画判定部３０２は、ＡＢＲの動画データの配信に係る通信であると判定した場合、ＯＳ２０からＣＬ１０に送信されるレスポンスデータ（動画データ）を、トラフィック最適化の実施対象と判定する。

【0069】

なお、ＡＢＲ動画判定部３０２は、ＣＬ１０からのアップロードデータだけでなく、後述するステップＳ４８でＯＳ２０からのレスポンスデータ（動画データ）を受信した際にも、同様の判定を行っても良い。例えば、ＡＢＲ動画判定部３０２は、レスポンスデータのヘッダ情報に含まれる送信元ＩＰアドレスに基づいて、レスポンスデータの送信元がＯＳであることを特定した場合に、ＡＢＲの動画データの配信に係る通信であると判定しても良い。

【0070】

ＡＢＲ動画判定部３０２は、ＣＬ１０とＯＳ２０との間で行われている通信が、ＡＢＲの動画データの配信に係る通信であるか否かの判定結果を通信処理部３０１に返却する（ステップＳ４３）。また、ＡＢＲ動画判定部３０２は、ＡＢＲの動画データの配信に係る通信であると判定した場合、ＯＳ２０からＣＬ１０に送信されるレスポンスデータ（動画データ）が、トラフィック最適化の実施対象であることも、通信処理部３０１に通知する。

【0071】

ここで、ＡＢＲ動画判定部３０２により、通信が、ＡＢＲの動画データの配信に係る通信であると判定されている場合、通信処理部３０１は、倍速再生判定部３０３を動作させる（ステップＳ４４）。

【0072】

倍速再生判定部３０３は、判定閾値データベース３０４に対して、ＯＳ２０の情報をキー情報として渡して、そのＯＳ２０について、倍速再生を判定するためのリクエストデータの送信間隔の閾値を取得する（ステップＳ４５）。

【0073】

また、倍速再生判定部３０３は、ＡＢＲ動画判定部３０２により、ＡＢＲの動画データの配信に係る通信であると判定された通信を観察し、アップロードデータのデータサイズに基づいて、アップロードデータがリクエストデータであるか否かを判定する。倍速再生判定部３０３は、リクエストデータであると判定した場合には、リクエストデータの送信間隔を、ステップＳ４５で判定閾値データベース３０４から取得した閾値と比較することで、ＣＬ１０で倍速再生が行われているか否かを判定し、さらに、倍速再生が行われていると判定した場合には、倍速再生の再生速度も判定する。

【0074】

倍速再生判定部３０３は、ＣＬ１０で倍速再生が行われていと判定した場合には、倍速再生の再生速度を最適化適用部３０５に通知する（ステップＳ４６）。

【0075】

通信処理部３０１は、ＣＬ１０からのリクエストデータをＯＳ２０に転送する（ステップＳ４７）。
なお、ＡＢＲ動画判定部３０２により、通信が、ＡＢＲの動画データの配信に係る通信でないと判定されている場合、通信処理部３０１は、倍速再生判定部３０３を動作させることなく、ＣＬ１０からのリクエストデータをＯＳ２０に転送する（ステップＳ４７）。

【0076】

通信処理部３０１は、ＯＳ２０から、ＣＬ１０のリクエストデータに応じたレスポンスデータ（動画データ）を受信する（ステップＳ４８）。

【0077】

ここで、ＡＢＲ動画判定部３０２により、ＯＳ２０からのレスポンスデータ（動画データ）がトラフィック最適化の実施対象であると判定されている場合、通信処理部３０１は、レスポンスデータ（動画データ）を最適化適用部３０５に渡す（ステップＳ４９）。

【0078】

最適化適用部３０５は、最適化ポリシーデータベース３０６に対して、ＣＬ１０とＯＳ２０との間で行われている通信の情報（ＣＬ１０やＯＳ２０のＩＰアドレス等）をキー情報として渡して、その通信に対して適用する最適化ポリシーを問い合わせる。また、最適化適用部３０５は、倍速再生判定部３０３から倍速再生の再生速度の通知を受けている場合は、最適化ポリシーデータベース３０６に対して、上述した通信の情報と共に倍速再生の再生速度の情報をキー情報として渡して、最適化ポリシーを問い合わせる。

【0079】

最適化ポリシーデータベース３０６は、最適化適用部３０５からの問い合わせに対して、ＣＬ１０とＯＳ２０との間で行われている通信に適用する最適化ポリシーを決定し、決定した最適化ポリシーを最適化適用部３０５に返却する（ステップＳ５０）。この最適化ポリシーには、レスポンスデータ（動画データ）の送信ビットレートの情報も含まれる。

【0080】

最適化適用部３０５は、最適化ポリシーデータベース３０６から取得した最適化ポリシーに基づいて、レスポンスデータ（動画データ）に対し、送信ビットレートをコントロールするトラフィック最適化処理を実施し、トラフィック最適化処理を実施した動画データを通信処理部３０１に返却する（ステップＳ５１）。

【0081】

通信処理部３０１は、最適化適用部３０５から返却された動画データをＣＬ１０に送信する（ステップＳ５２）。
なお、ＡＢＲ動画判定部３０２により、ＯＳ２０からのレスポンスデータ（動画データ）がトラフィック最適化の実施対象でないと判定されている場合、通信処理部３０１は、レスポンスデータ（動画データ）を、最適化適用部３０５に渡すことなく、そのままＣＬ１０に送信する（ステップＳ５２）。

【0082】

ステップＳ４１～Ｓ５２を繰り返している間に、ステップＳ４４，Ｓ４５において、ＣＬ１０で倍速再生が行われていると判定された場合、倍速再生判定部３０３は、倍速再生の再生速度を最適化適用部３０５に通知する（ステップＳ４６）。これを受けて、最適化適用部３０５は、倍速再生時の最適化ポリシーに基づいて、トラフィック最適化処理を実施する（ステップＳ５０）。

【0083】

本実施の形態１によれば、データ中継装置３０Ａは、ＣＬ１０からＯＳ２０へ送信されるアップロードデータのデータサイズに基づいて、そのアップロードデータがリクエストデータであるか否かを判定し、さらに、リクエストデータの送信間隔に基づいて、ＣＬ１０で動画データの倍速再生が行われているか否かを判定する。

【0084】

ここで、アップロードデータのデータサイズや送信間隔は、データ中継装置３０Ａでも取得可能な情報である。そのため、データ中継装置３０Ａは、データ中継装置３０Ａで取得可能な情報から、ＣＬ１０で動画データの倍速再生が行われているか否かを判定可能である。

【0085】

また、データ中継装置３０Ａは、倍速再生の判定が可能となるため、ＣＬ１０で動画データの倍速再生が行われていると判定したら、例えば、図５に示されるように、ＣＬ１０に送信する動画データの送信ビットレートを上げる、といったトラフィック最適化処理を実施可能となる。これにより、ＣＬ１０で動画データの倍速再生中のＱｏＥの悪化を防止しつつ、トラフィックを最適化することが可能となる。

【0086】

＜実施の形態２＞
図１６には、本実施の形態２に係るデータ中継装置３０Ｂの構成例が示されている。なお、本実施の形態２は、上述した実施の形態１を上位概念化した実施形態に相当する。

【0087】

図１６に示されるように、本実施の形態２に係るデータ中継装置３０Ｂは、ＣＬ（クライアント端末）１０と、動画データを配信するＯＳ（配信サーバ）２０と、の間に配置され、ＯＳ２０から配信された動画データをＣＬ１０に送信する装置である。

【0088】

本実施の形態２に係るデータ中継装置３０Ｂは、第１の判定部３１１と、第２の判定部３１２と、を備えている。第１の判定部３１１及び第２の判定部３１２は、上述した実施の形態１に係る通信処理部３０１及び倍速再生判定部３０３を組み合わせたものに相当する。

【0089】

第１の判定部３１１は、ＣＬ１０からＯＳ２０に送信されるアップロードデータを受信し、そのアップロードデータのデータサイズに基づいて、そのアップロードデータが所定のアップロードデータであるか否かを判定する。

【0090】

第２の判定部３１２は、第１の判定部３１１で判定された所定のアップロードデータの送信間隔に基づいて、ＣＬ１０で動画データの倍速再生が行われているか否かを判定する。

【0091】

本実施の形態２によれば、データ中継装置３０Ｂは、ＣＬ１０からＯＳ２０へ送信されるアップロードデータのデータサイズに基づいて、そのアップロードデータが所定のアップロードデータであるか否かを判定し、さらに、その判定された所定のアップロードデータの送信間隔に基づいて、ＣＬ１０で動画データの倍速再生が行われているか否かを判定する。

【0092】

ここで、アップロードデータのデータサイズや送信間隔は、データ中継装置３０Ｂでも取得可能な情報である。そのため、データ中継装置３０Ｂは、データ中継装置３０Ｂで取得可能な情報から、ＣＬ１０で動画データの倍速再生が行われているか否かを判定可能である。

【0093】

なお、本実施の形態２に係るデータ中継装置３０Ｂは、第２の判定部３１２による倍速再生の判定結果に基づいて、ＣＬ１０に送信する動画データの送信ビットレートをコントロールする制御部をさらに備えていても良い。この制御部は、上述した実施の形態１に係る通信処理部３０１及び最適化適用部３０５を組み合わせたものに相当する。

【0094】

また、第１の判定部３１１は、ＣＬ１０からＯＳ２０に送信されるアップロードデータのデータサイズに基づいて、そのアップロードデータが、動画データをリクエストするリクエストデータであるか、又は、動画データを受信したことを通知する確認応答データであるかを判定しても良い。また、所定のアップロードデータは、リクエストデータであっても良い。

【0095】

また、第２の判定部３１２は、ＣＬ１０で動画データの倍速再生が行われていると判定した場合は、リクエストデータの送信間隔に基づいて、ＣＬ１０で行われている倍速再生の再生速度をさらに判定しても良い。
また、制御部は、第２の判定部３１２による倍速再生の再生速度の判定結果に基づいて、ＣＬ１０に送信する動画データの送信ビットレートをコントロールしても良い。

【0096】

＜実施の形態３＞
図１７には、本実施の形態３に係るデータ中継装置３０Ｃのハードウェア構成例が示されている。
図１７に示されるように、本実施の形態３に係るデータ中継装置３０Ｃは、プロセッサ３２１と、メモリ３２２と、を備えている。

【0097】

プロセッサ３２１は、例えば、マイクロプロセッサ、ＭＰＵ（Micro Processing Unit）、又はＣＰＵ（Central Processing Unit）であっても良い。プロセッサ３２１は、複数のプロセッサを含んでも良い。

【0098】

メモリ３２２は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ３２２は、プロセッサ３２１から離れて配置されたストレージを含んでも良い。この場合、プロセッサ３２１は、図示されていないＩ（Input）／Ｏ（Output）インタフェースを介してメモリ３２２にアクセスしても良い。

【0099】

上述した実施の形態１，２に係るデータ中継装置３０Ａ，３０Ｂは、図１７に示されるハードウェア構成を有することができる。メモリ３２２には、プログラムが記憶される。このプログラムは、コンピュータに読み込まれた場合に、上述した実施の形態１，２で説明されたデータ中継装置３０Ａ，３０Ｂの１又はそれ以上の機能をコンピュータに行わせるための命令群（又はソフトウェアコード）を含む。上述したデータ中継装置３０Ａ，３０Ｂにおける、通信処理部３０１、ＡＢＲ動画判定部３０２、倍速再生判定部３０３、最適化適用部３０５、第１の判定部３１１、及び第２の判定部３１２は、プロセッサ３２１がメモリ３２２に記憶されたプログラムを読み込んで実行することにより実現されても良い。また、上述したデータ中継装置３０Ａにおける、判定閾値データベース３０４及び最適化ポリシーデータベース３０６は、メモリ３２２により実現されても良い。

【0100】

また、上述したプログラムは、非一時的なコンピュータ可読媒体又は実体のある記憶媒体に格納されても良い。限定ではなく例として、コンピュータ可読媒体又は実体のある記憶媒体は、random-access memory（RAM）、read-only memory（ROM）、フラッシュメモリ、solid-state drive（SSD）又はその他のメモリ技術、CD-ROM、digital versatile disc（DVD）、Blu-ray（登録商標）ディスク又はその他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ又はその他の磁気ストレージデバイスを含む。プログラムは、一時的なコンピュータ可読媒体又は通信媒体上で送信されても良い。限定ではなく例として、一時的なコンピュータ可読媒体又は通信媒体は、電気的、光学的、音響的、又はその他の形式の伝搬信号を含む。

【0101】

以上、実施の形態を参照して本開示を説明したが、本開示は上述した実施の形態に限定されるものではない。本開示の構成や詳細には、本開示のスコープ内で当業者が理解し得る様々な変更をすることができる。

【0102】

また、以上の説明により、本開示の産業上利用可能性は明らかであるが、本開示は、例えば、移動体通信（セルラネットワーク）において、ＣＬとＯＳの間のＴＣＰ／ＵＤＰ通信を対象とした通信流量制御に利用可能である。

【0103】

また、本開示は、セルラネットワークの代わりに、無線ＬＡＮ（Local Area Network）、有線ＬＡＮ、光ファイバ等の各種アクセス網を通したＴＣＰ／ＵＤＰ通信を対象とした通信流量制御にも利用可能である。

【符号の説明】

【0104】

１０ ＣＬ（クライアント端末）
２０ ＯＳ（配信サーバ）
３０，３０Ａ，３０Ｂ，３０Ｃ データ中継装置
３０１ 通信処理部
３０２ ＡＢＲ動画判定部
３０３ 倍速再生判定部
３０４ 判定閾値データベース
３０５ 最適化適用部
３０６ 最適化ポリシーデータベース
３１１ 第１の判定部
３１２ 第２の判定部
３２１ プロセッサ
３２２ メモリ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】