JP2008512163A - データ処理 - Google Patents

Abstract

【課題】
【解決手段】 取外し可能記憶媒体がそれぞれのプログラムおよび関係するデータを記憶しているデータ処理装置であって、装置は、取外し可能記憶媒体読取り装置と、読取り装置によって現在読取り可能な第１の取外し可能記憶媒体からのプログラムを、その第１の取外し可能記憶媒体に記憶されたデータを用いて実行するための手段とを備えており、実行手段および／またはプログラムは、プログラムの実行の範囲内の少なくとも所定の時点で、第１の取外し可能記憶媒体が読取り装置から取外されることができ、第２の異なる取外し可能記憶媒体が読取り装置と関係づけられることができ、それによりプログラムの実行は第２の取外し可能記憶媒体から読取られたデータを用いて続行することができるように構成されている。

Description

この発明は、データ処理に関する。

データ処理の例としては、コンピュータゲームが周知であり、磁気および／または光ディスクといった多様な配布媒体で供給され得る。汎用コンピュータまたはより専用のゲームコンソールがこれらのゲームを行うために使用され得る。

ゲームが配布媒体に記憶されたオーディオおよび／またはビデオファイルを利用することは知られている。例えば、遊技者がコンピュータまたはゲームコンソールに接続されたマイクロホンに向かって歌う、ソニー（Sony（登録商標））のシング・スター（SingStar（商標））ゲームといったカラオケゲームが知られている。コンピュータまたはゲームコンソールは、ビデオを表示し、かつ／またはオーディオトラックを再生することができ、その意図は遊技者が一緒に歌うことである。歌詞および／または音符が遊技者に表示され、それにより遊技者は歌う内容や音程を知ることができる。

限られた数のオーディオ／ビデオファイルだけが配布媒体に記憶され得る。そのように、遊技者はゲームを行う時には限られた数の選択するべきトラックしかない。

１つの従来技術のゲームが知られており、（ｉ）「一般的な」音楽ＣＤ（ゲームには関連しない）がコンピュータまたはゲームコンソールに挿入されるのを可能にし、（ｉｉ）遊技者が再生されるオーディオファイルとしてこの一般的な音楽ＣＤからトラックを選択するのを可能にする。

別の従来技術のゲームが知られており、遊技者が「拡張ディスク」をコンピュータまたはゲームコンソールに挿入するのを可能にし、拡張ディスクは単にオーディオ／ビデオデータ記憶媒体として機能する媒体である。

ゲームの異なるバージョンを発売することが知られている。そのような異なるバージョンはしばしば、新しいゲーム機能性といった強化を有する。さらに、異なるバージョンは、例えばユーザにそのゲームを購入する気にさせるために、それらに記憶された異なるオーディオ／ビデオファイルを有するかもしれない。しかし、あるゲームの１つのバージョンを行っている時に、遊技者がそのゲームの別のバージョンからのトラックを行いたい場合、現在のゲームバージョンを出て、コンピュータまたはゲームコンソールに別のゲームバージョンをロードすることが必要である。これはたいてい時間がかかりゲームの楽しみを損なう。

この発明は、取外し可能記憶媒体がそれぞれのプログラムおよび関係するデータを記憶しているデータ処理装置を提供し、装置は、
取外し可能記憶媒体読取り装置と、
読取り装置によって現在読取り可能である第１の取外し可能記憶媒体からのプログラムを、その第１の取外し可能記憶媒体に記憶されたデータを用いて実行するための手段とを備えており、実行手段および／またはプログラムは、プログラムの実行の範囲内の少なくとも所定の時点で、第１の取外し可能記憶媒体が読取り装置から取外されることができ、第２の異なる取外し可能記憶媒体が読取り装置と関係づけられることができ、それによりプログラムの実行は第２の取外し可能記憶媒体から読取られたデータを用いて続行することができるように構成されている。

本発明の種々のさらなるそれぞれの態様および特徴は、添付の請求項において規定される。

本発明は、（例えば）ゲームの異なるバージョンが異なるデータの集合（例えばオーディオ／ビデオファイル）から構成されるかもしれないことを認識する。本発明の実施形態によれば、遊技者がゲームの第１のバージョンを行っている時に、遊技者が、ゲームの現在行われていたバージョンの一部を形成しておらずゲームの別のバージョンの一部を形成するデータ（例えばオーディオ／ビデオファイル）を使用するゲームを行いたい場合に、その遊技者はゲームコンソールをリセットしゲームの第２のバージョンをロードする必要はない。

ここで本発明の実施形態を添付図面に関して例証としてのみ説明する。

図１は、プレイステーション２の全体的なシステムアーキテクチャを図式的に例示している。システムユニット１０が、システムユニットに接続可能な種々の周辺装置とともに設けられている。

システムユニット１０は、エモーションエンジン（Emotion Engine）１００、グラフィックスシンセサイザ（Graphics Synthesiser）２００、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）を有するサウンドプロセッサユニット３００、読出し専用メモリ（ＲＯＭ）４００、コンパクトディスク（ＣＤ）およびディジタル多用途ディスク（ＤＶＤ）読取り装置４５０、ラムバスダイナミックランダムアクセスメモリ（ＲＤＲＡＭ；Rambus Dynamic Random Access Memory）ユニット５００、専用ＲＡＭ７５０を備える入出力プロセッサ（ＩＯＰ）７００を含む。（オプションの）外部ハードディスクドライブ（ＨＤＤ）３９０が接続され得る。

入出力プロセッサ７００は２つのユニバーサルシリアルバス（ＵＳＢ）ポート７１５およびｉＬｉｎｋまたはＩＥＥＥ１３９４ポート（ｉＬｉｎｋはＩＥＥＥ１３９４規格のソニー・コーポレーションによる具体化である）を有する。ＩＯＰ７００は、全部のＵＳＢ、ｉＬｉｎｋおよびゲームコントローラデータトラフィックを取り扱う。例えば、ユーザがゲームを行っている時、ＩＯＰ７００はゲームコントローラからデータを受け取り、それをエモーションエンジン１００に向けて送り、エモーションエンジンは相応にゲームの現在状態を更新する。ＩＯＰ７００は、迅速なデータ転送速度を助成する直接メモリアクセス（ＤＭＡ）アーキテクチャを有する。ＤＭＡは、ＣＰＵにデータを通過させることを要さずにメインメモリから装置へのデータの転送を伴う。ＵＳＢインタフェースは、オープンホストコントローラインタフェース（ＯＨＣＩ）と互換性を有し、１．５Ｍｂｐｓないし１２Ｍｂｐｓのデータ転送速度を取り扱うことができる。これらのインタフェースの装備により、プレイステーション２はビデオカセットレコーダ（ＶＣＲ）、ディジタルカメラ、マイクロホン、セットトップボックス、プリンタ、キーボード、マウスおよびジョイスティックといった周辺装置と潜在的に互換性を有することになる。

一般に、首尾よいデータ通信がＵＳＢポート７１５に接続された周辺装置と生じるためには、デバイスドライバといった適切なソフトウェア部分が設けられなければならない。デバイスドライバ技術は極めて周知であり、当業者はデバイスドライバまたは類似のソフトウェアインタフェースがここに記載された実施形態において要求され得ることを承知しているはずであると言うだけで、ここでは詳述しない。

現在の実施形態では、ＵＳＢマイクロホン７３０がＵＳＢポートに接続されている。ＵＳＢマイクロホン７３０が手持ち型マイクロホンであるとするか、または人間オペレータによって装着されるヘッドセットの一部を形成することもできることは十分理解されるであろう。ヘッドセットを装着する長所は、人間オペレータの手が他の行動を実行するために自由になることである。マイクロホンは、アナログ−ディジタルコンバータ（ＡＤＣ）および基本的なハードウエアベースのリアルタイムデータ圧縮・符号化装置を備えており、それによりオーディオデータはプレイステーション２システムユニット１０での復号化のために１６ビットモノラルＰＣＭ（非圧縮フォーマット）といった適切なフォーマットでＵＳＢポート７１５にマイクロホン７３０によって送られる。

