JP2002215516A

JP2002215516A - 情報端末装置、ダウンロード制御方法およびコンピュータプログラム

Info

Publication number: JP2002215516A
Application number: JP2001013008A
Authority: JP
Inventors: Makoto Abe; 阿部　　誠; Masahisa Someya; 賢久染谷
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2001-01-22
Filing date: 2001-01-22
Publication date: 2002-08-02

Abstract

(57)【要約】【課題】ダウンロードしたデータのストリーミング再生
に際して、データの一部分を逐次サーバに要求する場合
に効率的なデータ転送を実現する。【解決手段】データ配信サーバからのデータのダウンロ
ードに際し、バッファメモリに対するデータのオーバー
フローが発生しない範囲内でサーバに対して最大限のサ
イズの部分データの転送を要求し、転送されたデータを
バッファメモリに格納していく。所定量のデータが格納
された時点でデータの再生を開始する。その後、バッフ
ァメモリ内の未再生データの量に基づいて、当該バッフ
ァ残量に対し、バッファメモリに対するデータのオーバ
ーフローが発生しない範囲内で、サーバに対して要求す
る部分データの最大限のサイズを逐次計算する。バッフ
ァ残量が予め定めた閾値以下となるのを待って、当該最
大限のサイズの部分データの転送を要求する。全データ
の転送要求が終了するまで再生と並行して上記のような
データ転送要求を繰り返す。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報端末装置によ
る、サーバからのデータのダウンロードおよびストリー
ミング再生に関する。

【０００２】

【従来の技術】近年、携帯電話（簡易携帯電話を含む）
やＰＤＡ(Personal Digital Assistant)のような携帯型
の情報端末装置が普及し、ユーザの要求に応じて、イン
ターネットのような通信網上にあるサーバから、音楽デ
ータを代表とする種々のデータの配信を行うサービスが
企画され、開始されている。

【０００３】このようにサーバに対してクライアントが
データの転送を要求し、サーバからデータ全体を受信し
終わる前に当該データの再生を開始し、受信と並行して
再生を実行する技術は、いわゆるストリーミング再生と
して知られている。

【０００４】

【発明が解決しようとする課題】ストリーミング再生に
おいては、再生によりデータを消費するデータ速度より
転送されるデータ速度の方が大きくなければ再生が転送
に追いついてしまい、再生が停止してしまう。このた
め、データ転送速度を大きくとる必要がある。しかし、
逆に転送速度が大きすぎる場合には、一度に大きなデー
タの要求を行いクライアント側で用意した内部バッファ
の容量を越えたデータが転送されたとき、バッファのオ
ーバーフローが発生し、そのあふれたデータは欠落デー
タとなってしまう。これを回避するためには、オーバー
フローが生じないように、サーバ側に対して、一度にデ
ータの一部分を転送するように要求し、この要求を何度
も繰り返して行う必要がある。しかし、このような高頻
度の要求により冗長なヘッダ情報などの比率が増大して
データ転送効率が低下したり、要求からレスポンスまで
に遅延が生じたりするおそれがある。また、その結果、
再生が転送に追いついて再生が停止してしまう等のおそ
れもある。

【０００５】このような問題は、内部バッファとして利
用できるメモリ容量が制限されることの多い携帯型の情
報端末装置、また、データ転送速度が変動しやすいイン
ターネットのような通信環境でのデータダウンロードに
おいて顕著となる。

【０００６】本発明は、このような背景においてなされ
たものであり、ダウンロードしたデータのストリーミン
グ再生に際して、１回のダウンロード時にデータの一部
分を逐次サーバに要求する場合に効率的なデータ転送を
実現することができるダウンロード制御方法および情報
端末装置を提供することを目的とする。

【０００７】

【課題を解決するための手段】本発明による情報端末装
置は、通信網を介してデータのダウンロードを行う情報
端末装置であって、データを配信するサーバへ接続する
ためのデータ通信手段と、前記サーバからダウンロード
されたデータを一時的に格納するための所定の記憶容量
を有するバッファメモリと、このバッファメモリに格納
されたデータを再生する再生手段と、データのダウンロ
ード時に、前記サーバに対して当該データのサイズより
小さいサイズの部分データ単位に前記サーバへ転送の要
求を逐次行う制御手段とを備え、この制御手段は、前記
バッファメモリへのダウンロードデータの書き込み中
に、前記再生手段によりデータの再生を開始し、前記バ
ッファメモリに対するデータのオーバーフローが発生し
ない範囲内で、前記サーバに対する１回のデータ転送要
求時に最大限のサイズの部分データの転送を要求するこ
とを特徴とする。

