CN104615629A - 信息处理设备以及游戏数据的数据结构 - Google Patents

Abstract

一种用于处理包括启动文件和程序文件的游戏数据的信息处理设备，通过向游戏数据的图像文件添加元数据形成游戏数据，游戏数据的图像文件包括每个被赋予一个或多个块的多个文件，并且包括每一个文件的元数据，元数据包括附加于构成图像文件的所述多个块中的每一个块的签名。所述信息处理设备包括：第一安装处理部分，在第一安装点处安装将添加了包括签名的元数据的图像文件，并且识别所述图像文件；以及第二安装处理部分，在第二安装点处安装所识别的图像文件，并且识别在所述图像文件中包括的多个文件。

Description

信息处理设备以及游戏数据的数据结构

技术领域

本公开涉及一种游戏数据的数据结构、以及一种用于处理具有所述数据结构的游戏数据的信息处理设备。

在相关技术中，已经在以诸如光盘、磁光盘、蓝光盘等的ROM(只读存储器)介质的形式分发和销售包括游戏程序的游戏数据(游戏软件)。最近，由于英特网上的数据通信的速度提高，服务器经由英特网分发游戏数据的图像文件已经成为可能。

背景技术

游戏软件包括用于执行游戏的诸如启动文件、游戏程序等的资源文件组和游戏设备的OS(操作系统)所使用的文件组。由于游戏设备的硬件规范已经得以显著提高，所以在游戏软件中包括的文件的数目日益增多，而且数据的大小也不断增大。游戏软件包括多个游戏文件以及每一个文件的元数据。在游戏程序的执行期间，例如，为了标识存储文件的扇区，期望预先将元数据读出到存储器中，并且将其用于文件访问处理。由于存储器的大小有限，所以希望开发一种最小化元数据的数据大小的数据结构。

另外，扩展存储器中的元数据有助于文件访问的速度的增加。然而，以不同的速度从存储游戏文件的存储单元读出数据。众所周知，通常，慢速地从其中加载了ROM介质的媒介驱动器中读出数据，高速地从DRAM(动态随机存取存储器)读出数据。因此，在将游戏文件存储在多个存储单元中的情况下，希望开发一种进行有效文件访问的技术。

根据本公开的一种模式的一种信息处理设备是一种用于处理包括启动文件和程序文件的游戏数据的信息处理设备，通过向游戏数据的图像文件添加元数据来形成游戏数据，游戏数据的图像文件包括每个被赋予一个或多个块的多个文件并且包括每一个文件的元数据，元数据包括附加于构成图像文件的所述多个块中每一个块的签名。所述信息处理设备包括：在第一安装点处安装将包括添加了签名的元数据的图像文件，并且识别图像文件的第一安装处理部分；以及在第二安装点处安装所识别的图像文件，并且识别在图像文件中包括的多个文件的第二安装处理部分。

本公开的另一种模式是一种游戏数据的数据结构。所述游戏数据的数据结构是一种包括计算机所执行的程序文件的游戏数据的数据结构，其中，向游戏数据的图像文件添加元数据，游戏数据的图像文件包括被赋予了一个或多个块的多个文件并且包括每一个文件的元数据，元数据包括附加于构成图像文件的所述多个块中每一个块的签名，并且未将签名附加于在图像文件中包括的文件的块。

应该注意的是，作为本公开的模式，将本公开的各种表示转换为其的以上所描述的各种构成成分以及方法、设备、系统、记录媒介、计算机程序等也是高效的。

根据本公开的信息处理技术，可以实现一种舒适地玩游戏的环境。

附图说明

图1是描述了根据本公开的一个实施例的信息处理系统的图；

图2是示出信息处理设备的功能块的图；

图3是描述了游戏软件的文件配置的概念图；

图4是描述了游戏软件的文件配置的具体示例的图；

图5是描述了组与文件之间的关系的一个示例的图；

图6是描述了组文件的一个示例的图；

图7是辅助解释了文件空间分配的一个示例的图；

图8是描述了数据结构的游戏数据的一个参照示例的图；

图9是游戏数据创建方法的流程图；

图10A是描述了游戏数据的完全纯文本图像文件的一个示例的图，图10B是描述了压缩的图像文件的一个示例的图；

图11是描述了根据本实施例的游戏数据的数据结构的一个示例的图；

图12A是描述了平路径表的一个示例的图，图12B是描述了冲突文件的一个示例的图；

图13A是描述了普通根目录和低层子目录的图，图13B是描述了超级目录和低层子目录的图；

图14是描述了用于实现文件访问功能的配置的图；

图15是描述了用于实现文件管理功能的配置的图；

图16是辅助解释了拷贝处理的示例的图；以及

图17是示意性地描述了存储单元的存储区域的状态的图。

具体实施方式

图1描述了根据本公开的实施例的信息处理系统1。信息处理系统1包括信息处理设备10、网络服务器5、用于分发数字内容的内容服务器12、以及用于销售数字内容的商店服务器16。经由诸如英特网、LAN(局域网)等的网络3将信息处理设备与服务器互相连接。由数字内容的制造商、发行商等维护和管理内容服务器12。

访问点(以下将其称为“AP”)8具有无线访问点和路由器的功能。将信息处理设备10经由无线电或者有线地连接于AP8，从而按照与网络服务器5、内容服务器12、以及商店服务器16进行通信的方式，将其连接于网络3上的网络服务器5、内容服务器12、以及商店服务器16。

经由无线电或者有线地将信息处理设备10连接于用户操作的输入设备6。输入设备6将表示用户进行的操作的结果的操作信息输出于信息处理设备10。当从输入设备6接收到操作信息时，信息处理设备10反射OS(操作系统)或者应用软件的处理中的操作信息，并且使处理的结果从输出设备4输出。在信息处理系统1中，信息处理设备10是用于执行游戏软件的游戏设备。输入设备6可以是用于向例如游戏控制器等的信息处理设备10供应用户操作信息的设备。为了玩游戏，用户登陆到信息处理设备10的OS(操作系统)。通过登记在信息处理设备10中的用户账户来管理登陆到OS的用户。

由操作信息处理系统1的实体来维护和管理网络服务器5。网络服务器5向信息处理系统1的用户提供游戏的网络服务。网络服务器5管理标识用户的网络账户。用户使用网络账户签名登录(sign in)网络服务器5所提供的网络服务。通过从信息处理设备10签名进入网络服务，用户可以从商店服务器16购买数字内容，并且从内容服务器12接收所分发的数字内容。顺便提及，在本实施例中，数字内容可以是各种类型的应用软件。然而，以下将特别描述其中数字内容为游戏软件的情况。

