図面 (/)

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

出願人 任天堂株式会社
発明者 石田尚人谷口和彦中田雅康
出願日 1994年9月30日 (24年3ヶ月経過) 出願番号 1994-261652
公開日 1996年4月16日 (22年8ヶ月経過) 公開番号 1996-101671
状態 拒絶査定
技術分野 デジタル計算機の表示出力 計算機・データ通信 CATV、双方向TV等 表示装置の制御、回路 他装置と結合した電話通信 デジタル計算機のユーザインターフェイス 計算機間の情報転送 電話通信サービス 双方向TV,動画像配信等 デジタル計算機のユーザインターフェイス
主要キーワード 再イニシャライズ 通常ルーチン 初期マップ 事業性 同期放送 ファミコン ルーチンテーブル 生け垣
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(1996年4月16日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

目的

データ放送またはデータ通信サービスを受信するためのメニューに関し、視覚的に優れ、変化に富むメニュー表示と、ユーザー自身分身を操作するメニュー選択を採用することにより、ゲーム感覚で任意のサービスを選択できるメニュー表示・選択方法を提供する。

構成

人間2はユーザーが操作可能なユーザーシンボルであり、特定のサービスを象徴する建物4、6、8、10、12、14を選択することにより特定のサービスを開始する。また、ユーザーシンボルが噴水花壇等の障害物ぶつかった時にはサービスシンボルの移動が阻害される。さらに、移動するサービスシンボル6や、サービス可否にともなう建物表示の変更等により、ゲーム感覚でサービスを選択可能なメニュー画面を構成する。

概要

背景

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

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

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

概要

データ放送またはデータ通信サービスを受信するためのメニューに関し、視覚的に優れ、変化に富むメニュー表示と、ユーザー自身分身を操作するメニュー選択を採用することにより、ゲーム感覚で任意のサービスを選択できるメニュー表示・選択方法を提供する。

人間2はユーザーが操作可能なユーザーシンボルであり、特定のサービスを象徴する建物4、6、8、10、12、14を選択することにより特定のサービスを開始する。また、ユーザーシンボルが噴水花壇等の障害物ぶつかった時にはサービスシンボルの移動が阻害される。さらに、移動するサービスシンボル6や、サービス可否にともなう建物表示の変更等により、ゲーム感覚でサービスを選択可能なメニュー画面を構成する。

目的

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

効果

実績

技術文献被引用数
3件
牽制数
5件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

データ放送またはデータ通信において、複数の放送または通信サービスの中から、任意のサービスを選択する方法であって、受信可能なサービスをサービスシンボルとしてディスプレイ上に表示するステップと、ユーザーが操作可能なユーザーシンボルを表示するステップと、サービスシンボルでもなく、かつユーザーシンボルでもない背景画像を表示するステップを有し、ユーザーシンボルによって、特定の放送または通信サービスを実行するために、それに対応するサービスシンボルが選択されるメニュー画面において、ユーザーシンボルが特定の背景画像の一部と衝突した場合には、ユーザーシンボルの移動を阻害することを特徴とするメニュー表示、選択方法

請求項2

前記ユーザーシンボルと前記サービスシンボルとの衝突によって、特定のサービスシンボルが選択されることを特徴とする特許請求の範囲第1項記載のメニュー表示、選択方法。

請求項3

前記ユーザーシンボルの進行方直近に前記サービスシンボルがある時に、特定のボタンが押されることによって、特定のサービスシンボルが選択されることを特徴とする特許請求の範囲第1項記載のメニュー表示、選択方法。

請求項4

前記サービスシンボルは、前記背景画像上の特定の位置に固定されているシンボルと、前記背景画像上を移動するシンボルとを含む、特許請求範囲第1項記載のメニュー表示、選択方法。

請求項5

メニュー画面上で特定のイベントを発生させるためのイベントシンボルを表示するステップをさらに含み、前記ユーザーシンボルによってイベントシンボルが選択された場合には、放送または通信データを新たに受信することなくイベントが発生する特許請求範囲第1項記載のメニュー表示、選択方法。

請求項6

データ放送またはデータ通信において、複数の放送または通信サービスの中から、任意のサービスを選択する方法であって、受信可能なサービスをサービスシンボルとしてディスプレイ上に表示するステップと、ユーザーが操作可能なユーザーシンボルを表示するステップと、サービスシンボルでもなく、かつユーザーシンボルでもない背景画像を表示するステップと、前記サービスシンボルおよび背景画像を変更するための変更データを受信するステップを有し、ユーザーシンボルによって、特定の放送または通信サービスを実行するために、それに対応するサービスシンボルが選択されるメニュー画面において、前記変更データの受信に対応して、サービスシンボルまたは背景画像の表示が変更されることを特徴とするメニュー表示、選択方法。

請求項7

前記サービスシンボルの表示変更に対応して、当該サービスシンボルが選択された場合のサービスの実行を許可または禁止する特許請求の範囲第6項記載のメニュー表示、選択方法。

請求項8

前記サービスシンボルおよび背景画像の表示を初期設定する初期設定データを受信するステップをさらに含み、前記変更データが前記初期設定データに比べて頻繁に受信される特許請求の範囲第6項記載のメニュー表示、選択方法。

技術分野

0001

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

背景技術

0002

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

0003

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

0004

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

発明が解決しようとする課題

0005

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

0006

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

課題を解決するための手段

0007

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

0008

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

0009

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

0010

図4に本件発明のシステム構成図を示す。本件実施例では、家庭用ゲーム機スーパーファミコン登録商標)」を用いた衛星放送によるデータ放送受信システムを開示する。ゲーム機本体30には、衛星放送受信アダプタ32とメモリカートリッジ34が接続される。ユーザーがユーザーシンボルを操作するためのコントローラ36が接続される。衛星放送はBSアンテナ42で受信され、BSチューナ44で任意の放送チャンネルが選択される。選択された放送チャンネルの副搬送波信号はBSチューナによって復調され、ビットストリーム信号として出力される。分配器38はBSチューナ44からのビットストリーム信号を2分配し、その内の1つを衛星放送受信アダプタ32に与える。ゲーム機30からのビデオオーディオ信号はTV46に出力され、表示される。ACアダプタ40は、衛星放送受信アダプタ32に接続され、衛星放送受信アダプタ32、ゲーム機本体30、カートリッジ34に電源を供給する。

