JP6515687B2 - 中継方法、中継プログラム及び中継装置 - Google Patents

Description

本発明は、コンテンツを中継する技術に関する。

ある特許文献には、配信サーバにおいて受信端末におけるストリーミング中の未再生バッファ残量を把握し、未再生バッファ残量が少ない受信端末に優先的に通信帯域を割り当てる技術が開示されている。このようにすれば、コンテンツバッファ枯渇による再生障害を抑制することができる。

但し、通信経路における通信状況が悪い場合には、配信サーバが未再生バッファ残量が少ない受信端末に優先的にデータを送出したとしても、当該受信端末において円滑にコンテンツの再生が行われるとは限らない。

また、配信サーバにおいて受信端末の状況を把握できない場合には、上述のように通信帯域の割り当てを制御することは適わない。

国際公開第２００５／０６２５６６号 特開２００２−０７７２５１号公報

本発明の目的は、一側面では、無線ネットワークに接続する端末におけるストリーミングをより円滑にすることである。

一態様に係るデータ中継方法は、（Ａ）ストリーミングを行う端末から無線ネットワークを介して受信したコンテンツ取得リクエストに応じて、コンテンツ配信装置からコンテンツを取得する処理と、（Ｂ）コンテンツの転送先である端末におけるプリバッファ残量を特定する特定処理と、（Ｃ）無線ネットワークにおける空き帯域が割り当てられるコンテンツ転送処理の許容数が、待機しているコンテンツ転送処理の数に満たない場合に、プリバッファ残量が少ない方の端末へのコンテンツの転送を開始させる処理とを含む。

一側面としては、無線ネットワークに接続する端末におけるストリーミングをより円滑にすることができる。

図１は、ネットワーク構成例を示す図である。 図２は、ネットワーク構成例を示す図である。 図３は、リクエストの発生間隔の例を示す図である。 図４は、コンテンツ転送のタイミング例を示す図である。 図５は、中継装置のモジュール構成例を示す図である。 図６は、メイン処理（Ａ）フローを示す図である。 図７は、リクエストテーブルの例を示す図である。 図８は、ルールの例を示す図である。 図９は、転送処理（Ａ）フローを示す図である。 図１０は、スレッドテーブルの例を示す図である。 図１１は、判別処理フローを示す図である。 図１２は、携帯無線端末のモジュール構成例を示す図である。 図１３は、ローカルプロキシ処理（Ａ）フローを示す図である。 図１４は、コンテンツ取得のリクエストにおけるヘッダの例を示す図である。 図１５は、メイン処理（Ｂ）フローを示す図である。 図１６は、実施の形態２に係るリクエストテーブルの例を示す図である。 図１７は、実施の形態２に係るルールの例を示す図である。 図１８は、ローカルプロキシ処理（Ｂ）フローを示す図である。 図１９は、転送処理（Ｂ）フローを示す図である。 図２０は、実施の形態３に係るスレッドテーブルの例を示す図である。 図２１は、ローカルプロキシ処理（Ｂ）フローを示す図である。 図２２は、ローカルプロキシ処理（Ｃ）フローを示す図である。 図２３は、転送処理（Ｃ）フローを示す図である。 図２４は、実施の形態４に係るスレッドテーブルの例を示す図である。 図２５は、実施の形態５に係る携帯無線端末のモジュール構成例を示す図である。 図２６は、インストール処理フローを示す図である。 図２７は、定義データの例を示す図である。 図２８は、実施の形態５に係る中継装置のモジュール構成例を示す図である。 図２９は、配信処理フローを示す図である。 図３０は、ローカルプロキシ処理（Ｄ）フローを示す図である。 図３１は、メイン処理（Ｃ）フローを示す図である。 図３２は、アンインストール処理フローを示す図である。 図３３は、携帯無線端末のハードウエア構成例を示す図である。 図３４は、コンピュータの機能ブロック図である。

［実施の形態１］
図１に、ネットワーク構成例を示す。携帯無線端末１０１は、無線ネットワークを介してノード装置１０３に接続する。無線ネットワークがセルラー方式であれば、ノード装置１０３は基地局に相当する。無線ネットワークが無線ＬＡＮ（Local Area Network）方式であれば、ノード装置１０３はアクセスポイントに相当する。

更に、ノード装置１０３は、有線ネットワークに接続している。有線ネットワークは、例えばインターネットに接続している。

この例で、携帯無線端末１０１は、中継装置１０７を介してコンテンツサーバ１０５からコンテンツを取得する。コンテンツサーバ１０５は、例えば動画サイトであって、動画のコンテンツを配信する。

コンテンツサーバ１０５ａのＵＲＬ（Uniform Resource Locator）は、「https//jp.tube.com/」であって、コンテンツサーバ１０５ａは動画サービスＡを提供するものとする。コンテンツサーバ１０５ｂのＵＲＬは、「http://www.motion.com/」であって、コンテンツサーバ１０５ｂは動画サービスＢを提供するものとする。コンテンツサーバ１０５ｃのＵＲＬは、「http://xxx.video.com/」であって、コンテンツサーバ１０５ｃは動画サービスＣを提供するものとする。

図２に、別のネットワーク構成例を示す。図２に示すように、ノード装置１０３が、中継装置１０７を兼ねるようにしてもよい。中継装置１０７は、携帯無線端末１０１とコンテンツサーバ１０５との間に設けられていれば、図１及び図２に示した位置以外の位置に設けられていてもよい。

中継装置１０７は、サーバ装置の態様であってもよい。また、中継装置１０７は、例えばｈｔｔｐ（Hypertext Transfer Protocol）リクエストを中継するプロキシサーバであってもよいし、ＩＰ（Internet Protocol）を全般的に中継する透過型プロキシサーバであってもよい。また、図２に示した中継装置１０７の態様以外のネットワーク機器であってもよい。更に、中継装置１０７は、コンテンツサーバ１０５と一体であってもよい。中継装置１０７は、管理者が使用するコンソールと接続していてもよい。

携帯無線端末１０１は、動画サービスから取得した動画のコンテンツをストリーミングによって再生するアプリケーションプログラムを有している。そして、アプリケーションプログラムは、プリバッファリングの機能を有している。プリバッファリングを行うことによって、一時的に通信が滞ることがあったとしても、コンテンツの再生が中断しにくくなる。また、ストリーミングを行うアプリケーションプログラムは、繰り返しコンテンツ取得のリクエストを送出する。但し、リクエストが発生する間隔は、一定とは限らない。

図３に、リクエストの発生間隔の例を示す。横軸は、時間の経過を示している。縦軸は、コンテンツ取得のリクエストが発生する間隔を示している。図示した通り、ブラウザにおいて動画の再生を開始した直後に、リクエストが頻繁に発生している。また、再生ポイントをスライドさせた場合にも、リクエストが頻繁に発生している。いずれの場合も、プリバッファ残量が少ない場合に、ブラウザがコンテンツ取得のリクエストを頻繁に発行していることを示している。

このようにすれば、早い段階で或る程度のプリバッファ残量を確保することができるようになる。この特性に着目すれば、アプリケーションプログラムにプリバッファ残量を問い合わせなくとも、外部からアプリケーションプログラムにおけるプリバッファ残量を推定することができる。

一方、プリバッファリングの機能を有していても、通信状況が悪い場合には、アプリケーションプログラムにおけるコンテンツの再生に支障が生じることがある。例えば、セルラー方式における基地局又は無線ＬＡＮ方式におけるアクセスポイントにアクセスが集中した場合には、携帯無線端末１０１におけるスループットが低下する。例えば、以下のような場合に、輻輳が生じ、携帯無線端末１０１におけるスループットが低下すると考えられる。

（Ａ）スポーツスタジアムで、ゲームの休憩時間に、他のスタジアムで行われているゲーム結果の速報動画を見る場合、（Ｂ）イベント会場において、観客がクラウドにアップロードしている動画のうち、自席から直接見えなかったアングルからの動画を見る場合、（Ｃ）高速道路で事故発生時に，ドライブ計画を変更する目的で、事故現場の車の流れを動画で確認する場合。

本実施の形態では、プリバッファ残量に余裕が無い携帯無線端末１０１に対する応答を先に行い、プリバッファ残量に余裕が有る携帯無線端末１０１に対しては応答を遅らせるようにする。つまり、プリバッファ残量を、コンテンツ取得のリクエストに対する応答の優先度を示す評価情報として用いる。

このようにすれば、１つのノード装置１０３にアクセスが集中したとしても、アプリケーションプログラムによる再生に支障が生じにくくなる。そして、ユーザによるアプリケーションプログラムに対する体感品質が向上することになる。また、無線ネットワークにおけるトラフィックが平準化される面もある。

図４に、本実施の形態におけるコンテンツ転送のタイミング例を示す。時刻Ｔ₁₁に、中継装置１０７は、携帯無線端末１０１ａからコンテンツＡ取得のリクエストを受信し、当該リクエストに応じてコンテンツサーバ１０５ａからコンテンツＡを取得し始める。同様に、時刻Ｔ₂₁に、中継装置１０７は、携帯無線端末１０１ｂからコンテンツＢ取得のリクエストを受信し、当該リクエストに応じてコンテンツサーバ１０５ｂからコンテンツＢを取得し始める。同様に、時刻Ｔ₃₁に、中継装置１０７は、携帯無線端末１０１ｃからコンテンツＣ取得のリクエストを受信し、当該リクエストに応じてコンテンツサーバ１０５ｃからコンテンツＣを取得し始める。同様に、時刻Ｔ₄₁に、中継装置１０７は、携帯無線端末１０１ｄからコンテンツＤ取得のリクエストを受信し、当該リクエストに応じてコンテンツサーバ１０５ａからコンテンツＤを取得し始める。

本実施の形態では、同時に行われるコンテンツ転送処理の数を制限する。図４に示した例では、説明の便宜のためにコンテンツ転送処理の最大数を２とする。

コンテンツＡを取得する期間Ｐ₁₁が経過した時点Ｔ₁₂で、コンテンツ転送処理は１つも行われていないので、中継装置１０７は、コンテンツＡを携帯無線端末１０１ａへ転送する処理を開始する。

コンテンツＢを取得する期間Ｐ₂₁が経過した時点Ｔ₂₂で、コンテンツ転送処理は１つしか行われていないので、中継装置１０７は、コンテンツＢを携帯無線端末１０１ｂへ転送する処理を開始する。