辅助存储设备2是诸如HDD(硬盘驱动器)、闪存等的海量存储器。辅助存储设备2可以是通过USB(通用串行总线)等连接于信息处理设备10的外部存储设备，也可以是内部存储设备。输出设备4可以是包括用于输出图像的显示器或者用于输出声音的扬声器的电视机，或可以是计算机显示器。可以通过有线电缆将输出设备4连接于信息处理设备10，或可以经由无线电将输出设备4连接于信息处理设备10。

输入设备6包括多个输入部分，例如，多种按压类型的操作按钮、允许输入模拟量的模拟棒、旋转类型的按钮等。将照相机7作为成像设备提供在输出设备4的附近。照相机7对输出设备4周围的空间进行成像。图1描述了其中将照相机7附接于输出设备4的上部的示例。然而，也可以将照相机7设置在输出设备4侧。在任何一种情况下，将照相机7设置在能够对位于输出设备4前面玩游戏的用户进行成像的位置。信息处理设备10具有从由照相机7所成像的图像对用户进行面部确认的功能。

图2是信息处理设备10的功能框图。信息处理设备10包括主电源按钮20、通电LED(发光二极管)21、备用LED22、系统控制器24、时钟26、设备控制器30、介质驱动器32、USB模块34、闪存36、无线通信模块38、有线通信模块40、子系统50、以及主系统60。

主系统60包括主CPU(中央处理器)、作为主存储设备的存储器和存储器控制器、GPU(图像处理单元)等。GPU主要用于游戏程序的算术处理。可以在芯片上将这些功能构造为系统，从而将其形成在一块芯片上。主CPU具有启动OS以及在OS所提供的环境下执行记录在辅助存储设备2中或者ROM介质44上的游戏软件的功能。

子系统50包括子CPU、作为主存储设备的存储器和存储器控制器等。子系统50不包括GPU。子CPU的电路门的数目小于主CPU的电路门的数目。子CPU的操作中的能耗低于主CPU的操作中的能耗。如以上所描述的，在主CPU处于备用状态时，子CPU操作，并且对子CPU的处理功能被限制以保持低能耗。顺便提及，可以在分开的芯片上形成子CPU和存储器。

主电源按钮20是其中执行来自用户的操作输入的输入部分。将主电源按钮20被提供到信息处理设备10的外壳的前表面。主电源按钮20被操作以接通或者关闭信息处理设备10的主系统60的电能供给。以下，主电源的接通状态意味着主系统60处于活跃状态，而主电源的关闭状态意味着主系统60处于备用状态。当接通主电源按钮20时，点亮通电LED21。当关闭主电源按钮20时，点亮备用LED22。

系统控制器24检测用户对主电源按钮20的按压。当在主电源处于关闭状态时按下主电源按钮20时，系统控制器24获得作为“接通指令”的按压操作。另一方面，当在主电源处于接通状态时按下主电源按钮20时，系统控制器24获得作为“关闭指令”的按压操作。

尽管主CPU具有执行记录在辅助存储设备2中或者ROM介质44上的游戏程序的功能，但子CPU不具有这样的功能。然而，子CPU具有访问辅助存储设备2的功能和向网络服务器5、内容服务器12等传输信息以及从网络服务器5、内容服务器12等接收信息的功能。子CPU被配置为仅具有这样的有限的处理功能。因此，与主CPU相比，子CPU能够以低能耗操作。当主CPU处于备用状态时，执行子CPU的这些功能。

时钟26是实时时钟。时钟26生成当前日期和时间信息，并且将当前日期和时间信息供应于系统控制器24、子系统50、以及主系统60。

将设备控制器30配置为在诸如Southbridge(南桥)的设备之间传送信息的LSI(大尺寸集成电路)。如图2中所示，将设备控制器30与诸如系统控制器24、介质驱动器32、USB模块34、闪存36、无线通信模块38、有线通信模块40、子系统50、主系统60等的设备相连接。设备控制器30接纳各设备的电特性之间的差别以及数据传送率之间的差别，并且控制数据传送时序。

介质驱动器32是加载有其上记录了诸如游戏等的应用软件以及许可证(license)信息的ROM介质44的驱动设备，其驱动ROM介质44，并且从ROM介质44读取程序、数据等。以下，当未对程序和数据特别互相区分时，可以将程序和数据统称为数据。然而，数据也将用于表示构成文件的元素。ROM介质44是只读记录介质，例如，光盘、磁光盘、蓝光盘等。

USB模块34是通过USB电缆连接于外部设备的模块。可以通过USB电缆将USB模块34连接于辅助存储设备2和照相机7。闪存36是形成内部存储器的辅助存储设备。例如，无线通信模块38在诸如蓝牙(注册商标)协议、IEEE802.11协议等的通信协议下执行与输入设备6的无线通信。顺便提及，无线通信模块38可以支持与ITU(国际通信协会)所定义的IMT-2000(国际移动通信2000)标准兼容的第三代(3G)数字移动电话系统，或可以支持不同代的数字移动电话系统。有线通信模块40执行与外部设备的有线通信。例如，经由AP8将有线通信模块40连接于网络3。

返回至图1，内容服务器12和商店服务器16向信息处理设备10提供游戏软件。游戏软件包括启动文件、用于执行诸如游戏程序等的游戏的资源文件组、以及信息处理设备10的OS所使用的文件组。游戏软件将最初记录在ROM介质44上的游戏软件的图像文件提供于信息处理设备10。需要游戏程序来执行游戏。通过运行游戏程序使游戏得以进展。启动文件是用于启动游戏程序的程序。当执行启动文件时，调用游戏程序，并且加以执行。例如，OS所使用的文件组包括显示在信息处理设备10中的菜单屏幕上的游戏图标图像。

游戏软件具有树类型目录结构。根目录包括启动文件。根据文件类型对下层子目录进行分类。例如，形成针对3D(三维)模型的子目录、针对纹理(texture)的子目录、针对脚本(script)的子目录等，作为子目录。

图3描述了游戏软件的文件配置。由多个文件形成根据本实施例的游戏软件70的主体，并且将其逻辑地划分为多个组72，如图中所示。每个文件属于所述多个组72中的至少之一，而且至少一个文件属于每个组72。图3中所示的游戏软件70包括作为前端组的第一组72a、作为跟随第一组72a的组的第二组72b、第三组72c、第四组72d、第五组72e、以及第六组72f。顺便提及，可能存在着跟随第六组72f的第七和后续的组72。由诸如第一、第二等的组编号来标识每个组。

在所述多个子目录中包括的文件属于逻辑上划分的各个组。即，由不同类型的文件形成每个组，并且将每个组这样地设置：信息处理设备10执行游戏中的某一具体单元、例如场景、舞台等所需的文件属于每个组。

