JPH0974391A - テレビジョン放送センタ - Google Patents

Abstract

(57)【要約】 【課題】 放送要求をする利用者に、その要求した放送
が開始されるまでにかかる時間等を常時映像で通知可能
とする。 【解決手段】 視聴者からの放送要求を、音声応答装置
２０が受理すると、ホストコンピュータ１１は、そのリ
クエストコードが有効か否かを外部記憶装置１２上のデ
ータベースとの照合によって判断し、有効であればホス
トコンピュータ１１内のＣＰＵメモリ１１ｂに蓄積され
る。さらにホストコンピュータ１１は、外部記憶装置１
２内のデータベースを基に、放送開始までの予定所要時
間あるいは放送開始予定時刻を算出し、外部記憶装置１
２内の文字フォントデータによってＣＰＵメモリ１１ｂ
に展開され、テロップ合成装置１５に転送し、放送手段
１６を介して出力される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、視聴者から個別に
なされた放送要求を蓄積しておき、その放送要求に応じ
た映像を含む放送用情報を、所定の順番に従って順次放
送していくリクエスト応答機能付きのテレビジョン放送
センタに関する。

【０００２】

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

【０００３】このようなシステムにおけるテレビジョン
放送センタは、次々にやってくる視聴者からの放送要求
を一時的に蓄積し、要求された順番に映像を含む放送用
情報を放送していくのであるが、当然ながらこのような
形態であれば、視聴者からの放送要求のスピードが、そ
の要求に応じた放送用情報の放送・消化のスピードを上
回る事態が発生する。すると、放送要求は蓄積してしま
い、要求した視聴者の待ち時間が長くなってしまう。

【０００４】ところで、このような形態であってもカラ
オケ番組と呼ばれるカラオケ楽曲の放送のみを取り扱う
番組時間枠（若しくは設けられた専用のチャンネル）等
であれば実際の運用を行うことが可能な程度に上記の問
題は縮小する。カラオケの場合は１曲の所要時間が数分
程度であり、要求数が少なければ、待ち時間もあまり長
くはならないからである。

【０００５】ただし、このようなリクエスト応答タイプ
のテレビジョンシステムにおけるカラオケ番組であって
も、上記したような要求速度と消化速度にまつわる問題
は完全には解消できない。視聴者の立場としては、要求
した放送用情報が直ちに自宅のＴＶ画面として映ること
を求めるのであり、それが不可能であったとしても、現
在要求は多いのかどうかといった情報は必須になる。

【０００６】特に、これから新たに放送要求をしようと
している視聴者にとっては、その放送要求に応じた放送
用情報の放送開始までにかかる時間あるいは放送開始時
刻を把握することができれば、その待ち時間によっては
新たな要求をしないという選択もできる。つまり、視聴
者独自の予定によって、これから何分以内、あるいは何
時何分までしかこのカラオケ番組を視聴することができ
ないという事情がある場合に、せっかく放送要求をした
のに時間の関係上視聴できなかったりする不都合も生じ
てくる。そのため、放送要求をする前に、放送開始まで
にかかる時間あるいは放送開始時刻が判ると非常に便利
である。

【０００７】そこで本発明は、上述した問題点を解決す
るためになされたものであり、既に放送要求をし、その
要求に応じた放送を待っている視聴者、あるいは新たに
放送要求をしようとしている視聴者に対して、その放送
開始までにかかる時間あるいは演奏開始時刻など、放送
開始予定に関する情報を常時映像で通知可能とすること
で、視聴者の利用の便宜を向上させることを目的として
いる。

【０００８】

【課題を解決するための手段及び発明の効果】この目的
を達成するためになされた請求項１記載の発明は、視聴
者から個別になされた放送要求を蓄積しておくための要
求蓄積手段と、その要求蓄積手段に記憶されている放送
要求に応じた映像を含む放送用情報を、所定の順番に従
って順次放送していく放送手段とを備えたリクエスト応
答機能付きのテレビジョン放送センタにおいて、前記要
求蓄積手段に蓄積されている放送要求に基づき、放送要
求自体は既に蓄積されているが放送はまだ開始されてい
ない放送用情報、またはこの次にさらに放送要求がなさ
れた場合の当該放送要求に応じた放送用情報の少なくと
もいずれか一方の放送開始予定に関する情報を作成する
放送開始予定関連情報作成手段を備え、前記放送手段
は、その作成した放送開始予定関連情報を、視聴者側に
放送する放送用情報に映像形式で常時付加した状態で放
送可能に構成されていることを特徴とするテレビジョン
放送センタである。

【０００９】請求項２に記載の発明は、請求項１のテレ
ビジョン放送センタにおいて、前記放送用情報毎の放送
所要時間を記憶する所要時間記憶手段を備え、前記放送
開始予定関連情報作成手段は、前記要求蓄積手段に蓄積
されている放送要求に対応した放送用情報の各放送所要
時間情報に基づき、該当する放送用情報の放送開始まで
の予定所要時間あるいは放送開始予定時刻を算出し、前
記放送開始予定関連情報とすることを特徴とする。

【００１０】請求項３に記載の発明は、請求項２のテレ
ビジョン放送センタにおいて、前記放送開始予定関連情
報作成手段は、前記要求蓄積手段に放送要求自体は蓄積
されているが放送はまだ開始されていない各放送用情報
及びこの次にさらに放送要求がなされた場合の当該放送
要求に応じた放送用情報について、それぞれ放送開始ま
での予定所要時間あるいは放送開始予定時刻を算出し、
前記放送開始予定関連情報とすることを特徴とする。

