JP6606176B2 - 適応型レート制御及びトラフィック管理のシステム及び方法 - Google Patents

Description

関連出願の相互参照
０００１ 本出願は、２０１４年３月４日に出願された米国仮出願第６１/９４７,９８２号の関連出願である、２０１４年９月５日に出願された米国仮出願第６２/０４６,８７４号の優先権及び利益を主張する。

０００２ 本発明の実施形態の態様は、適応型レート制御及びトラフィック管理のシステム及び方法に関する。

０００３ 電子デバイス（スマートフォン又はタブレットなどのポータブル電子デバイスを含む）用の高帯域幅アプリケーション（例えばストリーミング動画）の使用の増加により、無線データネットワーク（例えばセルラーデータネットワーク）に対する需要が大きくなってきている。現在、同じ制限されたネットワーク帯域幅を使用しようとするこれらのデバイス上で動作している多数のポータブルデバイス及びアプリケーション（「アプリ」）が存在する。デバイス上のキャッシュサーバのコンテンツは同じデータに対する繰り返しのリクエストには役立つものの、これは、しばしば又は通常は、これらの高帯域幅アプリケーションの多く（ポータブルデバイス上でリアルタイムに動画コンテンツを見たり、音声コンテンツを聞いたりする時など）ではそうではない。

０００４ 現在のモバイル通信システム（例えばセルラーネットワーク）は、制限された容量が加速する需要に追い付かないことによって引き起こされる問題の影響を受けている。容量は、各モバイルネットワークオペレータの有限の無線スペクトル、既存のスペクトルのスペクトル容量における物理的限度に達する技術、及び新しいスペクトルへのアクセスのための長い規制リード時間によって制限される。同時に、より多くのユーザが移動可能となり、モバイルデバイスがより高速／高機能になることによる需要が、利用できる容量を上回っている。容量が不十分である結果として、モバイルサービスのネットワーク混雑、貧弱なユーザ体験、及び収益の機会の喪失となる。

０００５ ユーザ需要とネットワークモバイルネットワーク容量のミスマッチの原因は多くある（例えば、より高速のデバイス、よりデータ消費量が多い又は「派手な」アプリ、及びモバイル動画の増加など）。モバイル動画の消費は特に問題であるが、それは、主に利用できるネットワーク容量のすべてまで自動的に使用するためのアダプティブ動画ストリーミングの本来の動作のために、他のどのモバイル活動よりも速くデータ消費を増やしているからである。アダプティブ動画ストリーミングは、デバイスがより低速のネットワークに合わせて動画品質を下げるように自動的に調整できるように設計されているが、より高速のネットワークに合わせて動画品質を上げるように自動的に調整する反対の動作も可能にし、その結果、ユーザにとって予想できないほど高いデータ使用をもたらし得る。

０００６ 不運にも、ユーザ又はモバイルネットワークオペレータは、そのデータ使用を管理するための十分な洞察又は制御を有していないので、この需要と容量のミスマッチの結果として、一般に貧弱なユーザ体験及び／又はエンドユーザの高いコストにつながる。モバイルオペレータは、過剰にチャティであったり過剰なデータを使用し得る特定のアプリを見るためのネットワークからの可視性をほとんど又は全く有さず、よって、モバイルネットワークに対するその影響を調整／制限するための精度に欠ける。モバイルオペレータは、特定のユーザからのデータ消費を監視及び／又は制御するためのネットワークに配置された既存のツール（例えばインテリジェントなスイッチ及びプロキシサーバ）を有するが、これらのツールは、特定のトラフィックのための特定のアプリを確実に特定はできないため、十分な粒度を欠いている。エンドユーザにとっては、当該ツールは、そのデータ消費を管理するための制御（例えば高帯域幅の動画ストリームがそのデータ計画を使い果たすことを防いだり、特定のアプリがローミングの際にデータを使用するのを許可する／ブロックしたりすることなど）をほとんど有さない。これは、エンドユーザがそのデータ消費、コスト、及びユーザ体験を管理可能とすることを防ぐ。

０００７ 本発明の実施形態の態様は、ポータブルデバイス（例えばスマートフォン）上のトラフィックの監視及び制御を対象とする。さらなる態様は、適応型レート制御及びトラフィック管理のシステム及び方法を対象とする。

０００８ 本発明の実施形態の態様は、モバイルデバイス内からのアプリケーションレベルのデータ使用の検出及び制御を提供することによって、これらの及び他の懸念に取り組む。さらに詳細に、本発明の態様は、モバイルアプリに提供されるデータレートを制限することによってデータ消費の大幅な削減を提供する（例えばアダプティブ動画ストリームにおいて）。さらなる態様は、デバイスがデータを受信するために携帯電話の基地局に接続される必要がある時間の総量を減らすために、アプリ／デバイスにデータをバースト受信することによって、ラジオ信号送信及びセルラー混雑の削減を提供する。そしてさらなる態様は、モバイルアプリに許可／限定されるネットワーク容量のきめ細かい追跡及び制御を提供する。

０００９ 従って、本発明の実施形態は、モバイルデバイス上のアプリによって実行されるモバイルトラフィックを処理する能力を提供する。「帯域内で」このトラフィックを処理する能力は、モバイルアプリトラフィックに適用される多種多様な監視及び制御機能を可能にする。デバイス内のこのトラフィックを処理する能力は、デバイスがアクセスする任意のネットワークに亘ってこれらの機能を可能にする。本発明の実施形態は、帯域内の監視及び制御がモバイルデバイス上で達成され得る複数の方法（例えば、プロキシ構成、ＶＰＮトンネルデバイス、又はモバイルアプリ内のリクエスト傍受の使用）を提供する。

００１０ 本発明の実施形態は、データストリーミングアプリケーション（動画又は音声など）の帯域幅を改良又は最適化することを対象とする。本発明の実施形態は、動画又は音声のストリーミング技術に適したストリーミングファイル（例えば、マルチメディアストリームの質を、当該ストリームを送信するのに利用できる帯域幅の質に一致するように調整するＡＢＲ（アダプティブビットレート））を含む、一部のコンテンツを一時的に格納すること（例えば次のいくつかの動画チャンクを事前読み込みすること）を対象とする。

００１１ 本発明の実施形態は、アダプティブビットレート（ＡＢＲ）制御（例えば、既存のプロトコルで帯域幅使用を最小にするためにこのような方法でデータをリクエストするためにアプリを最適化する）及び接続制御（例えば、ネットワークへの接続時間を、データをできるだけ効率的に取得するのに必要な時間に最小化する）を対象とする。

００１２ 本発明の実施形態は、データ速度のビットレート制御、ストリームチャンクの事前読み込み（後で接続を開くのを避けるために、アプリが当該事前読み込みを要求する前に）、ストリームチャンク（動画ストリームチャンクなど）を事前読み込みする際に事前読み込みのデータ速度及び量をビットレート制御するために、かつ特定のリクエスト（例えばアプリによるネットワークの使用を制御又は制限するため）を許可及び不許可するために、望ましいビットレート制御を決めるための方針に基づく規則を対象とする。

００１３ データ速度のビットレート制御は、例えば帯域幅の使用を減らすために使用されてよく、かつ接続時間を減らすためにいくつかの場合ではストリームチャンクの事前読み込み（例えば、ストリーミングコンテンツ（例えば動画）用）と組み合わせられ得る。これらを制御するためのポリシーに基づく規則のための別の用語は、「エンドポイントのトラフィック管理」であり、これは、アプリが実行できるリクエストのタイプ及び頻度を制限するために使用してよい。

００１４ これらの技術のすべての重要な態様は、それらが以前はエンドポイントデバイス（スマートフォン又はタブレットなど）上で有効にされていないことである。

００１５ 本発明の一実施形態では、アダプティブビットレートは、データがいかに配信されるかを決定し、それを利用するためにクライアントからのリクエストを最適化する（ユーザが本当にこれを必要とするまで過剰なコンテンツをバッファリングすること）。他の実施形態では、ビットレート制御は、データが、これを要求しているアプリにいかに速く配信されているかを判定する。例えば、これは、「アダプティブビットレートストリーム」に該当し得るものであり、アプリは、要求するアイテムの複数のサイズの選択肢（例えば同じ動画を複数の解像度で）を有し、ペースを遅くすることで、アプリによりサイズが小さいバージョン（よってより小さい帯域幅を使用する）を選択させる。

００１６ 本発明の一実施形態では、接続制御は、接続期間を最大限に利用するように試み、接続を切って、再度アクセスが必要になるまで他のアプリケーション／ユーザがネットワークにアクセスすることを許す。

