(57)【要約】【課題】ユーザおよび開発者が、ゲーミングコンソール、マルチメディアコンソール、またはゲーミングコンソールでもマルチメディアコンソールでもあるコンソールに接続されている、いくつかの異なるタイプのローカルデバイスおよびリモートデバイスにデータを記憶できるようにするシステムおよび方法を提供すること。【解決手段】使用可能なストレージデバイスの範囲が、ストレージパフォーマンス（例えば、レイテンシ）における明らかな不一致を回避するように対処される成果を生み出す。データを読み取り書き込む一貫性のある方法が、エンドユーザおよび開発者が様々なデバイスに固有の制約および制限について心配する必要がないように実現される。【選択図】図１
2006134300.tif 000002
【特許請求の範囲】
【請求項１】
ゲーミングコンソールに通信できるように接続された複数の様々なストレージデバイスのうちの１つからデータを読み取り／それにデータを書き込む方法であって、
ストレージデバイスを検出し列挙すること、
データを読み取り／書き込むように要求するイベントを検出すること、
検出されたストレージデバイスを表示するユーザインターフェースを提示すること、
前記データが読み取られ／書き込まれるべき特定のストレージデバイスを選択する入力を受け取ること、および、
受け取られた入力に従って前記データを読み取り／書き込むこと
を含むことを特徴とする方法。
【請求項２】
前記ストレージデバイスを検出し列挙することは、前記イベントごとにストレージデバイスの挿入および削除を追跡することをさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記ストレージデバイスに対してデータを読み取り／書き込むように要求するアプリケーションに関連した識別情報について前記ストレージデバイスを検索することをさらに含むことを特徴とする請求項１に記載の方法。
【請求項４】
ＡＰＩを公開して一般的なシステムセーブユーザインターフェースまたはアプリケーション特有のセーブユーザインターフェースを提供することをさらに含むことを特徴とする請求項１に記載の方法。
【請求項５】
読取りオペレーションが実施される場合に、
第１のＡＰＩを呼び出すこと、
前記一般的なシステムセーブダイアログを提供すること、
前記第１のＡＰＩにデータを渡すこと、および、
前記ゲーミングコンソールに制御を渡して、前記読取りオペレーションを実施すること
をさらに含むことを特徴とする請求項４に記載の方法。
【請求項６】
読取りオペレーションが実施され、前記アプリケーションが読み取るべきデータのロケーションを知っている場合に、
データファイルおよび名前にポインタを渡すこと、
前記データファイルに関連するストレージロケーションをマウントすること、
前記データファイルを読み取ること、および、
前記データファイルから前記アプリケーションへとデータを渡すこと
をさらに含むことを特徴とする請求項４に記載の方法。
【請求項７】
読取りオペレーションが実施される場合に、
第２のＡＰＩを呼び出して、前記ストレージデバイスを検出し列挙することを実施すること、
前記アプリケーション特有のセーブユーザインターフェースを提供すること、
第３のＡＰＩを呼び出して、要求されたストレージデバイスをマウントし、前記要求されたストレージデバイスから前記データを読み取ること、および、
前記読取りオペレーションが完了したことを前記ゲーミングコンソールに通知すること
をさらに含むことを特徴とする請求項４に記載の方法。
【請求項８】
書込みオペレーションが実施される場合に、
第４のＡＰＩを呼び出すこと、
前記一般的なシステムセーブダイアログを提供すること、
前記第４のＡＰＩにデータを渡すこと、および、
前記ゲーミングコンソールに制御を渡して、前記書込みオペレーションを実施すること
をさらに含むことを特徴とする請求項４に記載の方法。
【請求項９】
書込みオペレーションが実施され、前記アプリケーションが書き込むべきデータのロケーションを知っている場合に、
データファイルおよび名前にポインタを渡すこと、
前記データファイルに関連するストレージロケーションをマウントすること、
前記データファイルを書き込むステップと、および、
前記アプリケーションから前記データファイルへとデータを渡すこと
をさらに含むことを特徴とする請求項４に記載の方法。
【請求項１０】
書込みオペレーションが実施される場合に、
第５のＡＰＩを呼び出して、前記ストレージデバイスを検出し列挙することを実施すること、
前記アプリケーション特有のセーブユーザインターフェースを提供すること、
第６のＡＰＩを呼び出して、要求されたストレージデバイスをマウントし、前記要求されたストレージデバイスに前記データを書き込むこと、および、
前記書込みオペレーションが完了したことを前記ゲーミングコンソールに通知すること
をさらに含むことを特徴とする請求項４に記載の方法。
【請求項１１】
ゲーミングコンソールに通信できるように接続された複数の様々なストレージデバイスのうちの１つからデータを読み取り／それにデータを書き込むためのコンピュータ実行可能命令をその上に記憶しているコンピュータ読取り可能記憶媒体であって、前記命令は、
ストレージデバイスを検出し列挙するステップと、
データを読み取り／書き込むように要求するイベントを検出するステップと、
検出されたストレージデバイスを表示するユーザインターフェースを提示するステップと、
前記データが読み取られ／書き込まれるべき特定のストレージデバイスを選択する入力を受け取るステップと、
受け取られた入力に従って前記データを読み取り／書き込むステップと
を実施することを特徴とするコンピュータ読取り可能記憶媒体。
【請求項１２】
前記ストレージデバイスを検出し列挙する前記ステップは、前記イベントごとにストレージデバイスの挿入および削除を追跡するステップのための命令をさらに含むことを特徴とする請求項１１に記載のコンピュータ読取り可能記憶媒体。
【請求項１３】
前記ストレージデバイスに対してデータを読み取り／書き込むように要求するアプリケーションに関連した識別情報について前記ストレージデバイスを検索するステップのための命令をさらに含むことを特徴とする請求項１１に記載のコンピュータ読取り可能記憶媒体。
【請求項１４】
ＡＰＩを公開して一般的なシステムセーブユーザインターフェースまたはアプリケーション特有のセーブユーザインターフェースを提供するステップのための命令をさらに含むことを特徴とする請求項１１に記載のコンピュータ読取り可能記憶媒体。
【請求項１５】
読取りオペレーションが実施される場合に、
第１のＡＰＩを呼び出すステップと、
前記一般的なシステムセーブダイアログを提供するステップと、
前記第１のＡＰＩにデータを渡すステップと、
前記ゲーミングコンソールに制御を渡して、前記読取りオペレーションを実施するステップと
のための命令をさらに含むことを特徴とする請求項１４に記載のコンピュータ読取り可能記憶媒体。
【請求項１６】
読取りオペレーションが実施され、前記アプリケーションが読み取るべきデータのロケーションを知っている場合に、
データファイルおよび名前にポインタを渡すステップと、
前記データファイルに関連するストレージロケーションをマウントするステップと、
前記データファイルを読み取るステップと、
前記データファイルから前記アプリケーションへとデータを渡すステップと
のための命令をさらに含むことを特徴とする請求項１４に記載のコンピュータ読取り可能記憶媒体。
【請求項１７】
読取りオペレーションが実施される場合に、
第２のＡＰＩを呼び出して、前記ストレージデバイスを検出し列挙する前記ステップを実施するステップと、
前記アプリケーション特有のセーブユーザインターフェースを提供するステップと、
第３のＡＰＩを呼び出して、要求されたストレージデバイスをマウントし、前記要求されたストレージデバイスから前記データを読み取るステップと、
前記読取りオペレーションが完了したことを前記ゲーミングコンソールに通知するステップと
のための命令をさらに含むことを特徴とする請求項１４に記載のコンピュータ読取り可能記憶媒体。
【請求項１８】
書込みオペレーションが実施される場合に、
第４のＡＰＩを呼び出すステップと、
前記一般的なシステムセーブダイアログを提供するステップと、
前記第４のＡＰＩにデータを渡すステップと、
前記ゲーミングコンソールに制御を渡して、前記書込みオペレーションを実施するステップと
のための命令をさらに含むことを特徴とする請求項１４に記載のコンピュータ読取り可能記憶媒体。
【請求項１９】
書込みオペレーションが実施され、前記アプリケーションが書き込むべきデータのロケーションを知っている場合に、
データファイルおよび名前にポインタを渡すステップと、
前記データファイルに関連するストレージロケーションをマウントするステップと、
前記データファイルを書き込むステップと、
前記アプリケーションから前記データファイルへとデータを渡すステップと
のための命令をさらに含むことを特徴とする請求項１４に記載のコンピュータ読取り可能記憶媒体。
【請求項２０】
書込みオペレーションが実施される場合に、
第５のＡＰＩを呼び出して、前記ストレージデバイスを検出し列挙する前記ステップを実施するステップと、
前記アプリケーション特有のセーブユーザインターフェースを提供するステップと、
第６のＡＰＩを呼び出して、要求されたストレージデバイスをマウントし、前記要求されたストレージデバイスに前記データを書き込むステップと、
前記書込みオペレーションが完了したことを前記ゲーミングコンソールに通知するステップと
のための命令をさらに含むことを特徴とする請求項１４に記載のコンピュータ読取り可能記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にマルチメディアデバイスおよびゲーミングコンソールの分野に関する。詳細には、本発明は、複数の異なるストレージデバイスからデータを読み取り書き込むための単一のユーザインターフェースを実現する、ゲーム機におけるシステムアーキテクチャを対象としている。
【背景技術】
【０００２】
従来のマルチメディアシステムおよびゲーミングコンソールにおいては、データを保存し抽出することができる非常に多くのオプションが、開発者にとっての悩みである。特に、ストレージデバイスのレイテンシおよび持続性における違いがあるので、開発者はしばしば、異なるプロセス（および時には異なるユーザインターフェース）を実装して異なるストレージデバイスにアクセスする必要がある。これにより、混乱させるような、また一貫性のないユーザ体験がもたらされる。
【０００３】
以上に加えて、ストレージデバイスがシステムに追加され取り除かれるので、ストレージデバイスの存在または非存在、ならびに持続性および非持続性についてアプリケーションおよびユーザに通知することは難しい。さらに、従来のマルチメディアシステムでは、将来開発され得るストレージデバイスを追加するための用意がされていない。したがって、新しいストレージオプションは追加することができず、これにより、ユーザが、好ましいロケーションへデータを記憶し、そこからデータを抽出することができなくなってしまうこともある。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
したがって、異なるストレージデバイスにデータをセーブし、そこからデータを読み取るときに、一貫性のあるユーザ体験をもたらすためのシステムおよび方法が必要である。また、ストレージデバイスの存在を判定し、ストレージデバイスの詳細に基づいてデータをセーブするための推定時間を決定するためのシステムも必要である。本発明は、かかる解決方法を提供している。
【課題を解決するための手段】
【０００５】
本発明により、アプリケーションユーザは、マルチメディア／ゲーミングコンソールに接続された様々なストレージデバイス（例えば、ＨＤＤ（hard disk drive）、ＭＵ（Memory Unit）、ネットワークＰＣ、リモートサーバベースのストレージ）にデータを記憶することができるようになる。ストレージデバイスＵＩ（User Interface）を使用して、ユーザは、適切なストレージデバイスを簡単に選択して、データを記憶することができる。
【０００６】
本発明によれば、通信できるようにマルチメディアコンソールに接続された複数の様々なストレージデバイスのうちの１つからデータを読み取り／それにデータを書き込む方法が提供される。この方法は、ストレージデバイスを検出し列挙すること、データを読み取り／書き込むように要求するイベントを検出すること、検出されたストレージデバイスを表示するユーザインターフェースを提示すること、データを読み取り／書き込む特定のストレージデバイスを選択する入力を受け取ること、および受け取った入力に従ってデータを読み取り／書き込むことを含んでいる。
【０００７】
この方法により、アプリケーションは、アプリケーションが探しているファイルのタイプを単に知ることにより、特定のファイルがどこに存在するか／特定のファイルが存在するかどうかを見出すことができるようになる。例えば、ユーザは、アプリケーション／ゲームが直接の知識をもたないデバイス上に「セーブゲーム（save game）」を記憶することができる。アプリケーション／ゲームが開始されるとき、アプリケーション／ゲームは、すべての使用可能なストレージデバイス上の、ユーザについてのすべてのセーブ済みのゲームを見つけるように、ストレージサブシステムに要求することができる。次いで、ファイルがどのデバイス上に存在するかを特に知ることなく、データは、アプリケーション／ゲームに読み込まれる。
【０００８】
本発明の特徴によれば、ストレージデバイスを検出し列挙することは、読取り／書込みイベントごとにストレージデバイスの挿入および除去を追跡することを含むこともできる。ストレージデバイスは、ストレージデバイスからデータを読み取り／それにデータを書き込むことを要求するアプリケーションに関連した識別情報（例えば、タイトルＩＤ）を検索することができる。
【０００９】
１組のＡＰＩを公開して、一般的なシステムセーブユーザインターフェース（例えば、シンプル読取り／書込み（simple read/write））、またはアプリケーション特有のコンテンツ列挙インターフェース（例えば、フレキシブル読取り／書込み（flexible read/write））を実現することができる。サイレント読取り／書込み（silent read/write）は、アプリケーションに知られているデータについて実現することができ、ここでは、ユーザ介入（例えば、チェックポイントセーブ）なしにデータが読み取られ／書き込まれる。
【００１０】
本発明の追加の特徴および利点は、添付図面を参照して進められる例示の実施形態についての以下の詳細な説明から明らかになろう。
【００１１】
以上の概要、ならびに好ましい実施形態の以下の詳細な説明は、添付の図面を併せ読むと、より良く理解される。本発明を例示する目的で、図面中に本発明の例示の構成が示されているが、本発明は、開示される特定の方法および手段だけに限定されるものではない。
【発明を実施するための最良の形態】
【００１２】
図１は、本発明のある種の態様を実装することができるマルチメディアコンソール１００の機能コンポーネントを示している。マルチメディアコンソール１００は、レベル１キャッシュ１０２、レベル２キャッシュ１０４、およびフラッシュＲＯＭ（Read Only Memory）１０６を有するＣＰＵ（central processing unit）１０１を有する。レベル１キャッシュ１０２およびレベル２キャッシュ１０４は、一時的にデータを記憶し、したがってメモリアクセスサイクル数を低減させ、それによって処理速度およびスループットを改善している。複数のコアを、したがって追加のレベル１キャッシュ１０２およびレベル２キャッシュ１０４を有するＣＰＵ１０１を提供することもできる。フラッシュＲＯＭ１０６は、マルチメディアコンソール１００の電源が投入されるときに起動処理の初期フェーズ中にロードされる実行可能コードを記憶することができる。
【００１３】
ＧＰＵ（graphics processing unit）１０８およびビデオエンコーダ／ビデオコーデック（コーダ／デコーダ）１１４は、高速で高分解能のグラフィック処理についてのビデオ処理パイプラインを形成する。データは、グラフィック処理ユニット１０８からビデオエンコーダ／ビデオコーデック１１４へとバスを経由して搬送される。このビデオ処理パイプラインは、テレビジョンまたはその他のディスプレイに伝送するためにＡ／Ｖ（オーディオ／ビデオ）ポート１４０へとデータを出力する。メモリコントローラ１１０は、ＧＰＵ１０８に接続されて、それだけには限定されないが、ＲＡＭ（random access memory）など様々なタイプのメモリ１１２に対してプロセッサがアクセスすることを助ける。
【００１４】
マルチメディアコンソール１００は、モジュール１１８上に実装されることが好ましい入出力コントローラ１２０、システム管理コントローラ１２２、オーディオ処理ユニット１２３、ネットワークインターフェース１２４、第１のＵＳＢホストコントローラ１２６、第２のＵＳＢコントローラ１２８、およびフロントパネル入出力サブアセンブリ１３０を含んでいる。ＵＳＢコントローラ１２６および１２８は、ペリフェラルコントローラ１４２（１）〜１４２（２）、無線アダプタ１４８、および外部メモリデバイス１４６（例えば、フラッシュメモリ、外部ＣＤ／ＤＶＤ  ＲＯＭドライブ、取り外し可能記憶媒体など）のためのホストとしての役割を果たす。ネットワークインターフェース１２４および／または無線アダプタ１４８は、ネットワーク（例えば、インターネット、ホームネットワークなど）へのアクセスを実現し、イーサネット（登録商標）カード（Ethernet（登録商標）card）、モデム、ブルートゥースモジュール（Bluetooth module）、ケーブルモデムなどを含めて多種多様な様々な有線または無線のインターフェースコンポーネントのうちのどれでもよい。
【００１５】
システムメモリ１４３は、起動処理中にロードされるアプリケーションデータを記憶するために設けられる。メディアドライブ１４４が設けられ、これは、ＤＶＤ／ＣＤドライブ、ハードドライブ、またはその他の取り外し可能メディアドライブなどを含むことができる。メディアドライブ１４４は、マルチメディアコンソール１００の内部にあってもよく、また外部にあってもよい。アプリケーションデータは、マルチメディアコンソール１００によって実行または再生などをするためにメディアドライブ１４４を介してアクセスすることができる。メディアドライブ１４４は、シリアルＡＴＡバスや他の高速接続（例えば、ＩＥＥＥ１３９４）などのバスを経由して入出力コントローラ１２０に接続される。
【００１６】
システム管理コントローラ１２２は、マルチメディアコンソール１００の可用性を保証することに関連した様々なサービス機能を提供する。オーディオ処理ユニット１２３およびオーディオコーデック１３２は、高い忠実度とステレオ処理に対応するオーディオ処理パイプラインを形成する。オーディオデータは、通信リンクを介してオーディオ処理ユニット１２３とオーディオコーデック１３２との間で搬送される。オーディオ処理パイプラインは、外部のオーディオプレーヤまたはオーディオ機能を有するデバイスによって再現するためにＡ／Ｖポート１４０に対してデータを出力する。
【００１７】
フロントパネル入出力サブアセンブリ１３０は、パワーボタン１５０および取出しボタン１５２、ならびにマルチメディアコンソール１００の外部表面上に見えるようにした任意のＬＥＤ（light emitting diode 発光ダイオード）またはその他のインジケータの機能をサポートする。システム電源モジュール１３６は、マルチメディアコンソール１００のこれらのコンポーネントに対して電力を供給する。ファン１３８は、マルチメディアコンソール１００内の回路を冷却する。
【００１８】
マルチメディアコンソール１００内のＣＰＵ１０１、ＧＰＵ１０８、メモリコントローラ１１０、およびその他の様々なコンポーネントは、シリアルバスおよびパラレルバス、メモリバス、ペリフェラルバス、ならびに様々なバスアーキテクチャのうちのどれかを使用したプロセッサバスまたはローカルバスを含む、１つまたは複数のバスを介して相互接続される。実施例として、かかるアーキテクチャは、ＰＣＩ（Peripheral Component Interconnect ペリフェラルコンポーネント相互接続）バス、ＰＣＩ−エクスプレス（PCI-Express）バスなどを含むことができる。
【００１９】
マルチメディアコンソール１００の電源が投入されると、アプリケーションデータは、システムメモリ１４３からメモリ１１２および／またはキャッシュ１０２、１０４へとロードされ、ＣＰＵ１０１上で実行される。アプリケーションは、マルチメディアコンソール１００上で使用可能な異なるメディアタイプへとナビゲートする際に、一貫性のあるユーザ体験をもたらすグラフィックユーザインターフェースを提示することができる。作動中には、メディアドライブ１４４内に含まれるアプリケーションおよび／またはその他のメディアは、起動され、またはメディアドライブ１４４から再生され、マルチメディアコンソール１００に対する追加の機能を提供することができる。
【００２０】
マルチメディアコンソール１００は、テレビジョンまたはその他のディスプレイにシステムを単に接続することにより、スタンドアロンシステムとして動作させることもできる。スタンドアロンモードにおいては、マルチメディアコンソール１００により、１人または複数人のユーザが、システムと対話し、映画を眺め、または音楽を聴くことができるようになる。しかし、ネットワークインターフェース１２４または無線アダプタ１４８を介して使用可能とされるブロードバンド接続の統合化を用いて、マルチメディアコンソール１００は、さらに大規模なネットワーク社会における参加者として動作させることもできる。
【００２１】
マルチメディアコンソール１００の電源が投入されると、一定量のハードウェアリソースが、マルチメディアコンソールのオペレーティングシステムによるシステム使用のために確保される。これらのリソースは、メモリ（例えば、１６ＭＢ）、ＣＰＵおよびＧＰＵサイクル（例えば、５％）、ネットワーキング帯域幅（例えば、８ｋｂｓ）などの確保を含むこともある。これらのリソースは、システム起動時に確保されるので、確保されたリソースは、アプリケーションの観点からは存在していない。
【００２２】
とりわけ、メモリの確保は、起動カーネル、同時に実行可能なシステムアプリケーション、およびドライバを包含するのに十分に大容量であることが好ましい。確保されたＣＰＵの使用量がシステムアプリケーションによって消費されない場合に、待機スレッドが未使用の任意のサイクルを消費するように、ＣＰＵの確保は一定であることが好ましい。
【００２３】
ＧＰＵの確保に関しては、システムアプリケーション（例えば、ポップアップ）が生成する軽量のメッセージは、ＧＰＵ割込みを使用し、コードをスケジュールし、ＵＩをオーバレイ中に表現することにより表示される。オーバレイのために必要とされるメモリ容量は、オーバレイ区域のサイズに依存し、オーバレイは、スクリーン分解能を用いてスケーリングされることが好ましい。ユーザインターフェースのすべてが、同時に実行可能なシステムアプリケーションによって使用される場合には、アプリケーションの分解能とは独立した分解能を使用することが好ましい。周波数を変更し、ＴＶ再同期化をもたらす必要がなくなるように、スケーラを使用して、この分解能を設定することができる。
【００２４】
マルチメディアコンソール１００が起動され、システムリソースが確保された後に、同時に実行可能なシステムアプリケーションが実行されて、システム機能を実現する。システム機能は、前述の確保されたシステムリソース内で実行される１組のシステムアプリケーション内にカプセル化される。オペレーティングシステムカーネルは、ゲーミングアプリケーションスレッド（gaming application thread）に対比されるシステムアプリケーションスレッド（system application thread）であるスレッドを識別する。システムアプリケーションは、ＣＰＵ１０１上で所定の時刻および時間間隔で実行されて、アプリケーションに対して一貫性のあるシステムリソースビューを提供するようにスケジュール化されることが好ましい。スケジューリングは、コンソール上で実行されているゲーミングアプリケーションについてのキャッシュの混乱を最小にすることである。
【００２５】
同時に実行可能なシステムアプリケーションがオーディオを必要とするときに、オーディオ処理は、時間感度に起因してこのゲーミングアプリケーションに対して非同期的にスケジュールされる。（以下で説明している）マルチメディアコンソールアプリケーションマネージャは、システムアプリケーションがアクティブであるときに、このゲーミングアプリケーションオーディオレベルを制御する（例えば、ミュートを行い（mute）、減衰させる）。
【００２６】
入力デバイス（例えば、コントローラ１４２（１）および１４２（２））は、ゲーミングアプリケーションとシステムアプリケーションによって共用される。入力デバイスは確保されたリソースではないが、それぞれが、デバイスのフォーカスを有するようになるように、システムアプリケーションとゲーミングアプリケーションの間で、スイッチングされるべきである。アプリケーションマネージャは、知識、すなわちゲーミングアプリケーションの知識なしに、入力ストリームのスイッチングを制御することが好ましく、またドライバは、フォーカススイッチに関する状態情報を保持する。
【００２７】
マルチメディアコンソール１００の作動中に、ユーザには、ローカル（例えば、ＭＵ１４６、ハードディスクドライブなど）でも、リモート（例えば、ネットワークＰＣ、サーバストレージスペースなど）でもある多数のロケーションに、データを記憶するオプションが提供されることになる。本発明は、一般的にエンドユーザおよび開発者に対してストレージを公開する「抽象化ストレージ」のシステムおよび方法を対象としている。換言すれば、このゲーム／アプリケーションが、すべてのデバイスにわたってそれに関連したコンテンツを見つけられるようにしながら、ストレージデバイスが、マルチメディアコンソール１００上のゲーム／アプリケーションに対する抽象ユニットとして公開される。このようにして、データの読取りおよび書込みは、あらゆるストレージデバイスにとって一貫性のあるやり方で行われる。これにより、ユーザは、同様に存在するすべての可能性のあるストレージロケーションにアクセスできるようになる。また、これにより、開発者は、データがそれに／それから転送される、ストレージデバイスのタイプについて知っている必要もなくなり、エンドユーザにとって簡単で一貫性のある体験がもたらされる。
【００２８】
本発明により、アプリケーションは、単にこのアプリケーションが探しているファイルのタイプを知ることにより、特定のファイルがどこに存在するか／特定のファイルが存在するかどうかを見出すことができるようになる。例えば、ユーザは、アプリケーション／ゲームが直接的な知識をもたないデバイス上に「セーブゲーム」を記憶することができる。アプリケーション／ゲームが開始されると、アプリケーション／ゲームは、使用可能なすべてのストレージデバイス上で、ユーザについてのすべてのセーブされたゲームを見つけるように抽象化ストレージサブシステムに対して要求することができる。次いで、そのファイルがどのデバイス上にあるかを詳細には知らないまま、データがアプリケーション／ゲーム中に読み込まれる。
【００２９】
ストレージタイプの多様性は、ストレージが一般的に取り扱われる（すなわち、任意のストレージデバイスにアプリケーションをセーブする）とき、およびストレージが特別に取り扱われる（すなわち、アプリケーションを再生しながら、メモリユニットへ書き込むことがネットワークＰＣに書き込むことよりも高速である）ときに関する問題を提起する。以下で説明するように、本発明は、デバイス上のスペース容量、デバイスからの読取り／デバイスへの書込みのレイテンシ、デバイスの持続性など、各ストレージデバイスの詳細を明らかにする。
【００３０】
本発明によると、ストレージデバイスにセーブすることができる多数のデータタイプが存在する。以下で指摘されるタイプは、例示の目的で提供されており、すべてのデータタイプを網羅したリストではないことが当業者には理解されよう。第１のタイプのデータは、アプリケーションセーブ（application save）やタイトルセーブ（title save）などのアプリケーションデータを含んでいる。アプリケーションセーブは、一般的にセーブポイントやクイックセーブ（quick save）など、ユーザが引き起こしたイベントからもたらされる。クイックセーブは、「チェックポイント」セーブであり、「チェックポイント」セーブでは、ユーザに、ユーザが「チェックポイント」に到達しており、セーブが行われたというフィードバックがもたらされる。タイトルセーブは、アプリケーションタイトル（すなわち、ゲーム）からのデータである。一般的に、タイトルセーブは、アプリケーションディスクからＨＤＤへとファイルをインストールすることからもたらされる。また、タイトルデータを使用して、アプリケーション環境に対する変化（例えば、木が戦闘中に破壊された、またはあるアイテムが取り上げられたなど）をセーブすることもできる。
【００３１】
第２のタイプのデータは、自動アップデートである。このカテゴリのデータは、マルチメディアコンソール１００についてのセキュリティパッチ（security patch）、またはマルチメディアコンソール１００が提供するその他のサービスを含むことができる。ＤＬＣ（Downloaded Content ダウンロードされたコンテンツ）は、さらに別のタイプであり、ネットワークサービスを介して開発者が提供するコンテンツである。ＤＬＣは、約１ＭＢから約１００ＭＢの範囲に及ぶ可能性がある。第４のタイプのデータは、ユーザが作成したコンテンツである。このコンテンツは、マルチメディアコンソール１００またはネットワークＰＣ上で作成することができる。第５のタイプのデータはシステムアプリケーションであり、このシステムアプリケーションは、マルチメディアコンソール１００に対するサービスを提供している。第６のタイプのデータは、デバイスドライバである。
【００３２】
以下は、ユーザがデータをセーブすることができる、例示的デバイスの非限定的なリストである。ローカルデバイスは、メモリユニット１４６、無線アダプタ１４８、内部ハードドライブ１４４、ＵＳＢドライブ、フラッシュメモリ、アプリケーションディスクなどを含んでいる。リモートデバイスは、ネットワークＰＣ（またはその他のコンピューティングデバイス）、ネットワークサービスストレージスペース、またはポータブルメディアプレーヤデバイスなどを含んでいる。各ストレージデバイスは、データをセーブするのに有利な、また不利な固有の特徴を有している。各ストレージタイプについての制限および違いは、本発明により、抽象化ストレージメカニズムの一部分として管理される。一部の制限は、サイズ、デバイスロケーション（ローカル対リモート）、パフォーマンス（レイテンシ、ネットワーク速度）、信頼性、および持続性を含んでいる。
【００３３】
以下の表１は、例示的ストレージデバイスと、上述した特徴に関するデバイスの長所／短所を示している。この表は、セーブされたデータについての宛先とすることが好ましい、いくつかのデバイス（例えば、内部ＨＤＤおよびＭＵ）を識別している。この情報は、「デフォルト」ストレージプリファランスを決定するときに使用することができる。
【００３４】
【表１】
2006134300.tif 000003
【００３５】
マルチメディアコンソール１００が制御できるときには、（以下で説明する）読取り／書込みＡＰＩ（Read/Write API）によって使用することが可能な、表２中の情報を各ストレージデバイスに書き込んでおくことが好ましい。追加のストレージ特性を追加することができる。
【００３６】
【表２】
2006134300.tif 000004
【００３７】
表３は、データにアクセスする速度／レイテンシ、ならびにストレージデバイスからの読取り／ストレージデバイスへの書込みの速度を示している。図から理解することができるように、ストレージデバイス間には多大な多様性が存在する。ネットワークサービスストレージスペースは、最低速のストレージデバイスである。１２８ｋ／秒の（または６４ｋ／秒であることさえある）読取り／書込み速度は、データをその特定のリモートストレージの宛先にセーブするための基本モデルについて使用することができる。この広範な多様性により、すべてのストレージデバイスを、エンドユーザにとって一般性があるように見えるようにすることの難しさが明らかになる。
【００３８】
【表３】
2006134300.tif 000005
【００３９】
これらのオプションを使用することにより、持続性、新しいストレージデバイス、およびオーバーフローの問題が有利に処理される。ユーザの意図した除去（例えば、ＭＵを引き抜くこと）や意図せぬ除去（例えば、誰かがネットワークＰＣの電源を切ったこと）などのイベントにより、開発者がエンドユーザについてのある範囲のエラーメッセージを生成することが必要になるときに、持続性の問題が発生する。また、無線ネットワークは、干渉の問題に出合うこともあり、エンドユーザが読取りコマンドまたは書込みコマンドを完了できないまま、パケットが連続的に脱落することもある。（内部ＨＤＤやネットワークサービスサーバストレージスペースなどの）新しいデバイスがマルチメディアコンソール１００に追加されるときには、本発明は、アプリケーションがマルチメディアコンソールからデータを読み取り／それにデータを書き込むたびに、新しいストレージデバイスについて検査している。デバイスが満杯のときには、本発明は、使用可能なその他のストレージデバイスに基づいて、エンドユーザについてのデフォルトデバイスを割り当てる。また、エラーメッセージがユーザに提供されることもある。
【００４０】
次に図２を参照すると、システムセーブＵＩ（user interface）が示されている。このＵＩは、例えばシステムセーブＵＩ  ＡＰＩを使用して呼び出され、このＵＩにより、マルチメディアコンソール１００が、推定セーブタイムを様々な宛先に対して提供することができるようになる。図２のＵＩは、アプリケーションおよびエンドユーザが使用して、ユーザが開始したセーブに応じて、接続された任意のストレージデバイスのうちの１つにデータをセーブすることができる。ＵＩは、ユーザがセーブすることができる、セーブされたデータ（スロット）の合計ユニット数をアプリケーションに設定できるようにするパラメータを含むこともある。アプリケーションは、システムＵＩなどに対して、それ自身のスキン（skin）、またはテーマを追加するように選択することもできる。
【００４１】
図３を参照して、１つまたは複数のストレージデバイスからデータを読み取るための、例示的コンソール１００上で実施されるプロセスについて次に説明する。ステップ２００において、コンソール１００が起動され、抽象化ストレージの初期化が、ステップ２０２において開始される。ステップ２０４において、コンソールは、すべてのデバイスを検出し、ステップ２０６において、新しいデバイスについて検査する。１つ（または複数）のＡＰＩを公開して（expose）、存在している各デバイスについての特性と共にコンソール１００に接続されたすべてのストレージデバイスを検出し列挙することができる。ＡＰＩは、ストレージデバイスの挿入／除去を追跡すること、デバイスをマウントすること、データにデジタル署名することなどを担うことができる。ステップ２０８において、アプリケーションは、コンソール１００に挿入される。ステップ２１０において、アプリケーションマネージャは、アプリケーションに関連したタイトルＩＤデータについて検出済みのデバイスを検索する。ステップ２１２において、ストレージメディア上のアプリケーションタイトルが、デバイス上のアプリケーションタイトルデータと等しい場合には、ブール変数が、デバイスごとに真／偽に設定される。ステップ２１４において、すべてのメディアタイプを含むビットマップが作成される。
【００４２】
ステップ２１６において、ユーザまたはアプリケーションによって開始された読取りが行われる。ステップ２１８において、制御はシステムアプリケーションまたはＡＰＩに渡されて、デバイスを列挙し、ステップ２２０において、現在のタイトルＩＤに関連するストレージを有するデバイスを探しているデバイス構造を介して、ルーチンはループする。ステップ２２２において、図２のＵＩが提示される。ステップ２２４において、データが、マウントされたデバイスから読み取られる。ステップ２２６において、制御はアプリケーションに戻され、ステップ２２８において、読取りが完了する。
【００４３】
本発明は、一般的なシステムセーブＵＩを使用するか、または公開されたＡＰＩを介して、アプリケーション自体のセーブＵＩを実装するという選択肢をアプリケーションに提供している。この第１の選択肢は、高レベルのシンプルＡＰＩ（Simple API）の一部分として提供されるシンプルストレージモデル（simple storage model）２３０である。ここで、アプリケーションは、ＡＰＩを呼び出し、システムセーブＵＩ（図２）の利点を有する。このオプションは、ＵＩをスキンで覆う（skin）機能を有するアプリケーションタイトルを提供し、その結果、ＵＩは、アプリケーションタイトルの特徴に合う。さらに、このオプションは、いくつかの簡単なパラメータを介してＵＩを変更するメカニズム（例えば、エンドユーザにとって使用可能ないくつかのセーブアプリケーションスロット）を実現する。シンプルストレージにより、アプリケーションタイトルが高レベルＡＰＩを呼び出してデータをコンソール１００に渡すことができるようになるので、シンプルストレージは有用である。コンソール１００は、ストレージデバイスを列挙し、標準ＵＩを提示し、データをセーブし／書込み、エラーについて検査し、またオプションとして、データファイルにデジタル署名する。この方法は、簡単なアプリケーションデータまたはタイトルデータをセーブしたいと望む多数のアプリケーションにとって好ましいものであり、またこの方法により、アプリケーションタイトルは、広範囲のエラー、および問題を引き起こし得る課題（例えば、持続性／非持続性メモリデバイス）を処理することを回避できるようになる。
【００４４】
第２の選択肢は、アプリケーションが記憶するために低レベルＡＰＩを使用できるようにするが、プロセス中でシステムセーブＵＩを呼び出すこともできる、フレキシブルストレージモデル２３２である。フレキシブルストレージは、複数のファイル、スロット化されたセーブ、サブディレクトリ作成などの、より豊富なセーブデータプロトコルを必要とするアプリケーションについて好ましいことがある。フレキシブルストレージモデルは、ストレージプロセスを用いて一意のユーザインターフェース／体験を提示し、またはこのシンプルメソッドでは提供されない一意の追加機能を提供したいと望むアプリケーションプログラマが使用することができる。フレキシブルストレージは、低レベルＡＰＩにアクセスしてアプリケーションの目標を達成する柔軟性をアプリケーションに提供するが、タイトルがファイルの列挙とセーブ／書込みＵＩを作成することを処理することを必要とする。フレキシブルストレージＡＰＩを使用するアプリケーションは、アプリケーション自体のＵＩを作成し、またはシステムセーブＵＩ  ＡＰＩを呼び出して、セーブ／ロードＵＩを実施することができる。セーブモデルに関係なく、ステップ２１８〜２２４は実施される。
【００４５】
簡単なセーブを実施するために、１つまたは複数のＡＰＩを提供することができる。機能的に、主要なＡＰＩを呼び出して、可能性のあるすべてのストレージデバイスからのセーブデータ（例えば、アプリケーションセーブ、スクリーンショットなど）を見つけ、読み取ることができる。ユーザが、アプリケーションのＵＩから「ロードデータ」を開始するときに、アプリケーションは、あるアプリケーションまたはＡＰＩを呼び出して、セーブされた可能性のあるデータを記憶することができるロケーションを検出することができるデータ読取りＡＰＩを呼び出す。次に、ＵＩは、ユーザが特定のデータを有するデバイスを選択することができる、セーブされたデータと共に提示される。次いで、システムはデバイスを要求し、デバイスが（読取り／書込みオペレーションなどの）呼び出しＡＰＩ（calling API）が要求するオペレーションをサポートする場合に、このデバイスに決定される。デバイスは、歌曲の物理ロケーションを抽出するメディアプレーヤなどの、システム機能によって自動化することができることに留意されたい。
【００４６】
デバイスの獲得が成功する場合、要求されるコンテンツコンテナ（content container）についての周知のストレージロケーションが、マウントされる。セーブされたゲームの場合には、これは、デバイス上のタイトルの割り当てられるロケーションのユーザディレクトリでもよい。このロケーションは、その他のタイプのコンテンツについては変わることになるが、周知のロケーションは、システム上のすべてのカテゴリのコンテンツについて割り当てられることになる。次に、要求されているコンテンツの妥当性を検査することができる。この妥当性検査は、ユーザが作成したコンテンツの場合には信頼できないので、署名検証またはコンテンツのフラグ付け（flagging content）を含んでもよい。コンテンツは、要求されたデータがすでに圧縮されている場合には、伸張することができる。（例えば、ネットワークＰＣがもはや使用可能ではないなど）適切なエラーメッセージが、もしあれば、ユーザに対して提示することができる。次いで、制御は、アプリケーションへと戻り、システムＵＩが戻すセーブされたデータを使用して、継続される。
【００４７】
「サイレント」データ読取りを実施して、アプリケーションタイトルが、図２のシステムセーブＵＩを呼び出さずに、データファイル全体にアクセスできるようになることもある。ユーザは、あるロケーションにすでにセーブしている可能性があり、アプリケーションタイトルは、データの宛先を知っている。このタイプのデータ読取りでは、アプリケーションは、例えば、一意の識別子、コンテンツタイプ（例えば、セーブゲーム）、およびコンテンツの処理に関連するその他のフラグ（すなわち、セキュリティ情報）を渡すＡＰＩを呼び出す。本発明によれば、ＡＰＩの呼出しは同期式でも、または非同期式でもよい。システムは、データファイルについての読取りを開始し、ストレージデバイスについての適切なドライブ（例えば、ＨＤＤユーザデータについてのレタードライブ（letter drive））をマウントする。次いで、システムは、データファイルを読み取り、アプリケーションタイトルに渡す。ストレージデバイスが存在しない場合、アプリケーションタイトルは、ＵＩを提示してデバイスに再接続し、アプリケーションには、データファイルがもはやデバイス上に存在しないかどうかが通知される。次いで、システムは、対応するドライブをアンマウントし（unmount）、制御をアプリケーションに戻し、アプリケーションは継続される。同様なオペレーションを実施してタイトルデータを読み取ることもできるが、タイトルデータはローカルハードドライブに記憶されるので、ハードドライブが常に存在することになる可能性が最も高い。
【００４８】
フレキシブルストレージ読取りを実施するために、アプリケーションがより低いレベルでストレージにアクセスすることができるように、より低いレベルの１組のストレージＡＰＩを使用することができる。アプリケーションは、メディアの挿入および除去、デバイスにまたがってのデータの列挙などの様々な場合を取り扱う。フレキシブルストレージ読取りデータオペレーションでは、以下の例示的手順（sequence）を行うこともできる。最初に、ユーザは、アプリケーションＵＩへとナビゲートして、アプリケーションデータをロードする。アプリケーションは、所定のＡＰＩを呼び出して、使用可能なすべてのストレージデバイスを見つける。アプリケーションＵＩは、選択されたデータタイプ（例えば、スクリーンショット対（versus）アプリケーションセーブなど）に基づいて入力され、ユーザは、所望のアプリケーションデータを選択する。ドライブはマウントされ、アプリケーションは、ＡＰＩを使用して、アプリケーションデータを読み取る。アプリケーションは、すべてのエラーメッセージ（例えば、デバイスが持続を停止する、データ読取りがパケット損失に起因して失敗するなど）を処理する必要がある。アプリケーションタイトルがデータ読取りを完了した後に、アプリケーションタイトルは、システムに、データ読取りが完了したことを通知する。次いで、システムは、対応するドライブをアンマウントし、アプリケーションの再生が再開される。
【００４９】
フレキシブルサイレントデータ読取りを実施するために、アプリケーションタイトルは、システムセーブＵＩを呼び出さずに、データファイルを読み取る。アプリケーションは、特定のディレクトリ中のデータ（例えば、インベントリデータ（inventory data））について知りたいだけであり、データファイル全体については知りたくないのでこれを行うことができる。このプロセスは、フレキシブルストレージセーブプロセスに関連して使用され、フレキシブルストレージセーブプロセスでは、アプリケーションタイトルが、複雑なデータ構造（例えば、ディレクトリ／サブディレクトリ）をセーブしており、データが存在する宛先をすでに決定している。ユーザは、ロケーションにすでにセーブしているはずであり、アプリケーションタイトルは、データの宛先を知っているはずである。フレキシブルサイレントデータ読取りを実施する際に、アプリケーションは、ＡＰＩを呼び出すことにより検索を発行する。システムは、見つけられたデータを表すデータ構造を、アプリケーションに戻す。見つけられたデータは、セーブされたゲーム、ディスプレイ名、単に「名前」などの「コンテンツタイプ」でもよい。オプションとして、データに関連するユーザの一意の識別子、およびデータが記憶されるデバイスを識別するより多くのデータへのポインタを戻すことができる。次いでアプリケーションは、別のファンクションコール中のデータ構造のうちの１つを使用して、ストレージデバイスをマウントし、データの読取りを開始する。
【００５０】
システムは、データファイルについての読取りを開始し、ストレージデバイスについての適切なドライブ（例えば、ＨＤＤユーザデータについてのレタードライブ）をマウントする。ストレージデバイスが存在しない場合、プリケーションタイトルは、ＵＩを提示して、デバイスを再接続する必要があり、アプリケーションには、データファイルがもはやデバイス上に存在しないかどうかが通知される。次に、システムは、対応するドライブをアンマウントし、制御は、アプリケーションに戻る。同様なオペレーションを実施してタイトルデータを読み取ることもできるが、タイトルデータは、ローカルハードドライブに記憶されるので、ハードドライブが常に存在することになる可能性が最も高い。
【００５１】
次に図４を参照して、１つまたは複数のストレージデバイスからのデータをセーブするための、例示的コンソール１００上で実施されるプロセスについて次に説明する。ステップ２００〜２１４は、図３を参照して説明したものとほぼ同じである。ステップ２３４において、ユーザまたはアプリケーションによって開始されるセーブ／書込みが行われる。ステップ２１８〜２２２は、前述のように処理され、ステップ２３６において、データがマウントされたデバイスに書き込まれる。ステップ２２６において制御がアプリケーションに戻され、書込みは、ステップ２３８において完了する。
【００５２】
データを書き込むために、シンプルストレージ２４０オプションおよびフレキシブルストレージ２４２オプションが提供される。シンプルストレージセーブ／書込み２４０プロセスは、ユーザがアプリケーションのＵＩ（例えば、アプリケーションセーブ）から「セーブデータ」を開始するときに開始される。このタイプのデータ読取りでは、アプリケーションは、データタイプ（例えばセーブゲーム）を指し示す１組のパラメータ、データをどのように処理すべきかをこのシステムに知らせる、データに関連するフラグ（例えば、データに割り当てるべきセキュリティ情報）、およびこのデータを所有するユーザを指し示す識別子を渡すＡＰＩを呼び出す。システムアプリケーション／ＡＰＩは、可能性のあるストレージロケーションを制御し検査し、セーブタイムを見積もる。ユーザは、（デフォルトストレージデバイスがあらかじめ決められた）デフォルトストレージロケーションを受け入れるか、または無効にし、新しいロケーションを選択する。システムアプリケーションにより、ユーザは、メモリ管理区域に進んで、「満杯」であり、または「使用可能な十分な余裕がない」可能性のあるデバイスを取り扱うことができるようになる。システムは、データセーブにデジタル署名することもできる。
【００５３】
次に、システムＵＩは、データを書き込み、システムＵＩに対する「書込み完了」メッセージに応答する。システムＵＩは、必要に応じてステータスバー（status bar）またはその他のエラーメッセージを処理する。リモートデバイスがセーブプロセス中に使用不可能になることや、パケットが無線ホームネットワーク上で脱落することなど、システムＵＩが取り扱う広範なエラーが存在する。最後に、システムＵＩは、終了し、制御をアプリケーションに戻す。同様なオペレーションを実施して、タイトルデータを書き込むことができるが、タイトルデータは、ローカルハードドライブ上に記憶されるので、ハードドライブが常に存在することになる可能性が最も高い。
【００５４】
シンプルサイレントセーブ／書込み（simple silent save/write）を実施して、タイトルデータの喪失を防止する。サイレントセーブは、ユーザが、ストレージデバイスを選択した後に行われる。サイレントセーブについてのプロセスは、アプリケーションが、記憶する必要のあるデータを有するときに開始される。アプリケーションは、ＡＰＩを呼び出し、ストレージの宛先およびデータ名についてシステムに通知する。システムアプリケーションは、オリジナルセーブのロケーションにアクセスし、ストレージデバイスについての適切なドライブ（例えば、ＨＤＤユーザデータについてのレタードライブ）をマウントする。次いで、アプリケーションは、オリジナルデータファイルを見つける。ストレージデバイスがもはや使用可能でない場合には、ユーザには、宛先ストレージデバイスに再接続するか、または新しいストレージの宛先を選ぶようにユーザに対して要求するＵＩが提示される。また、アプリケーションが、データファイルの所在を見出して上書きすることができない場合、アプリケーションはセーブする余裕があるかどうかを判定する。余裕がある場合、アプリケーションはセーブを行い、余裕がない場合には、アプリケーションは、システムセーブＵＩを提示して、新しいセーブデータプロセスを開始する。次いで、アプリケーションは、データファイルについての書込みを開始し、システムは、任意のエラーを処理する。システムは、書込みを確認し、対応するドライブをアンマウントし、その後アプリケーションは、継続される。
【００５５】
一部のアプリケーションは、シンプル「セーブデータ」メソッドに比べてより複雑なデータセーブメソッドを望み、または必要とすることもある。例えば、これらのアプリケーションは、サブディレクトリ、複数のファイルを作成し、および／またはファイル内における制限された書込みを実施したいと欲することもある。これらのタイトルに対応するために、アプリケーションがより低レベルでストレージにアクセスできるように、より低レベルの１組のストレージＡＰＩが、フレキシブルストレージ２４２セーブ／書込みオプションについて使用される。アプリケーションは、メディアの挿入および除去、デバイスにまたがってのデータの列挙などの様々な場合を取り扱う必要がある。
【００５６】
フレキシブルストレージ２４２セーブ／書込みプロセスは、ユーザが、アプリケーションのＵＩ（例えば、セーブゲーム）からの「セーブデータ」を開始するときに開始される。アプリケーションタイトルは、コンソール１００が将来のストレージデバイスを追加することができるようにする低レベルＡＰＩを用いて、使用可能なストレージデバイスについて検査する。アプリケーションタイトルは、ＡＰＩを呼び出して、それらのデータファイルをセーブする時間の見積もりを提供し、次いでＡＰＩを呼び出して、ユーザがセーブアプリケーションの名前およびデバイスを選択し、宛先をセーブすることができるようにする。次に、システムは、ＡＰＩを呼び出して、ストレージデバイスをマウントし、制御は、アプリケーションに戻る。
【００５７】
ストレージデバイスがマウントされた後に、セーブアプリケーションの名前が、アプリケーションに渡し戻される。アプリケーションは、ストレージＡＰＩを使用して適切なドライブ（例えば、ＨＤＤストレージについてのレタードライブ）に対してデバイスにデータを書き込む（例えば、ディレクトリを作成するなど）。アプリケーションタイトルは、ＡＰＩを呼び出してセーブされたデータについての情報（例えば、スクリーンショット対アプリケーションセーブ、移動可能など（screenshot versus application save, roamable,etc.））を提供し、セーブされたデータにデジタル署名することができる。アプリケーションタイトルは、アプリケーションの全体にわたって、書込みごとのエラーチェックを行って、デバイスが持続しており、デバイスが十分な使用していないブロックを有するようにする。アプリケーションが書込みを完了した後に、システムは通知を受け、ドライブはアンマウントされ、したがってアプリケーションは、再開することができる。
【００５８】
フレキシブルサイレントセーブ／書込みオプション（flexible silent save/write option）が提供される。サイレントセーブは、ユーザがフレキシブルセーブデータ書込みプロセス（flexible save data write process）を介してストレージデバイスを選択した後に行うことができ、サイレントセーブは、アプリケーションタイトルがストレージデバイス上にデータファイルの一部分（例えば、アプリケーション上の「インベントリ」スロット）を上書きすることができるようにする一連の低レベルＡＰＩである。サイレントセーブを用いて、アプリケーションタイトルがサイレントユーザセーブを開始したいと望むときに、アプリケーションタイトルは、ＡＰＩを使用して適切なストレージデバイスをマウントするシステムに対して、ストレージロケーションおよびデータファイル名を渡す。システムは、オリジナルデータファイルを見つける。ストレージデバイスがもはや存在しない場合、ユーザには、宛先ストレージデバイスを再接続し、または新しいストレージの宛先を選ぶようにユーザに要求するＵＩが提示される。アプリケーションがデータファイルを探し出して上書きすることができない場合には、アプリケーションは、セーブする余裕があるかどうかを判定する。余裕がある場合、アプリケーションはセーブを行い、余裕がない場合には、アプリケーションはシステムセーブＵＩを提示して、新しいシンプルセーブプロセスを開始する。次いで、制御は、アプリケーションに戻る。アプリケーションタイトルは、ストレージＡＰＩを使用して、マウントされたドライブに対してデバイスにデータを書き込む（例えば、ディレクトリを作成するなど）。
【００５９】
次いでアプリケーションは、ＡＰＩを呼び出してセーブされたデータについての情報（例えば、スクリーンショット対アプリケーションセーブ、移動可能など）を提供し、セーブされたデータにデジタル署名することができる。アプリケーションタイトルは、アプリケーションの全体にわたって、書込みごとのエラーチェックを行って、デバイスが依然として持続しており、十分な使用していないブロックを有するかどうかを判定する。そうでない場合には、エラーメッセージが表示される。アプリケーションは書込みを完了し、データの書込みが完了したことをシステムに通知する。システムは対応するドライブをアンマウントし、アプリケーションは再開される。同様なプロセスを使用して、タイトルデータを書き込むことができる。さらに、あるオプションを提供して、アプリケーションがそれ自体のアプリケーション特有のＵＩを作成できるようにすることもできる。
【００６０】
以上に加えて、本発明のこのシンプル読取り／書込みプロセスまたはフレキシブル読取り／書込みプロセスを使用してダウンロードされたコンテンツを記憶し、抽出することができる。自動アップデートを実装することができ、この場合にはローカルデバイス上に見当たらない必要なダウンロードが、サーバまたはネットワークＰＣから自動的にダウンロードされる。このオプションの利点は、実装が、エンドユーザにとって透過的であることである。
【００６１】
ユーザが作成したコンテンツ、ならびにシステムアプリケーション、ドライバなどもまた、本発明のシンプル読取り／書込みプロセスまたはフレキシブル読取り／書込みプロセスを使用して記憶し、抽出することができる。メディアファイルは、メディアプレーヤＵＩを介して、ユーザが指定するストレージロケーションから再生し、または、ユーザが指定するストレージロケーションへリッピングする（ｒｉｐ）ことができる。デバイスドライバおよびシステムアプリケーションは記憶されることができるが、これらはコンソールのオペレーションにとって不可欠なファイルなので、すべての状況の下で持続するロケーション（例えば、ＲＯＭ）に記憶されることが好ましい。
【００６２】
本発明は、様々な図面に示す好ましい実施形態に関連して説明してきたが、他の同様な実施形態を使用することもでき、また本発明を逸脱することなく本発明の同じ機能を実施するために、説明した実施形態に対して変更および追加を行うこともできることを理解されたい。
【図面の簡単な説明】
【００６３】
【図１】本発明の態様を実装することができるマルチメディアコンソールを示すブロック図である。
【図２】複数の異なるストレージロケーションからデータを読み込み／そこにデータをセーブするための例示的ユーザインターフェースを示す図である。
【図３】ストレージデバイスからデータを読み取るために実施されるプロセスの流れ図である。
【図４】ストレージデバイスにデータをセーブし／書き込むために実施されるプロセスの流れ図である。
【図１】
2006134300.tif 000006
【図２】
2006134300.tif 000007
【図３】
2006134300.tif 000008
【図４】
2006134300.tif 000009