JP2015088143A - 情報処理装置およびゲームデータのデータ構造 - Google Patents

Abstract

【課題】新たなゲームデータのデータ構造を提供する。
【解決手段】パッケージファイル２１４は、コンピュータにより実行されるプログラムファイルを含むデータ構造を有して構成される。このデータ構造においては、１または複数のブロックを割り当てられたファイルを複数含み且つ各ファイルのメタデータを含むゲームデータのイメージファイル２１２に、当該イメージファイル２１２を構成する複数のブロックのそれぞれに行った署名を少なくとも含むメタデータがメタデータ領域２０８に付加されている。イメージファイル２１２に含まれるファイルのブロックには、署名は行われていない。
【選択図】図１１

Description

本発明は、ゲームデータのデータ構造に関し、また当該データ構造を有するゲームデータを処理する情報処理装置に関する。

従来よりゲームプログラムを含むゲームデータ（ゲームソフトウェア）は、光ディスクや光磁気ディスク、ブルーレイディスクなどのＲＯＭ媒体の形態で流通、販売されてきた。最近ではインターネットにおけるデータ通信の高速化により、サーバがインターネット経由でゲームデータのイメージファイルを配信できるようになっている。

ゲームソフトウェアは、起動ファイル、ゲームプログラムなどのゲームを実行するためのリソースファイル群、およびゲーム装置のオペレーティングシステム（ＯＳ：Operating System）が使用するファイル群を含んでいる。ゲーム装置のハードウェアスペックが飛躍的に向上したことにともない、ゲームソフトウェアに含まれるファイル数は多くなり、データサイズは大規模化する傾向にある。ゲームソフトウェアは、複数のゲームファイルと、各ファイルのメタデータを含んで構成されるが、ゲームプログラムの実行時、メタデータは、ファイルが格納されているセクタを特定するなどの目的のために予めメモリに読み出されて、ファイルアクセス処理に利用されることが好ましい。メモリのサイズは有限であるため、メタデータのデータサイズを、できるだけ小規模に抑えたデータ構造の開発が望まれている。

またメタデータをメモリに展開することは、ファイルアクセスの高速化に寄与するが、ゲームファイルを記憶する記憶部からのデータ読出速度は様々であり、一般に、ＲＯＭ媒体を装着するメディアドライブからのデータ読出速度は遅く、ＤＲＡＭからのデータ読出速度は速いことが知られている。そこで複数の記憶部にゲームファイルが記憶されている場合に、効率的なファイルアクセスを行う技術の開発が望まれている。

上記課題を解決するために、本発明のある態様の情報処理装置は、起動ファイルおよびプログラムファイルを含むゲームデータを処理する情報処理装置であって、当該ゲームデータは、１または複数のブロックを割り当てられたファイルを複数含み且つ各ファイルのメタデータを含むゲームデータのイメージファイルに、当該イメージファイルを構成する複数のブロックのそれぞれに行った署名を少なくとも含むメタデータが付加されて構成されており、署名を含むメタデータが付加されたイメージファイルを第１のマウントポイントにマウントして、イメージファイルを認識する第１マウント処理部と、認識したイメージファイルを第２のマウントポイントにマウントして、イメージファイルに含まれる複数のファイルを認識する第２マウント処理部とを備える。

本発明の別の態様は、ゲームデータのデータ構造である。このゲームデータのデータ構造は、コンピュータにより実行されるプログラムファイルを含むゲームデータのデータ構造であって、１または複数のブロックを割り当てられたファイルを複数含み且つ各ファイルのメタデータを含むゲームデータのイメージファイルに、当該イメージファイルを構成する複数のブロックのそれぞれに行った署名を少なくとも含むメタデータが付加されており、イメージファイルに含まれるファイルのブロックには、署名が行われていないことを特徴とする。

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

本発明の情報処理技術によると、ユーザが快適にゲームをプレイすることのできる環境を実現することが可能となる。

本発明の実施例にかかる情報処理システムを示す図である。 情報処理装置の機能ブロックを示す図である。 ゲームソフトウェアのファイル構成の概念図を示す図である。 ゲームソフトウェアの具体的なファイル構成例を示す図である。 グループとファイルの関係の一例を示す図である。 グループファイルの一例を示す図である。 ファイルスペースの割り当ての一例を説明するための図である。 ゲームデータのデータ構造の参考例を示す図である。 ゲームデータの作成方法を示すフローチャートである。 （ａ）は、ゲームデータの完全平文のイメージファイルの一例を示す図であり、（ｂ）は、圧縮したイメージファイルの一例を示す図である。 本実施例のゲームデータのデータ構造の一例を示す図である。 （ａ）は、フラットパステーブルの一例を示す図であり、（ｂ）は、衝突ファイルの一例を示す図である。 （ａ）は、通常のルートディレクトリおよび下層のサブディレクトリを示す図であり、（ｂ）は、スーパディレクトリおよび下層のサブディレクトリを示す図である。 ファイルアクセス機能を実現するための構成を示す図である。 ファイル管理機能を実現するための構成を示す図である。 コピー処理の一例を説明するための図である。 記憶部の記憶領域の状態を模式的に示す図である。

図１は、本発明の実施例にかかる情報処理システム１を示す。情報処理システム１は、情報処理装置１０と、ネットワークサーバ５と、デジタルコンテンツを配信するコンテンツサーバ１２と、デジタルコンテンツを販売するストアサーバ１６とを備え、これらはインターネットやＬＡＮ（Local Area Network）などのネットワーク３を介して接続している。コンテンツサーバ１２は、デジタルコンテンツのメーカやパブリッシャなどにより保守、管理される。

アクセスポイント（以下、「ＡＰ」とよぶ）８は、無線アクセスポイントおよびルータの機能を有し、情報処理装置１０は、無線または有線経由でＡＰ８に接続して、ネットワーク３上のネットワークサーバ５、コンテンツサーバ１２、ストアサーバ１６と通信可能に接続する。

情報処理装置１０は、ユーザが操作する入力装置６と無線または有線で接続し、入力装置６はユーザの操作結果を示す操作情報を情報処理装置１０に出力する。情報処理装置１０は入力装置６から操作情報を受け付けるとＯＳ（システムソフトウェア）やアプリケーションソフトウェアの処理に反映し、出力装置４から処理結果を出力させる。情報処理システム１において情報処理装置１０はゲームソフトウェアを実行するゲーム装置であり、入力装置６はゲームコントローラなど情報処理装置１０に対してユーザの操作情報を供給する機器であってよい。ゲームをプレイするためにユーザは情報処理装置１０のＯＳ（システムソフトウェア）にログインする。ＯＳにログインするユーザは、情報処理装置１０において登録されているユーザアカウントによって管理される。

ネットワークサーバ５は情報処理システム１の運営主体により保守、管理され、情報処理システム１のユーザに対してゲームのネットワークサービスを提供する。ネットワークサーバ５はユーザを識別するネットワークアカウントを管理しており、ユーザは、ネットワークアカウントを用いて、ネットワークサーバ５が提供するネットワークサービスにサインインする。ユーザは情報処理装置１０からネットワークサービスにサインインすることで、ストアサーバ１６からデジタルコンテンツを購入し、またコンテンツサーバ１２からデジタルコンテンツの配信を受けることができる。なお本実施例において、デジタルコンテンツは、様々な種類のアプリケーションソフトウェアであってよいが、以下では、特にデジタルコンテンツがゲームソフトウェアである場合について説明する。

補助記憶装置２はＨＤＤ（ハードディスクドライブ）やフラッシュメモリなどの大容量記憶装置であり、ＵＳＢ（Universal Serial Bus）などによって情報処理装置１０と接続する外部記憶装置であってよく、内蔵型記憶装置であってもよい。出力装置４は画像を出力するディスプレイおよび音声を出力するスピーカを有するテレビであってよく、またコンピュータディスプレイであってもよい。出力装置４は、情報処理装置１０に有線ケーブルで接続されてよく、無線接続されてもよい。

入力装置６は複数のプッシュ式の操作ボタンや、アナログ量を入力できるアナログスティック、回動式ボタンなどの複数の入力部を有して構成される。撮像装置であるカメラ７は出力装置４の近傍に設けられ、出力装置４周辺の空間を撮像する。図１ではカメラ７が出力装置４の上部に取り付けられている例を示しているが、出力装置４の側方に配置されてもよく、いずれにしても出力装置４の前方でゲームをプレイするユーザを撮像できる位置に配置される。情報処理装置１０は、カメラ７の撮像画像からユーザを顔認証する機能をもつ。

