JP4085783B2

JP4085783B2 - Request-compatible information providing system and request device

Info

Publication number: JP4085783B2
Application number: JP2002324048A
Authority: JP
Inventors: 卓哉井上; 和典伊神
Original assignee: Brother Industries Ltd
Current assignee: Brother Industries Ltd
Priority date: 2002-11-07
Filing date: 2002-11-07
Publication date: 2008-05-14
Anticipated expiration: 2022-11-07
Also published as: JP2004157390A

Description

【０００１】
【発明の属する技術分野】
本発明は、受信したリクエスト情報に応じた提供用情報を用いて情報提供を実行する情報提供装置と、リクエスト情報を検索するための検索用データベースを有し、ユーザから受け付けた操作に基づき検索した結果としてのリクエスト情報を情報提供装置に対して送信するリクエスト装置を備えるリクエスト対応型情報提供システム等に関する。
【０００２】
【従来の技術】
従来、例えば楽曲を再生するカラオケ装置と、そのカラオケ装置に所定の楽曲を再生させるための動作指令を送信する遠隔操作装置を備えたカラオケシステムが知られている。このカラオケシステムにおいては、カラオケ装置に対して利用者が希望の曲をリクエストする際、例えば曲名や歌手名などのキーデータと、リクエストに利用するたとえば数桁の英数字などからなるリクエストコードが組となって記載されているリクエスト用の冊子（いわゆる早見本）を参照して、所望の曲に対応するキーデータからリクエストコードを検索した上で、そのリクエストコードをリクエスト装置に入力することによってリクエストを実現していた。
【０００３】
一方、昨今の通信インフラなどデータ配信技術の向上により、冊子の配本スピードがカラオケ曲の追加／更新のスピードに対して相対的に低下してしまう傾向にある。そのため、リクエスト装置内に検索用データベースを保持することによって、前記キーデータによる検索機能を実現し、利用者は所望の曲に対応するキーデータをリクエスト装置に入力することによって、該当するプログラムを検索し且つ選択し、リクエストを実現するカラオケシステムも開発されている（例えば、特許文献１参照）。
【０００４】
このカラオケシステムにおいては、カラオケ装置がホスト装置から新曲の配信を受けると、その新曲検索用の追加レコードをカラオケ装置からリクエスト装置に送信することによって、迅速に新曲のリクエストが可能となる。
【０００５】
【特許文献１】
特許第３０８９５２９号公報
【０００６】
【発明が解決しようとする課題】
ところで、例えば同じ店舗内に存在する複数のカラオケ装置同士であっても、リクエスト可能な曲に違いがある場合も考えられる。この原因としては大きく分けて２つあり、一つは機器の提供価格や利用契約の差異によって再生可能な曲数を機器ごとに変える場合などである。例えば営業政策的な理由によって、高価な機種の場合には全てのカラオケ曲データを蓄積して全て使用可能となっているが、廉価な機種の場合には蓄積するカラオケ曲データ数を制限して使用できる曲を限定することが考えられる。また、利用契約によって使用できるカラオケ曲データ数を制限することも考えられる。これらはカラオケ曲データが物理的にカラオケ装置内に存在しない場合である。
【０００７】
一方、カラオケ装置内にカラオケ曲データは存在していても、例えばユーザ層に応じて一部のカラオケ曲については演奏をさせないといった施策的観点からの制限も考えられる。例えば利用者の年齢層が低い場合にはアダルト向けの映像を伴うカラオケ曲の再生を禁止するとか、祝宴に供されるカラオケ装置にあっては、失恋の曲など雰囲気にふさわしくない曲の再生を禁止する、といったことである。
【０００８】
このようにカラオケ装置毎に再生可能な曲が異なる場合、次のような不都合が生じる。つまり、リクエスト装置が有する検索用データベースは、カラオケ装置の内で最も広範なリクエストが可能なものに対応させるおくことが好ましい。つまり、全曲再生可能なカラオケ装置に対応するよう全曲分の検索用データベースを持つようにするのである。一般に、リクエスト装置はどのカラオケ装置であっても使用できることが好ましいからである。逆に、特定のカラオケ装置には特定のリクエスト装置しか使用できないとなると管理等の面で非常に不自由なものとなる。
【０００９】
しかしながら、全曲再生可能なカラオケ装置に対応するよう全曲分の検索用データベースを持つリクエスト装置を準備した場合、汎用性は確保できるが、今度は、リクエスト装置ではリクエスト可能であるにもかかわらずカラオケ装置においてそのリクエストに対応した再生ができない状況が生じることとなる。もちろん、リクエスト自体は受け付け、再生時に「再生不可能」「再生禁止」といった報知をする対処も考えられるが、そのような対処が頻繁に生じると利用者としては興醒めしてしまう可能性がある。そのため、リクエスト自体が受け付けられないようにする対処が好ましい。
【００１０】
なお、このような問題は、カラオケシステムには限らず、リクエスト情報を検索するための検索用データベースを有し、ユーザから受け付けた操作に基づき検索した結果としてのリクエスト情報を情報提供装置に対して送信し、その受信したリクエスト情報に応じた提供用情報を用いて情報提供を実行する情報提供装置とからなるリクエスト対応型情報提供システムであれば同様に発生する。
【００１１】
そこで本発明は、リクエスト情報をリクエスト装置から情報提供装置に対して送信すれば、そのリクエスト情報を受信した情報提供装置においては、極力そのリクエスト情報に応じた提供用情報が存在し、リクエストに応じた情報提供が実現されるようにすることを目的とする。
【００１２】
【課題を解決するための手段及び発明の効果】
（１）上述した問題点を解決するためになされた本発明のリクエスト対応型情報提供システムは、情報提供装置にて情報提供できる提供用情報に対応するリクエスト情報と、リクエスト装置が有する検索用データベースに存在するリクエスト情報とが必ずしも一致しない状況もあり得ることを前提としたものである。例えばカラオケシステムであれば、複数の機種を準備し、ある機種ではリクエスト装置が有する検索用データベースに存在する全てのリクエスト情報に対応するカラオケ曲を演奏可能とし、別の機種では一部のカラオケ曲については演奏できないようにすることも考えられる。これは、ハードディスク等のデータ記憶記憶手段における記憶容量といった主に物理的観点、利用契約や営業政策的な観点などの事情である。また、同じ機種であっても、ユーザ層に応じて（カラオケ曲自体は存在するが）一部のカラオケ曲については演奏をさせないといった施策的観点からの事情も考えられる。例えばアダルト向け・キッズ向けというように、客層に応じてリクエスト対象曲を絞り込んだり逆にリクエスト対象から積極的に外すようにプロテクトするケースである。
【００１３】
このような理由で、情報提供装置にて情報提供できる提供用情報に対応するリクエスト情報と、検索用データベースに存在するリクエスト情報との不整合が生じるため、何ら対処しないと、リクエスト装置では検索してリクエスト可能であるのに、情報提供装置では情報提供できない、という不都合が発生する。
【００１４】
この不都合解消のために本発明のリクエスト対応型情報提供システムでは、情報提供装置が、リクエスト装置の有する検索用データベースに存在するリクエスト情報の内で、情報提供装置にて情報提供できる提供用情報に対応するリクエスト情報とそれ以外のリクエスト情報とを区別するためのマスクデータをリクエスト装置へ送信し、そのマスクデータを受信及び記憶したリクエスト装置は、情報提供装置にて情報提供できる提供用情報に対応するリクエスト情報のみを検索結果として有効に扱うよう、記憶したマスクデータを用いて調整する。
【００１５】
これによって、リクエスト装置での検索において有効な検索結果として扱われたリクエスト情報をリクエスト装置から情報提供装置に対して送信すれば、そのリクエスト情報を受信した情報提供装置においては、極力そのリクエスト情報に応じた提供用情報が存在し、リクエストに応じた情報提供が実現される。
【００１６】
（２）このリクエスト装置におけるマスクデータを用いた調整に関しては、例えば請求項２に示すように、マスクデータを用いて、検索用データベース中のリクエスト情報の内、情報提供装置にて情報提供できる提供用情報に対応するリクエスト情報のみを検索対象とし、そうでないリクエスト情報は検索対象から外して検索を実行することが考えられる。このように検索対象から予め外しておけば、情報提供装置にて情報提供できないリクエストが検索結果として抽出されること自体がなくなる。また、請求項３に示すように、検索結果を表示する表示手段を有し、その表示手段に検索結果を表示する際には、マスクデータを用いて、検索用データベースの検索した結果の内、情報提供装置にて情報提供できる提供用情報に対応するリクエスト情報であるもののみを表示し、そうでない場合は表示しないようにしてもよい。このようにすれば、表示手段には、情報提供装置にて情報提供できないリクエストが検索結果として表示されることがない。したがって、その表示された検索結果中から選択したリクエスト情報を情報提供装置に対して送信すれば、極力リクエストに応じた情報提供が実現されることとなる。
【００１７】
（３）リクエスト装置内のマスクデータは適宜更新される必要があるが、情報提供装置からリクエストへのマスクデータは、次のようにして送信されるように構成することが考えられる。
まず、請求項４に示すように、リクエスト装置が、所定のタイミングで情報提供装置に対してマスクデータの送信を要求することが考えられる。そして、情報提供装置がそのリクエスト装置からの送信要求に応じてマスクデータをリクエスト装置に対して送信し、その送信されたマスクデータをリクエスト装置は受信して記憶するのである。この場合の「所定のタイミング」としては、例えば請求項５に示すようにすることが考えられる。つまり、リクエスト装置が（そのリクエスト装置自体の）電源をオン・オフする電源スイッチを有しており、その電源スイッチがオンされた場合、または、電源オン後の所定時間毎の少なくともいずれかのタイミングでマスクデータの送信要求を行うのである。
【００１８】
また、請求項６に示すように、情報提供装置が所定のタイミングでマスクデータをリクエスト装置に対して送信するようにしてもよい。そして、その送信されたマスクデータをリクエスト装置は受信して記憶するのである。この場合の「所定のタイミング」としては、例えば請求項７に示すようにすることが考えられる。つまり、情報提供装置が（その情報提供装置自体の）電源をオン・オフする電源スイッチを有しており、その電源スイッチがオンされた場合、または、電源オン後の所定時間毎の少なくともいずれかのタイミングでマスクデータをリクエスト装置に対して送信するのである。
【００１９】
（４）また、リクエスト装置内のマスクデータの更新に関しては、次のような工夫をすることが考えられる。例えば請求項８に示すように、情報提供装置が、マスクデータの内容が更新される度に所定の識別情報の値をユニークに変化させ、その識別情報をマスクデータに付加してリクエスト装置に送信する。そして、その送信されたマスクデータを受信したリクエスト装置は、従前のマスクデータに付加された識別情報と、今回受信したマスクデータに付加された識別情報を比較し、両者が異なっている場合にのみ更新記憶するのである。
【００２０】
このようにすれば、実質的に変更のないデータの更新作業がなされることがなく、処理負荷が低減される。
また、情報提供装置が、情報提供できる提供用情報の内容に応じて機種の区別が設定されているのであれば、請求項９に示すようにしてもよい。つまり、その機種の区別をするための機種情報をマスクデータに付加してリクエスト装置に送信する。そして、その送信されたマスクデータを受信したリクエスト装置が、従前のマスクデータに付加された機種情報と、今回受信したマスクデータに付加された機種情報を比較し、両者が異なっている場合は更新記憶するのである。
【００２１】
このようにすれば、マスクデータ自体の比較をするまでもなく機種情報の比較のみで更新の必要の有無が判断できるため、さらに処理負荷が低減される。
（５）なお、請求項１０に示すように、請求項１〜９の何れかに記載のリクエスト対応型情報提供システムに用いられるリクエスト装置であって、当該各請求項においてリクエスト装置に関して記載された構成を備えるリクエスト装置として実現することもできる。
【００２２】
このようなリクエスト装置であれば、上述したリクエスト対応型情報提供システムに用いられることによって、上述の効果を発揮する上で有意な役割を果たすこととなる。
【００２３】
【発明の実施の形態】
以下、本発明が適用された実施例について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り種々の形態を採りうることは言うまでもない。
【００２４】
図１は、本発明のリクエスト対応型情報提供システムの一実施例としてのカラオケシステムの構成を示すブロック図である。本実施例のカラオケシステムはカラオケ装置１ａとリクエスト装置２、またはカラオケ装置１ｂとリクエスト装置２とから構成される。なお、カラオケ装置１ａとカラオケ装置１ｂは、記憶している演奏曲データの内容が異なるか、あるいは記憶している演奏曲データは同じであるが再生が禁止されている曲に違いがある。したがって、両者を区別して説明する必要がある場合には第１のカラオケ装置１ａ、第２のカラオケ装置１ｂというように個別に記載し、両者を区別して説明する必要がない場合には単にカラオケ装置１ａ，１ｂと記載することにする。一方、リクエスト装置２はたとえ複数存在したとしてもそれらに構成に違いはなく、第１のカラオケ装置１ａ、第２のカラオケ装置１ｂのいずれにも用いることができるようになっている。但し、上述のように、第１のカラオケ装置１ａと第２のカラオケ装置１ｂは、記憶している演奏曲データの内容が異なるか、あるいは記憶している演奏曲データは同じであるが再生が禁止されている曲に違いがあるため、それに対応するための所定の処理を実行する。その所定の処理については後述する。
【００２５】
［カラオケ装置１ａ，１ｂの構成］
カラオケ装置１ａ，１ｂは、図１に示されるように、図示しないホストコンピュータに公衆回線などの通信ネットワークを介して接続し各種の情報を送受信するモデム１２、カラオケ装置１ａ，１ｂ全体の制御を司るＣＰＵ１０、カラオケ用の音楽情報や画像情報その他各種データを記憶しているハードディスク１１、演奏の再生を行う再生装置１３、音楽情報にかかる電気信号を増幅等するアンプ１７、アンプ１７からの電気信号を入力して伴奏曲及び利用者の歌声等を流すスピーカ１８、利用者の歌声等をアンプ１７に入力するためのマイクロフォン（以下、単にマイクと称す。）１６、ハードディスク１１に記憶された画像情報に基づいて映像情報である背景画及び歌詞等を再生する映像再生装置９、再生された映像を表示するＣＲＴ１９、リクエスト装置２から発光される赤外線等によるリモコン信号を受光するリモコン受光部１４及びリクエスト装置２と無線で双方向通信（例えばBluetooth規格に基づく無線通信やＩｒＤＡ（Infrared Data Association）を用いた光通信）するための無線通信装置１５を備えている。この内、ハードディスク１１、モデム１２、再生装置１３、リモコン受光部１４、無線通信装置１５及び映像再生装置９はＣＰＵ１４に接続されている。
【００２６】
上述したモデム１２は、信号の変調および復調を行う変復調装置であり、ＣＰＵ１０の制御の下、公衆回線を通じてホストコンピュータにアクセス可能に構成されている。それによって、モデム１２は公衆回線を介してホストコンピュータから送られてくる演奏曲データの追加分（新曲のデータ等）を受信したり、その演奏曲データと同じくして配信されるリクエスト用楽曲データ（図５（ａ）参照）を受信する。
【００２７】
ここで受信された演奏曲データ、リクエスト用楽曲データ及びマスクデータはハードディスク１１にファイルとして記憶される。そして、演奏曲データはカラオケ演奏時に読み出され演奏処理に用いられ、リクエスト用楽曲データ及びマスクデータは無線通信装置１５を通じてリクエスト装置２へ送信される。
【００２８】
例えばカラオケ演奏処理では、ＣＰＵ１０から出力される演奏曲データは再生装置１３においてアナログの演奏音信号に変換された後、アンプ１７へ送られて電気的に増幅される。このアンプ１７は、マイク１６を介して入力される利用者（歌唱者）の歌唱音信号と適度な割合でミキシングするもので、ミキシングされた歌唱音信号と演奏音信号は、アンプ１７からスピーカ１８に出力され、音声及び演奏音となってスピーカ１８から外部へ出力される。一方、映像再生装置９は、ＣＰＵ１４の制御の下、ハードディスク１１から読み出された画像情報に基いて歌詞や背景画を再生してＣＲＴ１９に出力し、ＣＲＴ１９はそれらの表示を行うものである。それにより、ＣＰＵ１９においては、歌詞データが映像データと合成されて背景映像とともに歌詞テロップが表示されるようになっている。このような構成のため、利用者は、ＣＲＴ１９に表示される歌詞テロップを参照しながら、スピーカ１８より流れるカラオケ演奏にあわせ、マイク１６を使って歌唱できるようになっている。
【００２９】
なお、本実施例の第１のカラオケ装置１ａ、第２のカラオケ装置１ｂは、記憶している演奏曲データの内容が異なるか、あるいは記憶している演奏曲データは同じであるが再生が禁止されている曲に違いがある。例えば図２（ａ），（ｂ）に示すように、第１のカラオケ装置１ａは全ての曲について再生可能（あるいは再生が禁止されていない）であり、第２のカラオケ装置１ｂは一部の曲について再生不可能（あるいは再生が禁止されている）とされている。
【００３０】
これらの違いが生じる原因としては大きく分けて２つあり、一つはカラオケ装置１ａ，１ｂの提供価格や利用契約の差異によって再生可能な曲数を機器ごとに変える場合などである。例えば第１のカラオケ装置１ａが高価な機種の場合には、ハードディスク１１のデータ記憶容量も十分にあって全てのカラオケ曲データを蓄積しているが、例えば第２のカラオケ装置１ｂが廉価な機種の場合にはハードディスク１１のデータ記憶容量に制限があったり、営業政策上、蓄積可能なカラオケ曲データ数を制限する、といったことである。また、ハードディスク１１のデータ記憶容量自体は余裕があっても、利用契約によって蓄積するカラオケ曲データ数を制限することも考えられる。これらはカラオケ曲データが物理的にカラオケ装置１ａ，１ｂ内に存在しない場合である。
【００３１】
一方、施策的観点からの対処による要因も考えられる。例えば利用者の年齢層が低い場合にはアダルト向けの映像を伴うカラオケ曲の再生を禁止するとか、祝宴に供されるカラオケ装置にあっては、失恋の曲など雰囲気にふさわしくない曲の再生を禁止する、といったことである。このような再生禁止の設定は、カラオケ装置１ａ，１ｂ毎に設定できるようにされている。通常、カラオケボックスでは、各室に１台のカラオケ装置１ａ，１ｂが設置されており、上記再生禁止の設定は、各室単位で設定され、また、各室の、例えば使用料金の設定に応じて、設置されるカラオケ装置１ａ，１ｂの機種等が選択され、設置されている。
【００３２】
［リクエスト装置２の構成］
一方、リクエスト装置２は、カラオケボックスの各室に設置されたカラオケ装置１ａ，１ｂに対応して各室毎に１台もしくは複数台配置されている。また、図１に示すように、リクエスト装置２全体の制御を司るＣＰＵ２０、カラオケ装置１ａ，１ｂと無線で双方向通信（Bluetooth やＩｒＤＡ）するための無線通信装置２１、カラオケ装置１ａ，１ｂに対して赤外線等によるリモコン信号を発光するリモコン発光部２２、表示装置としての液晶表示部２３、入力手段としての入力装置２４及びＳＲＡＭ２５、ニッカドなどの二次電池からなる電源２６、その電源２６に接続された電源スイッチ２７を備えている。
【００３３】
リクエスト装置２は、無線通信装置２１を介してカラオケ１ａ，１ｂから受信したマスクデータ（図５（ｂ）参照）をファイルとしてＳＲＡＭ２５に記憶する。また、このマスクデータの受信と同じ機会あるいは別の機会に、リクエスト用楽曲データ（図５（ａ）参照）も受信し、これもＳＲＡＭ２５に上記と同様にファイルとして記憶される。このリクエスト用楽曲データは、選曲番号、曲名、その曲を歌った歌手名、その曲が属するジャンル情報、その曲のリリース年月日などが対になったものであり、例えば第１のカラオケ装置１ａあるいは第２のカラオケ装置１ｂのいずれかにおいて例えば１万曲のカラオケ曲の再生が可能であるならば、その１万曲分のリクエスト用楽曲データが存在する。これが「検索用データベース」を構成することとなる。ここで、ＳＲＡＭ２５は、電源スイッチ２７の遮断時にも記録された情報を保持可能なメモリである。
【００３４】
また、入力装置２４は、利用者によって操作されるものであり、任意の曲の選択、演奏音のキーの調整、演奏と歌との音量バランスの調整、その他エコー、音量、トーンなど各種調整を行うためのものであり、この入力装置２４が操作されることによって入力あるいは選択された曲番号や曲名等は液晶表示部２３に表示される。入力装置２４は、図３に示すように、リクエスト装置２の表側の中央にテンキーが設けられており、その他にも選択キーや各種機能キーが設けられている。そして、設けられたテンキーを用いて数字を入力することもできるし、文字を入力することもできる。文字入力は、例えば曲名や歌手名の頭に付く文字で検索する場合などに利用される。この文字入力に関しては、例えば現在一般に見られる携帯電話での文字入力方法に倣ったものとすることが考えられる。これによって検索すべき曲名を入力することができる。例えば、例えば「あ」を入力したければテンキーの「１」を１回押下した後で「＞」のキーを押下し、「ろ」を入力したければ「９」のキーを５回押下した後に「＞」のキーを押下する。上述の曲名の頭に付く文字で検索する場合であれば、リクエスト装置２は図３（ｂ）に示すように条件（この場合は頭に「あ」が付く曲名）に合致する曲名を表示し、その最上部に表示されている曲名の横に黒丸で示されるカーソルを表示する。利用者はリクエスト装置２の表側の下部に示される矢印キー（←→↑↓）を押下してカーソルを移動させ、所望の曲を選択した上で選択キーを押下することによってリクエスト曲を確定する。
【００３５】
このようにリクエスト曲が確定すると、ＣＰＵ２０はリモコン発光部２２を通じて、選択された曲名に対応する曲の選曲番号（選曲情報）を赤外線信号として送信する。カラオケ装置１ａ，１ｂは、リモコン受光部１４にてその赤外線信号を受信すると、受信信号から解析した選曲番号に応じたカラオケ曲の演奏を行う。なお、リクエスト装置２では、電源スイッチ２７をオンにすると、電源２６からＣＰＵ２０、無線通信装置２１、リモコン発光部２２、液晶表示部２３、ＳＲＡＭ２５等に電力が供給される。また、電源２６は、リクエスト装置２をクレードル（図示せず）にセットしたときに充電されるようになっている。
【００３６】
［リクエスト装置２、カラオケ装置１ａ，１ｂにて実行される処理］
ところで、本実施例のリクエスト装置２は、上述のように第１のカラオケ装置１ａあるいは第２のカラオケ装置１ｂのいずれにも用いることができる。但し、第１のカラオケ装置１ａ、第２のカラオケ装置１ｂは、記憶している演奏曲データの内容が異なるか、あるいは記憶している演奏曲データは同じであるが再生が禁止されている曲に違いがある。例えば図２（ａ），（ｂ）に示すように、第１のカラオケ装置１ａは全ての曲について再生可能（あるいは再生が禁止されていない）であり、第２のカラオケ装置１ｂは一部の曲について再生不可能（あるいは再生が禁止されている）とされている。通常、カラオケボックスでは、第１のカラオケ装置１ａ及び台２のカラオケ装置１ｂは、異なる室に設置されている。したがって、リクエスト装置２は、カラオケボックスの各室において現在、自分と対になっているカラオケ装置１ａ，１ｂにて再生可能な曲の中からのみリクエストを受け付けるように対処する必要がある。
【００３７】
この対処として本実施例のリクエスト装置２は、ＳＲＡＭ２５に記憶されているリクエスト用楽曲データ（図５（ａ）参照）と、直近にカラオケ装置１ａ，１ｂから受信してＳＲＡＭ２５に記憶したマスクデータとを用いて、所定の処理を行う。その処理内容を概念的に示すと図２（ｃ）のようになる。つまり、直近に受信して記憶されたマスクデータが第１のカラオケ装置１ａ用マスクデータであれば、特にマスク対象となっているデータがないため、リクエスト装置２では、記憶しているリクエスト用楽曲データの全てを液晶表示部２３に表示可能である。それに対して、直近に受信して記憶されたマスクデータが第２のカラオケ装置１ｂ用マスクデータであれば、例えば選曲番号２，５等のマスク対象となっているため、リクエスト装置２では、記憶しているリクエスト用楽曲データの内、そのマスク対象の曲名については液晶表示部２３に表示しないようにする。
【００３８】
その具体的な処理について、図４のフローチャート等を参照して説明する。
図４はリクエスト装置２において実行される曲名検索によるリクエスト処理を示しており、最初のステップ１０にて曲入力バッファをクリアした後、利用者からの文字入力があるか否か判断する（Ｓ２０）。そして、文字入力があれば（Ｓ２０：はい）、その入力された文字を曲名入力バッファに追加する（Ｓ３０）。そして、曲名入力バッファの内容をキーとし、ＳＲＡＭ２５内の検索用データベースから条件に合致するものを検索する（Ｓ４０）。なお、このステップＳ４０の処理が検索手段に相当する。そして、その検索結果に対して、ＳＲＡＭ２５に保存しているマスクデータを適用し、有効曲のみを抽出した後（Ｓ５０）、そのマスク適用後の検索結果を液晶表示部２３に表示する（Ｓ６０）。なお、このステップＳ６０の処理が検索結果表示手段に相当し、ステップＳ５０の処理が有効曲抽出手段に相当する。そして、表示対象曲があるか否か判断し（Ｓ７０）、表示対象曲がある場合には（Ｓ７０：はい）、仮の選曲対象を、液晶表示部２３に表示している曲とし、カーソルを最上部に合わせて表示する（Ｓ８０）。
【００３９】
ここで、入力された文字が「あ」であれば、リクエスト装置２が第１のカラオケ装置１ａと対で用いられている場合には図３（ｂ）に示すように表示され、リクエスト装置２が第２のカラオケ装置１ｂと対で用いられている場合には図３（ｃ）に示すように表示される。つまり、図２（ｃ）を用いて上述したように、リクエスト装置２が第１のカラオケ装置１ａと対で用いられている場合にはリクエスト装置２のＳＲＡＭ２５内に第１のカラオケ装置１ａ用マスクデータが記憶されているが、この場合は特にマスク対象となっているデータがないため、図３（ｂ）に示すように、頭に「あ」が付く曲名が全て表示される。一方、リクエスト装置２が第２のカラオケ装置１ｂと対で用いられている場合にはリクエスト装置２のＳＲＡＭ２５内に第２のカラオケ装置１ｂ用マスクデータが記憶されているが、この場合はマスク対象曲があるため、図３（ｃ）に示すように、図３（ｂ）では表示されていた曲の一部が表示されなくなっている。もちろん、液晶表示部２３に一度に表示できる曲数に限りがあるため、いずれの場合も検索結果の曲数が多ければ最初に表示される曲名は検索結果の一部となる。その場合は、カーソルを動かすことで順次スクロール表示されるようになっている。
【００４０】
図４の処理説明に戻り、次のステップＳ９０では、リクエスト装置２の表側の下部に示される矢印キー（←→↑↓）の内の「↑」のキーが押されたか否か判断し、押された場合には（Ｓ９０：はい）、仮選曲対象を、現時点でのカーソルに対応する曲の直上に表示している曲とし、カーソルを該当部に合わせて表示する（Ｓ１００）。なお、図３（ｂ）（ｃ）に示すように、検索結果として最初に表示される曲の上にカーソルが存在している状態ではカーソル移動は行わない。また、「↑」キーではない場合は（Ｓ９０：いいえ）、「↓」のキーが押されたか否か判断し（Ｓ１１０）、押された場合には（Ｓ１１０：はい）、仮選曲対象を、現時点でのカーソルに対応する曲の直下に表示している曲とし、カーソルを該当部に合わせて表示する（Ｓ１２０）。なお、例えば検索結果が１０曲存在するが例えば図３（ｂ）に示すように最初の５曲のみを表示した状態で、カーソルがその表示状態における最下に位置する曲に合わせて表示されている場合であれば、スクロール表示されることによって２〜６番目の曲が表示され、その６番目の曲の位置にカーソルが移動することとなる。それ以降の曲に関しても同様である。もちろん、そのようにしてスクロール表示して５〜１０番目の曲が表示され、その１０番目の曲の位置にカーソルが移動している状態では、それ以下の曲は存在しないため、当然ながらカーソル移動は行わない。
【００４１】
そして、「↑」キーでも「↓」キーでもなく、選曲キーが押された場合には（Ｓ１３０：はい）、仮選曲対象に対応（つまりカーソル位置に対応）する選曲コードをリモコン発光部２２からカラオケ装置１ａ，１ｂに向けて送信する（Ｓ１４０）。その後は、Ｓ２０へ戻る。
【００４２】
次に、リクエスト装置２がカラオケ装置１ａ，１ｂからマスクデータを受信してＳＲＡＭ２５に記憶する処理について図５、図６を参照して説明する。
図６のフローチャートは、図４のリクエストに係る処理と並行して実行される処理である。
【００４３】
最初のステップＳ２１０では、カラオケ装置１ａ，１ｂからの（無線通信）通信があるか否か判断し、通信があった場合には（Ｓ２１０：はい）、Ｓ２２０へ移行し、無線通装置２１を介してマスクデータ機種コードとリリース番号を取得する。ここでカラオケ装置１ａ，１ｂから送信されるマスクデータの構成について、図５（ｂ）を参照して説明する。第１のカラオケ装置１ａには第１のカラオケ装置１ａ用のマスクデータが記憶され、第２のカラオケ装置１ｂには第２のカラオケ装置１ｂ用のマスクデータが記憶されている。各マスクデータは、機種コードとリリース番号に加え、選曲番号に対応してマスク内容が「１」又は「０」で設定されている。ここでマスク内容「１」は「マスクしない」こと、つまりリクエスト対象として有効にすることを意味し、マスク内容「０」は「マスクをする」こと、つまりリクエスト対象として無効にすることを意味する。そして、リリース番号は、第１のカラオケ装置１ａ用のマスクデータ、第２のカラオケ装置１ｂ用のマスクデータそれぞれにおいて、更新される毎にインクリメントされる。また、機種コードは第１のカラオケ装置１ａの場合を「０１」、第２のカラオケ装置１ｂの場合を「０２」と設定してある。なお、この機種コードは、例えばカラオケ装置の製品種類毎に区別した内容としてもよいし、あるいはカラオケ装置単位で区別可能な内容としてもよい。つまり、同じ製品種類であっても装置が異なればそれらを区別するということである。この場合の機種コードとしては、例えば製造番号等のシリアル番号を用いることが考えられる。カラオケボックスの運営者が営業政策的な観点から使用できる曲を制限する場合には、同じ製品種類であっても区別する必要があるため、このような機種コードの設定が必要となってくる。
【００４４】
図６に戻り、上述したマスクデータの機種コードとリリース番号を取得したリクエスト装置２は、その取得した機種コードがＳＲＡＭ２５に現在保持している機種コードと異なるか否かを判断する（Ｓ２３０）。なお、このステップＳ２３０の処理が、機種判断手段に相当する。機種コードが同じ場合は（Ｓ２３０：いいえ）、今度は取得したリリース番号がＳＲＡＭ２５に現在保持しているリリース番号と異なるか否かを判断する（Ｓ２４０）。なお、このステップＳ２４０の処理が、識別情報判断手段に相当する。このリリース番号も同じであれば（Ｓ２４０：いいえ）、そのままステップＳ２１０へ戻るが、リリース番号が異なる場合は（Ｓ２４０：はい）、ステップＳ２５０へ移行して、カラオケ装置１ａ，１ｂからマスクデータ自体及びリクエスト用楽曲データを取得し、ＳＲＡＭ２５に更新記憶する。一方、Ｓ２３０にて肯定判断、つまり機種コードが異なる場合は、リリース番号の比較処理（Ｓ２４０）をすることなくステップＳ２５０へ移行し、マスクデータを取得・更新記憶する。
【００４５】
本実施例のカラオケ装置１ａ，１ｂは、図１には示さないが電源スイッチを有しており、その電源スイッチをオンすることによって、装置内の各部に電源が供給されるようになっている。そして、電源スイッチがオンされた場合、及びその後は所定時間毎（例えば１０分毎、３０分毎、１時間毎など）に、無線通信装置１５を介してリクエスト装置２に対して通信を行い、マスクデータの送信を行う。したがって、リクエスト装置２は、このカラオケ装置１ａ，１ｂから送信されるマスクデータを受信して、必要ならばＳＲＡＭ２５に更新記憶する。
【００４６】
図６のステップＳ２３０にて肯定判断となる場合というのは、例えばそれまで第１のカラオケ装置１ａのために使用されていたリクエスト装置２が第２のカラオケ装置１ｂのために使用されるようになった場合、あるいはその逆の場合などを想定している。つまり、例えばカラオケボックスにおいて、リクエスト装置２が配置されている室が変わってカラオケ１ａ，１ｂの機種が変わった場合である。図６の処理を実行、即ち、ステップＳ２５０へ移行し、マスクデータを取得、更新記憶することで、リクエスト装置２は、第１のカラオケ装置１ａ、第２のカラオケ装置１ｂのいずれにも用いることができる。それでいながら、いずれに用いた場合であっても、現在自分の相手となっているカラオケ装置１ａ，１ｂにて再生可能な曲の中からのみ検索結果を表示することとなり、自分の相手のカラオケ装置１ａ，１ｂにて再生できない曲のリクエストを受け付けることを適切に防止できる。
【００４７】
なお、上述したカラオケ装置１ａ，１ｂからリクエスト装置２へのマスクデータの送信間隔によっては、状況の変化（つまり対となるカラオケ装置１ａ，１ｂの変更）に対して一時的にマスクデータの更新が追いつかない場合もあり得る。しかし、マスクデータの更新がなされればその不都合も解消されるため、カラオケ装置１ａ，１ｂからのマスクデータの送信間隔を短くすれば、実質的な不都合をほとんど解消することが可能である。特に、カラオケボックスでは、利用者がフロントで受け付けを済ませたときにリクエスト装置２を受け取って自分が利用する室に持ち込む場合が多く、マスクデータの送信間隔を短くすれば、短時間でその室に設置されたカラオケ装置１ａ，１ｂと適合するリクエスト装置２となり、不都合を解消することができる。
【００４８】
また、図６のＳ２４０にて肯定判断となる場合というのは、例えば新曲が配信されてカラオケ装置１ａ，１ｂにて再生できる曲が増えた場合などである。そこで、カラオケ装置１ａ，１ｂにて新曲の配信を受けた場合の処理について図７のフローチャートを参照して説明する。なお、例えば新曲の配信は１日に１回、公衆回線にて接続される図示しないホストとモデム１２（図１参照）を介して通信し、新曲があればホストから配信を受けるようになっている。なお、本実施例では、カラオケ装置１ａ，１ｂは、新曲の配信があると、新たなリクエスト用楽曲データをリクエスト装置２へ無線通信装置２１を介して送るように構成されている。
【００４９】
図７の最初のステップＳ３１０において追加曲を受信すると、次に、マスクデータ内に追加曲の選曲番号を追加し、対応するビットを全て「０」とする（Ｓ３２０）。そして、自装置において何らかの再生制限設定がされているか否かを判断する（Ｓ３３０）。この再生制限設定に関しては上述したが、簡単に繰り返しておくと、例えば利用者の年齢層が低い場合にはアダルト向けの映像を伴うカラオケ曲の再生を禁止するとか、祝宴に供されるカラオケ装置にあっては、失恋の曲など雰囲気にふさわしくない曲の再生を禁止する、といった施策的観点からの対処である。
【００５０】
そして、再生制限設定がされていない場合には（Ｓ３３０：いいえ）、次に、受信した曲がその再生制限に該当せずに自装置にて再生可能であるか否かを判断する（Ｓ３４０）。この判断に際しては、例えば再生制限の種類を示す識別コードを、配信される曲データ中（例えばヘッダ部分等）に含めておき、カラオケ装置１ａ，１ｂに設定されている再生制限対象の識別コードと一致しなければ再生可能であると判断する、といったことが考えられる。
【００５１】
再生制限設定がされていない場合（Ｓ３３０：いいえ）で且つ受信した曲が再生制限対象曲に該当せずに再生可能である場合（Ｓ３４０：はい）には、ステップＳ３５０へ移行し、マスクデータ内の追加曲の選曲番号に対応するビットを「１」（マスクしない＝検索可を意味する）とする。次に、ステップＳ３６０へ移行し、全ての追加曲についてビット設定が完了したか否かを判断し、完了している場合（Ｓ３６０：はい）には、マスクデータのリリース番号をインクリメントし（Ｓ３７０）、処理を終了する。
【００５２】
また、ステップＳ３６０において全ての追加曲についてビット設定が完了していない場合（Ｓ３６０：いいえ）には、Ｓ３２０へ戻り、ステップＳ３２０〜Ｓ３５０の処理を繰り返す。
なお、リクエスト用楽曲データ（図５（ａ）参照）とは、ハードディスク１１に格納されている全ての演奏曲データに対応するデータベースである。
【００５３】
一方、再生制限設定がされている場合（Ｓ３３０：はい）、あるいは、受信した曲が再生制限に該当して再生不可能である場合（Ｓ３４０：いいえ）には、マスクデータ内の追加曲の選曲番号に対応するビットを「０」（マスクする＝検索不可能を意味する）のままとして、ステップＳ３６０へ移行する。
【００５４】
なお、図８は、カラオケ装置１ａ，１ｂにて実行されるカラオケ演奏に係る処理を示すフローチャートである。
リクエスト装置２のリモコン発光部２２から送信された選曲番号をリモコン受光部１４にて受信、という形で利用者からの選曲番号を受け付けると（Ｓ４１０）、その選曲番号に対応する演奏曲データがハードディスク１１内に存在するか否かを判断する（Ｓ４３０）。そして、該当曲が存在すれば（Ｓ４３０：はい）、演奏を開始し（Ｓ４４０）、該当曲が存在しなければ（Ｓ４３０：いいえ）、選曲不可能であることをＣＲＴ１９に表示する（Ｓ４５０）。
【００５５】
以上、本実施例のカラオケシステムによれば、次のような効果が得られる。
（イ）本実施例の第１のカラオケ装置１ａは全ての曲について再生可能（あるいは再生が禁止されていない）であり、第２のカラオケ装置１ｂは一部の曲について再生不可能（あるいは再生が禁止されている）とされている。したがって、リクエスト装置２の検索用データベースに対して何ら工夫をしないと、次のような問題が生じる。つまり、第１のカラオケ装置１ａに合わせて全ての曲をリクエスト対象としたリクエスト装置２を第２のカラオケ装置１ｂに用いた場合、リクエストは受け付けられたのに、実際にはカラオケ曲の再生が実行されない。逆に、第２のカラオケ装置１ｂにて再生可能な曲のみをリクエスト対象としたリクエスト装置２を第１のカラオケ装置１ａに用いた場合は、カラオケ曲自体は存在するのに、リクエストできないという問題が生じる。
【００５６】
そこで、この問題を解決するため本実施例のカラオケシステムでは、カラオケ装置１ａ，１ｂが定期的にマスクデータを無線通信装置１５を介して送信しており、その送信されたマスクデータを受け取ったリクエスト装置２は、更新すべきマスクデータであればＳＲＡＭ２５に更新記憶する。そしてリクエスト装置２は、検索すべき文字が入力された場合、ＳＲＡＭ２５に記憶されているリクエスト用楽曲データ（図５（ａ）参照）と、ＳＲＡＭ２５に記憶されているマスクデータとを用いて、その検索結果を表示する。具体的には、図２（ｃ）に示すように、マスクデータが第１のカラオケ装置１ａ用マスクデータであれば、特にマスク対象となっているデータがないため、リクエスト装置２では、検索結果をそのまま液晶表示部２３に表示する。それに対して、マスクデータが第２のカラオケ装置１ｂ用マスクデータであれば、例えば選曲番号２，５等のマスク対象となっているため、リクエスト装置２では、検索結果中にそれらマスク対象の曲があればそれを除く。つまり、記憶しているリクエスト用楽曲データの内、そのマスク対象の曲名については液晶表示部２３に表示しないのである。
【００５７】
このように、リクエスト装置２は、自装置が用いられているカラオケ装置１ａ，１ｂにて再生が可能な曲しかリクエストを受け付けないようにできるため、利用者にとっては、リクエストしたのにその曲が再生されない、という問題を極力防止できる。また、このような対処をしているので、リクエスト装置２は、いずれのカラオケ装置１ａ，１ｂにでも用いることができ、例えばそれまで第１のカラオケ装置１ａに利用していたリクエスト装置２が故障してしまった場合、別のリクエスト装置２で代用できる。つまり、その別のリクエスト装置２を第１のカラオケ装置１ａにおける無線通信装置１５の無線信号到達範囲内に置いてやれば、第１のカラオケ装置１ａからのマスクデータ等を受け取ることによって、その第１のカラオケ装置１ａに適したリクエスト装置２になるからである。
【００５８】
（ロ）また、本実施例ではリクエスト装置２におけるマスクデータの更新に際して、取得したマスクデータのリリース番号がＳＲＡＭ２５に現在保持しているリリース番号と異なる場合にマスクデータを更新しており、同じであれば更新しない。そのため、実質的に変更のないデータの更新作業がなされることがなく、処理負荷が低減される。
【００５９】
また、リリース番号を比較する以前に、取得した機種コードがＳＲＡＭ２５に現在保持している機種コードと異なるか否かを判断し（Ｓ２３０）、機種コードが異なれば（Ｓ２３０：はい）、マスクデータを更新する。このようにすれば、リリース番号の比較もせずにマスクデータの更新が必要であることが判断できるため、処理負荷が低減される。
【００６０】
なお、本実施例においては、演奏曲データが「提供用情報」に相当し、リクエスト用楽曲データが「リクエスト情報」に相当する。また、カラオケ装置１ａ，１ｂが情報提供装置に相当し、リクエスト装置２が「リクエスト装置」に相当する。また、リリース番号が「所定の識別情報」に相当し、機種コードが「機種情報」に相当する。さらに、リクエスト装置２のＣＰＵ２０が「検索手段」、「検索結果表示手段」、「有効曲抽出手段」、機種判断手段」、「識別情報半断手段」に相当する。
【００６１】
以上実施例について説明したが、本発明は上記実施例に限定されるものではなく、種々の態様で実施し得る。そのいくつかを説明する。
（１）上記実施例では、理解を容易にするために第１のカラオケ装置１ａと第２のカラオケ装置１ｂの２種類の存在を前提として説明したが、当然ながら、記憶している演奏曲データの内容、あるいは記憶している演奏曲データは同じであるが再生が禁止されている曲について３種類以上の違いがあるカラオケ装置群の存在を前提とした場合であっても同様に適用できる。
【００６２】
（２）上記実施例では図４のＳ５０に示すように、検索結果を表示する段階において検索結果にマスクデータを適用し、マスクすべき検索結果をリクエスト装置２の液晶表示部２３に表示しないようにしていた。しかし、例えばマスクデータをカラオケ装置１ａ，１ｂが受信した際などに、予めマスクデータを用いて、検索用データベース中において、検索対象として有効にするデータを抽出しておき、マスク対象となっているデータを検索対象から予め外しておくことも考えられる。このようにすれば、図４のＳ５０の処理は不要となり、リクエスト装置２において検索結果を表示するまでの処理時間を短くすることができる。
【００６３】
（３）上記実施例では、マスクデータの更新に関し、カラオケ装置１ａ，１ｂが主導で実行するようにした。つまり、カラオケ装置１ａ，１ｂは、電源スイッチがオンされた場合、及びその後は所定時間毎にリクエスト装置２に対して通信を行い、マスクデータの送信を行うようにした。しかし、逆にリクエスト装置２が主導でマスクデータの送信要求をするようにしてもよい。例えば、リクエスト装置２の電源スイッチ２７がオンされた場合、及びその後は所定時間毎（例えば１０分毎、３０分毎、１時間毎など）にカラオケ装置１ａ，１ｂに対して通信を行い、マスクデータの送信を要求するのである。そして、その送信要求を受けたカラオケ装置１ａ，１ｂは記憶しているマスクデータをリクエスト装置２に送信すればよい。
【００６４】
（４）上記実施例においては、カラオケ装置１ａ，１ｂとリクエスト装置２との間の通信手段として、それぞれに内蔵された無線通信装置１５，２１が例示されているが、これは内蔵されていなくてもよいし、また無線ではなく有線であってもよい。
【００６５】
（５）また、上記実施例においては、リクエスト用楽曲データは公衆回線を通じてそれ自体が配信されるように例示されているが、これはカラオケ装置１ａ，１ｂが現在保持しているリクエスト用楽曲データとの差分として配信されたり、演奏曲データ自身に含まれる形で配信され、カラオケ装置１ａ１ｂ内部で再構成されてもよいし、差分の形のままリクエスト装置２まで通知され、リクエスト装置２内でリクエスト用楽曲データとして再構成されてもよい。
【００６６】
（６）上記実施例では、カラオケ装置１ａ，１ｂ内に演奏曲データ自体は存在するのに、施策的観点から再生を禁止する例として、例えば利用者の年齢層が低い場合にはアダルト向けの映像を伴うカラオケ曲の再生を禁止するとか、祝宴に供されるカラオケ装置にあっては、失恋の曲など雰囲気にふさわしくない曲の再生を禁止する、といった例を挙げた。それ以外にも、例えば新曲の発売以前にカラオケで利用できるようになると困るが、予めカラオケ装置１ａ，１ｂへの演奏曲データの配信を行っておきたい場合もありえる。したがって、そのような場合も、演奏曲データ自体はカラオケ装置１ａ，１ｂ内に存在しながらリクエストされないようにする必要がある。この場合は、例えば配信する演奏曲データに再生が許可される期日等を含めておき、カラオケ装置１ａ，１ｂ側において、その期日になるまでは再生しない制御を実行することが考えられる。もちろん、マスクデータにも０を設定し、リクエストされないようにしておくことも考えられる。
【００６７】
（７）また、演奏曲データとリクエスト用楽曲データは必ずしも同時期にカラオケ装置１ａ，１ｂへ配信されるとは限らない。例えばリクエスト用楽曲データの方が先行して配信されることもあり得る。つまり、リリース日が不定ではあるがリリースされること自体は決まっている新曲の場合、先にリクエスト用楽曲データがカラオケ装置１ａ，１ｂへ送られ、カラオケ装置１ａ，１ｂからリクエスト装置２へも転送されることが考えられる。その場合、リクエスト装置２のＳＲＡＭ２５内における検索用データベース中には当該曲のリクエスト用楽曲データは存在するが、演奏曲データ自体がカラオケ装置１ａ，１ｂに存在しないこととなる。この場合は、たとえ全曲の再生を可能とすることを前提にしたいわゆる高機種の第１のカラオケ装置１ａであっても、カラオケ演奏曲データとリクエスト用楽曲データの不整合が生じる。したがって、上記同様、リクエスト用楽曲データに対応する演奏曲データが存在しないものについてはマスクしてリクエストされないような対処をする。
【００６８】
（８）上記実施例では、リクエスト装置２側において、機種コード及びリリース番号を判断して（図６のＳ２３０，Ｓ２４０参照）マスクデータを取得する（Ｓ２５０）ようにしたが、機種コード及びリリース番号をカラオケ装置１ａ，１ｂ側に送り、カラオケ装置１ａ，１ｂ側でマスクコードを更新する必要があるか否かを判断し、必要がある場合にマスクデータをリクエスト装置２へ送って更新するようにしても差し支えない。
【００６９】
（９）上記実施例では、カラオケシステムとして実現した場合について説明したが、カラオケシステムには限らず、リクエスト情報を検索するための検索用データベースを有し、ユーザから受け付けた操作に基づき検索した結果としてのリクエスト情報を情報提供装置に対して送信し、その受信したリクエスト情報に応じた提供用情報を用いて情報提供を実行する情報提供装置とからなるリクエスト対応型情報提供システムであれば同様に適用できる。例えばビデオサーバを利用したビデオライブラリなどが考えられる。
【００７０】
（１０）上記実施例では、図７を参照して説明したように、カラオケ装置１ａ，１ｂが、追加曲を受信すると（Ｓ３１０）、マスクデータ内に追加曲の選曲番号を追加し、対応するビットを全て「０」とし（Ｓ３２０）、自装置において何ら再生制限設定がされておらず（Ｓ３３０：いいえ）且つ再生可能な曲であれば（Ｓ３４０：はい）、マスクデータ内の追加曲の選曲番号に対応するビットを「１」（マスクしない＝検索可を意味する）とするようにした（Ｓ３５０）。つまり、デフォルト値を「０」（マスクする＝検索不可を意味する）として、再生可能な場合にのみ対応ビットを「１」にする方法を採用した。しかし、これとは逆に、デフォルト値を「１」として、再生不可能な場合にのみ対応ビットを「０」にする方法を採用してもよい。
【００７１】
また、図７のＳ３２０のようにカラオケ装置１ａ，１ｂ内でマスクデータのデフォルト値を設定するのではなく、予めデフォルト値の設定されたマスクデータをホストからカラオケ装置１ａ，１ｂが受信するようにしてもよい。
【図面の簡単な説明】
【図１】実施例のカラオケシステムの概略構成を示すブロック図である。
【図２】リクエスト用楽曲データに対するマスクデータの適用例を示す説明図である。
【図３】リクエスト装置の外観及び液晶表示部への表示内容の説明図である。
【図４】リクエスト装置にて実行されるリクエストに係る処理を示すフローチャートである。
【図５】（ａ）はリクエスト用楽曲データの説明図、（ｂ）はマスクデータの説明図である。
【図６】リクエスト装置にて実行されるマスクデータの取得・更新に係る処理を示すフローチャートである。
【図７】カラオケ装置にて実行される追加曲の受信に係る処理を示すフローチャートである。
【図８】カラオケ装置にて実行されるカラオケ演奏に係る処理を示すフローチャートである。
【符号の説明】
１ａ…第１のカラオケ装置、１ｂ…第２のカラオケ装置、９…映像再生装置、１０…ＣＰＵ、１１…ハードディスク、１２…モデム、１３…再生装置、１４…リモコン受光部、１５…無線通信装置、１６…マイクロフォン、１７…アンプ、１８…スピーカ、１９…ＣＲＴ、２０…ＣＰＵ、２１…無線通信装置、２２…リモコン発光部、２３…液晶表示部、２４…入力装置、２５…ＳＲＡＭ、２６…電源、２７…電源スイッチ。[0001]
BACKGROUND OF THE INVENTION
The present invention has an information providing apparatus that performs information provision using provision information according to received request information, and a search database for retrieving request information, and is searched based on an operation received from a user. The present invention relates to a request-compatible information providing system including a request device that transmits request information as a result to an information providing device.
[0002]
[Prior art]
2. Description of the Related Art Conventionally, for example, a karaoke system including a karaoke device that reproduces music and a remote operation device that transmits an operation command for causing the karaoke device to reproduce a predetermined music is known. In this karaoke system, when a user requests a desired song from the karaoke device, a key code such as a song name or a singer name and a request code made up of, for example, several digits of alphanumeric characters used for the request are set. The request code (referred to as a quick reference) described in the above is referenced, the request code is searched from the key data corresponding to the desired song, and the request code is input to the request device to request the request. Was realized.
[0003]
On the other hand, with the recent improvement in data distribution technology such as communication infrastructure, the distribution speed of booklets tends to be relatively reduced with respect to the speed of adding / updating karaoke songs. Therefore, a search function based on the key data is realized by holding a search database in the request device, and a user searches for a corresponding program by inputting key data corresponding to a desired song to the request device. In addition, a karaoke system for selecting and realizing the request has also been developed (see, for example, Patent Document 1).
[0004]
In this karaoke system, when the karaoke device receives distribution of a new song from the host device, a new song can be requested quickly by transmitting an additional record for searching for the new song from the karaoke device to the requesting device.
[0005]
[Patent Document 1]
Japanese Patent No. 3089529
[0006]
[Problems to be solved by the invention]
By the way, for example, even among a plurality of karaoke apparatuses existing in the same store, there may be a case where there is a difference in music that can be requested. There are two main reasons for this. One is the case where the number of reproducible songs is changed for each device depending on the provision price of the device and the difference in the usage contract. For example, because of sales policy reasons, all karaoke song data can be stored and used for expensive models, but the number of karaoke song data stored is limited for inexpensive models. It is conceivable to limit the songs that can be used. It is also conceivable to limit the number of karaoke song data that can be used according to the usage contract. These are cases where karaoke song data does not physically exist in the karaoke apparatus.
[0007]
On the other hand, even if there is karaoke song data in the karaoke device, for example, there is a restriction from a policy viewpoint that some karaoke songs are not played depending on the user layer. For example, if the user's age group is low, playback of karaoke songs accompanied by video for adults is prohibited, or in a karaoke device used for banquets, playback of songs that are not suitable for the atmosphere such as broken love songs It is prohibited.
[0008]
Thus, when the music which can be reproduced | regenerated differs for every karaoke apparatus, the following inconvenience arises. In other words, it is preferable that the search database included in the request device corresponds to a database that can make the most extensive requests in the karaoke device. That is, a search database for all songs is provided so as to correspond to a karaoke apparatus capable of reproducing all songs. In general, it is preferable that any request device can be used as the request device. On the other hand, if only a specific request device can be used for a specific karaoke device, it becomes very inconvenient in terms of management.
[0009]
However, when a request device having a search database for all songs is prepared so as to correspond to a karaoke device capable of reproducing all songs, versatility can be ensured, but this time the karaoke device can be requested even though it can be requested. In this case, a situation occurs in which reproduction corresponding to the request cannot be performed. Of course, it is conceivable to accept the request itself and give notifications such as “unreproducible” and “prohibit reproduction” at the time of reproduction. However, if such a countermeasure occurs frequently, the user may be awakened. For this reason, it is preferable to prevent the request itself from being accepted.
[0010]
Such a problem is not limited to the karaoke system, but has a search database for searching for request information, and requests information as a result of searching based on an operation received from the user is sent to the information providing apparatus. This occurs in the same manner as long as it is a request-compatible information providing system including an information providing apparatus that transmits and provides information using information for provision corresponding to the received request information.
[0011]
Therefore, according to the present invention, if request information is transmitted from a request device to an information providing device, the information providing device that has received the request information has provision information corresponding to the request information as much as possible. The purpose is to enable the provision of information.
[0012]
[Means for Solving the Problems and Effects of the Invention]
(1) The request correspondence type information provision system of the present invention made to solve the above-mentioned problems includes request information corresponding to provision information that can be provided by the information provision device, and a search database included in the request device. It is assumed that there may be a situation where the request information existing in the request does not necessarily match. For example, in the case of a karaoke system, a plurality of models are prepared, and in some models, karaoke songs corresponding to all the request information existing in the search database of the request device can be played, and in some models, some karaoke songs can be played. It may be possible not to be able to play about the. This is mainly due to physical viewpoints such as storage capacity in data storage means such as a hard disk, usage contracts, and sales policy. Moreover, even if it is the same model, the situation from the policy viewpoint of not performing a part of karaoke music according to a user layer (although karaoke music itself exists) is also considered. For example, for adults and kids, it is a case where the target music is narrowed down according to the customer base, and conversely, it is protected so as to be actively removed from the request target.
[0013]
For this reason, inconsistency occurs between the request information corresponding to the provision information that can be provided by the information provision device and the request information that exists in the search database. However, there is a disadvantage that information cannot be provided by the information providing apparatus.
[0014]
In order to solve this inconvenience, in the request-corresponding information providing system according to the present invention, the information providing apparatus converts the request information existing in the search database of the request apparatus into information for provision that can be provided by the information providing apparatus. The request device that transmits the mask data for distinguishing the corresponding request information from the other request information to the request device and receives and stores the mask data corresponds to the information for provision that can be provided by the information providing device. The stored mask data is used for adjustment so that only the request information to be handled is effectively handled as a search result.
[0015]
As a result, if request information treated as an effective search result in the search by the request device is transmitted from the request device to the information providing device, the information providing device that has received the request information includes the request information as much as possible. Information for provision exists according to the information, and information provision according to the request is realized.
[0016]
(2) Regarding the adjustment using the mask data in the request device, for example, as shown in claim 2, the provision of information that can be provided by the information providing device in the request information in the search database using the mask data It is conceivable that only request information corresponding to the business information is set as a search target, and request information that is not so is excluded from the search target and the search is executed. If the information providing apparatus is previously excluded from the search target in this way, a request that cannot be provided by the information providing apparatus is not extracted as a search result. In addition, as shown in claim 3, it has a display means for displaying the search results, and when displaying the search results on the display means, using the mask data, Only information that is request information corresponding to providing information that can be provided by the information providing apparatus may be displayed, and may not be displayed otherwise. In this way, a request that cannot be provided by the information providing apparatus is not displayed as a search result on the display means. Therefore, if request information selected from the displayed search results is transmitted to the information providing apparatus, information provision according to the request is realized as much as possible.
[0017]
(3) Although the mask data in the request device needs to be updated as appropriate, it is conceivable that the mask data from the information providing device to the request is transmitted as follows.
First, as shown in claim 4, it is conceivable that the requesting device requests the information providing device to transmit mask data at a predetermined timing. The information providing apparatus transmits mask data to the request apparatus in response to a transmission request from the request apparatus, and the request apparatus receives and stores the transmitted mask data. As the “predetermined timing” in this case, for example, it can be considered as shown in claim 5. In other words, the request device has a power switch for turning on / off the power (of the request device itself), and when the power switch is turned on, or at least one timing every predetermined time after the power is turned on Then, a mask data transmission request is made.
[0018]
Further, as shown in claim 6, the information providing apparatus may transmit the mask data to the requesting apparatus at a predetermined timing. The request device receives and stores the transmitted mask data. As the “predetermined timing” in this case, for example, it can be considered as shown in claim 7. That is, the information providing apparatus has a power switch for turning on / off the power (of the information providing apparatus itself), and when the power switch is turned on or at least every predetermined time after the power is turned on The mask data is transmitted to the requesting device at the timing.
[0019]
(4) Further, regarding the update of the mask data in the requesting device, the following device may be considered. For example, as shown in claim 8, the information providing device uniquely changes the value of the predetermined identification information every time the content of the mask data is updated, adds the identification information to the mask data, and transmits it to the request device. To do. Then, the requesting device that has received the transmitted mask data compares the identification information added to the previous mask data with the identification information added to the mask data received this time, and only if they are different The update is stored.
[0020]
In this way, the data update operation that does not substantially change is not performed, and the processing load is reduced.
Further, if the information providing apparatus is set to distinguish between models according to the contents of the providing information that can provide information, the information providing apparatus may be configured as shown in claim 9. That is, model information for identifying the model is added to the mask data and transmitted to the requesting device. Then, the request device that has received the transmitted mask data compares the model information added to the previous mask data with the model information added to the mask data received this time, and updates if the two are different Remember it.
[0021]
In this way, since it is possible to determine whether or not the update is necessary only by comparing the model information without comparing the mask data itself, the processing load is further reduced.
(5) It should be noted that, as shown in claim 10, a request device used in the request correspondence type information providing system according to any one of claims 1 to 9, wherein the request device is described in each claim. It can also be realized as a request device having a configuration.
[0022]
If it is such a request apparatus, it will play a significant role in exhibiting the above-mentioned effect by being used for the above-mentioned request correspondence type information providing system.
[0023]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments to which the present invention is applied will be described below with reference to the drawings. Needless to say, the embodiments of the present invention are not limited to the following examples, and can take various forms as long as they belong to the technical scope of the present invention.
[0024]
FIG. 1 is a block diagram showing the configuration of a karaoke system as an embodiment of the request-compatible information providing system of the present invention. The karaoke system of the present embodiment is composed of a karaoke device 1a and a request device 2, or a karaoke device 1b and a request device 2. The karaoke apparatus 1a and the karaoke apparatus 1b are different in the contents of the stored performance music data, or in the music for which playback is prohibited although the stored performance music data is the same. Therefore, when it is necessary to distinguish between the two, the first karaoke device 1a and the second karaoke device 1b are individually described. When there is no need to distinguish between the two, the karaoke device is simply described. These are described as 1a and 1b. On the other hand, even if there are a plurality of request devices 2, there is no difference in the configuration thereof, and the request device 2 can be used for either the first karaoke device 1a or the second karaoke device 1b. However, as described above, the first karaoke device 1a and the second karaoke device 1b are different in the contents of the stored performance music data or stored in the same performance music data but are reproduced. Since there is a difference in the prohibited music, a predetermined process is performed to cope with the difference. The predetermined process will be described later.
[0025]
[Configuration of Karaoke Apparatus 1a, 1b]
As shown in FIG. 1, the karaoke apparatuses 1a and 1b are connected to a host computer (not shown) via a communication network such as a public line, and control the entire karaoke apparatuses 1a and 1b. The CPU 10, the hard disk 11 storing karaoke music information, image information and other various data, the playback device 13 for reproducing the performance, the amplifier 17 for amplifying the electrical signal related to the music information, and the electrical signal from the amplifier 17 A speaker 18 for inputting an accompaniment and a user's singing voice, a microphone (hereinafter simply referred to as a microphone) 16 for inputting a user's singing voice and the like to the amplifier 17, and image information stored in the hard disk 11. A video playback device 9 for playing back background images and lyrics as video information, and a CRT for displaying the played back video 9. Remote control light receiving unit 14 that receives a remote control signal by infrared rays or the like emitted from the request device 2 and the request device 2 wirelessly using bidirectional communication (for example, wireless communication based on Bluetooth standard or IrDA (Infrared Data Association)) A wireless communication device 15 for communication). Among these, the hard disk 11, modem 12, playback device 13, remote control light receiver 14, wireless communication device 15, and video playback device 9 are connected to the CPU 14.
[0026]
The modem 12 described above is a modem device that modulates and demodulates a signal, and is configured to be accessible to a host computer through a public line under the control of the CPU 10. As a result, the modem 12 receives the additional music piece data (new song data, etc.) sent from the host computer via the public line, or requests music data distributed in the same way as the music piece data. (See FIG. 5A).
[0027]
The performance music data, the request music data, and the mask data received here are stored in the hard disk 11 as files. The performance music data is read out during karaoke performance and used for performance processing, and the request music data and the mask data are transmitted to the request device 2 through the wireless communication device 15.
[0028]
For example, in karaoke performance processing, performance music data output from the CPU 10 is converted into an analog performance sound signal by the playback device 13 and then sent to the amplifier 17 to be electrically amplified. This amplifier 17 is mixed with a user (singer) singing sound signal input via the microphone 16 at an appropriate ratio, and the mixed singing sound signal and performance sound signal are sent from the amplifier 17 to the speaker 18. And output as sound and performance sound from the speaker 18 to the outside. On the other hand, the video reproduction device 9 reproduces lyrics and background images based on image information read from the hard disk 11 and outputs them to the CRT 19 under the control of the CPU 14, and the CRT 19 displays them. Thereby, in the CPU 19, the lyrics data is synthesized with the video data, and the lyrics telop is displayed together with the background video. Due to such a configuration, the user can sing using the microphone 16 in accordance with the karaoke performance flowing from the speaker 18 while referring to the lyrics telop displayed on the CRT 19.
[0029]
The first karaoke device 1a and the second karaoke device 1b of the present embodiment are different in the contents of the stored performance music data, or the stored performance music data is the same, but reproduction is prohibited. There is a difference in the songs being played. For example, as shown in FIGS. 2 (a) and 2 (b), the first karaoke device 1a can play back all songs (or playback is not prohibited), and the second karaoke device 1b has a part of it. The song is not playable (or playback is prohibited).
[0030]
There are two main causes for these differences. One is when the number of reproducible songs is changed for each device depending on the provision price of the karaoke apparatuses 1a and 1b and the difference in the usage contract. For example, if the first karaoke apparatus 1a is an expensive model, the data storage capacity of the hard disk 11 is sufficient and all karaoke song data is stored. For example, the second karaoke apparatus 1b is an inexpensive model. In this case, the data storage capacity of the hard disk 11 is limited, or the number of karaoke song data that can be stored is limited due to business policies. Further, even if the data storage capacity of the hard disk 11 has a margin, it is conceivable to limit the number of karaoke song data to be accumulated by the use contract. These are cases where the karaoke song data does not physically exist in the karaoke apparatuses 1a and 1b.
[0031]
On the other hand, there may be factors due to countermeasures from a policy perspective. For example, if the user's age group is low, playback of karaoke songs accompanied by video for adults is prohibited, or in a karaoke device used for banquets, playback of songs that are not suitable for the atmosphere such as broken love songs It is prohibited. Such reproduction prohibition can be set for each of the karaoke apparatuses 1a and 1b. Normally, in a karaoke box, one karaoke device 1a, 1b is installed in each room, and the above-mentioned reproduction prohibition setting is set for each room, and according to the setting of the usage fee of each room, for example. Then, the models of the installed karaoke apparatuses 1a and 1b are selected and installed.
[0032]
[Configuration of Request Device 2]
On the other hand, one or a plurality of request devices 2 are arranged for each room corresponding to the karaoke devices 1a and 1b installed in each room of the karaoke box. In addition, as shown in FIG. 1, the CPU 20 that controls the entire request device 2, the wireless communication device 21 for wirelessly communicating with the karaoke devices 1 a and 1 b (Bluetooth and IrDA), and the karaoke devices 1 a and 1 b Remote control light emitting unit 22 for emitting a remote control signal by infrared rays, a liquid crystal display unit 23 as a display device, an input device 24 and SRAM 25 as input means, a power source 26 comprising a secondary battery such as a nickel cadmium, and the power source 26. A power switch 27 is provided.
[0033]
The request device 2 stores the mask data (see FIG. 5B) received from the karaokes 1a and 1b via the wireless communication device 21 as a file in the SRAM 25. Further, at the same opportunity as receiving this mask data or at another opportunity, request music data (see FIG. 5A) is also received and stored in the SRAM 25 as a file in the same manner as described above. The music data for request includes a song selection number, a song name, a name of a singer who sang the song, genre information to which the song belongs, a release date of the song, and the like. For example, the first karaoke device If, for example, 10,000 karaoke songs can be reproduced in either the 1a or the second karaoke apparatus 1b, the requested song data for 10,000 songs exists. This constitutes the “search database”. Here, the SRAM 25 is a memory capable of holding recorded information even when the power switch 27 is shut off.
[0034]
The input device 24 is operated by the user, and can be used to select an arbitrary song, adjust the key of the performance sound, adjust the volume balance between the performance and the song, and perform various adjustments such as echo, volume, and tone. For example, the music number or the music title input or selected by operating the input device 24 is displayed on the liquid crystal display unit 23. As shown in FIG. 3, the input device 24 is provided with a numeric keypad in the center on the front side of the requesting device 2, and in addition, a selection key and various function keys are provided. A number can be input using a provided numeric keypad, and a character can be input. Character input is used, for example, when searching by a character attached to the beginning of a song name or singer name. With regard to this character input, for example, it may be possible to follow a character input method on a mobile phone that is commonly seen at present. Thus, the name of the song to be searched can be input. For example, if you want to enter “A”, press the “1” keypad once, then press the “>” key, and if you want to enter “RO”, press the “9” key five times. Later, press the “>” key. In the case of searching by the character prefixed to the above-mentioned song name, the request device 2 displays a song name that meets the conditions (in this case, the song name prefixed with “A”) as shown in FIG. Then, a cursor indicated by a black circle is displayed beside the song name displayed at the top. The user presses an arrow key (← → ↑ ↓) shown at the lower part on the front side of the request device 2 to move the cursor, selects a desired song and presses the selection key to confirm the requested song. .
[0035]
When the requested music is determined in this way, the CPU 20 transmits the music selection number (music selection information) of the music corresponding to the selected music name as an infrared signal through the remote controller light emitting unit 22. When the karaoke apparatus 1a, 1b receives the infrared signal by the remote controller light receiving unit 14, the karaoke apparatus 1a, 1b performs a karaoke song corresponding to the music selection number analyzed from the received signal. In the request device 2, when the power switch 27 is turned on, power is supplied from the power source 26 to the CPU 20, the wireless communication device 21, the remote controller light emitting unit 22, the liquid crystal display unit 23, the SRAM 25, and the like. The power supply 26 is charged when the request device 2 is set in a cradle (not shown).
[0036]
[Processing executed by request device 2 and karaoke devices 1a and 1b]
By the way, the request apparatus 2 of a present Example can be used for any of the 1st karaoke apparatus 1a or the 2nd karaoke apparatus 1b as mentioned above. However, in the first karaoke device 1a and the second karaoke device 1b, the contents of the stored performance music data are different, or the music performance data stored is the same, but reproduction is prohibited. There is a difference. For example, as shown in FIGS. 2 (a) and 2 (b), the first karaoke device 1a can play back all songs (or playback is not prohibited), and the second karaoke device 1b has a part of it. The song is not playable (or playback is prohibited). Usually, in the karaoke box, the first karaoke device 1a and the karaoke device 1b of the table 2 are installed in different rooms. Therefore, it is necessary for the requesting apparatus 2 to cope with the request only in the music that can be reproduced by the karaoke apparatuses 1a and 1b that are currently paired with the requesting apparatus 2 in each room of the karaoke box.
[0037]
As a countermeasure, the request device 2 of the present embodiment includes the request music data (see FIG. 5A) stored in the SRAM 25, and the mask data received from the karaoke devices 1a and 1b and stored in the SRAM 25 most recently. Is used to perform a predetermined process. The processing contents are conceptually shown in FIG. In other words, if the most recently received and stored mask data is the mask data for the first karaoke device 1a, there is no data to be masked. All of the data can be displayed on the liquid crystal display unit 23. On the other hand, if the mask data received and stored most recently is the mask data for the second karaoke device 1b, the request device 2 stores the mask data, for example, the music selection numbers 2, 5 and so on. Among the requested music data for request, the masked music name is not displayed on the liquid crystal display unit 23.
[0038]
The specific processing will be described with reference to the flowchart of FIG.
FIG. 4 shows the request processing by the song name search executed in the requesting device 2. After clearing the song input buffer in the first step 10, it is determined whether or not there is a character input from the user (S20). . If there is a character input (S20: Yes), the input character is added to the music title input buffer (S30). Then, using the contents of the song name input buffer as a key, the search database in the SRAM 25 is searched for a matching condition (S40). Note that the processing in step S40 corresponds to a search means. Then, the mask data stored in the SRAM 25 is applied to the search result, and only the effective music is extracted (S50), and the search result after the mask application is displayed on the liquid crystal display unit 23 (S60). . The process of step S60 corresponds to the search result display unit, and the process of step S50 corresponds to the effective song extraction unit. Then, it is determined whether or not there is a display target song (S70). If there is a display target song (S70: Yes), the temporary music selection target is set as the song displayed on the liquid crystal display unit 23, and the cursor is moved. A display is made according to the top (S80).
[0039]
Here, if the input character is “A”, when the request device 2 is used in a pair with the first karaoke device 1a, the request device 2 is displayed as shown in FIG. Is used as a pair with the second karaoke apparatus 1b, it is displayed as shown in FIG. That is, as described above with reference to FIG. 2C, when the request device 2 is used in a pair with the first karaoke device 1a, the mask for the first karaoke device 1a is stored in the SRAM 25 of the request device 2. Although data is stored, in this case, since there is no data to be masked in particular, as shown in FIG. 3 (b), all the music titles prefixed with “A” are displayed. On the other hand, when the request device 2 is used in a pair with the second karaoke device 1b, the mask data for the second karaoke device 1b is stored in the SRAM 25 of the request device 2, but in this case, the mask object Since there is a song, as shown in FIG. 3C, a part of the song displayed in FIG. 3B is not displayed. Of course, since there is a limit to the number of songs that can be displayed on the liquid crystal display unit 23 at a time, in any case, if the number of songs in the search results is large, the song name that is displayed first becomes a part of the search results. In this case, the scrolling display is sequentially performed by moving the cursor.
[0040]
Returning to the description of the processing in FIG. 4, in the next step S90, it is determined whether or not the “↑” key of the arrow keys (← → ↑ ↓) shown at the lower part on the front side of the requesting device 2 has been pressed. If it has been performed (S90: Yes), the temporary selection target is set to the music displayed immediately above the music corresponding to the cursor at the current time, and the cursor is displayed in accordance with the corresponding part (S100). As shown in FIGS. 3B and 3C, the cursor is not moved in a state where the cursor is present on the music that is initially displayed as the search result. If it is not the “↑” key (S90: No), it is determined whether or not the “↓” key is pressed (S110). If it is pressed (S110: Yes), the temporary selection target is The music is displayed immediately below the music corresponding to the current cursor, and the cursor is displayed in accordance with the corresponding part (S120). For example, although there are 10 search results, only the first 5 songs are displayed as shown in FIG. 3B, for example, and the cursor is displayed in accordance with the song located at the bottom in the display state. If it is, the second to sixth songs are displayed by scroll display, and the cursor moves to the position of the sixth song. The same applies to the subsequent songs. Of course, in such a state that the 5th to 10th music is displayed by scrolling and the cursor is moved to the position of the 10th music, there is no music less than that, so naturally the cursor is moved. Do not do.
[0041]
When the music selection key is pressed instead of the “↑” key or the “↓” key (S130: Yes), a music selection code corresponding to the temporary music selection target (that is, corresponding to the cursor position) is transmitted from the remote controller light emitting unit 22. It transmits toward karaoke apparatus 1a, 1b (S140). Thereafter, the process returns to S20.
[0042]
Next, a process in which the request device 2 receives mask data from the karaoke devices 1a and 1b and stores it in the SRAM 25 will be described with reference to FIGS.
The flowchart of FIG. 6 is a process executed in parallel with the process related to the request of FIG.
[0043]
In the first step S210, it is determined whether or not there is (wireless communication) communication from the karaoke apparatuses 1a and 1b. If there is communication (S210: Yes), the process proceeds to S220 and the wireless communication apparatus 21 is used. Get the mask data model code and release number. Here, the configuration of the mask data transmitted from the karaoke apparatuses 1a and 1b will be described with reference to FIG. Mask data for the first karaoke device 1a is stored in the first karaoke device 1a, and mask data for the second karaoke device 1b is stored in the second karaoke device 1b. In each mask data, in addition to the model code and release number, the mask content is set to “1” or “0” corresponding to the music selection number. Here, the mask content “1” means “do not mask”, that is, enable as a request target, and the mask content “0” means “mask”, that is, disable as a request target. . The release number is incremented each time the mask data for the first karaoke device 1a and the mask data for the second karaoke device 1b are updated. The model code is set to “01” for the first karaoke device 1a and “02” for the second karaoke device 1b. The model code may be, for example, a content that is distinguished for each product type of the karaoke device, or may be a content that can be distinguished for each karaoke device. That is, even if they are the same product type, they are distinguished if the devices are different. As a model code in this case, for example, a serial number such as a manufacturing number may be used. When the karaoke box operator restricts the songs that can be used from the viewpoint of sales policy, it is necessary to distinguish even the same product type, and thus it is necessary to set such a model code.
[0044]
Returning to FIG. 6, the request device 2 that has acquired the model code and release number of the mask data described above determines whether or not the acquired model code is different from the model code currently held in the SRAM 25 (S230). Note that the processing in step S230 corresponds to a model determination unit. When the model codes are the same (S230: No), it is determined whether or not the acquired release number is different from the release number currently held in the SRAM 25 (S240). Note that the processing in step S240 corresponds to identification information determination means. If this release number is also the same (S240: No), the process returns to Step S210 as it is, but if the release number is different (S240: Yes), the process proceeds to Step S250 and the mask data itself and the karaoke devices 1a and 1b and Request music data is acquired and updated and stored in the SRAM 25. On the other hand, if the determination in S230 is affirmative, that is, if the model code is different, the process proceeds to step S250 without performing release number comparison processing (S240), and mask data is acquired / updated and stored.
[0045]
The karaoke apparatuses 1a and 1b of this embodiment have a power switch (not shown in FIG. 1), and power is supplied to each part in the apparatus by turning on the power switch. . Then, when the power switch is turned on, and thereafter every predetermined time (for example, every 10 minutes, every 30 minutes, every hour, etc.), communication is performed to the request device 2 via the wireless communication device 15, Transmit mask data. Therefore, the request device 2 receives the mask data transmitted from the karaoke devices 1a and 1b and updates and stores it in the SRAM 25 if necessary.
[0046]
The case where an affirmative determination is made in step S230 of FIG. 6 is that, for example, the request device 2 that has been used for the first karaoke device 1a until then is used for the second karaoke device 1b. It is assumed that this happens or vice versa. That is, for example, in the karaoke box, the room in which the request device 2 is arranged changes and the models of the karaokes 1a and 1b change. The request device 2 is used for both the first karaoke device 1a and the second karaoke device 1b by executing the processing of FIG. 6, that is, moving to step S250 to acquire and update and store the mask data. Can do. Nevertheless, in any case, the search result is displayed only from the songs that can be played back by the karaoke apparatuses 1a and 1b that are currently his / her partner, and the karaoke of his / her partner is displayed. It is possible to appropriately prevent a request for a song that cannot be played back by the devices 1a and 1b.
[0047]
In addition, depending on the transmission interval of the mask data from the karaoke apparatuses 1a and 1b to the request apparatus 2 described above, the mask data is temporarily updated in response to a change in the situation (that is, a change of the paired karaoke apparatuses 1a and 1b). It may not catch up. However, if the mask data is updated, the inconvenience is also eliminated. Therefore, if the transmission interval of the mask data from the karaoke apparatuses 1a and 1b is shortened, the substantial inconvenience can be almost eliminated. In particular, in a karaoke box, when the user has completed reception at the front desk, the request device 2 is often received and brought into the room that the user uses. If the mask data transmission interval is shortened, the user can quickly enter the room. The request device 2 is compatible with the installed karaoke devices 1a and 1b, and the inconvenience can be solved.
[0048]
Moreover, the case where an affirmative determination is made in S240 of FIG. 6 is a case where, for example, a new song is distributed and the number of songs that can be reproduced by the karaoke apparatuses 1a and 1b increases. Accordingly, processing when a new song is received by the karaoke apparatuses 1a and 1b will be described with reference to the flowchart of FIG. For example, a new song is distributed once a day by communicating with a host (not shown) connected via a public line via a modem 12 (see FIG. 1), and if there is a new song, the host receives the distribution. Yes. In this embodiment, the karaoke apparatuses 1 a and 1 b are configured to send new request music data to the request apparatus 2 via the wireless communication apparatus 21 when a new song is distributed.
[0049]
When the additional music is received in the first step S310 of FIG. 7, the music selection number of the additional music is added to the mask data, and the corresponding bits are all set to “0” (S320). Then, it is determined whether or not any reproduction restriction setting is made in the own apparatus (S330). Although this playback restriction setting has been described above, if it is simply repeated, for example, if the user's age group is low, playback of karaoke songs accompanied by adult videos is prohibited, or a karaoke device used for a celebration In that case, it is a countermeasure from a policy point of view, for example, prohibiting the reproduction of songs that are not suitable for the atmosphere, such as broken love songs.
[0050]
If the playback restriction is not set (S330: No), it is next determined whether or not the received song can be played back by the own device without corresponding to the playback restriction (S340). . For this determination, for example, an identification code indicating the type of playback restriction is included in the music data to be distributed (for example, the header portion), and the playback restriction target identification code set in the karaoke apparatuses 1a and 1b If they do not match, it may be determined that the reproduction is possible.
[0051]
If the playback restriction is not set (S330: No), and the received song is not applicable to the playback restriction target song and can be played back (S340: Yes), the process proceeds to step S350 and the mask data is stored. The bit corresponding to the music selection number of the additional music is “1” (not masked = means searchable). Next, the process proceeds to step S360, where it is determined whether or not the bit setting has been completed for all the additional songs. If it has been completed (S360: Yes), the release number of the mask data is incremented (S370). The process is terminated.
[0052]
If bit setting has not been completed for all the additional music pieces in step S360 (S360: No), the process returns to S320, and the processes in steps S320 to S350 are repeated.
The request music data (see FIG. 5A) is a database corresponding to all performance music data stored in the hard disk 11.
[0053]
On the other hand, if the playback restriction is set (S330: Yes), or if the received song falls under the playback restriction and cannot be played (S340: No), the selection of the additional song in the mask data is performed. The bit corresponding to the number is kept “0” (masking = implying search impossible), and the process proceeds to step S360.
[0054]
In addition, FIG. 8 is a flowchart which shows the process which concerns on the karaoke performance performed with karaoke apparatus 1a, 1b.
When the music selection number transmitted from the remote control light emitting unit 22 of the request device 2 is received by the remote control light receiving unit 14 (S410), the performance music data corresponding to the music selection number is stored in the hard disk. 11 is present or not (S430). If the corresponding music exists (S430: Yes), the performance is started (S440). If the corresponding music does not exist (S430: No), the CRT 19 displays that the music cannot be selected (S450).
[0055]
As described above, according to the karaoke system of the present embodiment, the following effects can be obtained.
(A) The first karaoke apparatus 1a of this embodiment can reproduce all songs (or reproduction is not prohibited), and the second karaoke apparatus 1b cannot reproduce (or reproduce) some songs. Is prohibited). Therefore, the following problems arise if no effort is made to the search database of the requesting device 2. That is, when the request device 2 for requesting all songs in accordance with the first karaoke device 1a is used for the second karaoke device 1b, the request is accepted, but the karaoke song is actually reproduced. Not executed. On the other hand, when the request device 2 for requesting only a song that can be played back by the second karaoke device 1b is used for the first karaoke device 1a, the karaoke song itself exists but cannot be requested. Occurs.
[0056]
Therefore, in order to solve this problem, in the karaoke system of the present embodiment, the karaoke apparatuses 1a and 1b periodically transmit mask data via the wireless communication apparatus 15, and the request that has received the transmitted mask data. The device 2 updates and stores it in the SRAM 25 if it is mask data to be updated. When the character to be searched is input, the request device 2 uses the request music data (see FIG. 5A) stored in the SRAM 25 and the mask data stored in the SRAM 25, Display search results. Specifically, as shown in FIG. 2 (c), if the mask data is mask data for the first karaoke device 1a, there is no data to be masked. Is displayed on the liquid crystal display unit 23 as it is. On the other hand, if the mask data is the mask data for the second karaoke device 1b, for example, the song selection numbers 2, 5, etc. are masked. If there is, exclude it. That is, the masked song name in the stored request song data is not displayed on the liquid crystal display unit 23.
[0057]
In this way, the request device 2 can accept requests only for songs that can be played back by the karaoke devices 1a and 1b in which the request device is used. The problem of not being regenerated can be prevented as much as possible. Further, since such measures are taken, the request device 2 can be used for any karaoke device 1a, 1b. For example, the request device 2 that has been used for the first karaoke device 1a until then has failed. If this happens, another requesting device 2 can be substituted. That is, if the other request device 2 is placed within the wireless signal reachable range of the wireless communication device 15 in the first karaoke device 1a, the first request device 2 receives the mask data from the first karaoke device 1a, and so on. This is because the request device 2 is suitable for one karaoke device 1a.
[0058]
(B) Also, in this embodiment, when updating the mask data in the requesting device 2, if the release number of the acquired mask data is different from the release number currently held in the SRAM 25, the mask data is updated. Do not update if present. For this reason, the data update operation which is not substantially changed is not performed, and the processing load is reduced.
[0059]
Before comparing the release numbers, it is determined whether the acquired model code is different from the model code currently held in the SRAM 25 (S230). If the model code is different (S230: Yes), the mask data is stored. Update. In this way, it is possible to determine that the mask data needs to be updated without comparing the release numbers, so the processing load is reduced.
[0060]
In this embodiment, the performance music data corresponds to “providing information”, and the request music data corresponds to “request information”. The karaoke apparatuses 1a and 1b correspond to information providing apparatuses, and the request apparatus 2 corresponds to a “request apparatus”. The release number corresponds to “predetermined identification information”, and the model code corresponds to “model information”. Further, the CPU 20 of the requesting device 2 corresponds to “search means”, “search result display means”, “effective song extraction means”, model determination means ”, and“ identification information half-cut means ”.
[0061]
Although the embodiments have been described above, the present invention is not limited to the above embodiments, and can be implemented in various modes. Some of them will be explained.
(1) In the above embodiment, the description has been made on the premise that there are two kinds of the first karaoke apparatus 1a and the second karaoke apparatus 1b for easy understanding. The same applies to the case where it is assumed that there is a group of karaoke devices having three or more types of differences in the contents of the music or stored musical composition data but reproduction is prohibited.
[0062]
(2) In the above embodiment, as shown in S50 of FIG. 4, the mask data is applied to the search result at the stage of displaying the search result, and the search result to be masked is not displayed on the liquid crystal display unit 23 of the request device 2. I was doing. However, for example, when the karaoke apparatuses 1a and 1b receive the mask data, the mask data is used in advance to extract data to be validated as a search target in the search database, and the mask data becomes a mask target. It is also possible to remove the data from the search target in advance. In this way, the processing of S50 of FIG. 4 is not necessary, and the processing time until the search result is displayed in the request device 2 can be shortened.
[0063]
(3) In the above-described embodiment, the karaoke apparatuses 1a and 1b are led and executed for updating the mask data. In other words, the karaoke apparatuses 1a and 1b communicate with the request apparatus 2 when the power switch is turned on and thereafter, and transmit mask data. However, conversely, the request device 2 may take the initiative in making a mask data transmission request. For example, when the power switch 27 of the request apparatus 2 is turned on and thereafter, the communication is performed with respect to the karaoke apparatuses 1a and 1b every predetermined time (for example, every 10 minutes, every 30 minutes, every hour, etc.) and masked. It requests data transmission. The karaoke apparatuses 1a and 1b that have received the transmission request may transmit the stored mask data to the request apparatus 2.
[0064]
(4) In the above embodiment, as the communication means between the karaoke apparatuses 1a and 1b and the request apparatus 2, the wireless communication apparatuses 15 and 21 incorporated therein are exemplified, but this is not incorporated. It may be wired instead of wireless.
[0065]
(5) In the above embodiment, the request music data is exemplified to be distributed through the public line. This is the request music data currently held by the karaoke apparatuses 1a and 1b. Or as a difference included in the performance music data itself, and may be reconfigured inside the karaoke apparatus 1a1b, or notified to the request apparatus 2 in the form of the difference, and within the request apparatus 2 It may be reconfigured as music data for request.
[0066]
(6) In the above embodiment, although the performance music data itself exists in the karaoke apparatuses 1a and 1b, as an example of prohibiting playback from a policy point of view, for example, when the user's age group is low, Examples include prohibiting playback of karaoke songs accompanied by video, or prohibiting playback of songs that are not suitable for the atmosphere, such as broken love songs, for karaoke devices used for banquets. In addition to this, for example, it becomes troublesome to be able to use it in karaoke before the release of a new song, but there may be a case where it is desired to distribute performance song data to the karaoke apparatuses 1a and 1b in advance. Therefore, even in such a case, it is necessary to prevent performance music data itself from being requested even though it exists in the karaoke apparatuses 1a and 1b. In this case, for example, it is conceivable that the performance music data to be distributed includes a date when reproduction is permitted, and the karaoke apparatuses 1a and 1b perform control not to reproduce until the due date. Of course, it is also conceivable that the mask data is set to 0 so that it is not requested.
[0067]
(7) Further, the performance music data and the request music data are not necessarily delivered to the karaoke apparatuses 1a and 1b at the same time. For example, the request music data may be distributed in advance. In other words, in the case of a new song whose release date is indefinite but the release itself is determined, the request song data is first sent to the karaoke devices 1a, 1b and transferred from the karaoke devices 1a, 1b to the request device 2 as well. It is thought that it is done. In this case, the request song data for the song exists in the search database in the SRAM 25 of the request device 2, but the performance song data itself does not exist in the karaoke devices 1a and 1b. In this case, even if the so-called high-quality first karaoke apparatus 1a is based on the premise that all songs can be reproduced, inconsistency between the karaoke performance song data and the request song data occurs. Therefore, in the same manner as described above, if there is no performance music data corresponding to the request music data, a countermeasure is taken so that it is not requested by masking.
[0068]
(8) In the above embodiment, the request device 2 determines the model code and the release number (see S230 and S240 in FIG. 6) and acquires the mask data (S250). Is sent to the karaoke apparatus 1a, 1b side, and it is determined whether the mask code needs to be updated on the karaoke apparatus 1a, 1b side, and if necessary, the mask data is sent to the request apparatus 2 for updating. There is no problem.
[0069]
(9) In the above embodiment, the case where the system is realized as a karaoke system has been described. However, not only the karaoke system but also a search database for searching for request information, and a search result based on an operation received from a user. As long as it is a request-compatible information providing system comprising an information providing apparatus that transmits request information to the information providing apparatus and performs information provision using information for provision according to the received request information Applicable. For example, a video library using a video server can be considered.
[0070]
(10) In the above-described embodiment, as described with reference to FIG. 7, when the karaoke apparatuses 1a and 1b receive the additional music (S310), the music selection number of the additional music is added to the mask data, and correspondingly performed. If all the bits are set to “0” (S320), no playback restriction is set in the own device (S330: No), and the music can be played back (S340: Yes), the music selection of the additional music in the mask data The bit corresponding to the number is set to “1” (do not mask = means search is possible) (S350). That is, a method is adopted in which the default value is “0” (masking = implying search impossible) and the corresponding bit is set to “1” only when reproduction is possible. However, conversely, a method may be adopted in which the default value is set to “1” and the corresponding bit is set to “0” only when reproduction is impossible.
[0071]
Further, instead of setting the default value of the mask data in the karaoke apparatuses 1a and 1b as in S320 of FIG. 7, the karaoke apparatuses 1a and 1b receive the mask data in which the default values are set in advance from the host. May be.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a schematic configuration of a karaoke system according to an embodiment.
FIG. 2 is an explanatory diagram showing an application example of mask data to request music data;
FIG. 3 is an explanatory diagram of an appearance of a request device and display contents on a liquid crystal display unit.
FIG. 4 is a flowchart showing processing relating to a request executed by the request device.
5A is an explanatory diagram of request music data, and FIG. 5B is an explanatory diagram of mask data;
FIG. 6 is a flowchart showing processing relating to acquisition / update of mask data executed by the requesting device.
FIG. 7 is a flowchart showing processing relating to reception of an additional song executed by the karaoke apparatus.
FIG. 8 is a flowchart showing processing related to karaoke performance executed by the karaoke apparatus.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 1a ... 1st karaoke apparatus, 1b ... 2nd karaoke apparatus, 9 ... Image | video reproduction apparatus, 10 ... CPU, 11 ... Hard disk, 12 ... Modem, 13 ... Playback apparatus, 14 ... Remote control light-receiving part, 15 ... Wireless communication apparatus 16 ... Microphone, 17 ... Amplifier, 18 ... Speaker, 19 ... CRT, 20 ... CPU, 21 ... Wireless communication device, 22 ... Remote control light emitting unit, 23 ... Liquid crystal display unit, 24 ... Input device, 25 ... SRAM, 26 ... Power, 27 ... Power switch.

