JP2020162988A - ゲームシステム - Google Patents

Abstract

【課題】柔軟にゲーム内通貨を利用したサービスを実現することが可能なゲームシステム等を提供すること。【解決手段】ゲームシステムは、ゲーム内通貨の増加量を定めた増加要求を受け付けた場合に、残高を当該増加量だけ増加させる増加部と、ゲーム内通貨の減少量を定めた減少要求を受け付けた場合に、残高を当該減少量だけ減少させる減少部と、増加部及び減少部によって変更された残高を０以上の値から０未満の値までの範囲でユーザの識別情報に関連付けて管理する管理部とを含み、減少部は、残高よりも多い減少量を定めた減少要求を受け付けた場合に、当該残高を０未満の値に変更する。【選択図】図５

Description

本発明は、ゲームシステムに関する。

従来、ユーザが保有しているゲーム内通貨の残高を管理し、ユーザがゲーム内通貨を消費することで、ゲーム自体をプレイしたり、ゲーム内アイテムを入手したりできるゲームシステムが知られている（例えば、特許文献１）。

特開２０１５−１５９９７６号公報

しかし、従来のゲームシステムでは、ユーザが保有するゲーム内通貨の残高を０以上の値で管理していた。すなわち、ユーザが保有するゲーム内通貨の残高が十分に残っているか否かで、ユーザがゲームをプレイ可能か否か、ゲーム内アイテムを入手可能か否かが決まっていた。このため、ユーザは柔軟にゲーム内通貨を利用したサービスを受けることができなかったし、サービス提供者にとっても柔軟にゲーム内通貨を利用したサービスをユーザに提供することができなかった。例えば、ユーザがゲームをプレイしたい気持ちになった時にゲーム内通貨の残高が不足していると、ユーザはゲームをプレイする前に、ゲーム内通貨を補充して残高を増やす必要がある。このゲーム内通貨を補充するという行為に対してユーザが煩わしさを感じてしまうと、ユーザのゲームのプレイに対する意欲が低下してしまう可能性があった。

本発明は、以上のような課題に鑑みてなされたものであり、その目的とするところは、柔軟にゲーム内通貨を利用したサービスを実現することが可能なゲームシステムを提供することにある。

（１）本発明は、ゲームの実行又はゲーム内アイテムの購入のために消費されるゲーム内通貨の残高をユーザの識別情報に関連付けて管理するゲームシステムであって、前記ゲーム内通貨の増加量を定めた増加要求を受け付けた場合に、前記残高を当該増加量だけ増加させる増加部と、前記ゲーム内通貨の減少量を定めた減少要求を受け付けた場合に、前記残高を当該減少量だけ減少させる減少部と、前記増加部及び前記減少部によって変更された前記残高を０以上の値から０未満の値までの範囲で前記ユーザの識別情報に関連付けて管理する管理部とを含み、前記減少部は、前記残高よりも多い前記減少量を定めた減少要求を受け付けた場合に、当該残高を０未満の値に変更することを特徴するゲームシステムに関する。

本発明によれば、ゲーム内通貨の残高が０以上の値から０未満の値までの範囲で管理され、残高よりも多い減少量を定めた減少要求を受け付けた場合に、残高が０未満の値に変更されるため、ゲーム内通貨の残高が不足していてもゲームのプレイやゲーム内アイテムの入手が可能となり、柔軟にゲーム内通貨を利用したサービスを実現することができる。

（２）また本発明に係るゲームシステムでは、前記増加部は、ユーザが指定した増加量を定めた増加要求を受け付けた場合に、当該増加量に対応する金額の決済要求を課金サー
バに送信し、当該決済要求に応じて課金サーバにおいて当該金額が決済された場合に、前記残高を当該増加量だけ増加させてもよい。

本発明によれば、ユーザが購入したゲーム内通貨を柔軟に利用したサービスを実現することができる。

（３）また本発明に係るゲームシステムでは、前記管理部は、前記残高を、０以上の値の第１パラメータと０以下の値の第２パラメータとの合算値で管理し、前記増加部は、前記ゲーム内通貨の増加量を定めた増加要求を受け付けた場合に、前記第１パラメータを当該増加量だけ増加させてもよい。

本発明によれば、ユーザが増加量を指定して増加要求を行ったときに、ゲーム内通貨の残高が０未満の値であったとしても、第１パラメータが当該増加量だけ増加するため、ユーザは、ゲーム内通貨の残高が指定した増加量だけ増加したことを容易に認識することができる。

（４）また本発明に係るゲームシステムでは、前記第１パラメータと前記第２パラメータとを区別してユーザの端末の表示部に表示させる表示制御部を更に含んでもよい。

本発明によれば、第１パラメータと第２パラメータとを区別して表示させることで、ユーザは、ゲーム内通貨の残高が指定した増加量だけ増加したことを容易に認識することができる。

（５）また本発明に係るゲームシステムでは、前記管理部は、ユーザの過去のゲーム利用歴が所与の信頼条件を満たすか否かを判定し、前記信頼条件を満たすユーザの前記残高を０未満の値に変更可能にし、前記信頼条件を満たさないユーザの前記残高を０未満の値に変更不能にしてもよい。

本発明によれば、信頼条件を満たすユーザに対して、柔軟にゲーム内通貨を利用したサービスを提供することができる。

（６）また本発明に係るゲームシステムでは、ユーザに対して所与の制限を与える制限部を更に含み、前記制限部は、ユーザの過去のゲーム利用歴が所与の信頼条件を満たすか否かを判定し、前記信頼条件を満たすユーザに与える前記制限を緩和してもよい。

（７）また本発明に係るゲームシステムでは、ユーザの前記残高が０未満の値になった場合に、当該ユーザに対して所与の制限を与える制限部を更に含んでもよい。

本発明によれば、０未満の値になったゲーム内通貨の残高を０以上の値に増加させることをユーザに促すことができる。

（８）また本発明に係るゲームシステムでは、前記制限部は、ユーザの過去のゲーム利用歴に基づく信頼度が高いほど、当該ユーザに与える前記制限を緩和してもよい。

本発明によれば、信頼度の低いユーザに対して、０未満の値になったゲーム内通貨の残高を０以上の値に増加させることを促すことができる。

（９）また本発明に係るゲームシステムでは、前記制限部は、ユーザによる前記ゲーム内通貨の消費に関する制限を与えてもよい。

本発明によれば、０未満の値になったゲーム内通貨の残高を０以上の値に増加させることをユーザに促すことができる。

（１０）また本発明に係るゲームシステムでは、前記制限部は、ゲーム進行上不利になる制限を与えてもよい。

本発明によれば、０未満の値になったゲーム内通貨の残高を０以上の値に増加させることをユーザに促すことができる。

（１１）また本発明に係るゲームシステムでは、前記ゲーム内通貨には、有償のゲーム内通貨と、無償のゲーム内通貨があり、前記制限部は、ユーザに与える前記制限として、当該ユーザに対する前記無償のゲーム内通貨の付与を停止してもよい。

本発明によれば、０未満の値になったゲーム内通貨の残高を０以上の値に増加させることをユーザに促すことができる。

（１２）また本発明に係るゲームシステムでは、前記制限部は、ユーザの前記残高が０以上の値になるまで当該ユーザに対して前記制限を与えてもよい。

本発明によれば、０未満の値になったゲーム内通貨の残高を０以上の値に増加させることをユーザに促すことができる。

（１３）また本発明に係るゲームシステムでは、前記制限部は、ユーザの前記残高が０未満の値になった後、所定期間が経過した後に当該残高が０以上の値になっていない場合に、当該ユーザに対して前記制限を与えてもよい。

本発明によれば、０未満の値になったゲーム内通貨の残高を０以上の値に増加させることをユーザに促すことができる。

（１４）また本発明に係るゲームシステムでは、前記管理部は、０未満の値になった前記残高を、他のゲームで管理される前記残高として引き継いでもよい。

本発明によれば、０未満の値になったゲーム内通貨の残高を０以上の値に増加させることをユーザに促すことができる。

（１５）また本発明に係るゲームシステムでは、前記管理部は、ユーザに与える前記制限を、前記他のゲームにおいて当該ユーザに与える前記制限として引き継いでもよい。

本発明によれば、０未満の値になったゲーム内通貨の残高を０以上の値に増加させることをユーザに促すことができる。

（１６）また本発明に係るゲームシステムでは、前記管理部は、所与の条件が満たされた場合に、前記残高の引き継ぎを行ってもよい。

本発明によれば、所与の条件下で、０未満の値になったゲーム内通貨の残高を０以上の値に増加させることをユーザに促すことができる。

本実施形態のゲームシステムを示す図。 本実施形態のゲームサーバの機能ブロック図の一例を示す図。 本実施形態の端末の機能ブロック図の一例を示す図。 ゲーム内通貨の残高を管理するためのテーブル情報の一例を示す図。 本実施形態のゲームシステムの処理の流れを示すフローチャート。

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

１．構成
図１は、本実施形態のゲームシステムを示す。本実施形態では、複数の端末１０とゲームサーバ２０（サーバシステム）と課金サーバ３０によって構成される。つまり、図１に示すように、本実施形態のゲームシステムは、ゲームサービスを提供するゲームサーバ２０と、課金額の決済を行う課金サーバ３０と、端末１０（１０Ａ、１０Ｂ、１０Ｃ・・・）とが、ネットワークに接続可能に構成される。

ゲームサーバ２０は、端末１０からの要求に応じてオンラインゲームサービスを提供する情報処理装置である。ゲームサーバ２０は、１又は複数のサーバ（認証サーバ、マッチングサーバ、ゲーム処理サーバ、通信サーバ、データベースサーバ等）により構成することができる。課金サーバ３０は、ゲームサーバ２０からの要求に応じて決済サービスを提供する情報処理装置である。なお、課金サーバ３０は、クレジットカード会社や他の決済系サーバと通信するものであってもよい。

本実施形態では、端末１０においてゲームプログラムが実行され、ゲームサーバ２０では、ユーザのアカウント情報や、端末１０で実行されるゲームのゲーム結果、当該ゲームで使用可能なゲーム内アイテム（キャラクタ（仮想的なカード）、アイテムなどのゲーム媒体）やゲーム内通貨（ゲームの実行又はゲーム内アイテムの購入のために消費される仮想的な通貨）などの情報が管理される。ここで、「ゲーム」とは、一般的にゲームと呼ばれる、アクションゲームやＲＰＧ、パズルゲーム、リズムゲーム、シューティングゲーム、スポーツゲーム、育成ゲーム、シミュレーションゲームなどを含むほか、仮想空間内で仮想的なキャラクタ（仮想キャラクタ）とコミュニケーションをとったり（会話やコメントを送る）、仮想キャラクタに対してプレゼントや評価（「いいね」等）をあげたりするものや、動画配信サービスにおいて、視聴者が動画配信者とコミュニケーションをとったり、動画配信者に対してプレゼントや評価をあげたりするものや、現実世界で行われているコンサートやイベントなどにおいて、ゲストが端末（スマートフォンやＰＣなど）を使用して、コンサートやイベントに対するリアクションを行うものも含む。また、「ゲームの実行」は、コミュニケーションをとるために、ゲーム内通貨を消費して、仮想キャラクタや動画配信者、イベントやコンサートの演者等に、コメントや評価を送ることも含む。また、「ゲーム内アイテム」は、ユーザが仮想空間内で使用するアバター、仮想キャラクタへのプレゼント（投げ銭や花束、仮想キャラクタの衣装など）、仮想空間の背景物や照明を変更するために使用されるアイテム、コンサートやイベントの内容（コンサートの照明など）を変更するために使用されるアイテムなどを含む。

端末１０は、携帯端末（スマートフォン、携帯電話、携帯型ゲーム機等）、パーソナルコンピュータ（ＰＣ）、ゲーム装置、画像生成装置などの情報処理装置であり、インターネット（ＷＡＮ）、ＬＡＮなどのネットワークを介してサーバ（ゲームサーバ２０、課金サーバ３０）に接続可能な装置である。なお、端末１０とサーバとの通信回線は、有線でもよいし無線でもよい。

図２に、本実施形態のゲームサーバ２０の機能ブロック図の一例を示す。なお本実施形
態のゲームサーバは図２の構成要素（各部）の一部を省略した構成としてもよい。

記憶部２７０は、処理部２００の各部としてコンピュータを機能させるためのプログラムや各種データを記憶するとともに、処理部２００のワーク領域として機能し、その機能はハードディスク、ＲＡＭなどにより実現できる。記憶部２７０は、格納部２７２（例えばデータベース）を含む。

格納部２７２は、本実施形態のゲームシステムで実行されるオンラインゲームに参加する複数のユーザそれぞれのユーザ情報を格納する。例えば、格納部２７２は、複数のユーザそれぞれのユーザ識別情報（ユーザＩＤや、ユーザが使用する端末ＩＤなど）に対応づけて、ユーザ名（ユーザアカウント）、パスワード、端末１０の宛先情報（ＩＰアドレス等）などを、ユーザ情報として格納する。また、格納部２７２は、ユーザとフレンド関係（所定の関係の一例）にある他のユーザを特定するための情報を、ユーザ情報として格納する。また、格納部２７２は、ユーザ識別情報に対応づけて、ユーザが保有するゲーム内アイテム（ゲーム媒体）やゲーム内通貨等や、ユーザのゲームのプレイ結果を、ユーザ情報として格納する。

通信部２９６は端末１０や課金サーバ３０との間で通信を行うための各種制御を行うものであり、その機能は、各種プロセッサ又は通信用ＡＳＩＣなどのハードウェアや、プログラムなどにより実現できる。

処理部２００（プロセッサ）は、端末１０から送信され通信部２９６を介して受信したデータ、プログラムなどに基づいて、ユーザ情報の管理、ログイン／ログアウトに関する処理、通信制御処理などの各種処理を行う。処理部２００は記憶部２７０をワーク領域として各種処理を行う。処理部２００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ等）、ＡＳＩＣ（ゲートアレイ等）などのハードウェアや、プログラムにより実現できる。処理部２００は、増加部２１０、減少部２１２、管理部２１４、表示制御部２１６を含む。

