JP7109044B2 - 改善されたモバイルインターネットの速度およびセキュリティのためのシステム - Google Patents

Description

関連出願
本出願は、米国特許出願であり、参照によってそれらの全体が本明細書に組み込まれる、２０１５年４月２０日に出願された米国仮特許出願第６２／１５０，２５０号および２０１５年７月２４日に出願された米国仮特許出願第６２／１９６，５８３号の利益を主張する。

本発明は、モバイルインターネットを改善し、特に、複数の無線ネットワークを組み合わせてモバイルインターネットの速度を増大させ、モバイルインターネットトラフィックを保護するシステムおよび方法に関する。

スマートフォンおよびタブレットなどのモバイルデバイスが至る所に存在するようになってきた。最近の統計によると、人々は既に従来のデスクトップコンピュータよりも自身のモバイルアプリケーションを使用してインターネット上でより多くの時間を費やしている。それらのモバイルデバイスがＷｉ－Ｆｉおよび３Ｇ／４Ｇ接続などの無線ネットワークを使用してインターネットに接続するので、それらは、既にはるかに遅れをとっている無線インフラストラクチャに対して無類の制約を生じさせてきた。ユーザは、コーヒーショップ、空港、列車、または会議においてなどの多くの場所で低いモバイルインターネットを経験する傾向がある。現在の無線ネットワークの速度は、需要についていけない。最近の統計によると、米国における平均的なＷｉ－Ｆｉおよびセルラ速度は、４．８および３．７メガビット／秒をそれぞれ下回る。この速度は、今では消費者のスマートフォンが高解像度のスクリーンを備えているため、消費者が望むフルＨＤの１０８０画素またはクアッドＨＤのビデオはもちろんのこと、７２０画素のビデオをストリーミングするのにも十分でない。さらに、セルラ無線帯域幅の需要と供給とのギャップは今後増加するだけである。例えば、世界の人口の７０％がスマートフォンを有し、全てのモバイルデータトラフィックの６０％が２０２０年までにオンラインビデオからであることが予測される。ＣｉｓｃｏのＶｉｓｕａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｉｎｄｅｘによる最新のモバイルデータ予測によると、２０１９年までには、モバイルの速度が２倍に増加する一方、モバイルデータに対する需要が１０倍に増加することが推定される。

不十分な帯域幅は、低解像度のコンテンツ、ビデオが失速することなどが引き起こす不良なユーザ経験をもたらす。このことは、次いで、ユーザの関与が少なくなることに起因して何十億もの歳入の損失に変わる。例えば、Ｃｏｎｖｉｖａは、不良な品質のビデオストリーミングに起因して、２０１２年には世界的なプレミアコンテンツブランドが２１億６千万ドルの歳入を損失し、ビデオストリーミング品質の問題を改善しない場合、２０１７年のうちに、驚異的なことに、２００億ドルを損失するとの予測を報告している。速度およびコストの両方の目的で帯域幅集中型アプリケーションのためにモバイルユーザによって、またそれらのトラフィックをオフロードするためにセルラオペレータによってＷｉ－Ｆｉがますます使用されている。しかしながら、Ｗｉ－Ｆｉ単独では、その範囲がセルラと同じくらい偏在してはいないので十分でなく、公共空間におけるほとんどのＷｉ－Ｆｉネットワークは一般的には混み合っている。よって、遅いモバイルインターネットの速度の問題を解決する必要性が存在する。

本明細書で説明される任意の特徴または特徴の組み合わせは、コンテキスト、本明細書、および当業者のうちの１人の知識から明らかなように任意のそのような組み合わせに含まれる特徴が相互に一致する限り、本発明の範囲内に含まれる。本発明の追加の利点および態様は、以下の詳細な説明および特許請求の範囲において明らかである。

主題の開示は、より高速なモバイルインターネットのために複数の無線ネットワークまたはデバイスを効率的に組み合わせ、ネットワークの信頼性を増加させ、インターネットのセキュリティおよびプライバシー保護を強化し、データ消費およびネットワーク性能についてのマルチネットワークの見識を提供し、サービスのクラスに基づく経験の品質を提供するシステムおよび方法を特徴とする。

本発明の実施形態は、モバイルデバイスの発信および着信データパケットをルーティングするように仮想プライベートネットワーク（ＶＰＮ）サービスアプリケーションを動作させることと、リモートサーバとモバイルデバイスとの間でのデータパケットの転送のためにＶＰＮサービスアプリケーションを通じてモバイルデバイスをリモートサーバに結合することと、を備えるモバイルインターネットの速度を増大させる方法を特徴とする。本発明の別の実施形態は、増大したモバイルインターネットの速度を有するモバイルデバイスを特徴とする。モバイルデバイスは、モバイルデバイスの発信および着信データパケットをルーティングするようにモバイルデバイスのバックグランドで動作する仮想プライベートネットワーク（ＶＰＮ）サービスアプリケーション、ならびにモバイルデバイスとリモートサーバとの間でのデータパケットの転送のためにサービスアプリケーションによって確立された仮想ネットワークインタフェースを含んでもよい。

本発明のさらなる実施形態は、モバイルデバイスのインターネットの速度を増大させる仮想プライベートネットワーク（ＶＰＮ）サーバを特徴とする。ＶＰＮサーバは、モバイルデバイスとＶＰＮサーバとの間でのデータパケットの転送のための複数のネットワークソケット、および複数のネットワークソケットに結合され、モバイルデバイスによって送信されたデータパケットを送信ターゲットホストに転送し、モバイルデバイスによって要求されたデータパケットを取り出しターゲットホストから取り出すことが可能なデータパケット転送コンポーネントを含んでもよい。

また、複数のチャネルを通じて暗号化データパケットを同時に送信することと、単一の装置によって暗号化データパケットを受信することと、を含むデータパケットの転送を保護するために複数のチャネルを同時に使用する方法が本明細書で説明される。

追加の実施形態は、モバイルデバイスとリモートサーバとの間でのデータパケットの転送のための方法を含む。方法は、Ｗｉ－Ｆｉチャネルを介して第１の複数のデータパケットが転送されるように指定することと、セルラチャネルを介して第２の複数のデータパケットが転送されるように指定することと、Ｗｉ－Ｆｉチャネルおよびセルラチャネルの両方を使用して第１の複数のデータパケットおよび第２の複数のデータパケットを同時に転送することと、を備えてもよい。

リモートＶＰＮサーバの支援によって複数の無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックを増大させおよび保護するシステムを特徴とする本発明の例示的な実施形態を示す。 リモートＶＰＮサーバの支援によって複数の無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックを増大させおよび保護するシステムを特徴とする本発明の例示的な実施形態を示す。 リモートＶＰＮサーバの支援によって複数の無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックを増大させおよび保護するシステムを特徴とする本発明の例示的な実施形態を示す。 リモートＶＰＮサーバの支援によって複数の無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックを増大させおよび保護するシステムを特徴とする本発明の例示的な実施形態を示す。 リモートＶＰＮサーバの支援によって複数の無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックを増大させおよび保護するシステムを特徴とする本発明の例示的な実施形態を示す。 複数の無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックを保護する方法を特徴とする本発明の例示的な実施形態を示す。 Ａ～Ｅ。同一のリモートサーバと通信するためにモバイルデバイス上でＷｉ－Ｆｉおよびセルラを同時に使用する方法を特徴とする本発明の例示的な実施形態を示す。 リモートＶＰＮサーバの支援なしに２つの無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックをルーティングしおよび増大させるシステムを特徴とする本発明の例示的な実施形態を示す。 リモートＶＰＮサーバの支援なしに２つの無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックをルーティングしおよび増大させるシステムを特徴とする本発明の例示的な実施形態を示す。 リモートＶＰＮサーバの支援なしに２つの無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックをルーティングしおよび増大させるシステムを特徴とする本発明の例示的な実施形態を示す。 複数のＵＤＰまたはＴＣＰ接続のために複数のユーザデータグラムプロトコル（ＵＤＰ）または伝送制御プロトコル（ＴＣＰ）接続を使用して異なるターゲットホストと通信するためにモバイルデバイス上でＷｉ－Ｆｉおよびセルラを同時に使用するシステムを特徴とする本発明の例示的な実施形態を示す。 単一のＵＤＰまたはＴＣＰ接続のために複数のＵＤＰまたはＴＣＰ接続を使用して単一のターゲットホストと通信するためにモバイルデバイス上でＷｉ－Ｆｉおよびセルラを同時に使用するシステムを特徴とする本発明の例示的な実施形態を示す。 複数のＵＤＰまたはＴＣＰ接続のために複数のユーザデータグラムプロトコル（ＵＤＰ）または伝送制御プロトコル（ＴＣＰ）接続を使用して異なるターゲットホストと通信するためにモバイルデバイス上でＷｉ－Ｆｉおよびセルラを同時に使用するシステムを特徴とする本発明の例示的な実施形態を示す。 複数のＵＤＰまたはＴＣＰ接続のために複数のユーザデータグラムプロトコル（ＵＤＰ）または伝送制御プロトコル（ＴＣＰ）接続を使用して異なるターゲットホストと通信するためにモバイルデバイス上でＷｉ－Ｆｉおよびセルラを同時に使用するシステムを特徴とする本発明の例示的な実施形態を示す。 単一のＵＤＰまたはＴＣＰ接続のために複数のＵＤＰまたはＴＣＰ接続を使用して単一のターゲットホストと通信するためにモバイルデバイス上でＷｉ－Ｆｉおよびセルラを同時に使用するシステムを特徴とする本発明の例示的な実施形態を示す。 複数のＵＤＰまたはＴＣＰ接続のために複数のユーザデータグラムプロトコル（ＵＤＰ）または伝送制御プロトコル（ＴＣＰ）接続を使用して異なるターゲットホストと通信するためにモバイルデバイス上でＷｉ－Ｆｉおよびセルラを同時に使用するシステムを特徴とする本発明の例示的な実施形態を示す。 ダウンロードのためのソロモード（Ｓｏｌｏ Ｍｏｄｅ）の例示的な実施形態を示す。単一のデバイスは、２つの異なるＣＤＮサーバに接続することによって、２つの異なるネットワークインタフェース、セルラおよびＷｉＦｉを通じて異なるビデオブロック（すなわち、ビデオセグメント）をダウンロードする。 ２つのＣＤＮサーバを単一のサーバと、（ｉ）このサーバが図７ｂに示される２つのアドレス指定可能なＩＰアドレスを有し、または（ｉｉ）クライアントが送信元ＩＰ－それが有するインタフェースの各々のＩＰアドレスに基づいてパケットをルーティングすることができる、すなわち、図７ｃに示される送信元に基づくルーティングもしくはポリシに基づくルーティングの場合に、交換することができる例示的な実施形態を示す。図７ｂでは、クライアントが２つの異なるＩＰアドレスに接続する限り、ＩＰ１およびＩＰ２が交換可能であることに留意されたい。 アップロードのためのソロモードの例示的な実施形態を示す。単一のデバイスは、ＷｉＦｉおよびセルラ無線接続を通じて異なるビデオブロックを２つの異なるＣＤＮサーバ、サーバ１およびサーバ２に送信することによってビデオをアップロードする。サーバ２は、それが受信するビデオブロックをサーバ１に送信し、サーバ１は元のビデオを再構築する。ユーザは、ＷｉＦｉおよびセルラ接続の合計速度でアップロードを経験する。 ２つのサーバを単一のサーバと、（ｉ）このサーバが図８ｂに示される２つのアドレス指定可能なＩＰアドレスを有し、または（ｉｉ）クライアントが送信元ＩＰおよびそれが有するインタフェースの各々のＩＰアドレスに基づいてパケットをルーティングすることができる、すなわち、図８ｃに示される送信元に基づくルーティングもしくはポリシに基づくルーティングの場合に、交換することができる例示的な実施形態を示す。図８ｂでは、各クライアントが２つの異なるＩＰアドレスに接続する限り、ＩＰ１およびＩＰ２が交換可能であることに留意されたい。 ＢＭＶアーキテクチャ、およびソロモードにおけるプログレッシブビデオダウンローディング（Ｐｒｏｇｒｅｓｓｉｖｅ Ｖｉｄｅｏ Ｄｏｗｎｌｏａｄｉｎｇ）のときのビデオプレイヤとの可能な対話の実施形態を示す。ＢＭＶモジュール式アーキテクチャは、以下のメインコンポーネント：ダウンロードモジュール、統計エンジン、記憶システム、キャッシュシステムおよびｈｔｔｐプロキシサーバから構成される。プログレッシブダウンローディングでは、外部ビデオプレイヤがビデオを要求し、ダウンロードモジュールによってダウンロードされたブロックがキャッシュに記憶され、それらはＨＴＴＰプロキシサーバを通じて外部ビデオプレイヤに供給される。 ＢＭＶアーキテクチャ、およびソロモードにおけるレギュラービデオダウンローディング（Ｒｅｇｕｌａｒ Ｖｉｄｅｏ Ｄｏｗｎｌｏａｄｉｎｇ）に使用されるときのビデオプレイヤとの可能な対話の実施形態を示す。レギュラーダウンローディングでは、ダウンロードされたビデオブロックが記憶システムに記憶され、要求したソフトウェア（ビデオダウンローダ）に利用可能となる。 ＢＭＶアーキテクチャ、およびプログレッシブＨＬＳダウンローディング、ソロモードにおけるライブストリーミングのときのビデオプレイヤとのその潜在的な対話を示す。ライブストリーミング（ＨＬＳファイル）では、ダウンロードモジュールコンポーネント内部のＨＴＴＰライブストリーミングエンジンがアクティブになる。 ＢＭＶアーキテクチャ、およびレギュラーＨＬＳダウンローディング、ソロモードのためのビデオダウンローダとのその可能な対話を示し、ＨＬＳファイルは記憶システムにダウンロードされる。 プロトコルスタックの異なるレイヤにおける該当の技術の可能な実装および対応する利点を示す。１つ目に、Ａｎｄｒｏｉｄ ａｐｐ ＶｉｄｅｏＢｅｅで行ったのと同様に、エンドユーザがより高速なダウンロードを楽しむために直接使用することができるスタンドアロンのモバイルアプリケーションを開発することができる。２つ目に、それらのユーザへのビデオ配信を加速化するためにそれらのモバイルアプリケーション内部でコンテンツプロバイダによって使用することができるＳＤＫを提供することができる。最後に、ユーザおよび他のアプリケーションに対して透過的な、オペレーティングシステムレベルにおけるサービスとして該当の技術を実装することができる。デバイスの製造者またはモバイルオペレーティングシステムの所有者は、それらのクライアントに競争力のある性能を提供するためにこの技術をそれらの製品に組み込むことができる。 ソロモードおよびグループモードの両方についての該当の室内実験におけるＶｉｄｅｏＢｅｅの性能の例をプロットする。この例について、以下の実験的なセットアップを使用しており、グループの２つのスマートフォン、（１）Ｇａｌａｘｙ Ｎｅｘｕｓバージョン４Ｇ、および（２）ＡＴ＆Ｔ ３ＧのＳａｍｓｕｎｇ Ｃａｐｔｉｖａｔｅに接続する。ＷｉＦｉ接続については、無線ＡＰ ８０２．１１ルータに接続する。全てのシナリオで同一の電話の配置を使用して同一の３分のＹｏｕＴｕｂｅのビデオを５回ダウンロードし、平均的なダウンロードの速度を報告する。ソロモードでは、１回目にセルラ接続のみを使用し、２回目にＷｉＦｉ接続のみを使用し、３回目に該当の技術による両方の接続を使用して（デュアルとして報告される）ビデオをダウンロードする。該当の技術によって、ＷｉＦｉおよびセルラ接続の合計速度を達成することが可能になることを検証する。グループモードでは、スマートフォン（セルラ１およびセルラ２として報告される）の各々を単独で最初に使用してダウンロードしており、次いで、それらをグループで接続し、それらの接続を集約する。グループモードでは、２つのセルラ接続の合計でダウンロードしたことを検証する。 ユーザの統計から収集したデータから処理することによってそのままのＶｉｄｅｏＢｅｅの性能の例をプロットする。ソロモードにおけるプログレッシブビデオダウンローディングを考える。ＷｉＦｉのみを使用することに対し、ＶｉｄｅｏＢｅｅでの両方のインタフェースを使用するときに達成することができる速度比のヒストグラムをプロットし、これは、ＷｉＦｉを単独で使用することに対して達成する改善をとらえる。 そのままのＶｉｄｅｏＢｅｅのソロモードのプログレッシブビデオダウンローディングの性能の例をプロットし、ここで、セルラ接続がＷｉＦｉ接続に寄与するメガビット／秒におけるレートのヒストグラムを描く。 ＶｉｄｅｏＢｅｅアプリケーションのスクリーンショットを示す。

