JPH0974392A - 放送センタ - Google Patents

Abstract

(57)【要約】 【課題】 所定の期間内に同じ情報が放送されるのを防
止し、視聴者の不快感をなくし、より多くのリクエスト
を受け付ける。 【解決手段】 ５桁のリクエストコードが入力される
と、ホストコンピュータ１１は、外部記憶装置１２上の
リクエストデータベースを参照して照合を行い、有効な
コードであれば、ＣＰＵメモリ１１ｂ上のリクエスト実
行テーブルのリクエストコード領域内の再生フラグが
「未」となっているものがあるかどうかを判断する。そ
れがあれば、その予約済みの演奏開始予定時刻を取り出
し、新規登録しない旨とセットで音声応答メッセージを
音声応答装置２０を介して送出し、回線を切断する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、電話回線を使用し
て視聴者から個別になされた放送要求に応じた放送用情
報を、所定の順番に従って順次放送していくリクエスト
応答機能付きの放送センタに関する。

【０００２】

【従来の技術および発明が解決しようとする課題】現
在、ＣＡＴＶシステム等のローカルなテレビジョン放送
センタと加入者端末との間において、双方向テレビジョ
ンと呼ばれるＴＶ放送の新しい形態が普及しつつある。
ただし、これらは一般にビデオ・オン・デマンド（ＶＯ
Ｄ）と呼ばれる視聴者があたかも自宅のビデオデッキで
好みの映像を視聴しているかのように映像を宅配するシ
ステムとは違い、あくまでも不特定多数に映像を発信す
る「放送」の枠を出ていない。つまり、視聴者から個別
になされた放送要求を蓄積しておき、その放送要求に応
じた放送用情報を、所定の順番に従って順次放送してい
くという限定的な双方向テレビジョンシステムである。

【０００３】このようなシステムにおけるテレビジョン
放送センタは、次々にやってくる視聴者からの放送要求
を一時的に蓄積し、要求時期が早い程早く放送されるよ
うに放送用情報を放送していくのであるが、当然ながら
このような形態であれば、視聴者からの放送要求のスピ
ードが、その要求に応じた放送用情報の放送・消化のス
ピードを上回る事態が発生する。すると、放送要求は蓄
積してしまい、要求した視聴者の待ち時間が長くなって
しまう。

【０００４】ところで、このような形態であってもカラ
オケ番組と呼ばれるカラオケ楽曲の放送のみを取り扱う
番組時間枠（もしくは設けられた専用のチャンネル）等
であれば実際の運用を行うことが可能な程度に上記の問
題は縮小する。カラオケの場合は１曲の所要時間が数分
程度であり、要求数が少なければ、待ち時間もあまり長
くはならないからである。

【０００５】ただし、このようなリクエスト応答タイプ
の放送システムにおけるカラオケ番組であっても、一定
間隔内に同じ曲が複数回リクエストされた場合に、その
リクエストを受け付けた順番通りに放送してしまうと、
同じ曲を続けてあるいは短期間に何度も放送してしまう
こととなる。つまり、予約されているがまだ演奏されて
いない曲の中に、自分がリクエストしようとする曲と同
じものがあっても、リクエスト時点ではその存在が判ら
ないのでリクエストしまうこととなる。そして自分がリ
クエストした順番より前に同じ曲の演奏があって初めて
他の人が同じ曲をリクエストしていたことが判り、そう
いう状況であったならばリクエストを控えることもでき
たと感じることとなる。

【０００６】そして、これは単に個人的な感情の問題で
はなく、そのような同じ曲が重複して演奏されること
は、そのカラオケ番組の視聴者全員に対して不快感を生
じさせるものであり、さらに、これからリクエストをし
ようとする視聴者に対しては、そのリクエストに対応す
るカラオケ曲の演奏開始時間を遅らせてしまう原因にも
なる。

【０００７】なお、これはＣＡＴＶ等のテレビジョン放
送に限らずラジオ放送あるいはその他の放送に関しても
同様の問題点が考えられる。本発明は、上述した問題点
を解決するためになされたものであり、例えば所定期間
内など、ある一定の条件内においては同じ放送用情報が
放送されることを防止し、視聴者の不快感を無くすと共
に、より多くのリクエストを受け付けて視聴者の希望に
添った放送を提供することを目的としている。

【０００８】

【課題を解決するための手段及び発明の効果】この目的
を達成するためになされた請求項１記載の発明は、視聴
者から個別になされた複数の放送要求を記憶しておく予
約順番記憶手段と、その予約順番記憶手段に記憶されて
いる予約順番に従って、順次対応する放送要求に応じた
放送用情報を放送していく放送手段とを備えたリクエス
ト応答機能付きの放送センタにおいて、前記視聴者から
なされた放送要求を前記予約順番記憶手段に記憶させる
前に、その予約順番記憶手段に同一の放送要求が記憶さ
れているかどうかを判断し、同一の放送要求が記憶され
ていない場合にのみ新規に予約させる新規予約制御手段
を備えていることを特徴とする放送センタである。

【０００９】請求項２に記載の発明は、請求項１に記載
の放送センタにおいて、前記予約順番記憶手段は、要求
時期が早い程早く放送されるように前記放送要求を記憶
しており、前記新規予約制御手段は、前記視聴者からな
された放送要求を前記予約順番記憶手段に記憶させる前
に、予約順番の遅い方から所定数以内に同一の放送要求
が記憶されているかどうかを判断し、同一の放送要求が
記憶されていない場合にのみ新規に予約させるよう構成
されていることを特徴とする。

【００１０】請求項３に記載の発明は、請求項１又は２
に記載の放送センタにおいて、前記放送手段による放送
が終了した放送用情報に対応する放送要求については、
前記予約順番記憶手段内において、前記同一の放送要求
が記憶されているかどうかの判断対象として除外するよ
うにしたことを特徴とする。

【００１１】請求項４に記載の発明は、視聴者から個別
になされた複数の放送要求を記憶しておく予約順番記憶
手段と、その予約順番記憶手段に記憶されている予約順
番に従って、順次対応する放送要求に応じた放送用情報
を放送していく放送手段とを備えたリクエスト応答機能
付きの放送センタにおいて、前記予約順番記憶手段は、
放送手段によって放送が終了した放送用情報に対応する
放送要求も記憶し続けており、前記放送手段によって放
送する放送用情報を決定する際、既に放送終了した最新
の所定数以内の放送用情報に、前記予約順番記憶手段に
従った場合に次に放送されるべき放送用情報と同一のも
のがあるかどうかを判断し、同一の放送用情報がない場
合にのみ前記放送手段によって次に放送する放送用情報
として決定させる次放送用情報決定手段を備えているこ
とを特徴とする放送センタである。

【００１２】本発明の放送センタによれば、予約順番記
憶手段が、視聴者から個別になされた放送要求を記憶し
ておく。そして、放送手段は、その予約順番記憶手段に
記憶されている予約順番に従って、順次対応する放送要
求に応じた放送用情報を放送していく。このように基本
的な放送処理を実行していくのであるが、ここで、次の
ような予約に関する処理を実行する。

【００１３】すなわち、記視聴者からなされた放送要求
を予約順番記憶手段に記憶させる前に、新規予約制御手
段は、その予約順番記憶手段に同一の放送要求が記憶さ
れているかどうかを判断し、同一の放送要求が記憶され
ていない場合にのみ新規に予約させるのである。これに
より、重複した放送要求の新規予約が禁止され、重複し
た放送用情報の放送が防止され、例えば同じ放送用情報
が何度も放送されることによる視聴者の不快感を防止す
ることができる。

【００１４】なお、予約順番記憶手段に同一の放送要求
が記憶されているかどうかの判断については、請求項２
に示すように、予約順番記憶手段が、要求時期が早い程
早く放送されるように放送要求を記憶しており、その予
約順番の遅い方から所定数以内に同一の放送要求が記憶
されているかどうかを判断するようにしてもよい。重複
した放送要求の新規予約を無制限に禁止してしまうと、
例えば２時間も３時間も前に放送された放送用情報と同
じであるとの理由で新規予約されなくなる場合もでてく
る。短時間に間に同じ放送用情報が何度も放送されると
視聴者も不快感を覚える可能性が高いが、ある程度間隔
が空くと、例えば視聴者自体も変わってしたりして、実
質的に新規予約を禁止する意味が薄れてくる。そこで、
予約順番の遅い方から所定数以内に同一の放送要求が記
憶されている場合に限って新規予約をさせないようにし
たのである。この「所定数」を適当に定めることによ
り、例えば１０〜２０分以内といった比較的短時間に同
じ放送用情報が何度も放送されることを防止でき、視聴
者に対する不快感を生じさせることなく、また新規予約
した場合の放送開始時間をむやみに遅らせてしまうこと
も防止できる。

【００１５】なお、請求項３に示すように、放送手段に
よる放送が終了した放送用情報に対応する放送要求につ
いては、予約順番記憶手段内において、同一の放送要求
が記憶されているかどうかの判断対象として除外するよ
うにしてもよい。これは次の点を考慮したものである。

【００１６】つまり、これから新規に放送要求をしよう
とする視聴者にとっては、予約されているがまだ放送さ
れていない放送要求に中に自分と同じものがある場合に
は、自分のした放送要求が新規予約がされなくても、他
人がした放送要求に応じた放送用情報が放送されること
で、実質的に要求がかなえられたことになる。しかしな
がら、すでに放送が終了した放送用情報に対応する放送
要求についても判断対象とすると、その放送自体は視聴
していない視聴者が放送要求をした場合にでも新規予約
がされない場合がでてくる。したがって、放送が終了し
た放送用情報に対応する放送要求については判断対象か
ら除外することで、そのような不都合を防止することが
できる。

【００１７】上述した請求項１〜３に記載の放送センタ
では、視聴者からなされた放送要求を予約順番記憶手段
に記憶させる前に、新規予約をしてもよいかどうかを判
断していたが、請求項４に示すように、新規予約自体は
制限なくさせ、実際に放送する段階において、放送する
かどうかを判断するようにしてもよい。

【００１８】すなわち、予約順番記憶手段は、放送手段
によって放送が終了した放送用情報に対応する放送要求
も記憶し続けており、放送手段によって放送する放送用
情報を決定する際、既に放送終了した最新の所定数以内
の放送用情報に、予約順番記憶手段に従った場合に次に
放送されるべき放送用情報と同一のものがあるかどうか
を判断する。そして、同一の放送用情報がない場合にの
み放送手段によって次に放送する放送用情報として決定
させるのである。

【００１９】このようにしても、同じ放送用情報が何度
も放送されることによる視聴者の不快感を防止すること
ができ、また、新規予約した場合の放送開始時間をむや
みに遅らせてしまうことも防止できる。なお、視聴者か
らの放送要求を受け付ける場合には、例えば電話回線を
介して行なうことが考えられる。その際、所定のガイダ
ンス用音声情報を電話回線を介して視聴者側に送信し、
視聴者識別情報や放送要求内容識別情報等をそのガイダ
ンス用音声情報に対する返答として受信するようにして
もよい。例えば、視聴者からの電話を自動着信し、電子
音声による案内を行う音声応答機能と、電話によるダイ
ヤルトーンを使用したコードの発信を受信するコード受
信機能を備え、音声応答機能によって所定のガイダンス
音声を流し、それにしたがって視聴者が放送要求として
例えば要求するカラオケの曲番号や視聴者識別番号等を
プッシュボタン等で入力し、それをダイヤルトーンを使
用したコードとして受信するようにすれば便利である。

【００２０】そして、この場合には、新規予約がなされ
たかどうかと、新規予約された場合には、その放送開始
予定に関する情報（例えばカラオケ番組であれば、何曲
後に放送されるとか、放送開始予定時刻などの情報）を
応答するようにしておくと好ましい。

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

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

【００２３】このように、本発明の放送センタによれ
ば、例えば所定期間内など、ある一定の条件内において
は同じ放送用情報が放送されることを防止し、視聴者の
不快感を無くすと共に、より多くのリクエストを受け付
けて視聴者の希望に添った放送を提供することができ
る。

【００２４】

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

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

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

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