コンテンツＣを取得する期間Ｐ₃₁が経過した時点Ｔ₃₂で、コンテンツ転送処理は２つ行われているので、中継装置１０７は、コンテンツＣの転送を行わずに待機する。

コンテンツＤを取得する期間Ｐ₄₁が経過した時点Ｔ₄₂で、上述した２つのコンテンツ転送処理は、継続しているので、中継装置１０７は、コンテンツＤの転送を行わずに待機する。

コンテンツＡを転送する期間Ｐ₁₂が経過した時点Ｔ₁₃で、コンテンツ転送処理は１つ減る。従って、中継装置１０７は、待機しているコンテンツＣの転送処理あるいはコンテンツＤの転送処理のうち、いずれかを開始させる。本実施の形態では、コンテンツＣの転送先である携帯無線端末１０１ｃのアプリケーションプログラムにおけるプリバッファ残量と、コンテンツＤの転送先である携帯無線端末１０１ｄのアプリケーションプログラムにおけるプリバッファ残量とを比較する。

この例では、携帯無線端末１０１ｄのアプリケーションプログラムにおけるプリバッファ残量の方が少なかったものとする。プリバッファ残量が少ない方のアプリケーションプログラムへのコンテンツの転送を先に行うようにする。従って、時点Ｔ₁₃に、中継装置１０７は、コンテンツＤを携帯無線端末１０１ｄへ転送する処理を開始する。

そして、コンテンツＢを転送する期間Ｐ₂₂が経過した時点Ｔ₂₃で、コンテンツ転送処理はまた１つ減る。このとき、中継装置１０７は、待機していたコンテンツＤの転送処理を開始する。以上で、本実施の形態における概要の説明を終える。

続いて、中継装置１０７について説明する。図５に、中継装置１０７のモジュール構成例を示す。中継装置１０７は、第１受信部５０１、起動部５０３、第１取得部５０５、記録処理部５０７、特定部５０９、転送部５１１、判別部５１３、監視部５１５、開始部５１７、リクエストテーブル記憶部５２１、ルール記憶部５２３、スレッドテーブル記憶部５２５及びコンテンツ記憶部５２７を有する。

第１受信部５０１は、携帯無線端末１０１からコンテンツ取得のリクエストを受信する。起動部５０３は、第１取得部５０５によるコンテンツ取得処理を起動する。起動部５０３は、更に、転送部５１１による転送処理を起動する。第１取得部５０５は、コンテンツサーバ１０５からコンテンツを取得する処理を行う。記録処理部５０７は、リクエストテーブルにおけるリクエストレコードを記録する処理を行う。特定部５０９は、携帯無線端末１０１のアプリケーションプログラムにおけるプリバッファ残量の推定値を特定する。転送部５１１は、コンテンツを携帯無線端末１０１へ転送する処理を行う。尚、転送部５１１は、リクエスト単位で設けられるスレッドとして動作する。判別部５１３は、コンテンツの転送を開始させる転送部５１１を特定する。監視部５１５は、無線ネットワークの状況を監視する。開始部５１７は、転送の開始を指示する。

リクエストテーブル記憶部５２１は、リクエストテーブルを記憶する。リクエストテーブルについては、後述する。ルール記憶部５２３は、プリバッファ残量の推定値を特定するためのルールを記憶する。ルールについては、後述する。スレッドテーブル記憶部５２５は、スレッドテーブルを記憶する。スレッドテーブルについては、後述する。コンテンツ記憶部５２７は、コンテンツサーバ１０５から取得したコンテンツを記憶する。

上述した第１受信部５０１、起動部５０３、第１取得部５０５、記録処理部５０７、特定部５０９、転送部５１１、判別部５１３、監視部５１５及び開始部５１７は、ハードウエア資源（例えば、図３４）と、以下で述べる処理をプロセッサに実行させるプログラムとを用いて実現される。

上述したリクエストテーブル記憶部５２１、ルール記憶部５２３、スレッドテーブル記憶部５２５及びコンテンツ記憶部５２７は、ハードウエア資源（例えば、図３４）を用いて実現される。

中継装置１０７におけるメイン処理について説明する。図６に、メイン処理（Ａ）フローを示す。起動部５０３は、第１受信部５０１が携帯無線端末１０１からコンテンツ取得のリクエストを受信したか否かを判定する（Ｓ６０１）。携帯無線端末１０１からコンテンツ取得のリクエストを受信したと判定した場合には、起動部５０３は、第１取得部５０５によるコンテンツ取得処理を起動する（Ｓ６０３）。

この例におけるコンテンツ取得処理は、メイン処理と並行して実行される。つまり、コンテンツ取得処理は、例えばスレッドとして非同期に動作する。但し、コンテンツ取得処理が、メイン処理と同期するようにしてもよい。

第１取得部５０５は、コンテンツサーバ１０５へコンテンツ取得のリクエストを送信し、コンテンツサーバ１０５からコンテンツを受信する。コンテンツは、コンテンツ記憶部５２７に記憶される。コンテンツを取得すると、第１取得部５０５は、コンテンツの取得完了を特定部５０９に通知する。

ここでは、コンテンツの取得完了を待たずに、Ｓ６０５の処理に移る。そして、記録処理部５０７は、リクエストテーブルにおけるリクエストレコードを登録又は更新する（Ｓ６０５）。

リクエストテーブルについて説明する。図７に、リクエストテーブルの例を示す。リクエストテーブルは、コンテンツ取得のリクエストの受信日時を管理するために用いられる。以下に述べるリクエストテーブルの説明で、コンテンツ取得のリクエストを単にリクエストという。本実施の形態では、ＵＲＬによって特定されるコンテンツサーバ１０５が発行したセッション識別子が共通するリクエストを一連のもの（以下、グループという。）として扱う。尚、セッション識別子は、コンテンツサーバ１０５において携帯無線端末１０１を識別するために用いられるものである。

この例におけるリクエストテーブルは、グループに対応するレコード（以下、リクエストレコードという。）を有している。リクエストレコードは、グループＩＤを設定するためのフィールドと、セッション識別子を設定するためのフィールドと、ＵＲＬを設定するためのフィールドと、今回のリクエストの受信日時を設定するためのフィールドと、前回のリクエストの受信日時を設定するためのフィールドとを有している。

この例における第１リクエストレコードは、ＵＲＬ「https//jp.tube.com/」で特定されるコンテンツサーバ１０５ａが発行したセッション識別子Ｓｅｓｓｉｏｎ＃１を用いるリクエストをグループとして扱い、当該グループにＩＤ「Ｒ０１」が割り当てられていることを示している。更に、第１リクエストレコードは、当該グループに属する最近のリクエストが「2014/10/01 10:40:00.000」に受信され、同じくその前のリクエストが「2014/10/01 10:39:59.000」に受信されたことを示している。

同じく第２リクエストレコードは、ＵＲＬ「http://www.motion.com/」で特定されるコンテンツサーバ１０５ｂが発行したセッション識別子Ｓｅｓｓｉｏｎ＃２を用いるリクエストをグループとして扱い、当該グループにＩＤ「Ｒ０２」が割り当てられていることを示している。更に、第２リクエストレコードは、当該グループに属する最近のリクエストが「2014/10/01 10:40:01.100」に受信され、同じくその前のリクエストが「2014/10/01 10:40:00.000」に受信されたことを示している。

同じく第３リクエストレコードは、ＵＲＬ「http://xxx.video.com/」で特定されるコンテンツサーバ１０５ｃが発行したセッション識別子Ｓｅｓｓｉｏｎ＃３を用いるリクエストをグループとして扱い、当該グループにＩＤ「Ｒ０３」が割り当てられていることを示している。更に、第３リクエストレコードは、当該グループに属する最近のリクエストが「2014/10/01 10:40:02.000」に受信され、同じくその前のリクエストが「2014/10/01 10:40:01.500」に受信されたことを示している。

ＵＲＬによってコンテンツサーバ１０５を特定すれば、コンテンツサーバ１０５毎の特性（リクエストの発生間隔とプリバッファ残量との相関）に応じて、より正しくプリバッファ残量を推定できる。尚、コンテンツ取得のリクエストに含まれるＵＲＬには、上述したＵＲＬの例に加えて、パラメータが付加されている場合がある。

図６に示したＳ６０５の処理の説明に戻る。Ｓ６０１で受信したと判定したリクエストが属するグループが無い場合、つまり初回のリクエストである場合には、記録処理部５０７は、リクエストテーブルに新たなリクエストレコードを登録する。そして、記録処理部５０７は、当該リクエストレコードに新たなグループＩＤを設定する。記録処理部５０７は、当該リクエストレコードに、更にセッション識別子及びＵＲＬも設定する。この時点でセッション識別子が特定されていない場合には、記録処理部５０７は、セッション識別子が特定された時点で当該セッション識別子を設定するようにしてもよい。また、記録処理部５０７は、当該リクエストレコードに、今回のリクエストの受信日時を設定する。初回であれば、前回のリクエストの受信日時は設定されない。

一方、Ｓ６０１で受信したと判定したリクエストが属するグループが有る場合、つまり２回目以降のリクエストである場合には、記録処理部５０７は、この時点で今回のリクエストの受信日時のフィールドに設定されている日時を前回のリクエストの受信日時にコピーする。そして、記録処理部５０７は、今回のリクエストの受信日時のフィールドに新たな受信日時を設定する。

そして、Ｓ６０１に示した処理に戻る。Ｓ６０１において、携帯無線端末１０１からコンテンツ取得のリクエストを受信していないと判定した場合には、特定部５０９は、第１取得部５０５から取得完了の通知を受けたか否かを判定する（Ｓ６０７）。

第１取得部５０５から取得完了の通知を受けたと判定した場合には、特定部５０９は、ＵＲＬ及びリクエストの受信間隔に基づいて、携帯無線端末１０１のアプリケーションプログラム（例えば、ブラウザである。）におけるプリバッファ残量の推定値を特定する（Ｓ６０９）。

プリバッファ残量の推定値を特定するためのルールについて説明する。図８に、ルールの例を示す。この例におけるルールは、サービスと、リクエストの発生間隔のレンジとの組み合わせに対して、プリバッファ残量の推定値を定めている。

例えば、動画サービスＡにおいてリクエストの発生間隔が５００ミリ秒である場合には、動画サービスＡと、リクエストの発生間隔のレンジ「１００ミリ秒〜１秒」との組み合わせに対応する推定量「３０秒分」が特定される。つまり、３０秒間の再生に供されるデータがプリバッファに格納されていると推定される。この例では、プリバッファ残量は、再生時間を単位としている。但し、プリバッファ残量は、データの大きさで表すようにしてもよい。尚、本実施の形態では、リクエストの受信間隔がリクエストの発生間隔であると看做す。また、動画サービス毎のルールをプラグインで追加できるようにしてもよい。