図１に示されるように、本発明は、モバイルインターネットトラフィックの速度を増加させるシステムである。システムは、複数のデータチャネルを通じて相互に通信することが可能な少なくとも１つのモバイルデバイス（１０２）およびリモートサーバ（２００）を備え、チャネルは、異なるタイプのチャネル（例えば、Ｗｉ－Ｆｉ（１１５）、セルラ（１１６）、およびＢｌｕｅｔｏｏｔｈ（１１７））である。本発明の主要な実施形態では、モバイルデバイス（１０２）は、仮想プライベートネットワーク（ＶＰＮ）サービスアプリケーション（１０３）を動作させるように構成され、サービスアプリケーションは、仮想ネットワークインタフェース（１０８）を確立する。モバイルデバイス（１０２）のオペレーティングシステムは、発信パケットの（１０７）のセットをこのインタフェースにルーティングし、着信パケット（１０６）のセットをこのインタフェースから受信するように構成され、仮想ネットワークインタフェース（１０８）は、ＶＰＮサービスアプリケーション（１０３）に結合されたネットワークソケットを使用して発信データパケットをリモートサーバ（２００）に送信する。典型的な実施形態では、ＶＰＮサービスアプリケーション（１０３）は、発信パケット（１０７）のセットを仮想ネットワークインタフェース（１０８）から読み出し、各発信パケット（１０７）を複数のチャネルのうちの１つに割り当て、割り当てられたチャネル（１１５、１１６、１１７）を介して発信パケットのセットをリモートサーバ（２００）に送信する。サービスアプリケーション（１０９）はまた、着信データパケットのセットをリモートサーバ（２００）から受信し、着信パケットは、複数のチャネルを通じて受信され、着信パケットを仮想ネットワークインタフェース（１０８）に書き込む。

主要な実施形態では、リモートサーバ（２００）は、インターネット上で複数のターゲットホスト（３００）と通信する。リモートサーバ（２００）は、複数のチャネルを介して発信パケットのセットをモバイルデバイス（１０２）から受信し、発信パケットのセットをターゲットホスト（３００）に転送し、着信パケット（２０７）のセットをターゲットホスト（３００）から受信し、各着信パケット（２０７）を複数のチャネルのうちの１つに割り当て、割り当てられたチャネル（１１５、１１６、１１７）を介して着信パケットのセットをモバイルデバイス（１０２）に送信する。

好ましい実施形態では、サービスアプリケーションは、増大ポリシ（ｂｏｏｓｔｉｎｇ ｐｏｌｉｃｙ）（１１９）に従ってパケットをチャネルに割り当てる。いくつかの実施形態では、増大ポリシ（１１９）は、パケットを生成するアプリケーション、各チャネルのスループットおよび遅延などの複数のチャネルの各々のチャネル状態、ならびに複数のチャネルの各々のチャネルタイプに少なくとも基づいてアルゴリズムによって定義される。

種々の実施形態では、チャネルタイプは、デバイスツーデバイス接続、Ｗｉ－Ｆｉ、マイクロセル、ピコセル、および標準的なセルラ基地局チャネル（１１７）を含んでもよい。

いくつかの実施形態では、増大ポリシ（１１９）は、構成可能なオプションのセットを含んでもよい。オプションは、コストを最小化し、伝送の速度を最適化し、または選択されたパケットタイプを優先付けるように増大ポリシ（１１９）を構成してもよい。

いくつかの実施形態では、増大ポリシ（１１９）は、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および／または各チャネルの遅延に基づいて、複数のチャネルを通じて送信されることになるデータパケットを選択する。

いくつかの実施形態では、リモートサーバ（２００）はまた、増大ポリシ（２０８）を動作させるように構成され、増大ポリシ（２０８）は、発信パケットを優先付け、どのパケットをどのチャネルに割り当てるかを決定する。いくつかの実施形態では、増大ポリシ（２０８）は、パケットを生成するアプリケーション、各チャネルのスループットおよび遅延などの複数のチャネルの各々のチャネル状態、ならびに複数のチャネルの各々のチャネルタイプに少なくとも基づいてアルゴリズムによって定義される。

いくつかの実施形態では、リモートサーバ（２００）は、ＶＰＮサーバ（２０１）であり、ＶＰＮサービスアプリケーション（１０３）は、モバイルデバイス（１０２）のバックグランドで動作する。いくつかの実施形態では、データパケットは、オープンシステムインターコネクション（ＯＳＩ）レイヤ３インターネットプロトコル（ＩＰ）データグラムまたはＯＳＩレイヤ２イーサネットフレームであってもよい。いくつかの実施形態では、仮想ネットワークインタフェースは、ＴＵＮまたはＴＡＰインタフェース（１０８）のいずれかである。仮想ネットワークインタフェース（１０８）は、リモートサーバ（２００）またはデータパケットをリモートサーバ（２００）に転送するプロキシサーバ（２１１）として、宛先を有するデータパケットを除く発信データパケットを遮断するように構成されてもよい。いくつかの実施形態では、ネットワークソケット（１０５）は、レイヤ４ユーザデータグラムプロトコル（ＵＤＰ）ソケット、レイヤ４伝送制御プロトコル（ＴＣＰ）ソケット、またはレイヤ３ロー（ｒａｗ）ソケットを含んでもよい。いくつかの実施形態では、データパケットを送出するネットワークソケット（１０５）は、Ｗｉ－Ｆｉ（１１５）またはセルラ（１１６）物理インタフェースなどの実物理インタフェースにバインド（ｂｉｎｄ）するように構成されてもよい。可変的な実施形態では、複数のチャネルは、少なくともＷｉ－Ｆｉチャネル（１１５）およびセルラチャネル（１１６）、少なくとも２つのセルラチャネル、少なくともセルラチャネル（１１６）およびローカルデバイスツーデバイスチャネル、または少なくともＷｉ－Ｆｉチャネル（１１５）およびローカルデバイスツーデバイスチャネル（１１７）を含む。ローカルデバイスツーデバイスチャネルは、Ｂｌｕｅｔｏｏｔｈチャネル、Ｗｉ－Ｆｉ直接チャネル、ロングタームエボリューション（ＬＴＥ）直接チャネル、またはＺｉｇＢｅｅチャネルであってもよい。

また、図１を参照して、本発明の実施形態は、増大したモバイルインターネットの速度を有するモバイルデバイス（１０２）を特徴とする。モバイルデバイス（１０２）は、モバイルデバイス（１０２）の発信および着信データパケットをルーティングするようにモバイルデバイス（１０２）のバックグランドで動作する仮想プライベートネットワーク（ＶＰＮ）サービスアプリケーション（１０３）、ならびにモバイルデバイス（１０２）とリモートサーバ（２００）との間でのデータパケットの転送のためにサービアプリケーションによって確立された仮想ネットワークインタフェースを含んでもよい。サービスアプリケーションは、発信データパケットを処理し、ネットワークソケット（１０５）を使用して処理されたデータパケットを送出してもよい。処理されたデータパケットは、複数のチャネル（１１５、１１６、１１７）を通じて同時に送信され、データパケットは、受信された後に組み立てられる（ａｓｓｅｍｂｌｅｄ）。

別の実施形態では、データパケットは、暗号化スキームを使用して暗号化され（１１０）、または符号化スキームを使用して符号化され（１１１）、次いで、増大ポリシ（１１９）に基づいて複数のチャネルを通じて送信される。データパケットは、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および各チャネルの遅延のうちの少なくとも１つに基づいて、複数のチャネルを通じて送信されてもよい。複数のチャネルを通じて送信されるデータパケットは、データパケットが送信される前に暗号化される場合に解読されてもよい（１１０）。また、データパケットは、データパケットが送信される前に符号化される場合に復号される。

図１を参照して、本発明の実施形態は、モバイルデバイス（１０２）のインターネットの速度を増大させる仮想プライベートネットワーク（ＶＰＮ）サーバ（２０１）を特徴とする。ＶＰＮサーバは、モバイルデバイス（１０２）とＶＰＮサーバ（２０１）との間でのデータパケットの転送のための複数のネットワークソケット、および複数のネットワークソケット（１０５）に結合され、モバイルデバイス（１０２）によって送信されたデータパケットを送信ターゲットホスト（３００）に転送し、モバイルデバイス（１０２）によって要求されたデータパケットを取り出しターゲットホスト（３００）から取り出すことが可能なデータパケット転送コンポーネントを含んでもよい。データパケットは、複数のチャネルを通じて同時に転送されてもよく、データパケットは、受信された後に組み立てられる。１つの実施形態では、データパケットは、増大ポリシ（１１９）に基づいて複数のチャネルを通じて送信される。別の実施形態では、データパケットは、暗号化スキームを使用して暗号化され、または符号化スキームを使用して符号化され、次いで、増大ポリシに基づいて複数のチャネルを通じて送信される。増大ポリシ（１１９）は、モバイルデバイス（１０２）のユーザまたはモバイルデバイス（１０２）のサービスキャリアによって構成可能であってもよい。増大ポリシ（１１９）は、パケットを生成するアプリケーション、複数のチャネルの各々のチャネル状態、および複数のチャネルの各々のチャネルタイプに少なくとも基づいてアルゴリズムによって定義されてもよく、チャネル状態は、各チャネルのスループットおよび遅延を含み、チャネルタイプは、デバイスツーデバイス接続、Ｗｉ－Ｆｉ、マイクロセル、ピコセル、および標準的なセルラ基地局を含む。

１つの実施形態では、複数のネットワークソケットのうちの少なくとも２つは、データパケットをモバイルデバイス（１０２）から受信するために同時に使用される。別の実施形態では、複数のネットワークソケットのうちの少なくとも２つは、データパケットをモバイルデバイス（１０２）に送信するために同時に使用される。他の実施形態では、仮想ネットワークインタフェース（２０４）は、ネットワーク接続経路を介して送信ターゲットホスト（３００）または取り出しターゲットホスト（３００）に結合してもよい。ネットワーク接続経路は、データグラムパケット内のネットワークアドレス情報を再マッピングまたは修正するネットワークアドレス変換（ＮＡＴ）（２１４）をサポートすることができる。

図１Ａ～Ｂに示されるように、リモートＶＰＮサーバ（２０１）の支援による複数の無線チャネルの同時使用は、モバイルデバイス（１０２）上の全てのトラフィックを増大させ、および保護することができる。要するに、この非限定的な実施形態は、システムをどのように作動させるかである。任意のインターネットトラフィック、すなわち、アプリケーションによって生成されたデータパケット（ＩＰデータグラムまたはイーサネットフレーム）は、オペレーティングシステムによって仮想ネットワークインタフェース（２０４）（ＴＵＮまたはＴＡＰインタフェース）にルーティングされる。次いで、仮想ネットワークインタフェースから読み出すために利用可能なデータパケットは、複数の無線チャネルを通じて同時に送信され、チャネルは、Ｗｉ－Ｆｉ（１１５）、セルラ（１１６）、または隣接デバイスを通じた間接（１１７）チャネル（例えば、隣接デバイスへのＢｌｕｅｔｏｏｔｈ接続によって確立され、隣接デバイスは、パケットのさらなる転送をサポートする）であってもよい。チャネルが遮断されたデータパケットを送出するために使用されるソケットは、ＴＣＰ、ＵＤＰ、またはＲＡＷソケットであってもよい。それらのソケットは、対応する物理ネットワークインタフェース（例えば、Ｗｉ－Ｆｉ、セルラ）をバインドするか、または単なる通常のソケットであるが、仮想ネットワークインタフェースの構成で実行されたＩＰアドレスに接続する（それらの実行されたＩＰアドレスを宛先とする任意のトラフィックが仮想ネットワークインタフェースにルーティングされないが、ターゲットＩＰアドレスに直接送信されるように）ようにバインドするかのいずれかで構成される。データパケットを送出する前に、モバイルデバイス（１０２）は、それらを暗号化または符号化してもよい。複数のチャネルを通じたデータパケットの発信は、ユーザが構成可能であり、キャリアが構成可能である増大ポリシに従い、ポリシはまた、チャネル状態、タイプ、および速度などを入力として受ける。サーバは、データパケットを複数のソケットから受信し、それらを組み立て（再順序付け、復号し、解読するなど）、インターネット上でそれらをターゲットホストに転送する。これが行われる１つの方法は、ＩＰ転送を可能にし、サーバ上でネットワークアドレス変換（２１４）との仮想ネットワークインタフェース（２０４）を確立することによってである。インターネット上で応答データパケットをリモートホストから受信すると、ＶＰＮサーバ（２０４）は、他の方向と同様に、複数のチャネルを同時に使用してそれらをモバイルデバイス（１０２）に転送する。データパケットをサーバからの複数のソケットから受信すると、モバイルデバイス（１０２）は、それらを組み立て（再順序付け、復号し、解読するなど）、それらをアプリケーション（１０９）に転送する。

図１Ｃでは、本発明をさらに明瞭にするフローチャートが提示され、「１」は、ネットワークソケット（１０５）を使用してデータパケットをモバイルデバイス（１０２）からリモートサーバ（２００）に送信するものとして指定される。「２」は、データパケットを受信するものとして指定され、それらのデータパケットの送信は、２つの部分に分割される。１つの実施形態では、パケットを送信することは、Ｗｉ－Ｆｉチャネルによる「１ａ」およびセルラチャネル（１１６）による「１ｂ」である。１つの実施形態では、ネットワークソケットは、スイッチとしての役割を果たし、それは、Ｗｉ－Ｆｉ（１１５）およびセルラ（１１６）チャネルを使用したモバイルデバイス（１０２）からリモートサーバ（２００）へのデータパケットの転送を意味する。

いくつかの実施形態では、「２ａ」は、データパケットをＷｉ－Ｆｉチャネル（１１５）から受信するものとして指定され、「２ｂ」は、データパケットをセルラチャネル（１１６）から受信するものとして指定される。１つの実施形態では、ネットワークソケットは、スイッチとしての役割を果たし、その主な機能は、データパケットを送信および受信するための特定のチャネルを発見することを解決することである。

図１Ｄを参照すると、本発明は、リモートサーバ（２００）とのセルラチャネル（１１６）通信がない実施形態を強調する。１つの実施形態では、フローチャートのフォーマットは、ネットワークソケットを使用してデータパケットをモバイルデバイス（１０２）からリモートサーバ（２００）に送信するものとして「１」が指定され、データパケットをインターネットホストから受信するものとして「２」が指定され、それらのデータパケットの送信および受信は、２つの部分に分割される。

いくつかの実施形態では、パケットを送信することは、セルラチャネル（１１６）による「１ａ」および間接チャネル（１１７）による「１ｂ」である。同様に、「２ａ」は、データパケットをセルラチャネルから受信するものとして指定され、「２ｂ」は、データパケットを間接チャネルから受信するものとして指定される。ローカルデバイスツーデバイスチャネル（間接チャネル）は、Ｂｌｕｅｔｏｏｔｈチャネル、Ｗｉ－Ｆｉ直接チャネル、ＬＴＥ直接チャネル、またはＺｉｇＢｅｅチャネルであってもよい。

ここで、図１Ｅを参照すると、本発明は、リモートサーバ（２００）とのＷｉ－Ｆｉチャネル通信がない実施形態を強調する。１つの実施形態では、フローチャートのフォーマットは、ネットワークソケットを使用してデータパケットをモバイルデバイス（１０２）からリモートサーバ（２００）に送信するものとして「１」が指定され、受信されたデータパケットとして「２」が指定され、それらのデータパケットの送信は、２つの部分に分割される。

いくつかの実施形態では、パケットを送信することは、Ｗｉ－Ｆｉチャネルによる「１ａ」および間接チャネル（１１７）による「１ｂ」である。同様に、「２ａ」は、データパケットをＷｉ－Ｆｉチャネル（１１５）から受信するものとして指定され、「２ｂ」は、データパケットを間接チャネル（１１７）から受信するものとして指定される。ローカルデバイスツーデバイスチャネル（間接チャネル）は、Ｂｌｕｅｔｏｏｔｈチャネル、Ｗｉ－Ｆｉ直接チャネル、ＬＴＥ直接チャネル、またはＺｉｇＢｅｅチャネルであってもよい。

ここで、図２を参照すると、本発明はさらに、データパケットの転送を保護するために複数のチャネを同時に使用する方法を特徴とすることができる。いくつかの実施形態では、方法は、複数のチャネルを通じて暗号化データパケットを同時に送信することと、単一の装置によって暗号化データパケットを受信することと、を備えてもよい。好ましくは、受信された暗号化データパケットは、組み立てられおよび解読される。いくつかの実施形態では、複数のチャネルは、少なくともＷｉ－Ｆｉチャネルおよびセルラチャネル、少なくとも２つのセルラチャネル、少なくともセルラチャネルおよびローカルデバイスツーデバイスチャネル、または少なくともＷｉ－Ｆｉチャネルおよびローカルデバイスツーデバイスチャネルを含んでもよい。ローカルデバイスツーデバイスチャネルは、Ｂｌｕｅｔｏｏｔｈチャネル、Ｗｉ－Ｆｉ直接チャネル、ＬＴＥ直接チャネル、またはＺｉｇＢｅｅチャネルであってもよい。

１つの実施形態では、暗号化データパケットは、セキュアポリシに基づいて複数のチャネルを通じて送信される。別の実施形態では、暗号化データパケットは、符号化スキームを使用して符号化され、次いで、セキュアポリシに基づいて複数のチャネルを通じて送信される。暗号化データパケットは、暗号化データパケットが送信される前に符号化される場合に復号されてもよい。暗号化データパケットは、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および各チャネルの遅延から選択された要因に少なくとも基づいて送信されてもよい。

いくつかの実施形態では、セキュアポリシは、暗号化パケットを生成するアプリケーションおよび複数のチャネルの各々のチャネル状態から選択された要因に少なくとも基づいてアルゴリズムによって定義されてもよい。他の実施形態では、チャネル状態は、各チャネルのスループットおよび遅延、複数のチャネルの各々のチャネルタイプから選択されたチャネルパラメータを含んでもよい。さらなる実施形態では、複数のチャネルの各々のチャネルタイプは、デバイスツーデバイス接続、Ｗｉ－Ｆｉ、マイクロセル、ピコセル、または標準的なセルラ基地局接続である。

