JP2015207145A - 情報処理装置および差分情報生成装置 - 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）デジタル携帯電話方式に対応してもよく、さらには別の世代のデジタル携帯電話方式に対応してもよい。有線通信モジュール４０は、外部機器と有線通信し、ＡＰ８を介してネットワーク３に接続する。

図１に戻ってコンテンツサーバ１２は、情報処理装置１０にゲームソフトウェアおよびそのパッチデータを提供する。本実施例においてコンテンツサーバ１２は、情報処理装置１０からの要求に応じて、最新バージョンのパッチファイルのうち、情報処理装置１０がダウンロードしていないデータを含むデータブロックを提供する。パッチファイルは、ゲームメーカにより適時更新され、コンテンツサーバ１２には、常に最新のパッチファイルをユーザがダウンロード可能に保持されている。最新のパッチファイルのデータには、それ以前のバージョンのパッチファイルのデータと重複するものもあるため、情報処理装置１０は、最新のパッチファイルにおいて、それ以前のパッチファイルでは取得していないデータを含むデータブロックのみをダウンロードするようにする。情報処理装置１０はゲームソフトウェアに最新のパッチをあてる際、それ以前のパッチファイルで取得済みのパッチデータについては、それを再利用する。これにより、ダウンロードする最新パッチファイルのデータ量を少なくでき、コンテンツサーバ１２の処理負荷を下げることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

このようにゲームソフトウェア７０が複数のグループにより構成されることで、情報処理装置１０は、グループのダウンロードの優先順位を定めるダウンロード順序にしたがって、ファイルをダウンロードすることができる。ゲームソフトウェア７０が、１人でプレイするシングルプレイ用のリソースファイルと、複数人でプレイするマルチプレイ用のリソースファイルを含む場合、ユーザがシングルプレイを望む場合には、シングルプレイ用のグループを優先的にダウンロードし、シングルプレイを楽しみながら、バックグランドで、マルチプレイ用のグループをダウンロードできるようになる。一方で、ユーザがマルチプレイを望む場合には、マルチプレイ用のグループを優先的にダウンロードし、マルチプレイを楽しみながら、バックグランドで、シングルプレイ用のグループをダウンロードできる。

なお本実施例において、ゲームソフトウェアは、圧縮され、署名され、且つ暗号化されている。後述するが、パッチファイルも、ゲームソフトウェアと同様に、圧縮され、署名され、且つ暗号化されている。このように圧縮署名暗号化されたゲームソフトウェアおよびパッチファイルは、所定のサイズ（たとえば６４キロバイト）のデータブロックを割り当てられて構成されている。データブロックは、ファイルシステムがデータを転送する基本単位となる。本実施例では、ファイルのデータが、データブロック単位で配信可能であるため、図６に示すグループファイルは、各グループと、各グループに所属するファイルのデータが含まれるデータブロックの番号との対応関係を記録していてもよい。また図６に示すグループファイルは、各グループと、各グループに所属するファイルのデータが含まれるデータブロックのアドレスとの対応関係を記録していてもよい。

以下、本実施例のゲームソフトウェアのデータ構造について説明する。本実施例では、ＵＮＩＸ（登録商標）で利用されるファイル管理手法を利用して、ゲームソフトウェアを構成する。ゲームソフトウェアは、複数のファイルとメタデータとを少なくとも含んで構成される。本実施例のデータ構造を説明する前に、図７において、アドレッシング用のデータ構造を参考に示し、図８において、本実施例のデータ構造と比較するためのデータ構造の比較例を示す。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スーパブロックには、イメージファイル２１３の管理情報が記録され、ブロックサイズ、総ブロック数などのメタデータが含まれる。ｉノードリストに含まれるイメージファイル２１３のｉノードおよび複数のインダイレクトブロックは、１つのファイルとして見立てたイメージファイル２１３を分割したブロック数分を少なくとも含むエントリに、イメージファイル２１３の各ブロックのハッシュ値を含むメタデータを記録する。このようにパッケージファイル２１４は、圧縮して暗号化したイメージファイル２１３を所定のブロックサイズで分割し、それぞれに連続したブロック番号を割り当てたデータ構造を有している。

図１０（ａ）から図１０（ｃ）に例示したイメージファイルの関係について説明する。
図１１（ａ）から図１１（ｃ）は、メタデータと、ファイルＡ〜Ｆを含むイメージファイルを説明するための図である。なお、説明の便宜上、図１１において、メタデータとして表現されているデータ群は、メタデータを含むだけでなく、図４に示す第１グループ７２ａに含まれるファイルも含むものとする。図１２にも関連して後述するが、図１１においてメタデータとして示すデータの集合体は、第１グループ７２ａに含むファイルを含み、したがって情報処理装置１０は、図１１でメタデータとして便宜上表現している第１グループ７２ａをダウンロードすることで、プログラムを起動できるようになる。

図１１（ａ）は、圧縮前のイメージファイル２１０の構成例を示す。ここではメタデータが第１ブロック２３１、第２ブロック２３２に格納され、ファイルＡが、第３ブロック２３３、第４ブロック２３４、第５ブロック２３５に格納され、ファイルＢが、第６ブロック２３６、第７ブロック２３７、第８ブロック２３８に格納され、ファイルＣが、第９ブロック２３９、第１０ブロック２４０、第１１ブロック２４１に格納され、ファイルＤが、第１２ブロック２４２、第１３ブロック２４３、第１４ブロック２４４に格納され、ファイルＥが、第１５ブロック２４５、第１６ブロック２４６、第１７ブロック２４７に格納され、ファイルＦが、第１８ブロック２４８、第１９ブロック２４９、第２０ブロック２５０に格納されている。各ブロックは、６４キロバイトのデータサイズを有している。このように圧縮前のイメージファイル２１０において、メタデータおよび各ファイルは、６４キロバイトのブロックに整列して格納されている。

