JP5430842B2 - サーバシステム及びプログラム - Google Patents

Description

本発明は、サーバシステム及びプログラムに関する。

近年、インターネットなどのネットワークを利用したゲームが普及しつつある。このネットワークゲームによれば、プレーヤは、不特定多数のプレーヤとマルチプレーヤゲームを楽しむことができるため、ゲームとしての人気が高い。

ところで、このようなネットワークゲームでは、サーバシステムの管理・運営が必要になる。このような管理・運営の費用を、ゲームソフトの売り上げの中から補填する手法も考えられるが、この手法では、ネットワークゲームの利用率が高くなった場合に、管理・運営の採算を取ることが難しいという問題がある。

また、サーバシステムの管理・運営費用を補填するための課金方式として、ネットワークゲームの通信時間や通信データ量に応じて課金を行う方式が考えられる。

しかしながら、この課金方式では、ゲーム装置とサーバシステムを常時接続状態にして通信時間や通信データ量を計測する必要があり、サーバシステムの処理負荷が重くなってしまうという課題がある。なおゲーム装置における課金方式の従来例としては例えば特許文献１に開示される技術などがある。
特開２００３−１５０８０８号公報

本発明は、以上のような考察に基づきなされており、本発明の幾つかの態様によれば、処理負荷の軽い課金処理の実現が可能なサーバシステム、ゲーム装置、プログラム及び情報記憶媒体を提供できる。

本発明は、ゲーム装置と通信接続されるサーバシステムであって、ゲームデータを記憶するゲームデータ記憶部と、前記ゲーム装置でプレイするプレーヤのユーザデータを、前記ゲームデータ記憶部から読み出す読み出し部と、前記ユーザデータを、プレーヤのゲームプレイ開始前に前記ゲーム装置に送信する送信部と、前記ゲーム装置でのプレーヤのゲーム結果データを、プレーヤのゲームプレイ終了後に前記ゲーム装置から受信する受信部と、受信された前記ゲーム結果データを前記ゲームデータ記憶部に書き込む書き込み部と、前記ユーザデータを前記ゲームデータ記憶部から読み出して前記ゲーム装置に送信するロード処理、及び、前記ゲーム結果データを前記ゲーム装置から受信して前記ゲームデータ記憶部に書き込むセーブ処理の少なくとも一方に対して、前記ゲーム装置でプレイするプレーヤへの課金処理を行う課金処理部とを含むサーバシステムに関係する。また本発明は、上記各部としてコンピュータを機能させるプログラム、又は該プログラムを記憶したコンピュータ読み取り可能な情報記憶媒体に関係する。

本発明では、ユーザデータがゲームデータ記憶部から読み出されて、プレーヤのゲームプレイ開始前にゲーム装置に送信される。またゲーム装置でのゲーム結果データが、ゲームプレイ終了後にゲーム装置から受信されて、ゲームデータ記憶部に書き込まれる。そして本発明では、ユーザデータを読み出して送信するロード処理、及び、ゲーム結果データを受信して書き込むセーブ処理の少なくとも一方に対して、プレーヤへの課金処理が行われる。このようにすれば、課金処理を簡素化でき、課金処理の負荷を軽減できる。また、ロード処理やセーブ処理などのネットワークサービスの利用に対して課金が行われるため、適正で公平な課金処理を実現できる。

また本発明に係るサーバシステム、プログラム及び情報記憶媒体では、前記送信部は、プレーヤの過去のゲーム成績情報、プレーヤが所属するチームの過去のゲーム成績情報、プレーヤのゲームプレイ履歴情報、成長情報、経験値情報、及び装備情報の少なくとも１つを含む前記ユーザデータを、前記ロード処理の際に前記ゲーム装置に対して送信してもよい。

このようなユーザデータのロード処理を行えば、過去のゲーム結果等が今回のゲームに反映されるようになるため、継続性の高い飽きの来にくいゲームを実現できる。そして、このようなネットワークを介したロード処理に対して課金処理を行えば、このようなゲームを実現するネットワークサービスの対価として、課金することができるため、適正な課金処理を実現できる。

また本発明に係るサーバシステム、プログラム及び情報記憶媒体では、前記受信部は、プレーヤの今回のゲームでのゲーム成績情報、プレーヤが所属するチームの今回のゲームでのゲーム成績情報、プレーヤの今回のゲームプレイ履歴情報、今回のゲームプレイで更新された成長情報、及び今回のゲームプレイで更新された経験値情報の少なくとも１つを含む前記ゲーム結果データを、前記セーブ処理の際に前記ゲーム装置から受信してもよい。

このようなゲーム結果データのセーブ処理を行えば、今回のゲーム結果を次回のゲーム等に反映できるようになるため、継続性の高い飽きの来にくいゲームを実現できる。そして、このようなネットワークを介したセーブ処理に対して課金処理を行えば、このようなゲームを実現するネットワークサービスの対価として、課金することができるため、適正な課金処理を実現できる。

また本発明に係るサーバシステム、プログラム及び情報記憶媒体では、前記課金処理部は、前記ロード処理に対しては課金処理を行わずに、前記セーブ処理に対して課金処理を行ってもよい。

このようにすれば、ロード処理に失敗が生じた場合にも、セーブ処理に対して課金処理を行うことができ、適正な課金処理を実現できる。

また本発明に係るサーバシステム、プログラム及び情報記憶媒体では、前記ゲーム装置は、前記サーバシステムから送信される前記ユーザデータの受信に失敗した場合には、プレーヤ用記憶装置に記憶されるユーザデータを用いて、ゲーム処理を行い、前記課金処理部は、前記ゲーム処理のゲーム結果データを受信して前記ゲームデータ記憶部に書き込むセーブ処理に対して、課金処理を行ってもよい。

このようにすれば、ユーザデータの受信に失敗した場合に、プレーヤ用記憶装置のユーザデータに基づいてゲーム処理が行われるため、プレーヤが長時間待たせれてしまう事態を防止できる。そしてこの場合にも、セーブ処理に対して課金処理が行われるため、適正な課金処理を実現できる。

また本発明に係るサーバシステム、プログラム及び情報記憶媒体では、前記課金処理部は、前記ロード処理の時間と前記セーブ処理の時間との差が、所定の時間差内であることを条件に、課金処理を行ってもよい。

このようにすれば、不適正な課金処理が行われる事態を防止できる。

また本発明に係るサーバシステム、プログラム及び情報記憶媒体では、前記課金処理部は、前記ロード処理の時間が取得されなかった場合にも、前記セーブ処理の時間が取得された場合には、課金処理を行ってもよい。

このようにすれば、ユーザデータの受信に失敗し、ロード処理の時間が取得できなかった場合にも、セーブ処理の時間に基づいて課金処理を行うことができるようになる。

また本発明に係るサーバシステム、プログラム及び情報記憶媒体では、前記送信部は、前記ロード処理の際に、前記ユーザデータと、前記ユーザデータに関連づけられた課金セッション識別情報とを、前記ゲーム装置に送信し、前記受信部は、前記セーブ処理の際に、前記ゲーム結果データと、前記ゲーム結果データに関連づけられた前記課金セッション識別情報とを、前記ゲーム装置から受信し、前記課金処理部は、受信した前記課金セッション識別情報を用いて、課金処理を行ってもよい。

また本発明は、ゲーム装置に通信接続されるサーバシステムであって、ゲームデータを記憶するゲームデータ記憶部と、前記ゲーム装置でプレイするプレーヤのユーザデータを、前記ゲームデータ記憶部から読み出す読み出し部と、前記ユーザデータを、プレーヤのゲームプレイ開始前に前記ゲーム装置に送信する送信部と、前記ゲーム装置でのプレーヤのゲーム結果データを、プレーヤのゲームプレイ終了後に前記ゲーム装置から受信する受信部と、受信された前記ゲーム結果データを前記ゲームデータ記憶部に書き込む書き込み部と、前記ゲーム装置でプレイするプレーヤへの課金処理を行う課金処理部とを含み、前記送信部は、前記ユーザデータを前記ゲームデータ記憶部から読み出して前記ゲーム装置に送信するロード処理の際に、前記ユーザデータと、前記ユーザデータに関連づけられた課金セッション識別情報とを、前記ゲーム装置に送信し、前記受信部は、前記ゲーム結果データを前記ゲーム装置から受信して前記ゲームデータ記憶部に書き込むセーブ処理の際に、前記ゲーム結果データと、前記ゲーム結果データに関連づけられた前記課金セッション識別情報とを、前記ゲーム装置から受信し、前記課金処理部は、受信した前記課金セッション識別情報を用いて、前記ゲーム装置でプレイするプレーヤへの課金処理を行うサーバシステムに関係する。また本発明は、上記各部としてコンピュータを機能させるプログラム、又は該プログラムを記憶したコンピュータ読み取り可能な情報記憶媒体に関係する。

本発明では、ユーザデータのロード処理の際に、ユーザデータと、それに関連づけられた課金セッション識別情報がゲーム装置に送信される。またゲーム結果データのセーブ処理の際には、ゲーム結果データと、それに関連づけられた上記の課金セッション識別情報が、受信される。そして本発明では、この課金セッション識別情報を用いて課金処理が行われる。従って、この課金セッション識別情報により課金セッションを特定し、特定された課金セッションに対して課金処理を行うことが可能になり、課金処理の負荷を軽減できる。

また本発明に係るサーバシステム、プログラム及び情報記憶媒体では、前記ゲーム装置は、前記サーバシステムから送信される前記課金セッション識別情報の受信に失敗した場合には、前記セーブ処理の際に、前記ゲーム結果データに関連づけて仮課金セッション識別情報を前記サーバシステムに送信し、前記課金処理部は、前記仮課金セッション識別情報を受信した場合には、課金開始と課金終了が同時に行われたと見なして、新たな課金セッション識別情報を生成し、生成された新たな課金セッション識別情報に基づいて、課金処理を行ってもよい。

このようにすれば、ゲーム装置がユーザデータの受信に失敗し、仮課金セッション識別情報が発行された場合にも、正常に課金セッションを終了して、課金処理を実現できるようになる。

また本発明に係るサーバシステム、プログラム及び情報記憶媒体では、前記課金処理部は、前記ゲーム装置でプレイするプレーヤへの課金のための課金データとして、前記課金セッション識別情報と、前記課金セッション識別情報に関連づけられた課金情報とを含む課金セッションデータを作成してもよい。

このような課金セッションデータを作成すれば、課金セッション識別情報と課金情報を用いた効率的な課金を実現できる。

また本発明に係るサーバシステム、プログラム及び情報記憶媒体では、前記課金処理部は、前記ロード処理の時間及び前記セーブ処理の時間の少なくとも一方を含む前記課金情報を、前記課金セッション識別情報に関連づけて、前記課金セッションデータを作成してもよい。

このようなセーブ処理の時間やロード処理の時間を課金セッションデータに含ませれば、どの時間に発生した課金なのかを明確化できる。

また本発明に係るサーバシステム、プログラム及び情報記憶媒体では、前記課金処理部は、前記ゲーム装置でプレイするプレーヤへの課金のための課金データとして、前記ゲーム装置の識別情報と、前記ロード処理及び前記セーブ処理の少なくとも一方による課金回数情報とを含む課金集計データを作成してもよい。

このようなゲーム装置識別情報と課金回数情報を課金集計データに含ませれば、課金額を簡素に特定できる課金データを作成できる。

また本発明に係るサーバシステム、プログラム及び情報記憶媒体では、前記課金処理部は、前記ロード処理及び前記セーブ処理の少なくとも一方の回数である処理回数が多くなるほど、プレーヤへの課金が高くなる課金処理を行ってもよい。

