JP5775019B2

JP5775019B2 - プログラム、情報記憶媒体、サーバ及びネットワークシステム

Info

Publication number: JP5775019B2
Application number: JP2012068230A
Authority: JP
Inventors: 無田　廣之; 廣之無田; 恩田　明生; 明生恩田
Original assignee: Namco Ltd; Bandai Namco Entertainment Inc
Current assignee: Namco Ltd; Bandai Namco Entertainment Inc
Priority date: 2012-03-23
Filing date: 2012-03-23
Publication date: 2015-09-09
Anticipated expiration: 2032-03-23
Also published as: JP2013198588A

Description

本発明は、プログラム、情報記憶媒体、サーバ及びネットワークシステムに関する。

従来から、ソーシャル・ネットワーキング・サービス（以下、「ＳＮＳ」という。）と呼ばれる、コミュニケーション型のサービスをユーザに提供するネットワークシステムが知られている。このようなネットワークシステムでは、ユーザが友人を自らの友人リストに追加して、友人に自己の日記を見せたり、メール交換する等によりコミュニティを図ったりすることを目的としている。そして、ソーシャル・ネットワーキング・サービス上では、ソーシャルゲームと呼ばれるオンラインゲームが提供され、他のユーザとコミュニケーションをとりながらプレイすることができる。

また、従来から、複数のユーザで構成されるグループを生成してゲームを行わせるゲームシステムが存在する（特許文献１、図９）。

特開２００４−８１３０８号公報

しかし、従来のグループを生成するゲームシステムは、ユーザの意思によってグループを決めるものであり、ゲームを活性化させる点において考慮されないものであった。

本発明は、以上の課題に鑑みたものであり、複数のユーザで構成されるグループでゲームを行わせる場合に、ゲームを活性化させることが可能なグループを生成することが可能なプログラム、情報記憶媒体、サーバ及びネットワークシステムを提供することにある。

（１）本発明は、複数のユーザの端末とネットワークを介してデータを送受信し、複数のユーザで構成されるグループを生成してゲームを行わせるサーバのプログラムであって、ユーザの識別情報毎に、ユーザが前記ゲームを活性化させるか否かを判定するための活性化情報を、記憶部に記憶する処理を行う活性化情報制御部と、ユーザ毎に、ユーザの識別情報に対応付けられた活性化情報に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定する処理を行う判定部と、複数のユーザで構成されるグループを生成する処理を行うグループ生成部として、コンピュータを機能させ、前記グループ生成部が、前記ゲームを活性化させると判定された少なくとも一人のユーザを含む前記グループを生成する処理を行うプログラムに関する。本発明は、コンピュータに読み取り可能であって、上記プログラムを記憶した情報記憶媒体、上記各部を含むサーバに関係する。本発明によれば、グループに、ゲームを活性化させると判定された少なくとも一人のユーザが含まれているので、そのグループでゲームを行わせる場合に、ゲームを活性化させることが可能となる。

（２）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、前記活性化情報は、ユーザのゲーム状況を含み、前記活性化情報制御部が、ユーザの識別情報毎に、ユーザのゲーム状況を前記記憶部に記憶し、前記判定部が、ユーザ毎に、ユーザの識別情報に対応付けられたゲーム状況に基づいて当該ユーザが前記ゲームを活性化させるか否かを判定するようにしてもよい。本発明によれば、ユーザのゲーム状況を考慮して、当該ユーザがゲームを活性化させるか否かを判定することができる。

（３）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、ゲーム中に使用するアイテムを前記記憶部に記憶し、ユーザからの課金によって当該アイテムを当該ユーザに取得させるための制御を行うアイテム取得制御部として、コンピュータを更に機能させ、前記活性化情報は、ユーザの前記アイテムの課金情報を含み、前記活性化情報制御部が、ユーザの識別情報毎に、当該ユーザの前記アイテムの課金情報を前記記憶部に蓄積し、前記判定部が、ユーザ毎に、ユーザの前記アイテムの課金情報に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定してもよい。本発明によれば、ユーザのアイテムの課金情報を考慮して、当該ユーザがゲームを活性化させるか否かを判定することができる。

（４）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、ゲーム中に使用するアイテムを前記記憶部に記憶し、当該アイテムをユーザ又は当該ユーザが属するグループに使用させるための制御を行うアイテム使用制御部として、コンピュータを更に機能させ、前記活性化情報は、ユーザ又は当該ユーザが属するグループの前記アイテムの使用状況を含み、前記活性化情報制御部が、ユーザの識別情報毎に、ユーザ又は当該ユーザが属するグループの前記アイテムの使用状況を前記記憶部に記憶し、前記判定部が、ユーザ毎に、ユーザ又は当該ユーザが属するグループの前記アイテムの使用状況に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定してもよい。本発明によれば、ユーザ又はユーザが属するグループのアイテムの使用状況を考慮して、当該ユーザがゲームを活性化させるか否かを判定することができる。

（５）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、ユーザからの課金によって前記アイテムを当該ユーザに取得させるための制御を行うアイテム取得制御部として、コンピュータを更に機能させ、前記活性化情報制御部が、ユーザの識別情報毎に、ユーザが課金した前記アイテムの使用状況を前記記憶部に記憶し、前記判定部が、ユーザ毎に、ユーザが課金した前記アイテムの使用状況に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定してもよい。本発明によれば、ユーザの課金アイテムの使用状況を考慮して、当該ユーザがゲームを活性化させるか否かを判定することができる。

（６）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、ゲーム中に使用するアイテムを前記記憶部に記憶し、当該アイテムをユーザ又は当該ユーザが属するグループに取得させるための制御を行うアイテム取得制御部として、コンピュータを更に機能させ、前記活性化情報は、ユーザ又は当該ユーザが属するグループの前記アイテムの取得状況を含み、前記活性化情報制御部が、ユーザの識別情報毎に、ユーザ又は当該ユーザが属するグループの前記アイテムの取得状況を前記記憶部に記憶し、前記判定部が、ユーザ毎に、ユーザ又は当該ユーザが属するグループの前記アイテムの取得状況に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定してもよい。本発明によれば、ユーザ又は当該ユーザが属するグループのアイテムの取得状況を考慮して、当該ユーザがゲームを活性化させるか否かを判定することができる。

（７）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、前記アイテム取得制御部が、ユーザからの課金によって前記アイテムを当該ユーザに取得させるための制御を行い、前記活性化情報制御部が、ユーザの識別情報毎に、ユーザが課金した前記アイテムの取得状況を前記記憶部に記憶し、前記判定部が、ユーザ毎に、ユーザが課金した前記アイテムの取得状況に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定してもよい。本発明によれば、ユーザの課金アイテムの取得状況を考慮して、当該ユーザがゲームを活性化させるか否かを判定することができる。

（８）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、前記活性化情報は、ユーザの前記アイテムの保有数を含み、前記活性化情報制御部が、ユーザの識別情報毎に、ユーザの前記アイテムの保有数を前記記憶部に記憶し、前記判定部が、ユーザ毎に、ユーザの前記アイテムの保有数に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定してもよい。本発明によれば、ユーザのアイテムの保有数を考慮して、当該ユーザがゲームを活性化させるか否かを判定することができる。

（９）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、前記活性化情報は、ユーザの前記アイテムの種類情報を含み、前記活性化情報制御部が、ユーザの識別情報毎に、ユーザの前記アイテムの種類情報を前記記憶部に記憶し、前記判定部が、ユーザ毎に、ユーザの前記アイテムの種類情報に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定してもよい。本発明によれば、ユーザのアイテムの種類情報を考慮して、当該ユーザがゲームを活性化させるか否かを判定することができる。

（１０）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、前記活性化情報は、ユーザのゲーム利用時間を含み、前記活性化情報制御部が、ユーザの識別情報毎に、ユーザのゲーム利用時間を前記記憶部に蓄積し、前記判定部が、ユーザ毎に、ユーザの前記ゲーム利用時間に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定してもよい。本発明によれば、ユーザのゲーム利用時間を考慮して、当該ユーザがゲームを活性化させるか否かを判定することができる。

（１１）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、前記活性化情報は、ユーザ又は当該ユーザが属するグループが行ったゲームのゲーム結果を含み、前記活性化情報制御部が、ユーザの識別情報毎に、ユーザ又は当該ユーザが属するグループの前記ゲーム結果を前記記憶部に蓄積し、前記判定部が、ユーザ毎に、ユーザ又は当該ユーザが属するグループの前記ゲーム結果に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定してもよい。本発明によれば、ユーザ又は当該ユーザが属するグループのゲーム結果を考慮して、当該ユーザがゲームを活性化させるか否かを判定することができる。

（１２）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、ユーザの前記端末からイベントの参加要求を受信した場合に、ゲーム中の当該イベントに当該ユーザを参加させるための制御を行うイベント参加制御部として、コンピュータを更に機能させ、前記活性化情報は、ユーザのイベントの参加状況を含み、前記活性化情報制御部が、ユーザの識別情報毎に、ユーザのイベントの参加状況を前記記憶部に記憶し、前記判定部が、ユーザ毎に、ユーザの前記イベントの参加状況に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定してもよい。本発明によれば、ユーザのイベントの参加状況を考慮して、当該ユーザがゲームを活性化させるか否かを判定することができる。

（１３）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、ユーザの前記端末からイベントの実行要求を受信した場合に、ゲーム中の当該イベントを実行させるための制御を行うイベント実行部として、コンピュータを更に機能させ、前記活性化情報は、ユーザのイベントの実行状況を含み、前記活性化情報制御部が、ユーザの識別情報毎に、ユーザのイベントの実行状況を前記記憶部に記憶し、前記判定部が、ユーザ毎に、ユーザの前記イベントの実行状況に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定してもよい。本発明によれば、ユーザのイベント実行状況を考慮して、当該ユーザがゲームを活性化させるか否かを判定することができる。

（１４）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、前記活性化情報は、前記サーバとネットワークを介して接続されるＳＮＳサーバに登録されているユーザのイベントの参加状況又はイベントの実行状況に関するＳＮＳ情報を含み、前記活性化情報制御部が、ユーザの識別情報毎に、前記ＳＮＳサーバから受信したユーザの前記イベントの参加状況又はイベントの実行状況に関するＳＮＳ情報を前記記憶部に記憶し、前記判定部が、ユーザ毎に、ユーザの前記イベントの参加状況又はイベントの実行状況に関するＳＮＳ情報に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定してもよい。本発明によれば、ユーザのイベントの参加状況又はイベントの実行状況に関するＳＮＳ情報を考慮して、当該ユーザがゲームを活性化させるか否かを判定することができる。

（１５）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、ＳＮＳ情報は、ユーザの前記イベントの参加状況又はイベントの実行状況に関する投稿回数を含み、前記活性化情報制御部が、ユーザの識別情報毎に、ユーザの前記イベントの参加状況又はイベントの実行状況に関する投稿回数を前記記憶部に記憶し、前記判定部が、ユーザ毎に、ユーザの前記イベントの参加状況又はイベントの実行状況に関する投稿回数に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定してもよい。本発明によれば、ユーザのイベントの参加状況又はイベントの実行状況に関する投稿回数を考慮して、当該ユーザがゲームを活性化させるか否かを判定することができる。

（１６）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、前記活性化情報は、ユーザ又は当該ユーザが属するグループが行ったイベントの成功可否を含み、前記活性化情報制御部が、ユーザの識別情報毎に、ユーザ又は当該ユーザが属するグループが行ったイベントの成功可否を前記記憶部に蓄積し、前記判定部が、ユーザ毎に、ユーザ又は当該ユーザが属するグループが行ったイベントの成功可否に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定してもよい。本発明によれば、ユーザ又は当該ユーザが属するグループが行ったイベントの成功可否を考慮して、当該ユーザがゲームを活性化させるか否かを判定することができる。

（１７）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、前記活性化情報は、ユーザ又は当該ユーザが属するグループが行ったイベントの参加時間を含み、前記活性化情報制御部が、ユーザの識別情報毎に、ユーザ又は当該ユーザが属するグループが行ったイベントの参加時間を前記記憶部に蓄積し、前記判定部が、ユーザ毎に、ユーザ又は当該ユーザが属するグループが行ったイベントの参加時間に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定してもよい。本発明によれば、ユーザ又は当該ユーザが属するグループが行ったイベントの参加時間を考慮して、当該ユーザがゲームを活性化させるか否かを判定することができる。

（１８）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、前記活性化情報は、前記サーバとネットワークを介して接続されるＳＮＳサーバに登録されているユーザの友人数を含み、前記活性化情報制御部が、ユーザの識別情報毎に、前記ＳＮＳサーバから受信したユーザの友人数を前記記憶部に記憶し、前記判定部が、ユーザ毎に、ユーザの識別情報に対応付けられた当該ユーザの友人数に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定してもよい。本発明によれば、ユーザの友人数に基づいて、当該ユーザがゲームを活性化させるか否かを判定することができる。

（１９）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、前記活性化情報は、前記サーバとネットワークを介して接続されるＳＮＳサーバに登録されているユーザが友人と行ったコミュニケーションの数を含み、前記活性化情報制御部が、ユーザの識別情報毎に、前記ＳＮＳサーバから受信した前記コミュニケーションの数を前記記憶部に記憶し、前記判定部が、ユーザ毎に、ユーザが友人と行った前記コミュニケーションの数に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定してもよい。本発明によれば、ユーザが友人と行ったコミュニケーションの数に基づいて、当該ユーザがゲームを活性化させるか否かを判定することができる。

（２０）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、前記判定部が、設定された期間におけるユーザのアイテムの課金額、ユーザのアイテムの保有数、設定された期間におけるユーザのゲーム利用時間、設定された期間におけるユーザのイベントの参加状況に関するＳＮＳサーバへの投稿回数、設定された期間におけるユーザのイベントの実行状況に関するＳＮＳサーバへの投稿回数、設定された期間におけるユーザ又は当該ユーザが属するグループが行ったイベントの参加時間、設定された期間におけるユーザ又は当該ユーザが属するグループが行ったイベントの実行時間、設定された期間におけるユーザが友人と行った前記コミュニケーションの数、の少なくとも１つに基づいて活性化数値を算出し、当該活性化数値が所定数値より高い場合に、当該ユーザが前記ゲームを活性化させると判定してもよい。

（２１）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、前記グループ生成部が、前記ゲームを活性化させると判定された複数のユーザで構成される前記グループを生成する処理を行うようにしてもよい。本発明によれば、ゲームを活性化させると判定された複数のユーザで構成されるグループを生成するので、ゲームを活性化させることができるゲーム環境を提供できる。

（２２）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、前記判定部が、ユーザの識別情報毎に、ユーザの活性化情報に基づいて当該ユーザを第１から第Ｎ（Ｎ≧３）のいずれかの活性化レベルに判定する処理を行い、前記グループ生成部が、第Ｍ（Ｎ＞Ｍ≧１）の活性化レベルのユーザと、第Ｍ＋１の活性化レベルのユーザで構成されるグループを生成してもよい。本発明によれば、第Ｍ＋１の活性化レベルのユーザが、第Ｍの活性化レベルのユーザに影響を与えることができ、全体としてゲームを活性化させることができるゲーム環境を提供できる。また、第Ｍの活性化レベルのユーザは、適度に活性化の影響を受けることができ適切なゲーム環境を提供することができる。

（２３）また、本発明のプログラム、情報記憶媒体、及びサーバにおいて、ユーザの端末からグループの生成要求を受信する処理を行う通信制御部と、ユーザの端末からグループの生成要求を受信した場合に、グループのメンバー候補である他のユーザを配置した表示情報を生成する処理を行う表示情報生成部として、コンピュータを更に機能させ、前記表示情報生成部が、前記ゲームを活性化させると判定された少なくとも一人の他のユーザを前記メンバー候補として配置した表示情報を生成する処理を行い、前記通信制御部が、前記ユーザの端末に前記表示情報を送信する処理を行い、前記ユーザが前記グループのメンバー候補からグループのメンバーとして選択された情報を、前記ユーザの端末から受信する処理を行い、前記グループ生成部が、前記ユーザと、前記メンバー候補から選択された他のユーザとを含むグループを生成してもよい。本発明によれば、ユーザ端末からのグループの生成要求を受信してグループの生成を行う際に、ユーザの端末に、ゲームを活性化させるメンバー候補を配置した表示情報を送信する。したがって、ユーザはゲームを活性化させるメンバー候補からメンバーを選択することができる。つまり、本発明によれば、ユーザは、ゲームを活性化させるメンバーからなるグループを生成することができる。

（２４）また、本発明は、複数のユーザの端末と、複数のユーザで構成されるグループを生成してゲームを行わせるサーバとが、ネットワークを介してデータを送受信するネットワークシステムであって、前記サーバが、ユーザの識別情報毎に、ユーザが前記ゲームを活性化させるか否かを判定するための活性化情報を、記憶部に記憶する処理を行う活性化情報制御部と、ユーザ毎に、ユーザの識別情報に対応付けられた活性化情報に基づいて、当該ユーザが前記ゲームを活性化させるか否かを判定する処理を行う判定部と、複数のユーザで構成されるグループを生成する処理を行うグループ生成部と、を含み、前記グループ生成部が、前記ゲームを活性化させると判定された少なくとも一人のユーザを含む前記グループを生成する処理を行うことを特徴とするネットワークシステムに関する。

