JP5250644B2 - 情報処理装置 - Google Patents

Description

本発明は、ゲーム装置などの情報処理装置で実行される情報処理技術に関する。

一般にゲームソフトウェアは、光ディスクや光磁気ディスク、ブルーレイディスクなどのＲＯＭ媒体の形態で流通、販売される。ＲＯＭ媒体に記録されたゲームソフトウェアは書き換えることができないため、ゲームソフトウェアの一部のバグを修正したり、機能を変更するためには、パッチを当てることで対応する。特許文献１は、記録媒体に記録されたバージョン情報と、パッチファイルに含まれるバージョン情報を比較して、より新しいバージョン情報が付与されている起動ファイルをメモリにロードして、ゲーム起動処理を実行するゲーム装置を開示している。

ＵＳ２００８／０１４１０１８号公開公報

インターネットの発達により、ゲームプログラムを含むゲームファイルやパッチファイルを、サーバからインターネット経由でユーザ端末に配信する環境が実現されている。ダウンロードしたゲームファイルやパッチファイルはユーザ端末のストレージにインストールされ、ファイルシステムにより管理される。ゲームプログラムは、起動されると、ゲームファイルやパッチファイルに含まれるコンテンツにアクセスする必要があるが、ゲームプログラムは、通常、コンテンツがストレージのどこに格納されているか把握していない。そのためゲームプログラムは、たとえばシステムのユーティリティを呼び出して、必要なコンテンツのパスを問い合わせ、その結果を受けてファイルにアクセスする。

パスを調査して、ゲームプログラムに通知するユーティリティを用意している場合であっても、ゲームプログラムによっては、たとえばゲームプログラム中に、アクセス先となるパスを埋め込んでおくことも可能である。しかしながら、ファイル管理は、あくまでもユーザ端末のファイルシステムにより行われるため、ファイルシステムにおける実際のパスとは異なるパスが埋め込まれている場合には、ゲームプログラムが、適切でないファイルにアクセスする状況も発生しうる。そこで、効率的に、且つセキュアなファイル管理を可能とするシステムの開発が望まれている。

また、パッチファイルが存在する場合、システムは、パッチファイルの起動ファイルをメモリにロードして、ゲーム起動処理を実行する。このとき、ゲームファイルとパッチファイルとは、ストレージの別の領域に格納されているため、実行されるパッチファイルは、自身がパッチファイルであることを認識して、オリジナルのゲームファイルにアクセスする必要がある。そのため、ゲームプログラムは、あるデータファイルにアクセスする場合に、ゲームファイルにアクセスするのか、またはパッチファイルにアクセスするのかを逐一判断して、アクセス先を決定する必要がある。そのため、パッチファイルが存在する場合は、パス確認作業のために、ファイルアクセス処理が複雑になっている。

そこで本発明は、ファイルアクセスを効率的に実行できる技術を提供することを目的とする。

上記課題を解決するために、本発明のある態様の情報処理装置は、アプリケーションの実行に用いられるアプリケーションファイルを格納する記憶部と、記憶部のファイルを管理するファイルシステムと、起動指示を受け付けて、アプリケーションを起動する起動部と、アプリケーションを実行する処理部と、を備えた情報処理装置であって、ファイルシステムは、起動部がアプリケーションを起動すると、記憶部におけるアプリケーションファイルのパスを取得するパス取得部と、パス取得部において取得したパスを、仮想的な所定のマウントポイントに対応付けるマウント部とを有する。処理部は、所定のマウントポイントを指定して、ファイルアクセスする。

本発明の別の態様は、ファイルシステムである。このファイルシステムは、アプリケーションファイルを格納する記憶部のファイルを管理するファイルシステムであって、アプリケーションが起動されると、記憶部におけるアプリケーションファイルのパスを取得するパス取得部と、パス取得部において取得したパスを、仮想的な所定のマウントポイントに対応付けるマウント部とを備える。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明の情報処理技術によると、ファイルアクセスを効率的に実行できる技術を提供することが可能となる。

本発明の実施例にかかる情報処理システムを示す図である。 実施例にかかる情報処理装置の外観の一例を示す図である。 情報処理装置の回路構成を示す図である。 ゲームファイルのディレクトリ構成を示す図である。 ファイルシステムにより所定のマウントポイント“ＧＡＭＥ０”にマウントされたゲームファイルの仮想的なディレクトリ構成を示す図である。 パッチファイルのディレクトリ構成を示す図である。 オーバーレイ処理を説明するための図である。 情報処理装置におけるファイル管理を実行するための機能ブロックを示す図である。 マウント部により生成される対応表を示す図である。 マウント部により生成される対応表を示す図である。

図１は、本発明の実施例にかかる情報処理システム１を示す。情報処理システム１は、ユーザ端末である情報処理装置１０と、ファイル提供サーバ１２とを備える。ファイル提供サーバ１２は、ゲームプログラムを含むゲームファイルを提供するゲームファイル提供サーバ１２ａと、ゲームに適用するパッチファイルを提供するパッチファイル提供サーバ１２ｂと、ゲームで使用するデータファイルを提供するデータファイル提供サーバ１２ｃとを含む。

情報処理装置１０、ゲームファイル提供サーバ１２ａ、パッチファイル提供サーバ１２ｂ、データファイル提供サーバ１２ｃは、インターネットや有線ＬＡＮなどのネットワーク４を介して通信可能に接続される。情報処理装置１０は無線通信機能を有し、アクセスポイント（以下、「ＡＰ」と呼ぶ）２を介してネットワーク４に接続して、ファイル提供サーバ１２から所望のファイルをダウンロードする。ＡＰ２は、無線ＬＡＮ（Local Area Network）で情報処理装置１０を他のアクセスポイントに接続したり、情報処理装置１０をネットワーク４に接続する中継装置として機能する。このように情報処理装置１０は、無線ＬＡＮ方式による通信機能を有してもよいが、第３世代移動通信システムなどの携帯電話通信方式により携帯電話網に接続して、ファイル提供サーバ１２からファイルをダウンロードしてもよい。

