JP2013208365A - サーバシステム、プログラム及び情報記憶媒体 - Google Patents

Abstract

【課題】第１のゲーム処理と第２のゲーム処理が競合することによる不具合の発生等を抑制できるサーバシステム、プログラム、情報記憶媒体等の提供。
【解決手段】サーバシステムは、ネットワークを介して情報を受信する処理を行う受信処理部と、ネットワークを介して情報を送信する処理を行う送信処理部と、ゲーム処理の制御処理を行う制御処理部と、ゲーム処理の更新対象となる情報を、サーバ管理情報として記憶する記憶部を含む。制御処理部は、第１のゲーム処理の実行中に、第１のゲーム処理と同じサーバ管理情報を更新対象とする第２のゲーム処理の実行要求が検出された場合に、ゲーム処理の競合時用処理を行う。
【選択図】図６

Description

本発明は、サーバシステム、プログラム及び情報記憶媒体等に関する。

近年、ネットワークを介してサーバシステムと端末装置とを通信接続して、ネットワークを利用したゲーム（以下、適宜、ネットワークゲームと呼ぶ）を楽しむことができるゲームシステムが脚光を浴びている。このようなネットワークゲームの従来技術としては例えば特許文献１、２に開示される技術がある。

そして、このようなネットワークゲームの普及に伴い、業務用ゲーム装置や家庭用ゲーム装置等のゲーム装置でプレイできるゲームを、スマートフォン等の携帯端末を用いたソーシャルゲーム等のアプリとしてもプレイ可能にするような連携システムも、提案されつつある。

この場合、ゲーム装置のハードウェア・ソフトウェア環境と携帯端末のハードウェア・ソフトウェア環境は異なるため、同じゲームタイトルのゲームであっても、実行されるゲーム処理は異なったものとなる。例えばゲーム装置用には、当該ゲーム装置用に開発された第１のゲーム処理のプログラムが実行され、携帯端末用には、当該携帯端末用に開発された第２のゲーム処理のプログラムが実行される。

そして、ゲーム装置でユーザがプレイする第１のゲームと、携帯端末でユーザがプレイする第２のゲームとで、共通のキャラクタ等をユーザが使用できるようにするためには、ゲーム処理自体は異なっていても、キャラクタのゲームパラメータや装備アイテムについては、共通のゲームパラメータや装備アイテムを使用できるようにすることが望ましい。

しかしながら、このようにゲームパラメータや装備アイテムを連携させた場合に、第１のゲーム処理と第２のゲーム処理とが競合してしまい、予期せぬ不具合が発生するおそれがあることが判明した。

特開２００４−２３０１９１号公報 特開２００９−１１９１４６号公報

本発明の幾つかの態様によれば、第１のゲーム処理と第２のゲーム処理が競合することによる不具合の発生等を抑制できるサーバシステム、プログラム及び情報記憶媒体等を提供できる。

本発明の一態様は、ネットワークを介して情報を受信する処理を行う受信処理部と、前記ネットワークを介して情報を送信する処理を行う送信処理部と、ゲーム処理の制御処理を行う制御処理部と、前記ゲーム処理の更新対象となる情報を、サーバ管理情報として記憶する記憶部とを含み、前記制御処理部は、第１のゲーム処理の実行中に、前記第１のゲーム処理と同じ前記サーバ管理情報を更新対象とする第２のゲーム処理の実行要求が検出された場合に、ゲーム処理の競合時用処理を行うサーバシステムに関係する。また本発明は、上記各部としてコンピュータを機能させるプログラム、又は該プログラムを記憶したコンピュータ読み取り可能な情報記憶媒体に関係する。

本発明の一態様では、ゲーム処理の更新対象となるサーバ管理情報が記憶部に記憶される。そして、このサーバ管理情報を更新対象とする第１のゲーム処理の実行中に、同じサーバ管理情報を更新対象とする第２のゲーム処理の実行要求が検出されると、ゲーム処理の競合時用の処理が実行されるようになる。このようにすれば、第１のゲーム処理と第２のゲーム処理が競合してしまうような状況が発生した場合にも、この競合時用の処理が実行されることで、第１、第２のゲーム処理が競合することによる不具合の発生等を、効果的に抑制できるようになる。

また本発明の一態様では、前記制御処理部は、前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第２のゲーム処理の実行を禁止する処理を、前記競合時用処理として行ってもよい。

このようにすれば、第１のゲーム処理の実行中に第２のゲーム処理の実行要求が検出されると、第１のゲーム処理の実行が禁止されるため、第１、第２のゲーム処理の競合による不具合の発生等を効果的に防止できる。

また本発明の一態様では、前記制御処理部は、前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第２のゲーム処理が行われる端末装置に対して、前記第２のゲーム処理の実行が禁止であることを通知する処理を、前記競合時用処理として行ってもよい。

このようにすれば、第１、第２のゲーム処理の競合が要因となって第２のゲーム処理の実行が禁止されたことを、ユーザに通知することができ、ユーザの利便性等を向上できる。

また本発明の一態様では、前記制御処理部は、前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第１のゲーム処理及び前記第２のゲーム処理の一方のゲーム処理を中止又は中断する処理を、前記競合時用処理として行ってもよい。

このようにすれば、第１のゲーム処理の実行中に第２のゲーム処理の実行要求が検出されると、第１、第２のゲーム処理の一方のゲーム処理が中止又は中断されるため、第１、第２のゲーム処理の競合による不具合の発生等を効果的に防止できる。

また本発明の一態様では、前記制御処理部は、前記第１のゲーム処理及び前記第２のゲーム処理のいずれのゲーム処理を中止又は中断するかを、ゲーム処理の優先度情報に基づいて判断してもよい。

このようにすれば、第１、第２のゲーム処理のいずれのゲーム処理を中止又は中断するかを、優先度情報を利用して簡素に判断できるようになる。

また本発明の一態様では、前記制御処理部は、前記第１のゲーム処理及び前記第２のゲーム処理のいずれのゲーム処理を中止又は中断するかを、ゲーム進行状況情報及び課金状態情報の少なくとも一方により設定された前記優先度情報に基づいて判断してもよい。

このようにすれば、第１、第２のゲーム処理のいずれを優先するかを、ゲーム進行状況情報や課金状態情報に応じて、適切に判断することが可能になる。

また本発明の一態様では、前記制御処理部は、前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第１のゲーム処理の再開に必要なセーブ情報のセーブ処理を行ってもよい。

このようにすれば、第１、第２のゲーム処理が競合した場合にも、セーブ情報を用いて、第１のゲーム処理を適切に再開することが可能になる。

また本発明の一態様では、前記制御処理部は、前記セーブ処理の後に、前記第１のゲーム処理を中断して、前記第２のゲーム処理を実行した場合には、前記第２のゲーム処理の終了後に、前記セーブ情報に基づいて、前記第１のゲーム処理を再開してもよい。

このようにすれば、第１、第２のゲーム処理の競合により、第１のゲーム処理が中断されて、第２のゲーム処理が実行された場合にも、その第２のゲーム処理の終了後に、セーブ情報に基づいて第１のゲーム処理を適切に再開することが可能になる。

また本発明の一態様では、前記制御処理部は、前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第１のゲーム処理の終了後に、前記第２のゲーム処理による前記サーバ管理情報の更新処理を許可してもよい。

このようにすれば、第２のゲーム処理によるサーバ管理情報の更新処理が原因で、サーバ管理情報にデータの不整合等が生じて、不具合が発生してしまう事態を効果的に防止できる。

また本発明の一態様では、前記制御処理部は、前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第１のゲーム処理を中断して、前記第２のゲーム処理を実行し、前記第１のゲーム処理の終了後に、前記第２のゲーム処理による前記サーバ管理情報の更新処理を許可してもよい。

このようにすれば、第１のゲーム処理によるサーバ管理情報の更新処理と、第２のゲーム処理によるサーバ管理情報の更新処理とを、適切に調整することが可能になる。

また本発明の一態様では、前記制御処理部は、前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第１のゲーム処理のポーズ処理又はスローモーション処理を行ってもよい。

このようにすれば、第１、第２のゲーム処理の競合時に、第１のゲーム処理のポーズ処理又はスローモーション処理を行うことで、第２のゲーム処理を実行させることなどが可能になる。

また本発明の一態様では、前記制御処理部は、前記ポーズ処理の期間又は前記スローモーション処理の期間において、前記第２のゲーム処理による前記サーバ管理情報の更新処理を許可してもよい。

このようにすれば、第１のゲーム処理のポーズ処理又はスローモーション処理の期間を有効活用して、第２のゲーム処理によるサーバ管理情報の更新処理を実行できるようになる。

また本発明の一態様では、前記第１のゲーム処理のゲームは、複数のゲームステージ又は複数のゲームシーンにより構成され、前記制御処理部は、前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第２のゲーム処理による前記サーバ管理情報の更新処理を、前記複数のゲームステージの各ゲームステージの終了後又は前記複数のゲームシーンの各ゲームシーンの終了後に許可してもよい。

このようにすれば、ゲームステージ間の期間やゲームシーン間の期間を有効活用して、第２のゲーム処理によるサーバ管理情報の更新処理を実行できるようになる。

また本発明の一態様では、前記制御処理部は、前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第１のゲーム処理及び前記第２のゲーム処理の少なくとも一方のゲーム処理での画像表示又は音出力を変更する処理を、前記競合時処理として行ってもよい。

このように第１、第２のゲーム処理の競合時に、第１、第２のゲーム処理での画像表示又は音出力を変更する制御を行うことで、ユーザのスムーズなゲーム操作等を実現することができ、ユーザの利便性を向上できる。

また本発明の一態様では、前記制御処理部は、前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第１のゲーム処理における音出力のレベルを小さくする処理を行ってもよい。

このように第１、第２のゲーム処理の競合時に、第１のゲーム処理の音出力レベルを小さくすることで、ユーザのスムーズなゲーム操作等を実現することが可能になる。

また本発明の一態様では、前記制御処理部は、前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第１のゲーム処理のゲーム画面に、前記第２のゲーム処理のゲーム画面を表示するための処理を行ってもよい。

このようにすれば、第１、第２のゲーム処理の競合時に、ユーザは、第１のゲーム処理のゲーム画面により、第２のゲーム処理のゲーム画面も確認できるようになるため、ユーザの利便性を向上できる。

また本発明の一態様では、前記第１のゲーム処理と前記第２のゲーム処理は、同一ユーザがプレイするゲームのゲーム処理であってもよい。

