(57)【要約】      （修正有）【課題】頻繁にネットワークを介してサービスを利用するユーザに継続的にサービスを利用してもらうようにした情報処理装置、情報処理システム、プログラムを提供する。【解決手段】ユーザの操作に基づくサービスの処理要求を送信または受信可能な情報処理装置であって、サービスの処理要求に関連して送信または受信されるデータのデータ量に関する情報と、当該サービスの処理要求の元となる操作をなしたユーザを識別するユーザ識別情報とを取得する取得手段と、取得手段によって取得されたデータ量に関する情報に基づいて、取得手段によって取得されたユーザ識別情報により識別されるユーザに付与すべき報酬の内容を決定する決定手段と、を備える。【選択図】図１０
2015133041.tif 000002
【特許請求の範囲】
【請求項１】
ユーザの操作に基づくサービスの処理要求を送信または受信可能な情報処理装置であって、
前記サービスの処理要求に関連して送信または受信されるデータのデータ量に関する情報と、当該サービスの処理要求の元となる操作をなしたユーザを識別するユーザ識別情報とを取得する取得手段と、
前記取得手段によって取得された前記データ量に関する情報に基づいて、前記取得手段によって取得された前記ユーザ識別情報により識別されるユーザに付与すべき報酬の内容を決定する決定手段と、
を備えた、情報処理装置。
【請求項２】
前記取得手段によって取得された前記データ量に関する情報を用いて、前記取得手段によって取得された前記ユーザ識別情報により識別されるユーザに報酬を付与するための付与条件を満たしているか否かを判定する判定手段、をさらに備え、
前記決定手段は、前記判定手段による判定の結果、前記付与条件を満たしていると判定された場合に、前記ユーザに付与する報酬の内容を決定する、
請求項１に記載された情報処理装置。
【請求項３】
前記取得手段によって取得された前記データ量に関する情報を用いて、累計のデータ量に関する情報を記憶装置に記憶させる記憶手段、をさらに備え、
前記付与条件は、前記記憶装置が記憶する累計のデータ量が所定値に達したことである、
請求項２に記載された情報処理装置。
【請求項４】
前記サービスの処理要求の種別ごとに前記データ量を調整するための調整方法が対応付けられ、
前記判定手段は、前記サービスの処理要求に関連して送信または受信したデータのデータ量を、当該サービスの処理要求に対応付けられた調整方法によって調整し、当該調整後のデータ量に基づいて判定する、
請求項１〜３のいずれかに記載された情報処理装置。
【請求項５】
前記調整方法は、前記サービスの処理要求の種別ごとに設定されている重み付け係数を用いて前記データ量を調整する方法、または前記サービスの処理要求の種別ごとに設定されている数式若しくはデータテーブルを用いて前記データ量を調整する方法である、
請求項４に記載された情報処理装置。
【請求項６】
前記サービスの処理要求を送信または受信した時間帯または期間に基づいて、少なくともいずれかのサービスの処理要求の種別に対応する調整方法を変更する変更手段、をさらに備えた、
請求項４または５に記載された情報処理装置。
【請求項７】
前記判定手段は、前記報酬を付与するための付与条件を満たしているか否かをユーザごとに判定し、
前記決定手段は、前記付与条件を満たした順に所定数のユーザに対して付与する報酬の内容を、前記付与条件を満たしていると判定され、かつ当該所定数のユーザ以外のユーザに対して付与する報酬の内容とは異ならせる、
請求項１〜６のいずれかに記載された情報処理装置。
【請求項８】
前記報酬は、前記サービス内で利用可能な報酬である、
請求項１〜７のいずれかに記載された情報処理装置。
【請求項９】
ユーザの操作に基づくサービスの処理要求を送信可能なユーザ端末と、前記サービスの処理要求を受信可能なサーバと、を含む情報処理システムであって、
前記サービスの処理要求に関連して送信または受信されるデータのデータ量に関する情報と、当該サービスの処理要求の元となる操作をなしたユーザを識別するユーザ識別情報とを取得する取得手段、
前記取得手段によって取得された前記データ量に関する情報に基づいて、前記取得手段によって取得された前記ユーザ識別情報により識別されるユーザに付与すべき報酬の内容を決定する決定手段、
の各手段を、前記ユーザ端末または前記サーバの少なくともいずれか一方が備えた
情報処理システム。
【請求項１０】
コンピュータを、
ユーザの操作に基づくサービスの処理要求に関連して送信または受信されるデータのデータ量に関する情報と、当該サービスの処理要求の元となる操作をなしたユーザを識別するユーザ識別情報とを取得する取得手段、
前記取得手段によって取得された前記データ量に関する情報に基づいて、前記取得手段によって取得された前記ユーザ識別情報により識別されるユーザに付与すべき報酬の内容を決定する決定手段、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介したデータの送受信処理についての情報処理技術に関する。
【背景技術】
【０００２】
近年、ユーザ端末とサーバとがネットワークを介して通信を行うことで実行されるゲームが普及している（特許文献１）。このようなゲームの中には、ユーザ端末とサーバとがＨＴＴＰに従った通信を行ってユーザ端末のウェブブラウザがＨＴＭＬ文書としてのゲーム画像を表示するもの（ブラウザ形式のゲーム）や、ゲームプログラムをインストールしたユーザ端末が主体的にゲームを実行しつつ必要に応じてサーバからデータをダウンロードするもの（ネイティブアプリケーション形式のゲーム）などが知られている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特許４８５５５４９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ブラウザ形式のゲームでは、サーバからユーザ端末へ送信されるデータ量が多い場合、ダウンロードに時間が掛かってユーザに不満が生ずる場合がある。特に、高画質な画像データを用いるゲームでは尚更である。また、ネイティブアプリケーション形式のゲームでは、ユーザ端末のゲームの進行に必要なデータテーブルや画像データをサーバが保持している場合、それらのデータ量が多い場合にはユーザ端末へのダウンロードに時間が掛かり、やはり不満が生ずる場合がある。また、ユーザ端末にデータテーブル等を保持していたとしても、ユーザ端末とサーバとの間で、ゲームをアップデートするために必要なデータのやり取りが行われ、そのデータ量が多い場合にはユーザ端末へのダウンロードに時間が掛かることから不満が生ずる場合もある。
一般的に多くのデータをサーバからダウンロードするユーザ端末のユーザは、より頻繁にゲームを実行している傾向があり、ゲーム提供者にとって優良なユーザであるといえる。そのため、このような優良なユーザに不満を生じさせずに継続的にゲームを実行することが要請される。なお、このような要請は、ゲームに限られず、ネットワークを利用するサービス一般に当てはまる。
【０００５】
本発明は上述した観点に鑑みてなされたものであり、その目的は、頻繁にネットワークを介してサービスを利用するユーザに継続的にサービスを利用してもらうようにした情報処理装置、情報処理システム、プログラムを提供することである。
【課題を解決するための手段】
【０００６】
本発明の一態様は、ユーザの操作に基づくサービスの処理要求を送信または受信可能な情報処理装置であって、
前記サービスの処理要求に関連して送信または受信されるデータのデータ量に関する情報と、当該サービスの処理要求の元となる操作をなしたユーザを識別するユーザ識別情報とを取得する取得手段と、
前記取得手段によって取得された前記データ量に関する情報に基づいて、前記取得手段によって取得された前記ユーザ識別情報により識別されるユーザに付与すべき報酬の内容を決定する決定手段と、
を備えた、情報処理装置である。
【０００７】
本発明の別の態様は、ユーザの操作に基づくサービスの処理要求を送信可能なユーザ端末と、前記サービスの処理要求を受信可能なサーバと、を含む情報処理システムであって、
前記サービスの処理要求に関連して送信または受信されるデータのデータ量に関する情報と、当該サービスの処理要求の元となる操作をなしたユーザを識別するユーザ識別情報とを取得する取得手段、
前記取得手段によって取得された前記データ量に関する情報に基づいて、前記取得手段によって取得された前記ユーザ識別情報により識別されるユーザに付与すべき報酬の内容を決定する決定手段、
の各手段を、前記ユーザ端末または前記サーバの少なくともいずれか一方が備えた
情報処理システムである。
【０００８】
本発明の別の態様は、コンピュータを、
ユーザの操作に基づくサービスの処理要求に関連して送信または受信されるデータのデータ量に関する情報と、当該サービスの処理要求の元となる操作をなしたユーザを識別するユーザ識別情報とを取得する取得手段、
前記取得手段によって取得された前記データ量に関する情報に基づいて、前記取得手段によって取得された前記ユーザ識別情報により識別されるユーザに付与すべき報酬の内容を決定する決定手段、
として機能させるためのプログラムである。
【図面の簡単な説明】
【０００９】
【図１】第１の実施形態のゲームシステムの基本構成を示す図。
【図２】第１の実施形態のユーザ端末の構成を示すブロック図。
【図３】第１の実施形態のゲームサーバの構成を示すブロック図。
【図４】第１の実施形態において送信データ量に基づくユーザへの報酬の付与を概念的に説明するための図。
【図５】第１の実施形態におけるユーザデータテーブルの構成例を示す図。
【図６】所持カードデータテーブルの構成例を示す図。
【図７】所持アイテムデータテーブルの構成例を示す図。
【図８】第１の実施形態のゲームの実行時のユーザ端末に表示される画像の一例を示す図。
【図９】第１の実施形態のゲームの実行時のユーザ端末に表示される画像の一例を示す図。
【図１０】第１の実施形態のゲームサーバの機能ブロック図。
【図１１】第１の実施形態において、送信データ量の記録処理の一例について示すフローチャート。
【図１２】第１の実施形態において、送信データ量に基づくユーザへの報酬付与処理の一例について示すフローチャート。
【図１３】実施形態の変形例におけるユーザデータテーブルの構成例を示す図。
【図１４】実施形態の変形例においてユーザ端末に表示される画像の一例を示す図。
【図１５】実施形態の変形例において、送信データ量に基づくユーザへの報酬付与処理の一例について示すフローチャート。
【図１６】実施形態の変形例において参照される報酬データテーブルの一例を示す図。
【発明を実施するための形態】
【００１０】
（１）第１の実施形態
（１−１）ゲームシステムの構成
以下、情報処理システムの一実施形態として、ゲームシステム１について説明する。
【００１１】
図１は、実施形態のゲームシステム１のシステム構成例を示している。図１に示すように、このゲームシステム１は、ユーザ端末１０ａ，１０ｂ，１０ｃ，…、およびゲームサーバ２０を含む。各ユーザ端末１０ａ，１０ｂ，１０ｃからゲームサーバ２０に対しては、例えばインターネットなどの通信網ＮＷを通してアクセス可能である。ゲームサーバ２０は、情報処理装置の一例である。
各ユーザ端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、フィーチャーフォン、スマートフォン、タブレット端末、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機（いわゆる多機能型のスマートテレビも含む。）、通信機能付き携帯ゲーム機などの通信端末である。以下の説明において、各ユーザ端末１０ａ，１０ｂ，１０ｃ，…に共通して言及するときには、ユーザ端末１０と表記する。
【００１２】
ゲームサーバ２０は、ゲームを実行するサーバである。ゲームサーバ２０には、ウェブブラウザによって解釈可能な画像データ（本実施形態では、例えばＨＴＭＬ、ＸＭＬなどの形式で記述された画像データのことである。）を作成可能なプログラムが実装されている。なお、画像データは、出力データの一例である。
ユーザ端末１０は、ゲームサーバ２０によって提供されるＨＴＭＬ文書を解釈して表示するウェブブラウザを備えており、ユーザ端末１０によるウェブページ上のユーザの操作に基づく要求を、ネットワークを介してゲームサーバ２０へ送信し、ゲームサーバ２０による処理結果を受信することでゲームの処理を実行する。
通信網ＮＷは、例えば、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）、専用回線、又はこれらの組み合わせによって構成される情報通信ネットワークである。
【００１３】
（１−２）ユーザ端末の構成
図２を参照してユーザ端末１０について説明する。
図２に示すように、ユーザ端末１０は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ(Read Only Memory)１２、ＲＡＭ(Random Access Memory)１３、操作入力部１５、表示部１６、通信インタフェース部１７、および、ストレージ１８を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス１９が設けられている。
【００１４】
ＣＰＵ１１は、ＲＯＭ１２に格納されているプログラムやデータを読み出して、ユーザ端末１０内の各部との制御信号やデータ信号のタイミング処理等、ユーザ端末１０内の全体の動作を制御する。ＣＰＵ１１はまた、ストレージ１８に記憶されているプログラムや、プログラムの実行に必要な各種データを読み出してＲＡＭ１３に展開し、プログラムの実行に伴うデータの入出力処理、演算処理、判定処理等の各種処理を行う。ＲＡＭ１３は、ＣＰＵ１１による演算処理、判定処理等のために一時的にデータを記憶する。
【００１５】
例えば、ＣＰＵ１１は、ストレージ１８内に格納されているウェブブラウザをＲＡＭ１３にロードして実行する。そして、ＣＰＵ１１は、操作入力部１５等によってユーザに入力されるＵＲＬ(Uniform Resource Locator)の指定に基づき、通信インタフェース部１７を介して、ゲームサーバ２０からウェブページを表示するためのデータ、すなわち、ＨＴＭＬ(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ（以下、総称して適宜「ＨＴＭＬデータ」と表記する。）を、通信インタフェース部１７を介して取得し、ウェブブラウザを実行してＨＴＭＬデータを解釈する。なお、ユーザ端末１０には、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインが実装されていてもよい。そのようなプラグインの一例は、米国のアドビシステムズ社によるフラッシュプレイヤである。あるいは、本実施形態でのＨＴＭＬデータを、動画及び音声の再生機能を備えたＨＴＭＬ５形式としてもよい。
【００１６】
ウェブブラウザは、ゲームサーバ２０とＨＴＴＰ(HyperText Transfer Protocol)に従った通信を行う。ウェブブラウザは、ユーザによる操作入力部１５の操作によってウェブページ上のＵＲＬ(Uniform Resource Locator)または操作対象（例えば、ソフトウェアボタン（以下、単に「ボタン」と表記する。）等）が選択されると、ウェブページの更新のために、その選択結果を含むＨＴＴＰリクエストをゲームサーバ２０に送信する。ウェブブラウザは、ＨＴＴＰレスポンスとしてゲームサーバ２０からＨＴＭＬデータを取得し、解釈して、ウェブページの画像を表示部１６に表示する。
本実施形態において、ＨＴＭＬデータは画像データの一例である。
【００１７】
表示部１６は、たとえば、ＬＣＤ(Liquid Cristal Display)や有機ＥＬ(Electro Luminescence)ディスプレイ等の表示デバイスである。マトリクス状に画素単位で配置された薄膜トランジスタを含むＬＣＤ(Liquid Cristal Display)モニタを適用した場合、表示部１６は、薄膜トランジスタを駆動することでウェブページの画像を表示画面に表示する。
【００１８】
ユーザ端末１０が釦入力方式のユーザ端末である場合、操作入力部１５は、例えば、ユーザの操作入力を受け入れるための方向指示釦、決定釦、テンキーなどの複数の指示入力釦を備え、各釦の押下（操作）入力を認識してＣＰＵ１１へ出力するためのインタフェース回路を含む。
ユーザ端末１０がタッチパネル入力方式のユーザ端末である場合、操作入力部１５は、主として表示画面に指先あるいはペンで触れることによるタッチパネル方式の入力を受け付ける。
【００１９】
ストレージ１８は、例えばフラッシュメモリあるいはＨＤＤ(Hard Disk Drive)によって構成される記憶装置である。
【００２０】
（１−３）ゲームサーバの構成
図３を参照してゲームサーバ２０の構成について説明する。
図３に示すように、ゲームサーバ２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、通信インタフェース部２４、および、ストレージ２５を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス２６が設けられている。なお、ゲームサーバ２０は、ハードウェアに関しては汎用のネットワークサーバと同一の構成をとることができる。
【００２１】
ＣＰＵ２１は、ＲＯＭ２２に格納されているプログラムやデータを読み出して、ゲームサーバ２０内の各部との制御信号やデータ信号のタイミング処理等、ゲームサーバ２０内の全体の動作を制御する。ＣＰＵ２１はまた、ストレージ２５に記憶されているプログラムや、プログラムの実行に必要な各種データを読み出してＲＡＭ２３に展開し、プログラムの実行に伴うデータの入出力処理、演算処理、判定処理等の各種処理を行う。ＲＡＭ２３は、ＣＰＵ２１による演算処理、判定処理等のために一時的にデータを記憶する。
【００２２】
例えば、ストレージ２５には、クライアントであるユーザ端末１０のウェブブラウザとの間でＨＴＴＰに従った通信を行ってウェブサービスを提供するプログラムが格納されている。ＣＰＵ２１は、ストレージ２５に格納されているプログラムをＲＡＭ２３に展開して、プログラムを実行する。プログラムの実行に伴ってＣＰＵ２１は、通信インタフェース部２４を介してユーザ端末１０からＨＴＴＰリクエストを取得し、当該ＨＴＴＰリクエストに応じた処理を実行し、その実行結果を含むＨＴＭＬデータをＨＴＴＰレスポンスとしてユーザ端末１０へ返す。
【００２３】
ストレージ２５は、例えばフラッシュメモリあるいはＨＤＤ(Hard Disk Drive)によって構成される記憶装置であり、上述したプログラムに加え、データテーブル群７０（後述する）を格納する。データテーブル群７０は、ユーザデータテーブル、所持カードデータテーブル、および、所持アイテムデータテーブルを含む。ストレージ２５内の各データテーブルは、適宜ＣＰＵ２１からデータの読み書きのためにアクセスされる。
【００２４】
（１−４）送信データ量に基づくユーザへの報酬付与
以下、本実施形態のゲームにおいて、ゲームサーバ２０からユーザのユーザ端末１０へ送信されるデータのデータ量（以下、「送信データ量」という。）に基づいて、当該ユーザへ報酬が付与される原理について、図４を参照して説明する。
本施形態のゲームシステム１において実行されるゲームは、特に限定されるものではないが、以下では説明の便宜上、ユーザがオブジェクトとしてのカードを利用するゲームである場合について説明する。このゲームには、ユーザが各ステージを探索あるいは進行するクエスト機能（以下、単に「クエスト」という。）、ユーザが所持するカード（以下、適宜「所持カード」という。）を用いて他のユーザやＮＰＣ(Non-Player Character)との間で行われる対戦する対戦機能（以下、単に「対戦」という。）、および、ユーザが抽選を行うことによってカードやアイテムを取得する抽選機能（以下、単に「抽選」という。）などが設けられている。
【００２５】
図４を参照すると、本実施形態で例示する処理要求とは、ユーザがユーザ端末１０を介して上述したクエスト、対戦、または抽選のいずれかの処理のゲームサーバ２０への要求である。ゲームサーバ２０は処理要求を取得すると、取得した処理要求に応じた処理を実行し、その処理に必要なデータや、処理の実行結果を含む画像データ等をユーザ端末１０へ送信する。
ここで、ゲームサーバ２０からユーザ端末１０への送信データ量が付与条件を満たしている場合には、ユーザに対して報酬を付与することが決定される。すなわち、送信データ量が多くなるような操作を行うユーザに対して報酬が付与され、それによって当該ユーザが優遇されるような仕組みを構築することができる。この仕組みには以下の利点がある。すなわち、一般的に多くのデータをサーバからダウンロードするユーザ端末１０のユーザは、より頻繁にサービスを利用している傾向があり、サービス提供者にとって優良なユーザであるといえるが、このような仕組みを構築することで、データの待ち時間に起因する不満を生じ難くさせることができるため、優良なユーザに継続的にサービスを利用してもらうことができる。
【００２６】
（１−５）データテーブルの構成
次に、ゲームサーバ２０のストレージ２５に格納されるデータテーブル群７０の各データテーブル（ユーザデータテーブル、所持カードデータテーブル、および、所持アイテムデータテーブル）について、図５〜７を参照して順に説明する。ゲームサーバ２０のストレージ２５は、記憶装置の一例である。
【００２７】
（i）ユーザデータテーブル
ユーザデータテーブルには、ユーザごとにゲームに関連する各種のデータが記録されている。図５にユーザデータテーブルの構成例を示す。図５に示すユーザデータテーブルの例では、ユーザＩＤごとに、ユーザ名、レベル、ステージ、体力、および、所持ポイントの各項目のデータが対応付けられて記録されており、各項目のデータの内容は以下のとおりである。ユーザＩＤは、ユーザ識別情報の一例である。なお、図５に示す項目は例示に過ぎず、ゲーム上でユーザに対応付けられる他の項目を適宜設定してもよい。
ユーザ名は、ゲームの実行時にユーザ端末１０のユーザを特定するために表示されるユーザ名である。ユーザ名は、例えばユーザによって予め指定される所定長以下のテキストである。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
ユーザのレベルは、本実施形態のゲームにおいて予め規定された規則に従って増加する。ゲームレベルは例えば、対戦でユーザが勝利した数、又は対戦での勝率が増加するにつれて増加してもよい。ユーザのステージは、ユーザがクエストによって到達したステージを示す値であり、初期値は１である。
ユーザの体力は、クエストを実行するときに変動するパラメータである。クエストを実行する度に体力が所定量低下し、所定時間が経過する度に体力が所定量増加する。
ユーザの所持ポイントは、ユーザがゲーム上で所持するポイントの値（単位：ｐｔ）である。本実施形態の例では、ユーザに付与される報酬が、送信データ量に応じた量のポイントとして説明を行うが、報酬は、ポイントに限られるものではない。報酬は、例えば、カード、アイテムなどのゲーム内で用いられるオブジェクトであってもよい。また、報酬は、ゲーム内で用いられるポイント、オブジェクトに限られるものではなく、ゲーム内での利用に限られない電子的な報酬（例えば、所定量のサービスポイントや電子マネー等）であってもよい。さらに、ユーザに付与される実体のある報酬（例えば、ギフトカードや時計等）であってもよい。つまり、ユーザに付与される報酬は、頻繁にネットワークを介してサービスを利用するユーザに継続的にサービスを利用してもらうための報酬であることから、どのような報酬であってもよい。
なお、報酬をポイントとすることで、報酬が付与されたユーザが、直ちにゲーム内で報酬としてのポイントを利用することができるため、積極的に報酬を得ようとする動機付けが強くなるという利点がある。
【００２８】
（ii）所持カードデータテーブル
所持カードデータテーブルには、ユーザの所持カードの情報が記録されている。図６に所持カードデータテーブルの構成例を示す。図６では１ユーザ分の所持カードデータテーブルを例示するが、所持カードデータテーブルは、ゲームに登録しているユーザ毎に設けられる。
図６に示す所持カードデータテーブルには、カードＩＤごとにカードレベルが対応付けられて記録されている。カードＩＤに対応するカード名、カード画像、およびパラメータ（例えば、対戦におけるＨＰ（Hit Points）、攻撃力、防御力等）は、カードデータテーブル（図示せず）に定義されている。カードレベルは、カードの育成レベルを示しており、ユーザによるカードを用いた処理によって変動するパラメータである。ユーザがカードを取得した時点でのカードレベルの値（初期値）は１であり、ユーザは例えば、そのカードを他のカードと合成処理することでカードレベルを増加させる（つまり、カードを成長させる）ことができる。
【００２９】
（iii）所持アイテムデータテーブル
所持アイテムデータテーブルには、ユーザが所持するアイテム（所持アイテム）の情報が記録されている。図７に所持カードデータテーブルの構成例を示す。図７では１ユーザ分の所持アイテムデータテーブルを例示するが、所持カードデータテーブルは、ゲームに登録しているユーザ毎に設けられる。図７に示す所持アイテムデータテーブルには、アイテムＩＤごとにアイテム名と所持数のデータが対応付けられて記録されている。本実施形態のゲームでは、ユーザがクエストを実行することでアイテムを取得可能となるように構成されている。ユーザがアイテムを取得した場合には、当該ユーザの所持アイテムデータテーブルが更新される。
【００３０】
（１−６）送信データ量に基づくユーザへの報酬付与の具体例
以下、本実施形態のゲームにおいて送信データ量に基づくユーザへの報酬付与の具体例について、図８および図９を参照しながら説明する。図８および図９はそれぞれ、本実施形態のゲームの処理を実行しているときのユーザ端末１０に表示される画面の一例を示す図である。
【００３１】
(i)クエスト
図８の画像Ｐ０は、ユーザがゲームにログインしたときに表示される画像であり、ゲームのメインメニューを含む。本実施形態の例では、メインメニューは、クエスト、抽選、および対戦の各処理を実行するためのボタンｂ１、ｂ２、およびｂ３を含む。
画像Ｐ０においてボタンｂ１（「クエスト」）が指定されると、Ｐ１に示すように画像が変化する。画像Ｐ１は、ユーザがクエストにおいて進行中のステージ（この例では、ステージ３）と、クエストを実行するためのボタンｂ１１（「探索」）と、クエストを終了するためのボタンｂ１２（「終了」）とを含む。画像Ｐ１においてボタンｂ１１（「探索」）が指定される度に、ユーザは体力を所定量ずつ消費しながらステージを進行させることができる。なお、図示しないが、ボタンｂ１１を指定する度に、各ステージの進行に関連するステージ画像（例えば、ステージの進行に関連するキャラクタや背景等の静止画像や動画像）、あるいはパラメータを表示する画像（例えば、ユーザの残り体力やステージの進行の進み具合を示す百分率等）が表示される。クエストを実行中には、画像Ｐ２に示すように、ユーザがアイテムを取得することができることもある。ボタンｂ１２（「終了」）が指定されるとクエストが終了して、画像Ｐ３が表示される。画像Ｐ３には、送信データ量（図８に示す例では、５ＭＢ）と、その送信データ量に基づいてユーザに付与されるポイント（獲得ポイント；図８に示す例では、５０ｐｔ）とが含まれる。この送信データ量は、画像Ｐ０のボタンｂ１（「クエスト」）の指定によってクエストの実行を開始してからクエストを終了するまでに、ゲームサーバ２０からユーザ端末１０へ送信されたデータ量である。
図８では、ボタンｂ１，ｂ１１がクエストの処理要求を行うためのボタンの例である。
【００３２】
(ii)抽選 
図８の画像Ｐ０においてボタンｂ２（「抽選」）が指定されると、Ｐ４に示すように画像が変化する。画像Ｐ４は、抽選の結果を表示する画像である。ここでは、ユーザに１枚のカードが付与された例が示してある。画像Ｐ４においてボタンｂ２１（「次へ」）を指定すると、Ｐ５に示すように画像が変化する。画像Ｐ５には、画像Ｐ０に戻るためのボタンｂ２２（「メインメニューへ戻る」）、および再度抽選を実行するためのボタンｂ２３（「再度抽選」）のほか、送信データ量（図８に示す例では、０．３ＭＢ）と、その送信データ量に基づいてユーザに付与されるポイント（獲得ポイント；図８に示す例では、３ｐｔ）とが含まれる。この送信データ量は、画像Ｐ０のボタンｂ２（「抽選」）が指定されてから抽選の結果が表示されるまで（つまり、抽選が終了するまで）に、ゲームサーバ２０からユーザ端末１０へ送信されたデータ量である。
図８では、ボタンｂ２，ｂ２３が抽選の処理要求を行うためのボタンの例である。
【００３３】
(iii)対戦 
図９の画像Ｐ０においてボタンｂ３（「対戦」）が指定されると、Ｐ６に示すように画像が変化する。画像Ｐ６は、ゲームサーバ２０によって決定された対戦相手を通知する画像であり、ボタンｂ３１（「対戦する」）とボタンｂ３２（「対戦しない」）を含む。ボタンｂ３１（「対戦する」）が指定されると、画像Ｐ７が表示される。画像Ｐ７は、例えば、ユーザと対戦相手との間の対戦の内容を表示する動画像である。対戦の内容は適宜設定することができる。このような動画像は、例えばゲームサーバ２０から送信される再生ファイルをユーザ端末１０が受信し、ユーザ端末１０が受信した再生ファイルを再生することによって表示されるものであってもよい。あるいは、ユーザと対戦相手の間でターン制の対戦が実行され、ユーザの複数の操作の結果、勝敗が決定されるものであってもよい。その場合、各ターンでの実行結果を含む複数回の静止画像または動画像がゲームサーバ２０からユーザ端末１０へ送信される。
対戦の勝敗が決定すると、画像Ｐ８が表示される。画像Ｐ８には、送信データ量（図９に示す例では、１０ＭＢ）と、その送信データ量に基づいてユーザに付与されるポイント（獲得ポイント；図９に示す例では、１００ｐｔ）とが含まれる。この送信データ量は、画像Ｐ０のボタンｂ３（「対戦」）の指定によって対戦の実行を開始してから勝敗が決定されるまでに、ゲームサーバ２０からユーザ端末１０へ送信されたデータ量である。
図９では、ボタンｂ３，ｂ３１が対戦の処理要求を行うためのボタンの例である。
【００３４】
上述したように、本実施形態のゲームは、メインメニューに含まれる各処理がユーザの操作に基づいて指定され、指定された処理が完了すると、指定された処理においてゲームサーバ２０からユーザ端末１０への送信データ量に基づくポイントがユーザに付与されるように構成されている。
【００３５】
（１−７）情報処理装置が備える機能の概要
次に、上述した本実施形態のゲームを実現するためにゲームサーバ２０が備える機能について説明する。図１０は、本実施形態のゲームサーバ２０で主要な役割を果たす機能を説明するための機能ブロック図である。図１０において、データテーブル群７０は、前述したように、ユーザデータテーブル、所持カードデータテーブル、および、所持アイテムデータテーブルを含む。なお、図１０に示す機能ブロック図に含まれる手段のすべてが本発明に必須の要素とは限らない。例えば、本実施形態では、取得手段５３および決定手段５５を備えていればよい。記憶手段５７および変更手段５８は変形例において言及される。
【００３６】
受付手段５１は、ユーザの操作入力に関する情報に基づいてユーザ端末１０からの様々な処理要求を受け付ける機能を備える。本実施形態のゲームにおいユーザ端末１０からの処理要求の例は、上述したクエストの処理要求（以下、「クエスト要求」）、抽選の処理要求（以下、「抽選要求」）、および、対戦の処理要求（以下、「対戦要求」）である。
受付手段５１の機能を実現するために、ゲームサーバ２０は、通信インタフェース部２４を介して、ユーザ端末１０からユーザによる操作入力に対応する処理要求を受信する。ゲームサーバ２０のＣＰＵ２１は、受信した処理要求に含まれる情報に基づいて、処理要求の受付処理を行う。受付処理では、受信した処理要求がユーザＩＤと対応付けてＲＡＭ１３に書き込まれる。ＣＰＵ２１は、受け付けられた要求に応じた処理を順に実行する。
【００３７】
ゲーム実行手段５２は、受付手段５１にて受け付けたユーザ端末１０からの処理要求に基づいて処理を実行する機能を備える。ゲーム実行手段５２の機能は、例えば以下のようにして実現される。
ゲームサーバ２０のＣＰＵ２１は、クエスト要求を受け付けると、要求元のユーザのユーザＩＤに対応するステージおよび体力のデータをユーザデータテーブルから読み出し、これらのデータを含むパラメータを適宜更新する。例えば、ＣＰＵ２１は、クエスト要求を受け付ける度に体力の値を所定量減少させ、ステージの進行の進み具合を示す百分率の値を所定量増加させる。ＣＰＵ２１は、ステージの進行の進み具合を示す百分率の値が所定値（例えば、１００％）に達した場合には、ステージの値を１つ増加させる。各ステージの進行に関連するステージ画像（例えば、ステージの進行に関連するキャラクタや背景等の静止画像や動画像）のデータが図示しないデータテーブルに記録されており、ＣＰＵ２１は当該データテーブルから、処理中のステージの進行に関連するステージ画像を読み出し、読み出したステージ画像と、更新後のパラメータとが含まれるようにして、ユーザ端末１０へ送信する画像データを生成する。
【００３８】
ゲームサーバ２０のＣＰＵ２１は、抽選要求を受け付けると、カードＩＤごとにカードの画像およびパラメータが対応付けられたカードデータテーブル（図示せず）、または、アイテムＩＤごとにアイテムの画像およびパラメータが対応付けられたアイテムデータテーブル（図示せず）から、無作為に所定数のカードまたはアイテムを選択する処理を行う。ＣＰＵ２１は、選択された所定数のカードまたはアイテムの画像およびパラメータが含まれるようにして、ユーザ端末１０へ送信する画像データを生成する。また、ＣＰＵ２１は、選択したカードまたはアイテムのデータに基づいて、要求元のユーザの所持カードデータテーブルまたは所持アイテムデータテーブルを更新する。
【００３９】
ゲームサーバ２０のＣＰＵ２１は、対戦要求を受け付けると、対戦処理を実行する。対戦処理は、要求元のユーザの対戦相手の選択処理、ＨＰ等の対戦に関するパラメータの更新処理、対戦に関する画像データの生成および送信の処理を含む。
具体的には、ＣＰＵ２１は、ＮＰＣとの対戦では、例えば予め設定されている複数の対戦相手（モンスターキャラクタ等）の中からいずれかの対戦相手を選択する。ＣＰＵ２１は、ユーザ間の対戦では、例えば、要求元のユーザ以外のユーザの中から無作為にいずれかのユーザを選択し、選択されたユーザを要求元のユーザの対戦相手とする。
パラメータの種類およびその更新方法は、適用される対戦の内容や規則に応じて適宜設定される。例えばターン制の対戦では、ＣＰＵ２１は、要求元のユーザの操作入力に基づく当該ユーザの攻撃と、対戦相手の攻撃とが交互に実行されるように制御し、各攻撃に基づいてユーザおよび対戦相手のＨＰを、攻撃力に応じて低下させる。ＣＰＵ２１は、ユーザおよび対戦相手のいずれかのＨＰがゼロになった時点で対戦を終了させる。ＣＰＵ２１は、各ターンにおいて、ユーザおよび対戦相手のパラメータの値を含み、かつ対戦の内容を示す静止画像あるいは動画像のデータ（画像データ）を生成し、ユーザ端末１０へ送信する。
【００４０】
ゲームサーバ２０のＣＰＵ２１は、処理要求に基づく処理を実行する度に、受け付けた処理要求の要求元のユーザのユーザＩＤと対応付けて、当該処理要求に関連した送信データ量に関する情報をＲＡＭ２３に書き込む。ＣＰＵ２１は、処理要求に関連した送信データ量に関する情報を書き込むために、例えば、当該処理要求に対するＨＴＴＰレスポンスであるＨＴＭＬデータを構成するパケット数を計数する。書込み対象となる送信データ量に関する情報は、パケット数であってもデータ量自体（バイト数等）であってもよい。
【００４１】
送信データ量に関する情報は、送信データ量をパケット数に基づいて算出する場合に限られず、処理要求に基づく送信データ量の推定値や、送信データ量の指標値であってもよい。
例えば、クエスト要求、抽選要求、および、対戦要求等の処理要求の種別ごとのユーザ端末１０への送信データ量が例えば統計上見積もることが可能な場合には、種別ごとの要求回数に基づいて、送信データ量を推定することができる。例えば、クエスト要求（１回のボタンｂ１１（図８参照）の指定による処理要求）に対応する送信データ量の規定値をＡ１[MB]、抽選要求（１回のボタンｂ２（図８参照）の指定による処理要求）に対応する送信データ量の規定値をＡ２[MB]、対戦要求（１回のボタンｂ３１（図９参照）の指定による処理要求）に対応する送信データ量の規定値をＡ３[MB]、といった具合に予め規定しておき、各処理要求の受付回数を計数することによって、送信データ量を適宜推定することができる。例えば、クエスト要求が３回である場合には、送信データ量を３×Ａ１として推定することができる。
また、送信データ量の指標値は、算出若しくは推定した送信データ量を、例えば以下に示すように、複数段階のいずれかに区分したデータであってもよい。
【００４２】
［送信データ量の指標値の具体例］
・レベル１…送信データ量がＢ１[MB]未満
・レベル２…送信データ量がＢ２[MB]以上Ｂ２[MB]未満
・レベル３…送信データ量がＢ２[MB]以上
【００４３】
取得手段５３は、各処理要求に関連した送信データ量に関する情報と、当該処理要求の元となる操作をなしたユーザ（すなわち、要求元のユーザ）のユーザＩＤとを取得する機能を備える。
取得手段５３の機能を実現するために、処理要求に関連した送信データ量に関する情報をＲＡＭ２３から読み出す（取得する）。
処理要求に関連した送信データ量をＲＡＭ２３から読み出すタイミングは、適宜設定することができる。図８および図９に例示したクエスト、抽選、および、対戦の各処理の例では、ＣＰＵ２１は、関連した一連の処理要求に対する処理を実行する間、ＲＡＭ２３内の送信データ量に関する情報を更新し、その一連の処理要求に対する処理が終了した時点（例えば、図８において画像Ｐ３若しくはＰ５、または図９において画像Ｐ８を表示するための画像データを生成する時点）で、ＲＡＭ２３から送信データ量に関する情報を読み出す（取得する）。
処理要求に関連した送信データ量に関する情報をＲＡＭ２３から読み出すタイミングは、個々の処理要求を受け付けたタイミングであってもよい。その場合、例えば図８に示したクエストの例では、ボタンｂ１１（「探索」）を指定する度にＲＡＭ２３から送信データ量を読み出す（取得する）。
処理要求に関連した送信データ量に関する情報をＲＡＭ２３から読み出すタイミングは、関連した一連の処理要求に対する処理が完了した時刻よりも後の時刻であってもよく、例えばアクセスにおける１つのセッションが終了する時刻であってもよい。
【００４４】
判定手段５４は、取得手段５３によって取得された送信データ量に関する情報を用いて、取得手段５３によって取得されたユーザＩＤのユーザに報酬を付与するための付与条件を満たしているか否かを判定する機能を備える。送信データ量に関する情報が付与条件を満たしているか否かを判定できる限り、付与条件は適宜設定することができる。例えば、送信データ量に関する情報が、算出若しくは推定した送信データ量である場合、付与条件として「送信データ量がＴ１[MB]以上である」という条件を設定してもよい。送信データ量に関する情報がレベル１〜３のいずれかに区分されたデータである場合、付与条件として「送信データ量がレベル２以上である」という条件を設定してもよい。
判定手段５４の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、処理要求に関連した送信データ量に関する情報と、要求元のユーザのユーザＩＤとをＲＡＭ２３から取得すると、取得した送信データ量に関する情報が付与条件を満たすか否かについて判定する。
なお、判定手段５４を設けることは必須でないが、付与条件に基づいて報酬の内容を決定することで、付与条件に応じて報酬の内容を画一的ではなく柔軟に設定できるようになる。また、判定手段５４を設けることが必須でない理由として、付与条件の判定自体をゲームサーバ２０以外の別の装置に行わせてその判定結果をゲームサーバ２０が受け取るようにした場合、ゲームサーバ２０において判定自体を行う必要がないことが挙げられる。
【００４５】
決定手段５５は、判定手段５４による判定の結果、付与条件を満たしていると判定された場合に、ユーザに付与する報酬の内容を決定する機能を備える。本実施形態の例では、報酬はゲーム内のポイントであるが、その内容は適宜設定することができる。例えば、ユーザに付与するポイントの量は一定値であってもよいし、送信データ量に比例した量のポイントであってもよいし、送信データ量に応じて段階的に設定された量のポイントであってもよい。
決定手段５５の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、送信データ量に関する情報を用いて付与条件を満たすと判定した場合、予め規定された、送信データ量に関する情報と報酬の内容との関係に基づいて、報酬の内容を決定する。例えば、図８および図９に示した例では、送信データ量をα [MB]とし、報酬としての獲得ポイントをβ［pt］としたときに、β＝１０×αの関係に基づいて、報酬の内容が決定される。
【００４６】
ＣＰＵ２１は、通信インタフェース部２４を介して、送信データ量に関する情報と、決定した報酬の内容（ポイント）とを含む画像データをユーザ端末１０へ送信する。また、ＣＰＵ２１は、ＲＡＭ２３の送信データ量の値をリセットする（つまり、ゼロにする）。
なお、報酬の内容を決定するに当たって、送信データ量に関する情報と報酬の内容との関係は、比例関係に限られず、様々な観点から設定されてもよい。以下に、送信データ量に関する情報と、報酬の内容との関係の他の具体例を示す。
【００４７】
［送信データ量に関する情報と報酬の内容との関係の具体例１］
・送信データ量がＴ１[MB]以上Ｔ２[MB]未満である場合…報酬の内容：１ＭＢ当たり５０ｐｔ
・送信データ量がＴ２[MB]以上である場合…報酬の内容：１ＭＢ当たり８０ｐｔ
【００４８】
［送信データ量に関する情報と報酬の内容との関係の具体例２］
・送信データ量に関する情報がレベル２である場合…報酬の内容：１２０ｐｔ
・送信データ量に関する情報がレベル３である場合…報酬の内容：２００ｐｔ
【００４９】
付与手段５６は、決定手段５５によって決定された報酬の内容に基づいて、ユーザに報酬を付与する機能を備える。
付与手段５６の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、報酬の内容として決定されたポイントの量が付与対象のユーザの現在のポイントに加算されるようにして、当該ユーザのユーザデータテーブルを更新する。それによって、ユーザに報酬としてポイントが付与されたことになる。
【００５０】
（１−８）本実施形態のゲームの処理フロー
次に、本実施形態のゲームの処理フローについて、図１１および図１２を参照して説明する。図１１は、送信データ量の記録処理の一例について示すフローチャートである。図１２、送信データ量に基づくユーザへの報酬付与処理の一例について示すフローチャートである。なお、以下では、取得対象となる送信データ量に関する情報が送信データ量自体（例えばバイト数）である場合を例として説明する。
【００５１】
図１１において、ゲームサーバ２０のＣＰＵ２１は、通信インタフェース部２４を介して、ユーザ端末１０からユーザによる操作入力に対応する処理要求を取得すると（Ｓ１０：ＹＥＳ）、取得した処理要求の受付処理を行う（Ｓ１２）。受付処理は、処理要求をユーザＩＤと対応付けてＲＡＭ１３へ記録する処理が含まれる。ＣＰＵ２１は、Ｓ１２で受け付けた処理要求に基づく処理を実行する（Ｓ１４）。実行される処理の内容は、受け付けた処理要求の種別（本実施形態の例では、クエスト要求、抽選要求、または対戦要求のいずれかの種別）によって異なる。
ＣＰＵ２１は、Ｓ１４での処理結果を含む画像データを生成する（Ｓ１６）。ＣＰＵ２１は、通信インタフェース部２４を介して、Ｓ１６で生成した画像データをユーザ端末１０へ送信する（Ｓ１８）。次いで、ＣＰＵ２１は、Ｓ１８で送信した画像データ（ＨＴＭＬデータ等）のパケット数に基づいて送信データ量を算出し（Ｓ２０）、算出した送信データ量をユーザＩＤと対応付けてＲＡＭ２３に記録する（Ｓ２２）。
【００５２】
図１２において、ゲームサーバ２０のＣＰＵ２１は、送信データ量の取得タイミングであると判定すると（Ｓ３０：ＹＥＳ）、ＲＡＭ２３から送信データ量のデータを取得する（読み出す）（Ｓ３２）。
Ｓ３０における取得タイミングの判定は、様々な観点から行うことができる。例えば、ゲームサーバ２０からユーザ端末１０へ画像データを送信した場合（例えば、処理要求に基づく処理を実行した場合）、取得タイミングに達したと判定してもよい。
あるいは、クエスト、抽選、および、対戦の、関連した一連の処理要求に対する処理の実行が完了した場合に、取得タイミングに達したと判定してもよい。図８に示した例では、画像Ｐ０のボタンｂ１（「クエスト」）を指定する操作が行われてクエストの処理が開始された後、画像Ｐ２のボタンｂ１２（「終了」）を指定する操作によってクエストの処理が終了した場合に、取得タイミングに達したと判定される。
また、アクセスにおける１つのセッションが終了した場合に、取得タイミングに達したと判定してもよい。
【００５３】
ゲームサーバ２０のＣＰＵ２１は、送信データ量のデータを取得すると、Ｓ３２で取得した送信データ量のデータが付与条件を満たすか否かについて判定する（Ｓ３４）。Ｓ３４において付与条件を満たすと判定した場合には（Ｓ３４：ＹＥＳ）、ＣＰＵ２１は、予め規定された、送信データ量と報酬の内容との関係に基づき、報酬の内容としてのユーザの獲得ポイントを決定する（Ｓ３６）。例えば、図８および図９に例示したように、ユーザの獲得ポイントが送信データ量に比例した値となるようにして報酬の内容が決定される。
次いで、ゲームサーバ２０のＣＰＵ２１は、報酬の内容として決定された獲得ポイントの量が付与対象のユーザの現在のポイントに加算されるようにして、当該ユーザのユーザデータテーブルを更新する。それによって、ユーザに報酬としてポイントが付与されたことになる（Ｓ３８）。なお、Ｓ３４において付与条件を満たさないと判定した場合には（Ｓ３４：ＮＯ）、ＣＰＵ２１は、Ｓ３６およびＳ３８の処理を実行しない。
最後にＣＰＵ２１は、ＲＡＭ２３の送信データ量の値をリセットする（つまり、ゼロにする）（Ｓ４０）。それによって、送信データ量の取得タイミングに達する度に、付与条件を満たすか否かについて適切に判定を行うことができる。
【００５４】
図１１および図１２に示したフローにおいて、付与条件の判定対象となる送信データ量は、取得タイミングによって変動する。例えば、関連した一連の処理要求に対する処理の実行が完了した場合に取得タイミングに達したと判定する場合には、例えばクエストや対戦等の一連の処理が終了したと判断されるまで、図１１のＳ２２で記録される送信データ量の値が蓄積され、蓄積された送信データ量が図１２のＳ３４における判定対象となる。また、アクセスにおける１つのセッションが終了した場合に取得タイミングに達したと判定する場合には、セッションが開始されてからそのセッションが終了するまでの間、図１１のＳ２２で記録される送信データ量の値が蓄積され、蓄積された送信データ量が図１２のＳ３４における判定対象となる。そのため、図１２のＳ３４における付与条件は、取得タイミングの設定に応じて適宜規定されていることが好ましい。
【００５５】
以上説明したように、本実施形態のゲームシステムでは、ユーザの操作に基づくゲームの処理要求に関連した送信データ量に関する情報が付与条件を満たしている場合、そのユーザに対して報酬を付与することが決定される。そのため、送信データ量が多くなるような操作を行うユーザに対して報酬が付与され、それによって当該ユーザが優遇されるような仕組みを構築することができる。この仕組みには以下の利点がある。すなわち、一般的に多くのデータをサーバからダウンロードするユーザ端末のユーザは、より頻繁にゲームを実行している傾向があり、ゲーム提供者にとって優良なユーザであるといえるが、この仕組みによれば、優良なユーザに対してデータの待ち時間に起因する不満を生じ難くさせることができ、優良なユーザが継続的にサービスを利用することが図られる。
【００５６】
（２）第２の実施形態
第１の実施形態では、ユーザ端末１０とゲームサーバ２０との間でＨＴＴＰに従った通信が行われ、ユーザ端末１０がゲームサーバ２０から取得するＨＴＭＬ文書を解釈することでゲーム画像を表示する、いわゆるブラウザ形式によって本発明が実現される場合について説明したが、この場合に限られない。ユーザ端末１０がダウンロードしたゲームプログラムを実行することでユーザ端末１０が主体的にゲームの処理を実行し、ユーザ端末１０とゲームサーバ２０の間の送受信処理を抑制した、いわゆるネイティブアプリケーション形式によって実現してもよい。ネイティブアプリケーション形式では、ウェブブラウザを利用せずにユーザ端末１０内で画像データを生成して表示する。
第２の実施形態では、第１の実施形態のゲームをネイティブアプリケーション形式によって実現する場合の一例について説明する。なお、本実施形態のハードウェア構成は、第１の実施形態と同じ構成でよい。本実施形態のネイティブアプリケーションの形式では、処理のほとんどをユーザ端末１０側で行うことを想定しているが、以下で説明しないゲームの処理の一部（例えば、ゲーム運営者がユーザにカードを付与するプレゼント処理等）については、ゲームサーバ２０側で処理を実行し、ゲームサーバ２０による処理結果をユーザ端末１０へ送信するように構成してもよい。
本実施形態では、ユーザ端末１０が情報処理装置の一例となる。
【００５７】
本実施形態では、ユーザ端末１０がユーザによる所定の操作に基づいて、ゲーム運営者のサーバからゲームプログラムを受信し、受信したゲームプログラムがストレージ１８に格納される。ユーザ端末１０によってゲームが起動されると、ユーザ端末１０とゲームサーバ２０との間で通信が確立されてログイン処理が行われ、ゲームサーバ２０からユーザ端末１０へデータテーブル群（ユーザデータテーブル、所持カードデータテーブル、および、所持アイテムデータテーブル）が送信される。ユーザ端末１０に送信されるデータテーブル群は、ユーザ端末１０のストレージ１８内に保持される。この場合、ストレージ１８内のデータテーブル群は、ログインの度に更新される。
【００５８】
本実施形態では、ゲームサーバ２０から受信したデータのデータ量（以下、「受信データ量」という。）に基づいて、ユーザ端末１０においてユーザに報酬を付与するか否か判定される。図１１および図１２に示したフローチャートにおいて「送信データ量」を「受信データ量」と読み替えることで、これらのフローチャートは本実施形態においても適用できる。
例えば、本実施形態において、ユーザ端末１０のＣＰＵ１１は、操作入力部１５を介して受け付けた処理要求に基づいて処理を実行し、処理に関連してゲームサーバ２０から受信したデータのデータ量に関する情報を、受信データ量としてＲＡＭ１３に記録する。なお、ネイティブアプリケーション形式においても、例えば対戦において新たな対戦相手のデータをゲームサーバ２０からダウンロードした後に実行する等、必要に応じてゲームサーバ２０からユーザ端末１０へ、処理要求に基づくデータの送信が随時発生する。ＣＰＵ１１は、受信データ量に関する情報の取得タイミングに達したと判定すると、ＲＡＭ１３から受信データ量に関する情報を取得し、取得した受信データ量に関する情報が付与条件を満たす場合に、ストレージ１８内のユーザデッキデータテーブルを更新することで、ユーザに報酬を付与する。
【００５９】
所持カードデータテーブルおよび所持アイテムデータテーブルがユーザ端末１０において改竄されることを防止するため、ユーザ端末１０による所定の処理が終了する度、あるいは、ゲームからログアウトする時点で、ユーザ端末１０内の所持カードデータテーブルおよび所持アイテムデータテーブルがゲームサーバ２０へ送信される。ゲームサーバ２０では、受信した所持カードデータテーブルおよび所持アイテムデータテーブルを、ストレージ２５内の所持カードデータテーブルおよび所持アイテムデータテーブルと比較し、データの改竄が行われていないか確認した後に、ストレージ２５内の所持カードデータテーブルおよび所持アイテムデータテーブルを受信したものに置き換える。
【００６０】
ユーザデータテーブル、所持カードデータテーブル、および、所持アイテムデータテーブルはゲームサーバ２０において保持される場合に限られない。ネイティブアプリケーション形式のゲームでは、各データテーブルの保持分担については適宜設定することが可能であって、ユーザ端末１０、ゲームサーバ２０、または、ユーザ端末１０若しくはゲームサーバ２０からアクセス可能な他の装置の少なくともいずれかに各データテーブルが保持されるようにすればよく、特定の保持態様に限定されるものではない。
【００６１】
（３）変形例
以下、上述した各実施形態に共通の変形例について説明する。以下では、第１の実施形態の変形例として説明するが、第２の実施形態についても同様に適用できる。
【００６２】
（３−１）変形例１
上述した第１の実施形態では、処理要求に関連した送信データ量に関する情報を取得するタイミングは、関連した一連の処理要求に対する処理を実行する期間ごとのタイミングや、アクセスにおける１つのセッションごとのタイミング等、比較的短い間隔に設定される場合について説明したが、その場合に限られない。本変形例では、ユーザごとに送信データ量に関する情報を蓄積しておき、累計の送信データ量に関する情報が付与条件を満たした時点で、ユーザに報酬を付与する。その場合、累計の送信データ量に関する情報をストレージ２５に記録しておき、例えば定期的に、あるいはユーザのログインの度に、ストレージ２５から読み出されて、報酬の付与条件の判定に使用される。なお、累計の送信データ量に関する情報は、累計の送信データ量自体であってもよいし、累計の送信データ量の推定値であってもよいし、累計の送信データ量の指標値であってもよい。
【００６３】
図１３は、本変形例のユーザデータテーブルの構成例を示す図である。図１３に示すユーザデータテーブルは、図５に示したものと比較して、累計の送信データ量に関する情報として「累計の送信データ量」の項目が設けられた点で異なる。
本変形例の機能ブロック図では、図１０に示したように、記憶手段５７が設けられる。記憶手段５７は、取得手段５３によって取得された送信データ量に関する情報を用いて、累計のデータ量に関する情報をストレージ２５（記憶装置の一例）のユーザデータテーブルに記憶させる機能を備える。また、本変形例では、判定手段５４における付与条件は、ストレージ２５のユーザデータテーブルが記憶する累計のデータ量が所定値に達したことである。
記憶手段５７の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、処理要求に基づく処理結果を含む画像データを送信した後、当該画像データの送信データ量を算出し、算出した送信データ量の値によって、ユーザデータテーブルの累計の送信データ量の値を逐次積算する。
【００６４】
図１４に、本変形例においてユーザ端末に表示される画像の一例を示す。本変形例では、ユーザがゲームにログインしたときに、ユーザの累計の送信データ量が付与条件を満たしている場合には、画像Ｐ１０がユーザ端末１０に表示され、それによってユーザに報酬（プレゼント）が付与されることがユーザに通知される。画像Ｐ１０には、ボタンｂ５（「メインメニュー」）が含まれており、このボタンｂ５を指定することによって、Ｐ１１に示すように画像が変化する。画像Ｐ１１は、メインメニューであり、報酬としてのプレゼントがユーザに付与するためのボタンｂ５１が含まれる。画像Ｐ１１においてボタンｂ５１を指定すると、Ｐ１２に示すように画像が変化する。画像Ｐ１２には、送信データ量およびプレゼントの内容（ここでは、１００００ｐｔ）に関するデータが含まれる。画像１２においてボタンｂ５２（「受け取る」）を指定することによって、ユーザにプレゼントが付与される。
【００６５】
本変形例の送信データ量の記録処理と報酬付与処理について説明する。
本変形例の送信データ量の記録処理は、図１１に示したものと概ね同じである。但し、本変形例では、Ｓ２２において、算出した送信データ量の値がユーザデータテーブルに記録されている累計の送信データ量の値に加算されるようにして、送信データ量をユーザデータテーブルに記録する。
一方、本変形例の報酬付与処理のフローチャートを図１５に示す。
図１５に示すフローチャートについて、図１２に示したフローチャートと同様の処理について同一の符号を付して説明を簡略化して説明する。
図１５において、ゲームサーバ２０のＣＰＵ２１は、ユーザがゲームにログインした場合（Ｓ５０：ＹＥＳ）、ユーザデータテーブルから累計の送信データ量のデータを取得する（読み出す）（Ｓ５２）。
ゲームサーバ２０のＣＰＵ２１は、累計の送信データ量のデータを取得すると、Ｓ５２で取得した累計の送信データ量のデータが付与条件を満たすか否かについて判定する（Ｓ５４）。Ｓ５４において付与条件を満たすと判定した場合には（Ｓ５４：ＹＥＳ）、ＣＰＵ２１は、予め規定された、累計の送信データ量に関する情報と報酬の内容との関係に基づき、報酬の内容としてのユーザの獲得ポイントを決定する（Ｓ５６）。
次いで、ゲームサーバ２０のＣＰＵ２１は、報酬の内容として決定された獲得ポイントの量が付与対象のユーザの現在のポイントに加算されるようにして、当該ユーザのユーザデータテーブルを更新する。それによって、ユーザに報酬としてポイントが付与されたことになる（Ｓ５８）。次にＣＰＵ２１は、ユーザデータテーブルの累計の送信データ量の値をリセットする（つまり、ゼロにする）（Ｓ６０）。それによって、報酬をユーザに付与した後、次にユーザに報酬を付与するための基礎となる累計の送信データ量を適切に判定することができる。
Ｓ５４において付与条件を満たさないと判定した場合には（Ｓ３４：ＮＯ）、ＣＰＵ２１は、Ｓ５６〜Ｓ６０の処理を実行しない。
【００６６】
なお、報酬は、ポイントに限られるものではない。報酬は、例えば、カード、アイテムなどのゲーム内で用いられるオブジェクトであってもよい。図１６に、報酬がポイント以外である場合に参照される報酬データテーブルの一例を示す。この報酬データテーブルでは、送信データ量の条件と、ユーザに付与される報酬としてのアイテムとが定義されている。より具体的には、報酬データテーブルには、報酬ＩＤごとに、送信データ量の条件と、アイテムＩＤと、アイテム名とが対応付けられて記録されている。ここで、「回復薬」というアイテムは、クエスト処理を有利に進行させるためのアイテムであり、「抽選券」というアイテムは、抽選を所定回数実行するためのアイテムである。
また、報酬は、ゲーム内で用いられるポイント、オブジェクトに限られるものではなく、ゲーム内での利用に限られない電子的な報酬（例えば、所定量のサービスポイントや電子マネー等）であってもよい。さらに、ユーザに付与される実体のある報酬（例えば、図１６に例示するギフトカードや時計等）であってもよい。そのため、報酬の内容がポイント以外の場合であっても、送信データ量に応じた報酬の内容を設定したデータテーブルを参照することで、報酬の内容を決定することができる。
なお、報酬の内容がカード、アイテムなどのゲーム内で用いられるオブジェクトの場合は、付与対象のユーザに対応する所持カードデータベース、所持アイテムデータベースに報酬であるカード、アイテムを追加することになる。一方、報酬の内容が、ゲーム内での利用に限られない電子的な報酬や実体のある報酬の場合は、それぞれの報酬を管理する別のサービスアプリケーションへ、付与対象となるアイテムのアイテムＩＤをユーザＩＤと対応付けて通知する。
【００６７】
本変形例によれば、累計の送信データ量に基づいて報酬がユーザに付与されるため、あまり頻繁にゲームにアクセスしないユーザであっても、少しずつゲームを実行する（つまり、送信データ量を少しずつ積み上げる）ことで、時間が掛かっても報酬を得ることができる。そのため、頻繁にゲームを実行するいわゆる優良ユーザに限られず、より多くのユーザにゲームを継続する動機付けを与えることができる。
【００６８】
（３−２）変形例２
本変形例では、ゲーム上の処理要求の種別ごとに送信データ量を調整するための調整方法が対応付けられる。そして、判定手段５４は、ゲーム上の処理要求に関連した送信データ量を、当該ゲーム上の処理要求に対応付けられた調整方法によって調整し、当該調整後のデータ量に基づいて判定する。
上述した実施形態の例では、ゲーム上の処理要求の種別は、クエスト要求、抽選要求、および、対戦要求などの処理要求の種別である。処理要求の種別ごとに送信データ量を調整することで、ユーザが実行するゲーム上の処理の内容によって判定対象の送信データ量が変動するため、例えば特定の処理を利用しているユーザを優遇する等、ゲーム運営者の方針に従って柔軟にユーザに報酬を付与することができるようになる。
本変形例における判定手段５４の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、処理要求に基づく処理を実行してユーザ端末１０へ画像データを送信する度に、ＲＡＭ２３またはストレージ２５のユーザデータテーブルに、クエスト要求、抽選要求、および、対戦要求の各種別の処理要求ごとに区別して、送信データ量または累計の送信データ量を記録する。そして、ＣＰＵ２１は、例えば、送信データ量または累計の送信データ量を取得した後、取得した送信データ量または累計の送信データ量を処理要求の種別ごとの重み付け係数を乗じた後に加算し、その加算した値を、付与条件を満たすか否かについての判定対象とする。
【００６９】
以下に、送信データ量の調整方法の具体例を示す。
具体例１は、ゲーム上の処理要求の種別ごとに設定されている重み付け係数を用いて送信データ量を調整する方法の一例であり、具体例２は、ゲーム上の処理要求の種別ごとに設定されている数式の一例である。その他、調整前の送信データ量の範囲ごとに調整後の送信データ量の値が記述されるデータテーブルに基づいて、記録された送信データ量を調整してもよい。
【００７０】
［処理要求の種別と送信データ量の調整方法との関係の具体例１］
・処理要求の種別がクエスト要求である場合…記録された送信データ量（α１）×１．０
・処理要求の種別が抽選要求である場合    …記録された送信データ量（α２）×１．２
・処理要求の種別が対戦要求である場合    …記録された送信データ量（α３）×０．８
この場合、判定対象となる送信データ量は、α１×１．０＋α２×１．２＋α３×０．８となる。
【００７１】
［処理要求の種別と送信データ量の調整方法との関係の具体例２］
・処理要求の種別がクエスト要求である場合…変換式１を適用
・処理要求の種別が抽選要求である場合    …変換式２を適用
・処理要求の種別が対戦要求である場合    …変換式３を適用
なお、変換式１〜３は、記録された送信データ量を異なる量に変換するための関数を規定する式であり、例えば、記録された送信データ量をαとしたときに、α３／２，α２等の平易な式でよい。この場合も、判定対象となる送信データ量は、種別ごとの調整後のデータ量が加算されたものとなる。
【００７２】
また、変換式１〜３は、すべてを採用する必要はない。例えば、処理要求の種別がクエスト要求である場合には変換式１を採用して送信データ量を調整し、処理要求の種別が、抽選要求、対戦要求の場合は、記録された送信データ量を調整しなくてもよい。さらに、例えば、期間限定で、処理要求の種別がクエスト要求の場合の送信データ量のみを累計する場合、処理要求の種別がクエスト要求である場合には変換式１を採用して送信データ量を調整し、処理要求の種別が、抽選要求、対戦要求の場合は、送信データ量を加算しないように、変換式２と変換式３は記録された送信データ量に「０」を乗算する式としてもよい。
さらに、変換式により、記録された送信データ量から処理要求の種別の要求がなされた回数に変換してもよい。その場合、所定の回数に達した場合に、報酬を付与することになる。所定の種別の要求について発生する送信データ量は一定でないことがあり、その場合、送信データ量ではなく、回数によりカウントした方が公平な報酬付与につながることがあるためである。例えば、処理要求の種別ごとの送信データ量をＲＡＭ２３に記録しておき、以下に例示するように、種別ごとの送信データ量に基づいて種別ごとの処理要求の回数を算出する（当該回数に変換する）。
［送信データ量（α）から回数に変換する例］
・送信データ量がＴ１[MB]以上Ｔ２[MB]未満である場合…α／２[回]に変換
・送信データ量がＴ２[MB]以上Ｔ３[MB]未満である場合…α／３[回]に変換
・送信データ量がＴ３[MB]以上である場合…α／４[回]に変換
【００７３】
本変形例において調整方法は特に限定されるものではないが、上述したように、ゲーム上の処理要求の種別ごとに設定されている重み付け係数を用いて送信データ量を調整する方法、ゲーム上の処理要求の種別ごとに設定されている数式若しくはデータテーブルを用いて送信データ量を調整する方法を採ることで、データ量の調整に要する演算負荷が低減される。
【００７４】
（３−３）変形例３
上述した第１の実施形態では、変形例２で述べた送信データ量の調整方法が、ゲーム上の処理要求を受信した時間帯または期間によって変更される。
本変形例の機能ブロック図では、図１０に示したように、変更手段５８が設けられる。変更手段５８は、ゲーム上の処理要求を受信した時間帯または期間に基づいて、少なくともいずれかのゲーム上の処理要求の種別に対応する調整方法を変更する機能を備える。これによって、多数のユーザからの処理要求に基づいてゲームを実行する場合に、データの送信負荷を分散させることができる。例えば、送信データ量の調整方法を重み付け係数を用いて行う場合、例えば夜中の時間帯等、多くのユーザがアクセスしない時間帯における送信データ量に対する重み付け係数を増やすことで、そのような時間帯にアクセスするユーザが増加することから、ゲームサーバ２０のユーザ端末１０への送信負荷が分散することが図られる。また、ゲーム上の処理要求を受信した期間に基づいて送信データ量を調整することで、ゲーム運営者が例えば特定の期間を、報酬が得られやすいキャンペーン期間に設定することができるようになる。
以下に、時間帯および期間によって送信データ量の調整方法を変更する場合の具体例を示す。なお、処理要求が複数受け付けられた場合には、受け付けた時刻の平均時刻を基準としてもよいし、最初に受け付けた時刻を基準としてもよい。
【００７５】
［時間帯に応じた送信データ量の調整方法の具体例１］
・処理要求を受け付けた時刻が６〜１２時の場合  …記録された送信データ量×１．２
・処理要求を受け付けた時刻が１２〜２４時の場合…記録された送信データ量×１．０
・処理要求を受け付けた時刻が０〜６時の場合    …記録された送信データ量×２．０
【００７６】
［期間に応じた送信データ量の調整方法の具体例２］
・処理要求を受け付けた期間がイベント期間内の場合…記録された送信データ量×２．０
・処理要求を受け付けた期間がイベント期間外の場合…記録された送信データ量×１．０
【００７７】
本変形例において変更手段５８の機能は、以下のようにして実現される。例えば、ゲームサーバ２０のＣＰＵ２１にはタイマが内蔵しており、ＣＰＵ２１は、処理要求を受け付けた時刻と、当該処理要求に基づく送信データ量とを対応付けて、ＲＡＭ２３またはストレージ２５のユーザデータテーブルに記録する。そして、ＣＰＵ２１は、例えば、送信データ量または累計の送信データ量を取得した後、記録された時刻に基づいて適用する重み付け係数を変更し、それぞれ時間帯または期間ごとの重み付け係数を乗じた後に加算し、その加算した値を、付与条件を満たすか否かについての判定対象とする。
【００７８】
（３−４）変形例４
上述した第１の実施形態では、送信データ量に関する情報について付与条件を満たしたすべてのユーザに対して報酬を付与する場合について説明したが、付与条件を満たしたユーザの中から、より早く付与条件を満たした所定数のユーザに対して優先的に報酬を付与してもよい。
すなわち、本変形例では、判定手段５４は、報酬を付与するための付与条件を満たしているか否かをユーザごとに判定する。また、決定手段５５は、付与条件を満たした順に所定数のユーザに対して付与する報酬の内容を、付与条件を満たしていると判定され、かつ当該所定数のユーザ以外のユーザに対して付与する報酬の内容とは異ならせる。
【００７９】
なお、報酬の内容の異ならせ方は、適宜設定してもよい。例えば、付与条件を満たした順に所定数のユーザに対して実質的に報酬を付与し、所定数のユーザ以外のユーザに対して実質的に報酬を付与しない（報酬の内容がない）ようにしてもよいし、前者のユーザに対して相対的に多くの報酬を付与し、後者のユーザに対して相対的に少ない報酬を付与してもよい。例えば、図８および図９に示した例では、送信データ量をα [MB]とし、報酬としての獲得ポイントをβ［pt］としたときに、β＝１０×αの関係に基づいて報酬の内容が決定される場合について説明したが、早く付与条件を満たした１００人に対してβ＝１０×αの関係に基づいて報酬の内容（ポイント）を決定し、その１００人よりも遅く付与条件を満たしたユーザに対してβ＝５×αの関係に基づいて報酬の内容（ポイント）を決定し、若しくは報酬の内容をゼロ（０ｐｔ）としてもよい。
このように、付与条件を満たしたユーザに対して、付与条件を満たしたタイミングに基づいて、付与する報酬に差を付けることによって、ユーザ間で競争する仕組みを構築することができ、ゲームの実行の促進が図られる。
【００８０】
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、例えば、付与条件を満たしたか否かを示すフラグ（１：付与条件を満たした、０：付与条件を満たしていない）をユーザＩＤに対応付けて、ＲＡＭ２３またはユーザデータテーブルに記録する。また、ＣＰＵ２１は、フラグが「１」であるユーザＩＤの数を逐次計数し、その数が所定数に達した場合に、フラグが「１」であるユーザＩＤに対応するユーザを、第１の報酬を付与すべき所定数のユーザとして決定する。いったん所定数のユーザが確定した後に付与条件を満たしたユーザには、第１の報酬よりも少ない第２の報酬を付与することを決定する。
【００８１】
（４）ゲーム以外のアプリケーションへの適用について
上述した実施形態および変形例では、本発明がゲームに適用される場合について説明したが、他のサービスに適用してもよい。例えばウェブを利用したコンテンツの視聴サービスが提供される場合、その視聴サービスを提供するためにサーバからユーザ端末へ送信されるコンテンツのデータのデータ量（送信データ量）に応じてユーザに報酬を付与することができる。例えば、映像等の大量のデータを頻繁に視聴しているユーザは上記視聴サービスにおいて優良ユーザであるが、そのような優良ユーザに対して送信データ量に応じた報酬を付与することで、優良なユーザに対してデータの待ち時間に起因する不満を生じ難くさせることができ、優良なユーザが継続的にサービスを利用することが図られる。
報酬の内容として、例えば、視聴サービスが提供するコンテンツをダウンロードするために利用できるポイント等を採用してもよいし、実体のあるプレゼント（ギフトカード、時計等）を採用してもよい。
上述した例示以外の他のサービスについても適宜適用可能である。
【００８２】
以上、本発明の実施形態、変形例について詳細に説明したが、本発明は上記実施形態等に限定されない。また、実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。上記実施形態および各変形例に記載された技術的事項は適宜組合せて適用してもよい。
なお、要求の受付方法については上述した場合に限られない。例えば、要求の受付方法は、加速度センサを備えたユーザ端末を振ることによる指示入力、あるいはジェスチャによる指示入力（ジェスチャ入力）によって受け付ける方法であってもよい。ジェスチャ入力では、撮像機能を備えたユーザ端末に対する所定のジェスチャを行うことでユーザ端末がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。また、音声認識プログラムを実行可能なユーザ端末の場合には、要求の受付方法は、所定の音声による指示入力によって受け付ける方法であってもよい。
【００８３】
上述した実施形態では、ユーザの操作に基づく処理要求の例として、ユーザのボタンの指定操作に応じて直接的にゲームの処理要求（クエスト要求等）が行われる場合について説明したが、そのような場合に限られない。
上記実施形態において、例えば、ユーザの操作によってクエスト要求の予約がなされ、当該予約によって自動探索が実行される場合、そのような予約の操作は、ユーザの操作に基づくクエスト要求に含まれる。また、ネイティブアプリケーション形式で、ゲーム運営者のサーバからゲームプログラムを更新することをユーザの操作によって自動設定されている場合には、ユーザ操作を契機としないでダウンロードすることをユーザ端末が要求する場合も、ユーザの操作に基づく処理要求に含まれる。
【００８４】
［発明のまとめ］
以上の記載から本発明は例えば以下のように把握される。
【００８５】
本発明の一態様は、ユーザの操作に基づくサービスの処理要求を送信または受信可能な情報処理装置（１０または２０）であって、
前記サービスの処理要求に関連して送信または受信されるデータのデータ量に関する情報と、当該サービスの処理要求の元となる操作をなしたユーザを識別するユーザ識別情報とを取得する取得手段（５３）と、
前記取得手段（５３）によって取得された前記データ量に関する情報に基づいて、前記取得手段（５３）によって取得された前記ユーザ識別情報により識別されるユーザに付与すべき報酬の内容を決定する決定手段（５５）と、
を備えた、情報処理装置である。
【００８６】
「情報処理装置」は、ネットワークに接続可能な装置であれば如何なる装置であってもよい。また、情報処理装置は、サービスの処理要求を送信または受信する装置であってもよいし、サービスの処理要求に関連してデータを受信または送信する装置であってもよい。すなわち、情報処理装置は、サーバクライアントシステムにおいてサーバであってもよいしクライアントであってもよい。
「サービス」は、ウェブサービス等、ネットワークを介してユーザに提供されるサービスであれば如何なるサービスであってもよい。
「ユーザの操作に基づくサービスの処理要求」とは、ユーザの操作に応じた直接的なサービスの処理要求に限られず、ユーザの操作に対して間接的になされたサービスの処理要求であってもよい。例えば、ユーザの操作によって処理要求の予約がなされ、当該予約によってサービスの処理要求が自動的になされた場合も「ユーザの操作に基づくサービスの処理要求」に含まれる。また、ユーザの１回の操作によって自動的にサービスの処理要求が送信される設定となっている場合、その後に自動的に行われる１回または複数回のサービスの処理要求についても「ユーザの操作に基づくサービスの処理要求」に含まれる。
「ユーザ識別情報」は、ユーザを識別または特定する情報であり、例えばユーザＩＤ等であってもよい。
「データ量に関する情報」は、送信または受信したデータ量自体の情報（例えば、パケット数）のほか、送信または受信した処理要求に基づくデータ量の推定値や、データ量の指標値（データ量のレベル等（例えば、多、中、少））等であってもよい。
「報酬の内容」は、ユーザに電子的に付与される報酬（例えば、所定量のサービスポイントや電子マネー等）であってもよいし、ユーザに付与される実体のある報酬（例えば、ギフトカードや時計等）であってもよい。また、報酬の内容が空の場合（実質的に報酬が付与されない場合）があってもよい。
【００８７】
上記情報処理装置では、ユーザの操作に基づくサービスの処理要求に関連して送信または受信されるデータのデータ量に関する情報に基づいて、そのユーザに対して付与すべき報酬の内容が決定される。そのため、送信または受信されるデータのデータ量が多くなるような操作を行うユーザに対して報酬が付与され、それによって当該ユーザが優遇されるような仕組みを構築することができる。この仕組みには以下の利点がある。すなわち、一般的に多くのデータをサーバからダウンロードするユーザ端末のユーザは、より頻繁にサービスを利用している傾向があり、サービス提供者にとって優良なユーザであるといえるが、この仕組みによれば、優良なユーザに対してデータの待ち時間に起因する不満を生じ難くさせることができ、優良なユーザが継続的にサービスを利用することが図られる。
【００８８】
上記情報処理装置は、前記取得手段（５３）によって取得された前記データ量に関する情報を用いて、前記取得手段（５３）によって取得された前記ユーザ識別情報により識別されるユーザに報酬を付与するための付与条件を満たしているか否かを判定する判定手段（５４）、をさらに備え、
前記決定手段（５５）は、前記判定手段（５４）による判定の結果、前記付与条件を満たしていると判定された場合に、前記ユーザに付与する報酬の内容を決定してもよい。
付与条件に基づいて報酬の内容を決定することで、報酬の内容を画一的ではなく柔軟に設定できるようになる。
【００８９】
上記情報処理装置は、前記取得手段（５３）によって取得された前記データ量に関する情報を用いて、累計のデータ量に関する情報を記憶装置（２５）に記憶させる記憶手段（５７）、をさらに備え、
前記付与条件は、前記記憶装置（２５）が記憶する累計のデータ量が所定値に達したことであってもよい。
このような構成によれば、累計のデータ量に基づいて報酬がユーザに付与されるため、あまり頻繁にサービスを利用しないユーザであっても、少しずつサービスを利用する（つまり、データ量を少しずつ積み上げる）ことで、時間が掛かっても報酬を得ることができる。そのため、頻繁にサービスを利用するいわゆる優良ユーザに限られず、より多くのユーザにサービスの利用を継続する動機付けを与えることができる。
【００９０】
前記サービスの処理要求の種別ごとに前記データ量を調整するための調整方法が対応付けられ、
前記判定手段（５４）は、前記サービスの処理要求に関連して送信または受信したデータのデータ量を、当該サービスの処理要求に対応付けられた調整方法によって調整し、当該調整後のデータ量に基づいて判定してもよい。
「サービスの処理要求の種別」とは、要求対象となるサービスの処理の内容に対応した情報であればよく、適宜設定できる。例えばサービスがゲームに関連しており、ゲームに複数のゲーム要素やプレイモード、あるいはミニゲームが設けられている場合には、それらの各々に対応して種別が設定されていてもよい。また、ゲームに期間限定のイベントが設けられている場合には、その期間に限定されない通常のゲームとイベント内のゲームに対応してそれぞれ種別が設定されていてもよい。種別ごとにデータ量を調整することで、サービスの処理の内容によって判定対象のデータ量が変動するため、例えば特定のサービスを利用しているユーザを優遇する等、サービス提供者の方針に従って柔軟にユーザに報酬を付与することができる。
【００９１】
前記調整方法は、前記サービスの処理要求の種別ごとに設定されている重み付け係数を用いて前記データ量を調整する方法、または前記サービスの処理要求の種別ごとに設定されている数式若しくはデータテーブルを用いて前記データ量を調整する方法であってもよい。このような方法でデータ量を調整することで、データ量の調整に要する演算負荷が低減される。
【００９２】
前記サービスの処理要求を送信または受信した時間帯または期間に基づいて、少なくともいずれかのサービスの処理要求の種別に対応する調整方法を変更する変更手段（５８）、をさらに備えてもよい。
サービスの処理要求を送信または受信した時間帯に基づいて上記データ量を調整することで、多数のユーザに対してサービスを提供する場合に、データの送信負荷を分散させることができる。例えば、例えば夜中の時間帯等、多くのユーザがアクセスしない時間帯におけるデータ量に対する重み付け係数を増やすことで、そのような時間帯にアクセスするユーザが増加することから、ユーザへの送信負荷が分散することが図られる。
また、サービスの処理要求を送信または受信した期間に基づいて上記データ量を調整することで、サービス提供者が例えば特定の期間を、報酬が得られやすいキャンペーン期間に設定することができるようになる。
【００９３】
前記判定手段（５４）は、前記報酬を付与するための付与条件を満たしているか否かをユーザごとに判定し、
前記決定手段（５５）は、前記付与条件を満たした順に所定数のユーザに対して付与する報酬の内容を、前記付与条件を満たしていると判定され、かつ当該所定数のユーザ以外のユーザに対して付与する報酬の内容とは異ならせてもよい。
報酬の内容の異ならせ方は、適宜設定してもよい。例えば、付与条件を満たした順に所定数のユーザに対して実質的に報酬を付与し、所定数のユーザ以外のユーザに対して実質的に報酬を付与しない（報酬の内容がない）ようにしてもよいし、前者のユーザに対して相対的に多くの報酬を付与し、後者のユーザに対して相対的に少ない報酬を付与してもよい。このように、付与条件を満たしたユーザに対して、付与条件を満たしたタイミングに基づいて、付与する報酬に差を付けることによってユーザ間で競争する仕組みを構築することができ、サービスの利用促進が図られる。
【００９４】
前記報酬は、前記サービス内で利用可能な報酬であってもよい。この場合、報酬が付与されたユーザは、直ちにサービス内で報酬を利用することができるため、積極的に報酬を得ようとする動機付けが強くなる。
【００９５】
本発明の別の態様は、ユーザの操作に基づくサービスの処理要求を送信可能なユーザ端末（１０）と、前記サービスの処理要求を受信可能なサーバ（２０）と、を含む情報処理システム（１）であって、
前記サービスの処理要求に関連して送信または受信されるデータのデータ量に関する情報と、当該サービスの処理要求の元となる操作をなしたユーザを識別するユーザ識別情報とを取得する取得手段（５３）、
前記取得手段（５３）によって取得された前記データ量に関する情報を用いて、前記取得手段（５３）によって取得された前記ユーザ識別情報により識別されるユーザに付与すべき報酬の内容を決定する決定手段（５５）、
の各手段を、前記ユーザ端末（１０）または前記サーバ（２０）の少なくともいずれか一方が備えた
情報処理システムである。
【００９６】
本発明の別の態様は、コンピュータを、
ユーザの操作に基づくサービスの処理要求に関連して送信または受信されるデータのデータ量に関する情報と、当該サービスの処理要求の元となる操作をなしたユーザを識別するユーザ識別情報とを取得する取得手段（５３）、
前記取得手段（５３）によって取得された前記データ量に関する情報を用いて、前記取得手段（５３）によって取得された前記ユーザ識別情報により識別されるユーザに付与すべき報酬の内容を決定する決定手段（５５）、
として機能させるためのプログラムである。
【００９７】
本発明の別の態様は、上記プログラムを格納する、光ディスク、磁気ディスク等の、コンピュータが読み取り可能な記憶媒体であってもよい。
【００９８】
なお、上記では、本発明の理解を容易にするため、適宜図面に記載された符号を括弧書きで記載しているが、これにより本発明に係る情報処理装置等が図示の態様に限定されるものではない。
【符号の説明】
【００９９】
１…ゲームシステム
１０…ユーザ端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１５…操作入力部
１６…表示部
１７…通信インタフェース部
１８…ストレージ
１９…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…通信インタフェース部
２５…ストレージ
２６…バス
５１…受付手段
５２…ゲーム実行手段
５３…取得手段
５４…判定手段
５５…決定手段
５６…付与手段
５７…記憶手段
５８…変更手段
７０…データテーブル群
【図１】
2015133041.tif 000003
【図２】
2015133041.tif 000004
【図３】
2015133041.tif 000005
【図４】
2015133041.tif 000006
【図５】
2015133041.tif 000007
【図６】
2015133041.tif 000008
【図７】
2015133041.tif 000009
【図８】
2015133041.tif 000010
【図９】
2015133041.tif 000011
【図１０】
2015133041.tif 000012
【図１１】
2015133041.tif 000013
【図１２】
2015133041.tif 000014
【図１３】
2015133041.tif 000015
【図１４】
2015133041.tif 000016
【図１５】
2015133041.tif 000017
【図１６】
2015133041.tif 000018