ゲームファイル提供サーバ１２ａ、パッチファイル提供サーバ１２ｂ、データファイル提供サーバ１２ｃは、単一のサーバから構成されてもよいが、複数のサーバから構成されてもよい。また、ゲームファイル提供サーバ１２ａ、パッチファイル提供サーバ１２ｂ、データファイル提供サーバ１２ｃの２以上の組み合わせが、１つのサーバから構成されてもよい。

ゲームファイル提供サーバ１２ａは、ゲームファイルを提供する。ゲームファイルは、起動ファイル、ゲームプログラムなどのゲームを実行するためのファイル群、および情報処理装置１０のシステムソフトウェアが使用するファイル群を含んでいる。ゲームプログラムは、ゲームの実行に必要なプログラムであり、ゲームプログラムを走らせることで、ゲームが進行する。起動ファイルは、ゲームプログラムを起動するためのプログラムであり、起動ファイルを実行すると、ゲームプログラムが呼び出されて実行される。システムソフトウェアが使用するファイル群は、たとえば、情報処理装置１０におけるメニュー画面に表示されるゲームアイコン画像などを含む。

パッチファイル提供サーバ１２ｂは、ゲームに適用するパッチファイルを提供する。パッチファイルは、バグを修正したゲームプログラムや、ゲーム機能を変更するためのデータファイルなどを含む。パッチファイルはゲームファイルと同じファイル構成を有し、ゲームファイルに含まれるコンテンツと置き換えられるべきコンテンツを含んでいる。なお、ここで「コンテンツ」とは、ゲームファイルやパッチファイルに含まれるプログラムやデータファイルなどを統一的に表現する用語として用いている。

したがって、情報処理装置１０は、ゲームファイルおよびパッチファイルの両方をインストールすると、両方に同名のコンテンツが含まれている場合には、パッチファイルに含まれるコンテンツを利用してゲームを実行する。なお、後述するが、ゲームファイルとパッチファイルは、情報処理装置１０において別個のディレクトリに格納され、ゲームファイルのコンテンツがパッチファイルのコンテンツにより上書きされるわけではない。なお、情報処理装置１０が、複数のバージョンのパッチファイルをダウンロードしている場合には、より新しいバージョンのパッチファイルのコンテンツが使用されることで、ゲームが最新の状態で実行されることになる。

データファイル提供サーバ１２ｃは、オリジナルのゲーム進行に追加される新たなキャラクタやゲームシーンなどのデータファイルを提供する。データファイル提供サーバ１２ｃにより保持されるデータファイルは、オリジナルのゲーム進行に対して追加的に使用されることから、以下においては「追加データファイル」と呼ぶ。

図２は、実施例にかかる情報処理装置１０の外観の一例を示す。図２に示す情報処理装置１０は携帯型端末であり、無線通信機能を搭載する。なお情報処理装置１０は、ケーブルを介してネットワーク４に接続してもよく、また携帯型端末に限らず、据置型端末であってもよい。

図２に示すように、情報処理装置１０の表側、すなわち、ユーザが情報処理装置１０を把持して操作するときにユーザに面する側には、指示入力ボタン２１、方向キー２２、Ｒボタン２３、Ｌボタン２４などの入力装置２０と、表示装置６８が備えられている。表示装置６８には、ユーザの指やスタイラスペンなどによる接触を検知するためのタッチパネル６９が併設されている。情報処理装置１０の内部には、情報処理装置１０の傾きを検知するモーションセンサ２５が備えられている。なお情報処理装置１０の裏側に、背面タッチパネルが備えられてもよい。

ユーザは、情報処理装置１０を両手で把持した状態で、例えば、右手親指で指示入力ボタン２１を操作し、左手親指で方向キー２２を操作し、右手人差し指又は中指でＲボタン２３を操作し、左手人差し指又は中指でＬボタン２４を操作することができる。またタッチパネル６９を操作する場合には、情報処理装置１０を両手で把持した状態で、それぞれの親指でタッチパネル６９を操作してもよく、また情報処理装置１０を左手で把持した状態で、右手でタッチパネル６９を操作し、左手親指で方向キー２２を操作し、左手人差し指又は中指でＬボタン２４を操作してもよい。

図３は、情報処理装置１０の回路構成を示す図である。表示装置６８は、情報処理装置１０の各機能により生成される画像を表示する。表示装置６８は、液晶表示装置であってもよいし、有機ＥＬ表示装置であってもよい。タッチパネル６９は、表示装置６８の上に重ね合わせて設けられ、ユーザの指やペンなどによる接触を検知する。タッチパネル６９は、抵抗膜方式、表面型静電容量方式、投影型静電容量方式など、いずれの方式のものであってもよい。情報処理装置１０では、表示装置６８およびタッチパネル６９によりディスプレイが構成される。

無線通信モジュール３０はＩＥＥＥ８０２．１１ｂ／ｇ等の通信規格に準拠した無線ＬＡＮモジュールによって構成され、ＡＰ２を介して、ネットワーク４に接続する。なお無線通信モジュール３０は、他の情報処理装置１０とアドホックモードで直接通信してもよい。携帯電話モジュール３２は、ＩＴＵ（International Telecommunication Union；国際電気通信連合）によって定められたＩＭＴ−２０００（International Mobile Telecommunication 2000）規格に準拠した第３世代（3rd Generation）デジタル携帯電話方式に対応し、携帯電話網６に接続する。携帯電話モジュール３２には、携帯電話の電話番号を特定するための固有のＩＤ番号が記録されたＳＩＭカードが挿入される。

