(57)【特許請求の範囲】
【請求項１】
視聴者から個別になされた複数の放送要求を、基本的には要求時期が早い程早く放送されるように記憶しておく予約順番記憶手段と、
その予約順番記憶手段に記憶されている予約順番に従って、順次対応する放送要求に応じた放送用情報を放送していく放送手段と
を備えたリクエスト応答機能付きの放送センタにおいて、
前記視聴者からの新規予約候補の放送要求が、既に記憶されている予約順番が最後の放送要求と同一であるかどうかを判断し、同一の放送要求でない場合には通常の順番で新規予約させ、同一の放送要求である場合には、前記予約順番が最後の放送要求を、それよりも予約順番が早い放送要求と入れ替えるか又はその前に挿入した上で新規予約させるか、あるいは前記新規予約候補の放送要求を、前記予約順番が最後の放送要求よりも予約順番が早い放送要求の前に挿入して新規予約させる新規予約制御手段を備えていることを特徴とする放送センタ。
【請求項２】
前記新規予約制御手段は、前記新規予約候補の放送要求が、前記予約順番が最後の放送要求と同一であっても、前記予約順番が最後の放送要求又は前記新規予約候補の放送要求が、入れ替え対象となる放送要求と同一の場合及び入れ替え又は挿入を行った際の予約順番が前後の放送要求のいずれかと同一の場合には、前記入れ替え又は挿入処理を実行しないよう構成されていることを特徴とする請求項１に記載の放送センタ。
【請求項３】
前記放送手段による放送中あるいは放送が終了した放送用情報に対応する放送要求については、前記新規予約制御手段による予約順番が最後の放送要求との入れ替え又は挿入対象から除外するようにしたことを特徴とする請求項１又は２に記載の放送センタ。
【請求項４】
前記視聴者からの放送要求の受け付けは、所定のガイダンス用音声情報を電話回線を介して視聴者側に送信し、視聴者識別情報や放送要求識別情報等をそのガイダンス用音声情報に対する返答として受信するように構成されていることを特徴とする請求項１〜３のいずれかに記載の放送センタ。
【請求項５】
前記視聴者からの放送要求は、カラオケ曲を指定した要求であり、前記放送手段は、音声情報と映像情報が送信可能なテレビジョン放送手段であると共に、当該放送手段が放送する放送用情報は、要求されたカラオケ曲に応じたカラオケ演奏音及び背景映像に歌詞テロップが合成された映像とを含むものであることを特徴とする請求項１〜４のいずれかに記載の放送センタ。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、電話回線を使用して視聴者から個別になされた放送要求に応じた放送用情報を、所定の順番に従って順次放送していくリクエスト応答機能付きの放送センタに関する。
【０００２】
【従来の技術及び発明が解決しようとする課題】
現在、ＣＡＴＶシステム等のローカルなテレビジョン放送センタと加入者端末との間において、双方向テレビジョンと呼ばれるＴＶ放送の新しい形態が普及しつつある。ただし、これらは一般にビデオ・オン・デマンド（ＶＯＤ）と呼ばれる視聴者があたかも自宅のビデオデッキで好みの映像を視聴しているかのように映像を宅配するシステムとは違い、あくまでも不特定多数に映像を発信する「放送」の枠を出ていない。つまり、視聴者から個別になされた放送要求を蓄積しておき、その放送要求に応じた放送用情報を、所定の順番に従って順次放送していくという限定的な双方向テレビジョンシステムである。
【０００３】
このようなシステムにおけるテレビジョン放送センタは、次々にやってくる視聴者からの放送要求を一時的に蓄積し、要求時期が早い程早く放送されるように放送用情報を放送していくのであるが、当然ながらこのような形態であれば、視聴者からの放送要求のスピードが、その要求に応じた放送用情報の放送・消化のスピードを上回る事態が発生する。すると、放送要求は蓄積してしまい、要求した視聴者の待ち時間が長くなってしまう。
【０００４】
ところで、このような形態であってもカラオケ番組と呼ばれるカラオケ楽曲の放送のみを取り扱う番組時間枠（もしくは設けられた専用のチャンネル）等であれば実際の運用を行うことが可能な程度に上記の問題は縮小する。カラオケの場合は１曲の所要時間が数分程度であり、要求数が少なければ、待ち時間もあまり長くはならないからである。
【０００５】
ただし、このようなリクエスト応答タイプの放送システムにおけるカラオケ番組であっても、同じ曲が連続してリクエストされた場合に、そのリクエストを受け付けた順番通りに放送してしまうと、同じ曲を続けて放送してしまうこととなる。リクエスト応答タイプといっても、そのリクエストした人だけでなく、それ以外の人も視聴している。したがって、同じ曲が連続して演奏されることは、そのカラオケ番組の視聴者全員に対して不快感を生じさせるものである。
【０００６】
なお、これはＣＡＴＶ等のテレビジョン放送に限らずラジオ放送あるいはその他の放送に関しても同様の問題点が考えられる。
本発明は、上述した問題点を解決するためになされたものであり、同じ放送用情報が連続して放送されることを防止し、視聴者の不快感を無くして、放送システムの好適な運用を図ることを目的としている。
【０００７】
【課題を解決するための手段及び発明の効果】
この目的を達成するためになされた請求項１記載の放送センタは、
視聴者から個別になされた複数の放送要求を、基本的には要求時期が早い程早く放送されるように記憶しておく予約順番記憶手段と、
その予約順番記憶手段に記憶されている予約順番に従って、順次対応する放送要求に応じた放送用情報を放送していく放送手段と
を備えたリクエスト応答機能付きの放送センタにおいて、
前記視聴者からの新規予約候補の放送要求が、既に記憶されている予約順番が最後の放送要求と同一であるかどうかを判断し、同一の放送要求でない場合には通常の順番で新規予約させ、同一の放送要求である場合には、前記予約順番が最後の放送要求を、それよりも予約順番が早い放送要求と入れ替えるか又はその前に挿入した上で新規予約させるか、あるいは前記新規予約候補の放送要求を、前記予約順番が最後の放送要求よりも予約順番が早い放送要求の前に挿入して新規予約させる新規予約制御手段を備えていることを特徴とする。
【０００８】
本発明の放送センタによれば、予約順番記憶手段が、視聴者から個別になされた放送要求を記憶しておく。そして、放送手段は、その予約順番記憶手段に記憶されている予約順番に従って、順次対応する放送要求に応じた放送用情報を放送していく。このように基本的な放送処理を実行していくのであるが、ここで、次のような予約に関する処理を実行する。
【０００９】
すなわち、新規予約制御手段は、既に記憶されている予約順番が最後の放送要求と同一であるかどうかを判断し、同一の放送要求でない場合には通常の順番で新規予約させる。一方、同一の放送要求である場合には、次の（１），（２）のいずれかを行なう。
【００１０】
（１）予約順番が最後の放送要求を、それよりも予約順番が早い放送要求と入れ替えるか又はその前に挿入した上で新規予約させる。
（２）新規予約候補の放送要求を、予約順番が最後の放送要求よりも予約順番が早い放送要求の前に挿入して新規予約させる。
【００１１】
つまり、これから新規予約しようとする放送要求が、その時点での予約順番が最後の放送要求と同一の場合には、そのまま新規予約してしまうと、同一の放送要求が連続してしまうので、これを避けるために、予約順番を組替えての新規予約処理を行なうのである。
【００１２】
例えば、１→２→３→４の順番で放送要求が予約されていた場合に、続けて５を予約してしまうと４と５の放送要求が同じになってしまう場合を考える。上記（１）の場合には、予約順番が最後の放送要求である「４」を移動させる。例えば、その「４」よりも予約順番が早い放送要求（つまり、１，２，３のいずれか）と入れ替えるか又はその前に挿入してから５を新規予約する。
【００１３】
▲１▼「１」と入れ替える場合には、予約順番が４→２→３→１→５となる。
▲２▼「２」と入れ替える場合には、予約順番が１→４→３→２→５となる。
▲３▼「３」と入れ替える場合には、予約順番が１→２→４→３→５となる。
▲４▼「１」の前に挿入する場合には、予約順番が４→１→２→３→５となる。
【００１４】
▲５▼「２」の前に挿入する場合には、予約順番が１→４→２→３→５となる。
▲６▼「３」の前に挿入する場合には、予約順番が１→２→４→３→５となる。
これら▲１▼〜▲６▼のいずれの場合にも、「４」と「５」の予約順番は連続しない。
一方、上記（２）の場合には、新規予約候補の放送要求である「５」を、予約順番が最後の放送要求である「４」よりも予約順番が早い放送要求（つまり、１，２，３のいずれか）の前に挿入して新規予約する。
【００１５】
▲１▼「１」の前に挿入する場合には、予約順番が５→１→２→３→４となる。
▲２▼「２」の前に挿入する場合には、予約順番が１→５→２→３→４となる。
▲３▼「３」の前に挿入する場合には、予約順番が１→２→５→３→４となる。
これら▲１▼〜▲３▼のいずれの場合にも、「４」と「５」の予約順番は連続しない。
【００１６】
このように、入れ替え又は挿入対象としては１つ前のものでも２つ以上前のものでも構わない。これにより、同一の放送要求が連続して新規予約されることが禁止され、同一の放送用情報が連続して放送されることが防止される。その結果、視聴者の不快感を無くして、放送システムの好適な運用を図ることができる。
【００１７】
なお、前記新規予約制御手段による入れ替え制御に関しては、請求項２に示すように、新規予約候補の放送要求が、予約順番が最後の放送要求と同一であっても、予約順番が最後の放送要求又は前記新規予約候補の放送要求が、入れ替え対象となる放送要求と同一の場合及び入れ替え又は挿入を行った際の予約順番が前後の放送要求のいずれかと同一の場合には、入れ替え又は挿入処理を実行しないようにすることが好ましい。この場合には入れ替えても、結局は同一の放送要求が連続してしまうこととなるからである。
【００１８】
また、入れ替え又は挿入対象としては１つ前のものでも２つ以上前のものでも構わないことは上述したが、その入れ替え又は挿入対象の放送要求と同一の場合に入れ替え処理を実行しない制御と合わせて次のようにしてもよい。つまり、最初は１つ前の放送要求を入れ替え又は挿入対象として、放送要求が連続するかどうかを判断し、連続する場合には、次に２つ前の放送要求を入れ替え又は挿入対象として放送要求が連続するかどうかを判断する、という具合いに、入れ替え又は挿入可能な放送要求が見つかるまで順次入れ替え又は挿入対象を変更して判断していくことも考えられる。
【００１９】
そしてまた、どのような放送要求であっても入れ替え又は挿入対象となるというのではなく、所定の適正条件がある。それは、まだ放送手段による放送が開始されていないということである。そのため、請求項３に示すように、放送手段による放送中あるいは放送が終了した放送用情報に対応する放送要求については、新規予約制御手段による予約順番が最後の放送要求との入れ替え又は挿入対象から除外するようにすることが好ましい。これは、例えばその放送要求自体を予約順番記憶手段から削除してもよいし、また識別フラグを立てて、入れ替え又は挿入対象の判断には用いないようにしてもよい。
【００２０】
一方、視聴者からの放送要求を受け付ける場合には、例えば電話回線を介して行なうことが考えられる。その際、請求項４に示すように、所定のガイダンス用音声情報を電話回線を介して視聴者側に送信し、視聴者識別情報や放送要求内容識別情報等をそのガイダンス用音声情報に対する返答として受信するようにしてもよい。例えば、視聴者からの電話を自動着信し、電子音声による案内を行う音声応答機能と、電話によるダイヤルトーンを使用したコードの発信を受信するコード受信機能を備え、音声応答機能によって所定のガイダンス音声を流し、それにしたがって視聴者が放送要求として例えば要求するカラオケの曲番号や視聴者識別番号等をプッシュボタン等で入力し、それをダイヤルトーンを使用したコードとして受信するようにすれば便利である。
【００２１】
また、放送センタから放送する放送用情報としては、例えばカラオケ用の情報が考えられる。この場合、請求項５に示すように、放送手段は、音声情報と映像情報が送信可能なテレビジョン放送手段であると共に、放送手段が放送する放送用情報は、要求されたカラオケ曲に応じたカラオケ演奏音及び背景映像に歌詞テロップが合成された映像とを含むようにすることが考えられる。
【００２２】
もちろん、放送用情報としてカラオケ演奏音だけを放送してもカラオケとしては成立するが、現在のカラオケには、もはや背景映像に歌詞テロップを合成した映像をカラオケ演奏に併せて表示させるということが常識化されつつあるので、カラオケ演奏音及び背景映像に歌詞テロップが合成された映像とを含む放送用情報を放送することが好ましいと言える。この場合、いわゆるＣＡＴＶのように有線で放送センタと加入者端末を接続してもよいし、通常の放送システムのように無線のままでもよい。さらには、映像情報だけという場合も考えられる。
【００２３】
【発明の実施の形態】
以下、本発明の放送センタを具体化した一実施例を図面を参照しながら説明する。
図１は、本実施例の放送センタ１０の概略構成を示すブロック図である。図１に示すように、放送センタ１０は、「新規予約制御手段」に相当するホストコンピュータ１１と、外部記憶装置１２と、表示装置１３と、カラオケ再生装置１４と、「放送手段」としての放送手段１６と、音声応答装置２０とを備えている。また、放送センタ１０は、公衆電話回線４０を介して多数の加入者電話機５０と接続されている。
【００２４】
各構成装置について、放送センタ１０における役割あるいは放送システムとの関わりも含めて説明する。
まず、音声応答装置２０は視聴者からの放送要求を受け付け、さらにその放送要求に応じた放送用情報の放送開始予定に関する情報を音声情報として応答するためのものである。本放送センタ１０は、視聴者から個別になされた放送要求を蓄積しておき、その放送要求に応じた放送用情報（本実施例の場合にはカラオケ用の情報）を順次放送していくリクエスト応答機能を備えているのであるが、視聴者は自宅にあるところのケーブルテレビによって本放送センタ１０に接続されたテレビジョン受信機（図示せず）を視聴しながら、手持ちの加入者電話機５０により一般の公衆電話回線４０を通して、希望するカラオケ用情報の放送を要求する。この放送要求は、予め定められた「リクエストコード」によって行う。これは、カラオケ視聴の提供に限り、一般のカラオケ装置における「曲番号」と同義のものである。数字コードによるリクエストであるため、実際には視聴者が加入者電話機５０のダイヤルもしくはプッシュホンの押し下げにより上記リクエストコードをトーン発信する。このリクエストコードはあらかじめ視聴者に配布物等によって通知されているものとする。
【００２５】
この視聴者からの通話は放送センタ１０において音声応答装置２０により自動的に受理される。音声応答装置２０は内蔵された合成音声手段（図示せず）により予め登録されたメッセージを送出し、視聴者にリクエストコードの入力と、そのガイダンスを促すものであり、ホストコンピュータ１１により制御され、上記した通話の受話、メッセージの送話からパルスコードの受信までを行う。
【００２６】
音声応答装置２０によって受理されたリクエストコードは、ホストコンピュータ１１により、そのコードが有効であるかどうか、外部記憶装置１２上のデータベースとの照合により判断され、有効であり、かつ所定の条件を満たしていればホストコンピュータ１１内のＣＰＵメモリ１１ｂ（図２参照）に蓄積される。なお、このＣＰＵメモリ１１ｂが「予約順番記憶手段」に相当する。
【００２７】
ホストコンピュータ１１はこの蓄積されたリクエストコードと、外部記憶装置１２内のデータベースを基に、リクエスト実行テーブル（図３参照）を作成し、このリクエスト実行テーブルに従う順番で蓄積されたリクエストコードがカラオケ再生装置１４に渡され、カラオケ演奏が実行されていく。
【００２８】
なお、本実施例のカラオケ再生装置１４は、カラオケ演奏音を再生すると共に、歌詞テロップの合成された背景映像も再生できるものである。したがって、放送手段１６は、テレビジョン放送手段である。なお、発明の主旨を考えると映像がなくても構わないので、カラオケ再生装置１４はカラオケ演奏音だけを再生するものとし、放送手段１６がいわゆるラジオ放送手段であっても構わない。
【００２９】
放送手段１６によって放送された放送内容は、視聴者側のテレビジョン受信機などの受信設備にて受信され、カラオケ番組として視聴可能である。なお、放送センタ１０と視聴者側の受信設備はＣＡＴＶシステムのように有線で接続されていてもよいし、通常の放送システムのように無線でもよい。
【００３０】
表示装置１３はホストコンピュータ１１に接続されており、これらの状況を表示することができる。これは、放送センタ１０のオペレータが確認するために利用される。
続いて、図２を参照して、ホストコンピュータ１１を中心とした信号の流れを説明する。
【００３１】
図２に示すように、音声応答装置２０はホストコンピュータ１１のＣＰＵ１１ａと制御信号によって結ばれている。ＣＰＵ１１ａは音声応答装置２０に対して公衆電話回線４０（図１参照）の着信待ちに関する制御、着信後の同装置２０内の音声メッセージの送話に関する制御（複数のメッセージの内の選択）を行う。音声応答装置２０はホストコンピュータ１１に対して公衆電話回線４０を通じて受信したダイヤルパルスを数値情報として返す。これにより、公衆電話回線４０による視聴者リクエストの自動受理を行うものである。音声応答装置２０より返された数値はＣＰＵメモリ１１ｂに格納される。
【００３２】
外部記憶装置１２は、リクエストコードに関するデータベースを格納されたホストコンピュータ１１の外部記憶であり、装置間でデータの読み書きが行われる。これにより、ＣＰＵ１１ａはリクエストコードの検索・照合と、ログ記憶を行うものである。
【００３３】
カラオケ再生装置１４はＣＰＵ１１ａと制御信号により結ばれている、ＣＰＵ１１ａはリクエストコード（曲番号）を送信し、同装置１４にカラオケ楽曲の再生を行わせ、またこの再生の開始・終了などの制御を行うことができる。また、カラオケ再生装置１４は、ＣＰＵ１１ａに対して再生の状況（再生中・再生終了等）を返す。これにより、ＣＰＵ１１ａはリクエストコードによるカラオケ楽曲の再生を行うことができる。
【００３４】
次に、本実施例の放送センタ１０の動作について、図を参照して説明する。
図８〜図１１はＣＰＵ１１ａによって実行されるプログラムの処理手順を示すフローチャートであり、図３〜図７はこのプログラムが取り扱うデータ構造図である。以下、処理フローの詳細を説明する。なお、図８〜図１０は、リクエスト自動受理・予約処理のフローチャート、図１１は、リクエスト再生処理のフローチャートであり、これらの処理はそれぞれ同時に独立して動作するいわゆるマルチタスク処理である。
【００３５】
まず、リクエスト自動受理・予約処理（図８〜図１０）について説明する。
本処理は、加入者側からの公衆電話回線４０によるリクエストの自動受理と、そのリクエストのＣＰＵメモリ１１ｂへの予約手順を示す。なお、この加入者とは単にこの放送センタ１０からの放送を受信できるという意味ではなく、リクエストする権利を有しているものという意味である。例えばＣＡＴＶシステムで、そのシステムに加入する際に自動的にリクエストの権利も与えられる場合には、全てが加入者となる。なお、通常の無線形式で放送する場合には、例えばリクエストをする代わりに所定の料金を徴収するような契約を別個に行なうことが考えられる。その場合には、契約をした人だけが加入者となる。
【００３６】
まず、図８の最初のステップＳ１００において、音声応答装置２０を公衆電話回線４０を介しての着信が可能な状態に制御し、続くＳ１１０にて、加入者電話機５０からの着信があるまで待機する。そして、着信があれば（Ｓ１１０：ＹＥＳ）、Ｓ１２０へ移行する。
【００３７】
Ｓ１２０では、音声応答装置２０より音声応答メッセージ（例えば「加入者番号を入力してください」）を送出し、最初に行ってもらう加入者番号の入力を促す。その後、Ｓ１３０にて、加入者電話機５０よりのダイヤルパルスの発信を待つ。入力された番号は、Ｓ１４０にて、ＣＰＵメモリ１１ｂ上のリクエスト受付バッファ（図５参照）の加入者コードの領域Ｃ３に格納していく。これを５桁の加入者番号が全て入力されるまで繰り返す（Ｓ１５０）。
【００３８】
５桁の加入者番号が入力されると（Ｓ１５０：ＹＥＳ）、Ｓ１６０へ移行して、その加入者番号が有効であるかどうかの照合を行なう。これは、外部記憶装置１２上の加入者データベース（図７）を照会して行なう。
この照合の結果、有効な番号でないと判断されれば（Ｓ１７０：ＮＯ）、入力のやり直しを求める音声メッセージ（例えば「加入者番号を再入力してください」）を再生し（Ｓ１８０）、Ｓ１３０へ戻る。
【００３９】
最初に入力された加入者番号、あるいは再度入力された加入者番号が有効であれば（Ｓ１７０：ＹＥＳ）、Ｓ１９０（図９参照）に移行する。
Ｓ１９０では、音声応答メッセージを送出し、リクエストコードの入力を促す。続くＳ２００〜２２０では、ダイヤルパルスの発信を待ち、入力された番号をリクエスト受付バッファ（図５）のリクエストコードの領域Ｃ２に格納していき、これを５桁のリクエストコードがすべて入力されるまで繰り返す。
【００４０】
５桁のリクエストコードが入力されると（Ｓ２２０：ＹＥＳ）、そのリクエストコードの照合を行なう。これは、外部記憶装置１２上のリクエストデータベース（図３）を照会して実行する。そして、Ｓ１４０で有効な番号であるかどうかを判断する。有効な番号でないと判断されれば（Ｓ２４０：ＮＯ）、Ｓ２４５へ移行して、入力のやり直しを求める音声メッセージ（例えば「リクエストコードを再入力してください」）を再生し、Ｓ２００へ戻る。
【００４１】
最初に入力されたリクエストコードが有効である場合、あるいは再度入力されたリクエストコードが有効であれば（Ｓ２４０：ＹＥＳ）、Ｓ２５０の処理に移行する。
Ｓ２５０においては、リクエストを受け付けて新規登録する旨を視聴者側に知らせるための音声応答メッセージを送出し、Ｓ２６０では回線を切断する。その後は、図１０のＳ２７０へ移行して、新規予約の具体的処理を実行する。
【００４２】
ここで、受け付けたリクエストを予約しておくためのリクエスト実行テーブルについて説明しておく。このリクエスト実行テーブルは、図４に示すように、再生フラグＢ１及びリクエストコードＢ２の２つの項目からなっている。新規予約は、リクエスト受付バッファ（図５）の内容をリクエスト実行テーブル（図４）内の受付ポインタＢ５の示しているリクエストコード領域Ｂ２に登録させて行なう。この新規予約は、リクエストコードＣ２を受付ポインタＢ５の示すリクエストコード領域Ｂ２にコピーし、再生フラグＢ１を「未」とすることにより行われる。なお、初期状態では再生フラグＢ１にはすべて「無」が、リクエストコードＢ２には不定値が入っているものとする。
【００４３】
図１０に戻り、Ｓ２７０では、受け付けた日時をタイムスタンプとしてリクエスト受付バッファ（図５）の受付時刻の領域Ｃ１に書き込む。ここまでの処理が終了すれば、図５に示すリクエスト受付バッファ上には受付時刻Ｃ１、有効なリクエストコードＣ２及び有効な加入者コードＣ３の３要素が揃い、実際のリクエストの受付が可能になる。
【００４４】
そのため、まずＳ２８０〜Ｓ３４０において、そのまま新規予約してよいかどうかを判断を行い、そのまま新規予約できない場合には所定の入れ替え処理を実行する等してして、３５０へ移行する。Ｓ３５０においては、リクエスト受付バッファ（図５）の内容をリクエスト実行テーブル（図４）内の受付ポインタＢ５の示しているリクエストコード領域Ｂ２に新規予約する。この新規予約は、リクエスト受付バッファ（図５）リクエストコードＣ２を受付ポインタの示すリクエストコード領域Ｂ２にコピーし、再生フラグＢ１を「未」とすることにより行われることは上述した。
【００４５】
続いて、Ｓ２８０〜Ｓ３４０の処理について説明する。なお、ここでの処理内容の理解を容易にするために、図１２（Ａ）に示すように、リクエスト実行テーブルの受付ポインタＢ５の位置にリクエストコード「０１８２６」を新規予約する場合を例にとって説明する。
【００４６】
まずＳ２８０では、受付ポインタＢ５の位置の１つ前のリクエストコードを読み、続くＳ２９０にて、それがこれから新規予約しようとするリクエストコード「０１８２６」と同一かどうかを判断する。もしも、これが同一でなければ（Ｓ２９０：ＮＯ）、リクエストコードは連続しないことになるので、そのままＳ３５０へ移行して、新規予約を行なう。
【００４７】
一方、Ｓ２９０で肯定判断、すなわち、１つ前のリクエストコードと同一である場合には、そのまま新規予約してしまうと連続したリクエストコードが予約されてしまう。例えば、図１２（Ａ）に示す場合では、新規予約しようとするリクエストコード「０１８２６」と受付ポインタＢ５の位置の１つ前（図中▲１▼で示す）のリクエストコード「０１８２６」とが同一なので、この場合には、所定の条件が成立すれば、図中▲１▼で示す１つ前のリクエストコードと図中▲２▼で示す２つ前のリクエストコードとを入れ替えることによって、新規予約してもリクエストコードが連続しないようにする制御を行なう。
【００４８】
すなわち、Ｓ３００では、その受付ポインタＢ５の位置の１つ前（図中▲１▼）のリクエストコードの再生フラグＢ１が「中」であるかどうかを判断する。もしも再生中を示すフラグとなっていたら（Ｓ３００：ＹＥＳ）、そのリクエストコードは移動させることはできない。したがって、入れ替え処理も不可能なので、この場合には、そのままＳ３５０へ移行して新規予約を実行する。
【００４９】
一方、再生中を示すフラグでない、つまりこの場合には「未」となっていたら（Ｓ３００：ＮＯ）、そのリクエストコードを移動させることが可能なので、Ｓ３１０へ移行する。図１２（Ａ）の場合には、「未」となっているので、続くＳ３１０〜Ｓ３３０において入れ替え先に関する条件を判断する。
【００５０】
まずＳ３１０では、受付ポインタＢ５の位置の２つ前（図中▲２▼）と３つ前（図中３）のリクエストコードを読み出し、続くＳ３２０では、受付ポインタＢ５の位置の１つ前（図中▲１▼）のリクエストコードが、それら２つのリクエストコードの内のいずれか一方とでも同一かどうかを判断する。
【００５１】
そして、いずれとも同一でない場合には（Ｓ３２０：ＮＯ）、Ｓ３３０へ移行して、２つ前（図中▲２▼）とリクエストコードの再生フラグＢ１が「中」であるかどうかを判断する。これが再生中でなければ（Ｓ３３０：ＮＯ）、Ｓ３４０へ移行して、受付ポインタＢ５の位置の１つ前（図中▲１▼）のリクエストコードと２つ前（図中▲２▼）のリクエストコードとを入れ替える。
【００５２】
図１２（Ａ）に示す具体例で説明すれば、Ｓ３１０で読み込んだ２つのリクエストコードは「０１３０１」と「０３０８０」であり、受付ポインタＢ５の位置の１つ前（図中▲１▼）のリクエストコード「０１８２６」とは異なる。そして、Ｓ３３０の判断においても、２つ前（図中▲２▼）のリクエストコードに対する再生フラグは「未」であるため、Ｓ３４０にて、受付ポインタＢ５の位置の１つ前（図中▲１▼）のリクエストコードである「０１８２６」と２つ前（図中▲２▼）のリクエストコードである「０１３０１」とを入れ替える。
【００５３】
このように入れ替え処理をしてから、新規予約をした場合のリクエスト実行テーブルを図１２（Ｂ）に示す。▲１▼と▲２▼の順番が入れ替わっており、「０１８２６」のリクエストコードが新規予約されている。
図１２（Ｂ）には入れ替え処理が実行された場合のテーブルを示したが、Ｓ３２０とＳ３３０の判断結果によっては、入れ替え処理を実行しない場合もある。それについて説明する。
【００５４】
まず、上記Ｓ３２０で肯定判断、すなわち受付ポインタＢ５の位置の１つ前（図中▲１▼）のリクエストコードが、２つ前あるいは３つ前のリクエストコードの内のいずれか一方とでも同一である場合には、Ｓ３４０で入れ替え処理をしても結局はリクエストコードが連続してしまう。なお、１つ前のリクエストコードが、２つ前のリクエストコードとは異なるが３つ前のリクエストコードと同一の場合には、Ｓ３４０にて入れ替え処理を実行すれば、新規予約するリクエストコードとその前のリクエストコードとは連続しないが、今度は２つ前のリクエストコードと３つ前のリクエストコードとが連続してしまうこととなる。つまり、リクエスト実行テーブルにおいて、新規予約する場合のリクエストコードの連続を避けるために入れ替え処理をしたために、先に予約していたリクエストコード同士を連続させてしまうという不都合が生じるので、この場合にも入れ替え処理を実行しないこととしたのである。
【００５５】
一方、Ｓ３３０で２つ前（図中▲２▼）のリクエストコードの再生フラグＢ１が「中」であれば、入れ替え処理を実行しない。これは、上述したＳ３００での判断と同様の理由である。つまり、再生フラグＢ１が「中」となっていたら、そのリクエストコードは移動させることはできない。そのため、入れ替え処理も不可能なので、そのままＳ３５０へ移行して新規予約を実行することとなる。なお、２つ前（図中▲２▼）のリクエストコードの再生フラグＢ１については「中」であっても関係ない。これは移動させる対象ではないからである。
【００５６】
このようにして、入れ替えが可能な条件が成立した場合に限ってＳ３４０での入れ替え処理を実行し、その上でＳ３５０の新規予約を実行する。また、それ以外の場合には入れ替え処理を行なうことなく、そのままＳ３５０の新規予約をする。
【００５７】
Ｓ３５０での新規予約の処理終了後は、Ｓ３６０へ移行して、受付ポインタＢ５をリクエスト実行テーブル（図４）上の次の領域に進める。この動作が、後述するリクエスト再生処理（図１１）の動作に反映する。さらに、続くＳ３７０では、受け付けたリクエストをログとして保持するために、外部記憶装置１２上のリクエストログ記憶部（図６）の受付時刻領域Ｄ１、リクエストコード領域Ｄ２、加入者コード領域Ｄ３（図５のリクエスト受付バッファと同様の要素を持つ。）にそれぞれの要素をコピーする。なお、この後は、再び着信待ち状態（図８のＳ１００）に戻り、以降の処理を繰り返す。
【００５８】
次に、リクエスト再生処理（図１１）について説明する。
本処理は、ＣＰＵメモリ１１ｂ上のリクエスト実行テーブル（図４）に予約されたリクエストコードの再生の手順を示す。
まず、最初のステップＳ４１０において、リクエスト実行テーブル（図４）内の再生ポインタＢ４が示す領域より、再生フラグＢ１を取り出す。再生フラグＢ１が「未」でなければ（Ｓ４２０：ＮＯ）、リクエスト実行テーブル（図４）の予約内容の再生がすべて済んでいる、若しくは予約内容が空であるため、そのままリクエスト自動受理・予約処理（図８〜図１０）によるリクエストの新規予約待ちに入る（Ｓ４３０）。
【００５９】
一方、再生フラグＢ１が「未」であれば、Ｓ４４０へ移行し、リクエストコードＢ２を取り出す。そして、Ｓ４５０にて、同リクエストコードＢ２をカラオケ再生装置１４に渡し、再生の指示を出す。さらに、Ｓ４６０にて、再生フラグＢ１を「中」に変え、続くＳ４７０にて、カラオケ再生装置１４の再生状態のチェックを行う。
【００６０】
再生の終了がカラオケ再生装置１４より指示されるまでこれを繰り返す（Ｓ４８０：ＮＯ）。そして、再生が終了すると（Ｓ４８０：ＹＥＳ）、Ｓ４９０へ移行して再生フラグＢ１を「済」に変え、Ｓ５００にて、再生ポインタＢ４を次のテーブルに移動する。なお、この後は、再びＳ４１０に戻り、次のリクエストの再生を繰り返す。
【００６１】
以上説明した本実施例の放送センタ１０によれば、視聴者からのリクエストを受け付けた場合には、リクエスト実行テーブル（図４）のリクエストコード領域Ｂ２の受付ポインタＢ５の位置に新規予約するのであるが、その１つ前のリクエストコードと同一の場合には、リクエストコードが連続してしまうので、所定の入れ替え条件が成立した場合には、１つ前のリクエストコードと２つ前のリクエストコードとを入れ替えた上で、新規予約することによって、リクエストコードが連続しないようにしている。
【００６２】
所定の入れ替え条件の一つは再生フラグを見て判断する。つまり、入れ替えるリクエストコードの一方が再生中であれば、それは移動させることができないので、再生中フラグとなっていたら入れ替え処理を実行しない。もう一つは、リクエストコードを見て判断する、つまり、新規予約するリクエストコードを中心にして考えてリクエストコードが連続しないように入れ替えた場合に、その入れ替えることによって別の部分でリクエストコードが連続してしまうのは好ましくないので、その場合も入れ替え処理を実行しない。
【００６３】
これにより、同一の放送要求が連続して新規予約されることが禁止され、同一の放送用情報が連続して放送されることが防止される。その結果、視聴者の不快感を無くして、放送システムの好適な運用を図ることができる。
以上、具体例に従って、本発明の実施の形態について説明したが、本発明はこのような具体例に限定されるものではなく、発明の要旨を逸脱しない範囲で様々な実施ができることは言うまでもない。
【００６４】
例えば、上記実施例においては、図１２（Ａ）及び図１２（Ｂ）に示すように、受付ポインタＢ５の１つ前（図中▲１▼）のリクエストコードを２つ前（図中▲２▼）のリクエストコードと入れ替えるものであったが、新規予約するリクエストコード自体を移動させてもよい。
【００６５】
例えば、図１２（Ｃ）に示すように、新規予約するリクエストコードを、図１２（Ａ）の状態における受付ポインタＢ５の２つ前（図中▲２▼）のリクエストコードと３つ前（図中▲３▼）のリクエストコードの間に挿入するようにしてもよい。これでも、連続したリクエストコードとなることを防止することができる。なお、新規予約するリクエストコードは、１つ前（図中▲１▼）のリクエストコードと同一であるので、図１２（Ａ）の状態における受付ポインタＢ５の１つ前（図中▲１▼）のリクエストコードと２つ前（図中▲２▼）のリクエストコードの間に挿入しても結局リクエストコードが連続してしまうので意味がない。したがって、２つ前（図中▲２▼）のリクエストコードあるいはそれよりも前のリクエストコードの「前」に挿入する必要がある。
【００６６】
以上のことを鑑みると、移動させる対象として新規予約するリクエストコードと１つ前のリクエストコードの２つが考えられ、また、移動させる方法としては、新規予約するリクエストの場合には挿入だけであり、１つ前のリクエストコードの場合には入れ替えと挿入の２つが考えられる。したがって、それぞれの組み合せによる移動処理が考えられる。
【００６７】
そして、入れ替える場合あるいは挿入する場合には、その対象は、最も順番が近いものであってもよいし、さらにそれよりも順番が遠いものであってもよい。また、最初は、最も順番が近いものに対して入れ替えあるいは挿入が可能かを判断し、不可能な場合には、順次、それよりも順番が遠いものに対して入れ替えあるいは挿入が可能かを判断するようにしていってもよい。但し、上記実施例においても考慮していたように、その入れ替えあるいは挿入によって、別の部分でリクエストコードが連続してしまうのは好ましくないので、その場合はやはり入れ替え処理を実行しないほうがよい。
【図面の簡単な説明】
【図１】実施例の放送センタの概略構成を示すブロック図である。
【図２】ホストコンピュータを中心した信号の流れを示す説明図である。
【図３】ホストコンピュータが取り扱うリクエストデータベースのデータ構造図である。
【図４】ホストコンピュータが取り扱うリクエスト実行テーブルのデータ構造図である。
【図５】ホストコンピュータが取り扱うリクエスト受付バッファのデータ構造図である。
【図６】ホストコンピュータが取り扱うリクエストログ記憶部のデータ構造図である。
【図７】ホストコンピュータが取り扱う加入者データベースのデータ構造図である。
【図８】ホストコンピュータが実行するリクエスト自動受理・予約処理の一部を示すフローチャートである。
【図９】ホストコンピュータが実行するリクエスト自動受理・予約処理の一部を示すフローチャートである。
【図１０】ホストコンピュータが実行するリクエスト自動受理・予約処理の一部を示すフローチャートである。
【図１１】ホストコンピュータが実行するリクエスト再生処理を示すフローチャートである。
【図１２】リクエストコードの連続を解消させる場合の処理結果を示すリクエスト実行テーブルのデータ構造図である。
【符号の説明】
１０…放送センタ                １１…ホストコンピュータ
１１ａ…ＣＰＵ                  １１ｂ…ＣＰＵメモリ
１２…外部記憶装置                １３…表示装置
１４…カラオケ再生装置            １６…放送手段
２０…音声応答装置                ４０…公衆電話回線
５０…加入者電話機
【図１】
0003629076.tif 000002
【図２】
0003629076.tif 000003
【図３】
0003629076.tif 000004
【図４】
0003629076.tif 000005
【図５】
0003629076.tif 000006
【図６】
0003629076.tif 000007
【図７】
0003629076.tif 000008
【図８】
0003629076.tif 000009
【図９】
0003629076.tif 000010
【図１０】
0003629076.tif 000011
【図１１】
0003629076.tif 000012
【図１２】
0003629076.tif 000013