増加部２１０は、ゲーム内通貨の増加量を定めた増加要求を受け付けた場合に、ゲーム内通貨の残高を当該増加量だけ増加させる。ゲーム内通貨は、複数種類あってもよく、有償のゲーム内通貨（ユーザが決済サービスを利用して購入するゲーム内通貨）と、無償のゲーム内通貨があってもよいし、有償のゲーム内通貨が複数種類あってもよい。無償のゲーム内通貨とは、例えば、ログイン時にログインボーナスとしてユーザに付与されるゲーム内通貨や、ゲーム結果（クエストのクリアやバトルでの勝利など）に応じた特典としてユーザに付与されるゲーム内通貨である。有償のゲーム内通貨の残高を増加させる場合、増加部２１０は、ユーザが指定した増加量を定めた増加要求を受け付けた場合に、当該増加量に対応する金額の決済要求を課金サーバ３０に送信し、当該決済要求に応じて課金サーバ３０において当該金額が決済された場合に、当該ユーザのゲーム内通貨の残高を当該増加量だけ増加させる。なお、ユーザが増加量を指定するとは、ユーザが増加量を数値で入力して指定することであってもよいし、ゲーム運営側等が予め増加量の選択肢として「１，０００」、「２，０００」等を定めておき、ユーザがそれらの選択肢から増加量を選択して指定することであってもよい。また、ユーザがゲーム内通貨そのものの増加量を直接指定するのではなく、ユーザが金額のみを指定することで、その金額に対応する増加量を間接的に指定するようにしてもよい。なお、無償のゲーム内通貨の場合は、増加量はゲーム運営側等によって指定される。また、有償のゲーム内通貨を月額制で増加させてもよい。月額制の場合、例えばユーザが各月「５，０００」という増加量を一度指定すると、その後は、毎月の決まったタイミングで増加量「５，０００」を定めた増加要求が受け付けられ、課金サーバ３０での課金処理（決済処理）が行われて、当該ユーザのゲーム内通貨の残高が増加する。この場合、月額サービスの加入時点でユーザが増加量を指定するが、その後は、自動的に増加量が指定されて増加要求が受け付けられることになる。この場
合、毎月、ユーザの端末１０から増加要求が送信されるようにしてもよいし、月額サービスの加入中は、サーバ（ゲームサーバ２０、後述するＰＦサーバ、課金サーバ３０）が、毎月決まったタイミングで自動的に増加要求を生成したり送信したりするようにしてもよい。また、最初に料金を一括で支払った後に分割してゲーム内通貨の残高を増加させてもよい。例えば、ユーザの端末１０から「１０，０００」という増加量を定めた増加要求を受け付けた場合に、すぐに増加量「１０，０００」だけゲーム内通貨の残高を増加させるのではなく、毎月決まったタイミングで「２００」ずつゲーム内通貨の残高を増加させる。この場合、増加量「１０，０００」に対応する金額の決済要求を課金サーバ３０に送信して決済を行い、その後、課金サーバ３０を介さずに、「２００」という増加量を定めた増加要求を毎月決まったタイミングで生成・送信して、ユーザのゲーム内通貨の残高が「２００」ずつ増加するようにしてもよい。なお、有償のゲーム内通貨と無償のゲーム内通貨の両方が存在する場合、増加部２１０は、ユーザが有償のゲーム内通貨を購入した場合のみ、当該ユーザの有償のゲーム内通貨の残高を増加させ、ユーザに無償のゲーム内通貨が付与された場合のみ、当該ユーザの無償のゲーム内通貨の残高を増加させるようにし、ユーザが有償のゲーム内通貨を購入した場合に当該ユーザの無償のゲーム内通貨の残高を増加させたり、ユーザに無償のゲーム内通貨が付与された場合に当該ユーザの有償のゲーム内通貨の残高を増加させたりしないようにしてもよい。

減少部２１２は、ゲーム内通貨の減少量を定めた減少要求を受け付けた場合に、ゲーム内通貨の残高を当該減少量だけ減少させる。ゲーム内通貨が複数種類ある場合、減少部２１２が、ある種類のゲーム内通貨の残高を減少させて、増加部２１０が、その減少量だけ別の種類のゲーム内通貨（例えば、残高が０未満の値になっているゲーム内通貨）の残高を増加させてもよい。また、減少部２１２が、無償のゲーム内通貨の残高を減少させて、増加部２１０が、その減少量だけ有償のゲーム内通貨の残高を増加させてもよいし、減少部２１２が、有償のゲーム内通貨の残高を減少させて、増加部２１０が、その減少量だけ無償のゲーム内通貨の残高を増加させてもよい。なお、減少量は、ゲーム運営者側が定めてもよい（例えば、ガシャ１回につきゲーム内通貨を「２００」消費など）。また、ユーザが減少量を指定するようにしてもよい。

管理部２１４は、増加部２１０及び減少部２１２によって変更された前記残高を、０以上の値から０未満の値までの範囲で、ユーザの識別情報に関連付けて管理する。減少部２１２は、前記残高よりも多い減少量を定めた減少要求を受け付けた場合に、当該残高を０未満の値に変更する。また、管理部２１４は、前記残高を、０以上の値の第１パラメータと０以下の値の第２パラメータとの合算値で管理してもよい。この場合、増加部２１０は、増加量を定めた増加要求を受け付けた場合に、第１パラメータを当該増加量だけ増加させてもよい。また、管理部２１４は、ユーザの過去のゲーム利用歴が所与の信頼条件を満たすか否かを判定し、信頼条件を満たすユーザの前記残高を０未満の値に変更可能にし、信頼条件を満たさないユーザの前記残高を０未満の値に変更不能にしてもよい。

表示制御部２１６は、ユーザのゲーム内通貨の残高を当該ユーザの端末１０の表示部に表示させる制御を行う。管理部２１４が、第１パラメータと第２パラメータとの合算値で前記残高を管理する場合、表示制御部２１６は、第１パラメータと第２パラメータとを区別してユーザの端末１０の表示部に表示させてもよい。

処理部２００は、制限部２１８を更に含んでいてもよい。制限部２１８は、ユーザに対して所与の制限（例えば、ゲーム内通貨の消費に関する制限、ゲーム進行上不利になる制限、無償のゲーム内通貨の付与に関する制限）を与える。制限部２１８は、ユーザの前記残高が０未満の値になった場合に、当該ユーザの前記残高が０以上の値になるまで当該ユーザに対して制限を与えてもよい。また、制限部２１８は、ユーザの前記残高が０未満の値になった後、所定期間（所定の時間、日数、月数、年数など）が経過した後に当該残高
が０以上の値になっていない場合に、当該ユーザに対して制限を与えもよい。例えば、ユーザの前記残高が０未満の値になってから、２４時間後に当該残高が０以上の値になっていない場合や、１か月後に当該残高が０以上の値になっていない場合に、当該ユーザに対して制限を与えてもよい。また、前記残高が０未満の値になった時点から所定の制限判定時点までを所定期間としてもよい。例えば、前記残高が０未満の値になった時点から同日の２４時（所定の制限判定時点）までに当該残高が０以上の値になっていない場合に制限を与えるようにしてもよい。すなわち、どの時点で前記残高が０未満の値になったかに応じて所定期間の長さが変わるようにしてもよい。また、制限部２１８は、ユーザの過去のゲーム利用歴が所与の信頼条件を満たすか否かを判定し、信頼条件を満たすユーザに与える制限を緩和してもよい。また、制限部２１８は、ユーザの過去のゲーム利用歴に基づく信頼度が高いほど、当該ユーザに与える前記制限を緩和してもよい。

また、管理部２１４は、ユーザのゲーム内通貨の残高を、当該ユーザがプレイするゲーム（例えば、ユーザの端末１０にインストールされているゲームアプリ）毎に管理し、所与の条件が満たされた場合に、所与のゲームにおいて０未満の値になった前記残高を、他のゲームで管理される前記残高として引き継いてもよい。この場合、管理部２１４は、所与のゲームにおいてユーザに与える制限を、他のゲームにおいて当該ユーザに与える制限として引き継いでもよい。

図３に、本実施形態の端末１０の機能ブロック図の一例を示す。なお本実施形態の端末は図３の構成要素（各部）の一部を省略した構成としてもよい。

入力部１５０は、ユーザからの入力情報を入力（検出）するための機器であり、ユーザの入力情報（操作入力）を処理部１００に出力する。入力部１５０の機能は、タッチパネル、タッチパッド、マウス、方向キーやボタン、キーボード等の入力機器により実現することができる。

記憶部１７０は、処理部１００の各部としてコンピュータを機能させるためのプログラムや各種データを記憶するとともに、処理部１００のワーク領域として機能し、その機能はハードディスク、ＲＡＭなどにより実現できる。

表示部１９０は、処理部１００で生成されたゲーム画像を出力するものであり、その機能は、入力部１５０としても機能するタッチパネル、ＬＣＤ或いはＨＭＤ（ヘッドマウントディスプレイ）などのディスプレイにより実現できる。

音出力部１９２は、処理部１００で生成された音を出力するものであり、その機能は、スピーカ、或いはヘッドフォンなどにより実現できる。

通信部１９６はゲームサーバ２０や課金サーバ３０、他の端末１０との間で通信を行うための各種制御を行うものであり、その機能は、各種プロセッサ又は通信用ＡＳＩＣなどのハードウェアや、プログラムなどにより実現できる。

なお、ゲームサーバ２０が有する情報記憶媒体や記憶部に記憶されている処理部１００の各部としてコンピュータを機能させるためのプログラムや各種データを、ネットワークを介して受信し、受信したプログラムやデータを記憶部１７０に記憶してもよい。このようにプログラムや各種データを受信して端末を機能させる場合も本発明の範囲内に含む。

処理部１００（プロセッサ）は、入力部１５０からの入力情報（操作情報）、プログラム、通信部１９６を介して受信したデータなどに基づいて、ゲーム処理、画像生成処理、音生成処理、などの処理を行う。処理部１００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ
等）、ＡＳＩＣ（ゲートアレイ等）などのハードウェアや、プログラムにより実現できる。処理部１００は、ゲーム処理部１１０、画像生成部１２０、音生成部１３０を含む。

ゲーム処理部１１０は、入力部１５０からの入力情報や、ゲームサーバ２０から受信した情報に基づいて、ゲーム内アイテムを使用したゲーム（例えば、ゲーム内アイテムであるキャラクタをプレーヤキャラクタとしてゲームに登場させるゲーム）を進行させる処理を行う。

画像生成部１２０は、処理部１００で行われる種々の処理の結果に基づいて描画処理を行い、これによりゲーム画像を生成し、表示部１９０に出力する。画像生成部１２０は、オブジェクト空間（ゲーム空間）内において仮想カメラ（所与の視点）から見える画像（いわゆる３次元画像）を生成してもよい。

音生成部１３０は、処理部１００で行われる種々の処理の結果に基づいて音処理を行い、ＢＧＭ、効果音、又は音声などのゲーム音を生成し、音出力部１９２に出力する。

また処理部１００は、ゲームを開始した場合には、ゲームを開始したことを通知するための情報をゲームサーバ２０に送信し、ゲームが終了した場合には、ゲーム結果や各種ゲームパラメータに関するゲーム結果情報（ユーザが保有するゲーム内アイテムに関する情報、ユーザが保有するゲーム内通貨に関する情報、ゲームのプレイ結果）をゲームサーバ２０に送信する。ゲームサーバ２０は、ゲーム装置（端末１０）から送信された、ゲーム結果情報に基づいて、各ユーザに対応付けられた各種データの更新処理を行う。なお、端末１０側で生成したゲーム結果情報をゲームサーバ２０に送信する例に限らず、ゲーム実行中に端末１０からゲームサーバ２０に順次送信される各種の情報に基づいて、ゲームサーバ２０側でゲーム結果情報を生成するようにしてもよい。また、ゲームが終了したか否かも、端末１０側で判断してもよいし、ゲームサーバ２０側で判断してもよい。

また、ゲームシステムを、端末１０と、ゲームサーバ２０により構成してもよい。この場合、ゲームサーバ２０が、課金サーバ３０の機能を有する。また、ゲームシステムを、端末１０と、課金サーバ３０により構成してもよい。この場合、課金サーバ３０が、ゲームサーバ２０の機能を有する。また、ゲームシステムを、端末１０と、ゲームサーバ２０と、ユーザ情報（ユーザの個人情報、ユーザがプレイする各ゲームの情報、各ゲーム内のフレンド情報など）を管理するプラットフォームサーバ（ＰＦサーバ）と、課金サーバ３０により構成してもよい。この場合、ゲームサーバ２０から課金サーバ３０に決済要求を送信するようにしてもよいし、ＰＦサーバから課金サーバ３０に決済要求を送信するようにしてもよい。また、ゲームシステムを、端末１０と、ゲームサーバ２０と、ＰＦサーバにより構成してもよい。この場合、ＰＦサーバが、課金サーバ３０の機能を有する。また、ゲームシステムを、端末１０と、ＰＦサーバと、課金サーバ３０により構成してもよい。この場合、ＰＦサーバが、ゲームサーバ２０の機能を有する。また、ゲームシステムを、端末１０と、ＰＦサーバにより構成してもよい。この場合、ＰＦサーバが、ゲームサーバ２０の機能と、課金サーバ３０の機能を有する。端末１０側だけでゲームを実行できる場合、ゲームサーバ２０は無くてもよい。また、基本的には端末１０側だけでゲームを実行し、ゲームサーバ２０が一部のゲーム（オンライン要素が必要なゲーム）のみを実行するようにしてもよい。端末１０は、ゲームサーバ２０やＰＦサーバに直接アクセスできるようにしてもよい。端末１０、ゲームサーバ２０、ＰＦサーバなどは、課金サーバ３０から、有償のゲーム内通貨の購入に関する決済の成否を受け取る。また、端末１０、ゲームサーバ２０、ＰＦサーバなどは、課金サーバ３０から、ユーザの返金要請に関する情報（返金処理の進捗、返金の可否、返金額、返金の対象となった有償のゲーム内通貨の量）を受け取るようにしてもよい。また、これら決済や返金に関する情報は、そのまま或いは必要に応じて加工して、ネットワーク経由ではなく、直接ゲームサーバ２０やＰＦサーバに
手入力して使用するようにしてもよい。また、ゲーム内通貨の残高は、端末１０、ゲームサーバ２０、ＰＦサーバ、課金サーバ３０のいずれかで管理していればよい。すなわち、増加部２１０、減少部２１２、管理部２１４、表示制御部２１６、制限部２１８の機能は、端末１０、ゲームサーバ２０、ＰＦサーバ、課金サーバ３０のいずれかが有していればよい。また、異なるサーバ（例えば、ゲームサーバ２０とＰＦサーバ）でゲーム内通貨の残高を管理するようにしてもよい。この場合、各サーバで共通のゲーム内通貨の残高を管理するようにしてもよいし、各サーバで異なる種類のゲーム内通貨の残高を管理するようにしてもよい。また、この場合、それぞれのゲーム内通貨が別々に消費されるようにしてもよいし、それぞれのゲーム内通貨の残高を合算したものが消費するようにしてもよいし、特定の種類のゲーム内通貨を優先的に消費するようにしてもよい。

２．本実施形態の手法
次に本実施形態の手法について図面を用いて説明する。

本実施形態のゲームシステムでは、ユーザが保有するゲーム内通貨（有償の或いは無償のゲーム内通貨）を消費して、ゲームをプレイしたりゲーム内アイテム（ゲーム内で使用可能なキャラクタやアイテム等）を入手（購入）したりすることができる仕組みが提供される。

図４は、ユーザが保有するゲーム内通貨の残高を管理するためのテーブル情報の一例を示す図である。このテーブル情報は、格納部２７２に格納される。テーブル情報３００は、ユーザのユーザＩＤ３１０（ユーザの識別情報）に関連付けて、当該ユーザのゲーム内通貨の残高３２０と、当該ユーザのゲーム利用歴３５０とを格納する。図４に示す例は、ユーザＩＤ「００１」のユーザのゲーム内通貨の残高３２０が「１，０００」であり、ユーザＩＤ「００２」のユーザのゲーム内通貨の残高３２０が「−５００」であることを示している。

ユーザが、端末１０において有償のゲーム内通貨の購入を要求する操作を行うと、当該ユーザによって指定された増加量（購入量）を定めた増加要求がゲームサーバ２０の増加部２１０で受け付けられる。当該増加要求を受け付けた増加部２１０は、当該増加要求で定められた増加量に対応する金額の決済要求を課金サーバ３０に送信し、課金サーバ３０から、当該金額の決済が成立した旨の通知を受信した場合に、当該ユーザの残高３２０を当該増加量だけ増加させる。

また、ゲームサーバ２０（サービス提供者）からユーザに対してログインボーナスやゲーム結果に応じた特典として無償のゲーム内通貨が配布された場合、当該ユーザが端末１０において当該ゲーム内通貨の受け取りを指示する操作を行ったり、当該ユーザが端末１０からゲームサーバ２０にアクセス（ログイン）したりすると、増加量（配布量）を定めた増加要求が増加部２１０で受け付けられ、増加部２１０は、当該ユーザの残高３２０を当該増加要求で定められた増加量だけ増加させる。なお、ユーザがログインボーナスの受け取り操作やゲームへのアクセスを行うことで、増加要求が端末１０からゲームサーバ２０に送信されるようにしてもよいし、ゲームサーバ２０において、端末１０でログインボーナスの受け取り操作があったことやゲームへのアクセスがあったことが検出された場合に、ゲームサーバ２０内で増加要求を生成して、増加部２１０に出力するようにしてもよい。