図１１（ｂ）は、圧縮したイメージファイル２１２の構成例を示す。イメージファイル２１０の各ブロックが圧縮され、圧縮した各ブロックを連結することで、イメージファイル２１２が生成される。
図１１（ｃ）は、圧縮したイメージファイル２１２を６４キロバイトのブロックに分割して、ブロックごとに署名暗号化したイメージファイル２１３の構成例を示す。圧縮署名暗号化されたメタデータ（Ｍ）は、第１ブロック２６１と、第２ブロック２６２の一部に格納されている。また圧縮署名暗号化されたファイルＡは、第２ブロック２６２の一部と、第３ブロック２６３と、第４ブロック２６４の一部に格納されている。圧縮署名暗号化されたファイルＢは、第４ブロック２６４の一部と、第５ブロック２６５と、第６ブロック２６６の一部に、圧縮署名暗号化されたファイルＣは、第６ブロック２６６の一部と、第７ブロック２６７と、第８ブロック２６８の一部に、圧縮署名暗号化されたファイルＤは、第８ブロック２６８の一部と、第９ブロック２６９と、第１０ブロック２７０の一部に、圧縮署名暗号化されたファイルＥは、第１０ブロック２７０の一部と、第１１ブロック２７１と、第１２ブロック２７２の一部に、圧縮署名暗号化されたファイルＦは、第１２ブロック２７２の一部と、第１３ブロック２７３と、第１４ブロック２７４に、それぞれ格納されている。このように圧縮後のイメージファイル２１２を６４キロバイトのブロックで分割し、各ブロック内での暗号化が行われている。なお本実施例において、暗号化は共通鍵暗号を採用し、したがってブロックの暗号化の前後においてデータの増減は発生しない。

図１２は、圧縮署名暗号化されたファイルをダウンロードする方法を説明するための図である。図５および図６に、グループとファイルの関係の一例を示したが、その例とは別に、図１２では理解を容易にするために、グループとファイルの関係を単純化して示している。
図１２（ａ）に示すイメージファイル２１３において、上記したように、メタデータＭは、第１グループ７２ａに対応するものとして示している。なお第１グループ７２ａには、さらに図１０（ｃ）に示すメタデータ領域２０８に含まれるメタデータも含まれる。
図１２（ｂ）は、第１グループ７２ａに属するファイルを示すデータブロックを示す。第１グループ７２ａは、第１ブロック２６１と、第２ブロック２６２の一部に格納されており、したがって第１グループ７２ａを取得するためには、第１ブロック２６１と第２ブロック２６２をダウンロードする必要がある。

図１２（ｃ）は、第２グループ７２ｂに属するファイルを示すデータブロックを示す。第２グループ７２ｂは、ファイルＡ，Ｂ，Ｆから構成される。ファイルＡは、第２ブロック２６２の一部と、第３ブロック２６３と、第４ブロック２６４の一部に格納され、ファイルＢは、第４ブロック２６４の一部と、第５ブロック２６５と、第６ブロック２６６の一部に格納され、ファイルＦは、第１２ブロック２７２の一部と、第１３ブロック２７３と、第１４ブロック２７４に格納されている。したがってファイルＡ，Ｂ，Ｆから構成される第２グループ７２ｂを取得するためには、第２ブロック２６２〜第６ブロック２６６、第１２ブロック２７２〜第１４ブロック２７４をダウンロードする必要がある。

図１２（ｄ）は、第３グループ７２ｃに属するファイルを示すデータブロックを示す。第３グループ７２ｃは、ファイルＣ，Ｄ，Ｆから構成される。ファイルＣは、第６ブロック２６６の一部と、第７ブロック２６７と、第８ブロック２６８の一部に格納され、ファイルＤは、第８ブロック２６８の一部と、第９ブロック２６９と、第１０ブロック２７０の一部に格納され、ファイルＦは、第１２ブロック２７２の一部と、第１３ブロック２７３と、第１４ブロック２７４に格納されている。したがってファイルＣ，Ｄ，Ｆから構成される第３グループ７２ｃを取得するためには、第６ブロック２６６〜第１０ブロック２７０、第１２ブロック２７２〜第１４ブロック２７４をダウンロードする必要がある。

図１２（ｅ）は、第４グループ７２ｄに属するファイルを示すデータブロックを示す。第４グループ７２ｄは、Ｅから構成される。ファイルＥは、第１０ブロック２７０の一部と、第１１ブロック２７１と、第１２ブロック２７２の一部に格納されている。したがってファイルＥから構成される第４グループ７２ｄを取得するためには、第１０ブロック２７０〜第１２ブロック２７２をダウンロードする必要がある。

ここで、第２グループ７２ｂが、シングルプレイ用のリソースファイル、第３グループ７２ｃが、マルチプレイ用のリソースファイル、第４グループ７２ｄが、エンディング用のリソースファイルであるとする。たとえば一人でプレイ（シングルプレイ）を行うユーザは、複数人でプレイ（マルチプレイ）用の第３グループ７２ｃをすぐには必要とせず、また一方で、マルチプレイを行うユーザは、シングルプレイ用の第２グループ７２ｂをすぐには必要としない。

つまりシングルプレイを行うユーザは、第１グループ７２ａをまずダウンロードした後、第２グループ７２ｂ、第４グループ７２ｄを、この順にダウンロードし、最後に第３グループ７２ｃをダウンロードすればよい。このユーザは、ダウンロード時にはマルチプレイに興味がないため、いち早く、シングルプレイ用のリソースファイルと、エンディング用のリソースファイルとをダウンロードして、ゲームをシングルプレイできることが好ましいためである。

一方で、マルチプレイを行うユーザは、第１グループ７２ａをまずダウンロードした後、第３グループ７２ｃ、第４グループ７２ｄを、この順にダウンロードし、最後に第２グループ７２ｂをダウンロードすればよい。このユーザは、ダウンロード時にはシングルプレイに興味がないため、いち早く、マルチプレイ用のリソースファイルと、エンディング用のリソースファイルとをダウンロードして、ゲームを複数ユーザでプレイできることが好ましいためである。

そこでユーザがゲームソフトウェアをダウンロードする際、出力装置４の画面には「シングルプレイ用のゲームを優先的にダウンロードする」、「マルチプレイ用のゲームを優先的にダウンロードする」の選択肢が提示され、コンテンツサーバ１２は、選択された選択肢にしたがって、グループのダウンロード順序を示す順序情報を情報処理装置１０に提供し、情報処理装置１０が、その順序情報にしたがって、コンテンツサーバ１２からゲームファイルをダウンロードする。なお、この順序情報は、メタデータ（第１グループ７２ａ）に含まれており、情報処理装置１０は、第１グループ７２ａのダウンロード後、順序情報にしたがった順序で、グループ単位でのダウンロードを実行してもよい。このように、本実施例の情報処理システム１においては、ユーザが希望するプレイ態様、すなわちシングルプレイかマルチプレイかに応じて、ファイルのダウンロード順序が定められる。

図１２（ｆ）は、シングルプレイ用のダウンロード順序を示す。このダウンロード順序では、ダウンロードするブロックのブロック番号の順番が規定される。図中に示される番号は、ブロック番号を示す。このダウンロード順序では、第１グループ７２ａ、第２グループ７２ｂ、第４グループ７２ｄ、第３グループ７２ｃの順番でダウンロードされるため、図１２（ｆ）に示すように、第１ブロック２６１、第２ブロック２６２、第３ブロック２６３、第４ブロック２６４、第５ブロック２６５、第６ブロック２６６、第１２ブロック２７２、第１３ブロック２７３、第１４ブロック２７４、第１０ブロック２７０、第１１ブロック２７１、第７ブロック２６７、第８ブロック２６８、第９ブロック２６９の順番で、ブロックがダウンロードされる。

