JPH09205636A - 放送センタ - Google Patents

Abstract

(57)【要約】 【課題】 視聴者からのリクエストに応じた情報の放送
開始時刻を視聴者に前もって告知する。 【解決手段】 ＣＰＵ１１ａは、ＣＰＵメモリ１１ｂ内
のリクエスト受付テーブルからリクエストデータを取得
し、予告タイミング設定時間の大きい順に並び替える。
そして、番組開始までの待ち時間を取得し、予告タイミ
ングよりも大きければ、告知先に公衆電話回線４０を介
して電話機から音声メッセージとして通知する。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

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

【０００４】そのため、次のような不都合が生じる。す
なわち、視聴者はリクエストした自分の曲や情報が放送
されるのをラジオやテレビ等のリクエスト放送可能な媒
体のそばで待っている必要があった。しかしながら、必
ずしも自分が待っている時間あるいは日に自分のリクエ
ストした情報が放送されるとは限らず、視聴者はリクエ
ストした時点から放送されるかもしれない時間中ずっ
と、どこにも行かずその媒体の前に居なくてはいけない
という事態も考えられる。また、急に人と会う約束等が
できて外出したりする場合、放送番組をビデオレコーダ
等の録画・録音できる媒体を用いて予約録画・録音して
おくことも考えられるが、録画・録音後に実際に視聴し
てみると、結局のところ自分のリクエストした情報が放
送されていなかいこともあり、その場合は、ただ無駄に
ビデオテープやカセットテープを使った上、自分が希望
するリクエストに対応する情報もないので、それらを視
聴している時間は大変無駄となってしまう。

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

【０００６】

【課題を解決するための手段及び発明の効果】この目的
を達成するためになされた請求項１記載の発明は、視聴
者から個別になされたリクエスト情報を記憶しておくリ
クエスト情報記憶手段と、該リクエスト情報記憶手段に
記憶されているリクエスト情報に応じた放送用情報を、
所定の順番に従って順次放送していく放送手段とを備え
たリクエスト応答機能付きの放送センタにおいて、前記
リクエスト情報記憶手段は、リクエスト情報に応じた放
送用情報又は該放送用情報が含まれている放送番組の放
送開始時刻を予告するタイミング及びその告知先の情報
も記憶可能であり、さらに、前記リクエスト情報記憶手
段に記憶されているリクエスト情報毎に、該リクエスト
情報に応じた放送用情報又は該放送用情報が含まれてい
る放送番組の放送開始時刻を予告する必要があるかどう
かを判断する判断手段と、該判断手段によって放送開始
時刻について予告する必要があると判断された場合に
は、前記リクエスト情報記憶手段に記憶されている予告
タイミングに基づいて、該当する告知先に放送開始時刻
を通知する放送開始時刻通知手段とを備えていることを
特徴とする放送センタである。

【０００７】本発明の放送センタによれば、視聴者から
個別になされたリクエスト情報をリクエスト情報記憶手
段が記憶しており、放送手段が、そのリクエスト情報記
憶手段に記憶されているリクエスト情報に応じた放送用
情報を、所定の順番に従って順次放送していく。

【０００８】このような基本的な放送処理に加えて、次
のような処理を実行する。すなわち、リクエスト情報記
憶手段は、リクエスト情報に応じた放送用情報又は該放
送用情報が含まれている放送番組の放送開始時刻を予告
するタイミング及びその告知先の情報も記憶可能であ
り、判断手段が、リクエスト情報記憶手段に記憶されて
いるリクエスト情報毎に、該リクエスト情報に応じた放
送用情報又は該放送用情報が含まれている放送番組の放
送開始時刻を予告する必要があるかどうかを判断する。
そして、放送開始時刻について予告する必要があると判
断された場合には、放送開始時刻通知手段が、リクエス
ト情報記憶手段に記憶されている予告タイミングに基づ
いて、該当する告知先に放送開始時刻を通知する。