インタフェース５０において、ＬＥＤ（Light Emitting Diode）５１は、無線通信モジュール３０や携帯電話モジュール３２などがデータの送受信をしている際に点滅する。モーションセンサ２５は、情報処理装置１０の動きを検知する。マイク５２は、情報処理装置１０の周辺の音声を入力する。スピーカ５３は、情報処理装置１０の各機能により生成される音声を出力する。ステレオ入出力端子５４は、外部のマイクからステレオ音声を入力し、外部のヘッドフォンなどへステレオ音声を出力する。入力装置２０は、前述した操作キーなどを含み、ユーザの操作入力を受け付ける。

ＣＰＵ（Central Processing Unit）４０は、メインメモリ４４にロードされたプログラムなどを実行する。ＧＰＵ（Graphics Processing Unit）４２は、画像処理に必要な計算を実行する。メインメモリ４４は、ＲＡＭ（Random Access Memory）などにより構成され、情報処理装置１０で動作するプログラムやデータなどを記憶する。ストレージ４６は、ＮＡＮＤ型フラッシュメモリ（NAND-type flash memory）などにより構成され、プログラムやデータなどを記録する。ストレージ４６は、後述するメモリカード制御部６２に挿入される記憶メディア８０に対して、内蔵型の記憶装置として利用される。

ＧＰＳ（Global Positioning System）制御部６０は、ＧＰＳ衛星からの信号を受信し、現在位置を算出する。ＵＳＢ制御部６１は、ＵＳＢ（Universal Serial Bus）で接続された周辺装置との間の通信を制御する。メモリカード制御部６２は、フラッシュメモリなどの記憶メディア８０が挿入されて、記憶メディア８０との間のデータの読み書きを制御する。記憶メディア８０が挿入されると、記憶メディア８０は、補助記憶装置として利用される。メディアドライブ６３は、ゲームファイルを記録したゲーム記録メディア７０が挿入されて、ゲーム記録メディア７０との間のデータの読み書きを制御する。

ゲーム記録メディア７０には、ゲームファイルが記録されており、ユーザは、ゲーム記録メディア７０をメディアドライブ６３に差し込むことで、ゲームをプレイできる。ゲーム記録メディア７０には、書込可能な記憶領域が設けられており、たとえば、パッチファイルや追加データファイルなどが書き込まれてもよい。なお既述したように、情報処理装置１０において、ゲームファイルは、ゲームファイル提供サーバ１２ａよりダウンロードされて、ストレージ４６または記憶メディア８０にインストールすることもできる。このように、情報処理装置１０は、ゲーム記録メディア７０に記録されたゲームファイル、またはインストールされたゲームファイルを実行する機能を有している。ビデオ出力制御部６４は、ＨＤＭＩなどの規格に基づいて、外部表示装置へビデオ信号を出力する。以上の各機能ブロックはバス９０によって互いに接続されている。

以下、実施例の概要を述べる。まず背景として、アプリケーションが、自身のファイルにアクセスする場合、アプリケーションは、自身（すなわちアプリケーションファイル）がどこに格納されているかを把握していない。そのため、ファイルアクセスの一つの手法として、アプリケーションが、アプリケーションＩＤをもとに、システムのユーティリティにファイルの格納位置を調べてもらい、格納位置を示すパス情報を受け取ることで、所望のファイルにアクセスする手法がある。しかしながら、このような手法をとる場合、アプリケーションは比較的自由にストレージにアクセスでき、たとえばアプリケーションがユーティリティを介さずに、自身以外のアプリケーションファイルにアクセスすることも理論上は可能であり、セキュリティ上、好ましくないことも生じうる。

そこで実施例の情報処理装置１０では、ファイルシステムが、アプリケーションファイルのパスを、仮想的な所定のマウントポイント（たとえば、“ＧＡＭＥ０”）に対応付ける。アプリケーションファイルには、この所定のマウントポイント“ＧＡＭＥ０”を特定する情報が予め含まれており、アプリケーションは、このマウントポイントを指定して、ファイルにアクセスする。マウントポイントとアプリケーションファイルのパスの対応付けは、ファイルシステムにより管理されるため、アプリケーションは、ファイルの実際のパスを指定する必要はなく、単に、“ＧＡＭＥ０”を指定するだけで、所望のファイルにアクセスできるようになる。またセキュリティの観点からみると、アプリケーションがファイルのパスを指定しても、ファイルシステムは、設定したマウントポイント以外のパス指定を受け付けないために、アプリケーションに対して実質的なアクセス制限をかけることができ、セキュリティを向上できる。

なお、複数のアプリケーションが起動される場合であっても、各アプリケーションは、同じマウントポイント“ＧＡＭＥ０”を指定して、ファイルにアクセスできる。これは、ファイルシステムが、各アプリケーションプロセスをプロセスＩＤによって区別することにより実現される。このように、本実施例の情報処理装置１０によると、アプリケーションは、アプリケーションファイルの格納位置を全く意識する必要がなく、単にマウントポイント“ＧＡＭＥ０”を指定するだけで、ファイルにアクセスできるため、ファイルアクセスに関するゲームメーカの開発負荷を大幅に低減できるメリットがある。

図４は、ゲームファイルのディレクトリ構成を示す。ここで“ｄｅｖｉｃｅ：”は、ストレージ４６を指定し、図４に示すディレクトリ構成は、ストレージ４６内の格納位置を示しているが、ゲームファイルは、記憶メディア８０またはゲーム記録メディア７０に記録されていてもよい。ゲームファイルは、“ｇａｍｅ”ディレクトリに格納される。全てのゲームファイルには、それぞれを一意に識別するためのタイトルＩＤが設定されており、“ｇａｍｅ”ディレクトリにおいて、各ゲームファイルは、タイトルＩＤ（ｔｉｔｌｅ＿ｉｄ）で特定されるサブディレクトリに格納される。なお、サブディレクトリを構成する“ｔｉｔｌｅ＿ｉｄ”は、タイトルＩＤそのものであってもよく、またタイトルＩＤから生成されるコードであってもよい。