【００１１】請求項４に記載の発明は、請求項３のテレ
ビジョン放送センタにおいて、前記放送手段は、放送用
情報の放送中は、この次にさらに放送要求がなされた場
合の放送用情報の放送開始までの予定所要時間あるいは
放送開始予定時刻のみを放送用情報に付加して放送し、
一つの放送用情報の放送が終了して次の放送用情報の放
送が開始されるまでの期間は、前記要求蓄積手段に放送
要求自体は蓄積されているが放送はまだ開始されていな
い各放送用情報についての放送開始までの予定所要時間
あるいは放送開始予定時刻も加えた一覧表示映像を放送
するように構成されていることを特徴とする。

【００１２】請求項５に記載の発明は、請求項１〜４の
いずれかに記載のテレビジョン放送センタにおいて、前
記視聴者からの放送要求を通信回線を介して受信し、前
記要求蓄積手段にデータとして自動的に蓄積させる要求
受付手段を備えることを特徴とする。

【００１３】請求項６に記載の発明は、請求項１〜５の
いずれかに記載のテレビジョン放送センタにおいて、前
記視聴者からの放送要求は、カラオケ曲を指定した要求
であり、前記放送手段が放送する放送用情報は、要求さ
れたカラオケ曲に応じたカラオケ演奏音及び背景映像に
歌詞テロップが合成された映像とを含むものであること
を特徴とする。

【００１４】本発明のテレビジョン放送センタによれ
ば、要求蓄積手段が視聴者から個別になされた放送要求
を蓄積しておき、放送手段が、その要求蓄積手段に記憶
されている放送要求に応じた映像を含む放送用情報を、
所定の順番に従って順次放送していく。このような基本
的な放送処理に加えて、次のような処理を実行する。す
なわち、放送開始予定関連情報作成手段は、要求蓄積手
段に蓄積されている放送要求に基づき、放送要求自体は
既に蓄積されているが放送はまだ開始されていない放送
用情報、またはこの次にさらに放送要求がなされた場合
の当該放送要求に応じた放送用情報の少なくともいずれ
か一方の放送開始予定に関する情報を作成する。そし
て、放送手段は、その作成した放送開始予定関連情報
を、視聴者側に放送する放送用情報に映像形式で常時付
加した状態で放送するのである。

【００１５】ここで、放送開始予定関連情報について説
明する。これは該当する放送用情報の放送開始予定に関
する情報を視聴者に対して知らせるための情報であり、
例えば、請求項２に示すテレビジョン放送センタは、放
送用情報毎の放送所要時間を記憶しており、要求蓄積手
段に蓄積されている放送要求に対応した放送用情報の各
放送所要時間情報に基づき、該当する放送用情報の放送
開始までの予定所要時間あるいは放送開始予定時刻を算
出して、「放送開始予定関連情報」とするのである。し
たがって、視聴者側の放送受信設備（テレビジョン受信
機など）には、その放送開始までの予定所要時間あるい
は放送開始予定時刻が常時表示されることとなる。

【００１６】なお、「放送開始予定関連情報」として
は、放送開始までの予定所要時間あるいは放送開始予定
時刻の他に、放送予定の放送用情報数などであってもよ
い。例えばカラオケの場合には、１曲あたりの所要時間
が３〜５分程度のものが多いので、放送予定の曲数だけ
が示されていても、おおよその待ち時間のようなものは
視聴者側で把握することができる。しかし、１曲が３分
のものと５分のものとでは、例えば５曲分すでに予約さ
れていれば待ち時間に１０分の違いが出てくるので、単
に曲数ではなく、直接的に放送開始までの予定所要時間
あるいは放送開始予定時刻を表示するようにした方が好
ましいと言える。

【００１７】また、該当する放送用情報の放送開始まで
の予定所要時間あるいは放送開始予定時刻を算出する際
の「該当する放送用情報」としては、請求項３に示すよ
うに、：「要求蓄積手段に放送要求自体は蓄積されて
いるが放送はまだ開始されていない各放送用情報」であ
ってもよいし、あるいは、：「この次にさらに放送要
求がなされた場合の当該放送要求に応じた放送用情報」
であってもよい。そして、請求項３の場合には、，
それぞれの放送開始までの予定所要時間あるいは放送開
始予定時刻を算出し、放送開始予定関連情報としてい
る。

【００１８】の「要求蓄積手段に放送要求自体は蓄積
されているが放送はまだ開始されていない各放送用情
報」についての放送開始までの予定所要時間あるいは放
送開始予定時刻は、既に放送要求をしたがまだ放送はさ
れていない順番待ちの状態のときに、放送開始までの時
間あるいは放送予定時刻を知りたいという要求に応える
ことができる。これにより、自分の要求した放送用情報
の放送開始までに例えば別の用事を済ませるといったこ
ともでき、いつ始まるか判らないので単に待っているだ
けという無駄な時間をなくすことができる。

【００１９】一方、の「この次にさらに放送要求がな
された場合の放送用情報」についての放送開始までの予
定所要時間あるいは放送開始予定時刻は、これから放送
要求をしようとしている視聴者にとって、現在の待ち時
間を知りたいという要求に応えることができる。これに
より、例えば、あまり待ち時間が長いのであれば、あえ
て放送要求はしないという選択もできる。

【００２０】そして、上記及びについての放送開始
予定関連情報の表示タイミングについては、請求項４に
示すようにしてもよい。すなわち、放送用情報の放送中
は、上記の「この次にさらに放送要求がなされた場合
の放送用情報」の放送開始までの予定所要時間あるいは
放送開始予定時刻のみを放送用情報に付加して放送し、
一つの放送用情報の放送が終了して次の放送用情報の放
送が開始されるまでの期間は、上記の「要求蓄積手段
に放送要求自体は蓄積されているが放送はまだ開始され
ていない各放送用情報」についての放送開始までの予定
所要時間あるいは放送開始予定時刻も加えた一覧表示映
像を放送するのである。

