JP2003241769A

JP2003241769A - コンテンツ配信システム、コンテンツ配信方法、並びに、コンテンツ配信システムで用いるコンテンツ配信サーバおよび再生機

Info

Publication number: JP2003241769A
Application number: JP2002041727A
Authority: JP
Inventors: Yoshio Omori; 良夫大森
Original assignee: Denon Ltd
Current assignee: Denon Ltd
Priority date: 2002-02-19
Filing date: 2002-02-19
Publication date: 2003-08-29

Abstract

(57)【要約】【課題】ネットワークに接続された小容量のメモリを搭
載した複数のコンテンツ再生機に対し、コンテンツ配信
サーバから、コンテンツデータを、円滑に配信できるよ
うにする。【解決手段】コンテンツ配信サーバに各再生機のメモリ
内の未再生コンテンツを監視する手段と、送信済みコン
テンツデータの終了ポイントを記憶する手段とを設け、
コンテンツ配信サーバは、監視結果に基づき、次にコン
テンツを配信する再生機を決定し、終了ポイント以降の
コンテンツデータを送信する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワークを介
してコンテンツデータを配信する技術に関し、特に、複
数の再生機がそれぞれ要求するコンテンツデータを配信
するのに好適な技術に関する。

【０００２】

【従来の技術】例えば通信カラオケシステムなどの、コ
ンテンツ配信サーバに複数のコンテンツ再生機が接続さ
れて構成されたコンテンツ配信システムが、カラオケボ
ックスや結婚披露宴式場などで利用されている。

【０００３】このようなコンテンツ配信システムにおい
て、コンテンツ再生機は、ユーザの楽曲の指定を受け付
けると、コンテンツ配信サーバに、指定された楽曲デー
タの配信要求を行う。コンテンツ配信サーバは、コンテ
ンツ再生機から配信要求された楽曲のデータを、この配
信要求元のコンテンツ再生機に配信する。

【０００４】

【発明が解決しようとする課題】従来のコンテンツ配信
システムにおいて、コンテンツ再生機からコンテンツ配
信サーバへ送信される配信要求が１曲以上の楽曲単位で
あるため、コンテンツ配信サーバは、楽曲単位でデータ
をコンテンツ再生機に配信している。このため、コンテ
ンツ再生機には、最低１曲以上の楽曲データを記憶する
ための記憶装置が要求される。

【０００５】ところが、電源を落とした場合にデータが
消去される揮発性メモリを、楽曲１曲分（例えば５分の
オーディオデータ）全てを記憶することが可能な容量分
搭載すると、コストが嵩む。

【０００６】また、上述したように、従来のコンテンツ
配信システムでは、コンテンツ配信サーバは、楽曲単位
でデータをコンテンツ再生機に配信しているので、複数
のコンテンツ再生機から長時間の楽曲の配信要求が短期
間に集中した場合、コンテンツ再生機の中には、一時的
に、コンテンツ配信サーバからの送信を長時間待たなけ
ればならないというような事態が発生することもある。

【０００７】本発明は、上記事情に鑑みてなされたもの
であり、本発明の目的は、小容量（例えば楽曲１曲分を
全て記憶することができない容量）のメモリを搭載した
複数のコンテンツ再生機に対して、コンテンツ配信サー
バからコンテンツデータを、円滑に配信できるようにす
ることにある。

【０００８】

【課題を解決するための手段】上記課題を解決するため
に、本発明では、複数のコンテンツ再生機各々に、コン
テンツ配信サーバにコンテンツデータの配信要求を送信
する配信要求手段と、前記コンテンツ配信サーバより配
信されたコンテンツデータを一時的に蓄積するメモリ
と、を設けている。ここで、メモリは、例えば楽曲１曲
分を全て記憶することができない小容量のものでもかま
わない。

【０００９】また、本発明では、コンテンツ配信サーバ
に、配信要求を登録する配信要求登録手段と、配信要求
の対象となるコンテンツデータを、当該配信要求元の前
記再生機へ配信するコンテンツ配信手段と、前記配信要
求登録手段に配信要求が登録されている前記再生機のう
ち、次にコンテンツデータを配信すべき前記再生機を決
定する配信順序決定手段と、を設けている。

【００１０】ここで、前記配信要求登録手段は、登録さ
れている配信要求毎に、当該配信要求の対象となるコン
テンツデータのうち、当該配信要求元の前記再生機に送
信済みのデータの最後尾ポイントをも登録する。

【００１１】また、前記配信順序決定手段は、前記配信
要求登録手段に配信要求が登録されている前記再生機各
々より、当該再生機に送信済みのデータのうち未再生部
分のデータ量を取得し、取得した前記再生機各々の未再
生部分のデータ量に基づいて、次にコンテンツデータを
配信すべき前記再生機を決定する。

【００１２】そして、前記コンテンツ配信手段は、前記
配信順序決定手段により決定された前記再生機に対し、
前記配信要求登録手段に登録されている当該再生機の配
信要求の対象となるコンテンツデータのうち、当該配信
要求と共に登録されている最後尾ポイントに続く部分の
データを、当該再生機のメモリ容量と未再生部分のデー
タ量とにより定まるデータ量分送信する。

【００１３】以上の構成により、本発明によれば、コン
テンツ再生機のメモリに格納されている未再生部分のデ
ータ残量に基づいて、この未再生分のデータがなくなる
前に、当該コンテンツ再生機に対して、メモリがデータ
で満たされるように、当該コンテンツ再生機が配信を要
求するコンテンツデータの未配信部分のデータを配信す
ることができる。したがって、小容量のメモリを搭載し
た複数のコンテンツ再生機に対して、コンテンツ配信サ
ーバからコンテンツデータを、円滑に配信することがで
きる。

【００１４】

【発明の実施の形態】本発明の実施の形態について、以
下に説明する。なお、本実施の形態においては、配信す
るコンテンツデータをＣＤに録音された楽曲と仮定し、
楽曲再生システムを例にあげ、説明する。もちろん、本
発明を適用したコンテンツ配信・再生システムにおい
て、配信可能なコンテンツデータは、ＣＤに録音された
楽曲に限らない。また、後述する楽曲配信サーバは、コ
ンテンツデータを記憶する大容量記憶装置（例えば、ハ
ードディスクドライブ（ＨＤＤ））を備え、その大容量
記憶装置に記憶されたコンテンツデータを配信するよう
にしてもよい。

【００１５】本実施形態の楽曲再生システムは、結婚式
場のように、同じ楽曲を複数の会場で同じ時間帯に再生
する可能性の高い場所での使用を想定している。本実施
形態の楽曲再生システムは、各会場に配置され楽曲を再
生する複数の再生機と、楽曲を配信するサーバとを備え
る。再生機は、配信された楽曲を一時的に保持するバッ
ファと、バッファに保持された楽曲を再生する機能と、
楽曲を配信するサーバに、リクエストする楽曲名および
楽曲名が複数の場合その再生順からなる楽曲配信要求デ
ータを楽曲配信要求として送信する機能とを有する。そ
して、楽曲を配信するサーバは、各再生機から受けた楽
曲配信要求を登録する機能と、各再生機のバッファ内の
未再生の楽曲データの量（以後、データ残量と呼ぶ）を
モニタする機能と、最もバッファ内のデータ残量が少な
い再生機を次のコンテンツデータ配信再生機と決定する
機能と、その再生機の要求した楽曲データ（圧縮データ
やＭＩＤＩデータに比べて情報量が多いデータ）をＣＤ
から読み出し、その再生機に送信する機能と、送信する
データ量が再生機の空きバッファ量より大きい場合、送
信済みデータの終了ポイントを保持する機能とを有す
る。この構成により、本実施形態の楽曲再生システムに
おいて、楽曲を配信するサーバは複数の再生機に効率よ
く円滑に楽曲データを配信でき、各再生機は、送られて
きた楽曲データをほぼリアルタイムに再生することがで
きる。

【００１６】さらに、楽曲を配信するサーバに、各再生
機がバッファ容量内の全データを再生し切る前に必ず２
回目の配信ができる程度のＣＤ読み出し能力を持たせて
おけば、再生機は音の途切れもなく楽曲データを再生で
きる。

【００１７】このように、本実施形態のコンテンツデー
タ配信システムにおいては、ネットワークに接続された
バッファリングできるデータ量の小さい複数の再生機
に、順序よく効率的にコンテンツ配信サーバからコンテ
ンツデータを配信することができる。