启动游戏软件70所需的程序文件和数据文件属于第一组72a。因此，当信息处理设备10从内容服务器12或者商店服务器16获得游戏软件70时，如果信息处理设备10已经下载了属于第一组72a的所有文件，则信息处理设备10可以立即启动游戏软件70，即使是在信息处理设备10没有下载接下来的第二组72b以及后续的各组的文件的情况下。顺便提及，在信息处理设备10已经获得了属于第一组72a的所有文件并且启动了游戏软件70之后，信息处理设备10在后台下载属于后续的组72的文件。因此，可以通过最小化最初所下载的用于执行游戏所需的文件，并且允许在获得这些文件的那一时刻执行游戏，来缩短用户的下载等待时间。顺便提及，在本实施例中，在ROM介质44上记录的游戏软件70和从内容服务器12等下载的游戏软件70具有采用相同文件和目录配置的数据结构。

图4描述了游戏软件的文件配置的具体示例。由游戏软件70中首先被下载的文件组来形成第一组72a。在这一情况下，将游戏参数文件、组文件、启动文件、和必需的资源文件示出为第一组72a。

此处，由信息处理设备10的OS使用游戏参数文件。例如，游戏参数文件包括诸如标题ID(标识)、显示分辨率等、图标图像数据等的信息。

组文件是描述每个文件被包括在哪个组中的定义文件。例如，可以按XML(可扩展标记语言)来表示该组文件。然而，也可以按任何形式的不同语言来表示组文件。以下将参照图5和图6描述组文件。

启动文件是用于启动游戏程序的程序。必需的资源文件包括诸如对游戏等的执行必需的程序的资源文件、整个游戏中所使用的公共文件等。

当信息处理设备10从内容服务器12等下载游戏软件70时，信息处理设备10当获得了属于第一组72a的所有文件组时，可以启动游戏。相反，第一组72a包括用户玩部分游戏所需的文件组。顺便提及，在这一情况下的游戏播放也可以包括在游戏开始时所执行的设置动作，例如，用户对人物的确定或者对游戏级别的确定。即，第一组72a包括开始游戏并且允许用户执行至少某些操作所需的文件组。例如，能够使用在第一组72a中包括的文件组进行的游戏播放可以仅是针对游戏的初始设置，或至能够播放游戏的第一阶段的程度。

在图4中所示的示例中，针对场景1的多个资源文件属于第二组72b，针对场景2的多个资源文件属于第三组72c，以及针对场景3的多个资源文件属于第四组72d。具体地讲，所述多个资源文件是针对具体场景的3D模型文件、纹理文件、脚本文件等，并且包括在目录结构的所述多个子目录中包括的文件。另外，针对英语的资源文件属于第十组72k，以及针对日语的资源文件属于第十一组72l。

许多的近期游戏被创建以能够在不同语言的多个国家中运行。音频数据和图像数据被创建以对应于多种语言，并且将针对多种语言的音频文件和图像文件包括在一个包装软件中。以下，可以将这样的文件称为“依赖于语言的文件”。音频文件和图像文件主要倾向于具有大的数据尺寸。这样的依赖于语言的文件的数据尺寸可能占到整个游戏软件的数据尺寸的相当大的比例。因此，为了可以仅获取必需的依赖于语言的文件，根据本实施例的游戏软件70包括针对各种语言的资源文件的各组，在这些组中，逐语言地收集音频文件和图像文件的组。

图5描述了组与文件之间的关系的示例。在这一情况下，将文件A和N描述为属于相应的组72。如图中所示，每个文件属于多个组72中的至少一个，并且至少一个文件属于每个组72。顺便提及，文件G属于第二组72b、第三组72c、以及第四组72d。这意味着文件G是形成游戏中的场景1、场景2、以及场景3所需的。于是，一个文件可以属于多个组。顺便提及，文件K也属于多个组72，即，第四组72d和第五组72e。

图6描述了组文件的示例。如以上所描述的，可以按XML来表示组文件，也可用不同的程序语言来表示组文件。为了有助于理解，图6按表格形式描述了表示组和文件之间对应关系的组文件。当信息处理设备10下载游戏软件70的每个文件时，信息处理设备10可以通过引用组文件来判断是否获得了属于某个组的所有文件。例如，对于第一组72a，信息处理设备10可以通过引用组文件来识别出：属于第一组72a的文件为文件A、B、C、D、E、以及F。于是，当将这些文件记录在辅助存储设备2中时，信息处理设备10判断：获得了属于第一组72a的所有文件。

如以上所描述的，游戏软件70包括各种游戏文件。以下将描述根据本实施例的游戏数据的数据结构。在本实施例中，使用用于UNIX(注册商标)的文件管理方法来配置游戏数据。游戏数据至少包括以上所描述的游戏软件70的主体(由多个游戏文件构成)以及元数据。

使用一个或多个分配于其的块来配置文件。块是传输数据的文件系统的基本单位。将一个块设置为预先确定的数据大小(例如，64K字节)。因此，在1280K字节的文件的情况下，将20个块分配给该文件。为每个文件设置用于存储构成文件的一个或多个数据块的一个或多个记录位置位置的索引表。

图7是辅助解释了用于对游戏文件的数据块寻址的数据结构的参照示例的图。将第一层的第一索引表称为索引节点(简称“i-节点”)，而且其具有用于对数据块进行寻址的总共15个项目(entry)。所有文件均由i-节点和若干数据块构成。赋予i-节点用于标识文件系统中的文件的i-节点编号。i-节点具有i-节点编号、文件的类型、文件的字节长度、访问权限等，作为属性信息。

在作为参照示例所描述的数据结构中，将用于标识数据块的记录位置的信息记录在i-节点的项目中。例如，这一信息可以是指定距记录磁盘或者分区的起始的相对位置的块编号。顺便提及，用于标识数据块的记录位置的信息并不局限于块编号，也可以是例如，诸如用于计算块编号的块大小、文件偏移量等的信息。另外，用于标识数据块的记录位置的信息也可以是其扇区编号直接标识记录位置的记录磁盘的扇区编号。

将文件名和管理文件的i-节点的i-节点编号(具有作为指向i-节点的指针的含义)互相相关联地被保存在目录的数据块中。因此当游戏程序通过文件名引用文件时，OS的内核引用目录项的信息、获得相应于文件名的i-节点编号、以及使用在i-节点编号所标识的i-节点中包括的块编号来访问文件。

从文件中的一开始，使用i-节点的12个项目来记录12个数据块的块编号。于是，当由12个或者更少的数据块来形成文件时，i-节点可以使用其数目等于块的数目的项目来记录相应数据块的块编号。

顺便提及，当由13个或者更多的数据块来形成文件时，需要处于多个层的索引表。在图7中所示的示例中，将处于第二层(间接块)的索引表的块编号记录在i-节点第13个项目中。将i-节点的第13个项目链接于该间接块，从而其可用于第一阶段中的间接参照。间接块具有固定的数据大小，并且具有256个项目。将处于第二层的数据块的块编号记录在间接块的项目中。