図６の説明に戻る。特定部５０９は、ＵＲＬに基づいてサービスを特定する。また、特定部５０９は、今回のリクエストの受信日時から前回のリクエストの受信日時を引いて、リクエストの受信間隔を得る。そして、図８に示したルールに従って、サービスとリクエストの発生間隔のレンジとの組み合わせに対応するプリバッファ残量の推定値を特定する。この例では、表によるルールの例を示したが、ルールは、サービス毎に設けられた、リクエストの発生間隔を変数とする算出式であってもよい。その場合には、特定部５０９は、算出式に従ってプリバッファ残量の推定値を算出する。

この例では、リクエストの受信間隔に基づいてプリバッファ残量の推定値を特定するが、例えばＴＣＰ（Transmission Control Protocol）におけるＡＣＫ（ACKnowledgment ）の受信間隔に基づいてプリバッファ残量の推定値を特定するようにしてもよい。

また、アプリケーションプログラムにおける再生によってプリバッファ残量が減少することを考慮すれば、このとき特定されたプリバッファ残量の推定値を、時間の経過とともに減らすようにしてもよい。

次に、起動部５０３は、転送部５１１による転送処理を起動する（Ｓ６１１）。転送処理は、メイン処理と並行して処理される。この例では、１つのリクエストに応じた転送処理を行うスレッドが、１つ生成されるものとする。

図９に、転送処理（Ａ）フローを示す。転送部５１１は、スレッドテーブルに新たなスレッドレコードを登録する（Ｓ９０１）。

図１０に、スレッドテーブルの例を示す。この例におけるスレッドテーブルは、その時点で存在するスレッドに対応するレコード（以下、スレッドレコードという。）を有している。スレッドレコードは、スレッドＩＤを設定するためのフィールドと、グループＩＤを設定するためのフィールドと、ステータスを設定するためのフィールドと、プリバッファ残量の推定値を設定するためのフィールドとを有している。

スレッドＩＤは、スレッドを識別する。グループＩＤは、当該スレッドで転送するコンテンツを求めたリクエストが属するグループのＩＤである。つまり、グループＩＤは、スレッドレコードをリクエストレコードに関連付ける。スレッドが未だコンテンツの転送を開始していない場合に、ステータスには「待機中」が設定される。他方、スレッドがコンテンツの転送を開始した場合に、ステータスには「転送中」が設定される。プリバッファ残量の推定値は、コンテンツの転送先である携帯無線端末１０１におけるアプリケーションプログラムにおけるプリバッファ残量を推定した値である。

この例における第１スレッドレコードは、スレッドＩＤ「Ｔ０１」で識別されるスレッドが、グループＩＤ「Ｒ０１」のグループに属するリクエストに基づいて起動され、未だコンテンツの転送を開始していないことを示している。更に、第１スレッドレコードは、このスレッドによるコンテンツの転送先である携帯無線端末１０１におけるアプリケーションプログラムのプリバッファ残量がＢ₁であると推定されていることを示している。

同じく第２スレッドレコードは、スレッドＩＤ「Ｔ０２」で識別されるスレッドが、グループＩＤ「Ｒ０２」のグループに属するリクエストに基づいて起動され、コンテンツの転送を開始したことを示している。更に、第２スレッドレコードは、このスレッドによるコンテンツの転送先である携帯無線端末１０１におけるアプリケーションプログラムのプリバッファ残量がＢ₂であると推定されていることを示している。

同じく第３スレッドレコードは、スレッドＩＤ「Ｔ０３」で識別されるスレッドが、グループＩＤ「Ｒ０３」のグループに属するリクエストに基づいて起動され、未だコンテンツの転送を開始していないことを示している。更に、第３スレッドレコードは、このスレッドによるコンテンツの転送先である携帯無線端末１０１におけるアプリケーションプログラムのプリバッファ残量がＢ₃であると推定されていることを示している。

図９の説明に戻る。Ｓ９０１において、転送部５１１は、新たなスレッドレコードに新たなスレッドＩＤを割り当てる。また、転送部５１１は、当該スレッドにおいて転送すべきコンテンツを取得するリスエストが属するグループのＩＤを設定する。ステータスのフィールドには、「待機中」が設定される。プリバッファ残量の推定値のフィールドには、図６のＳ６０９で特定した値が設定される。

転送部５１１は、判別部５１３から転送開始の指示を受けたか否かを判定する（Ｓ９０３）。判別部５１３から未だ転送開始の指示を受けていないと判定した場合には、転送開始の指示を受けるまで、転送部５１１は、そのまま待機する。

そして、判別部５１３から転送開始の指示を受けたと判定した場合には、転送部５１１は、コンテンツの転送を開始する（Ｓ９０５）。つまり、転送部５１１は、コンテンツ記憶部５２７に記憶されているコンテンツを携帯無線端末１０１に送信する。そして、転送部５１１は、自らのスレッドレコードにおけるステータスを「転送中」に変更する（Ｓ９０７）。

転送部５１１は、コンテンツの転送が完了したか否かを判定する（Ｓ９０９）。コンテンツの転送が完了していないと判定した場合には、コンテンツの転送が完了するまで、転送部５１１は、そのまま待機する。

そして、コンテンツの転送が完了したと判定した場合には、転送部５１１は、コンテンツの転送完了を判別部５１３に通知する（Ｓ９１１）。そして、転送部５１１は、Ｓ９０１で登録した自らのスレッドレコードを削除する（Ｓ９１３）。転送処理（Ａ）を終えると、当該スレッドは消滅する。

図６の説明に戻る。判別部５１３は、監視部５１５から無線ネットワークの状況を取得する（Ｓ６１３）。この例で、監視部５１５は、中継装置１０７と携帯無線端末１０１との間の通信状況を監視する。但し、判別部５１３は、他の装置からノード装置１０３と携帯無線端末１０１との間の通信状況を取得するようにしてもよい。この例で、無線ネットワークの状況には空き帯域幅が含まれるものとする。尚、中継装置１０７がノード装置１０３と一体である場合、あるいはノード装置１０３に近い位置にある場合には、より正確な通信状況を得やすくなるという面がある。

判別部５１３は、判別処理を実行する（Ｓ６１５）。判別処理では、コンテンツの転送を開始させるべきスレッド（転送部５１１に相当する。）を判別する。この処理を、スケジューリングと呼んでもよい。

図１１に、判別処理フローを示す。判別部５１３は、利用する帯域幅を所定帯域幅で割って、並行してコンテンツを転送するスレッドの最大数を求める（Ｓ１１０１）。利用する帯域幅は、空き帯域幅であってもよいし、空き帯域幅の一部であってもよい。所定帯域幅は、１つのスレッド（転送部５１１に相当する。）に割り当てられる帯域幅に相当する。

判別部５１３は、Ｓ１１０１で求めたスレッドの最大数から、転送中であるスレッドの数を引くことによって、新たに転送を開始させるスレッドの数を求める（Ｓ１１０３）。転送中であるスレッドの数は、ステータスのフィールドに「転送中」が設定されているスレッドレコードの数である。新たに転送を開始させるスレッドの数は、無線ネットワークにおける空き帯域が割り当てられるコンテンツ転送処理の許容数に相当する。

判別部５１３は、新たに転送を開始させるスレッドの数が１以上であるか否かを判定する（Ｓ１１０５）。新たに転送を開始させるスレッドの数が０である場合には、そのまま判別処理を終了する。新たに転送を開始させるスレッドの数を、空きスロット数と呼んでもよい。

新たに転送を開始させるスレッドの数が１以上である場合には、判別部５１３は、「待機中」のスレッドのうち、プリバッファ残量の推定値が小さい方から順に、新たに転送を開始させるスレッドの数だけスレッドを選択する（Ｓ１１０７）。そして、判別処理を終えると、図６に示したＳ６１７の処理に移る。

図６の説明に戻る。開始部５１７は、判別結果に従って、新たに転送を開始させるスレッド（転送部５１１に相当する。）にコンテンツの転送の開始を指示する（Ｓ６１７）。新たに転送を開始させるスレッドが無い場合には、Ｓ６１７の処理は省かれる。そして、Ｓ６０１に示した処理に戻って、上述した処理を繰り返す。

Ｓ６０７の説明に戻る。Ｓ６０７において、第１取得部５０５から取得完了の通知を受けていないと判定した場合には、判別部５１３は、いずれかのスレッド（転送部５１１に相当する。）からコンテンツの転送完了の通知を受けたか否かを判定する（Ｓ６１９）。コンテンツの転送完了の通知を受けたと判定した場合には、Ｓ６１３に示した処理に移る。コンテンツの転送が完了すると、空き帯域が広がる。従って、空いた帯域を用いて、別のスレッドが、新たにコンテンツの転送を開始するようになる。

一方、Ｓ６１９においてコンテンツの転送完了の通知を受けていないと判定した場合には、Ｓ６０１に示した処理に戻って、上述した処理を繰り返す。以上で、中継装置１０７における処理についての説明を終える。

本実施の形態によれば、無線ネットワークに接続する携帯無線端末１０１におけるストリーミングをより円滑にできる。

また、コンテンツサーバ１０５及びアプリケーションプログラムに、特別な仕組みを設けなくて済むという面がある。

また、同一のセッションにおけるコンテンツ取得リクエストの受信間隔に基づいて、プリバッファ残量を特定するので、間接的に携帯無線端末１０１におけるプリバッファ残量を把握することができる。

［実施の形態２］
本実施の形態では、同一の携帯無線端末１０１から受信したコンテンツ取得のリクエストに含まれるリクエスト発生時刻の間隔に基づいて、携帯無線端末１０１におけるプリバッファ残量を特定する例について説明する。また、この例では、ストリーミングを行うアプリケーションプログラムの種類に応じて、プリバッファ残量を特定する。つまり、アプリケーションプログラムのロジックに応じたルールを採用する。

本実施の形態では、携帯無線端末１０１にプロキシ機能を設ける。図１２に、携帯無線端末１０１のモジュール構成例を示す。携帯無線端末１０１は、ローカルプロキシ部１２０１、アプリケーションプログラム１２０３及びオペレーティングシステム１２２１を有する。ローカルプロキシ部１２０１は、携帯無線端末１０１内部におけるプロキシとして動作する。アプリケーションプログラム１２０３は、コンテンツを再生する。アプリケーションプログラム１２０３は、例えばブラウザ又は各動画サービス専用の表示プログラムである。携帯無線端末１０１は、種類の異なる複数のアプリケーションプログラム１２０３を有する場合がある。