【０００８】このように、本発明では、ダウンロード対
象のデータの一部分を逐次複数回に分けてサーバに要求
する際に、バッファへのデータの書き込みの終了前に再
生を開始し、かつ、各部分データの要求時にはバッファ
メモリに対するデータのオーバーフローが発生しない範
囲内で、最大限のサイズの部分データの転送を要求す
る。これにより、転送要求回数を最小限にして、効率的
なデータのダウンロードを行うことが可能となる。

【０００９】前記転送を要求する部分データのサイズ
は、好ましくは、データ転送速度とこれより遅いデータ
再生速度との差に応じて増大していく前記バッファメモ
リ内の未再生データサイズが前記所定の記憶容量を越え
ることのないほぼ最大のサイズである。より具体的に
は、前記要求する部分データのサイズは、当該部分デー
タの要求時から、前記バッファメモリ内の未再生データ
サイズがほぼ前記所定の記憶容量に達する時点までの、
前記データ転送速度による累積転送データ量により定め
ることができる。この際、好ましくは、前記バッファメ
モリ内の未再生データサイズは、ダウンロード開始時の
最初の部分データの要求時には０であり、２回目以降の
部分データの要求時には所定の残量が存在し、２回目以
降の部分データの要求は、前記残量が予め定めた閾値以
下になるまで、要求を待機する。

【００１０】前記データ転送速度は、少なくとも前記ダ
ウンロード開始時の最初の部分データの要求時には推定
値を用いる。この推定値は、例えば、予測されるデータ
転送速度に安全係数を掛け合わせて得られる値、あるい
は、当該通信網で予測される最大のデータ転送速度の値
である。

【００１１】前記データ転送速度は、前記ダウンロード
開始後の２回目以降の部分データの要求時には、先行す
る部分データの実際の転送速度の実測値を基に決定する
ようにすることも可能である。

【００１２】また、本発明によるダウンロード制御方法
は、通信網を介してデータのダウンロードを行う情報端
末装置におけるダウンロード制御方法であって、（ａ）
データを配信するサーバへ接続するステップと、（ｂ）
前記サーバからのデータのダウンロードに際し、前記バ
ッファメモリに対するデータのオーバーフローが発生し
ない範囲内で前記サーバに対して要求する部分データの
最大限のサイズの部分データの転送を要求するステップ
と、（ｃ）転送されたデータをバッファメモリに格納し
ていくステップと、（ｄ）所定量のデータが格納された
時点で当該データの再生を開始するステップと、（ｅ）
前記バッファメモリ内の未再生データの量に基づいて、
当該量に対し、前記バッファメモリに対するデータのオ
ーバーフローが発生しない範囲内で、前記サーバに対し
て要求する部分データの最大限のサイズを逐次計算する
ステップと、（ｆ）当該最大限のサイズがあらかじめ定
めた閾値以下になったか否かをチェックするステップ
と、（ｇ）前記閾値以下になったと判定されたとき、当
該最大限のサイズの部分データの転送を要求するステッ
プとを備え、全データの転送要求が終了するまで、前記
再生と並行して前記ステップ（ｅ）（ｆ）（ｇ）を繰り
返して実行することを特徴とする。

【００１３】この方法において、前記バッファメモリ内
の未再生データの量があらかじめ定めた閾値以下になら
ない場合であっても、前記計算された部分データのサイ
ズ分の次の１回のデータ転送で全データの転送が終了す
ると判断される場合、当該全データのサイズを転送要求
サイズとしてデータの転送要求を行う。

【００１４】本発明はまた、上記のような通信網を介し
てデータのダウンロードを行う情報端末装置におけるダ
ウンロード制御方法を実現するコンピュータプログラ
ム、または、このコンピュータプログラムを格納したプ
ログラム格納媒体として把握することも可能である。

【００１５】

【発明の実施の形態】以下、本発明の好適な実施の形態
について、図面を参照しながら詳細に説明する。

【００１６】まず図１により、本発明が適用される情報
端末装置の一例としての携帯電話機１０と、データを配
信するサーバとしての音楽配信サーバ５０との関係を説
明する。但し、本発明の情報端末装置は携帯電話機に限
るものではない。バッファメモリの容量に制限があり、
ダウンロードすべきデータの複数の転送を逐次要求する
ような情報端末装置であれば、本発明は任意の情報端末
装置に適用することができる。そのような情報端末装置
としては、携帯電話機のほかに、ＰＤＡ、ゲーム機等が
挙げられる。

【００１７】図１において、携帯電話機１０は、図示し
ない基地局およびゲートウェイ（データセンター）等を
介してインターネット３０に接続され、インターネット
３０上の音楽配信サーバ３０による音楽データのダウン
ロードサービスを享受する。

