技術 デ─タ放送またはデ─タ通信におけるメニュ─表示、選択方法

0001

この発明は、データ放送またはデータ通信におけるメニュー選択の方法に関し、より特定的には、現在受信可能なサービスを表示し、ユーザーに任意のサービスを選択させることによって特定のサービスを開始するメニュー表示およびサービスセレクトの方法に関する。

0002

データ通信の分野においては、現在、公衆電話回線を使用したネットワークが盛んである。ユーザーは、高性能のホストコンピュータによって構築された大規模なデータベースに対し、比較的性能の劣る端末機から公衆回線を通じてアクセスし、そこに蓄えられたデータの参照やプログラムのダウンロード等のサービスを受けることができる。一方、データ放送の分野においても、地上波のＴＶ放送を利用した文字放送がすでに実用化され、さらに衛星放送を利用したデータ放送も徐々に運用環境が整備されつつあり、来たるべきニューメディア時代のさきがけとして期待されている。

0003

ネットワークのメリットとしては、通信プロトコルを合わせることにより、端末機の種類によらずデータベースにアクセスできるという点が挙げられる。したがって、ホストコンピュータを運営する側からすれば、すべてのコンピュータを対象としてサービスを運営できるため、市場規模が大きくなり、商業的な価値が高い。しかしながら、電話回線における通信速度の問題や、個々のコンピュータの性能の違いから、一般的には会話形式のテキストデータのやりとりによってサービスの種類を指定するというメニュー選択方法がとられている。

0004

図２に従来のメニューの例を示す。ネットワークにログインすると、ホストコンピュータから現在受付中のサービスの一覧表がテキストデータとして送信される。ユーザーは端末機に表示された一覧表の中から望みのサービスを選択し、例えばそれをサービス番号を入力することによって指定する。入力されたサービス番号は、テキストデータとしてホストコンピュータに送信され、ホストコンピュータはこれに基づいてサービスを開始する。文字放送においても、サービス一覧表から任意のサービスを番号で指定することにより、端末機が指定されたサービスのデータファイルを選択的にロードし、そのデータをディスプレイに表示する。

0005

このようなメニュー選択方法は、端末機の性能に依存しないという反面、無味乾燥した印象をユーザーに与えるため、視覚的なイメージが伴わず、広く一般的なユーザーに受け入れられ難いという問題点があった。そのため、パソコン通信などは、どちらかと言うとマニア向けという印象をぬぐい得ない。また、文字放送においても、送信されるデータそのものによほど魅力的なサービスが無い限り、ユーザーが端末機を購入しようとしないのが実情である。

0006

ところで、端末機の普及台数は放送の質を左右する。受信端末機の台数が増えれば増えるほど放送の事業性は有利になり、より良いサービスを供給できるようになるが、端末機が普及しないとサービスの種類が限定され、サービス自体の魅力が損なわれ、さらに端末機が普及しづらくなるという悪循環に陥る。したがって、いかにサービスそのもの以外の部分に付加価値を付けるか、また、それによっていかに、まず端末機を普及させるかが、データ放送事業を成功に導く上での最大の課題である。

0007

本件は、サービス選択メニューにおいて背景画像の上にサービスシンボルを配置し、そのマップの上でユーザーが自身の分身であるユーザーシンボルを操作することにより、ゲーム感覚でメニュー選択が行えるため、従来の方法に比べて飛躍的に視覚的イメージが充足され、一般のユーザーに受け入れられやすいメニュー画面を提供する。そのため、本件は、受信可能なサービスをサービスシンボルとしてディスプレイ上に表示するステップと、ユーザーが操作可能なユーザーシンボルを表示するステップと、サービスシンボルでもなく、かつユーザーシンボルでもない背景画像を表示するステップを有し、ユーザーシンボルが特定の背景画像の一部と衝突した場合には、ユーザーシンボルの移動を阻害し、また、ユーザーシンボルがサービスシンボルと衝突した場合には、それに対応する放送または通信データを受信してサービスを行う。また、メニュー画面の画像表現を、放送データを用いて常時更新しているため、常に変化に富んだ、飽きることのないメニュー画像をユーザーに提供できる。

0008

例えばサービスシンボルを建物で表示し、ユーザーシンボルを人間として表示し、背景画像として街の表示を行うと、ユーザーは、その街を実際に歩いているかのような疑似体験が得られる。ユーザーは木にぶつかった場合、それを越えては移動できない。また、芝生には入れるけれど、花壇の中には入れない。さらに、建物の中にはいると、その建物の外観に応じたサービスが受けられ、ユーザーは違和感なくデータ放送（またはデータ通信）を楽しむことができる。また、この街の配置や外観は、逐次、放送データによって自動的に変化する。従ってユーザーは変化に富んだ、飽きないメニュー画面そのものを楽しむことができる。これによって広く一般のユーザーがゲーム感覚でデータ放送を享受でき、従来までの情報通信に対する嫌悪感が払拭される。

0009

図１に本件発明におけるメニュー画面の例を示す。画面中、中央付近の人間２はユーザーシンボルを示す。建物４、６、８、１０、１２、１４は、サービスシンボルを示す。また、犬１６もサービスシンボルを示すが、背景画像上を移動するという点で建物のサービスシンボルとは種類が異なる。木、花壇、噴水、立て札はユーザーシンボルの移動を阻害する背景画像であり、生け垣、芝生、道路はユーザーシンボルの移動を阻害しない背景画像として表示される。また、通行人１８、車２０は移動する背景画像としてディスプレイに表示される。なお、物理的には通行人、車、犬、人間はゲーム機の特殊機能であるオブジェクト（スプライト）で表示されるが、ここで言う「背景画像」は各シンボルに対する背景という意味であり、通常オブジェクトと対に用いられる「背景」（バックグラウンド）とは意味合いが異なる。さらに本件実施例では、車にぶつかった場合や、通行人で特定の操作を行った場合等に、データ放送サービスとは無関係にイベントを発生させることにより、メニュー画面におけるゲーム性を向上させている。本件発明によるメニュー画面がいかにして機能するかを順を追って以下に説明する。

