JP3610135B2

JP3610135B2 - Broadcast center

Info

Publication number: JP3610135B2
Application number: JP30181395A
Authority: JP
Inventors: 尚美滝藤
Original assignee: Brother Industries Ltd; Xing Inc
Current assignee: Brother Industries Ltd; Xing Inc
Priority date: 1995-11-20
Filing date: 1995-11-20
Publication date: 2005-01-12
Anticipated expiration: 2015-11-20
Also published as: JPH09146571A

Description

【０００１】
【発明の属する技術分野】
本発明は、視聴者から個別になされた放送要求に応じた放送用情報を、所定の順番に従って順次放送していくリクエスト応答機能付きの放送センタに係り、特に、そのリクエスト応答に対して所定の料金を課すようなシステムに用いて有効な放送センタに関する。
【０００２】
【従来の技術および発明が解決しようとする課題】
現在、ＣＡＴＶシステム等のローカルなテレビジョン放送センタと加入者端末との間において、双方向テレビジョンと呼ばれるＴＶ放送の新しい形態が普及しつつある。そして、このようなシステムの放送センタは、決められた時刻に決められた情報を流すだけでなく、視聴者から個別になされた放送要求に応じた放送用情報を、所定の順番に従って順次放送していくリクエスト応答機能も備えるようになってきている。例えば、カラオケリクエスト番組と呼ばれるカラオケの放送のみを取り扱う番組時間枠（もしくは設けられた専用のチャンネル）等が採用されており、この番組においては視聴者からのリクエストを電話等を介して受け付け、そのリクエストに応じたカラオケを放送するといったことである。
【０００３】
このようにリクエストに応じたカラオケを放送する場合には、例えば、所定曲数までリクエストを受け付けて予約しておき、その予約リクエストに応じたカラオケを順次放送していくことが考えられる。この場合、リクエスト自体は既に予約されているがそれに応じたカラオケ曲の放送はまだ開始されていないというリクエストが存在する可能性がある。そのような状態で新規にしたリクエストが既に予約されているが放送はまだであるものと同じであった場合に、それもリクエストとして予約してしまうと、同じカラオケ曲が何度も放送されることとなり、放送内容のマンネリ化につながってしまう。
【０００４】
また、リクエストをした利用者としては、自分のリクエストしたものであろうが他人がリクエストしたものであろうが、希望したカラオケ曲が放送されればよいので、他人がリクエストしたカラオケ曲の放送によって既に自分の要求は満たされていることとなる。そのため、その後さらに今度は自分がリクエストしたものに対応するカラオケ曲が放送されても、すでに同じカラオケ曲の放送がされた後なので、リクエストした利用者にとっての必要性は非常に薄くなる。
【０００５】
したがって、リクエスト自体は既に予約されているがそれに応じたカラオケ曲の放送はまだ開始されていないものと同じリクエストがされた場合には、それに対応するカラオケ曲を放送するための予約データとしては登録しないようにすることが、放送内容の充実等から好ましい。
【０００６】
一方、このようにリクエストに応じた情報を放送する場合にそのリクエスト応答に対して所定の料金を課そうとする場合には、いわゆる定量制の料金制度ではなく、従量制の料金制度を導入する必要性が出て来る。つまり、リクエストした利用者が、その料金を負担する（支払う）のである。
【０００７】
しかしながら、この場合の料金徴収については、単純にリクエストをした回数だけに基づいて料金を計算すると不都合が生じる場合がある。上述したように、放送内容のマンネリ化防止の点等から、リクエストしたものが放送するカラオケ曲の予約データとして登録しないこともあるからである。そして、このような場合も含む状態で、単純にリクエストをした回数だけに基づいて料金を計算してしまうと、放送曲数と料金徴収対象となったリクエスト数とが異なってしまい、放送システム側が一部タダ取りしてしまうような状況となる。
【０００８】
なお、テレビジョン放送に限らずラジオ放送あるいはその他の放送に関しても同様の課題が考えられる。
本発明は、基本的には視聴者からのリクエストに応じた放送用情報を放送し、リクエストに対応する所定の料金を課金するための実績情報をリクエストした視聴者毎に記憶しておく機能を備えながら、さらに重複したリクエストがあった場合には、放送内容の充実や利用者の便宜の向上を図る上で適切な対応が可能な放送センタを提供することを目的とする。
【０００９】
【課題を解決するための手段及び発明の効果】
この目的を達成するためになされた請求項１記載の発明は、通信回線を使用して視聴者から個別になされた放送要求を受信し、要求蓄積手段にデータとして自動的に蓄積させる要求受付手段と、前記要求蓄積手段に記憶されている放送要求に応じた放送用情報を、所定の順番に従って順次放送していく放送手段と、前記放送要求受付手段によって要求蓄積手段に蓄積させた放送要求に対応する所定の料金を課金するための実績情報を、放送要求をした視聴者毎に記憶しておく課金実績情報記憶手段とを備えたリクエスト応答機能付きの放送センタにおいて、前記要求受付手段によって受信した放送要求が、既に要求蓄積手段に蓄積されているが、その放送要求に応じた放送用情報の前記放送手段による放送は未だ開始されていない放送要求と同じである重複放送要求である場合には、放送要求が重複している旨を、当該放送要求を送信してきた視聴者側に対し、前記通信回線を介して音声情報として応答する応答手段を備えると共に、前記応答手段は、前記放送要求が重複している旨に加えて、前記既蓄積・放送未開始の放送要求の内の最も早く放送開始がなされるものに応じた放送用情報の放送開始予定に関する情報も応答するように構成されており、前記要求受付手段は、前記受信した放送要求が前記重複放送要求である場合には、前記重複した放送要求の前記要求蓄積手段への蓄積を実行しないように構成されていることを特徴とする放送センタである。
【００１０】
上記構成を有する本発明の放送センタは、要求受付手段が、通信回線を使用して視聴者から個別になされた放送要求を受信し、要求蓄積手段にデータとして自動的に蓄積させる。そして、放送手段が、要求蓄積手段に記憶されている放送要求に応じた放送用情報を、所定の順番に従って順次放送していくというリクエスト応答機能を備えている。
【００１１】
また、課金実績情報記憶手段には、放送要求受付手段によって要求蓄積手段に蓄積させた放送要求に対応する所定の料金を課金するための実績情報を、放送要求をした視聴者毎に記憶しておくことができる。この実績情報に基づいて別途所定の課金や料金徴収が実行される。例えば、金融機関からの自動引き落しや管理者側の料金回収スタッフが利用者側に直接出向いて徴収したりすることとなる。
【００１２】
このように、リクエスト応答と課金のための実績情報の記憶という基本的な機能を備えていると共に、さらに次のような機能を発揮する。すなわち、要求受付手段によって受信した放送要求が、既に要求蓄積手段に蓄積されているが、その放送要求に応じた放送用情報の前記放送手段による放送は未だ開始されていない放送要求と同じである重複放送要求である場合には、放送要求が重複している旨を、当該放送要求を送信してきた視聴者側に対し、通信回線を介して音声情報として応答する。そして、さらに、要求受付手段は、受信した放送要求が重複放送要求である場合には、その重複した放送要求の要求蓄積手段への蓄積を実行しないのである。
【００１３】
このように、受信した放送要求が重複放送要求である場合にその重複した放送要求の要求蓄積手段への蓄積を実行しないことによって、必要性の薄い放送用情報が放送されることが防止され、放送内容の充実につながる。つまり、重複放送要求の場合には、既に蓄積されているが放送はまだ開始されていない放送要求に応じた放送用情報がこれから放送されるので、重複した放送要求を行った視聴者にとっては、その放送用情報によって要求が満たされることとなる。そのため、仮に重複した放送要求もそのまま蓄積させてしまうと、自分のした放送要求に応じた放送用情報が放送された後でさらに同じ放送用情報が放送されることとなり、放送要求をした視聴者にとっての必要性は非常に薄くなる。
【００１４】
したがって、このような重複放送要求に応じた放送用情報は放送しないように制御することで、視聴者の要求を満足させながら、必要性の薄い放送用情報の放送を防止する等、放送内容の充実を図ることができる。特に、放送要求を受け付ける期間が限られている場合に、必要性の薄い放送要求のために真に放送要求をしたかった人が要求できなかったり、あるいは放送時刻が遅くなったりすることは放送内容の充実や利用者の便宜の向上を阻害するものである。したがって、そのような必要性の薄い放送用情報を放送しないようにすることが、放送内容の充実や利用者の便宜の向上につながるのである。
【００１５】
また、受信した放送要求が重複放送要求である場合に、その重複した放送要求の要求蓄積手段への蓄積を実行しないことによって、課金実績情報記憶手段には、課金するための実績情報が記憶されない。つまり、自分のした放送要求そのものに対応した放送用情報の放送はなされていないので、それについては課金実績情報として記憶しないのである。
【００１６】
これによって、料金徴収についても適切な対処が可能となる。例えば単純に放送要求の実績（例えば回数）だけに基づいて料金を計算してしまうと、実際に放送した放送用情報数と料金徴収対象となった放送要求数とが異なってしまい、放送システム事業者側が一部タダ取りしてしまうような状況となる。そこで本発明のようにすれば、実際に放送した放送用情報数と料金徴収対象となった放送要求数とが一致し、公正・健全なシステム運営の点で好ましい。
【００１７】
なお、重複放送要求をした視聴者には、放送要求が重複している旨が通信回線を介して音声情報として応答される。そのため、視聴者にとっては重複した放送要求であることが認識できる。そして、重複放送要求の場合には通常の放送要求をした場合の料金とは異なる（例えば無料になる）ことが予め通知されているのであれば、この放送要求が重複している旨の音声応答により、そのことも認識できる。そして、放送要求が重複している旨を視聴者に応答する応答手段は、さらに、放送要求が重複している旨に加えて、既蓄積・放送未開始の放送要求の内の最も早く放送開始がなされるものに応じた放送用情報の放送開始予定に関する情報も応答する。
【００１８】
また、請求項２に記載の発明は、請求項１に記載の放送センタにおいて、前記要求受付手段によって受信した放送要求を、前記要求蓄積手段へ蓄積させたものと、前記重複放送要求であるため前記要求蓄積手段への蓄積を実行しなかったものとが区別可能な状態で、要求受信実績として記憶しておく要求受信実績記憶手段を備えており、前記課金実績情報記憶手段には、前記要求受信実績記憶手段に記憶されている要求受信実績の内の、前記要求蓄積手段へ放送要求を蓄積させた要求受信実績に対応する課金実績情報を記憶するように構成されていることを特徴とする。
【００１９】
上述したように、一定の条件で放送要求が重複した場合には、その放送要求は要求蓄積手段への蓄積が実行されない。しかし、放送センタとしては、放送要求の数に基づいて例えばリクエストランキングを作成する等、種々の理由によって放送要求自体がされたことの実績は残しておくことが好ましい。したがって、この請求項２に示すようにすれば、受信した放送要求を、要求蓄積手段へ蓄積させたものと、重複放送要求であるため要求蓄積手段への蓄積を実行しなかったものとが区別可能な状態で要求受信実績として記憶しておくことができる。そして、この場合、課金実績情報記憶手段には、記憶されている要求受信実績の内の、要求蓄積手段へ放送要求を蓄積させた要求受信実績に対応する課金実績情報を記憶するので、請求項１と同様の効果を発揮する。
【００２０】
上述のように、本発明の放送センタの応答手段は、放送要求が重複している旨に加えて、既蓄積・放送未開始の放送要求の内の最も早く放送開始がなされるものに応じた放送用情報の放送開始予定に関する情報も応答する。
【００２１】
この場合、請求項３に示すように、放送用情報毎の放送所要時間を記憶する所要時間記憶手段を備え、応答手段は、要求蓄積手段に蓄積されている放送要求に対応した放送用情報の各放送所要時間情報に基づき、要求受付手段によって要求蓄積手段に蓄積させた放送要求に応じた放送用情報の放送開始までの予定所要時間あるいは放送開始予定時刻を算出し、その予定所要時間あるいは開始予定時刻を音声情報として応答することが考えられる。
【００２２】
このようにすれば、視聴者は自分の要求した放送用情報の放送開始までにかかる時間あるいは演奏開始時刻など、放送開始予定に関する情報をほぼリアルタイムで知ることができる。そのため、自分の要求した放送用情報の放送開始までに例えば別の用事を済ませるといったこともでき、いつ始まるか判らないので単に待っているだけという無駄な時間をなくすことができるというように、視聴者の利用の便宜を向上させることができる。
【００２３】
また、このような放送センタから放送する放送用情報としては、例えばカラオケ用の情報が考えられる。この場合、請求項４に示すように、放送手段は、音声情報と映像情報が送信可能なテレビジョン放送手段であると共に、放送手段が放送する放送用情報は、要求されたカラオケ曲に応じたカラオケ演奏音及び背景映像に歌詞テロップが合成された映像とを含むようにすることが考えられる。
【００２４】
もちろん、放送用情報としてカラオケ演奏音だけを放送してもカラオケとしては成立するが、現在のカラオケには、もはや背景映像に歌詞テロップを合成した映像をカラオケ演奏に併せて表示させるということが常識化されつつあるので、カラオケ演奏音及び背景映像に歌詞テロップが合成された映像とを含む放送用情報を放送することが好ましいと言える。この場合、いわゆるＣＡＴＶのように有線で放送センタと加入者端末を接続してもよいし、通常の放送システムのように無線のままでもよい。さらには、音声情報だけあるいは映像情報だけという場合も考えられる。
【００２５】
なお、要求受付手段は、視聴者からの放送要求を受け付ける際、所定のガイダンス用音声情報を視聴者側に送信し、そのガイダンス用音声情報に対する返答として放送要求を受信するようにしてもよい。こうすれば、視聴者はそのガイダンス用音声情報に従って操作するだけでよく、より視聴者の便宜が向上する。例えば、実際には視聴者の識別情報等も送信する必要があるので、ガイダンスがあると便利である。
【００２６】
また、要求受付手段が放送要求を受信するために使用する通信回線としては、電話回線でもよいし、ＣＡＴＶの同軸ケーブルを介して双方向全２重通信が実現されるのであれば、その同軸ケーブルでもよい。電話回線の場合には、例えば電話機のプッシュボタン等でリクエスト番号等を入力し、それをダイヤルトーンを使用したコードとして送信するようにし、要求受付手段がそれを受信するようにすればよい。
【００２７】
【発明の実施の形態】
以下、本発明の放送センタを具体化した一実施例を図面を参照しながら説明する。
図１は、本実施例の放送センタ１０の概略構成を示すブロック図である。図１に示すように、放送センタ１０は、制御手段及び「応答手段」としてのホストコンピュータ１１と、「課金実績情報記憶手段」及び「要求受信実績記憶手段」としての外部記憶装置１２と、表示手段としての表示装置１３と、カラオケ再生装置１４と、「放送手段」としての放送手段１６と、「要求受付手段」としての音声応答装置２０とを備えている。また、放送センタ１０は、公衆電話回線４０を介して多数の加入者電話機５０と接続されている。
【００２８】
各構成装置について、放送センタ１０における役割あるいは放送システム全体との関わりも含めて説明する。
音声応答装置２０は視聴者からの放送要求を受け付け、その放送が所定の「重複放送要求」である場合にはその旨、そして放送要求に応じた放送用情報の放送開始予定に関する情報を音声情報として応答するためのものである。なお、重複放送要求については後述する。
【００２９】
まず、放送要求の受け付けに関して詳細に説明する。
本放送センタ１０は、視聴者から個別になされた放送要求を蓄積しておき、その放送要求に応じた放送用情報（本実施例の場合にはカラオケ用の情報）を順次放送していくリクエスト応答機能を備えているのであるが、視聴者は自宅にあるところのケーブルテレビによって本放送センタ１０に接続されたテレビジョン受信機（図示せず）を視聴しながら、手持ちの加入者電話機５０により一般の公衆電話回線４０を通して、希望するカラオケ用情報の放送を要求する。この放送要求は、予め定められた「リクエストコード」によって行う。これは、カラオケ視聴の提供に限り、一般のカラオケ装置における「曲番号」と同義のものである。数字コードによるリクエストであるため、実際には視聴者が加入者電話機５０のダイヤルもしくはプッシュホンの押し下げにより上記リクエストコードをトーン発信する。このリクエストコードはあらかじめ視聴者に配布物等によって通知されているものとする。
【００３０】
この視聴者からの通話は放送センタ１０において音声応答装置２０により自動的に受理される。音声応答装置２０は内蔵された合成音声手段（図示せず）により予め登録されたメッセージを送出し、視聴者にリクエストコードの入力と、そのガイダンスを促すものであり、ホストコンピュータ１１により制御され、上記した通話の受話、メッセージの送話からパルスコードの受信までを行う。
【００３１】
音声応答装置２０によって受理されたリクエストコードは、ホストコンピュータ１１により、そのコードが有効であるかどうか、外部記憶装置１２上のデータベースとの照合により判断され、有効であればホストコンピュータ１１内のＣＰＵメモリ１１ｂ（図２参照）に蓄積される。なお、このＣＰＵメモリ１１ｂが「要求蓄積手段」及び「所要時間記憶手段」に相当する。
【００３２】
ホストコンピュータ１１は、リクエストを受け付けた場合には、その旨を通知するためのメッセージを音声情報として作成する。そして、音声応答装置２０から公衆電話回線４０を介して放送要求をしてきた視聴者側の加入者電話機５０に応答するのである。
【００３３】
また、蓄積されたリクエストコードは、ホストコンピュータ１１によって制御されるカラオケ再生装置１４に渡され、映像の再生がなされる。
なお、本実施例のカラオケ再生装置１４は、カラオケ演奏音を再生すると共に、歌詞テロップの合成された背景映像も再生できるものである。したがって、放送手段１６は、テレビジョン放送手段である。なお、発明の主旨を考えると映像がなくても構わないので、カラオケ再生装置１４はカラオケ演奏音だけを再生するものとし、放送手段１６がいわゆるラジオ放送手段であっても構わない。もちろん、カラオケ以外に適用した場合には、逆に映像だけということも考えられる。
【００３４】
放送手段１６によって放送された放送内容は、視聴者側のテレビジョン受信機などの受信設備にて受信され、カラオケ番組として視聴可能である。なお、放送センタ１０と視聴者側の受信設備はＣＡＴＶシステムのように有線で接続されていてもよいし、通常の放送システムのように無線でもよい。
【００３５】
表示装置１３はホストコンピュータ１１に接続されており、これらの状況を表示することができる。これは、放送センタ１０のオペレータが確認するために利用される。
続いて、図２を参照して、ホストコンピュータ１１を中心とした信号の流れを説明する。
【００３６】
図２に示すように、音声応答装置２０はホストコンピュータ１１のＣＰＵ１１ａと制御信号によって結ばれている。ＣＰＵ１１ａは音声応答装置２０に対して公衆電話回線４０（図１参照）の着信待ちに関する制御、着信後の同装置２０内の音声メッセージの送話に関する制御（複数のメッセージの内の選択）を行う。音声応答装置２０はホストコンピュータ１１に対して公衆電話回線４０を通じて受信したダイヤルパルスを数値情報として返す。これにより、公衆電話回線４０による視聴者からの要求の自動受理を行うものである。音声応答装置２０より返された数値はＣＰＵメモリ１１ｂに格納される。
【００３７】
外部記憶装置１２は、リクエストコードに関するデータベースあるいは課金実績テーブルが格納されたホストコンピュータ１１の外部記憶であり、装置間でデータの読み書きが行われる。これにより、ＣＰＵ１１ａはリクエストコードの検索・照合と、ログ記録を行うものである。
【００３８】
カラオケ再生装置１４はＣＰＵ１１ａと制御信号により結ばれている。ＣＰＵ１１ａはリクエストコード（曲番号）を送信し、同装置１４にカラオケ楽曲の再生を行わせ、またこの再生の開始・終了などの制御を行うことができる。また、カラオケ再生装置１４は、ＣＰＵ１１ａに対して再生の状況（再生中・再生終了等）を返す。これにより、ＣＰＵ１１ａはリクエストコードによるカラオケ楽曲の再生を行うことができる。
【００３９】
次に、本実施例の放送センタ１０の動作について、図を参照して説明する。
図９〜図１３はＣＰＵ１１ａによって実行されるプログラムの処理手順を示すフローチャートであり、図３〜図８はこのプログラムが取り扱うデータ構造図である。以下、処理フローの詳細を説明する。なお、図９〜図１１は、リクエスト自動受理・登録処理のフローチャート、図１２は、リクエスト再生処理のフローチャートであり、これらの処理はそれぞれ同時に独立して動作するいわゆるマルチタスク処理である。また、図１３は、所定のタイミング、例えば１か月毎に実行される課金集計処理のフローチャートである。
【００４０】
まず、リクエスト自動受理・登録処理（図９〜図１１）について説明する。
本処理は、加入者側からの公衆電話回線４０によるリクエストの自動受理と、そのリクエストのＣＰＵメモリ１１ｂへの登録手順を示す。なお、この加入者とは単にこの放送センタ１０からの放送を受信できるという意味ではなく、リクエストする権利を有しているものという意味である。例えばＣＡＴＶシステムで、そのシステムに加入する際に自動的にリクエストの権利も与えられる場合には、全てが加入者となる。なお、通常の無線形式で放送する場合には、例えばリクエストをする代わりに所定の料金を徴収するような契約を別個に行なうことが考えられる。その場合には、契約をした人だけが加入者となる。
【００４１】
まず、図９の最初のステップＳ１００において、音声応答装置２０を公衆電話回線４０を介しての着信が可能な状態に制御し、続くＳ１１０にて、加入者電話機５０からの着信があるまで待機する。そして、着信があれば（Ｓ１１０：ＹＥＳ）、Ｓ１２０へ移行する。
【００４２】
Ｓ１２０では、音声応答装置２０より音声応答メッセージ（例えば「加入者番号を入力してください」）を送出し、最初に行ってもらう加入者番号の入力を促す。その後、Ｓ１３０にて、加入者電話機５０よりのダイヤルパルスの発信を待つ。入力された番号は、Ｓ１４０にて、ＣＰＵメモリ１１ｂ上のリクエスト受付バッファ（図５参照）の加入者コードの領域Ｃ３に格納していく。これを５桁の加入者番号が全て入力されるまで繰り返す（Ｓ１５０）。
【００４３】
５桁の加入者番号が入力されると（Ｓ１５０：ＹＥＳ）、Ｓ１６０へ移行して、その加入者番号が有効であるかどうかの照合を行なう。これは、外部記憶装置１２上の加入者データベース（図７）を照会して行なう。
この照合の結果、有効な番号でないと判断されれば（Ｓ１７０：ＮＯ）、入力のやり直しを求める音声メッセージ（例えば「加入者番号を再入力してください」）を再生し（Ｓ１８０）、Ｓ１３０へ戻る。
【００４４】
最初に入力された加入者番号が有効である場合、あるいは再度入力された加入者番号が有効であれば（Ｓ１７０：ＹＥＳ）、Ｓ１９０（図１０参照）に移行する。Ｓ１９０では、音声応答メッセージを送出し、リクエストコードの入力を促す。続くＳ２００〜２２０では、ダイヤルパルスの発信を待ち、入力された番号をリクエスト受付バッファ（図５）のリクエストコードの領域Ｃ２に格納していき、これを５桁のリクエストコードがすべて入力されるまで繰り返す。
【００４５】
５桁のリクエストコードが入力されると（Ｓ２２０：ＹＥＳ）、そのリクエストコードの照合を行なう。これは、外部記憶装置１２上のリクエストデータベース（図３）を照会して実行する。そして、Ｓ１４０で有効な番号であるかどうかを判断する。有効な番号でないと判断されれば（Ｓ２４０：ＮＯ）、Ｓ２５０へ移行して、入力のやり直しを求める音声メッセージ（例えば「リクエストコードを再入力してください」）を再生し、Ｓ２００へ戻る。
【００４６】
最初に入力されたリクエストコードが有効である場合、あるいは再度入力されたリクエストコードが有効であれば（Ｓ２４０：ＹＥＳ）、Ｓ２６０の処理に移行する。
Ｓ２６０では、ＣＰＵメモリ１１ｂ上のリクエスト実行テーブル（図４）のリクエストコード領域Ｂ２の内の、再生フラグＢ１が「未」となっているものの中に、同一のリクエストコードがないかどうかを判断する。ここで、リクエスト実行テーブルについて説明しておく。このリクエスト実行テーブルは、図４に示すように、再生フラグＢ１、リクエストコードＢ２、演奏開始予定時刻Ｂ３の３つの項目からなっている。
【００４７】
後述するＳ３１０の処理（図１１参照）において、新規登録をするとの判断がなされた場合には、Ｓ３３０において、リクエスト受付バッファ（図５）の内容をリクエスト実行テーブル（図４）内の受付ポインタＢ５の示しているリクエストコード領域Ｂ２に追加登録する。この追加登録は、リクエストコードＣ２を受付ポインタＢ５の示すリクエストコード領域Ｂ２にコピーし、再生フラグＢ１を「未」とすることにより行われる。なお、初期状態では再生フラグＢ１にはすべて「無」が、リクエストコードＢ２には不定値が入っているものとする。また、演奏開始予定時刻Ｂ３は、一つ前のリクエストコードＢ２を登録した場合に、その曲の再生時間を加算することによって、次に新規登録された場合の演奏開始予定時刻Ｂ３が決定する。新規登録が終了すると受付ポインタＢ５がリクエスト実行テーブル（図４）上の次の領域に進められるため、その領域の演奏開始予定時刻Ｂ３の欄に、上述した「次に新規登録された場合の演奏開始予定時刻」が書き込まれることとなる。
【００４８】
図９に戻り、Ｓ２６０では、このリクエスト実行テーブル（図４）のリクエストコード領域Ｂ２の内の、再生フラグＢ１が「未」となっているものの中に、同一のリクエストコードがないかどうかを判断するのである。そして、既に登録されていれば（Ｓ２６０：ＹＥＳ）、Ｓ２７０へ移行して、その登録済みの演奏開始予定時刻を取り出す。例えば、新規に受け付けたリクエストコードが「０１３０１」であった場合には、同じものが既に登録されているので、これは「重複リクエスト」であり、その登録済みのリクエストコードに対応する演奏開始予定時刻である「１２時３０分」を取り出すこととなる。
【００４９】
一方、登録されていなければ（Ｓ２６０：ＮＯ）、Ｓ２８０へ移行して、新規登録の場合の演奏開始予定時刻を取り出す。これは、受付ポインタＢ５の示す領域のものであり、図４に示す場合では、「１２時３９分」となる。
そして、Ｓ２７０において登録済みの演奏開始予定時刻を取り出した場合には、Ｓ２９０において重複リクエスト用の音声応答メッセージを送出する。これは、上記登録済みの演奏開始予定時刻を重複リクエストである旨とセットで視聴者側に知らせるための音声応答メッセージである。例えば「同じリクエストがすでに受け付けられおり、重複リクエストです。その○○は、今から××番目の曲として、◇◇時□□分頃に放送されます。」といったような内容である。
【００５０】
一方、Ｓ２８０において新規登録の場合の演奏開始予定時刻を取り出した場合には、Ｓ２９５にて新規リクエスト用の音声応答メッセージを送出する。これは、上記新規登録の場合の演奏開始予定時刻をリクエストの受付が完了した旨とセットで視聴者側に知らせるための音声応答メッセージである。例えば「リクエストを受け付けました。あなたのリクエストされた○○は、今から××番目の曲として、◇◇時□□分頃に放送されます。」といったような内容である。
【００５１】
これにより、リクエストした視聴者は、まず、新規のリクエストであるか重複リクエストであるかが判ると共に、いずれの場合であっても、即座に自分のリクエストした曲あるいはリクエストしたものと同じ曲の放送時刻（演奏開始時刻）が判る。
【００５２】
Ｓ２９０あるいはＳ２９５処理の後は、Ｓ３００へ移行して回線を切断する。そして、Ｓ３００での回線切断処理が終了すると、Ｓ３１０（図１１参照）に移行する。
Ｓ３１０では、新規登録をするかどうか判断する。このＳ３１０での新規登録をするかしないかの判断は、上述したＳ２６０での判断で、既に登録されていた場合には新規登録をしないと判断し、登録されていない場合には新規登録すると判断する。
【００５３】
新規登録をする場合にはＳ３２０以降の処理を実行する。つまり、Ｓ３２０においては、受け付けた日時をタイムスタンプとしてリクエスト受付バッファ（図５）の受付時刻の領域Ｃ１に書き込む。ここまでの処理が終了すれば、図５に示すリクエスト受付バッファ上には受付時刻Ｃ１、有効なリクエストコードＣ２及び有効な加入者コードＣ３の３要素が揃い、実際のリクエストの受付が可能になるので、続くＳ３３０では、このリクエスト受付バッファ（図５）の内容をリクエスト実行テーブル（図４）内の受付ポインタＢ５の示しているリクエストコード領域Ｂ２に新規登録する。この新規登録は、リクエスト受付バッファ（図５）リクエストコードＣ２を受付ポインタの示すリクエストコード領域Ｂ２にコピーし、再生フラグＢ１を「未」とすることにより行われることは上述した。
【００５４】
Ｓ３３０での新規登録の処理終了後、Ｓ３４０へ移行する。Ｓ３４０では、受付ポインタＢ５をリクエスト実行テーブル（図４）上の次の領域に進める。この動作が、後述するリクエスト再生処理（図１１）の動作に反映する。
さらに、続くＳ３５０では、受け付けたリクエストをログ記録として保持するために、外部記憶装置１２のリクエストログ記録（図６）における受付時刻領域Ｄ１、リクエストコード領域Ｄ２、加入者コード領域Ｄ３（このＤ１〜Ｄ３は、図５のリクエスト受付バッファと同様の要素を持つ。）にそれぞれの要素をコピーする。そして、さらにこの場合は、新規リクエストであるので、重複フラグ領域Ｄ４に「０」をセットする。この重複フラグについては後で詳細に説明する。
【００５５】
次に、Ｓ３６０において、演奏待ちリクエスト数の値をインクリメントし、Ｓ３７０では、リクエスト受付バッファ（図５）のリクエストコードＣ２を基に検索したリクエストデータベース（図３）の要素である再生時間Ａ３の値を、図４のリクエスト実行テーブルの演奏開始予定時刻の最新のもの（受付ポインタＢ５の示す一つ前の領域に書き込まれているもの）に加算する。これにより、次にリクエストがされた場合の演奏開始予定時刻が算出され、この時刻を受付ポインタＢ５の示す演奏開始予定時刻領域Ｂ３に書き込む。
【００５６】
なお、この後は、再び着信待ち状態（Ｓ１００）に戻り、以降の処理を繰り返す。
一方、新規登録をしない場合には（Ｓ３１０：ＮＯ）、Ｓ３８０の処理を実行してからＳ１００へ戻ることとなる。Ｓ３８０では、受け付けたリクエストをログ記録として保持するために、上述したＳ３５０と同様に、外部記憶装置１２のリクエストログ記録（図６）における受付時刻領域Ｄ１、リクエストコード領域Ｄ２、加入者コード領域Ｄ３にそれぞれの要素をコピーする。そして、この場合には重複リクエストであるので、Ｓ３５０とは異なり、重複フラグ領域Ｄ４に「１」をセットする。
【００５７】
ここで、重複フラグについて補足説明する。上記Ｓ３５０あるいはＳ３８０によって、重複しない新規のリクエストであれば重複フラグとして「０」がセットされ、重複リクエストの場合には「１」がセットされる。新規リクエストであろうが重複リクエストであろうが視聴者からのリクエストがされたことにはかわりないので、リクエストがされたこと自体をログとして残しておくために、いずれの場合にもリクエストログ記録（図６）に記録する。しかし、後述する課金集計処理（図１３）において、新規リクエストの場合と重複リクエストの場合の区別なく単にリクエストがなされた事実だけに基づいて集計してしまうと、不都合があるため、これらの区別を付けるために重複フラグを設けたのである。
【００５８】
なお、上記不都合とは例えば次のようにことである。例えば、単にリクエストがされた実績だけに基づいて料金を計算してしまうと、実際に放送したカラオケ曲数と料金徴収対象となったリクエスト数とが異なってしまい、放送システム事業者側が一部タダ取りしてしまうような状況となることである。そこで本実施例の放送センタ１０においては、実際に放送したカラオケ曲数と料金徴収対象となったリクエスト数とが一致するために、重複フラグとして、重複したリクエストであるかどうかを区別する情報を設定しておき、適切な課金処理に利用しようとしているのである。
【００５９】
次に、リクエスト再生処理（図１２）について説明する。
本処理は、ＣＰＵメモリ１１ｂ上のリクエスト実行テーブル（図４）に登録されたリクエストコードの再生の手順を示す。
まず、最初のステップＳ４１０において、リクエスト実行テーブル（図４）内の再生ポインタＢ４が示す領域より、再生フラグＢ１を取り出す。再生フラグＢ１が「未」でなければ（Ｓ４２０：ＮＯ）、リクエスト実行テーブル（図４）の登録内容の再生がすべて済んでいる、若しくは登録内容が空であるため、そのままリクエスト自動受理・登録処理（図９〜図１１）によるリクエストの追加登録待ちに入る（Ｓ４３０）。
【００６０】
一方、再生フラグＢ１が「未」であれば、Ｓ４４０へ移行し、リクエストコードＢ２を取り出す。そして、Ｓ４５０にて、同リクエストコードＢ２をカラオケ再生装置１４に渡し、再生の指示を出す。さらに、Ｓ４６０にて、再生フラグＢ１を「中」に変え、続くＳ４７０にて、カラオケ再生装置１４の再生状態のチェックを行う。
【００６１】
再生の終了がカラオケ再生装置１４より指示されるまでこれを繰り返す（Ｓ４８０：ＮＯ）。そして、再生が終了すると（Ｓ４８０：ＹＥＳ）、Ｓ４９０へ移行して再生フラグＢ１を「済」に変え、Ｓ５００にて、再生ポインタＢ４を次のテーブルに移動する。
【００６２】
次に、Ｓ５１０において、演奏待ちリクエスト数の値をデクリメントする。なお、この後は、再びＳ４１０に戻り、次のリクエストの再生を繰り返す。
以上、図９〜図１１でリクエスト自動受理・登録処理、図１２でリクエスト再生処理について説明したが、次に、所定のタイミング、例えば１か月毎に実行される課金集計処理について図１３を参照して説明する。なお、この処理は、例えば放送センタ１０が放送関連処理を実行していない時期（例えば深夜や早朝といった時間帯）に実行すればよい。
【００６３】
本課金集計処理においては、まず、最初のステップＳ６１０において加入者数カウンタをクリアし、次のステップＳ６２０において、課金曲数カウンタをクリアする。
そして、続くＳ６３０では、加入者データベース（図７）より加入者コードを取得する。これは、加入者データベースに登録されている加入者コードの順番に順次取得してくる。
【００６４】
続くＳ６４０では、加入者数カウンタの値が加入者データベースの登録者数以上であるかどうかを判断する。加入者数カウンタの値が加入者データベースの登録者数以上であれば（Ｓ６４０：ＹＥＳ）、そのまま本処理を終了するが、加入者数カウンタの値が加入者データベースの登録者数より小さければ（Ｓ６４０：ＮＯ）、Ｓ６５０以下の処理を実行する。
【００６５】
Ｓ６５０では、現在参照しているファイルがリクエストログ記憶（図６）のログファイルエンドになっているかどうかを判断し、ログファイルエンドでなければ、Ｓ６６０へ移行して、リクエストログ記憶より１リクエスト分のログを取得する。なお、このＳ６６０でのログ取得は、リクエストログ記憶（図６）に記憶されているログの順番に順次取得してくる。
【００６６】
続くＳ６７０においては、Ｓ６３０で加入者データベ−スから取得した加入者コードと、Ｓ６６０で取得したログの加入者コードとを比較する。そして２つの加入者コードが一致していれば、Ｓ６８０へ移行するが、一致していなければＳ６５０へ戻る。
Ｓ６８０では、ログの重複フラグＤ４（図６参照）が「１」であるかどうかによって重複リクエストであるかどうかを判断する。重複フラグＤ４が「１」であれば重複リクエストであり、重複フラグＤ４が「０」であれば重複リクエストではない。
【００６７】
そして、重複リクエストでなければ（Ｓ６８０：ＮＯ）、Ｓ６９０へ移行して課金曲数カウンタをインクリメントしてから、Ｓ６５０へ戻る。一方、重複リクエストである場合には（Ｓ６８０：ＹＥＳ）、Ｓ６９０の処理を行なうことなくＳ６５０へ戻る。
【００６８】
このようにしてＳ６３０で取得した加入者コードに対応するログを検索して、重複リクエストでなければ課金曲数カウンタをインクリメントしていく集計処理を順次を行っていき、Ｓ６５０で肯定判断、つまりログファイルエンドまで処理した場合にはＳ７００へ移行する。
【００６９】
Ｓ７００では、課金曲数カウンタの課金曲数に、１曲についての単価を乗算して課金金額を算出する。そして、続くＳ７１０では、図８の課金実績テーブルの該当する加入者コードのファイルとして、課金曲数とＳ７００で算出した課金金額を記憶する。
【００７０】
これで、１人分の課金実績の記憶が終了したので、次の加入者に対する課金実績の集計・記憶処理に移行する。具体的には、続くＳ７２０で加入者数カウンタの値をインクリメントしてから、Ｓ６２０へ戻る。Ｓ６２０で課金曲数カウンタをクリアし、Ｓ６３０で次の加入者コードを加入者データベース（図７）から取得する。そして、Ｓ６４０以降の処理を行なう。
【００７１】
このようにして加入者データベース（図７）に記憶されている全ての加入者コードに対しての課金実績の集計・記憶が終了すると、Ｓ６４０で肯定判断となるため、これで本処理を終了する。
なお、この図８に示す課金実績テーブルに記憶されたデータが例えば金融機関に送られて自動引き落しで徴収されたり、あるいは請求書として印刷され、管理者側の料金回収スタッフが利用者側に直接出向いて徴収したりすることとなる。
【００７２】
以上説明した本実施例の放送センタ１０によれば、リクエスト応答と課金のための実績情報の記憶という基本的な機能を備えていると共に、さらに次のような機能を発揮する。すなわち、視聴者からのリクエストが重複リクエストである場合には、図１０のＳ２９０に示すように、重複リクエストである旨をリクエストしてきた視聴者側に対し音声応答メッセージとして応答する。そして、リクエストログ記憶（図６）には記憶するが、リクエスト実行テーブル（図４）には新規登録をしない。
【００７３】
このように、受信したリクエストが重複リクエストである場合にリクエスト実行テーブルに新規登録をしないことによって、必要性の薄いリクエストに応じたカラオケ曲が放送されることが防止され、放送内容の充実につながる。つまり、重複リクエストの場合には、既に予約されているが放送はまだ開始されていないリクエストに応じたカラオケ曲がこれから放送されるので、重複リクエストを行った視聴者にとっては、そのカラオケ曲が放送されることよって要求が満たされることとなる。そのため、仮に重複したリクエストもそのままリクエスト実行テーブル（図４）に登録させてしまうと、自分の希望するカラオケ曲であるが、実際は他人のリクエストに応じたカラオケ曲が放送された後で、さらに今度は自分のリクエストに応じたカラオケ曲が放送されることとなり、重複リクエストをした視聴者にとっての必要性は非常に薄くなる。
【００７４】
したがって、このような重複リクエストに応じたカラオケ曲は放送しないように制御することで、視聴者の要求を満足させながら、必要性の薄いカラオケ曲の放送を防止する等、放送内容の充実を図ることができる。特に、リクエストを受け付ける期間が限られている場合に、必要性の薄いリクエストのために真にリクエストをしたかった人が要求できなかったり、あるいはその人のリクエストに応じたカラオケ曲の放送時刻が遅くなったりすることは放送内容の充実や利用者の便宜の向上を阻害するものである。したがって、そのような必要性の薄いカラオケ曲を放送しないようにすることが、放送内容の充実や利用者の便宜の向上につながるのである。
【００７５】
また、図１１に示した処理からも判るように、受信したリクエストが重複リクエストである場合に、リクエストログ記憶（図６）に記憶する場合に、重複フラグを「１」にして記憶している。そのため、図１３の課金集計処理において、Ｓ６８０で重複フラグが１であるとＳ６９０での課金曲カウンタがインクリメントされない。したがって、結果的に、その重複リクエストについては課金金額の算出対象とはならない。
【００７６】
これによって、料金徴収についても適切な対処が可能となる。例えば単純にリクエストログ記憶（図６）に記憶されているリクエストログ数だけに基づいて料金を計算してしまうと、実際に放送したカラオケ曲数と料金徴収対象となったリクエスト数とが異なってしまい、放送システム事業者側が一部タダ取りしてしまうような状況となる。そこで本実施例のようにすれば、実際に放送したカラオケ曲数と料金徴収対象となったリクエスト数とが一致し、公正・健全なシステム運営の点で好ましい。
【００７７】
また、重複リクエストをした視聴者には、重複リクエストである旨が音声応答メッセージとして応答される。そのため、視聴者にとっては重複したリクエストであることが認識できる。そして、重複リクエストの場合には通常のリクエストをした場合の料金とは異なる（例えば無料になる）ことが予め通知されているのであれば、リクエストが重複している旨の音声応答メッセージにより、そのことも認識できる。
【００７８】
なお、課金実績の集計等においては、重複リクエストの実績は結果的に必要ないのであるが、図６のリクエストログ記憶としては、そのような重複リクエストもログとして記憶している。これは、放送センタ１０としては、リクエスト数に基づいて例えばリクエストランキングを作成する等、種々の理由によってリクエスト自体がされたことの実績は残しておくことが好ましいからである。
【００７９】
また、本実施例においては、リクエストをした場合には、それが重複リクエストであってもそうでなくても、そのリクエストに応じたカラオケ曲の放送開始予定時刻を音声応答メッセージとして視聴者に通知している。そのため、視聴者は自分のリクエストしたカラオケ曲の放送がいつ開始されるかを、ほぼリアルタイムで知ることができる。そのため、自分のリクエストしたカラオケ曲の放送開始までに例えば別の用事を済ませるといったこともでき、いつ始まるか判らないので単に待っているだけという無駄な時間をなくすことができるというように、視聴者の利用の便宜を向上させることができる。
【００８０】
以上、具体例に従って、本発明の実施の形態について説明したが、本発明はこのような具体例に限定されるものではなく、発明の要旨を逸脱しない範囲で様々な実施ができることは言うまでもない。
例えば、上記実施例では、図１３の課金集計処理において、課金曲数とそれに基づいて算出した課金金額を、「課金実績情報」として課金実績テーブル（図８）に記憶するようにしたが、例えば課金曲数だけを記憶しておき、それに基づいて別の課金処理システムが課金関連処理を実行するようにしてもよい。また、課金金額だけを記憶しておいてもよい。
【００８１】
そしてまた、課金金額の算出については、上記実施例では１曲の単価が固定であるという前提で説明したが、例えば新曲は高く、古い曲は安く設定している場合には、リクエストログ記憶にそれらの区別を付けるためのデータを記憶しておき、それぞれの場合の料金を記憶しておく料金テーブルから読み出した料金に基づいて算出するようにしてもよい。
【００８２】
また、上記実施例では、カラオケ番組の放送に使用する例を説明したが、本発明は放送用情報を供給するサーバ側が少数であり、放送用情報を要求するクライアント側が多数であり、両者が遠隔である等の理由で、放送という情報供給形態を採用する状況であることが応用の主旨である。したがって、放送用情報として音声情報だけあるいは映像情報だけという場合も考えられる。
【図面の簡単な説明】
【図１】実施例の放送センタの概略構成を示すブロック図である。
【図２】ホストコンピュータを中心した信号の流れを示す説明図である。
【図３】ホストコンピュータが取り扱うリクエストデータベースのデータ構造図である。
【図４】ホストコンピュータが取り扱うリクエスト実行テーブルのデータ構造図である。
【図５】ホストコンピュータが取り扱うリクエスト受付バッファのデータ構造図である。
【図６】ホストコンピュータが取り扱うリクエストログ記録のデータ構造図である。
【図７】ホストコンピュータが取り扱う加入者データベースのデータ構造図である。
【図８】ホストコンピュータが取り扱う課金実績テーブルのデータ構造図である。
【図９】ホストコンピュータが実行するリクエスト自動受理・登録処理の一部を示すフローチャートである。
【図１０】ホストコンピュータが実行するリクエスト自動受理・登録処理の一部を示すフローチャートである。
【図１１】ホストコンピュータが実行するリクエスト自動受理・登録処理の一部を示すフローチャートである。
【図１２】ホストコンピュータが実行するリクエスト再生処理を示すフローチャートである。
【図１３】ホストコンピュータが実行する課金集計処理を示すフローチャートである。
【符号の説明】
１０…放送センタ１１…ホストコンピュータ
１１ａ…ＣＰＵ１１ｂ…ＣＰＵメモリ
１２…外部記憶装置１３…表示装置
１４…カラオケ再生装置１６…放送手段
２０…音声応答装置４０…公衆電話回線
５０…加入者電話機[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a broadcast center with a request response function that sequentially broadcasts broadcast information corresponding to broadcast requests made by viewers in a predetermined order, and in particular, a predetermined response to the request response. The present invention relates to a broadcasting center that is effective for use in a system that charges a fee.
[0002]
[Background Art and Problems to be Solved by the Invention]
Currently, a new form of TV broadcasting called interactive television is becoming widespread between local television broadcasting centers such as CATV systems and subscriber terminals. The broadcasting center of such a system not only distributes the determined information at the determined time, but also sequentially broadcasts the broadcast information according to the broadcast request made individually by the viewer in a predetermined order. It has come to have a request response function. For example, a program time frame (or a dedicated channel provided) that handles only karaoke broadcasts called a karaoke request program is adopted, and in this program, requests from viewers are accepted via telephone etc. It is to broadcast karaoke upon request.
[0003]
When broadcasting karaoke according to a request in this way, for example, it is conceivable to receive and reserve a request up to a predetermined number of songs, and broadcast karaoke according to the reservation request sequentially. In this case, there is a possibility that there is a request that the request itself has already been reserved, but broadcasting of the corresponding karaoke song has not yet started. If the new request is already reserved in such a state but the broadcast is the same as it is, the same karaoke song will be broadcast many times if it is also reserved as a request As a result, the content of the broadcast will become rutted.
[0004]
Also, the user who made the request may be the one requested by the user or the one requested by another person, but it is only necessary to broadcast the desired karaoke song. Your request has already been met. Therefore, even if a karaoke song corresponding to the one requested by him / herself is broadcasted after that, since the same karaoke song has already been broadcast, the necessity for the requesting user becomes very light.
[0005]
Therefore, if the request itself has already been reserved, but the same request as the one for which broadcasting of the corresponding karaoke song has not yet started is made, it is registered as reservation data for broadcasting the corresponding karaoke song. It is preferable from the viewpoint of enhancement of broadcast contents.
[0006]
On the other hand, in the case of broadcasting information according to a request in this way, if a predetermined fee is charged for the request response, a metered fee system is introduced instead of a so-called quantitative fee system. The need comes out. That is, the requesting user bears (pays) the fee.
[0007]
However, with regard to charge collection in this case, it may be inconvenient if the charge is simply calculated based only on the number of requests. This is because, as described above, the requested content may not be registered as reservation data for the karaoke song to be broadcasted, for example, in order to prevent the broadcast content from becoming rutted. In such a situation, if the fee is simply calculated based only on the number of requests, the number of broadcast songs differs from the number of requests for which the fee is collected. It will be a situation where you get some free.
[0008]
The same problem can be considered not only for television broadcasting but also for radio broadcasting or other broadcasting.
The present invention basically has a function of broadcasting broadcast information in response to a request from a viewer and storing performance information for charging a predetermined fee corresponding to the request for each viewer who requests it. It is an object of the present invention to provide a broadcasting center capable of appropriately responding to enhancement of broadcast contents and improvement of convenience for users when there are further duplicate requests.
[0009]
[Means for Solving the Problems and Effects of the Invention]
In order to achieve this object, the invention according to claim 1 is a request receiving means for receiving a broadcast request made individually from a viewer using a communication line and automatically storing it as data in the request storage means. Broadcast information corresponding to the broadcast request stored in the request storage means, and broadcast means that sequentially broadcasts the broadcast information according to a predetermined order, and broadcast requests stored in the request storage means by the broadcast request reception means. Received by the request accepting means in a broadcast center with a request response function having a charge performance information storage means for storing performance information for charging a corresponding predetermined fee for each viewer who has requested broadcasting. The broadcast request is already stored in the request storage means, but the broadcast information corresponding to the broadcast request is not yet started by the broadcast means. A response means for responding to the viewer side that has transmitted the broadcast request as audio information via the communication line, if the request is a duplicate broadcast request. WithIn addition to the fact that the broadcast request is duplicated, the response means relates to a broadcast start schedule of broadcast information corresponding to the broadcast request that has been started the earliest among the broadcast requests that have not already been accumulated and broadcast. The information is also configured to respond, The request receiving means is configured to not store the duplicate broadcast request in the request storage means when the received broadcast request is the duplicate broadcast request. The center.
[0010]
In the broadcast center of the present invention having the above-described configuration, the request receiving means receives broadcast requests made individually from viewers using a communication line, and automatically stores them as data in the request storage means. The broadcast means is provided with a request response function in which broadcast information corresponding to the broadcast request stored in the request storage means is sequentially broadcast in a predetermined order.
[0011]
In addition, the performance information for charging a predetermined fee corresponding to the broadcast request stored in the request storage unit by the broadcast request receiving unit is stored in the accounting result information storage unit for each viewer who made the broadcast request. I can leave. Based on this record information, predetermined billing and fee collection are separately performed. For example, an automatic withdrawal from a financial institution or a fee collection staff on the manager side goes directly to the user side and collects it.
[0012]
In this way, the basic function of storing request information and performance information for billing is provided, and the following functions are further exhibited. That is, the broadcast request received by the request accepting means is already stored in the request storing means, but the broadcast information corresponding to the broadcast request is the same as the broadcast request that has not yet been started. In the case of a duplicate broadcast request, the fact that the broadcast request is duplicated is responded to the viewer who has transmitted the broadcast request as audio information via the communication line. Further, when the received broadcast request is a duplicate broadcast request, the request receiving means does not execute the accumulation of the duplicate broadcast request in the request accumulation means.
[0013]
In this way, when the received broadcast request is a duplicate broadcast request, by not storing the duplicate broadcast request in the request storage means, it is possible to prevent broadcast information that is less necessary from being broadcast, It leads to enhancement of broadcast contents. In other words, in the case of a duplicate broadcast request, since broadcast information corresponding to a broadcast request that has already been accumulated but has not yet started broadcasting will be broadcast from now on, for viewers who have made duplicate broadcast requests, The request is satisfied by the broadcast information. Therefore, if the duplicate broadcast requests are stored as they are, the same broadcast information will be broadcast after the broadcast information corresponding to the broadcast request made by the user is broadcast, and the viewer who made the broadcast request The need for is very thin.
[0014]
Therefore, by controlling not to broadcast the broadcast information in response to such a duplicate broadcast request, it is possible to prevent broadcast of broadcast information that is less necessary while satisfying the viewer's request. Can be enriched. In particular, when the period for receiving a broadcast request is limited, it is a broadcast that a person who really wanted to make a broadcast request because of a less necessary broadcast request cannot request or the broadcast time is delayed. This hinders the enhancement of content and the convenience of users. Therefore, not broadcasting such broadcasting information that is not necessary leads to enhancement of broadcasting contents and improvement of convenience for users.
[0015]
Further, when the received broadcast request is a duplicate broadcast request, the charge record information storage means does not store the record information for charging by not storing the duplicate broadcast request in the request storage means. . In other words, since the broadcast information corresponding to the broadcast request itself is not broadcasted, it is not stored as billing record information.
[0016]
As a result, it is possible to appropriately deal with fee collection. For example, if a fee is simply calculated based only on the actual number of broadcast requests (for example, the number of times), the number of broadcast information actually broadcast differs from the number of broadcast requests subject to fee collection. It will be a situation where a part of the person will be free. Therefore, according to the present invention, the number of broadcast information actually broadcast matches the number of broadcast requests subject to charge collection, which is preferable in terms of fair and sound system operation.
[0017]
It should be noted that a viewer who has made a duplicate broadcast request is notified as audio information via the communication line that the broadcast request is duplicated. Therefore, it can be recognized that it is a duplicate broadcast request for the viewer. In the case of a duplicate broadcast request, if it is notified in advance that the charge is different from the charge for a normal broadcast request (for example, free of charge), a voice response to the effect that this broadcast request is duplicated This can also be recognized.The response means for responding to the viewer that the broadcast request is duplicated further, in addition to the fact that the broadcast request is duplicated, the earliest broadcast start of the broadcast requests that have not been stored or started yet. Information on the broadcast start schedule of the broadcast information according to what is performed is also responded.
[0018]
The invention according to claim 2 is the broadcast center according to claim 1, wherein the broadcast request received by the request receiving means is stored in the request storage means and the duplicate broadcast request. A request reception record storage unit for storing the request reception record as a request reception record in a state that can be distinguished from that in which the accumulation in the request storage unit has not been performed. Of the request reception results stored in the reception result storage means, it is configured to store charging result information corresponding to the request reception results obtained by accumulating broadcast requests in the request storage means. .
[0019]
As described above, when broadcast requests are duplicated under certain conditions, the broadcast requests are not stored in the request storage unit. However, it is preferable for the broadcast center to keep track of the fact that the broadcast request itself has been made for various reasons, such as creating a request ranking based on the number of broadcast requests. Therefore, according to the second aspect of the present invention, the received broadcast request is distinguished from the request accumulation means that is not accumulated in the request accumulation means because it is a duplicate broadcast request. It can be stored as a request reception record in a possible state. In this case, the charging record information storage unit stores the charging record information corresponding to the request reception record in which the broadcast request is stored in the request storage unit among the stored request reception records. 1 exhibits the same effect.
[0020]
As described above, the broadcasting center of the present inventionResponse means, ReleaseIn addition to the fact that the transmission request is duplicated, the information on the broadcast start schedule of the broadcast information corresponding to the broadcast request that has already been started and of the broadcast request that has not been stored / broadcast has been returnedThe
[0021]
ThisIn the case of3As shown in the figure, it is provided with a required time storage means for storing a required broadcast time for each broadcast information, and a response means is provided for each required broadcast time information of the broadcast information corresponding to the broadcast request stored in the request storage means. Based on the broadcast request stored in the request storage means by the request receiving means, the scheduled required time or the scheduled start time of the broadcast information is calculated, and the scheduled required time or the scheduled start time is used as audio information. It is possible to respond.
[0022]
In this way, the viewer can know information related to the broadcast start schedule, such as the time required to start broadcasting the broadcast information requested by the viewer or the performance start time, in almost real time. For this reason, it is possible to complete another task, for example, by the time the broadcast information requested by the user starts, and it is not possible to know when it will start, so it is possible to eliminate wasted time simply waiting. User convenience can be improved.
[0023]
Moreover, as information for broadcasting broadcast from such a broadcasting center, for example, information for karaoke can be considered. In this case, the claim4As shown, the broadcasting means is a television broadcasting means capable of transmitting audio information and video information, and the broadcasting information broadcast by the broadcasting means is a karaoke performance sound and background video corresponding to the requested karaoke song. It is conceivable to include an image synthesized with lyrics telop.
[0024]
Of course, even if only the karaoke performance sound is broadcast as broadcast information, it will be established as a karaoke, but it is common sense that the current karaoke no longer displays a video in which lyrics telop is combined with the background video along with the karaoke performance. Therefore, it can be said that it is preferable to broadcast broadcasting information including a karaoke performance sound and a video in which a lyrics telop is synthesized with a background video. In this case, the broadcasting center and the subscriber terminal may be connected by wire as in the so-called CATV, or may remain wireless as in a normal broadcasting system. Further, there may be cases where only audio information or video information is used.
[0025]
When receiving a broadcast request from the viewer, the request receiving means may transmit predetermined guidance voice information to the viewer and receive the broadcast request as a response to the guidance voice information. In this way, the viewer only has to operate according to the guidance audio information, and the convenience of the viewer is further improved. For example, since it is actually necessary to transmit viewer identification information and the like, it is convenient to have guidance.
[0026]
The communication line used by the request receiving means to receive a broadcast request may be a telephone line, or the coaxial cable if bidirectional full-duplex communication is realized via a CATV coaxial cable. But you can. In the case of a telephone line, for example, a request number or the like is input by a push button of the telephone, and the request number is transmitted as a code using a dial tone, and the request receiving means receives it.
[0027]
DETAILED DESCRIPTION OF THE INVENTION
An embodiment embodying a broadcasting center of the present invention will be described below with reference to the drawings.
FIG. 1 is a block diagram showing a schematic configuration of a broadcast center 10 of the present embodiment. As shown in FIG. 1, the broadcasting center 10 includes a host computer 11 as a control unit and a “response unit”, an external storage device 12 as a “billing record information storage unit” and a “request reception record storage unit”, and a display. A display device 13 as means, a karaoke playback device 14, broadcast means 16 as "broadcast means", and a voice response device 20 as "request reception means" are provided. The broadcast center 10 is connected to a large number of subscriber telephones 50 through a public telephone line 40.
[0028]
Each component device will be described including its role in the broadcast center 10 or its relationship with the entire broadcast system.
The voice response device 20 receives a broadcast request from the viewer. If the broadcast is a predetermined “duplicate broadcast request”, the voice response device 20 indicates that information and information on the broadcast start schedule of the broadcast information according to the broadcast request. Is to respond as. The duplicate broadcast request will be described later.
[0029]
First, the reception of a broadcast request will be described in detail.
The broadcast center 10 stores broadcast requests individually made by viewers, and sequentially broadcasts broadcast information corresponding to the broadcast requests (in this embodiment, information for karaoke). Although it has a response function, the viewer can watch the television receiver (not shown) connected to the broadcast center 10 by cable television at home, while using the subscriber telephone 50 on hand. A request for broadcasting of desired karaoke information is made through a general public telephone line 40. This broadcast request is made by a predetermined “request code”. This is synonymous with “song number” in a general karaoke apparatus only for providing karaoke viewing. Since the request is based on a numeric code, the viewer actually sends a tone to the request code by dialing the subscriber telephone 50 or pushing down a push phone. It is assumed that this request code is notified to the viewer in advance by a distributed material or the like.
[0030]
The call from the viewer is automatically accepted by the voice response device 20 at the broadcast center 10. The voice response device 20 sends a pre-registered message by a built-in synthesized voice means (not shown), and prompts the viewer to input a request code and provide guidance thereof, and is controlled by the host computer 11. From receiving the above call and sending a message to receiving a pulse code.
[0031]
The request code received by the voice response device 20 is determined by the host computer 11 by checking with the database on the external storage device 12 whether the code is valid. It is stored in the memory 11b (see FIG. 2). The CPU memory 11b corresponds to “request storage unit” and “required time storage unit”.
[0032]
When the host computer 11 accepts the request, the host computer 11 creates a message for notifying that as voice information. Then, the voice response device 20 responds to the subscriber's subscriber telephone 50 that has made a broadcast request via the public telephone line 40.
[0033]
Further, the accumulated request code is transferred to the karaoke playback device 14 controlled by the host computer 11, and the video is played back.
The karaoke playback device 14 of this embodiment can play back a karaoke performance sound and a background video in which lyrics telops are synthesized. Therefore, the broadcasting means 16 is a television broadcasting means. In view of the gist of the invention, since there is no need for video, the karaoke playback device 14 plays back only the karaoke performance sound, and the broadcast means 16 may be so-called radio broadcast means. Of course, when applied to applications other than karaoke, it is conceivable that only video is used.
[0034]
The broadcast content broadcast by the broadcast means 16 is received by a receiving facility such as a television receiver on the viewer side and can be viewed as a karaoke program. Note that the broadcasting center 10 and the receiving facility on the viewer side may be connected by wire as in the CATV system, or may be wireless as in the normal broadcasting system.
[0035]
The display device 13 is connected to the host computer 11 and can display these conditions. This is used for confirmation by the operator of the broadcast center 10.
Next, with reference to FIG. 2, a signal flow centered on the host computer 11 will be described.
[0036]
As shown in FIG. 2, the voice response device 20 is connected to the CPU 11a of the host computer 11 by a control signal. The CPU 11a performs control related to waiting for an incoming call on the public telephone line 40 (see FIG. 1) to the voice response device 20, and control related to voice message transmission within the same device 20 after the incoming call (selection among a plurality of messages). . The voice response device 20 returns the dial pulse received through the public telephone line 40 to the host computer 11 as numerical information. In this way, automatic reception of a request from the viewer through the public telephone line 40 is performed. The numerical value returned from the voice response device 20 is stored in the CPU memory 11b.
[0037]
The external storage device 12 is an external storage of the host computer 11 in which a database related to request codes or an accounting result table is stored, and data is read and written between the devices. Thus, the CPU 11a performs request code search / collation and log recording.
[0038]
The karaoke player 14 is connected to the CPU 11a by a control signal. The CPU 11a can transmit a request code (song number), cause the apparatus 14 to play back the karaoke music, and control the start / end of the playback. Further, the karaoke playback device 14 returns the playback status (during playback, playback end, etc.) to the CPU 11a. Thereby, the CPU 11a can reproduce the karaoke music piece by the request code.
[0039]
Next, the operation of the broadcast center 10 of this embodiment will be described with reference to the drawings.
9 to 13 are flowcharts showing the processing procedure of the program executed by the CPU 11a, and FIGS. 3 to 8 are data structure diagrams handled by this program. Details of the processing flow will be described below. 9 to 11 are flowcharts of the automatic request reception / registration process, and FIG. 12 is a flowchart of the request reproduction process. These processes are so-called multitask processes that operate independently at the same time. FIG. 13 is a flowchart of a billing aggregation process executed at a predetermined timing, for example, every month.
[0040]
First, the automatic request reception / registration process (FIGS. 9 to 11) will be described.
This process shows a procedure for automatically accepting a request from the subscriber side through the public telephone line 40 and registering the request in the CPU memory 11b. The subscriber does not simply mean that the broadcast from the broadcasting center 10 can be received, but means that the subscriber has the right to make a request. For example, in a CATV system, when a request right is automatically given when subscribing to the system, all of them become subscribers. When broadcasting in a normal wireless format, for example, it is conceivable to separately make a contract for collecting a predetermined fee instead of making a request. In that case, only the person who made the contract becomes the subscriber.
[0041]
First, in step S100 of FIG. 9, the voice response device 20 is controlled to be able to receive a call via the public telephone line 40, and in S110, the process waits until a call is received from the subscriber telephone 50. . If there is an incoming call (S110: YES), the process proceeds to S120.
[0042]
In S120, the voice response device 20 sends a voice response message (for example, “please enter the subscriber number”) to prompt the user to enter the subscriber number to be received first. Thereafter, in S130, the transmission of the dial pulse from the subscriber telephone 50 is awaited. In S140, the input number is stored in the subscriber code area C3 of the request reception buffer (see FIG. 5) on the CPU memory 11b. This is repeated until all 5-digit subscriber numbers are input (S150).
[0043]
When the 5-digit subscriber number is input (S150: YES), the process proceeds to S160, where it is verified whether the subscriber number is valid. This is done by querying the subscriber database on the external storage device 12 (FIG. 7).
If it is determined that the number is not valid as a result of this collation (S170: NO), a voice message requesting re-entry (for example, “Please re-enter the subscriber number”) is reproduced (S180), and the process goes to S130. Return.
[0044]
If the subscriber number entered first is valid, or if the subscriber number entered again is valid (S170: YES), the process proceeds to S190 (see FIG. 10). In S190, a voice response message is transmitted to prompt the input of a request code. In subsequent steps S200 to S220, the transmission of the dial pulse is awaited, and the entered number is stored in the request code area C2 of the request reception buffer (FIG. 5) until all of the 5-digit request code is inputted. repeat.
[0045]
When a 5-digit request code is input (S220: YES), the request code is verified. This is executed by referring to the request database (FIG. 3) on the external storage device 12. In step S140, it is determined whether the number is valid. If it is determined that the number is not valid (S240: NO), the process proceeds to S250 to play a voice message requesting re-input (for example, "Please re-enter the request code"), and the process returns to S200.
[0046]
If the request code input first is valid, or if the request code input again is valid (S240: YES), the process proceeds to S260.
In S260, it is determined whether or not the same request code exists in the request code table B2 of the request execution table (FIG. 4) on the CPU memory 11b in which the reproduction flag B1 is “not yet”. . Here, the request execution table will be described. As shown in FIG. 4, this request execution table is composed of three items: a reproduction flag B1, a request code B2, and a scheduled performance start time B3.
[0047]
If it is determined in the process of S310 (see FIG. 11) described later that new registration is to be made, the contents of the request reception buffer (FIG. 5) are changed to the reception pointer B5 in the request execution table (FIG. 4) in S330. Are additionally registered in the request code area B2 shown in FIG. This additional registration is performed by copying the request code C2 to the request code area B2 indicated by the reception pointer B5 and setting the reproduction flag B1 to “not yet”. In the initial state, it is assumed that the reproduction flag B1 is all “none” and the request code B2 is an indefinite value. Further, when the previous request code B2 is registered, the scheduled performance start time B3 for the next newly registered performance is determined by adding the playback time of the song. When the new registration is completed, the acceptance pointer B5 is advanced to the next area on the request execution table (FIG. 4). The “scheduled start time” is written.
[0048]
Returning to FIG. 9, in S260, it is determined whether or not the same request code exists in the request code area B2 of this request execution table (FIG. 4) in which the reproduction flag B1 is “not yet”. To do. If it is already registered (S260: YES), the process proceeds to S270, and the registered scheduled performance start time is taken out. For example, if the newly accepted request code is “01301”, the same code has already been registered, so this is a “duplicate request” and the performance start schedule corresponding to the registered request code is scheduled. The time “12:30” will be taken out.
[0049]
On the other hand, if it is not registered (S260: NO), the process proceeds to S280, and the scheduled performance start time in the case of new registration is extracted. This is in the area indicated by the acceptance pointer B5, and is “12:39” in the case shown in FIG.
If the registered scheduled performance start time is extracted in S270, a voice response message for duplicate request is sent in S290. This is a voice response message for informing the viewer side that the registered scheduled performance start time is a duplicate request and a set. For example, “The same request has already been accepted and it is a duplicate request. The XX will be broadcast as the XXth song from now on around ◇◇ time □□ minutes.”
[0050]
On the other hand, if the scheduled performance start time in the case of new registration is extracted in S280, a voice response message for a new request is transmitted in S295. This is a voice response message for informing the viewer of the scheduled start time of performance in the case of the new registration, together with the fact that the reception of the request has been completed. For example, “Your request has been accepted. Your requested XX will be broadcast as the XXth song from now on ◇◇ hour □□ minutes.”
[0051]
As a result, the requesting viewer first knows whether the request is a new request or a duplicate request, and in any case, immediately broadcasts the song requested or the same as the requested song. The time (performance start time) is known.
[0052]
After S290 or S295, the process proceeds to S300 to disconnect the line. When the line disconnection process in S300 is completed, the process proceeds to S310 (see FIG. 11).
In S310, it is determined whether or not new registration is performed. The determination as to whether or not to perform new registration in S310 is based on the determination in S260 described above. If it has already been registered, it is determined that new registration is not performed, and if it is not registered, new registration is determined. To do.
[0053]
In the case of new registration, the processing after S320 is executed. That is, in S320, the received date and time is written as a time stamp in the reception time area C1 of the request reception buffer (FIG. 5). When the processing so far is completed, the request reception buffer shown in FIG. 5 has three elements of reception time C1, valid request code C2, and valid subscriber code C3, and the actual request can be accepted. Therefore, in the subsequent S330, the contents of the request reception buffer (FIG. 5) are newly registered in the request code area B2 indicated by the reception pointer B5 in the request execution table (FIG. 4). As described above, this new registration is performed by copying the request reception buffer (FIG. 5) request code C2 to the request code area B2 indicated by the reception pointer and setting the reproduction flag B1 to “not yet”.
[0054]
After completion of the new registration process in S330, the process proceeds to S340. In S340, the reception pointer B5 is advanced to the next area on the request execution table (FIG. 4). This operation is reflected in the operation of request reproduction processing (FIG. 11) described later.
Further, in subsequent S350, in order to hold the received request as a log record, the reception time area D1, the request code area D2, and the subscriber code area D3 (this D1 to D1) in the request log record (FIG. 6) of the external storage device 12 are stored. D3 has the same elements as the request reception buffer in FIG. 5). Further, in this case, since it is a new request, “0” is set in the duplication flag area D4. This duplication flag will be described later in detail.
[0055]
Next, in S360, the value of the number of requests waiting for performance is incremented. In S370, the value of the reproduction time A3 that is an element of the request database (FIG. 3) searched based on the request code C2 of the request reception buffer (FIG. 5). Is added to the latest performance start time (written in the previous area indicated by the acceptance pointer B5) in the request execution table of FIG. Thus, the scheduled performance start time for the next request is calculated, and this time is written in the scheduled performance start time area B3 indicated by the reception pointer B5.
[0056]
Thereafter, the process returns to the incoming call waiting state (S100) again, and the subsequent processing is repeated.
On the other hand, when new registration is not performed (S310: NO), the process returns to S100 after executing the process of S380. In S380, in order to hold the received request as a log record, as in S350 described above, the reception time area D1, request code area D2, and subscriber code area D3 in the request log record (FIG. 6) of the external storage device 12 Copy each element to. In this case, since it is a duplicate request, “1” is set in the duplicate flag area D4, unlike S350.
[0057]
Here, a supplementary explanation of the duplication flag will be given. As a result of S350 or S380, “0” is set as a duplication flag for a new request that does not overlap, and “1” is set for a duplicate request. Whether it is a new request or a duplicate request, it doesn't matter that the viewer has made a request, so in each case a request log is recorded to keep a log of the request itself. Record in (FIG. 6). However, in the accounting aggregation process (FIG. 13) described later, it is inconvenient if the aggregation is based solely on the fact that requests are made without distinction between new requests and duplicate requests. In order to attach it, a duplicate flag is provided.
[0058]
The inconvenience is, for example, as follows. For example, if the fee is calculated based solely on the actual request, the number of karaoke songs actually broadcast differs from the number of requests that are subject to fee collection. It will be a situation that will be taken. Therefore, in the broadcasting center 10 of the present embodiment, since the number of karaoke songs actually broadcast matches the number of requests for which charges are collected, information for distinguishing whether or not the request is a duplicate is used as a duplication flag. It is set and used for appropriate billing processing.
[0059]
Next, request reproduction processing (FIG. 12) will be described.
This process shows the procedure for reproducing the request code registered in the request execution table (FIG. 4) on the CPU memory 11b.
First, in the first step S410, the reproduction flag B1 is extracted from the area indicated by the reproduction pointer B4 in the request execution table (FIG. 4). If the reproduction flag B1 is not “not yet” (S420: NO), the reproduction of the registered contents in the request execution table (FIG. 4) is all completed or the registered contents are empty, so that the request automatic acceptance / registration process is performed as it is. The system waits for additional registration of requests according to (FIGS. 9 to 11) (S430).
[0060]
On the other hand, if the reproduction flag B1 is “not yet”, the process proceeds to S440, and the request code B2 is extracted. Then, in S450, the request code B2 is transferred to the karaoke playback device 14 and a playback instruction is issued. Further, the reproduction flag B1 is changed to “medium” in S460, and the reproduction state of the karaoke reproducing apparatus 14 is checked in S470.
[0061]
This is repeated until the end of playback is instructed by the karaoke playback device 14 (S480: NO). When the reproduction ends (S480: YES), the process proceeds to S490, the reproduction flag B1 is changed to “Done”, and the reproduction pointer B4 is moved to the next table in S500.
[0062]
Next, in S510, the value of the number of requests waiting for performance is decremented. Thereafter, the process returns to S410 again, and the reproduction of the next request is repeated.
The automatic request acceptance / registration process has been described with reference to FIGS. 9 to 11 and the request reproduction process has been described with reference to FIG. 12. Next, referring to FIG. 13 for the billing aggregation process executed at a predetermined timing, for example, every month. To explain. Note that this process may be executed, for example, at a time when the broadcast center 10 is not executing a broadcast-related process (for example, a time zone such as midnight or early morning).
[0063]
In this billing tabulation process, first, the subscriber number counter is cleared in the first step S610, and the billing song number counter is cleared in the next step S620.
In subsequent S630, a subscriber code is acquired from the subscriber database (FIG. 7). This is sequentially acquired in the order of the subscriber codes registered in the subscriber database.
[0064]
In subsequent S640, it is determined whether or not the value of the subscriber number counter is equal to or greater than the number of registered users in the subscriber database. If the value of the subscriber number counter is equal to or greater than the number of registrants in the subscriber database (S640: YES), this process is terminated. If the value of the subscriber number counter is smaller than the number of registrants in the subscriber database ( S640: NO), the processing of S650 and subsequent steps is executed.
[0065]
In S650, it is determined whether or not the currently referred file is the log file end of the request log storage (FIG. 6). If it is not the log file end, the process proceeds to S660, and one request is stored from the request log storage. Get the log. The log acquisition in S660 is sequentially acquired in the order of logs stored in the request log storage (FIG. 6).
[0066]
In subsequent S670, the subscriber code acquired from the subscriber database in S630 is compared with the subscriber code of the log acquired in S660. If the two subscriber codes match, the process proceeds to S680, but if they do not match, the process returns to S650.
In S680, whether or not the request is a duplicate request is determined based on whether or not the log duplication flag D4 (see FIG. 6) is “1”. If the duplicate flag D4 is “1”, it is a duplicate request, and if the duplicate flag D4 is “0”, it is not a duplicate request.
[0067]
If the request is not a duplicate request (S680: NO), the process proceeds to S690, the chargeable music number counter is incremented, and the process returns to S650. On the other hand, if it is a duplicate request (S680: YES), the process returns to S650 without performing the process of S690.
[0068]
In this way, the log corresponding to the subscriber code acquired in S630 is searched, and if it is not a duplicate request, the counting process for incrementing the billing music number counter is sequentially performed, and an affirmative determination in S650, that is, the log If processing has been completed up to the file end, the process proceeds to S700.
[0069]
In S700, the billing amount is calculated by multiplying the billing song number of the billing song number counter by the unit price for one song. In the subsequent S710, the number of charging songs and the charging amount calculated in S700 are stored as the corresponding subscriber code file in the charging result table of FIG.
[0070]
Now that the storage of the accounting results for one person has been completed, the processing proceeds to accounting / storage processing of the accounting results for the next subscriber. Specifically, after the value of the subscriber number counter is incremented in S720, the process returns to S620. The billing music number counter is cleared in S620, and the next subscriber code is acquired from the subscriber database (FIG. 7) in S630. And the process after S640 is performed.
[0071]
When the totaling / storage of the accounting results for all the subscriber codes stored in the subscriber database (FIG. 7) is completed in this way, an affirmative determination is made in S640, and thus this processing ends. .
The data stored in the accounting result table shown in FIG. 8 is sent to, for example, a financial institution and collected by automatic withdrawal, or printed as an invoice, and the charge collection staff on the administrator side sends the data to the user side. You will go directly and collect.
[0072]
The broadcast center 10 of the present embodiment described above has the basic functions of request response and storage of performance information for billing, and further exhibits the following functions. That is, when the request from the viewer is a duplicate request, as shown in S290 of FIG. 10, a response to the viewer requesting that it is a duplicate request is made as a voice response message. Then, it is stored in the request log storage (FIG. 6), but is not newly registered in the request execution table (FIG. 4).
[0073]
In this way, when the received request is a duplicate request, by not newly registering in the request execution table, it is possible to prevent the broadcasting of karaoke songs corresponding to a request that is less necessary, and to enhance the broadcast content . In other words, in the case of a duplicate request, since a karaoke song corresponding to a request that has already been reserved but has not yet started broadcasting will be broadcast from now on, the karaoke song will be broadcast to the viewer who made the duplicate request. As a result, the request is satisfied. Therefore, if a duplicate request is registered in the request execution table (FIG. 4) as it is, it is a karaoke song desired by the user, but in reality, after a karaoke song according to another person's request has been broadcast, Karaoke will be broadcast according to your request, and the need for viewers who make duplicate requests will be very light.
[0074]
Therefore, by controlling not to broadcast karaoke songs in response to such duplicate requests, the content of broadcasting is enhanced, such as preventing broadcasting of karaoke songs that are less necessary while satisfying the viewer's request. be able to. In particular, when the period for accepting requests is limited, a person who really wanted to make a request because of a less necessary request cannot request it, or the broadcast time of the karaoke song according to the request of that person Slowness hinders enhancement of broadcast contents and improvement of user convenience. Therefore, not broadcasting such a karaoke song that is less necessary leads to enhancement of broadcast contents and improvement of convenience for the user.
[0075]
As can be seen from the processing shown in FIG. 11, when the received request is a duplicate request, the duplicate flag is set to “1” when the request is stored in the request log storage (FIG. 6). . For this reason, in the accounting tabulation process of FIG. 13, if the duplication flag is 1 in S680, the accounting song counter in S690 is not incremented. Therefore, as a result, the duplication request is not subject to calculation of the charge amount.
[0076]
As a result, it is possible to appropriately deal with fee collection. For example, if the charge is simply calculated based on the number of request logs stored in the request log storage (FIG. 6), the actual number of karaoke songs broadcasted differs from the number of requests subject to charge collection. As a result, a part of the broadcasting system provider will be free. Therefore, according to the present embodiment, the number of karaoke songs actually broadcast matches the number of requests subject to charge collection, which is preferable in terms of fair and sound system operation.
[0077]
In addition, a viewer who has made a duplicate request is notified as a voice response message that it is a duplicate request. Therefore, it can be recognized that it is a duplicate request for the viewer. In the case of a duplicate request, if it has been notified beforehand that it is different from the charge for a normal request (for example, it will be free), a voice response message stating that the request is duplicated You can also recognize that.
[0078]
It should be noted that, in accounting of billing results and the like, the results of duplicate requests are not necessary as a result, but such duplicate requests are also stored as logs as the request log storage in FIG. This is because it is preferable for the broadcast center 10 to keep track of the fact that the request itself has been made for various reasons, such as creating a request ranking based on the number of requests.
[0079]
In this embodiment, when a request is made, whether or not it is a duplicate request, the scheduled broadcast start time of the karaoke song according to the request is notified to the viewer as a voice response message. doing. Therefore, the viewer can know in almost real time when the broadcast of the karaoke song requested by the viewer starts. Therefore, it is possible to finish another task before the broadcast of the karaoke song requested by the viewer, for example, and since the viewer does not know when it will start, the wasted time of simply waiting can be eliminated. The convenience of use can be improved.
[0080]
The embodiments of the present invention have been described above according to the specific examples, but the present invention is not limited to such specific examples, and it goes without saying that various implementations can be made without departing from the gist of the invention.
For example, in the above-described embodiment, the number of music pieces to be billed and the billing amount calculated based on the number of billing songs are stored in the billing record table (FIG. 8) as “billing record information”. Only the number of charging songs may be stored, and another charging processing system may execute charging-related processing based on the stored number. Further, only the billing amount may be stored.
[0081]
Further, the calculation of the billing amount has been described on the assumption that the unit price of one song is fixed in the above embodiment. For example, when the new song is high and the old song is set cheaply, the request log is stored. Data for distinguishing them may be stored, and the calculation may be made based on the charges read from the charge table storing the charges in each case.
[0082]
Moreover, although the example used for the broadcast of a karaoke program was demonstrated in the said Example, in this invention, the server side which supplies the information for broadcasting has few, the client side which requests | requires the information for broadcasting is many, and both are remote. For this reason, the main purpose of the application is that it is a situation where an information supply form called broadcasting is adopted. Therefore, there may be a case where only the audio information or the video information is used as the broadcast information.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a schematic configuration of a broadcast center according to an embodiment.
FIG. 2 is an explanatory diagram showing a signal flow centered on a host computer.
FIG. 3 is a data structure diagram of a request database handled by a host computer.
FIG. 4 is a data structure diagram of a request execution table handled by a host computer.
FIG. 5 is a data structure diagram of a request reception buffer handled by a host computer.
FIG. 6 is a data structure diagram of a request log record handled by a host computer.
FIG. 7 is a data structure diagram of a subscriber database handled by a host computer.
FIG. 8 is a data structure diagram of an accounting result table handled by a host computer.
FIG. 9 is a flowchart showing a part of an automatic request acceptance / registration process executed by a host computer.
FIG. 10 is a flowchart showing a part of an automatic request acceptance / registration process executed by a host computer.
FIG. 11 is a flowchart showing a part of an automatic request acceptance / registration process executed by a host computer.
FIG. 12 is a flowchart showing request reproduction processing executed by a host computer.
FIG. 13 is a flowchart showing billing aggregation processing executed by the host computer.
[Explanation of symbols]
10 ... broadcast center 11 ... host computer
11a ... CPU 11b ... CPU memory
12 ... External storage device 13 ... Display device
14 ... Karaoke playback device 16 ... Broadcasting means
20 ... Voice response device 40 ... Public telephone line
50 ... Subscriber telephone