図２は、情報処理装置１０の機能ブロック図を示す。情報処理装置１０は、メイン電源ボタン２０、電源ＯＮ用ＬＥＤ２１、スタンバイ用ＬＥＤ２２、システムコントローラ２４、クロック２６、デバイスコントローラ３０、メディアドライブ３２、ＵＳＢモジュール３４、フラッシュメモリ３６、無線通信モジュール３８、有線通信モジュール４０、サブシステム５０およびメインシステム６０を有して構成される。

メインシステム６０は、メインＣＰＵ（Central Processing Unit）、主記憶装置であるメモリおよびメモリコントローラ、ＧＰＵ（Graphics Processing Unit）などを備える。ＧＰＵはゲームプログラムの演算処理に主として利用される。これらの機能はシステムオンチップとして構成されて、１つのチップ上に形成されてよい。メインＣＰＵはＯＳを起動し、ＯＳが提供する環境下において、補助記憶装置２やＲＯＭ媒体４４に記録されたゲームソフトウェアを実行する機能をもつ。

サブシステム５０は、サブＣＰＵ、主記憶装置であるメモリおよびメモリコントローラなどを備え、ＧＰＵを備えない。サブＣＰＵの回路ゲート数は、メインＣＰＵの回路ゲート数よりも少なく、サブＣＰＵの動作消費電力は、メインＣＰＵの動作消費電力よりも少ない。上記したように、サブＣＰＵは、メインＣＰＵがスタンバイ状態にある間に動作するものであり、消費電力を低く抑えるべく、その処理機能を制限されている。なおサブＣＰＵおよびメモリは、別個のチップに形成されてもよい。

メイン電源ボタン２０は、ユーザからの操作入力が行われる入力部であって、情報処理装置１０の筐体の前面に設けられ、情報処理装置１０のメインシステム６０への電源供給をオンまたはオフするために操作される。以下、メイン電源がオン状態にあるとは、メインシステム６０がアクティブ状態にあることを意味し、メイン電源がオフ状態にあるとは、メインシステム６０がスタンバイ状態にあることを意味する。電源ＯＮ用ＬＥＤ２１は、メイン電源ボタン２０がオンされたときに点灯し、スタンバイ用ＬＥＤ２２は、メイン電源ボタン２０がオフされたときに点灯する。

システムコントローラ２４は、ユーザによるメイン電源ボタン２０の押下を検出する。メイン電源がオフ状態にあるときにメイン電源ボタン２０が押下されると、システムコントローラ２４は、その押下操作を「オン指示」として取得し、一方で、メイン電源がオン状態にあるときにメイン電源ボタン２０が押下されると、システムコントローラ２４は、その押下操作を「オフ指示」として取得する。

メインＣＰＵは補助記憶装置２やＲＯＭ媒体４４に記録されているゲームプログラムを実行する機能をもつ一方で、サブＣＰＵはそのような機能をもたない。しかしながらサブＣＰＵは補助記憶装置２にアクセスする機能、ネットワークサーバ５やコンテンツサーバ１２などの間で情報を送受信する機能を有している。サブＣＰＵは、このような制限された処理機能のみを有して構成されており、したがってメインＣＰＵと比較して小さい消費電力で動作できる。これらのサブＣＰＵの機能は、メインＣＰＵがスタンバイ状態にある際に実行される。

クロック２６はリアルタイムクロックであって、現在の日時情報を生成し、システムコントローラ２４やサブシステム５０およびメインシステム６０に供給する。

デバイスコントローラ３０は、サウスブリッジのようにデバイス間の情報の受け渡しを実行するＬＳＩ（Large-Scale Integrated Circuit）として構成される。図示のように、デバイスコントローラ３０には、システムコントローラ２４、メディアドライブ３２、ＵＳＢモジュール３４、フラッシュメモリ３６、無線通信モジュール３８、有線通信モジュール４０、サブシステム５０およびメインシステム６０などのデバイスが接続される。デバイスコントローラ３０は、それぞれのデバイスの電気特性の違いやデータ転送速度の差を吸収し、データ転送のタイミングを制御する。

メディアドライブ３２は、ゲームなどのアプリケーションソフトウェア、およびライセンス情報を記録したＲＯＭ媒体４４を装着して駆動し、ＲＯＭ媒体４４からプログラムやデータなどを読み出すドライブ装置である。以下では、プログラムおよびデータを特に区別しない場合には、まとめてデータと呼ぶこともあるが、データは、ファイルを構成する要素を表現するものとしても使用する。ＲＯＭ媒体４４は、光ディスクや光磁気ディスク、ブルーレイディスクなどの読出専用の記録メディアである。

ＵＳＢモジュール３４は、外部機器とＵＳＢケーブルで接続するモジュールである。ＵＳＢモジュール３４は補助記憶装置２およびカメラ７とＵＳＢケーブルで接続してもよい。フラッシュメモリ３６は、内部ストレージを構成する補助記憶装置である。無線通信モジュール３８は、Bluetooth（登録商標）プロトコルやIEEE802.11プロトコルなどの通信プロトコルで、たとえば入力装置６と無線通信する。なお無線通信モジュール３８は、ＩＴＵ（International Telecommunication Union；国際電気通信連合）によって定められたＩＭＴ−２０００（International Mobile Telecommunication 2000）規格に準拠した第３世代（3rd Generation）デジタル携帯電話方式に対応してもよく、さらには別の世代のデジタル携帯電話方式に対応してもよい。有線通信モジュール４０は、外部機器と有線通信し、たとえばＡＰ８を介してネットワーク３に接続する。

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

ゲームソフトウェアはツリー型ディレクトリ構造を有し、ルートディレクトリには起動ファイルが含まれている。下層のサブディレクトリは、ファイルの種類ごとに分類され、たとえば３Ｄモデル用のサブディレクトリ、テクスチャ用のサブディレクトリ、スクリプト用のサブディレクトリなどが形成されている。

図３は、ゲームソフトウェアのファイル構成の概念図を示す。本実施例のゲームソフトウェア７０の本体は複数のファイルによって構成され、図示されるように複数のグループ７２に論理的に分割される。各ファイルは複数のグループ７２のうち少なくとも１つのグループに属し、また各グループ７２には少なくとも１つのファイルが属している。図３に示すゲームソフトウェア７０には、先頭グループとして第１グループ７２ａが存在し、それに後続するグループとして第２グループ７２ｂ、第３グループ７２ｃ、第４グループ７２ｄ、第５グループ７２ｅ、第６グループ７２ｆが存在している。なお第６グループ７２ｆに後続する７番目以降のグループ７２が存在していてもよい。各グループは、第１、第２などのグループ番号によって識別される。

論理的に分割された各グループには、複数のサブディレクトリに含まれるファイルが属し、すなわち各グループは、種類の異なるファイルによって構成され、情報処理装置１０がゲーム中のシーンやステージなどの特定の単位を実行するのに必要なファイルが属するように設定されている。

第１グループ７２ａには、ゲームソフトウェア７０の起動に必要なプログラムファイルおよびデータファイルが属している。したがって情報処理装置１０は、ゲームソフトウェア７０をコンテンツサーバ１２やストアサーバ１６から取得する場合、第１グループ７２ａに属する全てのファイルをダウンロードすれば、後続の第２グループ７２ｂ以降のファイルをダウンロードしなくても、ただちにゲームソフトウェア７０を起動することが可能となる。なお情報処理装置１０は、第１グループ７２ａに属する全てのファイルを取得して、ゲームソフトウェア７０を起動した後に、後続のグループ７２に属するファイルをバックグランドでダウンロードする。このようにゲームの実行に必要な最低限のファイルをまず最初にダウンロードさせ、それらのファイルが揃った時点でゲームを実行可能とすることで、ユーザのダウンロード待ち時間を短くすることが可能となる。なお、本実施例においては、ＲＯＭ媒体４４に記録されるゲームソフトウェア７０も、コンテンツサーバ１２などからダウンロードされるゲームソフトウェア７０も、同じファイルおよびディレクトリ構成をもつデータ構造を有している。

図４は、ゲームソフトウェアの具体的なファイル構成例を示す。第１グループ７２ａは、ゲームソフトウェア７０の中で一番最初にダウンロードされるべきファイル群で構成されており、ここではゲームパラメータファイル、グループファイル、起動ファイルおよび必須リソースファイルが示されている。