このようにすれば、同じユーザがプレイする第１、第２のゲーム処理の競合により、そのユーザについてのサーバ管理情報にデータの不整合等が生じて、不具合が発生してしまう事態を効果的に防止できる。

また本発明の一態様では、前記制御処理部は、前記第１のゲーム処理と前記第２のゲーム処理とが、同一ユーザがプレイするゲームのゲーム処理であることを、ユーザがプレイする端末装置からのユーザ識別情報に基づいて判断してもよい。

このようにすれば、第１、第２のゲーム処理が同じユーザによるものか否かを、端末装置からのユーザ識別情報に基づいて簡素に判断できるようになる。

また本発明の一態様では、前記記憶部は、前記サーバ管理情報として、ゲームパラメータ情報、ゲームアイテム情報、及びゲーム成績情報の少なくとも１つの情報を記憶してもよい。

また本発明の一態様では、前記第１のゲーム処理は、ユーザの操作情報に基づいてゲーム処理が行われ、ゲームを構成する複数のゲームステージ又は複数のゲームシーンの各ゲームステージ毎又は各ゲームシーン毎に、前記サーバ管理情報の更新処理が行われるゲーム処理であり、前記第２のゲーム処理は、ユーザの操作情報の入力毎に、前記サーバ管理情報の更新処理が行われるゲーム処理であってもよい。

本実施形態の処理システムの構成例。 本実施形態の処理システムの構成例。 本実施形態のサーバシステムの構成例。 本実施形態の端末装置の構成例。 図５（Ａ）、図５（Ｂ）はサーバ管理情報の更新処理についての説明図。 図６（Ａ）、図６（Ｂ）は本実施形態の手法の説明図。 図７（Ａ）、図７（Ｂ）は第１のゲーム処理による第１のゲームの例。 図８（Ａ）、図８（Ｂ）は第２のゲーム処理による第２のゲームの例。 図９（Ａ）、図９（Ｂ）も第２のゲーム処理による第２のゲームの例。 第１、第２のゲーム処理の競合時に第２のゲーム処理の実行を禁止する手法の説明図。 図１１（Ａ）、図１１（Ｂ）は第１、第２のゲーム処理の競合時に第１、第２のゲーム処理のいずれかを中止又は中断する手法の説明図。 図１２（Ａ）、図１２（Ｂ）は第１、第２のゲーム処理の競合時に第１のゲーム処理のセーブ情報のセーブ処理を行う手法の説明図。 第１、第２のゲーム処理の競合時におけるサーバ管理情報の更新手法の説明図。 第１、第２のゲーム処理の競合時に第１のゲーム処理のポーズ処理又はスローモーション処理を行う手法の説明図。 第１のゲーム処理の各ゲームステージ毎又は各ゲームシーン毎に第２のゲーム処理によるサーバ管理情報の更新処理を行う手法の説明図。 第１、第２のゲーム処理の競合時に音出力レベルを制御する手法の説明図。 第１、第２のゲーム処理の競合時に第２のゲーム処理のゲーム画面を第１のゲーム処理のゲーム画面に表示する手法の説明図。 第１、第２のゲーム処理のゲームをプレイするユーザの同一性を判断する手法の説明図。 本実施形態の詳細な処理例のフローチャート。 本実施形態の詳細な処理例のフローチャート。 本実施形態の詳細な処理例のフローチャート。 本実施形態の詳細な処理例のフローチャート。

以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。

１．処理システム、サーバシステム、端末装置の構成
図１、図２に本実施形態の処理システムの構成例を示す。この処理システムは、サーバシステム５００と端末装置ＴＭ１、ＴＭ２を含む。

サーバシステム５００（情報処理システム）は、ネットワーク５１０を介して、端末装置ＴＭ１、ＴＭ２と通信接続される。例えばサーバシステム５００はホストであり、端末装置ＴＭ１、ＴＭ２はクライアントである。サーバシステム５００は例えば１又は複数のサーバ（管理サーバ、ゲームサーバ、サービス提供サーバ、コンテンツ配信サーバ、認証サーバ、データベースサーバ、通信サーバ又は課金サーバ等）により実現できる。ネットワーク５１０（配信網、通信回線）は、例えばインターネットや無線ＬＡＮ等を利用した通信路であり、直接接続のための専用線（専用ケーブル）やイーサネット（登録商標）等によるＬＡＮの他、電話通信網やケーブル網や無線ＬＡＮ等の通信網を含むことができる。また通信方法については有線／無線を問わない。

端末装置ＴＭ１、ＴＭ２は、例えばネット接続機能（インターネット接続機能）を有する端末である。そして端末装置ＴＭ１は、例えば、業務用ゲーム装置、携帯型ゲーム装置、或いは家庭用ゲーム装置などのゲーム装置である。端末装置ＴＭ２は、例えば、スマートフォン、フューチャーフォン、或いは携帯電話機などの携帯端末である。例えば、図１では端末装置ＴＭ１は業務用ゲーム装置となっており、図２では端末装置ＴＭ１は携帯型ゲーム装置となっている。但し、本実施形態はこれに限定されず、端末装置ＴＭ１が携帯端末であり、端末装置ＴＭ２がゲーム装置であってもよい。或いは、端末装置ＴＭ１、ＴＭ２の両方がゲーム装置（異なるタイプのゲーム装置）であってもよく、端末装置ＴＭ１、ＴＭ２の両方が携帯端末（異なるタイプの携帯端末）であってもよい。或いは、端末装置ＴＭ１、ＴＭ２の少なくとも一方が、例えばパーソナルコンピュータ（ＰＣ）などの情報処理装置であってもよい。

本実施形態では、端末装置ＴＭ１においては、第１のゲーム処理により、ユーザは第１のゲームをプレイできるようになっている。一方、端末装置ＴＭ２においては、第２のゲーム処理により、ユーザは第２のゲームをプレイできるようになっている。なお、第１、第２のゲーム処理は、それぞれ、端末装置ＴＭ１、ＴＭ２上で実行される第１、第２のゲームプログラムにより実現してもよいし、サーバシステム５００上で実行される第１、第２のゲームプログラムにより実現してもよい。或いは、第１、第２のゲーム処理を、端末装置ＴＭ１、ＴＭ２とサーバシステム５００の分散処理により実現してもよい。

図３に本実施形態のサーバシステム５００（ホスト装置、情報処理システム）の構成例を示す。なお、サーバシステム５００の構成は図３に限定されず、その構成要素（各部）の一部を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。

サーバシステム５００は、処理部６００、操作部６６０、記憶部６７０、通信部６９６を含む。

処理部６００は、通信部６９６を介して受信したデータや、記憶部６７０に記憶されるデータ、プログラム等に基づいて、サーバの各種サービス・管理に必要な種々の処理を行う。この処理部６００の機能は、各種プロセッサ（ＣＰＵ、ＧＰＵ等）、ＡＳＩＣ（ゲートアレイ等）などのハードウェアや、プログラムにより実現できる。

処理部６００は、受信処理部６０２、送信処理部６０４、制御処理部６０６、ゲーム処理部６０８、管理処理部６１０、画像情報生成部６２０、音情報生成部６３０を含む。

受信処理部６０２は、端末装置等からの情報の受信処理を行う。送信処理部６０４は、端末装置等への情報の送信処理を行う。ここで受信処理は、通信部６９６に情報の受信を指示したり、通信部６９６が受信した情報を取得して記憶部６７０に書き込む処理などである。送信処理は、通信部６９６に情報の送信を指示したり、送信する情報を通信部６９６に指示する処理などである。

制御処理部６０６は、各種の制御処理を行う。具体的には制御処理部６０６はゲーム処理の制御処理を行う。例えば制御処理部６０６は、図１、図２で説明した第１、第２のゲーム処理の実行や、実行の中断・中止・再開等を制御する。また、第１、第２のゲーム処理の処理モード（セーブ処理、ポーズ処理、スローモーション処理等）の制御処理なども行う。この制御処理部６０の詳細については後述する。

ゲーム処理部６０８は、各種のゲーム処理を行う。ここでゲーム処理としては、ゲーム開始条件が満たされた場合にゲームを開始する処理、ゲームを進行させる処理、ゲーム終了条件が満たされた場合にゲームを終了する処理、或いはゲーム結果を演算する処理などがある。具体的には、サーバ側がゲーム処理を行う場合には、サーバ側のゲーム処理部６０８が、端末装置に入力されたユーザの操作情報に基づいて、ゲームを開始したり、ゲームを進行させたり、ゲームを終了させたりするなどのゲーム処理を行う。また、ユーザの操作情報に基づいて、キャラクタ等のオブジェクトを移動させたり、動作させるゲーム処理を行う。また、例えば、第１のゲーム処理においては、ゲームステージ毎にゲーム結果（ゲーム成績）を演算する処理を行ったり、第２のゲーム処理においては、ユーザの操作毎にゲーム結果を演算する処理を行う。またゲーム処理部６０８は、ゲーム情報である画像情報や音情報を生成させるための処理を行う。具体的には、ゲーム画面等を端末装置に表示するためのゲーム処理や、ゲーム音を端末装置に出力させるためのゲーム処理を行う。

管理処理部６１０は、サーバの各種の管理処理を行う。例えば、サーバが提供する各種サービスの管理処理、サーバ管理情報などの各種情報の管理処理を行う。画像情報生成部６２０は、画像の生成のための情報である画像情報を生成する。音情報生成部６３０は、音（音声、ゲーム音、効果音）の生成のための情報である音情報を生成する。具体的には、画像情報は、本実施形態の手法により生成される画像を各端末装置ＴＭ１〜ＴＭｎにおいて生成・表示するための情報であり、画像データそのものであってもよいし、各端末装置が画像を生成・表示するために使用する各種データ（表示画面の設定データ、オブジェクトデータ等）であってもよい。音情報生成部６３０が生成する音情報についても同様である。

操作部６６０は、システムの管理者（運営者）が種々の情報を入力するためのものである。

記憶部６７０は、処理部６００や通信部６９６などのワーク領域となるものであり、その機能はＲＡＭ（ＤＲＡＭ、ＳＲＡＭ、ＶＲＡＭ）やＳＳＤ（Solid State Drive）やＨＤＤ（Hard Disk Drive）などにより実現できる。記憶部６７０は、サーバ管理情報記憶部６７２、優先度情報記憶部６７４を含む。これらの詳細については後述する。

