JPH09116650A - 放送センタ - Google Patents

Abstract

(57)【要約】 【課題】 利用者自身がリアルタイムで課金金額を知る
ことができるようにすることによって、利用者の便宜を
向上させ、放送システムの利用促進を図る。 【解決手段】 本放送センタ１０は、音声応答装置２０
が、視聴者から個別になされたリクエストを受信し、ホ
ストコンピュータ１１内のＣＰＵメモリにデータとして
自動的に記憶させる。そして、放送手段１６が、ＣＰＵ
メモリに記憶されているリクエストに応じたカラオケ曲
を所定の順番に従って順次放送していく。また、外部記
憶装置１２には、音声応答装置２０によってＣＰＵメモ
リに記憶させたリクエストに対応する所定の料金を課金
するための実績情報を、放送要求をした視聴者毎に記憶
しておく。この実績情報に基づいて別途所定の課金や料
金徴収が実行される。また、視聴者から要求があれば、
視聴者が希望する期間における課金金額が電話機を介し
て知らされる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、視聴者から個別に
なされた放送要求に応じた放送用情報を所定の順番に従
って順次放送していくリクエスト応答機能付きの放送セ
ンタに係り、特にその放送要求に対して所定の料金が課
される場合に用いて有効な放送センタに関する。

【０００２】

【従来の技術および発明が解決しようとする課題】現
在、ＣＡＴＶシステム等のローカルなテレビジョン放送
センタと加入者端末との間において、双方向テレビジョ
ンと呼ばれるＴＶ放送の新しい形態が普及しつつある。
そして、このようなシステムの放送センタは、決められ
た時刻に決められた情報を流すだけでなく、視聴者から
個別になされた放送要求に応じた放送用情報を、所定の
順番に従って順次放送していくリクエスト応答機能も備
えるようになってきている。例えば、カラオケ番組と呼
ばれるカラオケ情報の放送のみを取り扱う番組時間枠
（もしくは設けられた専用のチャンネル）等が採用され
ており、この番組においては視聴者からのリクエストを
電話等を介して受け付け、そのリクエストに応じたカラ
オケ情報を放送するといったことである。

【０００３】このようにリクエストに応じた情報を放送
する場合には、いわゆる定量制の料金制度ではなく、従
量制の料金制度を導入する必要性が出てくる。つまり、
リクエストした利用者が、その料金を負担する（支払
う）のである。ところで、この場合の料金徴収について
は、通常、情報提供料金を最終的に徴収する側（以下、
管理者とも呼ぶ。）の主導で行われ、また現状のＣＡＴ
Ｖシステムでも実施されているように月毎に料金を支払
う契約が多いので、リクエストした利用者は課金結果で
ある請求額を後で一方的に知らされるのみである。つま
り、現状での料金回収のシステムは、利用者側に請求書
を送り、その送られてきた請求書に記載された金額を利
用者自ら所定の場所に出向いて支払うか、あるいは管理
者側の料金回収スタッフが利用者側に直接出向いて、そ
の場で請求金額を告げて徴収するか、いわゆる金融機関
での自動引き落しシステムを利用するかである。

【０００４】このように、所定の集計期間（例えば１か
月）単位の課金金額をその集計期間が過ぎてから通知さ
れるシステムであるので、その集計期間の途中での状況
を利用者が知ることができない。そのため、次のような
不都合が生じる。すなわち、リクエストをする時点で利
用者は、自分がその月のその時点までの利用金額がどれ
だけになっているかが判らず、自分の感覚で利用金額が
高額となっていると考えた場合にはリクエストを控えよ
うとする。そして、後日金額が請求された時点で考えて
いたよりも少なく、それであればもっと利用していれば
よかったと後悔したりする。このような状況は、システ
ムの利用促進という点、あるいは利用者の便宜向上の点
で解決すべき課題である。

【０００５】また、これは音声と映像がセットになった
テレビジョン放送に限らずラジオ放送あるいはその他の
放送に関しても同様の課題が考えれる。本発明は、利用
者自身がリアルタイムで課金金額を知ることができるよ
うにすることによって、利用者の便宜を向上させ、放送
システムの利用促進を図ることを目的とする。

【０００６】

【課題を解決するための手段及び発明の効果】この目的
を達成するためになされた請求項１記載の発明は、視聴
者から個別になされた放送要求を受信し、要求記憶手段
にデータとして自動的に記憶させる放送要求受付手段
と、前記要求記憶手段に記憶されている放送要求に応じ
た放送用情報を、所定の順番に従って順次放送していく
放送手段とを備えたリクエスト応答機能付きの放送セン
タにおいて、前記放送要求受付手段によって要求記憶手
段に記憶させた放送要求に対応する所定の料金を課金す
るための実績情報を、放送要求をした視聴者毎に記憶し
ておく実績情報記憶手段と、通信回線を介して視聴者か
ら個別になされた課金金額の通知要求を受け付ける通知
要求受付手段と、前記課金金額の通知要求に対し、前記
実績情報記憶手段に記憶されている当該視聴者に対する
実績情報に基づいて算出した課金金額を、前記通信回線
を介して音声情報として応答する課金金額応答手段とを
備えていることを特徴とする放送センタである。

【０００７】上記構成を有する本発明の放送センタは、
放送要求受付手段が、視聴者から個別になされた放送要
求を受信し、要求記憶手段にデータとして自動的に記憶
させる。そして、放送手段が、要求記憶手段に記憶され
ている放送要求に応じた放送用情報を、所定の順番に従
って順次放送していく。