ここでゲームパラメータファイルは、情報処理装置１０のＯＳが使用するファイルであり、たとえばタイトルＩＤやディスプレイ解像度などの情報、またアイコン画像データなどを含んでいる。

グループファイルは、各ファイルがどのグループに含まれるかを記述する定義ファイルである。たとえばグループファイルはＸＭＬで表現されてよいが、他のプログラム言語によって表現されてもよく、その形式は問わない。グループファイルについては、図５、図６に関して後述する。

起動ファイルは、ゲームプログラムを起動するためのプログラムである。また必須リソースファイルは、ゲーム実行に必須となるプログラムなどのリソースファイルやゲーム全体で使用する共通ファイルなどを含む。

情報処理装置１０は、ゲームソフトウェア７０をコンテンツサーバ１２などからダウンロードする場合、第１グループ７２ａに属するファイル群を全て取得すれば、ゲームを起動することができる。逆に言えば、第１グループ７２ａは、ユーザがゲームの一部をプレイするために必要なファイル群を含むように構成されている。なお、ここでいうゲームプレイは、たとえばユーザがキャラクタを決定したり、ゲームレベルを決定するなど、ゲーム開始時に行う設定行動も含むものであってよい。つまり第１グループ７２ａは、ゲームを起動し、ユーザが少なくとも何らかの動作を行える状態にするために必要なファイル群を含んで構成されている。第１グループ７２ａに含まれるファイル群を用いて実行可能となるゲームプレイは、たとえばゲームの初期設定だけであってもよく、またゲームの第１ステージまでプレイ可能とするものであってもよい。これはゲームメーカ次第である。

図４に示す例では、第２グループ７２ｂには、シーン１用の複数のリソースファイルが属しており、第３グループ７２ｃには、シーン２用の複数のリソースファイルが属しており、第４グループ７２ｄには、シーン３用の複数のリソースファイルが属している。具体的に複数のリソースファイルは、特定のシーン用の３Ｄモデルファイル、テクスチャファイル、スクリプトファイルなどであり、ディレクトリ構造の複数のサブディレクトリに含まれるファイルを含む。また第１０グループ７２ｋには、英語用のリソースファイルが属しており、また第１１グループ７２ｌには、日本語用のリソースファイルが属している。

近年のゲームは、言語が異なる複数の国で実行可能に作成されているものが多い。音声データおよび画像データは、複数の言語に対応して作成され、複数言語の音声ファイルおよび画像ファイルが、１つのパッケージソフトウェアに収められている。以下、このようなファイルを「言語依存」ファイルと呼ぶこともあるが、音声ファイルおよび画像ファイルは、基本的にデータサイズが大きくなる傾向があり、このような言語依存ファイルのデータサイズは、ゲームソフトウェア全体のデータサイズに対して、かなりの割合を占めることがある。そこで本実施例のゲームソフトウェア７０は、必要な言語依存ファイルのみを取得できるように、言語ごとに音声ファイルおよび画像ファイルを集合させた言語用のリソースファイルのグループを含むようにしている。

図５は、グループとファイルの関係の一例を示す。ここでは、ファイルＡ〜Ｎが、各グループ７２に属していることが示される。図示されるように、各ファイルは複数のグループ７２のうち少なくとも１つのグループに属し、また各グループ７２には少なくとも１つのファイルが属している。なおファイルＧは、第２グループ７２ｂ、第３グループ７２ｃおよび第４グループ７２ｄに属している。このことは、ファイルＧが、ゲーム中のシーン１、シーン２、シーン３を構成する上で必要なファイルであることを意味し、このように１つのファイルが、複数のグループに所属することもある。なお同様にファイルＫも、複数のグループ７２、すなわち第４グループ７２ｄおよび第５グループ７２ｅに属している。

図６は、グループファイルの一例を示す。既述したように、グループファイルはＸＭＬによって表現されてもよく、他のプログラム言語によって表現されてもよい。図６には、理解を容易にするために、グループとファイルの対応関係をテーブル形式で表現したグループファイルを示している。情報処理装置１０は、ゲームソフトウェア７０の各ファイルをダウンロードする際に、グループファイルを参照して、あるグループに属するファイルが全て揃ったか、または揃ってないかを判定することが可能となる。たとえば第１グループ７２ａに関して言えば、情報処理装置１０はグループファイルを参照することで、第１グループ７２ａに属するファイルが、ファイルＡ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆであることを認識できるため、これらのファイルが補助記憶装置２に記録されていれば、第１グループ７２ａに属するファイルが全て揃ったことを判定する。

以上のように、ゲームソフトウェア７０は、様々なゲームファイルを含んで構成されている。以下、本実施例のゲームデータのデータ構造について説明する。本実施例では、ＵＮＩＸ（登録商標）で利用されるファイル管理手法を利用して、ゲームデータを構成する。ゲームデータは、上記したゲームソフトウェア７０の本体（複数のゲームファイルから構成される）と、メタデータとを少なくとも含んで構成される。

ファイルは、１または複数のブロックを割り当てられて構成される。ブロックは、ファイルシステムがデータを転送する基本単位であり、１つのブロックは所定のデータサイズ（たとえば６４ｋバイト）に設定される。そのため１２８０ｋバイトのファイルであれば、２０個のブロックを割り当てられることになる。各ファイルには、ファイルを構成する１以上のデータブロックの記録場所を格納するための索引表が設定される。

図７は、ゲームファイルのデータブロックのアドレッシングに使用されるデータ構造の参考例を説明するための図である。最初の１段目の索引表はｉｎｄｅｘ ｎｏｄｅ（略して「ｉノード」）と呼ばれ、データブロックのアドレッシング用に合計１５個のエントリを有する。全てのファイルはｉノードとデータブロックから構成され、ｉノードは、ファイルシステムにおいてファイルを識別するためのｉノード番号を付与されている。ｉノードは、属性情報として、ｉノード番号、ファイルの種類、ファイルのバイト長、アクセス権などを有している。

この参考例として示すデータ構造においては、ｉノードのエントリに、データブロックの記録場所を特定するための情報が記録されている。この情報は、たとえば記録ディスクもしくはパーティションの先頭からの相対位置を指定するブロック番号であってよい。なお、データブロックの記録場所を特定するための情報は、ブロック番号に限らず、たとえばブロック番号を算出するためのブロックサイズやファイルオフセットなどの情報であってもよい。またデータブロックの記録場所を特定するための情報は、直接的に記録場所を特定する記録ディスクのセクタ番号であってもよい。

ファイル名と、そのファイルを管理するｉノードのｉノード番号（ｉノードへのポインタとしての意味をもつ）は、ディレクトリのデータブロックにおいて対応付けて保持されている。したがってゲームプログラムがファイルをファイル名で参照するとき、ＯＳのカーネルは、ディレクトリエントリの情報を参照して、そのファイル名に対応するｉノード番号を取得し、ｉノード番号で特定されるｉノードに含まれるブロック番号を用いて、ファイルにアクセスする。

ｉノードの１２個のエントリは、ファイル内の先頭から１２個までのデータブロックのブロック番号を記録するために使用される。したがってファイルが１２個以内のデータブロックで構成されていれば、ｉノードは、ブロック数分のエントリを用いて各データブロックのブロック番号を記録できる。

なお、ファイルが１３個以上のブロックで構成されていると、複数段の索引表が必要となる。図７に示す例では、ｉノードの１３番目のエントリには、２段目の索引表（インダイレクトブロック）のブロック番号が記録され、ｉノードの１３番目のエントリが、インダイレクトブロックにリンクして、１段階目の間接参照に利用される。インダイレクトブロックは、固定のデータサイズを有して、２５６個のエントリを有している。インダイレクトブロックのエントリには、２段目のデータブロックのブロック番号が記録される。

ｉノードの１４番目のエントリには、３段目の索引表（ダブルインダイレクトブロック）をリンクするための２段目の索引表（インダイレクトブロック）のブロック番号が記録されている。インダイレクトブロックのエントリには、ダブルインダイレクトブロックのブロック番号が記録されている。ダブルインダイレクトブロックは、２５６個のエントリを有しており、そのエントリには、３段目のデータブロックのブロック番号が記録されている。このようにｉノードの１４番目のエントリは、２段階目の間接参照に利用される。