このようにすれば、ネットワークサービスの利用回数が多いほど、課金額が高くなり、公平な課金を実現できると共に、課金処理の負荷も軽減できる。

また本発明に係るサーバシステム、プログラム及び情報記憶媒体では、前記課金処理部は、前記処理回数に対する課金レートを可変に変更する課金レート変更部を含んでもよい（課金レート変更部としてコンピュータを機能させてもよい）。

このようにすれば、課金レートを変更することで、様々な事情・要望に応えることが可能になる。

また本発明に係るサーバシステム、プログラム及び情報記憶媒体では、前記課金処理部は、前記ゲーム装置においてプレーヤがゲームプレイした時間帯を特定し、特定された時間帯に応じて、前記課金レートを変更してもよい。

このようにすれば、課金についてのプレーヤの負担の軽減やネットワーク負荷の軽減等を実現できる。

また本発明に係るサーバシステム、プログラム及び情報記憶媒体では、前記送信部は、リプレイデータ又はプレイ履歴データを、前記ゲーム装置に送信し、前記課金処理部は、前記リプレイデータ又は前記プレイ履歴データを前記ゲーム装置に送信するロード処理に対して、課金処理を行ってもよい。

このようにすれば、ネットワークを介したリプレイデータやプレイ履歴データのロード処理というネットワークサービスに対して、課金することができ、適正な課金処理を実現できる。

また本発明に係るサーバシステム、プログラム及び情報記憶媒体では、前記送信部は、前記ゲーム装置に対して既にロードされているリプレイデータ又はプレイ履歴データ以外の未ロードのリプレイデータ又は未ロードのプレイ履歴データを、前記ゲーム装置に送信し、前記課金処理部は、前記未ロードのリプレイデータ又は前記未ロードのプレイ履歴データを前記ゲーム装置に送信するロード処理に対して、課金処理を行ってもよい。

このようにすれば、未ロードのリプレイデータやプレイ履歴データのロード処理が可能になり、このようなロード処理に対して課金処理を行うことが可能になる。

また本発明に係るサーバシステム、プログラム及び情報記憶媒体では、前記送信部は、ランキングデータを、前記ゲーム装置に送信し、前記課金処理部は、前記ランキングデータを、前記ゲーム装置に送信するロード処理に対して、課金処理を行ってもよい。

このようにすれば、ネットワークを介したランキングデータのロード処理というネットワークサービスに対して、課金することができ、適正な課金処理を実現できる。

また本発明は、上記のいずれかに記載のサーバシステムと通信接続されるゲーム装置であって、前記ユーザデータを前記サーバシステムから受信する受信部と、受信した前記ユーザデータを用いてゲーム処理を行うゲーム処理部と、前記ゲーム処理での前記ゲーム結果データを前記サーバシステムに送信する送信部と、プレーヤ用記憶装置とのインターフェースを行うインターフェース部とを含むゲーム装置に関係する。

また本発明では、前記ゲーム処理部は、前記サーバシステムから送信される前記ユーザデータの受信に失敗した場合には、前記プレーヤ用記憶装置に記憶されるユーザデータを用いてゲーム処理を行ってもよい。

このようにすれば、受信が失敗した場合に、プレーヤが長時間待たされてしまう事態を防止できる。

また本発明では、前記送信部は、前記サーバシステムへの前記ゲーム結果データの送信に失敗した場合には、前記ゲーム結果データをスタックし、スタックされた前記ゲーム結果データを、バックグラウンド通信により前記サーバシステムに送信してもよい。

このようにすれば、バックグラウンド通信期間を有効活用して、ゲーム結果データをサーバシステムに送信できるようになる。

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

１．システム構成例
図１に本実施形態のシステム構成例を示す。このシステムは、複数のゲーム装置２０-1、２０-2・・・２０-nと、これらのゲーム装置２０-1、２０-2・・・２０-nにネットワーク１２を介して通信接続されるサーバシステム１０を含む。

ネットワーク１２（通信回線）はデータ授受が可能な通信路である。ネットワーク１２は、例えばインターネットを利用した通信路であり、直接接続のための専用線（専用ケーブル）やイーサネット（登録商標）等によるＬＡＮの他、電話通信網やケーブル網等の通信網を含むことができる。また通信方法については有線／無線を問わない。

サーバシステム１０（サーバ装置）は、各種処理を実行する処理部、各種プログラムやデータを記憶する記憶部、ネットワーク１２を介したデータの送受信のための通信部等を有する公知のコンピュータシステムにより構成できる。別の言い方をすればサーバシステム１０は、１又は複数のサーバ（処理サーバ）や、１又は複数のデータベース（データサーバ）を含むことができる。このサーバシステム１０は、例えばゲームソフトの制作メーカやゲーム装置の製造メーカが提供（設置）し、システムの全体制御や、ネットワークゲームの管理等を行う。

ゲーム装置２０-1〜２０-nは、プレーヤがゲームプレイを行うための装置（端末）であり、各種処理を実行する処理部、各種プログラムやデータを記憶する記憶部、プレーヤが操作入力を行うための操作部、ゲーム画面等を表示するための表示部、ゲーム音等を出力する音出力部、ネットワーク１２を介したデータの送受信のための通信部等を有する公知のコンピュータシステムにより構成できる。このゲーム装置２０-1〜２０-nは、例えば、家庭用の目的で販売される家庭用ゲーム装置である。具体的には、家庭用のテレビのモニタに、有線又は無線で接続して、ゲーム装置で生成されたゲーム画像をテレビのモニタに表示して、ゲームを楽しむ。なおゲーム装置２０-1〜２０-nは、例えばプレーヤが外出先に持ち歩いてゲームプレイすることができる携帯型ゲーム装置であってもよい。この携帯型ゲーム装置では、ＬＣＤ等の小型の表示部にゲーム画像が表示される。携帯型ゲーム装置の場合には、アクセスポイントまでは無線で通信接続し、アクセスポイントからサーバシステム１０には例えば有線で通信接続すればよい。

図２に図１のシステムのハードウェア構成例を示す。図２において、ゲーム装置２０-1〜２０-nは、ゲームプログラムが格納されるメモリ（ＲＯＭ）やゲーム処理を行うプロセッサ等により実現される。

サーバシステム１０は、認証サーバ３０、ゲームサーバ４０、ゲームデータベース４２（ゲームデータサーバ）、課金サーバ５０、課金データベース５２（課金データサーバ）、携帯電話用ウェブサーバ６０、携帯電話用データベース６２（携帯データサーバ）、バックオフィスサーバ７０、バックオフィス端末７２を含むことができる。なおサーバシステム１０は図２の構成に限定されず、その一部の構成要素（例えばバックオフィスサーバ、バックオフィス端末、携帯電話用ウェブサーバ、携帯電話用データベース等）を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。

認証サーバ３０は、ゲーム装置２０-1〜２０-nの認証処理を行う。この認証処理によって、ゲーム装置２０-1〜２０-n等が正規な装置であることが確認される。

ゲームサーバ４０は、データのロード処理やセーブ処理などのネットワークゲームに必要な種々のゲーム処理を行う。ゲームデータベース４２はネットワークゲームに必要な種々のゲームデータを記憶する。認証サーバ３０により認証されたゲーム装置は、ゲームサーバ４０から、ネットワークゲームに必要な種々のサービスを受けることが可能になる。

課金サーバ５０はネットワークゲームについての様々な課金処理を行う。課金データベース５２は、課金サーバ５０により生成された課金データを記憶する。

携帯電話用ウェブサーバ６０は携帯電話６４（広義には携帯型情報端末）を利用した様々なサービス（例えばアイテム購入）を実現するためのサーバであり、携帯電話用データベース６２はそのサービスのためのデータを記憶する。バックオフィスサーバ７０は、サーバの管理・運営の事務や営業のためのサーバであり、バックオフィス端末７２は事務や営業に使用される端末である。なお携帯電話用のウェブサービスを、ゲーム装置２０-1〜２０-nに対して直接提供するようにしてもよい。例えばゲーム装置２０-1〜２０-nが携帯型ゲーム装置である場合には、外出先等でこのウェブサービスを受けることが可能になる。

２．サーバシステム
図３に本実施形態のサーバシステムの機能ブロック図の例を示す。なお図３の構成要素（各部）の一部を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。

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

操作部２３０は、システムの管理・運営者が種々の情報を入力するためのものである。記憶部２４０は、処理部２００や通信部２９６などのワーク領域となるもので、その機能はＲＡＭなどにより実現できる。情報記憶媒体２８０（コンピュータにより読み取り可能な媒体）は、プログラムやデータなどを格納するものであり、その機能は、光ディスク（ＣＤ、ＤＶＤ）、ＨＤＤ（ハードディスクドライブ）、或いはメモリ（ＲＯＭ等）などにより実現できる。表示部２９０は、システムの管理・運営者に対して種々の情報を表示するためのものである。通信部２９６は、有線や無線のネットワーク１２を介して外部のゲーム装置や、外部の他のサーバとの通信を行うものであり、その機能は、通信用ＡＳＩＣ又は通信用プロセッサなどのハードウェアや、通信用ファームウェアにより実現できる。

処理部２００はゲーム処理部２１０と課金処理部２２０を含む。ゲーム処理部２１０は、種々のゲーム処理（ゲーム装置でのゲーム処理に必要な処理、サーバシステムのサービスのための処理）を行うものであり、例えば図２のゲームサーバ４０等により実現できる。課金処理部２２０は種々の課金処理（課金データの作成処理、保存処理、課金レートの変更処理等）を行うものであり、例えば図２の課金サーバ５０等により実現できる。

ゲーム処理部２１０は、受け付け部２１２、読み出し部２１３、送信部２１４、受信部２１５、書き込み部２１６を含む。なおこれらの構成要素の一部（例えば受け付け部）を省略する構成としてもよい。

受け付け部２１２は、ゲーム装置等のクライアントからの種々の処理のリクエストを受け付ける。本実施形態のサーバシステムでは、個々のクライアントの内部がどのような状態にあるのかを問わないようになっている。即ち、受け付け部２１２は、クライアントからの処理のリクエスト（リクエストデータ）が到着するのを待ち、到着すると、そのリクエストで指定される処理を実行する。そして処理の終了後、次の処理のリクエストが到着するのを待つ状態に戻る。こうすることで、サーバシステムとクライアントとの間で常時通信（ポーリング）を行わなくて済むようになるため、通信処理の負荷を大幅に軽減できる。

読み出し部２１３は、記憶部２４０からのデータの読み出し処理を行う。例えばゲーム装置でプレイするプレーヤのユーザデータを、ゲームデータ記憶部２４２から読み出す処理を行う。具体的には読み出し部２１３は、ゲーム開始を通知するリクエストを、クライアントであるゲーム装置が送信し、受け付け部２１２がこのリクエストを受け付けると、ユーザデータ記憶部２４４に記憶されるユーザデータを読み出す。

ここでユーザデータは、ゲーム装置においてゲーム処理（ゲーム進行処理、ゲーム成績演算処理、画像生成処理、音生成処理）を行うために予めゲーム装置側にロードしておく必要があるデータであり、ユーザであるプレーヤに固有のデータ（カスタマイズデータ）などである。このユーザデータは、プレーヤの過去のゲーム成績情報（過去の勝利数、敗北数等）、プレーヤが所属するチームの過去のゲーム成績情報（チームポイント等）、プレーヤのゲームプレイ履歴情報（ゲームのプレイ時間、ゲームのプレイ回数等）、成長情報（キャラクタの過去の成長情報、レベル、段位等）、経験値情報（キャラクタの過去の経験値情報、経験ポイント等）、及び装備情報（キャラクタの装備情報、エンブレム、称号等）の少なくとも１つを含むことができる。またプレーヤの識別情報（ユーザＩＤ、ユーザ名等）、プレーヤが所属するチームの識別情報（チームＩＤ、チーム名等）の少なくとも１つを含んでもよい。