【０００９】視聴者にとっては、自分がリクエストした
放送用情報又は該放送用情報が含まれている放送番組が
放送される前にその放送開始時刻を通知してもらえるの
で、自分がリクエストした放送用情報を見逃すことを防
止できる。そして、従来は、いつ自分のリクエストした
放送用情報が放送されるか判らないため、例えば放送が
される可能性のある時間中、どこにも行かず放送される
のを待っていなくてはならなかったり、放送番組をビデ
オレコーダ等によって録画したにもかかわらず、録画後
に実際に視聴してみると、結局のところ自分のリクエス
トした情報が放送されていないといったことも生じる
が、本放送センタによれば、そのような不都合は生じな
い。

【００１０】また、視聴者からのリクエストを受け付け
る場合には、放送センタ側のオペレータが視聴者からの
リクエスト情報を聞き、それをマニュアルでリクエスト
情報記憶手段に記憶させるようにしてもよい。また、リ
クエストの受付を自動化し、放送センタ側においてオペ
レータ等の人手を全く介さないシステムとして構築する
ことも可能である。

【００１１】このように人手を介さずに自動的にリクエ
スト情報を記憶させるものとしては、例えば請求項２に
示すものが考えられる。その構成は、請求項１に記載の
放送センタにおいて、視聴者から個別に送信されたリク
エスト情報を受信し、前記リクエスト情報記憶手段にデ
ータとして自動的に記憶させるリクエスト受付手段を備
えており、該リクエスト受付手段は、視聴者から送信さ
れた予告タイミング及び告知先の情報をリクエスト情報
に対応させて記憶するようにしたものである。

【００１２】この場合、例えば請求項３に示すように、
リクエスト受付手段は、視聴者からのリクエスト情報を
受け付ける際、所定のガイダンス用音声情報を電話回線
を介して視聴者側に送信し、そのガイダンス用音声情報
に対する返答として、視聴者識別情報やリクエスト内容
識別情報、あるいは前記予告タイミングや告知先の情報
等を受信するように構成し、前記放送開始時刻通知手段
は、前記電話回線を介して、該当する告知先に放送開始
時刻を通知するよう構成することが考えられる。

【００１３】もちろん、電話回線以外にも専用の通信回
線等を使用しても実現できるが、電話回線の場合には既
存のものを利用できるという利点もある。そしてこの場
合には、例えば視聴者からの電話を自動着信し、電子音
声による案内を行う音声応答機能と、電話によるダイヤ
ルトーンを使用したコードの発信を受信するコード受信
機能を備え、音声応答機能によって所定のガイダンス音
声を流し、それにしたがって視聴者が例えば要求するカ
ラオケの曲番号や視聴者識別番号等をプッシュボタン等
で入力し、それをダイヤルトーンを使用したコードとし
て受信するようにすれば便利である。

【００１４】なお、予告タイミングについては、例えば
一律に放送開始時刻の１時間前といったように固定して
もよいが、視聴者の都合によって、ある人は１時間前で
よいが、別の人にとっては３時間前に通知して欲しいと
いう場合もある。そのため、予告タイミングも視聴者側
から指定できるようにしておくことが好ましい。また、
同様に告知先についても、ある人にとっては自宅の電話
がよいが、別の人にとっては携帯電話やさらには無線呼
出し受信機（いわゆるポケットベル）に連絡して欲しい
場合もある。そのため、告知先も視聴者側から指定でき
るようにしておく始ことが好ましい。

【００１５】したがって、その告知先の情報は、例えば
請求項４に示すように電話番号とすることが代表的な例
として考えられる。電話番号であれば、いわゆる宅内電
話機や携帯電話機はもちろん、上述したポケットベルや
さらにはファクシミリにも適用できる。なお、放送開始
時刻を通知する場合、電話機であれば音声でその内容を
通知し、ファクシミリであれば文字でその内容を通知す
ればよい。また、ポケットベルの場合にも、送信したメ
ッセージを受信して表示できる機能を備えたものがある
ので、その場合には文字で表示すればよい。また、メッ
セージを表示できない場合でも、呼出し先の区別によっ
て判断は可能である。

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

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

【００１８】

