JP2019093249A - サーバシステム - Google Patents

Abstract

【課題】電子決済に利用可能なユーザＩＤで利用登録した複数のゲームコンテンツを同時使用可能にして、電子決済を用いたゲームシステムの利便性を向上させること。【解決手段】サーバシステム１１００は、あるユーザＩＤを用いてプレイ対価を支払って業務用ゲーム装置１３００にて第１ゲームコンテンツＧ１をプレイしている期間中に、同じユーザＩＤを用いてスマートフォン１５００で第２ゲームコンテンツＧ２に係る課金要求を受信した場合、第１ゲームコンテンツＧ１と第２ゲームコンテンツＧ２とが所定の関連コンテンツ条件を満たす場合には、当該課金要求を許可し決済処理する。しかし、関連コンテンツ条件を満たさなければ、当該課金要求は許可しない。【選択図】図５

Description

本発明は、ユーザの仮想通貨の口座を管理し、端末装置からのゲームコンテンツに係る課金要求に対して当該口座からの決済処理を実行するサーバシステムに関する。

従来、ゲームセンターなどの店舗施設で運営されるいわゆる業務用ゲーム装置では、硬貨投入によるプレイ対価の支払いを基本としてきた。しかし近年は、業務用ゲーム装置でプレイする際に、硬貨投入の代わりに予め登録していたユーザＩＤを入力することで、ユーザＩＤに紐付けされたユーザ（プレーヤ）の仮想通貨（電子マネー）の口座からプレイ対価を引き落とす電子決済を行う電子決済方式も利用されるようになってきた（例えば、特許文献１，特許文献２を参照）。

電子決済方式では、ゲーム参加登録（ゲームへのエントリー）のプロセスで、ユーザＩＤまたはユーザＩＤと紐付けされた媒体ＩＤを記憶したＩＣカード（いわゆるユーザカード）を業務用ゲーム装置に読み取らせれば、プレイ対価の支払いが自動的に行われる。硬貨を持ち歩く必要が無く、エントリーの都度硬貨を投入する必要も無い。

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

近年、大手のゲーム会社（ゲームメーカやゲーム運営会社など）が、複数のゲームタイトルをリリースし、その幾つかにおいて上述のような電子決済方式を採用しつつ、更に異なるゲームコンテンツ間でなにがしかの関連を設定したコンテンツミックス戦略を採用しているケースがみられる。

コンテンツミックスの例としては、例えば異なるゲームコンテンツ間で同じプレーヤキャラクタが登場したり、それぞれのゲームコンテンツの主人公は異なるが戦友や同僚、知人、親族、マスターとサーバントなどの関係が設定されているものが挙げられる。また、異なるゲームコンテンツ間がパラレルワールドとなる関係でもよい。また、一方のゲームコンテンツを、プレーヤキャラクタを操作して得点を稼いだりミッションを遂行するゲームプレイ用のコンテンツとし、他方のゲームコンテンツを、当該プレーヤキャラクタの能力向上のための訓練やアイテムの購入などを行うゲームプレイ以外のコンテンツとする関係でもよい。

プレーヤは、ユーザＩＤや、ユーザＩＤに紐付けられたあるゲームでのプレーヤキャラクタの名前などの１つの識別情報で、こうしたコンテンツミックスな複数のゲームコンテンツを渡り歩きながら楽しむことが可能であり、単独で完結するゲームコンテンツをプレイするよりも、あらゆる角度からゲーム世界を楽しむことができるため、遙かに立体的にゲーム世界を堪能することができるので人気である。

本発明は、電子決済に利用可能なユーザＩＤで利用登録した複数のゲームコンテンツを同時使用可能にして、電子決済を用いたゲームシステムの利便性を向上させることを目的とする。

上述した課題を解決するための第１の発明は、ユーザの仮想通貨（例えば、電子マネー）の口座を管理し、端末装置からのゲームコンテンツに係る課金要求に対して前記口座からの決済処理（例えば、仮想通貨による課金処理）を実行するサーバシステムであって、
第１の端末装置から第１の課金要求を受信し、且つ、第２の端末装置から第２の課金要求を受信したときに、両者の課金要求のタイミングが所定の共遊時期条件を満たさない場合、（例えば、図５の課金要求タイミングＴ１、図１３のステップＳ５６のＮＯ→Ｓ６０）、又は、前記共遊時期条件を満たし、且つ両者の課金要求に係るゲームコンテンツが所定関係であることを示す関連コンテンツ条件を満たす場合に、両者の課金要求に対する決済処理を実行する決済処理手段（例えば、図５の課金要求タイミングＴ２、図１３のステップＳ５８のＹＥＳ→Ｓ６０）、を備えたサーバシステムである。

第１の発明によれば、共遊時期条件を満たし、且つ関連コンテンツ条件を満たす場合に、電子決済に利用可能な同一のユーザＩＤで利用登録した複数のゲームコンテンツを同時使用可能にして、電子決済を用いたゲームシステムの利便性を向上させることができる。勿論、同じユーザＩＤが先行して使用されていなければ、同時使用の可能性であろうとなかろうと、従来通りに好きなときに好きなようにゲームコンテンツを実行できる。

第２の発明は、前記決済処理手段が、前記共遊時期条件を満たし、且つ、前記関連コンテンツ条件を満たさない場合には、何れか一方又は両方の課金要求に対する決済処理を拒絶する（例えば、例えば、図６の課金要求タイミングＴ３、図１３のステップＳ６８）、第１の発明のサーバシステムである。

第２の発明によれば、後から関連コンテンツ条件を満たし得ない別のゲームコンテンツを当該ユーザＩＤでもって実行しようとしても、共遊時期条件を満たしていると当該別のゲームコンテンツに係る決済処理は行われない。コンテンツ内課金のみのタイプであっても、実質的にコンテンツが機能しないことになる。勿論、コンテンツ実行時に課金されるタイプであればそもそも当該別のゲームコンテンツは実行されないことになる。結果、副次的に、例えユーザＩＤが不正利用されたとしても、ユーザＩＤの正規使用者が先にゲームコンテンツを実行し課金してさえいれば、知らないうちに課金されるといった事態を回避できる。

関連コンテンツ条件を満たすゲームコンテンツ同士の位置づけは、適宜設定可能である。
例えば、第３の発明として、前記決済処理手段が、前記両者の課金要求に係るゲームコンテンツのうち、一方が前記第１の端末装置で実行されるゲームプレイ用コンテンツ（例えば、図４の第１ゲームコンテンツＧ１）であり、他方が前記ゲームプレイ用コンテンツのゲームプレイに影響が及ぶゲームプレイ以外の前記第２の端末装置で実行されるコンテンツ（例えば、図４の第４ゲームコンテンツＧ４）であることを前記関連コンテンツ条件として、前記関連コンテンツ条件を満たすか否かを判定する、第１又は第２の発明のサーバシステムを構成することができる。

また、共遊期間条件については、例えば第４の発明として、前記両者の課金要求に係るゲームコンテンツは、一方又は両方がゲームプレイ用コンテンツであり、前記決済処理手段は、前記ゲームプレイ用コンテンツのプレイ期間を用いて前記共遊時期条件を満たすか否かを判定する、第１〜第３の何れかの発明のサーバシステムを構成することができる。

第５の発明は、前記共遊時期条件を満たし、且つ、前記関連コンテンツ条件を満たす場合に、所与の特典を付与する特典付与処理を実行する特典付与手段、（例えば、図８の終了条件緩和制御部２４０、図１５のステップＳ１４０）、を更に備えた第１〜第３の何れかの発明のサーバシステムである。

第５の発明によれば、同一ユーザＩＤを用いて、関連コンテンツ条件を満たす複数のゲームコンテンツを使用するプレイスタイルにインセンティブを与えることができる。よって、プレーヤにゲームコンテンツの利用を促すことができる。

第６の発明は、前記特典付与手段が、前記両者の課金要求の一方又は両方の価額を割り引く割引処理手段（例えば、図８の割引処理部２１８、図１４のステップＳ１０２〜Ｓ１０４）を有する、第５の発明のサーバシステムである。

第６の発明によれば、同一ユーザＩＤを用いて、関連コンテンツ条件を満たす複数のゲームコンテンツを同じ使用するプレイスタイルにインセンティブを与えることができる。よって、更にプレーヤにゲームコンテンツの利用を促すことができる。