このように本実施例において、ダウンロードはブロック単位で管理される。圧縮署名暗号化されたブロックには、複数のファイルのデータが混在していることがあるが、既にダウンロード済みのブロックが、もう１度ダウンロードされることはない。情報処理装置１０は、ダウンロード済みのブロックを管理し、これからダウンロードするグループに、既にダウンロード済みのブロックが含まれていれば、それらをダウンロード対象から外し、まだダウンロードしていないブロックのみをダウンロードするように制御する。これによりダウンロード時間を効率的に短縮できるようになる。

図１２（ｇ）は、マルチプレイ用のダウンロード順序を示す。図中に示される番号は、ブロック番号を示す。このダウンロード順序では、第１グループ７２ａ、第３グループ７２ｃ、第４グループ７２ｄ、第２グループ７２ｂの順番でダウンロードされるため、図１２（ｇ）に示すように、第１ブロック２６１、第２ブロック２６２、第６ブロック２６６、第７ブロック２６７、第８ブロック２６８、第９ブロック２６９、第１０ブロック２７０、第１２ブロック２７２、第１３ブロック２７３、第１４ブロック２７４、第１１ブロック２７１、第３ブロック２６３、第４ブロック２６４、第５ブロック２６５の順番で、ブロックがダウンロードされる。

以上は、ゲームソフトウェアのデータ構造について説明した。以下においては、本実施例におけるパッチファイルについて説明するが、パッチファイルも、本ゲームソフトウェアと同様のデータ構造を有している。すなわち説明したように、パッチファイルも、ネストしたデータ構造をもち、ゲームデータは圧縮され、署名され、暗号化されたデータとして構成される。なおゲームソフトウェアは、書き換え不能なイメージファイルとしてＲＯＭ媒体４４に記録され、またはコンテンツサーバ１２から配信されて補助記憶装置２に記録される。パッチファイルは、コンテンツサーバ１２から適時ダウンロードされて補助記憶装置２に記録され、パスオーバレイ処理により、ファイル単位ないしはデータブロック単位で擬似的に上書きされて使用される。つまりゲームソフトウェアに含まれるファイルをパッチファイルにて更新される場合には、そのファイルについては、ゲームソフトウェアのパスではなく、パッチファイルのパスが設定されて使用されることになる。またパッチファイルが、ゲームにおける追加シナリオファイルを含む場合には、そのパッチファイルが使用される。

以下においては、圧縮署名暗号化されたパッチファイルを、ブロック単位で管理する仕組みについて説明する。たとえばバージョン１の古いパッチファイルと、バージョン２の新しいパッチファイルが存在する場合、既に情報処理装置１０が、バージョン１のパッチファイルをダウンロード済みであれば、バージョン２のパッチファイルにおいて、同じデータを含むブロックをダウンロードすることは、ネットワークリソースを無駄に使用し、またコンテンツサーバ１２の処理負荷を高めることにもなる。そこで情報処理装置１０において、既にダウンロード済みのデータについては、コンテンツサーバ１２からダウンロードすることなく、情報処理装置１０において再利用する。ゲームメーカは、異なるバージョン間のパッチファイルの差分情報を作成し、情報処理装置１０は、ダウンロード済みのパッチファイルのバージョン情報に対応する差分情報をコンテンツサーバ１２から取得し、その差分情報にしたがって、未ダウンロードのデータブロックのみをダウンロードする。以下、ゲームメーカにおいて、差分情報生成ソフトウェアが、パッチファイルの異なるバージョン間の差分情報を作成するための方法について説明する。

差分情報生成ソフトウェアは、圧縮前の最新のバージョンのパッチファイルと、直近の（１つ前の）バージョンのパッチファイル同士を比較して、同じデータブロックが存在するか判定する。
図１３は、再利用可能な圧縮後ブロックの検索方法を示す。図１３（ａ）は、圧縮前のバージョン１のパッチファイルを構成するデータブロック列の一例を示し、図１３（ｂ）は、圧縮前のバージョン２のパッチファイルを構成するデータブロック列の一例を示す。ここでＨで表現しているのは、各ブロックのハッシュ値であり、たとえばＳＨＡ−２５６アルゴリズムにしたがって、圧縮前の各ブロックのハッシュ値を予め計算しておく。

差分情報生成ソフトウェアは、ハッシュ値を比較して、バージョン２の圧縮前パッチファイルにおいて、バージョン１の圧縮前パッチファイルと同じハッシュ値をもつデータブロックを特定する。ここで同じハッシュ値をもつことは、データブロックに含まれるデータが同一であることを意味している。図１３（ｂ）において、ハッチングを付したデータブロックは、異なるハッシュ値をもつことを示し、ハッチングを付していないデータブロックは、同一のハッシュ値をもつことを示している。

続いて、差分情報生成ソフトウェアは、バージョン２の圧縮前パッチファイルのデータブロックが、バージョン２の圧縮後パッチファイルのどのデータブロックに格納されているかを確認する。たとえば、Ｈ21のハッシュ値をもつデータブロックは、圧縮後のデータブロックＣ1の一部に格納されており、Ｈ22のハッシュ値をもつデータブロックは、圧縮後のデータブロックＣ1の一部と、データブロックＣ2の一部に格納されている。このように確認していくと、データブロックＣ4には、Ｈ11のハッシュ値をもつデータブロックの一部と、Ｈ12のハッシュ値をもつデータブロックの一部が格納されていることが判定される。同様に、データブロックＣ7には、Ｈ5のハッシュ値をもつデータブロックの一部と、Ｈ6のハッシュ値をもつデータブロックと、Ｈ7のハッシュ値をもつデータブロックの一部が格納されていることが判定される。またデータブロックＣ11には、Ｈ16のハッシュ値をもつデータブロックの一部と、Ｈ17のハッシュ値をもつデータブロックの一部が格納されており、データブロックＣ13には、Ｈ18のハッシュ値をもつデータブロックの一部と、Ｈ19のハッシュ値をもつデータブロックの一部が格納されている。