【００２１】これは、の場合に比べての場合には、
蓄積されている放送要求数分の放送開始までの予定所要
時間あるいは放送開始予定時刻となるので、放送要求数
が多い場合には、一覧表示によって放送中の放送用情報
を隠してしまう部分が多くなり、不都合が生じるおそれ
があるからである。そのため、放送用情報の切り替わる
間を利用してそれらについては表示しようとするのであ
る。なお、放送開始予定の順が早い所定曲（例えば１，
２曲程度まで）分だけ表示するようにしてもよい。もち
ろん、視聴者がテレビジョン放送の受信設備として例え
ば２画面テレビを有していれば、上述した一覧表示画面
を常時片方の１画面に表示させるようにすることも考え
られる。

【００２２】また、と比較すれば、の「この次にさ
らに放送要求がなされた場合の放送用情報」の放送開始
までの予定所要時間あるいは放送開始予定時刻は、常時
表示させておく方が好ましい。これは次の理由による。
例えば、放送開始までの予定所要時間あるいは放送開始
予定時刻を放送用情報の切り替わる間にだけ表示するこ
とも考えられるが、その場合には、現在の待ち時間を知
るのにその切り替わりタイミングまで待たなくてはなら
ない。それを待てなくて、現在の待ち時間を知らずに放
送要求をしてしまった場合には、後で待ち時間が予想外
に長かったことを知り、そういう状況であれば放送要求
をしなかったと後悔する状況も出て来る。

【００２３】また、待ち時間を知るために切り替わりタ
イミングまで待つようにすると、多数の視聴者がその同
じぐらいのタイミングに放送要求をする状況が出てくる
ため、放送要求が集中してしまう。そのため、例えば電
話で放送要求をする場合に電話がつながらないという状
況が生じ易くなる。あるいは、短時間に放送要求が多数
あった場合には、後の方に要求が受け付けられた視聴者
にとっては、表示で見た待ち時間に比べて実際の待ち時
間が予想外に長くなるという事態も生じ易くなる。

【００２４】したがって、本発明のように、この待ち時
間については常時表示しておくことで、視聴者から放送
要求がなされるタイミングが分散され、放送要求を受け
付けて処理するテレビジョン放送センタ側としても都合
がよいし、また視聴者側にとっても上述した不都合が起
こり難くなるので好ましい。

【００２５】一方、視聴者からの放送要求を受け付ける
システムとしては各種考えられるが、例えば請求項５に
示すように、テレビジョン放送センタの要求受付手段
が、視聴者からの放送要求を公衆電話回線を介して受信
し、要求蓄積手段にデータとして自動的に蓄積させるよ
うにすることが考えられる。電話を介し、さらに放送要
求をデータとして自動的に蓄積することで、専用のオペ
レータを必要とせず、またリアルタイム性の向上にとっ
て好ましい。

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

【００２７】このようなテレビジョン放送センタから放
送する放送用情報としては、例えばカラオケ用の情報が
考えられる。請求項６では、視聴者からカラオケ曲を指
定した放送要求を受け付け、要求されたカラオケ曲に応
じたカラオケ演奏音及び背景映像に歌詞テロップが合成
された映像とを含む放送用情報を放送する。

【００２８】もちろん、放送用情報としてカラオケ演奏
音だけを放送してもカラオケとしては成立するが、放送
開始予定関連情報を視聴者側の設備で表示させることを
前提としており、現在のカラオケには、もはや背景映像
に歌詞テロップを合成した映像をカラオケ演奏に併せて
表示させるということが常識化されつつあるので、カラ
オケ演奏音及び背景映像に歌詞テロップが合成された映
像とを含む放送用情報を放送することが好ましいと言え
る。

【００２９】また、放送用情報は、カラオケに関するも
のには限られず、いわゆるミュージックテレビのような
映像と音楽が一体となったものでもよい。その他にも文
字情報的なもの等でもよいが、実際には、１つの放送用
情報があまり長いと意味をなさなくなってくる。そのた
め、１つの放送用情報の放送時間が１時間や２時間とい
ったレベルではなく、数分から長くても１０分程度を上
限とすることが好ましいし、そのような場合に実質的な
効果が出てくる。

【００３０】なお、テレビジョン放送センタにおける情
報供給系統及び伝送チャンネル数が多くなって多重化で
きるのであれば、より長時間の映像内容の提供を行うこ
とも容易であり、映画などのように１つの放送用情報の
所要時間が比較的長いものであっても適用することがで
き、ビデオ・オン・デマンド的なシステムの実現に近づ
くことが可能である。

【００３１】

【発明の実施の形態】以下、本発明のテレビジョン放送
センタを具体化した一実施例を図面を参照しながら説明
する。図１は、本実施例のテレビジョン放送センタ（以
下、単に放送センタと呼ぶ。１０の概略構成を示すブロ
ック図である。図１に示すように、放送センタ１０は、
制御手段及び「放送開始予定関連情報作成手段」として
のホストコンピュータ１１と、「所要時間記憶手段」と
しての外部記憶装置１２と、表示装置１３と、カラオケ
再生装置１４と、テロップ合成装置１５と、「放送手
段」としての放送手段１６と、「要求受付手段」として
の音声応答装置２０とを備えている。また、放送センタ
１０は、公衆電話回線４０を介して多数の加入者電話機
５０と接続されている。

