(57)【要約】【課題】より短期間で新たなゲームコンテンツ等を配信してユーザの継続的なプレイを維持する課金プログラム等を提供することにある。【解決手段】楽曲が再生されるリズムゲーム（音楽ゲーム）において、ユーザがプレイする楽曲の種別に応じて、ゲームの運営者への課金額を算定する課金レートを変更する。ユーザが未プレイの追加楽曲（エキストラ）をプレイした場合の課金レートを、既存楽曲等をプレイした場合での課金レートよりも高く設定する。【選択図】図２２
2019080741.tif 000002
【特許請求の範囲】
【請求項１】
対価を支払ったユーザにゲームのプレイが許可されるゲーム装置と通信ネットワークにより接続されるサーバ装置に、前記ゲームの運営者に対する課金額を前記対価に基づいて算定させるための課金プログラムであって、
前記サーバ装置に、
前記プレイが許可されたゲームのコンテンツが、第一状態の所定のコンテンツを第二状態に設定変更するコンテンツであるか否かに関する情報を含むプレイ情報を、該ゲーム装置から取得する取得機能、
前記設定変更するコンテンツである場合、第１課金レートを用いて前記プレイの前記課金額を算定し、前記設定変更するコンテンツでない場合、前記第１課金レートよりも低いレートの第２課金レートを用いて前記プレイの前記課金額を算定する算定機能、
を実現させるための課金プログラム。
【請求項２】
前記サーバ装置に、さらに、
前記ユーザの識別情報を前記ゲーム装置から取得し、記憶部に記憶されている該ユーザの前記ゲームのプレイ履歴を含む履歴情報に基づいて、前記ゲームの複数のコンテンツにおける第一状態のコンテンツの有無を判定する判定機能、
前記第一状態のコンテンツがあると判定された場合、前記設定変更するコンテンツを前記ユーザに選択可能にさせる情報をゲーム装置に送信する許可機能、
を実現させるための請求項１に記載の課金プログラム。
【請求項３】
前記ゲームは、楽曲を再生するとともに操作入力を促す指示標識を前記ゲーム装置の表示部に表示するリズムゲームであり、
前記コンテンツは、前記楽曲である請求項１又は２に記載の課金プログラム。
【請求項４】
前記第一状態のコンテンツは、前記ゲーム装置でプレイ可能に新規に追加され、且つ、前記設定変更するコンテンツのプレイによって第二状態に設定変更される前の状態のコンテンツである請求項１〜３のいずれかに記載の課金プログラム。
【請求項５】
前記取得機能では、前記ゲーム装置から、前記ゲーム装置自体の識別情報又は／及び前記運営者の識別情報も取得する機能、
前記算定機能では、前記ゲーム装置自体の識別情報又は前記運営者の識別情報に基づいて、前記運営者毎に前記課金額を算定する機能、
を実現させるための請求項１〜４のいずれかに記載の課金プログラム。
【請求項６】
通信ネットワークによりサーバ装置に接続され、対価を支払ったユーザにゲームのプレイを許可するゲーム装置のゲームプログラムであって、
前記ゲーム装置に、
前記ゲームの運営者に対する課金額を前記対価に基づいて算定するサーバ装置であって、前記プレイが許可されたゲームのコンテンツが第一状態の所定のコンテンツを第二状態に設定変更するコンテンツである場合、第１課金レートを用いて前記プレイの前記課金額を算定し、前記許可されたゲームのコンテンツが前記設定変更するコンテンツでない場合、前記第１課金レートよりも低いレートの第２課金レートを用いて前記プレイの前記課金額を算定するサーバ装置に、前記プレイが許可されたゲームのコンテンツが、第一状態の所定のコンテンツを第二状態に設定変更するコンテンツであるか否かに関する情報を含むプレイ情報を送信する送信機能、
を実現させるためのゲームプログラム。
【請求項７】
対価を支払ったユーザにゲームのプレイが許可されるゲーム装置と、前記ゲーム装置と通信ネットワークにより接続されるサーバ装置とを備え、前記ゲームの運営者に対する課金額を前記対価に基づいて算定するゲームシステムであって、
記憶部に記憶されている前記ユーザの前記ゲームのプレイ履歴を含む履歴情報に基づいて、前記ゲームの複数のコンテンツにおける第一状態のコンテンツの有無を判定する判定手段、
前記第一状態のコンテンツがあると判定された場合、第一状態のコンテンツを第二状態に設定変更するコンテンツを前記ユーザに選択可能にさせる許可手段、
前記ゲームのプレイ結果に応じて前記履歴情報を更新する更新手段、
前記プレイが許可されたゲームのコンテンツが、前記設定変更するコンテンツである場合、第１課金レートを用いて前記プレイの前記課金額を算定し、前記設定変更するコンテンツでない場合、前記第１課金レートよりも低いレートの第２課金レートを用いて前記プレイの前記課金額を算定する算定手段、
を含む、ゲームシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態の少なくとも１つは、ゲームの運営者に対する課金額をサーバ装置に算定させるための課金プログラム等に関する。
【背景技術】
【０００２】
店舗などの施設に設置される業務用のゲーム装置（アーケードゲーム機）では、例えば、コイン（硬貨等）や電子マネーによる対価の支払いに応じてユーザにプレイが許可される。
【０００３】
近年の業務用のゲーム装置では、通信ネットワークを介してコンテンツ配信等のためにサーバ装置が接続された構成もある。上記サーバ装置は、ゲームメーカによって管理・運営され、新たなゲームコンテンツ等をゲーム装置に配信する。すなわち、業務用のゲーム装置に対しても、家庭用のオンラインゲームのように、定期的なアップデート、新たなゲームモードや新規キャラクター・アイテムの追加等が行われる。
【０００４】
上述の業務用のゲーム装置とサーバ装置とが接続された構成では、例えば、施設の運営者（オペレータ）と、サーバ装置を管理・運営するゲームメーカーとで、ユーザが支払った対価が所定比率でシェアされる。この場合、サーバ装置が、課金サーバとして機能し、上記対価に基づいて算定した課金額を運営者に対して課金する。
【０００５】
上述の課金額は、上記対価に対して固定のレートで算定される場合や、課金開始日からの経過期間に応じて異なるレートを用いて算定される場合もある（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１０−２４２２１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上述の運営者に対して課金を行う構成では、配信される新たなゲームのコンテンツ等の制作コストをゲームメーカが回収するのに長い期間を要することが課題である。そのため、短期間（短期サイクル）で新たなゲームコンテンツ等を配信していくことが難しい。ゲームの人気やユーザの継続的なプレイを維持していくには、短期間（短期サイクル）で新たなゲームコンテンツ等を配信していくことも重要である。
【０００８】
本発明の少なくとも１つの実施形態の目的は、上記課題を解決し、より短期間で新たなゲームコンテンツ等を配信してユーザの継続的なプレイを維持する課金プログラム等を提供することにある。
【課題を解決するための手段】
【０００９】
非限定的な観点によると、本発明の一実施形態に係るゲームプログラムは、対価を支払ったユーザにゲームのプレイが許可されるゲーム装置と通信ネットワークにより接続されるサーバ装置に、ゲームの運営者に対する課金額を対価に基づいて算定させるための課金プログラムであって、サーバ装置に、プレイが許可されたゲームのコンテンツが、第一状態の所定のコンテンツを第二状態に設定変更するコンテンツであるか否かに関する情報を含むプレイ情報を、ゲーム装置から取得する取得機能、設定変更するコンテンツである場合、第１課金レートを用いてプレイの課金額を算定し、設定変更するコンテンツでない場合、第１課金レートよりも低いレートの第２課金レートを用いてプレイの課金額を算定する算定機能、を実現させるためのものである。
【００１０】
非限定的な観点によると、本発明の一実施形態に係るゲームプログラムは、通信ネットワークによりサーバ装置に接続され、対価を支払ったユーザにゲームのプレイを許可するゲーム装置のゲームプログラムであって、ゲーム装置に、ゲームの運営者に対する課金額を対価に基づいて算定するサーバ装置であって、プレイが許可されたゲームのコンテンツが第一状態の所定のコンテンツを第二状態に設定変更するコンテンツである場合、第１課金レートを用いてプレイの課金額を算定し、許可されたゲームのコンテンツが設定変更するコンテンツでない場合、第１課金レートよりも低いレートの第２課金レートを用いてプレイの課金額を算定するサーバ装置に、プレイが許可されたゲームのコンテンツが、第一状態の所定のコンテンツを第二状態に設定変更するコンテンツであるか否かに関する情報を含むプレイ情報を送信する送信機能、を実現させるためものである。
【００１１】
非限定的な観点によると、本発明の一実施形態に係るゲームシステムは、対価を支払ったユーザにゲームのプレイが許可されるゲーム装置と、ゲーム装置と通信ネットワークにより接続されるサーバ装置とを備え、ゲームの運営者に対する課金額を対価に基づいて算定するゲームシステムであって、記憶部に記憶されているユーザのゲームのプレイ履歴を含む履歴情報に基づいて、ゲームの複数のコンテンツにおける第一状態のコンテンツの有無を判定する判定手段、第一状態のコンテンツがあると判定された場合、第一状態のコンテンツを第二状態に設定変更するコンテンツをユーザに選択可能にさせる許可手段、ゲームのプレイ結果に応じて履歴情報を更新する更新手段、プレイが許可されたゲームのコンテンツが、設定変更するコンテンツである場合、第１課金レートを用いてプレイの課金額を算定し、設定変更するコンテンツでない場合、第１課金レートよりも低いレートの第２課金レートを用いてプレイの課金額を算定する算定手段、を含む。
【発明の効果】
【００１２】
本願の各実施形態により１または２以上の不足が解決される。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施形態の少なくとも一つに対応するゲームシステムの構成の例を示すブロック図である。
【図２】本発明の実施形態の少なくとも一つに対応するサーバ装置の構成を示す機能ブロック図である。
【図３】本発明の実施形態の少なくとも一つに対応する端末装置の構成を示す機能ブロック図である。
【図４】本発明の実施形態の少なくとも一つに対応するゲームの進行処理の例を示すフローチャートである。
【図５】本発明の実施形態の少なくとも一つに対応するサーバ装置の構成を示す機能ブロック図である。
【図６】本発明の実施形態の少なくとも一つに対応する端末装置の構成を示す機能ブロック図である。
【図７】本発明の実施形態の少なくとも一つに対応するゲームの進行処理の例を示すフローチャートである。
【図８】本発明の実施形態の少なくとも一つに対応するサーバ装置の構成を示す機能ブロック図である。
【図９】本発明の実施形態の少なくとも一つに対応する端末装置の構成を示す機能ブロック図である。
【図１０】本発明の実施形態の少なくとも一つに対応するゲームシステムの構成の例を示すブロック図である。
【図１１】本発明の実施形態の少くとも一つに対応するゲーム画像の一例を示す図である。
【図１２】本発明の実施形態の少なくとも一つに対応するサーバ装置の構成を示す機能ブロック図である。
【図１３】本発明の実施形態の少なくとも一つに対応する端末装置の構成を示す機能ブロック図である。
【図１４】本発明の実施形態の少なくとも一つに対応する履歴情報の一例を示す図である。
【図１５】本発明の実施形態の少なくとも一つに対応する楽曲リストの一例を示す図である。
【図１６】本発明の実施形態の少なくとも一つに対応するゲームの進行処理の例を示すフローチャートである。
【図１７】本発明の実施形態の少なくとも一つに対応するゲームシステムの構成の例を示すブロック図である。
【図１８】本発明の実施形態の少なくとも一つに対応するサーバ装置の構成を示す機能ブロック図である。
【図１９】本発明の実施形態の少なくとも一つに対応する端末装置の構成を示す機能ブロック図である。
【図２０】本発明の実施形態の少なくとも一つに対応するゲームの進行処理の例を示すフローチャートである。
【図２１】本発明の実施形態の少なくとも一つに対応するゲームシステムの構成の例を示すブロック図である。
【図２２】本発明の実施形態の少なくとも一つに対応するゲーム画像の一例を示す図である。
【図２３】本発明の実施形態の少なくとも一つに対応するサーバ装置の構成を示す機能ブロック図である。
【図２４】本発明の実施形態の少なくとも一つに対応する端末装置の構成を示す機能ブロック図である。
【図２５】本発明の実施形態の少なくとも一つに対応する履歴情報の一例を示す図である。
【図２６】本発明の実施形態の少なくとも一つに対応する楽曲リストの一例を示す図である。
【図２７】本発明の実施形態の少なくとも一つに対応するゲームの進行処理の例を示すフローチャートである。
【発明を実施するための形態】
【００１４】
以下、本発明の実施形態の例について図面を参照して説明する。なお、以下で説明する各実施形態の例における各種構成要素は、矛盾等が生じない範囲で適宜組み合わせ可能である。また、ある実施形態の例として説明した内容については、他の実施形態においてその説明を省略している場合がある。また、各実施形態の特徴部分に関係しない動作や処理については、その内容を省略している場合がある。さらに、以下で説明する各種フローを構成する各種処理の順序は、処理内容に矛盾等が生じない範囲で順不同である。
【００１５】
［第１の実施形態］
図１は、本発明の一の実施形態におけるゲームシステム１００の構成の例を示すブロック図である。図１に示すように、ゲームシステム１００は、サーバ装置１０と、ビデオゲームをプレイする複数のユーザ（プレイヤ）がそれぞれ使用する端末装置（ゲーム装置）２０，２０１〜２０Ｎ（Ｎは任意の整数）とを含む。サーバ装置１０と複数の端末装置２０，２０１〜２０Ｎとは、それぞれインターネットなどの通信ネットワーク１５に接続されている。なお、ゲームシステム１００の構成はこれに限定されず、例えば単一の端末装置を複数のユーザが使用する構成としてもよいし、複数のサーバ装置を備える構成としてもよい。
【００１６】
ゲームシステム１００は、例えば、ゲーム（ビデオゲーム）の運営者に対する課金額を、ユーザが支払った対価に基づいて算定する各種機能を有する。ユーザは、端末装置２０，２０１〜２０Ｎにおいて対価を支払うことでゲームのプレイが許可される。すなわち、運営者は、ゲームをプレイするユーザから対価を獲得するゲームの運営者である。課金額は、上記ゲームを制作したゲームメーカ等が、運営を許可した運営者に課す金額である。
【００１７】
本実施形態の例では、プレイが許可されたゲームのコンテンツが、第一状態の所定のコンテンツを第二状態に設定変更するコンテンツである場合、第１課金レートを用いて上記許可されたプレイの課金額が算定される。一方、プレイが許可されたゲームのコンテンツが、設定変更するコンテンツでない場合、第２課金レートを用いて上記許可されたプレイの課金額が算定される。第二課金レートは、第一課金レートよりも低いレートが設定されている。
【００１８】
例えば、第１課金レート：７５％、第２課金レート：１５％と設定されて、ユーザが１００円の対価を支払ってプレイを行う場合について説明する。第一課金レートを用いた場合、上記ユーザのプレイにおける課金額は、対価：１００円の７５％にあたる７５円となる。すなわち、７５円が運営者からゲームメーカ等に支払う金額となる。そして、残りの２５円が運営者の売り上げとなる。
【００１９】
サーバ装置１０は、運営者に課金を行うゲームメーカ等の管理者によって管理され、運営者の課金額を算定するための各種機能を有する。この実施形態において、サーバ装置１０は、課金額を算定するべくＷＷＷサーバなどの情報処理装置によって構成され、各種情報を格納するデータベースを備える。
【００２０】
図２は、サーバ装置１０の構成の例であるサーバ装置１０Ａの構成を示す機能ブロック図である。サーバ装置１０Ａは、図示しないＨＤＤ等の記憶部及びＣＰＵ等から構成される制御部等を備えるが、詳細な説明は省略する。サーバ装置１０Ａは、制御部が記憶部に記憶されている課金プログラムを実行することで課金サーバとして機能するための取得部１１及び算定部１２を少なくとも備える。
【００２１】
取得部１１は、ゲームのプレイ情報を端末装置２０，２０１〜２０Ｎから取得する。プレイ情報は、ユーザがゲームのプレイを行う（又は行った）実績を示す情報であり、プレイが許可されたゲームのコンテンツが、第一状態の所定のコンテンツを第二状態に設定変更するコンテンツであるか否かに関する情報が少なくとも含まれる。
【００２２】
算定部１２は、プレイ情報を参照し、プレイの対価に基づいて運営者の課金額を算定する。上述したように、プレイが許可されたゲームのコンテンツの状態に応じた課金レートを用いて、ユーザのプレイに対する運営者の課金額を算定する。なお、第一課金レート及び第二課金レートの値は、予め課金プログラムのデータとして含めておけばよい。
【００２３】
複数の端末装置２０，２０１〜２０Ｎは、それぞれ、ビデオゲームを行うユーザ又は運営者等によって管理される。端末装置２０，２０１〜２０Ｎは、例えば、据置型ゲーム装置、パーソナルコンピュータ、携帯電話端末やＰＤＡ（Personal Digital Assistants）、携帯型ゲーム装置、業務用のゲーム装置などのビデオゲームを実行することが可能な端末装置によって構成される。
【００２４】
端末装置２０，２０１〜２０Ｎのそれぞれは、ビデオゲームの進行を制御するため、複数の操作装置（操作部）、ＨＤＤ等の記憶部、ゲームを実行してゲーム画像を生成するＣＰＵ等から構成される制御部、ゲーム画像を表示させる表示装置（表示部）等を備えるが、詳細な説明は省略する。また、端末装置２０，２０１〜２０Ｎには、本実施形態の例のビデオゲームの進行を制御するとともに、ユーザのゲームのプレイ情報をサーバ装置１０に送信するためのソフトウェア（プログラム）が記憶部に記憶されている。
【００２５】
図３は、端末装置２０の構成の例である端末装置２０Ａの構成を示す機能ブロック図である。端末装置２０Ａは、例えば、制御部が記憶部に記憶されているプログラムを実行することで判定部２１、許可部２２及び更新部２３を少なくとも備える。なお、端末装置２０１Ａ〜２０ＮＡについても同様の構成である。
【００２６】
判定部２１は、ユーザの履歴情報に基づいて、ゲームの複数のコンテンツの中で第一状態のコンテンツがあるか否かを判定する。判定部２１は、例えば、ユーザが所持する可搬型のＩＣカード（記憶部）から履歴情報を取得すればよい。履歴情報は、ユーザのゲームのプレイ履歴を含む履歴情報であり、ユーザの識別情報に対応付けて記憶されている。履歴情報は、少なくとも、ゲームの各コンテンツが第一状態及び第二状態のいずれの状態であるかを特定するための情報が含まれていればよい。この特定するための情報としては、例えば、第二状態が設定されているコンテンツのリストが該当する。また、過去にプレイした設定変更するコンテンツのプレイ履歴の情報が該当する。
【００２７】
許可部２２は、第一状態のコンテンツがあると判定された場合、設定変更するコンテンツをユーザに選択可能にさせる情報（許可情報）を設定する。すなわち、選択可能な設定がされた端末装置２０Ａ，２０１Ａ〜２０ＮＡのみ、設定変更するコンテンツのプレイが可能となる。更新部２３は、ユーザのゲームのプレイ結果に応じて、このユーザの履歴情報を更新する。
【００２８】
次に、この実施形態のゲームシステム１００（システム１００）の動作について説明する。
【００２９】
図４は、システム１００が実行するゲームの進行処理の例を示すフローチャートである。本実施形態の例における進行処理では、ゲームを進行させるための処理が行われるとともに、ゲームの運営者の課金額を算定するための処理（課金処理）が行われる。なお、図４においては、主として、課金処理に関連する処理のみを説明し、その他の処理は省略する。以下、サーバ装置１０Ａと端末装置２０Ａとが進行処理を実行する場合を例にして説明する。
【００３０】
本実施形態の例の進行処理は、例えばサーバ装置１０Ａ及び端末装置２０Ａの起動中に実施される。
【００３１】
進行処理において、端末装置２０Ａは、履歴情報を取得するまで待機する（ステップＳ３０）。端末装置２０Ａは、例えば、ユーザが対価を支払って、ユーザの履歴情報が記憶部から読み取られるまで待機する。ユーザの履歴情報を取得した場合（ステップＳ３０：ＹＥＳ）、端末装置２０Ａは、ゲームの複数のコンテンツのうち、第一状態にあるコンテンツの有無を判定する（ステップＳ３１）。上述したように、ユーザの履歴情報に基づいて、第一状態のコンテンツの有無が判定される。
【００３２】
次に、端末装置２０Ａは、判定結果に基づく設定を行う（ステップＳ３２）。具体的には、第一状態のコンテンツがある場合、端末装置２０Ａは、設定変更するコンテンツをユーザに選択可能にさせる情報（許可情報）を設定する。一方、第一状態のコンテンツがない場合、端末装置２０Ａは、設定変更するコンテンツをユーザに選択不可にさせる情報（不許可情報）を設定する。なお、不許可情報は設定しなくてもよい。
【００３３】
その後、端末装置２０Ａは、ゲームのプレイが許可されるまで待機する（ステップＳ３３）。図示しないが、端末装置２０Ａは、上記設定に基づいて、例えば、表示部にゲームのコンテンツの選択画面を表示し、ユーザによって選択されたコンテンツのプレイを許可する。プレイが許可された場合（ステップＳ３３：ＹＥＳ）、端末装置２０Ａは、このユーザのプレイ情報をサーバ装置１０Ａに送信する（ステップＳ３４）。
【００３４】
一方、サーバ装置１０Ａは、端末装置２０Ａからプレイ情報を受信するまで待機する（ステップＳ１０）。プレイ情報を受信した場合（ステップＳ１０：ＹＥＳ）、サーバ装置１０Ａは、プレイ情報に基づいて、プレイが許可されたゲームのコンテンツが、第一状態の所定のコンテンツを第二状態に設定変更するコンテンツであるか否かを判定する（ステップＳ１１）。
【００３５】
プレイが許可されたゲームのコンテンツが設定変更するコンテンツである場合（ステップＳ１１：ＹＥＳ）、サーバ装置１０Ａは、第１課金レートを用いて上記プレイ（プレイ情報）に対する運営者の課金額を算定する（ステップＳ１２）。一方、プレイが許可されたゲームのコンテンツが設定変更するコンテンツでない場合（ステップＳ１１：ＮＯ）、サーバ装置１０Ａは、第２課金レートを用いて上記プレイ（プレイ情報）に対する運営者の課金額を算定する（ステップＳ１３）。その後、サーバ装置１０Ａは、ステップＳ１０の処理に戻る。
【００３６】
また、端末装置２０Ａは、ステップＳ３４の処理の実行後、図示しないがプレイを許可したゲームのコンテンツの進行処理を開始する。そして、プレイの終了後、端末装置２０Ａは、ゲーム結果に基づいて、このユーザの履歴情報を更新し（ステップＳ３５）、ステップＳ３０の処理に戻る。
【００３７】
以上のように、第１の実施形態の一側面として、サーバ装置１０Ａが、取得部１１及び算定部１２を備える構成としているので、プレイが許可されたゲームのコンテンツに応じて課金額が異なってくる。例えば、新たに配信された新規状態（第一状態）のゲームのコンテンツを既存状態（第二状態）に設定変更するコンテンツがある場合、新規状態から既存状態に変更するための課金額は高くなる。したがって、新規なコンテンツが配信された当初は課金額が高くなるため、配信される新たなゲームのコンテンツ等の制作コストをゲームメーカがより短期間で回収することができる。これによって、より短期間で新たなゲームのコンテンツ等を配信してユーザの継続的なプレイを維持することができる。
【００３８】
また、コンテンツの状態が、ユーザ毎に設定されるので、ユーザの対価に基づく課金額をより正確に算定できる。
【００３９】
なお、上述のゲームの「コンテンツ」は、ゲームに関連する要素を意味し、例えば、ゲームにおけるプレイモード（ユーザ対戦モード、シングルプレイモード等）、ゲーム内のキャラクタ、アイテム等が含まれる。また、例えば、楽曲を再生するとともに操作入力を促す指示標識を端末装置の表示部に表示するリズムゲームにおいて、楽曲もコンテンツに該当する。また、ゲームステージ、ゲームのシナリオ等もコンテンツに該当する。
【００４０】
また、上述の「第一状態」及び「第二状態」は、例えば、コンテンツが新規であることを示す状態（新規状態）、及び、新規ではないことを示す状態（既存状態）がある。例えば、上述のリズムゲームにおいて、新規な楽曲（新規状態）が端末装置に配信された場合、所定のゲームモード（第一モード）をユーザがプレイすることで、新規な楽曲（新規状態）が既存の楽曲（既存状態）に設定変更される。この場合、第一モードが「設定変更するコンテンツ」に該当し、第一課金レートが用いられる。そして、既存状態の楽曲は、第二モードにおいてプレイすることができる。第二モードは、既存状態の楽曲のみプレイでき、また第二モードでのプレイは、第二課金レートが用いられる。
【００４１】
上述の履歴情報としては、上述したリズムゲームの場合、ユーザの履歴情報に、既存状態（第二状態）である楽曲を特定する楽曲リストを含めておけばよい。そして、履歴情報の楽曲リストに含まれていない楽曲は、新規状態（第一状態）と判定すればよい。
【００４２】
上述の運営者は、単体でも二以上であってもよい。二以上の運営者がいる場合、サーバ装置は、プレイ情報とともに、端末装置の識別情報、又は／及び、運営者の識別情報を端末装置から取得すればよい。なお、端末装置の識別情報を取得する場合、いずれの運営者の端末装置であるかを特定できるように、端末装置の識別情報と運営者の識別情報とが対応付けられた情報をサーバ装置の記憶部に記憶していおけばよい。
【００４３】
上述のユーザのプレイの対価は、電子マネー、クレジット決済、硬貨の投入等のいずれの支払い形式であってもよい。なお、対価の額は、一律に固定されている構成としてもよく、プレイするゲームのコンテンツ等によって異なる構成としてもよい。対価の額が一律に固定されていない場合、サーバ装置は、対価の額の情報をプレイ情報に含めて端末装置から取得すればよい。
【００４４】
上述の「ビデオゲーム」は、ユーザの対価の支払いによってプレイが許可される構成であれば、リズムゲームに限らず、ロールプレイングゲーム、育成ゲーム等のいずれのジャンルのゲームを採用してもよい。
【００４５】
なお、上述の実施形態の例では、端末装置がゲームの進行制御も行っているが、特にこれに限定されるものではない。例えば、サーバ装置が課金処理に加えて、ゲームサーバとしてゲームの進行制御を行ってもよい。あるいは、課金処理を行うサーバ装置とは異なるサーバ装置がゲームサーバとしてゲームの進行制御を行ってもよい。
【００４６】
また、上述の実施形態の例では、端末装置が、判定部、許可部、更新部を備えているが、サーバ装置が判定部、許可部、更新部の全部又は一部を備える構成としてもよい。
【００４７】
［第２の実施形態］
図５は、サーバ装置１０の例であるサーバ装置１０Ｂの構成を示すブロック図である。本実施形態の例において、サーバ装置１０Ｂは、取得部１１、算定部１２、判定部１３Ｂ及び許可部１４Ｂを少なくとも備える。
【００４８】
判定部１３Ｂは、上述の判定部２１と同様に、ユーザの履歴情報に基づいて、ゲームの複数のコンテンツの中で第一状態のコンテンツがあるか否かを判定する。本実施形態の判定部１３Ｂは、ユーザの識別情報をこのユーザが使用する端末装置２０Ｂ，２０１Ｂ〜２０ＮＢから取得し、このユーザの識別情報に対応する履歴情報を記憶部から取得する。記憶部は、サーバ装置１０Ｂが履歴情報を取得できるように構成されていれば、サーバ装置１０Ｂに内蔵の記憶部であっても、サーバ装置１０Ｂに接続された外部の記憶部であってもよい。
【００４９】
許可部１４Ｂは、第一状態のコンテンツがあると判定された場合、設定変更するコンテンツをユーザに選択可能にさせる情報（許可情報）を、このユーザが使用する端末装置２０Ｂ，２０１Ｂ〜２０ＮＢに送信する。許可情報を受信した端末装置２０，２０１〜２０Ｎは、例えば、表示部に設定変更するコンテンツも選択可能に表示する。
【００５０】
取得部１１は、ゲームのプレイ情報を端末装置２０Ｂ，２０１Ｂ〜２０ＮＢから取得する。算定部１２は、プレイ情報を参照し、プレイの対価に基づいて運営者の課金額を算定する。プレイが許可されたゲームのコンテンツの状態に応じた課金レートを用いて、ユーザのプレイに対する運営者の課金額が算定される。
【００５１】
図６は、端末装置２０の例である端末装置２０Ｂの構成を示すブロック図である。本実施形態の例において、端末装置２０Ｂは、更新部２３を少なくとも備える。なお、端末装置２０１Ｂ〜２０ＮＢについても同様の構成である。
【００５２】
更新部２３Ｂ、ユーザのゲームのプレイ結果に応じて、このユーザの履歴情報を更新する。本実施形態の例では、更新部２３Ｂは、記憶部の履歴情報を直接に更新してもよく、またサーバ装置１０Ｂ経由で更新してもよい。なお、端末装置２０Ｂは、ゲームの進行処理において、事前にユーザの履歴情報を記憶部から取得しておけばよい。なお、サーバ装置１０Ｂが端末装置２０Ｂからゲーム結果を取得してユーザの履歴情報を更新するようにしてもよい。
【００５３】
図７は、システム１００が実行するゲームの進行処理の例を示すフローチャートである。本実施形態の例における進行処理では、ゲームを進行させるための処理が行われるとともに、ゲームの運営者の課金額を算定するための処理（課金処理）が行われる。なお、図７においては、主として、課金処理に関連する処理のみを説明し、その他の処理は省略する。以下、サーバ装置１０Ｂと端末装置２０Ｂとが進行処理を実行する場合を例にして説明する。
【００５４】
本実施形態の例の進行処理は、例えばサーバ装置１０Ｂ及び端末装置２０Ｂの起動中に実施される。
【００５５】
進行処理において、端末装置２０Ｂは、ユーザの識別情報を取得するまで待機する（ステップＳ２５−Ｂ）。端末装置２０Ｂは、例えば、ユーザが対価を支払って、ユーザの識別情報が入力されるまで待機する。あるいは、ユーザの識別情報を、端末装置２０Ｂの記憶部に予め記憶しておき、記憶部からユーザの識別情報を取得してもよい。ユーザの履歴情報を取得した場合（ステップＳ２５−Ｂ：ＹＥＳ）、端末装置２０Ｂは、サーバ装置１０Ｂにユーザの識別情報を送信し（Ｓ２６−Ｂ）、サーバ装置１０Ｂからの応答を待つ。
【００５６】
サーバ装置１０Ｂは、ユーザの識別情報を受信するまで待機する（ステップＳ５−Ｂ）。ユーザの識別情報を受信した場合（ステップＳ５−Ｂ：ＹＥＳ）、サーバ装置１０Ｂは、ゲームの複数のコンテンツのうち、第一状態にあるコンテンツの有無を判定する（ステップＳ６−Ｂ）。上述したように、ユーザの識別情報に対応する履歴情報に基づいて、コンテンツの有無が判定される。
【００５７】
次に、サーバ装置１０Ｂは、判定結果に基づく情報を、ユーザの識別情報を送信した端末装置２０Ｂに送信する（ステップＳ７−Ｂ）。具体的には、第一状態のコンテンツがある場合、サーバ装置１０Ｂは、設定変更するコンテンツをユーザに選択可能にさせる情報（許可情報）を送信する。一方、第一状態のコンテンツがない場合、サーバ装置１０Ｂは、設定変更するコンテンツをユーザに選択不可にさせる情報（不許可情報）を送信する。なお、不許可情報は送信しなくてもよい。この場合、例えば、端末装置２０Ｂは、ユーザの識別情報をサーバ装置１０Ｂに送信後、所定期間を経過するまでに許可情報を受信しなければ不許可であると判断すればよい。
【００５８】
その後、サーバ装置１０Ｂは、端末装置２０Ａからプレイ情報を受信するまで待機する（ステップＳ１０）。一方、端末装置２０Ｂは、送信された情報に基づく設定を行う（ステップＳ３２−Ｂ）。すなわち、許可情報及び不許可情報のいずれかが設定される。
【００５９】
次に、端末装置２０Ｂは、ゲームのプレイが許可されるまで待機する（ステップＳ３３）。図示しないが、端末装置２０ＢＡは、上記設定に基づいて、例えば、表示部にゲームのコンテンツの選択画面を表示し、ユーザによって選択されたコンテンツのプレイを許可する。プレイが許可された場合（ステップＳ３３：ＹＥＳ）、端末装置２０Ｂは、このユーザのプレイ情報をサーバ装置１０Ａに送信する（ステップＳ３４）。
【００６０】
プレイ情報を受信した場合（ステップＳ１０：ＹＥＳ）、サーバ装置１０Ｂは、プレイ情報に基づいて、プレイが許可されたゲームのコンテンツが、第一状態の所定のコンテンツを第二状態に設定変更するコンテンツであるか否かを判定する（ステップＳ１１）。
【００６１】
プレイが許可されたゲームのコンテンツが設定変更するコンテンツである場合（ステップＳ１１：ＹＥＳ）、サーバ装置１０Ｂは、第１課金レートを用いて上記プレイ（プレイ情報）に対する運営者の課金額を算定する（ステップＳ１２）。一方、プレイが許可されたゲームのコンテンツが設定変更するコンテンツでない場合（ステップＳ１１：ＮＯ）、サーバ装置１０Ｂは、第２課金レートを用いて上記プレイ（プレイ情報）に対する運営者の課金額を算定する（ステップＳ１３）。その後、サーバ装置１０Ｂは、ステップＳ５−Ｂの処理に戻る。
【００６２】
また、端末装置２０Ｂは、ステップＳ３４の処理の実行後、図示しないがプレイを許可したゲームのコンテンツの進行処理を開始する。そして、プレイの終了後、端末装置２０Ｂは、ゲーム結果に基づいて、このユーザの履歴情報を更新し（ステップＳ３５−Ｂ）、ステップＳ２５−Ｂの処理に戻る。
【００６３】
以上のように、第２の実施形態の一側面として、サーバ装置１０Ｂが、取得部１１、算定部１２、判定部１３Ｂ及び許可部１４Ｂを備える構成としているので、プレイが許可されたゲームのコンテンツに応じて課金額が異なってくる。例えば、新たに配信された新規状態（第一状態）のゲームのコンテンツを既存状態（第二状態）に設定変更するコンテンツがある場合、新規状態から既存状態に変更するための課金額は高くなる。したがって、新規なコンテンツが配信された当初は課金額が高くなるため、配信される新たなゲームのコンテンツ等の制作コストをゲームメーカがより短期間で回収することができる。これによって、より短期間で新たなゲームのコンテンツ等を配信してユーザの継続的なプレイを維持することができる。
【００６４】
また、コンテンツの状態が、ユーザ毎に設定されるので、ユーザの対価に基づく課金額をより正確に算定できる。
【００６５】
［第３の実施形態］
図８は、サーバ装置１０の例であるサーバ装置１０Ｃの構成を示すブロック図である。本実施形態の例において、サーバ装置１０Ｃは、取得部１１Ｃ及び算定部１２を少なくとも備える。
【００６６】
本実施形態の例では、端末装置２０Ｃ，２０１Ｃ〜２０ＮＣにおいて、楽曲を再生するとともに操作入力を促す指示標識を表示部に表示するリズムゲームが実行される。また、第一状態及び第二状態が設定されるコンテンツとして楽曲が該当する。
【００６７】
取得部１１Ｃは、プレイが許可されたゲームのコンテンツが、第一状態の所定の楽曲を第二状態に設定変更するコンテンツであるか否かに関する情報を含むプレイ情報を、端末装置２０Ｃ，２０１Ｃ〜２０ＮＣから取得する。
【００６８】
算定部１２は、プレイ情報を参照し、プレイの対価に基づいて運営者の課金額を算定する。プレイが許可されたゲームのコンテンツの状態に応じて選択した課金レートを用いて、ユーザのプレイに対する運営者の課金額が算定される。
【００６９】
図９は、端末装置２０の構成の例である端末装置２０Ｃの構成を示す機能ブロック図である。なお、端末装置２０１Ｃ〜２０ＮＣについても同様の構成である。端末装置２０Ｃは、判定部２１Ｃ、許可部２２Ｃ及び更新部２３Ｃを少なくとも備える。
【００７０】
判定部２１Ｃは、ユーザの履歴情報に基づいて、ゲームの複数の楽曲の中で第一状態の楽曲があるか否かを判定する。履歴情報は、少なくとも、楽曲が第一状態及び第二状態のいずれの状態であるかを特定するための情報が含まれていればよい。例えば、第二状態が設定されている楽曲のリストが該当する。また、過去にプレイした設定変更するコンテンツのプレイ履歴の情報が該当する。
【００７１】
許可部２２Ｃは、第一状態の楽曲があると判定された場合、設定変更するコンテンツをユーザに選択可能にさせる情報（許可情報）を設定する。更新部２３Ｃは、ユーザのゲームのプレイ結果に応じて、このユーザの履歴情報を更新する。例えば、第二状態が設定されている楽曲のリストが更新される。なお、ゲームの進行処理については、第１の実施形態の図４と同様であるので説明は省略する。
【００７２】
上述の第一状態の所定の楽曲を第二状態に設定変更するコンテンツは、例えば、ゲームのモードであってもよく、また第一状態の楽曲自体であってもよい。
【００７３】
例えば、「第一状態」及び「第二状態」が、楽曲が新規であることを示す状態（新規状態）、及び、新規ではないことを示す状態（既存状態）を示す場合について説明する。新規な楽曲（新規状態）が端末装置に配信された場合、所定のゲームモード（第一モード）をユーザがプレイすることで、新規な楽曲（新規状態）が既存の楽曲（既存状態）に設定変更される。この場合、第一モードが「設定変更するコンテンツ」に該当し、第一課金レートが用いられる。そして、既存状態の楽曲は、第二モードにおいてプレイすることができる。第二モードは、既存状態の楽曲のみプレイでき、また第二モードでのプレイは、第二課金レートが用いられる。
【００７４】
また、例えば、第一状態の所定の楽曲を第二状態に設定変更するコンテンツが、新規状態（第一状態）の楽曲自体である場合について説明する。ユーザによって或る新規状態の楽曲がプレイされることで、この楽曲が第二状態に設定変更される。そして、第一状態の楽曲がプレイされる場合は第一課金レートが用いられ、第二状態の楽曲がプレイされる場合は第二課金レートが用いられる。すなわち、楽曲をプレイする場合は、新規状態の最初のプレイのみ運営者の課金額が高くなる。
【００７５】
以上のように、第３の実施形態の一側面として、サーバ装置１０Ｃが、取得部１１Ｃ及び算定部１２を備える構成としているので、プレイが許可されたゲームのコンテンツに応じて課金額が異なってくる。上記例のように、新たに配信された新規状態（第一状態）のゲームのコンテンツを既存状態（第二状態）に設定変更するコンテンツがある場合、新規状態から既存状態に変更するための課金額は高くなる。したがって、新規なコンテンツが配信された当初は課金額が高くなるため、配信される新たなゲームのコンテンツ等の制作コストをゲームメーカがより短期間で回収することができる。これによって、より短期間で新たなゲームのコンテンツ等を配信してユーザの継続的なプレイを維持することができる。
【００７６】
また、楽曲の状態が、ユーザ毎に設定されるので、ユーザの対価に基づく課金額をより正確に算定できる。
【００７７】
［第４の実施形態］
図１０は、ゲームシステム１００の構成の例であるゲームシステム１００Ｄの構成を示すブロック図である。本実施形態の例のゲームシステム１００Ｄは、サーバ装置１０Ｄと、複数の端末装置２０Ｄ，２０１Ｄ〜２０ＮＤ（Ｎは任意の整数）とを含む。サーバ装置１０Ｄと、ビデオゲームをプレイする複数のユーザ（プレイヤ）がそれぞれ使用する複数の端末装置２０Ｄ，２０１Ｄ〜２０ＮＤとは、それぞれインターネットなどの通信ネットワーク１５に接続されている。なお、ゲームシステム１００の構成はこれに限定されず、例えば単一の端末装置を複数のユーザが使用する構成としてもよいし、複数のサーバ装置を備える構成としてもよい。
【００７８】
本実施形態の例のゲームシステム１００Ｄは、例えば、楽曲を再生するとともに操作入力を促す指示標識（ターゲット）を端末装置２０Ｄ，２０１Ｄ〜２０ＮＤの表示部に表示するリズムゲームを実行する各種機能を有する。また、本実施形態の例のゲームシステム１００Ｄは、リズムゲームの運営者に対する課金額を、ユーザが支払った対価に基づいて算定する各種機能を有する。
【００７９】
サーバ装置１０Ｄは、運営者に課金を行うゲームメーカの管理者によって管理され、運営者の課金額を算定するための各種機能を有する。また、サーバ装置１０Ｄは、楽曲（コンテンツ）等の新たなコンテンツを端末装置２０Ｄ，２０１Ｄ〜２０ＮＤに配信するための各種機能を有する。この実施形態において、サーバ装置１０Ｄは、課金額の算定及びコンテンツの配信をするべくＷＷＷサーバなどの情報処理装置によって構成され、各種情報を格納するデータベースを備える。
【００８０】
端末装置２０Ｄ，２０１Ｄ〜２０ＮＤは、店舗（施設）に設置された業務用のゲーム装置であり、各店舗の運営者によって管理される。端末装置２０Ｄ，２０１Ｄ〜２０ＮＤの記憶部には、本実施形態の例のリズムゲームの進行を制御するとともに、ユーザのゲームのプレイ情報をサーバ装置１０Ｄに送信するためのソフトウェア（プログラム）が記憶されている。ユーザは、端末装置２０Ｄ，２０１Ｄ〜２０ＮＤにおいて対価を支払うことでゲームのプレイが可能となる。各店舗の端末装置２０Ｄ，２０１Ｄ〜２０ＮＤは、各店舗に設置された通信装置４０Ｄ，４０１Ｄ，４０ｎＤ（ｎは任意の整数）を介して通信ネットワーク１５に接続されている。本実施形態の例では、端末装置２０Ｄ，２０１Ｄ〜２０ＮＤを管理する店舗の運営者が、リズムゲームの運営者である。
【００８１】
本実施形態の例のリズムゲームでは、図１１に示すように、第一モード及び第二モードの２種類のゲームモードがある。ユーザは、図１１に示すゲーム画面（選択画面）上で端末装置２０Ｄ，２０１Ｄ〜２０ＮＤの操作部を操作してプレイしたいモードを選択できる。
【００８２】
第一モードは、配信された新規の楽曲を解放するための特殊なゲームモードである。第二モードは、既存の楽曲をプレイするための通常のゲームモードである。楽曲には新規状態及び既存状態のいずれかの状態が設定される。第二モードは、端末装置２０Ｄ，２０１Ｄ〜２０ＮＤに配信されている全ての既存状態の楽曲のうちから、例えば３曲をプレイすることができる。
【００８３】
第一モードは、端末装置２０Ｄ，２０１Ｄ〜２０ＮＤに配信されている全ての楽曲のうちから、例えば２曲をプレイすることができる。第一モードでは、第二モードと異なり、新規状態の楽曲もプレイすることができるがプレイできる楽曲数が少ない。しかし、第一モードで２曲をプレイした結果が解放条件を満たした場合、新規状態の全ての楽曲が既存状態に設定変更される。本実施形態の例では、各モードを１プレイするための対価は同一である（例えば１００円）。
【００８４】
本実施形態の例では、プレイが許可されたゲームモードが第一モードである場合、第１課金レートを用いて上記プレイの課金額が算定される。一方、プレイが許可されたゲームモードが第二モードである場合、第２課金レートを用いて上記プレイの課金額が算定される。第二課金レートは、第一課金レートよりも低いレートが設定されている。例えば、第１課金レート：７５％、第２課金レート：１５％が設定される。第一課金レートを用いた場合、上記ユーザのプレイに対する課金額は、対価１００円の７５％にあたる７５円となる。そして、残りの２５円が運営者の売り上げとなる。
【００８５】
本実施形態の例では、サーバ装置１０Ｄが、ユーザのプレイに対して個々に算定した課金額を運営者毎に所定の期間（例えば毎月末締め）で集計し、集計した課金額（累計金額）をレポート（ゲームメーカーから運営者へ発行されるロイヤリティレポートや請求書等）として作成して出力する。すなわち、運営者が管理する端末装置で許可されたプレイの対価に基づいてのみ、この運営者の課金額が算定される。なお、レポートは、サーバ装置１０Ｄから各運営者に直接送信してもよい。
【００８６】
図１２は、サーバ装置１０の構成の例であるサーバ装置１０Ｄの構成を示す機能ブロック図である。サーバ装置１０Ｄは、制御部が記憶部に記憶されている課金プログラム及び配信プログラムを実行することで課金サーバ及び配信サーバとして機能するための取得部１１Ｄ、算定部１２Ｄ及び配信制御部１５Ｄを少なくとも備える。
【００８７】
取得部１１Ｄは、プレイが許可されたゲームモードが第一モードであるか否かに関する情報を含むプレイ情報を、端末装置２０Ｄ，２０１Ｄ〜２０ＮＤから取得する。プレイ情報は、運営者の識別情報とともに取得する。
【００８８】
算定部１２Ｄは、プレイ情報を参照し、プレイの対価に基づいて各運営者の課金額を算定する。具体的には、プレイ情報とともに取得した運営者の識別情報毎に課金額を算定する。また、上述したように、プレイが許可されたゲームモードに応じた課金レートを用いて課金額が算定される。
【００８９】
配信制御部１５Ｄは、サーバ装置１０Ｄのデータベース（記憶部）に記憶されている楽曲を端末装置２０Ｄ，２０１Ｄ〜２０ＮＤに配信する。すなわち、配信制御部１５Ｄは、新規に追加された楽曲のデータ等を端末装置２０Ｄ，２０１Ｄ〜２０ＮＤに送信する。なお、楽曲等のコンテンツの配信は、一般的な構成であるので詳細な説明は省略する。
【００９０】
図１３は、端末装置２０の構成の例である端末装置２０Ｄの構成を示す機能ブロック図である。なお、端末装置２０１Ｄ〜２０ＮＤについても同様の構成である。端末装置２０Ｄは、判定部２１Ｄ、許可部２２Ｄ、更新部２３Ｄ、読取部２４Ｄ及びゲーム進行制御部２５Ｄを少なくとも備える。
【００９１】
判定部２１Ｄは、ユーザの履歴情報に基づいて、端末装置２０Ｄにおいてプレイ可能な複数の楽曲の中で新規状態の楽曲があるか否かを判定する。ユーザの履歴情報は、図１４に示すように、ユーザのリズムゲームのプレイ履歴を含む履歴情報である。履歴情報は、ユーザが所有する可搬型のＩＣカード（記憶部）に記憶されている。読取部２４Ｄが、ユーザのＩＣカードから履歴情報を読み出す。
【００９２】
図１４に示すように、履歴情報は、ユーザＩＤに対応付けて、ランク、名称、既存曲ＩＤ等が設定されている。ユーザＩＤは、ユーザの識別情報である。ランクは、ユーザのリズムゲームにおけるレベルを示す。名称は、ユーザのリズムゲーム内での名称を示す。既存曲ＩＤは、このユーザ（ユーザＩＤ）に対する既存状態の楽曲を特定する情報（リスト）であり、楽曲の識別情報（楽曲ＩＤ）が設定される。既存曲ＩＤは、ユーザのゲームモードのプレイ状況に応じて変化することとなり、ユーザ毎に異なってくる。
【００９３】
判定部２１Ｄは、例えば、履歴情報の既存曲ＩＤと、図１５に示すような楽曲リストとを比較することで、新規状態の楽曲の有無を判定する。楽曲リストは、端末装置２０Ｄでプレイ可能な楽曲の一覧であり、端末装置２０Ｄの記憶部に記憶されている。判定部２１Ｄは、楽曲リスト中に、履歴情報の既存曲ＩＤに一致しない楽曲ＩＤが存在する場合、新規状態の楽曲があると判定する。
【００９４】
楽曲リストは、楽曲ＩＤに対応付けて、譜面データ、再生ファイル等が設定されている。譜面データは、リズムゲームにおける指示標識の表示開始タイミング、ユーザが操作すべきタイミングを特定する情報等が設定される。再生ファイルは、対応する楽曲の再生ファイルの情報が設定される。
【００９５】
許可部２２Ｄは、新規状態のコンテンツがあると判定された場合、第一モードをユーザに選択可能にさせる情報（許可情報）を設定する。更新部２３Ｄは、ユーザのリズムゲームのプレイ結果に応じて、ユーザの履歴情報を更新する。すなわち、ユーザが所有するＩＣカードの履歴情報を更新する。例えば、第一モードをプレイした場合、解放条件を満たせば、現時点における全ての新規状態の楽曲の楽曲ＩＤが既存曲ＩＤとして追加設定される。すなわち、新規状態の楽曲が既存状態に設定変更される。解放条件は、例えば、第一モードでの楽曲（２曲）のプレイの評価が所定評価以上の場合である。なお、解放条件は設定しなくてもよい。
【００９６】
読取部２４Ｄは、例えば、ＩＣカードリーダであり、ユーザのＩＣカードの情報を読み取る。ゲーム進行制御部２５Ｄは、ユーザの対価の支払いに基づいてゲームの進行を制御する。本実施形態の例では、端末装置２０Ｄ単体でゲームの進行が制御される。
【００９７】
図１６は、システム１００Ｄが実行するゲームの進行処理の例を示すフローチャートである。本実施形態の例における進行処理では、リズムゲームを進行させるための処理が行われるとともに、ゲームの運営者の課金額を算定するための処理（課金処理）が行われる。なお、図１６においては、主として、課金処理に関連する処理のみを説明し、その他の処理は省略する。以下、サーバ装置１０Ｄと端末装置２０Ｄとが進行処理を実行する場合を例にして説明する。
【００９８】
本実施形態の例の進行処理は、例えばサーバ装置１０Ｄ及び端末装置２０Ｄの起動中に実施される。
【００９９】
進行処理において、端末装置２０Ｄは、履歴情報を取得するまで待機する（ステップＳ３０−Ｄ）。端末装置２０Ｄは、ユーザが対価を支払って、ユーザの履歴情報がＩＣカードから読み取られるまで待機する。ユーザの履歴情報を取得した場合（ステップＳ３０−Ｄ：ＹＥＳ）、端末装置２０Ｄは、リズムゲームの複数の楽曲のうち、新規状態にある楽曲の有無を判定する（ステップＳ３１−Ｄ）。上述したように、ユーザの履歴情報及び楽曲リストに基づいて、新規状態の楽曲の有無が判定される。
【０１００】
次に、端末装置２０Ｄは、判定結果に基づく設定を行う（ステップＳ３２−Ｄ）。具体的には、新規状態の楽曲がある場合、端末装置２０Ｄは、第一モードをユーザに選択可能にさせる情報（許可情報）を設定する。一方、新規状態の楽曲がない場合、端末装置２０Ｄは、第一モードをユーザに選択不可にさせる情報（不許可情報）を設定する。なお、不許可情報は設定しなくてもよい。
【０１０１】
次に、端末装置２０Ｄは、設定情報に基づいて、端末装置２０Ｄの表示部にゲームモードの選択画面を表示する（ステップＳ３３−１Ｄ）。具体的には、設定情報に基づいて、選択画面での第一モードの表示及び非表示を切り替える。例えば、第一モードの非表示は、図１１の選択画面において第一モードの項目を非表示とする。ユーザは、第一モードが非表示の場合には選択することができない。
【０１０２】
その後、端末装置２０Ｄは、ゲームのプレイが許可されるまでＳ３３−１Ｄの処理を繰り返し実行する（ステップＳ３３−２Ｄ）。すなわち、プレイするモード及び楽曲が選択されるまで選択画面が表示される。なお、図示しないが、モードが選択された後、楽曲選択画面が表示される。そして、プレイが許可された場合（ステップＳ３３−２Ｄ：ＹＥＳ）、端末装置２０Ｄは、このユーザのプレイ情報をサーバ装置１０Ｄに送信する（ステップＳ３４−Ｄ）。本実施形態の例では、プレイ情報に対応付けて運営者の識別情報も送信される。運営者の識別情報は、事前に端末装置２０Ｄの記憶部に記憶しておけばよい。
【０１０３】
一方、サーバ装置１０Ｄは、端末装置２０Ｄからプレイ情報を受信するまで待機する（ステップＳ１０−Ｄ）。プレイ情報を受信した場合（ステップＳ１０−Ｄ：ＹＥＳ）、サーバ装置１０Ｄは、プレイ情報に基づいて、プレイが許可されたゲームモードが、第一モードであるか否かを判定する（ステップＳ１１−Ｄ）。
【０１０４】
第一モードである場合（ステップＳ１１−Ｄ：ＹＥＳ）、サーバ装置１０Ｄは、第１課金レートを用いて上記プレイ（プレイ情報）に対する運営者の課金額を算定する（ステップＳ１２−Ｄ）。一方、第二モードのである場合（ステップＳ１１−Ｄ：ＮＯ）、サーバ装置１０Ｄは、第２課金レートを用いて上記プレイ（プレイ情報）に対する運営者の課金額を算定する（ステップＳ１３−Ｄ）。
【０１０５】
その後、サーバ装置１０Ｄは、算定した課金額を、対応する運営者の累計金額に加算する（ステップＳ１４−Ｄ）。すなわち、運営者毎に所定の期間（例えば毎月末締め）で集計される。その後、サーバ装置１０Ｄは、ステップＳ１０−Ｄの処理に戻る。
【０１０６】
また、端末装置２０Ｄは、ステップＳ３４−Ｄの処理の実行後、プレイが許可されたゲームモードでの楽曲の進行制御を行う（ステップＳ３５−１Ｄ）。そして、プレイの終了後、端末装置２０Ｄは、ゲーム結果に基づいて、このユーザの履歴情報を更新し（ステップＳ３５−２Ｄ）、ステップＳ３０−Ｄの処理に戻る。履歴情報の更新は、上述したように、既存曲ＩＤの更新等が行われる。
【０１０７】
以上のように、第４の実施形態の一側面として、サーバ装置１０Ｄが、取得部１１Ｄ、算定部１２Ｄ及び配信制御部１５Ｄを備える構成としているので、プレイが許可されたゲームのコンテンツ（ゲームモード）に応じて課金額が異なってくる。すなわち、楽曲を新規状態から既存状態に変更するための課金額が高くなる。したがって、新規なコンテンツが配信された当初は課金額が高くなるため、配信される新たなゲームのコンテンツ等の制作コストをゲームメーカがより短期間で回収することができる。これによって、より短期間で新たなゲームのコンテンツ等を配信してユーザの継続的なプレイを維持することができる。
【０１０８】
また、コンテンツの状態が、ユーザ毎に設定されるので、ユーザの対価に基づく課金額をより正確に算定できる。
【０１０９】
なお、上述の実施形態の例では、第一モードの１回のプレイによって、現時点での新規状態の複数の楽曲の全てが、既存状態に変更されるが、特にこれに限定されるものではない。例えば、第一モードの１回ののプレイによって１又は所定数の新規状態の楽曲のみ既存状態に変更される構成としてもよい。この場合、既存状態に変更する楽曲をユーザが指定すればよい。
【０１１０】
上述の実施形態の例では、ゲームモードが、設定変更するコンテンツであったが、特にこれに限定されるものではない。例えば、ゲームモードの代わりに、新規状態の楽曲自体を設定変更のコンテンツとしてもよい。
【０１１１】
上述の実施形態の例では、運営者の識別情報を用いているが、上述の他の実施形態で説明したように、端末装置の識別情報を用いていもよい。
【０１１２】
また、上述の実施形態の例では、端末装置が、判定部、許可部、更新部及びゲーム進行制御部を備えているが、サーバ装置が判定部、許可部、更新部及びゲーム進行制御部の全部又は一部を備える構成としてもよい。
【０１１３】
さらに、上述の実施形態の例では、単一のサーバ装置が配信機能及び課金機能を備えていたが、機能ごとに複数のサーバ装置を設けてもよい。
【０１１４】
［第５の実施形態］
図１７は、ゲームシステム１００の構成の例であるゲームシステム１００Ｅの構成を示すブロック図である。本実施形態の例のゲームシステム１００Ｅは、サーバ装置１０Ｅと、複数の端末装置２０Ｅ，２０１Ｅ〜２０ＮＥ（Ｎは任意の整数）とを含む。サーバ装置１０Ｅと、ビデオゲームをプレイする複数のユーザ（プレイヤ）がそれぞれ使用する複数の端末装置２０Ｅ，２０１Ｅ〜２０ＮＥとは、それぞれインターネットなどの通信ネットワーク１５に接続されている。なお、ゲームシステム１００の構成はこれに限定されず、例えば単一の端末装置を複数のユーザが使用する構成としてもよいし、複数のサーバ装置を備える構成としてもよい。
【０１１５】
本実施形態の例のゲームシステム１００Ｅは、楽曲を再生するとともに操作入力を促す指示標識（ターゲット）を端末装置２０Ｅ，２０１Ｅ〜２０ＮＥの表示部に表示するリズムゲームを実行する各種機能を有する。また、本実施形態の例のゲームシステム１００Ｅは、リズムゲームの運営者に対する課金額を、ユーザが支払った対価に基づいて算定する各種機能を有する。本実施形態の例では、サーバ装置１０Ｅを管理する単一の運営者の課金額が算定される。
【０１１６】
リズムゲームは、第４の実施形態と同様に、第一モード及び第二モードがあり、新規状態の楽曲がある場合に第一モードをプレイできる。本実施形態の例では、ユーザは、例えば、クレジット決済を利用してゲーム内で使用する仮想チケットを購入できる（課金による購入）。そして、ユーザは、仮想チケット１枚を消費することで各モードを１回プレイできる。仮想チケットは、例えば、１００円／枚で購入できる。すなわち、本実施形態の例のゲームシステム１００Ｅは、ユーザが支払う対価としてサーバ側で課金を行うことでユーザのゲームのプレイを許可する各種機能を有する。
【０１１７】
サーバ装置１０Ｅは、リズムゲームの運営者によって管理され、ユーザの課金額、運営者の課金額を算定するための各種機能を有する。また、サーバ装置１０Ｅは、ユーザ端末２０Ｅ，２０１Ｅ〜２０ＮＥに対してリズムゲームを進行させる情報を提供するための各種の機能を有する。例えば、サーバ装置１０Ｅは、ユーザ端末２０Ｅ，２０１Ｅ〜２０ＮＥから操作情報を取得し、上記リズムゲームのゲーム画像の情報を提供する。この実施形態において、サーバ装置１０Ｅは、課金額び算定及びリズムゲームの進行を制御するべくＷＷＷサーバなどの情報処理装置によって構成され、各種情報を格納するデータベースを備える。
【０１１８】
本実施形態の例では、例えば、ゲームメーカから提供される新規の楽曲の情報がサーバ装置１０Ｅのデータベースに追加されることで、ユーザがプレイ可能となる。
【０１１９】
端末装置２０Ｅ，２０１Ｅ〜２０ＮＥは、スマートホン（スマートデバイス）である。端末装置２０Ｅ，２０１Ｅ〜２０ＮＥの記憶部には、本実施形態の例のリズムゲームを実行するためのソフトウェア（アプリケーションプログラム）が記憶されている。
【０１２０】
図１８は、サーバ装置１０の構成の例であるサーバ装置１０Ｅの構成を示す機能ブロック図である。サーバ装置１０Ｅは、制御部が記憶部に記憶されている課金プログラム及びゲーム処理プログラムを実行することで課金サーバ及びゲーム処理サーバとして機能するための取得部１１Ｅ、算定部１２Ｅ、判定部１３Ｅ、許可部１４Ｅ、更新部１６Ｅ及びゲーム進行制御部１７Ｅを少なくとも備える。
【０１２１】
取得部１１Ｅは、プレイが許可されたゲームモードが第一モードであるか否かに関する情報を含むプレイ情報を、端末装置２０Ｅ，２０１Ｅ〜２０Ｅから取得する。すなわち、取得部１１Ｅは、ユーザがチケットを消費してプレイするべく選択したゲームモードの情報を取得する。
【０１２２】
算定部１２Ｅは、プレイ情報を参照し、プレイの対価に基づいて運営者の課金額を算定する。本実施形態の例では、仮想チケットの消費に基づいて運営者の課金額が算定される。また、上述したように、プレイが許可されたゲームモードに応じた課金レートを用いて課金額が算定される。
【０１２３】
判定部１３Ｅは、ユーザの履歴情報に基づいて、リズムゲームの複数の楽曲の中で新規状態の楽曲があるか否かを判定する。ユーザの履歴情報は、例えば、図１４で例示した履歴情報である。履歴情報は、サーバ装置１０Ｅの記憶部で管理される。判定部１３Ｅは、ユーザの識別情報を、このユーザが使用する端末装置２０Ｅ，２０１Ｅ〜２０ＮＥから取得し、このユーザの識別情報に対応する履歴情報を記憶部から取得する。なお、ユーザの履歴情報は、端末装置２０Ｅ，２０１Ｅ〜２０ＮＥの記憶部に予め記憶しておいてもよく、またユーザが都度、入力してもよい。判定部１３Ｅは、第４の実施形態と同様に、例えば、履歴情報の既存曲ＩＤと、図１５に示すような楽曲リストとを比較することで、新規状態の楽曲の有無を判定する。なお、楽曲リストは、サーバ装置１０Ｅの記憶部に記憶しておけばよい。
【０１２４】
許可部１４Ｅは、新規状態のコンテンツがあると判定された場合、第一モードをユーザに選択可能にさせる情報（許可情報）を設定する。更新部１６Ｅは、第４の実施形態と同様に、ユーザのリズムゲームのプレイ結果に応じて、ユーザの履歴情報を更新する。ゲーム進行制御部１７Ｅは、ユーザのチケット消費に基づいてゲームの進行を制御する。
【０１２５】
図１９は、端末装置２０の構成の例である端末装置２０Ｅの構成を示す機能ブロック図である。なお、端末装置２０１Ｅ〜２０ＮＥについても同様の構成である。端末装置２０Ｅは、情報送信部２６Ｅ及び表示制御部２７Ｅを少なくとも備える。
【０１２６】
情報送信部２６Ｅは、端末装置２０Ｅの操作部におけるユーザの操作情報、ユーザの識別情報等をサーバ装置１０Ｅに送信する。表示制御部２７Ｅは、サーバ装置１０Ｅから受信するゲーム画像を生成するための情報（画像情報）に基づいてゲーム画像を表示部に表示する。
【０１２７】
図２０は、システム１００が実行するゲームの進行処理の例を示すフローチャートである。本実施形態の例における進行処理では、リズムゲームを進行させるための処理が行われるとともに、ゲームの運営者の課金額を算定するための処理（課金処理）が行われる。なお、図２０においては、主として、運営者の課金処理に関連する処理のみを説明し、その他の処理は省略する。以下、サーバ装置１０Ｅと端末装置２０Ｅとが進行処理を実行する場合を例にして説明する。
【０１２８】
本実施形態の例の進行処理は、例えばサーバ装置１０Ｅ及び端末装置２０Ｅの起動中に実施される。
【０１２９】
進行処理において、端末装置２０Ｅは、ユーザの識別情報を取得するまで待機する（ステップＳ２５−Ｅ）。端末装置２０Ｅは、例えば、ユーザが仮想チケットを使用する操作を行ったことを条件として、記憶部からユーザの識別情報を読み出す。ユーザの識別情報を取得した場合（ステップＳ２５−Ｅ：ＹＥＳ）、端末装置２０Ｅは、サーバ装置１０Ｅにユーザの識別情報を送信し（Ｓ２６−Ｅ）、サーバ装置１０Ｅからの応答を待つ。
【０１３０】
サーバ装置１０Ｅは、ユーザの識別情報を受信するまで待機する（ステップＳ５−Ｅ）。ユーザの識別情報を受信した場合（ステップＳ５−Ｅ：ＹＥＳ）、サーバ装置１０Ｅは、リズムゲームの複数の楽曲のうち、新規状態にある楽曲の有無を判定する（ステップＳ６−Ｅ）。上述したように、ユーザの識別情報に対応する履歴情報及び楽曲リストに基づいて、新規状態の楽曲の有無が判定される。
【０１３１】
次に、サーバ装置１０Ｅは、判定結果に基づく設定を行う（ステップＳ７−１Ｅ）。具体的には、新規状態のコンテンツがある場合、サーバ装置１０Ｅは、第一モードをユーザに選択可能にさせる情報（許可情報）を設定する。一方、新規状態の楽曲がない場合、サーバ装置１０Ｅは、第一モードをユーザに選択不可にさせる情報（不許可情報）を設定する。そして、サーバ装置１０Ｅは、設定に基づく選択画面の情報を、ユーザの識別情報を送信した端末装置２０Ｅに送信する（ステップＳ７−２Ｅ）。具体的には、図１１に示すようなゲームモードの選択画面を端末装置２０Ｅに表示させるための画像情報を送信する。なお、第一モードの選択不可の場合には、第一モードが非表示となる画像情報が送信される。
【０１３２】
端末装置２０Ｅは、画像情報に基づいて、端末装置２０Ｅの表示部にゲームモードの選択画面を表示する（ステップＳ３３−１Ｅ）。その後、端末装置２０Ｅは、ゲームのプレイが許可されるまでＳ３３−１Ｅの処理を繰り返し実行する（ステップＳ３３−２Ｅ）。すなわち、プレイするモード及び楽曲が選択されるまで選択画面が表示される。そして、プレイが許可された場合（ステップＳ３３−２Ｅ：ＹＥＳ）、端末装置２０Ｅは、このユーザのプレイ情報をサーバ装置１０Ｅに送信する（ステップＳ３４−Ｅ）。
【０１３３】
一方、サーバ装置１０Ｅは、端末装置２０Ｅからプレイ情報を受信するまで待機する（ステップＳ１０−Ｅ）。プレイ情報を受信した場合（ステップＳ１０−Ｅ：ＹＥＳ）、サーバ装置１０Ｅは、プレイ情報に基づいて、プレイが許可されたゲームモードが、第一モードであるか否かを判定する（ステップＳ１１−Ｅ）。
【０１３４】
第一モードである場合（ステップＳ１１−Ｅ：ＹＥＳ）、サーバ装置１０Ｅは、第１課金レートを用いて上記プレイ（プレイ情報）に対する運営者の課金額を算定する（ステップＳ１２−Ｅ）。一方、第二モードのである場合（ステップＳ１１−Ｅ：ＮＯ）、サーバ装置１０Ｅは、第２課金レートを用いて上記プレイ（プレイ情報）に対する運営者の課金額を算定する（ステップＳ１３−Ｅ）。
【０１３５】
その後、サーバ装置１０Ｅは、算定した課金額を、運営者の累計金額に加算する（ステップＳ１４−Ｅ）。すなわち、所定の期間（例えば毎月末締め）で集計される。その後、サーバ装置１０Ｅは、プレイが許可されたゲームモードでの楽曲の楽曲の進行制御を行う（ステップＳ１５−Ｅ）。そして、プレイの終了後、サーバ装置１０Ｅは、ゲーム結果に基づいて、このユーザの履歴情報を更新し（ステップＳ１６−Ｅ）、ステップＳ５−Ｅの処理に戻る。履歴情報の更新は、上述したように、既存曲ＩＤ及び保有する仮想チケットの更新等が行われる。
【０１３６】
一方、端末装置２０Ｅは、ゲームプレイ中、サーバ装置１０Ｅから画像情報等を受信してプレイ画面（ゲーム画像）を表示部に表示し（ステップＳ３６−Ｅ）、プレイ終了後にステップＳ２５−Ｅの処理に戻る。
【０１３７】
以上のように、第５の実施形態の一側面として、サーバ装置１０Ｅが、取得部１１Ｅ、算定部１２Ｅ、判定部１３Ｅ、許可部１４Ｅ、更新部１６Ｅ及びゲーム進行制御部１７Ｅを備える構成としているので、プレイが許可されたゲームのコンテンツ（ゲームモード）に応じて課金額が異なってくる。すなわち、楽曲を新規状態から既存状態に変更するための課金額が高くなる。したがって、新規なコンテンツが配信された当初は課金額が高くなるため、配信される新たなゲームのコンテンツ等の制作コストをゲームメーカがより短期間で回収することができる。これによって、より短期間で新たなゲームのコンテンツ等を配信してユーザの継続的なプレイを維持することができる。
【０１３８】
また、コンテンツの状態が、ユーザ毎に設定されるので、ユーザの対価に基づく課金額をより正確に算定できる。
【０１３９】
なお、上述の実施形態の例では、単一の運営者について説明しているが、第４の実施形態と同様に、複数の運営者のそれぞれに対する課金額の算定を行う構成を適用してもよい。
【０１４０】
また、上述の実施形態の例では、単一のサーバ装置がゲーム進行処理機能及び課金機能を備えていたが、機能ごとに複数のサーバ装置を設けてもよい。
【０１４１】
［第６の実施形態］
図２１は、ゲームシステム１００の構成の例であるゲームシステム１００Ｆの構成を示すブロック図である。本実施形態の例のゲームシステム１００Ｆは、サーバ装置１０Ｅと、複数の端末装置２０Ｆ，２０１Ｆ〜２０ＮＦ（Ｎは任意の整数）とを含む。サーバ装置１０Ｅと、ビデオゲームをプレイする複数のユーザ（プレイヤ）がそれぞれ使用する複数の端末装置２０Ｆ，２０１Ｆ〜２０ＮＦとは、それぞれインターネットなどの通信ネットワーク１５に接続されている。なお、ゲームシステム１００の構成はこれに限定されず、例えば単一の端末装置を複数のユーザが使用する構成としてもよいし、複数のサーバ装置を備える構成としてもよい。
【０１４２】
本実施形態の例のゲームシステム１００Ｆは、例えば、楽曲を再生するとともに操作入力を促す指示標識（ターゲット）を端末装置２０Ｆ，２０１Ｆ〜２０ＮＦの表示部に表示するリズムゲームを実行する各種機能を有する。また、本実施形態の例のゲームシステム１００Ｆは、リズムゲームの運営者に対する課金額を、ユーザが支払った対価に基づいて算定する各種機能を有する。
【０１４３】
サーバ装置１０Ｆは、運営者に課金を行うゲームメーカの管理者によって管理され、運営者の課金額を算定するための各種機能を有する。また、サーバ装置１０Ｆは、楽曲（コンテンツ）等の新たなコンテンツを端末装置２０Ｆ，２０１Ｆ〜２０ＮＦに配信するための各種機能を有する。この実施形態において、サーバ装置１０えは、課金額の算定及びコンテンツの配信をするべくＷＷＷサーバなどの情報処理装置によって構成され、各種情報を格納するデータベースを備える。
【０１４４】
端末装置２０Ｆ，２０１Ｆ〜２０ＮＦは、店舗（施設）に設置された業務用のゲーム装置であり、各店舗の運営者によって管理される。端末装置２０Ｆ，２０１Ｆ〜２０ＮＦの記憶部には、本実施形態の例のリズムゲームの進行を制御するとともに、ユーザのゲームのプレイ情報をサーバ装置１０Ｄに送信するためのソフトウェア（プログラム）が記憶されている。ユーザは、端末装置２０Ｆ，２０１Ｆ〜２０ＮＦにおいて対価を支払うことでゲームのプレイが可能となる。各店舗の端末装置２０Ｆ，２０１Ｆ〜２０ＮＦは、各店舗に設置された通信装置４０Ｄ，４０１Ｄ，４０ｎＤ（ｎは任意の整数）を介して通信ネットワーク１５に接続されている。本実施形態の例では、端末装置２０Ｆ，２０１Ｆ〜２０ＮＦを管理する店舗の運営者が、リズムゲームの運営者である。
【０１４５】
本実施形態の例のリズムゲームでは，対価（例えば、１００円）を支払って所定数（例えば３曲）の楽曲をプレイ可能である。ユーザがプレイ可能な楽曲には、既存楽曲、追加楽曲（レギュラー）、追加楽曲（エキストラ）の３種類がある。既存楽曲は、リズムゲームの提供開始当初から既に存在する楽曲等の新規に追加された楽曲ではない楽曲である。既存楽曲は、対価の支払いがプレイ条件となる。追加楽曲（レギュラー）は、新たに配信（追加）された楽曲である。追加楽曲（レギュラー）は、対価の支払いがプレイ条件となる。追加楽曲（エキストラ）は、追加楽曲（レギュラー）と同様、新たに配信（追加）された楽曲であるが、プレイ条件が異なる。追加楽曲（エキストラ）は、対価の支払い及びＩＣカード（ユーザの履歴情報）の利用がプレイ条件となる。ＩＣカードは、ユーザが所有する可搬型の記憶装置（記憶部）であり、ユーザの履歴情報が記憶されている。
【０１４６】
また、追加楽曲（エキストラ）は、新規状態（第一状態）を示す未プレイ状態と既存状態（第二状態）を示す既プレイ状態とに区別される。未プレイ状態は、ユーザが未だプレイしていない状態を意味する。既プレイ状態は、ユーザが既にプレイした状態を意味する。追加楽曲（エキストラ：未プレイ）は、ユーザが一度プレイした後は、そのユーザに対しては追加楽曲（エキストラ：既プレイ）に状態が設定変更される。すなわち、追加楽曲（エキストラ）は、同じ楽曲でも各ユーザに応じて状態が異なる。
【０１４７】
上記楽曲の選択は、選択画面が表示された状態において行われる。選択画面では、各楽曲に対応する選択肢の画像が表示される。ユーザは、端末装置２０Ｆの操作部を操作して選択肢を選択することでプレイしたい楽曲を選択できる。本実施形態の例では、既存楽曲、追加楽曲（レギュラー）、追加楽曲（エキストラ：未プレイ）、追加楽曲（エキストラ：既プレイ）で、選択肢の画像の表示態様が異なる。
【０１４８】
図２２は、ゲーム画像（選択画面）の一例を示す図である。図２２（Ａ）及び図２２（Ｃ）は、ＩＣカードを利用しているユーザの選択画面の一例を示す。図２２（Ｂ）は、ＩＣカードを利用していないユーザの選択画面の一例を示す。図２２（Ａ）に示すように、追加楽曲（レギュラー）に対応する選択肢５２には、楽曲の名称に加えて「ＮＥＷ」の文字が表示される。追加楽曲（エキストラ：未プレイ）に対応する選択肢５３，５４には、楽曲の名称に加えて「ＥＸＴＲＡ」の文字が表示される。一方、既存楽曲に対応する選択肢５０及び追加楽曲（エキストラ：既プレイ）に対応する選択肢５１には、楽曲の名称が表示されるのみである。これにより、ユーザは、追加楽曲（レギュラー）及び追加楽曲（エキストラ：未プレイ）を特定することができる。
【０１４９】
なお、ユーザがＩＣカードを利用していない場合、図２２（Ｂ）に示すように、追加楽曲（エキストラ：既プレイ）に対応する選択肢５１及び追加楽曲（エキストラ：未プレイ）に対応する選択肢５３，５４は、ブラックアウトして表示され、ユーザが選択できない状態となっている。なお、追加楽曲（レギュラー）は選択可能である。
【０１５０】
また、例えば、図２２（Ａ）に示す状態において、選択肢５４に対応する追加楽曲（エキストラ：未プレイ）をユーザがプレイした場合、この追加楽曲（エキストラ：未プレイ）は、追加楽曲（エキストラ：既プレイ）となって、選択肢５４は図２２（Ｃ）に示すように「ＥＸＴＲＡ」の表示がなくなる（表示態様が変化する）。
【０１５１】
なお、追加楽曲（レギュラー）及び追加楽曲（エキストラ)は、例えば、新規に追加された後、所定期間が経過後に既存楽曲に変更される構成としてもよい。この場合、端末装置２０Ｅ又はサーバ装置１０Ｆが楽曲の種別（図２６参照）を変更すればよい。
【０１５２】
本実施形態の例では、上述したように、対価の支払いによって所定数（例えば３曲）の楽曲のプレイが許可される。そして、許可された楽曲に、追加楽曲（エキストラ：未プレイ）が含まれている場合、この追加楽曲（エキストラ：未プレイ）は追加楽曲（エキストラ：既プレイ）に状態が設定変更される。なお、本実施形態の例では、いずれの種別の楽曲であっても同一の対価でプレイできる楽曲数は同じである。
【０１５３】
本実施形態の例では、プレイが許可された楽曲に追加楽曲（エキストラ：未プレイ）である場合、第１課金レートを用いて上記プレイの課金額が算定される。また、本実施形態の例では、プレイが許可された所定数の楽曲のうち１曲でも追加楽曲（エキストラ：未プレイ）が含まれる場合は、第１課金レートが用いられる。一方、プレイが許可された所定数の楽曲が、既存楽曲、追加楽曲（レギュラー）及び追加楽曲（エキストラ：既プレイ）のいずれかである場合、第２課金レートを用いて上記プレイの課金額が算定される。第二課金レートは、第一課金レートよりも低いレートが設定されている。例えば、第１課金レート：７５％、第２課金レート：１５％が設定される。第一課金レートを用いた場合、上記ユーザのプレイに対する課金額は、対価１００円の７５％にあたる７５円となる。そして、残りの２５円が運営者の売り上げとなる。
【０１５４】
したがって、追加楽曲（エキストラ：未プレイ）は、「設定変更するコンテンツ」にも該当する。なお、本実施形態の例では、サーバ装置１０Ｆが、ユーザのプレイに対して個々に算定した課金額を運営者毎に所定の期間（例えば毎月末締め）で集計し、集計した課金額（累計金額）をレポート（ゲームメーカーから運営者へ発行されるロイヤリティレポートや請求書等）として作成して出力する。すなわち、運営者が管理する端末装置で許可されたプレイの対価に基づいてのみ、この運営者の課金額が算定される。なお、レポートは、サーバ装置１０Ｆから各運営者に直接送信してもよい。
【０１５５】
なお、本実施形態の例では、プレイが許可された所定数の楽曲のうち１曲でも追加楽曲（エキストラ：未プレイ）が含まれる場合は、第１課金レートが用いられるが、特にこれに限定されるものではない。例えば、プレイが許可された追加楽曲（エキストラ：未プレイ）の楽曲数に応じた第１課金レートを用いてもよい。例えば、楽曲数：３の場合は第１課金レート：７５％、楽曲数：２の場合は第１課金レート：５５％、楽曲数：１の場合は第１課金レート：３５％とする。
【０１５６】
図２３は、サーバ装置１０の構成の例であるサーバ装置１０Ｆの構成を示す機能ブロック図である。サーバ装置１０Ｆは、制御部が記憶部に記憶されている課金プログラム及び配信プログラムを実行することで課金サーバ及び配信サーバとして機能するための取得部１１Ｆ、算定部１２Ｆ及び配信制御部１５Ｆを少なくとも備える。
【０１５７】
取得部１１Ｆは、プレイが許可された楽曲に追加楽曲（エキストラ：未プレイ）が含まれるか否かに関する情報を含むプレイ情報を、端末装置２０Ｆ，２０１Ｆ〜２０ＮＦから取得する。プレイ情報は、運営者の識別情報とともに取得する。
【０１５８】
算定部１２Ｆは、プレイ情報を参照し、プレイの対価に基づいて各運営者の課金額を算定する。具体的には、プレイ情報とともに取得した運営者の識別情報毎に課金額を算定する。また、上述したように、プレイが許可された楽曲に応じた課金レートを用いて課金額が算定される。
【０１５９】
配信制御部１５Ｆは、サーバ装置１０Ｆのデータベース（記憶部）に記憶されている楽曲を端末装置２０Ｆ，２０１Ｆ〜２０ＮＦに配信する。すなわち、配信制御部１５Ｆは、新規に追加された楽曲（追加楽曲）のデータ等を端末装置２０Ｆ，２０１Ｆ〜２０ＮＦに送信する。なお、楽曲等のコンテンツの配信は、一般的な構成であるので詳細な説明は省略する。
【０１６０】
図２４は、端末装置２０の構成の例である端末装置２０Ｆの構成を示す機能ブロック図である。なお、端末装置２０１Ｆ〜２０ＮＦについても同様の構成である。端末装置２０Ｆは、判定部２１Ｆ、許可部２２Ｆ、更新部２３Ｆ、読取部２４Ｆ及びゲーム進行制御部２５Ｆを少なくとも備える。
【０１６１】
判定部２１Ｆは、ユーザの履歴情報に基づいて、端末装置２０Ｅにおいてプレイ可能な複数の楽曲の中で追加楽曲（エキストラ：未プレイ）があるか否かを判定する。なお、判定部２１Ｆは、ユーザの履歴情報が記憶されているＩＣカードの利用がない場合は、判定を行わない。ユーザの履歴情報は、図２５に示すように、ユーザのリズムゲームのプレイ履歴を含む履歴情報である。読取部２４Ｆが、ユーザのＩＣカードから履歴情報を読み出す。
【０１６２】
図２５に示すように、履歴情報は、ユーザＩＤに対応付けて、ランク、名称、ＥＸ既プレイ曲ＩＤ等が設定されている。ユーザＩＤは、ユーザの識別情報である。ランクは、ユーザのリズムゲームにおけるレベルを示す。名称は、ユーザのリズムゲーム内での名称を示す。ＥＸ既プレイ曲ＩＤは、このユーザ（ユーザＩＤ）に対する追加楽曲（エキストラ：既プレイ）を特定する情報（リスト）であり、楽曲の識別情報（楽曲ＩＤ）が設定される。ＥＸ既プレイ曲ＩＤは、ユーザの追加楽曲（エキストラ：未プレイ）のプレイ状況に応じて変化することとなり、ユーザ毎に異なってくる。
【０１６３】
判定部２１Ｆは、例えば、履歴情報のＥＸ既プレイ曲ＩＤと、図２６に示すような楽曲リストとを比較することで、追加楽曲（エキストラ：未プレイ）の有無を判定する。楽曲リストは、端末装置２０Ｆでプレイ可能な楽曲の一覧であり、端末装置２０Ｆの記憶部に記憶されている。判定部２１Ｆは、楽曲リスト中に、履歴情報のＥＸ既プレイ曲ＩＤに一致しない楽曲ＩＤが存在する場合、追加楽曲（エキストラ：未プレイ）があると判定する。
【０１６４】
楽曲リストは、楽曲ＩＤに対応付けて、種別、譜面データ、再生ファイル等が設定されている。種別は、上述したように、楽曲の種別を特定する情報が設定される。すなわち、種別の情報によって、楽曲（楽曲ＩＤ）が、既存楽曲、追加楽曲（レギュラー）、追加楽曲（エキストラ）であるかが特定される。例えば、種別０１：既存楽曲、種別０２：追加楽曲（レギュラー）、種別０３：追加楽曲（エキストラ）となる。なお、端末装置２０Ｆは、楽曲リストの種別を設定変更することで、追加楽曲を既存楽曲に変更可能である。
【０１６５】
譜面データは、リズムゲームにおける指示標識の表示開始タイミング、ユーザが操作すべきタイミングを特定する情報等が設定される。再生ファイルは、対応する楽曲の再生ファイルの情報が設定される。
【０１６６】
許可部２２Ｆは、追加楽曲（エキストラ：未プレイ）があると判定された場合、追加楽曲（エキストラ：未プレイ）をユーザに選択可能にさせる情報を設定する。本実施形態の例では、許可部２２Ｆは、特定された追加楽曲（エキストラ：未プレイ）の楽曲ＩＤの情報を設定する（端末装置２０Ｆの記憶部に記憶する）。更新部２３Ｆは、ユーザのリズムゲームのプレイ結果に応じて、ユーザの履歴情報を更新する。すなわち、ユーザが所有するＩＣカードの履歴情報を更新する。例えば、或る追加楽曲（エキストラ：未プレイ）をプレイした場合、或る追加楽曲（エキストラ：未プレイ）の楽曲ＩＤがＥＸ既プレイ曲ＩＤとして追加設定される。なお、第４の実施形態のように解放条件を設定してもよい。また、ＩＣカードの利用がない場合は、履歴情報は更新されない。
【０１６７】
読取部２４Ｆは、例えば、ＩＣカードリーダであり、ユーザのＩＣカードの情報を読み取る。ゲーム進行制御部２５Ｆは、ユーザの対価の支払いに基づいてゲームの進行を制御する。本実施形態の例では、端末装置２０Ｆ単体でゲームの進行が制御される。
【０１６８】
図２７は、システム１００Ｆが実行するゲームの進行処理の例を示すフローチャートである。本実施形態の例における進行処理では、リズムゲームを進行させるための処理が行われるとともに、ゲームの運営者の課金額を算定するための処理（課金処理）が行われる。なお、図２７においては、主として、課金処理に関連する処理のみを説明し、その他の処理は省略する。以下、サーバ装置１０Ｆと端末装置２０Ｆとが進行処理を実行する場合を例にして説明する。
【０１６９】
本実施形態の例の進行処理は、例えばサーバ装置１０Ｆ及び端末装置２０Ｆの起動中に実施される。
【０１７０】
進行処理において、端末装置２０Ｆは、ＩＣカードの利用の有無を判断する（ステップＳ３０−１Ｆ）。例えば、ユーザは、対価を支払いとともに、端末装置２０Ｆの操作部を介してＩＣカードの利用意思を入力する。端末装置２０Ｆは、この入力に基づいて判断すればよい。あるいは、対価の支払い後の所定時間内にＩＣカードの読み取りが行われたか否かに基づいて利用有無を判断してもよい。利用のない場合（ステップＳ３０−１Ｆ：ＮＯ）、端末装置２０Ｆは、ステップＳ３３−１Ｆの処理に移行する。
【０１７１】
一方、利用される場合（ステップＳ３０−１Ｆ：ＹＥＳ）、端末装置２０Ｆは、履歴情報を取得するまで待機する（ステップＳ３０−２Ｆ）。端末装置２０Ｆは、ユーザの履歴情報がＩＣカードから読み取られるまで待機する。ユーザの履歴情報を取得した場合（ステップＳ３０−２Ｆ：ＹＥＳ）、端末装置２０Ｆは、リズムゲームの複数の楽曲のうち、追加楽曲（エキストラ：未プレイ）の有無を判定する（ステップＳ３１−Ｆ）。上述したように、ユーザの履歴情報及び楽曲リストに基づいて追加楽曲（エキストラ：未プレイ）の有無が判定される。
【０１７２】
次に、端末装置２０Ｆは、判定結果に基づく設定を行う（ステップＳ３２−Ｆ）。具体的には、追加楽曲（エキストラ：未プレイ）がある場合、端末装置２０Ｆは、追加楽曲（エキストラ：未プレイ）をユーザに選択可能にさせる情報を設定する。本実施形態の例では、ユーザの履歴情報に基づいて、楽曲リストのうち追加楽曲（エキストラ：未プレイ）に該当する楽曲（楽曲ＩＤ）の情報が設定される。一方、追加楽曲（エキストラ：未プレイ）がない場合、端末装置２０Ｆは、追加楽曲（エキストラ：未プレイ）に該当する楽曲（楽曲ＩＤ）の情報の設定は行わない。
【０１７３】
次に、端末装置２０Ｆは、ステップＳ３２−Ｆの処理での設定情報、ＩＣカードの利用有無及び楽曲リスト等に基づいて、端末装置２０Ｆの表示部に楽曲の選択画面を表示する（ステップＳ３３−１Ｆ）。具体的には、ＩＣカードの利用がない場合、図２２（Ｂ）に示すように、追加楽曲（エキストラ）の選択ができない表示形態で選択画面が表示される。また、ＩＣカードの利用がある場合、図２２（Ａ）、図２２（Ｃ）に示すように、追加楽曲が選択可能な表示形態で選択画面が表示される。
【０１７４】
その後、端末装置２０Ｆは、ゲームのプレイが許可されるまでＳ３３−１Ｆの処理を繰り返し実行する（ステップＳ３３−２Ｆ）。すなわち、プレイする所定数の楽曲が選択されるまで選択画面が表示される。そして、プレイが許可された場合（ステップＳ３３−２Ｆ：ＹＥＳ）、端末装置２０Ｆは、このユーザのプレイ情報をサーバ装置１０Ｆに送信する（ステップＳ３４−Ｆ）。例えば、プレイ情報には、プレイが許可された楽曲に追加楽曲（エキストラ：未プレイ）が含まれているか否かの情報が含まれる。あるいは、プレイが許可された追加楽曲（エキストラ：未プレイ）の楽曲数の情報でもよい。また、本実施形態の例では、プレイ情報に対応付けて運営者の識別情報も送信される。運営者の識別情報は、事前に端末装置２０Ｆの記憶部に記憶しておけばよい。
【０１７５】
一方、サーバ装置１０Ｆは、端末装置２０Ｆからプレイ情報を受信するまで待機する（ステップＳ１０−Ｆ）。プレイ情報を受信した場合（ステップＳ１０−Ｆ：ＹＥＳ）、サーバ装置１０Ｆは、プレイ情報に基づいて、プレイが許可された楽曲に追加楽曲（エキストラ：未プレイ）が含まれているか否かを判定する（ステップＳ１１−Ｆ）。
【０１７６】
追加楽曲（エキストラ：未プレイ）が含まれている場合（ステップＳ１１−Ｆ：ＹＥＳ）、サーバ装置１０Ｆは、第１課金レートを用いて上記プレイ（プレイ情報）に対する運営者の課金額を算定する（ステップＳ１２−Ｆ）。一方、追加楽曲（エキストラ：未プレイ）が含まれていない場合（ステップＳ１１−Ｆ：ＮＯ）、サーバ装置１０Ｆは、第２課金レートを用いて上記プレイ（プレイ情報）に対する運営者の課金額を算定する（ステップＳ１３−Ｆ）。
【０１７７】
その後、サーバ装置１０Ｆは、算定した課金額を、対応する運営者の累計金額に加算する（ステップＳ１４−Ｆ）。すなわち、運営者毎に所定の期間（例えば毎月末締め）で集計される。その後、サーバ装置１０Ｆは、ステップＳ１０−Ｆの処理に戻る。
【０１７８】
また、端末装置２０Ｆは、ステップＳ３４−Ｆの処理の実行後、プレイが許可された楽曲の進行制御を行う（ステップＳ３５−１Ｆ）。そして、プレイの終了後、端末装置２０Ｆは、ゲーム結果に基づいて、このユーザの履歴情報を更新し（ステップＳ３５−２Ｆ）、ステップＳ３０−１Ｆの処理に戻る。履歴情報の更新は、上述したように、ＥＸ既プレイ曲ＩＤの更新等が行われる。なお、ＩＣカードが利用されていない場合は、上記更新処理は実行されない。
【０１７９】
以上のように、第６の実施形態の一側面として、サーバ装置１０Ｆが、取得部１１Ｆ、算定部１２Ｆ及び配信制御部１５Ｆを備える構成としているので、プレイが許可されたゲームのコンテンツ（楽曲）に応じて課金額が異なってくる。すなわち、追加楽曲（エキストラ）を未プレイから既プレイの状態に変更するための課金額が高くなる。したがって、新規なコンテンツ（追加楽曲）が配信された当初は課金額が高くなるため、配信される新たなゲームのコンテンツ等の制作コストをゲームメーカがより短期間で回収することができる。これによって、より短期間で新たなゲームのコンテンツ等を配信してユーザの継続的なプレイを維持することができる。
【０１８０】
また、コンテンツ（追加楽曲（エキストラ）の状態が、ユーザ毎に設定されるので、ユーザの対価に基づく課金額をより正確に算定できる。
【０１８１】
上述の実施形態の例では、運営者の識別情報を用いているが、上述の他の実施形態で説明したように、端末装置の識別情報を用いていもよい。
【０１８２】
上述の実施形態の例では、端末装置が、判定部、許可部、更新部及びゲーム進行制御部を備えているが、サーバ装置が判定部、許可部、更新部及びゲーム進行制御部の全部又は一部を備える構成としてもよい。この場合、サーバ装置から、設定変更するコンテンツをユーザに選択可能にさせる情報として、追加楽曲（エキストラ：未プレイ）の楽曲ＩＤ等の情報を送信すればよい。
【０１８３】
上述の実施形態の例では、単一のサーバ装置が配信機能及び課金機能を備えていたが、機能ごとに複数のサーバ装置を設けてもよい。
【０１８４】
上述の実施形態の例では、ステップＳ３１−Ｆ，Ｓ３２−Ｆの処理を実行しているが、特に実行しなくてもよい。例えば、ステップＳ３０−２Ｆの処理の実行後、ＩＣカードの利用有無、ユーザの履歴情報及び楽曲リストに基づいて、直接的に選択画面を表示するようにしてもよい。
【０１８５】
上述の実施形態の例では、追加楽曲（レギュラー）が配信される構成であるが、追加楽曲（レギュラー）の配信は行わない構成としてもよい。
【０１８６】
上述の実施形態の例では、ＩＣカードを利用する場合に追加楽曲（エキストラ）をプレイできる構成であるが、特にこれに限定されるものではない。例えば、サーバ装置が、ユーザの履歴情報を記憶する構成であればＩＣカードはなくてもよい。
【０１８７】
［付記］
上述した実施形態の説明は、少なくとも下記発明を、当該発明の属する分野における通常の知識を有する者がその実施をすることができるように記載した。
【０１８８】
[１]
対価を支払ったユーザにゲームのプレイが許可されるゲーム装置と通信ネットワークにより接続されるサーバ装置に、前記ゲームの運営者に対する課金額を前記対価に基づいて算定させるための課金プログラムであって、
前記サーバ装置に、
前記プレイが許可されたゲームのコンテンツが、第一状態の所定のコンテンツを第二状態に設定変更するコンテンツであるか否かに関する情報を含むプレイ情報を、該ゲーム装置から取得する取得機能、
前記設定変更するコンテンツである場合、第１課金レートを用いて前記プレイの前記課金額を算定し、前記設定変更するコンテンツでない場合、前記第１課金レートよりも低いレートの第２課金レートを用いて前記プレイの前記課金額を算定する算定機能、
を実現させるための課金プログラム。
【０１８９】
［２］
前記サーバ装置に、さらに、
前記ユーザの識別情報を前記ゲーム装置から取得し、記憶部に記憶されている該ユーザの前記ゲームのプレイ履歴を含む履歴情報に基づいて、前記ゲームの複数のコンテンツにおける第一状態のコンテンツの有無を判定する判定機能、
前記第一状態のコンテンツがあると判定された場合、前記設定変更するコンテンツを前記ユーザに選択可能にさせる情報をゲーム装置に送信する許可機能、
を実現させるための［１］に記載の課金プログラム。
【０１９０】
［３］
前記ゲームは、楽曲を再生するとともに操作入力を促す指示標識を前記ゲーム装置の表示部に表示するリズムゲームであり、
前記コンテンツは、前記楽曲である［１］又は［２］に記載の課金プログラム。
【０１９１】
［４］
前記第一状態のコンテンツは、前記ゲーム装置でプレイ可能に新規に追加され、且つ、前記設定変更するコンテンツのプレイによって第二状態に設定変更される前の状態のコンテンツである［１］〜［３］のいずれかに記載の課金プログラム。
【０１９２】
［５］
前記取得機能では、前記ゲーム装置から、前記ゲーム装置自体の識別情報又は／及び前記運営者の識別情報も取得する機能、
前記算定機能では、前記ゲーム装置自体の識別情報又は前記運営者の識別情報に基づいて、前記運営者毎に前記課金額を算定する機能、
を実現させるための［１］〜［４］のいずれかに記載の課金プログラム。
【０１９３】
［６］
対価を支払ったユーザにゲームのプレイが許可されるゲーム装置と通信ネットワークにより接続され、前記ゲームの運営者に対する課金額を前記対価に基づいて算定するサーバ装置であって、
前記プレイが許可されたゲームのコンテンツが、第一状態の所定のコンテンツを第二状態に設定変更するコンテンツであるか否かに関する情報を含むプレイ情報を、該ゲーム装置から取得する取得手段、
前記設定変更するコンテンツである場合、第１課金レートを用いて前記プレイの前記課金額を算定し、前記設定変更するコンテンツでない場合、前記第１課金レートよりも低いレートの第２課金レートを用いて前記プレイの前記課金額を算定する算定手段、
を含むサーバ装置。
【０１９４】
［７］
通信ネットワークによりサーバ装置に接続され、対価を支払ったユーザにゲームのプレイを許可するゲーム装置のゲームプログラムであって、
前記ゲーム装置に、
前記ゲームの運営者に対する課金額を前記対価に基づいて算定するサーバ装置であって、前記プレイが許可されたゲームのコンテンツが第一状態の所定のコンテンツを第二状態に設定変更するコンテンツである場合、第１課金レートを用いて前記プレイの前記課金額を算定し、前記許可されたゲームのコンテンツが前記設定変更するコンテンツでない場合、前記第１課金レートよりも低いレートの第２課金レートを用いて前記プレイの前記課金額を算定するサーバ装置に、前記プレイが許可されたゲームのコンテンツが、第一状態の所定のコンテンツを第二状態に設定変更するコンテンツであるか否かに関する情報を含むプレイ情報を送信する送信機能、
を実現させるためのゲームプログラム。
【０１９５】
［８］
対価を支払ったユーザにゲームのプレイが許可されるゲーム装置と、前記ゲーム装置と通信ネットワークにより接続されるサーバ装置とを備え、前記ゲームの運営者に対する課金額を前記対価に基づいて算定するゲームシステムであって、
記憶部に記憶されている前記ユーザの前記ゲームのプレイ履歴を含む履歴情報に基づいて、前記ゲームの複数のコンテンツにおける第一状態のコンテンツの有無を判定する判定手段、
前記第一状態のコンテンツがあると判定された場合、第一状態のコンテンツを第二状態に設定変更するコンテンツを前記ユーザに選択可能にさせる許可手段、
前記ゲームのプレイ結果に応じて前記履歴情報を更新する更新手段、
前記プレイが許可されたゲームのコンテンツが、前記設定変更するコンテンツである場合、第１課金レートを用いて前記プレイの前記課金額を算定し、前記設定変更するコンテンツでない場合、前記第１課金レートよりも低いレートの第２課金レートを用いて前記プレイの前記課金額を算定する算定手段、
を含む、ゲームシステム。
【０１９６】
［９］
前記ゲームは、楽曲を再生するとともに操作入力を促す指示標識を前記ゲーム装置の表示部に表示するリズムゲームであり、
前記コンテンツは、前記楽曲である［８］に記載のゲームシステム。
【０１９７】
［１０］
前記第一状態のコンテンツは、前記ゲーム装置でプレイ可能に新規に追加され、且つ、前記設定変更するコンテンツのプレイによって第２状態に設定変更される前の状態のコンテンツである［８］又は［９］に記載のゲームシステム。
【０１９８】
［１１］
前記算定手段は、前記ゲーム装置の識別情報又は／及び前記運営者の識別情報に基づいて、前記運営者毎に前記課金額を算定する、
を実現させるための［８］〜［１０］のいずれかに記載のゲームシステム。
【０１９９】
［１２］
前記サーバ装置が、前記算定手段を含み、
前記ゲーム装置が、前記判定手段、前記許可手段及び前記更新手段を含む、
［８］〜［１１］のいずれかに記載のゲームシステム。
【０２００】
［１３］
対価を支払ったユーザにゲームのプレイが許可されるゲーム装置と通信ネットワークにより接続されるサーバ装置に、前記ゲームの運営者に対する課金額を前記対価に基づいて算定させる課金方法であって、
前記プレイが許可されたゲームのコンテンツが、第一状態の所定のコンテンツを第二状態に設定変更するコンテンツであるか否かに関する情報を含むプレイ情報を、該ゲーム装置から取得する取得処理、
前記設定変更するコンテンツである場合、第１課金レートを用いて前記プレイの前記課金額を算定し、前記設定変更するコンテンツでない場合、前記第１課金レートよりも低いレートの第２課金レートを用いて前記プレイの前記課金額を算定する算定処理、
を含む課金方法。
【０２０１】
［１４］
対価を支払ったユーザにゲームのプレイが許可されるゲーム装置と、前記ゲーム装置と通信ネットワークにより接続されるサーバ装置とを備え、前記ゲームの運営者に対する課金額を前記対価に基づいて算定するゲームシステムが実行するビデオゲーム処理方法であって、
記憶部に記憶されている前記ユーザの前記ゲームのプレイ履歴を含む履歴情報に基づいて、前記ゲームの複数のコンテンツにおける第一状態のコンテンツの有無を判定する判定処理、
前記第一状態のコンテンツがあると判定された場合、第一状態のコンテンツを第二状態に設定変更するコンテンツを前記ユーザに選択可能にさせる許可処理、
前記ゲームのプレイ結果に応じて前記履歴情報を更新する更新処理、
前記プレイが許可されたゲームのコンテンツが、前記設定変更するコンテンツである場合、第１課金レートを用いて前記プレイの前記課金額を算定し、前記設定変更するコンテンツでない場合、前記第１課金レートよりも低いレートの第２課金レートを用いて前記プレイの前記課金額を算定する算定処理、
を含む、ビデオゲーム処理方法。
【産業上の利用可能性】
【０２０２】
本発明の実施形態の一つによれば、より短期間で新たなゲームコンテンツ等を配信してユーザの継続的なプレイを維持するのに有用である。
【符号の説明】
【０２０３】
１０    サーバ装置
２０，２０１〜２０Ｎ    端末装置
１１    取得部
１２    算定部
１３，２１    判定部
１４，２２    許可部
１５    配信制御部
１６，２３    更新部
２４    読取部
１７，２５    ゲーム進行制御部
２６    情報送信部
２７    表示制御部
１００    ゲームシステム
【図１】
2019080741.tif 000003
【図２】
2019080741.tif 000004
【図３】
2019080741.tif 000005
【図４】
2019080741.tif 000006
【図５】
2019080741.tif 000007
【図６】
2019080741.tif 000008
【図７】
2019080741.tif 000009
【図８】
2019080741.tif 000010
【図９】
2019080741.tif 000011
【図１０】
2019080741.tif 000012
【図１１】
2019080741.tif 000013
【図１２】
2019080741.tif 000014
【図１３】
2019080741.tif 000015
【図１４】
2019080741.tif 000016
【図１５】
2019080741.tif 000017
【図１６】
2019080741.tif 000018
【図１７】
2019080741.tif 000019
【図１８】
2019080741.tif 000020
【図１９】
2019080741.tif 000021
【図２０】
2019080741.tif 000022
【図２１】
2019080741.tif 000023
【図２２】
2019080741.tif 000024
【図２３】
2019080741.tif 000025
【図２４】
2019080741.tif 000026
【図２５】
2019080741.tif 000027
【図２６】
2019080741.tif 000028
【図２７】
2019080741.tif 000029
【手続補正書】
【提出日】平成30年11月28日(2018.11.28)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
対価を支払ったユーザにプレイを許可したゲームを実行するゲーム装置と通信ネットワークにより接続されるサーバ装置に、前記ゲームの運営者に対する課金額を前記対価に基づいて算定させるための課金プログラムであって、
前記サーバ装置に、
前記プレイが許可されたゲームのコンテンツが、該ゲームの新規状態の所定のコンテンツを既存状態に設定変更するコンテンツであるか否かに関する情報を含むプレイ情報を、該ゲーム装置から取得する取得機能、
前記設定変更するコンテンツである場合、第１課金レートを用いて前記プレイの前記課金額を算定し、前記設定変更するコンテンツでない場合、前記第１課金レートよりも低いレートの第２課金レートを用いて前記プレイの前記課金額を算定する算定機能、
を実現させるための課金プログラム。
【請求項２】
前記サーバ装置に、さらに、
前記ユーザの識別情報を前記ゲーム装置から取得し、該ユーザの識別情報に対応する履歴情報であって記憶部に記憶されている該ユーザの前記ゲームのプレイ履歴を含む履歴情報に基づいて、前記ゲームの複数のコンテンツにおける前記新規状態の所定のコンテンツの有無を判定する判定機能、
前記新規状態の所定のコンテンツがあると判定された場合、前記設定変更するコンテンツを前記ユーザがプレイ可能であることを示す情報をゲーム装置に送信する許可機能、
を実現させるための請求項１に記載の課金プログラム。
【請求項３】
前記ゲームは、楽曲を再生するとともに操作入力を促す指示標識を前記ゲーム装置の表示部に表示するリズムゲームであり、
前記コンテンツは、前記楽曲である請求項１又は２に記載の課金プログラム。
【請求項４】
前記ゲームのコンテンツには、ユーザがプレイ可能な第一モード及び該第一モードとは異なる第二モードの二種類のゲームモードが含まれ、
前記設定変更するコンテンツは前記第一モードであり、前記所定のコンテンツは前記ゲームモードとは異なるコンテンツである、請求項１〜３のいずれかに記載の課金プログラム。
【請求項５】
前記取得機能では、前記ゲーム装置から、前記ゲーム装置自体の識別情報又は／及び前記運営者の識別情報も取得する機能、
前記算定機能では、前記ゲーム装置自体の識別情報又は前記運営者の識別情報に基づいて、前記運営者毎に前記課金額を算定する機能、
を実現させるための請求項１〜４のいずれかに記載の課金プログラム。
【請求項６】
通信ネットワークによりサーバ装置に接続され、対価を支払ったユーザにプレイを許可したゲームを実行するゲーム装置のゲームプログラムであって、
前記ゲーム装置に、
前記ゲームの運営者に対する課金額を前記対価に基づいて算定するサーバ装置であって、前記プレイが許可されたゲームのコンテンツが該ゲームの新規状態の所定のコンテンツを既存状態に設定変更するコンテンツである場合、第１課金レートを用いて前記プレイの前記課金額を算定し、前記許可されたゲームのコンテンツが前記設定変更するコンテンツでない場合、前記第１課金レートよりも低いレートの第２課金レートを用いて前記プレイの前記課金額を算定するサーバ装置に、前記プレイが許可されたゲームのコンテンツが、新規状態の所定のコンテンツを既存状態に設定変更するコンテンツであるか否かに関する情報を含むプレイ情報を送信する送信機能、
を実現させるためのゲームプログラム。
【請求項７】
対価を支払ったユーザにプレイを許可したゲームを実行するゲーム装置と、前記ゲーム装置と通信ネットワークにより接続されるサーバ装置とを備え、前記ゲームの運営者に対する課金額を前記対価に基づいて算定するゲームシステムであって、
前記ユーザの識別情報に対応する履歴情報であって記憶部に記憶されている前記ユーザの前記ゲームのプレイ履歴を含む履歴情報に基づいて、前記ゲームの複数のコンテンツにおける新規状態の所定のコンテンツの有無を判定する判定手段、
前記新規状態の所定のコンテンツがあると判定された場合、新規状態の所定のコンテンツを既存状態に設定変更するコンテンツを前記ユーザがプレイ可能であることを示す許可手段、
前記ゲームのプレイ結果に応じて前記履歴情報を更新する更新手段、
前記プレイが許可されたゲームのコンテンツが、前記設定変更するコンテンツである場合、第１課金レートを用いて前記プレイの前記課金額を算定し、前記設定変更するコンテンツでない場合、前記第１課金レートよりも低いレートの第２課金レートを用いて前記プレイの前記課金額を算定する算定手段、
を含む、ゲームシステム。
【手続補正書】
【提出日】平成31年3月6日(2019.3.6)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
対価を支払ったユーザにプレイを許可したゲームを実行するゲーム装置と通信ネットワークにより接続されるサーバ装置に、前記ゲームの運営者に対する課金額を前記対価に基づいて算定させるための課金プログラムであって、
前記サーバ装置に、
前記プレイが許可されたゲームのコンテンツが、プレイすることを条件として該ゲームの新規状態の所定のコンテンツを既存状態に設定変更するコンテンツであるか否かに関する情報を含むプレイ情報を、該ゲーム装置から取得する取得機能、
前記設定変更するコンテンツである場合、第１課金レートを用いて前記プレイの前記課金額を算定し、前記設定変更するコンテンツでない場合、前記第１課金レートよりも低いレートの第２課金レートを用いて前記プレイの前記課金額を算定する算定機能、
を実現させるための課金プログラム。
【請求項２】
前記サーバ装置に、さらに、
前記ユーザの識別情報を前記ゲーム装置から取得し、該ユーザの識別情報に対応する履歴情報であって記憶部に記憶されている該ユーザの前記ゲームのプレイ履歴を含む履歴情報に基づいて、前記ゲームの複数のコンテンツにおける前記新規状態の所定のコンテンツの有無を判定する判定機能、
前記新規状態の所定のコンテンツがあると判定された場合、前記設定変更するコンテンツを前記ユーザがプレイ可能であることを示す情報をゲーム装置に送信する許可機能、
を実現させるための請求項１に記載の課金プログラム。
【請求項３】
前記ゲームは、楽曲を再生するとともに操作入力を促す指示標識を前記ゲーム装置の表示部に表示するリズムゲームであり、
前記コンテンツは、前記楽曲である請求項１又は２に記載の課金プログラム。
【請求項４】
前記ゲームのコンテンツには、ユーザがプレイ可能な第一モード及び該第一モードとは異なる第二モードの二種類のゲームモードが含まれ、
前記設定変更するコンテンツは前記第一モードであり、前記所定のコンテンツは前記ゲームモードとは異なるコンテンツである、請求項１〜３のいずれかに記載の課金プログラム。
【請求項５】
前記取得機能では、前記ゲーム装置から、前記ゲーム装置自体の識別情報又は／及び前記運営者の識別情報も取得する機能、
前記算定機能では、前記ゲーム装置自体の識別情報又は前記運営者の識別情報に基づいて、前記運営者毎に前記課金額を算定する機能、
を実現させるための請求項１〜４のいずれかに記載の課金プログラム。
【請求項６】
通信ネットワークによりサーバ装置に接続され、対価を支払ったユーザにプレイを許可したゲームを実行するゲーム装置のゲームプログラムであって、
前記ゲーム装置に、
前記ゲームの運営者に対する課金額を前記対価に基づいて算定するサーバ装置であって、前記プレイが許可されたゲームのコンテンツがプレイすることを条件として該ゲームの新規状態の所定のコンテンツを既存状態に設定変更するコンテンツである場合、第１課金レートを用いて前記プレイの前記課金額を算定し、前記許可されたゲームのコンテンツが前記設定変更するコンテンツでない場合、前記第１課金レートよりも低いレートの第２課金レートを用いて前記プレイの前記課金額を算定するサーバ装置に、前記プレイが許可されたゲームのコンテンツが、新規状態の所定のコンテンツを既存状態に設定変更するコンテンツであるか否かに関する情報を含むプレイ情報を送信する送信機能、
を実現させるためのゲームプログラム。
【請求項７】
対価を支払ったユーザにプレイを許可したゲームを実行するゲーム装置と、前記ゲーム装置と通信ネットワークにより接続されるサーバ装置とを備え、前記ゲームの運営者に対する課金額を前記対価に基づいて算定するゲームシステムであって、
前記ユーザの識別情報に対応する履歴情報であって記憶部に記憶されている前記ユーザの前記ゲームのプレイ履歴を含む履歴情報に基づいて、前記ゲームの複数のコンテンツにおける新規状態の所定のコンテンツの有無を判定する判定手段、
前記新規状態の所定のコンテンツがあると判定された場合、プレイすることを条件として新規状態の所定のコンテンツを既存状態に設定変更するコンテンツを前記ユーザがプレイ可能であることを示す許可手段、
前記ゲームのプレイ結果に応じて前記履歴情報を更新する更新手段、
前記プレイが許可されたゲームのコンテンツが、前記設定変更するコンテンツである場合、第１課金レートを用いて前記プレイの前記課金額を算定し、前記設定変更するコンテンツでない場合、前記第１課金レートよりも低いレートの第２課金レートを用いて前記プレイの前記課金額を算定する算定手段、
を含む、ゲームシステム。