0011

図5は、本件発明のシステムブロック図である。分配器38は図5では省略されている。BSアンテナ42によって受信され、BSチューナ44によって復調されたビットストリーム信号は、データチャンネルデコーダ50に与えられる。データチャンネルデコーダ50は、ビットストリーム信号に同期した内部クロック信号を発生し、前記ビットストリーム信号とともにPCMデコーダ52に与える。ビットストリーム信号は図3に示すパケット構造を持ち、PCMデコーダ52によって誤り訂正を受けた後、PCM音声データ部とデータパケット部とに分離される。PCM音声データ部はDーAコンバータを介してアナログ音声信号としてゲーム機本体30に与えられ、データパケット部はデータチャンネルデコーダ50に出力される。

0012

データチャンネルデコーダ50は図3に示すようにデータパケットを複数個つなぎ合わせることにより、1つのデータファイルを構築する。ビットストリーム信号は図6に示すように、複数個のファイルを含む。これらのファイルは各々複数個のパケットからなり、それぞれのパケットは時分割で送信される。図3ヘッダ部はそれぞれのパケットがどのファイルに対応するデータであるかを示す論理チャンネル(LCI)を含み、CPU54から指定された論理チャンネルに基づいて、データチャンネルデコーダ50が特定のファイルを組み立てる。組み立てられた(あるいは組み立て途上の)データは、データチャンネル50内のバッファに蓄えられ、CPU54により適時ワークRAM62、PS−RAM58、またはフラッシュメモリ56に格納される。ROM60は、主として本件の特徴を成すゲーム性のあるメニュー画面を達成するためのプログラムを保持する。

0013

メモリから読み出された画像データは、CPU54によって、PPU64を介してビデオRAM66に格納される。PPU64はビデオRAM66のデータに基づいて、DーAコンバータ、ビデオエンコーダを通じてビデオ信号を生成し、TV46に与える。同様に各メモリから読み出された音声データはAPU68を介してオーディオRAM70に格納され、APU68によって音声信号として出力される。APUから出力された音声データは、D−Aコンバータによってアナログ信号に変換される。ミキサー72は、APU68からのアナログ音声信号と、PCMデコーダ52からのアナログ音声信号を混合し、TV46に与える。ポート74は、コントローラ36によって入力されるユーザーの操作情報をCPU54に与える。

0014

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

0015

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

0016

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

0017

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

0018

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

0019

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

0020

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

0021

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

0022

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

0023

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

0024

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

0025

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

0026

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

0027

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

0028

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

0029

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

0030

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

0031

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

0032

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

0033

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

0034

