JPH10117337A - 放送センタ - Google Patents

Abstract

(57)【要約】 【課題】 視聴者からのリクエストに応じた情報の放送
開始を視聴者にコールバックする放送センタを提供す
る。 【解決手段】 放送センタ１０は、視聴者から電話機５
０を用いて個別になされたリクエストを受け付ける際、
構内交換装置１８が内線番号を管理しており、リクエス
トがなされた電話機５０の内線番号を自動的に識別し、
併せて受け付けたリクエスト予告タイミングになった
ら、その電話機５０へリクエスト開始の旨のコールバッ
クを行う。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

【０００３】このようなシステムにおけるテレビジョン
放送センタは、次々にやってくる視聴者からのリクエス
トを一時的に蓄積し、要求された順番に映像を含む放送
用情報を放送していくのであるが、当然ながらこのよう
な形態であれば、視聴者からのリクエストのスピードが
放送用情報の放送・消化のスピードを上回る事態が発生
する。すると、リクエストは蓄積してしまい、要求した
視聴者の待ち時間が長くなってしまう。例えば、リクエ
ストは所定の２時間以内にのみ受け付け、それに応じた
放送用情報の放送はその日の放送終了までに行なうとい
ったような場合、リクエストをした視聴者にとってみる
と、いつ自分のリクエストに応じたものが放送されるか
判らない。

【０００４】そのため、視聴者はリクエストした自分の
曲や情報が放送されるのをラジオやテレビ等のリクエス
ト放送可能な媒体のそばで待っている必要があった。し
かしながら、必ずしも自分が待っている時間に自分のリ
クエストした情報が放送されるとは限らず、視聴者はリ
クエストした時点から放送されるかもしれない時間中ず
っと、どこにも行かずその媒体の前に居なくてはいけな
いという事態も考えられる。つまり、自分のリクエスト
した曲でないものまで全てチェックしていなくてはなら
なくなる。

【０００５】本発明は、上述した問題点を解決するため
になされたものであり、視聴者からされたリクエストに
応じた情報の放送開始を視聴者にコールバックすること
により、利用者の便宜を向上可能な放送センタを提供す
ることを目的とする。

【０００６】

【課題を解決するための手段及び発明の効果】この目的
を達成するためになされた請求項１記載の発明は、視聴
者側の端末装置から電話回線を介して個別に送信された
リクエスト情報を受信し、リクエスト情報記憶手段にデ
ータとして自動的に記憶させるリクエスト受付手段と、
前記リクエスト情報記憶手段に記憶されているリクエス
ト情報に応じた放送用情報を、所定の順番に従って順次
放送していく放送手段とを備えたリクエスト応答機能付
きの放送センタにおいて、前記リクエスト受付手段は、
発呼してきた前記端末装置に付与されている識別情報
（端末ＩＤ）を認識可能な端末ＩＤ識別手段を備え、前
記送信されたリクエスト情報を、当該端末ＩＤ識別手段
によって認識した端末ＩＤとセットにして前記リクエス
ト情報記憶手段に記憶するよう構成され、さらに、前記
リクエスト情報記憶手段に記憶されたリクエスト情報に
応じた放送用情報の放送開始前の所定タイミングにおい
て、対応して記憶されている端末ＩＤに該当する端末装
置に対してコールバックし、放送開始を通知する放送開
始通知手段を備えていることを特徴とする放送センタで
ある。

【０００７】本発明の放送センタによれば、リクエスト
受付手段が、視聴者側の端末装置から電話回線を介して
個別に送信されたリクエスト情報をリクエスト情報記憶
手段に自動的に記憶させる。そして、放送手段が、その
リクエスト情報記憶手段に記憶されているリクエスト情
報に応じた放送用情報を、所定の順番に従って順次放送
していく。