情報記憶媒体６８０（コンピュータにより読み取り可能な媒体）は、プログラムやデータなどを格納するものであり、その機能は、光ディスク（ＣＤ、ＤＶＤ）、ＨＤＤ、或いはメモリ（ＲＯＭ等）などにより実現できる。この情報記憶媒体６８０には、サーバシステム５００（処理システム）の各部をコンピュータとして機能させるためのプログラムが記憶されている。

通信部６９６は、有線や無線のネットワーク５１０を介して端末装置ＴＭ１〜ＴＭｎや他の外部サーバとの通信を行うものであり、その機能は、通信用ＡＳＩＣ又は通信用プロセッサなどのハードウェアや、通信用ファームウェアにより実現できる。

図４に本実施形態の端末装置（クライアント装置）の構成例を示す。なお、端末装置の構成は図４に限定されず、その構成要素（各部）の一部を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。図４は、図１、図２の端末装置ＴＭ１、ＴＭ２の機能的な構成例を示す図である。即ち、ゲーム装置や携帯端末の構成例を示すものである。但し、実際には端末装置ＴＭ１とＴＭ２とでは、そのハードウェア構成が異なっている。

端末装置は、処理部２００、操作部２６０、撮像部２６４、記憶部２７０、表示部２９０、音出力部２９２、Ｉ／Ｆ部２９４、通信部２９６を含む。

処理部２００（プロセッサ）は、操作部２６０からの操作情報やプログラムなどに基づいて、各種サービス提供のための処理、ゲーム処理、画像表示処理、或いは音出力処理などを行う。処理部２００は、記憶部２７０をワーク領域として各種処理を行う。この処理部２００の機能は、各種プロセッサ（ＣＰＵ、ＧＰＵ等）、ＡＳＩＣ（ゲートアレイ等）などのハードウェアや、プログラムにより実現できる。

処理部２００は、入力受け付け部２０１、受信処理部２０２、送信処理部２０４、ゲーム処理部２０８、表示制御部１２０、音制御部１３０を含む。

入力受け付け部２０１は、ユーザ（プレーヤ）からの入力情報の受け付け処理を行う。例えば操作部２６０を介して入力された情報の受け付け処理を行う。受信処理部２０２は、サーバシステムや他の端末装置等の外部装置からの情報の受信処理を行う。送信処理部２０４は、サーバシステムや他の端末装置等の外部装置への情報の送信処理を行う。

ゲーム処理部２０８は、各種のゲーム処理を行う。ゲーム処理は、前述したように、ゲーム開始条件が満たされた場合にゲームを開始する処理、ゲームを進行させる処理、ゲーム終了条件が満たされた場合にゲームを終了する処理、或いはゲーム結果を演算する処理などである。例えば端末装置側がゲーム処理を行う場合には、端末装置側のゲーム処理部２０８が、操作部２６０により入力されたユーザの操作情報に基づいて、ゲームを開始したり、ゲームを進行させたり、ゲームを終了させたりするなどのゲーム処理を行う。また、ユーザの操作情報に基づいて、キャラクタ等のオブジェクトを移動させたり、動作させるなどのゲーム処理を行う。また、例えば、第１のゲーム処理においては、ゲームステージ毎にゲーム結果を演算する処理を行ったり、第２のゲーム処理においては、ユーザの操作毎にゲーム結果を演算する処理を行う。またゲーム処理部２０８は、ゲーム画像を生成したり、ゲームオンを生成するための処理を行う。

なお、第１、第２のゲーム処理等のゲーム処理は、図３に示すサーバ側のゲーム処理部６０８がサーバ上で実行してもよいし、図４に示す端末装置側のゲーム処理部２０８が端末装置上で実行してもよい。或いは、第１、第２のゲーム処理等のゲーム処理を、サーバ側のゲーム処理部６０８と端末装置側のゲーム処理部２０８の分散処理時により実行してもよい。例えばゲーム処理の一部を端末装置側が行い、ゲーム処理の他の部分をサーバ側が行うようにする。

表示制御部２２０は、表示部２９０に画像を表示するための制御を行う。例えば端末装置側で画像を生成する場合には、処理部２００で行われる種々の処理（アプリケーション処理、ゲーム処理）の結果に基づいて描画処理を行い、これにより画像を生成し、表示部２９０に出力する。サーバ側で画像を生成する場合には、サーバシステムからの画像情報（画像生成用データ）に基づく画像を表示部２９０に表示する制御を行う。音制御部２３０は、処理部２００で行われる種々の処理の結果に基づいて音制御を行う。これにより、ＢＧＭ、効果音、又は音声などが音出力部２９２から出力されるようになる。

操作部２６０は、ユーザ（プレーヤ）が、操作情報等の種々の情報を入力するためのものであり、その機能は、操作ボタン、方向指示キー、アナログスティック、レバー、各種センサ（角速度センサ、加速度センサ等）、マイク、或いはタッチパネル型ディスプレイなどにより実現できる。

撮像部２６４（カメラ）は、被写体の撮像を行うものであり、ＣＣＤやＣＭＯＳセンサなどの画像センサと、フォーカスレンズ等により構成される光学系などにより実現される。

記憶部２７０は、処理部２００や通信部２９６などのワーク領域となるもので、その機能はＲＡＭやＳＳＤやＨＤＤなどにより実現できる。

情報記憶媒体２８０（コンピュータにより読み取り可能な媒体）は、プログラムやデータなどを格納するものであり、その機能は、光ディスク、ＨＤＤ、或いはメモリなどにより実現できる。処理部２００は、情報記憶媒体２８０に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。即ち情報記憶媒体２８０には、本実施形態の各部としてコンピュータ（操作部、処理部、記憶部、出力部を備える装置）を機能させるためのプログラム（各部の処理をコンピュータに実行させるためのプログラム）が記憶される。

表示部２９０は、本実施形態により生成された画像を出力するものであり、その機能は、ＬＣＤ、有機ＥＬディスプレイ、ＣＲＴ、或いはＨＭＤなどにより実現できる。音出力部２９２は、本実施形態により生成された音を出力するものであり、その機能は、スピーカ、或いはヘッドフォンなどにより実現できる。

Ｉ／Ｆ（インターフェース）部２９４は、不揮発性記憶装置２９５（携帯型情報記憶媒体）とのインターフェース処理を行うものであり、その機能はＩ／Ｆ処理用のＡＳＩＣなどにより実現できる。不揮発性記憶装置２９５は、ユーザが各種の情報を保存するためのものであり、電源が非供給になった場合にもこれらの情報の記憶を保持する記憶装置である。不揮発性記憶装置２９５は、ＩＣカード（メモリーカード）、ＵＳＢメモリー、或いは磁気カードなどにより実現できる。

通信部２９６は、ネットワーク５１０を介して外部装置（サーバシステム、他の端末装置等）との間で通信を行うものであり、その機能は、通信用ＡＳＩＣ又は通信用プロセッサなどのハードウェアや、通信用ファームウェアにより実現できる。

そして本実施形態では図３に示すように、サーバシステム５００が、受信処理部６０２と送信処理部６０４と制御処理部６０６を含む。またサーバ管理情報を記憶する記憶部６７０（データベース）を含む。

ここで、サーバシステム５００の受信処理部６０２は、ネットワーク５１０を介して情報を受信する処理を行う。送信処理部６０４は、ネットワーク５１０を介して情報を送信する処理を行う。例えば受信処理部６０２、送信処理部６０４は、第１、第２のゲーム処理等のゲーム処理を制御するための情報の受信・送信処理を行う。例えば、ゲーム処理の制御指示情報の受信・送信処理や、制御指示情報に対する応答情報の受信・送信処理を行う。また、受信処理部６０２、送信処理部６０４は、サーバ管理情報記憶部６７２に記憶されるサーバ管理情報の更新処理のための情報の受信・送信処理を行う。例えば更新指示情報の受信・送信処理や、更新指示情報の応答情報の受信・送信処理を行う。

またサーバシステム５００の記憶部６７０は、ゲーム処理の更新対象となる情報を、サーバ管理情報として記憶する。具体的には、記憶部６７０に設けられたサーバ管理情報記憶部６７２が、このサーバ管理情報を記憶する。

そして本実施形態では、サーバシステム５００の制御処理部６０６は、第１のゲーム処理の実行中に、第２のゲーム処理の実行要求（実行）が検出された場合に、ゲーム処理の競合時用の処理を行う。例えば、競合時用に予め用意された処理を行う。

例えばサーバシステム５００の制御処理部６０６は、第１のゲーム処理の実行中に第２のゲーム処理の実行要求が検出された場合に、第２のゲーム処理の実行を禁止する処理を、競合時用処理として行う。例えば第２のゲーム処理の実行要求が来た場合にも、その実行要求を受け付けず、第２のゲーム処理が実行されないように禁止する。

そして制御処理部６０６は、１のゲーム処理の実行中に第２のゲーム処理の実行要求が検出された場合に、第２のゲーム処理が行われる端末装置に対して、第２のゲーム処理の実行が禁止であることを通知する処理を、競合時用処理として行う。例えば図１、図２において、端末装置ＴＭ１の第１のゲーム処理の実行中に、端末装置ＴＭ２の第２のゲーム処理の実行要求が来た場合には、端末装置ＴＭ２の表示部に対して、第１のゲーム処理が実行中であるため、第２のゲーム処理の実行を禁止する旨の通知表示を行う。このようにすることで、ユーザは、第１のゲーム処理が実行中であるため第２のゲーム処理の第２のゲームをプレイできないことを、当該通知に容易に把握できるようになる。

また制御処理部６０６は、第１のゲーム処理の実行中に第２のゲーム処理の実行要求（実行）が検出された場合に、第１のゲーム処理及び前記第２のゲーム処理の一方のゲーム処理を中止又は中断する処理を、競合時用処理として行う。具体的には、第１のゲーム処理の実行を中止又は中断して、第２のゲーム処理が実行されるようにする。或いは、逆に、第２のゲーム処理の実行を中止又は中断（禁止）して、第１のゲーム処理が実行されるようにする。即ち、第１、第２のゲーム処理が排他的に実行されるように、一方のゲーム処理だけを実行させる。

この場合に制御処理部６０６は、第１のゲーム処理及び第２のゲーム処理のいずれのゲーム処理を中止又は中断するかを、ゲーム処理の優先度情報に基づいて判断してもよい。具体的には、ゲーム進行状況情報及び課金状態情報の少なくとも一方により設定された優先度情報に基づいて判断する。

