JPH08305758A - 情報提供端末及び該端末を備えた通信式情報提供システム - Google Patents

Abstract

(57)【要約】 【目的】 半永久的に新しいサービス提供用情報を情報
提供装置内の情報記憶手段に追加記憶させることが可能
な通信式情報提供システムを提供する。 【構成】 中央制御装置３１は、第１通信制御装置２７
ａを介して情報センタ３に、配信される曲があるかどう
かを問い合わせる。その後、ハードディスク３３の明き
容量が所定量以上あるかどうかチェックし、所定量以上
なければ、同じハードディスク３３内の課金・使用実績
テーブルの課金状態の項を参照して、所定期間以上未課
金のため使用禁止フラグが設定されているカラオケ曲情
報を削除する。そして、前記配信される予定の曲を受信
し、ハードディスク３３に格納する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、情報記憶手段に記憶さ
れたサービス提供用情報を用いて所定の情報提供サービ
スを実行する場合に、課金状態記憶手段において課金済
みであると記憶されたもののみ、その情報提供サービス
処理への使用を許可するようにした情報提供端末及びそ
の端末を備えた通信式情報提供システムに関する。

【０００２】

【従来の技術】従来より、情報記憶手段にサービス提供
用情報を記憶しているが、その全てを使用できるのはな
く、その対価である所定料金の課金処理が済んだサービ
ス提供用情報についてのみ所定の情報提供サービス処理
のために使用可能とするものが提案されている。例え
ば、スクランブル情報を付加することで、そのままでは
使用不可能な状態でサービス提供用情報としてのカラオ
ケ曲情報を記憶させた記憶媒体（レーザディスクやＣＤ
等）を情報提供端末としてのカラオケ端末にセットし、
ビデオテックス通信網等を用いた所定の課金処理が実行
されると、その課金金額に応じてスクランブル情報を解
除するための解除キーが送信され、カラオケ曲情報が使
用可能となるもの等である。

【０００３】また、上記スクランブル情報の付加された
カラオケ曲情報を情報センタからオンラインで送信して
カラオケ端末の情報記憶手段に記憶させ、上記例と同様
に、ビデオテックス通信網等を用いた所定の課金処理に
伴って受信した解除キーで、カラオケ曲情報を使用可能
とするものも出願人は提案している。例えば、カラオケ
端末の設置時には、内蔵のハードディスクに既にリリー
スされている数千曲程度のカラオケ曲情報を記憶させて
おき、その後順次リリースされる新曲については、その
都度オンラインで送信し、曲数を充実させていくという
ものである。

【０００４】

【発明が解決しようとする課題】しかしながら、このよ
うに新曲を自動的に送信して曲数を増やしていく方式を
採用すると、いずれは情報記憶手段の記憶容量の限界に
達してしまい、その後の新曲については受信して記憶さ
せることができなくなってしまう。あるいは、そのよう
な事態を考慮して大容量の情報記憶手段を準備しておく
ことも考えられるが、そのためには非常に大型の情報記
憶手段を準備する必要があり、装置の大型化及びコスト
アップにつながる。

【０００５】また、上述したように課金が済んで初めて
使用可能にする手法を採用した場合には、カラオケ曲情
報自体は記憶されておりながら、実際のカラオケ演奏に
は使用されないという事態が生じる可能性がある。つま
り、カラオケ端末の設置事業者が、例えばある特定のジ
ャンルしか必要ない、あるいはある特定のジャンルにつ
いては不要だと考えて、記憶されているカラオケ曲情報
を全て使用可能にするのではなく、自分が必要だと考え
るカラオケ曲情報についてのみ、その料金を支払って使
用可能にすることが考えられる。

【０００６】すると、必要度の低いカラオケ曲情報が記
憶されていることが原因で、相対的に必要度の高い新曲
については記憶させられなくなることも考えられる。あ
るいは、この必要度の低いカラオケ曲情報も含めて記憶
するためには、必要以上に大型の情報記憶手段を準備し
なくてはならない。このように、新しいカラオケ曲情報
を追加して記憶させていきたい場合に、必要度の低いカ
ラオケ曲情報の存在によって新曲の追加が不可能であっ
たり必要以上に情報記憶手段が大型化してしまうという
問題が生じるのである。

【０００７】そして、こうした問題はもちろん通信カラ
オケシステムだけに限る訳ではなく、将来のマルチメデ
イア社会における各種の情報提供システムに共通するも
のである。そこで、本発明は、内蔵する情報記憶手段を
必要以上に大型化させることなく、半永久的に新しいサ
ービス提供用情報をその情報記憶手段に追加記憶させる
ことが可能な情報提供端末及びその情報提供端末を備え
た通信式情報提供システムを提供することを目的とす
る。

【０００８】

【課題を解決するための手段、作用及び発明の効果】上
記目的を解決するためになされた請求項１に記載の発明
は、サービス提供用の情報を記憶している情報記憶手段
と、該情報記憶手段に記憶されたサービス提供用情報を
用いて所定の情報提供サービスを実行可能な情報提供実
行手段と、前記情報記憶手段に記憶されたサービス提供
用情報毎に、課金済みであるか未課金であるかを記憶し
ておく課金状態記憶手段と、該課金状態記憶手段におい
て課金済みであると記憶されているサービス提供用情報
についてのみ、前記情報提供実行手段による情報提供サ
ービス処理への使用を許可する使用許可手段とを備えた
情報提供端末であって、前記情報記憶手段に記憶された
サービス提供用情報毎に、必要度を判断する判断手段
と、所定の削除実行条件が成立した場合には、該判断手
段によって必要度が低いと判断されたサービス提供用情
報を、前記情報記憶手段より削除する情報削除手段とを
備えていることを特徴とする情報提供端末である。

【０００９】この情報提供端末は、情報記憶手段に記憶
しているサービス提供用情報を用いて所定の情報提供サ
ービス処理を実行することができるのであるが、情報記
憶手段が記憶しているサービス提供用情報であれば、ど
れも無条件に使用して情報提供サービス処理を実行でき
るのではない。つまり、課金状態記憶手段が、情報記憶
手段に記憶されたサービス提供用情報毎に課金済みであ
るか未課金であるかを記憶しており、使用許可手段は、
課金状態記憶手段において課金済みであると記憶されて
いる情報についてのみ、情報提供実行手段による情報提
供サービス処理への使用を許可するのである。

【００１０】具体的には、例えば、未課金の場合にはス
クランブル情報を付加した状態でサービス提供用情報を
記憶させ、そのままでは実質的に情報提供サービス処理
に使用できないような状態にしておき、課金済みとなれ
ば、そのスクランブル情報を解除することで使用許可す
ることが考えられる。また、スクランブル情報の付加と
いったようにサービス提供用情報自体を使用不可にして
おくのではなく、サービス提供用情報自体は物理的には
使用可能であっても、課金状態が未課金である場合（例
えばフラグ等で区別する）には、そのサービス提供用情
報を使用する情報提供サービスがリクエストされても受
け付けないように制御してもよい。

【００１１】このように、課金済みであるサービス提供
用情報のみが情報提供サービス処理に使用できるように
なるのであるが、例えば、情報提供端末の設置事業者の
意図によって未課金のまま放置されるサービス提供用情
報も生じる可能性がある。つまり、そのサービス提供用
情報はその設置事業者にとっては不要あるいは必要度が
あまり高くないので、あえて料金を支払ってまで使用可
能とするものでもないと考える場合には、未課金のまま
となる。例えば、情報提供端末をカラオケ端末に適用し
た場合で考えると、設置事業者が、例えばある特定のジ
ャンルしか必要ない、あるいはある特定のジャンルにつ
いては不要だと考えて、記憶されているカラオケ曲情報
を全て使用可能にするのではなく、自分が必要だと考え
るカラオケ曲情報についてのみ、その料金を支払って使
用可能にすることは十分に考えられる。