【０００８】このようにリクエスト応答機能付きであ
り、実績情報記憶手段が、放送要求受付手段によって要
求記憶手段に記憶させた放送要求に対応する所定の料金
を課金するための実績情報を、放送要求をした視聴者毎
に記憶しておく。この実績情報に基づいて別途所定の課
金や料金徴収が実行される。例えば、金融機関の自動引
き落しシステムを利用して徴収したり、管理者側の料金
回収スタッフが利用者側に直接出向いて徴収したりする
こととなる。

【０００９】この場合の料金徴収については、通常、管
理者側の主導で行われ、また現状のＣＡＴＶシステムで
も実施されているように月毎に料金を支払う契約が多い
ので、リクエストした利用者は課金結果である請求額を
後で一方的に知らされるのみである。つまり、金融機関
からの自動引き落しの場合には、引き落し予定額の記載
された請求書が送られてくる。また、管理者側の料金回
収スタッフが利用者側に直接出向く場合には、その場で
初めて請求金額を告げられることとなる。

【００１０】このように、所定の集計期間（例えば１か
月）単位の課金金額をその集計期間が過ぎてから通知さ
れるシステムであるので、その集計期間の途中での状況
を利用者が知ることができない。そのため、リクエスト
をする時点で利用者は、自分がその月のその時点までの
利用金額がどれだけになっているかが判らず、自分の感
覚で利用金額が高額となっていると考えた場合にはリク
エストを控えようとする。そして、後日金額が請求され
た時点で考えていたよりも少なく、それであればもっと
利用していればよかったと後悔したりする。このような
状況を鑑みてなされた本発明の放送センタでは、次のよ
うに動作する。

【００１１】すなわち、通知要求受付手段が、通信回線
を介して視聴者から個別になされた課金金額の通知要求
を受け付けると、課金金額応答手段が、課金金額の通知
要求に対し、実績情報記憶手段に記憶されている当該視
聴者に対する実績情報に基づいて算出した課金金額を、
通信回線を介して音声情報として応答するのである。

【００１２】このように、視聴者は、管理者側で決めた
集計期間に関係なく、自分が知りたいと思った時点で現
在までの課金金額を例えば手持ちの電話機ですぐに知る
ことができるため、自分の感覚だけで利用金額が高額と
なっていると感じてリクエストを控えようとすることも
なくなり、安心してリクエストができる。その結果、シ
ステムの利用促進が図られ、また視聴者の便宜も向上す
る。

【００１３】また、請求項２に示すように、通知要求受
付手段が、通知要求の受付に際して、複数候補の中から
選択された集計期間に対する課金金額の通知要求を受付
可能にされており、課金金額応答手段は、実績情報記憶
手段に記憶されている当該視聴者に対する実績情報の内
の、選択された集計期間内の実績情報に基づいて課金金
額を算出・応答するようにしてもよい。

【００１４】例えば、１週間・１か月間・３か月間・６
か月間等といった中から選択できるようにしておくこと
が考えられる。例えば料金徴収のための集計期間が１か
月である場合には、次に支払う金額が現在までにいくら
になっているかを知りたければ１か月間を選択すればよ
い。また、それだけでなく、過去３か月間あるいは６月
間の累計金額が判れば、それによってリクエストを控え
たり、あるいは安心してリクエストができたりする。も
ちろん、過去の料金通知書等を見て加算すれば判るので
あるが、それらを探す手間等が面倒である。したがっ
て、知りたいときにすぐに金額が判れば便利である。さ
らに、集計期間よりは短い１週間といった単位であって
も、例えば視聴者自身が１週間の上限を決めていたりす
ることもあり、このような期間の課金金額も知りたいと
いう要請はあると考えられる。

【００１５】もちろん、この期間は上述した例だけでな
く、システム構成や提供する情報の内容あるいは視聴者
の希望等によって適宜設定すればよい。なお、上述の放
送センタでは、放送センタに対して視聴者が行なう放送
要求の放送については特に限定しなかったが、例えば請
求項３に示すように、放送要求受付手段が、電話回線を
介して視聴者から個別になされた放送要求を受信するよ
うに構成することが考えられる。こうすれば、放送要求
も前記課金金額の問い合わせも視聴者は手持ちの電話機
等を用いて実行することができる。

【００１６】また、請求項４に示すように、通知要求受
付手段が、視聴者からの放送要求を受け付ける際、所定
のガイダンス用音声情報を視聴者側に送信し、視聴者識
別情報や請求項２における集計期間の選択情報をそのガ
イダンス用音声情報に対する返答として受信するように
してもよい。こうすれば、視聴者はそのガイダンス用音
声情報に従って操作するだけでよく、より視聴者の便宜
が向上する。

【００１７】例えば、視聴者からの電話を自動着信し、
電子音声による案内を行う音声応答機能と、電話による
ダイヤルトーンを使用したコードの発信を受信するコー
ド受信機能を備え、音声応答機能によって所定のガイダ
ンス音声を流し、それに従って視聴者が要求する例えば
カラオケの曲番号や視聴者識別番号、あるいは請求項２
に示す場合であれば集計期間の選択結果等をプッシュボ
タン等で入力し、それをダイヤルトーンを使用したコー
ドとして受信するようにすれば便利である。