本実施形態のネットワークシステムのネットワーク図の一例。本実施形態のサーバ、端末の機能ブロック図の一例。本実施形態のＳＮＳサーバの機能ブロック図の一例。本実施形態のアイテム保有数を説明するための図。本実施形態のアイテムの取得状況を説明するための図。本実施形態の使用アイテム数を説明するための図。本実施形態のアイテムの使用状況を説明するための図。本実施形態の課金情報を説明するための図。本実施形態の課金情報を説明するための図。本実施形態の課金情報を説明するための図。本実施形態のゲーム情報を説明するための図。本実施形態のゲーム利用時間を説明するための図。本実施形態のゲーム結果を説明するための図。本実施形態のイベントの参加状況を説明するための図。本実施形態のイベントの実行状況を説明するための図。本実施形態の友人数を説明するための図。本実施形態のコミュニケーション数を説明するための図。本実施形態のＳＮＳ情報を説明するための図。本実施形態のＳＮＳ情報を説明するための図。図２０（Ａ）は本実施形態の活性化フラグ、図２０（Ｂ）は本実施形態の活性化レベルを説明するための図。本実施形態の活性化数値を説明するための図。本実施形態の表示情報の生成処理を説明するための図。本実施形態のサーバの処理の流れを示すフローチャート。

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

１．ネットワークシステムの説明
図１は、本実施形態のネットワークシステムを示す。図１に示すように、本実施形態のネットワークシステムは、ゲームサービスを提供するサーバ１０と、端末２０（端末２０Ａ、２０Ｂ、２０Ｃ）とが、インターネット（ネットワークの一例）に接続可能に構成されている。

サーバ１０は、インターネットを介してサーバに通信接続された端末２０を介して、ユーザにゲームをプレイさせるサービスを提供することが可能な情報処理装置である。また、本実施形態のネットワークシステムは、コミュニケーション型のサービスを提供するＳＮＳサーバ３０を含んでもよい。ＳＮＳサーバ３０は、複数のユーザ間でコミュニケーションを提供することが可能なサービスを提供する情報処理装置である。

サーバ１０が提供するゲームは、ＳＮＳサーバ３０が提供するＳＮＳの動作環境（ＡＰＩ（アプリケーションプログラミングインタフェース）、プラットフォーム等）を利用して実行されるソーシャルゲーム（ＳｏｃｉａｌＧａｍｅ）と呼ばれるゲームでもよい。

サーバ１０が提供するゲームは、端末２０のＷｅｂブラウザ上で提供されるゲーム、例えばＨＴＭＬ、ＦＬＡＳＨ、ＣＧＩ、ＰＨＰ、ｓｈｏｃｋｗａｖｅ、Ｊａｖａ（登録商標）アプレット、ＪａｖａＳｃｒｉｐｔ（登録商標）など様々な言語で作られたブラウザゲーム（Ｗｅｂブラウザで設置サイトを開くだけで起動するゲーム）でもよい。

ソーシャルゲームは、既存のオンラインゲームとは違い、専用のクライアントソフトウェアを必要とせず、ＷｅｂブラウザとＳＮＳのアカウントのみで利用可能なゲームでもよい。

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

課金サーバ４０は、ユーザの端末からアイテムの代価を徴収するサーバである。課金サーバ４０は、サーバ１０、端末２０、ＳＮＳサーバ３０とネットワークを介して接続される。

例えば、課金サーバ４０は、ユーザへの料金請求及びユーザの銀行口座等からの引き落とし等を管理する機能を備える。例えば、クレジット会社や、ユーザの端末２０の通信サービス会社に応じた種々の課金処理を行う。

端末２０は、スマートフォン、携帯電話、ＰＨＳ、コンピュータ、ゲーム装置、ＰＤＡ、携帯型ゲーム機等、画像生成装置などの情報処理装置であり、インターネット（ＷＡＮ）、ＬＡＮなどのネットワークを介してサーバ１０、ＳＮＳサーバ３０、課金サーバ４０に接続可能な装置である。なお、端末２０とサーバ１０、ＳＮＳサーバ３０、課金サーバ４０との通信回線は、有線でもよいし無線でもよい。

また、端末２０はＷｅｂページ（ＨＴＭＬ形式のデータ）を閲覧可能なＷｅｂブラウザを備えている。つまり、端末２０は、サーバ１０やＳＮＳサーバ３０との通信を行うための通信制御機能、及びサーバ１０やＳＮＳサーバ３０から受信したデータ（Ｗｅｂデータ、ＨＴＭＬ形式で作成されたデータなど）を用いて表示部への表示制御を行うＷｅｂブラウザ機能などを備え、表示情報（ゲーム画面の情報）を端末の表示部に表示させる処理を行う。

端末２０から所定ゲームを行う旨の要求をサーバ１０に対して行うと、端末２０は、サーバ１０のゲームサイトに接続され、ゲームが開始される。ゲームでは、必要に応じてＡＰＩを用いることにより、ＳＮＳサーバ３０に所定の処理を行わせたり、ＳＮＳサーバ３０が管理するＳＮＳユーザ情報を取得したりすることができる。

例えば、本実施形態のネットワークシステムは、端末２０の入力情報をサーバ１０に送信し、サーバ１０は受信した入力情報に基づいてゲーム処理を行う。そして、サーバ１０はゲーム処理結果を端末２０に送信し、端末２０はサーバ１０から受信したゲーム処理結果を表示部２９０に表示する処理を行う。

なお、サーバ１０が、ＳＮＳサーバ３０の機能を備えていてもよいし、サーバ１０が、課金サーバ４０の機能を備えていてもよい。また、本実施の形態のゲームの処理は、サーバ１０が一部又は全部を行ってもよいし、端末２０が一部又は全部を行ってもよい。

また、サーバ１０、ＳＮＳサーバ３０、課金サーバ４０は、１つの（装置、プロセッサ）で構成されていてもよいし、複数の（装置、プロセッサ）で構成されていてもよい。

また、サーバ１０の記憶領域（記憶部１７０）に記憶される課金情報、ゲーム情報等の情報を、ネットワーク（イントラネット又はインターネット）を介して接続されたデータベース（広義には記憶装置、メモリ）に記憶するようにしてもよい。

また、ＳＮＳサーバ３０の記憶領域（記憶部３７０）に記憶されるユーザ情報等の情報を、ネットワーク（イントラネット又はインターネット）を介して接続されたデータベース（広義には記憶装置、メモリ）に記憶するようにしてもよい。

２．ＳＮＳの説明
ＳＮＳ（ソーシャル・ネットワーキング・サービス）とは、社会的ネットワークをインターネット上で構築するサービスのことであり、本実施形態では、ＳＮＳサーバ３０がＳＮＳを提供する。ＳＮＳの基本的な機能としては、プロフィール機能、メッセージ送受信機能、友人関係機能（ユーザ相互リンク機能）、ユーザ検索機能、日記機能（ブログ機能）、掲示情報投稿機能（メッセージ投稿機能）、コミュニティ機能等がある。

ＳＮＳサーバ３０は、ユーザの情報（ユーザ名、プロフィール、日記、掲示情報、ゲームの進捗状況、コミュニティなど）をログインしたユーザだけでなく、当該ユーザと友人関係（フレンド関係）にある他のユーザにも送信し、ユーザ間でコミュニティを図るようにしている。ＳＮＳサーバ３０は、会員登録を行ったユーザに限定してサービスを提供するようにしてもよい。

例えば、ＳＮＳサーバ３０は、Ｗｅｂサーバ機能や、メール配送が可能なメールサーバ機能を備え、端末２０は、ＳＮＳサーバ３０のＳＮＳ用のＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）にアクセスし、ユーザの識別情報（ユーザ名等）、パスワードを送信する。そして、ＳＮＳサーバ３０において当該ユーザのログインが成功すると、ＳＮＳサーバ３０は当該ユーザのＷｅｂページを端末２０に送信する。そして、端末２０は、Ｗｅｂブラウザ上に受信した当該ユーザのＷｅｂページを表示部２９０に表示させる。

本実施形態のＳＮＳサーバ３０は、一方のユーザと他方のユーザとの双方が互いに友人関係を要求する情報を受け取ると、互いに、一方のユーザの識別情報に対応付けて（関連付けて）他方のユーザの識別情報を登録する。

例えば、本実施形態は、ＳＮＳサーバ３０が、端末２０ＡからユーザＡがユーザＢに友人関係を要求する情報を受け取る。すると、ＳＮＳサーバ３０は、ユーザＢの端末２０Ｂに、ユーザＡからの友人要求（フレンド要求）を送信する処理を行う。そして、ＳＮＳサーバ３０が、端末２０Ｂから、ユーザＢがユーザＡの友人要求に対する許可の情報を受信した場合には、ユーザＡとユーザＢの友人関係が成立したものと判定する。そして、ユーザＡの識別情報に対応づけて、ユーザＢの識別情報を登録し、ユーザＢの識別情報に対応付けて、ユーザＡの識別情報を登録する。

本実施形態のＳＮＳは、各ユーザが、掲示情報の投稿を行うことができる。例えば、ユーザＡが掲示情報を投稿するとは、ユーザＡの端末２０ＡからＳＮＳサーバ３０にユーザ端末から入力された掲示情報を送信することであり、ＳＮＳサーバ３０は、ユーザＡが投稿した掲示情報を含むデータ（Ｗｅｂページ）を端末２０Ａに送信し、端末２０Ａの表示部に掲示情報を表示することができる。

また、ＳＮＳサーバ３０は、ユーザＡの端末から当該掲示情報を友人リスト（フレンドリスト）として登録されているユーザＢにも公開することができる。例えば、ユーザＡが投稿した掲示情報は、ユーザＢから参照することができ、ユーザＢは、ユーザＡが投稿した掲示情報に対してコメントや評価（「いいね」など）を行うことができ、ユーザ間のコミュニケーションを図ることができる。

なお、ＳＮＳサーバ３０は、各ユーザの公開制限情報（閲覧制限情報）に基づいて、各ユーザのユーザ情報（プロフィール、掲示情報等）を公開するユーザを所定のユーザに制限するようにしてもよい。例えば、ユーザＡが公開制限情報を友人に制限している場合には、ユーザＡと友人関係にある他のユーザ（例えば、ユーザＢ、Ｃ、Ｄ、Ｅ）にのみユーザＡの掲示情報を閲覧可能とし、友人関係にない他のユーザ（例えば、ユーザＦ）には、ユーザＡの掲示情報を閲覧不能とするように制御する。なお、公開制限情報は、「全てのユーザに公開」「友人のみの公開」、「友人の友人までに公開」など複数段階の制限を設け、ＳＮＳサーバ３０は、ユーザの端末からいずれの段階にするかの選択要求を受け付けて、当該ユーザの公開制限情報を設定している。

さらに、ＳＮＳサーバ３０は、フォローワー情報（自己がフォローワーとして登録しているユーザの情報）及びフォロー情報（自己をフォローしているユーザの情報）を記憶部に記憶してもよい。なお、友人関係（フレンド関係）による互いのサービスユーザにおける双方向の情報共有とは異なり、特定のサービスユーザのＳＮＳ上の更新情報を閲覧可能に登録しているのみの一方向のサービスユーザを、特定サービスユーザのフォローワーといい、当該更新情報を閲覧可能にすることをフォローという。すなわち、ＳＮＳサーバ３０は、ユーザの識別情報に対応づけて、フォローワー関係、フォロー関係にある１又は複数の他のユーザの識別情報を記憶部に記憶してもよい。

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

３−１．サーバ
記憶部１７０は、処理部１００や通信部１９６などのワーク領域となるもので、その機能はＲＡＭ（ＶＲＡＭ）などにより実現できる。また、記憶部１７０には、アイテム１７２、活性化情報１７３、ユーザ情報１７５、友人情報１７６が記憶される。なお、記憶部１７０に記憶される情報は、データベースで管理してもよい。

記憶部１７０に記憶されるアイテムは、サーバ１０がユーザに提供するために予め用意された提供用のアイテムと、ユーザ毎（ユーザの識別情報毎）に対応づけて登録されているユーザ用のアイテムの両方を含む。提供用のアイテムは、課金用と無料用とに分けて記憶部１７０に記憶していてもよい。

活性化情報１７３は、ユーザのゲーム状況を含む。ゲーム状況はアイテムの取得・使用状況、イベント参加・実行状況、課金情報（課金状況）、ゲーム情報等である。

つまり、活性化情報１７３は、ユーザのアイテムの課金情報を含む。また、活性化情報１７３は、ユーザ又は当該ユーザが属するグループのアイテムの使用状況を含む。

また、活性化情報１７３は、ユーザ又は当該ユーザが属するグループのアイテムの取得状況を含む。また、活性化情報１７３は、ユーザのアイテムの保有数、ユーザのアイテムの種類情報を含む。また、活性化情報１７３は、ユーザのゲーム利用時間（ゲームの利用期間、ゲームの利用時間帯）、ユーザ又は当該ユーザが属するグループが行ったゲームのゲーム結果を含む。また、活性化情報１７３は、ユーザのイベントの参加状況、ユーザのイベントの実行状況を含む。また、活性化情報１７３は、ＳＮＳサーバ３０に登録されているユーザのイベントの参加状況に関するＳＮＳ情報、ＳＮＳサーバ３０に登録されているユーザのイベントの実行状況に関するＳＮＳ情報を含む。また、活性化情報１７３は、ユーザ又は当該ユーザが属するグループが行ったイベントの成功可否、ユーザ又は当該ユーザが属するグループが行ったイベントの参加時間を含む。また、活性化情報１７３は、ＳＮＳサーバ３０に登録されているユーザの友人数や、ＳＮＳサーバ３０に登録されているユーザが友人と行ったコミュニケーションの数を含む。

なお、課金情報は、ユーザが過去に購入したアイテムを含む。また、課金情報は、ユーザが過去に購入したアイテムの購入額を含む。また、課金情報は、アイテムと交換可能なユーザが所持する仮想通貨を含む。また、課金情報は、ユーザが過去に購入したアイテムの購入日時を含む。また、課金情報は、ユーザが過去に購入したアイテムの購入時のモードを含む。なお、サーバ１０は、ユーザ毎に、ユーザの課金情報を当該ユーザの識別情報に対応づけて記憶部１７０に記憶する。

また、ゲーム情報は、ゲーム結果、ゲーム利用時間（ログイン日時、ログアウト日時）ユーザキャラクタのパラメータ、ユーザキャラクタの服装情報を含む。なお、サーバ１０は、ユーザ毎に、ユーザのゲーム情報を当該ユーザの識別情報に対応づけて記憶部１７０に記憶する。

ユーザ情報１７５は、ユーザの識別情報（ユーザ名、ユーザＩＤ、メールアドレスなどユーザを識別できる情報）、ユーザのパスワード、ユーザが投稿した掲示情報等である。サーバ１０のユーザの識別情報（ゲームＩＤ）は、ＳＮＳサーバ３０のユーザの識別情報（ＳＮＳＩＤ）と同じでもよいし、サーバ１０のユーザの識別情報（ゲームＩＤ）は、ＳＮＳサーバ３０のユーザの識別情報（ＳＮＳＩＤ）と異なるものであってもよい。サーバ１０のユーザの識別情報（ゲームＩＤ）と、ＳＮＳサーバ３０のユーザの識別情報（ＳＮＳＩＤ）とが異なる場合には、サーバ１０、ＳＮＳサーバ３０それぞれは、サーバ１０のユーザの識別情報（ゲームＩＤ）と、ＳＮＳサーバ３０のユーザの識別情報（ＳＮＳＩＤ）とを対応づけて記憶部に記憶する。

また、ユーザ情報１７５は、ＳＮＳサーバ３０の記憶部３７０に記憶されているユーザ情報３７２と同じでもよい。例えば、なお、サーバ１０は、ユーザ情報１７５を記憶部１７０に記憶せずに、ＳＮＳサーバ３０の記憶部３７０に記憶されているユーザ情報３７２を参照してもよい。また、ユーザ情報１７５は、ユーザの仲間情報を含む。仲間情報は、ユーザキャラクタの仲間となる他のユーザキャラクタ等である。

友人情報１７６は、ユーザと友人関係にある他のユーザの識別情報等である。友人情報１７６は、ＳＮＳサーバ３０の記憶部３７０に記憶されている友人情報３７３と同じでもよい。なお、サーバ１０は、友人情報１７６を記憶部１７０に記憶せずに、ＳＮＳサーバ３０の記憶部３７０に記憶されている友人情報３７３を参照してもよい。サーバ１０は、ユーザ毎に、ユーザの識別情報に対応づけて当該ユーザの友人情報１７６を記憶部１７０に記憶してもよい。

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

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

