JPH08195836A - 情報料課金システム及びそこに使用される情報提供端末 - Google Patents

Abstract

(57)【要約】 【目的】 料金徴収に面倒がないだけでなく、さらに、
端末において利用可能な情報を充実させやすくすること
のできる情報料課金システム及びそこに使用される情報
提供端末を提供する。 【構成】 カラオケ端末１０と曲データ配信用ホスト２
０とを一般公衆回線５０で接続し、カラオケ端末１０と
アカウント端末３０とをビデオテックス回線５２を介し
て接続する。新曲データの配信には、まず、カラオケ端
末１０がビデオテックス回線５２を介してアカウント端
末３０と接続し、課金処理を受ける。課金処理の完了は
アカウント端末３０からホスト２０へと自動的に伝達さ
れ、ホスト２０の方からカラオケ端末１０を呼び出し、
課金の終っている新曲データを配信する。課金処理にお
いては、配信を要求された曲数に応じてまとめ買いほど
得になるように料金計算をする。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、情報を蓄積している情
報センタから情報通信網を介して情報の配信を受けて利
用者に提供し得るようにされている情報提供端末の設置
者から、前記配信される情報の料金を徴収するための課
金システム及びそれに使用する情報提供端末に係り、特
に、ビデオテックス等の課金通信網を利用した技術に関
する。

【０００２】

【従来の技術及び発明が解決しようとする課題】近年普
及している通信カラオケシステムは、店舗等に設置され
た通信カラオケ端末に予め多数の曲データを記憶してお
き、新曲は電話回線を通じてホストコンピュータから配
信する様に構成されている。そして、この新曲の配信に
伴う料金徴収は、曲データ配信事業者がカラオケ端末設
置事業者の店舗等に直接出向いたり、銀行口座に振り込
んでもらうなどの方法によっている。

【０００３】しかしながら、カラオケ端末の転売等によ
って曲データ配信事業者側がカラオケ端末を使用するカ
ラオケ端末設置事業者の管理が不可能になったりする
と、以後のカラオケ端末への曲データ配信サービス及び
同サービスに対する料金徴収が難しくなるという問題を
もっている。

【０００４】また、このようなカラオケ端末設置事業者
の管理や、曲データ配信に対する料金徴収は、曲データ
配信事業者側には大きな負担でもあった。そこで、出願
人は、近年実用化されているビデオテックスシステムや
ダイヤルキューツーシステムの様な課金回線網を利用し
た料金徴収システムの構築を検討することとした。

【０００５】このビデオテックスシステムとしては、わ
が国ではキャプテンシステムがよく知られている。この
システムは、ビデオテックス通信網を介して利用者端末
を情報センタに接続し、利用者端末からの要求に応じ
て、情報センタから文字図形情報などを提供する会話型
画像情報通信として実用化されている。そして、情報セ
ンタから提供した情報の料金を回収するため、上記のビ
デオテックス通信網は課金機能を備えており、情報単位
で料金徴収が可能となっている。

【０００６】また、ダイヤルキューツーシステムは、利
用者端末と情報センタとを公衆回線を介して接続し、情
報センタ毎に設定された単位時間当りの情報料を公衆回
線使用料に上乗せして従量計算により料金徴収を行うも
のである。こうした課金通信網を利用することによっ
て、通信カラオケシステムにおける曲データ配信事業者
側の管理負担を大幅に軽減することが可能になるものと
予測される。

【０００７】ところで、例えば、大量の曲データの配信
を受ける場合には、少量の曲データの配信を受ける場合
よりもデータ当りの単価を引き下げた割引サービスがで
きるなら、より多くの曲データをまとめ買いし易くな
り、カラオケ端末での提供可能な曲目をより充実したも
のとさせることができる。また、システム全体で見たと
きにもその利用を高めることができ、データ配信業者、
端末設置業者はもちろん、端末の利用客にも望ましいも
のということができる。これは通信カラオケシステムだ
けに限る訳ではなく、将来のマルチメデイア社会におけ
る各種の情報提供システムに共通するものである。

【０００８】そこで、本発明は、料金徴収に面倒がない
だけでなく、さらに、端末において利用可能な情報を充
実させやすくすることのできる情報料課金システム及び
そこに使用される情報提供端末を提供することを目的と
する。

【０００９】

【課題を解決するための手段、作用及び効果】本発明の
情報料課金システムは、情報を蓄積している情報センタ
と、該情報センタから情報通信網を介して配信された情
報に基づいて利用者に情報提供サービスを実行し得るよ
うにされている情報提供端末と、該情報提供端末が情報
センタから情報の配信を受けるとき、当該情報提供端末
と課金通信網を介して接続し、該配信される情報の対価
に相当する課金情報を含む情報を当該情報提供端末に対
して送信することにより端末に対する課金を実行する課
金センタとを備え、前記情報提供端末は、情報センタか
ら情報の配信を受けようとするときにその旨を要求する
配信要求手段を備える情報料課金システムであって、１
回に配信される情報の量に応じて、前記課金情報の決定
条件を変更する課金条件変更手段を備えたことを特徴と
する。

【００１０】また、この情報料課金システムにおいて、
前記課金条件変更手段は、個々の情報の対価に基づいて
１回に配信される情報の全体の対価を算出する対価算出
手段と、１回に配信される情報の量と割引率との関係を
設定する割引率設定手段と、１回に配信される情報の量
に応じて、前記割引率設定手段の設定内容を参照し、前
記対価算出手段の算出した全体の対価を補正する対価補
正手段とを備えたことを特徴とする。

【００１１】さらに、この情報料課金システムにおい
て、前記割引率設定手段には、１回に配信される情報の
中に含まれる情報の種類を加味して前記割引率との関係
が設定されていることを特徴とする。そして、これらの
情報料課金システムにおいて、前記情報通信網は課金通
信網とは異なる通信網であり、前記課金センタから情報
提供端末へ送信される情報は課金情報を含むダミーのデ
ータであることを特徴とする。

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

【００１３】こうして情報提供端末と課金センタとが接
続されると、課金センタは、配信される情報の対価に相
当する課金情報を含む情報を当該情報提供端末に対して
送信する。これによって、課金通信網を介する情報提供
端末への課金が実行されるのである。

【００１４】ここで、課金センタから情報提供端末に送
信される情報は、通常のビデオテックスシステムと同様
に、配信すべき実情報であってもよいが、情報通信網を
課金通信網と別に持っているものでは単なるダミーのデ
ータで十分である。また、情報提供端末に対して情報セ
ンタが配信する情報自体も、例えば暗号解読キーとして
の情報であってもよい。これは、情報提供端末側に予め
スクランブル情報として情報を蓄積しておき、暗号解読
キーを受信することによって情報を提供可能な形に解読
あるいは変換などして利用者に提供する様にすることも
できるからである。この場合には、課金通信網からはダ
ミーのデータを、情報通信網からは暗号解読キーを送信
するようにしてもよいし、課金通信網が情報通信網を兼
ねるならば暗号解読キーに課金情報を含ませて送信する
ようにしてもよい。

【００１５】ここまでの説明でも分かる通り、本発明の
情報料課金システムにおいて情報センタが配信する情報
は、そのまま情報提供端末からサービスとして提供され
る情報と同一である場合はもちろん、単なる暗号解読キ
ーのようなものである場合も含んでいるのである。ま
た、課金通信網と情報通信網は別々のものでもよいし、
同一のものでもよいのである。そして、情報センタと課
金センタは概念として別物の如く表現されているが、一
つのセンタの中に両機能を持たせて構成してもよいこと
はもちろんである。情報センタと課金センタとが別々に
設置される場合には、両センタ間で配信を行う際の連絡
手段が別途必要となる。