このことはつまり、バージョン２の圧縮後パッチファイルのうち、バージョン１のパッチファイルを既に有しているユーザに対しては、データブロックＣ4、Ｃ7、Ｃ11、Ｃ13のデータブロックは送信する必要がないことを意味している。これらのデータブロックＣ4、Ｃ7、Ｃ11、Ｃ13に含まれるデータは、既にユーザがバージョン１のパッチファイルとしてダウンロード済みであるからである。一方で、データブロックＣ1〜Ｃ3、Ｃ5〜Ｃ6、Ｃ8〜Ｃ10、Ｃ12、Ｃ14には、バージョン１のパッチファイルから変更されたデータが含まれており、したがって、これらのデータブロックは、送信する必要があることが判定される。

このように差分情報生成ソフトウェアは、圧縮前パッチファイルにおける各データブロックのハッシュ値を異なるバージョン間で比較することで、同一のデータブロックであるか否かを判定する。その後、差分情報生成ソフトウェアは、バージョン２の圧縮後パッチファイルのデータブロックごとに、そのブロックに更新されているデータが含まれているか、また含まれていなければ（バージョン１のデータのみが含まれていれば）、バージョン１の圧縮後パッチファイルのどのアドレスに記録されているかを示す差分情報を作成する。差分情報はバージョン２の圧縮後パッチファイルのデータブロックごとに生成され、バージョン２で更新されたデータを含むデータブロックについては、フラグ０が設定され、一方で、バージョン１のデータのみから構成されるデータブロックについては、フラグ１とともに、バージョン１のパッチファイルにおける格納位置を示す情報とが設定される。

なお、バージョン２の圧縮後パッチファイルは、バージョン２の圧縮前パッチファイルを作成後、その圧縮前パッチファイルを圧縮し、署名し、暗号化することで作成されてもよいが、同じデータブロックについては、バージョン１の圧縮後パッチファイルを復号して再暗号化することで作成されてもよい。

以下、差分情報の生成方法を説明する。
図１４は、ブロックの差分情報の生成方法を説明するための図である。図１４（ａ）は、バージョン１の圧縮前パッチファイルの５つのブロックＰ、Ｑ、Ｒ、Ｓ、Ｔを示す。図１４（ｂ）は、バージョン１の圧縮後パッチファイルのブロック１〜３を示す。各ブロック１〜３は、６４キロバイトのサイズで構成されている。図１４（ｂ）において、ブロックＴのデータが含まれるブロックサイズが、ブロック１〜３と異なっているように示されているが、実際には、圧縮前の後続のデータが格納されてブロックサイズは同じとされるものであり、単なる説明図であるということでご理解いただきたい。バージョン１の圧縮後のブロック１には、ブロックＰのデータと、ブロックＱのデータの一部が、ブロック２には、ブロックＱのデータの一部と、ブロックＲのデータの一部が、ブロック３には、ブロックＲのデータの一部と、ブロックＳのデータが格納されている。

図１４（ｄ）は、バージョン２の圧縮前パッチファイルの５つのブロックＰ’、Ｑ’、Ｒ、Ｓ、Ｔを示す。図１４（ｃ）は、バージョン２の圧縮後パッチファイルのブロック１〜３を示す。ここで図１４（ａ）、（ｄ）を参照して、圧縮前パッチファイルのバージョン間を比較すると、バージョン２においては、圧縮前のブロックＰとブロックＱのデータに更新があり、ブロックＲとブロックＳとブロックＴには更新がない（なお、以下の説明においては、ブロックＴについては考慮しない）。バージョン２の圧縮後のブロック１には、ブロックＰ’のデータと、ブロックＱ’のデータの一部が、ブロック２には、ブロックＱ’のデータの一部と、ブロックＲのデータの一部が、ブロック３には、ブロックＲのデータの一部と、ブロックＳのデータの一部が格納されている。

バージョン２のブロック３に着目すると、ブロック３には、バージョン１でも共通のブロックＲとブロックＳのデータが格納されている。したがって、情報処理装置１０が既にバージョン１のパッチファイルをダウンロードしていれば、バージョン２のブロック３に格納されたデータは、既に情報処理装置１０において取得済みであることが分かる。そこで本実施例においては、情報処理装置１０は、バージョン２のブロック３をダウンロードせずに、バージョン１のデータを再利用するようにする。

そのために差分情報生成ソフトウェアは、バージョン２のブロック３のデータが、バージョン１において、どのアドレスに格納されているかを示す情報（バージョン１における格納位置を示す情報）を含む差分情報を生成する。図示されるように、バージョン２のブロック３のデータは、バージョン１におけるブロック１の先頭アドレスからオフセットされたアドレスから連続して格納されている。したがって、バージョン２のブロック３の差分情報は、バージョン１のブロック１の先頭アドレスからのオフセット情報として記録される。たとえばブロック１の先頭アドレスが０、オフセット量が１００キロバイトであれば、バージョン２のブロック３の差分情報は、ブロック１の先頭アドレスから１００キロバイトオフセットされたアドレスを示すオフセット情報として生成される。なお、オフセット量が、ブロック内におけるオフセットとして定義される場合には、ブロック１の先頭アドレスが０、ブロック２の先頭アドレスが６４キロバイト、オフセット量が３６キロバイトとして、バージョン２のブロック３の差分情報は、ブロック２の先頭アドレスから３６キロバイトオフセットされたアドレスを示すオフセット情報として生成されてよい。

このように差分情報生成ソフトウェアが差分情報を生成することで、この差分情報をダウンロードした情報処理装置１０は、差分情報を参照して、バージョン２のブロック３のデータを、バージョン１のパッチファイルから再利用することができる。なお、バージョン２のブロック３のデータは、バージョン１のブロック２とブロック３にまたがって格納されているため、情報処理装置１０は、バージョン１のブロック２とブロック３とを復号、伸張して、バージョン２のブロック３に対応するデータを取得できるようになる。

一方で、バージョン２のブロック１とブロック２には、更新されたブロックＰ’、Ｑ’のデータが含まれている。したがってバージョン２のブロック１とブロック２の差分情報は、バージョン１のデータを再利用できないことを示す情報、すなわち、更新されたデータが含まれており、バージョン２のデータを利用することを示す情報となる。

以上のように、ゲームメーカは、パッチファイルおよび差分情報を作成し、コンテンツサーバ１２においてダウンロード可能に保持させる。コンテンツサーバ１２は、最新のパッチファイルと、差分情報が保持され、過去のパッチファイルについては破棄して保持しない。

次に、パッチファイルが複数回更新されている場合について説明する。たとえば、２回の更新が行われて、コンテンツサーバ１２から、バージョン３のパッチファイルをダウンロード可能とする場合、コンテンツサーバ１２は、バージョン１とバージョン３との差分情報と、バージョン２とバージョン３との差分情報とをダウンロード可能に保持している必要がある。それは、ユーザが常に最新のパッチファイルをアップデートしているとは限らず、たとえばバージョン１のパッチファイルのダウンロード後、バージョン２のパッチファイルをダウンロードしていないことも考えられるためである。以下、バージョンごとの差分情報を作成する方法について説明する。

