(57)【要約】  クローズドシステムにおいて、無署名コンテンツの実行を可能にし、またそのような無署名コンテンツがシステム上で実行される場合にリソースの保護を可能にする機構が開示される。例えば、無署名コンテンツを実施するアクセスレイヤーと、クローズドシステムのオペレーティングシステムの間で、アプリケーションプログラミングインターフェースが使用される。アプリケーションプログラミングインターフェースは、アクセスレイヤーのサブレイヤーに対応するサブインターフェースを有することができる。サブインターフェースは、サブレイヤーによって発行されるアクセスコールを、クローズドシステムの保護リソースに提示する。アプリケーションプログラミングインターフェースを提供することによって、無署名コンテンツも、一般には署名付コンテンツのみを実行するように設計されたクローズドシステム上で動作することができる。【選択図】図１
2010528376.tif 000002
【特許請求の範囲】
【請求項１】
クローズドシステム内の保護リソースにアクセスするためのシステムであって、
前記保護リソース［４０５］に対するリソースコールを生成する無署名ソフトウェアコンポーネント［４１０］と、
前記保護リソース［４０５］を管理するクローズドコンピューティングデバイス［１８０］と、
前記保護リソース［４０５］に対して前記リソースコールを提示する少なくとも１つのアプリケーションプログラミングインターフェース［４１５］と
を備えるシステム。
【請求項２】
前記保護リソース［４０５］が、グラフィックスコンポーネント［５１０］、オーディオコンポーネント［５１５］、数学コンポーネント［５２８］、ストレージコンポーネント［５２５］、または入力コンポーネント［５２０］を備える、請求項１に記載のシステム。
【請求項３】
前記アプリケーションプログラミングインターフェース［４１５］が、前記グラフィックスコンポーネント［６１０］、前記オーディオコンポーネント［６１５］、前記数学コンポーネント［６２８］、前記ストレージコンポーネント［６２５］、または前記入力コンポーネント［６２０］に対応するサブインターフェースを１つずつ備える、請求項２に記載のシステム。
【請求項４】
前記クローズドコンピューティングデバイス［２００］が、クローズドゲームコンソール［１８０］である、請求項１に記載のシステム。
【請求項５】
前記クローズドコンピューティングデバイス［２００］が、汎用コンピューター［１００ａ］である、請求項１に記載のシステム。
【請求項６】
前記保護リソース［４０５］が、ネイティブコードフォーマット［５４０］を使用する、請求項１に記載のシステム。
【請求項７】
前記リソースコールが、ユーザーモード［５００］において生成される、請求項１に記載のシステム。
【請求項８】
カーネルモードで動作するクローズドシステム内の保護リソース［４０５］へのアクセスを提供するための方法であって、
ユーザーモードで動作する無署名ソフトウェアコンポーネント［４１０］からクローズドコンピューティングデバイスリソースコールを受け取るステップと、
前記リソースコールを確認するステップ［９０２］と、
前記リソースコールを受け取るためにアプリケーションプログラミングインターフェース［４１５］を公開するステップと
を含む方法。
【請求項９】
前記リソースコールを確認するステップが、
前記リソースコールに関連するメモリーをユーザーモードメモリーロケーションからカーネルモードメモリーロケーションにコピーするステップ［９００］［９０６］と、
前記リソースコールのパラメーターを確認するステップ［９０２］と、
前記リソースコールを処理するために生成されたカーネルモードポイントをハンドルに変換するステップ［９０４］と、
前記ハンドルをユーザーモードに返すステップ［９０４］と
を含む、請求項８に記載の方法。
【請求項１０】
前記パラメーターが、列挙値セット確認、範囲チェック、またはゼロ参照チェック［９０２］を含む、請求項９に記載の方法。
【請求項１１】
前記リソースコールを前記保護リソース［４０５］に提示するステップをさらに含む、
請求項８に記載の方法。
【請求項１２】
前記クローズドシステム［２００］が、クローズドゲームコンソール［１８０］または汎用コンピューター［１００ａ］である、請求項８に記載の方法。
【請求項１３】
前記無署名ソフトウェアコンポーネント［４１０］から受け取った前記リソースコールが、マネージドコードフォーマット［５３０］をとる、請求項８に記載の方法。
【請求項１４】
前記リソースコールを提示するステップが、前記受け取ったマネージドコードフォーマットを、前記保護リソース［４０５］によって使用されるネイティブ言語フォーマットに変換するステップをさらに含む、請求項８に記載の方法。
【請求項１５】
カーネルモードで動作するクローズドシステム内の保護リソース［４０５］へのアクセスを提供するコンピューター可読命令を含むコンピューター可読媒体であって、前記コンピューター可読命令が、
カーネルモード［５０５］で動作するリソースに対するユーザーモードリソースコールを生成する命令と、
前記ユーザーモードリソースコールを確認する命令［９０２］と、
前記リソースコールが確認された場合、前記リソースコールを実行するためにアプリケーションプログラミングインターフェース［４１５］を公開する命令［９０４］と
を含む、コンピューター可読媒体。
【請求項１６】
前記アプリケーションプログラミングインターフェース［４１５］が、ユーザーモード［５００］の前記リソースコールをカーネルモード［５０５］のリソースコールに変換する、請求項１５に記載のコンピューター可読媒体。
【請求項１７】
前記リソースが、前記クローズドシステム内の保護グラフィックスリソース［５１０］に対応し、前記クローズドシステム内の保護オーディオリソース［５１５］に対応し、前記クローズドシステム内の保護ストレージリソース［５２５］に対応し、前記クローズドシステム内の保護数学リソース［５２８］に対応し、または前記クローズドシステム内の保護入力リソース［５２０］に対応する、請求項１５に記載のコンピューター可読媒体。
【請求項１８】
前記ユーザーモードリソースコールを確認する前記命令が、前記リソースコールのパラメーターを確認する命令［９０２］を含む、請求項１５に記載のコンピューター可読媒体。
【請求項１９】
前記パラメーターが、列挙値セット確認、範囲チェック、またはゼロ参照チェック［９０２］を含む、請求項１８に記載のコンピューター可読媒体。
【請求項２０】
前記リソースコールが確認されない場合［９０２］に前記リソースコールを終了する命令をさらに含む、請求項１５に記載のコンピューター可読媒体。
【発明の詳細な説明】
【背景技術】
【０００１】
ゲームコンソールは、今日のコンピューティング環境に広く行き渡っている。ゲームコンソールは一般に、ハードウェアベンダーによって管理された署名付ゲームだけがそのようなコンソール上で実行可能な、クローズドシステム（ｃｌｏｓｅｄ  ｓｙｓｔｅｍ）である。この制約は、様々な理由で行われ得るが、それは、知的財産権侵害を最小限に抑える厳格に管理された環境を有することに関するビジネスモデルを発行者のために確保するためであったり、または例えば、親がプレーさせてもよいと考えるコンテンツだけを子供がプレーできるようにするなど、ゲームシステムでプレーできるゲームのタイプを管理するためであったりする。加えて、署名付コードの動作だけを許可することは、コミュニティー内で通用する得点またはデジタル通貨など、ある種の仮定事項が正確であることが必須である、オンラインコミュニティー内で行われるゲームにおける、詐欺行為の可能性を抑制および低減する助けとなる。
【０００２】
しかし、ゲームコンソールに存在するこれらの厳格な制約は、全体としてより大きな創造的コミュニティーが、クローズドゲームコンソール上でゲームまたはゲームライクなアプリケーションを開発する妨げとなる。したがって、とりわけ、デベロッパー、ゲーマー（ｇａｍｅｒ）、一般ホビイスト、および学生ゲーム開発者コミュニティー（ｓｔｕｄｅｎｔ  ｇａｍｅ  ｄｅｖｅｌｏｐｅｒ  ｃｏｍｍｕｎｉｔｙ）が、従来のクローズドシステム用にゲームを書くことを可能にする必要性に対処することが重要である。加えて、無署名コードの動作をゲームコンソール上で可能にするために、時間と努力を費やしてゲームコンソールに不正侵入する、自家製品デベロッパー（ｈｏｍｅｂｒｅｗ  ｄｅｖｅｌｏｐｅｒ）たちの市場が急成長を遂げている問題に対処することが重要である（そのような場合も、これから以下で開示される主題を用いれば、彼らがそのような時間と努力を別途さらに費やす必要はないであろう）。
【発明の概要】
【課題を解決するための手段】
【０００３】
クローズドシステム上で動作する無署名コンテンツが、保護されたカーネルモード（ｋｅｒｎｅｌ  ｍｏｄｅ）で動作するリソースに対するリソースコール（ｒｅｓｏｕｒｃｅ  ｃａｌｌ）を実行することを可能にする機構が提供される。本開示の主題の一態様では、無署名コンテンツをクローズドシステムにおいてユーザーモード（ｕｓｅｒ  ｍｏｄｅ）で実行する場合、カーネルモードで動作するリソースに対するリソースコールを可能にするＡＰＩの承認済リストのみが公開される。公開されたＡＰＩは、リソースコールを確認し、必要であれば、リソースコールをユーザーモード言語フォーマットからカーネルモード言語フォーマットに変換する。例示的で非限定的な一例では、グラフィックスレイヤー、オーディオレイヤー、入力レイヤー、およびストレージレイヤーなど、保護リソースのサブレイヤーとインターフェースをとる、いくつかのＡＰＩが存在することがある。例示的で非限定的な一態様では、言及されたＡＰＩは、プラットフォーム独立とすることができ、様々なプラットフォームにおいて実施される開発コンテンツからのインターフェースを提供する。例示的で非限定的な一態様では、言及されたＡＰＩは、プラットフォームリソースに許可されたアクセスを変更するように修正することができる。
【０００４】
この「課題を解決するための手段」は、以下の「発明を実施するための形態」においてさらに説明される概念の抜粋を簡略化された形で紹介するために提供されたことに留意されたい。この「課題を解決するための手段」は、特許請求される主題の主要な特徴または必須の特徴を識別することを意図したものではなく、特許請求される主題の範囲を決定する際の助けとして使用されることを意図したものでもない。
【０００５】
上述の「課題を解決するための手段」および以下の「発明を実施するための形態」は、添付の図面と併せて読むことで、より良く理解される。本開示を説明するために、本開示の様々な態様が示される。しかし、本開示は、説明された特定の態様に限定されない。以下の図が含まれる。
【図面の簡単な説明】
【０００６】
【図１】署名付ソフトウェアコンポーネント、すなわち署名付ゲームだけが典型的なクローズドシステム上で動作できるシステムを示す図である。
【図２】署名付ゲームと無署名ゲームの両方がクローズドシステム上で動作できるシステムを示す図である。
【図３】署名付ゲームは認証され、無署名ゲームは認証されないことを示す図である。
【図４】ゲームアクセスレイヤーとゲームオペレーティングシステムの間にＡＰＩが存在することを示す図である。
【図５】図４でアブストラクションとして示されたアクセスレイヤーを、グラフィックス、オーディオ、入力、およびストレージなどの様々なサブレイヤーと共により詳細に示す図である。
【図６】図５の様々なサブレイヤーと対話するサブインターフェースを有するＡＰＩを示す図である。
【図７】ストレージＡＰＩサブインターフェースの態様をより詳細に示す図である。
【図８】ストレージＡＰＩによって使用されるファイルフォーマットを示す図である。
【図９】コンテンツをセーブする例示的な方法を示す図である。
【図９ａ】事前にユーザーモードからデーターを確認する例示的な方法を示す図である。
【図１０】本開示の主題による、無署名コンテンツが動作できる例示的で非限定的なコンピューティングシステム環境を表すブロック図である。
【図１１】無署名コンテンツが導入され得る例示的な方法を示す図である。
【図１２】本開示の主題の別の態様による、前記無署名コンテンツが動作できる例示的で非限定的なマルチメディアコンソールデバイスを示すブロック図である。
【発明を実施するための形態】
【０００７】
概要
一般に、ゲームコンソールは、署名付ゲームの実行だけを許可する。署名付ゲームが、セキュリティーホールを作り得る（ｅｘｐｌｏｉｔｉｖｅ）いかなる仕方でもクローズドコンソールを公開しないことを保証するため、ゲームは、認証として知られるプロセスを受けさせられる。認証は、ゲームへの署名を可能にする前に、ゲームが１組の厳格な規則に従うことを必要とする。これらの厳格な規則は、製造業者およびコンテンツ発行者に不利益な仕方でクローズドコンソールへの不正侵入を可能にし得るセキュリティーホール（ｅｘｐｌｏｉｔ）を当該タイトル（ｔｉｔｌｅ）がそれとは知らずに生成することを防止するために設けられる。特に、クローズドコンソール上でのコンテンツの権利侵害を防止することが重要である。
【０００８】
クローズドコンソール上で動作するゲームは、メモリー、ＣＰＵアクセス、ＧＰＵ、光ディスクドライブ、入力デバイス、および（ハードディスクドライブなどの）永続的ストレージなどのリソースへのアクセスを必要とすることがある。無署名ゲームは、署名付ゲームに必要とされる典型的な認証プロセスを経ていないので、無署名ゲームから保護リソースに流れるデーターが制限され、管理されることを保証する方法を示すための、システム、方法、およびコンピューター可読媒体が本明細書で開示される。
【０００９】
本開示の例示的で非限定的な一態様では、悪意をもつ可能性のある無署名ソースコードへの保護リソースの公開を制限するために、アプリケーションプログラミングインターフェース（ＡＰＩ）が、リソース管理レイヤーを介して発行されるリソース要求をサポートする。本開示の例示的で非限定的な一態様では、ＡＰＩは、無署名ゲームによる、クローズドゲームコンソール内のリソース管理レイヤーを介して行われる保護リソースへのアクセスを制限するようにも構成することができる。ＡＰＩは、よく知られたエントリーポイントを提供し、無署名ゲームがコンソールの保護リソースにアクセスすることを可能にする。リソース管理レイヤーから利用可能にされた利用可能なエントリーポイントは、データーフローを制限し、管理するのを助けるため、また安全性の保証がない新しいエントリーポイントの生成を防止するのを助けるために、コンソール製造業者によって固定され、事前決定されることができる。
【００１０】
本開示の例示的で非限定的な一態様では、リソース管理レイヤーは、サブレイヤーを有することができる。リソース管理レイヤーとクローズドコンソールの保護リソースの間のコールを円滑化するため、ＡＰＩは、リソース管理レイヤーの様々なサブレイヤーをサポートするサブインターフェースを有する。これらのサブインターフェースのいくつかは、リソース管理レイヤーのオーディオサブレイヤー、入力サブレイヤー、ストレージサブレイヤー、グラフィックスサブレイヤー、および数学サブレイヤー用である。
【００１１】
最後に、ＡＰＩは、カーネルまたはスーパーバイザーモード（ｓｕｐｅｒｖｉｓｏｒ  ｍｏｄｅ）で動作するクローズドコンソールの保護リソースと、ユーザーまたはマネージドモード（ｍａｎａｇｅｄ  ｍｏｄｅ）で動作するリソース管理システムまたはレイヤーの間のインターフェースであるので、ＡＰＩは、通常はユーザー／カーネルモードで利用可能な保護リソースに対する、悪意をもつ可能性のあるコードの無拘束なアクセスを防止するために、適所にセキュリティー対策を有することができる。したがって、ＡＰＩは、許可される保護リソースコールのタイプおよび範囲を制限することによって、あるレベルのセキュリティーを提供することができる。
【００１２】
クローズドシステムにおける無署名コンテンツの態様
本開示の主題に関する本セクションは、クローズドシステムにおける無署名コンテンツの実行が安全であるような（すなわちクローズドシステム内のリソースが保護されるような）方法での、そのような実行に重点を置く。これらの態様についてより良い理解を得るには、署名付コンテンツだけを許可するクローズドシステムを、無署名コンテンツと署名付コンテンツの両方を許可するクローズドシステムと比較することが有益である。
【００１３】
したがって、図１は、署名付ソフトウェアコンポーネント、すなわち署名付ゲームだけが動作できるクローズドシステムを示している。具体的には、ゲームＡ  １８５およびゲームＢ  １９０などの様々な署名付ゲームがそれによって実行１９５できる、クローズドシステム１８０が示されている。これらのゲーム１８５、１９０は一般に、クローズドシステム１８０の製造業者によって認可されるが、しかし、いくつかの態様では、それらは、ゲームデベロッパーまたは他の何らかのサードパーティーによって認可することもできる。いずれの場合であっても、システム１８０は、汎用パーソナルコンピューター（ＰＣ）の場合とは異なって、すべてのソフトウェアアプリケーションがその上で動作できるわけではないという意味で、「クローズド」であると見なされる。
【００１４】
上で言及された典型的な署名プロセスは、知的財産権侵害を制限すること、および適切なコンテンツに誰がアクセスできるかを管理することなど、様々な目的に役立つ。しかし、そのようなクローズドシステム１８０の多くの利点にも関わらず、それは、他の「無署名」ゲーム（ゲーム機関（ｇａｍｉｎｇ  ａｕｔｈｏｒｉｔｙ）によって公式に認可されていないゲーム）の開発を不必要に制限する。そのような無署名ゲームは、（署名付ゲームの発行者から許可が得られた場合には「署名付」ゲームのことさえある）既存のゲームの上に作成されたゲームとすることができ、または他の方法ではクローズドシステム上で実行できない新たに開発されたゲームとすることができる。
【００１５】
したがって、図１と対比すると、図２は、署名付ゲームと無署名ゲームの両方がクローズドシステム上で動作できるシステムを示している。図１のクローズドシステムであるクローズドシステム１８０と比較して異なるクローズドシステム２００は、署名付ゲームＡ  ２０５およびゲームＢ  ２１０ばかりでなく、無署名ゲームＣ  ２１５およびゲームＤ  ２２０も実行することができる。しかし、示されたクローズドシステム１８０および２００は、例示的なものに過ぎず、いずれか特定の製造業者またはコンピューティングデバイスの世代に制限されないことに留意されたい（図１および図２では、そのようなシステムは、具体的な描写の代わりに抽象的なボックスで示すことができる）。
【００１６】
上で言及されたように、一般には無署名コンテンツの動作を許可しないシステム２００上で、無署名ゲームコンテンツＣ  ２１５および無署名ゲームコンテンツＤ  ２２０が動作できるようにすることは、そのようなシステム２００のゲーム機能を拡張する。しかし、無署名ゲームコンテンツ２１５、２２０の実行を許可することは、セキュリティー問題も提示する。ゲームＣ  ２１５およびゲームＤ  ２２０は署名されていないので、すなわち、それらが称するところのものが検証されていないので、悪意のあるまたは望ましくないコードおよびデーターが、最終的にゲームシステム２２０上で実行されることがあり得る。図４に関連して簡潔に説明されるように、セキュリティーレイヤーが存在しなければならない。このセキュリティーレイヤーは、まず最初に無署名ゲームの実行を可能にするだけでなく、それに加えて、望ましくないコードおよびデーターがゲームシステム２００のリソースと対話することを防止する利点も有する。
【００１７】
次に、図３は、署名付ゲームは認証され、無署名ゲームは認証されないことを示している。具体的には、ゲームＡ  ３０５およびゲームＢ  ３１０は、これらのゲームが機関によって指定された特定のクローズドシステム上で動作３３５できるように、何らかの認証または確認機関によって署名される。そのような署名付ゲームＡ  ３０５およびゲームＢ  ３１０は、認証３２５されていると言われる。対照的に、認証されていないゲーム３３０は、そのような何らかの機関によって署名されていないゲーム、すなわちゲームＡ  ３１５およびゲームＢ  ３２０であり、そのため一般に、クローズドシステム３００上で動作することはできない。本開示の上記および下記の態様を用いれば、（もともとの署名付ゲームＡ  ３０５およびもともとの署名付ゲームＢ  ３１０に加えて）そのようなゲーム３１５、３２０も、クローズドシステム３００上で動作することができる。
【００１８】
ここで図４を参照すると、図４は、ユーザーモードまたは無署名モードで動作するゲームアクセスレイヤーと、カーネルまたはスーパーバイザーモードで動作するゲームオペレーティングシステムの間に、アプリケーションプログラミングインターフェース（ＡＰＩ）が存在することを示している。ＡＰＩ  ４１５は、ゲームアクセスレイヤー４０５によって発行された、オペレーティングシステムレイヤー４００のリソースを求める要求をサポートする。上で説明されたように、悪意あるコード、または無署名コンテンツに見出される可能性のある、オペレーティングシステムレイヤー４００のリソースを不適切に利用する他のコードからオペレーティングシステムレイヤー４００を保護するため、ゲームシステムの保護された部分、オペレーティングシステムレイヤー４００と、ゲームシステムの保護されていない部分またはユーザー部分の間に、障壁が築かれなければならない。障壁を円滑に生成するため、無署名コンテンツによる実行を許可されるコードは、管理されなければならない。
【００１９】
マネージドコードは、クローズドコンソールプロバイダーなどのコンテンツプロバイダーによって提供されるコードであり、デベロッパーに提供されて、無署名コンテンツの開発に使用される。物理メモリーなど、保護されたクローズドコンソールリソースに、無署名コンテンツが悪意あるまたは不注意な干渉またはアクセスを行うリスクがあるため、一般に正体が特定されない無署名デベロッパーは、コードを開発する際に、ある程度の柔軟性を許可してもらえるに過ぎない。これは、無署名コンテンツが、署名付コンテンツになるための認証プロセスを経ないためである。したがって、コンテンツプロバイダーは、システムリソースに対する無署名コンテンツデベロッパーの能力を制限するため、コンテンツデベロッパーにマネージドコードまたは所定のコードを提供する。
【００２０】
このマネージドコードまたは所定のコードは基本的に、無署名コンテンツデベロッパーによって使用される場合、クローズドコンソールの保護リソースに対する不適切なアクセスを好ましくは許可しない、コンソールプロバイダーによって定められた１組のガイドラインである。マネージドコードを実施するためのいくつかの異なる方法が存在し得る。例えば、コンソールプロバイダーは、アプリケーションによって通常必要とされるアクセスの経路およびレベルを事前決定することができ、そのコードを無署名コンテンツデベロッパーに提供することができる。事前パッケージされたコードは、アクセスの新しい経路およびレベルの生成を防止するため、修正不可能である。マネージドコードが無署名コンテンツデベロッパーに提供される方法は、様々であり、本開示に影響を及ぼさない。本開示に関係することは、マネージドコードおよびカーネル／スーパーバイザーネイティブコードは、保護コンソールリソースと異なる仕方で対話することである。
【００２１】
引き続き図４によって、ゲームアクセスレイヤー４０５を参照すると、ゲームアクセスレイヤー４０５は、（以下で図５および図６を参照してより詳細に説明される）アブストラクション（ａｂｓｔｒａｃｔｉｏｎ）である。簡潔に言えば、ゲームアクセスレイヤー４０５は、無署名コンテンツ４１０が対話するあるタイプのインターフェースとして大まかに理解することができる。実際には、ゲームアクセスレイヤーは、（例えば図３に示されるゲームＡ  ３０５およびゲームＢ  ３１０などの署名付ゲームコンテンツの場合とは異なって）無署名コンテンツ４１０がオペレーティングシステムレイヤー４００に厳格に適合しなくてもよいようにする、無署名コンテンツ４１０のための仮想化ハードウェアを表す。
【００２２】
ＡＰＩ  ４１５は、ゲームアクセスレイヤー４０５によって発行される、オペレーティングシステムレイヤー４００に対する要求をサポートするために提供されるインターフェースである。無署名コンテンツによる実行のために利用可能なマネージドコードは、上で述べられた理由で、署名付コンテンツによって利用可能なネイティブ言語コードとは異なるので、ＡＰＩ  ４１５は、マネージドコードリソース要求を受け取り、その要求をオペレーティングシステムレイヤー４００によって使用されるネイティブ言語モードに変換する。これは、ＡＰＩ  ４１５のサブインターフェースの例示的で非限定的なタイプに関して、以下でより十分に説明される。
【００２３】
ＡＰＩ  ４１５がオペレーティングシステムレイヤー４００に対するゲームアクセスレイヤー４０５からのリソースコールをサポートする方法が、図５を参照してより詳細に説明される。上で言及されたように、いくつかのタイプの保護リソース、すなわち、ストレージ、オーディオ、数学、グラフィックス、入力リソースが存在し得るので、様々なリソースに対するコールを発行できるように、アクセスレイヤー４０５は、少なくとも６つのレイヤー、すなわち、グラフィックスレイヤー５１０、オーディオレイヤー５１５、入力レイヤー５２０、ストレージレイヤー５２５、および数学レイヤー５２８から成ることができる。これらのレイヤーの各々は、異なるタスクを担当する。
【００２４】
例えば、グラフィックスレイヤー５１０は、（フラットシェーディング、法線マッピング、およびテクスチャーマッピングなどを含むが、これらに限定されない）グラフィックスの描画を担当することができ、オーディオレイヤー５１５は、その名称によって示唆されるように、クローズドシステム上でオーディオを担当することができ（しかし、そのようなオーディオは、無署名コンテンツに関連してもよく、または関連しなくてもよいことに留意されたい。オーディオは、ＣＤ、ＤＶＤ、または何らかのコンピューターデバイスファイルから獲得される独立オーディオとすることができる）、入力レイヤー５２０は、コントローラーボタンの選択および入力デバイスを使用したクリックなど、ユーザーからの入力の処理を担当することができ、ストレージレイヤー５２５は、あるゲームコンテンツの保存またはあるゲームコンテンツの呼び出しを担当することができ（加えて、新しいコンソールハードウェアでもゲームコンテンツを普通に動作させるコードおよび／またはデーターを保存することによって、レガシーソフトウェアの動作を可能にするために使用することもできる）、最後に、数学レイヤー５２８は、例えば、（グラフィックスが関与する場合に）より効率的な地図描画を可能にするなど、ある種の数学的関数の実行を可能にすることができる。サブレイヤー５１０、５１５、５２０、５２５、５２７、５２８は例示的なものであり、本開示の態様を説明するために使用されたことに留意されたい。
【００２５】
これらのレイヤー５１０、５１５、５２０、５２５、５２７、５２８の各々は、ユーザーモード５００とスーパーバイザー（例えばカーネル）モード５０５の間で、それぞれのリソースコールを発行する。より明確には、ゲームアクセスレイヤー４０５および関連するレイヤー５１０、５１５、５２０、５２５、５２７、５２８は、ネイティブＯＳレイヤー４５０内のリソースに対して、マネージドコード５３０でリソースコールを発行する。リソースコールは確認され、リソースコールのいずれかのパラメーターが無効または許容可能範囲外であると分かった場合、コールは直ちに終了される。確認に関するさらなる情報は、図９ａを参照することで見出すことができる。リソースコールが確認されると、承認済ＡＰＩがリソースコールに公開され、リソースコールが処理される。
【００２６】
ユーザーモードとカーネルモードの間を分離する理由の１つは、無署名コードが、コンソール製造業者または他の利害関係者によって意図されていない目的で、基礎ネイティブＯＳレイヤー５４０およびいずれかの関連コンソールリソースを占拠しないようにすることである。したがって、図５によれば、上述の無署名コードに関連するいくつかのマネージドコード５３０が、アクセスレイヤー４０５に提供され、アクセスレイヤーは、上で説明された様々なサブレイヤー５１０、５１５、５２０、５２５、５２７、５２８から成ることができる。マネージドコード５３０は、ユーザーモード５００側から提供され、フィルタリングされながらサブレイヤーを通過し、本開示のＡＰＩを介して、スーパーバイザーモード５０５側に達する。これら６つのレイヤー５１０、５１５、５２０、５２５、５２７、５２８は、ＡＰＩ  ４１５を介して、ネイティブＯＳレイヤー５４０に対してリソースコールを発行する。ＡＰＩ  ４１５は、ゲームアクセスレイヤー４０５および様々なサブレイヤー５１０、５１５、５２０、５２５、５２７、５２８からリソースコールを受け取る。そしてＡＰＩは、ネイティブＯＳレイヤー５４０と対話し、リソースコールによる使用のためにリソースをリリースさせる。
【００２７】
様々なリソースは、マネージドコード５３０を使用する無署名コンテンツデベロッパーから利用可能にする必要があるので、サブレイヤー５１０、５１５、５２０、５２５、５２７、５２８によって発行されるコールは、図６に示されるように、ＡＰＩ  ４１５のサブインターフェースによって処理される。図６は、リソースコールをサブレイヤー５１０、５１５、５２０、５２５、５２７、５２８からネイティブＯＳレイヤー５４０に提供する、ＡＰＩ  ４１５のサブインターフェースをより詳細に示している。より詳細には、ＡＰＩ  ４１５のサブインターフェースは、サブレイヤーのタイプに対応する。サブインターフェースグラフィックスＡＰＩ  ６１０は、グラフィックスリソースコールをグラフィックスレイヤー５１０からネイティブＯＳレイヤー５４０に提供し、サブインターフェースオーディオＡＰＩ  ６１５は、オーディオリソースコールをオーディオレイヤー５１５からネイティブＯＳレイヤー５４０に提供し、入力ＡＰＩ  ６２０は、入力レイヤー５２０用であり、ストレージＡＰＩは、ストレージレイヤー５２５用であり、数学ＡＰＩ  ６２８は、数学レイヤー５２８用である。当業者であれば、本開示が示されたサブインターフェースＡＰＩに限定されないことを理解されたい。
【００２８】
サブインターフェースＡＰＩ  ６１０、６１５、６２０、６２５、６２８は、マネージドコードからネイティブコードへのインターフェースを提供し、サブインターフェースの各タイプの用途の例示的で非限定的な説明が提供される。
【００２９】
ストレージＡＰＩ
実施され得るＡＰＩのあるタイプの例示的で非限定的な一例として、本明細書では、図６のストレージＡＰＩ  ６２５が、図７を参照してより十分に説明される。ストレージＡＰＩ  ６２５は、汎用ＰＣとは対照的に、基礎デバイスおよびフォーマットについての知識をもつ必要なしに、すなわち、クローズドゲームコンソール上で、無署名コンテンツを保護システムリソースにセーブし、管理する能力を、デベロッパーに提供する。これは、保護システムリソースにアクセスするのに必要な言語をコード内にすでに含む、マネージドモードでデベロッパーによって使用されるコードを提供する、マネージドコードの一面である。さらに、システムリソースにアクセスするのに必要な開発済コードがデベロッパーに提供されるので、ストレージＡＰＩ  ６２５は、あるリソースおよびファイルを隔離することによって、あるレベルのセキュリティーも提供することができる。以下の説明は、上述の目標の一部または全部を満たすストレージＡＰＩ  ６２５を提供する例示的で非限定的な一方法である。
【００３０】
図７は、ストレージＡＰＩ  ６２５の論理アーキテクチャー概要の例示的で非限定的な説明である。ストレージＡＰＩ  ６２５は、保護リソース上にセーブされるゲームを様々なローカル論理コンテナーにグループ化する。各コンテナーは、ゼロ個以上のセーブゲーム（ｓａｖｅｄ  ｇａｍｅ）を含むことができ、ユーザー依存（ｕｓｅｒ  ａｗａｒｅ）ローカルストレージ７１０またはユーザー非依存（ｕｓｅｒ  ａｇｎｏｓｔｉｃ）ローカルストレージ７１５とすることができる。ユーザーは、実行されるタスクによって様々であり得る。例えば、無署名コンテンツが開発されている場合、ユーザーはデベロッパーとすることができる。別の例では、無署名ゲームがプレーされている場合、ユーザーはゲーマーとすることができる。説明を続けると、ユーザー非依存ローカルストレージ７１５は、セーブゲームを実行する任意のユーザープロファイルによってアクセスすることができる。ユーザープロファイル依存コンテナーは、ゲームを作成したユーザープロファイルによってのみアクセスすることができる。一般に、各ユーザープロファイルは、１つのユーザープロファイル依存コンテナーと、１つのユーザープロファイル非依存コンテナーにアクセスする。
【００３１】
ストレージ７１０または７１５のインスタンスが生成されると、個々のセーブゲームがその内部で生成されることができる。これは、所与の名前を有するファイルを生成するようストレージ７１０または７１５に単に依頼することによって行われる。セーブゲームストレージのインスタンスを有することで、デベロッパーは、セーブゲームへのストリームを取得すること、セーブゲームを削除すること、ストレージ内部のすべてのセーブゲームを列挙すること、またはセーブゲームの名前を変更することもできる。さらに、ストレージ７１０または７１５は、すべてのファイルが空にされること、または完全に削除されることができる。
【００３２】
セーブゲームまたはタイトルは、動作するとき、関連ファイルシステム上のゲームのストレージロケーションにアクセスする必要がある。一般に、タイトルは、関連ファイルシステム内のタイトルの実行可能ディレクトリまたはサブディレクトリに、テクスチャー、動画、およびアセンブリーなどのサポートファイルを置く。タイトルがこのデーターのロケーションにアクセスできない場合、またはロケーションを知らない場合、ゲームは、適切に動作することができない。セーブタイトルに必要な情報を提供するため、タイトルインストール・ローカルサポート（ｔｉｔｌｅ  ｉｎｓｔａｌｌ  ｌｏｃａｌ  ｓｕｐｐｏｒｔ）７２０が提供される。サポート７２０は、セーブゲームが属するタイトルの名前、セーブゲームが属するタイトルのｉｄ、セーブゲームの名前、セーブゲームについてのコメント、およびセーブゲームを代表するサムネイルを含む、ゲームに必要なある種の情報を提供する。
【００３３】
クローズドコンソール・ストレージフォーマットは一般に、汎用フォーマットまたはＰＣフォーマットとは異なる。ストレージＡＰＩ  ６２５は、様々なフォーマットで情報を保存する能力をユーザーに提供するため、クローズドコンソール上で使用される論理マネージドコンテンツラッパー（ｌｏｇｉｃａｌ  ｍａｎａｇｅｄ  ｃｏｎｔｅｎｔ  ｗｒａｐｐｅｒ）７２５と、ＰＣ上で使用されるシステムＩＯ＆シェルラッパー（Ｓｙｓｔｅｍ．ＩＯ  ＆  Ｓｈｅｌｌ  ｗｒａｐｐｅｒ）７３０を有する。ラッパーは、一般的に言えば、１つの言語またはフォーマットで開発されたコンテンツを受け取り、そのコンテンツを別のフォーマットで使用することを可能にするのに必要な言語を提供する、インタープリターと見なすことができる。これは、上で言及されたプラットフォーム独立の機能を提供する。言い換えると、デベロッパーは、ゲームコンテンツをストレージにセーブするためのコードを書き、そのコードをプラットフォーム間で、すなわち、クローズドコンソールとＰＣの間で転送することができる。したがって、ラッパー７２５およびラッパー７３０は、コンテンツをそれぞれのストレージシステムにセーブするために必要なフォーマットを解釈し、提供する。
【００３４】
クローズドコンソール用のストレージシステム、クローズドコンソール・ファイルシステム７４５の要件は、ＰＣ、ＰＣファイルシステム７４０の要件とは異なる可能性が高く、したがって、ストレージフォーマットも異なる可能性が高い。無署名コンテンツデベロッパーは、コンテンツをクローズドコンソールまたはＰＣにセーブするのに必要なコードを書くのに十分な経験または時間を有さないことがあるが、ラッパー７２５および７３０が、ストレージＡＰＩ  ６２５によって提供されるので、デベロッパーは、基礎フォーマットを考慮することなく、セーブコンテンツ機能を実行しさえすればよい。
【００３５】
加えて、クローズドコンソールの基礎リソースは一般に、ＰＣとは異なり、ストレージＡＰＩ  ６２５によるストレージコールを実行するために付加的な機能を必要とすることがあり、スーパーバイザーモード５０５でクローズドコンソール・ファイルシステム７４５と、ユーザーモード５００でラッパー７２５とインターフェースをとる、インターオペラビリティーレイヤー（ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  ｌａｙｅｒ）７３５が提供される。ＡＰＩ  ６２６は、コンテンツをセーブするのに必要なクローズドコンテンツ・ファイルシステム７４５へのアクセスを獲得するために、インターオペラビリティーレイヤー７３５にコールを発行する。ゲームは、以下で説明される方法でフォーマットされる。
【００３６】
セーブゲームファイルフォーマット
ストレージＡＰＩ  ６２５は、図８に示されるような、特定のセーブゲームフォーマットに従ったファイルを生成する。ファイル８００は、３つのセクション、すなわち、ヘッダーブロックデーター８１０、セーブゲームデーター８１５、およびサムネイルデーター８２０に分割される。ヘッダーブロック８１０は一般に、最初に書かれ、セーブゲームデーター８１５がそれに続く。セーブゲームデーター８１０は一般に、セーブゲーム状態を構成するタイトル定義コンテンツである。セーブゲームに関連するサムネイルデーター８２０は一般に、セーブゲームデーター８１０の後のストリーム内に出現する。
【００３７】
ゲームファイルのセーブ
ゲームをセーブするための簡略化されたプロセスが図９に示されている。プロセスステップは、簡略化のため抽象的に示されている。当業者であれば、図９に示されるプロセスは様々な方法を使用して実行できること、各ステップの詳細な説明は本開示を可能にするために必ずしも必要でないことを理解されたい。図９を参照すると、ステップ９００において、ゲームのセーブが実行される。ステップ９０５において、ストレージＡＰＩ  ６２５は、上で図８において説明されたフォーマットにゲームデーターをフォーマットする。データーがフォーマットされると、ステップ９１５において、出力先ファイルが関連ファイルシステムに、すなわち、クローズドコンソールシステムまたは汎用システムにマウントされる。出力先ファイルがマウントされると、ステップ９２０において、図７のユーザー依存ローカルストレージ７１０またはユーザー非依存ローカルストレージ７１５にマウントされたコンテンツファイルに、ゲームがセーブされる。
【００３８】
データーをユーザーモードから上で説明されたようなネイティブシステムＡＰＩに渡す前に、図９で説明されたようなリソースコールを確認することが好ましい場合がある。リソースコールの確認は、不注意でＡＰＩが無効なリソースコールに公開され得る可能性を低減または排除するのに役立つ。図９ａは、リソースコールデーターをネイティブシステムＡＰＩに渡す前に、リソースコールを確認するための方法の例示的で非限定的な一例である。
【００３９】
ステップ９００において、ユーザーモードで保存されたデーターが、カーネルモード内に存在する確認用に割り当てられたメモリーの一部にコピーされる。これは、ユーザーモードとカーネルモードの間の分離を維持するために、ユーザーモードの一部からの任意のデーターに対するどのようなタイプのメモリー参照も防止する試みとして行われる。メモリーがコピーされた後、ステップ９０２において、データーのパラメーターが、既知の良好または許容可能な値に照らして確認される。いくつかのパラメーターチェックは、列挙値セット確認、範囲チェック、またはゼロ参照チェックなどを含むことができる。
【００４０】
９０２の確認ステップが完了した後、カーネルモードリソースへのすべてのポインターは、安全なハンドルに変換され、ハンドルテーブルに保存される。その後、ハンドルは、ユーザーモードに返され、ネイティブまたはカーネルモードポインターを使用する必要がある場合に、参照として使用される。ハンドルを使用しようと試みるその後のコールは、コールが有効なハンドルを参照していることを保証するためにチェックされる。ユーザーモードにおいてネイティブポインターの代わりにハンドルを使用する主要な理由は、ユーザーモードとカーネルモードの間を分離する付加的なレイヤーを提供することである。さらなる理由は、悪意あるコードが、ネイティブポインターを取得するために１つの有効なリソースコールを発行し、次に、コードへのネイティブポインターが分かった後、ネイティブポインター情報を使用して、ネイティブリソースに悪意をもってアクセスすることを防止することである。データーがチェックされ、確認されると、ネイティブシステムコールが起動され、カーネルモードメモリーへの参照が行われないように、ユーザーモードに返されるヒープ上のデーターはどれも、ユーザーモードアロケーションにコピーされる。
【００４１】
コンテンツ提供アーキテクチャーのタイプ
コンテンツ提供アーキテクチャーの様々なタイプが本明細書で考察される。１つのタイプは、コンピューティングソース１００２、１００４、１００６とクローズドシステム１００８の間に、介在サーバー１０１０を有することができ、一方、他のタイプは、コンピューティングソースとクローズドシステム１００８の間に、直接接続を有することができる。当業者であれば、コンテンツがクローズドシステムに配送され得る様々な方法を容易に理解されよう。コンテンツがクローズドシステム１００８に提供されると、システム１００８は、このコンテンツを受け取り、図４に示された、アクセスレイヤー４０５およびＡＰＩ  ４１５、図６に示された、グラフィックス６１０、オーディオ６１５、入力６２０、数学６２８、およびストレージ６２５の様々なサブインターフェースを介して、コンテンツを実行する。情報が受け取られ、保存され、システム１００８のリソースに渡される方法は、アクセスレイヤーにおいてシステム１００８の製造業者によって課される制約に依存し、したがって、無署名コンテンツの内容に依存する。
【００４２】
例示的なコンピューティングデバイス
言及されたように、本開示の主題は、任意のデバイスに適用され、本主題を用いなければクローズドであるシステム上で無署名コンテンツを動作させることが望ましい場合がある。しかし、上で指摘されたように、無署名コンテンツの内容と同等の他のコンテンツは、すべての種類の本開示のコンピューティングオブジェクトと共に機能できることを理解されたい。したがって、図１１に記載の以下で説明される以下の汎用リモートコンピューターは、一例に過ぎず、本主題は、スタンドアロンであるか、またはネットワーク／バス相互運用性および対話性を有するかに関わらず、任意のクライアントまたはポータブルデバイスを用いて実施することができる。したがって、本主題は、非常に僅かまたは最低限のクライアントリソースしか関与しないネットワークホストサービス環境、例えば、機器内に配置されたオブジェクトなど、クライアントデバイスがネットワーク／バスとのインターフェースとして単に機能するネットワーク環境において実施することができる。
【００４３】
必ずしも必要ではないが、本主題は、デバイスもしくはオブジェクトに対するサービスのデベロッパーによる使用のために、オペレーティングシステムを介して部分的に実施することができ、および／または本主題に関連して動作するアプリケーションソフトウェア内に含まれることができる。ソフトウェアは、クライアントワークステーション、サーバー、または他のデバイスなど、１つまたは複数のコンピューターによって実行される、プログラムモジュールなどのコンピューター実行可能命令という一般的な文脈において説明することができる。当業者であれば、本主題が他のコンピューターシステム構成およびプロトコルを用いて実践できることを理解されよう。
【００４４】
したがって、図１１は、先行する図を参照して説明された様々な態様が実施できる適切なコンピューティングシステム環境１００ａの一例を示しているが、上で明らかにされたように、コンピューティングシステム環境１００ａは、実行デバイスのための適切なコンピューティング環境の一例であるに過ぎず、これら様々な態様の使用または機能の範囲に関してどのような限定も示唆する意図はない。コンピューティング環境１００ａは、例示的な動作環境１００ａに示されたコンポーネントのいかなる１つまたは組合せに関しても、どのような依存性または必要性ももたないと解釈されるべきである。
【００４５】
図１１を参照すると、上述の態様を実施するための例示的なリモートデバイスは、コンピューター１１０ａの形態をとる汎用コンピューティングデバイスを含む。コンピューター１１０ａのコンポーネントは、限定することなく、処理装置１２０ａと、システムメモリー１３０ａと、システムメモリーを含む様々なシステムコンポーネントを処理装置１２０ａに結合するシステムバス１２１ａとを含むことができる。システムバス１２１ａは、様々なバスアーキテクチャーのいずれかを使用する、メモリーバスまたはメモリーコントローラー、周辺装置バス、およびローカルバスを含む、いくつかのタイプのバス構造のいずれかとすることができる。
【００４６】
コンピューター１１０ａは一般に、様々なコンピューター可読媒体を含む。コンピューター可読媒体は、コンピューター１１０ａによってアクセスできる任意の利用可能な媒体とすることができる。限定することなく例を挙げると、コンピューター可読媒体は、コンピューター記憶媒体および通信媒体を含むことができる。コンピューター記憶媒体は、コンピューター可読命令、データー構造、プログラムモジュール、または他のデーターなどの情報を記憶するための任意の方法または技術で実施される、揮発性および不揮発性の着脱可能および着脱不能な媒体を含む。コンピューター記憶媒体は、限定することなく、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリー、もしくは他のメモリー技術、ＣＤＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、もしくは他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶、もしくは他の磁気記憶デバイス、または所望の情報を保存するために使用でき、コンピューター１１０ａによってアクセスできる他の任意の媒体を含む。通信媒体は一般に、搬送波などの変調データー信号または他のトランスポート機構内に、コンピューター可読命令、データー構造、プログラムモジュール、または他のデーターを具現し、任意の情報配送媒体を含む。
【００４７】
システムメモリー１３０ａは、リードオンリーメモリー（ＲＯＭ）および／またはランダムアクセスメモリー（ＲＡＭ）などの、揮発性および／または不揮発性メモリーの形態をとるコンピューター記憶媒体を含むことができる。基本入出力システム（ＢＩＯＳ）は、スタートアップ中などにコンピューター１１０ａ内の要素間で情報を転送するのに役立つ基本ルーチンを含み、メモリー１３０ａ内に保存することができる。メモリー１３０ａは一般に、処理装置１２０ａから直接アクセス可能な、および／または処理装置１２０ａがそれに基づいて目下動作している、データーおよび／またはプログラムモジュールも含む。限定することなく例を挙げると、メモリー１３０ａは、オペレーティングシステム、アプリケーションプログラム、他のプログラムモジュール、およびプログラムデーターも含むことができる。
【００４８】
コンピューター１１０ａは、他の着脱可能／着脱不能の揮発性／不揮発性コンピューター記憶媒体も含むことができる。例えば、コンピューター１１０ａは、着脱不能の不揮発性磁気媒体に対して読み書きを行うハードディスクドライブ、着脱可能の不揮発性磁気ディスクに対して読み書きを行う磁気ディスクドライブ、および／またはＣＤ−ＲＯＭもしくは他の光媒体など、着脱可能の不揮発性光ディスクに対して読み書きを行う光ディスクドライブを含むことができる。例示的な動作環境において使用できる他の着脱可能／着脱不能の揮発性／不揮発性コンピューター記憶媒体は、限定することなく、磁気テープカセット、フラッシュメモリーカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、およびソリッドステートＲＯＭなどを含む。ハードディスクドライブは一般に、インターフェースなどの着脱不能メモリーインターフェースを介してシステムバス１２１ａに接続され、磁気ディスクドライブまたは光ディスクドライブは一般に、インターフェースなどの着脱可能メモリーインターフェースによってシステムバス１２１ａに接続される。
【００４９】
ユーザーは、コントローラーを介してクローズドコンピューティングデバイスに入力を提供できるのに加えて、キーボード、およびマウス、トラックボール、またはタッチパッドと通常呼ばれるポインティングデバイスなどの入力デバイスを介して、コンピューター１１０ａにコマンドおよび情報を入力することができる。そのような周辺デバイスに加えて、他の入力デバイスは、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信用アンテナ、またはスキャナーなどを含むことができる。これらおよび他の入力デバイスはしばしば、システムバス１２１ａに結合されるユーザー入力１４０ａおよび関連インターフェースを介して、処理装置１２０ａに接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造によって接続することもできる。グラフィックスサブシステムも、システムバス１２１ａに接続することができる。モニターまたは他のタイプのディスプレーデバイスも、出力インターフェース１５０ａなどのインターフェースを介して、システムバス１２１ａに接続され、そして出力インターフェース１５０ａは、ビデオメモリーと通信できる。モニターに加えて、コンピューターは、出力インターフェース１５０ａを介して接続できる、スピーカーおよびプリンターなどの他の周辺出力デバイスも含むことができる。
【００５０】
コンピューター１１０ａは、リモートコンピューター１７０ａなど、１つまたは複数の他のリモートコンピューターへの論理接続を使用して、ネットワーク環境または分散環境で動作することができ、そしてリモートコンピューター１７０ａは、デバイス１１０ａとは異なるメディア機能を有することができる。リモートコンピューター１７０ａは、パーソナルコンピューター、サーバー、ルーター、ネットワークＰＣ、ピアデバイスもしくは他の共通ネットワークノード、または他の任意のリモートメディア消費もしくは送信デバイスとすることができ、コンピューター１１０ａに関連して上で説明された要素のいずれかまたはすべてを含むことができる。図９に示された論理接続は、ローカルエリアネットワーク（ＬＡＮ）またはワイドエリアネットワーク（ＷＡＮ）などのネットワーク１７１ａを含むが、他のネットワーク／バスを含むこともできる。そのようなネットワーク環境は、家庭、オフィス、企業規模のコンピューターネットワーク、イントラネット、およびインターネットで一般的である。
【００５１】
ＬＡＮネットワーク環境で使用される場合、コンピューター１１０ａは、ネットワークインターフェースまたはアダプターを介してＬＡＮ  １７１ａに接続される。ＷＡＮネットワーク環境で使用される場合、コンピューター１１０ａは一般に、インターネットなどのＷＡＮを介する通信を確立するためのモデムまたは他の手段を含む。内蔵または外付けとすることができるモデムは、入力１４０ａのユーザー入力インターフェースまたは他の適切な機構を介して、システムバス１２１ａに接続することができる。ネットワーク環境では、コンピューター１１０ａまたはその部分に関連して示されたプログラムモジュールは、リモートメモリー記憶デバイスに保存することができる。示され説明されたネットワーク接続は例示的なものであり、コンピューター間で通信リンクを確立する他の手段も使用できることが理解されよう。
【００５２】
例示的なマルチメディア（クローズド）コンソール環境
次に図１２を参照すると、（クローズドデバイスメーカーであるか、または何らかのゲーム発行者であるかに関わらず）何らかの署名機関によって署名された限られた数のソフトウェアコンポーネントだけに閉じられている場合もある、別の例示的で非限定的なコンピューティングデバイス、すなわち、例示的なマルチメディアコンソールを説明するブロック図が示されている。図１２は、本開示の主題の態様がその中で実施できるマルチメディアコンソール１００の機能コンポーネントを示している。マルチメディアコンソール１００は、レベル１（Ｌ１）キャッシュ１０２と、レベル２（Ｌ２）キャッシュ１０４と、フラッシュＲＯＭ（リードオンリーメモリー）１０６とを有する、中央処理装置（ＣＰＵ）１０１を有する。レベル１キャッシュ１０２およびレベル２キャッシュ１０４は、データーを一時的に保存し、したがって、メモリーアクセスサイクルの回数を減少させ、それによって、処理速度およびスループットを向上させる。フラッシュＲＯＭ  １０６は、マルチメディアコンソール１００に電源が投入されたときのブートプロセスの初期フェーズ中にロードされる、実行可能コードを保存することができる。代替として、初期ブートフェーズ中にロードされる実行可能コードは、ＦＬＡＳＨメモリーデバイス（図示されず）内に保存することもできる。さらに、ＲＯＭ  １０６は、ＣＰＵ  １０１から分離して配置することもできる。
【００５３】
このコンソールは、高速および高解像度グラフィックス処理用のビデオ処理パイプラインに属するグラフィックス処理装置（ＧＰＵ）１０８およびビデオエンコーダー／ビデオコーデック（コーダー／デコーダー）１１４など、コンソールから利用可能な様々なリソースを有することができる。この構成では、データーは、グラフィックス処理装置１０８からビデオエンコーダー／ビデオコーデック１１４にバスを介して伝送される。ビデオ処理パイプラインは、データーをテレビまたは他のディスプレーに送るためにＡ／Ｖ（オーディオ／ビデオ）ポート１４０に出力する。ＲＡＭ（ランダムアクセスメモリー）などの、しかしそれに限定されない、様々なタイプのメモリー１１２へのプロセッサーアクセスを円滑化するために、メモリーコントローラー１１０が、ＧＰＵ  １０８およびＣＰＵ  １０１に接続される。
【００５４】
マルチメディアコンソール１００は、Ｉ／Ｏコントローラー１２０と、システム管理コントローラー１２２と、オーディオ処理装置１２３と、ネットワークインターフェースコントローラー１２４と、第１のＵＳＢホストコントローラー１２６と、第２のＵＳＢコントローラー１２８と、好ましくはモジュール１１８上で実施される前面パネルＩ／Ｏサブアセンブリー１３０とを含む。ＵＳＢコントローラー１２６、１２８は、周辺装置コントローラー１４２（１）〜１４２（２）、ワイヤレスアダプター１４８、および外部メモリーユニット１４６（例えば、フラッシュメモリー、外部ＣＤ／ＤＶＤ  ＲＯＭドライブ、着脱可能媒体など）に対するホストとして機能する。ネットワークインターフェース１２４および／またはワイヤレスアダプター１４８は、ネットワーク（例えば、インターネット、ホームネットワークなど）へのアクセスを提供し、Ｅｔｈｅｒｎｅｔ（登録商標）カード、モデム、Ｂｌｕｅｔｏｏｔｈモジュール、およびケーブルモデムなどを含む、多種多様の有線または無線インターフェースコンポーネントのいずれかとすることができる。
【００５５】
システムメモリー１４３は、ブートプロセス中にロードされるアプリケーションデーターを保存するために提供される。媒体ドライブ１４４が提供され、媒体ドライブ１４４は、ＤＶＤ／ＣＤドライブ、ハードドライブ、または他の着脱可能媒体ドライブなどを含むことができる。媒体ドライブ１４４は、マルチメディアコンソール１００に内蔵することもでき、または外部に存在することもできる。アプリケーションデーターは、マルチメディアコンソール１００による実行、再生などのために、媒体ドライブ１４４を介してアクセスすることができる。媒体ドライブ１４４は、シリアルＡＴＡバスまたは他の高速接続（例えばＩＥＥＥ１３９４）などのバスを介してＩ／Ｏコントローラー１２０に接続される。
【００５６】
システム管理コントローラー１２２は、マルチメディアコンソール１００のアベイラビリティーを保証することに関する様々なサービス機能を提供する。オーディオ処理装置１２３およびオーディオコーデック１３２は、ハイファイおよびステレオ処理を有する対応するオーディオ処理パイプラインを形成する。オーディオデーターは、オーディオ処理装置１２３とオーディオコーデック１２６の間で通信リンクを介して伝送される。オーディオ処理パイプラインは、データーを外部オーディオプレーヤーまたはオーディオ機能を有するデバイスによる再生のためにＡ／Ｖポート１４０に出力する。
【００５７】
前面パネルＩ／Ｏサブアセンブリー１３０は、マルチメディアコンソール１００の外側正面に提供された、電源ボタン１５０およびイジェクトボタン１５２、ならびに任意のＬＥＤ（発光ダイオード）または他のインジケーターの機能をサポートする。システム電源モジュール１３６は、マルチメディアコンソール１００のコンポーネントに電力を提供する。ファン１３８は、マルチメディアコンソール１００内の回路を冷却する。
【００５８】
マルチメディアコンソール１００内のＣＰＵ  １０１、ＧＰＵ  １０８、メモリーコントローラー１１０、および他の様々なコンポーネントは、様々なバスアーキテクチャーのいずれかを使用する、シリアルおよびパラレルバス、メモリーバス、周辺装置バス、プロセッサーまたはローカルバスを含む、１つまたは複数のバスを介して相互接続される。
【００５９】
マルチメディアコンソール１００に電源が投入された場合、またはマルチメディアコンソール１００がリブートされた場合、アプリケーションデーターは、システムメモリー１４３からメモリー１１２および／またはキャッシュ１０２、１０４にロードされ、ＣＰＵ１０１上で実行されることができる。アプリケーションは、マルチメディアコンソール１００上で利用可能な異なるメディアタイプに移動するときに、一貫性のあるユーザー体験を提供する、グラフィカルユーザーインターフェースを提示することができる。動作中、さらなる機能をマルチメディアコンソール１００に提供するために、媒体ドライブ１４４内に含まれるアプリケーションおよび／または他のメディアが、媒体ドライブ１４４から起動され、または再生されることができる。
【００６０】
マルチメディアコンソール１００は、システムをテレビまたは他のディスプレーに単に接続することによって、スタンドアロンシステムとして動作することができる。このスタンドアロンモードでは、マルチメディアコンソール１００は、１人または複数人のユーザーが、システムと対話すること、動画を見ること、および音楽を聴くことなどを可能にすることができる。しかし、ネットワークインターフェース１２４またはワイヤレスアダプター１４８を介して利用可能にされるブロードバンド接続を組み込むことで、マルチメディアコンソール１００はさらに、より大きなネットワークコミュニティーの参加者として動作することができる。
【００６１】
図１０に示されたマルチメディアコンソールは、例えばゲームなどのマルチメディアアプリケーションを実行するために使用できる、典型的なマルチメディアコンソールである。マルチメディアアプリケーションは、例えば、システム設定、ボイスチャット、ネットワークゲーム、ネットワークを介して他のユーザーと対話する機能、電子メール、ブラウザーアプリケーションなどを含むシステム機能を用いて、強化することができる。そのようなシステム機能は、マルチメディアコンソール１００のための改良された機能を可能にし、例えば、異なる場所にいるプレーヤーは、インターネットを介して共通のゲームをプレーすることができる。
【００６２】
また、時間とともに、システム機能を更新すること、またはマルチメディアアプリケーションに追加することができる。これらのシステム機能を提供するために、マルチメディアアプリケーションに大幅な修正を施すよう、マルチメディアデベロッパーに要求する代わりに、本明細書で説明されるシステムおよび方法は、マルチメディアデベロッパーが、マルチメディアアプリケーションと連携して動作する別個のシステムアプリケーションを用いて、システム機能を提供することを可能にする。例えば、システムアプリケーションは、ネットワーク機能に関係する機能を具現することができ、それによって、マルチメディアアプリケーションが、マルチメディア（例えばゲーム）デベロッパーによる僅かな作業だけで、ネットワーク機能を提供するように容易に適合されることを可能にする。そのような機能の１つは、多数のネットワーク接続されたユーザーに対するシステムレベル通知の機能である。システム上で動作するゲームなどの個々のマルチメディアアプリケーションによって処理されるのとは対照的に、システムレベル通知をシステムアプリケーションの一部とすることで、ゲームの誘いなどの通知の表示処理は、マルチメディアアプリケーションデベロッパーの開発プロセスから除外され、デベロッパーは、マルチメディアアプリケーションそのものに注力することができる。
【００６３】
上で言及されたように、本主題の例示的な実施形態が様々なコンピューティングデバイスおよびネットワークアーキテクチャーに関連して説明されたが、基礎をなす概念は、デバイスまたはシステムを制御するために入力デバイスが利用できる任意のコンピューティングデバイスまたはシステムに適用することができる。例えば、説明された態様のアルゴリズムおよびハードウェア実施は、デバイス上の別個のオブジェクトとして、別のオブジェクトの一部として、再利用可能なコントロールとして、サーバーからダウンロード可能なオブジェクトとして、デバイスまたはオブジェクトとネットワークの間の「ミドルマン（ｍｉｄｄｌｅ  ｍａｎ）」として、分散オブジェクトとして、ハードウェアとして、メモリー内で、上記のいずれかの組合せなどとして提供される、コンピューティングデバイスのオペレーティングシステムに適用することができる。例示的なプログラミング言語、名前、および例は、本明細書では様々な選択肢の代表として選択されたが、これらの言語、名前、および例は、限定的なものとして意図されていない。
【００６４】
言及されたように、本明細書で説明された様々な技法は、ハードウェアもしくはソフトウェアに関連して、または適切な場合には、両方の組合せに関連して実施することができる。したがって、本主題の方法および装置、またはそれらのある態様または部分は、フロッピー（登録商標）ディスケット、ＣＤ−ＲＯＭ、ハードドライブ、または他の任意の機械可読記憶媒体などの有形な媒体内で具現されるプログラムコード（すなわち命令）の形態をとることができ、プログラムコードが、コンピューターなどの機械にロードされ、機械によって実行された場合、その機械は、本開示の態様を実践するための装置となる。プログラムコードをプログラム可能コンピューター上で実行する場合、コンピューティングデバイスは一般に、プロセッサーと、プロセッサーによって可読の（揮発性および不揮発性メモリーならびに／または記憶素子を含む）記憶媒体と、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスとを含む。
【００６５】
上記の態様に従って提供される任意のソフトウェアを実施または利用できる１つまたは複数のプログラムは、コンピューターシステムと通信するために、好ましくは、高水準手続き型またはオブジェクト指向プログラミング言語で実施される。しかし、プログラムは、それが望ましければ、アセンブリー言語またはマシン語で実施することもできる。いずれの場合も、言語は、コンパイル言語またはインタープリター言語とすることができ、ハードウェア実施と組み合わせることができる。
【００６６】
本開示の態様の方法および装置は、電気的配線もしくはケーブル、光ファイバー、または他の任意の形態の送信を介してなど、何らかの送信媒体を介して送信されるプログラムコードの形態で具現される通信を介して実践することもでき、プログラムコードが、ＥＰＲＯＭ、ゲートアレイ、プログラム可能論理回路（ＰＬＤ）、クライアントコンピューターなどの機械によって受け取られ、その機械内にロードされ、その機械によって実行された場合、その機械は、本開示の主題を実践するための装置となる。汎用プロセッサー上で実施される場合、プログラムコードは、プロセッサーと組み合わされて、本主題の機能を生じさせるように動作する独特な装置を提供する。加えて、本態様に関連して使用される任意の記憶技法は常に、ハードウェアとソフトウェアの組合せとすることができる。
【００６７】
上で説明された態様は、様々な図に記載の好ましい実施形態に関連して説明されたが、説明された態様から逸脱することなく、同じ機能を実行するために、他の類似の実施形態を使用することもでき、または説明された実施形態に修正および追加を施すこともできることを理解されたい。例えば、当業者であれば、本出願で説明されるような方法は、有線または無線に関わらず、ゲームコンソール、ハンドヘルドコンピューター、ポータブルコンピューターなどの任意のコンピューティングデバイスまたは環境に適用でき、通信ネットワークを介して接続され、ネットワークを介して対話する任意の数のそのようなコンピューティングデバイスに適用できることを理解されよう。
【００６８】
さらに、特に無線ネットワークデバイスの数が急増し続けているので、ハンドヘルドデバイスオペレーティングシステムおよび他の特定用途向けオペレーティングシステムを含む様々なコンピュータープラットフォームが企図されていることを強調すべきであろう。またさらに、本主題の機能は、複数の処理チップまたはデバイス内で、あるいは複数の処理チップまたはデバイスにわたって実施することができ、ストレージも同様に、複数のデバイスにわたって達成することができる。したがって、本説明の態様は、いずれか単一の実施形態に限定されるべきではなく、むしろ添付の特許請求の範囲に従った広がりおよび範囲で解釈されるべきである。
【図１】
2010528376.tif 000003
2010528376.tif 000004
【図２】
2010528376.tif 000005
2010528376.tif 000006
【図３】
2010528376.tif 000007
【図４】
2010528376.tif 000008
【図５】
2010528376.tif 000009
【図６】
2010528376.tif 000010
【図７】
2010528376.tif 000011
【図８】
2010528376.tif 000012
【図９】
2010528376.tif 000013
【図９ａ】
2010528376.tif 000014
【図１０】
2010528376.tif 000015
【図１１】
2010528376.tif 000016
【図１２】
2010528376.tif 000017
【国際調査報告】
2010528376.tif 000018
2010528376.tif 000019