【０００８】このような基本的なリクエスト受付及び放
送処理に加えて、本発明の放送センタは次のような処理
を実行する。すなわち、リクエスト受付手段では、端末
ＩＤ識別手段が発呼してきた端末装置に付与されている
端末ＩＤを認識し、送信されたリクエスト情報をその認
識した端末ＩＤとセットにしてリクエスト情報記憶手段
に記憶する。そして放送開始通知手段が、リクエスト情
報記憶手段に記憶されたリクエスト情報に応じた放送用
情報の放送開始前の所定タイミングにおいて、対応して
記憶されている端末ＩＤに該当する端末装置に対してコ
ールバックし、放送開始を通知する。

【０００９】視聴者にとっては、端末装置から電話回線
を介してリクエストすると、自分がリクエストした放送
用情報が放送される前にその放送が開始されることをコ
ールバックしてもらえるので、自分がリクエストした放
送用情報を見逃すことを防止できる。従来は、いつ自分
のリクエストした放送用情報が放送されるか判らないた
め、例えば放送がされる可能性のある時間中、どこにも
行かず放送されるのを待っていなくてはならなかった
が、本放送センタによれば、そのような不都合は生じな
い。そして、放送センタの端末ＩＤ識別手段によって自
動的に端末ＩＤが識別されるので、視聴者は、リクエス
トの度に、コールバックしてもらいたい自己の端末ＩＤ
を連絡する必要がなくなり、便利である。

【００１０】放送開始通知手段による放送開始の通知
は、少なくとも対応する放送用情報の放送が開始される
前に行えばよいが、例えば直前に放送開始を通知される
と準備が間に合わない状況も考えられる。但し、一律に
放送開始の５分前というような固定された時間としても
実状にそぐわない場合も考えられる。したがって、請求
項２に示すように、リクエスト受付手段が視聴者から送
信された予告タイミングの情報をリクエスト情報に対応
させて記憶するようにし、視聴者の便宜を図ることも効
果的である。なお、特に予告タイミングの指定がなけれ
ば直前に通知すればよい。また、予告タイミングについ
ては、全くの自由にするのではなく、例えば放送用情報
としてカラオケ曲に応じた情報を放送する場合には、１
曲前とか２曲前といった曲単位での選択指定が可能とす
ることが、処理の都合上からいけば好ましい。

【００１１】また、リクエスト受付手段についてさらに
言えば、例えば請求項３に示すように、視聴者からのリ
クエスト情報を受け付ける際、所定のガイダンス用音声
情報を電話回線を介して視聴者側に送信し、そのガイダ
ンス用音声情報に対する返答として、リクエスト内容識
別情報や予告タイミングの情報等を受信するように構成
することが考えられる。

【００１２】このように、リクエスト内容識別情報や予
告タイミングの情報等については、例えば視聴者が電話
機のプッシュボタンで入力するといったことが考えられ
るが、端末ＩＤはわざわざ入力しなくてもよい。本発明
の放送センタにおいては、放送センタの端末ＩＤ識別手
段が発呼してきた端末装置に付与されている端末ＩＤを
自動的に認識するからである。そして、この端末ＩＤと
しては、請求項４に示すように、端末装置毎に設定され
ている電話番号とすることが考えられる。さらに、この
ような電話番号の一例としてはいわゆる「内線電話番
号」が挙げられる。この場合、端末ＩＤ識別手段として
は、請求項５に示すように、構内交換装置における発呼
者の内線電話番号識別機能を利用して端末ＩＤを識別す
る構成とすることが考えられる。例えば、ホテルなどの
各部屋にはそれぞれ内線番号で識別する電話機が備え付
けられており、その電話機を使用すると、部屋番号など
をいちいち告げなくても構内交換装置自体をホテルが管
理しているため、内線番号を自動的に取得できる。した
がって、この内線番号を取得しておけば自動的にコール
バックすることが容易にできる。

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

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

【００１５】

【発明の実施の形態】以下、本発明の放送センタを具体
化した一実施形態を図面を参照しながら説明する。図１
は本実施形態の放送センタ１０を含むシステムの概略構
成を示すブロック図であり、ここでは、ホテル内の各部
屋に設置されたテレビ７０に対して放送するためのシス
テムとして構成されている。

