JP2016015566A - 端末装置及びデータ配信方法 - Google Patents

Abstract

【課題】データ再生部には何ら変更を加えることなく、該データ再生部に破綻なく配信データを供給することができるようにする。【解決手段】 取得部１２により、データ再生部１１からの要求に応じた配信データをデータ配信装置１６から受信して、該要求に応じた転送速度でデータ再生部１１に転送すると共に、データ配信装置１６との間の通信経路における通信状況を取得し、判定部１３により、取得部１２によって取得した通信状況に基づいて、現在時点のビットレートより高ビットレートの配信データの受信に切り換え可能か否かを判定し、切換部１４により、判定部１３によって切り換え可能と判定された場合、上記高ビットレートの配信データの受信に切り換えると共に、受信した配信データのデータ再生部１１への転送速度を、現在時点より速い速度に切り換える。【選択図】図１

Description

開示の技術は端末装置及びデータ配信方法に関する。

近年、様々な端末装置に向けて映像データ等を配信する技術として、ＨＴＴＰ（Hypertext Transfer Protocol）と呼ばれているプロトコルを用いてストリームデータを配信する技術が活用されるようになってきた。また、ストリームデータの配信技術として、ストリームデータを時間軸の方向に複数のファイル断片（セグメント）に分割し、クライアント端末装置（以下、「端末装置」という。）の要求するファイルをＨＴＴＰによって送信する技術が知られている。この技術では、端末装置が受信したファイルのセグメントを逐次連続的に再生することで動画の視聴を可能とする。この技術の代表的なものとして、ＭＰＥＧ−ＤＡＳＨ（Moving Picture Experts Group(MPEG)-Dynamic Adaptive Streaming over HTTP）による技術があり、ＩＳＯ／ＩＥＣ２３００９−１として標準化が進んでいる。

この種のストリームデータの配信に関する従来の技術として、端末装置がサーバからルータを介して映像コンテンツ等のストリームデータを受信する形態において、ルータにより各装置間の通信品質を測定する技術が提案されている。この技術では、所定の伝送レートのテストコンテンツのストリームデータを用いて、サーバと端末装置との間、及びサーバとルータとの間のそれぞれの通信品質を測定する。また、この技術では、この通信品質の測定結果に基づいて、サーバと端末装置との間、及びサーバとルータとの間のそれぞれで上記所定の伝送レートのストリームデータが受信可能か否かを判断する。そして、この技術では、前者が受信不可で後者が受信可能の場合、端末装置により、サーバから受信しているテストコンテンツを切り替えずに、ルータに該テストコンテンツのデータ量を削減させたストリームデータを受信して通信品質の測定を行う。

また、従来の技術として、第１の送信レートでサーバからストリームデータを送信し、この送信で損失したパケット数と閾値とを比較し、該比較に基づいて第１の送信レートで送信を続けるか又は第２の送信レートに送信を切り替える技術も提案されている。

特開２００８−２９４７８４号公報 特表２００９−５１４３０３号公報

ところで、ＭＰＥＧ−ＤＡＳＨ等のマルチビットレートに対応したストリームデータを端末装置により受信して、該端末装置に設けられた後述するローカルプロキシサーバを介してメディアプレーヤに代表されるデータ再生部で再生する場合を考える。この場合、一般に、ローカルプロキシサーバを基準としてデータ配信サーバ側及びデータ再生部側のそれぞれの通信区間の通信速度には大きな速度差がある。具体的には、データ配信サーバ側の通信速度より、データ再生部側の方が著しく通信速度が速い。このため、データ再生部が、より高ビットレートの配信データを要求した場合、ローカルプロキシサーバによるストリームデータの取得が間に合わず、ストリームデータのデータ再生部への供給が破綻してしまう場合があるという問題があった。

この問題に関連して、前述した従来の技術は、データ配信サーバとローカルプロキシサーバとの間の通信状況に関しては考慮されておらず、該問題を解決することはできない。なお、この問題は、端末装置に設けられたローカルプロキシサーバがストリームデータの受信に介在する場合に限らず、ハードウェアにより単体構成とされたプロキシサーバがストリームデータの受信に介在する場合にも生じ得る問題である。

開示の技術は、一つの側面として、データ再生部には何ら変更を加えることなく、該データ再生部に破綻なく配信データを供給することができるようにすることが目的である。

開示の技術は、動画及び音声の少なくとも一方を表し、マルチビットレートに対応した配信データから、何れかのビットレートの配信データの配信を選択的に要求し、該要求に応じて受信した配信データを再生するデータ再生部を備える。また、開示の技術は、前記データ再生部からの要求に応じた配信データをデータ配信装置から受信して、該要求に応じた転送速度で前記データ再生部に転送すると共に、前記データ配信装置との間の通信経路における通信状況を取得する取得部を備える。また、開示の技術は、前記取得部によって取得された通信状況に基づいて、現在時点のビットレートより高ビットレートの配信データの受信に切り換え可能か否かを判定する判定部を備える。また、開示の技術は、前記判定部によって切り換え可能と判定された場合、前記高ビットレートの配信データの受信に切り換えると共に、受信した配信データの前記データ再生部への転送速度を、現在時点より速い速度に切り換える切換部を備える。

開示の技術は、一つの側面として、データ再生部には何ら変更を加えることなく、該データ再生部に破綻なく配信データを供給することができる、という効果を有する。

第１実施形態に係る端末装置の機能ブロック図である。 第１実施形態に係るコンピュータ・システムの概略構成を示すブロック図である。 端末情報管理テーブルの一例を示す図表である。 コンピュータ・システムの基本的な動作の説明に供するブロック図である。 コンピュータ・システムで用いられる各種メッセージの構成例を示す概略図である。 テスト・切換処理の一例を示すフローチャートである。 データ転送処理の一例を示すフローチャートである。 Ｐ２Ｐによるシステムにおける他の端末装置からストリームデータを取得する場合の通信状態の一例を示すタイムチャートである。 第２実施形態に係る端末装置の機能ブロック図である。 ウェブ（Ｗｅｂ）・ブラウザによりウェブ・サーバから各種情報を取得する場合の概略構成の一例を示すブロック図である。 移動端末装置により映像配信サーバからストリームデータを取得する場合の概略構成の一例を示すブロック図である。 第２実施形態に係る移動端末装置の構成を示すブロック図である。 第２実施形態に係る速度マップデータベースの一例を示す図表である。 移動端末装置により映像配信サーバからストリームデータを取得する場合の通信状態の一例を示すタイムチャートである。 プロキシサーバがハードウェア構成とされた場合の接続状態の一例を示すブロック図である。

以下、図面を参照して開示の技術の実施形態の一例を詳細に説明する。

〔第１実施形態〕

図１には、本実施形態に係る端末装置１０が示されている。図１に示すように、本実施形態に係る端末装置１０は、データ再生部１１、取得部１２、判定部１３及び切換部１４を備えている。

データ再生部１１は、動画及び音声の少なくとも一方を表し、マルチビットレートに対応した配信データ（本実施形態では、ストリームデータ）から、何れかのビットレートの配信データの配信を選択的に要求し、該要求に応じて受信した配信データを再生する。なお、本実施形態では、データ再生部１１として、コンピュータ上で動画や音声の電子ファイルを再生するためのアプリケーション・ソフトウェアとして構成されたメディアプレーヤを適用しているが、これに限定されるものではない。例えば、ハードウェアにより構成された映像再生装置や、ソフトウェアにより構成されたメディアプレーヤ以外の映像再生プログラム等をデータ再生部１１として適用してもよい。

一方、取得部１２は、データ再生部１１からの要求に応じた配信データをデータ配信装置１６から受信して、該要求に応じた転送速度でデータ再生部１１に転送すると共に、データ配信装置１６との間の通信経路における通信状況を取得する。なお、取得部１２では、データ再生部１１からの要求に応じたビットレートの配信データである第１の配信データを受信している場合に、該ビットレートより高いビットレートの配信データである第２の配信データをデータ配信装置１６に要求して受信する。そして、取得部１２では、該第２の配信データの受信に要した時間に基づいて通信状況を取得する。

なお、本実施形態では、後述するようにＰ２Ｐ（Peer to Peer、ピア・ツー・ピア）技術により他の端末装置１０から配信データを受信する場合があるが、この場合に、取得部１２は、該他の端末装置１０との間の通信経路における通信状況を取得する。また、本実施形態では、上記通信経路としてネットワーク８０を適用している。

また、判定部１３は、取得部１２によって取得された通信状況に基づいて、現在時点のビットレートより高ビットレートの配信データの受信に切り換え可能か否かを判定する。なお、本実施形態に係る判定部１３は、取得部１２によって取得された通信状況に基づいて、現在時点のビットレートより低ビットレートの配信データの受信に切り換える必要があるか否かをさらに判定する。

さらに、切換部１４は、判定部１３によって切り換え可能と判定された場合、上記高ビットレートの配信データの受信に切り換えると共に、受信した配信データのデータ再生部１１への転送速度を、現在時点より速い速度に切り換える。なお、本実施形態に係る切換部１４は、判定部１３によって切り換え可能と判定された場合、上記第２の配信データの受信に要した時間に基づいて上記転送速度を切り換える。また、本実施形態に係る切換部１４は、判定部１３により、上記低ビットレートの配信データの受信に切り換える必要があると判定された場合、該低ビットレートの配信データの受信に切り換える。そして、この場合、切換部１４は、受信した配信データのデータ再生部１１への転送速度を、現在時点より遅い速度に切り換える。

本実施形態に係る端末装置１０では、切換部１４を、データ配信装置１６から受信する配信データの切り換えを行う第１切換部１４Ａと、データ再生部１１への配信データの転送速度の切り換えを行う第２切換部１４Ｂと、の２つの切換部に区分している。すなわち、第１切換部１４Ａは、より高ビットレートの配信データの受信に切り換えたり、より低ビットレートの配信データの受信に切り換えたりする。また、第２切換部１４Ｂは、受信した配信データのデータ再生部１１への転送速度を、現在時点より速い速度に切り換えたり、現在時点より遅い速度に切り換えたりする。

なお、本実施形態に係る端末装置１０では、上記配信データとして、動画及び音声の双方を含む映像を表す映像データを適用し、データ配信装置１６として、映像配信サーバを適用している。端末装置１０におけるデータ再生部１１は開示の技術に係るデータ再生部の一例であり、取得部１２は開示の技術に係る取得部の一例であり、判定部１３は開示の技術に係る判定部の一例であり、切換部１４は開示の技術に係る切換部の一例である。

ところで、本実施形態では、端末装置１０のデータ再生部１１が再生対象とする映像データとして、上述したＭＰＥＧ−ＤＡＳＨにより規定されるデータを適用している。ＭＰＥＧ−ＤＡＳＨは、上述したようにマルチビットレートの切り換えに対応している。また、ＭＰＥＧ−ＤＡＳＨによる配信では、メディアプレーヤは、ストリームデータの受信速度に余裕があると判断すると、より高いビットレート（高画質、高音質）の映像データの配信に要求を切り換え、ユーザは、より高品質の映像の視聴が体験できる。

また、メディアプレーヤは、一般に、映像の視聴を開始する際には、複数のビットレートのストリームデータのうち、まずビットレートが最も低いストリームデータを要求し、該ストリームデータの受信速度を計測しながら映像の再生を開始する。次いで、メディアプレーヤは、受信速度がより高いビットレートのストリームデータ（以下、「高ビットレートデータ」という。）の受信が十分に行えると判断すると、要求するストリームデータを高ビットレートデータへと切り換える。

一方、端末装置は、高ビットレートデータを受信している間も受信速度を計測し、実際の受信速度が該高ビットレートデータの受信に不十分となった場合には、より低いビットレートのストリームデータ（以下、「低ビットレートデータ」という。）に切り換える。このように、ＭＰＥＧ−ＤＡＳＨは、ネットワークの条件により時々刻々と変化するストリームデータの受信速度に応じ、要求するストリームデータのビットレートを切り換えることで、可能な限り高い映像品質でストリームデータの取得を試みる技術とされている。