将用于链接处于第三层(双重间接块)的索引表的处于第二层(间接块)的索引表的块编号记录在i-节点的第14个项目中。将双重间接块的块编号记录在间接块的项目中。双重间接块具有256个项目。将处于第三层的数据块的块编号记录在双重间接块的项目中。于是，可以将i-节点的第14项目用于第二阶段中的间接参照。

将用于链接处于第四层(三重间接块)的索引表的、用于链接处于第三层(双重间接块)的索引表的处于第二层(间接块)的索引表的块编号记录在i-节点的第15项目中。将双重间接块的块编号记录在间接块的项目中。将三重间接块的块编号记录在双重间接块的项目中。三重间接块具有256个项目。将处于第四层的数据块的块编号记录在三重间接块的项目中。于是，将i-节点的第15项目用于第三阶段中的间接参照。

以下，可以将处于第二以及后续层的索引表(即，除i-节点之外的索引表)统称为间接块。

在作为参照示例所描述的游戏文件的数据结构中，索引表的每个项目也与块编号一起存储在数据块中包括的数据的哈希值。例如，哈希值是32个字节的数据值。将数据块中的数据的哈希值记录在其中登记了数据块的项目中使得当读出块的数据时能够验证数据，并且能够防止数据被篡改。

如以上所描述的，间接块具有固定的数据大小。当将间接块用作索引表时，需要确保固定长度的区域。例如，在一个游戏文件的块的数目为20的情况下，将数据块登记在i-节点的12个项目和处于第二层的间接块的8个项目中，并且将相应的块编号和哈希值记录在所述项目中。因此，处于第二层的间接块的248(＝256-8)个其余的项目为空，于是，这是作为元数据的无贡献的不需要的区域。

游戏软件70的主体包括多个游戏文件，例如，多于10000个游戏文件。在这一文件系统中，为了读出游戏文件，在诸如DDR3(双数据率3)等的存储器中扩展在i-节点和间接块中记录的所有元数据。顺便提及，期望也将尽可能多的游戏文件读出到存储器中。因此，期望元数据的数据大小尽可能地小。

然而，如以上所描述的，当在间接块的项目中存在大量空(null)数据时，也在存储器中扩展这些空数据，从而减少存储器空间。在游戏软件70包括多于10000个文件的情况下，具体地，当准备了针对每个文件的索引表时，包括空数据的元数据可能会超过1G字节。

图8描述了游戏数据的数据结构的参照示例。通过向包括多个(例如，10000个)游戏文件的游戏数据区域202添加包括超级块、i-节点列表、以及多个(N个)间接块，来获得本参照示例中所示的数据结构。超级块已经在其中记录了用于管理在游戏数据区域202中包括的文件的信息，并且包括诸如块大小、块的总数目等的元数据。i-节点列表包括数目至少等于在游戏数据区域202中包括的文件的数目(例如，10000个)的i-节点。(顺便提及，为了精确起见，在这一文件系统中，也将目录和文件名当作一个文件，于是，i-节点列表还包括与目录和文件名相关的i-节点)。

为那些不能够在i-节点的12个项目中登记其数据块的文件提供间接块。在本参照示例中，如已经描述的，i-节点和间接块的项目包括块编号和在数据块中包括的数据的哈希值。

因此，当游戏数据区域202包括10000个文件时，存在着大量间接块。在某些间接块中，大多数项目可能包括空数据，如以上所描述的。于是，元数据区域200的数据大小变得不必要的大。在游戏程序的执行期间，从存储器的有效使用以扩展在存储器中的元数据区域200中包括的元数据的角度，这是所不希望的。

因此，本实施例中的游戏数据具有其中最小化了元数据的数据大小的数据结构，而非具有针对每一文件的每一块的哈希值的数据结构。具体地讲，创建了其中将无签名(哈希值)的多个文件汇总(lump)在一起的完全纯文本(plain text)图像文件，并且创建了通过向图像文件添加元数据所获得的游戏数据。顺便提及，图像文件指的是作为包括文件系统的结构、控制信息等的一个文件所形成的图像文件。

使用这一游戏数据的数据结构，将多个文件记录在记录介质上的连续的位置(块)中。于是，当将开始位置和文件大小作为元数据保存在i-节点的项目中时，可以标识每个文件的记录位置。因此，变得不需要具有用于标识每个数据块的记录位置、诸如块编号等的信息。另外，由于不为每个数据块附加签名，所以变得不需要为每个数据块具有作为每个文件的元数据的哈希值。于是，可以将每个文件的元数据包含在i-节点的项目中。即，当针对每个块生成哈希值、并且将数据块记录在连续编号的块中时，间接块显得不必要，因此可以显著减小元数据的数据大小。

图9是游戏数据创建方法的流程图。流程图中所示的步骤表示这样的过程：其中，游戏制造商创建了最终的游戏包(package)软件，并且通过包创建软件来实现这些步骤。首先，包创建软件创建纯文本游戏数据(无压缩、无加密、以及无签名)的图像文件(S10)。如已经描述的，将图像文件形成为包括文件系统的结构、控制信息等的一个文件。

图10A描述了本实施例中的游戏数据的完全纯文本图像文件的示例。图像文件210具有通过向包括多个(例如10000个)文件的游戏数据区域202添加包括超级块、i-节点列表、超级根目录、以及平路径表的元数据区域204所获得的数据结构。以下将描述超级根目录和平路径表。超级块在其中已经记录了用于管理在游戏数据区域202中包括的文件的信息，并且包括诸如块大小、块的总数目等的元数据。

将具有连续编号的逻辑块分配于在游戏数据区域202中包括的多个游戏文件。分配于在游戏数据区域202中包括的多个游戏文件的块的排列使得能够根据将文件分配于其的开始块编号和文件的数据大小来标识记录介质上的一个游戏文件的存储位置。因此，通过记录游戏文件的i-节点中的文件的开始块编号和文件的数据大小，来标识文件的记录位置。于是，当OS访问游戏文件时，通过获得游戏文件的i-节点编号，可以标识游戏文件的记录位置。

无签名被附加于在游戏数据区域202中记录的游戏文件。于是，不存在针对每个块的哈希值。因此，不需要准备用于记录文件的元数据的间接块，而可以将文件的元数据包含在i-节点的一个项目中。因此，元数据区域204中的i-节点列表包括数目等于游戏数据区域202中文件的数目个i-节点。另一方面，与图8进行比较可以清楚地看出，元数据区域204不包括与文件相关的多个间接块。顺便提及，如已经描述的，在这一文件系统中，也将目录和文件名当成一个文件。于是，i-节点列表也包括与目录和文件名相关的i-节点。然而，在这一情况下，未将签名附加于目录和文件名，使得不需要准备间接块。