【発明の実施の形態】以下、本発明の放送センタを具体
化した一実施例を図面を参照しながら説明する。図１は
本実施例の放送センタ１０の概略構成を示すブロック図
である。図１に示すように、放送センタ１０は、放送セ
ンタ全体の制御を行う制御手段であり「判断手段」及び
「放送開始時刻通知手段」としてのホストコンピュータ
１１と、「リクエスト情報記憶手段」としての外部記憶
装置１２と、表示装置１３と、カラオケ再生装置１４
と、テロップ合成装置１５と、「放送手段」としての放
送手段１６と、「リクエスト受付手段」及び「放送開始
時刻通知手段」としての音声応答装置２０とを備えてい
る。また、放送センタ１０は、公衆電話回線４０を介し
て多数の電話機５０と接続されている。なお、公衆電話
回線４０を介しているので、電話機５０以外にも例えば
無線呼出し受信機（以下、通称である「ポケットベル」
と記す。）６０とも接続可能である。

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

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

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

【００２２】ホストコンピュータ１１はこの記憶された
リクエストコードを基にして、所定の集計期間に該当す
るリクエスト情報を、セットで記憶されている受付時刻
情報に基づいて集計する。そして、リクエスト情報の集
計結果として例えばリクエスト総数を含む結果情報を算
出し、任意のメッセージとして表示すべき文字列を生成
する。生成されたメッセージは、外部記憶装置１２内の
フォントデータによって画像データとしてホストコンピ
ュータ１１のＣＰＵメモリ１１ｂに展開され、テロップ
合成装置１５に転送される。

【００２３】テロップ合成装置１５から出力された映像
信号はカラオケ再生装置１４から出力される音声信号と
共に、放送手段１６によってテレビジョン放送される。
この放送内容は、視聴者側のテレビジョン受信機などの
受信設備にて受信され、視聴可能である。

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

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

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

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

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

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

【００３０】放送センタ１０は、図３に示す通信シーケ
ンスに従って視聴者からリクエストを受け付ける。な
お、このリクエストできる視聴者は、単にこの放送セン
タ１０からの放送を視聴できるという意味ではなく、リ
クエストする権利を有している「加入者」という意味で
ある。例えばＣＡＴＶシステムで、そのシステムに加入
する際に自動的にリクエストの権利も与えられる場合に
は、全てがここでいう「加入者」となる。なお、通常の
無線形式で放送する場合には、例えばリクエストをする
代わりに所定の料金を徴収するような契約を別個に行な
うことが考えられる。その場合には、契約をした人だけ
がここでいう「加入者」となる。なお、以下の説明で
は、特に断わらない限り、加入者の意味で視聴者という
言葉を使用する。

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

【００３２】そして、視聴者が電話機５０を介してリク
エストしたい曲番号を入力すると、そのリクエスト番号
はＣＰＵメモリ１１ｂ上のリクエスト受付テーブル（図
４）のリクエスト曲番号Ｄ３の項目として格納される。
放送センタ１０では、リクエスト受付応答送信として、
音声応答装置２０が例えば「リクエストを受け付けまし
た。リクエストの放送時間を知らせる必要がある場合は
１＃、必要がない場合は２＃を入力して下さい。」とい
った内容の音声応答メッセージを送信することで、リク
エストを受け付けたことを応答すると共に、視聴者側に
おいて放送開始時刻の予告の必要があるかどうかを入力
するよう促す。

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

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

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

【００３６】続いて、音声応答装置２０によって、例え
ば「放送前の？（加入者が入力した値）時間前にお知ら
せします。希望するお知らせ先を＊入力後、入力して下
さい。」といった内容の音声応答メッセージを送信す
る。これに応じて視聴者は希望する電話番号を入力し、
この番号が電話機５０を介しての放送センタ１０へ送信
される。受信した放送センタ１０は、この送信されてき
た電話番号を図４のリクエスト受付テーブルの告知先Ｄ
２の項目に格納する。この告知先Ｄ２としての電話番号
は、そのリクエストに用いている電話機に対応する電話
番号でもよいし、また別の携帯電話の番号やポケットベ
ルの番号であってもよい。

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

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

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

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

【００４１】そして、続くＳ２０では、Ｓ１０において
取得したリクエストデータを、さらに予告タイミングＤ
１に基づき、予告タイミングＤ１として設定されている
時間の値が大きい順に並べ替える。本実施例ではこの予
告タイミングＤ１は１時間刻みの設定とされている。Ｓ
１０で取得したリクエストデータをＳ２０にて並び替え
た状態のテーブルの一例を図６に示す。