例えば図３に示すように、この優先度情報はサーバシステム５００の記憶部６７０の優先度情報記憶部６７４に記憶されている。そして、この優先度情報は、例えばゲーム進行状況情報や課金状態情報などの各種情報により設定される。そして、ゲーム進行の観点から、第１、第２のゲーム処理のいずれか一方のゲーム処理が優先されると優先度情報に基づき判断した場合には、他方のゲーム処理を中止又は中断する。また、課金状態の観点から、第１、第２のゲーム処理のいずれか一方のゲーム処理が優先されると優先度情報に基づき判断した場合には、他方のゲーム処理を中止又は中断する。

また制御処理部６０６は、第１のゲーム処理の実行中に第２のゲーム処理の実行要求（実行）が検出された場合に、第１のゲーム処理の再開に必要なセーブ情報のセーブ処理を行う。例えば、第１のゲーム処理を再開するのに必要な各種の情報（進行状況情報、パラメータ情報）を保存する。例えばサーバ又は端末装置の記憶部に保存する。そして制御処理部６０６は、セーブ処理の後に第１のゲーム処理を中断して、第２のゲーム処理を実行した場合には、第２のゲーム処理の終了後に、セーブ情報に基づいて、第１のゲーム処理を再開する。即ち、第２のゲーム処理の終了後に、記憶部６７０に保存しておいたセーブ情報を読み出して、これらのセーブ情報に基づいてゲーム処理の再開に必要な各種の設定処理を行って、第１のゲーム処理を再開する。

また制御処理部６０６は、第１のゲーム処理の実行中に第２のゲーム処理の実行要求（実行）が検出された場合に、第１のゲーム処理の終了後に、第２のゲーム処理によるサーバ管理情報の更新処理を許可する。具体的には、例えば、第２のゲーム処理の実行要求が検出されると、第１のゲーム処理を中断して、第２のゲーム処理を実行し、第１のゲーム処理の終了後に、第２のゲーム処理によるサーバ管理情報の更新処理を許可する。即ち、第２のゲーム処理による更新処理を、第１のゲーム処理が終了するまでウェイトする。そして第１のゲーム処理が終了後に、第２のゲーム処理の実行結果に基づくサーバ管理情報を更新処理が行われるようにする。具体的には、ゲームパラメータ情報、ゲームアイテム情報、又はゲーム成績情報等の更新処理が行われるようにする。

また制御処理部６０６は、第１のゲーム処理の実行中に第２のゲーム処理の実行要求（実行）が検出された場合に、第１のゲーム処理のポーズ処理又はスローモーション処理を行う。そして例えば、ポーズ処理の期間又はスローモーション処理の期間において、第２のゲーム処理によるサーバ管理情報（ゲームパラメータ情報、ゲームアイテム情報、ゲーム成績情報等）の更新処理を許可する。

また、第１のゲーム処理のゲームが、複数のゲームステージ又は複数のゲームシーンにより構成されていたとする。例えば、複数のゲームステージを順次クリアすることで、第１のゲーム処理のゲームがクリアされる。或いは、複数のゲームシーンが順次移行して、各ゲームシーンでの映像が再生されることで、ユーザは、第１のゲームを鑑賞して楽しむ。

このとき、制御処理部６０６は、第１のゲーム処理の実行中に第２のゲーム処理の実行要求（実行）が検出された場合に、第２のゲーム処理によるサーバ管理情報の更新処理を、複数のゲームステージの各ステージの終了後又は複数のゲームシーンの各ゲームシーンの終了後に許可する。即ち、各ステージ又は各ゲームシーンが終了するまでは、第２のゲーム処理によるサーバ管理情報の更新処理を禁止し、各ステージ又は各ゲームシーンが終了したことを条件に、第２のゲーム処理によるサーバ管理情報の更新処理を許可する。

また制御処理部６０６は、第１のゲーム処理の実行中に第２のゲーム処理の実行要求（実行）が検出された場合に、第１のゲーム処理及び第２のゲーム処理の少なくとも一方のゲーム処理での画像表示又は音出力を変更する処理を、競合時処理として行ってもよい。具体的には、第１のゲーム処理の実行中に第２のゲーム処理の実行要求が検出されると、第１のゲーム処理における音出力のレベルを小さくする処理を行う。或いは、第１のゲーム処理における画像表示を、競合時用に用意された画像に切り替えてもよい。

或いは制御処理部６０６は、第１のゲーム処理の実行中に第２のゲーム処理の実行要求（実行）が検出された場合に、第１のゲーム処理のゲーム画面に、第２のゲーム処理のゲーム画面を表示するための処理を行ってもよい。例えば第１のゲーム処理のゲーム画面に対して、第２のゲーム処理のゲーム画面をウィンドウ表示（スーパーインポーズ表示）する処理を行う。

なお第１のゲーム処理と第２のゲーム処理は、例えば同一ユーザがプレイするゲームのゲーム処理である。例えば、同一のユーザＩＤのユーザによりプレイされるゲーム処理である。この場合に制御処理部６０６は、第１のゲーム処理と第２のゲーム処理とが、同一ユーザがプレイするゲームのゲーム処理であることを、ユーザがプレイする端末装置からのユーザ識別情報に基づいて判断する。

例えば端末装置が、ユーザＩＤ（ユーザ識別情報）が書き込まれたメモリーカードを装着して、ゲームをプレイするタイプの装置である場合には、端末装置に装着されたメモリーカードからユーザＩＤを読み出すことで、ユーザを識別して、第１のゲーム処理と第２のゲーム処理が同一ユーザがプレイするゲームであるか否かを判断する。

一方、端末装置が、ユーザＩＤやパスワードによりログインして、ゲームをプレイするタイプの装置である場合には、ログイン時に入力されたユーザＩＤに基づいて、ユーザを識別して、第１のゲーム処理と第２のゲーム処理が同一ユーザがプレイするゲームであるか否かを判断する。

なお、第１のゲーム処理は、例えばユーザの操作情報に基づいてゲーム処理が行われ、ゲームを構成する複数のゲームステージ又は複数のゲームシーンの各ゲームステージ毎又は各ゲームシーン毎に、サーバ管理情報の更新処理が行われるゲーム処理である。

例えば、ゲームステージ（ゲームシーン）でのゲームプレイ期間においては、端末装置の操作部からの操作情報に基づきゲーム処理（リアルタイムゲーム処理）が行われ、このゲームプレイ期間ではサーバ側のサーバ管理情報は更新されない。一方、ゲームステージ（ゲームシーン）が終了すると、サーバ管理情報へのアクセスが行われて、サーバ管理情報のゲーム成績情報等の更新処理が行われる。例えば業務用ゲーム装置や家庭用ゲーム装置のゲーム（格闘技ゲーム等）では、このような第１の方式のゲーム処理が行われる場合が多い。

これに対して、第２のゲーム処理は、ユーザの操作情報の入力毎に、サーバ管理情報の更新処理が行われるゲーム処理である。例えば、ユーザが端末装置の操作部を操作する毎に、サーバのサーバ管理情報に対するアクセス要求が行われて、その操作に応じたゲームパラメータ等のサーバ管理情報の更新処理が行われる。例えば携帯端末等のアプリゲーム（ソーシャルゲーム）では、このような第２の方式のゲーム処理が行われる場合が多い。なお、第２のゲーム処理は、このような第２の方式のゲーム処理のみならず、上述の第１の方式のゲーム処理を含んでいてもよい。

２．本実施形態の手法
次に本実施形態の手法について詳細に説明する。なお、以下では、サーバシステムを、適宜、単にサーバと記載する。また、以下では、第１のゲーム処理用の端末装置がゲーム装置であり、第２のゲーム処理用の端末装置が携帯端末である場合を主に例にとり説明するが、本実施形態はこれに限定されるものではない。

２．１ 競合時用処理
さて、前述した図１、図２に示すように、本実施形態では、端末装置ＴＭ１においては、第１のゲーム処理により、ユーザは第１のゲームをプレイできるようになっている。一方、端末装置ＴＭ２においては、第２のゲーム処理により、ユーザは第２のゲームをプレイできるようになっている。

ここで第１、第２のゲームは、同様のゲームタイトル（同一シリーズのゲームタイトル）のゲームであり、例えば、共通のキャラクタ、ゲームステージ、又はマップ等を使用できるようになっている。即ち、第１、第２のゲームを実現する第１、第２のゲーム処理は連携しており、ユーザは、端末装置ＴＭ１でプレイできるゲームタイトルを、端末装置ＴＭ２においてプレイできるようになっている。

このようにすれば、例えば端末装置ＴＭ１の第１のゲームで育成したキャラクタを、端末装置ＴＭ２の第２のゲームのキャラクタとして使用したり、逆に、端末装置ＴＭ２の第２のゲームで育成したキャラクタを、端末装置ＴＭ１の第１のゲームのキャラクタとして使用することが可能になり、好適な連携システムを実現できる。

例えば端末装置ＴＭ２の第２のゲームでキャラクタを育成して、そのステータス・パラメータを上昇させると、端末装置ＴＭ１の第１のゲームにおいても、ステータス・パラメータが上昇したキャラクタを使用して、ゲームをプレイできるようになる。また、例えば端末装置ＴＭ２の第２のゲームでキャラクタに武器や衣装などのアイテムを装備させると、端末装置ＴＭ１の第１のゲームにおいても、当該アイテムが装備されたキャラクタを使用して、ゲームをプレイできるようになる。

そして、このように、端末装置ＴＭ１でユーザがプレイする第１のゲームと、端末装置ＴＭ２でユーザがプレイする第２のゲームとで、共通のキャラクタやゲームステージ等をユーザが使用できるようにするためには、ゲーム処理自体は異なっていても、キャラクタ等のゲームパラメータや装備アイテム等のゲームデータについては、共通のゲームパラメータや共通のゲームデータを使用できるようにすることが望ましい。

しかしながら、このようにゲームパラメータやゲームデータ等を連携させた場合に、第１のゲーム処理と第２のゲーム処理が競合して、予期せぬ不具合等の問題が発生するおそれがある。

そこで本実施形態では、端末装置ＴＭ１の第１のゲーム処理の実行中に、端末装置ＴＭ２の第２のゲーム処理の実行要求（実行）が検出された場合に、ゲーム処理の競合時用処理を行うことで、上記問題を解決している。

例えば図５（Ａ）に示すように、第１のゲーム処理の実行の際には、サーバ上のサーバ管理情報が参照されて、その更新処理が行われる。同様に、第２のゲーム処理の実行の際にも、サーバ上のサーバ管理情報が参照されて、その更新処理が行われる。このサーバ管理情報は、図３に示すようにサーバのサーバ管理情報記憶部６７２に記憶されている。

