JP6505879B2 - サーバ及びプログラム - Google Patents

Description

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

最近では、サーバがユーザの端末にゲームのアプリケーションを配信して端末上で気軽に遊べるタイプのゲーム等が人気を博している。

かかるタイプのゲームは、既存のオンラインゲームとは違い、専用のクライアントソフトウェアを必要とせず、ウェブブラウザとSNSのアカウントのみで利用可能であり、無料で遊べ、課金システムはアイテム課金制をとる物が多い。

上記のようなゲームでは、アイテムを購入する際にゲーム内通貨を消費することで課金を行うものが多い。このような場合、ゲームサーバは、課金を専門に行う課金サーバと連携して、課金サーバがゲーム内通貨に相当する課金額をユーザのクレジットカード等で清算する処理を行い、ゲームサーバは、課金サーバを介して課金額を徴収する。

特開２０１２−２３５８７１号公報

かかるシステムでは、ユーザはゲーム上でアイテムを購入する際にその都度課金サーバにアクセスしてゲーム内通貨を購入するのは面倒であるので、あらかじめ所与の額のゲーム内通貨を購入してゲーム内に保持しておき、保持しているゲーム内通貨を消費してアイテムを購入することが多い。

ところがサーバがゲームサービスを終了する場合には、ユーザがゲームサービスの終了を意識してゲーム内通貨を消費しないとユーザがゲーム内に保持しているゲーム内通貨が消費されないまま残ってしまう。

かかるシステムでは、ゲームサーバ側では、ユーザの個人情報（住所やクレジットカード番号等）を保持していないので、消費されないまま残ったユーザのゲーム内通貨の返金するためには、ユーザから返金のために必要な個人情報を提供してもらう必要がある。従ってゲームサービスの終了による返金処理をいかにしてユーザに周知させ、もれなく行うことができるかが問題となる。

本発明は、以上のような課題に鑑みてなされたものであり、その目的とするところは、アイテム課金を行うゲームにおいて、ゲームのサービスを終了する際の返金処理をユーザに周知徹底させることが可能なゲームを提供できるサーバ及びプログラムを提供することにある。

（１）本発明は、端末と通信し、ユーザが購入したゲーム内通貨を消費させてゲーム内アイテムを購入させるゲームを実行させるサーバにおいて、前記端末から受信したユーザ識別情報を取得するユーザ識別情報取得部と、前記ユーザ識別情報に基づいて、前記端末に前記ユーザのゲーム内通貨の残高を通知する通知処理部と、前記端末から前記ゲーム内通
貨の返金に関する返金登録を受け付け、前記ユーザ識別情報に関連付けて前記返金登録をおこなう返金登録処理部と、を含み、前記通知処理部は、前記ユーザ識別情報に関連付けて前記返金登録がなされておらず、かつ、前記ユーザ識別情報に関連付けて記憶されている前記ゲーム内通貨の残高がある場合に、前記端末に対して前記返金登録を促す通知を行うことを特徴とするサーバに関する。

本発明は、上記各手段を含むシステムに関係する。本発明は、上記各手段として、コンピュータを機能させるプログラムに関する。また本発明は、コンピュータに読み取り可能であって、上記プログラムを記憶した情報記憶媒体に関係する。

ユーザ識別情報とはユーザＩＤや端末ＩＤ等である。

ゲーム内通貨の返金に関する返金登録はゲーム内通貨の返金を要求する登録でもよいし、ゲーム内通貨の返金を希望しない（使い切る）という登録でもよい。

返金とは、現金（現金書留）やクレジットカードへの返金でもよいし、他の仮想通貨（複数のゲームサーバで共通に使用される仮想通貨）への換金でもよい。

このようにすれば、アイテム課金を行うゲームにおいて、ゲームのサービスを終了する際の返金処理をユーザに周知徹底させることが可能なゲームを提供できる。

（２）また、本発明のサーバ、システム、プログラム及び情報記憶媒体において、前記返金登録が行われた場合に、前記ユーザ識別情報に関連付けて記憶されている前記ゲーム内通貨の消費を制限（例えば消費禁止）する処理を行うゲーム内通貨消費制限処理部を、さらに含んでもよい。

ゲーム内通貨の消費を制限するとは、例えばゲーム内通貨を使用できない（ゲーム内アイテムを購入できない）ようにすることでもよい。

このようにすると、返金登録済のゲーム内通貨が消費されないようにすることができる。

（３）また、本発明のサーバ、システム、プログラム及び情報記憶媒体において、前記通知処理部は、前記端末から前記ゲーム内通貨の消費を伴う指示入力が行われた場合に、前記ゲーム内通貨の消費の可否、又は消費後の前記ゲーム内通貨の残高を通知してもよい。

前記ゲーム内通貨の消費の可否は、ゲーム内通貨の残高を全額返金することが登録されて前記ゲーム内通貨の消費が全面的に禁止されている場合や、ユーザが返金額を指定した場合にゲーム内通貨の残高とユーザが指定した返金額の差額（のみが使用可能である場合（前記ゲーム内通貨の所定額以上の消費が禁止されている場合）に通知してもよい。このようにすると、ユーザは消費が制限されている理由を知ることができる。

また消費後の前記ゲーム内通貨の残高の通知は、ゲーム通貨内の消費が制限されていない場合や、ユーザが返金額を指定した場合にゲーム内通貨の残高とユーザが指定した返金額の差額が、消費額を上回っている場合に通知してもよい。このようにすると、消費後のゲーム内通貨の残高を意識しながらアイテムを購入するので、サービスが終了するまでに計画的にゲーム内通貨の残高を消費することができる。