送信部２１４はデータの送信処理を行う。例えば、ユーザデータをプレーヤのゲームプレイ開始前にゲーム装置に送信する処理を行う。具体的には、読み出し部２１３によりユーザデータ記憶部２４４から読み出されたユーザデータの送信を、通信部２９６に対して指示し、これによりネットワークを介してゲーム装置にユーザデータを送信する。

受信部２１５はデータの受信処理を行う。例えばゲーム装置でのプレーヤのゲーム結果データを、プレーヤのゲームプレイ終了後にゲーム装置から受信する処理を行う。具体的には、ゲーム装置でのゲームが終了し（ゲームオーバーになり）、ゲーム装置がリクエストデータとしてゲーム結果データを送信した場合に、送信されたゲーム結果データをネットワーク及び通信部２９６を介して受信するための処理を行う。

なおゲーム結果データは、ゲーム装置での今回のゲームプレイの結果等をサーバシステムに通知するためのデータである。このゲーム結果データは、プレーヤの今回のゲームでのゲーム成績情報（勝利数、敗北数、ユーザポイント、クリア時間等）、プレーヤが所属するチームの今回のゲームでのゲーム成績情報（チームポイント等）、プレーヤの今回のゲームプレイ履歴情報（ゲームのプレイ時間、ゲームのプレイ回数等）、、今回のゲームプレイで更新（獲得）された成長情報（今回のゲームで更新されたキャラクタのレベル、段位等）、及び今回のゲームプレイで更新（獲得）された経験値情報（今回のゲームで更新されたキャラクタの経験値等）の少なくとも１つを含むことができる。またプレーヤの識別情報（ユーザＩＤ等）、プレーヤが所属するチームの識別情報（チームＩＤ等）、キャラクタの識別情報（キャラクタＤＢＩＤ等）の少なくとも１つを含んでもよい。

書き込み部２１６は記憶部２４０へのデータの書き込み処理を行う。例えば、受信されたゲーム結果データをゲームデータ記憶部２４２に書き込む処理を行う。具体的には、ゲーム終了によりゲーム装置がゲーム結果データ（個人データ）を送信し、受信部２１５がゲーム結果データを受信すると、受信されたゲーム結果データを、ゲーム結果データ記憶部２４６（個人データ記憶部）に書き込む。

課金処理部２２０は、ユーザデータをゲームデータ記憶部２４２（ユーザデータ記憶部２４４）から読み出してゲーム装置に送信するロード処理（送信処理）、及び、ゲーム結果データをゲーム装置から受信してゲームデータ記憶部２４２（ゲーム結果データ記憶部２４６）に書き込むセーブ処理（受信処理）の少なくとも一方に対して、課金処理を行う。例えばロード処理及びセーブ処理の少なくとも一方の処理回数（課金開始回数、課金終了回数）が多くなるほど、課金が高くなるように、課金処理を行う。

例えば課金処理部２２０は、ロード処理に対しては課金処理を行わずに、セーブ処理に対してのみ課金処理を行うようにしてもよい。具体的にはゲーム装置は、サーバシステムから送信されるユーザデータの受信に失敗した場合には、プレーヤ用記憶装置（ＩＣカード、メモリカード等）に記憶されるユーザデータを用いて、ゲーム処理を行う。この場合に課金処理部２２０は、このようなプレーヤ用記憶装置（携帯型記憶装置）のユーザデータにより行われたゲーム処理のゲーム結果データを受信する。そして、このゲーム結果データをゲームデータ記憶部２４２に書き込むセーブ処理に対してだけ課金処理を行う。また課金処理部２２０は、ロード処理の時間（課金開始時間）とセーブ処理の時間（課金終了時間）との差が、所定の時間差内である場合に課金処理を行う。そしてロード処理の時間（時刻）が取得されなかった場合にも、セーブ処理の時間（時刻）が取得された場合には、課金処理を行うようにする。

また送信部２１４は、ロード処理の際にユーザデータと課金セッションＩＤ（識別情報、IDentification)をゲーム装置に送信する。一方、受信部２１５は、セーブ処理の際にゲーム結果データと課金セッションＩＤをゲーム装置から受信する。この場合に、課金処理部２２０は、受信した課金セッションＩＤを用いて課金処理を行う。例えば、生成した課金セッションＩＤの個数に応じて高くなる課金処理を行う。またゲーム装置がサーバシステムからの課金セッションＩＤの受信に失敗して仮課金セッションＩＤを送信した場合には、課金処理部２２０は、新たな課金セッションＩＤを生成する。そして生成された新たな課金セッションＩＤに基づいて課金処理を行う。即ち課金開始（ロード）と課金終了（セーブ）が同時に行われたと見なして、課金処理を行う。なお課金セッションＩＤは課金セッションＩＤ記憶部２５８に保存される。

課金処理部２２０は課金データ作成部２２２と課金レート変更部２２４を含む。課金データ作成部２２２は、課金データの作成処理を行う。

具体的には課金データ作成部２２２は、ゲーム装置でゲームプレイするプレーヤへの課金のための課金データとして課金セッションデータを作成する。そして課金データ記憶部２６０の課金セッションデータ記憶部２６２に保存する。この課金セッションデータは、課金セッションＩＤと、課金セッションＩＤに関連づけられた課金情報を含む。そして課金セッションＩＤに関連づけられる課金情報は、例えばロード処理の時間（課金開始時間）及びセーブ処理の時間（課金終了時間）の少なくとも一方を含むことができる。また課金情報は、ゲーム装置のＩＤ、及びゲーム装置でプレーヤがプレイしたゲームの識別情報（ゲームＩＤ、ゲームサブＩＤ）の少なくとも１つを含むことができる。

また課金データ作成部２２２は、プレーヤへの課金のための課金データとして課金集計データを作成する。そして課金データ記憶部２６０の課金集計データ記憶部２６４に保存する。この課金集計データは、ゲーム装置の識別情報と、ロード処理及びセーブ処理の少なくとも一方による課金回数情報（課金開始回数、課金終了回数）を含むことができる。

課金レート変更部２２４は課金レートの変更処理を行う。具体的には、ロード処理及びセーブ処理の少なくとも一方である処理回数（課金開始回数、課金終了回数）に対する課金レート（処理回数に対する乗算係数）を可変に変更する。例えば課金レート変更部２２４は、ゲーム装置においてプレーヤがゲームプレイした時間帯を特定し、特定された時間帯（時間帯情報、時間情報）に基づいて、課金レートを変更する。なお、課金レートは、課金レート記憶部２７０に保存される。

送信部２１４は、リプレイデータ記憶部２５２、プレイ履歴データ記憶部２５３に記憶されるリプレイデータ又はプレイ履歴データ（ゴーストデータ）を、ゲーム装置に送信する。そして課金処理部２２０は、リプレイデータ又はプレイ履歴データをゲーム装置に送信するロード処理に対して、課金処理を行うことができる。この場合に、ゲーム装置にロードされていない未ロード（最新）のリプレイデータ又はプレイ履歴データをゲーム装置に送信するロード処理に対して、課金処理を行ってもよい。

更に送信部２１４は、ランキングデータを、ゲーム装置に送信する。そして課金処理部２２０は、ランキングデータを、ゲーム装置に送信するロード処理に対して、課金処理を行ってもよい。なお、ゲームプログラムのパッチデータはパッチデータ記憶部２５１に保存される。

３．ゲーム装置
図４に本実施形態のゲーム装置の機能ブロック図の例を示す。なお図４の構成要素（各部）の一部を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。

操作部１３０は、プレーヤが操作データを入力するためのものであり、その機能は、方向キー、操作ボタン或いはタッチパネル型ディスプレイなどにより実現できる。記憶部１４０は、処理部１００や通信部１９６などのワーク領域となるもので、その機能はＲＡＭ（ＤＲＡＭ、ＶＲＡＭ）などにより実現できる。情報記憶媒体１８０（コンピュータにより読み取り可能な媒体）は、プログラムやデータなどを格納するものであり、その機能は、光ディスク、ＨＤＤ、或いはメモリなどにより実現できる。処理部１００は、情報記憶媒体１８０に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。

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

Ｉ／Ｆ（インターフェース）部１９３は、プレーヤが所持するＩＣカード１９４（広義にはプレーヤ用記憶装置）とのインターフェースを行う。具体的にはＩ／Ｆ部１９３（カードリーダ・ライタ）は、ＩＣカード１９４（メモリカード）からのデータの書き込みやデータの読み出しなどのアクセス処理を行う。このＩＣカード１９４は、例えば着脱自在となっており、プレーヤの個人的なデータが記憶される。

なお、本実施形態のプレーヤ用記憶装置はＩＣカード１９４に限定されず、データをリード、ライトできる種々の記憶装置を使用できる。例えばプレーヤ用記憶装置として携帯電話等の携帯通信端末を用い、その無線機能等を利用してデータのリード、ライトを行ってもよい。

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

処理部１００（プロセッサ）は、操作部１３０からの操作データやプログラムなどに基づいて、ゲーム処理、画像生成処理、或いは音生成処理などを行う。処理部１００は記憶部１４０をワーク領域として各種処理を行う。この処理部１００の機能は、各種プロセッサ（ＣＰＵ、ＧＰＵ等）、ＡＳＩＣ（ゲートアレイ等）などのハードウェアや、プログラムにより実現できる。

処理部１００は、ゲーム処理部１０２、受信部１０４、送信部１０６、画像生成部１２０、音生成部１２８を含むことができる。なおこれらの一部の構成要素を省略する構成としてもよい。

ゲーム処理部１０２は、プレーヤがゲームプレイするためのゲーム処理（ゲーム演算処理）を行う。ここでゲーム処理としては、ゲーム開始条件が満たされた場合にゲームを開始する処理、ゲームを進行させる処理、ゲーム結果を演算する処理、或いはゲーム終了条件が満たされた場合にゲームを終了する処理などがある。

受信部１０４は、ユーザデータをサーバシステムから受信する処理を行う。そしてゲーム処理部１０２は、受信したユーザデータを用いてゲーム処理を行う。即ちユーザデータを反映したゲーム画像を生成したり、ゲーム音を生成するための処理を行う。そして、受信したユーザデータはユーザデータ記憶部１４４に記憶される。

送信部１０６は、ゲーム結果データをサーバシステムに送信するための処理を行う。具体的には、ゲーム処理部１０２でのゲーム処理の結果により得られたゲーム結果データを、サーバシステムに送信する。

画像生成部１２０は、ゲーム処理部１０２で行われる種々のゲーム処理の結果に基づいて描画処理を行い、これによりゲーム画像を生成し、描画バッファ１７０に書き込んで、表示部１９０に出力する。この場合に、表示されるゲーム画像は、３次元画像であってもよいし、２次元画像であってもよい。

音生成部１２８は、ゲーム処理部１０２で行われるゲーム処理の結果に基づいて音処理を行い、ＢＧＭ、効果音、又は音声などのゲーム音を生成し、音出力部１９２に出力する。なおゲームデータ記憶部１４２の各記憶部は、ユーザデータ、ゲーム結果データ、ランキングデータ、パッチデータ、リプレイデータ、プレイ履歴データ、課金セッションＩＤを記憶する。