【００３２】各構成装置について、放送センタ１０にお
ける役割あるいは放送システムとの関わりも含めて説明
する。まず、音声応答装置２０は視聴者からの放送要求
を受け付けるためのものである。本放送センタ１０は、
視聴者から個別になされた放送要求を蓄積しておき、そ
の放送要求に応じた放送用情報（本実施例の場合にはカ
ラオケ用の情報）を順次放送していくリクエスト応答機
能を備えているのであるが、視聴者は自宅にあるテレビ
ジョン受信機（図示せず）を視聴しながら、手持ちの加
入者電話機５０により一般の公衆電話回線４０を通し
て、希望するカラオケ用情報の放送を要求する。この放
送要求は、予め定められた「リクエストコード」によっ
て行う。これは、カラオケ視聴の提供に限り、一般のカ
ラオケ装置における「曲番号」と同義のものである。数
字コードによるリクエストであるため、実際には視聴者
が加入者電話機５０のダイヤルもしくはプッシュホンの
押し下げにより上記リクエストコードをトーン発信す
る。このリクエストコードはあらかじめ視聴者に配布物
等によって通知されているものとする。

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

【００３４】音声応答装置２０によって受理されたリク
エストコードは、ホストコンピュータ１１により、その
コードが有効であるかどうか、外部記憶装置１２上のデ
ータベースとの照合により判断され、有効であればホス
トコンピュータ１１内のＣＰＵメモリ１１ｂ（図２参
照）に蓄積される。なお、このＣＰＵメモリ１１ｂが
「要求蓄積手段」に相当する。

【００３５】ホストコンピュータ１１はこの蓄積された
リクエストコードと、外部記憶装置１２内のデータベー
スを基に、「放送開始予定関連情報」としての放送開始
までの予定所要時間あるいは放送開始予定時刻を算出
し、任意のメッセージとして表示すべき文字列を生成す
る。これが、視聴者がカラオケ映像と共に見ることにな
るリクエスト状況のインフォメーションである。生成さ
れたメッセージは、外部記憶装置１２内の文字フォント
データによって画像データとしてホストコンピュータ１
１内のＣＰＵメモリ１１ｂに展開され、これがテロップ
合成装置１５に転送される。

【００３６】また、蓄積されたリクエストコードは、ホ
ストコンピュータ１１によって制御されるカラオケ再生
装置１４に渡され、映像の再生がなされる。この時点で
得られる映像は通常のカラオケ装置と同様の内容であ
り、上述したように、テロップ合成装置１５上に用意さ
れたインフォメーション用の画像との合成がなされるこ
とにより、放送されるべき映像が出力される。

【００３７】表示装置１３はホストコンピュータ１１に
接続されており、これらの状況を表示することができ
る。これは、放送センタ１０のオペレータが確認するた
めに利用される。一方、テロップ合成装置１５から出力
された映像信号はカラオケ再生装置１４から出力される
音声信号と共に放送手段１６によってテレビジョン放送
される。この放送内容は、視聴者側のテレビジョン受信
機などの受信設備にて受信され、カラオケ番組として視
聴可能である。なお、放送センタ１０と視聴者側の受信
設備はＣＡＴＶシステムのように有線で接続されていて
もよいし、通常の放送システムのように無線でもよい。

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

【００３９】外部記憶装置１２は、リクエストコードに
関するデータベースを格納されたホストコンピュータ１
１の外部記憶であり、装置間でデータの読み書きが行わ
れる。これにより、ＣＰＵ１１ａはリクエストコードの
検索・照合と、ログ記録を行うものである。

【００４０】カラオケ再生装置１４はＣＰＵ１１ａと制
御信号により結ばれている、ＣＰＵ１１ａはリクエスト
コード（曲番号）を送信し、同装置１４にカラオケ楽曲
の再生を行わせ、またこの再生の開始・終了などの制御
を行うことができる。また、カラオケ再生装置１４は、
ＣＰＵ１１ａに対して再生の状況（再生中・再生終了
等）を返す。これにより、ＣＰＵ１１ａはリクエストコ
ードによるカラオケ楽曲の再生を行うことができる。

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

【００４２】テロップ合成装置１５とその周辺との信号
を流れを、さらに図３を参照して説明する。テロップ合
成装置１５は、画像表示用のメモリであるＶＲＡＭ１５
ｃと、このＶＲＡＭ１５ｃに読み書きを行い、画像信号
を出力するＶＤＰ１５ａと、外部から入力された映像信
号とＶＤＰ１５ａが出力する画像信号とをスーパーイン
ポーズ方式により合成する映像合成機構１５ｂを備えて
いる。ＣＰＵ１１ａはＶＤＰ１５ａに対して画像の出力
と合成に関する制御を与え、また、ＶＤＰ１５ａを通し
てＶＲＡＭ１５ｃに表示すべき画像を転送する。同時
に、カラオケ再生装置１４は映像信号をテロップ合成装
置１５に伝送する。両者の映像は映像合成機構１５ｂに
より合成がなされ、カラオケ再生装置１４からの映像に
テロップが加わる形で映像信号の出力が完成する。

【００４３】図１５は、この様子を実際の映像例を想定
して説明したものである。図１５（Ａ）はカラオケ再生
装置１４の出力する映像、図１５（Ｂ）はテロップ合成
装置１５のＶＲＡＭ１５ｃに描画される画像、図１５
（Ｃ）は両者の合成がなされた出力映像を表している。
視聴者側の受信設備においては図１５（Ｃ）に示すよう
な出力映像が表示されることとなる。

【００４４】次に、本実施例の放送センタ１０の動作に
ついて、図を参照して説明する。図１０〜図１４はＣＰ
Ｕ１１ａによって実行されるマイクロプログラムの処理
手順を示すフローチャートであり、図４から図９はこの
プログラムが取り扱うデータ構造図である。以下、処理
フローの詳細を説明する。なお、図１０〜図１２はリク
エスト自動受理・登録処理のフローチャート、図１３は
リクエスト再生処理のフローチャート、図１４はテロッ
プ表示処理のフローチャートであり、これらの処理はそ
れぞれ同時に独立して動作するいわゆるマルチタスク処
理である。なお、図１４のテロップ表示処理は、リクエ
スト自動受理・登録処理あるいはリクエスト再生処理か
ら呼び出されるルーチンである。