処理部１００（プロセッサ）は、情報記憶媒体１８０に記憶されるプログラム等に基づいて、処理を行う。具体的には、端末からの要求に応じてサービスを提供する。また、処理部１００は記憶部１７０内の主記憶部１７１をワーク領域として各種処理を行う。処理部１００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ等）、ＡＳＩＣ（ゲートアレイ等）などのハードウェアや、プログラムにより実現できる。

特に、本実施形態のサーバ１０の処理部１００は、通信制御部１１０、Ｗｅｂ処理部１１１、活性化情報制御部１１２、判定部１１３、表示情報生成部１１４、ゲーム処理部１１５、アイテム取得制御部１１６、アイテム使用制御部１１７、イベント参加制御部１１８、イベント実行部１１９、グループ生成部１２０を含む。なお、これらの一部を省略する構成としてもよい。

通信制御部１１０は、端末２０、ＳＮＳサーバ３０、課金サーバ４０それぞれとネットワークを介してデータを送受信する処理を行う。すなわち、サーバ１０は、通信制御部１１０によって端末２０等から受信した情報に基づいて各種処理を行う。

特に、本実施形態の通信制御部１１０は、ユーザの端末２０からグループの生成要求を受信する処理を行う。また、通信制御部１１０は、ユーザの端末２０からグループの生成要求を受信した場合に、ユーザの端末２０に表示情報生成部１１４で生成された表示情報を送信してもよい。

また、通信制御部１１０は、グループのメンバー候補からグループのメンバーとして選択された情報を、ユーザの端末２０から受信する処理を行ってもよい。

また、通信制御部１１０は、生成されたグループの情報（グループに属する各ユーザの情報）を、グループに属する各ユーザの端末に送信する処理を行ってもよい。

Ｗｅｂ処理部１１１は、Ｗｅｂサーバとして機能する。例えば、Ｗｅｂ処理部１１１は、ＨＴＴＰ（ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）等の通信プロトコルを通じて、端末２０にインストールされているＷｅｂブラウザ２１１の要求に応じてデータを送信する処理、端末２０のＷｅｂブラウザ２１１によって送信されるデータを受信する処理を行う。

活性化情報制御部１１２は、ユーザの識別情報毎に、ユーザがゲームを活性化させるか否かを判定するための活性化情報１７３を、記憶部１７０に記憶する処理を行う。つまり、活性化情報制御部１１２は、ユーザの識別情報毎に、ユーザのゲーム状況を記憶部１７０に記憶する。

また、活性化情報制御部１１２は、ユーザの識別情報毎に、当該ユーザのアイテムの課金情報を記憶部１７０に蓄積する。また、活性化情報制御部１１２は、ユーザの識別情報毎に、ユーザ又は当該ユーザが属するグループのアイテムの使用状況を記憶部１７０に記憶する。また、活性化情報制御部１１２は、ユーザの識別情報毎に、ユーザが課金したアイテムの使用状況を記憶部１７０に記憶する。

また、活性化情報制御部１１２は、ユーザの識別情報毎に、ユーザ又は当該ユーザが属するグループのアイテムの取得状況を記憶部１７０に記憶する。また、活性化情報制御部１１２は、ユーザの識別情報毎に、ユーザが課金したアイテムの取得状況を記憶部１７０に記憶する。

また、活性化情報制御部１１２は、ユーザの識別情報毎に、ユーザのアイテムの保有数を記憶部１７０に記憶する。また、活性化情報制御部１１２は、ユーザの識別情報毎に、ユーザのアイテムの種類情報を記憶部１７０に記憶する。

また、活性化情報制御部１１２は、ユーザの識別情報毎に、ユーザのゲーム利用時間を記憶部１７０に蓄積する。また、活性化情報制御部１１２は、ユーザの識別情報毎に、ユーザ又は当該ユーザが属するグループのゲーム結果を記憶部１７０に蓄積する。

また、活性化情報制御部１１２は、ユーザの識別情報毎に、ユーザのイベントの参加状況を記憶部１７０に記憶する。例えば、活性化情報制御部１１２は、ユーザの識別情報毎に、ＳＮＳサーバ３０から受信したユーザのイベントの参加状況に関するＳＮＳ情報を記憶部１７０に記憶する。

また、活性化情報制御部１１２は、ユーザの識別情報毎に、ユーザのイベントの実行状況を記憶部１７０に記憶する。例えば、活性化情報制御部１１２は、ユーザの識別情報毎に、ＳＮＳサーバ３０から受信したユーザのイベントの実行状況に関するＳＮＳ情報を記憶部１７０に記憶する。

また、活性化情報制御部１１２は、ユーザの識別情報毎に、ユーザのイベントの参加状況又はイベントの実行状況に関する投稿回数を記憶部１７０に記憶する。また、活性化情報制御部１１２は、ユーザの識別情報毎に、ユーザ又は当該ユーザが属するグループが行ったイベントの成功可否を記憶部１７０に蓄積する。また、活性化情報制御部１１２は、ユーザの識別情報毎に、ユーザ又は当該ユーザが属するグループが行ったイベントの参加時間を記憶部１７０に蓄積する。

また、活性化情報制御部１１２は、ユーザの識別情報毎に、ＳＮＳサーバ３０から受信したユーザの友人数を記憶部１７０に記憶する。また、活性化情報制御部１１２は、ユーザの識別情報毎に、ＳＮＳサーバ３０から受信し、コミュニケーションの数を記憶部１７０に記憶する。

判定部１１３は、ユーザ毎に、ユーザの識別情報に対応付けられた活性化情報に基づいて、当該ユーザがゲームを活性化させるか否かを判定する処理を行う。

つまり、判定部１１３は、ユーザ毎に、ユーザの識別情報に対応付けられたゲーム状況に基づいて当該ユーザがゲームを活性化させるか否かを判定する。

例えば、判定部１１３は、ユーザ毎に、ユーザのアイテムの課金情報に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。また、判定部１１３は、予め設定された期間（所定期間）において、ユーザのアイテムの課金額が所定額より多い場合に、当該ユーザがゲームを活性化させると判定する。

また、判定部１１３は、ユーザ毎に、ユーザ又は当該ユーザが属するグループのアイテムの使用状況に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。また、判定部１１３は、ユーザ毎に、ユーザが課金したアイテムの使用状況に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。

また、判定部１１３は、ユーザ毎に、ユーザ又は当該ユーザが属するグループのアイテムの取得状況に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。また、判定部１１３は、ユーザ毎に、ユーザが課金したアイテムの取得状況に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。

また、判定部１１３は、ユーザ毎に、ユーザのアイテムの保有数に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。例えば、判定部１１３は、ユーザのアイテムの保有数が所定数より多い場合に、当該ユーザがゲームを活性化させると判定する。

また、判定部１１３は、ユーザ毎に、ユーザのアイテムの種類情報に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。例えば、判定部１１３は、ユーザが特定の種類のアイテム（例えば、種類がカード）を取得している場合に、当該ユーザがゲームを活性化させると判定する。

また、判定部１１３は、ユーザ毎に、ユーザのゲーム利用時間に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。例えば、判定部１１３は、予め設定された期間において、ユーザのゲーム利用時間が所定利用時間より長い場合に、当該ユーザがゲームを活性化させると判定する。

また、判定部１１３は、ユーザ毎に、ユーザ又は当該ユーザが属するグループのゲーム結果に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。例えば、判定部１１３は、ユーザ又はユーザが属するグループが、特定のゲーム結果（例えば、「勝ち」）に達するまでゲームを利用している場合に、当該ユーザがゲームを活性化させると判定する。

また、判定部１１３は、ユーザ毎に、ユーザのイベントの参加状況に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。例えば、判定部１１３は、ユーザ毎に、ユーザのイベントの参加状況に関するＳＮＳ情報に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。ＳＮＳ情報は、ユーザのイベントの参加状況に関する投稿回数を含む。例えば、ＳＮＳ情報は、イベントＡ、イベントＢ、イベントＣなどの参加に関する投稿回数や、友人とのコミュニケーション回数（「いいね」の回数や、返信コメント欄の回数）などである。例えば、判定部１１３は、この回数が所定数より多いと活性化するユーザと判定する。言い換えると、判定部１１３は、ユーザ毎に、ユーザのイベントの参加状況に関する投稿回数に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。例えば、判定部１１３は、予め設定された期間において、ユーザのイベントの参加状況に関する投稿回数が所定数より多い場合に、当該ユーザがゲームを活性化させると判定する。

判定部１１３は、ユーザ毎に、ユーザのイベントの実行状況に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。例えば、判定部１１３は、ユーザ毎に、ユーザのイベントの実行状況に関するＳＮＳ情報に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。ＳＮＳ情報は、ユーザのイベントの実行状況に関する投稿回数を含む。例えば、ＳＮＳ情報は、イベントＡを実行に関する投稿回数（実行した、勝った、負けた、宝物を獲得した等の投稿回数）や、イベントＡを実行の投稿に対して友人とのコミュニケーションを行った回数（「いいね」の回数や、返信コメント欄の回数）などである。例えば、判定部１１３は、この回数が所定数より多いと活性化するユーザと判定する。言い換えると、判定部１１３は、ユーザ毎に、ユーザのイベントの実行状況に関する投稿回数に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。例えば、判定部１１３は、予め設定された期間において、ユーザのイベントの実行状況に関する投稿回数が所定数より多い場合に、当該ユーザがゲームを活性化させると判定する。

また、判定部１１３は、ユーザ毎に、ユーザ又は当該ユーザが属するグループが行ったイベントの成功可否に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。例えば、判定部１１３は、ユーザ又はユーザが属するグループが、イベントが成功するまでゲームを利用している場合に、当該ユーザがゲームを活性化させると判定する。

また、判定部１１３は、ユーザ毎に、ユーザ又は当該ユーザが属するグループが行ったイベントの参加時間に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。例えば、判定部１１３は、予め設定された期間において、ユーザ又は当該ユーザが属するグループが行ったイベントの参加時間が所定参加時間より長い場合に、ユーザがゲームを活性化させると判定する。

また、判定部１１３は、ユーザ毎に、ユーザの識別情報に対応付けられた当該ユーザの友人数に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。また、判定部１１３は、ユーザ毎に、ユーザが友人と行ったコミュニケーションの数に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。例えば、判定部１１３は、予め設定された期間において、ユーザが友人と行ったコミュニケーションの数が所定数より多い場合に、当該ユーザがゲームを活性化させると判定する。

また、判定部１１３は、ユーザの識別情報毎に、ユーザの活性化情報に基づいて当該ユーザを第１から第Ｎ（Ｎ≧３）のいずれかの活性化レベルに判定する処理を行うようにしてもよい。

また、判定部１１３は、設定された期間におけるユーザのアイテムの課金額、ユーザのアイテムの保有数、設定された期間におけるユーザのゲーム利用時間、設定された期間におけるユーザのイベントの参加状況に関するＳＮＳサーバへの投稿回数、設定された期間におけるユーザのイベントの実行状況に関するＳＮＳサーバへの投稿回数、設定された期間におけるユーザ又は当該ユーザが属するグループが行ったイベントの参加時間、設定された期間におけるユーザ又は当該ユーザが属するグループが行ったイベントの実行時間、設定された期間におけるユーザが友人と行ったコミュニケーションの数、の少なくとも１つに基づいて活性化数値を算出し、当該活性化数値が所定数値より高い場合に、当該ユーザがゲームを活性化させると判定してもよい。

表示情報生成部１１４は、表示内容が配置された表示情報を生成する処理を行う。例えば、表示情報生成部１１４は、ユーザの端末２０からグループの生成要求を受信した場合に、グループのメンバー候補である他のユーザを配置した表示情報を生成する処理を行う。例えば、表示情報生成部１１４は、ゲームを活性化させると判定された少なくとも一人の他のユーザをメンバー候補として配置した表示情報を生成する処理を行う。

なお、表示情報生成部１１４は、表示内容（ゲーム画面の内容、例えば、メッセージ、画像、リンクなど）、表示内容の配置（構成）が決定された表示情報（ゲーム画面の情報、ページ情報）を生成する。表示情報は、ＨＴＭＬ、ＦＬＡＳＨ、ＣＧＩ、ＰＨＰ、ｓｈｏｃｋｗａｖｅ、Ｊａｖａ（登録商標）アプレット、ＪａｖａＳｃｒｉｐｔ（登録商標）など様々な言語で作られた情報であり、端末２０のＷｅｂブラウザ等は、表示情報に基づき当該表示内容を表示部２９０に表示することが可能である。

ゲーム処理部１１５は、端末２０から本実施形態のゲームプログラム（ゲームアプリケーション）の実行命令要求を受信すると、当該ゲームプログラムを実行する処理を行う。例えば、ゲーム処理部１１５は、ゲームに関する各種処理（例えば、抽選処理（ガチャ）、バトル処理（対戦処理）、イベント処理その他のゲーム演算処理）を行う。

例えば、ゲーム処理部１１５は、ユーザの端末から当該ユーザの抽選要求（ガチャ実行要求）を受け付けた場合に、記憶部１７０に記憶された提供用の複数のアイテムの中からランダムに一のアイテムを選択する処理を行う。

なお、本実施形態では、サーバ１０においてゲーム処理を実行しているが、ゲーム処理部１１５の全部または一部の処理を端末２０において行うようにしてもよい。かかる場合には、サーバ２０から、当該ゲーム処理部１１５のプログラムを端末２０に送信し、端末２０のゲーム処理部２１２がゲーム処理を実行する。

アイテム取得制御部１１６は、ゲーム中に使用するアイテムを記憶部１７０に記憶し、当該アイテムをユーザ又は当該ユーザが属するグループに取得させるための制御を行う。ここで、アイテムをユーザに取得させるための制御とは、提供用のアイテムを、当該ユーザの識別情報に対応づけて当該ユーザのアイテム（ユーザの所有アイテム、取得アイテム）として対応付ける処理を行うことである。また、アイテムをユーザが属するグループに取得させるための制御とは、提供用のアイテムを、グループの識別情報又はグループに属する各ユーザの識別情報に対応づけて当該ユーザのアイテムとして対応付ける処理を行うことである。

例えば、アイテム取得制御部１１６は、ユーザからの課金によって当該アイテムを当該ユーザに取得させるための制御を行うようにしてもよい。また、アイテム取得制御部１１６は、ゲーム中に、ユーザに無料でアイテムを取得させるための制御を行うようにしてもよい。

アイテム使用制御部１１７は、ゲーム中に使用するアイテムを記憶部１７０に記憶し、当該アイテムをユーザ又は当該ユーザが属するグループに使用させるための制御を行う。

アイテムを使用させるとは、ユーザが取得した複数のアイテムのうち、ユーザキャラクタに効果を発生させる一のアイテムの選択を受け付けて、ゲーム中に当該受け付けたアイテムの効果を発生させることである。例えば、ユーザが選択した一のアイテムに基づき、ユーザのキャラクタのパラメータを変動させる（攻撃力を増加させる）。なお、ゲーム中に使用するアイテムは１つに限らず、複数であってもよい。

イベント参加制御部１１８は、ユーザの端末２０からイベントの参加要求を受信した場合に、ゲーム中の当該イベントに当該ユーザを参加させるための制御を行う。

また、イベント実行部１１９は、ユーザの端末２０からイベントの実行要求を受信した場合に、ゲーム中の当該イベントを実行させるための制御を行う。

グループ生成部１２０は、複数のユーザで構成されるグループを生成する処理を行う。例えば、グループ生成部１２０は、ゲームを活性化させると判定された少なくとも一人のユーザを含むグループを生成する処理を行う。例えば、グループ生成部１２０は、ゲームを活性化させると判定された複数のユーザで構成されるグループを生成する処理を行うようにしてもよい。また、グループ生成部１２０は、第Ｍ（Ｎ＞Ｍ≧１、Ｎ≧３）の活性化レベルのユーザと、第Ｍ＋１の活性化レベルのユーザで構成されるグループを生成してもよい。また、グループ生成部１２０は、ユーザと、メンバー候補から選択された他のユーザとを含むグループを生成してもよい。

３−２．端末
入力部２６０は、ユーザからの入力情報を入力するための機器であり、ユーザの入力情報を処理部に出力する。本実施形態の入力部２６０は、ユーザの入力情報（入力信号）を検出する検出部を備える。入力部２６０は、例えば、レバー、ボタン、ステアリング、マイク、タッチパネル型ディスプレイ、キーボード、マウスなどがある。

また、入力部２６０は、３軸の加速度を検出する加速度センサや、角速度を検出するジャイロセンサ、撮像部を備えた入力機器でもよい。例えば、入力機器は、ユーザが把持して動かすものであってもよいし、ユーザが身につけて動かすものであってもよい。また、入力機器には、ユーザが把持する刀型コントローラや銃型コントローラ、あるいはユーザが身につける（ユーザが手に装着する）グローブ型コントローラなど実際の道具を模して作られたコントローラも含まれる。また入力機器には、入力機器と一体化されているゲーム装置、携帯型ゲーム装置、携帯電話なども含まれる。本実施形態の端末は、複数の入力部２６０を備えていてもよい。

記憶部２７０は、処理部２００や通信部２９６などのワーク領域となるもので、その機能はＲＡＭ（ＶＲＡＭ）などにより実現できる。

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