【００１８】携帯電話機１０は、基地局との間で無線信
号を授受するアンテナ１１、アンテナからの受信信号の
処理およびアンテナへの送信信号の処理を行う送受信部
（Ｔｘ／Ｒｘ）１３、この送受信部１３を含む携帯電話
機１０全体の制御を行うＣＰＵ１５、表示部を構成する
液晶ディスプレイ（ＬＣＤ）１６、テンキーを初めとす
る各種操作キーを含む操作キー部１７、前記ＣＰＵ１５
により利用される内部データバッファおよび作業領域を
提供するメモリ（ＲＡＭ）１８、ＣＰＵ１５の制御下で
音楽データのデコードおよび再生処理を行う音楽プレー
ヤ部１９、およびオーディオ信号を音声に変換するスピ
ーカ２１を備える。特に図示しないが、通常の携帯電話
機に備えられるマイクロフォンも具備している。その
他、外部のステレオイヤホン等への信号出力部を備えて
もよい。ＣＰＵ１５は、制御プログラムを格納したＲＯ
Ｍや各種コントローラ等も内蔵している。音楽プレーヤ
部１９は、本実施の形態では、高能率符号化方式の一種
であるＡＴＲＡＣ３（Adaptive TRansform Acoustic Co
ding 3）の利用を想定している。また、インターネット
とのデータの授受は、ＴＣＰ／ＩＰプロトコルの利用を
想定している。しかし、本発明は特にこれらに限られる
ものではなく、音楽データ圧縮方式、デコード手段の構
成および通信プロトコル等の如何は問わない。この携帯
電話機１０自体の構成は既知のものでよく、本発明の特
徴部はＣＰＵ１５の新規なダウンロード処理およびそれ
を実現するコンピュータプログラムにある。

【００１９】次に図２により、本発明の概略動作を説明
する。特定の音楽データのダウンロードに際して、一度
に要求する部分データの量（サイズ）を、内部データバ
ッファの容量およびストリーミング再生開始後のそのデ
ータ残量に応じて、バッファのオーバーフローが起きな
い範囲内で最大となるように決定する。すなわち、個々
の部分データ転送要求時には、その時点のバッファの空
き容量を超える量のデータの転送を要求する。これは、
バッファにデータを蓄積していく一方で、そのデータの
再生を並行して行うことにより、バッファの空き容量分
のデータを取り込んだ時点では既にその何分の一かは再
生されており、バッファのオーバーフローを起こすこと
なく、さらに多くのデータをバッファ内に取り込むこと
が可能であるからである。これによって、一度に要求す
る部分データのサイズを最大限に大きくし、効率的なデ
ータ転送を実現することができる。データ転送要求時に
要求する部分データのサイズの具体的な決定方法につい
ては後に詳述する。

【００２０】図２（ａ）に示すように、最初にバッファ
の空き容量より大きい所定量のデータの要求をサーバに
対して行うと、これに応じて、時点ｔ０でダウンロード
が開始され、所定の転送速度で受信データがバッファ内
に取り込まれていく。この受信データの転送速度は変動
しうる。一方、ダウンロード開始後にバッファ内に所定
量ｄ０のデータが蓄積された時点ｔ１でバッファ内のデ
ータの再生が開始される。ただし、この所定量ｄ０は厳
密な値である必要はないので、時点ｔ１は、バッファ内
データに基づくのではなく、受信開始からの予め定めた
時間に基づいて決定してもよい。

【００２１】データ再生によりバッファ内のデータが消
費される速度であるデータ再生速度はほぼ一定であり、
データを受信するデータ転送速度より遅い。よって、図
２（ｂ）に示すように、バッファ内の未再生のデータ
は、データ転送速度とデータ再生速度の差分の速度でバ
ッファ内に蓄積されていく。これは、要求された部分デ
ータの全量が受信完了する時点ｔ２まで継続する。時点
ｔ２でデータの受信が停止する一方、データの再生は継
続されるので、バッファ内の未再生データは減少に転ず
る。この未再生データは、時点ｔ３で、あらかじめ定め
た量まで低減する。このようにバッファの残量がある所
定のサイズ（閾値）以下となるまで次の部分データの転
送要求の発生を待つ。これは要求する部分データのサイ
ズを最大限に大きくしようとするものである。図２の例
では閾値は、ｄ０と同じとしてあるが、ｄ０と異なって
もよい。時点ｔ３で、サーバに対して次の部分データの
要求を行うと、以後、時点ｔ１から時点ｔ２までの期間
と同様に、時点ｔ３から時点ｔ４までの間でデータの受
信と再生が並行して実行される。時点ｔ４では再生が停
止され、時点ｔ４から時点ｔ５までの間にバッファ内の
未再生データの量が漸次低減していく。時点ｔ５で再度
次の部分データの要求サイズが決定される。ただし、要
求すべきデータサイズよりサーバ側の残りのデータ量が
小さい場合には、そのデータ量を要求サイズとする。時
点ｔ５でデータを要求した後、時点ｔ６で全データの受
信が完了する。その後もデータ再生は継続され、時点ｔ
７でデータ再生が完了する。