【００１６】こうした情報の配信及び課金の実行におい
て、本発明システムでは、１回に配信される情報の量に
応じて、課金情報の決定条件を変更する。よって、例え
ば、１回に配信される情報の量が多い場合にはスケール
メリットを生かした割引条件で課金条件を設定するとい
ったことを行うことができる。なお、ここでいう情報の
量とは、データ大きさとしての量と、個数という意味で
の量の両方又は一方の意味を含むものである。

【００１７】この課金条件の変更の仕方はどのようにな
っていてもよいのであるが、第２番目に上げたシステム
の様に、まずは通常の条件で情報の全体の対価を算出
し、それを設定されている割引率に関する条件と今回の
配信の条件との関係に基づいて割引率自体あるいは「１
−割引率」を求めて補正するという手法を採用した場
合、この割引の実行のために設定しておくべき情報の量
が少なくて済むというメリットがある。

【００１８】こういう手法ではないものとしては、例え
ば、それぞれの情報毎に、下記表１の様に、単独で配信
する場合の対価、他の情報と共に合計１１〜２０個で配
信する場合の対価、合計２１〜３０個で配信する場合の
対価、…といった具合いにしておき、補正ではなく割引
価格を直接算出できるようにしておいてももよい。

【００１９】

【表１】

【００２０】この例の場合、各データについてテーブル
中の対価を特定するために配信データ数の条件に応じて
毎回テーブルを参照する処理が必要となり、非常に多く
の時間が必要となるおそれがある。また、上記の様なテ
ーブルを記憶しておく必要から記憶量を増加することが
必要となる。

【００２１】これに対し、補正により対価を決定する構
成においては、通常の条件での算出自体は何が情報とし
て選ばれているのかだけで直ちに対価を算出でき、後は
割引率に関する条件を１回求めるだけで割引後の対価を
決定することができる点で、処理時間が短くなり、か
つ、割引サービスを実行することによる記憶量の増加も
少ないという点でメリットがあるのである。

【００２２】３番目に上げたシステムでの「情報の種類
を加味して割引率との関係が設定されている構成」とし
ては、例えば、新しい情報についてはまとめて配信を受
けても割引はしないが、古い情報についてだけ割引をす
るといったものを例示することができる。あるいは、新
しい情報と古い情報とをグループ分けし、新しい情報の
個数と割引率との関係、古い情報の個数と割引率の関係
をそれぞれ設定しておく様にしてもよい。

【００２３】なお、４番目に上げたシステムの様に、情
報通信網と課金通信網とを異なるものとしておくのは、
特に、情報センタに実情報を蓄積しておき、これを端末
に配信し、端末ではこの実情報自体に基づいて情報提供
サービスを行うシステムにおいて、次の点で特に優れた
作用・効果を奏する。

【００２４】即ち、実情報は、例えばカラオケ演奏用の
新曲データであるとか、ゲームソフトであるように、情
報量のかなり大きなものである場合が想定されるとき、
そういった大きな情報を配信するのに適した通信網を利
用することで、課金通信網を利用して実情報を配信する
よりも迅速であったり、データの信頼性が高かったりす
るという点で、情報提供端末が受け取るべき情報の種類
に応じた最適なシステム構成が可能となるからである。

【００２５】なお、本発明の情報料提供システムでは、
課金条件変更手段を情報センタ又は課金センタ側に持た
せてもよいし、情報提供端末側に持たせてもよい。情報
提供端末側に持たせたものとしては、次の様な情報提供
端末を用いることができる。

【００２６】情報通信網を介して情報センタと接続する
情報通信網接続手段と、前記情報センタから配信を受け
た情報を記憶しておく情報記憶手段と、課金通信網を介
して課金センタと接続する課金通信網接続手段と、前記
情報センタから情報の配信を受けようとするときに、当
該配信を受ける情報全体の対価を決定して前記課金セン
タに伝達する対価伝達手段とを備えた情報提供端末であ
って、前記対価伝達手段は、対価の決定に当たって、１
回に配信される情報の量に応じて対価の決定条件を変更
することを特徴とする情報提供端末がそれである。

【００２７】また、この情報提供端末において、前記対
価伝達手段は、個々の情報の対価に基づいて１回に配信
される情報の全体の対価を算出する対価算出手段と、１
回に配信を受ける情報の量と割引率との関係を設定する
割引率設定手段と、１回に配信を受ける情報の量に応じ
て、前記割引率設定手段の設定内容を参照し、前記対価
算出手段の算出した全体の対価を補正する対価補正手段
とを備えたものとしてもよい。

【００２８】さらに、この情報提供端末において、前記
割引率設定手段には、１回に配信される情報の中に含ま
れる情報の種類を加味して前記割引率との関係が設定さ
れているものとしてもよい。これらの場合の作用・効果
は、既に本発明システムについて説明したものと同様で
ある。

【００２９】そして、特有のメリットとしては、課金セ
ンタは端末から伝達された対価に従って課金を実行する
だけでよく、課金のための接続処理時間を短くすること
ができる点をあげることができる。これらの情報提供端
末において、配信を受けようとする情報の量を変更した
仮想条件下での対価をも決定する仮想対価決定手段と、
実際に配信を受けようとしている情報の量に応じて決定
された対価と、前記仮想条件下での対価とを対比可能に
表示する対価対比手段とを備えたものとするなら、さら
にメリットが増す。

【００３０】即ち、この情報提供端末によれば、情報提
供端末で情報の配信を受けようとするとき、予定してい
る配信量ではいくらかかり、それよりも少し増やすだけ
でどう変わるのかといったことを容易に判別することが
できるようになるのである。なお、これらの情報提供端
末においても、前記情報通信網接続手段は課金通信網接
続手段とは異なる通信網に対する接続手段としておき、
サービスとして提供する情報にはそうした情報の配信に
適した通信網を使用し、迅速性やデータの信頼性を確保
するのが望ましい。

【００３１】

【実施例】以下、本発明をネットワークカラオケシステ
ムに具体化した一実施例を図面を参照して説明する。最
初に図１を参照して、実施例としてのネットワークカラ
オケシステム及び電話事業者側設備の構成を説明する。
図１の左側が本発明のネットワークカラオケシステムで
あり、右側が電話事業者側設備である。

【００３２】図１に示すネットワークカラオケシステム
は、最小の構成例であり１台の曲データ配信用ホスト２
０、１台のカラオケ端末１０、１台のアカウント端末３
０から構成される。実際には、上記各装置はそれぞれ複
数台存在する場合もあり、１台の曲データ配信用ホスト
２０に対して、複数台のカラオケ端末１０が存在するの
が一般的である。カラオケ端末１０は電話事業者による
公衆回線５０を介して曲データ配信用ホスト２０及びア
カウント端末３０と接続できるようになっている。ま
た、このとき、アカウント端末３０とカラオケ端末１０
との間は、料金徴収代行システム５１へ接続された専用
回線５２を介して接続するように構成されている。本実
施例では、この料金徴収代行システム５１及び専用回線
５２として、ビデオテックス通信網を想定している。

【００３３】まず、カラオケ端末１０についてその構成
及び機能の概略を説明する。カラオケ端末１０は、ＲＯ
Ｍ１１、メモリとしてのＲＡＭ１２、操作パネル１３、
制御装置としてのＣＰＵ１４、モデム１５、記憶装置と
してのハードディスク１６及びカラオケ演奏制御部１７
から構成される。