なお、割り引く内容については適宜設定可能である。
例えば、第７の発明として、前記割引処理手段は、前記両者の課金要求のタイミングに基づいて、割り引く内容を変更する、第６の発明のサーバシステムを構成することができる。

また、第８の発明として、前記両者の課金要求に係るゲームコンテンツは、一方がゲームプレイ用コンテンツであり、他方がゲームプレイ以外のコンテンツであり、前記割引処理手段は、前記ゲームプレイ用コンテンツのゲームプレイ中に、前記ゲームプレイ以外のコンテンツに係る課金要求がなされた回数又は課金額に基づいて、割り引く内容を変更する、第６の発明のサーバシステムを構成するとしてもよい。

そして、特典内容は適宜設定可能である。
例えば、第９の発明として、前記両者の課金要求に係るゲームコンテンツは、一方又は両方がゲームプレイ用コンテンツであり、前記特典付与手段は、前記ゲームプレイ用コンテンツのゲームプレイ時間を延長する処理を前記特典付与処理として実行する、第５〜第８の何れかの発明のサーバシステムを構成することができる。

また、第１０の発明として、前記両者の課金要求に係るゲームコンテンツは、一方がゲームプレイ用コンテンツであり、他方がゲームプレイ以外のコンテンツであり、前記特典付与手段は、前記ゲームプレイ以外のコンテンツに係る課金要求の価額に応じて、前記特典を可変に設定する、第５〜第８の何れかの発明のサーバシステムを構成することもできる。

第１１の発明は、前記ゲームコンテンツの実行をユーザＩＤを用いて管理するとともに、前記口座を当該ユーザの前記ユーザＩＤと対応付けて管理する、第１〜第１０の何れかの発明のサーバシステムである。

第１１の発明によれば、ユーザＩＤを用いてゲームコンテンツの実行と口座の管理を一元管理することができる。

決済処理については、第１２の発明として、前記決済処理手段が、前記課金要求に応じた価額の前記仮想通貨を前記口座から消費することで実現することとしてもよい。

ゲームシステムの構成の一例を示す図。 業務用ゲーム装置（端末装置）の構成例を示す斜視外観図。 スマートフォン（端末装置）の構成例を示す外観図。 コンテンツミックスの関係を示す為の図。 決済処理の原理を説明するための図。 決済処理の原理を説明するための図。 特典について説明するための図。 サーバシステムの機能構成例を示す機能ブロック図。 サーバ記憶部が記憶するプログラムやデータの例を示す図。 ゲームコンテンツ課金履歴のデータ構成例を示す図。 ゲームコンテンツ実行履歴のデータ構成例を示す図。 端末装置における処理の流れについて説明するためのフローチャート。 サーバシステムにおける処理の流れについて説明するためのフローチャート。 図１３より続くフローチャート。 図１４より続くフローチャート。

〔第１実施形態〕
本発明を適用した実施形態として、業務用ゲーム装置にて電子決済用媒体を用いてゲームのプレイ対価の支払を行い、とあるゲームコンテンツをプレイしている最中に、スマートフォンで同じ電子決済用媒体を用いてコンテンツミックスの関係にある別のゲームコンテンツを実行する例について説明する。

図１は、本実施形態におけるゲームシステムの構成の一例を示す図である。本実施形態のゲームシステムは、通信回線９に接続することのできるサーバシステム１１００と、プレーヤが電子決済用媒体６を用いてプレーヤ登録とプレイ対価の支払いができる業務用ゲーム装置１３００と、電子決済用媒体６の媒体読取装置１５４４が装着されたスマートフォン１５００と、を含む。媒体読取装置１５４４は外付け型として図示しているが、スマートフォン１５００に内蔵されることとしてもよい。

電子決済用媒体６は、電子マネー（仮想通貨）による電子決済システムを利用するためのキーデータを記憶する。当該キーデータは、コンピュータに接続された専用の読取装置を用いることで読み取り可能とされる。電子決済用媒体６は、例えば、ＩＣカードや、所定の電子決済アプリケーションを起動するスマートフォンなどにより実現できる。本実施形態では、業務用ゲーム装置１３００とスマートフォン１５００とが、それぞれ電子決済用媒体６に対応する媒体読取装置１３４４、媒体読取装置１５４４を有しており、対価支払設置装置として機能する。

キーデータとしては、例えば、ユーザ登録時に設定される固有のユーザＩＤや、固有の媒体ＩＤ（例えば、ＩＣカードならばカードＩＤ、スマートフォンなどの情報機器ならばＭＡＣアドレス）などを適宜設定することができる。ちなみに、本実施形態の電子決済用媒体６には、媒体ＩＤは記憶されているが金銭価値に対応するデータは記憶されていない。

本実施形態では、プレーヤは、予め所定の手続きを経てユーザ登録しユーザＩＤを取得すると、自身の口座へ電子マネーを購入して入金し、更に別途入手した電子決済用媒体６の固有の媒体ＩＤを自身のユーザＩＤと関連付けて登録することができる。ユーザＩＤと対応づけて電子決済用媒体６を登録することで、あたかもプリペイドカードの如く電子決済用媒体６をプレイ対価の支払いに使用する事ができるようになる。

通信回線９は、データ通信が可能な通信路を意味する。すなわち、通信回線９とは、直接接続のための専用線（専用ケーブル）やイーサネット（登録商標）等によるＬＡＮ（Local Area Network）の他、電話通信網やケーブル網、インターネット等の通信網を含む意味であり、また、通信方法については有線／無線を問わない。

サーバシステム１１００は、例えば、本体装置１１０１と、キーボード１１０６と、タッチパネル１１０８と、ストレージ１１４０とを備える。
本体装置１１０１には制御基板１１５０が搭載されている。この制御基板１１５０には、ＣＰＵ（Central Processing Unit）１１５１やＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などの各種マイクロプロセッサ、ＡＳＩＣ（Application Specific Integrated Circuit）、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１１５２、通信装置１１５３が搭載されている。

そして、サーバシステム１１００は、制御基板１１５０で所定のプログラム及びデータに基づいて演算処理することにより、１）ユーザの登録処理及び仮想通貨の口座を含む登録情報を管理しゲームコンテンツに係る課金要求に対して口座からの決済処理を実行する「ユーザ登録管理機能」と、２）業務用ゲーム装置１３００やスマートフォン１５００へゲームコンテンツを実行するのに必要なデータを提供する「ゲーム管理機能」と、を実現する。

なお、図１の例では、サーバシステム１１００は単体として記しているが、ユーザ登録管理機能とゲーム管理機能とを分担する複数のブレードサーバを搭載して、相互に内部バスを介してデータ通信可能に接続した構成であっても良い。或いは、離れた場所に設置された独立した複数のサーバを、通信回線９を介してデータ通信させることで、全体としてサーバシステム１１００として機能させる構成であっても良い。

図２は、業務用ゲーム装置１３００の構成例を示す斜視外観図である。
業務用ゲーム装置１３００は、通信回線９に接続してサーバシステム１１００にアクセスすることができるコンピュータであり電子装置（電子機器）であって、ゲームコンテンツを実行するためにプレーヤが使用する第１の端末装置である。

本実施形態の業務用ゲーム装置１３００は、携帯型ゲーム装置、据置型家庭用ゲーム装置、据置型家庭用ゲーム装置のゲームコントローラに分類される装置に置き換えることができる。また、端末装置としての機能を実現するためのアプリケーションプログラムを実行できるスマートフォンや、パソコン、タブレット型コンピュータ、ウェアラブルコンピュータなどに分類される装置でもよい。

本実施形態における業務用ゲーム装置１３００は、ジョイスティック１３０２と、ボタンスイッチ１３０４と、画像表示デバイス兼接触位置入力デバイスとして機能するタッチパネル１３０６と、スピーカ１３１０と、制御基板１３５０と、電子決済用媒体６からデータを読み取りできる媒体読取装置１３４４と、を備える。

制御基板１３５０は、ＣＰＵ１３５１やＧＰＵ，ＤＳＰなどの各種マイクロプロセッサと、ＡＳＩＣ，ＶＲＡＭ，ＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１３５２と、通信回線９に通信接続するための無線通信モジュール１３５３とが搭載されている。その他、タッチパネル１３０６のドライバ回路、ジョイスティック１３０２及びボタンスイッチ１３０４からの信号を受信する回路、スピーカ１３１０へ音声信号を出力する出力アンプ回路、媒体読取装置１３４４への信号入出力回路といった所謂Ｉ／ＦコントロールＩＣ１３５７（インターフェース回路）等が搭載されている。これら制御基板１３５０に搭載されている各要素は、それぞれバス回路などを介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。