００１７ 本発明の一実施形態では、トラフィック管理は、現在システムが利用できない多数のユーザビリティの機能（セキュリティ、使用監視など）を追加する。１つ以上の実施形態では、これらの機能は、ユーザビリティ（エンドユーザ用）又はネットワークオペレータ（例えばセルラープロバイダ）用の制御／保護のいずれかであってよい。いくつかの実施形態では、これらは、方針を適用しかつ決定を下すことができるように、エンドポイントデバイスのトラフィックフローの中心点に位置するトラフィックマネージャ（プロキシなど）に依存し、又は当該トラフィックマネージャを有し得る。

００１８ 本発明の一実施形態では、コンピュータプロセッサと、ネットワーク経由で前記プロセッサとの間でデータを送受信するためのコンピュータサーバへのネットワーク接続とを有するポータブル通信デバイスにおける、通信トラフィック管理方法が提供される。この方法は、前記プロセッサ上で動作しているトラフィックマネージャアプリケーションによって、前記プロセッサ上で動作し、かつ前記ネットワーク経由で前記サーバに／から第１のデータを配信する第１のアプリケーションを特定することと、前記トラフィックマネージャアプリケーションによって、前記第１のアプリケーションへの／からの前記第１のデータの電子トラフィックを傍受することと、前記トラフィックマネージャアプリケーションによって、前記第１のアプリケーションへの／からの、又は前記サーバへの／からの前記第１のデータの配信速度を制御することとを含む。

００１９ 前記第１のデータの前記配信速度の前記制御は、前記第１のアプリケーションによって認識される前記ネットワークの現在速度を、前記ネットワークの前記現在速度より遅い第１のデータレートに絞ることを含み得る。

００２０ 前記第１のデータの前記電子トラフィックは、データがハイパーテキストトランスファープロトコル（ＨＴＴＰＳ）のセキュアプロトコルを使用して送信されることを含み得る。

００２１ 前記第１のデータの前記配信速度の前記制御は、前記サーバへの／からの前記第１のデータの前記配信速度を、前記ネットワークの現在速度より遅い第１のデータレートに絞ることを含み得る。

００２２ 前記第１のデータの前記電子トラフィックは、アダプティブビットレートストリームを含み得る。

００２３ 前記第１のデータの前記電子トラフィックは、プログレッシブストリームを含み得る。

００２４ 前記第１のアプリケーションは、マニフェストによって制御される異なる対応する解像度を有する複数のデータレートをサポート可能であり得る。前記第１のデータの前記配信速度の前記制御は、前記データレートのうち第１のデータレートを超える前記データレートを隠す又は取り除くために前記マニフェストを編集することを含み得る。

００２５ 前記第１のアプリケーションは、異なる対応する解像度を有する複数のデータレートをサポート可能であり得る。前記第１のデータの前記配信速度の前記制御は、前記データレートのうち第１のデータレートを超える前記データレートへのアクセスを失敗又はブロックすることを含み得る。

００２６ 前記方法は、前記トラフィックマネージャアプリケーションによって、前記プロセッサ上で動作し、かつ前記ネットワーク経由で前記サーバに／から第２のデータを配信する第２のアプリケーションを特定することと、前記トラフィックマネージャアプリケーションによって、前記第２のアプリケーションへの／からの前記第２のデータの電子トラフィックを傍受することと、前記トラフィックマネージャアプリケーションによって、前記第２のアプリケーションへの／からの、又は前記サーバへの／からの前記第２のデータの配信速度を制御することとをさらに含み得る。

００２７ 前記第１の及び第２のデータの前記配信速度の前記制御は、前記第１のデータの前記配信速度が、前記第２のデータの前記配信速度を超えるように、前記第１の及び第２のデータの前記配信速度を同時に制限することを含み得る。

００２８ 前記電子トラフィックの前記傍受は、前記プロセッサ上で動作している内部プロキシの使用を含み得る。

００２９ 前記電子トラフィックの前記傍受は、前記プロセッサ上の仮想プライベートネットワーク（ＶＰＮ）インターフェースの使用を含み得る。

００３０ 前記電子トラフィックの前記傍受は、前記プロセッサ上で変更された前記第１のアプリケーションを実行することを含み得るものであり、前記変更された第１のアプリケーションは、前記電子トラフィックの前記傍受を要求するように構成される。

００３１ 本発明の他の実施形態では、通信トラフィック管理システムが提供される。当該システムは、コンピュータプロセッサと、ネットワーク経由で前記プロセッサとの間でデータを送受信するためのコンピュータサーバへのネットワーク接続とを有するポータブル通信デバイスと、前記プロセッサに接続された非揮発性記憶装置とを備える。当該非揮発性記憶装置は、前記プロセッサによって実行された場合、前記プロセッサに、前記プロセッサ上で動作し、かつ前記ネットワーク経由で前記サーバに／から第１のデータを配信する第１のアプリケーションを特定することと、前記第１のアプリケーションへの／からの前記第１のデータの電子トラフィックを傍受することと、前記第１のアプリケーションへの／からの、又は前記サーバへの／からの前記第１のデータの配信速度を制御することとを行わせる命令を記憶する。

００３２ 前記命令は、前記プロセッサによって実行された場合、前記第１のアプリケーションによって認識される前記ネットワークの現在速度を、前記ネットワークの前記現在速度より遅い第１のデータレートに絞ることによって、さらに前記プロセッサに、前記第１のデータの前記配信速度を制御させ得る。

００３３ 前記第１のデータの前記電子トラフィックは、データがハイパーテキストトランスファープロトコル（ＨＴＴＰＳ）のセキュアプロトコルを使用して送信されることを含み得る。

００３４ 前記命令は、前記プロセッサによって実行された場合、前記サーバへの／からの前記第１のデータの前記配信速度を、前記ネットワークの現在速度より遅い第１のデータレートに絞ることによって、さらに前記プロセッサに、前記第１のデータの前記配信速度を制御させ得る。

００３５ 前記第１のデータの前記電子トラフィックは、アダプティブビットレートストリームを備え得る。

００３６ 前記第１のデータの前記電子トラフィックは、プログレッシブストリームを備え得る。

００３７ 前記第１のアプリケーションは、マニフェストによって制御される異なる対応する解像度を有する複数のデータレートをサポート可能であり得る。前記命令は、前記プロセッサによって実行された場合、前記データレートのうち第１のデータレートを超える前記データレートを隠す又は取り除くために前記マニフェストを編集することによって、さらに前記プロセッサに、前記第１のデータの前記配信速度を制御させ得る。

００３８ 前記第１のアプリケーションは、異なる対応する解像度を有する複数のデータレートをサポート可能であり得る。前記命令は、前記プロセッサによって実行された場合、前記データレートのうち第１のデータレートを超える前記データレートへのアクセスを失敗又はブロックすることによって、さらに前記プロセッサに、前記第１のデータの前記配信速度を制御させ得る。

００３９ 前記命令は、前記プロセッサによって実行された場合、さらに前記プロセッサに、前記プロセッサ上で動作し、かつ前記ネットワーク経由で前記サーバに／から第２のデータを配信する第２のアプリケーションを特定することと、前記第２のアプリケーションへの／からの前記第２のデータの電子トラフィックを傍受することと、前記第２のアプリケーションへの／からの、又は前記サーバへの／からの前記第２のデータの配信速度を制御することとを行わせ得る。

００４０ 前記命令は、前記プロセッサによって実行された場合、前記第１のデータの前記配信速度が、前記第２のデータの前記配信速度を超えるように、前記第１の及び第２のデータの前記配信速度を同時に制限することによって、さらに前記プロセッサに、前記第１の及び第２のデータの前記配信速度を制御させ得る。

００４１ 前記命令は、前記プロセッサによって実行された場合、前記プロセッサ上で動作している内部プロキシを使用することによって、さらに前記プロセッサに、前記電子トラフィックを傍受させ得る。

００４２ 前記命令は、前記プロセッサによって実行された場合、前記プロセッサ上で仮想プライベートネットワーク（ＶＰＮ）インターフェースを使用することによって、さらに前記プロセッサに、前記電子トラフィックを傍受させ得る。

００４３ 前記命令は、前記プロセッサによって実行された場合、前記プロセッサ上で変更された前記第１のアプリケーションを実行することによって、さらに前記プロセッサに、前記電子トラフィックを傍受させ得るものであり、前記変更された第１のアプリケーションは、前記電子トラフィックの前記傍受を要求するように構成される。

