JP3638661B2 - 情報提供端末及び該端末を備えた通信式情報提供システム - Google Patents
情報提供端末及び該端末を備えた通信式情報提供システム Download PDFInfo
- Publication number
- JP3638661B2 JP3638661B2 JP10863195A JP10863195A JP3638661B2 JP 3638661 B2 JP3638661 B2 JP 3638661B2 JP 10863195 A JP10863195 A JP 10863195A JP 10863195 A JP10863195 A JP 10863195A JP 3638661 B2 JP3638661 B2 JP 3638661B2
- Authority
- JP
- Japan
- Prior art keywords
- information
- charging
- terminal
- karaoke
- song
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【産業上の利用分野】
本発明は、情報記憶手段に記憶されたサービス提供用情報としてカラオケ曲情報を用いて所定の情報提供サービスを実行する場合に、課金状態記憶手段において課金済みであると記憶されたもののみ、その情報提供サービス処理への使用を許可するようにした情報提供端末及びその端末を備えた通信式情報提供システムに関する。
【０００２】
【従来の技術】
従来より、情報記憶手段にサービス提供用情報を記憶しているが、その全てを使用できるのはなく、その対価である所定料金の課金処理が済んだサービス提供用情報についてのみ所定の情報提供サービス処理のために使用可能とするものが提案されている。例えば、スクランブル情報を付加することで、そのままでは使用不可能な状態でサービス提供用情報としてのカラオケ曲情報を記憶させた記憶媒体（レーザディスクやＣＤ等）を情報提供端末としてのカラオケ端末にセットし、ビデオテックス通信網等を用いた所定の課金処理が実行されると、その課金金額に応じてスクランブル情報を解除するための解除キーが送信され、カラオケ曲情報が使用可能となるもの等である。
【０００３】
また、上記スクランブル情報の付加されたカラオケ曲情報を情報センタからオンラインで送信してカラオケ端末の情報記憶手段に記憶させ、上記例と同様に、ビデオテックス通信網等を用いた所定の課金処理に伴って受信した解除キーで、カラオケ曲情報を使用可能とするものも出願人は提案している。例えば、カラオケ端末の設置時には、内蔵のハードディスクに既にリリースされている数千曲程度のカラオケ曲情報を記憶させておき、その後順次リリースされる新曲については、その都度オンラインで送信し、曲数を充実させていくというものである。
【０００４】
【発明が解決しようとする課題】
しかしながら、このように新曲を自動的に送信して曲数を増やしていく方式を採用すると、いずれは情報記憶手段の記憶容量の限界に達してしまい、その後の新曲については受信して記憶させることができなくなってしまう。あるいは、そのような事態を考慮して大容量の情報記憶手段を準備しておくことも考えられるが、そのためには非常に大型の情報記憶手段を準備する必要があり、装置の大型化及びコストアップにつながる。
【０００５】
また、上述したように課金が済んで初めて使用可能にする手法を採用した場合には、カラオケ曲情報自体は記憶されておりながら、実際のカラオケ演奏には使用されないという事態が生じる可能性がある。つまり、カラオケ端末の設置事業者が、例えばある特定のジャンルしか必要ない、あるいはある特定のジャンルについては不要だと考えて、記憶されているカラオケ曲情報を全て使用可能にするのではなく、自分が必要だと考えるカラオケ曲情報についてのみ、その料金を支払って使用可能にすることが考えられる。
【０００６】
すると、必要度の低いカラオケ曲情報が記憶されていることが原因で、相対的に必要度の高い新曲については記憶させられなくなることも考えられる。あるいは、この必要度の低いカラオケ曲情報も含めて記憶するためには、必要以上に大型の情報記憶手段を準備しなくてはならない。このように、新しいカラオケ曲情報を追加して記憶させていきたい場合に、必要度の低いカラオケ曲情報の存在によって新曲の追加が不可能であったり必要以上に情報記憶手段が大型化してしまうという問題が生じるのである。
【０００７】
そこで、本発明は、内蔵する情報記憶手段を必要以上に大型化させることなく、半永久的に新しいサービス提供用情報としてカラオケ曲情報をその情報記憶手段に追加記憶させることが可能な情報提供端末及びその情報提供端末を備えた通信式情報提供システムを提供することを目的とする。
【０００８】
【課題を解決するための手段、作用及び発明の効果】
上記目的を解決するためになされた請求項１に記載の発明は、
サービス提供用情報としてカラオケ曲情報を記憶している情報記憶手段と、該情報記憶手段に記憶されたサービス提供用情報を用いて所定の情報提供サービスを実行可能な情報提供実行手段と、前記情報記憶手段に記憶されたサービス提供用情報毎に、課金済みであるか未課金であるかを記憶しておく課金状態記憶手段と、該課金状態記憶手段において課金済みであると記憶されているサービス提供用情報についてのみ、前記情報提供実行手段による情報提供サービス処理への使用を許可する使用許可手段とを備えた情報提供端末であって、前記情報記憶手段に記憶されたサービス提供用情報毎に、前記課金状態記憶手段に記憶されている課金済みであるか未課金であるかの情報に基づいて、必要度を判断する判断手段と、所定の削除実行条件が成立した場合には、該判断手段によって必要度が低いと判断されたサービス提供用情報を、前記情報記憶手段より削除する情報削除手段とを備えていることを特徴とする情報提供端末である。
【０００９】
この情報提供端末は、情報記憶手段に記憶しているサービス提供用情報としてカラオケ曲情報を用いて所定の情報提供サービス処理を実行することができるのであるが、情報記憶手段が記憶しているサービス提供用情報であれば、どれも無条件に使用して情報提供サービス処理を実行できるのではない。つまり、課金状態記憶手段が、情報記憶手段に記憶されたサービス提供用情報毎に課金済みであるか未課金であるかを記憶しており、使用許可手段は、課金状態記憶手段において課金済みであると記憶されている情報についてのみ、情報提供実行手段による情報提供サービス処理への使用を許可するのである。
【００１０】
具体的には、例えば、未課金の場合にはスクランブル情報を付加した状態でサービス提供用情報としてカラオケ曲情報を記憶させ、そのままでは実質的に情報提供サービス処理に使用できないような状態にしておき、課金済みとなれば、そのスクランブル情報を解除することで使用許可することが考えられる。また、スクランブル情報の付加といったようにサービス提供用情報自体を使用不可にしておくのではなく、サービス提供用情報自体は物理的には使用可能であっても、課金状態が未課金である場合（例えばフラグ等で区別する）には、そのサービス提供用情報を使用する情報提供サービスがリクエストされても受け付けないように制御してもよい。
【００１１】
このように、課金済みであるサービス提供用情報のみが情報提供サービス処理に使用できるようになるのであるが、例えば、情報提供端末の設置事業者の意図によって未課金のまま放置されるサービス提供用情報も生じる可能性がある。つまり、そのサービス提供用情報はその設置事業者にとっては不要あるいは必要度があまり高くないので、あえて料金を支払ってまで使用可能とするものでもないと考える場合には、未課金のままとなる。例えば、情報提供端末をカラオケ端末に適用した場合で考えると、設置事業者が、例えばある特定のジャンルしか必要ない、あるいはある特定のジャンルについては不要だと考えて、記憶されているカラオケ曲情報を全て使用可能にするのではなく、自分が必要だと考えるカラオケ曲情報についてのみ、その料金を支払って使用可能にすることは十分に考えられる。
【００１２】
すると、例えば、新曲を随時追加していくようなシステムを採用している場合には、必要度の低いカラオケ曲情報が記憶されているのに、相対的に必要度の高い新曲については記憶させられなくなったり、あるいは、この必要度の低いカラオケ曲情報も含めて記憶するために、必要以上に大型の情報記憶手段を準備しなくてはならないという問題が生じる。
【００１３】
そこで、本情報提供端末においては、以下のように対処する。
つまり、判断手段によって、情報記憶手段に記憶されたサービス提供用情報毎に、課金状態記憶手段に記憶されている課金済みであるか未課金であるかの情報に基づいて、必要度を判断することができ、所定の削除実行条件が成立した場合には、情報削除手段が、その判断手段によって必要度が低いと判断されたサービス提供用情報を情報記憶手段より削除するのである。
【００１４】
この「所定の削除実行条件が成立した場合」については、例えば請求項２に示すように、情報記憶手段における空き容量が所定量より少なくなった場合に所定の削除実行条件が成立したと判断することが考えられる。そして、その場合に、情報削除手段は、情報記憶手段における空き容量が所定量以上となるまで、必要度が低いと判断されたサービス提供用情報を削除する。
【００１５】
このように、必要度が低いと判断されたサービス提供用情報としてカラオケ曲情報が情報記憶手段より削除されることで、情報記憶手段の空き容量が増すのである。例えば請求項２の場合であれば、常に情報記憶手段における空き容量が所定量以上となるようにすることができる。したがって、内蔵する情報記憶手段を必要以上に大型化させることなく、半永久的に新しいサービス提供用情報としてカラオケ曲情報をその情報記憶手段に追加記憶させることが可能となるのである。
【００１６】
【００１７】
【００１８】
【００１９】
【００２０】
【００２１】
【００２２】
以上は、情報提供端末についてであったが、この情報提供端末を備えた通信式情報提供システムとしては以下のものが考えられる。
請求項３に示す通信式情報提供システムは、請求項１または２に記載の情報提供端末と、該情報提供端末に対し、課金通信網を介して課金情報を送信可能な課金センタとを備え、該課金センタが前記課金通信網を介して課金情報を送信することによって、前記課金通信網の課金機能による課金がなされると共に、前記情報提供端末の課金状態記憶手段においては、その送信された課金情報に対応するサービス提供用情報が課金済みであると記憶されることを特徴とする。
【００２３】
請求項１または２に示した情報提供端末においては、課金あるいは実際の料金徴収については特に限定せず、課金状態記憶手段が、サービス提供用情報としてカラオケ曲情報毎に課金済みであるか未課金であるかを記憶しておく点を明示した。したがって、例えば、サービス提供用情報提供者側のサービスマン等が、直接その情報提供端末の設置された場所まで出向き、設置事業者の要求に応じて課金済みに設定すると共に、その料金を徴収してもよいが、このような方法では非常に面倒である。
【００２４】
そこで、請求項３に示すものでは、課金センタが課金通信網を介して課金情報を送信することによって課金通信網の課金機能による課金がなされると共に、課金状態記憶手段においては、その送信された課金情報に対応するサービス提供用情報が課金済みであると記憶されるようにした。このようにすれば、例えば情報提供端末の設置事業者が課金を実行させてサービス提供用情報としてカラオケ曲情報を使用可能にしたいと考えたときには、その指示をするだけで課金通信網による課金機能を利用した課金がなされ、サービス提供用情報を使用可能にするための対価を、人の手を煩わさずに自動的に回収することが可能となるため、非常に便利である。
【００２５】
なお、この課金処理を実行する際には、まず課金センタと情報提供端末とを課金通信網を介して接続する必要がある。ここで、現行のキャプテンシステムやダイヤルキューツーなどの課金通信網では発呼側（電話をかけた側）に課金することとなっているので、情報提供端末側から課金センタをコールして接続することになる。しかし、既に公衆電話回線においても実用化されているように、コレクトコール方式で着呼側（電話を受けた側）に課金するように課金通信網の構成を変更することは可能である。よって、ここでの接続は、情報提供端末側に課金される限りは、情報提供端末側が発呼するものであっても課金センタ側が発呼するものであっても構わない。
【００２６】
また、情報記憶手段が記憶するサービス提供用情報の出所についても、上記情報提供端末の説明では特に限定していない。したがって、例えば、サービス提供用情報を記憶させた記憶媒体（ＬＤやＣＤ、あるいはハードディスク等）を情報提供端末にセットして情報記憶手段として機能させてもよいし、オンラインで受信してもよい。
【００２７】
このオンラインでサービス提供用情報を受信するようにした通信式情報提供システムの一例が請求項４に示すものである。すなわち、その構成は、請求項３に記載の通信式情報提供システムであって、前記情報提供端末に対し、情報通信網を介してスクランブル情報の付加されたサービス提供用情報を送信可能な情報センタを備え、前記情報提供端末の使用許可手段は、情報センタから送信されて情報記憶手段に記憶されたサービス提供用情報の内、課金状態記憶手段に課金済みであると記憶された情報についてのみ、スクランブル情報を解除して情報提供サービス処理への使用を許可することを特徴とする。
【００２８】
なお、サービス提供用情報としてカラオケ曲情報は先に送信しておき、その後、課金処理が済んだものだけ使用可能にするものであるため、先に送信するサービス提供用情報を未課金であるにもかかわらず不正に使用される可能性もある。したがって、情報センタから送信する時点ではスクランブル情報を付加しておき、課金が済んだものについては、スクランブルを解除するための暗号解読キーを受信することによって使用可能とすることが好ましい。
【００２９】
また、本システムにおいて、情報通信網と課金通信網とを異なる通信網とすれば、次の点で特に優れた作用・効果を奏する。
即ち、情報提供端末において情報提供サービスに用いるサービス提供用情報はカラオケ曲情報であり情報量のかなり大きなものとなる場合が想定されるが、そういった大きな情報そのものを情報センタから配信する場合には、その配信に適した通信網を利用することが好ましい。つまり、課金通信網を利用してサービス提供用情報自体を配信するよりも迅速であったり、データの信頼性が高かったりするという点で、情報提供端末が受け取るべき情報の種類に応じた最適なシステム構成が可能となるからである。
【００３０】
ここまでの説明でも判る通り、本発明の通信式情報提供システムにおける課金センタと情報センタは、別々の独立したセンタとして存在してもよいし、一つのセンタの中に両機能を備えさせておいてもよい。いずれにしても情報提供端末に対して情報の配信が可能な情報通信網の方を介して接続されたときに情報センタとしての機能を発揮でき、課金通信網の方を介して接続されたときに課金センタとしての機能が発揮でき、課金センタとしての機能を有する部分による課金の完了が何等かの手段によって情報センタとしての機能を有する部分に伝達される限りは、両センタが別体であろうと一体であろうと構わないのである。即ち、本発明においては、情報センタと課金センタは概念として分けて表現されているだけであって物として分かれている場合だけを意味するわけではない。
【００３１】
【実施例】
以下、本発明を具体化した一実施例を図面を参照して説明する。
図１は、実施例の通信式情報提供システムをカラオケに関するシステムに適用した場合の概略構成図、図２はそのシステムの構成要素である情報提供端末としてのカラオケ端末１０の構成を示すブロック図である。
【００３２】
図１に示すように、本実施例のシステムは、課金関連処理を担当する課金センタ１と複数のカラオケ端末１０とが、課金通信網５を介して接続されていると共に、カラオケ曲情報の送信関連処理を担当する情報センタ３と複数のカラオケ端末１０とが、情報通信網７を介して接続されて構成されている。また、課金センタ１と情報センタ３との間も接続されている。
【００３３】
課金通信網５は、例えばビデオテックス通信網やダイヤルキューツー通信網のように、情報料に対して課金する機能を持つものである。現在の日本国内では、ビデオテックス網とダイヤルキューツー網がその代表的なものとして知られておいる。ダイヤルキューツー網は基本的に時間単位の従量計算であり、ビデオテックス網は、情報の内容毎に任意の料金を設定可能であり、いわゆるキャプテンシステム等に用いられている。
【００３４】
その課金機能の一例として、ビデオテックス通信網について説明すると、ビデオテックス通信網は、具体的には例えば各カラオケ端末１０に接続された公衆電話回線とビデオテックス通信処理装置とで構成されている。このビデオテックス通信処理装置が、ビデオテックス通信網にアクセスしようとしている公衆電話回線の課金センタ１への接続・交換、利用者装置であるカラオケ端末１０の管理及び課金センタ１への加入者管理、通信料及び電話会社が代理徴収する情報提供料の課金、カラオケ端末１０と課金センタ１との間の会話制御、プロトコル変換やコード／パターン変換などの変換処理等の通信処理機能を提供する。
【００３５】
続いてカラオケ端末１０の構成について、図２を参照して説明する。使用許可手段、判断手段及び情報削除手段等に相当する中央制御装置３１には、各種指示入力を行なうための入力手段としての多目的入力キー３２、情報記憶手段としてのハードディスク３３、音声再生回路３５、画面表示制御装置２６、情報通信網７と接続可能な第１通信制御装置２７ａ及び課金通信網５と接続可能な第２通信制御装置２７ｂとを備えている。また、音声再生回路３５にはミキサアンプ３８が、画面表示制御装置２６には表示手段としてのテレビモニタ２９がそれぞれ接続されている。また、ミキサアンプ３８にはスピーカ４１とマイクロフォン４３が接続されている。
【００３６】
そして、この中央制御装置３１は所定の課金制御処理を実行する。この課金制御処理については後で詳しく説明するが、従来の課金通信網５の利用方法とは異なるので、その点を説明しておく。従来は、利用者端末がこの課金通信網５を介して情報を受信し、その情報を用いて所定の処理を実行する。そして、課金通信網５はその情報の代金として所定の料金（情報内容毎に設定された所定料金）を課金することとなる。
【００３７】
それに対して、本実施例では、カラオケ端末１０がカラオケ演奏処理に用いる情報は、ハードディスク３３が記憶している。ハードディスク３３には予め数千曲程度のカラオケ曲情報が記憶されている。なお、カラオケ端末１０は、カラオケ端末設置事業者の管理であり、新しい曲データがリリースされる毎に曲データ配信事業者から曲データの供給を受けることができる。本実施例のシステムでは、第１通信制御装置２７ａを介して情報通信網７と接続し、情報センタ３からその新曲データを受信して、ハードディスク３３に後から記憶させることができるようにされている。
【００３８】
なお、前記ハードディスク３３に記憶されるカラオケ曲情報は、曲同士を識別するための識別情報である曲番号情報と、実体情報とから構成されている。この内の実体情報は、伴奏音楽の情報であるＭＩＤＩ（Musical Instrument Digital Interface）規格の演奏情報や、歌詞情報及び背景映像情報からなっている。背景映像情報は曲毎に対応した映像情報を符号化したものである。
【００３９】
そして、このカラオケ曲情報はそのままでは使用できないようにされている。使用するためには、課金通信網５に第２通信制御装置２７ｂを通して接続し、中央制御装置３１が課金制御プログラムを実行することによって、課金通信網５による課金機能を利用した所定の課金処理が行われて、カラオケ曲情報を使用することができる状態となる。
【００４０】
例えば、未課金状態ではカラオケ曲情報にスクランブル情報を付加しておき、そのままでは使用できなくしてある場合に、課金処理によって解除キーを配信してもらい、その解除キーによってスクランブル情報を解除することで使用許可することが考えられる。また、スクランブル情報の付加といったようにカラオケ曲情報自体を使用不可にしておくのではなく、カラオケ曲情報自体は物理的には使用可能であっても、課金状態が未課金である場合には、使用禁止フラグを設定しておき、そのカラオケ曲情報がリクエストされても受け付けないような制御をするようにしてもよい。そして、課金済みとなると、その使用禁止フラグを使用可能フラグに変更するといったような制御をすれば実現できる。
【００４１】
本実施例では、課金・使用実績テーブル中において、曲毎に使用可能フラグあるいは使用禁止フラグのいずれかが設定されており、そのフラグに応じて使用を許可したり、禁止したりするようにされている。図１１には、ハードディスク３３に格納されたその課金・使用実績テーブルを示す。カラオケ曲情報毎に、その曲番号・曲名・そのカラオケ曲情報に対する料金・課金日・課金状態・使用許可禁止フラグ・受信日または最終リクエスト日・使用回数の項目からなるテーブルが存在する。
【００４２】
ここで、受信日または最終リクエスト日とは、カラオケ曲情報を受信してから一度もリクエストされずにカラオケ演奏処理に使用されてしない場合には、受信日が記憶され、リクエストがあってカラオケ演奏処理に使用された場合には、そのリクエスト毎に更新されていき、最後にリクエストがあった日がここに記憶されることとなる。また、使用回数とは、リクエストによってカラオケ演奏として使用された回数である。
【００４３】
また、課金状態とは、所定の課金処理が済んでいる「課金済み」か課金処理が済んでいない「未課金」かのいずれかである。そして、使用許可禁止フラグとしては、上述したように許可か禁止のフラグが設定されるのであるが、これはまず、課金状態が「未課金」の場合には、禁止フラグが設定されて曲の使用ができないロック状態とされている。そして、所定の課金処理によって「課金済み」となると許可フラグが設定されてロック状態が解除され、曲情報は自由に使用できるようになる。
【００４４】
上記許可フラグが設定されて、カラオケ曲情報が使用できるようになると、利用者は多目的入力キー３２を操作することで歌いたい曲を選択する。すると中央制御装置３１は、所定のカラオケ演奏プログラムに従って、カラオケ演奏処理を実行する。簡単に説明すると、中央制御装置３１は、選択された曲に対応する演奏情報、歌詞情報および背景映像情報をハードディスク３３から読み出し、演奏情報は音声再生回路３５に、歌詞情報および背景映像情報は画面表示制御装置２６にそれぞれ転送する。
【００４５】
音声再生回路３５に出力された演奏情報は、アナログの演奏信号に変換された後、ミキサアンプ３８へ送られて電気的に増幅されるとともに、マイクロフォン４３を介して入力する利用者の歌声と適度な割合でミキシングされる。ミキシングされた音声信号は、スピーカ４１により演奏音として外部へ出力される。
【００４６】
一方、演奏情報と同期して出力される歌詞情報は、画面表示制御装置２６において、後述する背景映像信号と合成（スーパーインポーズ）されてテレビモニタ２９に表示される。これにより、テレビモニタ２９には、背景映像に歌詞テロップが合成された状態で表示される。
【００４７】
続いて、課金センタ１の構成を図３を参照して説明する。
課金センタ１は、ホストコンピュータ５１と、記憶装置５３と、入力装置５５と、通信制御装置５７と、プリンタ５９と、ＣＲＴ６１とを備えている。前記記憶装置５３は、ホストコンピュータ５１が作動するための各種制御プログラムや、前記各カラオケ端末１０毎の課金実績等を記憶するためのものである。つまり、図１１に示した課金・使用実績テーブルに似たものが、各カラオケ端末１０に対応して記憶されているのである。詳しくは、図１１に示したデータ項目の内の使用許可禁止フラグは記憶しておく必要がないので、その使用許可禁止フラグの項目を除く。また受信日または最終リクエスト日の項目には配信日が記憶される。そして使用回数の項目はない。すなわち、カラオケ曲情報毎に、その曲番号・曲名・そのカラオケ曲情報に対する料金・課金日・課金状態・配信日の項目からなるテーブルが存在する。したがって、カラオケ端末１０毎に、どの曲が課金済みであるかが判るようになっている。
【００４８】
なお、入力装置５５からは各種指令を入力することができ、例えば、記憶装置５３に記憶された各カラオケ端末１０毎の課金情報を基にして課金実績等を作成させたり、それをプリンタ５９によって印刷させたり、ＣＲＴ６１に表示させたりすることができる。
【００４９】
次に、情報センタ３の構成及び機能について説明する。
情報センタ３は、図３に示すとおり、情報通信網７を介してカラオケ端末１０と接続する通信制御装置７７と、カラオケ端末１０に配信するカラオケ曲データを蓄積する記憶装置７３とを備え、これらが中央制御装置としてのホストコンピュータ７１によって制御されている。また、ホストコンピュータ７１には、入力装置７５、プリンタ７９、ＣＲＴ８１などの各種機器が接続されている。また、記憶装置７３には、カラオケ曲データの他に、ホストコンピュータ７１が作動するための各種制御プログラム等も記憶されている。
【００５０】
このように構成された情報センタ３は、カラオケ曲データを、情報通信網７を介して各カラオケ端末１０に対して送信する。この送信は、新曲データの追加のために、数日おき程度のペースで情報センタ３側から行われるが、例えばカラオケ端末１０側からの定期的に（例えば１日１回）新曲問い合わせをし、その問い合わせに応えて配信すべき新曲があれば配信処理をするようにしてもよい。いずれにしても、結果としてカラオケ曲情報が情報センタ３からカラオケ端末１０へと送信されることになる。
【００５１】
次に、上記構成を有する本実施例のシステムにおける動作について説明する。まず、図４〜図８のフローチャートに基づいて、カラオケ端末１０の作動を説明する。
電源が投入されると、このメインルーチンが開始される。
【００５２】
まず、最初のステップＳ１にて、通信制御装置２７ａ，２８ｂのリセット等の装置全体の初期化を行う。次に、Ｓ２にて、カラオケ端末１０の動作指定として、カラオケ演奏モードが指定されたか否かをチェックする。カラオケ端末設置事業者によってカラオケ演奏モードの指定があればＳ３へ移行し、同指定がなければＳ４へ移行する。
【００５３】
Ｓ３では、サブルーチンをコールしてカラオケ演奏処理を行う。このカラオケ演奏処理を図５のフローチャートにて説明する。
本カラオケ演奏処理の最初のステップＳ３０では、多目的入力キー３２からのキー入力を待ち、キー入力があれば（Ｓ３０：ＹＥＳ）、Ｓ３１にて、それがリクエスト番号の入力かどうかを判断する。そして、リクエスト番号入力である場合には、Ｓ３２に移行して、その曲がロック対象であるかどうかを判断する。これは、上述した課金・使用実績テーブル（図１１参照）の使用許可禁止フラグの項目において、禁止フラグが設定されているかどうかで判断する。
【００５４】
許可フラグが設定されている場合にはＳ３３へ移行して、そのリクエストされた番号の曲の演奏を実行するが、禁止フラグが設定されている場合には、ロック対象であるので、Ｓ３５へ移行し、テレビモニタ２９に利用不可であることを示す表示をする。このＳ３３あるいはＳ３５の処理の後でＳ３４へ移行する。
【００５５】
一方、Ｓ３１にてリクエスト番号入力でないと判断された場合には、Ｓ３６にて、その他のキー入力に応じた処理を実行してからＳ３４へ移行する。Ｓ３４ではカラオケモード終了の指示があったかどうかを判断し、終了指示がない場合にはＳ３０へ戻り、終了指示があった場合には、本カラオケ演奏処理を終了して、図４のフローチャートのＳ４へ移行する。
【００５６】
Ｓ４では、カラオケ端末１０の動作指定として、カラオケ端末設置事業者により曲情報リクエストモードが指定されたか否かをチェックする。曲情報リクエストモードの指定があればＳ５へ移行し、同指定がなければＳ６へ移行する。
Ｓ５では、サブルーチンをコールして曲情報リクエスト処理を行う。この曲情報リクエスト処理を図６のフローチャートにて説明する。
【００５７】
本曲情報リクエスト処理は、未課金であるため禁止フラグが設定され使用不可となっている曲情報について、所定の課金処理を実行させて使用可能にするための処理であり、最初のステップＳ５０では、禁止フラグが設定され使用不可となっている曲情報の一覧をテレビモニタ２９に表示させる。この際、「課金を希望する曲を指定して下さい」といった選択を促す表示も出すとよい。カラオケ端末１０の設置事業者は、この曲情報一覧から所望の曲を１曲以上選択し、選択終了を指示する。選択が終了すると（Ｓ５１：ＹＥＳ）、課金センタ１と課金通信網５を通じて接続する（Ｓ５２）。課金センタ１との接続処理終了後、Ｓ５３へ移行する。
【００５８】
Ｓ５３では、選択された曲についての課金を課金センタ１に対して要求する。そして、続くＳ５４では、課金要求に対する応答として、課金センタ１から送信される課金情報の受信を行なう。この課金情報の受信処理が完了したら、Ｓ５５へ移行し、課金センタ１との接続解除処理を行う。
【００５９】
Ｓ５５での接続解除処理が終了すると、Ｓ５６にて、上記選択された曲情報について課金・使用実績テーブル（図１１参照）の課金状態の項目に「課金済み」と設定し、Ｓ５７では、その「課金済み」と設定された曲情報、つまり選択された曲情報についての使用許可禁止フラグの項目に許可フラグを設定して、その曲情報の使用が可能な状態にする。
【００６０】
この後、本曲情報リクエスト処理を一旦終了して、図４のフローチャートのＳ６のステップへ移行する。
Ｓ６では、カラオケ端末１０の動作指定として、新曲問い合わせのための所定時刻であるかどうかをチェックする。これは、新曲のデータをなるべく早く取得するため、例えば１日に１回、情報センタ３から配信すべき曲データがあるかどうかを問い合わせるためのものである。新曲問い合わせのための所定時刻であればＳ７へ移行して曲情報削除処理を実行した後、Ｓ８へ移行して新曲問い合わせ処理を実行する。また、新曲問い合わせの所定時刻でなければＳ２へ移行する。
【００６１】
Ｓ７では、サブルーチンをコールして曲情報削除処理を行う。この曲情報削除処理は、これから新曲を受ける可能性があるので、その前にハードディスク３３の空き容量をチェックしておき、もし空き容量が十分でなければ記憶されているカラオケ曲情報を必要度の低いものから削除して、空き容量を確保するための処理である。この曲情報削除処理を図７のフローチャートにて説明する。
【００６２】
最初のステップＳ７０で、ハードディスク３３の空き容量が所定量未満かどうかを判断する。Ｓ７０で否定判断、すなわちハードディスク３３の空き容量が所定量以上確保されている場合には、この状態で新曲のカラオケ曲情報を受信してもなんら支障がないため、Ｓ７１以降の処理を実行することなく、本曲情報削除処理を終了して、図４のフローチャートのＳ８へ移行する。
【００６３】
一方、ハードディスク３３の空き容量が所定量未満である場合には（Ｓ７０：ＹＥＳ）、Ｓ７１へ移行する。
Ｓ７１では、課金・使用実績テーブル（図１１参照）の課金状態の項を参照して、未課金である曲を探す。これは、例えばテーブルのレコード番号順に見ていき、図１１の場合でいけば曲番号「０００２」のものが最初に該当する。
【００６４】
したがって、この場合にはＳ７２で未課金曲ありと判断され（Ｓ７２：ＹＥＳ）Ｓ７３へ移行する。Ｓ７３では、その未課金状態が長期間続いているかどうかを判断するため、受信日からα日以上経過しているかどうかを判断する。未課金の場合は使用禁止フラグが設定されているのでリクエストされることはなく、受信日または最終リクエスト日の項は必ず受信日となる。そのため、その受信日を見て、α日以上経過しているかどうかを判断するのである。
【００６５】
例えば、α＝１８０として、およそ６か月以上未課金状態が続いているものは削除してもよいとし、例えば平成７年４月１日にこの処理を実行したとすると、上記曲番号「０００２」のものの受信日は平成４年１月７日なので、Ｓ７３で肯定判断となって、Ｓ７４へ移行する。
【００６６】
Ｓ７４では、ハードディスク３３に記憶されているそのカラオケ曲情報を削除する。そして、続くＳ７５では、課金・使用実績テーブル中から対応するレコードを削除して、Ｓ７０へ戻る。
こうして、例えばまず曲番号「０００２」のカラオケ曲情報をハードディスク３３から削除し、課金・使用実績テーブル中からも対応するレコードを削除して、Ｓ７０で再度ハードディスク３３の空き容量が所定量未満かどうかを判断する。
【００６７】
そして、まだハードディスク３３の空き容量が所定量未満の場合には、Ｓ７１以下の処理を繰り返す。図１１の例でいけば、続いて曲番号「０００５」のカラオケ曲情報が削除され、次いで曲番号「００１４」，「００１５」のカラオケ曲情報が削除候補となる。これら２曲が削除されてもまだＳ７０で肯定判断となる場合には、曲番号「００２１」のカラオケ曲情報が削除候補となるが、これは受信日が平成７年１月１４日で１８０日以上経過していないので、Ｓ７３で否定判断となる。なお、受信日から所定期間が経過していない場合には削除しないとしたのは、これらの曲については今後図４のＳ５に示した曲情報リクエスト処理が実行されて、課金済みと設定される可能性がまだ十分にあるとの判断に基づくものである。
【００６８】
このように受信日から所定期間が経過していない曲の場合には、Ｓ７１〜Ｓ７３のループを繰り返すだけとなるので、制御上、例えばＳ７３で否定判断となった曲については、Ｓ７１における未課金曲であるとの判断対象から除外することとする。
このようにして、未課金曲で受信日からα日以上経過しているものについて全て削除してもまだハードディスク３３の空き容量が所定量未満の場合には、Ｓ７２で否定判断となり、Ｓ７６へ移行する。
【００６９】
Ｓ７６以降では、今度は課金済みであっても一度もリクエストされていなかったり、あるいは少なくとも一度はリクエストされていても、その後長期間にわたってリクエストがされていない曲は必要度も相対的に低いと見なして削除する。なお、以降の説明のため、未課金曲で受信日からα日以上経過しているものについて全て削除した状態の課金・使用実績テーブルを図１２に示す。
【００７０】
Ｓ７６では、まず課金・使用実績テーブル（図１２）についてレコード順に検査していくためｎ＝１とし、続くＳ７７で、そのレコードの受信日または最終リクエスト日を読み出す。例えば、図１２に示す場合では、最初のレコードである曲番号「０００１」についての受信日または最終リクエスト日は平成６年１月７日である。
【００７１】
そして、続くＳ７８では、一度もリクエストされていない状態が長期間続いているかどうかを判断するため、受信日または最終リクエスト日からβ日以上経過しているかどうかを判断する。例えば、β＝１８０として、およそ６か月以上リクエストされない状態が続いているものは削除してもよいとし、例えば平成７年４月１日にこの処理を実行したとすると、上記曲番号「０００１」のものの受信日または最終リクエスト日は平成６年１月７日なので、Ｓ７８で肯定判断となって、Ｓ７４へ移行する。
【００７２】
Ｓ７４では、ハードディスク３３に記憶されているそのカラオケ曲情報を削除する。そして、続くＳ７５では、課金・使用実績テーブル中から対応するレコードを削除して、Ｓ７０へ戻る。
こうして、例えばまず曲番号「０００１」のカラオケ曲情報をハードディスク３３から削除し、課金・使用実績テーブル（この場合は図１２参照）中からも対応するレコードを削除して、Ｓ７０で再度ハードディスク３３の空き容量が所定量未満かどうかを判断する。
【００７３】
そして、まだハードディスク３３の空き容量が所定量未満の場合には、Ｓ７１以下の処理を繰り返す。具体的には、再度Ｓ７６へ移行し、続くＳ７７で最初のレコードの受信日または最終リクエスト日を読み出すのであるが、この場合には図１２に示す状態から曲番号「０００１」のレコードが削除されているので、最初のレコードは曲番号「０００３」のものとなる。Ｓ７７では読みだされる日は平成６年１１月２４日である。これは、使用回数の項に「１」とあることからも判るように、平成６年１１月２４日に一度リクエストされたことがある。
【００７４】
この場合にはβ日以上経過していないので（Ｓ７８：ＮＯ）、Ｓ７９へ移行する。Ｓ７９では、次のレコードを検査するため、ｎをインクリメント（ｎ←ｎ＋１）して、Ｓ７７へ戻る。こうして、順番にレコードを検査してくのであるが、図１２に示す場合で説明すると、曲番号「０００４」，「０００６」，「０００７」の３つについてはいずれもβ日以上経過していないので削除されず、その次の曲番号「０００８」の受信日または最終リクエスト日がβ日以上経過しているので、削除されることとなる。
【００７５】
このように本曲情報削除処理においては、まず未課金曲で受信日からα日以上経過しているカラオケ曲情報について削除し、該当するものを全て削除してもまだハードディスク３３の空き容量が所定量未満の場合には、課金済みであってもβ日以上リクエストがされたことがないカラオケ曲情報を削除して、ハードディスク３３が所定量以上の空き容量を備えるように制御するのである。
【００７６】
こうして曲情報削除処理が終了すると、図４のフローチャートのＳ８へ移行する。
Ｓ８では、サブルーチンをコールして新曲問い合わせ・受信処理を行う。この新曲問い合わせ・受信処理について図８のフローチャートを参照して説明する。
【００７７】
新曲問い合わせ・受信処理の最初のステップＳ８０では、情報通信網７を介して情報センタ３と接続する。情報センタ３との接続処理終了後、Ｓ８１へ移行する。
Ｓ８１では、新曲の有無を情報センタ３に問い合わせ、Ｓ８２でその問い合わせに対する回答を受信する。その回答により、配信すべき新曲データが有ると判断された場合には（Ｓ８３：ＹＥＳ）、Ｓ８４へ移行して、その配信すべき新曲を全曲取得する要求を情報センタ３に送信する。続くＳ８５では、その全曲取得要求に対する応答として、情報センタ３から送信される新曲にかかるカラオケ曲情報を受信して内蔵のハードディスク３３へセーブする。このハードディスク３３へのセーブが完了したら、Ｓ８６へ移行し、情報センタ３との接続解除処理を行う。
【００７８】
なお、Ｓ８３にて、配信すべき新曲データが無いと判断された場合には（Ｓ８３：ＮＯ）、Ｓ８７へ移行して新曲データ無しを記憶してから、Ｓ８６へ移行する。この場合、新曲データが無い旨をテレビモニタ２９に表示するようにしてもよい。
【００７９】
Ｓ８６での情報センタ３との接続解除の完了後、図４のフローチャートのＳ２へ移行する。
以上がカラオケ端末１０の中央制御装置３１の作動であり、カラオケ演奏、カラオケ曲情報を使用可能とするための課金情報の要求、曲情報削除、及び配信された新曲に係るカラオケ曲情報の受信の各処理を行う。
【００８０】
次に、課金センタ１の作動を図９のフローチャートを基に説明する。
課金センタ１では、電源投入後、Ｓ１００のステップから実行する。
Ｓ１００では、通信制御装置５７のリセット等の装置全体の初期化を行う。Ｓ１００の処理を終了後、Ｓ１０１へ移行する。
【００８１】
Ｓ１０１では、カラオケ端末１０からの接続要求があるかどうか調べる。あればＳ１０２へ移行し、なければＳ１０１の処理を繰り返し、待機状態となる。
Ｓ１０２では、カラオケ端末１０からの接続要求に対して同カラオケ端末１０との接続を行う。接続完了後、Ｓ１０３へ移行する。
【００８２】
Ｓ１０３では、カラオケ端末１０からの課金要求情報を受信する。課金要求情報とは、図６に示すＳ５３において要求される情報であり、未課金であるため禁止フラグが設定され使用不可となっているカラオケ曲情報を使用可能とするために、所定の課金処理の実行を要求するものである。
【００８３】
Ｓ１０４では、その要求に応じて所定の課金情報を該当するカラオケ端末１０に送信する。送信完了後、Ｓ１０５へ移行する。
Ｓ１０５では、接続中のカラオケ端末１０との接続を解除する。接続解除完了後、Ｓ１０１へ移行する。
【００８４】
以上が課金センタ１のホストコンピュータ５１の作動であり、カラオケ端末１０から課金要求情報を受け取り、その内容を参照した上で、所定の課金情報を送信する処理を行う。
なお、この処理は、図６に示すカラオケ端末１０側での曲情報リクエスト処理との関連で実行されるものであり、両者の通信処理について、図１３の通信シーケンス図を参照して説明する。
【００８５】
カラオケ端末１０が課金センタ１に対して発呼し、接続できた後にパスワードを課金センタ１に送信する。
課金センタ１では、通信制御装置５７を介してこれを受け取り、ホストコンピュータ５１が電話番号やパスワード等で端末照合を行い、課金センタ１に登録されているカラオケ端末１０であれば、照合正常を返送する。カラオケ端末１０はこの照合正常を受信して課金センタ１が受付可能状態となって後に、上記選択された曲についての課金情報要求を送信するのである。
【００８６】
この課金情報要求は所定の情報提供料を課金するために行われるのであるが、この場合の情報提供料は、カラオケ端末１０側で決定し、その料金に基づく課金情報が送信されるように課金センタ１に要求してもよいし、あるいは選択された曲情報を課金センタ１に送信し、その曲情報に基づく料金の決定は課金センタ１側に任せ、その決定した料金での課金情報が送信されるように要求してもよい。
【００８７】
なお、課金通信網５を構成する料金徴収代行システムでは、どのカラオケ端末１０が課金センタ１から課金通信網５を介して課金情報が送信されたかを課金実績として取得する。この課金実績に基づき、予め登録されている料金リストを参照して算出した情報提供料金を、電話事業者は、該当するカラオケ端末１０の設置事業者に対する電話料金請求時にこれに上乗せする形で徴収し、情報提供者である曲情報配信事業者へと渡すサービスを行っている。これ自体は、ＮＴＴで行っているビデオテックスとしてよく知られているものである。
【００８８】
そして、電話事業者側において実際に料金が徴収されると、その徴収実績は課金センタ１の記憶装置５３に記憶される。つまり、課金センタ１の記憶装置５３には、図１１と似たテーブル（上述したように使用許可禁止フラグや使用回数の項目は不要であるために無く、受信日または最終リクエスト日の項目には配信日が記憶されている。）が各カラオケ端末１０に対応して格納されており、カラオケ端末１０からの課金要求があれば、課金情報を送信すると共に、該当する曲情報の課金状態を課金済みに設定する。
【００８９】
次に、情報センタ３の作動を図１０のフローチャートに基づいて説明する。情報センタ３では、電源投入後、Ｓ１２０のステップから実行する。
Ｓ１２０では、通信制御装置７７のリセット等の装置全体の初期化を行う。そして、Ｓ１２１へ移行し、カラオケ端末１０から接続要求があるかどうかを調べる。あればＳ１２２へ移行し、なければＳ１２１の処理を繰り返し、待機状態となる。
【００９０】
Ｓ１２２では、カラオケ端末１０からの接続要求に対して当該カラオケ端末１０との接続を行う。接続完了後、Ｓ１２３へ移行する。
Ｓ１２３では、カラオケ端末１０からの新曲有無の問い合わせを受信し、Ｓ１２４でその回答を送信する。その回答が新曲データ無しの場合には（Ｓ１２５：ＮＯ）、上述したようにカラオケ端末１０側でもそのまま回線接続が切断され、その後の通信が必要でなくなるため、当該カラオケ端末１０との接続を解除して（Ｓ１４０）、Ｓ１２１へ戻る。
【００９１】
一方、回答が新曲データ有りの場合には（Ｓ１２５：ＹＥＳ）、カラオケ端末１０からの要求があるのでそれを受信する（Ｓ１２６）。上記図８のＳ８４で説明したように、この要求は全曲取得の要求であるため、続くＳ１２７では、配信すべき新曲に係るカラオケ曲情報を全部送信する。
【００９２】
こうしてＳ１２８で新曲データの送信が完了したら、Ｓ１２９へ移行し、当該カラオケ端末１０との接続を解除する。接続解除処理が完了後、Ｓ１２１へ移行し、上記の処理を繰り返す。
以上が情報センタ３のホストコンピュータ７１の作動であり、カラオケ端末１０からの新曲問い合わせに対して、配信すべき新曲データがあれば、それを配信する処理を実行する。
【００９３】
なお、この処理は、図８に示すカラオケ端末１０側での新曲問い合わせ・受信処理との関連で実行されるものであり、両者の通信処理について、図１４の通信シーケンス図を参照して説明する。
カラオケ端末１０が情報通信網７を介して情報センタ３に対して発呼し、接続できた後にパスワードを情報センタ３に送信する。
【００９４】
情報センタ３では、通信制御装置７７を介してこれを受け取り、ホストコンピュータ７１が電話番号やパスワード等で端末照合を行い、情報センタ３に登録されているカラオケ端末１０であれば、照合正常を返送する。カラオケ端末１０はこの照合正常を受信して情報センタ３が受付可能状態となって後に、新曲有無の問い合わせを行なう。
【００９５】
情報センタ３では、この問い合わせを受け付けて当該カラオケ端末１０に対する新曲データを検索し、問い合わせの回答をカラオケ端末１０に送信する。つまり、新曲データが有るか無いかを示す回答である。
カラオケ端末１０では、この回答結果に基づいて新曲データが有るか無いか判断し、新曲データが有る場合には情報センタ３に対して新曲データの全曲取得要求を送信する。そして、この要求を受信した情報センタ３は、該当する新曲データすなわちカラオケ曲情報をカラオケ端末１０に送信する。これを受信してセーブしたカラオケ端末１０は情報センタ３との接続を切断する。
【００９６】
以上説明した本実施例によれば、カラオケ端末１０において、ハードディスク３３が記憶している所定のカラオケ曲情報の内、課金通信網５から課金情報を受信し、使用許可フラグの設定された曲情報についてのみカラオケ演奏に使用可能とされている。
【００９７】
このように、課金済みであるカラオケ曲情報のみがカラオケ演奏処理に使用できるようになるのであるが、例えば、カラオケ端末１０の設置事業者の意図によって未課金のまま放置されるカラオケ曲も生じる可能性がある。つまり、そのカラオケ曲情報はその端末設置事業者にとっては不要あるいは必要度があまり高くないので、あえて料金を支払ってまで使用可能とするものでもないと考える場合には、未課金のままとなる。例えば、ある特定のジャンルしか必要ない、あるいはある特定のジャンルについては不要だと考えて、記憶されているカラオケ曲情報を全て使用可能にするのではなく、自分が必要だと考えるカラオケ曲情報についてのみ、その料金を支払って使用可能にすることは十分に考えられる。
【００９８】
すると、例えば、新曲を随時追加していくようなシステムであるので、必要度の低いカラオケ曲情報が記憶されていることで、相対的に必要度の高い新曲については記憶させられなくなったり、あるいは、この必要度の低いカラオケ曲情報も含めて記憶するために、必要以上に大型のハードディスク３３を準備しなくてはならないという問題が生じる。
【００９９】
これに対して、本実施例のカラオケ端末１０では、新曲を受信する前に、ハードディスク３３の空き容量を判断し、新曲を受信するためには空き容量が十分でない場合には、カラオケ曲情報毎に必要度を判断して、必要度が低いものから削除していくのである。これにより、ハードディスク３３の空き容量が増し、ハードディスク３３を必要以上に大型化させることなく、半永久的に新曲の受信が可能となるのである。
【０１００】
なお、上記実施例では、未課金であることと、長期間リクエストがないことを要因として削除するデータを決定したが、図１１のテーブルに示した使用回数、つまりリクエストされた回数を削除データの決定の際に考慮することも考えられる。つまり、一見使用されていない期間が長くても、長期的に見た場合に、コンスタントにされており、その使用回数はトータルで多くなる場合もある。また、逆に使用回数は少なくても、そのカラオケ曲情報の受信時期あるいは課金時期が最近である場合には、使用回数が少なくても当然であるので、所定期間使用されていない、あるいは使用回数が少ないというだけで単純に必要度が低いと判断するのではなく、例えば使用されてない期間と使用頻度等を総合的に分析して必要度を判断するようにすることが好ましい。
【０１０１】
また、削除されたカラオケ曲情報についても今後必要となる場合も想定されるので、その場合の対処として、例えば、削除したレコードを記憶しておき、そこから所望のカラオケ曲情報を選択して情報センタ３に配信を要求できるようにしておくとよい。
【０１０２】
以上本発明はこの様な実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲において種々なる態様で実施し得る。例えば、上記実施例では、新曲のカラオケ曲情報は情報通信網７を用いて送信していたが、課金通信網５を用いても送信するようにしてもよい。但し、上記実施例のように、情報通信網７を課金通信網５とは異なる通信網として、その情報通信網７によってカラオケ曲情報を送信する場合には、次の点で特に優れた作用・効果を奏する。すなわち、カラオケ曲情報は、情報量のかなり大きなものとなる場合が想定されるが、そういった大きな情報そのものを配信する場合には、その配信に適した通信網を利用することが好ましい。これは、課金通信網５を利用してカラオケ曲情報自体を配信するよりも迅速であったり、データの信頼性が高かったりするという点で、カラオケ端末１０が受け取るべき情報の種類に応じた最適なシステム構成が可能となるからである。
【０１０３】
さらに、新曲を追加していくのに情報通信網７を用い、いわゆるオンラインで送信するようにしたが、本発明の情報提供端末としては、上記実施例のような通信式カラオケシステムにおけるカラオケ端末１０には限らない。例えば、スタンドアロンタイプのものであって、新曲の追加を例えば曲配信事業者のサービスマンが直接出向いて、ハードディスク３３に追加記憶させるような場合でも、不要なカラオケ曲情報を削除することは、新曲を追加する場合に、その追加ができなくなることを防止する等、上述したオンラインの場合と同様の効果を奏する。
【０１０４】
また、本発明の適用対象は、通信式カラオケシステムに限らず、ゲームソフトの配信ネットワーク等として適用してもよいことはいうまでもない。
【図面の簡単な説明】
【図１】 実施例の通信式情報提供システムをカラオケに関するシステムに適用した場合の概略構成図である。
【図２】 実施例のシステムの構成要素であるカラオケ端末の構成を示すブロック図である。
【図３】 実施例のシステムの構成要素である課金センタ及び情報センタの構成を示すブロック図である。
【図４】 実施例のカラオケ端末におけるメイン処理を示すフローチャートである。
【図５】 実施例のカラオケ端末におけるカラオケ演奏処理を示すフローチャートである。
【図６】 実施例のカラオケ端末における曲情報リクエスト処理を示すフローチャートである。
【図７】 実施例のカラオケ端末における曲情報削除処理を示すフローチャートである。
【図８】 実施例のカラオケ端末における新曲問い合わせ・受信処理を示すフローチャートである。
【図９】 実施例の課金センタにおけるメイン処理を示すフローチャートである。
【図１０】 実施例の情報センタにおけるメイン処理を示すフローチャートである。
【図１１】 実施例のカラオケ端末のハードディスクに格納された課金・使用実績テーブルの説明図である。
【図１２】 同じく課金・使用実績テーブルの説明図であり、削除が実行された後の状態を示す説明図である。
【図１３】 実施例の曲情報リクエスト処理における通信シーケンス図である。
【図１４】 実施例の新曲問い合わせ及び新曲送受信処理における通信シーケンス図である。
【符号の説明】
１…課金センタ ３…情報センタ
５…課金通信網 ７…情報通信網
１０…カラオケ端末 ２６…画面表示制御装置
２７ａ…第１通信制御装置 ２７ｂ…第２通信制御装置
２９…テレビモニタ ３１…中央制御装置
３２…多目的入力キー ３３…ハードディスク
３５…音声再生回路 ３８…ミキサアンプ
４１…スピーカ ４３…マイクロフォン
５１，７１…ホストコンピュータ ５３，７３…記憶装置
５５，７５…入力装置 ５７，７７…通信制御装置
５９，７９…プリンタ ６１，８１…ＣＲＴ
【産業上の利用分野】
本発明は、情報記憶手段に記憶されたサービス提供用情報としてカラオケ曲情報を用いて所定の情報提供サービスを実行する場合に、課金状態記憶手段において課金済みであると記憶されたもののみ、その情報提供サービス処理への使用を許可するようにした情報提供端末及びその端末を備えた通信式情報提供システムに関する。
【０００２】
【従来の技術】
従来より、情報記憶手段にサービス提供用情報を記憶しているが、その全てを使用できるのはなく、その対価である所定料金の課金処理が済んだサービス提供用情報についてのみ所定の情報提供サービス処理のために使用可能とするものが提案されている。例えば、スクランブル情報を付加することで、そのままでは使用不可能な状態でサービス提供用情報としてのカラオケ曲情報を記憶させた記憶媒体（レーザディスクやＣＤ等）を情報提供端末としてのカラオケ端末にセットし、ビデオテックス通信網等を用いた所定の課金処理が実行されると、その課金金額に応じてスクランブル情報を解除するための解除キーが送信され、カラオケ曲情報が使用可能となるもの等である。
【０００３】
また、上記スクランブル情報の付加されたカラオケ曲情報を情報センタからオンラインで送信してカラオケ端末の情報記憶手段に記憶させ、上記例と同様に、ビデオテックス通信網等を用いた所定の課金処理に伴って受信した解除キーで、カラオケ曲情報を使用可能とするものも出願人は提案している。例えば、カラオケ端末の設置時には、内蔵のハードディスクに既にリリースされている数千曲程度のカラオケ曲情報を記憶させておき、その後順次リリースされる新曲については、その都度オンラインで送信し、曲数を充実させていくというものである。
【０００４】
【発明が解決しようとする課題】
しかしながら、このように新曲を自動的に送信して曲数を増やしていく方式を採用すると、いずれは情報記憶手段の記憶容量の限界に達してしまい、その後の新曲については受信して記憶させることができなくなってしまう。あるいは、そのような事態を考慮して大容量の情報記憶手段を準備しておくことも考えられるが、そのためには非常に大型の情報記憶手段を準備する必要があり、装置の大型化及びコストアップにつながる。
【０００５】
また、上述したように課金が済んで初めて使用可能にする手法を採用した場合には、カラオケ曲情報自体は記憶されておりながら、実際のカラオケ演奏には使用されないという事態が生じる可能性がある。つまり、カラオケ端末の設置事業者が、例えばある特定のジャンルしか必要ない、あるいはある特定のジャンルについては不要だと考えて、記憶されているカラオケ曲情報を全て使用可能にするのではなく、自分が必要だと考えるカラオケ曲情報についてのみ、その料金を支払って使用可能にすることが考えられる。
【０００６】
すると、必要度の低いカラオケ曲情報が記憶されていることが原因で、相対的に必要度の高い新曲については記憶させられなくなることも考えられる。あるいは、この必要度の低いカラオケ曲情報も含めて記憶するためには、必要以上に大型の情報記憶手段を準備しなくてはならない。このように、新しいカラオケ曲情報を追加して記憶させていきたい場合に、必要度の低いカラオケ曲情報の存在によって新曲の追加が不可能であったり必要以上に情報記憶手段が大型化してしまうという問題が生じるのである。
【０００７】
そこで、本発明は、内蔵する情報記憶手段を必要以上に大型化させることなく、半永久的に新しいサービス提供用情報としてカラオケ曲情報をその情報記憶手段に追加記憶させることが可能な情報提供端末及びその情報提供端末を備えた通信式情報提供システムを提供することを目的とする。
【０００８】
【課題を解決するための手段、作用及び発明の効果】
上記目的を解決するためになされた請求項１に記載の発明は、
サービス提供用情報としてカラオケ曲情報を記憶している情報記憶手段と、該情報記憶手段に記憶されたサービス提供用情報を用いて所定の情報提供サービスを実行可能な情報提供実行手段と、前記情報記憶手段に記憶されたサービス提供用情報毎に、課金済みであるか未課金であるかを記憶しておく課金状態記憶手段と、該課金状態記憶手段において課金済みであると記憶されているサービス提供用情報についてのみ、前記情報提供実行手段による情報提供サービス処理への使用を許可する使用許可手段とを備えた情報提供端末であって、前記情報記憶手段に記憶されたサービス提供用情報毎に、前記課金状態記憶手段に記憶されている課金済みであるか未課金であるかの情報に基づいて、必要度を判断する判断手段と、所定の削除実行条件が成立した場合には、該判断手段によって必要度が低いと判断されたサービス提供用情報を、前記情報記憶手段より削除する情報削除手段とを備えていることを特徴とする情報提供端末である。
【０００９】
この情報提供端末は、情報記憶手段に記憶しているサービス提供用情報としてカラオケ曲情報を用いて所定の情報提供サービス処理を実行することができるのであるが、情報記憶手段が記憶しているサービス提供用情報であれば、どれも無条件に使用して情報提供サービス処理を実行できるのではない。つまり、課金状態記憶手段が、情報記憶手段に記憶されたサービス提供用情報毎に課金済みであるか未課金であるかを記憶しており、使用許可手段は、課金状態記憶手段において課金済みであると記憶されている情報についてのみ、情報提供実行手段による情報提供サービス処理への使用を許可するのである。
【００１０】
具体的には、例えば、未課金の場合にはスクランブル情報を付加した状態でサービス提供用情報としてカラオケ曲情報を記憶させ、そのままでは実質的に情報提供サービス処理に使用できないような状態にしておき、課金済みとなれば、そのスクランブル情報を解除することで使用許可することが考えられる。また、スクランブル情報の付加といったようにサービス提供用情報自体を使用不可にしておくのではなく、サービス提供用情報自体は物理的には使用可能であっても、課金状態が未課金である場合（例えばフラグ等で区別する）には、そのサービス提供用情報を使用する情報提供サービスがリクエストされても受け付けないように制御してもよい。
【００１１】
このように、課金済みであるサービス提供用情報のみが情報提供サービス処理に使用できるようになるのであるが、例えば、情報提供端末の設置事業者の意図によって未課金のまま放置されるサービス提供用情報も生じる可能性がある。つまり、そのサービス提供用情報はその設置事業者にとっては不要あるいは必要度があまり高くないので、あえて料金を支払ってまで使用可能とするものでもないと考える場合には、未課金のままとなる。例えば、情報提供端末をカラオケ端末に適用した場合で考えると、設置事業者が、例えばある特定のジャンルしか必要ない、あるいはある特定のジャンルについては不要だと考えて、記憶されているカラオケ曲情報を全て使用可能にするのではなく、自分が必要だと考えるカラオケ曲情報についてのみ、その料金を支払って使用可能にすることは十分に考えられる。
【００１２】
すると、例えば、新曲を随時追加していくようなシステムを採用している場合には、必要度の低いカラオケ曲情報が記憶されているのに、相対的に必要度の高い新曲については記憶させられなくなったり、あるいは、この必要度の低いカラオケ曲情報も含めて記憶するために、必要以上に大型の情報記憶手段を準備しなくてはならないという問題が生じる。
【００１３】
そこで、本情報提供端末においては、以下のように対処する。
つまり、判断手段によって、情報記憶手段に記憶されたサービス提供用情報毎に、課金状態記憶手段に記憶されている課金済みであるか未課金であるかの情報に基づいて、必要度を判断することができ、所定の削除実行条件が成立した場合には、情報削除手段が、その判断手段によって必要度が低いと判断されたサービス提供用情報を情報記憶手段より削除するのである。
【００１４】
この「所定の削除実行条件が成立した場合」については、例えば請求項２に示すように、情報記憶手段における空き容量が所定量より少なくなった場合に所定の削除実行条件が成立したと判断することが考えられる。そして、その場合に、情報削除手段は、情報記憶手段における空き容量が所定量以上となるまで、必要度が低いと判断されたサービス提供用情報を削除する。
【００１５】
このように、必要度が低いと判断されたサービス提供用情報としてカラオケ曲情報が情報記憶手段より削除されることで、情報記憶手段の空き容量が増すのである。例えば請求項２の場合であれば、常に情報記憶手段における空き容量が所定量以上となるようにすることができる。したがって、内蔵する情報記憶手段を必要以上に大型化させることなく、半永久的に新しいサービス提供用情報としてカラオケ曲情報をその情報記憶手段に追加記憶させることが可能となるのである。
【００１６】
【００１７】
【００１８】
【００１９】
【００２０】
【００２１】
【００２２】
以上は、情報提供端末についてであったが、この情報提供端末を備えた通信式情報提供システムとしては以下のものが考えられる。
請求項３に示す通信式情報提供システムは、請求項１または２に記載の情報提供端末と、該情報提供端末に対し、課金通信網を介して課金情報を送信可能な課金センタとを備え、該課金センタが前記課金通信網を介して課金情報を送信することによって、前記課金通信網の課金機能による課金がなされると共に、前記情報提供端末の課金状態記憶手段においては、その送信された課金情報に対応するサービス提供用情報が課金済みであると記憶されることを特徴とする。
【００２３】
請求項１または２に示した情報提供端末においては、課金あるいは実際の料金徴収については特に限定せず、課金状態記憶手段が、サービス提供用情報としてカラオケ曲情報毎に課金済みであるか未課金であるかを記憶しておく点を明示した。したがって、例えば、サービス提供用情報提供者側のサービスマン等が、直接その情報提供端末の設置された場所まで出向き、設置事業者の要求に応じて課金済みに設定すると共に、その料金を徴収してもよいが、このような方法では非常に面倒である。
【００２４】
そこで、請求項３に示すものでは、課金センタが課金通信網を介して課金情報を送信することによって課金通信網の課金機能による課金がなされると共に、課金状態記憶手段においては、その送信された課金情報に対応するサービス提供用情報が課金済みであると記憶されるようにした。このようにすれば、例えば情報提供端末の設置事業者が課金を実行させてサービス提供用情報としてカラオケ曲情報を使用可能にしたいと考えたときには、その指示をするだけで課金通信網による課金機能を利用した課金がなされ、サービス提供用情報を使用可能にするための対価を、人の手を煩わさずに自動的に回収することが可能となるため、非常に便利である。
【００２５】
なお、この課金処理を実行する際には、まず課金センタと情報提供端末とを課金通信網を介して接続する必要がある。ここで、現行のキャプテンシステムやダイヤルキューツーなどの課金通信網では発呼側（電話をかけた側）に課金することとなっているので、情報提供端末側から課金センタをコールして接続することになる。しかし、既に公衆電話回線においても実用化されているように、コレクトコール方式で着呼側（電話を受けた側）に課金するように課金通信網の構成を変更することは可能である。よって、ここでの接続は、情報提供端末側に課金される限りは、情報提供端末側が発呼するものであっても課金センタ側が発呼するものであっても構わない。
【００２６】
また、情報記憶手段が記憶するサービス提供用情報の出所についても、上記情報提供端末の説明では特に限定していない。したがって、例えば、サービス提供用情報を記憶させた記憶媒体（ＬＤやＣＤ、あるいはハードディスク等）を情報提供端末にセットして情報記憶手段として機能させてもよいし、オンラインで受信してもよい。
【００２７】
このオンラインでサービス提供用情報を受信するようにした通信式情報提供システムの一例が請求項４に示すものである。すなわち、その構成は、請求項３に記載の通信式情報提供システムであって、前記情報提供端末に対し、情報通信網を介してスクランブル情報の付加されたサービス提供用情報を送信可能な情報センタを備え、前記情報提供端末の使用許可手段は、情報センタから送信されて情報記憶手段に記憶されたサービス提供用情報の内、課金状態記憶手段に課金済みであると記憶された情報についてのみ、スクランブル情報を解除して情報提供サービス処理への使用を許可することを特徴とする。
【００２８】
なお、サービス提供用情報としてカラオケ曲情報は先に送信しておき、その後、課金処理が済んだものだけ使用可能にするものであるため、先に送信するサービス提供用情報を未課金であるにもかかわらず不正に使用される可能性もある。したがって、情報センタから送信する時点ではスクランブル情報を付加しておき、課金が済んだものについては、スクランブルを解除するための暗号解読キーを受信することによって使用可能とすることが好ましい。
【００２９】
また、本システムにおいて、情報通信網と課金通信網とを異なる通信網とすれば、次の点で特に優れた作用・効果を奏する。
即ち、情報提供端末において情報提供サービスに用いるサービス提供用情報はカラオケ曲情報であり情報量のかなり大きなものとなる場合が想定されるが、そういった大きな情報そのものを情報センタから配信する場合には、その配信に適した通信網を利用することが好ましい。つまり、課金通信網を利用してサービス提供用情報自体を配信するよりも迅速であったり、データの信頼性が高かったりするという点で、情報提供端末が受け取るべき情報の種類に応じた最適なシステム構成が可能となるからである。
【００３０】
ここまでの説明でも判る通り、本発明の通信式情報提供システムにおける課金センタと情報センタは、別々の独立したセンタとして存在してもよいし、一つのセンタの中に両機能を備えさせておいてもよい。いずれにしても情報提供端末に対して情報の配信が可能な情報通信網の方を介して接続されたときに情報センタとしての機能を発揮でき、課金通信網の方を介して接続されたときに課金センタとしての機能が発揮でき、課金センタとしての機能を有する部分による課金の完了が何等かの手段によって情報センタとしての機能を有する部分に伝達される限りは、両センタが別体であろうと一体であろうと構わないのである。即ち、本発明においては、情報センタと課金センタは概念として分けて表現されているだけであって物として分かれている場合だけを意味するわけではない。
【００３１】
【実施例】
以下、本発明を具体化した一実施例を図面を参照して説明する。
図１は、実施例の通信式情報提供システムをカラオケに関するシステムに適用した場合の概略構成図、図２はそのシステムの構成要素である情報提供端末としてのカラオケ端末１０の構成を示すブロック図である。
【００３２】
図１に示すように、本実施例のシステムは、課金関連処理を担当する課金センタ１と複数のカラオケ端末１０とが、課金通信網５を介して接続されていると共に、カラオケ曲情報の送信関連処理を担当する情報センタ３と複数のカラオケ端末１０とが、情報通信網７を介して接続されて構成されている。また、課金センタ１と情報センタ３との間も接続されている。
【００３３】
課金通信網５は、例えばビデオテックス通信網やダイヤルキューツー通信網のように、情報料に対して課金する機能を持つものである。現在の日本国内では、ビデオテックス網とダイヤルキューツー網がその代表的なものとして知られておいる。ダイヤルキューツー網は基本的に時間単位の従量計算であり、ビデオテックス網は、情報の内容毎に任意の料金を設定可能であり、いわゆるキャプテンシステム等に用いられている。
【００３４】
その課金機能の一例として、ビデオテックス通信網について説明すると、ビデオテックス通信網は、具体的には例えば各カラオケ端末１０に接続された公衆電話回線とビデオテックス通信処理装置とで構成されている。このビデオテックス通信処理装置が、ビデオテックス通信網にアクセスしようとしている公衆電話回線の課金センタ１への接続・交換、利用者装置であるカラオケ端末１０の管理及び課金センタ１への加入者管理、通信料及び電話会社が代理徴収する情報提供料の課金、カラオケ端末１０と課金センタ１との間の会話制御、プロトコル変換やコード／パターン変換などの変換処理等の通信処理機能を提供する。
【００３５】
続いてカラオケ端末１０の構成について、図２を参照して説明する。使用許可手段、判断手段及び情報削除手段等に相当する中央制御装置３１には、各種指示入力を行なうための入力手段としての多目的入力キー３２、情報記憶手段としてのハードディスク３３、音声再生回路３５、画面表示制御装置２６、情報通信網７と接続可能な第１通信制御装置２７ａ及び課金通信網５と接続可能な第２通信制御装置２７ｂとを備えている。また、音声再生回路３５にはミキサアンプ３８が、画面表示制御装置２６には表示手段としてのテレビモニタ２９がそれぞれ接続されている。また、ミキサアンプ３８にはスピーカ４１とマイクロフォン４３が接続されている。
【００３６】
そして、この中央制御装置３１は所定の課金制御処理を実行する。この課金制御処理については後で詳しく説明するが、従来の課金通信網５の利用方法とは異なるので、その点を説明しておく。従来は、利用者端末がこの課金通信網５を介して情報を受信し、その情報を用いて所定の処理を実行する。そして、課金通信網５はその情報の代金として所定の料金（情報内容毎に設定された所定料金）を課金することとなる。
【００３７】
それに対して、本実施例では、カラオケ端末１０がカラオケ演奏処理に用いる情報は、ハードディスク３３が記憶している。ハードディスク３３には予め数千曲程度のカラオケ曲情報が記憶されている。なお、カラオケ端末１０は、カラオケ端末設置事業者の管理であり、新しい曲データがリリースされる毎に曲データ配信事業者から曲データの供給を受けることができる。本実施例のシステムでは、第１通信制御装置２７ａを介して情報通信網７と接続し、情報センタ３からその新曲データを受信して、ハードディスク３３に後から記憶させることができるようにされている。
【００３８】
なお、前記ハードディスク３３に記憶されるカラオケ曲情報は、曲同士を識別するための識別情報である曲番号情報と、実体情報とから構成されている。この内の実体情報は、伴奏音楽の情報であるＭＩＤＩ（Musical Instrument Digital Interface）規格の演奏情報や、歌詞情報及び背景映像情報からなっている。背景映像情報は曲毎に対応した映像情報を符号化したものである。
【００３９】
そして、このカラオケ曲情報はそのままでは使用できないようにされている。使用するためには、課金通信網５に第２通信制御装置２７ｂを通して接続し、中央制御装置３１が課金制御プログラムを実行することによって、課金通信網５による課金機能を利用した所定の課金処理が行われて、カラオケ曲情報を使用することができる状態となる。
【００４０】
例えば、未課金状態ではカラオケ曲情報にスクランブル情報を付加しておき、そのままでは使用できなくしてある場合に、課金処理によって解除キーを配信してもらい、その解除キーによってスクランブル情報を解除することで使用許可することが考えられる。また、スクランブル情報の付加といったようにカラオケ曲情報自体を使用不可にしておくのではなく、カラオケ曲情報自体は物理的には使用可能であっても、課金状態が未課金である場合には、使用禁止フラグを設定しておき、そのカラオケ曲情報がリクエストされても受け付けないような制御をするようにしてもよい。そして、課金済みとなると、その使用禁止フラグを使用可能フラグに変更するといったような制御をすれば実現できる。
【００４１】
本実施例では、課金・使用実績テーブル中において、曲毎に使用可能フラグあるいは使用禁止フラグのいずれかが設定されており、そのフラグに応じて使用を許可したり、禁止したりするようにされている。図１１には、ハードディスク３３に格納されたその課金・使用実績テーブルを示す。カラオケ曲情報毎に、その曲番号・曲名・そのカラオケ曲情報に対する料金・課金日・課金状態・使用許可禁止フラグ・受信日または最終リクエスト日・使用回数の項目からなるテーブルが存在する。
【００４２】
ここで、受信日または最終リクエスト日とは、カラオケ曲情報を受信してから一度もリクエストされずにカラオケ演奏処理に使用されてしない場合には、受信日が記憶され、リクエストがあってカラオケ演奏処理に使用された場合には、そのリクエスト毎に更新されていき、最後にリクエストがあった日がここに記憶されることとなる。また、使用回数とは、リクエストによってカラオケ演奏として使用された回数である。
【００４３】
また、課金状態とは、所定の課金処理が済んでいる「課金済み」か課金処理が済んでいない「未課金」かのいずれかである。そして、使用許可禁止フラグとしては、上述したように許可か禁止のフラグが設定されるのであるが、これはまず、課金状態が「未課金」の場合には、禁止フラグが設定されて曲の使用ができないロック状態とされている。そして、所定の課金処理によって「課金済み」となると許可フラグが設定されてロック状態が解除され、曲情報は自由に使用できるようになる。
【００４４】
上記許可フラグが設定されて、カラオケ曲情報が使用できるようになると、利用者は多目的入力キー３２を操作することで歌いたい曲を選択する。すると中央制御装置３１は、所定のカラオケ演奏プログラムに従って、カラオケ演奏処理を実行する。簡単に説明すると、中央制御装置３１は、選択された曲に対応する演奏情報、歌詞情報および背景映像情報をハードディスク３３から読み出し、演奏情報は音声再生回路３５に、歌詞情報および背景映像情報は画面表示制御装置２６にそれぞれ転送する。
【００４５】
音声再生回路３５に出力された演奏情報は、アナログの演奏信号に変換された後、ミキサアンプ３８へ送られて電気的に増幅されるとともに、マイクロフォン４３を介して入力する利用者の歌声と適度な割合でミキシングされる。ミキシングされた音声信号は、スピーカ４１により演奏音として外部へ出力される。
【００４６】
一方、演奏情報と同期して出力される歌詞情報は、画面表示制御装置２６において、後述する背景映像信号と合成（スーパーインポーズ）されてテレビモニタ２９に表示される。これにより、テレビモニタ２９には、背景映像に歌詞テロップが合成された状態で表示される。
【００４７】
続いて、課金センタ１の構成を図３を参照して説明する。
課金センタ１は、ホストコンピュータ５１と、記憶装置５３と、入力装置５５と、通信制御装置５７と、プリンタ５９と、ＣＲＴ６１とを備えている。前記記憶装置５３は、ホストコンピュータ５１が作動するための各種制御プログラムや、前記各カラオケ端末１０毎の課金実績等を記憶するためのものである。つまり、図１１に示した課金・使用実績テーブルに似たものが、各カラオケ端末１０に対応して記憶されているのである。詳しくは、図１１に示したデータ項目の内の使用許可禁止フラグは記憶しておく必要がないので、その使用許可禁止フラグの項目を除く。また受信日または最終リクエスト日の項目には配信日が記憶される。そして使用回数の項目はない。すなわち、カラオケ曲情報毎に、その曲番号・曲名・そのカラオケ曲情報に対する料金・課金日・課金状態・配信日の項目からなるテーブルが存在する。したがって、カラオケ端末１０毎に、どの曲が課金済みであるかが判るようになっている。
【００４８】
なお、入力装置５５からは各種指令を入力することができ、例えば、記憶装置５３に記憶された各カラオケ端末１０毎の課金情報を基にして課金実績等を作成させたり、それをプリンタ５９によって印刷させたり、ＣＲＴ６１に表示させたりすることができる。
【００４９】
次に、情報センタ３の構成及び機能について説明する。
情報センタ３は、図３に示すとおり、情報通信網７を介してカラオケ端末１０と接続する通信制御装置７７と、カラオケ端末１０に配信するカラオケ曲データを蓄積する記憶装置７３とを備え、これらが中央制御装置としてのホストコンピュータ７１によって制御されている。また、ホストコンピュータ７１には、入力装置７５、プリンタ７９、ＣＲＴ８１などの各種機器が接続されている。また、記憶装置７３には、カラオケ曲データの他に、ホストコンピュータ７１が作動するための各種制御プログラム等も記憶されている。
【００５０】
このように構成された情報センタ３は、カラオケ曲データを、情報通信網７を介して各カラオケ端末１０に対して送信する。この送信は、新曲データの追加のために、数日おき程度のペースで情報センタ３側から行われるが、例えばカラオケ端末１０側からの定期的に（例えば１日１回）新曲問い合わせをし、その問い合わせに応えて配信すべき新曲があれば配信処理をするようにしてもよい。いずれにしても、結果としてカラオケ曲情報が情報センタ３からカラオケ端末１０へと送信されることになる。
【００５１】
次に、上記構成を有する本実施例のシステムにおける動作について説明する。まず、図４〜図８のフローチャートに基づいて、カラオケ端末１０の作動を説明する。
電源が投入されると、このメインルーチンが開始される。
【００５２】
まず、最初のステップＳ１にて、通信制御装置２７ａ，２８ｂのリセット等の装置全体の初期化を行う。次に、Ｓ２にて、カラオケ端末１０の動作指定として、カラオケ演奏モードが指定されたか否かをチェックする。カラオケ端末設置事業者によってカラオケ演奏モードの指定があればＳ３へ移行し、同指定がなければＳ４へ移行する。
【００５３】
Ｓ３では、サブルーチンをコールしてカラオケ演奏処理を行う。このカラオケ演奏処理を図５のフローチャートにて説明する。
本カラオケ演奏処理の最初のステップＳ３０では、多目的入力キー３２からのキー入力を待ち、キー入力があれば（Ｓ３０：ＹＥＳ）、Ｓ３１にて、それがリクエスト番号の入力かどうかを判断する。そして、リクエスト番号入力である場合には、Ｓ３２に移行して、その曲がロック対象であるかどうかを判断する。これは、上述した課金・使用実績テーブル（図１１参照）の使用許可禁止フラグの項目において、禁止フラグが設定されているかどうかで判断する。
【００５４】
許可フラグが設定されている場合にはＳ３３へ移行して、そのリクエストされた番号の曲の演奏を実行するが、禁止フラグが設定されている場合には、ロック対象であるので、Ｓ３５へ移行し、テレビモニタ２９に利用不可であることを示す表示をする。このＳ３３あるいはＳ３５の処理の後でＳ３４へ移行する。
【００５５】
一方、Ｓ３１にてリクエスト番号入力でないと判断された場合には、Ｓ３６にて、その他のキー入力に応じた処理を実行してからＳ３４へ移行する。Ｓ３４ではカラオケモード終了の指示があったかどうかを判断し、終了指示がない場合にはＳ３０へ戻り、終了指示があった場合には、本カラオケ演奏処理を終了して、図４のフローチャートのＳ４へ移行する。
【００５６】
Ｓ４では、カラオケ端末１０の動作指定として、カラオケ端末設置事業者により曲情報リクエストモードが指定されたか否かをチェックする。曲情報リクエストモードの指定があればＳ５へ移行し、同指定がなければＳ６へ移行する。
Ｓ５では、サブルーチンをコールして曲情報リクエスト処理を行う。この曲情報リクエスト処理を図６のフローチャートにて説明する。
【００５７】
本曲情報リクエスト処理は、未課金であるため禁止フラグが設定され使用不可となっている曲情報について、所定の課金処理を実行させて使用可能にするための処理であり、最初のステップＳ５０では、禁止フラグが設定され使用不可となっている曲情報の一覧をテレビモニタ２９に表示させる。この際、「課金を希望する曲を指定して下さい」といった選択を促す表示も出すとよい。カラオケ端末１０の設置事業者は、この曲情報一覧から所望の曲を１曲以上選択し、選択終了を指示する。選択が終了すると（Ｓ５１：ＹＥＳ）、課金センタ１と課金通信網５を通じて接続する（Ｓ５２）。課金センタ１との接続処理終了後、Ｓ５３へ移行する。
【００５８】
Ｓ５３では、選択された曲についての課金を課金センタ１に対して要求する。そして、続くＳ５４では、課金要求に対する応答として、課金センタ１から送信される課金情報の受信を行なう。この課金情報の受信処理が完了したら、Ｓ５５へ移行し、課金センタ１との接続解除処理を行う。
【００５９】
Ｓ５５での接続解除処理が終了すると、Ｓ５６にて、上記選択された曲情報について課金・使用実績テーブル（図１１参照）の課金状態の項目に「課金済み」と設定し、Ｓ５７では、その「課金済み」と設定された曲情報、つまり選択された曲情報についての使用許可禁止フラグの項目に許可フラグを設定して、その曲情報の使用が可能な状態にする。
【００６０】
この後、本曲情報リクエスト処理を一旦終了して、図４のフローチャートのＳ６のステップへ移行する。
Ｓ６では、カラオケ端末１０の動作指定として、新曲問い合わせのための所定時刻であるかどうかをチェックする。これは、新曲のデータをなるべく早く取得するため、例えば１日に１回、情報センタ３から配信すべき曲データがあるかどうかを問い合わせるためのものである。新曲問い合わせのための所定時刻であればＳ７へ移行して曲情報削除処理を実行した後、Ｓ８へ移行して新曲問い合わせ処理を実行する。また、新曲問い合わせの所定時刻でなければＳ２へ移行する。
【００６１】
Ｓ７では、サブルーチンをコールして曲情報削除処理を行う。この曲情報削除処理は、これから新曲を受ける可能性があるので、その前にハードディスク３３の空き容量をチェックしておき、もし空き容量が十分でなければ記憶されているカラオケ曲情報を必要度の低いものから削除して、空き容量を確保するための処理である。この曲情報削除処理を図７のフローチャートにて説明する。
【００６２】
最初のステップＳ７０で、ハードディスク３３の空き容量が所定量未満かどうかを判断する。Ｓ７０で否定判断、すなわちハードディスク３３の空き容量が所定量以上確保されている場合には、この状態で新曲のカラオケ曲情報を受信してもなんら支障がないため、Ｓ７１以降の処理を実行することなく、本曲情報削除処理を終了して、図４のフローチャートのＳ８へ移行する。
【００６３】
一方、ハードディスク３３の空き容量が所定量未満である場合には（Ｓ７０：ＹＥＳ）、Ｓ７１へ移行する。
Ｓ７１では、課金・使用実績テーブル（図１１参照）の課金状態の項を参照して、未課金である曲を探す。これは、例えばテーブルのレコード番号順に見ていき、図１１の場合でいけば曲番号「０００２」のものが最初に該当する。
【００６４】
したがって、この場合にはＳ７２で未課金曲ありと判断され（Ｓ７２：ＹＥＳ）Ｓ７３へ移行する。Ｓ７３では、その未課金状態が長期間続いているかどうかを判断するため、受信日からα日以上経過しているかどうかを判断する。未課金の場合は使用禁止フラグが設定されているのでリクエストされることはなく、受信日または最終リクエスト日の項は必ず受信日となる。そのため、その受信日を見て、α日以上経過しているかどうかを判断するのである。
【００６５】
例えば、α＝１８０として、およそ６か月以上未課金状態が続いているものは削除してもよいとし、例えば平成７年４月１日にこの処理を実行したとすると、上記曲番号「０００２」のものの受信日は平成４年１月７日なので、Ｓ７３で肯定判断となって、Ｓ７４へ移行する。
【００６６】
Ｓ７４では、ハードディスク３３に記憶されているそのカラオケ曲情報を削除する。そして、続くＳ７５では、課金・使用実績テーブル中から対応するレコードを削除して、Ｓ７０へ戻る。
こうして、例えばまず曲番号「０００２」のカラオケ曲情報をハードディスク３３から削除し、課金・使用実績テーブル中からも対応するレコードを削除して、Ｓ７０で再度ハードディスク３３の空き容量が所定量未満かどうかを判断する。
【００６７】
そして、まだハードディスク３３の空き容量が所定量未満の場合には、Ｓ７１以下の処理を繰り返す。図１１の例でいけば、続いて曲番号「０００５」のカラオケ曲情報が削除され、次いで曲番号「００１４」，「００１５」のカラオケ曲情報が削除候補となる。これら２曲が削除されてもまだＳ７０で肯定判断となる場合には、曲番号「００２１」のカラオケ曲情報が削除候補となるが、これは受信日が平成７年１月１４日で１８０日以上経過していないので、Ｓ７３で否定判断となる。なお、受信日から所定期間が経過していない場合には削除しないとしたのは、これらの曲については今後図４のＳ５に示した曲情報リクエスト処理が実行されて、課金済みと設定される可能性がまだ十分にあるとの判断に基づくものである。
【００６８】
このように受信日から所定期間が経過していない曲の場合には、Ｓ７１〜Ｓ７３のループを繰り返すだけとなるので、制御上、例えばＳ７３で否定判断となった曲については、Ｓ７１における未課金曲であるとの判断対象から除外することとする。
このようにして、未課金曲で受信日からα日以上経過しているものについて全て削除してもまだハードディスク３３の空き容量が所定量未満の場合には、Ｓ７２で否定判断となり、Ｓ７６へ移行する。
【００６９】
Ｓ７６以降では、今度は課金済みであっても一度もリクエストされていなかったり、あるいは少なくとも一度はリクエストされていても、その後長期間にわたってリクエストがされていない曲は必要度も相対的に低いと見なして削除する。なお、以降の説明のため、未課金曲で受信日からα日以上経過しているものについて全て削除した状態の課金・使用実績テーブルを図１２に示す。
【００７０】
Ｓ７６では、まず課金・使用実績テーブル（図１２）についてレコード順に検査していくためｎ＝１とし、続くＳ７７で、そのレコードの受信日または最終リクエスト日を読み出す。例えば、図１２に示す場合では、最初のレコードである曲番号「０００１」についての受信日または最終リクエスト日は平成６年１月７日である。
【００７１】
そして、続くＳ７８では、一度もリクエストされていない状態が長期間続いているかどうかを判断するため、受信日または最終リクエスト日からβ日以上経過しているかどうかを判断する。例えば、β＝１８０として、およそ６か月以上リクエストされない状態が続いているものは削除してもよいとし、例えば平成７年４月１日にこの処理を実行したとすると、上記曲番号「０００１」のものの受信日または最終リクエスト日は平成６年１月７日なので、Ｓ７８で肯定判断となって、Ｓ７４へ移行する。
【００７２】
Ｓ７４では、ハードディスク３３に記憶されているそのカラオケ曲情報を削除する。そして、続くＳ７５では、課金・使用実績テーブル中から対応するレコードを削除して、Ｓ７０へ戻る。
こうして、例えばまず曲番号「０００１」のカラオケ曲情報をハードディスク３３から削除し、課金・使用実績テーブル（この場合は図１２参照）中からも対応するレコードを削除して、Ｓ７０で再度ハードディスク３３の空き容量が所定量未満かどうかを判断する。
【００７３】
そして、まだハードディスク３３の空き容量が所定量未満の場合には、Ｓ７１以下の処理を繰り返す。具体的には、再度Ｓ７６へ移行し、続くＳ７７で最初のレコードの受信日または最終リクエスト日を読み出すのであるが、この場合には図１２に示す状態から曲番号「０００１」のレコードが削除されているので、最初のレコードは曲番号「０００３」のものとなる。Ｓ７７では読みだされる日は平成６年１１月２４日である。これは、使用回数の項に「１」とあることからも判るように、平成６年１１月２４日に一度リクエストされたことがある。
【００７４】
この場合にはβ日以上経過していないので（Ｓ７８：ＮＯ）、Ｓ７９へ移行する。Ｓ７９では、次のレコードを検査するため、ｎをインクリメント（ｎ←ｎ＋１）して、Ｓ７７へ戻る。こうして、順番にレコードを検査してくのであるが、図１２に示す場合で説明すると、曲番号「０００４」，「０００６」，「０００７」の３つについてはいずれもβ日以上経過していないので削除されず、その次の曲番号「０００８」の受信日または最終リクエスト日がβ日以上経過しているので、削除されることとなる。
【００７５】
このように本曲情報削除処理においては、まず未課金曲で受信日からα日以上経過しているカラオケ曲情報について削除し、該当するものを全て削除してもまだハードディスク３３の空き容量が所定量未満の場合には、課金済みであってもβ日以上リクエストがされたことがないカラオケ曲情報を削除して、ハードディスク３３が所定量以上の空き容量を備えるように制御するのである。
【００７６】
こうして曲情報削除処理が終了すると、図４のフローチャートのＳ８へ移行する。
Ｓ８では、サブルーチンをコールして新曲問い合わせ・受信処理を行う。この新曲問い合わせ・受信処理について図８のフローチャートを参照して説明する。
【００７７】
新曲問い合わせ・受信処理の最初のステップＳ８０では、情報通信網７を介して情報センタ３と接続する。情報センタ３との接続処理終了後、Ｓ８１へ移行する。
Ｓ８１では、新曲の有無を情報センタ３に問い合わせ、Ｓ８２でその問い合わせに対する回答を受信する。その回答により、配信すべき新曲データが有ると判断された場合には（Ｓ８３：ＹＥＳ）、Ｓ８４へ移行して、その配信すべき新曲を全曲取得する要求を情報センタ３に送信する。続くＳ８５では、その全曲取得要求に対する応答として、情報センタ３から送信される新曲にかかるカラオケ曲情報を受信して内蔵のハードディスク３３へセーブする。このハードディスク３３へのセーブが完了したら、Ｓ８６へ移行し、情報センタ３との接続解除処理を行う。
【００７８】
なお、Ｓ８３にて、配信すべき新曲データが無いと判断された場合には（Ｓ８３：ＮＯ）、Ｓ８７へ移行して新曲データ無しを記憶してから、Ｓ８６へ移行する。この場合、新曲データが無い旨をテレビモニタ２９に表示するようにしてもよい。
【００７９】
Ｓ８６での情報センタ３との接続解除の完了後、図４のフローチャートのＳ２へ移行する。
以上がカラオケ端末１０の中央制御装置３１の作動であり、カラオケ演奏、カラオケ曲情報を使用可能とするための課金情報の要求、曲情報削除、及び配信された新曲に係るカラオケ曲情報の受信の各処理を行う。
【００８０】
次に、課金センタ１の作動を図９のフローチャートを基に説明する。
課金センタ１では、電源投入後、Ｓ１００のステップから実行する。
Ｓ１００では、通信制御装置５７のリセット等の装置全体の初期化を行う。Ｓ１００の処理を終了後、Ｓ１０１へ移行する。
【００８１】
Ｓ１０１では、カラオケ端末１０からの接続要求があるかどうか調べる。あればＳ１０２へ移行し、なければＳ１０１の処理を繰り返し、待機状態となる。
Ｓ１０２では、カラオケ端末１０からの接続要求に対して同カラオケ端末１０との接続を行う。接続完了後、Ｓ１０３へ移行する。
【００８２】
Ｓ１０３では、カラオケ端末１０からの課金要求情報を受信する。課金要求情報とは、図６に示すＳ５３において要求される情報であり、未課金であるため禁止フラグが設定され使用不可となっているカラオケ曲情報を使用可能とするために、所定の課金処理の実行を要求するものである。
【００８３】
Ｓ１０４では、その要求に応じて所定の課金情報を該当するカラオケ端末１０に送信する。送信完了後、Ｓ１０５へ移行する。
Ｓ１０５では、接続中のカラオケ端末１０との接続を解除する。接続解除完了後、Ｓ１０１へ移行する。
【００８４】
以上が課金センタ１のホストコンピュータ５１の作動であり、カラオケ端末１０から課金要求情報を受け取り、その内容を参照した上で、所定の課金情報を送信する処理を行う。
なお、この処理は、図６に示すカラオケ端末１０側での曲情報リクエスト処理との関連で実行されるものであり、両者の通信処理について、図１３の通信シーケンス図を参照して説明する。
【００８５】
カラオケ端末１０が課金センタ１に対して発呼し、接続できた後にパスワードを課金センタ１に送信する。
課金センタ１では、通信制御装置５７を介してこれを受け取り、ホストコンピュータ５１が電話番号やパスワード等で端末照合を行い、課金センタ１に登録されているカラオケ端末１０であれば、照合正常を返送する。カラオケ端末１０はこの照合正常を受信して課金センタ１が受付可能状態となって後に、上記選択された曲についての課金情報要求を送信するのである。
【００８６】
この課金情報要求は所定の情報提供料を課金するために行われるのであるが、この場合の情報提供料は、カラオケ端末１０側で決定し、その料金に基づく課金情報が送信されるように課金センタ１に要求してもよいし、あるいは選択された曲情報を課金センタ１に送信し、その曲情報に基づく料金の決定は課金センタ１側に任せ、その決定した料金での課金情報が送信されるように要求してもよい。
【００８７】
なお、課金通信網５を構成する料金徴収代行システムでは、どのカラオケ端末１０が課金センタ１から課金通信網５を介して課金情報が送信されたかを課金実績として取得する。この課金実績に基づき、予め登録されている料金リストを参照して算出した情報提供料金を、電話事業者は、該当するカラオケ端末１０の設置事業者に対する電話料金請求時にこれに上乗せする形で徴収し、情報提供者である曲情報配信事業者へと渡すサービスを行っている。これ自体は、ＮＴＴで行っているビデオテックスとしてよく知られているものである。
【００８８】
そして、電話事業者側において実際に料金が徴収されると、その徴収実績は課金センタ１の記憶装置５３に記憶される。つまり、課金センタ１の記憶装置５３には、図１１と似たテーブル（上述したように使用許可禁止フラグや使用回数の項目は不要であるために無く、受信日または最終リクエスト日の項目には配信日が記憶されている。）が各カラオケ端末１０に対応して格納されており、カラオケ端末１０からの課金要求があれば、課金情報を送信すると共に、該当する曲情報の課金状態を課金済みに設定する。
【００８９】
次に、情報センタ３の作動を図１０のフローチャートに基づいて説明する。情報センタ３では、電源投入後、Ｓ１２０のステップから実行する。
Ｓ１２０では、通信制御装置７７のリセット等の装置全体の初期化を行う。そして、Ｓ１２１へ移行し、カラオケ端末１０から接続要求があるかどうかを調べる。あればＳ１２２へ移行し、なければＳ１２１の処理を繰り返し、待機状態となる。
【００９０】
Ｓ１２２では、カラオケ端末１０からの接続要求に対して当該カラオケ端末１０との接続を行う。接続完了後、Ｓ１２３へ移行する。
Ｓ１２３では、カラオケ端末１０からの新曲有無の問い合わせを受信し、Ｓ１２４でその回答を送信する。その回答が新曲データ無しの場合には（Ｓ１２５：ＮＯ）、上述したようにカラオケ端末１０側でもそのまま回線接続が切断され、その後の通信が必要でなくなるため、当該カラオケ端末１０との接続を解除して（Ｓ１４０）、Ｓ１２１へ戻る。
【００９１】
一方、回答が新曲データ有りの場合には（Ｓ１２５：ＹＥＳ）、カラオケ端末１０からの要求があるのでそれを受信する（Ｓ１２６）。上記図８のＳ８４で説明したように、この要求は全曲取得の要求であるため、続くＳ１２７では、配信すべき新曲に係るカラオケ曲情報を全部送信する。
【００９２】
こうしてＳ１２８で新曲データの送信が完了したら、Ｓ１２９へ移行し、当該カラオケ端末１０との接続を解除する。接続解除処理が完了後、Ｓ１２１へ移行し、上記の処理を繰り返す。
以上が情報センタ３のホストコンピュータ７１の作動であり、カラオケ端末１０からの新曲問い合わせに対して、配信すべき新曲データがあれば、それを配信する処理を実行する。
【００９３】
なお、この処理は、図８に示すカラオケ端末１０側での新曲問い合わせ・受信処理との関連で実行されるものであり、両者の通信処理について、図１４の通信シーケンス図を参照して説明する。
カラオケ端末１０が情報通信網７を介して情報センタ３に対して発呼し、接続できた後にパスワードを情報センタ３に送信する。
【００９４】
情報センタ３では、通信制御装置７７を介してこれを受け取り、ホストコンピュータ７１が電話番号やパスワード等で端末照合を行い、情報センタ３に登録されているカラオケ端末１０であれば、照合正常を返送する。カラオケ端末１０はこの照合正常を受信して情報センタ３が受付可能状態となって後に、新曲有無の問い合わせを行なう。
【００９５】
情報センタ３では、この問い合わせを受け付けて当該カラオケ端末１０に対する新曲データを検索し、問い合わせの回答をカラオケ端末１０に送信する。つまり、新曲データが有るか無いかを示す回答である。
カラオケ端末１０では、この回答結果に基づいて新曲データが有るか無いか判断し、新曲データが有る場合には情報センタ３に対して新曲データの全曲取得要求を送信する。そして、この要求を受信した情報センタ３は、該当する新曲データすなわちカラオケ曲情報をカラオケ端末１０に送信する。これを受信してセーブしたカラオケ端末１０は情報センタ３との接続を切断する。
【００９６】
以上説明した本実施例によれば、カラオケ端末１０において、ハードディスク３３が記憶している所定のカラオケ曲情報の内、課金通信網５から課金情報を受信し、使用許可フラグの設定された曲情報についてのみカラオケ演奏に使用可能とされている。
【００９７】
このように、課金済みであるカラオケ曲情報のみがカラオケ演奏処理に使用できるようになるのであるが、例えば、カラオケ端末１０の設置事業者の意図によって未課金のまま放置されるカラオケ曲も生じる可能性がある。つまり、そのカラオケ曲情報はその端末設置事業者にとっては不要あるいは必要度があまり高くないので、あえて料金を支払ってまで使用可能とするものでもないと考える場合には、未課金のままとなる。例えば、ある特定のジャンルしか必要ない、あるいはある特定のジャンルについては不要だと考えて、記憶されているカラオケ曲情報を全て使用可能にするのではなく、自分が必要だと考えるカラオケ曲情報についてのみ、その料金を支払って使用可能にすることは十分に考えられる。
【００９８】
すると、例えば、新曲を随時追加していくようなシステムであるので、必要度の低いカラオケ曲情報が記憶されていることで、相対的に必要度の高い新曲については記憶させられなくなったり、あるいは、この必要度の低いカラオケ曲情報も含めて記憶するために、必要以上に大型のハードディスク３３を準備しなくてはならないという問題が生じる。
【００９９】
これに対して、本実施例のカラオケ端末１０では、新曲を受信する前に、ハードディスク３３の空き容量を判断し、新曲を受信するためには空き容量が十分でない場合には、カラオケ曲情報毎に必要度を判断して、必要度が低いものから削除していくのである。これにより、ハードディスク３３の空き容量が増し、ハードディスク３３を必要以上に大型化させることなく、半永久的に新曲の受信が可能となるのである。
【０１００】
なお、上記実施例では、未課金であることと、長期間リクエストがないことを要因として削除するデータを決定したが、図１１のテーブルに示した使用回数、つまりリクエストされた回数を削除データの決定の際に考慮することも考えられる。つまり、一見使用されていない期間が長くても、長期的に見た場合に、コンスタントにされており、その使用回数はトータルで多くなる場合もある。また、逆に使用回数は少なくても、そのカラオケ曲情報の受信時期あるいは課金時期が最近である場合には、使用回数が少なくても当然であるので、所定期間使用されていない、あるいは使用回数が少ないというだけで単純に必要度が低いと判断するのではなく、例えば使用されてない期間と使用頻度等を総合的に分析して必要度を判断するようにすることが好ましい。
【０１０１】
また、削除されたカラオケ曲情報についても今後必要となる場合も想定されるので、その場合の対処として、例えば、削除したレコードを記憶しておき、そこから所望のカラオケ曲情報を選択して情報センタ３に配信を要求できるようにしておくとよい。
【０１０２】
以上本発明はこの様な実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲において種々なる態様で実施し得る。例えば、上記実施例では、新曲のカラオケ曲情報は情報通信網７を用いて送信していたが、課金通信網５を用いても送信するようにしてもよい。但し、上記実施例のように、情報通信網７を課金通信網５とは異なる通信網として、その情報通信網７によってカラオケ曲情報を送信する場合には、次の点で特に優れた作用・効果を奏する。すなわち、カラオケ曲情報は、情報量のかなり大きなものとなる場合が想定されるが、そういった大きな情報そのものを配信する場合には、その配信に適した通信網を利用することが好ましい。これは、課金通信網５を利用してカラオケ曲情報自体を配信するよりも迅速であったり、データの信頼性が高かったりするという点で、カラオケ端末１０が受け取るべき情報の種類に応じた最適なシステム構成が可能となるからである。
【０１０３】
さらに、新曲を追加していくのに情報通信網７を用い、いわゆるオンラインで送信するようにしたが、本発明の情報提供端末としては、上記実施例のような通信式カラオケシステムにおけるカラオケ端末１０には限らない。例えば、スタンドアロンタイプのものであって、新曲の追加を例えば曲配信事業者のサービスマンが直接出向いて、ハードディスク３３に追加記憶させるような場合でも、不要なカラオケ曲情報を削除することは、新曲を追加する場合に、その追加ができなくなることを防止する等、上述したオンラインの場合と同様の効果を奏する。
【０１０４】
また、本発明の適用対象は、通信式カラオケシステムに限らず、ゲームソフトの配信ネットワーク等として適用してもよいことはいうまでもない。
【図面の簡単な説明】
【図１】 実施例の通信式情報提供システムをカラオケに関するシステムに適用した場合の概略構成図である。
【図２】 実施例のシステムの構成要素であるカラオケ端末の構成を示すブロック図である。
【図３】 実施例のシステムの構成要素である課金センタ及び情報センタの構成を示すブロック図である。
【図４】 実施例のカラオケ端末におけるメイン処理を示すフローチャートである。
【図５】 実施例のカラオケ端末におけるカラオケ演奏処理を示すフローチャートである。
【図６】 実施例のカラオケ端末における曲情報リクエスト処理を示すフローチャートである。
【図７】 実施例のカラオケ端末における曲情報削除処理を示すフローチャートである。
【図８】 実施例のカラオケ端末における新曲問い合わせ・受信処理を示すフローチャートである。
【図９】 実施例の課金センタにおけるメイン処理を示すフローチャートである。
【図１０】 実施例の情報センタにおけるメイン処理を示すフローチャートである。
【図１１】 実施例のカラオケ端末のハードディスクに格納された課金・使用実績テーブルの説明図である。
【図１２】 同じく課金・使用実績テーブルの説明図であり、削除が実行された後の状態を示す説明図である。
【図１３】 実施例の曲情報リクエスト処理における通信シーケンス図である。
【図１４】 実施例の新曲問い合わせ及び新曲送受信処理における通信シーケンス図である。
【符号の説明】
１…課金センタ ３…情報センタ
５…課金通信網 ７…情報通信網
１０…カラオケ端末 ２６…画面表示制御装置
２７ａ…第１通信制御装置 ２７ｂ…第２通信制御装置
２９…テレビモニタ ３１…中央制御装置
３２…多目的入力キー ３３…ハードディスク
３５…音声再生回路 ３８…ミキサアンプ
４１…スピーカ ４３…マイクロフォン
５１，７１…ホストコンピュータ ５３，７３…記憶装置
５５，７５…入力装置 ５７，７７…通信制御装置
５９，７９…プリンタ ６１，８１…ＣＲＴ
Claims (4)
- サービス提供用情報としてカラオケ曲情報を記憶している情報記憶手段と、
該情報記憶手段に記憶されたサービス提供用情報を用いて所定の情報提供サービスを実行可能な情報提供実行手段と、
前記情報記憶手段に記憶されたサービス提供用情報毎に、課金済みであるか未課金であるかを記憶しておく課金状態記憶手段と、
該課金状態記憶手段において課金済みであると記憶されているサービス提供用情報についてのみ、前記情報提供実行手段による情報提供サービス処理への使用を許可する使用許可手段と
を備えた情報提供端末であって、
前記情報記憶手段に記憶されたサービス提供用情報毎に、前記課金状態記憶手段に記憶されている課金済みであるか未課金であるかの情報に基づいて、必要度を判断する判断手段と、
所定の削除実行条件が成立した場合には、該判断手段によって必要度が低いと判断されたサービス提供用情報を、前記情報記憶手段より削除する情報削除手段と
を備えていることを特徴とする情報提供端末。 - 請求項１に記載の情報提供端末において、
前記情報記憶手段における空き容量が所定量より少なくなった場合に前記所定の削除実行条件が成立したと判断し、前記情報削除手段は、前記情報記憶手段における空き容量が所定量以上となるまで、必要度が低いと判断されたサービス提供用情報を削除することを特徴とする情報提供端末。 - 請求項１または２に記載の情報提供端末と、
該情報提供端末に対し、課金通信網を介して課金情報を送信可能な課金センタと
を備え、該課金センタが前記課金通信網を介して課金情報を送信することによって、前記課金通信網の課金機能による課金がなされると共に、前記情報提供端末の課金状態記憶手段においては、その送信された課金情報に対応するサービス提供用情報が課金済みであると記憶されることを特徴とする通信式情報提供システム。 - 請求項３に記載の通信式情報提供システムであって、
前記情報提供端末に対し、情報通信網を介してスクランブル情報の付加されたサービス提供用情報を送信可能な情報センタを備え、
前記情報提供端末の使用許可手段は、情報センタから送信されて情報記憶手段に記憶されたサービス提供用情報の内、課金状態記憶手段に課金済みであると記憶された情報についてのみ、スクランブル情報を解除して情報提供サービス処理への使用を許可することを特徴とする通信式情報提供システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP10863195A JP3638661B2 (ja) | 1995-05-02 | 1995-05-02 | 情報提供端末及び該端末を備えた通信式情報提供システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP10863195A JP3638661B2 (ja) | 1995-05-02 | 1995-05-02 | 情報提供端末及び該端末を備えた通信式情報提供システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH08305758A JPH08305758A (ja) | 1996-11-22 |
| JP3638661B2 true JP3638661B2 (ja) | 2005-04-13 |
Family
ID=14489700
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP10863195A Expired - Fee Related JP3638661B2 (ja) | 1995-05-02 | 1995-05-02 | 情報提供端末及び該端末を備えた通信式情報提供システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3638661B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5959945A (en) * | 1997-04-04 | 1999-09-28 | Advanced Technology Research Sa Cv | System for selectively distributing music to a plurality of jukeboxes |
| KR100595717B1 (ko) * | 2000-07-28 | 2006-07-03 | 엘지전자 주식회사 | 디지털 컨텐츠의 재생 제어 방법 |
| JP2004164466A (ja) * | 2002-11-15 | 2004-06-10 | Sony Corp | 情報更新システム、情報処理装置および情報更新方法 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2537706B2 (ja) * | 1991-03-28 | 1996-09-25 | 日本ビクター株式会社 | ファイルシステム |
| JPH06242999A (ja) * | 1993-02-17 | 1994-09-02 | Nippon Telegr & Teleph Corp <Ntt> | データファイル管理方法 |
| JPH06268774A (ja) * | 1993-03-11 | 1994-09-22 | Yamaha Corp | カラオケ制御装置 |
| JPH0744377A (ja) * | 1993-07-30 | 1995-02-14 | Nippon Telegr & Teleph Corp <Ntt> | 流通ソフトウェア偽造防止方法と装置 |
-
1995
- 1995-05-02 JP JP10863195A patent/JP3638661B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH08305758A (ja) | 1996-11-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3752266B2 (ja) | 通信式情報提供システム及び情報インストール装置 | |
| JP3638661B2 (ja) | 情報提供端末及び該端末を備えた通信式情報提供システム | |
| JP3569360B2 (ja) | 情報提供端末 | |
| JP3322500B2 (ja) | 通信式情報提供システム及び情報提供端末 | |
| JP3587903B2 (ja) | 通信式情報提供システム及び情報提供端末 | |
| JPH08234770A (ja) | 通信式カラオケシステム及びカラオケ端末 | |
| JP3324892B2 (ja) | 情報料課金システム及び情報提供端末 | |
| JP3854655B2 (ja) | 通信式情報提供システム及び情報提供端末 | |
| JPH08205119A (ja) | 情報提供装置及び情報提供料課金システム | |
| JPH08185191A (ja) | カラオケ装置及びカラオケ曲情報使用料課金システム | |
| JP3729531B2 (ja) | 情報処理装置 | |
| JPH0934480A (ja) | カラオケ装置およびカラオケシステム | |
| JPH08190393A (ja) | 情報提供装置及び情報提供料課金システム | |
| JPH08205122A (ja) | 通信式カラオケシステム及びカラオケ端末 | |
| JP3224703B2 (ja) | 情報使用料課金システム及び情報処理装置 | |
| JPH08242437A (ja) | 情報料課金システム及びそこに使用される情報提供端末 | |
| JPH08305382A (ja) | カラオケ装置及び該装置を備えたカラオケシステム | |
| JP3363637B2 (ja) | 通信式情報提供システム及び情報提供端末 | |
| JP3637100B2 (ja) | カラオケ通信システム | |
| JPH09237093A (ja) | カラオケ装置およびカラオケシステム | |
| JPH08328572A (ja) | 映像カラオケ装置及び通信式カラオケシステム | |
| JPH08237395A (ja) | 通信式情報提供システム及び情報提供端末 | |
| JPH08315031A (ja) | 通信式情報提供システム及び情報提供端末 | |
| JPH08194666A (ja) | 情報処理装置 | |
| JP3566782B2 (ja) | 情報提供端末 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040727 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040924 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20041221 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050112 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080121 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090121 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100121 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100121 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110121 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120121 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120121 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130121 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140121 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |