JPH09167999A - 放送センタ - Google Patents

Abstract

(57)【要約】 【課題】 より多くの視聴者の希望に沿ったリクエスト
番組を提供する。 【解決手段】 リクエスト回数順にする第１モードが設
定された場合、制御部１４は、リクエスト入力部１０か
らのリクエスト信号を受信すると、リクエスト情報記憶
部１８ａ内のリクエストキューテーブルを参照して、同
じ曲番号があるかどうかを判断する。同じ番号があれ
ば、その曲番号の登録されているテーブルのリクエスト
回数をインクリメントする。そして、１つ前の曲のリク
エスト回数を比較し、該回数が多ければ、その曲とリク
エストキューの順序を入れ替える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、例えば視聴者から
個別になされた放送要求に応じた放送用情報を放送する
リクエスト応答機能を備えた放送センタに関する。

【０００２】

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

【０００３】また、このようなシステムにおけるテレビ
ジョン放送センタは、次々にやってくる視聴者からの放
送要求を一時的に記憶し、要求された順番に映像を含む
放送用情報を放送していくような「リクエスト番組」を
放送している。例えば、カラオケ番組を考えると、視聴
者からの放送要求に応じたカラオケ曲が放送されること
となる。そして、このような場合には、例えば放送要求
がなされた順番に放送予約テーブルのようなものに記憶
させておき、その記憶された予約順番にしたがってカラ
オケ曲を放送していくことが考えられる。

【０００４】

【発明が解決しようとする課題】しかしながら、番組放
送中にもリアルタイムで放送要求を受け付けるシステム
を採用した場合、リクエストされたカラオケ曲をその放
送要求時期が早い順番でそのまま再生していくと、例え
ばあまり人気のないカラオケ曲が放送要求されて予約さ
れた後、非常に人気のある曲に対して放送要求が多くあ
った場合にでも、あまり人気のない曲の後に再生するし
かない。すると、例えば番組終了直前などは放送要求の
非常に少ない（例えば１回しかない）カラオケ曲を放送
したために、放送要求が非常に多かったカラオケ曲を放
送しないで番組を終了してしまうことも考えられ、視聴
者全体として見た場合の要望を満たしているとはいい難
い状況が生じてしまう。

【０００５】そこで本発明は、上述した問題点を解決す
るためになされたものであり、例えば放送要求時期は遅
くても放送要求の総数が多い放送用情報は優先して早く
放送できるようにして、より多くの視聴者の希望に添っ
たリクエスト番組を提供することを目的としている。

【０００６】

【課題を解決するための手段及び発明の効果】この目的
を達成するためになされた請求項１記載の発明は、放送
要求を要求記憶手段にデータとして記憶させる要求入力
手段と、前記要求記憶手段に記憶されている放送要求に
応じた放送用情報の内から次に放送するものを選択する
選択手段と、該選択手段によって選択された放送用情報
を放送する放送手段と、を備えたリクエスト応答機能付
きの放送センタにおいて、前記要求入力手段によって要
求記憶手段に記憶させた放送要求の履歴を記憶しておく
要求履歴記憶手段を備え、前記放送手段によって放送を
実行している間も、前記要求記憶手段への放送要求の記
憶及び要求履歴記憶手段への放送要求履歴の記憶を続行
するよう構成されていると共に、前記選択手段は、次に
放送する放送用情報を選択する際、その時点で所定の条
件を満たす選択候補の放送用情報が複数ある場合には、
前記要求履歴記憶手段に記憶された放送要求数がその時
点で最多のものを選択することを特徴とする放送センタ
である。

【０００７】本発明の放送センタによれば、要求入力手
段によって放送要求が要求記憶手段にデータとして記憶
される。そして、選択手段が、要求記憶手段に記憶され
ている放送要求に応じた放送用情報の内から次に放送す
るものを選択し、その選択された放送用情報を放送手段
が放送する。