【００１８】また、結婚披露宴のような場では、一旦リ
クエストされた曲が、その順番どおりに再生されないこ
とも多い。各会場においてリクエストされた楽曲の順番
どおりに再生する以外の場合、例えば、現在再生してい
る曲を停止して次曲の再生開始の指示やリクエストされ
ている楽曲以外の再生開始の指示などが割り込みで行わ
れる場合（以下、「例外処理」と呼ぶ）がある。具体的
には、結婚披露宴などでは、歓談中のＢＧＭを停止し
て、新郎・新婦の入場の曲を再生するなどの場合などで
ある。

【００１９】このように配信コンテンツの変更が頻繁に
行われる可能性のある場合、単に順番にコンテンツを再
生機のバッファ容量分送信するシステムでは、突然の変
更に対応することは難しい。例えば、２０台の再生機が
接続され、１５台目の再生機において、ある楽曲を再生
中に、突然、ユーザから別の楽曲の再生開始の指示を受
けた場合（楽曲を配信するサーバが１５台目の再生機に
再生中の楽曲と異なる楽曲データを送信しなければなら
ない場合）、楽曲を配信するサーバは、１台目から順に
楽曲データを送信しているため、１５台目の再生機に楽
曲データを送信するまでに時間がかかり、その会場で
は、所望の曲の再生を待たせてしまうという事態とな
る。

【００２０】本実施形態の楽曲再生システムでは、再生
機は、ユーザから別の楽曲の再生などの指示を受け付け
た場合には、バッファ内に記憶している現在再生中の楽
曲のデータを消去し、楽曲を配信するサーバに、その再
生中の楽曲に関する楽曲配信要求データとその他の既に
登録されている楽曲配信要求データとを消去することな
どを通知する。そして、新たに受け付けた楽曲に関する
楽曲配信要求データを楽曲配信要求として送信する。な
お、例えば、予め複数の楽曲が楽曲配信要求として送信
され、このような状況で再生中止となった楽曲のみを飛
ばして次の楽曲を再生する場合は、再生中止となった楽
曲に関する楽曲配信要求データのみを消去することを、
楽曲を配信するサーバに通知すればよく、再生中止とな
った楽曲以外の既に登録されている楽曲配信要求データ
を消去するとともに改めて楽曲配信要求を送信する必要
はない。

【００２１】これにより、この再生機は、バッファ内の
未再生のデータ量が０になるため、楽曲を配信するサー
バからの次の問い合わせ時に、バッファ内のデータ残量
が最も少ない再生機となる。本実施形態の楽曲再生シス
テムでは、楽曲を配信するサーバが、再生機のバッファ
内の未再生のデータ量をモニタし、最もデータ残量の少
ない再生機を次に配信する再生機とするため、複数の再
生機のうち、例外処理を行った再生機に優先的に楽曲デ
ータが送信される。

【００２２】このように、本実施形態の楽曲再生システ
ムでは、ユーザの任意の指示により、再生機において再
生するコンテンツが変更になった場合でも、再生機は、
ユーザの再生指示の入力の受け付け後、短時間で指示さ
れたコンテンツを再生することができる。

【００２３】以下に、本発明の第一の実施形態の楽曲再
生システムの詳細について、図面を用いて説明する。

【００２４】図１は第一の実施形態の楽曲再生システム
の基本構成を説明するためのブロック図である。本図に
示すように、本実施形態の楽曲再生システムは、楽曲配
信サーバ１０と、複数の再生機２０−１〜２０−ｎ（以
下、これらを総称して単に再生機２０と呼ぶ）と、ネッ
トワーク網（ＬＡＮ）３０とを備え、楽曲配信サーバ１
０は、ネットワーク網３０を介して、複数の再生機２０
と接続している。

【００２５】再生機２０は、ネットワーク網３０と接続
するインタフェースであるＩ／Ｆ部２４０と、楽曲配信
サーバ１０から送信された楽曲データを一時的蓄積する
ためのバッファ部２３０と、送信された楽曲データをア
ナログ信号に変換し、増幅するための、Ｄ／Ａ変換部２
２０と、中央処理装置（ＣＰＵ）によって各機能部の動
作を制御する制御部２１０とを備える。制御部２１０
は、ユーザから受け付けた楽曲配信要求データを楽曲配
信要求として楽曲配信サーバ１０へ送信する配信要求部
２１１を備える。配信要求部２１１は、さらに、楽曲配
信サーバ１０に送信され登録された楽曲配信要求データ
の削除の指示の送信も行う。

【００２６】なお、再生機は、Ｄ／Ａ変換部２２０を介
して図示しない外部スピーカと接続している。また、こ
のバッファ部２３０を構成しているメモリは、データの
再生のための一時蓄積メモリであり、電源を切ればデー
タも消滅してしまう、揮発性の記憶素子で構成されてい
る。

【００２７】更に、図示はしないが、再生機２０には、
ユーザからの楽曲のリクエストを受け付けることを支援
するために楽曲配信サーバ１０が保有している楽曲情報
を表示するモニタなどの出力装置と、ユーザからの楽曲
の選択・登録の入力を受け付けるためのキーボードなど
の入力装置とが接続されている。これらの入力装置およ
び出力装置は、選択・登録を受け付けた楽曲配信要求デ
ータを楽曲配信要求として楽曲配信サーバ１０へ送信す
る指示、楽曲配信サーバ１０から転送された楽曲データ
の再生タイミングの指示、再生中の楽曲データの再生中
止の指示、一旦楽曲配信サーバ１０に送信し登録された
楽曲配信要求データを削除する指示などにも用いられ
る。

【００２８】制御部２１０は、これらの指示を受け付
け、各々、配信要求部２１１による処理に加え、バッフ
ァ部２３０内に格納されている楽曲を再生し、楽曲の再
生を停止すると共にバッファ部２３０内のそのデータを
消去するなどの処理を行う。

【００２９】ここで、再生機２０から楽曲配信要求とし
て楽曲配信サーバ１０へ送信される楽曲配信要求データ
は、前述のように楽曲名と再生順とを備える。再生順
は、１つの楽曲配信要求に含まれる楽曲配信要求データ
で示される楽曲の再生の順番を示すデータであり、一度
に一つの楽曲配信要求データを楽曲配信要求として楽曲
配信サーバ１０に送信する場合は、自動的に１番始めに
再生されることを示すデータが付与され、一度に複数の
楽曲配信要求データをまとめて楽曲配信要求として送信
する場合、つまり、ユーザから受け付けた複数の楽曲の
リクエストをまとめて楽曲配信サーバ１０に送信する場
合は、ユーザによって入力装置を介して指定されたもの
が付与される。再生機２０は、楽曲配信サーバ１０か
ら、楽曲配信サーバ１０が配信可能な楽曲データとして
後述する楽曲情報データベース１４０のデータの提供を
受け、そのデータをユーザに提示することによって、リ
クエストを受け付ける。

【００３０】楽曲配信サーバ１０は、再生機２０とのデ
ータのやりとりを行うインタフェースであるインタフェ
ース部１２０と、配信コンテンツ制御部１１０とを備え
る。配信コンテンツ制御部１１０は、記憶部１１０１と
制御部１１０２とを備え、記憶部１１０１には、後述す
る楽曲情報データベース１４０と、リクエストデータベ
ース１５０と、制御部１１０２の機能を実現するプログ
ラム１３０とを備える。

【００３１】制御部１１０２は、再生機２０からの楽曲
配信要求を記憶部１１０１のデータベースに登録するな
ど記憶部１１０１のデータベースにアクセスし処理を行
う配信要求登録部１８０と、配信要求の対象となる楽曲
データを配信要求元に送信するコンテンツ配信部１６０
と、データベースに楽曲配信要求が登録されている再生
機の中から、それらの再生機のバッファ部２３０のデー
タ残量をモニタすることで、次に楽曲データを配信すべ
き再生機を決定する配信順序決定部１７０とを備える。

【００３２】本実施形態の場合、配信するコンテンツデ
ータがＣＤに録音された楽曲であるため、配信コンテン
ツ制御部１１０は、ＣＰＵとメモリとＣＤチェンジャと
を備える。メモリ内に記憶部１１０１の楽曲情報データ
ベース１４０、リクエストデータベース１５０およびプ
ログラム１３０が格納され、ＣＰＵが記憶部１１０１内
のプログラム１３０を実行することで、上記制御部１１
０２の各機能である配信要求登録部１８０、コンテンツ
配信部１６０、および、配信順序決定部１７０の機能を
実現する。