“ｂｏｏｔ＿ｇａｍｅ．ｂ”は、ユーザからの起動指示を受けて、システムソフトウェアが最初に起動する起動ファイルである。“ｆｉｌｅｓ ｏｒ ｄｉｒｓ”は、ファイルまたはディレクトリを統一的に表現しており、ゲームを構成するファイル群が格納されている状態を示している。“ｓｙｓ”には、システムソフトウェアが使用するファイル群が格納される。このファイル群は、タイトルＩＤが記述されたパラメータファイルや、システムソフトウェアがメニュー画面に表示するアイコン画像ファイルなどを含んでいる。

図５は、ファイルシステムにより所定のマウントポイント“ＧＡＭＥ０”にマウントされたゲームファイルの仮想的なディレクトリ構成を示す。ファイルシステムは、図５に示すディレクトリ構成をゲームに対して提供する。したがって、ゲームは、マウントポイント“ＧＡＭＥ０”を指定することで、ゲームファイルに含まれるファイルにアクセスすることができる。たとえば、ファイルのアクセスコマンドが“ｏｐｅｎ（）”で表現される場合、ゲームが、ｏｐｅｎ（“ＧＡＭＥ０：ｄａｔａ１．ｄａｔ”）のコマンドをファイルシステムに送ると、ファイルシステムが、このコマンドを、図４に示す“ｄｅｖｉｃｅ：／ｇａｍｅ／（ｔｉｔｌｅ＿ｉｄ）／ｄａｔａ１．ｄａｔ”のアクセスコマンドであることを認識して、ゲームが“ｄａｔａ１．ｄａｔ”をストレージ４６から読み出すことができる。これにより、ゲームは、“ｄａｔａ１．ｄａｔ”の実際の格納位置を知る必要がなく、単純に、マウントポイント“ＧＡＭＥ０”を指定することで、ファイルにアクセスできるようになる。

本実施例において、パッチファイルが存在する場合、情報処理装置１０のファイルシステムは、ゲームファイルとパッチファイルとのオーバーレイ処理を行う。本実施例においてパッチファイルは、ゲームファイルと同じファイル構成を有し、ゲームファイルに含まれるコンテンツと置き換えられるべきコンテンツを含んでいる。本実施例においてオーバーレイ処理とは、ゲームファイルが格納されたディレクトリに、パッチファイルが上書きされた状態を仮想的に生成する処理をいう。なお、ゲームファイルとパッチファイルとは、別個の位置に格納されており、ゲームファイルがパッチファイルにより実際に上書きされるわけではない。これにより、ゲームは、パッチファイルを意識することなく、ゲームファイルが格納されたディレクトリにアクセスすると、ファイルシステムが、必要に応じてパッチファイルのパスに切り替えて、ゲームがパッチファイルにアクセスできるようになる。以下では、ゲームファイルが格納されたディレクトリが、図５に示す仮想的なディレクトリである例を示すが、図４に示す実際のディレクトリであってもよい。

図６は、パッチファイルのディレクトリ構成を示す。パッチファイルは、“ｐａｔｃｈ”ディレクトリに格納される。“ｐａｔｃｈ”ディレクトリにおいて、各パッチファイルは、タイトルＩＤ（ｔｉｔｌｅ＿ｉｄ）で特定されるサブディレクトリに格納される。パッチファイルは、図４に示すゲームファイルと同じディレクトリ構成をとるが、ゲームファイルに含まれるコンテンツのうち、更新または追加が必要なコンテンツのみが含まれる。なお、図６に示す例では、“ｂｏｏｔ＿ｇａｍｅ．ｂ”が含まれているが、オリジナルのゲームファイルに含まれる“ｂｏｏｔ＿ｇａｍｅ．ｂ”に更新の必要がなければ、パッチファイルにおいて“ｂｏｏｔ＿ｇａｍｅ．ｂ”は含まれない。

図７は、オーバーレイ処理を説明するための図である。ゲームディレクトリ７２は、マウントポイント“ＧＡＭＥ０”にマウントされたゲームファイルの仮想的なディレクトリ構成を示す。ゲームディレクトリ７２において、“ｂｏｏｔ＿ｇａｍｅ．ｂ”は、ゲームの起動ファイルであり、“ｄａｔａ１．ｄａｔ”、“ｄａｔａ２．ｄａｔ”は、それぞれゲームのデータファイルである。“ｐａｒａｍｅｔｅｒ．ａ”は、システムソフトウェアで使用されるゲームのパラメータファイルであり、“ｉｃｏｎ０．ｐ”、“ｉｃｏｎ１．ｐ”は、メニュー画面に表示されるアイコン画像データであり、“ｇａｍｅ＿ｉｎｆｏ．ｃ”は、メニュー画面に表示されるゲームの情報データである。

パッチディレクトリ７４は、パッチファイルのディレクトリ構成を示す。ゲームの実行時、ゲームディレクトリ７２に含まれるコンテンツは、パッチファイルに含まれるコンテンツにより置き換えられる。ここでは、パッチファイルに含まれる“ｂｏｏｔ＿ｇａｍｅ．ｂ”、“ｄａｔａ１．ｄａｔ”、“ｐａｒａｍｅｔｅｒ．ａ”、“ｉｃｏｎ０．ｐ”、“ｇａｍｅ＿ｉｎｆｏ．ｃ”が、ゲームファイルに含まれる同一名のファイルの代わりに使用される。なお、パッチファイルにおける“ｐｒ．ｂ”は、ゲームの追加データに相当する。

ファイルシステムは、ゲームファイルを所定のマウントポイントにマウントして、仮想的なゲームディレクトリ７２を生成した後、同一のタイトルＩＤをもつパッチファイルを探索する。ファイルシステムは、パッチファイルを見つけると、ゲームファイルに仮想的に上書きするコンテンツをゲームディレクトリ７２から探し出す。ここでは、“ｂｏｏｔ＿ｇａｍｅ．ｂ”、“ｄａｔａ１．ｄａｔ”、“ｐａｒａｍｅｔｅｒ．ａ”、“ｉｃｏｎ０．ｐ”、“ｇａｍｅ＿ｉｎｆｏ．ｃ”が抽出される。また、“ｐｒ．ｂ”も、ゲームファイルに追加されるファイルとして抽出される。