ローカルプロキシ部１２０１は、受付部１２０５、付加部１２０７、送信部１２０９、第２受信部１２１１、引渡部１２１３、リクエスト記憶部１２１４、コンテンツ記憶部１２１５、復元部１２１７及びフラグメント記憶部１２１９を有する。

受付部１２０５は、アプリケーションプログラム１２０３からコンテンツ取得のリクエストを受け付ける。付加部１２０７は、コンテンツ取得のリクエストのヘッダに各種のデータを付加する。送信部１２０９は、コンテンツ取得のリクエストを、中継装置１０７に送信する。第２受信部１２１１は、中継装置１０７からデータ（例えば、コンテンツ）を受信する。引渡部１２１３は、アプリケーションプログラム１２０３へコンテンツを渡す。リクエスト記憶部１２１４は、コンテンツ取得のリクエストを記憶する。コンテンツ記憶部１２１５は、受信したコンテンツを記憶する。

復元部１２１７及びフラグメント記憶部１２１９は、後述する実施の形態３及び実施の形態４において用いられる。復元部１２１７は、コンテンツから分割されたフラグメントを連結することによって、コンテンツを復元する。フラグメント記憶部１２１９は、フラグメントを記憶する。

上述したローカルプロキシ部１２０１、アプリケーションプログラム１２０３、受付部１２０５、付加部１２０７、送信部１２０９、第２受信部１２１１、引渡部１２１３、復元部１２１７及びオペレーティングシステム１２２１は、ハードウエア資源（例えば、図３３）と、以下で述べる処理をプロセッサに実行させるプログラムとを用いて実現される。

上述したリクエスト記憶部１２１４、コンテンツ記憶部１２１５及びフラグメント記憶部１２１９は、ハードウエア資源（例えば、図３３）を用いて実現される。

ローカルプロキシ部１２０１によるローカルプロキシ処理について説明する。図１３に、ローカルプロキシ処理（Ａ）フローを示す。受付部１２０５は、アプリケーションプログラム１２０３からコンテンツ取得のリクエストを受け付ける（Ｓ１３０１）。コンテンツ取得のリクエストは、リクエスト記憶部１２１４に記憶される。

受付部１２０５は、受付日時を特定し（Ｓ１３０３）、更に要求元のアプリケーションプログラム１２０３を特定する（Ｓ１３０５）。例えば、ソケットにアクセスしてきたプロセスのＩＤに基づいて、アプリケーションプログラム名を特定する。

付加部１２０７は、コンテンツ取得のリクエストのヘッダに端末識別子及びアプリケーション識別子を付加する（Ｓ１３０７）。付加部１２０７は、当該ヘッダに、更にＳ１３０３で特定した受付日時を付加する（Ｓ１３０９）。コンテンツ取得のリクエストの受付日時は、コンテンツ取得のリクエストの発生時刻に相当する。受付日時は、無線ネットワークにおける遅延の影響を受けていない。端末識別子は、例えばＭＡＣ（Media Access Control）アドレスである。

図１４に、コンテンツ取得のリクエストにおけるヘッダの例を示す。この例におけるコンテンツ取得のリクエストは、ｈｔｔｐリクエストの一種である。破線で囲まれた部分が、付加部１２０７によって付加されたデータである。破線で囲まれた部分における第１行は、当該リクエストの送信元である携帯無線端末１０１を識別する端末識別子が「ａａ：ａａ：ａａ：ａａ：ａａ：ａａ」であることを示している。同じく第２行は、当該リクエストの要求元であるアプリケーションプログラム１２０３が、ブラウザであることを示している。同じく第３行は、当該リクエストの送信元である携帯無線端末１０１において、当該リクエストが日時「2014/10/01 10:40:00.000」に受け付けられたことを示している。

この例では、コンテンツ取得のリクエストの受付日時をヘッダに付加するが、携帯無線端末１０１におけるバッテリ残量又は無線通信のスループットなどの情報をヘッダに付加するようにしてもよい。また、携帯無線端末１０１におけるオペレーティングシステム１２２１の種類又はバージョンをヘッダに付加するようにしてもよい。

図１３の説明に戻る。送信部１２０９は、ヘッダが更新されたコンテンツ取得のリクエストを、中継装置１０７に送信する（Ｓ１３１１）。第２受信部１２１１は、待機して、中継装置１０７からコンテンツを受信する（Ｓ１３１３）。受信したコンテンツは、コンテンツ記憶部１２１５に記憶される。そして、引渡部１２１３は、アプリケーションプログラム１２０３へコンテンツを渡す（Ｓ１３１５）。そして、Ｓ１３０１に示した処理に戻って、上述した処理を繰り返す。

続いて、中継装置１０７における処理について説明する。本実施の形態では、図６に示したメイン処理（Ａ）に代えて、メイン処理（Ｂ）を行う。図１５に、メイン処理（Ｂ）フローを示す。Ｓ６０１及びＳ６０３の処理は、図６の場合と同様である。

記録処理部５０７は、リクエストレコードを登録又は更新する（Ｓ１５０１）。

実施の形態２に係るリクエストテーブルについて説明する。図１６に、実施の形態２に係るリクエストテーブルの例を示す。リクエストテーブルは、コンテンツ取得のリクエストの受付日時を管理するために用いられる。但し、本実施の形態では、同じ携帯無線端末１０１における同じアプリケーションプログラム１２０３から発行された、同じＵＲＬに対するリクエストを一連のもの（グループ）として扱う。

リクエストレコードは、グループＩＤを設定するためのフィールドと、端末識別子を設定するためのフィールドと、アプリケーション識別子を設定するためのフィールドと、ＵＲＬを設定するためのフィールドと、今回のリクエストの受付日時を設定するためのフィールドと、前回のリクエストの受付日時を設定するためのフィールドとを有している。リクエストの受付日時は、携帯無線端末１０１のローカルプロキシ部１２０１においてリクエストを受け付けた日時である。端末識別子、アプリケーション識別子及び今回のリクエストの受付日時は、リクエストのヘッダから抽出される。

この例における第１リクエストレコードは、端末識別子「ａａ：ａａ：ａａ：ａａ：ａａ：ａａ」で識別される携帯無線端末１０１ａで動作するブラウザから、ＵＲＬ「https//jp.tube.com/」で特定されるコンテンツサーバ１０５ａへ要求されたリクエストをグループとして扱い、当該グループにＩＤ「Ｒ０１」が割り当てられていることを示している。更に、第１リクエストレコードは、当該グループに属する最近のリクエストが「2014/10/01 10:40:00.000」に受け付けられ、同じくその前のリクエストが「2014/10/01 10:39:59.000」に受け付けられたことを示している。

同じく第２リクエストレコードは、端末識別子「ｂｂ：ｂｂ：ｂｂ：ｂｂ：ｂｂ：ｂｂ」で識別される携帯無線端末１０１ｂで動作する動画サービスＢ専用の表示プログラムから、ＵＲＬ「http://www.motion.com/」で特定されるコンテンツサーバ１０５ｂへ要求されたリクエストをグループとして扱い、当該グループにＩＤ「Ｒ０２」が割り当てられていることを示している。更に、第２リクエストレコードは、当該グループに属する最近のリクエストが「2014/10/01 10:40:01.100」に受け付けられ、同じくその前のリクエストが「2014/10/01 10:40:00.000」に受け付けられたことを示している。

同じく第３リクエストレコードは、端末識別子「ｃｃ：ｃｃ：ｃｃ：ｃｃ：ｃｃ：ｃｃ」で識別される携帯無線端末１０１ｃで動作するブラウザから、ＵＲＬ「http://xxx.video.com/」で特定されるコンテンツサーバ１０５ｃへ要求されたリクエストをグループとして扱い、当該グループにＩＤ「Ｒ０３」が割り当てられていることを示している。更に、第３リクエストレコードは、当該グループに属する最近のリクエストが「2014/10/01 10:40:02.000」に受け付けられ、同じくその前のリクエストが「2014/10/01 10:40:01.500」に受け付けられたことを示している。

図１５に示したＳ１５０１の説明に戻る。初回のリクエストに基づいて、新たなリクエストレコードを登録する場合には、記録処理部５０７は、セッション識別子に代えて、コンテンツ取得のリクエストヘッダに含まれる端末識別子を設定する。記録処理部５０７は、加えて、当該ヘッダに含まれるアプリケーション識別子も、新たなリクエストレコードに設定する。また、記録処理部５０７は、今回のリクエストの受付日時に、当該ヘッダに含まれる受付日時を設定する。

２回目以降のリクエストに基づいて、リクエストレコードを更新する場合には、記録処理部５０７は、この時点で今回のリクエストの受付日時のフィールドに設定されている日時を前回のリクエストの受付日時にコピーする。そして、記録処理部５０７は、今回のリクエストの受付日時のフィールドに、コンテンツ取得のリクエストヘッダに含まれる受付日時を設定する。

Ｓ６０７の処理は、図６の場合と同様である。

Ｓ６０７において、第１取得部５０５から取得完了の通知を受けたと判定した場合には、特定部５０９は、アプリケーション識別子、ＵＲＬ及びリクエストの受付間隔に基づいて、携帯無線端末１０１のアプリケーションプログラム１２０３（例えば、ブラウザ又は各動画サービス専用の表示プログラムである。）のプリバッファ残量の推定値を特定する（Ｓ１５０３）。

プリバッファ残量の推定値を特定するためのルールについて説明する。図１７に、実施の形態２に係るルールの例を示す。この例は、動画サービス専用の表示プログラムを用いた場合の推定ルールを定めている。

この例におけるルールは、図８に示した例と同様に、サービスと、リクエストの発生間隔のレンジとの組み合わせに対して、プリバッファ残量の推定値を定めている。但し、図８に示した例は、ブラウザで動画を再生させる場合におけるプリバッファ量の推定値を定めたものであるが、図１７は、各動画サービス専用の表示プログラムで動画を再生させる場合におけるプリバッファ量の推定値を定めたものである。

