JP4838338B2 - 情報処理装置 - Google Patents

Description

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

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

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

インターネットの発達により、パッチファイルを、サーバからインターネット経由でユーザ端末に配信する環境が実現されている。また従来から、パッチファイルを組み込んでリマスタリングしたＲＯＭ媒体を販売することで、不具合を改善したゲームソフトウェアをユーザに提供することも行われている。リマスタリングしたＲＯＭ媒体において、ゲームソフトウェアはパッチを当てられた形態で記録される。

ユーザ端末が、パッチファイルをインターネット経由で取得してインストールする場合、このパッチファイルは、ハードディスクドライブなどの補助記憶装置に格納されるため、パッチファイルにおいて、モジュールを特定するためのパス情報は、補助記憶装置に格納されていることを前提に作成される。一方で、リマスタリングしたＲＯＭ媒体においてはモジュールがすべてＲＯＭ媒体に記録されているため、パス情報は、当然のことながら、ＲＯＭ媒体のアドレスにしたがって作成される。そのためゲームソフトウェアの提供者は、パッチファイルをサーバから提供する場合と、ＲＯＭ媒体をリマスタすることで提供する場合とで、異なるパッチファイルを用意する必要があった。また、リマスタリング後に、新たなパッチファイルをサーバから提供する場合にも、初期のＲＯＭ媒体に対するパッチファイルと、リマスタリングしたＲＯＭ媒体に対するパッチファイルを作成する必要があり、ゲームソフトウェアの提供者にとって手のかかる作業となっていた。またユーザ側からみても、パッチファイルをインターネット経由でインストールするとき、初期ＲＯＭ媒体用とリマスタリングしたＲＯＭ媒体用の両方のパッチファイルをダウンロードして、ダウンロード後に、使用しているＲＯＭ媒体に応じていずれを利用するか決定しているが、これは、時間およびコストの観点から好ましくない。

また、たとえば、リマスタリングしたＲＯＭ媒体に対するパッチファイルをダウンロードした後、初期ＲＯＭ媒体を用いてゲームソフトウェアを実行しようとすると、リマスタリングしたＲＯＭ媒体には含まれていたパッチファイルが補助記憶装置に存在しないために、いわゆるパッチの「中抜け」という不具合が生じる可能性もあった。

そこで本発明は、パッチファイルをアプリケーションソフトウェアに好適に適用できる技術を提供することを目的とする。

上記課題を解決するために、本発明のある態様の情報処理装置は、アプリケーションソフトウェアおよびパッチファイルを記録した記録媒体からデータを読み出すドライブ装置と、ドライブ装置によるデータの読み出しを制御する読出制御部と、アプリケーションソフトウェアを起動する実行処理部と、記憶装置とを備える。読出制御部は、アプリケーションソフトウェアの実行要求を受けると、ドライブ装置に記録媒体からパッチファイルを読み出させて、記憶装置にインストールし、パッチファイルのインストール後、実行処理部は、記憶装置にインストールされたパッチファイルを適用して、アプリケーションソフトウェアを起動する。

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

本発明の情報処理技術によると、パッチファイルをアプリケーションソフトウェアに好適に適用する技術を提供することが可能となる。

本発明の実施例にかかるファイル配信システムを示す図である。 ゲーム装置の機能ブロック図を示す図である。 ゲーム装置におけるパッチファイル取得処理を実行するための機能ブロックを示す図である。 表示機器に表示されるメニュー画面を示す図である。 バージョンファイルの一例を示す図である。 （ａ）は従来型のリマスタリングしたＲＯＭ媒体を用いて、パッチファイルを取得したときのインストール状況を示す図であり、（ｂ）は本実施例のＲＯＭ媒体を用いて、パッチファイルを取得したときのインストール状況を示す図である。 ゲーム装置におけるパッチファイル取得処理のフローチャートを示す図である。 ＲＯＭ媒体に記録されたパッチファイルのインストール確認画面を示す図である。 ファイル提供サーバに保持されたパッチファイルのインストール確認画面を示す図である。

本発明の実施例を具体的に説明する前に、まず概要を述べる。本実施例の情報処理装置は、リマスタリングした記録媒体に記録されたアプリケーションソフトウェアを実行する。記録媒体には、アプリケーションソフトウェアだけでなく、そのアプリケーションソフトウェアに適用するためのパッチファイルが記録されている。アプリケーションソフトウェアはパッチを当てた形態で記録されているのではなく、アプリケーションソフトウェアとパッチファイルとが別個独立して記録されている点で、従来のリマスタリングした記録媒体の記録形態とは異なっている。

情報処理装置は、アプリケーションソフトウェアの実行要求がユーザより入力されると、アプリケーションソフトウェアを起動する前に、記録媒体からパッチファイルを読み出して、ハードディスクドライブなどの記憶装置にインストールする。この後、情報処理装置は、インストールしたパッチファイルを適用して、アプリケーションソフトウェアを起動する。記録媒体に記録するパッチファイルは、サーバから提供するパッチファイルと同じものでよいため、ゲームソフトウェア提供者によるパッチファイルの作成負荷が低減される。またユーザ端末においては、パッチの中抜けが発生する可能性を低減もしくはなくすことができる利点もある。

図１は、本発明の実施例にかかるファイル配信システム１を示す。ファイル配信システム１は、ゲームソフトウェアの好適な実行環境を提供するゲームシステムにおいて構築され、ゲームソフトウェアに適用するパッチファイルの取得処理を支援する。