【００１８】このような放送センタから放送する放送用
情報としては、例えばカラオケ用の情報が考えられる。
この場合、請求項５に示すように、放送手段は、音声情
報と映像情報が送信可能なテレビジョン放送手段である
と共に、放送手段が放送する放送用情報は、要求された
カラオケ曲に応じたカラオケ演奏音及び背景映像に歌詞
テロップが合成された映像とを含むようにすることが考
えられる。

【００１９】もちろん、放送用情報としてカラオケ演奏
音だけを放送してもカラオケとしては成立するが、現在
のカラオケには、もはや背景映像に歌詞テロップを合成
した映像をカラオケ演奏に併せて表示させるということ
が常識化されつつあるので、カラオケ演奏音及び背景映
像に歌詞テロップが合成された映像とを含む放送用情報
を放送することが好ましいと言える。この場合、いわゆ
るＣＡＴＶのように有線で放送センタと加入者端末を接
続してもよいし、通常の放送システムのように無線のま
までもよい。さらには、音声情報だけあるいは映像情報
だけという場合も考えられる。

【００２０】なお、上記請求項３では、放送要求受付手
段が、電話回線を介して視聴者から個別になされた放送
要求を受信するようにした例を説明したが、視聴者から
の放送要求を受信する方法は当然それ以外でも構わな
い、例えば、ＣＡＴＶの同軸ケーブルを介して双方向全
２重通信が実現されるのであれば、その同軸ケーブルを
介して行ってもよい。

【００２１】

【発明の実施の形態】以下、本発明の放送センタを具体
化した一実施例を図面を参照しながら説明する。図１
は、本実施例の放送センタ１０の概略構成を示すブロッ
ク図である。図１に示すように、放送センタ１０は、制
御手段及び「課金金額応答手段」としてのホストコンピ
ュータ１１と、「実績情報記憶手段」としての外部記憶
装置１２と、表示手段としての表示装置１３と、カラオ
ケ再生装置１４と、「放送手段」としての放送手段１６
と、「放送要求受付手段」、「通知要求受付手段」及び
「課金金額応答手段」としての音声応答装置２０とを備
えている。また、放送センタ１０は、「通信回線」とし
ての公衆電話回線４０を介して多数の加入者電話機５０
と接続されている。

【００２２】各構成装置について、放送センタ１０にお
ける役割あるいは放送システム全体との関わりも含めて
説明する。音声応答装置２０は視聴者からの放送要求を
受け付けることに加え、視聴者からの課金金額の通知要
求を受け付け、その通知要求に応じて当該視聴者に対す
る課金金額を音声情報として応答するためのものであ
る。なお、この課金金額については後述する。

【００２３】まず、放送要求の受け付けに関して詳細に
説明する。本放送センタ１０は、視聴者から個別になさ
れた放送要求を記憶しておき、その放送要求に応じた放
送用情報（本実施例の場合にはカラオケ用の情報）を順
次放送していくリクエスト応答機能を備えているのであ
るが、視聴者は自宅にあるところのケーブルテレビによ
って本放送センタ１０に接続されたテレビジョン受信機
（図示せず）を視聴しながら、手持ちの加入者電話機５
０により一般の公衆電話回線４０を通して、希望するカ
ラオケ用情報の放送を要求する。この放送要求は、予め
定められた「リクエストコード」によって行う。これ
は、カラオケ視聴の提供に限り、一般のカラオケ装置に
おける「曲番号」と同義のものである。数字コードによ
るリクエストであるため、実際には視聴者が加入者電話
機５０のダイヤルもしくはプッシュホンの押し下げによ
り上記リクエストコードをトーン発信する。このリクエ
ストコードはあらかじめ視聴者に配布物等によって通知
されているものとする。

【００２４】この視聴者からの通話は放送センタ１０に
おいて音声応答装置２０により自動的に受理される。音
声応答装置２０は内蔵された合成音声手段（図示せず）
により予め登録されたメッセージを送出し、視聴者にリ
クエストコードの入力を促すものであり、ホストコンピ
ュータ１１により制御され、上記した通話の受話、メッ
セージの送話からパルスコードの受信までを行う。

【００２５】音声応答装置２０によって受理されたリク
エストコードは、ホストコンピュータ１１により、その
コードが有効であるかどうか、外部記憶装置１２上のデ
ータベースとの照合により判断され、有効であればホス
トコンピュータ１１内のＣＰＵメモリ１１ｂ（図２参
照）に記憶される。なお、このＣＰＵメモリ１１ｂが
「要求記憶手段」に相当する。

【００２６】ホストコンピュータ１１は、リクエストを
受け付けた場合には、その旨を通知するためのメッセー
ジを音声情報をして作成する。そして、音声応答装置２
０から公衆電話回線４０を介して放送要求をしてきた視
聴者側の加入者電話機５０に応答するのである。

【００２７】また、記憶されたリクエストコードは、ホ
ストコンピュータ１１によって制御されるカラオケ再生
装置１４に渡され、音声・映像の再生がなされる。な
お、本実施例のカラオケ再生装置１４は、カラオケ演奏
音を再生すると共に、歌詞テロップの合成された背景映
像も再生できるものである。したがって、放送手段１６
は、テレビジョン放送手段である。なお、発明の主旨を
考えると映像がなくても構わないので、カラオケ再生装
置１４はカラオケ演奏音だけを再生するものとし、放送
手段１６がいわゆるラジオ放送手段であっても構わな
い。もちろん、カラオケ等のように音声情報を含むもの
以外に適用した場合には、逆に映像だけということも考
えられる。