００４４ 添付の図は明細書と共に、本発明の実施形態例を示す。これらの図は以下の説明と共に、本発明の態様及び原則をよりよく説明するのに役立つ。
００４５ 図１は、本発明の一実施形態に従ってオンデバイストラフィック管理の実施と共に使用するのに適したモバイルデバイス例（スマートフォンなど）のアーキテクチャの略図である。 ００４６ 図２は、本発明の実施形態に従ってアプリとサーバの間のネットワークトラフィックの監視及び制御を有効にするためのプロキシ内のソフトウェアコンポーネントのブロック図である。 ００４６ 図３は、本発明の実施形態に従ってアプリとサーバの間のネットワークトラフィックの監視及び制御を有効にするためのプロキシ内のソフトウェアコンポーネントのブロック図である。 ００４６ 図４は、本発明の実施形態に従ってアプリとサーバの間のネットワークトラフィックの監視及び制御を有効にするためのプロキシ内のソフトウェアコンポーネントのブロック図である。 ００４６ 図５は、本発明の実施形態に従ってアプリとサーバの間のネットワークトラフィックの監視及び制御を有効にするためのプロキシ内のソフトウェアコンポーネントのブロック図である。 ００４７ 図６は、本発明の一実施形態に従ってプロキシを通してアプリとサーバの間のリクエストの処理を例示するプロセスタイミング図である。 ００４８ 図７は、本発明の他の実施形態に従ってアプリとサーバの間のネットワークトラフィックの監視及び制御を有効にするプロキシ内のソフトウェアコンポーネントのブロック図である。 ００４９ 図８は、本発明の他の実施形態に従ってプロキシを通してアプリとサーバの間のリクエストの処理を例示するプロセスタイミング図である。

００５０ 本発明の実施形態例は、添付の図を参照して説明される。図では、同じ又は類似の参照番号は、全体を通じて同じ又は類似の要素を示す。ここでは、本発明の実施形態を説明する際の「〜得る、〜してもよい」という用語の使用は、「本発明の１つ以上の実施形態」を示す。さらに、本発明の実施形態を説明する際の「又は」などの代替の言葉の使用は、列挙されている各対応する項目の「本発明の１つ以上の実施形態」を示す。

００５１ １つ以上の実施形態では、モバイルデバイス内のネットワークトラフィックを管理するためのシステム及び方法が提供される。実施形態例は、図１〜図８を参照して説明される。

００５２ 図１は、本発明の一実施形態に従ってオンデバイストラフィック管理の実施と共に使用するのに適したモバイルデバイス例の略図（スマートフォンなど）のアーキテクチャ１００の略図である。例えば、モバイルデバイスは、Androidフォンであってよい。例示の目的で、モバイルデバイスは、Androidスマートフォンであると仮定される。さらに、このようなモバイルデバイスは、多くのユーザをサポートすることが可能とし得る一方、説明を容易にするために、モバイルデバイスが特定のユーザの専用であることが想定されるため、「ユーザ」及び「モバイルデバイス」（又は個人的もしくは携帯可能な態様で使用される任意のコンピューティングデバイス）という用語は、全体を通じて同義語として使用され得る。

００５３ 本発明の１つ以上の実施形態に従って、モバイルデバイス上の汎用アーキテクチャ（例えばアーキテクチャ１００）は、アプリケーション（例えばモバイルアプリ又は単に「アプリ」）から発し、例えば、モバイルデバイスが、例えばＷｉＦｉ又はセルラーネットワークを介してアクセスするアプリケーションサーバ（又はアプリサーバ）２５０までのデータトラフィックを監視又は制御し得る集中型のプロキシ１３０を提供する。このアプローチは、トラフィック管理が複数のネットワーク（例えばＷｉＦｉ及びセルラー）に亘ってかつ複数のアプリに亘って実行されることを可能にし、かつトラフィック管理が中央で管理されることを可能にするが、本発明はこれに限定されない。他の実施形態では、トラフィック管理は、分散型の方法（例えば各アプリ内で動作しているプロキシで）で実行され得るものであり、全体的なデバイストラフィックが効果的に中央で管理されるような調整された態様で動作している。

００５４ スマートフォン１００のアプリ及び他のプログラム可能な構成要素は、例えばスマートフォン１００の非一過性記憶装置に格納されたコンピュータ命令の集合として実装され、スマートフォン１００の１つ以上のプロセッサ上で実行されるように構成され得る。プロキシ１３０はまた、特定のウェブサイトのトラフィックを（例えばウェブブラウザから）管理し得る。従って、説明を容易にするために、「アプリケーション」、「アプリ」、「ウェブサイト」、又は「サイト」などの用語は、プロキシ１３０によって管理されているコンテンツのカテゴリーを示す場合、本出願全体に亘ってほぼ置き換え可能に使用され得る。

００５５ プロキシ１３０は、いくつかの異なる機構（例えば、ソケットレイヤー１２０を使用するプロキシサーバ（例えばオペレーティングシステム（ＯＳ）ネットワーク設定を介して）、ネットワークトンネル（ＴＵＮ）デバイス２３０を使用する仮想プライベートネットワーク（ＶＰＮ）サービス（例えばＯＳネットワーク設定を介して）、又は傍受レイヤー１５０を使用するアプリ内に埋め込まれる）から確保され得る。プロキシ１３０は、Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）１６０上で実行され得る。プロキシは、フラッシュメモリ１７０又は他の非揮発性記憶装置などの物理記憶装置上のキャッシュされたコンテンツを管理するためのキャッシュエンジン１１０を含み得る。一般性を失うことなしに、このようなデバイスは、時に「ディスク」と呼ばれ得るが、これはソリッドステートドライブなどあらゆるタイプの非一過性記憶装置であり得る。さらに、キャッシュされた又は任意の他の格納されるコンテンツは、全体又は一部が、揮発性ストレージ（ランダムアクセスメモリなど）上に格納されてよく、この揮発性ストレージは、非揮発性ストレージと組み合わせて使用してもよく、例えば、階層式の態様では、最も最近アクセスされたコンテンツが、より低速の非揮発性ストレージに移行する前に、より高速の揮発性ストレージに格納される。

００５６ プロキシ１３０は、多様な形式の要素（例えばアプリケーション、カーネルドライバ、又はモバイルデバイス上のＯＳ内）で動作し、ネットワーク接続（例えばＯＳネットワーク設定経由で）を受信するように構成され得る。１つ以上の実施形態では、プロキシサーバは、ＪＶＭで動作し得る。プロキシ１３０は、クライアントアプリケーションの代わりに中間物として機能し得る。例えば、プロキシ１３０は、別のＪＶＭ１６５で動作しているアプリ１８０のリクエストにサービスを提供し得る。

００５７ アプリ１８０は、例えば、Ｈｔｔｐ ＵＲＬ接続１９０などのAndroidサービスを使用してインターネットにアクセスし得る。ここで、ＨＴＴＰは、ハイパーテキストトランスファープロトコルの略であり、ＵＲＬは、ユニフォームリソースローケーター（例えばウェブアドレス）である。Ｈｔｔｐ ＵＲＬ接続１９０は、次に、インターネットにアクセスするためにネットワークサービス２００を呼び出し得る。ネットワークサービス２００は、例えば、アクセスポイント名（ＡＰＮ）２１０（例えば３Ｇなどのモバイルネットワーク）又はＷｉＦｉ接続２２０を使用してインターネットにアクセスし得る。ネットワークサービス２００は、システムに、又はＡＰＮもしくはＷｉＦｉ接続にグローバルに適用されるプロキシ構成を使用して、アプリ１８０からプロキシサーバ１３０にリクエストをルーティングするように構成され得る。ネットワークサービス２００はまた、他の多様な方法（例えばネットワークトンネル（ＴＵＮ）デバイス２３０又はＩＰルーティングテーブル（「ＩＰテーブル」ともいう）を介して）を使用して、アプリ１８０からプロキシ１３０にリクエストをルーティングし得る。

００５８ ネットワークサービス２００は、インターネットにアクセスするために、プロキシを直接的又は間接的に（例えば、デバイス上で動作しているアプリによって直接的に、又はＡＰＮ２１０又はＷｉＦｉ接続２２０上の設定を通して間接的に検出かつ使用されるグローバルシステムプロキシとして）指定するように構成され得るものであり、これによって、リクエストが、標準的な通信レイヤー、例えば、ソケット１２０（例えばインターネットに接続するためのネットワークソケット）を通して送信されて、プロキシ１３０によって受信され得る。プロキシ１３０は、今度は、ネットワークサービス２００を通してアプリサーバ２５０にリクエストしてよく（プロキシ１３０自体にループバックすることを避けるためにＡＰＮ又はＷｉＦｉプロキシ構成をバイパスする間に）、当該ネットワークサービス２００は、リクエストにサービスを提供し、あらゆる応答通信をプロキシ１３０に返す。プロキシは次に、アプリとサーバの間の通信を監視又は制御し得る。プロキシ１３０はまた、反対に、上述の同じステージを通してネットワークソケット１２０を介してアプリ１８０に応答を返す前に、キャッシュエンジン１１０を介して応答の一部、ゼロ、又は全部をキャッシュし得る。