与图8中所示的元数据区域200进行比较可以看出，能够显著减小图10A中所示的元数据区域204的数据大小，因为元数据区域204不包括间接块。因此，即使当在游戏程序执行期间将在元数据区域204中包括的元数据读出到诸如DDR3等的存储器中时，元数据也仅具有小的数据大小。

返回至图9，包创建软件压缩图10A中所示的纯文本图像文件210(S12)。图10B描述了压缩的图像文件的示例。包创建软件将具有连续编号的逻辑块分配于压缩的图像文件212。在压缩的图像文件212中，将表示压缩之前和压缩之后的文件的块之间的关系的压缩表写入至元数据区域204。在压缩表的头部分中描述该压缩之前的纯文本图像文件210的大小，并且在压缩表的表部分中互相相关地描述压缩之前的块编号、压缩之后的块编号、以及压缩之后的块编号的块中的位移位置。与游戏数据区域202的数据大小相比，这样的压缩减小了游戏数据区域206的数据大小。

可以将图10A和图10B中所示的图像文件210和212照原样用作游戏数据的图像文件。即，当信息处理设备10中的OS在用于执行游戏的预先确定的安装点(以下将将其安装点称为执行安装点)时安装了图像文件210或者212时，开启启动文件，以执行游戏程序。此时，可以在不包括间接块的情况下使元数据区域204的数据大小偏小，因此能够有效地在存储器中扩展元数据。

然而，未将签名附加于图像文件210和212。因此，存在着这样的缺点：当读出块的数据时，不能够验证数据，并且不能够有效地防止数据被篡改。于是，在本实施例中，将档案格式的图像文件212当作一个文件，附加签名，并且还进行加密以创建安全游戏数据。顺便提及，当对图像文件212施加签名和加密，以整体减小游戏数据的数据大小时，在进行压缩以创建安全游戏数据之前，可以对图像文件210施加签名和加密。

包创建软件将压缩的图像文件212当作一个文件，并且向图像文件212分配具有连续编号的逻辑块。包创建软件将签名附加于构成压缩的图像文件212的多个块中的每个块，或者具体地获得每一段块数据的哈希值，并且将签名作为元数据添加于图像文件212(S14)。顺便提及，为了提高游戏数据的安全性，包创建软件可以将签名附加于所创建的元数据，并且还对游戏数据的元数据和主体进行加密处理。

图11描述了根据本实施例的游戏数据的数据结构的例子。将具有这一数据结构的游戏数据作为包文件214记录在ROM介质44上，或者作为包文件214从内容服务器12或者商店服务器16下载至信息处理设备10，并且将其记录在辅助存储设备2上。

如图11中所说明的，包文件214具有其中嵌套了图像文件212的数据结构。通过将包括超级块、i-节点列表、多个(M个)间接块、超级根目录、以及平路径表的元数据区域208添加于被当作一个文件的图像文件212，来获得根据本实施例的数据结构。

超级块中已经记录了用于管理图像文件212的信息，并且包括诸如块大小、块的总数目等元数据。将包括图像文件212的各块的哈希值的元数据记录在将i-节点包括在i-节点列表以及多个间接块中的图像文件212的i-节点的项目中，所述项目包括至少多个其数目等于对作为文件的图像文件212进行划分所获得的块的数目的项目。于是，使用通过如下方式所获得的数据结构形成包文件214：将包括至少附加于构成图像文件212的多个块中每块的签名(哈希值)的元数据添加于游戏数据的图像文件212，其中游戏数据的图像文件包括分别被赋予一个或多个块的多个文件，并且包括这些文件的元数据。应该加以注意的是，如已经描述的，未将签名附加于包括在图像文件212中的各文件的块。

记录在记录介质(ROM介质44或者辅助存储设备2)上的包文件214具有其中嵌套了图像文件212的数据结构。于是，通过两次安装包文件214，OS的内核能够访问包括在游戏数据区域202中的每文件。

在第一阶段中的安装处理中，所述内核在第一安装点处安装包文件214，以能够识别包文件214的文件系统。具体地讲，所述内核使用包括在包文件214的元数据区域208中的元数据，以能够识别图像文件212，从而能够将图像文件212视为文件。由作为第一安装处理部分操作的内核实现这一安装功能。

在第二阶段中的安装处理中，为了执行游戏程序，所述内核在第二安装点处(执行安装点)安装图像文件212，以能够识别图像文件212的文件系统。具体地讲，所述内核使用包括在图像文件212的元数据区域204中的元数据，以能够识别游戏数据区域206，从而能够访问包括在游戏数据区域206中的多个(例如，10000个)游戏文件。由作为第二安装处理部分操作的内核实现这一安装功能。顺便提及，第一阶段中安装处理中的第一安装点与第二阶段中安装处理中的第二安装点可以相同，也可以不同。

在第二阶段中的安装处理之后，所述内核执行启动文件。顺便提及，在游戏数据区域206中不压缩启动文件。因此所述内核可以照原样启动启动文件。由于图像文件212的元数据区域204的很小的数据大小，能够在诸如DDR3等的存储器中有效地扩展元数据。

以下，将描述作为图像文件210或者212的元数据区域204中的元数据所包括的平路径表。

在根据本实施例的、在UNIX中所使用的文件管理方法中，如已经描述的，也将目录和文件名当作一种文件，因此，赋予目录和文件名块，并且加以记录。例如，当存在目录结构“user/AAA/BBB/CCC/文件名”时，向目录名和文件名中的每目录目名和文件名分配块。因此，总共需要5个块。

特别是，目录的数目随游戏数据的文件的数目的增加而增加。如已经描述的，需要将文件的i-节点作为元数据读出到诸如DDR3等的存储器中。于是，就尺寸而言，最好尽可能多地减小元数据的量。因此，为减小元数据的量，在根据本实施例的数据结构中，不将以上所描述的示例中所示的全路径信息(user/AAA/BBB/CCC/文件名)用作元数据，而使用了平路径表。

将平路径表配置为将游戏文件全路径信息的哈希值与用于识别游戏文件的记录位置的信息相关联的对应文件。最好将能够从游戏程序读出的所有游戏文件的全路径信息的哈希值和用于标识游戏文件的记录位置的信息互相关联地记录在平路径表中。此处，用于标识文件的记录位置的信息可以为唯一标识记录在记录介质上的文件的i-节点编号。因此，例如，将相应文件的全路径(user/AAA/BBB/CCC/文件名)的哈希值和i-节点编号相互关联地记录在根据本实施例的平路径表中。当游戏程序输出包括全路径信息的文件读出请求时，OS中的文件读出API(应用编程接口)顺序地获得全路径的哈希值，使用哈希值搜寻平路径表中的i-节点编号，并且标识构成文件的块。