そして本実施形態ではゲーム処理部１０２は、サーバシステムから送信されるユーザデータの受信に失敗した場合には、ＩＣカード１９４（プレーヤ用記憶装置）に記憶されるユーザデータを用いてゲーム処理を行う。一方、送信部１０６は、サーバシステムへのゲーム結果データの送信に失敗した場合には、ゲーム結果データを例えばゲーム結果データ記憶部１４６にスタックし、スタックされたゲーム結果データを、バックグラウンド通信によりサーバシステムに送信する。

４．本実施形態の手法
４．１ 課金処理
次に、図５（Ａ）〜図５（Ｅ）を用いて本実施形態の課金処理について説明する。ゲーム装置２０でのゲームが開始すると、図５（Ａ）に示すようにゲーム装置２０は、ユーザデータのロード処理のリクエストをサーバシステム１０に送信して、ゲームの開始をサーバシステム１０に通知する。即ちプレーヤがゲーム装置２０の電源をオンにして、ゲームプレイを開始すると、ゲーム装置２０からサーバシステム１０にリクエストが送信される。図６（Ａ）に示すように、このリクエストのデータは、ゲーム装置（基板）ＩＤ、カードＩＤ、キャラクタＤＢＩＤなどを含む。ゲーム装置ＩＤは、リクエストを送信したゲーム装置のＩＤである。カードＩＤは、ＩＣカード１９４に記録されたユニークなＩＤである。キャラクタＤＢＩＤ（キャラクタデータベースのＩＤ）は、ゲームデータ記憶部２４２（ゲームデータベース）上のキャラクタデータのインデックスである。

サーバシステム１０は、ゲーム装置ＩＤに基づいて、受信したリクエストが、どのゲーム装置からのリクエストなのかを特定できる。またキャラクタＤＢＩＤに基づいて、リクエストによりゲーム装置２０に送信すべきユーザデータを特定できる。このキャラクタＤＢＩＤは、プレーヤやプレーヤのＩＣカード１９４が登録された時に作成され、プレーヤとその使用キャラクタ（ファイター）を特定するためのＩＤである。

このようにゲーム開始が通知されると、図５（Ｂ）に示すように、サーバシステム１０（ゲームサーバ、ゲーム処理部）は、ゲームデータ記憶部２４２からユーザデータを読み出して、リクエストに対するレスポンスデータであるユーザデータを、ゲーム装置２０に送信するロード処理を行う。

図６（Ｂ）に示すようにユーザデータ（レスポンスデータ）は、例えばユーザＩＤ、ユーザ名、チームＩＤ、チーム名、コメント、段位ＩＤ、経験値、アイテム装備情報、チームエンブレムＩＤ、称号ＩＤ、対人戦勝利数、対人戦敗北数、携帯会員判定フラグ、チームポイントを含む。またユーザデータには課金セッションＩＤが関連づけられている。このユーザデータ、課金セッションＩＤは、図４のゲーム装置２０のユーザデータ記憶部１４４、課金セッションＩＤ記憶部１５８に保存される。

図６（Ｂ）のユーザデータにおいて、ユーザＩＤ、ユーザ名は、ユーザであるプレーヤのＩＤ、プレーヤが入力した名前である。チームＩＤ、チーム名は、プレーヤが所属するチームのＩＤ、チームの名前である。コメントは、プレーヤが設定したコメントである。段位ＩＤは、プレーヤのキャラクタの段位のＩＤである。経験値は、そのキャラクタが既に獲得している経験値であり、段位の算定用に使用される。アイテム装備情報は、キャラクタが装備しているアイテム（例えば手袋、帽子、ペンダント等）の装備情報である。このアイテムは図２の携帯電話６４等を用いたウェブサービスより購入できる。チームエンブレムＩＤはプレーヤが所属するチームのエンブレムのＩＤである。称号ＩＤは例えば「強者」「四天王」等のキャラクタの称号のＩＤであり、この称号も携帯電話６４を用いたウェブサービス等により購入できる。対人戦勝利数、対人戦敗北数は、対人戦の累積の勝利数、敗北数である。携帯会員判定フラグは、携帯電話６４を用いたウェブサービスの会員か否かを判定するためのフラグである。チームポイントは、プレーヤが所属するチームが既に獲得しているポイントである。

課金セッションＩＤは、１回のロード処理と１回のセーブ処理を一組とした課金セッションを識別するためのＩＤである。このように本実施形態では、ユーザデータのロード処理の際に、ユーザデータ（プレーヤデータ）と、ユーザデータに関連づけられた課金セッションＩＤとが、サーバシステム１０からゲーム装置２０に送信される。

このようなユーザデータのロード処理の後に、図５（Ｃ）に示すようにゲーム装置２０でのゲーム処理が行われ、プレーヤが例えば格闘ゲーム、レースゲーム等のゲームプレイを開始する。この時、図５（Ｂ）でロードされたユーザデータを用いてゲーム処理が行われる。例えばゲーム画面にユーザ名やチーム名が表示されたり、キャラクタの段位、経験値が、ユーザデータの段位ＩＤ、経験値に基づき設定される。またゲーム画面に登場するキャラクタには、アイテム装備情報で設定されるアイテムが装備され、チームエンブレムや称号も付与される。更に、ユーザデータの対人戦勝利数、対人戦敗北数、チームポイントが、プレーヤのゲームプレイにより更新されるようになる。

ゲーム装置２０でのゲームが終了すると、図５（Ｄ）に示すようにゲーム装置２０がゲーム結果データのセーブ処理のリクエストを送信して、ゲームの終了をサーバシステム１０に通知する。即ち、プレーヤの連勝が止まり、敗北するなどしてゲームオーバーになると、ゲーム結果データ（リクエストデータ）がゲーム装置２０からサーバシステム１０に送信される。図７（Ａ）に示すように、このゲーム結果データである個人データは、ゲーム装置ＩＤ、ユーザＩＤ、チームＩＤ、キャラクタＤＢＩＤ、対人戦勝利数、対人戦敗北数、対ゴースト戦勝利数、対ゴースト戦敗北数、対ＣＰＵ戦勝利数、対ＣＰＵ戦敗北数、段位ＩＤ、経験値、プレイタイム、ユーザポイント、チームポイント、ＣＰＵ戦クリア時間などを含む。またゲーム結果データである個人データには、課金セッションＩＤが関連づけられている。このゲーム結果データ、課金セッションＩＤは、図３のサーバシステム１０のゲーム結果データ記憶部２４６、課金セッションＩＤ記憶部２５８に保存される。

図７（Ａ）の個人データにおいて、対人戦、対ゴースト戦、対ＣＰＵ戦の勝利数は、今回の対人戦、ゴースト戦、ＣＰＵ戦でプレーヤが達成した勝利数である。対人戦、対ゴースト戦、対ＣＰＵ戦の敗北数は、今回の対人戦、ゴースト戦、ＣＰＵ戦でプレーヤが喫した敗北数であり、通常は１か０になる。段位ＩＤは、今回のゲームプレイ結果を反映したキャラクタの段位のＩＤであり、経験値は、今回のゲームプレイで更新された経験値である。プレイタイムは今回のゲームプレイに費やした時間である。ユーザポイントは、今回のゲームプレイでプレーヤが獲得したポイントであり、チームポイントは、今回のゲームプレイでチームが獲得したポイントである。ＣＰＵ戦クリア時間は、今回のゲームプレイでＣＰＵ戦のクリアにかかった時間であり、クリアしていない場合には０になる。

課金セッションＩＤは、図５（Ｂ）のようにユーザデータに関連づけてサーバシステム１０からゲーム装置２０に送信されて、図４の課金セッションＩＤ記憶部１５８に保存されたＩＤである。このように本実施形態では、セーブ処理の際に、ゲーム結果データと、ゲーム結果データに関連づけられた課金セッションＩＤが、ゲーム装置２０からサーバシステム１０に送信される。

サーバシステム１０は、ゲーム結果データを受信すると、図５（Ｅ）に示すように処理結果（レスポンスデータ）のコードをゲーム装置２０に送信する。図７（Ｂ）に示すこの処理結果は、処理（ゲーム結果データの受信処理）の結果を示すコードである、ゲーム装置２０は、サーバシステム１０がゲーム結果データの受信に成功するまで、後述するバックグラウンド通信等によりゲーム結果データの送信を繰り返す。

そして本実施形態では図５（Ｅ）に示すように、図５（Ｂ）のロード処理、図５（Ｄ）のセーブ処理に対して課金処理を行う。例えばロード処理及びセーブ処理の両方に対して課金処理を行ったり、ロード処理及びセーブ処理の一方に対してのみ課金処理を行う。例えば、図５（Ｂ）でサーバシステム１０からゲーム装置２０に送信されて保存され、図５（Ｄ）でゲーム装置２０からサーバシステム１０に送信されて戻された課金セッションＩＤを用いて、課金処理を行う。即ちこの課金セッションＩＤにより課金セッションを特定し、特定された課金セッションに対して課金処理を行う。例えば課金セッションの回数が多くなるほど高くなる課金を、ゲーム装置２０でプレイするプレーヤに対して行う。

本実施形態の比較例の課金方式として、ネットワークゲームの通信時間や通信データに課金する方式がある。しかしながら、この方式では、通信時間等の計測処理やネットワークの接続処理の負荷が重くなると共に、課金処理の負荷も重くなる。

この点、本実施形態では、ロード処理やセーブ処理に対して課金処理を行うため、ネットワークの利用状況に応じた公平な課金を実現できる。即ち、ネットワークを介してユーザデータをロードしたりゲーム結果データをセーブするネットワークサービスに対して課金が行われるため、このようなネットワークサービスの利用回数が少ないプレーヤへの課金は少なくすることができ、公平な課金を実現できる。

また課金処理は、ロード処理（課金開始時間）やセーブ処理（課金終了時間）の回数をカウントするだけで済むため、課金処理の負荷を大幅に軽減できる。

また図５（Ａ）〜図５（Ｅ）では、サーバシステム１０は、クライアントであるゲーム装置２０からの処理のリクエストが到着するのを待つ。そしてリクエストが到着したら、リクエストで指定されたロード処理やセーブ処理などの処理を実行して、レスポンスをゲーム装置２０に返す。そして処理の終了後、次のリクエストが到着するのを待つ状態に戻る。従って、サーバシステム１０とゲーム装置２０との間で常時通信（ポーリング）を行わなくて済む。例えば、図５（Ａ）のゲーム開始前の期間や、図５（Ｃ）のようにゲーム装置２０においてゲーム処理を行っている期間では、サーバシステム１０とゲーム装置２０との間でデータの通信を行わなくて済むため、通信処理の負荷を大幅に軽減できる。

４．２ 受信の失敗
ネットワークを介した通信では、一方の装置がデータを送信しても、他方の装置がそのデータの受信に失敗する場合がある。例えばネットワークでのデータのトラフィック量が多い場合に、このような受信の失敗が頻繁に起こるおそれがある。

図８（Ｂ）では、ロード処理においてサーバシステム１０から送信されたデータの受信に、ゲーム装置２０が失敗している。このようにデータの受信に失敗した場合に、ゲーム装置２０がリクエスト処理を再度実行し、ユーザデータの受信に成功するまで通信を繰り返すと、図８（Ｃ）のゲーム処理の開始が遅れてしまう。従って、受信が成功するまでプレーヤのゲームプレイを待たせる結果になってしまい、スムーズなゲームプレイを実現できない。