図２に示されるように、複数の無線チャネルの同時使用は、モバイルデバイス（１０２）上の全てのトラフィックを保護することができる。モバイルデバイス（１０２）上の仮想ネットワークインタフェースにルーティングされるデータパケット（ＩＰデータグラムまたはイーサネットフレーム）を考える。それらのデータパケットは、暗号化および符号化され、次いで、セキュアポリシに基づいて複数のチャネルを同時に使用してリモートサーバ（２００）に送信される。このセキュアポリシは、データパケットを生成したアプリケーションならびにチャネル状態、タイプ、および速度などを入力として受ける。暗号化データパケットをモバイルデバイス（１０２）から受信すると、リモートサーバ（２００）は、それらを組み立てて（再順序付け、復号し、解読するなど）データパケットを取得する。モバイルデバイス（１０２）に再度送信される必要があるデータパケット（ターゲットホストからの応答）は、同様に、複数のチャネルを通じて同時に安全に送信されてもよい。

図３に示されるように、本発明の追加の実施形態は、モバイルデバイス（１０２）とリモートサーバ（２００）との間でのデータパケットの転送のための方法を特徴とすることができる。方法は、Ｗｉ－Ｆｉチャネルを介して第１の複数のデータパケットが転送されるように指定することと、セルラチャネルを介して第２の複数のデータパケットが転送されるように指定することと、Ｗｉ－Ｆｉチャネルおよびセルラチャネルの両方を使用して第１の複数のデータパケットおよび第２の複数のデータパケットを同時に転送することと、を備えてもよい。１つの実施形態では、リモートサーバ（２００）は、第１の複数のデータパケットを転送するための第１のインターネットプロトコル（ＩＰ）アドレスおよび第２の複数のデータパケットを転送するための第２のＩＰアドレスを有するように構成されてもよく、第２のＩＰアドレスは、第１のＩＰアドレスとは別個である。別の実施形態では、リモートサーバ（２００）は、第１の複数のデータパケットを転送するための単一のＩＰアドレスを有するように構成されてもよく、第２の複数のデータパケットは、単一のＩＰアドレスとは異なるＩＰアドレスでプロキシサーバ（２１１）を介してリモートサーバ（２００）とモバイルデバイス（１０２）との間で転送される。さらなる別の実施形態では、リモートサーバ（２００）は、第２の複数のデータパケットを転送するための単一のＩＰアドレスを有するように構成されてもよく、第１の複数のデータパケットは、単一のＩＰアドレスとは異なるＩＰアドレスでプロキシサーバ（２１１）を介してリモートサーバ（２００）とモバイルデバイス（１０２）との間で転送される。

いくつかの実施形態では、Ｗｉ－Ｆｉチャネルを介して転送されることになる第１の複数のデータパケットは、Ｗｉ－Ｆｉチャネル接続がモバイルデバイス（１０２）上で有効にされた後にデフォルトの構成またはアプリケーションプログラミングインタフェース（ＡＰＩ）の構成でモバイルデバイス（１０２）上で指定され、セルラチャネルを介して転送されることになる第２の複数のデータパケットは、セルラチャネル接続がモバイルデバイス（１０２）上で有効にされた後にデフォルトの構成またはアプリケーションプログラミングインタフェース（ＡＰＩ）の構成でモバイルデバイス（１０２）上で指定される。

他の実施形態では、Ｗｉ－Ｆｉチャネルを介して転送されることになる第１の複数のデータパケットは、Ｗｉ－Ｆｉチャネルがモバイルデバイス（１０２）上で有効にされた後、次いで、第１の複数のデータパケットを送信するためにそれらのソケットを使用して、既にＷｉ－Ｆｉチャネルにバインドされたソケットを選択することによって、またはモバイルデバイス（１０２）上の選択されたネットワークソケットをＷｉ－Ｆｉチャネルにバインドすることによって指定され、セルラチャネルを介して転送されることになる第２の複数のデータパケットは、セルラチャネルがモバイルデバイス（１０２）上で有効にされた後、次いで、第２の複数のデータパケットを送信するためにそれらのソケットを使用して、既にセルラチャネルにバインドされたソケットを選択することによって、またはモバイルデバイス（１０２）上の選択されたネットワークソケットをセルラチャネルにバインドすることによって指定される。

図３に示されるように、Ｗｉ－Ｆｉチャネル（１１５）およびセルラチャネル（１１６）は、以下の２つのアプローチのクラス、（ｉ）モバイルデバイス（１０２）がＷｉ－Ｆｉ（１１５）およびセルラ（１１６）接続のために２つの異なるＩＰアドレスに接続することであって（図３Ａ、３Ｂ、３Ｃ）、リモートサーバ（２００）に直接接続するか（図３Ａ）またはプロキシサーバ（２１１）を通じて接続するか（図３Ｂ、３Ｃ）のいずれかである、ことと、（ｉｉ）モバイルデバイス（１０２）が明確に少なくともソケットを物理インタフェースにバインドすること（図３Ｄにおけるセルラまたは図３ＥにおけるＷｉ－Ｆｉ）と、に従ういくつかの方法で、同一のリモートサーバ（２００）と通信するためにモバイルデバイス（１０２）上で同時に使用されてもよい。

利用可能なときに（セカンダリチャネルがデータを転送するために使用されないときでさえ）少なくとも２つのチャネルを同時にアクティブに保持することは、複数のネットワークにわたってシームレスな接続性を提供するための重要な技術である。例えば、２つの利用可能なチャネル、ＷｉＦｉおよびセルラを有し、ＷｉＦｉが現在プライマリインタフェースであることを仮定する。セルラインタフェースがアクティブに保持されないが、ＷｉＦｉが切断されるときのみアクティブになり、次いで、ＯＳがセルラインタフェースをアクティブにするために（使用できるまでには）数秒の遅延がある。これは、ＩＰデータグラムまたはイーサネットフレームをモバイルデバイスとＶＰＮサーバとの間で搬送する際に中断を生じさせることがあり、それによって、アプリケーションの現在のＴＣＰ／ＵＤＰセッションを切断する。

図４Ａに示されるように、本発明は、モバイルインターネットトラフィックの速度を増加させるシステムである。システムは、データチャネルをルーティングするユーザデータグラムプロトコル（ＵＤＰ）／伝送制御プロトコル（ＴＣＰ）を通じてターゲットホスト（６００）と通信することが可能な少なくとも１つのモバイルデバイス（５０２）を備えてもよく、チャネルは、異なるタイプのチャネルである（例えば、Ｗｉ－Ｆｉ（５２４）およびセルラ（５２５））。本発明の主要な実施形態では、モバイルデバイス（５０２）は、仮想プライベートネットワーク（ＶＰＮ）サービスアプリケーション（５０３）を動作させるように構成され、サービスアプリケーションは、仮想ネットワークインタフェース（５０５）を確立する。モバイルデバイス（５０２）のオペレーティングシステムは、発信パケットのセットをこのインタフェースにルーティングし、着信パケットのセットをこのインタフェースから受信するように構成され、仮想ネットワークインタフェース（５０５）は、ＶＰＮサービスアプリケーション（５０３）に結合されたネットワークソケットを使用して発信データパケットをターゲットホスト（６００）に送信する。典型的な実施形態では、ＶＰＮサービスアプリケーション（５０３）は、発信パケットのセットを仮想ネットワークインタフェース（５０５）から読み出し、各発信パケットをチャネルのルーティングのうちの１つに割り当て、割り当てられたチャネルを介して発信パケットのセットをターゲットホストに送信する。サービスアプリケーションはまた、着信データパケットのセットをホストから受信し、着信パケットは、チャネルのＵＤＰ／ＴＣＰを通じて受信され、着信パケットを仮想ネットワークインタフェース（５０５）に書き込む。

いくつかの実施形態では、サービスアプリケーションは、増大ポリシ（５１４）に従ってパケットをチャネルに割り当てる。いくつかの実施形態では、増大ポリシ（５１４）は、パケットを生成するアプリケーション、各チャネルのスループットおよび遅延などのルーティング処理の各々のチャネル状態、ならびに転送チャネルの各々のチャネルタイプに少なくとも基づいてアルゴリズムによって定義される。

いくつかの実施形態では、増大ポリシ（５１４）は、構成可能なオプションのセットを含む。オプションは、コストを最小化し、伝送の速度を最適化し、またはパケットタイプを送信および受信するためのルーティング処理を選択するように増大ポリシ（５１４）を構成してもよい。

いくつかの実施形態では、増大ポリシ（５１４）は、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および／または各チャネルの遅延に基づいて、チャネルの異なるルーティングを通じて送信されることになるデータパケットを選択する。

また、図４Ａを参照して、本発明の実施形態は、増大した（５１４）モバイルインターネットの速度を有するモバイルデバイス（５０２）を特徴とする。モバイルデバイス（５０２）は、モバイルデバイス（５０２）の発信および着信データパケットをルーティングするためにモバイルデバイス（５０２）のバックグランドで動作する仮想プライベートネットワーク（ＶＰＮ）サービスアプリケーション（５０３）、ならびにモバイルデバイス（５０２）とターゲットホスト（６００）との間でのデータパケットの転送のためにサービスアプリケーションによって確立された仮想ネットワークインタフェース（５０５）を備えてもよい。サービスアプリケーションは、発信データパケットを処理し、ネットワークソケットを使用して処理されたデータパケットを送出してもよい。処理されたデータパケットは、複数のチャネル（５２４、５２５）を通じて同時に送信され、データパケットは、受信された後に組み立てられる。

いくつかの実施形態では、データパケットは、ユーザデータグラムプロトコル（ＵＤＰ）／伝送制御プロトコル（ＴＣＰ）によって提供されるルーティング処理ならびに増大ポリシ（５１４）に基づいて複数のチャネル（５２４、５２５）を通じて送信される。データパケットは、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および／または各チャネルの遅延のうちの少なくとも１つに基づいて複数のチャネルを通じて送信されてもよい。

要するに、この非限定的な実施形態は、システムの作動方法である。パケットからのデータは、レイヤ３データグラム（またはレイヤ２フレーム）とレイヤ４パケットとの間で変換を実行することによってそれらのターゲットホストに送信され、それによって、通常のＵＤＰ／ＴＣＰソケットを使用してデータをインターネットに送出することができる。特に、発信トラフィックについて、ＩＰデータグラム（またはイーサネットフレーム）のデータは、抽出され、ＵＤＰ／ＴＣＰソケットを通じてターゲットホストに直接送信される必要がある。ターゲットホストが応答するとき、その応答データは、ＵＤＰ／ＴＣＰソケットから読み出され、ＩＰデータグラム（およびイーサネットフレーム）で包み込まれる必要があり、それらは次いで、ＴＵＮ（またはＴＡＰ）インタフェースに書き込まれる。

また、この非限定的な実施形態は、システムによる、異なるトラフィックタイプに対するインターネットの速度の増大の達成方法である。増大は、ＵＤＰまたはＴＣＰトラフィックのいずれかを加速化するために複数のレイヤ４ＵＤＰ／ＴＣＰソケットを同時に使用することによって達成される。それらのソケットは、Ｗｉ－Ｆｉまたはセルラのいずれかの適切なインタフェースにバインドするように構成され、また、仮想ネットワークインタフェース（例えば、保護されたソケット）にループバックしないように構成される。４つの増大の例示的なケース：（１）異なるターゲットホストへの複数のＴＣＰ接続：ホストＡをターゲットとするＴＣＰ接続をＴＣＰ Ｗｉ－Ｆｉに割り当てることができ、ホストＢをターゲットとする別のＴＣＰ接続をＴＣＰセルラに割り当てることができる。（２）同一のターゲットホストへの単一のＴＣＰ接続：アプリケーションレイヤプロトコルに応じて、単一のＴＣＰ接続が複数のＴＣＰ接続に分解されることが可能となることがあり、例えば、各接続がＨＴＴＰ範囲要求においてデータの範囲の部分的な範囲をフェッチする。次いで、それらの接続をＷｉ－Ｆｉおよびセルラに同時に割り当てることができる。元の範囲の部分的な範囲がフェッチされるとき、それらは、パケットデータの順序を保証するために仮想ネットワークインタフェースに送信される前に再組み立てされる。（３）異なるターゲットホストへの複数のＵＤＰ接続：ホストＡをターゲットとするＵＤＰ接続をＵＤＰ Ｗｉ－Ｆｉに割り当てることができ、ホストＢをターゲットとする別のＵＤＰ接続をＵＤＰセルラに割り当てることができる。（４）同一のターゲットホストへの単一のＵＤＰ接続：アプリケーションレイヤプロトコルに応じて、単一のＵＤＰ接続が複数のＵＤＰ接続に分解されることが可能となることがあり、例えば、各接続がＴＣＰのためのＨＴＴＰ範囲要求においてデータの部分などをフェッチする。次いで、それらの接続を上記のようにＷｉ－Ｆｉおよびセルラに同時に割り当てることができる。

図４Ｂ～Ｃでは、本発明をさらに明瞭にするフローチャートが提示され、「１」は、保護されたソケット（５１５）を使用してデータパケットをモバイルデバイス（５０２）からターゲットホスト（６００）に送信するものとして指定され、「２」は、データパケットを受信するものとして指定され、それらのデータパケットの送信は、２つの部分に分割される。１つの実施形態では、パケットを送信することは、Ｗｉ－Ｆｉチャネル（５２４）による「１ａ」およびセルラチャネル（５２５）による「１ｂ」である。

いくつかの実施形態では、「２ａ」は、データパケットをＷｉ－Ｆｉチャネル（５２４）から受信するものとして指定され、「２ｂ」は、データパケットをセルラチャネル（５２５）から受信するものとして指定される。

ここで、図４Ｃを参照すると、本発明は、ＵＤＰ（５１０）のルーティング処理との通信がない実施形態を強調する。１つの実施形態では、フローチャートにおける「１」は、ネットワークソケットを使用してデータパケットをモバイルデバイス（５０２）からターゲットホスト（６００）に送信するものとして指定され、「２」は、受信されたデータパケットとして指定され、それらのデータパケットの送信は、２つの部分に分割される。１つの実施形態では、パケットを送信することは、Ｗｉ－Ｆｉチャネル（５２４）による１ａおよびセルラチャネル（５２５）による１ｂである。

図５～６に示されるように、Ｗｉ－Ｆｉチャネル（５２４）およびセルラチャネル（５２５）は、以下の２つのアプローチのクラス：（ｉ）モバイルデバイス（５０２）がＷｉ－Ｆｉ（５２４）およびセルラ（５２５）接続のために同一のターゲットホスト（６００）の２つの異なるターゲットＩＰ（６０１、６０２）または２つの異なるターゲットホストに接続すること（図５Ａ、６Ａ、５Ｃ、６Ｃ）と、（ｉｉ）モバイルデバイス（５０２）がＷｉ－Ｆｉ（５２４）およびセルラ（５２５）接続のために同一のターゲットホスト（６００）の単一のターゲットＩＰに接続すること（図５Ｂ、６Ｂ）と、に従ういくつかの方法で、ターゲットホスト（６００）と通信するためにモバイルデバイス（５０２）上で同時に使用されてもよい。

ＳＤＫの増大
ソフトウェア専用の解決策を使用して、同一のコンテンツ（例えば、同一のビデオ）をダウンロードまたはアップロードするために同一のデバイスまたはプロキシデバイスのグループのいずれかに属するいくつかのネットワーク接続の帯域幅。以下では、ソフトウェアシステムの１つの実施形態を参照するためにＢＭＶ（ブースティングモバイルビデオ（Ｂｏｏｓｔｉｎｇ Ｍｏｂｉｌｅ Ｖｉｄｅｏ）を使用する。単一のデバイスのネットワーク接続を集約するケースを説明するためにソロモードに言及する。

ソロモードでは、Ａｎｄｒｏｉｄスマートフォン、タブレット、およびビデオプレイヤなど、複数のネットワークインタフェースを有するデバイスによって該当の技術を使用することができる。例えば、ビデオをダウンロードすることを試みる空港内のユーザは、ＷｉＦｉおよびセルラ接続を同時に使用することによってビデオをダウンロードするように空港のＷｉＦｉ接続を自身のセルラ接続に集約するために該当の技術を使用することができる。

この技術の実装方法の例を説明する。図１３における分類に示されるプロトコルスタックのいくつかのレイヤにおいて該当のソフトウェアを配置することができる。まず、アプリケーションレイヤでは、Ａｎｄｒｏｉｄ ａｐｐ ＶｉｄｅｏＢｅｅで行ったのと同様に、スタンドアロンのモバイルアプリケーションを開発することができる。エンドユーザは、特定のアプリケーションのプレイヤの内部でビデオを見るためにＶｉｄｅｏＢｅｅを使用する（ビデオが多くの異なるプロバイダからストリーミングされる場合でさえ）。次に、Ｎｅｔｆｌｉｘモバイルアプリケーションなど、サーバへの複数の経路を使用することによってそれらのモバイル配信を加速化するために他のモバイルアプリケーションによって使用することができるＳＤＫを提供することができる。このケースでは、エンドユーザは、ビデオをいつものように見るためにＮｅｔｆｌｉｘモバイルアプリケーションを使用し、該当の技術は、帯域幅を増加させるためにユーザに対して透過的にまたは明確なパーミッションでバックグランドで使用される（例えば、通知および増大ボタンを通じて）。さらに、オペレーティングシステムレベルにおけるサービスとして該当の技術をユーザおよび他のアプリケーションに対して透過的に実装することができる。そのシナリオでは、サービスは、複数の経路を使用することによってデバイスに着信される全てのＨＴＴＰトラフィックを増大させることができる。