【００３４】ＲＯＭ１１は、ＣＰＵ１４の動作プログラ
ムを格納する。ＲＡＭ１２は、ＣＰＵ１４のワークエリ
アである。入力手段としての操作パネル１３は、カラオ
ケ動作における選曲作業や、アカウント端末３０との接
続などの操作に使用される。ＣＰＵ１４は、カラオケ端
末装置全体の動作制御を行っている。モデム１５は、電
話事業者側設備である公衆回線網を通してアカウント端
末３０や曲データ配信用ホスト２０とデータ通信を行う
ためのものであり、デジタルデータの音声帯域への変
調、受信した音声帯域信号のデジタルデータへの復調を
行う。ハードディスク１６は、演奏に必要な曲データを
記憶・蓄積するためのものである。カラオケ演奏制御部
１７は、曲データを音声信号と字幕表示に変換して出力
するためのものである。このため、カラオケ演奏制御部
１７には、マイク１７ａ、スピーカ１７ｂ及びテレビモ
ニタ１７ｃが接続されている。

【００３５】カラオケ端末１０は、上記の様な構成から
なり、実際にカラオケ演奏を行うための装置であって、
演奏に必要な曲データを曲データ配信用ホスト２０から
有料で供給を受け、内蔵するハードディスク１６に記憶
・蓄積しておく。そして、カラオケ利用者のリクエスト
に応じて曲データをハードディスク１６から読み出し、
音声信号及び字幕表示に変換して出力する。

【００３６】このカラオケ端末１０は、カラオケ端末設
置事業者が管理する。そして、新しい曲データを曲デー
タ配信事業者から有料で供給してもらい、ハードディス
ク１６に順次記憶・蓄積して演奏可能曲数を充実させて
いく。次に、曲データ配信用ホスト２０についてその構
成及び機能の概略を説明する。

【００３７】曲データ配信用ホスト２０は、ＲＯＭ２
１、ＲＡＭ２２、ＣＰＵ２３、モデム２４及びハードデ
ィスク２５から構成される。ＲＯＭ２１は、ＣＰＵ２４
の動作プログラムを格納する。ＲＡＭ２２は、ＣＰＵ２
３のワークエリアである。ＣＰＵ２３は、曲データ配信
用ホスト装置全体の動作制御を行っている。モデム２４
は、電話事業者側設備である公衆回線網５０を通してア
カウント端末３０やカラオケ端末１０とデータ通信を行
うためのものであり、デジタルデータの音声帯域への変
調、及び受信した音声帯域信号のデジタルデータへの復
調を行う。そして、ハードディスク２５には、カラオケ
端末１０へ配信可能な曲データが記憶・蓄積されてい
る。

【００３８】曲データ配信用ホスト２０は上記の様な構
成からなり、カラオケ端末１０で使用する曲データの供
給用装置として機能する。この曲データの供給に当たっ
ては、カラオケ端末１０からの要求に対して、その曲デ
ータに対する課金処理の実行が確認されることを条件
に、公衆回線５０を通して当該カラオケ端末１０へ当該
課金完了が確認された曲データを送信する様に動作す
る。これは、曲データ配信事業者の管理する設備であ
る。

【００３９】次に、アカウント端末３０についてその構
成及び機能の概略を説明する。アカウント端末３０は、
ＲＯＭ３１、ＲＡＭ３２、制御装置としてのＣＰＵ３
３、モデム３４、記憶手段としてのハードディスク３５
及び料金徴収代行システム通信部３６から構成される。

【００４０】ＲＯＭ３１は、ＣＰＵ３４の動作プログラ
ムを格納する。ＲＡＭ３２は、ＣＰＵ３３のワークエリ
アである。ＣＰＵ３３は、アカウント端末装置全体の動
作制御を行っている。モデム３４は、電話事業者側設備
である公衆回線網を通して曲データ配信用ホスト２０と
データ通信を行うためのものであり、デジタルデータの
音声帯域への変調、及び受信した音声帯域信号のデジタ
ルデータへの復調を行う。ハードディスク３５は、カラ
オケ端末１０へ提供することができる曲データに関する
情報や、カラオケ端末１０に対する曲データの配信実
績、曲毎のデータ料を特定するための単価テーブル、さ
らにはまとめ買いをするケースでの割引条件を記録した
割引テーブルを格納している。

【００４１】単価テーブルの１例をあげると、例えば下
記表２の様なものとしておくことができる。

【００４２】

【表２】

【００４３】また、割引テーブルとしては、例えば下記
表３の様なものを用いることができる。

【００４４】

【表３】

【００４５】この場合、データ配信時には、下記数１の
如く基本単価の積算結果ΣＡ１に、割引係数Ｋ１を乗算
してデータ料金ＣＳＴが決定されることになる。

【００４６】

【数１】

【００４７】料金徴収代行システム通信部３６は、専用
回線５２によって、料金徴収代行システム５１と接続
し、料金徴収代行システム５１経由でカラオケ端末１０
とデータ通信を行うためのものである。このアカウント
端末３０も、曲データ配信事業者の設備である。従っ
て、曲データ配信用ホスト２０と一体のコンピュータで
構成してもよいし、別々に分かれたものとして構成して
もよい。本実施例では、別々の場所に設置されている場
合を想定している。

【００４８】このアカウント端末３０は、カラオケ端末
設置事業者からの曲データ配信要求を受け付け、当該カ
ラオケ端末に対する課金のための処理を実行すると共
に、課金のための処理が完了したことを曲データ配信用
ホスト２０に通知する役割を果たしている。

【００４９】このアカウント端末３０による曲データ配
信に伴う課金処理は、ビデオテックス通信システムを利
用して実行する。即ち、アカウント端末３０は、専用回
線５２及び料金徴収代行システム５１を通した課金通信
網経由で各カラオケ端末１０と接続し、各カラオケ端末
１０へと課金のための何等かの情報（課金情報）を送信
することによって当該端末に対する課金を実行する。こ
の料金は、カラオケ端末１０に対する電話料金に上乗せ
した形で、電話事業者により代行徴収され、手数料を控
除した上で曲データ配信事業者へと渡される。

【００５０】以上の様に構成された本実施例のネットワ
ークカラオケシステムでは、曲データ配信事業者からカ
ラオケ端末設置事業者への新曲データの配信が次の様に
して行われることになる。まず、カラオケ端末１０から
料金徴収代行システム５１、より具体的にいえばビデオ
テックス通信網の方を経由してアカウント端末３０に接
続する。そして、自己のＩＤコード及び新曲データ目録
の要求を送信する。これに対して、アカウント端末３０
は、受信したＩＤコードによりカラオケ端末１０を特定
し、当該端末への過去の配信実績と現在ホスト側に蓄積
されている曲データとを照合し、未配信曲目の目録を作
成する。このとき、目録は、曲のジャンル別などに作成
すると一層便利である。そして、この目録をカラオケ端
末１０へと送信する。カラオケ端末１０では、この目録
中から欲しい曲目を指定してアカウント端末３０へと配
信要求を送信する。これにより配信すべき曲データの特
定が終了し、アカウント端末３０では、要求された曲デ
ータに対するデータ料金の課金のためのダミーの課金情
報をビデオテックス通信網を介してカラオケ端末１０へ
と送信する。このダミーのデータの通信実行により、カ
ラオケ端末１０に対するビデオテックス通信システム上
の課金が実行され、後日電話料金と共に端末設置者の銀
行口座から引き落とされることになる。この課金処理の
実績（課金実績）は、アカウント端末３０及び料金徴収
代行システム５１のそれぞれに記録される。そして、ア
カウント端末３０は、この課金実績を、公衆回線５０経
由で曲データ配信用ホスト２０に転送し、課金処理の完
了を確認させる。曲データ配信用ホスト２０は、アカウ
ント端末３０から受信した課金実績に基づいて、該当す
るカラオケ端末１０をコールし、該端末へ課金の完了し
た曲データを配信する。また、電話事業者側は記録した
課金実績に基づいて、カラオケ端末設置事業者から代行
徴収したデータ料金の中から手数料を控除した残りをア
カウント端末３０の設置者である曲データ配信事業者に
渡すことになる。