【００２２】このように、本発明は、一つの音楽データ
をダウンロードする際に、バッファの容量制限のために
複数回に分けてデータの転送を要求する必要がある場合
であっても、ストリーミング再生におけるバッファの使
用状況に応じて、最小限の転送要求回数で効率的にダウ
ンロードを実行できるようにするものである。

【００２３】以下、データ転送要求時に要求するデータ
のサイズの具体的な決定方法について説明する。バッフ
ァ内の未再生データの有無の相違により、初回の部分デ
ータ要求時と２回目以降の部分データ要求時とは要求サ
イズの計算方法が異なる。すなわち、初回の要求時には
バッファ残量は０であるが、２回目以降の要求時にはバ
ッファ内に所定量のデータが残っている状態でデータ転
送要求を行う。これは、再生の途中で再生すべきデータ
がとぎれてしまうことを防止するためである。以下で
は、初回の要求時と２回目以降とで別々の図で説明す
る。

【００２４】まず図３により、最初の部分データ要求時
の要求データサイズの決定方法を説明する。ここで、次
のようなパラメータを設定する。

【００２５】ｔ１：再生開始予想時刻（ｓ）（時点ｔ０
を原点とする）ｔ２：当該要求分の部分データの転送完了予想時刻
（ｓ）ｄ０：再生開始時のバッファ内の所定のデータ量（byt
e) Ｒ０：初回の要求サイズ（転送要求する部分データのサ
イズ）(byte) Ｂ：既知のバッファサイズｄ：データ転送速度の推定値(byte/s) ｐ：再生速度の推定値(byte/s)

【００２６】これらのパラメータを用いて、要求サイズ
Ｒ０は次のように算出される。ｄ０＝ｄ×ｔ１これよりｔ１＝ｄ０／ｄ（１）Ｒ０＝ｄ×ｔ２これよりｔ２＝Ｒ０／ｄ（２）一方、Ｒ０＝Ｂ＋ｐ×（ｔ２−ｔ１）（３）式（１）（２）（３）から、次式が得られる。

【００２７】Ｒ０＝Ｂ＋（Ｒ０−ｄ０）×ｐ／ｄ（４）この式を逐次変形して、次の式（５）が得られる。Ｒ０＝（Ｂ×ｄ−ｄ０×ｐ）／（ｄ−ｐ）（５）

【００２８】式（５）は、既知のバッファサイズＢ、再
生開始時のバッファ内の所定のデータ量ｄ０、データ転
送速度の推定値ｄ、および再生速度の推定値ｐに基づい
て、要求サイズＲ０が計算により求められることを示し
ている。図３から明らかなように、このＲ０の値は、バ
ッファサイズＢより遙かに大きい。しかし、バッファの
オーバーフローは生じない。バッファ内の未再生データ
の蓄積量がバッファサイズを超える直前でデータの転送
が停止されるからである。換言すれば、要求サイズＲ０
はそのようなサイズとして求められる。

【００２９】なお、データの転送速度は常時一定ではな
く状況によって変わりうるので、転送速度の推定値ｄ
は、予測される実際のデータ転送速度に所定の安全係数
（＞１）を掛け合わせて得られる値を用いることが好ま
しい。これにより、転送速度が予測したより速くなった
場合のバッファのオーバーフローを確実に防止すること
が可能となる。図３において、転送速度の推定値ｄが大
きいほどバッファ内の未再生データの蓄積量の増加速度
が大きく、早い時点（図ではｔ２）でバッファサイズＢ
に達する。しかし、この時点で受信すべきデータがなく
なれば、バッファからデータがあふれることがない。実
際の転送速度が推定値ｄより小さい場合には、図の場合
よりも未再生データの蓄積量の増加速度が小さくなるの
で、受信データの終了までの時間ｔ２は延びるが、やは
り未再生データがバッファサイズに到達することはな
い。

