JP3696961B2

JP3696961B2 - 放送センタ

Info

Publication number: JP3696961B2
Application number: JP01192396A
Authority: JP
Inventors: 道子榎本
Original assignee: Brother Industries Ltd; Xing Inc
Current assignee: Brother Industries Ltd; Xing Inc
Priority date: 1996-01-26
Filing date: 1996-01-26
Publication date: 2005-09-21
Anticipated expiration: 2016-01-26
Also published as: JPH09205636A

Description

【０００１】
【発明の属する技術分野】
本発明は、視聴者から個別になされたリクエストに応じた放送用情報を、所定の順番に従って放送していくリクエスト応答機能付きの放送センタに関する。
【０００２】
【従来の技術及び発明が解決しようとする課題】
現在、ＣＡＴＶシステム等のローカルなテレビジョン放送センタと加入者端末との間において、双方向テレビジョンと呼ばれるＴＶ放送の新しい形態が普及しつつある。ただし、これらは一般にビデオ・オン・デマンド（ＶＯＤ）と呼ばれる視聴者があたかも自宅のビデオデッキで好みの映像を視聴しているかのように映像を宅配するシステムとは違い、あくまでも不特定多数に映像を発信する「放送」の枠を出ていない。つまり、視聴者から個別になされたリクエストを蓄積しておき、そのリクエストに応じた放送用情報を、所定の順番に従って順次放送していくという限定的な双方向テレビジョンシステムである。
【０００３】
このようなシステムにおけるテレビジョン放送センタは、次々にやってくる視聴者からのリクエストを一時的に蓄積し、要求された順番に映像を含む放送用情報を放送していくのであるが、当然ながらこのような形態であれば、視聴者からのリクエストのスピードが放送用情報の放送・消化のスピードを上回る事態が発生する。すると、リクエストは蓄積してしまい、要求した視聴者の待ち時間が長くなってしまう。例えば、リクエストは所定の２時間以内にのみ受け付け、それに応じた放送用情報の放送はその日の放送終了までに行なうとか、２４時間受け付け、受け付けた時点から１週間以内のどこかで放送するといったような場合、リクエストをした視聴者にとってみると、いつ自分のリクエストに応じたものが放送されるか判らない。
【０００４】
そのため、次のような不都合が生じる。すなわち、視聴者はリクエストした自分の曲や情報が放送されるのをラジオやテレビ等のリクエスト放送可能な媒体のそばで待っている必要があった。しかしながら、必ずしも自分が待っている時間あるいは日に自分のリクエストした情報が放送されるとは限らず、視聴者はリクエストした時点から放送されるかもしれない時間中ずっと、どこにも行かずその媒体の前に居なくてはいけないという事態も考えられる。また、急に人と会う約束等ができて外出したりする場合、放送番組をビデオレコーダ等の録画・録音できる媒体を用いて予約録画・録音しておくことも考えられるが、録画・録音後に実際に視聴してみると、結局のところ自分のリクエストした情報が放送されていないこともあり、その場合は、ただ無駄にビデオテープやカセットテープを使った上、自分が希望するリクエストに対応する情報もないので、それらを視聴している時間は大変無駄となってしまう。
【０００５】
本発明は、上述した問題点を解決するためになされたものであり、視聴者からされたリクエストに応じた情報の放送開始時刻を視聴者に前もって告知することにより、利用者の便宜を向上可能な放送センタを提供することを目的とする。
【０００６】
【課題を解決するための手段及び発明の効果】
この目的を達成するためになされた請求項１記載の発明は、視聴者から個別になされたリクエスト情報を記憶しておくリクエスト情報記憶手段と、該リクエスト情報記憶手段に記憶されているリクエスト情報に応じた放送用情報を、所定の順番に従って順次放送していく放送手段とを備えたリクエスト応答機能付きの放送センタにおいて、前記リクエスト情報記憶手段は、リクエスト情報に応じた「放送用情報」又は「該放送用情報が含まれている放送番組」の放送開始時刻を予告するタイミング、及びその告知先の通信端末へアクセスするための情報も記憶しており、さらに、前記リクエスト情報記憶手段に記憶されているリクエスト情報毎に、該リクエスト情報に応じた放送用情報又は該放送用情報が含まれている放送番組の放送開始時刻を記憶している放送開始時刻記憶手段と、前記リクエスト情報記憶手段に記憶されているリクエスト情報毎に、該リクエスト情報に応じた放送用情報又は該放送用情報が含まれている放送番組の放送開始時刻を予告する必要があるかどうかを判断する判断手段と、該判断手段によって放送開始時刻について予告する必要があると判断された場合には、前記リクエスト情報記憶手段に記憶されている予告タイミングに基づいて、該当する告知先に放送開始時刻を通知する放送開始時刻通知手段とを備えていることを特徴とする放送センタである。
【０００７】
本発明の放送センタによれば、視聴者から個別になされたリクエスト情報をリクエスト情報記憶手段が記憶しており、放送手段が、そのリクエスト情報記憶手段に記憶されているリクエスト情報に応じた放送用情報を、所定の順番に従って順次放送していく。
【０００８】
このような基本的な放送処理に加えて、次のような処理を実行する。すなわち、リクエスト情報記憶手段は、リクエスト情報に応じた放送用情報又は該放送用情報が含まれている放送番組の放送開始時刻を予告するタイミング及びその告知先の情報も記憶しており、放送開始時刻記憶手段は、リクエスト情報記憶手段に記憶されているリクエスト情報毎に、該リクエスト情報に応じた放送用情報又は該放送用情報が含まれている放送番組の放送開始時刻を記憶しており、判断手段が、リクエスト情報記憶手段に記憶されているリクエスト情報毎に、該リクエスト情報に応じた放送用情報又は該放送用情報が含まれている放送番組の放送開始時刻を予告する必要があるかどうかを判断する。
そして、放送開始時刻について予告する必要があると判断された場合には、放送開始時刻通知手段が、リクエスト情報記憶手段に記憶されている予告タイミングに基づいて、該当する告知先に放送開始時刻を通知する。
【０００９】
視聴者にとっては、自分がリクエストした放送用情報又は該放送用情報が含まれている放送番組が放送される前にその放送開始時刻を通知してもらえるので、自分がリクエストした放送用情報を見逃すことを防止できる。そして、従来は、いつ自分のリクエストした放送用情報が放送されるか判らないため、例えば放送がされる可能性のある時間中、どこにも行かず放送されるのを待っていなくてはならなかったり、放送番組をビデオレコーダ等によって録画したにもかかわらず、録画後に実際に視聴してみると、結局のところ自分のリクエストした情報が放送されていないといったことも生じるが、本放送センタによれば、そのような不都合は生じない。
【００１０】
また、視聴者からのリクエストを受け付ける場合には、放送センタ側のオペレータが視聴者からのリクエスト情報を聞き、それをマニュアルでリクエスト情報記憶手段に記憶させるようにしてもよい。また、リクエストの受付を自動化し、放送センタ側においてオペレータ等の人手を全く介さないシステムとして構築することも可能である。
【００１１】
このように人手を介さずに自動的にリクエスト情報を記憶させるものとしては、例えば請求項２に示すものが考えられる。その構成は、請求項１に記載の放送センタにおいて、視聴者から個別に送信されたリクエスト情報を受信し、前記リクエスト情報記憶手段にデータとして自動的に記憶させるリクエスト受付手段を備えており、該リクエスト受付手段は、視聴者から送信された予告タイミング及びの告知先の電話番号をリクエスト情報に対応させて記憶するようにしたものである。
【００１２】
この場合、例えば請求項３に示すように、リクエスト受付手段は、視聴者からのリクエスト情報を受け付ける際、所定のガイダンス用音声情報を電話回線を介して視聴者側に送信し、そのガイダンス用音声情報に対する返答として、視聴者識別情報やリクエスト内容識別情報、あるいは前記予告タイミングやの告知先の電話番号を受信するように構成し、前記放送開始時刻通知手段は、前記電話回線を介して、該当する告知先に放送開始時刻を通知するよう構成することが考えられる。
【００１３】
もちろん、電話回線以外にも専用の通信回線等を使用しても実現できるが、電話回線の場合には既存のものを利用できるという利点もある。そしてこの場合には、例えば視聴者からの電話を自動着信し、電子音声による案内を行う音声応答機能と、電話によるダイヤルトーンを使用したコードの発信を受信するコード受信機能を備え、音声応答機能によって所定のガイダンス音声を流し、それにしたがって視聴者が例えば要求するカラオケの曲番号や視聴者識別番号等をプッシュボタン等で入力し、それをダイヤルトーンを使用したコードとして受信するようにすれば便利である。
【００１４】
なお、予告タイミングについては、例えば一律に放送開始時刻の１時間前といったように固定してもよいが、視聴者の都合によって、ある人は１時間前でよいが、別の人にとっては３時間前に通知して欲しいという場合もある。そのため、予告タイミングも視聴者側から指定できるようにしておくことが好ましい。また、同様に告知先についても、ある人にとっては自宅の電話がよいが、別の人にとっては携帯電話やさらには無線呼出し受信機（いわゆるポケットベル）に連絡して欲しい場合もある。そのため、告知先も視聴者側から指定できるようにしておく始ことが好ましい。
【００１５】
したがって、本発明では、その告知先を特定するための情報として電話番号を用いている。電話番号であれば、いわゆる宅内電話機や携帯電話機はもちろん、上述したポケットベルやさらにはファクシミリにも適用できる。なお、放送開始時刻を通知する場合、電話機であれば音声でその内容を通知し、ファクシミリであれば文字でその内容を通知すればよい。また、ポケットベルの場合にも、送信したメッセージを受信して表示できる機能を備えたものがあるので、その場合には文字で表示すればよい。また、メッセージを表示できない場合でも、呼出し先の区別によって判断は可能である。
【００１６】
このような放送センタから放送する放送用情報としては、例えばカラオケ用の情報が考えられる。
この場合、請求項４に示すように、放送手段は、音声情報と映像情報が送信可能なテレビジョン放送手段であると共に、放送手段が放送する放送用情報は、要求されたカラオケ曲に応じたカラオケ演奏音及び背景映像に歌詞テロップが合成された映像とを含むようにすることが考えられる。
【００１７】
もちろん、放送用情報としてカラオケ演奏音だけを放送してもカラオケとしては成立するが、現在のカラオケには、もはや背景映像に歌詞テロップを合成した映像をカラオケ演奏に併せて表示させるということが常識化されつつあるので、カラオケ演奏音及び背景映像に歌詞テロップが合成された映像とを含む放送用情報を放送することが好ましいと言える。この場合、いわゆるＣＡＴＶのように有線で放送センタと加入者端末を接続してもよいし、通常の放送システムのように無線のままでもよい。さらには、映像情報だけという場合も考えられる。
【００１８】
【発明の実施の形態】
以下、本発明の放送センタを具体化した一実施例を図面を参照しながら説明する。
図１は本実施例の放送センタ１０の概略構成を示すブロック図である。図１に示すように、放送センタ１０は、放送センタ全体の制御を行う制御手段であり「判断手段」及び「放送開始時刻通知手段」としてのホストコンピュータ１１と、「リクエスト情報記憶手段」及び「放送開始時刻記憶手段」としての外部記憶装置１２と、表示装置１３と、カラオケ再生装置１４と、テロップ合成装置１５と、「放送手段」としての放送手段１６と、「リクエスト受付手段」及び「放送開始時刻通知手段」としての音声応答装置２０とを備えている。また、放送センタ１０は、公衆電話回線４０を介して多数の電話機５０と接続されている。なお、公衆電話回線４０を介しているので、電話機５０以外にも例えば無線呼出し受信機（以下、通称である「ポケットベル」と記す。）６０とも接続可能である。
【００１９】
各装置について、放送センタ１０における役割あるいは放送システムとの関わりも含めて説明する。
まず、音声応答装置２０は視聴者からのリクエストを受け付けるためのものである。放送センタ１０は視聴者から個別になされたリクエストを蓄積しておき、そのリクエストの集計結果を放送可能とされており、視聴者は手持ちの電話機５０により一般の公衆電話回線４０を通して、希望するカラオケ用情報をリクエストすることができる。このリクエストは、予め定められた「リクエストコード」によって行う。これは、一般のカラオケ装置における「曲番号」と同義のものである。数字コードのよるリクエストであるため、実際には視聴者が電話機５０のダイヤルもしくはプッシュホンの押し下げにより上記リクエストコードをトーン発信する。このリクエストコードは予め視聴者に配布物等によって通知されているものとする。
【００２０】
この視聴者から通話は放送センタ１０において音声応答装置２０により自動的に受理される。音声応答装置２０は内蔵された合成音声手段（図示せず）により予め登録されたメッセージを送話し、視聴者にリクエストコードの入力及び後述する放送開始時刻の予告の必要の有無や、必要な場合の予告タイミングやその告知先の入力と、そのガイダンスを促すものであり、ホストコンピュータ１１により制御され、上記した通話の受話や各種メッセージの送話からパルスコードの受信まで行う。
【００２１】
音声応答装置２０によって受理されたリクエストコードは、ホストコンピュータ１１により、そのリクエストコードが有効であるかどうか、外部記憶装置１２上のデータベースとの照合により判断され、有効であればＣＰＵメモリ１１ｂ（図２参照）内のリクエスト受付テーブル（図４参照）に受け付けた時刻情報とセットで記憶される。
【００２２】
ホストコンピュータ１１はこの記憶されたリクエストコードを基にして、所定の集計期間に該当するリクエスト情報を、セットで記憶されている受付時刻情報に基づいて集計する。そして、リクエスト情報の集計結果として例えばリクエスト総数を含む結果情報を算出し、任意のメッセージとして表示すべき文字列を生成する。生成されたメッセージは、外部記憶装置１２内のフォントデータによって画像データとしてホストコンピュータ１１のＣＰＵメモリ１１ｂに展開され、テロップ合成装置１５に転送される。
【００２３】
テロップ合成装置１５から出力された映像信号はカラオケ再生装置１４から出力される音声信号と共に、放送手段１６によってテレビジョン放送される。
この放送内容は、視聴者側のテレビジョン受信機などの受信設備にて受信され、視聴可能である。
【００２４】
放送手段１６によって放送された放送内容は、視聴者側のテレビジョン受信機などの受信設備にて受信され、カラオケ番組として視聴可能である。なお、放送センタ１０と視聴者側の受信設備はＣＡＴＶシステムのように有線で接続されていてもよいし、通常の放送システムのように無線でもよい。
【００２５】
表示装置１３はホストコンピュータ１１に接続されており、これらの状況を表示することができる。これは、放送センタ１０のオペレータが確認するために利用される。
続いて、図２を参照して、ホストコンピュータ１１を中心とした信号の流れを説明する。
【００２６】
図２に示すように、音声応答装置２０はホストコンピュータ１１のＣＰＵ１１ａと制御信号によって結ばれている。ＣＰＵ１１ａは音声応答装置２０に対して公衆電話回線４０（図１参照）の着信待ちに関する制御、着信後の同装置２０内の音声メッセージの送話に関する制御（複数のメッセージ内の選択）を行う。音声応答装置２０はホストコンピュータ１１に対して公衆電話回線４０を通じて受信したダイヤルパルスを数値情報として返す。これにより、公衆電話回線４０による視聴者リクエストの自動受理を行う。音声応答装置２０より返された数値はＣＰＵメモリ１１ｂに格納される。
【００２７】
外部記憶装置１２は、リクエストコードに関するデータベースを格納したホストコンピュータ１１の外部記憶であり、装置間のデータの読み書きが行われる。これにより、ＣＰＵ１１ａはリクエストコードの検索・照合等を行う。カラオケ再生装置１４はＣＰＵ１１ａと制御信号により結ばれている。ＣＰＵ１１ａはカラオケ再生装置１４にリクエストコード（曲番号）を送信し、同装置１４にカラオケ楽曲の再生を行わせ、またこの再生の開始・終了などの制御を行うことができる。また、カラオケ再生装置１４は、ＣＰＵ１１ａに対して再生の状況（再生中・再生終了等）を返す。これにより、ＣＰＵ１１ａはリクエストコードによるカラオケ楽曲の再生を行うことができる。
【００２８】
テロップ合成装置１５は、ＣＰＵ１１ａから画像の出力と合成に関する制御と、画像データの転送を受ける。同装置１５はカラオケ再生装置１４からの映像信号を入力しており、ＣＰＵ１１ａから転送された画像とこの映像を合成し、カラオケ再生装置１４の出力する映像にテロップ表示を付加できる。
【００２９】
次に、本実施例の放送センタ１０の動作について、図を参照して説明する。
まず、視聴者からのリクエストを受け付ける際の動作について説明する。図３はリクエスト受付時の視聴者と放送センタ１０側との間の通信シーケンス図であり、図４はリクエスト受付テーブルの説明図である。
【００３０】
放送センタ１０は、図３に示す通信シーケンスに従って視聴者からリクエストを受け付ける。なお、このリクエストできる視聴者は、単にこの放送センタ１０からの放送を視聴できるという意味ではなく、リクエストする権利を有している「加入者」という意味である。例えばＣＡＴＶシステムで、そのシステムに加入する際に自動的にリクエストの権利も与えられる場合には、全てがここでいう「加入者」となる。なお、通常の無線形式で放送する場合には、例えばリクエストをする代わりに所定の料金を徴収するような契約を別個に行なうことが考えられる。その場合には、契約をした人だけがここでいう「加入者」となる。なお、以下の説明では、特に断わらない限り、加入者の意味で視聴者という言葉を使用する。
【００３１】
図３の通信シーケンスに戻り、視聴者が公衆電話回線４０を介して放送センタ１０に対して発信・接続すると、放送センタ１０側は音声応答装置２０が、電話機５０からの着信の応答として音声応答メッセージ（例えば「リクエストする曲番号を入力して下さい」といった内容）を送出する。
【００３２】
そして、視聴者が電話機５０を介してリクエストしたい曲番号を入力すると、そのリクエスト番号はＣＰＵメモリ１１ｂ上のリクエスト受付テーブル（図４）のリクエスト曲番号Ｄ３の項目として格納される。
放送センタ１０では、リクエスト受付応答送信として、音声応答装置２０が例えば「リクエストを受け付けました。リクエストの放送時間を知らせる必要がある場合は１＃、必要がない場合は２＃を入力して下さい。」といった内容の音声応答メッセージを送信することで、リクエストを受け付けたことを応答すると共に、視聴者側において放送開始時刻の予告の必要があるかどうかを入力するよう促す。
【００３３】
ここで視聴者が「２＃」を入力した場合、それを受信した放送センタ１０側では、予告の必要なしとして図４のリクエスト受付テーブルにおいては予告タイミングＤ１や告知先Ｄ２の項目には、あり得ない値（例えば予告タイミングＤ１として「９９：９９：９９」、告知先Ｄ２として「９９９９−９９−９９９９」）がセットされることとなる。この値の扱いは後述する。
【００３４】
一方、視聴者が「１＃」を入力した場合には、メッセージ通りに放送開始時刻の予告の必要がある場合であり、それを受信した放送センタ１０側では、その予告のための個別的な情報を得るため、まず音声応答装置２０によって、例えば「予告タイミングは放送前の１時間から９時間までです。「＊」入力後に、希望する時間の１〜９までの数字を入力して下さい。」といった内容の音声応答メッセージを送信する。
【００３５】
これに応じて視聴者が入力した「＊」と予告してほしい時間（１〜９までのいずれかの数字）が電話機５０を介しての放送センタ１０へ送信される。予告タイミングを受信した放送センタ１０は、先のリクエスト曲番号Ｄ３とともに、図４のリクエスト受付テーブルの予告タイミングＤ１の項目に格納される。
【００３６】
続いて、音声応答装置２０によって、例えば「放送前の？（加入者が入力した値）時間前にお知らせします。希望するお知らせ先を＊入力後、入力して下さい。」といった内容の音声応答メッセージを送信する。
これに応じて視聴者は希望する電話番号を入力し、この番号が電話機５０を介しての放送センタ１０へ送信される。受信した放送センタ１０は、この送信されてきた電話番号を図４のリクエスト受付テーブルの告知先Ｄ２の項目に格納する。この告知先Ｄ２としての電話番号は、そのリクエストに用いている電話機に対応する電話番号でもよいし、また別の携帯電話の番号やポケットベルの番号であってもよい。
【００３７】
こうして、放送開始時刻を予告するための詳細情報が得られた場合には、視聴者への受付確認のため、音声応答装置２０が例えば「放送前の？（加入者が入力した値）時間前に？？？−？？？−？？？？（加入者が入力した値）へお知らせします。リクエストありがとうございました。」といった内容の音声応答メッセージを送信する。
【００３８】
その後さらに、リクエスト受付年月日Ｄ４及び受付時分秒Ｄ５の２項目を加え、図４に示すリクエスト受付テーブルの全ての項目（Ｄ１〜Ｄ５）が格納されることとなる。
次に、放送開始時刻の通知に関する動作について説明する。図５は、ＣＰＵ１１ａによって実行されるプログラムの処理手順を示すフローチャートである。
【００３９】
なお、図５に示す処理の前提を説明しておく。前提としては、１日に１回リクエスト曲を放送する番組があり、その番組で放送する曲は、過去のリクエストを基に自動的に決定したものか、あるいは番組作成者が適宜選択して決定したものである。
【００４０】
まず、最初のステップＳ１０においては、リクエスト受付テーブル（図４）から本日の番組中に放送予定の曲に該当する曲番号をリクエスト曲番号Ｄ３として持つリクエストデータを全て取得する。例えば、同じ曲について複数のリクエストがされている場合には、それぞれ一つのリクエストデータとして取得する。したがって、番組中での放送予定は１０曲の場合でも、該当するリクエストデータは、２０や３０といった多数になる場合も考えられる。なお、この場合に取得するリクエストデータは、図４に示す項目の内の予告タイミングＤ１と告知先Ｄ２とリクエスト曲番号Ｄ３の３つの項目だけでよい。
【００４１】
そして、続くＳ２０では、Ｓ１０において取得したリクエストデータを、さらに予告タイミングＤ１に基づき、予告タイミングＤ１として設定されている時間の値が大きい順に並べ替える。本実施例ではこの予告タイミングＤ１は１時間刻みの設定とされている。Ｓ１０で取得したリクエストデータをＳ２０にて並び替えた状態のテーブルの一例を図６に示す。
【００４２】
Ｓ３０では、そのテーブル（図６）より最初のデータを読み出し、続くＳ４０にて、通知の必要があるかどうかを判断する。例えば、図６に示すテーブルの最初のリクエストデータは、予告タイミングＤ１が「９９：９９：９９」、告知先Ｄ２が「９９９９−９９−９９９９」とされている。これは上述したように、リクエストする際に視聴者が放送開始時刻の予告の必要がないとして「２＃」を入力をすると設定される値である。したがって、予告タイミングＤ１や告知先Ｄ２に上記値が設定されている場合には通知の必要がないと判断し（Ｓ４０：ＮＯ）、Ｓ８０へ移行する。
【００４３】
Ｓ８０では、最後のリクエストデータかどうかを判断する。この場合には最後ではないので（Ｓ８０：ＮＯ）、Ｓ９０へ移行し、図６のテーブルより次のリクエストデータを読み出し、Ｓ４０へ移行する。図６のテーブルにおける２番目のリクエストデータは、予告タイミングＤ１や告知先Ｄ２の値からＳ４０にて肯定判断、すなわち通知の必要があると判断されてＳ５０へ移行する。
【００４４】
Ｓ５０では、番組開始までの待ち時間を取得する。番組の放送開始予定時刻については外部記憶装置１２に記憶されているので、その放送開始予定時刻から現在時刻を差し引くことで上記「待ち時間」が得られる。
続くＳ６０では、Ｓ３０又はＳ４０で読み込んだリクエストデータ中の予告タイミングＤ１がＳ５０で得た待ち時間よりも大きいかどうかを判断する。予告タイミングＤ１が待ち時間以下の場合には、視聴者が通知して欲しいタイミングをまだ過ぎていないので（Ｓ６０：ＮＯ）、Ｓ５０へ戻る。このようにして、該当する予告タイミングＤ１が待ち時間よりも大きくなった場合には、視聴者が通知して欲しいタイミングを過ぎているので（Ｓ６０：ＹＥＳ）、Ｓ７０に移行して、該当する告知先Ｄ２に対して通知する。
【００４５】
具体的には、その該当する告知先Ｄ２に公衆電話回線４０を介してアクセスし、例えばそれが電話機５０（図１参照）であれば、番組の放送開始時間が近づいてることを音声メッセージとして通知する。なお、番組の放送開始予定時刻は既に判っているので、「○時から番組が始まります。」あるいは「○時から始まる番組であなたのリクエストした曲が放送されます。是非、リクエストされた曲を視聴できる場所へお戻り下さい。」といったメッセージを予め準備しておいて流すようにしてもよい。
【００４６】
そして、Ｓ７０での通知処理の後は、Ｓ８０へ移行し、図６のテーブルの最後のリクエストデータとなるまで上述した処理を繰り返す。例えば図６のテーブルにおいて３番目のリクエストデータは、２番目のリクエストデータと同様に予告タイミングＤ１が「０３：００：００」となっているので、すぐにＳ６０で肯定判断となり、Ｓ７０にて、その該当する告知先へ通知する。そして、４番目のリクエストデータの予告タイミングＤ１は「０２：００：００」であるので、約１時間後にＳ７０の通知処理が実行されることとなる。
【００４７】
このようにして、図６のテーブルにおける最後のリクエストデータについての通知処理が終了した場合には（Ｓ８０：ＹＥＳ）、本処理を終了する。
以上説明したように、本実施例の放送センタ１０によれば、視聴者から個別に送信されるリクエストを受信し、リクエスト情報を受けた時点でリクエストを予告する場合の予告タイミングや告知先の詳細情報を得て、それらをデータとしてホストコンピュータ１１内に保管し、そのデータを基にそのリクエストに応じた曲が放送される番組の放送開始前に視聴者に通知することが可能となる。これにより、加入者は自分のリクエストした曲を見逃すことなく視聴することができるようになる。
【００４８】
つまり、視聴者にとっては、自分がリクエストした曲が放送予定となっている番組の放送前にその放送開始時刻を通知してもらえるので、自分がリクエストした曲を見逃すことを防止できる。そして、従来は、いつ自分のリクエストした曲が放送されるか判らないため、例えば毎日番組が放送される度に、どこにも行かず放送されるのを待っていなくてはならなかったり、放送番組をビデオレコーダ等によって録画したにもかかわらず、録画後に実際に視聴してみると、結局のところ自分のリクエストした情報が放送されていないといったことも生じるが、本放送センタ１０によれば、そのような不都合は生じない。
【００４９】
なお、予告タイミングについては、例えば一律に放送開始時刻の１時間前といったように固定してもよいが、視聴者の都合によって、ある人は１時間前でよいが、別の人にとっては３時間前に通知して欲しいという場合もある。そのため、本実施例のように、予告タイミングも視聴者側から指定できるようにしておくことが好ましい。また、同様に告知先についても、ある人にとっては自宅の電話機５０がよいが、別の人にとってはポケットベル６０に連絡して欲しい場合もある。そのため、告知先も視聴者側から指定できるようにしておくことが好ましい。
【００５０】
したがって、その告知先の情報としては、本実施例に示すように電話番号とすることが代表的な例として考えられる。電話番号であれば、いわゆる宅内電話機や携帯電話機はもちろん、上述したポケットベルやさらにはファクシミリにも適用できる。なお、放送開始時刻を通知する場合、上記実施例の電話機５０であれば音声でその内容を通知し、ファクシミリであれば文字でその内容を通知すればよい。また、ポケットベル６０の場合にも、送信したメッセージを受信して表示できる機能を備えたものがあるので、その場合には文字で表示すればよい。また、メッセージを表示できない場合でも呼出し先の区別によって判断は可能である。
【００５１】
以上、具体例に従って、本発明の実施形態について説明したが、本発明はこのような具体例に限定されるものではなく、発明の要旨を逸脱しない範囲で様々な実施ができることは言うまでもない。
例えば、リクエスト告知先も実施例においては、単に電話番号のみとしているが、電話機に限らない、電話番号からポケットベル等の判断がつくため、各機能に合った告知の方法も取ることができる。ポケットベルの場合なら、メッセージ表示可能なものであればその旨を送信して加入者に告知することもできる。なお、電話番号を用いた告知先としてはファクシミリも考えられる。告知先としてファクシミリであることを記憶しておけば、ファクシミリ用の情報を送信することも可能である。
【００５２】
また、上記図５に示した処理の前提は、１日に１回リクエスト曲を放送する番組があり、その番組で放送する曲は、過去のリクエストを基に自動的に決定したものか、あるいは番組作成者が適宜選択して予め決定しておくというものであった。そのような限定されたシステムでなく、種々の形態が考えられる。例えば放送番組が１日に複数回、例えば１回目が１０：００〜１２：００、２回目が１５：００〜１７：００、３回目が２０：００〜２２：００というように３回ある場合も考えられる。この場合には、それぞれの番組での放送予定曲が判るので、上記図５のＳ５０で番組開始までの待ち時間を取得する場合に、何回目の番組かを区別してその放送開始時刻情報に基づいて計算すればよい。したがって、例えばＳ７０での通知をしていく場合、１回目の番組でのある放送予定曲Ａのリクエストデータの予告タイミングＤ１が「０１：００：００」であり、２回目の番組でのある放送予定曲Ｂのリクエストデータの予告タイミングＤ１が「０７：００：００」であった場合には、先に２回目の番組での放送予定曲Ｂに対しての通知を行い、その約１時間後に１回目の番組での放送予定曲Ａに対しての通知を行うという場合もあり得る。
【００５３】
また、上記実施例では、放送予定曲は番組の放送開始前に決定されているという前提であったが、例えば視聴者からのリクエストを随時受け付けながら、番組もそれと並行して長時間放送する場合もある。この場合には、リクエストした曲がすぐに、あるいは２〜３曲待てば実際に番組中で放送されるという場合も考えられる。すなわちリクエストした後で即座に放送予定が決定可能な場合には、その場で通知できる。したがって、例えば図３で放送センタ１０が曲番号を受信した後の音声応答メッセージとして、「リクエストを受け付けました。なお、リクエストされた曲は３曲後に放送されますので、しばらくお待ち下さい。」といった内容を通知すればよい。そして、リクエストが多く、その時点で即座には放送予定が決定できない場合には、上記説明通り予告の必要があるかどうかの伺いをして、視聴者の希望を聞くようにすればよい。
【００５４】
さらに、上記実施例では、リクエストした曲が放送予定の「番組」の放送開始時刻を通知するようにしたが、曲毎の放送予定時刻が判っている場合には、曲毎に予告タイミングを判断し、「あなたのリクエストした曲は、○時○分から放送されます」というように細かく通知するようにしてもよい。
【００５５】
また、上記実施例では、カラオケ番組の放送に使用する例を説明したが、本発明は放送用情報を供給するサーバ側が少数であり、リクエストする視聴者側が多数であり、両者が遠隔である等の理由で、放送という情報供給形態を採用する状況であることが応用の主旨である。したがって、放送する情報としてもカラオケ曲以外に、カラオケ用でなく聞くための曲という意味での「通常の」曲でもよい。そしてその場合には、映像はなく音声情報だけであってもよい。一方、映画等も考えられるが、映画の場合には１つが長時間となるので、上記「番組」の放送開始時間というのではなく、その映画作品自体の放送開始時間を通知することが好ましい。
【図面の簡単な説明】
【図１】実施例の放送センタの概略構成を示すブロック図である。
【図２】ホストコンピュータを中心とした信号の流れを示す図である。
【図３】リクエスト受付時の加入者と放送センタ側との間の通信シーケンスを示す説明図である。
【図４】ホストコンピュータが取り扱うリクエスト受付テーブルのデータ構成図である。
【図５】ホストコンピュータが実行する放送開始時刻の通知処理を示すフローチャートである。
【図６】ホストコンピュータが放送開始時刻の通知処理において取り扱うテーブルのデータ構成図である。
【符号の説明】
１０…放送センタ１１…ホストコンピュータ
１１ａ…ＣＰＵ１１ｂ…ＣＰＵメモリ
１２…外部記憶装置１３…表示装置
１４…カラオケ再生装置１５…テロップ再生装置
１６…放送手段２０…音声応答装置
４０…公衆電話回線５０…電話機
６０…ポケットベル

Claims

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