【００４２】Ｓ３０では、そのテーブル（図６）より最
初のデータを読み出し、続くＳ４０にて、通知の必要が
あるかどうかを判断する。例えば、図６に示すテーブル
の最初のリクエストデータは、予告タイミングＤ１が
「９９：９９：９９」、告知先Ｄ２が「９９９９−９９
−９９９９」とされている。これは上述したように、リ
クエストする際に視聴者が放送開始時刻の予告の必要が
ないとして「２＃」を入力をすると設定される値であ
る。したがって、予告タイミングＤ１や告知先Ｄ２に上
記値が設定されている場合には通知の必要がないと判断
し（Ｓ４０：ＮＯ）、Ｓ８０へ移行する。

【００４３】Ｓ８０では、最後のリクエストデータかど
うかを判断する。この場合には最後ではないので（Ｓ８
０：ＮＯ）、Ｓ９０へ移行し、図６のテーブルより次の
リクエストデータを読み出し、Ｓ４０へ移行する。図６
のテーブルにおける２番目のリクエストデータは、予告
タイミングＤ１や告知先Ｄ２の値からＳ４０にて肯定判
断、すなわち通知の必要があると判断されてＳ５０へ移
行する。

【００４４】Ｓ５０では、番組開始までの待ち時間を取
得する。番組の放送開始予定時刻については外部記憶装
置１２に記憶されているので、その放送開始予定時刻か
ら現在時刻を差し引くことで上記「待ち時間」が得られ
る。続くＳ６０では、Ｓ３０又はＳ４０で読み込んだリ
クエストデータ中の予告タイミングＤ１がＳ５０で得た
待ち時間よりも大きいかどうかを判断する。予告タイミ
ングＤ１が待ち時間以下の場合には、視聴者が通知して
欲しいタイミングをまだ過ぎていないので（Ｓ６０：Ｎ
Ｏ）、Ｓ５０へ戻る。このようにして、該当する予告タ
イミングＤ１が待ち時間よりも大きくなった場合には、
視聴者が通知して欲しいタイミングを過ぎているので
（Ｓ６０：ＹＥＳ）、Ｓ７０に移行して、該当する告知
先Ｄ２に対して通知する。

【００４５】具体的には、その該当する告知先Ｄ２に公
衆電話回線４０を介してアクセスし、例えばそれが電話
機５０（図１参照）であれば、番組の放送開始時間が近
づいてることを音声メッセージとして通知する。なお、
番組の放送開始予定時刻は既に判っているので、「○時
から番組が始まります。」あるいは「○時から始まる番
組であなたのリクエストした曲が放送されます。是非、
リクエストされた曲を視聴できる場所へお戻り下さ
い。」といったメッセージを予め準備しておいて流すよ
うにしてもよい。

【００４６】そして、Ｓ７０での通知処理の後は、Ｓ８
０へ移行し、図６のテーブルの最後のリクエストデータ
となるまで上述した処理を繰り返す。例えば図６のテー
ブルにおいて３番目のリクエストデータは、２番目のリ
クエストデータと同様に予告タイミングＤ１が「０３：
００：００」となっているので、すぐにＳ６０で肯定判
断となり、Ｓ７０にて、その該当する告知先へ通知す
る。そして、４番目のリクエストデータの予告タイミン
グＤ１は「０２：００：００」であるので、約１時間後
にＳ７０の通知処理が実行されることとなる。

【００４７】このようにして、図６のテーブルにおける
最後のリクエストデータについての通知処理が終了した
場合には（Ｓ８０：ＹＥＳ）、本処理を終了する。以上
説明したように、本実施例の放送センタ１０によれば、
視聴者から個別に送信されるリクエストを受信し、リク
エスト情報を受けた時点でリクエストを予告する場合の
予告タイミングや告知先の詳細情報を得て、それらをデ
ータとしてホストコンピュータ１１内に保管し、そのデ
ータを基にそのリクエストに応じた曲が放送される番組
の放送開始前に視聴者に通知することが可能となる。こ
れにより、加入者は自分のリクエストした曲を見逃すこ
となく視聴することができるようになる。