いくつかの実施形態では、ビデオのストリーミングは、ＢＭＶおよびＡＰＩインタフェースを使用する。この実施形態では、ビデオプレイヤ、例えば、Ａｎｄｒｏｉｄシステムの内蔵プレイヤまたはＭＸ－Ｐｌａｙｅｒプレイヤなどの第三者ビデオプレイヤは、図９に示されるように、下記のように進行する。それは、例えば、要求されたネットワークを提供するためにｓｅｔＮｅｔｗｏｒｋｓ（ネットワーク）を呼び出すことによって、ビデオをダウンロードためにどのネットワークインタフェースを使用することを望むかを最初に指定する。次いで、それは、例えば、プログレッシブダウンロード（ビデオｕｒｌ）と呼ばれる関数を呼び出すことによってダウンロードを開始し、再生することを望むビデオのビデオｕｒｌ（ユニフォームリソースロケータ）は、例えば、ｈｔｔｐ：／／ｒｅｍｏｔｅｓｅｒｖｅｒ．ｃｏｍ／ｖｉｄｅｏ．ｍｐ４である。ＢＭＶは、ビデオパーツ（ｖｉｄｅｏ ｐａｒｔｓ）をダウンロードし、それらをキャッシュに一時的に記憶し、ローカルＨＴＴＰプロキシサーバを通じてそれらを供給することによってそれらをローカルに利用可能にする。いくつかの実施形態では、ダウンロードされたパーツは、ローカルＵＲＬである、例えば、ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ／ｖｉｄｅｏ．ｍｐ４から利用可能となる。ビデオプレイヤは最後に、例えば、ｓｅｔＤａｔａＳｏｕｒｃｅ（「ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ／ｖｉｄｅｏ．ｍｐ４」）と呼ばれる関数を呼び出すことによってビデオデータをこのローカルＵＲＬにフェッチするべき位置を設定する必要があり、次いで、このローカルＵＲＬから直接再生するためにビデオパーツをフェッチする。ダウンロードが進行中の間は、ビデオプレイヤはまた、異なるネットワークインタフェースからダウンロードされたデータ、ネットワークインタフェースの速度などを含む、ＢＭＶシステムからの種々の統計を要求することができる。

ダウンロードモジュールは、ビデオパーツをダウンロードすることを担う主なソフトウェアである。いくつかの実施形態では、それは、ＵＲＬリゾルバの支援により複数のネットワーク接続を確立し、それらを同時に使用し、それは、スケジューリングアルゴリズムを使用して各々の接続を通じてどのビデオ範囲をダウンロードするかを管理し、それは、キャッシュ（プログレッシブダウンローディング）または記憶システム（レギュラーダウンローディング）のいずれかを使用してダウンロードされたパーツを記憶する。

図９を参照すると、ＵＲＬリゾルバは、ＢＭＶにおいて重要な役割を果たす。今日のＡｎｄｒｏｉｄデバイス上では、２つのインタフェースの各々が異なるＩＰアドレスに接続している限り、セルラインタフェースおよびＷｉＦｉインタフェースを同時に利用することができる（デバイスをルート化（ｒｏｏｔ）することなく）。よって、課題は、それらのインタフェースの各々を通じて同一のコンテンツのパーツをなおダウンロードする間にどのようにこれを達成することができるかである。該当の新規の見解は、今日の人気のあるコンテンツが、異なるＩＰアドレスを有するいくつかのコンテンツ配信ネットワーク（ＣＤＮ）サーバ（これは、例えば、ＹｏｕＴｕｂｅ、Ａｍａｚｏｎ、ＮｅｔＦｌｉｘなどについてのケースである）に記憶されるという事実を利用することによってそれを行うことができることである。よって、例えば、セルラインタフェースおよびＷｉＦｉインタフェースを、異なるＩＰアドレスを有するが同一のコンテンツを供給する２つの異なるＣＤＮサーバに接続することができる。それを行うことができるように、ＢＭＶがＣＤＮの異なるサーバのＵＲＬアドレスを高速かつ信頼して取得することを可能にする必要がある。これは正確には、ＵＲＬリゾルバが行うことである。１つの実施形態では、ＵＲＬリゾルバは、提供されたＵＲＬ（例えば、ｈｔｔｐ：／／ｒｅｍｏｔｅ‐ｓｅｒｖｅｒ．ｃｏｍ／ｖｉｄｅｏ．ｍｐ４）から開始し、異なるＩＰアドレスに接続する追加のＵＲＬを識別する。これを達成するために、使用することができる技術は、次に説明する２つを含むことができ、どの技術を使用できるかは、アクセスしようとするコンテンツホストに依存することがある。

ＤＮＳリゾルバ：ＢＭＶは、ビデオのホスト名（該当の例では、ｒｅｍｏｔｅ－ｓｅｒｖｅｒ．ｃｏｍの）のＮ個の（Ｎは無線インタフェースの数）異なるＩＰアドレスを発見するために明確なドメイン名解決（ＤＮＳ解決）を実行することができる。次いで、そのたびにホスト名ｒｅｍｏｔｅ－ｓｅｒｖｅｒ．ｃｏｍをＮ個の異なるＩＰアドレスのうちの１つに置き換えることによってＮ個の異なるＵＲＬアドレスを作成することができる。この技術をＤＮＳリゾルバと呼ぶ。該当の例を続けて、ＢＭＶがＩＰアドレス１９２．１６８．１．１および１９２．１６８．１．２を発見すると仮定して、次いで、異なるサーバ上の同一のコンテンツにアクセスする２つのＵＲＬであるｈｔｔｐ：／／１９２．１６８．１．１／ｖｉｄｅｏ．ｍｐ４およびｈｔｔｐ：／／１９２．１６８．１．２／ｖｉｄｅｏ．ｍｐ４を作成することができる。要求された数のＩＰアドレスを高速かつ信頼して取得することを保証するために、ＢＭＶは、以下を含むクエリを実行する。
－ドメイン名の信頼すべき（Ａｕｔｈｏｒｉｔａｔｉｖｅ）ＤＮＳサーバへのクエリ。
－ドメイン名の信頼すべきでないＤＮＳサーバへのクエリ、それらのサーバは、ローカルネットワークＤＮＳサーバとともにＧｏｏｇｌｅ ＤＮＳサーバ、オープンＤＮＳサーバなどの一般のパブリックＤＮＳサーバを含む。
－ホストの潜在的に記憶された（かつ期限切れでない）ＩＰアドレスを発見するためのそのローカルデータベースへのクエリ。このデータベースは、ローカルに利用可能であり、人気のあるビデオプロバイダ、例えば、Ｄａｉｌｙ ｍｏｔｉｏｎの特定のセットのために頻繁に更新される。

１つの実施形態では、クエリは、連続して実行され、プログラムは、十分な数のＩＰアドレスを収集すると停止する。それらのクエリが実行される順序は、アプリケーションおよびユーザの振る舞いに依存することがある。例えば、同一のホストに度々アクセスするユーザには、最も効率的なのは、複数のＩＰアドレスをローカルに記憶し、それらを最初にチェックすることである。

解決ブラウザ（Ｒｅｓｏｌｕｔｉｏｎ Ｂｒｏｗｓｅｒ）：いくつかのホストでは、単純にホスト名をＩＰアドレスに置き換えることでは有効なＵＲＬが得られず、よって、ＤＮＳリゾルバ技術は機能しない。これについての理由は、以下を含む。
－１つ目に、ホストは、その特定のＵＲＬについて計算する署名をＵＲＬの内部に組み込むことができる。署名を更新することなくホスト名を異なるＩＰアドレスに置き換えることは、無効なＵＲＬにつながる。しかしながら、ホストによってのみ署名を計算することができる。例として、署名を含むＹｏｕＴｕｂｅビデオのＵＲＬは、ｈｔｔｐ：／／ｍ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｖｉｄｅｏｌｄ＆ｓｉｇｎａｔｕｒｅ＝ＡＡＡの形式である。
－２つ目に、いくつかのケースでは、ホストはまた、ブラウザの送信元ＩＰアドレスをＵＲＬに挿入し、ブラウザのＩＰアドレスを通じて署名を計算し、それによって、異なるＩＰアドレスを有するクライアントによってＵＲＬが使用されることを防止する。例えば、このフォーマットのＹｏｕＴｕｂｅのビデオのＵＲＬは、ｈｔｔｐ：／／ｍ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｖｉｄｅｏｌｄ＆ｓｏｕｒｃｅ＿ｉｐ＝１．２．３．４＆ｓｉｇｎａｔｕｒｅ＝ＡＡＡである。

異なるインタフェースが異なるＩＰアドレスを有するので、セルラインタフェースを通じてビデオをダウンロードするために、ＷｉＦｉインタフェースを通じてブラウザによって発見されたＵＲＬを使用することはできない。このケースに対処するために、ＢＭＶの１つの実施形態は、解決ブラウザと呼ばれる内蔵ウェブブラウザを特徴とする。解決ブラウザは、同一のビデオの異なるＵＲＬを直接取得するためにページを複数回見ることが可能である（ビデオサーバは、負荷分散を理由に異なるＵＲＬを生成する）。また、それは、異なるネットワークインタフェースを通じてブラウザインスタンスをインスタンス化することができ、よって、そのインタフェースを通じて使用されることになるＵＲＬを直接取得する（例えば、それは、セルラインタフェースで使用されることになるＵＲＬを直接取得するためにセルラインタフェースを使用してウェブページを見る）。例えば、携帯電話上で稼働し、ＷｉＦｉを通じてブラウザを使用するＢＭＶは、ＵＲＬ、ｈｔｔｐ：／／ｐｒｏｘｙ１．ｒｅｍｏｔｅ－ｓｅｒｖｅｒ．ｃｏｍ／ｖｉｄｅｏ．ｍｐ４？ｓｏｕｒｃｅｌＰ＝７．７．７．１＆ｓｉｇｎ＝ＡＡＡＡを取得することができ、セルラを通じてブラウザを使用するＢＭＶは、ＵＲＬである、ｈｔｔｐ：／／ｐｒｏｘｙ２．ｒｅｍｏｔｅ－ｓｅｒｖｅｒ．ｃｏｍ／ｖｉｄｅｏ．ｍｐ４？ｓｏｕｒｃｅｌＰ＝７．７．７．２＆ｓｉｇｎ＝ＢＢＢＢを取得することができ、７．７．７．１は、ＷｉＦｉのＩＰアドレスであり、７．７．７．２は、携帯電話のセルラＩＰアドレスである。ＢＭＶはまた、ｐｒｏｘｙ１．ｒｅｍｏｔｅ－ｓｅｒｖｅｒ．ｃｏｍおよびｐｒｏｘｙ２．ｒｅｍｏｔｅ－ｓｅｒｖｅｒ．ｃｏｍが２つの異なるＩＰアドレス（ＷｉＦｉおよびセルラを同時に使用することが必要な）に対して解決することをチェックすることができる。それらがたまたま同一のＩＰアドレスに対して解決する場合、ＢＭＶは、１つの実施形態では、それが異なるＩＰアドレスを取得するまでインタフェースのうちの１つを通じて見ることを続ける。

ＵＲＬリゾルバ障害：リゾルバが全てのインタフェースのＵＲＬについてあらかじめ定められた制限時間内に発見することができない場合、１つの実施形態では、ＢＭＶは、それが既に有する（ＢＭＶが少なくとも１つのＵＲＬを有する任意のケースにおいてであることに留意）ＵＲＬを利用してダウンロードを開始し、それによって、起動時間が影響されない。いくつかのトリガにおいて、例えば、システムが定常状態に到達するとき（後に説明するように、これは、緊急のブロックが必要とされないことを意味する）、または予め定められた時間ウインドウが経過した場合、ＢＭＶは、インタフェースを維持するためのＵＲＬを取得するためにＵＲＬリゾルバ技術を再開することができる。

ＵＲＬリゾルバが必要とされないとき：クライアントが複数のルーティングテーブルを使用してパケットをルーティングすることができるケースでは、すなわち、送信元に基づくルーティング（異なる送信元ＩＰアドレス、すなわち、異なるネットワークインタフェースのＩＰアドレスに基づく）、またはポリシに基づくルーティングを使用することによって、図７ｃおよび８ｃに示されるように、クライアントが両方のインタフェースを使用して単一のＩＰに直接接続することができるので、ＵＲＬリゾルバが必要とされない。このケースでは、ＵＲＬリゾルバは、各インタフェースを通じて送信されるパケットが適切にサーバにルーティングされることを保証するために、２つのルーティングテーブル（送信元に基づくルーティング）またはルーティングポリシ（ポリシに基づくルーティング）の維持を実行する。

スケジューリングアルゴリズム
該当のスケジューリングアルゴリズムは、１つの実施形態では、コンテンツのどのパーツが各インタフェースを通じてダウンロードされるかを決定し、いくつかの所望の特性を特徴とする。特に、この実施形態では、それは、
－待機および起動時間を最小化する円滑なストリーミングを提供し、
－接続の合計速度に近い速度を達成し、
－チャネル変動および損失の多い接続に対してロバストであり、明確にチャネル統計を記録する必要なく、各インタフェースを通じてコンテンツのどのパーツをダウンロードするかを調節し、
－再生時間に十分に近くない限りコンテンツをダウンロードせず、それによって、ユーザが探索するとき（ユーザが見ようとするビデオのパーツを前または後に変更する）、高速に適合させることができ、
－制限された記憶空間でデバイス上で動作させることができる。

バッファマップは、全てのビデオブロックについての状態を維持する。それは、ビデオブロックの各々が１）ダウンロードされ、および利用可能であるか、２）現在ダウンロード中であるか、または３）消失しているかを記録する。ＢＭＶは、ビデオのいくつかのブロックがキャッシュにおいて利用可能であるかをチェックする。そうである場合、それらをダウンロードされたものとしてマーク付けする。全ての残りのビデオブロックが消失しているものとしてマーク付けされる（ケース３）。

ブロックプールは、ダウンロードしようとしているスライドウインドウで、すなわち、再生時間からの時間Ｗ内で重複する（部分的にでも）ブロックのサブセットをバッファマップに維持する。これは、ダウンロードのためにスレッドに利用可能なブロックのセットである。最初に、それは、全てのブロックを時間ゼロ（ビデオの開始時間）から時間Ｗ内に含む。ブロックプールは、順序付けられたセットであり、再生時間により近いブロックを最初に供給する。

緊急プールは、次のアルゴリズムで説明するように、緊急に必要とされ、２つ以上のスレッドが並列にダウンロードを試みることを可能にするブロックのセットの維持するブロックプールのサブセットである。緊急プールはまた、最初に供給される再生時間により近いブロックを有する順序付けられたセットである。緊急プールは、空であることがあり、この望ましい状態を「定常状態」と呼ぶ。最初に、緊急プールは、ビデオを再生することを開始するために必要な最初のＳ個のブロックを含み、Ｓは、指定されたパラメータである。緊急プールのサイズは、セーフティパディング時間と呼び、また、スケジューリングアルゴリズムへの入力として指定されるパラメータΔの関数である。ＳおよびΔは、ＢＭＶまたはユーザによって指定されることがあり、デバイス、コンテンツおよび無線状態の関数であることができる。

１つの実施形態では、クエリが連続して実行され、プログラムは、十分な数のＩＰアドレスを収集すると停止する。それらのクエリが実行される順序は、アプリケーション、およびユーザの振る舞いに依存することがある。例えば、ユーザが同一のホストに度々アクセスするために、最も効率的なのは、複数のＩＰアドレスをローカルに記憶し、それらを最初にチェックすることである。

アルゴリズム
入力：パラメータＳ、Δ、Ｗ、Ｔ１、Ｔ２、Ｔ３。初期状態：バッファマップにおける全てのブロックが消失しているとしてタグ付けされる。ブロックプールは、開始時間からのＷ内である全てのブロックを含む。緊急プールは、開始時間からの最初のＳ個のブロックを含む。

キャッシュからの取り出し：
－ＢＭＶは、キャッシュがブロックのいくつかをバッファマップに既に有しているかをチェックし、そのようなブロックを発見した場合、バッファマップにおいてそれらをダウンロードされたものとしてタグ付けする。

スレッドダウンローディング
－各々のアクティブなスレッドは、緊急プールを最初にチェックし、それが空である場合、次いで、ブロックプールをチェックし、それが空である場合、それはスリープする。緊急プールまたはブロックプールに追加される新たなブロックがある場合、全てのスレッドが通知される（スリープから起動し、再度チェックする）。
－緊急プールが空でない場合、スレッドは、最初のブロックをとり、それをダウンロードすることを試み、それがダウンロードされると、それはブロックをキャッシュシステムに渡し、バッファマップにおいてブロックをダウンロードされたものとしてタグ付けする。ＢＭＶは、ブロックを緊急プールから削除する。複数のスレッドがダウンロードする最初の緊急ブロックを同時に選択することができることに留意されたい。同一のブロックをダウンロードすることを試みるスレッドの数を、インタフェースごとに最大で１つに制限する。
－緊急プールが空であるが、ブロックプールが空でない場合、スレッドは、ブロックプールにおいて最初のブロックをとる。スレッドは、バッファマップ上で、ブロックが消失しているか、またはダウンロード中であるかをチェックし、消失している場合、それをダウンロード中であるとしてマーク付けし、それをサーバから要求することを進行させ、それがダウンロード中である場合、ブロックプールに戻り、第２のブロックをチェックする。それが消失しているブロックを発見するまでこの方式で継続する。それがブロックをダウンロードすると、それをキャッシュシステムに渡し、バッファマップにおいてそれをダウンロードされたものとしてマーク付けする。ＢＭＶは、それをブロックプールから削除する。