制御基板１３５０は、ゲームプログラムを実行して演算処理を実行し、ジョイスティック１３０２やボタンスイッチ１３０４，タッチパネル１３０６からの操作入力に応じて業務用ゲーム装置１３００の各部を制御してゲームプレイを可能にする。本実施形態の業務用ゲーム装置１３００は、必要なプログラムや各種設定データを予めＩＣメモリ１３５２に記憶しているものとするが、起動の都度、サーバシステム１１００からダウンロードする構成としても良い。

制御基板１３５０の制御により、業務用ゲーム装置１３００は、ジョイスティック１３０２やタッチパネル１３０６などを介した操作入力の結果をサーバシステム１１００へ逐次送信する一方で、サーバシステム１１００から第１のゲームコンテンツ（ゲームプレイ用のコンテンツ）を実行するための各種データを受信し、ゲーム画面の画像を生成してタッチパネル１３０６に表示させ、効果音や操作音の音信号を生成してスピーカ１３１０から放音することができる。つまり、プレーヤはタッチパネル１３０６に表示されるゲーム画面を見て、スピーカ１３１０から流れるゲーム音を聞きながら、ジョイスティック１３０２等を操作して第１のゲームコンテンツのゲームプレイを楽しむことができる。

図３は、本実施形態におけるスマートフォン１５００の構成例を示す外観図である。
本実施形態のスマートフォン１５００は、アプリケーションプログラムを実行可能なコンピュータであって、第２のゲームコンテンツを実行するために使用される第２の端末装置である。

本実施形態ではアプリケーションプログラムを実行可能な携帯電話に分類される装置としているが、第２のゲームコンテンツを実行するためのアプリケーションプログラムを実行できるコンピュータであれば、スマートフォンの形態に限らず、パソコン、タブレット型コンピュータ、ウェアラブルコンピュータなどに分類される装置であってもよい。

本実施形態におけるスマートフォン１５００は、方向入力キー１５０２と、ボタンスイッチ１５０４と、画像表示デバイス兼接触位置入力デバイスとし機能するタッチパネル１５０６と、スピーカ１５１０と、マイク１５１２と、制御基板１５５０と、電子決済用媒体６からデータを読み取りできる媒体読取装置１５４４と、を備える。その他、図示されていない電源ボタン、音量調節ボタン等が設けられている。

制御基板１５５０は、ＣＰＵ１５５１やＧＰＵ，ＤＳＰなどの各種マイクロプロセッサと、ＶＲＡＭ，ＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１５５２と、通信回線９に通信接続するための無線通信モジュール１５５３とが搭載されている。その他、タッチパネル１５０６のドライバ回路、方向入力キー１５０２及びボタンスイッチ１５０４からの信号を受信する回路、スピーカ１５１０へ音声信号を出力する出力アンプ回路、マイク１５１２で集音した音声の信号を生成する入力信号生成回路、媒体読取装置１５４４への信号入出力回路といった所謂Ｉ／ＦコントロールＩＣ１５５７（インターフェース回路）等が搭載されている。これら制御基板１５５０に搭載されている各要素は、それぞれバス回路などを介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。

制御基板１５５０は、第２のゲームコンテンツに係る第２ゲームプログラムやデータをＩＣメモリ１５５２に一時記憶する。そして、当該プログラムを実行して演算処理を実行し、方向入力キー１５０２やボタンスイッチ１５０４，タッチパネル１５０６からの操作入力に応じてスマートフォン１５００の各部を制御して、第２のゲームコンテンツの実行を可能にする。

なお、本実施形態では、スマートフォン１５００は必要なプログラムや各種設定データをサーバシステム１１００から取得する構成としているが、別途入手したメモリカード１５４０などの記憶媒体から読み出す構成としても良い。また、媒体読取装置１５４４は、外付けタイプに限らず装置本体に内蔵されている構成でもよい。

［コンテンツミックスについて］
図４は、本実施形態におけるコンテンツミックスの関係を示す為の図である。
業務用ゲーム装置１３００やスマートフォン１５００がサーバシステム１１００へ接続することで実行可能になるゲームコンテンツは複数用意されている。本実施形態では、第１ゲームコンテンツＧ１〜第４ゲームコンテンツＧ４の４種とするが、コンテンツミックスの関係が設定された２種類が含まれる限りに於いてその数は適宜設定可能である。

第１ゲームコンテンツＧ１及び第３ゲームコンテンツＧ３は、ゲームプレイを目的とした所謂オンラインゲームであって、コンテンツ実行開始時（ゲームプレイ開始時）にプレイ対価の課金が行われ、更にゲームプレイ内でも課金する要素を含む。

第１ゲームコンテンツＧ１と第３ゲームコンテンツＧ３は、それぞれが独立したゲームコンテンツであって、同じユーザＩＤでプレイできると言う以外の共通点・関連性は無い。例えば、第１ゲームコンテンツＧ１が、プレーヤキャラクタ４１を使用して敵キャラクタ６１と戦うアクションゲームやＲＰＧ（ロールプレイングゲーム）で、第３ゲームコンテンツＧ３が、プレーヤキャラクタに該当するプレーヤ部隊７３を編成して敵部隊８３と交戦する戦略シミュレーションゲーム、と言った具合である。勿論、それぞれのゲームコンテンツのジャンルは適宜設定可能である。カーレースでも良いし、恋愛シミュレーションゲーム、育成ゲーム、パズルゲームなどでもよい。

対して、第２ゲームコンテンツＧ２及び第４ゲームコンテンツＧ４は、第１ゲームコンテンツＧ１と「コンテンツミックス」の関係にある。
コンテンツミックスの関係とは、異なるコンテンツ間で内容に係る共通点が存在する関係を言う。例えば、１）それぞれのゲームコンテンツに係るパラメータ値が相互に影響を及ぼし合う関係や、２）異なるゲームコンテンツ間で登場するキャラクタが一部又は全部が共通している場合、３）一方が他方のゲーム世界の一部を構成している場合、４）一方がゲームプレイを主体とし、他方が一方のゲームコンテンツのゲームプレイ以外の要素に係るマンマシンインターフェースの役割を担う場合、などが考えられる。

なお、ここで言う「登場するキャラクタ」とは、必ずしもゲーム画面上に表示されるキャラクタとは限らない。例えば、一方のゲームコンテンツにおける主たるプレーヤキャラクタが戦闘兵器でそのパイロットは画面には表示されなくとも、他方のゲームコンテンツにおける主たるプレーヤキャラクタがこのパイロットである場合には、コンテンツミックスの関係にあると言える。また、操作入力に応じて動作されるプレーヤキャラクタに限らず、当該プレーヤキャラクタの仲間や味方、使い魔、従僕とされるＮＰＣ（ノンプレーヤキャラクタ）、成長要素を有する装備品（例えば、攻撃力が増す魔法の刀剣キャラクタなど）に読み替えることもできる。データ的にコンテンツミックスを説明するならば、ゲームコンテンツに用いられる何らかのデータ（例えばパラメータ）が互いに共通利用されるゲームコンテンツ群のこと、ということができる。

図４の例で説明すると、第１ゲームコンテンツＧ１は、プレーヤキャラクタ４１にＨＰ（ヒットポイント）やＭＰ（マジックポイント）などの能力パラメータ値を設定し、それらに基づいてゲーム進行が制御されるＲＰＧである。

第２ゲームコンテンツＧ２は、プレーヤキャラクタ４１と同じプレーヤキャラクタ４２が登場し、ボタン連打の速さと回数に応じてその能力パラメータ値（図示の例ではＭＰ）を回復させるゲームとすると、第１ゲームコンテンツＧ１と第２ゲームコンテンツＧ２とはコンテンツミックス関係を成している。
なお、ここで言う“キャラクタが同じ”とは、全く同一であることは勿論だが、例えば一方がオプション兵器装着状態の戦闘ロボットで、他方が未装着の戦闘ロボットと言った具合に、主体となる部分が共通の意味をも含む。

また、第４ゲームコンテンツＧ４は、プレーヤキャラクタ４１がゲーム内で利用することのできる武器等のアイテムの購入や売却、合成などの管理を行うコンテンツである。従って、第１ゲームコンテンツＧ１と第４ゲームコンテンツＧ４とはコンテンツミックス関係を成している。