【０００８】このようにリクエスト応答機能を備えてい
るのであるが、選択手段が次に放送する放送用情報を選
択するに際して次のような処理を実行する。すなわち、
要求履歴記憶手段には、要求入力手段によって要求記憶
手段に記憶させた放送要求の履歴が記憶されるのである
が、放送手段によって放送を実行している間も、要求記
憶手段への放送要求の記憶及び要求履歴記憶手段への放
送要求履歴の記憶を続行する。そして、選択手段は、次
に放送する放送用情報を選択する際、その時点で所定の
条件を満たす選択候補の放送用情報が複数ある場合に
は、要求履歴記憶手段に記憶された放送要求数がその時
点で最多のものを選択する。

【０００９】したがって、例えば放送用情報Ａに対する
放送要求が１回あった後、放送用情報Ｂに対する放送要
求が連続して３回あった場合で、放送用情報ＡもＢも選
択候補となっていた場合には、要求時期はＡの方が早い
が、ＡでなくＢを優先して放送することとなる。もちろ
ん連続して放送要求がなくてはならないということでは
なく、例えば放送要求がＡ→Ｂ→Ｃ→Ｂ→Ｄ→Ｂ→Ｃと
いう順番でなされ、Ａ〜Ｄがすべて選択候補となってい
た場合には、Ｂの放送要求数が３でその時点では最多な
ので、Ｂが選択される。

【００１０】このように放送要求時期は遅くても放送要
求の総数が多い放送用情報は優先して早く放送できるよ
うにして、より多くの視聴者の希望に添ったリクエスト
番組を提供することができる。例えば放送要求時期が早
い順番にだけ従って放送してくと、番組終了直前などは
放送要求の非常に少ない（例えば１回しかない）放送用
情報を放送したために、放送要求が非常に多かった放送
用情報を再生しないで番組を終了してしまうことも考え
られ、視聴者全体として見た場合の要望を満たしている
とはいい難い状況が生じてしまうが、本放送センタによ
れば、放送要求が多い放送用情報を優先して放送するの
で、視聴者全体として見た場合の要望を満たすことがで
きるのである。

【００１１】なお、選択手段による選択候補となり得る
放送用情報の満たすべき所定の条件は、請求項３に示す
ように、放送手段によってまだ放送が開始されていない
ものとすることが好ましい。例えば、上述のＡ→Ｂ→Ｃ
→Ｂ→Ｄ→Ｂ→Ｃという順番で放送要求がなされＢが選
択されて放送された場合を考える。この後放送要求がさ
れずに次の放送用情報を選択する場合に、何も考慮しな
いと再度Ｂを選択してしまうこととなる。したがって、
一度放送したＢは除外して、それ以外のＡ，Ｃ，Ｄ，Ｅ
の４つを選択候補とする。この場合はＣが２回で最多な
ので、やはりＡではなくＣが優先して放送されることと
なる。なお、Ｃの放送後に新規の放送要求がなくＡ，
Ｄ，Ｅの３つが選択候補となった場合には、いずれも放
送要求数が１回で同じなので、この場合は例えば放送要
求時期の早いＡを選択すればよい。

【００１２】また、請求項２に示すように、放送要求数
の多い順番に放送する第１のモードと、放送要求時期の
早い順番に放送する第２のモードとのいずれかを外部か
ら選択設定するためのモード選択手段を備え、前記選択
手段は、その時点で所定の条件を満たす選択候補の放送
用情報が複数ある場合、第１のモードに設定されている
場合には要求履歴記憶手段に記憶された放送要求数がそ
の時点で最多のものを選択し、第２のモードに設定され
ている場合には要求記憶手段にデータとして記憶させた
時期の最も早いものを選択するように構成してもよい。