ＵＳＢポートのほかに、２つの他のポート７０５、７１０が知的所有権下にあるソケットであり、ゲーム関連情報を記憶するための知的所有権下にある不揮発性ＲＡＭメモリカード７２０、ハンドヘルド型ゲームコントローラ７２５または、ダンスマットといったハンドヘルド型コントローラを模した装置（図示せず）の接続を可能にする。

システムユニット１０は、ネットワークとのインタフェース（例えばイーサネットインタフェース）を付与するネットワークアダプタ８０５と接続されているかもしれない。このネットワークは、例えば、ＬＡＮ、ＷＡＮまたはインターネットであるとしてよい。ネットワークは、一般的なネットワークまたは、ゲーム関連通信に専用にされているものであるとしてよい。ネットワークアダプタ８０５は、同じネットワークに接続されている他のシステムユニット１０との間でデータが送受信されることを可能にする（他のシステムユニット１０もまた対応するネットワークアダプタ８０５を有する）。

エモーションエンジン１００は、ゲームアプリケーション用の３次元（３Ｄ）グラフィックスの効率的なシミュレーション向けに特殊に設計された１２８ビット中央処理装置（ＣＰＵ）である。エモーションエンジンの構成要素は、データバス、キャッシュメモリおよびレジスタを含み、それらの全部が１２８ビットである。これは大量のマルチメディアデータの高速処理を助成する。比較すれば、従来のＰＣは基本的な６４ビットデータ構造を有する。プレイステーション２の浮動小数点計算性能は６．２ＧＦＬＯＰＳである。エモーションエンジンはまた、３ＤグラフィックスデータおよびＤＶＤデータの同時処理を可能にするＭＰＥＧ２デコーダ回路を備える。エモーションエンジンは、数学的変換および変形を含む幾何学計算を実行し、さらに例えば２物体間の摩擦の計算などのシミュレーションオブジェクトの物理学に関係する計算も実行する。それは、後にグラフィックスシンセサイザ２００によって利用される画像レンダリングコマンドのシーケンスを生成する。画像レンダリングコマンドは表示リストの形態で出力される。表示リストは、グラフィックスシンセサイザに対し、いずれの基本図形オブジェクト（例えば点、直線、三角形、スプライト）を画面上のいずれの座標に描くべきかを指定する一連の描画コマンドである。それゆえ、典型的な表示リストは、頂点を描くコマンド、多角形の面を陰影づけるコマンド、ビットマップをレンダリングするコマンドなどを含むであろう。エモーションエンジン１００は複数の表示リストを非同期で生成することができる。

グラフィックスシンセサイザ２００は、エモーションエンジン１００によって生成された表示リストのレンダリングを実行するビデオアクセラレータである。グラフィックスシンセサイザ２００は、複数の表示リストを取り扱い追跡し管理するグラフィックスインタフェースユニット（ＧＩＦ）を含む。グラフィックスシンセサイザ２００のレンダリング機能は、いくつかの代替的標準出力画像フォーマット、すなわちＮＴＳＣ／ＰＡＬ、高精細度ディジタルＴＶおよびＶＥＳＡをサポートする画像データを生成することができる。一般に、グラフィックスシステムのレンダリング能力は、そのそれぞれがグラフィックスプロセッサ内部に位置するピクセルエンジンとビデオメモリとの間のメモリ帯域幅によって規定される。従来のグラフィックスシステムは、使用可能な帯域幅を制限しがちであるオフチップバスによってピクセルロジックに接続された外部ビデオランダムアクセスメモリ（ＶＲＡＭ）を使用する。しかし、プレイステーション２のグラフィックスシンセサイザ２００は、比較的大きい３８．４ギガバイト／秒のメモリアクセス帯域幅を可能にする単一の高性能チップ上にピクセルロジックおよびビデオメモリを備えている。グラフィックスシンセサイザは理論的に、毎秒７５００万ポリゴンのピークドローイング能力を達成することができる。テクスチャ、照明および透明度といった全範囲の効果を伴っても、毎秒２０００万ポリゴンの持続した速度が連続的に描かれ得る。従って、グラフィックスシンセサイザ２００は映画品質画像をレンダリングすることができる。

サウンドプロセッサユニット（ＳＰＵ）３００は事実上、ディジタル・シアター・サラウンド（ＤＴＳ（登録商標））サウンドおよび、ＤＶＤに使用されるサウンドフォーマットであるＡＣ−３（ドルビー・ディジタルとしても知られる）といった３Ｄディジタルサウンドを認識することができるシステムのサウンドカードである。

関係するスピーカ装置３１０を備えるビデオモニタまたはテレビといった表示・サウンド出力装置３０５が、グラフィックスシンセサイザ２００およびサウンド処理装置３００からビデオ／オーディオ信号を受け取るために接続されている。

エモーションエンジン１００をサポートするメインメモリは、ラムバス・インコーポレーテッド（Rambus Incorporated）社が生産するＲＤＲＡＭ（ラムバスダイナミックランダムアクセスメモリ）モジュール５００である。このＲＤＲＡＭメモリサブシステムは、ＲＡＭ、ＲＡＭコントローラおよび、ＲＡＭをエモーションエンジン１００に接続するバスを含む。

図２は、図１のエモーションエンジン１００のアーキテクチャを図式的に例示している。エモーションエンジン１００は、浮動小数点ユニット（ＦＰＵ）１０４、中央処理装置（ＣＰＵ）コア１０２、ベクトルユニット０（ＶＵ０）１０６、ベクトルユニット１（ＶＵ１）１０８、グラフィックスインタフェースユニット（ＧＩＦ）１１０、割込みコントローラ（ＩＮＴＣ）１１２、タイマユニット１１４、直接メモリアクセスコントローラ１１６、画像データプロセッサユニット（ＩＰＵ）１１８、ダイナミックランダムアクセスメモリコントローラ（ＤＲＡＭＣ）１２０、サブバスインタフェース（ＳＩＦ）１２２を含み、これらの構成要素の全部は１２８ビットのメインバス１２４によって接続されている。

ＣＰＵコア１０２は、３００ＭＨｚでクロックされる１２８ビットプロセッサである。ＣＰＵコアはＤＲＡＭＣ１２０を通じて３２ＭＢのメインメモリにアクセスできる。ＣＰＵコア１０２の命令セットは、付加的なマルチメディア命令とともに一部ＭＩＰＳ ＩＶ ＲＩＳＣ命令を備えるＭＩＰＳ ＩＩＩ ＲＩＳＣに基づく。ＭＩＰＳ ＩＩＩおよびＩＶは、ＭＩＰＳテクノロジーズ・インコーポレーテッド（MIPS Technologies）社の知的所有権下にある縮小命令セットコンピュータ（ＲＩＳＣ）命令セットアーキテクチャである。標準命令は６４ビット双方向スーパースカラーであり、それは２つの命令が同時に実行され得ることを意味する。他方、マルチメディア命令は、２つのパイプラインによって１２８ビット命令を使用する。ＣＰＵコア１０２は、１６ＫＢの命令キャッシュ、８ＫＢのデータキャッシュおよび、ＣＰＵによる直接の専用使用のために確保されたキャッシュの一部である１６ＫＢのスクラッチパッドＲＡＭを含む。

ＦＰＵ１０４は、ＣＰＵコア１０２のための第１のコプロセッサとして働く。ベクトルユニット１０６が第２のコプロセッサの働きをする。ＦＰＵ１０４は、浮動小数点積和論理演算装置（ＦＭＡＣ）および浮動小数点除算計算器（ＦＤＩＶ）を含む。ＦＭＡＣおよびＦＤＩＶの両方とも３２ビット値で演算するので、演算が（４つの３２ビット値から構成された）１２８ビット値で行われた場合、演算は全部の４つの部分で並行して行われ得る。例えば、２つのベクトルの加算は同時に行われ得る。