【００４５】まず、リクエスト自動受理・登録処理（図
１０〜図１２）について説明する。本処理は、加入者側
からの公衆電話回線４０によるリクエストの自動受理
と、そのリクエストのＣＰＵメモリ１１ｂへの登録手順
を示す。なお、この加入者とは単にこの放送センタ１０
からの放送を受信できるという意味ではなく、リクエス
トする権利を有しているものという意味である。例えば
ＣＡＴＶシステムで、そのシステムに加入する際に自動
的にリクエストの権利も与えられる場合には、全てが加
入者となる。なお、通常の無線形式で放送する場合に
は、例えばリクエストをする代わりに所定の料金を徴収
するような契約を別個に行なうことが考えられる。その
場合には、契約をした人だけが加入者となる。

【００４６】まず、図１０の最初のステップＳ１００に
おいて、音声応答装置２０を公衆電話回線４０を介して
の着信が可能な状態に制御し、続くＳ１１０にて、加入
者電話機５０からの着信があるまで待機する。そして、
着信があれば（Ｓ１１０：ＹＥＳ）Ｓ１２０へ移行す
る。

【００４７】Ｓ１２０では、音声応答装置２０より音声
応答メッセージ（例えば「加入者番号を入力してくださ
い」）を送出し、最初に行ってもらう加入者番号の入力
を促す。その後、Ｓ１３０にて、加入者電話機５０より
のダイヤルパルスの発信を待つ。入力された番号は、Ｓ
１４０にて、ＣＰＵメモリ１１ｂ上のリクエスト受付バ
ッファ（図６参照）の加入者コードの領域Ｃ３に格納し
ていく。これを５桁の加入者番号が全て入力されるまで
繰り返す（Ｓ１５０）。

【００４８】５桁の加入者番号が入力されると（Ｓ１５
０：ＹＥＳ）、Ｓ１６０へ移行して、その加入者番号が
有効であるかどうかの照合を行なう。これは、外部記憶
装置１２上の加入者データベース（図９）を照会して行
なう。この照合の結果、有効な番号でないと判断されれ
ば（Ｓ１７０：ＮＯ）、入力のやり直しを求める音声メ
ッセージ（例えば「再入力してください」）を再生し
（Ｓ１８０）、Ｓ１２０へ戻る。

【００４９】最初に入力された加入者番号が有効である
場合、あるいは再度入力された加入者番号が有効であれ
ば（Ｓ１７０：ＹＥＳ）、Ｓ１９０（図１１参照）に移
行する。図１１に示すＳ１９０では、音声応答メッセー
ジを送出し、リクエストコードの入力を促す。続くＳ２
００〜２２０では、ダイヤルパルスの発信を待ち、入力
された番号をリクエスト受付バッファ（図６）のリクエ
ストコードの領域Ｃ２に格納していき、これを５桁のリ
クエストコードがすべて入力されるまで繰り返す。

【００５０】５桁のリクエストコードが入力されると
（Ｓ２２０：ＹＥＳ）、そのリクエストコードの照合を
行なう。これは、外部記憶装置１２上のリクエストデー
タベース（図４）を照会して実行する。そして、Ｓ１４
０で有効な番号であるかどうかを判断する。有効な番号
でないと判断されれば（Ｓ２４０：ＮＯ）、Ｓ２５０へ
移行して、入力のやり直しを求める音声メッセージ（例
えば「再入力してください」）を再生し、Ｓ１９０へ戻
る。

【００５１】最初に入力されたリクエストコードが有効
である場合、あるいは再度入力されたリクエストコード
が有効であれば（Ｓ２４０：ＹＥＳ）、Ｓ２６０の処理
に移行する。Ｓ２６０では、この時点での日時をタイム
スタンプとしてリクエスト受付バッファ（図６）の受付
時刻の領域Ｃ１に書き込む。

【００５２】ここまでの処理が終了すれば、図６に示す
リクエスト受付バッファ上には受付時刻Ｃ１、有効なリ
クエストコードＣ２及び有効な加入者コードＣ３の３要
素が揃い、実際のリクエストの受付が可能になってい
る。そして、Ｓ２７０では、このリクエスト受付バッフ
ァ（図６）の内容をＣＰＵメモリ１１ｂ上のリクエスト
実行テーブル（図５）内の受付ポインタＢ４の示してい
るリクエストコード領域Ｂ２に追加登録する。この追加
登録は、リクエストコードＣ２を受付ポインタＢ４の示
すリクエストコード領域Ｂ２にコピーし、再生フラグＢ
１を「未」とすることにより行われる。なお、初期状態
では再生フラグＢ１にはすべて「無」が、リクエストコ
ードＢ２には不定値が入っているものとする。

【００５３】Ｓ２７０での追加登録の処理終了後、Ｓ２
８０へ移行する。Ｓ２８０では、受付ポインタＢ４をリ
クエスト実行テーブル（図５）上の次の領域に進める。
この動作が、後述するリクエスト再生処理（図１３）の
動作に反映する。さらに、続くＳ２９０（図１２参照）
では、受け付けたリクエストをログ記録として保持する
ために、外部記憶装置１２上のリクエストログ記録（図
７）の受付時刻領域Ｄ１、リクエストコード領域Ｄ２、
加入者コード領域Ｄ３（図６のリクエスト受付バッファ
と同様の要素を持つ。）にそれぞれの要素をコピーす
る。

【００５４】次に、Ｓ３００において、ＣＰＵメモリ１
１ｂ上のテロップ表示値（図８）の要素であるリクエス
ト数Ｅ１の値をインクリメントし、Ｓ３１０にて、累計
所要時間Ｅ２の値にリクエスト受付バッファ（図６）の
リクエストコードＣ２を基に検索したリクエストデータ
ベース（図４）の要素である再生時間Ａ３の値を加算す
る。この動作が、後述するテロップ表示ルーチン（図１
４）の動作に反映する。