なお、本実施形態では、サーバ１０が有する情報記憶媒体１８０や記憶部１７０に記憶されている本実施形態の各部としてコンピュータを機能させるためのプログラムやゲームデータを、ネットワークを介して受信し、受信したプログラムやデータを情報記憶媒体２８０に記憶する。サーバ１０から受信したプログラムやデータを記憶部２７０に記憶してもよい。このようにプログラムやデータを受信してネットワークシステムを機能させる場合も本発明の範囲内に含む。

表示部２９０は、本実施形態により生成された画像を出力するものであり、その機能は、ＣＲＴ、ＬＣＤ、タッチパネル型ディスプレイ、或いはＨＭＤ（ヘッドマウントディスプレイ）などにより実現できる。音出力部２９２は、本実施形態により生成された音を出力するものであり、その機能は、スピーカ、或いはヘッドフォンなどにより実現できる。

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

処理部２００（プロセッサ）は、入力部２６０からの入力情報やプログラムなどに基づいて、ゲーム処理、表示制御、画像生成処理、或いは音生成処理などの処理を行う。

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

処理部２００は、通信制御部２１０、Ｗｅｂブラウザ２１１、ゲーム処理部２１２、表示制御部２１３、描画部２２０、音生成部２３０を含む。なおこれらの一部を省略する構成としてもよい。

通信制御部２１０は、サーバ１０、ＳＮＳサーバ３０、課金サーバ４０それぞれとデータを送受信する処理を行う。また、通信制御部２１０は、サーバ１０から受信したデータを記憶部２７０に格納する処理、受信したデータを解析する処理、その他のデータの送受信に関する制御処理等を行う。なお、通信制御部２１０は、サーバの宛先情報（ＩＰアドレス、ポート番号）を情報記憶媒体２８０に記憶し、管理する処理を行うようにしてもよい。また、通信制御部２１０は、ユーザからの通信開始の入力情報を受け付けた場合に、サーバ１０との通信を行うようにしてもよい。

特に、通信制御部２１０は、サーバ１０或いはＳＮＳサーバ３０にユーザの識別情報を送信して、ユーザ情報に関するデータ（ユーザのＷｅｂページ、表示情報等）をサーバ１０或いはＳＮＳサーバ３０から受信する処理を行う。例えば、通信制御部２１０は、ユーザと友人関係にある他のユーザの情報（他のユーザ名、他のユーザの掲示情報など）を含むデータを、サーバ１０或いはＳＮＳサーバ３０から受信する処理を行う。

なお、通信制御部２１０は、所定周期でサーバ１０やＳＮＳサーバ３０とデータ送受信を行ってもよいし、入力部２６０からの入力情報を受け付けた場合に、サーバ１０やＳＮＳサーバ３０とデータ送受信を行ってもよい。特に、本実施形態の通信制御部２１０は、表示情報を、サーバ１０から受信する処理を行う。

例えば、本実施形態の通信制御部２１０は、ユーザ識別情報とサーバ１０に対して表示情報のアクセス要求を送信し、当該サーバ１０から表示情報を受信する処理を行う。

特に、本実施形態の通信制御部２１０は、グループの生成要求をサーバ１０に送信する処理を行う。また、通信制御部２１０は、サーバ１０からグループのメンバー候補を含む表示情報を受信し、入力部２６０からの入力情報に基づき当該グループのメンバー候補から選択されたメンバーの情報を、サーバ１０に送信してもよい。また、通信制御部２１０は、サーバ１０から生成されたグループに属する各ユーザの情報を受信するようにしてもよい。

Ｗｅｂブラウザ２１１は、Ｗｅｂページ（表示情報）を閲覧するためのアプリケーションプログラムであって、Ｗｅｂサーバ（サーバ１０）から、ＨＴＭＬファイルや画像ファイル等をダウンロードし、レイアウトを解析して表示制御する。また、Ｗｅｂブラウザ２１１は、入力フォーム（リンクやボタンやテキストボックス等）を用いてデータをＷｅｂサーバ（サーバ１０）に送信する。

本実施形態のＷｅｂブラウザ２１１は、ブラウザゲームを実現することができる。例えば、Ｗｅｂブラウザ２１１は、Ｗｅｂサーバ（サーバ１０）から受信したＪａｖａＳｃｒｉｐｔ（登録商標）、ＦＬＡＳＨ、Ｊａｖａ（登録商標）等で記述されたプログラムを実行するものであってもよい。

端末２０は、Ｗｅｂブラウザ２１１によって、インターネットを介してＵＲＬによって指定されたＷｅｂサーバからの情報を表示させることができる。例えば、端末２０は、サーバ１０から受信した表示情報（ＨＴＭＬ等のデータ）をＷｅｂブラウザ２１１によって表示させることができる。

ゲーム処理部２１２は、種々のゲーム演算処理を行う。例えば、ゲーム開始条件が満たされた場合にゲームを開始する処理、ゲームを進行させる処理、ゲーム終了条件が満たされた場合にゲームを終了する処理などがある。

また、ゲーム処理部２１２は、ユーザキャラクタ、建物、球場、車、樹木、柱、壁、マップ（地形）などの表示物を表す各種オブジェクト（ポリゴン、自由曲面又はサブディビジョンサーフェスなどのプリミティブで構成されるオブジェクト）をオブジェクト空間に配置設定する処理を行うようにしてもよい。

ここでオブジェクト空間とは、仮想空間であり、２次元空間、３次元空間の両方を含む。２次元空間とは、例えば２次元座標（Ｘ，Ｙ）においてオブジェクトが配置される空間であり、３次元空間とは、例えば３次元座標（Ｘ，Ｙ，Ｚ）においてオブジェクトが配置される空間である。例えば、オブジェクト空間設定部は、オブジェクト空間を３次元空間とした場合には、ワールド座標系にオブジェクトを配置する。また、例えば、ワールド座標系でのオブジェクトの位置や回転角度（向き、方向と同義であり、例えば、ワールド座標系でのＸ、Ｙ、Ｚ軸の各軸の正方向からみて時計回りに回る場合における回転角度）を決定し、その位置（Ｘ、Ｙ、Ｚ）にその回転角度（Ｘ、Ｙ、Ｚ軸回りでの回転角度）でオブジェクトを配置する。

例えば、ゲーム処理部２１２は、オブジェクト空間において、ユーザキャラクタを移動させる処理を行うようにしてもよい。すなわち入力部２６０によりユーザが入力した入力情報や、プログラム（移動・動作アルゴリズム）や、各種データ（モーションデータ）などに基づいて、ユーザキャラクタをオブジェクト空間内で移動させたり、オブジェクトを動作（モーション、アニメーション）させたりする処理を行う。具体的には、ユーザキャラクタの移動情報（位置、回転角度、速度、或いは加速度などの移動パラメータ）や動作情報（オブジェクトを構成する各パーツの位置、或いは回転角度）を、１フレーム（例えば、１／６０秒）毎に順次求める処理を行うようにしてもよい。なおフレームは、ユーザキャラクタの移動・動作処理や画像生成処理を行う時間の単位である。

特に、本実施形態の表示制御部２１３は、受信した表示情報を、表示部２９０に表示する処理を行う。例えば、表示制御部２１３は、サーバ１０から受信したデータ（Ｗｅｂデータ、ＨＴＭＬ言語等で作成された表示情報）を、Ｗｅｂブラウザ２１１などによって表示部２９０に表示させる処理を行う。表示制御部２１３は、ゲーム処理部２１２によるゲーム処理内容を表示させる表示制御を行ってもよいし、描画部２２０において生成された画像を表示部２９０に表示させる表示制御を行ってもよい。

描画部２２０は、処理部２００で行われる種々の処理（例えば、ゲーム処理）の結果に基づいて描画処理を行い、これにより画像を生成し、表示制御部２１３によって表示部２９０に出力する。描画部２２０が生成する画像は、いわゆる２次元画像であってもよいし、いわゆる３次元画像であってもよい。

なお、いわゆる３次元ゲーム画像を生成する場合には、まずオブジェクト（モデル）の各頂点の頂点データ（頂点の位置座標、テクスチャ座標、色データ、法線ベクトル或いはα値等）を含むオブジェクトデータ（モデルデータ）が入力され、入力されたオブジェクトデータに含まれる頂点データに基づいて、頂点処理（頂点シェーダによるシェーディング）が行われる。なお頂点処理を行うに際して、必要に応じてポリゴンを再分割するための頂点生成処理（テッセレーション、曲面分割、ポリゴン分割）を行うようにしてもよい。

音生成部２３０は、処理部２００で行われる種々の処理の結果に基づいて音処理を行い、ＢＧＭ、効果音、又は音声などのゲーム音を生成し、音出力部２９２に出力する。例えば、サーバ１０から受信した音データを音出力部２９２に出力するようにしてもよい。

３−３．ＳＮＳサーバの構成例
図３に本実施形態のＳＮＳサーバ３０の機能ブロック図の例を示す。本実施形態のＳＮＳサーバ３０は図４の構成要素（各部）の一部を省略した構成としてもよい。記憶部３７０は、処理部３００や通信部３９６などのワーク領域となるもので、その機能はＲＡＭ（ＶＲＡＭ）などにより実現できる。記憶部３７０は、データベースを含む。

また、記憶部３７０には、本実施形態のネットワークシステムに参加する複数のユーザそれぞれのユーザ情報３７２が記憶される。例えば、記憶部３７０には、複数のユーザそれぞれのユーザの識別情報に対応づけて、ユーザパスワードなどをユーザ情報３７２として格納する。また、記憶部３７０には、ユーザが投稿した掲示情報、ユーザのプロフィール情報等を、当該ユーザのユーザ情報１７５として記憶される。

また、記憶部３７０には、ユーザと友人関係にある他のユーザを特定するための情報を、友人情報３７３として記憶部３７０に記憶される。つまり、ユーザの識別情報毎に、ユーザの識別情報と友人関係にある１又は複数の他のユーザの識別情報とを対応づけて（関連付けて）、記憶部３７０に記憶する。

ユーザ情報３７２は、ユーザの識別情報とともにユーザの識別情報に対応づけられる種々の情報を含む。本実施形態では、ユーザの識別情報に対応づけられる情報として、端末識別情報、プロフィール情報、メッセージ掲示情報等が含まれる。

ユーザの識別情報は、ユーザ名、ユーザＩＤ、ユーザアカウント、メールアドレス等などユーザを識別可能な情報であり、各ユーザに割り振られた識別ＩＤ（ＳＮＳＩＤ）でもよい。端末識別情報は、端末２０に割り振られた識別ＩＤである。この端末識別情報をユーザの識別情報として用いてもよい。

プロフィール情報は、ゲームアプリケーションにユーザがユーザ登録を行う際に入力するプロフィールに基づいて生成・登録される情報である。例えば、プロフィール情報３２０は、ユーザのユーザアカウント（ユーザ名）、パスワード、ニックネーム、性別、年齢（生年月日）、在住する都道府県、自己紹介文などの情報を含む。

掲示情報は、掲示情報提供処理を行うＳＮＳサーバ（掲示サイト、投稿サイト）のユーザアカウントやパスワード、掲示設定（掲示条件（掲示タイミング）の設定、掲示するメッセージをカスタマイズするか否か等）、メッセージ文（カスタマイズする場合のメッセージ文、応援宛先）等の情報を含む。

ＳＮＳサーバ３０は、ユーザの識別情報に関連づけて、掲示情報を記憶部に記憶する。そして、ＳＮＳサーバ３０は、ユーザの端末２０からのアクセス要求に基づいて掲示情報を端末に送信する処理を行う。

ＳＮＳサーバ３０は、ユーザと友人関係にある他のユーザを特定するための情報を、友人情報３７３として記憶部３７０に記憶する。つまり、ユーザの識別情報毎に、ユーザの識別情報と友人関係にある１又は複数の他のユーザの識別情報とを対応づけて（関連付けて）記憶する。

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

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

処理部３００（プロセッサ）は、情報記憶媒体３８０に記憶されるプログラム等に基づいて、処理を行う。具体的には、端末からの要求に応じてサービスを提供する。また、処理部３００は記憶部３７０内の主記憶部３７２をワーク領域として各種処理を行う。処理部３００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ等）、ＡＳＩＣ（ゲートアレイ等）などのハードウェアや、プログラムにより実現できる。

特に、本実施形態のＳＮＳサーバ３０の処理部３００は、通信制御部３１０、Ｗｅｂ処理部３１１、ユーザ情報制御部３１２、友人情報制御部３１３を含む。なおこれらの一部を省略する構成としてもよい。

通信制御部３１０は、サーバ１０、端末２０、課金サーバ４０とネットワークを介してデータを送受信する処理を行う。例えば、通信制御部３１０は、ユーザの端末２０からの要求に基づいて、当該ユーザの情報を当該端末２０に送信する。また、通信制御部３１０は、当該ユーザに関連付けられている他のユーザの情報を、当該ユーザの端末２０に送信する処理を行う。

Ｗｅｂ処理部３１１は、Ｗｅｂサーバとして機能する。例えば、Ｗｅｂ処理部３１１は、ＨＴＴＰ等の通信プロトコルを通じて、端末２０にインストールされているＷｅｂブラウザ２１１の要求に応じてデータを送信する処理、端末２０のＷｅｂブラウザ２１１によって送信されるデータを受信する処理を行う。

ユーザ情報制御部３１２は、記憶部３７０にユーザ情報を登録する処理、記憶部３７０に記憶されたユーザ情報を更新する処理、記憶部３７０に記憶されたユーザ情報等を、削除処理等を行う。

友人情報制御部３１３は、複数のユーザを友人関係として登録する処理や、登録された複数のユーザの友人関係を解除する処理を行う。

例えば、友人情報制御部３１３は、第１のユーザ端末から第２のユーザを友人として登録する登録要求及び当該第２のユーザ端末から第１のユーザを友人として登録する登録要求に基づいて、第１のユーザの識別情報に対応づけて第２のユーザの識別情報を友人関係として登録すると共に、第２のユーザの識別情報に対応づけて第１のユーザの識別情報を友人関係として登録する。

また、友人情報制御部３１３は、友人関係として登録された複数のユーザのうち、いずれか一方のユーザが解除の要求を受け付けた場合には、当該複数のユーザの友人関係を解除する処理を行う。

また、ＳＮＳサーバ３０は、ユーザＡのユーザＢに対するフォローワーを登録する登録要求情報を、当該ユーザＡの端末２０Ａから受信した場合に、ユーザＡの識別情報に対応づけて、ユーザＢの識別情報をフォローワーとして登録（フォローワー登録）するようにしてもよい。

また、ＳＮＳサーバ３０は、ユーザＡのユーザＢに対するフォローワーを解除する解除要求情報を、当該ユーザＡの端末２０Ａから受信した場合に、ユーザＡの識別情報に対応づけてフォローワー登録されているユーザＢの識別情報を削除するようにしてもよい。

４．本実施形態の処理の手法
４−１．概要
本実施形態では、複数のユーザの端末とネットワークを介してデータを送受信し、複数のユーザで構成されるグループを生成してゲームを行わせるサーバ１０に関するものである。サーバ１０は、ユーザの識別情報毎に、ユーザがゲームを活性化させるか否かを判定するための活性化情報を記憶部１７０に記憶する処理を行い、ユーザの識別情報毎に、ユーザの活性化情報に基づいて当該ユーザがゲームを活性化させるか否かを判定する。そして、ゲームを活性化させると判定されたユーザを少なくとも含むグループを生成する処理を行う。このようにすれば、グループに、ゲームを活性化させると判定された少なくとも一人のユーザが含まれているので、そのグループでゲームを行わせる場合に、ゲームを活性化させることが可能となる。

４−２．活性化情報の説明
本実施形態のサーバ１０は、ユーザの識別情報毎に、活性化情報を記憶部１７０に記憶する。この活性化情報とは、ユーザがゲームを活性化させるか否かを判定するための情報であり、活性化情報は、ユーザのゲーム状況、ＳＮＳ情報（ＳＮＳ利用状況）等を含む。例えば、ゲームを活性化させるとは、言い換えると、グループに属する各ユーザの意思決定に影響を与えることである。つまり、「ゲームを活性化させるユーザ」は他のユーザに与える影響度が「ゲームを活性化させないユーザ」よりも大きいことを示す。また、「ゲームを活性化させるユーザ」は、ＳＮＳやソーシャルゲームにおいてオピニオンリーダーの役割を果たすユーザであってもよい。

４−２−１．ゲーム状況
本実施形態のゲーム状況とは、ゲームに関する状況を示す情報であり、例えば、アイテムの取得状況、アイテムの使用状況、課金情報（課金状況）、ゲーム情報（例えば、勝敗の状況）等である。

（Ａ）アイテムの取得状況
本実施形態のゲーム状況は、アイテムの取得状況を含む。なお、アイテムの取得状況は、ユーザのアイテムの取得状況、又は、ユーザが属するグループのアイテムの取得状況を含む。