ベクトルユニット１０６および１０８は、数学演算を実行し、ベクトル方程式の乗算および加算を評価する際に極めて高速である本質的に専用のＦＰＵである。それらは、加算および乗算演算に浮動小数点乗算加算計算器（ＦＭＡＣ）を、そして除算および平方根演算に浮動小数点除算器（ＦＤＩＶ）を使用する。それらは、マイクロプログラムを記憶するための内蔵メモリを有し、ベクトルインタフェースユニット（ＶＩＦ）を通じてシステムの残りの部分とインタフェースを取る。ベクトルユニット０ １０６は、それが本質的に第２の専用ＦＰＵであるように、専用の１２８ビットバスを通じてＣＰＵコア１０２のコプロセッサとして働くことができる。他方、ベクトルユニット１ １０８は、グラフィックスシンセサイザ２００との専用バスを有するので、それゆえ完全に別個のプロセッサとみなすことができる。２つのベクトルユニットの包含は、ソフトウェア開発者がその仕事をＣＰＵの異なる部分間で分割することを可能にし、ベクトルユニットは直列または並列接続のどちらかで使用され得る。

ベクトルユニット０ １０６は、４個のＦＭＡＣおよび１個のＦＤＩＶを含む。それはコプロセッサ接続を通じてＣＰＵコア１０２に接続されている。それは、データ用に４Ｋｂのベクトルユニットメモリおよび命令用に４Ｋｂのマイクロメモリを有する。ベクトルユニット０ １０６は、表示用の画像に関係する物理計算を実行するために役立つ。それは主にＣＰＵコア１０２とともに非パターン化された幾何学処理を実行する。

ベクトルユニット１ １０８は、５個のＦＭＡＣおよび２個のＦＤＩＶを含む。それはＣＰＵコア１０２へのいかなる直接的経路も持たないが、ＧＩＦユニット１１０への直接的経路を有する。それは、データ用に１６Ｋｂのベクトルユニットメモリおよび命令用に１６Ｋｂのマイクロメモリを有する。ベクトルユニット１ １０８は変換を実行するために役立つ。それは、パターン化された幾何学処理を主に実行し、生成された表示リストをＧＩＦ１１０に直接出力する。

ＧＩＦ１１０はグラフィックスシンセサイザ２００とのインタフェースユニットである。それは、表示リストパケットの最初のタグ指定に従ってデータを変換し、複数の転送を互いに裁定しながら、ドローイングコマンドをグラフィックスシンセサイザ２００に転送する。割込みコントローラ（ＩＮＴＣ）１１２は、ＤＭＡＣ１１６を除く周辺装置からの割込みを裁定する働きをする。

タイマユニット１１４は、１６ビットカウンタを備える４個の独立したタイマを含む。タイマは、バスクロックによってか（１／１６または１／２５６間隔で）、または外部クロックのどちらかによって駆動される。ＤＭＡＣ１１６は、メインメモリと周辺プロセッサとの間またはメインメモリとスクラッチパッドメモリとの間のデータ転送を取り扱う。それは同時にメインバス１２４を裁定する。ＤＭＡＣ１１６の性能最適化は、エモーションエンジン性能を改善するための重要な方途である。画像処理ユニット（ＩＰＵ）１１８は、圧縮された動画およびテクスチャ画像を伸張するために使用される画像データプロセッサである。それは、Ｉ−ＰＩＣＴＵＲＥマクロブロック復号化、色空間変換およびベクトル量子化を実行する。最後に、サブバスインタフェース（ＳＩＦ）１２２はＩＯＰ７００とのインタフェースユニットである。それは、サウンドチップおよび記憶装置といった入出力装置を制御するためのそれ自身のメモリおよびバスを有する。

図３は、グラフィックスシンセサイザ２００の機器構成を図式的に例示している。グラフィックスシンセサイザは、ホストインタフェース２０２、セットアップ／ラスター化ユニット、ピクセルパイプライン２０６、メモリインタフェース２０８、フレームページバッファ２１４およびテクスチャページバッファ２１６を含むローカルメモリ２１２、およびビデオコンバータ２１０を含む。

ホストインタフェース２０２は、ホスト（この場合、エモーションエンジン１００のＣＰＵコア１０２）とデータを転送する。ホストからのドローイングデータおよびバッファデータの両方ともこのインタフェースを通過する。ホストインタフェース２０２からの出力はグラフィックスシンセサイザ２００に供給され、グラフィックスシンセサイザは、エモーションエンジン１００から受信された頂点情報に基づきピクセルを描くためにグラフィックスを展開し、各ピクセルについてＲＧＢＡ値、デプス値（すなわちＺ値）、テクスチャ値およびフォッグ値といった情報を計算する。ＲＧＢＡ値は赤、緑、青（ＲＧＢ）の色成分を指定し、Ａ（アルファ）成分は画像オブジェクトの不透明さを表現する。アルファ値は完全に透明から完全に不透明までの範囲を取ることができる。ピクセルデータはピクセルパイプライン２０６に供給され、ピクセルパイプラインはテクスチャマッピング、フォギングおよびアルファブレンディングといったプロセスを実行し、計算されたピクセル情報に基づき最終的なドローイング色を決定する。

ピクセルパイプライン２０６は、１６個のピクセルエンジンＰＥ１、ＰＥ２．．ＰＥ１６を含み、それにより最大１６ピクセルを並行して処理することができる。ピクセルパイプライン２０６は、３２ビット色および３２ビットＺバッファを伴い１５０ＭＨｚで動作する。メモリインタフェース２０８は、ローカルグラフィックスシンセサイザメモリ２１２からデータを読出しデータを書込む。それは、ドローイングピクセル値（ＲＧＢＡおよびＺ）をピクセル演算の終わりにメモリに書込み、フレームバッファ２１４のピクセル値をメモリから読出す。フレームバッファ２１４から読出されたこれらのピクセル値は、ピクセルテストまたはアルファブレンディングに使用される。メモリインタフェース２０８はまた、フレームバッファの現在の内容についてのＲＧＢＡ値をローカルメモリ２１２から読出す。ローカルメモリ２１２は、グラフィックスシンセサイザ２００に組み込まれている３２メガビット（４ＭＢ）メモリである。それは、フレームバッファ２１４、テクスチャバッファ２１６および３２ビットＺバッファ２１５として編成することができる。フレームバッファ２１４は、カラー情報といったピクセルデータが格納されるビデオメモリの部分である。

グラフィックスシンセサイザは、視覚的詳細を３Ｄジオメトリに付加するために２Ｄ−３Ｄテクスチャマッピングプロセスを使用する。各テクスチャが、３Ｄ画像オブジェクトにラップアラウンドされることができ、３Ｄグラフィック効果を与えるために伸縮およびスキューされる。テクスチャバッファは、画像オブジェクトについてのテクスチャ情報を格納するために使用される。Ｚバッファ２１５（デプスバッファとしても知られる）は、ピクセルについてのデプス情報を格納するために使用可能なメモリである。画像は、グラフィックスプリミティブまたはポリゴンとして知られる基本的構成単位から構築される。ポリゴンがＺバッファリングによりレンダリングされる場合、そのピクセルの各々のデプス値は、Ｚバッファに格納された対応する値と比較される。Ｚバッファに格納された値が新しいピクセル値のデプス以上であれば、このピクセルは可視であると決定され、それによりそれはレンダリングされなければならず、Ｚバッファはその新しいピクセルデプスで更新されることになる。しかし、Ｚバッファデプス値が新しいピクセルデプス値未満であれば、新しいピクセル値はすでに描かれたものの背後にあり、レンダリングされないであろう。

ローカルメモリ２１２は、フレームバッファおよびＺバッファにアクセスするための１０２４ビット読出しポートおよび１０２４ビット書込みポート、ならびにテクスチャ読出しのための５１２ビットポートを有する。ビデオコンバータ２１０は、指定された出力フォーマットでフレームメモリの内容を表示するために動作可能である。

図４は、いわゆるカラオケゲームの間に再生されるオーディオ／ビデオファイルを選択するカルーセル（carousel）方法を図式的に例示している。この実施形態において、カラオケゲームはプレイステーション２ゲームコンソールで行われているが、異なる実施形態では異なるゲームコンソール（それは汎用コンピュータまたはより専用のゲーム機であるかもしれない）を利用できることは十分理解されるであろう。また、実施形態はこれらのカラオケゲームに限定されず、オーディオ／ビデオファイルが選択され得るいずれかの他のシステムも含むことも十分理解されるであろう。さらに、実施形態はオーディオ／ビデオファイルに限定されず、他のデータファイルがユーザによる選択のために表示され得ることも十分理解されるであろう。

