(57)【特許請求の範囲】
【請求項１】
第１ユーザによるゲーム内課金を第２ユーザが管理する管理サーバであって、
前記第１ユーザと前記第２ユーザとを紐づけて記憶する記憶部を備え、
前記第１ユーザが使用する第１ユーザ端末から課金要求を受付ける課金応答部と、
前記課金要求に基づいて前記第２ユーザが使用する第２ユーザ端末に所定の通知を行う通知部と、
前記第２ユーザ端末から課金の条件に関する設定情報を受け付ける管理設定受付部と、
前記課金要求が前記条件に合致しているか否かを判定する判定部とを備え、
前記通知部は、前記判定部が前記課金要求が前記条件に合致していないと判定した場合に、前記第２ユーザ端末に許可を求める通知を送信し、
前記条件は所定期間における課金合計額の上限額を含み、
前記判定部は、共通のＳＮＳアカウントに関連付けられた複数のゲームプログラムにおける前記第１ユーザの課金額の合計額を算出し、前記上限額と比較する、
ことを特徴とする、管理サーバ。
【請求項２】
前記課金応答部は、前記第２ユーザ端末から前記課金要求を許可する旨の情報を受付けた場合に前記第１ユーザ端末に対して課金処理を実行することを特徴とする、請求項１に記載の管理サーバ。
【請求項３】
前記通知部は、
前記上限額に関する情報を前記第１ユーザ端末に表示させることを特徴とする、請求項１または２のいずれかに記載の管理サーバ。
【請求項４】
前記判定部は、
前記課金要求に係る金額が、前記上限額から前記所定期間における前記第１ユーザの課金合計額を差し引いた課金可能残額よりも少ないか否かを判定することを特徴とする、請求項１ないし３のいずれかに記載の管理サーバ。
【請求項５】
第１ユーザによるゲーム内課金を第２ユーザが管理するための課金管理プログラムであって、
コンピュータに、
前記第１ユーザと前記第２ユーザとを紐づけて記憶する処理と、
前記第１ユーザが使用する第１ユーザ端末から課金要求を受付ける課金応答処理と、
前記課金要求に基づいて前記第２ユーザが使用する第２ユーザ端末に所定の通知を行う通知処理と、
前記第２ユーザ端末から課金の条件に関する設定情報を受け付ける管理設定受付処理と、
前記課金要求が前記条件に合致しているか否かを判定する判定処理と、
を実行させ、
前記通知処理は、前記判定処理が前記課金要求が前記条件に合致していないと判定した場合に、前記第２ユーザ端末に許可を求める通知を送信し、
前記条件は所定期間における課金合計額の上限額を含み、
前記判定処理は、共通のＳＮＳアカウントに関連付けられた複数のゲームプログラムにおける前記第１ユーザの課金額の合計額を算出し、前記上限額と比較する、
ことを特徴とする、課金管理プログラム。
【請求項６】
第１ユーザによるゲーム内課金を第２ユーザが管理するための課金管理方法であって、
前記第１ユーザと前記第２ユーザとを紐づけて記憶するステップと、
前記第１ユーザが使用する第１ユーザ端末から課金要求を受付ける課金応答ステップと、
前記課金要求に基づいて前記第２ユーザが使用する第２ユーザ端末に所定の通知を行う通知ステップと
前記第２ユーザ端末から課金の条件に関する設定情報を受け付ける管理設定受付ステップと、
前記課金要求が前記条件に合致しているか否かを判定する判定ステップと、
を有し、
前記通知ステップは、前記判定ステップが前記課金要求が前記条件に合致していないと判定した場合に、前記第２ユーザ端末に許可を求める通知を送信し、
前記条件は所定期間における課金合計額の上限額を含み、
前記判定ステップは、共通のＳＮＳアカウントに関連付けられた複数のゲームプログラムにおける前記第１ユーザの課金額の合計額を算出し、前記上限額と比較する、
ことを特徴とする、コンピュータによる課金管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は課金管理サーバ、課金管理プログラム、課金管理方法に関する。
【背景技術】
【０００２】
特許文献１には、子供がゲームをしすぎないように子供のゲーム端末に親がプレイ時間の制限をかけることのできるゲームシステムが開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１９−５３２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、スマートフォン等で提供されるゲームにあっては、ゲーム内で使用するアイテム等を入手するために課金するゲーム内課金システムが採用されている。しかし、未成年には、自らの経済状況に適したゲーム内課金の利用判定が難しい場合がある。上述した技術には、子供のゲーム内課金を効果的に制限することは記載されていない。
【０００５】
そこで、本発明は、管理者が被管理者のゲーム内課金を効果的に制限することのできる課金管理システムを提供することを一つの目的とする。
【課題を解決するための手段】
【０００６】
本発明によれば、第１ユーザによるゲーム内課金を第２ユーザが管理するための課金管理サーバであって、前記第１ユーザと前記第２ユーザとを紐づけて記憶する記憶部を備え、前記第１ユーザが使用する第１ユーザ端末から課金要求を受付ける課金応答部と、
前記課金要求に基づいて前記第２ユーザが使用する第２ユーザ端末に所定の通知を行う通知部とを備えることを特徴とする課金管理サーバ、課金管理プログラム、課金管理方法が得られる。
【発明の効果】
【０００７】
本発明によれば、被管理者のゲーム内課金を効果的に制限することのできる課金管理システムを提供することができる。
【図面の簡単な説明】
【０００８】
【図１】本発明の実施の形態によるシステムの構成例を示す図である。
【図２】本発明の実施の形態によるサーバ装置１の構成例を示す図である。
【図３】本発明の実施の形態による第１ユーザ端末の構成例を示す図である。
【図４】本発明の実施の形態による管理設定情報の構成例を示す図である。
【図５】本発明の実施の形態による第２ユーザ端末画面の構成例を示す図である。
【図６】本発明の実施の形態によるユーザ端末画面の構成例を示す図である。
【図７】本発明の実施の形態による第１ユーザ端末画面の構成例を示す図である。
【図８】本発明の実施の形態による処理フローの一例を示す図である。
【図９】本発明の実施の形態による第２ユーザ端末画面の構成例を示す図である。
【図１０】本発明の実施の形態による第２ユーザ端末画面の構成例を示す図である。
【発明を実施するための形態】
【０００９】
本発明の実施形態の内容を列記して説明する。本発明は、以下のような構成を備える。
［項目１］
第１ユーザによるゲーム内課金を第２ユーザが管理するための課金管理サーバであって、
前記第１ユーザと前記第２ユーザとを紐づけて記憶する記憶部を備え、
前記第１ユーザが使用する第１ユーザ端末から課金要求を受付ける課金応答部と、
前記課金要求に基づいて前記第２ユーザが使用する第２ユーザ端末に所定の通知を行う通知部とを備えることを特徴とする、課金管理サーバ。
［項目２］
前記第２ユーザ端末から課金の条件に関する設定情報を受け付ける管理設定受付部と、
前記課金要求が前記条件に合致しているか否かを判定する判定部とをさらに備え、
前記通知部は、前記判定部が前記課金要求が前記条件に合致していないと判定した場合に、前記第２ユーザ端末に許可を求める通知を送信し、
前記課金応答部は、前記第２ユーザ端末から前記課金要求を許可する旨の情報を受付けた場合に前記第１ユーザ端末に対して課金処理を実行することを特徴とする、項目１に記載の課金管理サーバ。
［項目３］
前記条件は課金の上限額を含み、
前記判定部は、前記課金要求に係る課金額が前記上限額を超えているか否かを判定することを特徴とする、項目２に記載の課金管理サーバ。
［項目４］
前記通知部は、
前記条件に係る上限額に関する情報を前記第１ユーザ端末に表示させることを特徴とする、項目３に記載の課金管理サーバ。
［項目５］
前記条件は所定期間における課金合計額の上限額を含み、
前記判定部は、
前記課金要求に係る金額が、前記上限額から前記所定期間における前記第１ユーザの課金合計額を差し引いた課金可能残額よりも少ないか否かを判定することを特徴とする、項目２に記載の課金管理サーバ。
［項目６］
前記判定部は、複数のゲームプログラムにおける前記第１ユーザの課金額の合計額を算出し、前記上限額と比較することを特徴とする請求項５に記載の課金管理サーバ。
［項目７］
第１ユーザによるゲーム内課金を第２ユーザが管理するための課金管理プログラムであって、
コンピュータに、
前記第１ユーザと前記第２ユーザとを紐づけて記憶する処理と、
前記第１ユーザが使用する第１ユーザ端末から課金要求を受付ける課金応答処理と、
前記課金要求に基づいて前記第２ユーザが使用する第２ユーザ端末に所定の通知を行う通知処理と
を実行させることを特徴とする、課金管理プログラム。
［項目８］
第１ユーザによるゲーム内課金を第２ユーザが管理するための課金管理方法であって、
前記第１ユーザと前記第２ユーザとを紐づけて記憶するステップと、
前記第１ユーザが使用する第１ユーザ端末から課金要求を受付ける課金応答ステップと、
前記課金要求に基づいて前記第２ユーザが使用する第２ユーザ端末に所定の通知を行う通知ステップと
を有することを特徴とする、コンピュータによる課金管理方法。
【００１０】
以下、本発明の実施の形態について、図面を参照しながら説明する。
【００１１】
＜構成＞
図１に示されるように、本課金管理システムは、ネットワーク４（例えば、インターネット等）を介してゲームに関する各種サービスをユーザに提供する。本実施の形態において、本課金管理システムは、サーバ装置１と、第２ユーザにより管理される被管理者である第１ユーザが使用する第１ユーザ端末２と、第１ユーザの課金に関する管理を行う管理者である第２ユーザが使用する第２ユーザ端末３と、とで構成される。なお、図１では第１ユーザ端末２及び第２ユーザ端末３を１台ずつ記載しているが、複数の第１ユーザ端末２及び第２ユーザ端末３がサーバ装置１と接続可能である。
【００１２】
＜サーバ装置１の構成＞
図２は、サーバ装置１の機能上の構成を示すブロック図である。サーバ装置１は、システム管理者等が各種サービスを運営・管理する際に利用する情報処理装置であり、例えば、ワークステーションやパーソナルコンピュータのような汎用コンピュータとしてもよいし、或いはクラウド・コンピューティング技術によって論理的に実現されてもよい。本実施形態において、サーバ装置１は、ゲームプログラム（課金管理プログラムを含む）の実行に係る処理を行う役割とともに、第２ユーザによる第１ユーザの課金の管理に関するシステムを提供する役割を担う前提で以下説明するが、これらをそれぞれ別のサーバで実行することとしてもよい。
【００１３】
サーバ装置１は、制御部１１、記憶部１２、入力部１３、表示部１４、通信部１５を有する。サーバ装置１は、通信部１５を介してユーザ端末２、３から各種の情報を受信すると、制御部１１において所定の処理を実行し、処理結果をユーザ端末２、３へ送信する。ゲームプログラムの実行に関しては、ユーザ端末２、３からコマンド（リクエスト）を受信すると、制御部１１においてゲームプログラムによる処理を実行し、ゲームプログラムの処理結果（例えば、ゲーム画像やゲーム音声等）がユーザ端末２、３へ送信される。なお、上記プログラムの一部は、ユーザ端末２、３に送信されてユーザ端末２、３上で実行されてもよい。
【００１４】
制御部１１は、各部間のデータの受け渡しを行うとともに、サーバ装置１全体の制御を行うものであり、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）が所定のメモリに格納されたプログラムを実行することによって実現される。本実施の形態の制御部１１は、少なくともゲーム実行部１１１、画面データ生成部１１２、課金応答部１１３、管理設定受付部１１４、判定部１１５、通知部１１６を備える。なお、これらの各種機能部については追って詳述する。
【００１５】
記憶部１２は、システムプログラムが記憶された読取専用の記憶領域であるＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）と、制御部１１による演算処理のワーク領域として使用される書き換え可能な記憶領域であるＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）とを有しており、例えば、フラッシュメモリやハードディスクなどの不揮発性記憶装置によって実現される。本実施形態における記憶部１２は、ゲーム情報記憶部１２１、プレイヤ情報記憶部１２２、管理情報記憶部１２３等の各種記憶部を有している。なお、これらの各種情報については追って詳述する。
【００１６】
入力部１３はシステム管理者がゲームサービスに関する各種データ（例えば、ゲーム情報等）を入力するためのものであり、例えばキーボードやマウス等によって実現される。
【００１７】
表示部１４は、制御部１１からの指令に基づいてシステム管理者用の操作画面を表示するためのものであり、例えば、液晶ディスプレイ（ＬＣＤ：Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ）等によって実現される。
【００１８】
通信部１５は、ユーザ端末２、３との間で通信を行うためのものであり、ユーザ端末２、３から送信される各種データや信号を受信する受信部としての機能と、制御部１１の指令に応じて各種データや信号をユーザ端末２、３へ送信する送信部としての機能を有している。通信部１５は、例えばＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）やＨＴＴＰＳ、ＷｅｂＳｏｃｋｅｔ、Ｐ２Ｐ（Ｐｅｅｒ  Ｔｏ  Ｐｅｅｒ）等によりユーザ端末２、３との通信を行う。
【００１９】
＜第１ユーザ端末２＞
図３は、第１ユーザ端末２の機能上の構成を表すブロック図である。第１ユーザ端末２は、第１ユーザが所持し利用することができる情報処理装置（例えば、スマートフォン、携帯電話端末、タブレット端末）である。第１ユーザ端末２は、サーバ装置１から送信されたゲームプログラムの処理結果をゲームアプリケーションまたはＷｅｂブラウザを介して出力（例えば、ゲーム画面表示、ゲーム音声出力等）することができる。第１ユーザ端末２は、第１ユーザ端末２全体の制御を行う制御部２１と、各種データ・プログラムを記憶する記憶部２２と、ユーザが操作入力を行うための入力部２３、ゲーム画面・操作画面等を出力する出力部２４、サーバ装置１との間で情報通信を行う通信部２５を有している。本実施の形態の制御部２１は、少なくとも操作情報受付部２１１、ゲーム動作部２１２を備える。また、記憶部２２は、少なくともゲーム動作情報記憶部２２１を備える。制御部２１の各機能部は、メモリやゲーム動作情報記憶部２２１に格納されているプログラムをＣＰＵが実行することにより実現することができる。
【００２０】
第１ユーザ端末２の操作情報受付部２１１は、プレイヤ（第１ユーザ）からゲームに関する操作を受け付ける。操作情報受付部２１１は、入力部２３を用いたゲームに関する操作を受け付ける。そして、操作情報受付部２１１は、受け付けた操作内容をゲーム動作部２１２に出力する。
【００２１】
ゲーム動作部２１２は、ゲームを動作させるための処理を実行する。ゲーム動作部２１２は、ゲーム動作情報記憶部２２１に記憶されたゲーム動作情報に含まれるゲームソフトウェアと、入力部２３から入力されたプレイヤの操作内容とに基づいてゲームを動作させる。ゲーム動作部２１２は、ゲームの動作に伴い、ゲーム動作情報に含まれる画像データからゲーム用の画像を生成し、生成した画像を出力部２４に出力させるための制御処理を行う。同様にして、ゲーム動作部２１２は、ゲームの動作に伴い、ゲーム動作情報に含まれる音楽データや音声データからゲーム用の音楽や音声を生成し、生成した音楽や音声を出力部２４から出力させるための制御処理を行う。なお、ここでは、ネイティブアプリがＷｅｂアプリの機能を一部実行する、すなわち、第１ユーザ端末２のゲーム動作部２１２がサーバ装置１の機能を一部実行する構成について説明したが、ゲーム動作部２１２を有さずにサーバ装置１が処理結果として全てのゲーム用画像、音声を生成するように構成されていてもよいし、ゲーム動作部２１２によって全てのゲーム用画像、音声を生成するように構成されていてもよい。
【００２２】
ゲーム動作部２１２を有する場合、ゲーム動作部２１２が動作させるゲームにおける所定のパラメータはサーバ装置１にて管理されることができる。例えば、ゲームにおけるスタミナや、有償ポイントといったパラメータが、サーバ装置１にて管理される。そのため、ゲーム動作部２１２は、ゲームにおいてこれらの所定のパラメータの変化が伴う処理が発生する場合には、サーバ装置１との通信を行うことにより、サーバ装置１が管理するパラメータを更新させる。そして、ゲーム動作部２１２は、更新後のパラメータをサーバ装置１から受信し、この更新後のパラメータに基づいてゲームの動作を継続する。
【００２３】
第１ユーザの管理者である第２ユーザが使用する第２ユーザ端末３は、第１ユーザ端末２と同様の構成を有していてもよいし、第２ユーザ端末３は上記ゲームの実行に関する構成を有さず、本実施の形態に係る処理を実現するための管理専用のアプリがインストールされてもよい。第２ユーザ端末３は、第２ユーザが所持し利用することができる情報処理装置（例えば、スマートフォン、携帯電話端末、タブレット端末）である。第２ユーザ端末３は、図示しないが、サーバ装置１から送信された課金管理プログラムの処理結果を専用アプリケーションまたはＷｅｂブラウザを介して出力することができる。第２ユーザ端末３は、第２ユーザ端末３全体の制御を行う制御部３１と、各種データ・プログラムを記憶する記憶部３２と、第２ユーザが操作入力を行うための入力部３３、ゲーム画面・操作画面等を出力する出力部３４、サーバ装置１との間で情報通信を行う通信部３５を有している。
【００２４】
本実施形態における課金管理システムは、第１ユーザによるゲーム内課金に関して、第１ユーザの管理者である第２ユーザが所定の管理を行うことができるものである。第２ユーザは典型的には第１ユーザの親などの家族であるが、その他友人などであってもよい。第１ユーザは、現実世界の通貨等による購入手続き（現金や電子マネーの支払い、クレジットカード決済等）によって取得可能なゲーム内通貨を取得したり、ゲーム内で使用可能なアイテムなどを購入することができる。
【００２５】
サーバ装置１のゲーム情報記憶部１２１は、ゲームに関する情報を記憶する。ゲーム情報は、ゲームの種類に応じて適宜構成される。例えば対戦ゲームである場合は、ステージＩＤに紐づけて、ステージ名、敵キャラクタ情報等を含む。
【００２６】
プレイヤ情報記憶部１２２は、プレイヤに関する情報を記憶する。プレイヤ情報には、プレイヤＩＤに紐づけて、プレイヤ名、所有キャラクタ情報、プレイステージ情報、所有アイテム情報等を含むことができる。なお、本実施の形態における第１ユーザはプレイヤであるので、プレイヤ情報には第１ユーザのプレイヤとしての情報が格納される。第２ユーザは必ずしもプレイヤでないが、第２ユーザもプレイヤである場合は、プレイヤ情報には第２ユーザのプレイヤとしての情報が格納される。所有キャラクタ情報は、所有キャラクタのＩＤに対応付けて、レベル、攻撃力、防御力、体力などの各種パラメータの現在値を含むことができる。プレイステージ情報は、設定された複数のステージのうち、プレイヤがこれまでにプレイしたことのあるステージに関する情報であり、プレイ回数、クリア情報等を含むことができる。所有アイテム情報は、1つ以上の有償ポイント及び無償アイテムの保有状況に関する情報を含み、各所有アイテムのＩＤに対応付けて、保有数などの情報を含むことができる。その他、プレイヤ及びゲームのプレイ状況に関する情報を含むことができる。
【００２７】
サーバ装置１のゲーム実行部１１１は、ゲームプログラムに従ってゲームを進行させる処理を実行する機能を有している。本実施形態におけるゲームシステムによるゲームは、任意の種類のゲームであってよく、例えば対戦ゲーム、パズルゲーム、アクションゲーム、野球ゲーム、サッカーゲーム、その他スポーツゲーム、クイズゲーム、ピンボールゲーム、カードゲーム、リズムゲーム、ＲＰＧ、アドベンチャーゲーム、カジノゲーム、シミュレーションゲーム、ストラテジーゲーム、ボードゲーム、レーシングゲームなどであってよい。
【００２８】
画面データ生成部１１２は、ゲーム画面を第１ユーザ端末２に表示させるための画面データを生成する処理を実行する機能を有している。画面データ生成部１１２は、上記の任意のゲームに関する画面データを生成する。生成された画面データは、第１ユーザ端末２に送信されて、出力部２４により出力される。
【００２９】
課金応答部１１３は、第１ユーザからの課金要求に応じて、課金処理を行い、課金額に応じた有償ポイントやアイテムを第１ユーザに付与する。具体的には、当該第１ユーザに紐づいた有償ポイントやアイテムの保有数を購入数分増加させる。または、第１ユーザによる課金要求について第２ユーザに許可を求め、許可情報が得られた場合に課金処理を行う。
【００３０】
管理設定受付部１１４は、課金管理に関する情報の入力を第１ユーザ又は第２ユーザから受け付ける。入力された管理情報は、管理情報記憶部１２３に格納される。図４は、管理情報記憶部１２３に格納される管理情報の構成例である。まず、課金設定受付部１１４は、管理者である第２ユーザと、被管理者である第１ユーザの情報を登録する。第２ユーザは、自身の端末３を介して、管理したい第１ユーザの情報を入力することができる。入力する第１ユーザの情報は、第１ユーザのゲームにおけるプレイヤＩＤ、ゲームアカウント名、ゲームと連携しているＳＮＳアカウント名、第１ユーザ端末２の端末識別番号（シリアル番号、ＩＭＥＩなど）、氏名、携帯電話番号、住所などであり、第１ユーザの所定のゲームにおけるプレイヤ情報を特定可能な情報である。なお、管理設定受付部１１４が、管理者である第２ユーザから管理情報の入力を受け付けた場合に、被管理者である第１ユーザ（第１ユーザ端末２）に対して、管理されることに同意するか否かを確認するようにしてもよい。その場合、例えば、上記第２ユーザから管理情報の入力を受け付けた際に、サーバ装置１の制御部１１が第１ユーザ端末２に同意の有無を確認する通知（メッセージ等）を送信する。そして、第１ユーザは端末２を操作して、管理されることに同意するか否かを示す情報をサーバ装置１に送信（返信）する。サーバ装置１は、第１ユーザ端末２から管理されることに同意した通知を取得した場合に限り、第２ユーザ端末３による第１ユーザ端末２の課金管理を可能とすることができる。
【００３１】
また、第２ユーザは、管理の設定に関する情報を入力することができる。例えば、１回当たりの課金上限額、１日当たりの課金上限額、１か月当たりの課金上限額等を任意で設定することができる。そのほか、課金可能な回数、頻度、時間帯等を設定してもよい。また、課金要求時には額や回数、頻度、時間に関わらず必ず第２ユーザの許可を得るように設定することもできる。また、第２ユーザが通知を受け取るタイミングに関する情報を設定することもできる。例えば上記課金上限を超える場合に、課金処理前に通知するのか、課金処理後に通知するのか等を設定することができる。
【００３２】
判定部１１５は、第１ユーザの課金要求について、管理情報に基づいて、課金の可否を判定する。すなわち、まず、第１ユーザが、課金管理の被管理者として登録されたユーザであるかを、管理情報記憶部１２３を参照することによって判定する。第１ユーザが被管理者として登録されたユーザでなければ、判定部１１５は課金可能と判定する。第１ユーザが被管理者として登録されたユーザであった場合は、管理者に許可を取る必要があるか否かを判定する。すなわち、課金要求が管理情報に登録された課金制限を満たしているか否かを確認し、満たしていない場合は、管理者に許可を取る必要があると判定する。例えば、１回当たりの課金上限額が設定されている場合、課金要求額が当該課金上限額を上回るか否かを判定し、所定期間あたりの合計課金上限額が設定されている場合、当該所定期間における過去の課金額の合計に今回の課金要求額を加算した額が当該課金上限額を上回るか否かを判定する。管理者に許可を取る必要がないと判定された場合、判定部１１５は課金可能と判定する。
【００３３】
課金応答部１１３は、判定部１１５による判定結果が、「課金可能」であった場合、第１ユーザに対して課金処理を実行する。また、通知部１１６は、第１ユーザが被管理者登録されているユーザである場合、当該課金に係る情報を第２ユーザ端末３に対して通知してもよい。図５は、第２ユーザ端末３の画面構成例である。図５（ａ）は、被管理者である第１ユーザ「太郎さん」が課金したことに関する通知（課金時間、課金額）や、今月の課金額合計、今月の設定課金上限額などを表示している。また、第１ユーザの課金履歴を表示することも可能である。例えば「太郎さんの課金履歴を見る」ことを要求するボタン４１を第２ユーザがタップすることによって、図５（ｂ）のような課金履歴情報を表示してもよい。図５（ｂ）では、過去の所定期間における課金時間、課金額等の情報を列挙している。
【００３４】
また、課金応答部１１３は、判定部１１５が、管理者に許可を取る必要があると判定した場合、第２ユーザに許可確認を行う。図６（ａ）は、管理者である第２ユーザ端末の画面表示例である。被管理者である第１ユーザ「太郎さん」が課金要求したことに関する通知（課金要求時間、課金要求額）と、それに対する返答のためのボタン４２、４３が表示されている。また、第２ユーザの今月の課金額合計、今月の設定課金上限額などを表示している。上限額からすでに課金した額を引いた課金可能残額を表示してもよい。第１ユーザは、課金を許可する場合に「許可する」ことを返すボタン４２をタップし、課金を許可しない場合に「許可しない」ことを返すボタン４３をタップすることで、サーバ装置１に対して返答を行うことができる。課金応答部１１３は、第２ユーザから「許可する」旨の返答を受信した場合、第１ユーザに対して課金処理を実行する。また、第２ユーザから「許可しない」旨の返答を受信した場合、課金応答部１１３は課金処理を行わず、第１ユーザ端末２に対して課金が許可されなかった旨の通知を行う。図６（ｂ）は、第１ユーザ端末２の画面表示例である。課金が許可されなかった旨のメッセージとともに、所定期間の課金額や課金上限、及び上限額からすでに課金した額を引いた課金可能残額等を表示してもよい。
【００３５】
また、ユーザが被管理者である場合は、ゲーム内通貨やアイテムを購入する画面において、課金制限に関する情報を表示してもよい。図７は、第１ユーザ端末２におけるゲーム内通貨を購入する際の画面表示例である。一例として、上限額からすでに課金した額を引いた課金可能残額（今月の利用可能額）を表示している。第１ユーザは、利用可能額を見ながら購入することができる。
【００３６】
図８は、本実施形態におけるシステムの基本動作例を説明するフロー図である。まず、第１ユーザはゲーム中でゲーム内通貨やアイテムを購入するために、課金要求をサーバ１に送信する（Ｓ１０１）。課金要求は、プレイヤＩＤ等の第１ユーザの識別情報と、課金要求額等の情報を含む。サーバ１の判定部１１５は、当該第１ユーザが管理対象者であるかを管理情報記憶部１２３を参照することによって確認する（Ｓ１０２）。被管理者でない場合（Ｓ１０２＝Ｎｏ）、Ｓ１０６に進む。第１ユーザが被管理者である場合（Ｓ１０２＝Ｙｅｓ）、さらに課金制限情報に照らして、今回の課金要求について管理者の許可が必要かどうかを判定する（Ｓ１０３）。すなわち、課金額が一定以上であれば管理者の許可を必要とする旨の設定がある場合は、課金要求額が当該設定上限額を超えているかを確認し、超えている場合は許可が必要と判定する。また、課金額の金額に関わらず管理者の許可を必要とする旨の設定である場合は、課金額の大小にかかわらず管理者の許可が必要と判定する。管理者の許可が不要と判定された場合（Ｓ１０３＝Ｎｏ）、Ｓ１０６に進む。管理者の許可が必要と判定された場合（Ｓ１０３＝Ｙｅｓ）、課金応答部１１３は、管理者である第２ユーザ端末に許可確認を行う（Ｓ１０４）。
【００３７】
第２ユーザは、課金を許可する場合、許可する旨の返答をサーバ装置１に返信する（Ｓ１０５）。サーバ装置１は、課金を許可する旨の返答を受信した場合、第１ユーザに対して課金処理を実行し（Ｓ１０６）、所定のゲーム内通貨やアイテムを第１ユーザに付与する処理を行う。また課金が成功した旨の通知を第１ユーザ端末２に送信する（Ｓ１０７）。同様に、第２ユーザ端末３にも通知してもよい。また、図示しないが、第２ユーザが課金を許可しない旨の返答をした場合は、課金応答部１１３は課金処理を行わない。
【００３８】
以上が、本実施の形態における課金管理システムの概要である。本実施形態のシステムによれば、第２ユーザは自身が設定した課金制限に反して第１ユーザが勝手に課金をしてしまうことを防止することができる。また、課金額に上限を設定し、上限以内であれば第２ユーザの許可を得ることなく課金が可能であるので、第１ユーザはルールの範囲内で自由にゲームを楽しむことができる。
【００３９】
（変形例）
本変形例では、第１ユーザが複数のゲームをプレイしている場合に、当該複数のゲームにおける課金行動を一括して管理可能なシステムを提供するものである。本変形例においては、個別のゲームプログラムをユーザに対して提供するゲームサーバとは別に、複数のゲームに関する情報を集約した情報を保有し、課金制限を行うプラットフォームとして機能する課金管理サーバを備える態様とすることができる。課金管理サーバは、プレイヤの情報に紐づけて、当該プレイヤが登録している複数のゲーム情報を紐づけて登録したデータベースを保有することができる。例えば、プレイヤ（第１ユーザ）のＳＮＳアカウント名や、第１ユーザ端末２の識別番号（シリアル番号、ＩＭＥＩ）など、複数のゲームにおいて共通している第１ユーザの識別情報に紐づけて、ゲーム名やゲームＩＤと、各ゲームにおけるプレイヤＩＤ等を登録することができる。
【００４０】
管理設定受付部１１４は、課金管理に関する情報の入力を第１ユーザ又は第２ユーザから受け付ける。本変形例においては、第１ユーザが複数のゲームをプレイしている場合で、第２ユーザが当該複数のゲームにおける課金を管理したい場合は、複数のゲームを特定したうえで、当該複数のゲームにおける第１ユーザのプレイヤ情報を登録することができる。なお、本変形例においても、サーバ装置１は、第１ユーザに対して課金管理に同意するか否かを確認し、第１ユーザから同意が得られた場合に限り、第２ユーザが第１ユーザの課金行動を管理できるようにしてもよい。図９は、ゲームを登録する際の第２ユーザ端末の画面表示例である。一例として、第１ユーザが共通のＳＮＳアカウントで複数のゲームをプレイしている場合は、ＳＮＳアカウント名を入力することによって、当該第１ユーザがプレイヤ登録されているゲームの一覧情報を出力することができる。第２ユーザは、管理対象ユーザに第１ユーザのＳＮＳアカウント名を所定欄４４に入力し、当該ＳＮＳアカウントで第１ユーザがプレイしているゲームを検索することを要求するボタン４５を選択すると、第１ユーザがプレイしているゲーム一覧４６を表示させることができる。同様に、第１ユーザ端末２の識別情報（シリアル番号、ＩＭＥＩ）を入力することで、当該端末の識別情報に紐づいたゲーム一覧４６を表示させることとしてもよい。第２ユーザは、複数のゲーム一覧の中から、管理対象としたいゲームを１つ以上選択することができる。
【００４１】
また、管理設定受付部１１４は、課金管理の設定に関する情報を入力することができる。例えば、１回当たりの課金上限額、１日当たりの課金上限額、１か月当たりの課金上限額等を任意で設定することができ、本変形例においては、第１ユーザがプレイしている複数のゲームにおける課金額の合計が、当該課金上限額を超えないように管理することを可能とする。
【００４２】
判定部１１５は、第１ユーザの課金要求について、上記実施形態と同様に、管理情報に基づいて、課金の可否を判定する。すなわち、まず、第１ユーザが、課金管理の被管理者として登録されたユーザであるか、さらには、当該課金要求に関して管理者に許可を取る必要があるか否かを判定する。ここで例えば、所定期間あたりの合計課金上限額が設定されている場合、複数のゲームにおいて当該所定期間の課金額の合計を計算し、今回の課金要求額を加算した額が当該課金上限額を上回るか否かを判定する。管理者に許可を取る必要がないと判定された場合、判定部１１５は課金可能と判定する。
【００４３】
課金応答部１１３は、判定部１１５による判定結果が、「課金可能」であった場合、第１ユーザに対して課金処理を実行する。また、通知部１１６は、第１ユーザが被管理者登録されているユーザである場合、当該課金に係る情報を第２ユーザ端末３に対して通知してもよい。図１０は、第２ユーザ端末３の画面構成例である。図１０（ａ）は、被管理者である第１ユーザ「太郎さん」が課金したことに関する通知（ゲーム名、課金時間、課金額）や、今月の課金額合計、今月の設定課金上限額などを表示している。また、第１ユーザの課金履歴を表示することも可能である。例えば「太郎さんの課金履歴を見る」ことを要求するボタン４１を第２ユーザがタップすることによって、図１０（ｂ）のような課金履歴情報を表示してもよい。図１０（ｂ）では、複数のゲームについて、過去の所定期間における課金時間、課金額等の情報を列挙している。また、ゲームごとの課金額合計を表示（４７）してもよい。
【００４４】
また本変形例において、図７のように第１ユーザ端末２上に課金可能残高を表示する場合は、複数のゲームにおける所定期間の課金額を合算したうえで、課金上限額から差し引くことで、課金可能残高を計算し、表示することができる。
【００４５】
本変形例によれば、第１ユーザが複数のゲームをプレイしている場合にも、一括して課金の管理をすることができ、複数のゲームで課金した合計金額が制限を超えないようにすることができる。第２ユーザは、第１ユーザがプレイしている複数のゲームについてそれぞれ管理する必要がなく、便利である。
【００４６】
以上説明した実施形態及び変形例において、サーバ装置１及びユーザ端末２、３が備えるソフトウェア機能部の処理について、本発明の趣旨を実現できる範囲で、サーバ１の一部若しくはすべての機能をユーザ端末２、３が備えてもよい。
【００４７】
また、図８の処理は、本実施形態の情報処理システムによる処理の一例を示したものであり、本願発明を限定する意図ではない。図８の処理に含まれる各工程は、図中に示される順序と異なる順序で実行するようにしてもよいし、一部の処理を並列に実行するよういしてもよいし、一部の工程を省略するようにしてもよいし、他の工程を追加してもよい。
【００４８】
上述した実施の形態は、本発明の理解を容易にするための例示に過ぎず、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良することができると共に、本発明にはその均等物が含まれることは言うまでもない。
【符号の説明】
【００４９】
１        管理サーバ
２        第１ユーザ端末
３        第２ユーザ端末
４        ネットワーク
【要約】
【課題】被管理者のゲーム内課金を効果的に制限することのできる課金管理システムを提供すること。
【解決手段】本発明は第１ユーザによるゲーム内課金を第２ユーザが管理するための課金管理サーバであって、前記第１ユーザと前記第２ユーザとを紐づけて記憶する記憶部を備え、前記第１ユーザが使用する第１ユーザ端末から課金要求を受付ける課金応答部と、前記課金要求に基づいて前記第２ユーザが使用する第２ユーザ端末に所定の通知を行う通知部とを備えることを特徴とする、課金管理サーバを提供するものである。
【選択図】図６【図１】
0006903207.tif 000002
【図２】
0006903207.tif 000003
【図３】
0006903207.tif 000004
【図４】
0006903207.tif 000005
【図５】
0006903207.tif 000006
【図６】
0006903207.tif 000007
【図７】
0006903207.tif 000008
【図８】
0006903207.tif 000009
【図９】
0006903207.tif 000010
【図１０】
0006903207.tif 000011