【００２８】ホストコンピュータ１１はこの蓄積された
リクエストコードと、外部記憶装置１２内のデータベー
スを基に、リクエスト実行テーブル（図３参照）を作成
し、このリクエスト実行テーブルに従う順番で蓄積され
たリクエストコードがカラオケ再生装置１４に渡され、
カラオケ演奏が実行されていく。

【００２９】なお、本実施例のカラオケ再生装置１４
は、カラオケ演奏音を再生すると共に、歌詞テロップの
合成された背景映像も再生できるものである。したがっ
て、放送手段１６は、テレビジョン放送手段である。な
お、発明の主旨を考えると映像がなくても構わないの
で、カラオケ再生装置１４はカラオケ演奏音だけを再生
するものとし、放送手段１６がいわゆるラジオ放送手段
であっても構わない。

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

【００３１】表示装置１３はホストコンピュータ１１に
接続されており、これらの状況を表示することができ
る。これは、放送センタ１０のオペレータが確認するた
めに利用される。続いて、図２を参照して、ホストコン
ピュータ１１を中心とした信号の流れを説明する。

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

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

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

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

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

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

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

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

【００４０】最初に入力された加入者番号が有効である
場合、あるいは再度入力された加入者番号が有効であれ
ば（Ｓ１７０：ＹＥＳ）、Ｓ１９０（図９参照）に移行
する。Ｓ１９０では、音声応答メッセージを送出し、リ
クエストコードの入力を促す。続くＳ２００〜２２０で
は、ダイヤルパルスの発信を待ち、入力された番号をリ
クエスト受付バッファ（図５）のリクエストコードの領
域Ｃ２に格納していき、これを５桁のリクエストコード
がすべて入力されるまで繰り返す。

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

【００４２】最初に入力されたリクエストコードが有効
である場合、あるいは再度入力されたリクエストコード
が有効であれば（Ｓ２４０：ＹＥＳ）、Ｓ２６０の処理
に移行する。Ｓ２６０では、未再生曲の中に同一のもの
があるかどうかを判断する。具体的には、ＣＰＵメモリ
１１ｂ上のリクエスト実行テーブル（図４）のリクエス
トコード領域Ｂ２の内の、再生フラグＢ１が「未」とな
っているもの（予約はされているがまだ再生されていな
い曲、すなわちこれから再生される曲）の中に、同一の
リクエストコードがないかどうかを判断する。

【００４３】ここで、リクエスト実行テーブルについて
説明しておく。このリクエスト実行テーブルは、図４に
示すように、再生フラグＢ１、リクエストコードＢ２、
演奏開始予定時刻Ｂ３の３つの項目からなっている。Ｓ
２６０で否定判断の場合には、Ｓ２８０，Ｓ３１０，Ｓ
３１５を経て図１０のＳ３２０へ移行して、さらにＳ３
３０において、リクエスト受付バッファ（図５）の内容
をリクエスト実行テーブル（図４）内の受付ポインタＢ
５の示しているリクエストコード領域Ｂ２に新規予約す
る。この新規予約は、リクエストコードＣ２を受付ポイ
ンタＢ５の示すリクエストコード領域Ｂ２にコピーし、
再生フラグＢ１を「未」とすることにより行われる。な
お、初期状態では再生フラグＢ１にはすべて「無」が、
リクエストコードＢ２には不定値が入っているものとす
る。

【００４４】また、演奏開始予定時刻Ｂ３は、一つ前の
リクエストコードＢ２を予約した場合に、その曲の再生
時間を加算することによって、次に新規予約された場合
の演奏開始予定時刻Ｂ３が決定する。新規予約が終了す
ると受付ポインタＢ５がリクエスト実行テーブル（図
４）上の次の領域に進められるため、その領域の演奏開
始予定時刻Ｂ３の欄に、上述した「次に新規予約された
場合の演奏開始予定時刻」が書き込まれることとなる。