図４に図示されたこの例では、多数（例えば３０）のオーディオ／ビデオトラックアイコンが表示出力装置３０５においてカルーセル構成１０００で表示され、現在選択されたオーディオ／ビデオトラックアイコン１０１０が遊技者の最も近くに表示されている。他のオーディオ／ビデオトラックアイコン１０２０、１０３０、１０４０、１０５０等が、まるでそれらが大きな円形カルーセルの一部を形成するように示されている。遊技者は、カルーセルを回転させるためにハンドヘルド型ゲームコントローラ７２５といった入力装置を介してゲームコンソールと対話することができ、それにより次のオーディオ／ビデオトラックアイコンが選択される。選択は方向に関し順方向または逆方向であってよい。例えば、遊技者がハンドヘルド型ゲームコントローラ７２５で「左」キーを押した場合、カルーセルは左方向に移動し、それによりオーディオ／ビデオトラックアイコン１０４０が現在選択されたオーディオ／ビデオトラックアイコンになるかもしれない。

いったん遊技者がその者が使用したいオーディオ／ビデオトラックを見つけると、その者は、例えばハンドヘルド型ゲームコントローラ７２５のボタンを押すことによってその事をゲームコンソールに知らせ、現在選択されたオーディオ／ビデオトラックアイコンに対応するオーディオ／ビデオトラックがゲームコンソールによって再生される。

図５は、配布媒体１１００および配布媒体１１００に記憶されたデータを図式的に例示している。この例において、配布媒体１１００はＤＶＤであるが、他の実施形態ではゲームコンソールと互換性を有するいずれかの他の形態の配布媒体を利用し得ることは十分理解されるであろう。

配布媒体１１００はゲームのためのアプリケーションソフトウェア１１１０を記憶している。一般に、アプリケーションソフトウェア１１１０は、（実行可能ファイル、ダイナミックリンクライブラリ（ＤＬＬ）などといった）１つ以上のソフトウェアファイルより構成される。さらに、アプリケーションソフトウェア１１１０は、例えばコンフィギュレーションデータを含み得る１つ以上の他のデータファイルより構成されるかもしれない。

現在のカラオケゲームの場合、配布媒体１１００はまた１つ以上のオーディオファイル１１２０も記憶している。オーディオファイル１１２０の各々は、カラオケゲームの遊技者が一緒に歌うことになる歌に関連するオーディオデータより構成される。オーディオファイル１１２０の各々について、配布媒体１１００はまた、対応するビデオファイル１１３０および対応する記述ファイル１１４０も記憶している。ビデオファイル１１３０の各々は、対応するオーディオファイル１１２０が再生されている間に表示されるべきビデオシーケンスに関連するビデオデータより構成される。記述ファイル１１４０は以下でさらに詳細に説明する。

図５では、ｍ個のオーディオファイル１１２０、ｍ個のビデオファイル１１３０およびｍ個の記述ファイル１１４０が存在する。オーディオファイル１１２０、ビデオファイル１１３０および記述ファイル１１４０の他の構成が可能であることは十分理解されるであろう。例えば、（ｉ）オーディオファイル１１２０およびその対応するビデオファイル１１３０は１つの多重化されたオーディオ／ビデオファイルに併合されるかもしれない、（ｉｉ）ビデオファイル１１３０のうちの１つがオーディオファイル１１２０のうちの複数のものと関係づけられるかもしれない、かつ／または、（ｉｉｉ）記述ファイル１１４０は１つの統一された記述ファイルに併合されるかもしれない。

オーディオファイル１１２０およびその対応するビデオファイル１１３０は、（オーディオファイル１１２０およびビデオファイル１１３０が配布媒体１１００で別個のファイルとして、または単一の多重化ファイルとして記憶されているかに関わらず）集合的にオーディオ／ビデオファイル１１５０と呼ぶものとする。

カラオケゲームの異なるバージョンはオーディオ／ビデオファイル１１５０の異なる集合（および対応して異なる記述ファイル１１４０）より構成されるかもしれない。現在の実施形態によれば、遊技者がゲームの第１のバージョンを行っている時、遊技者がゲームの第１のバージョンの一部を形成しておらずゲームの第２のバージョンの一部を形成するオーディオ／ビデオファイル１１５０を使用するゲームを行いたい場合、その遊技者は、ゲームコンソールをリセットしゲームの第２のバージョンをロードする必要はない。

図６は、カラオケゲームを行っている時にオーディオ／ビデオファイル１１５０を選択する際に伴うステップを例示している概略フローチャートである。

ステップＳ１２００で、ゲームコンソールは、ゲームコンソールに現在ロードされている配布媒体１１００に記憶されたゲームソフトウェアアプリケーション１１１０のバージョンで初期化される。現在の実施形態の場合、これは、ゲームが行われている間にゲームコンソールがソフトウェアアプリケーション１１１０で初期化される必要がある唯一の時である。

ステップＳ１２０２で、遊技者は、（例えばハンドヘルド型ゲームコントローラ７２５を用いて）ゲームを制御して選択モードに入り、それによって図４に図示されたカルーセル構成１０００が表示される。これは、後述の通り、ユーザが現在の配布媒体１１００を取り出し別のものを挿入するための適格な機会を成すことができる。

ステップＳ１２０４で、遊技者は所望のオーディオ／ビデオファイル１１５０を探索するために（図４に関して説明した方法を用いて）カルーセル構成１０００と対話する。ステップＳ１２０６で、遊技者が所望のオーディオ／ビデオファイル１１５０を捜し出すことができた場合（すなわち、所望のオーディオ／ビデオファイル１１５０はゲームコンソールに現在ロードされている配布媒体１１００に記憶されている）、その後ステップＳ１２０８で、遊技者は（図４に関して説明した方法を用いて）所望のオーディオ／ビデオファイル１１５０を選択する。その後ステップＳ１２１０で、ゲームコンソールは選択されたオーディオ／ビデオファイル１１５０を利用し、それにより遊技者はゲームを行うことができる。いったん遊技者が自己の順番を終えると、処理はステップＳ１２０２に戻る。

ステップＳ１２０６で、遊技者が所望のオーディオ／ビデオファイル１１５０を捜し出すことができない場合（すなわち、所望のオーディオ／ビデオファイル１１５０はゲームコンソールに現在ロードされている配布媒体１１００に記憶されていない）、その後ステップＳ１２１２で、遊技者は、ゲームコンソールに現在ロードされている配布媒体１１００を放出するようにゲームコンソールに命令することができる。これは、例えばハンドヘルド型ゲームコントローラ７２５のボタンを押すことによって達成され得る。あるいは、遊技者はゲームコンソールのボタンを押すこともできる。

ステップＳ１２１４で、遊技者は異なる配布媒体１１００をゲームコンソールに挿入する。好ましくは、この新しく挿入された配布媒体１１００は遊技者が望むオーディオ／ビデオファイル１１５０を記憶している。

ステップＳ１２１６で、新しく挿入された配布媒体１１００に記憶されているオーディオ／ビデオファイル１１５０は、アプリケーションソフトウェア１１１０の制御下でゲームコンソールによって検出される。図４に図示されたカルーセル構成１０００はその後、新しく検出されたオーディオ／ビデオファイル１１５０に従って更新される。制御はその後ステップＳ１２０４に戻り、そこで遊技者は所望のオーディオ／ビデオファイル１１５０を探索する。

従って、現在の実施形態によれば、遊技者は、ゲームの現在の（第１の）バージョンでゲームコンソールを初期化するために使用された配布媒体１１００を放出するようにゲームコンソールに要求することができる。遊技者はその後、ゲームの異なる（第２の）バージョンを収容している配布媒体１１００をゲームコンソールに挿入することができる。その後この新しく挿入された配布媒体１１００に記憶されたオーディオ／ビデオファイル１１５０が検出される。オーディオ／ビデオファイル１１５０を表示するための図４に図示されたようなカルーセル構成１０００はその後、新しく挿入された配布媒体１１００からの新しく検出されたオーディオ／ビデオファイル１１５０に従って更新される。ここで、「第１」および「第２」のバージョンという言及は、バージョンの発売順序ではなく、配布媒体がゲームコンソールに挿入された順序を言う。