そこで図８（Ｅ）では、図８（Ｂ）のロード処理に対しては課金処理を行わずに、図８（Ｄ）のセーブ処理に対してだけ課金処理を行っている。具体的にはゲーム装置２０は、図８（Ｂ）のようにユーザデータの受信に失敗した場合には、図８（Ｃ）に示すように、プレーヤが所持するＩＣカード１９４（プレーヤ用記憶装置）に記憶されるユーザデータを用いて、ゲーム処理を行う。例えばＩＣカード１９４には、ゲームプレイを行う毎にユーザデータ等が保存される。従ってＩＣカード１９４には、サーバシステム１０のゲームデータ記憶部２４２に記憶されるデータよりも古い更新日時のユーザデータが保存されている。そこでゲーム装置２０は、この古い更新日時のユーザデータを用いてゲーム処理を行う。この時、例えば今回のゲームの直前にプレーヤが、図２の携帯電話６４のウェブサービスを利用して装備等のアイテムを購入した場合には、今回のゲームプレイでは、このアイテムがキャラクタに装着されないことになる。しかしながら、それよりも前に購入したアイテムは装着されるため、ゲームプレイへの支障は少なく、その代わりにスムーズなゲームプレイを実現できるようになる。

一方、図８（Ｄ）のセーブ処理の際にサーバシステム１０がゲーム結果データの受信に失敗した場合には、ゲーム装置２０は、サーバシステム１０が受信に成功するまで、ゲーム結果データの送信を繰り返す。具体的には、バックグラウンド通信により、ゲーム結果データを送信する。

なおゲーム装置２０は、サーバシステム１０がゲーム結果データの受信に成功したか否かを、図８（Ｅ）の処理結果コードに基づいて判定できる。即ち図８（Ｅ）のように適正な処理結果コードがサーバシステム１０から返って来た場合には、サーバシステム１０の受信が成功したと判定し、返って来なかった場合には受信に失敗したと判定する。

また図９（Ｂ）ではサーバシステム１０は、ロード処理の際に課金セッションＩＤを生成し、生成された課金セッションＩＤと課金開始時間（課金セッションの開始時間、ロード処理の時間）をゲームデータ記憶部２４に保存する。そして、ゲームデータ記憶部２４２に記憶されたユーザデータと、生成された課金セッションＩＤをゲーム装置２０に送信する。

一方、図９（Ｄ）に示すように、サーバシステム１０は、セーブ処理の際に、対応する課金セッションＩＤをゲーム装置２０から受信すると、そのゲーム結果データと課金終了時間（課金セッションの終了時間）をゲームデータ記憶部２４に保存する。

そして図９（Ｅ）に示すように、課金処理部２２０は、図９（Ｄ）で受信した課金セッションＩＤを用いて課金処理を行う。具体的には、各プレーヤ毎の課金セッションの回数を、そのプレーヤについての課金セッションＩＤの個数に基づいて特定し、課金セッションの回数が多くなるほど高くなる課金を、プレーヤに対して行う。このようにすれば、課金セッションＩＤの個数をカウントするだけで、課金額を特定できるため、課金処理の負荷を大幅に軽減できる。

ところで、図１０（Ｂ）に示すようにゲーム装置２０がユーザデータの受信に失敗して、図１０（Ｃ）に示すようにＩＣカード１９４からのユーザデータに基づきゲーム処理を行う場合には、ゲーム装置２０は課金セッションＩＤの受信にも失敗している。従って、何ら対策を講じないと、課金セッションＩＤを用いた課金処理を実現できなくなってしまう。

そこで図１０（Ｄ）では、ゲーム装置２０は、課金セッションＩＤの受信に失敗した場合には、セーブ処理の際に、ゲーム結果データに関連づけて仮課金セッションＩＤをサーバシステム１０に送信する。この仮課金セッションＩＤは、通常の課金セッションＩＤには使用されない特定のコードに設定されたＩＤである。

サーバシステム１０は、このような仮課金セッションＩＤを受信した場合に、ゲーム結果データと、仮課金セッションＩＤの受信時間である課金終了時間をゲームデータ記憶部２４２に保存する。そして図１０（Ｅ）に示すようにサーバシステム１０は、新たな正規の課金セッションＩＤを生成して課金処理を行う。具体的には、仮課金セッションＩＤを受信した場合には、課金開始（ロード）と課金終了（セーブ）が同時に行われたと見なして、新たな課金セッションＩＤを生成し、生成された新たな課金セッションＩＤに基づいて、課金処理を行う。例えば、課金終了時間の回数をカウントして、課金処理を行う。

例えば図１１（Ａ）では、課金処理部２２０は、ロード処理による課金開始時間（広義にはロード処理の時間）とセーブ処理による課金終了時間（広義にはセーブ処理の時間）との差が、所定の時間差内であることを条件に、課金処理を行う。例えば課金開始時間と課金終了時間の差が、２４時間以内ではなかった場合には、正常な課金セッションではないことが推定される。従って、この場合には、課金セッションは正常ではないとして、課金を行わないようにする。

具体的には、図１０（Ｂ）のようにゲーム装置２０が課金セッションＩＤの受信に失敗し、図１０（Ｄ）のように仮課金セッションＩＤを送信した場合には、サーバシステム１０は、当該課金セッションについての課金開始時間を取得（特定）できない。一方、課金終了時間については、仮課金セッションＩＤを受信した時を課金終了時間として設定できる。

そこで図１１（Ｂ）に示すように、課金開始時間（ロード処理の時間）が取得されなかった場合にも、課金終了時間（セーブ処理の時間）が取得された場合には、課金処理を行うようにする。このようにすれば、ゲーム装置２０がユーザデータの受信に失敗し、仮課金セッションＩＤが発行された場合にも、正常に課金セッションを終了して、課金処理を実現できるようになる。

４．３ 課金データ
次に本実施形態の課金処理部２２０により作成される課金データについて説明する。課金処理部２２０は、プレーヤへの課金のための課金データとして、課金セッションデータと課金集計データを作成する。

具体的には課金処理部２２０は、課金セッションＩＤと、課金セッションＩＤに関連づけられた課金情報とを含む課金セッションデータを作成する。この場合の課金情報は、課金開始時間（ロード処理の時間）及び課金終了時間（セーブ処理の時間）の少なくとも一方を含むことができる。このような課金開始時間や課金終了時間を課金セッションデータに含ませれば、どの時間に発生した課金なのかを明確化できる。

図１２（Ａ）に課金セッションデータの具体的なデータ構造例を示す。受領日は課金データの発生日であり、課金セッションデータを作成した日である。ゲームＩＤ、ゲームサブＩＤは、ゲーム装置において実行されるゲームを識別するためのＩＤ、サブＩＤである。課金開始時間は課金対象となるゲームが開始した時刻であり、課金終了時間は課金対象となるゲームが終了した時刻である。例えばゲーム装置２０からユーザデータのリクエストが来て、処理を開始した時に、時刻が計測されて、その時刻が課金開始時間として記録される。またゲーム結果データである個人データを受信した時に、時刻が計測されて、その時刻が課金終了時間として記録される。処理済みフラグは、課金データの集計をしたか否かを示すフラグであり、最終更新時間は、最後に当該レコードを更新した時刻である。図１２（Ａ）では、これらの課金情報が、各課金セッションを一意に識別するための課金セッションＩＤに関連づけられる。

また課金処理部２２０は、プレーヤへの課金データとして、ゲーム装置ＩＤと、ロード処理及びセーブ処理の少なくとも一方による課金回数情報とを含む課金集計データを作成する。このようなゲーム装置ＩＤと課金回数情報を課金集計データに含ませれば、例えば課金回数が多くなるほど高くなる課金を、簡素に特定して通知できるようになる。

図１２（Ｂ）に課金集計データの具体的なデータ構造例を示す。受付日は課金データの集計日であり、売上日は課金データの発生日である。課金コードは、当該課金セッションの課金モードを示すコードである。課金回数情報である課金開始回数は、有効に課金開始した課金セッションの回数（個数）であり、課金回数情報である課金終了回数は、有効に課金終了した課金セッションの回数（個数）である。最終更新時間は最後に当該レコードを更新した時刻である。

４．４ 詳細な処理
次に本実施形態のサーバシステム１０の詳細な処理フローについて説明する。

図１３（Ａ）はゲーム装置２０の登録の処理フローである。まずゲーム装置２０からリクエストを受信する（Ａ１）。すると、受信したゲーム装置ＩＤ（或いはユーザＩＤ）を、ゲームデータ記憶部２４２（データベース）の該当情報を照合し、未登録であるならば新規に登録し、そうでない場合には特に処理は行わない（Ａ２）。そしてゲーム装置２０の最終アクセス日時を更新し（Ａ３）、通信間隔の制御パラメータとリクエストの処理結果コードを返信して、処理を終了する（Ａ４）。

図１３（Ｂ）は、ユーザデータのロード（送信）の処理フローである。まずゲーム装置２０からリクエストを受信する（Ｂ１）。すると、受信したリクエストに含まれるキャラクターＤＢＩＤに基づいて、ユーザデータ（キャラクタ情報）をゲームデータ記憶部２４２から取得する（Ｂ２）。次に、課金セッションＩＤを生成し、サーバ上の現在時刻を課金開始時間として、その他の課金情報と合わせて課金サーバ（課金処理部）に登録する（Ｂ３）。この時、送信されてきたカードＩＤとゲームデータ記憶部２４２上のカードＩＤが異なっている場合には、カードの引継ぎが行われたとして、ゲームデータ記憶部２４２上のカードデータを修正する（Ｂ４）。そして、ユーザデータと課金セッションＩＤと処理結果コードを返信して、処理を終了する（Ｂ５）。

図１３（Ｃ）は、新規カード登録の処理フローである。まずゲーム装置２０からリクエストを受信する（Ｃ１）。すると、受信したカードＩＤをゲームデータ記憶部２４２の該当情報と照合し、使用中（使用済）のＩＣカードである場合には使用中（使用済）としてエラーを返信する（Ｃ２）。未使用のＩＣカードによるリクエストである場合には、新たにキャラクタのデータを保存する領域を確保し、キャラクタＤＢＩＤを発行する（Ｃ３）。そして課金セッションＩＤを生成し、サーバ上の現在時刻を課金開始時間として、その他の課金情報と合わせて課金サーバに登録する（Ｃ４）。次にキャラクタＤＢＩＤ等のゲームデータと課金セッションＩＤと処理結果コードを返信して、処理を終了する（Ｃ５）。

図１４（Ａ）、図１４（Ｂ）に新規カード登録データのデータ構造例を示す。図１４（Ａ）は、図１３（Ｃ）の（Ｃ１）でゲーム装置２０からサーバシステム１０に送信されるデータである。ファイターＩＤは、そのＩＣカードで使用されるファイターのＩＤである。カード発行ＩＤは、新規カード発行時にクライアント（ゲーム装置）側が発行するＩＤである。

図１４（Ｂ）は、図１３（Ｃ）の（Ｃ５）でサーバシステム１０からゲーム装置２０に送信されるデータである。アイテム装備情報は、キャラクタが装備しているデフォルトのアイテムの装備情報である。課金セッションＩＤは、サーバシステム１０が発行するセッションＩＤであり、ゲーム装置２０はゲーム終了時に同じ値を返す。

図１３（Ｄ）は、ゲーム結果データであるプレイデータのセーブ（送信）の処理フローである。まずゲーム装置２０からリクエストを受信する（Ｄ１）。すると、プレイデータを各種データに変換して、ゲームデータ記憶部２４２に保存する（Ｄ２）。具体的には、プレイデータの過去の履歴を解析し、今回の新しいプレイデータとマージする更新処理を行う。なお対人戦、対ゴースト戦、対ＣＰＵ戦のそれぞれでリクエストは異なるが、基本的な処理は同じになる。そして処理結果コードを返信して処理を終了する（Ｄ３）。