【００４８】つまり、視聴者にとっては、自分がリクエ
ストした曲が放送予定となっている番組の放送前にその
放送開始時刻を通知してもらえるので、自分がリクエス
トした曲を見逃すことを防止できる。そして、従来は、
いつ自分のリクエストした曲が放送されるか判らないた
め、例えば毎日番組が放送される度に、どこにも行かず
放送されるのを待っていなくてはならなかったり、放送
番組をビデオレコーダ等によって録画したにもかかわら
ず、録画後に実際に視聴してみると、結局のところ自分
のリクエストした情報が放送されていないといったこと
も生じるが、本放送センタ１０によれば、そのような不
都合は生じない。

【００４９】なお、予告タイミングについては、例えば
一律に放送開始時刻の１時間前といったように固定して
もよいが、視聴者の都合によって、ある人は１時間前で
よいが、別の人にとっては３時間前に通知して欲しいと
いう場合もある。そのため、本実施例のように、予告タ
イミングも視聴者側から指定できるようにしておくこと
が好ましい。また、同様に告知先についても、ある人に
とっては自宅の電話機５０がよいが、別の人にとっては
ポケットベル６０に連絡して欲しい場合もある。そのた
め、告知先も視聴者側から指定できるようにしておくこ
とが好ましい。

【００５０】したがって、その告知先の情報としては、
本実施例に示すように電話番号とすることが代表的な例
として考えられる。電話番号であれば、いわゆる宅内電
話機や携帯電話機はもちろん、上述したポケットベルや
さらにはファクシミリにも適用できる。なお、放送開始
時刻を通知する場合、上記実施例の電話機５０であれば
音声でその内容を通知し、ファクシミリであれば文字で
その内容を通知すればよい。また、ポケットベル６０の
場合にも、送信したメッセージを受信して表示できる機
能を備えたものがあるので、その場合には文字で表示す
ればよい。また、メッセージを表示できない場合でも呼
出し先の区別によって判断は可能である。

【００５１】以上、具体例に従って、本発明の実施形態
について説明したが、本発明はこのような具体例に限定
されるものではなく、発明の要旨を逸脱しない範囲で様
々な実施ができることは言うまでもない。例えば、リク
エスト告知先も実施例においては、単に電話番号のみと
しているが、電話機に限らない、電話番号からポケット
ベル等の判断がつくため、各機能に合った告知の方法も
取ることができる。ポケットベルの場合なら、メッセー
ジ表示可能なものであればその旨を送信して加入者に告
知することもできる。なお、電話番号を用いた告知先と
してはファクシミリも考えられる。告知先としてファク
シミリであることを記憶しておけば、ファクシミリ用の
情報を送信することも可能である。

【００５２】また、上記図５に示した処理の前提は、１
日に１回リクエスト曲を放送する番組があり、その番組
で放送する曲は、過去のリクエストを基に自動的に決定
したものか、あるいは番組作成者が適宜選択して予め決
定しておくというものであった。そのような限定された
システムでなく、種々の形態が考えられる。例えば放送
番組が１日に複数回、例えば１回目が１０：００〜１
２：００、２回目が１５：００〜１７：００、３回目が
２０：００〜２２：００というように３回ある場合も考
えられる。この場合には、それぞれの番組での放送予定
曲が判るので、上記図５のＳ５０で番組開始までの待ち
時間を取得する場合に、何回目の番組かを区別してその
放送開始時刻情報に基づいて計算すればよい。したがっ
て、例えばＳ７０での通知をしていく場合、１回目の番
組でのある放送予定曲Ａのリクエストデータの予告タイ
ミングＤ１が「０１：００：００」であり、２回目の番
組でのある放送予定曲Ｂのリクエストデータの予告タイ
ミングＤ１が「０７：００：００」であった場合には、
先に２回目の番組での放送予定曲Ｂに対しての通知を行
い、その約１時間後に１回目の番組での放送予定曲Ａに
対しての通知を行うという場合もあり得る。

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

【００５４】さらに、上記実施例では、リクエストした
曲が放送予定の「番組」の放送開始時刻を通知するよう
にしたが、曲毎の放送予定時刻が判っている場合には、
曲毎に予告タイミングを判断し、「あなたのリクエスト
した曲は、○時○分から放送されます」というように細
かく通知するようにしてもよい。

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

【図面の簡単な説明】

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

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

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

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

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

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

【符号の説明】

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

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

Claims (5)

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