例えば、動画サービスＡを動画サービスＡ専用の表示プログラムを利用し、リクエストの発生間隔が５００ミリ秒である場合には、リクエストの発生間隔のレンジ「１００ミリ秒〜１秒」との組み合わせに対応する推定量「３５秒分」が特定される。つまり、３５秒間の再生に供されるデータがプリバッファに格納されていると推定される。この例では、プリバッファ残量は、再生時間を単位としている。但し、プリバッファ残量は、データの大きさで表すようにしてもよい。尚、ブラウザを利用する場合には、図８に示したルールを用いる。

図１５に示したＳ１５０３の処理の説明に戻る。特定部５０９は、実施の形態１の場合と同様に、ＵＲＬに基づいてサービスを特定する。特定部５０９は、今回のリクエストの受付日時から前回のリクエストの受付日時を引いて、リクエストの受付間隔を得る。そして、アプリケーション識別子がブラウザに該当する場合には、図８に示したルールに従って、サービスとリクエストの発生間隔のレンジとの組み合わせに対応するプリバッファ残量の推定値を特定する。一方、アプリケーション識別子が動画サービス専用の表示プログラムに該当する場合には、図１７に示したルールに従って、サービスとリクエストの発生間隔のレンジとの組み合わせに対応するプリバッファ残量の推定値を特定する。実施の形態１の場合と同様に、ルールは、サービス毎に設けられた、リクエストの発生間隔を変数とする算出式であってもよい。

Ｓ６１１乃至Ｓ６１９の処理は、図６の場合と同様である。以上で処理についての説明を終える。

本実施の形態によれば、間接的に携帯無線端末１０１におけるプリバッファ残量を把握することができる。

また、ストリーミングを行うプログラムの種類に応じて、プリバッファ残量を特定するので、携帯無線端末１０１におけるプリバッファ残量をより正しく把握することができる。

［実施の形態３］
本実施の形態では、コンテンツをフラグメントに分割する例について説明する。

上述した例では、同時に転送先となる携帯無線端末１０１の数における上限を定めて、その範囲内で優先度の高い携帯無線端末１０１を選択する。しかし、サイズの大きなコンテンツを送信している間は、帯域に空きが生まれない。従って、優先度が高い携帯無線端末１０１からのリクエストを受信した場合に、直ぐに対応できないという面がある。

本実施の形態では、コンテンツのサイズが一定以上の場合に、コンテンツをいくつかのフラグメントに分割し、例えばｈｔｔｐのＣｈｕｎｋｅｄ Ｔｒａｎｓｆｅｒという仕組みを利用して応答する。

このようにすれば、１回の転送時間を短縮でき、優先度が高い携帯無線端末１０１からのリクエストに応えるタイミングが早まる。

携帯無線端末１０１における処理について説明する。本実施の形態では、図１３に示したローカルプロキシ処理（Ａ）の処理に代えて、ローカルプロキシ処理（Ｂ）を行う。図１８及び後述する図２１に、ローカルプロキシ処理（Ｂ）フローを示す。

Ｓ１３０１乃至Ｓ１３１１の処理は、図１３の場合と同様である。つまり、ローカルプロキシ部１２０１がコンテンツ取得のリクエストを中継装置１０７へ送信するまでの処理は、実施の形態２の場合と同様である。Ｓ１３１１の処理を終えると、端子Ａを介して、図２１に示したＳ２１０１の処理に移る。図２１に示したＳ２１０１以降の処理については、後述する。

一旦、中継装置１０７における処理の説明に移る。この例では、実施の形態２をベースとして説明する。従って、中継装置１０７は、メイン処理（Ｂ）を行う。但し、実施の形態１をベースとする場合には、中継装置１０７は、メイン処理（Ａ）を行うようにしてもよい。

そして、本実施の形態では、図９に示した転送処理（Ａ）の処理に代えて、転送処理（Ｂ）を行う。図１９に、転送処理（Ｂ）フローを示す。転送部５１１は、フラグメントサイズ及びフラグメント数を決定する（Ｓ１９０１）。この例で、フラグメントサイズは、所定値とする。フラグメント数は、コンテンツのサイズをフラグメントサイズで除することによって求められる。尚、余りがある場合には、余りも１つと数える。転送部５１１は、スレッドテーブルに新たなスレッドレコードを登録する（Ｓ１９０３）。

図２０に、実施の形態３に係るスレッドテーブルの例を示す。この例におけるスレッドレコードは、図１０の場合におけるフィールドの他に、フラグメント数を設定するためのフィールドと、フラグメント番号を設定するためのフィールドとを有している。フラグメント数は、転送対象であるコンテンツから分割されたフラグメントの数である。フラグメント番号は、転送を開始したフラグメントの番号である。例えば、フラグメント番号が１である場合には、先頭のフラグメントの転送が完了したことを意味する。フラグメント番号がフラグメント数と一致する場合には、最後のフラグメントの転送が完了したことを意味する。

図１９の説明に戻る。Ｓ１９０１において、転送部５１１は、スレッドＩＤ、グループＩＤ及びプリバッファ残量の推定値を、図９の場合と同様に設定する。フラグメント数のフィールドには、Ｓ１９０１で決定されたフラグメント数が設定される。フラグメント番号には、初期値「０」が設定される。

転送部５１１は、判別部５１３から転送開始の指示を受けたか否かを判定する（Ｓ１９０５）。判別部５１３から転送開始の指示を受けていないと判定した場合には、転送開始の指示を受けるまで、転送部５１１は、そのまま待機する。

そして、判別部５１３から転送開始の指示を受けたと判定した場合には、転送部５１１は、フラグメントの転送を開始する（Ｓ１９０７）。つまり、転送部５１１は、コンテンツ記憶部５２７に記憶されているコンテンツのうち、未だ転送していない部分から、Ｓ１９０１で決定したフラグメントサイズに従ってフラグメントを切り出し、当該フラグメントを携帯無線端末１０１に送信する。尚、未だ転送していない部分がＳ１９０１で決定したサイズよりも小さい場合には、当該部分を最後のフラグメントとする。

Ｓ１９０１の処理において、コンテンツを予め各フラグメントに分割するようにしてもよい。その場合には、Ｓ１９０７におけるフラグメントの切り出しは省いてもよい。

転送部５１１は、自らのスレッドレコードにおけるステータスを「転送中」に変更する（Ｓ１９０９）。転送部５１１は、フラグメントの転送が完了したか否かを判定する（Ｓ１９１１）。フラグメントの転送が完了していないと判定した場合には、フラグメントの転送が完了するまで、転送部５１１は、そのまま待機する。

そして、フラグメントの転送が完了したと判定した場合には、転送部５１１は、フラグメント番号を更新する（Ｓ１９１３）。つまり、転送部５１１は、フラグメント番号に１を加える。

転送部５１１は、コンテンツの転送が完了したか否かを判定する（Ｓ１９１５）。具体的には、転送部５１１は、フラグメント番号がフラグメント数と一致する場合に、コンテンツの転送が完了したと判定する。

コンテンツの転送が完了していないと判定した場合には、転送部５１１は、自らのスレッドレコードにおけるステータスを「待機中」に変更する（Ｓ１９１７）。そして、Ｓ１９０５の処理に戻って、上述した処理を繰り返す。

一方、コンテンツの転送が完了したと判定した場合には、転送部５１１は、コンテンツの転送完了を判別部５１３及び携帯無線端末１０１に通知する（Ｓ１９１９）。そして、転送部５１１は、Ｓ１９０３で登録した自らのスレッドレコードを削除する（Ｓ１９２１）。転送処理（Ｂ）を終えると、当該スレッドは消滅する。

判別処理は、上述した通りである。尚、本実施の形態の場合における図１１に示したＳ１１０１の処理では、利用する帯域幅を所定帯域幅で割って、並行してフラグメントを転送するスレッドの最大数を求めることになる。但し、処理自体は、変わりが無い。

携帯無線端末１０１における処理の説明に戻る。図２１を用いて、携帯無線端末１０１側でコンテンツ取得のリクエストを送信した後のローカルプロキシ処理（Ｂ）について説明する。第２受信部１２１１は、待機して、中継装置１０７からの応答を受信する（Ｓ２１０１）。復元部１２１７は、応答がコンテンツの転送完了の通知であるか否かを判定する（Ｓ２１０３）。

応答がコンテンツの転送完了の通知ではないと判定した場合には、復元部１２１７は、応答がフラグメントであるか否かを判定する（Ｓ２１０５）。応答がフラグメントであると判定した場合には、復元部１２１７は、フラグメントをフラグメント記憶部１２１９に記憶する（Ｓ２１０７）。そして、Ｓ２１０１に示した処理に戻る。

一方、応答がフラグメントではないと判定した場合には、この例では、無効な応答であると看做して、Ｓ２１０１に戻る。但し、コンテンツの転送完了の通知又はフラグメント以外の応答が想定されない場合には、Ｓ２１０３におけるＮｏルートで直接Ｓ２１０７の処理に移るようにしてもよい。

Ｓ２１０３の説明に戻る。Ｓ２１０３において、応答がコンテンツの転送完了の通知であると判定した場合には、復元部１２１７は、フラグメント記憶部１２１９に蓄積したフラグメントを連結することによって、コンテンツを復元する（Ｓ２１０９）。復元されたコンテンツは、コンテンツ記憶部１２１５に記憶される。

引渡部１２１３は、アプリケーションプログラム１２０３へコンテンツを渡すと（Ｓ２１１１）、端子Ｂを介して、図１８に示したＳ１３０１の処理に戻って、上述した処理を繰り返す。

本実施の形態によれば、空き帯域の割り当てをより緻密に行うことができる。

［実施の形態４］
本実施の形態では、携帯無線端末１０１との通信スループット又は携帯無線端末１０１におけるバッテリ残量に基づいて、フラグメントのサイズを決定する例について説明する。

携帯無線端末１０１又は無線ネットワークの状況によっては、フラグメントのサイズを一律にしない方がよい場合がある。

例えばデータ通信の頻度が多くなると、携帯無線端末１０１におけるバッテリの消費が増える。従って、バッテリ残量が少ない携帯無線端末１０１に転送するフラグメントを大きくした方が、バッテリ切れを防げる。逆にバッテリ残量が多い携帯無線端末１０１に転送するフラグメントを小さくした方が、他の優先度の高い携帯無線端末１０１に対する転送の機会が早まる。

また、携帯無線端末１０１毎の通信スループットに応じて，フラグメントのサイズを変えるようにしてもよい。プリバッファ量が少なく、且つ通信スループットの低い携帯無線端末１０１に転送するフラグメントを大きくすれば、当該携帯無線端末１０１における再生が安定しやすい。逆に、プリバッファ量が多く、且つスループットが高い携帯無線端末１０１転送するフラグメントを小さくすれば、他の優先度の高い携帯無線端末１０１に対する転送の機会が早まる。