Claims

An information providing apparatus that stores a plurality of provision information and request information corresponding to the information, receives the request information from the outside, and performs information provision using the provision information according to the request information,
A request device having a search database for searching for the request information, searching the search database based on an operation received from a user, and transmitting request information as a search result to the information providing device A request response type information providing system comprising:
The information providing apparatus includes:
Mask data for discriminating request information corresponding to providing information that can be provided by the information providing device and other request information from among the request information existing in the search database of the requesting device. Send to
The request device is:
The received mask data is received and stored from the information providing apparatus, and the stored mask data is effectively handled as a search result only for request information corresponding to the information for provision that can be provided by the information providing apparatus. Request-based information provision system that uses and adjusts.

In the request corresponding | compatible information provision system of Claim 1,
The request device includes:
Of the request information in the search database, only the request information corresponding to the providing information that can be provided by the information providing device is searched for using the mask data, and the other request information is excluded from the searching target. A request-based information provision system that executes search.

In the request corresponding | compatible information provision system of Claim 1,
The request device is:
Providing display means for displaying a search result, and providing the information provided by the information providing device among the search results of the search database using the mask data when displaying the search result on the display means A request-supporting information providing system that displays only the request information corresponding to the business information, and does not display otherwise.

In the request corresponding | compatible information provision system in any one of Claims 1-3, the said request apparatus requests | requires transmission of the said mask data with respect to the said information provision apparatus at predetermined timing,
The information providing apparatus transmits the mask data to the request apparatus in response to a transmission request from the request apparatus,
A request corresponding information providing system in which the request device receives and stores the transmitted mask data.