【００１３】状況によっては、放送要求時期が早いの
に、後からなされた放送要求に対応する放送用情報が優
先して放送されることによる不都合が生じる場合も考え
られるので、上述した第１のモードと第２のモードのい
ずれかを外部から選択設定できるようにしておけば便利
である。例えば、２時間の番組を放送する場合に、前半
の１時間は第２モードに設定しておき、後半の１時間は
第１モードに設定することが考えられる。例えば、番組
の最初の方に放送要求をしたにもかかわらず、その後の
放送要求が全て２回以上あったため、結局２時間の番組
中に放送されないという状況も考えられる。したがっ
て、最初の１時間については第２モードにして、あまり
人気のない（つまり放送要求が少ない）放送用情報であ
っても放送要求時期の早い順番に放送していき、後半の
１時間については第１モードにして、上述したように、
番組終了直前に放送要求の非常に少ない放送用情報のた
めに放送要求が非常に多い放送用情報を放送しないで番
組を終了してしまうという不都合を防止することができ
る。

【００１４】また、要求入力手段は、放送要求を要求記
憶手段にデータとして記憶させるものであるが、オペレ
ータが視聴者からの放送要求を聞き、それをマニュアル
でこの要求入力手段を介して入力するようにしてもよ
い。また、要求入力手段として音声応答機能をもたせ、
視聴者から直接電話などで放送要求が行えるようにし、
放送センタ側においてオペレータ等の人手を全く介さな
いシステムとして構築することも可能である。

【００１５】このように人手を介さずに自動的に放送要
求を記憶させるものとしては、例えば請求項４に示すも
のが考えられる。その構成は、要求入力手段が、電話回
線を介して視聴者から個別になされた放送要求を受け付
けて要求記憶手段にデータとして自動的に記憶させるも
のであり、放送要求を受け付ける際、所定のガイダンス
用音声情報を電話回線を介して視聴者側に送信し、視聴
者識別情報や放送要求内容識別情報等をガイダンス用音
声情報に対する返答として受信するのである。

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

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

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

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

【００２０】

【発明の実施の形態】以下、本発明の放送センタを具体
化した一実施例を図面を参照しながら説明する。図１
は、本実施例の放送センタの概略構成を示すブロック図
である。図１に示すように、放送センタ１は、「放送要
求入力手段」としてのリクエスト入力部１０と、「モー
ド選択手段」に相当し、番組の開始・終了を指示する指
示手段も兼ねた選択指示部１２と、「選択手段」に相当
し、センタ全体の制御も行なう制御手段としての制御部
１４と、「放送要求記憶手段」及び「要求履歴記憶手
段」に相当するリクエスト情報記憶部１８ａとカラオケ
曲を演奏するためのデータを記憶している曲データ記憶
部１８ｂを備えたハードディスク１８と、カラオケ曲の
再生を行うカラオケ再生装置１６と、カラオケ再生装置
１６で再生されたカラオケ曲を放送する「放送手段」と
しての放送部２０とを備えている。

【００２１】本実施例の放送センタ１ではカラオケのリ
クエスト番組を放送することができるのであるが、この
カラオケ番組はカラオケ演奏のみで構成されており、リ
クエスト入力部１０より入力された「放送要求」として
のリクエスト情報をもとに、制御部１４がそのカラオケ
番組内において次に演奏するカラオケを選択し、カラオ
ケ再生装置１６に演奏曲を指定する。カラオケ再生装置
１６は制御部１４より指定されたカラオケ曲の曲データ
をハードディスク１８の曲データ記憶部１８ｂより読み
出し、再生処理を行う。この再生処理によってカラオケ
演奏音が再生されると共に、歌詞テロップの合成された
背景映像も再生される。こうして再生された映像と音声
は放送部２０により放送されるのである。

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

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

【００２４】なお、リクエスト入力部１０については、
オペレータが視聴者からのリクエストを聞き、それをマ
ニュアルでこのリクエスト入力部１０を介して入力する
ようにしてもよいし、また、電話受付機能と音声応答機
能をもたせ、視聴者からのリクエストを自動的に受け付
けて記憶するようなシステムとしてもよい。そうすれ
ば、放送センタ１側においてオペレータ等の人手を全く
介さないシステムとして構築することも可能である。