图12A描述了平路径表的示例。在平路径表220中，将每一段全路径信息的哈希值和相应于全路径信息的i-节点编号互相关联地加以记录。此处，例如，将哈希值作为4个字节的值加以形成。于是，与全路径信息的数据量相比，可以形成全路径信息的哈希值，从而能够以极小的数据量加以表示。在平路径表220中，按递降的次序排列全路径信息的哈希值。在这一情况下，为了便于描述，将哈希值表示为16进制数字。

另一方面，当使用哈希值时，多段全路径信息的哈希值可能相同。通常将这称为“哈希值冲突”。在平路径表220中，用由少量数据表示的哈希值取代全路径信息，因此可能出现哈希值之间的冲突。在这一情况下，会同时存在与不同i-节点编号相关联的相同的哈希值。因此，为了互相区别这些哈希值，平路径表220将冲突文件222定义为伴随平路径表220的文件。

图12B描述了冲突文件的示例。在冲突文件222中，对于其哈希值互相冲突的全路径信息，将文件名和用于标识文件的记录位置的信息(在这一情况下为i-节点编号)互相相关地加以记录。

将描述图12A的表中的右项中的“i-节点编号/位移”。例如，这一项由4个字节表示，在高阶比特中设置至少表示冲突存在或者不存在的信息。假设，在一个示例中，将这一信息准备为冲突标志，并且假设当存在冲突时设置冲突标志1，当不存在冲突时设置冲突标志0。

因此，在平路径表220中，对于不存在其重复哈希值的哈希值(无冲突的哈希值)，将高阶比特的冲突标志设置为0，并且在低阶比特中描述i-节点编号。当游戏程序输出指定全路径信息的文件读出请求时，OS中的文件读出API获得全路径信息的哈希值，并且使用哈希值搜寻在存储器中扩展的平路径表中的i-节点编号。此时，当相应的哈希值是非冲突的哈希值时(即，当将冲突标志设置为0时)，文件读出API标识所述表中的右项中所描述的i-节点编号，并读出该文件。

另一方面，在平路径表220中，对于存在其重复哈希值的哈希值(冲突的哈希值)，将高阶比特的冲突标志设置为1，并且在低阶比特中描述位移信息。此处，位移信息表示记录位置相对冲突文件的位移，并且是标识描述了在冲突文件中包括的数据的第一位置。当游戏程序输出指定全路径信息的文件读出请求时，OS中的文件读出API获得全路径信息的哈希值，并且使用哈希值搜寻在存储器中扩展的平路径表中的i-节点编号。此时，当相应的哈希值是冲突的哈希值时(即，当将冲突标志设置为1时)，文件读出API使用位移信息来访问冲突文件，并且搜寻在冲突文件中记录的数据。

例如，当读出请求所指定的全路径信息的哈希值为“012B341C”，并且在表的右项中将冲突标志设置为1时，读出API引用冲突文件，并且搜寻被请求以读出的文件的文件名。如图12B中所示，在冲突文件中，将文件名和i-节点编号互相相关地加以记录。读出API搜寻冲突文件的内部，并且找出被请求以读出的文件的文件名。将i-节点编号与冲突文件中的文件名相关联。于是，读出API能够根据文件名标识i-节点编号，并且读出该文件。

因此，通过取代图像文件210或者212的元数据区域204中的全路径信息，而准备平路径表和冲突文件，可以减小在程序执行期间读出到存储器中的元数据的量。

以下将描述超级根目录。

图13A描述了普通根目录和低层的子目录。针对游戏程序的执行所需的每一种文件，形成子目录。所述内核可以通过在预先确定的执行安装点处安装根目录来执行游戏程序。

图13B描述了本实施例中所使用的超级根目录和低层的子目录。在高于根目录的层的层上设置超级根目录，根目录是所述超级目录的子目录。顺便提及，还是在图13B中所示的目录结构中，所述内核可以通过安装超级根目录来执行根目录的启动文件。由于在较高的层上提供了超级目录，所以能够在低于根目录的层的层上无任何变化的情况下，容易地将子目录添加于低于从根目录独立分支的超级目录的层的层。例如，这使平路径表的文件能够被设置在低于超级目录的层的层。因此，能够提供具有良好延伸性的文件系统。

图14描述了用于实现访问在游戏数据中包括的文件的文件访问功能的配置。信息处理设备10包括接收部分100、哈希值推导部分102、i-节点编号获得部分104、以及文件访问部分106。以由任意计算机的CPU、存储器、加载于存储器中的程序、存储装置等硬件部件的形式实现这些构成元件。然而，在这一情况下，描述了通过这些部件的协作所实现的功能块。因此，本领域技术人员将会意识到：可以仅通过硬件、仅通过软件、或者通过硬件与软件的组合按各种形式实现这些功能块。此处，可以通过以上所描述的读出API实现接收部分100、哈希值推导部分102、以及i-节点编号获得部分104的功能。

在游戏的执行期间，接收部分100从游戏接收包括文件的全路径信息的读出请求。哈希值推导部分102根据预先确定的哈希函数推导所接收的全路径信息的哈希值。i-节点编号获得部分104引用配置为对应文件的平路径表220，并且使用哈希值获得用于标识文件的记录位置的信息，或者这一情况下的i-节点编号。于是，文件访问部分106可以使用i-节点编号来访问游戏所指定的文件，并且读出该文件。

应该加以注意的是，以上表示在哈希值推导部分102所推导的哈希值为非冲突哈希值的情况下的文件访问操作。当将所推导的哈希值的冲突标志设置为0时，i-节点编号获得部分104判断哈希值不冲突，并且能够从平路径表220获得i-节点编号。

在哈希值推导部分102所推导的哈希值为冲突的哈希值的情况下，i-节点编号获得部分104判断哈希值冲突，因为将所推导的哈希值的冲突标志设置为1。因此，i-节点编号获得部分104使用与哈希值相关联的位移信息来访问冲突文件222，并且搜寻冲突文件222中的全路径信息中所指定的文件名。当找到冲突文件222中的文件名时，i-节点编号获得部分104获得与该文件名相关联的i-节点编号。于是，当哈希值推导部分102所推导的哈希值冲突时，i-节点编号获得部分104引用冲突文件222，并且从文件名获得i-节点编号。因此，文件访问部分106可以使用i-节点编号访问游戏所指定的文件，并且读出该文件。