【００２８】放送手段１６によって放送された放送内容
は、視聴者側のテレビジョン受信機などの受信設備にて
受信され、カラオケ番組として視聴可能である。なお、
放送センタ１０と視聴者側の受信設備はＣＡＴＶシステ
ムのように有線で接続されていてもよいし、通常の放送
システムのように無線でもよい。

【００２９】表示装置１３はホストコンピュータ１１に
接続されており、これらの状況を表示することができ
る。これは、放送センタ１０のオペレータが確認するた
めに利用される。以上は放送要求の受け付けに関する説
明であったが、次に課金金額の通知要求の受け付けに関
して詳細に説明する。

【００３０】本放送センタ１０は、上述した放送要求の
受付時において、ＣＰＵメモリ１１ｂに記憶させたリク
エストコードとそれをリクエストした視聴者識別番号と
に基づき、視聴者毎に所定の料金を課金するための実績
情報を外部記憶装置１２の課金実績テーブル（図８参
照）に記憶しておく。これに基づいて別途料金徴収の処
理等が行われるのであるが、本放送センタ１０は、視聴
者から個別になされた課金金額の通知要求に対して、現
時点までの課金金額をその課金実績テーブルに基づいて
算出し、応答する機能を備えている。

【００３１】視聴者は、加入者電話機５０により一般の
公衆電話回線４０を通して、課金金額の通知要求を送信
する。この場合には、視聴者の識別番号と課金金額の通
知要求であることを示す番号を加入者電話機５０のダイ
ヤルもしくはプッシュホンの押し下げによりトーン発信
する。

【００３２】詳しくは、上述した放送要求の場合と同様
に、音声応答装置２０から予め登録されたメッセージが
送出され、そのメッセージによるガイダンスに従って所
定の操作をすることで課金金額の要求ができる。ホスト
コンピュータ１１はこの通知要求があれば、視聴者識別
番号と外部記憶装置１２内の課金実績テーブルを基に、
その視聴者に対応する現時点までの課金金額を算出し、
これを通知するためのメッセージを音声情報をして作成
する。そして、音声応答装置２０から公衆電話回線４０
を介して放送要求をしてきた視聴者側の加入者電話機５
０に応答するのである。

【００３３】続いて、図２を参照して、ホストコンピュ
ータ１１を中心とした信号の流れを説明する。図２に示
すように、音声応答装置２０はホストコンピュータ１１
のＣＰＵ１１ａと制御信号によって結ばれている。ＣＰ
Ｕ１１ａは音声応答装置２０に対して公衆電話回線４０
（図１参照）の着信待ちに関する制御、着信後の同装置
２０内の音声メッセージの送話に関する制御（複数のメ
ッセージの内の選択）を行う。音声応答装置２０はホス
トコンピュータ１１に対して公衆電話回線４０を通じて
受信したダイヤルパルスを数値情報として返す。これに
より、公衆電話回線４０による視聴者からの要求の自動
受理を行うものである。音声応答装置２０より返された
数値はＣＰＵメモリ１１ｂに格納される。

【００３４】外部記憶装置１２は、リクエストコードに
関するデータベースあるいは課金実績テーブルが格納さ
れたホストコンピュータ１１の外部記憶であり、装置間
でデータの読み書きが行われる。これにより、ＣＰＵ１
１ａはリクエストコードの検索・照合と、ログ記録、あ
るいは課金実績の検索を行うものである。

【００３５】カラオケ再生装置１４はＣＰＵ１１ａと制
御信号により結ばれている、ＣＰＵ１１ａはリクエスト
コード（曲番号）を送信し、同装置１４にカラオケ楽曲
の再生を行わせ、またこの再生の開始・終了などの制御
を行うことができる。また、カラオケ再生装置１４は、
ＣＰＵ１１ａに対して再生の状況（再生中・再生終了
等）を返す。これにより、ＣＰＵ１１ａはリクエストコ
ードによるカラオケ楽曲の再生を行うことができる。

【００３６】次に、本実施例の放送センタ１０の動作に
ついて、図を参照して説明する。図９〜図１３はＣＰＵ
１１ａによって実行されるプログラムの処理手順を示す
フローチャートであり、図３〜図８はこのプログラムが
取り扱うデータ構造図である。以下、処理フローの詳細
を説明する。なお、図９〜図１２は、カラオケの放送要
求あるいは課金実績の通知要求に応答する処理のフロー
チャート、図１３は、リクエスト再生処理のフローチャ
ートであり、これらの処理はそれぞれ同時に独立して動
作するいわゆるマルチタスク処理である。

【００３７】まず、要求応答処理（図９〜図１２）につ
いて説明する。本処理は、加入者側からの公衆電話回線
４０によるカラオケ放送要求の自動受理とＣＰＵメモリ
１１ｂへの登録手順、及び課金金額の通知要求の自動受
理と課金金額の音声応答処理を示す。なお、この加入者
とは単にこの放送センタ１０からの放送を受信できると
いう意味ではなく、カラオケ放送要求をする権利を有し
ているものという意味である。例えばＣＡＴＶシステム
で、そのシステムに加入する際に自動的にカラオケ放送
を要求する権利も与えられる場合には、全てが加入者と
なる。なお、通常の無線形式で放送する場合には、例え
ばカラオケ放送要求をする代わりに所定の料金を徴収す
るような契約を別個に行なうことが考えられる。その場
合には、契約をした人だけが加入者となる。