ファイルシステムは、上書きするべきファイルを抽出すると、ゲームディレクトリ７６として示すゲームファイルを仮想的に生成する。なおファイルシステムは、実際にゲームファイルのディレクトリにパッチファイルを上書きするのではなく、あくまでもゲームファイルにパッチファイルが上書きされているような仮想的なゲームディレクトリ７６を生成する。ゲームディレクトリ７６において、“＊”をつけたコンテンツは、パッチファイルに含まれているものであり、実際にはパッチディレクトリ７４に格納されている。このようにファイルシステムが、オーバーレイ処理を行うことで、ゲームは、アクセスするコンテンツがゲームファイルに含まれるものなのか、またはパッチファイルに含まれるものなのかを意識することなく、所望のコンテンツにアクセスすることができる。

図８は、情報処理装置１０におけるファイル管理を実行するための機能ブロックを示す。図８では、メインメモリ４４やＧＰＵ４２などの図示は省略している。情報処理装置１０は、入力装置２０、タッチパネル６９、入力部９２、ＣＰＵ４０および記憶部１３０を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

入力部９２は、入力装置２０およびタッチパネル６９から入力されるユーザによる操作指示を受け付ける。記憶部１３０は、ゲームの実行に用いられるゲームファイルを格納し、ストレージ４６、記憶メディア８０、および／またはゲーム記録メディア７０を含む。なお、パッチファイルが存在する場合、記憶部１３０は、ゲームファイルとは別のディレクトリに、パッチファイルを記録する。なお、ゲームファイルおよびパッチファイルは、ストレージ４６、記憶メディア８０またはゲーム記録メディア７０のいずれに格納されていてもよい。以下では、説明の便宜上、ゲームファイルおよびパッチファイルが、記憶部１３０に格納されているものとして説明する。

ＣＰＵ４０は、プロセス起動部９４、ファイルシステム１００および処理部１２０の機能を構成する。ファイルシステム１００は、記憶部１３０のファイルを管理し、パス取得部１０２、マウント部１０４、パス切替部１０６、属性設定部１０８およびパス変換部１１０を有する。ファイルシステム１００の各機能は、システムソフトウェアのカーネルレイヤや、ユーティリティソフトウェアなどにより実現される。処理部１２０は、ゲームを実行し、アプリケーション実行部１２２およびファイルアクセス部１２４を有する。処理部１２０は、ゲームソフトウェアおよびユーティリティソフトウェアにより実現される。

まずファイルシステム１００による仮想マウント処理について説明する。ゲームの実行前、システムソフトウェアは、表示装置６８に、ゲームアイコンを含むメニュー画面を生成する。ゲームアイコンは、たとえば図７のゲームディレクトリ７２に示す“ｉｃｏｎ０．ｐ”から生成される。ユーザが、入力装置２０またはタッチパネル６９よりゲームアイコンを選択すると、入力部９２がユーザの選択操作を受け付け、プロセス起動部９４に通知する。プロセス起動部９４は、その通知を、ゲームの起動指示として受け付ける。プロセス起動部９４は、選択操作により指定されたゲームのタイトルＩＤを特定し、記憶部１３０から、そのゲームタイトルＩＤの起動ファイル（ｂｏｏｔ＿ｇａｍｅ．ｂ）を探索して、起動する。

このときプロセス起動部９４は、起動したアプリケーションに対して、プロセスＩＤを付与する。プロセス起動部９４は、プロセスＩＤを、アプリケーションを起動した順に付与し、したがって、実行中のアプリケーションは、プロセスＩＤにより区別される。そのため複数のゲームが同時に実行されている場合、各ゲームからのコマンドは、プロセスＩＤにより区別されることになる。以下、ゲームのタイトルＩＤが、“ＡＢＣＴＥＮＮＩＳ２”であり、プロセスＩＤが“１”に設定されたものとする。プロセス起動部９４は、ゲーム“ＡＢＣＴＥＮＮＩＳ２”の起動ファイルを起動すると、プロセスＩＤおよびゲームタイトルＩＤとともに、起動した旨をファイルシステム１００に通知する。

ファイルシステム１００において、パス取得部１０２は、ゲームタイトルＩＤを用いて、記憶部１３０を探索し、実行するゲームファイルのパスを取得する。図４に示したように、本実施例においてゲームファイルは、タイトルＩＤで特定されるディレクトリに格納されている。そこでパス取得部１０２は、“／ｇａｍｅ／ＡＢＣＴＥＮＮＩＳ２”を含むディレクトリを探索し、ゲームファイルのパスを取得する。パス取得部１０２が、ゲームファイルのパスを取得すると、マウント部１０４が、そのパスを、仮想的な所定のマウントポイント“ＧＡＭＥ０”に対応付け、対応表を生成する。パス取得部１０２およびマウント部１０４は、起動ファイルが起動されると、処理部１２０からの指示なしに自動的にマウント処理を行う。

図９は、マウント部１０４により生成される対応表を示す。対応表には、プロセスＩＤ、タイトルＩＤ、ゲームファイルのパス情報、およびマウントポイントが対応付けられて記録される。なお、図９に示す対応表は、プロセスＩＤとゲームファイルのパス情報とを一対一に対応付けているが、プロセスＩＤと、ゲームファイルに含まれる各ファイル（コンテンツ）のパス情報とが一対一に対応付けられてもよい。処理部１２０がファイルシステム１００にファイルアクセスのコマンドを送る際、コマンドには、プロセスＩＤが付加される。ファイルシステム１００は、プロセスＩＤを参照して、対応表において対応付けられているパス情報を特定することで、ファイルのアクセス先を特定することができる。

