▶ モボファイルズ インク． ディービーエー モボライズの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-01-12
(45)【発行日】2023-01-20
(54)【発明の名称】動的チャネルボンディングのシステム及び方法
(51)【国際特許分類】
H04W 48/18 20090101AFI20230113BHJP
H04W 48/16 20090101ALI20230113BHJP
【ＦＩ】
H04W48/18
H04W48/16 131
【請求項の数】
30
(21)【出願番号】P 2020566841
(86)(22)【出願日】2019-05-31
(65)【公表番号】
(43)【公表日】2021-09-27
(86)【国際出願番号】 US2019035082
(87)【国際公開番号】W WO2019232497
(87)【国際公開日】2019-12-05
【審査請求日】2022-04-08
(31)【優先権主張番号】62/678,810
(32)【優先日】2018-05-31
(33)【優先権主張国・地域又は機関】US
【早期審査対象出願】
(73)【特許権者】
【識別番号】514116693
【氏名又は名称】モボファイルズ インク． ディービーエー モボライズ
(74)【代理人】
【識別番号】100093861
【弁理士】
【氏名又は名称】大賀 眞司
(74)【代理人】
【識別番号】100129218
【弁理士】
【氏名又は名称】百本 宏之
(72)【発明者】
【氏名】ウィリアム・ウェイヤ・チョウ
(72)【発明者】
【氏名】マーク・レア・ツイ
(72)【発明者】
【氏名】ブライアン・アレックス・トゥルン
【審査官】野村 潔
(56)【参考文献】
【文献】特表２０１６－５１７６４７（ＪＰ，Ａ）
【文献】特表２０１４－５３２２３３（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１８／００４８５６７（ＵＳ，Ａ１）
【文献】欧州特許出願公開第０１９６２４７１（ＥＰ，Ａ１）
【文献】米国特許第０６１４１６８６（ＵＳ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｂ ７／２４－ ７／２６
Ｈ０４Ｗ ４／００－９９／００
３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４
ＳＡ ＷＧ１－４
ＣＴ ＷＧ１、４
(57)【特許請求の範囲】
【請求項1】
プロセッサと、メモリと、複数のネットワークに接続するように構成された複数のネットワークインターフェースとを備えるポータブル通信デバイス上のネットワークトラフィックを管理する方法であって、前記プロセッサ上で動作しているトラフィックマネージャが、前記プロセッサ上で動作しているアプリケーションへのかつ当該アプリケーションからのネットワークデータをインターセプトすることと、
前記トラフィックマネージャが、サーバの冪等リクエストを前記ネットワークデータが有するときを判断することと、
前記トラフィックマネージャが、前記アプリケーションから受信した冪等リクエストと同じ冪等リクエストを、前記複数のネットワークを介して前記サーバに送信することと、
前記トラフィックマネージャが、前記複数のネットワーク上の第１のネットワークを介して前記サーバからの前記冪等リクエストへの応答を受信することと、
前記トラフィックマネージャが、前記アプリケーションの前記冪等リクエストに関連付けられた追加的なネットワークデータを送受信するために使用する前記第１のネットワークを選択することと
を含む、方法。
【請求項2】
前記複数のネットワークを介して前記サーバに前記冪等リクエストを送信することは、前記複数のネットワークのうちの第２のネットワーク上で前記冪等リクエストを送信することを含み、前記方法は、前記第２のネットワーク上で前記冪等リクエストを終了することをさらに含む、請求項１に記載の方法。
【請求項3】
前記複数のネットワークを介して前記サーバに前記冪等リクエストを送信することは、前記複数のネットワークのうちの１つのネットワークを介して前記サーバに前記冪等リクエストを送信することと、
遅延に応じて前記複数のネットワークのうちの１つ以上の他のネットワークを介して前記サーバに前記冪等リクエストを送信することとを含む、請求項１に記載の方法。
【請求項4】
前記遅延は、前記ポータブル通信デバイス上で動作している前記アプリケーションのアプリケーションレベルタイムアウトよりも短い、請求項３に記載の方法。
【請求項5】
前記遅延は、前記冪等リクエストに対する典型的な応答時間に基づいて設定される、請求項３に記載の方法。
【請求項6】
前記冪等リクエストは、ネットワークプロトコルに関連付けられており、前記遅延は、前記冪等リクエストに関連付けられた前記ネットワークプロトコルに基づいて設定される、請求項３に記載の方法。
【請求項7】
前記遅延は、前記冪等リクエストに対する応答のサイズに基づいて設定される、請求項３に記載の方法。
【請求項8】
前記遅延は、ネットワーク品質メトリックに基づいて設定される、請求項３に記載の方法。
【請求項9】
前記複数のネットワークは、優先順位に従って配置され、前記１つ以上の他のネットワークは、前記優先順位に従って選択される、請求項３に記載の方法。
【請求項10】
前記ネットワークの各々は、前記優先順位に従って異なる遅延に関連付けられる、請求項９に記載の方法。
【請求項11】
前記複数のネットワークを１つ以上の動的要因に従って前記優先順位で再配置することをさらに含む、請求項９に記載の方法。
【請求項12】
前記１つ以上の動的要因は、ネットワーク性能を含む、請求項１１に記載の方法。
【請求項13】
前記１つ以上の動的要因は、ネットワークトラフィックコストを含む、請求項１１に記載の方法。
【請求項14】
前記複数のネットワークは、複数の異なる種類のネットワークを含む、請求項１に記載の方法。
【請求項15】
複数の種類のネットワークは、セルラー、Ｂｌｕｅｔｏｏｔｈ、及びＷｉ－Ｆｉネットワークのうちの１つ以上を含む、請求項１４に記載の方法。
【請求項16】
プロセッサと、メモリと、複数のネットワークに接続するように構成された複数のネットワークインターフェースとを備えるポータブル通信デバイスであって、前記メモリは、前記プロセッサによって実行された場合に、前記プロセッサ上で動作しているトラフィックマネージャが、前記プロセッサ上で動作しているアプリケーションへのかつ当該アプリケーションからのネットワークデータをインターセプトすることと、
前記トラフィックマネージャが、サーバの冪等リクエストを前記ネットワークデータが有するときを判断することと、
前記トラフィックマネージャが、前記アプリケーションから受信した冪等リクエストと同じ冪等リクエストを、前記複数のネットワークを介して前記サーバに送信することと、
前記トラフィックマネージャが、前記複数のネットワーク上の第１のネットワークを介して前記サーバからの前記冪等リクエストに対する応答を受信することと、
前記トラフィックマネージャが、前記アプリケーションの前記冪等リクエストに関連付けられた追加的なネットワークデータを送受信するために使用する前記第１のネットワークを選択することと
によって前記ポータブル通信デバイスのネットワークトラフィックを管理することを前記プロセッサにさせる命令を前記メモリが記憶する、ポータブル通信デバイス。
【請求項17】
前記複数のネットワークを介して前記サーバに前記冪等リクエストを送信することは、前記複数のネットワークのうちの第２のネットワーク上で前記冪等リクエストを送信することを含み、前記命令は、前記第２のネットワーク上の前記冪等リクエストを前記プロセッサに終了させる命令をさらに含む、請求項１６に記載のポータブル通信デバイス。
【請求項18】
前記複数のネットワークを介して前記サーバに前記冪等リクエストを送信することは、前記複数のネットワークのうちの１つのネットワークを介して前記サーバに前記冪等リクエストを送信することと、
遅延に応じて前記複数のネットワークのうちの１つ以上の他のネットワークを介して前記サーバに前記冪等リクエストを送信することとを含む、請求項１６に記載のポータブル通信デバイス。
【請求項19】
前記遅延は、前記ポータブル通信デバイス上で動作している前記アプリケーションのアプリケーションレベルタイムアウトよりも短い、請求項１８に記載のポータブル通信デバイス。
【請求項20】
前記遅延は、前記冪等リクエストへの典型的な応答時間に基づいて設定される、請求項１８に記載のポータブル通信デバイス。
【請求項21】
前記冪等リクエストは、ネットワークプロトコルに関連付けられており、前記遅延は、前記冪等リクエストに関連付けられる前記ネットワークプロトコルに基づいて設定される、請求項１８に記載のポータブル通信デバイス。
【請求項22】
前記遅延は、前記冪等リクエストへの応答のサイズに基づいて設定される、請求項１８に記載のポータブル通信デバイス。
【請求項23】
前記遅延は、ネットワーク品質メトリックに基づいて設定される、請求項１８に記載のポータブル通信デバイス。
【請求項24】
前記複数のネットワークは、優先順位に従って配置され、前記１つ以上の他のネットワークは、前記優先順位に従って選択される、請求項１８に記載のポータブル通信デバイス。
【請求項25】
前記ネットワークの各々は、前記優先順位に従って異なる遅延に関連付けられる、請求項２４に記載のポータブル通信デバイス。
【請求項26】
前記メモリは、１つ以上の動的要因に従って前記優先順位で前記複数のネットワークを前記プロセッサに再配置させる命令をさらに記憶する、請求項２４に記載のポータブル通信デバイス。
【請求項27】
前記１つ以上の動的要因は、ネットワーク性能を含む、請求項２６に記載のポータブル通信デバイス。
【請求項28】
前記１つ以上の動的要因は、ネットワークトラフィックコストを含む、請求項２７に記載のポータブル通信デバイス。
【請求項29】
前記複数のネットワークは、複数の異なる種類のネットワークを含む、請求項１６に記載のポータブル通信デバイス。
【請求項30】
複数の種類のネットワークは、セルラー、Ｂｌｕｅｔｏｏｔｈ、及びＷｉ－Ｆｉネットワークのうちの１つ以上を含む、請求項２９に記載のポータブル通信デバイス。【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
【0002】
本出願は、２０１８年５月３１日に米国特許商標庁に出願された米国仮特許出願第６２／６７８，８１０号の利益を主張するものであり、参照によりその開示全体が本明細書に組み込まれる。
【0003】
本発明の実施形態の様態は、コンピュータネットワーキングの分野に関する。
【背景技術】
【0004】
接続ボンディング又はリンクアグリゲーションは、多数のネットワーク接続を結合又は集約するための方法に関する。
【0005】
いくつかのネットワーク条件の下では、コンピューティングデバイスがネットワーク到達の使用可能な範囲の近く又はそれを超えた場合、又はネットワークの容量の使用可能な限界の近く又はそれを超えた場合などは、コンピューティングデバイス上のネットワーク接続性は貧弱であり得る。例えば、無線ローカルエリアネットワーク又はＷＬＡＮ（例えばＷｉ－Ｆｉネットワーク）に接続されているスマートフォンが、無線ネットワークの有効範囲の縁部に移動されると（自宅の私道で車に乗っているときなど）、スマートフォンは、無線ネットワークへの接続が貧弱であっても、一般に、そのセルラー接続に切り替えるのではなく、無線ネットワークを介してデータを送信及びリクエストしようとし続ける。その結果、セルラーネットワーク信号が強い場合であっても、ユーザがローカル無線ネットワークの縁部にいる場合に、ネットワーク接続が一時的に失われるなど、劣悪なユーザ体験となる可能性がある。もう１つの例は、混雑した喫茶店やスポーツイベント中のスタジアムの混雑したＷｉ－Ｆｉネットワークなど、処理能力を上回るトラフィックを有するワイヤレスネットワークにスマートフォンが接続されている場合である。その結果、インターネットコンテンツにアクセスしようと試みた場合に、ハングアウトやタイムアウトが発生するなど、劣悪なユーザの操作性となり得る。
【0006】
ＷＬＡＮ接続の例としては、Ｗｉ－Ｆｉとも呼ばれるＩＥＥＥ ８０２.１１規格に基づくネットワークなどを含む。セルラーネットワーク接続の例としては、３Ｇ無線セルラーネットワーク（例えばユニバーサル移動体通信サービス又はＵＭＴＳ、モバイル用グローバルシステム又はＧＳＭ、及び符号分割多元接続２０００又はＣＤＭＡ２０００などと呼ばれる場合もある）又は４Ｇ無線セルラーネットワーク（例えば、Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｓｉｏｎ Ａｄｖａｎｃｅｄ又はＬＴＥ Ａｄｖａｎｃｅｄなどと呼ばれる場合もある）等を含む。
【0007】
Ｗｉ－Ｆｉなどの他の種類のネットワークへの接続には、性能（例えば、セルラー接続よりも遅い場合がある）、アクセシビリティ（例えば、インターネットアクセスを許可する前にログインが必要になる場合がある）、又は品質（例えばより良い信号又は性能を有する別のアクセスポイントが存在する場合がある）などの追加の問題もある。一般的に、これらの問題はデバイス（その上で動作するソフトウェアを含む）では適切に処理されないか又はまったく処理されないため、ユーザは多くの場合、デバイス上でＷｉ－Ｆｉを無効にしたり又は切断したりして、手動でデバイスにセルラー接続を使用させるなど、これらの接続を手動で管理する必要がある。この結果、非常に劣悪なユーザ体験（例えば、ユーザにＷｉ－Ｆｉをオンに戻すタイミングを覚えてもらう必要がある）をもたらし、ユーザ（例えば、ユーザが従量制のデータプランを有する場合）又はモバイルネットワークオペレータ（例えば、ユーザが無制限のデータプランを有している場合）のいずれかのためのより高いセルラーコストのような付加的な結果をもたらす。
【0008】
デバイスは、Ｂｌｕｅｔｏｏｔｈなどの他の種類のネットワーク又は将来的に可能な他のネットワークにも接続でき、これらのいずれのネットワークでも、その縁部で同様の問題が発生する可能性がある。一般的に、デバイスが接続できる異なる機能がある異種ネットワークが複数存在する場合、デバイスが、使用可能な各ネットワークをいつどのように使用すべきかという課題がある。
【0009】
関連技術
【0010】
デバイスが使用可能な複数の、おそらく異種のネットワークの使用を管理する問題は、当該問題に取り組む際の他の関連するアプローチを見てきた。その範囲は、ユーザによる手動制御を可能にするユーザインターフェース（ＵＩ）設定の提供から、ネットワークへの接続を自動化するソフトウェアベースのアプローチ（例えばＷｉ－Ｆｉ用のＰａｓｓｐｏｉｎｔ（登録商標））、複数の使用可能なネットワークがどのようにいつ使用されるかの制御（例えばＭｕｌｔｉｐａｔｈ ＴＣＰ）にまで及ぶ。
【0011】
複数の使用可能なネットワークにわたってネットワークトラフィックを分割し、次いで関連する仲介体を使用して、分割されたトラフィックを下流で再結合することによって、おそらくより高い性能（例えば、セルラー及びＷｉ－Ｆｉネットワークにわたって同時にデータの負荷バランシングを行うことによって）及びより高い回復力（例えば、失われたＷｉ－Ｆｉパケットをセルラーネットワークに再試行／再送することによって）を可能にすることにより、例えば、マルチパスＴＣＰ（ＭＰＴＣＰ）などの複数のネットワークを同時に活用するようにいくつかの比較ネットワークプロトコルが設計されている。クライアントでトラフィックを分割し、その後に下流のサーバ（又は同等の仲介体）でトラフィックを再結合するという統合クライアント／サーバモデルに従っている、長年にわたって開発されてきたこのようなネットワークプロトコル（専有のものを含む）は数多くある。しかし、これらのアプローチでは、すべてのデバイストラフィックが仲介体を介して誘導される必要があり、これは、重大な影響（例えば、高い運転コスト）をもたらし得る。このコストは、一般に、モバイルネットワークオペレーター（ＭＮＯ）など、デバイスが使用するネットワークのいずれかのオペレーターが負担するが、ここで、追加コストには、ユーザのデバイスがＷｉ－Ｆｉネットワークに接続されている間、ＭＮＯが以前は扱う必要がなかった新しいサーバと追加の帯域幅（例えばＷｉ－Ｆｉトラフィック）が含まれる。
【0012】
講じられる他の比較アプローチは、アプリケーションがマルチネットワーク・アウェアであることであるが、例えば、アプリケーションがそのトラフィックをＷｉ－Ｆｉ及び／又はセルラーの両方に同時に（負荷バランシングによる性能）又は選択的に（１つのネットワークが機能しない場合の回復力）向ける。例えば、Ｓａｍｓｕｎｇ（登録商標）のダウンロードブースターは、セルラーとＷｉ－Ｆｉにわたっての負荷バランシングにより大容量ファイルのダウンロード（＞３０ＭＢ）を高速化できる。しかし、このアプローチは、異なるアプリケーションに亘ってネットワーク性能の全般的改善を提供するようには拡張しない（例えば、このアプローチはウェブ閲覧やビデオ視聴を改善しない）が、これは、ウェブブラウザなどの特定のアプリによって実行されるファイルのダウンロード専用に使用されるからである。これらのアプローチはまた、各ネットワークの動的に変化する性能の特徴に基づいて使用可能なネットワーク間の負荷を動的に調整するアウェアネスを欠いている。他の比較例としては、Ａｐｐｌｅ（登録商標）ｉＯＳのＷｉ－Ｆｉアシスト機能があり、Ｗｉ－Ｆｉが不応答であることを検出すると、アプリをセルラーを使用するように切り替えることができる。しかし、この実装では、実際に応答しているネットワークを迅速かつシームレスに（例えばほぼリアルタイムで）検出する機能がないため、Ｗｉ－Ｆｉからセルラーに切り替える前にネットワークリクエストがハング又はタイムアウトする必要がある。また、Ａｐｐｌｅ（登録商標）のＷｉ－Ｆｉアシスト機能は、「フォアグラウンド」アプリ（つまりユーザが現在操作しているフォアグラウンドで動作しているアプリケーション）に制限されているが、これは、ユーザ又はＭＮＯセルラーデータの使用量を制御するためのポリシー制御がないためである。
【発明の概要】
【0013】
本発明の実施形態の態様は、ネットワーク接続性を改善するために、コンピューティングデバイスにおける多数のネットワーク接続を自動的に管理するシステム及び方法に関する。
【0014】
本発明の一実施形態に従って、プロセッサと、メモリと、複数のネットワークに接続するように構成された複数のネットワークインターフェースとを備えるポータブル通信デバイス上のネットワークトラフィックを管理する方法は、前記プロセッサ上で動作しているトラフィックマネージャによって、前記プロセッサ上で動作しているアプリケーションへのかつ当該アプリケーションからのネットワークデータをインターセプトすることと、前記トラフィックマネージャによって、前記複数のネットワークを介して前記ネットワークデータの冪等リクエストをサーバに送信することと、前記トラフィックマネージャによって、前記複数のネットワーク上の第１のネットワークを介して前記サーバからの前記冪等リクエストへの応答を受信することと、前記トラフィックマネージャによって、前記アプリケーションへの前記応答を送受信するために使用する前記複数のネットワークのうちの前記第１のネットワークを選択することとを含む。
【0015】
前記複数のネットワークを介して前記サーバに前記冪等リクエストを送信することは、前記複数のネットワークのうちの第２のネットワーク上で前記冪等リクエストを送信することを含んでよく、前記方法は、前記第２のネットワーク上で前記冪等リクエストを終了することをさらに含んでよい。
【0016】
前記複数のネットワークを介して前記サーバに前記冪等リクエストを送信することは、前記複数のネットワークのうちの１つのネットワークを介して前記サーバに前記冪等リクエストを送信することと、遅延に応じて前記複数のネットワークのうちの１つ以上の他のネットワークを介して前記サーバに前記冪等リクエストを送信することとを含んでよい。
【0017】
前記遅延は、前記ポータブル通信デバイス上で動作している前記アプリケーションのアプリケーションレベルタイムアウトよりも短くてよい。
【0018】
前記遅延は、前記冪等リクエストに対する典型的な応答時間に基づいて設定されてよい。
【0019】
前記冪等リクエストは、ネットワークプロトコルに関連付けられてよく、前記遅延は、前記冪等リクエストに関連付けられた前記ネットワークプロトコルに基づいて設定されてよい。
【0020】
前記遅延は、前記冪等リクエストに対する応答のサイズに基づいて設定されてよい。
【0021】
前記遅延は、ネットワーク品質メトリックに基づいて設定されてよい。
【0022】
前記複数のネットワークは、優先順位に従って配置されてよく、前記１つ以上の他のネットワークは、前記優先順位に従って選択されてよい。
【0023】
前記ネットワークの各々は、前記優先順位に従って異なる遅延に関連付けられてよい。
【0024】
前記方法は、前記複数のネットワークを１つ以上の動的要因に従って前記優先順位で再配置することをさらに含んでよい。
【0025】
前記１つ以上の動的要因は、ネットワーク性能を含んでよい。
【0026】
前記１つ以上の動的要因は、ネットワークトラフィックコストを含んでよい。
【0027】
前記複数のネットワークは、複数の異なる種類のネットワークを含んでよい。
【0028】
前記複数の種類のネットワークは、セルラー、Ｂｌｕｅｔｏｏｔｈ、及びＷｉ－Ｆｉネットワークのうちの１つ以上を含んでよい。
【0029】
本発明の一実施形態に従って、プロセッサと、メモリと、複数のネットワークに接続するように構成された複数のネットワークインターフェースとを備えるポータブル通信デバイス上のネットワークトラフィックを管理する方法は、前記複数のネットワークのうちの、前記プロセッサ上で動作しているオペレーティングシステムによってプライマリネットワークとして指定される第１のネットワークを介して、前記プロセッサ上で動作しているアプリケーションのネットワークトラフィックを処理することと、前記第１のネットワークに関連付けられた複数のネットワーク状態情報を監視することと、前記受信したネットワーク状態情報の１つ以上のパラメータが、１つ以上の閾値の外にある場合に、第１のネットワークの問題を検出することと、前記第１のネットワークにおける前記問題の検出に応答して、前記複数のネットワークのうちの第２のネットワークを前記プライマリネットワークとして選択することと、前記更新されたプライマリネットワークとしての前記第２のネットワークを介して前記ネットワークトラフィックを処理することとを含む。
【0030】
前記ネットワークトラフィックは、リクエストと、前記リクエストへの応答とを含んでよく、前記第１のネットワークにおける前記問題は、前記リクエストのタイムスタンプと、最大閾値を上回る前記応答のタイムスタンプとの間の応答時間に基づいて検出されてよい。
【0031】
前記第１のネットワークにおける前記問題を検出することは、前記第１のネットワーク上のネットワーク統計のうちの少なくとも１つを監視することと、前記ネットワーク統計の変更が閾値を上回った場合に、前記問題を検出することとを含んでよい。
【0032】
前記ネットワーク統計は、パケット損失率又は不良パケット率を含んでよい。
【0033】
前記第１のネットワークは、無線ネットワークであってよく、前記第１のネットワークにおける前記問題の検出は、前記無線ネットワークの信号強度を監視することと、前記信号強度が閾値信号強度を下回った場合に、前記問題を検出することとを含んでよい。
【0034】
前記複数のネットワークのうちの前記第２のネットワークは、前記複数のネットワークの優先順位に従って選択されてよい。
【0035】
前記第１のネットワークにおける前記問題は、前記第１のネットワーク上で応答が受信される前に他のネットワーク上で受信される応答に基づいて検出されてよい。
【0036】
本発明の一実施形態に従って、ポータブル通信デバイスは、プロセッサと、メモリと、複数のネットワークに接続するように構成された複数のネットワークインターフェースとを備え、前記メモリは、前記プロセッサによって実行された場合に、前記プロセッサ上で動作しているトラフィックマネージャによって、前記プロセッサ上で動作しているアプリケーションへのかつ当該アプリケーションからのネットワークデータをインターセプトすることと、前記トラフィックマネージャによって、前記複数のネットワークを介して前記ネットワークデータの冪等リクエストをサーバに送信することと、前記トラフィックマネージャによって、前記複数のネットワーク上の第１のネットワークを介して前記サーバからの前記冪等リクエストに対する応答を受信することと、前記トラフィックマネージャによって、前記アプリケーションへの前記応答を送受信するために使用する前記複数のネットワークのうちの前記第１のネットワークを選択することとによって、前記プロセッサをして、前記ポータブル通信デバイスのネットワークトラフィックを管理させる命令を記憶する。
【0037】
前記複数のネットワークを介して前記サーバに前記冪等リクエストを送信することは、前記複数のネットワークのうちの第２のネットワーク上で前記冪等リクエストを送信することを含んでよく、前記命令は、前記プロセッサをして、前記第２のネットワーク上の前記冪等リクエストを終了させる命令をさらに含んでよい。
【0038】
前記複数のネットワークを介して前記サーバに前記冪等リクエストを送信することは、前記複数のネットワークのうちの１つのネットワークを介して前記サーバに前記冪等リクエストを送信することと、遅延に応じて前記複数のネットワークのうちの１つ以上の他のネットワークを介して前記サーバに前記冪等リクエストを送信することとを含んでよい。
【0039】
前記遅延は、前記ポータブル通信デバイス上で動作している前記アプリケーションのアプリケーションレベルタイムアウトよりも短くてよい。
【0040】
前記遅延は、前記冪等リクエストへの典型的な応答時間に基づいて設定されてよい。
【0041】
前記冪等リクエストは、ネットワークプロトコルに関連付けられてよく、前記遅延は、前記冪等リクエストに関連付けられる前記ネットワークプロトコルに基づいて設定されてよい。
【0042】
前記遅延は、前記冪等リクエストへの応答のサイズに基づいて設定されてよい。
【0043】
前記遅延は、ネットワーク品質メトリックに基づいて設定されてよい。
【0044】
前記複数のネットワークは、優先順位に従って配置されてよく、前記１つ以上の他のネットワークは、前記優先順位に従って選択されてよい。
【0045】
前記ネットワークの各々は、前記優先順位に従って異なる遅延に関連付けられてよい。
【0046】
前記メモリは、前記プロセッサによって実行された場合、前記プロセッサをして、１つ以上の動的要因に従って前記優先順位で前記複数のネットワークを再配置させる命令をさらに記憶してよい。
【0047】
前記１つ以上の動的要因は、ネットワーク性能を含んでよい。
【0048】
前記１つ以上の動的要因は、ネットワークトラフィックコストを含んでよい。
【0049】
前記複数のネットワークは、複数の異なる種類のネットワークを含んでよい。
【0050】
前記複数の種類のネットワークは、セルラー、Ｂｌｕｅｔｏｏｔｈ、及びＷｉ－Ｆｉネットワークのうちの１つ以上を含んでよい。
【0051】
本発明の一実施形態に従って、ポータブル通信デバイスは、プロセッサと、メモリと、複数のネットワークに接続するように構成された複数のネットワークインターフェースとを備え、前記メモリは、前記プロセッサによって実行された場合に、前記複数のネットワークのうち、前記プロセッサ上で動作しているオペレーティングシステムによってプライマリネットワークとして指定される第１のネットワークを介して前記プロセッサ上で動作しているアプリケーションのネットワークトラフィックを処理することと、前記第１のネットワークに関連付けられた複数のネットワーク状態情報を監視することと、前記受信したネットワーク状態情報の１つ以上のパラメータが、１つ以上の閾値の外にある場合に、前記第１のネットワークの問題を検出することと、前記第１のネットワークにおける前記問題の検出に応答して、前記複数のネットワークのうちの第２のネットワークを前記プライマリネットワークとして選択することと、前記更新されたプライマリネットワークとしての前記第２のネットワークを介して前記ネットワークトラフィックを処理することとによって、前記プロセッサをして前記ポータブル通信デバイスのネットワークトラフィックを管理させる命令を記憶する。
【0052】
前記ネットワークトラフィックは、リクエストと、前記リクエストに対する応答とを含んでよく、前記第１のネットワークにおける前記問題は、前記リクエストのタイムスタンプと、最大閾値を上回る前記応答のタイムスタンプとの間の応答時間に基づいて検出されてよい。
【0053】
前記第１のネットワークにおける前記問題を検出するための前記命令は、前記プロセッサによって実行された場合に、前記プロセッサをして、前記第１のネットワーク上のネットワーク統計のうちの少なくとも１つを監視することと、前記ネットワーク統計情報の変更が閾値を上回った場合に、前記問題を検出することとを行わせる命令を含んでよい。
【0054】
前記ネットワーク統計は、パケット損失率又は不良パケット率を含んでよい。
【0055】
前記第１のネットワークが無線ネットワークであってよく、前記第１のネットワークにおける前記問題の検出は、前記無線ネットワークの信号強度を監視することと、前記信号強度が閾値信号強度を下回った場合に、前記問題を検出することとを含んでよい。
【0056】
前記複数のネットワークのうちの前記第２のネットワークは、前記複数のネットワークの優先順位に従って選択されてよい。
【0057】
前記第１のネットワークにおける前記問題は、前記第１のネットワーク上で応答が受信される前に、他のネットワーク上で受信される応答に基づいて検出されてよい。
【0058】
本発明の実施形態の態様は、アクティブリクエスト数に基づいて異なるネットワーク上でリクエストを送信することによって、改良された性能を提供することに関するものであり、異なるネットワーク間のアクティブリクエストの比率に基づいて負荷を分散することと、レイテンシ及び帯域幅を含む要因に基づきアクティブリクエストの比率を動的に調整することと、前回のインバウンド／応答データ以降十分に長い遅延があった場合のアウトバウンド／リクエストデータの存在及びリクエストの完了による新規アクティブリクエストの検出を含む、暗号化トラフィックのアクティブリクエストを検出しかつ追跡することを含む。
【0059】
本発明の一実施形態に従って、コンピュータプロセッサと、コンピュータサーバにデータを送信又は受信するための複数のネットワークインターフェースとを有するポータブル通信デバイス上でネットワークトラフィックを管理する方法は、トラフィックマネージャアプリケーションによって、第１のアプリケーションへの又はからの第１のデータの電子トラフィックをインターセプトすることと、前記トラフィックマネージャアプリケーションによって、各ネットワークインターフェースへのアクティブデータリクエスト又は応答の数を追跡することと、前記トラフィックマネージャアプリケーションによって、アクティブデータのやり取りの数に基づいて、前記サーバへの又はからの前記第１のアプリケーションへの又はからの第１のデータの引渡のために使用する前記ネットワークインターフェースを選択することとを含む。
【0060】
本発明の一実施形態に従って、プロセッサと、メモリと、複数のネットワークに接続するように構成された複数のネットワークインターフェースとを備えるポータブル通信デバイス上のトラフィックを管理する方法は、前記プロセッサ上で動作しているトラフィックマネージャによって、前記プロセッサ上で動作しているアプリケーションへのかつ当該アプリケーションからのネットワークデータをインターセプトすることと、前記トラフィックマネージャによって、前記複数のネットワークを介して複数のリクエストをサーバに送信することと、前記トラフィックマネージャによって、各ネットワークインターフェースと関連付けられた複数の数のアクティブデータリクエストを追跡することと、前記トラフィックマネージャによって、前記ネットワークインターフェースに関連付けられた前記複数の数のアクティブデータリクエストに従って、前記サーバに前記ネットワークデータを送信し、かつ前記サーバから前記ネットワークデータを受信するための前記複数のネットワークインターフェースのうちのネットワークインターフェースを選択することとを含む。
【0061】
前記複数のネットワークのうちの１つが、プライマリネットワークとして指定されてよく、かつ前記ネットワークインターフェースを選択することは、前記プライマリネットワークと関連付けられたアクティブデータリクエストの数が閾値を上回ると判断することと、前記アクティブデータリクエストの数が前記閾値を上回らない前記複数のネットワークのうちの別のネットワークに対応するネットワークインターフェースを選択することとを含んでよい。
【0062】
前記複数のネットワークインターフェースのうちの前記ネットワークインターフェースを選択することは、前記複数のネットワークインターフェースのうちの第２のネットワークインターフェースを選択することと、前記ネットワークインターフェースに関連付けられたアクティブデータリクエストの数と、前記第２のネットワークインターフェースに関連付けられたアクティブデータリクエストとに従って、アクティブデータリクエストの比率を計算することと、前記アクティブリクエストの比率に従って、前記ネットワークインターフェースと前記第２のネットワークインターフェースとの間で前記ネットワークデータのネットワークトラフィックを分散することとを含んでよい。
【0063】
前記方法は、前記複数のネットワークの複数のネットワーク条件に従って前記アクティブリクエストの比率を動的に調整することをさらに含んでよい。
【0064】
前記ネットワーク条件は、前記複数のネットワークに対応するレイテンシ測定を含んでよい。
【0065】
前記ネットワーク条件は、前記複数のネットワークに対応する最大帯域幅測定を含んでよい。
【0066】
前記方法は、前記ネットワークインターフェースに関連付けられた第１のネットワーク又は前記第２のネットワークインターフェースに関連付けられた第２のネットワークが、不応答ネットワークである場合に、これを検出することと、前記不応答ネットワークを放棄することとをさらに含んでよい。
【0067】
本発明の実施形態の態様は、ボンディング（例えば、ダブルタップ又は負荷バランシング）が、プライマリ／デフォルトネットワークの劣化を検出した場合、別のネットワークに切り替えることと、ダブルタップ（例えば、前記プライマリネットワークをスイッチオフした場合など）に基づいて別のネットワークに切り替えることと、例えば、アクティブリクエストが現在のプライマリネットワーク上で十分に迅速に完了しない場合など、負荷バランシングに基づいて別のネットワークに切り替えることとを含む、接続管理に関する。
【図面の簡単な説明】
【0068】
添付の図は、明細書と共に、本発明の実施形態例を示し、これらの図は以下の説明と共に、本発明の原則を説明するのに役立つ。
【図1】本発明の一実施形態に従ってオンデバイスのチャネルボンディング実装で使用するのに適した、スマートフォンなどの例示的なポータブル通信デバイスのアーキテクチャの略図である。
【図2】本発明の実施形態に従ってアプリとサーバとの間のネットワークトラフィックの監視及び制御を可能にするプロキシ内のソフトウェアコンポーネントのブロック図である。
【図3】本発明の一実施形態に従ってプライマリネットワークを設定する方法を示すハイレベルのフローチャート図である。
【図4】本発明の一実施形態に従ってアドバンス信号を利用してネットワークアクセスを制御する方法を示すハイレベルのフローチャート図である。
【図5】本発明の一実施形態に従って負荷バランシングのアプローチの方法例を示すハイレベルのフローチャート図である。
【図6】各Ｗｉ－Ｆｉネットワークが良好な信号品質の領域を示す内側の緑の円形領域と、不良な信号品質の領域を示す外側の赤の円形領域（つまりＷｉ－Ｆｉネットワークのデッドゾーン）とを有する、複数のＷｉ－Ｆｉネットワークの近傍域例を示している。
【発明を実施するための形態】
【0069】
以下の詳細な説明では、本発明の特定の例示的実施形態のみを実例として示し説明する。当業者であれば認識するように、本発明は多くの異なる形式で実施することができ、本明細書に記載される実施形態に制限されるとは解釈されるべきではない。
【0070】
モバイルネットワーキングにおける１つの課題は、異機種ネットワークの場合のように、異なるネットワーク間のハンドオフがシームレスでないことが多いということである。異機種ネットワークの使用は、一般に、Ｗｉ－Ｆｉとセルラー間の切り替えなど、モバイルデバイスでサポートされる異なる種類のネットワーク間の切り替え時に発生する。例えば、モバイルデバイスがＷｉ－Ｆｉネットワークに結合／取付されている場合、Ｗｉ－Ｆｉ信号が弱過ぎて（又は貧弱過ぎて）信頼性の高い通信に使用できないときでも、デバイスはそのＷｉ－Ｆｉネットワークにとどまってネットワーク通信にこれを使用するが、なぜならば、Ｗｉ－Ｆｉを使用しようとするすべての試みが失敗するまで（例えば、長いタイムアウトの後）、Ｗｉ－Ｆｉが使用できないことを検出するのが難しいからである。この状態はしばしば「デッドゾーン」として知られており、ここでは、デバイスは、使用できないネットワークに依然として接続されていて使用している（又は使用しようと試みている）ためにインターネットに接続できない。この問題は、同じ種類のネットワーク間で切り替えを行う場合にも発生するが、なぜならば、それらのネットワーク間で調整が行われないことが多いからである。例えば、デバイスが１つのＷｉ－Ｆｉネットワークのデッドゾーンにあるが、その範囲内に別のより良好な使用可能なＷｉ－Ｆｉネットワークがある場合であっても、デバイスは、それらのＷｉ－Ｆｉネットワーク間で何らかの明示的な調整が行われない限り、別のＷｉ－Ｆｉネットワークに切り替わらない。明示的な調整の例としては、一般的に企業によって運用される複数のＷｉ－Ｆｉアクセスポイントを有する「エンタープライズ」メッシュネットワークがあり、ＩＥＥＥ ８０２．１１ｒや８０２.１１ｖなどのハンドオフ技術を利用する。しかし、ユーザは、公共スペースなどで互いに無関係なＷｉ－Ｆｉネットワークを使用していることが多いが、かかる公共スペースでは、互いに認識していない（例えば、協力していない）１つ以上の重複又は隣接しているＷｉ－Ｆｉネットワークが存在する場合があるため、その間でデバイスを積極的にハンドオフすることはできない。言い換えると、これはシームレスなハンドオフを妨げる異機種ネットワークの別の事例である。
【0071】
複数のネットワークに負荷を分散する際の１つの課題は、各ネットワークが異なる性能の特徴を有する場合に、負荷の最適な分散を決定することである。例えば、全体的な性能は最も低速なパスによって決まるため、単純な負荷バランシングのポリシーでは性能が改善しないことがよくあり得る。以下の表１では、Ｗｉ－Ｆｉネットワークの速度が４０ｍｂｐｓ、セルラーネットワークの速度が２０ｍｂｐｓであることを想定している。この表は、高速のＷｉ－Ｆｉ接続と、より低速のセルラー接続の間との負荷の様々な分散を使用して、４０ＭＢのファイルと１００ＭＢをダウンロードするための経過時間の様々な計算を示している。
【0072】
【表1】
【0073】
表１は、実際の性能の向上を達成できるためには、使用可能なネットワークの相対的な性能に比例して負荷を分散することが望ましいことを示しており、例えば、セルラーネットワークの２倍の速度のＷｉ－Ｆｉネットワークでは、総待機時間を大幅に短縮するためには、２倍のトラフィックが必要である。
【0074】
しかし、複数のネットワークに負荷を適切に分散させる場合の１つの問題は、それが実際にいつ必要とされるかを判断することであり、なぜならば、クライアント装置が、ネットワークが処理できるよりも多くのネットワーク負荷及び／又はトラフィックを生成しようとせずに、ネットワークの容量にいつ達したかを判断することが困難であるからであり、これは、ウェブページの閲覧のような通常の使用時にはめったに発生しない。ネットワーク容量の上限に達したことを判断するためのいくつかのアプローチは、総帯域幅レートが増加しなくなるまで、大きなテストファイルの複数の同時ダウンロードを継続的に追加する「速度テスト」によってなどして、テストトラフィックを生成することである。しかし、このアプローチは通常のユーザの活動中には適用できないものであり、なぜならば、このアプローチが不要な追加の負荷（バッテリ持続時間やネットワーク使用量に影響を与えるかもしれない）を発生させ、ユーザの活動に干渉／競合し、追加のネットワーク使用コスト（例えば従量制ネットワークを使用する場合）を追加する可能性があるからである。また、この技術は、使用可能なネットワーク容量（例えば同じネットワーク上の他のユーザに基づいて変動する混雑）の動的な変化を考慮しておらず、現在のネットワーク容量を連続的に再計算するために絶えずテストトラフィックを生成することは一般に望ましくない。
【0075】
従って、本発明の実施形態の態様は、トラフィックを仲介体／サーバによって分割して再結合する必要がなく、ネットワークの現在の容量に達したか否かをテストするためにネットワークトラフィックを生成する必要もなく、エンドユーザ（クライアント）デバイスにおいて使用可能なネットワークの品質及び性能をリアルタイムに（例えば必要に応じてネットワーク使用時に）検出する能力を有するアプローチを対象としている。本発明の実施形態のいくつかの態様は、負荷バランシングが、異なる種類のネットワークトラフィック（例えば、大容量ファイルのダウンロードだけでなく、ウェブブラウジングなど）を高速化するように、並びにクライアントでのハング及びタイムアウトを回避するためにＷｉ－Ｆｉからセルラーへの迅速なフェイルオーバーを可能にするように動的に調整することができるように、使用可能なネットワークのきめ細かいアウェアネスに関する。
【0076】
本発明の実施形態の態様は、ネットワーク接続性を改善するためにコンピューティングデバイス内の複数のネットワーク接続を自動的に管理するためのシステム及び方法に関する。便宜上、本発明の実施形態は、無線ローカルエリアネットワーク（例えばＷＬＡＮ又はＷｉ－Ｆｉ）の接続性と、セルラーネットワーク（例えば３Ｇ ＧＳＭ、４Ｇ ＬＴＥ）の接続性の両方を有するモバイルデバイスにおけるネットワーク接続性を改良することに関して本明細書で説明される。しかし、本発明の実施形態はこれに限定されるものではなく、２つの異なるネットワーク接続（例えば、無線ローカルエリアネットワーク接続及び有線ローカルエリアネットワーク接続）を有するデバイス、及び２つ以上の異なるネットワーク接続（例えば、有線ローカルエリアネットワーク接続又は衛星データ接続などの第３のネットワーク接続）を有するデバイスにも適用してよい。
【0077】
以下に本発明の実施形態例について、添付の図を参照して説明する。図では、同じ又は類似の参照番号は、全体を通じて同じ又は類似の要素を示す。本明細書において、本発明の実施形態を説明する際の「～得る、～してよい」という用語の使用は、「本発明の１つ以上の実施形態」を示す。さらに、本発明の実施形態を説明する際の「又は」などの代替の文言の使用は、列挙されている各対応する項目について「本発明の１つ以上の実施形態」を示す。
【0078】
図１は、本発明の一実施形態に従ったオンデバイスのチャネルボンディングの実装で使用するのに適した例示的なポータブル通信デバイス（例えばスマートフォン）のアーキテクチャ１００の略図である。例示の目的上、ポータブル通信デバイス又はモバイル装置１００は、Ａｎｄｒｏｉｄ（登録商標）スマートフォンであることを仮定する。しかし、本発明の実施形態はこれに限定されるものではなく、Ａｎｄｒｏｉｄ（登録商標）以外のオペレーティングシステムを実行するスマートフォンやタブレットコンピュータ、ラップトップコンピュータ等の他のコンピューティングデバイスに適用してもよい。さらに、このようなモバイルデバイスは多くのユーザをサポートできるが、説明を容易にするために、モバイルデバイスは特定のユーザ専用であると仮定するため、「ユーザ」及び「モバイルデバイス」という用語（又は個人的又はポータブルな方法で使用されるコンピュータデバイス）は、全体を通して同義的に使用してもよい。
【0079】
本発明の１つ以上の実施形態に従って、ポータブル通信デバイス又はモバイルデバイス上の一般的なアーキテクチャ（例えばアーキテクチャ１００）は、アプリケーション（例えばモバイルアプリ又は「アプリ」）で発生し、例えば、モバイルデバイスが例えばＷｉ－Ｆｉ又はセルラーネットワークを介してアクセスするアプリケーションサーバ（又はアプリサーバ）２５０に送信されるデータトラフィックを監視又は制御するように構成されている中央プロキシ１３０（又はトラフィックマネージャ）を提供する。このアプローチにより、チャネルボンディングを複数のネットワーク（例えばＷｉ－Ｆｉやセルラー）にわたって、かつ複数のアプリケーションにわたって実行することができ、チャネルボンディングを中央管理することができるが、本発明の実施形態はこれに限定されない。他の実施形態では、チャネルボンディングは、各アプリケーション内で、又はアプリの特定のサブセットに対してプライベートに実行してもよい。
【0080】
ポータブル通信デバイス１００のアプリ及び他のプログラム可能なコンポーネントは、例えば、ポータブル通信デバイス１００の非一時的な記憶装置（例えばフラッシュメモリ１７０）に記憶されたコンピュータ命令のセットとして実装され、ポータブル通信デバイス１００の１つ以上のプロセッサ上で実行されるように構成されてもよい。プロキシ１３０はまた、ウェブブラウザからのような特定のウェブサイトのためのトラフィックを管理してもよい。従って、説明を容易にするために、プロキシ１３０によって管理されているコンテンツのカテゴリを参照する場合に、「アプリケーション」、「アプリ」、「ウェブサイト」、又は「サイト」などの用語は本出願全体では幾分交換可能に使用してもよい。
【0081】
プロキシ１３０は、ソケット層１２０を使用するプロキシサーバ（例えばオペレーティングシステム（ＯＳ）のネットワーク設定による）、ネットワークトンネル（ＴＵＮ）デバイス２３０を使用する仮想プライベートネットワーク（ＶＰＮ）サービス１４０（例えばＯＳのネットワーク設定）、又は遮断層１５０を使用するアプリへの組み込みなど、いくつかの異なる仕組みと連携してよい。プロキシ１３０は、Ｊａｖａ仮想マシン（ＪＶＭ）、Ａｎｄｒｏｉｄ（登録商標）ランタイム（ＡＲＴ）、又は他の管理されたランタイム環境１６０上で実行されてもよく、又は管理されたランタイム環境なしにオペレーティングシステム上で直接実行されてもよい。プロキシ１３０は、フラッシュメモリ１７０又は他の不揮発性記憶装置などの物理的記憶装置上のキャッシュされたコンテンツを管理するためのキャッシュエンジン１１０を含んでもよい。一般性を失うことなく、このような装置は「ディスク」と呼ばれることもあるが、ソリッドステートドライブ（例えば、ＮＡＮＤフラッシュメモリ）などの任意の種類の非一時的な記憶装置であり得る。さらに、キャッシュされた又は他の記憶されたコンテンツの全部又は一部は、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）などの揮発性記憶装置に記憶してよく、この揮発性記憶装置は、最近アクセスされたコンテンツがより低速の不揮発性記憶装置に移行する前に、より高速の揮発性記憶装置に記憶される階層方式などのように、不揮発性記憶装置と組み合わせて使用してもよい。
【0082】
プロキシ１３０は、アプリケーション、カーネルドライバ、又はモバイルデバイス上のＯＳ内などの様々なフォームファクタで動作してよく、かつ内部アプリ１８０及び外部アプリケーションサーバ２５０からネットワーク接続を受信するように（例えばＯＳのネットワーク設定を介して）構成してよい。１つ以上の実施形態では、プロキシサーバは、ＪＶＭ１６０などの管理されたランタイム環境で実行してよい。プロキシ１３０は、クライアントアプリケーション１８０のための仲介体として機能してよい。例えば、プロキシ１３０は、ＪＶＭ１６５などの別の管理されたランタイム環境で動作するアプリ１８０のリクエストを処理してよい。
【0083】
動作の一例として、アプリ１８０は、例えば、ＨｔｔｐＵＲＬ接続１９０などのＡｎｄｒｏｉｄサービスを使用してインターネットへのアクセスをリクエストしてよい。（ここで、ＨＴＴＰは、ハイパーテキスト転送プロトコルを表し、ＵＲＬは、ウェブアドレスなどのユニフォームリソースロケータを表す。）次にＨｔｔｐＵＲＬ接続１９０は、インターネットにアクセスするためにＯＳによって提供されるネットワークサービス２００を呼び出してよい。ネットワークサービス２００は、例えば、アクセスポイント名（ＡＰＮ）２１０（例えば、３Ｇ又は４Ｇセルラーネットワークなどのモバイルネットワーク）又はＷｉ－Ｆｉ接続２２０を使用してインターネットにアクセスしてよい。ネットワークサービス２００は、図１に点線で示すように、システムにグローバルに適用されるか又はＡＰＮ２１０又はＷｉ－Ｆｉ接続２２０に適用されるプロキシ構成を使用して、リクエストをアプリ１８０からプロキシサーバ１３０にルーティングするように構成されてもよい。ネットワークサービス２００は、図１に破線で示すように、他の様々な方法、例えばネットワークトンネル（ＴＵＮ）デバイス２３０又はＩＰルーティングテーブル（「ｉｐｔａｂｌｅｓ」とも知られている）を介して、リクエストをアプリ１８０からプロキシ１３０にルーティングしてもよい。
【0084】
ネットワークサービス２００は、インターネットにアクセスするためにプロキシを直接的又は間接的に（例えば、デバイス上で動作するアプリによって直接検出され使用される、又はＡＰＮ２１０又はＷｉ－Ｆｉ接続２２０上の設定を通して間接的にグローバルシステムプロキシとして）指定するように構成されてよく、よって、リクエストが、ソケット１２０（例えば、インターネットに接続するためのネットワークソケット）などの標準通信層を通して送信され、プロキシ１３０によって受信されるようにする。一方、プロキシ１３０は、ネットワークサービス２００を通して（自身へのループバックを回避するためにＡＰＮ又はＷｉ－Ｆｉプロキシ設定をバイパスしている間）、及び外部ネットワーク２４０上でリクエストをアプリサーバ２５０に対して行ってよく、ここで、アプリサーバ２５０は、リクエストを処理し、外部ネットワーク２４０及びネットワークサービス２００を介して応答通信をプロキシ１３０に返す。従って、プロキシ１３０はその後、アプリ１８０とサーバ２５０との間の通信を監視又は制御してよい。プロキシ１３０はまた、サーバ２５０からキャッシングエンジン１１０を介して受信した応答の一部、ゼロ、又は全てをキャッシュし、その後で説明した同じ段階を逆にしてネットワークソケット１２０を介して応答をアプリ１８０に返してもよい（例えば、ＡＰＮ ２１０接続／Ｗｉ－Ｆｉ２２０接続、ネットワークサービス２００、及びＨｔｔｐＵＲＬ接続ライブラリ１９０）。
【0085】
ＡＰＮ又はＷｉ－Ｆｉ接続でプロキシ構成を使用する代わりに、ネットワークサービス２００は、他の様々な手段を介してリクエストをプロキシサーバ１３０にルーティングするように構成してもよい。例えば、別のアプローチは、ネットワークトンネル（ＴＵＮ）２３０を使用してＶＰＮ接続を確立することであるが、これは、ネットワーク送信を処理するためにネットワーク活動をＶＰＮサービス１４０にルーティングし得る。次にＶＰＮサービス１４０は、リクエストを処理し、かつネットワークトンネル２３０を介して応答を返すためにソケット１２０（適宜に）を使用して、アプリ１８０とアプリケーションサーバ２５０との間のトラフィックを管理するためにリクエストをプロキシ１３０にルーティングしてよい。
【0086】
プロキシ１３０を関与させるための別の機構は、アプリ内で遮断層（例えば遮断層１５０及び１５５）を使用して、トラフィックをプロキシプロセスにリダイレクトすることである。例えば、上記の例では、Ｈｔｔｐ ＵＲＬ接続１９０がネットワークサービス２００を呼び出してインターネットにアクセスする前又はその代わりに、ＨｔｔｐＵＲＬ接続１９０は、遮断層１５０にアプリ１８０からのリクエストをインターセプトさせ、そのトラフィックをプロキシ１３０に直接転送してよい。インターセプト１５０からプロキシ１３０への転送は、ネットワークサービス２００を介して、又は、メッセージキュー、名前付きパイプ、又は共有メモリなど、当業者には明らかであろう標準的なプロセス間通信（ＩＰＣ）機構を使用して実行してよい。
【0087】
プロキシ１３０がＪＶＭ１６０内などの別個のプロセス内で動作するのに加えて、他の実施形態では、プロキシ１３０は、ＪＶＭ１６５又はブラウザ１８５（例えばウェブブラウザ）などのリクエストプロセス内に埋め込まれてもよい。その後、プロキシ１３０は、プロセス間通信を必要とせずにアプリのネットワークトラフィックを管理してよい。
【0088】
別の例では、ウェブブラウザ１８５は、インターネット（例えば外部ネットワーク２４０）にアクセスしようとする。上記のアプリ１８０と同様に、ウェブブラウザ１８５は、いくつかの異なるアプローチによってプロキシ１３０を活用してよい。例えば、ウェブブラウザ１８５は、ネットワークソケット１２５を使用してインターネットにアクセスするように構成してよく、これは次に、例えば上述のようにソケット１２０又はＶＰＮサービス１４０を使用して、ネットワークサービス２００を使用してアプリサーバ２５０及び／又はプロキシ１３０にアクセスすることができる。同様の方法で、遮断層１５５をウェブブラウザ１８５に追加してよく、それがウェブブラウザ１８５からのリクエストをインターセプトし、そのトラフィックをプロキシ１３０に転送し得る。
【0089】
より詳細には、上記の技術は、既存のインターフェースに統合してよく、かかる既存のインターフェースでは、いくつかの実施形態では、セキュアソケットレイヤー（ＳＳＬ、例えば暗号化されている）通信と非ＳＳＬ（例えば暗号化されていない）通信との間の技術が区別される。アプリケーションとの統合は、例えば、ネットワークスタック内の集中化された場所で、非ＳＳＬ通信のために可能にしてよい。例えば、プロキシ１３０は、ＨＴＴＰ、ＨＴＴＰＳ、又はその両方のためだけなど、ネットワークプロトコルの全て又はサブセットのためのプロキシとして構成されてよい。同様に、プロキシ１３０は、セルラー、Ｗｉ－Ｆｉ、又はその両方などのネットワークインターフェースのすべて又はサブセットのプロキシとして構成されてよい。例えば、ＡＰＮ２１０アクセスの場合、セルラーアクセスポイントをプロキシ１３０に設定してもよい。ｉｐｔａｂｌｅｓアクセスの場合、対応するインターネットプロトコル（ＩＰ）ルーティングテーブルのエントリを設定してよい。ＶＰＮサービスの場合、ＶＰＮクライアント（例えばＶＰＮサービス１４０）は、トラフィックをプロキシ１３０にルーティングしてよい。Ｗｉ－Ｆｉの場合、プロキシ１３０を各Ｗｉ－Ｆｉアクセスポイント（ＡＰ）ごとに設定してよい。グローバルシステムプロキシの場合、システムは、すべてのアプリケーショントラフィックのトラフィックをプロキシ１３０に向けてよい。
【0090】
さらに、ＳＳＬ又はＴＬＳなどの暗号化通信を使用するアプリケーションとの統合では、暗号化されていないネットワークデータ（例えば暗号化される前のネットワークデータ）へのアクセスが必要になる場合がある。ここで使用してよいアプローチはいくつかある。中間者のアプローチの場合、暗号化されたデータへのアクセスは、信頼された認証局（ＣＡ）を介してサーバになりすますことによって取得してよい。ソフトウェア開発キット（ＳＤＫ）のアプローチ（例えば図１の遮断層１５５）では、ビルド時リンクを暗号化層の上（例えば前）にあるネットワークＡＰＩへのフックと共に使用できる。再リンクのアプローチの場合、ＨＴＴＰ ＵＲＬ接続１９０などのカスタム置換アプリケーションプログラミングインターフェース（ＡＰＩ）を使用するために、既存のアプリを逆コンパイルして再リンクしてよい。ウェブブラウザ１８５などのブラウザによる代替アプローチの場合、遮断（ｉｎｔｅｒｃｅｐｔｉｏｎ）が既に配線されているところでアプリケーションの代替バージョンを提供してよい。これは、広く使用されているオープンソースアプリに特に適している。
【0091】
図１は主にポータブル通信デバイス又はモバイルデバイス１００のアーキテクチャを対象としているが、一方、オンデバイスのチャネルボンディングは、モバイルデバイス１００の１つ以上のプロセッサ上で動作するように構成されたソフトウェアコンポーネントなどの他のコンポーネントを必然的に伴い得る。図２は、本発明のいくつかの例示的な実施形態に従ったアプリ２８０とサーバ２５０との間のネットワークトラフィックの監視及び制御を可能にするためのプロキシ１３０内のソフトウェアコンポーネントのブロック図である。
【0092】
図２では、モバイルデバイス１００内で動作するアプリ２８０は、アプリサーバ２５０と通信し、プロキシ１３０は、システムプロキシ設定又はＶＰＮを介してなど、前述の方法のいずれかを使用してアプリのネットワークトラフィックをインターセプトすることとなる。プロキシ１３０内では、本発明の１つ以上の実施形態では、ネットワークトラフィックの監視及び制御を実行する論理ソフトウェアコンポーネントがあり、これらのソフトウェアコンポーネントは、内部データパス１３３（モバイルデバイス１００の内部）をアプリ２８０で処理するクライアントハンドラ１３２と、外部ネットワークデータパス１３５（例えばインターネットなどの外部ネットワークを介して、移動装置１００の外部）をアプリサーバ２５０で処理するリクエストハンドラ１３４とを含んでよい。図２は、プロキシ１３０とアプリサーバ２５０との間のいくつかの矢印を示し、ポータブル通信デバイス１００の異なるネットワークインターフェースを介してポータブル通信デバイス１００にアクセス可能な異なるネットワーク（例えば、異なるＷｉ－Ｆｉネットワーク、異なるセルラーネットワーク等）を表す。
【0093】
アプリ２８０とクライアントハンドラ１３２との間のデータパス１３３は、当業者には明らかであろうネットワークソケット又は任意の他の標準プロセス間通信機構などの、アプリのネットワークトラフィックをインターセプトするために使用される方法に応じて、異なる機構上で発生し得る。リクエストハンドラ１３３とアプリサーバ２５０との間のデータパス１３５もまた、アプリ２８０がアプリケーションサーバ２５０と通常どのように通信するか（例えばＴＣＩ／ＩＰを使用したネットワークとソケットでなど）に応じて、異なる機構上で発生し得る。内部データパス１３３とアプリ２８０、そして外部データパス１３５とアプリサーバ２５０を分離することによって、プロキシ１３０は、例えば、アプリ２８０へかつ又はから（内部データパス１３３を介して）データを配信する一方、アプリサーバ２５０へかつ又はから（外部ネットワークデータパス１３５を介して）使用可能な１つ以上のネットワーク接続を使用するために、アプリ２８０によって使用されるネットワークパスを、アプリサーバ２５０と通信する際に使用されるネットワークパスから分離することができる。
【0094】
本発明の別の実施形態に従って、リクエストハンドラ１３３によって使用される外部ネットワークデータパス１３５を管理するために、パスマネージャ１３６を使用してよい。複数の使用可能なネットワークが存在する場合、パスマネージャ１３６は、リクエストハンドラに、アプリサーバ２５０との通信にどのネットワークを使用すべきかを指示するために、１つ以上のポリシーを実装することができる。例えば、リクエストハンドラ１３３に対して、複数のリクエストを複数のネットワークにわたって（例えば複数の外部ネットワークデータパス１３５にわたって）分散（負荷バランスとも呼ばれる）するよう指示することによって、低速ネットワーク（例えば混雑した喫茶店の混雑したＷｉ－Ｆｉネットワーク）を処理する方法を決定するためのポリシーがあってもよい。別の例として、ネットワークの１つが無応答であっても、シームレスで応答性のあるデータ接続を提供するために、複数のネットワーク上でデータリクエストをいつ重複して発行するかを決定するためのポリシーがあってよい。
【0095】
上述したポリシーのいずれも、例えば、ユーザによって提供されたり、アプリによって予め構成されたり、あるいは管理サーバなどの外部システムから受信されたりしてもよい。前述のポリシーのいずれも、例えば各パラメータのどの性能指標、コスト要因、相対的な重み付けなどの複数又は可変のパラメータを有するように拡張されてもよい。例えば、負荷バランシングのポリシーは、デフォルトのプライマリネットワーク（例えばＷｉ－Ｆｉ）を増強するために、どのように／いつ別のネットワーク（例えばセルラー）を使用するかについてのポリシーを計算するために、ネットワーク速度／帯域幅、レイテンシ、及びバイトあたりのコストを考慮してよい。
【0096】
ダブルタップ
【0097】
本発明の実施形態のいくつかの態様は、コンピューティングデバイスに使用可能な複数のネットワーク接続又はネットワークインターフェースのうちの２つ以上においてデータの同じリクエストを送信することによって、使用可能なネットワーク又は外部ネットワークデータパス１３５から選択することに関する。上述の例を続けると、スマートフォンは、その無線ローカルエリアネットワーク（又はＷｉ－Ｆｉ）接続とそのセルラーネットワーク接続の両方で冗長又は「ダブルタップ」リクエスト（例えば、ＤＮＳクエリ、ウェブページのリクエスト）を送信してよい。「リクエスト」という用語は、本明細書では、対応する応答がある任意のネットワークリクエストを指すために一般的に使用される。リクエストをダブルタップするには、リクエストは単に冪等である必要がある（例えば、別の接続で安全に再送できる、又はアプリサーバ２５０によって複数回安全に受信できる）。例えば、アカウント状態のリクエストが一般的に冪等であるのは、リクエストの結果としてアプリサーバ２５０でユーザデータが変更されないからであるが、クレジットカードに課金するリクエストが一般的に冪等ではないのは、アプリサーバ２５０がそのリクエストを受信するたびにクレジットカードに課金し得るからである。このアプローチを実質的にどの種類のネットワークトラフィックでも採用できるのは、多くのネットワークプロトコルの最初のリクエストが一般に冪等であるからである。このような冪等なリクエストの例には、ドメインネームシステム（ＤＮＳ）クエリ、伝送制御プロトコル（ＴＣＰ）接続のＳＹＮパケット、トランスポート層セキュリティ（ＴＬＳ）ハンドシェイクのクライアントハロー、又はＨＴＴＰ ＧＥＴリクエストが含まれる。通常、冪等でない（又は非冪等）リクエストの例には、ＨＴＴＰ ＰＯＳＴが含まれる。
【0098】
本発明の実施形態は、冗長なリクエスト／応答のコストが無視できる／小さい（例えば、応答のサイズがプロトコルによって小さいと定義されているＤＮＳリクエスト）ときなど、１つ以上の他の使用可能なネットワーク上ですぐにダブルタップしてよく（例えば、同じデータリクエストを重複して送信する）、あるいは、コストが大きいかのような場合（例えば、ファイルダウンロードなどの大きなサイズの応答を生成することが予想されるリクエストや、ＴＣＰ接続の確立などの重要なサーバリソースを消費するリクエスト）、最初の遅延の後で他の使用可能なネットワークのいずれか（例えばセルラー）上で同じリクエストをダブルタップする前に、優先ネットワーク（例えばＷｉ－Ｆｉ）上で最初にリクエストを送信してよい。従って、遅延の長さは、冪等なリクエストに対する応答の既知又は期待されるサイズ（例えば、小さいサイズの応答では短い遅延、大きいサイズの応答では長い遅延）に基づいて、又は他のコストの考慮（例えば、低コストの場合は遅延が短く、高コストの場合は遅延が長い）に基づいて設定されてもよい。次にコンピューティングデバイス１００は、どの接続がより優れた性能を有するか（例えば、どの接続が最初に応答を配信するか）を検出し、他方の接続を放棄（例えば応答の受信を控える、かつ／又はさらなるリクエストを送信する）しながら、より優れた接続を使用し続けることができる。上記の例では、弱いＷｉ－Ｆｉネットワーク接続のエリアにおいて本発明の実施形態に従ったダブルタップ技術を用いる場合、コンピューティング装置１００は、Ｗｉ－Ｆｉ接続を介するよりも速くセルラー接続を介して応答を受信し、結果を直ちに提供し得る。対照的に、比較すると、コンピューティングデバイス１００は、最初にＷｉ－Ｆｉ接続を試み、Ｗｉ－Ｆｉ接続が短い遅延（例えばアプリケーションレベルのタイムアウトよりもはるかに短い時間）内に応答しなかった後にのみ、セルラー接続に沿ってリクエストを送信してよく、これを本明細書ではダブルタップ遅延という。
【0099】
冗長リクエストが送信されるのが早ければ早いほど、一方のネットワークの応答が他方のネットワークの応答よりも速いかどうかをより早く検出できる。一般的に、複数のネットワークがある場合、どれを使用するかを決定する際の好み又は優先度がある。例えば、Ｗｉ－Ｆｉは通常、無制限又は定額制のネットワークであるが、一方、セルラーは多くの場合、従量制又はスロットルネットワークであり得るので、Ｗｉ－Ｆｉが、デフォルトで使用する「プライマリ」ネットワークとして好ましい場合があり、一方、セルラー及び他の可能なネットワークは、Ｗｉ－Ｆｉが低速又は応答しない場合に、セカンダリとして使用してよい。異なるネットワークは、異なるコスト及び性能の特徴を有し得ることがあるので、Ｂｌｕｅｔｏｏｔｈよりもセルラーを好む、又は無制限のデータプランを有する場合に、セカンダリネットワークとしてのみセルラーを許可するなど、各ネットワークに関連する異なる優先度があり得る。言い換えると、使用可能なネットワークの優先順位は、性能又はコストのようなネットワークの１つ以上の特徴に基づいて決定することができる。本発明のいくつかの実施形態では、使用可能なネットワークの優先順位は、ユーザによって提供される構成データを介して設定される。本発明の実施形態は、冗長なリクエストに使用するために、異なる優先順位のセカンダリネットワークの組み合わせを利用することができる。
【0100】
例えば、アプリケーションがサーバからデータをリクエストする場合、アプリサーバのドメイン名に関連付けられたＩＰアドレスに対するＤＮＳリクエストを送信し、その後にＴＣＰ ＳＹＮパケットを送信してアプリサーバとの接続を確立し、そして場合によりその後にＴＬＳクライアントハロー（例えば、ＨＴＴＰＳリクエスト用の場合）を送信し、最後にＨＴＴＰ ＧＥＴを送信してデータをリクエストする。これらのリクエストの各々は冪等であり、プライマリネットワークの問題に対する回復力を提供するために、セカンダリネットワークで冗長に発行できる。しかし、これらのリクエストの各々は、ネットワーク及び／又はサーバに対して異なるコストと影響を有する。例えば、ＤＮＳリクエスト／応答は小さくステートレスであるため、ネットワークやＤＮＳサーバに大きなコストやオーバーヘッドを発生させることなく複数のネットワークで冗長に送信できる。しかし、ＴＣＰ接続は、より限定されたリソースである（例えば、サーバの同時接続には制限がある）ため、いくつかの実施形態では、プロキシ１３０は、セカンダリネットワーク上のサーバへのＴＣＰ接続の冗長リクエスト（例えば、ＳＹＮパケットの送信）を、プライマリネットワークを介して典型的な時間内に（例えば、典型的な時間は、多くの場合１～２秒以内でよい）アプリサーバ２５０から応答を受信しなかった（例えば、ＳＹＮ－ＡＣＫの受信）ことを検出するまで遅延させる。上述したように、この待機期間は、本明細書ではダブルタップ遅延（例えば、応答のための典型的な時間よりもわずかに長い時間、例えば２秒）と呼んでよい。
【0101】
一般に、セカンダリネットワーク上で冗長ダブルタップのリクエストを遅延させる場合、プライマリネットワーク上のリクエストには効果的に小さなヘッドスタートが与えられ、ほとんどの場合は正常に完了する（例えば、応答は通常、セカンダリネットワーク上のサーバにＳＹＮリクエストを送る必要なしに、ダブルタップ遅延内でプライマリネットワークを介して受信される）。しかし、ダブルタップ遅延の後、冗長リクエストはセカンダリネットワークで送信されるため、プライマリネットワークで送信されたリクエストと競合することになる。応答が見られる任意のネットワークは、応答を受信するために使用することができ、応答が複数のネットワークを介して受信される可能性がある。重複するネットワークトラフィックを低減又は最小化するために、いくつかの実施形態では、プロキシ１３０は、応答を受信するネットワークを１つだけ（例えば正確に１つ）選択する。本発明の一実施形態では、プロキシ１３０が最初に応答を受信したネットワークが、ダブルタップの「勝者」として選択され、プロキシ１３０は、他の１つ以上のネットワーク上のデータリクエストを終了する（例えば、他の１つ以上の接続を閉じることによって）。ダブルタップの１つ以上の「敗者」を終了することは、冗長な応答に対応するためのさらなる処理及びネットワーク使用（例えば、帯域幅の消費）を防止し、冗長なリクエストを終了する方法は、リクエストの種類によって異なる。例えば、ＤＮＳはステートレスであるため、冗長な「敗者」の応答を無視するだけで十分であるが、一方、ＨＴＴＰリクエストは、ダブルタップレースで負けたネットワーク上の冗長な接続を閉じることで終了できる。
【0102】
ＤＮＳ及びＴＣＰプロトコルについて前述したように、本明細書で説明されるように「ダブルタップ」することができるプロトコルの多くの例があるが、他のプロトコルも同様にこのダブルキャップのアプローチを利用して冗長性を提供できることは、当業者には明らかである。例えば、ＴＬＳセッションは、一般にＴＣＰ接続上で確立され、ＴＬＳクライアントハローのリクエストは、セカンダリネットワーク上でダブルタップされ得るが、これは、好ましくは、プロキシ１３０が典型的な応答時間内に（例えば、典型的には１～２秒以内に）プライマリネットワーク上のアプリサーバ２５０からＴＬＳサーバハローの応答を受信しない遅延後でもあることが好ましい。もう１つの例はＱＵＩＣ（クイックＵＤＰインターネット接続）であり、これはＴＣＰの代わりにＵＤＰを使って論理的に安全な接続を確立し、同じＴＬＳハンドシェイクを利用するので、その冪等なリクエストはダブルタップ技術を使って冗長に送信する（例えば、同じクライアントハローを、セカンダリネットワーク上で、場合によっては遅延の後に冗長的に送信する）ことができる。別の例として、ＨＴＴＰリクエストは一般に、ＴＣＰ又はＱＵＩＣ接続を確立した後に実行され、任意の冪等ＨＴＴＰリクエスト（例えば、方法がＧＥＴ、ＨＥＡＤ、ＰＵＴ、ＤＥＬＥＴＥであるＨＴＴＰリクエスト）は、セカンダリネットワーク上で冗長的に送信することができるが、プライマリネットワーク上で最初に送信した後に遅延して送信することも好ましい。これらの例で説明されているように、ダブルタップは、ＯＳＩネットワークプロトコルモデルによって定義されるプロトコル層など異なるプロトコル層に適用することができ、ダブルタップは、同じアプリケーションレベルのデータリクエストに対して複数のプロトコル層で実行することさえできる。複数のプロトコル層でダブルタップを実行すると、複数の冗長ポイントが提供されるが、ここで、障害（例えば不良なネットワーク信号による）がクライアントとサーバの相互作用でこれらの複数のポイントのいずれかで発生し、セカンダリネットワークで回復される可能性がある。
【0103】
セカンダリネットワーク上の冗長リクエストは、ほとんどの応答に見られる典型的な応答時間だけ遅延されるので（例えばダブルタップ遅延時間）、本発明のいくつかの実施形態では、これらのダブルタップ遅延は、超過時に結果的にエラーを生じるようなアプリケーションのタイムアウト（例えば、最大又は最悪の場合の応答時間に基づいて設定されるタイムアウト）に対して典型的に設定されるよりもはるかに短い閾値である。冗長リクエストの発行に短い遅延（例えば数秒）を使用すると、これらの冗長リクエストは、ネットワークの問題の検出に使用されるアプリケーションのタイムアウトを超過することなく、プライマリネットワークが不良／不応答である場合に、セカンダリネットワークから応答を提供できる。場合によっては、これによって、アプリケーションタイムアウトのメッセージがユーザに表示されることを防ぎ得る（セカンダリネットワークから応答が受信されるため）。対照的に、比較システムでは、ユーザは、アプリケーションレベルでタイムアウトエラーが発生するまで長い時間（例えば数十秒）待つ必要があるかもしれず、問題の原因が何であるかがユーザにとって不明瞭であることが多い（例えば、応答しないＷｉ－Ｆｉネットワークは、そのサーバとの通信が別のネットワークでも試みられない限り、不応答のサーバと区別できないことが多い）。本発明の一実施形態は、セカンダリネットワーク上で冗長的に送信される可能性のあるリクエストの各々に対して適切なダブルタップ遅延を構成することであり、よって、各遅延は、プライマリネットワークが良好であるか、応答があるか、又は健全であるときはいつでも、所定の種類のリクエストの大部分の応答がその時間枠内に受信されることを可能にする。
【0104】
図３は、本発明の一実施形態に従ったダブルタップアプローチの１つの例示的な方法を示すハイレベルのフローチャート図である。このフローチャートは、アプリ２８０とアプリケーションサーバ２５０との間のプロキシ１３０によって図１で説明したようなネットワークデータパスの仲介体によって実行することができる。プロキシ１３０は、ステップ３１０においてデータリクエストがアプリからサーバに送信されるのを待っていてもよい。ステップ３１５でアプリからデータリクエストが受信されると、プロキシは、ステップ３２０でリクエストが冪等であるか否かを判断し、ダブルタップ手法を適用できるか否かを判断する。Ｎｏの場合、プロキシによる通常のネットワーク処理は、ステップ３２５でダブルタップを実行することなく適用される。Ｙｅｓの場合、プロキシ１３０は、該当する場合は（例えば、リクエストの種類、及び場合によっては前述の他の要因に基づいて）、最初にステップ３３０で現在のタイムスタンプをダブルタップ遅延の開始として保存することにより、ダブルタップを適用する。次にデータリクエストは、ステップ３３５で現在のプライマリネットワーク上のサーバに送信される。プロキシ１３０は、ステップ３４０で、ダブルタップ遅延まで、サーバから（例えば、ネットワークが良好／応答する場合）応答が受信されるのを待つ。プロキシがステップ３４５で、ダブルタップトラップ遅延を上回っていると判断した場合、プロキシ１３０はステップ３５０に進み、１つ以上の使用可能なセカンダリネットワーク上で冗長にリクエストを送信する。プロキシ１３０がステップ３４５で、応答がダブルタップ遅延内に正常に受信されたと判定した場合、プロキシ１３０はステップ３７５に進み、応答をアプリ２８０に送信することによって応答を完了する。
【0105】
ステップ３５０で冗長リクエストが送信された場合、プロキシ１３０は、リクエストが冗長的に送信されたネットワークのいずれかで応答が受信されるのを待つ。ステップ３６０で、プロキシ１３０が、応答がいずれのネットワークを介しても（例えばタイムアウト期間内に）受信されなかったと判断した場合、プロキシ１３０は、ステップ３６５でアプリへのリクエストを失敗させる（例えば、エラー応答又は接続リセットなどの失敗をアプリ２８０に送信する）。しかし、最初の応答を受信した場合（例えばタイムアウト期間内に）、この最初の応答は、ダブルタップレースの「勝者」であり、プロキシ１３０は、ステップ３７０で他の「敗者」のネットワーク上のリクエストを放棄することができる（例えば、ソケットを閉じることによって明示的に、又は単にその後の応答を無視することによって黙示的に）。プロキシ１３０が成功した応答を有するので、ステップ３７５でダブルタップの勝者からの応答をアプリ２８０に送信することができる。プロトコル及びアプリとの接続の状態に応じて、論理的リクエストを完了するために実行されるステップ３８０での追加処理があってよい。例えば、ＴＬＳハンドシェイクはクライアントハローで始まるが、プロセスを完了するためにサーバとの追加のリクエスト／応答のラウンドトリップがなされてもよい。逆に、ＤＮＳクエリ又はＴＣＰ接続は、サーバからの単一の応答によって完了し、ステップ３８０で追加の処理を必要としない。
【0106】
プライマリネットワークに問題があると判断された場合（例えば、遅い又は完全に不応答ではない）、現在のプライマリネットワークが明示的に失敗する（例えば、タイムアウト、切断）前に、プライマリネットワークとして異なるネットワークにプリエンプティブに切り替えることが望ましい場合があるが、これは、現在のプライマリネットワーク上の遅延は、ユーザがＷｉ－Ｆｉネットワークの最適範囲の縁部（「デッドゾーン」とも呼ばれる）にいる場合など、現在のリクエスト／接続を超えて継続することが多くあり得るからである。デフォルトで問題のあるプライマリネットワークを使用してネットワークデータの処理を続行しても動作する場合があるが、結果として全体的なネットワーク性能が通常よりも低下する可能性があるが、これは、セカンダリネットワーク上で送信される冗長データリクエストが重複ネットワークトラフィックを最小限に抑えるために遅延されるかもしれないからである。ネットワークトラフィックを処理するためにおそらくより応答性の高い別のネットワークにプライマリネットワークとして切り替えると、リクエストがデフォルトでは遅延なしにそのネットワーク上で最初に送信されることを意味するため、ユーザは、そのより応答性の高いネットワークの性能を最大限に体験できる。プライマリネットワークをいつどのように変更するかを決定する場合には、異なるポリシーが可能である（例えば、連続したダブルタップ勝者の閾値を上回ったり、又は１つ以上の応答の応答時間の最大閾値を上回ったりすることによって）。これらのポリシーに使用される閾値は、特定のネットワーク（例えば、一部のＷｉ－Ｆｉネットワークが他のネットワークよりもＤＮＳへの応答が遅いことは正常であるかもしれない）又は特定のサーバ（例えば、あるサーバが、ＴＣＰ ＳＹＮ又はＴＬＳクライアントハローリクエストに他のサーバよりも遅い応答をするのは正常かもしれない）で見られた以前の結果に基づく発見的学習／機械学習によって手動又は動的に構成することができる。
【0107】
プライマリネットワークに問題がある（又は減衰もしくは劣化した）場合に、性能を向上させる別の方法は、他の信号を利用して、セカンダリネットワークへの冗長リクエストをどれだけ遅延させるかを決定するか、又はプライマリネットワークとして別のネットワークにプリエンプティブに切り替えることである。例えば、デバイス１００（例えばオペレーティングシステム）がネットワーク品質（例えば、信号強度、パケット故障率（例えばパケットの損失／不良））に関する情報へのアクセスを提供する場合、これらを使用してセカンダリネットワークをいつどのように使用するかを決定することができる。例えば、プライマリネットワークがＷｉ－Ｆｉであり、その信号品質（例えば、受信信号強度インジケーター（ＲＳＳＩともいう））が特定の閾値を下回っている場合、冗長リクエストのダブルタップ遅延を、場合によってはゼロにまで削減して、セカンダリネットワークがリクエストをより早く処理できるようにし、かつ劣化したネットワーク接続でタイムアウトを待つことによるユーザに見える遅延を軽減又は最小化できる。このアプローチは段階的又は多層的に行うことができ、よって、異なる信号品質レベルに対して異なる遅延を設定することができる（例えば、信号品質が悪くなるとダブルタップ遅延が減少する）。信号品質の低下や劣化が続くと、以前のプライマリネットワークの信号品質レベルが最悪の場合のレベルを下回った場合に、新しいプライマリネットワークに切り替えるために使用することもできる。ネットワークに使用可能な任意の品質のレベル又はインジケーターを任意の組み合わせで使用して、前述のアプローチを適用して、ダブルタップ遅延を低減するか、又は新しいプライマリネットワークに切り替えることができる。いくつかの実施形態では、現在のプライマリネットワーク（すなわち、新しいプライマリネットワークとして別のネットワークに切り替える前）の信号強度は、動作可能な範囲内であってもよいが、性能が劣化してもよい。例えば、信号強度は、現在のプライマリネットワークの最大帯域幅が減少する地点まで劣化する場合があるが、接続は依然として使用可能である（例えば、部分的なパケット損失）。
【0108】
図４は、本発明の一実施形態に従ったアドバンス信号を利用してネットワークアクセスを制御する方法を示すハイレベルのフローチャート図である。「アドバンス信号」という用語は、本明細書では、ネットワーク動作の監視から検出される早期警告サインを指すために使用してよい（例えば、現在のプライマリネットワークが明示的に失敗したりタイムアウトになったりする前）。いくつかの実施形態では、アドバンス信号の検出を使用して、ダブルタップ遅延を調整するか、及び／又はプライマリ／デフォルトネットワークをプリエンプティブに切り替える。図４を参照すると、一実施形態に従って、ステップ４１０で、プロキシ１３０は、信号強度更新（例えばＲＳＳＩ）又はオペレーティングシステムからの類似のネットワーク品質データのために登録する（このステップは、ネットワーク品質データが使用できない実施形態では省略してよく、これは、オペレーティングシステムがそれをサポートしていない場合や、又は現在のプライマリネットワークで使用できない場合などである）。ステップ４１５で、プロキシ１３０は、パケット統計などのネットワークメトリクス（例えば、ネットワーク上で検出される放棄されたパケット又は再送信されたパケットの数及び／又は率）の監視を開始してもよい。ステップ４２０で、プロキシ１３０は、加入ネットワークの信号品質データ及び／又はネットワーク統計データに対する変更又は更新を待つ。変更が検出される（例えば、オペレーティングシステムがコールバック又は同等の機能（サポートされている場合）及び／又はスレッド又は同等の定期的なサンプルを介して通知を送信し、ネットワークデータの変更を監視する）場合、ステップ４２５で、プロキシ１３０は、更新されたネットワークデータ（例えば、ＲＳＳＩデータ及び／又はネットワーク統計データ）を受信する。
【0109】
ステップ４３０で、プロキシ１３０は、受信された新しい値（例えばＲＳＳＩデータ又はネットワーク統計データの値）が「良好な」ネットワークを示す所定の閾値よりも「下」であるか（又はそれ以外の点でより良好であるか）否かを判断する。Ｙｅｓの場合は、プロキシはステップ４２０に戻り、より多くのデータを待つ。例えば、パケット損失率が「良好」の閾値を下回る場合は、変更は必要なく、プロキシ１３０はステップ４２０に戻る。「下」（又は図４の「＜」）という用語は、必ずしも数値を指すものではなく、その値が「良好な」性能の範囲内にあるか否かを指すものである。例えば、ＲＳＳＩ値は、信号強度が高いほど良いので、高い信号強度は、図４に示すように、「良好な」閾値の条件を満たす。逆に、パケット損失は小さい方が良いため、値が小さい（又はこの値の変化率）場合は「良好な閾値」の条件を満たす。
【0110】
新しい値が「良好な」閾値又は範囲内にない場合、プロキシ１３０は、ステップ４３５に進み、新しい値が「使用可能な」範囲内にあるか否かを判定する（プロキシ１３０がステップ４３５に達したので、新しい値は「良好な」範囲外である）。Ｙｅｓの場合、ステップ４４０で、プロキシ１３０は、上述したダブルタップ遅延を減少する。これは、現在のネットワークが信頼できないように見えるためであり、従って、リクエストは早期に代替ネットワークで送信する必要がある。ステップ４４０でダブルタップ遅延を減らした後で、プロキシはステップ４２０に戻って次のネットワーク状態の更新を待つ。
【0111】
プロキシ１３０がステップ４３５で、新しい値が「使用可能な」範囲内にないと判断した場合、ステップ４４５で、プロキシ１３０は、ポータブル通信デバイス１００に使用可能なネットワークの別のネットワークをプライマリネットワークとして設定する。別のネットワークの選択は、上述したように、他のネットワーク（例えば最高ランクのネットワーク）間の優先順位に基づいて行ってよい。
【0112】
本発明の実施形態のいくつかの態様は、図３に関して上述したように、ダブルタップリクエストの応答時間に基づいてプライマリネットワークとなる別のネットワークを選択することに関する。引き続き図４を参照して、本発明のいくつかの実施形態では、プロキシ１３０がステップ４５０で現在のプライマリネットワークを介してダブルタップを実行した後で、プロキシ１３０はステップ４５５でダブルタップの勝者の応答時間を計算する（例えば、リクエストのタイムスタンプと、ネットワークからの対応する応答のタイムスタンプとの間の差）。ステップ４６０で、プロキシ１３０は、応答時間が「使用可能な」閾値を上回ったか否かを判断するが、これは、アプリ２８０によって検出される障害／タイムアウトを回避するのに十分に低いが、ネットワークが将来のリクエストに対するデフォルトのネットワークとして好まれるほど十分には応答していないことを示すのに十分に高い時間閾値（例えば２～４秒）である。Ｙｅｓの場合、プロキシ１３０は、上述したように、ステップ４４５で新しいプライマリネットワークを選択する。
【0113】
ダブルタップの勝者の応答時間がプライマリネットワークに対して許容された最大の「使用可能」時間閾値内である場合、プロキシ１３０は、ステップ４６５で、プライマリネットワークがダブルタップの勝者であったか否かをチェックする。Ｙｅｓの場合は、プライマリネットワークは十分に応答していることが確認され、プロキシ１３０は、ステップ４５０で、デフォルトでそれをリクエストに使用し続ける。しかし、ダブルタップの勝者がセカンダリネットワークであった場合、ステップ４７０で、プライマリネットワークで観測された連続ダブルタップ負けの数をインクリメントする。次に、ステップ４７５で、プロキシ１３０は、プライマリネットワークによる連続ダブルタップ負けの数が、プライマリネットワークが十分に劣化しているか又は応答していないことを示す（例えば２～４連敗）「使用可能な」閾値を上回っているか否かをチェックする。Ｎｏの場合、プライマリネットワークは依然として十分に応答があるかもしれず、プロキシ１３０は、ステップ４５０で、デフォルトでそれをリクエストに使用し続ける。そうでない場合、プロキシ１３０は、上述したように、ステップ４４５で新しいプライマリネットワークを選択する。
【0114】
デフォルトでプライマリネットワークとして使用するために別のネットワークに切り替える場合、これは、通常は優先ネットワーク（例えばＷｉ－Ｆｉ）に問題があり（例えば、不応答又は遅過ぎる）、優先度の低い別のネットワーク（例えばセルラー）を使用したほうがよいことを意味する。次に、ユーザがＷｉ－Ｆｉ信号品質が再び良好な場所の近くに戻った場合など、後でより好ましいネットワークが十分に応答するようになる可能性がある。ダブルタップのアプローチを使用して、現在のネットワークよりも良好なネットワークがプライマリネットワークとして使用可能であることを判定することができるが、これは例えば、ダブルタップリクエストが、使用可能なネットワークにわたって競争すること、ネットワーク品質メトリックを利用すること、又はこれらの組み合わせを継続的に可能にすることによる。新しいプライマリネットワークに切り替えた後でもダブルタップを実行すると、我々は、以前のプライマリネットワークの応答性を確認し、スイッチを最初にトリガした条件の変化を監視することができる。例えば、連続したダブルタップ負けを上回ったためにプライマリネットワークがセルラーに切り替えられた場合、プロキシ１３０は単にＷｉ－Ｆｉへの冗長なリクエストの送信を継続することができ、プロキシ１３０がＷｉ－Ｆｉ上で連続したダブルタップの勝者を検出した場合、プロキシ１３０はプライマリネットワークとしてＷｉ－Ｆｉに再び切り替えることができる。
【0115】
いくつかの実施形態では、使用可能なネットワーク間の優先順位は、コスト、性能、ビジネス関係などの要因の組み合わせに基づいて決定される。これらの要因は、ネットワーク性能（例えば一時的な混雑）又はネットワークトラフィックのコスト（例えばピーク時により高くなる）のように可変であり得るので、優先順位は動的に変化してよい。本発明の実施形態は、静的又は動的な要因の任意の組み合わせを利用して、どのネットワークをいつでも優先するかを考慮することができる。例えば、性能を要因として考慮する場合、使用可能なネットワークのスループットを監視することができる。システム（例えばプロキシ１３０）がネットワークトラフィックを処理しているので、本発明の一実施形態は、次に、現在のネットワーク帯域幅又はシステムを通して流れるトラフィックのレイテンシを能動的に測定し（例えば、現在の率、最近の期間内のピーク率）、それに応じて優先順位を調整する（例えば、セルラーネットワークよりも著しく遅いＷｉ－Ｆｉネットワークは、おそらくセルラーがより好ましいと考えられるように、その相対的ランキングを減少させることができる）ことができる。別の例として、コストを要因として考慮するために、システムは、特定のネットワークを使用するための現在のコストを照会してよい。本発明の一実施形態は、ネットワーク又は何らかのバックエンド管理及び／又は価格システムに対してアプリケーションプログラミングインターフェース（ＡＰＩ）を呼び出して、使用可能なネットワーク（例えば、現在のＷｉ－Ｆｉネットワークやセルラーネットワーク）を使用する現在のコストを問い合わせ、それに応じて優先順位を調整してよい。例えば、これらのコストは動的な場合があり得るが、例えば、ユーザがサードパーティのセルラーネットワークにローミングしている場合、アクセスに課金されるＷｉ－Ｆｉネットワークにアクセスしようとしている場合、又は輻輳に基づいて増加する現在のオンデマンド／スポット価格に基づいて変動する可能性がある場合などである。本発明の実施形態のいくつかの態様において、ユーザ、移動ネットワークオペレータ、又はデバイス製造者などの実体は、特定のランキングを提供することができ（例えば、優先順位の高い特定のネットワークをピン留めする）、又はネットワークの優先順位を組み合わせる際に使用される特定の要因の重みを構成してよい。
【0116】
本発明の前述の実施形態は、ネットワークトラフィックに依存してそれぞれのアクションをトリガすることができるが、例えば、異なるプライマリネットワークへの切り替えや、又は使用可能なネットワークの優先順位の再ランク付け（再編成）などである。場合によっては、所望のアクションをトリガするのに十分なネットワークトラフィックが存在しないかもしれず、例えば、ダブルマップ可能な新しいデータリクエストなしでサーバからデータを受信する長命の暗号化された接続が１つしかない場合などである。本発明の一実施形態では、プロキシ１３０は、応答しないプライマリネットワークの検出をトリガするのに役立つ最小レベルのアクティビティを生成するために、それ自身のダブルタップされたリクエストを生成する。例えば、１つのアプローチは、ダブルタップされた内部から受信した最後のＤＮＳリクエストからの最小時間閾値（例えば数秒）について監視することであり、それを上回った場合、プロキシ１３０は、その最小時間閾値内で不応答のプライマリネットワークを検出するのに役立つテストＤＮＳリクエスト（例えば既知のホスト名）のダブルタップを実行する。その後、ＴＣＰ接続リクエスト（例えばＳＹＮ）のようなダブルキャップされ得る任意のデータリクエストを使用できることは、当業者には明らかである。同様に、これらの単純で軽量なダブルタップテストを使用して、使用可能なネットワークの優先順位の再ランク付けなど、他の必要なアクションをトリガすることができる。
【0117】
負荷バランシング
【0118】
本発明の実施形態のいくつかの態様は、ネットワーク（例えば遅いＷｉ－Ｆｉ接続）上の低速接続の性能を、別のネットワーク（例えばセルラー接続）上の別の接続で向上させることに関する。本発明の様々な実施形態では、負荷バランシングの技術は、１つ以上の使用可能なネットワークに負荷を分散して、ネットワーク全体の性能を向上させることである（例えば帯域幅の拡大、レイテンシの削減）。本発明のいくつかの実施形態は、異なるネットワーク接続の性能を測定し（上述のダブルタップ技術に類似）、より高いスループット又はより少ない輻輳を有するネットワーク接続又はネットワーク接続の組み合わせを選択してよい。このアプローチは、複数のリクエスト又は接続をそれらの性能に基づいて使用可能なネットワークにわたって分配することを可能にするものであり、例えば、各ネットワークの達成可能な最大スループット、各ネットワークの未処理のリクエスト／接続の数、又はそれらの組み合わせに基づいて分配するなどである。本発明の他の実施形態では、すべてのネットワーク接続（例えばＷｉ－Ｆｉ接続とセルラー接続の両方）を同時に使用してデータの異なる部分をダウンロードしてよく、ここで、異なる接続で受信されたデータはデバイスで再結合される。
【0119】
本発明の実施形態は、プライマリのより好ましいネットワークがビジー又は低速である場合に、ネットワークトラフィックをセカンダリのより好ましくないネットワークにいつ分配すべきかを検出することを目的とする。一般に、高速で十分な容量がある場合には、優先ネットワークを使用し、優先ネットワークの容量に達した場合にのみ、他の優先度の低いネットワークを使用することが望ましい。しかし、ネットワーク接続を完全に飽和状態にするのに十分なデータが転送されていない限り、これを正確に判断することは困難であり得る。また、ネットワークを他のユーザと共有する場合（これはＷｉ－Ｆｉネットワークとセルラーネットワークの両方に共通である）、他のユーザが使用する容量は、測定可能なピーク容量を減少させる。このように、いくつかの実施形態は、優先ネットワークの容量にテストトラフィックの生成なしに到達し、そのネットワーク上の他のユーザによって生成されるネットワーク負荷とは独立して動作すると判定することに関する。本発明の一実施形態は、優先ネットワーク上で現在アクティブリクエストを追跡し、その閾値に達した場合に、他の優先度の低いネットワークにリクエストを配信することである。ここでのアクティブリクエストの概念は、任意の論理的なリクエスト／応答のペアであり、これは、クリアテキストトラフィック（例えばＨＴＴＰ ＧＥＴ）と、暗号化されたトラフィック（例えばアウトバウンド暗号化データの送信に応答した暗号化データの受信）の両方に該当し得る。クリアテキストトラフィックの場合、リクエストがもはやアクティブでないと判定することは、完全な応答データの受信に基づくことができる（例えば、ＨＴＴＰ応答は、チャンク転送のためにコンテンツ長ヘッダ又はデータ終端マーカを指定することができる）。暗号化されたトラフィックについては、応答の明示的な終了を識別することができない場合があり、そのため、いくつかの実施形態では、リクエストは、初期データ応答の受信時に完了したものとして扱われる（例えば、サーバからのほとんどの応答は小さく、数秒以内に完了する）。あるいは、暗号化されたデータリクエストの終了を識別するために利用することができる他の信号があるが、例えば、最後に暗号化されたデータチャンクを受信してからの時間が、サーバからのデータチャンク間の典型的な最小時間を上回ったとき（例えば２～３秒）などである。アクティブリクエストを追跡するこのアプローチには、アクティブに処理されている実際のリクエストを有する接続だけを考慮するという利点があり、存続期間が長いがアクティブではない接続（例えば、未使用の接続のプール）を考慮することを回避する。このアプローチはまた、単一の接続を通過するパイプライン化されたリクエストを扱うこともできるが、これは、その各パイプライン化されたリクエストがアウトバウンドデータの連続シーケンスとしてサーバに送信されるからであり、これらの各々は、アクティブリクエスト数をデクリメントするために、サーバからのインバウンドデータの対応するシーケンスが受信されるまで、アクティブリクエスト数をインクリメントすることができる。
【0120】
「アクティブリクエスト」数では、次にプロキシ１３０は、プライマリ優先ネットワーク（例えばＷｉ－Ｆｉ）の閾値を上回ったときはいつでも、新しいリクエストを別のより優先度の低いネットワーク（例えばセルラー）にシフトすることができる。この閾値（例えば最小閾値）は、プライマリネットワークが最初に新しいリクエストに対して試行されるようにネットワークの選択を制御し、これらのアクティブリクエストがこの閾値を上回ることなく迅速に完了した（例えば応答した）場合、プロキシ１３０は、ネットワークトラフィックの大部分を処理する（ｓｅｒｖｉｃｅ）ために、プライマリネットワークを使用する。この閾値に達する度に、プロキシ１３０は次に、本発明の実施形態に従って新しいリクエストを別のネットワークに送り、それに応じて、その別のネットワークに対するアクティブリクエストの数を追跡して使用可能なネットワーク間の負荷のバランスのとれた分散を確立する。
【0121】
本発明の別の実施形態は、アクティブリクエストの数を使用して、各ネットワークに配信するリクエストの比率を確立することである。使用可能なネットワーク間のアクティブリクエストの相対的な比率により、システムは、複数のネットワーク間でアクティブリクエストの分散を維持して、それらのネットワーク間のネットワーク負荷を分散（例えば最適な性能を得るために）することができる。例えば、低速なネットワークでは、高速なネットワークに送信されるリクエストよりも長い時間アクティブなままであるリクエストがある場合があるため、このアプローチでは、各ネットワークの容量を判定するためにテストトラフィックを使用することなしに、複数のネットワークにトラフィックを分散する方法を提供する。本発明の様々な実施形態では、使用可能なネットワークの各々の間で維持されるアクティブリクエストの比率は、静的に構成されるか、動的に計算されるか、又はそれらの組み合わせである。いくつかの実施形態では、アクティブリクエストの比率は、プライマリネットワークの最小閾値と組み合わされ、よってその比率は、最小閾値を現在上回っている場合に、新しいリクエストをネットワーク間に分散するために使用される。
【0122】
図５は、負荷バランシングのアプローチの１つの例示的な方法を示すハイレベルのフローチャート図である。このフローチャートは、ネットワークデータパスの仲介体、例えば図１で説明したアプリケーション２８０とアプリケーションサーバ２５０との間のプロキシ１３０によって実行することができる。本発明の一実施形態に従って、プロキシ１３０は、ステップ４１０で、データリクエストがアプリ２８０からアプリサーバ２５０に送信されるのを待つ。ステップ５５でアプリからデータリクエストが受信されると、プロキシ１３０は、ステップ５２０で、プライマリネットワークがアクティブリクエストの最小閾値を上回ったか否かを判断する。Ｎｏの場合、ステップ５２５で新しいリクエストのためにプライマリネットワークが選択され、ステップ５５５に進む。Ｙｅｓの場合、プロキシ１３０は、優先順位などのようにセカンダリネットワークの各々を反復して、プライマリネットワークに対するアクティブリクエストの比率をチェックすることによって、使用するネットワークを識別又は選択する。ステップ５３５における現在のセカンダリネットワークに対するプライマリネットワークのアクティブリクエストの比率が目標比率より大きい場合、プロキシ１３０は、ステップ５４５で、あたかもそれがプライマリであるかのようにこのリクエストに使用する現在のセカンダリネットワークを選択し、プロキシ１３０はステップ５５５に進む。そうでなければ、プライマリネットワークと現在のセカンダリネットワークとの間のアクティブリクエスト比率が目標比率よりも小さい場合、プロキシ１３０は、ステップ５３０で次のセカンダリネットワークに進む。ステップ５４０に他のセカンダリネットワークが存在しない場合、ステップ５５０でプライマリネットワークが選択され、ステップ５５５に進む。ステップ５５５では、リクエストに対してネットワークが選択されているので、ネットワークに対するアクティブリクエスト数がインクリメントされる。本発明の一実施形態では、ステップ５６０で、負荷バランシングのアプローチがダブルタップのアプローチと組み合わされるが、ここで、不応答である選択されたネットワークに対する冗長性が提供されるように、図３のフローチャートに従ってリクエストが処理される。リクエストが完了すると（例えば、選択されたネットワークから応答が受信されると）、選択されたネットワークのアクティブリクエスト数がデクリメントされる。
【0123】
本発明の実施形態のいくつかの態様は、システムを通して現在流れているネットワークアクティビティによって使用される帯域幅（例えば、平均速度とピーク速度）を監視することによって、テストトラフィックを使用せずに、各ネットワークの速度／帯域幅を測定することに関する。このアプローチにより、システム（例えばプロキシ１３０）は、各ネットワークのこれらの帯域幅の測定値を使用して、これらの使用可能なネットワーク間のアクティブリクエストの適切な比率を計算し、そしてこの比率を維持するために新しいリクエストを各ネットワークに配信することも可能にする。例えば、上記の表１は、各ネットワークの相対速度に基づいて負荷を複数のネットワークに分散することによっていかに全体的な性能を向上できるかを示している。一般に、ネットワークは複数のユーザ間で複数のモバイルデバイス（例えばセルラーやＷｉ－Ｆｉ）によって共有されるため、これらの共有ネットワークの性能は時間の経過とともに変化する可能性がある（例えば、ユーザ間の競合により）。従って、これらの帯域幅の測定値を使用して、使用可能なネットワーク間のアクティブリクエストの比率を動的に監視かつ更新することができる。
【0124】
本発明の実施形態のいくつかの態様は、各ネットワーク（例えば、特定のＷｉ－Ｆｉ ＳＳＩＤとＢＳＳＩＤ、又は特定のセルタワー）について見られる最大帯域幅を、各ネットワークの可能な帯域幅上限として追跡することに関するものであり、これは、アクティブリクエスト比を計算するために使用することができる。例えば、ネットワークのアクティブリクエスト数が増加しているが、測定された帯域幅が増加していない場合は、現在測定されている帯域幅は、ネットワークの現在の上限であるかもしれない。また、本発明の実施形態のいくつかの態様は、測定された帯域幅が可能な上限であるという信頼性を高め、かつ誤検知を回避するために、帯域幅測定の時間枠中に転送されるデータの最小量又は閾値量を使用することに関する。本発明のいくつかの実施形態では、プロキシ１３０は、現在の帯域幅の信頼レベル（又は信頼スコア）を計算するが、これは、現在の測定値の以前の測定値への近接に基づいたり、及び／又は現在の測定値の時間枠中にどれだけのデータが転送されたかに基づいたりする。信頼レベルを有することにより、システムは、アクティブリクエストの比率を更新するために、現在測定されている帯域幅を使用すべきか否かを、例えば比率を更新するために必要な最小の信頼レベルを確立することによって、判断することができる。次に、プロキシ１３０は、データ要求のためのネットワークを選択するとき、現在選択されているネットワークがその帯域幅上限にあるか否かを判断し、帯域幅上限未満の別のネットワークを選択するが、これは、おそらく、アクティブな要求の比率にかかわらず（例えば無効化して）行われる。
【0125】
各ネットワークのアクティブリクエストを追跡することで、ネットワークの容量の変化を動的に検出することもできる。本発明の実施形態のいくつかの態様は、各ネットワークがアクティブリクエストをほぼ同じ時間で完了できる（例えばアクティブリクエスト数を減らす）ように、各ネットワークのリクエストがどのくらいの間アクティブであり続けるかを監視し、かつ各ネットワークのアクティブリクエストの閾値を調整することに関する。例えば、あるネットワークがアクティブリクエストを別のネットワークの倍の速度（例えば２倍高速）で完了していることがわかった場合、アクティブリクエストの比率を調整して、低速なネットワークよりも高速なネットワークに新しいリクエストを倍の数（例えば２倍）送信することができる。各ネットワークのリクエスト完了時間は時間の経過とともに変化する可能性があるため（例えば、共有ネットワーク上の他のユーザによるアクティビティが、時間の経過とともに増加又は減少するために）、これを使用して、使用可能なネットワーク間のアクティブリクエストの比率を動的に調整することができる。いくつかの実施形態では、このアプローチは、使用可能なネットワークのピーク容量又は速度を決定するのに十分なネットワークアクティビティがない（例えばピーク容量を決定するためにテストトラフィックを使用する必要がない）状況で適用される。このアプローチはまた、適切な比率を計算するために各ネットワークの速度測定を使用する前述のアプローチと組み合わせることができるが、これは、各アプローチに重み付けをし、組み合わせた重み付けに基づいてアクティブリクエストの比率を計算することによって行われる。いくつかの実施形態では、各アプローチの相対的な重み付けは、それぞれの信頼度に基づいて調整される。例えば、現在測定されているネットワークの速度は、転送されるデータ量が多いほど正確であるが、一方、リクエストのアクティブ時間の測定は、転送されるデータ量が少ないほど正確であるため、それぞれの重み付けは、これらの要因（例えば、リクエストごとに転送されるバイト数）に基づいて動的に調整できる。
【0126】
上記アプローチのいくつかの実施形態は、例えば、リクエストを送信してから応答の最初のバイトを受信するまでの時間（例えば、アクティブリクエストが完全に完了するのを待たずに最初のバイトまでの時間）を測定することによって、各ネットワークに送信するリクエストの比率を計算するために応答時間又はレイテンシを使用する。このアプローチは、同様の方法（例えば、組み合わせた重み付けの計算）で、速度測定及びリクエストごとのアクティブ時間を考慮する前述のアプローチと組み合わせることもできる。各使用可能なネットワークに分散するアクティブリクエストの最適な比率を決定するために、様々な異なる性能のメトリクスを利用することができることは、当業者には明らかである。
【0127】
前述の閾値又は比率の各々は、システムが各ネットワークに使用する閾値（例えば最良の閾値）を学習するように、ネットワークごとに調整する（例えば個別のＷｉ－Ｆｉ ＳＳＩＤごとに見られる履歴結果に基づいて個別の値を追跡する）こともできる。これにより、システムは、ネットワークが接続される度に、ゼロから開始することなく、ネットワークの動作設定（例えば最適な動作設定）を確立できる。前述の様々な測定値及び計算された比率は、各ネットワーク（例えば、ネットワークのＷｉ－Ｆｉ ＳＳＩＤに従って）について記憶することができ、その特定のネットワークに再接続するたびに復元して、時間の経過とともに継続的に更新することができる。
【0128】
Ｗｉ－Ｆｉ接続管理
【0129】
本発明の実施形態のいくつかの態様は、例えば、より良好な信号品質を有する他のＷｉ－Ｆｉネットワークをチェックし、かつデバイスが「良好な」Ｗｉ－Ｆｉネットワーク接続の範囲内にある場合に、通知を生成するか、又は現在接続されているＷｉ－Ｆｉネットワークからプリエンティブに分離してデバイスをより良好なＷｉ－Ｆｉネットワークに強制的に接続させるかのいずれかによってなどで、Ｗｉ－Ｆｉ接続プロセスの自動化に関する。本発明の実施形態のいくつかの態様は、キャプティブポータル（例えば、企業によって提供されるが、ログイン、パスワード、又は支払い要件の対象となるＷｉ－Ｆｉネットワーク接続）へのログインのプロセスの自動化に関する。
【0130】
本発明の実施形態の一態様は、ポータブル通信デバイス１００による使用可能なネットワークのスキャン（例えばＷｉ－Ｆｉネットワークの再スキャン）を利用して、異なるネットワークに接続し、性能を向上させることに関する。これらの再スキャンは、ユーザが移動したとき、現在のネットワークのＲＳＳＩが変更されたとき、ユーザが使用可能なネットワークのリストを閲覧したときなど、ほとんどのオペレーティングシステムで定期的に発生する。例えば、図３に関して上述したダブルタップがプライマリネットワークスイッチをトリガする場合（例えば、Ｗｉ－Ｆｉネットワークのデッドゾーン内の場合）、現在のネットワークが低速又は不応答であると見なされているので、好ましい種類（例えば、より良いＲＳＳＩを有する別のＷｉ－Ｆｉネットワーク）の異なるネットワークをチェックすることは有益であり得る。別の例として、負荷バランシングが、アクティブリクエストの終了が遅過ぎる（例えば、平均又はより悪いケースの時間が、ある最小閾値を下回っている）と判断する場合がある。
【0131】
トリガに関係なく、現在接続されているネットワークで検出された劣化を使用して、同じ種類の別のネットワークへの切り替えをトリガできる。言い換えると、ダブルタップのアプローチに関する前述の説明は、あるネットワーク種類（例えばＷｉ－Ｆｉ）から別のネットワーク種類（例えば単一のリクエスト用の、又はすべてのリクエストのデフォルト／プライマリとして使用するため）に切り替えることであったが、これは同じ種類の異なるネットワーク間を切り替えるためにさらに一般化することができる。例えば、これは、別のＷｉ－Ｆｉネットワーク（例えばＳＳＩＤが異なる、又は同じＳＳＩＤであるがＢＳＳＩＤが異なる）に切り替える場合に、有用であり、なぜならば、デバイスは典型的には問題が確実に発生するくらい十分に高く設定されるタイムアウト値を使用して問題を検出するのみなので、現在のＷｉ－Ｆｉネットワークが使用できなくなるまでは、別のＷｉ－Ｆｉネットワークに切り替えないからである。しかし、上述のように、これらのタイムアウトは一般的に高過ぎて、よって、ユーザをより良いネットワークにシームレスに移動するには遅過ぎる（例えば、アプリが長時間ハングし、かつ／又はデバイスがより良いネットワークに切り替わる前に、ユーザがエラーメッセージを見るかもしれない）。例えば、ダブルタップのアプローチでは、システムは、ユーザがタイムアウト障害を見るよりも十分前に、好ましい種類の別のネットワークに変更する（例えば現在のＷｉ－Ｆｉネットワークから切断し、別のＷｉ－Ｆｉネットワークに接続する）ために、より迅速な決定を行うことができ、好ましいネットワーク種類の品質／可用性を最大化しながら、より速く、よりシームレスな移行を可能にする。また、異なる無関係なＷｉ－Ｆｉネットワーク間のハンドオフは、ポータブル通信デバイス１００がＷｉ－Ｆｉネットワークに参加して認証するために、長い多段階プロセスを実行する必要があるために遅くなる可能性があり、そのため、ダブルタップのアプローチは、前述のように、この移行中にセルラーを使用することによって、Ｗｉ－ＦｉネットワークからＷｉ－Ｆｉネットワークへのよりシームレスな移行を確保することができる。
【0132】
図６は、複数のＷｉ－Ｆｉネットワークが存在する近傍域の一例を示しており、ここで、各Ｗｉ－Ｆｉネットワークは、良好な信号品質の領域を示す内側円形領域と、不良な信号品質の領域を示す外側円形領域（例えば、Ｗｉ－Ｆｉデッドゾーン）とを有する。例えば、あるＷｉ－Ｆｉネットワーク（例えばＷｉ－Ｆｉネットワーク「Ａ」）の外側ゾーンが、別のＷｉ－Ｆｉネットワーク（例えばＷｉ－Ｆｉネットワーク「Ｂ」）の内側ゾーンと重なると、その結果、Ｗｉ－ＦｉネットワークＡによってＷｉ－ＦｉネットワークＢの使用が妨げられることがあり、例えば、モバイルデバイスが最初にＷｉ－ＦｉネットワークＡに接続された後で、Ｗｉ－ＦｉネットワークＢの方がネットワーク接続が良好な場合でも、Ｗｉ－ＦｉネットワークＡに接続されたままになる場合などである。
【0133】
図７は、図６と同じ例を示すが、本発明の実施形態に従った技術を利用している。ダブルタップ技術により、モバイルデバイス１００が各Ｗｉ－Ｆｉネットワークの外側の使用不能ゾーンにある場合に、関連するＷｉ－Ｆｉネットワークのデッドゾーンにいる間に、セルラーネットワークを利用して自動的にネットワーク接続性を満たすことができる。負荷バランシング技術を使用すると、各Ｗｉ－Ｆｉネットワークの内側使用可能ゾーンは、セルラーネットワークを利用して両方の帯域幅を組み合わせ、全体的な性能を向上させることができる。接続管理技術を用いて、モバイルデバイス１００は、外側デッドゾーン内のダブルタップ論理によって又は内部グッドゾーン内の負荷バランシング論理のいずれかによってトリガされるなど、別のＷｉ－Ｆｉネットワークのスキャンを実行することによって、別のＷｉ－Ｆｉネットワークに自動的に切り替えることができる。
【0134】
本発明は特定の例示的実施形態との関連で説明してきたが、本発明は開示された実施形態に限定されるのではなく、逆に、添付の請求項及びその同等物の精神及び範囲内に含まれる多様な修正及び同等のアレンジメントを網羅することが意図されていることを理解すべきである。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