ここでサーバ管理情報は、サーバの管理対象（更新対象）となる各種情報であり、図５（Ａ）、図５（Ｂ）に示すように、例えばゲームパラメータ情報、ゲームアイテム情報、ゲーム成績情報（ゲーム結果情報）、或いはユーザ情報などである。

ゲームパラメータ情報は、ゲーム処理における各種の判断処理（ゲーム進行の判断処理、ゲーム結果の判断処理等）や設定処理に使用されるパラメータ（変数）である。ゲームパラメータとしては、例えばキャラクタ等の状態（体力、攻撃力、守備力、耐久度、レベル等）を量的、質的に表すステータス・パラメータなどがある。ゲームアイテム情報は、ゲームに登場して使用される各種のアイテムの情報である。アイテムとしては、例えばキャラクタが身につける武器アイテム等の装着アイテム、キャラクタのステータスを変更する回復アイテム等のステータス変更アイテム、或いはキャラクタを成長させるための成長アイテムなどがある。ゲーム成績情報は、ゲームにおけるユーザ（プレーヤ）の得点やポイントや勝敗などを表す情報である。ユーザ情報は、例えばユーザの個人情報などであり、ユーザＩＤ、パスワード、性別、生年月日、或いは住所等などである。

そして図５（Ａ）、図５（Ｂ）に示すように、第１のゲーム処理と第２のゲーム処理は、同じサーバ管理情報を更新対象とするゲーム処理である。例えば、第１のゲーム処理と第２のゲーム処理とは、図３のサーバ管理情報記憶部６７２に記憶されるゲームパラメータ情報、ゲームアイテム情報、ゲーム成績情報、或いはゲーム成績情報などのサーバ管理情報を、共通のサーバ管理情報として、その更新処理の対象とする。

例えば、第１のゲーム処理による第１のゲームと、第２のゲーム処理による第２のゲームには、共通のキャラクタが登場する。そして、この共通のキャラクタのステータス・パラメータなどのゲームパラメータ情報は、第１のゲーム処理によって更新されると共に、第２のゲーム処理によっても更新される。

また、第１のゲーム処理による第１のゲームと、第２のゲーム処理による第２のゲームには、共通のアイテムが登場する。そして、この共通のアイテムの情報は、第１のゲーム処理によって更新されると共に、第２のゲーム処理によっても更新される。例えば第１、第２のゲームのいずれか一方のゲームおいて、アイテムが獲得されると、他方のゲームにおいても、そのアイテムが獲得されて登場するようになる。また第１、第２のゲームのいずれか一方のゲームにおいて、ユーザのゲーム成績が演算されて更新されると、他方のゲームにおいても、ユーザのゲーム成績が更新されるようになる。

ここで、例えば図６（Ａ）に示すように、第１のゲーム処理の実行中に、第２のゲーム処理の実行要求があり、第１のゲーム処理と第２のゲーム処理が同時に実行された場合を想定する。

このような場合には、第１のゲーム処理と第２のゲーム処理の両方により、ゲームパラメータ情報やゲームアイテム情報などのサーバ管理情報が更新されてしまうと、サーバ管理情報に不具合が発生するおそれがある。即ち、サーバ管理情報のゲームパラメータ情報やゲームアイテム情報に矛盾等が生じ、最悪の場合、第１のゲーム処理と第２のゲーム処理の両方がハングアップするような事態が生じるおそれがある。

そこで本実施形態では、図６（Ｂ）に示すように、第１のゲーム処理の実行中に、第１のゲーム処理と同じサーバ管理情報を更新対象とする第２のゲーム処理の実行要求が検出された場合に、ゲーム処理の競合時用の処理を実行する。

このようにすれば、このゲーム処理の競合時用の処理が実行されることで、第１のゲーム処理と第２のゲーム処理の競合による不具合の発生等を抑制することが可能になり、サーバ管理情報のゲームパラメータ情報やゲームアイテム情報に矛盾等が生じ、第１、第２のゲーム処理の両方がハングアップするような事態の発生を効果的に防止できる。

ここで、ゲーム処理の競合時用の処理は、第１のゲーム処理と第２のゲーム処理が競合した場合のために、例えば予め用意された処理であり、競合時用の制御処理としてプログラミングされた処理であり、サーバの制御処理部６０６により実行される。なお、以下では制御処理部６０６の競合時用処理の対象となるゲーム処理が、第１、第２のゲーム処理というように２つのゲーム処理である場合を主に例にとり説明するが、本実施形態はこれに限定されない。例えば競合時用処理の対象となるゲーム処理は、例えば第１〜第３のゲーム処理というように３つ以上のゲーム処理であってもよい。

２．２ 第１、第２のゲーム処理
次に、第１、第２のゲーム処理や第１、第２のゲーム処理により実現される第１、第２のゲームの具体例について説明する。

図７（Ａ）、図７（Ｂ）は第１のゲーム処理とそれにより実現される第１のゲームの例である。この第１のゲームは、いわゆる格闘技ゲームである。この第１のゲームでは、ユーザは図４の操作部２６０を操作して、自身が操作するキャラクタであるプレーヤキャラクタＣＨＰを操作する。そして、コンピュータ又は相手プレーヤが操作する敵キャラクタＣＨＥと対戦する。そして、敵キャラクタＣＨＥのヒットポイントが０になるなどの所定条件が満たされると、ユーザの勝利となり、図７（Ｂ）に示すような画面が表示される。

このように第１のゲーム処理は、ユーザの操作情報に基づいて、ゲーム処理が行われ、ゲームを構成する複数のゲームステージ（又は複数のゲームシーン）の各ゲームステージ毎（又は各ゲームシーン毎）に、サーバ管理情報の更新処理が行われるゲーム処理である。

即ち、図７（Ａ）に示すように、ユーザが入力した操作情報（ゲーム操作）に基づいて、複数のゲームステージ（又は複数のゲームシーン）の各ゲームステージ（又は各ゲームシーン）での処理が行われる。例えば操作情報に基づいて、プレーヤキャラクタＣＨＰを動作させるなどの処理（モーション処理）が行われる。そして、このゲームステージ（ゲームシーン）の期間内では、サーバ管理情報へのアクセスは行われず、サーバ管理情報の更新処理は行われない。

一方、ゲームステージ（ゲームシーン）が終了すると、サーバ管理情報へのアクセスが行われ、サーバ管理情報の更新処理が行われる。具体的には、各ゲームステージでのゲーム結果に基づいて、サーバ管理情報のゲーム成績情報が更新される。例えばゲームステージの勝敗結果等に基づいて、ゲーム成績情報の勝敗情報等が更新される。また各ゲームステージでのゲーム結果に基づいて、サーバ管理情報のキャラクタのパラメータ情報の更新処理が行われる。例えば、ゲームステージでのゲーム結果に基づいて、キャラクタのステータス・パラメータが更新され、キャラクタの育成処理等が行われる。

図８（Ａ）、図８（Ｂ）は、第２のゲーム処理とそれにより実現される第２のゲームの例である。この第２のゲームは、いわゆるソーシャルゲーム等で行われる手法のゲームである。例えばユーザは図８（Ａ）のＡ１に示すようにゲーム画面上に表示された実行ボタンをタッチする。すると、例えば敵への攻撃等が行われる。そして、敵の撃破に成功すると、図８（Ｂ）に示すようなゲーム画面が表示される。

そして、この第２のゲーム処理では、Ａ１に示すようにユーザがゲーム操作を行う毎に、Ａ２に示すようにサーバへのアクセス処理が行われて、ゲームパラメータ情報等のサーバ管理情報の更新が行われる。このように第２のゲーム処理は、ユーザの操作情報の入力毎に、サーバ管理情報の更新処理が行われるゲーム処理である。例えばソーシャルゲーム等では、ハードウェア等の制約から、そのゲーム処理の処理負荷を軽くする必要がある。また、ゲームプレイへのユーザの拘束時間を少なくして、ユーザが手軽にゲームを楽しめるようにしている。このため図８（Ａ）、図８（Ｂ）に示すような簡素な操作でゲーム処理が実行されて、ユーザがゲームを手軽に楽しめるようになっている。

図９（Ａ）、図９（Ｂ）は、第２のゲーム処理の他の例である。この第２のゲーム処理では、自身が操作するキャラクタのパワーアップや育成のために、アイテムをネット購入するためのゲーム処理が行われる。例えば図９（Ａ）では、ユーザが選択したゲームタイトルにおいてネット購入できる商品のリストが表示される。そして、ユーザが端末装置の操作部２６０を操作して、図９（Ｂ）のように商品であるアイテムを購入すると、サーバのサーバ管理情報へのアクセスが行われ、サーバ管理情報のゲームアイテム情報等が更新される。

なお、以上では、図７（Ａ）、図７（Ｂ）のようなゲーム処理を、第１のゲーム処理として、図８（Ａ）〜図９（Ｂ）のようなゲーム処理を、第２のゲーム処理としたが、本実施形態はこれに限定されない。例えば、逆に、図７（Ａ）、図７（Ｂ）のようなゲーム処理を、第２のゲーム処理として、図８（Ａ）〜図９（Ｂ）のようなゲーム処理を、第１のゲーム処理とししてもよい。

２．３ 競合時用処理の第１の例
図１０に、ゲーム処理の競合時用処理の第１の例を示す。図１０では、第１のゲーム処理の実行中に、第２のゲーム処理の実行要求が検出されている。前述した図５（Ａ）、図５（Ｂ）に示すように、この第２のゲーム処理は、第１のゲーム処理と同じサーバ管理情報（同じ記憶領域に記憶されるサーバ管理情報）を更新対象とするゲーム処理である。

このように、第１のゲーム処理の実行中に第２のゲーム処理の実行要求が検出された場合に、図１０では、第２のゲーム処理の実行を禁止する処理を、競合時用処理として行っている。更に、第２のゲーム処理が行われる端末装置に対して、第２のゲーム処理の実行が禁止であることを通知する処理を、競合時用処理として行っている。

例えばユーザが業務用ゲーム装置で図７（Ａ）、図７（Ｂ）に示す第１のゲームをプレイしていたとする。このような場合に、そのユーザが、図７（Ａ）、図７（Ｂ）で操作しているキャラクタＣＨＰと同じキャラクタを用いて図８（Ａ）、図８（Ｂ）に示すようなゲームをプレイしたり、図９（Ａ）、図９（Ｂ）に示すようにアイテムを購入したとする。すると、図７（Ａ）、図７（Ｂ）で戦闘中のキャラクタＣＨＰのゲームパラメータの値が、予期しない値に変更されてしまったり、図８（Ａ）、図８（Ｂ）のアイテム購入により、図７（Ａ）、図７（Ｂ）の戦闘中のキャラクタが不正にパワーアップしてしまうなどの事態が生じる。