【００１２】すると、例えば、新曲を随時追加していく
ようなシステムを採用している場合には、必要度の低い
カラオケ曲情報が記憶されているのに、相対的に必要度
の高い新曲については記憶させられなくなったり、ある
いは、この必要度の低いカラオケ曲情報も含めて記憶す
るために、必要以上に大型の情報記憶手段を準備しなく
てはならないという問題が生じる。

【００１３】そこで、本情報提供端末においては、以下
のように対処する。つまり、判断手段によって、情報記
憶手段に記憶されたサービス提供用情報毎に必要度を判
断することができ、所定の削除実行条件が成立した場合
には、情報削除手段が、その判断手段によって必要度が
低いと判断されたサービス提供用情報を情報記憶手段よ
り削除するのである。

【００１４】この「所定の削除実行条件が成立した場
合」については、例えば請求項２に示すように、情報記
憶手段における空き容量が所定量より少なくなった場合
に所定の削除実行条件が成立したと判断することが考え
られる。そして、その場合に、情報削除手段は、情報記
憶手段における空き容量が所定量以上となるまで、必要
度が低いと判断されたサービス提供用情報を削除する。

【００１５】このように、必要度が低いと判断されたサ
ービス提供用情報が情報記憶手段より削除されること
で、情報記憶手段の空き容量が増すのである。例えば請
求項２の場合であれば、常に情報記憶手段における空き
容量が所定量以上となるようにすることができる。した
がって、内蔵する情報記憶手段を必要以上に大型化させ
ることなく、半永久的に新しいサービス提供用情報をそ
の情報記憶手段に追加記憶させることが可能となるので
ある。

【００１６】前記必要度を判断する判断手段について
は、以下の様な態様が考えられる。すなわち、請求項３
に示すものでは、判断手段は、課金状態記憶手段に記憶
されている課金済みであるか未課金であるかの情報に基
づいて、サービス提供用情報毎に必要度を判断する。

【００１７】また請求項４に示すものでは、判断手段
は、情報提供実行手段による所定の情報提供サービスの
実行のために使用されていない期間に基づいて、サービ
ス提供用情報毎に必要度を判断する。さらに、請求項５
に示すものでは、判断手段は、情報提供実行手段による
所定の情報提供サービスの実行頻度に基づいて、サービ
ス提供用情報毎に必要度を判断する。

【００１８】上述したように、自分が必要だと考えるサ
ービス提供用情報についてのみ、その料金を支払って使
用可能にすることが考えられるので、情報提供端末の設
置事業者の意志を鑑みても、課金済みと記憶されている
ものは必要度が高く、未課金と記憶されているものは必
要度が低いと考えても特に問題がない。但し、新しく記
憶させたサービス提供用情報については、その必要度を
設置事業者が判断しない間に一律に必要度が低いと判断
してしまうのは好ましくないので、例えば新しく記憶さ
せたサービス提供用情報については、その記憶時から所
定期間経過後に本判断をするようにした方がよい。

【００１９】また、課金済みか未課金かではなく、情報
提供実行手段による所定の情報提供サービスの実行のた
めに使用されていない期間や実行頻度に基づいて必要度
を判断することも考えられる。つまり、例え一度は使用
されていても、その後長期間にわたって使用されていな
い場合には、そのサービス提供用情報に対する必要度が
低いと考えられるので、情報提供サービスの実行のため
に使用されていない期間が長い程、必要度が低いとする
ことができる。また、同様に実行頻度が低い程、必要度
が低いとすることができる。

【００２０】但し、一見使用されていない期間が長くて
も、長期的に見た場合に、コンスタントにされており、
その使用回数はトータルで多くなる場合もある。また、
逆に使用回数は少なくても、そのサービス提供用情報の
記憶時期が新しい場合には、使用回数が少なくても当然
であるので、所定期間使用されていない、あるいは使用
回数が少ないというだけで単純に必要度が低いと判断す
るのではなく、例えば使用されてない期間と使用頻度等
を総合的に分析して必要度を判断するようにすることが
好ましい。

【００２１】なお、上記請求項２の場合には、情報記憶
手段における空き容量が所定量より少なくなった場合に
所定の削除実行条件が成立したと判断したが、このよう
に空き容量に基づくのではなく、例えば上記使用されて
いない期間等に基づいて判断してもよい。つまり、使用
されていない期間が相当長くなった場合には、例え空き
容量が所定量よりも多い場合であっても、所定の削除実
行条件が成立したと判断してもよい。

【００２２】以上は、情報提供端末についてであった
が、この情報提供端末を備えた通信式情報提供システム
としては以下のものが考えられる。請求項６に示す通信
式情報提供システムは、請求項１〜５のいずれかに記載
の情報提供端末と、該情報提供端末に対し、課金通信網
を介して課金情報を送信可能な課金センタとを備え、該
課金センタが前記課金通信網を介して課金情報を送信す
ることによって、前記課金通信網の課金機能による課金
がなされると共に、前記情報提供端末の課金状態記憶手
段においては、その送信された課金情報に対応するサー
ビス提供用情報が課金済みであると記憶されることを特
徴とする。

【００２３】請求項１〜５に示した情報提供端末におい
ては、課金あるいは実際の料金徴収については特に限定
せず、課金状態記憶手段が、サービス提供用情報毎に課
金済みであるか未課金であるかを記憶しておく点を明示
した。したがって、例えば、サービス提供用情報提供者
側のサービスマン等が、直接その情報提供端末の設置さ
れた場所まで出向き、設置事業者の要求に応じて課金済
みに設定すると共に、その料金を徴収してもよいが、こ
のような方法では非常に面倒である。

【００２４】そこで、請求項６に示すものでは、課金セ
ンタが課金通信網を介して課金情報を送信することによ
って課金通信網の課金機能による課金がなされると共
に、課金状態記憶手段においては、その送信された課金
情報に対応するサービス提供用情報が課金済みであると
記憶されるようにした。このようにすれば、例えば情報
提供端末の設置事業者が課金を実行させてサービス提供
用情報を使用可能にしたいと考えたときには、その指示
をするだけで課金通信網による課金機能を利用した課金
がなされ、サービス提供用情報を使用可能にするための
対価を、人の手を煩わさずに自動的に回収することが可
能となるため、非常に便利である。

【００２５】なお、この課金処理を実行する際には、ま
ず課金センタと情報提供端末とを課金通信網を介して接
続する必要がある。ここで、現行のキャプテンシステム
やダイヤルキューツーなどの課金通信網では発呼側（電
話をかけた側）に課金することとなっているので、情報
提供端末側から課金センタをコールして接続することに
なる。しかし、既に公衆電話回線においても実用化され
ているように、コレクトコール方式で着呼側（電話を受
けた側）に課金するように課金通信網の構成を変更する
ことは可能である。よって、ここでの接続は、情報提供
端末側に課金される限りは、情報提供端末側が発呼する
ものであっても課金センタ側が発呼するものであっても
構わない。

【００２６】また、情報記憶手段が記憶するサービス提
供用情報の出所についても、上記情報提供端末の説明で
は特に限定していない。したがって、例えば、サービス
提供用情報を記憶させた記憶媒体（レーザディスクやＣ
Ｄ、あるいはハードディスク等）を情報提供端末にセッ
トして情報記憶手段として機能させてもよいし、オンラ
インで受信してもよい。