【００３３】楽曲情報データベース１４０は、ＣＤチェ
ンジャに挿入されているＣＤの位置を示すＣＤチェンジ
ャ識別番号１４０４、ＣＤ識別番号１４０５、トラック
識別番号１４０６と、その楽曲情報であるアーティスト
名１４０２、楽曲名１４０１、再生時間１４０３とを管
理している。図２は、楽曲情報データベース１４０のデ
ータ構造の一例を示す図である。楽曲情報データベース
１４０は、各再生機２０から送信される楽曲名が指定さ
れている楽曲配信要求データから、リクエストデータベ
ース１５０を構築する際に用いられる。また、配信コン
テンツ制御部１１０は、再生機２０からの要求に応じ、
楽曲情報データベース１４０で管理しているデータを各
再生機２０に送信し、リクエストを受け付けることがで
きる環境を各再生機に提供する。もちろん、楽曲情報デ
ータベース１４０に管理されている項目はこれらに限ら
ない。

【００３４】リクエストデータベース１５０は、配信要
求登録部１８０において作成され、楽曲配信要求として
受け付けた各再生機２０からの楽曲配信要求データを構
成する楽曲名と再生順とを、その受け付け時間、楽曲情
報データベース１４０から抽出したデータとともに登録
し、管理するものである。図３はリクエストデータベー
ス１５０のデータ構造の一例を説明するための図であ
る。

【００３５】本図に示すように、リクエストデータベー
ス１５０は、その送信元再生機２０の再生機識別番号１
５０１ごとに、受け付け時間１５０２と再生順番１５０
３とＣＤチェンジャ識別番号１５０４とＣＤ識別番号１
５０５とトラック識別番号１５０６と再生機２０に配信
した際の最終読み出し位置１５０７とを備えるリクエス
トデータ１５１０を管理するものである。

【００３６】リクエストデータベース１５０において、
受け付け時間１５０２は、配信要求登録部１８０が、再
生機２０から送信された楽曲配信要求データを基にリク
エストデータ１５１０を構成し、リクエストデータベー
ス１５０に格納した時間である。受付時間１５０２は、
配信順序決定部１７０が、次のコンテンツデータ配信先
の再生機２０を決定する際に、各再生機２０から取得し
た各々のバッファ部２３０のデータ残量が同じだった場
合に用いられるものである。この場合、楽曲配信要求を
受け付けた時間の早い方を次の配信先の再生機２０と決
定する。

【００３７】再生順番１５０３は、再生機２０から送信
される楽曲配信要求データから取得するものである。

【００３８】ＣＤチェンジャ識別番号１５０４とＣＤ識
別番号１５０５とトラック識別番号１５０６とは楽曲配
信要求データとして受け付けた楽曲名を基に、楽曲情報
データベース１４０の楽曲名１４０１を照合し、そこか
ら取得するものである。

【００３９】最終読み出し位置１５０７には、各リクエ
ストデータ１５１０毎のコンテンツ配信部１６０が前回
送信した楽曲データの最終読み出し位置のアドレスが格
納されている。これは、送信する楽曲のデータがバッフ
ァ部２３０の空き容量以上の場合、一度に全楽曲分のデ
ータを送信することができないため保持されているもの
である。コンテンツ配信部１６０は、次回の送信時にこ
の情報を用い、その楽曲データの送信を開始する位置を
特定し、未送信分を配信する。

【００４０】もちろん、リクエストデータベース１５０
に管理されている項目はこれらに限らない。

【００４１】配信要求登録部１８０は、再生機２０から
楽曲配信要求を受け付けると、その楽曲配信要求に含ま
れる楽曲名と楽曲情報データベース１４０に格納されて
いる楽曲名１４０１とを照合し、リクエストデータベー
ス１５０を構築する。また、コンテンツ配信部１６０が
楽曲の配信を終えると、当該楽曲の全データの配信を終
えた場合、リクエストデータベース１５０からその楽曲
に関するリクエストデータ１５１０を削除し、当該楽曲
の全データの配信を終えていない場合、つまり、データ
に関し未送信データがある場合、送信済みデータの最後
尾ポイントをリクエストデータベース１５０に登録す
る。また、再生機２０から楽曲配信要求データを削除す
る指示を受け付けると、該当するリクエストデータ１５
１０を削除する。

【００４２】コンテンツ配信部１６０は、定期的にリク
エストデータベース１５０をモニタし、リクエストデー
タ１５１０が一つもない状態で再生機２０からの楽曲配
信要求がリクエストデータ１５１０として新たに登録さ
れると起動する。リクエストデータベース１５０を参照
し、配信順序決定部１７０から指示された再生機２０に
関するリクエストデータ１５１０を抽出し、該当する楽
曲データをＣＤチェンジャによってＣＤから所定量読み
出し、要求元の再生機２０に送信するものである。

【００４３】ここで、再生する楽曲データの量は、該当
再生機２０のバッファの空き容量、または、その楽曲デ
ータの未送信のデータ量の少ない方である。そして、楽
曲データの未送信のデータ量とは、再生中の楽曲データ
のリクエストデータベース１５０の最終読み出し位置１
５０７にアドレスが保持されている場合は、前回送信時
にその楽曲データが全て送信されていないため、その楽
曲データのうち、最終読み出し位置以降のデータ、つま
り、前回未送信分のデータのことであり、最終読み出し
位置１５０７にアドレスが保持されていない場合は、そ
のリクエストデータ１５１０で示される楽曲データの全
データである。

【００４４】コンテンツ配信部１６０は、送信後、配信
要求登録部１８０にどちらのデータ量を送信したかを通
知し、また、配信順序決定部１７０に次の配信先の再生
機２０を問い合わせる。

【００４５】配信順序決定部１７０は、コンテンツ配信
部１６０から、配信先の再生機決定の指示を受け付ける
と、リクエストデータベース１５０を参照し、その時点
で楽曲配信要求としてリクエストデータ１５１０が登録
されている再生機２０を抽出し、それらの再生機２０の
バッファ部２３０のデータ残量を問い合わせる。問い合
わせの結果、最もデータ残量の少ない再生機２０を特定
し、その再生機２０を次に楽曲データを配信すべき再生
機２０として、コンテンツ配信部１６０に通知する。こ
こで、最もデータ残量の少ない再生機２０が複数あった
場合は、再度リクエストデータベース１５０を参照し、
データ残量が最小の再生機２０の中で楽曲配信要求の受
け付け時間の最も早い再生機２０を次の楽曲データを配
信すべき再生機２０としてコンテンツ配信部１６０に通
知する。

【００４６】なお、配信順序決定部１７０は、各再生機
２０のバッファ部２３０のデータ残量を、当該バッファ
部２３０に送信したデータの最後のアドレスから、現在
読み出しを行っているデータのアドレスを差し引いた
「差分」を用いて求めることで計測する。

【００４７】また、コンテンツ配信部１６０が、各再生
機２０に楽曲データを配信するにあたって、その送信先
再生機２０のバッファ部２３０の空き容量を前もって知
っておく必要がある。送信先再生機２０の空き容量は、
配信順序決定部１７０によって、各再生機２０に空き容
量の問合せを行った時に検出されたものが、送信先再生
機２０の通知とともに、配信順序決定部１７０からコン
テンツ配信部１６０に通知される。もちろん通知される
データは、データ残量そのものであってもよいし、デー
タ残量から算出した、そのデータ残量を再生する時間で
あってもよい。

【００４８】ここで、コンテンツ配信部１６０におい
て、複数の再生機２０に途切れなく楽曲データを配信す
るためには、ＣＤチェンジャのデータ読み出し時間は、
接続されている再生機の台数分の１未満であることが必
須条件となる。例えば、施設内に１０台の再生機２０を
設置した場合、ＣＤチェンジャは、１０倍より早い読み
出し速度が必要となる。実際には、さらに、ＣＤチェン
ジャ内でディスクの交換に費やすオーバーヘッドも考慮
する必要も出てくるため、複数の再生機２０が楽曲デー
タを途切れなく再生するためには、ＣＤチェンジャの読
み出し速度は、再生機２０のバッファ容量をＭ（byt
e）、再生機２０の数をｎ台、ＣＤ（楽曲データ）の再
生速度をVplay(byte/sec)、ＣＤチェンジャにおける楽
曲データの読み出し速度をVread(byte/sec)、ＣＤチェ
ンジャにおけるディスク交換時間をTex(sec)とすると、
以下の式を満たす必要がある。

【００４９】（Ｍ/Vread+Tex）×ｎ＜Ｍ/Vplay ・・・・・・(１)