【００５１】以上の様な機能を達成するための具体的処
理の内容について、カラオケ端末１０、曲データ配信用
ホスト２０及びアカウント端末３０の各ＣＰＵ１４，２
３，３３の実行する制御処理を説明する。まず、カラオ
ケ端末１０の作動を図２のフローチャートを基に説明す
る。

【００５２】電源が投入されると、このメインルーチン
が実行開始される。まず、最初のステップＳ１にて、Ｒ
ＡＭ１２の初期化、モデム１５のリセット、パネル表示
の初期化、等の装置全体の初期化を行う。次に、Ｓ２に
て、カラオケ端末１０の動作指定として、カラオケ演奏
モードが指定されたか否かをチェックする。カラオケ演
奏モードの指定があればＳ３へ移行し、同指定がなけれ
ばＳ４へ移行する。

【００５３】Ｓ３では、操作パネル１３で選曲された曲
データをハードディスク１６から読み出し、カラオケ演
奏制御部１７にて音声信号及び字幕表示に変換すること
を内容とするカラオケ演奏処理を行う。このＳ３はカラ
オケ演奏モードが解除されるまで利用客からのリクエス
ト待ちとカラオケ演奏の実行とを繰り返し行う。Ｓ３の
ステップは、カラオケ演奏モードの解除指定により終了
し、Ｓ４へと移行する。

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

【００５５】サブルーチンＳＵＢ１の最初のステップＳ
１０では、アカウント端末３０との接続を実行する。よ
り具体的には、カラオケ端末１０は、所定の通信プロト
コルに従って、まず、公衆回線５０を通じて料金徴収代
行システム５１と接続し、さらに料金徴収代行システム
５１とアカウント端末３０との間を専用回線５２を介し
て接続させることによって、アカウント端末３０との接
続を実行する。アカウント端末３０との接続処理終了
後、Ｓ１１へ移行する。

【００５６】Ｓ１１では、アカウント端末３０からメニ
ュー情報を受信する。このメニュー情報は、上述した様
に過去の配信実績とホスト側に蓄積されている曲データ
との関係からアカウント端末３０で自動作成されるもの
であって、システム中に存在する各端末毎の未配信曲の
目録である。カラオケ端末１０は、このメニュー情報の
受信完了後にＳ１２へ移行する。

【００５７】Ｓ１２では、Ｓ１１で受信したメニュー情
報を解読し、必要な曲データの配信要求を意味する様に
メニュー選択を実行し、その選択情報をアカウント端末
３０に対して送信する。メニュー選択情報送信処理の完
了後、Ｓ１３移行へする。Ｓ１３では、メニュー選択情
報に対する応答として、アカウント端末３０から選択し
た曲データのデータ料が課金されたことを意味するダミ
ーのデータであるところの課金情報を受信する。この課
金情報自体は曲データではないので、この段階では新曲
の蓄積は終っていない。この課金情報の受信完了後、Ｓ
１４へ移行し、アカウント端末３０との接続解除処理を
行う。

【００５８】こうしてサブルーチンＳＵＢ１が完了する
と、図２のフローチャートのＳ６へ移行する。Ｓ６で
は、曲データ配信用ホスト２０からの接続要求が発生し
ているか否かをチェックする。発生していればＳ７へ移
行し、そうでなければＳ２へ移行し上記の処理を繰り返
し行う。

【００５９】Ｓ７では、曲データ配信用ホスト２０から
配信される曲データを受信して内蔵のハードディスク１
６へ記録する処理を行うためにサブルーチンＳＵＢ２を
コールする。サブルーチンＳＵＢ２の処理を図４のフロ
ーチャートにて説明する。サブルーチンＳＵＢ２の最初
のステップＳ２０では、曲データ配信用ホスト２０から
の呼出しに応答して接続を行う。接続完了後、Ｓ２１へ
移行し、曲データ配信用ホスト２０から送信される曲デ
ータの受信を行う。そして、曲データ受信処理完了後、
Ｓ２２へ移行し、Ｓ２１で受信した曲データをハードデ
ィスク１６へセーブする。こうして受信した曲データの
ハードディスク１６へのセーブが完了したらＳ２３へ移
行し、曲データ配信用ホスト２０との接続を解除する。

【００６０】この後、サブルーチンＳＵＢ２をリターン
して、図２のフローチャートのＳ２のステップへ移行
し、電源オフとされるまでの間、Ｓ２以下の処理を繰り
返し実行する。以上がカラオケ端末１０のＣＰＵ１４の
作動であり、カラオケ演奏、曲データの配信要求、及び
配信された曲データの受信の各処理を行う。

【００６１】次に、曲データ配信用ホスト２０の作動を
図５のフローチャートを基に説明する。曲データ配信用
ホスト２０では、電源投入後、まずＳ３０のステップか
ら実行する。Ｓ３０では、ＲＡＭ２２の初期化、モデム
２４のリセット、等の装置全体の初期化を行う。Ｓ３０
の処理を終了後、Ｓ３１へ移行し、アカウント端末３０
からの接続要求があるかどうかを調べる。あればＳ３２
へ移行し、なければＳ３１の処理を繰り返す。

【００６２】Ｓ３２では、アカウント端末３０からの接
続要求に対して同端末３０との接続を行う。接続完了
後、Ｓ３３へ移行し、アカウント端末３０から曲データ
配信要求情報を受信する。曲データ配信要求情報とは、
カラオケ端末１０がアカウント端末３０に料金徴収代行
システム５１を経由して接続し、課金が完了した曲デー
タを特定するための情報のことで、具体的には複数のカ
ラオケ端末が存在するとき、どのカラオケ端末がどの曲
データを購入したのか、というたことが判明する様に構
成された情報であって、アカウント端末３０で記録され
る課金実績と一致する情報である。曲データ配信用ホス
ト２０は、アカウント端末３０から受信したこの課金実
績に対応する曲データ配信要求情報を基にして、該当す
るカラオケ端末へ対応する曲データを送信する処理を行
うことができるようになるのである。

【００６３】曲データ配信要求情報の受信完了後はＳ３
４へ移行し、アカウント端末３０との接続を解除する。
そして、接続解除完了後、Ｓ３５へ移行し、曲データ配
信要求情報に基づいて、曲データを配信すべきカラオケ
端末１０を、公衆回線５０を経由して呼び出す。同処理
完了後、Ｓ３６へ移行し、曲データ配信要求情報により
特定された曲データを、前記接続したカラオケ端末１０
へと送信する。

【００６４】こうしてカラオケ端末１０に対し、該端末
が購入した曲データの送信が完了したらＳ３７へ移行
し、当該カラオケ端末１０との接続を解除する。接続解
除完了後、Ｓ３１へ移行し、上記処理を繰り返す。以上
が曲データ配信用ホスト２０のＣＰＵ２３の作動であ
り、アカウント端末３０から曲データ配信要求情報を受
け取り、その内容を参照した上で、アカウント端末３０
による課金処理を受けたカラオケ端末１０に対して、こ
の課金処理によって当該カラオケ端末１０が購入した曲
データを送信する処理を行うのである。