一方、映像配信サーバにおける映像データの配信のための処理の負荷や、ネットワークにおける通信の負荷を軽減する観点から、負荷を分散するための技術として、Ｐ２Ｐ技術が知られている。

すなわち、従来のクライアント・サーバ型のデータ配信技術では、データを受信する端末装置の数の増加に伴い、それに比例したデータ配信のための負荷が映像配信サーバに発生する。そのため、規模が比較的大きなシステムにおいては、アクセスが集中する映像配信サーバやネットワーク基盤の増強が必須であり、データ配信のためのコストの低減が課題となる。この課題を解決するための技術として、近年、Ｐ２Ｐ技術を応用したデータ配信技術が注目されている。

Ｐ２Ｐ技術による映像データの配信では、映像配信サーバが映像データを受信する端末装置の全てに該映像データを直接配信するのではなく、一部の端末装置のみに該映像データを配信する。そして、Ｐ２Ｐ技術では、映像配信サーバから映像データを受信した端末装置が、受信した映像データを再生するだけでなく、該映像データを別の端末装置へ転送することで、該別の端末装置が映像データを再生できるようになる。この場合、映像配信サーバは上記別の端末装置へ映像データを配信しなくてよいため、該配信のための負荷を軽減することができる。

このように、Ｐ２Ｐ技術によるストリーミング配信では、ストリームデータを受信した端末装置が、該ストリームデータを他の端末装置へ中継することができるため、ストリームデータを次々にリレー配信することにより大規模な一斉同報配信を行うことができる。従って、Ｐ２Ｐ技術によるストリーミング配信は、端末装置の増加に対する映像配信サーバのデータ配信のための負荷の増加が緩やか、若しくは影響がない、という特徴を備えている。そして、Ｐ２Ｐ技術によるストリーミング配信は、物理的なネットワークの環境を意識しない、端末装置間の論理リンクで形成される論理ネットワーク（オーバーレイ・ネットワーク）上でのデータ配信を行っていると見なすことができる。

また、Ｐ２Ｐ技術による映像配信システムでは、ストリームデータの取得を行うＰ２Ｐクライアントモジュールと、映像の再生を行う一般的なメディアプレーヤとを同一の端末装置内に分離して配備することが可能である。そして、この形態では、Ｐ２Ｐクライアントモジュールがメディアプレーヤからの映像データの取得の要求を受けて、対象とするストリームデータを映像配信サーバ、または他のＰ２Ｐクライアントモジュールから取得し、メディアプレーヤへと供給する。すなわち、Ｐ２Ｐクライアントモジュールは、メディアプレーヤにとって、映像配信サーバからのストリームデータの取得を代行する、ローカルプロキシサーバ（以下、単に「プロキシサーバ」ともいう。）と見なすことができる。

ところで、Ｐ２Ｐ技術による映像配信システムでは、一般に、プロキシサーバを基準として映像配信サーバ側及びメディアプレーヤ側のそれぞれの通信区間の通信速度には大きな速度差がある。上述したように、プロキシサーバとメディアプレーヤは同一の端末装置に配備される。従って、プロキシサーバとメディアプレーヤとの間の通信速度は映像配信サーバや他の端末装置とプロキシサーバとの間の通信速度に比較して高速であり、該通信速度とは無相関である。

また、Ｐ２Ｐ技術による映像配信システムでは、Ｐ２Ｐクライアントモジュールは必要なストリームデータを確実かつ速やかに他の端末装置等から取得できるとは限らない。このため、Ｐ２Ｐクライアントモジュールは、可能な限り先読みを行ってキャッシュ（Cache）しておくことにより、メディアプレーヤからのストリームデータの要求に備える必要がある。

ここで、プロキシサーバがメディアプレーヤからのストリームデータの送信要求に対して素直に応答し、先読みしてキャッシュしたストリームデータを供給する場合を考える。この場合、メディアプレーヤからみた見かけ上の映像配信サーバ等へのストリームデータの送信要求に対するストリームデータの取得が非常に高速に完了する。このため、メディアプレーヤは、その時点で受信しているストリームデータのビットレートよりも高いビットレートのデータ（高ビットレートデータ）を取得するように、受信対象とするストリームデータを切り換える動作を行う。

しかし、実際に行われた先読みによるキャッシング処理では、受信中のストリームデータがぎりぎりで受信できる通信速度でようやく受信できた可能性もある。従って、このような状況でメディアプレーヤが高ビットレートデータを要求すると、ストリームデータの取得が間に合わず、ストリームデータのメディアプレーヤへの供給が破綻してしまう可能性があった。また、対象とするストリームデータが切り換えられると、プロキシサーバにおける先読みの予測が外れることとなり、安定性も低下する場合があった。

なお、これらの問題は、通信プロトコルとしてＭＰＥＧ−ＤＡＳＨを適用した場合のみに生じる問題ではなく、マルチビットレートに対応した通信プロトコルを適用した場合には生じ得る問題である。例えば、通信プロトコルとして、マイクロソフト社のスムーズ・ストリーミングや、アドビシステムズ社によるＲＴＭＰ（Real Time Messaging Protocol）を適用した場合にも生じ得る。また、例えば、通信プロトコルとして、アップル社によるＨＬＳ（HTTP Live Streaming）や、リアルネットワークス社によるＲＴＳＰ（Real Time Streaming Protocol）等を適用した場合にも生じ得る問題である。また、この問題は、ローカルプロキシサーバを用いた映像配信システムのみに生じる問題ではなく、プロキシサーバをハードウェアで構成し、映像配信サーバと端末装置との間にプロキシサーバを介在させたシステム等においても生じ得る問題である。

これらの問題を解決するために、本実施形態に係る端末装置１０は、前述した取得部１２、判定部１３及び切換部１４を備えている。

本実施形態に係る端末装置１０及びデータ配信装置１６は、図２に示すコンピュータ・システム３０に含まれるクライアントＰＣ（Personal Computer）４０及び映像配信サーバ５０によって各々実現することができる。本実施形態に係るコンピュータ・システム３０は、上述したＰ２Ｐ技術を採用しており、ネットワーク８０に各々アクセス可能とされた複数のクライアントＰＣ４０と、映像配信サーバ５０と、Ｐ２Ｐインデックスサーバ６０と、を含んでいる。

クライアントＰＣ４０は、ＣＰＵ（Central Processing Unit）４１、メモリ４２、記憶部４３、入力部４４、表示部４５、媒体読み書き装置（Ｒ／Ｗ）４６及び通信インタフェース（Ｉ／Ｆ）部４７を備えている。ＣＰＵ４１、メモリ４２、記憶部４３、入力部４４、表示部４５、媒体読み書き装置４６及び通信Ｉ／Ｆ部４７はバス４８を介して互いに接続されている。媒体読み書き装置４６は、記録媒体９６に書き込まれている情報の読み出し及び記録媒体９６への情報の書き込みを行う。

記憶部４３は、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ等によって実現できる。記憶部４３には、クライアントＰＣ４０を端末装置１０として機能させるためのテスト・切換プログラム４３Ａ、データ転送プログラム４３Ｂ及びメディアプレーヤＭＰが記憶されている。

テスト・切換プログラム４３Ａは、テスト・切換プログラム４３Ａが書き込まれた記録媒体９６が媒体読み書き装置４６にセットされ、媒体読み書き装置４６が記録媒体９６からのテスト・切換プログラム４３Ａの読み出しを行うことで、記憶部４３へ記憶される。ＣＰＵ４１は、テスト・切換プログラム４３Ａを記憶部４３から読み出してメモリ４２に展開し、テスト・切換プログラム４３Ａが有するプロセスを順次実行する。

同様に、データ転送プログラム４３Ｂは、データ転送プログラム４３Ｂが書き込まれた記録媒体９６が媒体読み書き装置４６にセットされ、媒体読み書き装置４６が記録媒体９６からのデータ転送プログラム４３Ｂの読み出しを行うことで、記憶部４３へ記憶される。ＣＰＵ４１は、データ転送プログラム４３Ｂを記憶部４３から読み出してメモリ４２に展開し、データ転送プログラム４３Ｂが有するプロセスを順次実行する。

テスト・切換プログラム４３Ａは、取得プロセス４３Ａ１、判定プロセス４３Ａ２及び第１切換プロセス４３Ａ３を有する。ＣＰＵ４１は、取得プロセス４３Ａ１を実行することで、図１に示す取得部１２として動作する。また、ＣＰＵ４１は、判定プロセス４３Ａ２を実行することで、図１に示す判定部１３として動作する。さらに、ＣＰＵ４１は、第１切換プロセス４３Ａ３を実行することで、図１に示す切換部１４における第１切換部１４Ａとして動作する。

一方、データ転送プログラム４３Ｂは、第２切換プロセス４３Ｂ１を有する。ＣＰＵ４１は、第２切換プロセス４３Ｂ１を実行することで、図１に示す切換部１４における第２切換部１４Ｂとして動作する。なお、前述したように、メディアプレーヤＭＰは端末装置１０のデータ再生部１１に相当するものである。

以上により、テスト・切換プログラム４３Ａ、データ転送プログラム４３Ｂ及びメディアプレーヤＭＰを実行したクライアントＰＣ４０が、端末装置１０として機能することになる。すなわち、本実施形態に係るコンピュータ・システム３０では、テスト・切換プログラム４３Ａ及びデータ転送プログラム４３Ｂが、ローカルプロキシサーバとして機能するＰ２ＰクライアントモジュールＣＭに含まれる。

一方、Ｐ２Ｐインデックスサーバ６０は、Ｐ２Ｐのネットワークに参加して映像を視聴する各クライアントＰＣ４０に関する情報（以下、「端末情報」という。）を管理する役割を有している。また、Ｐ２Ｐインデックスサーバ６０は、映像データの供給元となる他のクライアントＰＣ４０に関する情報を新規にＰ２Ｐのネットワークに参加したクライアントＰＣ４０に提供する役割も有している。このように、本実施形態に係るコンピュータ・システム３０は、Ｐ２Ｐインデックスサーバ６０を用いたハイブリッドＰ２Ｐの形態とされているが、これに限らない。本実施形態に係るコンピュータ・システム３０が、端末情報を各クライアントＰＣ４０が少しずつ分散して持ち合うピュアＰ２Ｐの形態等とされていてもよい。

Ｐ２Ｐインデックスサーバ６０は、記憶部６３を備えている。記憶部６３はＨＤＤやフラッシュメモリ等によって実現できる。記憶部６３には、端末情報管理テーブル記憶領域６３Ａが設けられている。Ｐ２Ｐインデックスサーバ６０の図示しないＣＰＵが、端末情報管理テーブル記憶領域６３Ａに記憶されたデータを図示しないメモリに展開することにより、端末情報管理テーブルが作成される。

図３には、本実施形態に係る端末情報管理テーブルの構成の一例が示されている。

図３に示すように、本実施形態に係る端末情報管理テーブルは、端末名、ＩＰ（Internet Protocol）アドレス、受信ストリーム、セグメント番号、参加時刻及び終了時刻の各情報が記憶される。

端末名はクライアントＰＣ４０を特定するための情報であり、各クライアントＰＣ４０の各々別に個別の情報が割り当てられる。また、ＩＰアドレスは、対応する端末名によって示されるクライアントＰＣ４０のＩＰアドレスを示す情報であり、受信ストリームは、対応するクライアントＰＣ４０が受信しているストリームデータを特定するための情報である。また、セグメント番号は受信中のストリームデータのセグメントを示す情報であり、参加時刻及び終了時刻は、対応するクライアントＰＣ４０が、Ｐ２Ｐインデックスサーバ６０が管理するＰ２Ｐのネットワークに参加した時刻及び該参加を終了した時刻を各々示す。