Claims

A request accepting means for receiving a broadcast request made individually from a viewer using a communication line and automatically storing the request in the request accumulating means;
Broadcasting means for sequentially broadcasting the broadcast information corresponding to the broadcast request stored in the request storage means according to a predetermined order;
Charging performance information storage means for storing performance information for charging a predetermined fee corresponding to the broadcast request stored in the request storage means by the broadcast request reception means for each viewer who requested the broadcast. In a broadcast center with a request response function
The broadcast request received by the request accepting means has already been accumulated in the request accumulating means, but the broadcast information corresponding to the broadcast request is the same as the broadcast request that has not yet been started by the broadcast means. In the case of a broadcast request, it is provided with a response means that responds as audio information via the communication line to the viewer side that has transmitted the broadcast request to the effect that the broadcast request is duplicated.
In addition to the fact that the broadcast request is duplicated, the response means relates to a broadcast start schedule of broadcast information corresponding to the broadcast request that has been started the earliest among the broadcast requests that have not already been accumulated and broadcast. The information is also configured to respond,
The request receiving means is configured to not store the duplicate broadcast request in the request storage means when the received broadcast request is the duplicate broadcast request. center.

In the broadcasting center according to claim 1,
In a state where the broadcast request received by the request accepting means is stored in the request accumulating means, and the broadcast request received by the request accumulating means is not distinguished because it is the duplicate broadcast request. A request reception record storage means for storing the request reception record is provided.
The charging record information storage unit stores charging record information corresponding to the request reception record in which the request storage unit stores the broadcast request in the request reception record stored in the request reception record storage unit. A broadcast center characterized by being configured as described above.

In the broadcast center according to claim 1 or 2 ,
A required time storage means for storing the required broadcast time for each broadcast information;
The response means is based on each broadcast required time information of the broadcast information corresponding to the broadcast request stored in the request storage means, and for the broadcast corresponding to the broadcast request stored in the request storage means by the request reception means. A broadcast center characterized by calculating a scheduled required time or scheduled broadcast start time until the start of broadcasting of information and responding with the scheduled required time or scheduled start time as audio information.

In the broadcast center according to any one of claims 1 to 3 ,
The broadcast request from the viewer is a request specifying a karaoke song,
The broadcasting means is a television broadcasting means capable of transmitting audio information and video information, and the broadcasting information broadcast by the broadcasting means is a karaoke performance sound corresponding to the requested karaoke song and a lyrics telop on the background video. A broadcast center characterized in that it includes a synthesized video.