【００６５】次に、アカウント端末３０の作動を図６の
フローチャートを基に説明する。アカウント端末３０で
は、電源投入後、Ｓ４０のステップから実行する。Ｓ４
０では、ＲＡＭ３２の初期化、モデム３４のリセット、
等の装置全体の初期化を行う。そして、Ｓ４１へ移行
し、カラオケ端末１０から料金徴収代行システム５１を
経由した接続要求があるかどうかを調べる。あればＳ４
２へ移行し、なければＳ４１の処理を繰り返し、待機状
態となる。

【００６６】Ｓ４２では、カラオケ端末１０からの接続
要求に対して当該カラオケ端末１０との接続を行う。接
続完了後、Ｓ４３へ移行し、当該カラオケ端末１０に対
して未配信となっている曲データのメニュー情報を送信
する。送信処理完了後、Ｓ４４へ移行し、カラオケ端末
１０からの応答であるメニュー選択情報を受信する。

【００６７】このメニュー選択情報の受信完了後、Ｓ４
５へ移行し、メニュー選択情報に基づいて選択された曲
データを特定し、これに対するデータ料の課金実行のた
めのダミーのデータを送信する。この課金情報はダミー
のデータであるから、カラオケ端末１０にとっては意味
のないデータであるが、アカウント端末３０及び料金徴
収代行システム５１にとっては、どのカラオケ端末１０
にどの曲データについて課金が実行されたのかを判別す
るための情報として大切な意味を有する。アカウント端
末３０は、この課金情報を課金実績として記録すると共
に、同情報を基に、どのカラオケ端末１０にどの曲デー
タを配信すべきかを判断し、これを曲データ配信要求情
報として曲データ配信用ホスト２０に通知する。カラオ
ケ端末１０とアカウント端末３０の通信路の間に存在す
る料金徴収代行システム５１は、この課金情報を基に、
該当するカラオケ端末１０の設置事業者に対して電話料
金に上乗せした格好で情報料の徴収を行うのである。

【００６８】このＳ４５の課金情報の送信の処理をさら
に詳細に示すと図７のようになる。まず最初に曲数カウ
ンタＣＮＴ及びデータ料金ＣＳＴを初期化し（Ｓ５
１）、続いて、選択された曲番号の中から一つを抽出す
ると共に曲数カウンタＣＮＴをインクリメントする（Ｓ
５２）。そして、この抽出した曲番号にて表２を参照し
て当該曲の基本単価Ａを決定してこれをデータ料金ＣＳ
Ｔに加算する（Ｓ５３）。そして、選択された全ての曲
番号についてこれらの処理が終了するまでＳ５２，Ｓ５
３の処理を繰り返す（Ｓ５４）。

【００６９】選択された曲番号の全てについてＳ５２，
Ｓ５３の処理が実行できたら、次に、曲数カウンタＣＮ
Ｔの値に基づいて表３を参照し、割引条件Ｋ１を決定す
る（Ｓ５５）。そして、この割引条件Ｋ１を乗算して最
終的なデータ料金ＣＳＴを決定し（Ｓ５６）、さらに、
このデータ料金を意味する課金用のダミーデータを決定
する（Ｓ５７）。この課金用のダミーデータも、アカウ
ント端末３０のハードディスク３５内に予めテーブル化
するなどして記憶してある。

【００７０】こうして今回の取引における課金用ダミー
データを決定できたら、これを送信する（Ｓ５８）。こ
うしてＳ４５の課金情報の送信が完了したら、Ｓ４６へ
移行し、カラオケ端末１０との接続を解除する。接続解
除処理が完了後、Ｓ４７へ移行し、Ｓ４２〜Ｓ４４の処
理の結果である課金実績を曲データ配信要求情報として
メモリに記録する。また、ハードディスク３５内の配信
実績への追加も実行する。この処理終了後、Ｓ４８へ移
行する。

【００７１】Ｓ４８では、曲データ配信用ホスト２０を
公衆回線経由で呼び出し、データ転送を行うための接続
を行う。接続処理完了後、Ｓ４９へ移行し、Ｓ４７でメ
モリに記録した「曲データ配信要求情報」＝「選択曲番
号」を曲データ配信用ホスト２０へ送信する。この送信
処理の完了後、Ｓ５０へ移行し、曲データ配信用ホスト
２０との接続を解除する。接続解除処理完了後、Ｓ４１
へ移行し、上記の処理を繰り返す。

【００７２】以上がアカウント端末３０のＣＰＵ３３の
作動であり、カラオケ端末１０からの料金徴収代行シス
テム５１を経由した接続要求に対して接続を行い、指定
された曲データに対応する課金情報を送信すると共に課
金実績を記録し、これを曲データ配信用ホスト２０に受
け渡すことによって要求された曲データをカラオケ端末
に配信させるのである。

【００７３】最後に、電話事業者側設備である料金徴収
代行システム５１の機能を説明する。上述の様に、カラ
オケ端末１０が曲データをアカウント端末３０から購入
する場合には、この料金徴収代行システム５１を経由し
てデータのやり取りを行う。この時、料金徴収代行シス
テム５１は、どのカラオケ端末１０が、どのアカウント
端末３０から、どの有料ダミーデータを購入したかにつ
いての情報を、データのやり取りの途中に位置する立場
から課金実績として取得する。この課金実績に基づき、
本ネットワークカラオケシステムでのものとして予め登
録されている料金リストを参照し、情報提供料金を算出
する。なお、ここで予め登録されている料金リストは、
ダミーデータの種類と料金との関係をテーブル化したも
のである。

【００７４】電話事業者は、この算出した情報提供料金
を、有料ダミーデータを読み出したカラオケ端末１０の
所有者であるカラオケ端末設置事業者に対する電話料金
請求時にこれに上乗せする形で徴収し、情報提供者であ
る曲データ配信事業者へと渡すサービスを行っている。
これ自体は、ＮＴＴで行っているビデオテックスとして
よく知られている。このように本実施例によれば、カラ
オケ端末１０は、アカウント端末３０に対して電話事業
者側の料金徴収代行システム５１を経由して接続し、ダ
ミーのデータである課金情報を受信することで、曲デー
タ配信用ホスト２０に対する曲データの配信を要求する
ことができる。その結果として、アカウント端末３０
は、どのカラオケ端末１０がどの曲データを購入したの
かという情報を曲データ配信用ホスト２０に自動的に通
知し、同通知を受信した曲データ配信用ホスト２０は、
課金処理の終っているカラオケ端末１０へと当該端末が
購入した曲データを配信することになる。更に曲データ
の販売料金の徴収は、電話事業者の料金徴収代行システ
ムによって行うことができる。

【００７５】以上説明したことから明かなように、本実
施例のネットワークカラオケシステムによれば、カラオ
ケ端末設置事業者による曲データの配信要求に対してそ
の受付処理を自動的に行い、さらに曲データ配信事業者
による曲データ配信に伴う料金徴収については電話事業
者による代行サービスを利用することができ、これらの
ことから曲データ配信事業者の負担を軽減することがで
きる。

【００７６】しかも、かかる自動化されたデータ販売シ
ステムを構築したにも拘らず、対面販売などで実施され
るようなまとめ買いに対する割引サービスをも合理的に
実行することができる。ところで、上記の実施例では、
どのジャンルの曲データも一括してまとめ買い割引の対
象としたが、次の様に構成することもできる。

【００７７】曲数カウンタＣＮＴ及びデータ料金ＣＳＴ
を、割引可能ジャンルに対するものＣＮＴ１，ＣＳＴ１
と不可能ジャンルに対するものＣＮＴ２，ＣＳＴ２と分
けて設けておき、図８に示すように、最初に各曲数カウ
ンタＣＮＴ１，ＣＮＴ２及びデータ料金ＣＳＴ１，ＣＳ
Ｔ２を初期化し（Ｓ６１）、続いて、選択された曲番号
の中から一つを抽出すると共にジャンル判定を行う（Ｓ
６２）。ジャンル判定は、例えば表２に示した様に曲番
号の最初の一桁めで判明するようにしておくなどすれば
簡単に実行できる。