ｉノードの１５番目のエントリには、４段目の索引表（トリプルインダイレクトブロック）をリンクするための３段目の索引表（ダブルインダイレクトブロック）をリンクするための２段目の索引表（インダイレクトブロック）のブロック番号が記録されている。インダイレクトブロックのエントリには、ダブルインダイレクトブロックのブロック番号が記録されている。ダブルインダイレクトブロックのエントリには、トリプルインダイレクトブロックのブロック番号が記録されている。トリプルインダイレクトブロックは、２５６個のエントリを有しており、そのエントリには、４段目のデータブロックのブロック番号が記録されている。このようにｉノードの１５番目のエントリは、３段階目の間接参照に利用される。
以下、２段目以降の索引表（つまりｉノード以外の索引表）を、まとめてｉｎｄｉｒｅｃｔ Ｂｌｏｃｋ（インダイレクトブロック）と呼ぶこともある。

参考例として示すゲームファイルのデータ構造においては、索引表の各エントリに、ブロック番号とともに、データブロックに含まれるデータのハッシュ値も格納される。ハッシュ値はたとえば３２バイトのデータ値であり、データブロックを登録するエントリにデータブロック内のデータのハッシュ値を記録することで、ブロックのデータが読み出される際に、そのデータが正しいデータであるか否かを検証できるようにし、またデータの改ざんを防止することも可能となる。

上記したように、インダイレクトブロックは固定のデータサイズを有しており、索引表としてインダイレクトブロックが使用される場合には、固定長の領域を確保する必要がある。たとえば１つのゲームファイルのブロック数が２０個である場合、ｉノードの１２個のエントリと、２段目のインダイレクトブロックの８個のエントリに、データブロックが登録されて、各エントリに、それぞれのブロック番号とハッシュ値とが記録されることになるが、その結果、２段目のインダイレクトブロックの残りの２４８（＝２５６−８）個のエントリは空であり、メタデータとして寄与しない無駄な領域となる。

ゲームソフトウェア７０の本体は、複数たとえば１００００個を超えるゲームファイルを含んで構成されている。このファイルシステムでは、ゲームファイルの読出しの目的のために、ｉノードおよびインダイレクトブロックに記録されたメタデータは全て、ＤＤＲ３などのメモリ上に展開される。なおメモリ上には、ゲームファイルも可能な限り読み出すことが好ましく、したがってメタデータのデータサイズは、できるだけ小さいことが好ましい。

しかしながら上記したように、インダイレクトブロックのエントリに空データが多く存在すると、その空データもメモリ上に展開されることになり、結果としてメモリ容量を圧迫することになる。特に、１００００個を超えるファイルが存在するようなゲームソフトウェア７０では、各ファイルの索引表を用意することで、空データを含むメタデータが１Ｇバイトを超えることも生じうる。

図８は、ゲームデータのデータ構造の参考例を示す。この参考例で示されるデータ構造は、複数（たとえば１００００個）のゲームファイルを含むゲームデータ領域２０２に、スーパブロック、ｉノードリストおよび複数（Ｎ個）のインダイレクトブロックを含むメタデータ領域２００を付加した構造をとる。スーパブロックには、ゲームデータ領域２０２に含まれるファイルの管理情報が記録され、ブロックサイズ、総ブロック数などのメタデータが含まれる。ｉノードリストは、ｉノードを、少なくともゲームデータ領域２０２に含まれるファイル数分（たとえば１００００個）含んでいる。（なお正確には、このファイルシステムでは、ディレクトリやファイル名も１つのファイルとして扱われるため、ｉノードリストには、ディレクトリやファイル名に関するｉノードも含まれることになる。）

インダイレクトブロックは、ｉノードの１２エントリでデータブロックを登録しきれなかったファイルに関して設けられる。この参考例においては、既述したように、ｉノードおよびインダイレクトブロックのエントリに、ブロック番号と、データブロックに含まれるデータのハッシュ値が含まれている。

そのためゲームデータ領域２０２に１００００個のファイルが含まれる場合には、インダイレクトブロックが多数存在することになり、インダイレクトブロックの中には上記したように、エントリのほとんどが空データを含むものも存在する。そのためメタデータ領域２００のデータサイズは不必要に大きくなり、ゲームプログラムの実行中、メタデータ領域２００に含まれるメタデータをメモリに展開することは、メモリの効率的な使用の観点から好ましくない。

そこで本実施例のゲームデータは、各ファイルのブロックごとにハッシュ値をもつデータ構造ではなく、メタデータのデータサイズを可能な限り小さくしたデータ構造をとるようにする。具体的には、署名（ハッシュ値）無しの複数のファイルを１まとめにした完全平文のイメージファイルを作成し、このイメージファイルに対して、メタデータを付加したゲームデータを作成する。なおイメージファイルとは、ファイルシステムの構造や制御情報などを含んで１つのファイルとして構成されるものを意味する。

このゲームデータのデータ構造では、複数のファイルを記録媒体上の連続した場所（ブロック）に記録する。これにより各ファイルの記録場所は、先頭位置とファイルサイズとをメタデータとしてｉノードのエントリに保持しておくことで、特定されることが可能となるため、各データブロックごとのブロック番号などの記録場所を特定するための情報をもつ必要がなくなる。また、データブロックごとの署名をしないことで、各ファイルのメタデータとしてデータブロックごとのハッシュ値をもつ必要がなくなるため、各ファイルのメタデータは、ｉノードのエントリに収めることができるようになる。つまりブロックごとのハッシュ値を生成せず、さらにデータブロックを連続した番号のブロックに記録することで、インダイレクトブロックを必要とせずにすみ、メタデータのデータサイズを大幅に削減することが可能となる。

図９は、ゲームデータの作成方法を示すフローチャートである。このフローチャートに示すステップは、ゲームメーカにおいて、最終的なゲームパッケージソフトウェアを作成する過程を表現しており、パッケージ作成ソフトウェアにより実現される。まずパッケージ作成ソフトウェアは、平文（圧縮なし、暗号化なし、署名なし）のゲームデータのイメージファイルを作成する（Ｓ１０）。既述したように、イメージファイルは、ファイルシステムの構造や制御情報などを含んだ１つのファイルとして構成される。

図１０（ａ）は、本実施例のゲームデータの完全平文のイメージファイルの一例を示す。このイメージファイル２１０は、複数（たとえば１００００個）のファイルを含むゲームデータ領域２０２に、スーパブロック、ｉノードリスト、スーパルートディレクトリおよびフラットパステーブルを含むメタデータ領域２０４を付加したデータ構造をとる。スーパルートディレクトリおよびフラットパステーブルについては後述する。スーパブロックには、ゲームデータ領域２０２に含まれるファイルの管理情報が記録され、ブロックサイズ、総ブロック数などのメタデータが含まれる。

ゲームデータ領域２０２に含まれる複数のゲームファイルには、連続した番号をもつ論理的なブロックが割り当てられている。ゲームデータ領域２０２に含まれる複数のゲームファイルに割り当てるブロックを整列することにより、１つのゲームファイルは、そのファイルが割り当てられた先頭のブロック番号と、ファイルのデータサイズとによって、記録媒体における格納場所を特定することが可能となる。そのためゲームファイルのｉノードは、そのファイルの先頭のブロック番号と、ファイルのデータサイズとを記録しておくことで、ファイルの記録場所を特定する。これにより、ＯＳが、ゲームファイルにアクセスする際には、ゲームファイルのｉノード番号を取得することで、ゲームファイルの記録場所を知ることができる。

ゲームデータ領域２０２に記録されるゲームファイルは署名されないため、各ブロックごとのハッシュ値は存在しない。したがってファイルのメタデータを記録するためのインダイレクトブロックを用意する必要がなく、ファイルのメタデータは、ｉノードの１エントリに収めることが可能となる。そのためメタデータ領域２０４において、ｉノードリストは、ゲームデータ領域２０２におけるファイル数分のｉノードを含む一方で、図８と比較して明らかなように、ファイルに関する複数のインダイレクトブロックはメタデータ領域２０４に含まれない。なお既述したように、このファイルシステムではディレクトリやファイル名も１つのファイルとして扱われるため、ｉノードリストには、ディレクトリやファイル名に関するｉノードも含められることになるが、この場合にも、ディレクトリやファイル名は署名されないため、インダイレクトブロックを用意する必要がない。

図８に示すメタデータ領域２００と比較すると、図１０（ａ）に示すメタデータ領域２０４は、インダイレクトブロックを含まないために、そのデータサイズを大きく削減できている。そのためゲームプログラムの実行時、メタデータ領域２０４に含まれるメタデータをＤＤＲ３などのメモリに読み出しても、小さなデータサイズで済むことになる。