【００３０】安全係数の値は、個々の通信システムによ
って経験的、実験的に妥当な値を設定することができ
る。通信システムによってその最高のデータ転送速度が
決まっており、予測値に安全係数を掛けて得られた推定
値が当該最高速度を超えるような場合は、推定値として
当該最高速度を用いる。再生速度も変動する可能性があ
るが、転送速度に比べて変動幅が小さいと考えられるの
で、再生速度の変動には、前記転送速度の安全係数で対
処することができる。

【００３１】次に図４により、２回目以降の要求サイズ
の計算について説明する。この場合、図３の場合と異な
るのは、データ転送要求を発する時点でバッファ内に非
０の未再生データ（バッファ残量ｂｒ）が残存している
ことである。これは、一時的にでも再生が停止すること
がないように、バッファ残量が０になる前に次の要求を
発するためである。

【００３２】この場合の部分データの要求サイズは、次
のようにして求められる。ここでは、２回目以降を代表
して２回目の要求についてのパラメータを示し、２回目
の要求サイズを計算する。

【００３３】ｔ３：転送要求（および転送再開）時刻
（ｓ）ｔ４：当該要求分の部分データの転送完了予想時刻
（ｓ）ｂｒ：時点ｔ３でのバッファ残量（byte) Ｒ１：２回目の要求サイズ(byte) Ｂ：既知のバッファサイズｄ：データ転送速度の推定値(byte/s) ｐ：再生速度の推定値(byte/s)

【００３４】これらのパラメータを用いて、Ｂ＝Ｒ１＋ｂｒ−ｐ×（ｔ４−ｔ３）（６）これより、ｔ４−ｔ３＝（Ｒ１＋ｂｒ−Ｂ）／ｐ（７）一方、Ｒ１＝ｄ×（ｔ４−ｔ３）（８）式（７）、（８）より、Ｒ１＝（Ｒ１＋ｂｒ−Ｂ）×ｄ／ｐ（９）この式（９）をＲ１について解けば、次式が得られる。Ｒ１＝（Ｂ−ｂｒ）×ｄ／（ｄ−ｐ）（10）

【００３５】式（10）は、既知のバッファサイズＢ、再
生開始時のバッファ内のデータ残量ｂｒ、データ転送速
度の推定値ｄ、および再生速度の推定値ｐに基づいて、
要求サイズＲ１が計算により求められることを示してい
る。図４から明らかなように、このＲ１の値も、バッフ
ァサイズＢより大きい。また、前記と同様に、バッファ
のオーバーフローは生じない。

【００３６】図５に、本実施の形態におけるストリーミ
ング再生の処理手順の一例を示す。

【００３７】まず、初回の要求サイズを前述の式（５）
により計算する（Ｓ１１）。ついで、この計算された要
求サイズ分の部分データの転送をサーバに対して要求す
る（Ｓ１２）。その後、データの受信が開始され（Ｓ１
３）、所定量（ｄ０）のデータのバッファリング（蓄
積）を待って（Ｓ１４）、再生を開始する（Ｓ１５）。
この後、ダウンロードした全データを再生し終わるまで
（Ｓ１６）、以下の処理を継続する。全データの量は、
ダウンロード開始前にサーバから通知される情報により
予め端末側で認識できる。

【００３８】続くステップＳ１７では、今回の要求分の
部分データがすべて取得されたかを判断する。すべて取
得されるまでは、先のステップＳ１５へ戻る。今回の要
求分の部分データがすべて取得された後、上記式（10）
にしたがってその時点での要求サイズを計算する（Ｓ１
８）。サーバにおける未転送の残りのデータがこの要求
サイズ以下であれば（Ｓ１９，Ｙｅｓ）、残りのデータ
分の転送要求を行う（Ｓ２１）。そうでなければ（Ｓ１
９，Ｎｏ）、バッファ残量（ｂｒ）の大きさをチェック
する（Ｓ２０）。この残量が閾値より小さくなるまで
は、ステップＳ１５へ戻り、再生を継続する。バッファ
内の未再生のデータ残量ｂｒが閾値より小さくなるとい
うことは、式（10）から分かるように、要求サイズＲ１
が所定のサイズより大きくなることに相当する。ステッ
プＳ２０から戻ったステップＳ１５での処理では、前回
の要求分の部分データの受信を終了しているので、受信
処理は行われない。

【００３９】ステップＳ２０において、バッファ残量が
閾値以下となったら、その要求サイズで次の部分データ
の転送をサーバへ要求する（Ｓ２１）。ついで、ステッ
プＳ１５へ戻り、受信と再生を並行して実行する。