【００７８】こうしてジャンル判定ができたら、当該曲
は割引対象ジャンルであるか否かに応じてＳ６４とＳ６
５とに処理を分岐する（Ｓ６３）。割引対象ジャンルで
ある場合には、カウンタＣＮＴ１をインクリメントする
と共にデータ料金ＣＳＴ１の方に今回の曲番号に基づい
て表２から特定できた基本単価Ａを加算する（Ｓ６
４）。一方、割引対象ではないジャンルである場合に
は、カウンタＣＮＴ２の方をインクリメントすると共に
データ料金ＣＳＴ２の方に今回の曲番号に基づいて表２
から特定できた基本単価Ａを加算する（Ｓ６５）。

【００７９】そして、選択された全ての曲番号について
これらの処理が終了するまでＳ６２〜Ｓ６５の処理を繰
り返す（Ｓ６６）。選択された曲番号の全てについてＳ
６２〜Ｓ６５の処理が実行できたら、次に、曲数カウン
タＣＮＴ１の方の値に基づいて表３を参照し、割引条件
Ｋ１を決定する（Ｓ６７）。そして、この割引条件Ｋ１
をＣＳＴ１の方に乗算したものと、ＣＳＴ２とを加えて
最終的なデータ料金ＣＳＴを決定し（Ｓ６８）、さら
に、このデータ料金を意味する課金用のダミーデータを
決定し、送信する（Ｓ６９，Ｓ７０）。

【００８０】このように、特定ジャンルについてだけま
とめ買い割引の対象とすることもできるのである。な
お、本実施例を通信シーケンス図で示すと、図９〜図１
１の様になる。図９は、カラオケ端末１０とアカウント
端末（課金センタ）３０との間での通信シーケンスを示
しており、まず、カラオケ端末１０がビデオテックス通
信網を介して課金センタ３０に対して発呼し、接続でき
た後にパスワードを送信する。

【００８１】課金センタ３０ではこのパスワードに基づ
いて端末照合を行い、ネットワークカラオケシステム内
のものとして登録されている端末であれば、照合正常の
旨を返送する。カラオケ端末１０はこの照合正常を受信
して課金センタ３０が受付可能状態となって後に、新曲
データの有無を問い合わせる。

【００８２】課金センタ３０では、この問い合わせを受
け付けて当該カラオケ端末に対する新曲データを検索
し、問い合わせの回答をカラオケ端末１０に送信する。
つまり、新曲データが有るか無いかを示す回答である。
カラオケ端末１０では、この回答結果に基づいて新曲デ
ータが有るか無いか判断し、新曲データが有る場合には
課金センタ３０に対して新曲データの購入申込に相当す
る要求を送信する。

【００８３】課金センタ３０は、この要求に応じて購入
価格に相当する料金を課金するためのダミーのデータを
カラオケ端末１０に向けて送信する。これを受けてカラ
オケ端末１０は課金センタ３０との接続を遮断する。以
上の処理が終了すると、課金センタ３０と曲データ配信
用ホスト（情報センタ）２０との間で図９に示す通信が
実行され、まず、課金センタ３０が公衆回線を介して情
報センタ２０に発呼・接続し、新曲データの配信要求を
送信する。情報センタ２０は、この配信要求を受信した
ら、受信完了を返信する。これを受けて、課金センタ３
０は情報センタ２０との接続を遮断する。

【００８４】以上の処理が終了すると、今度は情報セン
タ２０とカラオケ端末１０との間で図１０に示す通信が
実行され、まず、情報センタ２０が公衆回線を介してカ
ラオケ端末１０に発呼・接続し、配信要求により特定さ
れた新曲データを送信する。そして、カラオケ端末１０
からの受信完了を受けて、接続を遮断する。

【００８５】こうして、「カラオケ端末１０」→「課金
センタ３０」→「情報センタ２０」→「カラオケ端末１
０」という順番で通信が受け渡され、新曲データの有料
配信が実行されている。次に、第２実施例のネットワー
クカラオケシステムについて説明する。この第２実施例
のシステム構成は、第１実施例とどうようであるが、次
の点で異なっている。

【００８６】まず、その概略から説明すると、第１実施
例では、アカウント端末３０から受信した新曲メニュー
に掲載されている全ての曲データを購入することが前提
であったが、この第２実施例では、新曲メニューの中か
ら所望の曲データだけを選択して要求を出すようになっ
ている。そして、表２，表３のテーブルは、カラオケ端
末１０側でも保持している点で第１実施例と異なってい
る。

【００８７】そして、カラオケ端末１０では、新曲メニ
ューを受信したらＳ１２のメニュー選択情報送信処理の
詳細として、図１２，図１３に示すような処理を実行す
る。まず、メニュー情報を付属のテレビモニタ１７ｃに
表示する（Ｓ８１）。そして、カラオケ端末設置者によ
る曲番号の選択を待つ（Ｓ８２）。曲番号が選択された
らこれをメニュー選択情報としてＲＡＭにセットし（Ｓ
８３）、次の選曲を行うか否かを画面表示する（Ｓ８
４）。次の選曲があるならＳ８１へ戻る。選曲終了がキ
ー入力されたらＳ８５へ移行し、曲数カウンタＣＮＴ及
びデータ料金ＣＳＴを初期化し、続いて、ＲＡＭにセッ
トされた曲番号の中から一つを抽出すると共に曲数カウ
ンタＣＮＴをインクリメントする（Ｓ８６）。そして、
この抽出した曲番号にて表２を参照して当該曲の基本単
価Ａを決定してこれをデータ料金ＣＳＴに加算する（Ｓ
８７）。そして、選択された全ての曲番号についてこれ
らの処理が終了するまでＳ８６，Ｓ８７の処理を繰り返
す（Ｓ８８）。

【００８８】選択された曲番号の全てについてＳ８６，
Ｓ８７の処理が実行できたら、次に、曲数カウンタＣＮ
Ｔの値に基づいて表３を参照し、割引条件Ｋ１を決定す
る（Ｓ８９）。そして、この割引条件Ｋ１を乗算して今
回の選択結果としてのデータ料金ＣＳＴを決定し（Ｓ９
０）、これをテレビモニタ１７ｃに表示する（Ｓ９
１）。

【００８９】次に、選曲増減時の参考料金表示処理を行
うか否かを問い合わせるメッセージを表示し（Ｓ９
２）、入力を待つ（Ｓ９３）。参考料金の表示不要と入
力された場合には、ＲＡＭにセットされている選択情報
をアカウント端末３０へ向けて送信する（Ｓ９４）。

【００９０】一方、参考料金表示要と入力されたら、サ
ブルーチンＳＵＢ３をコールする（Ｓ９５）。サブルー
チンＳＵＢ３は、図１４に示すように構成され、増減い
ずれの参考料金の表示を望んでいるのかを問い合わせる
メッセージを表示して入力を待つ（Ｓ１０１）。増が入
力されたら、ＲＡＭにセットされている選択情報を元
に、当該未選択曲を特定する（Ｓ１０２）。そして、次
に、どのジャンルについて参考料金を表示するのかを問
い合わせるメッセージを表示して入力を待ち（Ｓ１０
３）、ジャンル指定に応じてＳ１０２で特定した未選択
曲の中から当該ジャンルの最大増加曲数を決定し（Ｓ１
０４）、続いて、この最大増加曲数内で、例えば２曲，
４曲，…と増加したことを仮定して仮想コスト計算を実
行し（Ｓ１０５）、２曲増加時，４曲増加時，…の仮想
コストをＳ９０で決定した料金の下に続けて表示する
（Ｓ１０６）。そして、選択情報の変更をするか否かを
問い合わせるメッセージを表示して入力を待ち（Ｓ１０
７）、変更不要が入力されたならば、Ｓ９４へ移行して
選択情報をそのままアカウント端末３０へ向けて送信す
る。一方、変更要が入力されたならば、追加曲番号の入
力を求め（Ｓ１０８）、追加曲番号の入力に応じて選択
情報の追加とコスト計算とをやり直してからＳ９４へ移
行する（Ｓ１０９）。