（４）また、本発明のサーバ、システム、プログラム及び情報記憶媒体において、前記返金登録処理部は、前記返金登録に関連して、指定された指定返金額を前記ユーザ識別情報
に関連付けて登録する処理を行い、ゲーム内通貨消費制限処理部は、前記ゲーム内通貨の消費を行うことにより、前記ゲーム内通貨の残額が前記指定返金額を下回る場合には、前記ゲーム内通貨の消費を禁止する処理を行い、前記通知処理部は、前記ゲーム内通貨の消費を行うことにより、前記ゲーム内通貨の残額が前記指定返金額を下回る場合には、その旨を通知する処理を行ってもよい。

このようにするとユーザが指定した指定返金額を返金することができる。

（５）また、本発明のサーバ、システム、プログラム及び情報記憶媒体において、前記返金登録処理部は、前記指定返金額を前記ゲーム内通貨から差し引いた残額がいずれのゲーム内アイテムも購入できない端数額である場合、又はいずれかのゲーム内アイテムを購入した後の残額が前記端数額になることが確実である場合には、前記指定返金額の登録を許可しないでもよい。

このようにすると端数額をユーザが使えないままゲームが終了することを防止することができる。

（６）また、本発明のサーバ、システム、プログラム及び情報記憶媒体において、前記通知処理部は、前記ゲーム内通貨の消費を伴う指示入力が行われた場合に、前記ユーザ識別情報に関連付けて前記返金登録がされているか否か判断し、前記返金登録がされていると判断した場合には、ゲーム内通貨の消費後の残高を通知してもよい。

このようにすると、消費後のゲーム内通貨の残高を意識しながらアイテムを購入するので、サービスが終了するまでに計画的にゲーム内通貨の残高を消費することができる。

（７）また、本発明のサーバ、システム、プログラム及び情報記憶媒体において、ユーザを認証するための認証情報（システムが発行した問い合わせ番号でもよいし、ユーザが登録したパスワードでもよい）を用いてユーザ認証を行う認証処理部をさらに含み、前記返金登録処理部は、前記認証処理部により認証されたユーザについて前記返金登録を行ってもよい。

（８）また、本発明のサーバ、システム、プログラム及び情報記憶媒体において、前記認証処理部は、ユーザの所定の個人情報の登録が行われた場合に、前記認証情報として、認証番号を生成してユーザに提供し、ユーザ端末から受信した前記認証番号を用いてユーザを認証してもよい。

このようすると、なりすましのユーザに個人情報を変更されるのを防ぐことができる。

本実施形態のネットワークシステムのネットワーク図の一例。 本実施形態のサーバの機能ブロック図。 ゲームサーバがゲームをクローズするまでのタイムスケジュールを示した図。 図４（Ａ）（Ｂ）は、ゲームユーザ情報の一例を示す図。 返金登録時の端末の画面遷移図の一例。 返金登録による返金登録情報の更新例を示す図の一例。 返金登録変更時の端末の画面遷移図の一例。 返金登録時の端末の画面遷移図の一例。 アイテム購入画面の一例。 アイテム購入画面の一例。 共通管理サーバを含む構成について説明するための図。 返金登録変更時の端末の画面遷移図の一例。 ゲームサーバが行う通知処理と返金登録処理の流れを示すフローチャート。 図１４は、返金登録の変更処理の流れについて説明するためのフローチャート。 返金額の登録処理の詳細な処理の流れを示すフローチャート。 ゲーム内通貨消費制限処理の流れを示すフローチャート。

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

１．構成
１−１．ネットワークシステム
図１は、本実施の形態のネットワークシステム１を示す。本実施形態では、ユーザ端末１０（端末は複数でもよい）とゲームサーバ２０とインターネット２等の通信ネットワークに接続可能に構成されている。

ゲームサーバ２０は、インターネット（ネットワークの一例）２を介してサーバに通信接続された端末１０を介して、ユーザにゲームをプレイさせるサービスを提供することが可能な情報処理装置であり、端末１０に所定のゲームを提供している。

ゲームサーバ２０は、ゲームユーザのゲーム履歴情報が記憶されているゲーム履歴情報データベース２２やゲームユーザのユーザ情報が記憶されているゲームユーザ情報データベース２４を管理している。

本実施形態のゲームサーバ２０は、課金サーバ３０とネットワーク２を介して接続可能に構成されている。課金サーバ３０は、オンライン方式（金融機関、クレジットカード会社又は電子マネーのサービス会社のホストコンピュータと、小売店等の決済用端末をオンラインで接続し決済を行う方式）の電子マネーの一種である「クレジット」に関するクレジット情報を管理している。「クレジット」は、課金サーバが提供するＷＥＢサイトにおいてクレジットカード情報等を入力することにより購入でき、課金サーバがユーザのクレジット情報を管理している。課金サーバ３０は、ゲームユーザのクレジット情報が記憶されたクレジット情報データベース３２やゲームユーザのアカウント情報等が記憶された課金ユーザ情報データベース３４を管理している。

本実施形態のゲームサーバ２０、課金サーバ３０は、Ｗｅｂサーバ機能を備える。

端末１０は、スマートフォンや携帯電話、タブレット端末、パーソナルコンピュータ、ゲーム端末などであり、インターネット（ＷＡＮ）、ＬＡＮなどのネットワークを介してサーバ２０に接続可能な装置である。なお、端末１０とゲームサーバ２０、課金サーバ３０との通信回線は、有線でもよいし無線でもよい。ゲームサーバ２０や課金サーバ３０との通信を行うための通信制御機能及びゲームサーバ２０や課金サーバ３０から受信したデータ（Ｗｅｂデータ、ＨＴＭＬ形式で作成されたデータなど）を用いて表示部への表示制御を行うＷｅｂブラウザ機能などを備え、所定のゲーム画像を端末の表示部に表示させる処理を行う。

