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