【００３８】まず、図９の最初のステップＳ１００にお
いて、音声応答装置２０を公衆電話回線４０を介しての
着信が可能な状態に制御し、続くＳ１１０にて、加入者
電話機５０からの着信があるまで待機する。そして、着
信があれば（Ｓ１１０：ＹＥＳ）Ｓ１２０へ移行する。

【００３９】Ｓ１２０では、音声応答装置２０より音声
応答メッセージ（例えば「加入者番号を入力してくださ
い」）を送出し、最初に行ってもらう加入者番号の入力
を促す。その後、Ｓ１３０にて、加入者電話機５０より
のダイヤルパルスの発信を待つ。入力された番号は、Ｓ
１４０にて、ＣＰＵメモリ１１ｂ上のリクエスト受付バ
ッファ（図５参照）の加入者コードの領域Ｃ３に格納し
ていく。これを５桁の加入者番号が全て入力されるまで
繰り返す（Ｓ１５０）。

【００４０】５桁の加入者番号が入力されると（Ｓ１５
０：ＹＥＳ）、Ｓ１６０へ移行して、その加入者番号が
有効であるかどうかの照合を行なう。これは、外部記憶
装置１２上の加入者データベース（図７）を照会して行
なう。この照合の結果、有効な番号でないと判断されれ
ば（Ｓ１７０：ＮＯ）、入力のやり直しを求める音声メ
ッセージ（例えば「加入者番号を再入力してくださ
い」）を再生し（Ｓ１８０）、Ｓ１３０へ戻る。

【００４１】最初に入力された加入者番号が有効である
場合、あるいは再度入力された加入者番号が有効であれ
ば（Ｓ１７０：ＹＥＳ）、Ｓ１９０（図１０参照）に移
行する。Ｓ１９０では、音声応答メッセージを送出し、
モード選択コードの入力を促す。ここでモード選択コー
ドとは、「カラオケ放送要求」あるいは「課金金額通知
要求」のいずれのモードであるかを示すコードである。
例えば、カラオケ放送要求の場合には「１」、課金金額
通知要求の場合は「２」に設定しておき、「カラオケ放
送をリクエストされる場合には１を押して下さい。ま
た、課金金額の通知を要求される場合には２を押して下
さい。」といったメッセージを流す。

【００４２】続くＳ２００，２１０では、ダイヤルパル
スの発信を待ち、入力された番号が受け取ると（Ｓ２１
０：ＹＥＳ）、その番号が放送要求モードであるかどう
かを判断する。放送要求モードであれば（Ｓ２２０：Ｙ
ＥＳ）、Ｓ２３０へ移行し、放送要求モードでなければ
（Ｓ２２０：ＮＯ）、Ｓ３７０（図１２参照）へ移行す
る。

【００４３】まず、放送要求モードであった場合の処理
について説明する。Ｓ２３０では、音声応答メッセージ
を送出し、リクエストコードの入力を促す。続くＳ２４
０〜２６０では、ダイヤルパルスの発信を待ち、入力さ
れた番号をリクエスト受付バッファ（図５）のリクエス
トコードの領域Ｃ２に格納していき、これを５桁のリク
エストコードがすべて入力されるまで繰り返す。

【００４４】５桁のリクエストコードが入力されると
（Ｓ２６０：ＹＥＳ）、そのリクエストコードの照合を
行なう。これは、外部記憶装置１２上のリクエストデー
タベース（図３）を照会して実行する。そして、Ｓ１４
０で有効な番号であるかどうかを判断する。有効な番号
でないと判断されれば（Ｓ２８０：ＮＯ）、Ｓ２９０へ
移行して、入力のやり直しを求める音声メッセージ（例
えば「リクエストコードを再入力してください」）を再
生し、Ｓ２４０へ戻る。

【００４５】最初に入力されたリクエストコードが有効
である場合、あるいは再度入力されたリクエストコード
が有効であれば（Ｓ２８０：ＹＥＳ）、Ｓ３００の処理
に移行する。Ｓ３００では、リクエストの受付が完了し
た旨を視聴者側に知らせるための音声応答メッセージを
送出し、続くＳ３１０で回線を切断する。

【００４６】Ｓ３１０での回線切断処理が終了すると、
Ｓ３２０（図１１参照）に移行する。Ｓ３２０において
は、受け付けた日時をタイムスタンプとしてリクエスト
受付バッファ（図５）の受付時刻の領域Ｃ１に書き込
む。ここまでの処理が終了すれば、図５に示すリクエス
ト受付バッファ上には受付時刻Ｃ１、有効なリクエスト
コードＣ２及び有効な加入者コードＣ３の３要素が揃
い、実際のリクエストの受付が可能になるので、続くＳ
３３０では、このリクエスト受付バッファ（図５）の内
容をリクエスト実行テーブル（図４）内の受付ポインタ
Ｂ５の示しているリクエストコード領域Ｂ２に新規登録
する。