図１５は、複数バージョンの差分情報の生成方法を説明するための図である。図１５（ａ）は、バージョン１の圧縮前パッチファイルの５つのブロックＵ、Ｖ、Ｗ、Ｘ、Ｙを示す。図１５（ｂ）は、バージョン１の圧縮後パッチファイルのブロック１〜３を示す。各ブロック１〜３は、６４キロバイトのサイズで構成されている。バージョン１の圧縮後のブロック１には、ブロックＵのデータと、ブロックＶのデータの一部が、ブロック２には、ブロックＶのデータの一部と、ブロックＷのデータの一部が、ブロック３には、ブロックＷのデータの一部と、ブロックＸのデータが格納されている。

図１５（ｃ）は、バージョン２の圧縮後パッチファイルのブロック１〜３を示す。ここではバージョン１の圧縮前パッチファイルと比較すると、ブロックＵがブロックＵ’に更新されており、バージョン２の圧縮後パッチファイルにおいては、ブロックＵとブロックＵ’の圧縮データサイズが異なるため、バージョン１とバージョン２とで、アライメントがずれている。バージョン２の圧縮後のブロック１には、ブロックＵ’のデータと、ブロックＶのデータの一部が、ブロック２には、ブロックＶのデータの一部と、ブロックＷのデータの一部が、ブロック３には、ブロックＷのデータの一部と、ブロックＸのデータの一部が格納されている。

図１５（ｄ）は、バージョン３の圧縮後パッチファイルのブロック１〜３を示す。ここではバージョン２の圧縮前パッチファイルと比較すると、ブロックＶがブロックＶ’に更新されており、バージョン３の圧縮後パッチファイルにおいては、ブロックＶとブロックＶ’の圧縮データサイズが異なるため、バージョン２とバージョン３とで、アライメントがずれている。バージョン３の圧縮後のブロック１には、ブロックＵ’のデータと、ブロックＶ’のデータの一部が、ブロック２には、ブロックＶ’のデータの一部と、ブロックＷのデータの一部が、ブロック３には、ブロックＷのデータの一部と、ブロックＸのデータの一部が格納されている。

ゲームメーカは、図１４に関して説明したように、バージョン２のパッチファイルを作成した時点で、バージョン１とバージョン２との間の差分情報を既に作成している。またゲームメーカは、バージョン３のパッチファイルを作成すると、その直近のバージョン、すなわちバージョン２とバージョン３の差分情報を作成する。この差分情報の作成は、図１４に関して説明したとおりである。

ここでバージョン１とバージョン３の間の差分情報について考察する。図１５に示す例において、バージョン１〜３において、ブロックＷとブロックＸに変更はない。前後のバージョン間のオフセット、すなわちバージョン３とバージョン２のオフセットと、バージョン２とバージョン１のオフセットとが、差分情報として定義済みであれば、図示される関係を利用して、それぞれのオフセットを合成することで、バージョン３とバージョン１のオフセットを導出することができる。

ここで、バージョン２とバージョン３の差分情報において、バージョン３のブロック３が、バージョン２のブロック２とブロック３を参照しており（すなわちバージョン３のブロック３がバージョン２のブロック２とブロック３に含まれており）、バージョン２のブロック２とブロック３とが、共にバージョン１を参照可能なブロックであれば（すなわちバージョン２のブロック２とブロック３とが、バージョン１に含まれているデータブロックであれば）、差分情報生成ソフトウェアは、バージョン３のブロック３が、バージョン１のブロックを参照可能であることを判定する。つまり、この場合には、差分情報生成ソフトウェアが、バージョン３のブロック３が、バージョン１のパッチファイルに含まれていることを判定する。これにより差分情報生成ソフトウェアは、バージョン３とバージョン２のオフセットと、バージョン２とバージョン１のオフセットを合成することで、バージョン３のブロック３に関して、バージョン３とバージョン１のオフセットを導出することができるようになる。

図１６は、差分情報の合成方法を説明するための図である。このようにバージョン１とバージョン３の間の差分情報は、バージョン１とバージョン２の間の差分情報と、バージョン２とバージョン３の差分情報を合成することで、容易に導出することができる。この合成は、差分情報生成ソフトウェアによって実現されるが、合成処理は、ゲームメーカにおいて行われてもよいが、コンテンツサーバ１２において行われてもよい。

ゲームメーカは、パッチファイルおよびバージョンごとの差分情報を作成し、コンテンツサーバ１２においてダウンロード可能に保持させる。バージョンごとの差分情報は、最新のバージョンと、それ以前のバージョンとの差分情報であり、それ以前のバージョンが複数存在する場合には、その数だけ差分情報がコンテンツサーバ１２に保持される。なお差分情報の合成処理は、コンテンツサーバ１２において行われてもよい。ゲームメーカは、アプリケーションソフトウェアと最新パッチファイルとの差分情報を作成して、コンテンツサーバ１２においてダウンロード可能に保持させてもよい。たとえばバージョン３のパッチファイルがダウンロード可能となったときに、一度もパッチファイルをダウンロードしたことのないユーザがいることも考えられるためである。特に、パッチファイルが、アプリケーションソフトウェアのバグを修正する機能を有する場合には、アプリケーションソフトウェアとの差分情報を作成することで、効率的なダウンロード処理が実現される。

図１７は、差分情報生成装置の機能ブロックを示す。差分情報生成装置４００は、ブロック特定部４０２、オフセット導出部４０４、差分情報生成部４０６、合成部４０８および差分情報記録部４１０を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされたプログラム、ストレージなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。なおブロック特定部４０２、オフセット導出部４０４、差分情報生成部４０６の各機能は、ゲームメーカにおいて使用される開発ツールである差分情報生成ソフトウェアにより実現されてよい。合成部４０８の機能も、差分情報生成ソフトウェアにより実現されてよいが、コンテンツサーバ１２にインストールされる差分情報合成ソフトウェアにより実現されてもよい。

ブロック特定部４０２は、バージョンＺ（Ｚは自然数）の第１パッチファイルに含まれるデータブロックと、第１パッチファイルの次のバージョン（Ｚ＋１）の第２パッチファイルに含まれるデータブロックとを比較して、同一のデータブロックを特定する。具体的にブロック特定部４０２は、第２パッチファイルのデータブロックのハッシュ値と、第１パッチファイルのデータブロックのハッシュ値とを比較して、第２パッチファイルのデータブロックと同じハッシュ値をもつ第１パッチファイルのデータブロックが存在するか否かを確認する。