次に、本実施形態の作用を説明する。

［コンピュータ・システム３０の基本動作］

まず、図４及び図５を参照して、コンピュータ・システム３０の基本的な動作を説明する。なお、図４は、コンピュータ・システム３０の基本的な動作の説明に供するブロック図であり、図５は、コンピュータ・システム３０で用いられる各種メッセージの構成例を示す概略図である。また、錯綜を回避するため、ここでは、本実施形態に係るコンピュータ・システム３０として、Ｐ２Ｐのネットワークに参加するクライアントＰＣ４０が、クライアントＰＣ４０Ａ〜４０Ｃの３台のみである場合について説明する。

図４に示すように、各クライアントＰＣ４０Ａ〜４０Ｃは、上述したＰ２ＰクライアントモジュールＣＭを搭載すると共に、メディアプレーヤＭＰを搭載している。メディアプレーヤＭＰは、ストリームデータをＰ２ＰクライアントモジュールＣＭから取得する。

以下、クライアントＰＣ４０ＡとクライアントＰＣ４０Ｃとが同一の映像を表し、かつ異なるビットレートのストリームデータを受信中である場合を想定する。また、ここでは、クライアントＰＣ４０Ａが受信しているストリームデータの方が、クライアントＰＣ４０Ｃが受信しているストリームデータより高ビットレート（高画質、高音質）であるものとする。以下、クライアントＰＣ４０Ａが受信しているストリームデータのビットレートを「高ビットレート」といい、クライアントＰＣ４０Ｃが受信しているストリームデータのビットレートを「低ビットレート」という。

この場合、クライアントＰＣ４０ＡとクライアントＰＣ４０Ｃの各々の端末情報が、Ｐ２Ｐインデックスサーバ６０により端末情報管理テーブルによって管理されており、図３には、この場合の端末情報管理テーブルの一例が示されている。なお、図３では、便宜上、端末名としてクライアントＰＣ４０Ａを「端末Ａ」と表記し、クライアントＰＣ４０Ｃを「端末Ｃ」と表記している。

ここで、クライアントＰＣ４０Ｂが、クライアントＰＣ４０Ａ及びクライアントＰＣ４０Ｃと同一の映像を示すストリームデータを受信する端末装置とされ、Ｐ２Ｐのネットワークに参加する場合、以下のように動作する。

まず、クライアントＰＣ４０Ｂは、Ｐ２Ｐインデックスサーバ６０に、ストリームデータを要求する接続先を問い合わせるＪＯＩＮメッセージ８０を、自らの端末情報としてＩＰアドレス、受信対象とするストリームデータの種別等を含めて送信する。Ｐ２Ｐインデックスサーバ６０は、ＪＯＩＮメッセージ８０を受信すると、この時点で保持している端末情報管理テーブルとＪＯＩＮメッセージ８０内の情報を照らし合わせる。そして、Ｐ２Ｐインデックスサーバ６０は、クライアントＰＣ４０Ｂが受信対象としているストリームデータと同一のデータを受信しているクライアントＰＣ４０に関する情報を端末情報管理テーブルから読み出す。そして、Ｐ２Ｐインデックスサーバ６０は、読み出した情報をＪＯＩＮ＿ＡＣＫメッセージ８１として、ＪＯＩＮメッセージ８０の送信元のクライアントＰＣ４０Ｂに返信する。

例えば、クライアントＰＣ４０Ｂが、初期の段階で低ビットレートのストリームデータから受信を開始するものとする。このとき、Ｐ２Ｐインデックスサーバ６０は、ＪＯＩＮメッセージ８０の内容から、クライアントＰＣ４０Ｂが低ビットレートのストリームデータを受信対象としていることを把握する。そして、Ｐ２Ｐインデックスサーバ６０は、端末情報管理テーブルから同一の低ビットレートのストリームデータを受信中のクライアントＰＣ４０Ｃに関する情報を読み出し、ＪＯＩＮ＿ＡＣＫメッセージ８１として返送する。

クライアントＰＣ４０Ｂは、Ｐ２Ｐインデックスサーバ６０から受信したＪＯＩＮ＿ＡＣＫメッセージ８１に含まれるクライアントＰＣ４０ＣのＩＰアドレスに基づき、クライアントＰＣ４０ＣにＣＯＮＮＥＣＴメッセージ８２を送信して、接続が完了する。

これ以降、クライアントＰＣ４０ＢのＰ２ＰクライアントモジュールＣＭはクライアントＰＣ４０Ｃに必要なストリームデータを要求して取得する。Ｐ２Ｐインデックスサーバ６０は、適切なクライアントＰＣ４０が見つからない場合には、映像配信サーバ５０に関する情報をＪＯＩＮ＿ＡＣＫメッセージ８１でクライアントＰＣ４０Ｂに通知する。この場合、クライアントＰＣ４０Ｂは、必要なストリームデータを映像配信サーバ５０に要求して受信する。動作としてはストリームデータを他のクライアントＰＣ４０ＡやクライアントＰＣ４０Ｃから取得する場合でも、映像配信サーバ５０から取得する場合でも、クライアントＰＣ４０Ｂからみた場合には変わりはない。

コンピュータ・システム３０において、Ｐ２ＰクライアントモジュールＣＭは、取得したストリームデータを内部のキャッシュ領域（本実施形態では、メモリ４２の所定領域）に保持する。そして、Ｐ２ＰクライアントモジュールＣＭは、メディアプレーヤＭＰからのストリームデータの取得の要求に応じて該ストリームデータをキャッシュ領域から読み出してメディアプレーヤＭＰに供給する。また、他のクライアントＰＣ４０のＰ２ＰクライアントモジュールＣＭからストリームデータの取得の要求を受信した場合にも、同様にキャッシュ領域から対応するストリームデータを読み出して、該ストリームデータの供給先のクライアントＰＣ４０への供給を行う。

ところで、ＭＰＥＧ−ＤＡＳＨでは、配信する各ストリームデータに関する情報を記載したＭＰＤ（Media Presentation Description）と呼ばれるファイルの形式や、実際のストリームデータ（動画ストリーム、音声ストリーム等）の形式等を規定している。そして、ストリームデータは、セグメントと呼ばれる小さなファイルの断片として扱われる。映像配信サーバ５０は、これらのファイルがＨＴＴＰによって要求されると、該要求に応じて要求元のクライアントＰＣ４０に、これらのファイルを供給する。ＭＰＤファイルには、どのようなビットレートのストリームデータが配備されているか、各ストリームデータのセグメント番号、ビットレート等が記載されており、メディアプレーヤＭＰは、これらを読み取ることで目的のファイル名を決定して送信の要求を行うことが可能となる。

ＭＰＥＧ−ＤＡＳＨによる配信形式に対応したメディアプレーヤＭＰは、一般に、以下のアルゴリズムでストリームデータの要求を行う。

まず、メディアプレーヤＭＰは、ＭＰＤファイルを読み込み、読み込んだＭＰＤファイルに記載されている複数のビットレートのストリームデータのうち、最低のビットレートのストリームデータを選択し、受信を開始する。すなわち、最初はネットワークにおいて利用可能な帯域が不明なので、まずは最低のビットレートのストリームデータの受信から開始し、状況に応じて、より高いビットレートのストリームデータの受信に切り換えていくのが一般的である。メディアプレーヤＭＰで映像を視聴しているユーザにとっては、最初に低画質で低音質の映像の再生が開始された後、ネットワークが高ビットレートのストリームデータを受信するのに十分な状況であれば、段階的に、より高画質で高音質の映像に切り換わっていく。

［クライアントＰＣによるストリームデータの具体的な取得手順］

次に、クライアントＰＣ４０による、より具体的なストリームデータの取得の手順を説明する。なお、ここでも、図４を参照して、Ｐ２ＰのネットワークにクライアントＰＣ４０Ａ〜４０Ｃの３台のみが参加し、ビットレートとして上述した高ビットレート及び低ビットレートの２種類のみが用意されている場合について説明する。以下、低ビットレートのストリームデータをストリームＳ１とし、高ビットレートのストリームデータをストリームＳ２として説明する。

まず、クライアントＰＣ４０Ｂを操作するユーザが、視聴したい映像を、例えばクライアントＰＣ４０Ｂのウェブ・ブラウザから選択する。これにより、選択した映像のＵＲＬ（Uniform Resource Locators）に示されたＭＰＤファイルの取得の要求が、クライアントＰＣ４０Ｂ内のローカルプロキシサーバＰＳとして動作するＰ２ＰクライアントモジュールＣＭに送信される。Ｐ２ＰクライアントモジュールＣＭは、対象とするＭＰＤファイルを映像配信サーバ５０から取得し、内部のキャッシュ領域に格納すると共に、内部状態を「映像配信開始」とし、ＭＰＤファイルをウェブ・ブラウザに供給する。

ウェブ・ブラウザは、ＭＰＤファイルを取得すると、取得したＭＰＤファイルと関連付けされているメディアプレーヤＭＰを起動し、メディアプレーヤＭＰにＭＰＤファイルを入力する。メディアプレーヤＭＰは、ＭＰＤファイルが入力されると、該ＭＰＤファイルに記載されているストリームデータのうち、最もビットレートの低いストリームＳ１の第１セグメント（１番目のセグメント）をＰ２ＰクライアントモジュールＣＭに要求する。

「映像配信開始」状態においてストリームＳ１の第１セグメントの要求を受けると、Ｐ２ＰクライアントモジュールＣＭは、該要求を受けた時刻を時刻Ｔｃｒとしてメモリ４２に記憶すると共に、Ｐ２Ｐインデックスサーバ６０へＪＯＩＮメッセージ８０を送信する。

ＪＯＩＮメッセージ８０を受信したＰ２Ｐインデックスサーバ６０は、前述したように、ストリームＳ１を受信しているクライアントＰＣ４０Ｃを接続相手の候補として、ＪＯＩＮ＿ＡＣＫメッセージ８１に含めてクライアントＰＣ４０Ｂに返送する。クライアントＰＣ４０Ｂは、受信したＪＯＩＮ＿ＡＣＫメッセージ８１の内容に従い、ＣＯＮＮＥＣＴメッセージ８２をクライアントＰＣ４０Ｃへ送信して、ストリームＳ１の供給元となるＰ２ＰクライアントであるクライアントＰＣ４０Ｃへの接続が完了する。

その後、クライアントＰＣ４０ＢのＰ２ＰクライアントモジュールＣＭは、メディアプレーヤＭＰから要求のあったストリームＳ１の第１セグメントをクライアントＰＣ４０Ｃから取得し、キャッシュ領域に格納すると共にメディアプレーヤＭＰへ供給する。

この際のストリームＳ１のメディアプレーヤＭＰへの供給のタイミング（時刻）Ｔは、以下のように決定する。すなわち、ストリームＳ１のビットレートをＢ１とし、ストリームＳ２のビットレートをＢ２とする。また、Ｐ２ＰクライアントモジュールＣＭとメディアプレーヤＭＰは同一のクライアントＰＣに設けられているため、その間の通信時間が無視できるとする。この場合、Ｐ２ＰクライアントモジュールＣＭからメディアプレーヤＭＰへのストリームＳ１の供給速度、すなわちメディアプレーヤＭＰからみた場合のストリームＳ１の受信速度ＳＰＤは、１セグメントのサイズをＳ［ｂｉｔ］とした場合、簡易的に次の式（１）で表される。

従って、Ｐ２ＰクライアントモジュールＣＭは、次の式（２）を満足するように時刻Ｔを決定し、該時刻ＴにメディアプレーヤＭＰへ第１セグメントを供給すればよい。

