(57)【要約】【課題】リクエスト装置が有する検索用データベース更新のための通信が必要ある場合のみ、情報提供装置とリクエスト装置との間での実質的なデータ通信を行う。【解決手段】カラオケ装置のハードディスク内のリクエスト用楽曲データ受信フラグ格納領域におけるリクエスト用楽曲データ受信フラグがオンであれば（Ｓ１２０：ＹＥＳ）、通信済みリクエスト装置管理テーブルの初期化を行う（Ｓ１３０）。そして、通信可能なリクエスト装置があれば（Ｓ１５０：ＹＥＳ）、そのリクエスト装置の識別情報が上記管理テーブルに登録済みか否か判断し（Ｓ１６０）、登録済みでない場合は（Ｓ１６０：ＮＯ）、リクエスト用楽曲データを、前記応答のあったリクエスト装置へ送信し（Ｓ１７０）、そのリクエスト装置は上記管理テーブルに登録される（Ｓ１９０）。【選択図】図４
2004184766.tif 000002
【特許請求の範囲】
【請求項１】
複数の提供情報を記憶しておくための記憶手段を有し、外部からその提供情報と対応するリクエスト情報を受信すると、そのリクエスト情報に応じた提供情報を用いて情報提供を実行する情報提供装置、
前記リクエスト情報を検索するための検索用データベースを有し、ユーザから受け付けた操作に基づき前記検索用データベースの検索を行い、その検索結果としてのリクエスト情報を前記情報提供装置に対して送信する、１以上のリクエスト装置、
前記情報提供装置と通信可能、且つ、前記リクエスト装置を挿抜可能に保持すると共にその保持したリクエスト装置と通信可能に構成され、前記情報提供装置と前記リクエスト装置との間での通信を中継するクレードル、
を備えるリクエスト対応型情報提供システムであって、
前記情報提供装置の前記記憶手段には、前記リクエスト装置毎に前記検索用データベース更新のための通信が必要あるか否かを設定可能な管理テーブルが記憶されており、
前記情報提供装置は、
前記記憶手段に新たな検索用データベースが追加された場合、前記管理テーブルにおいて、全てのリクエスト装置に対してデータベース更新のための通信が必要ありと設定する通信必要設定手段、
前記クレードルを介して通信可能な前記リクエスト装置が存在するか否かを判断する存在有無判断手段、
前記存在有無判断手段によって前記リクエスト装置が存在すると判断された場合、その判断対象のリクエスト装置について前記検索用データベース更新のための通信が必要あるか否かを前記管理テーブルを参照して判断する通信有無判断手段、
前記通信有無判断手段によって前記検索用データベース更新のための通信が必要あると判断された場合は、前記記憶手段に追加された新たな検索用データベースを前記リクエスト装置へ送信する送信手段、
前記送信手段によって新たな検索用データベースを前記リクエスト装置へ送信した場合、前記管理テーブルにおいて、前記新たな検索用データベースを送信したリクエスト装置に関してデータベース更新のための通信が必要なしと設定する通信不要設定手段、
を有し、
一方、前記情報提供装置から送信された前記新たな検索用データベースを受信した前記リクエスト装置は、その受信した新たな検索用データベースを前記検索用データベースに更新記憶する
リクエスト対応型情報提供システム。
【請求項２】
複数の提供情報を記憶しておくための記憶手段を有し、外部からその提供情報と対応するリクエスト情報を受信すると、そのリクエスト情報に応じた提供情報を用いて情報提供を実行する情報提供装置、
前記リクエスト情報を検索するための検索用データベースを有し、ユーザから受け付けた操作に基づき前記検索用データベースの検索を行い、その検索結果としてのリクエスト情報を前記情報提供装置に対して送信する、１以上のリクエスト装置、
前記情報提供装置と通信可能、且つ、前記リクエスト装置を挿抜可能に保持すると共にその保持したリクエスト装置と通信可能に構成され、前記情報提供装置と前記リクエスト装置との間での通信を中継するクレードル、
を備えるリクエスト対応型情報提供システムであって、
前記情報提供装置の前記記憶手段には、前記リクエスト装置毎に前記検索用データベース更新のための通信が必要あるか否かを設定可能な管理テーブルが記憶されており、
前記情報提供装置は、
所定の時間間隔をおいて設定された所定時刻になった場合、前記管理テーブルにおいて、全てのリクエスト装置に対してデータベース更新の必要ありと設定する通信必要設定手段、
前記クレードルを介して通信可能な前記リクエスト装置が存在するか否かを判断する存在有無判断手段、
前記存在有無判断手段によって前記リクエスト装置が存在すると判断された場合、その判断対象のリクエスト装置について前記検索用データベース更新のための通信が必要あるか否かを前記管理テーブルを参照して判断する通信有無判断手段、
前記通信有無判断手段によって前記検索用データベース更新のための通信が必要あると判断された場合は、前記記憶手段に追加された新たな検索用データベースを前記リクエスト装置へ送信する送信手段、
前記送信手段によって新たな検索用データベースを前記リクエスト装置へ送信した場合、前記管理テーブルにおいて、前記新たな検索用データベースを送信したリクエスト装置に関してデータベース更新のための通信が必要なしと設定する通信不要設定手段、
を有し、
一方、前記情報提供装置から送信された前記新たな検索用データベースを受信した前記リクエスト装置は、その受信した新たな検索用データベースを前記検索用データベースに更新記憶する
リクエスト対応型情報提供システム。
【請求項３】
請求項２に記載のリクエスト対応型情報提供システムにおいて、
前記情報提供装置又は前記リクエスト装置の少なくともいずれか一方に、ユーザから受け付けた操作に基づいて緊急通信要求を発生させる緊急通信要求発生手段を備え、
前記情報提供装置の前記送信手段は、緊急通信要求発生手段から緊急通信要求が発生した場合は、前記通信有無判断手段による判断結果には関係なく、前記記憶手段に記憶された検索用データベースを前記リクエスト装置へ送信する
リクエスト対応型情報提供システム。
【請求項４】
請求項３に記載のリクエスト対応型情報提供システムにおいて、
前記緊急通信要求発生手段は、通常ユーザが行う操作ではありえない特殊な操作を受け付けた場合に、前記緊急通信要求を発生させる
リクエスト対応型情報提供システム。
【請求項５】
請求項１〜４の何れかに記載のリクエスト対応型情報提供システムにおいて、
前記情報提供装置は、
外部の配信ホストから前記新たな検索用データベースの配信を受けることができるよう構成されており、
前記外部の配信ホストから前記検索用データベースの配信を受けた場合に、その配信を受けた検索用データベースを、前記記憶手段に新たな検索用データベースとして追加する
リクエスト対応型情報提供システム。
【請求項６】
請求項１〜５の何れかに記載のリクエスト対応型情報提供システムに用いられる情報提供装置であって、
当該各請求項において情報提供装置に関して記載された構成を備える情報提供装置。
【請求項７】
請求項４に記載のリクエスト対応型情報提供システムに用いられるリクエスト装置であって、
当該請求項においてリクエスト装置に関して記載された構成を備えるリクエスト装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、受信したリクエスト情報に応じた提供情報を用いて情報提供を実行する情報提供装置と、リクエスト情報を検索するための検索用データベースを有し、ユーザから受け付けた操作に基づき検索した結果としてのリクエスト情報を情報提供装置に対して送信するリクエスト装置を備えるリクエスト対応型情報提供システム等に関する。
【０００２】
【従来の技術】
従来、例えば楽曲を再生するカラオケ装置と、そのカラオケ装置に所定の楽曲を再生させるための動作指令を送信する遠隔操作装置を備えたカラオケシステムが知られている。このカラオケシステムにおいては、カラオケ装置に対して利用者が希望の曲をリクエストする際、例えば曲名や歌手名などのキーデータと、リクエストに利用するたとえば数桁の英数字などからなるリクエストコードが組となって記載されているリクエスト用の冊子（いわゆる早見本）を参照して、所望の曲に対応するキーデータからリクエストコードを検索した上で、そのリクエストコードをリクエスト装置に入力することによってリクエストを実現していた。
【０００３】
一方、昨今の通信インフラなどデータ配信技術の向上により、冊子の配本スピードがカラオケ曲の追加／更新のスピードに対して相対的に低下してしまう傾向にある。そのため、リクエスト装置内に検索用データベースを保持することによって、前記キーデータによる検索機能を実現し、利用者は所望の曲に対応するキーデータをリクエスト装置に入力することによって、該当する曲を検索し、その後、その中から希望する曲を利用者（歌唱者）が選択し、リクエストを実現するカラオケシステムも開発されている。
【０００４】
そして、このようなカラオケシステムにおいては、カラオケ装置がホスト装置から新曲の配信を受けた場合には、その新曲についてもリクエストできるようにするため、その新曲検索用の追加レコードをカラオケ装置からリクエスト装置に送信して、リクエスト装置内の検索用データベースを更新するようにしている。この検索用データベースの更新を迅速に行う工夫として、例えばカラオケ装置に接続された充電器にリクエスト装置が挿入される度に、リクエスト装置が検索用データベースの記憶状態を示す状態データをカラオケ装置へ通知し、カラオケ装置ではその通知された状態データに基づいてデータ更新の必要性があるか否かを判断する方法が提案されている（例えば、特許文献１参照）。
【０００５】
【特許文献１】
特許第３０８９５２９号公報（第２〜第３頁）
【０００６】
【発明が解決しようとする課題】
しかしながら、このように充電器にリクエスト装置が挿入される度にカラオケ装置側でデータ更新の必要性があるか否かを判断する手法であると、次のような不都合が生じる。つまり、カラオケ装置は、充電器にリクエスト装置が挿入される度に、実際にはデータ更新の必要性がなくても機械的にリクエスト装置から検索用データベースの現在の記憶状態を示す状態データを通知してもらい、データ更新の必要性の有無を判断してしまうこととなる。
【０００７】
したがって、頻繁に挿入されると、実際には必要がないにもかかわらず、カラオケ装置とリクエスト装置間でのデータ通信を伴う処理が発生し、処理負荷が増えてしまう。リクエスト装置が充電器に挿入されたとしてもカラオケ装置側でカラオケ演奏等の各種処理を実行していないというわけではない。例えばユーザがリクエスト装置を用いてリクエスト操作をした後、リクエスト装置の置き場として充電器に挿入することもよくあることである。つまり、充電器がいわゆるクレードルの役割もするのである。したがって、上述した従来技術の場合には、リクエスト装置を充電器に挿入した場合にカラオケ装置側でカラオケ演奏を実行している最中であれば、そのカラオケ演奏処理の間に、上述した実際には必要のないデータ更新有無の必要性の確認処理をしなくてはならないこととなる。情報提供装置においては本来的な機能として情報提供に係る処理を優先して実行すべきであるため、このようないわば無用な処理は極力避けたいものである。
【０００８】
なお、このような問題は、カラオケシステムには限らず、リクエスト情報を検索するための検索用データベースを有し、ユーザから受け付けた操作に基づき検索した結果としてのリクエスト情報を情報提供装置に対して送信し、その受信したリクエスト情報に応じた提供情報を用いて情報提供を実行する情報提供装置とからなるリクエスト対応型情報提供システムであって、検索用データベースの更新が必要となるシステムであれば同様に発生する。
【０００９】
そこで本発明は、このようなシステムにおいて、リクエスト装置が有する検索用データベース更新のための通信が必要ある場合のみ、情報提供装置とリクエスト装置との間での実質的なデータ通信を行うようにして、特に情報提供装置側の処理負荷を低減することを目的とする。
【００１０】
【課題を解決するための手段及び発明の効果】
（１）請求項１に係るリクエスト対応型情報提供システムは、情報提供装置、１以上のリクエスト装置、クレードルを備えている。クレードルは、情報提供装置と通信可能、且つ、リクエスト装置を挿抜可能に保持すると共にその保持したリクエスト装置と通信可能に構成され、情報提供装置とリクエスト装置との間での通信を中継する機能を有する。また、リクエスト装置は、リクエスト情報を検索するための検索用データベースを有し、ユーザから受け付けた操作に基づき前記検索用データベースの検索を行い、その検索結果としてのリクエスト情報を情報提供装置に対して送信する。情報提供装置は、記憶手段に複数の提供情報を記憶しており、リクエスト装置からリクエスト情報を受信すると、そのリクエスト情報に応じた提供情報を用いて情報提供を実行する。
【００１１】
そして、本システムでは、リクエスト装置の検索用データベースの更新を次のようにして行う。まず、情報提供装置の記憶手段には、リクエスト装置毎に検索用データベース更新のための通信が必要あるか否かを設定可能な管理テーブルが記憶されており、情報提供装置は、記憶手段に新たな検索用データベースが追加された場合、管理テーブルにおいて、全てのリクエスト装置に対してデータベース更新の必要ありと設定する。そして、クレードルを介して通信可能なリクエスト装置が存在するか否かを判断する。リクエスト装置が存在する場合、その判断対象のリクエスト装置について検索用データベース更新のための通信が必要あるか否かを管理テーブルを参照して判断し、更新のための通信が必要ありと判断された場合は、記憶手段に追加された新たな検索用データベースをリクエスト装置へ送信する。このように情報提供装置から送信された新たな検索用データベースを受信したリクエスト装置は、その受信した新たな検索用データベースを検索用データベースに更新記憶する。一方、情報提供装置では、上述したように新たな検索用データベースをリクエスト装置へ送信した場合、管理テーブルにおいて、新たな検索用データベースを送信したリクエスト装置に関してデータベース更新の必要なしと設定する。
【００１２】
したがって、リクエスト装置が有する検索用データベース更新のための通信が必要ある場合のみ、情報提供装置とリクエスト装置との間での実質的なデータ通信を行うこととなり、特に、情報提供装置側の処理負荷を低減する上で有効である。
【００１３】
なお、例えばリクエスト装置が複数存在し、情報提供装置の通信有無判断手段が、判断対象のリクエスト装置について検索用データベース更新のための通信が必要あるか否かの判断に際してリクエスト装置から識別情報を取得する実施形態を採用したとしても、従来手法のようなリクエスト装置の検索用データベースの記憶状態を示すデータを通知してもらう、といった実質的なデータ通信を行っているものではない。したがって、やはり情報提供装置側の処理負荷を低減する上で有効である。
【００１４】
（２）請求項１に係る発明システムの場合は、通信必要設定手段が管理テーブルにおいて全てのリクエスト装置に対してデータベース更新のための通信が必要ありと設定するタイミングを、例えば通信カラオケシステムで言えば配信ホストからカラオケ装置へ新曲の配信があったときなど、記憶手段に新たな検索用データベースが追加された場合とした。これに対して、請求項２に係る発明システムの場合は、通信必要設定手段が管理テーブルにおいて全てのリクエスト装置に対してデータベース更新のための通信が必要ありと設定するタイミングとして、所定の時間間隔をおいて設定された所定時刻を採用した。例えば通信カラオケシステムで言えば、配信ホストからカラオケ装置への新曲配信が例えば１日に１回ペースであれば、その配信間隔に合わせ、１日１回所定時刻になったときに、管理テーブルにおいて全てのリクエスト装置に対してデータベース更新のための通信が必要ありと設定するのである。
【００１５】
このようにして管理テーブルでの更新のための通信が必要あり・なしを設定することで、情報提供装置の記憶手段に新たな検索用データベースが追加された後、所定時刻になった以降、そのリクエスト情報を送信したリクエスト装置については、管理テーブルにて更新のための通信が必要なしと設定されるため、その管理テーブルの設定内容を参照するだけで新たな検索用データベースの送信の必要性を判断できる。したがって、請求項１に係る発明システムの場合と同様、情報提供装置側において、リクエスト装置から検索用データベースの記憶状態を示すデータを通知してもらう必要は全くなく、自己（つまり情報提供装置）が記憶している管理テーブルの設定内容のみに基づいて必要性を判断できる。そのため、リクエスト装置が有する検索用データベース更新のための通信が必要ある場合のみ、情報提供装置とリクエスト装置との間での実質的なデータ通信を行うこととなり、特に情報提供装置側の処理負荷を低減する上で有効である。
【００１６】
但し、この請求項２に係る発明システムの場合は、請求項１に係る発明システムの場合と違って、例えば、所定時刻になったことをトリガとして、その後にリクエスト装置への新たな検索用データベースの送信（及びリクエスト装置での更新記憶）がなされた直後に情報提供装置の記憶手段に新たな検索用データベースが追加された場合には、直近に追加された新たな検索用データベースのリクエスト装置への送信（及びリクエスト装置での更新記憶）が遅れてしまう可能性がある。例えば１日に１回新たな検索用データベースが追加される場合を想定すると、丸一日程度もリクエスト装置における検索用データベースの更新がされないこととなる。例えば通信カラオケシステムでの新曲配信を想定した場合、配信ホストからカラオケ装置（情報提供装置としての一例に相当する）へのデータ配信が例えば毎日１時頃に実行されるとして、所定時刻を例えばその１時間後の２時頃にしておけば問題はない。しかし、新曲の配信が必ず１時に実行されるとは限らないため、場合によっては上述のようなケースも生じる。
【００１７】
そこで、そのような場合の対処として、人がマニュアルでリクエスト装置又は情報提供装置を操作することによって、所定時刻以外であっても強制的に、情報提供装置からリクエスト装置へ新たな検索用データベースを送信できるようにしてもよい。例えば請求項３に示すように、情報提供装置又はリクエスト装置の少なくともいずれか一方に、ユーザから受け付けた操作に基づいて緊急通信要求を発生させる緊急通信要求発生手段を備え、緊急通信要求が発生した場合、情報提供装置は、通信有無判断手段による判断結果には関係なく、記憶手段に記憶された検索用データベースを前記リクエスト装置へ送信するのである。
【００１８】
なお、緊急通信要求発生手段に関しては、例えば請求項４に示すように、通常ユーザが行う操作ではありえない特殊な操作を受け付けた場合に、緊急通信要求を発生させるよう構成することが考えられる。例えばリクエスト装置がテンキーなど複数の操作子を備えていたとしても、リクエストに際しては通常同時に複数の操作子を操作することはない。したがって、例えば所定の２つの操作子を同時に操作することで、緊急通信要求を発生させるようにすれば、緊急通信要求のためだけに特別な操作子を設ける必要はなくなる。もちろん、緊急通信要求のためだけに特別な操作子を設けることを排除する意図ではない。
【００１９】
（３）ここで、「所定の時間間隔をおいて設定された所定時刻」について補足説明する。この所定時刻の設定に際して考慮するものとしては、例えば記憶手段に新たな検索用データベースが追加されるタイミングやあるいは情報提供装置の稼働しているタイミングが考えられる。
【００２０】
前者のタイミングを考慮した例を考える。上述した通信カラオケシステムの例のように、１日に１回新たな検索用データベースが追加されるようなシステムであれば、１日１回だけ所定時刻を設定すればよい。また、例えば１日に２回新たな検索用データベースが追加されるようなシステムであれば、１日２回所定時刻を設定すればよい。また、１日に２回といった場合、それがおよそ１２時間おきであることが分かっているか、あるいは不定期であれば例えば所定時刻も１２時間間隔で設定すればよい。また、例えば午前０時と午後６時というようにおよその予定時刻が定まっている場合には、それに合わせ、例えば午前１時と午後７時を所定時刻にする、といったことが考えられる。もちろん、１日に１回新たな検索用データベースが追加されるようなシステムであっても、例えば２日１回だけ更新するように所定時刻を設定してもよい。
【００２１】
このような観点からすれば、特に請求項５に示すように、情報提供装置が外部の配信ホストから新たな検索用データベースの配信を受けることができるよう構成されており、外部の配信ホストから前記検索用データベースの配信を受けた場合に、その配信を受けた検索用データベースを、記憶手段に新たな検索用データベースとして追加するシステムの場合には、非常に有効な対処となる。その一例が上述の通信カラオケシステムである。
【００２２】
一方、後者のタイミングを考慮した例としては、例えば上述した通信カラオケシステムを営業に用いる場合、カラオケ店の営業時間外の所定時刻を設定することが考えられる。
（４）なお、請求項６に示すように、請求項１〜５の何れかに記載のリクエスト対応型情報提供システムに用いられる情報提供装置であって、当該各請求項において情報提供装置に関して記載された構成を備える情報提供装置として実現することもできる。また、請求項７に示すように、請求項４に記載のリクエスト対応型情報提供システムに用いられるリクエスト装置であって、当該請求項においてリクエスト装置に関して記載された構成を備えるリクエスト装置として実現することもできる。このような情報提供装置やリクエスト装置であれば、上述したリクエスト対応型情報提供システムに用いられることによって、上述の効果を発揮する上で有意な役割を果たすこととなる。
【００２３】
【発明の実施の形態】
以下、本発明が適用された実施例について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り種々の形態を採りうることは言うまでもない。
【００２４】
［第１実施例］
図１は、本発明のリクエスト対応型情報提供システムの一実施例としてのカラオケシステムの構成を示すブロック図である。本実施例のカラオケシステムは、カラオケ装置１とリクエスト装置２、そして、カラオケ装置１と通信可能、且つリクエスト装置２を挿抜可能に保持すると共にその保持したリクエスト装置２と通信可能に構成され、カラオケ装置１とリクエスト装置２との間での通信を中継するクレードル３とから構成される。なお、図１では、１台のリクエスト装置２しか示していないが、１台のクレードル３が２台のリクエスト装置２を保持可能になっていてもよい。また、そのような２台のリクエスト装置２を保持可能なクレードル３同士を接続（カスケード接続）して、１台のカラオケ装置１に対して４台以上のリクエスト装置２を準備することも可能である。
【００２５】
（カラオケ装置１の構成）
カラオケ装置１は、図１に示されるように、図示しないホストコンピュータに公衆回線などの通信ネットワークを介して接続し各種の情報を送受信するモデム１２、カラオケ装置１全体の制御を司るＣＰＵ１０、現在日時を取得するためのタイマ８、カラオケ用の音楽情報や画像情報その他各種データを記憶しているハードディスク１１、演奏の再生を行う再生装置１３、音楽情報にかかる電気信号を増幅等するアンプ１７、アンプ１７からの電気信号を入力して伴奏曲及び利用者の歌声等を流すスピーカ１８、利用者の歌声等をアンプ１７に入力するためのマイクロフォン（以下、単にマイクと称す。）１６、ハードディスク１１に記憶された画像情報に基づいて映像情報である背景画及び歌詞等を再生する映像再生装置９、再生された映像を表示するＣＲＴ１９、リクエスト装置２から発光される赤外線等によるリモコン信号を受光するリモコン受光部１４及びクレードル３を介してリクエスト装置２と双方向通信するための通信Ｉ／Ｆ１５を備えている。この内、タイマ８、ハードディスク（ＨＤＤ）１１、モデム１２、再生装置１３、リモコン受光部１４、通信Ｉ／Ｆ１５及び映像再生装置９はＣＰＵ１４に接続されている。
【００２６】
上述したモデム１２は、信号の変調および復調を行う変復調装置であり、ＣＰＵ１０の制御の下、公衆回線を通じてホストコンピュータにアクセス可能に構成されている。それによって、モデム１２は公衆回線を介してホストコンピュータから送られてくる演奏曲データの追加分（新曲のデータ等）を受信したり、その演奏曲データと同じくして配信されるリクエスト用楽曲データを受信する。
【００２７】
ここで受信された演奏曲データ、リクエスト用楽曲データはハードディスク１１にファイルとして記憶される。そして、演奏曲データはカラオケ演奏時に利用者（歌唱者）により入力された選曲番号に対応するものが読み出され演奏処理に用いられ、リクエスト用楽曲データは通信Ｉ／Ｆ１５を通じてクレードル３へ送信され、クレードル３からリクエスト装置２へ送信される。前記リクエスト用楽曲データは、リクエスト情報としての選曲番号、検索キー情報としての曲名、その曲を歌う歌手名、リリース年月日、ジャンルなどから構成され、前記各演奏曲データと対応している。従って、複数のリクエスト用楽曲データによって、リクエスト用楽曲データベースが構成される。
【００２８】
例えばカラオケ演奏処理では、ＣＰＵ１０から出力される演奏曲データは再生装置１３においてアナログの演奏音信号に変換された後、アンプ１７へ送られて電気的に増幅される。このアンプ１７は、マイク１６を介して入力される利用者（歌唱者）の歌唱音信号と適度な割合でミキシングするもので、ミキシングされた歌唱音信号と演奏音信号は、アンプ１７からスピーカ１８に出力され、音声及び演奏音となってスピーカ１８から外部へ出力される。一方、映像再生装置９は、ＣＰＵ１４の制御の下、ハードディスク１１から読み出された画像情報に基いて歌詞や背景画を再生してＣＲＴ１９に出力し、ＣＲＴ１９はそれらの表示を行うものである。それにより、ＣＲＴ１９においては、歌詞データが映像データと合成されて背景映像とともに歌詞テロップが表示されるようになっている。このような構成のため、利用者は、ＣＲＴ１９に表示される歌詞テロップを参照しながら、スピーカ１８より流れるカラオケ演奏にあわせ、マイク１６を使って歌唱できるようになっている。
【００２９】
一方、リクエスト用楽曲データが記憶されるハードディスク１１には、リクエスト用楽曲データのファイル群を格納する領域１１ａに加え、通信済みリクエスト装置管理テーブル１１ｂ及びリクエスト用楽曲データフラグ格納領域１１ｃが準備されている。通信済みリクエスト装置管理テーブル１１ｂは、更新すべき新たなリクエスト用楽曲データの送信が完了した場合には当該リクエスト装置２の識別情報（ＩＤ）を登録するためのテーブルである。また、リクエスト用楽曲データフラグ格納領域１１ｃは、更新すべきリクエスト用楽曲データの存在を示すフラグを格納するためのものであり、公衆回線を通じてホストコンピュータから新たなリクエスト用楽曲データを受信した場合にオンにされる。なお、ホストコンピュータからの新たなリクエスト用楽曲データの送信は、演奏曲データの追加送信と同じタイミングであってもよいし、別のタイミングであってもよい。
【００３０】
なお、クレードル３とカラオケ装置１とはハーネスによって接続される。具体的には、そのハーネスの一端が前記通信Ｉ／Ｆ１５に設けられたコネクタに接続され、他端はクレードル３の図示しないコネクタに接続される。
（リクエスト装置２の構成）
一方、リクエスト装置２は、カラオケボックスの各室に設置されたカラオケ装置１に対応して各室毎に１台もしくは複数台配置されている。また、図１に示すように、リクエスト装置２全体の制御を司るＣＰＵ２０、カラオケ装置１とクレードル３を介して双方向通信するための通信Ｉ／Ｆ２１、カラオケ装置１に対して赤外線等によるリモコン信号を発光するリモコン発光部２２、表示装置としての液晶表示部２３、入力手段としての入力装置２４、ＳＲＡＭ２５及び電源２６を備えている。なお、電源２６が例えばニッカドなどの二次電池を備える場合、クレードル３を介して充電できるようにされていてもよい。その場合は、クレードル３側にも充電用のコネクタが準備され、カラオケ装置１とクレードル３を接続するハーネス内にも電源線が含まれている。
【００３１】
なお、クレードル３は、リクエスト装置２と双方向通信するための通信Ｉ／Ｆを備えている。本実施例では、リクエスト装置２とクレードル３との間でＩｒＤＡ（Ｉｎｆｒａｒｅｄ  Ｄａｔａ  Ａｓｓｏｃｉａｔｉｏｎ）を用いた光通信を行うものとし、リクエスト装置２の通信Ｉ／Ｆ２１及びクレードル３の通信Ｉ／Ｆともに、それに対応した構成とされている。
【００３２】
リクエスト装置２は、クレードル３及び通信Ｉ／Ｆ２１を介してカラオケ装置１から受信したリクエスト用楽曲データを受信し、これを記憶手段としてのＳＲＡＭ２５にファイル（検索用データベース）として記憶する。このリクエスト用楽曲データは、各演奏曲データと対応する選曲番号、曲名、その曲を歌った歌手名、その曲が属するジャンル情報、その曲のリリース年月日などが対になったものであり、例えばカラオケ装置１において例えば１万曲のカラオケ曲の再生が可能であるならば、その１万曲分のリクエスト用楽曲データが存在する。これが「検索用データベース」を構成することとなる。ここで、ＳＲＡＭ２５は、電源遮断時にも記録された情報を保持可能なメモリである。
【００３３】
また、入力装置２４は、利用者によって操作されるものであり、任意の曲の選択、演奏音のキーの調整、演奏と歌との音量バランスの調整、その他エコー、音量、トーンなど各種調整を行うためのものであり、この入力装置２４が操作されることによって入力あるいは選択された曲番号や曲名等は液晶表示部２３に表示される。入力装置２４は、リクエスト装置２の表側の中央にテンキーが設けられており、その他にも選択キーや各種機能キーが設けられている。そして、設けられたテンキーを用いて数字を入力することもできるし、文字を入力することもできる。文字入力は、例えば曲名や歌手名の頭に付く文字で検索する場合などに利用される。この文字入力に関しては、例えば現在一般に見られる携帯電話での文字入力方法に倣ったものとすることが考えられる。これによって検索すべき曲名を入力することができる。
【００３４】
このようにリクエスト曲が確定すると、ＣＰＵ２０はリモコン発光部２２を通じて、選択された曲名に対応する曲の選曲番号（選曲情報）を赤外線信号として送信する。カラオケ装置１は、リモコン受光部１４にてその赤外線信号を受信すると、受信信号から解析した選曲番号に応じたカラオケ曲の演奏を行う。なお、リクエスト装置２では、電源２６からＣＰＵ２０、通信Ｉ／Ｆ２１、リモコン発光部２２、液晶表示部２３、ＳＲＡＭ２５等に電力が供給される。
【００３５】
（リクエスト用楽曲データの更新に関する処理）
図３は、ホストコンピュータから配信されるデータの受信時にカラオケ装置１にて実行される処理を示すフローチャートである。
例えば新曲の演奏曲データ及びそれに対応するリクエスト用楽曲データの配信は１日に１回、公衆回線にて接続される図示しないホストとモデム１２（図１参照）を介して通信し、新曲の演奏曲データ及びそれに対応するリクエスト用楽曲データがあればホストから配信を受けるようになっている。
【００３６】
図３の最初のステップＳ１０において公衆回線から配信データを受信してハードディスク１１に格納すると、次に、その受信したデータがリクエスト用楽曲データか否かを判断する（Ｓ２０）。そして、リクエスト用楽曲データであれば（Ｓ２０：ＹＥＳ）、図２に示すように、ハードディスク１１内の所定領域、つまりリクエスト用楽曲データのファイル群を格納する領域１１ａに格納すると共に、リクエスト用楽曲データ受信フラグ格納領域１１ｃの受信フラグをオンにする（Ｓ３０）。一方、受信したデータがリクエスト用楽曲データでなければ（Ｓ２０：ＮＯ）、その他の処理を実行する（Ｓ４０）。この「その他の処理」とは、例えば受信したデータ種類に応じて適宜所定領域に格納する処理などであり、例えば演奏曲データは、ステップＳ２０の判断では「ＮＯ」となる。
【００３７】
図４は、カラオケ装置１にて実行される、リクエスト装置２へのリクエスト用楽曲データの送信に関する処理を示すフローチャートである。
カラオケ装置１が例えばカラオケボックス等に設置され、それによりカラオケ装置１に電源供給がなされて本処理ルーチンが開始すると、まず、ハードディスク１１内の通信済みリクエスト装置管理テーブル１１ｂ（図２参照）の初期化を行う（Ｓ１１０）。
【００３８】
次に、ハードディスク１１内のリクエスト用楽曲データ受信フラグ格納領域１１ｃ（図２参照）におけるリクエスト用楽曲データ受信フラグがオンであるか否かを判断する（Ｓ１２０）。上述したようにリクエスト用楽曲データを受信すると、Ｓ３０（図３）において受信フラグがオンとされるので、この受信フラグがオンとなると（Ｓ１２０：ＹＥＳ）、更新すべきリクエスト用楽曲データが存在するため、通信済みリクエスト装置管理テーブル１１ｂ（図２参照）の初期化を行うと共に、リクエスト用楽曲データ受信フラグをオフとする（Ｓ１３０）。通信済みリクエスト装置管理テーブル１１ｂが初期化された場合、当該管理テーブルにはリクエスト装置識別情報が何ら登録されていないため、全てのリクエスト装置２が更新対象となる。なお、カラオケ装置１が設置されたばかりのときは、受信フラグはオフの状態であるので、ステップＳ１２０の判断は、「ＮＯ」となる。
【００３９】
そして、通信可能なリクエスト装置２を探索する（Ｓ１４０）。具体的には、通信Ｉ／Ｆ１５を介してクレードル３に挿入されたリクエスト装置２に対して通信要求を送信し、その要求に対するリクエスト装置２からの応答を待つ。そして、例えば所定時間内に何らリクエスト装置２からの応答がなければ（Ｓ１５０：ＮＯ）、Ｓ１２０へ戻るが、リクエスト装置２からの応答があれば（Ｓ１５０：ＹＥＳ）、そのリクエスト装置２の識別情報が、ハードディスク１１内の通信済みリクエスト装置管理テーブル１１ｂに登録済みか否か判断する（Ｓ１６０）。リクエスト装置２は、カラオケ装置１からの通信要求に対し、自己の識別情報（リクエスト装置識別情報）を含めて応答する。このリクエスト装置識別情報が通信済みリクエスト装置管理テーブル１１ｂに登録済みの場合は（Ｓ１６０：ＹＥＳ）、既に更新すべきリクエスト用楽曲データを送信しているため、Ｓ１２０へ戻る。なお、カラオケ装置１が設置されたばかりで新たなリクエスト用楽曲データの配信を受けていないときは、リクエスト装置２にリクエスト用楽曲データを送ることなく、通信済みリクエスト装置管理テーブル１１ｂにリクエスト装置識別情報のみを登録する。
【００４０】
一方、リクエスト装置識別情報が通信済みリクエスト装置管理テーブル１１ｂに登録済みでない場合は（Ｓ１６０：ＮＯ）、リクエスト用楽曲データを、前記応答のあったリクエスト装置２へ送信する（Ｓ１７０）。このリクエスト用楽曲データは、通信Ｉ／Ｆ１５、クレードル３を介してリクエスト装置２へ送信される。リクエスト装置２は、通信Ｉ／Ｆ２１を介してこのリクエスト用楽曲データを受信し、ＳＲＡＭ２５へ格納する
このようなリクエスト用楽曲データの送信処理が正常に終了した場合には（Ｓ１８０：ＹＥＳ）、前記応答のあったリクエスト装置２のリクエスト装置識別情報を通信済みリクエスト装置管理テーブル１１ｂに登録し（Ｓ１９０）、Ｓ１２０へ戻る。また、正常終了しなかった場合は）Ｓ１８０：ＹＥＳ）、そのままＳ１２０へ戻る。
【００４１】
このようにして処理を繰り返している最中に、例えばリクエスト用楽曲データによる検索用データベースの更新が済んでいないリクエスト装置２がクレードル３に挿入されると、Ｓ１５０にて肯定判断及びＳ１６０にて否定判断となってＳ１７０へ移行し、そのリクエスト装置２へリクエスト用楽曲データが送信されることとなる。また、処理を繰り返している最中に新しいリクエスト用楽曲データがホストコンピュータから配信された場合には、図３のＳ３０にてリクエスト用楽曲データ受信フラグ格納領域１１ｃの受信フラグがオンとなり、したがって、図４のＳ１２０にて肯定判断となるため、Ｓ１３０にて通信済みリクエスト装置管理テーブル１１ｂが初期化される。そのため、それ以降の処理では、既にクレードル３に挿入されていたリクエスト装置２であっても通信済みリクエスト装置管理テーブル１１ｂに登録されていないこととなり、Ｓ１６０にて否定判断となる。したがって、そのリクエスト装置２に対しても更新されたリクエスト用楽曲データが送信されることとなる（Ｓ１７０）。
【００４２】
なお、本第１実施例においては、演奏曲データが「提供情報」に相当し、リクエスト用楽曲データが「検索用データベース」に相当する。また、カラオケ装置１が情報提供装置に相当し、リクエスト装置２が「リクエスト装置」に相当し、クレードル３が「クレードル」に相当する。また、ハードディスク１１が「記憶手段」に相当し、通信済みリクエスト装置管理テーブル１１ｂが「管理テーブル」に相当する。さらに、カラオケ装置１のＣＰＵ１０が「通信必要設定手段」、「存在有無判断手段」、「通信有無判断手段」、「送信手段」、「通信不要設定手段」に相当する。そして、図４のＳ１３０の処理が「通信必要設定手段」、Ｓ１４０及びＳ１５０の処理が「存在有無判断手段」、Ｓ１６０の処理が「通信有無判断手段」、Ｓ１７０の処理が「送信手段」、Ｓ１９０の処理が「通信不要設定手段」、にそれぞれ相当する。
【００４３】
（第１実施例の効果）
以上説明した本第１実施例のカラオケシステムによれば、次のような効果が得られる。
リクエスト装置２のＳＲＡＭ２５に格納されているリクエスト用楽曲データによる検索用データベースの更新が次のようにして行される。つまり、カラオケ装置１のハードディスク１１内のリクエスト用楽曲データ受信フラグ格納領域１１ｃにおけるリクエスト用楽曲データ受信フラグがオンであれば（Ｓ１２０：ＹＥＳ）、通信済みリクエスト装置管理テーブル１１ｂの初期化を行う（Ｓ１３０）。そして、通信可能なリクエスト装置２があれば（Ｓ１５０：ＹＥＳ）、そのリクエスト装置２の識別情報が通信済みリクエスト装置管理テーブル１１ｂに登録済みか否か判断し（Ｓ１６０）、登録済みでない場合は（Ｓ１６０：ＮＯ）、リクエスト用楽曲データを、前記応答のあったリクエスト装置２へ送信する（Ｓ１７０）。
【００４４】
したがって、カラオケ装置１のハードディスク１１内に新しいリクエスト用楽曲データが追加された以降、クレードル３にリクエスト装置２が挿入されると、そのリクエスト装置２へリクエスト用楽曲データが送信されて、最新の検索用データベースの内容とすることができる。そして、この送信がなされた後は、さらに新しいリクエスト用楽曲データがカラオケ装置１のハードディスク１１内に追加されない限り、重複したデータ送信をすることはない。つまり、リクエスト装置２が有する検索用データベース更新のための通信が必要ある場合のみ、カラオケ装置１とリクエスト装置２との間での実質的なデータ通信を行うこととなり、特にカラオケ装置１側の処理負荷を低減する上で有効である。なお、カラオケ装置１は、図４のＳ１６０の判断において、リクエスト装置２から取得した識別情報を元に、その識別情報が通信済みリクエスト装置管理テーブル１１ｂに登録されているか否かを判断している。しかし、これは単にリクエスト装置２からの応答データのヘッダ部分にＩＤを付加するだけでのものであり、従来手法のようなリクエスト装置の検索用データベースの記憶状態を示すデータを通知してもらう、といった実質的なデータ通信を行っているものではない。したがって、やはりカラオケ装置１側の処理負荷を低減する上で有効である。
【００４５】
［第２実施例］
次に、本発明の第２実施例を図５を用いて説明する。
本第２実施例のカラオケシステムは、システム全体の構成は図１に示した第１実施例のものと同様である。
【００４６】
そして、第１実施例と異なる点は、リクエスト装置２においては、後述する緊急通信要求をカラオケ装置１側へ送信できる点のみ異なる。一方、カラオケ装置１においては、本実施例では、通信済みリクエスト装置管理テーブル１１ｂが、設定された初期化時刻になると初期化される点で異なる。従って、第１実施例において、図２に示すハードディスク１１内のリクエスト用楽曲データ受信フラグ格納領域１１ｃが不要であり、そのため当然ながら、図３のＳ３０においてリクエスト用楽曲データ受信時にリクエスト用楽曲データ受信フラグ格納領域１１ｃの受信フラグをオンにする、といった処理自体が不要である。また、図４の処理に代えて図５の処理を実行する。そこで、図５の処理について説明する。
【００４７】
図５は、カラオケ装置１にて実行される、リクエスト装置２へのリクエスト用楽曲データの送信に関する処理を示すフローチャートである。
カラオケ装置１が例えばカラオケボックスに設置され、それによりカラオケ装置１に電源供給がなされて本処理ルーチンが開始すると、まず、ハードディスク１１内の通信済みリクエスト装置管理テーブル１１ｂ（図２参照）の初期化を行う（Ｓ２１０）。
【００４８】
次に、タイマ８（図１参照）から得た現在時刻が、例えばハードディスク１１内に記憶されている管理テーブル初期化時刻になったか否かを判断する（Ｓ２２０）。
ここで、管理テーブル初期化時刻について説明する。この初期化時刻は、所定の時間間隔をおいて設定されたものであり、例えばホストコンピュータからカラオケ装置１への新曲配信が例えば１日に１回ペースであれば、その配信間隔に合わせ、１日１回所定時刻を設定する。例えば毎日０時頃に新曲の配信がある予定のシステムであれば、例えば１時を初期化時刻として設定することが考えられる。また、カラオケ装置１の稼働しているタイミングを考慮してもよい。例えば本実施例のカラオケシステムを営業に用いる場合、カラオケ店の営業時間が４時までであったとすると、たとえ０時に配信があったとしても、４時以降の初期化時刻、例えば５時を初期化時刻に設定することで、カラオケ装置１の稼働中は更新させないようにしてもよい。
【００４９】
図５の説明に戻り、管理テーブル初期化時刻になった場合は（Ｓ２２０：ＹＥＳ）、更新すべきリクエスト用楽曲データが存在するため、通信済みリクエスト装置管理テーブル１１ｂ（図２参照）の初期化を行う（Ｓ２３０）。通信済みリクエスト装置管理テーブル１１ｂが初期化された場合、当該管理テーブルにはリクエスト装置識別情報が何ら登録されていないため、全てのリクエスト装置２が更新のための通信対象となる。
【００５０】
そして、上記第１実施例の場合と同様、通信可能なリクエスト装置２を探索し（Ｓ２４０）、例えば所定時間内に何らリクエスト装置２からの応答がなければ（Ｓ２５０：ＮＯ）、Ｓ２２０へ戻る。一方、リクエスト装置２からの応答があれば（Ｓ２５０：ＹＥＳ）、次に、その応答に伴って緊急通信要求があるか否か判断する（Ｓ２６０）。
【００５１】
この緊急通信要求は、リクエスト装置２が、入力装置２４を介して特殊な操作を受け付けた場合にカラオケ装置１側へ送信する。入力装置２４は上述したようにテンキーや各種機能キーを有しているが、通常の操作においてはこれらを複数同時に操作することはない。したがって、例えば所定の２つの操作子を同時に操作することで、緊急通信要求信号を送信するよう構成されている。このようにすれば、緊急通信要求のためだけに特別な操作子を設ける必要はなくなる。もちろん、緊急通信要求のためだけに特別な操作子を設けてもよい。
【００５２】
図５の説明に戻り、緊急通信要求がない場合には（Ｓ２６０：ＮＯ）、そのリクエスト装置２の識別情報が、ハードディスク１１内の通信済みリクエスト装置管理テーブル１１ｂに登録済みか否か判断する（Ｓ２７０）。リクエスト装置識別情報が通信済みリクエスト装置管理テーブル１１ｂに登録済みの場合は（Ｓ２７０：ＹＥＳ）、既に更新すべきリクエスト用楽曲データを送信しているため、Ｓ２２０へ戻る。
【００５３】
一方、リクエスト装置識別情報が通信済みリクエスト装置管理テーブル１１ｂに登録済みでない場合は（Ｓ２７０：ＮＯ）、リクエスト用楽曲データを、前記応答のあったリクエスト装置２へ送信する（Ｓ２８０）。
また、緊急通信要求がある場合には（Ｓ２６０：ＹＥＳ）、Ｓ２７０の処理を実行せずにＳ３１０へ移行する。つまり、ステップＳ３１０では、リクエスト装置２から緊急通信要求があれば、通信済みリクエスト装置管理テーブル１１ｂへの登録の有無を判断せずに、緊急通信要求があったリクエスト装置２にリクエスト用楽曲データを送信するのである。このときのリクエスト用楽曲データの送信は、ハードディスク１１に記憶されたリクエスト用楽曲データを全て送信するようにしてもよいし、追加された新たなリクエスト用楽曲データのみを送信するようにしてもよい。
【００５４】
このようなリクエスト用楽曲データの送信処理が正常に終了した場合には（Ｓ２９０：ＹＥＳ）、前記応答のあったリクエスト装置２のリクエスト装置識別情報を、通信済みリクエスト装置管理テーブル１１ｂに登録し（Ｓ３００）、Ｓ２２０へ戻る。また、正常終了しなかった場合は（Ｓ２９０：ＹＥＳ）、そのままＳ２２０へ戻る。
【００５５】
このようにして処理を繰り返している最中に、再度、通信済みリクエスト装置管理テーブル１１ｂの初期化時刻になれば、Ｓ２２０にて肯定判断となるため、Ｓ２３０にて通信済みリクエスト装置管理テーブル１１ｂが初期化され、それ以降の処理では、既にクレードル３に挿入されていたリクエスト装置２であっても通信済みリクエスト装置管理テーブル１１ｂに登録されていないこととなり、Ｓ２７０にて否定判断となる。したがって、そのリクエスト装置２に対しても更新されたリクエスト用楽曲データが送信されることとなる（Ｓ２８０）。
【００５６】
なお、本第２実施例においては、演奏曲データが「提供情報」に相当し、リクエスト用楽曲データが「検索用データベース」に相当する。また、カラオケ装置１が情報提供装置に相当し、リクエスト装置２が「リクエスト装置」に相当し、クレードル３が「クレードル」に相当する。また、ハードディスク１１が「記憶手段」に相当し、通信済みリクエスト装置管理テーブル１１ｂが「管理テーブル」に相当する。また、管理テーブル初期化時刻が「所定時刻」に相当する。さらに、カラオケ装置１のＣＰＵ１０が「通信必要設定手段」、「存在有無判断手段」、「通信有無判断手段」、「送信手段」、「通信不要設定手段」に相当する。そして、図５のＳ２３０の処理が「通信必要設定手段」、Ｓ２４０及びＳ２５０の処理が「存在有無判断手段」、Ｓ２７０の処理が「通信有無判断手段」、Ｓ２８０の処理が「送信手段」、Ｓ３００の処理が「通信不要設定手段」、にそれぞれ相当する。また、リクエスト装置２の入力装置２４及びＣＰＵ２０が「緊急通信要求発生手段」に相当する。
【００５７】
（第２実施例の効果）
以上説明した本第２実施例のカラオケシステムによれば、次のような効果が得られる。
カラオケ装置１は、管理テーブル初期化時刻になると（Ｓ２２０：ＹＥＳ）、通信済みリクエスト装置管理テーブル１１ｂの初期化を行う（Ｓ２３０）。そして、通信可能なリクエスト装置２があり（Ｓ２５０：ＹＥＳ）、そのリクエスト装置２の識別情報が通信済みリクエスト装置管理テーブル１１ｂに登録済みでない場合は（Ｓ２７０：ＮＯ）、リクエスト用楽曲データを、前記応答のあったリクエスト装置２へ送信する（Ｓ２８０）。
【００５８】
このように、カラオケ装置１のハードディスク１１に新たなリクエスト用楽曲データが追加された後、管理テーブル初期化時刻になった以降、リクエスト装置２がクレードル３に挿入されると、そのリクエスト装置２へリクエスト用楽曲データが送信されて、最新の検索用データベースの内容とすることができる。そして、この送信がなされた後は、基本的には、管理テーブル初期化時刻にならない限り、重複したデータ送信をすることはない。
【００５９】
したがって、上記第１実施例の場合と同様、リクエスト装置２が有する検索用データベース更新のための通信が必要ある場合のみ、カラオケ装置１とリクエスト装置２との間での実質的なデータ通信を行うこととなり、特にカラオケ装置１側の処理負荷を低減する上で有効である。
【００６０】
（２）また、上述のように「基本的には、管理テーブル初期化時刻にならない限り、重複したデータ送信をすることはない」のであるが、リクエスト装置２としては、管理テーブル初期化時刻にならない限りリクエスト用楽曲データの送信をしてもらえないのでは、不都合な場合も生じる可能性がある。つまり、上記第１実施例の場合であれば、カラオケ装置１のハードディスク１１内に新しいリクエスト用楽曲データが追加されると、それをトリガとして通信済みリクエスト装置管理テーブル１１ｂの初期化を行った（図４のＳ１３０参照）。それに対して本第２実施例の場合は、所定時刻である管理テーブル初期化時刻になったことをトリガとして通信済みリクエスト装置管理テーブル１１ｂの初期化を行っている（図５のＳ２３０参照）。そのため、次のような不都合がある。
【００６１】
例えば管理テーブル初期化時刻になって通信済みリクエスト装置管理テーブル１１ｂの初期化がなされ、その結果、クレードル３に挿入されていたリクエスト装置２へリクエスト用楽曲データが送信された場合を想定する。この場合、図５のＳ３００において通信済みリクエスト装置管理テーブル１１ｂへ登録されるため、それ以降は、次の「管理テーブル初期化時刻」にならないと、当該リクエスト装置２へのリクエスト用楽曲データの送信は行われない。
【００６２】
しかしながら、例えば図５のＳ３００において通信済みリクエスト装置管理テーブル１１ｂへ登録された直後にカラオケ装置１のハードディスク１１内に新しいリクエスト用楽曲データが追加された場合、当該リクエスト装置２に対しては、その追加されたリクエスト用楽曲データの送信が遅れる可能性がある。例えば管理テーブル初期化時刻が１日に１回しか設定されていない場合、丸一日程度も新しいリクエスト用楽曲データが送信されなくなる。
【００６３】
そこで、そのような場合の対処として、本第２実施例では、図５のＳ２６０に示すように、リクエスト装置２から緊急通信要求があった場合は、Ｓ２７０での通信済みリクエスト装置管理テーブル１１ｂへの登録の有無を判断せずに、緊急通信要求のあったリクエスト装置２にリクエスト用楽曲データを送信する（Ｓ２８０）ようにした。例えば、ユーザ（ここではカラオケシステムの管理者の意味）が、上述のような新しいリクエスト用楽曲データの配信がカラオケ装置１に対してなされたことを知った場合には、リクエスト装置２の入力装置２４を介して特殊な操作をして緊急通信要求を出せばよい。このようにすることで、所定時刻以外であっても強制的に、カラオケ装置１からリクエスト装置２へ新たなリクエスト用楽曲データを送信させることができる。
【００６４】
［別実施例］
以上実施例について説明したが、本発明は上記実施例に限定されるものではなく、種々の態様で実施し得る。そのいくつかを説明する。
（１）上記実施例では、複数のリクエスト装置２の存在を前提にしたため、図２に示すように、通信済みリクエスト装置管理テーブル１１ｂへリクエスト装置識別情報を登録するようにした。しかし、仮に１台のカラオケ装置１に対しては固定の１台のリクエスト装置２しか用いないのであれば、識別情報まで登録する必要はなく、単にフラグをオン・オフ設定するだけでも対応可能である。
【００６５】
（２）上記第２実施例では、緊急通信要求をリクエスト装置２側から出すようにしたが、例えばカラオケ装置１に所定のスイッチを設けておき、それを操作すると緊急通信要求が発生して通信済みリクエスト装置管理テーブル１１ｂが初期化され、それによりそれ以降クレードル３に挿入されるリクエスト装置２に対して、リクエスト用楽曲データを送信するようにしてもよい。
【００６６】
（３）上記実施例では、カラオケシステムとして実現した場合について説明したが、カラオケシステムには限らず、リクエスト情報を検索するための検索用データベースを有し、ユーザから受け付けた操作に基づき検索した結果としてのリクエスト情報を情報提供装置に対して送信し、その受信したリクエスト情報に応じた提供情報を用いて情報提供を実行する情報提供装置とからなるリクエスト対応型情報提供システムであれば同様に適用できる。例えばビデオサーバを利用したビデオライブラリなどが考えられる。
【図面の簡単な説明】
【図１】実施例のカラオケシステムの概略構成を示すブロック図である。
【図２】カラオケ装置のハードディスク内に格納されるリクエスト用楽曲データ及びそれに関連するデータの概略説明図である。
【図３】第１実施例のカラオケ装置にて実行される配信データの受信時の処理を示すフローチャートである。
【図４】第１実施例のカラオケ装置にて実行されるリクエスト用楽曲データの更新に係る処理を示すフローチャートである。
【図５】第２実施例のカラオケ装置にて実行されるリクエスト用楽曲データの更新に係る処理を示すフローチャートである。
【符号の説明】
１…カラオケ装置、２…リクエスト装置、３…クレードル、８…タイマ、９…映像再生装置、１０…ＣＰＵ、１１…ハードディスク、１２…モデム、１３…再生装置、１４…リモコン受光部、１５…通信Ｉ／Ｆ、１６…マイクロフォン、１７…アンプ、１８…スピーカ、１９…ＣＲＴ、２０…ＣＰＵ、２１…通信Ｉ／Ｆ、２２…リモコン発光部、２３…液晶表示部、２４…入力装置、２５…ＳＲＡＭ、電源２６
【図１】
2004184766.tif 000003
【図２】
2004184766.tif 000004
【図３】
2004184766.tif 000005
【図４】
2004184766.tif 000006
【図５】
2004184766.tif 000007