【００４０】ところで、上記実施の形態では、２回目以
降の要求サイズの計算時にも、転送速度の推定値ｄとし
ては、初回要求時と同じ値を用いた。しかし、１回目の
データ転送により実際のデータ転送速度は計測すること
ができる。そこで上記実施の形態の変形例として、２回
目以降の要求サイズの計算時には転送速度の推定値ｄと
して実測値を用いる場合を以下に説明する。図６に、そ
のようなストリーミング再生処理のフローチャートを示
す。図６の処理において、ステップＳ３１〜Ｓ３５およ
びＳ３７〜Ｓ４２は、図５のステップＳ１１〜Ｓ２１と
同じである。図５と異なるのは、ステップＳ３５の後に
ステップＳ３６を追加し、このステップＳ３６におい
て、実際のデータ転送速度を計算する点、および、ステ
ップＳ３９でこの計算されたデータ転送速度を利用する
点である。このような実測によるデータ転送速度の値と
しては、（１）最新の実測値、（２）一定時間の実測値
の平均値、（３）過去の最大値、等のいずれかを採用す
ることができる。このような実測値を用いることによ
り、必要最小限の転送速度推定値を用いることができ
る。これにより、図５の処理に比べて、必要以上に大き
い転送速度推定値を用いる必要がなくなる。

【００４１】図７により、推定値ｄが実際の転送速度に
近づいた場合の効果について説明する。この図に示すよ
うに転送速度の推定値と実際の転送速度に差がある場
合、要求サイズＲ０の部分データの受信終了時点はｔ２
より遅い時点ｔａとなる。このときのバッファ内未再生
データの量ＢａはバッファサイズＢより小さい。したが
って、オーバーフローまでに十分な余裕があり、バッフ
ァサイズを十分に利用しているとはいえない。これに対
して、仮に転送速度の推定値が実際の転送速度と一致し
た場合には、未再生データ量がバッファサイズに達する
のが時点ｔｂにまで延び、このときの要求サイズＲａは
Ｒ０より大きくなる。このように、転送速度の推定値を
実際の転送速度に近づけることにより、バッファ容量を
より有効に利用して、１回の部分データの転送要求サイ
ズを大きくし、要求回数の低減を図ることができる。但
し、データの転送速度の実測値も変動するので、バッフ
ァのオーバーフローの発生を完全に防止するためには、
実測値を用いる場合にも転送速度の推定値に、実測値か
らある程度の余裕をもたせることが好ましい。

【００４２】最後に図８により、具体的なシステムにお
ける具体的な処理例について説明する。この例は、ＰＨ
Ｓ(Personal Handyphone System)における６４Ｋｂｐｓ
のＰＩＡＦＳ方式のデータ通信サービスを利用したダウ
ンロードを想定している。この場合の最大転送速度は５
８．４Ｋｂｐｓであるが、ＩＰヘッドやＴＣＰヘッダを
考慮したＭＴＵ(Maximum Transmission Unit)１５００
ｂｙｔｅに対して、ＩＰヘッドおよびＴＣＰヘッダがそ
れぞれ２４ｂｙｔｅずつ付加されると仮定すると、実効
データは９６．８％となる。また、本実施の形態におけ
るストリーミング再生を行う一つのＨＴＴＰメッセージ
には、約１５０ｂｙｔｅのＨＴＴＰヘッダが付加される
が１回の転送要求（ＨＴＴＰリクエスト）ではコンテン
ツデータとして９０Ｋｂｙｔｅ以上の受信となり、ＨＴ
ＴＰヘッダは全体の１％にも満たないため、無視できる
ものとする。結果として、理想的な転送時の速度は５
６．５Ｋｂｐｓとなる。これも含めたパラメータを以下
に示す。

【００４３】バッファサイズＢ＝７０Ｋｂｙｔｅ転送速度推定値ｄ＝最大転送速度＝５６．５Ｋ
ｂｐｓバッファ残量閾値＝２４Ｋｂｙｔｅ総データサイズ＝３２９６００ｂｙｔｅ再生速度ｐ（再生データ消費量）＝５５０４ｂｙｔｅ
／ｓ（４４Ｋｂｐｓ）

【００４４】このような条件下でのデータの要求、受信
および再生の状態を示すのが図８のグラフである。この
例では、転送速度の推定値として最大の転送速度を用い
ている。３２９６００ｂｙｔｅの総データは、複数回に
分けて転送要求し、約６０秒かけて再生完了している。
それぞれの要求サイズは、上記式（５）（10）により具
体的に計算することができる。

【００４５】このようなストリーミング再生は、ユーザ
の要求に対して直ちに再生を開始することができるとい
う利点がある。また、バッファ内のデータは１回の再生
で消滅させてしまう構成とすれば、データは端末内に残
らないので、このような方式は、データの一時的な視
聴、例えば音楽データの試し聴きのような用途に適す
る。勿論、音楽データに限らず、インタビューや各種メ
ッセージ、ガイダンス等の音声にも適用できる。さらに
はこれらのオーディオデータに限らず、動画や、動画と
音声の組み合わせに対しても本発明は適用可能である。