【００１６】図１に示すように、放送センタ１０は、放
送センタ全体の制御を行う制御手段としてのホストコン
ピュータ１１と、外部記憶装置１２と、表示装置１３
と、カラオケ再生装置１４と、テロップ合成装置１５
と、「放送手段」としての放送手段１６と、「端末ＩＤ
識別手段」としての構内交換装置１８と、「リクエスト
受付手段」として機能する音声応答装置２０とを備えて
いる。なお、ホストコンピュータ１１と音声応答装置２
０とで「放送開始通知手段」を構成する。

【００１７】上述したように、この放送センタ１０はホ
テル内の各部屋に設置されたテレビ７０に対して放送す
るよう構成されているのであるが、各部屋には電話機５
０とテレビ７０とが備えられている。そして、各部屋の
電話機５０は内線４０を介して構内交換装置１８と接続
されており、また、各部屋のテレビ７０はＣＡＴＶ伝送
路６０を介して放送手段１６と接続されてＣＡＴＶシス
テムを構成している。

【００１８】各装置について、放送センタ１０における
役割あるいは放送システムとの関わりも含めて説明す
る。まず、音声応答装置２０は視聴者からのリクエスト
を受け付けるためのものである。放送センタ１０は視聴
者から個別になされたリクエストをＣＰＵメモリ１１ｂ
（図２参照）内に蓄積しておき、そのリクエストに基づ
くカラオケ曲を放送可能とされており、視聴者は部屋に
ある電話機５０により内線４０を通して、希望するカラ
オケ用情報をリクエストすることができる。このリクエ
ストは、予め定められた「リクエストコード」によって
行う。これは、一般のカラオケ装置における「曲番号」
と同義のものである。数字コードのよるリクエストであ
るため、実際には視聴者が電話機５０のダイヤルもしく
はプッシュホンの押し下げにより上記リクエストコード
をトーン発信する。このリクエストコードは予め視聴者
に配布物等によって通知されているものとする。

【００１９】この視聴者から通話は、放送センタ１０に
おいて構内交換装置１８を介して音声応答装置２０によ
り自動的に受理される。音声応答装置２０は内蔵された
合成音声手段（図示せず）により予め登録されたメッセ
ージを送話し、視聴者にリクエストコードの入力及び後
述する放送開始時刻の予告の必要の有無や、必要な場合
の予告タイミングと、そのガイダンスを促すものであ
り、ホストコンピュータ１１により制御され、上記した
通話の受話や各種メッセージの送話からパルスコードの
受信まで行う。

【００２０】音声応答装置２０によって受理されたリク
エストコードは、ホストコンピュータ１１により、その
リクエストコードが有効であるかどうか、外部記憶装置
１２上のデータベースとの照合により判断され、有効で
あればＣＰＵメモリ１１ｂ（図２参照）内のリクエスト
受付テーブル（図４参照）に受け付けた時刻情報とセッ
トで記憶される。

【００２１】また、構内交換装置１８は、内線番号を管
理できるため、電話機５０からの発呼があると、それが
どの内線番号の電話機５０からのものであるかを自動的
に判断することができ、その内線番号情報はホストコン
ピュータ１１のＣＰＵ１１ａに送られる。そのため、上
述のリクエスト受付テーブル（図４参照）には、さらに
内線番号もセットで記憶させることができる。

【００２２】ホストコンピュータ１１はこの記憶された
リクエストコードを基にして、所定の集計期間に該当す
るリクエスト情報を、セットで記憶されている受付時刻
情報に基づいて集計する。そして、そのリクエスト情報
の集計結果を元にして放送用テーブルを作成し、その放
送用テーブルにしたがって放送処理を実行していく。そ
の放送処理は、カラオケ再生装置１４から出力される音
声信号とテロップ合成装置１５から出力された映像信号
とが放送手段１６によってテレビジョン放送されること
となるが、この放送内容は、各部屋のテレビ７０を所定
のチャンネル（カラオケチャンネル）に設定すること
で、カラオケ番組として視聴可能である。