【００４５】図９に戻り、Ｓ２６０では、このリクエス
ト実行テーブル（図４）のリクエストコード領域Ｂ２の
内の、再生フラグＢ１が「未」となっているものの中
に、同一のリクエストコードがないかどうかを判断する
のである。そして、同一のものがあれば（Ｓ２６０：Ｙ
ＥＳ）、Ｓ２７０へ移行して、その予約済みの演奏開始
予定時刻を取り出す。例えば、新規に受け付けたリクエ
ストコードが「０１３０１」であった場合には、同じも
のが既に予約されているので、その予約済みのリクエス
トコードに対応する演奏開始予定時刻である「１２時３
０分」を取り出すこととなる。

【００４６】そして、続くＳ２９０において、上記Ｓ２
７０において取り出した演奏開始予定時刻を、新規登録
しない旨とセットで視聴者側に知らせるための音声応答
メッセージを送出し、Ｓ３００では回線を切断する。そ
の後は、図８のＳ１００へ戻る。

【００４７】なお、Ｓ２９０での音声応答メッセージ
は、例えば「リクエストは受け付けられません。但し、
同じ曲が既に予約されていますので、今から××番目の
曲として、◇◇時□□分頃に放送されます。」といった
ような内容である。一方、同一のものが予約されていな
ければ（Ｓ２６０：ＮＯ）、Ｓ２８０へ移行して、新規
予約の場合の演奏開始予定時刻を取り出す。これは、受
付ポインタＢ５の示す領域のものであり、図４に示す場
合では、「１２時３９分」となる。

【００４８】そして、続くＳ３１０において、上記Ｓ２
８０において取り出した演奏開始予定時刻を、新規登録
する旨とセットで視聴者側に知らせるための音声応答メ
ッセージを送出し、Ｓ３１５では回線を切断する。その
後は、図１０のＳ３２０へ移行して、新規予約の具体的
処理を実行する。

【００４９】なお、Ｓ３１５の音声応答メッセージは、
例えば「リクエストを受け付けました。あなたのリクエ
ストされた○○は、今から××番目の曲として、◇◇時
□□分頃に放送されます。」といったような内容であ
る。Ｓ３２０（図１０参照）では、受け付けた日時をタ
イムスタンプとしてリクエスト受付バッファ（図５）の
受付時刻の領域Ｃ１に書き込む。ここまでの処理が終了
すれば、図５に示すリクエスト受付バッファ上には受付
時刻Ｃ１、有効なリクエストコードＣ２及び有効な加入
者コードＣ３の３要素が揃い、実際のリクエストの受付
が可能になるので、続くＳ３３０では、このリクエスト
受付バッファ（図５）の内容をリクエスト実行テーブル
（図４）内の受付ポインタＢ５の示しているリクエスト
コード領域Ｂ２に新規予約する。この新規予約は、リク
エスト受付バッファ（図５）リクエストコードＣ２を受
付ポインタの示すリクエストコード領域Ｂ２にコピー
し、再生フラグＢ１を「未」とすることにより行われる
ことは上述した。

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

【００５１】次に、Ｓ３６０において、演奏待ちリクエ
スト数の値をインクリメントし、Ｓ３７０では、リクエ
スト受付バッファ（図５）のリクエストコードＣ２を基
に検索したリクエストデータベース（図３）の要素であ
る再生時間Ａ３の値を、図４のリクエスト実行テーブル
の演奏開始予定時刻の最新のもの（受付ポインタＢ５の
示す一つ前の領域に書き込まれているもの）に加算す
る。これにより、次にリクエストがされた場合の演奏開
始予定時刻が算出され、この時刻を受付ポインタＢ５の
示す演奏開始予定時刻領域Ｂ３に書き込む。

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

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

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

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

【００５６】次に、Ｓ５１０において、演奏待ちリクエ
スト数の値をデクリメントする。なお、この後は、再び
Ｓ４１０に戻り、次のリクエストの再生を繰り返す。以
上説明した本実施例の放送センタ１０によれば、視聴者
からのリクエストを受け付けた場合に、リクエスト実行
テーブル（図４）のリクエストコード領域Ｂ２の内の、
再生フラグＢ１が「未」となっているもの（予約はされ
ているがまだ再生されていない曲、すなわちこれから再
生される曲）の中に、同一のリクエストコードがないか
どうかを判断し、同一のリクエストコードがない場合に
のみ新規に予約させるのである。これにより、同じ曲が
何度も放送されることによる視聴者の不快感を防止する
ことができる。