【００４６】

【発明の効果】本発明によれば、ダウンロードしたデー
タのストリーミング再生に際して、１回のダウンロード
時にデータの一部分を逐次サーバに要求する場合に、限
られたバッファ容量を有効に用いて、効率的なデータ転
送を実現することができる。

【図面の簡単な説明】

【図１】本発明が適用される情報端末装置の一例として
携帯電話機と、データを配信するサーバとしての音楽配
信サーバとの関係を説明するための図である。

【図２】本発明の概略動作を説明するためのグラフであ
る。

【図３】本発明の実施の形態における最初の部分データ
要求時の要求データサイズの決定方法を説明するための
グラフである。

【図４】本発明の実施の形態における２回目以降の要求
サイズの計算について説明するためのグラフである。

【図５】本発明の実施の形態におけるストリーミング再
生の処理手順の一例を示すフローチャートである。

【図６】図５の処理の変形例を示すフローチャートであ
る。

【図７】本発明の実施の形態において推定値ｄが実際の
転送速度に近づいた場合の効果について説明するための
図である。

【図８】本発明の具体的なシステムにおける具体的な処
理例について説明するための図である。

【符号の説明】

１０…携帯電話機、１１…アンテナ、１３…送受信部、
１５…ＣＰＵ、１６…ＬＣＤ、１７…操作キー部、１８
…ＲＡＭ、１９…音楽プレーヤ部、２１…スピーカ、３
０…インターネット、５０…音楽配信サーバ

Claims

【特許請求の範囲】