なお、第２ゲームコンテンツＧ２は、コンテンツ実行開始時にプレイ対価の課金が行われる。第４ゲームコンテンツＧ４はコンテンツ実行開始時には課金されないが、アイテム等の購入等に応じて電子マネーの口座への入金・出金が行われるものとする。

図５及び図６は、本実施形態における決済処理の原理を説明するための図である。
本実施形態のサーバシステム１１００は、相前後する異なるゲームコンテンツからの課金要求（課金リクエスト）に関して、それらの課金要求タイミングの時間差と、コンテンツミックスの関係の有無に基づいて決済を行うか否かを判断する。

具体的には、サーバシステム１１００は、課金要求毎に履歴を記憶する機能を有する。そして、第１の課金要求を業務用ゲーム装置１３００から受信し、第２の課金要求をスマートフォン１５００から受信するものとする。

［ケース１］サーバシステム１１００は、両者の課金要求のタイミングが所定の共遊時期条件を満たさなければ両者の課金要求に対する決済処理を実行する。本実施形態における共遊時期条件は、「第２の課金要求タイミングが、先行して実行されている他ゲームコンテンツに係る第１の課金要求タイミングからゲーム終了までの期間内である」とされる。図５の例では、第２の課金要求タイミングがタイミングＴ１の場合、共遊時期条件が満たさないと判断されて決済が行われる。

共遊時期条件を満たすときには、［ケース２ａ］両者の課金要求に係るゲームコンテンツが関連コンテンツ条件を満たせば両者の課金要求に対する決済処理を実行するが、［ケース２ｂ］関連コンテンツ条件を満たさなければ何れか一方又は両方の課金要求に対する決済処理を不可とする。本実施形態における関連コンテンツ条件は、「両者の間にコンテンツミックスの関係が設定されている」こととされる。

図５の例では、第２ゲームコンテンツＧ２に係る第２の課金要求タイミングが、先行して実行されている第１ゲームコンテンツＧ１の最初の課金（プレイ対価への課金：第１の課金要求タイミング）からゲーム終了までの期間、すなわちプレイ期間のうちのタイミングＴ２で行われている。共遊時期条件を満たしており、且つ第１ゲームコンテンツＧ１と第２ゲームコンテンツＧ２は前述のようにコンテンツミックスの関係にあるので、タイミングＴ２における第２の課金要求の決済は行われる。

つまり、図５に示す例によれば、第２ゲームコンテンツＧ２を実行でき、そのゲームプレイの結果によって、第１ゲームコンテンツＧ１にも登場するプレーヤキャラクタ４１のＭＰを獲得することができる。もし、第２ゲームコンテンツＧ２が第４ゲームコンテンツＧ４であれば、アイテムを購入可能となり、新たに購入したアイテムを第１ゲームコンテンツＧ１にて利用可能となる。

一方図６では、第３ゲームコンテンツＧ３に係る第２の課金要求タイミングが、先行して実行されているゲームコンテンツの最初の課金からゲーム終了までの期間内であるタイミングＴ３で行われている。しかし、このケースでは、タイミングＴ３は共遊時期条件を満たしているが、第１ゲームコンテンツＧ１と第３ゲームコンテンツＧ３との間にはコンテンツミックスの関係は設定されていないので、この第３ゲームコンテンツＧ３に係る第２の課金要求の決済は拒絶される。

よって、上記のケース２ａによって、“電子決済に利用可能な同一のユーザＩＤで利用登録した複数のゲームコンテンツを同時使用可能にして、電子決済を用いたゲームシステムの利便性を向上させる”当初の目的は達せられることとなる。勿論、ケース１のように、同じユーザＩＤが先行して使用されていなければ、同時使用の可能性であろうとなかろうと、従来通りに好きなときに好きなようにゲームコンテンツを制限無く利用できる。

しかし、同じユーザＩＤが先行して使用されている状態で、後から関連コンテンツ条件を満たし得ない別のゲームコンテンツを当該ユーザＩＤでもって利用しようとしても、当該別のゲームコンテンツに係る決済処理は行われない。尚、コンテンツ実行時に課金されるタイプであればそもそも当該別のゲームコンテンツは実行されないことになる。コンテンツ内課金のみのタイプであっても、実質的にコンテンツが機能しないことになる。
結果、副次的に、例えユーザＩＤが不正利用されたとしても、ユーザＩＤの正規使用者が先に第１ゲームコンテンツＧ１のプレイに係り課金が行われていれば、知らないうちに課金されるといった事態を回避することができることになる。

図７は、［ケース２ａ］に係る特典について説明するための図である。
本実施形態では、上記［ケース２ａ］における決済において特典を付与することができる。本実施形態における特典の内容は、課金の割引と、ゲームコンテンツの終了条件の緩和の２種類とするがこれに限るものではない。例えば、使用可能なキャラクタの追加、アイテムの付与、プレイ可能なゲームステージ（音楽ゲームであればプレイ可能な曲、恋愛ゲームならば恋愛対象のキャラクタに相当）の追加・拡張、既に所持済のアイテムの作用効果や能力の向上、プレーヤキャラクタの能力の向上、ゲームに係る課金で利用可能なクーポンの付与、電子マネーのキャッシュバック、など適宜特典の内容を設定することができる。ゲームコンテンツの終了条件の緩和は、時間制のゲームであればプレイ可能時間の延長、ミス操作回数が規程値に達するとゲームオーバーになるゲームであれば規程値の増加など、そのゲーム内容に即して適宜設定するものとする。本実施形態ではプレイ可能時間の延長とする。

割引率については図７（１）に示すように、そしてゲームコンテンツの終了条件の緩和については図７（２）に示すように、第２の課金要求に係るゲームコンテンツにおける今回の実行に係る課金回数や、その都度の課金額、課金総額などをパラメータとして所定の関数で図示の如く設定する。勿論、それらのパラメータ値と算出される割引率の関係は図示の例以外にも適宜設定可能である。

［機能構成の説明］
次に、本実施形態を実現するための機能構成例について説明する。
図８は、本実施形態におけるサーバシステム１１００の機能構成例を示す機能ブロック図である。本実施形態におけるサーバシステム１１００は、操作入力部１００ｓと、サーバ処理部２００ｓと、画像表示部３９２ｓと、通信部３９４ｓと、サーバ記憶部５００ｓとを備える。

操作入力部１００ｓは、サーバの管理のための各種操作を入力するための手段である。図１の例ではキーボード１１０６が該当する。

サーバ処理部２００ｓは、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ（特定用途向け集積回路）、ＩＣメモリなどの電子部品によって実現され、操作入力部１００ｓやサーバ記憶部５００ｓを含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１００ｓからの操作入力信号、業務用ゲーム装置１３００等の端末装置から受信したデータに基づいて各種の演算処理を実行して、サーバシステム１１００の動作を統合的に制御する。図１の例では制御基板１１５０が該当する。

そして、本実施形態のサーバ処理部２００ｓは、ユーザ登録管理部２１０と、ゲームコンテンツ管理部２３０と、画像生成部２９２ｓと、通信制御部２９４ｓとを含む。

ユーザ登録管理部２１０は、ユーザ登録手続きに係る処理と、ユーザ登録データの管理と、当該ユーザが利用するゲームコンテンツ毎のデータ管理に関する処理とを行う。
本実施形態では、１）所定の登録手続きを経たユーザすなわちプレーヤへの固有のユーザＩＤの発給、２）電子決済に使用する電子決済用媒体６の紐付け処理、３）電子決済用の口座の設定、３）口座への入金／出勤処理すなわち決済処理と、決済履歴の記憶管理、）４）利用するコンテンツ別のデータ管理（例えば、セーブデータや実行履歴、課金履歴などの管理）、などを行うことができる。

そして、本実施形態のユーザ登録管理部２１０は、決済処理部２１２と、課金履歴管理部２２０と、を有する。

決済処理部２１２は、通信接続された端末装置（業務用ゲーム装置１３００やスマートフォン１５００）からの課金要求に応じて決済処理を実行する。
本実施形態では、相前後する異なるゲームコンテンツからの課金要求に関して、それらの課金要求タイミングの時間差と、コンテンツミックスの関係の有無に基づいて決済を行うか否かを判断する（図５〜図７参照）。これに関連して、共遊時期条件判定部２１４と、関連コンテンツ条件判定部２１６と、割引処理部２１８とを有する。