また、ユーザが、端末１０において所与のゲームのプレイ（ガシャの実行を含む）を要求する操作を行うと、当該ゲームのプレイに必要なゲーム内通貨の量を減少量として定めた減少要求（端末１０からゲームサーバ２０に送信された減少要求、端末１０から受信した情報に応じてゲームサーバ２０内で生成した減少要求）が減少部２１２で受け付けられ
、減少部２１２は、当該ユーザの残高３２０を当該減少要求で定められた減少量だけ減少させる。また、ユーザが、端末１０においてゲーム内アイテムの購入を要求する操作を行うと、当該ゲーム内アイテムの購入に必要なゲーム内通貨の量を減少量として定めた減少要求が減少部２１２で受け付けられ、減少部２１２は、当該ユーザの残高３２０を当該減少要求で定められた減少量だけ減少させる。また、ユーザが未使用のゲーム内通貨の払い戻しを要請し、或いは、サービス終了によるユーザに対する未使用のゲーム内通貨の払い戻しが実施され、当該払い戻しに伴う返金が完了する（例えば、課金サーバ３０からの返金が完了した旨の通知をゲームサーバ２０が受け付ける）と、返金額に相当するゲーム内通貨の量を減少量として定めた減少要求（課金サーバ３０やＰＦサーバや外部の装置からゲームサーバ２０に送信された減少要求、課金サーバ３０やＰＦサーバや外部の装置から受信した情報に応じてゲームサーバ２０内で生成した減少要求）が減少部２１２で受け付けられ、減少部２１２は、当該ユーザの残高３２０を当該減少要求で定められた減少量だけ減少させる。

ここで、本実施形態では、残高３２０よりも多い減少量を定めた減少要求を受け付けた場合に、当該残高３２０を０未満の値に変更する。例えば、ゲーム内通貨の残高が「５００」であるときに、当該残高を減少量「１，０００」だけ減少させる場合、当該残高は「−５００」となる。なお、ゲーム内通貨の払い戻しによって残高３２０を減少させる場合のみ、残高３２０を０未満の値に変更できる（残高３２０よりも多い減少量を定めた減少要求を受け付ける）ようにし、ゲームのプレイ要求やゲーム内アイテムの購入要求によって残高３２０を減少させる場合には、残高３２０を０未満の値に変更できない（残高３２０よりも多い減少量を定めた減少要求を受け付けない）ようにしてもよい。また、無償のゲーム内通貨と有償のゲーム内通貨の両方がある場合に、有償のゲーム内通貨の残高のみ０未満の値に変更できるようにし、無償のゲーム内通貨の残高を０未満の値に変更できないようにしてもよい。また、ゲームサーバ２０と課金サーバ３０との通信が正常に行えない場合や課金サーバ３０から異常信号を受信した場合などに、ゲームサーバ２０は、課金サーバ３０が正常に決済処理を行えない状態にあると判定し、その場合に、ゲーム内通貨の残高を０未満の値に変更できるようにしてもよい。また、課金サーバ３０に限らず、課金によってゲーム内通貨を増加させるために必要な処理を行う装置が使用できない状態になっている場合に、ゲーム内通貨の残高を０未満の値に変更できるようにしてもよい。この場合、正常に動作できる装置だけでゲーム内通貨を減少させる処理やゲーム内通貨の管理を行えるようにしておく必要があり、例えば、減少部２１２や管理部２１４の機能を複数の装置のそれぞれに持たせておき、異常発生時は正常な装置で各種の処理を行い、異常の復旧後に、ゲーム内通貨の消費の履歴やゲーム内通貨の量などの、異常中に発生したゲームデータに関する変化を装置間で整合させるようにする。また、期間限定のイベントゲームの実行のためにゲーム内通貨を消費する場合や、期間限定のゲーム内アイテムの購入のためにゲーム内通貨を消費する場合に、当該期間の終了時間の付近（例えば、終了時間の１時間前）だけ、ゲーム内通貨の残高を０未満の値に変更できるようにしてもよい。

また、本実施形態では、図４に示すように、残高３２０を、０以上の値の第１パラメータ３３０と０以下の値の第２パラメータ３４０との合算値で管理してもよい。また、ユーザのゲーム内通貨の残高３２０を当該ユーザの端末１０の表示部１９０に表示させる際に、第１パラメータ３３０と第２パラメータ３４０とを区別して（識別可能に）表示させるようにしてもよい。この場合、ゲーム内通貨の増加量を定めた増加要求を受け付けた場合に、第２パラメータ３４０が０未満の値であっても、第１パラメータ３３０を当該増加量だけ増加させるようにしてもよい。例えば、図４に示す例において、ユーザＩＤ「００２」のユーザがゲーム内通貨を「１，０００」だけ購入し、当該ユーザの残高３２０を増加量「１，０００」だけ増加させる場合、当該ユーザの第１パラメータ３３０を「０」から「１，０００」に増加させ、第１パラメータ３３０（「１，０００」）と第２パラメータ３４０（「−５００」）の合算値である残高３２０を「５００」にする。このようにする
と、ユーザは、ゲーム内通貨の購入時に第１パラメータ３３０を確認することで、ゲーム内通貨の残高が確実に購入量（指定した増加量）だけ増加したことを容易に認識することができる。なお、ユーザの第１パラメータ３３０の値が０より大きく第２パラメータ３４０の値が０未満である場合に、当該ユーザの操作により、第１パラメータ３３０を指定した量だけ減少させ、第２パラメータ３４０を当該指定した量だけ増加させることができるようにしてもよい。また、ゲーム内通貨の減少量を定めた減少要求を受け付けた場合には、第１パラメータ３３０を当該減少量だけ減少させるようにしてもよいし、第２パラメータ３４０を当該減少量だけ減少させるようにしてもよい。また、ユーザのゲーム内通貨の残高３２０を当該ユーザの端末１０の表示部１９０に表示させる際に、当該残高３２０が０未満の値である場合に、当該残高３２０を赤文字等（残高３２０が０より大きい値であるときとは異なる表示態様）でそのまま表示させてもよいし、残高を「０」として赤文字等で表示させてもよい。また、無償のゲーム内通貨と有償のゲーム内通貨の両方がある場合に、無償のゲーム内通貨の残高と有償のゲーム内通貨の残高とを区別して表示させるようにしてもよい。また、増加要求によって、第１パラメータを増加させるのか、第２パラメータを増加させるのかを、ユーザが指定できるようにしてもよい。また、減少要求によって第１パラメータを減少させるのか、第２パラメータを減少させるのかを、ユーザが指定できるようにしてもよい。この場合、増加要求や減少要求自体に、どちらのパラメータを変更するかを示した増加先や減少先が含まれていてもよいし、増加要求や減少要求を受け付けた後に、ユーザ等の操作によって増加先や減少先を指定できるようにしてもよい。また、例えば「５，０００」という増加量の増加要求を受け付けた場合（ユーザがゲーム内通貨を「５，０００」だけ購入した場合）、第１パラメータを「２，０００」だけ増加させて、第２パラメータを「３，０００」だけ増加させるなど、ユーザ等が増加先や増加させる数量、配分などを指定できるようにしてもよい。同様に、減少要求を受け付けた場合、ユーザ等が減少先や減少量、配分などを指定できるようにしてもよい。この場合、必要に応じてユーザの端末１０に、ユーザが増加先（減少先）や配分などを指定するためのダイアログなどをゲーム画面などに表示させるようにすればよい。

