説明

通信システム、通信プログラム、情報処理装置、サーバ、および通信方法

【課題】新規な通信システム、通信プログラム、情報処理装置、サーバ、および通信方法を提供する。
【解決手段】マッチメイキング手段は、複数の情報処理装置の間で所定のアプリケーションを実行する際の、当該情報処理装置の組み合わせを設定する。ログ取得判定手段は、マッチメイキング手段がアプリケーションを実行する情報処理装置の組み合わせを設定する際、所定の条件に基づいて当該アプリケーションが実行されたログを取得するか否かを判定する。処理実行手段は、マッチメイキング手段によって組み合わせられた他の情報処理装置との間でアプリケーションを実行する。ログ送出手段は、ログ取得判定手段がログを取得する判定をした場合、当該判定の対象となったアプリケーションが実行されたログを所定の装置へ送出する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信システム、通信プログラム、情報処理装置、サーバ、および通信方法に関し、特に例えば、通信相手を組み合わせる処理を制御する通信システム、通信プログラム、情報処理装置、サーバ、および通信方法に関する。
【背景技術】
【0002】
従来、ネットワークを介して、他のユーザと対戦等の通信ゲームを行うゲームシステムが知られている。このようなゲームシステムでは、見ず知らずのユーザと通信ゲームを行うことも可能であるため、不正を行う一部のユーザによって、善良なユーザが通信ゲームで不快な思いをしないような対策が考えられている(例えば、特許文献1参照)。例えば、上記特許文献1で開示されたゲームシステムは、通信ゲームにおいて各ユーザが所有するアイテムの情報に基づいて、当該通信ゲームで不正が行われたか否かを判定する。そして、不正を行ったユーザ同士を当該通信ゲームで組み合わせてプレイするようにして、不正の可能性のあるユーザが他の善良なユーザと上記通信ゲームで組み合わせられることがないようにしている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2006−296769号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、上記特許文献1で開示されたゲームシステムは、通信ゲームに参加する全てのユーザのアイテム情報を検証して不正が行われた否かを判定する必要があるため、サーバの処理負荷およびサーバ運用者の作業負荷が大きくなってしまうという問題がある。
【0005】
それ故に、本発明の主たる目的は、新規な通信システム、通信プログラム、情報処理装置、サーバ、および通信方法を提供することである。また、本発明の他の目的は、サーバの処理負荷およびサーバ運用者の作業負荷を低減しつつ、ユーザの監視が可能な通信システム、通信プログラム、情報処理装置、サーバ、および通信方法を提供することである。
【課題を解決するための手段】
【0006】
上記目的を達成するために、本発明は例えば以下のような構成を採用し得る。なお、特許請求の範囲の記載を解釈する際に、特許請求の範囲の記載によってのみその範囲が解釈されるべきであることが理解され、特許請求の範囲の記載と本欄の記載とが矛盾する場合には、特許請求の範囲の記載が優先する。
【0007】
本発明の通信システムの一構成例は、サーバと当該サーバと通信可能な複数の情報処理装置とを少なくとも含む。サーバは、マッチメイキング手段およびログ取得判定手段を備える。マッチメイキング手段は、複数の情報処理装置の間で所定のアプリケーションを実行する際の、当該情報処理装置の組み合わせを設定する。ログ取得判定手段は、マッチメイキング手段がアプリケーションを実行する情報処理装置の組み合わせを設定する際、所定の条件に基づいて当該アプリケーションが実行されたログを取得するか否かを判定する。情報処理装置は、処理実行手段およびログ送出手段をそれぞれ備える。処理実行手段は、マッチメイキング手段によって組み合わせられた他の情報処理装置との間でアプリケーションを実行する。ログ送出手段は、ログ取得判定手段がログを取得する判定をした場合、当該判定の対象となったアプリケーションが実行されたログを所定の装置へ送出する。
【0008】
上記によれば、情報処理装置の組み合わせ(ユーザの組み合わせ)を設定する際に、所定の条件に基づいてアプリケーションが実行されたログを取得するか否かが判定されるため、適切なログの取得が可能となり、サーバの処理負荷およびサーバ運用者の作業負荷を低減しつつ、取得したログを用いてユーザの監視が可能となる。
【0009】
また、上記ログ送出手段は、アプリケーションを実行した自機のログとともに、当該自機との間で当該アプリケーションを実行した他の情報処理装置のログを送出してもよい。
【0010】
上記によれば、自機のログだけでなく自機とともにアプリケーションを実行した他の情報処理装置のログも送出されるため、ある装置のログを複数取得することが可能となる。
【0011】
また、上記通信システムは、ログ取得手段およびログ解析手段を備えてもよい。ログ取得手段は、ログ送出手段がそれぞれ送出したログを取得する。ログ解析手段は、ログ取得手段が取得したログを解析する。第1の情報処理装置と第2の情報処理装置との間で実行するアプリケーションがログを取得する対象となった場合、第1の情報処理装置のログ送出手段は、アプリケーションを実行した当該第1の情報処理装置のログおよび当該アプリケーションを実行した第2の情報処理装置のログをログ取得手段へ送出してもよい。第2の情報処理装置のログ送出手段は、アプリケーションを実行した当該第2の情報処理装置のログおよび当該アプリケーションを実行した第1の情報処理装置のログをログ取得手段へ送出してもよい。この場合、上記ログ解析手段は、少なくとも、第1の情報処理装置のログ送出手段から取得した第1の情報処理装置のログと第2の情報処理装置のログ送出手段から取得した第1の情報処理装置のログとの間の整合性を確認してもよい。
【0012】
上記によれば、第1の情報処理装置が自機のログを改ざんして送出したとしても、第2の情報処理装置から送出される第1の情報処理装置のログとの整合性を確認することができるため、改ざんして送出されたログを抽出することができる。
【0013】
また、上記ログ送出手段は、判定の対象となったアプリケーションの実行が開始される際に当該アプリケーションの実行の開始を示す情報をさらに送出してもよい。
【0014】
上記によれば、アプリケーションの実行を途中で止めた情報処理装置を検出することができる。
【0015】
また、上記サーバは、評価管理手段を、さらに備えてもよい。評価管理手段は、アプリケーションを実行した情報処理装置毎に当該アプリケーションの実行に関する評価を管理する。この場合、上記ログ取得判定手段は、アプリケーションを実行するために組み合わせられた情報処理装置毎の評価に基づいて、当該アプリケーションを実行したログを取得するか否かを判定してもよい。
【0016】
上記によれば、アプリケーションの実行に関する評価に基づいてログの取得要否が判断されるため、情報処理装置の評価に応じた適切なログを取得することができる。
【0017】
また、上記情報処理装置は、通知手段をそれぞれ備えてもよい。通知手段は、他の情報処理装置におけるアプリケーションの実行に関する評価をサーバへ通知する。この場合、上記評価管理手段は、通知手段からの通知された評価に基づいて、当該通知された他の情報処理装置に関する評価を更新してもよい。
【0018】
上記によれば、情報処理装置からの通知に基づいて、他の情報処理装置の評価が設定されるため、当該評価を行うためのサーバの処理負荷およびサーバ運用者の作業負荷を低減することができる。
【0019】
また、上記通知手段は、マッチメイキング手段によって組み合わせられた他の情報処理装置を対象として、評価を通知してもよい。
【0020】
上記によれば、実際に組み合わせられてアプリケーションを実行した相手の情報処理装置が評価の対象となるため、通知元の情報処理装置から適切な評価を得ることができる。
【0021】
また、上記通知手段は、マッチメイキング手段によって組み合わせられた他の情報処理装置を対象として、アプリケーションが実行された後に当該アプリケーションの実行に関する評価を通知してもよい。
【0022】
上記によれば、実際にアプリケーションが実行された後に当該アプリケーションの実行に関する評価が通知されるため、通知元の情報処理装置から適切な評価を得ることができる。
【0023】
また、上記マッチメイキング手段は、評価に対して所定の条件を満たしている情報処理装置同士を組み合わせてもよい。
【0024】
上記によれば、情報処理装置からの評価が所定の条件を満たしているもの同士がマッチメイキングされるため、情報処理装置の組み合わせを適切に設定することができる。
【0025】
また、上記評価管理手段は、通知スコア算出手段を、さらに備えてもよい。通知スコア算出手段は、通知された評価毎に、当該評価の対象となっている情報処理装置の通知スコアを累積する。この場合、上記マッチメイキング手段は、累積された通知スコアが第1の所定値以上の情報処理装置同士を組み合わせる、または累積された通知スコアが第1の所定値未満の情報処理装置同士を組み合わせてもよい。上記ログ取得判定手段は、アプリケーションを実行するために組み合わせられた少なくとも1つの情報処理装置の通知スコアが第2の所定値以上の場合、当該アプリケーションの実行を対象として所定の条件に基づいて当該アプリケーションが実行されたログを取得するか否かを判定してもよい。
【0026】
上記によれば、より多くのユーザからの評価を累積することによって、評価の信頼度を上げることができ、より適切なログ取得要否の判断が可能となる。また、評価に基づいて通報スコアが算出されるため、情報処理装置の評価を適切に管理することができる。
【0027】
また、本発明は、上記各手段としてコンピュータを機能させる通信プログラム、上記各手段の一部を備える情報処理装置、上記各手段の一部を備えるサーバ、上記各手段で行われる動作を含む通信方法の形態で実施されてもよい。上記各手段を備える情報処理装置および情報処理システムや上記各手段で行われる動作を含む情報処理方法の形態で実施されてもよい。
【発明の効果】
【0028】
本発明によれば、情報処理装置の組み合わせを設定する際に、所定の条件に基づいてアプリケーションが実行されたログを取得するか否かが判定されるため、適切なログの取得が可能となり、サーバの処理負荷およびサーバ運用者の作業負荷を低減しつつ、取得したログを用いてユーザの監視が可能となる。
【図面の簡単な説明】
【0029】
【図1】本発明の一実施形態に係る通信システム1を説明するための外観図
【図2】図1のゲーム装置3の構成の一例を示すブロック図
【図3】図1のマッチメイキングサーバ200の構成の一例を示すブロック図
【図4】通信システム1において、ユーザが通信ゲームに関する通報情報を通報する際の装置間のやりとりの一例を時間軸に沿って表現した図
【図5】通信システム1において、通信ゲームのログを送信する際の装置間のやりとりの一例を時間軸に沿って表現した図
【図6】ゲーム装置3のメインメモリ32に記憶される主なデータおよびプログラムの一例を示す図
【図7】マッチメイキングサーバ200の記憶部203に記憶される主なデータおよびプログラムの一例を示す図
【図8】記憶部203に記憶される通報スコアテーブルデータDmの一例を示す図
【図9】記憶部203に記憶される通報ログ情報データDnの一例を示す図
【図10】記憶部203に記憶される通報スコア情報データDoの一例を示す図
【図11】ゲーム装置3において実行される処理の一例を示すフローチャート
【図12】図11におけるステップ44のゲーム参加処理の一例を示すサブルーチン
【図13】図11におけるステップ52の通報処理の一例を示すサブルーチン
【図14】マッチメイキングサーバ200において実行される処理の一例を示すフローチャート
【図15】図14におけるステップ92の待機リスト送信処理の一例を示すサブルーチン
【図16】図14におけるステップ94の待機部屋作成処理の一例を示すサブルーチン
【図17】図14におけるステップ96の待機部屋参加処理の一例を示すサブルーチン
【図18】図14におけるステップ98の通報スコア算出処理の一例を示すサブルーチン
【発明を実施するための形態】
【0030】
図1を参照して、本発明の一実施形態に係る通信システムについて説明する。図1に示すように、当該通信システムの一例である通信システム1は、複数のゲーム装置3、マッチメイキングサーバ200、ログ保管サーバ300、ログ処理サーバ400、ログ処理装置500、および認証サーバ600が、ネットワーク100を介して接続されて構築される。
【0031】
ゲーム装置3は、無線または有線通信を用いて、ネットワーク100に接続可能に構成されている。例えば、ゲーム装置3は、ピアツーピア(Peer to Peer)通信方式やクライアント−サーバ方式等を用いて、他のゲーム装置3と組み合わせられて所定のアプリケーション(例えば、通信ゲーム)の実行が可能である。また、ゲーム装置3は、ネットワーク100を介して、マッチメイキングサーバ200およびログ保管サーバ300と接続を確立することによって、マッチメイキングサーバ200およびログ保管サーバ300との通信がそれぞれ可能となる。例えば、ゲーム装置3は、交換可能なメモリカードや光ディスク等の記録媒体内に記憶され、または、サーバや他のゲーム装置から受信した通信プログラムの一例となるプログラム(例えば、ゲームプログラム)を実行可能である。ゲーム装置3は、携帯ゲーム装置であってもよく、一般的なパーソナルコンピュータ、携帯電話機、PDA(Personal Digital Assistant)等のデバイスであってもかまわない。また、ゲーム装置3は、上記プログラムを記録した光ディスクと、光ディスクのプログラムを実行してゲーム画面をモニタに表示出力させるためのコンピュータを搭載したゲーム装置本体と、表示画面に表示されたオブジェクト等を操作するために必要な操作情報をゲーム装置本体に与えるためのコントローラとを備えた、据置型のゲームシステムであってもよい。
【0032】
ログ保管サーバ300は、複数のゲーム装置3が通信して所定の処理(例えば、通信ゲーム)を行った後に当該ゲーム装置3からそれぞれ送信される当該処理のログを受信して格納する。なお、上記ログを取得する対象であるか否かはマッチメイキングサーバ200によって決定され、当該対象となったゲーム装置3へ通知される。そして、ログ取得対象である場合、複数のゲーム装置3が通信して上記所定の処理を行った後に当該ゲーム装置3からそれぞれログ保管サーバ300に当該処理のログが送信される。
【0033】
ログ処理サーバ400は、ログ保管サーバ300に格納されたログを自動的に解析して、当該ログによって示されている処理において、ユーザが不正な行為を行っているか否かを判断する。そして、ログ処理サーバ400は、上記処理において不正な行為が行われている場合、当該行為を行ったユーザに対する通報理由を選出し、当該ユーザのユーザIDおよび当該通報理由をマッチメイキングサーバ200へ送信する。
【0034】
ログ処理装置500は、ログ保管サーバ300に格納されたログを実機(例えば、ゲーム装置3と同様の能力を有する装置)を用いて解析(例えば、エミュレーション)して、当該ログによって示されている処理において、ユーザが不正な行為を行っているか否かを判断する。そして、ログ処理サーバ400は、上記処理において不正な行為が行われている場合、当該行為を行ったユーザに対する通報理由を選出し、当該ユーザのユーザIDおよび当該通報理由をマッチメイキングサーバ200へ送信する。
【0035】
認証サーバ600は、ゲーム装置3を用いてネットワーク100にログインされた場合、当該ログインしようとしているユーザが正規のユーザか否かを判別するために利用される。例えば、認証サーバ600は、ネットワーク100の利用者のユーザIDおよびパスワードとともに、ログインに用いられたゲーム装置3のデバイスIDを管理しており、当該データを用いてログインしたユーザに対して認証を行う。また、認証サーバ600は、マッチメイキングサーバ200との間で所定のプロトコルを用いて通信を行い、マッチメイキングサーバ200からユーザ認証やデバイスIDの確認が要求された場合、当該要求に対する回答を行う。
【0036】
次に、図2を参照して、ゲーム装置3について説明する。なお、図2は、ゲーム装置3の構成の一例を示すブロック図である。
【0037】
図2において、ゲーム装置3には、情報処理部31、メインメモリ32、外部メモリインターフェイス(外部メモリI/F)33、データ保存用内部メモリ35、無線通信モジュール36、ローカル通信モジュール37、入力部38、および表示部39等を備えている。
【0038】
情報処理部31は、所定のプログラムを実行するためのCPU(Central Processing Unit)311、画像処理を行うGPU(Graphics Processing Unit)312等を含む情報処理手段である。本実施形態では、所定のプログラムがゲーム装置3内のメモリ(例えば外部メモリI/F33に接続された外部メモリ45やデータ保存用内部メモリ35)に記憶されている。情報処理部31のCPU311は、当該所定のプログラムを実行することによって、後述する通信処理やゲーム処理を実行する。なお、情報処理部31のCPU311によって実行されるプログラムは、他の機器との通信によって他の機器から取得されてもよい。また、情報処理部31は、VRAM(Video RAM)313を含む。情報処理部31のGPU312は、情報処理部31のCPU311からの命令に応じて画像を生成し、VRAM313に描画する。そして、情報処理部31のGPU312は、VRAM313に描画された画像を表示部39に出力し、表示部39に当該画像が表示される。
【0039】
情報処理部31には、メインメモリ32、外部メモリI/F33、およびデータ保存用内部メモリ35が接続される。外部メモリI/F33は、外部メモリ45を着脱自在に接続するためのインターフェイスである。
【0040】
メインメモリ32は、情報処理部31(CPU311)のワーク領域やバッファ領域として用いられる揮発性の記憶手段である。すなわち、メインメモリ32は、画像処理やゲーム処理で用いられる各種データを一時的に記憶したり、外部(外部メモリ45や他の機器等)から取得されるプログラムを一時的に記憶したりする。
【0041】
外部メモリ45は、情報処理部31によって実行されるプログラムを記憶するための不揮発性の記憶手段である。外部メモリ45は、例えば読み取り専用の半導体メモリで構成される。外部メモリ45が外部メモリI/F33に接続されると、情報処理部31は外部メモリ45に記憶されたプログラムを読み込むことができる。情報処理部31が読み込んだプログラムを実行することにより、所定の処理が行われる。
【0042】
データ保存用内部メモリ35は、読み書き可能な不揮発性メモリ(例えばNAND型フラッシュメモリ)で構成され、所定のデータを格納するために用いられる。例えば、データ保存用内部メモリ35には、無線通信モジュール36を介した無線通信によってダウンロードされたデータやプログラムが格納される。
【0043】
無線通信モジュール36は、例えばIEEE802.11.b/gの規格に準拠した方式により、無線LANに接続する機能を有する。また、ローカル通信モジュール37は、所定の通信方式(例えば赤外線通信)により同種のゲーム装置との間で無線通信を行う機能を有する。無線通信モジュール36およびローカル通信モジュール37は、情報処理部31に接続される。情報処理部31は、無線通信モジュール36を用いてインターネットを介して他の機器との間でデータを送受信したり、ローカル通信モジュール37を用いて同種の他のゲーム装置との間でデータを送受信したりすることができる。
【0044】
入力部38は、操作ボタン、タッチパネル、および動きセンサ等の少なくとも1つからなり、情報処理部31に接続される。入力部38から情報処理部31へは、入力部38に対する入力状況を示す操作データが出力される。情報処理部31は、入力部38から操作データを取得することによって、入力部38に対する入力に応じた処理を実行する。
【0045】
表示部39は、情報処理部31に接続される。表示部39は、情報処理部31(GPU312)の指示にしたがって画像を表示する。
【0046】
次に、図3を参照して、マッチメイキングサーバ200について説明する。なお、図3は、マッチメイキングサーバ200の構成の一例を示すブロック図である。
【0047】
マッチメイキングサーバ200は、通信部201、制御部202、および記憶部203を有している。通信部201は、通信パケットの送受信を行うことで、ネットワーク100を介してゲーム装置3、ログ処理サーバ400、ログ処理装置500、および認証サーバ600等と通信を行う。制御部202は、複数の装置が通信して所定の処理(例えば、通信ゲーム)を行う際、当該処理を行うゲーム装置3の組み合わせ(マッチメイキング)を決定する処理、ゲーム装置3のユーザ毎の通報スコアを管理する処理、上記所定の処理後に当該処理のログを取得するか否かを決定する処理のほか、通信部201を介してゲーム装置3、ログ処理サーバ400、ログ処理装置500、および認証サーバ600等との通信リンクを確立し、ネットワーク100におけるデータ搬送制御や経路選択を行う。記憶部203は、制御部202で実行されるプログラム、ゲーム装置3の組み合わせを決定する処理に必要な各種データ、ユーザから通報された通報情報を示すデータ、ユーザ毎の通報スコアを示すデータ、ゲーム装置3、ログ処理サーバ400、ログ処理装置500、および認証サーバ600との通信に必要な各種データ等が記憶される。なお、マッチメイキングサーバ200は、単一のサーバマシンから構成されてもいいし、複数のサーバマシンによって構成されてもよい。また、図1の説明では、マッチメイキングサーバ200、ログ保管サーバ300、ログ処理サーバ400、ログ処理装置500、および認証サーバ600を、それぞれ別の装置で構成したが、これらの機能の少なくとも2つが単一の装置(例えば、単一のサーバマシン)で構成されてもかまわない。
【0048】
次に、ゲーム装置3やマッチメイキングサーバ200が行う具体的な処理を説明する前に、図4および図5を用いて通信システム1において行われる処理の概要について説明する。なお、図4は、通信システム1において、ユーザが通信ゲームに関する通報情報を通報する際の装置間のやりとりの一例を時間軸に沿って表現した図である。図5は、通信システム1において、通信ゲームのログを送信する際の装置間のやりとりの一例を時間軸に沿って表現した図である。なお、図4および図5を用いて説明する通信ゲーム例では、複数のユーザが通信して1つの通信ゲームを行う際、あるユーザが待機部屋を作成して他のユーザの入室を待ち、当該待機部屋に他のユーザが入室してメンバーが揃った場合に当該通信ゲームが当該メンバー間で開始される例を用いる。なお、以下の説明では、複数のゲーム装置3の間で実行するアプリケーションの一例として通信ゲームを用いているが、短い文章をリアルタイムにやり取りしてコミュニケーションを行うチャット等、複数のゲーム装置3の間で他のアプリケーションを実行してもかまわない。
【0049】
図4において、所定の通信ゲームを行う際、ゲーム装置3のユーザは、マッチメイキングサーバ200に対して他のユーザとの組み合わせを設定するためのマッチメイキング要求を行う。マッチメイキング要求を行う際、ゲーム装置3は、当該マッチメイキング要求およびマッチメイキング要求するゲームに関する情報(ゲームの種類、モード、ゲームレベル等を示す情報)とともに、ゲーム装置3のユーザを示すユーザIDをマッチメイキングサーバ200へ送信する。ここで、ユーザIDは、ユーザ識別が可能となるユニークな符号であればよく、例えばユーザ識別のための標識となる文字列であるアカウントIDでもかまわない。
【0050】
マッチメイキングサーバ200は、マッチメイキング要求したユーザの通報スコアを確認する。そして、マッチメイキングサーバ200は、マッチメイキング要求されたゲームに対して既に作成されている待機部屋のうち、通報スコアに応じた待機部屋を選出し、当該待機部屋で待機しているユーザを示す待機リストをマッチメイキング要求元へ送信する。例えば、マッチメイキングサーバ200は、通報スコアが第1の閾値T1未満の場合に通常の待機部屋(通常ギャザリング)を選出対象とし、通報スコアが第1の閾値T1以上の場合に隔離された待機部屋(専用ギャザリング)を選出対象とする。
【0051】
次に、マッチメイキング要求したゲーム装置3のユーザは、受信した待機リストに基づいた待機部屋の状況を見て、新たに待機部屋を作成する場合、マッチメイキングサーバ200に対して待機部屋作成要求を行う。待機部屋作成要求を行う際、ゲーム装置3は、当該待機部屋作成要求とともに、ユーザIDをマッチメイキングサーバ200へ送信する。
【0052】
マッチメイキングサーバ200は、待機部屋作成要求したユーザの通報スコアを確認する。そして、マッチメイキングサーバ200は、要求されたゲームに対して通報スコアに応じた待機部屋を作成して新たに登録する。例えば、マッチメイキングサーバ200は、通報スコアが第1の閾値T1未満の場合に通常の待機部屋を新たに登録し、通報スコアが第1の閾値T1以上の場合に隔離された待機部屋を新たに登録する。
【0053】
一方、上記所定の通信ゲームを行う他のゲーム装置3のユーザも、マッチメイキングサーバ200に対して他のユーザとの組み合わせを設定するためのマッチメイキング要求を行う。このマッチメイキング要求を行う場合も、ゲーム装置3は、当該マッチメイキング要求およびマッチメイキング要求するゲームに関する情報とともに、ゲーム装置3のユーザを示すユーザIDをマッチメイキングサーバ200へ送信する。そして、マッチメイキングサーバ200は、マッチメイキング要求したユーザの通報スコアに応じた待機部屋を選出し、当該待機部屋で待機しているユーザを示す待機リストをマッチメイキング要求元へ送信する。
【0054】
次に、マッチメイキング要求したゲーム装置3のユーザは、受信した待機リストに基づいた待機部屋の状況を見て、希望する待機部屋に入る場合、マッチメイキングサーバ200に対して待機部屋参加要求を行う。待機部屋参加要求を行う際、ゲーム装置3は、当該待機部屋参加要求とともに、ユーザIDをマッチメイキングサーバ200へ送信する。
【0055】
マッチメイキングサーバ200は、参加要求された待機部屋に要求元のユーザを登録する。そして、マッチメイキングサーバ200は、新たにユーザが登録された待機部屋に参加している全ユーザに対して、当該全ユーザを示す参加者情報(例えば、参加者全員のユーザID)を送信する。なお、新たに待機部屋に登録されたユーザに対しては、当該待機部屋に登録されている当該ユーザ以外の参加者を示す参加者情報を送信してもよい。また、既に待機部屋に登録されていたユーザに対しては、新たに当該待機部屋に登録された参加者のみを示す参加者情報を送信してもよい。
【0056】
次に、待機部屋に参加しているユーザは、所定の通信方式(例えば、ピアツーピア通信方式)を用いて互いに通信を行うことによって、通信ゲームを開始する。そして、通信ゲーム終了後、当該通信ゲームを行ったユーザに対して通報の機会が与えられる。ここで、上記通報は、通信ゲームを行った相手ユーザについて行うことができ、当該通信ゲームにおける相手の評価(不正行為の有無、マナーがよい、悪い等)を行うものである。ゲーム装置3のユーザが通報を行った場合、当該通報を行った相手のユーザIDと当該通報の理由とを示す情報がマッチメイキングサーバ200へ送信される。
【0057】
ユーザからの通報を受け取ったマッチメイキングサーバ200は、当該通報毎に当該通報に対する通報スコアを算出する。なお、後述により明らかとなるが、通報スコアは、マッチメイキングサーバ200において通報理由毎に予め定められている。そして、マッチメイキングサーバ200は、通報されたユーザに対して既に設定されている通報スコアに、算出された通報スコアを加減算し、加減算された通報スコアを用いて当該ユーザの通報スコアを更新する。
【0058】
次に、図5を参照して、通信ゲームのログを送信する際の動作の一例について説明する。図5において、マッチメイキングサーバ200は、ゲーム装置3から待機部屋作成要求を受信した際、当該要求元を通信ゲームログの取得対象とするか否かを判定する。そして、マッチメイキングサーバ200は、上記取得対象とする場合、ログ取得通知を上記要求元のユーザへ送信する。
【0059】
また、マッチメイキングサーバ200は、ゲーム装置3から待機部屋参加要求を受信した際、当該要求元を通信ゲームログの取得対象とするか否かを判定する。第1の例として、参加要求された待機部屋に上記取得対象となったユーザが含まれている場合、当該参加要求元のユーザも通信ゲームログの取得対象とし、ログ取得通知を当該参加要求元のユーザへ送信する。第2の例として、参加要求された待機部屋に既に参加しているユーザは上記取得対象ではないが、新たに参加要求したユーザを通信ゲームログの取得対象とする場合、当該待機部屋の参加者を全て通信ゲームログの取得対象とし、ログ取得通知を当該待機部屋の全ての参加者へ送信する。
【0060】
ログ取得通知を受信したゲーム装置3は、通信ゲームを行った後、当該通信ゲームのログをログ保管サーバ300に送信する。ここで、ゲーム装置3がログ保管サーバ300に送信するログは、アプリケーション(通信ゲーム)で発生したイベント(動作、事象、操作等)が記録されたイベントデータや、通信ゲームにおけるプレイを再現するゴーストデータ等がある。なお、ログ取得通知を受信したゲーム装置3は、当該ゲーム装置3のログだけでなく、通信ゲームを行った相手ユーザがプレイしているログも同時に送信してもよい。また、上述から明らかなように、ログ取得対象となった通信ゲームは、当該通信ゲームをプレイしている全ユーザがログ取得通知を受け取ることになる。この場合、ログ取得対象となった通信ゲームをプレイしている全ユーザが、相手ユーザのログを含めて当該通信ゲームのログをログ保管サーバ300に送信することになる。
【0061】
ログ処理サーバ400および/またはログ処理装置500は、ログ保管サーバ300に保管された通信ゲームの各ログを解析し、解析対象となった通信ゲームにおいて不正が行われていないか否かを判断する。そして、ログ処理サーバ400および/またはログ処理装置500は、通信ゲームにおいて不正が行われている場合、マッチメイキングサーバ200へ通報が行われる。例えば、上記通報において、ログ処理サーバ400および/またはログ処理装置500は、不正を行ったユーザのユーザIDと当該通報の理由とを示す情報を、マッチメイキングサーバ200へ送信する。
【0062】
ログ処理サーバ400が通信ゲームのログを解析する場合、当該ログによって示されている処理において当該通信ゲームであり得ないプレイ(例えば、あり得ない数のアイテムを使用している、移動できない空間を移動しているなど)が行われているか否かなど、予め定められた判定基準を自動的に解析することによって、ユーザが不正な行為を行っているか否かを判断する。また、ログ処理装置500が通信ゲームのログを解析する場合、当該ログによって示されている処理を実機(例えば、ゲーム装置3と同様の能力を有する装置)を用いて解析(再現)して、ユーザが不正な行為を行っているか否かを判断する。ここで、ログ処理装置500を用いたログ解析においては、通信ゲームを運営するオペレータ自身が当該ログを監視して、当該監視において不正行為の有無を判定してもかまわない。
【0063】
なお、ログ取得対象となった通信ゲームをプレイしている全ユーザが、相手ユーザのログを含めて当該通信ゲームのログをログ保管サーバ300に送信する場合、ログ処理サーバ400および/またはログ処理装置500は、送信されたログの整合性を確認することが可能となる。例えば、第1のゲーム装置3aと第2のゲーム装置3bとの間で実行する通信ゲームがログ取得対象となった場合、ログ処理サーバ400および/またはログ処理装置500は、第1のゲーム装置3aから取得した第1のゲーム装置3aのログと第2のゲーム装置3bから取得した第1のゲーム装置3aのログとの間の整合性を確認することが可能となる。また、ログ処理サーバ400および/またはログ処理装置500は、第2のゲーム装置3bから取得した第2のゲーム装置3bのログと第1のゲーム装置3aから取得した第2のゲーム装置3bのログとの間の整合性も確認することが可能となる。したがって、通信ゲームのログ解析においては、特定ユーザのログだけでなく通信ゲームに参加した全ユーザのログが解析対象となるため、特定ユーザがログを改ざんして送信したとしても他のユーザから送信された当該特定ユーザのログとの整合性を確認することによって改ざんされたログを検出することができる。また、あるユーザが通信ゲームを途中で止めて通信ゲーム後にログを送信しなかった場合も、他のユーザから送信された当該あるユーザのログを解析することによって、途中で通信ゲームを止めたユーザを検出することができる。
【0064】
また、ログ取得通知を受信したゲーム装置3は、ログ取得の対象となった通信ゲームを開始する前に当該通信ゲームの開始を示す情報を、ログ保管サーバ300にそれぞれ送信してもよい。ここで、通信ゲームの開始を示す情報の一例として、当該通信ゲームに関する空ログが考えられる。このように、通信ゲームの開始を示す情報をログ保管サーバ300に送信することによって、通信ゲーム開始後に当該通信ゲームを中断したユーザであっても当該情報がログ保管サーバ300にアップされているために、ログ処理サーバ400および/またはログ処理装置500によるログ解析によってユーザが通信ゲームを中断したことを検出することができる。したがって、ログ処理サーバ400および/またはログ処理装置500では、通信ゲームの中断有無をユーザ評価の一要素として加えることができる。
【0065】
ログ処理サーバ400および/またはログ処理装置500からの通報を受け取ったマッチメイキングサーバ200は、当該通報毎に当該通報に対する通報スコアを算出する。そして、マッチメイキングサーバ200は、通報されたユーザに対して既に設定されている通報スコアに、算出された通報スコアを加減算し、加減算された通報スコアを用いて当該ユーザの通報スコアを更新する。なお、通報スコアは、ユーザからの通報に対して、ログ処理サーバ400および/またはログ処理装置500からの不正行為の通報に対する通報スコアの絶対値を相対的に大きく設定してもかまわない。例えば、ユーザからの通報では虚偽の通報が行われる可能性があることに対して、ログ解析に基づいた通報は、その信用度が相対的に高くなるため、当該信用度に応じて通報スコアを設定することによって、通報スコアの信用度自体も高くすることが可能となる。
【0066】
上述したように、通報スコアは、マッチメイキングサーバ200において通信ゲームに参加するユーザを組み合わせる際に用いられているが、ユーザのアカウントを停止する場合の判断基準に用いることもできる。例えば、待機部屋の選出に用いる上記第1の閾値T1よりも相対的に大きい第3の閾値T3を設定し、通信ゲームの通報スコアが当該第3の閾値T3以上となったユーザを、当該通信ゲームに対するアカウントを停止する対象として抽出する。そして、アカウント停止対象となったユーザに対して、上記通信ゲームのログなどを所定の装置や運営者によって再解析するなど、所定の確認作業を行うことによって不正行為が確認された場合は、当該ユーザのアカウントを当該通信ゲームに関して停止することが考えられる。この場合、アカウントを停止するユーザのユーザIDと通信ゲームの種類とを示す情報を認証サーバ600に通知することによって、認証サーバ600においてアカウント停止処理を行ってもよい。なお、上述した手順では、アカウント停止対象となったユーザに対して、所定の確認作業を行った後にアカウント停止処置が行われる例を示したが、当該確認作業を行うことなく、通報スコアが第3の閾値T3以上となってアカウント停止対象となったユーザに対して、アカウントを停止する処置を即時に行ってもかまわない。
【0067】
このように、ユーザ毎に算出される通報スコアに基づいて、通信ゲームにおける待機部屋の選択が可能となるため、通報スコアの優劣に応じて通信ゲームにおいてユーザを組み合わせることができる。そのため、通報スコアが相対的に優れているユーザと通報スコアが相対的に劣っているユーザとが組み合わされることを防止される。ここで、ユーザ毎に算出される通報スコアは、通信ゲームを行った相手ユーザの通報に基づいて算出されるため、マッチメイキングサーバ200の処理負荷やサーバ運営者の作業負担を低減することができる。また、ユーザ毎に算出される通報スコアは、通信ゲームのログ解析に基づいて算出することも可能であるが、通信ゲームのログの一部が取得対象となるため、マッチメイキングサーバ200の処理負荷やサーバ運営者の作業負担を低減しながら、ログ解析によって通報スコアの信用度を向上させることもできる。
【0068】
次に、通信システム1において行われる処理の詳細を説明する。まず、図6〜図10を参照して、処理において用いられる主なデータについて説明する。なお、図6は、ゲーム装置3のメインメモリ32に記憶される主なデータおよびプログラムの一例を示す図である。図7は、マッチメイキングサーバ200の記憶部203に記憶される主なデータおよびプログラムの一例を示す図である。図8は、記憶部203に記憶される通報スコアテーブルデータDmの一例を示す図である。図9は、記憶部203に記憶される通報ログ情報データDnの一例を示す図である。図10は、記憶部203に記憶される通報スコア情報データDoの一例を示す図である。
【0069】
図6に示すように、メインメモリ32のデータ記憶領域には、操作データDa、ユーザIDデータDb、パスワードデータDc、デバイスIDデータDd、通報相手データDe、通報理由データDf、参加者情報データDg、ログ取得対象フラグデータDh、ログデータDi、および表示画像データDj等が記憶される。なお、メインメモリ32には、図6に示す情報に含まれるデータの他、実行するアプリケーションで用いるデータ等、処理に必要なデータが記憶される。また、メインメモリ32のプログラム記憶領域には、通信プログラムを構成する各種プログラム群Paが記憶される。
【0070】
操作データDaは、ユーザがゲーム装置3を操作した操作情報を示すデータである。例えば、操作ボタン等を操作したことを示す操作データは、ゲーム装置3が処理する時間単位(例えば、1/60秒)毎に取得され、当該取得に応じて操作データDaに格納されて更新される。
【0071】
ユーザIDデータDbは、ゲーム装置3を使用するユーザの識別が可能となるユニークな符号(ユーザID)を示すデータであり、例えばユーザ識別のための標識となる文字列であるアカウントIDを示すデータである。パスワードデータDcは、ゲーム装置3を用いてネットワーク100にログインする際に用いられるパスワードを示すデータである。
【0072】
デバイスIDデータDdは、ゲーム装置3毎に識別が可能となるユニークな符号(デバイスID)を示すデータであり、例えばデバイス識別のための標識となる改変不可能な文字列を示すデータである。そして、デバイスIDデータDdには、ゲーム装置3に対して予め設定されているデバイスIDが格納されている。
【0073】
通報相手データDeは、ユーザが通報する際の通報相手を示すデータであり、例えば当該通報相手のユーザIDを示すデータである。通報理由データDfは、ユーザが通報する際に選択した通報理由を示すデータである。
【0074】
参加者情報データDgは、通信ゲームを行う際に、当該通信ゲームの参加者を示すデータであり、例えば当該通信ゲームに参加する参加者全員のユーザIDを示すデータである。
【0075】
ログ取得対象フラグデータDhは、マッチメイキングサーバ200から通信ゲームのログを取得する対象に指定された際にオンに設定されるログ取得対象フラグを示すデータである。なお、ログ取得対象フラグは、後述するゲームアプリケーションを起動する際、オフに初期化される。ログデータDiは、通信ゲームを行った際のログを示すデータであり、当該通信ゲームに参加した全ユーザのログが格納される。
【0076】
表示画像データDjは、オブジェクト、文字、および背景等配置した画像を生成して表示部39に表示するためのデータである。
【0077】
図7に示すように、記憶部203のデータ記憶領域には、通報スコアテーブルデータDm、通報ログ情報データDn、通報スコア情報データDo、通常部屋情報データDp、および隔離部屋情報データDq等が記憶される。なお、記憶部203には、図7に示す情報に含まれるデータの他、マッチメイキングサーバ200で行う処理に必要なデータ等が記憶される。また、記憶部203のプログラム記憶領域には、上記処理を実現するための各種プログラム群Pbが記憶される。
【0078】
図8に示すように、通報スコアテーブルデータDmは、ユーザから通報された通報理由それぞれに応じて、予め設定された通報スコアを示すデータである。例えば、ユーザからの通報理由が「不正行為」である場合、通報スコアが+2に設定されている。ユーザからの通報理由が「マナーが悪い」である場合、通報スコアが+1に設定されている。ユーザからの通報理由が「うますぎる」や「下手すぎる」である場合、通報スコアが0に設定されている。そして、ユーザからの通報理由が「マナーがよい」である場合、通報スコアが−1に設定されている。
【0079】
このように、図8に示した一例では、通信ゲームに関する通報理由の劣悪度合に応じて、劣悪度合が高いほど大きな値に通報スコアが設定されている。また、通信ゲームにおいて優良な相手であった場合の通報では、通報スコアが負の値に設定されており、不正行為なくマナーのよいゲームプレイを行った場合に自身の通報スコアを下げることが可能となり、各ユーザに優良なプレイを推奨する対策にもなり得る。さらに、図8に示した一例では、通報スコアが0に設定されている通報理由も設定されている。後述により明らかとなるが、ユーザは、複数の選択肢から選択することによって通報理由を選択することが可能である。一方、ユーザがゲームの熟練者や初心者である場合等、ユーザのプレイレベルに起因して通報されることが考えられる。つまり、相手のゲームプレイが劣悪であった場合の通報理由のみ選択可能に構成した場合、本来通信ゲームの相手に対する劣悪さが通報理由ではない場合であっても、劣悪であったことが原因となった通報理由が通報されてしまう。したがって、劣悪さにも優良さにも起因しない理由が通報理由であった場合、通報スコアに影響しない通報理由を選択肢に含ませることによって、ユーザからの誤通報を防止することが可能となる。
【0080】
なお、このような効果を期待しない場合、通報理由に応じて設定される通報スコアは、正の値だけ、正の値と零との組み合わせ、または正の値と負の値との組み合わせでもかまわない。このような通報スコアの設定であっても、劣悪度合に応じた通報スコアの設定が可能であるため、後述するマッチメイキング処理において、通信ゲームに対する劣悪度合に応じたユーザの層別が可能となる。
【0081】
図9に示すように、通報ログ情報データDnは、ユーザからマッチメイキングサーバ200に通報された通報ログをそれぞれ示すデータである。例えば、通報ログ情報データDnは、通報者のユーザIDおよびデバイスIDと、被通報者のユーザIDおよびデバイスIDと、通報者が通報した通報理由とを、通報毎に示すデータである。
【0082】
図10に示すように、通報スコア情報データDoは、ユーザ毎に設定されている通報スコアを示すデータである。例えば、通報スコア情報データDoは、デバイスID、通報スコア、および当該通報スコアの最新更新日を、ユーザ毎に示すデータである。
【0083】
通常部屋情報データDpは、ゲーム毎に設定されている通常の待機部屋に関するデータであり、通常の待機部屋の数および種別等とともに、それぞれの待機部屋で待機しているユーザを示すデータである。隔離部屋情報データDqは、ゲーム毎に設定されている隔離された待機部屋に関するデータであり、隔離された待機部屋の数および種別等とともに、それぞれの待機部屋で待機しているユーザを示すデータである。ここで、「隔離」とは、通常の待機部屋に対して隔離された環境であることを示しており、通報スコアが上記第1の閾値T1以上のユーザは、隔離された待機部屋のみ利用可能となる。
【0084】
なお、上述した説明では、通常の待機部屋用の通常部屋情報データDpと隔離された待機部屋用の隔離部屋情報データDqとをそれぞれ設定しているが、1つの待機部屋用のデータを用いてもかまわない。例えば、上記1つの待機部屋用のデータにおいて、通常の待機部屋か隔離された待機部屋かを区別するフラグ(例えば、通常の待機部屋の場合にオフに設定され、隔離された待機部屋の場合にオンに設定されるフラグ)を設定し、当該フラグによって上記通常部屋情報データDpと隔離部屋情報データDqとを区別して運用してもかまわない。
【0085】
次に、図11〜図18を参照して、ゲーム装置3およびマッチメイキングサーバ200において行われる処理の詳細を説明する。なお、図11は、ゲーム装置3において実行される処理の一例を示すフローチャートである。図12は、図11におけるステップ44のゲーム参加処理の一例を示すサブルーチンである。図13は、図11におけるステップ52の通報処理の一例を示すサブルーチンである。図14は、マッチメイキングサーバ200において実行される処理の一例を示すフローチャートである。図15は、図14におけるステップ92の待機リスト送信処理の一例を示すサブルーチンである。図16は、図14におけるステップ94の待機部屋作成処理の一例を示すサブルーチンである。図17は、図14におけるステップ96の待機部屋参加処理の一例を示すサブルーチンである。図18は、図14におけるステップ98の通報スコア算出処理の一例を示すサブルーチンである。ここで、図11〜図18に示すフローチャートにおいては、通信システム1における処理のうち、通報スコアが算出される処理やログが取得される処理について主に説明し、これらの処理と直接関連しない他の処理については詳細な説明を省略する。また、図11〜図18では、CPU311が実行する各ステップを「S」と略称する。
【0086】
ゲーム装置3の電源が投入されると、ゲーム装置3のCPU311は、ROM/RTC13に記憶されている起動用のプログラムを実行し、これによってメインメモリ32等の各ユニットが初期化される。そして、外部メモリ45等に記憶された通信プログラムがメインメモリ32に読み込まれ、CPU311によって当該プログラムの実行が開始される。図11〜図13に示すフローチャートは、以上の処理が完了した後に行われる処理を示すフローチャートである。
【0087】
図11において、CPU311は、ネットワーク100にログインする処理を行い(ステップ41)、次のステップに処理を進める。例えば、CPU311は、ユーザIDデータDbが示すユーザID、パスワードデータDcが示すパスワード、およびデバイスIDデータDdが示すデバイスIDを用いて、ネットワーク100にログインする処理を行う。ネットワーク100に接続されている認証サーバ600は、ログインの際に送信されたユーザIDおよびパスワードを用いてアカウント認証を行い、当該認証結果を送信元(ゲーム装置3)に送信する。なお、本実施例においては、認証サーバ600は、ネットワーク100の利用者のユーザIDおよびパスワードとともに、ログインに用いられたゲーム装置3のデバイスIDをユーザIDに関連付けて管理する。
【0088】
次に、CPU311は、認証サーバ600から認証結果を待ち(ステップ42)、アカウント認証によってログイン権利が確認された場合、次のステップ43に処理を進める。
【0089】
ステップ43において、CPU311はゲームアプリケーションを起動する。そして、CPU311は、ゲーム参加処理を行い(ステップ44)、次のステップに処理を進める。以下、図12を参照して、上記ステップ44において行われるゲーム参加処理について説明する。
【0090】
図12において、CPU311は、上記ステップ44で起動したゲームを他のユーザも参加する通信ゲーム形式で行うために、マッチメイキングサーバ200にマッチメイキング要求を送信する(ステップ61)。なお、CPU311は、マッチメイキング要求を送信する際、マッチメイキング要求するゲームに関する情報(ゲームの種類、モード、ゲームレベル等を示す情報)とともに、ゲーム装置3のユーザを示すユーザID(ユーザIDデータDbが示すユーザID)をマッチメイキングサーバ200へ送信する。そして、CPU311は、マッチメイキングサーバ200から送信される待機リストを待ち(ステップ62)、待機リストを受領した場合、次のステップ63に処理を進める。
【0091】
ステップ63において、CPU311は、受領した待機リストに基づいて、現時点における待機部屋の状況を表示部39に表示し、次のステップに処理を進める。ここで、マッチメイキングサーバ200は、マッチメイキング要求したユーザの通報レベルに応じた待機リストをマッチメイキング要求元に送信している。具体的には、マッチメイキングサーバ200は、マッチメイキング要求したユーザの通報レベルが第1の閾値T1未満である場合、通常の待機部屋の数および種別等とともに、通常の待機部屋でそれぞれ待機しているユーザを示す待機リストを送信する。一方、マッチメイキングサーバ200は、マッチメイキング要求したユーザの通報レベルが第1の閾値T1以上である場合、隔離された待機部屋の数および種別等とともに、隔離された待機部屋でそれぞれ待機しているユーザを示す待機リストを送信する。したがって、上記ステップ63において、ゲーム装置3の表示部39には、ユーザの通報レベルが第1の閾値T1未満の場合に通常の待機部屋の状況が表示され、ユーザの通報レベルが第1の閾値T1以上の場合に隔離された待機部屋の状況が表示されることになる。
【0092】
次に、CPU311は、ステップ44で起動した通信ゲームに参加するか否かを判断する(ステップ64)。例えば、CPU311は、操作データDaを参照して、通信ゲームに参加する操作をユーザが行ったと判断した場合、当該通信ゲームに参加すると判断する。そして、CPU311は、通信ゲームに参加する場合、次のステップ65に処理を進める。一方、CPU311は、通信ゲームに参加しない場合、上記ステップ62に戻って処理を繰り返す。
【0093】
ステップ65において、CPU311は、待機部屋を新たに作成するか否かを判断する。例えば、CPU311は、操作データDaを参照して、待機部屋を新たに作成する操作をユーザが行ったと判断した場合、当該待機部屋を作成すると判断する。そして、CPU311は、待機部屋を新たに作成する場合、次のステップ66に処理を進める。一方、CPU311は、待機部屋を新たに作成しない場合、次のステップ67に処理を進める。
【0094】
ステップ66において、CPU311は、マッチメイキングサーバ200に待機部屋作成要求を送信し、次のステップ67に処理を進める。なお、CPU311は、待機部屋作成要求を送信する際、待機部屋を作成するゲームに関する情報(ゲームの種類、モード、ゲームレベル等を示す情報)とともに、ゲーム装置3のユーザを示すユーザID(ユーザIDデータDbが示すユーザID)をマッチメイキングサーバ200へ送信する。
【0095】
ステップ67において、CPU311は、既に作成されている待機部屋に入るか否かを判断する。例えば、CPU311は、操作データDaを参照して、待機部屋に入る操作をユーザが行ったと判断した場合、当該待機部屋に入ると判断する。そして、CPU311は、待機部屋に入る場合、次のステップ68に処理を進める。一方、CPU311は、待機部屋に入らない場合、次のステップ69に処理を進める。
【0096】
ステップ68において、CPU311は、マッチメイキングサーバ200に待機部屋参加要求を送信し、次のステップ69に処理を進める。なお、CPU311は、待機部屋参加要求を送信する際、上記ステップ63において表示された待機部屋から選択された参加要求する待機部屋に関する情報とゲーム装置3のユーザを示すユーザID(ユーザIDデータDbが示すユーザID)とを、マッチメイキングサーバ200へ送信する。
【0097】
ステップ69において、CPU311は、マッチメイキングサーバ200から参加者情報およびログ取得通知を受信し、次のステップに処理を進める。ここで、マッチメイキングサーバ200は、新たなユーザが待機部屋に登録された場合、当該待機部屋に参加している全ユーザに対して、当該全ユーザを示す参加者情報(例えば、参加者全員のユーザID)を送信している。一例として、マッチメイキングサーバ200は、既に待機部屋に登録されていたユーザに対しては、新たに当該待機部屋にユーザが登録される毎に、新たに登録されたユーザを示す参加者情報を送信する。また、マッチメイキングサーバ200は、新たに待機部屋に登録されたユーザに対しては、当該待機部屋に既に登録されているユーザを示す参加者情報を送信する。また、マッチメイキングサーバ200は、待機部屋が作成された際、および待機部屋に登録される際、当該待機部屋をログ取得対象とした場合は、当該待機部屋に登録されているユーザに対してログ取得通知を送信している。上記ステップ69においては、このようにマッチメイキングサーバ200が参加者情報および/またはログ取得通知を送信した場合に受信する処理を行う。そして、CPU311は、受信した参加者情報を用いて、参加者情報データDgを更新する。また、CPU311は、ログ取得通知を受信した場合、ログ取得対象フラグをオンに設定して、ログ取得対象フラグデータDhを更新する。
【0098】
次に、CPU311は、通信ゲームを開始するか否かを判断する(ステップ70)。通信ゲームを開始する条件としては、例えば、通信ゲームを開始する条件が満たされたこと(例えば、参加者の数が所定の人数に到達、参加者募集後に所定時間が経過)や、ユーザが通信ゲームを開始する操作を行ったこと等がある。CPU311は、通信ゲームを開始しない場合に上記ステップ65に戻って処理を繰り返し、通信ゲームを開始する場合に当該サブルーチンによる処理を終了する。
【0099】
図11に戻り、上記ステップ44のゲーム参加処理の後、CPU311は、上記ステップ44において参加した通信ゲームがログ取得対象か否かを判断する(ステップ45)。例えば、CPU311は、ログ取得対象フラグデータDhが示すログ取得対象フラグがオンに設定されている場合、上記通信ゲームがログ取得対象であると判断する。そして、CPU311は、上記通信ゲームがログ取得対象である場合、次のステップ46に処理を進める。一方、CPU311は、上記通信ゲームがログ取得対象でない場合、次のステップ47に処理を進める。
【0100】
ステップ46において、CPU311は、ログ保管サーバ300に通信ゲームが開始されたことを示すログを送信し、次のステップ47に処理を進める。例えば、CPU311は、空ログと通信ゲームの参加者を示すユーザID(ゲーム装置3のユーザIDを含む)とを送ることによって、通信ゲームが開始されたことと当該通信ゲームの参加者とをログ保管サーバ300に通知する。なお、上記ステップ46で送信する空ログは、通信ゲームの開始を示す情報の一例であり、当該通信ゲームの開始を示すことが可能なものであれば他のデータを送信してもかまわない。
【0101】
ステップ47において、CPU311は、起動されたゲームアプリケーションに基づいて、ゲーム処理を行い、次のステップに処理を進める。なお、上記ステップ47では、参加者情報データDgが示す参加者情報に基づいて、当該参加者情報が示す他のゲーム装置3と通信しながら当該他のゲーム装置3のユーザが参加する通信ゲームが実行される。また、CPU311は、上記ステップ47のゲーム処理におけるログを、他の参加者のログも含めてログデータDiに記録する。
【0102】
次に、CPU311は、ゲームを終了するか否かを判断する(ステップ48)。ゲームを終了する条件としては、例えば、ゲームを終了させる条件が満たされたこと(例えば、ゲームオーバ)や、ユーザがゲームを終了する操作を行ったこと等がある。CPU311は、ゲームを終了しない場合に上記ステップ47に戻って処理を繰り返し、ゲームを終了する場合に次のステップ49に処理を進める。
【0103】
ステップ49において、CPU311は、上記ステップ44において参加した通信ゲームがログ取得対象か否かを判断する。例えば、CPU311は、ログ取得対象フラグデータDhが示すログ取得対象フラグがオンに設定されている場合、上記通信ゲームがログ取得対象であると判断する。そして、CPU311は、上記通信ゲームがログ取得対象である場合、次のステップ50に処理を進める。一方、CPU311は、上記通信ゲームがログ取得対象でない場合、次のステップ51に処理を進める。
【0104】
ステップ50において、CPU311は、ログ保管サーバ300に上記ステップ47において実行された通信ゲームのログを送信し、次のステップ51に処理を進める。例えば、CPU311は、ログデータDiが示すゲームログと通信ゲームの参加者を示すユーザID(ゲーム装置3のユーザIDを含む)とを送ることによって、通信ゲームのログと当該通信ゲームの参加者とをログ保管サーバ300に送信する。
【0105】
ステップ51において、CPU311は、通報を行うか否かを判断する。例えば、CPU311は、上記通信ゲームが終了した際、当該通信ゲームに関する通報処理を行うことを示す通報ボタンを表示部39に表示する。そして、CPU311は、操作データDaを参照して、表示部39に表示された通報ボタンを選択する操作をユーザが行ったと判断した場合、通報を行うと判断する。そして、CPU311は、通報を行う場合、次のステップ52に処理を進める。一方、CPU311は、通報を行わない場合、当該フローチャートによる処理を終了する。
【0106】
ステップ52において、CPU311は、通報処理を行い、当該フローチャートによる処理を終了する。以下、図13を参照して、上記ステップ52において行われる通報処理について説明する。
【0107】
図13において、CPU311は、通報相手を選択し(ステップ81)、次のステップに処理を進める。例えば、CPU311は、参加者情報データDgが示す参加者に基づいて、終了した通信ゲームに参加していた他のユーザのリストを表示部39に表示して、ユーザに通報相手の選択を促す。そして、CPU311は、操作データDaを参照して、ユーザが入力部38を用いて選択したユーザ(通報相手)を抽出し、当該ユーザを示すユーザIDを用いて通報相手データDeを更新する。
【0108】
次に、CPU311は、通報理由を選択し(ステップ82)、次のステップに処理を進める。例えば、CPU311は、予め設定されている複数の通報理由を表示部39に表示して、ユーザに通報理由の選択を促す。ユーザに選択を促す通報理由の選択肢は、図8に示したように、一例として「不正行為」、「マナーが悪い」、「うますぎる」、「下手すぎる」、「マナーがよい」等が考えられる。そして、CPU311は、操作データDaを参照して、ユーザが入力部38を用いて選択した通報理由を抽出し、当該通報理由を用いて通報理由データDfを更新する。
【0109】
次に、CPU311は、通報情報をマッチメイキングサーバ200に送信し(ステップ83)、当該サブルーチンによる処理を終了する。例えば、CPU311は、通報相手データDeが示す通報相手のユーザIDと通報理由データDfが示す通報理由とを示す情報を用いて、通報情報をマッチメイキングサーバ200へ送信する。
【0110】
なお、上述したフローチャートでは、通信ゲームの終了直後に当該通信ゲームの参加者を通報相手とした通報が可能となる例を用いたが、他のタイミングで通報可能にしてもいいし、他の通報相手を通報対象としてもかまわない。例えば、通報が行えるタイミングは、上記通信ゲームが終了した後であれば、いつでも通報可能に構成してもかまわない。また、通報相手は、自身がプレイした通報ゲームの参加者でなくてもかまわない。例えば、ゲームに関する特定のユーザ(例えば、当該ゲームの得点ランキングに入っているユーザや通報ランキングに入っているユーザ)を通報相手として、上記通報情報を送信可能に構成してもかまわない。
【0111】
図14において、マッチメイキングサーバ200の制御部202は、ゲーム装置3からマッチメイキング要求を受領したか否かを判断する(ステップ91)。そして、制御部202は、マッチメイキング要求を受領した場合、次のステップ92に処理を進める。一方、制御部202は、マッチメイキング要求を受領していない場合、次のステップ93に処理を進める。
【0112】
ステップ92において、制御部202は、マッチメイキング要求を送信した送信元のゲーム装置3に待機リストを送信する処理を行い、次のステップ93に処理を進める。以下、図15を参照して、上記ステップ92において行われる待機リスト送信処理について説明する。
【0113】
図15において、制御部202は、マッチメイキング要求した要求元のデバイスIDを取得して(ステップ101)、次のステップに処理を進める。例えば、制御部202は、マッチメイキング要求を送信したゲーム装置3から送信されたユーザIDのアカウント認証を認証サーバ600に問い合わせるとともに、ユーザIDに対応するデバイスIDを要求する。そして、制御部202は、ユーザIDのアカウント認証を認証サーバ600に確認し、ログイン権利が確認された場合、当該ユーザIDに対応するデバイスIDを取得する。
【0114】
なお、アカウント認証処理については、マッチメイキングサーバ200にアクセスする前段階で既に行われている(例えば、ステップ41、ステップ42)ため、当該アクセスの都度行わなくてもかまわない。この場合、マッチメイキングサーバ200が認証サーバ600と直接通信することは不要となり、マッチメイキングサーバ200にアクセスしたゲーム装置3のデバイスIDについても当該ゲーム装置3から直接取得すればよい。なお、以下の説明においては、マッチメイキングサーバ200にアクセスする毎にマッチメイキングサーバ200がアカウント認証を認証サーバ600に問い合わせるとともに、ユーザIDに対応するデバイスIDを要求する例を用いる。
【0115】
次に、制御部202は、上記ステップ101で取得したデバイスIDに対応する通報スコアNSを抽出し(ステップ102)、次のステップに処理を進める。例えば、制御部202は、通報スコア情報データDoを参照して、上記ステップ101で取得したデバイスIDに対応する通報スコアNSを抽出する。
【0116】
次に、制御部202は、上記ステップ102で抽出した通報スコアNSが第1の閾値T1未満か否かを判断する(ステップ103)。そして、制御部202は、通報スコアNSが第1の閾値T1未満である場合、次のステップ104に処理を進める。一方、制御部202は、通報スコアNSが第1の閾値T1以上である場合、次のステップ105に処理を進める。
【0117】
ステップ104において、制御部202は、通常の待機部屋の待機リストを送信し、当該サブルーチンによる処理を終了する。例えば、制御部202は、通常部屋情報データDpを参照し、マッチメイキング要求されたゲームにおいて、通常の待機部屋の数および種別等とともに、当該通常の待機部屋に登録されているユーザを示す待機リストを作成して、マッチメイキング要求した要求元のゲーム装置3へ当該待機リストを送信する。
【0118】
一方、ステップ105において、制御部202は、隔離された待機部屋の待機リストを送信し、当該サブルーチンによる処理を終了する。例えば、制御部202は、隔離部屋情報データDqを参照し、マッチメイキング要求されたゲームにおいて、隔離された待機部屋の数および種別等とともに、当該隔離された待機部屋に登録されているユーザを示す待機リストを作成して、マッチメイキング要求した要求元のゲーム装置3へ当該待機リストを送信する。
【0119】
図14に戻り、ステップ93において、制御部202は、ゲーム装置3から待機部屋作成要求を受領したか否かを判断する。そして、制御部202は、待機部屋作成要求を受領した場合、次のステップ94に処理を進める。一方、制御部202は、待機部屋作成要求を受領していない場合、次のステップ95に処理を進める。
【0120】
ステップ94において、制御部202は、待機部屋作成処理を行い、次のステップ95に処理を進める。以下、図16を参照して、上記ステップ94において行われる待機部屋作成処理について説明する。
【0121】
図16において、制御部202は、待機部屋作成要求した要求元のデバイスIDを取得して(ステップ111)、次のステップに処理を進める。例えば、制御部202は、待機部屋作成要求を送信したゲーム装置3から送信されたユーザIDのアカウント認証を認証サーバ600に問い合わせるとともに、ユーザIDに対応するデバイスIDを要求する。そして、制御部202は、ユーザIDのアカウント認証を認証サーバ600に確認し、ログイン権利が確認された場合、当該ユーザIDに対応するデバイスIDを取得する。
【0122】
次に、制御部202は、上記ステップ111で取得したデバイスIDに対応する通報スコアNSを抽出し(ステップ112)、次のステップに処理を進める。例えば、制御部202は、通報スコア情報データDoを参照して、上記ステップ111で取得したデバイスIDに対応する通報スコアNSを抽出する。
【0123】
次に、制御部202は、上記ステップ112で抽出した通報スコアNSが第1の閾値T1未満か否かを判断する(ステップ113)。そして、制御部202は、通報スコアNSが第1の閾値T1未満である場合、次のステップ114に処理を進める。一方、制御部202は、通報スコアNSが第1の閾値T1以上である場合、次のステップ115に処理を進める。
【0124】
ステップ114において、制御部202は、待機部屋作成要求した要求元に対して当該要求元が要求したゲームの待機部屋として通常の待機部屋を用意し、当該待機部屋に当該要求元のユーザを登録して、次のステップ116に処理を進める。例えば、制御部202は、待機部屋作成要求されたゲームにおいて新たに通常の待機部屋を用意し、当該待機部屋に上記要求元のユーザIDを登録して、通常部屋情報データDpを更新する。これによって、通常部屋情報データDpには、待機部屋作成要求されたゲームにおいて、当該要求元が待機している新たな通常の待機部屋が、当該要求元のユーザIDとともに登録されることになる。
【0125】
一方、ステップ115において、制御部202は、待機部屋作成要求した要求元に対して当該要求元が要求したゲームの待機部屋として隔離された待機部屋を用意し、当該待機部屋に当該要求元のユーザを登録して、次のステップ116に処理を進める。例えば、制御部202は、待機部屋作成要求されたゲームにおいて新たに隔離された待機部屋を用意し、当該待機部屋に上記要求元のユーザIDを登録して、隔離部屋情報データDqを更新する。これによって、隔離部屋情報データDqには、待機部屋作成要求されたゲームにおいて、当該要求元が待機している新たな隔離された待機部屋が、当該要求元のユーザIDとともに登録されることになる。
【0126】
ステップ116において、制御部202は、上記ステップ114またはステップ115において作成した待機部屋を用いて行われる通信ゲームを、ログ取得対象とするか否かを判断する。そして、制御部202は、上記通信ゲームをログ取得対象とする場合、次のステップ117に処理を進める。一方、制御部202は、上記通信ゲームをログ取得対象としない場合、当該サブルーチンによる処理を終了する。第1の例として、制御部202は、待機部屋作成要求したユーザの通報スコアNSが第2の閾値T2以上である場合、当該ユーザが待機している待機部屋を用いて行われる通信ゲームをログ取得対象とする。第2の例として、制御部202は、待機部屋作成要求したユーザが待機している待機部屋を用いて行われる通信ゲームをログ取得対象とするか否かを、ランダム選択によって決定する。第3の例として、制御部202は、上記第1の例および第2の例を組み合わせてログ取得対象とするか否かを判断する。一例として、制御部202は、待機部屋作成要求したユーザの通報スコアNSが第2の閾値T2未満の場合に当該ユーザが待機している待機部屋を用いて行われる通信ゲームをログ取得対象とせず、当該通報スコアNSが第2の閾値T2以上の場合に当該待機部屋を用いて行われる通信ゲームをログ取得対象とするか否かをランダム選択によって決定する。他の例として、制御部202は、待機部屋作成要求したユーザの通報スコアNSが第2の閾値T2未満の場合に当該ユーザが待機している待機部屋を用いて行われる通信ゲームをログ取得対象とするか否かをランダム選択によって決定し、当該通報スコアNSが第2の閾値T2以上の場合に当該待機部屋を用いて行われる通信ゲームを必ずログ取得対象とする。
【0127】
ステップ117において、制御部202は、待機部屋作成要求したゲーム装置3にログ取得通知を送信し、当該サブルーチンによる処理を終了する。例えば、制御部202は、待機部屋作成要求したユーザが待機している待機部屋をログ取得対象に設定して、当該待機部屋が管理されている通常部屋情報データDpまたは隔離部屋情報データDqを更新する。そして、制御部202は、待機部屋作成要求したゲーム装置3に、作成した待機部屋を用いた通信ゲームがログの取得対象であることを示すログ取得通知を送信する。
【0128】
図14に戻り、ステップ95において、制御部202は、ゲーム装置3から待機部屋参加要求を受領したか否かを判断する。そして、制御部202は、待機部屋参加要求を受領した場合、次のステップ96に処理を進める。一方、制御部202は、待機部屋参加要求を受領していない場合、次のステップ97に処理を進める。
【0129】
ステップ96において、制御部202は、待機部屋参加処理を行い、次のステップ97に処理を進める。以下、図17を参照して、上記ステップ96において行われる待機部屋参加処理について説明する。
【0130】
図17において、制御部202は、待機部屋参加要求した要求元のデバイスIDを取得して(ステップ121)、次のステップに処理を進める。例えば、制御部202は、待機部屋参加要求を送信したゲーム装置3から送信されたユーザIDのアカウント認証を認証サーバ600に問い合わせるとともに、ユーザIDに対応するデバイスIDを要求する。そして、制御部202は、ユーザIDのアカウント認証を認証サーバ600に確認し、ログイン権利が確認された場合、当該ユーザIDに対応するデバイスIDを取得する。
【0131】
次に、制御部202は、待機部屋参加要求したユーザを、参加要請された待機部屋に登録し(ステップ122)、次のステップに処理を進める。例えば、制御部202は、参加要請された待機部屋に待機部屋参加要求したユーザのユーザIDを登録して、当該待機部屋を管理している通常部屋情報データDpまたは隔離部屋情報データDqを更新する。これによって、通常部屋情報データDpまたは隔離部屋情報データDqには、待機部屋参加要求されたゲームにおいて、参加要請された待機部屋に参加要求元のユーザIDが登録されることになる。
【0132】
次に、制御部202は、参加者情報を送信し(ステップ123)、次のステップに処理を進める。例えば、制御部202は、上記ステップ122において新たなユーザが待機部屋に登録された場合、当該待機部屋に参加している全ユーザのゲーム装置3に対して、当該全ユーザを示す参加者情報(例えば、参加者全員のユーザID)を送信する。なお、マッチメイキングサーバ200は、既に待機部屋に登録されていたユーザのゲーム装置3に対しては、新たに登録されたユーザのみを示す参加者情報を送信してもよい。また、マッチメイキングサーバ200は、新たに待機部屋に登録されたユーザのゲーム装置3に対しては、当該待機部屋に既に登録されているユーザのみを示す参加者情報を送信してもよい。
【0133】
次に、制御部202は、参加要請された待機部屋がログ取得対象か否かを判断する(ステップ124)。例えば、制御部202は、参加要請された待機部屋を管理している通常部屋情報データDpまたは隔離部屋情報データDqを参照して、当該待機部屋がログ取得対象に設定されているか否かを判断する。そして、制御部202は、参加要請された待機部屋がログ取得対象である場合、次のステップ125に処理を進める。一方、制御部202は、参加要請された待機部屋がログ取得対象でない場合、次のステップ126に処理を進める。
【0134】
ステップ125において、制御部202は、待機部屋参加要求したゲーム装置3にログ取得通知を送信し、当該サブルーチンによる処理を終了する。例えば、制御部202は、待機部屋参加要求したゲーム装置3に、参加要請した待機部屋を用いた通信ゲームがログの取得対象であることを示すログ取得通知を送信する。
【0135】
一方、ステップ126において、制御部202は、上記ステップ121で取得したデバイスIDに対応する通報スコアNSを抽出し、次のステップに処理を進める。例えば、制御部202は、通報スコア情報データDoを参照して、上記ステップ121で取得したデバイスIDに対応する通報スコアNSを抽出する。
【0136】
次に、制御部202は、参加要請された待機部屋を用いて行われる通信ゲームを、ログ取得対象とするか否かを判断する(ステップ127)。そして、制御部202は、上記通信ゲームをログ取得対象とする場合、次のステップ128に処理を進める。一方、制御部202は、上記通信ゲームをログ取得対象としない場合、当該サブルーチンによる処理を終了する。なお、上記ステップ127においてログ取得対象とするか否かを判断する方法例は、待機部屋作成要求したユーザの通報スコアNSが用いられる例が、上記ステップ126で抽出した待機部屋作成要求したユーザの通報スコアNSが用いられることを除いて、上記ステップ116における処理と同様であるため、ここでは詳細な説明を省略する。
【0137】
ステップ128において、制御部202は、参加要請された待機部屋に登録されている全ユーザのゲーム装置3にログ取得通知を送信し、当該サブルーチンによる処理を終了する。例えば、制御部202は、待機部屋参加要求されたユーザを登録した待機部屋をログ取得対象に設定して、当該待機部屋が管理されている通常部屋情報データDpまたは隔離部屋情報データDqを更新する。そして、制御部202は、当該待機部屋に登録されている全ユーザのゲーム装置3に、参加している待機部屋を用いた通信ゲームがログの取得対象であることを示すログ取得通知を送信する。
【0138】
図14に戻り、ステップ97において、制御部202は、他の装置(ゲーム装置3、ログ処理サーバ400、ログ処理装置500等)から通報を受領したか否かを判断する。そして、制御部202は、通報を受領した場合、次のステップ98に処理を進める。一方、制御部202は、通報を受領していない場合、次のステップ99に処理を進める。
【0139】
ステップ98において、制御部202は、通報スコア算出処理を行い、次のステップ99に処理を進める。以下、図18を参照して、上記ステップ99において行う通報スコア算出処理について説明する。
【0140】
図18において、制御部202は、受領した通知がユーザからの通報(ゲーム装置3からの通報)か否かを判断する(ステップ131)。そして、制御部202は、ユーザからの通報である場合、次のステップ132に処理を進める。一方、制御部202は、ユーザからの通報でない場合、次のステップ137に処理を進める。
【0141】
ステップ132において、制御部202は、通報を行った通報者および通報された被通報者のデバイスIDを取得して、次のステップに処理を進める。例えば、制御部202は、通報したゲーム装置3から送信されたユーザID(すなわち、通報者のユーザID)のアカウント認証を認証サーバ600に問い合わせるとともに、ユーザIDに対応するデバイスIDを要求する。また、制御部202は、認証サーバ600に対して、通報されたユーザを示すユーザID(すなわち、被通報者のユーザID)に対応するデバイスIDを要求する。そして、制御部202は、通報者のユーザIDのアカウント認証を認証サーバ600に確認し、ログイン権利が確認された場合、通報者のユーザIDおよび被通報者のユーザIDにそれぞれ対応するデバイスIDを取得する。
【0142】
次に、制御部202は、通報された通報情報を通報ログ情報データDnに登録し(ステップ133)、次のステップに処理を進める。例えば、図9に示すように、制御部202は、ゲーム装置3から通報された通報情報(通報者のユーザIDおよびデバイスID、被通報者のユーザIDおよびデバイスID、通報理由)を通報ログ情報に追加して、通報ログ情報データDnを更新する。
【0143】
次に、制御部202は、通報された通報情報が既に通報されているものか否かを判断する(ステップ134)。そして、制御部202は、通報された通報情報が既に通報されているものではない場合、次のステップ135に処理を進める。一方、制御部202は、通報された通報情報が既に通報されているものである場合、次のステップ137に処理を進める。第1の例として、制御部202は、通報ログ情報データDnを参照して、受領した通報情報の通報者が当該通報情報の被通報者に対して既に通報している場合、受領した通報情報が既に通報されているものと判断する。第2の例として、通報ログ情報データDnを参照して、受領した通報情報の通報者が当該通報情報の被通報者に対して既に所定回数以上通報している場合、受領した通報情報が既に通報されているものと判断する。第3の例として、通報ログ情報データDnを参照して、受領した通報情報の通報者が当該通報情報の被通報者に対して所定期間以内に通報している場合、受領した通報情報が既に通報されているものと判断する。なお、受領した通報情報が既に通報されているものと判断された場合、当該通報された通報情報を通報ログ情報データDnに登録しなくてもかまわない。
【0144】
ステップ135において、制御部202は、受領した通報の通報理由に応じた通報スコアを取得して、次のステップに処理を進める。例えば、制御部202は、通報スコアテーブルデータDm(図8参照)を参照して、受領した通報の通報理由に応じた通報スコアを取得する。
【0145】
次に、制御部202は、被通報者の通報スコアを算出して(ステップ136)、次のステップ137に処理を進める。例えば、制御部202は、通報スコア情報データDo(図10参照)を参照して、受領した通報における被通報者のデバイスIDに対応する通報スコアに、上記ステップ135で取得した通報スコアを加算する。そして、制御部202は、加算後の通報スコアを用いて、通報スコア情報データDoの当該デバイスIDに対応する通報スコアを更新する。
【0146】
なお、上記ステップ134〜ステップ136の処理では、マッチメイキングサーバ200側で通報者と被通報者との組み合わせが同じ通報について有効/無効を判定し、有効な通報に対して通報スコアの更新を行っている。しかしながら、通報を行うゲーム装置3側で通報を制限してもかまわない。例えば、ゲーム装置3において、上記ステップ134の処理の判断基準において無効と判断されるような、通報者と被通報者との組み合わせが同じ通報については当該通報が作成されないようにしてもかまわない。この場合、マッチメイキングサーバ200側で通報の有効/無効を判定する必要がないため、上記ステップ134の判定処理が不要となる。
【0147】
ステップ137において、受領した通知がログ処理結果による通報(ログ処理サーバ400またはログ処理装置500からの通報)か否かを判断する。そして、制御部202は、ログ処理結果による通報である場合、次のステップ138に処理を進める。一方、制御部202は、ログ処理結果による通報でない場合、当該サブルーチンによる処理を終了する。
【0148】
ステップ138において、制御部202は、ログ処理結果に基づいて通報された被通報者のデバイスIDを取得して、次のステップに処理を進める。例えば、制御部202は、ログ処理サーバ400またはログ処理装置500から通報された被通報者を示すユーザID(すなわち、被通報者のユーザID)に対応するデバイスIDを認証サーバ600に要求する。そして、制御部202は、認証サーバ600から被通報者のユーザIDに対応するデバイスIDを取得する。
【0149】
次に、制御部202は、受領した通報の通報理由に応じた通報スコアを取得して(ステップ139)、次のステップに処理を進める。一例として、制御部202は、通報スコアテーブルデータDmを参照して、受領した通報の通報理由に応じた通報スコアを取得する。他の例として、制御部202は、ユーザからの通報による通報スコアより十分に大きい値をログ処理結果に基づいた通報専用の通報スコアとして予め設定しており、当該設定された通報スコアを取得する。
【0150】
次に、制御部202は、被通報者の通報スコアを算出して(ステップ140)、当該サブルーチンによる処理を終了する。例えば、制御部202は、通報スコア情報データDoを参照して、受領した通報における被通報者のデバイスIDに対応する通報スコアに、上記ステップ139で取得した通報スコアを加算する。そして、制御部202は、加算後の通報スコアを用いて、通報スコア情報データDoの当該デバイスIDに対応する通報スコアを更新する。
【0151】
なお、上記ステップ137〜ステップ140の処理の説明においては、ログ処理サーバ400またはログ処理装置500からの通報に応じて、被通報者の通報スコアがカウントアップされる例を用いたが、当該通報に応じて被通報者の通報スコアが減算または初期化されてもかまわない。この場合、ログ処理サーバ400またはログ処理装置500におけるログ解析において、ユーザが不正な行為を行っていないと判定された場合、当該解析結果を示すデータをログ処理結果としてマッチメイキングサーバ200へ送信する。そして、当該ログ処理結果を受領したマッチメイキングサーバ200は、通報スコア情報データDoを参照して、受領した通報における被通報者のデバイスIDに対応する通報スコアから所定数減算または当該通報スコアを所定値(例えば、0)に初期化して、減算または初期化後の通報スコアを用いて、通報スコア情報データDoの当該デバイスIDに対応する通報スコアを更新する。このように、ログ解析の結果によって、ユーザの通報スコアを減算または初期化してもかまわない。
【0152】
図14に戻り、ステップ99において、制御部202は、通報スコアをカウントアップした最新更新日が所定日数前となっているデバイスIDの通報スコアがあるか否かを判断する。例えば、制御部202は、通報スコア情報データDoに記載されている通報スコアカウントアップ最新更新日を参照して、当該最新更新日が所定日数前(例えば、7日前)になっているデバイスIDの通報スコアの有無を確認する。そして、制御部202は、最新更新日が所定日数前となっているデバイスIDの通報スコアがある場合、次のステップ100に処理を進める。一方、制御部202は、最新更新日が所定日数前となっているデバイスIDの通報スコアがない場合、当該フローチャートによる処理を終了する。
【0153】
ステップ100において、制御部202は、最新更新日が所定日数前となっている通報スコアを初期化して、当該フローチャートによる処理を終了する。例えば、制御部202は、通報スコア情報データDoに記載されている通報スコアカウントアップ最新更新日が所定日数前になっている通報スコアを全て所定値(例えば、0)に初期化し、当該最新更新日を全て初期化した日にして、通報スコア情報データDoを更新する。
【0154】
このように、通信システム1では、ユーザからの通報に基づいて、通信ゲームをプレイする組み合わせが決定されるため、善良なユーザが不正な行為を行う可能性のあるユーザと組み合わせられることを防止することを実現しながら、サーバの処理負荷およびサーバ運用者の作業負荷を低減することができる。また、通信システム1では、通信ゲームにおけるマッチメイキングの際に当該通信ゲームのログを取得するか否かの判断が行われ、当該判断結果に基づいて当該ログが取得されるため、通信ゲームにおけるマッチメイキング状況に応じた効率のよい当該通信ゲームのログ収集が可能となる。
【0155】
なお、上述した説明では、マッチメイキング処理において第1の閾値T1以上か否かによってユーザを2つの群に層別し、同じ群に属するユーザ同士を組み合わせる例を用いたが、ユーザを3つ以上の群に層別してもかまわない。例えば、第1の閾値T1より小さい第4の閾値T4を新たに設定して、通報スコアNSが第4の閾値T4未満の第1の群、通報スコアNSが第4の閾値T4以上で第1の閾値T1未満の第2の群、および通報スコアNSが第1の閾値T1以上の第3の群にユーザを層別し、同じ群に属するユーザ同士を組み合わせる。
【0156】
また、マッチメイキング処理において、ユーザを3つ以上の群に層別する場合、マッチメイキング処理において異なる群に属するユーザ同士を組み合わせてもかまわない。例えば、上述した第1の群、第2の群、および第3の群にユーザを層別する場合、第1の群のユーザを同じ第1の群または第2の群のユーザと組み合わせ、第3の群のユーザを同じ第3の群のユーザまたは第2のユーザと組み合わせる。つまり、マッチメイキング処理において、ある群に属するユーザと当該ある群に分類される通報スコアに対して最も大きな差を有する通報スコアが分類される群を少なくとも除いた群に属するユーザ(典型的には、分類される通報スコアの大きさが近い群(例えば、隣接する群)のユーザ同士)とが組み合わせられる。このような組み合わせであっても、通報スコアのレベルが相対的に大きく異なるユーザ(例えば、第1の群、第2の群、第3の群にユーザを層別する場合の第1の群のユーザと第3の群のユーザ)が組み合わせられることがないため、善良なユーザが不正を行う可能性が高いユーザと組み合わせられることを防止することができる。
【0157】
また、上述した処理では、通報スコアのカウントアップが所定日数前から現時点までないユーザを対象として、当該通報スコアを初期化している。このように、実時間を条件として通報スコアを初期化することによって、ゲーム装置3が売却されたり譲り渡されたりした場合であっても、ユーザが他のユーザに手渡してから所定日数が経過することによって当該ゲーム装置3に設定されている通報スコアが初期化されるため、前のユーザの通報スコアの設定が次のユーザに引き継がれることを防止することができる。このような効果を期待しない場合、他の態様によってユーザの通報スコアを初期化してもかまわない。一例として、通報スコアの対象となっている通信ゲーム(アプリケーション)が所定回数行われる間に通報スコアのカウントアップがないユーザを対象として、当該通報スコアを初期化する。他の例として、通報スコアの対象となっている通信ゲーム(アプリケーション)が実行されている累積時間が所定時間になるまでの間に通報スコアのカウントアップがないユーザを対象として、当該通報スコアを初期化する。このように、実時間だけでなく通信ゲーム(アプリケーション)を行った回数や時間を条件として、ユーザの通報スコアを初期化してもかまわない。
【0158】
また、上述した処理では、ゲーム装置3のユーザが通報する際、通報理由を示す情報がマッチメイキングサーバ200に送信され、当該通報理由に相当する通報スコアがマッチメイキングサーバ200によって設定されるが、送信元側で通報スコアを設定してもかまわない。すなわち、ゲーム装置3のユーザが通報する際、通報理由に相当する通報スコアがゲーム装置3によって設定され、当該通報スコアを示す情報がマッチメイキングサーバ200に送信されてもかまわない。
【0159】
また、上述した処理では、通信ゲームが終了した時点で当該通信ゲームに参加していたゲーム装置3それぞれからゲームログがログ保管サーバ300へ送出されるが、他のタイミングでゲームログが送出されてもかまわない。例えば、ログ取得対象フラグデータDhが示すログ取得対象フラグがオンに設定されている場合、上記ステップ47におけるゲーム処理中において所定の周期で、当該ゲーム処理に関するゲームログがゲーム装置3それぞれからログ保管サーバ300へ送出されてもかまわない。
【0160】
また、上述した説明では、1人のユーザが1台のゲーム装置3を操作する前提でゲーム装置3同士をマッチメイキングする例を用いており、これによってユーザ同士がマッチメイキングされることになる。しなしながら、上記実施例は、複数のユーザが1台のゲーム装置3を操作する環境であっても適用することができる。例えば、複数のユーザが1台のゲーム装置3を操作する環境でユーザ同士をマッチメイキングする場合、デバイスIDの代わりにアカウント認証されたユーザIDだけを用いてマッチメイキングすれば、当該環境であってもユーザ同士のマッチメイキングが可能であることは言うまでもない。
【0161】
また、上述した説明では、ログ取得対象が待機部屋単位で設定されるため、当該待機部屋に属している全てのユーザを対象にしてログ取得であるか否かが設定される。しかしながら、上記ログ取得対象は、待機部屋に属している一部のユーザ(1人または2人以上)に設定してもかまわない。この場合、当該待機部屋を用いた通信ゲームでは、当該通信ゲームに参加した一部のユーザのログを取得することになるが、当該ユーザから取得するログに通信ゲームに参加した全てのユーザのログが含まれているために、同様のログ解析が可能となる。
【0162】
また、上述した説明では情報処理をゲーム装置3およびマッチメイキングサーバ200で行う例を用いたが、上記情報処理における処理ステップの少なくとも一部を他の装置で行ってもかまわない。例えば、ゲーム装置3がさらに他の装置(例えば、別のサーバ、他のゲーム装置、他の携帯端末)と通信可能に構成されている場合、上記情報処理における処理ステップは、さらに当該他の装置が協働することによって実行してもよい。一例として、他の装置において、ゲーム処理における仮想世界の生成や当該仮想世界を用いたゲーム処理が行われ、当該ゲーム処理の結果がゲーム装置3の表示部39に表示されることも考えられる。また、マッチメイキングサーバ200で行われている処理の一部をゲーム装置3や他の装置で行うことも考えられる。このように、上記情報処理における処理ステップの少なくとも一部を他の装置で行うことによって、上述した情報処理と同様の処理が可能となる。また、上述した情報処理は、少なくとも1つの情報処理装置とサーバとにより構成される通信システムに含まれる1つのプロセッサまたは複数のプロセッサ間の協働により実行されることが可能である。また、上記実施形態においては、ゲーム装置3のCPU311やマッチメイキングサーバ200の制御部202が所定のプログラムを実行することによって、上述したフローチャートによる処理が行われたが、ゲーム装置3が備える専用回路やマッチメイキングサーバ200が備える専用回路によって上記処理の一部または全部が行われてもよい。
【0163】
また、上述した情報処理で用いられる処理順序、設定値、判定に用いられる条件等は、単なる一例に過ぎず他の順序、値、条件であっても、本実施例を実現できることは言うまでもない。
【0164】
また、上記通信プログラム(ゲームプログラム)は、外部メモリ45等の外部記憶媒体を通じてゲーム装置3に供給されるだけでなく、有線または無線の通信回線を通じてゲーム装置3に供給されてもよい。また、上記プログラムは、ゲーム装置3内部の不揮発性記憶装置に予め記録されていてもよい。なお、上記プログラムを記憶する情報記憶媒体としては、不揮発性メモリの他に、CD−ROM、DVD、あるいはそれらに類する光学式ディスク状記憶媒体、フレキシブルディスク、ハードディスク、光磁気ディスク、磁気テープ、などでもよい。また、上記プログラムを記憶する情報記憶媒体としては、上記プログラムを記憶する揮発性メモリでもよい。このような記憶媒体は、コンピュータ等が読み取り可能な記録媒体ということができる。例えば、コンピュータ等に、これらの記録媒体のプログラムを読み込ませて実行させることにより、上述で説明した各種機能を提供させることができる。
【0165】
以上、本発明を詳細に説明してきたが、前述の説明はあらゆる点において本発明の例示に過ぎず、その範囲を限定しようとするものではない。本発明の範囲を逸脱することなく種々の改良や変形を行うことができることは言うまでもない。本発明は、特許請求の範囲によってのみその範囲が解釈されるべきであることが理解される。また、当業者は、本発明の具体的な実施形態の記載から、本発明の記載および技術常識に基づいて等価な範囲を実施することができることが理解される。また、本明細書において使用される用語は、特に言及しない限り、当該分野で通常用いられる意味で用いられることが理解されるべきである。したがって、他に定義されない限り、本明細書中で使用される全ての専門用語および技術用語は、本発明の属する分野の当業者によって一般的に理解されるのと同じ意味を有する。矛盾する場合、本明細書(定義を含めて)が優先する。
【産業上の利用可能性】
【0166】
本発明に係る通信システム、通信プログラム、情報処理装置、サーバ、および通信方法は、新規な通信システム、通信プログラム、情報処理装置、サーバ、および通信方法を提供することができ、複数の装置間で所定の情報処理等を行う通信システム、通信プログラム、情報処理装置、サーバ、および通信方法等として有用である。
【符号の説明】
【0167】
1…通信システム
3…ゲーム装置
31…情報処理部
311…CPU
312…GPU
313…VRAM
32…メインメモリ
33…外部メモリI/F
35…データ保存用内部メモリ
36…無線通信モジュール
37…ローカル通信モジュール
38…入力部
39…表示部
100…ネットワーク
200…マッチメイキングサーバ
201…通信部
202…制御部
203…記憶部
300…ログ保管サーバ
400…ログ処理サーバ
500…ログ処理装置
600…認証サーバ