共遊時期条件判定部２１４は、同じユーザＩＤで同時期に利用されているゲームコンテンツに係る課金要求タイミングが共有時期条件を満たしているか判定処理する。本実施形態では、後に開始されたゲームコンテンツに係る課金要求タイミングが、これより先に開始されているゲームコンテンツの最初の課金要求タイミングからコンテンツ終了まで、すなわちプレイ期間（図５参照）内であれば“肯定”と判定する。勿論、共遊期間はプレイ期間に限るものではなく、単純に最初の課金要求タイミングから所定期間（例えば、２４時間）としてもよい。

関連コンテンツ条件判定部２１６は、同じユーザＩＤで同時期に利用されているゲームコンテンツが所定の関連性を有しているかを判定する。本実施形態では、コンテンツミックスの関係に該当する場合には肯定と判定する。

割引処理部２１８は、本実施形態の決済処理に係る第１の特典付与部であって、割引率（図７参照）を算出して決済に適用する処理をする。

課金履歴管理部２２０は、決済処理が実行される都度の履歴、すなわち課金履歴を記憶管理する。

ゲームコンテンツ管理部２３０は、端末装置から実行リクエストされたゲームコンテンツを起動させて、当該端末装置と通信を維持し当該コンテンツ実行に必要なデータを提供する制御を行う。本実施形態では、提供するゲームコンテンツ別の制御部（第１ゲームコンテンツ制御部２３１，第２ゲームコンテンツ制御部２３２，…）と、ゲームコンテンツの終了条件緩和制御部２４０と、を含む。

終了条件緩和制御部２４０は、本実施形態の決済処理に係る第２の特典付与部であって、ゲームコンテンツの終了条件の緩和度合を決定して反映させる。

画像生成部２９２ｓは、サーバシステム１１００の保守に関する画像等を生成し、画像表示部３９２ｓへ出力することができる。

画像表示部３９２ｓは、画像生成部２９２ｓから入力される画像信号に基づいてシステム管理のための各種画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。図１の例ではタッチパネル１１０８が該当する。

通信制御部２９４ｓは、データ通信に係るデータ処理を実行し、通信部３９４ｓを介して外部装置とのデータのやりとりを実現する。

通信部３９４ｓは、通信回線９と接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現される。図１の例では通信装置１１５３が該当する。

サーバ記憶部５００ｓは、サーバ処理部２００ｓにサーバシステム１１００を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲームを管理するために必要なプログラム、各種データ等を記憶する。また、サーバ処理部２００ｓの作業領域として用いられ、サーバ処理部２００ｓが各種プログラムに従って実行した演算結果などを一時的に記憶する。こうした機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図１の例では本体装置１１０１が搭載するＩＣメモリ１１５２やハードディスクなどの記憶媒体、及びストレージ１１４０がこれに該当する。

図９は、本実施形態におけるサーバ記憶部５００ｓが記憶するプログラムやデータの例を示す図である。
サーバ記憶部５００ｓは、サーバシステムプログラム５０１と、ユーザ登録管理プログラム５０３と、ゲームコンテンツ管理プログラム５０５と、複数のプログラムファイル５１０と、複数の初期設定ファイル５１２と、関連コンテンツ設定データ５３０と、特典設定データ５３２と、を予め記憶する。また、サーバ記憶部５００ｓは、逐次生成更新されるデータとして、ユーザ登録データ６００と、コンテンツ管理データ６１０と、プレイデータ７００とを記憶する。更には、その他、タイマやカウンタ、各種フラグなどの情報を適宜記憶できる。

サーバシステムプログラム５０１は、サーバ処理部２００ｓが読み出して実行することでサーバシステム１１００にコンピュータとして必要な基本的な入出力機能を実現するためのシステムプログラムである。

ユーザ登録管理プログラム５０３は、サーバ処理部２００ｓが読み出して実行することで、ユーザ登録管理部２１０としての機能を実現させるためのプログラムである。

ゲームコンテンツ管理プログラム５０５は、サーバ処理部２００ｓにゲームコンテンツ管理部２３０としての機能、すなわちゲームコンテンツの実行環境を実現させるためのプログラムである。

プログラムファイル５１０は、サーバシステム１１００が提供するゲームコンテンツ別に用意される。一つのプログラムファイル５１０は、ゲームコンテンツの識別情報である固有のコンテンツＩＤと対応づけて、サーバ処理部２００ｓが読み出して実行することで、それぞれのゲームコンテンツ制御部（第１ゲームコンテンツ制御部２３１，第２ゲームコンテンツ制御部２３２，…）としての機能を実現させるためのコンテンツ制御プログラムを格納する。

更には、プログラムファイル５１０に、対応するゲームコンテンツを実行するために端末装置側で実行するべき「配信用のクライアントプログラム」を対応づけて含むとしてもよい。配信用のクライアントプログラムは、例えば、専用のプログラムとして実現してもよい。あるいは、本実施形態のゲームをウェブゲームとして実現するならば、ウェブブラウザをベースとしてＨＴＭＬとともにＪａｖａ（登録商標）やＣＳＳ（Cascading Style Sheets）等を利用して能動的に画面表示を制御するウェブ技術や、Adobe（登録商標） Flashなどのプラグインを用いて実現するとしてもよい。勿論、その他の方法でもかまわない。

初期設定ファイル５１２は、サーバシステム１１００が提供するゲームコンテンツ別に用意される。一つの初期設定ファイル５１２は、コンテンツＩＤと、当該コンテンツＩＤのゲームコンテンツを実行するために必要な各種初期設定データを格納する。その一部は、端末装置への配信に用いるとしてもよい。

関連コンテンツ設定データ５３０は、コンテンツミックスの関係の設定毎に用意される。一つの関連コンテンツ設定データ５３０には、固有のコンテンツミックスＩＤと対応づけて、関連するゲームコンテンツのコンテンツＩＤ（図中の「関連コンテンツＩＤ」）を格納する。

特典設定データ５３２は、特典を付与する条件およびその特典内容（図７参照）を定義するデータである。

ユーザ登録データ６００は、ユーザ登録されたプレーヤ毎に用意される。１つのユーザ登録データ６００は、例えば１）ユーザＩＤ６０２と、２）認証登録済みの電子決済用媒体６を示す認証済媒体ＩＤ６０３と、３）電子決済用口座の口座残高６０４と、５）決済履歴６０５と、を含む。勿論、これら以外のデータも適宜格納することができる。

コンテンツ管理データ６１０は、ユーザ登録されたプレーヤ毎で、更に利用したことのあるゲームコンテンツ毎に用意される。
１つのコンテンツ管理データ６１０は、例えば、ユーザＩＤ６１２と、認証済媒体ＩＤ６１４と、ゲームコンテンツの識別情報であるコンテンツＩＤ６１６と、セーブデータ６１８と、ゲームコンテンツ課金履歴６２０と、ゲームコンテンツ実行履歴６３０と、を含む。勿論、これら以外のデータも適宜格納することができる。

ゲームコンテンツ課金履歴６２０は、例えば図１０に示すように、決済が行われた課金日時６２２と、課金の目的である課金理由６２４と、課金額６２６とを対応づけて格納する。

ゲームコンテンツ実行履歴６３０は、例えば図１１に示すように、開始日時６３２と、終了日時６３６とを対応付けて格納する。

プレイデータ７００は、実行中のゲームコンテンツ別に用意され、その進行状況を記述する各種データを格納する。その１つに、当該ゲームコンテンツの終了条件パラメータ値７０２を含む。終了条件パラメータ値７０２は、例えば、時間制のゲームコンテンツならば、実行開始からの経過時間の制限時間を格納する。操作ミス回数を終了条件とするゲームコンテンツならば、その上限回数を格納する、といった具合にゲーム内容に応じて適宜設定するものとする。コンテンツミックスの他ゲームコンテンツに係る課金にとともなって、特典付与の１つとして終了条件の緩和を行う場合には、ゲームコンテンツの実行開始時には終了条件パラメータ値７０２を所定値としておき、終了条件の緩和を行う場合に当該パラメータ値を変更することとする。

［処理の流れの説明］
図１２は、端末装置である業務用ゲーム装置１３００における処理の流れについて説明するためのフローチャートである。なお、もう一つの端末装置であるスマートフォン１５００における処理の流れもこれと同様である。