プール更新：Ｔ１秒ごとに、ＢＭＶは、現在の再生時間をチェックし、再生時間が進行している場合にプール更新を実行する。プール更新の実行は代わりに、ＢＭＶによる新たな再生時間の受信（ビデオプレイヤからの）によってトリガされてもよい。プール更新は以下のように行われる：
－緊急プールまたはブロックプールにおけるブロックが現在の再生時間よりも前である場合、それを削除する。同様に、ブロックが再生時間の後のＷ内でない場合、それも削除する。そのようなケースは、ユーザが再生時間を探索し、前または後に変更するときに発生することがある。
－それは、バッファマップにおいてダウンロードされたものとしてマーク付けされておらず、再生時間からのＷ内である（部分的にでも）全てのブロックをブロックプールに追加する。
－それは、再生時間のΔ内である全ての消失しているブロックを緊急プールに追加する。
－それは、バッファマップにおいてスレッドによってダウンロード中であるとしてタグ付けされた各ブロックをチェックし、それを緊急プールに移動させるかを決定するために以下のテストを使用する。Ｐは、ブロックが再生されるまでのビデオの経過時間を表す。ＢＭＶは、推定されるネットワークインタフェースの速度を、このインタフェースのアクティブなスレッドの数およびブロックサイズの積で乗算することによって、スレッドがブロックをダウンロードするための推定時間Ｄを計算する。Ｄ＋Δ＜Ｐの場合、ＢＭＶは、ブロックを緊急プールに移動させ、バッファマップ上でそれを消失しているものとしてマーク付けする（それによって他のスレッドがそれを選択することができる）。

統計エンジン
－ＢＭＶは、Ｔ２秒ごとに、最後のＴ４秒の間にインタフェースを通じてダウンロードされるデータの量を合計することによって、インタフェースごとの推定されるネットワークインタフェースの速度を含む統計を計算し、Ｔ４についての典型的な値は、１、１０、２０、３０秒である。それを可能にするために、図の［プログレッシブダウンローディングＡＰＩ］に示されるように、どのスレッドが統計エンジンにおいてどのブロックをダウンロードしたかを記録する。

スレッド失敗：ビデオをダウンロードしている間に、スレッドのうちの１つまたは複数が接続を損失する可能性があり、例えば、セルラおよびコーヒーショップから出るＳｔａｒｂｕｃｋｓのＷｉＦｉに接続されたユーザを考える。そのポイントでは、ＳｔａｒｂｕｃｋｓのＷｉＦｉネットワークを損失することがあるが、セルラネットワーク（なお、屋外である）はより強くなることがある。１つの実施形態では、ＢＭＶは、１つまたは複数のスレッドが失敗するときにビデオをダウンロードすることを停止せず、残りのブロックを選択する他のスレッドを通じてダウンロードを継続する。よって部分的なネットワーク損失は、ユーザ経験を中断しない。

他のユーザは、スケジューリングについて選択し、接続の合計速度を達成する代わりに、他のユーザ定義基準を達成するようにアルゴリズムを容易に修正することができ、例えば：
－データプランの上限設定：ユーザは、データプラン（セルラ接続）を制限までのみ使用することを望み、次いで、通知されることを指定することができる。ＢＭＶは、統計エンジンにおいて各スレッドによってダウンロードされたデータの量を記録し、上限に達すると、それは、ユーザに通知し、セルラスレッドを停止する。
－データプランの節約：ＢＭＶはまた、緊急ウインドウ内、または再生時間からの時間Ｗ１＜Ｗ内のいずれかであるブロックのみをセルラスレッドがダウンロードすることを可能にすることによって、データプランの節約を実現することができ、すなわち、ＢＭＶは、Ｗｉ－Ｆｉ接続からのセグメントを優先的にダウンロードし、Ｗｉ－Ｆｉ接続がＷ１内で必要なセグメントをダウンロードすることを管理しなくなった場合のみセグメントをセルラ接続に割り当てる。
－バッテリ。同様に、ＢＭＶは、バッテリレベルを入力として受け、バッテリが特定の閾値を上回る限り、制限された数のインタフェース上でのみスレッドのダウンロードをアクティブにする（ユーザに通知する）。
－通常ダウンロード：緊急プールをこれ以上維持しない。全てのブロックは、ブロックプールに配置され、連続して選択され、スレッドによってダウンロードされる。全てのブロックがダウンロードされ、またはダウンロード中である場合、失敗したスレッドに起因して不完全なダウンロードを回避するために、ダウンロードしているスレッドの推定されるダウンロード時間Ｄを上回ってダウンロードしていたブロックをスレッドが選択することを可能にする。
－スレッドは、ダウンロードされたブロックをキャッシュシステムの代わりに記憶システムに提供する。

ＢＭＶのキャッシュシステムは、１つの実施形態では、カスタムデータベースおよびファイルシステムを組み合わせることによって、複数のスレッドによって同時にダウンロードされたブロックを効率的に記憶およびクエリすることをサポートするように設計される。小さいファイルの記憶。この実施形態では、基本的な着想は、同一のファイルの内部にビデオの全てのブロックを収集する代わりに、各ブロックがファイルシステムにおける異なる小さいファイルに記憶されることである。結果として、複数のスレッドは、相互に妨害することなくファイルシステムに同時に書き込む（またはそれから読み出す）ことができる（それらが同一のファイルへの書き込みを試みる場合に行うように）。各スレッドは、ブロックに関するメタデータを保持するカスタムデータベーステーブルに行、例えば、ビデオ識別子、開始バイト、終了バイト、長さ、アクセス時間とともにブロックのデータを含む小さいファイルへのポインタを最初に挿入し、それは次いで、ブロックをファイルシステムに記憶することを進行させる。このアプローチは、ビデオについての単一のファイルを保持する従来のアプローチと比較してより高速な書き込み時間を提供する。これは、後者のアプローチでは、ブロックを書き込むことは、ファイルへのランダムな書き込みを伴い、それは、探索が含まれることになるので著しく長い時間を要するからである。プログレッシブモードをサポートするために、キャッシュシステムはまた、図の［プログレッシブダウンローディングＡＰＩ］に示されるように、キャッシュにおいて利用可能なメタデータおよびビデオのデータ範囲をＨＴＴＰプロキシサーバによって取り出すことができるクエリインタフェースを提供する。

退去（ｅｖｉｃｔｉｏｎ）ポリシ：制約された記憶空間を有するデバイスをサポートするために、キャッシュシステムは、構成可能な最大サイズ、例えば、５０メガバイト、所与の時に記憶することができるデータの最大量を有してもよい。スレッドが新たなブロックをキャッシュに書き込むことになり、キャッシュの空きが不足しているとき、新たな１つのための空きを作るためにいくつかの記憶されたデータを退去させる必要がある。キャッシュシステムの重要な設計選択は、その退去ポリシである。ＢＭＶキャッシュシステムは、その目標が円滑な再生をサポートするためにほとんどの関連するデータを常に保持することである新規なキャッシュ退去ポリシを含む。特に、キャッシュがデータを退去させる必要があるとき、１つの実施形態では、それは最初に：
－直近にアクセスされたビデオから始まって、現在再生しているビデオ以外のビデオの記憶されたブロックを退去させる（現在再生しているビデオは直近にアクセスされたものである）。
－そのようなデータが存在しない場合、それは、現在の再生時間の前に再生しているビデオのデータを退去させる。ダウンロードしているときの該当のスライドウインドウのサイズは、キャッシュが記憶することができるよりも多くのデータをダウンロードしないことを保証する。しかしながら、ユーザが探索の間にジャンプする場合、該当のポリシがわずかに変化する。現在の再生時間とは別に、ジャンプの前に最後に再生された時間をも記録する。ジャンプの前の最後に再生された時間の前である最初のブロックを退去させ、それらが消耗しているとき、現在の再生時間の前に、かつ最後に再生された時間からできるだけ離れたブロックを退去させる。このようにして、ユーザが戻ることを決めるケースについて、ユーザが見ることを停止したものに近いできるだけ長いブロックについて維持する。

記憶システム：レギュラーダウンローディングをサポートするために、ＢＭＶは、ダウンロードされたビデオデータをファイルシステムに永続的に記憶することを担う記憶システムを有する。１つの実施形態では、記憶システムの設計および実装は、記憶システムが退去ポリシを有さないこと除いてキャッシュシステムと同様である。記憶システムの主なカスタム機能は、複数のスレッドからの効率的な書き込みをサポートすることである。ビデオが完全にダウンロードされる場合、記憶システムは、ビデオの全てのデータを内蔵型再生可能ビデオファイルにエクスポートすることを可能にする。

ＨＴＴＰプロキシサーバ：プログレッシブダウンローディングをサポートするために、ＢＭＶは、ＢＭＶの支援を要求したビデオプレイヤにダウンロードモジュールによってダウンロードされたビデオブロックを供給する、ＨＴＴＰプロキシサーバを提供する。１つの実施形態では、サーバは、ＨＴＴＰ１．１プロトコルに従って、ビデオプレイヤのＨＴＴＰ範囲要求に応答する。１つの実施形態では、サーバは、複数の要求に同時に対処することが可能である。１つの実施形態では、ＨＴＴＰプロキシサーバは、現在の再生時間を推測し、ダウンロードモジュールに通知するためにビデオプレイヤのＨＴＴＰ範囲要求を使用する。

ＢＭＶのコンポーネントはともに作動し、プログレッシブダウンローディングインスタンスの例を考えると、ビデオプレイヤはＡＰＩと通信し、プログレッシブモードでＢＭＶを起動させ、ＨＴＴＰプロキシサーバは、起動し、ローカルアドレス、例えば、ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ／またはｈｔｔｐ：／／１２７．０．０．１をビデオプレイヤに提供する。ダウンロードモジュールは、ブロックをダウンロードし、それらをキャッシュシステムに記憶する。ビデオプレイヤが再生のためにメタデータまたはビデオの範囲をフェッチするためにローカルアドレスを示すとき、ＨＴＴＰプロキシサーバは、要求されたデータについてキャッシュシステムをクエリし、ビデオプレイヤに応答する。この実施形態はまた、図９に示される。

ＢＭＶは、ＨＬＳビデオのダウンロード（ライブストリーミング）をサポートする。ＨＬＳビデオは、単一のファイルではないが、代わりに、．ｍ３ｕ８インデックスファイルおよび．ｔｓセグメントファイルを含む、ファイルの集合から構成される。プログレッシブダウンローディング（ライブストリーミングイベントのケースにおける）およびレギュラーダウンローディング（ＨＬＳフォーマットに記憶された事前に記録されたイベントのケースにおける）の両方においてＨＬＳビデオをダウンロードするためにＢＭＶを使用することができる。１つの実施形態では、ステップは、通常のビデオについてのステップと非常に類似している（図１１も参照）。主な差異は、インデックス（．ｍ３ｕ８）ファイルを最初に取得し、次いで、ＨＬＳビデオに追加される最後のセグメントを学習するためにインデックスファイルをサーバからリフレッシュすることである。特に、この実施形態では：
－ビデオプレイヤは、（ｉ）ｓｅｔＮｅｔｗｏｒｋｓ（ネットワーク）などの関数を呼び出すことによってダウンロードするためにどのネットワークを使用するかをＢＭＶに通知し、（ｉｉ）プログレッシブダウンロード（ｖｉｄｅｏＵｒｌ）と命名する関数を呼び出すことによってダウンロードを開始することをＢＭＶに通知し、（ｉｉｉ）ｓｅｔＤａｔａＳｏｕｒｃｅ（）と命名する関数を呼び出すことによってプレイヤのデータの送信元をＨＴＴＰプロキシサーバに示す。
－最初に、ｖｉｄｅｏＵＲＬは、インデックス（．ｍ３ｕ８）ファイルへのＵＲＬである。インデックスファイルは、セグメントについてのＵＲＬへのポインタを含む。ライブストリーミングでは、インデックスファイルは、より多くのビデオセグメントがオンラインで追加されるにつれて更新され、したがって、ＢＭＶは、最新のバージョンのインデックスファイルを定期的にダウンロードする。ＢＭＶは、インデックスファイルをダウンロードおよびリフレッシュするためにＷｉＦｉインタフェースを一貫して使用する（デバイスがセルラ専用モードで動作していない限り）。
－インデックスファイルをダウンロードするために使用されるＵＲＬは、それらが典型的にはインデックスファイルと同一のサーバに記憶されるので、セグメントをダウンロードするために度々再使用されてもよい。ＢＭＶは、解決されたＵＲＬのリソース部分を置き換えることによって、すなわち、インデックスファイル名を適切なセグメントファイル名と置き換え、次いで、結果として生じるＵＲＬが有効であるかをチェックすることによって、セグメントＵＲＬを作成するためにこれを利用する。ＢＭＶは、残りの必要とされるＵＲＬを識別するためにＵＲＩリゾルバを採用する。
－各セグメントは、以前のビデオと同一の方法で取り扱われる。特に、セグメントは、バッファマップ、ブロックプールおよび緊急プールに追加されるブロックに分割される。スレッドは、異なるインタフェースを通じてセグメントブロックをダウンロードする。セグメントがキャッシュに完全にダウンロードされると、それは、要求されるといつでも、ＨＴＴＰプロキシサーバに、次いで、ビデオプレイヤにフェッチされる準備がされる。
－セグメントは、現在の再生時間により近い１つから始まって（前の方向での）、１つずつダウンロードされる。インデックスファイルをリフレッシュするとき、ＢＭＶは新たなセグメントを認識するので、それは、それらのダウンロードを連続してスケジュールする。

ＢＭＶはまた、適応的（品質）ストリーミングをサポートする。このケースでは、ＨＬＳビデオの複数のストリームを有し、その各々が異なる品質のビデオに対応する。各ストリームはそれ自身のセグメントを有する。ＨＴＴＰプロキシサーバがビデオデータをどの程度高速に供給するかに応じて、ビデオプレイヤはその選択された品質を適合させることができ、すなわち、供給するためのより高いまたはより低い品質のビデオを選択することができる。ＢＭＶは、１つの実施形態では、ＨＴＴＰプロキシサーバに、ビデオプレイヤの現在選択されているストリームをＨＬＳエンジンに通知させることによって適応的ストリーミングをサポートする。通知は、黙示的に行うことができ、例えば、ビデオプレイヤは、ＨＴＴＰプロキシからの特定の品質のセグメントを要求し、プロキシは、これを学習し、次いで、要求された品質のセグメントを取得することをＨＬＳエンジンに通知する。実施形態では、ＨＬＳエンジンは、対応するストリームからの要求された品質のセグメントのダウンロードを開始する。レギュラーダウンローディングについて、ＢＭＶは、１つの実施形態では、前のと同様の手順を使用して、ＨＬＳビデオを取得するためにＨＬＳエンジンを使用することができる。差異は以下を含む：１つ目に、ＨＬＳエンジンは、インデックスファイル（．ｍ３ｕ８）を、このファイルがなおも静的であり、１回のみフェッチされる必要があるので定期的にフェッチする必要がなく、２つ目に、ストリームの品質は、それがダウンロードを開始するとき、すなわち、図１２に示されるように、通常のダウンロード（ｖｉｄｅｏＵｒｌ、ストリーム品質）を呼び出すことによって指定される必要がある。

ＶｉｄｅｏＢｅｅ：ＢＭＶプログレッシブおよびレギュラーダウンローディングは、ＶｉｄｅｏＢｅｅ［１１］と呼ばれる、ａｎｄｒｏｉｄアプリケーションに実装およびテストされている。ＶｉｄｅｏＢｅｅからのスクリーンショットが図１３に提示される。ＶｉｄｅｏＢｅｅは、学術界および産業の両方によって非常に受け入れられている［１５～２０］。単一の電話のみが利用可能であるとき、ＶｉｄｅｏＢｅｅは、セルラのみ、ＷｉＦｉのみ、またはセルラおよびＷｉＦｉの両方（ソロモード）を使用してビデオをダウンロードすることができる。第２の電話が近くにある場合、ＶｉｄｅｏＢｅｅは、Ｂｌｕｅｔｏｏｔｈを通じて２つのデバイスを接続し（グループモード）、第１の電話のダウンロードレートを増大させるために第２の電話のインターネット接続（セルラ、ＷｉＦｉ、またはデュアル）を使用する（ベータテストの目的で、グループサイズを現在２に制限している）。両方のケースでは、主要なデバイスは、全ての接続の合計まで加速化したダウンロードを享受する。図９は、実験室においてＶｉｄｅｏＢｅｅのテストされた性能を示す。ＶｉｄｅｏＢｅｅは、単一のデバイスがそのＷｉＦｉおよびセルラ接続の合計速度においてダウンロードすることを可能にし、２つのデバイスのグループがそれらの２つのセルラ接続の合計速度においてダウンロードすることを可能にしている。

ベータテスタのフィードバック：ＶｉｄｅｏＢｅｅは、アクセスコードが与えられるときのみユーザがＶｉｄｅｏＢｅｅを実行するときに、非常に成功したクローズドベータテスト期間を得ている。それは３０００のユーザを魅了し、それらは該当の技術の早くからの適合者であり、肯定的なフィードバックを与えることを非常に熱望している。

