(57)【要約】音楽コンテンツ配信システム１は、音楽資産管理システム２、ネットワーク３、ＡＶ装置４−ｎ、およびテレビジョン受像機（ＴＶ）５−ｎを含む。音楽資産管理システム２は、異なる音楽サービスを提供する複数の音楽サーバ２０−ｋからなり、ネットワーク３に接続される。ＡＶ装置４−ｎは、ネットワーク３を通じて全ての音楽サーバ２０−ｋにアクセスできる。ＡＶ装置４−ｎは、音楽サーバ２０−ｋから音楽コンテンツを受信する。【特許請求の範囲】
【請求項１】
各々が、音楽コンテンツを提供する複数の音楽コンテンツ提供サーバと、
ネットワークを通じて前記音楽コンテンツ提供サーバのいずれにもアクセス可能な少なくとも１つのオーディオ／ビジュアル装置と、を備え、
前記オーディオ／ビジュアル装置は、
前記音楽コンテンツ提供サーバと交信して、前記音楽コンテンツ提供サーバから音楽コンテンツを受信する通信処理部と、
前記通信処理部が受信した前記音楽コンテンツに基づいて、テレビジョン受像機が表示できる形式の映像信号および前記テレビジョン受像機が出力できる形式の音声信号を生成する映像／音声処理部と、
プログラムを実行して、前記通信処理部および前記映像／音声処理部を制御する制御部と、
前記プログラムを記憶する記憶部と、を含み、
前記音楽コンテンツ提供サーバは、前記オーディオ／ビジュアル装置の要求に応じて、前記音楽コンテンツを送信する、音楽コンテンツ配信システム。
【請求項２】
少なくとも歌詞のデータを複数の楽曲の各々について検索可能なサーバ、およびネットワークを介して前記サーバにアクセスするユーザ端末を含む音楽コンテンツ配信システムであって、
前記ユーザ端末は、
少なくとも１つの楽曲とその楽曲に関連する楽曲情報とを記憶した記憶媒体から前記楽曲情報を読み出す再生手段；
前記楽曲情報を前記ネットワークを介して前記サーバへ送信する送信手段；
前記サーバが前記楽曲情報に基づいて検索した前記楽曲の歌詞を表す歌詞データを受信する受信手段；および
前記受信手段によって受信した歌詞データに基づく歌詞を表示する表示手段を備える、音楽コンテンツ配信システム。
【請求項３】
前記歌詞データは、複数のブロックに区分けされた歌詞ブロックと前記歌詞ブロック毎にその歌詞ブロックの歌詞を表示すべき時間を表すブロック開始時間とのデータを含み、
前記再生手段は前記記憶媒体の前記楽曲を再生し、
前記ブロック開始時間に基づいて、前記歌詞ブロックの歌詞を前記表示手段が表示するタイミングを前記再生手段による楽曲の再生に合わせるタイミング調整手段とさらに備える、クレーム２に従属する音楽コンテンツ配信システム。
【請求項４】
前記記憶媒体は複数の楽曲を記憶していて、前記楽曲情報は各楽曲に関連する楽曲情報を含み、
前記サーバは前記楽曲情報に基づいて検索した各楽曲の少なくとも歌詞の歌詞番号のデータを送信し、
前記送信手段は前記各楽曲の歌詞番号のうちの１つを前記サーバへ送信し、
前記サーバはその１つの歌詞番号によって検索した歌詞の歌詞データを送信する、クレーム２または３に従属する音楽コンテンツ配信システム。
【請求項５】
前記表示手段は前記受信手段が受信した前記歌詞番号のデータに基づいて各楽曲の歌詞番号を表示し、
前記表示手段が表示した歌詞番号から前記１つの歌詞番号を選択する歌詞番号選択手段をさらに備える、クレーム４に従属する音楽コンテンツ配信システム。
【請求項６】
前記記憶媒体が前記再生手段に装着されていないときエラーメッセージを発するエラーメッセージ発生手段をさらに備える、クレーム２ないし５のいずれかに従属する音楽コンテンツ配信システム。
【請求項７】
少なくとも歌詞のデータを複数の楽曲の各々について検索可能なサーバにアクセスする歌詞プレイヤであって、
少なくとも１つの楽曲とその楽曲に関連する楽曲情報とを記憶した記憶媒体から前記楽曲情報を読み出す再生手段；
前記楽曲情報を前記サーバへ送信する送信手段；
前記サーバが前記楽曲情報に基づいて検索した前記楽曲の歌詞を表す歌詞データを受信する受信手段；および
前記受信手段によって受信した歌詞データに基づく歌詞を表示する表示手段を備える、歌詞プレイヤ。
【請求項８】
前記記憶媒体は複数の楽曲を記憶していて、前記楽曲情報は各楽曲に関連する楽曲情報を含み、
前記サーバは前記楽曲情報に基づいて検索した各楽曲の少なくとも歌詞の歌詞番号のデータを送信し、
前記送信手段は前記各楽曲の歌詞番号のうちの１つを前記サーバへ送信し、
前記サーバはその１つの歌詞番号によって検索した歌詞の歌詞データを送信する、クレーム７に従属する歌詞プレイヤ。
【請求項９】
複数の楽曲と各楽曲に関連する楽曲情報とを記憶した記憶媒体を再生するユーザ端末によってアクセスされるサーバであって、
前記ユーザ端末によって前記記憶媒体から読み出された前記楽曲情報を受信する手段と、
前記楽曲情報に基づいて、前記記憶媒体に記憶された前記楽曲の歌詞のデータを検索する手段と、
検索した前記歌詞のデータを前記ユーザ端末に送信する手段と、を備えるサーバ。
【請求項１０】
複数の楽曲と各楽曲に関連する楽曲情報とを記憶した記憶媒体を再生するユーザ端末によってアクセスされるサーバ（であって、
前記ユーザ端末によって前記記憶媒体から読み出された前記楽曲情報を受信する手段と、
受信した前記楽曲情報に基づいて、前記記憶媒体を特定する手段と、
特定した前記記憶媒体に記憶された前記各楽曲の名称および前記各楽曲の歌詞番号を取得する手段と、
前記各楽曲の名称および前記各楽曲の歌詞番号を前記ユーザ端末に送信する手段と、を備えるサーバ。
【請求項１１】
複数の楽曲と各楽曲に関連する楽曲情報とを記憶した記憶媒体を再生するユーザ端末によってアクセスされるサーバであって、
前記ユーザ端末が送信した前記楽曲の歌詞番号を受信する手段と、
受信した前記歌詞番号に基づいて検索した前記楽曲の歌詞を表す歌詞データを前記ユーザ端末に送信する手段と、を備えるサーバ。
【請求項１２】
サーバからデータの配信を受ける端末装置であって、
前記データを受信するときに表示手段に所定の背景画像を表示させる背景画像表示手段；および
前記サーバから前記データを受信するとき前記表示手段による表示画像の更新を禁止する更新禁止手段を備える、端末装置。
【請求項１３】
前記サーバからの前記データの受信が完了したとき前記表示画像の更新を許容する更新許容手段をさらに備える、クレーム１２に従属する端末装置。
【請求項１４】
複数の楽曲の楽曲データを配信できるサーバ、およびネットワークを介して前記サーバにアクセスするユーザ端末を含む音楽コンテンツ配信システムであって、
前記ユーザ端末は、
前記サーバからの配信を希望する楽曲を含む楽曲リストを記憶する記憶手段；
前記楽曲リストの中の楽曲の楽曲データの配信を前記サーバに要求する要求手段；
前記サーバから送信される前記楽曲データを記憶する記憶手段；および
前記要求手段の要求に応答して前記サーバから別の楽曲データが送信されたとき、前記別の楽曲データで前記記憶手段を上書きする上書き手段を備える、音楽コンテンツ配信システム。
【請求項１５】
前記ユーザ端末は２以上の楽曲データの前記サーバからの配信を予約する予約手段を含み、前記楽曲リストは前記予約手段によって予約した楽曲を含む予約リストである、クレーム１４に従属する音楽コンテンツ配信システム。
【請求項１６】
前記ユーザ端末は前記予約リストで次に配信されるべき楽曲を自動的に指定する予約リストポインタを含む、クレーム１５に従属する音楽コンテンツ配信システム。
【請求項１７】
前記ユーザ端末は、前記サーバから配信を希望する楽曲を含むＢＧＭリストのリスト番号を前記サーバに送信するＢＧＭリスト番号送信手段；前記ＢＧＭリスト番号に応じて前記サーバから送信されるＢＧＭリストを受信するＢＧＭリスト受信手段を含み、
前記楽曲リストは前記ＢＧＭリスト受信手段によって受信されたＢＧＭリストである、クレーム１４に従属する音楽コンテンツ配信システム。
【請求項１８】
前記ユーザ端末は前記ＢＧＭリストで次に配信されるべき楽曲を自動的に指定するＢＧＭリストポインタを含む、クレーム１７に従属する音楽コンテンツ配信システム。
【請求項１９】
複数の楽曲の楽曲データを配信できるサーバにアクセスする端末装置であって、
前記サーバからの配信を希望する楽曲を含む楽曲リストを記憶する記憶手段；
前記楽曲リストの中の楽曲の楽曲データの配信を前記サーバに要求する要求手段；
前記サーバから送信される前記楽曲データを記憶する記憶手段；および
前記要求手段の要求に応答して前記サーバから別の楽曲データが送信されたとき、前記別の楽曲データで前記記憶手段を上書きする上書き手段を備える、端末装置。
【発明の詳細な説明】
【技術分野】  この発明は、音楽コンテンツ配信システムに関し、特にたとえばネットワークを介して音楽コンテンツをユーザ端末に配信する、音楽コンテンツ配信システムに関する。
【背景技術】  特開平２００１−１０１７８９号公報には、音楽データおよび歌詞データをダウンロードして、ミニディスクに記録することにより、音楽を購入する技術が開示されている。この従来技術では、ミニディスクに記録された音楽データを基に、デレビジョンモニタのスピーカから楽音を出力するとともに、記録された歌詞データを基に、テレビジョンモニタに歌詞を表示する。
特開平２００１−１０１７８９号公報は、ネットワークを介した音楽情報提供サービスの一例であり、これら以外にも、ネットワークを介した様々な音楽情報提供サービスが存在する。
しかしながら、所望のサービスを受けるためには、対応する端末を用意する必要がある。つまり、サービスごとに、異なる端末を用意しなければならない。これでは、ユーザの負担が大きい。
また、家庭用パーソナルコンピュータ（以下、「家庭用ＰＣ」と呼ぶ。）から、各事業者のサーバにアクセスして、各サービスを受けることもできる。しかしながら、家庭用ＰＣは、汎用性が高く、一台で様々な機能を実行できる反面、使えない、あるいは使い難いと感じる人も多い。平成１６年（西暦２００４年）の家庭用ＰＣの普及率が、約６５％程度（日本国内閣府経済社会総合研究所調べ）であることからも、家庭用ＰＣを使えない、あるいは使い難いと感じている人が意外と多いことが推測できる。ちなみに、同研究所によれば、カラーテレビの普及率は、約９９％にもなる。
［発明の概要］
そこで、この発明の主たる目的は、新規な、音楽コンテンツ配信システムを提供することである。
この発明の他の目的は、ユーザが、異なる端末を用意することなく、しかも、簡易に、様々な音楽サービスを受けることができる、音楽コンテンツ配信システムを提供することである。
また、この発明のさらに他の目的は、ユーザが、音楽が記録された記録媒体を購入した後においても、その音楽の歌詞の配信を受けることができる、音楽コンテンツ配信システムを提供することである。
第１の発明によれば、音楽コンテンツ配信システムは、各々が、音楽コンテンツを提供する複数の音楽コンテンツ提供サーバと、ネットワークを通じて前記音楽コンテンツ提供サーバのいずれにもアクセス可能な少なくとも１つのオーディオ／ビジュアル装置と、を備え、前記オーディオ／ビジュアル装置は、前記音楽コンテンツ報提供サーバと交信して、前記音楽コンテンツ提供サーバから音楽コンテンツを受信する通信処理部と、前記通信処理部が受信した前記音楽コンテンツに基づいて、テレビジョン受像機が表示できる形式の映像信号および前記テレビジョン受像機が出力できる形式の音声信号を生成する映像／音声処理部と、プログラムを実行して、前記通信処理部および前記映像／音声処理部を制御する制御部と、前記プログラムを記憶する記憶部と、を含み、前記音楽コンテンツ提供サーバは、前記オーディオ／ビジュアル装置の要求に応じて、前記音楽コンテンツを送信する。
この構成によれば、ユーザは、１つのオーディオ／ビジュアル装置により、異なる音楽サービスを提供する複数の音楽コンテンツ提供サーバにアクセスでき、様々な音楽コンテンツを取得できる。しかも、このオーディオ／ビジュアル装置は、家庭用ＰＣのような汎用的な使用を目的とする情報処理装置でなく、テレビジョン受像機に接続して使用する専用の端末であるため、家庭用ＰＣに比べると使い易く、また、家庭用ＰＣよりも普及率が高く、より身近なテレビジョン受像機を使用するので、家庭用ＰＣに馴染めない人たちにとっても受け入れ易い。
よって、ユーザは、異なる端末を用意することなく、しかも、簡易に、様々な音楽コンテンツ配信を受けることができる。
ここで、音楽コンテンツとは、音楽に関連した情報であり、オーディオデータ、カラオケデータ、音楽に関連した映像データ、歌詞データ、および音楽に関連した内容の文字情報などが含まれる。
また、音楽コンテンツ提供サーバは、オーディオ／ビジュアル装置の要求に応じて、音楽コンテンツを送信するため、つまり、ユーザが要求した時にサービスを提供するため、オンデマンド方式と呼べる。
第２の発明は、少なくとも歌詞のデータを複数の楽曲の各々について検索可能なサーバ、およびネットワークを介してサーバにアクセスするユーザ端末を含む音楽コンテンツ配信システムであって、ユーザ端末は、少なくとも１つの楽曲とその楽曲に関連する楽曲情報とを記憶した記憶媒体から楽曲情報を読み出す再生手段；楽曲情報をネットワークを介してサーバへ送信する送信手段；サーバが楽曲情報に基づいて検索した楽曲の歌詞を表す歌詞データを受信する受信手段；および受信手段によって受信した歌詞データに基づく歌詞を表示する表示手段）を備える、音楽コンテンツ配信システムである。
この第２の発明では、サーバ（２０−１：実施例において相当する部分を例示する参照符号。以下同様。）は、複数の楽曲の歌詞のデータを検索することができる。そして、ユーザ端末（４）はネットワーク（３）を介してサーバにアクセスして、楽曲の歌詞の配信を要求する。たとえばＣＤドライブ（４８３）にＣＤを装着すると、再生手段（４０，４８３，Ｓ６９−Ｓ７３）が、そのＣＤから、ＣＤに記録している楽曲とそれらの楽曲情報たとえばＴＯＣ情報を読み出す。送信手段（４０，４７９，Ｓ７７−Ｓ７９）がその楽曲情報をネットワークを介してサーバ（２０−９）へ送信する。ただし、このサーバ（２０−９）は上のサーバ（２０−１）と同じコンピュータで構成してもよいし、別々のコンピュータで構成するようにしてもよい。送信手段がＴＯＣ情報をサーバ（２０−９）に送信すると、そのサーバ（２０−９）から、たとえばリリック番号がユーザ端末（４）に送信される。そして、ユーザ端末（４）からリリック番号を受信したサーバ（２０−１）は、そのリリック番号で指定される、上記楽曲の歌詞を表す歌詞データをユーザ端末に送信する。ユーザ端末の受信手段（４０，４７９，Ｓ９５）はサーバ（２０−１）から送信される歌詞データを受信し、たとえばＳＲＡＭ（４７１）に記憶する。したがって、表示手段（４０，５−ｎ，Ｓ１０９）が、受信手段によって受信した歌詞データに基づく歌詞を、記憶手段から読み出して表示する。
このように、この第２の発明では、たとえば、ＡＶ装置（４）のＣＤドライブ（４８３）にＣＤを装着すると、そのＣＤのＴＯＣ情報がサーバ（２０−９）に送信され、サーバ（２０−９）でＣＤ内のすべての楽曲のリリック番号が検索され、リストとして、ＡＶ装置４に返送される。ＡＶ装置４でユーザが１つのリリック番号を指定すると、そのリリック番号がサーバ（２０−１）に送信され、サーバ（２０−１）からはそのリリック番号で示される楽曲の歌詞（リリック）のデータがＡＶ装置４に送られてくる。したがって、ＡＶ装置（４）はそのリリックデータに従って、たとえば図１６のリリックプレイヤ表示画面（４９１）のように、楽曲の歌詞を表示器（５−ｎ）に表示することができる。
ただし、このとき、歌詞データは、複数のブロックに区分けされた歌詞ブロックと歌詞ブロック毎にその歌詞ブロックの歌詞を表示すべき時間を表すブロック開始時間のデータを含む。したがって、再生手段（４０，４８３，Ｓ９７）が記憶媒体の楽曲を再生するとき、タイミング調整手段（４０，Ｓ９９−Ｓ１１１）によって、ブロック開始時間に基づいて、歌詞ブロックの歌詞を表示するタイミングを楽曲の再生に同期させることができる。
また、サーバ（２０−９）から送られる各楽曲の歌詞番号が表示手段に表示されるので、ユーザはたとえばカーソルを移動させるなどして、そのうちの１つの歌詞番号を選択し、その歌詞番号がサーバ（２０−１）に送られるので、サーバ（２０−１）はその歌詞番号で示される歌詞の歌詞データをユーザ端末に返送する。
さらに、上述のような歌詞配信を受けるモードにおいて、記憶媒体が再生手段に装着されていないときには、エラーメッセージ発生手段（４０，Ｓ５９−Ｓ６５）によって、たとえば「ＣＤが装着されていません」のようなエラーメッセージを発するようにしてもよい。
第３の発明は、少なくとも歌詞のデータを複数の楽曲の各々について検索可能なサーバにアクセスする歌詞プレイヤであって、少なくとも１つの楽曲とその楽曲に関連する楽曲情報とを記憶した記憶媒体から楽曲情報を読み出す再生手段；楽曲情報をサーバへ送信する送信手段；サーバが楽曲情報に基づいて検索した楽曲の歌詞を表す歌詞データを受信する受信手段；および受信手段によって受信した歌詞データに基づく歌詞を表示する表示手段を備える、歌詞プレイヤである。
第３の発明では、サーバ（２０−１）は、複数の楽曲の歌詞のデータを検索することができる。そして、歌詞プレイヤ（４）はたとえばネットワーク（３）を介してサーバにアクセスして、楽曲の歌詞の配信を要求する。たとえばＣＤドライブ（４８３）にＣＤを装着すると、再生手段（４０，４８３，Ｓ６９−Ｓ７３）が、そのＣＤから、ＣＤに記録している楽曲とそれらの楽曲情報たとえばＴＯＣ情報を読み出す。送信手段（４０，４７９，Ｓ７７−Ｓ７９）がその楽曲情報をネットワークを介してサーバ（２０−９）へ送信する。ただし、このサーバ（２０−９）は上のサーバ（２０−１）と同じコンピュータで構成してもよいし、別々のコンピュータで構成するようにしてもよい。送信手段がＴＯＣ情報をサーバ（２０−９）に送信すると、そのサーバ（２０−９）から、たとえばリリック番号が歌詞プレイヤ（４）に送信される。そして、歌詞プレイヤ（４）からリリック番号を受信したサーバ（２０−１）は、そのリリック番号で指定される、上記楽曲の歌詞を表す歌詞データをユーザ端末に送信する。ユーザ端末の受信手段（４０，４７９，Ｓ９５）はサーバ（２０−１）から送信される歌詞データを受信し、たとえばＳＲＡＭ（４７１）に記憶する。したがって、表示手段（４０，５−ｎ，Ｓ１０９）が、受信手段によって受信した歌詞データに基づく歌詞を、記憶手段から読み出して表示する。
第３の発明でも、歌詞プレイヤは、サーバからは受信した歌詞（リリック）のデータに従って、その歌詞を表示器に表示することができる。
第３の発明の好ましい実施例では、記憶媒体が複数の楽曲を記憶していて、楽曲情報も各楽曲に関連する楽曲情報を含む。この場合、サーバは楽曲情報に基づいて検索した各楽曲の少なくとも歌詞の歌詞番号のデータを送信し、送信手段は各楽曲の歌詞番号のうちの１つをサーバへ送信し、サーバはその１つの歌詞番号によって検索した歌詞の歌詞データを送信することになる。
第４の発明は、複数の楽曲と各楽曲に関連する楽曲情報とを記憶した記憶媒体を再生するユーザ端末によってアクセスされるサーバであって、ユーザ端末によって記憶媒体から読み出された楽曲情報を受信する手段と、楽曲情報に基づいて、記憶媒体に記憶された楽曲の歌詞のデータを検索する手段と、検索した歌詞のデータをユーザ端末に送信する手段と、を備えるサーバである。
第４の発明では、サーバ（２０−１，２０−９）はユーザ端末（４）から、そのユーザ端末が記憶媒体たとえばＣＤから読み出した楽曲情報を受信し、その楽曲情報に基づいて検索した歌詞をそのユーザ端末に返送する。
第５の発明は、複数の楽曲と各楽曲に関連する楽曲情報とを記憶した記憶媒体を再生するユーザ端末によってアクセスされるサーバであって、ユーザ端末によって記憶媒体から読み出された楽曲情報を受信する手段と、受信した楽曲情報に基づいて、記憶媒体を特定する手段と、特定した記憶媒体に記憶された各楽曲の名称および各楽曲の歌詞番号を取得する手段と、各楽曲の名称および各楽曲の歌詞番号をユーザ端末に送信する手段と、を備えるサーバである。
第５の発明では、サーバ（２０−９）はユーザ端末（４）から、そのユーザ端末が記憶媒体たとえばＣＤから読み出した楽曲情報を受信し、その楽曲情報に基づいてその記憶媒体、たとえばＣＤを特定し、特定したに記憶されている楽曲の曲名や歌詞番号を取得し、それらをユーザ端末に返送する。したがって、ユーザ端末はその記憶媒体の中の各楽曲の歌詞番号を知ることができる。
第６の発明は、複数の楽曲と各楽曲に関連する楽曲情報とを記憶した記憶媒体を再生するユーザ端末によってアクセスされるサーバであって、ユーザ端末が送信した楽曲の歌詞番号を受信する手段と、受信した歌詞番号に基づいて検索した楽曲の歌詞を表す歌詞データをユーザ端末に送信する手段と、を備えるサーバである。
第６の発明では、サーバ（２０−１）はユーザ端末（４）から、そのユーザ端末が送信した歌詞番号に基づいて検索した歌詞をそのユーザ端末に返送する。
第７の発明は、サーバからデータの配信を受ける端末装置であって、データを受信するときに表示手段に所定の背景画像を表示させる背景画像表示手段；およびサーバからデータを受信するとき表示手段による表示画像の更新を禁止する更新禁止手段を備える、端末装置である。
第７の発明では、端末装置（４）は、サーバ（２０−１）からデータ（たとえばカラオケデータ）の配信を受ける。背景画像表示手段（４０，Ｓ１９９）は、サーバからデータを受信するときに所定の背景画像（たとえば少ない能力で表示可能な背景画像）を表示手段（５−ｎ）に表示させるとともに、サーバからデータを受信するとき、更新禁止手段（４０，Ｓ１９１）によって表示手段による表示画像の更新を禁止する。一例として、ラスタスキャン表示器の場合、一般にＶブランキング期間に表示を更新するので、更新禁止手段は、そのＶブランキング期間の割り込みを禁止する。
したがって、表示処理に割り振るプロセサ（４０）の能力を極力少なくして、より多くの能力をたとえばＬＡＮコントローラ（４７９）からのデータ取得処理に割くことにより、データ量の大きいデータをサーバから取得し、そのような大量のデータを処理しなければならない場合でも、必要最小限の能力を有するプロセサによって、必要な時間内にデータ量の大きいデータの処理が可能となる。
ただし、サーバからのデータの受信が完了したとき更新許容手段（４０，Ｓ１９９）によって、表示画像の更新を許容するようにすればよい。
第８の発明は、複数の楽曲の楽曲データを配信できるサーバ、およびネットワーク介してサーバにアクセスするユーザ端末を含む音楽コンテンツ配信システムであって、ユーザ端末は、サーバからの配信を希望する楽曲を含む楽曲リストを記憶する記憶手段；楽曲リストの中の楽曲の楽曲データの配信をサーバに要求する要求手段；サーバから送信される楽曲データを記憶する記憶手段；および要求手段の要求に応答してサーバから別の楽曲データが送信されたとき、別の楽曲データで記憶手段を上書きする上書き手段を備える、音楽コンテンツ配信システムである。
第８の発明では、サーバ（２０−１）は、ネットワーク（３）を介してアクセスしてくるユーザ端末（４）に、楽曲データ（たとえばカラオケデータ）を配信できる。ユーザ端末の記憶手段（４７１）は、サーバからの配信を希望する楽曲を含む楽曲リストを記憶し、要求手段（４０，Ｓ１９３−Ｓ１９５）が、その楽曲リストの中の楽曲の楽曲データの配信をサーバに要求する。したがって、サーバからユーザ端末には、その要求手段が要求した楽曲データを送信する。ユーザ端末の記憶手段（４０，４７１，Ｓ１９５）は、そのサーバから送信される楽曲データを記憶するが、サーバから別の楽曲データが送信されたとき、上書き手段（４０，Ｓ１９５）は、再生した楽曲データを消去するように、別の楽曲データで記憶手段を上書きする。
このように、たとえば１曲の楽曲データをユーザ端末にダウンロードし、ユーザ端末では、その１曲の楽曲データをたとえばＳＲＡＭ（４７１）に格納し、１曲再生し、その後、次の１曲をダウンロードし、その１曲をＳＲＡＭに上書きし、その１曲を再生する、…、というように、ユーザ端末すなわちＡＶ装置（４）には、常に１曲分のカラオケデータしか格納されない。このため、ＡＶ装置（４）に搭載する記憶手段（実施例ではＳＲＡＭ４７１）の記憶容量を小さくできる。
上述の楽曲リストは、たとえば、カラオケモードでは、予約手段（４０，Ｓ１５９−Ｓ１７９）によって予約した楽曲を含む予約リストであり、あるいは、ＢＧＭモードでは、ＢＧＭリスト受信手段（４０，Ｓ１２７）によってサーバから受信した、ＢＧＭリストである。
いずれのリストも、ポインタによって、次の楽曲を自動的に指定または選択することができる。
第９の発明は、複数の楽曲の楽曲データを配信できるサーバにアクセスする端末装置であって、サーバからの配信を希望する楽曲を含む楽曲リストを記憶する記憶手段；楽曲リストの中の楽曲の楽曲データの配信をサーバに要求する要求手段；サーバから送信される楽曲データを記憶する記憶手段；および要求手段の要求に応答してサーバから別の楽曲データが送信されたとき、別の楽曲データで記憶手段を上書きする上書き手段を備える、端末装置である。
第９の発明では、端末装置（４）の記憶手段（４７１）は、サーバからの配信を希望する楽曲を含む楽曲リストを記憶し、要求手段（４０，Ｓ１９３−Ｓ１９５）が、その楽曲リストの中の楽曲の楽曲データの配信をサーバに要求する。したがって、サーバからユーザ端末には、その要求手段が要求した楽曲データを送信する。ユーザ端末の記憶手段（４０，４７１，Ｓ１９５）は、そのサーバから送信される楽曲データを記憶するが、サーバから別の楽曲データが送信されたとき、上書き手段（４０，Ｓ１９５）は、再生した楽曲データを消去するように、別の楽曲データで記憶手段を上書きする。したがって、端末装置（４）には、常に１曲分の楽曲データしか格納されない。このため、ＡＶ装置（４）に搭載する記憶手段（４７１）の記憶容量を小さくできる。
この発明の上述の目的，その他の目的，特徴，および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。
【図面の簡単な説明】  図１はこの発明の一実施例の音楽コンテンツ配信システムの全体構成を示すブロック図である。
図２は図１実施例での音楽資産管理システムを示す図解図である。
図３は図１実施例でのオーディオ／ビジュアル装置（ＡＶ装置）の内部構成を示すブロック図である。
図４は図１実施例で利用できるＡＶ装置の内部構造の一部を詳細に示すブロック図である。
図５はそのＡＶ装置の内部構造の残りの一部を詳細に示すブロック図である。
図６は図５に示すフラッシュメモリの構成の一例を示す図解図である。
図７は図５に示すリモコン用赤外線受信機に赤外線リモコン信号を送信するリモコン送信機の一例を示す図解図である。
図８は図１実施例における図４および図５に示すＡＶ装置の動作を示すメインフロー図である。
図９はＴＣＰ／ＩＰ送受信処理の動作を示すフロー図である。
図１０はメインメニュー表示画面の一例を示す図解図である。
図１１はリリックプレイヤモードの動作の一部を示すフロー図である。
図１２はリリックプレイヤモードの図１０に後続する一部を示すフロー図である。
図１３はリリックプレイヤモードでのエラーメッセージ表示画面の一例を示す図解図である。
図１４はリリックプレイヤモードでの曲リスト表示画面の一例を示す図解図である。
図１５はリリックプレイヤモードでのリリックデータ構成の一例を示す図解図である。
図１６はリリックプレイヤモードでのリリックプレイヤ表示画面の一例を示す図解図である。
図１７はＢＧＭモードの動作を示すフロー図である。
図１８は図１７実施例におけるＢＧＭメニュー表示画面の一例を示す図解図である。
図１９は図１７実施例におけるＢＧＭリストデータの一例を示す図解図である。
図２０は図１７実施例におけるＢＧＭリストデータの他の例を示す図解図である。
図２１は図１７実施例におけるカラオケデータの一例を示す図解図である。
図２２はカラオケモードの動作の一部を示すフロー図である。
図２３はカラオケモードの動作の図２２に後続する他の一部を示すフロー図である。
図２４はカラオケモードでのカラオケ検索方法表示画面の一例を示す図解図である。
図２５はカラオケモードでの番号入力画面の一例を示す図解図であり、図２５（Ａ）は５桁のカラオケ番号がすべて入力されたときのカラオケ番号入力画面を示し、図２５（Ｂ）は１桁目のカラオケ番号が入力されたときのカラオケ番号入力画面を示し、図２５（Ｃ）は４桁目のカラオケ番号が入力されたときのカラオケ番号入力画面を示す。
【発明を実施するための最良の形態】  以下、この発明の実施の形態について、図面を参照しながら説明する。なお、図中、同一または相当部分については同一の参照符号を付してその説明を援用する。
図１は、この発明の実施の形態による音楽コンテンツ配信システム１の全体構成を示すブロック図である。図１に示すように、この音楽コンテンツ配信システム１は、音楽資産管理システム２、ネットワーク３、オーディオ／ビジュアル装置（以下、「ＡＶ装置」と呼ぶ。）４−ｎ（ｎは１以上の整数）、およびテレビジョン受像機（以下、「ＴＶ」と呼ぶ。）５−ｎ（ｎは１以上の整数）を含む。
音楽資産管理システム２およびＡＶ装置４−ｎは、それぞれネットワーク３に接続されており、互いに通信することができる。ネットワーク３は、たとえば、インタネットやＬＡＮなどである。ＡＶ装置４−ｎは、ＴＶ５−ｎと接続される。
音楽資産管理システム２は、様々な音楽資産を、デジタルデータおよび／またはアナログデータとして管理しており、ＡＶ装置４−ｎによるネットワーク３を介した要求に応じて、管理している音楽資産の中から適切な音楽情報を、要求を出したＡＶ装置４−ｎに送信する。ＡＶ装置４−ｎは、音楽資産管理システム２から受信した音楽情報に応じた映像（たとえば、ＮＴＳＣ信号やＰＡＬ信号など）および／または音声（アナログ）をＴＶ５−ｎに出力する。これにより、ＴＶ５−ｎには、音楽資産管理システム２から送信された音楽情報に応じた映像が映し出されるとともに、そのスピーカ（図示せず）からは、その音楽情報に応じた音声が出力される。
図２は、図１の音楽資産管理システム２の説明図である。図２に示すように、音楽資産管理システム２は、カラオケサーバ２０−１、歌詞サーバ２０−２、楽曲サーバ２０−３、音楽ゲームサーバ２０−４、音楽レッスンサーバ２０−５、音楽関連情報サーバ２０−６、音楽メディア購入サーバ２０−７、音楽コミュニティサーバ２０−８、およびＣＤデータベースサーバ２０−９を含む。ただし、音楽資産管理システム２には、新たに追加される音楽資産およびサービスに応じて、必要なサーバが追加される。ＣＤデータベースサーバ２０−９は既に日本で販売されたすべてのＣＤのＴＯＣ（Ｔａｂｌｅ  ｏｆ  Ｃｏｎｔｅｎｔｓ）情報からそのＣＤに録音されている曲のリリック（歌詞）番号を検索できるサーバである。このＣＤデータベースサーバ２０−９は後述のリリックプレイヤモード（歌詞配信モード）でカラオケサーバ２０−１と共に使われる。この場合、カラオケサーバ２０−１がＣＤデータベースサーバ２０−９を取り込む形でまたは、逆にＣＤデータベースサーバ２０−９がカラオケサーバ２０−１を取り込む形で、両者が１つのサーバとして構成されてもよい。
なお、音楽資産管理システム２を構成する各サーバを区別しないときは、「音楽サーバ２０−ｋ（ｋは１以上の整数）」と表記する。各音楽サーバ２０−ｋにより提供されるサービスは後述する。つまり、音楽資産管理システム２は、究極的には、多数の機能を有する１つのサーバだけで構成されてもよい。したがって、場合によっては、各サーバを区別することなく単に「サーバ」と呼ぶこともある。
図３は、図１のＡＶ装置４−ｎの内部構成を示すブロック図である。図３に示すように、ＡＶ装置４−ｎは、制御部４０、映像／音声処理部５０、記憶部５１、および通信処理部４６を含む。映像／音声処理部５０は、映像処理部４１、音声処理部４２、および光ディスクドライブ４３を含む。記憶部５１は、メモリ４４およびハードディスクドライブ（以下、「ＨＤＤ」と呼ぶ。）４５を含む。
制御部４０は、ＨＤＤ４５に格納されたプログラムに従って、各機能ブロック４１〜４６を制御する。メモリ４４は、制御部４０のワーク領域、バッファリング領域、およびフラグ領域等として使用される。ＨＤＤ４６は、大容量の記憶装置であり、各種プログラムおよびデータが格納される。
映像処理部４１は、映像データを圧縮および伸長する映像コーデック、Ｄ／Ａコンバータ、およびメモリ等を備え、生成した映像信号ＶＤをＴＶ５−ｎに送信する。音声処理部４２は、音声データを圧縮および伸長する音声コーデック、Ｄ／Ａコンバータ、およびメモリ等を備え、生成した音声信号ＡＵをＴＶ５−ｎに与える。
光ディスクドライブ４３は、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ）およびＣＤ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ）の再生／記録を行うものであり、光ピックアップ、サーボ機構、および信号処理部等を備える。
通信処理部４６は、ネットワーク３に接続してデータの送受信を行うための通信ユニット、ワイヤレスマイク６からの信号を増幅／復調するＲＦ（Ｒａｄｉｏ  Ｆｒｅｑｕｅｎｃｙ）レシーバ、接続されたＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）機器７を制御するＵＳＢコントローラ、およびＩＲ（Ｉｎｆｒａｒｅｄ）機器８から赤外線信号を受信して復調するＩＲレシーバ等を備える。ＵＳＢ機器は、たとえば、プリンタや携帯型の音楽用ハードディスクレコーダ等である。ＩＲ機器は、たとえば、赤外線リモコンや音楽ゲームを行うためのコントローラ等である。
［カラオケ配信］
図２に戻って、カラオケサーバ２０−１は、多数の楽曲のカラオケデータを蓄積しており、ＡＶ装置４−ｎからの要求に応じて、カラオケデータをストリーミング送信する。カラオケデータは、オーディオデータ、映像データ、および歌詞データを含む。オーディオデータは、ＭＩＤＩ（Ｍｕｓｉｃａｌ  Ｉｎｓｔｒｕｍｅｎｔ  Ｄｉｇｉｔａｌ  Ｉｎｔｅｒｆａｃｅ）データのような楽譜データ（制御データ）ではなく、ＰＣＭ（Ｐｕｌｓｅ  Ｃｏｄｅｄ  Ｍｏｄｕｌａｔｉｏｎ）データのようなサンプリングして得られた音声波形データである。本明細書および特許請求の範囲において、オーディオデータというときは、このような音声波形データを意味する。歌詞データには、文字コードの他、表示制御情報（各文字を表示・消去するタイミングおよびワイプ時間を示す情報）が含まれる。
図３の通信処理部４６は、カラオケサーバ２０−１からのカラオケデータを受信して、映像データを映像処理部４１へ、オーディオデータを音声処理部４２へ、歌詞データを制御部４０へ、渡す。また、通信処理部４６は、ワイヤレスマイク６からの音声信号を音声処理部４２へ出力する。
音声処理部４２は、オーディオデータのバッファリングを行いながら、伸長処理を施し、ワイヤレスマイク６からの音声信号と合成し、音声信号ＡＵとして、ＴＶ５−ｎに出力する。制御部４０は、歌詞データを基に文字画像を生成し、表示制御情報にしたがって、その文字画像を映像処理部４１へ渡す。映像処理部４１は、映像データのバッファリングを行いながら、伸長処理を施し、制御部４０から与えられた文字画像と合成し、映像信号ＶＤとしてＴＶ５−ｎに送信する。このようにして、カラオケデータのストリーミング再生が行われる。
ここで、データ配信の２つの方式を説明する。１つは、上記のようなストリーミング方式であり、ストリーミング送信されたデータを逐次受信しながらリアルタイムに再生する方式である。この方式では、再生後は、ＡＶ装置４−ｎにデータは残らない。もう１つの方式は、ダウンロード方式であり、送信される全データをＨＤＤ４５等の記憶装置に格納し、その後再生する。この方式では、再生後でも、ＡＶ装置４−ｎにデータが残る。ただし、再生後に、ＡＶ装置４−ｎにデータが残らないように消去することもできる。
以上のように、ストリーミング方式によりカラオケの配信を行うので、支払うべき著作権料が安価になるばかりでなく、ＨＤＤ４５の容量を抑えることができるため、安価なＡＶ装置４−ｎを提供できる。業務用の通信カラオケ装置のように、ダウンロード方式および蓄積型を採用している場合は、より大容量のハードディスクが必要になり、高価なものとなる。したがって、ストリーミング方式は、家庭向きと言うことができる。ストリーミング方式では、ＨＤＤ４５は、必ずしも必要ない。また、ＭＩＤＩデータではなく、オーディオデータを送信しているので、より高品質な（音質の良い）音楽を提供できる。
［歌詞配信］
ユーザからの入力情報を受けた制御部４０は、セットされた音楽ＣＤに記録されたＴＯＣ情報を光ディスクドライブ４３から取得する。そして、制御部４０は歌詞サーバ２０−２に向けて、ＴＯＣ情報を通信処理部４６に送信させる。ＴＯＣ情報は、曲数や曲ごとの時間情報等からなるデータである。歌詞サーバ２０−２は、数多くの音楽ＣＤのタイトル、アーティスト名、および歌詞データなどを蓄積しており、このＴＯＣ情報により音楽ＣＤを特定して、対応する歌詞データをＡＶ装置４−ｎに送信する。
この歌詞データには、文字コードの他、表示制御情報（各文字を表示・消去するタイミングを示す情報）が含まれる。この場合、音楽ＣＤの歌詞カードに印刷された写真や絵図などの画像データ、およびタイトルやアーティスト名などのデータを送信することもできる。また、曲がリリースされた年のトピック等の情報（映像や文字）を送信することもできる。
制御部４０は、通信処理部４６が受信した歌詞データを、メモリ４４あるいはＨＤＤ４５に格納する。そして、制御部４０は、その歌詞データに基づいて文字画像を生成し、表示制御情報に従って、映像処理部４１へ出力する。映像処理部４１は、入力された文字画像に応じた映像信号ＶＤを生成して、ＴＶ５−ｎに出力する。一方、制御部４０は、光ディスクドライブ４３に、音楽ＣＤから音楽データ（つまり音声波形データ）を読み出すように指示する。読み出されたデータは、音声処理部４２に与えられ、必要な処理が施され、音声信号ＡＵとして、ＴＶ５−ｎに出力される。以上のようにして、ＴＶ５−ｎのスピーカから音楽が出力されるとともに、音楽に同期して、歌詞がＴＶ５−ｎに表示される。なお、受信した歌詞データは、メモリ４４およびＨＤＤ４５から消去される。
以上のように、歌詞がＴＶ５−ｎに表示されるので、歌詞カードで歌詞を見るより、より見やすい。歌詞カードのサイズは、ＣＤケースのサイズによって決まってしまい、それ故、歌詞カードに印刷される歌詞は、文字が小さく読み難い。また、歌詞カードを紛失してしまう場合もある。本実施の形態では、ユーザは、音楽ＣＤを購入した後においても、その音楽の歌詞の配信を受けることができる。
なお、後述の実施例では、歌詞配信は、ＣＤデータベースサーバ２０−９とカラオケサーバ２０−１とを利用して行われる。
［楽曲配信］
楽曲サーバ２０−３は、多数の楽曲のオーディオデータを蓄積しており、ＡＶ装置４−ｎからの要求に応じて、オーディオデータを配信する。この場合、ＡＶ装置４−ｎからは、ストリーミング方式による配信あるいはダウンロード方式による配信のいずれかを示す選択情報が送信されるため、楽曲サーバ２０−３は、選択情報が示す方式で、オーディオデータを送信する。ダウンロード方式により配信されたオーディオデータは、一旦ＨＤＤ４５に格納され、音声処理部４２により伸長処理およびその他の必要な処理が施され、光ディスクドライブ４３により、ＣＤやＤＶＤに記録したり、あるいは、ＵＳＢ機器７としての携帯型の音楽用ハードディスクレコーダ等に記録できる。ただし、ＨＤＤ４５に格納後、他の記録媒体あるいは記憶装置に記録した場合は、ＨＤＤ４５からオーディオデータは消去される。なお、ＡＶ装置４−ｎは、曲ごと、あるいはアルバムごとに、ダウンロード方式による配信を要求できる。
一方、ストリーミング方式により配信されたオーディオデータは、上記したカラオケのオーディオデータと同様にして、音声処理部４２によりストリーミング再生され、ＴＶ５−ｎに出力される。なお、ＡＶ装置４−ｎは、曲ごと、あるいはアルバムごとに、ストリーミング方式による配信を要求できる。また、ジャンルごと、あるいはテーマごとに曲を用意し、ＡＶ装置４−ｎが要求するジャンルやテーマの曲を配信することもできる。
［音楽ゲーム配信］
音楽ゲームサーバ２０−４は、ＡＶ装置４−ｎの要求に応じて、ゲームプログラムおよび必要なデータをＡＶ装置４−ｎに送信する。制御部４０は、通信処理部４６が受信したゲームプログラム等をＨＤＤ４５に格納する。そして、制御部４０は、そのゲームプログラムを実行して、ゲーム画面を表す映像信号ＶＤおよびゲーム音楽や効果音を表す音声信号ＡＵをＴＶ５−ｎに出力する。
また、音楽ゲームサーバ２０−４上でゲームプログラムを動かして、ネットワーク３を介して、テレビゲームを行うようにすることもできる（オンラインゲーム）。この場合、各ＡＶ装置４−ｎのユーザ同士で協力／対戦／競争を行うオンラインゲームの提供もできる。
［音楽レッスン］
音楽レッスンサーバ２０−５は、ＡＶ装置４−ｎの要求に応じて、音楽レッスンのためのデータをＡＶ装置４−ｎに送信する。たとえば、音楽レッスンサーバ２０−５は、洋楽のオーディオデータとともに、原語の歌詞およびその対訳を、ＡＶ装置４−ｎにストリーミング配信する。また、たとえば、音楽レッスンサーバ２０−５は、楽器練習用の楽譜を表す画像データ、および練習用の伴奏のためのオーディオデータ、並びに手本となる演奏のオーディオデータを、ＡＶ装置４−ｎにストリーミング配信する。以上の場合、カラオケの場合と同様にして、映像信号ＶＤおよび音声信号ＡＵが生成され、ＴＶ５−ｎに出力される。また、ＵＳＢ機器７として、カメラを接続し、ネットワーク３を介して、音楽レッスンを受けることができるようにすることもできる。
［音楽関連情報提供］
音楽関連情報サーバ２０−６は、ＡＶ装置４−ｎの要求に応じて、音楽関連情報をＡＶ装置４−ｎに送信する。音楽関連情報は、たとえば、アーティスト情報、音楽ランキング情報、コンサート情報、およびジャンル別音楽ガイド情報など、音楽に関連する様々な情報である。通信処理部４６が受信した音楽関連情報に基づいて、映像処理部４１および音声処理部４２で、映像信号ＶＤおよび音声信号ＡＵが生成され、ＴＶ５−ｎに出力される。
［音楽メディア購入］
音楽メディア購入サーバ２０−７は、ＡＶ装置４−ｎの要求に応じて、ＣＤやＤＶＤ等の音楽メディアや映像メディアの購入手続きを行う。
［音楽コミュニティ］
音楽コミュニティサーバ２０−８は、オンラインカラオケサービスや楽曲発表サービスなどを提供する。オンラインカラオケサービスでは、各ＡＶ装置４−ｎのユーザが集まって、カラオケを行うことができる。たとえば、ＡＶ装置４−１，４−２および４−３のユーザがオンラインカラオケに参加したとする。ＡＶ装置４−１にカラオケデータがストリーミング配信された場合、ＡＶ装置４−１のユーザが、ワイヤレスマイク６を用いて歌う。すると、映像信号ＶＤおよび音声信号ＡＵは、ＴＶ５−１に出力されるとともに、圧縮されて、ネットワーク３を介して、他の参加者のＡＶ装置４−２および４−３にストリーミング配信される。そして、ＡＶ装置４−２および４−３では、それらのデータがストリーミング再生される。
楽曲発表サービスでは、ＡＶ装置４−ｎから音楽コミュニティサーバ２０−８に、オーディオデータあるいはＭＩＤＩデータをアップロードする。アップロード対象のこれらのデータは、光ディスクドライブ４３あるいはＵＳＢ機器７などから、ＨＤＤ４５に取り込まれ、音声処理部４２で圧縮されて、通信処理部４６により、音楽コミュニティサーバ２０−８に送信される。アップロードされたオーディオデータあるいはＭＩＤＩデータに基づく音楽は、たとえば、第三者（専門家や他のＡＶ装置４−ｎのユーザ等）から評価され、その評価情報が、音楽コミュニティサーバ２０−８から、ＡＶ装置４−ｎに送信される。映像処理部４１は、その評価情報に応じた映像信号ＶＤを生成して、ＴＶ５−ｎに出力する。
また、音楽コミュニティサーバ２０−８にアップロードされたオーディオデータは、他のＡＶ装置４−ｎの要求に応じて、そのＡＶ装置４−ｎにストリーミング配信され、必要な処理が施されて、音声信号ＡＵとして、ＴＶ５−ｎに出力される。また、音楽コミュニティサーバ２０−８にアップロードされたＭＩＤＩデータが他のＡＶ装置４−ｎに送信される場合は、ＡＶ装置４−ｎは、音源を有している必要があり、ＭＩＤＩデータおよび音源に基づき、音声信号ＡＵが生成される。
さて、以上のように、本実施の形態によれば、ユーザは、１つのＡＶ装置４−ｎにより、異なる音楽サービスを提供する複数の音楽サーバ２０−ｋにアクセスでき、様々な音楽情報を取得できる。しかも、このＡＶ装置４−ｎは、家庭用ＰＣのような汎用的な使用を目的とする情報処理装置でなく、ＴＶ５−ｎに接続して使用する専用の端末であるため、家庭用ＰＣに比べると使い易く、また、家庭用ＰＣよりも普及率が高く、より身近なＴＶ５−ｎを使用するので、家庭用ＰＣに馴染めない人たちにとっても受け入れ易い。よって、ユーザは、異なる端末を用意することなく、しかも、簡易に、様々な音楽サービスを受けることができる。
また、本実施の形態では、ＡＶ装置４−ｎに、音楽ＣＤをセットすることにより、音楽を再生しながら、対応する歌詞をＴＶ５−ｎに表示できる。このように、ユーザが、音楽ＣＤを購入した後においても、その音楽の歌詞を取得できる（上記のように一時的な場合も含む。）。上記では、ＴＶ５−ｎに歌詞を表示した後、ＡＶ装置４−ｎから歌詞データを消去したが、消去せずに、ＨＤＤ４５に残しておくこともできる。
以上で図１に示すこの発明の一実施例の音楽コンテンツ配信システム１について説明した。次に、図４以降の図面を参照して、この発明の他の好ましい実施例を説明する。
図４および図５は他の好ましい実施例に用いられるＡＶ装置４を示すブロック図である。この実施例のＡＶ装置４では１つの制御部すなわちプロセサ４０が用いられるが、全体を図４と図５とに２分した関係で、便宜的に、図４および図５の両方にプロセサ４０を図示したことに留意されたい。
図４を参照して、ＡＶ装置４は３つのレギュレータ４０１，４０３および４０５を含み、プロセサ４０には、２つのレギュレータ４０３および４０５から２つの電源電圧が印加される。まず、レギュレータ４０１が電源アダプタ（図示せず）から６Ｖの直流電源を受け、その６Ｖを電圧調整して、５．０Ｖとする。レギュレータ４０３がレギュレータ４０１からの５．０Ｖを受け、その５．０Ｖを電圧調整して３．３Ｖとし、３．３Ｖの直流電源をプロセサ４０に供給するとともに、それをレギュレータ４０５が電圧調整して１．５Ｖの直流電源をプロセサ４０に供給する。ただし、このような直流電源の数や具体的な電圧値は単なる例示であることは、当然である。
この実施例のＡＶ装置４も先の実施例と同様にカラオケが利用できる。そのために、プロセサ４０には４つのマイク入力ポートＡＩＮ０，ＡＩＮ１，ＡＩＮ２およびＡＩＮ３が設けられる。この実施例では、マイク入力ポートＡＩＮ０およびＡＩＮ１は、それぞれがピンジャックおよびピンプラグの組み合わせ（図示せず）で接続された、リアマイク４０７および４０９からの入力信号を受ける。マイク入力ポートＡＩＮ２およびＡＩＮ３は、それぞれが３．５Φジャックおよび３．５Φプラグの組み合わせ（図示せず）で接続された、フロントマイク４１１および４１３からの入力信号を受ける。
詳しく説明すると、リアマイク４０７からのマイク信号は、縦続接続されたマイクアンプ４１５および４１７で増幅された後、マイク入力ポートＡＩＮ０に入力される。同様に、リアマイク４０９からのマイク信号は、マイクアンプ４１９および４２１で増幅された後、マイク入力ポートＡＩＮ１に入力される。フロントマイク４１１からのマイク信号は、マイクアンプ４２３および４２５で増幅された後、マイク入力ポートＡＩＮ２に入力される。フロントマイク４１３からのマイク信号は、マイクアンプ４２７および４２９で増幅された後、マイク入力ポートＡＩＮ３に入力される。
マイク入力ポートＡＩＮ０〜ＡＩＮ３に入力されたマイク信号は、プロセサ４０内部で、デジタル信号に変換され、後述の採点処理に利用される。
１段目のマイクアンプ４１５，４１９，４２３および４２７を経た各マイク４０７，４０９，４１１および４１３からのマイク信号はそれぞれ分岐されて、スイッチ４３１，４３３，４３５および４３７およびアンプ４３９，４４１，４４３および４４５を介して、マイクミキサ４４７に入力される。リアマイク４０７および４０９ためのスイッチ４３１および４３３は、プロセサ４０からの３ビットの制御信号ＡＳＷ１４−１６およびＡＳＷ１１−１３によって制御され、フロントマイク４１１および４１３のためのスイッチ４３５および４３７はプロセサ４０からの１ビットの制御信号ＡＳＷ２およびＡＳＷ１でオンまたはオフされる。
スイッチ４３１および４３３がオンされると、このスイッチ４３１および４３３を通してリアマイク４０７および４０９のマイク信号は、それぞれ、アンプ４３９および４４１を経て、マイクミキサ４４７に入力される。スイッチ４３５および４３７がオンされると、このスイッチ４３５および４３７を通してフロントマイク４１１および４１３のマイク信号が、それぞれ、アンプ４４３および４４５を経て、マイクミキサ４４７に入力される。ただし、アンプ４４５および４４３はそれぞれボリューム制御信号ＶＯＬ１およびＶＯＬ２によって増幅度が制御されるので、結果的に、フロントマイク４１１および４１３からのマイク信号はボリューム調整されてマイクミキサ４４７に入力される。
マイクミキサ４４７では、最大４つのマイク信号を混合する。マイクミキサ４４７で混合したマイク信号は、エコーアンプ４４９を通して、ミキサ４０３に入力される。このミキサ４０３は、マイク４０７，４０９，４１１および４１３から入力されたマイク信号と、プロセサ４０から出力される音楽音声とを混合する。ただし、音楽音声にはカラオケ音楽音声だけではなく、ＢＧＭ音楽音声が含まれるが、ミキサ４０３でマイク信号と混合されるのはカラオケ音楽音声であり、ＢＧＭ音楽音声はマイク信号と混合されることなくそのままミキサ４０３から出力される。
カラオケ音楽音声およびＢＧＭ音楽音声は、いずれも、プロセサ４０がカラオケサーバ２０−１（図２）から取得した音楽データ（この実施例では、ＰＣＭデータではなくＭＩＤＩデータ）を再生することによってプロセサ４０の出力ポートＬおよびＲから出力される。出力ポートＬおよびＲからの音楽音声の左信号および右信号は、それぞれ、リバーブアンプ４５３および４５５ならびにインピーダンス４５７および４５９を介して、ミキサ４０３に入力される。そして、ミキサ４０３から出力されるオーディオ信号は、たとえば、図示しないスピーカから音楽音声として出力される。
なお、上述のエコーアンプ４４９はエコー調整器４６１によって、そのエコー量（遅延時間）が制御される。そして、エコー調整器４６１によるエコー量は、たとえばプロセサ４０からの３ビットの調整信号ＡＳＷ５−７によって８段階に調整される。
さらに、リバーブアンプ４５３およびインピーダンス４５７を経た左音楽音声信号は、ミキサ４０３に入力される前に、左信号調整器４６３によって大きさ（振幅）の調整を受ける。同様に、リバーブアンプ４５５およびインピーダンス４５９を経た右音楽音声信号は、ミキサ４０３に入力される前に、右信号調整器４６５によって大きさ（振幅）の調整を受ける。左信号調整器４６３および右信号調整器４６５は、それぞれ、プロセサ４０からの３ビットの調整信号ＡＳＷ８−１０によって、８段階に調整される。
また、よく知られているように、カラオケモードではＴＶすなわち表示器５−ｎ（図３）に背景映像および歌詞（文字）情報を表示する必要があるが、この映像信号は、プロセサ４０のビデオ出力ポートＶＩＤＥＯＯＵＴから出力されて、その表示器５−ｎに入力される。
図５を参照して、プロセサ４０には、たとえば３０ビットのアドレスバスおよび１６ビットのデータバスを含むバス４６７が結合され、バス４６７にはフラッシュメモリ４６９およびＳＲＡＭ４７１が結合される。フラッシュメモリ４６９はこの実施例ではたとえば１２８ＭＢの記憶容量を有し、ＳＲＡＭ４７１はたとえば６４ＭＢの記憶容量を有する。ただし、これらの記憶容量は必要に応じて増減できるし、さらには、別の半導体メモリが用いられてもよい。そして、バス４６７にはたとえばＮＡＤインタフェースメモリのような外部メモリ４７３が必要に応じて結合され得る。
上述のフラッシュメモリ４６９は図６に示す記憶領域４６９ａ，４６９ｂ，４６９ｃなどを有する。プログラム記憶領域４６９ａには、後に詳細に説明する各モード（リリックプレイヤモード，ＢＧＭモードおよびカラオケモードなど）の動作プログラムを予め記録している。画像記憶領域４６９ｂには、それらの動作プログラムの実行に必要な映像または画像のデータが記憶される。
たとえば、リリックプレイヤモードは、ＣＤ中に録音されている曲の歌詞を曲名や歌手名と一緒にＴＶ（表示器）５−ｎ（図３）に文字で表示することによってその曲の歌唱練習に役立てようとするモードであり、その文字表示の際に背景画像も併せて表示する。この場合の背景画像のためのデータはフラッシュメモリ４６９のこの画像記憶領域４６９ｂに予め記憶しておく。
同じように、カラオケモードではカラオケデータをカラオケサーバ２０−１から取得するが、そのカラオケデータにはカラオケ背景画像のデータは含まれないので、背景画像をＡＶ装置４側で作成する必要があるが、そのカラオケ背景画像の画像データもこの画像記憶領域４６９ａに予め記憶されている。
メッセージ記憶領域４６９ｃには各動作プログラムの実行中にＴＶ５−ｎに表示することによってユーザの注意を喚起するためのメッセージのデータが記憶される。どのモードでも、たとえばエラーや障害が発生した場合にそのことをユーザに知らせるために、ＴＶすなわち表示器５−ｎに可視メッセージを表示するが、それらのメッセージのためのデータがこのメッセージ記憶領域４６９ｃに予め記憶される。
さらに、このフラッシュメモリ４６９には、必要に応じて、参照テーブルあるいは変換テーブルなども予め設定されている。
プロセサ４０の割り込み信号入力用ポートには、リモコン用赤外線受信機４７５からのリモコン信号が入力される。このＡＶ装置４に附属するＩＲ機器８の範疇に含まれるリモコン送信機の一例が図７に示される。
図７を参照して、リモコン送信機８０は、長手矩形のハウジング８０１を含み、このハウジング８０１の上面に各操作部８０３，８０５および８０７が設定される。操作部８０３は、カラオケ用操作キー８０９，８１１，８１３ａ，８１３ｂ，８１５ａおよび８１５ｂを含む。操作キー８０９は採点キーであり、ユーザの歌唱を採点表示するかしないかを選択的に設定するキーである。ただし、この採点きー８０９は歌唱の途中でも操作することができる。そして、ＡＶ装置４では、採点キー８０９がユーザによってオンされていると、マイクから入力される音声信号に基づいて歌唱の採点をリアルタイムで行う。
エコーキー８１１は、先に説明したエコーアンプ４４９（図４）をイネーブルするかどうかを設定するためのキーで、このエコーキー８１１を操作すると、エコーアンプ４４９がイネーブルされ、自分の歌唱のマイク信号にエコーという音響効果を施すことができる。シャープキー８１３ａおよびフラットキー８１３ｂはともに音高設定キーとして機能し、シャープキー８１３ａを操作する都度、カラオケ音楽音声のキー（音高）が半音ずつ上げられ、フラットキー８１３ｂを操作する都度、キーが半音ずつ下げられる。プラスキー８１５ａおよびマイナスキー８１５ｂはともにテンポ設定キーとして機能し、プラスキー８１５ａを操作する都度、カラオケ音楽音声のテンポが速くされ、マイナスキー８１５ｂを操作する都度、テンポが遅くされる。
操作部８０５はメニュー選択用操作部であり、メニューキー８１７を含む。このメニューキー８１７を操作すると、後述のメインメニューを表示器５−ｎ（図３）に表示し、カーソル移動キー８１９ａ，８１９ｂ，８１９ｃおよび８１９ｄを操作することによって、カーソル（図示せず）を上下左右に動かして、メニュー選択などを実行できる。カーソル移動キー８１９ａ，８１９ｂ，８１９ｃおよび８１９ｄは、それぞれ、カーソルを前後左右に移動させることができる。
予約キー８２１はカラオケモードにおいてカラオケ配信を受けるべきカラオケ番号を予約するためのキーであり、この予約キー８２１を操作することによって、その前に選択または指定したカラオケ番号を予約リストに登録する。ただし、予約リストは図示しないがＳＲＡＭ４７１（図５）の適宜の領域に記憶される。
決定キー８２３は、メニュー選択や予約登録を決定するときに操作するキーであり、キャンセルキー８２５は、一旦決定したメニューや予約登録を取り消すために操作するキーである。メニュー用操作部８０５にはまた、特別な選択キー８２７が設けられていて、このキー８２７はリリックプレイヤキーである。リリックプレイヤキー８２７は、先に説明した「歌詞配信」のサービスを受けるときにユーザが操作する。このリリックプレイヤキー８２７を１回操作するだけで、順次のメニュー選択の操作なしで、リリックプレイヤモード（歌詞配信モード）を選択することができる。
操作部８０７にはテンキー８２９が設けられる。このテンキー８２９は、「０」−「９」までの数値を入力することができ、たとえば後述のカラオケモードにおいてカラオケ番号を入力するためなどに利用される。
なお、図７のリモコン送信機８０は単なる一例であり、具体的な形状，キーの配列あるいは操作キーの種類や数は適宜変更できる。つまり、この図７の実施例より多い種類や数の操作キーを設けてもよく、図７の実施例より少ない種類や数の操作キーしか持たないリモコン送信機であってもよい。
実施例では、このリモコン送信機８０は、上で説明した各キー８０９−８２９の操作信号を赤外線信号として送信し、この赤外線リモコン信号は、図５に示すリモコン用赤外線受信機４７５によって受信される。
そして、リモコン用赤外線受信機４７５は、赤外線リモコン信号を復調、復号して各操作キー８０９−８２９の操作信号をプロセサ４０に入力する。
図５に戻って、ＡＶ装置４はＬＡＮコントローラ４７９を含み、このＬＡＮコントローラ４７９は、バス４７７によってプロセサ４０に結合される。さらに、このバス４７７によって、ＡＴＡ（ＡＴ  Ａｔｔａｃｈｍｅｎｔ）／ＡＴＡＰＩ（ＡＴＡ  Ｐａｃｋｅｔ  Ｉｎｔｅｒｆａｃｅ）コネクタ４８１がプロセサ４０に結合される。ＬＡＮコントローラ４７９は、このＡＶ装置４によってたとえばインタネット３を介して、音楽資産管理システム２に含まれる各サーバ２０−１，−２，−３，−４，−５，−６，−７，−８および−９（図２）にアクセスするときの通信プロトコルを実行する。
ＡＴＡ／ＡＴＡＰＩコネクタ４８１は、ＣＤドライブ４８３接続される。ＣＤドライブ４８３にはＣＤ（図示せず）が装着でき、ＡＶ装置４は、ＡＴＡ／ＡＴＡＰＩコネクタ４８１を介して、ＣＤドライブ４８３に、ＣＤに録音している音楽をそのまま再生させることができるし、ＣＤを利用して後に詳細に説明するリリックプレイヤモードを実行することができる。上で説明したように、リリックプレイヤモードでは、ＡＶ装置４は、ＣＤに録音されている曲の歌詞（リリック）をたとえばカラオケサーバ２０−１から提供してもらうモードである。
なお、ＣＤドライブ４８３によって再生された音楽音声ＣＬおよびＣＲは、図４のミキサ４０３に入力され、ミキサ４０３からそのままオーディオ信号として出力され、あるいは、エコーアンプ４４９からの音楽音声および／またはプロセサ４０からの音楽音声とミキシングされてオーディオ信号として出力される。
この図４および図５に詳細に示すＡＶ装置４は全体としてプロセサ４０が制御を司り、プロセサ４０は、電源が投入されると、図８に示すメインルーチンを実行する。
最初のステップＳ１では、プロセサ４０は、このＡＶ装置４の全体を初期化する。具体的には、たとえばＳＲＡＭ４７１（図５）に形成されるレジスタ，フラグ，カウンタ，ポインタなどを初期化する。
続いて、ステップＳ３において、プロセサ４０は、音楽資産管理システム２の各サーバ２０−１，−２，−３，−４，−５，−６，−７，−８，−９（図２）のいずれかにアクセスし、ユーザ認証データの送信の準備をする。ただし、ユーザ認証は、ユーザ認証データをユーザ端末すなわちＡＶ装置４からサーバに送信し、サーバからのレスポンスとして当該ユーザ認証の結果を受信する。
なお、図２に示す音楽資産管理システム２にはカラオケサーバ２０−１を含むが、このカラオケサーバ２０−１は、カラオケモードでは、カラオケ番号を検索キーとしてデータベースからカラオケデータを検索するが、リリックプレイヤモードでは、リリック番号を検索キーにしてデータベースからリリックデータを検索し、さらには、ＢＧＭモードでは、ＢＧＭ番号を検索キーにしてデータベースからＢＧＭデータを検索するサーバである。下の説明では、一例として、カラオケサーバ２０−１が上述のカラオケデータ，リリックデータおよびＢＧＭデータをすべて検索でき、かつユーザ端末すなわちＡＶ装置４がそのようなカラオケサーバ２０−１にアクセスするものとして説明する。ただし、図２に示すＣＤデータベースサーバ２０−９は、ＣＤドライブ４８３（図５）で再生したＣＤのＴＯＣ（Ｔａｂｌｅ  Ｏｆ  Ｃｏｎｔｅｎｔｓ）情報を検索キーにしてＣＤのタイトル名，歌手名，曲リストおよびリリック番号を検索できるサーバである。つまり、リリックデータを検索するときのリリック番号はＣＤデータベースサーバ２０−９が提供することになる。
続くステップＳ５において、プロセサ４０はＴＣＰ／ＩＰ送受信処理を実行する。ＴＣＰ／ＩＰとは、インタネットにおける通信プロトコルの総称であり、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）とＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）という２つの代表的なプロトコルの名称を合体させたものである。このＴＣＰ／ＩＰ送受信処理ステップは具体的には、図９に従って実行される。
図９の最初のステップＳ７では、プロセサ４０は、図５に示すＳＲＡＭ４７１の適宜の領域に割り付けられたカウンタ（ｄ）（図示せず）を初期化する。このカウンタ（ｄ）は送信データ数をカウントするためのもので、ステップＳ９でＬＡＮコントローラ４７９（図５）に１バイト転送する毎に、ステップＳ１１でインクリメントされる。そして、ステップＳ１３でそのカウンタ（ｄ）のカウント値が送信すべきデータ数に達したかどうかをプロセサ４０は判断する。つまり、このステップＳ１３において、プロセサ４０はすべての送信データの送信が終了したかどうか判断する。したがって、このステップＳ１３で“ＹＥＳ”を判断すると続いてステップＳ１５で受信モードへ遷移するが、“ＮＯ”を判断したときには、ステップＳ９に戻り、すべての送信データを送信するまで、ステップＳ９−Ｓ１３を繰り返し実行する。
ステップＳ１３で“ＹＥＳ”の結果受信モードに遷移したとき、ステップＳ１７において、プロセサ４０はＬＡＮコントローラ４７９で上述のデータ送信に対するレスポンスデータを受信したかどうか判断する。“ＮＯ”なら、データを受信するまで、待機する。
“ＹＥＳ”なら、次のステップＳ１９において、プロセサ４０は、ＳＲＡＭ４７１（図５）の適宜の領域に割り付けられたカウンタ（ｅ）（図示せず）を初期化する。このカウンタ（ｅ）は受信データ数をカウントするためのもので、ステップＳ２１でＬＡＮコントローラ４７９から１バイトの転送を受ける毎に、ステップＳ２３でインクリメントされる。そして、ステップＳ２５で、そのカウンタ（ｅ）のカウント値が受信すべきデータ数に達したかどうかをプロセサ４０は判断する。つまり、このステップＳ２５において、プロセサ４０はすべての受信データの受信が終了したかどうか判断する。
ステップＳ２５で“ＹＥＳ”を判断すると続いてステップＳ２７で受信データをデコードする。コンテンツ長（Ｃｏｎｔｅｎｔ  Ｌｅｎｇｔｈ）は総データ数であるが、この総データ数も受信データをデコードすることによって判明する。そして、ステップＳ２９でプロセサ４０が、そのようにして求めた総データ数の受信データのデコード終了を検知すると、ステップＳ２９で“ＹＥＳ”となり、たとえば図８のメインルーチンへリターンする。ただし、ステップＳ２９で“ＮＯ”となった場合には先のステップＳ１７に戻り、それ以後のステップＳ１９−Ｓ２９を繰り返す。
プロセサ４０は続くステップＳ３１（図８）で先のステップＳ５でのＴＣＰ／ＩＰ送受信処理の結果、ユーザ認証がＯＫかどうか、判断する。“ＮＯ”の場合には、このプログラムを進行することができないので、プロセサ４０は、ステップＳ３３において、たとえば「ユーザ認証がＮＧでしたので、電源をオフします。」などのエラーメッセージを表示器すなわちＴＶ５−ｎに表示した後、電源、すなわちレギュレータ４０１をオフして、このプログラムを終了する。
ユーザ認証がＯＫの場合には、ステップＳ３１で“ＹＥＳ”が判断され、プロセサ４０は次のステップＳ３５において、サーバ２０−１に対してメインメニューの送信を要求する準備をする。そして、次のステップＳ３７において、プロセサ４０は、ステップＳ５と同様の図９に詳細に示すＴＣＰ／ＩＰ送受信処理を実行する。したがって、このステップＳ３７が終わったとき、プロセサ４０は、サーバ２０−１からメインメニューデータを受信している。
したがって、次のステップＳ３９で、プロセサ４０は、ＴＶすなわち表示器５−ｎに図１０に例示するメインメニュー画面４８５を表示する。この実施例のメインメニュー画面４８５では、選択可能なメインメニューとして、３つのモード、すなわちリリックプレイヤモード，ＢＧＭモードおよびカラオケモードが表示される。
その後、プロセサ４０はステップＳ４１において、ＩＲ受信処理を実行する。詳しく言うと、先に図５を参照して説明したように、この実施例のＡＶ装置４はリモコン用赤外線受信機４７５を備え、その赤外線（ＩＲ）受信機４７５は、図７に示すリモコン送信機８０からの赤外線（ＩＲ）信号を受信し、そのＩＲ信号を復号してプロセサ４０に送信する。そして、プロセサ４０は、そのときリモコン送信機８０から送信されてきたキー操作信号がキー８０９−８２９（図７）のどれのものであるかを特定する。この一連の処理がＩＲ受信処理である。
ステップＳ４１でプロセサ４０はＩＲ受信機４７５からキー操作信号を受けるので、次のステップＳ４３で、そのときリモコン送信機８０の決定キー８２３が操作されたかどうか、つまり、メニュー選択が完了したかどうかを判断する。“ＮＯ”ならステップＳ４１に戻ってＩＲ受信機４７５からのキー操作信号を待つ。
決定キー８２３が操作されたと判断したとき、プロセサ４０は、次のステップＳ４５で、ユーザが選択したメニューがリリックプレイヤモードであるのかどうか、判断する。“ＮＯ”なら、プロセサ４０は、次のステップＳ４７で、ユーザが選択したメニューがＢＧＭモードであるのかどうか、判断する。“ＮＯ”なら、プロセサ４０は、次のステップＳ４９で、ユーザが選択したメニューがカラオケモードであるのかどうか、判断する。
また、ステップＳ４５でリリックプレイヤモードが選択されたと判断したときには、ステップＳ５１のリリックプレイヤモードへジャンプする。同様にして、ステップＳ４７でＢＧＭモードが選択されたと判断したときには、ステップＳ５３のＢＧＭモードへジャンプし、ステップＳ４９でカラオケモードが選択されたと判断したときには、ステップＳ５５のカラオケモードへジャンプする。
リリックプレイヤモードの動作の詳細が図１１および図１２のフロー図に示される。図１１の最初のステップＳ５７では、プロセサ４０は、ＳＲＡＭ４７１（図５）の適宜の領域に形成されたカウンタ（図示せず）を初期化する。このカウンタはエラー検出用の時間カウンタである。
そして、次のステップＳ５９において、プロセサ４０は、ＡＴＡ／ＡＴＡＰＩコネクタ４８１からバス４７７を通して入力される情報から、ＣＤドライブ４８３（図５）にＣＤが挿入または装着されているかどうかを判断する。“ＮＯ”なら、ステップＳ６１で、ステップＳ５７で初期化した時間カウンタをインクリメントし、ステップＳ６３で、その時間カウンタのカウント値が所定の最大値に達したかどうか判断する。つまり、このリリックプレイヤモードにおいては、このモードを選択したにも拘らず一定時間以内にＣＤがＣＤドライブ４８３に装着されないときには、このステップＳ６３で“ＹＥＳ”を判断することになり、エラーとして処理する。すなわち、ステップＳ６５で、プロセサ４０は、たとえば「ＣＤが挿入されていません」というようなエラーメッセージを図１３に示すエラーメッセージ画面４８７として、ＴＶすなわち表示器５−ｎに表示して、ユーザにエラー状態を知らせる。
その後、プロセサ４０は、ステップＳ６７で、ステップＳ４１（図８）で説明したと同様のＩＲ受信処理を実行する。したがって、もしユーザがそのエラーメッセージを見てリモコン送信機８０のキャンセルキー８２５（図７）を操作したのであれば、ＴＶすなわち表示器５−ｎの表示は、図１０に示すメインメニュー画面４８５に戻る。
ステップＳ５９で“ＹＥＳ”が判断されたときには、プロセサ４０は、次のステップＳ６９において、バス４７７から入力される、ＣＤのＴＯＣサイズデータを読み込む。次のステップＳ７１で、プロセサ４０は、ＣＤから読み出したＴＯＣデータを読み込み、ステップＳ７３で、そのＴＯＣデータを、たとえばＳＲＡＭ４７１に一時的に記憶する。このＴＯＣデータの読み込みの完了をステップＳ７５で検出すると、プロセサ４０は、次のステップＳ７７において、そのＴＯＣデータをＣＤデータベースサーバ２０−９に送信する準備をする。なお、ＴＯＣデータは、ＣＤ（記憶媒体）に記録されている楽曲に関連する情報を含むので、楽曲情報または楽曲データということができる。
その後、ステップＳ７９で、先に説明したと同様のＴＣＰ／ＩＰ送受信処理を行なって、ＣＤから読み取ったＴＯＣデータをＣＤデータベースサーバ２０−９に送信する。そのＣＤデータベースサーバ２０−９のレスポンスに含まれるＣＤタイトル名，歌手名，曲リストおよびリリック番号のデータを取得し、そのうちリリック番号およびＣＤタイトル名を除く，歌手名および曲リストを、図１４に示す曲リスト画面４８９として、ＴＶすなわち表示器５−ｎに表示する（ステップＳ８１）。この曲リスト画面４８９には、歌手名および曲リストのみが表示されているが、ＣＤタイトル名を表示するようにしてもよいことは勿論である。
その後、図１２のステップＳ８３に進み、プロセサ４０は、先に説明したＩＲ受信処理を実行し、リモコン操作信号を取得する。そして、ステップＳ８５で決定キーの操作を検出するまで待つ。
ステップＳ８５で決定キー８２３（図７）の操作を検出すると、次のステップＳ８７において、プロセサ４０は、リリックプレイヤ用の背景映像をＴＶすなわち表示器５−ｎに表示する。なお、このリリックプレイヤ用の背景映像は、たとえばフラッシュメモリ４６９（図５）に予め登録しておけばよい。
そして、次のステップＳ８９で、リモコン送信機８０のカーソル移動キー８１９ａ−８１９ｄで移動されたカーソルの位置座標（ＴＶすなわち表示器５−ｎの画面上の）データを取得する。カーソル位置が図１４の曲名リスト画面４８９でそのとき選択された曲名を表しているので、このステップＳ８９では、結局プロセサ４０は、そのとき装着されているＣＤの中のユーザによって選択された曲名を知ることができる。そして、次のステップＳ９１において、プロセサ４０は、その曲名に対応するリリック番号（これはステップＳ８１でＳＲＡＭ４７１に記憶されている）を取得する。
プロセサ４０は、このリリック番号を次にカラオケサーバ２０−１に送信する準備をする（ステップＳ９３）。ステップＳ９５でＴＣＰ／ＩＰ送受信処理を実行する。したがって、このステップＳ９５で、プロセサ４０は、そのとき送信したリリック番号によって表される歌詞のデータ（つまりリリックデータ）をカラオケサーバ２０−１からのレスポンスとして取得し、それをＳＲＡＭ４７１に記憶する。
リリックデータの構成の一例が図１５に示される。リリックデータは、複数のブロックに区分されている。したがって、リリックデータには、各ブロックの表示開始時間（ＣＤの先頭からの）である表示開始時間（ａ）と、各ブロック毎に表示すべき歌詞データ（ｃ）とが含まれる。図１５の実施例では、ブロック１の表示開始時間は２ミリ秒であり、歌詞は「Ｎｏ．１にならなくてもいい  もともと特別なＯｎｌｙ  Ｏｎｅ」である。ブロック２の表示開始時間は５０００ミリ秒で、歌詞は「花屋の店先に並んだいろんな花を見ていた」というものである。ただし、最後のブロックには、歌詞データ（文字コード）の代わりに、終了コードが設定されていて、したがって、最後のブロックには表示開始時間に表示する歌詞はなく、この表示開始時間は終了時間の意味を持つことになる。
ステップＳ９５で図１５のような構成のリリックデータを受信したのち、ステップＳ９７で、プロセサ４０はＣＤドライブ４８３に指令を与え、ＣＤの再生をスタートさせる。
そして、ステップＳ９９で、プロセサ４０は、ＳＲＡＭ４７１から、リリックデータの最初のブロックの表示開始時間（ａ）を読み出し、その表示開始時間を図示しない時間レジスタにロードする。そして、ステップＳ１０１で、ＣＤの再生時間（ｂ）をバス４７７から読み込む。表示開始時間（ａ）と再生時間（ｂ）とが等しくなったことをステップＳ１０３で検出すると、プロセサ４０は、ステップＳ１０５で、そのブロックの歌詞データ（ｃ）をＳＲＡＭ４７１から読み出す。ステップＳ１０７で終了コードを検知するまで、ステップＳ１０９で、図１６に示す、曲名、歌詞データ（ｃ）および歌手名を含むリリックプレイヤ画面４９１をＴＶすなわち表示器５−ｎに表示する。
このように、リリックプレイヤモードでは、そのときＣＤドライブ４８３に装着されているＣＤの中の、選択した曲の歌詞がリリックプレイヤ画面４９１としてＴＶ５−ｎに表示されるので、そのＣＤのその曲の歌唱練習が効率よくできる。ＣＤのケースの中にはいわゆる歌詞カードが同梱されているが、その歌詞カードの文字の大きさは一般的には小さく、見難いものである。これに対して、ＴＶすなわち表示器５−ｎの大きな画面にリリックプレイヤ画面４９１（図１６）が表示されるこの実施例では、その曲の歌詞の目視確認が容易で、したがって、歌唱練習が効率よくできるのである。
その後、ステップＳ１１１で、プロセサ４０は、ブロックポインタ（これはたとえばＳＲＡＭ４７１の一部の領域を使ったカウンタのようなもの）を次のブロックに進める。そして、ステップＳ１０７で終了コードを検出するまで、ステップＳ９９−Ｓ１１１を繰り返し実行する。したがって、各ブロックの歌詞データ（ｃ）がＣＤの再生とタイミング的に同期して、順次表示される。
ステップＳ１０７で終了コードを検出すると、プロセサ４０は、ステップＳ１１３で、ＣＤドライブ４８３に停止命令を与えてＣＤの再生を停止させ、さらに、ステップＳ１１５で、再生すべき次のトラックがあるかどうか判断する。“ＹＥＳ”なら先のステップＳ９３から各ステップを準じ実行し、自動的に、次の曲の再生を行う。
ただし、ステップＳ１１５で“ＮＯ”が判断されたとき、つまり、次の曲はないと判断したとき、プロセサ４０は、先のステップＳ８１に戻る。
このように、リリックプレイヤモードでは、ＡＶ装置４のＣＤドライブ４８３（図５）にＣＤを装着すると、そのＣＤのＴＯＣ情報がサーバ２０−９に送信され、サーバ２０−９でＣＤ内のすべての楽曲のリリック番号が検索され、リストとして、ＡＶ装置４に返送される。ＡＶ装置４でユーザが１つのリリック番号を指定すると、そのリリック番号がサーバ２０−１に送信され、サーバ２０−１からはそのリリック番号で示される楽曲の歌詞（リリック）のデータがＡＶ装置４に送られてくる。したがって、ＡＶ装置４はそのリリックデータに従って、たとえば図１６のリリックプレイヤ表示画面４９１のように、楽曲の歌詞を表示器５−ｎに表示することができる。
なお、実施例ではＣＤドライブ４８３にＣＤを装着してリリックプレイヤモードを実行するようにしているが、ＣＤドライブ４８３をＤＶＤドライブに代え、ＣＤをＤＶＤに代えてもよいことは勿論である。つまり、楽曲の記憶媒体としては任意のものが利用できる。
また、上記では、ＡＶ装置４は、リリック番号をＣＤデータベースサーバ２０−９から取得した。しかし、ＡＶ装置４がＣＤデータベースサーバ２０−９からＣＤの識別情報を取得して、この識別情報をカラオケサーバ２０−１に送信し、カラオケサーバ２０−１がリリック番号をＡＶ装置４に送信するようにしてもよい。さらに、ＡＶ装置４がＣＤデータベースサーバ２０−９からＣＤの識別情報を取得して、この識別情報をカラオケサーバ２０−１に送信し、カラオケサーバ２０−１がそのＣＤに含まれる全楽曲の歌詞データをＡＶ装置４に送信するようにしてもよい。
先に説明したように、メインルーチン（図８）のステップＳ４７でＢＧＭモードが選択されたと判断したときには、ステップＳ５３のＢＧＭモード（楽曲配信モード）へジャンプする。
このＢＧＭモードの動作の詳細が図１７のフロー図に示される。図１７の最初のステップＳ１１７では、プロセサ４０は、フラッシュメモリ４６９（図５）の適宜の領域に予め登録されているＢＧＭメニューデータを読み出して、たとえば図１８に示すＢＧＭメニュー画面４９３をＴＶ（表示器）５−ｎ上に表示し、ユーザの選択を待つ。ただし、このＢＧＭメニューは、カラオケサーバ２０−１からＳＲＡＭ４７１にダウンロードしておき、このＳＲＡＭ４７１からＢＧＭメニューを読み出すようにしてもよい。
このＢＧＭメニュー画面４９３では、実施例では、２０００年代の楽曲，１９９０年代の楽曲，１９８０年代の楽曲あるいは１９７０年代の楽曲を選択できるように、ＢＧＭリスト番号を表示する。たとえば、図１９に示すように２０００年代の楽曲リストがリスト番号０１で指定され、図２０に示すように１９９０年代の楽曲リストがリスト番号０２で示される。
その後、プロセサ４０は、ステップＳ１１９で、先に説明したと同様のＩＲ受信処理を実行する。つまり、プロセサ４０はステップＳ１１９でＩＲ受信機４７５からキー操作信号を受け、次のステップＳ１２１で、そのときリモコン送信機８０の決定キー８２３が操作されたかどうか、つまり、ＢＧＭメニュー選択が完了したかどうかを判断する。“ＮＯ”ならステップＳ１１９に戻ってＩＲ受信機４７５からのキー操作信号を待つ。
そして、次のステップＳ１２３で、リモコン送信機８０のカーソル移動キー８１９ａ−８１９ｄで移動されたカーソルの位置座標（ＴＶすなわち表示器５−ｎの画面上の座標位置）データを取得する。カーソル位置が図１８のＢＧＭメニュー画面４９３でそのとき選択されたＢＧＭメニューの１つを表しているので、このステップＳ１２３では、結局プロセサ４０は、そのときユーザによって選択されたＢＧＭメニュー（ＢＧＭリスト番号）を知ることができる。
その後、プロセサ４０は、次のステップＳ１２５において、そのＢＧＭリスト番号をカラオケサーバ２０−１に送信する準備をする。そして、ステップＳ１２７で、先に説明したと同様のＴＣＰ／ＩＰ送受信処理を行って、カラオケサーバ２０−１からのレスポンスとしてユーザが選択したＢＧＭリスト番号に含まれるカラオケ（ＢＧＭ）のリスト、すなわちＢＧＭリストのデータを取得する。このＢＧＭリストデータは、ＳＲＡＭ４７１の所定領域にダウンロードされる。ＢＧＭリストにはユーザが配信を希望する楽曲（実施例ではカラオケ）を示すデータすなわち実施例ではカラオケ番号が含まれるので、ＢＧＭリストは、楽曲リストとも呼ぶことができる。この楽曲リストはＳＲＡＭ４７１の上記所定領域に保持される。したがって、このＢＧＭモードにおいて、ＳＲＡＭ４７１は、ＢＧＭリストすなわち楽曲リストの保持手段として機能する。
ＢＧＭリストの一例が図１９および図２０に図解されているが、図１９のＢＧＭリストはＢＧＭリスト番号０１に含まれる、ＢＧＭとして提供可能な２０００年代のカラオケ楽曲の番号（カラオケ番号）が配列されている。図２０のＢＧＭリストはＢＧＭリスト番号０２に含まれる、１９９０年代のカラオケ楽曲のカラオケ番号が配列されている。ＢＧＭモードではこのＢＧＭリストに載せられたすべての楽曲を順次自動的に演奏するものであるため、このＢＧＭリストからＢＧＭとして再生すべき曲のカラオケ番号をユーザに選択させる必要はない。ただし、ＳＲＡＭ４７１内のＢＧＭリストのカラオケ番号を自動演奏のためにＢＧＭリストポインタで順次指定する必要がある。
このＢＧＭリストポインタは図示しないが、たとえばＳＲＡＭ４７１（図５）の一部の領域に形成されたカウンタであり、ステップＳ１２９で初期化される。したがって、その段階では、ＢＧＭリスト（図１９、図２０）の最上位に示されているカラオケ番号が指定されていて、ＢＧＭリストポインタを順次インクリメントすることによって、ＢＧＭリストのカラオケ番号を順次指定することになる。ステップＳ１３１では、プロセサ４０はＳＲＡＭ４７１に記憶しているＢＧＭリストデータから、そのときＢＧＭリストポインタで指定されているカラオケ番号を読み込む。
そして、次のステップＳ１３３において、プロセサ４０は、フラッシュメモリ４６９から受信待ち背景画像の画像データを読み出して、ＴＶすなわち表示器５−ｎの表示画面上にその受信待ち画像（図示せず）を表示する。この場合の背景画像は、プロセサ４０が小さな労力で表示処理を行うことができるような、極力シンプルな内容のものとする。このように、極力シンプルな内容の背景画像を表示することで、プロセサ４０の能力を、表示器５−ｎへの表示処理よりもＬＡＮコントローラ４７９からのデータ取得処理に多く割くことができる。
次のステップＳ１３５で、プロセサ４０は、ＴＶ５−ｎの表示画面を更新するためのＶブランク（垂直ブランク）割り込みを禁止する。Ｖブランク割り込みを禁止することにより、ステップＳ１３３の処理と相俟って、より一層、プロセサ４０の能力を、表示器５−ｎへの表示処理よりもＬＡＮコントローラ４７９からのデータ取得処理に割くことができる。
このようなステップＳ１３３および／またはＳ１３５の処理は、コストを抑えた必要最小限の能力を有するプロセサ４０を搭載したときに特に好適である。つまり、表示処理に割り振るプロセサ４０の能力を極力少なくして、より多くの能力をＬＡＮコントローラ４７９からのデータ取得処理に割くことにより、ＬＡＮコントローラ４７９にデータ量の大きいデータをサーバ２０−ｋから取得させ、そのようなデータをプロセサ４０が処理しなければならない場合でも、必要最小限の能力を有するプロセサ４０によって、必要な時間内にデータ量の大きいデータの処理が可能となる。
したがって、搭載するプロセサ４０の能力によっては（つまり、プロセサ４０が十分大きな能力を持っているか、あるいは複数のプロセサ４０を搭載していれば）、ステップＳ１３３およびＳ１３５の処理は不要の場合もあるし、また、いずれか一方の処理で十分な場合もある。一方、必要最小限の能力を有するプロセサ４０であっても、ＬＡＮコントローラ４７９からのデータ量によっては（つまり、小さなデータ量では）、ステップＳ１３３およびＳ１３５の処理は不要の場合もあるし、また、いずれか一方の処理で足りる場合もある。
このように、ステップＳ１３３および／またはＳ１３５の挿入により、プロセサ４０の能力の振り分けをコントロールできる。
その後、プロセサ４０は、次のステップＳ１３７において、上述のカラオケ番号をカラオケサーバ２０−１に送信する準備をする。そして、ステップＳ１３９で、先に説明したと同様のＴＣＰ／ＩＰ送受信処理を行って、カラオケサーバ２０−１からのレスポンスとしてＢＧＭポインタが指定したカラオケ番号のカラオケデータを取得する。
カラオケデータの一例が図２１に示される。カラオケデータは、後に説明するカラオケモードでカラオケサーバ２０−１から取得するものと同じである。カラオケデータは、最初にヘッダ部が配置され、そのヘッダ部に後続して、タイトル画像のデータがある。このタイトル画像は、カラオケの曲名を表示する際に文字情報の背景に表示される画像であり、曲名だけでなく、作曲者名や作詞者名をも含む。カラオケデータ内では、タイトル画像に後続して、歌詞（リリック）情報，カラオケＭＩＤＩデータおよびコーラスＰＣＭデータが設定されている。なお、演奏の終了を示す終了コードはカラオケＭＩＤＩ終了コードとしてＭＩＤＩデータに含まれる。
ステップＳ１３９でＴＣＰ／ＩＰ送受信処理が完了した後には、先にステップＳ１３５で禁止していたＶブランク割り込みを許可し、表示の更新ができるようにする。
ステップＳ１３９で図２１のようなカラオケデータが得られるので、ステップＳ１４１でＶブランク割り込みの禁止を解除した後、プロセサ４０は、次のステップＳ１４３において、曲名，作詞者および作曲者の文字情報を、タイトル画像と一緒にＴＶすなわち表示器５−ｎに表示する。このときの表示画面にはリリック（歌詞）は表示しない。ただし、タイトル画像を表示しないようにすることも可能である。
その後、プロセサ４０は、ステップＳ１４７で終了コードを検出するまで、ステップＳ１４５でカラオケＭＩＤＩデータを再生する。つまり、カラオケを演奏する。
そして、ステップＳ１４７で終了コードを検出すると、プロセサ４０は、次のステップＳ１４９でＢＧＭリストポインタをインクリメントし、ステップＳ１５１でＢＧＭリストに演奏未了のカラオケ番号が残っているかどうか判断する。そのステップＳ１５１でＢＧＭリストの終了ではないと判断したときには、プロセサ４０は、先のステップＳ１３１に戻り、ステップＳ１３１−Ｓ１５１を繰り返し実行する。
詳しく説明すると、ステップＳ１４５を実行することによって１つのカラオケデータ（ＢＧＭ）の再生が終了する。そして、ステップＳ１５１で“ＮＯ”が判断された後には、ステップＳ１３９でカラオケサーバ２０−１に、ＢＧＭリストに保持されている別のカラオケ番号で示される別の楽曲（カラオケ）のデータの送信を要求する。その要求に応じてサーバ２０−１から、当該別のカラオケデータが送信され、ステップＳ１３９でそれを受信するが、そのとき、プロセサ４０は、ＳＲＡＭ４７１のＢＧＭデータ記憶領域（図示せず）をその別のカラオケデータで上書きする。つまり、ＳＲＡＭ４７１内には再生済みのカラオケデータ（ＢＧＭデータ）は、新しくサーバ２０−１から送られてきた別のカラオケデータによってＳＲＡＭ４７１の該当領域が上書きされることによって、ユーザ端末すなわちＡＶ装置４内には残ることがない。
このように、ＢＧＭモードでは、ＡＶ装置４でユーザがたとえば図１８に示すようなＢＧＭメニューを選択すると、ＡＶ装置４は選択したＢＧＭメニューのＢＧＭリスト番号をカラオケサーバ２０−１へ送信する。応じて、カラオケサーバ２０−１からは、そのＢＧＭリストを構成する複数のカラオケ番号を含むリストデータがＡＶ装置４に送信される。ＡＶ装置４で複数のカラオケ番号の１つを順次指定することによって、カラオケサーバ２０−１から、そのカラオケ番号の演奏データ（カラオケデータ）がＡＶ装置４に送られてくる。したがって、ＡＶ装置４は順次送られてくるカラオケデータを、ＢＧＭとして再生することができる。
先に説明したように、メインルーチン（図８）のステップＳ４９でカラオケモードが選択されたと判断したときには、ステップＳ５５のカラオケモードへジャンプする。
このカラオケモードの動作の詳細が図２２および図２３に示すフロー図に示される。図２３の最初のステップＳ１５３では、プロセサ４０は、フラッシュメモリ４６９（図５）の適宜の領域に予め登録されているカラオケ検索方法画面データを読み出して、たとえば図２４に示すカラオケ検索方法表示画面４９５をＴＶ（表示器）５−ｎ上に表示し、ユーザの選択を待つ。カラオケ検索方法としては、この実施例では、カラオケ番号を直接指定する方法、歌手名から検索する方法あるいは曲名を検索する方法などがカバーされている。ただし、他の検索方法が利用されてもよい。
その後、プロセサ４０は、ステップＳ１５５で、先に説明したと同様のＩＲ受信処理を実行する。つまり、プロセサ４０はステップＳ１５５でＩＲ受信機４７５からキー操作信号を受け、次のステップＳ１５７で、そのときリモコン送信機８０の決定キー８２３が操作されたかどうか、つまり、検索方法のユーザによる選択が完了したかどうかを判断する。“ＮＯ”ならステップＳ１５５に戻ってＩＲ受信機４７５からのキー操作信号を待つ。
そして、次のステップＳ１５９で、リモコン送信機８０のカーソル移動キー８１９ａ−８１９ｄで移動されたカーソルの位置座標（ＴＶすなわち表示器５−ｎの画面上の座標位置）データを取得する。カーソル位置が図２４の検索方法表示画面４９５でそのとき選択された検索方法の１つを表しているので、このステップＳ１５９では、結局プロセサ４０は、そのときユーザによって選択されたカラオケ検索方法がどれかを知ることができる。実施例では、図２４に示す番号検索方法が選択された場合を想定する。したがって、このステップＳ１５９において、プロセサ４０は、たとえば図２５に示す番号入力画面４９７をＴＶすなわち表示器５−ｎに表示する。
その後、ステップＳ１６１において、プロセサ４０は、予約リストライトポインタを初期化する。予約リストは、たとえば図５のＳＲＡＭ４７１内の適宜の領域に形成され、カラオケモードにおいてユーザが予約したカラオケ番号をリスト形式で登録する。予約リストライトポインタは、そのような予約リストを書き込むとき（登録するとき）に予約リスト位置を指定するポインタであり、後述の予約リストリードポインタは予約リストを読み出すときに予約リスト位置を指定するポインタである。いずれのポインタも、たとえばＳＲＡＭ４７１に形成されたカウンタである。
そして、続くステップＳ１６３において、プロセサ４０は、たとえばＳＲＡＭ４７１の適宜の領域に形成された番号桁数カウンタを初期化する。この番号桁数カウンタは、検索方法としてカラオケ番号を直接入力する方法を採用したとき、入力数値の桁数をカウントする。そして、入力桁数が予め決めた一定値たとえば「５」に達すると、カラオケ番号の入力があったとみなされる。
その後、プロセサ４０は、次のステップＳ１６５において、再びＩＲ受信処理を実行する。そして、ステップＳ１６７において、上述の桁数カウンタのカウント値が「５」に達したかどうか判断する。カラオケ番号入力の途中ではこのステップＳ１６７では“ＮＯ”が判断されるので、プロセサ４０は、続くステップＳ１６９において、ステップＳ１６５で受信したリモコン送信機８０からのリモコン信号がテンキー８２７（図７）のものかどうか判断する。“ＮＯ”ならステップＳ１６５に戻るが、“ＹＥＳ”なら、次のステップＳ１７１において、たとえば図２５（Ｂ）に示すように、そのときユーザが操作したテンキーが表す数値をカラオケ番号の１つの桁として表示する。それとともに、ステップＳ１７３においてプロセサ４０がＳＲＡＭ内の桁数カウンタをインクリメントした後、ステップＳ１６５に戻り、ステップＳ１６７で“ＹＥＳ”が判断されるまで、つまり、所定桁数たとえば「５」のカラオケ番号入力が完了するまで、ステップＳ１６５‐Ｓ１７３を繰り返し実行する。
そして、ユーザの入力桁数が「５」に達した後には、通常であれば、ユーザはそのカラオケ番号を予約するために予約キー８２１（図７）を操作するか、あるいはそのカラオケ番号のカラオケを直ちに再生するため、もしくは予約登録を終了させるために、決定キー８２３を操作する。したがって、ステップＳ１６７で“ＹＥＳ”を判断した後には、プロセサ４０は、ステップＳ１７５で予約キー８２１または決定キー８２３の操作があったかどうか判断する。そして、たとえば５桁のカラオケ番号の入力の後、リモコン送信機８０のそれ以外のキーが操作されると、ステップＳ１７５で“ＮＯ”となり、テップＳ１６５に戻り、予約キー８２１または決定キー８２３が操作されるのを待つ。
そして、予約キー８２１または決定キー８２３が操作されたときには、ステップＳ１７５で“ＹＥＳ”が判断されるので、プロセサ４０は、次のステップＳ１７７において、ＳＲＡＭ４７１内の予約リストにそのとき入力されたカラオケ番号を登録するとともに、ステップＳ１７９において、次の予約登録に備えて、予約リストライトポインタをインクリメントする。図示していないが、図１９や図２０に示すＢＧＭリストと同じく、予約リストには、ユーザが配信を希望する楽曲（カラオケ）のカラオケ番号が含まれるので、予約リストは、楽曲リストとも呼ぶことができるが、この楽曲リストはＳＲＡＭ４７１の所定領域（予約リスト記憶領域）（図示せず）に保持される。したがって、このカラオケモードにおいて、ＳＲＡＭ４７１は、予約リストすなわち楽曲リストの保持手段として機能する。
その後、ステップＳ１８１において、プロセサ４０は、ステップＳ１７５で検出したキー操作は決定キー８２３のものであったのかどうか判断する。“ＮＯ”なら、ステップＳ１６３に戻り、次のカラオケ番号入力を待つ。
ステップＳ１８１で“ＹＥＳ”が判断されたとき、ステップＳ１８３で、プロセサ４０は、予約リストリードポインタを初期化し、ステップＳ１８５でその予約リストが終了したかどうか判断する。具体的には、予約リストライトポインタと予約リストリードポインタとを比較すれば、予約リストに予約カラオケ番号が残っているかどうか判断できる。予約リストが終了していれば、ステップＳ１５９に戻る。
ステップＳ１８５において、予約リストにカラオケ番号が残っていると判断したとき、ステップＳ１８７において、プロセサ４０は、その予約リストからカラオケ番号を読み出す。
ステップＳ１７７では、先のステップＳ１６５‐Ｓ１７３を実行してカラオケ番号を入力した後、予約キー８２１を操作しないで、決定キー８２３を操作した場合でも、そのときのカラオケ番号を予約リストに登録するが、その理由は、カラオケ番号を予約した場合でも予約しなかった場合でも、同じカラオケ番号の読み出し機構（予約リストおよび予約リストリードポインタ）を利用して、カラオケ番号を読み出すようにするためである。
ステップＳ１８５で“ＮＯ”が判断されると、つまり、予約リストの終了ではない場合には、ステップＳ１８９において、プロセサ４０は、フラッシュメモリ４６９から受信待ち背景画像の画像データを読み出して、ＴＶすなわち表示器５−ｎの表示画面上にその受信待ち画像（図示せず）を表示する。この場合の受信待ち画像は、プロセサ４０が小さな労力で表示処理を行うことができるような、極力シンプルな内容のものとする。このように、極力シンプルな内容の受信待ち画像を表示することで、図１７のステップＳ１３３と同様の効果を奏することができる。
次のステップＳ１９１で、プロセサ４０は、Ｖブランク割り込みを禁止する。Ｖブランク割り込みを禁止することによって、図１７のステップＳ１３５と同様の効果を奏することができる。
そして、次のステップＳ１９３で、プロセサ４０は、先のステップＳ１８７で読み出したカラオケ番号をカラオケサーバ２０−１に送信する準備をする。そして、ステップＳ１９５で、先に説明したと同様のＴＣＰ／ＩＰ送受信処理を行って、カラオケサーバ２０−１からのレスポンスとしてそのカラオケ番号の、図２１に示すようなカラオケデータを受信する。このカラオケデータは、ＳＲＡＭ４７１（図５）の適宜の領域に形成されたカラオケデータ記憶領域（図示せず）に書き込まれる。
ステップＳ１９５でＴＣＰ／ＩＰ送受信処理が完了した後には、先にステップＳ１９１で禁止していたＶブランク割り込みを許可し、表示の更新ができるようにする。
そして、ステップＳ１９９において、プロセサ４０は、フラッシュメモリ４６９の画像記憶領域４６９ｂからカラオケ背景画像の画像データを読み出し、ＴＶすなわち表示器５−ｎに、そのカラオケ背景画像を表示する。
その後、ステップＳ２０１で、プロセサ４０は、図２１に示すカラオケデータに含まれるタイトル画像のデータを使ってタイトル表示処理を実行し、そのタイトル表示処理が終わると（ステップＳ２０３）、プロセサ４０は、ステップＳ２０５で、先に説明したと同様のＩＲ受信処理を実行する。つまり、プロセサ４０はステップＳ２０５でＩＲ受信機４７５からキー操作信号を受け、次のステップＳ２０７で、そのときリモコン送信機８０のキャンセルキー８２５が操作されたかどうか、つまり、カラオケの再生を中止するかどうか判断する。“ＮＯ”なら次のステップＳ２０９で歌詞表示処理を実行するとともに、ステップＳ２１１でコーラスＰＣＭの再生処理を実行し、さらにはステップＳ２１３でカラオケＭＩＤＩ再生処理を実行する。つまり、ステップＳ２０９‐Ｓ２１３で、先のステップＳ１９５でＳＲＡＭ４７１のカラオケデータ記憶領域に記憶していたカラオケデータを読み出して、再生する。
その後、プロセサ４０は、ステップＳ２１５でカラオケデータの中の終了コードを検出すると、先のステップＳ２０７でキャンセルキー８２５の操作を検出したときと同様に、ステップＳ２１７で、予約リストリードポインタをインクリメントし、先のステップＳ１８５に戻る。
したがって、このステップＳ１８５で予約したが未再生のカラオケ番号が予約リストに残っていれば、ステップＳ２０７でインクリメントした予約リストリードポインタによって、自動的に次の予約カラオケ番号が指定され、ステップＳ１８７−Ｓ２１５を繰り返し実行し、該当の次の予約カラオケ番号のカラオケデータの再生が自動的に行われ得る。
詳しく説明すると、ステップＳ２０９‐Ｓ２１３を実行することによって１つのカラオケデータの再生が終了し、その後ステップＳ２１５で“ＹＥＳ”が判断された後のステップＳ１９５でカラオケサーバ２０−１に別のカラオケ番号で示される別のカラオケデータの送信を要求する。そして、その要求に応じてサーバ２０−１から、当該別のカラオケデータが送信され、ステップＳ１９５でそれを受信するが、そのとき、プロセサ４０は、ＳＲＡＭ４７１のカラオケデータ記憶領域（図示せず）をその別のカラオケデータで上書きする。つまり、再生済のカラオケデータは、このように新しいカラオケデータによってＳＲＡＭ４７１の該当領域が上書きされることによって、ユーザ端末すなわちＡＶ装置４内には残ることがない。したがって、通常のダウンロード配信とは異なり、データ利用料を安価に抑えることができる。
上述のように、サーバ２０−１からのカラオケデータ（図２１参照）のダウンロードは、ＢＧＭモードおよびカラオケモードのいずれにおいても、１曲ごとに行われ、プロセサ４０は、ＳＲＡＭ４７１に１曲分のカラオケデータのみを格納する。そして、その１曲分のカラオケデータの再生が終了してから、次の１曲分のカラオケデータをダウンロードし、プロセサ４０は、ダウンロードしたカラオケデータを、ＳＲＡＭ４７１に格納されている再生済みのカラオケデータに上書きする。
このように、１曲ダウンロードし、１曲ＳＲＡＭ４７１に格納し、１曲再生し、その後、次の１曲をダウンロードし、その１曲をＳＲＡＭ４７１に上書きし、その１曲を再生する、…、というように、ＡＶ装置４−ｎには、常に１曲分のカラオケデータしか格納されない。このため、ＡＶ装置４−ｎに搭載する記憶装置（実施例ではＳＲＡＭ４７１）の記憶容量を小さくできる。
なお、実施例では、１曲分のカラオケデータのみをＡＶ装置４−ｎに記憶するようにしたが、１以上の所定曲数分のカラオケデータをＡＶ装置４−ｎに記憶するようにすることもできる。たとえば、何曲分をＡＶ装置４−ｎに記憶するかは、搭載した記憶装置の容量にもよるので、コスト等の関係から設定すればよい。
なお、一般的なダウンロードであれば、ＨＤＤなどが必要で、ユーザにカラオケデータを販売することに相当する。一方、ストリーミングであれば、データをサーバから取得しつつ、カラオケデータを再生する。したがって、実施例は、このいずれにも属さないシステムを実現している。
この発明が詳細に説明され図示されたが、それは単なる図解および一例として用いたものであり、限定であると解されるべきではないことは明らかであり、この発明の精神および範囲は添付されたクレームの文言によってのみ限定される。
【図１】
2006041229.tif 000002
【図２】
2006041229.tif 000003
【図３】
2006041229.tif 000004
【図４】
2006041229.tif 000005
【図５】
2006041229.tif 000006
【図６】
2006041229.tif 000007
【図１０】
2006041229.tif 000008
【図７】
2006041229.tif 000009
【図８】
2006041229.tif 000010
【図９】
2006041229.tif 000011
【図１１】
2006041229.tif 000012
【図１２】
2006041229.tif 000013
【図１３】
2006041229.tif 000014
【図１４】
2006041229.tif 000015
【図１５】
2006041229.tif 000016
【図１６】
2006041229.tif 000017
【図１７】
2006041229.tif 000018
【図１８】
2006041229.tif 000019
【図１９】
2006041229.tif 000020
【図２０】
2006041229.tif 000021
【図２１】
2006041229.tif 000022
【図２２】
2006041229.tif 000023
【図２３】
2006041229.tif 000024
【図２４】
2006041229.tif 000025
【図２５】
2006041229.tif 000026
【国際調査報告】
2006041229.tif 000027
2006041229.tif 000028
2006041229.tif 000029
2006041229.tif 000030
2006041229.tif 000031
2006041229.tif 000032
2006041229.tif 000033