【００５５】そして、リクエストの受付が完了したこと
を視聴者に知らせる音声応答メッセージを送出し（Ｓ３
２０）、回線を切断し（Ｓ３３０）、テロップ表示内容
を更新するためテロップ表示ルーチン（Ｓ３４０）を呼
び出して、本リクエスト自動受理・登録処理は完了す
る。なお、この後は、再び着信待ち状態（Ｓ１００）に
戻り、以降の処理を繰り返す。

【００５６】次に、リクエスト再生処理（図１３）につ
いて説明する。本処理は、ＣＰＵメモリ１１ｂ上のリク
エスト実行テーブル（図５）に登録されたリクエストコ
ードの再生の手順を示す。まず、最初のステップＳ４１
０において、リクエスト実行テーブル（図５）内の再生
ポインタＢ３が示す領域より、再生フラグＢ１を取り出
す。再生フラグＢ１が「未」でなければ（Ｓ４２０：Ｎ
Ｏ）、リクエスト実行テーブル（図５）の登録内容の再
生がすべて済んでいる、若しくは登録内容が空であるた
め、そのままリクエスト自動受理・登録処理（図１０か
ら図１２）によるリクエストの追加登録待ちに入る（Ｓ
４３０）。

【００５７】一方、再生フラグＢ１が「未」であれば、
Ｓ４４０へ移行し、リクエストコードＢ２を取り出す。
そして、Ｓ４５０にて、同リクエストコードＢ２をカラ
オケ再生装置１４に渡し、再生の指示を出す。さらに、
Ｓ４６０にて、再生フラグＢ１を「中」に変え、続くＳ
４７０にて、カラオケ再生装置１４の再生状態のチェッ
クを行う。

【００５８】再生の終了がカラオケ再生装置１４より指
示されるまでこれを繰り返す（Ｓ４８０：ＮＯ）。そし
て、再生が終了すると（Ｓ４８０：ＹＥＳ）、Ｓ４９０
へ移行して再生フラグＢ１を「済」に変え、Ｓ５００に
て、再生ポインタＢ３を次のテーブルに移動する。

【００５９】次に、Ｓ５１０において、ＣＰＵメモリ上
１１ｂのテロップ表示値（図８）の要素であるリクエス
ト数Ｅ１の値をデクリメントし、Ｓ５２０にて、累計所
要時間Ｅ２の値から、リクエスト受付バッファ（図６）
のリクエストコードＣ２を基に検索したリクエストデー
タベース（図４）の要素である再生時間Ａ３の値を減算
する。この動作が、後述するテロップ表示ルーチン（図
１４）の動作に反映する。

【００６０】最後にテロップ表示内容を更新するため、
テロップ表示ルーチンを呼び出し（Ｓ５３０）、リクエ
スト再生処理は完了する。なお、この後は、再びＳ４１
０に戻り、次のリクエストの再生を繰り返す。次に、テ
ロップ表示処理（図１４）について説明する。

【００６１】このテロップ表示処理は、リクエスト自動
受理・登録処理におけるＳ３４０、及びリクエスト再生
処理におけるＳ５３０において実行される処理であり、
ＣＰＵメモリ１１ｂ上のテロップ表示値（図８）に基づ
いて合成表示されるテロップ表示内容を更新するルーチ
ンの手順を示す。

【００６２】まず、最初のステップ６１０において、テ
ロップ表示値（図８）に格納されている現在値として、
リクエスト数Ｅ１及び所要時間Ｅ２を読み出す。Ｓ６２
０では、読み出した所要時間を秒単位の値から分単位の
値に変換する。なお、この場合に、分以下を切り捨てて
「何分」とだけ表示してもよいし、「何分何秒」まで表
示してもよい。

【００６３】次に、Ｓ６３０では、Ｓ６２０で得た値を
基に表示内容を文字列として生成する。つまり、「何
分」あるいは「何分何秒」というように表示するための
文字列である。そして、続くＳ６４０では、この文字列
情報を、外部記憶装置１２上に格納されたフォントデー
タによって画像データとしてＣＰＵメモリ１１ｂ上に展
開する。Ｓ６４０の処理の終了後、Ｓ６５０へ移行す
る。

【００６４】Ｓ６５０では、展開された画像データをＣ
ＰＵメモリ１１ｂからテロップ合成装置１５のＶＲＡＭ
１５ｃへ転送し、この画像と、入力映像との合成をテロ
ップ合成装置１５に指示する。テロップ表示ルーチンの
動作はこれで終了する。なお、Ｓ６５０での処理の結
果、上述したように、図１５（Ｃ）に示したような合成
映像の出力が得られる。

【００６５】以上説明した本実施例の放送センタ１０に
よれば、視聴者から個別になされた放送要求を蓄積して
おき、その放送要求に応じた映像を含むカラオケ用情報
を所定の順番に従って順次放送していくことができる。
そして、これだけでなく、図１５（Ｃ）に示すように、
現在のリクエスト状況として、リクエストされている曲
数と待ち時間を合成した映像を常時放送することができ
る。

【００６６】これにより、これからリクエストをしよう
としている視聴者にとって、現在の待ち時間をリアルタ
イムで知ることができ、例えば、あまり待ち時間が長い
のであれば、あえてリクエストをしないという選択もで
きる。そして、この待ち時間が加入者側の受信設備にお
いて常時表示されるように放送しているため、次のよう
な効果がある。

