(57)【要約】  複数の無線ネットワークまたはデバイスを効率的に組み合わせるシステムおよび方法は、より高速で、より信頼でき、かつより安全なモバイルインターネットをもたらす。仮想プライベートネットワーク（ＶＰＮ）サービスアプリケーションは、モバイルデバイスの発信および着信データパケットをルーティングするように動作する。モバイルデバイスは、（ｉ）リモートサーバとモバイルデバイスとの間でのデータパケットの転送のためにＶＰＮサービスアプリケーションを通じてリモートサーバに結合されるか、または（ｉｉ）モバイルデバイスとインターネット上の直接のターゲットホストとの間でのデータパケットの転送のために相互レイヤ変換を実行するかのいずれかである。複数のチャネルを同時に使用することは、複数のチャネルを通じて暗号化データパケットを送信し、単一の装置により暗号化データパケットを受信することによってデータパケット転送を保護する。データパケットは、Ｗｉ−Ｆｉチャネルまたはセルラチャネル介して転送されるよう指定され、次いで、Ｗｉ−Ｆｉチャネルおよびセルラチャネルの両方を使用して転送される。【選択図】図１Ａ
2018517341.tif 000002
【特許請求の範囲】
【請求項１】
モバイルインターネットトラフィックの速度を増加させるシステム（１００）であって、
ａ．複数のデータチャネルを通じてリモートサーバ（２００）と通信することが可能な少なくとも１つのモバイルデバイス（１０２）であって、前記チャネルは、異なるタイプのチャネル（１１５、１１６）であり、前記モバイルデバイス（１０２）は、仮想プライベートネットワーク（ＶＰＮ）サービスアプリケーション（１０３）を動作させるように構成され、前記サービスアプリケーションは、
ｉ．仮想ネットワークインタフェース（１０８）を確立することであって、前記モバイルデバイス（１０２）のオペレーティングシステムは、発信パケット（１０７）のセットをこのインタフェース（１０８）にルーティングするように構成され、前記ＶＰＮサービスアプリケーション（１０３）は次いで、ネットワークソケット（１０５）を使用して前記発信データパケット（１１４）を前記リモートサーバ（２００）に送信する、確立することと、
ｉｉ．発信パケット（１０７）の前記セットを前記仮想ネットワークインタフェース（１０８）から読み出すことと、
ｉｉｉ．各発信パケット（１０７）を前記複数のチャネルのうちの１つに割り当てることと、
ｉｖ．前記割り当てられたチャネルを介して発信パケット（１１４）の前記セットを前記リモートサーバ（２００）に送信することであって、前記割り当てられたチャネルは同時に、Ｗｉ−Ｆｉチャネルおよびセルラチャネル（１１５、１１６）である、送信することと、
ｖ．着信データパケット（１１３）の前記セットを前記リモートサーバ（２００）から受信することであって、前記着信パケット（１１３）は、前記複数のチャネルを通じて同時に受信され、前記チャネルは、前記Ｗｉ−Ｆｉチャネルおよび前記セルラチャネルである、受信することと、
ｖｉ．前記着信パケット（１０６）を前記仮想ネットワークインタフェース（１０８）に書き込むことと、
を含む動作を実行する、少なくとも１つのモバイルデバイス（１０２）と、
ｂ．前記複数のチャネルを通じて前記モバイルデバイス（１０２）と通信することが可能な前記リモートサーバ（２００）であって、前記チャネルは、異なるタイプのチャネル（１１５、１１６）であり、前記リモートサーバ（２００）は、インターネット上で複数のターゲットホスト（３００）と通信することが可能であり、前記リモートサーバ（２００）は、
ｉ．前記複数のチャネルを介して発信パケット（１１４）の前記セットを前記モバイルデバイス（１０２）から同時に受信することであって、前記チャネルは、前記Ｗｉ−Ｆｉチャネルおよび前記モバイルデバイスの前記セルラチャネル（１１５、１１６）である、受信することと、
ｉｉ．発信パケット（２０６）の前記セットを前記ターゲットホスト（３００）に転送することと、
ｉｉｉ．着信パケット（２０７）の前記セットを前記ターゲットホスト（３００）から受信することと、
ｉｖ．各着信パケット（２０７）を前記複数のチャネルのうちの１つに割り当てることであって、前記チャネルは、前記Ｗｉ−Ｆｉチャネルおよび前記モバイルデバイスの前記セルラチャネル（１１５、１１６）である、割り当てることと、
ｖ．前記割り当てられたチャネル（１１５、１１６）を介して着信パケット（１１３）前記セットを前記モバイルデバイス（１０２）に送信することと、
を含む動作を実行するように構成される、前記リモートサーバ（２００）と、
を備える、システム。
【請求項２】
モバイルインターネットトラフィックの速度を増加させるシステム（１００）であって、
ａ．複数のデータチャネルを通じてリモートサーバ（２００）と通信することが可能な少なくとも１つのモバイルデバイス（１０２）であって、前記チャネルは、異なるタイプのチャネル（１１５、１１６、１１７）であり、前記モバイルデバイス（１０２）は、仮想プライベートネットワーク（ＶＰＮ）サービスアプリケーション（１０３）を動作させるように構成され、前記サービスアプリケーションは、
ｉ．仮想ネットワークインタフェース（１０８）を確立することであって、前記モバイルデバイス（１０２）のオペレーティングシステムは、発信パケット（１０７）の前記セットをこのインタフェース（１０８）にルーティングするように構成され、前記ＶＰＮサービスアプリケーション（１０３）は次いで、ネットワークソケット（１０５）を使用して前記発信データパケットｌ（１１４）を前記リモートサーバ（２００）に送信する、確立することと、
ｉｉ．発信パケットの（１０７）前記セットを前記仮想ネットワークインタフェース（１０８）から読み出すことと、
ｉｉｉ．各発信パケット（１０７）を前記複数のチャネルのうちの１つに割り当てることと、
ｉｖ．前記割り当てられたチャネル（１１５、１１６、１１７）を介して発信パケット（１１４）の前記セットを前記リモートサーバ（２００）に送信することと、
ｖ．着信データパケット（１１３）の前記セットを前記リモートサーバ（２００）から受信することであって、前記着信パケット（１１３）は、前記複数のチャネルを通じて受信される、受信することと、
ｖｉ．前記着信パケット（１０６）を前記仮想ネットワークインタフェース（１０８）に書き込むことと、
を含む動作を実行する、少なくとも１つのモバイルデバイス（１０２）と、
ｂ．前記複数のチャネルを通じて前記モバイルデバイス（１０２）と通信することが可能な前記リモートサーバ（２００）であって、前記チャネルは、異なるタイプのチャネル（１１５、１１６、１１７）であり、前記リモートサーバ（２００）は、インターネット上で複数のターゲットホスト（３００）と通信することが可能であり、前記リモートサーバ（２００）は、
ｉ．前記複数のチャネル（１１５、１１６、１１７）を介して発信パケット（１１４）の前記セットを前記モバイルデバイス（１０２）から受信することと、
ｉｉ．発信パケット（２０６）の前記セットを前記ターゲットホスト（３００）に転送することと、
ｉｉｉ．着信パケット（２０７）の前記セットを前記ターゲットホスト（３００）から受信することと、
ｉｖ．各着信パケット（２０７）を前記複数のチャネルのうちの１つに割り当てることと、
ｖ．前記割り当てられたチャネル（１１５、１１６、１１７）を介して着信パケット（１１３）の前記セットを前記モバイルデバイス（１０２）に送信することと、
を含む動作を実行するように構成される、前記リモートサーバ（２００）と、
を備える、システム。
【請求項３】
前記リモートサーバ（２００）は、ＶＰＮサーバ（２０１）である、請求項２に記載のシステム。
【請求項４】
前記サービスアプリケーション（１０９）は、増大ポリシ（１１６）を含み、前記増大ポリシ（１１９）は、前記発信パケット（１１４）を優先付け、どのパケットをどのチャネル（１１５、１１６、１１７）に割り当てるかを決定する、請求項２に記載のシステム。
【請求項５】
前記増大ポリシ（１１９）は、前記パケットを生成するアプリケーション、前記複数のチャネル（１１５、１１６、１１７）の各々のチャネル状態に少なくとも基づいてアルゴリズムによって定義され、前記チャネル状態は、各チャネルのスループットおよび遅延、ならびに前記複数のチャネルの各々のチャネルタイプを含み、前記チャネルタイプは、デバイスツーデバイス接続（１１７）、Ｗｉ−Ｆｉ（１１５）、マイクロセル、ピコセル、および標準的なセルラ基地局（１１６）を含む、請求項４に記載のシステム。
【請求項６】
前記増大ポリシ（１１９）は、構成可能なオプションのセットを含み、前記オプションは、コストを最小化し、伝送の速度を最適化し、または選択されたパケットタイプを優先付けるように前記増大ポリシ（１１９）を構成する、請求項４に記載のシステム。
【請求項７】
発信パケット（１１４）の前記セットは、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および各チャネルの遅延のうちの少なくとも１つに基づいて、前記複数のチャネルを通じて送信される、請求項４に記載のシステム。
【請求項８】
前記リモートサーバ（２００）は、増大ポリシ（２０８）を動作させるように構成され、前記増大ポリシ（２０８）は、前記発信パケットの前記セットを優先付け、どのパケットをどのチャネルに割り当てるかを決定する、請求項２に記載のシステム。
【請求項９】
前記増大ポリシ（２０８）は、前記パケットを生成するアプリケーション、前記複数のチャネルの各々のチャネル状態に少なくとも基づいてアルゴリズムによって定義され、前記チャネル状態は、各チャネルのスループットおよび遅延、ならびに前記複数のチャネルの各々のチャネルタイプを含み、前記チャネルタイプは、デバイスツーデバイス接続（１１７）、Ｗｉ−Ｆｉ（１１５）、マイクロセル、ピコセル、および標準的なセルラ基地局（１１６）を含む、請求項８に記載のシステム。
【請求項１０】
着信パケットの前記セットは、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および各チャネルの遅延のうちの少なくとも１つに基づいて、前記複数のチャネルを通じて送信される、請求項８に記載のシステム。
【請求項１１】
前記ＶＰＮサービスアプリケーション（１０３）は、前記モバイルデバイス（１０２）のバックグランドで動作する、請求項２に記載のシステム。
【請求項１２】
前記データパケット（１２０）は、オープンシステムインターコネクション（ＯＳＩ）レイヤ３インターネットプロトコル（ＩＰ）データグラムまたはＯＳＩレイヤ２イーサネットフレームのいずれかである、請求項２に記載のシステム。
【請求項１３】
前記仮想ネットワークインタフェースは、ＴＵＮまたはＴＡＰインタフェース（１０８）のいずれかである、請求項２に記載のシステム。
【請求項１４】
前記ネットワークソケット（１０５）は、レイヤ４ユーザデータグラムプロトコル（ＵＤＰ）ソケット、レイヤ４伝送制御プロトコル（ＴＣＰ）ソケット、およびレイヤ３ローソケットのうちの少なくとも１つを含む、請求項２に記載のシステム。
【請求項１５】
データパケットを送信する前記ネットワークソケット（１０５）は、実物理ネットワークインタフェースにバインドするように構成される、請求項２に記載のシステム。
【請求項１６】
前記実物理ネットワークインタフェースは、Ｗｉ−Ｆｉ（１１５）またはセルラ（１１６）物理インタフェースである、請求項１５に記載のシステム。
【請求項１７】
前記複数のチャネルは、少なくともＷｉ−Ｆｉチャネル（１１５）およびセルラチャネル（１１６）を含む、請求項２に記載のシステム。
【請求項１８】
前記複数のチャネルは、少なくとも２つのセルラチャネル（１１６）を含む、請求項２に記載のシステム。
【請求項１９】
前記複数のチャネルは、少なくとも２つのＷｉ−Ｆｉチャネル（１１５）を含む、請求項２に記載のシステム。
【請求項２０】
前記複数のチャネルのうちの１つは、ローカルデバイスツーデバイスチャネル（１１７）である、請求項２に記載のシステム。
【請求項２１】
前記ローカルデバイスツーデバイスチャネル（１１７）は、Ｂｌｕｅｔｏｏｔｈチャネル、Ｗｉ−Ｆｉ直接チャネル、ロングタームエボリューション（ＬＴＥ）直接チャネル、またはＺｉｇＢｅｅチャネルである、請求項２０に記載のシステム。
【請求項２２】
前記サーバは、前記複数のチャネルを介して受信された前記発信パケット（１１４）を、それらを前記インターネット上でターゲットホスト（３００）に転送する前に再順序付けする、請求項２に記載のシステム。
【請求項２３】
前記サーバは、有効とされたＩＰ転送で構成され、前記サーバは、ネットワークアドレス変換（２１４）との仮想ネットワークインタフェース（２０４）を確立し、前記インターネット上で着信パケット（２０７）を前記ターゲットホスト（３００）から受信すると、前記サーバ（２００）は、前記複数のチャネル（１１５、１１６、１１７）を同時に使用してそれらを前記モバイルデバイス（１０２）に転送する、請求項２に記載のシステム。
【請求項２４】
前記モバイルデバイス（１０２）は、着信パケット（１１３）の前記セットを再順序付け、それらをモバイルデバイスアプリケーション（１０９）にルーティングする、請求項２に記載のシステム。
【請求項２５】
前記モバイルデバイス（１０２）からの前記発信データパケット（１１４）および前記リモートサーバ（２００）からの前記着信データパケット（１１３）は、暗号化スキームを使用して暗号化され（１１０）、前記着信データパケットは、前記モバイルデバイス（１０２）によって解読され（１１０）、前記発信パケットは、前記リモートサーバ（２００）によって解読される（２０９）、請求項２に記載のシステム。
【請求項２６】
前記パケットの暗号化（１１０）は、セキュリティポリシ（２１２）によって制御され、前記セキュリティポリシ（２１２）は、前記パケットを生成する前記アプリケーション、前記複数のチャネルの各々のチャネルスループット、チャネル遅延、およびチャネルタイプを入力として受ける、請求項２５に記載のシステム。
【請求項２７】
前記モバイルデバイス（１０２）からの前記発信データパケット（１１４）および前記リモートサーバ（２００）からの前記着信データパケット（１１３）は、前記複数のチャネル（１１５、１１６、１１７）を通じて送信される前に符号化スキームを使用して符号化され（１１１）、前記着信データパケット（１１３）は、前記モバイルデバイス（１０２）によって復号され（１１１）、前記発信パケット（１１４）は、前記リモートサーバ（２００）によって復号される（２１０）、請求項２に記載のシステム。
【請求項２８】
前記パケットの暗号化（２０９）は、セキュリティポリシ（２１２）によって制御され、前記セキュリティポリシ（２１２）は、前記パケットを生成する前記アプリケーション、前記複数のチャネルの各々のチャネルスループット、チャネル遅延、およびチャネルタイプのうちの少なくとも１つを入力として受ける、請求項２７に記載のシステム。
【請求項２９】
前記リモートサーバ（２００）は、前記複数のチャネルの全ての上で同一のインターネットプロトコル（ＩＰ）アドレスを有するように構成される、請求項２に記載のシステム。
【請求項３０】
前記リモートサーバ（２００）は、前記複数のチャネルのうちの少なくとも１つの上で異なるインターネットプロトコル（ＩＰ）アドレスを有するように構成され、各チャネル上の前記発信パケット（２０６）は、それぞれの各チャネル上で前記サーバの前記ＩＰアドレスにアドレス指定される、請求項２に記載のシステム。
【請求項３１】
前記モバイルデバイス（１０２）は、前記複数のチャネルのうちの少なくとも１つの上でプロキシサーバ（２１１）を介して前記リモートサーバ（２００）と通信し、前記プロキシサーバ（２１１）は、発信パケット（１１４）の前記セットを前記モバイルデバイス（１０２）から受信し、それらを前記リモートサーバ（２００）に転送し、前記プロキシサーバ（２１１）は、着信パケットの前記セットを前記リモートサーバ（２００）から受信し、それらを前記モバイルデバイス（１０２）に転送する、請求項２に記載のシステム。
【請求項３２】
前記チャネルのうちの１つがＷｉ−Ｆｉ（１１５）である場合、前記Ｗｉ−Ｆｉチャネル（１１５）は、前記Ｗｉ−Ｆｉチャネル（１１５）が前記モバイルデバイス（１０２）上で有効にされた後、既に前記Ｗｉ−Ｆｉチャネル（１１５）にバインドされたソケットを選択することによって、または前記モバイルデバイス（１０２）上の選択されたネットワークソケットを前記Ｗｉ−Ｆｉチャネル（１１５）にバインドすることによって指定される、請求項２に記載のシステム。
【請求項３３】
前記チャネルのうちの１つがセルラである場合、前記セルラチャネル（１１６）は、前記セルラチャネル（１１６）が前記モバイルデバイス（１０２）上で有効にされた後、既に前記セルラチャネル（１１６）にバインドされたソケットを選択することによって、または前記モバイルデバイス（１０２）上の選択されたネットワークソケットを前記セルラチャネル（１１６）にバインドすることによって指定される、請求項２に記載のシステム。
【請求項３４】
前記リモートサーバ（２００）は、Ｗｉ−Ｆｉ接続性を提供し、またはＷｉ−Ｆｉアクセスポイントとしての役割を果たす、請求項２に記載のシステム。
【請求項３５】
前記リモートサーバ（２００）は、セルラ接続性を提供し、またはセルラアクセスポイントとしての役割を果たし、前記セルラアクセスポイントは、スモールセル、マイクロセル、およびピコセルを含む、請求項２に記載のシステム。
【請求項３６】
利用可能な前記チャネル（１１５、１１６、１１７）のうちの１つのみがアクティブに使用され、使用されていない前記チャネルのうちの少なくとも１つが、このチャネルが障害を起こす場合には、使用されている前記チャネルのトラフィックを即時に搬送するためにアクティブに保持される、請求項２に記載のシステム。
【請求項３７】
リモートサーバを使用することなくルーティング処理（５０４）を管理し、モバイルインターネットトラフィック（５１２、５１３）上のデータ転送についてのインターネットの速度（５１４）を増大させるシステムであって、前記システムは、異なる割り当てられたルーティングチャネル（５１０、５１１）を通じてターゲットインターネットホスト（６００）と通信することが可能なクライアントの少なくとも１つのモバイルデバイス（５０２）を備え、前記チャネルは、異なるタイプのチャネル（５２４、５２５）であり、前記モバイルデバイス（５０２）は、仮想プライベートネットワーク（ＶＰＮ）サービスアプリケーション（５０３）を動作させるように構成され、前記サービスアプリケーションは、
ａ．仮想ネットワークインタフェース（５０５）を確立することであって、モバイルデバイス（５０２）のオペレーティングシステムは、発信パケット（５０８）のセットをこのインタフェースにルーティングするように構成され、前記ＶＰＮサービスアプリケーション（５０３）は、ユーザデータグラムプロトコル／インターネットプロトコル（ＵＤＰ／ＩＰ）（５１３）または伝送制御プロトコル／インターネットプロトコルＴＣＰ／ＩＰ（５１２）トラフィックネットワークソケットを使用して、前記発信データパケット（５０８）から抽出されたデータを前記インターネットホスト（６００）に送信する、確立することと、
ｂ．発信パケット（５０８）の前記セットを前記仮想ネットワークインタフェース（５０５）から読み出すことと、
ｃ．各発信パケット（５０８）を異なるトランスレータに割り当てることと、
ｄ．前記発信パケット（５０８）のデータを抽出することと、
ｅ．前記割り当てられたルーティングチャネル（５２４、５２５）のＵＤＰまたはＴＣＰソケットを介して前記抽出されたデータを前記インターネットホストに送信することと、
ｆ．着信データの前記セットを前記ターゲットホスト（６００）で生成されたＵＤＰまたはＴＣＰソケット（５１６、５１８、５２０、５２２）から受信することと、
ｇ．データパケット（５０９）を前記受信されたデータから構築することと、
ｈ．前記データパケット（５０９）を前記仮想ネットワークインタフェース（５０５）に書き込むことと、
を含む動作を実行する、システム。
【請求項３８】
前記ＶＰＮサービスアプリケーション（５０３）は、前記モバイルデバイス（５０２）のバックグランドで動作する、請求項３７に記載のシステム。
【請求項３９】
前記データパケット（５０８、５０９）は、オープンシステムインターコネクション（ＯＳＩ）レイヤ３インターネットプロトコル（ＩＰ）データグラムまたはＯＳＩレイヤ２イーサネットフレームである、請求項３７に記載のシステム。
【請求項４０】
前記仮想ネットワークインタフェース（５０５）は、ＴＵＮまたはＴＡＰインタフェースのいずれかである、請求項３７に記載のシステム。
【請求項４１】
保護された前記ソケット（５１５）は、レイヤ４ユーザデータグラムプロトコル（ＵＤＰ）ソケットおよびレイヤ４伝送制御プロトコル（ＴＣＰ）ソケットのうちの少なくとも１つを含む、請求項３７に記載のシステム。
【請求項４２】
ルーティングモジュールは、ＵＤＰトランスレータおよびＴＣＰトランスレータを使用してＵＤＰおよびＴＣＰトラフィック（５１２、５１３）をルーティングするように構成される、請求項３７に記載のシステム。
【請求項４３】
前記ＵＤＰトランスレータは、異なるチャネル（５２４、５２５）を通じて複数の別個のターゲットホストに接続する、請求項４２に記載のシステム。
【請求項４４】
前記異なるチャネルは、ＷｉＦｉチャネルおよびセルラチャネルである、請求項４３に記載のシステム。
【請求項４５】
前記ＵＤＰトランスレータは、異なるチャネル（５２４、５２５）を通じて単一のターゲットホスト（６００）に接続する、請求項４２に記載のシステム。
【請求項４６】
前記異なるチャネルは、ＷｉＦｉチャネルおよびセルラチャネルである、請求項４５に記載のシステム。
【請求項４７】
前記ＴＣＰトランスレータは、異なるチャネル（５２４、５２５）を通じて複数の別個のターゲットホストに接続する、請求項４２に記載のシステム。
【請求項４８】
前記異なるチャネルは、ＷｉＦｉチャネルおよびセルラチャネルである、請求項４７に記載のシステム。
【請求項４９】
前記ＴＣＰトランスレータは、異なるチャネル（５２４、５２５）を通じて単一のターゲットホストに接続する、請求項４２に記載のシステム。
【請求項５０】
前記異なるチャネルは、ＷｉＦｉチャネルおよびセルラチャネルである、請求項４９に記載のシステム。
【請求項５１】
データパケットを送出する保護された前記ソケット（５１５）は、実物理ネットワークインタフェースにバインドするように構成される、請求項３７に記載のシステム。
【請求項５２】
前記実物理ネットワークインタフェースは、Ｗｉ−Ｆｉ（５２４）またはセルラ（５２５）物理インタフェースである、請求項５１に記載のシステム。
【請求項５３】
前記ＶＰＮサービスアプリケーション（５０３）は、前記異なるチャネル（５２４、５２５）から受信されたデータを再組み立ておよび再順序付けし、データパケット（５０９）を前記受信されたデータから構築し、それらをモバイルデバイスアプリケーション（５０７）にルーティングするためにそれらを前記仮想ネットワークインタフェースに書き込むように構成される、請求項３７に記載のシステム。
【請求項５４】
保護された前記ソケット（５１５）は、前記ターゲットホストに直接接続する、請求項３７に記載のシステム。
【請求項５５】
前記サービスアプリケーションは、増大ポリシ（５１４）を含み、前記増大ポリシ（５１４）は、前記発信データをルーティングし、どのデータをどのチャネルに割り当てるかを決定する、請求項３７に記載のシステム。
【請求項５６】
前記増大ポリシは、構成可能なオプションのセットを含み、前記オプションは、コストを最小化し、伝送の速度を最適化し、または選択されたパケットタイプをルーティングするように前記増大ポリシ（５１４）を構成し、パケットタイプは、前記アプリケーション（５０７）ならびにパケットサイズ、パケット遅延要件、およびパケットのターゲットホストを含む他の要因に依存する、請求項５５に記載のシステム。
【請求項５７】
発信パケットの前記セットは、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および各チャネルの遅延のうちの少なくとも１つに基づいて、前記ＵＤＰ／ＴＣＰソケットを通じて送信される、請求項５５に記載のシステム。
【請求項５８】
モバイルデバイス上でハイパーテキスト転送プロトコル（ＨＴＴＰ）を通じてファイルのダウンロードの速度を増加させる方法であって、前記モバイルデバイスは、複数の無線チャネルを通じて通信することが可能であり、前記方法は、
ａ．ダウンロードされることになるファイルのＵＲＬを取得することと、
ｂ．それから前記ファイルをダウンロードすることができる前記ＵＲＬを使用して複数のＩＰアドレスを取得することであって、各ＩＰアドレスは、異なる無線チャネルに割り当てられる、取得することと、
ｃ．各無線チャネルに割り当てられた前記ＩＰアドレスとの通信リンクを確立することと、
ｄ．前記ＵＲＬを使用して、ダウンロードされることになる前記ファイルのメタデータを取得することと、
ｅ．前記メタデータを使用して前記ファイルを複数のブロックに分割することと、
ｆ．前記ファイルの前記ブロックのバッファマップを記憶することであって、前記バッファマップは、ブロックごとのダウンロード状態を含み、前記ダウンロード状態は、前記ブロックがダウンロードされたか、ダウンロードの処理中であるか、または消失しているかを識別する、記憶することと、
ｇ．次にダウンロードされることになる複数のブロックを含むブロックプールを記憶することと、
ｈ．前記ブロックプールをダウンロードされる必要がある新たなブロックで更新することと、
ｉ．複数のフェッチャスレッドを実行することであって、各フェッチャスレッドは、
ｉ．ダウンロードされたブロックについての前記ブロックプールをチェックすることと、
ｉｉ．前記ブロックプールが空である場合にスリープすることと、
ｉｉｉ．前記ブロックプールが空でない場合に、ブロックを前記ブロックプールから取得し、前記ブロックを前記ブロックプールから削除することと、
ｉｖ．前記ブロックを前記スレッドに割り当てることと、
ｖ．前記ブロックについての前記バッファマップのエントリを更新して、それをダウンロードしているとして識別することと、
ｖｉ．前記スレッドに割り当てられた前記ブロックをダウンロードすることと、
ｖｉｉ．前記ブロックを記憶システムに記憶することであって、前記記憶システムは、データベースおよびメモリを含み、前記データベースは、各ブロックおよび各ブロックが記憶されたメモリ位置についてのメタデータを含む、記憶することと、
ｖｉｉｉ．前記ブロックについての前記バッファマップのエントリを更新して、それをダウンロードされたものとして識別することと、
を含むコードを実行する、実行することと、
ｊ．各フェッチャスレッドを無線チャネルに割り当てることであって、前記無線チャネルは、Ｗｉ−Ｆｉチャネルまたはセルラチャネルであり、前記フェッチャスレッドは、その割り当てられたブロックをダウンロードするときに前記割り当てられた無線チャネルを利用し、それによって、Ｗｉ−Ｆｉまたはセルラチャネルを通じてコンテンツを特定のＩＰアドレスからダウンロードするために各スレッドを割り当てる、割り当てることと、
ｋ．ＨＴＴＰプロキシサーバを実行することであって、前記ＨＴＴＰプロキシサーバは、
ｉ．ファイルの範囲に関するメタデータについてキャッシュシステムをクエリし、
ｉｉ．ファイルデータの範囲を前記キャッシュシステムからフェッチし、
ｉｉｉ．ローカルアドレスを前記キャッシュシステムに記憶されたファイルデータの範囲に提供する、
ためのコードを含む、実行することと、
を備える、方法。
【請求項５９】
前記記憶システムは、前記キャッシュシステムを含み、前記キャッシュシステムは、ファイルブロックを一時的に記憶し、前記キャッシュシステムは、退避ポリシを含み、十分なメモリがある場合に、より古いファイルブロックを削除または上書きすることができる、請求項５８に記載の方法。
【請求項６０】
前記ブロックプールは、緊急プールをさらに含み、前記緊急プールは、緊急に必要とされるブロックのリストを含み、前記フェッチャスレッドは、緊急に必要とされる任意のブロックがあるかを決定するために前記緊急プールを最初にチェックし、緊急に必要とされる任意のブロックがある場合、前記フェッチャスレッドは、ブロックを前記緊急プールから選択し、前記ブロックは、それがダウンロードされることに成功した後までは前記緊急プールから削除されない、請求項５８に記載の方法。
【請求項６１】
ブロックは、前記ブロックの消費時間の前に時間のスライドウインドウに基づいて前記ブロックプールに割り当てられ、各ブロックは、それが消費されるべきときを指定するメタデータを有し、ブロックごとに、前記ファイルの現在の消費時間が前記ブロックの消費時間の前の前記スライドウインドウ内である場合、前記ブロックが前記ブロックプールに割り当てられる、請求項５８に記載の方法。
【請求項６２】
前記ファイルをダウンロードすることができる複数のＩＰアドレスを取得することは、ＤＮＳリゾルバを実行することを含み、前記ＤＮＳリゾルバは、
ａ．ドメイン名の信頼すべきＤＮＳサーバをクエリすることと、
ｂ．前記ドメイン名の信頼すべきでないＤＮＳサーバをクエリすることと、
ｃ．前記ホストの潜在的に記憶されたＩＰアドレスを発見するためにローカルデータベースをクエリすることと、
を含む、請求項５８に記載の方法。
【請求項６３】
前記ファイルをダウンロードすることができる複数のＩＰアドレスを取得することは、解決ブラウザを実行することを含み、前記解決ブラウザを実行することは、同一のファイルの異なるＵＲＬを直接取得するためにページを複数回見ることを含む、請求項５８に記載の方法。
【請求項６４】
各フェッチャは、物理ネットワークインタフェースにバインドされたソケットを少なくとも使用する、請求項５８に記載の方法。
【請求項６５】
前記物理ネットワークインタフェースは、Ｗｉ−Ｆｉおよびセルラインタフェースを含む、請求項６４に記載の方法。
【請求項６６】
少なくとも２つのフェッチャがあり、同一のファイルのブロックを単一のＩＰアドレスからフェッチするために、１つのフェッチャは、前記Ｗｉ−Ｆｉインタフェースにバインドされたソケットを使用し、もう一方のフェッチャは、前記セルラインタフェースにバインドされたソケットを使用する、請求項６５に記載の方法。
【請求項６７】
前記方法は、構成可能な数の前の秒の間にダウンロードされたデータの量を合計することによってインタフェースごとの前記ネットワークの速度を推定することをさらに備える、請求項５８に記載の方法。
【請求項６８】
前記方法は、前記ファイルをローカル位置から前記ＨＴＴＰサーバにアップロードするために使用され、前記フェッチャスレッドは、前記複数の無線チャネルを介して前記ローカルファイルのブロックを前記複数のＩＰアドレスまたは単一のＩＰアドレスにアップロードするために割り当てられ、前記複数のＩＰアドレスまたは前記単一のＩＰアドレスと関連付けられた前記サーバは、前記アップロードされたブロックを収集し、それらをもとのファイルに組み立てまたは再順序付けするソフトウェアを実行する、請求項５８に記載の方法。
【請求項６９】
モバイルデバイス上でハイパーテキスト転送プロトコル（ＨＴＴＰ）を通じてファイルのダウンロードの速度を増加させるシステムであって、前記モバイルデバイスは、複数の無線チャネルを通じて通信することが可能であり、前記システムは、
ａ．ダウンロードされることになるファイルのＵＲＬを受信することが可能なダウンロードモジュールであって、前記ダウンロードモジュールは、
ｉ．複数のＩＰアドレスを、前記複数の無線チャネルを介して前記ファイルをダウンロードするために使用することができる前記ＵＲＬから識別することが可能なユニフォームリソースロケータ（ＵＲＬ）リゾルバであって、
１．ドメイン名サーバ（ＤＮＳ）リゾルバであって、前記ＤＮＳリゾルバは、
Ａ．前記ファイルの前記ホスト名の第１のＩＰアドレスを前記ＵＲＬから識別する手段と、
Ｂ．複数の代替ＩＰアドレスを探索するクエリを実行する手段と、
を含む、ＤＮＳリゾルバと、
２．複数のインスタンスが追加のＩＰアドレスを識別するために前記ＵＲＬによって識別されたページを見る手段を含む解決ブラウザと、
を含む、ＵＲＬリゾルバと、
ｉｉ．ダウンロードスケジューリングアルゴリズムであって、
１．前記ファイルの前記メタデータをフェッチする手段と、
２．ダウンロードされることになる前記ファイルを複数のブロックに分割する手段と、
３．所望の消費時間の前の時間のスライドウインドウ内でダウンロードされることになる複数のブロックを識別する手段と、
４．バッファマップを記憶する手段であって、前記バッファマップは、ブロックごとのダウンロード状態を記憶し、前記ダウンロード状態は、前記ブロックがダウンロードされたか、ダウンロードされるか、または消失しているかを識別する、記憶する手段と、
５．ブロックプールを記憶する手段であって、前記ブロックプールは、前記スライドウインドウ内の前記複数のブロックを含む、記憶する手段と、
６．緊急プールを記憶する手段であって、前記緊急プールは、緊急に必要とされる複数のブロックを含む、記憶する手段と、
７．複数のフェッチャスレッドを実行する手段であって、各フェッチャスレッドは、
Ａ．前記緊急プールをチェックする手段と、
Ｂ．前記ブロックプールをチェックする手段と、
Ｃ．スリープする手段と、
Ｄ．ブロックを前記スレッドに割り当てる手段と、
Ｅ．前記スレッドに割り当てられた前記ブロックをダウンロードする手段と、
Ｆ．前記バッファマップをチェックする手段と、
Ｇ．前記バッファマップを更新する手段と、
Ｈ．前記ブロックを前記キャッシュシステムに記憶する手段と、
を含み、
前記フェッチャスレッドは、前記緊急プールを最初にチェックし、前記緊急プールが空である場合、前記フェッチャスレッドは、前記ブロックプールをチェックし、前記ブロックプールが空である場合、前記フェッチャスレッドはスリープし、
前記緊急プールが空でない場合、前記フェッチャスレッドは、前記第１のブロックをとり、それをダウンロードすることを試み、前記フェッチャスレッドが前記第１のブロックをダウンロードすることを終了すると、前記フェッチャスレッドは、前記第１のブロックを前記キャッシュシステムに記憶し、前記バッファマップにおいて前記第１のブロックをダウンロードされたものとしてタグ付けし、前記緊急プールが空であるが、前記ブロックプールが空でない場合、前記フェッチャスレッドは、前記ブロックプールにおいて前記第１のブロックをとり、前記第１のブロックが消失しているかまたはダウンロードしているかを決定するために前記バッファマップをチェックし、前記第１のブロックがダウンロード中である場合、前記フェッチャスレッドは、前記フェッチャスレッドが消失しているブロックを発見するまで、ブロックをとることを繰り返し、そのブロックが消失しているか、またはダウンロード中であるかを決定するために前記バッファマップをチェックし、前記フェッチャスレッドが消失しているブロックを発見するとき、前記フェッチャスレッドは、その消失しているブロックを前記スレッドに割り当て、前記フェッチャスレッドがその消失しているブロックをダウンロードすると、前記フェッチャスレッドは、前記バッファマップにおいてそのブロックをダウンロードされたものとしてマーク付けし、そのブロックを前記ブロックプールから削除する、
実行する手段と、
８．前記複数のフェッチャスレッドの各々を前記複数の無線チャネルのうちの１つに割り当てる手段であって、
Ａ．フェッチャスレッドごとに、データブロックを、そのルーティングが特定の無線チャネルを通るように構成されるＩＰアドレスからフェッチする手段であって、前記無線チャネルは、Ｗｉ−Ｆｉチャネルまたはセルラチャネルである、フェッチする手段と、
Ｂ．フェッチャスレッドごとに、物理ネットワークインタフェースにバインドされたソケットを使用する手段であって、前記ネットワークインタフェースは、Ｗｉ−Ｆｉまたはセルラインタフェースを含む、使用する手段と、
を含む、ダウンロードスケジューリングアルゴリズムと、
を含む、ダウンロードモジュールと、
ｂ．プログレッシブダウンローディングにおいて使用するために一時的にダウンロードされたファイルブロックを記憶するように構成されたキャッシュシステムであって、
ｉ．前記ファイルの識別子、前記ファイルの開始バイト、前記ファイルの終了バイト、長さ、アクセス時間、および前記ブロックの前記データへのポインタを含む、ダウンロードされたブロックに関するメタデータを記憶するように構成されたデータベースと、
ｉｉ．前記ファイルブロックを記憶するように構成されたメモリと、
を含む、キャッシュシステムと、
ｃ．レギュラーダウンローディングにおいて使用するために永続的にダウンロードされたファイルブロックを記憶するように構成された記憶システムと、
ｄ．構成可能な量の秒の間にダウンロードされたデータの量を合計することによって各ネットワークインタフェースの速度を計算する手段を含む統計エンジンと、
ｅ．ＨＴＴＰプロキシサーバであって、前記ＨＴＴＰサーバは、ダウンロードされたファイルブロックの前記ローカルアドレスを供給するように構成される、ＨＴＴＰプロキシサーバと、
ｆ．アプリケーションプログラミングインタフェース（ＡＰＩ）であって、前記ＡＰＩは、
ｉ．所望のネットワークチャネルを指定する手段と、
ｉｉ．ダウンロードされることになるファイルのＵＲＬを指定する手段と、
ｉｉｉ．前記複数の無線チャネルの前記速度に関する統計を要求し、前記システムから受信する手段と、
ｉｖ．ファイルデータのブロックを要求し、前記システムから受信する手段と、
を含む、ＡＰＩと、
を備える、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本出願は、米国特許出願であり、参照によってそれらの全体が本明細書に組み込まれる、２０１５年４月２０日に出願された米国仮特許出願第６２／１５０，２５０号および２０１５年７月２４日に出願された米国仮特許出願第６２／１９６，５８３号の利益を主張する。
【０００２】
本発明は、モバイルインターネットを改善し、特に、複数の無線ネットワークを組み合わせてモバイルインターネットの速度を増大させ、モバイルインターネットトラフィックを保護するシステムおよび方法に関する。
【背景技術】
【０００３】
スマートフォンおよびタブレットなどのモバイルデバイスが至る所に存在するようになってきた。最近の統計によると、人々は既に従来のデスクトップコンピュータよりも自身のモバイルアプリケーションを使用してインターネット上でより多くの時間を費やしている。それらのモバイルデバイスがＷｉ−Ｆｉおよび３Ｇ／４Ｇ接続などの無線ネットワークを使用してインターネットに接続するので、それらは、既にはるかに遅れをとっている無線インフラストラクチャに対して無類の制約を生じさせてきた。ユーザは、コーヒーショップ、空港、列車、または会議においてなどの多くの場所で低いモバイルインターネットを経験する傾向がある。現在の無線ネットワークの速度は、需要についていけない。最近の統計によると、米国における平均的なＷｉ−Ｆｉおよびセルラ速度は、４．８および３．７メガビット／秒をそれぞれ下回る。この速度は、今では消費者のスマートフォンが高解像度のスクリーンを備えているため、消費者が望むフルＨＤの１０８０画素またはクアッドＨＤのビデオはもちろんのこと、７２０画素のビデオをストリーミングするのにも十分でない。さらに、セルラ無線帯域幅の需要と供給とのギャップは今後増加するだけである。例えば、世界の人口の７０％がスマートフォンを有し、全てのモバイルデータトラフィックの６０％が２０２０年までにオンラインビデオからであることが予測される。ＣｉｓｃｏのＶｉｓｕａｌ  Ｎｅｔｗｏｒｋｉｎｇ  Ｉｎｄｅｘによる最新のモバイルデータ予測によると、２０１９年までには、モバイルの速度が２倍に増加する一方、モバイルデータに対する需要が１０倍に増加することが推定される。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
不十分な帯域幅は、低解像度のコンテンツ、ビデオが失速することなどが引き起こす不良なユーザ経験をもたらす。このことは、次いで、ユーザの関与が少なくなることに起因して何十億もの歳入の損失に変わる。例えば、Ｃｏｎｖｉｖａは、不良な品質のビデオストリーミングに起因して、２０１２年には世界的なプレミアコンテンツブランドが２１億６千万ドルの歳入を損失し、ビデオストリーミング品質の問題を改善しない場合、２０１７年のうちに、驚異的なことに、２００億ドルを損失するとの予測を報告している。速度およびコストの両方の目的で帯域幅集中型アプリケーションのためにモバイルユーザによって、またそれらのトラフィックをオフロードするためにセルラオペレータによってＷｉ−Ｆｉがますます使用されている。しかしながら、Ｗｉ−Ｆｉ単独では、その範囲がセルラと同じくらい偏在してはいないので十分でなく、公共空間におけるほとんどのＷｉ−Ｆｉネットワークは一般的には混み合っている。よって、遅いモバイルインターネットの速度の問題を解決する必要性が存在する。
【０００５】
本明細書で説明される任意の特徴または特徴の組み合わせは、コンテキスト、本明細書、および当業者のうちの１人の知識から明らかなように任意のそのような組み合わせに含まれる特徴が相互に一致する限り、本発明の範囲内に含まれる。本発明の追加の利点および態様は、以下の詳細な説明および特許請求の範囲において明らかである。
【課題を解決するための手段】
【０００６】
主題の開示は、より高速なモバイルインターネットのために複数の無線ネットワークまたはデバイスを効率的に組み合わせ、ネットワークの信頼性を増加させ、インターネットのセキュリティおよびプライバシー保護を強化し、データ消費およびネットワーク性能についてのマルチネットワークの見識を提供し、サービスのクラスに基づく経験の品質を提供するシステムおよび方法を特徴とする。
【０００７】
本発明の実施形態は、モバイルデバイスの発信および着信データパケットをルーティングするように仮想プライベートネットワーク（ＶＰＮ）サービスアプリケーションを動作させることと、リモートサーバとモバイルデバイスとの間でのデータパケットの転送のためにＶＰＮサービスアプリケーションを通じてモバイルデバイスをリモートサーバに結合することと、を備えるモバイルインターネットの速度を増大させる方法を特徴とする。本発明の別の実施形態は、増大したモバイルインターネットの速度を有するモバイルデバイスを特徴とする。モバイルデバイスは、モバイルデバイスの発信および着信データパケットをルーティングするようにモバイルデバイスのバックグランドで動作する仮想プライベートネットワーク（ＶＰＮ）サービスアプリケーション、ならびにモバイルデバイスとリモートサーバとの間でのデータパケットの転送のためにサービスアプリケーションによって確立された仮想ネットワークインタフェースを含んでもよい。
【０００８】
本発明のさらなる実施形態は、モバイルデバイスのインターネットの速度を増大させる仮想プライベートネットワーク（ＶＰＮ）サーバを特徴とする。ＶＰＮサーバは、モバイルデバイスとＶＰＮサーバとの間でのデータパケットの転送のための複数のネットワークソケット、および複数のネットワークソケットに結合され、モバイルデバイスによって送信されたデータパケットを送信ターゲットホストに転送し、モバイルデバイスによって要求されたデータパケットを取り出しターゲットホストから取り出すことが可能なデータパケット転送コンポーネントを含んでもよい。
【０００９】
また、複数のチャネルを通じて暗号化データパケットを同時に送信することと、単一の装置によって暗号化データパケットを受信することと、を含むデータパケットの転送を保護するために複数のチャネルを同時に使用する方法が本明細書で説明される。
【００１０】
追加の実施形態は、モバイルデバイスとリモートサーバとの間でのデータパケットの転送のための方法を含む。方法は、Ｗｉ−Ｆｉチャネルを介して第１の複数のデータパケットが転送されるように指定することと、セルラチャネルを介して第２の複数のデータパケットが転送されるように指定することと、Ｗｉ−Ｆｉチャネルおよびセルラチャネルの両方を使用して第１の複数のデータパケットおよび第２の複数のデータパケットを同時に転送することと、を備えてもよい。
【図面の簡単な説明】
【００１１】
【図１Ａ】リモートＶＰＮサーバの支援によって複数の無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックを増大させおよび保護するシステムを特徴とする本発明の例示的な実施形態を示す。
【図１Ｂ】リモートＶＰＮサーバの支援によって複数の無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックを増大させおよび保護するシステムを特徴とする本発明の例示的な実施形態を示す。
【図１Ｃ】リモートＶＰＮサーバの支援によって複数の無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックを増大させおよび保護するシステムを特徴とする本発明の例示的な実施形態を示す。
【図１Ｄ】リモートＶＰＮサーバの支援によって複数の無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックを増大させおよび保護するシステムを特徴とする本発明の例示的な実施形態を示す。
【図１Ｅ】リモートＶＰＮサーバの支援によって複数の無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックを増大させおよび保護するシステムを特徴とする本発明の例示的な実施形態を示す。
【図２】複数の無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックを保護する方法を特徴とする本発明の例示的な実施形態を示す。
【図３】Ａ〜Ｅ。同一のリモートサーバと通信するためにモバイルデバイス上でＷｉ−Ｆｉおよびセルラを同時に使用する方法を特徴とする本発明の例示的な実施形態を示す。
【図４Ａ】リモートＶＰＮサーバの支援なしに２つの無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックをルーティングしおよび増大させるシステムを特徴とする本発明の例示的な実施形態を示す。
【図４Ｂ】リモートＶＰＮサーバの支援なしに２つの無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックをルーティングしおよび増大させるシステムを特徴とする本発明の例示的な実施形態を示す。
【図４Ｃ】リモートＶＰＮサーバの支援なしに２つの無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックをルーティングしおよび増大させるシステムを特徴とする本発明の例示的な実施形態を示す。
【図５Ａ】複数のＵＤＰまたはＴＣＰ接続のために複数のユーザデータグラムプロトコル（ＵＤＰ）または伝送制御プロトコル（ＴＣＰ）接続を使用して異なるターゲットホストと通信するためにモバイルデバイス上でＷｉ−Ｆｉおよびセルラを同時に使用するシステムを特徴とする本発明の例示的な実施形態を示す。
【図５Ｂ】単一のＵＤＰまたはＴＣＰ接続のために複数のＵＤＰまたはＴＣＰ接続を使用して単一のターゲットホストと通信するためにモバイルデバイス上でＷｉ−Ｆｉおよびセルラを同時に使用するシステムを特徴とする本発明の例示的な実施形態を示す。
【図５Ｃ】複数のＵＤＰまたはＴＣＰ接続のために複数のユーザデータグラムプロトコル（ＵＤＰ）または伝送制御プロトコル（ＴＣＰ）接続を使用して異なるターゲットホストと通信するためにモバイルデバイス上でＷｉ−Ｆｉおよびセルラを同時に使用するシステムを特徴とする本発明の例示的な実施形態を示す。
【図６Ａ】複数のＵＤＰまたはＴＣＰ接続のために複数のユーザデータグラムプロトコル（ＵＤＰ）または伝送制御プロトコル（ＴＣＰ）接続を使用して異なるターゲットホストと通信するためにモバイルデバイス上でＷｉ−Ｆｉおよびセルラを同時に使用するシステムを特徴とする本発明の例示的な実施形態を示す。
【図６Ｂ】単一のＵＤＰまたはＴＣＰ接続のために複数のＵＤＰまたはＴＣＰ接続を使用して単一のターゲットホストと通信するためにモバイルデバイス上でＷｉ−Ｆｉおよびセルラを同時に使用するシステムを特徴とする本発明の例示的な実施形態を示す。
【図６Ｃ】複数のＵＤＰまたはＴＣＰ接続のために複数のユーザデータグラムプロトコル（ＵＤＰ）または伝送制御プロトコル（ＴＣＰ）接続を使用して異なるターゲットホストと通信するためにモバイルデバイス上でＷｉ−Ｆｉおよびセルラを同時に使用するシステムを特徴とする本発明の例示的な実施形態を示す。
【図７Ａ】ダウンロードのためのソロモード（Ｓｏｌｏ  Ｍｏｄｅ）の例示的な実施形態を示す。単一のデバイスは、２つの異なるＣＤＮサーバに接続することによって、２つの異なるネットワークインタフェース、セルラおよびＷｉＦｉを通じて異なるビデオブロック（すなわち、ビデオセグメント）をダウンロードする。
【図７Ｂ−Ｃ】２つのＣＤＮサーバを単一のサーバと、（ｉ）このサーバが図７ｂに示される２つのアドレス指定可能なＩＰアドレスを有し、または（ｉｉ）クライアントが送信元ＩＰ−それが有するインタフェースの各々のＩＰアドレスに基づいてパケットをルーティングすることができる、すなわち、図７ｃに示される送信元に基づくルーティングもしくはポリシに基づくルーティングの場合に、交換することができる例示的な実施形態を示す。図７ｂでは、クライアントが２つの異なるＩＰアドレスに接続する限り、ＩＰ１およびＩＰ２が交換可能であることに留意されたい。
【図８Ａ】アップロードのためのソロモードの例示的な実施形態を示す。単一のデバイスは、ＷｉＦｉおよびセルラ無線接続を通じて異なるビデオブロックを２つの異なるＣＤＮサーバ、サーバ１およびサーバ２に送信することによってビデオをアップロードする。サーバ２は、それが受信するビデオブロックをサーバ１に送信し、サーバ１は元のビデオを再構築する。ユーザは、ＷｉＦｉおよびセルラ接続の合計速度でアップロードを経験する。
【図８Ｂ−Ｃ】２つのサーバを単一のサーバと、（ｉ）このサーバが図８ｂに示される２つのアドレス指定可能なＩＰアドレスを有し、または（ｉｉ）クライアントが送信元ＩＰおよびそれが有するインタフェースの各々のＩＰアドレスに基づいてパケットをルーティングすることができる、すなわち、図８ｃに示される送信元に基づくルーティングもしくはポリシに基づくルーティングの場合に、交換することができる例示的な実施形態を示す。図８ｂでは、各クライアントが２つの異なるＩＰアドレスに接続する限り、ＩＰ１およびＩＰ２が交換可能であることに留意されたい。
【図９】ＢＭＶアーキテクチャ、およびソロモードにおけるプログレッシブビデオダウンローディング（Ｐｒｏｇｒｅｓｓｉｖｅ  Ｖｉｄｅｏ  Ｄｏｗｎｌｏａｄｉｎｇ）のときのビデオプレイヤとの可能な対話の実施形態を示す。ＢＭＶモジュール式アーキテクチャは、以下のメインコンポーネント：ダウンロードモジュール、統計エンジン、記憶システム、キャッシュシステムおよびｈｔｔｐプロキシサーバから構成される。プログレッシブダウンローディングでは、外部ビデオプレイヤがビデオを要求し、ダウンロードモジュールによってダウンロードされたブロックがキャッシュに記憶され、それらはＨＴＴＰプロキシサーバを通じて外部ビデオプレイヤに供給される。
【図１０】ＢＭＶアーキテクチャ、およびソロモードにおけるレギュラービデオダウンローディング（Ｒｅｇｕｌａｒ  Ｖｉｄｅｏ  Ｄｏｗｎｌｏａｄｉｎｇ）に使用されるときのビデオプレイヤとの可能な対話の実施形態を示す。レギュラーダウンローディングでは、ダウンロードされたビデオブロックが記憶システムに記憶され、要求したソフトウェア（ビデオダウンローダ）に利用可能となる。
【図１１】ＢＭＶアーキテクチャ、およびプログレッシブＨＬＳダウンローディング、ソロモードにおけるライブストリーミングのときのビデオプレイヤとのその潜在的な対話を示す。ライブストリーミング（ＨＬＳファイル）では、ダウンロードモジュールコンポーネント内部のＨＴＴＰライブストリーミングエンジンがアクティブになる。
【図１２】ＢＭＶアーキテクチャ、およびレギュラーＨＬＳダウンローディング、ソロモードのためのビデオダウンローダとのその可能な対話を示し、ＨＬＳファイルは記憶システムにダウンロードされる。
【図１３】プロトコルスタックの異なるレイヤにおける該当の技術の可能な実装および対応する利点を示す。１つ目に、Ａｎｄｒｏｉｄ  ａｐｐ  ＶｉｄｅｏＢｅｅで行ったのと同様に、エンドユーザがより高速なダウンロードを楽しむために直接使用することができるスタンドアロンのモバイルアプリケーションを開発することができる。２つ目に、それらのユーザへのビデオ配信を加速化するためにそれらのモバイルアプリケーション内部でコンテンツプロバイダによって使用することができるＳＤＫを提供することができる。最後に、ユーザおよび他のアプリケーションに対して透過的な、オペレーティングシステムレベルにおけるサービスとして該当の技術を実装することができる。デバイスの製造者またはモバイルオペレーティングシステムの所有者は、それらのクライアントに競争力のある性能を提供するためにこの技術をそれらの製品に組み込むことができる。
【図１４】ソロモードおよびグループモードの両方についての該当の室内実験におけるＶｉｄｅｏＢｅｅの性能の例をプロットする。この例について、以下の実験的なセットアップを使用しており、グループの２つのスマートフォン、（１）Ｇａｌａｘｙ  Ｎｅｘｕｓバージョン４Ｇ、および（２）ＡＴ＆Ｔ  ３ＧのＳａｍｓｕｎｇ  Ｃａｐｔｉｖａｔｅに接続する。ＷｉＦｉ接続については、無線ＡＰ  ８０２．１１ルータに接続する。全てのシナリオで同一の電話の配置を使用して同一の３分のＹｏｕＴｕｂｅのビデオを５回ダウンロードし、平均的なダウンロードの速度を報告する。ソロモードでは、１回目にセルラ接続のみを使用し、２回目にＷｉＦｉ接続のみを使用し、３回目に該当の技術による両方の接続を使用して（デュアルとして報告される）ビデオをダウンロードする。該当の技術によって、ＷｉＦｉおよびセルラ接続の合計速度を達成することが可能になることを検証する。グループモードでは、スマートフォン（セルラ１およびセルラ２として報告される）の各々を単独で最初に使用してダウンロードしており、次いで、それらをグループで接続し、それらの接続を集約する。グループモードでは、２つのセルラ接続の合計でダウンロードしたことを検証する。
【図１５】ユーザの統計から収集したデータから処理することによってそのままのＶｉｄｅｏＢｅｅの性能の例をプロットする。ソロモードにおけるプログレッシブビデオダウンローディングを考える。ＷｉＦｉのみを使用することに対し、ＶｉｄｅｏＢｅｅでの両方のインタフェースを使用するときに達成することができる速度比のヒストグラムをプロットし、これは、ＷｉＦｉを単独で使用することに対して達成する改善をとらえる。
【図１６】そのままのＶｉｄｅｏＢｅｅのソロモードのプログレッシブビデオダウンローディングの性能の例をプロットし、ここで、セルラ接続がＷｉＦｉ接続に寄与するメガビット／秒におけるレートのヒストグラムを描く。
【図１７】ＶｉｄｅｏＢｅｅアプリケーションのスクリーンショットを示す。
【発明を実施するための形態】
【００１２】
図１に示されるように、本発明は、モバイルインターネットトラフィックの速度を増加させるシステムである。システムは、複数のデータチャネルを通じて相互に通信することが可能な少なくとも１つのモバイルデバイス（１０２）およびリモートサーバ（２００）を備え、チャネルは、異なるタイプのチャネル（例えば、Ｗｉ−Ｆｉ（１１５）、セルラ（１１６）、およびＢｌｕｅｔｏｏｔｈ（１１７））である。本発明の主要な実施形態では、モバイルデバイス（１０２）は、仮想プライベートネットワーク（ＶＰＮ）サービスアプリケーション（１０３）を動作させるように構成され、サービスアプリケーションは、仮想ネットワークインタフェース（１０８）を確立する。モバイルデバイス（１０２）のオペレーティングシステムは、発信パケットの（１０７）のセットをこのインタフェースにルーティングし、着信パケット（１０６）のセットをこのインタフェースから受信するように構成され、仮想ネットワークインタフェース（１０８）は、ＶＰＮサービスアプリケーション（１０３）に結合されたネットワークソケットを使用して発信データパケットをリモートサーバ（２００）に送信する。典型的な実施形態では、ＶＰＮサービスアプリケーション（１０３）は、発信パケット（１０７）のセットを仮想ネットワークインタフェース（１０８）から読み出し、各発信パケット（１０７）を複数のチャネルのうちの１つに割り当て、割り当てられたチャネル（１１５、１１６、１１７）を介して発信パケットのセットをリモートサーバ（２００）に送信する。サービスアプリケーション（１０９）はまた、着信データパケットのセットをリモートサーバ（２００）から受信し、着信パケットは、複数のチャネルを通じて受信され、着信パケットを仮想ネットワークインタフェース（１０８）に書き込む。
【００１３】
主要な実施形態では、リモートサーバ（２００）は、インターネット上で複数のターゲットホスト（３００）と通信する。リモートサーバ（２００）は、複数のチャネルを介して発信パケットのセットをモバイルデバイス（１０２）から受信し、発信パケットのセットをターゲットホスト（３００）に転送し、着信パケット（２０７）のセットをターゲットホスト（３００）から受信し、各着信パケット（２０７）を複数のチャネルのうちの１つに割り当て、割り当てられたチャネル（１１５、１１６、１１７）を介して着信パケットのセットをモバイルデバイス（１０２）に送信する。
【００１４】
好ましい実施形態では、サービスアプリケーションは、増大ポリシ（ｂｏｏｓｔｉｎｇ  ｐｏｌｉｃｙ）（１１９）に従ってパケットをチャネルに割り当てる。いくつかの実施形態では、増大ポリシ（１１９）は、パケットを生成するアプリケーション、各チャネルのスループットおよび遅延などの複数のチャネルの各々のチャネル状態、ならびに複数のチャネルの各々のチャネルタイプに少なくとも基づいてアルゴリズムによって定義される。
【００１５】
種々の実施形態では、チャネルタイプは、デバイスツーデバイス接続、Ｗｉ−Ｆｉ、マイクロセル、ピコセル、および標準的なセルラ基地局チャネル（１１７）を含んでもよい。
【００１６】
いくつかの実施形態では、増大ポリシ（１１９）は、構成可能なオプションのセットを含んでもよい。オプションは、コストを最小化し、伝送の速度を最適化し、または選択されたパケットタイプを優先付けるように増大ポリシ（１１９）を構成してもよい。
【００１７】
いくつかの実施形態では、増大ポリシ（１１９）は、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および／または各チャネルの遅延に基づいて、複数のチャネルを通じて送信されることになるデータパケットを選択する。
【００１８】
いくつかの実施形態では、リモートサーバ（２００）はまた、増大ポリシ（２０８）を動作させるように構成され、増大ポリシ（２０８）は、発信パケットを優先付け、どのパケットをどのチャネルに割り当てるかを決定する。いくつかの実施形態では、増大ポリシ（２０８）は、パケットを生成するアプリケーション、各チャネルのスループットおよび遅延などの複数のチャネルの各々のチャネル状態、ならびに複数のチャネルの各々のチャネルタイプに少なくとも基づいてアルゴリズムによって定義される。
【００１９】
いくつかの実施形態では、リモートサーバ（２００）は、ＶＰＮサーバ（２０１）であり、ＶＰＮサービスアプリケーション（１０３）は、モバイルデバイス（１０２）のバックグランドで動作する。いくつかの実施形態では、データパケットは、オープンシステムインターコネクション（ＯＳＩ）レイヤ３インターネットプロトコル（ＩＰ）データグラムまたはＯＳＩレイヤ２イーサネットフレームであってもよい。いくつかの実施形態では、仮想ネットワークインタフェースは、ＴＵＮまたはＴＡＰインタフェース（１０８）のいずれかである。仮想ネットワークインタフェース（１０８）は、リモートサーバ（２００）またはデータパケットをリモートサーバ（２００）に転送するプロキシサーバ（２１１）として、宛先を有するデータパケットを除く発信データパケットを遮断するように構成されてもよい。いくつかの実施形態では、ネットワークソケット（１０５）は、レイヤ４ユーザデータグラムプロトコル（ＵＤＰ）ソケット、レイヤ４伝送制御プロトコル（ＴＣＰ）ソケット、またはレイヤ３ロー（ｒａｗ）ソケットを含んでもよい。いくつかの実施形態では、データパケットを送出するネットワークソケット（１０５）は、Ｗｉ−Ｆｉ（１１５）またはセルラ（１１６）物理インタフェースなどの実物理インタフェースにバインド（ｂｉｎｄ）するように構成されてもよい。可変的な実施形態では、複数のチャネルは、少なくともＷｉ−Ｆｉチャネル（１１５）およびセルラチャネル（１１６）、少なくとも２つのセルラチャネル、少なくともセルラチャネル（１１６）およびローカルデバイスツーデバイスチャネル、または少なくともＷｉ−Ｆｉチャネル（１１５）およびローカルデバイスツーデバイスチャネル（１１７）を含む。ローカルデバイスツーデバイスチャネルは、Ｂｌｕｅｔｏｏｔｈチャネル、Ｗｉ−Ｆｉ直接チャネル、ロングタームエボリューション（ＬＴＥ）直接チャネル、またはＺｉｇＢｅｅチャネルであってもよい。
【００２０】
また、図１を参照して、本発明の実施形態は、増大したモバイルインターネットの速度を有するモバイルデバイス（１０２）を特徴とする。モバイルデバイス（１０２）は、モバイルデバイス（１０２）の発信および着信データパケットをルーティングするようにモバイルデバイス（１０２）のバックグランドで動作する仮想プライベートネットワーク（ＶＰＮ）サービスアプリケーション（１０３）、ならびにモバイルデバイス（１０２）とリモートサーバ（２００）との間でのデータパケットの転送のためにサービアプリケーションによって確立された仮想ネットワークインタフェースを含んでもよい。サービスアプリケーションは、発信データパケットを処理し、ネットワークソケット（１０５）を使用して処理されたデータパケットを送出してもよい。処理されたデータパケットは、複数のチャネル（１１５、１１６、１１７）を通じて同時に送信され、データパケットは、受信された後に組み立てられる（ａｓｓｅｍｂｌｅｄ）。
【００２１】
別の実施形態では、データパケットは、暗号化スキームを使用して暗号化され（１１０）、または符号化スキームを使用して符号化され（１１１）、次いで、増大ポリシ（１１９）に基づいて複数のチャネルを通じて送信される。データパケットは、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および各チャネルの遅延のうちの少なくとも１つに基づいて、複数のチャネルを通じて送信されてもよい。複数のチャネルを通じて送信されるデータパケットは、データパケットが送信される前に暗号化される場合に解読されてもよい（１１０）。また、データパケットは、データパケットが送信される前に符号化される場合に復号される。
【００２２】
図１を参照して、本発明の実施形態は、モバイルデバイス（１０２）のインターネットの速度を増大させる仮想プライベートネットワーク（ＶＰＮ）サーバ（２０１）を特徴とする。ＶＰＮサーバは、モバイルデバイス（１０２）とＶＰＮサーバ（２０１）との間でのデータパケットの転送のための複数のネットワークソケット、および複数のネットワークソケット（１０５）に結合され、モバイルデバイス（１０２）によって送信されたデータパケットを送信ターゲットホスト（３００）に転送し、モバイルデバイス（１０２）によって要求されたデータパケットを取り出しターゲットホスト（３００）から取り出すことが可能なデータパケット転送コンポーネントを含んでもよい。データパケットは、複数のチャネルを通じて同時に転送されてもよく、データパケットは、受信された後に組み立てられる。１つの実施形態では、データパケットは、増大ポリシ（１１９）に基づいて複数のチャネルを通じて送信される。別の実施形態では、データパケットは、暗号化スキームを使用して暗号化され、または符号化スキームを使用して符号化され、次いで、増大ポリシに基づいて複数のチャネルを通じて送信される。増大ポリシ（１１９）は、モバイルデバイス（１０２）のユーザまたはモバイルデバイス（１０２）のサービスキャリアによって構成可能であってもよい。増大ポリシ（１１９）は、パケットを生成するアプリケーション、複数のチャネルの各々のチャネル状態、および複数のチャネルの各々のチャネルタイプに少なくとも基づいてアルゴリズムによって定義されてもよく、チャネル状態は、各チャネルのスループットおよび遅延を含み、チャネルタイプは、デバイスツーデバイス接続、Ｗｉ−Ｆｉ、マイクロセル、ピコセル、および標準的なセルラ基地局を含む。
【００２３】
１つの実施形態では、複数のネットワークソケットのうちの少なくとも２つは、データパケットをモバイルデバイス（１０２）から受信するために同時に使用される。別の実施形態では、複数のネットワークソケットのうちの少なくとも２つは、データパケットをモバイルデバイス（１０２）に送信するために同時に使用される。他の実施形態では、仮想ネットワークインタフェース（２０４）は、ネットワーク接続経路を介して送信ターゲットホスト（３００）または取り出しターゲットホスト（３００）に結合してもよい。ネットワーク接続経路は、データグラムパケット内のネットワークアドレス情報を再マッピングまたは修正するネットワークアドレス変換（ＮＡＴ）（２１４）をサポートすることができる。
【００２４】
図１Ａ〜Ｂに示されるように、リモートＶＰＮサーバ（２０１）の支援による複数の無線チャネルの同時使用は、モバイルデバイス（１０２）上の全てのトラフィックを増大させ、および保護することができる。要するに、この非限定的な実施形態は、システムをどのように作動させるかである。任意のインターネットトラフィック、すなわち、アプリケーションによって生成されたデータパケット（ＩＰデータグラムまたはイーサネットフレーム）は、オペレーティングシステムによって仮想ネットワークインタフェース（２０４）（ＴＵＮまたはＴＡＰインタフェース）にルーティングされる。次いで、仮想ネットワークインタフェースから読み出すために利用可能なデータパケットは、複数の無線チャネルを通じて同時に送信され、チャネルは、Ｗｉ−Ｆｉ（１１５）、セルラ（１１６）、または隣接デバイスを通じた間接（１１７）チャネル（例えば、隣接デバイスへのＢｌｕｅｔｏｏｔｈ接続によって確立され、隣接デバイスは、パケットのさらなる転送をサポートする）であってもよい。チャネルが遮断されたデータパケットを送出するために使用されるソケットは、ＴＣＰ、ＵＤＰ、またはＲＡＷソケットであってもよい。それらのソケットは、対応する物理ネットワークインタフェース（例えば、Ｗｉ−Ｆｉ、セルラ）をバインドするか、または単なる通常のソケットであるが、仮想ネットワークインタフェースの構成で実行されたＩＰアドレスに接続する（それらの実行されたＩＰアドレスを宛先とする任意のトラフィックが仮想ネットワークインタフェースにルーティングされないが、ターゲットＩＰアドレスに直接送信されるように）ようにバインドするかのいずれかで構成される。データパケットを送出する前に、モバイルデバイス（１０２）は、それらを暗号化または符号化してもよい。複数のチャネルを通じたデータパケットの発信は、ユーザが構成可能であり、キャリアが構成可能である増大ポリシに従い、ポリシはまた、チャネル状態、タイプ、および速度などを入力として受ける。サーバは、データパケットを複数のソケットから受信し、それらを組み立て（再順序付け、復号し、解読するなど）、インターネット上でそれらをターゲットホストに転送する。これが行われる１つの方法は、ＩＰ転送を可能にし、サーバ上でネットワークアドレス変換（２１４）との仮想ネットワークインタフェース（２０４）を確立することによってである。インターネット上で応答データパケットをリモートホストから受信すると、ＶＰＮサーバ（２０４）は、他の方向と同様に、複数のチャネルを同時に使用してそれらをモバイルデバイス（１０２）に転送する。データパケットをサーバからの複数のソケットから受信すると、モバイルデバイス（１０２）は、それらを組み立て（再順序付け、復号し、解読するなど）、それらをアプリケーション（１０９）に転送する。
【００２５】
図１Ｃでは、本発明をさらに明瞭にするフローチャートが提示され、「１」は、ネットワークソケット（１０５）を使用してデータパケットをモバイルデバイス（１０２）からリモートサーバ（２００）に送信するものとして指定される。「２」は、データパケットを受信するものとして指定され、それらのデータパケットの送信は、２つの部分に分割される。１つの実施形態では、パケットを送信することは、Ｗｉ−Ｆｉチャネルによる「１ａ」およびセルラチャネル（１１６）による「１ｂ」である。１つの実施形態では、ネットワークソケットは、スイッチとしての役割を果たし、それは、Ｗｉ−Ｆｉ（１１５）およびセルラ（１１６）チャネルを使用したモバイルデバイス（１０２）からリモートサーバ（２００）へのデータパケットの転送を意味する。
【００２６】
いくつかの実施形態では、「２ａ」は、データパケットをＷｉ−Ｆｉチャネル（１１５）から受信するものとして指定され、「２ｂ」は、データパケットをセルラチャネル（１１６）から受信するものとして指定される。１つの実施形態では、ネットワークソケットは、スイッチとしての役割を果たし、その主な機能は、データパケットを送信および受信するための特定のチャネルを発見することを解決することである。
【００２７】
図１Ｄを参照すると、本発明は、リモートサーバ（２００）とのセルラチャネル（１１６）通信がない実施形態を強調する。１つの実施形態では、フローチャートのフォーマットは、ネットワークソケットを使用してデータパケットをモバイルデバイス（１０２）からリモートサーバ（２００）に送信するものとして「１」が指定され、データパケットをインターネットホストから受信するものとして「２」が指定され、それらのデータパケットの送信および受信は、２つの部分に分割される。
【００２８】
いくつかの実施形態では、パケットを送信することは、セルラチャネル（１１６）による「１ａ」および間接チャネル（１１７）による「１ｂ」である。同様に、「２ａ」は、データパケットをセルラチャネルから受信するものとして指定され、「２ｂ」は、データパケットを間接チャネルから受信するものとして指定される。ローカルデバイスツーデバイスチャネル（間接チャネル）は、Ｂｌｕｅｔｏｏｔｈチャネル、Ｗｉ−Ｆｉ直接チャネル、ＬＴＥ直接チャネル、またはＺｉｇＢｅｅチャネルであってもよい。
【００２９】
ここで、図１Ｅを参照すると、本発明は、リモートサーバ（２００）とのＷｉ−Ｆｉチャネル通信がない実施形態を強調する。１つの実施形態では、フローチャートのフォーマットは、ネットワークソケットを使用してデータパケットをモバイルデバイス（１０２）からリモートサーバ（２００）に送信するものとして「１」が指定され、受信されたデータパケットとして「２」が指定され、それらのデータパケットの送信は、２つの部分に分割される。
【００３０】
いくつかの実施形態では、パケットを送信することは、Ｗｉ−Ｆｉチャネルによる「１ａ」および間接チャネル（１１７）による「１ｂ」である。同様に、「２ａ」は、データパケットをＷｉ−Ｆｉチャネル（１１５）から受信するものとして指定され、「２ｂ」は、データパケットを間接チャネル（１１７）から受信するものとして指定される。ローカルデバイスツーデバイスチャネル（間接チャネル）は、Ｂｌｕｅｔｏｏｔｈチャネル、Ｗｉ−Ｆｉ直接チャネル、ＬＴＥ直接チャネル、またはＺｉｇＢｅｅチャネルであってもよい。
【００３１】
ここで、図２を参照すると、本発明はさらに、データパケットの転送を保護するために複数のチャネを同時に使用する方法を特徴とすることができる。いくつかの実施形態では、方法は、複数のチャネルを通じて暗号化データパケットを同時に送信することと、単一の装置によって暗号化データパケットを受信することと、を備えてもよい。好ましくは、受信された暗号化データパケットは、組み立てられおよび解読される。いくつかの実施形態では、複数のチャネルは、少なくともＷｉ−Ｆｉチャネルおよびセルラチャネル、少なくとも２つのセルラチャネル、少なくともセルラチャネルおよびローカルデバイスツーデバイスチャネル、または少なくともＷｉ−Ｆｉチャネルおよびローカルデバイスツーデバイスチャネルを含んでもよい。ローカルデバイスツーデバイスチャネルは、Ｂｌｕｅｔｏｏｔｈチャネル、Ｗｉ−Ｆｉ直接チャネル、ＬＴＥ直接チャネル、またはＺｉｇＢｅｅチャネルであってもよい。
【００３２】
１つの実施形態では、暗号化データパケットは、セキュアポリシに基づいて複数のチャネルを通じて送信される。別の実施形態では、暗号化データパケットは、符号化スキームを使用して符号化され、次いで、セキュアポリシに基づいて複数のチャネルを通じて送信される。暗号化データパケットは、暗号化データパケットが送信される前に符号化される場合に復号されてもよい。暗号化データパケットは、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および各チャネルの遅延から選択された要因に少なくとも基づいて送信されてもよい。
【００３３】
いくつかの実施形態では、セキュアポリシは、暗号化パケットを生成するアプリケーションおよび複数のチャネルの各々のチャネル状態から選択された要因に少なくとも基づいてアルゴリズムによって定義されてもよい。他の実施形態では、チャネル状態は、各チャネルのスループットおよび遅延、複数のチャネルの各々のチャネルタイプから選択されたチャネルパラメータを含んでもよい。さらなる実施形態では、複数のチャネルの各々のチャネルタイプは、デバイスツーデバイス接続、Ｗｉ−Ｆｉ、マイクロセル、ピコセル、または標準的なセルラ基地局接続である。
【００３４】
図２に示されるように、複数の無線チャネルの同時使用は、モバイルデバイス（１０２）上の全てのトラフィックを保護することができる。モバイルデバイス（１０２）上の仮想ネットワークインタフェースにルーティングされるデータパケット（ＩＰデータグラムまたはイーサネットフレーム）を考える。それらのデータパケットは、暗号化および符号化され、次いで、セキュアポリシに基づいて複数のチャネルを同時に使用してリモートサーバ（２００）に送信される。このセキュアポリシは、データパケットを生成したアプリケーションならびにチャネル状態、タイプ、および速度などを入力として受ける。暗号化データパケットをモバイルデバイス（１０２）から受信すると、リモートサーバ（２００）は、それらを組み立てて（再順序付け、復号し、解読するなど）データパケットを取得する。モバイルデバイス（１０２）に再度送信される必要があるデータパケット（ターゲットホストからの応答）は、同様に、複数のチャネルを通じて同時に安全に送信されてもよい。
【００３５】
図３に示されるように、本発明の追加の実施形態は、モバイルデバイス（１０２）とリモートサーバ（２００）との間でのデータパケットの転送のための方法を特徴とすることができる。方法は、Ｗｉ−Ｆｉチャネルを介して第１の複数のデータパケットが転送されるように指定することと、セルラチャネルを介して第２の複数のデータパケットが転送されるように指定することと、Ｗｉ−Ｆｉチャネルおよびセルラチャネルの両方を使用して第１の複数のデータパケットおよび第２の複数のデータパケットを同時に転送することと、を備えてもよい。１つの実施形態では、リモートサーバ（２００）は、第１の複数のデータパケットを転送するための第１のインターネットプロトコル（ＩＰ）アドレスおよび第２の複数のデータパケットを転送するための第２のＩＰアドレスを有するように構成されてもよく、第２のＩＰアドレスは、第１のＩＰアドレスとは別個である。別の実施形態では、リモートサーバ（２００）は、第１の複数のデータパケットを転送するための単一のＩＰアドレスを有するように構成されてもよく、第２の複数のデータパケットは、単一のＩＰアドレスとは異なるＩＰアドレスでプロキシサーバ（２１１）を介してリモートサーバ（２００）とモバイルデバイス（１０２）との間で転送される。さらなる別の実施形態では、リモートサーバ（２００）は、第２の複数のデータパケットを転送するための単一のＩＰアドレスを有するように構成されてもよく、第１の複数のデータパケットは、単一のＩＰアドレスとは異なるＩＰアドレスでプロキシサーバ（２１１）を介してリモートサーバ（２００）とモバイルデバイス（１０２）との間で転送される。
【００３６】
いくつかの実施形態では、Ｗｉ−Ｆｉチャネルを介して転送されることになる第１の複数のデータパケットは、Ｗｉ−Ｆｉチャネル接続がモバイルデバイス（１０２）上で有効にされた後にデフォルトの構成またはアプリケーションプログラミングインタフェース（ＡＰＩ）の構成でモバイルデバイス（１０２）上で指定され、セルラチャネルを介して転送されることになる第２の複数のデータパケットは、セルラチャネル接続がモバイルデバイス（１０２）上で有効にされた後にデフォルトの構成またはアプリケーションプログラミングインタフェース（ＡＰＩ）の構成でモバイルデバイス（１０２）上で指定される。
【００３７】
他の実施形態では、Ｗｉ−Ｆｉチャネルを介して転送されることになる第１の複数のデータパケットは、Ｗｉ−Ｆｉチャネルがモバイルデバイス（１０２）上で有効にされた後、次いで、第１の複数のデータパケットを送信するためにそれらのソケットを使用して、既にＷｉ−Ｆｉチャネルにバインドされたソケットを選択することによって、またはモバイルデバイス（１０２）上の選択されたネットワークソケットをＷｉ−Ｆｉチャネルにバインドすることによって指定され、セルラチャネルを介して転送されることになる第２の複数のデータパケットは、セルラチャネルがモバイルデバイス（１０２）上で有効にされた後、次いで、第２の複数のデータパケットを送信するためにそれらのソケットを使用して、既にセルラチャネルにバインドされたソケットを選択することによって、またはモバイルデバイス（１０２）上の選択されたネットワークソケットをセルラチャネルにバインドすることによって指定される。
【００３８】
図３に示されるように、Ｗｉ−Ｆｉチャネル（１１５）およびセルラチャネル（１１６）は、以下の２つのアプローチのクラス、（ｉ）モバイルデバイス（１０２）がＷｉ−Ｆｉ（１１５）およびセルラ（１１６）接続のために２つの異なるＩＰアドレスに接続することであって（図３Ａ、３Ｂ、３Ｃ）、リモートサーバ（２００）に直接接続するか（図３Ａ）またはプロキシサーバ（２１１）を通じて接続するか（図３Ｂ、３Ｃ）のいずれかである、ことと、（ｉｉ）モバイルデバイス（１０２）が明確に少なくともソケットを物理インタフェースにバインドすること（図３Ｄにおけるセルラまたは図３ＥにおけるＷｉ−Ｆｉ）と、に従ういくつかの方法で、同一のリモートサーバ（２００）と通信するためにモバイルデバイス（１０２）上で同時に使用されてもよい。
【００３９】
利用可能なときに（セカンダリチャネルがデータを転送するために使用されないときでさえ）少なくとも２つのチャネルを同時にアクティブに保持することは、複数のネットワークにわたってシームレスな接続性を提供するための重要な技術である。例えば、２つの利用可能なチャネル、ＷｉＦｉおよびセルラを有し、ＷｉＦｉが現在プライマリインタフェースであることを仮定する。セルラインタフェースがアクティブに保持されないが、ＷｉＦｉが切断されるときのみアクティブになり、次いで、ＯＳがセルラインタフェースをアクティブにするために（使用できるまでには）数秒の遅延がある。これは、ＩＰデータグラムまたはイーサネットフレームをモバイルデバイスとＶＰＮサーバとの間で搬送する際に中断を生じさせることがあり、それによって、アプリケーションの現在のＴＣＰ／ＵＤＰセッションを切断する。
【００４０】
図４Ａに示されるように、本発明は、モバイルインターネットトラフィックの速度を増加させるシステムである。システムは、データチャネルをルーティングするユーザデータグラムプロトコル（ＵＤＰ）／伝送制御プロトコル（ＴＣＰ）を通じてターゲットホスト（６００）と通信することが可能な少なくとも１つのモバイルデバイス（５０２）を備えてもよく、チャネルは、異なるタイプのチャネルである（例えば、Ｗｉ−Ｆｉ（５２４）およびセルラ（５２５））。本発明の主要な実施形態では、モバイルデバイス（５０２）は、仮想プライベートネットワーク（ＶＰＮ）サービスアプリケーション（５０３）を動作させるように構成され、サービスアプリケーションは、仮想ネットワークインタフェース（５０５）を確立する。モバイルデバイス（５０２）のオペレーティングシステムは、発信パケットのセットをこのインタフェースにルーティングし、着信パケットのセットをこのインタフェースから受信するように構成され、仮想ネットワークインタフェース（５０５）は、ＶＰＮサービスアプリケーション（５０３）に結合されたネットワークソケットを使用して発信データパケットをターゲットホスト（６００）に送信する。典型的な実施形態では、ＶＰＮサービスアプリケーション（５０３）は、発信パケットのセットを仮想ネットワークインタフェース（５０５）から読み出し、各発信パケットをチャネルのルーティングのうちの１つに割り当て、割り当てられたチャネルを介して発信パケットのセットをターゲットホストに送信する。サービスアプリケーションはまた、着信データパケットのセットをホストから受信し、着信パケットは、チャネルのＵＤＰ／ＴＣＰを通じて受信され、着信パケットを仮想ネットワークインタフェース（５０５）に書き込む。
【００４１】
いくつかの実施形態では、サービスアプリケーションは、増大ポリシ（５１４）に従ってパケットをチャネルに割り当てる。いくつかの実施形態では、増大ポリシ（５１４）は、パケットを生成するアプリケーション、各チャネルのスループットおよび遅延などのルーティング処理の各々のチャネル状態、ならびに転送チャネルの各々のチャネルタイプに少なくとも基づいてアルゴリズムによって定義される。
【００４２】
いくつかの実施形態では、増大ポリシ（５１４）は、構成可能なオプションのセットを含む。オプションは、コストを最小化し、伝送の速度を最適化し、またはパケットタイプを送信および受信するためのルーティング処理を選択するように増大ポリシ（５１４）を構成してもよい。
【００４３】
いくつかの実施形態では、増大ポリシ（５１４）は、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および／または各チャネルの遅延に基づいて、チャネルの異なるルーティングを通じて送信されることになるデータパケットを選択する。
【００４４】
また、図４Ａを参照して、本発明の実施形態は、増大した（５１４）モバイルインターネットの速度を有するモバイルデバイス（５０２）を特徴とする。モバイルデバイス（５０２）は、モバイルデバイス（５０２）の発信および着信データパケットをルーティングするためにモバイルデバイス（５０２）のバックグランドで動作する仮想プライベートネットワーク（ＶＰＮ）サービスアプリケーション（５０３）、ならびにモバイルデバイス（５０２）とターゲットホスト（６００）との間でのデータパケットの転送のためにサービスアプリケーションによって確立された仮想ネットワークインタフェース（５０５）を備えてもよい。サービスアプリケーションは、発信データパケットを処理し、ネットワークソケットを使用して処理されたデータパケットを送出してもよい。処理されたデータパケットは、複数のチャネル（５２４、５２５）を通じて同時に送信され、データパケットは、受信された後に組み立てられる。
【００４５】
いくつかの実施形態では、データパケットは、ユーザデータグラムプロトコル（ＵＤＰ）／伝送制御プロトコル（ＴＣＰ）によって提供されるルーティング処理ならびに増大ポリシ（５１４）に基づいて複数のチャネル（５２４、５２５）を通じて送信される。データパケットは、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および／または各チャネルの遅延のうちの少なくとも１つに基づいて複数のチャネルを通じて送信されてもよい。
【００４６】
要するに、この非限定的な実施形態は、システムの作動方法である。パケットからのデータは、レイヤ３データグラム（またはレイヤ２フレーム）とレイヤ４パケットとの間で変換を実行することによってそれらのターゲットホストに送信され、それによって、通常のＵＤＰ／ＴＣＰソケットを使用してデータをインターネットに送出することができる。特に、発信トラフィックについて、ＩＰデータグラム（またはイーサネットフレーム）のデータは、抽出され、ＵＤＰ／ＴＣＰソケットを通じてターゲットホストに直接送信される必要がある。ターゲットホストが応答するとき、その応答データは、ＵＤＰ／ＴＣＰソケットから読み出され、ＩＰデータグラム（およびイーサネットフレーム）で包み込まれる必要があり、それらは次いで、ＴＵＮ（またはＴＡＰ）インタフェースに書き込まれる。
【００４７】
また、この非限定的な実施形態は、システムによる、異なるトラフィックタイプに対するインターネットの速度の増大の達成方法である。増大は、ＵＤＰまたはＴＣＰトラフィックのいずれかを加速化するために複数のレイヤ４ＵＤＰ／ＴＣＰソケットを同時に使用することによって達成される。それらのソケットは、Ｗｉ−Ｆｉまたはセルラのいずれかの適切なインタフェースにバインドするように構成され、また、仮想ネットワークインタフェース（例えば、保護されたソケット）にループバックしないように構成される。４つの増大の例示的なケース：（１）異なるターゲットホストへの複数のＴＣＰ接続：ホストＡをターゲットとするＴＣＰ接続をＴＣＰ  Ｗｉ−Ｆｉに割り当てることができ、ホストＢをターゲットとする別のＴＣＰ接続をＴＣＰセルラに割り当てることができる。（２）同一のターゲットホストへの単一のＴＣＰ接続：アプリケーションレイヤプロトコルに応じて、単一のＴＣＰ接続が複数のＴＣＰ接続に分解されることが可能となることがあり、例えば、各接続がＨＴＴＰ範囲要求においてデータの範囲の部分的な範囲をフェッチする。次いで、それらの接続をＷｉ−Ｆｉおよびセルラに同時に割り当てることができる。元の範囲の部分的な範囲がフェッチされるとき、それらは、パケットデータの順序を保証するために仮想ネットワークインタフェースに送信される前に再組み立てされる。（３）異なるターゲットホストへの複数のＵＤＰ接続：ホストＡをターゲットとするＵＤＰ接続をＵＤＰ  Ｗｉ−Ｆｉに割り当てることができ、ホストＢをターゲットとする別のＵＤＰ接続をＵＤＰセルラに割り当てることができる。（４）同一のターゲットホストへの単一のＵＤＰ接続：アプリケーションレイヤプロトコルに応じて、単一のＵＤＰ接続が複数のＵＤＰ接続に分解されることが可能となることがあり、例えば、各接続がＴＣＰのためのＨＴＴＰ範囲要求においてデータの部分などをフェッチする。次いで、それらの接続を上記のようにＷｉ−Ｆｉおよびセルラに同時に割り当てることができる。
【００４８】
図４Ｂ〜Ｃでは、本発明をさらに明瞭にするフローチャートが提示され、「１」は、保護されたソケット（５１５）を使用してデータパケットをモバイルデバイス（５０２）からターゲットホスト（６００）に送信するものとして指定され、「２」は、データパケットを受信するものとして指定され、それらのデータパケットの送信は、２つの部分に分割される。１つの実施形態では、パケットを送信することは、Ｗｉ−Ｆｉチャネル（５２４）による「１ａ」およびセルラチャネル（５２５）による「１ｂ」である。
【００４９】
いくつかの実施形態では、「２ａ」は、データパケットをＷｉ−Ｆｉチャネル（５２４）から受信するものとして指定され、「２ｂ」は、データパケットをセルラチャネル（５２５）から受信するものとして指定される。
【００５０】
ここで、図４Ｃを参照すると、本発明は、ＵＤＰ（５１０）のルーティング処理との通信がない実施形態を強調する。１つの実施形態では、フローチャートにおける「１」は、ネットワークソケットを使用してデータパケットをモバイルデバイス（５０２）からターゲットホスト（６００）に送信するものとして指定され、「２」は、受信されたデータパケットとして指定され、それらのデータパケットの送信は、２つの部分に分割される。１つの実施形態では、パケットを送信することは、Ｗｉ−Ｆｉチャネル（５２４）による１ａおよびセルラチャネル（５２５）による１ｂである。
【００５１】
図５〜６に示されるように、Ｗｉ−Ｆｉチャネル（５２４）およびセルラチャネル（５２５）は、以下の２つのアプローチのクラス：（ｉ）モバイルデバイス（５０２）がＷｉ−Ｆｉ（５２４）およびセルラ（５２５）接続のために同一のターゲットホスト（６００）の２つの異なるターゲットＩＰ（６０１、６０２）または２つの異なるターゲットホストに接続すること（図５Ａ、６Ａ、５Ｃ、６Ｃ）と、（ｉｉ）モバイルデバイス（５０２）がＷｉ−Ｆｉ（５２４）およびセルラ（５２５）接続のために同一のターゲットホスト（６００）の単一のターゲットＩＰに接続すること（図５Ｂ、６Ｂ）と、に従ういくつかの方法で、ターゲットホスト（６００）と通信するためにモバイルデバイス（５０２）上で同時に使用されてもよい。
【００５２】
ＳＤＫの増大
ソフトウェア専用の解決策を使用して、同一のコンテンツ（例えば、同一のビデオ）をダウンロードまたはアップロードするために同一のデバイスまたはプロキシデバイスのグループのいずれかに属するいくつかのネットワーク接続の帯域幅。以下では、ソフトウェアシステムの１つの実施形態を参照するためにＢＭＶ（ブースティングモバイルビデオ（Ｂｏｏｓｔｉｎｇ  Ｍｏｂｉｌｅ  Ｖｉｄｅｏ）を使用する。単一のデバイスのネットワーク接続を集約するケースを説明するためにソロモードに言及する。
【００５３】
ソロモードでは、Ａｎｄｒｏｉｄスマートフォン、タブレット、およびビデオプレイヤなど、複数のネットワークインタフェースを有するデバイスによって該当の技術を使用することができる。例えば、ビデオをダウンロードすることを試みる空港内のユーザは、ＷｉＦｉおよびセルラ接続を同時に使用することによってビデオをダウンロードするように空港のＷｉＦｉ接続を自身のセルラ接続に集約するために該当の技術を使用することができる。
【００５４】
この技術の実装方法の例を説明する。図１３における分類に示されるプロトコルスタックのいくつかのレイヤにおいて該当のソフトウェアを配置することができる。まず、アプリケーションレイヤでは、Ａｎｄｒｏｉｄ  ａｐｐ  ＶｉｄｅｏＢｅｅで行ったのと同様に、スタンドアロンのモバイルアプリケーションを開発することができる。エンドユーザは、特定のアプリケーションのプレイヤの内部でビデオを見るためにＶｉｄｅｏＢｅｅを使用する（ビデオが多くの異なるプロバイダからストリーミングされる場合でさえ）。次に、Ｎｅｔｆｌｉｘモバイルアプリケーションなど、サーバへの複数の経路を使用することによってそれらのモバイル配信を加速化するために他のモバイルアプリケーションによって使用することができるＳＤＫを提供することができる。このケースでは、エンドユーザは、ビデオをいつものように見るためにＮｅｔｆｌｉｘモバイルアプリケーションを使用し、該当の技術は、帯域幅を増加させるためにユーザに対して透過的にまたは明確なパーミッションでバックグランドで使用される（例えば、通知および増大ボタンを通じて）。さらに、オペレーティングシステムレベルにおけるサービスとして該当の技術をユーザおよび他のアプリケーションに対して透過的に実装することができる。そのシナリオでは、サービスは、複数の経路を使用することによってデバイスに着信される全てのＨＴＴＰトラフィックを増大させることができる。
【００５５】
いくつかの実施形態では、ビデオのストリーミングは、ＢＭＶおよびＡＰＩインタフェースを使用する。この実施形態では、ビデオプレイヤ、例えば、Ａｎｄｒｏｉｄシステムの内蔵プレイヤまたはＭＸ−Ｐｌａｙｅｒプレイヤなどの第三者ビデオプレイヤは、図９に示されるように、下記のように進行する。それは、例えば、要求されたネットワークを提供するためにｓｅｔＮｅｔｗｏｒｋｓ（ネットワーク）を呼び出すことによって、ビデオをダウンロードためにどのネットワークインタフェースを使用することを望むかを最初に指定する。次いで、それは、例えば、プログレッシブダウンロード（ビデオｕｒｌ）と呼ばれる関数を呼び出すことによってダウンロードを開始し、再生することを望むビデオのビデオｕｒｌ（ユニフォームリソースロケータ）は、例えば、ｈｔｔｐ：／／ｒｅｍｏｔｅｓｅｒｖｅｒ．ｃｏｍ／ｖｉｄｅｏ．ｍｐ４である。ＢＭＶは、ビデオパーツ（ｖｉｄｅｏ  ｐａｒｔｓ）をダウンロードし、それらをキャッシュに一時的に記憶し、ローカルＨＴＴＰプロキシサーバを通じてそれらを供給することによってそれらをローカルに利用可能にする。いくつかの実施形態では、ダウンロードされたパーツは、ローカルＵＲＬである、例えば、ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ／ｖｉｄｅｏ．ｍｐ４から利用可能となる。ビデオプレイヤは最後に、例えば、ｓｅｔＤａｔａＳｏｕｒｃｅ（「ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ／ｖｉｄｅｏ．ｍｐ４」）と呼ばれる関数を呼び出すことによってビデオデータをこのローカルＵＲＬにフェッチするべき位置を設定する必要があり、次いで、このローカルＵＲＬから直接再生するためにビデオパーツをフェッチする。ダウンロードが進行中の間は、ビデオプレイヤはまた、異なるネットワークインタフェースからダウンロードされたデータ、ネットワークインタフェースの速度などを含む、ＢＭＶシステムからの種々の統計を要求することができる。
【００５６】
ダウンロードモジュールは、ビデオパーツをダウンロードすることを担う主なソフトウェアである。いくつかの実施形態では、それは、ＵＲＬリゾルバの支援により複数のネットワーク接続を確立し、それらを同時に使用し、それは、スケジューリングアルゴリズムを使用して各々の接続を通じてどのビデオ範囲をダウンロードするかを管理し、それは、キャッシュ（プログレッシブダウンローディング）または記憶システム（レギュラーダウンローディング）のいずれかを使用してダウンロードされたパーツを記憶する。
【００５７】
図９を参照すると、ＵＲＬリゾルバは、ＢＭＶにおいて重要な役割を果たす。今日のＡｎｄｒｏｉｄデバイス上では、２つのインタフェースの各々が異なるＩＰアドレスに接続している限り、セルラインタフェースおよびＷｉＦｉインタフェースを同時に利用することができる（デバイスをルート化（ｒｏｏｔ）することなく）。よって、課題は、それらのインタフェースの各々を通じて同一のコンテンツのパーツをなおダウンロードする間にどのようにこれを達成することができるかである。該当の新規の見解は、今日の人気のあるコンテンツが、異なるＩＰアドレスを有するいくつかのコンテンツ配信ネットワーク（ＣＤＮ）サーバ（これは、例えば、ＹｏｕＴｕｂｅ、Ａｍａｚｏｎ、ＮｅｔＦｌｉｘなどについてのケースである）に記憶されるという事実を利用することによってそれを行うことができることである。よって、例えば、セルラインタフェースおよびＷｉＦｉインタフェースを、異なるＩＰアドレスを有するが同一のコンテンツを供給する２つの異なるＣＤＮサーバに接続することができる。それを行うことができるように、ＢＭＶがＣＤＮの異なるサーバのＵＲＬアドレスを高速かつ信頼して取得することを可能にする必要がある。これは正確には、ＵＲＬリゾルバが行うことである。１つの実施形態では、ＵＲＬリゾルバは、提供されたＵＲＬ（例えば、ｈｔｔｐ：／／ｒｅｍｏｔｅ‐ｓｅｒｖｅｒ．ｃｏｍ／ｖｉｄｅｏ．ｍｐ４）から開始し、異なるＩＰアドレスに接続する追加のＵＲＬを識別する。これを達成するために、使用することができる技術は、次に説明する２つを含むことができ、どの技術を使用できるかは、アクセスしようとするコンテンツホストに依存することがある。
【００５８】
ＤＮＳリゾルバ：ＢＭＶは、ビデオのホスト名（該当の例では、ｒｅｍｏｔｅ−ｓｅｒｖｅｒ．ｃｏｍの）のＮ個の（Ｎは無線インタフェースの数）異なるＩＰアドレスを発見するために明確なドメイン名解決（ＤＮＳ解決）を実行することができる。次いで、そのたびにホスト名ｒｅｍｏｔｅ−ｓｅｒｖｅｒ．ｃｏｍをＮ個の異なるＩＰアドレスのうちの１つに置き換えることによってＮ個の異なるＵＲＬアドレスを作成することができる。この技術をＤＮＳリゾルバと呼ぶ。該当の例を続けて、ＢＭＶがＩＰアドレス１９２．１６８．１．１および１９２．１６８．１．２を発見すると仮定して、次いで、異なるサーバ上の同一のコンテンツにアクセスする２つのＵＲＬであるｈｔｔｐ：／／１９２．１６８．１．１／ｖｉｄｅｏ．ｍｐ４およびｈｔｔｐ：／／１９２．１６８．１．２／ｖｉｄｅｏ．ｍｐ４を作成することができる。要求された数のＩＰアドレスを高速かつ信頼して取得することを保証するために、ＢＭＶは、以下を含むクエリを実行する。
−ドメイン名の信頼すべき（Ａｕｔｈｏｒｉｔａｔｉｖｅ）ＤＮＳサーバへのクエリ。
−ドメイン名の信頼すべきでないＤＮＳサーバへのクエリ、それらのサーバは、ローカルネットワークＤＮＳサーバとともにＧｏｏｇｌｅ  ＤＮＳサーバ、オープンＤＮＳサーバなどの一般のパブリックＤＮＳサーバを含む。
−ホストの潜在的に記憶された（かつ期限切れでない）ＩＰアドレスを発見するためのそのローカルデータベースへのクエリ。このデータベースは、ローカルに利用可能であり、人気のあるビデオプロバイダ、例えば、Ｄａｉｌｙ  ｍｏｔｉｏｎの特定のセットのために頻繁に更新される。
【００５９】
１つの実施形態では、クエリは、連続して実行され、プログラムは、十分な数のＩＰアドレスを収集すると停止する。それらのクエリが実行される順序は、アプリケーションおよびユーザの振る舞いに依存することがある。例えば、同一のホストに度々アクセスするユーザには、最も効率的なのは、複数のＩＰアドレスをローカルに記憶し、それらを最初にチェックすることである。
【００６０】
解決ブラウザ（Ｒｅｓｏｌｕｔｉｏｎ  Ｂｒｏｗｓｅｒ）：いくつかのホストでは、単純にホスト名をＩＰアドレスに置き換えることでは有効なＵＲＬが得られず、よって、ＤＮＳリゾルバ技術は機能しない。これについての理由は、以下を含む。
−１つ目に、ホストは、その特定のＵＲＬについて計算する署名をＵＲＬの内部に組み込むことができる。署名を更新することなくホスト名を異なるＩＰアドレスに置き換えることは、無効なＵＲＬにつながる。しかしながら、ホストによってのみ署名を計算することができる。例として、署名を含むＹｏｕＴｕｂｅビデオのＵＲＬは、ｈｔｔｐ：／／ｍ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｖｉｄｅｏｌｄ＆ｓｉｇｎａｔｕｒｅ＝ＡＡＡの形式である。
−２つ目に、いくつかのケースでは、ホストはまた、ブラウザの送信元ＩＰアドレスをＵＲＬに挿入し、ブラウザのＩＰアドレスを通じて署名を計算し、それによって、異なるＩＰアドレスを有するクライアントによってＵＲＬが使用されることを防止する。例えば、このフォーマットのＹｏｕＴｕｂｅのビデオのＵＲＬは、ｈｔｔｐ：／／ｍ．ｙｏｕｔｕｂｅ．ｃｏｍ／ｗａｔｃｈ？ｖ＝ｖｉｄｅｏｌｄ＆ｓｏｕｒｃｅ＿ｉｐ＝１．２．３．４＆ｓｉｇｎａｔｕｒｅ＝ＡＡＡである。
【００６１】
異なるインタフェースが異なるＩＰアドレスを有するので、セルラインタフェースを通じてビデオをダウンロードするために、ＷｉＦｉインタフェースを通じてブラウザによって発見されたＵＲＬを使用することはできない。このケースに対処するために、ＢＭＶの１つの実施形態は、解決ブラウザと呼ばれる内蔵ウェブブラウザを特徴とする。解決ブラウザは、同一のビデオの異なるＵＲＬを直接取得するためにページを複数回見ることが可能である（ビデオサーバは、負荷分散を理由に異なるＵＲＬを生成する）。また、それは、異なるネットワークインタフェースを通じてブラウザインスタンスをインスタンス化することができ、よって、そのインタフェースを通じて使用されることになるＵＲＬを直接取得する（例えば、それは、セルラインタフェースで使用されることになるＵＲＬを直接取得するためにセルラインタフェースを使用してウェブページを見る）。例えば、携帯電話上で稼働し、ＷｉＦｉを通じてブラウザを使用するＢＭＶは、ＵＲＬ、ｈｔｔｐ：／／ｐｒｏｘｙ１．ｒｅｍｏｔｅ−ｓｅｒｖｅｒ．ｃｏｍ／ｖｉｄｅｏ．ｍｐ４？ｓｏｕｒｃｅｌＰ＝７．７．７．１＆ｓｉｇｎ＝ＡＡＡＡを取得することができ、セルラを通じてブラウザを使用するＢＭＶは、ＵＲＬである、ｈｔｔｐ：／／ｐｒｏｘｙ２．ｒｅｍｏｔｅ−ｓｅｒｖｅｒ．ｃｏｍ／ｖｉｄｅｏ．ｍｐ４？ｓｏｕｒｃｅｌＰ＝７．７．７．２＆ｓｉｇｎ＝ＢＢＢＢを取得することができ、７．７．７．１は、ＷｉＦｉのＩＰアドレスであり、７．７．７．２は、携帯電話のセルラＩＰアドレスである。ＢＭＶはまた、ｐｒｏｘｙ１．ｒｅｍｏｔｅ−ｓｅｒｖｅｒ．ｃｏｍおよびｐｒｏｘｙ２．ｒｅｍｏｔｅ−ｓｅｒｖｅｒ．ｃｏｍが２つの異なるＩＰアドレス（ＷｉＦｉおよびセルラを同時に使用することが必要な）に対して解決することをチェックすることができる。それらがたまたま同一のＩＰアドレスに対して解決する場合、ＢＭＶは、１つの実施形態では、それが異なるＩＰアドレスを取得するまでインタフェースのうちの１つを通じて見ることを続ける。
【００６２】
ＵＲＬリゾルバ障害：リゾルバが全てのインタフェースのＵＲＬについてあらかじめ定められた制限時間内に発見することができない場合、１つの実施形態では、ＢＭＶは、それが既に有する（ＢＭＶが少なくとも１つのＵＲＬを有する任意のケースにおいてであることに留意）ＵＲＬを利用してダウンロードを開始し、それによって、起動時間が影響されない。いくつかのトリガにおいて、例えば、システムが定常状態に到達するとき（後に説明するように、これは、緊急のブロックが必要とされないことを意味する）、または予め定められた時間ウインドウが経過した場合、ＢＭＶは、インタフェースを維持するためのＵＲＬを取得するためにＵＲＬリゾルバ技術を再開することができる。
【００６３】
ＵＲＬリゾルバが必要とされないとき：クライアントが複数のルーティングテーブルを使用してパケットをルーティングすることができるケースでは、すなわち、送信元に基づくルーティング（異なる送信元ＩＰアドレス、すなわち、異なるネットワークインタフェースのＩＰアドレスに基づく）、またはポリシに基づくルーティングを使用することによって、図７ｃおよび８ｃに示されるように、クライアントが両方のインタフェースを使用して単一のＩＰに直接接続することができるので、ＵＲＬリゾルバが必要とされない。このケースでは、ＵＲＬリゾルバは、各インタフェースを通じて送信されるパケットが適切にサーバにルーティングされることを保証するために、２つのルーティングテーブル（送信元に基づくルーティング）またはルーティングポリシ（ポリシに基づくルーティング）の維持を実行する。
【００６４】
スケジューリングアルゴリズム
該当のスケジューリングアルゴリズムは、１つの実施形態では、コンテンツのどのパーツが各インタフェースを通じてダウンロードされるかを決定し、いくつかの所望の特性を特徴とする。特に、この実施形態では、それは、
−待機および起動時間を最小化する円滑なストリーミングを提供し、
−接続の合計速度に近い速度を達成し、
−チャネル変動および損失の多い接続に対してロバストであり、明確にチャネル統計を記録する必要なく、各インタフェースを通じてコンテンツのどのパーツをダウンロードするかを調節し、
−再生時間に十分に近くない限りコンテンツをダウンロードせず、それによって、ユーザが探索するとき（ユーザが見ようとするビデオのパーツを前または後に変更する）、高速に適合させることができ、
−制限された記憶空間でデバイス上で動作させることができる。
【００６５】
バッファマップは、全てのビデオブロックについての状態を維持する。それは、ビデオブロックの各々が１）ダウンロードされ、および利用可能であるか、２）現在ダウンロード中であるか、または３）消失しているかを記録する。ＢＭＶは、ビデオのいくつかのブロックがキャッシュにおいて利用可能であるかをチェックする。そうである場合、それらをダウンロードされたものとしてマーク付けする。全ての残りのビデオブロックが消失しているものとしてマーク付けされる（ケース３）。
【００６６】
ブロックプールは、ダウンロードしようとしているスライドウインドウで、すなわち、再生時間からの時間Ｗ内で重複する（部分的にでも）ブロックのサブセットをバッファマップに維持する。これは、ダウンロードのためにスレッドに利用可能なブロックのセットである。最初に、それは、全てのブロックを時間ゼロ（ビデオの開始時間）から時間Ｗ内に含む。ブロックプールは、順序付けられたセットであり、再生時間により近いブロックを最初に供給する。
【００６７】
緊急プールは、次のアルゴリズムで説明するように、緊急に必要とされ、２つ以上のスレッドが並列にダウンロードを試みることを可能にするブロックのセットの維持するブロックプールのサブセットである。緊急プールはまた、最初に供給される再生時間により近いブロックを有する順序付けられたセットである。緊急プールは、空であることがあり、この望ましい状態を「定常状態」と呼ぶ。最初に、緊急プールは、ビデオを再生することを開始するために必要な最初のＳ個のブロックを含み、Ｓは、指定されたパラメータである。緊急プールのサイズは、セーフティパディング時間と呼び、また、スケジューリングアルゴリズムへの入力として指定されるパラメータΔの関数である。ＳおよびΔは、ＢＭＶまたはユーザによって指定されることがあり、デバイス、コンテンツおよび無線状態の関数であることができる。
【００６８】
１つの実施形態では、クエリが連続して実行され、プログラムは、十分な数のＩＰアドレスを収集すると停止する。それらのクエリが実行される順序は、アプリケーション、およびユーザの振る舞いに依存することがある。例えば、ユーザが同一のホストに度々アクセスするために、最も効率的なのは、複数のＩＰアドレスをローカルに記憶し、それらを最初にチェックすることである。
【００６９】
アルゴリズム
入力：パラメータＳ、Δ、Ｗ、Ｔ１、Ｔ２、Ｔ３。初期状態：バッファマップにおける全てのブロックが消失しているとしてタグ付けされる。ブロックプールは、開始時間からのＷ内である全てのブロックを含む。緊急プールは、開始時間からの最初のＳ個のブロックを含む。
【００７０】
キャッシュからの取り出し：
−ＢＭＶは、キャッシュがブロックのいくつかをバッファマップに既に有しているかをチェックし、そのようなブロックを発見した場合、バッファマップにおいてそれらをダウンロードされたものとしてタグ付けする。
【００７１】
スレッドダウンローディング
−各々のアクティブなスレッドは、緊急プールを最初にチェックし、それが空である場合、次いで、ブロックプールをチェックし、それが空である場合、それはスリープする。緊急プールまたはブロックプールに追加される新たなブロックがある場合、全てのスレッドが通知される（スリープから起動し、再度チェックする）。
−緊急プールが空でない場合、スレッドは、最初のブロックをとり、それをダウンロードすることを試み、それがダウンロードされると、それはブロックをキャッシュシステムに渡し、バッファマップにおいてブロックをダウンロードされたものとしてタグ付けする。ＢＭＶは、ブロックを緊急プールから削除する。複数のスレッドがダウンロードする最初の緊急ブロックを同時に選択することができることに留意されたい。同一のブロックをダウンロードすることを試みるスレッドの数を、インタフェースごとに最大で１つに制限する。
−緊急プールが空であるが、ブロックプールが空でない場合、スレッドは、ブロックプールにおいて最初のブロックをとる。スレッドは、バッファマップ上で、ブロックが消失しているか、またはダウンロード中であるかをチェックし、消失している場合、それをダウンロード中であるとしてマーク付けし、それをサーバから要求することを進行させ、それがダウンロード中である場合、ブロックプールに戻り、第２のブロックをチェックする。それが消失しているブロックを発見するまでこの方式で継続する。それがブロックをダウンロードすると、それをキャッシュシステムに渡し、バッファマップにおいてそれをダウンロードされたものとしてマーク付けする。ＢＭＶは、それをブロックプールから削除する。
【００７２】
プール更新：Ｔ１秒ごとに、ＢＭＶは、現在の再生時間をチェックし、再生時間が進行している場合にプール更新を実行する。プール更新の実行は代わりに、ＢＭＶによる新たな再生時間の受信（ビデオプレイヤからの）によってトリガされてもよい。プール更新は以下のように行われる：
−緊急プールまたはブロックプールにおけるブロックが現在の再生時間よりも前である場合、それを削除する。同様に、ブロックが再生時間の後のＷ内でない場合、それも削除する。そのようなケースは、ユーザが再生時間を探索し、前または後に変更するときに発生することがある。
−それは、バッファマップにおいてダウンロードされたものとしてマーク付けされておらず、再生時間からのＷ内である（部分的にでも）全てのブロックをブロックプールに追加する。
−それは、再生時間のΔ内である全ての消失しているブロックを緊急プールに追加する。
−それは、バッファマップにおいてスレッドによってダウンロード中であるとしてタグ付けされた各ブロックをチェックし、それを緊急プールに移動させるかを決定するために以下のテストを使用する。Ｐは、ブロックが再生されるまでのビデオの経過時間を表す。ＢＭＶは、推定されるネットワークインタフェースの速度を、このインタフェースのアクティブなスレッドの数およびブロックサイズの積で乗算することによって、スレッドがブロックをダウンロードするための推定時間Ｄを計算する。Ｄ＋Δ＜Ｐの場合、ＢＭＶは、ブロックを緊急プールに移動させ、バッファマップ上でそれを消失しているものとしてマーク付けする（それによって他のスレッドがそれを選択することができる）。
【００７３】
統計エンジン
−ＢＭＶは、Ｔ２秒ごとに、最後のＴ４秒の間にインタフェースを通じてダウンロードされるデータの量を合計することによって、インタフェースごとの推定されるネットワークインタフェースの速度を含む統計を計算し、Ｔ４についての典型的な値は、１、１０、２０、３０秒である。それを可能にするために、図の［プログレッシブダウンローディングＡＰＩ］に示されるように、どのスレッドが統計エンジンにおいてどのブロックをダウンロードしたかを記録する。
【００７４】
スレッド失敗：ビデオをダウンロードしている間に、スレッドのうちの１つまたは複数が接続を損失する可能性があり、例えば、セルラおよびコーヒーショップから出るＳｔａｒｂｕｃｋｓのＷｉＦｉに接続されたユーザを考える。そのポイントでは、ＳｔａｒｂｕｃｋｓのＷｉＦｉネットワークを損失することがあるが、セルラネットワーク（なお、屋外である）はより強くなることがある。１つの実施形態では、ＢＭＶは、１つまたは複数のスレッドが失敗するときにビデオをダウンロードすることを停止せず、残りのブロックを選択する他のスレッドを通じてダウンロードを継続する。よって部分的なネットワーク損失は、ユーザ経験を中断しない。
【００７５】
他のユーザは、スケジューリングについて選択し、接続の合計速度を達成する代わりに、他のユーザ定義基準を達成するようにアルゴリズムを容易に修正することができ、例えば：
−データプランの上限設定：ユーザは、データプラン（セルラ接続）を制限までのみ使用することを望み、次いで、通知されることを指定することができる。ＢＭＶは、統計エンジンにおいて各スレッドによってダウンロードされたデータの量を記録し、上限に達すると、それは、ユーザに通知し、セルラスレッドを停止する。
−データプランの節約：ＢＭＶはまた、緊急ウインドウ内、または再生時間からの時間Ｗ１＜Ｗ内のいずれかであるブロックのみをセルラスレッドがダウンロードすることを可能にすることによって、データプランの節約を実現することができ、すなわち、ＢＭＶは、Ｗｉ−Ｆｉ接続からのセグメントを優先的にダウンロードし、Ｗｉ−Ｆｉ接続がＷ１内で必要なセグメントをダウンロードすることを管理しなくなった場合のみセグメントをセルラ接続に割り当てる。
−バッテリ。同様に、ＢＭＶは、バッテリレベルを入力として受け、バッテリが特定の閾値を上回る限り、制限された数のインタフェース上でのみスレッドのダウンロードをアクティブにする（ユーザに通知する）。
−通常ダウンロード：緊急プールをこれ以上維持しない。全てのブロックは、ブロックプールに配置され、連続して選択され、スレッドによってダウンロードされる。全てのブロックがダウンロードされ、またはダウンロード中である場合、失敗したスレッドに起因して不完全なダウンロードを回避するために、ダウンロードしているスレッドの推定されるダウンロード時間Ｄを上回ってダウンロードしていたブロックをスレッドが選択することを可能にする。
−スレッドは、ダウンロードされたブロックをキャッシュシステムの代わりに記憶システムに提供する。
【００７６】
ＢＭＶのキャッシュシステムは、１つの実施形態では、カスタムデータベースおよびファイルシステムを組み合わせることによって、複数のスレッドによって同時にダウンロードされたブロックを効率的に記憶およびクエリすることをサポートするように設計される。小さいファイルの記憶。この実施形態では、基本的な着想は、同一のファイルの内部にビデオの全てのブロックを収集する代わりに、各ブロックがファイルシステムにおける異なる小さいファイルに記憶されることである。結果として、複数のスレッドは、相互に妨害することなくファイルシステムに同時に書き込む（またはそれから読み出す）ことができる（それらが同一のファイルへの書き込みを試みる場合に行うように）。各スレッドは、ブロックに関するメタデータを保持するカスタムデータベーステーブルに行、例えば、ビデオ識別子、開始バイト、終了バイト、長さ、アクセス時間とともにブロックのデータを含む小さいファイルへのポインタを最初に挿入し、それは次いで、ブロックをファイルシステムに記憶することを進行させる。このアプローチは、ビデオについての単一のファイルを保持する従来のアプローチと比較してより高速な書き込み時間を提供する。これは、後者のアプローチでは、ブロックを書き込むことは、ファイルへのランダムな書き込みを伴い、それは、探索が含まれることになるので著しく長い時間を要するからである。プログレッシブモードをサポートするために、キャッシュシステムはまた、図の［プログレッシブダウンローディングＡＰＩ］に示されるように、キャッシュにおいて利用可能なメタデータおよびビデオのデータ範囲をＨＴＴＰプロキシサーバによって取り出すことができるクエリインタフェースを提供する。
【００７７】
退去（ｅｖｉｃｔｉｏｎ）ポリシ：制約された記憶空間を有するデバイスをサポートするために、キャッシュシステムは、構成可能な最大サイズ、例えば、５０メガバイト、所与の時に記憶することができるデータの最大量を有してもよい。スレッドが新たなブロックをキャッシュに書き込むことになり、キャッシュの空きが不足しているとき、新たな１つのための空きを作るためにいくつかの記憶されたデータを退去させる必要がある。キャッシュシステムの重要な設計選択は、その退去ポリシである。ＢＭＶキャッシュシステムは、その目標が円滑な再生をサポートするためにほとんどの関連するデータを常に保持することである新規なキャッシュ退去ポリシを含む。特に、キャッシュがデータを退去させる必要があるとき、１つの実施形態では、それは最初に：
−直近にアクセスされたビデオから始まって、現在再生しているビデオ以外のビデオの記憶されたブロックを退去させる（現在再生しているビデオは直近にアクセスされたものである）。
−そのようなデータが存在しない場合、それは、現在の再生時間の前に再生しているビデオのデータを退去させる。ダウンロードしているときの該当のスライドウインドウのサイズは、キャッシュが記憶することができるよりも多くのデータをダウンロードしないことを保証する。しかしながら、ユーザが探索の間にジャンプする場合、該当のポリシがわずかに変化する。現在の再生時間とは別に、ジャンプの前に最後に再生された時間をも記録する。ジャンプの前の最後に再生された時間の前である最初のブロックを退去させ、それらが消耗しているとき、現在の再生時間の前に、かつ最後に再生された時間からできるだけ離れたブロックを退去させる。このようにして、ユーザが戻ることを決めるケースについて、ユーザが見ることを停止したものに近いできるだけ長いブロックについて維持する。
【００７８】
記憶システム：レギュラーダウンローディングをサポートするために、ＢＭＶは、ダウンロードされたビデオデータをファイルシステムに永続的に記憶することを担う記憶システムを有する。１つの実施形態では、記憶システムの設計および実装は、記憶システムが退去ポリシを有さないこと除いてキャッシュシステムと同様である。記憶システムの主なカスタム機能は、複数のスレッドからの効率的な書き込みをサポートすることである。ビデオが完全にダウンロードされる場合、記憶システムは、ビデオの全てのデータを内蔵型再生可能ビデオファイルにエクスポートすることを可能にする。
【００７９】
ＨＴＴＰプロキシサーバ：プログレッシブダウンローディングをサポートするために、ＢＭＶは、ＢＭＶの支援を要求したビデオプレイヤにダウンロードモジュールによってダウンロードされたビデオブロックを供給する、ＨＴＴＰプロキシサーバを提供する。１つの実施形態では、サーバは、ＨＴＴＰ１．１プロトコルに従って、ビデオプレイヤのＨＴＴＰ範囲要求に応答する。１つの実施形態では、サーバは、複数の要求に同時に対処することが可能である。１つの実施形態では、ＨＴＴＰプロキシサーバは、現在の再生時間を推測し、ダウンロードモジュールに通知するためにビデオプレイヤのＨＴＴＰ範囲要求を使用する。
【００８０】
ＢＭＶのコンポーネントはともに作動し、プログレッシブダウンローディングインスタンスの例を考えると、ビデオプレイヤはＡＰＩと通信し、プログレッシブモードでＢＭＶを起動させ、ＨＴＴＰプロキシサーバは、起動し、ローカルアドレス、例えば、ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ／またはｈｔｔｐ：／／１２７．０．０．１をビデオプレイヤに提供する。ダウンロードモジュールは、ブロックをダウンロードし、それらをキャッシュシステムに記憶する。ビデオプレイヤが再生のためにメタデータまたはビデオの範囲をフェッチするためにローカルアドレスを示すとき、ＨＴＴＰプロキシサーバは、要求されたデータについてキャッシュシステムをクエリし、ビデオプレイヤに応答する。この実施形態はまた、図９に示される。
【００８１】
ＢＭＶは、ＨＬＳビデオのダウンロード（ライブストリーミング）をサポートする。ＨＬＳビデオは、単一のファイルではないが、代わりに、．ｍ３ｕ８インデックスファイルおよび．ｔｓセグメントファイルを含む、ファイルの集合から構成される。プログレッシブダウンローディング（ライブストリーミングイベントのケースにおける）およびレギュラーダウンローディング（ＨＬＳフォーマットに記憶された事前に記録されたイベントのケースにおける）の両方においてＨＬＳビデオをダウンロードするためにＢＭＶを使用することができる。１つの実施形態では、ステップは、通常のビデオについてのステップと非常に類似している（図１１も参照）。主な差異は、インデックス（．ｍ３ｕ８）ファイルを最初に取得し、次いで、ＨＬＳビデオに追加される最後のセグメントを学習するためにインデックスファイルをサーバからリフレッシュすることである。特に、この実施形態では：
−ビデオプレイヤは、（ｉ）ｓｅｔＮｅｔｗｏｒｋｓ（ネットワーク）などの関数を呼び出すことによってダウンロードするためにどのネットワークを使用するかをＢＭＶに通知し、（ｉｉ）プログレッシブダウンロード（ｖｉｄｅｏＵｒｌ）と命名する関数を呼び出すことによってダウンロードを開始することをＢＭＶに通知し、（ｉｉｉ）ｓｅｔＤａｔａＳｏｕｒｃｅ（）と命名する関数を呼び出すことによってプレイヤのデータの送信元をＨＴＴＰプロキシサーバに示す。
−最初に、ｖｉｄｅｏＵＲＬは、インデックス（．ｍ３ｕ８）ファイルへのＵＲＬである。インデックスファイルは、セグメントについてのＵＲＬへのポインタを含む。ライブストリーミングでは、インデックスファイルは、より多くのビデオセグメントがオンラインで追加されるにつれて更新され、したがって、ＢＭＶは、最新のバージョンのインデックスファイルを定期的にダウンロードする。ＢＭＶは、インデックスファイルをダウンロードおよびリフレッシュするためにＷｉＦｉインタフェースを一貫して使用する（デバイスがセルラ専用モードで動作していない限り）。
−インデックスファイルをダウンロードするために使用されるＵＲＬは、それらが典型的にはインデックスファイルと同一のサーバに記憶されるので、セグメントをダウンロードするために度々再使用されてもよい。ＢＭＶは、解決されたＵＲＬのリソース部分を置き換えることによって、すなわち、インデックスファイル名を適切なセグメントファイル名と置き換え、次いで、結果として生じるＵＲＬが有効であるかをチェックすることによって、セグメントＵＲＬを作成するためにこれを利用する。ＢＭＶは、残りの必要とされるＵＲＬを識別するためにＵＲＩリゾルバを採用する。
−各セグメントは、以前のビデオと同一の方法で取り扱われる。特に、セグメントは、バッファマップ、ブロックプールおよび緊急プールに追加されるブロックに分割される。スレッドは、異なるインタフェースを通じてセグメントブロックをダウンロードする。セグメントがキャッシュに完全にダウンロードされると、それは、要求されるといつでも、ＨＴＴＰプロキシサーバに、次いで、ビデオプレイヤにフェッチされる準備がされる。
−セグメントは、現在の再生時間により近い１つから始まって（前の方向での）、１つずつダウンロードされる。インデックスファイルをリフレッシュするとき、ＢＭＶは新たなセグメントを認識するので、それは、それらのダウンロードを連続してスケジュールする。
【００８２】
ＢＭＶはまた、適応的（品質）ストリーミングをサポートする。このケースでは、ＨＬＳビデオの複数のストリームを有し、その各々が異なる品質のビデオに対応する。各ストリームはそれ自身のセグメントを有する。ＨＴＴＰプロキシサーバがビデオデータをどの程度高速に供給するかに応じて、ビデオプレイヤはその選択された品質を適合させることができ、すなわち、供給するためのより高いまたはより低い品質のビデオを選択することができる。ＢＭＶは、１つの実施形態では、ＨＴＴＰプロキシサーバに、ビデオプレイヤの現在選択されているストリームをＨＬＳエンジンに通知させることによって適応的ストリーミングをサポートする。通知は、黙示的に行うことができ、例えば、ビデオプレイヤは、ＨＴＴＰプロキシからの特定の品質のセグメントを要求し、プロキシは、これを学習し、次いで、要求された品質のセグメントを取得することをＨＬＳエンジンに通知する。実施形態では、ＨＬＳエンジンは、対応するストリームからの要求された品質のセグメントのダウンロードを開始する。レギュラーダウンローディングについて、ＢＭＶは、１つの実施形態では、前のと同様の手順を使用して、ＨＬＳビデオを取得するためにＨＬＳエンジンを使用することができる。差異は以下を含む：１つ目に、ＨＬＳエンジンは、インデックスファイル（．ｍ３ｕ８）を、このファイルがなおも静的であり、１回のみフェッチされる必要があるので定期的にフェッチする必要がなく、２つ目に、ストリームの品質は、それがダウンロードを開始するとき、すなわち、図１２に示されるように、通常のダウンロード（ｖｉｄｅｏＵｒｌ、ストリーム品質）を呼び出すことによって指定される必要がある。
【００８３】
ＶｉｄｅｏＢｅｅ：ＢＭＶプログレッシブおよびレギュラーダウンローディングは、ＶｉｄｅｏＢｅｅ［１１］と呼ばれる、ａｎｄｒｏｉｄアプリケーションに実装およびテストされている。ＶｉｄｅｏＢｅｅからのスクリーンショットが図１３に提示される。ＶｉｄｅｏＢｅｅは、学術界および産業の両方によって非常に受け入れられている［１５〜２０］。単一の電話のみが利用可能であるとき、ＶｉｄｅｏＢｅｅは、セルラのみ、ＷｉＦｉのみ、またはセルラおよびＷｉＦｉの両方（ソロモード）を使用してビデオをダウンロードすることができる。第２の電話が近くにある場合、ＶｉｄｅｏＢｅｅは、Ｂｌｕｅｔｏｏｔｈを通じて２つのデバイスを接続し（グループモード）、第１の電話のダウンロードレートを増大させるために第２の電話のインターネット接続（セルラ、ＷｉＦｉ、またはデュアル）を使用する（ベータテストの目的で、グループサイズを現在２に制限している）。両方のケースでは、主要なデバイスは、全ての接続の合計まで加速化したダウンロードを享受する。図９は、実験室においてＶｉｄｅｏＢｅｅのテストされた性能を示す。ＶｉｄｅｏＢｅｅは、単一のデバイスがそのＷｉＦｉおよびセルラ接続の合計速度においてダウンロードすることを可能にし、２つのデバイスのグループがそれらの２つのセルラ接続の合計速度においてダウンロードすることを可能にしている。
【００８４】
ベータテスタのフィードバック：ＶｉｄｅｏＢｅｅは、アクセスコードが与えられるときのみユーザがＶｉｄｅｏＢｅｅを実行するときに、非常に成功したクローズドベータテスト期間を得ている。それは３０００のユーザを魅了し、それらは該当の技術の早くからの適合者であり、肯定的なフィードバックを与えることを非常に熱望している。
【００８５】
実性能：２０１３年１２月の下旬、クローズドベータ期間を完了し、それをＧｏｏｇｌｅ  Ｐｌａｙ  ｓｔｏｒｅ［１１］からダウンロードすることによって誰もがＶｉｄｅｏＢｅｅを試すことができるオープンベータを開始している。これまでに、一意なアプリケーションユーザは１５０００に達し、１週間ごとに平均すると３０００の新規ユーザである。また、何千ものユーザによって使用されるときにＶｉｄｅｏＢｅｅ性能をそのままで収集するために、モニタモジュールを開発し、それを業界最高レベルＦｌｕｒｒｙ分析エンジン［２１］に統合している。図１０〜１２は、ソロモード（ＷｉＦｉおよびセルラの両方による）ならびにグループモードをそれぞれ使用するときにユーザがどの程度高速にダウンロードすることができるかを示す。特に、該当の収集された統計から、ソロモードは、ダウンロードの速度を１．５倍の平均増大率および０．５メガビット／秒の平均増大率（グラフには示されない）を有する最大で２．６倍に増大させることができ、グループモードは、ダウンロードの速度を１．４倍の平均増大率および０．５メガビット／秒の平均増大率（グラフには示されない）を有する最大で６．１倍に増大させることができる。それらの実性能は、該当の技術を使用することによって得られる性能を立証する。正確な規模は、利用可能な接続の帯域幅に依存するが、ＶｉｄｅｏＢｅｅの増大効果は、実際には付加的なものである。
【００８６】
アップロード：１つの実施形態におけるアップロードのために使用される技術は、ダウンロードのために使用される技術と対称的である。方法の同様のステップを繰り返すことなく、主な差異は、以下を含む。
【００８７】
サーバ：１つの実施形態では、ＢＭＶサーバ（それらのいくつかを維持することができる）または第三者サーバ（例えば、Ｆａｃｅｂｏｏｋサーバ）にアップロードすることができる。サーバは、アップロードされたブロックを単純に収集し、それらを範囲の順序で単一のファイルに結合するＢＭＶソフトウェアを実行する。１つの実施形態では、それを行うために、ブロックがアップロードされると、サーバは、指定されたメインサーバ上の単一のファイルにおける全てのアップロードされたブロックを収集するために相互に通信する。ファイルが結合されると、ＢＭＶサーバを使用している場合、１つの実施形態では、メインＢＭＶサーバは次いで、ユーザがアップロードされることを要求した位置（例えば、Ｙｏｕｔｕｂｅまたはパーソナルコンピュータ）にビデオを転送する。別の実施形態として、サーバは、それらが消失した全てのブロックを交換し、よって、それらは、アップロードされたビデオを全て再構築する。
【００８８】
ソロモード：１つの実施形態では、ソロモードにおいて、ＢＭＶは、複数のインタフェースおよびスレッドを確立し、ここで各インタフェースは、ＢＭＶサーバ（検索なしでアプリケーションの内部で直接提供される）または第三者サーバ（協働する第三者によって再度提供しており、または前と同一の技術で取得される）のうちの１つのＵＲＬに接続される。アップロードでは、レギュラーアップローディングモードをサポートする。１つの実施形態では、ＢＭＶは、ビデオをブロックに分割し、スレッドは、ブロックを選択し、それをサーバに１つずつアップロードし、バッファマップは、どのブロックがアップロードされたか、どのブロックが消失しているかを記録する。
【００８９】
本明細書で使用されるように、用語「約（ａｂｏｕｔ）」は、言及した数のプラスまたはマイナス１０％を指す。
【００９０】
本明細書で説明されたものに加え、発明の種々の変更例が上述した説明から当業者にとって明らかである。そのような変更例はまた、添付の特許請求の範囲内にあることが意図される。本出願で示された各参考文献は、その全体を参照することによって本明細書に組み込まれる。
【００９１】
本発明の好ましい実施形態が示され、および説明されてきたが、添付の特許請求の範囲を逸脱せずに修正例がそれらになされてもよいことが当業者にとって容易に明らかである。したがって、本発明の範囲は、以下の特許請求の範囲によってのみ限定される。特許請求の範囲に記載される参照符号は例示的であり、特許庁による検討を容易にするためのみのものであり、決して限定するものではない。いくつかの実施形態では、本特許出願で提示された図面は、角度、大きさの比率などを含む、縮尺通りに描かれている。いくつかの実施形態では、図面は単なる表現であり、特許請求の範囲が図面の大きさによって限定されない。いくつかの実施形態では、フレーズ「備える（ｃｏｍｐｒｉｓｉｎｇ）」を使用して本明細書で説明された発明の説明は、「から構成される（ｃｏｎｓｉｓｔｉｎｇ  ｏｆ）」として説明されてよいも実施形態を含み、それによって、フレーズ「から構成される」を使用した本発明の１つまたは複数の実施形態を特許請求する記載要件が満たされる。
【００９２】
参考文献
［１］Ｃｉｓｃｏ，「Ｃｉｓｃｏ  Ｖｉｒｔｕａｌ  Ｎｅｔｗｏｒｋｉｎｇ  Ｉｎｄｅｘ：Ｇｌｏｂａｌ  Ｍｏｂｉｌｅ  Ｄａｔａ  Ｔｒａｆｆｉｃ  Ｆｏｒｅｃａｓｔ  Ｕｐｄａｔｅ，２０１２−２０１７，」ｈｔｔｐ：／／ｗｗｗ．ｃｉｓｃｏ．ｃｏｍ／ｅｎ／ＵＳ／ｓｏｌｕｔｉｏｎｓ／ｃｏｌｌａｔｅｒａｌ／  ｎｓ３４１／ｎｓ５２５／ｎｓ５３７／ｎｓ７０５／ｎｓ８２７／ｗｈｉｔｅ＿ｐａｐｅｒ＿ｃ１１−５２０８６２．ｈｔｍｌ（２０１４年１月３０日に参照）。
［２］ＣＮｅｔ  Ｎｅｗｓ，「Ｃａｎ  Ａｐｐｌｅ’ｓ  Ａｐｐ  Ｓｔｏｒｅ  ｍａｉｎｔａｉｎ  ｉｔｓ  ｌｅａｄ  ｏｖｅｒ  Ｇｏｏｇｌｅ  Ｐｌａｙ？，」ｈｔｔｐ：／／ｎｅｗｓ．ｃｎｅｔ．ｃｏｍ／８３０１−１０３５＿３−５７５２１２５２−９４／ｃａｎ−ａｐｐｌｅｓ−ａｐｐ−ｓｔｏｒｅ−ｍａｉｎｔａｉｎ−ｉｔｓ−ｌｅａｄ−ｏｖｅｒ−ｇｏｏｇｌｅ−ｐｌａｙ（２０１４年１月３０日に参照）。
［３］ＡＴ＆Ｔ  Ｎｅｗｓ  Ｒｅｌｅａｓｅ，「ＡＴ＆Ｔ  ｔｏ  Ｉｎｖｅｓｔ  ＄１４  Ｂｉｌｌｉｏｎ  ｔｏ  Ｓｉｇｎｉｆｉｃａｎｔｌｙ  Ｅｘｐａｎｄ  Ｗｉｒｅｌｅｓｓ  ａｎｄ  Ｗｉｒｅｌｉｎｅ  Ｂｒｏａｄｂａｎｄ  Ｎｅｔｗｏｒｋｓ，Ｓｕｐｐｏｒｔ  Ｆｕｔｕｒｅ  ＩＰ  Ｄａｔａ  Ｇｒｏｗｔｈ  ａｎｄ  Ｎｅｗ  Ｓｅｒｖｉｃｅｓ」，ｈｔｔｐ：／／ｗｗｗ．ａｔｔ．ｃｏｍ／ｇｅｎ／ｐｒｅｓｓ−ｒｏｏｍ？ｐｉｄ＝２３５０６＆ｃｄｖｎ＝ｎｅｗｓ＆ｎｅｗｓａｒｔｉｃｌｅｉｄ＝３５６６１（２０１４年１月３０日に参照）。
［４］Ｎｅｔｆｌｉｘ，「Ｉｎｔｅｒｎｅｔ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｐｅｅｄ  Ｒｅｃｏｍｍｅｎｄａｔｉｏｎｓ，」ｈｔｔｐｓ：／／ｓｕｐｐｏｒｔ．ｎｅｔｆｌｉｘ．ｃｏｍ／ｅｎ／ｎｏｄｅ／３０６（２０１４年１月３０日に参照）。
［５］ＹｏｕＴｕｂｅ，「Ａｄｖａｎｃｅｄ  ｅｎｃｏｄｉｎｇ  ｓｅｔｔｉｎｇｓ，」ｈｔｔｐｓ：／／ｓｕｐｐｏｒｔ．ｇｏｏｇｌｅ．ｃｏｍ／ｙｏｕｔｕｂｅ／ａｎｓｗｅｒ／１７２２１７１？ｈｌ＝ｅｎ（２０１４年１月３０日に参照）。
［６］Ａｋａｍａｉ，「Ｔｈｅ  ｓｔａｔｅ  ｏｆ  ｔｈｅ  ｉｎｔｅｒｎｅｔ，」ｖｏｌｕｍｅ  ４，Ｎｏ．４，４ｔｈ  ｑｕａｒｔｅｒ  ２０１２  ｒｅｐｏｒｔ。
［７］Ｌ．Ｋｅｌｌｅｒ，Ａ．Ｌｅ，Ｂ．Ｃｉｃｉ，Ｈ．Ｓｅｆｅｒｏｇｌｕ，Ｃ．Ｆｒａｇｏｕｌｉ，Ａ．Ｍａｒｋｏｐｏｕｌｏｕ，「Ｍｉｃｒｏｃａｓｔ：Ｃｏｏｐｅｒａｔｉｖｅ  Ｖｉｄｅｏ  Ｓｔｒｅａｍｉｎｇ  ｏｎ  Ｓｍａｒｔｐｈｏｎｅｓ，」ｉｎ  ＡＣＭ  ＭｏｂｉＳｙｓ  ２０１２，Ｌａｋｅ  Ｗｏｏｄ，ＵＫ，Ｊｕｎｅ  ２０１２。
Ｆｉｒｓｔ  ｐｌａｃｅ  ｉｎ  ＡＭＡＳＥ（ｍｏｂｉｌｅ  ａｐｐｓ）  ｃｏｍｐｅｔｉｔｉｏｎ，ＵＣＩ，Ｊｕｎｅ  ２０１２。
Ｔｏｐ  ５  ｐａｐｅｒｓ  ｉｎ  ＡＣＭ  Ｍｏｂｉｓｙｓ  ２０１２，Ｊｕｎｅ  ２０１２。
Ｍｉｃｒｏｃａｓｔ  ｒｅｓｅａｒｃｈ  ｐｒｏｊｅｃｔ：ｈｔｔｐ：／／ｍｉｃｒｏｃａｓｔ．ｃａｌｉｔ２．ｕｃｉ．ｅｄｕ
［８］Ｎａｔｉｏｎａｌ  Ｓｃｉｅｎｃｅ  Ｆｏｕｎｄａｔｉｏｎ  ｌ−Ｃｏｒｐｓ  Ａｗａｒｄ  １２５８８６６，「ＭｉｃｒｏＣａｓｔ：Ｃｏｏｐｅｒａｔｉｖｅ  Ｎｅｔｗｏｒｋｉｎｇ  ｏｆ  Ｍｏｂｉｌｅ  Ｄｅｖｉｃｅｓ，」Ｓｅｐｔｅｍｂｅｒ  ２０１２。
［９］ＡＭＡＳＥ  Ｃｏｍｐｅｔｉｔｉｏｎ（「Ａ  Ｍｏｂｉｌｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｓｈｏｗｃａｓｅ  Ｅｖｅｎｔ」），Ｓｃｈｏｏｌ  ｏｆ  ＩＣＳ，ＵＣ  Ｉｒｖｉｎｅ，Ｊｕｎｅ  ２０１２，ｈｔｔｐ：／／ｗｗｗ．ｉｃｓ．ｕｃｉ．ｅｄｕ／ｃｏｍｍｕｎｉｔｙ／ｅｖｅｎｔｓ／ａｍａｓｅ／ｉｎｄｅｘ．ｐｈｐ（２０１４年１月３０日に参照）。
［１０］Ｎａｔｉｏｎａｌ  Ｓｃｉｅｎｃｅ  Ｆｏｕｎｄａｔｉｏｎ  ＳＢＩＲ  Ｐｈａｓｅ  Ｉ  Ａｗａｒｄ  １３１５１０６，「Ｍｉｃｒｏｃａｓｔ：Ｃｏｏｐｅｒａｔｉｖｅ  Ｖｉｄｅｏ  Ｄｅｌｉｖｅｒｙ  ｔｏ  Ｍｏｂｉｌｅ  Ｄｅｖｉｃｅｓ，」Ｊｕｎｅ  ２０１３。
［１１］Ａｎｄｒｏｉｄ  Ａｐｐ  ＶｉｄｅｏＢｅｅｈｔｔｐｓ：／／ｐｌａｙ．ｇｏｏｇｌｅ．ｃｏｍ／ｓｔｏｒｅ／ａｐｐｓ／ｄｅｔａｉｌｓ？ｉｄ＝ｃｏｍ．ｓｈｏｅｌａｃｅｗｉｒｅｌｅｓｓ．ａｐｐ．ｖｉｄｅｏｂｅｅ（２０１４年１月３０日に参照）。
［１２］Ｂｕｓｉｎｅｓｓ  Ｉｎｓｉｄｅｒ，「Ｈｅｒｅ’ｓ  Ｗｈａｔ  Ｐｅｏｐｌｅ  Ａｒｅ  Ａｃｔｕａｌｌｙ  Ｗａｔｃｈｉｎｇ  Ｏｎ  Ｔｈｅｉｒ  Ｓｍａｒｔｐｈｏｎｅｓ  Ａｎｄ  Ｔａｂｌｅｔｓ，Ａｓ  ＴＶ  Ｇｏｅｓ  Ｍｏｂｉｌｅ，」ｈｔｔｐ：／／ｗｗｗ．ｂｕｓｉｎｅｓｓｉｎｓｉｄｅｒ．ｃｏｍ／ｍｏｂｉｌｅ−ｖｉｄｅｏ−ｒｅｐｏｒｔ−２０１３−１２（２０１４年１月３０日に参照）
［１３］Ｃｏｎｖｉｖａ，「Ｖｉｅｗｅｒ  Ｅｘｐｅｒｉｅｎｃｅ  Ｒｅｐｏｒｔ，２０１２」Ｆｅｂ  ２０１３。
［１４］Ｅｎｇａｄｇｅｔ，「ＹｏｕＴｕｂｅ  Ａｎｄｒｏｉｄ  ａｐｐ  ｕｐｄａｔｅ  ｂｒｉｎｇｓ  ＨＤ  ｖｉｄｅｏ  ｓｔｒｅａｍｉｎｇ  ｔｏ  ｃａｐａｂｌｅ  ２．２＋  ｄｅｖｉｃｅｓ，」ｈｔｔｐ：／／ｗｗｗ．ｅｎｇａｄｇｅｔ．ｃｏｍ／２０１２／０３／０２／ｙｏｕｔｕｂｅ−ａｎｄｒｏｉｄ−ａｐｐ−ｕｐｄａｔｅ−ｂｒｉｎｇｓ−ｈｄ−ｖｉｄｅｏ−ｓｔｒｅａｍｉｎｇ−ｔｏ−ｃａｐａｂｌｅ／（２０１４年１月３０日に参照）。
［１５］ＣＴＩＡ，「ＣＴＩＡ  Ａｎｎｏｕｎｃｅｓ  Ｓｔａｒｔｕｐ  Ｔｈｒｏｗ  Ｄｏｗｎ  Ｗｉｎｎｅｒｓ  ａｔ  ＣＴＩＡ  ２０１３，」ｈｔｔｐ：／／ｗｗｗ．ｃｔｉａ．ｏｒｇ／ｒｅｓｏｕｒｃｅ−ｌｉｂｒａｒｙ／ｐｒｅｓｓ−ｒｅｌｅａｓｅｓ／ａｒｃｈｉｖｅ／ｃｔｉａ−ｓｔａｒｔｕｐ−ｔｈｒｏｗ−ｄｏｗｎ−ｗｉｎｎｅｒｓ−ｃｔｉａ−２０１３（２０１４年１月３０日に参照）。
［１６］ＶｉｄｅｏＢｅｅ−Ｓｅｃｏｎｄ  Ｂｅｓｔ  Ｍｏｂｉｌｅ  Ａｐｐ  Ａｗａｒｄ，ＡＣＭ  Ｍｏｂｉｃｏｍ  Ｍｏｂｉｌｅ  Ａｐｐ  Ｃｏｍｐｅｔｉｔｉｏｎ，２０１３  ｈｔｔｐ：／／ｗｗｗ．ｓｉｇｍｏｂｉｌｅ．ｏｒｇ／ｍｏｂｉｃｏｍ／２０１３／ａｐｐ＿ｗｉｎｎｅｒｓ．ｈｔｍｌ（２０１４年１月３０日に参照）。
［１７］ＸＤＡ  Ｄｅｖｅｌｏｐｅｒｓ，「Ｇｅｔ  Ｙｏｕｒ  Ｖｉｄｅｏｓ  Ｆａｓｔｅｒ  ｗｉｔｈ  ＶｉｄｅｏＢｅｅ  ｆｏｒ  Ａｎｄｒｏｉｄ，」ｈｔｔｐ：／／ｗｗｗ．ｘｄａ−ｄｅｖｅｌｏｐｅｒｓ．ｃｏｍ／ａｎｄｒｏｉｄ／ｇｅｔ−ｙｏｕｒ−ｖｉｄｅｏｓ−ｆａｓｔｅｒ−ｗｉｔｈ−ｖｉｄｅｏｂｅｅ−ｆｏｒ−ａｎｄｒｏｉｄ／（２０１４年１月３０日に参照）。
［１８］Ｍｏｂｉｌｅ  Ｔｉｍｅ，「ＶｉｄｅｏＢｅｅ：ａｐｐ  ｃｒｉａ  ｓｔｒｅａｍｉｎｇ  「ｃｏｏｐｅｒａｔｉｖｏ」ｅｎｔｒｅ  ｃｅｌｕｌａｒｅｓ，」ｈｔｔｐ：／／ｗｗｗ．ｍｏｂｉｌｅｔｉｍｅ．ｃｏｍ．ｂｒ／１９／１２／２０１３／ｖｉｄｅｏｂｅｅ−ａｐｐ−ｃｒｉａ−ｓｔｒｅａｍｉｎｇ−ｃｏｏｐｅｒａｔｉｖｏ−ｅｎｔｒｅ−ｃｅｌｕｌａｒｅｓ／３６４８２０／ｎｅｗｓ．ａｓｐｘ（２０１４年１月３０日に参照）。
［１９］Ａｎｄｒｏｉｄ  Ａｙｕｄａ，「Ｄｅｓｃａｒｇａ  ｙ  ｃｏｍｐａｒｔｅ  ｖｉｄｅｏｓ  ｒａｐｉｄａｍｅｎｔｅ  ｇｒａｃｉａｓ  ａ  ＶｉｄｅｏＢｅｅ  ｐａｒａ  Ａｎｄｒｏｉｄ，」ｈｔｔｐ：／／ａｎｄｒｏｉｄａｙｕｄａ．ｃｏｍ／２０１３／１  １／０９／ｄｅｓｃａｒｇａ−ｙ−ｃｏｍｐａｒｔｅ−ｖｉｄｅｏｓ−ｒａｐｉｄａｍｅｎｔｅ−ｇｒａｃｉａｓ−ｖｉｄｅｏｂｅｅ−ｐａｒａ−ａｎｄｒｏｉｄ／（２０１４年１月３０日に参照）。
［２０］Ａｎｄｒｏｉｄ  Ｐｉｐｅ，「Ｖｉｄｅｏ  Ｓｔｒｅａｍｉｎｇ  ａｔ  Ｉｔｓ  Ｂｅｓｔ  ｗｉｔｈ  ＶｉｄｅｏＢｅｅ  ｆｏｒ  Ａｎｄｒｏｉｄ，」ｈｔｔｐ：／／ｗｗｗ．ａｎｄｒｏｉｄｐｉｐｅ  ｏｍ／ｖｉｄｅｏ−ｓｔｒｅａｍｉｎｇ−ａｔ−ｉｔｓ−ｂｅｓｔ−ｗｉｔｈ−ｖｉｄｅｏｂｅｅ−ｆｏｒ−ａ（２０１４年１月３０日に参照）。
［２１］Ｆｌｕｒｒｙ  Ａｎａｌｙｔｉｃｓ  ｈｔｔｐ：／／ｗｗｗ．ｆｌｕｒｒｙ．ｃｏｍ／ｆｌｕｒｒｙ−ａｎａｌｙｔｉｃｓ．ｈｔｍｌ（２０１４年１月３０日に参照）．
［２２］ＩＥＴＦ  Ｉｎｔｅｒｎｅｔ  Ｄｒａｆｔ，「ＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇ，」ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／  ｄｒａｆｔ−ｐａｎｔｏｓ−ｈｔｔｐ−ｌｉｖｅ−ｓｔｒｅａｍｉｎｇ−１２（２０１４年１月３０日に参照）。
［２３］Ａｐｐｌｅ  ｉＯＳ，「Ｕｓｉｎｇ  ＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇ，」ｈｔｔｐｓ：／／ｄｅｖｅｌｏｐｅｒ．ａｐｐｌｅ．ｃｏｍ／ｌｉｂｒａｒｙ／ｍａｃ／ｄｏｃｕｍｅｎｔａｔｉｏｎ／ｎｅｔｗｏｒｋｉｎｇｉｎｔｅｒｎｅｔ／ｏｎｃｅｐｔｕａｌ／ｓｔｒｅａｍｉｎｇｍｅｄｉａｇｕｉｄｅ／ＵｓｉｎｇＨＴＴＰ  ＬｉｖｅＳｔｒｅａｍｉｎｇ／ＵｓｉｎｇＨＴＴＰＬｉｖｅＳｔｒｅａｍｉｎｇ．ｈｔｍｌ（２０１４年１月３０日に参照）。
［２４］Ｇｏｏｇｌｅ  Ａｎｄｒｏｉｄ，「Ｓｕｐｐｏｒｔｅｄ  Ｍｅｄｉａ  Ｆｏｒｍａｔ，」ｈｔｔｐ：／／ｄｅｖｅｌｏｐｅｒ．ａｎｄｒｏｉｄ．ｃｏｍ  ／ｇｕｉｄｅ／ａｐｐｅｎｄｉｘ／ｍｅｄｉａ−ｆｏｒｍａｔｓ．ｈｔｍｌ（２０１４年１月３０日に参照）。
［２５］Ｍａｒｋｅｔｉｎｇ  Ｃｈａｒｔｓ，「Ｔｏｐ  １０  Ｍｏｂｉｌｅ−Ｐｈｏｎｅ  Ｗｅｂｓｉｔｅｓ，ｂｙ  ＵＳ  Ｍａｒｋｅｔ  Ｓｈａｒｅ  ｏｆ  Ｖｉｓｉｔｓ，Ａｕｇｕｓｔ  ２０１３，」ｈｔｔｐ：／／ｗｗｗ．ｍａｒｋｅｔｉｎｇｃｈａｒｔｓ．ｃｏｍ／ｗｐ／ｉｎｔｅｒａｃｔｉｖｅ／ｔｏｐ−１０−ｍｏｂｉｌｅ−ｐｈｏｎｅ−ｗｅｂｓｉｔｅｓ−ａｕｇｕｓｔ−２０１３−３６５２３／（２０１４年１月３０日に参照）。
［２６］Ａｎｈ  Ｌｅ  ａｎｄ  Ａｎｄｒｅｗ  Ｓｗｅｒｄｌｏｗ，「Ｂｒｏｗｓｅｒ  Ｅｘｔｅｎｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｌｏｗ  Ｇｒａｐｈ  Ｃｏｎｓｔｒｕｃｔｉｏｎ  Ｆｏｒ  Ｄｅｔｅｒｍｉｎｉｎｇ  Ｓｅｎｓｉｔｉｖｅ  Ｐａｔｈｓ，」米国特許第８，２８６，２５０号，２０１２年１０月９日に許可。
［２７］Ａｎｈ  Ｌｅ  ａｎｄ  Ａｎｄｒｅｗ  Ｓｗｅｒｄｌｏｗ，「Ｂｒｏｗｓｅｒ  Ｅｘｔｅｎｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｌｏｗ  Ｇｒａｐｈ  Ｂａｓｅｄ  Ｔａｉｎｔ  Ｔｒａｃｋｉｎｇ，」米国特許第８，３６５，２９１号，２０１３年１月２９日に許可。
［２８］ＢＧＲ，「ＡＴ＆Ｔ’ｓ  ４Ｇ  ＬＴＥ  ｎｅｔｗｏｒｋ  ｆｏｕｎｄ  ｔｏ  ｂｅ  ｔｈｅ  ｆａｓｔｅｓｔ  ｉｎ  ｔｈｅ  Ｕ．Ｓ，」ｈｔｔｐ：／／ｂｇｒ．ｃｏｍ／２０１３／０６／１７／４ｇ−ｌｔｅ−ｓｐｅｅｄｓ−ａｔｔ−ｖｅｒｉｚｏｎ−ｓｐｒｉｎｔ−ｔ−ｍｏｂｉｌｅ（２０１４年１月３０日に参照）。
［２９］Ａｒｓｔｅｃｈｎｉｃａ，「Ｍｕｌｔｉｐａｔｈ  ＴＣＰ  ｌｅｔｓ  Ｓｉｒｉ  ｓｅａｍｌｅｓｓｌｙ  ｓｗｉｔｃｈ  ｂｅｔｗｅｅｎ  Ｗｉ−Ｆｉ  ａｎｄ  ３Ｇ／ＬＴＥ，」ｈｔｔｐ：／／ｇｏｏ．ｇｌ／ｉＷｃＴｄＴ（２０１４年１月３０日に参照）。
［３０］Ｇｏｏｇｌｅ，Ｖｐｎ−Ｓｅｒｖｉｃｅ  ｄｏｃｕｍｅｎｔａｔｉｏｎ，ｈｔｔｐ：／／ｄｅｖｅｌｏｐｅｒ．ａｎｄｒｏｉｄ．ｃｏｍ／ｒｅｆｅｒｅｎｃｅ／ａｎｄｒｏｉｄ／ｎｅｔ／ＶｐｎＳｅｒｖｉｃｅ．ｈｔｍｌ（２０１４年１月３０日に参照）。
［３１］Ｇｏｏｇｌｅ  Ａｎｄｒｏｉｄ，「Ａｎｄｒｏｉｄ  ２．２  Ｐｌａｔｆｏｒｍ  Ｈｉｇｈｌｉｇｈｔｓ，」Ｍａｙ  ２０１０  ｈｔｔｐ：／／ｄｅｖｅｌｏｐｅｒ．ａｎｄｒｏｉｄ．ｃｏｍ／ａｂｏｕｔ／ｖｅｒｓｉｏｎｓ／ａｎｄｒｏｉｄ−２．２−ｈｉｇｈｌｉｇｈｔｓ．ｈｔｍｌ
［３２］Ｓａｍｓｕｎｇ，「Ｗｈａｔ  ｉｓ  Ｓ  Ｂｅａｍ，ａｎｄ  ｈｏｗ  ｄｏ  Ｉ  ｕｓｅ  ｉｔ？」，ｈｔｔｐ：／／ｗｗｗ．ｓａｍｓｕｎｇ．ｃｏｍ／ｕｓ／ｓｕｐｐｏｒｔ／ｓｕｐｐｏｒｔＯｗｎｅｒｓＨｏｗＴｏＧｕｉｄｅＰｏｐｕｐ．ｄｏ７ｈｏｗ  ｔｏ＿ｇｕｉｄｅ＿ｓｅｑ＝７０４２＆ｐｒｄ＿ｉａ＿ｃｄ＝Ｎ００００００３＆ｍａｐ＿ｓｅｑ＝４８１５７
［３３］Ｊ．Ｋｉｍ，Ｒ．Ｋｈａｌｉｌｉ，Ａ．Ｆｅｌｄｍａｎｎ，Ｙ−Ｃ．Ｃｈｅｎ，Ｄ．Ｔｏｗｓｌｅｙ，「Ｍｕｌｔｉ−Ｓｏｕｒｃｅ  Ｍｕｌｔｉ−Ｐａｔｈ  ＨＴＴＰ（ｍＨＴＴＰ）：Ａ  Ｐｒｏｐｏｓａｌ，」ａｒＸｉｖ．１３１０．２７４８  ｈｔｔｐ：／／ａｒｘｉｖ−ｗｅｂ３．ｌｉｂｒａｒｙ．ｃｏｒｎｅｌｌ．ｅｄｕ／ａｂｓ／１３１０．２７４８ｖ３（２０１４年１月３０日に参照）。
［３４］ＭｕｌｔｉＰａｔｈ  ＴＣＰ  ｈｔｔｐ：／／ｗｗｗ．ｍｕｌｔｉｐａｔｈ−ｔｃｐ．ｏｒｇ／（２０１４年１月３０日に参照）。
［３５］Ｃ．Ｔｓａｏ  ａｎｄ  Ｒ．Ｓｉｖａｋｕｍａｒ，「Ｏｎ  ｅｆｆｅｃｔｉｖｅｌｙ  ｅｘｐｌｏｉｔｉｎｇ  ｍｕｌｔｉｐｌｅ  ｗｉｒｅｌｅｓｓ  ｉｎｔｅｒｆａｃｅｓ  ｉｎ  ｍｏｂｉｌｅ  ｈｏｓｔｓ，」Ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ５ｔｈｌｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｅｍｅｒｇｉｎｇ  Ｎｅｔｗｏｒｋｉｎｇ  Ｅｘｐｅｒｉｍｅｎｔｓ  ａｎｄ  Ｔｅｃｈｎｏｌｏｇｉｅｓ（ＣｏＮＥＸＴ），ｐａｇｅｓ  ３３７−３４８，２００９。
［３６］Ｈ．Ｓｏｒｏｕｓｈ，Ｐ．Ｇｉｌｂｅｒｔ，Ｎ．Ｂａｎｅｒｊｅｅ，Ｍ．Ｄ．Ｃｏｒｎｅｒ，Ｂ．Ｎ．Ｌｅｖｉｎｅ，ａｎｄ  Ｌ．Ｃｏｘ，「Ｓｐｉｄｅｒ：Ｉｍｐｒｏｖｉｎｇ  ｍｏｂｉｌｅ  ｎｅｔｗｏｒｋｉｎｇ  ｗｉｔｈ  ｃｏｎｃｕｒｒｅｎｔ  ｗｉ−ｆｉ  ｃｏｎｎｅｃｔｉｏｎｓ，」ｉｎ  ＳＩＧ−ＣＯＭＭ  Ｃｏｍｐｕｔｅｒ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｒｅｖｉｅｗ，４１（４）：４０２−４０３，Ａｕｇ．２０１１。
［３７］Ｐ．Ｒｏｄｒｉｇｕｅｚ，Ｒ．Ｃｈａｋｒａｖｏｒｔｙ，Ｊ．Ｃｈｅｓｔｅｒｆｉｅｌｄ，Ｉ．Ｐｒａｔｔ，ａｎｄ  Ｓ．Ｂａｎｅｒｊｅｅ，「ＭＡＲ：ａ  ｃｏｍｍｕｔｅｒ  ｒｏｕｔｅｒ  ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  ｆｏｒ  ｔｈｅ  ｍｏｂｉｌｅ  ｉｎｔｅｒｎｅｔ，」ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ２ｎｄ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｍｏｂｉｌｅ  Ｓｙｓｔｅｍｓ，Ａｐｐｌｉｃａｔｉｏｎｓ，ａｎｄ  Ｓｅｒｖｉｃｅｓ（ＭｏｂｉＳｙｓ），ｐａｇｅｓ２１７−２３０，２００４。
［３８］Ｊ．Ｃｈｅｓｔｅｒｆｉｅｌｄ，Ｒ．Ｃｈａｋｒａｖｏｒｔｙ，Ｉ．Ｐｒａｔｔ，Ｓ．Ｂａｎｅｒｊｅｅ，ａｎｄ  Ｐ．Ｒｏｄｒｉｇｕｅｚ，「Ｅｘｐｌｏｉｔｉｎｇ  ｄｉｖｅｒｓｉｔｙ  ｔｏ  ｅｎｈａｎｃｅ  ｍｕｌｔｉｍｅｄｉａ  ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ｃｅｌｌｕｌａｒ  ｌｉｎｋｓ，」ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ２００５  ＩＥＥＥ  ＩＮＦＯＣＯＭ，ｐａｇｅｓ  ２０２０−２０３１，Ｍａｒ．２００５。
［３９］Ｂ．Ｈａｎ，Ｐ．Ｈｕｉ，Ｖ．Ａ．Ｋｕｍａｒ，Ｍ．Ｖ．Ｍａｒａｔｈｅ，Ｇ．Ｐｅｉ，ａｎｄ  Ａ．Ｓｒｉｎｉｖａｓａｎ，「Ｃｅｌｌｕｌａｒ  ｔｒａｆｆｉｃ  ｏｆｆｌｏａｄｉｎｇ  ｔｈｒｏｕｇｈ  ｏｐｐｏｒｔｕｎｉｓｔｉｃ  ｃｏｍｍｕｎｉｃａｔｉｏｎｓ：ａ  ｃａｓｅ  ｓｔｕｄｙ，」ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ５ｔｈ  ＡＣＭ  Ｗｏｒｋｓｈｏｐ  ｏｎ  Ｃｈａｌｌｅｎｇｅｄ  Ｎｅｔｗｏｒｋｓ（ＣＨＡＮＴＳ），ｐａｇｅｓ  ３１−３８，２０１０。
［４０］Ｓ．ｌｏａｎｎｉｄｉｓ，Ａ．Ｃｈａｉｎｔｒｅａｕ，ａｎｄ  Ｌ．Ｍａｓｓｏｕｌｉｅ．「Ｏｐｔｉｍａｌ  ａｎｄ  ｓｃａｌａｂｌｅ  ｄｉｓｔｒｉｂｕｔｉｏｎ  ｏｆ  ｃｏｎｔｅｎｔ  ｕｐｄａｔｅｓ  ｏｖｅｒ  ａ  ｍｏｂｉｌｅ  ｓｏｃｉａｌ  ｎｅｔｗｏｒｋ，」ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ２００９  ＩＥＥＥ  ＩＮＦＯＣＯＭ，ｐａｇｅｓ  １４２２−１４３０，Ａｐｒ．２００９。
［４１］Ｊ．Ｗｈｉｔｂｅｃｋ，Ｍ．Ａｍｏｒｉｍ，Ｙ．Ｌｏｐｅｚ，Ｊ．Ｌｅｇｕａｙ，ａｎｄ  Ｖ．Ｃｏｎａｎ．「Ｒｅｌｉｅｖｉｎｇ  ｔｈｅ  ｗｉｒｅｌｅｓｓ  ｉｎｆｒａｓｔｒｕｃｔｕｒｅ：Ｗｈｅｎ  ｏｐｐｏｒｔｕｎｉｓｔｉｃ  ｎｅｔｗｏｒｋｓ  ｍｅｅｔ  ｇｕａｒａｎｔｅｅｄ  ｄｅｌａｙｓ，」ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ２０１１  ＩＥＥＥ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｓｙｍｐｏｓｉｕｍ  ｏｎ  ａ  Ｗｏｒｌｄ  ｏｆ  Ｗｉｒｅｌｅｓｓ，Ｍｏｂｉｌｅａｎｄ  Ｍｕｌｔｉｍｅｄｉａ  Ｎｅｔｗｏｒｋｓ（ＷｏＷＭｏＭ），ｐａｇｅｓ  １−１０，Ｊｕｎｅ  ２０１１。
［４２］Ｃ．Ｂｏｌｄｒｉｎｉ，Ｍ．Ｃｏｎｔｉ，ａｎｄ  Ａ．Ｐａｓｓａｒｅｌｌａ，「Ｅｘｐｌｏｉｔｉｎｇ  ｕｓｅｒｓ’  ｓｏｃｉａｌ  ｒｅｌａｔｉｏｎｓ  ｔｏ  ｆｏｒｗａｒｄ  ｄａｔａ  ｉｎ  ｏｐｐｏｒｔｕｎｉｓｔｉｃ  ｎｅｔｗｏｒｋｓ：Ｔｈｅ  ＨｉＢＯｐ  ｓｏｌｕｔｉｏｎ，」ｉｎ  Ｐｅｒｖａｓｉｖｅ  ａｎｄ  Ｍｏｂｉｌｅ  Ｃｏｍｐｕｔｉｎｇ，４（５）：６３３−６５７，Ｏｃｔ．２００８。
［４３］Ｐ．Ｈｕｉ，Ｊ．Ｃｒｏｗｃｒｏｆｔ，ａｎｄ  Ｅ．Ｙｏｎｅｋｉ．「Ｂｕｂｂｌｅ  ｒａｐ：ｓｏｃｉａｌ−ｂａｓｅｄ  ｆｏｒｗａｒｄｉｎｇ  ｉｎ  ｄｅｌａｙ  ｔｏｌｅｒａｎｔ  ｎｅｔｗｏｒｋｓ，」ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ９ｔｈ  ＡＣＭ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｓｙｍｐｏｓｉｕｍ  ｏｎ  Ｍｏｂｉｌｅ  Ａｄ  Ｈｏｃ  Ｎｅｔｗｏｒｋｉｎｇ  ａｎｄ  Ｃｏｍｐｕｔｉｎｇ（Ｍｏｂｉ−Ｈｏｃ），ｐａｇｅｓ  ２４１−２５０，２００８。
［４４］Ｇ．Ａｎａｎｔｈａｎａｒａｙａｎａｎ，Ｖ．Ｎ．Ｐａｄｍａｎａｂｈａｎ，Ｌ．Ｒａｖｉｎｄｒａｎａｔｈ，ａｎｄ  Ｃ．Ａ．Ｔｈｅｋｋａｔｈ，「ＣＯＭＢＩＮＥ：ｌｅｖｅｒａｇｉｎｇ  ｔｈｅ  ｐｏｗｅｒ  ｏｆ  ｗｉｒｅｌｅｓｓ  ｐｅｅｒｓ  ｔｈｒｏｕｇｈ  ｃｏｌｌａｂｏｒａｔｉｖｅ  ｄｏｗｎｌｏａｄｉｎｇ，」ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ５ｔｈ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｍｏｂｉｌｅ  Ｓｙｓｔｅｍｓ，Ａｐｐｌｉｃａｔｉｏｎｓ  ａｎｄ  Ｓｅｒｖｉｃｅｓ（ＭｏｂｉＳｙｓ），ｐａｇｅｓ  ２８６−２９８，２００７。
［４５］Ｍ．Ｓｔｉｅｍｅｒｌｉｎｇ  ａｎｄ  Ｓ．Ｋｉｅｓｅｌ，「Ａ  ｓｙｓｔｅｍ  ｆｏｒ  ｐｅｅｒ−ｔｏ−ｐｅｅｒ  ｖｉｄｅｏ  ｓｔｒｅａｍｉｎｇ  ｉｎ  ｒｅｓｏｕｒｃｅ  ｃｏｎｓｔｒａｉｎｅｄ  ｍｏｂｉｌｅ  ｅｎｖｉｒｏｎｍｅｎｔｓ，」ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  １  ｓｔ  ＡＣＭ  Ｗｏｒｋｓｈｏｐ  ｏｎ  Ｕｓｅｒ−ｐｒｏｖｉｄｅｄ  Ｎｅｔｗｏｒｋｉｎｇ：Ｃｈａｌｌｅｎｇｅｓ  ａｎｄ  Ｏｐｐｏｒｔｕｎｉｔｉｅｓ（Ｕ−ＮＥＴ），ｐａｇｅｓ  ２５−３０，２００９。
［４６］Ｖｅｒｉｚｏｎ  Ｓｈａｒｅ−Ｅｖｅｒｙｔｈｉｎｇ  Ｐｌａｎ，ｈｔｔｐ：／／ｗｗｗ．ｖｅｒｉｚｏｎｗｉｒｅｌｅｓｓ．ｃｏｍ／ｗｃｍｓ／ｃｏｎｓｕｍｅｒ／ｓｈｏｐ／ｓｈａｒｅ−ｅｖｅｒｙｔｈｉｎｇ．ｈｔｍｌ（２０１４年１月３０日に参照）。
［４７］ＡＴ＆Ｔ  Ｍｏｂｉｌｅ  Ｓｈａｒｅ  Ｖａｌｕｅ  Ｐｌａｎｓ，ｈｔｔｐ：／／ｗｗｗ．ａｔｔ．ｃｏｍ／ｓｈｏｐ／ｗｉｒｅｌｅｓｓ／ｄａｔａ−ｐｌａｎｓ．ｈｔｍｌ＃ｆｂｉｄ＝１０ｎｄＥｓｐｖ７ＢＷ（２０１４年１月３０日に参照）。
［４８］Ｔ−Ｍｏｂｉｌｅ，「Ｓｍａｒｔｐｈｏｎｅ  Ｍｏｂｉｌｅ  Ｈｏｔｓｐｏｔ，」ｈｔｔｐ：／／ｏｆｆｅｒｓ．ｔ−ｍｏｂｉｌｅ．ｃｏｍ／ｔｅｔｈｅｒｉｎｇ／ａｄｍｉｎ／ｆａｑ．ｊｓｐ（２０１４年１月３０日に参照）。
［４９］Ｌ．Ｋｅｌｌｅｒ，Ａ．Ｌｅ，Ｂ．Ｃｉｃｉ，Ｈ．Ｓｅｆｅｒｏｇｌｕ，Ｃ．Ｆｒａｇｏｕｌｉ，Ａ．Ｍａｒｋｏｐｏｕｌｏｕ，「Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ  ｆｏｒ  Ｃｏｏｐｅｒａｔｉｖｅ  Ｄａｔａ  Ｓｔｒｅａｍｉｎｇ，」２０１３年３月にＵＣ  ＩｒｖｉｎｅおよびＥＰＦＬによって共同で出願された米国特許出願（米国特許出願第１３／８４１，５００号）。
［５０］Ａ．Ｌｅ，Ｌ．Ｋｅｌｌｅｒ，Ｃ．Ｆｒａｇｏｕｌｉ，Ａ．Ｍａｒｋｏｐｏｕｌｏｕ，「Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ  ｆｏｒ  Ｌｏｃａｌ  Ｍｕｌｔｉｐｌａｙｅｒ  Ｇａｍｉｎｇ，」２０１３年３月にＵＣ  ＩｒｖｉｎｅおよびＥＰＦＬによって共同で出願された米国特許出願（米国特許出願第１３／８４１，９５６号）。
【図１Ａ】
2018517341.tif 000003
【図１Ｂ】
2018517341.tif 000004
【図１Ｃ】
2018517341.tif 000005
【図１Ｄ】
2018517341.tif 000006
【図１Ｅ】
2018517341.tif 000007
【図２】
2018517341.tif 000008
【図３】
2018517341.tif 000009
【図４Ａ】
2018517341.tif 000010
【図４Ｂ】
2018517341.tif 000011
【図４Ｃ】
2018517341.tif 000012
【図５Ａ】
2018517341.tif 000013
【図５Ｂ】
2018517341.tif 000014
【図５Ｃ】
2018517341.tif 000015
【図６Ａ】
2018517341.tif 000016
【図６Ｂ】
2018517341.tif 000017
【図６Ｃ】
2018517341.tif 000018
【図７】
2018517341.tif 000019
【図８】
2018517341.tif 000020
【図９】
2018517341.tif 000021
【図１０】
2018517341.tif 000022
【図１１】
2018517341.tif 000023
【図１２】
2018517341.tif 000024
【図１３】
2018517341.tif 000025
【図１４】
2018517341.tif 000026
【図１５】
2018517341.tif 000027
【図１６】
2018517341.tif 000028
【図１７】
2018517341.tif 000029
【国際調査報告】
2018517341.tif 000030
2018517341.tif 000031
2018517341.tif 000032