００５９ ＡＰＮ又はＷｉＦｉ接続上でプロキシ構成を使用する代わりに、ネットワークサービス２００はまた、多様な他の手段を通してリクエストをプロキシサーバ１３０にルーティングするように構成され得る。例えば、別のアプローチは、ＶＰＮ接続を確立するためにネットワークトンネル（ＴＵＮ）２３０を使用することであり、これは、ネットワーク送信を処理するためにネットワーク活動をＶＰＮサービス１４０にルーティングし得る。ＶＰＮサービス１４０は次に、リクエストにサービスを提供し、かつネットワークトンネル２３０を介して応答を返すために、ソケット１２０（適宜）を使用してアプリとアプリサーバ２５０の間のトラフィックを管理するためにリクエストをプロキシ１３０にルーティングし得る。

００６０ プロキシ１３０を確保するための別の機構は、トラフィックをプロキシプロセスにリダイレクトするためにアプリ内の傍受レイヤー（例えば傍受レイヤー１５０及び１５５）を使用することである。例えば、上記の例では、インターネットにアクセスするために、Ｈｔｔｐ ＵＲＬ接続１９０に、ネットワークサービス２００を呼び出させる前に又はその代わりに、Ｈｔｔｐ ＵＲＬ接続は、傍受レイヤー１５０にアプリ１８０からのリクエストを傍受させ、かつそのトラフィックをプロキシ１３０に直接転送させてよい。インターセプト１５０からプロキシ１３０への転送は、当業者には明らかなように、ネットワークサービス２００を通して又標準的なプロセス間通信機構（例えば、メッセージキュー、名前付きパイプ、又は共有メモリ）を使用して実行され得る。

００６１ 別個のプロセス（例えばＪＶＭ１６０内）で動作するプロキシ１３０に加えて、他の実施形態では、プロキシ１３０は、リクエストのプロセス（例えばＪＶＭ１６５又はブラウザ１８５（ウェブブラウザなど））内に埋め込まれ得る。プロキシ１３０は次に、プロセス間通信の必要なしにアプリのネットワークトラフィックを管理し得る。

００６２ 別の例では、ウェブブラウザ１８５は、インターネットへのアクセスを探す。上記のアプリ１８０と同様に、ウェブブラウザ１８５は、いくつかの異なるアプローチによってプロキシ１３０を利用し得る。例えば、ウェブブラウザ１８５は、ネットワークソケット１２５を使用してインターネットにアクセスするように構成され得るもので、ネットワークソケット１２５は次に、例えば、上記のようにソケット１２０又はＶＰＮサービス１４０を使用して、アプリサーバ２５０及び／又はプロキシ１３０にアクセスするためにネットワークサービス２００を使用し得る。同様に、傍受レイヤー１５５は、ウェブブラウザ１８５に追加されてもよく、これは、ウェブブラウザ１８５からのリクエストを傍受し、そのトラフィックをプロキシ１３０に転送し得る。

００６３ さらに詳細には、上記の技術は、セキュアソケットレイヤー（例えば暗号化されているＳＳＬ）通信と非ＳＳＬ（例えば暗号化されていない）通信の間の可能な分化により、既存のインターフェースに統合され得る。アプリケーションとの統合は、例えばネットワークスタックの中央の位置で、非ＳＳＬ通信のために有効にされ得る。例えば、プロキシ１３０は、ネットワークプロトコルのすべて又はサブセットのためのプロキシとして構成され得る（例えばＨＴＴＰ、ＨＴＴＰＳのみについて、又は両方）。同様に、プロキシ１３０は、ネットワークインターフェースのすべて又はサブセット用のプロキシとして構成され得る（例えばセルラー、ＷｉＦｉ、又は両方について）。例えば、ＡＰＮ２１０アクセスでは、セルラーアクセスポイントは、プロキシ１３０に設定され得る。ＩＰテーブルアクセスでは、対応するインターネットプロトコル（ＩＰ）ルーティングテーブルのエントリが設定され得る。ＶＰＮサービスでは、ＶＰＮクライアント（ＶＰＮサービス１４０など）は、トラフィックをプロキシ１３０にルーティングし得る。ＷｉＦｉでは、プロキシ１３０は、各ＷｉＦｉアクセスポイント（ＡＰ）のために設定され得る。グローバルシステムプロキシでは、システムは、すべてのアプリケーショントラフィックのトラフィックをプロキシ１３０に向け得る。

００６４ さらに、ＳＳＬ又はＴＬＳなどの暗号化された通信を使用するアプリケーションとの統合は、暗号化されていないネットワークデータへのアクセスを必要とし得る。ここで使用され得るいくつかのアプローチが存在する。中間者のアプローチでは、暗号化されたデータへのアクセスは、信頼された認証局（ＣＡ）を介してサーバになりすますことによって取得され得る。ソフトウェア開発キット（ＳＤＫ）アプローチ（例えば図１の傍受レイヤー１５５での）では、キャッシュエンジン１１０へのフックとの実装時間リンキングは、暗号化レイヤーの上で使用され得る。再リンクのアプローチでは、既存のアプリは、Ｈｔｔｐ ＵＲＬ接続１９０などで、カスタムリプレースメントアプリケーションプログラミングインターフェース（ＡＰＩ）を使用するために逆コンパイルかつ再リンクされ得る。代替のアプローチ（例えばウェブブラウザ１８５などのブラウザを使用して）では、アプリの代わりのバージョンを提供してもよく、ここでは傍受が既に組み込まれている。これは、幅広く使用されているオープンソースのアプリに特に適し得る。

００６５ 図１は主にモバイルデバイスのアーキテクチャ１００を対象としているが、オンデバイストラフィック管理はまた、他の構成要素（例えばモバイルデバイス１００の１つ以上のプロセッサ上で動作するように構成されたソフトウェアコンポーネント）を含み得る。図２〜図５は、本発明の実施形態に従ってアプリ３１０とサーバ２５０の間のネットワークトラフィックの監視及び制御を可能にするためのプロキシ１３０内のソフトウェアコンポーネントのブロック図である。

００６６ 図２では、モバイルデバイス１００内で動作しているアプリ３１０は、アプリサーバ２５０と通信し、プロキシ１３０は、上述の方法のいずれかを使用して（例えばシステムプロキシ設定又はＶＰＮを通して）アプリのネットワークトラフィックを傍受するだろう。プロキシ１３０内では、本発明の１つ以上の実施形態では、ネットワークトラフィックの監視及び制御を実行する論理的なソフトウェアコンポーネントが存在し、これらのソフトウェアコンポーネントは、アプリ３１０でデータパス３２５を処理し得るクライアントハンドラ３２０と、アプリサーバ２５０でデータパス３３５を処理し得るリクエストハンドラ３３０とを含み得る。

００６７ アプリ３１０とクライアントハンドラ３２０の間のデータパス３２５は、アプリのネットワークトラフィック（例えば、当業者には明らかであるネットワークソケット又は任意の他の標準的なプロセス間通信機構）を傍受するために使用される方法次第で異なる機構において生じ得る。リクエストハンドラ３３０とアプリサーバ２５０の間のデータパス３３５はまた、アプリ３１０が通常アプリサーバ２５０と通信する方法次第で（例えばＴＣＰ／ＩＰを使用しているネットワークソケットで）異なる機構において生じる。アプリ３１０との内部データパスと、アプリサーバ２５０との外部データパスを切り離すことによって、プロキシ１３０がアプリ３１０とアプリサーバ２５０の間のデータレートを別々に制御することを可能にする（例えば、実際にアプリサーバ２５０に／から（データパス３３５経由で）配信され得るよりも遅い速度で、アプリ３１０に／から（データパス３２５経由で）データを配信するために）。