また、本実施形態では、ユーザの過去のゲーム利用歴（ゲーム内通貨の増減履歴や、ゲームプレイ歴など）を、当該ユーザのユーザＩＤに関連付けてゲーム利用歴３５０として記憶しておき、当該ゲーム利用歴が所与の信頼条件を満たすか否かを判定し、信頼条件を満たすユーザのゲーム内通貨の残高を０未満の値に変更できる（残高よりも多い減少量を定めた減少要求を受け付ける）ようにし、信頼条件を満たさないユーザのゲーム内通貨の残高を０未満の値に変更できない（残高よりも多い減少量を定めた減少要求を受け付けない）ようにしてもよい。例えば、ユーザのゲーム内通貨の増減履歴を記憶しておき、ユーザのゲーム内通貨の残高が０未満の値となった回数が多く且つ当該残高が０未満の値となってから０以上の値になるまでにかかった時間が短い場合や、ユーザのゲーム内通貨の残高の履歴上の最低値が高い場合に、当該ユーザのゲーム利用歴が信頼条件を満たすと判断してもよい。また、ユーザのゲームプレイ歴が長い（ゲームのプレイを開始してから現時点までの経過時間が長い、ゲームのプレイ回数が多い）場合に、当該ユーザのゲーム利用歴が信頼条件を満たすと判断してもよい。

また、本実施形態では、ユーザのゲーム内通貨の残高が０未満の値になった場合に、当該ユーザに対して所与の制限を与えるようにしてもよい。この場合、ユーザのゲーム内通貨の残高を減少させる際に、当該減少によって残高が０未満の値になる場合には、その旨ユーザに通知する（表示部１９０に通知を表示させる）ようにしてもよい。なお、第１パラメータと第２パラメータの合算値（残高）が０未満の値になった場合に、制限を与えるようにしてもよい。この場合に、第１パラメータと第２パラメータとを区別して表示したり、どちらのパラメータを増加させるのかをユーザが指定できるようにすると、ユーザは、制限を受けないように第１パラメータを増加させて０以上の値にした後に、ゲーム内通貨を消費してゲーム内アイテムを購入するかを、各パラメータの値を確認しながら決定す
ることができる。例えば、第１パラメータが「０」、第２パラメータが「−５００」のときに、このままだと制限を受けてしまうので、第１パラメータを「１，０００」まで増加させる。その後、ゲーム内通貨を「６００」だけ消費する所望のアイテムＡとゲーム内通貨を「５００」だけ消費する所望のアイテムＢが登場した場合に、制限を回避するためにアイテムＢの方を選択するか、制限を受けることを許容してアイテムＡの方を選択するかを、新たな課金を行うことなく決定することができる。なお、第１パラメータと第２パラメータの合算値（残高）は０以上であるが、第２パラメータが０未満である場合に、制限を与えるようにしてもよい。例えば、第１パラメータが「２，０００」、第２パラメータが「−５００」である場合、合算した残高は０以上の値（「１，５００」）であるが、第２パラメータは０未満の値（「−５００」）であるため、制限を与える。この場合、制限を受けないようにするためには、ユーザの意思（操作）で、第１パラメータを「５００」だけ減算させて第２パラメータを「５００」だけ増加させて、第２パラメータの値を０にすればよい。このような制限がある場合において、パラメータごとに増加や減少を行えるようにすると、以下のようなことができる。例えば、ユーザが、第２のパラメータが「−２，０００」になり制限を受けた後、新たにゲーム内通貨を「１０，０００」だけ増加させる課金を行って、第１パラメータを「１０，０００」、第２パラメータを「−２，０００」にしたとする。この場合に、制限を受けるが、新たに課金をすることなく、目的のゲーム内アイテムを入手できるまで第１パラメータを消費することができ、目的のゲーム内アイテムを入手した後に第１パラメータが残っていれば、新たに課金を行うことなく、その余った分を第２パラメータを０以上の値にするために使用するという選択が行えるため、利便性が向上する。

所与の制限として、ユーザによるゲーム内通貨の消費に関する制限を与えるようにしてもよい。ゲーム内通貨の消費に関する制限として、ゲームのプレイ要求やゲーム内アイテムの購入要求によって残高を減少させる（ゲーム内通貨を消費する）場合に、ユーザのゲーム内通貨の残高が０以上の値であるときだけ残高を減少させることができる（プレイ要求や購入要求に基づく減少要求を受け付ける）ようにし、残高が０未満の値であるときには残高を減少させることができない（プレイ要求や購入要求に基づく減少要求を受け付けない）ようにしてもよい。また、ゲーム内通貨の消費に関する制限として、残高が０未満の値であるときに残高を減少させることができる期間を限定し、当該期間が過ぎると残高を０以上の値にしないと減少させることができないようにしてもよい。例えば、ユーザのゲーム内通貨の残高が１月に０未満の値になった場合、１月中は残高を減少させることができるが、２月になったら残高を０以上の値にしないと残高を減少させることができないようにしてもよい。また、ゲーム内通貨の消費に関する制限として、残高の０未満の値の下限値（例えば、「−１０，０００」）を設定し、残高を下限値未満の値まで減少させることができないようにしてもよい。

また、所与の制限として、ゲーム進行上不利になる制限を与えるようにしてもよい。例えば、ユーザのゲーム内通貨の残高が０未満の値になった場合に、当該ユーザのゲームプレイに必要なスタミナ値（時間経過で回復するパラメータ）の回復スピードを低下させてもよいし、スタミナ値の最大値を低下させてもよいし、当該ユーザのキャラクタの能力値を低下させてもよいし、当該ユーザがゲームにおいて強いキャラクタ（例えば、レア度が高いキャラクタ）を使用できなくなるようにしてもよいし、当該ユーザが一部のゲームしかプレイできなくなる（例えば、ガシャを実行できなくなる）ようにしてもよいし、当該ユーザにゲームステージが解放されなくなるようにしてもよいし、当該ユーザがマルチプレイを行えなくなるようにしてもよいし、当該ユーザをランキングの対象外とする等してもよい。また、ユーザのゲーム内通貨の消費によるゲーム内アイテムの獲得履歴を記憶しておき、ユーザがゲーム内アイテムを獲得するためにゲーム内通貨を消費した結果、残高が０未満の値になった場合に、そのときに獲得したゲーム内アイテムの使用を制限する（使用不可にする、使用可能期間や使用可能回数を限定する等）ようにしてもよい。また、
残高が０未満の値になった時点から所定期間遡った期間内に獲得されたゲーム内アイテムの使用を制限するようにしてもよい。

また、所与の制限として、無償のゲーム内通貨の付与に関する制限を与えるようにしてもよい。例えば、ユーザに対してログインボーナスや特典として無償のゲーム内通貨が付与（配布）される場合、ユーザのゲーム内通貨の残高が０未満の値になった場合に、当該ユーザに対する無償のゲーム内通貨の付与を停止したり配布量を少なくしたりしてもよい。

また、ユーザのゲーム内通貨の残高が０未満の値になってから当該残高が０以上の値になるまでの間、当該ユーザに所与の制限を与え、当該残高が０以上の値になった場合に当該制限を解除するようにしてもよい。また、ユーザのゲーム内通貨の残高が０未満の値になってから所定期間の間（当該残高が０以上の値になったか否かに依らず）当該ユーザに所与の制限を与えるようにし、当該所定期間の間に当該残高が０以上の値になった場合に、当該所定期間に続く次の期間において当該制限を解除するようにしてもよい。また、ユーザのゲーム内通貨の残高が０未満の値になってから所定期間の間は当該ユーザに所与の制限を与えずに、当該所定期間が経過した後に当該残高が０以上の値になっていない場合に、当該ユーザに所与の制限を与えるようにしてもよい。