図９に戻り、パッケージ作成ソフトウェアは、図１０（ａ）に示す平文のイメージファイル２１０を圧縮する（Ｓ１２）。図１０（ｂ）は、圧縮したイメージファイルの一例を示す。パッケージ作成ソフトウェアは、圧縮したイメージファイル２１２に、連続した番号をもつ論理的なブロックを割り当てる。圧縮イメージファイル２１２においては、圧縮前と圧縮後のファイルのブロックの関係を示す圧縮テーブルが、メタデータ領域２０４に書き込まれる。圧縮テーブルでは、そのヘッダ部分に圧縮前の平文のイメージファイル２１０のサイズが記述され、またテーブル部分に圧縮前のブロック番号と、圧縮後のブロック番号および圧縮後のブロック番号のブロック内でのオフセット位置とが対応付けられて記述されている。このように圧縮することで、ゲームデータ領域２０６のデータサイズは、ゲームデータ領域２０２のデータサイズと比較して小さくなっている。

図１０（ａ）および図１０（ｂ）に示すイメージファイル２１０、２１２は、このままでも、ゲームデータのイメージファイルとして使用されることが可能である。すなわち情報処理装置１０において、ＯＳは、イメージファイル２１０または２１２をゲームを実行するための所定のマウントポイント（以下、実行マウントポイントと呼ぶ）にマウントすると、起動ファイルが起動されて、ゲームプログラムが実行されることになる。このとき、メタデータ領域２０４のデータサイズは、インダイレクトブロックを含まずに小さくできているため、メモリ上にメタデータを効率的に展開できる。

しかしながら、イメージファイル２１０、２１２は署名されていないため、ブロックのデータが読み出される際に、そのデータが正しいデータであるか否かを検証することができず、またデータの改ざんを効果的に防止できないという欠点がある。そこで本実施例では、アーカイブ形式のイメージファイル２１２を１つのファイルとして扱って署名を行い、さらには暗号化も行って、セキュアなゲームデータを作成する。なお、ゲームデータ全体のデータサイズを小さくするためにイメージファイル２１２に対して署名および暗号化を施すこととしたが、圧縮前のイメージファイル２１０に対して署名および暗号化を施して、セキュアなゲームデータを作成してもよい。

パッケージ作成ソフトウェアは、圧縮したイメージファイル２１２を１つのファイルと見立てて、連続した番号をもつ論理的なブロックを割り当てる。パッケージ作成ソフトウェアは、圧縮イメージファイル２１２を構成する複数のブロックのそれぞれに署名を行い、具体的には各ブロックデータのハッシュ値を求め、イメージファイル２１２にメタデータとして付加する（Ｓ１４）。なおパッケージ作成ソフトウェアは、ゲームデータのセキュリティを高めるために、作成したメタデータに署名を行い、さらにメタデータおよびゲームデータ本体に暗号化処理を行ってもよい。

図１１は、本実施例のゲームデータのデータ構造の一例を示す。このデータ構造をもつゲームデータは、パッケージファイル２１４としてＲＯＭ媒体４４に記録され、またはパッケージファイル２１４としてコンテンツサーバ１２やストアサーバ１６から情報処理装置１０にダウンロードされて、補助記憶装置２に記録される。

図１１に示されるように、パッケージファイル２１４は、イメージファイル２１２をネストしたデータ構造をもつ。本実施例のデータ構造は、１つのファイルとして取り扱われるイメージファイル２１２に、スーパブロック、ｉノードリスト、複数（Ｍ個）のインダイレクトブロック、スーパルートディレクトリおよびフラットパステーブルを含むメタデータ領域２０８を付加した構造をとる。

スーパブロックには、イメージファイル２１２の管理情報が記録され、ブロックサイズ、総ブロック数などのメタデータが含まれる。ｉノードリストに含まれるイメージファイル２１２のｉノードおよび複数のインダイレクトブロックは、１つのファイルとして見立てたイメージファイル２１２を分割したブロック数分を少なくとも含むエントリに、イメージファイル２１２の各ブロックのハッシュ値を含むメタデータを記録する。このようにパッケージファイル２１４は、１または複数のブロックを割り当てられたファイルを複数含み且つそれらのファイルのメタデータを含むゲームデータのイメージファイル２１２に、当該イメージファイル２１２を構成する複数のブロックのそれぞれに行った署名（ハッシュ値）を少なくとも含むメタデータが付加されたデータ構造を有して構成される。なお既述したように、イメージファイル２１２に含まれる各ファイルのブロックには、署名が行われていない。

記録媒体（ＲＯＭ媒体４４または補助記憶装置２）に記録されたパッケージファイル２１４は、イメージファイル２１２をネストしたデータ構造を有しているため、ＯＳのカーネルは、パッケージファイル２１４を２度マウントすることで、ゲームデータ領域２０２に含まれる各ファイルにアクセスできるようになる。

第１段階のマウント処理では、カーネルが、パッケージファイル２１４を第１のマウントポイントにマウントして、パッケージファイル２１４のファイルシステムを認識できるようにする。具体的にカーネルは、パッケージファイル２１４のメタデータ領域２０８に含まれるメタデータを利用して、イメージファイル２１２を認識できるようにし、これによりイメージファイル２１２を１つのファイルとして見ることができるようになる。このマウント機能は、カーネルが第１のマウント処理部として動作することによって実現される。

第２段階のマウント処理では、カーネルがイメージファイル２１２を、ゲームプログラムを実行するための第２のマウントポイント（実行マウントポイント）にマウントして、イメージファイル２１２のファイルシステムを認識できるようにする。具体的にカーネルは、イメージファイル２１２のメタデータ領域２０４に含まれるメタデータを利用して、ゲームデータ領域２０６を認識できるようにし、これによりゲームデータ領域２０６に含まれる複数（たとえば１００００個）のゲームファイルにアクセス可能となる。このマウント機能は、カーネルが第２のマウント処理部として動作することによって実現される。なお、第１段階のマウント処理における第１のマウントポイントは、第２段階のマウント処理における第２のマウントポイントと同じであってもよく、また異なっていてもよい。

第２段階のマウント処理を経て、カーネルは、起動ファイルを実行する。なお起動ファイルについてはゲームデータ領域２０６において圧縮が施されておらず、したがってカーネルは、起動ファイルをそのまま起動できる。イメージファイル２１２のメタデータ領域２０４のデータサイズは小さいため、メタデータを効率的にＤＤＲ３などのメモリに展開することができる。

以下、メタデータとしてイメージファイル２１０または２１２のメタデータ領域２０４に含まれるフラットパステーブルについて説明する。
本実施例のＵＮＩＸで利用されるファイル管理手法では、既述したようにディレクトリやファイル名もファイルの一種として取り扱われるため、ディレクトリやファイル名も１つのブロックに割り当てられて記録される。たとえば、「ｕｓｅｒ／ＡＡＡ／ＢＢＢ／ＣＣＣ／ファイル名」というディレクトリ構造があった場合、それぞれのディレクトリ名、ファイル名に対して１ブロックずつ割り当てられて、合計で５ブロックが必要となる。

特に、ゲームデータのファイル数が多くなると、ディレクトリの数も多くなる。既述したように、ファイルのｉノードは、メタデータとしてＤＤＲ３などのメモリに読み出される必要があるため、可能な限りメタデータの容量を小規模化することが好ましい。そこで本実施例のデータ構造では、上記の例で示した（ｕｓｅｒ／ＡＡＡ／ＢＢＢ／ＣＣＣ／ファイル名）のフルパスの情報をメタデータとしては利用せず、メタデータ容量を削減する目的でフラットパステーブルを利用する。

フラットパステーブルは、ゲームファイルのフルパス情報のハッシュ値と、ゲームファイルの記録位置を特定するための情報とを対応付けた対応ファイルとして構成される。フラットパステーブルは、ゲームプログラムから読み出される可能性のある全てのゲームファイルのフルパス情報のハッシュ値と、そのゲームファイルの記録位置を特定するための情報とを対応付けて記録することが好ましい。ここで、ファイルの記録位置を特定するための情報は、記録媒体に記録されたファイルを一意に特定するｉノード番号であってよい。したがって本実施例のフラットパステーブルでは、たとえばフルパス（ｕｓｅｒ／ＡＡＡ／ＢＢＢ／ＣＣＣ／ファイル名）のハッシュ値と、当該ファイルのｉノード番号とが対応付けられて記録される。ＯＳにおけるファイル読出ＡＰＩ（Application Programming Interface）は、ゲームプログラムがフルパス情報を含むファイル読出要求を出力すると、逐次、フルパスのハッシュ値を求めて、そのハッシュ値から、フラットパステーブルにおけるｉノード番号を探索し、ファイルを構成するブロックを特定するようにする。