【００９１】Ｓ１０１において減が選択されたならば、
図１５に示すように、どのジャンルについて参考料金を
表示するのかを問い合わせるメッセージを表示し（Ｓ１
１１）、ジャンル指定に応じてＲＡＭにセットされてい
る選択情報の中から当該ジャンルの最大減少曲数を決定
し（Ｓ１１２）、続いて、この最大減少曲数内で、例え
ば２曲，４曲，…と減少したことを仮定してコスト計算
を実行し（Ｓ１１３）、２曲減少時の料金，４曲減少時
の料金，…をＳ９０で決定した料金の下に続けて表示す
る（Ｓ１１４）。そして、選択情報の変更をするか否か
を問い合わせるメッセージを表示し（Ｓ１１５）、変更
不要が入力されたならば、Ｓ９４へ移行して選択情報を
そのままアカウント端末３０へ向けて送信する。一方、
変更要が入力されたならば、削除すべき曲番号の入力を
求め（Ｓ１１６）、選択情報の削除とコスト計算とをや
り直してからＳ９４へ移行する（Ｓ１１７）。

【００９２】以上の様に、この第２実施例によれば、カ
ラオケ端末１０側でもコスト計算をすることができ、し
かも、まとめ買いの量を変更した場合の仮想コストも確
認できる。よって、カラオケ端末設置事業者が、自らコ
スト計画を立てながら最適な新曲データ購入を行うこと
ができる。

【００９３】次に、第３実施例について説明する。この
第３実施例のネットワークカラオケシステムは、図１６
に示すように、情報センタ１１０と複数のカラオケ端末
１３０とが、課金通信網１２０を介して接続されてい
る。課金通信網１２０は、第１，第２実施例と同様のビ
デオテックス通信網である。

【００９４】カラオケ端末１３０は、図１７に示すよう
に、制御装置としてのＣＰＵ１３１と、記憶装置として
のハードディスク１３２と、音源１３３及びアンプ１３
４と、画面表示装置１３５と、モデム１３６とから構成
される。画面表示制御装置１３５にはテレビモニタ１３
７が、アンプ１３４にはスピーカ１３８とマイクロフォ
ン１３９が接続されている。

【００９５】なお、ハードディスク１３２には数千曲程
度のカラオケ曲データが記憶されており、１曲分のカラ
オケ曲データは、曲同士を識別するための識別情報であ
る曲番号情報と、実体情報とから構成されている。この
内の実体情報は、伴奏音楽の情報であるＭＩＤＩ（Musi
cal Instrument Digital Interface）規格の演奏情報
や、歌詞情報及び背景映像情報からなっている。背景映
像情報は曲毎に対応した映像情報を符号化したものであ
る。また、このカラオケ曲データの目録に相当するメニ
ュー情報も記憶している。

【００９６】そして、このカラオケ曲データはそのまま
では使用できないようにされている。使用するために
は、課金通信網１２０を介して情報センタ１１０と接続
し、暗号解読キーの配信及び課金を受けなければならな
いように構成されている。この暗号解読キーは、一度に
１個だけ配信を受けることもできるし、多数個をまとめ
て配信してもらうこともできる。

【００９７】カラオケ端末１３０には、また、表２，表
３に示した様な基本単価テーブル及び割引条件テーブル
が格納されている。そして、図１８に示す様なプログラ
ムを実行することにより、情報センタから暗号解読キー
の配信を受ける様に構成されている。

【００９８】まず、カラオケ曲データの目録に相当する
メニュー情報を読み出して表示し、データの選択入力を
待つ（Ｓ１２１）。そして、データの選択入力に対応し
て、第２実施例のＳ８３〜Ｓ９０と同様にコスト計算を
実行し（Ｓ１２２）、計算結果をテレビモニタ１３７に
表示する（Ｓ１２３）。

【００９９】そして、この計算結果でよいか否かを問い
合わせ（Ｓ１２４）、ＯＫならビデオテックス通信網１
２０にて情報センタ１１０と接続してデータ選択結果及
びコスト計算結果を送信する（Ｓ１２５）。情報センタ
１１０は、このデータ選択結果及びコスト計算結果を受
信したら、データ選択結果に対応する暗号解読キー群に
コスト計算結果に対応する課金情報を付与して返信して
来るので、これを受信してストアし、接続を切る（Ｓ１
２６，Ｓ１２７）。そして、この暗号解読キーを用いて
カラオケ曲データのスクランブルを解除し、カラオケ演
奏を実施する（Ｓ１２８）。

【０１００】なお、Ｓ１２４でＮＯと入力された場合に
は、終了か否かを問い合わせ（Ｓ１２９）、その結果に
応じてＳ１２１へ戻るかあるいは本ルーチンを処理を終
了する。この様に、本発明は、蓄積型のネットワークカ
ラオケシステムにおいても適用することができ、この場
合もまとめて暗号解読キーを購入することによって第
１，第２実施例と同様の効果を達成することができる。

【０１０１】以上本発明のいくつかの実施例を説明した
が、本発明はこれにのみ限定されるわけではない。例え
ば、第１実施例における図９〜図１１の通信シーケンス
に変えて、次の様に構成することもできる。

【０１０２】図１９は、変形例としてのカラオケ端末１
０と課金センタ３０及び情報センタ２０との間での通信
シーケンスを示している。カラオケ端末１０がビデオテ
ックス通信網を介して課金センタ３０に対して発呼・接
続し、切断するまでの処理は実施例と同様であるが、こ
の後の処理が異なっている。カラオケ端末１０は、課金
情報を受け取ってビデオテックス通信網の方の回線を遮
断すると、次に、情報センタ２０をコールして公衆回線
網により接続する。そして、新曲データの配信要求を送
信する。情報センタ２０は、この配信要求を受信した
ら、配信要求により特定された新曲データを送信する。
そして、カラオケ端末１０は、この新曲データを受信完
了した後に、情報センタ２０との接続を遮断する。

【０１０３】この様に、課金センタ３０から情報センタ
２０への情報の受渡しに変えて、カラオケ端末１０が直
接情報センタ２０へと配信要求を送り、新曲データの有
料配信を実行するようにしてもよいのである。あるい
は、図２０に示すように、カラオケ端末１０が公衆回線
網を介して最初に情報センタ２０に対して発呼・接続
し、新曲メニューを要求し、受信した時点ビデオテック
ス通信網の方を介して課金センタ３０を呼び出し、メニ
ュー選択情報を送信して課金情報を受信するのをまって
ビデオテックス通信網の方を切断し、情報センタ２０に
対して課金完了に伴う新曲データの配信要求を送信し、
新曲データを受信完了したら、公衆回線の方を切断する
といった手順にしてもよい。

【０１０４】この様に、課金センタ３０から情報センタ
２０への情報の受渡しに変えて、カラオケ端末１０が直
接情報センタ２０へと配信要求を送り、新曲データの有
料配信を実行するようにしてもよいのである。以上の他
にも、本発明の要旨を逸脱しない範囲内において各種の
通信シーケンスを採用することができる。