【００２３】表示装置１３はホストコンピュータ１１に
接続されており、これらの状況を表示することができ
る。これは、放送センタ１０のオペレータが確認するた
めに利用される。続いて、図２を参照して、ホストコン
ピュータ１１を中心とした信号の流れを説明する。図２
に示すように、音声応答装置２０はホストコンピュータ
１１のＣＰＵ１１ａと制御信号によって結ばれている。
ＣＰＵ１１ａは音声応答装置２０に対して構内交換装置
１８からの着信待ちに関する制御、着信後の同装置２０
内の音声メッセージの送話に関する制御（複数のメッセ
ージ内の選択）を行う。音声応答装置２０はホストコン
ピュータ１１に対して構内交換装置１８を通じて受信し
たダイヤルパルスを数値情報として返す。これにより、
構内交換装置１８による視聴者リクエストの自動受理を
行う。音声応答装置２０より返された数値はＣＰＵメモ
リ１１ｂに格納される。また、上述したように、構内交
換装置１８では電話機５０からの発呼があるとそれがど
の内線番号の電話機５０からのものであるかを判断し、
その内線番号情報をＣＰＵ１１ａへ送る。

【００２４】外部記憶装置１２は、リクエストコードに
関するデータベースを格納したホストコンピュータ１１
の記憶装置であり、装置間のデータの読み書きが行われ
る。これにより、ＣＰＵ１１ａはリクエストコードの検
索・照合等を行う。カラオケ再生装置１４はＣＰＵ１１
ａと制御信号により結ばれている。ＣＰＵ１１ａはカラ
オケ再生装置１４にリクエストコード（曲番号）を送信
し、同装置１４にカラオケ楽曲の再生を行わせ、またこ
の再生の開始・終了などの制御を行うことができる。ま
た、カラオケ再生装置１４は、ＣＰＵ１１ａに対して再
生の状況（再生中・再生終了等）を返す。これにより、
ＣＰＵ１１ａはリクエストコードによるカラオケ楽曲の
再生を行うことができる。

【００２５】テロップ合成装置１５は、ＣＰＵ１１ａか
ら画像の出力と合成に関する制御と、画像データの転送
を受ける。同装置１５はカラオケ再生装置１４からの映
像信号を入力しており、ＣＰＵ１１ａから転送された画
像とこの映像を合成し、カラオケ再生装置１４の出力す
る映像にテロップ表示を付加できる。

【００２６】次に、本実施形態の放送センタ１０の動作
について、図を参照して説明する。まず、視聴者からの
リクエストを受け付ける際の動作について説明する。図
３はリクエスト受付時の視聴者と放送センタ１０側との
間の通信シーケンス図であり、図４はリクエスト受付テ
ーブルの説明図である。

【００２７】放送センタ１０は、図３に示す通信シーケ
ンスに従って視聴者からリクエストを受け付ける。な
お、本実施形態では、ホテルの各部屋に備えられたテレ
ビ７０においてカラオケ番組を視聴する者という意味で
の視聴者である。一般的なＣＡＴＶシステムでは、物理
的に放送を視聴できるという意味ではなくリクエストす
る権利を有している「加入者」という意味であるが、こ
の場合はホテルの部屋を使用することに伴うサービス的
な意味合いが強く、通常は特に断わらなくても自由にリ
クエストする権利を有するものとなり得る。

【００２８】図３の通信シーケンスに戻り、視聴者が部
屋の電話機５０から放送センタ１０に対して発信・接続
すると、放送センタ１０では構内交換装置１８を介して
着信し、音声応答装置２０がその電話機５０からの着信
の応答として音声応答メッセージ（例えば「リクエスト
する曲番号を入力して下さい」といった内容）を送出す
る。