【００６７】例えば、放送用情報の切り替わる間（上記
実施例では、前のカラオケ曲の放送が終了して、次のカ
ラオケ曲の放送が開始する前の間）にだけ表示すること
も考えられるが、その場合には、現在の待ち時間を知る
のにその切り替わりタイミングまで待たなくてはならな
い。それを待てなくて、現在の待ち時間を知らずにリク
エストしてしまった場合には、後で待ち時間が予想外に
長かったことを知り、そういう状態であればリクエスト
しなかったと後悔する状況も出て来る。また、待ち時間
を知るために切り替わりタイミングまで待つようにする
と、多数の視聴者がその同じぐらいのタイミングにリク
エストする状況が出てくるため集中してしまう。そのた
め例えば電話でリクエストをする場合に電話がつながら
ないという状況が生じ易くなる。あるいは、短時間にリ
クエストが多数あった場合には、後の方に要求が受け付
けられた視聴者にとっては、表示で見た待ち時間に比べ
て実際の待ち時間が予想外に長くなるという事態も生じ
易くなる。

【００６８】したがって、待ち時間を常時表示しておく
ことで、視聴者からリクエストがなされるタイミングが
分散され、リクエストを受け付けて処理する放送センタ
１０側としても都合がよいし、また視聴者側にとっても
上述した不都合が起こり難くなるので好ましい。

【００６９】以上、具体例に従って、本発明の実施の形
態について説明したが、本発明はこのような具体例に限
定されるものではなく、発明の要旨を逸脱しない範囲で
様々な実施ができることは言うまでもない。例えば、上
述の実施例では待ち時間、すなわち現在予約されている
分の放送が完了するまでの所要時間を表示していたが、
その代わりに、新たにリクエストをした場合の放送開始
予定時刻を表示させるようにしてもよい。つまり、「次
にリクエストされる曲は何時何分に放送開始されま
す。」といった内容が表示されるようにしてもよい。ま
た、上記「待ち時間」は、主に今後リクエストをしよう
かと考えている視聴者のための便宜を図るものである
が、さらに、ＣＰＵメモリ１１ｂにはリクエストデータ
として受け付けられているが、放送自体はまだ開始され
ていない場合についても、そのリクエスト毎に放送開始
までの予定所要時間あるいは放送開始予定時刻も加えた
一覧表示映像として放送するようにすることも考えられ
る。これは主に、既にリクエストはしたがまだ放送はさ
れていない順番待ちの状態のときに、放送開始までの時
間あるいは放送予定時刻を知りたいという要求に応える
ためである。これにより、自分の要求したリクエスト曲
の放送開始までに例えば別の用事を済ませるといったこ
ともでき、いつ始まるか判らないので単に待っているだ
けという無駄な時間をなくすことができる。

【００７０】なお、リクエスト済みで未放送の曲数が多
いと、一覧表示の占める領域が大きくなり、背景映像を
隠してしまう部分が多くなってしまう可能性もある。し
たがって、カラオケ用映像を放送している最中には、図
１５（Ｃ）に示すように、次のリクエストのための待ち
時間のみを表示し、前の映像が終了して次の映像に切り
替わるまでの期間のみ一覧表示するようにすることが好
ましいと考えられる。但し、背景映像の隠れることがあ
まり気にならないのであれば、放送開始予定の順が早い
所定曲（例えば１，２，３曲程度まで）分だけ表示する
ようにしてもよい。もちろん、視聴者が受信設備として
例えば２画面テレビを有していれば、上述した一覧表示
画面を常時片方の１画面に表示させるようにすることも
考えられる。

【００７１】また、上記実施例では、図４のリクエスト
データベースに記憶される再生時間Ａ３はいわゆるフル
コーラス演奏した場合の時間の１種類しかなかったが、
複数種類の演奏時間を記憶するようにしてもよい。これ
は、通常のカラオケ装置で実施されている「後奏カッ
ト」や「２コーラス」機能を考慮したものである。「後
奏カット」とは、曲中において歌詞のある部分の演奏が
全て終了したところで曲の演奏を中断し、次の曲の演奏
を開始する機能である。また「２コーラス」とは、曲の
２番までの演奏が終了したところで曲の演奏を中断し、
次の曲の演奏を開始する機能である。

【００７２】この場合、リクエストデータベース（図
４）には、再生時間Ａ３として、「フルコーラス」演奏
した場合、「後奏カット」機能を使用した場合、「２コ
ーラス」機能を使用した場合の３種類の時間を曲毎に格
納することとなる。リクエスト受付バッファ（図６）に
は、この３種類の内のいずれが選択されたかを示す情報
も記憶しておき、テロップ表示値（図８）の所要時間Ｅ
２を算出する際に、該当する種類の再生時間を取り出し
て加算等をすることとなる。このように「後奏カット」
や「２コーラス」機能が設定されているかどうかによっ
て、曲の演奏時間を合計する処理で使用する演奏時間を
選択すれば、それぞれに対応した正確な待ち時間を表示
することができる。

【００７３】また、上記実施例では、カラオケ番組の放
送に使用する例を説明したが、本発明は映像を含む放送
用情報を供給するサーバ側が少数であり、放送用情報を
要求するクライアント側が多数であり、両者が遠隔であ
る等の理由で、放送という情報供給形態を採用する状況
であることが応用の主旨である。

【００７４】一方、視聴者からのリクエストを受けるた
めに、上記実施例では公衆電話回線４０を用いている
が、これは、リクエストコードという短い情報を伝達可
能でありさえすれば、通信手段は問わない。また、当然
のことながら、映像ソースとして提供される内容はカラ
オケに限らず、ある程度の統一性のある映像ライブラリ
であれば運用は可能である。そしてまた、放送センタに
おける情報供給系統及び伝送チャンネル数が多くなって
多重化できるのであれば、より長時間の映像内容の提供
を行うことも容易であり、映画などのように１つの放送
用情報の所要時間が比較的長いものであっても適用する
ことができ、ビデオ・オン・デマンド的なシステムの実
現に近づくことが可能である。