なお、図９においては、説明のために、ＡＢＣＴＥＮＮＩＳ２が起動された後、さらに別のゲームタイトルＩＤ“ＤＥＦＳＯＣＣＥＲ”をもつゲームが起動されたときに生成される対応表を示している。図示されるように、マウント部１０４は、ＤＥＦＳＯＣＣＥＲのゲームプロセスに対しても、ＡＢＣＴＥＮＮＩＳ２と同じマウントポイントを設定する。このように、ファイルシステム１００は、全てのゲームファイルに対して、同じマウントポイント“ＧＡＭＥ０”を設定し、プロセスＩＤによって、ファイルパスを管理する。

このファイルシステム１００によるマウント処理により、ゲームは、図５に示す仮想的なディレクトリ構成でゲームファイルにアクセスできるようになる。なお、ゲームファイルには、マウントポイント“ＧＡＭＥ０”を特定する情報が予め含まれており、起動ファイルが起動されると、起動ファイルはマウントポイント“ＧＡＭＥ０”を用いて必要なコンテンツにアクセスし、またゲームプログラムが起動されると、ゲームプログラムが、同じくマウントポイント“ＧＡＭＥ０”を用いて、所望のコンテンツにアクセスする。

処理部１２０の機能は、プロセス起動部９４により起動ファイルが実行されて、起動ファイルによりゲームプログラムが実行されることで実現される。アプリケーション実行部１２２は、ゲーム進行を制御し、ファイルアクセス部１２４は、ゲーム進行に必要なファイルを記憶部１３０から読み出す。たとえば、データファイル“ｄａｔａ１．ｄａｔ”を記憶部１３０から読み出す場合、ファイルアクセス部１２４は、ｏｐｅｎ（“ＧＡＭＥ０：ｄａｔａ１．ｄａｔ”）のコマンドを、プロセスＩＤとともに、ファイルシステム１００に送る。ファイルシステム１００において、パス変換部１１０は、プロセスＩＤから、マウントポイント“ＧＡＭＥ０”に対応付けられているパス情報を特定し、仮想マウントポイントを、記憶部１３０におけるパス（ｄｅｖｉｃｅ：／ｇａｍｅ／ＡＢＣＴＥＮＮＩＳ２／ｄａｔａ１．ｄａｔ）に変換することで、ファイルアクセス部１２４は、記憶部１３０における“ｄａｔａ１．ｄａｔ”にアクセスすることができる。

次にファイルシステム１００によるオーバーレイ処理について説明する。本実施例でオーバーレイ処理は、ゲームファイルのパスを仮想的なマウントポイントにマウントした後に実行される。マウント部１０４が、図９に示す対応表を生成した後、パス取得部１０２は、同じゲームタイトルＩＤのパッチファイルが存在するか記憶部１３０を探索して調査する。パッチファイルが存在しなければ、オーバーレイ処理は実行されない。図６に示したように、本実施例においてパッチファイルは、タイトルＩＤで特定されるパッチディレクトリに格納されている。そこでパス取得部１０２は、“／ｐａｔｃｈ／ＡＢＣＴＥＮＮＩＳ２”を含むディレクトリを探索し、存在すれば、パッチファイルのパスを取得する。パス取得部１０２が、パッチファイルのパスを取得すると、パス切替部１０６が、パッチファイルのディレクトリを参照して、ゲームファイルと比較する。具体的にパス切替部１０６は、ゲームファイルとパッチファイルの両方に同名のコンテンツが含まれている場合に、ゲームファイルに含まれるコンテンツのパスを、パッチファイルに含まれるコンテンツのパスに設定する。

図７を参照して、パス切替部１０６は、ゲームディレクトリ７２に含まれるコンテンツと、パッチディレクトリ７４に含まれるコンテンツとを比較して、“ｂｏｏｔ＿ｇａｍｅ．ｂ”、“ｄａｔａ１．ｄａｔ”、“ｐａｒａｍｅｔｅｒ．ａ”、“ｉｃｏｎ０．ｐ”、“ｇａｍｅ＿ｉｎｆｏ．ｃ”が重複していることを判定し、また“ｐｒ．ｂ”がパッチディレクトリ７４にのみ含まれていることを判定する。パス切替部１０６は、この判定結果を受けて、仮想的なゲームディレクトリ７６を生成する。ゲームディレクトリ７６において、“＊”をつけたコンテンツは、パッチファイルに含まれているコンテンツを示している。オーバーレイ処理を行う場合、マウント部１０４は、コンテンツごとにパス情報を設定した対応表を生成する。

図１０は、マウント部１０４により生成される対応表を示す。対応表には、プロセスＩＤ、タイトルＩＤ、コンテンツ、コンテンツのパス情報、およびマウントポイントが対応付けられて記録される。図示されるように、ゲームファイルとパッチファイルとで重複するコンテンツのパス情報には、パッチディレクトリのパス情報が記述されている。なお、マウントポイントは、“ＧＡＭＥ０”のままである。このように、マウント部１０４は、マウントポイントを変えずに対応表を生成することで、あたかもパッチファイルがゲームファイルに上書きされたような仮想ゲームディレクトリ７６を、処理部１２０に提供することができる。これにより処理部１２０において、ファイルアクセス部１２４は、アクセスするファイルがゲームファイルに含まれているのか、またはパッチファイルに含まれているのかを意識しないでよく、ファイルアクセス処理を簡易に実行できる。

パス取得部１０２が記憶部１３０を探索した結果、複数のパッチファイルを見つけた場合、パス取得部１０２は、パッチファイルのバージョン情報を取得して、最新のバージョンのパッチファイルのパスを取得し、パス切替部１０６に渡す。なお、複数のパッチファイルのバージョン情報が同じである場合には、パス取得部１０２は、更新日（インストール日）が新しいパッチファイルのパスを取得する。ゲーム記録メディア７０のゲームファイルを実行する場合であって、記憶メディア８０およびゲーム記録メディア７０のそれぞれに記録されているパッチファイルのバージョン情報が同じである場合には、パス取得部１０２は、更新日にかかわらず、ゲーム記録メディア７０に記録されているパッチファイルのパスを取得することが好ましい。これにより、ファイルアクセス部１２４が、ゲーム記録メディア７０にアクセスすることで、ゲームが実行されるようになる。