【００２５】例えば、視聴者からの電話を自動着信し、
電子音声による案内を行う音声応答機能と、電話による
ダイヤルトーンを使用したコードの発信を受信するコー
ド受信機能を備え、音声応答機能によって所定のガイダ
ンス音声を流し、それにしたがって視聴者が要求する例
えばカラオケの曲番号や視聴者識別番号等をプッシュボ
タン等で入力し、それをダイヤルトーンを使用したコー
ドとして受信するようにすれば便利である。なお、電話
回線を介して視聴者から個別になされたリクエストを受
信する例を説明したが、視聴者からのリクエストを受信
する方法は当然それ以外でも構わない、例えば、ＣＡＴ
Ｖの同軸ケーブルを介して双方向全２重通信が実現され
るのであれば、その同軸ケーブルを介して行ってもよ
い。

【００２６】このような本実施例の放送センタ１におけ
る動作をより明確にするため、具体的なリクエスト受付
処理、演奏指示処理について図を参照して説明する。ま
ず、具体的な処理の前に、ハードディスク１８のリクエ
スト情報記憶部１８ａに格納されている本実施例のリク
エストキューテーブルについて図２を参照して説明す
る。リクエストキューテーブルには、リクエスト入力部
１０よりリクエストされた曲番号ごとに情報を持ち、そ
れぞれ曲番号Ｄ２、その曲番号Ｄ２のリクエストされた
件数Ｄ１、番組中に演奏を終了をしていることを示す演
奏終了フラグＤ３、再生された時点でのリクエスト回数
Ｄ４の４つの項目を持つ。

【００２７】ここで、再生時リクエスト回数Ｄ４は次の
ように利用される。この再生時リクエスト回数Ｄ４はそ
の曲番号の曲が再生された時点でのリクエスト回数であ
るが、これよりもリクエスト回数Ｄ１の方が大きけれ
ば、その曲を放送した後に新規にリクエストがあったこ
とが判る。したがって、詳しくは後述するが、未再生の
リクエスト曲がなくなった場合には次に放送する曲を、
すでに再生した曲の中から例外的に選択するので、この
選択する場合に、再生時リクエスト回数Ｄ４とリクエス
ト回数Ｄ１を考慮するのである。

【００２８】次に、番組を構成する演奏曲の再生指示を
行い番組の構成を行う演奏制御処理を図３のフローチャ
ートを参照して説明する。本演奏制御処理の最初のステ
ップＳ１においては、選択指示部１２から指示されたリ
クエストの受付モードの選択設定処理を行う。これは、
リクエストの入力によるリクエスト受付割り込み処理
を、リクエスト回数順にする第１モードか、リクエスト
順にする第２モードかを選択設定するのである。

【００２９】ここで、Ｓ１で設定された各モードによる
リクエスト受付処理を図４，５のフローチャートを参照
して説明する。図４は、リクエスト回数順にする第１モ
ードが設定された場合のリクエスト受付処理を示すフロ
ーチャートである。

【００３０】最初のステップＳ４１においては、リクエ
ストがあるかどうかを判断し、リクエストされた場合に
は（Ｓ４１：ＹＥＳ）、続くＳ４３にて、リクエストキ
ュー（図２）を参照してすでにリクエストされている番
号の中に同じものがあるかどうかを判断する。

【００３１】同じ曲番号がない場合には（Ｓ４３：Ｎ
Ｏ）、Ｓ４５へ移行して新規登録を行なう。具体的に
は、リクエストキューの最後にリクエストされた曲番号
を入れてリクエスト回数を１とする。Ｓ４５の処理の後
は、本処理を一旦終了する。一方、Ｓ４３にて、同じ番
号がすでにリクエストされていると判断された場合には
（Ｓ４３：ＹＥＳ）、Ｓ４７へ移行して、その曲番号の
登録されているテーブルのリクエスト回数Ｄ１をインク
リメント（１を加算）する。Ｓ４７の処理の後は、リク
エスト回数順にリクエストキューを並び替えるため、Ｓ
４９，Ｓ５１，Ｓ５３の処理を行なう。