【００５０】このように、本実施の形態のＣＤチェンジ
ャは、接続されている再生機の台数分倍以上であり、な
おかつ、ディスク交換のオーバーヘッド時間も考慮され
た、十分大きな速度でＣＤの楽曲データを読み出すこと
のできるものとする。

【００５１】言い換えれば、（１）式の条件を満たすシ
ステムであれば、楽曲配信サーバは、容量の小さいバッ
ファを備えた複数の再生機各々にスムーズにデータの配
信を行い、各再生機は、楽曲のデータをスムーズに効率
よく再生を行うことができる。

【００５２】もちろん、ディスク交換のオーバーヘッド
時間に関しては、それを短くするために、種々の工夫が
可能である。例えば、ＣＤチェンジャを増設し、コンテ
ンツ配信部１６０が、１つのＣＤチェンジャで楽曲デー
タを読み出している間に、次に楽曲データを配信すべき
ＣＤを確定し、他のＣＤチェンジャの再生部に確定した
ＣＤをセットし、現在再生中の楽曲の再生が終了すると
同時に、次の楽曲データの再生が始まるよう制御するな
どである。

【００５３】なお、ディスク交換のオーバーヘッド時間
を考慮しなくてもよい場合は、複数の再生機２０が楽曲
データを途切れなく再生するためには、ＣＤチェンジャ
の読み出し速度Vread(byte/sec)は、再生機２０の数を
ｎ台、ＣＤ（楽曲データ）の再生速度をVplay(byte/se
c)とすると、 Vread ＞ｎ × Vplay ・・・・・・（２）を満たせばよい。

【００５４】さらに、各ＣＤチェンジャが複数の再生部
を有する構成とし、同じＣＤチェンジャ内で、コンテン
ツ配信部１６０が、１つの再生部でＣＤを再生している
間に、別の再生部に次に再生するＣＤをセットするよう
制御することで、ディスク交換のオーバーヘッド時間を
軽減することもできる。

【００５５】もちろん、配信するコンテンツデータの種
類によって、例えば、途中多少の途切れがあっても、問
題ないものの場合は、上記のようなコンテンツデータの
読出し時間の条件およびコンテンツ配信部１６０の制御
などは不要となる。

【００５６】次に、本実施形態の楽曲再生システムの動
作につき説明する。本実施形態の楽曲再生システムで
は、再生機２０から楽曲配信サーバ１０へ楽曲の配信要
求が送信され、楽曲配信サーバ１０では、その楽曲配信
要求に基づきリクエストデータベース１５０を構築し、
構築されたリクエストデータベース１５０に基づき、要
求元の再生機２０に要求された楽曲を配信し、配信を受
けた再生機２０でその楽曲データは再生される。

【００５７】再生機２０から楽曲配信サーバ１０への楽
曲配信要求は、再生機２０の制御部２１０によって以下
のように行われる。まず、制御部２１０が楽曲配信サー
バ１０へ楽曲情報入手のためにアクセスし、楽曲配信サ
ーバ１０は、そのアクセスに応え、楽曲情報データベー
ス１４０で管理しているデータを楽曲情報として要求元
の再生機２０に送信する。それを受け取った制御部２１
０は、再生機２０の表示装置に受け取った楽曲情報の一
覧表示を行う。送信される楽曲情報には、楽曲名だけで
なくアーティスト名などの補助情報も含まれるので、制
御部２１０は、これらを利用してアーティスト別や楽曲
名の五十音順、または、これまでのリクエストの多い順
など披露宴ならではのメニュー画面を作成し、表示する
ことも可能である。

【００５８】再生機２０は、キーボードなどの入力装置
を介してユーザからの登録を受け付け、受け付けた楽曲
名を登録する。複数の楽曲のリクエストを連続して受け
付ける場合は、再生順番の希望も受け付け、楽曲名とと
もに楽曲配信要求データとして登録する。登録された楽
曲配信要求データは、一時的に再生機２０に保存され、
ユーザの指示に従い、再生機２０の配信要求部２２１に
よって楽曲配信サーバ１０に楽曲配信要求として送信さ
れる。また、一旦楽曲配信サーバ１０に送信された楽曲
配信要求データの削除の指示をユーザから受け付けた場
合、再生機２０は、その指示を楽曲配信サーバ１０に送
信する。

【００５９】また、楽曲配信サーバ１０から楽曲データ
の配信を受けた再生機２０は、受け取った楽曲データを
すぐに再生してもよいし、所望の時間まで待ってから再
生してもよい。再生開始、待機、一旦停止などの指示
は、ユーザからキーボードなどの入力装置を介して入力
され、再生機２０によって受け付けられる。また、ある
楽曲データの再生を中止することも可能である。ユーザ
から入力装置を介して楽曲再生中止の指示があった場
合、再生機２０は、バッファ部２３０内の未再生データ
を消去し、次に優先的に楽曲データの配信を受けられる
ようにする。この時、再生機２０は、再生中止になった
楽曲に関する楽曲配信要求データおよび必要ならばその
他の既に登録されている楽曲に関する楽曲配信要求デー
タを削除する指示を楽曲配信サーバ１０に送信する。

【００６０】次に、上記の楽曲配信要求を受け付けた楽
曲配信サーバ１０の配信コンテンツ制御部１１０の動作
について説明する。配信コンテンツ制御部１１０の処理
動作は、受け付けた楽曲配信要求をリクエストデータベ
ース１５０に登録する配信要求登録部１８０によるリク
エストデータベース構築処理と、構築されたリクエスト
データベース１５０に基づいて、楽曲データを各要求元
の再生機２０に配信するコンテンツ配信部１６０による
コンテンツデータ配信処理と、リクエストデータベース
１５０に管理されているデータと、各再生機２０のバッ
ファ部２３０のデータ残量に基づいて次に楽曲データを
配信する再生機２０を決定する配信順序決定部１７０に
よる配信再生機決定処理とからなる。以下に各々につき
説明する。

【００６１】リクエストデータベース構築処理におい
て、配信要求登録部１８０は、楽曲配信要求を受け付け
ると、受け付けた要求を構成する楽曲配信要求データの
楽曲名を元に、楽曲情報データベース１４０を参照し、
対応する楽曲名１４０１のＣＤチェンジャ識別番号１４
０４と、ＣＤ識別番号１４０５と、トラック識別番号１
４０６とを読み出す。そして、読み出したデータを、楽
曲配信要求データを受け付けた時間と、楽曲配信要求デ
ータに含まれている再生順と共に、要求元の再生機２０
毎にリクエストデータベース１５０に格納する。

【００６２】図４は配信再生機決定処理の流れを示すフ
ローチャートである。

【００６３】配信順序決定部１７０は、コンテンツ配信
部１６０から、配信再生機選択の指示を受け付けると、
リクエストデータベース１５０を参照し、リクエストデ
ータ１５１０が格納されている再生機２０を全て抽出す
る（Ｓ４０１）。抽出した全ての再生機２０に関し、各
バッファ部２３０のデータ残量を問合せる（Ｓ４０
２）。問合せ結果から、データ残量が最少の再生機２０
を選択する（Ｓ４０３）。ここで、ステップＳ４０３で
選択した再生機２０が１つであった場合（Ｓ４０４）、
その再生機２０を、楽曲データを配信する再生機２０と
してコンテンツ配信部１６０に通知する（Ｓ４０６）。
また、ステップＳ４０３で選択した再生機２０が複数で
あった場合、つまり、データ残量が最少でありかつ同量
である再生機２０が複数あった場合、ステップＳ４０３
で選択した全再生機２０に関し、リクエストデータベー
ス１５０を参照し、受け付け時間１５０２の最も早い再
生機２０を選択する（Ｓ４０５）。そしてステップＳ４
０５で選択した再生機を楽曲データを配信する再生機２
０としてコンテンツ配信部１６０に通知する（Ｓ４０
６）。

【００６４】図５は、コンテンツデータ配信処理の流れ
を示すフローチャートである。

【００６５】コンテンツ配信部１６０は、定期的にリク
エストデータベース１５０をモニタし、リクエストデー
タ１５１０が登録されると処理を開始する。まず、配信
順序決定部１７０に配信再生機選択の指示を出し、楽曲
データを配信する再生機２０を選択させる（Ｓ５０
１）。選択された再生機２０からのリクエストデータ１
５１０をリクエストデータベース１５０から取得し（Ｓ
５０２）、リクエストされている楽曲のＣＤを、送信先
バッファ部２３０が満杯になるまで、または、その楽曲
データの未送信のデータ全ての少ない方だけ再生し、要
求元の再生機２０に送信する（Ｓ５０３）。