ゲームサーバ２０が提供するゲームは、アイテムを購入する際にゲーム内通貨を消費す
ることで課金を行うタイプのアイテム課金制をとるゲームである。ゲームサーバ２０は、課金を専門に行う課金サーバ３０と連携して、課金サーバ３０がゲーム内通貨に相当する課金額をユーザのクレジットカード等で清算する処理を行い、ゲームサーバ２０は、課金サーバにおける課金額に応じて、ユーザに対してゲーム内通貨を付与する。

端末１０においてゲームサーバ２０が提供するゲームを行う際に、ユーザはゲーム内通貨を消費して特定のゲームアイテムを購入したり、特定のイベント（たとえば、アイテムの付与のための抽選イベント）を実行したりすることができる。

ゲームサーバ２０が提供するゲーム、基本は無料のゲームであり、端末のＷｅｂブラウザ上で提供されるゲーム、例えばFLASH、CGI、PHP、shockwave、Java（登録商標）アプレット、JavaScript（登録商標）など様々な言語で作られたブラウザゲーム（Webブラウザで設置サイトを開くだけで起動するゲーム）でもよい。

またゲームサーバ２０が提供するゲームは課金サーバ３０がＷｅｂ上で提供する動作環境（ＡＰＩ（アプリケーションプログラミングインタフェース）、プラットフォーム等）を利用して実行されるソーシャルゲーム（Social Game）と呼ばれるゲームでもよい。ソーシャルゲーム（Social Game）は、ソーシャル・ネットワーキング・サービス（ＳＮＳ）等により、ウェブブラウザ上で動作する動作環境（ＡＰＩやプラットフォーム）が提供され、これを基盤として制作されたアプリケーションである。既存のオンラインゲームとは違い、専用のクライアントソフトウェアを必要とせず、ウェブブラウザとＳＮＳのアカウントのみで利用可能である。

またゲームサーバ２０が提供するゲームは、コンピュータネットワークを介して専用のサーバ（ゲームサーバ２０や課金サーバ３０等）や他のユーザの端末（パソコン、ゲーム機など）と接続し、オンラインで同時に同じゲーム進行を共有することができるオンラインゲームでもよい。

ゲームサーバ２０が提供するゲームの処理は、端末１０が一部を行う場合でもよいし、クラウドコンピューティングで実現されるゲームでもよい。

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

記憶部２７０は、処理部２００や通信部２９６などのワーク領域となるもので、その機能はＲＡＭ（ＶＲＡＭ）などにより実現できる。記憶部２７０は、格納部２６０（例えば、データベース）を含む。

格納部２６０は、本実施形態で所定のゲームを行ったユーザのゲーム履歴情報２６２が記憶されているゲーム履歴情報データベースとして機能する。また格納部２６０は、本実施形態で所定のゲームを行ったユーザのゲームユーザ情報２６１が記憶されているゲームユーザ情報データベースとして機能する。

ゲームユーザ情報として、ネットワークシステムに参加する複数のユーザそれぞれのゲームユーザ情報２６１を格納してもよい。ゲームユーザ情報として、例えば、ユーザの識別情報に対応づけて、ユーザ名（ユーザアカウント）、ユーザパスワードなどを、ゲームユーザ情報２６１として格納してもよい。またユーザの識別情報に対応づけて、端末の「宛先情報」（ＩＰアドレス、メールアドレス、ポート番号、ＭＡＣアドレス、電話番号等）、ユーザが使用する端末にアクセスするための端末１０の端末識別情報を、ゲームユー
ザ情報２６１として格納してもよい。

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

通信部２９６は外部（例えば、端末、他のサーバや他のネットワークシステム）との間で通信を行うための各種制御を行うものであり、その機能は、各種プロセッサ又は通信用ＡＳＩＣなどのハードウェアや、プログラムなどにより実現できる。

処理部２００（プロセッサ）は、情報記憶媒体２８０に記憶されるプログラム等に基づいて、処理を行う。具体的には、端末からの要求に応じてサービスを提供する。

また、処理部２００は記憶部２７０内の主記憶部２７２をワーク領域として各種処理を行う。処理部２００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ等）、ＡＳＩＣ（ゲートアレイ等）などのハードウェアや、プログラムにより実現できる。

特に、本実施形態のサーバの処理部２００は、ネットワーク設定部２１０、通信制御部２１１、ユーザ識別情報取得部２１２、通知処理部２１３、ゲーム処理部２２０、返金登録処理部２２２、ゲーム内通貨消費制限処理部２２３、認証処理部２２４を含む。なおこれらの一部を省略する構成としてもよい。

ネットワーク設定部２１０は、端末（例えば、携帯端末などの）識別情報を端末１０から受信し、受信した端末識別情報に対応づけて、ユーザのネットワーク情報を、格納部２６０に格納する。

通信制御部２１１は、ネットワークを介して課金サーバとユーザ端末を含む他のコンピュータとデータを送受信する処理を行う。

ゲームサーバ２０のゲーム処理部２２０は、ユーザ端末からゲームのゲームプログラム（ゲームアプリケーション）の実行命令要求を受信すると、当該ゲームプログラムを実行する処理を行う。ゲーム処理部２２０における各種処理は、サーバ２０で行ってもよいが、一部の処理を端末において行うようにしてもよい。かかる場合には、ゲームサーバ２０から、当該ゲーム処理部２２０のプログラムを端末１０に送信する（インストールする）。

ユーザ識別情報取得部２１２は、端末から受信したユーザ識別情報を取得する。通知処理部２１３は、ユーザ識別情報に基づいて、端末に前記ユーザのゲーム内通貨の残高を通知する。返金登録処理部２２２は、前記端末から前記ゲーム内通貨の返金に関する返金登録を受け付け、前記ユーザ識別情報に関連付けて前記返金登録をおこなう。