【００５７】なお、上記実施例では、リクエスト実行テ
ーブル（図４）のリクエストコード領域Ｂ２の内の、再
生フラグＢ１が「未」となっているものの中に、同一の
リクエストコードがないかどうかを判断しているが、さ
らにその中の、予約順番の遅い方から所定数以内に同一
のリクエストコードがあるかどうかを判断するようにし
てもよい。重複したリクエストの新規予約を無制限に禁
止してしまうと、例えば１０曲や２０曲も前に予約され
ている曲と同じであるとの理由で新規予約ができなくな
る場合もでてくる。短時間に間に同じ曲が何度も放送さ
れると視聴者も不快感を覚える可能性が高いが、ある程
度間隔が空くと、例えば視聴者自体も変わってしたりし
て、実質的に新規予約を禁止する意味が薄れてくる。そ
こで、予約順番の遅い方から所定数以内に同一のリクエ
ストコードが記憶されている場合に限って新規予約をさ
せないようにすることも好ましい。

【００５８】この「所定数」を適当に定めることによ
り、例えば１０〜２０分以内といった比較的短時間に同
じ曲が何度も放送されることを防止できる。例えばカラ
オケ曲の場合には、１曲あたり３〜５分程度であるの
で、３〜５曲程度を「所定数」としておくことが考えら
れる。このようにすれば、視聴者に対する不快感を生じ
させることなく、また新規予約した場合の放送開始時間
をむやみに遅らせてしまうことも防止できる。

【００５９】なお、上記実施例の場合には、放送が終了
したリクエストコードに対しては、図４に示すように、
再生フラグＢ１として「済」を書き込むことにより、図
９のＳ２６０での同一の未再生曲があるかどうかの判断
対象として除外するようにしている。これは次の点を考
慮したものである。

【００６０】つまり、これから新規にリクエストをしよ
うとする視聴者にとっては、リクエスト実行テーブル
（図４）に予約されているがまだ放送自体はされていな
いリクエストコード中に自分のリクエスト曲と同じもの
がある場合には、自分のリクエストが新規予約がされな
くても、他人がしたリクエストに応じたカラオケ曲が放
送されることで、実質的に要求がかなえられたことにな
る。しかしながら、すでに放送が終了したカラオケ曲に
対応するリクエストコードについても判断対象とする
と、そのカラオケ放送自体は視聴していない視聴者がリ
クエストをした場合にでも新規予約がされない場合がで
てくる。例えば、図４においてリクエストコードＢ２と
して記憶されている「０２００７」や「０３５５１」と
同じリクエストについても受け付けられなくなってく
る。したがって、放送が終了したものについては「済」
を書き込んで判断対象から除外することで、そのような
不都合を防止することができる。

【００６１】以上、具体例に従って、本発明の実施の形
態について説明したが、本発明はこのような具体例に限
定されるものではなく、発明の要旨を逸脱しない範囲で
様々な実施ができることは言うまでもない。例えば、上
述の実施例では、放送が終了したリクエストコードにつ
いては図４中で再生フラグＢ１として「済」を書き込ん
で、図９のＳ２６０での判断対象として例外なく除外す
るようにしたが、単純に曲数だけで判断してもよい。す
なわち、放送が終了したか未再生（未放送）かは関係な
く、予約順番の遅い方から所定数以内に同一のリクエス
トコードが記憶されている場合には新規予約をさせない
ようにするのである。例えば５曲前までに同一のリクエ
ストコードがあれば新規予約しないとすれば、図４の場
合には、リクエストコード「０３５５１」の曲をリクエ
ストした場合には、放送終了した中に同一のものがある
ので、新規予約しないこととなる。これは、単純に、短
時間の間に同じ曲が繰り返し放送されることを防止する
ためである。

【００６２】また、上記実施例の放送センタ１０では、
視聴者からなされたリクエストをリクエスト実行テーブ
ル（図４）に新規予約させる前に、新規予約をしてもよ
いかどうかを判断していたが、その新規予約自体は制限
なくさせ、実際に放送する段階において、放送するかど
うかを判断するようにしてもよい。例えば、図１２のフ
ローチャートに示すようなリクエスト再生処理を実行す
ればよい。