0010

図４に本件発明のシステム構成図を示す。本件実施例では、家庭用ゲーム機「スーパーファミコン（登録商標）」を用いた衛星放送によるデータ放送受信システムを開示する。ゲーム機本体３０には、衛星放送受信アダプタ３２とメモリカートリッジ３４が接続される。ユーザーがユーザーシンボルを操作するためのコントローラ３６が接続される。衛星放送はＢＳアンテナ４２で受信され、ＢＳチューナ４４で任意の放送チャンネルが選択される。選択された放送チャンネルの副搬送波信号はＢＳチューナによって復調され、ビットストリーム信号として出力される。分配器３８はＢＳチューナ４４からのビットストリーム信号を２分配し、その内の１つを衛星放送受信アダプタ３２に与える。ゲーム機３０からのビデオ、オーディオ信号はＴＶ４６に出力され、表示される。ＡＣアダプタ４０は、衛星放送受信アダプタ３２に接続され、衛星放送受信アダプタ３２、ゲーム機本体３０、カートリッジ３４に電源を供給する。

0011

図５は、本件発明のシステムブロック図である。分配器３８は図５では省略されている。ＢＳアンテナ４２によって受信され、ＢＳチューナ４４によって復調されたビットストリーム信号は、データチャンネルデコーダ５０に与えられる。データチャンネルデコーダ５０は、ビットストリーム信号に同期した内部クロック信号を発生し、前記ビットストリーム信号とともにＰＣＭデコーダ５２に与える。ビットストリーム信号は図３に示すパケット構造を持ち、ＰＣＭデコーダ５２によって誤り訂正を受けた後、ＰＣＭ音声データ部とデータパケット部とに分離される。ＰＣＭ音声データ部はＤーＡコンバータを介してアナログ音声信号としてゲーム機本体３０に与えられ、データパケット部はデータチャンネルデコーダ５０に出力される。

0012

データチャンネルデコーダ５０は図３に示すようにデータパケットを複数個つなぎ合わせることにより、１つのデータファイルを構築する。ビットストリーム信号は図６に示すように、複数個のファイルを含む。これらのファイルは各々複数個のパケットからなり、それぞれのパケットは時分割で送信される。図３のヘッダ部はそれぞれのパケットがどのファイルに対応するデータであるかを示す論理チャンネル（ＬＣＩ）を含み、ＣＰＵ５４から指定された論理チャンネルに基づいて、データチャンネルデコーダ５０が特定のファイルを組み立てる。組み立てられた（あるいは組み立て途上の）データは、データチャンネル５０内のバッファに蓄えられ、ＣＰＵ５４により適時ワークＲＡＭ６２、ＰＳ−ＲＡＭ５８、またはフラッシュメモリ５６に格納される。ＲＯＭ６０は、主として本件の特徴を成すゲーム性のあるメニュー画面を達成するためのプログラムを保持する。

0013

各メモリから読み出された画像データは、ＣＰＵ５４によって、ＰＰＵ６４を介してビデオＲＡＭ６６に格納される。ＰＰＵ６４はビデオＲＡＭ６６のデータに基づいて、ＤーＡコンバータ、ビデオエンコーダを通じてビデオ信号を生成し、ＴＶ４６に与える。同様に各メモリから読み出された音声データはＡＰＵ６８を介してオーディオＲＡＭ７０に格納され、ＡＰＵ６８によって音声信号として出力される。ＡＰＵから出力された音声データは、Ｄ−Ａコンバータによってアナログ信号に変換される。ミキサー７２は、ＡＰＵ６８からのアナログ音声信号と、ＰＣＭデコーダ５２からのアナログ音声信号を混合し、ＴＶ４６に与える。ポート７４は、コントローラ３６によって入力されるユーザーの操作情報をＣＰＵ５４に与える。

0014

図６から分かるように、本件では、ＴＣＤファイル、番組案内データファイル、メニュー制御データファイル、番組ファイルの４種類のファイルによってメニュー画面を制御し、サービスを供給する。

0015

ＴＣＤファイル
伝送制御データファイルを意味し、放送中の全ファイルの放送業者識別番号（ＰＶ）、番組番号（ＰＲ）、論理チャンネル（ＬＣＩ）データを含む。論理チャンネルは放送されるファイルの数によってその都度変化するため、特定ファイルをロードする際には、予めＴＣＤファイルをロードし、ＰＶ、ＰＲを元に論理チャンネルを検索した後に、その論理チャンネルに基づいてファイルを指定しなければならない。このＴＣＤファイルの内容は、電気通信技術審議会の衛星データ放送委員会報告概要に詳細に記載されている。

0016

番組案内データファイル
図９に番組案内データファイルの構成を示す。番組案内データファイルは、衛星データ放送受信システムの起動時にロードされ、メニュー画面の初期設定に用いられる。番組案内データファイルはまた、番組案内データが変更された時にもロードされ、メニュー画面の再設定を行う。番組案内データファイルは、ヘッダ部、トップメニュー情報部（およびサブメニュー情報部）および補足情報から成り、ヘッダ部には番組案内データの構成を示すバージョン番号、番組案内データの更新時に変化する番組案内シリアル番号、およびトップメニュー数、サブメニュー数を含む。

0017