業務用ゲーム装置１３００は、媒体読取装置１３４４で電子決済用媒体６から媒体ＩＤを読み取ると（ステップＳ２）、当該ＩＤに対応づけられているユーザＩＤをサーバシステム１１００から取得する制御を行う（ステップＳ４）。
具体的には、業務用ゲーム装置１３００は、読み取った媒体ＩＤと自機固有の端末ＩＤ（例えば、ＭＡＣアドレスやＩＰアドレスなど）と所定の照合リクエストとをサーバシステム１１００へ送信する。サーバシステム１１００は、当該媒体ＩＤと合致する認証済媒体ＩＤ６０３を有するユーザ登録データ６００を検索し、そのユーザＩＤ６０２を返信する（図９参照）。

業務用ゲーム装置１３００は、所定のコンテンツ実行リクエストとともに、取得したユーザＩＤ６０２と、自機が実行するゲームコンテンツの固有のコンテンツＩＤと、プレイ対価とされる所定の課金額と、をサーバシステム１１００へ送信する（ステップＳ６）。当該送信を「通信Ａ」とする。なお、業務用ゲーム装置１３００で実行するゲームコンテンツが、プレイ対価が無料でコンテンツ内で主たる課金するタイプ（例えば、アイテム課金タイプのコンテンツ）とする構成では、通信Ａには課金額を含めなくとも良い。

次に、業務用ゲーム装置１３００は、通信Ａへの返信として実行リクエストしたゲームコンテンツの実行可否を「通信Ｂ」としてサーバシステム１１００から受信する。実行開始時にプレイ対価を支払うゲームコンテンツの場合、通信Ｂとされる実行可否の通知は、実質的な今回の課金の決済可／不可の通知となる。

そして、もし通信Ｂの結果がコンテンツ実行拒絶・実行不可であれば（ステップＳ８のＮＯ ）、業務用ゲーム装置１３００はプレーヤへ向けてゲームコンテンツが実行できな
い旨の通知を行って、一連の処理を終了する。

通信Ｂの結果がコンテンツ実行可であれば（ステップＳ８のＹＥＳ）、業務用ゲーム装置１３００は、ゲームコンテンツを実行するための制御を開始する（ステップＳ１２）。

制御開始後に、コンテンツ内課金操作が検出されると（ステップＳ２０のＹＥＳ）、業務用ゲーム装置１３００は、コンテンツ内課金リクエストとともに、端末ＩＤと、ユーザＩＤと、コンテンツＩＤと、課金理由と、課金額と、をサーバシステム１１００へ送信する（ステップＳ２２）。当該送信を「通信Ｃ」とする。

次いで、業務用ゲーム装置１３００は、サーバシステム１１００から通信Ｃへの返信として今回のコンテンツ内課金の課金完了（＝決済可：決済完了）または課金拒絶（＝決済不可：決済拒絶）を含む「通信Ｄ」を受信すると、当該通知の結果をプレーヤに通知制御する（ステップＳ２４）。

ステップＳ２０〜Ｓ２６は、サーバシステム１１００からゲームコンテンツの終了を通知する「通信Ｅ」を受信するか、自機で所定のゲームコンテンツ終了操作を検出するなど、ゲームコンテンツ終了条件を満たすまで繰り返される（ステップＳ２６のＮＯ）。ゲームコンテンツ終了条件を満たせば、サーバシステム１１００への通信接続を終了して（ステップＳ２８）、一連の処理を終了する。

なお、業務用ゲーム装置１３００で実行されるゲームコンテンツがコンテンツ内課金をサポートしないタイプであれば、ステップＳ２０〜Ｓ２４を省略すればよい。

図１３〜図１５は、本実施形態のサーバシステム１１００における処理の流れについて説明するためのフローチャートであって、サーバシステム１１００がサーバシステムプログラム５０１を実行した状態でユーザ登録管理プログラム５０３及びゲームコンテンツ管理プログラム５０５を実行することにより実装される。
なお、ユーザ登録については、公知の電子決済方式のオンラインゲームに係る会員登録やユーザ登録と同様に実現できるので、ここでの説明は省略する。そして、複数のユーザ登録データ６００が既に記憶されているものとする。

図１３に示すように、端末装置から通信Ａすなわちコンテンツ実行リクエストを受信すると（ステップＳ５０のＹＥＳ）、サーバシステム１１００は、実行リクエストされたゲームコンテンツが、リクエスト元ユーザに係るコンテンツ管理データ６１０を参照し、ゲームコンテンツ実行履歴６３０にて、実行中の状態（終了日時６３６が未定の状態：図１１で言うところのＮＵＬＬの状態）で登録されているかを判定する（ステップＳ５２）。

もし、実行中で登録されておらず（ステップＳ５２のＮＯ）、且つ、当該実行リクエストされたゲームコンテンツが、実行時に課金する設定である場合には（ステップＳ５４のＹＥＳ）、サーバシステム１１０は、実行リクエストに係る今回の課金要求に対して共遊時期条件を満たす過去の課金履歴が有るか判定する（ステップＳ５６）。

本実施形態における共遊時期条件は「第２の課金要求タイミング（今回の実行リクエストに係る課金要求）が、先行して実行されている他ゲームコンテンツに係る第１の課金要求タイミングからゲーム終了までの期間内」とされる。
よって、具体的には、先ずリクエスト元ユーザに係る全コンテンツ管理データ６１０のゲームコンテンツ実行履歴６３０（図１１参照）を参照して、今回実行リクエストされたゲームコンテンツとは異なるゲームコンテンツに対応していて、且つ、終了日時６３６が「ＮＵＬＬ」となっているゲームコンテンツ実行履歴６３０を検索する。更に、これに対応するコンテンツ管理データ６１０（図９参照）を検索する。これに対応するゲームコンテンツが「先行して実行されている他ゲームコンテンツ」を示す。次いで、検索されたコンテンツ管理データ６１０のゲームコンテンツ課金履歴６２０（図１０参照）から、最新の履歴の課金日時６２２を検索する。これが「第１の課金要求タイミング」を示す。
そして、該当するコンテンツ管理データ６１０または課金日時６２２が無ければステップＳ５６は“否定”とする。両者があればステップＳ５６は“肯定”とする。
もし、共遊時期条件の「ゲーム終了」を「所定期間」とする構成ならば、両者があって、且つ、検索された課金日時６２２と現在日時との時間差が所定期間内である場合にステップＳ５６は“肯定”とされる。

さて、ステップＳ５６が否定ならば（ステップＳ５６のＮＯ）、サーバシステム１１００はリクエスト元のユーザに対してプレイ対価の課金処理（決済処理）を実行し、当該ユーザに対応付けられ、且つ実行リクエストされたゲームコンテンツのゲームコンテンツ課金履歴６２０に当該課金の履歴を追加し、リクエスト元のユーザのユーザ登録データ６００の決済履歴６０５にも履歴を追加する（ステップＳ６０）。

次いで、サーバシステム１１００は、当該実行リクエストされたゲームコンテンツを終了日時６３６が未定の状態で登録、すなわち実行中として登録する（ステップＳ６２）。
そして、リクエスト元の端末装置を対象として、リクエストされたゲームコンテンツの進行制御を開始し（ステップＳ６４）、コンテンツ実行可の通知をリクエスト元の端末装置へ送信する（ステップＳ６６：通信Ｂ）。

なお、ゲームコンテンツの進行制御においては、ユーザに関連する情報（例えば、セーブデータ６１８など）を参照するプロセスでは、コンテンツ実行リクエストとともに受信したユーザＩＤとコンテンツ管理データ６１０のユーザＩＤ６１２とを照合して検索・参照することができる。勿論、受信したユーザＩＤに対応する認証済媒体ＩＤ６０３と、コンテンツ管理データ６１０の認証済媒体ＩＤ６１４との照合で検索・参照することもできる（図９参照）。

ステップＳ５６が肯定の場合でも（ステップＳ５６のＹＥＳ）、サーバシステム１１００は、実行リクエストされたゲームコンテンツと、共遊時期条件を満たす過去の課金履歴に係る他ゲームコンテンツとがコンテンツミックスの関係にあり、すなわち関係コンテンツ条件を満たす場合には（ステップＳ５８のＹＥＳ）、ステップＳ６０〜Ｓ６６を同様に実行する。

しかし、ステップＳ５８が否定の場合や（ステップＳ５８のＮＯ）、そもそもステップＳ５２で肯定された場合には（ステップＳ５２のＹＥ）、サーバシステム１１００は当該実行リクエストを拒絶し、リクエスト元の端末装置へ所定のコンテンツ実行を拒絶する通知を返信する（ステップＳ６８）。どちらの場合も、同じユーザＩＤを使って同じゲームを実行するのはユーザＩＤの不正利用の可能性があるからである。

