JP2004157390A - リクエスト対応型情報提供システム及びリクエスト装置 - Google Patents

Abstract

【課題】リクエスト装置からリクエスト情報を受信した情報提供装置において、極力そのリクエスト情報に応じた情報提供が実現されるようにする。
【解決手段】カラオケ装置が定期的にマスクデータをリクエスト装置に送信し、その送信されたマスクデータを受け取ったリクエスト装置は、更新すべきマスクデータであれば更新記憶する。そしてリクエスト装置２は、検索すべき文字が入力された場合、記憶しているリクエスト用楽曲データとマスクデータとを用いて、その検索結果を表示する。マスクデータが第１のカラオケ装置１ａ用マスクデータであれば、特にマスク対象となっているデータがないため検索結果をそのまま表示する。それに対して、マスクデータが第２のカラオケ装置１ｂ用マスクデータであれば、例えば選曲番号２，５等のマスク対象となっているため検索結果の内のマスク対象の曲名については表示しない。
【選択図】図２

Description

【０００１】
【発明の属する技術分野】
本発明は、受信したリクエスト情報に応じた提供用情報を用いて情報提供を実行する情報提供装置と、リクエスト情報を検索するための検索用データベースを有し、ユーザから受け付けた操作に基づき検索した結果としてのリクエスト情報を情報提供装置に対して送信するリクエスト装置を備えるリクエスト対応型情報提供システム等に関する。
【０００２】
【従来の技術】
従来、例えば楽曲を再生するカラオケ装置と、そのカラオケ装置に所定の楽曲を再生させるための動作指令を送信する遠隔操作装置を備えたカラオケシステムが知られている。このカラオケシステムにおいては、カラオケ装置に対して利用者が希望の曲をリクエストする際、例えば曲名や歌手名などのキーデータと、リクエストに利用するたとえば数桁の英数字などからなるリクエストコードが組となって記載されているリクエスト用の冊子（いわゆる早見本）を参照して、所望の曲に対応するキーデータからリクエストコードを検索した上で、そのリクエストコードをリクエスト装置に入力することによってリクエストを実現していた。
【０００３】
一方、昨今の通信インフラなどデータ配信技術の向上により、冊子の配本スピードがカラオケ曲の追加／更新のスピードに対して相対的に低下してしまう傾向にある。そのため、リクエスト装置内に検索用データベースを保持することによって、前記キーデータによる検索機能を実現し、利用者は所望の曲に対応するキーデータをリクエスト装置に入力することによって、該当するプログラムを検索し且つ選択し、リクエストを実現するカラオケシステムも開発されている（例えば、特許文献１参照）。
【０００４】
このカラオケシステムにおいては、カラオケ装置がホスト装置から新曲の配信を受けると、その新曲検索用の追加レコードをカラオケ装置からリクエスト装置に送信することによって、迅速に新曲のリクエストが可能となる。
【０００５】
【特許文献１】
特許第３０８９５２９号公報
【０００６】
【発明が解決しようとする課題】
ところで、例えば同じ店舗内に存在する複数のカラオケ装置同士であっても、リクエスト可能な曲に違いがある場合も考えられる。この原因としては大きく分けて２つあり、一つは機器の提供価格や利用契約の差異によって再生可能な曲数を機器ごとに変える場合などである。例えば営業政策的な理由によって、高価な機種の場合には全てのカラオケ曲データを蓄積して全て使用可能となっているが、廉価な機種の場合には蓄積するカラオケ曲データ数を制限して使用できる曲を限定することが考えられる。また、利用契約によって使用できるカラオケ曲データ数を制限することも考えられる。これらはカラオケ曲データが物理的にカラオケ装置内に存在しない場合である。
【０００７】
一方、カラオケ装置内にカラオケ曲データは存在していても、例えばユーザ層に応じて一部のカラオケ曲については演奏をさせないといった施策的観点からの制限も考えられる。例えば利用者の年齢層が低い場合にはアダルト向けの映像を伴うカラオケ曲の再生を禁止するとか、祝宴に供されるカラオケ装置にあっては、失恋の曲など雰囲気にふさわしくない曲の再生を禁止する、といったことである。
【０００８】
このようにカラオケ装置毎に再生可能な曲が異なる場合、次のような不都合が生じる。つまり、リクエスト装置が有する検索用データベースは、カラオケ装置の内で最も広範なリクエストが可能なものに対応させるおくことが好ましい。つまり、全曲再生可能なカラオケ装置に対応するよう全曲分の検索用データベースを持つようにするのである。一般に、リクエスト装置はどのカラオケ装置であっても使用できることが好ましいからである。逆に、特定のカラオケ装置には特定のリクエスト装置しか使用できないとなると管理等の面で非常に不自由なものとなる。
【０００９】
しかしながら、全曲再生可能なカラオケ装置に対応するよう全曲分の検索用データベースを持つリクエスト装置を準備した場合、汎用性は確保できるが、今度は、リクエスト装置ではリクエスト可能であるにもかかわらずカラオケ装置においてそのリクエストに対応した再生ができない状況が生じることとなる。もちろん、リクエスト自体は受け付け、再生時に「再生不可能」「再生禁止」といった報知をする対処も考えられるが、そのような対処が頻繁に生じると利用者としては興醒めしてしまう可能性がある。そのため、リクエスト自体が受け付けられないようにする対処が好ましい。
【００１０】
なお、このような問題は、カラオケシステムには限らず、リクエスト情報を検索するための検索用データベースを有し、ユーザから受け付けた操作に基づき検索した結果としてのリクエスト情報を情報提供装置に対して送信し、その受信したリクエスト情報に応じた提供用情報を用いて情報提供を実行する情報提供装置とからなるリクエスト対応型情報提供システムであれば同様に発生する。
【００１１】
そこで本発明は、リクエスト情報をリクエスト装置から情報提供装置に対して送信すれば、そのリクエスト情報を受信した情報提供装置においては、極力そのリクエスト情報に応じた提供用情報が存在し、リクエストに応じた情報提供が実現されるようにすることを目的とする。
【００１２】
【課題を解決するための手段及び発明の効果】
（１）上述した問題点を解決するためになされた本発明のリクエスト対応型情報提供システムは、情報提供装置にて情報提供できる提供用情報に対応するリクエスト情報と、リクエスト装置が有する検索用データベースに存在するリクエスト情報とが必ずしも一致しない状況もあり得ることを前提としたものである。例えばカラオケシステムであれば、複数の機種を準備し、ある機種ではリクエスト装置が有する検索用データベースに存在する全てのリクエスト情報に対応するカラオケ曲を演奏可能とし、別の機種では一部のカラオケ曲については演奏できないようにすることも考えられる。これは、ハードディスク等のデータ記憶記憶手段における記憶容量といった主に物理的観点、利用契約や営業政策的な観点などの事情である。また、同じ機種であっても、ユーザ層に応じて（カラオケ曲自体は存在するが）一部のカラオケ曲については演奏をさせないといった施策的観点からの事情も考えられる。例えばアダルト向け・キッズ向けというように、客層に応じてリクエスト対象曲を絞り込んだり逆にリクエスト対象から積極的に外すようにプロテクトするケースである。
【００１３】
このような理由で、情報提供装置にて情報提供できる提供用情報に対応するリクエスト情報と、検索用データベースに存在するリクエスト情報との不整合が生じるため、何ら対処しないと、リクエスト装置では検索してリクエスト可能であるのに、情報提供装置では情報提供できない、という不都合が発生する。
【００１４】
この不都合解消のために本発明のリクエスト対応型情報提供システムでは、情報提供装置が、リクエスト装置の有する検索用データベースに存在するリクエスト情報の内で、情報提供装置にて情報提供できる提供用情報に対応するリクエスト情報とそれ以外のリクエスト情報とを区別するためのマスクデータをリクエスト装置へ送信し、そのマスクデータを受信及び記憶したリクエスト装置は、情報提供装置にて情報提供できる提供用情報に対応するリクエスト情報のみを検索結果として有効に扱うよう、記憶したマスクデータを用いて調整する。
【００１５】
これによって、リクエスト装置での検索において有効な検索結果として扱われたリクエスト情報をリクエスト装置から情報提供装置に対して送信すれば、そのリクエスト情報を受信した情報提供装置においては、極力そのリクエスト情報に応じた提供用情報が存在し、リクエストに応じた情報提供が実現される。
【００１６】
（２）このリクエスト装置におけるマスクデータを用いた調整に関しては、例えば請求項２に示すように、マスクデータを用いて、検索用データベース中のリクエスト情報の内、情報提供装置にて情報提供できる提供用情報に対応するリクエスト情報のみを検索対象とし、そうでないリクエスト情報は検索対象から外して検索を実行することが考えられる。このように検索対象から予め外しておけば、情報提供装置にて情報提供できないリクエストが検索結果として抽出されること自体がなくなる。また、請求項３に示すように、検索結果を表示する表示手段を有し、その表示手段に検索結果を表示する際には、マスクデータを用いて、検索用データベースの検索した結果の内、情報提供装置にて情報提供できる提供用情報に対応するリクエスト情報であるもののみを表示し、そうでない場合は表示しないようにしてもよい。このようにすれば、表示手段には、情報提供装置にて情報提供できないリクエストが検索結果として表示されることがない。したがって、その表示された検索結果中から選択したリクエスト情報を情報提供装置に対して送信すれば、極力リクエストに応じた情報提供が実現されることとなる。
【００１７】
（３）リクエスト装置内のマスクデータは適宜更新される必要があるが、情報提供装置からリクエストへのマスクデータは、次のようにして送信されるように構成することが考えられる。
まず、請求項４に示すように、リクエスト装置が、所定のタイミングで情報提供装置に対してマスクデータの送信を要求することが考えられる。そして、情報提供装置がそのリクエスト装置からの送信要求に応じてマスクデータをリクエスト装置に対して送信し、その送信されたマスクデータをリクエスト装置は受信して記憶するのである。この場合の「所定のタイミング」としては、例えば請求項５に示すようにすることが考えられる。つまり、リクエスト装置が（そのリクエスト装置自体の）電源をオン・オフする電源スイッチを有しており、その電源スイッチがオンされた場合、または、電源オン後の所定時間毎の少なくともいずれかのタイミングでマスクデータの送信要求を行うのである。
【００１８】
また、請求項６に示すように、情報提供装置が所定のタイミングでマスクデータをリクエスト装置に対して送信するようにしてもよい。そして、その送信されたマスクデータをリクエスト装置は受信して記憶するのである。この場合の「所定のタイミング」としては、例えば請求項７に示すようにすることが考えられる。つまり、情報提供装置が（その情報提供装置自体の）電源をオン・オフする電源スイッチを有しており、その電源スイッチがオンされた場合、または、電源オン後の所定時間毎の少なくともいずれかのタイミングでマスクデータをリクエスト装置に対して送信するのである。
【００１９】
（４）また、リクエスト装置内のマスクデータの更新に関しては、次のような工夫をすることが考えられる。例えば請求項８に示すように、情報提供装置が、マスクデータの内容が更新される度に所定の識別情報の値をユニークに変化させ、その識別情報をマスクデータに付加してリクエスト装置に送信する。そして、その送信されたマスクデータを受信したリクエスト装置は、従前のマスクデータに付加された識別情報と、今回受信したマスクデータに付加された識別情報を比較し、両者が異なっている場合にのみ更新記憶するのである。
【００２０】
このようにすれば、実質的に変更のないデータの更新作業がなされることがなく、処理負荷が低減される。
また、情報提供装置が、情報提供できる提供用情報の内容に応じて機種の区別が設定されているのであれば、請求項９に示すようにしてもよい。つまり、その機種の区別をするための機種情報をマスクデータに付加してリクエスト装置に送信する。そして、その送信されたマスクデータを受信したリクエスト装置が、従前のマスクデータに付加された機種情報と、今回受信したマスクデータに付加された機種情報を比較し、両者が異なっている場合は更新記憶するのである。
【００２１】
このようにすれば、マスクデータ自体の比較をするまでもなく機種情報の比較のみで更新の必要の有無が判断できるため、さらに処理負荷が低減される。
（５）なお、請求項１０に示すように、請求項１〜９の何れかに記載のリクエスト対応型情報提供システムに用いられるリクエスト装置であって、当該各請求項においてリクエスト装置に関して記載された構成を備えるリクエスト装置として実現することもできる。
【００２２】
このようなリクエスト装置であれば、上述したリクエスト対応型情報提供システムに用いられることによって、上述の効果を発揮する上で有意な役割を果たすこととなる。
【００２３】
【発明の実施の形態】
以下、本発明が適用された実施例について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り種々の形態を採りうることは言うまでもない。
【００２４】
図１は、本発明のリクエスト対応型情報提供システムの一実施例としてのカラオケシステムの構成を示すブロック図である。本実施例のカラオケシステムはカラオケ装置１ａとリクエスト装置２、またはカラオケ装置１ｂとリクエスト装置２とから構成される。なお、カラオケ装置１ａとカラオケ装置１ｂは、記憶している演奏曲データの内容が異なるか、あるいは記憶している演奏曲データは同じであるが再生が禁止されている曲に違いがある。したがって、両者を区別して説明する必要がある場合には第１のカラオケ装置１ａ、第２のカラオケ装置１ｂというように個別に記載し、両者を区別して説明する必要がない場合には単にカラオケ装置１ａ，１ｂと記載することにする。一方、リクエスト装置２はたとえ複数存在したとしてもそれらに構成に違いはなく、第１のカラオケ装置１ａ、第２のカラオケ装置１ｂのいずれにも用いることができるようになっている。但し、上述のように、第１のカラオケ装置１ａと第２のカラオケ装置１ｂは、記憶している演奏曲データの内容が異なるか、あるいは記憶している演奏曲データは同じであるが再生が禁止されている曲に違いがあるため、それに対応するための所定の処理を実行する。その所定の処理については後述する。
【００２５】
［カラオケ装置１ａ，１ｂの構成］
カラオケ装置１ａ，１ｂは、図１に示されるように、図示しないホストコンピュータに公衆回線などの通信ネットワークを介して接続し各種の情報を送受信するモデム１２、カラオケ装置１ａ，１ｂ全体の制御を司るＣＰＵ１０、カラオケ用の音楽情報や画像情報その他各種データを記憶しているハードディスク１１、演奏の再生を行う再生装置１３、音楽情報にかかる電気信号を増幅等するアンプ１７、アンプ１７からの電気信号を入力して伴奏曲及び利用者の歌声等を流すスピーカ１８、利用者の歌声等をアンプ１７に入力するためのマイクロフォン（以下、単にマイクと称す。）１６、ハードディスク１１に記憶された画像情報に基づいて映像情報である背景画及び歌詞等を再生する映像再生装置９、再生された映像を表示するＣＲＴ１９、リクエスト装置２から発光される赤外線等によるリモコン信号を受光するリモコン受光部１４及びリクエスト装置２と無線で双方向通信（例えばＢｌｕｅｔｏｏｔｈ規格に基づく無線通信やＩｒＤＡ（Ｉｎｆｒａｒｅｄ Ｄａｔａ Ａｓｓｏｃｉａｔｉｏｎ）を用いた光通信）するための無線通信装置１５を備えている。この内、ハードディスク１１、モデム１２、再生装置１３、リモコン受光部１４、無線通信装置１５及び映像再生装置９はＣＰＵ１４に接続されている。
【００２６】
上述したモデム１２は、信号の変調および復調を行う変復調装置であり、ＣＰＵ１０の制御の下、公衆回線を通じてホストコンピュータにアクセス可能に構成されている。それによって、モデム１２は公衆回線を介してホストコンピュータから送られてくる演奏曲データの追加分（新曲のデータ等）を受信したり、その演奏曲データと同じくして配信されるリクエスト用楽曲データ（図５（ａ）参照）を受信する。
【００２７】
ここで受信された演奏曲データ、リクエスト用楽曲データ及びマスクデータはハードディスク１１にファイルとして記憶される。そして、演奏曲データはカラオケ演奏時に読み出され演奏処理に用いられ、リクエスト用楽曲データ及びマスクデータは無線通信装置１５を通じてリクエスト装置２へ送信される。
【００２８】
例えばカラオケ演奏処理では、ＣＰＵ１０から出力される演奏曲データは再生装置１３においてアナログの演奏音信号に変換された後、アンプ１７へ送られて電気的に増幅される。このアンプ１７は、マイク１６を介して入力される利用者（歌唱者）の歌唱音信号と適度な割合でミキシングするもので、ミキシングされた歌唱音信号と演奏音信号は、アンプ１７からスピーカ１８に出力され、音声及び演奏音となってスピーカ１８から外部へ出力される。一方、映像再生装置９は、ＣＰＵ１４の制御の下、ハードディスク１１から読み出された画像情報に基いて歌詞や背景画を再生してＣＲＴ１９に出力し、ＣＲＴ１９はそれらの表示を行うものである。それにより、ＣＰＵ１９においては、歌詞データが映像データと合成されて背景映像とともに歌詞テロップが表示されるようになっている。このような構成のため、利用者は、ＣＲＴ１９に表示される歌詞テロップを参照しながら、スピーカ１８より流れるカラオケ演奏にあわせ、マイク１６を使って歌唱できるようになっている。
【００２９】
なお、本実施例の第１のカラオケ装置１ａ、第２のカラオケ装置１ｂは、記憶している演奏曲データの内容が異なるか、あるいは記憶している演奏曲データは同じであるが再生が禁止されている曲に違いがある。例えば図２（ａ），（ｂ）に示すように、第１のカラオケ装置１ａは全ての曲について再生可能（あるいは再生が禁止されていない）であり、第２のカラオケ装置１ｂは一部の曲について再生不可能（あるいは再生が禁止されている）とされている。
【００３０】
これらの違いが生じる原因としては大きく分けて２つあり、一つはカラオケ装置１ａ，１ｂの提供価格や利用契約の差異によって再生可能な曲数を機器ごとに変える場合などである。例えば第１のカラオケ装置１ａが高価な機種の場合には、ハードディスク１１のデータ記憶容量も十分にあって全てのカラオケ曲データを蓄積しているが、例えば第２のカラオケ装置１ｂが廉価な機種の場合にはハードディスク１１のデータ記憶容量に制限があったり、営業政策上、蓄積可能なカラオケ曲データ数を制限する、といったことである。また、ハードディスク１１のデータ記憶容量自体は余裕があっても、利用契約によって蓄積するカラオケ曲データ数を制限することも考えられる。これらはカラオケ曲データが物理的にカラオケ装置１ａ，１ｂ内に存在しない場合である。
【００３１】
一方、施策的観点からの対処による要因も考えられる。例えば利用者の年齢層が低い場合にはアダルト向けの映像を伴うカラオケ曲の再生を禁止するとか、祝宴に供されるカラオケ装置にあっては、失恋の曲など雰囲気にふさわしくない曲の再生を禁止する、といったことである。このような再生禁止の設定は、カラオケ装置１ａ，１ｂ毎に設定できるようにされている。通常、カラオケボックスでは、各室に１台のカラオケ装置１ａ，１ｂが設置されており、上記再生禁止の設定は、各室単位で設定され、また、各室の、例えば使用料金の設定に応じて、設置されるカラオケ装置１ａ，１ｂの機種等が選択され、設置されている。
【００３２】
［リクエスト装置２の構成］
一方、リクエスト装置２は、カラオケボックスの各室に設置されたカラオケ装置１ａ，１ｂに対応して各室毎に１台もしくは複数台配置されている。また、図１に示すように、リクエスト装置２全体の制御を司るＣＰＵ２０、カラオケ装置１ａ，１ｂと無線で双方向通信（Ｂｌｕｅｔｏｏｔｈ やＩｒＤＡ）するための無線通信装置２１、カラオケ装置１ａ，１ｂに対して赤外線等によるリモコン信号を発光するリモコン発光部２２、表示装置としての液晶表示部２３、入力手段としての入力装置２４及びＳＲＡＭ２５、ニッカドなどの二次電池からなる電源２６、その電源２６に接続された電源スイッチ２７を備えている。
【００３３】
リクエスト装置２は、無線通信装置２１を介してカラオケ１ａ，１ｂから受信したマスクデータ（図５（ｂ）参照）をファイルとしてＳＲＡＭ２５に記憶する。また、このマスクデータの受信と同じ機会あるいは別の機会に、リクエスト用楽曲データ（図５（ａ）参照）も受信し、これもＳＲＡＭ２５に上記と同様にファイルとして記憶される。このリクエスト用楽曲データは、選曲番号、曲名、その曲を歌った歌手名、その曲が属するジャンル情報、その曲のリリース年月日などが対になったものであり、例えば第１のカラオケ装置１ａあるいは第２のカラオケ装置１ｂのいずれかにおいて例えば１万曲のカラオケ曲の再生が可能であるならば、その１万曲分のリクエスト用楽曲データが存在する。これが「検索用データベース」を構成することとなる。ここで、ＳＲＡＭ２５は、電源スイッチ２７の遮断時にも記録された情報を保持可能なメモリである。
【００３４】
また、入力装置２４は、利用者によって操作されるものであり、任意の曲の選択、演奏音のキーの調整、演奏と歌との音量バランスの調整、その他エコー、音量、トーンなど各種調整を行うためのものであり、この入力装置２４が操作されることによって入力あるいは選択された曲番号や曲名等は液晶表示部２３に表示される。入力装置２４は、図３に示すように、リクエスト装置２の表側の中央にテンキーが設けられており、その他にも選択キーや各種機能キーが設けられている。そして、設けられたテンキーを用いて数字を入力することもできるし、文字を入力することもできる。文字入力は、例えば曲名や歌手名の頭に付く文字で検索する場合などに利用される。この文字入力に関しては、例えば現在一般に見られる携帯電話での文字入力方法に倣ったものとすることが考えられる。これによって検索すべき曲名を入力することができる。例えば、例えば「あ」を入力したければテンキーの「１」を１回押下した後で「＞」のキーを押下し、「ろ」を入力したければ「９」のキーを５回押下した後に「＞」のキーを押下する。上述の曲名の頭に付く文字で検索する場合であれば、リクエスト装置２は図３（ｂ）に示すように条件（この場合は頭に「あ」が付く曲名）に合致する曲名を表示し、その最上部に表示されている曲名の横に黒丸で示されるカーソルを表示する。利用者はリクエスト装置２の表側の下部に示される矢印キー（←→↑↓）を押下してカーソルを移動させ、所望の曲を選択した上で選択キーを押下することによってリクエスト曲を確定する。
【００３５】
このようにリクエスト曲が確定すると、ＣＰＵ２０はリモコン発光部２２を通じて、選択された曲名に対応する曲の選曲番号（選曲情報）を赤外線信号として送信する。カラオケ装置１ａ，１ｂは、リモコン受光部１４にてその赤外線信号を受信すると、受信信号から解析した選曲番号に応じたカラオケ曲の演奏を行う。なお、リクエスト装置２では、電源スイッチ２７をオンにすると、電源２６からＣＰＵ２０、無線通信装置２１、リモコン発光部２２、液晶表示部２３、ＳＲＡＭ２５等に電力が供給される。また、電源２６は、リクエスト装置２をクレードル（図示せず）にセットしたときに充電されるようになっている。
【００３６】
［リクエスト装置２、カラオケ装置１ａ，１ｂにて実行される処理］
ところで、本実施例のリクエスト装置２は、上述のように第１のカラオケ装置１ａあるいは第２のカラオケ装置１ｂのいずれにも用いることができる。但し、第１のカラオケ装置１ａ、第２のカラオケ装置１ｂは、記憶している演奏曲データの内容が異なるか、あるいは記憶している演奏曲データは同じであるが再生が禁止されている曲に違いがある。例えば図２（ａ），（ｂ）に示すように、第１のカラオケ装置１ａは全ての曲について再生可能（あるいは再生が禁止されていない）であり、第２のカラオケ装置１ｂは一部の曲について再生不可能（あるいは再生が禁止されている）とされている。通常、カラオケボックスでは、第１のカラオケ装置１ａ及び台２のカラオケ装置１ｂは、異なる室に設置されている。したがって、リクエスト装置２は、カラオケボックスの各室において現在、自分と対になっているカラオケ装置１ａ，１ｂにて再生可能な曲の中からのみリクエストを受け付けるように対処する必要がある。
【００３７】
この対処として本実施例のリクエスト装置２は、ＳＲＡＭ２５に記憶されているリクエスト用楽曲データ（図５（ａ）参照）と、直近にカラオケ装置１ａ，１ｂから受信してＳＲＡＭ２５に記憶したマスクデータとを用いて、所定の処理を行う。その処理内容を概念的に示すと図２（ｃ）のようになる。つまり、直近に受信して記憶されたマスクデータが第１のカラオケ装置１ａ用マスクデータであれば、特にマスク対象となっているデータがないため、リクエスト装置２では、記憶しているリクエスト用楽曲データの全てを液晶表示部２３に表示可能である。それに対して、直近に受信して記憶されたマスクデータが第２のカラオケ装置１ｂ用マスクデータであれば、例えば選曲番号２，５等のマスク対象となっているため、リクエスト装置２では、記憶しているリクエスト用楽曲データの内、そのマスク対象の曲名については液晶表示部２３に表示しないようにする。
【００３８】
その具体的な処理について、図４のフローチャート等を参照して説明する。
図４はリクエスト装置２において実行される曲名検索によるリクエスト処理を示しており、最初のステップ１０にて曲入力バッファをクリアした後、利用者からの文字入力があるか否か判断する（Ｓ２０）。そして、文字入力があれば（Ｓ２０：はい）、その入力された文字を曲名入力バッファに追加する（Ｓ３０）。そして、曲名入力バッファの内容をキーとし、ＳＲＡＭ２５内の検索用データベースから条件に合致するものを検索する（Ｓ４０）。なお、このステップＳ４０の処理が検索手段に相当する。そして、その検索結果に対して、ＳＲＡＭ２５に保存しているマスクデータを適用し、有効曲のみを抽出した後（Ｓ５０）、そのマスク適用後の検索結果を液晶表示部２３に表示する（Ｓ６０）。なお、このステップＳ６０の処理が検索結果表示手段に相当し、ステップＳ５０の処理が有効曲抽出手段に相当する。そして、表示対象曲があるか否か判断し（Ｓ７０）、表示対象曲がある場合には（Ｓ７０：はい）、仮の選曲対象を、液晶表示部２３に表示している曲とし、カーソルを最上部に合わせて表示する（Ｓ８０）。
【００３９】
ここで、入力された文字が「あ」であれば、リクエスト装置２が第１のカラオケ装置１ａと対で用いられている場合には図３（ｂ）に示すように表示され、リクエスト装置２が第２のカラオケ装置１ｂと対で用いられている場合には図３（ｃ）に示すように表示される。つまり、図２（ｃ）を用いて上述したように、リクエスト装置２が第１のカラオケ装置１ａと対で用いられている場合にはリクエスト装置２のＳＲＡＭ２５内に第１のカラオケ装置１ａ用マスクデータが記憶されているが、この場合は特にマスク対象となっているデータがないため、図３（ｂ）に示すように、頭に「あ」が付く曲名が全て表示される。一方、リクエスト装置２が第２のカラオケ装置１ｂと対で用いられている場合にはリクエスト装置２のＳＲＡＭ２５内に第２のカラオケ装置１ｂ用マスクデータが記憶されているが、この場合はマスク対象曲があるため、図３（ｃ）に示すように、図３（ｂ）では表示されていた曲の一部が表示されなくなっている。もちろん、液晶表示部２３に一度に表示できる曲数に限りがあるため、いずれの場合も検索結果の曲数が多ければ最初に表示される曲名は検索結果の一部となる。その場合は、カーソルを動かすことで順次スクロール表示されるようになっている。
【００４０】
図４の処理説明に戻り、次のステップＳ９０では、リクエスト装置２の表側の下部に示される矢印キー（←→↑↓）の内の「↑」のキーが押されたか否か判断し、押された場合には（Ｓ９０：はい）、仮選曲対象を、現時点でのカーソルに対応する曲の直上に表示している曲とし、カーソルを該当部に合わせて表示する（Ｓ１００）。なお、図３（ｂ）（ｃ）に示すように、検索結果として最初に表示される曲の上にカーソルが存在している状態ではカーソル移動は行わない。また、「↑」キーではない場合は（Ｓ９０：いいえ）、「↓」のキーが押されたか否か判断し（Ｓ１１０）、押された場合には（Ｓ１１０：はい）、仮選曲対象を、現時点でのカーソルに対応する曲の直下に表示している曲とし、カーソルを該当部に合わせて表示する（Ｓ１２０）。なお、例えば検索結果が１０曲存在するが例えば図３（ｂ）に示すように最初の５曲のみを表示した状態で、カーソルがその表示状態における最下に位置する曲に合わせて表示されている場合であれば、スクロール表示されることによって２〜６番目の曲が表示され、その６番目の曲の位置にカーソルが移動することとなる。それ以降の曲に関しても同様である。もちろん、そのようにしてスクロール表示して５〜１０番目の曲が表示され、その１０番目の曲の位置にカーソルが移動している状態では、それ以下の曲は存在しないため、当然ながらカーソル移動は行わない。
【００４１】
そして、「↑」キーでも「↓」キーでもなく、選曲キーが押された場合には（Ｓ１３０：はい）、仮選曲対象に対応（つまりカーソル位置に対応）する選曲コードをリモコン発光部２２からカラオケ装置１ａ，１ｂに向けて送信する（Ｓ１４０）。その後は、Ｓ２０へ戻る。
【００４２】
次に、リクエスト装置２がカラオケ装置１ａ，１ｂからマスクデータを受信してＳＲＡＭ２５に記憶する処理について図５、図６を参照して説明する。
図６のフローチャートは、図４のリクエストに係る処理と並行して実行される処理である。
【００４３】
最初のステップＳ２１０では、カラオケ装置１ａ，１ｂからの（無線通信）通信があるか否か判断し、通信があった場合には（Ｓ２１０：はい）、Ｓ２２０へ移行し、無線通装置２１を介してマスクデータ機種コードとリリース番号を取得する。ここでカラオケ装置１ａ，１ｂから送信されるマスクデータの構成について、図５（ｂ）を参照して説明する。第１のカラオケ装置１ａには第１のカラオケ装置１ａ用のマスクデータが記憶され、第２のカラオケ装置１ｂには第２のカラオケ装置１ｂ用のマスクデータが記憶されている。各マスクデータは、機種コードとリリース番号に加え、選曲番号に対応してマスク内容が「１」又は「０」で設定されている。ここでマスク内容「１」は「マスクしない」こと、つまりリクエスト対象として有効にすることを意味し、マスク内容「０」は「マスクをする」こと、つまりリクエスト対象として無効にすることを意味する。そして、リリース番号は、第１のカラオケ装置１ａ用のマスクデータ、第２のカラオケ装置１ｂ用のマスクデータそれぞれにおいて、更新される毎にインクリメントされる。また、機種コードは第１のカラオケ装置１ａの場合を「０１」、第２のカラオケ装置１ｂの場合を「０２」と設定してある。なお、この機種コードは、例えばカラオケ装置の製品種類毎に区別した内容としてもよいし、あるいはカラオケ装置単位で区別可能な内容としてもよい。つまり、同じ製品種類であっても装置が異なればそれらを区別するということである。この場合の機種コードとしては、例えば製造番号等のシリアル番号を用いることが考えられる。カラオケボックスの運営者が営業政策的な観点から使用できる曲を制限する場合には、同じ製品種類であっても区別する必要があるため、このような機種コードの設定が必要となってくる。
【００４４】
図６に戻り、上述したマスクデータの機種コードとリリース番号を取得したリクエスト装置２は、その取得した機種コードがＳＲＡＭ２５に現在保持している機種コードと異なるか否かを判断する（Ｓ２３０）。なお、このステップＳ２３０の処理が、機種判断手段に相当する。機種コードが同じ場合は（Ｓ２３０：いいえ）、今度は取得したリリース番号がＳＲＡＭ２５に現在保持しているリリース番号と異なるか否かを判断する（Ｓ２４０）。なお、このステップＳ２４０の処理が、識別情報判断手段に相当する。このリリース番号も同じであれば（Ｓ２４０：いいえ）、そのままステップＳ２１０へ戻るが、リリース番号が異なる場合は（Ｓ２４０：はい）、ステップＳ２５０へ移行して、カラオケ装置１ａ，１ｂからマスクデータ自体及びリクエスト用楽曲データを取得し、ＳＲＡＭ２５に更新記憶する。一方、Ｓ２３０にて肯定判断、つまり機種コードが異なる場合は、リリース番号の比較処理（Ｓ２４０）をすることなくステップＳ２５０へ移行し、マスクデータを取得・更新記憶する。
【００４５】
本実施例のカラオケ装置１ａ，１ｂは、図１には示さないが電源スイッチを有しており、その電源スイッチをオンすることによって、装置内の各部に電源が供給されるようになっている。そして、電源スイッチがオンされた場合、及びその後は所定時間毎（例えば１０分毎、３０分毎、１時間毎など）に、無線通信装置１５を介してリクエスト装置２に対して通信を行い、マスクデータの送信を行う。したがって、リクエスト装置２は、このカラオケ装置１ａ，１ｂから送信されるマスクデータを受信して、必要ならばＳＲＡＭ２５に更新記憶する。
【００４６】
図６のステップＳ２３０にて肯定判断となる場合というのは、例えばそれまで第１のカラオケ装置１ａのために使用されていたリクエスト装置２が第２のカラオケ装置１ｂのために使用されるようになった場合、あるいはその逆の場合などを想定している。つまり、例えばカラオケボックスにおいて、リクエスト装置２が配置されている室が変わってカラオケ１ａ，１ｂの機種が変わった場合である。図６の処理を実行、即ち、ステップＳ２５０へ移行し、マスクデータを取得、更新記憶することで、リクエスト装置２は、第１のカラオケ装置１ａ、第２のカラオケ装置１ｂのいずれにも用いることができる。それでいながら、いずれに用いた場合であっても、現在自分の相手となっているカラオケ装置１ａ，１ｂにて再生可能な曲の中からのみ検索結果を表示することとなり、自分の相手のカラオケ装置１ａ，１ｂにて再生できない曲のリクエストを受け付けることを適切に防止できる。
【００４７】
なお、上述したカラオケ装置１ａ，１ｂからリクエスト装置２へのマスクデータの送信間隔によっては、状況の変化（つまり対となるカラオケ装置１ａ，１ｂの変更）に対して一時的にマスクデータの更新が追いつかない場合もあり得る。しかし、マスクデータの更新がなされればその不都合も解消されるため、カラオケ装置１ａ，１ｂからのマスクデータの送信間隔を短くすれば、実質的な不都合をほとんど解消することが可能である。特に、カラオケボックスでは、利用者がフロントで受け付けを済ませたときにリクエスト装置２を受け取って自分が利用する室に持ち込む場合が多く、マスクデータの送信間隔を短くすれば、短時間でその室に設置されたカラオケ装置１ａ，１ｂと適合するリクエスト装置２となり、不都合を解消することができる。
【００４８】
また、図６のＳ２４０にて肯定判断となる場合というのは、例えば新曲が配信されてカラオケ装置１ａ，１ｂにて再生できる曲が増えた場合などである。そこで、カラオケ装置１ａ，１ｂにて新曲の配信を受けた場合の処理について図７のフローチャートを参照して説明する。なお、例えば新曲の配信は１日に１回、公衆回線にて接続される図示しないホストとモデム１２（図１参照）を介して通信し、新曲があればホストから配信を受けるようになっている。なお、本実施例では、カラオケ装置１ａ，１ｂは、新曲の配信があると、新たなリクエスト用楽曲データをリクエスト装置２へ無線通信装置２１を介して送るように構成されている。
【００４９】
図７の最初のステップＳ３１０において追加曲を受信すると、次に、マスクデータ内に追加曲の選曲番号を追加し、対応するビットを全て「０」とする（Ｓ３２０）。そして、自装置において何らかの再生制限設定がされているか否かを判断する（Ｓ３３０）。この再生制限設定に関しては上述したが、簡単に繰り返しておくと、例えば利用者の年齢層が低い場合にはアダルト向けの映像を伴うカラオケ曲の再生を禁止するとか、祝宴に供されるカラオケ装置にあっては、失恋の曲など雰囲気にふさわしくない曲の再生を禁止する、といった施策的観点からの対処である。
【００５０】
そして、再生制限設定がされていない場合には（Ｓ３３０：いいえ）、次に、受信した曲がその再生制限に該当せずに自装置にて再生可能であるか否かを判断する（Ｓ３４０）。この判断に際しては、例えば再生制限の種類を示す識別コードを、配信される曲データ中（例えばヘッダ部分等）に含めておき、カラオケ装置１ａ，１ｂに設定されている再生制限対象の識別コードと一致しなければ再生可能であると判断する、といったことが考えられる。
【００５１】
再生制限設定がされていない場合（Ｓ３３０：いいえ）で且つ受信した曲が再生制限対象曲に該当せずに再生可能である場合（Ｓ３４０：はい）には、ステップＳ３５０へ移行し、マスクデータ内の追加曲の選曲番号に対応するビットを「１」（マスクしない＝検索可を意味する）とする。次に、ステップＳ３６０へ移行し、全ての追加曲についてビット設定が完了したか否かを判断し、完了している場合（Ｓ３６０：はい）には、マスクデータのリリース番号をインクリメントし（Ｓ３７０）、処理を終了する。
【００５２】
また、ステップＳ３６０において全ての追加曲についてビット設定が完了していない場合（Ｓ３６０：いいえ）には、Ｓ３２０へ戻り、ステップＳ３２０〜Ｓ３５０の処理を繰り返す。
なお、リクエスト用楽曲データ（図５（ａ）参照）とは、ハードディスク１１に格納されている全ての演奏曲データに対応するデータベースである。
【００５３】
一方、再生制限設定がされている場合（Ｓ３３０：はい）、あるいは、受信した曲が再生制限に該当して再生不可能である場合（Ｓ３４０：いいえ）には、マスクデータ内の追加曲の選曲番号に対応するビットを「０」（マスクする＝検索不可能を意味する）のままとして、ステップＳ３６０へ移行する。
【００５４】
なお、図８は、カラオケ装置１ａ，１ｂにて実行されるカラオケ演奏に係る処理を示すフローチャートである。
リクエスト装置２のリモコン発光部２２から送信された選曲番号をリモコン受光部１４にて受信、という形で利用者からの選曲番号を受け付けると（Ｓ４１０）、その選曲番号に対応する演奏曲データがハードディスク１１内に存在するか否かを判断する（Ｓ４３０）。そして、該当曲が存在すれば（Ｓ４３０：はい）、演奏を開始し（Ｓ４４０）、該当曲が存在しなければ（Ｓ４３０：いいえ）、選曲不可能であることをＣＲＴ１９に表示する（Ｓ４５０）。
【００５５】
以上、本実施例のカラオケシステムによれば、次のような効果が得られる。
（イ）本実施例の第１のカラオケ装置１ａは全ての曲について再生可能（あるいは再生が禁止されていない）であり、第２のカラオケ装置１ｂは一部の曲について再生不可能（あるいは再生が禁止されている）とされている。したがって、リクエスト装置２の検索用データベースに対して何ら工夫をしないと、次のような問題が生じる。つまり、第１のカラオケ装置１ａに合わせて全ての曲をリクエスト対象としたリクエスト装置２を第２のカラオケ装置１ｂに用いた場合、リクエストは受け付けられたのに、実際にはカラオケ曲の再生が実行されない。逆に、第２のカラオケ装置１ｂにて再生可能な曲のみをリクエスト対象としたリクエスト装置２を第１のカラオケ装置１ａに用いた場合は、カラオケ曲自体は存在するのに、リクエストできないという問題が生じる。
【００５６】
そこで、この問題を解決するため本実施例のカラオケシステムでは、カラオケ装置１ａ，１ｂが定期的にマスクデータを無線通信装置１５を介して送信しており、その送信されたマスクデータを受け取ったリクエスト装置２は、更新すべきマスクデータであればＳＲＡＭ２５に更新記憶する。そしてリクエスト装置２は、検索すべき文字が入力された場合、ＳＲＡＭ２５に記憶されているリクエスト用楽曲データ（図５（ａ）参照）と、ＳＲＡＭ２５に記憶されているマスクデータとを用いて、その検索結果を表示する。具体的には、図２（ｃ）に示すように、マスクデータが第１のカラオケ装置１ａ用マスクデータであれば、特にマスク対象となっているデータがないため、リクエスト装置２では、検索結果をそのまま液晶表示部２３に表示する。それに対して、マスクデータが第２のカラオケ装置１ｂ用マスクデータであれば、例えば選曲番号２，５等のマスク対象となっているため、リクエスト装置２では、検索結果中にそれらマスク対象の曲があればそれを除く。つまり、記憶しているリクエスト用楽曲データの内、そのマスク対象の曲名については液晶表示部２３に表示しないのである。
【００５７】
このように、リクエスト装置２は、自装置が用いられているカラオケ装置１ａ，１ｂにて再生が可能な曲しかリクエストを受け付けないようにできるため、利用者にとっては、リクエストしたのにその曲が再生されない、という問題を極力防止できる。また、このような対処をしているので、リクエスト装置２は、いずれのカラオケ装置１ａ，１ｂにでも用いることができ、例えばそれまで第１のカラオケ装置１ａに利用していたリクエスト装置２が故障してしまった場合、別のリクエスト装置２で代用できる。つまり、その別のリクエスト装置２を第１のカラオケ装置１ａにおける無線通信装置１５の無線信号到達範囲内に置いてやれば、第１のカラオケ装置１ａからのマスクデータ等を受け取ることによって、その第１のカラオケ装置１ａに適したリクエスト装置２になるからである。
【００５８】
（ロ）また、本実施例ではリクエスト装置２におけるマスクデータの更新に際して、取得したマスクデータのリリース番号がＳＲＡＭ２５に現在保持しているリリース番号と異なる場合にマスクデータを更新しており、同じであれば更新しない。そのため、実質的に変更のないデータの更新作業がなされることがなく、処理負荷が低減される。
【００５９】
また、リリース番号を比較する以前に、取得した機種コードがＳＲＡＭ２５に現在保持している機種コードと異なるか否かを判断し（Ｓ２３０）、機種コードが異なれば（Ｓ２３０：はい）、マスクデータを更新する。このようにすれば、リリース番号の比較もせずにマスクデータの更新が必要であることが判断できるため、処理負荷が低減される。
【００６０】
なお、本実施例においては、演奏曲データが「提供用情報」に相当し、リクエスト用楽曲データが「リクエスト情報」に相当する。また、カラオケ装置１ａ，１ｂが情報提供装置に相当し、リクエスト装置２が「リクエスト装置」に相当する。また、リリース番号が「所定の識別情報」に相当し、機種コードが「機種情報」に相当する。さらに、リクエスト装置２のＣＰＵ２０が「検索手段」、「検索結果表示手段」、「有効曲抽出手段」、機種判断手段」、「識別情報半断手段」に相当する。
【００６１】
以上実施例について説明したが、本発明は上記実施例に限定されるものではなく、種々の態様で実施し得る。そのいくつかを説明する。
（１）上記実施例では、理解を容易にするために第１のカラオケ装置１ａと第２のカラオケ装置１ｂの２種類の存在を前提として説明したが、当然ながら、記憶している演奏曲データの内容、あるいは記憶している演奏曲データは同じであるが再生が禁止されている曲について３種類以上の違いがあるカラオケ装置群の存在を前提とした場合であっても同様に適用できる。
【００６２】
（２）上記実施例では図４のＳ５０に示すように、検索結果を表示する段階において検索結果にマスクデータを適用し、マスクすべき検索結果をリクエスト装置２の液晶表示部２３に表示しないようにしていた。しかし、例えばマスクデータをカラオケ装置１ａ，１ｂが受信した際などに、予めマスクデータを用いて、検索用データベース中において、検索対象として有効にするデータを抽出しておき、マスク対象となっているデータを検索対象から予め外しておくことも考えられる。このようにすれば、図４のＳ５０の処理は不要となり、リクエスト装置２において検索結果を表示するまでの処理時間を短くすることができる。
【００６３】
（３）上記実施例では、マスクデータの更新に関し、カラオケ装置１ａ，１ｂが主導で実行するようにした。つまり、カラオケ装置１ａ，１ｂは、電源スイッチがオンされた場合、及びその後は所定時間毎にリクエスト装置２に対して通信を行い、マスクデータの送信を行うようにした。しかし、逆にリクエスト装置２が主導でマスクデータの送信要求をするようにしてもよい。例えば、リクエスト装置２の電源スイッチ２７がオンされた場合、及びその後は所定時間毎（例えば１０分毎、３０分毎、１時間毎など）にカラオケ装置１ａ，１ｂに対して通信を行い、マスクデータの送信を要求するのである。そして、その送信要求を受けたカラオケ装置１ａ，１ｂは記憶しているマスクデータをリクエスト装置２に送信すればよい。
【００６４】
（４）上記実施例においては、カラオケ装置１ａ，１ｂとリクエスト装置２との間の通信手段として、それぞれに内蔵された無線通信装置１５，２１が例示されているが、これは内蔵されていなくてもよいし、また無線ではなく有線であってもよい。
【００６５】
（５）また、上記実施例においては、リクエスト用楽曲データは公衆回線を通じてそれ自体が配信されるように例示されているが、これはカラオケ装置１ａ，１ｂが現在保持しているリクエスト用楽曲データとの差分として配信されたり、演奏曲データ自身に含まれる形で配信され、カラオケ装置１ａ１ｂ内部で再構成されてもよいし、差分の形のままリクエスト装置２まで通知され、リクエスト装置２内でリクエスト用楽曲データとして再構成されてもよい。
【００６６】
（６）上記実施例では、カラオケ装置１ａ，１ｂ内に演奏曲データ自体は存在するのに、施策的観点から再生を禁止する例として、例えば利用者の年齢層が低い場合にはアダルト向けの映像を伴うカラオケ曲の再生を禁止するとか、祝宴に供されるカラオケ装置にあっては、失恋の曲など雰囲気にふさわしくない曲の再生を禁止する、といった例を挙げた。それ以外にも、例えば新曲の発売以前にカラオケで利用できるようになると困るが、予めカラオケ装置１ａ，１ｂへの演奏曲データの配信を行っておきたい場合もありえる。したがって、そのような場合も、演奏曲データ自体はカラオケ装置１ａ，１ｂ内に存在しながらリクエストされないようにする必要がある。この場合は、例えば配信する演奏曲データに再生が許可される期日等を含めておき、カラオケ装置１ａ，１ｂ側において、その期日になるまでは再生しない制御を実行することが考えられる。もちろん、マスクデータにも０を設定し、リクエストされないようにしておくことも考えられる。
【００６７】
（７）また、演奏曲データとリクエスト用楽曲データは必ずしも同時期にカラオケ装置１ａ，１ｂへ配信されるとは限らない。例えばリクエスト用楽曲データの方が先行して配信されることもあり得る。つまり、リリース日が不定ではあるがリリースされること自体は決まっている新曲の場合、先にリクエスト用楽曲データがカラオケ装置１ａ，１ｂへ送られ、カラオケ装置１ａ，１ｂからリクエスト装置２へも転送されることが考えられる。その場合、リクエスト装置２のＳＲＡＭ２５内における検索用データベース中には当該曲のリクエスト用楽曲データは存在するが、演奏曲データ自体がカラオケ装置１ａ，１ｂに存在しないこととなる。この場合は、たとえ全曲の再生を可能とすることを前提にしたいわゆる高機種の第１のカラオケ装置１ａであっても、カラオケ演奏曲データとリクエスト用楽曲データの不整合が生じる。したがって、上記同様、リクエスト用楽曲データに対応する演奏曲データが存在しないものについてはマスクしてリクエストされないような対処をする。
【００６８】
（８）上記実施例では、リクエスト装置２側において、機種コード及びリリース番号を判断して（図６のＳ２３０，Ｓ２４０参照）マスクデータを取得する（Ｓ２５０）ようにしたが、機種コード及びリリース番号をカラオケ装置１ａ，１ｂ側に送り、カラオケ装置１ａ，１ｂ側でマスクコードを更新する必要があるか否かを判断し、必要がある場合にマスクデータをリクエスト装置２へ送って更新するようにしても差し支えない。
【００６９】
（９）上記実施例では、カラオケシステムとして実現した場合について説明したが、カラオケシステムには限らず、リクエスト情報を検索するための検索用データベースを有し、ユーザから受け付けた操作に基づき検索した結果としてのリクエスト情報を情報提供装置に対して送信し、その受信したリクエスト情報に応じた提供用情報を用いて情報提供を実行する情報提供装置とからなるリクエスト対応型情報提供システムであれば同様に適用できる。例えばビデオサーバを利用したビデオライブラリなどが考えられる。
【００７０】
（１０）上記実施例では、図７を参照して説明したように、カラオケ装置１ａ，１ｂが、追加曲を受信すると（Ｓ３１０）、マスクデータ内に追加曲の選曲番号を追加し、対応するビットを全て「０」とし（Ｓ３２０）、自装置において何ら再生制限設定がされておらず（Ｓ３３０：いいえ）且つ再生可能な曲であれば（Ｓ３４０：はい）、マスクデータ内の追加曲の選曲番号に対応するビットを「１」（マスクしない＝検索可を意味する）とするようにした（Ｓ３５０）。つまり、デフォルト値を「０」（マスクする＝検索不可を意味する）として、再生可能な場合にのみ対応ビットを「１」にする方法を採用した。しかし、これとは逆に、デフォルト値を「１」として、再生不可能な場合にのみ対応ビットを「０」にする方法を採用してもよい。
【００７１】
また、図７のＳ３２０のようにカラオケ装置１ａ，１ｂ内でマスクデータのデフォルト値を設定するのではなく、予めデフォルト値の設定されたマスクデータをホストからカラオケ装置１ａ，１ｂが受信するようにしてもよい。
【図面の簡単な説明】
【図１】実施例のカラオケシステムの概略構成を示すブロック図である。
【図２】リクエスト用楽曲データに対するマスクデータの適用例を示す説明図である。
【図３】リクエスト装置の外観及び液晶表示部への表示内容の説明図である。
【図４】リクエスト装置にて実行されるリクエストに係る処理を示すフローチャートである。
【図５】（ａ）はリクエスト用楽曲データの説明図、（ｂ）はマスクデータの説明図である。
【図６】リクエスト装置にて実行されるマスクデータの取得・更新に係る処理を示すフローチャートである。
【図７】カラオケ装置にて実行される追加曲の受信に係る処理を示すフローチャートである。
【図８】カラオケ装置にて実行されるカラオケ演奏に係る処理を示すフローチャートである。
【符号の説明】
１ａ…第１のカラオケ装置、１ｂ…第２のカラオケ装置、９…映像再生装置、１０…ＣＰＵ、１１…ハードディスク、１２…モデム、１３…再生装置、１４…リモコン受光部、１５…無線通信装置、１６…マイクロフォン、１７…アンプ、１８…スピーカ、１９…ＣＲＴ、２０…ＣＰＵ、２１…無線通信装置、２２…リモコン発光部、２３…液晶表示部、２４…入力装置、２５…ＳＲＡＭ、２６…電源、２７…電源スイッチ。