ステップＳ１２１６でカルーセル構成１０００に表示されたオーディオ／ビデオトラックアイコンが単に新しく挿入された配布媒体１１００からのオーディオ／ビデオファイル１１５０に対応し得ることは十分理解されるであろう。あるいは、ゲームコンソールは、第１の配布媒体１１００からのオーディオ／ビデオファイル１１５０の記述（例えば、対応する記述ファイル１１４０の一部を形成し得る対応するオーディオ／ビデオトラックアイコン）を（例えばメモリに）記憶することができ、それにより、第２の配布媒体１１００がゲームコンソールに存在する時に、カルーセル構成１０００は第１および第２の両方の配布媒体１１００からのオーディオ／ビデオファイル１１５０に対応するオーディオ／ビデオトラックアイコンを表示することができる。ステップＳ１２０８で、遊技者がその時ゲームコンソールに現在存在する配布媒体１１００に記憶されていないオーディオ／ビデオファイル１１５０を選択した場合、遊技者は適切な配布媒体１１００をゲームコンソールに挿入するように（例えばスクリーンメッセージによって）促される。

従って、現在の実施形態は、遊技者が（ｉ）ゲームコンソールをリブートする必要なく、または（ｉｉ）現在のゲームを出て新しいゲームを再始動する必要なく、行われているゲームの異なるバージョンからオーディオ／ビデオファイル１１５０にアクセスすることを可能にする。

各々がゲームの異なるバージョンを記憶している２個を超える配布媒体１１００に遊技者がアクセスすることができ、そして上記のプロセスが使用されて遊技者がそれらの配布媒体１１００のいずれかに記憶されたオーディオ／ビデオファイル１１５０のいずれかにアクセスできるようになり得ることもまた十分理解されるであろう。

ゲームアプリケーションソフトウェア１１１０自体がゲームコンソールのメモリにロードされることができ、それにより配布媒体１１００を入れ替える唯一の目的は単に、遊技者がゲームを再始動する必要なく異なるオーディオ／ビデオファイル１１５０にアクセスするのを可能にすることであることは十分理解されるであろう。

ゲームを行うことを助成するために、（図５に図示の通り）オーディオ／ビデオファイル１１５０に関連して配布媒体１１００に記憶されたいわゆる記述ファイル１１４０を有することがしばしば必要である。例えば、これらの記述ファイル１１４０は歌の歌詞および／または音符を含むかもしれず、カラオケゲームは遊技者が歌と一緒に歌うことを可能にするためにこの情報を表示する。従って、従来の一般的な音楽ＣＤは、それがそのような記述ファイル１１４０を備えて設計／製造されていないので、そのようなカラオケゲームのために使用されることができない。また、オーディオ／ビデオファイルは暗号化されているか、または少なくともそれらへのアクセスが制限されているかもしれない。従来のＣＤまたはその類はそのようなアクセス制限と互換性がない。

さらに、純粋にオーディオ／ビデオデータファイル１１５０（そしてもしかすると記述ファイル１１４０）を収容している「拡張ディスク」は、ゲームコンソールを初期化しゲームの再生を制御するために使用される実際のゲームアプリケーションソフトウェア１１１０を記憶していない。それゆえ、そのような拡張ディスクを利用する別のゲームにおいて、遊技者が、アプリケーションソフトウェア１１１０を収容している配布媒体に記憶されておらず代わりに拡張ディスクだけに記憶されているオーディオ／ビデオファイル１１５０を使用するゲームを行いたい場合、その遊技者はアプリケーションソフトウェア１１１０を収容している配布媒体および拡張ディスクの両方を必要とする。しかし現在の実施形態によれば、所望のオーディオ／ビデオファイル１１５０は、ゲームを行うためのアプリケーションソフトウェア１１１０も記憶している配布媒体１１００に記憶されている。

図１０は、本発明の代替的な実施形態を図式的に例示しており、この場合、所望のオーディオファイル１１２０は、オーディオデータ（トラック）が従来の一般的な音楽ＣＤに記憶されているのと同様にしてＣＤ１６１０に記憶されている。しかし、第１のオーディオトラックは、その第１のオーディオトラックに対応するオーディオファイル１１２０のオーディオデータだけでなく、オーディオファイル１１２０の各々に対応する記述ファイル１１４０および好ましくは（しかし必ずしもではなく）ビデオファイル１１３０のデータを含み、ビデオファイル１１３０および記述ファイル１１４０はオーディオデータとして符号化されている。（やはり、別個のファイルとしてのビデオファイル１１３０および記述ファイル１１４０の構成は純粋に例示的であり、これらのファイルは例えば１つ以上の他のファイルに結合され得ることは十分理解されるであろう）。ビデオファイル１１３０および記述ファイル１１４０は、（従来の一般的な音楽ＣＤでのデータの再生順序で）第１のオーディオトラック内部でオーディオファイル１１２０に先行する。

従来の一般的な音楽ＣＤプレーヤに対し、そのオーディオトラックの再生が始まるべきオーディオトラック内の地点を指示するためにオフセット値を使用することが知られている。これは、例えば（図１０には図示されていない）ＣＤの目次において指定されるかもしれない。従って、この実施形態によれば、第１のオーディオトラックのためのオフセット値は、ビデオファイル１１３０および記述ファイル１１４０のためのデータが終わり第１のオーディオトラックのためのオーディオファイル１１２０が始まる、位置１６００であるように指定される（オフセット値がビデオファイル１１３０および記述ファイル１１４０の後の任意の位置にあってもよいことは十分理解されるであろうが）。そうしたものとして、ＣＤ１６１０が従来の一般的な音楽ＣＤプレーヤで使用された場合、第１のオーディオトラックの再生は、対応するオーディオファイル１１２０から始まり、ビデオファイル１１３０および記述ファイル１１４０を（オーディオとして）再生しないであろう。それゆえ、ＣＤ１６１０は、従来の一般的な音楽ＣＤプレーヤにおいて従来の一般的な音楽ＣＤと同様にして使用することができる。しかし、ＣＤ１６１０はまた、（上述した通り）カラオケゲームのための付加的なオーディオファイル１１２０（ならびに関係するビデオファイル１１３０および記述ファイル１１４０）を供給する配布媒体としても使用することができ、ゲームは、そのようなＣＤ１６１０の使用を検出し、オーディオファイル１１２０、ビデオファイル１１３０および記述ファイル１１４０の場所を識別するように構成されている。

一部の従来の一般的な音楽ＣＤプレーヤは、ユーザが第１のオーディオトラックのためのオフセット値に先行する位置から第１のオーディオトラックを再生できるようにさせることが可能である（例えば、第１のオーディオトラックが再生されており、ユーザが第１のオーディオトラックを後方にスキャンした場合）。従って本発明の好ましい実施形態は、ＣＤ１６１０上のビデオファイル１１３０および記述ファイル１１４０のためのデータを、オーディオとして再生された場合に出力オーディオが低音量であるように符号化している。これはＣＤ１６１０にビデオファイル１１３０および記述ファイル１１４０を記憶するために要求されるデータの量を増大させるが、これはビデオファイル１１３０および記述ファイル１１４０のデータがオーディオとして再生された場合にユーザのスピーカが損傷を受けるのを防ぐ。ビデオファイル１１３０および記述ファイル１１４０のこの符号化は、例えば、オーディオファイル１１２０のオーディオサンプルに割り当てられたビットの全部から達成可能なフルで可能なダイナミックレンジに関して出力オーディオのダイナミックレンジを制限するためにオーディオサンプルに割り当てられる最下位のビット（ＬＳＢ）の１つ以上を使用するだけによって達成され得る。ビデオファイル１１３０および記述ファイル１１４０を符号化するために使用されないオーディオサンプルの最上位のビット（ＭＳＢ）の１つ以上は、代わりに他の目的に使用され得ることは十分理解されるであろう。例えば、ＭＳＢが音楽または話といった実際のオーディオ信号を表現するために使用された場合、オーディオトラックのこの区分の再生時に、この音楽または話は、ＭＳＢを使用したために、ＬＳＢとして符号化されたビデオファイル１１３０および記述ファイル１１４０のオーディオとしての再生から生じる少量の雑音を伴い、優勢なオーディオ信号として再生されるであろう。