ファイル配信システム１は、ユーザ端末であるゲーム装置１０と、ゲームソフトウェアに適用するパッチファイルのバージョンを管理する管理サーバ１２と、パッチファイルを提供するファイル提供サーバ１６ａ、１６ｂ（以下、総称して「ファイル提供サーバ１６」とよぶ）とを備える。ゲーム装置１０、管理サーバ１２およびファイル提供サーバ１６は、インターネットなどのネットワーク１８を介して通信可能に接続される。

管理サーバ１２は、ゲームシステムの運営主体により管理され、ゲームソフトウェアごとに、パッチファイルのバージョン情報と、パッチファイルを格納する位置を示すアドレス情報とを対応づけたパッチ情報を含むバージョンファイルを保持している。ゲームソフトウェアに対して複数のパッチファイルが作成されている場合、バージョンファイルには、それぞれのパッチファイルに関するパッチ情報が含められる。

管理サーバ１２は、たとえばゲームソフトウェアの識別情報（以下、「タイトルＩＤ」とよぶ）をディレクトリ名および／またはファイル名に用いたアドレス（ＵＲＬ）にバージョンファイルを格納する。ゲームソフトウェアのタイトルＩＤをディレクトリ名および／またはファイル名に用いるアドレス生成手法は、管理サーバ１２およびゲーム装置１０の間で共通化されている。したがってゲーム装置１０は、起動するゲームソフトウェアのタイトルＩＤを用いてアドレスを生成し、管理サーバ１２にアクセスすることで、ゲームソフトウェアのバージョンファイルを取得できる。

ファイル提供サーバ１６は、ゲームソフトウェアの提供者（たとえばゲームメーカ）により管理され、ゲームソフトウェアに適用するパッチファイルを保持している。パッチファイルは、ＲＯＭ媒体中のプログラムのバグを修正したり、機能を変更または追加などするために使用される。本実施例におけるパッチファイルは、前のバージョンのパッチファイルからの差分プログラムなどを含む形式で作成され、ゲーム装置１０の記憶装置にインストールされる際には、前のバージョンのパッチファイルに統合された差分ファイルの形式で保持される。したがって、ゲームソフトウェアに対して差分ファイルを適用することで、全てのバージョンのパッチが当てられたゲームソフトウェアが実行される。

ゲームメーカは、ゲームソフトウェアのパッチファイルを生成すると、ファイル提供サーバ１６に格納して、ゲーム装置１０が、パッチファイルをファイル提供サーバ１６からダウンロードできるようにする。ゲームメーカは、生成したパッチファイルをダウンロード可能な状態にすると、ゲームシステムの運営主体に対して、タイトルＩＤ、パッチファイルのバージョン情報、パッチファイルを格納する位置を示すアドレス情報などを含むパッチ情報を通知する。この通知は、オンラインで行われてもオフラインで行われてもよい。システム運営主体は、パッチ情報を受け取ると、パッチ情報の内容をバージョンファイルに追加して、バージョンファイルを更新する。

本実施例のファイル配信システム１において、ゲーム装置１０に電源が投入されると、まずオペレーティングシステム（以下、単に「ＯＳ（Operating System）」と呼ぶ）が起動されて、ゲームソフトウェアの実行環境が整えられる。ゲーム装置１０のドライブ装置に、ゲームソフトウェアを記録した記録媒体が装着され、ユーザからゲームの実行要求が入力されると、まずＯＳが、記録媒体にパッチファイルが記録されているか探索する。パッチファイルが記録されている場合には、ドライブ装置がパッチファイルを補助記憶装置に読み出して、インストールする。パッチファイルのインストールが完了すると、ドライブ装置が、補助記憶装置に保持されたパッチファイルの起動ファイルを読み出し、ゲーム装置１０は、起動ファイルを実行して、ゲームソフトウェアにパッチを当てる。

ゲーム装置１０は、ゲームソフトウェアを起動すると、起動処理を行いながら、同時にネットワーク１８を介して管理サーバ１２にアクセスし、起動したゲームソフトウェアのバージョンファイルを取得する。ゲーム装置１０は、バージョンファイルに、インストールしたパッチファイルのバージョン情報よりも、新しいバージョン情報が含まれるか判断する。バージョンファイルに、保有していないパッチファイルのバージョン情報が含まれている場合、ゲーム装置１０は、ファイル提供サーバ１６にアクセスし、保有していないパッチファイルをダウンロードして、ゲームソフトウェアを再起動する。これによりゲーム装置１０は、最新の状態でゲームアプリケーションを実行する。

本実施例に示す技術は、ゲーム装置１０に限らず、会計ソフトやＣＡＤソフトなどのプログラムが記録されたＲＯＭ媒体を装着される情報処理装置においても実現できる。

図２は、ゲーム装置１０の機能ブロック図を示す。ゲーム装置１０は、電源ボタン２０、ＬＥＤ２２、システムコントローラ２４、デバイスコントローラ３０、メディアドライブ３２、ハードディスクドライブ３４、スイッチ３６、無線インタフェース３８、メインコントローラ１００、メインメモリ１０２および出力処理部２００を有して構成される。