通知処理部２１３は、ユーザ識別情報に関連付けて返金登録がなされておらず、かつ、ユーザ識別情報に関連付けて記憶されているゲーム内通貨の残高がある場合に、端末に対して前記返金登録を促す通知を行ってもよい。

ゲーム内通貨消費制限処理部２２３は、返金登録が行われた場合に、ユーザ識別情報に
関連付けて記憶されているゲーム内通貨の消費を制限（例えば消費禁止）する処理を行ってもよい。

通知処理部２１３は、端末からゲーム内通貨の消費を伴う指示入力が行われた場合に、ゲーム内通貨の消費の可否、又は消費後の前記ゲーム内通貨の残高を通知してもよい。

返金登録処理部２２２は、返金登録に関連して、指定された指定返金額をユーザ識別情報に関連付けて登録する処理を行う。ゲーム内通貨消費制限処理部２２３は、ゲーム内通貨の消費を行うことにより、ゲーム内通貨の残額が指定返金額を下回る場合には、ゲーム内通貨の消費を禁止する処理を行う。通知処理部２１３は、ゲーム内通貨の消費を行うことにより、前記ゲーム内通貨の残額が前記指定返金額を下回る場合には、その旨を通知する処理を行ってもよい。

返金登録処理部２２２は、指定返金額を前記ゲーム内通貨から差し引いた残額がいずれのゲーム内アイテムも購入できない端数額である場合、又はいずれかのゲーム内アイテムを購入した後の残額が前記端数額になることが確実である場合には、前記指定返金額の登録を許可しないでもよい。

通知処理部２１３は、ゲーム内通貨の消費を伴う指示入力が行われた場合に、ユーザ識別情報に関連付けて返金登録がされているか否か判断し、返金登録がされていると判断した場合には、ゲーム内通貨の消費後の残高を通知してもよい。

認証処理部２２４は、ユーザを認証するための認証情報（システムが発行した問い合わせ番号でもよいし、ユーザが登録したパスワードでもよい）を用いてユーザ認証を行う。返金登録処理部２２２は、認証処理部２２４により認証されたユーザについて前記返金登録を行ってもよい。

認証処理部２２４は、ユーザの所定の個人情報の登録が行われた場合に、前記認証情報として、認証番号を生成してユーザに提供し、ユーザ端末から受信した認証番号を用いてユーザを認証してもよい。

２．本実施の形態の手法
２−１．ゲームクローズまでのタイムスケジュール
図３は、本実施の形態のゲームサーバ２０がゲームをクローズするまでのタイムスケジュールを時系列に示している。日時Ｔ１において、ゲームサーバ２０は、本ゲームのサービス終了は３月後の日時Ｔ４であることを発表する。そして日時Ｔ１から１月後の日時Ｔ２に、課金サーバ、又はゲームサーバ２０が課金サーバ３０を介して行うゲーム内通貨の発売を停止する。そしてゲームサーバ２０は、日時Ｔ２から２月後の日時Ｔ３に、本ゲームのアプリケーションのユーザの端末への配信を中止する。そして日時Ｔ３の翌日である日時Ｔ４に、ゲームのサービスを終了する。そして日時Ｔ４の１月後の日時Ｔ５に返金登録の受付を終了する。

ユーザはゲームのサービスが終了する日時Ｔ４までは、ゲーム上でゲーム内通貨が使用可能である。しかし日時Ｔ２以降は、ユーザはゲーム内通貨を購入することができなくなるので、それ以降はユーザがゲーム内に保持しているゲーム内通貨の範囲内でアイテム等を購入することになる。

ゲームサービス終了である日時Ｔ４以降は、ゲーム内通貨の使用はできなくなるため、ユーザは日時Ｔ４までにゲーム内通貨を使いきるか、返金登録をして、残ったゲーム内通貨を返金してもらうかを選択する。

しかし、ユーザが返金登録に気が付かない可能性もあるため、ゲームサーバ２０は、ユーザに返金登録の周知徹底を図るため以下に説明するような処理を行っている。

２−２．ゲームユーザ情報の一例
図４（Ａ）（Ｂ）は、ゲームユーザ情報として記憶される返金登録情報３００と返金処理用個人情報３４０の一例を示す図である。いずれも格納部（図２の２６０）にゲームユーザ情報（図２の２６１）として格納される。

図４（Ｂ）に示すように、返金処理用個人情報３４０として、返金登録番号３２４に関連付けてユーザのメールアドレス３４２、名前３４４、郵便番号３４６、住所３４８等が登録される。

２−３．通知処理と返金登録処理
ゲームサーバ２０は、所定のタイミングで、ゲーム内通貨残高を有しているユーザにゲーム内通貨の残高を通知する通知処理と、ユーザによるゲーム内通貨の返金に関する返金登録（返金を要求する登録でもよいし、返金不要の登録でもよい）の要求を受け付け、当該ユーザのユーザ識別情報に関連付けて前記返金登録をおこなう返金登録処理を行う。

通知処理は、ユーザが返金登録をしておらす、ゲーム内通貨の残高がある場合に、当該ユーザに対して返金登録を促す通知を行う処理である。

ゲームサーバ２０は、ゲームのクローズを発表してから、ゲーム内通貨の発売を停止したのち（図３の日時Ｔ２〜日時Ｔ５の間）に返金登録処理を行うようにしてもよい。またゲームサーバ２０は、所定のタイミング、例えばユーザがユーザ端末からゲームにログインした場合タイミングで、通知処理を行うようにしてもよい。

ゲームサーバ２０が行う通知処理と返金登録処理の一例について、図５、図６、図１３を用いて説明する。図１３は、ゲームサーバが行う通知処理と返金登録処理の流れを示すフローチャートである。