【００６６】その後、コンテンツ配信部１６０は、当該
楽曲データを全て再生し送信したかどうか判断する（Ｓ
５０４）。全て再生し送信したと判断した場合、リクエ
ストデータベース１５０から、そのリクエストデータ１
５１０を削除し（Ｓ５０５）、リクエストデータベース
１５０を参照し、未処理のリクエストデータ１５１０が
あるかどうか確認する（Ｓ５０６）。未処理のリクエス
トデータ１５１０がなければ、処理を終了する。未処理
のリクエストデータ１５１０があれば、ステップＳ５０
１へ行く。コンテンツ配信部１６０は、当該楽曲データ
を全て再生し送信していないと判断した場合、再生され
た当該楽曲データの最終のアドレスを、リクエストデー
タベース１５０の最終読み出し位置１５０７に格納する
よう配信要求登録部１８０に通知する（Ｓ５０７）。そ
してステップＳ５０１に行く。

【００６７】以下、具体例で説明する。

【００６８】ここでは、再生機を５台とし、ＣＤチェン
ジャの読み出し速度を２０倍速、ＣＤチェンジャがディ
スク交換に要する時間を１０秒とする。また、各再生機
２０のバッファ部２３０の容量を３０ＭＢとする。これ
は、ＣＤの楽曲データの１分に相当する量が約１０ＭＢ
であるため、ほぼ３分に相当する量ということである。
また、ネットワーク３０上の送信速度は、上記読出し速
度以上とする。

【００６９】図７は、各再生機からの楽曲配信要求であ
るリクエスト状況を示したものである。本図に示すよう
に、再生機２０−１は、３分の曲であるｄｉｓｋ＃１と
３分の曲であるｄｉｓｋ＃５をこの順でリクエストして
いる。再生機２０−２は、５分の曲であるｄｉｓｋ＃２
と２分の曲であるｄｉｓｋ＃３を、再生機２０−３は、
２分の曲であるｄｉｓｋ＃３と４分の曲であるｄｉｓｋ
＃２をこの順に、再生機２０−４は、３分の曲であるｄ
ｉｓｋ＃１を、そして、再生機２０−５は、４分の曲で
あるｄｉｓｋ＃４をリクエストしている。また、楽曲配
信サーバ１０は、再生機２０−１から再生機２０−５の
順にリクエストを取得したとする。また、例外処理とし
て、再生開始２分後に再生機２０−２においてｄｉｓｋ
＃２の再生を中断し、次のリクエストの曲であるｄｉｓ
ｋ＃３の再生を行うこととする。

【００７０】このような状況で、楽曲配信サーバ１０が
どのような配信処理をしているか、図８に基づき説明す
る。図８は、楽曲配信サーバ１０から各再生機２０−１
〜５へのデータ配信を時系列に示した図である。

【００７１】図８において、横軸が時間軸を示し、縦軸
が楽曲配信サーバ１０が各再生機２０に楽曲を配信する
処理を各々の再生機に対する配信処理毎に示している。
また、本図において各再生機２０−１〜５における四角
形の幅は、各再生機２０−１〜５がデータを再生してい
る時間を示す。

【００７２】楽曲配信サーバ１０は、データの配信対象
の再生機の選択（各再生機２０−１〜５のバッファ部２
３０のデータの残量の問い合わせ等）を行い、対象とな
る曲が記録されたディスクの交換、データの配信対象の
再生機へのデータ転送の動作を繰り返し行う。

【００７３】再生機２０−１から再生機２０−５は、楽
曲サーバ１０へ楽曲配信要求データを転送し、楽曲配信
要求を行う。これらの楽曲配信要求データが楽曲配信サ
ーバ１０のリクエストデータベース１５０に格納された
時点では、どの再生機のバッファ部２３０にもデータが
ない状態なので、楽曲サーバ１０は、楽曲配信要求を時
間的に一番早く受け付けた再生機２０−１にデータ転送
の処理を開始する。

【００７４】図８（ａ）の配信処理において、楽曲配信
サーバ１０は、再生機２０−１のリクエストであるｄｉ
ｓｋ＃１をＣＤチェンジャに１０秒かけてセットする。
再生機２０−１は３分に相当する量のバッファを持って
おり、ｄｉｓｋ＃１の曲のデータは３分であるため、楽
曲配信サーバ１０は、再生機２０−１のバッファ部２３
０にｄｉｓｋ＃１の全データを転送する。３分の楽曲の
読み出し転送時間は、９秒である。データ転送後、楽曲
配信サーバ１０は、リクエストデータベース１５０から
ｄｉｓｋ＃１の曲のデータを削除し、再生機２０−１
は、すぐに再生を開始する。

【００７５】再生機２０−１に転送終了後、楽曲配信サ
ーバ１０は、各再生機にバッファ部２３０のデータの残
量を問い合わせる。ここで、バッファ部２３０のデータ
の残量は、残りの再生時間で示される。再生機２０−１
以外は、どの再生機バッファにもデータが無い状態なの
で、楽曲配信サーバ１０は、残りの再生機の中で、楽曲
配信要求を時間的に一番早く受け付けた再生機２０−２
にデータ転送の処理を開始する。

【００７６】図８（ｂ）の配信処理において、再生機２
０−２のリクエストは、ｄｉｓｋ＃２の５分の曲であ
る。楽曲配信サーバ１０は、ｄｉｓｋ＃１からｄｉｓｋ
＃２に１０秒かけて交換し、再生機２０−２のバッファ
部２３０のバッファサイズに合わせ、ｄｉｓｋ＃２の楽
曲データ５分のうち、３分に相当する量の楽曲データを
９秒かけて再生機２０−２に転送する。そして、３分に
相当する量のデータを送信したことをリクエストデータ
ベース１５０の最終読み出し位置欄に記憶させておく。
データ転送終了後、再生機２０−２はすぐに再生を開始
し、楽曲配信サーバ１０は、各再生機のバッファ部２３
０のデータ残量、つまり、残り再生時間を、各再生機に
問い合わせる。

【００７７】この時点で、各再生機の残り再生時間は、
再生機２０−１が２分４１秒であり、再生機２０−２が
３分であり、再生機２０−３から再生機２０−５は０分
である。従って、楽曲配信サーバ１０は、最もデータ残
量が少ない再生機２０−３から再生機２０−５までのう
ち、楽曲配信要求を一番早く受け付けた再生機２０−３
にデータ転送の処理を開始する。

【００７８】図８（ｃ）の配信処理において、再生機２
０−３のリクエストは、ｄｉｓｋ＃３の２分の曲であ
る。再生機２０−３は３分に相当する量のバッファを持
っている。楽曲配信サーバ１０は、ｄｉｓｋ＃２からｄ
ｉｓｋ＃３に１０秒かけて交換し、リクエストされたｄ
ｉｓｋ＃３の２分の曲のデータ全てを再生機２０−３に
６秒かけて転送する。データ転送終了後、再生機２０−
３はすぐに再生を開始し、楽曲配信サーバ１０は、リク
エストデータベース１５０の再生機２０−３のｄｉｓｋ
＃３の曲のデータを削除し、各再生機にバッファ部２３
０のデータの残量、つまり、残りの再生時間を問い合わ
せる。

【００７９】この時点で、各再生機の残り再生時間は、
再生機２０−１が２分２５秒であり、再生機２０−２が
２分４４秒であり、再生機２０−３が２分であり、再生
機２０−４及び再生機２０−５は０分である。従って、
楽曲配信サーバ１０は、最もデータ残量が少ない再生機
２０−４および再生機２０−５のうち、楽曲配信要求を
一番早く受け付けた再生機２０−４にデータ転送の処理
を開始する。

【００８０】図８（ｄ）の配信処理において、再生機２
０−４のリクエストは、ｄｉｓｋ＃１の３分の曲であ
る。再生機２０−４は３分に相当する量のバッファを持
っている。楽曲配信サーバ１０は、ｄｉｓｋ＃３からｄ
ｉｓｋ＃１に１０秒かけて交換し、リクエストされたｄ
ｉｓｋ＃１の３分の曲のデータ全てを再生機２０−４に
９秒かけて転送する。データ転送終了後、再生機２０−
４はすぐに再生を開始し、楽曲配信サーバ１０は、リク
エストデータベース１５０の再生機２０−４のｄｉｓｋ
＃１の曲のデータを削除し、各再生機にバッファ部２３
０のデータの残量、つまり、残りの再生時間を問い合わ
せる。