００６８ 本発明の他の実施形態に従って、ビットレートマネージャ３４０は、アプリ３１０への／からの、又はアプリサーバ２５０への／からの適切なビットレート（データレートとして知られる）を管理するために使用され得る。これにより、個別のソフトウェア部品が、ビットレートについての１つ以上のポリシー（例えば、異なるユーザのための異なるビットレート、異なるアプリのための異なるビットレート、事前のデータ消費に基づいた異なるビットレート、異なるネットワークタイプのための異なるビットレート、及び当業者には明らかであろうその他のバリエーション）を実施することを可能にする。異なるユーザのためにビットレートを実施するポリシーは、ユーザのリスト又はユーザのカテゴリーで構成してよく、ユーザのカテゴリーは、任意のグループのユーザであってよい（例えばデバイスのタイプ（例えばスマートフォン対タブレット）、デバイスモデル、又はデータ計画によるグループなど）。異なるアプリのために異なるビットレートを実施するポリシーは、アプリ又はアプリのカテゴリー別のビットレートのリストを含んでよく、アプリのカテゴリーは、アプリの任意のグルーピング（例えば機能別（例えば動画、ソーシャル、メールなど）、ベンダー別、又は他のいくつかの他のカテゴリー別（例えば仕事対パーソナル））であってよい。

０００１ アプリに基づくポリシーはまた、アプリがいかにかついつ動作するかに基づいてよく、例えば、当該アプリがユーザにとって可視である（例えば、バックグラウンドではなくフォアグラウンドで動作している）場合、より高いビットレートを可能にし、又は高優先度のアプリが動作している場合、低優先度のアプリ用はより低いビットレートを強制するなどとしてよい。異なるネットワークタイプ用に異なるビットレートを実施するためのポリシーは、ネットワークタイプ毎のビットレートのリスト（例えばＷｉＦｉ、ＬＴＥ、ＨＳＰＡ、ＣＤＭＡなど）又は特定のネットワーク（特定の携帯電話の基地局又はＷｉＦｉホットスポットなど）のリストを含み得る。ネットワークに基づくポリシーはまた、ネットワークに関連する所有権又はコストに基づいてよく、例えば、ユーザのデータ計画のオペレータが所有するホームネットワークにアクセスする場合には、より高いビットレートであるが、当該ユーザが別のオペレータが所有するネットワーク上でローミングしている場合には、より低いビットレートとしてよい。

００６９ ビットレートマネージャによって管理されている速度制限は、ちょうどビットレベルであることに制限されず、他の増加量又は単位でのトラフィックの速度に対する制限（例えば、リクエスト、パケット（例えばＴＣＰセグメント又はＩＰパケット）、ネットワーク接続、又は当業者に明らかであるその他の粒度によってなど）も含み得る。例えば、特定のネットワークタイプが引き起こす可能性がある混雑を制御／最小化するために、特定のネットワークタイプに対する「チャティな」アプリによるリクエストの頻度を制限することが望ましいかもしれない。なぜならば、いくつかのタイプのネットワーク（例えば２Ｇ及び３Ｇのセルラーネットワーク）は、同時にサポートできる限られた数の接続を有し得るからである。

００７０ 上記のポリシーのいずれも、例えば、ユーザによって提供され、アプリによって事前構成され、又は管理サーバなどの外部システムから受信され得る。また、上記のポリシーのいずれも、複数又は多様な速度制限（例えば以前のデータ使用又はトラフィック活動に基づいて変化する速度制限）を有するように拡張され得る。例えば、アプリに基づくポリシーは、アプリのデータ消費が増えるにつれて減少する複数のビットレートレベルを可能にし得るもので、例えば、より低いデータ消費のアプリは、より高い（又は無制限でさえある）ビットレートで動作することを可能にし、一方で、より高い帯域幅アプリが１つ以上の閾値を上回った場合には、当該より高い帯域幅アプリを制限するなどしてよい。

００７１ 例えば、アプリ３１０がアプリサーバ２５０からデータを受信するリクエストを実行すると、リクエストは、最初にクライアントハンドラ３２０によって受信されることになり、このクライアントハンドラ３２０は、次にリクエストを処理するために必要とされる適切なタイプのリクエストハンドラ３３０に当該リクエストを渡す。プロキシ１３０は、１つ以上のタイプのリクエストハンドラ（例えば、リクエストをアプリサーバ２５０に渡し得る、図３のパススルーハンドラ３３１）をサポートし得る。別のタイプのリクエストハンドラは、キャッシュされたデータの鮮度を検証するのに必要なキャッシュエンジン１１０及びアプリサーバ２５０と相互作用することによって、キャッシュからのコンテンツでリクエストに応答し得る、図４のサーブフロムキャッシュハンドラ３３２であってよい。さらに他のタイプのリクエストハンドラは、例えば、他の態様では外部ネットワークもしくはサーバによってサポートされ得る速度よりも低い速度でリクエストデータを送信し、又は応答データを受信することによって、アプリサーバ２５０でデータパスの速度を制御し得る、図５のスロットリングハンドラ３３３であってよい。本発明の一実施形態では、各タイプのリクエストハンドラは、リクエストハンドラスーパークラスのサブクラスとして実装され得る。リクエストハンドラは、リクエストに応答し、かつクライアントハンドラ３２０に応答を提供することを担当し、クライアントハンドラ３２０は次に応答をアプリ３１０に送信する。

００７２ クライアントハンドラ３２０は、リクエストハンドラから応答データを受信すると、応答データをアプリ３１０に送信し得るものであり、クライアントハンドラ３２０は、ビットレートマネージャ３４０によってクライアントハンドラ３２０に提供される速度制限に基づいて、当該データがいかに迅速に送信されるかを制御し得る。クライアントハンドラ３２０は、当事者には明らかな多様な方法で（例えば応答全体が送信されるまで時間間隔毎に特定の量を送信することによって）速度制限を実施し得る。本発明の一実施形態では、クライアントハンドラ３２０は、データをアプリ３１０に毎秒送信するように構成され得るので、データがアプリサーバ２５０から受信される場合、クライアントハンドラ３２０は、ビットレートマネージャ３４０によって指定される秒単位の速度制限を上限とした量で、毎秒データを送信する。例えば、ビットレートマネージャ３４０が、アプリ３１０のデータレートを１０００キロビット／秒に制限すべきであることをクライアントハンドラ３２０に示す場合、クライアントハンドラ３２０は、応答全体が送信されるまで、毎秒最大１０００キロビットをアプリ３１０に送信する。これにより、リクエストハンドラ３３０が、クライアントハンドラ３２０がそのデータをアプリ３１０に送信している速度と異なる（例えば当該速度よりも速い）速度でアプリサーバ２５０からデータを受信することを可能にする。

００７３ リクエストハンドラ３３０は、クライアントハンドラ３２０がデータをデバイスメモリ（揮発性でも非揮発性でもよい）に格納することによって、当該データをアプリ３１０に送信する速度よりも速い速度で、アプリサーバ２５０からデータを受信し得る。非揮発性メモリはより豊富であってよく、大量のデータがバッファされる必要がある場合に、例えば、クライアントハンドラ３２０がアプリ３１０に送信している速度よりもはるかに速い速度で、データがアプリサーバ２５０から受信されている場合に、非揮発性メモリを使用してよい。本発明の一実施形態に従って、スロットリングハンドラ３３３は、クライアントハンドラ３２０がまだデータをアプリ３１０に送信する準備ができていない場合、アプリサーバ２５０から受信したデータの一部を非揮発性メモリに格納するために、バッファリングを管理し得る。スロットリングハンドラ３３３はまた、例えばデバイス上で利用できるメモリ又はストレージを超えることを避けるために、アプリサーバ２５０からどのくらいの量のデータをいかに速く受信するかを制限し得る。

００７４ 例えば、データパス３３５は、ＴＣＰベースのネットワークソケットであってよく、スロットリングハンドラ３３３は、ネットワークソケットからデータを受信するのを中止し得るもので、これにより、そのネットワークソケット上のＴＣＰ受信ウィンドウがフルである場合、アプリサーバ２５０がデータを送信するのを中止させる。リクエストハンドラ（例えばスロットリングハンドラ）は、アプリサーバ２５０からデータを受信する速度を決定するために、アプリサーバ２５０から受信したデータを分析し得る。

００７５ いくつかの場合では、データが実際に動画アプリによって消費される速度で動画データを受信することが望ましいかもしれない（例えば、ユーザが動画を視聴するのを止めた（但し受信は続ける）場合に、消費されない動画データを受信するのを避けるために）。このアプローチは、異なるタイプのアプリに適用され得る。なぜならば、アプリがデータを消費する速度と、ネットワーク／サーバがそのデータを配信できる速度との間には、一般的にほとんど又は全く関係がないからである。例えば、ＭＰＥＧ−４動画は、モバイルデバイスが現在ネットワーク／サーバからその動画データを受信し得る速度よりも低いビットレートで暗号化され得る（例えば、当該デバイスが、混雑していないセルサイトで良好なセルラー信号を有する場合など）。従って、ＭＰＥＧ−４動画が２ｍｂｐｓのビットレートで符号化され、デバイスがそのデータを４ｍｂｐｓで受信している場合、もしもユーザが動画全体を視聴しないのであれば、かなりの量の受信動画データ（例えば、５０％）が浪費される可能性がある。本発明の１つ以上の実施形態は、動画符号化ビットレートをネットワーク配信ビットレートに合わせることによってこれに対処し得る。