如以上所描述的，文件访问部分106使用i-节点编号来访问该文件。在根据本实施例的信息处理设备10中，作为缓冲器操作的存储器(例如，DDR3)、辅助存储设备2、以及ROM介质44以存储文件的存储部分的形式出现。将ROM介质44加载于介质驱动器32中，以便将数据从ROM介质44读出。此处，将存储器、辅助存储设备2、以及介质驱动器32的相应数据读出速度互相进行比较可以看出：数据读出速度依存储器(memory)、辅助存储设备2、以及介质驱动器32的这一次序而下降。

在这一情况下，在本实施例中，将将存储器称为高速设备，将将辅助存储设备2称为中速设备，并且将将介质驱动器32称为低速设备。以下将描述用于提高文件访问处理的速度的机制，其中，所述机制主要考虑的是数据读出速度的差别。

顺便提及，在描述提高速度的机制之前，由于在在ROM介质44上记录的游戏软件70的执行期间、信息处理设备10具有将在ROM介质44上记录的游戏软件70拷贝至辅助存储设备2的功能，所以将首先描述这一拷贝功能。

图15描述了用于实现文件管理功能的配置。信息处理设备10包括用于进行文件访问的文件访问部分106和用于进行文件管理的文件管理部分108。文件管理部分108也具有将游戏软件70从ROM介质44拷贝至辅助存储设备2的功能。作为存储文件的存储部分120，信息处理设备10具有作为高速存储设备的存储器110、作为中速存储设备的辅助存储设备2、以及作为低速存储设备的介质驱动器32。将存储器110连接于辅助存储设备2或者介质驱动器32。存储器110具有临时存储从辅助存储设备2或者介质驱动器32读出的数据的功能。顺便提及，为了更高速的文件访问，预先在存储器110中扩展图10中所示的在元数据区域204中包括的元数据。

如参照图14所描述的，文件访问部分106使用i-节点编号，访问游戏在全路径信息中所指定的文件，并且读出该文件的数据。具体地讲，文件访问部分106将文件数据从ROM介质44的记录区域(所述记录区域由i-节点编号标识)读出到存储器110中，从存储器110获得文件数据，并且将文件数据提供该游戏程序。

图16是辅助说明拷贝处理的示例的图。这一拷贝处理假设游戏程序正被执行。当游戏程序请求该数据的读出时，文件访问部分106从介质驱动器32读出在ROM介质44上记录的数据，而存储器110临时存储所读出的数据(ST1)。文件访问部分106将在存储器110中存储的数据提供该游戏程序(ST2)。于是，游戏程序可以使用被请求读出的数据来推进该游戏。

此时，文件管理部分108读出在存储器110中存储的数据，并且将数据记录在辅助存储设备2中(ST3)。于是，通过不仅根据来自游戏程序的请求向游戏程序提供读出到存储器110中的数据，而且还将数据记录在辅助存储设备2中，可以将数据从低速设备拷贝至中速设备。当游戏程序下一次需要数据时，将拷贝至辅助存储设备2的数据从辅助存储设备2读出至游戏。

文件管理部分108管理从ROM介质44拷贝至辅助存储设备2的文件。例如，文件管理部分108可以管理表示是否拷贝了文件的信息，作为针对一个文件的位图(bitmap)。顺便提及，在本实施例中，文件由一个或多个块构成。因此，期望文件管理部分108以块为单位管理指示是否拷贝了块的信息。当文件管理部分108已经将数据块从ROM介质44拷贝至辅助存储设备2时，文件管理部分108设置指示将相应数据块拷贝在块位图上的信息(标志)，从而更新块位图(ST4)。于是，文件管理部分108可以识别将哪个块从ROM介质44拷贝至辅助存储设备2。

图17示意性地描述了存储部分120的各存储单元的存储区域的状态。顶行描述了作为高速设备的存储器110的存储区域的状态。中间行描述了作为中速设备的辅助存储设备2的存储区域的状态。底行描述了作为低速设备的ROM介质44的存储区域的状态。在示意性地描述了各存储区域的水平方向为长的矩形区域中，由垂直线所划分的区域表示多个块，画阴影线的块表示已经将数据存储在这些存储区域中。

在这一情况下，顶行所示的存储器110将元数据存储在元数据区域204中，并且还将一部分游戏数据临时存储在其余的存储区域中。由于存储器110的存储区域的尺寸很小，所以可以通过最小化在元数据区域204中包括的元数据的大小来扩展临时存储游戏数据的区域。顺便提及，在这一情况下，将存储器110的存储区域描述为好像充分使用。然而，实际上，存储器110的存储区域仅代表存储器110中的预先确定大小的存储区域，因此，并未充分使用存储器110。

块位图(块BMP)表示文件管理部分108所管理的位图信息。文件管理部分108通过为从ROM介质44拷贝至辅助存储设备2的块设置标志值1，且为未从ROM介质44拷贝至辅助存储设备2的块设置标志值0，来创建该块BMP。如以上所描述的，每次将块从ROM介质44拷贝至辅助存储设备2时，文件管理部分108更新该块BMP。因此，文件管理部分108掌握着辅助存储设备2的最新存储状态。作为中间行中所示的辅助存储设备2的示例的HDD(硬盘驱动器)已经在其上记录了拷贝处理从ROM介质44拷贝的块数据。不加阴影的块区域表示尚未将块数据拷贝到块区域中。

作为底行中所示的ROM介质44的示例的BD(蓝光盘)已经在其上记录了游戏软件的所有数据(包文件214)。因此，BD的所有存储区域被划阴影线。顺便提及，由于实际上对包文件214进行了加密或者压缩，所以不同于图像文件210的游戏数据区域202中的游戏数据的块的块对应于在包文件214中包括的游戏数据。在图17中，虚拟地表示了在译码和/或解压缩之后的块，且各存储区域中的垂直方向上重叠的块代表同一块。

返回至图15，文件访问部分106根据文件管理部分108所管理的存储部分120的存储状况来确定要访问的存储介质。将再次描述存储部分120中的存储器110、辅助存储设备2、以及ROM介质44的游戏数据存储状况。

(1)存储器110中的存储状况

将元数据区域204中的所有元数据存储在存储器110中。于是，文件访问部分106无需寻找和搜寻在记录介质上记录的元数据。文件访问部分106可以引用在存储器110中扩展的元数据，并且迅速标识游戏所请求读出的文件的i-节点编号。另外，存储器110还可以临时存储部分游戏数据。根据需要随时更新游戏数据。文件管理部分108管理存储器110中的存储状况，并且掌握哪个块数据被存储在存储器110中。

(2)辅助存储设备2中的存储状况