【００８１】この時点で、各再生機の残り再生時間は、
再生機２０−１が２分０６秒であり、再生機２０−２が
２分２５秒であり、再生機２０−３が１分４１秒であ
り、再生機２０−４が３分であり、再生機２０−５は０
分である。従って、楽曲配信サーバ１０は、最もデータ
残量が少ない再生機２０−５にデータ転送の処理を開始
する。

【００８２】図８（ｅ）の配信処理において、再生機２
０−５のリクエストは、ｄｉｓｋ＃４の４分の曲であ
る。再生機２０−５は３分に相当する量のバッファを持
っている。楽曲配信サーバ１０は、ｄｉｓｋ＃１からｄ
ｉｓｋ＃４に１０秒かけて交換し、再生機２０−５のバ
ッファ部２３０のバッファサイズに合わせ、ｄｉｓｋ＃
４の楽曲データ４分のうち、３分に相当する量の楽曲デ
ータを９秒かけて再生機２０−５に転送する。そして、
３分に相当する量のデータを送信したことをリクエスト
データベース１５０の最終読み出し位置欄に記憶させて
おく。データ転送終了後、再生機２０−５はすぐに再生
を開始する。

【００８３】ここで、楽曲配信サーバ１０は、５台の再
生機２０−１〜再生機２０−５のリクエストに対して１
回ずつデータ転送の処理を行ったことになる。

【００８４】楽曲配信サーバ１０は、再生機２０−５へ
のデータ転送が終了した後、各再生機のバッファ部２３
０のデータ残量、つまり、残り再生時間を、各再生機に
問い合わせる。

【００８５】この時点で、各再生機の残り再生時間は、
再生機２０−１が１分４７秒（１０７秒）であり、再生
機２０−２が２分０６秒であり、再生機２０−３が１分
２２秒（８２秒）であり、再生機２０−４が２分４１秒
（１６１秒）であり、再生機２０−５が３分（１８０
秒）である。楽曲配信サーバ１０は、最もデータ残量が
少ない再生機２０−３にデータ転送の処理を開始する。

【００８６】図８（ｆ）の配信処理において、再生機２
０−３の２番目のリクエストは、ｄｉｓｋ＃２の４分の
曲である。楽曲配信サーバ１０は、ｄｉｓｋ＃４からｄ
ｉｓｋ＃２に１０秒かけて交換する。再生機２０−３は
３分に相当する量のバッファを持っているため、再生機
２０−５のデータ転送終了後時点（図８（ｅ））でのバ
ッファ部２３０の空き容量は９８秒に相当する量であ
る。その後、ディスクの交換のための１０秒分再生が進
むため、送信開始時点での再生機２０−３のバッファ部
２３０の空き容量は１０８秒に相当する量となる。した
がって、楽曲配信サーバ１０は、再生機２０−３のバッ
ファ部２３０の空き容量に合わせ、ｄｉｓｋ＃２の４分
の曲のデータのうち、１０８秒に相当する量の楽曲デー
タを５．４秒かけて再生機２０−３に転送する。データ
転送終了後、楽曲配信サーバ１０は、１０８秒に相当す
る量のデータ送信したことをリクエストデータベース１
５０の最終読み出し位置欄に記憶させ、各再生機にバッ
ファ部２３０のデータの残量、つまり、残りの再生時間
を問い合わせる。

【００８７】この時点で、再生機２０−１が１分３１．
６秒（９１．６秒）であり、再生機２０−２が１分５
０．６秒（１１０．６秒）であり、再生機２０−３が３
分であり、再生機２０−４が２分２５．６秒（１４５．
６秒）であり、再生機２０−５が２分４４．６秒（１６
４．６秒）であり、楽曲配信サーバ１０は、最もデータ
残量が少ない再生機２０−１にデータ転送の処理を開始
する。

【００８８】図８（ｇ）の配信処理において、再生機２
０−１の２番目のリクエストは、ｄｉｓｋ＃５の３分の
曲である。楽曲配信サーバ１０は、ｄｉｓｋ＃２からｄ
ｉｓｋ＃５に１０秒かけて交換する。再生機２０−１は
３分に相当する量のバッファを持っているため、再生機
２０−３へのデータ転送終了後時点（図８（ｆ））での
再生機２０−１のバッファ部２３０の空き容量は８８．
４秒に相当する量である。その後、ディスクの交換のた
めの１０秒分再生が進むため、送信開始時点での再生機
２０−１のバッファ部２３０の空き容量は９８．４秒に
相当する量となる。したがって、楽曲配信サーバ１０
は、再生機２０−１のバッファ部２３０の空き容量に合
わせ、ｄｉｓｋ＃５の楽曲データ３分のうち、９８．４
秒に相当する量の楽曲データを４．９秒かけて再生機２
０−１に転送する。そして、９８．４秒に相当する量の
データを送信したことをリクエストデータベース１５０
の最終読み出し位置欄に記憶させておく。

【００８９】以下、上述した処理の繰り返しにより、楽
曲配信サーバ１０は、再生機２０−１〜再生機２０−５
へのデータ転送を行う。

【００９０】次に、例外処理が発生した場合の処理につ
いて説明する。

【００９１】具体的には、再生機２０−３への２回目の
リクエストに対するデータ転送が終了し（図８
（ｆ））、再生機２０−１への２回目のリクエストに対
するデータ転送の処理中（図８（ｇ））に、すなわち、
リクエストを受けデータ転送の処理を開始後２分が経過
したとき、再生機２０−２において、現在再生中のｄｉ
ｓｋ＃２を停止する指示、および、次のリクエストの楽
曲であるｄｉｓｋ＃３の再生要求を受け付けるという例
外処理が発生したとして説明する。

【００９２】なお、例外処理がなかったとすると、図８
（ｈ）の配信処理において、再生機２０−１へのデータ
転送終了後、楽曲配信サーバ１０が、各再生機にデータ
の残量を問い合わせ、最もデータ残量の少ない再生機２
０−２に１回目のリクエストのｄｉｓｋ＃２の５分の楽
曲データにおける３分の曲のデータを転送した後の残り
２分のデータのうち、９４．３秒分のデータを転送する
ことになる。

【００９３】図８（ｇ）の配信処理中に、再生機２０−
２で例外処理が発生すると、再生機２０−２は、例外処
理が発生した旨を楽曲配信サーバ１０に通知し、バッフ
ァに記憶されている楽曲データのうち、停止要求したｄ
ｉｓｋ＃２のデータを消去する。具体的には、ｄｉｓｋ
＃２の再生終了アドレスをバッファ内のｄｉｓｋ＃２の
楽曲データの最終アドレスに変更するなど、楽曲配信サ
ーバ１０からの問合せに対し、バッファ部２３０のデー
タ残量が０となるようにする操作を行う。

【００９４】楽曲配信サーバ１０は、リクエストデータ
ベース１５０の再生機２０−２の１回目のリクエストで
あるｄｉｓｋ＃２が再生停止要求があった旨の通知を受
け、リクエストデータベース１５０の再生機２０−２の
１回目のリクエストであるｄｉｓｋ＃２のデータを削除
する。

【００９５】図８（ｉ）の配信処理において、再生機２
０−２による２回目のリクエストは、ｄｉｓｋ＃３の２
分の曲である。再生機２０−２は３分に相当する量のバ
ッファを持っている。楽曲配信サーバ１０は、ｄｉｓｋ
＃５からｄｉｓｋ＃３に１０秒かけて交換し、ｄｉｓｋ
＃３の楽曲データ２分の楽曲データを６秒かけて再生機
２０−２に転送する。データ転送終了後、再生機２０−
２はすぐに再生を開始し、楽曲配信サーバ１０は、リク
エストデータベース１５０の再生機２０−２のｄｉｓｋ
＃３の曲のデータを削除し、各再生機にバッファ部２３
０のデータの残量、つまり、残りの再生時間を問い合わ
せる。

【００９６】この時点で、各再生機の残り再生時間は、
再生機２０−１が２分３９．１秒（１５９．１秒）であ
り、再生機２０−２が２分（１２０秒）であり、再生機
２０−３が２分２３．７秒（１４３．７秒）であり、再
生機２０−４が１分５４．７秒（１１４．７秒）であ
り、再生機２０−５が２分１３．７秒（１３３．７秒）
である。再生機２０−４は、残り再生時間が１１４．７
秒で一番少ないが、リクエストデータベースに登録され
ている再生機２０−４の次のリクエストはない。従っ
て、楽曲配信サーバ１０は、次に最もデータ残量が少な
い再生機２０−５にデータ転送の処理を開始する。この
時点で、再生機２０−５のバッファ部２３０の空き容量
は、４６．３秒である。