【００２９】そして、視聴者が電話機５０を介してリク
エストしたい曲番号を入力すると、そのリクエスト番号
はＣＰＵメモリ１１ｂ上のリクエスト受付テーブル（図
４）のリクエスト曲番号Ｄ３の項目として格納される。
また、この際、構内交換装置１８においては、内線番号
を管理している関係から、どの内線番号の電話機５０を
用いてのリクエストであったかが判断できる。その内線
番号情報が構内交換装置１８からＣＰＵ１１ａに送られ
るため、ＣＰＵメモリ１１ｂ上のリクエスト受付テーブ
ル（図４）の内線番号Ｄ２の項目には、その送られてき
た内線番号が格納される。

【００３０】放送センタ１０では、リクエスト受付応答
送信として、音声応答装置２０が例えば「リクエストを
受け付けました。リクエストの放送開始を知らせる必要
がある場合は１＃、必要がない場合は２＃を入力して下
さい。」という音声応答メッセージを送信することで、
リクエストを受け付けたことを応答すると共に、視聴者
側において放送開始の予告の必要があるかどうかを入力
するよう促す。

【００３１】ここで視聴者が「２＃」を入力した場合、
それを受信した放送センタ１０側では、予告の必要なし
として図４のリクエスト受付テーブルにおいては予告希
望タイミングＤ１の項目には、あり得ない値（例えば
「９９」）がセットされることとなる。この値の扱いは
後述する。

【００３２】一方、視聴者が「１＃」を入力した場合に
は、メッセージ通りに放送開始の予告の必要がある場合
であり、それを受信した放送センタ１０側では、その予
告のための個別的な情報を得るため、まず音声応答装置
２０によって、例えば「予告タイミングは放送の１曲前
から５曲前までです。「＊」入力後に、１〜５の内の希
望する数字を入力して下さい。」といった内容の音声応
答メッセージを送信する。

【００３３】これに応じて視聴者が入力した「＊」と何
曲前に予告してほしいか（１〜５までのいずれかの数
字）が電話機５０を介しての放送センタ１０へ送信され
る。予告希望タイミングを受信した放送センタ１０は、
先のリクエスト曲番号Ｄ３とともに、図４のリクエスト
受付テーブルの予告希望タイミングＤ１の項目に格納さ
れる。

【００３４】こうして、放送開始を予告するための詳細
情報が得られた場合には、視聴者への受付確認のため、
音声応答装置２０が例えば「放送の？（加入者が入力し
た値）曲前にお知らせします。リクエストありがとうご
ざいました。」といった内容の音声応答メッセージを送
信する。

【００３５】その後さらに、リクエスト受付年月日Ｄ４
及び受付時分秒Ｄ５の２項目を加え、図４に示すリクエ
スト受付テーブルの全ての項目（Ｄ１〜Ｄ５）が格納さ
れることとなる。次に、放送開始の通知に関する動作に
ついて説明する。図５は、ＣＰＵ１１ａによって実行さ
れるプログラムの処理手順を示すフローチャートであ
る。

【００３６】なお、図５に示す処理の前提を説明してお
く。前提としては、１日に１回リクエスト曲を放送する
番組があり、その番組で放送する曲は、過去のリクエス
トを基に自動的に決定したものか、あるいは番組作成者
がリクエストの中から適宜選択して決定したものであ
る。

【００３７】まず、最初のステップＳ１０においては、
リクエスト受付テーブル（図４）から本日の番組中に放
送予定の曲に該当する曲番号をリクエスト曲番号Ｄ３と
して持つリクエストデータを全て取得する。例えば、同
じ曲について複数のリクエストがされている場合には、
それぞれ一つのリクエストデータとして取得する。した
がって、番組中での放送予定は１０曲の場合でも、該当
するリクエストデータは、２０や３０といった多数にな
る場合も考えられる。なお、この場合に取得するリクエ
ストデータは、図４に示す項目の内の予告希望タイミン
グＤ１と内線番号Ｄ２とリクエスト曲番号Ｄ３の３つの
項目だけでよい。