S6において、SVFが1の場合はサービスに関する処理へ分岐する。SVF(SERVICEFLAG)は、例えばユーザーシンボルがサービスシンボルと衝突し、サービスが開始される場合に1になる。サービスが開始されると、CPU54は、ワークRAM62内のトップメニュー情報エリアからSVNOに対応するサービスを検索し、当該サービスに関連する情報を入手する(S8)。SVNO(SERVICENo.) は、開始すべきサービスを指定するためのサービス番号を記憶する。前記サービスに関連する情報には、ジャンプアドレスオフセットアドレスまたは間接的にジャンプ先を指定するためのメニュー形式データを含む。

0035

CPU54は、前記サービスに関連する情報に基づいて、サービスエントリアドレスにジャンプし(S10)、それによってサービスルーチンが起動される(S12)。サービスルーチンは、通常、それ自体で完成された一つのプログラムを成し、サービスルーチンが終了するまで、メインルーチンには復帰しない。しかし、TCDルーチンをメインルーチンと共用で使用したい場合には、シーケンサプログラムを内蔵することによりTVフレーム単位でメインルーチンに復帰してもよい。シーケンサプログラムはTVフレーム順にサービスルーチンがどのように動作するかを定義する。サービスが終了する場合、再イニシャライズを行い、SVFを0に戻してからメインルーチンに復帰する。

0036

S6において、SVFが0の場合は、メニュー制御のための処理へ分岐する。CPU54は、S14において、メニュー制御データをロードし、各種許可フラグを設定し、マップデータおよびメニュー画像を変更するためのメニュー制御データ処理を実行する。その後、CPU54は、コントローラ36から入力されたユーザーのキー入力データ受け取り(S16)、キー入力データに基づく衝突判定、ユーザーシンボルの移動、サービス開始時のSVFのセット、イベント開始時のルーチンテーブル許可フラグのセット等を制御するイベントテーブル処理S18を実行する。その後CPU54は、ルーチンテーブル処理S20において、指定された処理ルーチンを実行する。

0037

ルーチンテーブル処理S20が終了すると、CPU54は、NMI信号(すなわちPPU64からCPU54へのVブランクイミングを示す信号)を待ち(22)、NMIルーチンS24を実行してTCDルーチンS2へ戻る。NMIルーチンS24においては、Vブランク中に実行すべき処理、例えばビデオRAM66内への画像データの転送等、を実行する。S4からS6のNO分岐を通ってS24へ到達する一連の処理は、TVの1フィールド中に処理され、この処理が毎フィールド繰り返される。本件実施例では、TCDファイルのロード、メニュー制御データファイルのロード、番組ファイルのロードを、同時に行うことはないが、CPUの動作速度に余裕がある場合には、TCDファイルのロードとメニュー制御データファイルのロードまたは、 TCDファイルのロードと番組ファイルのロードを各々並列に行ってもよい。本件メインルーチンのフローによると、メニュー制御データファイルのロードと番組ファイルのロードが同時に発生することがないため、最大でも2チャンネル分だけデータ放送をデコードすればよく、データチャンネルデコーダ50の構造を複雑にせずに済む。

0038

図16は、イニシャライズルーチンS2の詳細を示す。CPU54は、S30において、PPU64、APU68、PCMデコーダ52、データチャンネルデコータ50の初期設定を行い、S32において、タイトル画面を表示する。S34〜S42はデータチャンネルデコーダ50が正常にビットストリーム信号を受信しているかどうかをチェックする処理であり、機器に接続不良があってビットストリーム信号が正常に受信できない場合には、エラーメッセージを表示し、正常に受信できるまでループし続ける。

0039

CPU54は予め指定されているTCDファイルの論理チャンネル値をデータチャンネルデコーダ50に与え、TCDファイルをワークRAM62にロードする(S44)。TCDファイルの中から、予め指定されているPV、PR値を頼りに番組案内データファイルの論理チャンネルを抽出する(S46)。CPU54はTCDファイルの時と同様にして番組案内データファイルをロードし、ワークRAM62に格納する。ロードされた番組案内データファイルは、S50においてマップデータを初期化し、S52において初期マップすなわち初期メニュー画面を表示し、S54においてイベントテーブルを初期化し、S56においてルーチンテーブルを初期化し、S58においてイベントテーブルおよびルーチンテーブルの許可フラグを初期化するのに利用される。

0040