サーバ１０又はＳＮＳサーバ３０がユーザにアイテムを取得させる（提供する）とは、当該ユーザの識別情報に対応づけてアイテムをサーバ１０の記憶部や情報記憶媒体等に登録（記憶）すること、サーバ１０又はＳＮＳサーバ３０が端末２０にアイテムを送信し、端末２０が端末２０の記憶部や情報記憶媒体等に受信したアイテムを登録（記憶）すること等である。

ここで、アイテムの取得状況とは、ユーザが取得したアイテムに関する情報であり、例えば、取得アイテムの保有数、取得アイテムの種類情報等である。例えば、サーバ１０は、図４に示すように、ユーザの識別情報毎に、ユーザが過去に取得したアイテムの保有数を記憶している。ここで、ユーザが過去に取得したアイテムの保有数とは、現時点を境に過去にユーザが取得したアイテム（例えば、ガチャの実行によって得られたアイテムや、ゲーム中に取得したアイテム）の総数を示す。例えば、ｕｓｅｒＡの過去に取得したアイテムの保有数が１５であることを示している。

また、サーバ１０は、図５に示すように、ユーザの識別情報毎に、ユーザが過去に取得したアイテムの種類情報を記憶している。ここで、ユーザが過去に取得したアイテムの種類情報とは、現時点を境にユーザが過去に取得した各アイテムの種類情報を示す。例えば、ｕｓｅｒＡが取得したカードＡ、カードＧ、カードＢのアイテムの種類が「カード」であること、薬草のアイテムの種類が「回復」であること、剣のアイテの種類が「攻撃」であることを示している。

本実施形態では、ユーザからの課金によって当該アイテムを当該ユーザに取得させるための制御を行うようにしてもよいし、ゲーム中に、ユーザに無料でアイテムを取得させるための制御を行うようにしてもよい。

例えば、図５に示すように、ユーザが課金によってアイテムを取得した場合には課金アイテムフラグを「１」に設定し、ユーザが課金によらずに無料でアイテムを取得した場合には課金アイテムフラグを「０」に設定する。例えば、ｕｓｅｒＡの取得アイテムの「カードＡ」は課金アイテムフラグが１であるので、ｕｓｅｒＡが課金によって「カードＡ」を取得したことを示している。また、ｕｓｅｒＢの取得アイテムの「カードＤ」は課金アイテムフラグが０であるので、ｕｓｅｒＢが無料で（課金によらずに）「カードＤ」を取得したことを示している。

（Ｂ）アイテムの使用状況
本実施形態のゲーム状況は、アイテムの使用状況を含む。なお、アイテムの使用状況は、ユーザのアイテムの使用状況、又は、ユーザが属するグループのアイテムの使用状況を含む。

ここで、アイテムの使用状況とは、ユーザが取得したアイテムのうち、ゲームやイベントで使用するアイテム（或いは、使用済みのアイテム）に関する情報であり、例えば、使用アイテム数、使用アイテムの種類情報等である。例えば、ユーザの取得アイテムが５０ある場合に、ゲーム中に使用できるアイテムが３つに限られている場合には、当該３つのアイテムが使用アイテムとなる。

なお、サーバ１０がユーザにアイテムを使用させるとは、ゲーム中にユーザのキャラクタに使用アイテムの効果を発生させることであり、例えば、ユーザが使用アイテムとして選択した１又は複数アイテムの各情報に基づき、ユーザのキャラクタのパラメータを変動させる（攻撃力を増加させる）等である。

例えば、サーバ１０は、図６に示すように、ユーザの識別情報毎に、ユーザの使用アイテムの数を記憶している。例えば、ｕｓｅｒＡの使用アイテムの数が３であることを示している。

また、サーバ１０は、図７に示すように、ユーザの識別情報毎に、ユーザが現在使用している使用アイテムの種類情報を記憶している。ここで、例えば、ｕｓｅｒＡが現在使用しているアイテムがカードＡ、カードＢ、カードＧであり、各アイテムの種類が「カード」であることを示している。

また、サーバ１０は、図７に示すように、使用アイテムが、ユーザが課金によって取得した課金アイテムである場合には、課金アイテムフラグを「１」に設定し、ユーザが課金によらずに無料でアイテムを取得した場合には課金アイテムフラグを「０」に設定する。例えば、ｕｓｅｒＡの使用アイテムの「カードＡ」は課金アイテムフラグが１であるので、ｕｓｅｒＡが課金で取得した「カードＡ」を使用していること示している。また、ｕｓｅｒＢの取得アイテムの「カードＤ」は課金アイテムフラグが０であるので、ｕｓｅｒＢが、無料で取得した「カードＤ」を使用していること示している。

（Ｃ）課金情報
本実施形態のゲーム状況は、ユーザのアイテムの課金情報を含む。本実施形態において課金とは、アイテムや仮想通貨に料金を課すことをいう。例えば、本実施形態での課金とは、アイテムを仮想通貨で料金を課すこと、仮想通貨を含むアイテムをリアルマネーで料金を課すこと等である。

本実施形態では、例えば、サーバ１０又はＳＮＳサーバ３０が、ユーザの端末２０からアイテムの仮想通貨の代価を徴収し、当該アイテムをユーザに提供する。サーバ１０がアイテムの代価を徴収した場合には、課金情報を、サーバ１０の記憶部１７０に記憶する処理を行う。また、ＳＮＳサーバ３０がアイテムの代価を徴収した場合には、課金情報をサーバ１０に送信し、サーバ１０が、サーバ１０の記憶部１７０に受信した課金情報を記憶する処理を行う。

また、本実施形態では、例えば、課金サーバ４０が、ユーザの端末２０からアイテムのリアルマネーの代価を徴収し、当該アイテムをユーザに提供する。課金サーバ４０がアイテムの代価を徴収した場合には、課金情報をサーバ１０に送信し、サーバ１０が、サーバ１０の記憶部１７０に課金サーバ４０から受信した課金情報を記憶する処理を行う。

また、本実施形態の課金情報（広義にはゲーム状況）は、課金に関する情報であり、例えば、ユーザが所持する仮想通貨額、購入したアイテム、購入額、購入日時、購入時のモード等を含む。本実施形態の課金情報は、ユーザ毎にユーザの識別情報に対応付けて課金情報をサーバ１０の記憶部１７０等に記憶する。例えば、サーバ１０は、データベースを用いて各ユーザの課金情報を管理してもよい。

図８は、ユーザの識別情報に対応付けて登録されている所持コイン（ユーザが所持する仮想通貨額）の一例を示す。例えば、ｕｓｅｒＡは２，０００コインを所持し、また、ｕｓｅｒＢが所持する仮想通貨額は零（コインを所持していない）、ｕｓｅｒＣは１００コインを所持していることを示す。

また、本実施形態の課金情報は、図９に示すように、ユーザが過去に購入したアイテム、当該アイテムの購入額、購入日時、購入時のモードを含む。例えば、サーバ１０の記憶部１７０に、ｕｓｅｒＡが、ゲーム終了モード（負けでゲームを終了したモード）で、ガチャＡ（抽選プログラムＡ）の実行権限を１００コインで２０１２年１月１３日２３時５５分２０秒に購入した履歴が記憶される。また、図９の例では、ｕｓｅｒＢの購入履歴がなくＮＵＬＬの状態となっている。

なお、「購入時のモード」とは、ユーザがアイテムを購入したときのモード（期間）である。ここで、購入時のモードについて説明すると、例えば、図１０に示すように、サーバ１０において、ユーザがログインしてから次のモードに以降するまで（例えば、Ｔ１〜Ｔ２期間）を「ログイン」モードに設定し、無料ガチャ（無料で実行権限が与えられるガチャ）を実行してから次のモードに以降するまで（例えば、Ｔ２〜Ｔ３期間）を「無料ガチャ」モードに設定する。

また、ゲームを開始（例えば、敵との対戦ゲームプログラムを実行）してから次のモードに以降するまで（例えば、Ｔ３〜Ｔ４期間、Ｔ５〜Ｔ６期間）を「ゲーム開始」モードに設定し、ゲームを終了（例えば、敵との対戦ゲームプログラムを終了）してから次のモードに以降するまで（例えば、Ｔ４〜Ｔ５期間、Ｔ６〜Ｔ７期間）を「ゲーム終了」モードに設定する。

また、イベントを開始（例えば、イベントプログラムを実行）してから次のモードに以降するまで（例えば、Ｔ７〜Ｔ８期間）を「イベント開始」モードに設定し、イベントを終了（例えば、イベントプログラムを終了）してから次のモードに以降するまで（例えば、Ｔ８〜Ｔ９期間）を「ゲーム終了」モードに設定する。また、ログアウト後のモードを、「ログアウト」モードに設定する。

なお、「ゲーム終了」モードでは、「ゲーム終了（負け）」モード、「ゲーム終了（勝ち）」モードのように、ゲーム結果（例えば、勝敗の結果）に応じてモードを設定してもよい。

そして、サーバ１０は、購入したアイテムの購入時にモードを、当該アイテムに対応づけて記憶部１７０に記憶する。例えば、図１０に示すように、ｕｓｅｒＡが、「ゲーム終了（負け）」モードのＡ時点で、ガチャＡ（抽選プログラムＡ）の実行権限を購入した場合には、ガチャＡの購入時のモードは「ゲーム終了（負け）」となる。

（Ｄ）ゲーム情報
本実施形態のゲーム状況は、ユーザのゲーム情報を含む。例えば、ゲーム情報は、ゲーム処理に用いられる情報であり、例えば、各種ゲームパラメータ、ゲーム利用時間（ログイン日時、ログアウト日時）、ゲーム結果等を含む。本実施形態のゲーム情報は、各ユーザの識別情報に対応付けてゲーム情報をサーバ１０の記憶部１７０等に記憶されている。例えば、サーバ１０は、データベースを用いて各ユーザのゲーム情報を管理してもよい。

図１１は、ゲーム情報の一例を示す。図１１に示すように、ゲーム情報は、ユーザキャラクタの「レベル」、「ポイント」、「カードの数（アイテムの数）」、「仲間の数」、「ＨＰ」、「スタミナ」などのゲームパラメータを含む。なお、ゲームパラメータは、「ステージ」や、ユーザキャラクタの「攻撃力」「防御力」、カードの数など種々のパラメータを含んでいてもよい。

また、図１２に示すように、ゲーム情報は、ユーザ端末２０がサーバ１０にアクセスしてゲーム処理を行ったゲーム利用時間（ログイン日時、ログアウト日時）を含む。

本実施形態では、ユーザのログイン日時、ログアウト日時に基づいて、当該ユーザの所定期間（例えば、１週間）あたりの利用時間、利用時間帯、利用回数等を求めることができる。

図１３に示すように、本実施形態のゲーム情報は、ゲーム結果を含む。例えば、サーバ１０は、ユーザの識別情報に対応づけて、ゲーム結果を日時とともに記憶部１７０に記憶する。本実施形態のサーバ１０は、ユーザのゲーム結果に基づいて、当該ユーザの最新のゲーム結果を知ることができる。また、所定期間内（例えば、１週間以内）におけるユーザのゲーム結果を知ることができる。

また、本実施形態のゲーム情報は、ユーザキャラクタの服装情報を含む。例えば、サーバ１０は、端末２０からユーザキャラクタにシャツ、ズボンの洋服情報を着せる要求情報を受信した場合には、ユーザの識別情報に対応づけて当該洋服情報を記憶部１７０に記憶し、端末２０に、当該ユーザキャラクタに当該洋服情報を着せた画像情報を送信する。

（Ｅ）イベントの参加状況
また、ゲーム状況は、ユーザのイベントの参加状況を含む。イベントの参加状況は、ユーザが参加したイベントに関する情報であり、イベントの参加回数、参加時間、参加頻度等である。

本実施形態のサーバ１０は、ゲーム中に実行可能なイベントプログラムを用意しており、ユーザの端末２０からイベントの参加要求を受信した場合に、ゲーム中の当該イベントに当該ユーザを参加させるための制御を行う。イベントは、限定された期間に参加可能としてもよいし、期間に関係なく、常にユーザが参加できるイベントであってもよい。また、イベントは、一人のユーザが参加するものであってもよいし、ユーザが属するグループ（複数のユーザで構成されるグループ）が参加するものであってもよい。

なお、ユーザを参加させるための制御とは、当該ユーザの識別情報に対応づけて、参加イベントを登録することを意味する。図１４は、イベント参加状況の一例である。本実施形態では、図１４に示すように、ユーザの識別情報に対応づけて、ユーザが参加したイベント、及びイベントの開始日時と終了日時を登録している。例えば、ｕｓｅｒＡは、イベントＡ、Ｂ、Ｃ、Ｅに参加したことを示している。

つまり、本実施形態では、イベント参加状況を参照し、ユーザ毎に、ユーザが参加したイベントの数を求めることができる。また、本実施形態では、イベント参加状況を参照し、ユーザ毎に、ユーザが参加したイベント毎にイベントの参加時間を求めることができる。例えば、サーバ１０は、ｕｓｅｒＡが２０１２年１月２２日２０時１５分０１秒から２０１２年１月３１日２３時５９分５９秒までイベントＡに参加したことを読み取ることができる。

また、本実施形態では、イベント参加状況を参照し、ユーザ毎に、ユーザがイベントに参加する頻度を求めることができる。参加頻度とは、所定期間（例えば、１ヶ月）あたりにユーザが参加したイベントの数であり、例えば、サーバ１０は、２０１２年１月に、ｕｓｅｒＡは、イベントＡ、Ｂ、Ｃ、Ｅの４つのイベントに参加したと算出することができる。

（Ｆ）イベントの実行状況
また、ゲーム状況は、ユーザのイベントの実行状況を含む。イベントの実行状況は、ユーザが実行したイベントに関する情報であり、イベントの実行回数、実行時間、実行頻度、成功可否等である。

本実施形態のサーバ１０は、ゲーム中に実行可能なイベントプログラムを用意しており、ユーザの端末２０からイベントの実行要求を受信した場合に、ゲーム中の当該イベントを実行させるための制御を行う。イベントは、限定された期間に実行可能としてもよいし、期間に関係なく、常にユーザが実行できるイベントであってもよい。また、イベントは、一人のユーザが実行するものであってもよいし、ユーザが属するグループ（複数のユーザで構成されるグループ）が実行するものであってもよい。

なお、イベントを実行させるための制御とは、イベントのプログラムを実行することを意味する。例えば、サーバ１０は、ユーザが参加したクエストなどのイベントプログラムを実行すると、ユーザ端末２０からの入力信号を受信し、ユーザのキャラクタが、クエストの成功条件（例えば、１時間以内に敵のＨＰ値を０にする等）を満たすか否かを判断し、成功可否を判断する。

図１５は、イベント実行状況の一例である。本実施形態では、図１５に示すように、ユーザの識別情報に対応づけて、ユーザが実行したイベント、及びイベントプログラムを実行した開始日時と終了日時、及び、成功可否（実行結果）を登録している
つまり、本実施形態では、イベント実行状況を参照し、ユーザ毎に、ユーザが実行したイベントの数を求めることができる。また、本実施形態では、イベント実行状況を参照し、ユーザ毎に、ユーザが実行したイベント毎にイベントの実行時間を求めることができる。例えば、サーバ１０は、ｕｓｅｒＡが直近に実行したイベントが、イベントＡであり、２０１２年１月３１日２２時５２分２０秒から２０１２年１月３１日２３時５２分２０秒まで実行し、イベントに成功したことを読み取ることができる。

また、本実施形態では、イベント参加状況を参照し、ユーザ毎に、ユーザがイベントを実行する頻度を求めることができる。実行頻度とは、所定期間（例えば、１ヶ月）あたりにユーザが実行したイベントの数であり、例えば、サーバ１０は、２０１２年１月に、ｕｓｅｒＡが、３回イベントＡを実行したと算出することができる。

４−２−２．ＳＮＳ情報
本実施形態のＳＮＳ情報は、ＳＮＳサーバ３０の利用状況を示す情報であり、例えば、ＳＮＳサーバ３０に登録されているユーザの友人数や、コミュニケーション数、ゲームのイベントの参加・実行状況に関する情報等である。

（Ａ）友人数
本実施形態のＳＮＳ情報は、ＳＮＳサーバ３０に登録されているユーザの友人数を含む。例えば、サーバ１０は、図１６に示すように、ユーザ毎に、ユーザの識別情報に対応づけて、ＳＮＳサーバ３０に登録されている当該ユーザの友人数を、記憶部１７０に記憶している。なお、ユーザの友人とは、ＳＮＳサーバ３０に登録されている当該ユーザと友人関係（フレンド関係）にある他のユーザのことである。

（Ｂ）コミュニケーション数
本実施形態のＳＮＳ情報は、ＳＮＳサーバ３０に登録されているユーザが友人と行ったコミュニケーション数を含む。例えば、サーバ１０は、図１７に示すように、ユーザ毎に、ユーザの識別情報に対応づけて、ＳＮＳサーバ３０に登録されている当該ユーザが友人と行ったコミュニケーションの数を、記憶部１７０に記憶している。

ここで、ユーザ（ｕｓｅｒＡ）が友人と行ったコミュニケーションの数とは、図１８に示すようにユーザ（ｕｓｅｒＡ）が掲示板に投稿したメッセージ３１に対する友人との返信数である。