図１５（Ａ）、図１５（Ｂ）にプレイデータのデータ構造例を示す。なお同図は対人戦の場合のプレイデータの例であり、対ゴースト戦や対ＣＰＵ戦では、異なった構造のデータになる。

図１５（Ａ）は、図１３（Ｄ）の（Ｄ１）でゲーム装置２０からサーバシステム１０に送信されるデータである。勝敗フラグは、１Ｐプレーヤと２Ｐプレーヤのどちらが勝ったかを示すフラグである。パーフェクト勝利数、グレート勝利数は、パーフェクト勝利、グレート勝利のラウンド数である。上段攻撃数、上段ガード成功数、中段攻撃数、中段ガード成功数は、プレーヤが成功した上段攻撃、上段ガード、中段攻撃、中段ガードの総数である。このようにプレイデータは、対戦におけるゲーム結果データを表すものである。

図１５（Ｂ）は、図１３（Ｄ）の（Ｄ３）でサーバシステム１０からゲーム装置２０に送信されるデータである。処理結果は、処理（プレイデータの受信処理）の結果を通知するコードである。

図１６（Ａ）は、ゲーム結果データである個人データのセーブ（送信）の処理フローである。まずゲーム装置２０からリクエストを受信する（Ｅ１）。すると、受信した個人データを各種データに変換して、ゲームデータ記憶部２４２に保存する（Ｅ２）。具体的には、個人データの過去の履歴を解析し、今回の新しい個人データとマージする更新処理を行う。次に、課金セッションＩＤに基づいて、当該課金セッションの終了を課金サーバに対して登録する（Ｅ３）。そして処理結果コードを返信して、処理を終了する（Ｅ４）。

図１６（Ｂ）はパッチバージョンの確認の処理フローである。まずゲーム装置２０からリクエストを受信する（Ｆ１）。すると、送信されて来た既に入手済みのパッチバージョン番号より新しいパッチが提供されているかを、ゲームデータ記憶部２４２の情報に基づいて確認する（Ｆ２）。新しいものが提供されている場合には、次に入手すべきパッチバージョン番号と処理結果コードを返信して、処理を終了する（Ｆ３）。

図１６（Ｃ）はパッチデータのロード（送信）の処理フローである。まずゲーム装置２０からリクエストを受信する（Ｇ１）。すると、指定されたパッチデータをゲームデータ記憶部２４２から読み出す（Ｇ２）。次に、読み出したパッチデータと処理結果コードを返信して、処理を終了する（Ｇ３）。このパッチデータは、ゲームプログラムを最新バージョンに更新するためのデータである。

図１７（Ａ）は、リプレイデータやプレイ履歴データの確認処理のフローである。まずゲーム装置２０からリクエストを受信する（Ｈ１）。すると、ゲーム装置２０から送信されて来たリプレイデータリスト（プレイ履歴データリスト）のリプレイデータ以外に、ゲーム装置２０に対して提供可能なリプレイデータ（プレイ履歴データ）が存在するか否かを検索する（Ｈ２）。ここでリプレイデータリスト（プレイ履歴データリスト）は、ゲーム装置２０が現在所持しているリプレイデータ（プレイ履歴データ）のリストである。提供可能なリプレイデータ（プレイ履歴データ）が存在する場合には、該当リプレイデータ（プレイ履歴データ）を、ダウンロード用のキャッシュ領域にコピーする（Ｈ３）。そして、提供可能なリプレイデータ（プレイ履歴データ）のＩＤと処理結果コードを返信して、処理を終了する（Ｈ４）。

図１７（Ｂ）は、リプレイデータやプレイ履歴データのロード（送信）の処理フローである。まずゲーム装置２０からリクエストを受信する（Ｉ１）。すると、要求されたリプレイデータ（プレイ履歴データ）のＩＤと、ダウンロード用のキャッシュ領域に用意されたリプレイデータ（プレイ履歴データ）のＩＤとが一致しているか確認する（Ｉ２）。そして、ダウンロード用のキャッシュ領域からリプレイデータ（プレイ履歴データ）を取得する（Ｉ３）。そして、リプレイデータ（プレイ履歴データ）と処理結果コードを返信して、処理を終了する（Ｉ４）。

なおプレイ履歴データは、いわゆるゴーストデータであり、このゴーストデータにより操作されるゴーストキャラクタには大きく２種類ある。１つは、実際のプレーヤのプレイ履歴（操作データの履歴）に沿ってその動きを忠実に再現した、プレーヤのゲームプレイをリプレイしているようなゴーストキャラクタである。もう１つは、実際のプレーヤのプレイ履歴とコンピュータ制御ルーチンとを組み合わせて、プレーヤのプレイ傾向に沿った動きをするゴーストキャラクタである。

図１７（Ｃ）は、ランキングデータの確認の処理フローである。まずゲーム装置２０からリクエストを受信する（Ｊ１）。すると、現在提供中のランキングデータのバージョンＩＤを検索する（Ｊ２）。そして、提供中のランキングデータのバージョンＩＤと処理結果コードを返信して、処理を終了する（Ｊ３）。

図１７（Ｄ）は、ランキングデータの取得の処理フローである。まずゲーム装置２０からリクエストを受信する（Ｋ１）。すると、要求されたランキングデータをゲームデータ記憶部２４２から取得する（Ｋ２）。そして、ランキングデータと処理結果コードを返信して、処理を終了する（Ｋ３）。

図１８（Ａ）は、リプレイデータやプレイ履歴データの保存準備処理のフローである。まずゲーム装置２０からリクエストを受信する（Ｐ１）。すると、指定されたリプレイデータ（プレイ履歴データ）を受信するためのアップロード用のキャッシュ領域を確保する（Ｐ２）。そして、アップロードキャッシュ用のＩＤと処理結果コードを返信して、処理を終了する（Ｐ３）。

図１８（Ｂ）は、リプレイデータやプレイ履歴データの保存処理のフローである。まずゲーム装置２０からリクエストを受信する（Ｑ１）。すると、リプレイデータ（プレイ履歴データ）の断片（転送単位データ）をアップロード用のキャッシュ領域に保存する（Ｑ２）。そして、全てのリプレイデータの断片が揃ったら、それらのデータを結合してリプレイデータ（プレイ履歴データ）を生成し、ゲームデータ記憶部２４２に保存する（Ｑ３）。そして、処理結果コードを返信して、処理を終了する（Ｑ４）。

４．５ 課金レート
本実施形態では図１９（Ａ）に示すように、ロード処理及びセーブ処理の少なくとも一方の回数である処理回数が多くなるほど、プレーヤへの課金が高くなるように課金処理を行う。例えば処理回数に所定の乗算係数を乗算することで、課金金額を決める。この処理回数は、図１２（Ｂ）の課金集計データの課金開始回数、課金終了回数である。

図１９（Ａ）のようにすれば、ネットワークサービスであるロード処理やセーブ処理の回数に応じて、課金が決まるようになる。従って、プレーヤのネットワークサービスの利用回数が多いほど、プレーヤの課金額が高くなり、公平な課金を実現できる。また回数のカウントだけで課金を決定できるため、課金処理の負荷も非常に軽いという利点がある。

但し、このような単一的な課金処理では、様々な事情・要望に応えることができなくなるおそれがある。このような場合には、例えば処理回数に対する課金レートを可変に変更する。例えば課金金額＝Ｋ×処理回数と表される場合には、様々な要因に基づいて課金レートに相当するＫを変化させる。或いは処理回数自体を課金レートに応じて、多くしたり少なくする。

例えば図１９（Ｂ）では、ゲーム装置においてプレーヤがゲームプレイした時間帯を特定する。そして特定された時間帯に応じて、課金レートを変更する。即ち図１９（Ｂ）のように、時間帯と課金レートを関連づけたテーブルに基づいて課金レートを設定する。

例えば午前中の時間帯（６時〜１２時）では課金レートを低くする一方で、夜の時間帯（１８時〜２４時）では課金レートを高くする。このようにすれば、ネットワークゲームへのプレーヤの参加人数が少ない午前中の時間帯では、プレーヤへの課金金額が小さくなるため、課金金額が安いことを動機づけとして、ネットワークゲームへのプレーヤの参加を促すことができる。一方、ネットワークゲームへのプレーヤの参加人数が多い夜の時間帯では課金レートを高くすることで、この時間帯でのネットワークゲームへのプレーヤの参加を抑制させて、混んでいる時間帯でのネットワークの負荷を軽減できる。

なお、プレーヤがゲームプレイした時間帯は、例えば図１２（Ａ）の課金開始時間や課金終了時間により特定できる。具体的には図９（Ｂ）のユーザデータの送信タイミングで課金開始時間を特定し、図９（Ｄ）のゲーム結果の受信タイミングで課金終了時間を特定する。そしてこれらの課金開始時間と課金終了時間の少なくとも一方により、プレーヤがゲームプレイした時間帯を特定する。このようにすれば、図１２（Ａ）の課金セッションデータに含まれる課金開始時間や課金終了時間を有効活用して、その課金セッションについての課金レートを簡素な処理で変更できる。なお、ゲーム装置からの受信情報に基づいて、プレーヤがゲームプレイした時間帯を特定してもよい。

４．６ リプレイデータ等のロード処理に対する課金
以上では、ユーザデータのロード処理やゲーム結果データのセーブ処理に対して課金を行う場合について説明したが、課金対象となるロード処理はこれに限定されない。例えばリプレイデータ、プレイ履歴データ、ランキングデータのロード処理に対して課金処理を行ってもよい。或いは、パッチデータのロード処理に対して課金処理を行うことも可能である。

例えば図２０（Ａ）では、ゲーム装置２０がリプレイデータリスト（プレイ履歴データリスト）をサーバ側に送信する。このリストによりサーバ側は、ゲーム装置２０に既にロードされているリプレイデータを識別できる。

そして図２０（Ｂ）では、ゲーム処理部２１０（送信部）が、リプレイデータ（プレイ履歴データ）を、ゲーム装置２０に送信する。具体的には、ゲーム装置２０に対して既にロードされているリプレイデータ以外の未ロードのリプレイデータ（未ロードのプレイ履歴データ）を、ゲーム装置２０に送信する。この未ロードのリプレイデータは、図２０（Ａ）で受信したリプレイデータリストにより判断できる。

そして課金処理部２２０は、このようにリプレイデータ（プレイ履歴データ）をゲーム装置２０に送信するロード処理に対して、課金処理を行う。例えばリプレイデータ（プレイ履歴データ）のロード処理の回数に応じて高くなる課金処理を行う。

このようにすれば、リプレイデータやプレイ履歴データをロードするネットワークサービスに対して、課金を行うことができる。即ちネットワークサービスの対価として課金することができ、より公平で適切な課金処理を実現できる。

また図２０（Ｃ）では、ゲーム処理部２１０の送信部２１４が、ランキングデータを、ゲーム装置２０に送信する。この場合に課金処理部２２０は、ランキングデータを、ゲーム装置に送信するロード処理に対して、課金処理を行う。例えばランキングデータのロード処理の回数に応じて高くなる課金処理を行う。

このようにすれば、ランキングデータをロードするというネットワークサービスの対価として課金することができ、より公平で適切な課金処理を実現できる。

４．７ バックグラウンド通信
図２１〜図２３に、ゲーム装置２０の処理の詳細を説明するためのフローチャートを示す。

図２１は、ゲーム装置２０の全体的な処理を説明するためのフローチャートである。なお図２１は、説明を簡素化するために、全てのプレーヤがＩＣカード（メモリカード）を使用してゲームプレイを行う場合を想定したフローになっている。