電源ボタン２０は、ユーザからの操作入力が行われる入力部であって、ゲーム装置１０への電源供給をオンまたはオフするために操作される。ＬＥＤ２２は、電源のオンまたはオフの状態を点灯表示する。システムコントローラ２４は、電源ボタン２０の押下状態または非押下状態を検出し、電源オフの状態から押下状態への状態遷移を検出すると、メインコントローラ１００を起動し、またＬＥＤ２２を点灯制御する。ゲーム装置１０に電源ケーブルが差し込まれている場合、システムコントローラ２４は、電源オフの状態であってもスタンバイモードを維持して、電源ボタン２０の押下を監視する。

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

メディアドライブ３２は、ゲームソフトウェアおよびパッチファイルを記録したＲＯＭ媒体５０を装着して駆動し、ＲＯＭ媒体５０からゲームソフトウェアおよびパッチファイルを読み出すドライブ装置である。ＲＯＭ媒体５０は、光ディスクや光磁気ディスク、ブルーレイディスクなどの読出専用の記録メディアである。

ゲームソフトウェアは、ゲームアプリケーションを実行させるメインプログラムと、メインプログラムを起動するための起動ファイルと、ゲームキャラクタやシナリオなどのゲームデータ、ゲームソフトウェアのタイトルＩＤ、ゲームソフトウェアのバージョン情報などを含んでいる。

メインプログラムは、アプリケーションの実行に必要なプログラムであり、メインプログラムを走らせることで、ゲームアプリケーションが進行する。起動ファイルは、メインプログラムを起動するためのプログラムであり、起動ファイルを実行すると、メインプログラムが呼び出されて実行される。

パッチファイルは、メインプログラムを起動するための起動ファイルと、ゲームソフトウェアのメインプログラムを修正するための修正プログラムや、追加されたゲームデータ、ゲームソフトウェアのタイトルＩＤ、パッチファイルのバージョン情報などを含んでいる。ＲＯＭ媒体５０において、パッチファイルはゲームソフトウェアに適用された形態ではなく、ゲームソフトウェアとは別個に記録されている。

ゲームソフトウェアのバージョン情報およびパッチファイルのバージョン情報は、それぞれの生成順を特定できるものであればよい。たとえばゲームソフトウェアのバージョン情報を「１」、最初に作成されたパッチファイルのバージョン情報を「２」、その次に作成されたパッチファイルのバージョン情報を「３」とするように、新しく作成されたパッチファイルには、それ以前に作成されたパッチファイルおよびゲームソフトウェアよりも大きな数字がバージョン情報として付与されてもよい。また単純にゲームソフトウェアの生成年月日、パッチファイルの生成年月日を特定する情報がバージョン情報として付与されてもよい。

ハードディスクドライブ３４は、内蔵ハードディスクを駆動し、磁気ヘッドを用いてデータの書込／読出を行う補助記憶装置である。スイッチ３６は、イーサネットスイッチ（イーサネットは登録商標）であって、外部の機器と有線または無線で接続して、情報の送受信を行うデバイスである。本実施例では、スイッチ３６にケーブルが差し込まれ、ネットワーク１８と通信可能に接続している。さらにスイッチ３６は無線インタフェース３８に接続し、無線インタフェース３８は、Bluetooth（登録商標）プロトコルやIEEE802.11プロトコルなどの通信プロトコルで無線通信機能をもつ入力装置４０と接続する。入力装置４０は、ユーザからの操作入力が行われる入力手段である。

メインコントローラ１００は、マルチコアＣＰＵを備え、１つのＣＰＵの中に１つの汎用的なプロセッサコアと、複数のシンプルなプロセッサコアを有する。汎用プロセッサコアをＰＰＵ（Power Processing Unit）と呼び、残りのプロセッサコアをＳＰＵ（Synergistic-Processing Unit）と呼ぶ。

メインコントローラ１００は、主記憶装置であるメインメモリ１０２に接続するメモリコントローラを備える。ＰＰＵはレジスタを有し、演算実行主体としてメインプロセッサを備えて、各アプリケーションにおける基本処理単位としてのタスクを各ＳＰＵに効率的に割り当てる。なお、ＰＰＵ自身がタスクを実行してもよい。ＳＰＵはレジスタを有し、演算実行主体としてのサブプロセッサとローカルな記憶領域としてのローカルメモリ（専用ＲＡＭ）を備える。ＳＰＵは制御ユニットとして専用のＤＭＡ（Direct Memory Access）コントローラをもち、メインメモリ１０２とローカルメモリの間のデータ転送を行うことで、データを高速にストリーム処理でき、また出力処理部２００に内蔵されるフレームメモリとローカルメモリの間で高速なデータ転送を実現できる。

出力処理部２００は、表示機器６０に接続されて、アプリケーションの処理結果である映像信号および音声信号を出力する。出力処理部２００は、画像処理機能を実現するＧＰＵ（Graphics Processing Unit）を備える。ＧＰＵは、ＨＤＭＩ（High Definition Multimedia Interface）を採用し、映像信号をデジタル出力できる。

図３は、ゲーム装置１０におけるパッチファイル取得処理を実行するための機能ブロックを示す。図３では、デバイスコントローラ３０やメインメモリ１０２などの構成は省略している。メインコントローラ１００は、入力受付部１０４、実行処理部１１０および更新処理部１２０を備え、実行処理部１１０は、ＯＳを実行するＯＳ実行部１１２と、ゲームアプリケーションを実行するアプリケーション実行部１１４とを有する。更新処理部１２０は、取得部１３０、比較部１４０および読出制御部１４２を備える。取得部１３０は、バージョンファイル取得部１３２およびパッチファイル取得部１３６を有する。なお、図３ではパッチファイル取得処理に関わる構成を機能別に示しているが、たとえば読出制御部１４２は、ＯＳ実行部１１２により実行されるシステムソフトウェアの一機能である。