CPU54は、その後ユーザーシンボルを表示し(S60)、予約変数PV、PRに予め指定されているメニュー制御データファイルのPV、PR値をセットして、DFに0を、TFに1をセットする(S62)。DFおよびTFは、メニュー制御データ処理S14およびTCDルーチンS4において、各々のシーケンスを制御するのに用いられ、これによってTCDファイルとメニュー制御ファイルは同時にロード作業が発生しないように制御される。これによりイニシャライズルーチンは終了し、メインルーチンへ復帰する。

0041

図17は、TCDルーチンS4の詳細を示す。TFはTCDファイルロード時のシーケンスを制御し、CPU54は、TFが0の時、何もせず(S70)、TFが1の時、DCD(データチャンネルデコーダ)50にTCDファイルの論理チャンネルをセットし(S72、S74)、TFが2の時、DCDにバッファリングされたTDCファイルのデータをロードし、解析する(S78、S80)。TFが2の場合に、TCDデータ上で前記予約変数PV、PRで指定されたファイル(この場合は、メニュー制御データファイル)を発見すると、そのファイルの論理チャンネルをレジスタLCIRにストアし(S84)、DFを1にして当該ファイルのロードを予約する(S88)。ここで、目的ファイルは既に発見されているため、それ以上のTCDファイルのロードはキャンセルされ(S88)、TFが0にセットされてTCDファイルのロード作業は終了する(S90)。S82で前記予約変数PV、PRで指定されたファイルが無かった場合、ファイルの終端でなければ、継続してTCDファイルのロード作業を行い、ファイルの終端であればTFを1に戻してTCDファイルのロード作業を再度、最初からやりなおす。各々のシーケンスは、最終的にはすべてメインルーチンに復帰する。

0042

図18は、メニュー制御データ処理S14の詳細を示す。DFはメニュー制御データファイルロード時のシーケンスを制御し、CPU54は、DFが0の時、何もせず(S100)、DFが1の時、DCD50に対してLCIRにストアされているメニュー制御データファイルの論理チャンネルをセットし(S104、S106)、DFが2の時、ファイルの終端までTVフィールドごとに、メニュー制御データファイルの各部分をロードして、ワークRAM62に格納し(S110、S112、S114)、各々メインルーチンへ復帰する。DFが3の場合は、メニュー制御データファイルのデータを解析し、処理するシーケンスであることを意味し、以下の手順で実行される。

0043

ルーチンテーブル処理において強制イベントを実行中の場合、途中でルーチン許可フラグが変化することは好ましくないため、S116において何もせずにメインルーチンへ復帰する。強制イベント中で無い場合には、まず、番組案内シリアル番号をチェックし、番組案内データファイルが更新されたかどうかをチェックする(S118)。ここで、番組案内データファイルが更新されている場合には、S128にてメッセージを表示し、システムリセットを行うことにより、更新された番組案内データファイルをロードする。番組案内データファイルが更新されていない場合には、イベント許可フラグおよびルーチン許可フラグを更新し(S122)、マップデータを更新するとともにメニュー画像の表示変更データを作成する。この表示変更データは、NMIルーチンにおいて、Vブランク中にビデオRAM66に転送され、メニュー画像を変化させる。そしてDFに0が、TFに1がセットされ、メニュー制御データの処理を終了し、TCDファイルのロードを再度開始するよう準備し、メインルーチンへ復帰する。

0044

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

0045

CPU54は、S148において、衝突判定の結果に基づいて分岐する。ユーザーシンボルの移動方向にサービスシンボルがある場合には、当該サービスを開始するための準備を行う。まずユーザーシンボルを移動して、衝突画像を表示し(S150)、サービス番号(トップメニューシリアル番号を意味する)をSVNOにセットしてSVFを1にする(S152)。次に、TCDファイルとメニュー制御ファイルのロードをキャンセルし(S154)、TF、DFともに0をセットしてメニュー制御データファイルのロードに伴う全ての処理を停止する(S156)。その後メインルーチンに復帰するが、これにより、次のTVフィールドでサービスルーチンが起動する。

0046

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

0047

図20は、イベントテーブル処理S18の後半部分の詳細を示す。この後半部分では、Aボタンが押されることにより各サービスやイベントが開始されるため、コントローラ36のAボタンが押されているかどうかをS170にてチェックする。Aボタンが押されていない場合は、何もせずにメインルーチンに復帰する。Aボタンが押されている場合には、前述のイベントテーブル処理と同様にして進行方向のマップデータをリードし(S172)、イベントテーブル2(図12)を参照する(S174)。その後、参照結果に基づいて分岐し(S176)、参照結果がサービスシンボルの場合は、上述のイベントテーブル処理と同様にして当該サービスを行うための準備を行い(S150、S152、S154、S156)、参照結果がイベントシンボルの場合は、ルーチンテーブル上の対応ルーチン許可フラグをセットし(S184)、マップデータがイベントテーブル2上に無い場合には、何もせずにメインルーチンに復帰する。