実際にはビットレートＢ１よりも十分速く、かつビットレートＢ２には満たない時刻Ｔを選択することにより、現状のストリームＳ１の受信が十分可能で、かつ高ビットレートのストリームＳ２の受信には不十分な受信速度となる。これにより、メディアプレーヤＭＰは、ストリームＳ２への切り換えは行わないが、現状のストリームＳ１を受信するには十分な速度となるため、安定した映像の再生が可能となる。なお、上記ビットレートＢ１よりも十分速く、かつビットレートＢ２には満たない時刻Ｔとしては、例えば、式（２）において、ビットレートＢ１とビットレートＢ２との中央のビットレートとなる時刻Ｔ等が例示される。

また、クライアントＰＣ４０ＢのＰ２ＰクライアントモジュールＣＭは、メディアプレーヤＭＰからの次のデータの取得の要求に備え、ＭＰＤファイルから推測される第２セグメント（２番目のセグメント）の取得の要求をクライアントＰＣ４０Ｃに送信する。また、この際、Ｐ２ＰクライアントモジュールＣＭは、該要求をクライアントＰＣ４０Ｃに送信した時刻を時刻Ｔｓとしてメモリ４２に記憶する。その後、クライアントＰＣ４０ＢのＰ２ＰクライアントモジュールＣＭは、クライアントＰＣ４０Ｃから該当するストリームＳ１が送信されてくると、受信を完了した時刻を時刻Ｔｒとしてメモリ４２に記憶し、受信したストリームＳ１をキャッシュ領域に格納する。

クライアントＰＣ４０ＢのＰ２ＰクライアントモジュールＣＭは、次の式（３）で示される受信速度Ｂｒｃｖを第２セグメントの受信速度としてメモリ４２に記憶し、第２セグメントの先読み処理を完了する。

これ以降、クライアントＰＣ４０ＢのＰ２ＰクライアントモジュールＣＭは、以上と同様の処理により、第３セグメント以降のキャッシュ領域への格納及び対応するセグメントの受信速度Ｂｒｃｖのメモリ４２への記憶を繰り返し行う。

ここで、先読み処理を何セグメント行うかは設定次第であるが、先読み量を多くするほど、キャッシュ領域を消費し、ユーザがメディアプレーヤＭＰ上で停止操作を行った場合等の無駄な先読みが多くなる。これに対し、先読み量を少なくするほど、通信速度が低下した場合等にストリームデータの供給が間に合わず、映像の再生に影響が出る可能性が高くなる。これらを考慮して、本実施形態では、例えば、２〜３セグメントの先読み量に設定する。

［通信状況に応じたビットレートの切り換えに関するクライアントＰＣの動作］

次に、図６を参照して、ネットワーク８０の通信状況に応じて映像配信サーバ５０から受信する映像データのビットレートを切り換える場合のクライアントＰＣ４０の動作について説明する。

ローカルプロキシサーバＰＳとして機能するＰ２ＰクライアントモジュールＣＭは、データの受信に関する内部状態として、安定している状態である「ｓｔａｂｌｅ」状態を有する。また、Ｐ２ＰクライアントモジュールＣＭは、データの受信に関する内部状態として、より高いビットレートのデータの受信への切り換えが可能な状態である「ｆａｓｔ ｅｎｏｕｇｈ」状態を有する。また、Ｐ２ＰクライアントモジュールＣＭは、データの受信に関する内部状態として、より高いビットレートのデータの受信テストを行っている状態である「ｕｎｄｅｒ ｔｅｓｔｉｎｇ」状態を有する。さらに、Ｐ２ＰクライアントモジュールＣＭは、データの受信に関する内部状態として、より高いビットレートのデータの受信への切り換え中の状態である「ｕｎｄｅｒ ｓｗｉｔｃｈｉｎｇ」状態、帯域不足の状態である「ｔｏｏ ｓｌｏｗ」状態を有する。このように、Ｐ２ＰクライアントモジュールＣＭは、データの受信状況に応じて内部状態が遷移する。

クライアントＰＣ４０のＰ２ＰクライアントモジュールＣＭは、メディアプレーヤＭＰからのストリームデータの要求を受信すると、テスト・切換プログラム４３Ａを実行させることで、図６に示すテスト・切換処理が行われる。以下、本実施形態に係るテスト・切換処理について説明する。なお、錯綜を回避するため、ここでは、通常のストリームデータを受信する処理（以下、「通常受信処理」という。）は別スレッドとして、上述したように行っている場合について説明する。

テスト・切換処理のステップ１００において、取得部１２は、本テスト・切換処理において用いる閾値Ｔｈ１，Ｔｈ２，・・・、マージンα，β、及び閾値ＴＨｆｅ，ＴＨｕｔの設定を行うと共に、カウンタＦＥ，ＵＴのリセット（ここでは、１を代入）を行う。

本実施形態に係るテスト・切換処理では、ＭＰＥＧ−ＤＡＳＨにより規定されるストリームデータとして、２種類のビットレートのみならず、３種類以上のビットレートを有するストリームデータに対応している。そして、本実施形態に係るテスト・切換処理では、閾値Ｔｈ１，Ｔｈ２，・・・として、ストリームデータにおける最も低速のビットレートから順に、各ビットレートの値そのものをそれぞれ設定する。すなわち、閾値Ｔｈ１として最も低速のビットレートを設定し、閾値Ｔｈ２として次に低速のビットレートを設定し、以下、同様に各閾値を設定する。なお、以下では、閾値Ｔｈ１，Ｔｈ２，・・・を総称する場合は「閾値Ｔｈ」と記載する。

一方、本実施形態に係るテスト・切換処理では、後述するように、上記各閾値Ｔｈ１，Ｔｈ２，・・・と、ストリームデータの受信速度と、を比較する処理を行っているが、上記マージンα及びマージンβは、その際の各閾値Ｔｈのマージンとして適用する値である。本実施形態では、マージンα及びマージンβとして同一の固定値（本実施形態では、１０（ｋｂｐｓ））を用いているが、これに限定されるものではない。例えば、マージンα及びマージンβとして異なる値を設定してもよく、また、例えば、マージンα及びマージンβとして、該マージンを適用する閾値の予め定められた割合（一例として１０％）の値を適用する形態としてもよい。

さらに、上記閾値ＴＨｆｅ、ＴＨｕｔ及びカウンタＦＥ、ＵＴは、テスト・切換処理において同一の処理を繰り返して実行する際の繰り返し回数を規定するために用いるものである。

ステップ１０２において、取得部１２は、別スレッドで実行している通常受信処理において、最も直近にメモリ４２に記憶された受信速度Ｂｒｃｖを読み出すことにより該受信速度Ｂｒｃｖを取得する。

ステップ１０４において、判定部１３は、受信速度Ｂｒｃｖが、この時点で上記通常受信処理において受信しているストリームデータのビットレートより１段階高いビットレートに対応する閾値Ｔｈにマージンβを加えた値より大きいか否かを判定する。ここで、否定判定となった場合はステップ１０６に移行する。

ステップ１０６において、判定部１３は、受信速度Ｂｒｃｖが、この時点で上記通常受信処理において受信しているストリームデータのビットレートに対応する閾値Ｔｈにマージンαを加えた値より小さいか否かを判定する。ここで、否定判定となった場合は「ｓｔａｂｌｅ」状態にあるものと見なして後述するステップ１３６に移行する一方、肯定判定となった場合は、「ｔｏｏ ｓｌｏｗ」状態にあるものと見なしてステップ１０８に移行する。

ステップ１０８において、第１切換部１４Ａは、上記通常受信処理に対して、この時点より１段階低いビットレートのストリームデータ（以下、「低側データ」という。）の受信に切り換えるように指示し、その後に後述するステップ１３６に移行する。この指示に応じて、上記通常受信処理では、これ以降、受信対象とするストリームデータを低側データに切り換え、該低側データを先読みしてキャッシュ領域に格納する。また、この切り換えを行う際に、上記通常受信処理では、切り換えた後のストリームデータの種類、セグメント番号等を更新情報としてＵＰＤＡＴＥ＿ＩＮＦＯメッセージ８５でＰ２Ｐインデックスサーバ６０に通知する。これに応じて、Ｐ２Ｐインデックスサーバ６０は、保持している端末情報管理テーブルを更新する。

すなわち、受信速度ＢｒｃｖがメディアプレーヤＭＰから要求されているビットレートより低下した場合は、これ以後、安定したストリームデータの受信や映像の再生が困難となる。このため、本テスト・切換処理では、この場合、受信対象とするストリームデータを１段階低いビットレートのストリームデータに切り換える処理を行っている。この際の低ビットレート側への切り換えは、それまでは切り換え前のビットレートのストリームデータが十分な速度で受信できていたと考えられるので即座に切り換えを行う。しかしながら、これに限定されず、後述する高ビットレート側への切り換え時と同様にテストを実施してから切り換える形態としてもよい。

なお、ステップ１０８の処理を実行する際に、上記通常受信処理によって最低のビットレートのストリームデータを受信している場合には、本ステップ１０８の処理を実行することなく、すなわち、低側データへの切り換えを行うことなくステップ１３６に移行する。

一方、上記ステップ１０４において肯定判定となった場合は、「ｆａｓｔ ｅｎｏｕｇｈ」状態にあるものと見なしてステップ１１０に移行する。

ステップ１１０において、取得部１２は、上記ステップ１０２の処理と同様の処理によって受信速度Ｂｒｃｖを取得する。

ステップ１１２において、判定部１３は、受信速度Ｂｒｃｖが、この時点で上記通常受信処理において受信しているストリームデータのビットレートより１段階高いビットレートに対応する閾値Ｔｈにマージンβを加えた値より大きいか否かを判定する。ここで、否定判定となった場合は、「ｓｔａｂｌｅ」状態にあるものと見なしてステップ１２４に移行し、カウンタＦＥをリセット（ここでは、１を代入）し、その後に上記ステップ１０２に戻る。また、ステップ１１２において、肯定判定となった場合にはステップ１１４に移行する。

ステップ１１４において、取得部１２は、カウンタＦＥの値を１だけインクリメントし、ステップ１１６において、取得部１２は、カウンタＦＥの値が閾値ＴＨｆｅを超えたか否かを判定する。ここで、否定判定となった場合は上記ステップ１１０に戻り、肯定判定となった場合は、「ｕｎｄｅｒ ｔｅｓｔｉｎｇ」状態に遷移可能な状態にあるものと見なしてステップ１１８に移行する。

ステップ１１８において、取得部１２は、この時点で上記通常受信処理において適用しているビットレートより１段階高いビットレートのストリームデータ（以下、「高側データ」という。）を受信できる装置をＰ２Ｐインデックスサーバ６０に問い合わせる。また、取得部１２は、該問い合わせに応じてＰ２Ｐインデックスサーバ６０から受信した情報により示される装置（以下、「高側データ受信可能装置」という。）に対して、上記高側データを要求すると共に、この時点の時刻を時刻Ｔｓとしてメモリ４２に記憶する。

なお、本ステップ１１８において、取得部１２は、Ｐ２Ｐインデックスサーバ６０への上記問い合わせを、ＱＵＥＲＹ＿ＩＮＦＯメッセージ８３を用いて行う。ＱＵＥＲＹ＿ＩＮＦＯメッセージ８３を受信すると、Ｐ２Ｐインデックスサーバ６０は、端末情報管理テーブルを参照し、上記高側データを受信中のクライアントＰＣ４０、すなわち高側データ受信可能装置の情報をＱＵＥＲＹ＿ＡＣＫメッセージ８４にて返信する。ＱＵＥＲＹ＿ＡＣＫメッセージ８４を受信すると、取得部１２は、高側データ受信可能装置にＣＯＮＮＥＣＴメッセージ８２を送信し、該高側データのセグメントを要求すると共に、この時点の時刻Ｔｓを記憶する。このとき要求する高側データのセグメント番号は、上記通常受信処理で受信しているストリームデータの最新のセグメントが第Ｎ番目のセグメントであった場合は、第Ｎ＋１番目のセグメント番号とする。