【００４７】リクエスト実行テーブルは、図４に示すよ
うに、再生フラグＢ１とリクエストコードＢ２の２つの
項目からなっている。そして新規登録をする場合には、
リクエスト受付バッファ（図５）のリクエストコードＣ
２を受付ポインタの示すリクエストコード領域Ｂ２にコ
ピーし、再生フラグＢ１を「未」とすることにより行わ
れる。なお、初期状態では再生フラグＢ１にはすべて
「無」が、リクエストコードＢ２には不定値が入ってい
るものとする。

【００４８】Ｓ３３０での新規登録が終了すると、Ｓ３
４０へ移行する。Ｓ３４０では、受付ポインタＢ５をリ
クエスト実行テーブル（図４）上の次の領域に進める。
この動作が、後述するリクエスト再生処理（図１３）の
動作に反映する。さらに、続くＳ３５０では、受け付け
たリクエストをログ記録として保持するために、外部記
憶装置１２上のリクエストログ記録（図６）の受付時刻
領域Ｄ１、リクエストコード領域Ｄ２、加入者コード領
域Ｄ３（図５のリクエスト受付バッファと同様の要素を
持つ。）にそれぞれの要素をコピーする。

【００４９】次に、Ｓ３６０で課金実績の更新処理を行
なう。これは図８に示す課金実績テーブルの該当箇所の
データを更新させることで実施する。課金実績テーブル
には加入者コードに対応して累積リクエスト数を書き込
む欄があり、このＳ３６０では、Ｓ３５０でログ記録さ
せたリクエストに対応する加入者コードの累積リクエス
ト数の値をインクリメントする。なお、累積リクエスト
数の初期値は「０」である。

【００５０】このＳ３６０の処理終了後は、再び着信待
ち状態（Ｓ１００）に戻り、以降の処理を繰り返す。以
上のＳ２３０〜Ｓ３６０が放送要求モードであった場合
（Ｓ２２０：ＹＥＳ）の処理であるが、続いてＳ２２０
で否定判断、すなわち課金金額通知要求モードである場
合の処理について、図１２のＳ３７０〜Ｓ４００にて説
明する。

【００５１】Ｓ３７０では、課金実績テーブル（図８）
より該当加入者コードに対応する累積リクエスト数を読
み出す。そして、Ｓ３８０では、この読み出した累積リ
クエスト数にカラオケ放送１曲についての単価を乗算し
て課金金額を算出する。そして、続くＳ３９０では、そ
の課金金額を視聴者側に知らせるための音声応答メッセ
ージを送出する。これによって、視聴者は、現在までの
課金金額をリアルタイムで知ることができるのである。

【００５２】続くＳ４００で回線を切断する。なお、こ
のＳ４００の処理終了後は、再び着信待ち状態（Ｓ１０
０）に戻り、以降の処理を繰り返す。次に、リクエスト
再生処理（図１３）について説明する。本処理は、ＣＰ
Ｕメモリ１１ｂ上のリクエスト実行テーブル（図４）に
登録されたリクエストコードの再生の手順を示す。

【００５３】まず、最初のステップＳ４１０において、
リクエスト実行テーブル（図４）内の再生ポインタＢ４
が示す領域より、再生フラグＢ１を取り出す。再生フラ
グＢ１が「未」でなければ（Ｓ４２０：ＮＯ）、リクエ
スト実行テーブル（図４）の登録内容の再生がすべて済
んでいる、若しくは登録内容が空であるため、そのまま
要求応答処理（図９〜図１２）によるリクエストの追加
登録待ちに入る（Ｓ４３０）。

【００５４】一方、再生フラグＢ１が「未」であれば、
Ｓ４４０へ移行し、リクエストコードＢ２を取り出す。
そして、Ｓ４５０にて、同リクエストコードＢ２をカラ
オケ再生装置１４に渡し、再生の指示を出す。さらに、
Ｓ４６０にて、再生フラグＢ１を「中」に変え、続くＳ
４７０にて、カラオケ再生装置１４の再生状態のチェッ
クを行う。

【００５５】再生の終了がカラオケ再生装置１４より指
示されるまでこれを繰り返す（Ｓ４８０：ＮＯ）。そし
て、再生が終了すると（Ｓ４８０：ＹＥＳ）、Ｓ４９０
へ移行して再生フラグＢ１を「済」に変え、Ｓ５００に
て、再生ポインタＢ４を次のテーブルに移動する。な
お、この後は、再びＳ４１０に戻り、次のリクエストの
再生を繰り返す。

【００５６】以上説明したように、本実施例の放送セン
タ１０は、視聴者から個別になされたカラオケ放送のリ
クエストを受け付けて順次放送していく。そして、リク
エストを受け付ける毎に、課金実績テーブル（図８）に
課金金額を算出するために必要な累積リクエスト数をイ
ンクリメントしていく。この累積リクエスト数に基づい
て別途所定の課金や料金徴収が実行される。例えば、所
定の集計期間、例えば所定の１か月間が経過すると、そ
の１か月間の累積リクエスト数に単価を乗算して課金金
額を算出する。そして、この課金金額情報が例えば金融
機関に送られて自動引き落しで徴収されたり、あるいは
請求書として印刷され、管理者側の料金回収スタッフが
利用者側に直接出向いて徴収したりすることとなる。

【００５７】この場合の料金徴収については、通常、管
理者側の主導で行われ、また現状のＣＡＴＶシステムで
も実施されているように月毎に料金を支払う契約が多い
ので、リクエストした利用者は課金結果である請求額を
後で一方的に知らされるのみである。つまり、金融機関
からの自動引き落しの場合には、引き落し予定額の記載
された請求書が送られてくる。また、管理者側の料金回
収スタッフが利用者側に直接出向く場合には、その場で
初めて請求金額を告げられることとなる。