【００２７】このオンラインでサービス提供用情報を受
信するようにした通信式情報提供システムの一例が請求
項７に示すものである。すなわち、その構成は、請求項
６に記載の通信式情報提供システムであって、前記情報
提供端末に対し、情報通信網を介してスクランブル情報
の付加されたサービス提供用情報を送信可能な情報セン
タを備え、前記情報提供端末の使用許可手段は、情報セ
ンタから送信されて情報記憶手段に記憶されたサービス
提供用情報の内、課金状態記憶手段に課金済みであると
記憶された情報についてのみ、スクランブル情報を解除
して情報提供サービス処理への使用を許可することを特
徴とする。

【００２８】なお、サービス提供用情報は先に送信して
おき、その後、課金処理が済んだものだけ使用可能にす
るものであるため、先に送信するサービス提供用情報を
未課金であるにもかかわらず不正に使用される可能性も
ある。したがって、情報センタから送信する時点ではス
クランブル情報を付加しておき、課金が済んだものにつ
いては、スクランブルを解除するための暗号解読キーを
受信することによって使用可能とすることが好ましい。

【００２９】また、本システムにおいて、情報通信網と
課金通信網とを異なる通信網とすれば、次の点で特に優
れた作用・効果を奏する。即ち、情報提供端末において
情報提供サービスに用いるサービス提供用情報は、例え
ばカラオケ曲情報やゲーム情報のように情報量のかなり
大きなものとなる場合が想定されるが、そういった大き
な情報そのものを情報センタから配信する場合には、そ
の配信に適した通信網を利用することが好ましい。つま
り、課金通信網を利用してサービス提供用情報自体を配
信するよりも迅速であったり、データの信頼性が高かっ
たりするという点で、情報提供端末が受け取るべき情報
の種類に応じた最適なシステム構成が可能となるからで
ある。

【００３０】ここまでの説明でも判る通り、本発明の通
信式情報提供システムにおける課金センタと情報センタ
は、別々の独立したセンタとして存在してもよいし、一
つのセンタの中に両機能を備えさせておいてもよい。い
ずれにしても情報提供端末に対して情報の配信が可能な
情報通信網の方を介して接続されたときに情報センタと
しての機能を発揮でき、課金通信網の方を介して接続さ
れたときに課金センタとしての機能が発揮でき、課金セ
ンタとしての機能を有する部分による課金の完了が何等
かの手段によって情報センタとしての機能を有する部分
に伝達される限りは、両センタが別体であろうと一体で
あろうと構わないのである。即ち、本発明においては、
情報センタと課金センタは概念として分けて表現されて
いるだけであって物として分かれている場合だけを意味
するわけではない。

【００３１】

【実施例】以下、本発明を具体化した一実施例を図面を
参照して説明する。図１は、実施例の通信式情報提供シ
ステムをカラオケに関するシステムに適用した場合の概
略構成図、図２はそのシステムの構成要素である情報提
供端末としてのカラオケ端末１０の構成を示すブロック
図である。

【００３２】図１に示すように、本実施例のシステム
は、課金関連処理を担当する課金センタ１と複数のカラ
オケ端末１０とが、課金通信網５を介して接続されてい
ると共に、カラオケ曲情報の送信関連処理を担当する情
報センタ３と複数のカラオケ端末１０とが、情報通信網
７を介して接続されて構成されている。また、課金セン
タ１と情報センタ３との間も接続されている。

【００３３】課金通信網５は、例えばビデオテックス通
信網やダイヤルキューツー通信網のように、情報料に対
して課金する機能を持つものである。現在の日本国内で
は、ビデオテックス網とダイヤルキューツー網がその代
表的なものとして知られておいる。ダイヤルキューツー
網は基本的に時間単位の従量計算であり、ビデオテック
ス網は、情報の内容毎に任意の料金を設定可能であり、
いわゆるキャプテンシステム等に用いられている。

【００３４】その課金機能の一例として、ビデオテック
ス通信網について説明すると、ビデオテックス通信網
は、具体的には例えば各カラオケ端末１０に接続された
公衆電話回線とビデオテックス通信処理装置とで構成さ
れている。このビデオテックス通信処理装置が、ビデオ
テックス通信網にアクセスしようとしている公衆電話回
線の課金センタ１への接続・交換、利用者装置であるカ
ラオケ端末１０の管理及び課金センタ１への加入者管
理、通信料及び電話会社が代理徴収する情報提供料の課
金、カラオケ端末１０と課金センタ１との間の会話制
御、プロトコル変換やコード／パターン変換などの変換
処理等の通信処理機能を提供する。

【００３５】続いてカラオケ端末１０の構成について、
図２を参照して説明する。使用許可手段、判断手段及び
情報削除手段等に相当する中央制御装置３１には、各種
指示入力を行なうための入力手段としての多目的入力キ
ー３２、情報記憶手段としてのハードディスク３３、音
声再生回路３５、画面表示制御装置２６、情報通信網７
と接続可能な第１通信制御装置２７ａ及び課金通信網５
と接続可能な第２通信制御装置２７ｂとを備えている。
また、音声再生回路３５にはミキサアンプ３８が、画面
表示制御装置２６には表示手段としてのテレビモニタ２
９がそれぞれ接続されている。また、ミキサアンプ３８
にはスピーカ４１とマイクロフォン４３が接続されてい
る。

【００３６】そして、この中央制御装置３１は所定の課
金制御処理を実行する。この課金制御処理については後
で詳しく説明するが、従来の課金通信網５の利用方法と
は異なるので、その点を説明しておく。従来は、利用者
端末がこの課金通信網５を介して情報を受信し、その情
報を用いて所定の処理を実行する。そして、課金通信網
５はその情報の代金として所定の料金（情報内容毎に設
定された所定料金）を課金することとなる。

【００３７】それに対して、本実施例では、カラオケ端
末１０がカラオケ演奏処理に用いる情報は、ハードディ
スク３３が記憶している。ハードディスク３３には予め
数千曲程度のカラオケ曲情報が記憶されている。なお、
カラオケ端末１０は、カラオケ端末設置事業者の管理で
あり、新しい曲データがリリースされる毎に曲データ配
信事業者から曲データの供給を受けることができる。本
実施例のシステムでは、第１通信制御装置２７ａを介し
て情報通信網７と接続し、情報センタ３からその新曲デ
ータを受信して、ハードディスク３３に後から記憶させ
ることができるようにされている。

【００３８】なお、前記ハードディスク３３に記憶され
るカラオケ曲情報は、曲同士を識別するための識別情報
である曲番号情報と、実体情報とから構成されている。
この内の実体情報は、伴奏音楽の情報であるＭＩＤＩ
（Musical Instrument DigitalInterface）規格の演奏
情報や、歌詞情報及び背景映像情報からなっている。背
景映像情報は曲毎に対応した映像情報を符号化したもの
である。

【００３９】そして、このカラオケ曲情報はそのままで
は使用できないようにされている。使用するためには、
課金通信網５に第２通信制御装置２７ｂを通して接続
し、中央制御装置３１が課金制御プログラムを実行する
ことによって、課金通信網５による課金機能を利用した
所定の課金処理が行われて、カラオケ曲情報を使用する
ことができる状態となる。