【００９７】図８（ｊ）の配信処理において、楽曲配信
サーバ１０は、ｄｉｓｋ＃３からｄｉｓｋ＃２に１０秒
かけて交換する。その間、再生機２０−５の再生は進む
ため、楽曲配信サーバ１０は、再生機２０−５のリクエ
ストのｄｉｓｋ＃４の４分の曲のデータにおいて既にデ
ータ転送した３分を除く残り１分のデータのうち、再生
機２０−５に５６．３秒に相当する量のデータを転送す
る。すなわち、楽曲配信サーバ１０は、再生機２０−５
のバッファサイズに合わせ、ｄｉｓｋ＃４の４分の楽曲
データにおいて既にデータ転送した３分を除く残りのデ
ータ１分のデータのうちの５６．３秒に相当する量の楽
曲データを２．８秒かけて再生機２０−５に転送する。
そして、３分５６．３秒に相当する量送信したことをリ
クエストデータベース１５０の最終読み出し位置欄に記
憶させておく。

【００９８】以下、上述した処理の繰り返しにより、楽
曲配信サーバ１０は、例外処理が発生した場合でも再生
機２０−１〜再生機２０−５にデータ転送を行う。

【００９９】ここでは、全ての再生機が楽曲の転送を受
け、すぐに再生を開始すると仮定したが、前述したよう
に、楽曲の再生はデータの転送を受けて、すぐに行わな
くてもよい。その場合、待機した時間だけ、バッファ内
の未再生データの減りが少なくなるため、次の配信順は
後となる。

【０１００】また、楽曲配信サーバ１０から再生機２０
へのデータ転送は、再生機２０のバッファ部２３０の空
き容量か、リクエストされた楽曲データの未送信データ
量の少ない方と仮定したが、１つの再生機２０からのリ
クエストデータ１５１０が複数ある場合であり、かつ、
そのとき転送しようとしている楽曲データの未送信分の
データ量がバッファ部２３０の空き容量より少ない場合
は、まず、その楽曲データの未送信分のデータを転送
し、ＣＤを交換し、合計してバッファ部２３０の空き容
量になるまで、次にリクエストされている楽曲データを
続けて転送するようにしてもよい。

【０１０１】このように、本実施形態においては、楽曲
配信サーバ１０が、各再生機２０のバッファ部２３０の
データ残量を常に監視し、そのデータ残量が最も少ない
再生機２０に、次にリクエストされた楽曲のデータを、
バッファ容量の空き分以下だけ転送するよう制御を行っ
ている。このため、本実施の形態のように、送信された
楽曲データを一時的に蓄積できるバッファ容量が小さい
再生機であっても、スムーズに楽曲の配信を受けること
ができる。

【０１０２】次に、第二の実施形態について、説明す
る。

【０１０３】第一の実施の形態では、楽曲配信サーバ１
０が、各再生機２０に対し未再生時間（データ残量）を
問い合わせ、未再生時間が最少の再生機２０に対し、当
該再生機のバッファ空き容量に相当する量のデータを転
送する。そのため、楽曲再生システムにおいて、稼動し
ている再生機２０の数が全数に満たないような場合で
も、楽曲配信サーバ１０は、最も残りデータ容量（未再
生時間）が少ない再生機２０に対して、随時データ転送
を行う。

【０１０４】例えば、稼動している再生機２０の数が全
数に満たないような場合、全ての再生機２０がバッファ
に記憶したデータの読み出し再生に要する時間よりも、
楽曲配信サーバ１０が各再生機へのバッファのデータ残
量の問い合わせ、ディスク交換及びデータ転送に要する
時間が短くなる。すなわち、再生機２０においてデータ
転送後から次にデータが転送されるまでに要する時間が
短い（再生機２０が再生するデータ量が少ない）ため、
楽曲配信サーバ１０は、楽曲配信サーバ１０が再生機２
０に転送するデータ量が徐々に少なくなる。このような
場合、楽曲配信サーバ１０から再生機にデータを転送す
る回数が多くなる。

【０１０５】そこで、本発明の第二の実施形態では、楽
曲配信サーバ１０は、各再生機に未再生時間の問い合わ
せを行い、各再生機の未再生時間（残りデータ容量）が
最も短い再生機２０を選択する。そして、その選択され
た再生機２０における未再生時間を予め定められた設定
時間と比較し、未再生時間が設定時間以下の場合のみ、
その再生機２０にデータを転送する。

【０１０６】ここで、設定時間は、楽曲配信サーバ１０
が全ての再生機２０に問合せを行い、かつ、全ての再生
機２０にデータの送信を行う時間の合計よりも長い時間
とする。例えば、前述した（１）式の条件を満たすシス
テムにおいて、次式に示す条件を上限値とする時間であ
る。

【０１０７】再生機２０のバッファ容量をＭ（byte）、
再生機２０の数をｎ台、ＣＤ（楽曲データ）の再生速度
をVplay(byte/sec)、ＣＤチェンジャにおける楽曲デー
タの読み出し速度をVread(byte/sec)、ＣＤチェンジャ
におけるディスク交換時間をTex(sec)とすると、設定時
間（sec）は、設定時間＝（Ｍ／Ｖplay）−（Ｍ／Ｖread＋Ｔex）×ｎ・・・（３）となる。

【０１０８】なお、比較するものを各再生機２０のバッ
ファ部２３０内の未再生時間としたが、これを、データ
残量とし、予め定められた設定値と比較するよう構成し
てもよい。

【０１０９】また、本実施形態における楽曲再生システ
ムの構成は、第一の実施形態と同じである。そして、
（１）式の条件は、本実施形態においても、配信するコ
ンテンツデータの種類によって、例えば、途中多少の途
切れがあっても問題のないコンテンツデータの場合は、
不要である。楽曲配信サーバ１０は、（３）式を満たす
値を上限値とした設定時間を用い、再生機の未再生時間
が当該設定時間より短くなった場合に、データ転送を行
うようにすることにより、楽曲配信サーバ１０から再生
機にデータを転送する回数を減らすことができる。

【０１１０】第一の実施形態とその働きが異なるものは
配信順序決定部１７０である。

【０１１１】第二の実施形態においては、配信順序決定
部１７０は、コンテンツデータ配信部１６０から、配信
先の再生機決定の指示を受け付けると、リクエストデー
タベース１５０を参照し、その時点で楽曲配信要求とし
てリクエストデータ１５１０が登録されている再生機２
０を抽出する。そして抽出した再生機２０各々のバッフ
ァ部２３０のデータの未再生時間を問い合わせる。問合
せの結果、最もデータ残量の少ない再生機２０を特定
し、その再生機２０の未再生時間各再生機２０のバッフ
ァ部２３０の未再生時間を問い合わせ、最も未再生時間
が短い再生機を特定し、当該再生機の未再生時間が設定
時間より短いときに、再生機２０の中で一番リクエスト
タイミングの早い再生機２０を、次に楽曲データを配信
する再生機２０としてコンテンツ配信部１６０に通知す
るものである。

【０１１２】図６は、第二の実施形態における上述の配
信順序決定部１７０による配信再生機決定処理の流れを
示すフローチャートである。

【０１１３】配信順序決定部１７０は、コンテンツ配信
部１６０から、配信再生機選択の指示を受け付けると、
リクエストデータベース１５０を参照し、リクエストデ
ータ１５１０が格納されている全ての再生機２０を抽出
する（Ｓ６０１）。抽出した全ての再生機２０の各バッ
ファ部２３０の未再生時間を問い合わせる（Ｓ６０
２）。そして、問い合わせ結果から、未再生時間が最も
短い再生機２０を選択し（Ｓ６０３）、その/それらの
再生機２０の未再生時間と設定時間とを比較する（Ｓ６
０４）。未再生時間の方が短いときは、その/それらの
再生機２０の数が１つであるならば（Ｓ６０５）、その
再生機２０を、楽曲データを配信する再生機２０として
コンテンツ配信部１６０に返す（Ｓ６０７）。ステップ
Ｓ６０５において、その再生機２０が複数の場合、リク
エストデータベース１５０を参照し、受付時間１５０２
の最も速い再生機２０を選択する（Ｓ６０６）。そし
て、その再生機２０を、楽曲データを配信する再生機２
０としてコンテンツ配信部１６０に返す（Ｓ６０７）。