なお、本実施例の情報処理装置１０は、以上のマウント処理の仕組みを利用して、ゲームファイル以外のファイルのパスを仮想的なマウントポイントにマウントすることもできる。

情報処理装置１０は、データファイル提供サーバ１２ｃからダウンロードした追加データファイルを、記憶部１３０に格納している。追加データファイルは、“ａｄｄｄａｔａ”ディレクトリに格納される。追加データファイルも、ゲームファイルやパッチファイルと同じく、タイトルＩＤ（ｔｉｔｌｅ＿ｉｄ）で特定されるサブディレクトリに格納される。したがって、追加データファイルのディレクトリは、“ｄｅｖｉｃｅ：／ａｄｄｄａｔａ／（ｔｉｔｌｅ＿ｉｄ）／”で構成される。

処理部１２０において、ファイルアクセス部１２４が追加データファイルにアクセスするときには、まずゲームが、追加データマウントＡＰＩ処理モジュールを呼び出して、追加データファイルのマウント処理を行わせる。具体的には、追加データマウントＡＰＩ処理モジュールが、マウント部１０４に対して、所望の追加データファイルのマウント処理を指示する。この指示には、プロセスＩＤ、ゲームタイトルＩＤ、マウントポイントを特定する情報（たとえば“ａｄｄｄａｔａ０”）、追加データファイルを特定する情報が含まれる。

マウント部１０４は、追加データマウントＡＰＩ処理モジュールからの指示を受けて、指定された追加データファイルのパスを、指示されたマウントポイント“ａｄｄｄａｔａ０”にマウントする。これにより、ファイルアクセス部１２４は、マウントポイント“ａｄｄｄａｔａ０”を指定して、所望の追加データファイルにアクセスできる。なお、複数の追加データファイルのパスをマウントするときには、追加データマウントＡＰＩ処理モジュールが、マウントポイントを指定する情報を、“ａｄｄｄａｔａ１”、“ａｄｄｄａｔａ２”などとして、マウントポイントを異ならせることで、ファイルアクセス部１２４が、所望の追加データファイルにアクセスできる。

また、処理部１２０は、記憶部１３０の“ｓａｖｅｄａｔａ”ディレクトリに格納されているセーブデータファイルにアクセスできる。セーブデータファイルも、ゲームファイルやパッチファイルと同じく、タイトルＩＤ（ｔｉｔｌｅ＿ｉｄ）で特定されるディレクトリに格納される。したがって、セーブデータファイルのディレクトリは、“ｄｅｖｉｃｅ：／ｓａｖｅｄａｔａ／（ｔｉｔｌｅ＿ｉｄ）／”で構成される。

処理部１２０において、ファイルアクセス部１２４がセーブデータファイルにアクセスするときには、まずゲームが、セーブデータマウントＡＰＩ処理モジュールを呼び出して、セーブデータファイルのマウント処理を行わせる。具体的には、セーブデータマウントＡＰＩ処理モジュールが、マウント部１０４に対して、所望のセーブデータファイルのマウント処理を指示する。この指示には、プロセスＩＤ、ゲームタイトルＩＤ、マウントポイントを特定する情報（たとえば“ｓａｖｅｄａｔａ０”）、セーブデータファイルを特定する情報が含まれる。

マウント部１０４は、セーブデータマウントＡＰＩ処理モジュールからの指示を受けて、指定されたセーブデータファイルのパスを、指示されたマウントポイント“ｓａｖｅｄａｔａ０”にマウントする。これにより、ファイルアクセス部１２４は、マウントポイント“ｓａｖｅｄａｔａ０”を指定して、所望のセーブデータファイルにアクセスできる。なお、複数のセーブデータファイルのパスをマウントするときには、セーブデータマウントＡＰＩ処理モジュールが、マウントポイントを指定する情報を、“ｓａｖｅｄａｔａ１”、“ｓａｖｅｄａｔａ２”などとして、マウントポイントを異ならせることで、ファイルアクセス部１２４が、所望のセーブデータファイルにアクセスできる。

また、処理部１２０は、他のゲームファイルにもアクセスできる。たとえばＡＢＣＴＥＮＮＩＳ２が、ＡＢＣＴＥＮＮＩＳ２より古いバージョンをもつＡＢＣＴＥＮＮＩＳ１のキャラクタなどを使用できる場合、ＡＢＣＴＥＮＮＩＳ２のｓｙｓディレクトリに、ＡＢＣＴＥＮＮＩＳ１を実行するためのパスワードが予め記録されている。このパスワードは、ＡＢＣＴＥＮＮＩＳ１固有のものであり、ＡＢＣＴＥＮＮＩＳ１のｓｙｓディレクトリにも記録されている。

ＡＢＣＴＥＮＮＩＳ２は、ゲームマウントＡＰＩ処理モジュールを呼び出して、他のゲームのマウント処理を行わせる。具体的には、ゲームマウントＡＰＩ処理モジュールが、マウント部１０４に対して、アクセスを希望するゲームファイルのマウント処理を指示する。この指示には、プロセスＩＤ、ゲームタイトルＩＤ、マウントポイントを特定する情報（たとえば“ＧＡＭＥ１”）、他のゲームファイルを特定する情報、および他のゲームファイルのパスワードが含まれる。