In the request corresponding | compatible information provision system of Claim 4,
The request device has a power switch for turning on / off the power of the request device itself. When the power switch is turned on, or at a timing at least every predetermined time after the power is turned on. A request-based information provision system that requests transmission of mask data.

The request corresponding information providing system according to any one of claims 1 to 3, wherein the information providing device transmits the mask data to the request device at a predetermined timing.
A request corresponding information providing system in which the request device receives and stores the transmitted mask data.

In the request corresponding | compatible information provision system of Claim 6,
The information providing apparatus includes a power switch for turning on / off the power of the information providing apparatus itself, and at least one timing when the power switch is turned on or every predetermined time after the power is turned on. The request corresponding type information providing system for transmitting the mask data to the requesting device.

In the request corresponding | compatible information provision system in any one of Claims 1-7, whenever the content of the said mask data is updated, the said information provision apparatus changes the value of predetermined identification information uniquely, The said Adding identification information to the mask data and sending it to the requesting device;
The request device that has received the transmitted mask data compares the identification information added to the previous mask data with the identification information added to the mask data received this time, and updates only when both are different. A request-based information provision system that memorizes.

In the request corresponding | compatible information provision system of Claim 8,
The information providing apparatus is set to distinguish between models according to the content of the information for providing information, and transmits the model information for distinguishing between the models to the request apparatus by adding to the mask data. ,
The request device that has received the transmitted mask data compares the model information added to the previous mask data and the model information added to the mask data received this time, and if both are different, the update storage is performed. Request-response information provision system.

A request device used in the request-compatible information providing system according to any one of claims 1 to 9,
A requesting device comprising the configuration described in the claims for the requesting device.