図１２（ａ）は、フラットパステーブルの一例を示す。フラットパステーブル２２０では、各フルパス情報のハッシュ値と、そのフルパス情報に対応するｉノード番号とが対応付けて記録される。ここでハッシュ値は、たとえば４バイトの値として構成され、したがってフルパス情報のハッシュ値は、フルパス情報のデータ量と比較して、非常に小さく構成できる。フラットパステーブル２２０において、フルパス情報のハッシュ値は降順に並べられており、ここでは説明の便宜上、ハッシュ値を１６進数で表現している。

一方で、ハッシュ値を採用することで、複数のフルパス情報のハッシュ値が同じになることが生じうる。これは一般に「ハッシュ値の衝突」と呼ばれるものであるが、フラットパステーブル２２０では、フルパス情報をデータ量の小さいハッシュ値に置換しているために、ハッシュ値同士の衝突が生じうる。その場合、異なるｉノード番号に対応付けられた同じハッシュ値が並存することになるため、これらのハッシュ値を区別するために、フラットパステーブル２２０は、その付随ファイルとして、衝突ファイル２２２を定義する。

図１２（ｂ）は、衝突ファイルの一例を示す。衝突ファイル２２２は、ハッシュ値が衝突するフルパス情報に対して、ファイル名とファイルの記録位置を特定するための情報（ここではｉノード番号）とが対応付けて記録する。
図１２（ａ）のテーブル右項目における「ｉノード番号／オフセット」について説明する。この項目は、たとえば４バイトで表現されており、その上位ビットには、衝突の有無を示す情報が少なくとも設定されている。一例では、この情報は衝突フラグとして用意され、ここで衝突している場合には衝突フラグ１が、衝突していない場合には衝突フラグ０がセットされるものとする。

したがってフラットパステーブル２２０において、重複するハッシュ値が存在しないハッシュ値（非衝突ハッシュ値）については、上位ビットの衝突フラグが０に設定され、その下位ビットに、ｉノード番号が記述される。ＯＳにおけるファイル読出ＡＰＩは、ゲームプログラムがフルパス情報を指定したファイル読出要求を出力すると、フルパス情報のハッシュ値を求め、そのハッシュ値から、メモリ上に展開されているフラットパステーブルにおけるｉノード番号を探索する。このとき対応するハッシュ値が非衝突ハッシュ値であれば（すなわち衝突フラグが０に設定されていれば）、テーブル右項目に記述されているｉノード番号を特定して、ファイルを読み出す。

一方でフラットパステーブル２２０において、重複するハッシュ値が存在するハッシュ値（衝突ハッシュ値）については、上位ビットの衝突フラグが１に設定され、その下位ビットに、オフセット情報が記述されている。ここでオフセット情報は、衝突ファイルに対する記録位置のオフセットを示すものであり、衝突ファイルに含まれるデータが記述される最初の位置を特定する情報である。ＯＳにおけるファイル読出ＡＰＩは、ゲームプログラムがフルパス情報を指定したファイル読出要求を出力すると、フルパス情報のハッシュ値を求め、そのハッシュ値から、メモリ上に展開されているフラットパステーブルにおけるｉノード番号を探索する。このとき対応するハッシュ値が衝突ハッシュ値であれば（すなわち衝突フラグが１に設定されていれば）、オフセット情報から、衝突ファイルにアクセスして、衝突ファイルに記録されたデータを探索する。

たとえば読出要求されたフルパス情報のハッシュ値が“０１２Ｂ３４１Ｃ”であり、テーブル右項目において衝突フラグが１に設定されていると、読出ＡＰＩは、衝突ファイルを参照して、読出要求されたファイル名を探索する。図１２（ｂ）に示すように、衝突ファイルにおいては、ファイル名と、ｉノード番号とが対応付けて記録されており、読出ＡＰＩは、衝突ファイルの内部を探索して、ファイル読出要求されたファイル名を見つけ出す。衝突ファイルにおいては、ファイル名に対してｉノード番号が対応付けられているため、読出ＡＰＩは、ファイル名をもとに、ｉノード番号を特定して、ファイルを読み出すことができる。

このようにイメージファイル２１０または２１２において、メタデータ領域２０４に、フルパス情報の代わりに、フラットパステーブルおよび衝突ファイルを用意しておくことで、プログラム実行時にメモリに読み出すメタデータ量を削減できるようになる。

次にスーパルートディレクトリについて説明する。
図１３（ａ）は、通常のルートディレクトリおよび下層のサブディレクトリを示す。サブディレクトリは、ゲームプログラムの実行に必要なファイルの種類ごとに構成されている。カーネルは、ルートディレクトリを所定の実行マウントポイントにマウントすることで、ゲームプログラムを実行できる。

図１３（ｂ）は、本実施例で使用するスーパルートディレクトリおよび下層のサブディレクトリを示す。スーパルートディレクトリは、ルートディレクトリの上層に設定され、ルートディレクトリは、スーパディレクトリのサブディレクトリとなる。なお図１３（ｂ）に示すディレクトリ構造においても、カーネルが、スーパルートディレクトリをマウントすることで、ルートディレクトリの起動ファイルを実行できることには変わりないが、上層のスーパディレクトリを設けたことで、ルートディレクトリの下層を変更することなく、ルートディレクトリとは別に分岐したスーパディレクトリの下層に、サブディレクトリを容易に追加できるようになる。これにより、たとえばフラットパステーブルのファイルをスーパディレクトリの下層に配置できるようになり、拡張性に優れたファイルシステムを提供できる。

図１４は、ゲームデータに含まれるファイルにアクセスするファイルアクセス機能を実現するための構成を示す。情報処理装置１０は、受付部１００、ハッシュ値導出部１０２、ｉノード番号取得部１０４およびファイルアクセス部１０６を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされたプログラム、ストレージなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。ここで受付部１００、ハッシュ値導出部１０２およびｉノード番号取得部１０４の機能は、上記した読出ＡＰＩにより実現されてよい。

ゲームの実行中、受付部１００は、ゲームからファイルのフルパス情報を含む読出要求を受け付ける。ハッシュ値導出部１０２は、受け取ったフルパス情報のハッシュ値を所定のハッシュ関数により導出する。ｉノード番号取得部１０４は、対応ファイルとして構成されるフラットパステーブル２２０を参照し、ハッシュ値を用いて、ファイルの記録位置を特定するための情報、ここではｉノード番号を取得する。これによりファイルアクセス部１０６は、ｉノード番号を用いて、ゲームにより指定されたファイルにアクセスでき、当該ファイルを読み出す。

なお上記は、ハッシュ値導出部１０２が導出したハッシュ値が非衝突ハッシュ値である場合のファイルアクセス動作を示し、ｉノード番号取得部１０４は、導出したハッシュ値の衝突フラグが０に設定されている場合に、ハッシュ値が衝突していないことを判定して、フラットパステーブル２２０からｉノード番号を取得できる。

一方で、ハッシュ値導出部１０２が導出したハッシュ値が衝突ハッシュ値である場合には、ｉノード番号取得部１０４は、導出したハッシュ値の衝突フラグが１に設定されていることから、ハッシュ値が衝突していることを判定する。したがってｉノード番号取得部１０４は、当該ハッシュ値に対応付けられているオフセット情報から、衝突ファイル２２２にアクセスして、衝突ファイル２２２内で、フルパス情報で指定されたファイル名を探索する。衝突ファイル２２２において、ファイル名を見つけると、ｉノード番号取得部１０４は、ファイル名に対応付けられたｉノード番号を取得する。このようにｉノード番号取得部１０４は、ハッシュ値導出部１０２が導出したハッシュ値が衝突するものである場合に、衝突ファイル２２２を参照して、ファイル名からｉノード番号を取得する。これによりファイルアクセス部１０６は、ｉノード番号を用いて、ゲームにより指定されたファイルにアクセスでき、当該ファイルを読み出す。

以上のようにファイルアクセス部１０６は、ｉノード番号を用いてファイルにアクセスするが、本実施例の情報処理装置１０においては、ファイルを記憶する記憶部として、バッファとして動作するメモリ（たとえばＤＤＲ３）、補助記憶装置２およびＲＯＭ媒体４４が存在している。ＲＯＭ媒体４４はメディアドライブ３２に装着されてデータの読出を行われるものであるが、ここで、メモリと、補助記憶装置２と、メディアドライブ３２のデータ読出速度をそれぞれ比較すると、この順にデータ読出速度が高速となる。