例えば、ｕｓｅｒＡが投稿したメッセージ３１に対するｕｓｅｒＣの肯定的評価３２が投稿された場合（「いいね」がクリックされた場合）、１回としてカウントする。なお、肯定的評価をした友人が二人いる場合には、２回としてカウントする。

また、ｕｓｅｒＡが投稿したメッセージ３１に対するｕｓｅｒＢの返信コメント３３を１回としてカウントする。なお、ｕｓｅｒＢが投稿した返信コメント３３に対するｕｓｅｒＡのコメント３４を１回としてカウントする。

なお、コミュニケーション数に、メールの送受信回数を含めてもよい。例えば、ユーザが友人宛に送信したメールを１回、友人から受信したメールを１回として、カウントしてもよい。

また、本実施形態のコミュニケーション数は、所定期間（予め設定された期間、例えば、現時点を含めて１日）あたりのコミュニケーションの数としてもよいし、サーバ１０が記憶している過去のコミュニケーション数であってもよい。

（Ｃ）イベントの参加状況に関するＳＮＳ情報
また、本実施形態のＳＮＳ情報は、ＳＮＳサーバ３０に登録されているユーザのイベントの参加状況に関するＳＮＳ情報を含む。例えば、ＳＮＳサーバ３０に登録されているユーザのイベントの参加状況に関するＳＮＳ情報とは、ユーザのイベントの参加状況に関する投稿回数や、ユーザのイベントの参加状況に関する投稿メッセージに対する友人とのコミュニケーション数（肯定的評価数（「いいね」の回数）や、返信コメントの回数）などである。

例えば、図１８に示すように、ｕｓｅｒＡがイベントＡに参加したことを示すメッセージ３１をｕｓｅｒＡの掲示板に投稿したとする。つまり、ｕｓｅｒＡの端末２０からＳＮＳサーバ３０にメッセージ３１を送信し、ＳＮＳサーバ３０はｕｓｅｒＡの画面でメッセージ３１を含む表示情報を生成する。なお、サーバ１０は、ｕｓｅｒＡの端末２０からイベントＡの参加要求を受信すると、ｕｓｅｒＡがイベントＡに参加したことを示すメッセージ３１をｕｓｅｒＡの掲示板に投稿してもよい。つまり、サーバ１０が、ＳＮＳサーバ３０にメッセージ３１を送信し、ＳＮＳサーバ３０はｕｓｅｒＡの画面でメッセージ３１を含む表示情報を生成してもよい。

本実施形態では、ｕｓｅｒＡがイベントＡに参加したことを示すメッセージ３１をｕｓｅｒＡの掲示板に投稿した場合に、１カウントし、メッセージ３１に対する肯定的評価数、返信コメント回数をカウントする。

具体的に説明すると、サーバ１０は、図１８に示すように、サーバ１０が管理するゲームの「ゲーム名」、「イベント名」及び「参加」を検索文字列として、サーバ１０が管理するゲームの「ゲーム名」、「イベント名」及び「参加」にヒットするメッセージを検索する。そして、サーバ１０は、（ア）検索されたメッセージの数と、（イ）そのメッセージに対する肯定的評価数、（ウ）そのメッセージに対する返信コメント回数を求め、合計数（（ア）〜（ウ）の合計）を、ユーザの「イベントの参加状況に関する投稿回数」として算出する。

サーバ１０は、予め設定された期間内（例えば、２４時間以内）に、各ユーザのイベントＡの参加状況に関するＳＮＳ回数を求めるようにしてもよい。なお、本実施形態では、サーバ１０が、ＳＮＳサーバ３０に対して、各ユーザ「イベントの参加状況に関する投稿回数」を要求し、ＳＮＳサーバ３０が、各ユーザの「イベントの参加状況に関する投稿回数」を算出し、算出結果である各ユーザの「イベントの参加状況に関する投稿回数」をサーバ１０に送信するようにしてもよい。

（Ｄ）イベントの実行状況に関するＳＮＳ情報
また、本実施形態のＳＮＳ情報は、ＳＮＳサーバ３０に登録されているユーザのイベントの実行状況に関するＳＮＳ情報を含む。例えば、ＳＮＳサーバ３０に登録されているユーザのイベントの実行状況に関するＳＮＳ情報とは、ユーザのイベントの実行状況に関する投稿回数や、ユーザのイベントの実行状況に関する投稿メッセージに対する友人とのコミュニケーション数（肯定的評価数（「いいね」の回数）や、返信コメントの回数）などである。

例えば、図１９に示すように、ｕｓｅｒＡがイベントＡを実行したことを示すメッセージ４５やイベントＡの成功可否（実行結果）のメッセージ４１をｕｓｅｒＡの掲示板に投稿したとする。つまり、ｕｓｅｒＡの端末２０からＳＮＳサーバ３０にメッセージ４５、４１を送信し、ＳＮＳサーバ３０はｕｓｅｒＡの画面でメッセージ４５、４１を含む表示情報を生成する。なお、サーバ１０は、ｕｓｅｒＡの端末２０からイベントＡの実行要求を受信すると、ｕｓｅｒＡがイベントＡを実行したことを示すメッセージ４５やイベントＡの成功可否（実行結果）のメッセージ４１をｕｓｅｒＡの掲示板に投稿してもよい。つまり、サーバ１０が、ＳＮＳサーバ３０にメッセージ４５、４１を送信し、ＳＮＳサーバ３０はｕｓｅｒＡの画面でメッセージ４５、４１を含む表示情報を生成してもよい。

本実施形態では、ｕｓｅｒＡがイベントＡを実行したことを示すメッセージ４５やイベントＡの成功可否（実行結果）のメッセージ４１をｕｓｅｒＡの掲示板に投稿した場合に、それぞれ１カウントし、メッセージ４５、４１それぞれに対する肯定的評価数、返信コメント回数をカウントする。

具体的に説明すると、サーバ１０は、図１９に示すように、サーバ１０が管理するゲームの「ゲーム名」、「イベント名」及び「実行」を検索文字列として、サーバ１０が管理するゲームの「ゲーム名」、「イベント名」及び「実行」にヒットするメッセージを検索する。そして、サーバ１０は、（ア）検索されたメッセージの数と、（イ）そのメッセージに対する肯定的評価数、（ウ）そのメッセージに対する返信コメント回数を求め、合計数（（ア）〜（ウ）の合計）を、ユーザの「イベントの実行状況に関する投稿回数」として算出する。

サーバ１０は、予め設定された期間内（例えば、２４時間以内）に、各ユーザのイベントＡの実行状況に関するＳＮＳ回数を求めるようにしてもよい。なお、本実施形態では、サーバ１０が、ＳＮＳサーバ３０に対して、各ユーザ「イベントの実行状況に関する投稿回数」を要求し、ＳＮＳサーバ３０が、各ユーザの「イベントの実行状況に関する投稿回数」を算出し、算出結果である各ユーザの「イベントの実行状況に関する投稿回数」をサーバ１０に送信するようにしてもよい。

４−２−３アイテムの説明
なお、本実施形態のアイテムとは、コンピュータやインターネットを介してユーザに提供可能なデジタルコンテンツであり、ゲーム中に使用される（ゲーム処理で用いられる）。例えば、アイテムは、ゲーム情報、画像情報、音声情報、ユーザキャラクタの服装情報、プログラムなど、所与の価値に対する情報とすることができる。

例えば、本実施形態において、アイテムを用いてユーザキャラクタが敵キャラクタと対戦ゲーム処理を行う場合には、当該アイテムの攻撃力や防御力に基づき、攻撃力、防御力を増加させる処理を行う。

また、アイテムの一例としてガチャ（仮想販売機、抽選処理プログラム）の実行権限が挙げられる。サーバ１０は、ユーザＡの端末２０からガチャの実行権限の購入要求情報を受信すると、当該ガチャに割り当てられている異なる複数の種類のアイテムの中から所与のアルゴリズムに基づいて一のアイテムが選択され、選択された一のアイテムをユーザＡの所持アイテム（取得アイテム）として登録する処理を行う。つまり、サーバ１０は、ユーザＡの識別情報に対応づけて、選択された一のアイテムを記憶部に登録（記憶）する処理を行う。また、本実施形態のアイテムは、仮想通貨（例えば、コイン）も含む。仮想通貨は、仮想通貨以外のアイテム（例えば、カードなどのアイテム）と交換可能な仮想的な通貨である。

４−２−４仮想通貨の説明
なお、仮想通貨とは、ゲーム処理で用いられる通貨（遊技媒体）であり、アイテムと交換可能な仮想的な通貨である。つまり、仮想通貨はサーバ１０やＳＮＳサーバ３０が提供するアイテムを利用するための通貨である。サーバ１０は、ユーザ端末２０からのアイテムの購入要求情報を受信すると、ユーザの所定額の仮想通貨と交換してアイテムを提供する。言い換えると、ユーザは一定額の仮想通貨を支払うことによって、アイテムを取得することができる。

本実施形態での仮想通貨はコインとしているが、メダル、ポイント、紙幣等でもよく、単位はゲーム或いはＳＮＳで共通の通貨単位を用いてもよい。また、本実施形態において、ユーザに付与する仮想通貨の初期値は零であるが、初期段階で予め所定額（例えば、１００コイン）をユーザに付与してもよい。また、クレジットカード会社、携帯電話会社の課金サーバ４０（料金領収システム）等を利用して、リアルマネー（円、ドル、ユーロ等）の通貨（電子マネーを含む）と引き替えに、仮想通貨をユーザの端末２０に付与してもよい。

４−３．判定処理
４−３−１．活性化の判定処理
本実施形態のサーバ１０は、ユーザ毎に、ユーザの識別情報に対応付けられた活性化情報に基づいて、当該ユーザがゲームを活性化させるか否かを判定する処理を行う。例えば、サーバ１０は、ゲーム状況やＳＮＳ情報に基づいて当該ユーザがゲームを活性化させるか否かを判定する。

（Ａ）課金情報に基づく活性化の判定処理
具体的に説明すると、サーバ１０は、図８、９、１０に示すように、ユーザ毎に、ユーザのアイテムの課金情報を参照し、課金情報に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。例えば、サーバ１０は、予め設定された期間において、ユーザのアイテムの課金額が所定額より多い場合に、ユーザがゲームを活性化させると判定する。

例えば、１週間以内（予め設定された期間の一例）に、ｕｓｅｒＡの現金での課金が１０００円以上である場合に、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。一方、１週間以内に、ｕｓｅｒＡの現金での課金が１０００円未満である場合に、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

（Ｂ）アイテムの使用状況に基づく活性化の判定処理
また、サーバ１０は、図６、７に示すように、ユーザ毎に、ユーザ又は当該ユーザが属するグループのアイテムの使用状況を参照し、ユーザ又は当該ユーザが属するグループのアイテムの使用状況に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。

例えば、１週間以内に、ｕｓｅｒＡが特定のカードアイテム（例えば、レアカード）を２回以上使用している場合に、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。一方、１週間以内に、ｕｓｅｒＡが特定のカードアイテムを２回以上使用していない場合に、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

なお、アイテムは、課金アイテム（有料のアイテム）に限定してもよい。例えば、１週間以内に、ｕｓｅｒＡが課金アイテムを２回以上使用している場合に、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。一方、１週間以内に、ｕｓｅｒＡが課金アイテムを２回以上使用していない場合は、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

また、サーバ１０は、ユーザの使用アイテム数に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。例えば、サーバ１０は、ユーザの使用アイテム数が所定数より多い場合に、当該ユーザがゲームを活性化させると判定する。

例えば、ｕｓｅｒＡの使用アイテム数が２個以上である場合に、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。一方、ｕｓｅｒＡの使用アイテム数が２未満である場合に、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

また、サーバ１０は、ユーザ毎に、ユーザの使用アイテムの種類情報に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。例えば、ｕｓｅｒＡの使用アイテムの種類に「秘宝」がある場合に、ｕｓｅｒＡはゲームを活性化させるユーザであると判定し、ｕｓｅｒＡの使用アイテムの種類に「秘宝」がない場合に、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

（Ｃ）アイテムの取得状況に基づく活性化の判定処理
また、サーバ１０は、図４、５に示すように、ユーザ毎に、ユーザ又は当該ユーザが属するグループのアイテムの取得状況を参照し、ユーザ又は当該ユーザが属するグループのアイテムの取得状況に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。

例えば、１週間以内に、ｕｓｅｒＡがアイテムを５個以上取得している場合に、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。一方、１週間以内に、ｕｓｅｒＡがアイテムを５個以上取得していない場合に、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

なお、アイテムは、課金アイテム（有料のアイテム）に限定してもよい。例えば、１週間以内に、ｕｓｅｒＡが課金アイテムを５個以上取得している場合に、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。一方、１週間以内に、ｕｓｅｒＡが課金アイテムを５個以上取得していない場合に、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

また、サーバ１０は、ユーザのアイテムの保有数に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。例えば、サーバ１０は、ユーザのアイテムの保有数が所定数より多い場合に、当該ユーザがゲームを活性化させると判定する。

例えば、ｕｓｅｒＡのアイテム保有数が１５個以上である場合に、ｕｓｅｒＡはゲームを活性化させるユーザであると判定し、ｕｓｅｒＡのアイテム保有数が１５未満である場合に、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

また、サーバ１０は、ユーザ毎に、ユーザの取得アイテムの種類情報に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。例えば、ｕｓｅｒＡの取得アイテムの種類に「秘宝」がある場合に、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。一方、ｕｓｅｒＡの取得アイテムの種類に「秘宝」がない場合に、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

（Ｄ）ゲーム利用時間に基づく活性化の判定処理
また、サーバ１０は、ユーザ毎に、ユーザのゲーム利用時間に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。例えば、サーバ１０は、予め設定された期間において、ユーザのゲーム利用時間が所定利用時間より長い場合に、当該ユーザがゲームを活性化させると判定する。

例えば、本実施形態のサーバ１０は、図１２に示すように、ユーザの識別情報に対応付けられたゲーム利用時間（ログイン日時、ログアウト日時）を参照し、当該ゲーム利用時間の長さを参照する。例えば、ユーザの１週間以内の１日の平均ゲーム利用時間を算出する。そして、ｕｓｅｒＡの当該平均ゲーム利用時間が３０分以上の場合には、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。一方、ｕｓｅｒＡが特定の当該平均ゲーム利用時間が３０分未満の場合には、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

また、例えば、本実施形態のサーバ１０は、図１２に示すように、ユーザの識別情報に対応付けられたゲーム利用時間（ログイン日時、ログアウト日時）を参照し、当該ゲーム利用の時間帯を参照する。例えば、ユーザの１週間以内の１日のゲーム利用時間を参照し、当該ユーザが午前の時間帯（０時〜１２時）にゲームを利用するのか、午後の時間帯（１２時〜２４時）にゲームを利用するのかを判定する。そして、例えば、ｕｓｅｒＡのゲーム利用時間帯が午後の場合には、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。一方、ｕｓｅｒＡのゲーム利用時間帯が午前の場合には、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

また、本実施形態のサーバ１０は、図１２に示すように、ユーザの識別情報に対応付けられたゲーム利用時間（ログイン日時、ログアウト日時）を参照し、ユーザの１日あたり（所定期間内）の利用回数（利用頻度）を求める。例えば、サーバ１０は、ｕｓｅｒＡの１日あたりの利用回数が３回以上である場合には、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。一方、ｕｓｅｒＡの１日あたりの利用回数が３回未満である場合には、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

（Ｅ）ゲーム結果に基づく活性化の判定処理
また、サーバ１０は、ユーザ毎に、ユーザ又は当該ユーザが属するグループのゲーム結果に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。例えば、サーバ１０は、ユーザ又はユーザが属するグループが、特定のゲーム結果に達するまでゲームを利用している場合に、当該ユーザがゲームを活性化させると判定する。

例えば、サーバ１０は、図１３に示すように、予め設定された期間（例えば、現在を含む２４時間以内）のユーザの識別情報に対応付けられたゲーム結果を参照する。そして、例えば、サーバ１０は、２４時間以内に、（Ａ）ｕｓｅｒＡに対応付けられたゲーム結果に「勝ち」があり、当該「勝ち」のゲーム結果に到達するまでに「負け」が１回以上続けてある場合、（Ｂ）ｕｓｅｒＡに対応付けられたゲーム結果に「負け」が連続して２回以上ある場合、の少なくとも１つに該当する場合、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。

一方、サーバ１０は、２４時間以内に、（Ａ）ｕｓｅｒＡに対応付けられたゲーム結果が存在しない場合、（Ｂ）ｕｓｅｒＡに対応付けられたゲーム結果に「勝ち」があり、当該「勝ち」のゲーム結果に到達するまでに「負け」が１回以上ない場合、（Ｃ）ｕｓｅｒＡに対応付けられたゲーム結果に「負け」が連続して２回以上ない場合、の少なくとも１つに該当する場合、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

（Ｆ）イベントの参加状況に基づく活性化の判定処理
また、サーバ１０は、ユーザ毎に、ユーザのイベントの参加状況に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。