００７６ 本発明の一実施形態に従って、プロキシ１３０は、アプリサーバ２５０から受信したデータを構文解析することによって動画及びネットワークビットレートの調整を行い得る。アプリ３１０がアプリサーバ２５０から動画を要求した場合に、スロットリングハンドラ３３３は、動画符号化ビットレートを決定するために、受信したデータを構文解析してよく、スロットリングハンドラ３３３は、アプリサーバ２５０からデータを受信する速度を決定するために、この動画符号化ビットレートを使用し得る。例えば、前の例を用いると、スロットリングハンドラ３３３が２ｍｂｐｓで符号化された動画を検出した場合、スロットリングハンドラ３３３が同等の速度で（おそらくはネットワーク配信速度のあらゆる周知の／検出されたバリエーションに対応するために、わずかにより高く調整された速度で）アプリサーバ２５０からデータを受信することを確保し得る。

００７７ データ配信の速度をアプリ３１０に制限することによって、本発明の実施形態は、速度に基づいてデータサイズを調整するコンテンツ（例えば、アダプティブビットレート（ＡＢＲ）動画ストリームなど）のデータ消費を減らし得る。ＡＢＲストリーミング技術の例は、ダイナミックアダプティブストリーミング・オーバーＨＴＴＰ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）（ＤＡＳＨ）、Ｆｌａｓｈ用Ａｄｏｂｅアダプティブストリーミング（Ａｄｏｂｅ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｆｏｒ Ｆｌａｓｈ）、ＨＴＴＰライブストリーミング（ＨＬＳ）、及びマイクロソフト・スムーズストリーミング（Ｍｉｃｒｏｓｏｆｔ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ）を含む。例えば、ＹｏｕＴｕｂｅ（登録商標）動画は、幅広い種類の動画解像度のために暗号化され、各動画解像度は特定のデータ配信速度に対応し、よって、ＹｏｕＴｕｂｅアプリは、その認識されたデータ配信の速度によってサポートされ得る最も高い動画解像度を要求する。下の表は、各動画解像度の質に対応するＹｏｕＴｕｂｅアプリの推定データ使用率を示し、ここで、認識されたネットワーク速度がその動画に対応するデータ使用率を上回る場合にのみ、ＹｏｕＴｕｂｅアプリは解像度を選択する。プロキシ１３０は、望ましい動画解像度の又は少し上のビットレート制限を使用することによって、どの解像度がＹｏｕＴｕｂｅアプリによって選択されるのかを効果的に制御する。

００７８ ビットレート制限をＡＢＲストリームに適用した結果、データ消費全体が、動画の遅延やバッファリングを引き起こすことなしに、最も高い可能な解像度と比較して９０％以上まで、大きく削減され得る。唯一の影響は、より低い解像度の動画に対してであろう。また、ユーザは、そのデータ使用コストを節約するために、より低い解像度の動画を望んで見るかもしれない。表に示されるように、データ使用の違いは各解像度レベルの間で大きく、一般に解像度の対応する増加よりも速く増加する。例えば、３６０ｐから７２０ｐへの解像度の２倍の増加は、データ消費の３.４倍の増加につながる。解像度レベルを１つだけ下げただけで、データ使用は大きく減り得るものであり、例えば、１０８０ｐから７２０ｐへの解像度の減少は３３％であるが、データ使用の減少は５３％である。小型のモバイルデバイスでは、これは、ユーザにとってはほとんど識別できない目に見える質の差となり得るが、５０％以上のデータの節約を提供する。

００７９ 図６は、本発明の一実施形態に従ってプロキシを通したアプリとサーバの間のリクエストの処理を示しているプロセスタイミング図である。図６は、例えばセルラー接続のデータ消費を削減するために、ビットレートが制限されている本発明の一実施形態を示す。アプリ３１０がアプリサーバ２５０からデータ（動画など）のリクエストを実行すると、リクエストは、ステップ４１０でクライアントハンドラ３２０によって傍受される。クライアントハンドラ３２０は、当該リクエストをいかに処理するかを決定してよく、又はクライアントハンドラ３２０は、決定を行うためにリクエストマネージャ３５０にリクエストを提供し、リクエストマネージャ３５０は、リクエストを処理するためにスロットリングハンドラ３３３を割り当ててもよい。スロットリングハンドラ３３３は、適用する適切なビットレート制限（例えば、アプリ、ネットワークタイプ、又はリクエストされているデータのタイプと関連するポリシーに基づいてなど）を決定するために、ステップ４１５でビットレートマネージャ３４０と協議し得る。クライアントハンドラ３２０は、ステップ４２０でスロットリングハンドラ３３３にリクエストを送信し、スロットリングハンドラ３３３は、リクエストを処理するためにアプリサーバ２５０との相互作用を処理する。

００８０ アプリサーバ２５０がステップ４２５でリクエストに対する応答の送信を開始すると、スロットリングハンドラ３３３は、例えばサーバからデータを受信すべきである速度を決定するために、応答を構文解析し得る。応答データがアプリサーバ２５０から受信されると、スロットリングハンドラ３３３は、ステップ４３０で、揮発性ストレージ、非揮発性メモリ、又はその組み合わせのいずれかに応答データを格納し得る。データがアプリサーバ２５０から受信されると、クライアントハンドラ３２０は、ステップ４３５で、格納された応答データをアプリ３１０に送信し得るものであり、これは、スロットリングハンドラ３３３によってアプリサーバ２５０から受信される速度とは異なる速度で起こり得る。これは、ステップ４４０で最初のリクエストに対して追加の応答データが受信される場合に継続する。応答が完了すると、アプリ３１０は、ステップ４４５で後続のデータについての（例えば、ＨＴＴＰ ＵＲＬを介して個々にアドレス可能であり得る別々の時間に基づくチャンクに分割されるＡＢＲ動画ストリームについての）追加のリクエストを発行し続け得る。図６は、一部の当業者には明らかであるように、アプリ３１０によって要求されたデータが完了するまで継続すると仮定され得る。

００８１ 本発明の他の実施形態に従って、ビットレート制限は、他の手段で（例えばアプリサーバ２５０によってレポートされているストリームのリストを変更することによって）制御され得る。例えば、ＡＢＲストリーミングアプローチのいくつかは、サーバに、マニフェストと呼ばれるリストを介して、アプリに対して利用可能なストリームを通知させることに依存する。動画が最初にリクエストされると、アプリは、サーバからマニフェストを取得し、再生するストリームを選択し、この選択は、典型的にはアプリによって認識されるネットワーク速度に基づくこととなる。従って、ビットレートを制御する別のアプローチは、例えば利用可能なストリームをアプリに制限するために、サーバから受信されるマニフェストを変更することである。例えば、アプリ３１０がアプリサーバ２５０からマニフェストをリクエストする場合、プロキシ１３０は、マニフェストをアプリ３１０に送信する前に、マニフェストを変更し、マニフェストからより高解像度の動画ストリームを取り除き、これによってアプリ３１０を、マニフェストに残っているストリームを再生可能とすることのみに制限し得る。これにより、プロキシ１３０が、ビットレートマネージャ３４０が指定するポリシー内で許可されるストリームにアプリ３１０を制限することを効果的に可能にする。このアプローチは、サーバがクライアントへの複数のストリームを提供又は宣伝するあらゆるストリーミングアプローチに適用され得るものであり、この場合、利用可能なストリームのセットは、本発明の実施形態によって後で変更され得る。

００８２ 本発明の他の実施形態に従って、ビットレート制限が制御され得る別の手段は、サーバによって提供又は宣伝されるストリームのセット内の１つ以上のストリームへのアクセスを拒否又は他の方法でブロックすることである。例えば、プロキシ１３０は、アプリ３１０によってリクエストされる１つ以上の利用可能なストリームへのアクセスを許可してよく、その一方で他のストリームへのアクセスをブロックし、これによって、プロキシ１３０が、ビットレートマネージャ３４０によって指定されるポリシー内で許可されるストリームにアプリ３１０を制限することを効果的に可能にする。ストリームへのアクセスをブロックし得る多様な方法（接続を拒否すること、リクエストに対するエラーを返すこと、又はリクエストがタイムアウトすることを許可することを含む）が存在する。このアプローチは、それをサポートする特定のアプリに選択的に適用され得る。なぜならば、特定のブロックの機構を適切にサポートできないアプリもあり、また、特定の方法でブロックされる必要があるアプリもあり得るからである。