図３において、さまざまな処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、ＣＰＵ（Central Processing Unit）、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。既述したように、メインコントローラ１００には１つのＰＰＵと複数のＳＰＵとが設けられており、ＰＰＵおよびＳＰＵがそれぞれ単独または協同して、各機能ブロックを構成できる。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

電源が投入されると、ＯＳ実行部１１２が、ハードディスクドライブ３４に格納されたＯＳ１７０を起動する。メディアドライブ３２にＲＯＭ媒体５０が装着されると、メディアドライブ３２はＲＯＭ媒体５０を駆動する。ＯＳ実行部１１２は、ＲＯＭ媒体５０の認証処理を実行し、ＲＯＭ媒体５０が真正な媒体であることを判定すると、メニュー画面にゲームソフトウェアのアイコンを表示する。

図４は、表示機器６０に表示されるメニュー画面を示す。アイコン２０２は、ＲＯＭ媒体５０に記録されたゲームソフトウェアを特定する画像であり、選択領域２０４に配置されると図示のように大きく表示される。アイコン２０２が選択領域２０４に配置された状態で、ユーザが入力装置４０の所定のボタンを操作すると、入力受付部１０４が、ゲームの実行要求として受け付け、読出制御部１４２に供給する。

このとき読出制御部１４２は、メディアドライブ３２を制御して、ＲＯＭ媒体５０にパッチファイルが含まれているか探索させる。パッチファイルが含まれていれば、メディアドライブ３２は、パッチファイルのバージョン情報を読み出して、比較部１４０に供給する。なお、読み出されたバージョン情報は、ハードディスクドライブ３４を経由して、比較部１４０に供給されてもよい。ここでは、読み出されたバージョン情報が「２」と「３」であった場合を説明する。

比較部１４０は、ＲＯＭ媒体５０から読み出したパッチファイルのバージョン情報と、ハードディスクドライブ３４に既に保持されているパッチファイルのバージョン情報とを比較する。このとき、ハードディスクドライブ３４にパッチファイルが保持されていなければ、比較部１４０は、ＲＯＭ媒体５０に記録されているパッチファイルがハードディスクドライブ３４に保持されていないことを判定し、読出制御部１４２に通知する。比較部１４０は、バージョン情報が「２」と「３」であるパッチファイルがハードディスクドライブ３４に保持されていないことを伝えてもよく、またハードディスクドライブ３４にパッチファイルが存在していないことを伝えてもよい。読出制御部１４２は、比較部１４０による比較結果を受けると、メディアドライブ３２を制御して、ハードディスクドライブ３４に保持されていないパッチファイルを、ＲＯＭ媒体５０からハードディスクドライブ３４に読み出させて、インストールする。なお複数のパッチファイルを読み出す場合、パッチファイルを特定するバージョン情報の古い方から順にハードディスクドライブ３４にインストールする。既述したように、本実施例においてパッチファイルは差分ファイルとして作成されており、古いバージョンのパッチファイルからインストールして、次のバージョンのパッチファイルを、古いバージョンのパッチファイルに追加する形式で、ゲームソフトウェアに対する差分ファイルを作成していく。これにより、ゲームソフトウェアに対する差分ファイルを適切にインストールすることができる。

ハードディスクドライブ３４にバージョン情報が「２」であるパッチファイルが既にインストールされている場合、比較部１４０は、バージョン情報が「３」であるパッチファイルがハードディスクドライブ３４に保持されていないことを判定し、読出制御部１４２に通知する。このとき、読出制御部１４２は、バージョン情報が「３」であるパッチファイルのみを、メディアドライブ３２によりハードディスクドライブ３４に読み出させ、インストールする。

このように読出制御部１４２は、比較部１４０による比較結果を受けて、既にハードディスクドライブ３４にインストールされているパッチファイルについては読み出しを行わず、インストールされていないパッチファイルのみを読み出すことで、インストール時間を短縮できる。ハードディスクドライブ３４にインストールされたパッチファイルのバージョン情報のうち、最新のものが、最新パッチバージョン情報１６２として管理される。最新パッチバージョン情報１６２は、更新処理部１２０により管理され、最新のパッチファイル１６０がインストールされるたびに、最新パッチバージョン情報１６２は更新される。この例では、最新パッチバージョン情報１６２が「３」に設定されている。

読出制御部１４２によるパッチファイルのインストール処理が完了すると、ＯＳ実行部１１２は、ゲームの起動ファイルを実行する。このとき、パッチファイル１６０がハードディスクドライブ３４にインストールされていれば、ＯＳ実行部１１２は、パッチファイルに含まれる起動ファイルを実行する。なおパッチファイル１６０がハードディスクドライブ３４にインストールされていなければ、ＯＳ実行部１１２は、ＲＯＭ媒体５０に含まれる起動ファイルを実行する。起動ファイルが実行されると、アプリケーション実行部１１４は、ＲＯＭ媒体５０に記録されているメインプログラムと、インストールされたパッチファイルとをメインメモリ１０２にロードして、ゲームソフトウェアを起動する。