実施の形態３をベースにして本実施の形態について説明する。まず、携帯無線端末１０１における処理について説明する。本実施の形態では、ローカルプロキシ処理（Ｂ）に代えて、ローカルプロキシ処理（Ｃ）を行う。図２２に、ローカルプロキシ処理（Ｃ）フローを示す。Ｓ１３０１乃至Ｓ１３０９の処理は、図１３の場合と同様である。

付加部１２０７は、オペレーティングシステム１２２１から携帯無線端末１０１のバッテリー残量を取得する。或いは、付加部１２０７は、通信部からスループットを取得する。そして、付加部１２０７は、コンテンツ取得のリクエストのヘッダにバッテリー残量（又はスループット）を付加する（Ｓ２２０１）。

Ｓ１３１１の処理は、図１３の場合と同様である。そして、端子Ａを介して、図２１に示した処理に移る。ローカルプロキシ処理（Ｃ）においても、ローカルプロキシ処理（Ｂ）と同様に、図２１に示した処理を行う。

中継装置１０７における処理の説明に移る。本実施の形態では、転送処理（Ｂ）に代えて、転送処理（Ｃ）を行う。図２３に、転送処理（Ｃ）フローを示す。転送部５１１は、スレッドテーブルに新たなスレッドレコードを登録する（Ｓ２３０１）。

図２４に、実施の形態４に係るスレッドテーブルの例を示す。この例におけるスレッドレコードは、図１０の場合におけるフィールドの他に、フラグメントのサイズを設定するためのフィールドと、未転送量を設定するためのフィールドとを有している。

フラグメントのサイズは、新たに生成するフラグメントの大きさである。未転送量は、コンテンツのうち、未だ転送されていない部分の大きさである。例えば、未転送量がコンテンツの大きさと等しい場合には、未だ先頭のフラグメントが転送されていないことを意味する。未転送量が０である場合には、最後のフラグメントの転送が完了したことを意味する。

図２３の説明に戻る。Ｓ２３０１において、転送部５１１は、スレッドＩＤ、グループＩＤ及びプリバッファ残量の推定値を、図９の場合と同様に設定する。フラグメントのサイズは、この段階では未だ設定されない。未転送量のフィールドには、コンテンツのサイズが設定される。

転送部５１１は、判別部５１３から転送開始の指示を受けたか否かを判定する（Ｓ２３０３）。判別部５１３から転送開始の指示を受けていないと判定した場合には、転送開始の指示を受けるまで、転送部５１１は、そのまま待機する。

そして、判別部５１３から転送開始の指示を受けたと判定した場合には、転送部５１１は、フラグメントサイズを決定する（Ｓ２３０５）。本実施の形態では、バッテリ残量が多い場合には、フラグメントサイズを小さくし、バッテリ残量が少ない場合には、フラグメントサイズを大きくする。

例えば、以下のようにする。（Ａ）プリバッファ残量が多く（例えば５０％以上）、且つバッテリ残量が多い（例えば５０％以上）場合には、フラグメントサイズを小さくする（例えば１０Ｋｂｙｔｅ）。（Ｂ）プリバッファ残量が多く（例えば５０％以上）、且つバッテリ残量が少ない（例えば５０％未満）場合には、フラグメントサイズを中程度にする（例えば５０Ｋｂｙｔｅ）。（Ｃ）プリバッファ残量が少なく（例えば５０％未満）、且つバッテリ残量が多い（例えば５０％以上）場合には、フラグメントサイズを中程度にする（例えば５０Ｋｂｙｔｅ）。（Ｄ）プリバッファ残量が少なく（例えば５０％未満）、且つバッテリ残量が少ない（例えば５０％未満）場合には、フラグメントサイズを大きくする（例えば１００Ｋｂｙｔｅ）。

或いは、転送部５１１は、スループットが閾値より高い場合には、フラグメントサイズを小さくする。他方、スループットが閾値を超えない場合には、転送部５１１は、フラグメントサイズを大きくする。このとき、転送部５１１は、監視部５１５から、携帯無線端末１０１との間におけるスループットを取得するようにしてもよい。

判別部５１３から転送開始の指示を受けたと判定した場合には、転送部５１１は、フラグメントの転送を開始する（Ｓ２３０７）。つまり、転送部５１１は、コンテンツ記憶部５２７に記憶されているコンテンツのうち、未だ転送していない部分から、Ｓ２３０５で決定したフラグメントサイズに従ってフラグメントを切り出し、当該フラグメントを携帯無線端末１０１に送信する。尚、未だ転送していない部分がＳ２３０５で決定したサイズよりも小さい場合には、当該部分を最後のフラグメントとする。従って、この場合におけるフラグメントサイズは、未だ転送していない部分の大きさとなる。

転送部５１１は、自らのスレッドレコードにおけるステータスを「転送中」に変更する（Ｓ２３０９）。転送部５１１は、フラグメントの転送が完了したか否かを判定する（Ｓ２３１１）。フラグメントの転送が完了していないと判定した場合には、フラグメントの転送が完了するまで、転送部５１１は、そのまま待機する。

そして、フラグメントの転送が完了したと判定した場合には、転送部５１１は、未転送量を更新する（Ｓ２３１３）。つまり、転送部５１１は、自らのスレッドレコードにおける未転送量から、フラグメントサイズを減ずる。転送部５１１は、コンテンツの転送が完了したか否かを判定する（Ｓ２３１５）。具体的には、転送部５１１は、自らのスレッドレコードにおける未転送量が０である場合に、コンテンツの転送が完了したと判定する。

コンテンツの転送が完了していないと判定した場合には、転送部５１１は、自らのスレッドレコードにおけるステータスを「待機中」に変更する（Ｓ２３１７）。そして、Ｓ２３０３の処理に戻って、上述した処理を繰り返す。

一方、コンテンツの転送が完了したと判定した場合には、転送部５１１は、コンテンツの転送完了を判別部５１３及び携帯無線端末１０１に通知する（Ｓ２３１９）。そして、転送部５１１は、Ｓ２３０１で登録した自らのスレッドレコードを削除する（Ｓ２３２１）。転送処理（Ｃ）を終えると、当該スレッドは消滅する。

本実施の形態によれば、携帯無線端末１０１との通信スループットに応じて、フラグメントのサイズを決定するので、無線ネットワークにおける通信状況に応じて、より緻密に空き帯域を割り当てることができる。

また、携帯無線端末１０１におけるバッテリ残量に基づいて、フラグメントのサイズを決定するので、携帯無線端末１０１におけるバッテリー切れを予防しやすくなる。

［実施の形態５］
本実施の形態では、アプリケーションプログラム１２０３からコンテンツの再生状況を取得するためのアダプタモジュールの取得方法を定めた定義データを、携帯無線端末１０１に配信する例について説明する。

ユーザが新たなアプリケーションプログラム１２０３をインストールした場合、中継装置１０７において収集すべきデータが、従前のアプリケーションプログラム１２０３から得ていたものと異なることも考えられる。本実施の形態では、新たなアプリケーションプログラム１２０３に応じて、中継装置１０７がデータを収集できるようにする。

また、本実施の形態では、新たなアプリケーションプログラム１２０３は、コンテンツの再生状況に係るデータを提供するインターフェース（例えば、ＡＰＩ（Application Programming Interface））を備えるものとする。アダプタモジュールは、新たなアプリケーションプログラム１２０３のインターフェースを呼び出して得た情報を、汎用的なインターフェースで提供するものである。

図２５に、実施の形態５に係る携帯無線端末１０１のモジュール構成例を示す。携帯無線端末１０１は、図１２に示したモジュールの他に、インストール部２５５１、定義データ記憶部２５５３、アダプタモジュール２５５５及びアンインストール部２５５９を有する。

インストール部２５５１は、アダプタモジュール２５５５をインストールする。定義データ記憶部２５５３は、コンテンツ取得のリクエストのヘッダに付加すべきデータ、及びそのデータを得るために用いられるアダプタモジュール２５５５を定義するデータ（定義データ）を記憶している。ヘッダに付加すべきデータは、アプリケーションプログラム１２０３の再生状況に係るデータであって、以下、アプリケーション品質という。アダプタモジュール２５５５は、アプリケーションプログラム１２０３からアプリケーション品質を得る。アンインストール部２５５９は、アダプタモジュール２５５５をアンインストールする。

また、ローカルプロキシ部１２０１は、図１２に示したモジュールの他に、第２取得部２５５７を有する。第２取得部２５５７は、アダプタモジュール２５５５を介して、アプリケーションプログラム１２０３からアプリケーション品質を取得する。

上述したインストール部２５５１、アダプタモジュール２５５５、第２取得部２５５７及びアンインストール部２５５９は、ハードウエア資源（例えば、図３３）と、以下で述べる処理をプロセッサに実行させるプログラムとを用いて実現される。

上述した定義データ記憶部２５５３は、ハードウエア資源（例えば、図３３）を用いて実現される。

図２６に、インストール処理フローを示す。インストール部２５５１は、オペレーティングシステム１２２１から、アプリケーションプログラム１２０３のインストール完了のイベントを受け付ける（Ｓ２６０１）。インストール部２５５１は、中継装置１０７に、インストールされたアプリケーションプログラム１２０３に対応する定義データを求める。具体的には、インストール部２５５１は、中継装置１０７へ、定義データの要求（アプリケーションプログラム１２０３を識別するアプリケーション識別子を含む。）を送信する（Ｓ２６０３）。

図２７に、定義データの例を示す。まず、上側の破線で囲まれた部分について説明する。headerタグによって、コンテンツ取得のリクエストのヘッダに付加するデータが定義されている。name属性は、ヘッダに付与する項目名を示している。更に、付加されるデータの取得方法も指定されている。この例は、アダプタモジュール「com.foo.bar.MyVideoServiceAdapter」に対して、パラメータ「prebuffer」を指定してアクセスして得られる結果を、項目「X-MyVideoService-Buffer」のパラメータとしてヘッダに付加することを意味する。

次に、下側の破線で囲まれた部分について説明する。moduleタグによって、アプリケーションプログラム１２０３からデータを取得する際に使用されるアダプタモジュールが定義されている。class属性は、アダプタモジュールのクラス名である。url属性は、アダプタモジュールを配信するサイトのＵＲＬである．この例は、サイト「http://repository.foo.bar.com/MyVideoServiceAdapter.apk」からアダプタモジュール「com.foo.bar.MyVideoServiceAdapter」が得られることを示している。