トップメニュー情報は、複数個の番組情報を含み、各番組情報は、トップメニューシリアル番号、タイトルテキスト、放送日、番組内容案内テキスト、番組ファイルのＰＶ、ＰＲデータ、ファイルサイズおよびその他サービス情報を含む。サービス情報は図８に記載する情報を含み、当該サービスが実行される場合のメモリ構成や飛び先アドレスを示す予約サービス情報、サブメニューの表示形式を示すサブメニュー形式データ、当該サービス特有の表示を行うための表示オプション、関連するサブメニューシリアル番号を記載したサブメニュー情報、さらに当該サービスを行う上でのその他補助情報を含む。サブメニュー情報はトップメニュー情報と同様のデータ構造を持つが、当該サービス用の番組ファイルが１つでこと足りる場合には、サブメニュー情報におけるＰＶ、ＰＲにはダミーデータが登録される。さらに、特に番組ファイルを使用せずにサービスを行う場合（例えば、既にＲＯＭに登録されている予約プログラムだけを動作させる場合）には、トップメニュー情報のＰＶ、ＰＲにダミーデータが登録される。図８のその他補助情報は、予約プログラムを動作させるか、メニュー形式データに基づいてサブメニューを表示するか、さらにはＰＶ、ＰＲに基づいて直ちに番組ファイルデータをロードし、ロード後自動的に実行するかを示すサービスステータスデータを含み、さらにＰＶ、ＰＲがダミーデータであるか、それとも意味のあるデータであるかを示す番組ファイル有効フラグを含む。

0018

番組案内データファイルは、初期メニュー画面を構成するための補足情報を含む。補足情報は、各々のサービスシンボルおよび背景画像の配置を示すイニシャルマップデータテーブル、後述するイベントテーブルとイベントテーブル用許可フラグ、これも後述するルーチンテーブルとルーチンテーブル用許可フラグ、ＲＯＭ内の既に登録されたマップ表示用の画像・音声データに追加すべき画像音声データおよび追加すべきマップ表示処理用の処理ルーチンプログラムを含む。マップデータテーブルはユーザーシンボルが移動する際に、その先に何があるのかを参照するためのテーブルである。マップデータテーブルから得られたマップデータは、イベントテーブル上で検索され、ユーザーシンボルが何かに衝突したかどうかを判断するのに用いられる。イベントテーブル検索の結果、衝突相手がサービスシンボルであった場合には、前記トップメニュー情報が検索され、サービスが開始される。また、ルーチンテーブルはメニュー画面上でのサービス以外のイベントを提供するのに用いられる。

0019

メニュー制御データファイル
メニュー制御データファイルの構成を図７に示す。メニュー制御データファイルはメニュー画面において常時監視され、サービスの許可情報を更新する。番組案内データファイルがまれにしか更新されないのに対して（例えば一日毎）、メニュー制御データは頻繁に更新される。（例えば一時間毎）番組案内データで供給されるイベントテーブルには、例えばその日一日分のすべてのサービスリストが含まれており、放送時間に合わせ、メニュー制御データによって特定のサービスだけが許可される。メニュー制御データファイルは、番組案内データファイルが更新された場合に変化する対応番組案内シリアル番号、イベントテーブル許可フラグ、ルーチンテーブル許可フラグおよびイベントテーブルの変更に伴うマップデータの変更テーブルを含む。イベントテーブルとルーチンテーブルあるいは各々の許可フラグは、本件発明においてゲーム性を有するメニュー画面を構成するための好適な実施例であり、その全容は後程詳細に説明する。

0020

番組ファイル
番組ファイルは、各々のサービスで使用されるデータおよびプログラムを含む。例えば、天気予報のデータの場合、地域によって、または時間によって天気予報データがテーブル化されて保持される。サービスそのものの内容はそのサービスを行う放送事業者が任意に決めるべきものであり、また、ファイル内のプログラムによって任意に構築できるものであるため、本件明細書においては、特にその内容を規定しない。

0021

次に図１０および図１１を参照して、イベントテーブルの機能を説明する。図１に示すように、本件メニュー画面上にはさまざまなシンボルおよび背景画像が表示されている。マップデータテーブルにはこれらに対応する識別データが記憶されており、例えば、表示画面上の座標を８ドット単位のブロックで区切り、このブロックに存在するシンボルの画像データあるいは背景画像の画像データの識別番号をブロック毎に記憶する。例えば建物４、６、８、１０、１２の入り口のシンボル画像は同じデータが使用されており、図１０で示すように同じマップデータ「０１」で識別される。同様に自分の家のドアは「０２」で、車のボンネットは「４１」で、等、マップデータの項に記載されている数字で各々の画像が識別される。識別データとしては、画像に一対一で対応するデータでもよいし、画像とはかかわりのない単なる識別のためのデータであってもよい。前者の場合は識別コードの種類が増えるため、イベントテーブルが大きくなるが、マップデータテーブルをそのまま表示データとして使用できるため便利であり、また、後者の場合は、マップデータテーブルとは別に、表示のための画像コード表またはシンボル別の表示プログラムが必要となるが、反面イベントテーブルが小さくて済み、検索に要する時間を少なくできるという利点がある。

0022

座標範囲は、同じマップデータで異なるサービスを供給したい場合に、ユーザーシンボルの現在値と比較することにより、ユーザーがどのサービスを希望しているのかを判別するために使用される。マップデータと座標範囲で衝突が確認された場合、その衝突対象物に応じて３種類の異なる処理を行う。衝突した相手がサービスシンボルであった場合、前述のトップメニュー情報からサービス情報をを入手し、それを基にして指定されたサービスを開始する。衝突相手がイベントシンボルであった場合には、データ放送番組によらないイベントが開始される。また、衝突相手が障害物であった場合には、単にユーザーシンボルの移動を阻害する。オプションは、サービスシンボルの場合には、対応するトップメニューシリアル番号を指定し、イベントシンボルの場合は、対応するルーチン番号を指定する。ルーチン番号については、後述のルーチンテーブルの説明において開示する。備考は、単にテーブルを作成する人のメモであり、実際のテーブルデータとしては記録されない。