【００５８】このように、所定の集計期間（例えば１か
月）単位の課金金額をその集計期間が過ぎてから通知さ
れるシステムであるので、その集計期間の途中での状況
を利用者が知ることができない。そのため、リクエスト
をする時点で利用者は、自分がその月のその時点までの
利用金額がどれだけになっているかが判らず、自分の感
覚で利用金額が高額となっていると考えた場合にはリク
エストを控えようとする。そして、後日金額が請求され
た時点で考えていたよりも少なく、それであればもっと
利用していればよかったと後悔したりする。このような
問題に対して本実施例の放送センタ１０では、次のよう
にして解決する。

【００５９】すなわち、公衆電話回線４０を介して視聴
者から個別になされた課金金額の通知要求を受け付ける
と、課金実績テーブル（図８）より該当加入者コードに
対応する累積リクエスト数を読み出し、それに単価を乗
算して算出した課金金額を視聴者側に知らせるための音
声応答メッセージを送出するのである。これによって、
視聴者は、現在までの課金金額をリアルタイムで知るこ
とができる。

【００６０】このように、視聴者は、管理者側で決めた
集計期間に関係なく、自分が知りたいと思った時点で現
在までの課金金額を知ることができるため、自分の感覚
だけで利用金額が高額となっていると感じてリクエスト
を控えようとすることもなくなり、安心してリクエスト
ができる。その結果、システムの利用促進が図られ、ま
た視聴者の便宜も向上する。

【００６１】以上、具体例に従って、本発明の実施の形
態について説明したが、本発明はこのような具体例に限
定されるものではなく、発明の要旨を逸脱しない範囲で
様々な実施ができることは言うまでもない。例えば、上
記実施例では、図１２のフローチャートに示すように、
課金通知要求があった時点で、累積リクエスト数を読み
出し、この読み出した累積リクエスト数にカラオケ放送
１曲についての単価を乗算して課金金額を算出してい
た。しかし、リクエストがあった時点で課金金額まで計
算して記憶させておき、課金通知要求があった場合に
は、その時点での課金金額を読み出して通知するように
してもよい。その場合には、図８に点線で示すように、
課金金額を書き込む欄を設定しておき、図１１のＳ３６
０の処理において、累積リクエスト数をインクリメント
すると共に、課金金額欄に単価を加算していけばよい。
例えば新曲は高く、古い曲は安く設定している場合に
は、各カラオケ曲に対応して料金を記憶しておく料金テ
ーブルを準備しておき、リクエストがある毎にその料金
テーブルから読み出した料金を課金金額として加算して
いくようにすることが考えられる。

【００６２】なお、実際の徴収金額はリクエストにかか
る料金（上記実施例での課金金額）だけでなく、例えば
システムの基本使用料等を加算するようなシステムを構
築した場合には、実際の徴収金額を通知するようにして
もよい。また、基本使用料等は固定金額であるので、や
はりリクエストにかかる料金だけを通知するようにして
もよい。

【００６３】また、上記実施例では、所定の集計期間内
の現時点までの課金金額を通知するものであった。した
がって、例えばその集計期間が経過した時点で料金徴収
システム側へデータを送信し、累積リクエスト数をリセ
ットすることが考えられる。このようにすれば、例えば
１か月間単位で集計している場合には、今月分の課金金
額が期間の途中であっても判ることとなる。

【００６４】ここで、さらに課金金額の通知要求を、複
数の集計期間候補の中から選択して要求できるようにし
ておくことが考えられる。例えば、１週間・１か月間・
３か月間・６か月間等といった中から選択できるように
しておくのである。例えば料金徴収のための集計期間が
１か月である場合には、次に支払う金額が現在までにい
くらになっているかを知りたければ１か月間を選択すれ
ばよい。また、それだけでなく、過去３か月間あるいは
６月間の累計が判れば、それによってリクエストを控え
たり、あるいは安心してリクエストができたりする。も
ちろん、過去の料金通知書等を見て加算すれば判るので
あるが、それらを探す手間等が面倒である。したがっ
て、知りたいときにすぐに金額が判れば便利である。さ
らに、集計期間よりは短い１週間といった単位であって
も、例えば視聴者自身が１週間の上限を決めていたりす
ることもあり、このような期間の課金金額も知りたいと
いう要請はあると考えられる。

【００６５】そのためには、図８の課金実績テーブルの
累積リクエスト数あるいはそれに課金金額を加えた記憶
欄を、上述した１週間・１か月間・３か月間・６か月間
等といった各集計期間毎に設定しておく。そして、リク
エストがある毎に各欄について更新させていくと共に、
各集計期間に応じてリセットしていけばよい。もちろ
ん、この集計期間は上述した例だけでなく、システム構
成や提供する情報の内容あるいは視聴者の希望等によっ
て適宜設定すればよい。

【００６６】また、上記実施例では、カラオケ番組の放
送に使用する例を説明したが、本発明は放送用情報を供
給するサーバ側が少数であり、放送用情報を要求するク
ライアント側が多数であり、両者が遠隔である等の理由
で、放送という情報供給形態を採用する状況であること
が応用の主旨である。したがって、放送用情報として音
声情報だけあるいは映像情報だけという場合も考えられ
る。