本実施の形態では、このような定義データを用いることによって、ヘッダに付加させるパラメータを任意に設定できるようにする。

図２６の説明に戻る。インストール部２５５１は、中継装置１０７から応答を受信すると（Ｓ２６０５）、受信した応答に基づいて、インストールされたアプリケーションプログラム１２０３に対応する定義データがあったか否かを判定する（Ｓ２６０７）。具体的には、インストール部２５５１は、定義データが無い旨の通知を応答として受信した場合には、インストールされたアプリケーションプログラム１２０３に対応する定義データが無かったと判定する。インストールされたアプリケーションプログラム１２０３に対応する定義データが無かったと判定した場合には、Ｓ２６０１の処理に戻って、上述した処理を繰り返す。

一方、Ｓ２６０５において定義データを受信した場合には、インストールされたアプリケーションプログラム１２０３に対応する定義データが有ったと判定する。インストールされたアプリケーションプログラム１２０３に対応する定義データが有ったと判定した場合には、インストール部２５５１は、受信した定義データを定義データ記憶部２５５３に保存する（Ｓ２６０９）。

インストール部２５５１は、定義データによって特定されるアダプタモジュール２５５５が既にインストールされているか否かを判定する（Ｓ２６１１）。当該アダプタモジュール２５５５が既にインストールされていると判定した場合には、Ｓ２６０１の処理に戻って、上述した処理を繰り返す。

一方、当該アダプタモジュール２５５５が既にインストールされていないと判定した場合には、インストール部２５５１は、定義データに設定されているＵＲＬが示すサイトから当該アダプタモジュール２５５５をインストールする（Ｓ２６１３）。そして、Ｓ２６０１の処理に戻って、上述した処理を繰り返す。

一旦、中継装置１０７における動作について説明する。図２８に、実施の形態５に係る中継装置１０７のモジュール構成例を示す。中継装置１０７は、上述したモジュールに加えて、配信部２８０１及び定義データ格納部２８０３を有している。配信部２８０１は、定義データを配信する。定義データ格納部２８０３は、定義データを記憶している。

図２９に、配信処理フローを示す。配信部２８０１は、携帯無線端末１０１から定義データの要求を受信すると（Ｓ２９０１）、当該要求に含まれるアプリケーション識別子に対応する定義データが定義データ格納部２８０３に格納されているか否かを判定する（Ｓ２９０３）。当該定義データが定義データ格納部２８０３に格納されていないと判定した場合には、配信部２８０１は、定義データが無い旨を携帯無線端末１０１に通知する（Ｓ２９０５）。そして、Ｓ２９０１に示した処理に戻って、上述した処理を繰り返す。

一方、Ｓ２９０３において当該定義データが定義データ格納部２８０３に格納されていると判定した場合には、配信部２８０１は、当該定義データを定義データ格納部２８０３から取得し（Ｓ２９０７）、取得した定義データを携帯無線端末１０１に送信する（Ｓ２９０９）。そして、Ｓ２９０１に示した処理に戻って、上述した処理を繰り返す。

携帯無線端末１０１における動作の説明に戻る。本実施の形態では、ローカルプロキシ処理（Ｂ）に代えて、ローカルプロキシ処理（Ｄ）を行う。図３０に、ローカルプロキシ処理（Ｄ）フローを示す。Ｓ１３０１乃至Ｓ１３０７の処理は、図１３の場合と同様である。

第２取得部２５５７は、アプリケーションプログラム１２０３から、定義データにおいて指定されているアプリケーション品質を取得する（Ｓ３００１）。第２取得部２５５７は、インストールされているアダプタモジュール２５５５を介して、アプリケーションプログラム１２０３からアプリケーション品質を取得する。

アプリケーション品質は、例えばアプリケーションプログラム１２０３におけるプリバッファ残量のようなコンテンツの再生状況に関するデータである。この例では、定義データにおいて、取得するアプリケーション品質としてプリバッファ残量が指定されているものとする。付加部１２０７は、コンテンツ取得のリクエストのヘッダに、取得したアプリケーション品質を付加する（Ｓ３００３）。

Ｓ１３１１の処理は、図１３の場合と同様である。そして、端子Ａを介して、図２１に示した処理に移る。ローカルプロキシ処理（Ｄ）においても、ローカルプロキシ処理（Ｂ）と同様に、図２１に示した処理を行う。

中継装置１０７における動作について説明する。本実施の形態では、図６に示したメイン処理（Ａ）に代えて、メイン処理（Ｃ）を行う。図３１に、メイン処理（Ｃ）フローを示す。

Ｓ６０１及びＳ６０３の処理は、図６の場合と同様である。

記録処理部５０７は、リクエストレコードを登録又は更新する（Ｓ３１０１）。

本実施の形態に係るリクエストテーブルでは、図１６に示したリクエストレコードに、アプリケーション品質を設定するためのフィールドが追加されているものとする。

初回のリクエストに基づいて、新たなリクエストレコードを登録する場合には、図１５に示したＳ１５０１における処理に加えて、当該リクエストレコードにアプリケーション品質を設定する。このとき、アプリケーション品質は、コンテンツ取得のリクエストのヘッダから読み取られる。

２回目以降のリクエストに基づいて、リクエストレコードを更新する場合には、図１５に示したＳ１５０１の場合と同様の処理を行う。

Ｓ６０７の処理は、図６の場合と同様である。

Ｓ６０７において、第１取得部５０５から取得完了の通知を受けたと判定した場合には、特定部５０９は、アプリケーション品質に基づいて、プリバッファ残量を特定する（Ｓ３１０３）。この例では、アプリケーション品質が、プリバッファ残量そのものである。但し、アプリケーション品質に基づいて、プリバッファ残量の推定値を求めるようにしてもよい。

Ｓ６１１乃至Ｓ６１９の処理は、図６の場合と同様である。

携帯無線端末１０１における動作の説明に戻る。図３２に、アンインストール処理フローを示す。アンインストール部２５５９は、オペレーティングシステム１２２１から、アプリケーションプログラム１２０３のアンインストール完了のイベントを受け付ける（Ｓ３２０１）。アンインストール部２５５９は、アンインストールされたアプリケーションプログラム１２０３に対応する定義データが定義データ記憶部２５５３に保存されているか否かを判定する（Ｓ３２０３）。当該定義データが定義データ記憶部２５５３に保存されていないと判定した場合には、Ｓ３２０１に示した処理に戻って、上述した処理を繰り返す。

一方、当該定義データが定義データ記憶部２５５３に保存されていると判定した場合には、アンインストール部２５５９は、当該定義データによって特定されるアダプタモジュール２５５５が、他のアプリケーションプログラム１２０３によって使用されているか否かを判定する（Ｓ３２０５）。

当該定義データによって特定されるアダプタモジュール２５５５が、他のアプリケーションプログラム１２０３によって使用されていると判定した場合には、Ｓ３２０１に示した処理に戻って、上述した処理を繰り返す。

一方、当該定義データによって特定されるアダプタモジュール２５５５が、他のアプリケーションプログラム１２０３によって使用されていないと判定した場合には、アンインストール部２５５９は、当該アダプタモジュール２５５５をアンインストールする（Ｓ３２０７）。アンインストール部２５５９は、更に当該定義データを削除する（Ｓ３２０９）。

そして、Ｓ３２０１に示した処理に戻って、上述した処理を繰り返す。

本実施の形態によれば、携帯無線端末１０１におけるコンテンツの再生状況をより正しく把握することができる。

図３３に、携帯無線端末１０１のハードウエア構成例を示す。携帯無線端末１０１は、ＣＰＵ（Central Processing Unit）３３０１、記憶回路３３０３、無線通信用アンテナ３３１１、無線通信制御回路３３１３、スピーカ制御回路３３１５、スピーカ３３１７、マイク制御回路３３１９、マイク３３２１、ＬＣＤ（Liquid Crystal Display）制御回路３３２３、ＬＣＤ３３２５、タッチパッド３３２７、キー群３３２９、ＧＰＳ（Global Positioning System）装置３３３１及びカメラ３３３３を有している。

ＣＰＵ３３０１は、モデムＣＰＵとアプリケーションＣＰＵとからなることもある。記憶回路３３０３は、例えば、ＲＯＭ（Read Only Memory）３３０５とＲＡＭ（Random Access Memory）３３０７とフラッシュメモリ３３０９とを有している。ＲＯＭ３３０５は、例えば、オペレーティングシステムなどのプログラムや予め設定されているデータを格納している。ＲＡＭ３３０７は、例えばアプリケーションなどのプログラムを展開する領域を含んでいる。ＲＡＭ３３０７は、一時的なデータを格納する領域も含んでいる。フラッシュメモリ３３０９は、例えば、アプリケーションなどのプログラムや保持すべきデータを格納している。

ＬＣＤ制御回路３３２３は、所定の動作周波数でクロック回路を動作させ、ＬＣＤ３３２５を駆動させる。ＬＣＤ３３２５は、表示画面を表示する。タッチパッド３３２７は、例えば、ＬＣＤ３３２５の表示面上に配置されたパネル状のセンサであり、タッチ操作による指示を受け付ける。具体的には、ＬＣＤ３３２５とタッチパッド３３２７とは、一体としたタッチパネルとして用いられる。キー群３３２９の各ハードキーは、筐体の一部に設けられている。

無線通信用アンテナ３３１１は、近距離無線通信方式、セルラー方式及び無線ＬＡＮ方式による無線電波を受信する。無線通信用アンテナ３３１１は、複数のアンテナを含んでいてもよい。無線通信制御回路３３１３は、各方式における使用周波数に応じて無線通信の制御を行う。

スピーカ制御回路３３１５は、音データに関するデジタル／アナログ変換を行う。スピーカ３３１７は、アナログデータを音として出力する。マイク制御回路３３１９は、音データに関するアナログ／デジタル変換を行う。マイク３３２１は、音をアナログデータに変換する。

ＧＰＳ装置３３３１は、位置を計測する。カメラ３３３３は、例えば静止画像及び動画像を撮影する。

以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上述の機能ブロック構成はプログラムモジュール構成に一致しない場合もある。

また、上で説明した各記憶領域の構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ、処理の順番を入れ替えることや複数の処理を並列に実行させるようにしても良い。

なお、上で述べた中継装置１０７は、コンピュータ装置であって、図３４に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

中継装置１０７は、複数の通信制御部２５１７を有するようにしてもよい。