【００４０】例えば、未課金状態ではカラオケ曲情報に
スクランブル情報を付加しておき、そのままでは使用で
きなくしてある場合に、課金処理によって解除キーを配
信してもらい、その解除キーによってスクランブル情報
を解除することで使用許可することが考えられる。ま
た、スクランブル情報の付加といったようにカラオケ曲
情報自体を使用不可にしておくのではなく、カラオケ曲
情報自体は物理的には使用可能であっても、課金状態が
未課金である場合には、使用禁止フラグを設定してお
き、そのカラオケ曲情報がリクエストされても受け付け
ないような制御をするようにしてもよい。そして、課金
済みとなると、その使用禁止フラグを使用可能フラグに
変更するといったような制御をすれば実現できる。

【００４１】本実施例では、課金・使用実績テーブル中
において、曲毎に使用可能フラグあるいは使用禁止フラ
グのいずれかが設定されており、そのフラグに応じて使
用を許可したり、禁止したりするようにされている。図
１１には、ハードディスク３３に格納されたその課金・
使用実績テーブルを示す。カラオケ曲情報毎に、その曲
番号・曲名・そのカラオケ曲情報に対する料金・課金日
・課金状態・使用許可禁止フラグ・受信日または最終リ
クエスト日・使用回数の項目からなるテーブルが存在す
る。

【００４２】ここで、受信日または最終リクエスト日と
は、カラオケ曲情報を受信してから一度もリクエストさ
れずにカラオケ演奏処理に使用されてしない場合には、
受信日が記憶され、リクエストがあってカラオケ演奏処
理に使用された場合には、そのリクエスト毎に更新され
ていき、最後にリクエストがあった日がここに記憶され
ることとなる。また、使用回数とは、リクエストによっ
てカラオケ演奏として使用された回数である。

【００４３】また、課金状態とは、所定の課金処理が済
んでいる「課金済み」か課金処理が済んでいない「未課
金」かのいずれかである。そして、使用許可禁止フラグ
としては、上述したように許可か禁止のフラグが設定さ
れるのであるが、これはまず、課金状態が「未課金」の
場合には、禁止フラグが設定されて曲の使用ができない
ロック状態とされている。そして、所定の課金処理によ
って「課金済み」となると許可フラグが設定されてロッ
ク状態が解除され、曲情報は自由に使用できるようにな
る。

【００４４】上記許可フラグが設定されて、カラオケ曲
情報が使用できるようになると、利用者は多目的入力キ
ー３２を操作することで歌いたい曲を選択する。すると
中央制御装置３１は、所定のカラオケ演奏プログラムに
従って、カラオケ演奏処理を実行する。簡単に説明する
と、中央制御装置３１は、選択された曲に対応する演奏
情報、歌詞情報および背景映像情報をハードディスク３
３から読み出し、演奏情報は音声再生回路３５に、歌詞
情報および背景映像情報は画面表示制御装置２６にそれ
ぞれ転送する。

【００４５】音声再生回路３５に出力された演奏情報
は、アナログの演奏信号に変換された後、ミキサアンプ
３８へ送られて電気的に増幅されるとともに、マイクロ
フォン４３を介して入力する利用者の歌声と適度な割合
でミキシングされる。ミキシングされた音声信号は、ス
ピーカ４１により演奏音として外部へ出力される。

【００４６】一方、演奏情報と同期して出力される歌詞
情報は、画面表示制御装置２６において、後述する背景
映像信号と合成（スーパーインポーズ）されてテレビモ
ニタ２９に表示される。これにより、テレビモニタ２９
には、背景映像に歌詞テロップが合成された状態で表示
される。

【００４７】続いて、課金センタ１の構成を図３を参照
して説明する。課金センタ１は、ホストコンピュータ５
１と、記憶装置５３と、入力装置５５と、通信制御装置
５７と、プリンタ５９と、ＣＲＴ６１とを備えている。
前記記憶装置５３は、ホストコンピュータ５１が作動す
るための各種制御プログラムや、前記各カラオケ端末１
０毎の課金実績等を記憶するためのものである。つま
り、図１１に示した課金・使用実績テーブルに似たもの
が、各カラオケ端末１０に対応して記憶されているので
ある。詳しくは、図１１に示したデータ項目の内の使用
許可禁止フラグは記憶しておく必要がないので、その使
用許可禁止フラグの項目を除く。また受信日または最終
リクエスト日の項目には配信日が記憶される。そして使
用回数の項目はない。すなわち、カラオケ曲情報毎に、
その曲番号・曲名・そのカラオケ曲情報に対する料金・
課金日・課金状態・配信日の項目からなるテーブルが存
在する。したがって、カラオケ端末１０毎に、どの曲が
課金済みであるかが判るようになっている。

【００４８】なお、入力装置５５からは各種指令を入力
することができ、例えば、記憶装置５３に記憶された各
カラオケ端末１０毎の課金情報を基にして課金実績等を
作成させたり、それをプリンタ５９によって印刷させた
り、ＣＲＴ６１に表示させたりすることができる。

【００４９】次に、情報センタ３の構成及び機能につい
て説明する。情報センタ３は、図３に示すとおり、情報
通信網７を介してカラオケ端末１０と接続する通信制御
装置７７と、カラオケ端末１０に配信するカラオケ曲デ
ータを蓄積する記憶装置７３とを備え、これらが中央制
御装置としてのホストコンピュータ７１によって制御さ
れている。また、ホストコンピュータ７１には、入力装
置７５、プリンタ７９、ＣＲＴ８１などの各種機器が接
続されている。また、記憶装置７３には、カラオケ曲デ
ータの他に、ホストコンピュータ７１が作動するための
各種制御プログラム等も記憶されている。

【００５０】このように構成された情報センタ３は、カ
ラオケ曲データを、情報通信網７を介して各カラオケ端
末１０に対して送信する。この送信は、新曲データの追
加のために、数日おき程度のペースで情報センタ３側か
ら行われるが、例えばカラオケ端末１０側からの定期的
に（例えば１日１回）新曲問い合わせをし、その問い合
わせに応えて配信すべき新曲があれば配信処理をするよ
うにしてもよい。いずれにしても、結果としてカラオケ
曲情報が情報センタ３からカラオケ端末１０へと送信さ
れることになる。

【００５１】次に、上記構成を有する本実施例のシステ
ムにおける動作について説明する。まず、図４〜図８の
フローチャートに基づいて、カラオケ端末１０の作動を
説明する。電源が投入されると、このメインルーチンが
開始される。

【００５２】まず、最初のステップＳ１にて、通信制御
装置２７ａ，２８ｂのリセット等の装置全体の初期化を
行う。次に、Ｓ２にて、カラオケ端末１０の動作指定と
して、カラオケ演奏モードが指定されたか否かをチェッ
クする。カラオケ端末設置事業者によってカラオケ演奏
モードの指定があればＳ３へ移行し、同指定がなければ
Ｓ４へ移行する。

【００５３】Ｓ３では、サブルーチンをコールしてカラ
オケ演奏処理を行う。このカラオケ演奏処理を図５のフ
ローチャートにて説明する。本カラオケ演奏処理の最初
のステップＳ３０では、多目的入力キー３２からのキー
入力を待ち、キー入力があれば（Ｓ３０：ＹＥＳ）、Ｓ
３１にて、それがリクエスト番号の入力かどうかを判断
する。そして、リクエスト番号入力である場合には、Ｓ
３２に移行して、その曲がロック対象であるかどうかを
判断する。これは、上述した課金・使用実績テーブル
（図１１参照）の使用許可禁止フラグの項目において、
禁止フラグが設定されているかどうかで判断する。

【００５４】許可フラグが設定されている場合にはＳ３
３へ移行して、そのリクエストされた番号の曲の演奏を
実行するが、禁止フラグが設定されている場合には、ロ
ック対象であるので、Ｓ３５へ移行し、テレビモニタ２
９に利用不可であることを示す表示をする。このＳ３３
あるいはＳ３５の処理の後でＳ３４へ移行する。