ＲＯＭ媒体５０に記録されたゲームソフトウェアのバージョン情報が「１」であり、タイトルＩＤが「ＡＢＣＤ」であるとする。アプリケーション実行部１１４は、ハードディスクドライブ３４にパッチファイル１６０がインストールされているか探索する。パッチファイル１６０がインストールされている場合、アプリケーション実行部１１４は、パッチファイル１６０を適用して、ゲームソフトウェアを起動する。なお、ゲームアプリケーションの起動に利用した起動ファイルがハードディスクドライブ３４から読み出されている場合に、アプリケーション実行部１１４は、探索処理を行わずに、パッチファイル１６０が存在していることを判定してもよい。この例では、バージョン２，３のパッチファイルがインストールされており、したがってアプリケーション実行部１１４は、パッチを当てて、ゲームアプリケーションを実行する。

パッチファイルを適用してゲームソフトウェアが起動されると、バージョンファイル取得部１３２が、予め定められたアドレス生成手法により、ゲームソフトウェアのバージョンファイルを取得するためのアドレスを生成する。タイトルＩＤを「ＡＢＣＤ」とするゲームソフトウェアのアドレスは、アドレス生成手法により以下のように設定される。
ｈｔｔｐ：／／ｗｗｗ．＊＊＊．ｃｏｍ／ＡＢＣＤ／ＡＢＣＤ．ＸＹＺ
「ｗｗｗ．＊＊＊．ｃｏｍ」は管理サーバ１２を特定し、「ＡＢＣＤ／ＡＢＣＤ．ＸＹＺ」は、管理サーバ１２のディレクトリ（ＡＢＣＤ）に含まれるファイル名（ＡＢＣＤ．ＸＹＺ）を特定する。すなわち、このアドレス生成手法では、ゲームソフトウェアのタイトルＩＤを、ディレクトリ名およびファイル名に利用する。したがって管理サーバ１２の管理者が、ゲームソフトウェアごとに、タイトルＩＤをディレクトリとし、タイトルＩＤをファイル名としてバージョンファイルを格納することで、ゲーム装置１０が、起動するゲームソフトウェアのバージョンファイルを取得できるようになる。

バージョンファイル取得部１３２は、生成したアドレスをもとにネットワーク１８を介して管理サーバ１２にアクセスし、ゲームソフトウェアのバージョンファイルをダウンロードして取得する。

図５は、バージョンファイルの一例を示す。図５は、バージョンファイルに含まれる情報を簡略的に示しているが、バージョンファイルはＸＭＬの形式で記述されてもよい。バージョンファイルのファイル名は、「ＡＢＣＤ．ＸＹＺ」である。バージョンファイルは、タイトル情報１７６およびパッチ情報１８０ａ、１８０ｂ、１８０ｃを含む。

タイトル情報１７６は、タイトルＩＤを特定する情報であり、この例ではタイトルＩＤが「ＡＢＣＤ」である。パッチ情報１８０は、ゲームソフトウェアのパッチファイルのバージョン情報と、パッチファイルを格納する位置を示すアドレス情報とを対応づけた情報である。図５において、パッチファイルのバージョン情報は「パッチバージョン」として、アドレス情報は「パッチ取得ＵＲＬ」として、それぞれ示されている。ゲーム装置１０は、パッチ取得ＵＲＬに接続することで、パッチファイルを取得できる。

パッチ情報１８０ａ、１８０ｂ、１８０ｃは、それぞれ個々のパッチファイルに関する情報であり、この例ではタイトルＩＤをＡＢＣＤとするゲームソフトウェアに対して、３つのパッチファイルが存在することが示されている。パッチ情報１８０ａ、１８０ｂ、１８０ｃは、生成日が古いものから順に上から記述されている。パッチ情報１８０ａは、バージョン情報が「２」であるパッチファイルのアドレス情報を示す。パッチ情報１８０ｂは、バージョン情報が「３」であるパッチファイルのアドレス情報を示す。パッチ情報１８０ｃは、バージョン情報が「４」であるパッチファイルのアドレス情報を示す。

バージョンファイル取得部１３２が、ゲームソフトウェアのバージョンファイルを取得すると、比較部１４０は、ゲームソフトウェアに適用しているパッチファイルのバージョン情報と、バージョンファイルに含まれるバージョン情報とを比較する。アプリケーション実行部１１４は、バージョン２，３のパッチファイルを利用して、ゲームソフトウェアにパッチを当てている。比較部１４０は、最新パッチバージョン情報１６２に含まれるバージョン情報と、バージョンファイルに含まれるバージョン情報とを比較してよい。比較部１４０は、実行中のゲームソフトウェアに適用しているパッチファイル１６０の最新バージョン情報「３」と、バージョンファイルに含まれるバージョン情報「２」、「３」、「４」を比較し、バージョンファイルに含まれるバージョン情報「４」が、実行中のゲームソフトウェアに適用しているパッチファイルのバージョン情報よりも新しいことを判定する。この比較結果は、パッチファイル取得部１３６に供給される。