【００３２】Ｓ４９では、Ｓ４７でリクエスト回数Ｄ１
をインクリメントしたものを、１つ前の曲のテーブルに
おけるリクエスト回数Ｄ１と比較し、Ｓ５１ではリクエ
スト回数Ｄ１が前の曲のものより多いかどうかを判断す
る。そして、リクエスト回数が多ければ（Ｓ５１：Ｎ
Ｏ）、順序は変わらないのでそのまま終了する。

【００３３】一方、リクエスト回数が前の曲より多くな
っている場合は（Ｓ５１：ＹＥＳ）、Ｓ５３へ移行し
て、その曲とリクエストキューの順序を入れ替える。例
えば、図２（Ａ）に示すリクエストキューの状態から、
曲番号９５００が新規にリクエストされたとすると、曲
番号９５００の登録されているテーブルのリクエスト回
数Ｄ１は「２」となり、その前に並んでいた曲番号７３
０のテーブルのリクエスト回数Ｄ１の「１」を上回る。
そこで両者を並び替えることにより、図２（Ｂ）に示す
ようなリクエストキューの状態になるのである。

【００３４】Ｓ５３の処理の後は再度Ｓ４９へ戻り、さ
らに前の曲のリクエスト回数との比較を行う。ここでま
たリクエスト回数が前の曲より多くなっている場合は
（Ｓ５１：ＹＥＳ）、その曲とリクエストキューの順序
を入れ替える（Ｓ５３）。例えば、前２つのテーブルの
リクエスト回数Ｄ１が「１」であった場合に、その後の
テーブルのリクエスト回数Ｄ１が「２」になると、２回
入れ替え処理が実行され、順番が２つ前に移動する。

【００３５】このようにＳ４９，Ｓ５１，Ｓ５３の処理
を繰り返し、リクエストキュー（図２）をリクエスト回
数順に並び替えてから本処理を終了するのである。な
お、この処理からも判るように、第１モードの場合に
は、図２に示すリクエストキューテーブルのＤ１〜Ｄ４
の４つの項目が全て使用されることとなる。

【００３６】次に、リクエスト順にする第２モードが設
定された場合のリクエスト受付処理を図５のフローチャ
ートを参照して説明する。この場合は、リクエスト入力
があれば（Ｓ６１：ＹＥＳ）、上述の図４のＳ４５と同
様の新規登録を行なう。すなわちリクエストキューテー
ブルの最後尾に入力のあった曲の番号を入れてリクエス
ト回数を１にする（Ｓ６３）。リクエストされた順序で
すべて再生するモードなので、これで一旦終了する。な
お、この処理からも判るように、第２モードの場合に
は、図２に示すリクエストキューテーブルの曲番号Ｄ２
と演奏終了フラグＤ３の２つの項目しか使用されないこ
ととなる。

【００３７】以上説明した図４又は図５に示すリクエス
ト受付処理は、図３の演奏制御処理とは別個に実行され
ており、図３の演奏制御処理は、リクエスト受付処理に
よって作成されたリクエストキューテーブルに従って演
奏をしていくのである。図３のＳ３以降の処理を説明す
る。

【００３８】Ｓ３では、選択指示部１２から番組開始の
指令が入力されるのを待つ。そして、番組開始指令の入
力があれば（Ｓ３：ＹＥＳ）、Ｓ５へ移行して、リクエ
ストキュー（図２参照）の演奏終了フラグＤ３と再生時
リクエスト回数Ｄ４を「０」で初期化し、Ｓ７へ移行す
る。