将一次从ROM介质44读出到存储器110的数据拷贝至辅助存储设备2，并且存储在辅助存储设备2中。顺便提及，在以上所描述的拷贝处理中，已经描述了响应来自游戏的读出请求，拷贝读出到存储器110的数据。然而，例如，即使当不存在来自游戏的读出请求时，文件管理部分108也可以在后台将游戏数据从ROM介质44拷贝至辅助存储设备2。在这一情况下，辅助存储设备2不仅存储被请求读出的游戏数据，而且还存储其它游戏数据。这样的拷贝处理在辅助存储设备2中记录在ROM介质44上记录的全部或者部分游戏软件。文件管理部分108根据块位图来管理辅助存储设备2中的存储状况，并且掌握哪个块数据被存储在辅助存储设备2中。

(3)ROM介质44上的存储状况

将所有元数据和游戏文件存储在ROM介质44上。

假设执行上述拷贝处理，文件访问部分106根据预先确定的优先级次序、响应来自游戏的读出请求，向游戏提供来自ROM介质44、辅助存储设备2、以及存储器110之一的游戏数据。如已经描述的，文件管理部分108管理存储器110和辅助存储设备2的游戏数据存储状况。具体地讲，文件管理部分108以文件为单位或者以块为单位管理存储状况。特别是，对于辅助存储设备2的存储状况，文件管理部分108使用其上设置了表示是否已经拷贝了每个块或者文件的信息的块位图来管理辅助存储设备2的存储状况。

这样地设置预先确定的优先级次序使得：优先地选择具有快数据读出速度的设备。具体地讲，当将被请求读出的游戏数据存储在存储器110中时，文件访问部分106从存储器110向游戏提供游戏数据。此时，文件管理部分108不需要引用指示辅助存储设备2的存储状况的块位图。

当不将被请求读出的游戏数据存储在存储器110中时，文件管理部分108引用块位图，以判断是否将游戏数据存储在辅助存储设备2中。当将游戏数据存储在辅助存储设备2中时，文件访问部分106将游戏数据从辅助存储设备2读出至存储器110，并且向游戏提供游戏数据。因此，当不将被请求读出的游戏数据存储在存储器110中而存储在辅助存储设备2中时，文件访问部分106从辅助存储设备2向游戏提供游戏数据。

当文件管理部分108判断既不将被请求读出的游戏数据存储在存储器110中也不存储在辅助存储设备2中时，文件访问部分106将游戏数据从加载于介质驱动器32中的ROM介质44读出到存储器110，并且向游戏提供游戏数据。顺便提及，此时，文件管理部分108将从ROM介质44读出至存储器110的游戏数据拷贝至辅助存储设备2，并且更新块位图。因此。当下一次向游戏提供同一游戏数据时，可以从辅助存储设备2而不是ROM介质44提供游戏数据。顺便提及，此时，当将游戏数据存储在存储器110中时，从存储器110向游戏提供游戏数据。

于是，根据速度的级别来确定存储部分120中的存储单元的优先级次序，并且将存储在具有高优先级的存储部分中的游戏数据提供给游戏，从而可以实现较高速度的文件访问。

以上已经描述来针对将ROM介质44上的游戏数据拷贝到辅助存储设备2的情况下的文件访问。以下将描述针对从内容服务器12或者商店服务器16下载游戏软件的情况下的文件访问。

在游戏软件下载处理中，将辅助存储设备2用作用于存储构成游戏软件的多个文件的存储设备。如以上参照图3-6所描述的，在游戏软件中，每个文件属于至少一个组，以及至少一个文件属于每个组。

以组为单位执行下载处理。例如，在文件X、Y、以及Z属于组S的情况下，当生成下载组S的请求时，从内容服务器12下载文件X、Y、以及Z，并且将属于组S的所有文件X、Y、以及Z全部记录在辅助存储设备2中。顺便提及，当已经下载了文件X时，从内容服务器12下载文件Y和Z。于是，将属于组S的所有文件X、Y、以及Z全部记录在辅助存储设备2中。

如图3中所示，可以由组编号来标识游戏软件的组。从1按递降的次序来设置组编号。下载处理部分(未图示)可以按与组编号的次序相同的次序来确定将下载的组的次序。即，下载处理部分将较低编号的组确定为较早下载的对象，因此，确定按第一组72a、第二组72b、第三组72c……这样的次序下载，即，按组编号的次序下载。下载处理部分根据该次序下载在组中包括的文件。

下载处理部分以组为单位向内容服务器12传输下载请求，并且将从内容服务器12传输的游戏数据记录在辅助存储设备2中。此时，文件管理部分108以组为单位管理文件或者块的存储状况。所下载的文件是压缩和加密的包文件214。于是，文件管理部分108生成指示包文件214中的游戏数据的存储状况的第一位图和指示当对包文件214进行译码和解压缩时的游戏数据的存储状况的第二位图。顺便提及，第二位图与以上针对游戏数据从ROM介质44向辅助存储设备2的拷贝所描述的位图相同。如以上针对游戏数据的拷贝所描述的，文件管理部分108管理第二位图，于是，文件访问部分106能够进行高效的文件访问。顺便提及，当文件访问部分106管理第一位图时，例如，在下载未被安装的文件的情况下，可以适当地执行文件管理。

以上，已经根据其实施例描述了本公开。所述实施例是说明性的，而且本领域技术人员将会意识到，可以很容易地对所述实施例的构成成分和处理过程的组合进行各种修改，而且这样的修改也落入本公开的范围。在这些实施例中，将游戏描述为应用的示例。然而，也可以将本技术施用于其它应用。

本技术包含与2013年11月1日向日本专利局提出的日本优先权专利申请JP2013-228808中所公开的主题相关的主题，特将其全部内容并入此处，以作参考。

Claims (4)

1.一种用于处理包括启动文件和程序文件的游戏数据的信息处理设备，其中，通过向游戏数据的图像文件添加元数据来形成所述游戏数据，所述游戏数据的图像文件包括每个被赋予一个或多个块的多个文件并且包括每一个文件的元数据，所述元数据包括附加于构成所述图像文件的所述多个块中每一个块的签名，所述信息处理设备包含：

第一安装处理部分，在第一安装点处安装将添加了包括签名的元数据的图像文件，并且识别所述图像文件；以及

第二安装处理部分，在第二安装点处安装所识别的图像文件，并且识别在所述图像文件中包括的多个文件。

2.根据权利要求1所述的图像处理设备，

其中，所述第二安装点是用于执行所述程序文件的安装点。

3.一种包括计算机所执行的程序文件的游戏数据的数据结构，

其中，向游戏数据的图像文件添加元数据，所述游戏数据的图像文件包括每个被赋予了一个或多个块的多个文件并且包括每一个文件的元数据，所述元数据包括附加于构成图像文件的所述多个块中每一个块的签名，并且

未将签名附加于在图像文件中包括的文件的块。

4.根据权利要求3所述的游戏数据的数据结构，

其中，压缩所述图像文件，并且将包括构成所压缩的图像文件的多个块中的每一个块的哈希值的元数据添加于图像文件。