0023

許可フラグは、このサービスおよびイベントを許可するかどうかを示す。許可フラグが×となっている項目においては、仮にユーザーファイルがそれに衝突したとしてもなにも起こらない。第ＳＺ１５Ａでは、カラオケＢＯＸの番組とマンホールのイベントが不許可になっており、また、芝生を障害物として扱うことに対しても不許可になっている。したがって、カラオケＢＯＸの入り口やマンホールの上に立ってもなにも起こらず、また、芝生の中に自由に入って行けるということを意味している。この許可フラグはメニュー制御データファイルが更新される毎に変更されるため、たとえば昼間は芝生に入れないが、夜ならば入れるという制御も可能であり、メニュー画面上におけるゲーム性を向上できる。また、例えばカラオケＢＯＸのサービスが許可される際には、同時に入り口の画像が更新され、×印が削除される。これにより、ユーザーは、特定のサービスが許可されているかどうかをリアルタイムに、かつ視覚的に確認することができる。

0024

イベントテーブルのうち、すでに予約されている部分はＲＯＭに記憶されており、番組案内データで供給されるイベントテーブルは、このＲＯＭのテーブルに追加されるデータだけを含む。ただし許可フラグに関しては、番組案内データもしくはメニュー制御データによって、変化する可能性のあるデータは全て、予約されているテーブルであるか否かにかかわらず供給される。

0025

図１２は、特殊な操作により発動するイベントテーブルを示す。図１０および図１１においては、ユーザーシンボルと衝突した対象物がサービスあるいはイベントの対象となったが、図１２においては、ユーザーが例えばコントローラのＡボタンを押すことにより、進行方向直近の対象物をサービスあるいはイベントの対象とする例を開示している。この図の中で、犬を示すマップコード「５０」がサービスシンボルとして登録されている。すなわち、犬の前でＡボタンを押すと表に記載されている通りドッグフードのＣＭが一つの番組としてロードされ、実行される。犬はマップ上を自由に移動しているため、ユーザーがドッグフードのＣＭを見たい場合には犬を追いかけなければならず、これにより一層、メニュー画面におけるゲーム性が格段に向上する。マップデータテーブルの構造化や衝突判定のアルゴリズムは、既に多くのゲームソフトウェアで実施されており、様々な手法が存在する。上述の例は、単なる一実施例にすきず、設計者の好みによって任意の方法を取り得ることは言うまでもない。

0026

次に図１３を用いてルーチンテーブルの詳細を開示する。ルーチンテーブルはＴＶフレーム毎に処理しなければならない処理ルーチンを定義する。メニュー画面上で行われる処理はすべてテーブル化されており、任意の処理の許可フラグをセットすることによって当該処理を開始する。ルーチンテーブルは強制ルーチンテーブルと通常ルーチンテーブルを含む。本件実施例においては、１つのルーチンテーブルを用い、強制ルーチンであるかどうかを示すフラグを付加することにより、上記２つのルーチンテーブルを定義する。対応アドレスは、当該処理ルーチンのエントリエドレスを示す。オプションは対応するエントリアドレスにジャンプする場合の引き数を示す。備考はイベントテーブルと同様、テーブル作成時のメモであり、実際のテーブルデータとしては記録されない。

0027

イベントテーブルにおいては許可フラグは、検索対象であるかどうかの識別フラグとして用いられたが、ルーチンテーブルにおいては、許可フラグそのものが検索のキーとなる。強制ルーチンの場合、ルーチンテーブルを上から検索して最初に許可されているルーチンのみが実行され、それ以降の強制テーブルあるいは通常テーブルの許可フラグがＯＮになっていてもそれらは無視される。強制ルーチンは例えば、メニュー画面上で通行人と会話する場合に、会話文をウィンドウ表示し、特定のボタンが押されるまでそれ以外の処理を凍結するという処理に用いられる。これはロールプレイングゲーム等によく用いられる方法であり、これにメニュー画面をあたかもゲーム画面であるかのように表現できる。強制ルーチンは、そのシーケンスの最後で自らの許可フラグをＯＦＦにし、それによって次のＴＶフレーム以降の当該処理の実行を停止する。したがって、複数の強制ルーチンが許可された場合には、表の上の方にあるルーチンから順に処理が行われることとなり、表を優先順位の高い順に配置することにより、優先順に処理を実行することができる。

0028

通常ルーチンにおける許可フラグは、当該ルーチンの実行許可を示すフラグとして作用する。すなわち、強制ルーチンの許可フラグが全てＯＦＦの場合に通常ルーチンが参照され、許可フラグがＯＮになっている処理ルーチンが全て当該ＴＶフレーム中に処理される。通常ルーチンは例えば、犬が歩くというような、継続的に実行されるべき処理に用いられる。また、噴水の高さが連続的に上下するというような、視覚的変化を継続的にもたらす場合にも使用される。前述の番組案内データはルーチンテーブル、許可フラグおよびルーチンプログラムそのものも含むため、例えばメニュー画像の色を変化させて、昼→夕方→夜という景色変化をもたらす場合、たとえＲＯＭにそのプログラムが内蔵されていなくても、放送局から強制イベントとして実行することができる。

0029