また、ユーザの過去のゲーム利用歴（ゲーム内通貨の増減履歴、ゲームプレイ歴）を、当該ユーザのユーザＩＤに関連付けてゲーム利用歴３５０として記憶しておき、当該ゲーム利用歴が所与の信頼条件を満たすか否かを判定し、信頼条件を満たすユーザに与える所与の制限を緩和するようにしてもよい。例えば、ユーザのゲーム内通貨の増減履歴を記憶しておき、ユーザのゲーム内通貨の残高が０未満の値となった回数が多く且つ当該残高が０未満の値となってから０以上の値になるまでにかかった時間が短いほど、また、ユーザのゲーム内通貨の残高の履歴上の最低値が高いほど、信頼条件を満たすとして、ゲーム内通貨の消費に関する制限を緩和する（例えば、当該ユーザのゲーム内通貨の残高を０未満の値にできる期間を長くする、残高の０未満の値の下限値を低くする）ようにしてもよいし、ゲーム進行上不利になる制限を緩和する（例えば、スタミナ値の回復スピードや最大値を低下させる程度を低くする、ゲーム内アイテムの使用を制限する期間を短くする）ようにしてもよいし、無償のゲーム内通貨の付与に関する制限を緩和する（例えば、無償のゲーム内通貨の付与を停止する期間を短くする、配布量を低下させる程度を低くする）ようにしてもよい。また、ユーザのゲームプレイ歴が長いほど、信頼条件を満たすとして、ゲーム内通貨の消費に関する制限を緩和するようにしてもよいし、ゲーム進行上不利になる制限を緩和するようにしてもよいし、無償のゲーム内通貨の付与に関する制限を緩和するようにしてもよい。また、ユーザの過去のゲーム利用歴に基づく信頼度（例えば、ユーザのゲーム内通貨の残高が０未満の値となった回数が多く且つ当該残高が０未満の値となってから０以上の値になるまでにかかった時間が短いほど、ユーザのゲーム内通貨の残高の履歴上の最低値が高いほど、ゲームプレイ歴が長いほど、高くなる値）が高いほど、当該ユーザに与える制限を緩和するようにしてもよい。なお、信頼条件を満たさないと判断したユーザに与える所与の制限を強化する（より厳しくする）ようにしてもよい。また、信頼条件を満たすと判断したユーザに与える制限を、信頼条件を満たさないと判断したユーザに与える制限よりも緩和するようにし、信頼条件を満たすと判断したユーザに与える制限を一律に（同程度に）緩和するようにしてもよい。

また、ゲーム内通貨の払い戻しによって残高を減少させる場合のみ、残高が０未満の値になった場合に所与の制限をユーザに与え、ゲームのプレイ要求やゲーム内アイテムの購入要求によって残高を減少させる場合には、残高が０未満の値になった場合であっても所与の制限をユーザに与えないようにしてもよい。また、ゲーム内通貨の払い戻しによって残高を減少させる場合と、プレイ要求や購入要求によって残高を減少させる場合とで、残
高が０未満の値になった場合にユーザに与える所与の制限の種類を変えるようにしてもよい。例えば、ゲーム内通貨の払い戻しによって残高を減少させる場合の方が、プレイ要求や購入要求によって残高を減少させる場合よりも、残高が０未満の値になった場合にユーザに与える所与の制限を厳しくするようにしてもよい。また、残高が０未満の値になったか否かに依らずに、ユーザの所与の制限を与えるようにし、ユーザの過去のゲーム利用歴が信頼条件を満たすか否かを判定し、信頼条件を満たすユーザに与える所与の制限を緩和したり、ユーザの過去のゲーム利用歴に基づく信頼度（信頼の程度）が高いほど、当該ユーザに与える所与の制限を緩和したりしてもよい。

また、本実施形態では、ユーザのユーザＩＤ（ユーザやユーザの端末１０を識別するためのＩＤ）に関連付けて、当該ユーザがプレイする複数のゲームのそれぞれのゲームＩＤを管理し、各ゲームのゲームＩＤに関連付けて、各ゲームにおいてゲーム内通貨の残高を管理するためのテーブル情報３００を記憶するようにしてもよい。この場合、ユーザのユーザＩＤに関連するゲームＩＤに関連付けられたゲーム内通貨の残高が０未満の値である場合に、当該残高を、当該ユーザＩＤに関連する他のゲームＩＤに関連付けられたゲーム内通貨の残高として引き継ぐようにしてもよい。例えば、ユーザがプレイするゲーム「Ａ」で管理されるゲーム内通貨の残高が「−５００」であるときに、当該ユーザが他のゲーム「Ｂ」のプレイを始めた場合に、ゲーム「Ａ」で管理されるゲーム内通貨の残高を「−５００」から「０」に変更する代わりに、ゲーム「Ｂ」で管理されるゲーム内通貨の残高をゲーム開始時の初期値「０」から「−５００」に変更するようにしてもよい。また、当該ユーザが既に他のゲーム「Ｃ」をプレイ中である場合には、ゲーム「Ｃ」で管理されるゲーム内通貨の残高を「５００」だけ減少させる代わりに、ゲーム「Ａ」で管理されるゲーム内通貨の残高を「−５００」から「０」に変更するようにしてもよい。また、ユーザがプレイするゲーム「Ａ」で管理される０未満の値になったゲーム内通貨の残高を、当該ユーザがプレイする他のゲーム「Ｂ」で管理されるゲーム内通貨の残高として引き継ぐ場合、ゲーム「Ａ」において当該ユーザに与える所与の制限を、ゲーム「Ｂ」において当該ユーザに与える所与の制限として引き継ぐようにしてもよい。また、ゲーム内通貨の残高や所与の制限の引き継ぎは、所与の条件を満たした場合のみ行うようにしてもよい。例えば、ユーザがプレイするゲーム「Ａ」で管理されるゲーム内通貨の残高が０未満の値となった状態で、ユーザがゲーム「Ａ」のプレイを行わなくなった（例えば、ユーザがゲーム「Ａ」に所定期間以上ログインしていない）場合や、ユーザがゲーム「Ａ」から退会した場合や、ユーザがゲーム「Ａ」のアプリを端末１０から削除した場合に、当該残高や当該ユーザに与える所与の制限を当該ユーザがプレイする他のゲーム「Ｂ」に引き継ぐようにしてもよい。また、例えばゲーム「Ａ」におけるユーザのユーザＩＤとは別に、当該ユーザの端末１０を識別するための端末ＩＤやＰＦサーバにおける当該ユーザのユーザＩＤを設定しておき、ゲーム「Ａ」におけるユーザのユーザＩＤで管理されるゲーム内通貨の残高が０未満の値となった状態で、ＰＦサーバにおける当該ユーザのユーザＩＤや当該ユーザの端末１０の端末ＩＤを用いてゲームへのアクセスが行われた場合に、ゲーム「Ａ」におけるユーザＩＤで管理されるゲーム内通貨の残高や所与の制限を、ＰＦサーバにおけるユーザＩＤや端末ＩＤで管理されるゲーム内通貨の残高や所与の制限として引き継ぐようにしてもよい。また、ユーザやサービス提供者の要求によって、ユーザがプレイするゲーム「Ａ」で管理されるゲーム内通貨の残高を減少させて、当該ユーザがプレイする他のゲーム「Ｂ」で管理されるゲーム内通貨の残高をその減少量だけ増加させるようにしてもよい。

本実施形態によれば、ゲーム内通貨の残高が０以上の値から０未満の値までの範囲で管理され、残高よりも多い減少量を定めた減少要求を受け付けた場合に、残高が０未満の値になることが許容されるため、ゲーム内通貨の残高が不足していても、新たに課金（ゲーム内通貨の購入）を行うことなく、ゲームのプレイ（実行）やゲーム内アイテムの入手が可能となり、柔軟にゲーム内通貨を利用したサービスを実現することができる。例えば、
店舗でプリペイドカードを購入して課金を行う場合には、残高が不足していても、わざわざプリペイドカードを買いに行かずに、ゲーム内通貨の消費を行うことができる。また、残高が不足しているときに、ゲームの実行やゲーム内アイテムを購入したくなった場合に、そのタイミングで課金サーバ３０とゲームサーバ２０の通信などに異常が発生して通信が行えない場合（ゲームシステムを構成する装置間の通信に異常が発生した場合）でも、ゲーム内通貨の消費を行うことができる。ゲーム内通貨の残高が不足していても消費できるようにすることは、特に、期間限定のイベントゲームの実行や期間限定のゲーム内アイテムの購入のためにゲーム内通貨を消費する場合に有効である。また、本実施形態によれば、ユーザのゲーム内通貨の残高が０未満の値になってから０以上の値になるまで、或いは、当該残高が０未満の値になった後所定期間経過後に当該残高が０以上の値になっていない場合に、当該ユーザに対して所与の制限（ゲーム内通貨の消費に関する制限や、ゲーム進行上不利になる制限、無償のゲーム内通貨の付与に関する制限）を与えることで、０未満の値になったゲーム内通貨の残高を０以上の値に増加させることをユーザに促して、ゲーム内通貨の残高が０未満の値になることが常態化することを抑制することができる。