実性能：２０１３年１２月の下旬、クローズドベータ期間を完了し、それをＧｏｏｇｌｅ Ｐｌａｙ ｓｔｏｒｅ［１１］からダウンロードすることによって誰もがＶｉｄｅｏＢｅｅを試すことができるオープンベータを開始している。これまでに、一意なアプリケーションユーザは１５０００に達し、１週間ごとに平均すると３０００の新規ユーザである。また、何千ものユーザによって使用されるときにＶｉｄｅｏＢｅｅ性能をそのままで収集するために、モニタモジュールを開発し、それを業界最高レベルＦｌｕｒｒｙ分析エンジン［２１］に統合している。図１０～１２は、ソロモード（ＷｉＦｉおよびセルラの両方による）ならびにグループモードをそれぞれ使用するときにユーザがどの程度高速にダウンロードすることができるかを示す。特に、該当の収集された統計から、ソロモードは、ダウンロードの速度を１．５倍の平均増大率および０．５メガビット／秒の平均増大率（グラフには示されない）を有する最大で２．６倍に増大させることができ、グループモードは、ダウンロードの速度を１．４倍の平均増大率および０．５メガビット／秒の平均増大率（グラフには示されない）を有する最大で６．１倍に増大させることができる。それらの実性能は、該当の技術を使用することによって得られる性能を立証する。正確な規模は、利用可能な接続の帯域幅に依存するが、ＶｉｄｅｏＢｅｅの増大効果は、実際には付加的なものである。

アップロード：１つの実施形態におけるアップロードのために使用される技術は、ダウンロードのために使用される技術と対称的である。方法の同様のステップを繰り返すことなく、主な差異は、以下を含む。

サーバ：１つの実施形態では、ＢＭＶサーバ（それらのいくつかを維持することができる）または第三者サーバ（例えば、Ｆａｃｅｂｏｏｋサーバ）にアップロードすることができる。サーバは、アップロードされたブロックを単純に収集し、それらを範囲の順序で単一のファイルに結合するＢＭＶソフトウェアを実行する。１つの実施形態では、それを行うために、ブロックがアップロードされると、サーバは、指定されたメインサーバ上の単一のファイルにおける全てのアップロードされたブロックを収集するために相互に通信する。ファイルが結合されると、ＢＭＶサーバを使用している場合、１つの実施形態では、メインＢＭＶサーバは次いで、ユーザがアップロードされることを要求した位置（例えば、Ｙｏｕｔｕｂｅまたはパーソナルコンピュータ）にビデオを転送する。別の実施形態として、サーバは、それらが消失した全てのブロックを交換し、よって、それらは、アップロードされたビデオを全て再構築する。

ソロモード：１つの実施形態では、ソロモードにおいて、ＢＭＶは、複数のインタフェースおよびスレッドを確立し、ここで各インタフェースは、ＢＭＶサーバ（検索なしでアプリケーションの内部で直接提供される）または第三者サーバ（協働する第三者によって再度提供しており、または前と同一の技術で取得される）のうちの１つのＵＲＬに接続される。アップロードでは、レギュラーアップローディングモードをサポートする。１つの実施形態では、ＢＭＶは、ビデオをブロックに分割し、スレッドは、ブロックを選択し、それをサーバに１つずつアップロードし、バッファマップは、どのブロックがアップロードされたか、どのブロックが消失しているかを記録する。

本明細書で使用されるように、用語「約（ａｂｏｕｔ）」は、言及した数のプラスまたはマイナス１０％を指す。

本明細書で説明されたものに加え、発明の種々の変更例が上述した説明から当業者にとって明らかである。そのような変更例はまた、添付の特許請求の範囲内にあることが意図される。本出願で示された各参考文献は、その全体を参照することによって本明細書に組み込まれる。

本発明の好ましい実施形態が示され、および説明されてきたが、添付の特許請求の範囲を逸脱せずに修正例がそれらになされてもよいことが当業者にとって容易に明らかである。したがって、本発明の範囲は、以下の特許請求の範囲によってのみ限定される。特許請求の範囲に記載される参照符号は例示的であり、特許庁による検討を容易にするためのみのものであり、決して限定するものではない。いくつかの実施形態では、本特許出願で提示された図面は、角度、大きさの比率などを含む、縮尺通りに描かれている。いくつかの実施形態では、図面は単なる表現であり、特許請求の範囲が図面の大きさによって限定されない。いくつかの実施形態では、フレーズ「備える（ｃｏｍｐｒｉｓｉｎｇ）」を使用して本明細書で説明された発明の説明は、「から構成される（ｃｏｎｓｉｓｔｉｎｇ ｏｆ）」として説明されてよいも実施形態を含み、それによって、フレーズ「から構成される」を使用した本発明の１つまたは複数の実施形態を特許請求する記載要件が満たされる。