第２パッチファイルのデータブロックのハッシュ値が、第１パッチファイルのいずれかのデータブロックと等しい場合、ブロック特定部４０２は、その第２パッチファイルのデータブロックが、第１パッチファイルに含まれていることを判定する。このとき、オフセット導出部４０４は、第２パッチファイルのデータブロックと同じ第１パッチファイルのデータブロックの格納位置を示すアドレス情報を、オフセット情報として導出する。差分情報生成部４０６は、第２パッチファイルの各データブロックごとに、第１パッチファイルから更新されているデータが含まれているか否かを示す情報を含む差分情報を生成する。差分情報生成部４０６は、更新されているデータが含まれているデータブロックについては、更新されたデータを含むデータブロックであることを示すフラグ０を差分情報として設定し、更新されているデータが含まれていないデータブロックについては、更新されていないデータから構成されるデータブロックであることを示すフラグ１と、第１パッチファイルにおけるデータ格納位置を示すアドレス情報（オフセット情報）とを差分情報として設定する。差分情報生成部４０６は、第２パッチファイルの全てのデータブロックについて差分情報を生成し、差分情報記録部４１０に格納する。

以上は、差分情報生成部４０６が、バージョンＺの第１パッチファイルと、次のバージョン（Ｚ＋１）の第２パッチファイルとの差分情報を生成することについて説明した。ゲームメーカにおいて第２パッチファイルの次のバージョン（Ｚ＋２）の第３パッチファイルが生成されると、差分情報生成部４０６は、上記した手順により、第２パッチファイルと第３パッチファイルとの差分情報を生成する。このように差分情報生成部４０６は、新たに生成されたパッチファイルについて、その前のバージョンのパッチファイルとの差分情報を生成する。この差分情報の生成処理は、ゲームメーカにおいて行われる。

以下、差分情報の合成処理について説明する。差分情報記録部４１０に、第１パッチファイルと第２パッチファイルとの第１差分情報と、第２パッチファイルと第３パッチファイルとの第２差分情報とが記録されている場合について説明する。説明の便宜上、Ｚ＝１とし、すなわち第１パッチファイルは、バージョン１のパッチファイル、第２パッチファイルは、バージョン２のパッチファイル、第３パッチファイルは、バージョン３のパッチファイルであるとする。

合成部４０８は、第１差分情報と第２差分情報とに基づいて、第１パッチファイルと第３パッチファイルの差分情報を生成する。この合成処理は、ゲームメーカにおいて行われてもよいが、ゲームメーカから第１差分情報と第２差分情報とを提供されたコンテンツサーバ１２の差分情報合成ソフトウェアにより行われてもよい。

具体的に合成部４０８は、第２差分情報をもとに、第３パッチファイルのデータブロックが、第２パッチファイルに含まれているものであるか否かを判定する。これは合成部４０８が、第２差分情報におけるデータブロックのフラグを参照することで行われ、フラグが１に設定されていれば、第３パッチファイルの当該データブロックが第２パッチファイルに含まれていることが判定される。たとえば、第３パッチファイルのデータブロックＬの第２差分情報におけるフラグが１に設定されており、データブロックＬのデータが、第２パッチファイルのデータブロックＭ、データブロック（Ｍ＋１）に含まれているものとする。

続いて合成部４０８は、第１差分情報をもとに、第２パッチファイルのデータブロックＭ、データブロック（Ｍ＋１）が、第１パッチファイルに含まれているものであるか否かを判定する。これは合成部４０８が、第１差分情報におけるデータブロックのフラグを参照することで行われ、データブロックＭ、データブロック（Ｍ＋１）のフラグが１に設定されていれば、これらのデータブロックが第１パッチファイルに含まれていることが判定される。たとえば、第２パッチファイルのデータブロックＭ、データブロック（Ｍ＋１）の第１差分情報におけるフラグが１に設定されており、データブロックＭ、データブロック（Ｍ＋１）のデータが、第１パッチファイルのデータブロックＮ、データブロック（Ｎ＋１）、データブロック（Ｎ＋２）に含まれているものとする。

このとき、合成部４０８は、第３パッチファイルのデータブロックＬが第２パッチファイルのデータブロックＭ、データブロック（Ｍ＋１）に含まれ、また第２パッチファイルのデータブロックＭ、データブロック（Ｍ＋１）が、第１パッチファイルのデータブロックＮ、データブロック（Ｎ＋１）、データブロック（Ｎ＋２）に含まれていることを判定する。これにより、第３パッチファイルのデータブロックＬが、第１パッチファイルのデータブロックＮ、データブロック（Ｎ＋１）、データブロック（Ｎ＋２）のうちの１つ以上のデータブロックに含まれていることが分かる。合成部４０８は、第２差分情報におけるデータブロックＬのオフセット情報と、第１差分情報におけるデータブロックＭ、データブロック（Ｍ＋１）それぞれのオフセット情報とから、第３パッチファイルのデータブロックＬの、第１パッチファイルにおけるオフセット情報を導出できる。このように合成部４０８は第２差分情報のフラグ値、および第１差分情報のフラグ値を参照することで、第３パッチファイルのデータブロックが第１パッチファイルに含まれているか否かを判定することができ、含まれている場合には、第１差分情報および第２差分情報におけるオフセット情報を用いて、第３パッチファイルのデータブロックＬのデータの、第１パッチファイルにおけるオフセット情報（格納位置）を特定することが可能となる。このように合成部４０８は、第３パッチファイルの各データブロックについて、第１パッチファイルとの差分情報を求めることで、第１パッチファイルと第３パッチファイルの差分情報を合成処理により生成することが可能となる。

このように合成部４０８は、第１差分情報と第２差分情報のみに基づいて、第１パッチファイルと第３パッチファイルの第３差分情報を生成できる。コンテンツサーバ１２は、最新の第３パッチファイル、第３パッチファイルと第２パッチファイルの差分情報（第２差分情報）と、第３パッチファイルと第１パッチファイルの差分情報（第３差分情報）とを、ダウンロード可能に保持する。なお、第１パッチファイルと第２パッチファイルの差分情報（第１差分情報）は破棄してよい。

第３パッチファイルの次のバージョンの第４パッチファイルが生成された場合には、ゲームメーカにより第３パッチファイルと第４パッチファイルの差分情報（第４差分情報）も生成される。差分情報記録部４１０には、第３パッチファイルと第２パッチファイルの第２差分情報と、第３パッチファイルと第１パッチファイルの第３差分情報とが記録されているが、合成部４０８は、第４差分情報と第２差分情報とを用いて、第４パッチファイルと第２パッチファイルとの差分情報を生成することができ、また第４差分情報と第３差分情報とを用いて、第４パッチファイルと第１パッチファイルとの差分情報を生成することができる。これによりコンテンツサーバ１２は、最新の第４パッチファイル、第４パッチファイルと第３パッチファイルの差分情報、第４パッチファイルと第２パッチファイルの差分情報、第４パッチファイルと第１パッチファイルの差分情報とを、ダウンロード可能に保持するようになる。

