(57)【要約】  ネットワーク環境の劣化が突発的に発生する状況下においても、利用者のＱｏＥを維持するデータ通信装置を提供する。データ通信装置は、送受信部と、第１の判定部と、第２の判定部と、方式決定部と、を備える。送受信部は、端末及びサーバとの間でデータを送受信する。第１の判定部は、サーバから端末へのデータ送信がＡＢＲ配信方式によるものか否かを判定する。第２の判定部は、サーバから端末へのデータ送信がＡＢＲ配信方式である場合に、サーバからの受信データがＡＢＲ配信方式の規則性を維持しているか否かを判定する。方式決定部は、第２の判定部による判定結果に応じて、サーバからの受信データを端末に転送する際のデータ転送方式を決定する。送受信部は、方式決定部により決定されたデータ転送方式によりサーバからの受信データを端末に転送する。
2019070017.tif 000002
【特許請求の範囲】
【請求項１】
端末及びサーバとの間でデータを送受信する送受信部と、
前記サーバから前記端末へのデータ送信がＡＢＲ（Adaptive Bit Rate）配信方式によるものか否かを判定する、第１の判定部と、
前記サーバから前記端末へのデータ送信がＡＢＲ配信方式である場合に、前記サーバからの受信データがＡＢＲ配信方式の規則性を維持しているか否かを判定する、第２の判定部と、
前記第２の判定部による判定結果に応じて、前記サーバからの受信データを前記端末に転送する際のデータ転送方式を決定する、方式決定部と、
を備え、
前記送受信部は、前記方式決定部により決定されたデータ転送方式により前記サーバからの受信データを前記端末に転送する、データ通信装置。
【請求項２】
前記方式決定部は、前記第２の判定部による判定結果が、ＡＢＲ配信方式の規則性ありの場合には、ＡＢＲ配信方式に適した帯域制限を行って前記サーバからの受信データを前記端末に転送するように前記送受信部に指示する、請求項１のデータ通信装置。
【請求項３】
前記方式決定部は、前記第２の判定部による判定結果が、ＡＢＲ配信方式の規則性なしの場合には、前記帯域制限を解除して前記サーバからの受信データを前記端末に転送するように前記送受信部に指示する、請求項２のデータ通信装置。
【請求項４】
前記第２の判定部は、
所定の測定単位区間ごとに前記サーバからの受信データに関するデータ量を測定し、前記測定されたデータ量が所定の閾値よりも大きい前記測定単位区間が続く区間をデータ通信区間として算出し、前記測定されたデータ量が前記所定の閾値以下の前記測定単位区間が続く区間を無通信区間として算出すると共に、前記データ通信区間と前記無通信区間を１つのサイクルとし、
ＡＢＲ配信方式により送信された受信データが有する、前記サイクルの長さに関する特徴と前記データ通信区間におけるデータ量に関する特徴に基づき、前記ＡＢＲ配信方式の規則性に関する有無を判定する、請求項１乃至３のいずれか一項に記載のデータ通信装置。
【請求項５】
前記第２の判定部は、
第１のサイクルと前記第１のサイクルに続く第２のサイクルにおけるデータ量の変化率が第１の上限値よりも小さく、且つ、前記第１のサイクルの長さに対する第２のサイクルの長さに関する変化率が第２の上限値よりも小さい場合に、ＡＢＲ配信方式の規則性は維持されていると判定する、請求項４のデータ通信装置。
【請求項６】
前記送受信部は、前記サーバに対するプロキシとして動作する、請求項１乃至５のいずれか一項に記載のデータ通信装置。
【請求項７】
前記第２の判定部は、同一セッションのデータを対象として、受信データがＡＢＲ配信方式の規則性を維持しているか否かを判定する、請求項１乃至６のいずれか一項に記載のデータ通信装置。
【請求項８】
端末と、
サーバと、
前記端末と前記サーバの間の通信を中継する、データ通信装置と、
を含み、
前記データ通信装置は、
前記端末と前記サーバとの間でデータを送受信する送受信部と、
前記サーバから前記端末へのデータ送信がＡＢＲ（Adaptive Bit Rate）配信方式によるものか否かを判定する、第１の判定部と、
前記サーバから前記端末へのデータ送信がＡＢＲ配信方式である場合に、前記サーバからの受信データがＡＢＲ配信方式の規則性を維持しているか否かを判定する、第２の判定部と、
前記第２の判定部による判定結果に応じて、前記サーバからの受信データを前記端末に転送する際のデータ転送方式を決定する、方式決定部と、
を備え、
前記送受信部は、前記方式決定部により決定されたデータ転送方式により前記サーバからの受信データを前記端末に転送する、通信システム。
【請求項９】
端末及びサーバとの間でデータを送受信する送受信部を備えるデータ通信装置において、
前記サーバから前記端末へのデータ送信がＡＢＲ（Adaptive Bit Rate）配信方式によるものか否かを判定するステップと、
前記サーバから前記端末へのデータ送信がＡＢＲ配信方式である場合に、前記サーバからの受信データがＡＢＲ配信方式の規則性を維持しているか否かを判定するステップと、
受信データがＡＢＲ配信方式の規則性を維持しているか否かの判定結果に応じて、前記サーバからの受信データを前記端末に転送する際のデータ転送方式を決定するステップと、
前記決定されたデータ転送方式により前記サーバからの受信データを前記端末に転送するステップと、
を含むデータ通信方法。
【請求項１０】
端末及びサーバとの間でデータを送受信する送受信部を備えるデータ通信装置に搭載されたコンピュータに、
前記サーバから前記端末へのデータ送信がＡＢＲ（Adaptive Bit Rate）配信方式によるものか否かを判定する処理と、
前記サーバから前記端末へのデータ送信がＡＢＲ配信方式である場合に、前記サーバからの受信データがＡＢＲ配信方式の規則性を維持しているか否かを判定する処理と、
受信データがＡＢＲ配信方式の規則性を維持しているか否かの判定結果に応じて、前記サーバからの受信データを前記端末に転送する際のデータ転送方式を決定する処理と、
前記決定されたデータ転送方式により前記サーバからの受信データを前記端末に転送する処理と、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願についての記載）
本発明は、日本国特許出願：特願２０１７−１９５６６０号（２０１７年１０月  ６日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、データ通信装置、通信システム、データ通信方法及びプログラムに関する。
【背景技術】
【０００２】
特許文献１には、利用者のＱｏＥ（Quality of Experience）を維持するための技術が開示されている。特許文献１に開示された技術は、利用者が使用する移動機（クライアント、端末）のバッファを動画像視聴開始時に迅速に満たすことで動画像を円滑に視聴開始させることを目的としている。当該文献には、セッションの１回目のデータ転送時に限ってはペーシング処理を実施せず受信したデータを一斉に転送することが開示されている。なお、ペーシング処理とは、データの送受信状況に応じてデータ伝送速度をリアルタイムに制御する方式である。【０００３】
また、近年、ＡＢＲ（Adaptive Bit Rate）と称されるコンテンツ配信技術が開発されている。非特許文献１には、ＡＢＲ配信方式の一例であるＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇ（ＨＬＳ）が記載されている。ＨＬＳによるコンテンツ配信では、単一のコンテンツは複数のセグメントファイルに分割され、分割されたセグメントファイルごとにクライアント装置に配信される。また、ＨＬＳでは、コンテンツにおける各セグメントファイルのＵＲＬ（Uniform Resource Locator）が再生時間順に記載されたプレイリストファイル、当該コンテンツについてビットレートの異なる複数種類のセグメントファイル、各ビットレートに対応するプレイリストファイルのＵＲＬを記載したヴァリアント・プレイリストファイルが用いられる。クライアントは、ヴァリアント・プレイリストファイルを取得し、当該ファイルに記載されたプレイリストファイルの中から視聴環境に適したビットレートに対応するプレイリストファイルを選択する。クライアント装置は、選択したプレイリストファイルに記載されたセグメントファイルを順次取得し、コンテンツを再生する。【０００４】
特許文献２には、ＡＢＲ配信方式により送信されたデータ（パケット）に対して最適なビットレートを決定するための技術が開示されている。特許文献２には、ＡＢＲの分割ファイル単位でファイル長等から最適な転送ビットレートを算出し、当該ビットレートに合わせて各分割ファイルを転送することが開示されている。【０００５】
特許文献３には、ＨＴＴＰ（Hypertext Transfer Protocol）による動画配信において、映像ファイル情報のダウンロード速度が再生速度を下回った場合に、端末における再生映像の停止（フリーズ）が生じる問題を解決する技術が開示されている。特許文献３には、実際の転送速度を監視する機能と転送対象の映像の再生速度を確認し、再エンコーディングする機能とを備えるシステムが開示されている。特許文献３に開示された技術では、これらの両機能により、常に実際の転送速度が映像の再生速度を上回るようにすることで、再生映像の停止を防止している。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１６−１００６８１号公報
【特許文献２】特開２０１６−２１９９１５号公報
【特許文献３】特開２０１５−１５４３９５号公報
【非特許文献】
【０００７】
【非特許文献１】Apple Inc.、”HTTPライブストリーミングの概要”［0nline］、［平成２９年８月１日検索］、インターネット<URL:https://developer.apple.com/jp/documentation/StreamingMediaGuide.pdf>
【発明の概要】
【発明が解決しようとする課題】
【０００８】
なお、上記先行技術文献の各開示を、本書に引用をもって繰り込むものとする。以下の分析は、本発明者らによってなされたものである。【０００９】
特許文献１及び２に開示された技術では、データ転送中でのネットワーク環境の外乱（特に、劣化）は想定されていない。即ち、特許文献１及び２には、セッション途中でのペーシング処理の停止や再開に関する言及はない。当該事実は、特許文献１及び２に開示された技術では、当初から想定されているビットレートでの配信が継続することを意味する。その結果、外乱が発生する一般的なネットワーク環境に特許文献１及び２に開示されたような技術を適用した場合には以下のような問題が発生し得る。【００１０】
ＡＢＲトラヒック（ＡＢＲ配信方式により送信された同一セッションにおける複数のパケット又はデータ）では、後述するようにデータ通信区間と無通信区間が、交互かつ規則的に発生する。しかし、一般的なネットワーク環境では、例えば、配信元サーバ（ＯＳ；Origin Server）からのデータ受信間隔が想定以上に空いてしまうことがある。このような場合に、元来想定されていたビットレートでＡＢＲトラヒックの規則性通りに移動機がパケットを受信できない状況が突発的に発生する可能性がある。【００１１】
例えば、図１２に示すように、初期通信以降にペーシング処理を実施している際に配信元サーバからのデータ受信間隔が空いた後にデータを受信した場合を考える。この場合、配信元サーバが継続してペーシング処理を実施して移動機にデータを転送すると、移動機でのバッファが断続的に枯渇してしまい動画像再生が途切れてしまう可能性がある。とりわけ、移動機での動画像再生速度が移動機のデータ受信速度より速い場合に、上記問題（再生動画の途切れ）が生じる可能性が高くなる。この結果、動画像を視聴している利用者のＱｏＥが著しく低下してしまう。【００１２】
また、特許文献３に開示された技術では、ＡＢＲトラヒックのように、無通信区間が含まれる通信では再生映像の停止が発生するという問題がある。ＡＢＲトラヒックに特許文献３に開示された技術を適用した場合、無通信区間では実際の転送速度がゼロとなる。その結果、再生速度に関係なく、端末への映像転送速度がゼロとなる。この場合、端末では映像データを受信できないため、再生が停止（フリーズ）してしまう。【００１３】
本発明は、ネットワーク環境の劣化が突発的に発生する状況下においても、利用者のＱｏＥを維持することに寄与するデータ通信装置、通信システム、データ通信方法及びプログラムを提供することを主たる目的とする。
【課題を解決するための手段】
【００１４】
本発明乃至開示の第１の視点によれば、端末及びサーバとの間でデータを送受信する送受信部と、前記サーバから前記端末へのデータ送信がＡＢＲ（Adaptive Bit Rate）配信方式によるものか否かを判定する、第１の判定部と、前記サーバから前記端末へのデータ送信がＡＢＲ配信方式である場合に、前記サーバからの受信データがＡＢＲ配信方式の規則性を維持しているか否かを判定する、第２の判定部と、前記第２の判定部による判定結果に応じて、前記サーバからの受信データを前記端末に転送する際のデータ転送方式を決定する、方式決定部と、を備え、前記送受信部は、前記方式決定部により決定されたデータ転送方式により前記サーバからの受信データを前記端末に転送する、データ通信装置が提供される。【００１５】
本発明乃至開示の第２の視点によれば、端末と、サーバと、前記端末と前記サーバの間の通信を中継する、データ通信装置と、を含み、前記データ通信装置は、前記端末と前記サーバとの間でデータを送受信する送受信部と、前記サーバから前記端末へのデータ送信がＡＢＲ（Adaptive Bit Rate）配信方式によるものか否かを判定する、第１の判定部と、前記サーバから前記端末へのデータ送信がＡＢＲ配信方式である場合に、前記サーバからの受信データがＡＢＲ配信方式の規則性を維持しているか否かを判定する、第２の判定部と、前記第２の判定部による判定結果に応じて、前記サーバからの受信データを前記端末に転送する際のデータ転送方式を決定する、方式決定部と、を備え、前記送受信部は、前記方式決定部により決定されたデータ転送方式により前記サーバからの受信データを前記端末に転送する、通信システムが提供される。【００１６】
本発明乃至開示の第３の視点によれば、端末及びサーバとの間でデータを送受信する送受信部を備えるデータ通信装置において、前記サーバから前記端末へのデータ送信がＡＢＲ（Adaptive Bit Rate）配信方式によるものか否かを判定するステップと、前記サーバから前記端末へのデータ送信がＡＢＲ配信方式である場合に、前記サーバからの受信データがＡＢＲ配信方式の規則性を維持しているか否かを判定するステップと、受信データがＡＢＲ配信方式の規則性を維持しているか否かの判定結果に応じて、前記サーバからの受信データを前記端末に転送する際のデータ転送方式を決定するステップと、前記決定されたデータ転送方式により前記サーバからの受信データを前記端末に転送するステップと、を含むデータ通信方法が提供される。【００１７】
本発明乃至開示の第４の視点によれば、端末及びサーバとの間でデータを送受信する送受信部を備えるデータ通信装置に搭載されたコンピュータに、前記サーバから前記端末へのデータ送信がＡＢＲ（Adaptive Bit Rate）配信方式によるものか否かを判定する処理と、前記サーバから前記端末へのデータ送信がＡＢＲ配信方式である場合に、前記サーバからの受信データがＡＢＲ配信方式の規則性を維持しているか否かを判定する処理と、受信データがＡＢＲ配信方式の規則性を維持しているか否かの判定結果に応じて、前記サーバからの受信データを前記端末に転送する際のデータ転送方式を決定する処理と、前記決定されたデータ転送方式により前記サーバからの受信データを前記端末に転送する処理と、を実行させるプログラムが提供される。
なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transient）なものとすることができる。本発明は、コンピュータプログラム製品として具現することも可能である。
【発明の効果】
【００１８】
本発明乃至開示の各視点によれば、ネットワーク環境の劣化が突発的に発生する状況下においても、利用者のＱｏＥを維持することに寄与するデータ通信装置、通信システム、データ通信方法及びプログラムが提供される。
【図面の簡単な説明】
【００１９】
【図１】一実施形態の概要を説明するための図である。
【図２】ＡＢＲトラヒックの受信データ量に関する波形の模式図の一例を示す図である。
【図３】本願開示の用語を説明するための図である。
【図４】第１の実施形態に係る通信システムの概略構成の一例を示す図である。
【図５】第１の実施形態に係るデータ通信装置のハードウェア構成の一例を示すブロック図である。
【図６】データ通信装置の動作の一例を示すフローチャートである。
【図７】ＡＢＲ判定部の動作の一例を示すフローチャートである。
【図８】規則性判定部の動作の一例を示すフローチャートである。
【図９】規則性判定部の動作を説明するための図である。
【図１０】規則性判定部の動作を説明するための図である。
【図１１】第１の実施形態に係るデータ通信装置の動作を説明するための図である。
【図１２】ネットワーク環境が劣化した際の帯域変動の一例を示す図である。
【発明を実施するための形態】
【００２０】
初めに、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、各図におけるブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。
【００２１】
一実施形態に係るデータ通信装置１００は、送受信部１０１と、第１の判定部１０２と、第２の判定部１０３と、方式決定部１０４と、を備える（図１参照）。送受信部１０１は、端末及びサーバとの間でデータを送受信する。第１の判定部１０２は、サーバから端末へのデータ送信がＡＢＲ（Adaptive Bit Rate）配信方式によるものか否かを判定する。第２の判定部１０３は、サーバから端末へのデータ送信がＡＢＲ配信方式である場合に、サーバからの受信データがＡＢＲ配信方式の規則性を維持しているか否かを判定する。方式決定部１０４は、第２の判定部１０３による判定結果に応じて、サーバからの受信データを端末に転送する際のデータ転送方式を決定する。送受信部１０１は、方式決定部１０４により決定されたデータ転送方式によりサーバからの受信データを端末に転送する。
【００２２】
データ通信装置１００は、ＡＢＲトラヒックのペーシング処理の際に、例えば、ＡＢＲトラヒックパターン（ＡＢＲトラヒックが有する特徴）を考慮し、ＡＢＲトラヒックの規則性が維持されているか消滅しているかを判定する。その後、データ通信装置１００は、ＡＢＲトラヒックの規則性が維持されていない（消滅した）と判定された場合には、ペーシング処理を停止する。対して、ＡＢＲトラヒックの規則性が維持されている場合には、データ通信装置１００は、ペーシング処理を実施する（ペーシング処理を継続する）。即ち、ネットワーク環境の劣化などに起因して端末の受信バッファが枯渇する状況に陥ったとしても、ＡＢＲトラヒックに対して適用されていた帯域制限が解除され、端末の受信バッファが潤沢となるようにデータ通信装置１００からデータ転送がなされる。その結果、端末の受信バッファが断続的に枯渇するような状況を回避することができ、ネットワーク環境の劣化が突発的に発生する状況でも利用者のＱｏＥを維持することができる。
【００２３】
続いて、具体的な実施形態の説明に先立ち、本願開示にて対象とするＡＢＲトラヒックについて説明する。
【００２４】
図２は、ＡＢＲトラヒックの受信データ量に関する波形の模式図の一例を示す図である。図２を参照すると、ＡＢＲトラヒックの波形には少なくとも以下の２つの特徴が確認できる。
【００２５】
第１の特徴は、無通信の区間が定期的に存在する点である。図２では、無通信区間３０１が図示されている。
【００２６】
第２の特徴は、データ通信区間の開始から無通信区間の終了までの期間（サイクル）を１単位とすると、大きなデータ量を受信したサイクルの後続サイクルで受信するデータ量は同程度である点である。図２では、サイクル３１１にて所定のデータ量を受信し、その後続であるサイクル３１２でも同程度のデータ量を受信していることが分かる。
【００２７】
さらに、本願開示にて使用する用語を以下の表１のとおり定める。  
【００２８】
［表１］
2019070017.tif 000003
【００２９】
図３は、本願開示の用語を説明するための図である。図３には、上記表における項目番号（Ｎｏ．）とＡＢＲトラヒック波形との関係が図示されている。
【００３０】
以下に具体的な実施の形態について、図面を参照してさらに詳しく説明する。なお、各実施形態において同一構成要素には同一の符号を付し、その説明を省略する。
【００３１】
［第１の実施形態］
第１の実施形態について、図面を用いてより詳細に説明する。
【００３２】
［システム構成］
図４は、第１の実施形態に係る通信システムの概略構成の一例を示す図である。図４を参照すると、通信システムは、端末１０と、データ通信装置２０と、配信元サーバ３０と、を含んで構成される。
【００３３】
端末１０とデータ通信装置２０は第１ネットワーク（図示せず）を介して接続される。第１ネットワークは、典型的には無線網である。
【００３４】
データ通信装置２０と配信元サーバ３０は第２ネットワーク（図示せず）を介して接続される。第２ネットワークは、典型的には有線網である。
【００３５】
なお、上記第１及び第２ネットワークは、無線網及び有線網に限定されない。これら以外のネットワークにより各装置が接続されていても良いことは勿論である。
【００３６】
端末１０は、ＨＬＳ等のＡＢＲ配信に対応した端末である。端末１０は、配信元サーバ３０に対してデータ送信を要求する。端末１０は、当該要求の結果として送信されるデータを受信する。端末１０は、配信元サーバ３０から配信されるプレイリストファイル（例えば、ＨＬＳにおけるプレイリストファイル、ヴァリアント・プレイリストファイル）に基づき、受信するコンテンツのビットレートを選択する。端末１０は、当該選択したビットレートに応じた分割ファイル（ＨＬＳにおけるＴＳファイル）を取得する。端末１０は、取得した分割ファイルを再生する。端末１０には、スマートフォン、携帯電話、タブレット、パーソナルコンピュータ、ネットワーク接続機能付きテレビジョン等が例示される。
【００３７】
配信元サーバ３０は、ＨＬＳ等のＡＢＲ配信に対応したサーバ装置である。配信元サーバ３０は、端末１０からの要求に応じて、マルチメディアデータ（例えば、動画や音声等）を含むデータを送信する装置である。例えば、配信元サーバ３０は、あるコンテンツに関し、複数のビットレートに対応した分割ファイル（ＴＳファイル）を記憶している。また、配信元サーバ３０は、ビットレートごとのプレイリストファイル（ＨＬＳにおける上記２つのプレイリストファイル）を記憶し、端末１０に配信する。
【００３８】
データ通信装置２０は、端末１０と配信元サーバ３０の間の通信を中継すると共に、ペーシング処理を実施する装置である。データ通信装置２０は、図４に示すように、送受信部２０１とペーシング部２０２を含んで構成される。
【００３９】
送受信部２０１は、端末１０及び配信元サーバ３０との間でデータを送受信する手段である。送受信部２０１は、配信元サーバ３０に対するプロキシ（代理サーバ）として動作する。即ち、送受信部２０１は、端末１０に対してはサーバ、配信元サーバ３０に対してはクライアントとして振る舞う。送受信部２０１は、プロキシを実現するためのアドレス変換や、端末１０や配信元サーバ３０との間の通信制御（例えば、セッション確立、データ転送速度の変更）を行う。送受信部２０１は、後述するデータ転送方式決定部２１３により決定されたデータ転送方式により配信元サーバ３０からの受信データを端末１０に転送する。
【００４０】
ペーシング部２０２は、データの送受信状況に応じたペーシング処理を行う手段である。より具体的には、ペーシング部２０２は、配信元サーバ３０からの受信データがＡＢＲ配信方式によるものか否か、配信元サーバ３０からの受信データがＡＢＲ配信方式の規則性を維持しているか否かに応じて、送受信部２０１による端末１０へのデータ転送方式を決定する（データ転送を制御する）。
【００４１】
ペーシング部２０２は、ＡＢＲ判定部２１１と、規則性判定部２１２と、データ転送方式決定部２１３と、を含んで構成される。
【００４２】
ＡＢＲ判定部２１１は、配信元サーバ３０から端末１０へのデータ送信方式がＡＢＲ配信方式によるものか否かを判定する手段である（第１の判定部）。
【００４３】
規則性判定部２１２は、配信元サーバ３０から端末１０へのデータ送信がＡＢＲ配信方式である場合に、配信元サーバ３０からの受信データがＡＢＲ配信方式の規則性を維持しているか否かを判定する手段である（第２の判定部）。
【００４４】
データ転送方式決定部２１３は、規則性判定部２１２による判定結果に応じて、配信元サーバ３０からの受信データを端末１０に転送する際のデータ転送方式を決定する手段である（方式決定部）。
【００４５】
具体的には、データ転送方式決定部２１３は、規則性判定部２１２による判定結果が、ＡＢＲ配信方式の規則性ありの場合には、ＡＢＲ配信方式に適した帯域制限（帯域制御、データ転送時の転送速度の制御）を行って配信元サーバ３０からの受信データを端末１０に転送するように送受信部２０１に指示する。このように、データ転送方式決定部２１３は、ＡＢＲトラヒックに適したペーシング処理を実現する。なお、データ転送方式決定部２１３には、ＡＢＲトラヒックの場合に使用するペーシングレート（データ転送速度）の値が事前に設定されており、当該レートによるデータ転送を送受信部２０１に指示する。あるいは、特許文献２に開示されたように、データ転送方式決定部２１３は、ファイル長等から最適な転送ビットレートを算出し、当該ビットレートに合わせて各分割ファイルを転送するように送受信部２０１に指示してもよい。あるいは、データ通信装置２０が、端末１０が選択したビットレート（コンテンツのビットレート）に関する情報を取得できる場合には、データ転送方式決定部２１３は、当該取得したビットレートに基づき受信データの転送ビットレートを決定してもよい。
【００４６】
また、データ転送方式決定部２１３は、規則性判定部２１２による判定結果が、ＡＢＲ配信方式の規則性なしの場合には、上記ＡＢＲトラヒックに適用する帯域制限を解除して配信元サーバ３０からの受信データを端末１０に転送するように送受信部２０１に指示する。
【００４７】
［ハードウェア構成］
続いて、データ通信装置２０のハードウェア構成について説明する。
【００４８】
図５は、第１の実施形態に係るデータ通信装置２０のハードウェア構成の一例を示すブロック図である。データ通信装置２０は、図５に例示する構成を備える。例えば、データ通信装置２０は、内部バスにより相互に接続される、ＣＰＵ（Central Processing Unit）２１、メモリ２２、入出力インターフェイス２３、通信インターフェイスであるＮＩＣ（Network Interface Card）２４及び無線アンテナ２６に接続された送受信回路２５等を備える。
【００４９】
但し、図５に示す構成は、データ通信装置２０のハードウェア構成を限定する趣旨ではない。データ通信装置２０は、図示しないハードウェアを含んでもよいし、必要に応じて入出力インターフェイス２３等を備えていなくともよい。例えば、ネットワークにより接続された操作端末によりデータ通信装置２０に情報の入出力を行う場合には、入出力インターフェイス２３が不要な場合もある。また、データ通信装置２０に含まれるＣＰＵ等の数も図５の例示に限定する趣旨ではなく、例えば、複数のＣＰＵ２１がデータ通信装置２０に含まれていてもよい。
【００５０】
また、図５に示す構成は、端末１０とデータ通信装置２０が無線接続し、配信元サーバ３０とデータ通信装置２０が有線接続をする場合に対応したものである。従って、端末１０等との接続方式が異なれば、図５に示す構成が変化するのが当然である。例えば、端末１０とデータ通信装置２０が有線接続される場合には、送受信回路２５は不要である。
【００５１】
メモリ２２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、補助記憶装置（ハードディスク等）である。
【００５２】
入出力インターフェイス２３は、図示しない表示装置や入力装置のインターフェイスである。表示装置は、例えば、液晶ディスプレイ等である。入力装置は、例えば、キーボードやマウス等のユーザ操作を受け付ける装置や、ＵＳＢ（Universal Serial Bus）メモリ等の外部記憶装置から情報を入力する装置である。ユーザは、キーボードやマウス等を用いて、必要な情報をデータ通信装置２０に入力する。
【００５３】
送受信回路２５は、端末１０との間の無線通信を実現するための回路であって、無線アンテナ２６を介して無線信号を送受信する。
【００５４】
データ通信装置２０の機能は、上述の処理モジュール（送受信部２０１、ペーシング部２０２等）により実現される。当該処理モジュールは、例えば、メモリ２２に格納されたプログラムをＣＰＵ２１が実行することで実現される。また、そのプログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。即ち、上記処理モジュールが行う機能は、何らかのハードウェアにおいてソフトウェアが実行されることによって実現できればよい。
【００５５】
［動作の説明］
図６は、データ通信装置２０の動作の一例を示すフローチャートである。
【００５６】
初めに、送受信部２０１は、端末１０から配信元サーバ３０へのセッション確立要求を受信する（ステップＳ０１）。
【００５７】
送受信部２０１は、配信元サーバ３０へセッションの確立要求を送信する（ステップＳ０２）。
【００５８】
その後、送受信部２０１は、配信元サーバ３０からデータを受信し、所定期間に亘り受信データ（受信パケット）をバッファリングする（ステップＳ０３）。その後、送受信部２０１は、バッファリングした受信データ（受信パケット）をＡＢＲ判定部２１１に引き渡す。
【００５９】
ＡＢＲ判定部２１１は、受信データがＡＢＲトラヒックであるか否かを判定し、判定結果と送受信部２０１からの受信データを規則性判定部２１２に引き渡す（ステップＳ０４）。つまり、ＡＢＲ判定部２１１は、配信元サーバ３０から端末１０へのデータ送信方式がＡＢＲ配信方式によるものか否かを判定する。
【００６０】
なお、ＡＢＲ判定部２１１による上記判定は、ＡＢＲトラヒックが有する上記２つの特徴を利用して行われる。具体的には、ＡＢＲ判定部２１１は、所定の区間（表１のＮｏ．１；測定単位区間）ごとに配信元サーバ３０からの受信データに関するデータ量（表１のＮｏ．３：測定単位区間データ量）を算出する。さらに、ＡＢＲ判定部２１１は、算出されたデータ量が所定の閾値（表１のＮｏ．４；データ通信区間最少データ量）よりも大きい測定単位区間が続く区間をデータ通信区間（表１のＮｏ．５）として算出し、測定されたデータ量が所定の閾値以下の測定単位区間が続く区間を無通信区間（表１のＮｏ．６）として算出する。さらに、ＡＢＲ判定部２１１は、データ通信区間と無通信区間を１つのサイクルとして算出する。ＡＢＲ判定部２１１は、さらに、データ通信区間におけるデータ量（表１のＮｏ．８；サイクルデータ量）を算出する。その後、ＡＢＲ判定部２１１は、データ通信区間の後に無通信区間が検出できること（第１の特徴）や、データ通信区間におけるデータ量が前後のサイクルにて同程度であること（第２の特徴）、が所定の期間（数サイクル）に亘って検出できる場合に、受信データはＡＢＲトラヒックと判定する（受信データはＡＢＲ配信方式により送信されたデータであると判定する）。より具体的な判定方法については後述する。
【００６１】
規則性判定部２１２は、ＡＢＲ判定部２１１による判定結果と受信データの受信状況からＡＢＲトラヒックの規則性が維持されているか否かを判定し、その判定結果と受信データをデータ転送方式決定部２１３に引き渡す（ステップＳ０５）。
【００６２】
データ通信装置２０は、ＡＢＲトラヒックの規則性が維持されているか否かに応じたデータ転送を行う（ステップＳ０６）。具体的には、データ転送方式決定部２１３は、規則性判定部２１２による判定結果に基づいて受信データを端末１０に転送する際のデータ転送方式を決定し、当該決定した方式によるデータ転送を送受信部２０１に指示する。
【００６３】
規則性判定部２１２から取得した判定が「規則性が維持されている」であった場合には、データ転送方式決定部２１３は、ペーシング処理を実施すべきと判断する。その場合、データ転送方式決定部２１３は、配信元サーバ３０から受信したデータをＡＢＲトラヒックに適したデータ転送方式により端末１０に転送するように送受信部２０１に指示する。より詳細には、データ転送方式決定部２１３は、例えば、予め設定されたペーシングレート（ビットレート）によるデータ転送を送受信部２０１に指示する。
【００６４】
対して、規則性判定部２１２による判定が「規則性が維持されていない（消滅した）」であった場合には、データ転送方式決定部２１３は、ペーシング処理を実施すべきではないと判断する。その場合、データ転送方式決定部２１３は、配信元サーバ３０から受信しているデータ（データ通信装置２０にバッファされているデータ）を端末１０に対して帯域制限を設けずに転送するように送受信部２０１に指示する。このように、ＡＢＲトラヒックの規則性が維持されていない場合には、データ転送方式決定部２１３は、ＡＢＲトラヒックに適したデータ転送方式による帯域制限を解除する。
【００６５】
次に、ＡＢＲ判定部２１１による受信データがＡＢＲトラヒックであるか否かの判定について説明する。図７は、ＡＢＲ判定部２１１の動作の一例を示すフローチャートである。
【００６６】
ＡＢＲ判定部２１１は、蓄積された受信データを用いて、ＡＢＲトラヒックに特有なサイクル（表１及び図３のＮｏ．７）を検出する（ステップＳ１０１）。具体的には、ＡＢＲ判定部２１１は、測定単位区間（表１及び図３のＮｏ．１）におけるデータ量（受信パケット）を積算し、測定単位区間データ量（表１及び図３のＮｏ．３）を算出する。その後、ＡＢＲ判定部２１１は、測定単位区間データ量とデータ通信区間最小データ量（表１及び図３のＮｏ．４）を比較し、測定単位区間がデータ通信区間（表１及び図３のＮｏ．５）であるのか、無通信区間（表１及び図３のＮｏ．６）であるのかを判定する。その後、ＡＢＲ判定部２１１は、連続するデータ通信区間と連続する無通信区間を１組とするサイクル（表１及び図３のＮｏ．７）を算出する。ＡＢＲ判定部２１１は、蓄積（バッファリング）された受信データに対して上記処理を繰り返すことで、図３に示すような波形情報を取得する。
【００６７】
次に、ＡＢＲ判定部２１１は、検出されたサイクルごとに、ステップＳ１０２〜Ｓ１０６の処理を実行することで、各サイクルにＡＢＲトラヒックの特徴が存在するか否かを判定する。
【００６８】
ステップＳ１０２において、ＡＢＲ判定部２１１は、判定対象サイクルのサイクルデータ量（表１のＮｏ．８）が、サイクルデータ量上限（予め定められた閾値）よりも大きいか否かを判定する。サイクルデータ量がサイクルデータ量上限よりも大きければ（ステップＳ１０２、Ｙｅｓ分岐）、判定対象のサイクルは「ＡＢＲトラヒックの特徴なし」と判定される（ステップＳ１０７）。サイクルデータ量がサイクルデータ量上限以下であれば（ステップＳ１０２、Ｎｏ分岐）、ステップＳ１０３の処理が実行される。
【００６９】
ステップＳ１０３において、ＡＢＲ判定部２１１は、判定対象サイクルのサイクル長（表１のＮｏ．９）が、サイクル長上限よりも長いか否かを判定する。サイクル長がサイクル長上限よりも長ければ（ステップＳ１０３、Ｙｅｓ分岐）、判定対象のサイクルは「ＡＢＲトラヒックの特徴なし」と判定される（ステップＳ１０７）。サイクル長がサイクル長上限以下であれば（ステップＳ１０３、Ｎｏ分岐）、ステップＳ１０４の処理が実行される。
【００７０】
ステップＳ１０４において、ＡＢＲ判定部２１１は、判定対象サイクルの無通信区間から次のサイクルのデータ通信区間への遷移が生じているか否かを判定する。無通信区間からデータ通信区間への遷移（変化）が生じていなければ（ステップＳ１０４、Ｎｏ分岐）、無通信区間が継続していることを意味する。従って、事実上、端末１０と配信元サーバ３０との間の通信は行われていないことになるので、処理を終了する。無通信区間からデータ通信区間への遷移が生じていれば（ステップＳ１０４、Ｙｅｓ分岐）、ステップＳ１０５の処理が実行される。
【００７１】
ステップＳ１０５において、ＡＢＲ判定部２１１は、サイクルデータ量変化率（表１のＮｏ．１０）がサイクルデータ量変化率上限以下であるか否かを判定する。サイクル量変化率がサイクルデータ量変化率上限より大きい場合（ステップＳ１０５、Ｎｏ分岐）、判定対象サイクルは「ＡＢＲトラヒックの特徴なし」と判定される（ステップＳ１０７）。サイクルデータ量変化率がサイクルデータ量変化率上限以下である場合（ステップＳ１０５、Ｙｅｓ分岐）、ステップＳ１０６の処理が実行される。
【００７２】
例えば、図３において、１サイクル目と図示されたサイクルが判定対象サイクルであれば、当該サイクルとその後に続くサイクル（２サイクル目と表記されたサイクル）のサイクルデータ量の変化率が計算される。この変化率が、当該変化率が予め定めた閾値（サイクルデータ量変化率上限）以下であれば、２つの連続するサイクルにおける受信データ量は同程度であるという上記第２の特徴に合致する。換言すれば、サイクルデータ量変化率が上限を超えている場合、当該サイクルにはＡＢＲトラヒックの特徴が表れていないと判断される。
【００７３】
ステップＳ１０６において、ＡＢＲ判定部２１１は、サイクル長変化率（表１のＮｏ．１１）がサイクル長変化率上限以下であるか否かを判定する。サイクル長変化率がサイクル長変化率上限よりも大きい場合（ステップＳ１０６、Ｎｏ分岐）、判定対象サイクルは「ＡＢＲトラヒックの特徴なし」と判定される（ステップＳ１０７）。サイクル長変化率がサイクル長変化率上限以下である場合（ステップＳ１０６、Ｙｅｓ分岐）、判定対象サイクルは「ＡＢＲトラヒックの特徴あり」と判定される（ステップＳ１０８）。
【００７４】
例えば、図３において、１サイクル目と図示されたサイクルが判定対象サイクルであれば、当該サイクルとその後に続くサイクル（２サイクル目と表記されたサイクル）のサイクル長の変化率が計算される。この変化率が、当該変化率が予め定めた閾値（サイクル長変化率上限）以下であれば、当該サイクルにはＡＢＲトラヒックの特徴が表れていると判断される。
【００７５】
判定対象サイクルの判定が終了すると、ＡＢＲ判定部２１１は、判定すべきサイクルが残っているか否かを確認する（ステップＳ１０９）。判定するサイクルが存在すれば、ＡＢＲ判定部２１１は、判定対象サイクルを変更（ステップＳ１１０）し、ステップＳ１０２以降の処理を繰り返す。判定対象サイクルが存在しなければ、ステップＳ１１１の処理が実行される。
【００７６】
ステップＳ１１１において、ＡＢＲ判定部２１１は、各サイクルにおける判定結果（ＡＢＲの特徴あり、ＡＢＲの特徴なし）に基づいて受信データがＡＢＲトラヒックであるか否かを判定する。例えば、「ＡＢＲトラヒックの特徴あり」と判定されたサイクルの割合が所定値以上であれば、受信データは「ＡＢＲ」であると判定され、そうでなければ受信データは「非ＡＢＲ」と判定される。
【００７７】
次に、規則性判定部２１２の動作を、図面を参照しつつ説明する。図８は、規則性判定部２１２の動作の一例を示すフローチャートである。ここでは、規則性判定部２１２が、あるセッションの受信データとＡＢＲトラヒックか否かの判定結果をＡＢＲ判定部２１１から取得済みであるとする。なお、規則性判定部２１２は、ＡＢＲ判定部２１１から該当セッションのデータを随時受信しており、処理待ちのデータは規則性判定部２１２の内部記憶領域（例えば、メモリやレジスタ）に保存されている。
【００７８】
規則性判定部２１２は、ＡＢＲ判定部２１１からの判定結果の内容を確認する（ステップＳ２０１）。
【００７９】
ＡＢＲ判定部２１１からの判定結果がＡＢＲトラヒックではないことを示す「非ＡＢＲ」の場合には、規則性判定部２１２は、ＡＢＲ判定部２１１からの判定結果と受信データをデータ転送方式決定部２１３に通知（ステップＳ２０２）して処理を終了する。
【００８０】
一方、ＡＢＲ判定部２１１からの判定結果がＡＢＲトラヒックであることを示す「ＡＢＲ」の場合には、規則性判定部２１２は、該当セッションでの規則性に関する維持状況（ＡＢＲトラヒックの規則性は維持されているか又は消滅しているか）を示すモードを設定する（ステップＳ２０３）。
【００８１】
モードは、ＡＢＲトラヒックの規則性が維持されていると判定された場合には「維持」に、規則性が消滅したと判定された場合には「消滅」にそれぞれ設定される。なお、ＡＢＲ判定部２１１から受信した直後の処理では「維持」に設定される。
【００８２】
次に、規則性判定部２１２は、受信したデータから１サイクル分のデータを切り出す（ステップＳ２０４）。規則性判定部２１２は、測定単位区間ごとのデータ量（測定単位区間データ量）の変化を確認することで当該１サイクルの切り出し（判定）を実現する。具体的には、図３に示すように、ＡＢＲトラヒックではデータが存在する測定単位区間が連続して出現した後、データが存在しない測定単位区間が連続して出現する。その後、再度データが存在する測定単位区間が連続して出現する。規則性判定部２１２は、このデータが存在する測定単位区間とデータが存在しない測定単位区間を合わせて１つのサイクルと捉える。なお、規則性判定部２１２は、測定単位区間データ量がデータ通信区間最少データ量以下である場合に「データが存在しない」と判断する。
【００８３】
次に、規則性判定部２１２は、モードを確認する（ステップＳ２０５）。
【００８４】
モードが「消滅」の場合には、規則性判定部２１２は、切り出したサイクルにおけるデータからＡＢＲトラヒックの規則性が検出できるか否かを判定する（ステップＳ２０６）。換言するならば、規則性判定部２１２は、ＡＢＲトラヒックの規則性が復活しているか否かを判定する。
【００８５】
当該規則性の検出方法の具体例を、図９を参照しつつ説明する。
【００８６】
図９（ａ）は、ＡＢＲトラヒックの規則性が検出される場合の一例を示す。図９（ｂ）は、ＡＢＲトラヒックの規則性の検出には至っていない場合の一例を示す。
【００８７】
図９（ｂ）に示すように、規則性が直近サイクルに限り検出された場合では、規則性が維持されているとは判定されない。対して、少なくとも２回連続してＡＢＲトラヒックの規則性が検出された場合（図９（ａ））には、規則性が維持されていると判断される。即ち、規則性判定部２１２は、受信データにＡＢＲトラヒック特有の特徴を２回連続（２サイクル連続）して検出した場合に、受信データにＡＢＲトラヒックの規則性が存在すると判定する。
【００８８】
なお、図９の例は、規則性を判定する際の閾値を「２」に設定しているが、当該閾値を「２」に限定する趣旨ではないことは勿論である。また、上記判断を実現するため、規則性判定部２１２は、直近２サイクル分の情報（サイクルデータ量とサイクル長）を記憶領域（メモリ、レジスタ等）に格納しておく。
【００８９】
ここで、ＡＢＲトラヒックではサイクルデータ量とサイクル長に関してサイクルごとの変化は殆ど存在せず、サイクルデータ量は、サイクルデータ量変化率上限以下かつサイクル長変化率上限以下となる。そのため、処理対象サイクルのサイクルデータ量とサイクル長が直近サイクルのサイクルデータ量とサイクル長と同程度（サイクルデータ量変化率上限以下かつサイクル長変化率上限以下）であるか否かを規則性判定部２１２は、ＡＢＲトラヒックにおける規則性の検出に利用する。即ち、規則性判定部２１２は、サイクルデータ量変化率上限とサイクル長変化率上限を用いて、受信データがＡＢＲトラヒックの特徴（上述の第１の特徴、第２の特徴）を有しているか否かを判定する。
【００９０】
さらに、規則性判定部２１２は、受信データがＡＢＲトラヒックであると判定された回数が所定の回数以上続いた場合（上記の例では２回）に、ＡＢＲトラヒックの規則性が存在すると判定する。
【００９１】
このように、規則性判定部２１２は、ＡＢＲ判定部２１１と同様な方法により受信データからＡＢＲ配信方式によるデータが有する特徴を抽出する（データ通信区間、無通信区間、サイクル、サイクルデータ量等を算出する）。その後、規則性判定部２１２は、前後するサイクル（第１のサイクルと第１のサイクルに続く第２のサイクル）におけるデータ量の変化率が第１の上限値（表１のＮｏ．１０；サイクルデータ量変化率上限）よりも小さく、且つ、第１のサイクルの長さに対する第２のサイクルの長さに関する変化率が第２の上限値（表１のＮｏ．１１；サイクル長変化率上限）よりも小さい場合に、ＡＢＲ配信方式の規則性は維持されていると判定する。
【００９２】
図８に説明を戻すと、モードが「維持」の場合には、規則性判定部２１２は、ＡＢＲトラヒックの規則性が消滅していないか否かを判定する（ステップＳ２０７）。換言するならば、規則性判定部２１２は、ＡＢＲトラヒックの規則性が一時的に消滅しているか否かを判定する。
【００９３】
当該規則性が消滅しているか否かの判定方法の具体例を、図１０を参照しつつ説明する。
【００９４】
図１０（ａ）は、ＡＢＲトラヒックの規則性が消滅したと判断される場合の一例を示す。図１０（ｂ）は、ＡＢＲトラヒックの規則性が消滅したとの判断には至らない場合の一例を示す。
【００９５】
図１０（ｂ）に示すように、直近サイクルに限り規則性が検出できない場合には、ＡＢＲトラヒックの規則性が消滅したとは判断されない。対して、連続する２サイクルで規則性が検出できない場合（図１０（ａ））には、規則性が消滅したと判断される。
【００９６】
なお、上記判断を実現するため、上記処理でも規則性判定部２１２は格納している直近２サイクル分の情報（サイクルデータ量とサイクル長）を使用する。図１０（ａ）を参照すると、２つ前のサイクルのサイクル長が長くなっており、サイクル長変化率上限を超過している。さらに、直近サイクルでのサイクルデータ量が多くなっており、サイクルデータ量変化率上限を超過している。
【００９７】
これらの結果から、連続する２サイクルで規則性が検出されないため、規則性判定部２１２は、ＡＲＢトラヒックの規則性が消滅したと判断する。
【００９８】
なお、図１０の例は、規則性が消滅したと判定する際の閾値を「２」に設定しているが、当該閾値を「２」に限定する趣旨ではないことは勿論である。
【００９９】
このように、規則性判定部２１２は、ＡＢＲ配信方式により送信された受信データが有する、サイクルの長さに関する特徴とデータ通信区間におけるデータ量に関する特徴に基づき、ＡＢＲ配信方式の規則性に関する有無を判定する。
【０１００】
図８に説明を戻すと、規則性判定部２１２は、ＡＢＲトラヒックの規則性に関する判定結果（維持、消滅）に応じてモードを変更する（ステップＳ２０８）。
【０１０１】
その後、規則性判定部２１２は、データ転送方式決定部２１３へＡＢＲ判定部２１１の判定結果（ＡＢＲ、非ＡＢＲ）と規則性判定部２１２の判定結果（ＡＢＲトラヒックの規則性維持、消滅）を通知する（ステップＳ２０９）。
【０１０２】
さらにその後、該当セッション（同一セッション）のデータを規則性判定部２１２が継続して受信しているかを確認（ステップＳ２１０）し、受信している場合には次サイクルに移行する（ステップＳ２１１）。一方、当該セッションのデータが存在しない場合には、規則性判定部２１２は、処理を終了する。このように、規則性判定部２１２は、同一セッションのデータを対象として、受信データがＡＢＲ配信方式の規則性を維持しているか否かを判定する。
【０１０３】
以上のように、第１の実施形態に係るデータ通信装置２０は、ＡＢＲトラヒック転送中にその規則性の存在有無を判定し、判定結果に応じてペーシング処理を適用すべきか否かを決定している。より具体的には、ＡＢＲ判定部２１１により受信データはＡＢＲトラヒックであると判定された場合であっても、データ通信装置２０は、規則性判定部２１２を常時稼働させ、ＡＢＲトラヒックの規則性が維持されているか否かを判定する。判定の結果、ＡＢＲトラヒックの規則性が維持されていないと判断される場合には、ＡＢＲトラヒックに適したデータ転送方式（所定のビットレートによる帯域制限）を解除し、データ通信装置２０が受信済みのデータを端末１０に対してまとめて転送する。
【０１０４】
即ち、第１の実施形態では、ネットワーク環境の劣化が突発的に発生する状況下においても利用者のＱｏＥを維持することを実現するため、受信データがＡＢＲトラヒックと一旦判定された後に生じる外乱によりＡＢＲトラヒックの規則性が消滅する場合を想定する。その上で、データ通信装置２０は、端末１０にデータを転送するペーシング処理の前にＡＢＲトラヒックの規則性が維持されているかを判定する。その結果、通常のネットワーク環境において、配信元サーバ３０からのデータ受信間隔が想定以上に空いてしまうなど、想定したＡＢＲトラヒックの規則性通りに端末１０がパケットを受信できない状況が突発的に発生した場合であっても、利用者のＱｏＥ劣化を回避することができる。
【０１０５】
例えば、図１１に示すように、ＡＢＲトラヒック転送中にネットワーク環境が劣化し、受信データが途切れてしまった場合には、データ通信装置２０は、ＡＢＲトラヒックの規則性が消滅したと判定する。その結果、データ通信装置２０は、ペーシング処理を停止させ自装置に蓄積しているデータを端末１０に一斉（まとめて）に転送することが可能となる。そのため、端末１０のバッファを瞬時に満たすことができ、端末１０におけるバッファの枯渇が１度に制限される。
【０１０６】
つまり、図１１と図１２の比較で明らかなように、利用者は断続的な動画像停止ではなく、１度の動画像停止を体感するに限られる。即ち、第１の実施形態に係るデータ通信装置２０を用いることで、突発的なネットワーク環境の劣化においてもＱｏＥの劣化を最小限に留めることができる。
【０１０７】
上述の説明で用いた複数のフローチャートでは、複数の工程（処理）が順番に記載されているが、各実施形態で実行される工程の実行順序は、その記載の順番に制限されない。実施形態では、例えば各処理を並行して実行する等、図示される工程の順番を内容的に支障のない範囲で変更することができる。
【０１０８】
上記の説明により、本発明の産業上の利用可能性は明らかであるが、本発明は、移動体通信（セルラネットワーク）において、端末と動画配信サービスの間の通信を対象とした通信流量制御などに好適に適用可能である。また、セルラネットワークの代わりに、無線／有線ＬＡＮ（Local Area Network）、光ファイバ等の各種アクセス網を通した通信を対象とした通信流量制御にも好適に適用可能である。
【０１０９】
上記の実施形態の一部又は全部は、以下の形態のようにも記載され得るが、以下には限られない。
［形態１］
上述の第１の視点に係るデータ通信装置のとおりである。
［形態２］
前記方式決定部は、前記第２の判定部による判定結果が、ＡＢＲ配信方式の規則性ありの場合には、ＡＢＲ配信方式に適した帯域制限を行って前記サーバからの受信データを前記端末に転送するように前記送受信部に指示する、好ましくは形態１のデータ通信装置。
［形態３］
前記方式決定部は、前記第２の判定部による判定結果が、ＡＢＲ配信方式の規則性なしの場合には、前記帯域制限を解除して前記サーバからの受信データを前記端末に転送するように前記送受信部に指示する、好ましくは形態２のデータ通信装置。
［形態４］
前記第２の判定部は、
所定の測定単位区間ごとに前記サーバからの受信データに関するデータ量を測定し、前記測定されたデータ量が所定の閾値よりも大きい前記測定単位区間が続く区間をデータ通信区間として算出し、前記測定されたデータ量が前記所定の閾値以下の前記測定単位区間が続く区間を無通信区間として算出すると共に、前記データ通信区間と前記無通信区間を１つのサイクルとし、
ＡＢＲ配信方式により送信された受信データが有する、前記サイクルの長さに関する特徴と前記データ通信区間におけるデータ量に関する特徴に基づき、前記ＡＢＲ配信方式の規則性に関する有無を判定する、好ましくは形態１乃至３のいずれか一に記載のデータ通信装置。
［形態５］
前記第２の判定部は、
第１のサイクルと前記第１のサイクルに続く第２のサイクルにおけるデータ量の変化率が第１の上限値よりも小さく、且つ、前記第１のサイクルの長さに対する第２のサイクルの長さに関する変化率が第２の上限値よりも小さい場合に、ＡＢＲ配信方式の規則性は維持されていると判定する、好ましくは形態４のデータ通信装置。
［形態６］
前記送受信部は、前記サーバに対するプロキシとして動作する、好ましくは形態１乃至５のいずれか一に記載のデータ通信装置。
［形態７］
前記第２の判定部は、同一セッションのデータを対象として、受信データがＡＢＲ配信方式の規則性を維持しているか否かを判定する、好ましくは形態１乃至６のいずれか一に記載のデータ通信装置。
［形態８］
上述の第２の視点に係る通信システムのとおりである。
［形態９］
上述の第３の視点に係るデータ通信方法のとおりである。
［形態１０］
上述の第４の視点に係るプログラムのとおりである。
なお、形態８〜１０は、形態１と同様に、形態２〜形態７のように展開することが可能である。
【０１１０】
なお、引用した上記の特許文献等の各開示は、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。
【符号の説明】
【０１１１】
１０  端末
２０、１００  データ通信装置
２１  ＣＰＵ
２２  メモリ
２３  入出力インターフェイス
２４  ＮＩＣ
２５  送受信回路
２６  無線アンテナ
３０  配信元サーバ
１０１、２０１  送受信部
１０２  第１の判定部
１０３  第２の判定部
１０４  方式決定部
２０２  ペーシング部
２１１  ＡＢＲ判定部
２１２  規則性判定部
２１３  データ転送方式決定部
３０１  無通信区間
３１１、３１２  サイクル
【図１】
2019070017.tif 000004
【図２】
2019070017.tif 000005
【図３】
2019070017.tif 000006
【図４】
2019070017.tif 000007
【図５】
2019070017.tif 000008
【図６】
2019070017.tif 000009
【図７】
2019070017.tif 000010
【図８】
2019070017.tif 000011
【図９】
2019070017.tif 000012
【図１０】
2019070017.tif 000013
【図１１】
2019070017.tif 000014
【図１２】
2019070017.tif 000015
【国際調査報告】
2019070017.tif 000016
2019070017.tif 000017
2019070017.tif 000018
2019070017.tif 000019