【０１１４】ステップＳ６０４において、未再生時間の
方が、設定時間より長い場合、所定のタイミングで、ス
テップＳ６０１に戻り（Ｓ６１０）、再度処理を繰り返
す。ここで、所定のタイミングでステップＳ６０１に戻
るというのは、設定時間より短い予め定めた任意の時間
（以後、待機時間と呼ぶ）待機して、ステップＳ６０１
に戻り、そこからの処理を開始するということである。
なお、ステップＳ６０４の比較において、未再生時間と
設定時間の差が、その待機時間より短い場合は、ステッ
プＳ６１０において、差の時間のみ待機するよう構成し
てもよい。

【０１１５】このように、本実施形態においては、楽曲
配信サーバ１０が、各再生機２０のバッファ部２３０の
データ残量（未再生時間）を監視し、そのデータ残量
（未再生時間）が所定のデータ量（設定時間）より少な
くなるまでデータ転送を待機し、データ残量が所定のデ
ータ量より少なくなったときに、次に送信すべき楽曲デ
ータを当該再生機のバッファ空き容量に相当する量転送
するように制御を行っている。このため、本実施形態の
ように、稼動している再生機の数が全数に満たないよう
な場合でも、楽曲配信サーバ１０から再生機にデータを
転送する回数が少なく、送信された楽曲データを一時的
に蓄積できるバッファ容量が小さい再生機であっても、
スムーズに楽曲の配信を受けることができる。

【０１１６】以上の説明のとおり、本発明によれば、楽
曲配信サーバから配信された楽曲を、ネットワークに接
続されたバッファリングできるデータ量の小さい簡単な
システムの再生機において、スムーズに効率よく再生す
ることが可能となる。

【０１１７】なお、本発明は上記の実施形態に限定され
るものではなく、その要旨の範囲内で様々な変形が可能
である。例えば、上記の実施形態では、楽曲データを取
り扱う場合を例にとり説明したが、本発明は、これに限
定されない。本発明は、様々なコンテンツデータを複数
のクライアントに配信するシステムに広く適用できる。

【０１１８】また、上記の実施形態では、各再生機のバ
ッファ容量を同じと仮定して説明したが、個々の再生機
ごとにバッファ容量が異なっていてもよい。この場合、
例えば、コンテンツ配信サーバ側に、各再生機のバッフ
ァ容量に関するデータを持たせるなどして対応する。

【０１１９】

【発明の効果】本発明によれば、ネットワークに接続さ
れた、小容量のメモリを搭載した複数のコンテンツ再生
機に対し、コンテンツ配信サーバから、コンテンツデー
タを、円滑に配信できる。

【図面の簡単な説明】

【図１】図１は本発明の第一の実施形態における楽曲再
生システムの基本構成を説明するためのブロック図であ
る。

【図２】図２は楽曲情報データベース１４０のデータ構
造の一例を示す図である。

【図３】図３はリクエストデータベース１５０のデータ
構造の一例を説明するための図である。

【図４】図４は第一の実施形態における配信再生機決定
処理の流れを示すフローチャートである。

【図５】図５はコンテンツデータ配信処理の流れを示す
フローチャートである。

【図６】図６は第二の実施形態における配信再生機決定
処理の流れを示すフローチャートである。

【図７】図７は各再生機からのリクエスト状況を示す図
である。

【図８】図８は楽曲配信サーバから各再生機へのデータ
転送を時系列に示した図である。

【符号の説明】

10・・・楽曲配信サーバ、 20-1・・・再生機、 20-n・
・・再生機、 30・・・ネットワーク網、 110・・・配
信コンテンツ制御部、 1101・・・記憶部、 1102・・・
制御部、 120・・・インタフェース部、 130・・・プロ
グラム、 140・・・楽曲情報データベース、 150・・・
リクエストデータベース、 160・・・コンテンツ配信
部、 170・・・配信順序決定部、 180・・・配信要求登
録部、 210・・・制御部、 211・・・配信要求部、 220
・・・Ｄ／Ａ変換部、 230・・・バッファ部、 240・・
・インタフェース部

Claims

【特許請求の範囲】

【請求項１】コンテンツ配信サーバと、複数の再生機と
を有するコンテンツ配信システムであって、前記再生機は、前記コンテンツ配信サーバにコンテンツデータの配信要
求を送信する配信要求手段と、前記コンテンツ配信サーバより配信されたコンテンツデ
ータを一時的に蓄積するメモリとを有し、前記コンテンツ配信サーバは、配信要求を登録する配信要求登録手段と、配信要求の対象となるコンテンツデータを、当該配信要
求元の前記再生機へ配信するコンテンツ配信手段と、前記配信要求登録手段に配信要求が登録されている前記
再生機のうち、次にコンテンツデータを配信すべき前記
再生機を決定する配信順序決定手段とを有し、前記配信要求登録手段は、登録されている配信要求毎に、当該配信要求の対象とな
るコンテンツデータのうち、当該配信要求元の前記再生
機に送信済みのデータの最後尾ポイントをも登録し、前記配信順序決定手段は、前記配信要求登録手段に配信要求が登録されている前記
再生機各々より、当該再生機に送信済みのデータのうち
未再生部分のデータ量を取得し、取得した前記再生機各
々の未再生部分のデータ量に基づいて、次にコンテンツ
データを配信すべき前記再生機を決定し、前記コンテンツ配信手段は、前記配信順序決定手段により決定された前記再生機に対
し、前記配信要求登録手段に登録されている当該再生機
の配信要求の対象となるコンテンツデータのうち、当該
配信要求と共に登録されている最後尾ポイントに続く部
分のデータを送信することを特徴とするコンテンツ配信
システム。
【請求項２】請求項１記載のコンテンツ配信システムで
あって、前記配信順序決定手段は、未再生部分のデータ量が最も少ない前記再生機を抽出
し、次にコンテンツデータを配信すべき前記再生機と決
定することを特徴とするコンテンツ配信システム。
【請求項３】請求項２記載のコンテンツ配信システムで
あって、前記配信順序決定手段は、未再生部分のデータ量が最も少ない前記再生機を抽出し
た場合であっても、前記未再生部分のデータ量が予め定
められたデータ量以上の場合は、次にコンテンツデータ
を配信すべき再生機と決定しないことを特徴とするコン
テンツ配信システム。
【請求項４】請求項１、２または３記載のコンテンツ配
信システムであって、前記コンテンツ配信手段は、前記再生機のコンテンツ再生速度に、前記コンテンツ配
信再生システムを構成する前記再生機の数を掛け合わせ
たものよりも速い送信速度で、コンテンツデータを配信
することを特徴とするコンテンツ配信システム。
【請求項５】請求項１、２、３または４記載のコンテン
ツ配信システムであって、前記コンテンツデータはＣＤに記録された楽曲であり、前記コンテンツ配信手段は、少なくとも１台のＣＤチェンジャ装置を備えることを特
徴とするコンテンツ配信システム。
【請求項６】請求項１、２、３、４または５記載のコン
テンツ配信システムで用いるコンテンツ配信サーバ。
【請求項７】請求項１、２、３、４または５記載のコン
テンツ配信システムで用いる再生機。
【請求項８】複数の再生機各々に対して、前記再生機が
要求するコンテンツデータを配信するコンテンツ配信方
法であって、前記再生機より送られてきた配信要求を登録する配信要
求登録ステップと、配信要求が登録されている前記再生機のうち、次にコン
テンツデータを配信すべき前記再生機を決定する決定ス
テップと、決定された前記再生機に対して、当該再生機の配信要求
の対象となるコンテンツデータを配信する配信ステップ
と、決定された前記再生機に対応付けて、当該再生機の配信
要求の対象となるコンテンツデータのうち、当該再生機
に送信済みのデータの最後尾ポイントを登録する最後尾
ポイント登録ステップと、を有し、前記決定ステップは、配信要求が登録されている前記再生機各々より、当該再
生機に送信済みのデータのうち未再生部分のデータ量を
取得し、取得した前記再生機各々の未再生部分のデータ
量に基づいて、次にコンテンツデータを配信すべき前記
再生機を決定し、前記配信ステップは、決定された前記再生機に対して、当該再生機の配信要求
の対象となるコンテンツデータのうち、当該再生機に送
信済みのデータの最後尾ポイントに続く部分のデータを
送信することを特徴とするコンテンツ配信方法。