【０１０５】また、実施例では、カラオケ端末１０への
配信実績に基づいて、未配信曲目リストの様なものを作
成して送信することとしていたが、アカウント端末３０
に新曲データのメニューだけが記憶されるようにしてお
き、カラオケ端末１０からの問い合わせに対して直ちに
新曲メニューを送信する様にしてもよい。あるいは、ホ
スト２０の記憶・蓄積している全曲の中から任意の曲デ
ータを選択できるような形でメニューを送信するもので
あっても構わない。

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

【図面の簡単な説明】

【図１】 第１実施例のネットワークカラオケシステム
のブロック図である。

【図２】 第１実施例のカラオケ端末メイン処理フロー
チャート図である。

【図３】 第１実施例のカラオケ端末サブルーチンＳＵ
Ｂ１処理フローチャート図である。

【図４】 第１実施例のカラオケ端末サブルーチンＳＵ
Ｂ２処理フローチャート図である。

【図５】 第１実施例の曲データ配信用ホストメイン処
理フローチャート図である。

【図６】 第１実施例のアカウント端末メイン処理フロ
ーチャート図である。

【図７】 第１実施例のアカウント端末でのコスト計算
処理フローチャート図である。

【図８】 第１実施例のアカウント端末でのコスト計算
処理の他のフローチャート図である。

【図９】 第１実施例における通信シーケンス図であ
る。

【図１０】 第１実施例における通信シーケンス図であ
る。

【図１１】 第１実施例における通信シーケンス図であ
る。

【図１２】 第２実施例のカラオケ端末でのコスト計算
処理フローチャート図である。

【図１３】 第２実施例のカラオケ端末でのコスト計算
処理フローチャート図である。

【図１４】 第１実施例のカラオケ端末サブルーチンＳ
ＵＢ３処理フローチャート図である。

【図１５】 第１実施例のカラオケ端末サブルーチンＳ
ＵＢ３処理フローチャート図である。

【図１６】 第３実施例のネットワークカラオケシステ
ムのブロック図である。

【図１７】 第３実施例のネットワークカラオケシステ
ムのカラオケ端末のブロック図である。

【図１８】 第３実施例のカラオケ端末でのメインルー
チンフローチャート図である。

【図１９】 変形例における通信シーケンス図である。

【図２０】 変形例における通信シーケンス図である。

【符号の説明】

１０・・・カラオケ端末、１３・・・操作パネル、１５
・・・モデム、１６・・・ハードディスク、１７・・・
カラオケ演奏制御部、１７ａ・・・マイク、１７ｂ・・
・スピーカ、１７ｃ・・・テレビモニタ、２０・・・曲
データ配信用ホスト、２４・・・モデム、２５・・・ハ
ードディスク、３０・・・アカウント端末、３４・・・
モデム、３５・・・ハードディスク、３６・・・料金徴
収代行システム通信部、５０・・・公衆回線網、５１・
・・料金徴収代行システム、５２・・・専用回線、１１
０・・・情報センタ、１２０・・・課金通信網、１３０
・・・カラオケ端末、１３１・・・ＣＰＵ、１３２・・
・ハードディスク、１３３・・・音源、１３４・・・ア
ンプ、１３５・・・画面表示装置、１３６・・・モデ
ム、１３７・・・テレビモニタ１３７、１３８・・・ス
ピーカ、１３９・・・マイクロフォン。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 庁内整理番号 ＦＩ 技術表示箇所 Ｈ０４Ｍ 11/08 Ｈ０４Ｎ 7/16 Ｃ 7/173

Claims (9)

【特許請求の範囲】
1. 【請求項１】 情報を蓄積している情報センタと、 該情報センタから情報通信網を介して配信された情報に
   基づいて利用者に情報提供サービスを実行し得るように
   されている情報提供端末と、 該情報提供端末が情報センタから情報の配信を受けると
   き、当該情報提供端末と課金通信網を介して接続し、該
   配信される情報の対価に相当する課金情報を含む情報を
   当該情報提供端末に対して送信することにより端末に対
   する課金を実行する課金センタとを備え、 前記情報提供端末は、情報センタから情報の配信を受け
   ようとするときにその旨を要求する配信要求手段を備え
   る情報料課金システムであって、 １回に配信される情報の量に応じて、前記課金情報の決
   定条件を変更する課金条件変更手段を備えたことを特徴
   とする情報料課金システム。
2. 【請求項２】 請求項１に記載の情報料課金システムに
   おいて、前記課金条件変更手段は、 個々の情報の対価に基づいて１回に配信される情報の全
   体の対価を算出する対価算出手段と、 １回に配信される情報の量と割引率との関係を設定する
   割引率設定手段と、 １回に配信される情報の量に応じて、前記割引率設定手
   段の設定内容を参照し、前記対価算出手段の算出した全
   体の対価を補正する対価補正手段とを備えたことを特徴
   とする情報料課金システム。
3. 【請求項３】 請求項２に記載の情報料課金システムに
   おいて、前記割引率設定手段には、１回に配信される情
   報の中に含まれる情報の種類を加味して前記割引率との
   関係が設定されていることを特徴とする情報料課金シス
   テム。
4. 【請求項４】 請求項１〜請求項３のいずれかに記載の
   情報料課金システムにおいて、前記情報通信網は課金通
   信網とは異なる通信網であり、前記課金センタから情報
   提供端末へ送信される情報は課金情報を含むダミーのデ
   ータであることを特徴とする情報料課金システム。
5. 【請求項５】 情報通信網を介して情報センタと接続す
   る情報通信網接続手段と、 前記情報センタから配信を受けた情報を記憶しておく情
   報記憶手段と、 課金通信網を介して課金センタと接続する課金通信網接
   続手段と、 前記情報センタから情報の配信を受けようとするとき
   に、当該配信を受ける情報全体の対価を決定して前記課
   金センタに伝達する対価伝達手段とを備えた情報提供端
   末であって、 前記対価伝達手段は、対価の決定に当たって、１回に配
   信される情報の量に応じて対価の決定条件を変更するこ
   とを特徴とする情報提供端末。
6. 【請求項６】 請求項５に記載の情報提供端末におい
   て、前記対価伝達手段は、 個々の情報の対価に基づいて１回に配信される情報の全
   体の対価を算出する対価算出手段と、 １回に配信を受ける情報の量と割引率との関係を設定す
   る割引率設定手段と、 １回に配信を受ける情報の量に応じて、前記割引率設定
   手段の設定内容を参照し、前記対価算出手段の算出した
   全体の対価を補正する対価補正手段とを備えたことを特
   徴とする情報提供端末。
7. 【請求項７】 請求項６に記載の情報提供端末におい
   て、前記割引率設定手段には、１回に配信される情報の
   中に含まれる情報の種類を加味して前記割引率との関係
   が設定されていることを特徴とする情報提供端末。
8. 【請求項８】 請求項５〜請求項６のいずれかに記載の
   情報提供端末において、 配信を受けようとする情報の量を変更した仮想条件下で
   の対価をも決定する仮想対価決定手段と、 実際に配信を受けようとしている情報の量に応じて決定
   された対価と、前記仮想条件下での対価とを対比可能に
   表示する対価対比手段とを備えたことを特徴とする情報
   提供端末。
9. 【請求項９】 請求項５〜請求項８のいずれかに記載の
   情報提供端末において、前記情報通信網接続手段は課金
   通信網接続手段とは異なる通信網に対する接続手段であ
   ることを特徴とする情報提供端末。