ステップ１２０において、取得部１２は、高側データ受信可能装置から上記高側データを受信すると共に、この時点の時刻を時刻Ｔｒとして、前述した式（３）に代入することにより、受信速度Ｂｒｃｖを算出する。

ステップ１２２において、判定部１３は、算出した受信速度Ｂｒｃｖが、上記高側データのビットレートに対応する閾値Ｔｈにマージンβを加えた値より十分大きいか否かを判定する。ここで、否定判定となった場合は、「ｓｔａｂｌｅ」状態にあるものと見なしてステップ１２４に移行し、カウンタＵＴをリセット（ここでは、１を代入）し、その後に上記ステップ１０２に戻る。また、ステップ１２２において肯定判定となった場合に、取得部１２は、ステップ１２６に移行する。なお、上記ステップ１２２において上記十分大きいか否かを判定するために、判定部１３は、閾値Ｔｈに加算するマージンβを所定数倍（本実施形態では、２倍）する形態を適用しているが、これに限定されるものではない。例えば、上記マージンβに所定値を加える形態や、マージンβに代えてマージンβより大きな固定値を適用する形態等としてもよい。

ステップ１２６において、取得部１２は、カウンタＵＴの値を１だけインクリメントし、ステップ１２８において、取得部１２は、カウンタＵＴの値が閾値ＴＨｕｔを超えたか否かを判定する。ここで、否定判定となった場合は上記ステップ１１８に戻り、肯定判定となった場合は、「ｕｎｄｅｒ ｓｗｉｔｃｈｉｎｇ」状態に遷移可能な状態にあるものと見なしてステップ１３０に移行する。

ステップ１３０において、取得部１２は、上記ステップ１１８の処理と同様に、高側データを高側データ受信可能装置に要求した後、該高側データ受信可能装置から該高側データを受信する。なお、「ｕｎｄｅｒ ｓｗｉｔｃｈｉｎｇ」状態では、上記通常受信処理で受信するストリームデータのセグメント番号と、本ステップ１３０の処理で受信するストリームデータのセグメント番号が重複してもよい。

「ｕｎｄｅｒ ｓｗｉｔｃｈｉｎｇ」状態にある場合、後述するデータ転送処理（図７も参照。）では、上記通常受信処理によって受信されたストリームデータを上記高側データのビットレートより速い転送速度でメディアプレーヤＭＰに送信することを繰り返す。これに応じてメディアプレーヤＭＰは、該ストリームデータの受信が所定回数成功すると、ビットレートを１段階上げることが十分可能であると判断し、該１段階上のビットレートのストリームデータをＰ２ＰクライアントモジュールＣＭに要求する。なお、この際のメディアプレーヤＭＰによる高側データの受信が所定回数成功するか否かを判定することを、以下では「高速通信テスト」という。

そこで、ステップ１３２において、第１切換部１４Ａは、メディアプレーヤＭＰからの１段階上のビットレートのストリームデータの要求を受信したか否かを判定し、否定判定となった場合は上記ステップ１３０に戻る。また、ステップ１３２において肯定判定となった場合には、ステップ１３４に移行する。

ステップ１３４において、第１切換部１４Ａは、上記通常受信処理に対して、この時点より１段階高いビットレートのストリームデータ（高側データ）の受信に切り換えるように指示し、その後にステップ１３６に移行する。この指示に応じて、上記通常受信処理では、これ以降、受信対象とするストリームデータを高側データに切り換え、該高側データを先読みしてキャッシュ領域に格納する。また、この切り換えを行う際に、上記通常受信処理では、切り換えた後のストリームデータの種類、セグメント番号等を更新情報としてＵＰＤＡＴＥ＿ＩＮＦＯメッセージ８５によりＰ２Ｐインデックスサーバ６０に通知する。これに応じて、Ｐ２Ｐインデックスサーバ６０は、保持している端末情報管理テーブルを更新する。

すなわち、判定部１３は、受信速度ＢｒｃｖがメディアプレーヤＭＰから要求されているビットレートの１段階上のビットレートより十分速い場合は、現在時点のビットレートより高ビットレートのストリームデータの受信に切り換え可能であると判定する。そして、この場合、第１切換部１４Ａは、メディアプレーヤＭＰによる高速通信テストを経た後に、通常受信処理に対して、現在時点より１段階高いビットレートのストリームデータの受信に切り換えさせる処理を行っている。

なお、ステップ１１０を実行する際に、通常受信処理によって最大のビットレートのストリームデータを受信している場合には、ステップ１１０〜ステップ１３４の処理を行うことなく、すなわち、高側データへの切り換えを行うことなくステップ１３６に移行する。

ステップ１３６において、取得部１２は、受信中のストリームデータの受信が全て終了したか否かを判定し、否定判定となった場合は上記ステップ１０２に戻る一方、肯定判定となった場合には本テスト・切換処理を終了する。

［メディアプレーヤへのデータ転送に関するクライアントＰＣの動作］

次に、図７を参照して、メディアプレーヤＭＰへのストリームデータの転送に関するクライアントＰＣ４０の動作について説明する。

本実施形態に係るコンピュータ・システム３０では、クライアントＰＣ４０のＰ２ＰクライアントモジュールＣＭは、テスト・切換処理の実行を開始すると共に、データ転送プログラム４３Ｂを実行させることで、図７に示すデータ転送処理が行われる。以下、本実施形態に係るデータ転送処理について説明する。

データ転送処理のステップ２００において、第２切換部１４Ｂは、この時点の時刻を時刻Ｔｃｒとしてメモリ４２に記憶する。

ステップ２０２において、第２切換部１４Ｂは、この時点で上記通常受信処理によりキャッシュ領域に記憶されているストリームデータに、メディアプレーヤＭＰから要求されたセグメントのデータが含まれているか否かを判定する。ここで、否定判定となった場合はステップ２０４に移行する。

ステップ２０４において、第２切換部１４Ｂは、上記通常受信処理に対してメディアプレーヤＭＰから要求されたセグメントのストリームデータの受信を要求し、その後に上記ステップ２０２に戻る。なお、該要求を受けると上記通常受信処理では、要求されたセグメントのストリームデータを受信し、キャッシュする処理が実行される。一方、上記ステップ２０２において肯定判定となった場合、ステップ２０６に移行する。

ステップ２０６において、第２切換部１４Ｂは、この時点におけるストリームデータの受信状態が「ｔｏｏ ｓｌｏｗ」状態となっているか否かを判定することにより、上記低側データの受信に切り換えられたか否かを判定する。ここで、否定判定となった場合は後述するステップ２１４に移行する一方、肯定判定となった場合はステップ２０８に移行する。

ステップ２０８において、第２切換部１４Ｂは、次の式（４）を満足するように時刻Ｔを決定し、次のステップ２１０において、第２切換部１４Ｂは、現在時刻が時刻Ｔになるまで待機する。なお、式（４）におけるＢＬ１は、この時点でメディアプレーヤＭＰから要求されているストリームデータのビットレートより１段階低いビットレートを表す。また、式（４）におけるＢＨ１は、この時点でメディアプレーヤＭＰから要求されているストリームデータのビットレートを表す。

この際、上述したように、実際にはビットレートＢＬ１よりも十分速く、かつビットレートＢＨ１には満たない時刻Ｔを選択する。これにより、現状より１段階低いビットレートのストリームデータの受信が十分可能で、かつ現状のビットレートのストリームデータの受信には不十分な受信速度となる。

ステップ２１２において、第２切換部１４Ｂは、上記通常受信処理によってキャッシュ領域に格納され、かつメディアプレーヤＭＰから要求されている低側データをメディアプレーヤＭＰに送信し、その後にステップ２２８に移行する。

一方、ステップ２１４において、第２切換部１４Ｂは、この時点におけるストリームデータの受信状態が「ｕｎｄｅｒ ｓｗｉｔｃｈｉｎｇ」状態となっているか否かを判定することにより、上記高側データの受信に切り換えられている最中か否かを判定する。ここで、否定判定となった場合は後述するステップ２２２に移行する一方、肯定判定となった場合はステップ２１６に移行する。

ステップ２１６において、第２切換部１４Ｂは、次の式（５）を満足するように時刻Ｔを決定し、次のステップ２１８において、第２切換部１４Ｂは、現在時刻が時刻Ｔになるまで待機する。なお、式（５）におけるＢＬ２は、この時点でメディアプレーヤＭＰから要求されているストリームデータのビットレートより１段階高いビットレートを表す。また、式（５）におけるＢＨ２は、この時点でメディアプレーヤＭＰから要求されているストリームデータのビットレートより２段階高いビットレートを表す。

この際も、上述したように、実際にはビットレートＢＬ２よりも十分速く、かつビットレートＢＨ２には満たない時刻Ｔを選択する。これにより、現状より１段階高いビットレートのストリームデータの受信が十分可能で、かつ現状より２段階高いビットレートのストリームデータの受信には不十分な受信速度となる。なお、この場合、ビットレートＢＨ２が存在しない場合があるが、この場合は該ビットレートＢＨ２を無視する。

ステップ２２０において、第２切換部１４Ｂは、上記通常受信処理によってキャッシュ領域に格納され、かつメディアプレーヤＭＰから要求されている高側データをメディアプレーヤＭＰに送信し、その後にステップ２２８に移行する。

このように、「ｕｎｄｅｒ ｓｗｉｔｃｈｉｎｇ」状態では、メディアプレーヤＭＰからのストリームデータの要求に対して、要求されているビットレートよりも十分速い速度でストリームデータを供給する。該データを受信したメディアプレーヤＭＰは、データの受信速度がＭＰＤファイルに記載されている高側データのビットレートを基準にした閾値Ｔｈに対して十分速いため、要求するストリームデータのビットレートを１段階高いものに切り換えてよいと判断する。

一方、ステップ２２２において、第２切換部１４Ｂは、次の式（６）を満足するように時刻Ｔを決定し、次のステップ２２４において、第２切換部１４Ｂは、現在時刻が時刻Ｔになるまで待機する。なお、式（６）におけるＢＬ３は、この時点でメディアプレーヤＭＰから要求されているストリームデータのビットレートを表す。また、式（６）におけるＢＨ３は、この時点でメディアプレーヤＭＰから要求されているストリームデータのビットレートより１段階高いビットレートを表す。

この際も、上述したように、実際にはビットレートＢＬ３よりも十分速く、かつビットレートＢＨ３には満たない時刻Ｔを選択する。これにより、現状のビットレートのストリームデータの受信が十分可能で、かつ現状より１段階高いビットレートのストリームデータの受信には不十分な受信速度となる。なお、この場合も、ビットレートＢＨ３が存在しない場合があるが、この場合は該ビットレートＢＨ３を無視する。

ステップ２２６において、第２切換部１４Ｂは、上記通常受信処理によってキャッシュ領域に格納され、かつメディアプレーヤＭＰから要求されているストリームデータをメディアプレーヤＭＰに送信した後、ステップ２２８に移行する。

ステップ２２８において、第２切換部１４Ｂは、上記通常受信処理で受信しているストリームデータのメディアプレーヤＭＰからの送信要求が終了したか否かを判定し、否定判定となった場合はステップ２３０に移行する。ステップ２３０において、第２切換部１４Ｂは、メディアプレーヤＭＰから次のデータの送信要求が受信されるまで待機し、その後に上記ステップ２００に戻る。そして、ステップ２２８において肯定判定となった時点で本データ転送処理を終了する。

次に、図８を参照して、テスト・切換処理及びデータ転送処理を図４に示したシステム、すなわち、クライアントＰＣ４０が３台で、受信対象とするストリームデータのビットレートが２種類であるシステムに適用した場合の具体的な処理の流れを説明する。この場合、閾値Ｔｈ１、Ｔｈ２、・・・は、低ビットレートに対応する閾値Ｔｈ１と、高ビットレートに対応する閾値Ｔｈ２の２種類の閾値のみとなる。なお、ここでは、錯綜を回避するため、受信データの低ビットレート側への切り換えについては言及せず、高ビットレート側に切り換える場合のみについて説明する。