パッチファイル取得部１３６は、比較結果を受けると、ファイル提供サーバ１６にアクセスして、バージョン情報「４」で特定されるパッチファイルを取得する。バージョン４のパッチファイルの取得アドレスは、パッチ情報１８０ｃにおいて「パッチ取得ＵＲＬ」として記述されており、パッチファイル取得部１３６は、このアドレスにアクセスして、バージョン４のパッチファイルを取得し、ハードディスクドライブ３４にインストールする。パッチファイル取得部１３６は、ハードディスクドライブ３４にインストールされているパッチファイル１６０に、取得したバージョン４のパッチファイルを追加し、パッチファイル１６０を更新する。新たなパッチファイルが取得されると、実行処理部１１０は、ゲームソフトウェアを再起動し、更新されたパッチファイル１６０を適用して、ゲームソフトウェアを実行する。

本実施例のパッチファイルの取得処理を、従来型のリマスタリングしたＲＯＭ媒体を用いてファイル提供サーバ１６からパッチファイルを取得する処理と対比して説明する。従来型のリマスタリングしたＲＯＭ媒体には、既にパッチが当てられたゲームソフトウェアが記録されている。バージョン２，３のパッチが当てられたゲームソフトウェアのバージョンを「３」として、まず、従来型のパッチファイルの取得処理を説明する。

図６（ａ）は、従来型のリマスタリングしたＲＯＭ媒体５２を用いて、パッチファイルを取得したときのインストール状況を示す。バージョン３のゲームソフトウェアは、バージョン１のゲームソフトウェアに、バージョン２，３のパッチファイルが適用されたものである。アプリケーション実行部１１４がゲームソフトウェアを起動した後、バージョンファイル取得部１３２が、ゲームソフトウェアのバージョンファイルを取得する。比較部１４０は、ゲームソフトウェアのバージョン情報と、バージョンファイル（図５参照）に含まれるバージョン情報とを比較する。パッチファイル取得部１３６は、比較結果を受けると、ファイル提供サーバ１６にアクセスして、バージョン情報「４」で特定されるパッチファイル１６０ｄを取得する。

図６（ｂ）は、本実施例のＲＯＭ媒体５０を用いて、パッチファイルを取得したときのインストール状況を示す。ＲＯＭ媒体５０からバージョン２のパッチファイル１６０ａとバージョン３のパッチファイル１６０ｂがハードディスクドライブ３４にインストールされ、パッチファイル１６０ａと１６０ｂとが融合したパッチファイルが作成される。アプリケーション実行部１１４が、パッチを当ててゲームソフトウェア１５０を起動する。その後、バージョンファイル取得部１３２が、ゲームソフトウェア１５０のバージョンファイルを取得すると、比較部１４０が、ゲームソフトウェア１５０に適用しているパッチファイルのバージョン情報と、バージョンファイルに含まれるバージョン情報とを比較する。パッチファイル取得部１３６は、比較結果を受けると、ファイル提供サーバ１６にアクセスして、バージョン情報「４」で特定されるパッチファイル１６０ｃを取得する。パッチファイル取得部１３６は、ハードディスクドライブ３４にインストールされたパッチファイルと、取得したパッチファイル１６０ｃとを融合したパッチファイル１６０を作成する。

図６（ａ）に示すハードディスクドライブ３４においては、バージョン４のパッチファイル１６０ｄのみがインストールされており、バージョン２，３のパッチファイル１６０ａ、１６０ｂはインストールされていない。そのため、ＲＯＭ媒体５２を利用する限りにおいては適切にゲームアプリケーションは実行されるが、リマスタリングしていないＲＯＭ媒体を利用すると、バージョン２，３のパッチを当てることができないため、ゲームアプリケーションを適切に実行できなくなる。なお、リマスタリングしていないＲＯＭ媒体とは、バージョン１のゲームソフトウェア１５０を記録し、パッチファイルを記録していないＲＯＭ媒体である。

一方で、図６（ｂ）に示すハードディスクドライブ３４においては、最も古いバージョン２のパッチファイル１６０ａから最も新しいバージョンのパッチファイル１６０ｃまでのすべてを組み込んだパッチファイル１６０がインストールされている。そのため、リマスタリングしていないＲＯＭ媒体を利用しても、全てのパッチを当てることができ、ゲームアプリケーションを適切に実行できるという利点がある。

なお、図６（ａ）に示すパッチファイル１６０ｄは、パス情報などの違いから、図６（ｂ）に示すパッチファイル１６０ｃとは異なって作成されている。リマスタリングしたＲＯＭ媒体と、リマスタリングしていない初期のＲＯＭ媒体とで、パッチファイル１６０を共通に利用できるようにするためにも、図６（ｂ）に示すように、ゲームソフトウェアと、パッチファイルとを、別個にＲＯＭ媒体５０に記録して、記録媒体をリマスタすることには、ゲームソフトウェア提供者のパッチファイル作成負荷を低減する利点もある。