図１４に移って、次に、サーバシステム１１００は、通信Ｃすなわちコンテンツ内課金リクエストを受信すると（ステップＳ９０のＹＥＳ）、当該課金リクエストに対して共遊時期条件を満たす過去の課金履歴が有るか判定する（ステップＳ９２）。

具体的には、先のステップＳ５６と同様にして、先ず当該課金リクエストに係るコンテンツ管理データ６１０のゲームコンテンツ実行履歴６３０（図１１参照）を参照して、今回の課金リクエストに係るゲームコンテンツとは異なるゲームコンテンツであって、且つ、終了日時６３６が未定のままのコンテンツ管理データ６１０を検索する。次いで、そのゲームコンテンツ課金履歴６２０（図１０参照）から、最新の履歴の課金日時６２２を検索する。そして、該当するコンテンツ管理データ６１０または課金日時６２２が無ければステップＳ９２は“否定”とする。両者があればステップＳ９２は“肯定”とする。

そして、もし否定ならば（ステップＳ９２のＮＯ）、サーバシステム１１００はリクエスト元のユーザに対して正規価格で課金処理を行う（ステップＳ９４）。そして、今回のコンテンツ内課金リクエストに係るゲームコンテンツに対応するゲームコンテンツ課金履歴６２０、及びリクエスト元ユーザの決済履歴６０５に今回の課金の履歴を残し（ステップＳ１１０）、リクエスト元へ課金完了、すなわち決済可、決済完了の通知を送信する（ステップＳ１１２：通信Ｄ）。

一方、ステップＳ９２が肯定の場合には（ステップＳ９２のＹＥＳ）、サーバシステム１１００は今回のコンテンツ内課金リクエストに係るゲームコンテンツと、共遊時期条件を満たす過去の課金履歴に係る他ゲームコンテンツとがコンテンツミックスの関係にあるか、すなわち関係コンテンツ条件を満たすか判定する（ステップＳ１００）。

そして、肯定の場合（ステップＳ１００のＹＥＳ）、サーバシステム１１００は、割引率を決定して（ステップＳ１０２）、決定された割引率を適用してリクエスト元のユーザに対する課金処理を実行する（ステップＳ１０４）。そして、今回のコンテンツ内課金リクエストに係るゲームコンテンツに対応するゲームコンテンツ課金履歴６２０、及びリクエスト元ユーザの決済履歴６０５に今回の課金の履歴を残し（ステップＳ１１０）、リクエスト元へ課金完了、すなわち決済可、決済完了の通知を送信する（ステップＳ１１２：通信Ｄ）。

もし、否定の場合には（ステップＳ１００のＮＯ）、リクエスト元へ課金拒絶、すなわち決済不可、決済拒絶の通知を送信する（ステップＳ１１４：通信Ｄ）。

図１５のフローチャートに移って、現在ゲームコンテンツを実行中のユーザ別（プレーヤ別）にループＡを実行する（ステップＳ１３０〜Ｓ１６８）。

ループＡでは、処理対象とされるユーザに係る実行中のゲームコンテンツ毎にループＢを実行する（ステップＳ１３２〜Ｓ１６６）。

ループＢにおいて、サーバシステム１１００は、ループＡの処理対象ユーザのユーザ登録データ６００のゲームコンテンツ実行履歴６３０を参照して、当該処理対象のゲームコンテンツとコンテンツミックスの関係がある他ゲームコンテンツが実行中であるかを判定する（ステップＳ１３４）。

もし、該当する他ゲームコンテンツが有るならば（ステップＳ１３４のＹＥＳ）、サーバシステム１１００は、更にループＢの処理対象のゲームコンテンツに係る最新の課金履歴の課金日時６２２と、該当する他ゲームコンテンツに係る最新の課金履歴の課金日時６２２との時間差が、所定の近接時間判定値以下（例えば、１０分以下）であるか判定する（ステップＳ１３６）。

そして、近接時間判定値以下ならば（ステップＳ１３６のＹＥＳ）、サーバシステム１１００は、次にループＢ処理対象のゲームコンテンツの終了条件パラメータ値７０２を参照し、終了条件が緩和されているかを判定する（ステップＳ１３８）。
参照した終了条件パラメータ値７０２が当該コンテンツの所定の初期値から変更されていなければ、終了条件はまだ緩和されていないと判断して（ステップＳ１３８のＮＯ）、サーバシステム１１００は当該ゲームコンテンツの終了条件を緩和処理する（ステップＳ１４２）。例えば、終了条件パラメータ値７０２に格納されている制限時間を加算する等の処理を行い、ゲームコンテンツをより長い時間楽しめるようにする。

次に、サーバシステム１１００は、ループＢの処理対象とされるゲームコンテンツの終了条件を満たしているか判定する。終了条件を満たしている場合と（ステップＳ１４２のＹＥＳ）、終了条件が満たしておらず、且つループＡの処理対象ユーザの端末装置と定期通信が維持されていない場合には（ステップＳ１４４のＮＯ）、サーバシステム１１００はループＢの処理対象のゲームコンテンツを終了させる（ステップＳ１６０）。

そして、ループＡの処理対象ユーザの端末装置へ所定のゲーム終了通知を送信し（ステップＳ１６２：通信Ｅ）、同ユーザのループＢの処理対象のゲームコンテンツに対応するゲームコンテンツ実行履歴６３０から終了させたゲームコンテンツの登録を抹消して（ステップＳ１６４）、ループＢを終了する（ステップＳ１６６）。

ループＡの処理対象ユーザに係る実行中のゲームコンテンツ全てについてループＢを実行したならば、次の処理対象ユーザについてループＡを実行する。そして、ゲームコンテンツ実行中の全てのユーザについてループＡを実行したならば（ステップＳ１６８）、ステップＳ５０（図１３参照）に戻る。

以上、本実施形態によれば、電子決済に利用可能な同一のユーザＩＤで利用登録した複数のゲームコンテンツを同時使用可能にして、電子決済を用いたゲームシステムの利便性を向上させることが可能となる。また、副次的に、例えユーザＩＤが不正利用されたとしても、ユーザＩＤの正規使用者が先に第１ゲームコンテンツＧ１をプレイさえしていれば、不正利用による第１ゲームコンテンツＧ１へは不利な影響はなく、知らないうちに課金されるといった事態も回避することができる効果が得られる。

また、ユーザＩＤと、口座情報（口座残高６０４や決済履歴６０５）と、ユーザが利用している複数のゲームコンテンツの利用状況に係る情報（コンテンツ管理データ６１０）とを対応づけて管理できる。

ユーザから見れば、どのゲームコンテンツを利用しても同じ口座からプレイ対価の支払が行われるので、複数のゲームコンテンツを利用する場合でも、口座への入出金の管理が一元化できるので、ゲームコンテンツ別に入出金管理するよりも遙かに利便性が高くなる。運営者の立場から見ても、決済状況の確認や、課金の拒絶や停止などの課金制御も一元的に管理可能になるので、ゲームコンテンツ別に管理・制御するよりも容易となる効果が得られる。

〔変形例〕
以上、本発明を適用した実施形態について説明したが、本発明を適用可能な形態は上記形態に限定されるものではなく、適宜構成要素の追加・省略・変更を施すことができる。

［その１］
例えば、上記実施形態では、ゲーム進行制御に係る主だった処理をサーバシステム１１００にて実行する構成としたが、演算処理の一部を業務用ゲーム装置１３００とで分散して実行させる構成も可能である。

［その２］
また、共遊時期条件を「第２の課金要求タイミングが、先行して実行されている他ゲームコンテンツに係る第１の課金要求タイミングからゲーム終了までの期間内」としているが、ここで言う「ゲーム終了」を「所定時間（例えば２４時間）」と言った具合に、ゲーム終了後プラスαの時間、或いは、第１の課金要求タイミングから所定時間が経過するまでの間を共遊時期条件に設定することができる。例えば、図４の例で言えば、第１ゲームコンテンツＧ１を終了した後に自分のプレイを反省したプレーヤが、速やかに第４ゲームコンテンツＧ４で必要なアイテムを購入した場合でも特典が得られるようになる。