【００６３】この図１２の処理は、Ｓ４４５を追加した
以外は図１１に示した処理と同じである。Ｓ４４０でこ
れから再生するリクエストコードを取り出した後、Ｓ４
４５えは、そのリクエストコードが、図４のリクエスト
実行テーブル（図４）中の再生終了（放送終了）したも
のの最新の所定数以内にあるかどうかを判断する。そし
て、同一のリクエストコードがない場合には（Ｓ４４
５：ＮＯ）Ｓ４５０へ移行して、通常の再生処理とな
る。一方、同一のリクエストコードがある場合には（Ｓ
４４５：ＹＥＳ）、Ｓ４５０〜Ｓ４８０の再生処理をす
ることなくＳ４９０へ移行する。

【００６４】このようにしても、同じカラオケ曲が何度
も放送されることによる視聴者の不快感を防止すること
ができ、また、新規予約した場合の放送開始時間をむや
みに遅らせてしまうことも防止できる。

【図面の簡単な説明】

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

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

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

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

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

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

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

【図８】 ホストコンピュータが実行するリクエスト自
動受理・予約処理の一部を示すフローチャートである。

【図９】 ホストコンピュータが実行するリクエスト自
動受理・予約処理の一部を示すフローチャートである。

【図１０】 ホストコンピュータが実行するリクエスト
自動受理・予約処理の一部を示すフローチャートであ
る。

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

【図１２】 別実施例の場合のリクエスト再生処理を示
すフローチャートである。

【符号の説明】

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

Claims (4)

【特許請求の範囲】
1. 【請求項１】 視聴者から個別になされた複数の放送要
   求を記憶しておく予約順番記憶手段と、 その予約順番記憶手段に記憶されている予約順番に従っ
   て、順次対応する放送要求に応じた放送用情報を放送し
   ていく放送手段とを備えたリクエスト応答機能付きの放
   送センタにおいて、 前記視聴者からなされた放送要求を前記予約順番記憶手
   段に記憶させる前に、その予約順番記憶手段に同一の放
   送要求が記憶されているかどうかを判断し、同一の放送
   要求が記憶されていない場合にのみ新規に予約させる新
   規予約制御手段を備えていることを特徴とする放送セン
   タ。
2. 【請求項２】 請求項１に記載の放送センタにおいて、 前記予約順番記憶手段は、要求時期が早い程早く放送さ
   れるように前記放送要求を記憶しており、 前記新規予約制御手段は、前記視聴者からなされた放送
   要求を前記予約順番記憶手段に記憶させる前に、予約順
   番の遅い方から所定数以内に同一の放送要求が記憶され
   ているかどうかを判断し、同一の放送要求が記憶されて
   いない場合にのみ新規に予約させるよう構成されている
   ことを特徴とする放送センタ。
3. 【請求項３】 請求項１又は２に記載の放送センタにお
   いて、 前記放送手段による放送が終了した放送用情報に対応す
   る放送要求については、前記予約順番記憶手段内におい
   て、前記同一の放送要求が記憶されているかどうかの判
   断対象として除外するようにしたことを特徴とする放送
   センタ。
4. 【請求項４】 視聴者から個別になされた複数の放送要
   求を記憶しておく予約順番記憶手段と、 その予約順番記憶手段に記憶されている予約順番に従っ
   て、順次対応する放送要求に応じた放送用情報を放送し
   ていく放送手段とを備えたリクエスト応答機能付きの放
   送センタにおいて、 前記予約順番記憶手段は、放送手段によって放送が終了
   した放送用情報に対応する放送要求も記憶し続けてお
   り、 前記放送手段によって放送する放送用情報を決定する
   際、既に放送終了した最新の所定数以内の放送用情報
   に、前記予約順番記憶手段に従った場合に次に放送され
   るべき放送用情報と同一のものがあるかどうかを判断
   し、同一の放送用情報がない場合にのみ前記放送手段に
   よって次に放送する放送用情報として決定させる次放送
   用情報決定手段を備えていることを特徴とする放送セン
   タ。