ビデオファイル１１３０および記述ファイル１１４０は第１のオーディオトラック以外の、またはそれに加えて１つ以上のオーディオトラック内に記憶されることができ、当のオーディオトラックまたはオーディオトラックの各々に適切なオフセット値を保持するＣＤは、従来の一般的な音楽ＣＤプレーヤがビデオファイル１１３０および記述ファイル１１４０を出力オーディオとして再生しないようにビデオファイル１１３０および記述ファイル１１４０を記憶するために使用されることは十分理解されるであろう。

図１０に例示された実施形態はＣＤに関して説明したが、これが（スーパーオーディオＣＤ、音楽ＤＶＤなどといった）他の配布媒体に等しくあてはまることは十分理解されるであろう。この場合、ビデオファイル１１３０および記述ファイル１１４０は、（必ずしも再生順序でオーディオファイル１１２０に先行するというわけではなく）オーディオトラック内のどこにでもオーディオデータとして記憶されることができ、配布媒体は、出力オーディオとして再生されるオーディオトラックの部分および、オーディオデータとして表現されているが出力オーディオとしては再生されない（ビデオファイル１１３０および記述ファイル１１４０に対応する）オーディオトラックの部分を再生装置が確定するために使用し得る情報を記憶している。

ゲームの異なるバージョンは、オーディオ／ビデオファイル１１５０に関する異なるまたは付加的な情報を必要とするかもしれない。この情報は記述ファイル１１４０に記憶されるかもしれない。しかし、ゲームの現在のバージョンがゲームの以前のバージョンのための配布媒体１１００からのオーディオ／ビデオファイル１１５０を利用しようと試みた時に、以前のバージョンは、行われている現在のバージョンの機能の一部のために必要な情報を有していないかもしれない。これは図７に図式的に例示されており、この場合、ゲームの以前のバージョンからの記述ファイル１３００がゲームのその以前のバージョンの配布媒体１１００に記憶された特定のオーディオ／ビデオファイル１１５０に関連する情報を含むのに対し、ゲームの現在の（後の）バージョンからの記述ファイル１３１０はゲームの現在のバージョンの配布媒体１１００に記憶されている異なるオーディオ／ビデオファイル１１５０に関連する情報を含んでいる。

記述ファイル１３１０は、ゲームの以前のバージョン以来導入または変更されたゲームの現在のバージョンの機能のために、記述ファイル１３００とは完全に異なるフォーマットであるかもしれない。あるいは、記述ファイル１３１０は、ゲームの以前のバージョンの機能のための情報を含んでいる（記述ファイル１３００とフォーマットに関して類似の）データ部分１３２０および、ゲームの現在のバージョンの機能のための情報を含んでいるデータ部分１３３０より構成されるかもしれない。

多様なフォーマットが記述ファイル１１４０（１３００および１３１０）に使用され得ることは十分理解されるであろう。しかし好ましい実施形態において、使用されるフォーマットはＸＭＬである。

図８は、アプリケーションソフトウェア１１１０ａおよび１１１０ｂをそれぞれ記憶している２つの配布媒体１１００ａおよび１１００ｂを図式的に例示しており、アプリケーションソフトウェア１１１０ａはゲームの以前のバージョンのためのものであり、アプリケーションソフトウェア１１００ｂはゲームの現在の（後の）バージョンのためのものである。配布媒体１１００ａはｍ個のオーディオ／ビデオファイル１１５０ａおよび対応する記述ファイル１１４０ａを記憶している。記述ファイル１１４０ａは図７の記述ファイル１３００のフォーマットのものである。配布媒体１１００ｂは、ｎ個のオーディオ／ビデオファイル１１５０ｂおよび対応する記述ファイル１１４０ｂを記憶している。記述ファイル１１４０ｂは図７の記述ファイル１３１０のフォーマットのものである。

現在の実施形態によれば、配布媒体１１００ｂはまた、付加的な記述ファイル１４００も記憶している。配布媒体１１００ａに記憶されたオーディオ／ビデオファイル１１５０ａの各々について１つずつ、ｍ個の付加的な記述ファイル１４００が存在する。各々の付加的な記述ファイル１４００は、完全に独立した記述ファイル、すなわち記述ファイル１１４０ｂと同じフォーマットの記述ファイル全体であるかもしれない。あるいは、付加的な記述ファイル１４００は、記述ファイル１１４０ａと組み合わせられた時に、それらが図７に図示の通り（データ部分１３２０を形成する記述ファイル１１４０ａおよびデータ部分１３３０を形成する付加的な記述ファイル１４００により）記述ファイル１３１０を形成するように、必要なデータより構成されるかもしれない。

配布媒体１１００ｂがゲームの複数の以前のバージョンに対応する付加的な記述ファイル１４００を記憶できるはずであることは十分理解されるであろう。また、付加的な記述ファイル１４００が代替的な装置に記憶され得ることも十分理解されるであろう。例えば、ｍ個の個別の付加的な記述ファイル１４００を記憶する代わりに、付加的な記述ファイル１４００は１つの統一された付加的な記述ファイル１４００として記憶されるかもしれない。

従って、現在の実施形態によれば、ゲームのバージョンの配布媒体１１００は、そのバージョンに関係するオーディオ／ビデオファイル１１５０のための記述ファイル１１４０だけでなく、以前のバージョンのオーディオ／ビデオファイル１１５０のための付加的な記述ファイル１４００も記憶することができる。現在のゲームバージョンがゲームコンソールによってロードされる時に、（サイズが小さい）記述ファイル１１４０および１４００は、ゲームコンソールのメモリにロードされるかもしれない。以前のバージョンのオーディオ／ビデオファイル１１５０が選択された場合、適切な最新の記述情報がこの以前のバージョンの配布媒体１１００に記憶された記述情報の代わりにその後使用されるかもしれない。

本発明の好ましい実施形態において、配布媒体１１００は、例えばＸＭＬファイルであるとしてよい目次を記憶している。この目次は、ゲームの現在のバージョン（すなわち配布媒体１１００に対応したバージョン）のための項目および、ゲームの他のバージョンに対応した０以上の項目を有する。目次における項目の各々は、対応するゲームバージョンに適切である配布媒体１１００上の特定のデータの識別を備える。例えば、目次における項目は、（ｉ）どのオーディオファイル１１２０および／またはビデオファイル１１３０が対応するゲームバージョンに適切であるか、（ｉｉ）どの記述ファイル１１４０（および／または付加的な記述ファイル１４００）が対応するゲームバージョンに適切であるか、そして（ｉｉｉ）記述ファイル１１４０（および／または付加的な記述ファイル１４００）のどの部分（１３２０、１３３０）が対応するゲームバージョンに適切であるか、を識別することができる。

目次の項目がインクリメンタル情報を含み得る、すなわち、項目は対応するゲームバージョンに適切であるが目次の別の項目に対応する以前のゲームバージョンには適切ではない配布媒体１１００上の特定のデータを識別し得ることは十分理解されるであろう。

自己自身のゲームバージョンを認識しているソフトウェアアプリケーション１１１０は、配布媒体１１００上のどのファイル／データを使用するべきかを決定するために配布媒体１１００上の目次を使用する。好ましい実施形態において、これはゲームの初期化時に図６のステップＳ１２００において行われる。好ましい実施形態において、これはまた交替配布媒体１１００がゲームコンソールに挿入された後に図６のステップＳ１２１６で行われる。しかし、ステップＳ１２１６では、新しく挿入された配布媒体１１００の目次は、現在行われているゲームのバージョンに適切な項目を有していないかもしれない、すなわち、配布媒体に記憶されているデータが現在行われているゲームのバージョンによって適切ではない（処理できない）ことを指示する。これが起きた場合、ソフトウェアアプリケーションはこの趣旨でメッセージをユーザに対し表示させ、ユーザに現在行われているゲームのバージョンに適切な配布媒体１１００を挿入するように促す。