【００５５】一方、Ｓ３１にてリクエスト番号入力でな
いと判断された場合には、Ｓ３６にて、その他のキー入
力に応じた処理を実行してからＳ３４へ移行する。Ｓ３
４ではカラオケモード終了の指示があったかどうかを判
断し、終了指示がない場合にはＳ３０へ戻り、終了指示
があった場合には、本カラオケ演奏処理を終了して、図
４のフローチャートのＳ４へ移行する。

【００５６】Ｓ４では、カラオケ端末１０の動作指定と
して、カラオケ端末設置事業者により曲情報リクエスト
モードが指定されたか否かをチェックする。曲情報リク
エストモードの指定があればＳ５へ移行し、同指定がな
ければＳ６へ移行する。Ｓ５では、サブルーチンをコー
ルして曲情報リクエスト処理を行う。この曲情報リクエ
スト処理を図６のフローチャートにて説明する。

【００５７】本曲情報リクエスト処理は、未課金である
ため禁止フラグが設定され使用不可となっている曲情報
について、所定の課金処理を実行させて使用可能にする
ための処理であり、最初のステップＳ５０では、禁止フ
ラグが設定され使用不可となっている曲情報の一覧をテ
レビモニタ２９に表示させる。この際、「課金を希望す
る曲を指定して下さい」といった選択を促す表示も出す
とよい。カラオケ端末１０の設置事業者は、この曲情報
一覧から所望の曲を１曲以上選択し、選択終了を指示す
る。選択が終了すると（Ｓ５１：ＹＥＳ）、課金センタ
１と課金通信網５を通じて接続する（Ｓ５２）。課金セ
ンタ１との接続処理終了後、Ｓ５３へ移行する。

【００５８】Ｓ５３では、選択された曲についての課金
を課金センタ１に対して要求する。そして、続くＳ５４
では、課金要求に対する応答として、課金センタ１から
送信される課金情報の受信を行なう。この課金情報の受
信処理が完了したら、Ｓ５５へ移行し、課金センタ１と
の接続解除処理を行う。

【００５９】Ｓ５５での接続解除処理が終了すると、Ｓ
５６にて、上記選択された曲情報について課金・使用実
績テーブル（図１１参照）の課金状態の項目に「課金済
み」と設定し、Ｓ５７では、その「課金済み」と設定さ
れた曲情報、つまり選択された曲情報についての使用許
可禁止フラグの項目に許可フラグを設定して、その曲情
報の使用が可能な状態にする。

【００６０】この後、本曲情報リクエスト処理を一旦終
了して、図４のフローチャートのＳ６のステップへ移行
する。Ｓ６では、カラオケ端末１０の動作指定として、
新曲問い合わせのための所定時刻であるかどうかをチェ
ックする。これは、新曲のデータをなるべく早く取得す
るため、例えば１日に１回、情報センタ３から配信すべ
き曲データがあるかどうかを問い合わせるためのもので
ある。新曲問い合わせのための所定時刻であればＳ７へ
移行して曲情報削除処理を実行した後、Ｓ８へ移行して
新曲問い合わせ処理を実行する。また、新曲問い合わせ
の所定時刻でなければＳ２へ移行する。

【００６１】Ｓ７では、サブルーチンをコールして曲情
報削除処理を行う。この曲情報削除処理は、これから新
曲を受ける可能性があるので、その前にハードディスク
３３の空き容量をチェックしておき、もし空き容量が十
分でなければ記憶されているカラオケ曲情報を必要度の
低いものから削除して、空き容量を確保するための処理
である。この曲情報削除処理を図７のフローチャートに
て説明する。

【００６２】最初のステップＳ７０で、ハードディスク
３３の空き容量が所定量未満かどうかを判断する。Ｓ７
０で否定判断、すなわちハードディスク３３の空き容量
が所定量以上確保されている場合には、この状態で新曲
のカラオケ曲情報を受信してもなんら支障がないため、
Ｓ７１以降の処理を実行することなく、本曲情報削除処
理を終了して、図４のフローチャートのＳ８へ移行す
る。

【００６３】一方、ハードディスク３３の空き容量が所
定量未満である場合には（Ｓ７０：ＹＥＳ）、Ｓ７１へ
移行する。Ｓ７１では、課金・使用実績テーブル（図１
１参照）の課金状態の項を参照して、未課金である曲を
探す。これは、例えばテーブルのレコード番号順に見て
いき、図１１の場合でいけば曲番号「０００２」のもの
が最初に該当する。

【００６４】したがって、この場合にはＳ７２で未課金
曲ありと判断され（Ｓ７２：ＹＥＳ）Ｓ７３へ移行す
る。Ｓ７３では、その未課金状態が長期間続いているか
どうかを判断するため、受信日からα日以上経過してい
るかどうかを判断する。未課金の場合は使用禁止フラグ
が設定されているのでリクエストされることはなく、受
信日または最終リクエスト日の項は必ず受信日となる。
そのため、その受信日を見て、α日以上経過しているか
どうかを判断するのである。

【００６５】例えば、α＝１８０として、およそ６か月
以上未課金状態が続いているものは削除してもよいと
し、例えば平成７年４月１日にこの処理を実行したとす
ると、上記曲番号「０００２」のものの受信日は平成４
年１月７日なので、Ｓ７３で肯定判断となって、Ｓ７４
へ移行する。

【００６６】Ｓ７４では、ハードディスク３３に記憶さ
れているそのカラオケ曲情報を削除する。そして、続く
Ｓ７５では、課金・使用実績テーブル中から対応するレ
コードを削除して、Ｓ７０へ戻る。こうして、例えばま
ず曲番号「０００２」のカラオケ曲情報をハードディス
ク３３から削除し、課金・使用実績テーブル中からも対
応するレコードを削除して、Ｓ７０で再度ハードディス
ク３３の空き容量が所定量未満かどうかを判断する。

【００６７】そして、まだハードディスク３３の空き容
量が所定量未満の場合には、Ｓ７１以下の処理を繰り返
す。図１１の例でいけば、続いて曲番号「０００５」の
カラオケ曲情報が削除され、次いで曲番号「００１
４」，「００１５」のカラオケ曲情報が削除候補とな
る。これら２曲が削除されてもまだＳ７０で肯定判断と
なる場合には、曲番号「００２１」のカラオケ曲情報が
削除候補となるが、これは受信日が平成７年１月１４日
で１８０日以上経過していないので、Ｓ７３で否定判断
となる。なお、受信日から所定期間が経過していない場
合には削除しないとしたのは、これらの曲については今
後図４のＳ５に示した曲情報リクエスト処理が実行され
て、課金済みと設定される可能性がまだ十分にあるとの
判断に基づくものである。

【００６８】このように受信日から所定期間が経過して
いない曲の場合には、Ｓ７１〜Ｓ７３のループを繰り返
すだけとなるので、制御上、例えばＳ７３で否定判断と
なった曲については、Ｓ７１における未課金曲であると
の判断対象から除外することとする。このようにして、
未課金曲で受信日からα日以上経過しているものについ
て全て削除してもまだハードディスク３３の空き容量が
所定量未満の場合には、Ｓ７２で否定判断となり、Ｓ７
６へ移行する。

【００６９】Ｓ７６以降では、今度は課金済みであって
も一度もリクエストされていなかったり、あるいは少な
くとも一度はリクエストされていても、その後長期間に
わたってリクエストがされていない曲は必要度も相対的
に低いと見なして削除する。なお、以降の説明のため、
未課金曲で受信日からα日以上経過しているものについ
て全て削除した状態の課金・使用実績テーブルを図１２
に示す。