参考文献
［１］Ｃｉｓｃｏ，「Ｃｉｓｃｏ Ｖｉｒｔｕａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｉｎｄｅｘ：Ｇｌｏｂａｌ Ｍｏｂｉｌｅ Ｄａｔａ Ｔｒａｆｆｉｃ Ｆｏｒｅｃａｓｔ Ｕｐｄａｔｅ，２０１２－２０１７，」ｈｔｔｐ：／／ｗｗｗ．ｃｉｓｃｏ．ｃｏｍ／ｅｎ／ＵＳ／ｓｏｌｕｔｉｏｎｓ／ｃｏｌｌａｔｅｒａｌ／ ｎｓ３４１／ｎｓ５２５／ｎｓ５３７／ｎｓ７０５／ｎｓ８２７／ｗｈｉｔｅ＿ｐａｐｅｒ＿ｃ１１－５２０８６２．ｈｔｍｌ（２０１４年１月３０日に参照）。
［２］ＣＮｅｔ Ｎｅｗｓ，「Ｃａｎ Ａｐｐｌｅ’ｓ Ａｐｐ Ｓｔｏｒｅ ｍａｉｎｔａｉｎ ｉｔｓ ｌｅａｄ ｏｖｅｒ Ｇｏｏｇｌｅ Ｐｌａｙ？，」ｈｔｔｐ：／／ｎｅｗｓ．ｃｎｅｔ．ｃｏｍ／８３０１－１０３５＿３－５７５２１２５２－９４／ｃａｎ－ａｐｐｌｅｓ－ａｐｐ－ｓｔｏｒｅ－ｍａｉｎｔａｉｎ－ｉｔｓ－ｌｅａｄ－ｏｖｅｒ－ｇｏｏｇｌｅ－ｐｌａｙ（２０１４年１月３０日に参照）。
［３］ＡＴ＆Ｔ Ｎｅｗｓ Ｒｅｌｅａｓｅ，「ＡＴ＆Ｔ ｔｏ Ｉｎｖｅｓｔ ＄１４ Ｂｉｌｌｉｏｎ ｔｏ Ｓｉｇｎｉｆｉｃａｎｔｌｙ Ｅｘｐａｎｄ Ｗｉｒｅｌｅｓｓ ａｎｄ Ｗｉｒｅｌｉｎｅ Ｂｒｏａｄｂａｎｄ Ｎｅｔｗｏｒｋｓ，Ｓｕｐｐｏｒｔ Ｆｕｔｕｒｅ ＩＰ Ｄａｔａ Ｇｒｏｗｔｈ ａｎｄ Ｎｅｗ Ｓｅｒｖｉｃｅｓ」，ｈｔｔｐ：／／ｗｗｗ．ａｔｔ．ｃｏｍ／ｇｅｎ／ｐｒｅｓｓ－ｒｏｏｍ？ｐｉｄ＝２３５０６＆ｃｄｖｎ＝ｎｅｗｓ＆ｎｅｗｓａｒｔｉｃｌｅｉｄ＝３５６６１（２０１４年１月３０日に参照）。
［４］Ｎｅｔｆｌｉｘ，「Ｉｎｔｅｒｎｅｔ Ｃｏｎｎｅｃｔｉｏｎ Ｓｐｅｅｄ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎｓ，」ｈｔｔｐｓ：／／ｓｕｐｐｏｒｔ．ｎｅｔｆｌｉｘ．ｃｏｍ／ｅｎ／ｎｏｄｅ／３０６（２０１４年１月３０日に参照）。
［５］ＹｏｕＴｕｂｅ，「Ａｄｖａｎｃｅｄ ｅｎｃｏｄｉｎｇ ｓｅｔｔｉｎｇｓ，」ｈｔｔｐｓ：／／ｓｕｐｐｏｒｔ．ｇｏｏｇｌｅ．ｃｏｍ／ｙｏｕｔｕｂｅ／ａｎｓｗｅｒ／１７２２１７１？ｈｌ＝ｅｎ（２０１４年１月３０日に参照）。
［６］Ａｋａｍａｉ，「Ｔｈｅ ｓｔａｔｅ ｏｆ ｔｈｅ ｉｎｔｅｒｎｅｔ，」ｖｏｌｕｍｅ ４，Ｎｏ．４，４ｔｈ ｑｕａｒｔｅｒ ２０１２ ｒｅｐｏｒｔ。
［７］Ｌ．Ｋｅｌｌｅｒ，Ａ．Ｌｅ，Ｂ．Ｃｉｃｉ，Ｈ．Ｓｅｆｅｒｏｇｌｕ，Ｃ．Ｆｒａｇｏｕｌｉ，Ａ．Ｍａｒｋｏｐｏｕｌｏｕ，「Ｍｉｃｒｏｃａｓｔ：Ｃｏｏｐｅｒａｔｉｖｅ Ｖｉｄｅｏ Ｓｔｒｅａｍｉｎｇ ｏｎ Ｓｍａｒｔｐｈｏｎｅｓ，」ｉｎ ＡＣＭ ＭｏｂｉＳｙｓ ２０１２，Ｌａｋｅ Ｗｏｏｄ，ＵＫ，Ｊｕｎｅ ２０１２。
Ｆｉｒｓｔ ｐｌａｃｅ ｉｎ ＡＭＡＳＥ（ｍｏｂｉｌｅ ａｐｐｓ） ｃｏｍｐｅｔｉｔｉｏｎ，ＵＣＩ，Ｊｕｎｅ ２０１２。
Ｔｏｐ ５ ｐａｐｅｒｓ ｉｎ ＡＣＭ Ｍｏｂｉｓｙｓ ２０１２，Ｊｕｎｅ ２０１２。
Ｍｉｃｒｏｃａｓｔ ｒｅｓｅａｒｃｈ ｐｒｏｊｅｃｔ：ｈｔｔｐ：／／ｍｉｃｒｏｃａｓｔ．ｃａｌｉｔ２．ｕｃｉ．ｅｄｕ
［８］Ｎａｔｉｏｎａｌ Ｓｃｉｅｎｃｅ Ｆｏｕｎｄａｔｉｏｎ ｌ－Ｃｏｒｐｓ Ａｗａｒｄ １２５８８６６，「ＭｉｃｒｏＣａｓｔ：Ｃｏｏｐｅｒａｔｉｖｅ Ｎｅｔｗｏｒｋｉｎｇ ｏｆ Ｍｏｂｉｌｅ Ｄｅｖｉｃｅｓ，」Ｓｅｐｔｅｍｂｅｒ ２０１２。
［９］ＡＭＡＳＥ Ｃｏｍｐｅｔｉｔｉｏｎ（「Ａ Ｍｏｂｉｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｓｈｏｗｃａｓｅ Ｅｖｅｎｔ」），Ｓｃｈｏｏｌ ｏｆ ＩＣＳ，ＵＣ Ｉｒｖｉｎｅ，Ｊｕｎｅ ２０１２，ｈｔｔｐ：／／ｗｗｗ．ｉｃｓ．ｕｃｉ．ｅｄｕ／ｃｏｍｍｕｎｉｔｙ／ｅｖｅｎｔｓ／ａｍａｓｅ／ｉｎｄｅｘ．ｐｈｐ（２０１４年１月３０日に参照）。
［１０］Ｎａｔｉｏｎａｌ Ｓｃｉｅｎｃｅ Ｆｏｕｎｄａｔｉｏｎ ＳＢＩＲ Ｐｈａｓｅ Ｉ Ａｗａｒｄ １３１５１０６，「Ｍｉｃｒｏｃａｓｔ：Ｃｏｏｐｅｒａｔｉｖｅ Ｖｉｄｅｏ Ｄｅｌｉｖｅｒｙ ｔｏ Ｍｏｂｉｌｅ Ｄｅｖｉｃｅｓ，」Ｊｕｎｅ ２０１３。
［１１］Ａｎｄｒｏｉｄ Ａｐｐ ＶｉｄｅｏＢｅｅｈｔｔｐｓ：／／ｐｌａｙ．ｇｏｏｇｌｅ．ｃｏｍ／ｓｔｏｒｅ／ａｐｐｓ／ｄｅｔａｉｌｓ？ｉｄ＝ｃｏｍ．ｓｈｏｅｌａｃｅｗｉｒｅｌｅｓｓ．ａｐｐ．ｖｉｄｅｏｂｅｅ（２０１４年１月３０日に参照）。
［１２］Ｂｕｓｉｎｅｓｓ Ｉｎｓｉｄｅｒ，「Ｈｅｒｅ’ｓ Ｗｈａｔ Ｐｅｏｐｌｅ Ａｒｅ Ａｃｔｕａｌｌｙ Ｗａｔｃｈｉｎｇ Ｏｎ Ｔｈｅｉｒ Ｓｍａｒｔｐｈｏｎｅｓ Ａｎｄ Ｔａｂｌｅｔｓ，Ａｓ ＴＶ Ｇｏｅｓ Ｍｏｂｉｌｅ，」ｈｔｔｐ：／／ｗｗｗ．ｂｕｓｉｎｅｓｓｉｎｓｉｄｅｒ．ｃｏｍ／ｍｏｂｉｌｅ－ｖｉｄｅｏ－ｒｅｐｏｒｔ－２０１３－１２（２０１４年１月３０日に参照）
［１３］Ｃｏｎｖｉｖａ，「Ｖｉｅｗｅｒ Ｅｘｐｅｒｉｅｎｃｅ Ｒｅｐｏｒｔ，２０１２」Ｆｅｂ ２０１３。
［１４］Ｅｎｇａｄｇｅｔ，「ＹｏｕＴｕｂｅ Ａｎｄｒｏｉｄ ａｐｐ ｕｐｄａｔｅ ｂｒｉｎｇｓ ＨＤ ｖｉｄｅｏ ｓｔｒｅａｍｉｎｇ ｔｏ ｃａｐａｂｌｅ ２．２＋ ｄｅｖｉｃｅｓ，」ｈｔｔｐ：／／ｗｗｗ．ｅｎｇａｄｇｅｔ．ｃｏｍ／２０１２／０３／０２／ｙｏｕｔｕｂｅ－ａｎｄｒｏｉｄ－ａｐｐ－ｕｐｄａｔｅ－ｂｒｉｎｇｓ－ｈｄ－ｖｉｄｅｏ－ｓｔｒｅａｍｉｎｇ－ｔｏ－ｃａｐａｂｌｅ／（２０１４年１月３０日に参照）。
［１５］ＣＴＩＡ，「ＣＴＩＡ Ａｎｎｏｕｎｃｅｓ Ｓｔａｒｔｕｐ Ｔｈｒｏｗ Ｄｏｗｎ Ｗｉｎｎｅｒｓ ａｔ ＣＴＩＡ ２０１３，」ｈｔｔｐ：／／ｗｗｗ．ｃｔｉａ．ｏｒｇ／ｒｅｓｏｕｒｃｅ－ｌｉｂｒａｒｙ／ｐｒｅｓｓ－ｒｅｌｅａｓｅｓ／ａｒｃｈｉｖｅ／ｃｔｉａ－ｓｔａｒｔｕｐ－ｔｈｒｏｗ－ｄｏｗｎ－ｗｉｎｎｅｒｓ－ｃｔｉａ－２０１３（２０１４年１月３０日に参照）。
［１６］ＶｉｄｅｏＢｅｅ－Ｓｅｃｏｎｄ Ｂｅｓｔ Ｍｏｂｉｌｅ Ａｐｐ Ａｗａｒｄ，ＡＣＭ Ｍｏｂｉｃｏｍ Ｍｏｂｉｌｅ Ａｐｐ Ｃｏｍｐｅｔｉｔｉｏｎ，２０１３ ｈｔｔｐ：／／ｗｗｗ．ｓｉｇｍｏｂｉｌｅ．ｏｒｇ／ｍｏｂｉｃｏｍ／２０１３／ａｐｐ＿ｗｉｎｎｅｒｓ．ｈｔｍｌ（２０１４年１月３０日に参照）。
［１７］ＸＤＡ Ｄｅｖｅｌｏｐｅｒｓ，「Ｇｅｔ Ｙｏｕｒ Ｖｉｄｅｏｓ Ｆａｓｔｅｒ ｗｉｔｈ ＶｉｄｅｏＢｅｅ ｆｏｒ Ａｎｄｒｏｉｄ，」ｈｔｔｐ：／／ｗｗｗ．ｘｄａ－ｄｅｖｅｌｏｐｅｒｓ．ｃｏｍ／ａｎｄｒｏｉｄ／ｇｅｔ－ｙｏｕｒ－ｖｉｄｅｏｓ－ｆａｓｔｅｒ－ｗｉｔｈ－ｖｉｄｅｏｂｅｅ－ｆｏｒ－ａｎｄｒｏｉｄ／（２０１４年１月３０日に参照）。
［１８］Ｍｏｂｉｌｅ Ｔｉｍｅ，「ＶｉｄｅｏＢｅｅ：ａｐｐ ｃｒｉａ ｓｔｒｅａｍｉｎｇ 「ｃｏｏｐｅｒａｔｉｖｏ」ｅｎｔｒｅ ｃｅｌｕｌａｒｅｓ，」ｈｔｔｐ：／／ｗｗｗ．ｍｏｂｉｌｅｔｉｍｅ．ｃｏｍ．ｂｒ／１９／１２／２０１３／ｖｉｄｅｏｂｅｅ－ａｐｐ－ｃｒｉａ－ｓｔｒｅａｍｉｎｇ－ｃｏｏｐｅｒａｔｉｖｏ－ｅｎｔｒｅ－ｃｅｌｕｌａｒｅｓ／３６４８２０／ｎｅｗｓ．ａｓｐｘ（２０１４年１月３０日に参照）。
［１９］Ａｎｄｒｏｉｄ Ａｙｕｄａ，「Ｄｅｓｃａｒｇａ ｙ ｃｏｍｐａｒｔｅ ｖｉｄｅｏｓ ｒａｐｉｄａｍｅｎｔｅ ｇｒａｃｉａｓ ａ ＶｉｄｅｏＢｅｅ ｐａｒａ Ａｎｄｒｏｉｄ，」ｈｔｔｐ：／／ａｎｄｒｏｉｄａｙｕｄａ．ｃｏｍ／２０１３／１ １／０９／ｄｅｓｃａｒｇａ－ｙ－ｃｏｍｐａｒｔｅ－ｖｉｄｅｏｓ－ｒａｐｉｄａｍｅｎｔｅ－ｇｒａｃｉａｓ－ｖｉｄｅｏｂｅｅ－ｐａｒａ－ａｎｄｒｏｉｄ／（２０１４年１月３０日に参照）。
［２０］Ａｎｄｒｏｉｄ Ｐｉｐｅ，「Ｖｉｄｅｏ Ｓｔｒｅａｍｉｎｇ ａｔ Ｉｔｓ Ｂｅｓｔ ｗｉｔｈ ＶｉｄｅｏＢｅｅ ｆｏｒ Ａｎｄｒｏｉｄ，」ｈｔｔｐ：／／ｗｗｗ．ａｎｄｒｏｉｄｐｉｐｅ ｏｍ／ｖｉｄｅｏ－ｓｔｒｅａｍｉｎｇ－ａｔ－ｉｔｓ－ｂｅｓｔ－ｗｉｔｈ－ｖｉｄｅｏｂｅｅ－ｆｏｒ－ａ（２０１４年１月３０日に参照）。
［２１］Ｆｌｕｒｒｙ Ａｎａｌｙｔｉｃｓ ｈｔｔｐ：／／ｗｗｗ．ｆｌｕｒｒｙ．ｃｏｍ／ｆｌｕｒｒｙ－ａｎａｌｙｔｉｃｓ．ｈｔｍｌ（２０１４年１月３０日に参照）．
［２２］ＩＥＴＦ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ，「ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ，」ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ ｄｒａｆｔ－ｐａｎｔｏｓ－ｈｔｔｐ－ｌｉｖｅ－ｓｔｒｅａｍｉｎｇ－１２（２０１４年１月３０日に参照）。
［２３］Ａｐｐｌｅ ｉＯＳ，「Ｕｓｉｎｇ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ，」ｈｔｔｐｓ：／／ｄｅｖｅｌｏｐｅｒ．ａｐｐｌｅ．ｃｏｍ／ｌｉｂｒａｒｙ／ｍａｃ／ｄｏｃｕｍｅｎｔａｔｉｏｎ／ｎｅｔｗｏｒｋｉｎｇｉｎｔｅｒｎｅｔ／ｏｎｃｅｐｔｕａｌ／ｓｔｒｅａｍｉｎｇｍｅｄｉａｇｕｉｄｅ／ＵｓｉｎｇＨＴＴＰ ＬｉｖｅＳｔｒｅａｍｉｎｇ／ＵｓｉｎｇＨＴＴＰＬｉｖｅＳｔｒｅａｍｉｎｇ．ｈｔｍｌ（２０１４年１月３０日に参照）。
［２４］Ｇｏｏｇｌｅ Ａｎｄｒｏｉｄ，「Ｓｕｐｐｏｒｔｅｄ Ｍｅｄｉａ Ｆｏｒｍａｔ，」ｈｔｔｐ：／／ｄｅｖｅｌｏｐｅｒ．ａｎｄｒｏｉｄ．ｃｏｍ ／ｇｕｉｄｅ／ａｐｐｅｎｄｉｘ／ｍｅｄｉａ－ｆｏｒｍａｔｓ．ｈｔｍｌ（２０１４年１月３０日に参照）。
［２５］Ｍａｒｋｅｔｉｎｇ Ｃｈａｒｔｓ，「Ｔｏｐ １０ Ｍｏｂｉｌｅ－Ｐｈｏｎｅ Ｗｅｂｓｉｔｅｓ，ｂｙ ＵＳ Ｍａｒｋｅｔ Ｓｈａｒｅ ｏｆ Ｖｉｓｉｔｓ，Ａｕｇｕｓｔ ２０１３，」ｈｔｔｐ：／／ｗｗｗ．ｍａｒｋｅｔｉｎｇｃｈａｒｔｓ．ｃｏｍ／ｗｐ／ｉｎｔｅｒａｃｔｉｖｅ／ｔｏｐ－１０－ｍｏｂｉｌｅ－ｐｈｏｎｅ－ｗｅｂｓｉｔｅｓ－ａｕｇｕｓｔ－２０１３－３６５２３／（２０１４年１月３０日に参照）。
［２６］Ａｎｈ Ｌｅ ａｎｄ Ａｎｄｒｅｗ Ｓｗｅｒｄｌｏｗ，「Ｂｒｏｗｓｅｒ Ｅｘｔｅｎｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｌｏｗ Ｇｒａｐｈ Ｃｏｎｓｔｒｕｃｔｉｏｎ Ｆｏｒ Ｄｅｔｅｒｍｉｎｉｎｇ Ｓｅｎｓｉｔｉｖｅ Ｐａｔｈｓ，」米国特許第８，２８６，２５０号，２０１２年１０月９日に許可。
［２７］Ａｎｈ Ｌｅ ａｎｄ Ａｎｄｒｅｗ Ｓｗｅｒｄｌｏｗ，「Ｂｒｏｗｓｅｒ Ｅｘｔｅｎｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｌｏｗ Ｇｒａｐｈ Ｂａｓｅｄ Ｔａｉｎｔ Ｔｒａｃｋｉｎｇ，」米国特許第８，３６５，２９１号，２０１３年１月２９日に許可。
［２８］ＢＧＲ，「ＡＴ＆Ｔ’ｓ ４Ｇ ＬＴＥ ｎｅｔｗｏｒｋ ｆｏｕｎｄ ｔｏ ｂｅ ｔｈｅ ｆａｓｔｅｓｔ ｉｎ ｔｈｅ Ｕ．Ｓ，」ｈｔｔｐ：／／ｂｇｒ．ｃｏｍ／２０１３／０６／１７／４ｇ－ｌｔｅ－ｓｐｅｅｄｓ－ａｔｔ－ｖｅｒｉｚｏｎ－ｓｐｒｉｎｔ－ｔ－ｍｏｂｉｌｅ（２０１４年１月３０日に参照）。
［２９］Ａｒｓｔｅｃｈｎｉｃａ，「Ｍｕｌｔｉｐａｔｈ ＴＣＰ ｌｅｔｓ Ｓｉｒｉ ｓｅａｍｌｅｓｓｌｙ ｓｗｉｔｃｈ ｂｅｔｗｅｅｎ Ｗｉ－Ｆｉ ａｎｄ ３Ｇ／ＬＴＥ，」ｈｔｔｐ：／／ｇｏｏ．ｇｌ／ｉＷｃＴｄＴ（２０１４年１月３０日に参照）。
［３０］Ｇｏｏｇｌｅ，Ｖｐｎ－Ｓｅｒｖｉｃｅ ｄｏｃｕｍｅｎｔａｔｉｏｎ，ｈｔｔｐ：／／ｄｅｖｅｌｏｐｅｒ．ａｎｄｒｏｉｄ．ｃｏｍ／ｒｅｆｅｒｅｎｃｅ／ａｎｄｒｏｉｄ／ｎｅｔ／ＶｐｎＳｅｒｖｉｃｅ．ｈｔｍｌ（２０１４年１月３０日に参照）。
［３１］Ｇｏｏｇｌｅ Ａｎｄｒｏｉｄ，「Ａｎｄｒｏｉｄ ２．２ Ｐｌａｔｆｏｒｍ Ｈｉｇｈｌｉｇｈｔｓ，」Ｍａｙ ２０１０ ｈｔｔｐ：／／ｄｅｖｅｌｏｐｅｒ．ａｎｄｒｏｉｄ．ｃｏｍ／ａｂｏｕｔ／ｖｅｒｓｉｏｎｓ／ａｎｄｒｏｉｄ－２．２－ｈｉｇｈｌｉｇｈｔｓ．ｈｔｍｌ
［３２］Ｓａｍｓｕｎｇ，「Ｗｈａｔ ｉｓ Ｓ Ｂｅａｍ，ａｎｄ ｈｏｗ ｄｏ Ｉ ｕｓｅ ｉｔ？」，ｈｔｔｐ：／／ｗｗｗ．ｓａｍｓｕｎｇ．ｃｏｍ／ｕｓ／ｓｕｐｐｏｒｔ／ｓｕｐｐｏｒｔＯｗｎｅｒｓＨｏｗＴｏＧｕｉｄｅＰｏｐｕｐ．ｄｏ７ｈｏｗ ｔｏ＿ｇｕｉｄｅ＿ｓｅｑ＝７０４２＆ｐｒｄ＿ｉａ＿ｃｄ＝Ｎ００００００３＆ｍａｐ＿ｓｅｑ＝４８１５７
［３３］Ｊ．Ｋｉｍ，Ｒ．Ｋｈａｌｉｌｉ，Ａ．Ｆｅｌｄｍａｎｎ，Ｙ－Ｃ．Ｃｈｅｎ，Ｄ．Ｔｏｗｓｌｅｙ，「Ｍｕｌｔｉ－Ｓｏｕｒｃｅ Ｍｕｌｔｉ－Ｐａｔｈ ＨＴＴＰ（ｍＨＴＴＰ）：Ａ Ｐｒｏｐｏｓａｌ，」ａｒＸｉｖ．１３１０．２７４８ ｈｔｔｐ：／／ａｒｘｉｖ－ｗｅｂ３．ｌｉｂｒａｒｙ．ｃｏｒｎｅｌｌ．ｅｄｕ／ａｂｓ／１３１０．２７４８ｖ３（２０１４年１月３０日に参照）。
［３４］ＭｕｌｔｉＰａｔｈ ＴＣＰ ｈｔｔｐ：／／ｗｗｗ．ｍｕｌｔｉｐａｔｈ－ｔｃｐ．ｏｒｇ／（２０１４年１月３０日に参照）。
［３５］Ｃ．Ｔｓａｏ ａｎｄ Ｒ．Ｓｉｖａｋｕｍａｒ，「Ｏｎ ｅｆｆｅｃｔｉｖｅｌｙ ｅｘｐｌｏｉｔｉｎｇ ｍｕｌｔｉｐｌｅ ｗｉｒｅｌｅｓｓ ｉｎｔｅｒｆａｃｅｓ ｉｎ ｍｏｂｉｌｅ ｈｏｓｔｓ，」Ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ５ｔｈｌｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｅｍｅｒｇｉｎｇ Ｎｅｔｗｏｒｋｉｎｇ Ｅｘｐｅｒｉｍｅｎｔｓ ａｎｄ Ｔｅｃｈｎｏｌｏｇｉｅｓ（ＣｏＮＥＸＴ），ｐａｇｅｓ ３３７－３４８，２００９。
［３６］Ｈ．Ｓｏｒｏｕｓｈ，Ｐ．Ｇｉｌｂｅｒｔ，Ｎ．Ｂａｎｅｒｊｅｅ，Ｍ．Ｄ．Ｃｏｒｎｅｒ，Ｂ．Ｎ．Ｌｅｖｉｎｅ，ａｎｄ Ｌ．Ｃｏｘ，「Ｓｐｉｄｅｒ：Ｉｍｐｒｏｖｉｎｇ ｍｏｂｉｌｅ ｎｅｔｗｏｒｋｉｎｇ ｗｉｔｈ ｃｏｎｃｕｒｒｅｎｔ ｗｉ－ｆｉ ｃｏｎｎｅｃｔｉｏｎｓ，」ｉｎ ＳＩＧ－ＣＯＭＭ Ｃｏｍｐｕｔｅｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｖｉｅｗ，４１（４）：４０２－４０３，Ａｕｇ．２０１１。
［３７］Ｐ．Ｒｏｄｒｉｇｕｅｚ，Ｒ．Ｃｈａｋｒａｖｏｒｔｙ，Ｊ．Ｃｈｅｓｔｅｒｆｉｅｌｄ，Ｉ．Ｐｒａｔｔ，ａｎｄ Ｓ．Ｂａｎｅｒｊｅｅ，「ＭＡＲ：ａ ｃｏｍｍｕｔｅｒ ｒｏｕｔｅｒ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ｆｏｒ ｔｈｅ ｍｏｂｉｌｅ ｉｎｔｅｒｎｅｔ，」ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２ｎｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｍｏｂｉｌｅ Ｓｙｓｔｅｍｓ，Ａｐｐｌｉｃａｔｉｏｎｓ，ａｎｄ Ｓｅｒｖｉｃｅｓ（ＭｏｂｉＳｙｓ），ｐａｇｅｓ２１７－２３０，２００４。
［３８］Ｊ．Ｃｈｅｓｔｅｒｆｉｅｌｄ，Ｒ．Ｃｈａｋｒａｖｏｒｔｙ，Ｉ．Ｐｒａｔｔ，Ｓ．Ｂａｎｅｒｊｅｅ，ａｎｄ Ｐ．Ｒｏｄｒｉｇｕｅｚ，「Ｅｘｐｌｏｉｔｉｎｇ ｄｉｖｅｒｓｉｔｙ ｔｏ ｅｎｈａｎｃｅ ｍｕｌｔｉｍｅｄｉａ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ｃｅｌｌｕｌａｒ ｌｉｎｋｓ，」ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２００５ ＩＥＥＥ ＩＮＦＯＣＯＭ，ｐａｇｅｓ ２０２０－２０３１，Ｍａｒ．２００５。
［３９］Ｂ．Ｈａｎ，Ｐ．Ｈｕｉ，Ｖ．Ａ．Ｋｕｍａｒ，Ｍ．Ｖ．Ｍａｒａｔｈｅ，Ｇ．Ｐｅｉ，ａｎｄ Ａ．Ｓｒｉｎｉｖａｓａｎ，「Ｃｅｌｌｕｌａｒ ｔｒａｆｆｉｃ ｏｆｆｌｏａｄｉｎｇ ｔｈｒｏｕｇｈ ｏｐｐｏｒｔｕｎｉｓｔｉｃ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ：ａ ｃａｓｅ ｓｔｕｄｙ，」ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ５ｔｈ ＡＣＭ Ｗｏｒｋｓｈｏｐ ｏｎ Ｃｈａｌｌｅｎｇｅｄ Ｎｅｔｗｏｒｋｓ（ＣＨＡＮＴＳ），ｐａｇｅｓ ３１－３８，２０１０。
［４０］Ｓ．ｌｏａｎｎｉｄｉｓ，Ａ．Ｃｈａｉｎｔｒｅａｕ，ａｎｄ Ｌ．Ｍａｓｓｏｕｌｉｅ．「Ｏｐｔｉｍａｌ ａｎｄ ｓｃａｌａｂｌｅ ｄｉｓｔｒｉｂｕｔｉｏｎ ｏｆ ｃｏｎｔｅｎｔ ｕｐｄａｔｅｓ ｏｖｅｒ ａ ｍｏｂｉｌｅ ｓｏｃｉａｌ ｎｅｔｗｏｒｋ，」ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２００９ ＩＥＥＥ ＩＮＦＯＣＯＭ，ｐａｇｅｓ １４２２－１４３０，Ａｐｒ．２００９。
［４１］Ｊ．Ｗｈｉｔｂｅｃｋ，Ｍ．Ａｍｏｒｉｍ，Ｙ．Ｌｏｐｅｚ，Ｊ．Ｌｅｇｕａｙ，ａｎｄ Ｖ．Ｃｏｎａｎ．「Ｒｅｌｉｅｖｉｎｇ ｔｈｅ ｗｉｒｅｌｅｓｓ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ：Ｗｈｅｎ ｏｐｐｏｒｔｕｎｉｓｔｉｃ ｎｅｔｗｏｒｋｓ ｍｅｅｔ ｇｕａｒａｎｔｅｅｄ ｄｅｌａｙｓ，」ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２０１１ ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｙｍｐｏｓｉｕｍ ｏｎ ａ Ｗｏｒｌｄ ｏｆ Ｗｉｒｅｌｅｓｓ，Ｍｏｂｉｌｅａｎｄ Ｍｕｌｔｉｍｅｄｉａ Ｎｅｔｗｏｒｋｓ（ＷｏＷＭｏＭ），ｐａｇｅｓ １－１０，Ｊｕｎｅ ２０１１。
［４２］Ｃ．Ｂｏｌｄｒｉｎｉ，Ｍ．Ｃｏｎｔｉ，ａｎｄ Ａ．Ｐａｓｓａｒｅｌｌａ，「Ｅｘｐｌｏｉｔｉｎｇ ｕｓｅｒｓ’ ｓｏｃｉａｌ ｒｅｌａｔｉｏｎｓ ｔｏ ｆｏｒｗａｒｄ ｄａｔａ ｉｎ ｏｐｐｏｒｔｕｎｉｓｔｉｃ ｎｅｔｗｏｒｋｓ：Ｔｈｅ ＨｉＢＯｐ ｓｏｌｕｔｉｏｎ，」ｉｎ Ｐｅｒｖａｓｉｖｅ ａｎｄ Ｍｏｂｉｌｅ Ｃｏｍｐｕｔｉｎｇ，４（５）：６３３－６５７，Ｏｃｔ．２００８。
［４３］Ｐ．Ｈｕｉ，Ｊ．Ｃｒｏｗｃｒｏｆｔ，ａｎｄ Ｅ．Ｙｏｎｅｋｉ．「Ｂｕｂｂｌｅ ｒａｐ：ｓｏｃｉａｌ－ｂａｓｅｄ ｆｏｒｗａｒｄｉｎｇ ｉｎ ｄｅｌａｙ ｔｏｌｅｒａｎｔ ｎｅｔｗｏｒｋｓ，」ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ９ｔｈ ＡＣＭ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｍｏｂｉｌｅ Ａｄ Ｈｏｃ Ｎｅｔｗｏｒｋｉｎｇ ａｎｄ Ｃｏｍｐｕｔｉｎｇ（Ｍｏｂｉ－Ｈｏｃ），ｐａｇｅｓ ２４１－２５０，２００８。
［４４］Ｇ．Ａｎａｎｔｈａｎａｒａｙａｎａｎ，Ｖ．Ｎ．Ｐａｄｍａｎａｂｈａｎ，Ｌ．Ｒａｖｉｎｄｒａｎａｔｈ，ａｎｄ Ｃ．Ａ．Ｔｈｅｋｋａｔｈ，「ＣＯＭＢＩＮＥ：ｌｅｖｅｒａｇｉｎｇ ｔｈｅ ｐｏｗｅｒ ｏｆ ｗｉｒｅｌｅｓｓ ｐｅｅｒｓ ｔｈｒｏｕｇｈ ｃｏｌｌａｂｏｒａｔｉｖｅ ｄｏｗｎｌｏａｄｉｎｇ，」ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ５ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｍｏｂｉｌｅ Ｓｙｓｔｅｍｓ，Ａｐｐｌｉｃａｔｉｏｎｓ ａｎｄ Ｓｅｒｖｉｃｅｓ（ＭｏｂｉＳｙｓ），ｐａｇｅｓ ２８６－２９８，２００７。
［４５］Ｍ．Ｓｔｉｅｍｅｒｌｉｎｇ ａｎｄ Ｓ．Ｋｉｅｓｅｌ，「Ａ ｓｙｓｔｅｍ ｆｏｒ ｐｅｅｒ－ｔｏ－ｐｅｅｒ ｖｉｄｅｏ ｓｔｒｅａｍｉｎｇ ｉｎ ｒｅｓｏｕｒｃｅ ｃｏｎｓｔｒａｉｎｅｄ ｍｏｂｉｌｅ ｅｎｖｉｒｏｎｍｅｎｔｓ，」ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ １ ｓｔ ＡＣＭ Ｗｏｒｋｓｈｏｐ ｏｎ Ｕｓｅｒ－ｐｒｏｖｉｄｅｄ Ｎｅｔｗｏｒｋｉｎｇ：Ｃｈａｌｌｅｎｇｅｓ ａｎｄ Ｏｐｐｏｒｔｕｎｉｔｉｅｓ（Ｕ－ＮＥＴ），ｐａｇｅｓ ２５－３０，２００９。
［４６］Ｖｅｒｉｚｏｎ Ｓｈａｒｅ－Ｅｖｅｒｙｔｈｉｎｇ Ｐｌａｎ，ｈｔｔｐ：／／ｗｗｗ．ｖｅｒｉｚｏｎｗｉｒｅｌｅｓｓ．ｃｏｍ／ｗｃｍｓ／ｃｏｎｓｕｍｅｒ／ｓｈｏｐ／ｓｈａｒｅ－ｅｖｅｒｙｔｈｉｎｇ．ｈｔｍｌ（２０１４年１月３０日に参照）。
［４７］ＡＴ＆Ｔ Ｍｏｂｉｌｅ Ｓｈａｒｅ Ｖａｌｕｅ Ｐｌａｎｓ，ｈｔｔｐ：／／ｗｗｗ．ａｔｔ．ｃｏｍ／ｓｈｏｐ／ｗｉｒｅｌｅｓｓ／ｄａｔａ－ｐｌａｎｓ．ｈｔｍｌ＃ｆｂｉｄ＝１０ｎｄＥｓｐｖ７ＢＷ（２０１４年１月３０日に参照）。
［４８］Ｔ－Ｍｏｂｉｌｅ，「Ｓｍａｒｔｐｈｏｎｅ Ｍｏｂｉｌｅ Ｈｏｔｓｐｏｔ，」ｈｔｔｐ：／／ｏｆｆｅｒｓ．ｔ－ｍｏｂｉｌｅ．ｃｏｍ／ｔｅｔｈｅｒｉｎｇ／ａｄｍｉｎ／ｆａｑ．ｊｓｐ（２０１４年１月３０日に参照）。
［４９］Ｌ．Ｋｅｌｌｅｒ，Ａ．Ｌｅ，Ｂ．Ｃｉｃｉ，Ｈ．Ｓｅｆｅｒｏｇｌｕ，Ｃ．Ｆｒａｇｏｕｌｉ，Ａ．Ｍａｒｋｏｐｏｕｌｏｕ，「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｃｏｏｐｅｒａｔｉｖｅ Ｄａｔａ Ｓｔｒｅａｍｉｎｇ，」２０１３年３月にＵＣ ＩｒｖｉｎｅおよびＥＰＦＬによって共同で出願された米国特許出願（米国特許出願第１３／８４１，５００号）。
［５０］Ａ．Ｌｅ，Ｌ．Ｋｅｌｌｅｒ，Ｃ．Ｆｒａｇｏｕｌｉ，Ａ．Ｍａｒｋｏｐｏｕｌｏｕ，「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｌｏｃａｌ Ｍｕｌｔｉｐｌａｙｅｒ Ｇａｍｉｎｇ，」２０１３年３月にＵＣ ＩｒｖｉｎｅおよびＥＰＦＬによって共同で出願された米国特許出願（米国特許出願第１３／８４１，９５６号）。