ゲームサーバ２０は、端末１０からゲームサイトにアクセスがあると、端末１０からの受信情報に基づきユーザのゲームユーザ情報（図４（Ａ）の返金登録情報３００）を検索する（ステップＳ２０）。端末１０からの受信情報とは、例えば端末ＩＤでもよい。ゲームサーバ２０はユーザの端末ＩＤを保存しているので、端末ＩＤでゲーム開始可能である。

ユーザがすでに返金登録を行っていれば、返金登録フラグ（図４の３１８）は「ＯＮ」になっており、まだ返金登録を行っていない場合には、返金登録フラグ（図４の３１８）は「ＯＦＦ」になっている。例えば図４（Ａ）において、ゲームユーザ識別番号「ＧＹ１」のユーザはまだ返金登録を行っておらず、ゲームユーザ識別番号「ＧＹ２」のユーザはすでに返金登録を行っているユーザである。

ユーザの返金登録フラグ（図４の３１８）がＯＮである場合には（ステップＳ３０でＹ）、例えば図５の５１０に示すような画像を端末１０に提供して、端末１０に返金登録を促す通知を行う（ステップＳ４０）。

端末１０から返金登録要求あると（ステップＳ５０でＹ）、端末１０にユーザ認証を要求（ステップＳ６０）。例えばユーザが「はい」５１２を選択すると、ゲームサーバ２０は、５２０に示すようなユーザＩＤとパスワードを要求する画像を、端末１０に提供する
（表示させる）。

ゲームサーバ２０は、端末１０からユーザ認証情報を受信すると（ステップＳ７０でＹ）、ユーザ認証処理を行う（ステップＳ８０）。ここでのユーザ認証情報は、ユーザの本人確認を確実に行う必要性が高いため、５２０に示すように、ユーザ自身が入力する情報であるユーザＩＤやパスワード（ユーザ認証用の認証情報の一例）を用いる。

ゲームサーバ２０は、ユーザＩＤやパスワード（ユーザ認証用の認証情報の一例）を用いたユーザ認証に成功した場合には（ステップＳ９０でＹ）、例えば図５の５３０に示すような画像を提供し、端末１０にユーザのゲーム内通貨残高（図５の５３２参照）を通知し、返金情報（図５の５３４参照）の入力を促し（ステップＳ１００）、端末１０から受信した返金情報の登録処理を行う（ステップＳ１１０）。

図５の５４０に示すように返金額（図５の５４２参照）を通知して、個人情報の入力を要求（図５の５４４参照）する（ステップＳ１２０）。例えば図５の５５０に示すような画像を端末１０に提供して、メールアドレスや、名前、郵便番号、住所等の個人情報の入力を要求する。

ゲームサーバ２０は、端末１０から個人情報を受信すると（ステップＳ１３０でＹ）、返金登録番号（図４の３２８）を生成し、返金登録番号（図４の３２８）と個人情報（図４（Ｂ）の３４２、３４４、３４６、３４８等）をゲームユーザ情報（図４（Ｂ）の返金処理用個人情報３４０）として登録する。そして、端末１０に、図５の５６０、５７０に示すように返金登録完了と返金登録番号を通知する（ステップＳ１４０）。

図６は、返金登録フラグが「ＯＦＦ」であったゲームユーザ識別番号「ＧＹ１」のユーザが図５に示すようにして返金登録を行った場合に返金登録情報３００（ゲームユーザ情報の一例）が更新される様子を示している。ゲームサーバ２０は、返金登録フラグ３１８を「ＯＦＦ」から「ＯＮ」に更新し、ユーザが選択した「現金で返金」に対応する返金方法「１」を、返金方法３２０として登録する。

２−４．返金登録の変更処理
返金登録の変更処理は、既に返金登録を行っているユーザ（返金登録フラグが「ＯＮ」のユーザ）に対して行うもので、図１３のステップＳ３０でＹの場合の処理である。

ゲームサーバ２０が行う返金登録の変更処理の一例について、図１４、図７等を用いて説明する。

図１４は、返金登録の変更処理の流れについて説明するためのフローチャートである。

図１３のステップＳ３０でＹの場合、ゲームサーバ２０は端末１０に返金登録内容の確認・修正の有無を確認する通知を行う（ステップＳ２１０）。例えば図７の６１０に示すような確認画像を端末１０に提供する。ゲームサーバ２０は、端末１０からの確認・修正要求を受信すると（ステップＳ２２０）、端末１０に返金登録番号及びユーザ認証を要求する（ステップＳ２３０）。具体的には図７の６１０において、ユーザが「はい」６１２を選択すると、図７の６２０に示すような確認画像をユーザの端末１０に提供する。確認画像６２０では、図５の確認画像５２０と同じようにユーザＩＤとパスワードを要求するとともに、返金登録番号６２２も要求する。返金登録の変更処理の場合すでに返金登録番号が付与されているため、返金登録を行ったユーザであることを返金登録番号で確認して、成りすまし等による返金先の変更を防止するためである。

ゲームサーバ２０は、返金登録番号及びユーザ認証情報を受信すると（ステップＳ２４０でＹ）、ユーザＩＤによりゲームユーザ情報（図４（Ａ）の返金登録情報３００）を検索して、ユーザＩＤとパスワードによるユーザ認証処理、及び返金登録番号の認証処理を行う（ステップＳ２５０）。

ゲームサーバ２０は、ユーザ認証処理及び返金登録番号の認証処理に成功すると（ステップＳ２６０でＹ）、ユーザの返金登録情報（図４（Ａ）の返金登録情報３００）や返金処理用個人情報（図４（Ｂ）の返金処理用個人情報３４０）に基づき、図５の６３０に示すようなユーザの返金登録画像を生成して、端末１０に提供する（ステップＳ２７０）。