【図面の簡単な説明】

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

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

【図３】 テロップ合成装置を中心した信号の流れを示
す説明図である。

【図４】 ホストコンピュータが取り扱うリクエストデ
ータベースのデータ構造図である。

【図５】 ホストコンピュータが取り扱うリクエスト実
行テーブルのデータ構造図である。

【図６】 ホストコンピュータが取り扱うリクエスト受
付バッファのデータ構造図である。

【図７】 ホストコンピュータが取り扱うリクエストロ
グ記録のデータ構造図である。

【図８】 ホストコンピュータが取り扱うテロップ表示
値のデータ構造図である。

【図９】 ホストコンピュータが取り扱う加入者データ
ベースのデータ構造図である。

【図１０】 ホストコンピュータが実行するリクエスト
自動受理・登録処理の一部を示すフローチャートであ
る。

【図１１】 ホストコンピュータが実行するリクエスト
自動受理・登録処理の一部を示すフローチャートであ
る。

【図１２】 ホストコンピュータが実行するリクエスト
自動受理・登録処理の一部を示すフローチャートであ
る。

【図１３】 ホストコンピュータが実行するリクエスト
再生処理を示すフローチャートである。

【図１４】 ホストコンピュータが実行するテロップ表
示処理を示すフローチャートである。

【図１５】 実施例の放送センタが取り扱う映像の想定
図であり、（Ａ）はカラオケ再生装置の出力する映像、
（Ｂ）はテロップ合成装置のＶＲＡＭに描画される画
像、（Ｃ）は両者の合成がなされた出力映像の想定図で
ある。

【符号の説明】

１０…放送センタ １１…ホストコンピ
ュータ １１ａ…ＣＰＵ １１ｂ…ＣＰＵメモ
リ １２…外部記憶装置 １３…表示装置 １４…カラオケ再生装置 １５…テロップ合
成装置 １５ａ…ＶＤＰ １５ｂ…映像合成機
構 １５ｃ…ＶＲＡＭ １６…放送手段 ２０…音声応答装置 ４０…公衆電話回
線 ５０…加入者電話機

Claims (6)

【特許請求の範囲】
1. 【請求項１】 視聴者から個別になされた放送要求を蓄
   積しておくための要求蓄積手段と、 その要求蓄積手段に記憶されている放送要求に応じた映
   像を含む放送用情報を、所定の順番に従って順次放送し
   ていく放送手段とを備えたリクエスト応答機能付きのテ
   レビジョン放送センタにおいて、 前記要求蓄積手段に蓄積されている放送要求に基づき、
   放送要求自体は既に蓄積されているが放送はまだ開始さ
   れていない放送用情報、またはこの次にさらに放送要求
   がなされた場合の当該放送要求に応じた放送用情報の少
   なくともいずれか一方の放送開始予定に関する情報を作
   成する放送開始予定関連情報作成手段を備え、 前記放送手段は、その作成した放送開始予定関連情報
   を、視聴者側に放送する放送用情報に映像形式で常時付
   加した状態で放送可能に構成されていることを特徴とす
   るテレビジョン放送センタ。
2. 【請求項２】 請求項１に記載のテレビジョン放送セン
   タにおいて、 前記放送用情報毎の放送所要時間を記憶する所要時間記
   憶手段を備え、 前記放送開始予定関連情報作成手段は、前記要求蓄積手
   段に蓄積されている放送要求に対応した放送用情報の各
   放送所要時間情報に基づき、該当する放送用情報の放送
   開始までの予定所要時間あるいは放送開始予定時刻を算
   出し、前記放送開始予定関連情報とすることを特徴とす
   るテレビジョン放送センタ。
3. 【請求項３】 請求項２に記載のテレビジョン放送セン
   タにおいて、 前記放送開始予定関連情報作成手段は、前記要求蓄積手
   段に放送要求自体は蓄積されているが放送はまだ開始さ
   れていない各放送用情報及びこの次にさらに放送要求が
   なされた場合の当該放送要求に応じた放送用情報につい
   て、それぞれ放送開始までの予定所要時間あるいは放送
   開始予定時刻を算出し、前記放送開始予定関連情報とす
   ることを特徴とするテレビジョン放送センタ。
4. 【請求項４】 請求項３に記載のテレビジョン放送セン
   タにおいて、 前記放送手段は、放送用情報の放送中は、この次にさら
   に放送要求がなされた場合の放送用情報の放送開始まで
   の予定所要時間あるいは放送開始予定時刻のみを放送用
   情報に付加して放送し、一つの放送用情報の放送が終了
   して次の放送用情報の放送が開始されるまでの期間は、
   前記要求蓄積手段に放送要求自体は蓄積されているが放
   送はまだ開始されていない各放送用情報についての放送
   開始までの予定所要時間あるいは放送開始予定時刻も加
   えた一覧表示映像を放送するように構成されていること
   を特徴とするテレビジョン放送センタ。
5. 【請求項５】 請求項１〜４のいずれかに記載のテレビ
   ジョン放送センタにおいて、 前記視聴者からの放送要求を通信回線を介して受信し、
   前記要求蓄積手段にデータとして自動的に蓄積させる要
   求受付手段を備えることを特徴とするテレビジョン放送
   センタ。
6. 【請求項６】 請求項１〜５のいずれかに記載のテレビ
   ジョン放送センタにおいて、 前記視聴者からの放送要求は、カラオケ曲を指定した要
   求であり、 前記放送手段が放送する放送用情報は、要求されたカラ
   オケ曲に応じたカラオケ演奏音及び背景映像に歌詞テロ
   ップが合成された映像とを含むものであることを特徴と
   するテレビジョン放送センタ。