Claims (6)

1. マルチチャネルネットワークトラフィックをルーティングするためのシステムであって、前記システムは、
   １Ａ．リモートサーバを要求することなく複数のデータチャネルを通じて通信することが可能であり、かつ仮想プライベートネットワーク（ＶＰＮ）サービスアプリケーションを動作させるように構成された少なくとも１つのネットワークデバイスであって、前記ＶＰＮサービスアプリケーションは、ネットワークデバイスのオペレーティングシステムとして、またはオペレーティングシステムサービスとして実装することができ、前記ＶＰＮサービスアプリケーションはルーティングモジュールを備え、前記ルーティングモジュールは、ユーザデータグラムプロトコル（ＵＤＰ）トランスレータおよび伝送制御プロトコル（ＴＣＰ）トランスレータから構成することができ、前記ＶＰＮサービスアプリケーションは、
   ａ．仮想ネットワークインタフェースを確立し、発信データパケットのセットを前記仮想ネットワークインタフェースにルーティングすることであって、前記発信データパケットは、オープンシステムインターコネクション（ＯＳＩ）レイヤ３インターネットプロトコル（ＩＰ）データグラムまたはＯＳＩレイヤ２イーサネットフレームであることと、
   ｂ．前記仮想ネットワークインタフェースからの発信データパケットのセットを読み出し、前記発信データパケットのセットからデータを抽出することと、
   ｃ．修正された発信データパケットのセットを形成するために、前記発信データパケットのセットからの発信データパケットの各サブセットを、前記ＵＤＰトランスレータおよび前記ＴＣＰトランスレータのうちの少なくとも１つに割り当てることと、
   ｄ．レイヤ３インターネットプロトコルを伴うレイヤ４ユーザデータグラムプロトコル（ＵＤＰ／ＩＰ）、レイヤ３インターネットプロトコルを伴うレイヤ４伝送制御プロトコル（ＴＣＰ／ＩＰ）のデータトラフィックネットワークソケット、および／または実物理ネットワークインタフェースにバインドするように構成されたソケットを使用して、複数のネットワークソケットのうちの少なくとも１つを介して、前記修正された発信データパケットの１つ以上のサブセットを、複数のターゲットコンピュータホストのうちの少なくとも１つに送信することであって、前記複数のネットワークソケットは、保護されたソケットおよび標準的なソケットのうちの少なくとも１つであり、前記ソケットは、前記仮想ネットワークインタフェースにループバックしないように構成することができることと、
   ｅ．前記複数のデータチャネルのうちの少なくとも１つを使用して、前記複数のネットワークソケットのうちの少なくとも１つを介して、前記ターゲットコンピュータホストから修正された着信データパケットの１つ以上のサブセットを受信することと、
   ｆ．着信データパケットの１つ以上のサブセットを形成するために、前記修正された着信データパケットの１つ以上のサブセットからデータを抽出することと、
   ｇ．前記着信データパケットのサブセットを再順序付け、組み立て、かつ書き込み、前記着信データパケットのサブセットを、少なくとも１つのネットワークデバイスアプリケーションまたはオペレーティングシステムにルーティングすることと、
   を含む動作を行う、システム、および／または
   １Ｂ．少なくとも１つのネットワークデバイスおよび少なくとも１つのリモートサーバであって、
   ａ．前記少なくとも１つのネットワークデバイスは、仮想プライベートネットワーク（ＶＰＮ）サービスアプリケーションを動作させるように構成され、前記ＶＰＮサービスアプリケーションは、前記ネットワークデバイスのオペレーティングシステムまたはオペレーティングシステムサービスとして実装することができ、前記ネットワークデバイスは、複数のデータチャネルを通じてリモートサーバと通信することが可能であり、前記ＶＰＮサービスアプリケーションは、
   ｉ．仮想ネットワークインタフェースを確立し、発信データパケットのセットを前記仮想ネットワークインタフェースにルーティングすることであって、前記発信データパケットは、ＯＳＩレイヤ３ＩＰデータグラムまたはＯＳＩレイヤ２イーサネットフレームであり得ることと、
   ｉｉ．修正された発信データパケットのセットを形成するために、前記発信データパケットのセットを読み出すことと、
   ｉｉｉ．修正された発信データパケットのサブセットを形成するために、前記修正された発信データパケットのセットからの各データパケットを、前記複数のデータチャネルのうちの少なくとも１つに割り当てることと、
   ｉｖ．１つ以上のネットワークソケットを使用して、前記修正された発信データパケットのサブセットを前記リモートサーバに送信することであって、前記１つ以上のネットワークソケットは、レイヤ４ユーザデータグラムプロトコル（ＵＤＰ）ソケット、レイヤ４ＴＣＰソケット、実物理ネットワークインタフェースにバインドするように構成されたソケット、前記仮想ネットワークインタフェースにループバックしないように構成されたソケット、およびレイヤ３ローソケットから構成される群から選択することができることと、
   ｖ．１つ以上のネットワークソケットを使用して、少なくとも１つのリモートサーバから修正された着信データパケットの１つ以上のサブセットを受信することであって、前記１つ以上のネットワークソケットは、レイヤ４ＵＤＰソケット、レイヤ４ＴＣＰソケット、実物理ネットワークインタフェースにバインドするように構成されたソケット、前記仮想ネットワークインタフェースにループバックしないように構成されたソケット、およびレイヤ３ローソケットから構成される群から選択することができることと、
   ｖｉ．前記修正された着信データパケットのサブセットを着信データパケットのセットに前記仮想ネットワークインタフェースへ再順序付けし、組み立て、かつ書き込み、前記修正された着信データパケットのサブセットを、少なくとも１つのネットワークデバイスアプリケーションまたはオペレーティングシステムにルーティングすることと、
   を含む動作を行い、
   ｂ．前記少なくとも１つのリモートサーバは、前記複数のデータチャネルおよび複数のターゲットコンピュータホストのうちの少なくとも１つを通じて前記少なくとも１つのネットワークデバイスと通信することが可能なＶＰＮサービスまたはプロキシサービスを備え、前記少なくとも１つのリモートサーバは、
   ｉ．前記複数のデータチャネルを介して前記少なくとも１つのネットワークデバイスから修正された発信データパケットのサブセットを受信することであって、前記修正された発信データパケットのサブセットは、発信リモートサーバデータパケットのセットに再順序付けて組み立てることができ、前記発信リモートサーバデータパケットは、ＯＳＩレイヤ３ＩＰデータグラムまたはＯＳＩレイヤ２イーサネットフレームであり得ることと、
   ｉｉ．前記発信リモートサーバデータパケットのセットを１つ以上のターゲットコンピュータホストに転送することと、
   ｉｉｉ．修正された着信コンピュータホストデータパケットのセットを形成するために、前記１つ以上のターゲットコンピュータホストから着信コンピュータホストデータパケットのセットを受信することと、
   ｉｖ．前記修正された着信コンピュータホストデータパケットのセットからの各データパケットを、前記複数のデータチャネルのうちの少なくとも１つに割り当てることと、
   ｖ．前記修正された着信コンピュータホストデータパケットのサブセットが割り当てられる、前記複数のデータチャネルのうちの少なくとも１つを介して、前記修正された着信コンピュータホストデータパケットのサブセットを前記少なくとも１つのネットワークデバイスに送信することと、
   を含む動作を行うように構成される、リモートサーバと、
   を備える、システムと、
   から構成される群から選択される、システム。
2. ａ．前記仮想ネットワークインタフェースは、ネットワークＴＵＮｎｅｌ（ＴＵＮ）インタフェースまたはネットワークＴＡＰインタフェースのどちらかであり、かつ／または
   ｂ．前記ＶＰＮサービスおよび前記ＶＰＮサービスアプリケーションは、ネットワークデバイスのオペレーティングシステムまたはオペレーティングシステムサービスとして動作され、前記仮想ネットワークインタフェースは、ＴＵＮインタフェースまたはＴＡＰインタフェースであり得、かつ／または
   ｃ．前記ＶＰＮサービスおよび前記ＶＰＮサービスアプリケーションは、オペレーティングシステムサービスとして動作され、前記仮想ネットワークインタフェースは、ＴＵＮインタフェースまたはＴＡＰインタフェースであり得る、
   請求項１に記載のシステム。
3. 前記ＶＰＮサービスアプリケーションは、ソフトウェア開発キット（ＳＤＫ）である、請求項１に記載のシステム。
4. 前記ＶＰＮサービスアプリケーションは、
   ａ．１つ以上のデータチャネルを通じて受信されたデータを再組み立てまたは再順序付けすること、
   ｂ．前記１つ以上のデータチャネルを通じて受信されたデータからデータパケットを構築すること、
   ｃ．前記仮想ネットワークインタフェースに前記データパケットを書き込むこと、
   ｄ．前記データパケットを、前記少なくとも１つのネットワークデバイスアプリケーションまたはオペレーティングシステムにルーティングすること、
   ｅ．前記発信データパケットを暗号化すること、
   ｆ．前記発信データパケットを符号化すること、
   ｇ．前記着信データパケットを解読すること、および
   ｈ．前記着信データパケットを復号すること
   という動作のうちの少なくとも１つをさらに行う、請求項１に記載のシステム。
5. 前記少なくとも１つのネットワークデバイスはリモートサーバと通信することができ、前記少なくとも１つのネットワークデバイスは、
   （ａ）、コストを最小化し、伝送の速度を最適化し、各チャネルのキューサイズ、データ転送レート、および遅延のうちの１つ以上に基づいて選択されたパケットタイプを優先付け、かつ／またはパケットを優先付けてどのパケットをどのチャネルに割り当てるかを決定するように構成することができるオプション、
   （ｂ）少なくとも、前記パケットを生成するアプリケーション、各チャネルのスループット、遅延、およびチャネルタイプを含む複数のチャネルの各々のチャネル状態、ならびに、デバイスツーデバイス接続、Ｗｉ－Ｆｉ、マイクロセル、ピコセル、および標準的なセルラ基地局のうちの１つを備え得るチャネルタイプに基づくアルゴリズムによって定義することができるオプション、
   （ｃ）暗号化スキームまたは符号化スキームを利用することができるオプション、および／または
   （ｄ）ユーザが構成可能かつサービスキャリアが構成可能であり得るオプション
   という構成可能なオプションのセットを包含する増大ポリシを利用することができる、請求項１に記載のシステム。
6. 前記ネットワークデバイスのうちの１つ以上の上にある増大ポリシは、
   ａ．前記ＶＰＮサービスアプリケーションの動作を構成すること、
   ｂ．送信元に基づくルーティングもしくはポリシに基づくルーティングを実装すること、および／または
   ｃ．１つ以上のネットワークチャネルを使用して、全てのまたは選択されたアプリケーショントラフィックのデータパケットを、少なくとも１つのターゲットコンピュータホストにまたはそこから、あるいは少なくとも１つのリモートサーバにまたはそこから伝送するための特定のチャネルを分析して発見するスイッチとして機能すること
   という動作のうちの少なくとも１つを行う、請求項５に記載のシステム。

Images