００８３ 本発明の他の実施形態に従って、プロキシ１３０は、データがアプリサーバ２５０からデバイスによって受信されるサイズ又は頻度が、アプリ３１０が他の態様でデータを要求又は受信し得る方法とは異なるように、データをバースト受信することをサポートし得る。例えば、ユーザは動画全体を見ないかもしれないので、動画が見られている間に、その動画の次の部分だけ（例えば５分のプログレッシブ動画全体ではなく次の３０秒間）をダウンロードすることが望ましい。このような場合は、例えば、高速ネットワーク及び高速サーバは、ユーザが１０秒だけを見たとしても、５分の動画全体をダウンロードすることを可能にしてしまうかもしれず、そのすべてが、なおもユーザのデータ計画に不利に作用する。

００８４ その一方で、一度にあまりに少量の動画（例えば、ＡＢＲ動画では一般的であるが、一度に次の７秒だけなど）をダウンロードすることは望ましくなく、それは、セルラーラジオ及び接続が常にアイドル状態になることを防ぐからである。この場合、その非活動タイマーは、毎回ダウンロードされる動画の量（例えば５秒）よりも長い（例えば１５秒）ので、セルラーラジオは、アクティブで高パワーモードに留まり得る。セルラーネットワークでは、これは、携帯電話の基地局の信号送信、混雑、及びデバイスバッテリー消費の増加につながり得る。消費されていないデータを浪費することを避けために、あまりに多くダウンロードせずに、セルラーラジオがアイドル状態になることを可能にするのに十分なくらいのダウンロードの間のバランスを取るように、ネットワークのタイプと実際の速度によっては、異なるバーストサイズでデータを受信することが望ましいこともある。

００８５ 図７は、本発明の他の実施形態に従ってアプリ３１０とサーバ２５０の間のネットワークトラフィックの監視及び制御を可能にするためのプロキシ１３０内のソフトウェアコンポーネントのブロック図である。図７は、バースティングハンドラ３３４が、アプリサーバ２５０からデータを要求又はバースト受信するために提供されるタイプのリクエストハンドラであり、よって、他の場合ではプロキシ１３０又はバースティングハンドラ３３４なしでアプリ３１０によって行われるのと異なる量又は異なる頻度で、上記データが要求又は受信され得る、本発明の一実施形態を示す。バースティングハンドラ３３４は、データパス３２５でアプリ３１０に／からデータを送信／受信しているクライアントハンドラ３２０から独立して、データパス３３５でアプリサーバ２５０からデータを要求する。バースティングハンドラ３３４は、多様な要因に基づいて（例えば効率及び性能を改良又は最大化するために）、アプリサーバ２５０からデータを要求／受信するための適切な速度を決定するためにビットレートマネージャ３４０と調整を行い得る。

００８６ 例えば、セルラー接続のアイドル時間を増やす又は最大化する要因は、ネットワークタイプ（例えばＬＴＥ、ＥＤＧＥなど）、効果的なネットワーク速度、ネットワーク非活動タイマー（例えば１５秒）、及び動画符号化ビットレートを含み得る。さらなる例として、下記の式を使用した望ましいネットワークアイドル時間、ネットワーク配信ビットレート、及び動画符号化ビットレートに基づいて必要とされるバーストサイズを、以下の通り計算し得る。
＜望ましいアイドル時間＞／＜ビットレート率＞＊＜動画符号化ビットレート＞＝＜バーストサイズ＞

００８７ ここで、ビットレート率は、動画符号化ビットレートとネットワーク配信ビットレートとの比率である（例えば、動画が２ＭＢ／秒で暗号化され、ネットワークからのデータ配信速度が４ＭＢ／秒である場合の０．５の値）。例えば、この同じビットレート率では、望ましいアイドル時間が４５秒である場合（例えば、１５秒の非活動時間ウィンドウの後に３０秒の休止時間ウィンドウが続くことを可能にするために）、バーストサイズが以下のように計算される。
４５秒／０.５＊２ＭＢ／秒＝１８０ＭＢ

００８８ 注記すべき点として、他の理由（例えば、デバイスのバッテリーの寿命を改良するため、動画ストリームの失速を避けるため、又は当業者には明らかである他のシナリオ）によりバーストサイズを決定するために、追加の要因が考慮され得る。

００８９ 図８は、本発明の他の実施形態に従ってプロキシ１３０を通してアプリ３１０とサーバ２５０の間のリクエストの処理を例示するプロセスタイミング図である。図８は、例えば、セルラー接続のためのアイドル時間を増やす又は最大化するために、バースティングが実行される本発明の一実施形態を示す。アプリ３１０がアプリサーバ２５０からのデータ（例えば動画）を要求すると、当該リクエストはクライアントハンドラ３２０によって傍受される。クライアントハンドラ３２０は、当該リクエストをいかに処理するかを決定するか、又はクライアントハンドラ３２０は、決定するためにステップ５１０でリクエストマネージャ３５０にリクエストを提供し、リクエストマネージャ３５０は、リクエストを処理するためのバースティングハンドラ３３４を割り当て得る。クライアントハンドラ３２０は、ステップ５１５でバースティングハンドラ３３４にリクエストを送信し、バースティングハンドラ３３４は、リクエストを処理するためにアプリサーバ２５０との相互作用を処理する。

００９０ アプリサーバ２５０がステップ５２０でリクエストに対する応答の送信を開始すると、バースティングハンドラ３３４は、例えば、サーバからデータを受信すべき速度を決定するために、応答を構文解析し、かつデータがアプリ３１０に送信されるべき速度を設定するためにクライアントハンドラ３２０と調整を行い得る。応答データがアプリサーバ２５０から受信されると、バースティングハンドラ３３４は、ステップ５２５で、揮発性メモリ、非揮発性メモリ、又はその組み合わせのいずれかに応答データを格納し得る。バースティングハンドラ３３４は、バーストサイズを計算し、ポリシーに基づいて（例えば、最短セルラーアイドル時間を達成するなど）ステップ５３０で決定されたバーストサイズまで追加のデータを受信し始めてよい。データストリームが１つ以上の個々にアドレス可能なチャンクのデータを含む（例えば、各々がＨＴＴＰ ＵＲＬを介して個別にアドレス可能である）場合、バースティングハンドラ３３４は、最大ターゲットバーストサイズまでのデータを受信するために必要なリクエストを発行し得る。

００９１ データのターゲットバーストサイズが受信されると、バースティングハンドラ３３４は、次にステップ５３５でデータの受信を中止し（関連するネットワーク接続（例えばＴＣＰ接続）を閉じることを含み得る）、これにより、ターゲットアイドル時間の開始を始める。データがアプリサーバ２５０から受信されると、クライアントハンドラ３２０は、ステップ５４０で、格納された応答データをアプリ３１０に送信し、これは、バースティングハンドラ３３４によってアプリサーバ２５０から受信された速度とは異なる速度で起こり得る。これは、第１のバーストで受信されたデータがアプリ３１０に送信されるまで、必要に応じてステップ５４５及びそれ以降まで続く。次のバーストが開始する準備ができると、バースティングハンドラ３３４は、ステップ５５０で、アプリサーバ２５０から後続のデータをリクエストすることを開始し、クライアントハンドラ３２０のためにステップ５５５で次のバーストの格納を開始してよく、クライアントハンドラ３２０は次に、バースティングハンドラ３３４によってアプリサーバ２５０から受信された際の速度とは異なり得る速度で、後続の応答データをアプリ３１０に送信してよい。図８は、一部の当業者には明らかであるように、アプリ３１０によって要求されたデータが完了するまで継続すると仮定され得る。

００９２ 本発明は特定の実施形態例との関連で説明してきたが、本発明は開示された実施形態だけに限定されるのではなく、逆に、当業者には明らかなように、以下の請求項及びその同等物によって定義される発明の精神及び範囲から逸脱せずに、多様な変更及び同等のアレンジメントを網羅することを意図していることを理解すべきである。

Claims (26)