Claims (10)

1. 複数の提供用情報と、それに対応するリクエスト情報とを記憶しており、外部からリクエスト情報を受信し、そのリクエスト情報に応じた提供用情報を用いて情報提供を実行する情報提供装置、
   前記リクエスト情報を検索するための検索用データベースを有し、ユーザから受け付けた操作に基づき前記検索用データベースの検索を行い、その検索結果としてのリクエスト情報を前記情報提供装置に対して送信するリクエスト装置を備えるリクエスト対応型情報提供システムであって、
   前記情報提供装置は、
   前記リクエスト装置の有する検索用データベースに存在するリクエスト情報の内で、情報提供装置にて情報提供できる提供用情報に対応するリクエスト情報とそれ以外のリクエスト情報とを区別するためのマスクデータをリクエスト装置へ送信し、
   前記リクエスト装置は、
   前記情報提供装置から送信された前記マスクデータを受信及び記憶し、前記情報提供装置にて情報提供できる提供用情報に対応するリクエスト情報のみを検索結果として有効に扱うよう、前記記憶したマスクデータを用いて調整する
   リクエスト対応型情報提供システム。
2. 請求項１に記載のリクエスト対応型情報提供システムにおいて、
   前記リクエスト装置は、
   前記マスクデータを用いて、前記検索用データベース中のリクエスト情報の内、前記情報提供装置にて情報提供できる提供用情報に対応するリクエスト情報のみを検索対象とし、そうでないリクエスト情報は検索対象から外して検索を実行する
   リクエスト対応型情報提供システム。