３．処理
次に、本実施形態のゲームシステム（ゲームサーバ２０）の処理の一例について図５のフローチャートを用いて説明する。

まず、減少部２１２は、端末１０からゲーム内通貨の減少量を定めた減少要求を受信したか否かを判断する（ステップＳ１０）。減少要求を受信していない場合（ステップＳ１０のＮ）には、ステップＳ１４に移行する。減少要求を受信した場合（ステップＳ１０のＹ）には、減少部２１２は、当該端末１０のユーザのユーザＩＤに関連付けられたゲーム内通貨の残高を、減少要求で定められた減少量だけ減少させる（ステップＳ１１）。次に、制限部２１８は、当該ユーザのゲーム内通貨の残高が０以上の値から０未満の値になったか否かを判断し（ステップＳ１２）、当該残高が０未満の値になった場合（ステップＳ１２のＹ）には、当該ユーザに対して所与の制限を与える（ステップＳ１３）。

次に、増加部２１０は、端末１０からゲーム内通貨の増加量を定めた増加要求を受信したか否かを判断する（ステップＳ１４）。増加要求を受信していない場合（ステップＳ１４のＮ）には、ステップＳ２０に移行する。増加要求を受信した場合（ステップＳ１４のＹ）には、増加部２１０は、増加要求で定められた増加量に対応する金額の決済要求を課金サーバ３０に送信し（ステップＳ１５）、課金サーバ３０から決済が成立した旨の通知を受信したか否かを判断する（ステップＳ１６）。決済が成立した旨の通知を受信していない（ステップＳ１６のＮ）場合（決済が成立しなかった旨の通知を受信した場合）には、ステップＳ２０に移行する。決済が成立した旨の通知を受信した場合（ステップＳ１６のＹ）には、当該端末１０のユーザのユーザＩＤに関連付けられたゲーム内通貨の残高を、増加要求で定められた増加量だけ増加させる（ステップＳ１７）。次に、制限部２１８は、当該ユーザのゲーム内通貨の残高が０未満の値から０以上の値になったか否かを判断し（ステップＳ１８）、当該残高が０以上の値になった場合（ステップＳ１８のＹ）には、当該ユーザに対して与えていた所与の制限を解除する（ステップＳ１９）。

次に、処理部２００は、処理を継続するか否かを判断し（ステップＳ２０）、処理を継続する場合（ステップＳ２０のＹ）には、ステップＳ１０に移行する。

本発明は、上記実施形態で説明したものに限らず、種々の変形実施が可能である。例えば、明細書又は図面中の記載において広義や同義な用語として引用された用語は、明細書又は図面中の他の記載においても広義や同義な用語に置き換えることができる。

１０…端末、２０…ゲームサーバ、３０…課金サーバ、１００…処理部、１１０…ゲーム処理部、１２０…画像生成部、１３０…音生成部、１５０…入力部、１７０…記憶部、１９０…表示部、１９２…音出力部、１９６…通信部、２００…処理部、２１０…増加部、２１２…減少部、２１４…管理部、２１６…表示制御部、２１８…制限部、２７０…記憶部、２７２…格納部、２９６…通信部

Claims (16)

1. ゲームの実行又はゲーム内アイテムの購入のために消費されるゲーム内通貨の残高をユーザの識別情報に関連付けて管理するゲームシステムであって、
   前記ゲーム内通貨の増加量を定めた増加要求を受け付けた場合に、前記残高を当該増加量だけ増加させる増加部と、
   前記ゲーム内通貨の減少量を定めた減少要求を受け付けた場合に、前記残高を当該減少量だけ減少させる減少部と、
   前記増加部及び前記減少部によって変更された前記残高を０以上の値から０未満の値までの範囲で前記ユーザの識別情報に関連付けて管理する管理部とを含み、
   前記減少部は、
   前記残高よりも多い前記減少量を定めた減少要求を受け付けた場合に、当該残高を０未満の値に変更することを特徴するゲームシステム。
2. 請求項１において、
   前記増加部は、
   ユーザが指定した増加量を定めた増加要求を受け付けた場合に、当該増加量に対応する金額の決済要求を課金サーバに送信し、当該決済要求に応じて課金サーバにおいて当該金額が決済された場合に、前記残高を当該増加量だけ増加させることを特徴とするゲームシステム。
3. 請求項１又は２において、
   前記管理部は、
   前記残高を、０以上の値の第１パラメータと０以下の値の第２パラメータとの合算値で管理し、
   前記増加部は、
   前記ゲーム内通貨の増加量を定めた増加要求を受け付けた場合に、前記第１パラメータを当該増加量だけ増加させることを特徴とするゲームシステム。
4. 請求項３において、
   前記第１パラメータと前記第２パラメータとを区別してユーザの端末の表示部に表示させる表示制御部を更に含むことを特徴とするゲームシステム。
5. 請求項１乃至４のいずれか１項において、
   前記管理部は、
   ユーザの過去のゲーム利用歴が所与の信頼条件を満たすか否かを判定し、前記信頼条件を満たすユーザの前記残高を０未満の値に変更可能にし、前記信頼条件を満たさないユーザの前記残高を０未満の値に変更不能にすることを特徴とするゲームシステム。
6. 請求項１乃至５のいずれか１項において、
   ユーザに対して所与の制限を与える制限部を更に含み、
   前記制限部は、
   ユーザの過去のゲーム利用歴が所与の信頼条件を満たすか否かを判定し、前記信頼条件を満たすユーザに与える前記制限を緩和することを特徴とするゲームシステム。
7. 請求項１乃至５のいずれか１項において、
   ユーザの前記残高が０未満の値になった場合に、当該ユーザに対して所与の制限を与える制限部を更に含むことを特徴とするゲームシステム。
8. 請求項７において、
   前記制限部は、
   ユーザの過去のゲーム利用歴に基づく信頼度が高いほど、当該ユーザに与える前記制限を緩和することを特徴とするゲームシステム。
9. 請求項６乃至８のいずれか１項において、
   前記制限部は、
   ユーザによる前記ゲーム内通貨の消費に関する制限を与えることを特徴とするゲームシステム。
10. 請求項６乃至９のいずれか１項において、
    前記制限部は、
    ゲーム進行上不利になる制限を与えることを特徴とするゲームシステム。
11. 請求項６乃至１０のいずれか１項において、
    前記ゲーム内通貨には、有償のゲーム内通貨と、無償のゲーム内通貨があり、
    前記制限部は、
    ユーザに与える前記制限として、当該ユーザに対する前記無償のゲーム内通貨の付与を停止することを特徴とするゲームシステム。
12. 請求項７乃至１１のいずれか１項において、
    前記制限部は、
    ユーザの前記残高が０以上の値になるまで当該ユーザに対して前記制限を与えることを特徴とするゲームシステム。
13. 請求項７乃至１２のいずれか１項において、
    前記制限部は、
    ユーザの前記残高が０未満の値になった後、所定期間が経過した後に当該残高が０以上の値になっていない場合に、当該ユーザに対して前記制限を与えることを特徴とするゲームシステム。
14. 請求項１乃至１３のいずれか１項において、
    前記管理部は、
    ０未満の値になった前記残高を、他のゲームで管理される前記残高として引き継ぐことを特徴とするゲームシステム。
15. 請求項６乃至１３のいずれか１項に従属する請求項１４において、
    前記管理部は、
    ユーザに与える前記制限を、前記他のゲームにおいて当該ユーザに与える前記制限として引き継ぐことを特徴とするゲームシステム。
16. 請求項１４又は１５において、
    前記管理部は、
    所与の条件が満たされた場合に、前記残高の引き継ぎを行うことを特徴とするゲームシステム。

Images