ルーチンテーブルのうち、すでに予約されている部分は、イベントテーブルと同様、ＲＯＭに記憶されており、番組案内データで供給されるルーチンテーブルは、このＲＯＭのテーブルに追加されるデータだけを含む。ただし許可フラグに関しては、番組案内データもしくはメニュー制御データによって、変化する可能性のあるデータは全て、予約されているテーブルであるか否かにかかわらず供給される。

0030

図１４にメモリマップを示す。ＲＯＭエリアは図５におけるＲＯＭ６０に対応し、後述するメインプログラムが記憶される。さらにＲＯＭ６０は、画像データ、音声データ、予約サービスプログラム、予約ルーチンプログラム、予約イベントテーブルおよび予約ルーチンテーブルを含む。

0031

ＲＡＭエリアは図５におけるＰＳーＲＡＭ５８およびワークＲＡＭ６２によって構成される。ＲＡＭエリアは、放送データを受信する場合に使用される受信バッファを含み、番組案内データファイルで供給されるトップメニュー情報（およびサブメニュー情報）、追加画像・音声データ、追加ルーチンプログラム、イベント許可フラグ、ルーチン許可フラグ、追加イベントテーブル、追加ルーチンテーブルを記憶する。さらに、ＲＡＭエリアは、処理ルーチン用ワークエリアとメインプログラム用ワークエリアを含む。また、記憶容量の点で余裕がある場合は、受信された番組ファイルをＲＡＭエリアに記憶し、実行してもよい。不揮発性メモリ領域は、図５におけるフラッシュメモリ５６に対応し、保存すべきデータを記憶する。

0032

不揮発性メモリエリアには、主として受信された番組ファイルを記憶するが、ユーザーシンボルの移動速度のデータや受信ＬＯＧデータ等を含むシステムデータも保存される。また、記憶容量の点で余裕がある場合は、番組案内データファイルやメニュー制御データファイルの一部（トップメニュー情報の一部や、各種テーブル、各種許可フラグ等）を記憶してもよい。これによって、一度電源を切り、再度電源を投入した場合に、番組案内データをロードしなくても、ユーザーに対して不揮発性メモリに保存されているサービスを提供することができる。

0033

続いて、図１５〜図２２を用いて本件実施例におけるメインルーチンの動作を説明する。図１５は、メインルーチンの全体的な流れを示すフローチャートである。電源投入後、まずイニシャライズルーチンＳ２が実行され、システムの初期設定や番組案内データファイルのロードが行われる。次にＴＣＤルーチンＳ４が実行される。各々の処理の詳細は図１６、図１７を用いて後述する。

0034

Ｓ６において、ＳＶＦが１の場合はサービスに関する処理へ分岐する。ＳＶＦ(SERVICEFLAG)は、例えばユーザーシンボルがサービスシンボルと衝突し、サービスが開始される場合に１になる。サービスが開始されると、ＣＰＵ５４は、ワークＲＡＭ６２内のトップメニュー情報エリアからＳＶＮＯに対応するサービスを検索し、当該サービスに関連する情報を入手する（Ｓ８）。ＳＶＮＯ(SERVICENo.) は、開始すべきサービスを指定するためのサービス番号を記憶する。前記サービスに関連する情報には、ジャンプアドレス、オフセットアドレスまたは間接的にジャンプ先を指定するためのメニュー形式データを含む。

0035

ＣＰＵ５４は、前記サービスに関連する情報に基づいて、サービスエントリアドレスにジャンプし（Ｓ１０）、それによってサービスルーチンが起動される（Ｓ１２）。サービスルーチンは、通常、それ自体で完成された一つのプログラムを成し、サービスルーチンが終了するまで、メインルーチンには復帰しない。しかし、ＴＣＤルーチンをメインルーチンと共用で使用したい場合には、シーケンサプログラムを内蔵することによりＴＶフレーム単位でメインルーチンに復帰してもよい。シーケンサプログラムはＴＶフレーム順にサービスルーチンがどのように動作するかを定義する。サービスが終了する場合、再イニシャライズを行い、ＳＶＦを０に戻してからメインルーチンに復帰する。

0036

Ｓ６において、ＳＶＦが０の場合は、メニュー制御のための処理へ分岐する。ＣＰＵ５４は、Ｓ１４において、メニュー制御データをロードし、各種許可フラグを設定し、マップデータおよびメニュー画像を変更するためのメニュー制御データ処理を実行する。その後、ＣＰＵ５４は、コントローラ３６から入力されたユーザーのキー入力データを受け取り（Ｓ１６）、キー入力データに基づく衝突判定、ユーザーシンボルの移動、サービス開始時のＳＶＦのセット、イベント開始時のルーチンテーブル許可フラグのセット等を制御するイベントテーブル処理Ｓ１８を実行する。その後ＣＰＵ５４は、ルーチンテーブル処理Ｓ２０において、指定された処理ルーチンを実行する。

0037

ルーチンテーブル処理Ｓ２０が終了すると、ＣＰＵ５４は、ＮＭＩ信号（すなわちＰＰＵ６４からＣＰＵ５４へのＶブランクタイミングを示す信号）を待ち（２２）、ＮＭＩルーチンＳ２４を実行してＴＣＤルーチンＳ２へ戻る。ＮＭＩルーチンＳ２４においては、Ｖブランク中に実行すべき処理、例えばビデオＲＡＭ６６内への画像データの転送等、を実行する。Ｓ４からＳ６のＮＯ分岐を通ってＳ２４へ到達する一連の処理は、ＴＶの１フィールド中に処理され、この処理が毎フィールド繰り返される。本件実施例では、ＴＣＤファイルのロード、メニュー制御データファイルのロード、番組ファイルのロードを、同時に行うことはないが、ＣＰＵの動作速度に余裕がある場合には、ＴＣＤファイルのロードとメニュー制御データファイルのロードまたは、 ＴＣＤファイルのロードと番組ファイルのロードを各々並列に行ってもよい。本件メインルーチンのフローによると、メニュー制御データファイルのロードと番組ファイルのロードが同時に発生することがないため、最大でも２チャンネル分だけデータ放送をデコードすればよく、データチャンネルデコーダ５０の構造を複雑にせずに済む。

