(57)【要約】【課題】アプリケーションの体感品質を向上させる。【解決手段】アプリケーションプログラムによるデータ送信の複数のリクエストについて、前記複数のリクエストそれぞれの送信元であるアプリケーションプログラムの実行状況に関する情報を収集し、前記アプリケーションプログラムの実行状況に関する情報に基づいて、優先してデータ送信を許可するリクエストを判定する制御部を備える情報処理装置である。【選択図】図２
2017167637.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションプログラムによるデータ送信の複数のリクエストについて、前記複数のリクエストそれぞれの送信元であるアプリケーションプログラムの実行状況に関する情報を収集し、前記アプリケーションプログラムの実行状況に関する情報に基づいて、優先してデータ送信を許可するリクエストを判定する制御部、
を備える情報処理装置。
【請求項２】
前記制御部は、前記アプリケーションプログラムの実行状況に関する情報として、前記アプリケーションプログラムが、フォアグラウンド又はバックグラウンドのいずれで実行されているかを示す情報を収集し、前記優先してデータ送信を許可するリクエストとして、フォアグラウンドで実行されているアプリケーションプログラムによるデータ送信のリクエストを判定する、
請求項１に記載の情報処理装置。
【請求項３】
アプリケーションプログラムによるデータ送信のリクエストの発生時刻を記憶する記憶部をさらに備え、
前記制御部は、前記記憶部に記憶される前記リクエストの発生時刻にさらに基づいて、前記フォアグラウンドで実行されているアプリケーションプログラムによるリクエストのデータ送信よりも優先して、タイムアウトまでの時間が所定時間長より短いリクエストのデータ送信を許可することを判定する、
請求項２に記載の情報処理装置。
【請求項４】
前記制御部は、前記アプリケーションプログラムによるデータ送信のリクエストの平均発生間隔に基づいて、前記リクエストによる送信対象であるデータの分割送信を判定する、
請求項３に記載の情報処理装置。
【請求項５】
前記制御部は、前記リクエストの送信対象のデータサイズにさらに基づいて、前記フォアグラウンドで実行されているアプリケーションプログラムによるリクエストのデータ送信よりも優先して、前記送信対象のデータサイズが所定値より小さいデータ送信のリクエストの送信許可を判定する、
請求項２から４のいずれか一項に記載の情報処理装置。
【請求項６】
前記制御部は、前記リクエストの宛先に関する情報にさらに基づいて、前記フォアグラウンドで実行されているアプリケーションプログラムによるリクエストのデータ送信よりも優先して、前記リクエストの宛先が所定の宛先であるリクエストのデータ送信の許可を判定する、
請求項２から５のいずれか一項に記載の情報処理装置。
【請求項７】
前記制御部は、前記リクエストが通過する無線ネットワークの帯域の使用状況を取得し、前記無線ネットワークの帯域の使用状況にさらに基づいて、データ送信を許可するリクエストを判定する、
請求項１から６のいずれか一項に記載の情報処理装置。
【請求項８】
端末から、前記アプリケーションプログラムの実行状況に関する情報を含む、前記リクエストの送信許可要求を受信する受信部と、
前記データ送信が許可されたリクエストについて、前記端末に前記リクエストの送信指示を送信する送信部と、
をさらに備える、
請求項１から７のいずれか一項に記載の情報処理装置。
【請求項９】
アプリケーションプログラムによるデータ送信の複数のリクエストについて、前記複数のリクエストそれぞれの送信元であるアプリケーションプログラムの実行状況に関する情報を収集し、前記アプリケーションプログラムの実行状況に関する情報に基づいて、優先してデータ送信を許可するリクエストを判定する所定の装置に、前記アプリケーションプログラムの実行状況に関する情報を含む前記リクエストの送信許可要求を送信する送信部と、
前記所定の装置によって前記リクエストのデータ送信が許可された場合に、前記所定の装置から送信される前記リクエストの送信指示を受信する受信部と、
前記送信指示が受信された場合に、前記リクエストの送信の開始を判定する制御部と、を備える情報処理装置。
【請求項１０】
情報処理装置が、
アプリケーションプログラムによるデータ送信の複数のリクエストについて、前記複数のリクエストそれぞれの送信元であるアプリケーションプログラムの実行状況に関する情報を収集し、前記アプリケーションプログラムに実行状況に関する情報に基づいて、優先してデータ送信を許可するリクエストを判定する、
情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、及び、情報処理方法に関する。
【背景技術】
【０００２】
近年、無線ネットワークが普及し、あらゆる場所において、モバイル端末によってデータの送受信を伴うアプリケーションプログラムを利用することができる。しかしながら、モバイル端末からのアクセスが１か所に集中する状況では、無線ネットワークが輻輳し、遅延が発生することによって、アプリケーションプログラムに対するユーザの体感品質が低下することがある。以降、アプリケーションプログラムを、単に、アプリケーション、アプリ、と称する。
【０００３】
モバイル端末からのアクセスが集中するのは、例えば、以下の場合がある。例えば、イベント会場に集まっている大勢のユーザが、イベントの写真や動画などのサイズの大きいデータをクラウドにアップロードする場合である。また、例えば、電車やバスがトンネルを抜けて通信可能になり、カレンダーや電子メール等のアプリケーションの通信が一斉に開始され、端末側で更新されたデータがアップロードされる場合である。
【０００４】
アプリケーションに対するユーザの体感品質が低下することは、例えば、画面操作の応答が遅いことや、画面表示が遅いことなどがある。例えば、ウェブブラウザのように、インタラクティブなアプリケーションの場合には、無線ネットワークの輻輳による体感品質の低下が顕著である。
【０００５】
無線ネットワークの通信の遅延を抑制する方法の一つに、無線ＬＡＮ（Local Area network）通信の優先制御（IEEE 802.11e）がある。無線ＬＡＮ通信の優先制御では、パケットを優先度付きのキューのいずれかに振り分け、送信タイミングが重なる場合には、優先度の高いキューに格納されているパケットから送信される。これによって、無線ネットワークのトラフィックを平準化し、優先度の高いキューに振り分けられるトラフィックの遅延を抑制することができる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００８−２０４２６８号公報
【特許文献２】特開２００２−１４１９３６号公報
【特許文献３】特開２００８−５９０４０号公報
【非特許文献】
【０００７】
【非特許文献１】“M2M(Machine to Machine)通信向けデータ転送技術「すきま通信」を開発 〜ネットワークやサーバの空いている時間を通信モジュールが探索して有効活用〜”、[online]、２０１１年５月２４日、株式会社ＫＤＤＩ研究所、インターネット＜URL:http://www.kddilabs.jp/press/2011/0524-2.html＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、無線ＬＡＮ通信の優先制御では、ＭＡＣフレームのヘッダの情報に基づいて制御が行われるため、パケットをプロトコル単位で振り分けることはできるものの、アプリケーション単位で振り分けることはできない。アプリケーションの情報は、ＭＡＣフレームのヘッダに含まれていないからである。
【０００９】
例えば、通信プロトコルとしてＨＴＴＰを用いるアプリケーションには、ウェブブラウザと、画像データをアップロードするアプリケーションとがある。ウェブブラウザはインタラクティブなアプリケーションであり、ＨＴＴＰリクエストの送信からＨＴＴＰレスポンスの受信までの時間が長いと、ユーザの体感品質の低下を感じさせる。一方、画像データをアップロードするアプリケーションでは、画像データをサーバにアップロードさせればよく、インタラクティブなアプリケーションではない。
【００１０】
しかしながら、いずれもＨＴＴＰを用いたアプリケーションであるため、無線ＬＡＮの優先制御では、同等に扱われる。そのため、画像データのアップロードするアプリケーションのＨＴＴＰリクエストの処理のために、ウェブブラウザのＨＴＴＰリクエストの処理が遅れる、という事態が発生することがある。
【００１１】
すなわち、無線ＬＡＮ通信の優先制御では、通信を優先させたいアプリケーションがある場合に、同一の通信プロトコルを用いるアプリケーションとの間で、優先度の差をつけることができない。
【００１２】
本発明は、アプリケーションの体感品質を向上可能な情報処理装置、及び、情報処理方法を提供することを目的とする。
【課題を解決するための手段】
【００１３】
１つの態様では、情報処理装置は、アプリケーションプログラムによるデータ送信の複数のリクエストについて、複数のリクエストそれぞれの送信元であるアプリケーションプログラムの実行状況に関する情報を収集し、アプリケーションプログラムの実行状況に関する情報に基づいて、優先してデータ送信を許可するリクエストを判定する制御部、を備える。
【発明の効果】
【００１４】
開示の情報処理装置、及び、情報処理方法によれば、アプリケーションの体感品質を向上することができる。
【図面の簡単な説明】
【００１５】
【図１】図１は、第１実施形態に係る無線通信システムの構成の一例を示す図である。
【図２】図２は、無線通信システムにおけるリクエスト送信制御処理の一例を示す図である。
【図３】図３は、モバイル端末のハードウェア構成の一例を示す図である。
【図４】図４は、プロキシサーバのハードウェア構成の一例を示す図である。
【図５】図５は、モバイル端末の機能構成の一例を示す図である。
【図６】図６は、ＨＴＴＰリクエストのヘッダの一例を示す図である。
【図７】図７は、プロキシサーバの機能構成の一例を示す図である。
【図８】図８は、リクエスト管理テーブルの一例である。
【図９】図９は、モバイル端末のリクエスト送信制御処理のフローチャートの一例である。
【図１０】図１０は、プロキシサーバのリクエスト送信制御処理におけるリクエスト送信許可要求受信時のフローチャートの一例である。
【図１１】図１１は、プロキシサーバのリクエスト送信制御処理におけるＨＴＴＰリクエスト受信時のフローチャートの一例である。
【図１２】図１２は、プロキシサーバのＨＴＴＰリクエストの送信許可判定処理のフローチャートの一例である。
【図１３Ａ】図１３Ａは、モバイル端末＃Ａとモバイル端末＃Ｂとにおいて、ＨＴＴＰリクエストが発生した場合の無線通信システムにおける処理のシーケンスの一例を示す図である。
【図１３Ｂ】図１３Ｂは、モバイル端末＃Ａとモバイル端末＃Ｂとにおいて、ＨＴＴＰリクエストが発生した場合の無線通信システムにおける処理のシーケンスの一例を示す図である。
【図１４】図１４は、第２実施形態に係るリクエスト管理テーブルの一例である。
【図１５】図１５は、第３実施形態に係るプロキシサーバの機能構成の一例を示す図である。
【図１６】図１６は、プロキシサーバのリクエスト発生状況管理テーブルの一例である。
【図１７】図１７は、第３実施形態に係る、プロキシサーバのリクエスト送信制御処理におけるリクエスト送信許可要求受信時のフローチャートの一例である。
【図１８Ａ】図１８Ａは、第３実施形態に係る、プロキシサーバのリクエスト送信制御処理におけるＨＴＴＰリクエスト受信時のフローチャートの一例である。
【図１８Ｂ】図１８Ｂは、第３実施形態に係る、プロキシサーバのリクエスト送信制御処理におけるＨＴＴＰリクエスト受信時のフローチャートの一例である。
【図１９】図１９は、第３実施形態に係る、プロキシサーバのＨＴＴＰリクエストの送信許可判定処理のフローチャートの一例である。
【図２０Ａ】図２０Ａは、第３実施形態に係る、モバイル端末＃Ａとモバイル端末＃Ｂとにおいて、ＨＴＴＰリクエストが発生した場合の無線通信システムにおける処理のシーケンスの一例を示す図である。
【図２０Ｂ】図２０Ｂは、第３実施形態に係る、モバイル端末＃Ａとモバイル端末＃Ｂとにおいて、ＨＴＴＰリクエストが発生した場合の無線通信システムにおける処理のシーケンスの一例を示す図である。
【図２１】図２１は、第４実施形態に係るプロキシサーバの機能構成の一例を示す図である。
【図２２】図２２は、優先度管理テーブルの一例である。
【図２３】図２３は、第５実施形態に係るモバイル端末の機能構成の一例を示す図である。
【図２４Ａ】図２４Ａは、第５実施形態に係るモバイル端末のリクエスト送信制御処理のフローチャートの一例である。
【図２４Ｂ】図２４Ｂは、第５実施形態に係るモバイル端末のリクエスト送信制御処理のフローチャートの一例である。
【図２５】図２５は、第５実施形態に係るモバイル端末の定期的に実行されるＨＴＴＰリクエスト送信制御処理のフローチャートの一例である。
【発明を実施するための形態】
【００１６】
以下、図面に基づいて、本発明の実施の形態を説明する。以下の実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。
【００１７】
＜第１実施形態＞
図１は、第１実施形態に係る無線通信システム１００の構成の一例を示す図である。無線通信システム１００は、複数のモバイル端末１と、プロキシサーバ２と、コンテンツサーバ３とを含む。コンテンツサーバ３は複数であってもよい。モバイル端末１とプロキシサーバ２とは、無線ネットワーク２００に接続している。プロキシサーバ２とコンテンツサーバ３とは、例えば、キャリアの有線又は無線のネットワークに接続している。
【００１８】
図２は、無線通信システム１００におけるリクエスト送信制御処理の一例を示す図である。リクエスト送信制御処理は、モバイル端末１において発生するＨＴＴＰリクエストの
送信タイミングを制御する処理である。リクエスト送信制御処理では、インタラクティブな通信のＨＴＴＰリクエストを非インタラクティブな通信のＨＴＴＰリクエストよりも優先して送信させることで、インタラクティブな通信を伴うアプリケーションの体感品質を向上させる。
【００１９】
無線通信システム１００では、モバイル端末１とコンテンツサーバ３との間で、キャリア側にプロキシサーバ２、モバイル端末１側にプロキシプログラムが備えられ、プロキシサーバ２、プロキシプログラムを介して、通信が行われる。図２では、モバイル端末１Ａとモバイル端末１Ｂとが示されている。モバイル端末１Ａは、フォアグラウンドでブラウザアプリケーションを実行している。モバイル端末１Ｂは、バックグラウンドで写真共有アプリケーションを実行している。
【００２０】
フォアグラウンド、バックグラウンドは、アプリケーションの実行状況に関する情報の一例である。フォアグラウンドで実行されるアプリケーションは、ユーザが現在操作対象としているアプリケーションである。または、フォアグラウンドで実行されるアプリケーションは、ユーザインタフェースを有しているアプリケーションである、とも言える。バックグラウンドで実行されるアプリケーションは、ユーザが現在操作対象としていないが、処理を実行するアプリケーションである。または、バックグラウンドで実行されるアプリケーションは、ユーザインタフェースを有していないアプリケーションである、とも言える。
【００２１】
モバイル端末１では、同時刻に複数のアプリケーションをフォアグラウンドで実行することができず、フォアグラウンドで同時実行可能なアプリケーションの数は、１つである場合が多い。このようなモバイル端末１では、フォアグラウンドで実行中のアプリケーションによって、ディスプレイの大部分が占領される。一方、バックグラウンドでは、複数のアプリケーションを並行して実行可能である。第１実施形態では、アプリケーションがフォアグラウンド又はグラウンドのいずれで実行されているかは、モバイル端末１のＯＳが判定している。
【００２２】
第１実施形態の無線通信システム１００では、インタラクティブな通信の条件を、フォアグラウンドで実行中のアプリケーションの通信であることとする。したがって、第１実施形態では、フォアグラウンドで実行中のアプリケーションによるＨＴＴＰリクエストが、バックグラウンドで実行中のアプリケーションによるＨＴＴＰリクエストよりも優先して送信が許可される。
【００２３】
具体的には、第１実施形態に係るモバイル端末１の処理は、以下の通りである。モバイル端末１Ａ及び１Ｂに搭載されるプロキシプログラムは、それぞれ、アプリケーションによってＨＴＴＰリクエストが発生すると、プロキシサーバ２に、ＨＴＴＰリクエストの送信許可要求を送信する。モバイル端末１Ａ及び１Ｂに搭載されるプロキシプログラムは、プロキシサーバ２から、リクエスト送信指示として、リクエスト送信許可要求に対する応答を受信すると、ＨＴＴＰリクエストの送信を開始する。
【００２４】
また、第１実施形態に係るプロキシサーバ２の処理は、以下の通りである。ＨＴＴＰリクエストの送信許可要求には、アプリケーションの実行状況として、ＨＴＴＰリクエストの生成元のアプリケーションが、フォアグラウンド又はバックグラウンドのいずれで実行中であるかを示す情報が含まれている。プロキシサーバ２は、ＨＴＴＰリクエストの送信許可要求に含まれているアプリケーションの実行状況の情報を収集し、各リクエストのアプリケーションの実行状況に基づいて、フォアグラウンドで実行中のアプリケーションのＨＴＴＰリクエストの送信許可を優先して判定する。
【００２５】
例えば、図２において、モバイル端末１ＡのブラウザによるＨＴＴＰリクエストと、モバイル端末１Ｂの写真共有アプリケーションによるＨＴＴＰリクエストとがほぼ同じタイミングで発生した場合には、モバイル端末１ＡからのＨＴＴＰリクエストが先に送信許可される。モバイル端末１Ａにおいて、ブラウザはフォアグラウンドで実行中であり、モバイル端末１Ｂにおいて、写真共有アプリケーションは、バックグラウンドで実行中であるからである。
【００２６】
一方、モバイル端末１Ｂの写真共有アプリケーションによるＨＴＴＰリクエストは、送信待機状態となり、他にフォアグラウンドで実行中のアプリケーションによるＨＴＴＰリクエストが発生していない状況、又は、無線帯域に余裕のある状況になると、送信許可される。
【００２７】
また、第１実施形態では、プロキシサーバ２は、無線ネットワーク２００の帯域使用状況を監視し、無線ネットワーク２００の帯域使用状況に応じて、送信を許可するＨＴＴＰリクエストを判定する。プロキシサーバ２は、モバイル端末１からのＨＴＴＰリクエストの送信を一元的に管理するので、ＨＴＴＰの通信に関して、無線ネットワーク２００の通信量を平準化することができる。したがって、第１実施形態によれば、ＨＴＴＰの通信による無線ネットワーク２００の輻輳の発生を抑制することができる。ＨＴＴＰリクエストは、「データ送信のリクエスト」の一例である。
【００２８】
＜装置構成＞
図３は、モバイル端末１のハードウェア構成の一例を示す図である。モバイル端末１は、例えば、スマートフォン、タブレット端末、携帯電話端末、ノート型パソコン、その他無線通信機能を有する情報処理装置である。モバイル端末１は、「情報処理装置」の一例である。
【００２９】
モバイル端末１は、ＣＰＵ（Central Processing Unit）１０１、一次記憶憶装置１０
２、二次記憶装置１０３、表示装置１０４、入力装置１０５、無線通信部１０６を備える。また、これらはバスにより互いに電気的に接続されている。
【００３０】
入力装置１０５は、例えば、タッチパネル、操作ボタン等である。また、入力装置１０５は、マイクロフォン等の音声入力装置を含んでもよい。入力装置１０５から入力された信号は、ＣＰＵ  １０１に出力される。
【００３１】
二次記憶装置１０３は、補助記憶装置とも呼ばれ、ＯＳ（Operating System）、様々なプログラムや、各プログラムの実行に際してＣＰＵ  １０１が使用するデータを格納する。二次記憶装置１０３は、例えば、ＥＰＲＯＭ（Erasable Programmable ROM）、フラッ
シュメモリ、又はハードディスクドライブ（Hard Disk Drive）等の不揮発性のメモリで
ある。二次記憶装置１０３は、例えば、通信制御プロキシプログラム１０３Ａ、アプリケーションプログラム１０３Ｂを記憶する。通信制御プロキシプログラム１０３Ａは、モバイル端末１を、例えば、図２のリクエスト送信制御処理において、図２のモバイル端末として動作させるためのプログラムである。
【００３２】
アプリケーションプログラム１０３Ｂは、通信プロトコルを利用して通信を行うアプリケーションプログラムである。第１実施形態では、アプリケーションプログラム１０３Ｂが利用する通信プロトコルは、ＨＴＴＰであることを前提とする。ＨＴＴＰを利用するアプリケーションプログラムには、例えば、ウェブブラウザ、写真共有アプリケーション等がある。ただし、アプリケーションプログラム１０３Ｂが利用する通信プロトコルはＨＴＴＰに限定されない。また、アプリケーションプログラム１０３Ｂが複数である場合には、異なる通信プロトコルを利用するアプリケーションプログラム１０３Ｂが混在してもよ
い。また、１つのアプリケーションプログラム１０３Ｂが利用する通信プロトコルは、1
つに限定されず、１つのアプリケーションプログラム１０３Ｂは、複数の通信プロトコルを利用してもよい。
【００３３】
一次記憶装置１０２は、主記憶装置とも呼ばれ、ＣＰＵ  １０１に、二次記憶装置１０３に格納されているプログラムをロードする記憶領域および作業領域を提供したり、バッファとして用いられたりする記憶装置である。一次記憶装置１０２は、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）のような半導体メモリを含む。
【００３４】
ＣＰＵ  １０１は、二次記憶装置１０３に保持されたＯＳや様々なアプリケーションプログラムを一次記憶装置１０２にロードして実行することによって、様々な処理を実行する。ＣＰＵ  １０１は、１つに限られず、複数備えられてもよい。ＣＰＵ  １０１は、「制御部」の一例である。
【００３５】
無線通信部１０６は、アンテナと無線信号の処理回路とを含む。無線通信部１０６は、無線ＬＡＮ、３ＧＰＰ（3rd Generation Partnership Project）、ＬＴＥ（Long Term Evolution）、ＬＴＥ−ａｄｖａｎｃｅｄ等のいずれかの無線通信方式に対応する。無線通
信部１０６が対応する無線通信方式は、特定の無線通信方式に限定されない。
【００３６】
表示装置１０４は、例えば、液晶ディスプレイである。なお、図３に示されるモバイル端末１のハードウェア構成は、一例であり、上記に限られず、実施の形態に応じて適宜構成要素の省略や置換、追加が可能である。例えば、モバイル端末１は、可搬記録媒体駆動装置を備え、可搬記録媒体に対してデータの読み書きを行ってもよい。可搬記録媒体は、例えば、ＳＤカード、ｍｉｎｉＳＤカード、ｍｉｃｒｏＳＤカード、ＵＳＢ（Universal Serial Bus）フラッシュメモリ、ＣＤ（Compact Disc）、ＤＶＤ(Digital Versatile Disc)、Ｂｌｕ−ｒａｙ（登録商標）  Ｄｉｓｃ、又はフラッシュメモリカードのような記録媒体である。また、モバイル端末１に限られず、例えば、モバイル端末１の代わりに、デスクトップ型のＰＣのような据え置き型の端末であってもよい。
【００３７】
図４は、プロキシサーバ２のハードウェア構成の一例を示す図である。プロキシサーバ２は、例えば、専用又は汎用のコンピュータである。第１実施形態では、プロキシサーバ２は、ＨＴＴＰのプロキシサーバを想定する。
【００３８】
プロキシサーバ２は、ハードウェア構成要素として、ＣＰＵ  ２０１、一次記憶装置２０２、二次記憶装置２０３、表示装置２０４、入力装置２０５、通信インタフェース（ＩＦ）２０６を備え、これらは、バスによって電気的に接続されている。ＣＰＵ  ２０１、一次記憶装置２０２、二次記憶装置２０３、表示装置２０４についての説明は、モバイル端末１のＣＰＵ  １０１、一次記憶装置１０２、二次記憶装置１０３、表示装置１０４と重複する点は省略し、異なる点について説明する。
【００３９】
プロキシサーバ２において、二次記憶装置２０３は、通信タイミング調整プロキシプログラム２０３Ａを記憶する。通信タイミング調整プロキシプログラム２０３Ａは、プロキシサーバ２を、例えば、図２のリクエスト送信制御処理において、図２のプロキシサーバとして動作させるためのプログラムである。
【００４０】
プロキシサーバ２において、入力装置２０５は、例えば、キーボード、マウス等のポインティングデバイス、タッチパネル等である。プロキシサーバ２が、無線ネットワーク２００に直接接続可能な装置である場合には、通信インタフェース２０６は、無線ネットワーク２００の無線通信方式に対応するアンテナと無線信号の処理回路である。プロキシサーバ２が、無線ネットワーク２００を収容する有線ネットワークに接続する場合には、通
信インタフェース２０６は、例えば、ＮＩＣ（Network Interface Card）等の有線ネットワークに接続するインタフェースである。
【００４１】
プロキシサーバ２のハードウェア構成は、図４に示されるものに限定されない。プロキシサーバ２において、表示装置２０４、入力装置２０５は、搭載されていなくてもよく、外付けされてもよい。また、プロキシサーバ２は、可搬記録媒体駆動装置を備え、可搬記録媒体に対して、データの読み書きを行ってもよい。プロキシサーバ２は、「情報処理装置」の一例である。
【００４２】
また、プロキシサーバ２は、例えば、無線ネットワーク２００の無線基地局、無線ネットワークを収容する有線ネットワーク内の中継装置、と同じ装置に搭載されていてもよい。また、第１実施形態では、プロキシサーバ２は、ＨＴＴＰのプロキシサーバであることが想定されるが、プロキシサーバ２は、ＨＴＴＰ以外のＩＰ通信も中継する透過型のプロキシサーバであってもよい。プロキシサーバ２のＣＰＵ  ２０１は、「制御部」の一例である。
【００４３】
図５は、モバイル端末１の機能構成の一例を示す図である。モバイル端末１は、機能構成要素として、リクエスト制御部１１、送信許可問合部１２、情報収集部１３、アプリケーション１９を備える。リクエスト制御部１１、送信許可問合部１２、情報収集部１３は、それぞれ、モバイル端末１のＣＰＵ  １０１が、通信制御プロキシプログラム１０３Ａを実行することによって達成される機能構成要素である。アプリケーション１９は、モバイル端末１のＣＰＵ  １０１が、アプリケーション１０３Ｂを実行することによって達成される機能構成要素である。
【００４４】
リクエスト制御部１１は、アプリケーション１９からＨＴＴＰリクエストの入力を受ける。リクエスト制御部１１は、アプリケーション１９からＨＴＴＰリクエストの入力を受けると、ＨＴＴＰリクエストを待機バッファに格納し、送信許可問合部１２にＨＴＴＰリクエストの送信可否を問い合わせる。待機バッファは、モバイル端末１の一次記憶装置１０２内に生成される。以降、ＨＴＴＰリクエストを生成したアプリケーション１９を、通信元のアプリケーションとも称する。
【００４５】
また、リクエスト制御部１１は、送信許可問合部１２からＨＴＴＰリクエストに対する送信指示の入力を受ける。リクエスト制御部１１は、送信許可問合部１２から、ＨＴＴＰリクエストに対する送信指示の入力を受けると、待機バッファに格納されているＨＴＴＰリクエストをプロキシサーバ２経由で送信する。このとき、リクエスト制御部１１は、例えば、ＨＴＴＰリクエストのヘッダに、リクエスト識別子を含めて送信する。リクエスト識別子は、無線ネットワーク２００内のＨＴＴＰリクエストを識別するための情報であり、プロキシサーバ２によって付与されて通知される。
【００４６】
また、リクエスト制御部１１は、プロキシサーバ２を経由してＨＴＴＰレスポンスを受信する。ＨＴＴＰレスポンスは、ＨＴＴＰリクエストの宛先であるコンテンツサーバ３から送信される。リクエスト制御部１１は、ＨＴＴＰレスポンスを受信すると、受信したＨＴＴＰレスポンスをアプリケーション１９に出力する。なお、リクエスト制御部１１とアプリケーション１９との間は、ソケットによって通信が行われ、リクエスト制御部１１は、ソケットを使用しているプロセスのＩＤによって、アプリケーション１９を識別する。
【００４７】
送信許可問合部１２は、リクエスト制御部１１からＨＴＴＰリクエストの送信可否の問合せを受ける。送信許可問合部１２は、ＨＴＴＰリクエストの送信可否の問合せを受けると、情報収集部１３に、通信元のアプリケーション１９のアプリケーション識別子と実行状況とを問い合わせる。
【００４８】
送信許可問合部１２は、情報収集部１３から、通信元のアプリケーション１９のアプリケーション識別子と実行状況との入力を受ける。送信許可問合部１２は、通信元のアプリケーション１９のアプリケーション識別子と実行状況との入力を受けると、プロキシサーバ２に、リクエスト送信許可要求を送信する。リクエスト送信許可要求には、通信元のアプリケーション１９のアプリケーション識別子と実行状況と、モバイル端末１の識別子とが含まれる。モバイル端末１の識別子には、例えば、ＭＡＣ（Media Access Control）アドレスが用いられる。リクエスト送信許可要求は、「リクエストの送信許可要求」の一例である。
【００４９】
送信許可問合部１２は、プロキシサーバ２から、リクエスト送信許可応答を受信する。リクエスト送信許可応答は、リクエスト送信許可要求に対する応答であり、ＨＴＴＰリクエストの送信指示でもある。リクエスト送信許可応答には、リクエスト識別子が含まれる。送信許可問合部１２は、リクエスト送信許可応答を受信すると、リクエスト制御部１１に、ＨＴＴＰリクエストの送信指示をリクエスト識別子とともに通知する。
【００５０】
情報収集部１３は、送信許可問合部１２からの問合せを受けて、通信元のアプリケーション１９のアプリケーション識別子と実行状況とを取得する。アプリケーションの実行状況は、フォアグラウンド、バックグラウンドのいずれで実行されているかを示す情報である。アプリケーション識別子と実行状況とは、例えば、モバイル端末１のＯＳがＡｎｄｒｏｉｄ（登録商標）である場合には、以下のようにして取得される。アプリケーションの実行状況は、「アプリケーションの実行状況に関する情報」の一例である。
【００５１】
情報収集部１３は、ソケットに接続しているプロセスのプロセスＩＤから通信元のアプリケーション１９のパッケージ名を取得し、パッケージ名をアプリケーション識別子として用いる。アプリケーション１９がフォアグラウンド、バックグラウンドのいずれで実行されているかは、ＯＳが管理している。情報収集部１３は、ＯＳが提供するＡＰＩ（Application Programming Interface）を利用して、通信元のアプリケーション１９のプロセ
スがフォアグラウンド、バックグラウンドのいずれで実行されているかを取得する。
【００５２】
情報収集部１３は、取得した通信元のアプリケーション１９のアプリケーション識別子と実行状況とを、送信許可問合部１２に出力する。
【００５３】
図６は、ＨＴＴＰリクエストのヘッダの一例を示す図である。図６に示されるＨＴＴＰリクエストのヘッダは、リクエスト制御部１１から送信されるＨＴＴＰリクエストのヘッダである。モバイル端末１から送信されるＨＴＴＰリクエストは、プロキシサーバ２を経由させるので、図６に示されるＨＴＴＰリクエストのヘッダには、リクエスト先サーバを示す「Ｈｏｓｔ」のフィールドのホスト名の後ろに「８０８０」が記述されている。「８０８０」はＨＴＴＰのプロキシサーバに宛てて送信する際に用いられるＴＣＰ（Transmission Control Protocol）ポート番号である。
【００５４】
また、図６に示されるＨＴＴＰリクエストのヘッダには、「Ｘ−Ｒｅｑｕｅｓｔ」のフィールドに、通信元のアプリケーション１９のアプリケーション識別子が格納されている。アプリケーション識別子は、モバイル端末１のリクエスト制御部１１によって、ＨＴＴＰリクエストに格納される。
【００５５】
図７は、プロキシサーバ２の機能構成の一例を示す図である。プロキシサーバ２は、機能構成要素として、リクエスト中継部２１、ＮＷ状況管理部２２、送信許可判定部２３、リクエスト管理テーブル２４を含む。リクエスト中継部２１、ＮＷ状況管理部２２、送信許可判定部２３、リクエスト管理テーブル２４は、プロキシサーバ２のＣＰＵ  ２０１が
通信タイミング調整プロキシプログラム２０３Ａを実行することによって達成される機能構成要素である。
【００５６】
リクエスト中継部２１は、無線ネットワーク２００を通じて、モバイル端末１からＨＴＴＰリクエストを受信する。リクエスト中継部２１は、ＨＴＴＰリクエストを受信すると、ＨＴＴＰリクエストの宛先ＵＲＬ（Uniform Resource Locator）のコンテンツサーバ３にＨＴＴＰリクエストを転送する。リクエスト中継部２１は、ＨＴＴＰリクエストの応答であるＨＴＴＰレスポンスをコンテンツサーバ３から受信する。リクエスト中継部２１は、ＨＴＴＰレスポンスを受信すると、ＨＴＴＰリクエストの送信元であるモバイル端末１にＨＴＴＰレスポンスを転送する。また、リクエスト中継部２１は、ＨＴＴＰレスポンスを受信すると、ＨＴＴＰレスポンスの受信と、ＨＴＴＰレスポンスに対応するＨＴＴＰリクエストに含まれているリクエスト識別子とを、送信許可判定部２３に通知する。
【００５７】
ＮＷ状況管理部２２は、無線ネットワーク２００の帯域使用状況を監視する。例えば、ＮＷ状況管理部２２は、無線ネットワーク２００内の無線基地局等に、所定の周期又は送信許可判定部２３からの要求を受けて、無線ネットワーク２００の帯域使用状況を問い合わせて取得する。プロキシサーバ２が、無線基地局としても動作する装置である場合には、ＮＷ状況管理部２２自身が、自装置に備えられている無線通信のドライバ等を用いて、所定の周期で、無線ネットワーク２００の帯域使用状況を測定する。
【００５８】
送信許可判定部２３は、無線ネットワーク２００内に発生しているＨＴＴＰリクエストの送信許可を判定する送信許可判定処理を実行する。送信許可判定部２３は、第１実施形態では、無線ネットワーク２００を通じて、モバイル端末１からリクエスト送信許可要求を受信した場合、送信許可したＨＴＴＰリクエストに対するＨＴＴＰレスポンスが受信された場合、に送信許可判定処理を行う。
【００５９】
送信許可判定処理では、送信許可判定部２３は、無線ネットワーク２００の帯域使用状況とリクエスト管理テーブル２４とに基づいて、送信を許可するＨＴＴＰリクエストを判定する。送信許可判定部２３は、無線ネットワーク２００の帯域使用状況を、ＮＷ状況管理部２２に問い合わせて取得する。リクエスト管理テーブル２４には、無線ネットワーク２００内で送信を待機しているＨＴＴＰリクエストの情報が格納されている。リクエスト管理テーブル２４の詳細は、後述される。
【００６０】
第１実施形態では、送信許可判定部２３は、ＨＴＴＰリクエストについて、以下の優先順で、それぞれの許可条件を満たすＨＴＴＰリクエストの送信を許可する。
（１）タイムアウトの近いＨＴＴＰリクエスト
（２）フォアグラウンドで実行中のアプリケーションのＨＴＴＰリクエスト
（３）バックグラウンドで実行中のアプリケーションのＨＴＴＰリクエスト
【００６１】
第１実施形態では、通信元のアプリケーションの実行状況にかかわらず、タイムアウトの近いＨＴＴＰリクエストが最も優先して許可される。アプリケーションやモバイル端末１によってＨＴＴＰリクエストのタイムアウトの時間は異なる可能性があるものの、ＨＴＴＰにおいてＨＴＴＰリクエストのタイムアウトの初期値（６００秒）が設定されている。第１実施形態では、送信許可判定部２３は、ＨＴＴＰリクエストのタイムアウトの時間長を初期値とみなして、ＨＴＴＰリクエストのタイムアウトの初期値より短い値をタイムアウトの判定閾値とする。
【００６２】
また、送信許可判定部２３は、リクエスト送信許可要求の受信時刻を記録し、リクエスト送信許可要求の受信時刻をＨＴＴＰリクエストの発生時刻とみなす。送信許可判定部２３は、リクエスト送信要求の受信時刻からの経過時間がタイムアウトの判定閾値以上であ
るＨＴＴＰリクエストをタイムアウトの近いＨＴＴＰリクエストとして判定する。
【００６３】
送信許可判定部２３は、上記（１）−（３）の順で、ＨＴＴＰリクエストの送信を優先的に許可する。例えば、無線ネットワーク２００の使用帯域が所定の閾値未満である場合に、待機中のＨＴＴＰリクエストの中から、使用帯域が所定の閾値を超えないように、送信の許可が判定される。使用帯域の閾値は、輻輳と判定される閾値以下の値に設定される。
【００６４】
送信許可判定部２３は、送信許可を判定したＨＴＴＰリクエストのリクエスト送信許可要求の送信元のモバイル端末１に対して、リクエスト送信許可応答を送信する。リクエスト送信許可応答には、該当のＨＴＴＰリクエストに付与されたリクエスト識別子が含まれる。
【００６５】
図８は、リクエスト管理テーブル２４の一例である。リクエスト管理テーブル２４は、無線ネットワーク２００において発生しているＨＴＴＰリクエストの情報を記憶する。リクエス管理テーブル２４は、プロキシサーバ２の一次記憶装置２０２に記憶される。リクエスト管理テーブル２４は、送信許可判定部２３によって管理される。
【００６６】
リクエスト管理テーブル２４のエントリには、リクエスト識別子、端末識別子、アプリケーション識別子、実行状況、受信時刻、状態の項目が含まれる。リクエスト管理テーブル２４の１つのエントリは、無線ネットワーク２００内に発生している１つのＨＴＴＰリクエストに対応している。
【００６７】
リクエスト識別子は、無線ネットワーク２００内に発生しているＨＴＴＰリクエストを一意に識別するための識別子である。リクエスト識別子は、リクエスト送信許可要求が受信されて、リクエスト管理テーブル２４のエントリが生成される際に、送信許可判定部２３によって決定される。
【００６８】
端末識別子は、ＨＴＴＰリクエストの送信元のモバイル端末１を識別するための識別子である。端末識別子には、例えば、モバイル端末１のＭＡＣアドレスが用いられる。端末識別子は、モバイル端末１から送信されるリクエスト送信許可要求に含まれており、リクエスト送信許可要求から取得される。
【００６９】
アプリケーション識別子は、ＨＴＴＰリクエストの生成元のアプリケーションを識別するための識別子である。アプリケーション識別子には、例えば、アプリケーションのパッケージ名や実行ファイル名が用いられる。アプリケーション識別子は、モバイル端末１から送信されるリクエスト送信許可要求に含まれており、リクエスト送信許可要求から取得される。
【００７０】
実行状況は、ＨＴＴＰリクエストの生成元のアプリケーションの、モバイル端末１における実行状況である。「実行状況」の項目には、フォアグラウンド、又は、バックグラウンドのいずれかの値が格納される。実行状況は、モバイル端末１から送信される、リクエスト送信許可要求に含まれており、リクエスト送信許可要求から取得される。
【００７１】
受信時刻は、リクエスト送信許可要求の受信時刻である。受信時刻は、送信許可判定部２３によって記録される。クロックは各モバイル端末１によって異なる場合が多いので、モバイル端末１によって記録された発生時刻では、いずれのＨＴＴＰリクエストが先に発生したかを判定することが難しい。そのため、第１実施形態では、プロキシサーバ２側で記録したリクエスト送信許可要求の受信時刻を、ＨＴＴＰリクエストの発生時刻としてみなして利用する。
【００７２】
状態は、ＨＴＴＰリクエストの状態を示す。状態の項目には、「待機中」、「許可済み」、「送信中」のうち、いずれかの値が格納される。「待機中」は、プロキシサーバ２が、未だＨＴＴＰリクエストに対して送信許可を判定しておらず、モバイル端末１がＨＴＴＰリクエストの送信待機中である状態を示す。「許可済み」は、プロキシサーバ２がＨＴＴＰリクエストに対して送信許可を判定しているものの、モバイル端末１からＨＴＴＰリクエストを受信していない状態を示す。「送信中」は、プロキシサーバ２がＨＴＴＰリクエストを受信し、宛先のサーバに転送済みである状態を示す。
【００７３】
「状態」の項目の初期値は、「待機中」である。送信許可判定部２３によって、ＨＴＴＰリクエストの送信許可が判定されると、「状態」の項目の値は、「待機中」から「許可済み」に更新される。リクエスト中継部２１によって、ＨＴＴＰリクエストが受信され、転送されると、「状態」の項目の値は、「許可済み」から「送信中」に更新される。
【００７４】
リクエスト管理テーブル２４のエントリは、モバイル端末１からリクエスト送信許可要求が受信されると、送信許可判定部２３によって、生成される。また、コンテンツサーバ３からＨＴＴＰリクエストに対するＨＴＴＰレスポンスが受信されると、送信許可判定部２３によって、リクエスト管理テーブル２４のエントリは削除される。なお、リクエスト管理テーブル２４のエントリの項目は、一例であり、実施の形態によって適宜変更可能である。
【００７５】
＜処理の流れ＞
図９は、モバイル端末１のリクエスト送信制御処理のフローチャートの一例である。図９に示される処理は、アプリケーション１９からＨＴＴＰリクエストが入力されると開始される。図９に示される処理の主体は、通信制御プロキシプログラム１０３Ａを実行するモバイル端末１のＣＰＵ  １０１であるが、便宜上、機能構成であるリクエスト制御部１１、送信許可問合部１２、情報収集部１３を主体として説明する。
【００７６】
ＯＰ１では、リクエスト制御部１１は、アプリケーション１９からのＨＴＴＰリクエストの入力を受け、送信許可問合部１２に、ＨＴＴＰリクエストの送信可否の問合せ行う。リクエスト制御部１１は、待機バッファにＨＴＴＰリクエストを格納する。
【００７７】
ＯＰ２では、送信許可問合部１２は、情報収集部１３に、通信元のアプリケーション１９のアプリケーション識別子と、実行状況とを問い合わせ、情報収集部１３からアプリケーション識別子と実行状況とを取得する。
【００７８】
ＯＰ３では、送信許可問合部１２は、プロキシサーバ２に、リクエスト送信許可要求を送信する。リクエスト送信許可要求には、モバイル端末１の端末識別子と、ＯＰ２で取得された通信元のアプリケーション１９のアプリケーション識別子と実行状況とが含まれている。
【００７９】
ＯＰ４では、送信許可問合部１２は、プロキシサーバ２から、リクエスト送信許可応答を受信する。リクエスト送信許可応答には、リクエスト識別子が含まれている。送信許可問合部１２は、リクエスト制御部１１に、ＨＴＴＰリクエストの送信指示を通知する。
【００８０】
ＯＰ５では、リクエスト制御部１１は、待機バッファに格納されているＨＴＴＰリクエストをプロキシサーバ２経由で送信する。このとき、リクエスト制御部１１は、ＨＴＴＰリクエストのヘッダに、プロキシサーバ２から通知されたリクエスト識別子を格納する。
【００８１】
ＯＰ６では、リクエスト制御部１１は、プロキシサーバ２経由で、ＨＴＴＰレスポンス
を受信する。ＯＰ７では、リクエスト制御部１１は、通信元のアプリケーション１９にＨＴＴＰレスポンスを出力する。
【００８２】
図１０は、プロキシサーバ２のリクエスト送信制御処理におけるリクエスト送信許可要求受信時のフローチャートの一例である。図１０に示される処理は、モバイル端末１からリクエスト送信許可要求を受信した場合に開始される。図１０に示される処理の主体は、通信タイミング調整プロキシプログラム２０３Ａを実行するプロキシサーバ２のＣＰＵ  ２０１であるが、便宜上、機能構成である送信許可判定部２３を主体として説明する。
【００８３】
ＯＰ１１では、送信許可判定部２３は、モバイル端末１からリクエスト送信許可要求を受信する。
【００８４】
ＯＰ１２では、送信許可判定部２３は、リクエスト管理テーブル２４に、リクエスト送信許可要求の対象のＨＴＴＰリクエストのエントリを生成して、ＨＴＴＰリクエストの情報を登録する。具体的には、送信許可判定部２３は、リクエスト識別子を取得し、リクエスト管理テーブル２４にエントリを作成する。送信許可判定部２３は、リクエスト送信許可要求から端末識別子、アプリケーション識別子、実行状況を抽出し、リクエスト管理テーブル２４の生成したエントリに格納する。また、送信許可判定部２３は、生成したエントリの「状態」の項目を「待機中」に設定する。また、送信許可判定部２３は、リクエスト送信許可要求の受信時刻を、生成したエントリの「受信時刻」の項目に格納する。
【００８５】
ＯＰ１３では、送信許可判定部２３は、無線ネットワーク２００の帯域使用状況を、ＮＷ状況管理部２２に問い合わせて取得する。
【００８６】
ＯＰ１４では、送信許可判定部２３は、ＨＴＴＰリクエストの送信許可判定処理を行う。ＨＴＴＰリクエストの送信許可判定処理は、送信を許可するＨＴＴＰリクエストを判定する処理である。ＨＴＴＰリクエストの送信許可判定処理の詳細は、後述される。
【００８７】
ＯＰ１５では、送信許可判定部２３は、ＯＰ１１で受信したリクエスト送信許可要求の対象のＨＴＴＰリクエスト（対象リクエスト）以外の、送信許可が判定されたＨＴＴＰリクエストを処理するスレッドに、ＨＴＴＰリクエストの送信許可を通知する。対象リクエスト以外に、送信許可が判定されたＨＴＴＰリクエストがない場合には、ＯＰ１５の処理は省略される。
【００８８】
ＯＰ１６では、送信許可判定部２３は、対象リクエストの送信許可が判定されたか否かを判定する。対象リクエストの送信許可が判定された場合には（ＯＰ１６：ＹＥＳ）、処理がＯＰ１７に進む。対象リクエストの送信許可が判定されていない場合には（ＯＰ１６：ＮＯ）、処理がＯＰ１９に進む。
【００８９】
ＯＰ１７では、送信許可判定部２３は、対象リクエストについて、モバイル端末１にリクエスト送信許可応答を送信する。このとき、リクエスト送信許可応答には、対象リクエストのリクエスト識別子が含まれている。
【００９０】
ＯＰ１８では、送信許可判定部２３は、リクエスト管理テーブル２４の対象リクエストのエントリの「状態」の項目を「許可済み」に変更する。その後、図１０に示される処理が終了する。
【００９１】
ＯＰ１９では、対象リクエストの送信許可が判定されていないので、送信許可判定部２３は、他のスレッドによって対象リクエストの送信許可が判定されることを待機する。他のスレッドによって対象リクエストの送信許可が判定されると、処理がＯＰ１６に進み、
対象リクエストについて、モバイル端末１にリクエスト送信許可応答が送信される。
【００９２】
図１１は、プロキシサーバ２のリクエスト送信制御処理におけるＨＴＴＰリクエスト受信時のフローチャートの一例である。図１１に示される処理は、モバイル端末１からＨＴＴＰリクエストが受信された場合に開始される。図１１に示される処理の主体は、通信タイミング調整プロキシプログラム２０３Ａを実行するプロキシサーバ２のＣＰＵ  ２０１であるが、便宜上、機能構成であるリクエスト中継部２１、ＮＷ状況管理部２２、送信許可判定部２３を主体として説明する。
【００９３】
ＯＰ２１では、送信許可判定部２３は、リクエスト中継部２１から、ＨＴＴＰリクエストの受信の通知を受ける。
【００９４】
ＯＰ２２では、送信許可判定部２３は、ＨＴＴＰリクエストのヘッダから、リクエスト識別子を抽出する。ＯＰ２３では、送信許可判定部２３は、リクエスト管理テーブル２４の、抽出したリクエスト識別子に該当するエントリの「状態」の項目を、「送信中」に変更する。
【００９５】
ＯＰ２４では、リクエスト中継部２１は、ＨＴＴＰリクエストを宛先のＵＲＬに対応するコンテンツサーバ３に転送する。ＯＰ２５では、リクエスト中継部２１は、コンテンツサーバ３から、ＯＰ２４で送信されたＨＴＴＰリクエストに対するＨＴＴＰレスポンスを受信し、モバイル端末１に転送する。
【００９６】
ＯＰ２６では、送信許可判定部２３は、リクエスト管理テーブル２４の、受信されたＨＴＴＰレスポンスに対応するＨＴＴＰリクエストのリクエスト識別子に該当するエントリを削除する。
【００９７】
ＯＰ２７では、送信許可判定部２３は、無線ネットワーク２００の帯域使用状況を、ＮＷ状況管理部２２に問い合わせて取得する。ＯＰ２８では、送信許可判定部２３は、ＨＴＴＰリクエストの送信許可判定処理を行う。
【００９８】
ＯＰ２９では、送信許可判定部２３は、送信許可が判定されたＨＴＴＰリクエストを対象リクエストとするスレッドに、送信許可を通知する。その後、図１１に示される処理が終了する。
【００９９】
図１２は、プロキシサーバ２のＨＴＴＰリクエストの送信許可判定処理のフローチャートの一例である。図１２に示される処理の主体は、通信タイミング調整プロキシプログラム２０３Ａを実行するプロキシサーバ２のＣＰＵ  ２０１であるが、便宜上、機能構成である送信許可判定部２３を主体として説明する。
【０１００】
なお、第１実施形態において、ＨＴＴＰリクエストの許可条件の判定順（優先順）は以下の通りである。
（１）タイムアウトの近いＨＴＴＰリクエスト
（２）フォアグラウンドで実行中のアプリケーションのＨＴＴＰリクエスト
（３）バックグラウンドで実行中のアプリケーションのＨＴＴＰリクエスト
【０１０１】
ＯＰ３１では、送信許可判定部２３は、変数ｎを初期値の１に設定する。変数ｎは、ＨＴＴＰリクエストの許可条件の順番を示す。
【０１０２】
ＯＰ３２では、送信許可判定部２３は、ｎ番目の許可条件を満たすＨＴＴＰリクエストを、リクエスト管理テーブル２４の「待機中」のエントリから送信許可候補として選択す
る。
【０１０３】
ＯＰ３３では、送信許可判定部２３は、使用予定帯域が閾値１より大きいか否かを判定する。使用予定帯域は、現在の使用帯域に、送信許可候補として選択されたＨＴＴＰリクエストの送信によって消費が予定される帯域を加算したものである。第１実施形態では、１つのＨＴＴＰリクエストの送信によって消費される帯域を、固定値とみなして、使用予定帯域が算出される。閾値１は、無線ネットワーク２００が輻輳と判定される閾値以下の値に設定される。
【０１０４】
使用予定帯域が閾値１より大きい場合には（ＯＰ３３：ＹＥＳ）、処理がＯＰ３４に進む。使用予定帯域は閾値１以下である場合には（ＯＰ３３：ＮＯ）、処理がＯＰ３５に進む。
【０１０５】
ＯＰ３４では、使用予定帯域が閾値１より大きいので、送信許可判定部２３は、所定数のＨＴＴＰリクエストを送信許可候補から削除する。その後、処理がＯＰ３３に進む。削除するＨＴＴＰリクエストの数は、予め決められた数であってもよいし、ＯＰ３４の処理が行われる度に１つずつ増えてもよいし、使用予定帯域と閾値１との差分から算出されてもよい。
【０１０６】
ＯＰ３５では、送信許可判定部２３は、送信許可候補のＨＴＴＰリクエストの送信許可を確定する。
【０１０７】
ＯＰ３６では、送信許可判定部２３は、使用予定帯域が閾値２以下であるか否かを判定する。閾値２は、閾値１よりも小さい値である。例えば、閾値２は、閾値１から、１つのＨＴＴＰリクエストの送信によって消費されるとみなされる帯域を減じた値である。ＯＰ３６は、さらにＨＴＴＰリクエストの送信を許可できる程の空き帯域が無線ネットワーク２００にあるか否かを判定する処理である。使用予定帯域が閾値２以下である場合には（ＯＰ３６：ＹＥＳ）、処理がＯＰ３７に進む。使用予定帯域は閾値２より大きい場合には（ＯＰ３６：ＮＯ）、図１２に示される処理が終了する。
【０１０８】
ＯＰ３７では、送信許可判定部２３は、変数ｎがＮであるか否かを判定する。Ｎは、許可条件の数である。変数ｎがＮである場合には（ＯＰ３７：ＹＥＳ）、図１２に示される処理が終了する。変数ｎがＮでない場合には（ＯＰ３７：ＮＯ）、処理がＯＰ３８に進む。
【０１０９】
ＯＰ３８では、送信許可判定部２３は、変数ｎに１を加算して、変数ｎを更新する。その後、処理がＯＰ３２に進み、許可条件ｎについて、ＯＰ３２からＯＰ３７の処理が行われる。
【０１１０】
なお、図９から図１２に示されるフローチャートは、一例であり、実施の形態に応じて、各処理の実行順等は、適宜、変更可能である。
【０１１１】
＜具体例＞
図１３Ａ及び図１３Ｂは、モバイル端末＃Ａとモバイル端末＃Ｂとにおいて、ＨＴＴＰリクエストが発生した場合の無線通信システム１００における処理のシーケンスの一例を示す図である。モバイル端末＃Ａでは、バックグラウンドで実行され、オンラインストレージにデータをアップロードするアプリケーションのＨＴＴＰリクエストが発生することを想定する。モバイル端末＃Ｂでは、フォアグラウンドで実行されるブラウザのアプリケーションのＨＴＴＰリクエストが発生することを想定する。
【０１１２】
Ｓ１では、モバイル端末＃Ａのオンラインストレージアプリケーションによって、ＨＴＴＰリクエストが発生する（図９、ＯＰ１）。Ｓ２では、モバイル端末＃Ａは、オンラインストレージアプリケーションの、アプリケーション識別子、実行状況を収集する（図９、ＯＰ２）。
【０１１３】
Ｓ３では、モバイル端末＃Ａは、プロキシサーバ２にリクエスト送信許可要求を送信する（図９、ＯＰ３）。Ｓ３において送信されるリクエスト送信許可要求には、オンラインストレージアプリケーションのアプリケーション識別子、実行状況としてバックグラウンド、モバイル端末＃Ａの端末識別子が含まれている。
【０１１４】
Ｓ４では、プロキシサーバ２は、モバイル端末＃Ａからのリクエスト送信許可要求を受信し（図１０、ＯＰ１１）、リクエスト識別子＃１として、リクエスト管理テーブル２４にエントリを登録する（図１０、ＯＰ１２）。Ｓ５では、プロキシサーバ２は、無線ネットワーク２００の帯域使用状況を取得する（図１０、ＯＰ１３）。
【０１１５】
Ｓ６では、プロキシサーバ２は、ＨＴＴＰリクエストの送信許可判定処理を行う（図１０、ＯＰ１４）。ここでは、無線ネットワーク２００の帯域使用状況と、オンラインストレージアプリケーションがバックグラウンドで実行中であることから、モバイル端末＃ＡのＨＴＴＰリクエストは、送信許可されないことを想定する。リクエスト管理テーブル２４の該当のエントリの「状態」の項目は、「待機中」となる。
【０１１６】
Ｓ７では、モバイル端末＃Ｂのブラウザにおいて、ＨＴＴＰリクエストが発生する（図９、ＯＰ１）。Ｓ８では、モバイル端末＃Ｂは、ブラウザアプリケーションのアプリケーション識別子、実行状況を収集する（図９、ＯＰ２）。
【０１１７】
Ｓ９では、モバイル端末＃Ｂは、プロキシサーバ２にリクエスト送信許可要求を送信する（図９、ＯＰ３）。Ｓ９において送信されるリクエスト送信許可要求には、ブラウザアプリケーションのアプリケーション識別子、実行状況としてフォアグラウンド、モバイル端末＃Ｂの端末識別子が含まれている。
【０１１８】
Ｓ１０では、プロキシサーバ２は、モバイル端末＃Ｂからのリクエスト送信許可要求を受信し（図１０、ＯＰ１１）、リクエスト識別子＃２として、リクエスト管理テーブル２４にエントリを登録する（図１０、ＯＰ１２）。Ｓ１１では、プロキシサーバ２は、無線ネットワーク２００の帯域使用状況を取得する（図１０、ＯＰ１３）。
【０１１９】
Ｓ１２では、プロキシサーバ２は、ＨＴＴＰリクエストの送信許可判定処理を行う（図１０、ＯＰ１４）。ここでは、ブラウザのアプリケーションがフォアグラウンドで実行中であることから、モバイル端末＃ＢのＨＴＴＰリクエストは、送信許可されることを想定する。リクエスト管理テーブル２４の該当のエントリの「状態」の項目は、「許可済み」となる。
【０１２０】
Ｓ１３では、プロキシサーバ２は、モバイル端末＃Ｂに、リクエスト送信許可応答を送信する（図１０、ＯＰ１６：ＹＥＳ、ＯＰ１７）。リクエスト送信許可応答には、リクエスト識別子＃２が含まれている。
【０１２１】
Ｓ１４では、モバイル端末＃Ｂは、リクエスト送信許可応答を受信し（図９、ＯＰ４）、ブラウザのＨＴＴＰリクエストを送信する（図９、ＯＰ５）。ブラウザのＨＴＴＰリクエストのヘッダには、リクエスト識別子＃２が含まれている。
【０１２２】
Ｓ１５では、プロキシサーバ２は、ＨＴＴＰリクエストを受信し（図１１、ＯＰ２１）
、リクエスト識別子＃２に該当するリクエスト管理テーブル２４のエントリの「状態」の項目を「許可済み」から「送信中」に変更する（図１１、ＯＰ２３）。
【０１２３】
図１３ＢのＳ１６では、プロキシサーバ２は、ＨＴＴＰリクエストを宛先のコンテンツサーバ３に転送する（図１１、ＯＰ２４）。Ｓ１７では、プロキシサーバ２はコンテンツサーバから、ＨＴＴＰレスポンスを受信する（図１１、ＯＰ２５）。Ｓ１８では、プロキシサーバ２は、ＨＴＴＰレスポンスをモバイル端末＃Ｂに転送する。
【０１２４】
Ｓ１９では、プロキシサーバ２は、リクエスト識別子＃２に該当するリクエスト管理テーブル２４のエントリを削除する（図１１、ＯＰ２６）。Ｓ２０では、プロキシサーバ２は、無線ネットワーク２００の帯域使用状況を取得する（図１１、ＯＰ２７）。
【０１２５】
Ｓ２１では、プロキシサーバ２は、ＨＴＴＰリクエストの送信許可判定処理を行う（図１１、ＯＰ２８）。ここでは、モバイル端末＃ＢのＨＴＴＰリクエストの通信が終了したことによって空いた帯域に、バックグラウンドで実行中のモバイル端末＃ＡのＨＴＴＰリクエストが、送信許可されることを想定する。リクエスト管理テーブル２４の該当のエントリの「状態」の項目は、「待機中」から「許可済み」に更新される（図１０、ＯＰ１８）。
【０１２６】
Ｓ２２では、プロキシサーバ２は、モバイル端末＃Ａに、リクエスト送信許可応答を送信する（図１０、ＯＰ１６：ＹＥＳ、ＯＰ１７）。リクエスト送信許可応答には、リクエスト識別子＃１が含まれている。
【０１２７】
Ｓ２３では、モバイル端末＃Ａは、リクエスト送信許可応答を受信し（図９、ＯＰ４）、オンラインストレージアプリケーションのＨＴＴＰリクエストを送信する（図９、ＯＰ５）。オンラインストレージアプリケーションのＨＴＴＰリクエストのヘッダには、リクエスト識別子＃１が含まれている。
【０１２８】
Ｓ２４では、プロキシサーバ２は、ＨＴＴＰリクエストを受信し（図１１、ＯＰ２１）、リクエスト識別子＃１に該当するリクエスト管理テーブル２４のエントリの状態の項目を「許可済み」から「送信中」に変更する（図１１、ＯＰ２３）。
【０１２９】
Ｓ２５では、プロキシサーバ２は、ＨＴＴＰリクエストを宛先のコンテンツサーバ３に転送する（図１１、ＯＰ２４）。Ｓ２６では、プロキシサーバ２はコンテンツサーバから、ＨＴＴＰレスポンスを受信する（図１１、ＯＰ２５）。Ｓ２７では、プロキシサーバ２は、ＨＴＴＰレスポンスをモバイル端末＃Ａに転送する。
【０１３０】
Ｓ２８では、プロキシサーバ２は、リクエスト識別子＃１に該当するリクエスト管理テーブル２４のエントリを削除する（図１１、ＯＰ２６）。以降、再度無線ネットワークの使用帯域の取得が行われ、ＨＴＴＰリクエストの送信許可判定処理が行われる。
【０１３１】
図１３Ａ及び図１３Ｂに示されるように、無線通信システム１００では、バックグラウンドで実行中のオンラインストレージアプリケーションのＨＴＴＰリクエストよりもフォアグラウンドで実行中のブラウザのＨＴＴＰリクエストが優先され、先に送信許可される。
【０１３２】
＜第１実施形態の作用効果＞
第１実施形態では、ＨＴＴＰリクエストが発生すると、モバイル端末１は、通信元のアプリケーションの実行状況を取得し、リクエスト送信許可要求とともにプロキシサーバ２に送信する。プロキシサーバ２は、通信元のアプリケーションの実行状況に応じて、ＨＴ
ＴＰリクエストの送信許可を判定する。アプリケーションの実行状況に応じて、優先して送信許可されるＨＴＴＰリクエストが判定されるので、優先されたアプリケーションの体感品質を向上させることができる。
【０１３３】
また、第１実施形態では、フォアグラウンドで実行中のアプリケーションを、インタラクティブなアプリケーションとする。プロキシサーバ２は、バックグラウンドで実行中のアプリケーションによるＨＴＴＰリクエストよりも優先して、フォアグラウンドで実行中のアプリケーションのＨＴＴＰリクエストの送信許可を判定する。これによって、インタラクティブなアプリケーションのＨＴＴＰリクエストが優先して送信許可されるので、インタラクティブなアプリケーションの体感品質の低下を抑制することができる。バックグラウンドで実行中のＨＴＴＰリクエストは、無線ネットワーク２００の帯域に余裕のあるときに送信許可されることになる。これによって、無線ネットワーク２００のＨＴＴＰのトラフィックを平準化することができ、輻輳の発生を抑制することができる。
【０１３４】
タイムアウトの近いＨＴＴＰリクエストは、実行状況にかかわらず、最も優先して送信許可が判定される。これによって、ＨＴＴＰリクエストのタイムアウトを抑制することができる。無線ネットワーク２００の帯域の使用状況に基づいて、送信許可するリクエストが判定される。これによって、無線ネットワーク２００の輻輳発生を抑制することができる。
【０１３５】
また、第１実施形態では、モバイル端末１に、通信制御プロキシプログラム１０３Ａをインストールすればよく、既存のアプリケーションに変更を加えなくてよいため、実装が容易である。
【０１３６】
＜第２実施形態＞
第２実施形態では、第１実施形態のＨＴＴＰリクエストの許可条件に、さらに、ＨＴＴＰリクエストのボディ部のサイズも加える。第２実施形態では、第１実施形態と重複する説明は省略される。第２実施形態では、ＨＴＴＰリクエストのボディ部のサイズが小さい通信はインタラクティブ性が高い通信であるとみなされ、ＨＴＴＰリクエストのボディ部のサイズが大きい通信はインタラクティブ性が低い通信とみなされる。以降、単に、ＨＴＴＰリクエストのサイズ、という場合には、ＨＴＴＰリクエストのボディ部のサイズを示す。
【０１３７】
第２実施形態では、モバイル端末１、プロキシサーバ２のハードウェア構成、機能構成は、第１実施形態と同様である。第２実施形態では、ＨＴＴＰリクエストの許可条件にＨＴＴＰリクエストのサイズも含まれるため、以下の点が追加される。
【０１３８】
モバイル端末１の送信許可問合部１２は、リクエスト送信許可要求に、通信元のアプリケーション１９のアプリケーション識別子及び実行状況、端末識別子に加えて、ＨＴＴＰリクエストのサイズを含める。プロキシサーバ２の送信許可判定部２３は、リクエスト送信許可要求に含まれる、通信元のアプリケーション１９のアプリケーション識別子及び実行状況、端末識別子、ＨＴＴＰリクエストのサイズをリクエスト管理テーブル２４に登録する。
【０１３９】
第２実施形態における、プロキシサーバ２の送信許可判定部２３のＨＴＴＰリクエストの許可条件、及び、許可条件の優先順は、以下の通りである。
（１）タイムアウトの近いＨＴＴＰリクエスト
（２）サイズの小さいＨＴＴＰリクエスト
（３）フォアグラウンドで実行中のアプリケーションのＨＴＴＰリクエスト
（４）バックグラウンドで実行中のアプリケーションのＨＴＴＰリクエスト
【０１４０】
許可条件（２）では、所定の閾値よりも小さいサイズのＨＴＴＰリクエストが、通信元のアプリケーションの実行状況にかかわらず、送信許可を判定される。ＨＴＴＰリクエストのサイズが小さい場合、消費される帯域が少ないので、アプリケーションがバックグラウンドで実行中であったとしても、優先して送信される。また、フォアグラウンドで実行中のアプリケーションであったとしても、ＨＴＴＰリクエストのサイズが大きい場合には、インタラクティブ性が低いため、送信タイミングを遅らせられる。
【０１４１】
図１４は、第２実施形態に係るリクエスト管理テーブル２４の一例である。第２実施形態では、リクエスト管理テーブル２４のエントリに、「サイズ」の項目が追加される。「サイズ」の項目には、ＨＴＴＰリクエストのサイズが格納される。ＨＴＴＰリクエストのサイズは、モバイル端末１からのリクエスト送信許可要求に含まれている。
【０１４２】
第２実施形態では、プロキシサーバ２の送信許可判定部２３は、ＨＴＴＰリクエストの送信許可判定処理（図１２）において、ＨＴＴＰリクエストのサイズに応じて、各ＨＴＴＰリクエストの送信によって消費される帯域を推定し、使用予定帯域を算出する。ＨＴＴＰリクエストの送信による帯域の消費を、一様な値とせずに、ＨＴＴＰリクエストのサイズに応じて推定された値を用いることによって、使用予定帯域をより実際の消費帯域に近い値で算出することができる。これによって、無線ネットワーク２００の帯域をより有効に活用することができる。
【０１４３】
なお、ＨＴＴＰリクエストの許可条件は、一例であって、限定されない。例えば、許可条件（２）は、例えば、（２Ａ）フォアグラウンドで実行中のアプリケーションで、サイズの小さいＨＴＴＰリクエスト、（２Ｂ）バックグラウンドで実行中のアプリケーションで、サイズの小さいＨＴＴＰリクエストと、細分化して設定されてもよい。
【０１４４】
＜第３実施形態＞
第３実施形態では、アプリケーションのＨＴＴＰリクエストの発生間隔に応じて、ＨＴＴＰリクエストを分割して複数回に分けてコンテンツサーバ３に送信する。第３実施形態では、第１実施形態、第２実施形態と重複する説明は省略される。
【０１４５】
ＨＴＴＰリクエストは、送信データ（ボディ部）のサイズの大きさにかかわらず、１回で送信することが想定されている。そのため、サイズの大きなＨＴＴＰリクエストの送信が開始されると、フォアグラウンドで実行されているアプリケーションからＨＴＴＰリクエストが発生しても、先のＨＴＴＰリクエストの送信が終わらないと、帯域が確保されず、後発のＨＴＴＰリクエストを送信できない場合がある。
【０１４６】
第３実施形態では、アプリケーションのＨＴＴＰリクエストの発生間隔によって、ＨＴＴＰリクエストの分割サイズが決定される。分割サイズは、１回のＨＴＴＰリクエストの送信で送信可能なデータサイズである。例えば、アプリケーションのＨＴＴＰリクエストの発生間隔が短い（発生頻度が高い）場合には、後発のＨＴＴＰリクエストが割り込める機会を増やすために、分割サイズが小さく設定される。例えば、アプリケーションのＨＴＴＰリクエストの発生間隔が長い（発生頻度が低い）場合には、分割送信による通信のオーバヘッドやバッテリ消費を抑えるため、分割サイズが大きく設定される。これによって、後発の優先度の高いＨＴＴＰリクエストの割り込みを可能にして、インタラクティブなアプリケーションの体感品質を向上させる。
【０１４７】
第３実施形態では、モバイル端末１のハードウェア構成、機能構成は、第２実施形態と同様である。プロキシサーバのハードウェア構成は、第１実施形態と同様である。
【０１４８】
図１５は、第３実施形態に係るプロキシサーバ２Ｂの機能構成の一例を示す図である。プロキシサーバ２Ｂは、機能構成要素として、リクエスト中継部２１、ＮＷ状況管理部２２、送信許可判定部２３、リクエスト管理テーブル２４に加えて、リクエスト発生状況管理部２５、リクエスト発生状況管理テーブル２６を備える。リクエスト発生状況管理部２５、リクエスト発生状況管理テーブル２６も、プロキシサーバ２ＢのＣＰＵ  ２０１が通信タイミング制御プロキシプログラム２０３Ａを実行することによって達成される機能構成要素の一つである。
【０１４９】
第３実施形態では、送信許可判定部２３は、モバイル端末１からリクエスト送信許可要求を受信すると、リクエスト発生状況管理部２５にリクエスト送信許可要求の受信を通知する。リクエスト発生状況管理部２５は、送信許可判定部２３からリクエスト発生許可要求を受信すると、リクエスト発生状況管理テーブル２５に、ＨＴＴＰリクエストの発生時刻と、アプリケーション識別子、実行状況を登録する。リクエスト発生状況管理テーブル２６の詳細は後述される。
【０１５０】
リクエスト発生状況管理部２５は、リクエスト発生状況管理テーブル２６に基づいて、例えば、アプリケーションのＨＴＴＰリクエストの平均発生間隔を求める。リクエスト発生状況管理部２５は、送信許可判定部２３からの問い合わせに応じて、ＨＴＴＰリクエストの平均発生間隔を算出する。
【０１５１】
送信許可判定部２３は、タイムアウトまでの時間、アプリケーションの実行状況、ＨＴＴＰリクエストの平均発生間隔、ＨＴＴＰリクエストのサイズに基づいて、送信許可するＨＴＴＰリクエスト、ＨＴＴＰリクエストのサイズ等を判定する。第３実施形態におけるＨＴＴＰリクエストの送信許可判定処理の詳細は、後述される。
【０１５２】
送信許可判定部２３は、送信許可を判定したＨＴＴＰリクエストについて、モバイル端末１にリクエスト送信許可応答を送信する。第３実施形態では、リクエスト送信許可応答には、リクエスト識別子、ＨＴＴＰリクエストの送信データ（ボディ部）のサイズが含まれる。
【０１５３】
モバイル端末１のリクエスト制御部１１は、第３実施形態では、送信許可問合部１２から、リクエスト識別子と、送信データのサイズとを含む送信指示の入力を受ける。リクエスト制御部１１は、ＨＴＴＰリクエストで送信するデータを、指定のサイズ分にし、ヘッダ内にリクエスト識別子を格納して、プロキシサーバ２Ｂに送信する。
【０１５４】
第３実施形態では、プロキシサーバ２Ｂのリクエスト管理テーブル２４のエントリの項目は、第２実施形態と同様である。ただし、「状態」の項目の値は、「待機中」、「許可済み」、「受信中」、「送信中」のうちいずれかの値が格納される。初期値は、「待機中」である。
【０１５５】
「受信中」は、ＨＴＴＰリクエストの分割されたデータの一部分について、受信済みである状態である。分割されたデータを含むＨＴＴＰリクエストを受信すると、「許可済み」から「受信中」に「状態」の項目の値が更新される。その後、再度ＨＴＴＰリクエストについて送信許可されると「受信中」から「許可済み」に「状態」の項目の値が更新される。ＨＴＴＰリクエストのデータがすべて受信され、ＨＴＴＰリクエストがコンテンツサーバに転送されると、「許可済み」から「受信中」を経て、「送信中」に「状態」の項目が更新される。
【０１５６】
また、「サイズ」の項目には、未送信のＨＴＴＰリクエストのデータ（ボディ部）のサイズが格納される。分割されたデータを含むＨＴＴＰレスポンスが受信されると、該当の
エントリの「サイズ」の項目の値は、受信したＨＴＴＰレスポンスに含まれるデータのサイズ分減じた値に更新される。ＨＴＴＰリクエストのボディ部がすべて取得されると、リクエスト管理テーブル２４のエントリの「サイズ」の値が０になる。
【０１５７】
図１６は、プロキシサーバ２Ｂのリクエスト発生状況管理テーブル２６の一例である。リクエスト発生状況管理テーブル２６は、無線ネットワーク２００内のＨＴＴＰリクエストの発生履歴を、過去一定時間分、記憶する。リクエスト発生状況管理テーブル２６は、プロキシサーバ２Ｂの一次記憶装置２０２に記憶される。リクエスト発生状況管理テーブル２６は、リクエスト発生状況管理部２５によって管理される。リクエスト発生状況管理テーブル２６のエントリには、リクエスト受信時刻、アプリケーション識別子、実行状況の項目が含まれる。これらの項目は、リクエスト管理テーブル２４の項目と同じ情報が格納される。
【０１５８】
リクエスト発生状況管理部２５は、アプリケーションのＨＴＴＰリクエストの平均発生間隔を、例えば、リクエスト発生状況管理テーブル２６内の、全エントリの受信時刻の間隔の合計値を全エントリの数で割って求める。または、リクエスト発生状況管理部２５は、アプリケーションのＨＴＴＰリクエストの平均発生間隔を、特定のエントリを選択して、算出してもよい。例えば、リクエスト発生状況管理部２５は、リクエスト発生状況管理テーブル２６内の、アプリケーション識別子と実行状況とが一致するエントリの受信時刻の間隔の合計値を該エントリの数で割って求めてもよい。
【０１５９】
図１７は、第３実施形態に係る、プロキシサーバ２Ｂのリクエスト送信制御処理におけるリクエスト送信許可要求受信時のフローチャートの一例である。図１７に示される処理は、モバイル端末１からリクエスト送信許可要求が受信された場合に開始される。図１７に示される処理の主体は、通信タイミング調整プロキシプログラム２０３Ａを実行するプロキシサーバ２ＢのＣＰＵ  ２０１であるが、便宜上、機能構成である送信許可判定部２３を主体として説明する。
【０１６０】
ＯＰ４１では、送信許可判定部２３は、無線ネットワーク２００を通じて、モバイル端末１からリクエスト送信許可要求を受信する。
【０１６１】
ＯＰ４２では、送信許可判定部２３は、リクエスト管理テーブル２４に、リクエスト送信許可要求の対象のＨＴＴＰリクエストのエントリを生成して、ＨＴＴＰリクエストの情報を登録する。具体的には、送信許可判定部２３は、リクエスト識別子を取得し、リクエスト管理テーブル２４にエントリを作成する。送信許可判定部２３は、リクエスト送信許可要求から端末識別子、アプリケーション識別子、実行状況、ＨＴＴＰリクエストのサイズを抽出し、リクエスト管理テーブル２４の生成したエントリに格納する。また、送信許可判定部２３は、生成したエントリの「状態」の項目を「待機中」に設定する。また、送信許可判定部２３は、リクエスト送信許可要求の受信時刻を、生成したエントリの「受信時刻」に記録する。
【０１６２】
ＯＰ４３では、送信許可判定部２３は、無線ネットワーク２００の帯域使用状況を、ＮＷ状況管理部２２に問い合わせて取得する。
【０１６３】
ＯＰ４４では、送信許可判定部２３は、リクエスト発生状況管理部２５に、アプリケーションのＨＴＴＰリクエストの平均発生間隔を問い合わせ、取得する。リクエスト発生状況管理部２５は、ＯＰ４１で受信されたリクエスト送信許可要求の情報を、リクエスト発生状況管理テーブル２６に登録し、送信許可判定部２３の問い合わせに応じて、アプリケーションのＨＴＴＰリクエストの平均発生間隔を算出して、通知する。また、優先度の低いリクエストの発生時のみ、割り込みを許すようにしても良く、その場合は特定のアプリ
ケーション識別子や実行状況を持つリクエストの平均発生間隔を算出する。
【０１６４】
ＯＰ４５では、送信許可判定部２３は、ＨＴＴＰリクエストの送信許可判定処理を行う。ＨＴＴＰリクエストの送信許可判定処理の詳細は、後述される。
【０１６５】
ＯＰ４６では、送信許可判定部２３は、ＯＰ４１で受信したリクエスト送信許可要求の対象のＨＴＴＰリクエスト（対象リクエスト）以外の、送信許可が判定されたＨＴＴＰリクエストを処理するスレッドにリクエストの送信許可を通知する。対象リクエスト以外に、送信許可が判定されたＨＴＴＰリクエストがない場合には、ＯＰ４６の処理は省略される。
【０１６６】
ＯＰ４７では、送信許可判定部２３は、リクエスト管理テーブル２４の対象リクエストのエントリが削除されたか否かを判定する。リクエスト管理テーブル２４の対象リクエストのエントリが削除された場合には（ＯＰ４７：ＹＥＳ）、図１７に示される処理が終了する。リクエスト管理テーブル２４の対象リクエストのエントリが削除されない場合には（ＯＰ４７：ＮＯ）、処理がＯＰ４８に進む。
【０１６７】
ＯＰ４８では、送信許可判定部２３は、対象リクエストの送信許可が判定されたか否かを判定する。対象リクエストの送信許可が判定された場合には（ＯＰ４８：ＹＥＳ）、処理がＯＰ４９に進む。対象リクエストの送信許可が判定されていない場合には（ＯＰ４８：ＮＯ）、処理がＯＰ５１に進む。
【０１６８】
ＯＰ４９では、送信許可判定部２３は、対象リクエストについて、モバイル端末１にリクエスト送信許可応答を送信する。このとき、リクエスト送信許可応答には、リクエスト識別子、送信データのサイズが含まれている。
【０１６９】
ＯＰ５０では、送信許可判定部２３は、リクエスト管理テーブル２４の対象リクエストのエントリの「状態」の項目を「許可済み」に変更する。その後、処理がＯＰ４７に進む。
【０１７０】
ＯＰ５１では、対象リクエストの送信許可が判定されていないので、送信許可判定部２３は、一定時間待機する。一定時間が経過すると、処理がＯＰ４７に進む。
【０１７１】
図１８Ａ及び図１８Ｂは、第３実施形態に係る、プロキシサーバ２Ｂのリクエスト送信制御処理におけるＨＴＴＰリクエスト受信時のフローチャートの一例である。図１８Ａ、図１８Ｂに示される処理は、モバイル端末１からＨＴＴＰリクエストが受信された場合に開始される。図１８Ａ及び図１８Ｂに示される処理の主体は、通信タイミング調整プロキシプログラム２０３Ａを実行するプロキシサーバ２ＢのＣＰＵ  ２０１であるが、便宜上、機能構成であるリクエスト中継部２１、ＮＷ状況管理部２２、送信許可判定部２３を主体として説明する。
【０１７２】
ＯＰ６１では、送信許可判定部２３は、リクエスト中継部２１から、ＨＴＴＰリクエストの受信の通知を受ける。
【０１７３】
ＯＰ６２では、送信許可判定部２３は、ＨＴＴＰリクエストから、リクエスト識別子を抽出する。ＯＰ６３では、送信許可判定部２３は、リクエスト管理テーブル２４の、抽出したリクエスト識別子に該当するエントリの「状態」の項目の値を取得する。
【０１７４】
ＯＰ６４では、送信許可判定部２３は、リクエスト管理テーブル２４の該当のエントリの「状態」の項目の値を解析する。リクエスト管理テーブル２４の該当のエントリの「状
態」の項目の値が「許可済み」である場合には（ＯＰ６４：許可済み）、処理がＯＰ６５に進む。リクエスト管理テーブル２４の該当のエントリの「状態」の項目の値が「受信中」である場合には（ＯＰ６４：受信中）、処理がＯＰ６７に進む。
【０１７５】
ＯＰ６５では、「許可済み」であるので、送信許可判定部２３は、リクエスト管理テーブル２４の該当のエントリの「状態」の項目の値を「受信中」に変更する。ＯＰ６６では、送信許可判定部２３は、リクエスト中継部２１に、受信したＨＴＴＰリクエストのヘッダ部とボディ部とをバッファに記憶するよう指示する。
【０１７６】
ＯＰ６７では、「受信中」であるので、送信許可判定部２３は、リクエスト中継部２１に、受信したＨＴＴＰリクエストのボディ部を、バッファに記憶されているボディ部にマージして記憶するよう指示する。
【０１７７】
ＯＰ６８では、送信許可判定部２３は、リクエスト管理テーブル２４の該当のエントリの「サイズ」の項目の値を、ＯＰ６１で受信されたＨＴＴＰリクエストのボディ部のサイズ分減じた値に更新する。
【０１７８】
図１８ＢのＯＰ６９では、送信許可判定部２３は、リクエスト管理テーブル２４の該当のエントリの「サイズ」の項目の値が０であるか否かを判定する。リクエスト管理テーブル２４の該当のエントリの「サイズ」の項目の値が０である場合には（ＯＰ６９：ＹＥＳ）、処理がＯＰ７０に進む。リクエスト管理テーブル２４の該当のエントリの「サイズ」の項目の値が０でない場合には（ＯＰ６９：ＮＯ）、処理がＯＰ７４に進む。
【０１７９】
ＯＰ７０では、送信許可判定部２３は、リクエスト管理テーブル２４の該当のエントリの「状態」の項目の値を「送信中」に変更する。ＯＰ７１では、送信許可判定部２３は、リクエスト中継部２１に、ＨＴＴＰリクエストの送信を指示する。リクエスト中継２１は、バッファに記憶されているヘッダ部とボディ部とからＨＴＴＰリクエストを復元して、コンテンツサーバ３へ転送する。
【０１８０】
ＯＰ７２では、リクエスト中継部２１は、コンテンツサーバ３から、ＯＰ７１で送信されたＨＴＴＰリクエストに対するＨＴＴＰレスポンスを受信し、モバイル端末１に転送する。
【０１８１】
ＯＰ７３では、送信許可判定部２３は、リクエスト管理テーブル２４の、ＨＴＴＰレスポンスが受信されたＨＴＴＰリクエストに対応するリクエスト識別子に該当するエントリを削除する。
【０１８２】
ＯＰ７４では、送信許可判定部２３は、無線ネットワーク２００の帯域使用状況を、ＮＷ状況管理部２２に問い合わせて取得する。また、ＯＰ７５では、送信許可判定部２３は、リクエスト発生状況管理部２５に問い合わせて、アプリケーションのＨＴＴＰリクエストの平均発生間隔を取得する。ＯＰ７６では、送信許可判定部２３は、ＨＴＴＰリクエストの送信許可判定処理を行う。
【０１８３】
ＯＰ７７では、送信許可判定部２３は、送信許可が判定されたＨＴＴＰリクエストを対象リクエストとするスレッドに、送信許可を通知する。その後、図１８Ｂに示される処理が終了する。
【０１８４】
図１９は、第３実施形態に係る、プロキシサーバ２ＢのＨＴＴＰリクエストの送信許可判定処理のフローチャートの一例である。図１９に示される処理の主体は、通信タイミング調整プロキシプログラム２０３Ａを実行するプロキシサーバ２ＢのＣＰＵ  ２０１であ
るが、便宜上、機能構成である送信許可判定部２３を主体として説明する。
【０１８５】
なお、第３実施形態において、ＨＴＴＰリクエストの許可条件の判定順は、第２実施形態と同様であり、以下の通りである。
（１）タイムアウトの近いＨＴＴＰリクエスト
（２）サイズの小さいＨＴＴＰリクエスト
（３）フォアグラウンドで実行中のアプリケーションのＨＴＴＰリクエスト
（４）バックグラウンドで実行中のアプリケーションのＨＴＴＰリクエスト
【０１８６】
ＯＰ８１では、送信許可判定部２３は、変数ｎを初期値の１に設定する。変数ｎは、ＨＴＴＰリクエストの許可条件の順番を示す。
【０１８７】
ＯＰ８２では、送信許可判定部２３は、ｎ番目の許可条件を満たすＨＴＴＰリクエストを、リクエスト管理テーブル２４の「待機中」、「受信中」のエントリから送信許可候補として選択する。
【０１８８】
ＯＰ８３では、送信許可判定部２３は、使用予定帯域が閾値１より大きいか否かを判定する。第３実施形態では、送信許可判定部２３は、１つのＨＴＴＰリクエストの送信によって消費される帯域を、ＨＴＴＰリクエストのサイズに応じて判定し、使用予定帯域を算出する。
【０１８９】
使用予定帯域が閾値１より大きい場合には（ＯＰ８３：ＹＥＳ）、処理がＯＰ８４に進む。使用予定帯域は閾値１以下である場合には（ＯＰ８３：ＮＯ）、処理がＯＰ８５に進む。
【０１９０】
ＯＰ８４の処理は、ｎ＞２の場合について実行される処理である。ＯＰ８４では、送信許可判定部２３は、許可候補のＨＴＴＰリクエストの送信データのサイズを、各ＨＴＴＰリクエストの通信元のアプリケーションのＨＴＴＰリクエストの平均発生間隔に基づいて、決定する。その後処理がＯＰ８３に進む。
【０１９１】
例えば、ＯＰ８４において、送信許可判定部２３は、以下のような処理を行う。送信許可判定部２３は、許可候補のＨＴＴＰリクエストに該当するアプリケーションのＨＴＴＰリクエストの平均発生間隔と、許可候補のＨＴＴＰリクエストの受信時刻とから、次のＨＴＴＰリクエストの発生時刻を予測する。送信許可判定部２３は、次のＨＴＴＰリクエストの発生時刻までの時間内で、許可候補のＨＴＴＰリクエストが使用可能な空き帯域で送信可能なデータサイズを算出し、それに収まるように、ＨＴＴＰリクエストのボディ部のサイズを決定する。許可候補のＨＴＴＰリクエストが使用可能な空き帯域は、例えば、現在の無線ネットワーク２００の空き帯域を、許可候補のＨＴＴＰリクエストの数で等分して求められる。または、使用可能な空き帯域を、許可候補のＨＴＴＰリクエストで順に埋めていき、最後に収まり切らないリクエストについて、収まるように分割してもよい。
【０１９２】
したがって、ＨＴＴＰリクエストの発生間隔が長い場合には、次のＨＴＴＰリクエストの発生時刻までの時間が長くなり、次のＨＴＴＰリクエストの発生時刻までの時間内で送信可能なデータサイズが大きくなる。ＨＴＴＰリクエストの発生間隔が短い場合には、次のＨＴＴＰリクエストの発生時刻までの時間が短くなり、次のＨＴＴＰリクエストの発生時刻までの時間内で送信可能なデータサイズが小さくなる。第３実施形態では、ＨＴＴＰリクエストが分割送信される場合には、各送信のボディ部のサイズは一意ではなく、送信の度に決定される。また、無線ネットワーク２００の空き帯域と、許可候補のＨＴＴＰリクエストの数によっては、ＨＴＴＰリクエストは分割送信されない場合もある。
【０１９３】
ＯＰ８５では、送信許可判定部２３は、送信許可候補のＨＴＴＰリクエストの送信許可を確定する。
【０１９４】
ＯＰ８６では、送信許可判定部２３は、使用予定帯域が閾値２以下であるか否かを判定する。使用予定帯域が閾値２以下である場合には（ＯＰ８６：ＹＥＳ）、処理がＯＰ８７に進む。使用予定帯域は閾値２より大きい場合には（ＯＰ８６：ＮＯ）、図１９に示される処理が終了する。
【０１９５】
ＯＰ８７では、送信許可判定部２３は、変数ｎがＮであるか否かを判定する。Ｎは、許可条件の数である。変数ｎがＮである場合には（ＯＰ８７：ＹＥＳ）、図１９に示される処理が終了する。変数ｎがＮでない場合には（ＯＰ８７：ＮＯ）、処理がＯＰ８８に進む。
【０１９６】
ＯＰ８８では、送信許可判定部２３は、変数ｎに１を加算して、変数ｎを更新する。その後、処理がＯＰ８２に進み、許可条件ｎについて、ＯＰ８２からＯＰ８７の処理が行われる。
【０１９７】
なお、図１９に示されるＨＴＴＰリクエストの送信許可判定処理は、一例であって、ＨＴＴＰリクエストの送信許可判定処理は、限定されない。許可条件も、一例であって、上述のものに限定されない。
【０１９８】
図２０Ａ及び図２０Ｂは、第３実施形態に係る、モバイル端末＃Ａとモバイル端末＃Ｂとにおいて、ＨＴＴＰリクエストが発生した場合の無線通信システム１００における処理のシーケンスの一例を示す図である。モバイル端末＃Ａでは、バックグラウンドで実行されるオンラインストレージにデータをアップロードするアプリケーションのＨＴＴＰリクエストが発生することを想定する。モバイル端末＃Ｂでは、フォアグラウンドで実行されるブラウザのアプリケーションのＨＴＴＰリクエストが発生することを想定する。
【０１９９】
Ｓ３１では、モバイル端末＃Ａのオンラインストレージアプリケーションによって、ＨＴＴＰリクエストが発生する（図９、ＯＰ１）。Ｓ３２では、モバイル端末＃Ａは、オンラインストレージアプリケーションのアプリケーション識別子、実行状況を収集する（図９、ＯＰ２）。
【０２００】
Ｓ３３では、モバイル端末＃Ａは、プロキシサーバ２Ｂにリクエスト送信許可要求を送信する（図９、ＯＰ３）。Ｓ３３において送信されるリクエスト送信許可要求には、オンラインストレージアプリケーションのアプリケーション識別子、実行状況としてバックグラウンド、モバイル端末＃Ａの端末識別子、ＨＴＴＰリクエストのサイズが含まれている。
【０２０１】
Ｓ３４では、プロキシサーバ２Ｂは、モバイル端末＃Ａからのリクエスト送信許可要求を受信し（図１７、ＯＰ４１）、リクエスト識別子＃１として、リクエスト管理テーブル２４にエントリを登録する（図１７、ＯＰ４２）。Ｓ３５では、プロキシサーバ２Ｂは、無線ネットワーク２００の帯域使用状況と、各アプリケーションのＨＴＴＰリクエストの平均発生間隔を取得する（図１７、ＯＰ４３、ＯＰ４４）。
【０２０２】
Ｓ３６では、プロキシサーバ２Ｂは、ＨＴＴＰリクエストの送信許可判定処理を行う（図１７、ＯＰ４５）。ここでは、他にＨＴＴＰレスポンスが発生しておらず、無線ネットワーク２００の帯域使用状況と、オンラインストレージアプリケーションのＨＴＴＰリクエストの平均発生間隔とから、モバイル端末＃ＡのＨＴＴＰリクエストは、分割送信が判定されることを想定する。Ｓ３６では、リクエスト識別子＃１に該当するリクエスト管理
テーブル２４のエントリの「状態」の項目は、「待機中」から「許可済み」に変更される（図１７、ＯＰ４９）。
【０２０３】
Ｓ３７では、プロキシサーバ２Ｂは、モバイル端末＃Ａに、リクエスト送信許可応答を送信する（図１７、ＯＰ４８）。リクエスト送信許可応答には、リクエスト識別子＃１、送信データのサイズ（図中「分割＃１のサイズ」）が含まれている。
【０２０４】
Ｓ３８では、モバイル端末＃Ａは、リクエスト送信許可応答を受信し（図９、ＯＰ４）、オンラインストレージアプリケーションのＨＴＴＰリクエストを送信する（図９、ＯＰ５）。Ｓ３８において送信されるＨＴＴＰリクエストのヘッダには、リクエスト識別子＃１が含まれており、ボディ部のサイズはリクエスト送信許可応答で指定されたサイズである。
【０２０５】
Ｓ３９では、プロキシサーバ２Ｂは、ＨＴＴＰリクエストを受信し（図１８Ａ、ＯＰ６１）、リクエスト識別子＃１に該当するリクエスト管理テーブル２４のエントリの「状態」の項目を「許可済み」から「受信中」に変更する（図１８Ａ、ＯＰ６５）。また、プロキシサーバ２Ｂは、受信したＨＴＴＰリクエストをバッファする（図１８Ａ、ＯＰ６６）。
【０２０６】
Ｓ４０では、モバイル端末＃Ｂのブラウザアプリケーションによって、ＨＴＴＰリクエストが発生する（図９、ＯＰ１）。Ｓ４１では、モバイル端末＃Ｂは、ブラウザアプリケーションのアプリケーション識別子、実行状況を収集する（図９、ＯＰ２）。
【０２０７】
Ｓ４２では、モバイル端末＃Ｂは、プロキシサーバ２Ｂにリクエスト送信許可要求を送信する（図９、ＯＰ３）。Ｓ４２において送信されるリクエスト送信許可要求には、ブラウザアプリケーションのアプリケーション識別子、実行状況としてフォアグラウンド、モバイル端末＃Ｂの端末識別子、ＨＴＴＰリクエストのサイズが含まれている。
【０２０８】
Ｓ４３では、プロキシサーバ２Ｂは、モバイル端末＃Ｂからのリクエスト送信許可要求を受信し（図１７、ＯＰ４１）、リクエスト識別子＃２として、リクエスト管理テーブル２４にエントリを登録する（図１７、ＯＰ４２）。Ｓ４４では、プロキシサーバ２Ｂは、無線ネットワーク２００の帯域使用状況と、各アプリケーションのＨＴＴＰリクエストの平均発生間隔を取得する（図１７、ＯＰ４３、ＯＰ４４）。
【０２０９】
Ｓ４５では、プロキシサーバ２Ｂは、ＨＴＴＰリクエストの送信許可判定処理を行う（図１７、ＯＰ４５）。ここでは、ブラウザアプリケーションがフォアグラウンドで実行中であることから、モバイル端末＃ＢのＨＴＴＰリクエストは、モバイル端末＃ＡのＨＴＴＰリクエストよりも優先して、送信許可されることを想定する。なお、モバイル端末＃ＢのＨＴＴＰリクエストのサイズは小さく、分割されないこととする。Ｓ４５では、リクエスト識別子＃２に該当するリクエスト管理テーブル２４のエントリの「状態」の項目は、「待機中」から「許可済み」に変更される（図１７、ＯＰ４９）。
【０２１０】
図２０ＢのＳ４６では、プロキシサーバ２Ｂは、モバイル端末＃Ｂに、リクエスト送信許可応答を送信する（図１７、ＯＰ４７：ＹＥＳ、ＯＰ４８）。リクエスト送信許可応答には、リクエスト識別子＃２と、送信データのサイズが含まれている。リクエスト送信許可応答に含まれる送信データのサイズは、モバイル端末＃ＢのＨＴＴＰリクエストのサイズと同じである。
【０２１１】
Ｓ４７では、モバイル端末＃Ｂは、リクエスト送信許可応答を受信し（図９、ＯＰ４）、ブラウザのＨＴＴＰリクエストを送信する（図９、ＯＰ５）。ブラウザのＨＴＴＰリク
エストのヘッダには、リクエスト識別子＃２が含まれている。
【０２１２】
Ｓ４８では、プロキシサーバ２Ｂは、ＨＴＴＰリクエストを受信し（図１８Ａ、ＯＰ６１）、リクエスト識別子＃２に該当するリクエスト管理テーブル２４のエントリの状態の項目を「送信中」に変更する（図１８Ｂ、ＯＰ６９：ＹＥＳ、ＯＰ７０）。モバイル端末＃ＢのＨＴＴＰリクエストは一度で送信されるためである。
【０２１３】
Ｓ４９では、プロキシサーバ２Ｂは、ＨＴＴＰリクエストを宛先のコンテンツサーバ３に転送する（図１８Ｂ、ＯＰ７１）。Ｓ５０では、プロキシサーバ２Ｂはコンテンツサーバから、ＨＴＴＰレスポンスを受信する（図１８Ｂ、ＯＰ７２）。Ｓ５１では、プロキシサーバ２Ｂは、ＨＴＴＰレスポンスをモバイル端末＃Ｂに転送する。
【０２１４】
Ｓ５２では、プロキシサーバ２Ｂは、リクエスト識別子＃２に該当するリクエスト管理テーブル２４のエントリを削除する（図１８Ｂ、ＯＰ７３）。Ｓ５３では、プロキシサーバ２Ｂは、無線ネットワーク２００の帯域使用状況と、各アプリケーションのＨＴＴＰリクエストの平均発生間隔とを取得する（図１８Ｂ、ＯＰ７４、ＯＰ７５）。
【０２１５】
Ｓ５４では、プロキシサーバ２Ｂは、ＨＴＴＰリクエストの送信許可判定処理を行う（図１８Ｂ、ＯＰ７６）。ここでは、モバイル端末＃ＢのＨＴＴＰリクエストの通信が終了したことによって空いた帯域に、バックグラウンドで実行中のモバイル端末＃ＡのＨＴＴＰリクエストの残りのデータが、送信許可されることを想定する。リクエスト識別子＃１に該当するリクエスト管理テーブル２４のエントリの状態の項目は、「許可済み」に変更される（図１７、ＯＰ４７：ＹＥＳ、ＯＰ４９）。
【０２１６】
Ｓ５５では、プロキシサーバ２Ｂは、モバイル端末＃Ａに、リクエスト送信許可応答を送信する（図１７、ＯＰ４７：ＹＥＳ、ＯＰ４８）。リクエスト送信許可応答には、リクエスト識別子＃１、送信データのサイズが含まれている。
【０２１７】
Ｓ５６では、モバイル端末＃Ａは、リクエスト送信許可応答を受信し（図９、ＯＰ４）、オンラインストレージアプリケーションのＨＴＴＰリクエストを送信する（図９、ＯＰ５）。オンラインストレージアプリケーションのＨＴＴＰリクエストのヘッダには、リクエスト識別子＃１が含まれており、ボディ部には、残りのＨＴＴＰデータが格納されている。モバイル端末＃ＡのＨＴＴＰリクエストの残りのデータのサイズは、リクエスト送信許可応答に指定された送信データと同じである。
【０２１８】
Ｓ５７では、プロキシサーバ２Ｂは、ＨＴＴＰリクエストを受信し（図１８Ａ、ＯＰ６１）、リクエスト識別子＃１に該当するリクエスト管理テーブル２４のエントリの状態の項目を「送信中」に変更する（図１８Ｂ、ＯＰ６９：ＹＥＳ、ＯＰ７０）。モバイル端末＃ＡのＨＴＴＰリクエストの残りのデータのサイズは、リクエスト送信許可応答に指定された送信データのサイズよりも小さく、リクエスト識別子＃１に該当するリクエスト管理テーブル２４のエントリの「サイズ」の項目の値が０になるからである。
【０２１９】
Ｓ５８では、プロキシサーバ２Ｂは、Ｓ４９においてバッファされたＨＴＴＰリクエストとＳ５６において受信したＨＴＴＰリクエストとから、ＨＴＴＰリクエストを復元して、宛先のコンテンツサーバ３に転送する（図１８Ｂ、ＯＰ７１）。Ｓ５９では、プロキシサーバ２Ｂはコンテンツサーバから、ＨＴＴＰレスポンスを受信する（図１８Ｂ、ＯＰ７２）。Ｓ６０では、プロキシサーバ２Ｂは、ＨＴＴＰレスポンスをモバイル端末＃Ｂに転送する。
【０２２０】
Ｓ６１では、プロキシサーバ２Ｂは、リクエスト識別子＃１に該当するリクエスト管理
テーブル２４のエントリを削除する（図１８Ｂ、ＯＰ７３）。以降、再度無線ネットワークの使用帯域と、各アプリケーションのＨＴＴＰリクエストの平均発生間隔との取得が行われ、ＨＴＴＰリクエストの送信許可判定処理が行われる。
【０２２１】
図２０Ａ及び図２０Ｂに示される例では、バックグラウンドで実行中のオンラインストレージアプリケーションのＨＴＴＰリクエストは分割して送信される。フォアグラウンドで実行中のブラウザのＨＴＴＰリクエストが発生すると、該ＨＴＴＰリクエストの送信が優先され、オンラインストレージアプリケーションのＨＴＴＰリクエストの送信に割り込んで、先に送信許可される。
【０２２２】
第３実施形態では、アプリケーションのＨＴＴＰリクエストの平均発生間隔に応じて、ＨＴＴＰリクエストが分割されて複数回にわたり送信される。これによって、後発の優先度の高いアプリケーションのＨＴＴＰリクエストの送信を割り込ませて行うことができる。
【０２２３】
＜第４実施形態＞
第４実施形態では、プロキシサーバは、ＨＴＴＰリクエストのＵＲＬに応じて、優先して送信許可を判定するＨＴＴＰリクエストを判定する。第４実施形態においても、第１実施形態と重複する説明は省略される。
【０２２４】
同じアプリケーションであっても、送信するＨＴＴＰリクエストの体感品質への影響がすべて等価とは限らない。例えば、写真共有アプリケーションの場合、サーバに保存されている最新の写真は早く見たいので、他のＨＴＴＰリクエストよりも優先させたい場合がある。ウェブブラウジングの場合にも、コンテンツの本文は早く見たいので、速やかに本文のデータは取得されないと、体感品質は低下する。一方で、広告のような重要性の低いデータは、データ取得が遅くなっても、体感品質を低下させることがないと考えられる。したがって、同じアプリケーションが送信するＨＴＴＰリクエストであっても、ＨＴＴＰリクエストによって取得されるデータによって体感品質に与える影響が異なる。
【０２２５】
したがって、第４実施形態では、プロキシサーバは、ＨＴＴＰリクエストの宛先ＵＲＬに応じて優先制御を行い、無線ネットワーク２００のトラフィックの平準化を図り、体感品質を向上させる。
【０２２６】
図２１は、第４実施形態に係るプロキシサーバ２Ｃの機能構成の一例を示す図である。プロキシサーバ２Ｃは、機能構成要素として、リクエスト中継部２１、ＮＷ状況管理部２２、送信許可判定部２３、リクエスト管理テーブル２４に加えて、優先度管理部２７、優先度管理テーブル２８を備える。優先度管理部２７、優先度管理テーブル２８も、プロキシサーバ２ＣのＣＰＵ  ２０１が通信タイミング制御プロキシプログラム２０３Ａを実行することによって達成される機能構成要素の一つである。
【０２２７】
優先度管理部２７は、優先度管理テーブル２８を管理する。優先度管理テーブル２８には、ＵＲＬごとの優先度が格納されている。優先度管理部２７は、送信許可判定部２３からの問い合わせに応じて、ＵＲＬの優先度を優先度管理テーブル２８で検索し、ＵＲＬの優先度を送信許可判定部２３に返す。
【０２２８】
図２２は、優先度管理テーブル２８の一例である。優先度管理テーブル２８は、プロキシサーバ２の一次記憶装置２０２に記憶される。優先度管理テーブル２８のエントリには、アプリケーション識別子、ＵＲＬ、優先度の項目が含まれる。優先度管理テーブル２８のエントリは、例えば、無線通信システム１００の管理者によって登録される。
【０２２９】
「ＵＲＬ」の項目には、優先対象のＵＲＬが格納される。「優先度」の項目には、「ｈｉｇｈ」又は「ｌｏｗ」のいずれかの値が格納される。「優先度」の項目の値が「ｈｉｇｈ」であるＵＲＬは、優先的に送信許可される。
【０２３０】
例えば、図２２に示される優先度管理テーブル２８の１つ目のエントリでは、「写真共有」アプリが「http://picture.com/recent/*」にマッチするＵＲＬにアクセスする場合
の優先度が「ｈｉｇｈ」であることが示される。「*」は任意の文字列を表している。優
先度管理テーブル２８は、ＨＴＴＰリクエストのメソッド種別（ＧＥＴ、ＰＯＳＴなど）や時間帯など、他の条件が追加されもよい。
【０２３１】
第４実施形態では、モバイル端末１の送信許可問合部１２は、リクエスト送信許可要求に、通信元のアプリケーション１９のアプリケーション識別子、実行状況、端末識別子に加えて、ＨＴＴＰリクエストの宛先ＵＲＬを含めて、プロキシサーバ２に送信する。
【０２３２】
また、第４実施形態では、送信許可判定部２３は、リクエスト送信許可要求を受信すると、無線ネットワーク２００の帯域使用状況をＮＷ状況管理部２２から取得する。また、送信許可判定部２３は、優先度管理部２７に、リクエスト送信許可要求に含まれる宛先ＵＲＬの優先度を問い合わせ、取得する。なお、宛先ＵＲＬの優先度は設定されていない場合もある。
【０２３３】
送信許可判定部２３は、タイムアウトまでの時間、アプリケーションの実行状況、ＨＴＴＰリクエストの宛先の優先度に基づいて、送信許可するＨＴＴＰリクエストを判定する。例えば、第４実施形態における、プロキシサーバ２の送信許可判定部２３のＨＴＴＰリクエストの許可条件の優先順は、以下の通りである。なお、ＨＴＴＰリクエストの許可条件は、上記のものに限定されない。
（１）タイムアウトの近いＨＴＴＰリクエスト
（２）フォアグラウンドで実行中のアプリケーションであり、且つ、宛先ＵＲＬの優先度が「ｈｉｇｈ」であるＨＴＴＰリクエスト
（３）バックグラウンドで実行中のアプリケーションであり、且つ、宛先ＵＲＬの優先度が「ｈｉｇｈ」であるＨＴＴＰリクエスト
（４）フォアグラウンドで実行中のアプリケーションであり、且つ、宛先ＵＲＬの優先度の設定がないＨＴＴＰリクエスト
（５）フォアグラウンドで実行中のアプリケーションであり、且つ、宛先ＵＲＬの優先度が「ｌｏｗ」であるＨＴＴＰリクエスト
（６）バックグラウンドで実行中のアプリケーションであり、且つ、宛先ＵＲＬの優先度の設定がないＨＴＴＰリクエスト
（７）バックグラウンドで実行中のアプリケーションであり、且つ、宛先ＵＲＬの優先度が「ｌｏｗ」であるＨＴＴＰリクエスト
【０２３４】
プロキシサーバ２のＨＴＴＰリクエストの送信許可判定処理は、第１実施形態の図１２と同様であるため、説明を省略する。
【０２３５】
第４実施形態では、宛先ＵＲＬに優先度を設定し、同じアプリケーションでも優先度の高い宛先ＵＲＬから優先的に送信許可が判定される。これによって、同じアプリケーションのＨＴＴＰリクエストでも、宛先ＵＲＬで区別して、優先的に送信許可を判定することができる。
【０２３６】
＜第５実施形態＞
第５実施形態では、ＨＴＴＰリクエストの送信タイミングの調整を、プロキシサーバではなく、モバイル端末側で行う。第５実施形態でも、第１実施形態と重複する説明は省略
される。
【０２３７】
第５実施形態では、モバイル端末のハードウェア構成は、第１実施形態と同様であるため、説明を省略する。
【０２３８】
図２３は、第５実施形態に係るモバイル端末１Ｂの機能構成の一例を示す図である。第５実施形態では、モバイル端末１Ｂは、機能構成要素として、リクエスト制御部１１、送信許可問合部１２、情報収集部１３に加え、送信許可判定部１４、ＮＷ状況管理部１５、リクエスト管理テーブル１６を備える。これらは、それぞれ、モバイル端末１のＣＰＵ  １０１が、通信制御プロキシプログラム１０３Ａを実行することによって達成される機能構成要素である。
【０２３９】
リクエスト制御部１１、情報収集部１３は、第１実施形態と同様である。第５実施形態は、送信許可問合部１２は、リクエスト送信許可要求を、プロキシサーバ２ではなく、送信許可判定部１４に通知する。
【０２４０】
送信許可判定部１４は、モバイル端末１Ｂ内のＨＴＴＰリクエストについて、送信タイミングを制御する点以外は、第１実施形態と同様である。送信許可判定部１４は、送信許可を判定したＨＴＴＰリクエストについてのリクエスト送信許可応答を、送信許可問合部１２に通知する。
【０２４１】
ＮＷ状況管理部１５は、第１実施形態とは異なり、モバイル端末１Ｂの無線通信ドライバがセンシングを行い、無線ネットワーク２００の帯域使用状況を推定する。例えば、ＮＷ状況管理部１５は、無線ＬＡＮアクセスポイントから他のモバイル端末へのＡＣＫフレームの送信頻度を測定することによって、無線ネットワーク２００の混み具合を推定する。
【０２４２】
送信許可判定部１４は、ＮＷ状況管理部１５に問い合わせて無線ネットワーク２００の使用状況を取得する。または、送信許可判定部１４は、ＮＷ状況管理部１５を用いずに、例えば、バックグラウンドで実行中のアプリケーションのＨＴＴＰリクエストをランダムに遅延させてもよい。
【０２４３】
また、第５実施形態では、リクエスト管理テーブル１６は、自端末内のＨＴＴＰリクエストについて処理を行うので、エントリの項目に、端末識別子を含まない。それ以外は、リクエスト管理テーブル１６は、第１実施形態のリクエスト管理テーブル２４と同様である。
【０２４４】
なお、第５実施形態では、プロキシサーバは、通常のＨＴＴＰプロキシサーバと同様の処理、すなわち、ＨＴＴＰリクエスト、ＨＴＴＰレスポンスの中継を行う。
【０２４５】
図２４Ａ及び図２４Ｂは、第５実施形態に係るモバイル端末１Ｂのリクエスト送信制御処理のフローチャートの一例である。図２４Ａ、図２４Ｂに示される処理は、アプリケーション１９からＨＴＴＰリクエストが入力されると開始される。図２４Ａ、図２４Ｂに示される処理の主体は、通信制御プロキシプログラム１０３Ａを実行するモバイル端末１ＢのＣＰＵ  １０１であるが、便宜上、機能構成であるリクエスト制御部１１、送信許可問合部１２、情報収集部１３、送信許可判定部１４、ＮＷ状況管理部１５を主体として説明する。
【０２４６】
ＯＰ８１では、リクエスト制御部１１は、アプリケーション１９からのＨＴＴＰリクエストの入力を受け、送信許可問合部１２に、ＨＴＴＰリクエストの送信可否の問合せを行
う。リクエスト制御部１１は、待機バッファにＨＴＴＰリクエストを格納する。
【０２４７】
ＯＰ８２では、送信許可問合部１２は、情報収集部１３に、通信元のアプリケーション１９のアプリケーション識別子と、実行状況とを問い合わせて取得する。送信許可問合部１２は、送信許可判定部１４に、リクエスト送信許可要求を通知する。リクエスト送信許可要求には、モバイル端末１の端末識別子と、ＯＰ８２で取得したアプリケーション識別子と実行状況とが含まれている。
【０２４８】
ＯＰ８３では、送信許可判定部１４は、リクエスト管理テーブル１６に、リクエスト送信許可要求の対象のＨＴＴＰリクエストのエントリを生成して、ＨＴＴＰリクエストの情報を登録する。具体的には、送信許可判定部１４は、リクエスト識別子を取得し、リクエスト管理テーブル１６にエントリを作成する。送信許可判定部１４は、リクエスト送信許可要求から、アプリケーション識別子、実行状況を抽出し、リクエスト管理テーブル１６の生成したエントリに格納する。また、送信許可判定部１４は、生成したエントリの「状態」の項目を「待機中」に設定する。また、送信許可判定部１４は、ＨＴＴＰリクエストの発生時刻を生成したエントリの「受信時刻」の項目に記録する。
【０２４９】
ＯＰ８４では、送信許可判定部１４は、無線ネットワーク２００の帯域使用状況を、ＮＷ状況管理部１５に問い合わせて取得する。
【０２５０】
ＯＰ８５では、送信許可判定部１４は、ＨＴＴＰリクエストの送信許可判定処理を行う。ＨＴＴＰリクエストの送信許可判定処理は、図１２に示される通りである。
【０２５１】
ＯＰ８６では、送信許可判定部１４は、ＯＰ８１で受信したリクエスト送信許可要求の対象のＨＴＴＰリクエスト（対象リクエスト）以外の、送信許可が判定されたＨＴＴＰリクエストを処理するスレッドにリクエストの送信許可を通知する。対象リクエスト以外に、送信許可が判定されたＨＴＴＰリクエストがない場合には、ＯＰ８６の処理は省略される。
【０２５２】
図２４ＢのＯＰ８７では、送信許可判定部１４は、対象リクエストの送信許可が判定されたか否かを判定する。対象リクエストの送信許可が判定された場合には（ＯＰ８７：ＹＥＳ）、処理がＯＰ８９に進む。対象リクエストの送信許可が判定されていない場合には（ＯＰ８７：ＮＯ）、処理がＯＰ８８に進む。
【０２５３】
ＯＰ８８では、対象リクエストの送信許可が判定されていないので、送信許可判定部１４は、他のスレッドによって対象リクエストの送信許可が判定されることを待機する。他のスレッドによって対象リクエストの送信許可が判定されると、処理がＯＰ８７に進み、対象リクエストについて、送信許可問合部１２にリクエスト送信許可応答が送信される。
【０２５４】
ＯＰ８９では、送信許可判定部１４は、リクエスト管理テーブル１６の対象リクエストのエントリの「状態」の項目を「送信中」に変更する。
【０２５５】
ＯＰ９０では、送信許可判定部１４は、対象リクエストについて、送信許可問合部１２にリクエスト送信許可応答を通知し、送信許可問合部１２は、リクエスト制御部１１にＨＴＴＰリクエストの送信指示を通知する。リクエスト制御部１１は、待機バッファに格納されているＨＴＴＰリクエストをコンテンツサーバ３に送信し、ＨＴＴＰレスポンスを受信する。
【０２５６】
ＯＰ９１では、送信許可判定部１４は、リクエスト管理テーブル１６の、受信されたＨＴＴＰレスポンスに対応するＨＴＴＰリクエストのリクエスト識別子に該当するエントリ
を削除する。
【０２５７】
ＯＰ９２では、送信許可判定部１４は、無線ネットワーク２００の帯域使用状況を、ＮＷ状況管理部１５に問い合わせて取得する。ＯＰ９３では、送信許可判定部１４は、ＨＴＴＰリクエストの送信許可判定処理を行う。
【０２５８】
ＯＰ９４では、送信許可判定部１４は、送信許可が判定されたＨＴＴＰリクエストを対象リクエストとするスレッドに、送信許可を通知する。ＯＰ９５では、リクエスト制御部１１は、通信元のアプリケーション１９にＨＴＴＰレスポンスを出力する。その後、図２４Ｂに示される処理が終了する。
【０２５９】
図２５は、第５実施形態に係るモバイル端末１Ｂの定期的に実行されるＨＴＴＰリクエスト送信制御処理のフローチャートの一例である。図２５に示される処理は、所定の周期で実行される。
【０２６０】
ＯＰ１０１では、送信許可判定部１４は、無線ネットワーク２００の帯域使用状況を、ＮＷ状況管理部１５に問い合わせて取得する。ＯＰ１０２では、送信許可判定部１４は、ＨＴＴＰリクエストの送信許可判定処理を行う。
【０２６１】
ＯＰ１０３では、送信許可判定部１４は、送信許可が判定されたＨＴＴＰリクエストを対象リクエストとするスレッドに、送信許可を通知する。その後、図２５に示される処理が終了する。
【０２６２】
図２５に示される処理が定期的に実行されることによって、無線ネットワーク２００の帯域使用状況に余裕がある場合に、待機中のＨＴＴＰリクエストを送信させることができる。
【０２６３】
第５実施形態によれば、モバイル端末１Ｂ単体でも、ＨＴＴＰリクエストの送信タイミングを制御し、体感品質の低下を抑制することができる。
【０２６４】
＜その他＞
第１〜第５実施形態では、ＨＴＴＰリクエストの送信タイミングの制御について説明されたが、その他の通信プロトコルの送信要求についても、同様に送信タイミングの制御を適用することができる。また、複数の通信プロトコルの送信要求についても、同様に送信タイミングの制御を適用することができる。
【０２６５】
＜記録媒体＞
コンピュータその他の機械、装置（以下、コンピュータ等）に上記いずれかの機能を実現させるプログラムをコンピュータ等が読み取り可能な記録媒体に記録することができる。コンピュータ等に、この記録媒体のプログラムを読み込ませて実行させることにより、その機能を提供させることができる。
【０２６６】
ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることができる非一時的な記録媒体をいう。このような記録媒体のうちコンピュータ等から取り外し可能なものとしては、例えばフレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ／Ｗ、ＤＶＤ、ブルーレイディスク、ＤＡＴ、８ｍｍテープ、フラッシュメモリなどのメモリカード等がある。また、コンピュータ等に固定された記録媒体としてハードディスク、ＲＯＭ（リードオンリーメモリ）等がある。さらに、ＳＳＤ（Solid State Drive）は、コンピュータ等から取り外し可能な記録媒体としても、コ
ンピュータ等に固定された記録媒体としても利用可能である。
【符号の説明】
【０２６７】
１        モバイル端末
２        プロキシサーバ
３        コンテンツサーバ
１１      リクエスト制御部
１２      送信許可問合部
１３      情報収集部
１４      送信許可判定部
１５      ＮＷ状況管理部
１６      リクエスト管理テーブル
２１      リクエスト中継部
２２      ＮＷ状況管理部
２３      送信許可判定部
２４      リクエスト管理テーブル
２５      リクエスト発生状況管理部
２６      リクエスト発生状況管理テーブル
２７      優先度管理部
２８      優先度管理テーブル
１０１、２０１      ＣＰＵ
１０２、２０２      一次記憶装置
１０３、２０３      二次記憶装置
１０３Ａ    通信制御プロキシプログラム
２０３Ａ    通信タイミング調整プロキシプログラム
【図１】
2017167637.tif 000003
【図２】
2017167637.tif 000004
【図３】
2017167637.tif 000005
【図４】
2017167637.tif 000006
【図５】
2017167637.tif 000007
【図６】
2017167637.tif 000008
【図７】
2017167637.tif 000009
【図８】
2017167637.tif 000010
【図９】
2017167637.tif 000011
【図１０】
2017167637.tif 000012
【図１１】
2017167637.tif 000013
【図１２】
2017167637.tif 000014
【図１３Ａ】
2017167637.tif 000015
【図１３Ｂ】
2017167637.tif 000016
【図１４】
2017167637.tif 000017
【図１５】
2017167637.tif 000018
【図１６】
2017167637.tif 000019
【図１７】
2017167637.tif 000020
【図１８Ａ】
2017167637.tif 000021
【図１８Ｂ】
2017167637.tif 000022
【図１９】
2017167637.tif 000023
【図２０Ａ】
2017167637.tif 000024
【図２０Ｂ】
2017167637.tif 000025
【図２１】
2017167637.tif 000026
【図２２】
2017167637.tif 000027
【図２３】
2017167637.tif 000028
【図２４Ａ】
2017167637.tif 000029
【図２４Ｂ】
2017167637.tif 000030
【図２５】
2017167637.tif 000031