【００３９】Ｓ７では、番組終了の指令があったかどう
かを判断し、番組終了指令があれば（Ｓ７：ＹＥＳ）、
番組を終了してＳ１へ戻る。一方、番組終了指令がなけ
れば（Ｓ７：ＮＯ）、Ｓ９へ移行して、リクエストキュ
ーテーブル（図２参照）に未演奏のリクエストがあるか
どうかを判断する。これは、演奏終了フラグＤ３が
「０」であれば未演奏であり、演奏終了フラグＤ３が
「１」であれば演奏終了済みであると判断する。

【００４０】未演奏リクエストがあれば（Ｓ９：ＹＥ
Ｓ）、Ｓ１１へ移行して、その中から曲を選択する。こ
の選択について説明すると、Ｓ１において第１モードに
設定されている場合には、未演奏リクエストの中でリク
エスト回数Ｄ１の最も多いものを選択し、第２モードに
設定されている場合には最も早くリクエストされたもの
を選択する。なお、上述の図４でも説明したが、第１モ
ードの場合、リクエストされると新規のものであればリ
クエストキューテーブルの最後に新規登録され、重複し
たリクエストであればリクエスト回数Ｄ１を加算した
後、図４のＳ４９，Ｓ５１に示すように回数の多い順番
にテーブルを並び替える処理を行っているので、結局
は、演奏終了フラグＤ３が「０」に設定されているテー
ブルの内の最も前にあるものを選択することとなる。第
２モードの場合にはリクエスト順のテーブルとなるので
当然、演奏終了フラグＤ３が「０」に設定されているテ
ーブルの内の最も前にあるものを選択することとなる。

【００４１】そして、Ｓ１１で演奏する曲が選択される
と、Ｓ１３へ移行して、現在の設定モードが第１モード
であるかどうかを判断する。第１モードであれば（Ｓ１
３：ＹＥＳ）、Ｓ１５へ移行する。Ｓ１５では、その曲
のリクエスト回数Ｄ１を再生時リクエスト回数Ｄ４へ入
れ、演奏終了フラグＤ３を１にする。Ｓ１５の処理の後
は、Ｓ２１へ移行して、その曲の再生指示をカラオケ再
生装置１６へ出力する。なお、Ｓ１３で否定判断、すな
わち、第２モードであった場合にはＳ１５の処理をする
ことなく、そのままＳ２１へ移行する。

【００４２】一方、Ｓ９の処理において否定判断、すな
わち未演奏のリクエスト曲がなかった場合には、Ｓ１７
へ移行して、所定条件を満たす演奏済曲があるかどうか
を判断する。この所定条件を満たす演奏済曲とは、すで
に一度は演奏されたが、演奏後にもリクエストされた曲
であり、図２のリクエストキューテーブルの演奏終了フ
ラグＤ３が「１」になっている曲でリクエスト回数Ｄ１
が再生時リクエスト回数Ｄ４を上回っている曲がそれに
該当する。例えば、図２（Ａ）のリクエストキューテー
ブルの最初にある曲番号Ｄ２が「５１３３」となってい
るテーブルの再生時リクエスト回数Ｄ４は「６」である
が、リクエスト回数Ｄ１は「１５」であるので、前回再
生した時点からさらに９回のリクエストがあったことを
示している。したがって、この場合には、曲番号「５１
３３」が該当するため、Ｓ１９へ移行し、その曲を次の
再生曲として選択し、対応する再生時リクエスト回数Ｄ
４の項目には、その時点でのリクエスト回数Ｄ１を入れ
て更新する（Ｓ１９）。

【００４３】なお、所定条件を満たすものが２つ以上あ
る場合には、例えばリクエスト回数Ｄ１から再生時リク
エスト回数Ｄ４を減算した値が最も大きいものを選択す
ればよい。Ｓ１９で曲が選択された後は、Ｓ２１へ移行
して再生指示を出す。その後は曲再生の終了待ちとなり
（Ｓ２３）、再生が終了したら（Ｓ２３：ＹＥＳ）、Ｓ
３へ戻る。