1. コンピュータプロセッサと、ネットワーク経由で前記プロセッサとの間でデータを送受信するためのサーバへのネットワーク接続とを有するポータブル通信デバイスにおける、通信トラフィック管理方法であって、
   前記プロセッサ上で動作しているトラフィックマネージャアプリケーションによって、前記プロセッサ上で動作し、かつ前記ネットワーク経由で前記サーバに／から第１のデータを配信する第１のアプリケーションを特定することと、
   前記トラフィックマネージャアプリケーションによって、前記第１のアプリケーションによって要求される動画データであって、前記ネットワークを経た第１の配信速度で前記サーバから受信した動画データを含む前記第１のデータの電子トラフィックを傍受することと、
   前記トラフィックマネージャアプリケーションによって、前記トラフィックマネージャアプリケーションと前記第１のアプリケーションとの間の内部ネットワークデータ経路を経た前記第１のアプリケーションへの前記動画データの第２の配信速度であって、特定の目標動画解像度に対応する第２の配信速度を制限することと、
   を含む方法。
2. 前記第１のデータの前記配信速度の前記制御は、前記第１のアプリケーションによって認識される前記ネットワークの現在速度を、前記ネットワークの前記現在速度より遅い第１のデータレートに絞ることを含む、請求項１に記載の方法。
3. 前記第１のデータの前記電子トラフィックは、データがハイパーテキストトランスファープロトコル（ＨＴＴＰＳ）のセキュアプロトコルを使用して送信されることを含む、請求項２に記載の方法。
4. 前記第１のデータの前記配信速度の前記制御は、前記サーバへの／からの前記第１のデータの前記配信速度を、前記ネットワークの現在速度より遅い第１のデータレートに絞ることを含む、請求項１に記載の方法。
5. 前記第１のデータの前記電子トラフィックは、アダプティブビットレートストリームを含む、請求項１に記載の方法。
6. 前記第１のデータの前記電子トラフィックは、プログレッシブストリームを含む、請求項１に記載の方法。
7. 前記第１のアプリケーションは、マニフェストによって制御される異なる対応する解像度を有する複数のデータレートをサポートすることができ、かつ
   前記第１のデータの前記配信速度の前記制御は、前記データレートのうち第１のデータレートを超える前記データレートを隠す又は取り除くために前記マニフェストを編集することを含む、請求項１に記載の方法。
8. 前記第１のアプリケーションは、異なる対応する解像度を有する複数のデータレートをサポートすることができ、かつ
   前記第１のデータの前記配信速度の前記制御は、前記データレートのうち第１のデータレートを超える前記データレートへのアクセスを失敗又はブロックすることを含む、請求項１に記載の方法。
9. 前記トラフィックマネージャアプリケーションによって、前記プロセッサ上で動作し、かつ前記ネットワーク経由で前記サーバに／から第２のデータを配信する第２のアプリケーションを特定することと、
   前記トラフィックマネージャアプリケーションによって、前記第２のアプリケーションへの／からの前記第２のデータの電子トラフィックを傍受することと、
   前記トラフィックマネージャアプリケーションによって、前記第２のアプリケーションへの／からの、又は前記サーバへの／からの前記第２のデータの配信速度を制御することと
   をさらに含む、請求項１に記載の方法。
10. 前記第１の及び第２のデータの前記配信速度の前記制御は、前記第１のデータの前記配信速度が、前記第２のデータの前記配信速度を超えるように、前記第１の及び第２のデータの前記配信速度を同時に制限することを含む、請求項９に記載の方法。
11. 前記電子トラフィックの前記傍受は、前記プロセッサ上で動作している内部プロキシの使用を含む、請求項１に記載の方法。
12. 前記電子トラフィックの前記傍受は、前記プロセッサ上の仮想プライベートネットワーク（ＶＰＮ）インターフェースの使用を含む、請求項１に記載の方法。
13. 前記電子トラフィックの前記傍受は、前記プロセッサ上で変更された前記第１のアプリケーションを実行することを含み、前記変更された第１のアプリケーションが、前記電子トラフィックの前記傍受を要求するように構成される、請求項１に記載の方法。
14. 通信トラフィック管理システムであって、
    コンピュータプロセッサと、ネットワーク経由で前記プロセッサとの間でデータを送受信するためのサーバへのネットワーク接続とを有する、ポータブル通信デバイスと、
    前記プロセッサに接続された非揮発性記憶装置であって、前記プロセッサによって実行された場合、前記プロセッサ上で動作しているトラフィックマネージャアプリケーションに、
    前記プロセッサ上で動作し、かつ前記ネットワーク経由で前記サーバに／から第１のデータを配信する第１のアプリケーションを特定することと、
    前記第１のアプリケーションによって要求される動画データであって、前記ネットワークを経た第１の配信速度で前記サーバから受信した動画データを含む前記第１のデータの電子トラフィックを傍受することと、
    前記トラフィックマネージャアプリケーションと前記第１のアプリケーションとの間の内部ネットワークデータ経路を経た前記第１のアプリケーションへの前記動画データの第２の配信速度であって、特定の目標動画解像度に対応する第２の配信速度を制限することと、
    を行わせる命令を記憶する、非揮発性記憶装置と、
    を備える、システム。
15. 前記命令は、前記プロセッサによって実行された場合、前記第１のアプリケーションによって認識される前記ネットワークの現在速度を、前記ネットワークの前記現在速度より遅い第１のデータレートに絞ることによって、さらに前記プロセッサに、前記第１のデータの前記配信速度を制御させる、請求項１４に記載のシステム。
16. 前記第１のデータの前記電子トラフィックは、データがハイパーテキストトランスファープロトコル（ＨＴＴＰＳ）のセキュアプロトコルを使用して送信されることを含む、請求項１５に記載のシステム。
17. 前記命令は、前記プロセッサによって実行された場合、前記サーバへの／からの前記第１のデータの前記配信速度を、前記ネットワークの現在速度より遅い第１のデータレートに絞ることによって、さらに前記プロセッサに、前記第１のデータの前記配信速度を制御させる、請求項１４に記載のシステム。
18. 前記第１のデータの前記電子トラフィックは、アダプティブビットレートストリームを備える、請求項１４に記載のシステム。
19. 前記第１のデータの前記電子トラフィックは、プログレッシブストリームを備える、請求項１４に記載のシステム。
20. 前記第１のアプリケーションは、マニフェストによって制御される異なる対応する解像度を有する複数のデータレートをサポートすることができ、かつ
    前記命令は、前記プロセッサによって実行された場合、前記データレートのうち第１のデータレートを超える前記データレートを隠す又は取り除くために前記マニフェストを編集することによって、さらに前記プロセッサに、前記第１のデータの前記配信速度を制御させる、請求項１４に記載のシステム。
21. 前記第１のアプリケーションは、異なる対応する解像度を有する複数のデータレートをサポートすることができ、かつ
    前記命令は、前記プロセッサによって実行された場合、前記データレートのうち第１のデータレートを超える前記データレートへのアクセスを失敗又はブロックすることによって、さらに前記プロセッサに、前記第１のデータの前記配信速度を制御させる、請求項１４に記載のシステム。
22. 前記命令は、前記プロセッサによって実行された場合、さらに前記プロセッサに、
    前記プロセッサ上で動作し、かつ前記ネットワーク経由で前記サーバに／から第２のデータを配信する第２のアプリケーションを特定することと、
    前記第２のアプリケーションへの／からの前記第２のデータの電子トラフィックを傍受することと、
    前記第２のアプリケーションへの／からの、又は前記サーバへの／からの前記第２のデータの配信速度を制御することと
    を行わせる、請求項１４に記載のシステム。
23. 前記命令は、前記プロセッサによって実行された場合、前記第１のデータの前記配信速度が、前記第２のデータの前記配信速度を超えるように、前記第１の及び第２のデータの前記配信速度を同時に制限することによって、さらに前記プロセッサに、前記第１の及び第２のデータの前記配信速度を制御させる、請求項２２に記載のシステム。
24. 前記命令は、前記プロセッサによって実行された場合、前記プロセッサ上で動作している内部プロキシを使用することによって、さらに前記プロセッサに、前記電子トラフィックを傍受させる、請求項１４に記載のシステム。
25. 前記命令は、前記プロセッサによって実行された場合、前記プロセッサ上で仮想プライベートネットワーク（ＶＰＮ）インターフェースを使用することによって、さらに前記プロセッサに、前記電子トラフィックを傍受させる、請求項１４に記載のシステム。
26. 前記命令は、前記プロセッサによって実行された場合、前記プロセッサ上で変更された前記第１のアプリケーションを実行することによって、さらに前記プロセッサに、前記電子トラフィックを傍受させ、前記変更された第１のアプリケーションは、前記電子トラフィックの前記傍受を要求するように構成される、請求項１４に記載のシステム。