ユーザは、端末１０に表示された返金登録画像６３０において、返金登録の内容（返金方法６３２や個人情報６３４）を変更して「変更」６３６を指示する（クリックする）ことにより登録内容の変更情報がゲームサーバ２０に送信される。を行うことができる。

ゲームサーバ２０は、端末１０から変更情報を受信すると（ステップＳ２８０でＹ）、変更情報に基づき、ゲームユーザ情報（図４（Ａ）の返金登録情報３００や図４（Ｂ）の返金処理用個人情報３４０）を更新し、返金登録完了と返金登録番号を通知する（ステップＳ２９０）。

２−５．指定された返金額の登録処理
上記実施の形態では、ユーザが返金登録時のゲーム内通貨の残高を全額返金請求する場合を例にとり説明したこれに限られない。本実施の形態では、ユーザがゲーム内通貨の残高の範囲内で返金額を指定して返金を受けることも可能である。

ゲームサーバ２０が行う指定された返金額の登録処理の一例について、図１５、図８等を用いて説明する。

図１５は、返金額の登録処理の詳細な処理の流れを示すフローチャートであり、図１３の返金登録処理のステップＳ１１０の「返金情報の登録処理」の詳細な処理を示したものである。

ゲームサーバ２０は、図１３のステップＳ１００においてユーザ認証に成功した場合には（図１３のステップＳ９０でＹ）、例えば図５の５３０に示すような返金方法登録画像を提供し（ステップＳ３１０）、端末１０にユーザのゲーム内通貨残高（図５の５３２参照）を通知し、返金方法（図５の５３４参照）を選択させる。ユーザは、図５の５３０に示すような返金方法登録画像において、「現金で返金」、「システム共通通貨に換金」、「返金を希望しない」、「後で通知」から返金方法を選択することができる。

ゲームサーバ２０は、端末１０から返金方法を受信すると（ステップＳ３２０）、ユーザ識別情報に関連付けて返金方法を登録する（ステップＳ３３０）。

図５の５３０において「現金で返金」が選択された場合には、「現金で換金」に対応した返金方法「１」を、返金方法３２０として登録する。また「現金で返金」が選択された場合には、ユーザの個人情報（住所や氏名等）を利用して返金額に相当する現金書留や現金為替や商品券等を送付してもよい。またユーザの個人情報としてクレジットカード番号を取得する場合には、ユーザのクレジットカードの口座に返金してもよい。

また図５の５３０において「システム共通通貨に換金」が選択された場合には、「システム共通通貨に換金」に対応した返金方法「２」を、返金方法３２０として登録する。「システム共通通貨」については「２−６．システム共通通貨への換金処理」で説明する。

また図５の５３０において「返金を希望しない」が選択された場合には、「返金を希望しない」に対応した返金方法「３」を、返金方法３２０として登録する。

また図５の５３０において「今は保留」が選択された場合には、「今は保留」に対応した返金方法「４」を、返金方法３２０として登録する。

ゲームサーバ２０は、端末１０に例えば図８の６５０に示すような返金額種別登録画像を提供する（ステップＳ３４０）。

返金額種別登録画像６５０では、返金額種別として「現時点の残額を全額返金」、「返金額を指定」、「サービス終了時の残額を返金」が選択可能になっている。

ゲームサーバ２０は、端末１０から返金額種別を受信すると（ステップＳ３５０）、受信した返金額種別は「返金額指定」である場合には（ステップＳ３６０）、図８の６６０に示すような返金額種別指定画像を端末１０に提供する（ステップＳ３７０）。ユーザは、自己のゲーム内通貨残高の範囲ないで返金額の指定入力６６２を行うことができる。

ゲームサーバ２０は、端末１０から指定返金額を受信すると（ステップＳ３８０）、ゲーム内通貨残高から指定返金額を差し引いた残額がいずれのアイテムも購入できない端数額であるか又はいずれかのゲームアイテムを購入した後の残額が端数額になるか判定する（ステップＳ３９０）。ゲーム内通貨残高から指定返金額を差し引いた残額がいずれのアイテムも購入できない端数額である場合とは、例えばユーザが保有するゲーム内通貨残高が１０００ルビーで、ゲーム内通貨で購入できるアイテムが最低２００ルビーである場合に、ユーザが返金額を９００ルビーと指定したような場合である。この場合ゲーム内通貨残高（１０００ルビー）から指定返金額（９００ルビー）を差し引いた残額は１００ルビーであり、ゲーム内いずれのアイテムも購入することができない（アイテムは最低でも２００ルビー以上であるため）端数額となる。またいずれかのゲームアイテムを購入した後の残額が端数額になる場合とは、例えばユーザが保有するゲーム内通貨残高が１０００ルビーで、ゲーム内通貨で購入できるアイテムが２００ルビーと５００ルビーの２種類しかない場合に、ユーザが返金額を７００ルビーと指定したような場合である。この場合ゲーム内通貨残高（１０００ルビー）から指定返金額（７００ルビー）を差し引いた残額は３００ルビーであり、ユーザがゲーム内の２００ルビーのアイテムを購入すると、購入後の残高は１００ルビーとなり、（アイテムは２００ルビーと５００ルビーしかないため）端数額となる。

ゲームサーバ２０は、端末１０から指定返金額を受信すると（ステップＳ３８０）、ゲーム内通貨残高から指定返金額を差し引いた残額が端数額になる場合には（ステップＳ４００でＹ）、指定返金額の登録要求を受け付けず、図８の６８０に示すように、その理由「残額が端数なので返金額を登録できません」６８２を通知する（ステップＳ４１０）。

ゲームサーバ２０は、ゲーム内通貨残高から指定返金額を差し引いた残額が端数額にならない場合には（ステップＳ４００でＮ）、ユーザ識別情報に関連付けて、返金額種別及び指定返金額を登録（ステップＳ４２０）。