【００４４】以上説明した本実施例の放送センタ１によ
れば、リクエスト入力部１０を介して入力されたリクエ
ストはハードディスク１８のリクエスト情報記憶部１８
ａにリクエストキューテーブル形式で記憶される。そし
て、制御部１４がそのリクエストキューテーブルに記憶
されているリクエスト曲の内から次に放送するものを選
択し、その選択されたカラオケ曲をカラオケ再生装置１
６によって再生させ、放送部２０から放送する。

【００４５】このようにリクエスト応答機能を備えてい
るのであるが、制御部１４は次に放送するカラオケ曲を
選択するに際して次のような処理を実行する。すなわ
ち、リクエスト回数順に放送する第２モードに設定され
ている場合には、未演奏のリクエスト曲の中でリクエス
ト回数が最多のものを選択する。したがって、例えばカ
ラオケ曲Ａに対するリクエストが１回あった後、カラオ
ケ曲Ｂに対するリクエストが連続して３回あった場合
で、カラオケ曲ＡもＢも未演奏であった場合には、Ａで
なくＢを優先して放送することとなる。もちろん連続し
てリクエストがなくてはならない訳ではなく、例えばリ
クエストがＡ→Ｂ→Ｃ→Ｂ→Ｄ→Ｂ→Ｃという順番でな
され、Ａ〜Ｄがすべて選択候補となっていた場合には、
Ｂのリクエスト回数が３で最多なのでＢが選択される。

【００４６】このようにリクエスト時期は遅くてもリク
エストの総数が多いリクエストは優先して早く放送でき
るようにして、より多くの視聴者の希望に添ったリクエ
スト番組を提供することができる。例えば第１モードの
ように、リクエスト時期が早い順番にだけ従って放送し
てくと、番組終了直前などはリクエストの非常に少ない
（例えば１回しかない）曲を放送したために、リクエス
トが非常に多かった曲を再生しないで番組を終了してし
まうことも考えられ、視聴者全体として見た場合の要望
を満たしているとはいい難い状況が生じてしまうが、本
放送センタ１によれば、リクエストが多い曲を優先して
放送するので、視聴者全体として見た場合の要望を満た
すことができるのである。

【００４７】なお、本実施例では上述したようにリクエ
スト回数が多い順番に放送される第１モードとリクエス
ト時期が早い順番に放送される第２モードとを選択でき
るようにされている。状況によっては、リクエスト時期
が早いのに、後からなされたリクエストに対応するリク
エストが優先して放送されることによる不都合が生じる
場合も考えられるので、上述した第１のモードと第２の
モードのいずれかを外部から選択設定できるようにして
おけば便利である。例えば、２時間の番組を放送する場
合に、前半の１時間は第２モードに設定しておき、後半
の１時間は第１モードに設定することが考えられる。例
えば、番組の最初の方にリクエストをしたにもかかわら
ず、その後のリクエストが全て２回以上あったため、結
局２時間の番組中に放送されないという状況も考えられ
る。したがって、最初の１時間については第２モードに
して、あまり人気のない（つまりリクエストが少ない）
曲であってもリクエスト時期の早い順番に放送してい
き、後半の１時間については第１モードにして、上述し
たように、番組終了直前にリクエストの非常に少ない曲
のためにリクエストが非常に多い曲を放送しないで番組
を終了してしまうという不都合を防止することができ
る。

【００４８】以上、具体例に従って、本発明の実施の形
態について説明したが、本発明はこのような具体例に限
定されるものではなく、発明の要旨を逸脱しない範囲で
様々な実施ができることは言うまでもない。例えば、上
記実施例ではカラオケ番組の放送に使用する例を説明し
たが、カラオケには限定されず、例えばボーカル音入り
の通常のＢＧＭとして用いるような曲であってもよい。
さらには曲でなくても、リクエストに応じた情報を放送
するシステムであり、比較的１回のリクエストに応じた
放送時間が短いものであれば適用でき、また有効であ
る。