【００７０】Ｓ７６では、まず課金・使用実績テーブル
（図１２）についてレコード順に検査していくためｎ＝
１とし、続くＳ７７で、そのレコードの受信日または最
終リクエスト日を読み出す。例えば、図１２に示す場合
では、最初のレコードである曲番号「０００１」につい
ての受信日または最終リクエスト日は平成６年１月７日
である。

【００７１】そして、続くＳ７８では、一度もリクエス
トされていない状態が長期間続いているかどうかを判断
するため、受信日または最終リクエスト日からβ日以上
経過しているかどうかを判断する。例えば、β＝１８０
として、およそ６か月以上リクエストされない状態が続
いているものは削除してもよいとし、例えば平成７年４
月１日にこの処理を実行したとすると、上記曲番号「０
００１」のものの受信日または最終リクエスト日は平成
６年１月７日なので、Ｓ７８で肯定判断となって、Ｓ７
４へ移行する。

【００７２】Ｓ７４では、ハードディスク３３に記憶さ
れているそのカラオケ曲情報を削除する。そして、続く
Ｓ７５では、課金・使用実績テーブル中から対応するレ
コードを削除して、Ｓ７０へ戻る。こうして、例えばま
ず曲番号「０００１」のカラオケ曲情報をハードディス
ク３３から削除し、課金・使用実績テーブル（この場合
は図１２参照）中からも対応するレコードを削除して、
Ｓ７０で再度ハードディスク３３の空き容量が所定量未
満かどうかを判断する。

【００７３】そして、まだハードディスク３３の空き容
量が所定量未満の場合には、Ｓ７１以下の処理を繰り返
す。具体的には、再度Ｓ７６へ移行し、続くＳ７７で最
初のレコードの受信日または最終リクエスト日を読み出
すのであるが、この場合には図１２に示す状態から曲番
号「０００１」のレコードが削除されているので、最初
のレコードは曲番号「０００３」のものとなる。Ｓ７７
では読みだされる日は平成６年１１月２４日である。こ
れは、使用回数の項に「１」とあることからも判るよう
に、平成６年１１月２４日に一度リクエストされたこと
がある。

【００７４】この場合にはβ日以上経過していないので
（Ｓ７８：ＮＯ）、Ｓ７９へ移行する。Ｓ７９では、次
のレコードを検査するため、ｎをインクリメント（ｎ←
ｎ＋１）して、Ｓ７７へ戻る。こうして、順番にレコー
ドを検査してくのであるが、図１２に示す場合で説明す
ると、曲番号「０００４」，「０００６」，「０００
７」の３つについてはいずれもβ日以上経過していない
ので削除されず、その次の曲番号「０００８」の受信日
または最終リクエスト日がβ日以上経過しているので、
削除されることとなる。

【００７５】このように本曲情報削除処理においては、
まず未課金曲で受信日からα日以上経過しているカラオ
ケ曲情報について削除し、該当するものを全て削除して
もまだハードディスク３３の空き容量が所定量未満の場
合には、課金済みであってもβ日以上リクエストがされ
たことがないカラオケ曲情報を削除して、ハードディス
ク３３が所定量以上の空き容量を備えるように制御する
のである。

【００７６】こうして曲情報削除処理が終了すると、図
４のフローチャートのＳ８へ移行する。Ｓ８では、サブ
ルーチンをコールして新曲問い合わせ・受信処理を行
う。この新曲問い合わせ・受信処理について図８のフロ
ーチャートを参照して説明する。

【００７７】新曲問い合わせ・受信処理の最初のステッ
プＳ８０では、情報通信網７を介して情報センタ３と接
続する。情報センタ３との接続処理終了後、Ｓ８１へ移
行する。Ｓ８１では、新曲の有無を情報センタ３に問い
合わせ、Ｓ８２でその問い合わせに対する回答を受信す
る。その回答により、配信すべき新曲データが有ると判
断された場合には（Ｓ８３：ＹＥＳ）、Ｓ８４へ移行し
て、その配信すべき新曲を全曲取得する要求を情報セン
タ３に送信する。続くＳ８５では、その全曲取得要求に
対する応答として、情報センタ３から送信される新曲に
かかるカラオケ曲情報を受信して内蔵のハードディスク
３３へセーブする。このハードディスク３３へのセーブ
が完了したら、Ｓ８６へ移行し、情報センタ３との接続
解除処理を行う。

【００７８】なお、Ｓ８３にて、配信すべき新曲データ
が無いと判断された場合には（Ｓ８３：ＮＯ）、Ｓ８７
へ移行して新曲データ無しを記憶してから、Ｓ８６へ移
行する。この場合、新曲データが無い旨をテレビモニタ
２９に表示するようにしてもよい。

【００７９】Ｓ８６での情報センタ３との接続解除の完
了後、図４のフローチャートのＳ２へ移行する。以上が
カラオケ端末１０の中央制御装置３１の作動であり、カ
ラオケ演奏、カラオケ曲情報を使用可能とするための課
金情報の要求、曲情報削除、及び配信された新曲に係る
カラオケ曲情報の受信の各処理を行う。

【００８０】次に、課金センタ１の作動を図９のフロー
チャートを基に説明する。課金センタ１では、電源投入
後、Ｓ１００のステップから実行する。Ｓ１００では、
通信制御装置５７のリセット等の装置全体の初期化を行
う。Ｓ１００の処理を終了後、Ｓ１０１へ移行する。

【００８１】Ｓ１０１では、カラオケ端末１０からの接
続要求があるかどうか調べる。あればＳ１０２へ移行
し、なければＳ１０１の処理を繰り返し、待機状態とな
る。Ｓ１０２では、カラオケ端末１０からの接続要求に
対して同カラオケ端末１０との接続を行う。接続完了
後、Ｓ１０３へ移行する。

【００８２】Ｓ１０３では、カラオケ端末１０からの課
金要求情報を受信する。課金要求情報とは、図６に示す
Ｓ５３において要求される情報であり、未課金であるた
め禁止フラグが設定され使用不可となっているカラオケ
曲情報を使用可能とするために、所定の課金処理の実行
を要求するものである。

【００８３】Ｓ１０４では、その要求に応じて所定の課
金情報を該当するカラオケ端末１０に送信する。送信完
了後、Ｓ１０５へ移行する。Ｓ１０５では、接続中のカ
ラオケ端末１０との接続を解除する。接続解除完了後、
Ｓ１０１へ移行する。

【００８４】以上が課金センタ１のホストコンピュータ
５１の作動であり、カラオケ端末１０から課金要求情報
を受け取り、その内容を参照した上で、所定の課金情報
を送信する処理を行う。なお、この処理は、図６に示す
カラオケ端末１０側での曲情報リクエスト処理との関連
で実行されるものであり、両者の通信処理について、図
１３の通信シーケンス図を参照して説明する。

【００８５】カラオケ端末１０が課金センタ１に対して
発呼し、接続できた後にパスワードを課金センタ１に送
信する。課金センタ１では、通信制御装置５７を介して
これを受け取り、ホストコンピュータ５１が電話番号や
パスワード等で端末照合を行い、課金センタ１に登録さ
れているカラオケ端末１０であれば、照合正常を返送す
る。カラオケ端末１０はこの照合正常を受信して課金セ
ンタ１が受付可能状態となって後に、上記選択された曲
についての課金情報要求を送信するのである。