図１８は、情報処理装置１０におけるダウンロード処理を実行するための機能ブロックを示す。本実施例において、アプリケーションソフトウェアは、既に情報処理装置１０において記録されていることを前提とし、ダウンロード処理は、コンテンツサーバ１２からパッチファイルないしはパッチデータを取得して、補助記憶装置２に記録する処理である。

情報処理装置１０は、処理部３４０、通信部３４２および記録部３３０を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされたプログラム、ストレージなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

記録部３３０は、アプリケーションソフトウェアを記録するアプリケーション記録部３３２と、コンテンツサーバ１２から取得したパッチデータを記録するパッチ記録部３３４と、コンテンツサーバ１２から取得した差分情報を記録する差分情報記録部３３６とを備える。ここでアプリケーション記録部３３２は、アプリケーションソフトウェアを記録したＲＯＭ媒体４４であってもよく、またダウンロードしたアプリケーションソフトウェアを記録した補助記憶装置２であってもよい。パッチ記録部３３４および差分情報記録部３３６は、補助記憶装置２の記録領域に形成される。

通信部３４２は、入力装置６においてユーザが入力部を操作した操作情報を受信し、処理部３４０で生成した要求をコンテンツサーバ１２に送信し、コンテンツサーバ１２から配信されるデータを受信する。通信部３４２は図２に示す無線通信モジュール３８および有線通信モジュール４０の機能を併せ持つ構成として表現され、無線通信モジュール３８は入力装置６との通信を担当し、有線通信モジュール４０はコンテンツサーバ１２との通信を担当する。

処理部３４０は、コンテンツサーバ１２からパッチデータを取得するパッチ取得部３００と、アプリケーションソフトウェアおよびパッチデータを用いてアプリケーションを実行するアプリケーション実行部３１０とを備える。ここでパッチ取得部３００は、差分情報取得部３０２、ダウンロード実行部３０４および判定部３０６を有する。

差分情報取得部３０２は、パッチ記録部３３４に記録されているパッチファイルのバージョン情報を管理する。このバージョン情報は、パッチ記録部３３４において記録されていてもよい。通信部３４２が、入力装置６からパッチファイルの取得要求を受信すると、差分情報取得部３０２は、パッチ記録部３３４から、過去にダウンロードしたパッチファイルのうち、最新のバージョン情報を読み出す。たとえば、バージョン１のパッチファイルと、バージョン２のパッチファイルが既にパッチ記録部３３４に記録されていれば、差分情報取得部３０２は、最新のバージョン２のバージョン情報を読み出す。なお、バージョン２のパッチファイルがパッチ記録部３３４に記録された時点で、利用可能なデータを含むバージョン１のパッチファイルも、バージョン２のパッチファイルとして扱う場合には、パッチ記録部３３４には、常に最新のバージョンのパッチファイルのみが記録されていることとなり、差分情報取得部３０２は、そのバージョンのパッチファイルのバージョン情報を読み出す。

差分情報取得部３０２は、保持しているパッチファイルのバージョン情報を差分情報の取得要求に含めてコンテンツサーバ１２に送信する。コンテンツサーバ１２は、取得要求を受けると、指定されたバージョン情報に対応する差分情報を情報処理装置１０に送信する。たとえば、コンテンツサーバ１２がバージョン３のパッチファイルをダウンロード可能に保持している場合、取得要求に含まれるバージョン情報がバージョン２を示していれば、コンテンツサーバ１２は、バージョン２とバージョン３の間の差分情報を送信する。なおパッチ記録部３３４がバージョン１のパッチファイルのみを記録している場合には、差分情報の取得要求に、バージョン１のバージョン情報が含まれるため、コンテンツサーバ１２は、バージョン１とバージョン３の間の差分情報を送信する。

このようにして差分情報取得部３０２は、コンテンツサーバ１２が保持する最新のパッチファイルと、パッチ記録部３３４に記録しているパッチファイルとのデータブロックの差分情報を取得する。すなわち差分情報取得部３０２は、パッチ記録部３３４に記録しているパッチファイルのバージョン情報に対応する差分情報をコンテンツサーバ１２から取得し、差分情報記録部３３６に記録する。

ダウンロード実行部３０４は、取得した差分情報にしたがって、コンテンツサーバ１２に保持された最新のパッチファイルから、更新があったデータブロックをダウンロードする。差分情報には、最新のパッチファイルのデータブロックごとに、パッチ記録部３３４に記録済みのパッチデータにおける格納位置を示す情報と、更新されたデータブロックであることを示す情報のいずれかが含まれている。したがってダウンロード実行部３０４は、更新されたデータブロックであることを示す情報が記述されたデータブロックのみをダウンロードし、記録済みのパッチデータにおけるアドレスオフセットが差分情報として記述されたデータブロックはダウンロードしない。

コンテンツサーバ１２に保持されている最新のパッチファイルが、たとえば１００００個のデータブロックで構成されている場合（１６メガバイト）に、９０００個のデータブロックに対してアドレスオフセットが記述されていれば、ダウンロード実行部３０４は、１０００個のデータブロックをダウンロードするだけでよい。１６メガバイトをダウンロードする場合と比較すると、そのダウンロードデータ量は１／１０となり、ダウンロードにかかる時間を短縮できるとともに、コンテンツサーバ１２における処理負荷を下げることができる。ダウンロード実行部３０４は、コンテンツサーバ１２に対して、ブロック番号を指定したダウンロード要求を送信し、コンテンツサーバ１２は、指定されたブロック番号のデータブロックを情報処理装置１０に送信する。ダウンロード実行部３０４は、取得したパッチデータを、バージョン情報に対応付けてパッチ記録部３３４に記録する。

ダウンロード実行部３０４は、ダウンロード要求を送信する前に、コンテンツサーバ１２からダウンロード順序を示す順序情報を取得してもよい。ユーザがパッチデータをダウンロードする前に、出力装置４の画面には「シングルプレイ用のパッチデータを優先的にダウンロードする」、「マルチプレイ用のパッチデータを優先的にダウンロードする」の選択肢が提示され、コンテンツサーバ１２は、選択された選択肢にしたがって、グループのダウンロード順序を示す順序情報およびパッチに関するグループファイルを情報処理装置１０に提供する。ダウンロード実行部３０４は、順序情報を受け取ると、その順序情報にしたがって、コンテンツサーバ１２からパッチデータをダウンロードする。図１２においてゲームソフトウェアのダウンロード順序について説明したように、本実施例のパッチファイルも、グループ単位でダウンロード順序を設定可能であり、これによりユーザのニーズに合わせた効率的なダウンロード処理が実行されてよい。