0038

図１６は、イニシャライズルーチンＳ２の詳細を示す。ＣＰＵ５４は、Ｓ３０において、ＰＰＵ６４、ＡＰＵ６８、ＰＣＭデコーダ５２、データチャンネルデコータ５０の初期設定を行い、Ｓ３２において、タイトル画面を表示する。Ｓ３４〜Ｓ４２はデータチャンネルデコーダ５０が正常にビットストリーム信号を受信しているかどうかをチェックする処理であり、機器に接続不良があってビットストリーム信号が正常に受信できない場合には、エラーメッセージを表示し、正常に受信できるまでループし続ける。

0039

ＣＰＵ５４は予め指定されているＴＣＤファイルの論理チャンネル値をデータチャンネルデコーダ５０に与え、ＴＣＤファイルをワークＲＡＭ６２にロードする（Ｓ４４）。ＴＣＤファイルの中から、予め指定されているＰＶ、ＰＲ値を頼りに番組案内データファイルの論理チャンネルを抽出する（Ｓ４６）。ＣＰＵ５４はＴＣＤファイルの時と同様にして番組案内データファイルをロードし、ワークＲＡＭ６２に格納する。ロードされた番組案内データファイルは、Ｓ５０においてマップデータを初期化し、Ｓ５２において初期マップすなわち初期メニュー画面を表示し、Ｓ５４においてイベントテーブルを初期化し、Ｓ５６においてルーチンテーブルを初期化し、Ｓ５８においてイベントテーブルおよびルーチンテーブルの許可フラグを初期化するのに利用される。

0040

ＣＰＵ５４は、その後ユーザーシンボルを表示し（Ｓ６０）、予約変数ＰＶ、ＰＲに予め指定されているメニュー制御データファイルのＰＶ、ＰＲ値をセットして、ＤＦに０を、ＴＦに１をセットする（Ｓ６２）。ＤＦおよびＴＦは、メニュー制御データ処理Ｓ１４およびＴＣＤルーチンＳ４において、各々のシーケンスを制御するのに用いられ、これによってＴＣＤファイルとメニュー制御ファイルは同時にロード作業が発生しないように制御される。これによりイニシャライズルーチンは終了し、メインルーチンへ復帰する。

0041

図１７は、ＴＣＤルーチンＳ４の詳細を示す。ＴＦはＴＣＤファイルロード時のシーケンスを制御し、ＣＰＵ５４は、ＴＦが０の時、何もせず（Ｓ７０）、ＴＦが１の時、ＤＣＤ（データチャンネルデコーダ）５０にＴＣＤファイルの論理チャンネルをセットし（Ｓ７２、Ｓ７４）、ＴＦが２の時、ＤＣＤにバッファリングされたＴＤＣファイルのデータをロードし、解析する（Ｓ７８、Ｓ８０）。ＴＦが２の場合に、ＴＣＤデータ上で前記予約変数ＰＶ、ＰＲで指定されたファイル（この場合は、メニュー制御データファイル）を発見すると、そのファイルの論理チャンネルをレジスタＬＣＩＲにストアし（Ｓ８４）、ＤＦを１にして当該ファイルのロードを予約する（Ｓ８８）。ここで、目的ファイルは既に発見されているため、それ以上のＴＣＤファイルのロードはキャンセルされ（Ｓ８８）、ＴＦが０にセットされてＴＣＤファイルのロード作業は終了する（Ｓ９０）。Ｓ８２で前記予約変数ＰＶ、ＰＲで指定されたファイルが無かった場合、ファイルの終端でなければ、継続してＴＣＤファイルのロード作業を行い、ファイルの終端であればＴＦを１に戻してＴＣＤファイルのロード作業を再度、最初からやりなおす。各々のシーケンスは、最終的にはすべてメインルーチンに復帰する。

0042

図１８は、メニュー制御データ処理Ｓ１４の詳細を示す。ＤＦはメニュー制御データファイルロード時のシーケンスを制御し、ＣＰＵ５４は、ＤＦが０の時、何もせず（Ｓ１００）、ＤＦが１の時、ＤＣＤ５０に対してＬＣＩＲにストアされているメニュー制御データファイルの論理チャンネルをセットし（Ｓ１０４、Ｓ１０６）、ＤＦが２の時、ファイルの終端までＴＶフィールドごとに、メニュー制御データファイルの各部分をロードして、ワークＲＡＭ６２に格納し（Ｓ１１０、Ｓ１１２、Ｓ１１４）、各々メインルーチンへ復帰する。ＤＦが３の場合は、メニュー制御データファイルのデータを解析し、処理するシーケンスであることを意味し、以下の手順で実行される。

0043

ルーチンテーブル処理において強制イベントを実行中の場合、途中でルーチン許可フラグが変化することは好ましくないため、Ｓ１１６において何もせずにメインルーチンへ復帰する。強制イベント中で無い場合には、まず、番組案内シリアル番号をチェックし、番組案内データファイルが更新されたかどうかをチェックする（Ｓ１１８）。ここで、番組案内データファイルが更新されている場合には、Ｓ１２８にてメッセージを表示し、システムリセットを行うことにより、更新された番組案内データファイルをロードする。番組案内データファイルが更新されていない場合には、イベント許可フラグおよびルーチン許可フラグを更新し（Ｓ１２２）、マップデータを更新するとともにメニュー画像の表示変更データを作成する。この表示変更データは、ＮＭＩルーチンにおいて、Ｖブランク中にビデオＲＡＭ６６に転送され、メニュー画像を変化させる。そしてＤＦに０が、ＴＦに１がセットされ、メニュー制御データの処理を終了し、ＴＣＤファイルのロードを再度開始するよう準備し、メインルーチンへ復帰する。