マウント部１０４は、ゲームマウントＡＰＩ処理モジュールからの指示を受けて、指定されたゲームファイルのパスワードが、指定されたゲームファイルのｓｙｓディレクトリに含まれるパスワードと一致しているか判定する。一致していなければ、マウント処理は実行されない。一方、一致していれば、マウント部１０４は、他のゲームファイルのパスを、指示されたマウントポイント“ＧＡＭＥ１”にマウントする。これにより、ファイルアクセス部１２４は、マウントポイント“ＧＡＭＥ１”を指定して、ＡＢＣＴＥＮＮＩＳ１にアクセスできる。このとき、他のゲームファイルのパッチファイルが存在すれば、パス切替部１０６が、オーバーレイ処理を実行する。これにより、ファイルアクセス部１２４は、他のゲームファイルにアクセスできるようになる。

なお、属性設定部１０８は、各マウントポイントに対して、属性を設定できる。ここで属性は、アクセス制限に関し、読出専用であるか、または読出／書込可能であるかを特定する。属性設定部１０８は、“ＧＡＭＥ”を含むアクセスポイント、すなわちゲームファイルおよびオーバーレイ処理されたゲームファイルに対して、読出専用の属性を設定する。同様に、属性設定部１０８は、“ａｄｄｄａｔａ”を含むアクセスポイント、すなわち追加データファイルに対して、読出専用の属性を設定する。一方、属性設定部１０８は、“ｓａｖｅｄａｔａ”を含むアクセスポイント、すなわちセーブデータファイルに対して、読出／書込可能の属性を設定する。ファイルシステム１００は、属性設定部１０８により設定された属性にしたがって、ファイルアクセス部１２４からのコマンドを処理する。たとえば、“ＧＡＭＥ０”のファイルに対して書込要求が送られてきた場合であっても、“ＧＡＭＥ０”のファイルには、読出専用の属性が設定されているため、ファイルシステム１００は、その要求を拒否する。これにより、ファイルが不正に操作される事態を回避できる。

以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。実施例では、アプリケーションの例としてゲームを示したが、それ以外のアプリケーションであってもよい。

１・・・情報処理システム、１０・・・情報処理装置、１２・・・ファイル提供サーバ、２０・・・入力装置、４０・・・ＣＰＵ、４６・・・ストレージ、６２・・・メモリカード制御部、６３・・・メディアドライブ、６８・・・表示装置、６９・・・タッチパネル、７０・・・ゲーム記録メディア、７２・・・ゲームディレクトリ、７４・・・パッチディレクトリ、７６・・・ゲームディレクトリ、８０・・・記憶メディア、９２・・・入力部、９４・・・プロセス起動部、１００・・・ファイルシステム、１０２・・・パス取得部、１０４・・・マウント部、１０６・・・パス切替部、１０８・・・属性設定部、１１０・・・パス変換部、１２０・・・処理部、１２２・・・アプリケーション実行部、１２４・・・ファイルアクセス部、１３０・・・記憶部。

Claims (9)

1. アプリケーションプログラムを含むファイル群、およびアプリケーションプログラムを起動するための起動ファイルを含むアプリケーションファイルをディレクトリ構造で格納する記憶部と、
   前記記憶部にディレクトリ構造で格納されたファイルを管理するファイル管理部と、
   起動指示を受け付けて、起動ファイルを実行する起動部と、
   起動ファイルの実行後、アプリケーションプログラムを実行する処理部と、を備えた情報処理装置であって、
   前記起動部は、起動ファイルを実行するとプロセスＩＤをアプリケーションプロセスに対して付与し、
   前記ファイル管理部は、
   前記起動部が起動ファイルを実行すると、前記記憶部におけるアプリケーションファイルのパスを取得するパス取得部と、
   前記パス取得部において取得したパスを、プロセスＩＤと、所定のマウントポイントに対応付けるマウント部と、を有し、
   前記処理部は、所定のマウントポイントおよびプロセスＩＤを指定して、プロセスＩＤを付与されたアプリケーションプロセスに関するファイルにアクセスすることを特徴とする情報処理装置。
2. アプリケーションファイルには、所定のマウントポイントを特定する情報が含まれていることを特徴とする請求項１に記載の情報処理装置。
3. 前記マウント部は、所定のマウントポイントと、アプリケーションファイルのパスと、プロセスＩＤとを対応付けた対応表を生成することを特徴とする請求項１または２に記載の情報処理装置。
4. 前記マウント部は、前記処理部からの指示なしに、マウント処理を行うことを特徴とする請求項１から３のいずれかに記載の情報処理装置。
5. 前記マウント部は、アプリケーションファイル以外のファイルのパスを、別のマウントポイントに対応付けることができることを特徴とする請求項１から４のいずれかに記載の情報処理装置。
6. 前記ファイル管理部は、
   マウントポイントに、読出専用の属性、または、読出および書込可能の属性を設定する属性設定部を、さらに有することを特徴とする請求項１から５のいずれかに記載の情報処理装置。
7. 前記起動部が複数のアプリケーションの起動ファイルを実行する場合、それぞれのアプリケーションプロセスに対して異なるプロセスＩＤを付与し、
   前記マウント部は、複数のアプリケーションプロセスに対して同じマウントポイントを設定するとともに、それぞれのアプリケーションプロセスに関して、取得したパスを、プロセスＩＤおよび設定したマウントポイントに対応付ける、
   ことを特徴とする請求項１から６のいずれかに記載の情報処理装置。
8. コンピュータに、
   アプリケーションの起動ファイルが実行されると、アプリケーションプログラムを含むファイル群および起動ファイルを含むアプリケーションファイルをディレクトリ構造で格納する記憶部におけるアプリケーションファイルのパスを取得する機能と、
   取得したパスを、起動ファイルが実行されたことによりアプリケーションプロセスに対して付与されたプロセスＩＤと、所定のマウントポイントに対応付ける機能と、
   所定のマウントポイントおよびプロセスＩＤを指定したコマンドを受け付けると、所定のマウントポイントおよびプロセスＩＤに対応付けたパスを特定する機能と、
   を実現させるためのプログラム。
9. 請求項８に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images