3. 請求項１に記載のリクエスト対応型情報提供システムにおいて、
   前記リクエスト装置は、
   検索結果を表示する表示手段を有し、前記表示手段に検索結果を表示する際、前記マスクデータを用いて、前記検索用データベースの検索した結果の内、前記情報提供装置にて情報提供できる提供用情報に対応するリクエスト情報であるもののみを表示し、そうでない場合は表示しない
   リクエスト対応型情報提供システム。
4. 請求項１〜３の何れかに記載のリクエスト対応型情報提供システムにおいて、
   前記リクエスト装置は、所定のタイミングで前記情報提供装置に対して前記マスクデータの送信を要求し、
   前記情報提供装置は、前記リクエスト装置からの送信要求に応じて前記マスクデータを前記リクエスト装置に対して送信し、
   その送信されたマスクデータを前記リクエスト装置は受信して記憶する
   リクエスト対応型情報提供システム。
5. 請求項４に記載のリクエスト対応型情報提供システムにおいて、
   前記リクエスト装置は、そのリクエスト装置自体の電源をオン・オフする電源スイッチを有しており、当該電源スイッチがオンされた場合、または、電源オン後の所定時間毎の少なくともいずれかのタイミングで前記マスクデータの送信要求を行う
   リクエスト対応型情報提供システム。