オーディオ／ビデオファイル１１５０のフォーマットが時間とともに変化し得ることは十分理解されるであろう。これは例えば、（ｉ）オーディオおよび／またはビデオデータに使用されるデータ圧縮アルゴリズムを変える、（ｉｉ）オーディオデータのサンプリング周波数またはビデオデータの空間解像度を変える、および／または（ｉｉｉ）（単層ＤＶＤから二層ＤＶＤに移行するといった）配布媒体フォーマットを変更すること、に起因するかもしれない。この結果は、ゲームの１つのバージョンのためのゲームアプリケーションソフトウェア１１１０が、ゲームの異なるバージョンのための配布媒体１１００に記憶されたオーディオ／ビデオファイル１１５０を解釈することができないかもしれないということである。

従って、現在の実施形態はアプリケーションソフトウェア１１１０をモジュール形態で構成し、それにより（データ圧縮解除アルゴリズムといった）オーディオ／ビデオファイル１１５０を理解しアクセスするための機能性が１つ以上の別個のモジュールに含まれる。これらのモジュールは、例えばＤＬＬとすることができ、配布媒体はオーディオデータ圧縮解除ＤＬＬおよびビデオデータ圧縮解除ＤＬＬを記憶している。

ゲームの異なるバージョン間の互換性を保証するこのモジュール構成（および特にＤＬＬ）の使用は、図９のフローチャートにおいて図式的に例示されている。

ステップＳ１５００で、ゲームコンソールは、ゲームバージョンＡのための配布媒体１１００に記憶されたソフトウェアアプリケーション１１１０により初期化される。

ステップＳ１５１０で、遊技者は、現在ゲームコンソールにロードされたゲームバージョンＡのための配布媒体１１００を異なるゲームバージョンＢのための配布媒体１１００と入れ替える。ステップＳ１５２０で、遊技者は（ゲームバージョンＢのための）現在ロードされた配布媒体１１００に記憶されているオーディオ／ビデオファイル１１５０を選択する。これらの２つのステップＳｌ５１０およびＳ１５２０は図６に例示された方法に従う。

ステップＳ１５３０で、ゲームコンソールは、ゲームコンソールによって実行されているアプリケーションソフトウェア１１１０からの指示を受けて、選択されたオーディオ／ビデオファイル１１５０のフォーマットを断定する。

ステップＳ１５４０で、選択されたオーディオ／ビデオファイル１１５０のフォーマットがゲームコンソールによって実行されているアプリケーションソフトウェア１１１０によりサポートされていると断定された場合、処理はステップＳ１５５０に続き、そこでゲームは選択されたオーディオ／ビデオファイル１１５０を用いて行われる。

しかし、ステップＳ１５４０で、選択されたオーディオ／ビデオファイル１１５０のフォーマットがゲームコンソールによって実行されているアプリケーションソフトウェア１１１０によりサポートされていないと断定された場合、処理はステップＳ１５６０に続き、そこで実行されているアプリケーションソフトウェア１１１０は（ゲームバージョンＡのための配布媒体１１００からメモリにロードされたものの代わりに）ゲームバージョンＢのための配布媒体１１００に記憶されたモジュール（ＤＬＬ）を利用し、それにより選択されたオーディオ／ビデオファイル１１５０のフォーマットはサポートされることができる。これは、ＤＬＬといったモジュラーソフトウェアをロードし使用するための周知の方法のいずれかで実行され得る。

さらに、現在の実施形態によれば、ゲームを行っている遊技者のオーディオ入力をメモリカード７２０といった記憶媒体上に記録することが可能である。その後、記録されたオーディオを再生することが可能である。遊技者が一緒に合わせて歌っていた対応するオーディオ／ビデオファイル１１５０と連携してこの記録されたオーディオを再生することが普通である。しかし、このオーディオ／ビデオファイル１１５０がゲームコンソールに現在ロードされていない、それゆえアクセスできない配布媒体１１００に記憶されているかもしれないことは十分理解されるであろう。従って、現在の実施形態は、記録されたオーディオと一緒に、正しいオーディオ／ビデオファイル１１５０が遊技者から記録されたオーディオとともに再生されるためにどの配布媒体１１００またはゲームのどのバージョンが必要であるかを記述している情報をメモリカード７２０に記憶する。この情報は、例えば、ゲームのバージョン番号または、どの配布媒体１１００が必要かを記述しているテキストのデータであるかもしれない。それは遊技者のための視覚プロンプトとして使用することができる。

上述した本発明の実施形態が、少なくとも部分的に、ソフトウェア制御データ処理装置を用いて実現される限り、当該ソフトウェア制御を提供するコンピュータプログラム、当該コンピュータプログラムが記憶される記憶媒体および、当該コンピュータプログラムが伝送される伝送媒体が本発明の態様として考えられることは十分理解されるであろう。

プレイステーション２の全体的なシステムアーキテクチャを図式的に例示している。 エモーションエンジンのアーキテクチャを図式的に例示している。 グラフィックスシンセサイザの機器構成を図式的に例示している。 オーディオ／ビデオファイルを選択するカルーセル方法を図式的に例示している。 配布媒体を図式的に例示している。 オーディオ／ビデオファイルを選択することに伴うステップを例示している概略フローチャートである。 記述ファイルを図式的に例示している。 ２つの配布媒体を図式的に例示している。 ソフトウェアモジュールの使用を例示している概略フローチャートである。 本発明の実施形態に従った配布媒体でのファイルの記憶を図式的に例示している。

符号の説明

１０ システムユニット
１００ エモーションエンジン
２００ グラフィックスシンセサイザ
３００ サウンドプロセッサユニット
３０５ ディスプレイ
３１０ スピーカ装置
３９０ ハードディスクドライブ（ＨＤＤ）
４００ 読出し専用メモリ（ＲＯＭ）
４５０ コンパクトディスク（ＣＤ）／ディジタル多用途ディスク（ＤＶＤ）読取り装置
５００ ラムバスダイナミックランダムアクセスメモリ（ＲＤＲＡＭ）ユニット
７００ 入出力プロセッサ（ＩＯＰ）
７０５、７１０ ポート
７１５ ＵＳＢポート
７２０ ＲＡＭメモリカード
７２５ ハンドヘルド型ゲームコントローラ
７３０ マイクロホン
８０５ ネットワークアダプタ

Claims (38)

1. 取外し可能記憶媒体がそれぞれのプログラムおよび関係するデータを記憶しているデータ処理装置であって、装置は、
   取外し可能記憶媒体読取り装置と、
   読取り装置によって現在読取り可能な第１の取外し可能記憶媒体からのプログラムを、その第１の取外し可能記憶媒体に記憶されたデータを用いて実行するための手段とを備えており、実行手段および／またはプログラムは、プログラムの実行の範囲内の少なくとも所定の時点で、第１の取外し可能記憶媒体が読取り装置から取外されることができ、第２の異なる取外し可能記憶媒体が読取り装置と関係づけられることができ、それによりプログラムの実行は第２の取外し可能記憶媒体から読取られたデータを用いて続行することができるように構成されている、データ処理装置。
2. 装置はゲーム機であり、
   プログラムはゲームプログラムであり、
   データはゲームデータである、請求項１に記載の装置。
3. プログラムは音楽ゲームプログラムであり、
   データは歌のデータである、請求項２に記載の装置。
4. 取外し可能記憶媒体は読出し専用記憶媒体である、請求項１〜３のいずれか１項に記載の装置。
5. 取外し可能記憶媒体は光ディスクである、請求項４に記載の装置。
6. 取外し可能記憶媒体に記憶されたデータの異なる構成要素のユーザ選択を可能にするためにユーザメニューを生成するための手段と、
   読取り装置と関係づけられている第２の取外し可能記憶媒体に応答してユーザメニューを更新するための手段とを備えており、ユーザメニューは第２の取外し可能記憶媒体に記憶されたデータに従って更新される、上記請求項のいずれか１項に記載の装置。
7. 更新されたユーザメニューはユーザが第２の取外し可能記憶媒体に記憶されたデータの異なる構成要素を選択することを可能にする、請求項６に記載の装置。
8. 更新されたユーザメニューはユーザが第１の取外し可能記憶媒体および第２の取外し可能記憶媒体に記憶されたデータの異なる構成要素を選択することを可能にする、請求項６に記載の装置。
9. 現在アクセスされた第２の取外し可能記憶媒体に記憶されていないデータ構成要素のユーザ選択を検出するための手段と、
   そのような検出に応答し、別の取外し可能記憶媒体を読取り装置と関係づけるようにユーザに促すためにメッセージを生成するための手段とを備える、請求項８に記載の装置。