0048

図21には、ルーチンテーブル処理S20の詳細を示す。ルーチンテーブル処理において、CPU54は、まずルーチンテーブル(図13)上で強制フラグがONになっている各ルーチンテーブルをチェックする(190)。許可されている強制ルーチンがあれば、S192からS194へ移行し、当該ルーチンを強制イベントとして実行し、メンルーチンへ復帰する。強制ルーチンがすべて不許可になっている場合には、強制フラグがOFFになっている各ルーチンテーブルをチェックし(S196)、許可されているルーチンを実行する(S194)。この通常ルーチンテーブルのチェックおよび実行は、ルーチンテーブルの終端まで繰り返し行われる(S202)。

0049

図22は、NMIルーチンS24の例を示す。NMIルーチンは、本実施例では、TVフィールドのVブランク開始と同時に実行される。このルーチンでは、ビデオRAM66に対して画像データを転送したり(S210)、強制イベントルーチンにおいてTVフレームに同期した各種シーケンスを実行するために、フレームカウンタインクリメントを行った後(S212)、メインルーチンに復帰する。

0050

図23には、ユーザーシンボルがゲームコーナーのサービスシンボル4と衝突した場合に実行されるサービスルーチンS12の一例を示す。CPU54は、ゲームコーナーサービス用の画面設定を行い(S220)、イニシャライズを行う(S222)。画面上には、「メモリ内のゲームを実行する」、「新たにゲームをダウンロードする」および「マップメニューへ戻る」という3つのメニューが表示され、ユーザーに選択される(S224)。「メモリ内のゲームを実行する」が選択された場合には、S226、S228を経由してS238に分岐し、フラッシュメモリ56に格納されているゲームプログラムが実行される。「新たにゲームをダウンロードする」が選択された場合には、S230、S232を経由してS240に分岐し、トップメニュー情報のPV、PRで指定される番組ファイル(ゲームプログラム)をロードするために、まずTCDファイルをロードする。ここで発見された論理チャンネルに基づいて、S242においてゲームプログラムがダウンロードされ、フラッシュメモリ56に格納される。

0051

「マップメニューへ戻る」が選択された場合には、S234、S236を介してS244へ移行し、ゲームコーナーサービスを終了し、メニュー画面へ戻る準備を行う。これは、マップデータに従って初期マップ(メニュー画像)を表示し(S244)、ユーザーシンボルを表示し(S246)、PV、PRにメニュー制御データファイルの値を、DFに0を、TFに1をセットし、SVFを0に戻すことにより達成される(S248)。このゲームコーナーサービスによって、ユーザーは、放送中のゲームプログラムに加えて、以前ロードして蓄えておいたゲームプログラムをも実行できる。ユーザーはメニュー画面によって構成される疑似世界で、ゲームセンターに入り、ゲームを遊ぶという感覚で、違和感なくかつ容易にサービスを選択、実行できる。

0052

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

0053

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

0054

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

発明の効果

0055

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

0056

図面の簡単な説明

0057

図1本件発明におけるメニュー画面の例を示す。
図2従来のメニューの例を示す。
図3パケットとファイルの関係を示す概念図である。
図4本件発明のシステム構成図を示す。
図5本件発明のシステムブロック図である。
図6放送データの概念図である。
図7メニュー制御データファイルの構成図である。
図8サービス情報の構成図である。
図9番組案内データファイルの構成図である。
図10衝突時のイベントテーブルを示す。
図11図10の衝突時のイベントテーブルの続きを示す。
図12Aボタン押下時に参照されるイベントテーブルを示す。
図13ルーチンテーブルの詳細を示す。
図14メモリマップを示す。
図15メインルーチンの全体的な流れを示すフローチャートである。
図16イニシャライズルーチンS2の詳細を示す。
図17TCDルーチンの詳細を示す。
図18メニュー制御データ処理の詳細を示す。
図19衝突時のイベントテーブル処理を示す。
図20Aボタン押下時のイベントテーブル処理を示す。
図21ルーチンテーブル処理の詳細を示す。
図22NMIルーチンの例を示す。
図23サービスルーチンの例を示す。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

新着 最近 公開された関連が強い 技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する挑戦したい社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