例えば、サーバ１０は、図１４に示すように、ユーザ識別情報に対応づけられた参加イベントの数（イベントの参加回数）を参照し、参加イベントの数に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。具体的に説明すると、サーバ１０は、ｕｓｅｒＡが参加したイベントの数が１０以上である場合には、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。一方、ｕｓｅｒＡが参加したイベントの数が１０未満（１以下）である場合には、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

また、サーバ１０は、ユーザ毎に、ユーザ又は当該ユーザが属するグループが行ったイベントの参加時間に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。例えば、サーバ１０は、予め設定された期間において、ユーザ又は当該ユーザが属するグループが行ったイベントの参加時間が所定参加時間より長い場合に、ユーザがゲームを活性化させると判定する。

具体的に説明すると、サーバ１０は、図１４に示すように、１週間以内に、ユーザ識別情報に対応づけられた参加イベントの時間（イベントの参加時間）を参照し、参加イベントの時間に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。例えば、サーバ１０は、ｕｓｅｒＡが１週間以内において参加したイベントの時間（開始から終了までの時間）の合計時間が１時間以上である場合には、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。一方、ｕｓｅｒＡが過去１週間以内において参加したイベントの時間の合計時間が１時間未満である場合には、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

例えば、サーバ１０は、図１４に示すように、１週間以内に、ユーザ識別情報に対応づけられた参加頻度（所定期間におけるイベントの参加回数）を算出し、参加頻度に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。具体的に説明すると、サーバ１０は、ｕｓｅｒＡが１週間以内において参加したイベントの数が２以上である場合には、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。一方、ｕｓｅｒＡが過去１週間以内において参加したイベントの数が２未満（１以下）である場合には、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

また、サーバ１０は、ユーザ毎に、ユーザのイベントの参加状況に関するＳＮＳ情報に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。つまり、サーバ１０は、ユーザ毎に、ユーザのイベントの参加状況に関する投稿回数に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。例えば、サーバ１０は、予め設定された期間において、ユーザのイベントの参加状況に関する投稿回数が所定数より多い場合に、当該ユーザがゲームを活性化させると判定する。

本実施形態のサーバ１０は、ユーザのイベントの参加状況に関する投稿回数や、ユーザのイベントの参加状況に関する投稿メッセージに対する友人とのコミュニケーション数（肯定的評価数（「いいね」の回数）や、返信コメントの回数）に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。

例えば、サーバ１０は、１週間以内におけるｕｓｅｒＡの「イベントの参加状況に関する投稿回数」が１０回以上である場合には、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。一方、１週間以内におけるｕｓｅｒＡの「イベントの参加状況に関する投稿回数」が１０回未満である場合には、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

（Ｇ）イベントの実行状況に基づく活性化の判定処理
また、サーバ１０は、ユーザ毎に、ユーザのイベントの実行状況に関するＳＮＳ情報に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。つまり、サーバ１０は、ユーザ毎に、ユーザのイベントの実行状況に関する投稿回数に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。例えば、サーバ１０は、予め設定された期間において、ユーザのイベントの実行状況に関する投稿回数が所定数より多い場合に、当該ユーザがゲームを活性化させると判定する。

本実施形態のサーバ１０は、ユーザのイベントの実行状況に関する投稿回数や、ユーザのイベントの実行状況に関する投稿メッセージに対する友人とのコミュニケーション数（肯定的評価数（「いいね」の回数）や、返信コメントの回数）に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。

そして、例えば、サーバ１０は、１週間以内におけるｕｓｅｒＡの「イベントの実行状況に関する投稿回数」が１０回以上である場合には、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。一方、１週間以内におけるｕｓｅｒＡの「イベントの実行状況に関する投稿回数」が１０回未満である場合には、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

また、サーバ１０は、ユーザ毎に、ユーザ又は当該ユーザが属するグループが行ったイベントの成功可否に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。例えば、サーバ１０は、ユーザ又はユーザが属するグループが、イベントが成功するまでゲームを利用している場合に、当該ユーザがゲームを活性化させると判定する。

例えば、サーバ１０は、図１５に示すように、予め設定された期間（例えば、現在を含む２４時間以内）のユーザの識別情報に対応付けられた成功可否を参照する。そして、例えば、サーバ１０は、２４時間以内に、（ア）ｕｓｅｒＡに対応付けられた成功可否に「成功」があり、当該「成功」に到達するまでに「失敗」が１回以上続けてある場合、（イ）ｕｓｅｒＡに対応付けられた成功可否に「失敗」が連続して２回以上ある場合、の少なくとも１つに該当する場合、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。

一方、サーバ１０は、２４時間以内に、（ア）ｕｓｅｒＡに対応付けられた成功可否が存在しない場合、（イ）ｕｓｅｒＡに対応付けられた成功可否に「成功」があり、当該「成功」に到達するまでに「失敗」が１回以上ない場合、（ウ）ｕｓｅｒＡに対応付けられた成功可否に「失敗」が連続して２回以上ない場合、の少なくとも１つに該当する場合、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

（Ｈ）ユーザの友人数に基づく活性化の判定処理
また、サーバ１０は、ユーザ毎に、ユーザの識別情報に対応付けられた当該ユーザの友人数に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。

例えば、サーバ１０は、図１６に示すように、ユーザの識別情報に対応づけられた当該ユーザの友人数を参照し、当該友人数に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。例えば、サーバ１０は、ｕｓｅｒＡの友人数が１００以上である場合には、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。一方、ｕｓｅｒＡの友人数が１００未満である場合には、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

（Ｉ）ユーザが友人と行ったコミュニケーションの数に基づく活性化の判定処理
また、サーバ１０は、ユーザ毎に、ユーザが友人と行ったコミュニケーションの数に基づいて、当該ユーザがゲームを活性化させるか否かを判定してもよい。例えば、サーバ１０は、予め設定された期間において、ユーザが友人と行ったコミュニケーションの数が所定数より多い場合に、当該ユーザがゲームを活性化させると判定する。

例えば、サーバ１０は、図１７に示すように、ユーザの識別情報に対応づけられた１日あたりの当該ユーザが友人と行ったコミュニケーションの数を参照し、コミュニケーションの数に基づいて、当該ユーザがゲームを活性化させるか否かを判定する。

具体的には、サーバ１０は、ｕｓｅｒＡに対応付けられた１日あたりのコミュニケーションの数が２以上ある場合、ｕｓｅｒＡはゲームを活性化させるユーザであると判定する。一方、サーバ１０は、ｕｓｅｒＡに対応付けられた１日あたりのコミュニケーションの数が２未満である場合、ｕｓｅｒＡはゲームを活性化させないユーザであると判定する。

４−３−２．活性化フラグ
本実施形態では、上述したように、ユーザ毎にユーザが活性化させるか否かを判定し、図２０（Ａ）に示すように、ユーザの識別情報に対応づけて活性化フラグを設定する。例えば、サーバ１０は、ゲームを活性化させると判定されたユーザに対して活性化フラグを１に設定し、ゲームを活性化させないと判定されたユーザに対して活性化フラグを０に設定する。例えば、図２０（Ａ）の例では、ｕｓｅｒＡはゲームを活性化させるユーザであり、ｕｓｅｒＢはゲームを活性化させないユーザであることを示している。

なお、サーバ１０は、所定の周期（例えば、毎日午前０時）に、ユーザ毎に、ユーザがゲームを活性化させるか否かの判定を行ってもよいし、ユーザの端末２０からサーバ１０にアクセスがあるタイミングで、当該ユーザがゲームを活性化させるか否かの判定を行ってもよい。

また、サーバ１０は、ユーザ毎に、ゲーム状況、ＳＮＳ情報等の様々な各活性化情報を因子として、活性化の判定を行ってもよい。

具体的には、サーバ１０は、（Ａ）課金情報（例えば、設定された期間におけるユーザのアイテムの課金額）、（Ｂ）アイテムの使用状況に基づく活性化の判定処理（例えば、ユーザの使用アイテムの数）、（Ｃ）アイテムの取得状況に基づく活性化の判定処理、（Ｄ）ゲーム利用時間に基づく活性化の判定処理（例えば、設定された期間におけるユーザのゲーム利用時間）、（Ｅ）ゲーム結果に基づく活性化の判定処理、（Ｆ）イベントの参加状況に基づく活性化の判定処理（例えば、設定された期間におけるユーザのイベントの参加状況に関するＳＮＳサーバへの投稿回数、設定された期間におけるユーザ又は当該ユーザが属するグループが行ったイベントの参加時間等）、（Ｇ）イベントの実行状況に基づく活性化の判定処理（例えば、設定された期間におけるユーザのイベントの実行状況に関するＳＮＳサーバへの投稿回数、設定された期間におけるユーザ又は当該ユーザが属するグループが行ったイベントの実行時間等）、（Ｈ）ユーザの友人数に基づく活性化の判定処理（例えば、設定された期間におけるユーザの友人数）、（Ｉ）ユーザが友人と行ったコミュニケーションの数に基づく活性化の判定処理（例えば、設定された期間におけるユーザが友人と行ったコミュニケーションの数）、（Ｊ）その他の活性化情報等を活性化因子とし、（Ａ）〜（Ｊ）の少なくとも１つの因子に基づいて活性化数値を算出し、当該活性化数値が所定数値より高い場合に、当該ユーザがゲームを活性化させると判定してもよい。

例えば、サーバ１０は、課金額と友人数を乗算した値を活性化数値とし、活性化数値が１０００以上である場合に、ユーザがゲームを活性化させると判定し、活性化数値が１０００未満である場合に、ユーザがゲームを活性化させないと判定する。具体的には、図２１に示すように、１週間以内におけるｕｓｅｒＡのアイテムの課金額が５００円であり、友人数が４人である場合に、活性化数値が５００×４＝２０００となる。つまり、ｕｓｅｒＡの活性化数値は２０００であり、１０００以上であるのでゲームを活性化させるユーザであると判定する。

４−３−３．活性化レベル
また、サーバ１０は、ユーザの識別情報毎に、ユーザの活性化情報に基づいて当該ユーザを第１から第Ｎ（Ｎ≧３）のいずれかの活性化レベルに判定する処理を行うようにしてもよい。例えば、図２０（Ｂ）に示すように、本実施形態では、活性化レベルを「１」、「２」、「３」の３段階のレベルに分け、「１」はゲームを活性化させることが低いことを示し、「２」はゲームを活性化させることが中程度であることを示し、「３」はゲームを活性化させることが高いことを示している。例えば、図２０（Ｂ）の例では、ｕｓｅｒＡの活性化レベルは「３」であり高い確率でゲームを活性化させるユーザであることを示し、ｕｓｅｒＣの活性化レベルは「２」であり概ね中程度でゲームを活性化させるユーザであることを示し、ｕｓｅｒＢの活性化レベルは「１」でありゲームを活性化させる可能性が低いユーザであることを示している。

なお、サーバ１０は、所定の周期（例えば、毎日午前０時）に、ユーザ毎にユーザの活性化レベル判定を行ってもよいし、ユーザの端末２０からサーバ１０にアクセスがあるタイミングで、当該ユーザの活性化レベルを判定してもよい。

また、本実施形態では、ユーザ毎に、ゲーム状況、ＳＮＳ情報等の様々な各活性化情報を因子として、活性化レベルを判定してもよい。

具体的には、サーバ１０は、（Ａ）課金情報（例えば、設定された期間におけるユーザのアイテムの課金額）、（Ｂ）アイテムの使用状況に基づく活性化の判定処理（例えば、ユーザの使用アイテムの数）、（Ｃ）アイテムの取得状況に基づく活性化の判定処理、（Ｄ）ゲーム利用時間に基づく活性化の判定処理（例えば、設定された期間におけるユーザのゲーム利用時間）、（Ｅ）ゲーム結果に基づく活性化の判定処理、（Ｆ）イベントの参加状況に基づく活性化の判定処理（例えば、設定された期間におけるユーザのイベントの参加状況に関するＳＮＳサーバへの投稿回数、設定された期間におけるユーザ又は当該ユーザが属するグループが行ったイベントの参加時間等））、（Ｇ）イベントの実行状況に基づく活性化の判定処理（例えば、設定された期間におけるユーザのイベントの実行状況に関するＳＮＳサーバへの投稿回数、設定された期間におけるユーザ又は当該ユーザが属するグループが行ったイベントの実行時間等）、（Ｈ）ユーザの友人数に基づく活性化の判定処理（例えば、設定された期間におけるユーザの友人数）、（Ｉ）ユーザが友人と行ったコミュニケーションの数に基づく活性化の判定処理（例えば、設定された期間におけるユーザが友人と行ったコミュニケーションの数）、（Ｊ）その他の活性化情報等を活性化因子とし、（Ａ）〜（Ｊ）の少なくとも１つの因子に基づいて活性化数値を算出し、当該活性化数値に基づいて、ユーザを「１」、「２」、「３」の３段階のいずれかのレベルに判定する。

例えば、サーバ１０は、課金額と友人数を乗算した値を活性化数値とし、活性化数値が０以上〜１０００未満である場合に活性化レベル「１」と判定し、１０００以上〜２０００未満である場合に活性化レベル「２」と判定し、２０００以上である場合に活性化レベル「３」と判定する。

具体的には、図２１に示すように、１週間以内におけるｕｓｅｒＡのアイテムの課金額が５００円であり、友人数が４人である場合に、活性化数値が５００×４＝２０００となる。つまり、ｕｓｅｒＡの活性化数値は２０００であり、２０００以上であるのでゲームを活性化レベル「３」と判定される。

４−４．グループ生成処理
サーバ１０は、ユーザの端末２０からグループ生成要求を受信した場合に、当該ユーザのためのグループを生成する処理を行う。グループとは、複数のユーザで構成されるチーム、パーティである。

本実施形態では、一人のユーザが複数のグループに属していてもよい。例えば、ｕｓｅｒＡ、ｕｓｅｒＢからなる第１のグループと、ｕｓｅｒＡ、ｕｓｅｒＣからなる第２のグループと、ｕｓｅｒＤ、ｕｓｅｒＥ、ｕｓｅｒＦからなる第３のグループ、のように、グループは人数とメンバー構成の少なくとも一方が異なるようにグループを生成してもよい。

また、本実施形態では、グループの人数を制限（例えば、２名に制限）してもよいし、一人のユーザが属するグループを１つに制限してもよい（つまり、一人のユーザが複数のグループに属することを禁止してもよい）。

サーバ１０は、予め決められた期間にゲームを行うグループを生成してもよいし、ユーザの端末からのグループ解除要求を受信するまでのグループを生成してもよい。また、サーバ１０は、ユーザの端末からのグループのメンバー追加要求を受信した場合には、既にあるグループにメンバーを追加するようにしてもよい。例えば、サーバ１０は、既にｕｓｅｒＡ、ｕｓｅｒＢからなる第１のグループが存在し、ｕｓｅｒＡの端末２０から、第１のグループにｕｓｅｒＣを追加する要求を受信した場合には、第１のグループに、ｕｓｅｒＣを加えるようにしてもよい（つまり、ｕｓｅｒＡ、ｕｓｅｒＢ、ｕｓｅｒＣからなる第１のグループに編成してもよい）。

４−４−１．活性化フラグに基づくグループ生成処理
特に、本実施形態のサーバ１０は、グループを生成する際に、ゲームを活性化させると判定された少なくとも一人のユーザを含むグループを生成する処理を行う。

例えば、図２０（Ａ）に示すように、ｕｓｅｒＢの端末２０からグループ生成要求を受信すると、ｕｓｅｒＢの活性化フラグが０であるので、グループ内に活性化フラグが１であるユーザ（例えば、ｕｓｅｒＡ）を含むグループを生成する。このようにすれば、ｕｓｅｒＢは、活性化させるユーザ（例えば、ｕｓｅｒＡ）と共にゲームプレイを行うことができるので、ゲーム全体を活性化させることができる。

また、ｕｓｅｒＡの端末２０からグループ生成要求を受信すると、ｕｓｅｒＡの活性化フラグが１であるので、任意のユーザ（活性化フラグが０又は１のユーザ）を含むグループを生成する。例えば、活性化フラグが１であるユーザで構成されるグループ（ｕｓｅｒＡ、ｕｓｅｒＣ、ｕｓｅｒＥ）を生成すれば、各ユーザ同士が刺激し合うような活性化させるゲーム環境を提供できる。

４−４−２．活性化レベルに基づくグループ生成処理
また、サーバ１０は、第Ｍ（Ｎ＞Ｍ≧１）の活性化レベルのユーザと、第Ｍ＋１の活性化レベルのユーザで構成されるグループを生成してもよい。

例えば、図２０（Ｂ）に示すように、ｕｓｅｒＢの端末２０からグループ生成要求を受信すると、ｕｓｅｒＢの活性化レベルが「１」であるので、活性化レベルが「３」であるユーザ（例えば、ｕｓｅｒＡ）ではなく、活性化レベルが「２」であるユーザ（例えば、ｕｓｅｒＣ）を含むグループを生成する。