【図面の簡単な説明】

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

【図２】 リクエストキューテーブルのデータ構造図で
ある。

【図３】 制御部が実行する演奏制御処理を示すフロー
チャートである。

【図４】 制御部が実行する第１モードの場合のリクエ
スト受付処理を示すフローチャートである。

【図５】 制御部が実行する第２モードの場合のリクエ
スト受付処理を示すフローチャートである。

【符号の説明】

１…放送センタ １０…リクエスト入力
部 １２…選択指示部 １４…制御部 １６…カラオケ再生装置 １８…ハードディス
ク １８ａ…リクエスト情報記憶部 １８ｂ…曲データ記
憶部 ２０…放送部

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 庁内整理番号 ＦＩ 技術表示箇所 Ｈ０４Ｎ 7/173 Ｈ０４Ｎ 7/173

Claims (5)

【特許請求の範囲】
1. 【請求項１】 放送要求を要求記憶手段にデータとして
   記憶させる要求入力手段と、 前記要求記憶手段に記憶されている放送要求に応じた放
   送用情報の内から次に放送するものを選択する選択手段
   と、 該選択手段によって選択された放送用情報を放送する放
   送手段と、 を備えたリクエスト応答機能付きの放送センタにおい
   て、 前記要求入力手段によって要求記憶手段に記憶させた放
   送要求の履歴を記憶しておく要求履歴記憶手段を備え、 前記放送手段によって放送を実行している間も、前記要
   求記憶手段への放送要求の記憶及び要求履歴記憶手段へ
   の放送要求履歴の記憶を続行するよう構成されていると
   共に、 前記選択手段は、次に放送する放送用情報を選択する
   際、その時点で所定の条件を満たす選択候補の放送用情
   報が複数ある場合には、前記要求履歴記憶手段に記憶さ
   れた放送要求数がその時点で最多のものを選択すること
   を特徴とする放送センタ。
2. 【請求項２】 請求項１に記載の放送センタにおいて、 放送要求数の多い順番に放送する第１のモードと、放送
   要求時期の早い順番に放送する第２のモードとのいずれ
   かを外部から選択設定するためのモード選択手段と、 前記選択手段は、その時点で所定の条件を満たす選択候
   補の放送用情報が複数ある場合、前記第１のモードに設
   定されている場合には前記要求履歴記憶手段に記憶され
   た放送要求数がその時点で最多のものを選択し、前記第
   ２のモードに設定されている場合には前記要求記憶手段
   にデータとして記憶させた時期の最も早いものを選択す
   るように構成されていることを特徴とする放送センタ。
3. 【請求項３】 請求項１又は２に記載の放送センタにお
   いて、 前記選択手段による選択候補となり得る放送用情報の満
   たすべき所定の条件は、前記放送手段によってまだ放送
   が開始されていないものであることを特徴とする放送セ
   ンタ。
4. 【請求項４】 請求項１〜３のいずれかに記載の放送セ
   ンタにおいて、 前記要求入力手段は、電話回線を介して視聴者から個別
   になされた放送要求を受け付けて要求記憶手段にデータ
   として自動的に記憶させるものであり、放送要求を受け
   付ける際、所定のガイダンス用音声情報を電話回線を介
   して視聴者側に送信し、視聴者識別情報や放送要求内容
   識別情報等をガイダンス用音声情報に対する返答として
   受信するように構成されていることを特徴とする放送セ
   ンタ。
5. 【請求項５】 請求項１〜４のいずれかに記載の放送セ
   ンタにおいて、 前記視聴者からの放送要求は、カラオケ曲を指定した要
   求であり、 前記放送手段は、音声情報と映像情報が送信可能なテレ
   ビジョン放送手段であると共に、当該放送手段が放送す
   る放送用情報は、要求されたカラオケ曲に応じたカラオ
   ケ演奏音及び背景映像に歌詞テロップが合成された映像
   とを含むものであることを特徴とする放送センタ。