【００３８】そして、続くＳ２０では、Ｓ１０において
取得したリクエストデータについての予告希望タイミン
グＤ１として設定されている何曲前かという情報（本実
施形態では１〜５のいずれか）と、その曲を放送する順
番との関係に基づいて、放送順番を基準として「何曲目
の前に予告するか」という予告タイミングを算出し、そ
の予告タイミングの早い順番に並べ替える。その結果、
図６に示すように、予告タイミングＤ１１とそれに対応
する告知先内線番号Ｄ１２及び予告希望タイミングＤ１
３のデータによって予告用テーブルが作成されることと
なる。

【００３９】予告タイミングＤ１１の数字は、設定され
た放送順番を基準とした何曲目の放送の前に予告するか
を示すものである。また、告知先内線番号Ｄ１２は、そ
の予告タイミングを希望していたリクエスト者に対応す
る内線番号であり、複数が該当することもある。そし
て、予告タイミングＤ１１が同じでも複数の告知先内線
番号Ｄ１２が該当することがあり、予告希望タイミング
Ｄ１３は告知先内線番号Ｄ１２分だけ存在することとな
る。つまり、５番目の放送順番の曲が、予告希望タイミ
ングＤ１を１曲前として内線番号１０１からリクエスト
されており、また６番目の放送順番の曲が、予告希望タ
イミングＤ１を２曲前として内線番号１０２からリクエ
ストされていた場合には、共に４番目の放送順番の曲の
前が予告タイミングであるため、図６の予告タイミング
Ｄ１１の４曲目の前に対応する告知先内線番号として
は、「１０１」と「１０２」が設定されることとなる。

【００４０】なお、視聴者から予告の必要なしと指示さ
れた場合には、図４のリクエスト受付テーブルにおいて
は予告希望タイミングＤ１の項目に例えば「９９」とい
うあり得ない値がセットされることを説明した。この値
の扱いを説明する。Ｓ１０では、当然このような「９
９」という予告希望タイミングＤ１を持つリクエストデ
ータも取得されるのであるが、Ｓ２０において除外され
ることとなる。つまり、Ｓ２０では、予告希望タイミン
グＤ１として設定されている何曲前かという情報（１〜
５のいずれか）と、その曲を放送する順番との関係に基
づいて「何曲目の前に予告するか」を算出するのである
が、その際、予告希望タイミングＤ１として１〜５以外
が設定されている場合は除外するようにすればよい。

【００４１】Ｓ３０では、そのテーブル（図６）より最
初のデータを読み出し、続くＳ４０にて、予告タイミン
グになったかどうかを判断する。予告タイミングになっ
た場合には（Ｓ４０：ＹＥＳ）、Ｓ５０へ移行して、該
当する告知先に対して通知する。これは、告知先内線番
号Ｄ１２として設定されている内線番号に対して構内交
換装置１８を介してコールバックし、所定の予告メッセ
ージを通知する。この予告メッセージは、例えば「放送
開始の（予告希望タイミングＤ１３に設定されている
値）曲前です。ご準備下さい。」といったような内容で
ある。告知先に応じて予告希望タイミングＤ１３に設定
されている値が異なる場合あるので、それぞれ個別に予
告することとなる。例えば図６の予告用テーブルの予告
タイミングＤ１１が「１」の場合、すなわち、最初の曲
を放送する前には、内線番号が「１０８」のものについ
ては３曲前であることを通知し、内線番号が「１１１」
のものについては１曲前であることを通知し、内線番号
が「３１５」のものについては２曲前であることをそれ
ぞれ通知することとなる。

【００４２】このＳ５０での通知処理後はＳ６０へ移行
し、最後のリクエストデータかどうかを判断する。この
場合には最後ではないので（Ｓ６０：ＮＯ）、Ｓ７０へ
移行し、図６のテーブルより次のデータを読み出し、Ｓ
４０へ移行する。このようにして、図６のテーブルにお
ける最後のリクエストデータについての通知処理が終了
した場合には（Ｓ６０：ＹＥＳ）、本処理を終了する。

