端末装置
【課題】複数のコンテンツを順番に再生する際に、切れ目なくコンテンツが再生されるようにする。
【解決手段】端末装置は、１曲目のコンテンツデータをサーバ装置へ要求してからストリーミング形式の最初のコンテンツデータをデコードするまでの処理時間ｔ１を測定する。端末装置は、再生中のコンテンツの再生終了時刻Ｔ１３を算出する。端末装置は、処理時間ｔ１＋αの分だけ再生終了時刻Ｔ１３より前の時刻を、２曲目のコンテンツデータを要求する要求時刻Ｔ１とし、１曲目の再生中に要求時刻Ｔ１となると、２曲目のコンテンツデータをサーバ装置へ要求する。端末装置は、再生終了時刻Ｔ１３になる前にコンテンツデータを受信する。受信したコンテンツデータは、再生終了時刻Ｔ１３になる前にデコードされる。端末装置は、１曲目のコンテンツデータの再生が終了すると、直ぐに２曲目のコンテンツデータを再生する。
【解決手段】端末装置は、１曲目のコンテンツデータをサーバ装置へ要求してからストリーミング形式の最初のコンテンツデータをデコードするまでの処理時間ｔ１を測定する。端末装置は、再生中のコンテンツの再生終了時刻Ｔ１３を算出する。端末装置は、処理時間ｔ１＋αの分だけ再生終了時刻Ｔ１３より前の時刻を、２曲目のコンテンツデータを要求する要求時刻Ｔ１とし、１曲目の再生中に要求時刻Ｔ１となると、２曲目のコンテンツデータをサーバ装置へ要求する。端末装置は、再生終了時刻Ｔ１３になる前にコンテンツデータを受信する。受信したコンテンツデータは、再生終了時刻Ｔ１３になる前にデコードされる。端末装置は、１曲目のコンテンツデータの再生が終了すると、直ぐに２曲目のコンテンツデータを再生する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信回線を介してコンテンツを取得する技術に関する。
【背景技術】
【０００２】
音声及び映像を含むコンテンツをサーバ装置からクライアントへネットワークを介して送信するシステムとして、特許文献１に開示されたコンテンツ配信システムがある。このシステムにおいては、複数のコンテンツの配信要求がクライアントからサーバへ送信される。サーバは、配信要求を受け取ると、コンテンツをストリーミング形式で送信する。クライアントは、送信されたコンテンツをバッファに蓄積し、蓄積順に再生する。なお、クライアントは、バッファの残量を監視し、この残量を定期的にサーバへ通知する。サーバは、クライアントから通知される残量に基づいてコンテンツの送信速度を制御する。サーバは、最初のコンテンツを送信し終えると次のコンテンツの送信を開始する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−３１３９４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、特許文献１のシステムにおいては、コンテンツの送信開始のタイミングをサーバが主体で管理し、決定している。このシステムにおいてクライアントが複数あり、複数のクライアントから異なるグループの配信要求を受ける場合、サーバは、クライアント毎にコンテンツの送信タイミングを監視することになり、サーバに負荷が掛かることとなる。サーバに掛かる負荷を減らす方法としては、クライアントからの要求があってからコンテンツの送信を開始する方法がある。この方法によれば、サーバは要求があってからコンテンツを送信すればよいので、クライアント毎にコンテンツの送信タイミングを監視する必要がなく、負荷が減ることとなる。しかしながら、コンテンツを連続して再生する場合、再生中のコンテンツの再生が終了してから次のコンテンツを要求すると、コンテンツがクライアントに届くまでに時間がかかるため、再生中のコンテンツの再生が終了してから次のコンテンツの再生が開始されるまでに無音期間が生じることとなる。例えば、コンテンツがライブ演奏のアルバムやクラシック音楽のアルバムの曲であり、これらのアルバムの曲を連続して再生しようとする場合、これらのアルバムでは曲と曲との合間でも音が発生しているため、このように無音期間が発生すると不自然さを感じてしまうこととなる。
【０００５】
本発明は、上述した背景の下になされたものであり、複数のコンテンツを順番に再生する際に、切れ目なくコンテンツが再生されるようにすることを目的とする。
【課題を解決するための手段】
【０００６】
上述した課題と解決するため、本発明は、コンテンツを識別する識別子を含み当該コンテンツを要求する要求メッセージをサーバ装置へ送信する送信手段と、前記要求メッセージに応じて前記サーバ装置からストリーミング形式で順次送信されるエンコードされた複数ブロックのコンテンツデータを受信する受信手段と、前記受信手段で受信されたコンテンツデータをデコードして前記コンテンツを再生する再生手段と、前記要求メッセージを送信した時点から当該要求メッセージに応じて送信されるコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの処理時間を測定する測定手段と、前記要求メッセージで要求したコンテンツの再生終了時刻から少なくとも前記処理時間分より前の時刻において、前記再生手段で再生中のコンテンツの次に再生するコンテンツを要求する要求メッセージを前記送信手段から前記サーバ装置へ送信させる制御手段とを有する端末装置を提供する。
【０００７】
本発明においては、前記制御手段は、前記再生終了時刻から少なくとも前記処理時間分より前の時刻であり、且つ前記コンテンツデータのデコードがすべて完了した時刻より後の時刻において、前記要求メッセージを前記送信手段から前記サーバ装置へ送信させる構成であってもよい。
また、本発明においては、前記制御手段は、前記再生手段で再生中のコンテンツの要求メッセージを送信した時点から、当該要求メッセージに応じて送信されたコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの第２処理時間が、前記再生手段で再生中のコンテンツの一つ前に再生したコンテンツの要求メッセージを送信した時点から、当該要求メッセージに応じて送信されたコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの第１処理時間以上である場合、前記第２処理時間を前記処理時間とする構成であってもよい。
【０００８】
また、本発明においては、前記制御手段は、前記再生手段で再生中のコンテンツの要求メッセージを送信した時点から、当該要求メッセージに応じて送信されたコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの第２処理時間が、前記再生手段で再生中のコンテンツの一つ前に再生したコンテンツの要求メッセージを送信した時点から、当該要求メッセージに応じて送信されたコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの第１処理時間より短い場合、前記第２処理時間と前記第１処理時間の平均時間を前記処理時間とする構成であってもよい。
【発明の効果】
【０００９】
本発明によれば、複数のコンテンツを順番に再生する際に、切れ目なくコンテンツが再生される。
【図面の簡単な説明】
【００１０】
【図１】本発明の一実施形態に係るシステムの全体構成を示した図。
【図２】サーバ装置２０のハードウェア構成を示したブロック図。
【図３】サーバ装置２０が記憶するリストＬの内容を示した図。
【図４】端末装置１０のハードウェア構成を示したブロック図。
【図５】実施形態の動作を説明するためのシーケンス図。
【図６】端末装置１０が生成する再生リストの内容を示した図。
【図７】コンテンツデータの取得開始のタイミングを説明するための図。
【発明を実施するための形態】
【００１１】
［実施形態］
図１は、本発明の実施形態に係るシステムの全体構成を示した図である。図１に示したように、本システムにおいては、通信回線３０に端末装置１０とサーバ装置２０が接続される。なお、本実施形態においては、通信回線３０は有線ＬＡＮ（Local Area Network）となっているが、通信回線３０を無線ＬＡＮとし、無線通信により端末装置１０とサーバ装置２０が通信を行う構成であってもよい。
サーバ装置２０は、クライアントサーバシステムにおけるサーバとして機能する装置である。サーバ装置２０は、楽曲を表すコンテンツデータを記憶している。サーバ装置２０は、コンテンツデータをストリーミング形式で端末装置１０へ送信する。なお、本実施形態においては、コンテンツデータのフォーマットは、ＭＰ３（MPEG Audio Layer-3）となっている。
端末装置１０は、サーバ装置２０からコンテンツデータを取得し、取得したコンテンツデータを再生する装置である。例えば、サーバ装置２０を宅内のリビングルームに配置し、端末装置１０を宅内の各部屋に配置すれば、各部屋でコンテンツデータを再生して楽曲を聞くことができる。なお、本システムにおいては、サーバ装置２０は、複数の端末装置１０と通信を行うことが可能であるが、図面が繁雑になるのを防ぐため図面においては一つの端末装置１０を図示している。
【００１２】
（サーバ装置２０の構成）
図２は、サーバ装置２０のハードウェア構成を示したブロック図である。図２に示したように、サーバ装置２０の各部はバス２０１に接続されており、バス２０１を介して各部間でデータのやり取りを行う。
【００１３】
通信部２０８は、通信回線３０を介して通信を行う通信インターフェースとして機能し、他の装置とデータ通信を行う。表示部２０７は、液晶ディスプレイを備えており、サーバ装置２０を操作するための各種メニュー画面などを表示する。操作部２０６は、複数のボタンを備えている。サーバ装置２０の操作者によりボタンが操作されると、操作されたボタン応じてＣＰＵ（Central Processing Unit）２０２が各種処理を行う。
【００１４】
記憶部２０５は、ハードディスク装置を備えており、クライアントサーバシステムにおけるサーバの機能を実現するサーバプログラムを記憶している。また、記憶部２０５は、複数のコンテンツデータを記憶している。また、記憶部２０５は、コンテンツデータのリストＬを記憶している。図３は、コンテンツデータのリストＬの一例を示した図である。このリストＬの「ファイル名」の列においては、記憶部２０５に記憶されているコンテンツデータのファイル名が記述されている。また、リストＬの「曲名」の列においては、同じ行にあるファイル名のコンテンツデータが表す楽曲の曲名が記述されている。また、「演奏者名・歌手名」の列においては、同じ行にあるファイル名で特定されるコンテンツデータが表す楽曲の演奏者名または歌手名が記述されている。また、「データサイズ」の列には、同じ行にあるファイル名で特定されるコンテンツデータのサイズが記述されている。
【００１５】
ＲＯＭ（Read Only Memory）２０３は、初期制御プログラムを記憶している。サーバ装置２０の電源が入れられると、ＣＰＵ２０２はＲＯＭ２０３から初期制御プログラムを読み出して起動する。ＣＰＵ２０２により初期制御プログラムが起動されると、記憶部２０５に記憶されているサーバプログラムがＲＡＭ（Random Access Memory）２０４を利用して実行され、記憶部２０５を制御する機能や通信回線３０を介した通信を行う通信機能、コンテンツデータを端末装置１０へ送信する機能等、コンピュータ装置の機能及びクライアントサーバシステムにおけるサーバの機能が実現する。
【００１６】
（端末装置１０の構成）
図４は、端末装置１０のハードウェア構成を示したブロック図である。通信部１０８は、通信回線３０を介して通信を行う通信インターフェースとして機能し、他の装置とデータ通信を行う。操作部１０６は、端末装置１０を操作するための複数のボタンを備えている。端末装置１０の操作者によりボタンが操作されると、操作されたボタンに応じてＣＰＵ１０２が各種処理を行う。表示部１０７は、液晶ディスプレイを備えており、端末装置１０を操作するための各種メニュー画面や各種メッセージなどを表示する。再生部１０５は、スピーカ（図示略）を有している。再生部１０５は、コンテンツデータをエンコードすることによって得られたデータを受け取り、受け取ったデータから楽曲のアナログ信号を生成し、生成したアナログ信号をスピーカへ出力する。
【００１７】
ＲＯＭ１０３は、制御プログラムを記憶している。端末装置１０の電源が入れられると、ＣＰＵ１０２はＲＯＭ１０３から制御プログラムを読み出して実行する。ＣＰＵ１０２により制御プログラムが実行されると、通信回線３０を介した通信を行う通信機能、コンテンツデータをサーバ装置２０から取得する機能、時刻や時間を計るタイマー機能、取得したコンテンツデータをデコードする機能等、コンピュータ装置の機能及びクライアントサーバシステムにおけるクライアントの機能が実現する。
【００１８】
（動作例）
図５は、本実施形態の動作を説明するためのシーケンス図である。本実施形態に係るシステムの動作例について図５を用いて説明する。なお、以下の説明においては、まず端末装置１０で再生するコンテンツデータを端末装置１０において選択する動作について説明し、次に、端末装置１０で選択したコンテンツデータを端末装置１０がサーバ装置２０から取得して再生する動作について説明する。
【００１９】
（コンテンツデータを選択する時の動作）
まず、端末装置１０のユーザが、操作部１０６を操作してサーバ装置２０からリストＬの取得を指示する操作を行うと、ＣＰＵ１０２は、通信部１０８を制御し、リストＬを要求するリスト要求メッセージをサーバ装置２０へ送信する（ステップＳ１）。このリスト要求メッセージは、通信回線３０を介してサーバ装置２０へ送られ、通信部２０８で受信される。ＣＰＵ２０２は、リスト要求メッセージが通信部２０８で受信されると、記憶部２０５に記憶されているリストＬを表すデータを、通信部２０８を制御して端末装置１０へ送信する（ステップＳ２）。
【００２０】
このデータは、通信回線３０を介して端末装置１０へ送られ、通信部１０８で受信される。ＣＰＵ１０２は、リストＬを表すデータが通信部１０８で受信されると、受信したデータに基づいて表示部１０７を制御し、リストＬの曲名と演奏者名・歌手名の内容を表示部１０７に表示させる（ステップＳ３）。これにより、端末装置１０のユーザは、サーバ装置２０に記憶されているコンテンツデータの曲名を知ることができる。
【００２１】
次に、表示された曲名の中から再生する曲の曲名を選択する操作が端末装置１０において行われると、選択された曲名のリストが生成されてＲＡＭ１０４に記憶される（ステップＳ４）。例えば、再生する曲として「sample-1」、「sample-2」、「sample-4」が選択された場合、選択された曲名、選択された曲名に係るコンテンツデータのファイル名及び選択された曲に係るコンテンツデータのデータサイズがリストＬから抽出され、抽出されたファイル名、曲名及びデータサイズを対応付けた再生リスト（図６参照）がＲＡＭ１０４に記憶される。なお、再生リストにおいては、曲名が１行目から並べられている。曲名は、曲を再生する時の順番で並べられており、曲を再生する際には１行目の曲から順番に再生が行われる。
【００２２】
（コンテンツデータを取得して再生する時の動作）
次に、ユーザが選択した曲を再生する時の動作について図７を参照しながら説明する。ＲＡＭ１０４に記憶された再生リストの曲名を表示部１０７に表示させる操作が操作部１０６において行われると、ＣＰＵ１０２は、ＲＡＭ１０４に記憶された再生リストにある曲名を表示部１０７に表示させる（ステップＳ５）。次に、表示された曲名のコンテンツデータの再生を指示する操作が操作部１０６において行われると（ステップＳ６）、ＣＰＵ１０２は、再生リストにある曲名のコンテンツデータをサーバ装置２０から取得する。
【００２３】
例えば、再生リストの内容が図６に示した内容である場合、まずＣＰＵ１０２は、再生リストの１行目のファイル名を抽出する。次にＣＰＵ１０２は、抽出したファイル名を含みコンテンツを要求するコンテンツ要求メッセージを、通信部１０８を制御してサーバ装置２０へ送信する（ステップＳ７）。なお、ここでＣＰＵ１０２は、コンテンツ要求メッセージを送信した時点（要求時刻Ｔ０）からの経過時間の測定を開始する。
【００２４】
ファイル名を含むコンテンツ要求メッセージが通信部２０８で受信されると、ＣＰＵ２０２は、受信したファイル名のコンテンツデータを記憶部２０５から読み出し、読み出したコンテンツデータを複数のブロックに分け、通信部２０８を制御してストリーミング形式で端末装置１０へ送信する（ステップＳ８）。ＣＰＵ１０２は、通信部１０８においてコンテンツデータの最初のブロックが受信されると、受信したコンテンツデータのデコードを開始する。ＣＰＵ１０２は、所定期間のデコードが終了すると、時刻Ｔ０からの経過時間の測定を終了し、コンテンツ要求メッセージを送信した要求時刻Ｔ０からコンテンツデータの所定期間のデコードを完了した時点までの処理時間ｔ１をＲＡＭ１０４に記憶させる（ステップＳ９）。なお、ここでの所定期間とは、１ブロック分のコンテンツデータのデコードに要する期間であり、約１００ｍｓ〜１ｓほどである。
この後、引き続きサーバ装置２０からはコンテンツデータがストリーミング形式で送信され、順次ＲＡＭ１０４に記憶されると同時にデコードされる。ＣＰＵ１０２は、デコードにより得たデータを順次再生部１０５へ供給し、再生部１０５は、供給されたデータから楽曲のアナログ信号を生成し、生成したアナログ信号をスピーカへ出力する（１曲目の再生時刻Ｔ１１）。なお、再生部１０５に供給されたデータはＲＡＭ１０４から消去される。
【００２５】
ＣＰＵ１０２は、サーバ装置２０から順次送信されるデータをＲＡＭ１０４に記憶させ、ストリーミング形式で送信されるコンテンツデータの最後のブロックを受信したか否か判断する。なお、コンテンツデータの最後のブロックを受信したか否かは、最初のブロックを受信してからＲＡＭ１０４に記憶させたデータのサイズの合計が、再生リストのデータサイズの欄に記述されているデータサイズに達したか否かで判断することができる。例えば、「sample-1」という曲名のコンテンツデータの場合、ＣＰＵ１０２は、最初のブロックを受信してからＲＡＭ１０４に記憶させたデータのサイズの合計が５ＭＢｙｔｅになると、コンテンツデータの最後のブロックを受信したと判断する。ＣＰＵ１０２は、コンテンツデータの最後のブロックを受信したと判断すると、受信した全てのコンテンツデータをデコードしたか否か判断する。ＣＰＵ１０２は、全てデコードしたと判断すると、コンテンツデータのデコード処理を終了する。
【００２６】
ＣＰＵ１０２は、デコードが終了すると、受信した最後のブロックの再生終了時刻Ｔ１３を算出する（ステップＳ１０）。なお、データを再生し終えるまでに掛かる時間は、ＲＡＭ１０４に記憶されているデータ量に比例するため、データの再生終了時刻Ｔ１３は、ＲＡＭ１０４に記憶されているデータ量から算出することができる。例えば、図７に示した１曲目のデコード完了時刻Ｔ１２から最後のブロックが再生完了するまでにｎ秒かかる場合、１曲目のデコード完了時刻Ｔ１２よりｎ秒後の時刻が１曲目の再生終了時刻Ｔ１３となる。
【００２７】
次に、ＣＰＵ１０２は、次に再生するコンテンツデータについて、コンテンツ要求メッセージを送信する要求時刻Ｔ１を、ＲＡＭ１０４に記憶した処理時間ｔ１を用いて算出する（ステップＳ１１）。具体的には、ＣＰＵ１０２は、１曲目の再生終了時刻Ｔ１３より処理時間ｔ１＋αだけ前の時刻を要求時刻Ｔ１として算出する。αとは、予め実験的に求められた予備的な時間である。具体的には、１曲目の再生終了時刻Ｔ１３より処理時間ｔ１だけ前の時刻でコンテンツ要求メッセージを送信した場合、もし２曲目のコンテンツデータに係る処理時間ｔ２（後述）が処理時間ｔ１よりも長くなると、１曲目の再生終了時刻Ｔ１３と同時に２曲目の再生を開始することが出来ず、１曲目と２曲目の間に無音時間が発生してしまう。αとは、このような不具合を防ぐために要求時刻Ｔ１算出の際に付加される時間である。なお、αは、１曲目のデコード完了時刻Ｔ１２より要求時刻Ｔ１が後になるように設定されるのが好ましい。これは、次の曲の要求メッセージを送信してから次の曲が始まるまでの時間が長いと、その間にユーザが違った曲を選択してしまう可能性があり、この場合、要求通りの曲を選択できず、誤作動を起こす可能性があるためである。従ってαはできるだけ短い時間が好ましい。また、要求時刻Ｔ１を算出する際、再生終了時刻を算出しなくてもよく、残りの再生時間が（処理時間ｔ１＋α）になった時刻を要求時刻Ｔ１と設定しても良い。
【００２８】
次にＣＰＵ１０２は、計時している時刻を監視し、要求時刻Ｔ１になったか否かを判断する。ＣＰＵ１０２は、計時している時刻が時刻Ｔ１になった場合、再生リストから次に再生する曲名に係るファイル名を再生リストから抽出し、抽出したファイル名を含むコンテンツ要求メッセージを、通信部１０８を制御してサーバ装置２０へ送信する（ステップＳ１２）。それと同時に、ＣＰＵ１０２は、再びコンテンツ要求メッセージを送信した時点からの経過時間の測定を開始する。
【００２９】
この後、サーバ装置２０から２曲目のコンテンツデータの最初のブロックが送信される（ステップＳ１３）。ＣＰＵ１０２は、送信されたコンテンツデータの最初のブロックのデコードが完了すると、経過時間の測定を終了し、コンテンツ要求メッセージを送信した時点（要求時刻Ｔ１）からコンテンツデータの最初のブロックのデコードが完了した時点までの処理時間ｔ２をＲＡＭ１０４に記憶させる（ステップＳ１４）。
この後、引き続きサーバ装置２０から順次送信されるコンテンツデータは、ＲＡＭ１０４に記憶される。ＣＰＵ１０２は、ＲＡＭ１０４に記憶されたデータをデコードし、デコードにより得られたデータをＲＡＭ１０４に記憶させる。なお、前述したように、処理時間ｔ１＋α＞処理時間ｔ２となるようにαが決められているので、図７に示すように、２曲目のコンテンツデータの１ブロック目のデコードが終了する時刻は、１曲目の再生終了時刻Ｔ１３より前となる。
【００３０】
計時している時刻が１曲目の再生終了時刻Ｔ１３になると、既に２曲目のコンテンツデータをデコードして得たデータがＲＡＭ１０４に記憶されているため、ＣＰＵ１０２は、ＲＡＭ１０４に記憶されている２曲目のデータを再生部１０５へ供給する。再生部１０５においては、１曲目の再生が終了すると直ぐに２曲目の再生が開始されることとなるため（２曲目の再生開始時刻Ｔ２１）、先に再生された曲と次に再生される曲との間で無音期間が発生せず、楽曲を続けて再生することとなる。
【００３１】
ＣＰＵ１０２は、サーバ装置２０から順次送信されるデータをＲＡＭ１０４に記憶させ、２曲目についても、コンテンツデータの最後のブロックを受信したか否か判断する。ＣＰＵ１０２は、コンテンツデータの最後のブロックを受信したと判断すると、１曲目と同様に２曲目の再生終了時刻Ｔ２３を算出する（ステップＳ１５）。また、ＣＰＵ１０２は、次に再生する３曲目のコンテンツデータについて、コンテンツ要求メッセージを送信する要求時刻Ｔ２を算出する（ステップＳ１６）。
【００３２】
ここで、ＣＰＵ１０２は、再生中のコンテンツデータについて測定した処理時間（ステップＳ１４で記憶した処理時間）が、一つ前に再生したコンテンツデータについて測定した処理時間（ステップＳ９で記憶した経過時間）以上である場合、即ち、ここでは、２曲目のコンテンツデータについての処理時間ｔ２が、１曲目のコンテンツデータについての処理時間ｔ１以上である場合には、２曲目の再生終了時刻Ｔ２３より（処理時間ｔ２＋α）の分だけ前の時刻を３曲目の要求時刻Ｔ２とする。一方、ＣＰＵ１０２は、再生中のコンテンツデータについての処理時間ｔ２が、一つ前に再生したコンテンツデータについての処理時間ｔ１より短い場合、（１曲目の処理時間ｔ１＋２曲目の処理時間ｔ２）／２の演算結果にαを加算した時間を算出し、２曲目再生終了時刻Ｔ２３より算出した時間の分だけ前の時刻を３曲目の要求時刻Ｔ２とする。
【００３３】
この後、２曲目のコンテンツデータを取得した時と同様に、ＣＰＵ１０２は、計時している時刻が要求時刻Ｔ２になると、再生リストから次に再生する曲名に係るファイル名を抽出し、抽出したファイル名を含むコンテンツ要求メッセージを、通信部１０８を制御してサーバ装置２０へ送信する（ステップＳ１７）。ＣＰＵ１０２は、サーバ装置２０からコンテンツデータが送信されると（ステップＳ１８）、サーバ装置２０から送信されるデータをデコードし、デコードにより得られたデータをＲＡＭ１０４に記憶させる。
【００３４】
この後、計時している時刻が２曲目の再生終了時刻Ｔ２３になると、既に３曲目のコンテンツデータをデコードして得たデータがＲＡＭ１０４に記憶されているため、ＣＰＵ１０２は、ＲＡＭ１０４に記憶されている３曲目のデータを再生部１０５へ供給する。ここで、２曲目の再生が終了すると直ぐに３曲目のデータが再生部１０５に供給される。再生部１０５においては、２曲目の再生が終了すると直ぐに３曲目の再生が開始されることとなるため、ここでも先に再生された曲と次に再生される曲との間で無音期間が発生せず、楽曲を続けて再生することとなる。このように各曲の取得の際に処理時間を計測することで、ネットワーク環境の変化やサーバ毎の処理速度の違いに対応することができる。
【００３５】
［変形例］
以上、本発明の実施形態について説明したが、本発明は上述した実施形態に限定されることなく、他の様々な形態で実施可能である。例えば、上述の実施形態を以下のように変形して本発明を実施してもよい。なお、上述した実施形態及び以下の変形例は、各々を組み合わせてもよい。
【００３６】
上述した実施形態においては、再生中のコンテンツデータについての処理時間が、一つ前に再生したコンテンツデータについての処理時間より短い場合であっても、再生中のコンテンツデータについての処理時間＋αを算出し、再生中の曲の再生終了時刻Ｔより算出した時間の分だけ前の時刻を次の曲の要求時刻としてもよい。また、上述した実施形態においては、要求メッセージを送信する毎に測定した処理時間を全て記憶する構成としてもよい。また、この記憶した全ての処理時間の平均時間にαを加算して要求時刻を算出する構成としてもよい。また、この平均時間を算出する場合には、順次記憶した処理時間の全ての平均を算出するのではなく、処理時間の長い順に予め定められた個数の処理時間を抽出し、抽出した処理時間の平均を算出するようにしてもよい。測定した順番で最も新しいものからｎ個（ｎの値は設計時に設定）までの処理時間を抽出し、抽出した処理時間の平均を算出するようにしてもよい。
【００３７】
上述した実施形態においては、リストＬにおいてファイル名が記述されているが、コンテンツデータを一意に識別できる情報であれば、ファイル名でなくてもよい。例えば、コンテンツデータを一意に識別する識別子を生成し、生成した識別子をリストＬに記述してもよい。この構成の場合、端末装置１０がコンテンツ要求メッセージを送信する際には、識別子がサーバ装置２０へ送信され、サーバ装置２０は、送信された識別子で特定されるコンテンツデータを端末装置１０へ送信する。
【００３８】
上述した実施形態では、コンテンツデータは楽曲を表すデータとなっていたが、コンテンツデータは、楽曲を表すデータに限定されるものではなく、動画像を表すものや、動画像と楽曲の両方を含むものであってもよい。また、コンテンツデータのフォーマットはＭＰ３に限定されるものではなく、他のフォーマットであってもよい。また、上述した実施形態では、通信回線３０は、ＬＡＮとなっていたが、ＬＡＮに限定されるものではなくＷＡＮ（Wide Area Network）であってもよい。
【００３９】
上述した端末装置１０に記憶されている制御プログラムは、磁気記録媒体（磁気テープ、磁気ディスク（ＨＤＤ（Hard Disk Drive）、ＦＤ（Flexible Disk））など）、光記録媒体（光ディスク（ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk））など）、光磁気記録媒体、半導体メモリなどのコンピュータ読取り可能な記録媒体に記憶した状態で提供し、端末装置１０にインストールしてもよい。また、通信回線３０を介して制御プログラムをダウンロードして端末装置１０にインストールしてもよい。
【符号の説明】
【００４０】
１０…端末装置、２０…サーバ装置、３０…通信回線、１０１…バス、１０２…ＣＰＵ、１０３…ＲＯＭ、１０４…ＲＡＭ、１０５…再生部、１０６…操作部、１０７…表示部、１０８…通信部、２０１…バス、２０２…ＣＰＵ、２０３…ＲＯＭ、２０４…ＲＡＭ、２０６…操作部、２０７…表示部、２０８…通信部
【技術分野】
【０００１】
本発明は、通信回線を介してコンテンツを取得する技術に関する。
【背景技術】
【０００２】
音声及び映像を含むコンテンツをサーバ装置からクライアントへネットワークを介して送信するシステムとして、特許文献１に開示されたコンテンツ配信システムがある。このシステムにおいては、複数のコンテンツの配信要求がクライアントからサーバへ送信される。サーバは、配信要求を受け取ると、コンテンツをストリーミング形式で送信する。クライアントは、送信されたコンテンツをバッファに蓄積し、蓄積順に再生する。なお、クライアントは、バッファの残量を監視し、この残量を定期的にサーバへ通知する。サーバは、クライアントから通知される残量に基づいてコンテンツの送信速度を制御する。サーバは、最初のコンテンツを送信し終えると次のコンテンツの送信を開始する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−３１３９４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、特許文献１のシステムにおいては、コンテンツの送信開始のタイミングをサーバが主体で管理し、決定している。このシステムにおいてクライアントが複数あり、複数のクライアントから異なるグループの配信要求を受ける場合、サーバは、クライアント毎にコンテンツの送信タイミングを監視することになり、サーバに負荷が掛かることとなる。サーバに掛かる負荷を減らす方法としては、クライアントからの要求があってからコンテンツの送信を開始する方法がある。この方法によれば、サーバは要求があってからコンテンツを送信すればよいので、クライアント毎にコンテンツの送信タイミングを監視する必要がなく、負荷が減ることとなる。しかしながら、コンテンツを連続して再生する場合、再生中のコンテンツの再生が終了してから次のコンテンツを要求すると、コンテンツがクライアントに届くまでに時間がかかるため、再生中のコンテンツの再生が終了してから次のコンテンツの再生が開始されるまでに無音期間が生じることとなる。例えば、コンテンツがライブ演奏のアルバムやクラシック音楽のアルバムの曲であり、これらのアルバムの曲を連続して再生しようとする場合、これらのアルバムでは曲と曲との合間でも音が発生しているため、このように無音期間が発生すると不自然さを感じてしまうこととなる。
【０００５】
本発明は、上述した背景の下になされたものであり、複数のコンテンツを順番に再生する際に、切れ目なくコンテンツが再生されるようにすることを目的とする。
【課題を解決するための手段】
【０００６】
上述した課題と解決するため、本発明は、コンテンツを識別する識別子を含み当該コンテンツを要求する要求メッセージをサーバ装置へ送信する送信手段と、前記要求メッセージに応じて前記サーバ装置からストリーミング形式で順次送信されるエンコードされた複数ブロックのコンテンツデータを受信する受信手段と、前記受信手段で受信されたコンテンツデータをデコードして前記コンテンツを再生する再生手段と、前記要求メッセージを送信した時点から当該要求メッセージに応じて送信されるコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの処理時間を測定する測定手段と、前記要求メッセージで要求したコンテンツの再生終了時刻から少なくとも前記処理時間分より前の時刻において、前記再生手段で再生中のコンテンツの次に再生するコンテンツを要求する要求メッセージを前記送信手段から前記サーバ装置へ送信させる制御手段とを有する端末装置を提供する。
【０００７】
本発明においては、前記制御手段は、前記再生終了時刻から少なくとも前記処理時間分より前の時刻であり、且つ前記コンテンツデータのデコードがすべて完了した時刻より後の時刻において、前記要求メッセージを前記送信手段から前記サーバ装置へ送信させる構成であってもよい。
また、本発明においては、前記制御手段は、前記再生手段で再生中のコンテンツの要求メッセージを送信した時点から、当該要求メッセージに応じて送信されたコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの第２処理時間が、前記再生手段で再生中のコンテンツの一つ前に再生したコンテンツの要求メッセージを送信した時点から、当該要求メッセージに応じて送信されたコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの第１処理時間以上である場合、前記第２処理時間を前記処理時間とする構成であってもよい。
【０００８】
また、本発明においては、前記制御手段は、前記再生手段で再生中のコンテンツの要求メッセージを送信した時点から、当該要求メッセージに応じて送信されたコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの第２処理時間が、前記再生手段で再生中のコンテンツの一つ前に再生したコンテンツの要求メッセージを送信した時点から、当該要求メッセージに応じて送信されたコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの第１処理時間より短い場合、前記第２処理時間と前記第１処理時間の平均時間を前記処理時間とする構成であってもよい。
【発明の効果】
【０００９】
本発明によれば、複数のコンテンツを順番に再生する際に、切れ目なくコンテンツが再生される。
【図面の簡単な説明】
【００１０】
【図１】本発明の一実施形態に係るシステムの全体構成を示した図。
【図２】サーバ装置２０のハードウェア構成を示したブロック図。
【図３】サーバ装置２０が記憶するリストＬの内容を示した図。
【図４】端末装置１０のハードウェア構成を示したブロック図。
【図５】実施形態の動作を説明するためのシーケンス図。
【図６】端末装置１０が生成する再生リストの内容を示した図。
【図７】コンテンツデータの取得開始のタイミングを説明するための図。
【発明を実施するための形態】
【００１１】
［実施形態］
図１は、本発明の実施形態に係るシステムの全体構成を示した図である。図１に示したように、本システムにおいては、通信回線３０に端末装置１０とサーバ装置２０が接続される。なお、本実施形態においては、通信回線３０は有線ＬＡＮ（Local Area Network）となっているが、通信回線３０を無線ＬＡＮとし、無線通信により端末装置１０とサーバ装置２０が通信を行う構成であってもよい。
サーバ装置２０は、クライアントサーバシステムにおけるサーバとして機能する装置である。サーバ装置２０は、楽曲を表すコンテンツデータを記憶している。サーバ装置２０は、コンテンツデータをストリーミング形式で端末装置１０へ送信する。なお、本実施形態においては、コンテンツデータのフォーマットは、ＭＰ３（MPEG Audio Layer-3）となっている。
端末装置１０は、サーバ装置２０からコンテンツデータを取得し、取得したコンテンツデータを再生する装置である。例えば、サーバ装置２０を宅内のリビングルームに配置し、端末装置１０を宅内の各部屋に配置すれば、各部屋でコンテンツデータを再生して楽曲を聞くことができる。なお、本システムにおいては、サーバ装置２０は、複数の端末装置１０と通信を行うことが可能であるが、図面が繁雑になるのを防ぐため図面においては一つの端末装置１０を図示している。
【００１２】
（サーバ装置２０の構成）
図２は、サーバ装置２０のハードウェア構成を示したブロック図である。図２に示したように、サーバ装置２０の各部はバス２０１に接続されており、バス２０１を介して各部間でデータのやり取りを行う。
【００１３】
通信部２０８は、通信回線３０を介して通信を行う通信インターフェースとして機能し、他の装置とデータ通信を行う。表示部２０７は、液晶ディスプレイを備えており、サーバ装置２０を操作するための各種メニュー画面などを表示する。操作部２０６は、複数のボタンを備えている。サーバ装置２０の操作者によりボタンが操作されると、操作されたボタン応じてＣＰＵ（Central Processing Unit）２０２が各種処理を行う。
【００１４】
記憶部２０５は、ハードディスク装置を備えており、クライアントサーバシステムにおけるサーバの機能を実現するサーバプログラムを記憶している。また、記憶部２０５は、複数のコンテンツデータを記憶している。また、記憶部２０５は、コンテンツデータのリストＬを記憶している。図３は、コンテンツデータのリストＬの一例を示した図である。このリストＬの「ファイル名」の列においては、記憶部２０５に記憶されているコンテンツデータのファイル名が記述されている。また、リストＬの「曲名」の列においては、同じ行にあるファイル名のコンテンツデータが表す楽曲の曲名が記述されている。また、「演奏者名・歌手名」の列においては、同じ行にあるファイル名で特定されるコンテンツデータが表す楽曲の演奏者名または歌手名が記述されている。また、「データサイズ」の列には、同じ行にあるファイル名で特定されるコンテンツデータのサイズが記述されている。
【００１５】
ＲＯＭ（Read Only Memory）２０３は、初期制御プログラムを記憶している。サーバ装置２０の電源が入れられると、ＣＰＵ２０２はＲＯＭ２０３から初期制御プログラムを読み出して起動する。ＣＰＵ２０２により初期制御プログラムが起動されると、記憶部２０５に記憶されているサーバプログラムがＲＡＭ（Random Access Memory）２０４を利用して実行され、記憶部２０５を制御する機能や通信回線３０を介した通信を行う通信機能、コンテンツデータを端末装置１０へ送信する機能等、コンピュータ装置の機能及びクライアントサーバシステムにおけるサーバの機能が実現する。
【００１６】
（端末装置１０の構成）
図４は、端末装置１０のハードウェア構成を示したブロック図である。通信部１０８は、通信回線３０を介して通信を行う通信インターフェースとして機能し、他の装置とデータ通信を行う。操作部１０６は、端末装置１０を操作するための複数のボタンを備えている。端末装置１０の操作者によりボタンが操作されると、操作されたボタンに応じてＣＰＵ１０２が各種処理を行う。表示部１０７は、液晶ディスプレイを備えており、端末装置１０を操作するための各種メニュー画面や各種メッセージなどを表示する。再生部１０５は、スピーカ（図示略）を有している。再生部１０５は、コンテンツデータをエンコードすることによって得られたデータを受け取り、受け取ったデータから楽曲のアナログ信号を生成し、生成したアナログ信号をスピーカへ出力する。
【００１７】
ＲＯＭ１０３は、制御プログラムを記憶している。端末装置１０の電源が入れられると、ＣＰＵ１０２はＲＯＭ１０３から制御プログラムを読み出して実行する。ＣＰＵ１０２により制御プログラムが実行されると、通信回線３０を介した通信を行う通信機能、コンテンツデータをサーバ装置２０から取得する機能、時刻や時間を計るタイマー機能、取得したコンテンツデータをデコードする機能等、コンピュータ装置の機能及びクライアントサーバシステムにおけるクライアントの機能が実現する。
【００１８】
（動作例）
図５は、本実施形態の動作を説明するためのシーケンス図である。本実施形態に係るシステムの動作例について図５を用いて説明する。なお、以下の説明においては、まず端末装置１０で再生するコンテンツデータを端末装置１０において選択する動作について説明し、次に、端末装置１０で選択したコンテンツデータを端末装置１０がサーバ装置２０から取得して再生する動作について説明する。
【００１９】
（コンテンツデータを選択する時の動作）
まず、端末装置１０のユーザが、操作部１０６を操作してサーバ装置２０からリストＬの取得を指示する操作を行うと、ＣＰＵ１０２は、通信部１０８を制御し、リストＬを要求するリスト要求メッセージをサーバ装置２０へ送信する（ステップＳ１）。このリスト要求メッセージは、通信回線３０を介してサーバ装置２０へ送られ、通信部２０８で受信される。ＣＰＵ２０２は、リスト要求メッセージが通信部２０８で受信されると、記憶部２０５に記憶されているリストＬを表すデータを、通信部２０８を制御して端末装置１０へ送信する（ステップＳ２）。
【００２０】
このデータは、通信回線３０を介して端末装置１０へ送られ、通信部１０８で受信される。ＣＰＵ１０２は、リストＬを表すデータが通信部１０８で受信されると、受信したデータに基づいて表示部１０７を制御し、リストＬの曲名と演奏者名・歌手名の内容を表示部１０７に表示させる（ステップＳ３）。これにより、端末装置１０のユーザは、サーバ装置２０に記憶されているコンテンツデータの曲名を知ることができる。
【００２１】
次に、表示された曲名の中から再生する曲の曲名を選択する操作が端末装置１０において行われると、選択された曲名のリストが生成されてＲＡＭ１０４に記憶される（ステップＳ４）。例えば、再生する曲として「sample-1」、「sample-2」、「sample-4」が選択された場合、選択された曲名、選択された曲名に係るコンテンツデータのファイル名及び選択された曲に係るコンテンツデータのデータサイズがリストＬから抽出され、抽出されたファイル名、曲名及びデータサイズを対応付けた再生リスト（図６参照）がＲＡＭ１０４に記憶される。なお、再生リストにおいては、曲名が１行目から並べられている。曲名は、曲を再生する時の順番で並べられており、曲を再生する際には１行目の曲から順番に再生が行われる。
【００２２】
（コンテンツデータを取得して再生する時の動作）
次に、ユーザが選択した曲を再生する時の動作について図７を参照しながら説明する。ＲＡＭ１０４に記憶された再生リストの曲名を表示部１０７に表示させる操作が操作部１０６において行われると、ＣＰＵ１０２は、ＲＡＭ１０４に記憶された再生リストにある曲名を表示部１０７に表示させる（ステップＳ５）。次に、表示された曲名のコンテンツデータの再生を指示する操作が操作部１０６において行われると（ステップＳ６）、ＣＰＵ１０２は、再生リストにある曲名のコンテンツデータをサーバ装置２０から取得する。
【００２３】
例えば、再生リストの内容が図６に示した内容である場合、まずＣＰＵ１０２は、再生リストの１行目のファイル名を抽出する。次にＣＰＵ１０２は、抽出したファイル名を含みコンテンツを要求するコンテンツ要求メッセージを、通信部１０８を制御してサーバ装置２０へ送信する（ステップＳ７）。なお、ここでＣＰＵ１０２は、コンテンツ要求メッセージを送信した時点（要求時刻Ｔ０）からの経過時間の測定を開始する。
【００２４】
ファイル名を含むコンテンツ要求メッセージが通信部２０８で受信されると、ＣＰＵ２０２は、受信したファイル名のコンテンツデータを記憶部２０５から読み出し、読み出したコンテンツデータを複数のブロックに分け、通信部２０８を制御してストリーミング形式で端末装置１０へ送信する（ステップＳ８）。ＣＰＵ１０２は、通信部１０８においてコンテンツデータの最初のブロックが受信されると、受信したコンテンツデータのデコードを開始する。ＣＰＵ１０２は、所定期間のデコードが終了すると、時刻Ｔ０からの経過時間の測定を終了し、コンテンツ要求メッセージを送信した要求時刻Ｔ０からコンテンツデータの所定期間のデコードを完了した時点までの処理時間ｔ１をＲＡＭ１０４に記憶させる（ステップＳ９）。なお、ここでの所定期間とは、１ブロック分のコンテンツデータのデコードに要する期間であり、約１００ｍｓ〜１ｓほどである。
この後、引き続きサーバ装置２０からはコンテンツデータがストリーミング形式で送信され、順次ＲＡＭ１０４に記憶されると同時にデコードされる。ＣＰＵ１０２は、デコードにより得たデータを順次再生部１０５へ供給し、再生部１０５は、供給されたデータから楽曲のアナログ信号を生成し、生成したアナログ信号をスピーカへ出力する（１曲目の再生時刻Ｔ１１）。なお、再生部１０５に供給されたデータはＲＡＭ１０４から消去される。
【００２５】
ＣＰＵ１０２は、サーバ装置２０から順次送信されるデータをＲＡＭ１０４に記憶させ、ストリーミング形式で送信されるコンテンツデータの最後のブロックを受信したか否か判断する。なお、コンテンツデータの最後のブロックを受信したか否かは、最初のブロックを受信してからＲＡＭ１０４に記憶させたデータのサイズの合計が、再生リストのデータサイズの欄に記述されているデータサイズに達したか否かで判断することができる。例えば、「sample-1」という曲名のコンテンツデータの場合、ＣＰＵ１０２は、最初のブロックを受信してからＲＡＭ１０４に記憶させたデータのサイズの合計が５ＭＢｙｔｅになると、コンテンツデータの最後のブロックを受信したと判断する。ＣＰＵ１０２は、コンテンツデータの最後のブロックを受信したと判断すると、受信した全てのコンテンツデータをデコードしたか否か判断する。ＣＰＵ１０２は、全てデコードしたと判断すると、コンテンツデータのデコード処理を終了する。
【００２６】
ＣＰＵ１０２は、デコードが終了すると、受信した最後のブロックの再生終了時刻Ｔ１３を算出する（ステップＳ１０）。なお、データを再生し終えるまでに掛かる時間は、ＲＡＭ１０４に記憶されているデータ量に比例するため、データの再生終了時刻Ｔ１３は、ＲＡＭ１０４に記憶されているデータ量から算出することができる。例えば、図７に示した１曲目のデコード完了時刻Ｔ１２から最後のブロックが再生完了するまでにｎ秒かかる場合、１曲目のデコード完了時刻Ｔ１２よりｎ秒後の時刻が１曲目の再生終了時刻Ｔ１３となる。
【００２７】
次に、ＣＰＵ１０２は、次に再生するコンテンツデータについて、コンテンツ要求メッセージを送信する要求時刻Ｔ１を、ＲＡＭ１０４に記憶した処理時間ｔ１を用いて算出する（ステップＳ１１）。具体的には、ＣＰＵ１０２は、１曲目の再生終了時刻Ｔ１３より処理時間ｔ１＋αだけ前の時刻を要求時刻Ｔ１として算出する。αとは、予め実験的に求められた予備的な時間である。具体的には、１曲目の再生終了時刻Ｔ１３より処理時間ｔ１だけ前の時刻でコンテンツ要求メッセージを送信した場合、もし２曲目のコンテンツデータに係る処理時間ｔ２（後述）が処理時間ｔ１よりも長くなると、１曲目の再生終了時刻Ｔ１３と同時に２曲目の再生を開始することが出来ず、１曲目と２曲目の間に無音時間が発生してしまう。αとは、このような不具合を防ぐために要求時刻Ｔ１算出の際に付加される時間である。なお、αは、１曲目のデコード完了時刻Ｔ１２より要求時刻Ｔ１が後になるように設定されるのが好ましい。これは、次の曲の要求メッセージを送信してから次の曲が始まるまでの時間が長いと、その間にユーザが違った曲を選択してしまう可能性があり、この場合、要求通りの曲を選択できず、誤作動を起こす可能性があるためである。従ってαはできるだけ短い時間が好ましい。また、要求時刻Ｔ１を算出する際、再生終了時刻を算出しなくてもよく、残りの再生時間が（処理時間ｔ１＋α）になった時刻を要求時刻Ｔ１と設定しても良い。
【００２８】
次にＣＰＵ１０２は、計時している時刻を監視し、要求時刻Ｔ１になったか否かを判断する。ＣＰＵ１０２は、計時している時刻が時刻Ｔ１になった場合、再生リストから次に再生する曲名に係るファイル名を再生リストから抽出し、抽出したファイル名を含むコンテンツ要求メッセージを、通信部１０８を制御してサーバ装置２０へ送信する（ステップＳ１２）。それと同時に、ＣＰＵ１０２は、再びコンテンツ要求メッセージを送信した時点からの経過時間の測定を開始する。
【００２９】
この後、サーバ装置２０から２曲目のコンテンツデータの最初のブロックが送信される（ステップＳ１３）。ＣＰＵ１０２は、送信されたコンテンツデータの最初のブロックのデコードが完了すると、経過時間の測定を終了し、コンテンツ要求メッセージを送信した時点（要求時刻Ｔ１）からコンテンツデータの最初のブロックのデコードが完了した時点までの処理時間ｔ２をＲＡＭ１０４に記憶させる（ステップＳ１４）。
この後、引き続きサーバ装置２０から順次送信されるコンテンツデータは、ＲＡＭ１０４に記憶される。ＣＰＵ１０２は、ＲＡＭ１０４に記憶されたデータをデコードし、デコードにより得られたデータをＲＡＭ１０４に記憶させる。なお、前述したように、処理時間ｔ１＋α＞処理時間ｔ２となるようにαが決められているので、図７に示すように、２曲目のコンテンツデータの１ブロック目のデコードが終了する時刻は、１曲目の再生終了時刻Ｔ１３より前となる。
【００３０】
計時している時刻が１曲目の再生終了時刻Ｔ１３になると、既に２曲目のコンテンツデータをデコードして得たデータがＲＡＭ１０４に記憶されているため、ＣＰＵ１０２は、ＲＡＭ１０４に記憶されている２曲目のデータを再生部１０５へ供給する。再生部１０５においては、１曲目の再生が終了すると直ぐに２曲目の再生が開始されることとなるため（２曲目の再生開始時刻Ｔ２１）、先に再生された曲と次に再生される曲との間で無音期間が発生せず、楽曲を続けて再生することとなる。
【００３１】
ＣＰＵ１０２は、サーバ装置２０から順次送信されるデータをＲＡＭ１０４に記憶させ、２曲目についても、コンテンツデータの最後のブロックを受信したか否か判断する。ＣＰＵ１０２は、コンテンツデータの最後のブロックを受信したと判断すると、１曲目と同様に２曲目の再生終了時刻Ｔ２３を算出する（ステップＳ１５）。また、ＣＰＵ１０２は、次に再生する３曲目のコンテンツデータについて、コンテンツ要求メッセージを送信する要求時刻Ｔ２を算出する（ステップＳ１６）。
【００３２】
ここで、ＣＰＵ１０２は、再生中のコンテンツデータについて測定した処理時間（ステップＳ１４で記憶した処理時間）が、一つ前に再生したコンテンツデータについて測定した処理時間（ステップＳ９で記憶した経過時間）以上である場合、即ち、ここでは、２曲目のコンテンツデータについての処理時間ｔ２が、１曲目のコンテンツデータについての処理時間ｔ１以上である場合には、２曲目の再生終了時刻Ｔ２３より（処理時間ｔ２＋α）の分だけ前の時刻を３曲目の要求時刻Ｔ２とする。一方、ＣＰＵ１０２は、再生中のコンテンツデータについての処理時間ｔ２が、一つ前に再生したコンテンツデータについての処理時間ｔ１より短い場合、（１曲目の処理時間ｔ１＋２曲目の処理時間ｔ２）／２の演算結果にαを加算した時間を算出し、２曲目再生終了時刻Ｔ２３より算出した時間の分だけ前の時刻を３曲目の要求時刻Ｔ２とする。
【００３３】
この後、２曲目のコンテンツデータを取得した時と同様に、ＣＰＵ１０２は、計時している時刻が要求時刻Ｔ２になると、再生リストから次に再生する曲名に係るファイル名を抽出し、抽出したファイル名を含むコンテンツ要求メッセージを、通信部１０８を制御してサーバ装置２０へ送信する（ステップＳ１７）。ＣＰＵ１０２は、サーバ装置２０からコンテンツデータが送信されると（ステップＳ１８）、サーバ装置２０から送信されるデータをデコードし、デコードにより得られたデータをＲＡＭ１０４に記憶させる。
【００３４】
この後、計時している時刻が２曲目の再生終了時刻Ｔ２３になると、既に３曲目のコンテンツデータをデコードして得たデータがＲＡＭ１０４に記憶されているため、ＣＰＵ１０２は、ＲＡＭ１０４に記憶されている３曲目のデータを再生部１０５へ供給する。ここで、２曲目の再生が終了すると直ぐに３曲目のデータが再生部１０５に供給される。再生部１０５においては、２曲目の再生が終了すると直ぐに３曲目の再生が開始されることとなるため、ここでも先に再生された曲と次に再生される曲との間で無音期間が発生せず、楽曲を続けて再生することとなる。このように各曲の取得の際に処理時間を計測することで、ネットワーク環境の変化やサーバ毎の処理速度の違いに対応することができる。
【００３５】
［変形例］
以上、本発明の実施形態について説明したが、本発明は上述した実施形態に限定されることなく、他の様々な形態で実施可能である。例えば、上述の実施形態を以下のように変形して本発明を実施してもよい。なお、上述した実施形態及び以下の変形例は、各々を組み合わせてもよい。
【００３６】
上述した実施形態においては、再生中のコンテンツデータについての処理時間が、一つ前に再生したコンテンツデータについての処理時間より短い場合であっても、再生中のコンテンツデータについての処理時間＋αを算出し、再生中の曲の再生終了時刻Ｔより算出した時間の分だけ前の時刻を次の曲の要求時刻としてもよい。また、上述した実施形態においては、要求メッセージを送信する毎に測定した処理時間を全て記憶する構成としてもよい。また、この記憶した全ての処理時間の平均時間にαを加算して要求時刻を算出する構成としてもよい。また、この平均時間を算出する場合には、順次記憶した処理時間の全ての平均を算出するのではなく、処理時間の長い順に予め定められた個数の処理時間を抽出し、抽出した処理時間の平均を算出するようにしてもよい。測定した順番で最も新しいものからｎ個（ｎの値は設計時に設定）までの処理時間を抽出し、抽出した処理時間の平均を算出するようにしてもよい。
【００３７】
上述した実施形態においては、リストＬにおいてファイル名が記述されているが、コンテンツデータを一意に識別できる情報であれば、ファイル名でなくてもよい。例えば、コンテンツデータを一意に識別する識別子を生成し、生成した識別子をリストＬに記述してもよい。この構成の場合、端末装置１０がコンテンツ要求メッセージを送信する際には、識別子がサーバ装置２０へ送信され、サーバ装置２０は、送信された識別子で特定されるコンテンツデータを端末装置１０へ送信する。
【００３８】
上述した実施形態では、コンテンツデータは楽曲を表すデータとなっていたが、コンテンツデータは、楽曲を表すデータに限定されるものではなく、動画像を表すものや、動画像と楽曲の両方を含むものであってもよい。また、コンテンツデータのフォーマットはＭＰ３に限定されるものではなく、他のフォーマットであってもよい。また、上述した実施形態では、通信回線３０は、ＬＡＮとなっていたが、ＬＡＮに限定されるものではなくＷＡＮ（Wide Area Network）であってもよい。
【００３９】
上述した端末装置１０に記憶されている制御プログラムは、磁気記録媒体（磁気テープ、磁気ディスク（ＨＤＤ（Hard Disk Drive）、ＦＤ（Flexible Disk））など）、光記録媒体（光ディスク（ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk））など）、光磁気記録媒体、半導体メモリなどのコンピュータ読取り可能な記録媒体に記憶した状態で提供し、端末装置１０にインストールしてもよい。また、通信回線３０を介して制御プログラムをダウンロードして端末装置１０にインストールしてもよい。
【符号の説明】
【００４０】
１０…端末装置、２０…サーバ装置、３０…通信回線、１０１…バス、１０２…ＣＰＵ、１０３…ＲＯＭ、１０４…ＲＡＭ、１０５…再生部、１０６…操作部、１０７…表示部、１０８…通信部、２０１…バス、２０２…ＣＰＵ、２０３…ＲＯＭ、２０４…ＲＡＭ、２０６…操作部、２０７…表示部、２０８…通信部
【特許請求の範囲】
【請求項１】
コンテンツを識別する識別子を含み当該コンテンツを要求する要求メッセージをサーバ装置へ送信する送信手段と、
前記要求メッセージに応じて前記サーバ装置からストリーミング形式で順次送信されるエンコードされた複数ブロックのコンテンツデータを受信する受信手段と、
前記受信手段で受信されたコンテンツデータをデコードして前記コンテンツを再生する再生手段と、
前記要求メッセージを送信した時点から当該要求メッセージに応じて送信されるコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの処理時間を測定する測定手段と、
前記要求メッセージで要求したコンテンツの再生終了時刻から少なくとも前記処理時間分より前の時刻において、前記再生手段で再生中のコンテンツの次に再生するコンテンツを要求する要求メッセージを前記送信手段から前記サーバ装置へ送信させる制御手段と
を有する端末装置。
【請求項２】
前記制御手段は、前記再生終了時刻から少なくとも前記処理時間分より前の時刻であり、且つ前記コンテンツデータのデコードがすべて完了した時刻より後の時刻において、前記要求メッセージを前記送信手段から前記サーバ装置へ送信させること
を特徴とする請求項１に記載の端末装置。
【請求項３】
前記制御手段は、
前記再生手段で再生中のコンテンツの要求メッセージを送信した時点から、当該要求メッセージに応じて送信されたコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの第２処理時間が、前記再生手段で再生中のコンテンツの一つ前に再生したコンテンツの要求メッセージを送信した時点から、当該要求メッセージに応じて送信されたコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの第１処理時間以上である場合、前記第２処理時間を前記処理時間とすること
を特徴とする請求項１に記載の端末装置。
【請求項４】
前記制御手段は、
前記再生手段で再生中のコンテンツの要求メッセージを送信した時点から、当該要求メッセージに応じて送信されたコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの第２処理時間が、前記再生手段で再生中のコンテンツの一つ前に再生したコンテンツの要求メッセージを送信した時点から、当該要求メッセージに応じて送信されたコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの第１処理時間より短い場合、前記第２処理時間と前記第１処理時間の平均時間を前記処理時間とすること
を特徴とする請求項１に記載の端末装置。
【請求項１】
コンテンツを識別する識別子を含み当該コンテンツを要求する要求メッセージをサーバ装置へ送信する送信手段と、
前記要求メッセージに応じて前記サーバ装置からストリーミング形式で順次送信されるエンコードされた複数ブロックのコンテンツデータを受信する受信手段と、
前記受信手段で受信されたコンテンツデータをデコードして前記コンテンツを再生する再生手段と、
前記要求メッセージを送信した時点から当該要求メッセージに応じて送信されるコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの処理時間を測定する測定手段と、
前記要求メッセージで要求したコンテンツの再生終了時刻から少なくとも前記処理時間分より前の時刻において、前記再生手段で再生中のコンテンツの次に再生するコンテンツを要求する要求メッセージを前記送信手段から前記サーバ装置へ送信させる制御手段と
を有する端末装置。
【請求項２】
前記制御手段は、前記再生終了時刻から少なくとも前記処理時間分より前の時刻であり、且つ前記コンテンツデータのデコードがすべて完了した時刻より後の時刻において、前記要求メッセージを前記送信手段から前記サーバ装置へ送信させること
を特徴とする請求項１に記載の端末装置。
【請求項３】
前記制御手段は、
前記再生手段で再生中のコンテンツの要求メッセージを送信した時点から、当該要求メッセージに応じて送信されたコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの第２処理時間が、前記再生手段で再生中のコンテンツの一つ前に再生したコンテンツの要求メッセージを送信した時点から、当該要求メッセージに応じて送信されたコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの第１処理時間以上である場合、前記第２処理時間を前記処理時間とすること
を特徴とする請求項１に記載の端末装置。
【請求項４】
前記制御手段は、
前記再生手段で再生中のコンテンツの要求メッセージを送信した時点から、当該要求メッセージに応じて送信されたコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの第２処理時間が、前記再生手段で再生中のコンテンツの一つ前に再生したコンテンツの要求メッセージを送信した時点から、当該要求メッセージに応じて送信されたコンテンツデータの受信が開始され、所定期間のコンテンツデータのデコードが終了した時点までの第１処理時間より短い場合、前記第２処理時間と前記第１処理時間の平均時間を前記処理時間とすること
を特徴とする請求項１に記載の端末装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１２−５４７７９（Ｐ２０１２−５４７７９Ａ）
【公開日】平成２４年３月１５日（２０１２．３．１５）
【国際特許分類】
【出願番号】特願２０１０−１９５９８７（Ｐ２０１０−１９５９８７）
【出願日】平成２２年９月１日（２０１０．９．１）
【出願人】（０００００４０７５）ヤマハ株式会社 (5,930)
【Ｆターム（参考）】
【公開日】平成２４年３月１５日（２０１２．３．１５）
【国際特許分類】
【出願日】平成２２年９月１日（２０１０．９．１）
【出願人】（０００００４０７５）ヤマハ株式会社 (5,930)
【Ｆターム（参考）】
[ Back to top ]