0044

図１９は、イベントテーブル処理Ｓ１８の前半部分の詳細を示す。まず、上述の場合と同様の理由で、強制イベント実行中であるかどうかがチェックされ、実行中の場合、何もせずにメインルーチンに復帰する（Ｓ１４０）。この前半部分では、ユーザーシンボル移動時の衝突判定を行うため、コントローラ３６の十字キー（ユーザーシンボル移動キー）が押されているかどうかをＳ１４２にてチェックする。十字キーが押されていない場合は、衝突判定は行わず、図２０のイベントテーブル処理２へ制御を移す。十字キーのどれかが押されている場合には、まずユーザーシンボルの移動方向のマップデータをリードする（Ｓ１４４）。ここで、オブジェクトで描かれたシンボルや背景（例えば、犬や通行人等）が背景画で描かれたシンボルや背景に重なっている場合、オブジェクトで描かれたシンボルや背景のマップデータを優先的にリードする。次に、イベントテーブル１（第ＳＺ１５Ａ、Ｂ図）を参照し、衝突判定を行う（Ｓ１４６）。

0045

ＣＰＵ５４は、Ｓ１４８において、衝突判定の結果に基づいて分岐する。ユーザーシンボルの移動方向にサービスシンボルがある場合には、当該サービスを開始するための準備を行う。まずユーザーシンボルを移動して、衝突画像を表示し（Ｓ１５０）、サービス番号（トップメニューシリアル番号を意味する）をＳＶＮＯにセットしてＳＶＦを１にする（Ｓ１５２）。次に、ＴＣＤファイルとメニュー制御ファイルのロードをキャンセルし（Ｓ１５４）、ＴＦ、ＤＦともに０をセットしてメニュー制御データファイルのロードに伴う全ての処理を停止する（Ｓ１５６）。その後メインルーチンに復帰するが、これにより、次のＴＶフィールドでサービスルーチンが起動する。

0046

ユーザーシンボルがイベントシンボルと衝突した場合は、ユーザーシンボルを移動して衝突画像を表示し（Ｓ１５８）、ルーチンテーブルの対応イベントの許可フラグをセットし（Ｓ１６０）、メインルーチンに復帰する。これによって、次のルーチンテーブル処理において、当該イベントが起動する。ユーザーシンボルが障害物と衝突した場合には、何もせずイベントテーブル処理２へ移行する。そのため、ユーザーシンボルはユーザーのキー操作に反して移動せず、ユーザーシンボルの移動が阻害される。移動方向のシンボルや背景がイベントテーブル上にない場合には、単にユーザーシンボルがキー操作された方向に移動するだけで、イベントテーブル処理２へ移行する（Ｓ１６２）。

0047

図２０は、イベントテーブル処理Ｓ１８の後半部分の詳細を示す。この後半部分では、Ａボタンが押されることにより各サービスやイベントが開始されるため、コントローラ３６のＡボタンが押されているかどうかをＳ１７０にてチェックする。Ａボタンが押されていない場合は、何もせずにメインルーチンに復帰する。Ａボタンが押されている場合には、前述のイベントテーブル処理と同様にして進行方向のマップデータをリードし（Ｓ１７２）、イベントテーブル２（図１２）を参照する（Ｓ１７４）。その後、参照結果に基づいて分岐し（Ｓ１７６）、参照結果がサービスシンボルの場合は、上述のイベントテーブル処理と同様にして当該サービスを行うための準備を行い（Ｓ１５０、Ｓ１５２、Ｓ１５４、Ｓ１５６）、参照結果がイベントシンボルの場合は、ルーチンテーブル上の対応ルーチン許可フラグをセットし（Ｓ１８４）、マップデータがイベントテーブル２上に無い場合には、何もせずにメインルーチンに復帰する。

0048

図２１には、ルーチンテーブル処理Ｓ２０の詳細を示す。ルーチンテーブル処理において、ＣＰＵ５４は、まずルーチンテーブル（図１３）上で強制フラグがＯＮになっている各ルーチンテーブルをチェックする（１９０）。許可されている強制ルーチンがあれば、Ｓ１９２からＳ１９４へ移行し、当該ルーチンを強制イベントとして実行し、メンルーチンへ復帰する。強制ルーチンがすべて不許可になっている場合には、強制フラグがＯＦＦになっている各ルーチンテーブルをチェックし（Ｓ１９６）、許可されているルーチンを実行する（Ｓ１９４）。この通常ルーチンテーブルのチェックおよび実行は、ルーチンテーブルの終端まで繰り返し行われる（Ｓ２０２）。

0049

図２２は、ＮＭＩルーチンＳ２４の例を示す。ＮＭＩルーチンは、本実施例では、ＴＶフィールドのＶブランク開始と同時に実行される。このルーチンでは、ビデオＲＡＭ６６に対して画像データを転送したり（Ｓ２１０）、強制イベントルーチンにおいてＴＶフレームに同期した各種シーケンスを実行するために、フレームカウンタのインクリメントを行った後（Ｓ２１２）、メインルーチンに復帰する。

0050