【００４３】以上説明したように、本実施形態の放送セ
ンタ１０は視聴者から電話機５０を用いて個別になされ
たリクエストを受け付けるのであるが、構内交換装置１
８が内線番号を管理しているので、リクエストがされた
電話機５０の内線番号を自動的に識別することができ
る。したがって、視聴者からはリクエスト曲番号及び必
要であればリクエストを予告する場合の予告希望タイミ
ングを取得すれば、使用している内線番号などを視聴者
から直接連絡してもらわなくても、リクエストに応じた
曲の放送開始前に視聴者に通知することが可能となる。

【００４４】視聴者にとっては、電話機５０から内線４
０を介してリクエストすると、自分がリクエストした曲
の放送される前の希望したタイミングにその放送が開始
されることをコールバックしてもらえるので、自分がリ
クエストした曲を見逃す（聞逃す）ことを防止できる。
従来は、いつ自分のリクエストした曲が放送されるか判
らないため、例えば放送がされる可能性のある時間中、
どこにも行かず放送されるのを待っていなくてはならな
かったが、本放送センタ１０によれば、そのような不都
合は生じない。

【００４５】なお、本実施形態では、放送開始の通知を
行なう予告タイミングとして、１曲前から５曲前までの
いずれかを選択できるようにしている。理論的にはリク
エスト曲の放送が開始される前に行えばよいが、例えば
直前に放送開始を通知されると準備が間に合わない状況
も考えられる。そうかといって一律に放送開始の５分前
というような固定された時間としても実状にそぐわない
場合も考えられる。したがって、本実施形態では、１曲
前から５曲前までのいずれかという曲単位ではあるが、
視聴者が選択できるようにしたのである。

【００４６】以上、具体例に従って、本発明の実施形態
について説明したが、本発明はこのような具体例に限定
されるものではなく、発明の要旨を逸脱しない範囲で様
々な実施ができることは言うまでもない。例えば、上記
実施形態においては、視聴者側の端末装置として電話機
５０を例にとったが、これは、ホテルの各部屋には元々
カラオケ以外のサービスをフロントの要求したり、ある
いは外線と接続する一般的な電話機として用いる電話機
が備わっていることが多いため、そのような既存設備を
利用できるという点を考慮したものである。

【００４７】またこの実施形態は、各電話機５０が内線
４０で構内交換装置１８と接続されているため、構内交
換装置１８が内線番号を管理でき、その内線番号情報を
ホストコンピュータ１１が自由に利用できることを前提
としたものであった。しかしこのような構内交換装置１
８を備えるような放送センタでないと実現できないので
はなく、電話回線を管理する交換装置から電話番号情報
を取得できるような構成であれば同様に実現可能であ
る。その意味では、加入電話回線（いわゆる外線）を用
いたシステムとして構成した場合であっても、放送セン
タがその交換装置から電話番号情報を取得できる構成を
備えていればよい。

【００４８】また、上記実施形態では、放送予定曲は番
組の放送開始前に決定されているという前提であった
が、例えば視聴者からのリクエストを随時受け付けなが
ら、番組もそれと並行して長時間放送する場合もある。
この場合には、リクエストした曲がすぐに、あるいは１
曲待てば実際に番組中で放送されるという場合も考えら
れる。すなわちリクエストした後で即座に放送予定が決
定可能な場合には、その場で通知することも考えられ
る。したがって、例えば図３で放送センタ１０が曲番号
を受信した後の音声応答メッセージとして、「リクエス
トを受け付けました。なお、リクエストされた曲はこの
後すぐに（あるいは１曲後に）放送されますので、しば
らくお待ち下さい。」といった内容を通知すればよい。
そして、リクエストが多く、その時点で即座には放送予
定が決定できない場合には、上記説明通り予告の必要が
あるかどうかの伺いをして、視聴者の希望を聞くように
すればよい。

【００４９】また、上記実施形態では、カラオケ番組の
放送に使用する例を説明したが、本発明は放送用情報を
供給するサーバ側が少数であり、リクエストする視聴者
側が多数であり、両者が遠隔である等の理由で、放送と
いう情報供給形態を採用する状況であることが応用の主
旨である。したがって、放送する情報としてもカラオケ
曲以外に、カラオケ用でなく聞くための曲という意味で
の「通常の」曲でもよい。そしてその場合には、映像は
なく音声情報だけであってもよい。一方、映画等も考え
られるが、映画の場合には１つが長時間となるので、上
記「番組」の放送開始時間というのではなく、その映画
作品自体の放送開始時間を通知することが好ましい。