また受信した返金額種別は「返金額指定」である場合には（ステップＳ３６０でＮ）、ユーザ識別情報に関連付けて、返金額種別を登録（ステップＳ４３０）。

図８の５５０において「現時点の残額を全額返金」が選択された場合には、「現時点の残額を全額返金」に対応した返金額種別「１」を、返金額種別３２２として登録する。図
８の５５０において「返金額を指定」が選択された場合には、「返金額を指定」に対応した返金額種別「２」を、返金額種別３２２として登録する。図８の５５０において「サービス終了時の残額を返金」が選択された場合には、「サービス終了時の残額を返金」に対応した返金額種別「３」を、返金額種別３２２として登録する。

２−６．ゲーム内通貨消費制限処理
ゲームサーバ２０は、ユーザから返金登録が行われた場合に、当該ユーザのゲーム内通貨の消費を制限（例えば消費禁止）する処理を行う。

例えばユーザが「現時点の残額を全額返金」を選択して返金登録した場合には、その時点からユーザはゲーム内通貨残高を使用することができなくなる。またユーザが「返金額を指定」を選択して返金登録した場合には、アイテム購入金額が、ゲーム内通貨残高から指定返金額を差し引いた残額よりも大きい場合には、ユーザはアイテムを購入することができない。このように、ユーザのゲーム内通貨の使用を禁止する場合には、使用を制限することや制限理由を通知する。

ゲームサーバ２０が行うゲーム内通貨消費制限処理の一例について、図１６、図９、１０等を用いて説明する。図１６は、ゲーム内通貨消費制限処理の流れを示すフローチャートである。

ゲームサーバ２０は端末１０からアイテム購入要求を受信すると（ステップＳ５１０でＹ）、端末１０からの受信情報に基づきユーザのゲームユーザ情報を検索する（ステップＳ５２０）。例えば端末ＩＤ（図４の３１２）やユーザＩＤ（図４の３１４）等からゲームユーザ情報を検索することができる。検索結果取得したゲームユーザ情報（図４（Ａ））のユーザの返金登録フラグ（（図４（Ａ）の３１８）はオンである場合（ステップＳ５３０はＹ）、
返金額種別が「１」であれば（ステップＳ５４０でＹ）、アイテム購入要求を受け付けず、その理由「全額返金登録済なので新たな購入はできません」を通知する（ステップＳ５５０）。図９は本実施の形態のアイテム購入画面である。例えばすでに全額返金登録したユーザが、回復薬１個（２００ルビー）を指定して（７１０参照）、「購入」ボタン７２０を指示すると、７３０に示すような制限理由を通知するメッセージを出力する。

また返金額種別が「２」であれば（ステップＳ５６０でＹ）、ゲームサーバ２０はアイテム購入金額＞使用可能残高か否か判断し、アイテム購入金額＞使用可能残高であれば（ステップＳ５７０でＹ）、アイテム購入要求を受け付けず、その理由「○○ルビー返金登録されているのであなたの使用可能残高は××です。アイテム購入金額が使用可能残高をオーバーしています」を通知する（ステップＳ５８０）。またアイテム購入金額＞使用可能残高でなければ（ステップＳ５７０でＮ）、アイテム購入処理を行い、使用可能残高変更メッセージ「あなたの使用可能残高は××に変更になりました」を通知する（ステップＳ５９０）。

また返金額種別が「３」又は「４」である場合（ステップＳ６００でＹ）、アイテム購入金額＞ゲーム内通貨残高であれば（ステップＳ６１０でＹ）、アイテム購入要求を受け付けず、その理由「あなたのゲーム内通貨残額は××です。アイテム購入金額がゲーム内通貨残高をオーバーしています」を通知する（ステップＳ６２０）。またアイテム購入金額＞ゲーム内通貨残高でなければ（ステップＳ６１０でＮ）、アイテム購入処理を行い、図１０の７５０に示すように、ゲーム内通貨残高変更メッセージ「あなたのゲーム内通貨残高は××に変更になりました」を通知する（ステップＳ６３０）。

２−７．システム共通通貨への換金処理
上記実施の形態では、ゲーム内通貨残高を現金に変化する場合を例にとり説明したが、これに限られない。例えば、複数のゲームサーバで共通に使用可能なシステム共通通貨に換金することもできる。

図１１は、共通管理サーバを含む構成について説明するための図である。

共通管理サーバ５０は複数のゲームサーバ２０−１、２０−２、・・のユーザ情報やゲーム内通貨を共通に管理するためのサーバである。従ってこの共通管理サーバ５０で管理している共通管理ユーザ情報４４は、複数のゲームサーバ２０−１、２０−２、・・で共有して使用可能に構成されている。例えばユーザがシステム共通通貨を１０００コスモ有している場合には、この１０００コスモをゲームサーバ１が提供するゲーム１でも、ゲームサーバ２が提供するゲーム２でも使用することができる。ただし、各ゲームにより使用する通貨が異なる場合には、各ゲームの使用通貨に換金して使用することになる。例えばゲーム１では通貨の単位が「ルビー」であり、ゲーム２では、通貨の単位が「ダイヤ」である場合には、ゲーム１で使用する際には「コスモ」を「ルビー」に両替して使用し、ゲーム２で使用する際には「コスモ」を「ダイヤ」に両替して使用する。

このような場合、ゲームサーバ１で提供していたゲーム１がクローズとなる場合に、ゲーム１のゲーム内通貨「ルビー」をシステム共通通貨「コスモ」に換金することにより、共通管理サーバが管理している他のゲームサーバが提供するゲームのゲーム内通貨に両替できる。

ただしシステム共通通貨に換金するためには、ユーザのユーザ情報が共通管理サーバの共通管理ユーザ情報ＤＢに登録されていること（共通管理システムにユーザ登録されていること）が必要である。