以上述べた本発明の実施の形態をまとめると、以下のようになる。

本実施の形態に係る中継方法は、（Ａ）ストリーミングを行う端末から無線ネットワークを介して受信したコンテンツ取得リクエストに応じて、コンテンツ配信装置からコンテンツを取得する処理と、（Ｂ）コンテンツの転送先である端末におけるプリバッファ残量を特定する特定処理と、（Ｃ）無線ネットワークにおける空き帯域が割り当てられるコンテンツ転送処理の許容数が、待機しているコンテンツ転送処理の数に満たない場合に、プリバッファ残量が少ない方の端末へのコンテンツの転送を開始させる処理とを含む。

このようにすれば、無線ネットワークに接続する端末におけるストリーミングをより円滑にできる。

上記特定処理において、同一のセッションにおけるコンテンツ取得リクエストの受信間隔に基づいて、プリバッファ残量を特定するようにしてもよい。

このようにすれば、間接的に端末におけるプリバッファ残量を把握することができる。

上記特定処理において、同一の端末から受信したコンテンツ取得のリクエストに含まれるリクエスト発生時刻の間隔に基づいて、当該端末におけるプリバッファ残量を特定するようにしてもよい。

このようにすれば、間接的に端末におけるプリバッファ残量を把握することができる。

上記特定処理において、ストリーミングを行うプログラムの種類に応じて、プリバッファ残量を特定するようにしてもよい。

このようにすれば、端末におけるプリバッファ残量をより正しく把握することができる。

上記コンテンツ転送処理は、コンテンツを複数回に分けて転送する処理であってもよい。そして、上記コンテンツ転送処理において、１回分の転送を終えると、再開されるまで待機するようにしてもよい。

このようにすれば、空き帯域の割り当てをより緻密に行うことができる。

上記コンテンツ転送処理において、端末との通信スループットに応じて、１回に転送されるデータのサイズを決定するようにしてもよい。

このようにすれば、無線ネットワークにおける通信状況に応じて、より緻密に空き帯域を割り当てることができる。

上記コンテンツ転送処理において、端末におけるバッテリ残量に基づいて、１回に転送されるデータのサイズを決定するようにしてもよい。

このようにすれば、端末におけるバッテリー切れを予防しやすくなる。

更に、ストリーミングを行うプログラムからコンテンツの再生状況を取得するためのアダプタモジュールの取得方法を定めたデータを、端末に配信する処理を含むようにしてもよい。

このようにすれば、端末におけるコンテンツの再生状況をより正しく把握することができる。

なお、上記方法による処理をコンピュータに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納されるようにしてもよい。尚、中間的な処理結果は、一般的にメインメモリ等の記憶装置に一時保管される。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
ストリーミングを行う端末から無線ネットワークを介して受信したコンテンツ取得リクエストに応じて、コンテンツ配信装置からコンテンツを取得する処理と、
前記コンテンツの転送先である前記端末におけるプリバッファ残量を特定する特定処理と、
前記無線ネットワークにおける空き帯域が割り当てられるコンテンツ転送処理の許容数が、待機しているコンテンツ転送処理の数に満たない場合に、前記プリバッファ残量が少ない方の端末への前記コンテンツの転送を開始させる処理と
を含み、コンピュータにより実行される中継方法。

（付記２）
前記特定処理において、
同一のセッションにおけるコンテンツ取得リクエストの受信間隔に基づいて、前記プリバッファ残量を特定する
付記１記載の中継方法。

（付記３）
前記特定処理において、
同一の端末から受信したコンテンツ取得のリクエストに含まれるリクエスト発生時刻の間隔に基づいて、当該端末における前記プリバッファ残量を特定する
付記１記載の中継方法。

（付記４）
前記特定処理において、
前記ストリーミングを行うプログラムの種類に応じて、前記プリバッファ残量を特定する
付記１乃至３のいずれか１つ記載の中継方法。

（付記５）
前記コンテンツ転送処理は、前記コンテンツを複数回に分けて転送する処理であって、
前記コンテンツ転送処理において、１回分の転送を終えると、再開されるまで待機する
付記１乃至４のいずれか１つ記載の中継方法。

（付記６）
前記コンテンツ転送処理において、前記端末との通信スループットに応じて、１回に転送されるデータのサイズを決定する
付記５記載の中継方法。

（付記７）
前記コンテンツ転送処理において、前記端末におけるバッテリ残量に基づいて、１回に転送されるデータのサイズを決定する
付記５記載の中継方法。

（付記８）
更に、
前記ストリーミングを行うプログラムからコンテンツの再生状況を取得するためのアダプタモジュールの取得方法を定めたデータを、前記端末に配信する処理
を含む付記１記載の中継方法。

（付記９）
ストリーミングを行う端末から無線ネットワークを介して受信したコンテンツ取得リクエストに応じて、コンテンツ配信装置からコンテンツを取得する処理と、
前記コンテンツの転送先である前記端末におけるプリバッファ残量を特定する処理と、
前記無線ネットワークにおける空き帯域が割り当てられるコンテンツ転送処理の許容数が、待機しているコンテンツ転送処理の数に満たない場合に、前記プリバッファ残量が少ない方の端末への前記コンテンツの転送を開始させる処理と
をコンピュータに実行させる中継プログラム。

（付記１０）
ストリーミングを行う端末から無線ネットワークを介して受信したコンテンツ取得リクエストに応じて、コンテンツ配信装置からコンテンツを取得する取得部と、
前記コンテンツの転送先である前記端末におけるプリバッファ残量を特定する特定部と、
前記無線ネットワークにおける空き帯域が割り当てられるコンテンツ転送処理の許容数が、待機しているコンテンツ転送処理の数に満たない場合に、前記プリバッファ残量が少ない方の端末への前記コンテンツの転送を開始させる開始部と
を含む中継装置。

１０１ 携帯無線端末 １０３ ノード装置
１０５ コンテンツサーバ １０７ 中継装置
５０１ 第１受信部 ５０３ 起動部
５０５ 第１取得部 ５０７ 記録処理部
５０９ 特定部 ５１１ 転送部
５１３ 判別部 ５１５ 監視部
５１７ 開始部 ５２１ リクエストテーブル記憶部
５２３ ルール記憶部 ５２５ スレッドテーブル記憶部
５２７ コンテンツ記憶部 １２０１ ローカルプロキシ部
１２０３ アプリケーションプログラム １２０５ 受付部
１２０７ 付加部 １２０９ 送信部
１２１１ 第２受信部 １２１３ 引渡部
１２１４ リクエスト記憶部 １２１５ コンテンツ記憶部
１２１７ 復元部 １２１９ フラグメント記憶部
１２２１ オペレーティングシステム ２５５１ インストール部
２５５３ 定義データ記憶部 ２５５５ アダプタモジュール
２５５７ 第２取得部 ２５５９ アンインストール部
２８０１ 配信部 ２８０３ 定義データ格納部

Claims (10)

1. ストリーミングを行う端末から無線ネットワークを介して受信したコンテンツ取得リクエストに応じて、コンテンツ配信装置からコンテンツを取得する処理と、
   前記コンテンツの転送先である前記端末におけるプリバッファ残量を特定する特定処理と、
   前記コンテンツの転送先である前記端末への前記コンテンツの転送を行い且つ転送の開始が指示されるまで待機するコンテンツ転送処理であって前記無線ネットワークにおける空き帯域を割り当て可能なコンテンツ転送処理の許容数が、１以上であって、待機しているコンテンツ転送処理の数に満たない場合に、前記プリバッファ残量が少ない方の端末への前記コンテンツの転送を開始させる処理と
   を含み、コンピュータにより実行される中継方法。
2. 前記特定処理において、
   同一のセッションにおけるコンテンツ取得リクエストの受信間隔に基づいて、前記プリバッファ残量を特定する
   請求項１記載の中継方法。
3. 前記特定処理において、
   同一の端末から受信したコンテンツ取得のリクエストに含まれるリクエスト発生時刻の間隔に基づいて、当該端末における前記プリバッファ残量を特定する
   請求項１記載の中継方法。
4. 前記特定処理において、
   前記ストリーミングを行うプログラムの種類に応じて、前記プリバッファ残量を特定する
   請求項１乃至３のいずれか１つ記載の中継方法。
5. 前記コンテンツ転送処理は、前記コンテンツを複数回に分けて転送する処理であって、
   前記コンテンツ転送処理において、１回分の転送を終えると、再開されるまで待機する
   請求項１乃至４のいずれか１つ記載の中継方法。
6. 前記コンテンツ転送処理において、前記端末との通信スループットに応じて、１回に転送されるデータのサイズを決定する
   請求項５記載の中継方法。
7. 前記コンテンツ転送処理において、前記端末におけるバッテリ残量に基づいて、１回に転送されるデータのサイズを決定する
   請求項５記載の中継方法。
8. 更に、
   前記ストリーミングを行うプログラムからコンテンツの再生状況を取得するためのアダプタモジュールの取得方法を定めたデータを、前記端末に配信する処理
   を含む請求項１記載の中継方法。
9. ストリーミングを行う端末から無線ネットワークを介して受信したコンテンツ取得リクエストに応じて、コンテンツ配信装置からコンテンツを取得する処理と、
   前記コンテンツの転送先である前記端末におけるプリバッファ残量を特定する処理と、
   前記コンテンツの転送先である前記端末への前記コンテンツの転送を行い且つ転送の開始が指示されるまで待機するコンテンツ転送処理であって前記無線ネットワークにおける空き帯域を割り当て可能なコンテンツ転送処理の許容数が、１以上であって、待機しているコンテンツ転送処理の数に満たない場合に、前記プリバッファ残量が少ない方の端末への前記コンテンツの転送を開始させる処理と
   をコンピュータに実行させる中継プログラム。
10. ストリーミングを行う端末から無線ネットワークを介して受信したコンテンツ取得リクエストに応じて、コンテンツ配信装置からコンテンツを取得する取得部と、
    前記コンテンツの転送先である前記端末におけるプリバッファ残量を特定する特定部と、
    前記コンテンツの転送先である前記端末への前記コンテンツの転送を行い且つ転送の開始が指示されるまで待機するコンテンツ転送処理であって前記無線ネットワークにおける空き帯域を割り当て可能なコンテンツ転送処理の許容数が、１以上であって、待機しているコンテンツ転送処理の数に満たない場合に、前記プリバッファ残量が少ない方の端末への前記コンテンツの転送を開始させる開始部と
    を含む中継装置。

Images