最初に、クライアントＰＣ４０ＢのＰ２ＰクライアントモジュールＣＭは、通常受信処理により、「ｓｔａｂｌｅ」状態で、メディアプレーヤＭＰからの要求に応じてクライアントＰＣ４０Ｃから低ビットレートであるストリームＳ１を先読みしてキャッシングする。また、該Ｐ２ＰクライアントモジュールＣＭは、通常受信処理によりキャッシュされているストリームデータを、ストリームＳ１のビットレートＢ１より十分速く、かつストリーム２のビットレートＢ２には満たない送信速度でメディアプレーヤＭＰに送信する。

この状態において、クライアントＰＣ４０ＢのＰ２ＰクライアントモジュールＣＭは、映像配信サーバ５０からのストリームデータの受信速度Ｂｒｃｖを測定する。そして、クライアントＰＣ４０Ｂは、受信速度Ｂｒｃｖが次の式（７）の条件を満足した場合、高ビットレートを受信するために十分な受信速度であるものと見なして「ｆａｓｔ ｅｎｏｕｇｈ」状態に遷移する。

次に、クライアントＰＣ４０ＢのＰ２ＰクライアントモジュールＣＭは、通常受信処理によって受信しているストリームＳ１の受信速度Ｂｒｃｖが式（７）の条件を閾値ＴＨｆｅで示される回数（図８に示す例では、１回）満足したか否かを判定する。ここで、クライアントＰＣ４０Ｂは、満足したと判定した場合のみ、「ｕｎｄｅｒ ｔｅｓｔｉｎｇ」状態に遷移する。なお、この状態においても、クライアントＰＣ４０ＢのＰ２ＰクライアントモジュールＣＭは、キャッシングされているストリームＳ１を、ビットレートＢ１より十分速く、かつビットレートＢ２には満たない送信速度でメディアプレーヤＭＰに送信する。

次に、クライアントＰＣ４０ＢのＰ２ＰクライアントモジュールＣＭは、Ｐ２Ｐインデックスサーバ６０に、この時点でストリームＳ２を受信している装置（高側データ受信可能装置であり、ここでは、クライアントＰＣ４０Ａ）を問い合わせる。また、該Ｐ２ＰクライアントモジュールＣＭは、この問い合わせの結果得られたクライアントＰＣ４０Ａに対してストリームＳ２を要求する。そして、該Ｐ２ＰクライアントモジュールＣＭは、この要求に応じてストリームＳ２を受信するまでの時間に基づいて得られた受信速度Ｂｒｃｖが上記式（７）の条件を閾値ＴＨｕｔで示される回数（図８に示す例では、１回）満足したか否かを判定する。ここで、クライアントＰＣ４０Ｂは、満足したと判定した場合のみ、「ｕｎｄｅｒ ｓｗｉｔｃｈｉｎｇ」状態に遷移する。なお、この状態においても、クライアントＰＣ４０ＢのＰ２ＰクライアントモジュールＣＭは、キャッシングされているストリームＳ１を、ビットレートＢ１より十分速く、かつビットレートＢ２には満たない送信速度でメディアプレーヤＭＰに送信する。

次に、クライアントＰＣ４０ＢのＰ２ＰクライアントモジュールＣＭは、「ｕｎｄｅｒ ｓｗｉｔｃｈｉｎｇ」状態において、「ｕｎｄｅｒ ｔｅｓｔｉｎｇ」状態の場合と同様にクライアントＰＣ４０ＡからストリームＳ２を受信する。そして、該Ｐ２ＰクライアントモジュールＣＭは、メディアプレーヤＭＰから要求されたストリームデータを、ビットレートＢ２より十分速い送信速度でメディアプレーヤＭＰに送信する。

これに対し、メディアプレーヤＭＰは、前述したように、ストリームデータの受信が所定回数（図８に示す例では、３回）成功すると、ビットレートを１段階上げることが十分可能であると判断し、該１段階高いビットレートＢ２のストリームＳ２をＰ２ＰクライアントモジュールＣＭに要求する。

そこで、クライアントＰＣ４０ＢのＰ２ＰクライアントモジュールＣＭは、メディアプレーヤＭＰからストリームＳ２の要求があるまで待機し、その後に通常受信処理に対して受信するストリームデータをストリームＳ１からストリームＳ２に切り換える指示を行う。

なお、実際のＰ２Ｐ技術によるシステムにおいて、ストリームデータの送信元となる他のクライアントＰＣ４０Ａ及びクライアントＰＣ４０Ｃは、クライアントＰＣ４０Ｂがストリームデータを受信している最中に、常に存在しているとは限らない。例えば、ストリームデータの送信元の端末装置が、対象とする映像の再生（視聴）を停止してＰ２Ｐのネットワークから離脱する場合等である。この場合等に備えて、クライアントＰＣ４０Ｂは、ＱＵＥＲＹ＿ＩＮＦＯメッセージ８３により定期的に対象とするストリームデータを送信可能な他の装置をＰ２Ｐインデックスサーバ６０に問い合わせてもよい。そして、クライアントＰＣ４０Ｂは、対象とするストリームデータの受信が所定期間内に完了しない場合には、上記問い合わせに応じて得られた装置にストリームデータの送信元を切り換えてもよい。

〔第２実施形態〕

次に開示の技術の第２実施形態について説明する。本第２実施形態では、端末装置が携帯電話機やスマートフォン、タブレット端末装置等の移動端末装置である場合の形態について説明する。

図９には、本第２実施形態に係る端末装置２０が示されている。図９に示すように、本実施形態に係る端末装置２０は、データ再生部２１、取得部２２、判定部２３及び切換部２４を備えている。データ再生部２１、取得部２２、判定部２３及び切換部２４は、各々、上記第１実施形態に係る同一名称のデータ再生部１１、取得部１２、判定部１３及び切換部１４と同一か、または略同一のものである。

ただし、取得部２２と取得部１２とでは、通信経路における通信状態の取得方法が異なる。すなわち、上記第１実施形態に係る取得部１２では、データ再生部１１からの要求に応じたビットレートの配信データを受信している場合に、該ビットレートより高いビットレートの配信データを要求して受信し、該受信に要した時間に基づいて通信状況を取得する。これに対し、本第２実施形態に係る取得部２２では、次のように上記通信状況を取得する。すなわち、取得部２２は、データ再生部２１からの要求に応じたビットレートの第１の配信データを受信している場合に、より高いビットレートの第２の配信データの該ビットレートに応じて上記第１の配信データを増量してデータ配信装置１６に要求する。そして、取得部２２は、この要求に応じた第１の配信データを受信し、該第１の配信データの受信に要した時間に基づいて上記通信状況を取得する。

なお、本第２実施形態に係る端末装置２０でも、上記配信データとして、動画及び音声の双方を含む映像を表す映像データを適用し、データ配信装置１６として、映像配信サーバを適用している。端末装置２０におけるデータ再生部２１は開示の技術に係るデータ再生部の一例であり、取得部２２は開示の技術に係る取得部の一例であり、判定部２３は開示の技術に係る判定部の一例であり、切換部２４は開示の技術に係る切換部の一例である。

以上のように、本第２実施形態に係る端末装置２０の機能的な構成は、上記第１実施形態に係る端末装置１０と略同様とされているが、端末装置１０が固定して配置されるものであるのに対し、端末装置２０が、移動端末装置とされている点が大きく異なる。

すなわち、移動端末装置は、電話回線や無線ＬＡＮ（Local Area Network）等の通信回線を介した無線での通信機能を搭載しており、移動しながらデータの送受信が可能である。従って、移動端末装置では、通常の端末装置に比較して、通信速度等の通信状況の変化が起こりやすく、映像配信サーバからのストリームデータの取得が間に合わないケースが発生しやすい。

これに対し、近年、移動端末装置による通信速度が高速化され、電子メール等のデータ量が比較的少ないデータの通信については、通信不能となる状態の発生が抑制されるようになってきた。しかしながら、映像データを移動端末装置で受信する場合は、データ量が非常に多いため、移動中に安定して受信することが難しい場合がある。

ところで、ウェブ・サーバに対するアクセスの高速化のための技術として、一例として図１０に示すように、上記第１実施形態と同様のローカルプロキシサーバを端末装置に配備し、ウェブ・サーバから取得したウェブ・ページをキャッシュする技術がある。ここで、前述したように、ストリームデータをＨＴＴＰで取得する動作はウェブ・サーバに対するアクセスそのものであり、この高速化のための技術はＭＰＥＧ−ＤＡＳＨ等のマルチビットレートに対応したストリームデータを取得する技術にも適用が可能である。

すなわち、図１０に示すシステムにおいて対象としているウェブ・コンテンツが映像データである場合、このシステムは、図１１に示すシステムと等価である。そして、図１１に示すシステムでは、ローカルプロキシサーバＰＳがメディアプレーヤＭＰと映像配信サーバ５０との間を仲介して、ストリームデータの供給を高速化すると共に、映像の再生を安定化させることとなる。この場合も、前述した第１実施形態に係るＰ２Ｐ技術によるシステムの場合と同様に、ローカルプロキシサーバＰＳが、メディアプレーヤＭＰからの映像データの取得の要求を受けて、対象とするストリームデータをメディアプレーヤＭＰに供給する。

このような、移動端末装置におけるローカルプロキシサーバＰＳにおいても、移動中に時々刻々と変化するネットワークの通信状況によっては、要求されるストリームデータが映像配信サーバ５０から確実かつ速やかに取得できるとは限らない。このため、可能な限り先読みを行ってキャッシングしておくことが、メディアプレーヤＭＰへのデータの供給の安定化のために効果的である。

図１２には、本第２実施形態に係る移動端末装置７０の構成が示されている。図１２に示すように、本第２実施形態に係る移動端末装置７０は、ローカルプロキシサーバＰＳ及びメディアプレーヤＭＰが搭載されている。また、移動端末装置７０は、後述する速度マップＤＢ（データベース）７４に含まれる情報に基づいて、映像配信サーバ５０からのデータの受信速度を予測する速度予測部７２を備えている。なお、移動端末装置７０が端末装置２０に相当し、映像配信サーバ５０がデータ配信装置１６に相当する。また、移動端末装置７０のローカルプロキシサーバＰＳが端末装置２０の取得部２２、判定部２３及び切換部２４に相当し、メディアプレーヤＭＰが端末装置２０のデータ再生部２１に相当する。このように、本実施形態に係る移動端末装置７０では、映像配信サーバ５０とメディアプレーヤＭＰとの間に、ローカルプロキシサーバＰＳを移動端末装置７０に配備し、ストリームデータの各セグメントの先読みを積極的に行い、配信映像の再生を安定化させる。

図１３には、本第２実施形態に係る速度マップＤＢ７４の構成の一例が示されている。図１３に示すように、本第２実施形態に係る速度マップＤＢ７４は、位置及び受信速度の各情報が記憶される。

ここで、上記受信速度は、対応する位置（本実施形態では、緯度及び経度）に移動端末装置７０が位置する場合の映像配信サーバ５０からのデータの受信速度を示す情報である。なお、速度マップＤＢ７４に登録する情報は、以上の位置及び受信速度のみに限定されない。例えば、これらの情報に加えて、対応する受信速度を速度マップＤＢ７４に記録した日時を示す時刻情報や、対応する通信先の装置を示すＩＰ情報等を更に登録する形態としてもよい。

なお、速度マップＤＢ７４は、移動端末装置７０が移動されると想定される領域を所定サイズの矩形領域で細分化し、各細分化された矩形領域の中心の位置の受信速度を対応する矩形領域の内部における受信速度として予め登録しておく形態としてもよい。この形態を以下では「第１マップ形態」という。

また、速度マップＤＢ７４は、移動端末装置７０が移動されると想定される領域内における複数箇所の各位置において、該位置を中心とした所定半径の円の内部の受信速度の平均値を、該円の内部における受信速度として、予め登録しておく形態としてもよい。この形態を以下では「第２マップ形態」という。