図２３には、ユーザーシンボルがゲームコーナーのサービスシンボル４と衝突した場合に実行されるサービスルーチンＳ１２の一例を示す。ＣＰＵ５４は、ゲームコーナーサービス用の画面設定を行い（Ｓ２２０）、イニシャライズを行う（Ｓ２２２）。画面上には、「メモリ内のゲームを実行する」、「新たにゲームをダウンロードする」および「マップメニューへ戻る」という３つのメニューが表示され、ユーザーに選択される（Ｓ２２４）。「メモリ内のゲームを実行する」が選択された場合には、Ｓ２２６、Ｓ２２８を経由してＳ２３８に分岐し、フラッシュメモリ５６に格納されているゲームプログラムが実行される。「新たにゲームをダウンロードする」が選択された場合には、Ｓ２３０、Ｓ２３２を経由してＳ２４０に分岐し、トップメニュー情報のＰＶ、ＰＲで指定される番組ファイル（ゲームプログラム）をロードするために、まずＴＣＤファイルをロードする。ここで発見された論理チャンネルに基づいて、Ｓ２４２においてゲームプログラムがダウンロードされ、フラッシュメモリ５６に格納される。

0051

「マップメニューへ戻る」が選択された場合には、Ｓ２３４、Ｓ２３６を介してＳ２４４へ移行し、ゲームコーナーサービスを終了し、メニュー画面へ戻る準備を行う。これは、マップデータに従って初期マップ（メニュー画像）を表示し（Ｓ２４４）、ユーザーシンボルを表示し（Ｓ２４６）、ＰＶ、ＰＲにメニュー制御データファイルの値を、ＤＦに０を、ＴＦに１をセットし、ＳＶＦを０に戻すことにより達成される（Ｓ２４８）。このゲームコーナーサービスによって、ユーザーは、放送中のゲームプログラムに加えて、以前ロードして蓄えておいたゲームプログラムをも実行できる。ユーザーはメニュー画面によって構成される疑似世界で、ゲームセンターに入り、ゲームを遊ぶという感覚で、違和感なくかつ容易にサービスを選択、実行できる。

0052

衛星放送では、図３に示すように、ＰＣＭ音声データとデータパケットを同時に送信している。また、図５の本件システムブロック図に示すように、ＰＣＭ音声データをデコードして音声を出力する機能と、データパケットを処理する機能を同時に含んでおり、これによって本件で提案しているゲーム性を持たせたメニュー画面を、より効果的にユーザーに提供できる。これは、本出願人が以前、特願平５−７９０３７で提案した、音声とデータとの同期放送に関連する。

0053

放送局で作成されたデータをリアルタイムで放送するのは、現在の放送設備の関係上、困難である。それに対して、音声のリアルタイム放送（実況）は比較的容易に実現できる。従って、予め準備されたデータを放送し、放送局でディスクジョッキーがそのデータ放送を見ながら、それに関するコメント、かくれイベントについてのアドバイス等を実況することにより、通常のゲームにも見られないような臨場感あふれるメニューやサービスを実現できる。例えば、メニュー制御データでカラオケＢＯＸが許可され、カラオケＢＯＸの建物入り口の×印が除去された時、ディスクジョッキーが「おーっと！つい今しがた、カラオケＢＯＸがオープンしました！」とコメントすることにより、いままでに無い、全く新規なメニュー画面をユーザーに提供できる。また、強制イベントルーチンとしてカラオケＢＯＸの番組を開始し、音声をＰＣＭ放送て、歌詞をデータ放送で送信することも可能である。

0054

さらにプロ野球ニュースとして、試合の進行をゲーム画面を用いて再現し、それを放送するとともに、その再現画面に基づいてディスクジョッキーがその試合を実況することにより、通常では得られなかった臨場感を当該サービスに与えることができる。このように、本件のメニューを司るアルゴリズムと音声放送とを組み合わせることにより、従来の情報通信とは全く異なる、新しい分野の放送・通信サービスを提供できる。

0055

本件発明によれば、ユーザーに対して、新規な放送・通信のメニュー画面を提供できる。このメニュー画面によってユーザーはメニュー画面で疑似世界を体験でき、違和感なく各種サービスを選択できるため、従来まではマニア向けと思われていた各種放送・通信サービスをゲーム感覚で広く一般のユーザーに提供できる。また、放送サービス以外の部分に付加価値を付けることができるため、端末機の普及が容易になり、ひいてはユーザーに対するサービスの向上、放送・通信分野の産業の発展に寄与する。また、音声とデータ放送をリンクさせることにより、より一層臨場感のある放送・通信サービスおよびメニューを提供できる。

0056

0057

図１本件発明におけるメニュー画面の例を示す。
図２従来のメニューの例を示す。
図３パケットとファイルの関係を示す概念図である。
図４本件発明のシステム構成図を示す。
図５本件発明のシステムブロック図である。
図６放送データの概念図である。
図７メニュー制御データファイルの構成図である。
図８サービス情報の構成図である。
図９番組案内データファイルの構成図である。
図１０衝突時のイベントテーブルを示す。
図１１図１０の衝突時のイベントテーブルの続きを示す。
図１２Ａボタン押下時に参照されるイベントテーブルを示す。
図１３ルーチンテーブルの詳細を示す。
図１４メモリマップを示す。
図１５メインルーチンの全体的な流れを示すフローチャートである。
図１６イニシャライズルーチンＳ２の詳細を示す。
図１７ＴＣＤルーチンの詳細を示す。
図１８メニュー制御データ処理の詳細を示す。
図１９衝突時のイベントテーブル処理を示す。
図２０Ａボタン押下時のイベントテーブル処理を示す。
図２１ルーチンテーブル処理の詳細を示す。
図２２ＮＭＩルーチンの例を示す。
図２３サービスルーチンの例を示す。