(57)【特許請求の範囲】
【請求項１】
通信回線を使用して視聴者から個別になされた放送要求を受信し、要求蓄積手段にデータとして自動的に蓄積させる要求受付手段と、
前記要求蓄積手段に記憶されている放送要求に応じた放送用情報を、所定の順番に従って順次放送していく放送手段と、
前記放送要求受付手段によって要求蓄積手段に蓄積させた放送要求に対応する所定の料金を課金するための実績情報を、放送要求をした視聴者毎に記憶しておく課金実績情報記憶手段と
を備えたリクエスト応答機能付きの放送センタにおいて、
前記要求受付手段によって受信した放送要求が、既に要求蓄積手段に蓄積されているが、その放送要求に応じた放送用情報の前記放送手段による放送は未だ開始されていない放送要求と同じである重複放送要求である場合には、放送要求が重複している旨を、当該放送要求を送信してきた視聴者側に対し、前記通信回線を介して音声情報として応答する応答手段を備えると共に、
前記応答手段は、前記放送要求が重複している旨に加えて、前記既蓄積・放送未開始の放送要求の内の最も早く放送開始がなされるものに応じた放送用情報の放送開始予定に関する情報も応答するように構成されており、
前記要求受付手段は、前記受信した放送要求が前記重複放送要求である場合には、前記重複した放送要求の前記要求蓄積手段への蓄積を実行しないように構成されていることを特徴とする放送センタ。
【請求項２】
請求項１に記載の放送センタにおいて、
前記要求受付手段によって受信した放送要求を、前記要求蓄積手段へ蓄積させたものと、前記重複放送要求であるため前記要求蓄積手段への蓄積を実行しなかったものとが区別可能な状態で、要求受信実績として記憶しておく要求受信実績記憶手段を備えており、
前記課金実績情報記憶手段には、前記要求受信実績記憶手段に記憶されている要求受信実績の内の、前記要求蓄積手段へ放送要求を蓄積させた要求受信実績に対応する課金実績情報を記憶するように構成されていることを特徴とする放送センタ。
【請求項３】
請求項１または２に記載の放送センタにおいて、
前記放送用情報毎の放送所要時間を記憶する所要時間記憶手段を備え、
前記応答手段は、前記要求蓄積手段に蓄積されている放送要求に対応した放送用情報の各放送所要時間情報に基づき、前記要求受付手段によって要求蓄積手段に蓄積させた放送要求に応じた放送用情報の放送開始までの予定所要時間あるいは放送開始予定時刻を算出し、その予定所要時間あるいは開始予定時刻を音声情報として応答することを特徴とする放送センタ。
【請求項４】
請求項１〜３のいずれかに記載の放送センタにおいて、
前記視聴者からの放送要求は、カラオケ曲を指定した要求であり、
前記放送手段は、音声情報と映像情報が送信可能なテレビジョン放送手段であると共に、当該放送手段が放送する放送用情報は、要求されたカラオケ曲に応じたカラオケ演奏音及び背景映像に歌詞テロップが合成された映像とを含むものであることを特徴とする放送センタ。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、視聴者から個別になされた放送要求に応じた放送用情報を、所定の順番に従って順次放送していくリクエスト応答機能付きの放送センタに係り、特に、そのリクエスト応答に対して所定の料金を課すようなシステムに用いて有効な放送センタに関する。
【０００２】
【従来の技術および発明が解決しようとする課題】
現在、ＣＡＴＶシステム等のローカルなテレビジョン放送センタと加入者端末との間において、双方向テレビジョンと呼ばれるＴＶ放送の新しい形態が普及しつつある。そして、このようなシステムの放送センタは、決められた時刻に決められた情報を流すだけでなく、視聴者から個別になされた放送要求に応じた放送用情報を、所定の順番に従って順次放送していくリクエスト応答機能も備えるようになってきている。例えば、カラオケリクエスト番組と呼ばれるカラオケの放送のみを取り扱う番組時間枠（もしくは設けられた専用のチャンネル）等が採用されており、この番組においては視聴者からのリクエストを電話等を介して受け付け、そのリクエストに応じたカラオケを放送するといったことである。
【０００３】
このようにリクエストに応じたカラオケを放送する場合には、例えば、所定曲数までリクエストを受け付けて予約しておき、その予約リクエストに応じたカラオケを順次放送していくことが考えられる。この場合、リクエスト自体は既に予約されているがそれに応じたカラオケ曲の放送はまだ開始されていないというリクエストが存在する可能性がある。そのような状態で新規にしたリクエストが既に予約されているが放送はまだであるものと同じであった場合に、それもリクエストとして予約してしまうと、同じカラオケ曲が何度も放送されることとなり、放送内容のマンネリ化につながってしまう。
【０００４】
また、リクエストをした利用者としては、自分のリクエストしたものであろうが他人がリクエストしたものであろうが、希望したカラオケ曲が放送されればよいので、他人がリクエストしたカラオケ曲の放送によって既に自分の要求は満たされていることとなる。そのため、その後さらに今度は自分がリクエストしたものに対応するカラオケ曲が放送されても、すでに同じカラオケ曲の放送がされた後なので、リクエストした利用者にとっての必要性は非常に薄くなる。
【０００５】
したがって、リクエスト自体は既に予約されているがそれに応じたカラオケ曲の放送はまだ開始されていないものと同じリクエストがされた場合には、それに対応するカラオケ曲を放送するための予約データとしては登録しないようにすることが、放送内容の充実等から好ましい。
【０００６】
一方、このようにリクエストに応じた情報を放送する場合にそのリクエスト応答に対して所定の料金を課そうとする場合には、いわゆる定量制の料金制度ではなく、従量制の料金制度を導入する必要性が出て来る。つまり、リクエストした利用者が、その料金を負担する（支払う）のである。
【０００７】
しかしながら、この場合の料金徴収については、単純にリクエストをした回数だけに基づいて料金を計算すると不都合が生じる場合がある。上述したように、放送内容のマンネリ化防止の点等から、リクエストしたものが放送するカラオケ曲の予約データとして登録しないこともあるからである。そして、このような場合も含む状態で、単純にリクエストをした回数だけに基づいて料金を計算してしまうと、放送曲数と料金徴収対象となったリクエスト数とが異なってしまい、放送システム側が一部タダ取りしてしまうような状況となる。
【０００８】
なお、テレビジョン放送に限らずラジオ放送あるいはその他の放送に関しても同様の課題が考えられる。
本発明は、基本的には視聴者からのリクエストに応じた放送用情報を放送し、リクエストに対応する所定の料金を課金するための実績情報をリクエストした視聴者毎に記憶しておく機能を備えながら、さらに重複したリクエストがあった場合には、放送内容の充実や利用者の便宜の向上を図る上で適切な対応が可能な放送センタを提供することを目的とする。
【０００９】
【課題を解決するための手段及び発明の効果】
この目的を達成するためになされた請求項１記載の発明は、通信回線を使用して視聴者から個別になされた放送要求を受信し、要求蓄積手段にデータとして自動的に蓄積させる要求受付手段と、前記要求蓄積手段に記憶されている放送要求に応じた放送用情報を、所定の順番に従って順次放送していく放送手段と、前記放送要求受付手段によって要求蓄積手段に蓄積させた放送要求に対応する所定の料金を課金するための実績情報を、放送要求をした視聴者毎に記憶しておく課金実績情報記憶手段とを備えたリクエスト応答機能付きの放送センタにおいて、前記要求受付手段によって受信した放送要求が、既に要求蓄積手段に蓄積されているが、その放送要求に応じた放送用情報の前記放送手段による放送は未だ開始されていない放送要求と同じである重複放送要求である場合には、放送要求が重複している旨を、当該放送要求を送信してきた視聴者側に対し、前記通信回線を介して音声情報として応答する応答手段を備えると共に、前記応答手段は、前記放送要求が重複している旨に加えて、前記既蓄積・放送未開始の放送要求の内の最も早く放送開始がなされるものに応じた放送用情報の放送開始予定に関する情報も応答するように構成されており、  前記要求受付手段は、前記受信した放送要求が前記重複放送要求である場合には、前記重複した放送要求の前記要求蓄積手段への蓄積を実行しないように構成されていることを特徴とする放送センタである。
【００１０】
上記構成を有する本発明の放送センタは、要求受付手段が、通信回線を使用して視聴者から個別になされた放送要求を受信し、要求蓄積手段にデータとして自動的に蓄積させる。そして、放送手段が、要求蓄積手段に記憶されている放送要求に応じた放送用情報を、所定の順番に従って順次放送していくというリクエスト応答機能を備えている。
【００１１】
また、課金実績情報記憶手段には、放送要求受付手段によって要求蓄積手段に蓄積させた放送要求に対応する所定の料金を課金するための実績情報を、放送要求をした視聴者毎に記憶しておくことができる。この実績情報に基づいて別途所定の課金や料金徴収が実行される。例えば、金融機関からの自動引き落しや管理者側の料金回収スタッフが利用者側に直接出向いて徴収したりすることとなる。
【００１２】
このように、リクエスト応答と課金のための実績情報の記憶という基本的な機能を備えていると共に、さらに次のような機能を発揮する。すなわち、要求受付手段によって受信した放送要求が、既に要求蓄積手段に蓄積されているが、その放送要求に応じた放送用情報の前記放送手段による放送は未だ開始されていない放送要求と同じである重複放送要求である場合には、放送要求が重複している旨を、当該放送要求を送信してきた視聴者側に対し、通信回線を介して音声情報として応答する。そして、さらに、要求受付手段は、受信した放送要求が重複放送要求である場合には、その重複した放送要求の要求蓄積手段への蓄積を実行しないのである。
【００１３】
このように、受信した放送要求が重複放送要求である場合にその重複した放送要求の要求蓄積手段への蓄積を実行しないことによって、必要性の薄い放送用情報が放送されることが防止され、放送内容の充実につながる。つまり、重複放送要求の場合には、既に蓄積されているが放送はまだ開始されていない放送要求に応じた放送用情報がこれから放送されるので、重複した放送要求を行った視聴者にとっては、その放送用情報によって要求が満たされることとなる。そのため、仮に重複した放送要求もそのまま蓄積させてしまうと、自分のした放送要求に応じた放送用情報が放送された後でさらに同じ放送用情報が放送されることとなり、放送要求をした視聴者にとっての必要性は非常に薄くなる。
【００１４】
したがって、このような重複放送要求に応じた放送用情報は放送しないように制御することで、視聴者の要求を満足させながら、必要性の薄い放送用情報の放送を防止する等、放送内容の充実を図ることができる。特に、放送要求を受け付ける期間が限られている場合に、必要性の薄い放送要求のために真に放送要求をしたかった人が要求できなかったり、あるいは放送時刻が遅くなったりすることは放送内容の充実や利用者の便宜の向上を阻害するものである。したがって、そのような必要性の薄い放送用情報を放送しないようにすることが、放送内容の充実や利用者の便宜の向上につながるのである。
【００１５】
また、受信した放送要求が重複放送要求である場合に、その重複した放送要求の要求蓄積手段への蓄積を実行しないことによって、課金実績情報記憶手段には、課金するための実績情報が記憶されない。つまり、自分のした放送要求そのものに対応した放送用情報の放送はなされていないので、それについては課金実績情報として記憶しないのである。
【００１６】
これによって、料金徴収についても適切な対処が可能となる。例えば単純に放送要求の実績（例えば回数）だけに基づいて料金を計算してしまうと、実際に放送した放送用情報数と料金徴収対象となった放送要求数とが異なってしまい、放送システム事業者側が一部タダ取りしてしまうような状況となる。そこで本発明のようにすれば、実際に放送した放送用情報数と料金徴収対象となった放送要求数とが一致し、公正・健全なシステム運営の点で好ましい。
【００１７】
なお、重複放送要求をした視聴者には、放送要求が重複している旨が通信回線を介して音声情報として応答される。そのため、視聴者にとっては重複した放送要求であることが認識できる。そして、重複放送要求の場合には通常の放送要求をした場合の料金とは異なる（例えば無料になる）ことが予め通知されているのであれば、この放送要求が重複している旨の音声応答により、そのことも認識できる。そして、放送要求が重複している旨を視聴者に応答する応答手段は、さらに、放送要求が重複している旨に加えて、既蓄積・放送未開始の放送要求の内の最も早く放送開始がなされるものに応じた放送用情報の放送開始予定に関する情報も応答する。
【００１８】
また、請求項２に記載の発明は、請求項１に記載の放送センタにおいて、前記要求受付手段によって受信した放送要求を、前記要求蓄積手段へ蓄積させたものと、前記重複放送要求であるため前記要求蓄積手段への蓄積を実行しなかったものとが区別可能な状態で、要求受信実績として記憶しておく要求受信実績記憶手段を備えており、前記課金実績情報記憶手段には、前記要求受信実績記憶手段に記憶されている要求受信実績の内の、前記要求蓄積手段へ放送要求を蓄積させた要求受信実績に対応する課金実績情報を記憶するように構成されていることを特徴とする。
【００１９】
上述したように、一定の条件で放送要求が重複した場合には、その放送要求は要求蓄積手段への蓄積が実行されない。しかし、放送センタとしては、放送要求の数に基づいて例えばリクエストランキングを作成する等、種々の理由によって放送要求自体がされたことの実績は残しておくことが好ましい。したがって、この請求項２に示すようにすれば、受信した放送要求を、要求蓄積手段へ蓄積させたものと、重複放送要求であるため要求蓄積手段への蓄積を実行しなかったものとが区別可能な状態で要求受信実績として記憶しておくことができる。そして、この場合、課金実績情報記憶手段には、記憶されている要求受信実績の内の、要求蓄積手段へ放送要求を蓄積させた要求受信実績に対応する課金実績情報を記憶するので、請求項１と同様の効果を発揮する。
【００２０】
上述のように、本発明の放送センタの応答手段は、放送要求が重複している旨に加えて、既蓄積・放送未開始の放送要求の内の最も早く放送開始がなされるものに応じた放送用情報の放送開始予定に関する情報も応答する。
【００２１】
この場合、請求項３に示すように、放送用情報毎の放送所要時間を記憶する所要時間記憶手段を備え、応答手段は、要求蓄積手段に蓄積されている放送要求に対応した放送用情報の各放送所要時間情報に基づき、要求受付手段によって要求蓄積手段に蓄積させた放送要求に応じた放送用情報の放送開始までの予定所要時間あるいは放送開始予定時刻を算出し、その予定所要時間あるいは開始予定時刻を音声情報として応答することが考えられる。
【００２２】
このようにすれば、視聴者は自分の要求した放送用情報の放送開始までにかかる時間あるいは演奏開始時刻など、放送開始予定に関する情報をほぼリアルタイムで知ることができる。そのため、自分の要求した放送用情報の放送開始までに例えば別の用事を済ませるといったこともでき、いつ始まるか判らないので単に待っているだけという無駄な時間をなくすことができるというように、視聴者の利用の便宜を向上させることができる。
【００２３】
また、このような放送センタから放送する放送用情報としては、例えばカラオケ用の情報が考えられる。この場合、請求項４に示すように、放送手段は、音声情報と映像情報が送信可能なテレビジョン放送手段であると共に、放送手段が放送する放送用情報は、要求されたカラオケ曲に応じたカラオケ演奏音及び背景映像に歌詞テロップが合成された映像とを含むようにすることが考えられる。
【００２４】
もちろん、放送用情報としてカラオケ演奏音だけを放送してもカラオケとしては成立するが、現在のカラオケには、もはや背景映像に歌詞テロップを合成した映像をカラオケ演奏に併せて表示させるということが常識化されつつあるので、カラオケ演奏音及び背景映像に歌詞テロップが合成された映像とを含む放送用情報を放送することが好ましいと言える。この場合、いわゆるＣＡＴＶのように有線で放送センタと加入者端末を接続してもよいし、通常の放送システムのように無線のままでもよい。さらには、音声情報だけあるいは映像情報だけという場合も考えられる。
【００２５】
なお、要求受付手段は、視聴者からの放送要求を受け付ける際、所定のガイダンス用音声情報を視聴者側に送信し、そのガイダンス用音声情報に対する返答として放送要求を受信するようにしてもよい。こうすれば、視聴者はそのガイダンス用音声情報に従って操作するだけでよく、より視聴者の便宜が向上する。例えば、実際には視聴者の識別情報等も送信する必要があるので、ガイダンスがあると便利である。
【００２６】
また、要求受付手段が放送要求を受信するために使用する通信回線としては、電話回線でもよいし、ＣＡＴＶの同軸ケーブルを介して双方向全２重通信が実現されるのであれば、その同軸ケーブルでもよい。電話回線の場合には、例えば電話機のプッシュボタン等でリクエスト番号等を入力し、それをダイヤルトーンを使用したコードとして送信するようにし、要求受付手段がそれを受信するようにすればよい。
【００２７】
【発明の実施の形態】
以下、本発明の放送センタを具体化した一実施例を図面を参照しながら説明する。
図１は、本実施例の放送センタ１０の概略構成を示すブロック図である。図１に示すように、放送センタ１０は、制御手段及び「応答手段」としてのホストコンピュータ１１と、「課金実績情報記憶手段」及び「要求受信実績記憶手段」としての外部記憶装置１２と、表示手段としての表示装置１３と、カラオケ再生装置１４と、「放送手段」としての放送手段１６と、「要求受付手段」としての音声応答装置２０とを備えている。また、放送センタ１０は、公衆電話回線４０を介して多数の加入者電話機５０と接続されている。
【００２８】
各構成装置について、放送センタ１０における役割あるいは放送システム全体との関わりも含めて説明する。
音声応答装置２０は視聴者からの放送要求を受け付け、その放送が所定の「重複放送要求」である場合にはその旨、そして放送要求に応じた放送用情報の放送開始予定に関する情報を音声情報として応答するためのものである。なお、重複放送要求については後述する。
【００２９】
まず、放送要求の受け付けに関して詳細に説明する。
本放送センタ１０は、視聴者から個別になされた放送要求を蓄積しておき、その放送要求に応じた放送用情報（本実施例の場合にはカラオケ用の情報）を順次放送していくリクエスト応答機能を備えているのであるが、視聴者は自宅にあるところのケーブルテレビによって本放送センタ１０に接続されたテレビジョン受信機（図示せず）を視聴しながら、手持ちの加入者電話機５０により一般の公衆電話回線４０を通して、希望するカラオケ用情報の放送を要求する。この放送要求は、予め定められた「リクエストコード」によって行う。これは、カラオケ視聴の提供に限り、一般のカラオケ装置における「曲番号」と同義のものである。数字コードによるリクエストであるため、実際には視聴者が加入者電話機５０のダイヤルもしくはプッシュホンの押し下げにより上記リクエストコードをトーン発信する。このリクエストコードはあらかじめ視聴者に配布物等によって通知されているものとする。
【００３０】
この視聴者からの通話は放送センタ１０において音声応答装置２０により自動的に受理される。音声応答装置２０は内蔵された合成音声手段（図示せず）により予め登録されたメッセージを送出し、視聴者にリクエストコードの入力と、そのガイダンスを促すものであり、ホストコンピュータ１１により制御され、上記した通話の受話、メッセージの送話からパルスコードの受信までを行う。
【００３１】
音声応答装置２０によって受理されたリクエストコードは、ホストコンピュータ１１により、そのコードが有効であるかどうか、外部記憶装置１２上のデータベースとの照合により判断され、有効であればホストコンピュータ１１内のＣＰＵメモリ１１ｂ（図２参照）に蓄積される。なお、このＣＰＵメモリ１１ｂが「要求蓄積手段」及び「所要時間記憶手段」に相当する。
【００３２】
ホストコンピュータ１１は、リクエストを受け付けた場合には、その旨を通知するためのメッセージを音声情報として作成する。そして、音声応答装置２０から公衆電話回線４０を介して放送要求をしてきた視聴者側の加入者電話機５０に応答するのである。
【００３３】
また、蓄積されたリクエストコードは、ホストコンピュータ１１によって制御されるカラオケ再生装置１４に渡され、映像の再生がなされる。
なお、本実施例のカラオケ再生装置１４は、カラオケ演奏音を再生すると共に、歌詞テロップの合成された背景映像も再生できるものである。したがって、放送手段１６は、テレビジョン放送手段である。なお、発明の主旨を考えると映像がなくても構わないので、カラオケ再生装置１４はカラオケ演奏音だけを再生するものとし、放送手段１６がいわゆるラジオ放送手段であっても構わない。もちろん、カラオケ以外に適用した場合には、逆に映像だけということも考えられる。
【００３４】
放送手段１６によって放送された放送内容は、視聴者側のテレビジョン受信機などの受信設備にて受信され、カラオケ番組として視聴可能である。なお、放送センタ１０と視聴者側の受信設備はＣＡＴＶシステムのように有線で接続されていてもよいし、通常の放送システムのように無線でもよい。
【００３５】
表示装置１３はホストコンピュータ１１に接続されており、これらの状況を表示することができる。これは、放送センタ１０のオペレータが確認するために利用される。
続いて、図２を参照して、ホストコンピュータ１１を中心とした信号の流れを説明する。
【００３６】
図２に示すように、音声応答装置２０はホストコンピュータ１１のＣＰＵ１１ａと制御信号によって結ばれている。ＣＰＵ１１ａは音声応答装置２０に対して公衆電話回線４０（図１参照）の着信待ちに関する制御、着信後の同装置２０内の音声メッセージの送話に関する制御（複数のメッセージの内の選択）を行う。音声応答装置２０はホストコンピュータ１１に対して公衆電話回線４０を通じて受信したダイヤルパルスを数値情報として返す。これにより、公衆電話回線４０による視聴者からの要求の自動受理を行うものである。音声応答装置２０より返された数値はＣＰＵメモリ１１ｂに格納される。
【００３７】
外部記憶装置１２は、リクエストコードに関するデータベースあるいは課金実績テーブルが格納されたホストコンピュータ１１の外部記憶であり、装置間でデータの読み書きが行われる。これにより、ＣＰＵ１１ａはリクエストコードの検索・照合と、ログ記録を行うものである。
【００３８】
カラオケ再生装置１４はＣＰＵ１１ａと制御信号により結ばれている。ＣＰＵ１１ａはリクエストコード（曲番号）を送信し、同装置１４にカラオケ楽曲の再生を行わせ、またこの再生の開始・終了などの制御を行うことができる。また、カラオケ再生装置１４は、ＣＰＵ１１ａに対して再生の状況（再生中・再生終了等）を返す。これにより、ＣＰＵ１１ａはリクエストコードによるカラオケ楽曲の再生を行うことができる。
【００３９】
次に、本実施例の放送センタ１０の動作について、図を参照して説明する。
図９〜図１３はＣＰＵ１１ａによって実行されるプログラムの処理手順を示すフローチャートであり、図３〜図８はこのプログラムが取り扱うデータ構造図である。以下、処理フローの詳細を説明する。なお、図９〜図１１は、リクエスト自動受理・登録処理のフローチャート、図１２は、リクエスト再生処理のフローチャートであり、これらの処理はそれぞれ同時に独立して動作するいわゆるマルチタスク処理である。また、図１３は、所定のタイミング、例えば１か月毎に実行される課金集計処理のフローチャートである。
【００４０】
まず、リクエスト自動受理・登録処理（図９〜図１１）について説明する。
本処理は、加入者側からの公衆電話回線４０によるリクエストの自動受理と、そのリクエストのＣＰＵメモリ１１ｂへの登録手順を示す。なお、この加入者とは単にこの放送センタ１０からの放送を受信できるという意味ではなく、リクエストする権利を有しているものという意味である。例えばＣＡＴＶシステムで、そのシステムに加入する際に自動的にリクエストの権利も与えられる場合には、全てが加入者となる。なお、通常の無線形式で放送する場合には、例えばリクエストをする代わりに所定の料金を徴収するような契約を別個に行なうことが考えられる。その場合には、契約をした人だけが加入者となる。
【００４１】
まず、図９の最初のステップＳ１００において、音声応答装置２０を公衆電話回線４０を介しての着信が可能な状態に制御し、続くＳ１１０にて、加入者電話機５０からの着信があるまで待機する。そして、着信があれば（Ｓ１１０：ＹＥＳ）、Ｓ１２０へ移行する。
【００４２】
Ｓ１２０では、音声応答装置２０より音声応答メッセージ（例えば「加入者番号を入力してください」）を送出し、最初に行ってもらう加入者番号の入力を促す。その後、Ｓ１３０にて、加入者電話機５０よりのダイヤルパルスの発信を待つ。入力された番号は、Ｓ１４０にて、ＣＰＵメモリ１１ｂ上のリクエスト受付バッファ（図５参照）の加入者コードの領域Ｃ３に格納していく。これを５桁の加入者番号が全て入力されるまで繰り返す（Ｓ１５０）。
【００４３】
５桁の加入者番号が入力されると（Ｓ１５０：ＹＥＳ）、Ｓ１６０へ移行して、その加入者番号が有効であるかどうかの照合を行なう。これは、外部記憶装置１２上の加入者データベース（図７）を照会して行なう。
この照合の結果、有効な番号でないと判断されれば（Ｓ１７０：ＮＯ）、入力のやり直しを求める音声メッセージ（例えば「加入者番号を再入力してください」）を再生し（Ｓ１８０）、Ｓ１３０へ戻る。
【００４４】
最初に入力された加入者番号が有効である場合、あるいは再度入力された加入者番号が有効であれば（Ｓ１７０：ＹＥＳ）、Ｓ１９０（図１０参照）に移行する。Ｓ１９０では、音声応答メッセージを送出し、リクエストコードの入力を促す。続くＳ２００〜２２０では、ダイヤルパルスの発信を待ち、入力された番号をリクエスト受付バッファ（図５）のリクエストコードの領域Ｃ２に格納していき、これを５桁のリクエストコードがすべて入力されるまで繰り返す。
【００４５】
５桁のリクエストコードが入力されると（Ｓ２２０：ＹＥＳ）、そのリクエストコードの照合を行なう。これは、外部記憶装置１２上のリクエストデータベース（図３）を照会して実行する。そして、Ｓ１４０で有効な番号であるかどうかを判断する。有効な番号でないと判断されれば（Ｓ２４０：ＮＯ）、Ｓ２５０へ移行して、入力のやり直しを求める音声メッセージ（例えば「リクエストコードを再入力してください」）を再生し、Ｓ２００へ戻る。
【００４６】
最初に入力されたリクエストコードが有効である場合、あるいは再度入力されたリクエストコードが有効であれば（Ｓ２４０：ＹＥＳ）、Ｓ２６０の処理に移行する。
Ｓ２６０では、ＣＰＵメモリ１１ｂ上のリクエスト実行テーブル（図４）のリクエストコード領域Ｂ２の内の、再生フラグＢ１が「未」となっているものの中に、同一のリクエストコードがないかどうかを判断する。ここで、リクエスト実行テーブルについて説明しておく。このリクエスト実行テーブルは、図４に示すように、再生フラグＢ１、リクエストコードＢ２、演奏開始予定時刻Ｂ３の３つの項目からなっている。
【００４７】
後述するＳ３１０の処理（図１１参照）において、新規登録をするとの判断がなされた場合には、Ｓ３３０において、リクエスト受付バッファ（図５）の内容をリクエスト実行テーブル（図４）内の受付ポインタＢ５の示しているリクエストコード領域Ｂ２に追加登録する。この追加登録は、リクエストコードＣ２を受付ポインタＢ５の示すリクエストコード領域Ｂ２にコピーし、再生フラグＢ１を「未」とすることにより行われる。なお、初期状態では再生フラグＢ１にはすべて「無」が、リクエストコードＢ２には不定値が入っているものとする。また、演奏開始予定時刻Ｂ３は、一つ前のリクエストコードＢ２を登録した場合に、その曲の再生時間を加算することによって、次に新規登録された場合の演奏開始予定時刻Ｂ３が決定する。新規登録が終了すると受付ポインタＢ５がリクエスト実行テーブル（図４）上の次の領域に進められるため、その領域の演奏開始予定時刻Ｂ３の欄に、上述した「次に新規登録された場合の演奏開始予定時刻」が書き込まれることとなる。
【００４８】
図９に戻り、Ｓ２６０では、このリクエスト実行テーブル（図４）のリクエストコード領域Ｂ２の内の、再生フラグＢ１が「未」となっているものの中に、同一のリクエストコードがないかどうかを判断するのである。そして、既に登録されていれば（Ｓ２６０：ＹＥＳ）、Ｓ２７０へ移行して、その登録済みの演奏開始予定時刻を取り出す。例えば、新規に受け付けたリクエストコードが「０１３０１」であった場合には、同じものが既に登録されているので、これは「重複リクエスト」であり、その登録済みのリクエストコードに対応する演奏開始予定時刻である「１２時３０分」を取り出すこととなる。
【００４９】
一方、登録されていなければ（Ｓ２６０：ＮＯ）、Ｓ２８０へ移行して、新規登録の場合の演奏開始予定時刻を取り出す。これは、受付ポインタＢ５の示す領域のものであり、図４に示す場合では、「１２時３９分」となる。
そして、Ｓ２７０において登録済みの演奏開始予定時刻を取り出した場合には、Ｓ２９０において重複リクエスト用の音声応答メッセージを送出する。これは、上記登録済みの演奏開始予定時刻を重複リクエストである旨とセットで視聴者側に知らせるための音声応答メッセージである。例えば「同じリクエストがすでに受け付けられおり、重複リクエストです。その○○は、今から××番目の曲として、◇◇時□□分頃に放送されます。」といったような内容である。
【００５０】
一方、Ｓ２８０において新規登録の場合の演奏開始予定時刻を取り出した場合には、Ｓ２９５にて新規リクエスト用の音声応答メッセージを送出する。これは、上記新規登録の場合の演奏開始予定時刻をリクエストの受付が完了した旨とセットで視聴者側に知らせるための音声応答メッセージである。例えば「リクエストを受け付けました。あなたのリクエストされた○○は、今から××番目の曲として、◇◇時□□分頃に放送されます。」といったような内容である。
【００５１】
これにより、リクエストした視聴者は、まず、新規のリクエストであるか重複リクエストであるかが判ると共に、いずれの場合であっても、即座に自分のリクエストした曲あるいはリクエストしたものと同じ曲の放送時刻（演奏開始時刻）が判る。
【００５２】
Ｓ２９０あるいはＳ２９５処理の後は、Ｓ３００へ移行して回線を切断する。そして、Ｓ３００での回線切断処理が終了すると、Ｓ３１０（図１１参照）に移行する。
Ｓ３１０では、新規登録をするかどうか判断する。このＳ３１０での新規登録をするかしないかの判断は、上述したＳ２６０での判断で、既に登録されていた場合には新規登録をしないと判断し、登録されていない場合には新規登録すると判断する。
【００５３】
新規登録をする場合にはＳ３２０以降の処理を実行する。つまり、Ｓ３２０においては、受け付けた日時をタイムスタンプとしてリクエスト受付バッファ（図５）の受付時刻の領域Ｃ１に書き込む。ここまでの処理が終了すれば、図５に示すリクエスト受付バッファ上には受付時刻Ｃ１、有効なリクエストコードＣ２及び有効な加入者コードＣ３の３要素が揃い、実際のリクエストの受付が可能になるので、続くＳ３３０では、このリクエスト受付バッファ（図５）の内容をリクエスト実行テーブル（図４）内の受付ポインタＢ５の示しているリクエストコード領域Ｂ２に新規登録する。この新規登録は、リクエスト受付バッファ（図５）リクエストコードＣ２を受付ポインタの示すリクエストコード領域Ｂ２にコピーし、再生フラグＢ１を「未」とすることにより行われることは上述した。
【００５４】
Ｓ３３０での新規登録の処理終了後、Ｓ３４０へ移行する。Ｓ３４０では、受付ポインタＢ５をリクエスト実行テーブル（図４）上の次の領域に進める。この動作が、後述するリクエスト再生処理（図１１）の動作に反映する。
さらに、続くＳ３５０では、受け付けたリクエストをログ記録として保持するために、外部記憶装置１２のリクエストログ記録（図６）における受付時刻領域Ｄ１、リクエストコード領域Ｄ２、加入者コード領域Ｄ３（このＤ１〜Ｄ３は、図５のリクエスト受付バッファと同様の要素を持つ。）にそれぞれの要素をコピーする。そして、さらにこの場合は、新規リクエストであるので、重複フラグ領域Ｄ４に「０」をセットする。この重複フラグについては後で詳細に説明する。
【００５５】
次に、Ｓ３６０において、演奏待ちリクエスト数の値をインクリメントし、Ｓ３７０では、リクエスト受付バッファ（図５）のリクエストコードＣ２を基に検索したリクエストデータベース（図３）の要素である再生時間Ａ３の値を、図４のリクエスト実行テーブルの演奏開始予定時刻の最新のもの（受付ポインタＢ５の示す一つ前の領域に書き込まれているもの）に加算する。これにより、次にリクエストがされた場合の演奏開始予定時刻が算出され、この時刻を受付ポインタＢ５の示す演奏開始予定時刻領域Ｂ３に書き込む。
【００５６】
なお、この後は、再び着信待ち状態（Ｓ１００）に戻り、以降の処理を繰り返す。
一方、新規登録をしない場合には（Ｓ３１０：ＮＯ）、Ｓ３８０の処理を実行してからＳ１００へ戻ることとなる。Ｓ３８０では、受け付けたリクエストをログ記録として保持するために、上述したＳ３５０と同様に、外部記憶装置１２のリクエストログ記録（図６）における受付時刻領域Ｄ１、リクエストコード領域Ｄ２、加入者コード領域Ｄ３にそれぞれの要素をコピーする。そして、この場合には重複リクエストであるので、Ｓ３５０とは異なり、重複フラグ領域Ｄ４に「１」をセットする。
【００５７】
ここで、重複フラグについて補足説明する。上記Ｓ３５０あるいはＳ３８０によって、重複しない新規のリクエストであれば重複フラグとして「０」がセットされ、重複リクエストの場合には「１」がセットされる。新規リクエストであろうが重複リクエストであろうが視聴者からのリクエストがされたことにはかわりないので、リクエストがされたこと自体をログとして残しておくために、いずれの場合にもリクエストログ記録（図６）に記録する。しかし、後述する課金集計処理（図１３）において、新規リクエストの場合と重複リクエストの場合の区別なく単にリクエストがなされた事実だけに基づいて集計してしまうと、不都合があるため、これらの区別を付けるために重複フラグを設けたのである。
【００５８】
なお、上記不都合とは例えば次のようにことである。例えば、単にリクエストがされた実績だけに基づいて料金を計算してしまうと、実際に放送したカラオケ曲数と料金徴収対象となったリクエスト数とが異なってしまい、放送システム事業者側が一部タダ取りしてしまうような状況となることである。そこで本実施例の放送センタ１０においては、実際に放送したカラオケ曲数と料金徴収対象となったリクエスト数とが一致するために、重複フラグとして、重複したリクエストであるかどうかを区別する情報を設定しておき、適切な課金処理に利用しようとしているのである。
【００５９】
次に、リクエスト再生処理（図１２）について説明する。
本処理は、ＣＰＵメモリ１１ｂ上のリクエスト実行テーブル（図４）に登録されたリクエストコードの再生の手順を示す。
まず、最初のステップＳ４１０において、リクエスト実行テーブル（図４）内の再生ポインタＢ４が示す領域より、再生フラグＢ１を取り出す。再生フラグＢ１が「未」でなければ（Ｓ４２０：ＮＯ）、リクエスト実行テーブル（図４）の登録内容の再生がすべて済んでいる、若しくは登録内容が空であるため、そのままリクエスト自動受理・登録処理（図９〜図１１）によるリクエストの追加登録待ちに入る（Ｓ４３０）。
【００６０】
一方、再生フラグＢ１が「未」であれば、Ｓ４４０へ移行し、リクエストコードＢ２を取り出す。そして、Ｓ４５０にて、同リクエストコードＢ２をカラオケ再生装置１４に渡し、再生の指示を出す。さらに、Ｓ４６０にて、再生フラグＢ１を「中」に変え、続くＳ４７０にて、カラオケ再生装置１４の再生状態のチェックを行う。
【００６１】
再生の終了がカラオケ再生装置１４より指示されるまでこれを繰り返す（Ｓ４８０：ＮＯ）。そして、再生が終了すると（Ｓ４８０：ＹＥＳ）、Ｓ４９０へ移行して再生フラグＢ１を「済」に変え、Ｓ５００にて、再生ポインタＢ４を次のテーブルに移動する。
【００６２】
次に、Ｓ５１０において、演奏待ちリクエスト数の値をデクリメントする。なお、この後は、再びＳ４１０に戻り、次のリクエストの再生を繰り返す。
以上、図９〜図１１でリクエスト自動受理・登録処理、図１２でリクエスト再生処理について説明したが、次に、所定のタイミング、例えば１か月毎に実行される課金集計処理について図１３を参照して説明する。なお、この処理は、例えば放送センタ１０が放送関連処理を実行していない時期（例えば深夜や早朝といった時間帯）に実行すればよい。
【００６３】
本課金集計処理においては、まず、最初のステップＳ６１０において加入者数カウンタをクリアし、次のステップＳ６２０において、課金曲数カウンタをクリアする。
そして、続くＳ６３０では、加入者データベース（図７）より加入者コードを取得する。これは、加入者データベースに登録されている加入者コードの順番に順次取得してくる。
【００６４】
続くＳ６４０では、加入者数カウンタの値が加入者データベースの登録者数以上であるかどうかを判断する。加入者数カウンタの値が加入者データベースの登録者数以上であれば（Ｓ６４０：ＹＥＳ）、そのまま本処理を終了するが、加入者数カウンタの値が加入者データベースの登録者数より小さければ（Ｓ６４０：ＮＯ）、Ｓ６５０以下の処理を実行する。
【００６５】
Ｓ６５０では、現在参照しているファイルがリクエストログ記憶（図６）のログファイルエンドになっているかどうかを判断し、ログファイルエンドでなければ、Ｓ６６０へ移行して、リクエストログ記憶より１リクエスト分のログを取得する。なお、このＳ６６０でのログ取得は、リクエストログ記憶（図６）に記憶されているログの順番に順次取得してくる。
【００６６】
続くＳ６７０においては、Ｓ６３０で加入者データベ−スから取得した加入者コードと、Ｓ６６０で取得したログの加入者コードとを比較する。そして２つの加入者コードが一致していれば、Ｓ６８０へ移行するが、一致していなければＳ６５０へ戻る。
Ｓ６８０では、ログの重複フラグＤ４（図６参照）が「１」であるかどうかによって重複リクエストであるかどうかを判断する。重複フラグＤ４が「１」であれば重複リクエストであり、重複フラグＤ４が「０」であれば重複リクエストではない。
【００６７】
そして、重複リクエストでなければ（Ｓ６８０：ＮＯ）、Ｓ６９０へ移行して課金曲数カウンタをインクリメントしてから、Ｓ６５０へ戻る。一方、重複リクエストである場合には（Ｓ６８０：ＹＥＳ）、Ｓ６９０の処理を行なうことなくＳ６５０へ戻る。
【００６８】
このようにしてＳ６３０で取得した加入者コードに対応するログを検索して、重複リクエストでなければ課金曲数カウンタをインクリメントしていく集計処理を順次を行っていき、Ｓ６５０で肯定判断、つまりログファイルエンドまで処理した場合にはＳ７００へ移行する。
【００６９】
Ｓ７００では、課金曲数カウンタの課金曲数に、１曲についての単価を乗算して課金金額を算出する。そして、続くＳ７１０では、図８の課金実績テーブルの該当する加入者コードのファイルとして、課金曲数とＳ７００で算出した課金金額を記憶する。
【００７０】
これで、１人分の課金実績の記憶が終了したので、次の加入者に対する課金実績の集計・記憶処理に移行する。具体的には、続くＳ７２０で加入者数カウンタの値をインクリメントしてから、Ｓ６２０へ戻る。Ｓ６２０で課金曲数カウンタをクリアし、Ｓ６３０で次の加入者コードを加入者データベース（図７）から取得する。そして、Ｓ６４０以降の処理を行なう。
【００７１】
このようにして加入者データベース（図７）に記憶されている全ての加入者コードに対しての課金実績の集計・記憶が終了すると、Ｓ６４０で肯定判断となるため、これで本処理を終了する。
なお、この図８に示す課金実績テーブルに記憶されたデータが例えば金融機関に送られて自動引き落しで徴収されたり、あるいは請求書として印刷され、管理者側の料金回収スタッフが利用者側に直接出向いて徴収したりすることとなる。
【００７２】
以上説明した本実施例の放送センタ１０によれば、リクエスト応答と課金のための実績情報の記憶という基本的な機能を備えていると共に、さらに次のような機能を発揮する。すなわち、視聴者からのリクエストが重複リクエストである場合には、図１０のＳ２９０に示すように、重複リクエストである旨をリクエストしてきた視聴者側に対し音声応答メッセージとして応答する。そして、リクエストログ記憶（図６）には記憶するが、リクエスト実行テーブル（図４）には新規登録をしない。
【００７３】
このように、受信したリクエストが重複リクエストである場合にリクエスト実行テーブルに新規登録をしないことによって、必要性の薄いリクエストに応じたカラオケ曲が放送されることが防止され、放送内容の充実につながる。つまり、重複リクエストの場合には、既に予約されているが放送はまだ開始されていないリクエストに応じたカラオケ曲がこれから放送されるので、重複リクエストを行った視聴者にとっては、そのカラオケ曲が放送されることよって要求が満たされることとなる。そのため、仮に重複したリクエストもそのままリクエスト実行テーブル（図４）に登録させてしまうと、自分の希望するカラオケ曲であるが、実際は他人のリクエストに応じたカラオケ曲が放送された後で、さらに今度は自分のリクエストに応じたカラオケ曲が放送されることとなり、重複リクエストをした視聴者にとっての必要性は非常に薄くなる。
【００７４】
したがって、このような重複リクエストに応じたカラオケ曲は放送しないように制御することで、視聴者の要求を満足させながら、必要性の薄いカラオケ曲の放送を防止する等、放送内容の充実を図ることができる。特に、リクエストを受け付ける期間が限られている場合に、必要性の薄いリクエストのために真にリクエストをしたかった人が要求できなかったり、あるいはその人のリクエストに応じたカラオケ曲の放送時刻が遅くなったりすることは放送内容の充実や利用者の便宜の向上を阻害するものである。したがって、そのような必要性の薄いカラオケ曲を放送しないようにすることが、放送内容の充実や利用者の便宜の向上につながるのである。
【００７５】
また、図１１に示した処理からも判るように、受信したリクエストが重複リクエストである場合に、リクエストログ記憶（図６）に記憶する場合に、重複フラグを「１」にして記憶している。そのため、図１３の課金集計処理において、Ｓ６８０で重複フラグが１であるとＳ６９０での課金曲カウンタがインクリメントされない。したがって、結果的に、その重複リクエストについては課金金額の算出対象とはならない。
【００７６】
これによって、料金徴収についても適切な対処が可能となる。例えば単純にリクエストログ記憶（図６）に記憶されているリクエストログ数だけに基づいて料金を計算してしまうと、実際に放送したカラオケ曲数と料金徴収対象となったリクエスト数とが異なってしまい、放送システム事業者側が一部タダ取りしてしまうような状況となる。そこで本実施例のようにすれば、実際に放送したカラオケ曲数と料金徴収対象となったリクエスト数とが一致し、公正・健全なシステム運営の点で好ましい。
【００７７】
また、重複リクエストをした視聴者には、重複リクエストである旨が音声応答メッセージとして応答される。そのため、視聴者にとっては重複したリクエストであることが認識できる。そして、重複リクエストの場合には通常のリクエストをした場合の料金とは異なる（例えば無料になる）ことが予め通知されているのであれば、リクエストが重複している旨の音声応答メッセージにより、そのことも認識できる。
【００７８】
なお、課金実績の集計等においては、重複リクエストの実績は結果的に必要ないのであるが、図６のリクエストログ記憶としては、そのような重複リクエストもログとして記憶している。これは、放送センタ１０としては、リクエスト数に基づいて例えばリクエストランキングを作成する等、種々の理由によってリクエスト自体がされたことの実績は残しておくことが好ましいからである。
【００７９】
また、本実施例においては、リクエストをした場合には、それが重複リクエストであってもそうでなくても、そのリクエストに応じたカラオケ曲の放送開始予定時刻を音声応答メッセージとして視聴者に通知している。そのため、視聴者は自分のリクエストしたカラオケ曲の放送がいつ開始されるかを、ほぼリアルタイムで知ることができる。そのため、自分のリクエストしたカラオケ曲の放送開始までに例えば別の用事を済ませるといったこともでき、いつ始まるか判らないので単に待っているだけという無駄な時間をなくすことができるというように、視聴者の利用の便宜を向上させることができる。
【００８０】
以上、具体例に従って、本発明の実施の形態について説明したが、本発明はこのような具体例に限定されるものではなく、発明の要旨を逸脱しない範囲で様々な実施ができることは言うまでもない。
例えば、上記実施例では、図１３の課金集計処理において、課金曲数とそれに基づいて算出した課金金額を、「課金実績情報」として課金実績テーブル（図８）に記憶するようにしたが、例えば課金曲数だけを記憶しておき、それに基づいて別の課金処理システムが課金関連処理を実行するようにしてもよい。また、課金金額だけを記憶しておいてもよい。
【００８１】
そしてまた、課金金額の算出については、上記実施例では１曲の単価が固定であるという前提で説明したが、例えば新曲は高く、古い曲は安く設定している場合には、リクエストログ記憶にそれらの区別を付けるためのデータを記憶しておき、それぞれの場合の料金を記憶しておく料金テーブルから読み出した料金に基づいて算出するようにしてもよい。
【００８２】
また、上記実施例では、カラオケ番組の放送に使用する例を説明したが、本発明は放送用情報を供給するサーバ側が少数であり、放送用情報を要求するクライアント側が多数であり、両者が遠隔である等の理由で、放送という情報供給形態を採用する状況であることが応用の主旨である。したがって、放送用情報として音声情報だけあるいは映像情報だけという場合も考えられる。
【図面の簡単な説明】
【図１】実施例の放送センタの概略構成を示すブロック図である。
【図２】ホストコンピュータを中心した信号の流れを示す説明図である。
【図３】ホストコンピュータが取り扱うリクエストデータベースのデータ構造図である。
【図４】ホストコンピュータが取り扱うリクエスト実行テーブルのデータ構造図である。
【図５】ホストコンピュータが取り扱うリクエスト受付バッファのデータ構造図である。
【図６】ホストコンピュータが取り扱うリクエストログ記録のデータ構造図である。
【図７】ホストコンピュータが取り扱う加入者データベースのデータ構造図である。
【図８】ホストコンピュータが取り扱う課金実績テーブルのデータ構造図である。
【図９】ホストコンピュータが実行するリクエスト自動受理・登録処理の一部を示すフローチャートである。
【図１０】ホストコンピュータが実行するリクエスト自動受理・登録処理の一部を示すフローチャートである。
【図１１】ホストコンピュータが実行するリクエスト自動受理・登録処理の一部を示すフローチャートである。
【図１２】ホストコンピュータが実行するリクエスト再生処理を示すフローチャートである。
【図１３】ホストコンピュータが実行する課金集計処理を示すフローチャートである。
【符号の説明】
１０…放送センタ                  １１…ホストコンピュータ
１１ａ…ＣＰＵ                    １１ｂ…ＣＰＵメモリ
１２…外部記憶装置                １３…表示装置
１４…カラオケ再生装置            １６…放送手段
２０…音声応答装置                ４０…公衆電話回線
５０…加入者電話機
【図１】
0003610135.tif 000002
【図２】
0003610135.tif 000003
【図３】
0003610135.tif 000004
【図４】
0003610135.tif 000005
【図５】
0003610135.tif 000006
【図６】
0003610135.tif 000007
【図７】
0003610135.tif 000008
【図８】
0003610135.tif 000009
【図９】
0003610135.tif 000010
【図１０】
0003610135.tif 000011
【図１１】
0003610135.tif 000012
【図１２】
0003610135.tif 000013
【図１３】
0003610135.tif 000014