なお、速度マップＤＢ７４は、ユーザにより移動端末装置７０によって実際に映像配信サーバ５０からのデータの受信速度をロギングしながら、対応する位置を示す情報と共に保存することにより構築してもよい。

次に、図１２〜図１４を参照して、本第２実施形態の作用を説明する。なお、図１４は、移動端末装置７０のローカルプロキシサーバＰＳ（クライアントモジュール）により実行される処理の流れを示すタイムチャートである。また、ここでは、錯綜を回避するため、対象とするストリームデータのビットレートが２種類のみであるものとし、上記第１実施形態と同様に、低ビットレートのストリームデータをストリームＳ１とし、高ビットレートのストリームデータをストリームＳ２とする。また、ここでは、錯綜を回避するため、受信データの低ビットレート側への切り換えについては言及せず、高ビットレート側に切り換える場合のみについて説明する。

前述したように、単に先読みしたキャッシュ領域内のデータを、メディアプレーヤがローカルプロキシサーバＰＳから受信すると、ＭＰＥＧ−ＤＡＳＨ等のマルチビットレートに対応したメディアプレーヤでは、受信速度の判断を誤る可能性がある。このため、第２実施形態に係る移動端末装置７０では、第１実施形態に係るクライアントＰＣ４０と同様に、映像配信サーバ５０からのデータの受信速度を計測しつつ、メディアプレーヤＭＰへのストリームデータの供給速度を調整する。

また、本第２実施形態に係るローカルプロキシサーバＰＳは、速度予測部７２と連携して先読み量を調整するが、この点についての詳細は後述する。

まず、ローカルプロキシサーバＰＳは、ユーザによる操作に応じてメディアプレーヤＭＰからＭＰＤファイルの取得の要求が発生すると、キャッシュ領域を確認し、ＭＰＤファイルのデータがなければ映像配信サーバ５０にＭＰＤファイルの取得の要求を送信する。

次いで、ローカルプロキシサーバＰＳは、映像配信サーバ５０からＭＰＤファイルを取得すると、該ＭＰＤファイルのデータをキャッシュ領域に格納すると共に、メディアプレーヤＭＰへ供給し、メディアプレーヤＭＰからのストリームデータの要求を待つ。

メディアプレーヤＭＰの動作は上記第１実施形態のメディアプレーヤＭＰと同様で、ＭＰＤファイルに記載されている複数種類のビットレートのストリームデータのうち、まずは最低のビットレートであるストリームＳ１の第１セグメントのファイルを要求する。該要求を受けたローカルプロキシサーバＰＳは、要求された時刻を時刻Ｔｃｒとして記憶し、第１セグメントのストリームデータがキャッシュ領域に格納されてなければ、映像配信サーバ５０へ該データを要求し、この時点の時刻を時刻Ｔｓとして保持する。そして、ローカルプロキシサーバＰＳは、ストリームデータの受信が完了したところで、該ストリームデータをキャッシュ領域に格納する。また、ローカルプロキシサーバＰＳは、この時点の時刻を時刻Ｔｒとして保持し、要求されたストリームデータのサイズＳ［ｂｉｔ］に基づいて、受信速度Ｂｒｃｖを上述した式（３）により算出する。

ここで、メディアプレーヤＭＰから要求のあったセグメントのストリームデータをメディアプレーヤＭＰへ供給するタイミング（時刻）Ｔも、上記第１実施形態と同様に、上述した式（２）を満足するように決定する。

一方、第２実施形態に係るシステムでは、第１実施形態に係るシステムとは異なり、ストリームデータのビットレートを切り換えてもストリームデータの要求先となる装置が映像配信サーバ５０であり、変化しない。そこで、本第２実施形態に係る取得部２２では、「ｕｎｄｅｒ ｔｅｓｔｉｎｇ」状態で高ビットレートのストリームデータの受信をテストする際には、以下のように映像配信サーバ５０にストリームデータを要求する。すなわち、取得部２２は、図１４に示すように、要求するストリームデータのビットレートを変えずに受信中のストリームＳ１のデータの要求量をストリームＳ２のセグメントのサイズと同等以上に増やして、映像配信サーバ５０へ要求する。例えば、ストリームＳ２のビットレートＢ２がストリームＳ１のビットレートＢ１のｎ倍だった場合、すなわち、次の式（８）で示される場合は、ｎ個（図１４に示す例では、３個）のセグメントの送信要求を一気に行うと共に、この際の時刻を時刻Ｔｓとして記憶する。

そして、取得部２２は、ｎ個の全てのセグメントを受信した時刻を時刻Ｔｒとし、前述した式（３）を用いて受信速度Ｂｒｃｖを求め、この値がビットレートＢ２を十分に超えていれば、「ｕｎｄｅｒ ｓｗｉｔｃｈｉｎｇ」状態へ遷移し、映像配信サーバ５０への要求をストリームＳ２のセグメントに切り換える。

なお、「ｕｎｄｅｒ ｔｅｓｔｉｎｇ」状態のテスト時におけるストリームＳ１の先読み量を多めとしているので、この量が所定の先読み量を超えているようなら、メディアプレーヤＭＰへのデータの供給によって適切な量に低下するまで、先読みを保留してもよい。その他の動作は上記第１実施形態に係るローカルプロキシサーバＰＳと同様である。

ここで、「ｕｎｄｅｒ ｔｅｓｔｉｎｇ」状態で計測した受信速度ＢｒｃｖがビットレートＢ２に満たない場合は、ビットレートの切り換えは見送られる。そして、この場合、「ｓｔａｂｌｅ」状態へ復帰し、上記テストで読み込んだｎ個のセグメントのデータは、そのままキャッシュデータとして活用される。

次に、本第２実施形態に係る移動端末装置７０において、先読み量を、速度予測部７２により予測された情報に応じて変化させる場合の形態例を開示する。

速度予測部７２は、位置及び該位置毎の受信速度をデータベース化した速度マップＤＢ７４に加えて、移動端末装置７０の位置を計測して位置座標を出力するＧＰＳ（Global Positioning System）７６に接続されており、該ＧＰＳ７６と連携する。

速度予測部７２は、定期的にＧＰＳ７６から移動端末装置７０の位置座標を取得して記憶し、直近の所定回数（本実施形態では、２回）の記憶した情報から移動ベクトルを求める。また、速度予測部７２は、上記移動ベクトルに基づいて所定時間後（本実施形態では、１秒後）の移動後の移動端末装置７０の位置を予測（以下、「予測位置」という。）する。そして、速度予測部７２は、該予測位置から所定範囲内にある位置に対応する受信速度を速度マップＤＢ７４から読み出すことにより、該予測位置における受信速度を予測する。ここで、速度予測部７２は、上記受信速度の予測を以下のように行う。

まず、速度マップＤＢ７４が上記第１マップ形態である場合について説明する。なお、ここでは、予測位置を座標表現で（Ｘｐ，Ｙｐ）とし、速度マップＤＢ７４のｉ番目に登録されている位置の座標（以下、「エントリ座標」という。）を（Ｘｉ，Ｙｉ）とする。この場合、上記矩形領域の一辺の長さを２Ｄとすると、次の式（９）を満足する場合に、該矩形領域に対応する受信速度を、該予測位置における受信速度として予測する。

次に、速度マップＤＢ７４が上記第２マップ形態である場合について説明する。なお、ここでも、予測位置の座標を（Ｘｐ，Ｙｐ）とし、エントリ座標を（Ｘｉ，Ｙｉ）とする。この場合、上記円の半径をＲとし、予測位置と速度マップＤＢ７４に登録されている位置との距離の２乗をｒ^２とすると、次の式（１０）を満足する場合に、該円に対応する受信速度を、該予測位置における受信速度として予測する。

速度予測部７２は、以上のように求めた受信速度（以下、「予測速度」という。）をローカルプロキシサーバＰＳからの問い合わせに応じて通知する。なお、速度マップＤＢ７４に式（９）または式（１０）の条件を満足する適切なエントリ座標が見つからない場合、速度予測部７２は、受信速度の予測ができないことを示す値（一例として‘−１’）をローカルプロキシサーバＰＳに送信する。

なお、予測位置の座標（Ｘｐ，Ｙｐ）は、次の方法で求められる。

すなわち、現時点の直前の時刻ｔの時点で測定された位置の座標を座標（Ｘｐ_ｔ，Ｙｐ_ｔ）とし、該時刻ｔの直前の時刻ｔ−１の時点で得られた位置の座標を座標（Ｘｐ_ｔ−１，Ｙｐ_ｔ−１）とする。この場合、予測位置の座標（Ｘｐ，Ｙｐ）は次の式（１１）で得ることができる。なお、本実施形態では、上記時刻ｔとして、現時点の時刻の１秒前の時刻を適用し、上記時刻ｔ−１として、現時点の時刻の２秒前の時刻を適用しているが、これに限定されるものではない。

続いて、ローカルプロキシサーバＰＳによる、予測速度を考慮した先読み量の計算方法について説明する。

映像配信サーバ５０にストリームデータのセグメントを要求する際に、ローカルプロキシサーバＰＳは、速度予測部７２に予測速度を問い合わせ、これによって得られた予測速度が、対象とするセグメントのビットレートよりも小さい場合には、近い将来、対象とするセグメントの受信が間に合わなくなる可能性が高いので、先読み量を所定量（例えば、１個）増量し、先読み量を増やしておく。

ここで、予測速度がビットレートに対して十分に大きい場合は、任意のタイミングで余裕をもってセグメントを取得できる可能性が高いので、キャッシュ領域のバッファ容量を節約したい条件がある場合等は、先読み量を所定量（一例として、１個）減量する形態としてもよい。

なお、上記各実施形態では、クライアントＰＣ４０や移動端末装置７０にローカルプロキシサーバＰＳを設けた場合について説明したが、これに限定されるものではない。例えば、映像配信サーバのデータ配信のための負荷の軽減のためにユーザの環境の側に端末装置とは別体として配備するプロキシサーバやエッジサーバ等においても開示の技術は適用可能である。

図１５には、この場合のシステムの構成例が示されている。図１５に示す例では、ＷＡＮ（Wide Area Network）側の回線は、ＬＡＮ側の回線より通信速度が遅い。この場合、ハードウェアにより端末装置とは別体としてハードウェアにより構成されたプロキシサーバＨＰＳにより、第２実施形態に示したローカルプロキシサーバＰＳによる処理と同様の処理を実行する。これにより、第２実施形態と同様の効果が得られる。

また、上記各実施形態では、配信データとして動画及び音声を表す映像データを適用した場合を説明したが、これに限定されるものではない。例えば、配信データとして音声のみを表す音声データを適用する形態としてもよく、配信データとして動画のみを表す動画データを適用する形態としてもよい。

また、上記各実施形態では、閾値ＴＨｆｅ及び閾値ＴＨｕｔを１とした場合について説明したが、これに限定されるものではなく、これらの閾値として２以上を適用してもよいことは言うまでもない。この場合、上記各実施形態に比較して、受信データのビットレートの切り換えが頻発する状態の発生を防止することができる。

また、上記第１実施形態では、テスト・切換プログラム４３Ａ及びデータ転送プログラム４３Ｂを記録媒体９６から媒体読み書き装置４６を介してクライアントＰＣ４０の記憶部４３に読み込む態様を説明したが、これに限定されるものではない。例えば、テスト・切換プログラム４３Ａ及びデータ転送プログラム４３Ｂを、記憶部４３に予め記憶（インストール）しておく形態としてもよく、ネットワーク８０を介して外部装置から記憶部４３にダウンロードする形態としてもよい。