つまり、例えば、ｕｓｅｒＡがゲームに熱心なユーザである場合に、ｕｓｅｒＢとｕｓｅｒＡとをマッチングして同一グループにしてしまうと、ｕｓｅｒＢはｕｓｅｒＡの熱心さについていけずゲームを離脱する可能性がある。しかし、ｕｓｅｒＢとｕｓｅｒＣとをマッチングして同一グループにすれば、ｕｓｅｒＢはｕｓｅｒＣから適度な活性化の影響を受けることができ、ゲームを離脱することなく、ゲームプレイを継続して行うことができる。

例えば、図２０（Ｂ）に示すように、ｕｓｅｒＡの端末２０からグループ生成要求を受信すると、ｕｓｅｒＡの活性化レベルが「３」であるので、活性化レベルが「１」であるユーザ（例えば、ｕｓｅｒＢ）ではなく、活性化レベルが「２」であるユーザ（例えば、ｕｓｅｒＣ）を含むグループを生成する。

例えば、ｕｓｅｒＡがゲームに熱心なユーザである場合に、ｕｓｅｒＢとｕｓｅｒＡとをマッチングして同一グループにしてしまうと、ｕｓｅｒＡはゲームに飽きて離脱する可能性がある。しかし、ｕｓｅｒＡとｕｓｅｒＣとをマッチングして同一グループにすれば、ｕｓｅｒＡはｕｓｅｒＣに影響を与え、全体として活性化のあるゲームを提供でき、ｕｓｅｒＡはゲームに飽きることなくゲームを行わせることができる。

４−５．表示情報の生成
本実施形態のサーバ１０は、端末２０に表示させる表示情報を生成し、端末２０に送信してもよい。例えば、サーバ１０は、端末２０からのアクセス要求を受信すると、表示内容（ゲーム画面の内容、例えば、メッセージ、画像、リンクなど）の配置（構成）を決定して表示情報（ゲーム画面の情報、ページ情報）を生成し、当該表示情報を端末２０に送信する。例えば、サーバ１０が、Ｗｅｂサーバとして機能を有する場合には、ＨＴＭＬ、ＦＬＡＳＨ、ＣＧＩ、ＰＨＰ、ｓｈｏｃｋｗａｖｅ、Ｊａｖａ（登録商標）アプレット、ＪａｖａＳｃｒｉｐｔ（登録商標）など様々な言語で作られた表示情報を生成し、端末２０に当該表示情報を送信する。一方、端末２０は、サーバ１０から表示情報を受信し、Ｗｅｂブラウザ等によって当該表示情報を表示部２９０に表示する。なお、サーバ１０は、画像生成プログラムに基づき表示情報を生成してもよい。

特に、本実施形態のサーバ１０は、ｕｓｅｒＢの端末２０からグループの生成要求を受信すると、図２２に示すように、画面６０にグループのメンバー候補である他のユーザを配置した表示情報を生成する処理を行う。例えば、サーバ１０は、画面６０に配置する他のユーザ（グループのメンバー候補）は、少なくともゲームを活性化させると判定されたユーザ（或いは、活性化レベルが２以上のユーザ）としてもよい。また、サーバ１０は、画面６０のファーストビュー（画面６０の上部）に配置する他のユーザ（グループのメンバー候補）を、活性化フラグが１であるユーザや活性化レベルが２以上のユーザにしてもよい。なお、ファーストビューとは、例えば、表示情報を端末で表示する際に、スクロールをしなくても端末の表示部に表示される範囲である。

例えば、サーバ１０は、ｕｓｅｒＢの端末２０からグループの生成要求を受信すると、ｕｓｅｒＢの活性化フラグが０であるので、画面６０にグループのメンバー候補を、活性化フラグが１であるユーザ（例えば、活性化フラグが１であるｕｓｅｒＡ、ｕｓｅｒＣ、ｕｓｅｒＥ、ｕｓｅｒＦ、ｕｓｅｒＱ）にしてもよい。

そして、サーバ１０は、ｕｓｅｒＢの端末２０に生成した表示情報を送信する処理を行う。そして、ｕｓｅｒＢの端末２０において、ｕｓｅｒＡ、ｕｓｅｒＣ、ｕｓｅｒＥ、ｕｓｅｒＦ、ｕｓｅｒＱのメンバー候補うち、ｕｓｅｒＢからの入力情報に基づいてｕｓｅｒＡ、ｕｓｅｒＣ、ｕｓｅｒＥ、ｕｓｅｒＦをグループのメンバーとしてチェックボックス６４、６８、７２、７６にチェックがされた（選択された）とする。そして、ｕｓｅｒＢの端末２０は、仲間に誘うリンク６１或いは８２の入力を受け付けると、サーバ１０に対して、選択されたユーザの識別情報、つまり、ｕｓｅｒＡ、ｕｓｅｒＣ、ｕｓｅｒＥ、ｕｓｅｒＦを送信する。サーバ１０は、ｕｓｅｒＢの端末２０から選択されたユーザの識別情報、つまり、ｕｓｅｒＡ、ｕｓｅｒＣ、ｕｓｅｒＥ、ｕｓｅｒＦを受信する処理を行う。そして、サーバ１０は、ｕｓｅｒＢのグループに、ｕｓｅｒＡ、ｕｓｅｒＣ、ｕｓｅｒＥ、ｕｓｅｒＦを含むように（追加するように）、ｕｓｅｒＢのグループを生成する処理を行う。

４−６．グループ生成後の処理
本実施形態は、グループを生成後、グループで実現可能なゲームを提供する。例えば、ゲームは、グループを構成する各ユーザが協力して敵と対戦する対戦ゲームでもよいし、同一グループ内の第１のユーザと第２のユーザとが対戦するゲームでもよい。また、本実施形態のゲームは、グループ単位で行うゲームに適用してもよい。例えば、第１のグループと第２のグループとが対戦するゲームでもよい。また、本実施形態では、グループ生成後に、ユーザの端末２０からの解除要求に基づいて、ユーザのグループを解除、グループの脱退をできるように制御してもよい。

４−７．フローチャート
本実施形態のサーバ１０の処理の流れについて、図２３を用いて説明する。まず、ユーザの端末から、グループの生成要求を受信する処理を行う（ステップＳ１）。そして、ユーザの活性化フラグ＝１か否かを判定する（ステップＳ２）。活性化フラグ＝１でない場合（ステップＳ２のＮ、つまり、活性化フラグ＝０の場合）は、サーバが管理するユーザ群の中から活性化フラグ＝１の他のユーザを抽出する処理を行う（ステップＳ３）。一方、活性化フラグ＝１である場合（ステップＳ２のＹ）は、サーバが管理するユーザ群の中から任意の他のユーザを抽出する処理を行う（ステップＳ４）。

そして、抽出された他のユーザを、グループのメンバー候補として、表示情報を生成する処理を行う（ステップＳ５）。そして、表示情報をユーザの端末に送信する処理を行う（ステップＳ６）。そして、ユーザの端末から、グループのメンバー選択情報（選択されたメンバーのユーザ識別情報）を受信する処理を行い（ステップＳ７）、ユーザと選択された他のユーザとを含むグループを生成する処理を行う（ステップＳ８）。以上で処理が終了する。

５．その他
本実施形態では、対戦ゲーム、育成シミュレーションゲーム、レースゲーム、音楽ゲーム、格闘ゲーム、など種々のゲームに応用することができる。また、本実施形態では、複数のユーザによる対戦が可能な他のゲームに応用してもよい。

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

本発明は、実施形態で説明した構成と実質的に同一の構成（例えば、機能、方法及び結果が同一の構成、あるいは目的及び効果が同一の構成）を含む。また、本発明は、実施形態で説明した構成の本質的でない部分を置き換えた構成を含む。また、本発明は、実施形態で説明した構成と同一の作用効果を奏する構成又は同一の目的を達成することができる構成を含む。また、本発明は、実施形態で説明した構成に公知技術を付加した構成を含む。

上記のように、本発明の実施形態について詳細に説明したが、本発明の新規事項および効果から実体的に逸脱しない多くの変形が可能であることは当業者には容易に理解できるであろう。したがって、このような変形例はすべて本発明の範囲に含まれるものとする。

１０サーバ、２０、２０Ａ、２０Ｂ、２０Ｃ端末、３０ＳＮＳサーバ、
４０課金サーバ、１００処理部、１１０通信制御部、１１１Ｗｅｂ処理部、
１１２活性化情報制御部、１１３判定部、１１４表示情報生成部、
１１５ゲーム処理部、１１６アイテム取得制御部、１１７アイテム使用制御部、
１１８イベント参加制御部、１１９イベント実行部、１２０グループ生成部、
１７０記憶部、１７１主記憶部、１７２アイテム、１７３活性化情報、
１７５ユーザ情報、１７６友人情報、１８０情報記憶媒体、１９６通信部、
２００処理部、２１０通信制御部、２１１Ｗｅｂブラウザ、
２１２ゲーム処理部、２１３表示制御部、２２０描画部、２３０音生成部、
２６０入力部、２７０記憶部、２８０情報記憶媒体、２９０表示部、
２９２音出力部、２９６通信部

Claims

複数のユーザの端末とネットワークを介してデータを送受信し、複数のユーザで構成されるグループを生成してゲームを行わせるサーバのプログラムであって、
ユーザの識別情報毎に、各ユーザのゲーム状況を示す情報及び当該ゲームにおけるＳＮＳの利用状況を示す情報の少なくともいずれか一方を、活性化情報として、記憶部に記憶する処理を行う活性化情報制御部と、
ユーザ毎に、ユーザの識別情報に対応付けられた活性化情報が所与の条件を具備するか否かを判定し、当該所与の条件を具備するユーザを、前記ゲームを活性化させるユーザとして判定するとともに、前記活性化情報について所定の演算を実行してユーザの活性化レベルを判定する処理を行う判定部と、
前記活性化レベルに基づいて複数のユーザで構成されるグループを生成する処理を行うグループ生成部として、コンピュータを機能させ、
前記グループ生成部が、
所与の活性化レベルを有する第１のユーザと、当該第１のユーザより高い活性化レベルを有するユーザであって当該第１のユーザに影響を与え、かつ、全体として活性化のあるゲームを提供することが可能な条件を具備する活性化レベルを有する第２のユーザと、によって構成される前記グループを生成することを特徴とするプログラム。
請求項１において
前記活性化情報制御部が、前記各ユーザのゲーム状況を示す情報であって数値化されている情報及び当該ゲームにおけるＳＮＳの利用状況を示す情報であって数値化されている情報の中から少なくとも２以上の情報を、前記活性化情報として、記憶部に記憶し、
前記判定部が、前記２以上の活性化情報について所定の演算を実行してユーザの活性化レベルを判定することを特徴とするプログラム。
請求項２において
前記活性化情報が、前記ゲームの状況に基づく数値を因子として前記数値化されている情報、及び、前記ＳＮＳの利用状況に基づく数値を因子として前記数値化されている情報の少なくともいずれか一方である、プログラム。
請求項１〜３のいずれかにおいて、
前記各ユーザのゲーム状況を示す情報としては、前記ゲームで使用するアイテムの取得状況、当該アイテムの使用状況、当該アイテムを取得する際に徴収された課金情報、当該アイテムの保有数、当該アイテムの種類、当該ゲームに用いるパラメータ、当該ゲームの利用時間、当該ゲームのゲーム結果、当該ゲームのイベントへの参加状況、当該イベントへの実行状況の少なくともいずれか一の情報が含まれることを特徴とするプログラム。
請求項１〜３のいずれかにおいて、
前記ゲームにおけるＳＮＳの利用状況を示す情報としては、前記ＳＮＳ上で登録されている友人数、及び、当該ＳＮＳ上での友人とのコミュニケーション回数の少なくともいずれか一の情報が含まれることを特徴とするプログラム。
複数のユーザの端末とネットワークを介してデータを送受信し、複数のユーザで構成されるグループを生成してゲームを行わせるサーバのプログラムであって、
ユーザの識別情報毎に、前記ユーザ課金した課金情報を、ユーザが前記ゲームを活性化させるか否かを判定するための活性化情報として、前記記憶部に記憶する処理を行う活性化情報制御部と、
ユーザ毎に、ユーザの識別情報に対応付けられた課金情報に基づいて予め定められた期間に所定額より多い額の課金をしているか否かを判定し、当該所定額より多い額の課金をしているユーザを、前記ゲームを活性化させるユーザとして判定する処理を行う判定部と、
複数のユーザで構成されるグループを生成する処理を行うグループ生成部として、コンピュータを機能させ、
前記グループ生成部が、
前記ゲームを活性化させると判定された少なくとも一人のユーザを含む前記グループを生成する処理を行うことを特徴とするプログラム。
請求項１〜６のいずれかにおいて、
前記グループ生成部が、
前記ゲームを活性化させると判定された複数のユーザで構成される前記グループを生成する処理を行うことを特徴とするプログラム。
複数のユーザの端末とネットワークを介してデータを送受信し、複数のユーザで構成されるグループを生成してゲームを行わせるサーバであって、
ユーザの識別情報毎に、各ユーザのゲーム状況を示す情報及び当該ゲームにおけるＳＮＳの利用状況を示す情報の少なくともいずれか一方を、活性化情報として、記憶部に記憶する処理を行う活性化情報制御部と、
ユーザ毎に、ユーザの識別情報に対応付けられた活性化情報が所与の条件を具備するか否かを判定し、当該所与の条件を具備するユーザを、前記ゲームを活性化させるユーザとして判定するとともに、前記活性化情報について所定の演算を実行してユーザの活性化レベルを判定する処理を行う判定部と、
前記活性化レベルに基づいて複数のユーザで構成されるグループを生成する処理を行うグループ生成部と、を含み、
前記グループ生成部が、
所与の活性化レベルを有する第１のユーザと、当該第１のユーザより高い活性化レベルを有するユーザであって当該第１のユーザに影響を与え、かつ、全体として活性化のあるゲームを提供することが可能な条件を具備する活性化レベルを有する第２のユーザと、によって構成される前記グループを生成することを特徴とするサーバ。
複数のユーザの端末とネットワークを介してデータを送受信し、複数のユーザで構成されるグループを生成してゲームを行わせるサーバであって、
ユーザの識別情報毎に、前記ユーザ課金した課金情報を、ユーザが前記ゲームを活性化させるか否かを判定するための活性化情報として、前記記憶部に記憶する処理を行う活性化情報制御部と、
ユーザ毎に、ユーザの識別情報に対応付けられた課金情報に基づいて予め定められた期間に所定額より多い額の課金をしているか否かを判定し、当該所定額より多い額の課金をしているユーザを、前記ゲームを活性化させるユーザとして判定する処理を行う判定部と、
複数のユーザで構成されるグループを生成する処理を行うグループ生成部、を含み、
前記グループ生成部が、
前記ゲームを活性化させると判定された少なくとも一人のユーザを含む前記グループを生成する処理を行うことを特徴とするサーバ。
複数のユーザの端末と、複数のユーザで構成されるグループを生成してゲームを行わせるサーバとが、ネットワークを介してデータを送受信するネットワークシステムであって、
前記サーバが、
ユーザの識別情報毎に、各ユーザのゲーム状況を示す情報及び当該ゲームにおけるＳＮＳの利用状況を示す情報の少なくともいずれか一方を、活性化情報として、記憶部に記憶する処理を行う活性化情報制御部と、
ユーザ毎に、ユーザの識別情報に対応付けられた活性化情報が所与の条件を具備するか否かを判定し、当該所与の条件を具備するユーザを、前記ゲームを活性化させるユーザとして判定するとともに、前記活性化情報について所定の演算を実行してユーザの活性化レベルを判定する処理を行う判定部と、
前記活性化レベルに基づいて複数のユーザで構成されるグループを生成する処理を行うグループ生成部と、を含み、
前記グループ生成部が、
所与の活性化レベルを有する第１のユーザと、当該第１のユーザより高い活性化レベルを有するユーザであって当該第１のユーザに影響を与え、かつ、全体として活性化のあるゲームを提供することが可能な条件を具備する活性化レベルを有する第２のユーザと、によって構成される前記グループを生成することを特徴とするネットワークシステム。
複数のユーザの端末と、複数のユーザで構成されるグループを生成してゲームを行わせるサーバとが、ネットワークを介してデータを送受信するネットワークシステムであって、
前記サーバが、
複数のユーザの端末とネットワークを介してデータを送受信し、複数のユーザで構成されるグループを生成してゲームを行わせるサーバのプログラムであって、
ユーザの識別情報毎に、前記ユーザ課金した課金情報を、ユーザが前記ゲームを活性化させるか否かを判定するための活性化情報として、前記記憶部に記憶する処理を行う活性化情報制御部と、
ユーザ毎に、ユーザの識別情報に対応付けられた課金情報に基づいて予め定められた期間に所定額より多い額の課金をしているか否かを判定し、当該所定額より多い額の課金をしているユーザを、前記ゲームを活性化させるユーザとして判定する処理を行う判定部と、
複数のユーザで構成されるグループを生成する処理を行うグループ生成部と、を含み、
前記グループ生成部が、
前記ゲームを活性化させると判定された少なくとも一人のユーザを含む前記グループを生成する処理を行うことを特徴とするネットワークシステム。