ゲームプレイが行われていない状態では、バックグラウンド通信等が行われる（ステップＳ１）。プレーヤがＩＣカード１９４をゲーム装置２０のカード挿入部に挿入して、ゲームを開始すると、カード状態の確認が行われる（ステップＳ２）。そして、挿入されたＩＣカード１９４が登録済みのカードか否かが判断される（ステップＳ３）。登録済みのカードである場合には、図５（Ａ）で説明したユーザデータのリクエストの送信が行われる（ステップＳ４）。そしてゲーム処理が開始して、プレーヤのゲームプレイが開始する（ステップＳ７）。一方、未登録の新規のカードである場合には、図１３（Ｃ）で説明した新規カード登録のリクエストの送信が行われる（ステップＳ５）。そして登録に成功した場合には、ゲーム処理が開始し（ステップＳ６、Ｓ７）、成功しなかった場合にはステップＳ２に戻る。

１ゲームが終了すると、図１３（Ｄ）で説明したプレイデータの送信が行われる（ステップＳ９）。そしてゲームに勝利したか否かが判断され（ステップＳ１０）、勝利した場合にはステップＳ７に戻り、次のゲームが開始する。一方、敗北して、ゲームオーバーになった場合には、図５（Ｄ）、図１６（Ａ）で説明した個人データ（ゲーム結果データ）の送信が行われる（ステップＳ１１）。そしてステップＳ１に戻る。

図２２は、図２１のステップＳ１で行われるバックグラウンド通信処理のフローチャートである。バックグラウンド通信では、まずスタックデータの送信処理が行われる（ステップＳ２１）。そしてスタックデータが残っているか否かが判断され（ステップＳ２２）、残っている場合にはステップＳ２１に戻り、スタックデータが無くなるまで送信が繰り返される。

未送信のスタックデータが無くなると、図１６（Ｂ）で説明したパッチバージョンの確認が行われる（ステップＳ２３）。そしてサーバ側に最新パッチデータが存在する場合には、図１６（Ｃ）で説明したパッチデータの受信が行われる（ステップＳ２５）。

次に、図１７（Ａ）で説明したプレイ履歴データの確認が行われる（ステップＳ２６）。そして、最新（未ロード）のプレイ履歴データが存在する場合には、図１７（Ｂ）で説明したプレイ履歴データの受信が行われる（ステップＳ２７、Ｓ２８）。

図２３は図２２のステップＳ２１のスタックデータ送信処理のフローチャートである。まず個人データのスタックの確認が行われる（ステップＳ３１）。そして個人データのスタックがある場合には、スタックされた個人データの送信が行われる（ステップＳ３２、Ｓ３３）。次にプレイデータのスタックの確認が行われる（ステップＳ３４）。そしてプレイデータのスタックがある場合には、スタックされたプレイデータの送信が行われる（ステップＳ３５、Ｓ３６）。同様にしてプレイ履歴データ、リプレイデータのスタックの送信も行われる。

以上のように本実施形態では、ゲーム装置２０の送信部１０６は、個人データやプレイデータなどのゲーム結果データの送信に失敗した場合には、ゲーム結果データをスタックする。そしてスタックされたゲーム結果データを、図２２、図２３で説明したバックグラウンド通信によりサーバシステム１０に送信する。

例えば図８（Ｂ）のようにユーザデータの受信に失敗した時に、ユーザデータをスタックして再度通信を行うようにすると、通信が成功するまでプレーヤを待たせることになり、スムーズなゲーム処理を実現できない。

この点、ゲーム結果データを送信する時には、既にゲームが終了している。従って、ゲーム終了後の期間を有効活用して、バックグラウンド通信によりゲーム結果データをサーバシステム１０に送信すれば、プレーヤを待たせるなどの事態が生じることなく、ゲーム結果データのセーブ処理を実現できる。そしてこの場合に、図８（Ｅ）や図１１（Ｂ）で説明したように、セーブ処理に対してだけ課金処理を行うようにすれば、ユーザデータの受信失敗時にも適正な課金処理を実現できるようになる。

なお、上記のように本実施形態について詳細に説明したが、本発明の新規事項および効果から実体的に逸脱しない多くの変形が可能であることは当業者には容易に理解できるであろう。従って、このような変形例やその組み合わせは全て本発明の範囲に含まれるものとする。例えば、明細書又は図面において、少なくとも一度、より広義または同義な異なる用語（プレーヤ用記憶装置、携帯型通信端末、ロード処理の時間、セーブ処理の時間等）と共に記載された用語（ＩＣカード、携帯電話、課金開始時間、課金終了時間等）は、明細書又は図面のいかなる箇所においても、その異なる用語に置き換えることができる。また、ロード処理、セーブ処理、課金処理等も、本実施形態で説明したものに限定されず、これらと均等な手法も本発明の範囲に含まれる。

本実施形態のシステム構成例。 図１のシステムのハードウェア構成例。 本実施形態のサーバシステムの機能ブロック図の例。 本実施形態のゲーム装置の機能ブロック図の例。 図５（Ａ）〜図５（Ｅ）は本実施形態の課金処理の説明図。 図６（Ａ）、図６（Ｂ）はユーザデータのデータ構造例。 図７（Ａ）、図７（Ｂ）はゲーム結果データである個人データのデータ構造例。 図８（Ａ）〜図８（Ｅ）は受信失敗時の本実施形態の課金処理の説明図。 図９（Ａ）〜図９（Ｅ）は課金セッションＩＤを用いた課金処理の説明図。 図１０（Ａ）〜図１０（Ｅ）は受信失敗時の本実施形態の課金処理の説明図。 図１１（Ａ）、図１１（Ｂ）は課金処理の説明図。 図１２（Ａ）、図１２（Ｂ）は課金セッションデータのデータ構造例。 図１３（Ａ）〜図１３（Ｄ）は本実施形態の詳細な処理の説明図。 図１４（Ａ）、図１４（Ｂ）は新規カード登録データのデータ構造例。 図１５（Ａ）、図１５（Ｂ）はプレイデータのデータ構造例。 図１６（Ａ）〜図１６（Ｃ）は本実施形態の詳細な処理の説明図。 図１７（Ａ）〜図１７（Ｄ）は本実施形態の詳細な処理の説明図。 図１８（Ａ）、図１８（Ｂ）は本実施形態の詳細な処理の説明図。 図１９（Ａ）、図１９（Ｂ）は課金レートの変更手法の説明図。 図２０（Ａ）〜図２０（Ｃ）はリプレイデータ等のロード処理に対して行う課金処理の説明図。 ゲーム装置の処理を説明するためのフローチャート。 バックグラウンド通信処理を説明するためのフローチャート。 スタックデータ送信処理を説明するためのフローチャート。

符号の説明

１０ サーバシステム、１２ ネットワーク、
２０、２０-1〜２０-２０-n ゲーム装置、３０ 認証サーバ、４０ ゲームサーバ、
４２ ゲームデータベース、５０ 課金サーバ、
５２ 課金データベース、６０ 携帯電話用ウェブサーバ、
６２ 携帯電話用データベース、６４ 携帯電話、
７０ バックオフィスサーバ、７２ バックオフィス端末、
１００ 処理部、１０２ ゲーム処理部、１０４ 受信部、１０６ 送信部、
１２０ 画像生成部、１２８ 音生成部、１３０ 操作部、１４０ 記憶部、
１４２ ゲームデータ記憶部、１４４ ユーザデータ記憶部、
１４６ ゲーム結果データ記憶部、１４８ 個人データ記憶部、
１５０ ランキングデータ記憶部、１５１ パッチデータ記憶部、
１５２ リプレイデータ記憶部、１５３ プレイ履歴データ記憶部、
１５８ 課金セッションＩＤ記憶部、１７０ 描画バッファ、
１８０ 情報記憶媒体、１９０ 表示部、１９２ 音出力部、１９３ Ｉ／Ｆ部、
１９４ ＩＣカード（プレーヤ用記憶装置）、１９６ 通信部、
２００ 処理部、２１０ ゲーム処理部、２１２ 受け付け部、２１３ 読み出し部、
２１４ 送信部、２１５ 受信部、２１６ 書き込み部、２２０ 課金処理部、
２２２ 課金データ作成部、２２４ 課金レート変更部、２３０ 操作部、
２４０ 記憶部、２４２ ゲームデータ記憶部、２４４ ユーザデータ記憶部、
２４６ ゲーム結果データ記憶部、２４８ 個人データ記憶部、
２５０ ランキングデータ記憶部、２５１ パッチデータ記憶部、
２５２ リプレイデータ記憶部、２５３ プレイ履歴データ記憶部、
２５８ 課金セッションＩＤ記憶部、２６０ 課金データ記憶部、
２６２ 課金セッションデータ記憶部、２６４ 課金集計データ記憶部、
２７０ 課金レート記憶部、２８０ 情報記憶媒体、２９０ 表示部、２９６ 通信部

Claims (16)

1. ゲーム装置と通信接続されるサーバシステムであって、
   ゲームデータを記憶するゲームデータ記憶部と、
   前記ゲーム装置でプレイするプレーヤのユーザデータを、前記ゲームデータ記憶部から読み出す読み出し部と、
   前記ユーザデータを、プレーヤのゲームプレイ開始前に前記ゲーム装置に送信する送信部と、
   前記ゲーム装置でのプレーヤのゲーム結果データを、プレーヤのゲームプレイ終了後に前記ゲーム装置から受信する受信部と、
   受信された前記ゲーム結果データを前記ゲームデータ記憶部に書き込む書き込み部と、
   前記ユーザデータを前記ゲームデータ記憶部から読み出して前記ゲーム装置に送信するロード処理、及び、前記ゲーム結果データを前記ゲーム装置から受信して前記ゲームデータ記憶部に書き込むセーブ処理の少なくとも一方に対して、前記ゲーム装置でプレイするプレーヤへの課金処理を行う課金処理部と、
   を含み、
   前記送信部は、
   前記ロード処理の際に、前記ユーザデータと、前記ユーザデータに関連づけられた課金セッション識別情報とを、前記ゲーム装置に送信し、
   前記受信部は、
   前記セーブ処理の際に、前記ゲーム結果データと、前記ゲーム結果データに関連づけられた前記課金セッション識別情報とを、前記ゲーム装置から受信し、
   前記課金処理部は、
   受信した前記課金セッション識別情報を用いて、課金処理を行い、
   前記課金処理部は、
   前記ロード処理及び前記セーブ処理の少なくとも一方の回数である処理回数に対する課金レートを可変に変更する課金レート変更部を含むことを特徴とするサーバシステム。
2. 請求項１において、
   前記送信部は、
   プレーヤの過去のゲーム成績情報、プレーヤが所属するチームの過去のゲーム成績情報、プレーヤのゲームプレイ履歴情報、成長情報、経験値情報、及び装備情報の少なくとも１つを含む前記ユーザデータを、前記ロード処理の際に前記ゲーム装置に対して送信することを特徴とするサーバシステム。
3. 請求項１又は２において、
   前記受信部は、
   プレーヤの今回のゲームでのゲーム成績情報、プレーヤが所属するチームの今回のゲームでのゲーム成績情報、プレーヤの今回のゲームプレイ履歴情報、今回のゲームプレイで更新された成長情報、及び今回のゲームプレイで更新された経験値情報の少なくとも１つを含む前記ゲーム結果データを、前記セーブ処理の際に前記ゲーム装置から受信することを特徴とするサーバシステム。
4. 請求項１乃至３のいずれかにおいて、
   前記課金処理部は、
   前記ロード処理に対しては課金処理を行わずに、前記セーブ処理に対して課金処理を行うことを特徴とするサーバシステム。