6. 請求項１〜３の何れかに記載のリクエスト対応型情報提供システムにおいて、
   前記情報提供装置は、所定のタイミングで前記マスクデータを前記リクエスト装置に対して送信し、
   その送信されたマスクデータを前記リクエスト装置は受信して記憶する
   リクエスト対応型情報提供システム。
7. 請求項６に記載のリクエスト対応型情報提供システムにおいて、
   前記情報提供装置は、その情報提供装置自体の電源をオン・オフする電源スイッチを有しており、当該電源スイッチがオンされた場合、または、電源オン後の所定時間毎の少なくともいずれかのタイミングで前記マスクデータを前記リクエスト装置に対して送信する
   リクエスト対応型情報提供システム。
8. 請求項１〜７の何れかに記載のリクエスト対応型情報提供システムにおいて、
   前記情報提供装置は、前記マスクデータの内容が更新される度に、所定の識別情報の値をユニークに変化させ、当該識別情報を前記マスクデータに付加して前記リクエスト装置に送信し、
   その送信されたマスクデータを受信した前記リクエスト装置は、従前のマスクデータに付加された識別情報と、今回受信したマスクデータに付加された識別情報を比較し、両者が異なっている場合にのみ更新記憶する
   リクエスト対応型情報提供システム。
9. 請求項８に記載のリクエスト対応型情報提供システムにおいて、
   前記情報提供装置は、情報提供できる提供用情報の内容に応じて機種の区別が設定されており、当該機種の区別をするための機種情報を前記マスクデータに付加して前記リクエスト装置に送信し、
   その送信されたマスクデータを受信した前記リクエスト装置は、従前のマスクデータに付加された機種情報と、今回受信したマスクデータに付加された機種情報を比較し、両者が異なっている場合は更新記憶する
   リクエスト対応型情報提供システム。
10. 請求項１〜９の何れかに記載のリクエスト対応型情報提供システムに用いられるリクエスト装置であって、
    当該各請求項においてリクエスト装置に関して記載された構成を備えるリクエスト装置。

Images