【請求項１】通信網を介してデータのダウンロードを行
う情報端末装置であって、データを配信するサーバへ接続するためのデータ通信手
段と、前記サーバからダウンロードされたデータを一時的に格
納するための所定の記憶容量を有するバッファメモリ
と、このバッファメモリに格納されたデータを再生する再生
手段と、データのダウンロード時に、前記サーバに対して当該デ
ータのサイズより小さいサイズの部分データ単位に前記
サーバへ転送の要求を逐次行う制御手段とを備え、この制御手段は、前記バッファメモリへのダウンロード
データの書き込み中に、前記再生手段によりデータの再
生を開始し、前記バッファメモリに対するデータのオー
バーフローが発生しない範囲内で、前記サーバに対する
１回のデータ転送要求時に最大限のサイズの部分データ
の転送を要求することを特徴とする情報端末装置。
【請求項２】前記転送を要求する部分データのサイズ
は、データ転送速度とこれより遅いデータ再生速度との
差に応じて増大していく前記バッファメモリ内の未再生
データサイズが前記所定の記憶容量を越えることのない
ほぼ最大のサイズであることを特徴とする請求項１記載
の情報端末装置。
【請求項３】前記要求する部分データのサイズは、当該
部分データの要求時から、前記バッファメモリ内の未再
生データサイズがほぼ前記所定の記憶容量に達する時点
までの、前記データ転送速度による累積転送データ量に
より定めることを特徴とする請求項２記載の情報端末装
置。
【請求項４】前記バッファメモリ内の未再生データサイ
ズは、ダウンロード開始時の最初の部分データの要求時
には０であり、２回目以降の部分データの要求時には所
定の残量が存在し、２回目以降の部分データの要求は、
前記残量が予め定めた閾値以下になるまで、要求を待機
することを特徴とする請求項３記載の情報端末装置。
【請求項５】前記データ転送速度は、少なくとも前記ダ
ウンロード開始時の最初の部分データの要求時には推定
値を用いることを特徴とする請求項１〜４のいずれかに
記載の情報端末装置。
【請求項６】前記推定値は、予測されるデータ転送速度
に安全係数を掛け合わせて得られる値であることを特徴
とする請求項５記載の情報端末装置。
【請求項７】前記推定値は、当該通信網で予測される最
大のデータ転送速度の値であることを特徴とする請求項
５記載の情報端末装置。
【請求項８】前記データ転送速度は、前記ダウンロード
開始後の２回目以降の部分データの要求時には、先行す
る部分データの実際の転送速度の実測値を基に決定する
ことを特徴とする請求項５記載の情報端末装置。
【請求項９】通信網を介してデータのダウンロードを行
う情報端末装置におけるダウンロード制御方法であっ
て、（ａ）データを配信するサーバへ接続するステップ
と、（ｂ）前記サーバからのデータのダウンロードに際
し、前記バッファメモリに対するデータのオーバーフロ
ーが発生しない範囲内で前記サーバに対して最大限のサ
イズの部分データの転送を要求するステップと、（ｃ）
転送されたデータをバッファメモリに格納していくステ
ップと、（ｄ）所定量のデータが格納された時点で当該
データの再生を開始するステップと、（ｅ）前記バッフ
ァメモリ内の未再生データの量に基づいて、当該量に対
し、前記バッファメモリに対するデータのオーバーフロ
ーが発生しない範囲内で、前記サーバに対して要求する
部分データの最大限のサイズを逐次計算するステップ
と、（ｆ）前記バッファメモリ内の未再生データの量が
あらかじめ定めた閾値以下になったか否かをチェックす
るステップと、（ｇ）前記閾値以下になったと判定され
たとき、当該最大限のサイズの部分データの転送を要求
するステップとを備え、全データの転送要求が終了する
まで、前記再生と並行して前記ステップ（ｅ）（ｆ）
（ｇ）を繰り返して実行することを特徴とするダウンロ
ード制御方法。
【請求項１０】前記バッファメモリ内の未再生データの
量があらかじめ定めた閾値以下にならない場合であって
も、前記計算された部分データのサイズ分の次の１回の
データ転送で全データの転送が終了すると判断される場
合、当該全データのサイズを転送要求サイズとしてデー
タの転送要求を行うことを特徴とする請求項９記載のダ
ウンロード制御方法。
【請求項１１】前記転送を要求する部分データのサイズ
は、データ転送速度とこれより遅いデータ再生速度との
差に応じて増大していく前記バッファメモリ内の未再生
データサイズが前記所定の記憶容量を越えることのない
ほぼ最大のサイズであることを特徴とする請求項９記載
のダウンロード制御方法。
【請求項１２】前記要求する部分データのサイズは、当
該部分データの要求時から、前記バッファメモリ内の未
再生データサイズがほぼ前記所定の記憶容量に達する時
点までの、前記データ転送速度による累積転送データ量
により定めることを特徴とする請求項１１記載のダウン
ロード制御方法。
【請求項１３】前記バッファメモリ内の未再生データサ
イズは、ダウンロード開始時の最初の部分データの要求
時には０であり、２回目以降の部分データの要求時には
所定の残量が存在し、２回目以降の部分データの要求
は、前記残量が予め定めた閾値以下になるまで、要求を
待機することを特徴とする請求項１２記載のダウンロー
ド制御方法。
【請求項１４】前記データ転送速度は、少なくとも前記
ダウンロード開始時の最初の部分データの要求時には推
定値を用いることを特徴とする請求項１０〜１３のいず
れかに記載のダウンロード制御方法。
【請求項１５】前記推定値は、予測されるデータ転送速
度に安全係数を掛け合わせて得られる値であることを特
徴とする請求項１４記載のダウンロード制御方法。
【請求項１６】前記推定値は、当該通信網で予測される
最大のデータ転送速度の値であることを特徴とする請求
項１４記載のダウンロード制御方法。
【請求項１７】前記データ転送速度は、前記ダウンロー
ド開始後の２回目以降の部分データの要求時には、先行
する部分データの実際の転送速度の実測値を基に決定す
ることを特徴とする請求項１４記載のダウンロード制御
方法。
【請求項１８】通信網を介してデータのダウンロードを
行う情報端末装置におけるダウンロード制御方法を実現
するコンピュータプログラムであって、（ａ）データを
配信するサーバへ接続するステップと、（ｂ）前記サー
バからのデータのダウンロードに際し、前記バッファメ
モリに対するデータのオーバーフローが発生しない範囲
内で前記サーバに対して最大限のサイズの部分データの
転送を要求するステップと、（ｃ）転送されたデータを
バッファメモリに格納していくステップと、（ｄ）所定
量のデータが格納された時点で当該データの再生を開始
するステップと、（ｅ）前記バッファメモリ内の未再生
データの量に基づいて、当該量に対し、前記バッファメ
モリに対するデータのオーバーフローが発生しない範囲
内で、前記サーバに対して要求する部分データの最大限
のサイズを逐次計算するステップと、（ｆ）当該最大限
のサイズがあらかじめ定めた閾値以下になったか否かを
チェックするステップと、（ｇ）前記閾値以下になった
と判定されたとき、当該最大限のサイズの部分データの
転送を要求するステップとを備え、全データの転送要求
が終了するまで、前記再生と並行して前記ステップ
（ｅ）（ｆ）（ｇ）を繰り返して実行することを特徴と
するダウンロード制御方法を実現するコンピュータプロ
グラム。