5. 請求項４において、
   前記ゲーム装置は、
   前記サーバシステムから送信される前記ユーザデータの受信に失敗した場合には、プレーヤ用記憶装置に記憶されるユーザデータを用いて、ゲーム処理を行い、
   前記課金処理部は、
   前記ゲーム処理のゲーム結果データを受信して前記ゲームデータ記憶部に書き込むセーブ処理に対して、課金処理を行うことを特徴とするサーバシステム。
6. 請求項１乃至５のいずれかにおいて、
   前記課金処理部は、
   前記ロード処理の時間と前記セーブ処理の時間との差が、所定の時間差内であることを条件に、課金処理を行うことを特徴とするサーバシステム。
7. ゲーム装置と通信接続されるサーバシステムであって、
   ゲームデータを記憶するゲームデータ記憶部と、
   前記ゲーム装置でプレイするプレーヤのユーザデータを、前記ゲームデータ記憶部から読み出す読み出し部と、
   前記ユーザデータを、プレーヤのゲームプレイ開始前に前記ゲーム装置に送信する送信部と、
   前記ゲーム装置でのプレーヤのゲーム結果データを、プレーヤのゲームプレイ終了後に前記ゲーム装置から受信する受信部と、
   受信された前記ゲーム結果データを前記ゲームデータ記憶部に書き込む書き込み部と、
   前記ゲーム装置でプレイするプレーヤへの課金処理を行う課金処理部とを含み、
   前記送信部は、
   前記ユーザデータを前記ゲームデータ記憶部から読み出して前記ゲーム装置に送信するロード処理の際に、前記ユーザデータと、前記ユーザデータに関連づけられた課金セッション識別情報とを、前記ゲーム装置に送信し、
   前記受信部は、
   前記ゲーム結果データを前記ゲーム装置から受信して前記ゲームデータ記憶部に書き込むセーブ処理の際に、前記ゲーム結果データと、前記ゲーム結果データに関連づけられた前記課金セッション識別情報とを、前記ゲーム装置から受信し、
   前記課金処理部は、
   受信した前記課金セッション識別情報を用いて、前記ゲーム装置でプレイするプレーヤへの課金処理を行い、
   前記ゲーム装置は、
   前記サーバシステムから送信される前記課金セッション識別情報の受信に失敗した場合には、前記セーブ処理の際に、前記ゲーム結果データに関連づけて仮課金セッション識別情報を前記サーバシステムに送信し、
   前記課金処理部は、
   前記仮課金セッション識別情報を受信した場合には、課金開始と課金終了が同時に行われたと見なして、新たな課金セッション識別情報を生成し、生成された新たな課金セッション識別情報に基づいて、課金処理を行うことを特徴とするサーバシステム。
8. ゲーム装置と通信接続されるサーバシステムであって、
   ゲームデータを記憶するゲームデータ記憶部と、
   前記ゲーム装置でプレイするプレーヤのユーザデータを、前記ゲームデータ記憶部から読み出す読み出し部と、
   前記ユーザデータを、プレーヤのゲームプレイ開始前に前記ゲーム装置に送信する送信部と、
   前記ゲーム装置でのプレーヤのゲーム結果データを、プレーヤのゲームプレイ終了後に前記ゲーム装置から受信する受信部と、
   受信された前記ゲーム結果データを前記ゲームデータ記憶部に書き込む書き込み部と、
   前記ゲーム装置でプレイするプレーヤへの課金処理を行う課金処理部とを含み、
   前記送信部は、
   前記ユーザデータを前記ゲームデータ記憶部から読み出して前記ゲーム装置に送信するロード処理の際に、前記ユーザデータと、前記ユーザデータに関連づけられた課金セッション識別情報とを、前記ゲーム装置に送信し、
   前記受信部は、
   前記ゲーム結果データを前記ゲーム装置から受信して前記ゲームデータ記憶部に書き込むセーブ処理の際に、前記ゲーム結果データと、前記ゲーム結果データに関連づけられた前記課金セッション識別情報とを、前記ゲーム装置から受信し、
   前記課金処理部は、
   受信した前記課金セッション識別情報を用いて、前記ゲーム装置でプレイするプレーヤへの課金処理を行い、
   前記課金処理部は、
   前記ロード処理の時間及び前記セーブ処理の時間の少なくとも一方を含む課金情報を、前記課金セッション識別情報に関連づけて、
   前記ゲーム装置でプレイするプレーヤへの課金のための課金データとして、前記課金セッション識別情報と、前記課金セッション識別情報に関連づけられた前記課金情報とを含む課金セッションデータを作成することを特徴とするサーバシステム。
9. 請求項１乃至８のいずれかにおいて、
   前記課金処理部は、
   前記ゲーム装置でプレイするプレーヤへの課金のための課金データとして、前記ゲーム装置の識別情報と、前記ロード処理及び前記セーブ処理の少なくとも一方による課金回数情報とを含む課金集計データを作成することを特徴とするサーバシステム。
10. 請求項１乃至９のいずれかにおいて、
    前記課金処理部は、
    前記ロード処理及び前記セーブ処理の少なくとも一方の回数である処理回数が多くなるほど、プレーヤへの課金が高くなる課金処理を行うことを特徴とするサーバシステム。
11. 請求項７又は８において、
    前記課金処理部は、
    前記ロード処理及び前記セーブ処理の少なくとも一方の回数である処理回数に対する課金レートを可変に変更する課金レート変更部を含むことを特徴とするサーバシステム。
12. 請求項１乃至６又は請求項１１のいずれかにおいて、
    前記課金処理部は、
    前記ゲーム装置においてプレーヤがゲームプレイした時間帯を特定し、特定された時間帯に応じて、前記課金レートを変更することを特徴とするサーバシステム。
13. 請求項１乃至１２のいずれかにおいて、
    前記送信部は、
    リプレイデータ又はプレイ履歴データを、前記ゲーム装置に送信し、
    前記課金処理部は、
    前記リプレイデータ又は前記プレイ履歴データを前記ゲーム装置に送信するロード処理に対して、課金処理を行うことを特徴とするサーバシステム。
14. ゲーム装置と通信接続されるサーバシステムのためのプログラムであって、
    ゲームデータを記憶するゲームデータ記憶部と、
    前記ゲーム装置でプレイするプレーヤのユーザデータを、前記ゲームデータ記憶部から読み出す読み出し部と、
    前記ユーザデータを、プレーヤのゲームプレイ開始前に前記ゲーム装置に送信する送信部と、
    前記ゲーム装置でのプレーヤのゲーム結果データを、プレーヤのゲームプレイ終了後に前記ゲーム装置から受信する受信部と、
    受信された前記ゲーム結果データを前記ゲームデータ記憶部に書き込む書き込み部と、
    前記ユーザデータを前記ゲームデータ記憶部から読み出して前記ゲーム装置に送信するロード処理、及び、前記ゲーム結果データを前記ゲーム装置から受信して前記ゲームデータ記憶部に書き込むセーブ処理の少なくとも一方に対して、前記ゲーム装置でプレイするプレーヤへの課金処理を行う課金処理部として、
    コンピュータを機能させ、
    前記送信部は、
    前記ロード処理の際に、前記ユーザデータと、前記ユーザデータに関連づけられた課金セッション識別情報とを、前記ゲーム装置に送信し、
    前記受信部は、
    前記セーブ処理の際に、前記ゲーム結果データと、前記ゲーム結果データに関連づけられた前記課金セッション識別情報とを、前記ゲーム装置から受信し、
    前記課金処理部は、
    受信した前記課金セッション識別情報を用いて、課金処理を行い、
    前記課金処理部は、
    前記ロード処理及び前記セーブ処理の少なくとも一方の回数である処理回数に対する課金レートを可変に変更する課金レート変更部を含むことを特徴とするプログラム。
15. ゲーム装置に通信接続されるサーバシステムのためのプログラムであって、
    ゲームデータを記憶するゲームデータ記憶部と、
    前記ゲーム装置でプレイするプレーヤのユーザデータを、前記ゲームデータ記憶部から読み出す読み出し部と、
    前記ユーザデータを、プレーヤのゲームプレイ開始前に前記ゲーム装置に送信する送信部と、
    前記ゲーム装置でのプレーヤのゲーム結果データを、プレーヤのゲームプレイ終了後に前記ゲーム装置から受信する受信部と、
    受信された前記ゲーム結果データを前記ゲームデータ記憶部に書き込む書き込み部と、
    前記ゲーム装置でプレイするプレーヤへの課金処理を行う課金処理部として、
    コンピュータを機能させ、
    前記送信部は、
    前記ユーザデータを前記ゲームデータ記憶部から読み出して前記ゲーム装置に送信するロード処理の際に、前記ユーザデータと、前記ユーザデータに関連づけられた課金セッション識別情報とを、前記ゲーム装置に送信し、
    前記受信部は、
    前記ゲーム結果データを前記ゲーム装置から受信して前記ゲームデータ記憶部に書き込むセーブ処理の際に、前記ゲーム結果データと、前記ゲーム結果データに関連づけられた前記課金セッション識別情報とを、前記ゲーム装置から受信し、
    前記課金処理部は、
    受信した前記課金セッション識別情報を用いて、前記ゲーム装置でプレイするプレーヤへの課金処理を行い、
    前記ゲーム装置は、
    前記サーバシステムから送信される前記課金セッション識別情報の受信に失敗した場合には、前記セーブ処理の際に、前記ゲーム結果データに関連づけて仮課金セッション識別情報を前記サーバシステムに送信し、
    前記課金処理部は、
    前記仮課金セッション識別情報を受信した場合には、課金開始と課金終了が同時に行われたと見なして、新たな課金セッション識別情報を生成し、生成された新たな課金セッション識別情報に基づいて、課金処理を行うことを特徴とするプログラム。
16. ゲーム装置に通信接続されるサーバシステムのためのプログラムであって、
    ゲームデータを記憶するゲームデータ記憶部と、
    前記ゲーム装置でプレイするプレーヤのユーザデータを、前記ゲームデータ記憶部から読み出す読み出し部と、
    前記ユーザデータを、プレーヤのゲームプレイ開始前に前記ゲーム装置に送信する送信部と、
    前記ゲーム装置でのプレーヤのゲーム結果データを、プレーヤのゲームプレイ終了後に前記ゲーム装置から受信する受信部と、
    受信された前記ゲーム結果データを前記ゲームデータ記憶部に書き込む書き込み部と、
    前記ゲーム装置でプレイするプレーヤへの課金処理を行う課金処理部として、
    コンピュータを機能させ、
    前記送信部は、
    前記ユーザデータを前記ゲームデータ記憶部から読み出して前記ゲーム装置に送信するロード処理の際に、前記ユーザデータと、前記ユーザデータに関連づけられた課金セッション識別情報とを、前記ゲーム装置に送信し、
    前記受信部は、
    前記ゲーム結果データを前記ゲーム装置から受信して前記ゲームデータ記憶部に書き込むセーブ処理の際に、前記ゲーム結果データと、前記ゲーム結果データに関連づけられた前記課金セッション識別情報とを、前記ゲーム装置から受信し、
    前記課金処理部は、
    受信した前記課金セッション識別情報を用いて、前記ゲーム装置でプレイするプレーヤへの課金処理を行い、
    前記課金処理部は、
    前記ロード処理の時間及び前記セーブ処理の時間の少なくとも一方を含む課金情報を、前記課金セッション識別情報に関連づけて、
    前記ゲーム装置でプレイするプレーヤへの課金のための課金データとして、前記課金セッション識別情報と、前記課金セッション識別情報に関連づけられた前記課金情報とを含む課金セッションデータを作成することを特徴とするプログラム。

Images