また、上記第２実施形態では、速度マップＤＢ７４を移動端末装置７０において保持する場合を説明したが、これに限定されるものではない。例えば、速度マップＤＢ７４を他の端末装置（図示省略。）において保持するようにしてもよい。なお、この場合、移動端末装置７０において速度マップＤＢ７４を参照する際には、該他の端末装置に対して参照することになる。この場合、移動端末装置７０の速度マップＤＢ７４を記憶するためのメモリ容量を削減することができる。

本明細書に記載された全ての文献、特許出願及び技術規格は、個々の文献、特許出願及び技術規格が参照により取り込まれることが具体的かつ個々に記された場合と同程度に、本明細書中に参照により取り込まれる。

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

（付記１）
動画及び音声の少なくとも一方を表し、マルチビットレートに対応した配信データから、何れかのビットレートの配信データの配信を選択的に要求し、該要求に応じて受信した配信データを再生するデータ再生部と、
前記データ再生部からの要求に応じた配信データをデータ配信装置から受信して、該要求に応じた転送速度で前記データ再生部に転送すると共に、前記データ配信装置との間の通信経路における通信状況を取得する取得部と、
前記取得部によって取得された通信状況に基づいて、現在時点のビットレートより高ビットレートの配信データの受信に切り換え可能か否かを判定する判定部と、
前記判定部によって切り換え可能と判定された場合、前記高ビットレートの配信データの受信に切り換えると共に、受信した配信データの前記データ再生部への転送速度を、現在時点より速い速度に切り換える切換部と、
を備えた端末装置。

（付記２）
前記取得部は、前記データ再生部からの要求に応じたビットレートの配信データである第１の配信データを受信している場合に、該ビットレートより高いビットレートの配信データである第２の配信データを前記データ配信装置に要求して受信し、該第２の配信データの受信に要した時間に基づいて前記通信状況を取得する
付記１記載の端末装置。

（付記３）
前記取得部は、前記データ再生部からの要求に応じたビットレートの配信データである第１の配信データを受信している場合に、該ビットレートより高いビットレートの配信データである第２の配信データのビットレートに応じて前記第１の配信データを増量して前記データ配信装置に要求して受信し、該第１の配信データの受信に要した時間に基づいて前記通信状況を取得する
付記１記載の端末装置。

（付記４）
前記判定部は、前記取得部によって取得された通信状況に基づいて、現在時点のビットレートより低ビットレートの配信データの受信に切り換える必要があるか否かをさらに判定し、
前記切換部は、前記判定部により、前記低ビットレートの配信データの受信に切り換える必要があると判定された場合、前記低ビットレートの配信データの受信に切り換えると共に、受信した配信データの前記データ再生部への転送速度を、現在時点より遅い速度に切り換える
付記１〜付記３の何れか１項記載の端末装置。

（付記５）
前記取得部は、ピア・ツー・ピア技術により前記データ配信装置からの前記配信データの受信に代えて他の端末装置から該配信データを受信する場合、該他の端末装置との間の通信経路における通信状況を取得する
付記１〜付記４の何れか１項記載の端末装置。

（付記６）
前記配信データの配信元からの該配信データの受信速度を予測する予測部をさらに備え、
前記取得部は、前記配信データを先読みする場合のデータ要求量を、前記予測部によって予測された受信速度に基づいて決定する
付記１〜付記５の何れか１項記載の端末装置。

（付記７）
前記配信データは、ＭＰＥＧ−ＤＡＳＨで規定されるデータである
付記１〜付記６の何れか１項記載の端末装置。

（付記８）
前記取得部、前記判定部、及び前記切換部は、自端末装置のローカルプロキシサーバとしてソフトウェアにより構成されている
付記１〜付記７の何れか１項記載の端末装置。

（付記９）
前記取得部、前記判定部、及び前記切換部は、自端末装置とは別体としてハードウェアにより構成されている
付記１〜付記７の何れか１項記載の端末装置。

（付記１０）
前記他の端末装置は、自端末装置と同様の構成とされている
付記５記載の端末装置。

（付記１１）
動画及び音声の少なくとも一方を表し、マルチビットレートに対応した配信データから、何れかのビットレートの配信データの配信を選択的に要求し、該要求に応じて受信した配信データを再生するデータ再生部からの要求に応じた配信データをデータ配信装置から受信して、該要求に応じた転送速度で前記データ再生部に転送すると共に、前記データ配信装置との間の通信経路における通信状況を取得し、
取得した通信状況に基づいて、現在時点のビットレートより高ビットレートの配信データの受信に切り換え可能か否かを判定し、
切り換え可能と判定した場合、前記高ビットレートの配信データの受信に切り換えると共に、受信した配信データの前記データ再生部への転送速度を、現在時点より速い速度に切り換える、
ことを含む処理をコンピュータに実行させるデータ配信方法。

（付記１２）
前記データ再生部からの要求に応じたビットレートの配信データである第１の配信データを受信している場合に、該ビットレートより高いビットレートの配信データである第２の配信データを前記データ配信装置に要求して受信し、該第２の配信データの受信に要した時間に基づいて前記通信状況を取得する
付記１１記載のデータ配信方法。

（付記１３）
前記データ再生部からの要求に応じたビットレートの配信データである第１の配信データを受信している場合に、該ビットレートより高いビットレートの配信データである第２の配信データのビットレートに応じて前記第１の配信データを増量して前記データ配信装置に要求して受信し、該第１の配信データの受信に要した時間に基づいて前記通信状況を取得する
付記１１記載のデータ配信方法。

（付記１４）
取得した通信状況に基づいて、現在時点のビットレートより低ビットレートの配信データの受信に切り換える必要があるか否かをさらに判定し、
前記低ビットレートの配信データの受信に切り換える必要があると判定した場合、前記低ビットレートの配信データの受信に切り換えると共に、受信した配信データの前記データ再生部への転送速度を、現在時点より遅い速度に切り換える
付記１０〜付記１２の何れか１項記載のデータ配信方法。

（付記１５）
ピア・ツー・ピア技術により前記データ配信装置からの前記配信データの受信に代えて他の端末装置から該配信データを受信する場合、該他の端末装置との間の通信経路における通信状況を取得する
付記１１〜付記１４の何れか１項記載のデータ配信方法。

（付記１６）
前記配信データの配信元からの該配信データの受信速度を予測し、
前記配信データを先読みする場合のデータ要求量を、前記予測した受信速度に基づいて決定する
付記１１〜付記１５の何れか１項記載のデータ配信方法。

（付記１７）
前記配信データは、ＭＰＥＧ−ＤＡＳＨで規定されるデータである
付記１１〜付記１６の何れか１項記載のデータ配信方法。

（付記１８）
前記通信状況の取得、前記切り換え可能か否かの判定、及び前記切り換えを、ローカルプロキシサーバとしてソフトウェアにより実行する
付記１１〜付記１７の何れか１項記載のデータ配信方法。

（付記１９）
前記通信状況の取得、前記切り換え可能か否かの判定、及び前記切り換えを、ハードウェアにより実行する
付記１１〜付記１７の何れか１項記載のデータ配信方法。

１０ 端末装置
１１ データ再生部
１２ 取得部
１３ 判定部
１４ 切換部
１４Ａ 第１切換部
１４Ｂ 第２切換部
１６ データ配信装置
２０ 端末装置
２１ データ再生部
２２ 取得部
２３ 判定部
２４ 切換部
３０ コンピュータ・システム
４０、４０Ａ〜４０Ｃ クライアントＰＣ
４１ ＣＰＵ
４２ メモリ
４３ 記憶部
４３Ａ テスト・切換プログラム
４３Ａ１ 取得プロセス
４３Ａ２ 判定プロセス
４３Ａ３ 第１切換プロセス
４３Ｂ データ転送プログラム
４３Ｂ１ 第２切換プロセス
４４ 入力部
４５ 表示部
５０ 映像配信サーバ
６０ Ｐ２Ｐインデックスサーバ
６３ 記憶部
６３Ａ 端末情報管理テーブル記憶領域
７０ 移動端末装置
７２ 速度予測部
７４ 速度マップＤＢ
７６ ＧＰＳ
８０ ネットワーク
ＣＭ Ｐ２Ｐクライアントモジュール
ＨＰＳ プロキシサーバ
ＭＰ メディアプレーヤ
ＰＳ ローカルプロキシサーバ

Claims (9)

1. 動画及び音声の少なくとも一方を表し、マルチビットレートに対応した配信データから、何れかのビットレートの配信データの配信を選択的に要求し、該要求に応じて受信した配信データを再生するデータ再生部と、
   前記データ再生部からの要求に応じた配信データをデータ配信装置から受信して、該要求に応じた転送速度で前記データ再生部に転送すると共に、前記データ配信装置との間の通信経路における通信状況を取得する取得部と、
   前記取得部によって取得された通信状況に基づいて、現在時点のビットレートより高ビットレートの配信データの受信に切り換え可能か否かを判定する判定部と、
   前記判定部によって切り換え可能と判定された場合、前記高ビットレートの配信データの受信に切り換えると共に、受信した配信データの前記データ再生部への転送速度を、現在時点より速い速度に切り換える切換部と、
   を備えた端末装置。
2. 前記取得部は、前記データ再生部からの要求に応じたビットレートの配信データである第１の配信データを受信している場合に、該ビットレートより高いビットレートの配信データである第２の配信データを前記データ配信装置に要求して受信し、該第２の配信データの受信に要した時間に基づいて前記通信状況を取得する
   請求項１記載の端末装置。
3. 前記取得部は、前記データ再生部からの要求に応じたビットレートの配信データである第１の配信データを受信している場合に、該ビットレートより高いビットレートの配信データである第２の配信データのビットレートに応じて前記第１の配信データを増量して前記データ配信装置に要求して受信し、該第１の配信データの受信に要した時間に基づいて前記通信状況を取得する
   請求項１記載の端末装置。
4. 前記判定部は、前記取得部によって取得された通信状況に基づいて、現在時点のビットレートより低ビットレートの配信データの受信に切り換える必要があるか否かをさらに判定し、
   前記切換部は、前記判定部により、前記低ビットレートの配信データの受信に切り換える必要があると判定された場合、前記低ビットレートの配信データの受信に切り換えると共に、受信した配信データの前記データ再生部への転送速度を、現在時点より遅い速度に切り換える
   請求項１〜請求項３の何れか１項記載の端末装置。
5. 前記取得部は、ピア・ツー・ピア技術により前記データ配信装置からの前記配信データの受信に代えて他の端末装置から該配信データを受信する場合、該他の端末装置との間の通信経路における通信状況を取得する
   請求項１〜請求項４の何れか１項記載の端末装置。
6. 前記配信データの配信元からの該配信データの受信速度を予測する予測部をさらに備え、
   前記取得部は、前記配信データを先読みする場合のデータ要求量を、前記予測部によって予測された受信速度に基づいて決定する
   請求項１〜請求項５の何れか１項記載の端末装置。
7. 前記配信データは、ＭＰＥＧ−ＤＡＳＨで規定されるデータである
   請求項１〜請求項６の何れか１項記載の端末装置。
8. 前記取得部、前記判定部、及び前記切換部は、自端末装置のローカルプロキシサーバとしてソフトウェアにより構成されている
   請求項１〜請求項７の何れか１項記載の端末装置。
9. 動画及び音声の少なくとも一方を表し、マルチビットレートに対応した配信データから、何れかのビットレートの配信データの配信を選択的に要求し、該要求に応じて受信した配信データを再生するデータ再生部からの要求に応じた配信データをデータ配信装置から受信して、該要求に応じた転送速度で前記データ再生部に転送すると共に、前記データ配信装置との間の通信経路における通信状況を取得し、
   取得した通信状況に基づいて、現在時点のビットレートより高ビットレートの配信データの受信に切り換え可能か否かを判定し、
   切り換え可能と判定した場合、前記高ビットレートの配信データの受信に切り換えると共に、受信した配信データの前記データ再生部への転送速度を、現在時点より速い速度に切り換える、
   ことを含む処理をコンピュータに実行させるデータ配信方法。