従って、このような場合には、図７（Ａ）、図７（Ｂ）の第１のゲーム処理を優先して、図８（Ａ）〜図９（Ｂ）の第２のゲーム処理については、その実行を禁止するようにする。また、実行が禁止されたことをユーザに知らせるために、実行の禁止を通知する表示を、例えば第２のゲームを行っている端末装置（図１、図２のＴＭ２）の表示部に表示する。

このような競合時用の処理を行えば、第１のゲーム処理の実行中は、第２のゲーム処理が禁止されて、実行されないようになる。従って、第１、第２のゲーム処理が並列に実行されて、サーバ管理情報等にデータの不整合が生じたり、第１、第２のゲーム処理の両方がハングアップするような事態の発生を効果的に防止できる。具体的には、第１のゲームの途中で、第１のゲームのキャラクタのパラメータや所持アイテムが変更されてしまうような事態の発生を防止できる。また、第２のゲーム処理の実行が禁止された旨をユーザに伝えることで、ユーザが不自然に思うなどの事態を防止でき、ユーザの利便性を向上できる。

２．４ 競合時用処理の第２の例
図１１（Ａ）、図１１（Ｂ）に、ゲーム処理の競合時用処理の第２の例を示す。図１１（Ａ）では、第１のゲーム処理の実行中に第２のゲーム処理の実行要求が検出されると、制御処理部６０６は、第１のゲーム処理及び第２のゲーム処理の一方のゲーム処理を中止又は中断する処理を、競合時用処理として行う。

例えば図１１（Ａ）において、第２のゲーム処理の方を優先する場合には、制御処理部６０６は、第１のゲーム処理の実行を中止又は中断する。そして、第２のゲーム処理だけが実行されるように制御する。そして、このような競合時に第１のゲーム処理を中断した場合には、例えば第２のゲーム処理の終了後に、第１のゲーム処理を再開する。一方、第１のゲーム処理の方を優先する場合には、制御処理部６０６は、第２のゲーム処理を中止又は中断（禁止）する。そして、第１のゲーム処理だけが実行されるように制御する。

このような競合時用の処理を行えば、第１、第２のゲーム処理の一方が中止又は中断されるため、第１、第２のゲーム処理が並列に実行されてしまう事態を防止できる。従って、第１、第２のゲーム処理が並列に実行されて、サーバ管理情報等にデータの不整合が生じたり、ゲーム処理のハングアップ等の事態が発生するのを防止できる。

そして図１１（Ａ）のように、第１、第２のゲーム処理の一方を中止又は中断する場合には、その判断基準として、優先度情報を用いることが望ましい。

具体的には図１１（Ｂ）に示すように、制御処理部６０６は、第１、第２のゲーム処理のいずれのゲーム処理を中止又は中断するかを、ゲーム処理の優先度情報に基づいて判断する。例えば、優先度情報に基づいて、第１のゲーム処理の方がゲーム処理の優先度が高いと判断された場合には、第２のゲーム処理を中断又は中止する。一方、優先度情報に基づいて、第２のゲーム処理の方がゲーム処理の優先度が高いと判断された場合には、第１のゲーム処理を中断又は中止する。

この場合に優先度情報は、図１１（Ｂ）に示すよう、例えばゲーム進行状況情報や課金状態情報に基づき設定できる。

例えば図１１（Ｂ）において、第１のゲーム処理のゲーム進行が進んでおり、第１のゲーム処理を中止又は中断することが望ましくない場合がある。例えば長いゲームステージの後半まで第１のゲーム処理のゲーム進行が進んでいる場合には、第１のゲーム処理の方を優先すべきである。従って、この場合には、ゲーム進行状況情報に基づき設定された優先度情報に基づいて、第２のゲーム処理を中止又は中断し、第１のゲーム処理の実行を継続する。

また、例えば第１のゲーム処理による第１のゲームが、例えば１ゲームのプレイ毎にゲーム料金を投入するゲーム（例えば業務用ゲーム装置のゲーム）であり、第２のゲーム処理による第２のゲームが、例えば月単位でゲーム料金を支払うゲーム（例えばソーシャルゲーム等のゲームアプリ）であったとする。この場合には、１ゲーム分のゲーム料金が投入されてゲームプレイが行われている第１のゲーム処理の方を中止又は中断するのは適切ではない。従って、この場合には、課金状態情報に基づき設定された優先度情報に基づいて、第２のゲーム処理の実行の方を中止又は中断し、第１のゲーム処理の実行を継続する。

なお、このようなゲーム処理の中止、中断を判断する基準となる優先度情報の設定は、ゲーム進行状況情報や課金状態情報による設定には限定されず、種々の変形実施が可能である。例えば第１のゲームがメインのゲームであり、第２のゲームがサブのゲームである場合には、常に第１のゲーム処理の方を優先するというような優先度情報の設定にしてもよい。

２．５ 競合時用処理の第３の例
図１２（Ａ）、図１２（Ｂ）に、ゲーム処理の競合時用処理の第３の例を示す。図１２（Ａ）では、第１のゲーム処理の実行中に第２のゲーム処理の実行要求が検出されると、制御処理部６０６は、競合時用の処理として、第１のゲーム処理のセーブ情報のセーブ処理を行う。即ち、第１のゲーム処理の再開に必要な様々なデータをセーブ情報として保存する。そして図１２（Ａ）に示すように、セーブ処理の後に、第１、第２のゲーム処理のいずれか一方のゲーム処理を実行する。この場合に他方のゲーム処理については中止又は中断する。

また図１２（Ｂ）に示すように、セーブ処理の後に、第１のゲーム処理を中断して、第２のゲーム処理を実行したとする。この場合には、第２のゲーム処理の終了後に、セーブ情報に基づいて、第１のゲーム処理を再開する。

即ち、セーブ処理後に第１のゲーム処理を中断して、その中断期間において、第２のゲーム処理を実行する。このようにすれば、この中断期間では、第１、第２のゲーム処理が並列に実行されないようになる。従って、不正な更新処理によりサーバ管理情報等にデータの不整合が生じたり、ゲーム処理のハングアップ等の事態が発生するのを防止できる。

また、第２のゲーム処理が終了した後に、セーブ情報に基づいて第１のゲーム処理を再開すれば、第２のゲーム処理のみならず、第１のゲーム処理についても、その処理の最後まで実行して、第１のゲーム処理を適正に終了させることが可能になる。

２．６ 競合時用処理の第４の例
図１３に、ゲーム処理の競合時用処理の第４の例を示す。図１３では、第１のゲーム処理の実行中に第２のゲーム処理の実行要求が検出された場合に、第１のゲーム処理の終了後に、第２のゲーム処理によるサーバ管理情報の更新処理を許可する。更に具体的には、第１のゲーム処理の実行中に第２のゲーム処理の実行要求が検出されると、第１のゲーム処理を中断して、第２のゲーム処理を実行する。即ち、第２のゲーム処理の方を優先して実行する。そして、第２のゲーム処理が終了し、その後に、例えば第１のゲームが再開されて終了すると、その第１のゲーム処理の終了後に、第２のゲーム処理によるサーバ管理情報の更新処理を許可する。

このようにすれば、第１のゲーム処理の実行期間中に、第２のゲーム処理の方を優先して実行した場合においても、その第２のゲーム処理によるサーバ管理情報の更新処理により、サーバ管理情報にデータの不整合等の不具合が発生するのを効果的に防止できる。

具体的には、第１のゲーム処理の実行期間中に、第２のゲーム処理の方を優先して実行して、第２のゲーム処理が終了した場合に、その第２のゲーム処理の終了時点では、第２のゲーム処理によるサーバ管理情報の更新処理は行わないようにする。

そして、その後に、第１のゲーム処理が再開され、第１のゲーム処理が終了すると、その終了時点において、第１のゲーム処理によるサーバ管理情報の更新処理を行う。これにより、第１のゲーム処理の結果が、サーバ管理情報に対して反映されることになる。

そして、その後に、第２のゲーム処理によるサーバ管理情報の更新処理を行う。このようにすれば、第１のゲーム処理によるサーバ管理情報の更新処理が行われた後に、第２のゲーム処理によるサーバ管理情報の更新処理が行われることになる。従って、サーバ管理情報の更新処理に競合が起きて、サーバ管理情報にデータの不整合が生じるなどの事態を効果的に防止できる。

なお、上記では、第１のゲーム処理の終了後に、第１のゲーム処理によるサーバ管理情報の更新処理を行い、その後に、第２のゲーム処理によるサーバ管理情報の更新処理を行う場合について説明したが、本実施形態はこれに限定されない。例えば、第１のゲーム処理の終了後に、第２のゲーム処理によるサーバ管理情報の更新処理を行い、その後に、第１のゲーム処理によるサーバ管理情報の更新処理を行ってもよい。この場合に、第１、第２の処理のいずれのゲーム処理によるサーバ管理情報の更新処理を優先するかは、図１１（Ｂ）で説明したような優先度情報などに基づいて判断すればよい。

２．７ 競合時用処理の第５の例
図１４に、ゲーム処理の競合時用処理の第５の例を示す。図１４では、第１のゲーム処理の実行中に第２のゲーム処理の実行要求が検出された場合に、第１のゲーム処理のポーズ処理又はスローモーション処理を行う。そして例えば、このポーズ処理又はスローモーション処理の期間において、第２のゲーム処理によるサーバ管理情報の更新処理を許可する。

例えば第１のゲーム処理が、図７（Ａ）、図７（Ｂ）のような格闘技ゲームの処理であり、第２のゲーム処理が、図９（Ａ）、図９（Ｂ）のようなアイテムをネット購入するための処理であったとする。

この場合に、ユーザは、例えば図７（Ａ）、図７（Ｂ）のように格闘技ゲームをプレイしている途中で、自身のキャラクタＣＨＰをパワーアップ等するアイテムを購入して、戦闘を有利に進めたい場合もある。具体的には、業務用ゲーム装置（図１のＴＭ１）で図７（Ａ）、図７（Ｂ）の格闘技ゲームをプレイしている最中に、スマートフォン等の携帯端末（図１のＴＭ２）を用いて、キャラクタＣＨＰのパワーアップ用のアイテムをネット購入する。そして、不利な戦況等を解消して、逆転勝利等を狙う場合がある。