【００６７】さらに、上記実施例では、公衆電話回線４
０を介して視聴者から個別になされた放送要求を受信す
るようにした例を説明したが、視聴者からの放送要求を
受信する方法は当然それ以外でも構わない、例えば、Ｃ
ＡＴＶの同軸ケーブルを介して双方向全２重通信が実現
されるのであれば、その同軸ケーブルを介して行っても
よい。

【図面の簡単な説明】

【図１】 実施例の放送センタの概略構成を示すブロッ
ク図である。

【図２】 ホストコンピュータを中心した信号の流れを
示す説明図である。

【図３】 ホストコンピュータが取り扱うリクエストデ
ータベースのデータ構造図である。

【図４】 ホストコンピュータが取り扱うリクエスト実
行テーブルのデータ構造図である。

【図５】 ホストコンピュータが取り扱うリクエスト受
付バッファのデータ構造図である。

【図６】 ホストコンピュータが取り扱うリクエストロ
グ記録のデータ構造図である。

【図７】 ホストコンピュータが取り扱う加入者データ
ベースのデータ構造図である。

【図８】 ホストコンピュータが取り扱う課金実績テー
ブルのデータ構造図である。

【図９】 ホストコンピュータが実行する要求応答処理
の一部を示すフローチャートである。

【図１０】 ホストコンピュータが実行する要求応答処
理の一部を示すフローチャートである。

【図１１】 ホストコンピュータが実行する要求応答処
理の一部を示すフローチャートである。

【図１２】 ホストコンピュータが実行する要求応答処
理の一部であり、特に課金実績の通知要求に応答する処
理を示すフローチャートである。

【図１３】 ホストコンピュータが実行するリクエスト
再生処理を示すフローチャートである。

【符号の説明】

１０…放送センタ １１…ホストコン
ピュータ １１ａ…ＣＰＵ １１ｂ…ＣＰＵメ
モリ １２…外部記憶装置 １３…表示装置 １４…カラオケ再生装置 １６…放送手段 ２０…音声応答装置 ４０…公衆電話回
線 ５０…加入者電話機

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 庁内整理番号 ＦＩ 技術表示箇所 Ｇ０７Ｆ 17/30 Ｇ０７Ｆ 17/30 Ｇ１０Ｋ 15/04 ３０２ Ｇ１０Ｋ 15/04 ３０２Ｄ Ｈ０４Ｈ 1/02 Ｈ０４Ｈ 1/02 Ｆ 1/08 1/08 Ｈ０４Ｍ 11/08 Ｈ０４Ｍ 11/08 Ｈ０４Ｎ 7/16 Ｈ０４Ｎ 7/16 Ｃ

Claims (5)

【特許請求の範囲】
1. 【請求項１】 視聴者から個別になされた放送要求を受
   信し、要求記憶手段にデータとして自動的に記憶させる
   放送要求受付手段と、 前記要求記憶手段に記憶されている放送要求に応じた放
   送用情報を、所定の順番に従って順次放送していく放送
   手段とを備えたリクエスト応答機能付きの放送センタに
   おいて、 前記放送要求受付手段によって要求記憶手段に記憶させ
   た放送要求に対応する所定の料金を課金するための実績
   情報を、放送要求をした視聴者毎に記憶しておく実績情
   報記憶手段と、 通信回線を介して視聴者から個別になされた課金金額の
   通知要求を受け付ける通知要求受付手段と、 前記課金金額の通知要求に対し、前記実績情報記憶手段
   に記憶されている当該視聴者に対する実績情報に基づい
   て算出した課金金額を、前記通信回線を介して音声情報
   として応答する課金金額応答手段とを備えていることを
   特徴とする放送センタ。
2. 【請求項２】 請求項１に記載の放送センタにおいて、 前記通知要求受付手段は、前記通知要求の受付に際し
   て、複数候補の中から選択された集計期間に対する課金
   金額の通知要求を受付可能にされており、 前記課金金額応答手段は、前記実績情報記憶手段に記憶
   されている当該視聴者に対する実績情報の内の、前記選
   択された集計期間内の実績情報に基づいて課金金額を算
   出・応答することを特徴とする放送センタ。
3. 【請求項３】 請求項１又は２に記載の放送センタにお
   いて、 前記放送要求受付手段は、電話回線を介して視聴者から
   個別になされた放送要求を受信するように構成されてい
   ることを特徴とする放送センタ。
4. 【請求項４】 請求項１〜３のいずれかに記載の放送セ
   ンタにおいて、 前記通知要求受付手段は、視聴者からの放送要求を受け
   付ける際、所定のガイダンス用音声情報を視聴者側に送
   信し、視聴者識別情報や請求項２における集計期間の選
   択情報をそのガイダンス用音声情報に対する返答として
   受信するように構成されていることをことを特徴とする
   放送センタ。
5. 【請求項５】 請求項１〜４のいずれかに記載の放送セ
   ンタにおいて、 前記視聴者からの放送要求は、カラオケ曲を指定した要
   求であり、 前記放送手段は、音声情報と映像情報が送信可能なテレ
   ビジョン放送手段であると共に、当該放送手段が放送す
   る放送用情報は、要求されたカラオケ曲に応じたカラオ
   ケ演奏音及び背景映像に歌詞テロップが合成された映像
   とを含むものであることを特徴とする放送センタ。