【００８６】この課金情報要求は所定の情報提供料を課
金するために行われるのであるが、この場合の情報提供
料は、カラオケ端末１０側で決定し、その料金に基づく
課金情報が送信されるように課金センタ１に要求しても
よいし、あるいは選択された曲情報を課金センタ１に送
信し、その曲情報に基づく料金の決定は課金センタ１側
に任せ、その決定した料金での課金情報が送信されるよ
うに要求してもよい。

【００８７】なお、課金通信網５を構成する料金徴収代
行システムでは、どのカラオケ端末１０が課金センタ１
から課金通信網５を介して課金情報が送信されたかを課
金実績として取得する。この課金実績に基づき、予め登
録されている料金リストを参照して算出した情報提供料
金を、電話事業者は、該当するカラオケ端末１０の設置
事業者に対する電話料金請求時にこれに上乗せする形で
徴収し、情報提供者である曲情報配信事業者へと渡すサ
ービスを行っている。これ自体は、ＮＴＴで行っている
ビデオテックスとしてよく知られているものである。

【００８８】そして、電話事業者側において実際に料金
が徴収されると、その徴収実績は課金センタ１の記憶装
置５３に記憶される。つまり、課金センタ１の記憶装置
５３には、図１１と似たテーブル（上述したように使用
許可禁止フラグや使用回数の項目は不要であるために無
く、受信日または最終リクエスト日の項目には配信日が
記憶されている。）が各カラオケ端末１０に対応して格
納されており、カラオケ端末１０からの課金要求があれ
ば、課金情報を送信すると共に、該当する曲情報の課金
状態を課金済みに設定する。

【００８９】次に、情報センタ３の作動を図１０のフロ
ーチャートに基づいて説明する。情報センタ３では、電
源投入後、Ｓ１２０のステップから実行する。Ｓ１２０
では、通信制御装置７７のリセット等の装置全体の初期
化を行う。そして、Ｓ１２１へ移行し、カラオケ端末１
０から接続要求があるかどうかを調べる。あればＳ１２
２へ移行し、なければＳ１２１の処理を繰り返し、待機
状態となる。

【００９０】Ｓ１２２では、カラオケ端末１０からの接
続要求に対して当該カラオケ端末１０との接続を行う。
接続完了後、Ｓ１２３へ移行する。Ｓ１２３では、カラ
オケ端末１０からの新曲有無の問い合わせを受信し、Ｓ
１２４でその回答を送信する。その回答が新曲データ無
しの場合には（Ｓ１２５：ＮＯ）、上述したようにカラ
オケ端末１０側でもそのまま回線接続が切断され、その
後の通信が必要でなくなるため、当該カラオケ端末１０
との接続を解除して（Ｓ１４０）、Ｓ１２１へ戻る。

【００９１】一方、回答が新曲データ有りの場合には
（Ｓ１２５：ＹＥＳ）、カラオケ端末１０からの要求が
あるのでそれを受信する（Ｓ１２６）。上記図８のＳ８
４で説明したように、この要求は全曲取得の要求である
ため、続くＳ１２７では、配信すべき新曲に係るカラオ
ケ曲情報を全部送信する。

【００９２】こうしてＳ１２８で新曲データの送信が完
了したら、Ｓ１２９へ移行し、当該カラオケ端末１０と
の接続を解除する。接続解除処理が完了後、Ｓ１２１へ
移行し、上記の処理を繰り返す。以上が情報センタ３の
ホストコンピュータ７１の作動であり、カラオケ端末１
０からの新曲問い合わせに対して、配信すべき新曲デー
タがあれば、それを配信する処理を実行する。

【００９３】なお、この処理は、図８に示すカラオケ端
末１０側での新曲問い合わせ・受信処理との関連で実行
されるものであり、両者の通信処理について、図１４の
通信シーケンス図を参照して説明する。カラオケ端末１
０が情報通信網７を介して情報センタ３に対して発呼
し、接続できた後にパスワードを情報センタ３に送信す
る。

【００９４】情報センタ３では、通信制御装置７７を介
してこれを受け取り、ホストコンピュータ７１が電話番
号やパスワード等で端末照合を行い、情報センタ３に登
録されているカラオケ端末１０であれば、照合正常を返
送する。カラオケ端末１０はこの照合正常を受信して情
報センタ３が受付可能状態となって後に、新曲有無の問
い合わせを行なう。

【００９５】情報センタ３では、この問い合わせを受け
付けて当該カラオケ端末１０に対する新曲データを検索
し、問い合わせの回答をカラオケ端末１０に送信する。
つまり、新曲データが有るか無いかを示す回答である。
カラオケ端末１０では、この回答結果に基づいて新曲デ
ータが有るか無いか判断し、新曲データが有る場合には
情報センタ３に対して新曲データの全曲取得要求を送信
する。そして、この要求を受信した情報センタ３は、該
当する新曲データすなわちカラオケ曲情報をカラオケ端
末１０に送信する。これを受信してセーブしたカラオケ
端末１０は情報センタ３との接続を切断する。

【００９６】以上説明した本実施例によれば、カラオケ
端末１０において、ハードディスク３３が記憶している
所定のカラオケ曲情報の内、課金通信網５から課金情報
を受信し、使用許可フラグの設定された曲情報について
のみカラオケ演奏に使用可能とされている。

【００９７】このように、課金済みであるカラオケ曲情
報のみがカラオケ演奏処理に使用できるようになるので
あるが、例えば、カラオケ端末１０の設置事業者の意図
によって未課金のまま放置されるカラオケ曲も生じる可
能性がある。つまり、そのカラオケ曲情報はその端末設
置事業者にとっては不要あるいは必要度があまり高くな
いので、あえて料金を支払ってまで使用可能とするもの
でもないと考える場合には、未課金のままとなる。例え
ば、ある特定のジャンルしか必要ない、あるいはある特
定のジャンルについては不要だと考えて、記憶されてい
るカラオケ曲情報を全て使用可能にするのではなく、自
分が必要だと考えるカラオケ曲情報についてのみ、その
料金を支払って使用可能にすることは十分に考えられ
る。

【００９８】すると、例えば、新曲を随時追加していく
ようなシステムであるので、必要度の低いカラオケ曲情
報が記憶されていることで、相対的に必要度の高い新曲
については記憶させられなくなったり、あるいは、この
必要度の低いカラオケ曲情報も含めて記憶するために、
必要以上に大型のハードディスク３３を準備しなくては
ならないという問題が生じる。

【００９９】これに対して、本実施例のカラオケ端末１
０では、新曲を受信する前に、ハードディスク３３の空
き容量を判断し、新曲を受信するためには空き容量が十
分でない場合には、カラオケ曲情報毎に必要度を判断し
て、必要度が低いものから削除していくのである。これ
により、ハードディスク３３の空き容量が増し、ハード
ディスク３３を必要以上に大型化させることなく、半永
久的に新曲の受信が可能となるのである。

【０１００】なお、上記実施例では、未課金であること
と、長期間リクエストがないことを要因として削除する
データを決定したが、図１１のテーブルに示した使用回
数、つまりリクエストされた回数を削除データの決定の
際に考慮することも考えられる。つまり、一見使用され
ていない期間が長くても、長期的に見た場合に、コンス
タントにされており、その使用回数はトータルで多くな
る場合もある。また、逆に使用回数は少なくても、その
カラオケ曲情報の受信時期あるいは課金時期が最近であ
る場合には、使用回数が少なくても当然であるので、所
定期間使用されていない、あるいは使用回数が少ないと
いうだけで単純に必要度が低いと判断するのではなく、
例えば使用されてない期間と使用頻度等を総合的に分析
して必要度を判断するようにすることが好ましい。