【図面の簡単な説明】

【図１】 実施形態の放送センタを含むシステムの概略
構成を示すブロック図である。

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

【図３】 リクエスト受付時の視聴者側と放送センタ側
との間の通信シーケンスを示す説明図である。

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

【図５】 ホストコンピュータが実行する放送開始の通
知処理を示すフローチャートである。

【図６】 ホストコンピュータが放送開始の通知処理に
おいて取り扱う予告用テーブルのデータ構成図である。

【符号の説明】

１０…放送センタ １１…ホストコンピュー
タ １１ｂ…ＣＰＵメモリ １２…外部記憶装置 １３…表示装置 １４…カラオケ再生装置 １５…テロップ合成装置 １６…放送手段 １８…構内交換装置 ２０…音声応答装置 ４０…内線 ５０…電話機 ６０…ＣＡＴＶ伝送路 ７０…テレビ

Claims (6)

【特許請求の範囲】
1. 【請求項１】 視聴者側の端末装置から電話回線を介し
   て個別に送信されたリクエスト情報を受信し、リクエス
   ト情報記憶手段にデータとして自動的に記憶させるリク
   エスト受付手段と、前記リクエスト情報記憶手段に記憶
   されているリクエスト情報に応じた放送用情報を、所定
   の順番に従って順次放送していく放送手段とを備えたリ
   クエスト応答機能付きの放送センタにおいて、 前記リクエスト受付手段は、発呼してきた前記端末装置
   に付与されている識別情報（以下、端末ＩＤと称す。）
   を認識可能な端末ＩＤ識別手段を備え、前記送信された
   リクエスト情報を、当該端末ＩＤ識別手段によって認識
   した端末ＩＤとセットにして前記リクエスト情報記憶手
   段に記憶するよう構成され、 さらに、前記リクエスト情報記憶手段に記憶されたリク
   エスト情報に応じた放送用情報の放送開始前の所定タイ
   ミングにおいて、対応して記憶されている端末ＩＤに該
   当する端末装置に対してコールバックし、放送開始を通
   知する放送開始通知手段を備えていることを特徴とする
   放送センタ。
2. 【請求項２】 前記リクエスト受付手段は、視聴者から
   送信された予告タイミングの情報を前記リクエスト情報
   に対応させて記憶するように構成されていることを特徴
   とする請求項１に記載の放送センタ。
3. 【請求項３】 前記リクエスト受付手段は、視聴者から
   のリクエスト情報を受け付ける際、所定のガイダンス用
   音声情報を電話回線を介して視聴者側に送信し、そのガ
   イダンス用音声情報に対する返答として、リクエスト内
   容識別情報あるいは前記予告タイミングの情報等を受信
   するように構成されていることを特徴とする請求項１又
   は２に記載の放送センタ。
4. 【請求項４】 前記端末ＩＤは、電話番号であることを
   特徴とする請求項１〜３のいずれかに記載の放送セン
   タ。
5. 【請求項５】 前記端末ＩＤ識別手段は、構内交換装置
   における発呼者の内線電話番号識別機能を利用して端末
   ＩＤを識別する構成であることを特徴とする請求項４に
   記載の放送センタ。
6. 【請求項６】 前記視聴者からのリクエスト情報はカラ
   オケ曲を指定したリクエストであり、前記放送手段は、
   音声情報と映像情報が送信可能なテレビジョン放送手段
   であると共に、当該放送手段が放送する放送用情報は、
   要求されたカラオケ曲に応じたカラオケ演奏音及び背景
   映像に歌詞テロップが合成された映像とを含むものであ
   ることを特徴とする請求項１〜５のいずれかに記載の放
   送センタ。