この意味において本実施例では、メモリを高速デバイス、補助記憶装置２を中速デバイス、メディアドライブ３２を低速デバイスと呼ぶ。以下において、このデータ読出速度の違いに着目したファイルアクセス処理を高速にする仕組みについて説明する。

なお、高速化の仕組みを説明する前に、情報処理装置１０は、ＲＯＭ媒体４４に記録されたゲームソフトウェア７０の実行中に、ＲＯＭ媒体４４に記録されたゲームソフトウェア７０を補助記憶装置２にコピーする機能を有しており、まずは、このコピー機能について説明する。

図１５は、ファイル管理機能を実現するための構成を示す。情報処理装置１０は、ファイルアクセスを行うファイルアクセス部１０６と、ファイル管理を行うファイル管理部１０８を備える。ファイル管理部１０８は、ＲＯＭ媒体４４から補助記憶装置２にゲームソフトウェア７０をコピーする機能も有する。情報処理装置１０は、ファイルを記憶する記憶部１２０として、高速デバイスであるメモリ１１０、中速デバイスである補助記憶装置２、低速デバイスであるメディアドライブ３２を有する。メモリ１１０は、補助記憶装置２またはメディアドライブ３２と接続して、これらから読み出されるデータを一時的に記憶する役割をもつ。なおファイルアクセスを高速化するために、メモリ１１０には、図１０に示すメタデータ領域２０４に含まれるメタデータが予め展開されている。

図１４に関連して説明したように、ファイルアクセス部１０６は、ｉノード番号を用いて、ゲームによりフルパス情報で指定されたファイルにアクセスして、当該ファイルのデータを読み出す。具体的にファイルアクセス部１０６は、ｉノード番号により特定されるＲＯＭ媒体４４の記録領域からファイルデータをメモリ１１０に読み出し、メモリ１１０からファイルデータを取得して、ゲームプログラムに提供する。

図１６は、コピー処理の一例を説明するための図である。このコピー処理においては、ゲームプログラムが実行されていることが前提となる。ゲームプログラムがデータの読み出しを要求すると、ファイルアクセス部１０６が、メディアドライブ３２からＲＯＭ媒体４４に記録されたデータを読み出し、メモリ１１０が、読み出されたデータを一時的に記憶する（ＳＴ１）。ファイルアクセス部１０６は、メモリ１１０に記憶されたデータをゲームプログラムに提供する（ＳＴ２）。これによりゲームプログラムは、読み出しを要求したデータを用いてゲームを進行することができる。

このときファイル管理部１０８は、メモリ１１０に記憶されたデータを読み出し、補助記憶装置２に記録する（ＳＴ３）。このように、ゲームプログラムからの要求にしたがってメモリ１１０に読み出されたデータを、ゲームプログラムに提供するだけではなく、補助記憶装置２に記録することで、データを低速デバイスから中速デバイスにコピーすることが可能となる。補助記憶装置２にコピーされたデータは、ゲームプログラムにより次回必要とされたときに、補助記憶装置２からゲームに対して読み出される。

ファイル管理部１０８は、ＲＯＭ媒体４４から補助記憶装置２にコピーされたファイルを管理する。たとえばファイル管理部１０８は、１つのファイルに対して、コピーされたか否かを示す情報を、ビットマップとして管理してよい。なお本実施例において、ファイルは１以上のブロックから構成されており、したがってファイル管理部１０８は、ブロック単位で、コピーされたか否かを示す情報を管理することが好ましい。ファイル管理部１０８は、ＲＯＭ媒体４４から補助記憶装置２にデータブロックをコピーすると、ブロックビットマップ上において、対応するデータブロックがコピーされたことを示す情報（フラグ）を立てて、ブロックビットマップを更新する（ＳＴ４）。これによりファイル管理部１０８は、どのブロックがＲＯＭ媒体４４から補助記憶装置２にコピーされたかを知ることができる。

図１７は、記憶部１２０の各記憶部の記憶領域の状態を模式的に示す。上段は、高速デバイスであるメモリ１１０の記憶領域の状態、中段は、中速デバイスである補助記憶装置２の記憶領域の状態、下段は、低速デバイスであるＲＯＭ媒体４４の記憶領域の状態を示す。各記憶領域を模式的に示す横長矩形領域において、縦線で区切られている領域はブロックを表現し、ハッチングが施されたブロックは、記憶領域に記憶済みであることを表現している。

ここで上段に示すメモリ１１０にはメタデータ領域２０４のメタデータが記憶され、さらに、余った記憶領域に、一部のゲームデータが一時的に記憶されている。メモリ１１０の記憶領域は小さいために、メタデータ領域２０４に含まれるメタデータのサイズを可能な限り小さくすることで、ゲームデータを一時記憶するための領域を広げることが可能となる。なお、ここではメモリ１１０の記憶領域がフルに使用されているように示されているが、実際には、メモリ１１０における所定サイズの記憶領域を示すのであって、フルに使用するわけではない。

ブロックビットマップ（ブロックＢＭＰ）は、ファイル管理部１０８により管理されるビットマップ情報を示す。ファイル管理部１０８は、ＲＯＭ媒体４４から補助記憶装置２にコピーされたブロックにはフラグ値１を、コピーされていないブロックにはフラグ値０をセットして、ブロックＢＭＰを作成する。上記したように、ＲＯＭ媒体４４から補助記憶装置２へのブロックのコピーが行われる度に、ファイル管理部１０８は、ブロックＢＭＰを更新する。これによりファイル管理部１０８は、補助記憶装置２の最新の記憶状態を把握している。中段に示す補助記憶装置２の一例であるＨＤＤ（ハードディスクドライブ）には、コピー処理によってＲＯＭ媒体４４からコピーされたブロックデータが記録される。ハッチングが施されていないブロック領域は、まだブロックのデータがコピーされていないことを示している。

下段に示すＲＯＭ媒体４４の一例であるＢＤ（ブルーレイディスク）には、ゲームソフトウェアの全てのデータ（パッケージファイル２１４）が記録されているため、全ての記憶領域にハッチングが施されている。なおパッケージファイル２１４に含まれるゲームデータは、パッケージファイル２１４が実際には暗号化されたり圧縮されていることで、イメージファイル２１０のゲームデータ領域２０２のゲームデータとは異なるブロックが対応する。図１７においては、復号後および／または圧縮解凍後のブロックが仮想的に表現されているのであって、各記憶領域の縦方向に重なるブロックは、同じブロックを示している。

図１５に戻って、ファイルアクセス部１０６は、ファイル管理部１０８において管理されている記憶部１２０の各記憶状況をもとに、アクセスする記憶媒体を決定する。あらためて記憶部１２０におけるメモリ１１０、補助記憶装置２、ＲＯＭ媒体４４のゲームデータの記憶状況について説明する。

（１）メモリ１１０における記憶状況
メモリ１１０には、メタデータ領域２０４におけるメタデータの全てが記憶されている。これによりファイルアクセス部１０６は、記録媒体に記録されているメタデータをシークして探索する必要がなく、メモリ１１０に展開されたメタデータを参照して、ゲームから読出要求のあったファイルのｉノード番号を高速に特定できるようになる。またメモリ１１０には、ゲームデータの一部も一時的に記憶されている。このゲームデータは、必要に応じて随時更新される。ファイル管理部１０８は、メモリ１１０における記憶状況を管理し、どのブロックのデータが記憶されているかを把握している。

（２）補助記憶装置２における記憶状況
補助記憶装置２には、ＲＯＭ媒体４４から一度メモリ１１０に読み出されたデータがコピーされて記憶されている。なお上記したコピー処理においては、ゲームから読出要求を受けてメモリ１１０に読み出されたデータをコピーすることを説明したが、たとえば、ゲームからの読出要求がない場合であっても、ファイル管理部１０８が、バックグランドでＲＯＭ媒体４４から補助記憶装置２にゲームデータをコピーしてもよい。この場合、補助記憶装置２には、読出要求を受けたゲームデータだけでなく、それ以外のゲームデータも記憶されることになる。このようなコピー処理により、補助記憶装置２は、ＲＯＭ媒体４４に記録されているゲームソフトウェアの全部または一部を記録している。ファイル管理部１０８は、補助記憶装置２における記憶状況をブロックビットマップによって管理し、どのブロックのデータが記憶されているかを把握している。