図７は、ゲーム装置１０におけるパッチファイル取得処理のフローチャートを示す。ＲＯＭ媒体５０がメディアドライブ３２に装着されなければ（Ｓ１０のＮ）、パッチファイルの取得処理およびゲームソフトウェアの起動処理は実行されない。ＲＯＭ媒体５０がメディアドライブ３２に装着されると（Ｓ１０のＹ）、ＲＯＭ媒体５０の認証処理が実行される。ＲＯＭ媒体５０が真正な媒体であることが判定されると、図４に示すメニュー画面が表示機器６０に表示される。ユーザが入力装置４０を操作して、ゲーム実行要求を入力しなければ（Ｓ１２のＮ）、ゲームソフトウェアは起動されず、ゲーム実行要求を入力すると（Ｓ１２のＹ）、読出制御部１４２が、メディアドライブ３２を制御して、ＲＯＭ媒体５０にパッチファイルが記録されているか調査する（Ｓ１４）。パッチファイルが記録されていなければ（Ｓ１４のＮ）、ＯＳ実行部１１２は、起動ファイルをＲＯＭ媒体５０からメインメモリ１０２に読み出して実行し、アプリケーション実行部１１４が、メインプログラムを実行して、ゲームソフトウェアを起動する（Ｓ２２）。なお、このときハードディスクドライブ３４にパッチファイル１６０がインストールされていれば、ＯＳ実行部１１２は、起動ファイルをハードディスクドライブ３４からメインメモリ１０２に読み出して実行し、アプリケーション実行部１１４が、パッチファイル１６０を適用して、ゲームソフトウェアを起動する。

一方、ＲＯＭ媒体５０にパッチファイルが記録されていれば（Ｓ１４のＹ）、比較部１４０は、メディアドライブ３２から読み出されたパッチファイルのバージョン情報を取得する。比較部１４０は、バージョン情報を用いて、ＲＯＭ媒体５０に記録されているパッチファイルと同じバージョンのパッチファイルが既にハードディスクドライブ３４にインストールされているか判定する（Ｓ１６）。既にインストールされている場合（Ｓ１６のＹ）、読出制御部１４２は、メディアドライブ３２による同じバージョンのパッチファイルの読出を禁止する。ＯＳ実行部１１２は、起動ファイルをハードディスクドライブ３４からメインメモリ１０２に読み出して実行し、アプリケーション実行部１１４が、既にインストールされているパッチファイル１６０を適用して、ゲームソフトウェアを起動する（Ｓ２２）。

一方、ＲＯＭ媒体５０に記録されているパッチファイルと同じバージョンのパッチファイルがハードディスクドライブ３４にインストールされていなければ（Ｓ１６のＮ）、ＯＳ実行部１１２は、表示機器６０に、パッチファイルをインストールするかユーザに確認するための確認画面を表示する。

図８は、ＲＯＭ媒体５０に記録されたパッチファイルのインストール確認画面を示す。この確認画面では、ＲＯＭ媒体５０にパッチファイルが記録されており、パッチファイルをインストールしなければ、ゲームを実行できないことが通知される。ユーザが「はい」を選択すると、入力受付部１０４が、その選択操作をインストール要求として受け付け（Ｓ１８のＹ）、読出制御部１４２は、メディアドライブ３２を制御して、メディアドライブ３２にＲＯＭ媒体５０からパッチファイルを読み出させて、ハードディスクドライブ３４にインストールする（Ｓ２０）。一方、この確認画面で、ユーザが「いいえ」を選択すると、入力受付部１０４が、その選択操作を受け付け（Ｓ１８のＮ）、本フローは終了する。このように、本実施例のゲーム装置１０においては、ＲＯＭ媒体５０に記録されたパッチファイルをインストールしなければ、ゲームアプリケーションの実行が禁止される。逆に言えば、リマスタリングしたＲＯＭ媒体５０を用いると、パッチを当てなければゲームソフトウェアが起動されないため、ユーザに、パッチファイルをインストールさせるインセンティブを与えることができる。

パッチファイルのインストール後、ＯＳ実行部１１２は、起動ファイルをハードディスクドライブ３４からメインメモリ１０２に読み出して実行し、アプリケーション実行部１１４が、インストールされているパッチファイル１６０を適用して、ゲームソフトウェアを起動する（Ｓ２２）。

ゲームソフトウェアの起動後、バージョンファイル取得部１３２は、ネットワーク１８を介して、起動したゲームソフトウェアの識別情報を用いて、バージョンファイルを取得する（Ｓ２４）。比較部１４０は、起動したゲームソフトウェアに適用しているパッチファイルのバージョン情報と、バージョンファイルに含まれるバージョン情報とを比較し、未取得のパッチファイルが存在するか判定する（Ｓ２６）。ゲームソフトウェアに適用しているパッチファイルのバージョン情報よりも新しいバージョン情報がバージョンファイルに含まれる場合（Ｓ２６のＹ）、アプリケーション実行部１１４は、表示機器６０に、パッチファイルをインストールするかユーザに確認するための確認画面を表示する。

図９は、ファイル提供サーバ１６に保持されたパッチファイルのインストール確認画面を示す。この確認画面では、ファイル提供サーバ１６に未取得のパッチファイルが存在しており、パッチファイルをインストールすることで、最新の状態でゲームを実行できることが通知される。ユーザが「はい」を選択すると、入力受付部１０４が、その選択操作をインストール要求として受け付け（Ｓ２８のＹ）、パッチファイル取得部１３６は、ネットワーク１８を介して、バージョンファイルにおいて新しいバージョン情報に対応づけられたアドレス情報を利用して、パッチファイルを取得し（Ｓ３０）、ハードディスクドライブ３４にインストールする（Ｓ２０）。一方、この確認画面で、ユーザが「いいえ」を選択すると、入力受付部１０４が、その選択操作を受け付け（Ｓ２８のＮ）、ゲームの起動状態を維持して、本フローによるパッチファイルの取得処理は終了する。このように、本実施例のゲーム装置１０においては、ネットワーク１８経由でパッチファイルをインストールしなくても、ゲームアプリケーションの実行は維持されることとし、ネットワーク１８に接続しないゲーム装置１０との公平性を担保している。