【０１０１】また、削除されたカラオケ曲情報について
も今後必要となる場合も想定されるので、その場合の対
処として、例えば、削除したレコードを記憶しておき、
そこから所望のカラオケ曲情報を選択して情報センタ３
に配信を要求できるようにしておくとことよい。

【０１０２】以上本発明はこの様な実施例に何等限定さ
れるものではなく、本発明の要旨を逸脱しない範囲にお
いて種々なる態様で実施し得る。例えば、上記実施例で
は、新曲のカラオケ曲情報は情報通信網７を用いて送信
していたが、課金通信網５を用いても送信するようにし
てもよい。但し、上記実施例のように、情報通信網７を
課金通信網５とは異なる通信網として、その情報通信網
７によってカラオケ曲情報を送信する場合には、次の点
で特に優れた作用・効果を奏する。すなわち、カラオケ
曲情報は、情報量のかなり大きなものとなる場合が想定
されるが、そういった大きな情報そのものを配信する場
合には、その配信に適した通信網を利用することが好ま
しい。これは、課金通信網５を利用してカラオケ曲情報
自体を配信するよりも迅速であったり、データの信頼性
が高かったりするという点で、カラオケ端末１０が受け
取るべき情報の種類に応じた最適なシステム構成が可能
となるからである。

【０１０３】さらに、新曲を追加していくのに情報通信
網７を用い、いわゆるオンラインで送信するようにした
が、本発明の情報提供端末としては、上記実施例のよう
な通信式カラオケシステムにおけるカラオケ端末１０に
は限らない。例えば、スタンドアロンタイプのものであ
って、新曲の追加を例えば曲配信事業者のサービスマン
が直接出向いて、ハードディスク３３に追加記憶させる
ような場合でも、不要なカラオケ曲情報を削除すること
は、新曲を追加する場合に、その追加ができなくなるこ
とを防止する等、上述したオンラインの場合と同様の効
果を奏する。

【０１０４】また、本発明の適用対象は、通信式カラオ
ケシステムに限らず、ゲームソフトの配信ネットワーク
等として適用してもよいことはいうまでもない。

【図面の簡単な説明】

【図１】 実施例の通信式情報提供システムをカラオケ
に関するシステムに適用した場合の概略構成図である。

【図２】 実施例のシステムの構成要素であるカラオケ
端末の構成を示すブロック図である。

【図３】 実施例のシステムの構成要素である課金セン
タ及び情報センタの構成を示すブロック図である。

【図４】 実施例のカラオケ端末におけるメイン処理を
示すフローチャートである。

【図５】 実施例のカラオケ端末におけるカラオケ演奏
処理を示すフローチャートである。

【図６】 実施例のカラオケ端末における曲情報リクエ
スト処理を示すフローチャートである。

【図７】 実施例のカラオケ端末における曲情報削除処
理を示すフローチャートである。

【図８】 実施例のカラオケ端末における新曲問い合わ
せ・受信処理を示すフローチャートである。

【図９】 実施例の課金センタにおけるメイン処理を示
すフローチャートである。

【図１０】 実施例の情報センタにおけるメイン処理を
示すフローチャートである。

【図１１】 実施例のカラオケ端末のハードディスクに
格納された課金・使用実績テーブルの説明図である。

【図１２】 同じく課金・使用実績テーブルの説明図で
あり、削除が実行された後の状態を示す説明図である。

【図１３】 実施例の曲情報リクエスト処理における通
信シーケンス図である。

【図１４】 実施例の新曲問い合わせ及び新曲送受信処
理における通信シーケンス図である。

【符号の説明】

１…課金センタ ３…情報センタ ５…課金通信網 ７…情報通信網 １０…カラオケ端末 ２６…画面表示制
御装置 ２７ａ…第１通信制御装置 ２７ｂ…第２通信制
御装置 ２９…テレビモニタ ３１…中央制御装
置 ３２…多目的入力キー ３３…ハードディ
スク ３５…音声再生回路 ３８…ミキサアン
プ ４１…スピーカ ４３…マイクロフ
ォン ５１，７１…ホストコンピュータ ５３，７３…記憶
装置 ５５，７５…入力装置 ５７，７７…通信
制御装置 ５９，７９…プリンタ ６１，８１…ＣＲ
Ｔ

Claims (7)

【特許請求の範囲】
1. 【請求項１】 サービス提供用の情報を記憶している情
   報記憶手段と、 該情報記憶手段に記憶されたサービス提供用情報を用い
   て所定の情報提供サービスを実行可能な情報提供実行手
   段と、 前記情報記憶手段に記憶されたサービス提供用情報毎
   に、課金済みであるか未課金であるかを記憶しておく課
   金状態記憶手段と、 該課金状態記憶手段において課金済みであると記憶され
   ているサービス提供用情報についてのみ、前記情報提供
   実行手段による情報提供サービス処理への使用を許可す
   る使用許可手段とを備えた情報提供端末であって、 前記情報記憶手段に記憶されたサービス提供用情報毎
   に、必要度を判断する判断手段と、 所定の削除実行条件が成立した場合には、該判断手段に
   よって必要度が低いと判断されたサービス提供用情報
   を、前記情報記憶手段より削除する情報削除手段とを備
   えていることを特徴とする情報提供端末。
2. 【請求項２】 請求項１に記載の情報提供端末におい
   て、 前記情報記憶手段における空き容量が所定量より少なく
   なった場合に前記所定の削除実行条件が成立したと判断
   し、前記情報削除手段は、前記情報記憶手段における空
   き容量が所定量以上となるまで、必要度が低いと判断さ
   れたサービス提供用情報を削除することを特徴とする情
   報提供端末。
3. 【請求項３】 請求項１または２に記載の情報提供端末
   において、 前記判断手段は、前記課金状態記憶手段に記憶されてい
   る課金済みであるか未課金であるかの情報に基づいて、
   前記サービス提供用情報毎に必要度を判断することを特
   徴とする情報提供端末。
4. 【請求項４】 請求項１または２に記載の情報提供端末
   において、 前記判断手段は、前記情報提供実行手段による所定の情
   報提供サービスの実行のために使用されていない期間に
   基づいて、前記サービス提供用情報毎に必要度を判断す
   ることを特徴とする情報提供端末。
5. 【請求項５】 請求項１または２に記載の情報提供端末
   において、 前記判断手段は、前記情報提供実行手段による所定の情
   報提供サービスの実行頻度に基づいて、前記サービス提
   供用情報毎に必要度を判断することを特徴とする情報提
   供端末。
6. 【請求項６】 請求項１〜５のいずれかに記載の情報提
   供端末と、 該情報提供端末に対し、課金通信網を介して課金情報を
   送信可能な課金センタとを備え、該課金センタが前記課
   金通信網を介して課金情報を送信することによって、前
   記課金通信網の課金機能による課金がなされると共に、
   前記情報提供端末の課金状態記憶手段においては、その
   送信された課金情報に対応するサービス提供用情報が課
   金済みであると記憶されることを特徴とする通信式情報
   提供システム。
7. 【請求項７】 請求項６に記載の通信式情報提供システ
   ムであって、 前記情報提供端末に対し、情報通信網を介してスクラン
   ブル情報の付加されたサービス提供用情報を送信可能な
   情報センタを備え、 前記情報提供端末の使用許可手段は、情報センタから送
   信されて情報記憶手段に記憶されたサービス提供用情報
   の内、課金状態記憶手段に課金済みであると記憶された
   情報についてのみ、スクランブル情報を解除して情報提
   供サービス処理への使用を許可することを特徴とする通
   信式情報提供システム。