判定部３０６は、グループ単位でパッチファイルがパッチ記録部３３４に記録されているか判定する。判定部３０６は、ダウンロード実行部３０４が取得したグループファイルを参照して、グループに属するファイルが全てパッチ記録部３３４に記録されているか判定する。なお１つのファイルが、複数のバージョンのパッチデータに含まれている可能性もあり、したがって判定部３０６は、ファイルを構成するデータブロックが、どのバージョンのどのブロック番号に対応するかを差分情報をもとに把握し、グループに属するファイルごとに、全てのデータブロックがパッチ記録部３３４に記録されているか判定する。判定部３０６は、グループに属する全てのファイルがパッチ記録部３３４に記録されたことを判定すると、その旨をアプリケーション実行部３１０に通知して、これによりアプリケーションは、そのグループのファイルを使用できることを認識できるようにしてもよい。

アプリケーション実行部３１０は、アプリケーション記録部３３２に記録されたアプリケーションソフトウェア、およびパッチ記録部３３４に記録されたパッチデータを用いて、アプリケーションを実行する。既述したようにアプリケーションはゲームであってよい。アプリケーション実行部３１０は、差分情報を用いて、ファイルを構成するデータブロックの格納位置を特定し、パッチ記録部３３４から必要なパッチデータを読み出す。１つのファイルが、異なるバージョンのパッチデータとして記録されている場合には、それぞれのデータのパス情報を設定して、パッチ記録部３３４から読み出す。このパス情報は、差分情報にしたがって設定される。

このように本実施例によると、ダウンロード実行部３０４は、パッチデータのダウンロード処理において、既にパッチ記録部３３４に記録したデータのみを格納するデータブロックをダウンロードしないため、結果として、パッチ記録部３３４に記録するデータ量を削減でき、パッチ記録部３３４の記録領域を有効に利用できる。最新のパッチファイル全体を全てダウンロードし、過去にダウンロードしたパッチファイルを削除するようなダウンロード方法と比較すると、実施例のダウンロード方法は、必要なデータブロックのみのダウンロードで済むために、ダウンロードにかかる時間を大幅に短縮することが可能となる。

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

１・・・情報処理システム、１０・・・情報処理装置、１２・・・コンテンツサーバ、３００・・・パッチ取得部、３０２・・・差分情報取得部、３０４・・・ダウンロード実行部、３０６・・・判定部、３１０・・・アプリケーション実行部、３３０・・・記録部、３３２・・・アプリケーション記録部、３３４・・・パッチ記録部、３３６・・・差分情報記録部、３４０・・・処理部、３４２・・・通信部。

Claims (10)

1. アプリケーションソフトウェアを記録するアプリケーション記録部と、
   サーバから、パッチデータを取得するパッチ取得部と、
   取得したパッチデータを記録するパッチ記録部と、
   アプリケーションソフトウェアおよびパッチデータを用いて、アプリケーションを実行するアプリケーション実行部と、を備えた情報処理装置であって、
   前記パッチ取得部は、
   サーバが保持する最新のパッチファイルと、前記パッチ記録部に記録しているパッチファイルとのデータブロックの差分情報を取得する差分情報取得部と、
   差分情報にしたがって、最新のパッチファイルから、更新があったデータブロックをダウンロードするダウンロード実行部と、
   を備えることを特徴とする情報処理装置。
2. 前記差分情報取得部は、前記パッチ記録部に記録しているパッチファイルのバージョン情報に対応する差分情報をサーバから取得することを特徴とする請求項１に記載の情報処理装置。
3. 差分情報は、前記記録部に記録しているパッチデータにおける格納位置を示す情報と、更新されたデータブロックであることを示す情報のいずれかを含むことを特徴とする請求項１または２に記載の情報処理装置。
4. 前記アプリケーション実行部は、差分情報を用いて、アプリケーションを実行することを特徴とする請求項１から３のいずれかに記載の情報処理装置。
5. アプリケーションソフトウェアおよびパッチファイルは、それぞれ複数のファイルから構成されており、各ファイルは、複数のグループのうち少なくとも１つのグループに属するものであって、
   グループ単位でファイルが記録されているか判定する判定部をさらに有することを特徴とする請求項１から４のいずれかに記載の情報処理装置。
6. パッチデータは、暗号化されたデータであることを特徴とする請求項１から５のいずれかに記載の情報処理装置。
7. 第１パッチファイルと、第１パッチファイルの次のバージョンの第２パッチファイルとの第１差分情報と、第２パッチファイルと、第２パッチファイルの次のバージョンの第３パッチファイルとの第２差分情報とを記録する記録部と、
   第１差分情報と第２差分情報とに基づいて、第１パッチファイルと第３パッチファイルの差分情報を生成する合成部と、を備え、
   差分情報は、新しいバージョンのパッチファイルのデータブロックごとに、前のバージョンのパッチファイルから更新されているデータが含まれているか否かを示す情報を含んでおり、更新されているデータが含まれていない場合には、前のバージョンのパッチファイルにおけるデータ格納位置を示すアドレス情報が含まれることを特徴とする差分情報生成装置。
8. コンピュータに、
   サーバが保持する最新のパッチファイルと、コンピュータ側で記録しているパッチファイルとのデータブロックの差分情報を取得する機能と、
   差分情報にしたがって、最新のパッチファイルから、更新があったデータブロックをダウンロードする機能と、
   を実現するためのプログラム。
9. コンピュータに、
   第１パッチファイルと、第１パッチファイルの次のバージョンの第２パッチファイルとの第１差分情報と、第２パッチファイルと、第２パッチファイルの次のバージョンの第３パッチファイルとの第２差分情報とを記録する記録部から、第１差分情報と第２差分情報とを読み出す機能と、
   第１差分情報と第２差分情報とに基づいて、第１パッチファイルと第３パッチファイルの差分情報を生成する機能と、を実現するためのプログラムであって、
   差分情報は、新しいバージョンのパッチファイルのデータブロックごとに、前のバージョンのパッチファイルから更新されているデータが含まれているか否かを示す情報を含んで構成されており、更新されているデータが含まれていない場合には、前のバージョンのパッチファイルにおけるデータ格納位置を示すアドレス情報が含まれる、
   ことを特徴とするプログラム。
10. 請求項８または９に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images