例えば、このようなゲーム途中によるアイテム購入を、不正使用であるとして認めない場合には、図１０で説明した手法により、第２のゲーム処理の実行を禁止すればよい。

しかしながら、このようなゲーム途中によるアイテム購入を認めることで、逆に、これまでにないタイプのゲームを創出して、ゲームの面白みを増すことができる。

ところが、図７（Ａ）、図７（Ｂ）の格闘技ゲームの処理は、リアルタイム処理であるため、この第１のゲーム処理が通常の処理速度で実行されてしまうと、ユーザがアイテム等を購入する期間を確保できなくなってしまう。例えば業務用ゲーム装置で格闘技ゲームをプレイしながら、スマートフォン等の携帯端末でアイテムを購入するのは、難易度が高い。

そこで、このような場合に対応するために、図１４では、アイテム購入等のための第２のゲーム処理の実行が要求されると、リアルタイム処理である第１のゲーム処理のポーズ処理又はスローモーション処理を行う。

このようにすれば、ユーザは、このポーズ処理又はスローモーション処理の期間を利用して、第２のゲーム処理によりアイテムをネット購入し、自身が操作中のプレーヤキャラクタＣＨＰをパワーアップさせることなどが可能になる。或いは、対戦相手である敵キャラクタＣＨＥとの相性を考えたアイテム装備などを行うことも可能になる。従って、これまでにないタイプのネットワークゲームの連携システムを実現できる。

なお、第１のゲーム処理のポーズ処理やスローモーション処理は、キャラクタ等のモデルオブジェクトのモーション処理を制御することで実現可能である。具体的には、ポーズ処理では、キャラクタ等のモデルオブジェクトのモーションが停止するようにモーション処理を制御する。またスローモーション処理では、モデルオブジェクトのモーション速度が遅くなるようにモーション処理を制御する。

モーション処理は、モデルオブジェクトのモーションを、モーションデータ記憶部に記憶されているモーションデータに基づいて再生することなどで実現できる。例えばモデルオブジェクトのスケルトンを構成する骨（モーション骨、関節、パーツオブジェクト）の位置、回転角度が、モーションデータとして記憶される。例えば、キャラクタ等の歩きモーションが、複数の基準モーションにより構成されている場合に、これらの各基準モーションでの各骨の位置又は回転角度が、モーションデータとして予め記憶されている。そして、例えば第１の基準モーションの各骨（各パーツオブジェクト）の位置、回転角度を読み出し、次に第２の基準モーションの各骨の位置、回転角度を読み出すというように、基準モーションのモーションデータを時間経過に伴い順次読み出すことで、モーション処理が実現される。そして、上述のポーズ処理やスローモーション処理は、この基準モーションのモーションデータの読み出し速度等を制御することで実現できる。

以上のように本実施形態の種々の処理例について説明したが、本実施形態はこれに限定されず、種々の変形実施が可能である。

例えば図１５には、第２のゲーム処理によるサーバ管理情報の更新処理の他の例を示す。図１５では、第１のゲーム処理のゲームは、複数のゲームステージにより構成される。即ち、一連の複数のゲームステージの各ゲームステージを順次クリアすることで、ゲームを進めて行く。或いは、第１のゲーム処理のゲームは、複数のゲームシーンにより構成され、ゲームシーンの切り替わりイベントが発生する毎に、ゲームシーンが切り替わって行く。例えば各ゲームシーンは、ＣＧムービーなどの映像単位で構成される。

そして図１５では、このような第１のゲーム処理の実行中に第２のゲーム処理の実行要求が検出されると、第２のゲーム処理によるサーバ管理情報の更新処理を、各ゲームステージの終了後又は各ゲームシーンの終了後に許可する。

例えば図１５のように、第１のゲーム処理の第１のゲームステージの期間において、第２のゲーム処理の実行要求が来た場合には、この第１のゲームステージの期間内においては、第２のゲーム処理によるサーバ管理情報の更新処理を不許可とする。そして、第１のゲームステージが終了した後に、第２のゲーム処理によるサーバ管理情報の更新処理を許可して実行させる。

同様に、第１のゲーム処理の第２のゲームステージの期間において、第２のゲーム処理の実行要求が来た場合には、この第２のゲームステージの期間内においては、第２のゲーム処理によるサーバ管理情報の更新処理を不許可とする。そして、第２のゲームステージが終了した後に、第２のゲーム処理によるサーバ管理情報の更新処理を許可して実行させる。

このようにすれば、第１のゲーム処理のゲームにおいて区切りが良いタイミングで、サーバ管理情報の更新処理を実行できるようになる。例えば、ゲームステージやゲームシーンが終了して、例えば第１のゲーム処理によるサーバ管理情報の更新処理が終了した後に、第２のゲーム処理によるサーバ管理情報の更新処理を行うというような制御処理が可能になる。従って、サーバ管理情報の更新処理の競合により、サーバ管理情報にデータの不整合等が生じる事態を、効果的に抑制できる。

また本実施形態では、第１のゲーム処理の実行中に第２のゲーム処理の実行要求が検出された場合に、第１のゲーム処理及び前記第２のゲーム処理の少なくとも一方のゲーム処理での画像表示又は音出力を変更する処理を、競合時処理として行ってもよい。

例えば図１６では、第１のゲーム処理の実行中に、第２のゲーム処理の実行要求があった場合に、第１のゲーム処理での音出力レベルを小さくしている。例えば第１のゲーム処理として図７（Ａ）、図７（Ｂ）に示すような格闘技ゲームなどの処理が行われていると、ゲーム装置の音出力レベルが非常に大きくなっている場合が想定される。従って、例えば図１４に示すようなポーズ処理等を行ったとしても、音出力レベルの大きさが邪魔になって、ユーザがスムーズはゲーム操作を行えない事態が生じるおそれがある。この点、このような場合に、例えば第１のゲーム処理による音出力レベルを低くすれば、ユーザのスムーズなゲーム操作等を実現することができ、ユーザの利便性を向上できる。

或いは、第１のゲーム処理の実行中に第２のゲーム処理の実行要求が検出された場合に、第１のゲーム処理のゲーム画面に、第２のゲーム処理のゲーム画面を表示するための処理を行ってもよい。

例えば図１７では、第１のゲーム処理の第１のゲームとして、図７（Ａ）、図７（Ｂ）で示すような格闘技ゲームがプレイされており、このような格闘技ゲームの際に、例えば第２のゲーム処理として、図９（Ａ）、図９（Ｂ）に示すようなアイテムの購入処理が行われている。

このような場合に図１７のＢ１に示すように、第２のゲーム処理であるアイテムの購入処理のゲーム画面を、第１のゲーム処理のゲーム画面上に表示する。

このようにすれば、ユーザは、格闘技ゲーム等の第１のゲームのゲーム画面を見ながら、このゲーム画面上で、アイテムの購入についても確認できるようになる。従って、ユーザは、スムーズな操作でアイテムを購入できるようになり、ユーザにとって利便性の高いインターフェース環境を提供できる。

なお、以上に説明した第１、第２のゲーム処理は、例えば同一ユーザがプレイするゲームのゲーム処理である。即ち本実施形態では、例えば第１のユーザがプレイする第１のゲーム処理の実行中に、同じ第１のユーザがプレイする第２のゲーム処理の実行要求が検出された場合に、ゲーム処理の競合時用の処理を行う。具体的な状況としては、例えばゲームセンター等のアミューズメント施設で、第１のユーザが図７（Ａ）、図７（Ｂ）に示すような第１のゲーム処理による第１のゲームをプレイし、そのプレイの最中に、その第１のユーザが、図８（Ａ）、図８（Ｂ）や図９（Ａ）、図９（Ｂ）に示すような第２のゲーム処理による第２のゲームをプレイする。本実施形態では、このような状況において、ゲーム処理の競合時用の処理を行う。

この場合に、第１のゲーム処理と第２のゲーム処理とが、同一ユーザがプレイするゲームのゲーム処理であることは、ユーザがプレイする端末装置からのユーザ識別情報に基づいて判断することができる。

例えば図１８において、ユーザは、業務用ゲーム装置ＴＭ１で第１のゲームをプレイし、携帯端末ＴＭ２で第２のゲームをプレイしている。

そして、業務用ゲーム装置ＴＭ１では、いわゆるＩＣカード（メモリーカード）にユーザＩＤが記憶されており、このＩＣカードを、業務用ゲーム装置のカードリーダー等に装着したり、かざすことで、ユーザＩＤが読み取られ、業務用ゲーム装置ＴＭ１でプレイしているユーザが第１のユーザであることが認識される。

一方、携帯端末ＴＭ２では、そのゲームタイトルをプレイする際に、ユーザＩＤやパスワードを入力してログインするため、その時のユーザＩＤに基づいて、携帯端末ＴＭ２でそのゲームタイトルをプレイしているユーザが第１のユーザであることが認識される。

そして、業務用ゲーム装置ＴＭ１でプレイしているユーザが第１のユーザであり、携帯端末ＴＭ２で同じゲームタイトルをプレイしているユーザが同じ第１のユーザであり、且つ、業務用装置ＴＭ１の第１のゲーム処理と携帯端末ＴＭ２の第２のゲーム処理が競合している判断された場合に、本実施形態の競合時用処理が実行されることになる。

このようにすれが、第１のユーザについてのサーバ管理情報が、第１、第２のゲーム処理の競合により、そのデータに不整合が起きるなどの不具合を、効果的に防止できるようになる。

３．詳細な処理例
次に本実施形態の詳細な処理例について図１９〜図２２のフローチャートを用いて説明する。

図１９は、図１０で説明した手法の詳細な処理例を示すフローチャートである。まず、第１のゲーム処理を実行する（ステップＳ１）。そして、この第１のゲーム処理の実行中に第２のゲーム処理の実行が要求されたか否かを判断する（ステップＳ２）。そして、第２のゲーム処理の実行が要求された場合には、第２のゲーム処理の実行を禁止する（ステップＳ３）。そして、この実行禁止の通知を、第２のゲーム処理のゲーム画面に表示する（ステップＳ４）。

図２０は、図１１（Ａ）、図１１（Ｂ）で説明した手法の詳細な処理例を示すフローチャートである。まず、第１のゲーム処理を実行する（ステップＳ１１）。そして、この第１のゲーム処理の実行中に第２のゲーム処理の実行が要求されたか否かを判断する（ステップＳ１２）。そして、第２のゲーム処理の実行が要求された場合には、ゲーム処理についての優先度情報を参照してゲーム処理の優先度を判断する（ステップＳ１３）。そして優先度情報に基づいて、第１のゲーム処理と第２のゲーム処理のいずれか一方のゲーム処理を中止又は中断する処理を行う（ステップＳ１４）。