［その３］
また、ケース２ｂ（図６のケース）については、後から実行開始されたゲームコンテンツ（図６の例では第３ゲームコンテンツＧ３）に係る決済（例えば、コンテンツ内課金）は拒絶される一方で、先行するゲームコンテンツ（図６の例では第１ゲームコンテンツＧ１）に係る決済（例えば、コンテンツ内課金）は継続的に許可される構成とした。しかし、第３ゲームコンテンツＧ３が実行開始された後は、第１ゲームコンテンツＧ１の決済についても拒絶する構成としてもよい。

具体的には、コンテンツ管理データ６１０に、拒絶フラグを用意する。拒絶フラグは初期値「０」とされる。そして、処理の流れとしては、後から実行開始されたゲームコンテンツ（図６の例では第３ゲームコンテンツＧ３）係る決済が拒絶されたときに（図１４のステップＳ１００のＮＯ）、ステップＳ９２に係り検索されたコンテンツ管理データ６１０（図９参照、図６の例では第１ゲームコンテンツＧ１に該当）の拒絶フラグを「１」に変更するステップを追加する。そして、当該追加されたステップを経てステップＳ１１４を実行する。更に、ステップＳ９２とステップＳ９４の間に、コンテンツ内課金リクエストされたゲームコンテンツの拒絶フラグを参照し、当該フラグが「０」の場合にステップＳ９４に流れる構成とすればよい。なお、後から実行開始されたゲームコンテンツが終了すると、拒絶フラグは「０」に戻されるステップを適宜設けることとする。

［その４］
ケース２ａ（図５のケース）については、後から実行開始されたゲームコンテンツ（図５の例では第２ゲームコンテンツＧ２または第４ゲームコンテンツＧ４）に係る決済に適用された割引特典を、先行するゲームコンテンツ（図５の例では第１ゲームコンテンツＧ１）に係る決済にも適用させる構成も可能である。
具体的には、コンテンツ管理データ６１０に、割引フラグを用意する。割引フラグは初期値「０」とされる。そして、処理の流れとしては、後から実行開始されたゲームコンテンツに係る決済が許可される場合に（図１４のステップＳ１００のＹＥＳ）、ステップＳ９２に係り検索されたコンテンツ管理データ６１０の割引フラグを「１」に変更するステップを追加実行する構成とする。そして、ステップＳ９２とステップＳ９４の間に、コンテンツ内課金リクエストされたゲームコンテンツの割引フラグを参照し、当該フラグが「１」の場合にステップＳ９４にて割引を適用する構成とすればよい。なお、割引率はステップＳ１０２で算出された割引率を記憶しておいてこれを参照するとしてもよいし、所定値を適用するとしてもよい。なお、後から実行開始されたゲームコンテンツが終了すると、割引フラグは「０」に戻されるステップを適宜設けることとする。

［その５］
また、上記実施形態における「決済」や「課金」を「特典の付与」に読み替えた構成も可能である。特に、課金により取得可能な特典や、課金の代替と考えられる特典（例えば、クーポン券、音楽ゲームならばプレイする楽曲をスタンダードからロングバージョンに変更する、など）の付与に置き換えた構成も可能である。

２…プレーヤ
６…電子決済用媒体
２００ｓ…サーバ処理部
２１０…ユーザ登録管理部
２１２…決済処理部
２１４…共遊時期条件判定部
２１６…関連コンテンツ条件判定部
２１８…割引処理部
２２０…課金履歴管理部
２３０…ゲームコンテンツ管理部
２３１…第１ゲームコンテンツ制御部
２３２…第２ゲームコンテンツ制御部
２４０…終了条件緩和制御部
５００ｓ…サーバ記憶部
５０１…サーバシステムプログラム
５０３…ユーザ登録管理プログラム
５０５…ゲームコンテンツ管理プログラム
５１０…プログラムファイル
５１２…初期設定ファイル
５３０…関連コンテンツ設定データ
５３２…特典設定データ
６００…ユーザ登録データ
６０２…ユーザＩＤ
６０３…認証済媒体ＩＤ
６０４…口座残高
６０５…決済履歴
６１０…コンテンツ管理データ６１０
６１２…ユーザＩＤ
６１６…コンテンツＩＤ
６１８…セーブデータ
６２０…ゲームコンテンツ課金履歴
６２２…課金日時
６２４…課金理由
６２６…課金額
６３０…ゲームコンテンツ実行履歴
６３２…開始日時
６３６…終了日時
７００…プレイデータ
７０２…終了条件パラメータ値
１１００…サーバシステム
１１５０…制御基板
１３００…業務用ゲーム装置
１３４４…媒体読取装置
１３５０…制御基板
１５００…スマートフォン
１５４４…媒体読取装置
１５５０…制御基板

Claims (12)

1. ユーザの仮想通貨の口座を管理し、端末装置からのゲームコンテンツに係る課金要求に対して前記口座からの決済処理を実行するサーバシステムであって、
   第１の端末装置から第１の課金要求を受信し、且つ、第２の端末装置から第２の課金要求を受信したときに、両者の課金要求のタイミングが所定の共遊時期条件を満たさない場合、又は、前記共遊時期条件を満たし、且つ、両者の課金要求に係るゲームコンテンツが所定関係であることを示す関連コンテンツ条件を満たす場合に、両者の課金要求に対する決済処理を実行する決済処理手段、
   を備えたサーバシステム。
2. 前記決済処理手段は、前記共遊時期条件を満たし、且つ、前記関連コンテンツ条件を満たさない場合には、何れか一方又は両方の課金要求に対する決済処理を拒絶する、
   請求項１に記載のサーバシステム。
3. 前記決済処理手段は、前記両者の課金要求に係るゲームコンテンツのうち、一方が前記第１の端末装置で実行されるゲームプレイ用コンテンツであり、他方が前記ゲームプレイ用コンテンツのゲームプレイに影響が及ぶゲームプレイ以外の前記第２の端末装置で実行されるコンテンツであることを前記関連コンテンツ条件として、前記関連コンテンツ条件を満たすか否かを判定する、
   請求項１又は２に記載のサーバシステム。
4. 前記両者の課金要求に係るゲームコンテンツは、一方又は両方がゲームプレイ用コンテンツであり、
   前記決済処理手段は、前記ゲームプレイ用コンテンツのプレイ期間を用いて前記共遊時期条件を満たすか否かを判定する、
   請求項１〜３の何れか一項に記載のサーバシステム。
5. 前記共遊時期条件を満たし、且つ、前記関連コンテンツ条件を満たす場合に、所与の特典を付与する特典付与処理を実行する特典付与手段、
   を更に備えた請求項１〜３の何れか一項に記載のサーバシステム。
6. 前記特典付与手段は、前記両者の課金要求の一方又は両方の価額を割り引く割引処理手段を有する、
   請求項５に記載のサーバシステム。
7. 前記割引処理手段は、前記両者の課金要求のタイミングに基づいて、割り引く内容を変更する、
   請求項６に記載のサーバシステム。
8. 前記両者の課金要求に係るゲームコンテンツは、一方がゲームプレイ用コンテンツであり、他方がゲームプレイ以外のコンテンツであり、
   前記割引処理手段は、前記ゲームプレイ用コンテンツのゲームプレイ中に、前記ゲームプレイ以外のコンテンツに係る課金要求がなされた回数又は課金額に基づいて、割り引く内容を変更する、
   請求項６に記載のサーバシステム。
9. 前記両者の課金要求に係るゲームコンテンツは、一方又は両方がゲームプレイ用コンテンツであり、
   前記特典付与手段は、前記ゲームプレイ用コンテンツのゲームプレイ時間を延長する処理を前記特典付与処理として実行する、
   請求項５〜８の何れか一項に記載のサーバシステム。
10. 前記両者の課金要求に係るゲームコンテンツは、一方がゲームプレイ用コンテンツであり、他方がゲームプレイ以外のコンテンツであり、
    前記特典付与手段は、前記ゲームプレイ以外のコンテンツに係る課金要求の価額に応じて、前記特典を可変に設定する、
    請求項５〜８の何れか一項に記載のサーバシステム。
11. 前記ゲームコンテンツの実行をユーザＩＤを用いて管理するとともに、前記口座を当該ユーザの前記ユーザＩＤと対応付けて管理する、
    請求項１〜１０の何れか一項に記載のサーバシステム。
12. 前記決済処理手段は、前記課金要求に応じた価額の前記仮想通貨を前記口座から消費することで前記決済処理を実行する、
    請求項１１に記載のサーバシステム。

Images