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