図２１は、図１２（Ａ）、図１２（Ｂ）、図１３で説明した手法の詳細な処理例を示すフローチャートである。まず、第１のゲーム処理を実行する（ステップＳ２１）。そして、この第１のゲーム処理の実行中に第２のゲーム処理の実行が要求されたか否かを判断する（ステップＳ２２）。そして、第２のゲーム処理の実行が要求された場合には、第１のゲーム処理のセーブ情報のセーブ処理を行う（ステップＳ２３）。そして第１のゲーム処理を中断する（ステップＳ２４）。

次に、第２のゲーム処理を実行する（ステップＳ２５）。そして、第２のゲーム処理が終了したか否かを判断する（ステップＳ２６）。そして、第２のゲーム処理が終了した場合には、ステップＳ２３で保存されたセーブ情報に基づいて、第１のゲーム処理を再開する（ステップＳ２７）。

次に、再開した第１のゲーム処理が終了したか否かを判断する（ステップＳ２８）。そして第１のゲーム処理が終了したと判断した場合に、第２のゲーム処理によるサーバ管理情報の更新処理を許可する（ステップＳ２９）。

図２２は、図１４で説明した手法の詳細な処理例を示すフローチャートである。まず、第１のゲーム処理を実行する（ステップＳ３１）。そして、この第１のゲーム処理の実行中に第２のゲーム処理の実行が要求されたか否かを判断する（ステップＳ３２）。そして、第２のゲーム処理の実行が要求された場合には、第１のゲーム処理のポーズ処理又はスローモーション処理を行う（ステップＳ３３）。

次に、第２のゲーム処理を実行する（ステップＳ３４）。そして、この際に、第２のゲーム処理によるサーバ管理情報の更新処理を許可する（ステップＳ３５）。

次に、第２のゲーム処理が終了したか否か（一定時間が経過したか否か）を判断する（ステップＳ３６）。そして第２のゲーム処理が終了した場合（一定時間が経過した場合）には、ステップＳ３３で開始した第１のゲーム処理のポーズ処理又はスローモーション処理を解除する（ステップＳ３７）。

なお、上記のように本実施形態について詳細に説明したが、本発明の新規事項および効果から実体的に逸脱しない多くの変形が可能であることは当業者には容易に理解できるであろう。従って、このような変形例はすべて本発明の範囲に含まれるものとする。例えば、明細書又は図面において、少なくとも一度、より広義または同義な異なる用語（端末装置等）と共に記載された用語（ゲーム装置・携帯端末等）は、明細書又は図面のいかなる箇所においても、その異なる用語に置き換えることができる。また、ゲーム処理の競合時用処理、第１、第２のゲーム処理、第１、第２のゲーム処理の制御処理、サーバ管理情報の更新・管理処理、情報の送受信処理等も本実施形態で説明したものに限定されず、これらと均等な手法も本発明の範囲に含まれる。

ＴＭ、ＴＭ１〜ＴＭｎ 端末装置、
２００ 処理部、２０２ 受信処理部、２０４ 送信処理部、２０８ ゲーム処理部、
２２０ 表示制御部、２３０ 音制御部、２６０ 操作部、
２６４ 撮像部、２７０ 記憶部、２８０ 情報記憶媒体、２９０ 表示部、
２９２ 音出力部、２９４ Ｉ／Ｆ部、２９５ 不揮発性記憶装置、２９６ 通信部、
５００ サーバシステム、５１０ ネットワーク、６００ 処理部、
６０２ 受信処理部、６０４ 送信処理部、６０６ 制御処理部、
６０８ ゲーム処理部、６１０ 管理処理部、６２０ 画像情報生成部、
６３０ 音情報生成部、６６０ 操作部、６７０ 記憶部、
６７２ サーバ管理情報記憶部、６７４ 優先度情報記憶部、６８０ 情報記憶媒体、
６９６ 通信部

Claims (22)

1. ネットワークを介して情報を受信する処理を行う受信処理部と、
   前記ネットワークを介して情報を送信する処理を行う送信処理部と、
   ゲーム処理の制御処理を行う制御処理部と、
   前記ゲーム処理の更新対象となる情報を、サーバ管理情報として記憶する記憶部と、
   を含み、
   前記制御処理部は、
   第１のゲーム処理の実行中に、前記第１のゲーム処理と同じ前記サーバ管理情報を更新対象とする第２のゲーム処理の実行要求が検出された場合に、ゲーム処理の競合時用処理を行うことを特徴とするサーバシステム。
2. 請求項１において、
   前記制御処理部は、
   前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第２のゲーム処理の実行を禁止する処理を、前記競合時用処理として行うことを特徴とするサーバシステム。
3. 請求項１又は２において、
   前記制御処理部は、
   前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第２のゲーム処理が行われる端末装置に対して、前記第２のゲーム処理の実行が禁止であることを通知する処理を、前記競合時用処理として行うことを特徴とするサーバシステム。
4. 請求項１において、
   前記制御処理部は、
   前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第１のゲーム処理及び前記第２のゲーム処理の一方のゲーム処理を中止又は中断する処理を、前記競合時用処理として行うことを特徴とするサーバシステム。
5. 請求項４において、
   前記制御処理部は、
   前記第１のゲーム処理及び前記第２のゲーム処理のいずれのゲーム処理を中止又は中断するかを、ゲーム処理の優先度情報に基づいて判断することを特徴とするサーバシステム。
6. 請求項５において、
   前記制御処理部は、
   前記第１のゲーム処理及び前記第２のゲーム処理のいずれのゲーム処理を中止又は中断するかを、ゲーム進行状況情報及び課金状態情報の少なくとも一方により設定された前記優先度情報に基づいて判断することを特徴とするサーバシステム。
7. 請求項１において、
   前記制御処理部は、
   前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第１のゲーム処理の再開に必要なセーブ情報のセーブ処理を行うことを特徴とするサーバシステム。
8. 請求項７において、
   前記制御処理部は、
   前記セーブ処理の後に、前記第１のゲーム処理を中断して、前記第２のゲーム処理を実行した場合には、前記第２のゲーム処理の終了後に、前記セーブ情報に基づいて、前記第１のゲーム処理を再開することを特徴とするサーバシステム。
9. 請求項１において、
   前記制御処理部は、
   前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第１のゲーム処理の終了後に、前記第２のゲーム処理による前記サーバ管理情報の更新処理を許可することを特徴とするサーバシステム。
10. 請求項９において、
    前記制御処理部は、
    前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第１のゲーム処理を中断して、前記第２のゲーム処理を実行し、前記第１のゲーム処理の終了後に、前記第２のゲーム処理による前記サーバ管理情報の更新処理を許可することを特徴とするサーバシステム。
11. 請求項１において、
    前記制御処理部は、
    前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第１のゲーム処理のポーズ処理又はスローモーション処理を行うことを特徴とするサーバシステム。
12. 請求項１１において、
    前記制御処理部は、
    前記ポーズ処理の期間又は前記スローモーション処理の期間において、前記第２のゲーム処理による前記サーバ管理情報の更新処理を許可することを特徴とするサーバシステム。
13. 請求項１乃至１２のいずれかにおいて、
    前記第１のゲーム処理のゲームは、複数のゲームステージ又は複数のゲームシーンにより構成され、
    前記制御処理部は、
    前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第２のゲーム処理による前記サーバ管理情報の更新処理を、前記複数のゲームステージの各ゲームステージの終了後又は前記複数のゲームシーンの各ゲームシーンの終了後に許可することを特徴とするサーバシステム。
14. 請求項１乃至１３のいずれかにおいて、
    前記制御処理部は、
    前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第１のゲーム処理及び前記第２のゲーム処理の少なくとも一方のゲーム処理での画像表示又は音出力を変更する処理を、前記競合時処理として行うことを特徴とするサーバシステム。
15. 請求項１４において、
    前記制御処理部は、
    前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第１のゲーム処理における音出力のレベルを小さくする処理を行うことを特徴とするサーバシステム。
16. 請求項１乃至１５のいずれかにおいて、
    前記制御処理部は、
    前記第１のゲーム処理の実行中に前記第２のゲーム処理の実行要求が検出された場合に、前記第１のゲーム処理のゲーム画面に、前記第２のゲーム処理のゲーム画面を表示するための処理を行うことを特徴とするサーバシステム。
17. 請求項１乃至１６のいずれかにおいて、
    前記第１のゲーム処理と前記第２のゲーム処理は、同一ユーザがプレイするゲームのゲーム処理であることを特徴とするサーバシステム。
18. 請求項１７において、
    前記制御処理部は、
    前記第１のゲーム処理と前記第２のゲーム処理とが、同一ユーザがプレイするゲームのゲーム処理であることを、ユーザがプレイする端末装置からのユーザ識別情報に基づいて判断することを特徴とするサーバシステム。
19. 請求項１乃至１８のいずれかにおいて、
    前記記憶部は、
    前記サーバ管理情報として、ゲームパラメータ情報、ゲームアイテム情報、及びゲーム成績情報の少なくとも１つの情報を記憶することを特徴とするサーバシステム。
20. 請求項１乃至１９のいずれかにおいて、
    前記第１のゲーム処理は、ユーザの操作情報に基づいてゲーム処理が行われ、ゲームを構成する複数のゲームステージ又は複数のゲームシーンの各ゲームステージ毎又は各ゲームシーン毎に、前記サーバ管理情報の更新処理が行われるゲーム処理であり、
    前記第２のゲーム処理は、ユーザの操作情報の入力毎に、前記サーバ管理情報の更新処理が行われるゲーム処理であることを特徴とするサーバシステム。
21. ネットワークを介して情報を受信する処理を行う受信処理部と、
    前記ネットワークを介して情報を送信する処理を行う送信処理部と、
    ゲーム処理の制御処理を行う制御処理部と、
    前記ゲーム処理の更新対象となる情報を、サーバ管理情報として記憶する記憶部として、
    コンピュータを機能させ、
    前記制御処理部は、
    第１のゲーム処理の実行中に、前記第１のゲーム処理と同じ前記サーバ管理情報を更新対象とする第２のゲーム処理の実行要求が検出された場合に、ゲーム処理の競合時用処理を行うことを特徴とするプログラム。
22. コンピュータ読み取り可能な情報記憶媒体であって、請求項２１に記載のプログラムを記憶したことを特徴とする情報記憶媒体。

Images