（３）ＲＯＭ媒体４４における記憶状況
ＲＯＭ媒体４４には、全てのメタデータおよびゲームファイルが記憶されている。

以上のコピー処理が行われている前提のもとで、ファイルアクセス部１０６は、ゲームからの読出要求に応じて、所定の優先順位にしたがって、ＲＯＭ媒体４４、補助記憶装置２またはメモリ１１０のいずれかからゲームデータをゲームに提供する。既述したようにファイル管理部１０８は、メモリ１１０および補助記憶装置２のゲームデータの記憶状況を管理しており、具体的にはファイル単位またはブロック単位で記憶状況を管理している。特に補助記憶装置２の記憶状況に関しては、各ブロックまたはファイルごとにコピー済みであるか否かを示す情報を設定したビットマップを用いて管理している。

所定の優先順位は、データ読出の速いデバイスが優先的に選択されるように設定される。具体的にファイルアクセス部１０６は、読出要求されたゲームデータがメモリ１１０に記憶されていれば、メモリ１１０からゲームデータをゲームに提供する。このときファイル管理部１０８は、補助記憶装置２の記憶状況を示すビットマップを参照する必要がない。

読出要求されたゲームデータがメモリ１１０に記憶されていない場合、ファイル管理部１０８は、ビットマップを参照して、当該ゲームデータが補助記憶装置２に記憶されているか確認する。当該ゲームデータが補助記憶装置２に記憶されていれば、ファイルアクセス部１０６は、補助記憶装置２からゲームデータをメモリ１１０に読み出して、ゲームに提供する。このようにファイルアクセス部１０６は、読出要求されたゲームデータがメモリ１１０に記憶されておらず、補助記憶装置２に記憶されていれば、補助記憶装置２からゲームデータをゲームに提供する。

ファイル管理部１０８によって、読出要求されたゲームデータがメモリ１１０および補助記憶装置２に記憶されていないことが判定されると、ファイルアクセス部１０６は、メディアドライブ３２に装着されたＲＯＭ媒体４４からゲームデータをメモリ１１０に読み出して、ゲームに提供する。なお、このときファイル管理部１０８は、ＲＯＭ媒体４４からメモリ１１０に読み出したゲームデータを補助記憶装置２にコピーし、ビットマップを更新する。これにより、次回、この同じゲームデータをゲームに提供する際には、ＲＯＭ媒体４４からではなく補助記憶装置２から提供することが可能となる。なお、このときメモリ１１０に当該ゲームデータが記憶されていれば、メモリ１１０からゲームに提供される。

このように、記憶部１２０における各記憶部を速度順に優先順位を定め、優先順位の高い記憶部に記憶されているゲームデータをゲームに対して提供することで、より高速なファイルアクセスが実現できる。

以上は、ＲＯＭ媒体４４のゲームデータを補助記憶装置２にコピーした場合のファイルアクセスについて説明した。次に、コンテンツサーバ１２やストアサーバ１６から、ゲームソフトウェアをダウンロードしたときのファイルアクセスについて説明する。

ゲームソフトウェアのダウンロード処理において、補助記憶装置２は、ゲームソフトウェアを構成する複数のファイルを格納するための記憶装置として利用される。図３〜図６に関して説明したように、ゲームソフトウェアにおいて、各ファイルは少なくとも１つのグループに所属しており、また各グループには少なくとも１つのファイルが所属している。

ダウンロード処理はグループ単位で実行され、たとえば、ファイルＸ，Ｙ，ＺがグループＳに属している場合、グループＳのダウンロード要求が生成された場合には、ファイルＸ，Ｙ，Ｚがコンテンツサーバ１２からダウンロードされて、グループＳに属する全てのファイルＸ，Ｙ，Ｚが補助記憶装置２に記録されるようになる。なお既にファイルＸがダウンロード済みである場合には、ファイルＹ，Ｚがコンテンツサーバ１２からダウンロードされて、これによりグループＳに属する全てのファイルＸ，Ｙ，Ｚが補助記憶装置２に記録されるようになる。

図３に示すように、ゲームソフトウェアのグループはグループ番号で特定することができる。グループ番号は１から降順に設定されており、ダウンロード処理部（図示せず）は、グループの１つの決定手法として、ダウンロードするグループの順番を、グループ番号順と同じく定めてもよい。つまりダウンロード処理部は、より番号の小さいグループを、より早い順番でダウンロードする対象として決定し、したがって第１グループ７２ａ、第２グループ７２ｂ、第３グループ７２ｃ・・・と、グループ番号順にダウンロードすることを決定し、その順番にしたがってグループに含まれるファイルをダウンロードする。

ダウンロード処理部は、グループ単位でダウンロード要求をコンテンツサーバ１２に送信し、コンテンツサーバ１２から送信されるゲームデータを補助記憶装置２に記録する。このときファイル管理部１０８は、グループ単位で、ファイルまたはブロックの記憶状況を管理する。ダウンロードするファイルは、圧縮且つ暗号化されたパッケージファイル２１４であるため、ファイル管理部１０８は、パッケージファイル２１４におけるゲームデータの記憶状況を示す第１ビットマップと、パッケージファイル２１４を復号して、圧縮解凍したときのゲームデータの記憶状況を示す第２ビットマップとを生成する。なお、この第２ビットマップは、ＲＯＭ媒体４４から補助記憶装置２へのゲームデータコピーに関して説明したビットマップと同じものである。ゲームデータコピーに関して説明したように、ファイル管理部１０８が、第２ビットマップを管理することで、ファイルアクセス部１０６は、効率的にファイルアクセスすることが可能になる。なおファイルアクセス部１０６が、第１ビットマップを管理することで、たとえばマウントされないファイルをダウンロードするような場合に、ファイル管理を適切に行うことが可能となる。

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

１・・・情報処理システム、２・・・補助記憶装置、１０・・・情報処理装置、３２・・・メディアドライブ、４４・・・ＲＯＭ媒体、７０・・・ゲームソフトウェア、１００・・・受付部、１０２・・・ハッシュ値導出部、１０４・・・ｉノード番号取得部、１０６・・・ファイルアクセス部、１０８・・・ファイル管理部、１１０・・・メモリ、１２０・・・記憶部、２００・・・メタデータ領域、２０２・・・ゲームデータ領域、２０４・・・メタデータ領域、２０６・・・ゲームデータ領域、２０８・・・メタデータ領域、２１０，２１２・・・イメージファイル、２１４・・・パッケージファイル、２２０・・・フラットパステーブル、２２２・・・衝突ファイル。

Claims (6)

1. 起動ファイルおよびプログラムファイルを含むゲームデータを処理する情報処理装置であって、当該ゲームデータは、１または複数のブロックを割り当てられたファイルを複数含み且つ各ファイルのメタデータを含むゲームデータのイメージファイルに、当該イメージファイルを構成する複数のブロックのそれぞれに行った署名を少なくとも含むメタデータが付加されて構成されており、
   署名を含むメタデータが付加されたイメージファイルを第１のマウントポイントにマウントして、イメージファイルを認識する第１マウント処理部と、
   認識したイメージファイルを第２のマウントポイントにマウントして、イメージファイルに含まれる複数のファイルを認識する第２マウント処理部と、
   を備えることを特徴とする情報処理装置。
2. 第２のマウントポイントは、プログラムファイルを実行するためのマウントポイントであることを特徴とする請求項１に記載の情報処理装置。
3. コンピュータにより実行されるプログラムファイルを含むゲームデータのデータ構造であって、
   １または複数のブロックを割り当てられたファイルを複数含み且つ各ファイルのメタデータを含むゲームデータのイメージファイルに、当該イメージファイルを構成する複数のブロックのそれぞれに行った署名を少なくとも含むメタデータが付加されており、
   イメージファイルに含まれるファイルのブロックには、署名が行われていないことを特徴とするゲームデータのデータ構造。
4. イメージファイルは圧縮されており、圧縮されたイメージファイルを構成する複数のブロックのそれぞれのハッシュ値を含むメタデータが、当該イメージファイルに付加されていることを特徴とする請求項３に記載のゲームデータのデータ構造。
5. コンピュータに、
   署名を含むメタデータが付加されたイメージファイルを第１のマウントポイントにマウントして、イメージファイルを認識する機能と、
   認識したイメージファイルを第２のマウントポイントにマウントして、イメージファイルに含まれる複数のファイルを認識する機能と、
   を実現させるためのプログラム。
6. 請求項５に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images