【特許請求の範囲】
【請求項1】
サーバと当該サーバと通信可能な複数の情報処理装置とを少なくとも含む通信システムであって、
前記サーバは、
前記複数の情報処理装置の間で所定のアプリケーションを実行する際の、当該情報処理装置の組み合わせを設定するマッチメイキング手段と、
前記マッチメイキング手段が前記アプリケーションを実行する前記情報処理装置の組み合わせを設定する際、所定の条件に基づいて当該アプリケーションが実行されたログを取得するか否かを判定するログ取得判定手段とを備え、
前記情報処理装置は、
前記マッチメイキング手段によって組み合わせられた他の情報処理装置との間で前記アプリケーションを実行する処理実行手段と、
前記ログ取得判定手段がログを取得する判定をした場合、当該判定の対象となったアプリケーションが実行されたログを所定の装置へ送出するログ送出手段とをそれぞれ備える、通信システム。
【請求項2】
前記ログ送出手段は、前記アプリケーションを実行した自機のログとともに、当該自機との間で当該アプリケーションを実行した他の情報処理装置のログを送出する、請求項1に記載の通信システム。
【請求項3】
前記ログ送出手段がそれぞれ送出したログを取得するログ取得手段と、
前記ログ取得手段が取得したログを解析するログ解析手段とを備え、
第1の情報処理装置と第2の情報処理装置との間で実行するアプリケーションがログを取得する対象となった場合、
前記第1の情報処理装置の前記ログ送出手段は、前記アプリケーションを実行した当該第1の情報処理装置のログおよび当該アプリケーションを実行した前記第2の情報処理装置のログを前記ログ取得手段へ送出し、
前記第2の情報処理装置の前記ログ送出手段は、前記アプリケーションを実行した当該第2の情報処理装置のログおよび当該アプリケーションを実行した前記第1の情報処理装置のログを前記ログ取得手段へ送出し、
前記ログ解析手段は、少なくとも、前記第1の情報処理装置の前記ログ送出手段から取得した前記第1の情報処理装置のログと前記第2の情報処理装置の前記ログ送出手段から取得した前記第1の情報処理装置のログとの間の整合性を確認する、請求項2に記載の通信システム。
【請求項4】
前記ログ送出手段は、前記判定の対象となったアプリケーションの実行が開始される際に当該アプリケーションの実行の開始を示す情報をさらに送出する、請求項1乃至3のいずれか1つに記載の通信システム。
【請求項5】
前記サーバは、前記アプリケーションを実行した情報処理装置毎に当該アプリケーションの実行に関する評価を管理する評価管理手段を、さらに備え、
前記ログ取得判定手段は、前記アプリケーションを実行するために組み合わせられた情報処理装置毎の評価に基づいて、当該アプリケーションを実行したログを取得するか否かを判定する、請求項1乃至4のいずれか1つに記載の通信システム。
【請求項6】
前記情報処理装置は、他の情報処理装置における前記アプリケーションの実行に関する評価を前記サーバへ通知する通知手段をそれぞれ備え、
前記評価管理手段は、前記通知手段からの通知された評価に基づいて、当該通知された他の情報処理装置に関する評価を更新する、請求項5に記載の通信システム。
【請求項7】
前記通知手段は、前記マッチメイキング手段によって組み合わせられた他の情報処理装置を対象として、前記評価を通知する、請求項6に記載の通信システム。
【請求項8】
前記通知手段は、前記マッチメイキング手段によって組み合わせられた他の情報処理装置を対象として、アプリケーションが実行された後に当該アプリケーションの実行に関する評価を通知する、請求項7に記載の通信システム。
【請求項9】
前記マッチメイキング手段は、前記評価に対して所定の条件を満たしている情報処理装置同士を組み合わせる、請求項5乃至8のいずれか1つに記載の通信システム。
【請求項10】
前記評価管理手段は、前記通知された評価毎に、当該評価の対象となっている情報処理装置の通知スコアを累積する通知スコア算出手段を、さらに備え、
前記マッチメイキング手段は、前記累積された通知スコアが第1の所定値以上の情報処理装置同士を組み合わせる、または前記累積された通知スコアが第1の所定値未満の情報処理装置同士を組み合わせ、
前記ログ取得判定手段は、前記アプリケーションを実行するために組み合わせられた少なくとも1つの情報処理装置の通知スコアが第2の所定値以上の場合、当該アプリケーションの実行を対象として所定の条件に基づいて当該アプリケーションが実行されたログを取得するか否かを判定する、請求項6乃至8のいずれか1つに記載の通信システム。
【請求項11】
サーバと当該サーバと通信可能な複数の情報処理装置とを少なくとも含む通信システムに含まれるコンピュータで実行される通信プログラムであって、
前記コンピュータを、
前記複数の情報処理装置の間で所定のアプリケーションを実行する際の、当該情報処理装置の組み合わせを設定するマッチメイキング手段と、
前記マッチメイキング手段が前記アプリケーションを実行する前記情報処理装置の組み合わせを設定する際、所定の条件に基づいて当該アプリケーションが実行されたログを取得するか否かを判定するログ取得判定手段と、
前記ログ取得判定手段がログを取得する判定をした場合、当該判定の対象となったアプリケーションが実行されたログを、当該アプリケーションを実行する情報処理装置から送出させるログ送出指示手段として機能させる、通信プログラム。
【請求項12】
少なくともサーバと通信可能な情報処理装置であって、
複数の情報処理装置との間で所定のアプリケーションを実行する際の、前記サーバから指示された他の情報処理装置の組み合わせに基づいて、当該他の情報処理装置との間で当該アプリケーションを実行する処理実行手段と、
前記組み合わせを設定する際に所定の条件に基づいてアプリケーションが実行されたログを取得するか否かを前記サーバにおいて判定された結果を用いて、前記サーバがログを取得する判定をした場合、当該判定の対象となったアプリケーションが実行されたログを所定の装置へ送出するログ送出手段とを備える、情報処理装置。
【請求項13】
少なくとも複数の情報処理装置と通信可能なサーバであって、
前記複数の情報処理装置の間で所定のアプリケーションを実行する際の、当該情報処理装置の組み合わせを設定するマッチメイキング手段と、
前記マッチメイキング手段が前記アプリケーションを実行する前記情報処理装置の組み合わせを設定する際、所定の条件に基づいて当該アプリケーションが実行されたログを取得するか否かを判定するログ取得判定手段と、
前記ログ取得判定手段がログを取得する判定をした場合、当該判定の対象となったアプリケーションが実行されたログを、当該アプリケーションを実行する情報処理装置から送出させるログ送出指示手段とを備える、サーバ。
【請求項14】
サーバと当該サーバと通信可能な複数の情報処理装置とを少なくとも含む通信システムに含まれる1つのプロセッサまたは複数のプロセッサ間の協働により実行される通信方法であって、
前記複数の情報処理装置の間で所定のアプリケーションを実行する際の、当該情報処理装置の組み合わせを設定するマッチメイキングステップと、
前記マッチメイキングステップにおいて前記アプリケーションを実行する前記情報処理装置の組み合わせが設定される際、所定の条件に基づいて当該アプリケーションが実行されたログを取得するか否かを判定するログ取得判定ステップと、
前記マッチメイキングステップにおいて組み合わせられた他の情報処理装置との間で前記アプリケーションを実行する処理実行ステップと、
前記ログ取得判定ステップにおいてログを取得する判定された場合、当該判定の対象となったアプリケーションが実行されたログを所定の装置へ送出するログ送出ステップとを含む、通信方法。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate

【図15】
image rotate

【図16】
image rotate

【図17】
image rotate

【図18】
image rotate