図１１は、システム共通通貨に換金する場合の登録画像の一例である。図５の５３０において、ユーザが「システム共通通貨に換金」を選択した場合に、ユーザが共通管理システムにユーザ登録されていない場合には、ゲームサーバ２０は端末１０に図１１の９１０のような画像を提供し、ユーザが共通管理システムにユーザ登録されていないことを通知し（９１２参照）、共通管理システムへのユーザ登録を促す（９１４参照）。ユーザが「はい」指示すると、ゲームサーバ２０−１は９２０に示すような共通管理システムのユーザ登録画像を提供し、ユーザの入力情報を共通管理サーバ４０に送信し、共通管理システムに対するユーザ登録が終了すると、共通管理サーバ９３０に示すような画像を提供して、ゲーム内通貨の残高Ｒ２をシステム共通通貨Ｃ２コスモに換金したことを通知する。システム共通通貨Ｃ２コスモの換金額は、ユーザの共通管理システムのユーザ識別情報に関連付けて、共通管理ユーザ情報ＤＢに格納される。

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

１ ネットワークシステム、２ インターネット、１０ 端末、２０ ゲームサーバ、２２ ゲーム履歴情報データベース、２４ ゲームユーザ情報データベース、３０ 課金サーバ、３２ クレジット情報データベース、３４ 課金ユーザ情報データベース、２００
処理部、２１０ ネットワーク設定部、２１１ 通信制御部、２１２ ユーザ識別情報取得部、２１３ 通知処理部、２２０ ゲーム処理部、２２２ 返金登録処理部、２２３
ゲーム内通貨消費制限処理部、２２４ 認証処理部、２７０ 記憶部、２７２ 主記憶部、２６０ 格納部、２６１ ゲームユーザ情報、２６２ ゲーム履歴情報

Claims (9)

1. 端末と通信し、ユーザが購入したゲーム内通貨を消費させてゲーム内アイテムを購入させるゲームを実行させるサーバにおいて、
   前記端末から受信したユーザ識別情報を取得するユーザ識別情報取得部と、
   前記ユーザ識別情報に基づいて、前記端末に前記ユーザのゲーム内通貨の残高を通知する通知処理部と、
   前記端末から前記ゲーム内通貨の返金に関する返金登録を受け付け、指定された指定返金額を前記ユーザ識別情報に関連付けて前記返金登録をおこなう返金登録処理部と、を含み、
   前記通知処理部は、
   前記ユーザ識別情報に関連付けて記憶されている前記ゲーム内通貨の残高がある場合に、前記端末に対して前記返金登録に関する通知を行うことを特徴とするサーバ。
2. 請求項１において、
   前記返金登録が行われた場合に、前記ユーザ識別情報に関連付けて記憶されている前記ゲーム内通貨の消費を制限する処理を行うゲーム内通貨消費制限処理部を、さらに含むサーバ。
3. 請求項２において、
   前記通知処理部は、
   前記端末から前記ゲーム内通貨の消費を伴う指示入力が行われた場合に、前記ゲーム内通貨の消費の可否、又は消費後の前記ゲーム内通貨の残高を通知するサーバ。
4. 請求項１乃至３のいずれか１項において、
   ゲーム内通貨消費制限処理部は、
   前記ゲーム内通貨の消費を行うことにより、前記ゲーム内通貨の残額が前記指定返金額を下回る場合には、前記ゲーム内通貨の消費を禁止する処理を行い、
   前記通知処理部は、
   前記ゲーム内通貨の消費を行うことにより、前記ゲーム内通貨の残額が前記指定返金額を下回る場合には、その旨を通知する処理を行うサーバ。
5. 請求項１乃至４のいずれか１項において、
   前記返金登録処理部は、
   前記指定返金額を前記ゲーム内通貨から差し引いた残額がいずれのゲーム内アイテムも購入できない端数額である場合、又はいずれかのゲーム内アイテムを購入した後の残額が前記端数額になることが確実である場合には、前記指定返金額の登録を許可しないサーバ。
6. 請求項１乃至５のいずれか１項において、
   前記通知処理部は、
   前記ゲーム内通貨の消費を伴う指示入力が行われた場合に、前記ユーザ識別情報に関連付けて前記返金登録がされているか否か判断し、前記返金登録がされていると判断した場合には、ゲーム内通貨の消費後の残高を通知するサーバ。
7. 請求項１乃至６のいずれか１項において、
   ユーザを認証するための認証情報を用いてユーザ認証を行う認証処理部をさらに含み、
   前記返金登録処理部は、
   前記認証処理部により認証されたユーザについて前記返金登録を行うサーバ。
8. 請求項７において、
   前記認証処理部は、
   ユーザの所定の個人情報の登録が行われた場合に、前記認証情報として、認証番号を生成してユーザに提供し、
   ユーザ端末から受信した前記認証番号を用いてユーザを認証するサーバ。
9. 端末と通信し、ユーザが購入したゲーム内通貨を消費させてゲーム内アイテムを購入させるゲームを実行させるためのプログラムにおいて、
   前記端末から受信したユーザ識別情報を取得するユーザ識別情報取得部と、
   前記ユーザ識別情報に基づいて、前記端末に前記ユーザのゲーム内通貨の残高を通知する通知処理部と、
   前記端末から前記ゲーム内通貨の返金に関する返金登録を受け付け、指定された指定返金額を前記ユーザ識別情報に関連付けて前記返金登録をおこなう返金登録処理部と、してコンピュータを機能させ、
   前記通知処理部は、
   前記ユーザ識別情報に関連付けて記憶されている前記ゲーム内通貨の残高がある場合に、前記端末に対して前記返金登録に関する通知を行うことを特徴とするプログラム。

Images