10. ユーザメニューの生成は現在の取外し可能記憶媒体が交替され得る所定の時点を表す、請求項６〜９のいずれかに記載の装置。
11. 取外し可能記憶媒体に記憶されたデータはその取外し可能記憶媒体に記憶された関係する記述データを有する、上記請求項のいずれか１項に記載の装置。
12. 取外し可能記憶媒体のうちの１つは他の取外し可能記憶媒体に記憶されたデータに関連する記述データを記憶している、請求項１１に記載の装置。
13. 読取り装置と関係づけられた取外し可能記憶媒体に記憶された１つ以上のデータ部分識別子から、各データ部分識別子はプログラムの対応するバージョンに従って処理され得るその取外し可能記憶媒体に記憶されたデータの部分を識別するものであり、装置によって実行されているプログラムのバージョンに従って処理され得るその取外し可能記憶媒体に記憶されたデータの部分を決定するために動作可能な手段を備える、上記請求項のいずれか１項に記載の装置。
14. 読取り装置と関係づけられた取外し可能記憶媒体に記憶されたデータのいずれの部分も装置によって実行されているプログラムに従って処理され得ないという決定に応答し、別の取外し可能記憶媒体を読取り装置と関係づけるようにユーザに促すためにメッセージを生成するための手段を備える、請求項１３に記載の装置。
15. 取外し可能記憶媒体に記憶されたデータに関連するユーザデータを記憶するためのメモリと、
    読取り装置と現在関係する取外し可能記憶媒体に記憶されていないデータに関連するユーザデータのユーザアクセスを検出するための手段と、
    そのような検出に応答し、別の取外し可能記憶媒体を読取り装置と関係づけるようにユーザに促すためにメッセージを生成するための手段とを備える、上記請求項のいずれか１項に記載の装置。
16. いずれの取外し可能記憶媒体も読取り装置によってアクセスできない間に少なくともプログラムを記憶するためのメモリを備える、上記請求項のいずれか１項に記載の装置。
17. プログラムは、取外し可能記憶媒体に記憶されたデータを解釈するためのプログラムコードからなる１つ以上のプログラムモジュールより構成される、上記請求項のいずれか１項に記載の装置。
18. プログラムモジュールはダイナミックリンクライブラリである、請求項１７に記載の装置。
19. 取外し可能記憶媒体がそれぞれのプログラムおよび関係するデータを記憶しているシステムに関連するデータ処理方法であって、取外し可能記憶媒体は取外し可能記憶媒体読取り装置によって読取られ、方法は、
    読取り装置によって現在読取り可能である第１の取外し可能記憶媒体からのプログラムを、その第１の取外し可能記憶媒体に記憶されたデータを用いて、プログラムの実行の範囲内の少なくとも所定の時点で、第１の取外し可能記憶媒体が読取り装置から取外されることができ、第２の異なる取外し可能記憶媒体が読取り装置と関係づけられることができ、それによりプログラムの実行は第２の取外し可能記憶媒体から読取られたデータを用いて続行することができるように実行するステップを含む、データ処理方法。
20. 記憶媒体が再生装置と関係づけられた時に出力オーディオ信号として再生可能なデータを保持する記憶媒体であって、データはオーディオデータおよび関係する記述データを含み、記憶媒体は再生装置によって出力オーディオ信号として再生されるデータの所望の部分を識別する再生情報を保持しており、識別された部分は記述データを含まない、記憶媒体。
21. データは１つ以上のオーディオトラックとして構成されており、オーディオトラック内部にデータの再生順序が存在しており、オーディオトラックはオーディオデータを含んでおり、オーディオトラックのうちの少なくとも１つは、そのオーディオトラックの再生順序において、そのオーディオトラックのオーディオデータに先行する記述データを付加的に含んでおり、再生情報は再生装置によるそのオーディオトラックの再生が始まるはずであるそのオーディオトラックの再生順序における所望の位置を識別しており、所望の位置はそのオーディオトラックの記述データの後の位置である、請求項２０に記載の記憶媒体。
22. 複数のオーディオトラックおよび、オーディオトラックの再生順序が存在し、オーディオトラックの再生順序における最初のオーディオトラックだけが記述データを含む、請求項２１に記載の記憶媒体。
23. オーディオデータは所定の潜在的ダイナミックレンジを有しており、記述データはオーディオデータよりも小さいダイナミックレンジを有する、請求項２０〜２２のいずれか１項に記載の記憶媒体。
24. 記述データはゲームデータより構成される、請求項２０〜２３のいずれか１項に記載の記憶媒体。
25. 記述データはまたビデオデータより構成される、請求項２４に記載の記憶媒体。
26. 記憶媒体はコンパクトディスクである、請求項２０〜２５のいずれか１項に記載の記憶媒体。
27. プログラムおよび関係するデータが第１の取外し可能記憶媒体に記憶されているデータ処理装置であって、データはオーディオデータおよびオーディオデータと関係する記述データより構成され、装置は、
    記憶媒体読取り装置と、
    第１の記憶媒体が読取り装置と関係づけられた時に第１の記憶媒体に記憶されたプログラムを、その第１の記憶媒体に記憶されたデータを用いて実行するための手段とを備えており、実行手段および／またはプログラムは、プログラムの実行の範囲内の少なくとも所定の時点で、第１の記憶媒体が読取り装置から取外されることができ、請求項２０〜２６のいずれか１項に記載の第２の記憶媒体が読取り装置と関係づけられることができ、それによりプログラムの実行は第２の記憶媒体から読取られたデータを用いて続行することができるように構成されている、データ処理装置。
28. プログラムおよび関係するデータが記憶媒体読取り装置によって読取られる第１の取外し可能記憶媒体に記憶されているシステムに関連するデータ処理方法であって、データはオーディオデータおよびオーディオデータと関係する記述データを含み、方法は、
    第１の記憶媒体が読取り装置と関係づけられた時に第１の記憶媒体に記憶されたプログラムを、その第１の記憶媒体に記憶されたデータを用いて、プログラムの実行の範囲内の少なくとも所定の時点で、第１の記憶媒体が読取り装置から取外されることができ、請求項２０〜２６のいずれか１項に記載の第２の記憶媒体が読取り装置と関係づけられることができ、それによりプログラムの実行は第２の記憶媒体から読取られたデータを用いて続行することができるように実行するステップを含む、データ処理方法。
29. 請求項１９または２８に記載の方法を実行するためのコンピュータソフトウェア。
30. 請求項２９に記載のコンピュータソフトウェアを保持する記憶媒体。
31. 媒体はまたプログラムと関係するデータも保持する、請求項３０に記載の媒体。
32. 媒体はまた記憶されたデータと関係する記述データも保持する、請求項３１に記載の媒体。
33. オーディオ内容を提供する方法であって、前記方法は、
    オーディオ内容、記述データおよび再生情報を保持する記憶媒体を提供するステップを含み、
    前記記述データはダミーのオーディオデータとして記憶されており、
    前記再生情報は前記記述データが出力オーディオ信号として再生されてはならないことをオーディオ再生装置に指示する、方法。
34. 前記記憶媒体はコンパクトディスクであり、
    前記再生装置はコンパクトディスク再生装置である、請求項３３に記載の方法。
35. 前記記述データは前記オーディオ内容に関連するゲームデータより構成される、請求項３４に記載の方法。
36. オーディオ内容を提供する方法であって、前記方法は、
    オーディオ内容および記述データを保持する記憶媒体を提供するステップを含み、前記記述データは、オーディオ再生装置が前記記述データをオーディオ出力信号として再生することを禁止されるがゲーム機は前記記述データを読取ることができるように、ダミーのオーディオデータとして記憶されている、方法。
37. 前記記憶媒体はコンパクトディスクであり、
    前記再生装置はコンパクトディスク再生装置である、請求項３６に記載の方法。
38. 前記記述データは前記オーディオ内容に関連するゲームデータより構成される、請求項３７に記載の方法。

Images