パッチファイルがネットワーク１８経由でインストールされると、アプリケーション実行部１１４は、起動したゲームソフトウェアを終了し、新たなパッチファイル１６０を適用して、ゲームソフトウェアを再起動する（Ｓ２２）。ゲームソフトウェアの再起動後、バージョンファイル取得部１３２は、バージョンファイルを取得し（Ｓ２４）、比較部１４０は、未取得のパッチファイルが存在するか判定する（Ｓ２６）。このとき、未取得のパッチファイルは存在しないため（Ｓ２６のＮ）、パッチファイルの取得処理は終了し、アプリケーション実行部１１４は、引き続き、ゲームソフトウェアを実行する。

以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。実施例では、ゲームソフトウェアが記録された記録媒体の例としてＲＯＭ媒体を示したが、記録媒体は、たとえば情報の書換可能な媒体であっても構わない。

１・・・ファイル配信システム、１０・・・ゲーム装置、１２・・・管理サーバ、１６・・・ファイル提供サーバ、１８・・・ネットワーク、３２・・・メディアドライブ、３４・・・ハードディスクドライブ、５０・・・ＲＯＭ媒体、１００・・・メインコントローラ、１１０・・・実行処理部、１１２・・・ＯＳ実行部、１１４・・・アプリケーション実行部、１２０・・・更新処理部、１３０・・・取得部、１３２・・・バージョンファイル取得部、１３６・・・パッチファイル取得部、１４０・・・比較部、１４２・・・読出制御部、１５０・・・ゲームソフトウェア、１６０・・・パッチファイル、１７０・・・ＯＳ、１７６・・・タイトル情報、１８０・・・パッチ情報。

Claims (7)

1. アプリケーションソフトウェアおよびパッチファイルを記録した記録媒体からデータを読み出すドライブ装置と、
   記憶装置と、
   アプリケーションソフトウェアの実行要求を受けると、前記ドライブ装置に記録媒体からパッチファイルを読み出させて、前記記憶装置にインストールする読出制御部と、
   パッチファイルのインストール後、インストールされたパッチファイルを適用して、記録媒体に記録されているアプリケーションソフトウェアを起動する実行処理部と、
   アプリケーションソフトウェアの起動後、ネットワークを介して、起動したアプリケーションソフトウェアの識別情報を用いて、アプリケーションソフトウェアのパッチファイルのバージョン情報と、パッチファイルを格納する位置を示すアドレス情報とを対応づけたバージョンファイルを取得するバージョンファイル取得部と、
   起動したアプリケーションソフトウェアに適用しているパッチファイルのバージョン情報と、バージョンファイルに含まれるバージョン情報とを比較する比較部と、
   アプリケーションソフトウェアに適用しているパッチファイルのバージョン情報よりも新しいバージョン情報がバージョンファイルに含まれる場合に、ネットワークを介して、より新しいバージョン情報に対応づけられたアドレス情報を利用して、パッチファイルを取得して、前記記憶装置にインストールするパッチファイル取得部と、
   を備えることを特徴とする情報処理装置。
2. 前記パッチファイル取得部によりパッチファイルが取得されると、前記実行処理部は、アプリケーションソフトウェアを再起動することを特徴とする請求項１に記載の情報処理装置。
3. 前記実行処理部は、記録媒体に記録されているパッチファイルが前記記憶装置にインストールされなければ、アプリケーションソフトウェアを起動しないことを特徴とする請求項１または２に記載の情報処理装置。
4. 前記読出制御部は、前記記憶装置に、記録媒体に記録されているパッチファイルと同じバージョンのパッチファイルが既にインストールされている場合には、前記ドライブ装置による同じバージョンのパッチファイルの読出を禁止することを特徴とする請求項１から３のいずれかに記載の情報処理装置。
5. 前記実行処理部は、前記パッチファイル取得部により前記記憶装置にパッチファイルがインストールされなくても、アプリケーションソフトウェアの実行を維持することを特徴とする請求項１から４のいずれかに記載の情報処理装置。
6. コンピュータに、
   アプリケーションソフトウェアおよびパッチファイルを記録した記録媒体がドライブ装置に装着され、アプリケーションソフトウェアの実行要求を受けると、ドライブ装置により記録媒体からパッチファイルを読み出して、記憶装置にインストールする機能と、
   パッチファイルのインストール後、記憶装置にインストールされたパッチファイルを適用して、記録媒体に記録されているアプリケーションソフトウェアを起動する機能と、
   アプリケーションソフトウェアの起動後、ネットワークを介して、起動したアプリケーションソフトウェアの識別情報を用いて、アプリケーションソフトウェアのパッチファイルのバージョン情報と、パッチファイルを格納する位置を示すアドレス情報とを対応づけたバージョンファイルを取得する機能と、
   起動したアプリケーションソフトウェアに適用しているパッチファイルのバージョン情報と、バージョンファイルに含まれるバージョン情報とを比較する機能と、
   アプリケーションソフトウェアに適用しているパッチファイルのバージョン情報よりも新しいバージョン情報がバージョンファイルに含まれる場合に、ネットワークを介して、より新しいバージョン情報に対応づけられたアドレス情報を利用して、パッチファイルを取得して、前記記憶装置にインストールする機能と、
   を実現させるためのプログラム。
7. 請求項６に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images