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

Description

本発明は、通信システム、通信プログラム、情報処理装置、サーバ、および通信方法に関し、特に例えば、通信相手を組み合わせる処理を制御する通信システム、通信プログラム、情報処理装置、サーバ、および通信方法に関する。

従来、ネットワークを介して、他のユーザと対戦等の通信ゲームを行うゲームシステムが知られている。このようなゲームシステムでは、見ず知らずのユーザと通信ゲームを行うことも可能であるため、不正を行う一部のユーザによって、善良なユーザが通信ゲームで不快な思いをしないような対策が考えられている（例えば、特許文献１参照）。例えば、上記特許文献１で開示されたゲームシステムは、通信ゲームにおいて各ユーザが所有するアイテムの情報に基づいて、当該通信ゲームで不正が行われたか否かを判定する。そして、不正を行ったユーザ同士を当該通信ゲームで組み合わせてプレイするようにして、不正の可能性のあるユーザが他の善良なユーザと上記通信ゲームで組み合わせられることがないようにしている。

特開２００６−２９６７６９号公報

しかしながら、上記特許文献１で開示されたゲームシステムは、通信ゲームに参加する全てのユーザのアイテム情報を検証して不正が行われた否かを判定する必要があるため、サーバの処理負荷およびサーバ運用者の作業負荷が大きくなってしまうという問題がある。

それ故に、本発明の主たる目的は、新規な通信システム、通信プログラム、情報処理装置、サーバ、および通信方法を提供することである。また、本発明の他の目的は、サーバの処理負荷およびサーバ運用者の作業負荷を低減しつつ、ユーザの監視が可能な通信システム、通信プログラム、情報処理装置、サーバ、および通信方法を提供することである。

上記目的を達成するために、本発明は例えば以下のような構成を採用し得る。なお、特許請求の範囲の記載を解釈する際に、特許請求の範囲の記載によってのみその範囲が解釈されるべきであることが理解され、特許請求の範囲の記載と本欄の記載とが矛盾する場合には、特許請求の範囲の記載が優先する。

本発明の通信システムの一構成例は、サーバと当該サーバと通信可能な複数の情報処理装置とを少なくとも含む。サーバは、マッチメイキング手段およびログ取得判定手段を備える。マッチメイキング手段は、複数の情報処理装置の間で所定のアプリケーションを実行する際の、当該情報処理装置の組み合わせを設定する。ログ取得判定手段は、マッチメイキング手段がアプリケーションを実行する情報処理装置の組み合わせを設定する際、所定の条件に基づいて当該アプリケーションが実行されたログを取得するか否かを判定する。情報処理装置は、処理実行手段およびログ送出手段をそれぞれ備える。処理実行手段は、マッチメイキング手段によって組み合わせられた他の情報処理装置との間でアプリケーションを実行する。ログ送出手段は、ログ取得判定手段がログを取得する判定をした場合、当該判定の対象となったアプリケーションが実行されたログを所定の装置へ送出する。

上記によれば、情報処理装置の組み合わせ（ユーザの組み合わせ）を設定する際に、所定の条件に基づいてアプリケーションが実行されたログを取得するか否かが判定されるため、適切なログの取得が可能となり、サーバの処理負荷およびサーバ運用者の作業負荷を低減しつつ、取得したログを用いてユーザの監視が可能となる。

また、上記ログ送出手段は、アプリケーションを実行した自機のログとともに、当該自機との間で当該アプリケーションを実行した他の情報処理装置のログを送出してもよい。

上記によれば、自機のログだけでなく自機とともにアプリケーションを実行した他の情報処理装置のログも送出されるため、ある装置のログを複数取得することが可能となる。

また、上記通信システムは、ログ取得手段およびログ解析手段を備えてもよい。ログ取得手段は、ログ送出手段がそれぞれ送出したログを取得する。ログ解析手段は、ログ取得手段が取得したログを解析する。第１の情報処理装置と第２の情報処理装置との間で実行するアプリケーションがログを取得する対象となった場合、第１の情報処理装置のログ送出手段は、アプリケーションを実行した当該第１の情報処理装置のログおよび当該アプリケーションを実行した第２の情報処理装置のログをログ取得手段へ送出してもよい。第２の情報処理装置のログ送出手段は、アプリケーションを実行した当該第２の情報処理装置のログおよび当該アプリケーションを実行した第１の情報処理装置のログをログ取得手段へ送出してもよい。この場合、上記ログ解析手段は、少なくとも、第１の情報処理装置のログ送出手段から取得した第１の情報処理装置のログと第２の情報処理装置のログ送出手段から取得した第１の情報処理装置のログとの間の整合性を確認してもよい。

上記によれば、第１の情報処理装置が自機のログを改ざんして送出したとしても、第２の情報処理装置から送出される第１の情報処理装置のログとの整合性を確認することができるため、改ざんして送出されたログを抽出することができる。

また、上記ログ送出手段は、判定の対象となったアプリケーションの実行が開始される際に当該アプリケーションの実行の開始を示す情報をさらに送出してもよい。

上記によれば、アプリケーションの実行を途中で止めた情報処理装置を検出することができる。

また、上記サーバは、評価管理手段を、さらに備えてもよい。評価管理手段は、アプリケーションを実行した情報処理装置毎に当該アプリケーションの実行に関する評価を管理する。この場合、上記ログ取得判定手段は、アプリケーションを実行するために組み合わせられた情報処理装置毎の評価に基づいて、当該アプリケーションを実行したログを取得するか否かを判定してもよい。

上記によれば、アプリケーションの実行に関する評価に基づいてログの取得要否が判断されるため、情報処理装置の評価に応じた適切なログを取得することができる。

また、上記情報処理装置は、通知手段をそれぞれ備えてもよい。通知手段は、他の情報処理装置におけるアプリケーションの実行に関する評価をサーバへ通知する。この場合、上記評価管理手段は、通知手段からの通知された評価に基づいて、当該通知された他の情報処理装置に関する評価を更新してもよい。

上記によれば、情報処理装置からの通知に基づいて、他の情報処理装置の評価が設定されるため、当該評価を行うためのサーバの処理負荷およびサーバ運用者の作業負荷を低減することができる。

また、上記通知手段は、マッチメイキング手段によって組み合わせられた他の情報処理装置を対象として、評価を通知してもよい。

上記によれば、実際に組み合わせられてアプリケーションを実行した相手の情報処理装置が評価の対象となるため、通知元の情報処理装置から適切な評価を得ることができる。

また、上記通知手段は、マッチメイキング手段によって組み合わせられた他の情報処理装置を対象として、アプリケーションが実行された後に当該アプリケーションの実行に関する評価を通知してもよい。

上記によれば、実際にアプリケーションが実行された後に当該アプリケーションの実行に関する評価が通知されるため、通知元の情報処理装置から適切な評価を得ることができる。

また、上記マッチメイキング手段は、評価に対して所定の条件を満たしている情報処理装置同士を組み合わせてもよい。

上記によれば、情報処理装置からの評価が所定の条件を満たしているもの同士がマッチメイキングされるため、情報処理装置の組み合わせを適切に設定することができる。

また、上記評価管理手段は、通知スコア算出手段を、さらに備えてもよい。通知スコア算出手段は、通知された評価毎に、当該評価の対象となっている情報処理装置の通知スコアを累積する。この場合、上記マッチメイキング手段は、累積された通知スコアが第１の所定値以上の情報処理装置同士を組み合わせる、または累積された通知スコアが第１の所定値未満の情報処理装置同士を組み合わせてもよい。上記ログ取得判定手段は、アプリケーションを実行するために組み合わせられた少なくとも１つの情報処理装置の通知スコアが第２の所定値以上の場合、当該アプリケーションの実行を対象として所定の条件に基づいて当該アプリケーションが実行されたログを取得するか否かを判定してもよい。

上記によれば、より多くのユーザからの評価を累積することによって、評価の信頼度を上げることができ、より適切なログ取得要否の判断が可能となる。また、評価に基づいて通報スコアが算出されるため、情報処理装置の評価を適切に管理することができる。

また、本発明は、上記各手段としてコンピュータを機能させる通信プログラム、上記各手段の一部を備える情報処理装置、上記各手段の一部を備えるサーバ、上記各手段で行われる動作を含む通信方法の形態で実施されてもよい。上記各手段を備える情報処理装置および情報処理システムや上記各手段で行われる動作を含む情報処理方法の形態で実施されてもよい。

本発明によれば、情報処理装置の組み合わせを設定する際に、所定の条件に基づいてアプリケーションが実行されたログを取得するか否かが判定されるため、適切なログの取得が可能となり、サーバの処理負荷およびサーバ運用者の作業負荷を低減しつつ、取得したログを用いてユーザの監視が可能となる。

本発明の一実施形態に係る通信システム１を説明するための外観図 図１のゲーム装置３の構成の一例を示すブロック図 図１のマッチメイキングサーバ２００の構成の一例を示すブロック図 通信システム１において、ユーザが通信ゲームに関する通報情報を通報する際の装置間のやりとりの一例を時間軸に沿って表現した図 通信システム１において、通信ゲームのログを送信する際の装置間のやりとりの一例を時間軸に沿って表現した図 ゲーム装置３のメインメモリ３２に記憶される主なデータおよびプログラムの一例を示す図 マッチメイキングサーバ２００の記憶部２０３に記憶される主なデータおよびプログラムの一例を示す図 記憶部２０３に記憶される通報スコアテーブルデータＤｍの一例を示す図 記憶部２０３に記憶される通報ログ情報データＤｎの一例を示す図 記憶部２０３に記憶される通報スコア情報データＤｏの一例を示す図 ゲーム装置３において実行される処理の一例を示すフローチャート 図１１におけるステップ４４のゲーム参加処理の一例を示すサブルーチン 図１１におけるステップ５２の通報処理の一例を示すサブルーチン マッチメイキングサーバ２００において実行される処理の一例を示すフローチャート 図１４におけるステップ９２の待機リスト送信処理の一例を示すサブルーチン 図１４におけるステップ９４の待機部屋作成処理の一例を示すサブルーチン 図１４におけるステップ９６の待機部屋参加処理の一例を示すサブルーチン 図１４におけるステップ９８の通報スコア算出処理の一例を示すサブルーチン

図１を参照して、本発明の一実施形態に係る通信システムについて説明する。図１に示すように、当該通信システムの一例である通信システム１は、複数のゲーム装置３、マッチメイキングサーバ２００、ログ保管サーバ３００、ログ処理サーバ４００、ログ処理装置５００、および認証サーバ６００が、ネットワーク１００を介して接続されて構築される。

ゲーム装置３は、無線または有線通信を用いて、ネットワーク１００に接続可能に構成されている。例えば、ゲーム装置３は、ピアツーピア（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）通信方式やクライアント−サーバ方式等を用いて、他のゲーム装置３と組み合わせられて所定のアプリケーション（例えば、通信ゲーム）の実行が可能である。また、ゲーム装置３は、ネットワーク１００を介して、マッチメイキングサーバ２００およびログ保管サーバ３００と接続を確立することによって、マッチメイキングサーバ２００およびログ保管サーバ３００との通信がそれぞれ可能となる。例えば、ゲーム装置３は、交換可能なメモリカードや光ディスク等の記録媒体内に記憶され、または、サーバや他のゲーム装置から受信した通信プログラムの一例となるプログラム（例えば、ゲームプログラム）を実行可能である。ゲーム装置３は、携帯ゲーム装置であってもよく、一般的なパーソナルコンピュータ、携帯電話機、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）等のデバイスであってもかまわない。また、ゲーム装置３は、上記プログラムを記録した光ディスクと、光ディスクのプログラムを実行してゲーム画面をモニタに表示出力させるためのコンピュータを搭載したゲーム装置本体と、表示画面に表示されたオブジェクト等を操作するために必要な操作情報をゲーム装置本体に与えるためのコントローラとを備えた、据置型のゲームシステムであってもよい。

ログ保管サーバ３００は、複数のゲーム装置３が通信して所定の処理（例えば、通信ゲーム）を行った後に当該ゲーム装置３からそれぞれ送信される当該処理のログを受信して格納する。なお、上記ログを取得する対象であるか否かはマッチメイキングサーバ２００によって決定され、当該対象となったゲーム装置３へ通知される。そして、ログ取得対象である場合、複数のゲーム装置３が通信して上記所定の処理を行った後に当該ゲーム装置３からそれぞれログ保管サーバ３００に当該処理のログが送信される。

ログ処理サーバ４００は、ログ保管サーバ３００に格納されたログを自動的に解析して、当該ログによって示されている処理において、ユーザが不正な行為を行っているか否かを判断する。そして、ログ処理サーバ４００は、上記処理において不正な行為が行われている場合、当該行為を行ったユーザに対する通報理由を選出し、当該ユーザのユーザＩＤおよび当該通報理由をマッチメイキングサーバ２００へ送信する。

ログ処理装置５００は、ログ保管サーバ３００に格納されたログを実機（例えば、ゲーム装置３と同様の能力を有する装置）を用いて解析（例えば、エミュレーション）して、当該ログによって示されている処理において、ユーザが不正な行為を行っているか否かを判断する。そして、ログ処理サーバ４００は、上記処理において不正な行為が行われている場合、当該行為を行ったユーザに対する通報理由を選出し、当該ユーザのユーザＩＤおよび当該通報理由をマッチメイキングサーバ２００へ送信する。

認証サーバ６００は、ゲーム装置３を用いてネットワーク１００にログインされた場合、当該ログインしようとしているユーザが正規のユーザか否かを判別するために利用される。例えば、認証サーバ６００は、ネットワーク１００の利用者のユーザＩＤおよびパスワードとともに、ログインに用いられたゲーム装置３のデバイスＩＤを管理しており、当該データを用いてログインしたユーザに対して認証を行う。また、認証サーバ６００は、マッチメイキングサーバ２００との間で所定のプロトコルを用いて通信を行い、マッチメイキングサーバ２００からユーザ認証やデバイスＩＤの確認が要求された場合、当該要求に対する回答を行う。

次に、図２を参照して、ゲーム装置３について説明する。なお、図２は、ゲーム装置３の構成の一例を示すブロック図である。

図２において、ゲーム装置３には、情報処理部３１、メインメモリ３２、外部メモリインターフェイス（外部メモリＩ／Ｆ）３３、データ保存用内部メモリ３５、無線通信モジュール３６、ローカル通信モジュール３７、入力部３８、および表示部３９等を備えている。

情報処理部３１は、所定のプログラムを実行するためのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３１１、画像処理を行うＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３１２等を含む情報処理手段である。本実施形態では、所定のプログラムがゲーム装置３内のメモリ（例えば外部メモリＩ／Ｆ３３に接続された外部メモリ４５やデータ保存用内部メモリ３５）に記憶されている。情報処理部３１のＣＰＵ３１１は、当該所定のプログラムを実行することによって、後述する通信処理やゲーム処理を実行する。なお、情報処理部３１のＣＰＵ３１１によって実行されるプログラムは、他の機器との通信によって他の機器から取得されてもよい。また、情報処理部３１は、ＶＲＡＭ（Ｖｉｄｅｏ ＲＡＭ）３１３を含む。情報処理部３１のＧＰＵ３１２は、情報処理部３１のＣＰＵ３１１からの命令に応じて画像を生成し、ＶＲＡＭ３１３に描画する。そして、情報処理部３１のＧＰＵ３１２は、ＶＲＡＭ３１３に描画された画像を表示部３９に出力し、表示部３９に当該画像が表示される。

情報処理部３１には、メインメモリ３２、外部メモリＩ／Ｆ３３、およびデータ保存用内部メモリ３５が接続される。外部メモリＩ／Ｆ３３は、外部メモリ４５を着脱自在に接続するためのインターフェイスである。

メインメモリ３２は、情報処理部３１（ＣＰＵ３１１）のワーク領域やバッファ領域として用いられる揮発性の記憶手段である。すなわち、メインメモリ３２は、画像処理やゲーム処理で用いられる各種データを一時的に記憶したり、外部（外部メモリ４５や他の機器等）から取得されるプログラムを一時的に記憶したりする。

外部メモリ４５は、情報処理部３１によって実行されるプログラムを記憶するための不揮発性の記憶手段である。外部メモリ４５は、例えば読み取り専用の半導体メモリで構成される。外部メモリ４５が外部メモリＩ／Ｆ３３に接続されると、情報処理部３１は外部メモリ４５に記憶されたプログラムを読み込むことができる。情報処理部３１が読み込んだプログラムを実行することにより、所定の処理が行われる。

データ保存用内部メモリ３５は、読み書き可能な不揮発性メモリ（例えばＮＡＮＤ型フラッシュメモリ）で構成され、所定のデータを格納するために用いられる。例えば、データ保存用内部メモリ３５には、無線通信モジュール３６を介した無線通信によってダウンロードされたデータやプログラムが格納される。

無線通信モジュール３６は、例えばＩＥＥＥ８０２．１１．ｂ／ｇの規格に準拠した方式により、無線ＬＡＮに接続する機能を有する。また、ローカル通信モジュール３７は、所定の通信方式（例えば赤外線通信）により同種のゲーム装置との間で無線通信を行う機能を有する。無線通信モジュール３６およびローカル通信モジュール３７は、情報処理部３１に接続される。情報処理部３１は、無線通信モジュール３６を用いてインターネットを介して他の機器との間でデータを送受信したり、ローカル通信モジュール３７を用いて同種の他のゲーム装置との間でデータを送受信したりすることができる。

入力部３８は、操作ボタン、タッチパネル、および動きセンサ等の少なくとも１つからなり、情報処理部３１に接続される。入力部３８から情報処理部３１へは、入力部３８に対する入力状況を示す操作データが出力される。情報処理部３１は、入力部３８から操作データを取得することによって、入力部３８に対する入力に応じた処理を実行する。

表示部３９は、情報処理部３１に接続される。表示部３９は、情報処理部３１（ＧＰＵ３１２）の指示にしたがって画像を表示する。

次に、図３を参照して、マッチメイキングサーバ２００について説明する。なお、図３は、マッチメイキングサーバ２００の構成の一例を示すブロック図である。

マッチメイキングサーバ２００は、通信部２０１、制御部２０２、および記憶部２０３を有している。通信部２０１は、通信パケットの送受信を行うことで、ネットワーク１００を介してゲーム装置３、ログ処理サーバ４００、ログ処理装置５００、および認証サーバ６００等と通信を行う。制御部２０２は、複数の装置が通信して所定の処理（例えば、通信ゲーム）を行う際、当該処理を行うゲーム装置３の組み合わせ（マッチメイキング）を決定する処理、ゲーム装置３のユーザ毎の通報スコアを管理する処理、上記所定の処理後に当該処理のログを取得するか否かを決定する処理のほか、通信部２０１を介してゲーム装置３、ログ処理サーバ４００、ログ処理装置５００、および認証サーバ６００等との通信リンクを確立し、ネットワーク１００におけるデータ搬送制御や経路選択を行う。記憶部２０３は、制御部２０２で実行されるプログラム、ゲーム装置３の組み合わせを決定する処理に必要な各種データ、ユーザから通報された通報情報を示すデータ、ユーザ毎の通報スコアを示すデータ、ゲーム装置３、ログ処理サーバ４００、ログ処理装置５００、および認証サーバ６００との通信に必要な各種データ等が記憶される。なお、マッチメイキングサーバ２００は、単一のサーバマシンから構成されてもいいし、複数のサーバマシンによって構成されてもよい。また、図１の説明では、マッチメイキングサーバ２００、ログ保管サーバ３００、ログ処理サーバ４００、ログ処理装置５００、および認証サーバ６００を、それぞれ別の装置で構成したが、これらの機能の少なくとも２つが単一の装置（例えば、単一のサーバマシン）で構成されてもかまわない。

次に、ゲーム装置３やマッチメイキングサーバ２００が行う具体的な処理を説明する前に、図４および図５を用いて通信システム１において行われる処理の概要について説明する。なお、図４は、通信システム１において、ユーザが通信ゲームに関する通報情報を通報する際の装置間のやりとりの一例を時間軸に沿って表現した図である。図５は、通信システム１において、通信ゲームのログを送信する際の装置間のやりとりの一例を時間軸に沿って表現した図である。なお、図４および図５を用いて説明する通信ゲーム例では、複数のユーザが通信して１つの通信ゲームを行う際、あるユーザが待機部屋を作成して他のユーザの入室を待ち、当該待機部屋に他のユーザが入室してメンバーが揃った場合に当該通信ゲームが当該メンバー間で開始される例を用いる。なお、以下の説明では、複数のゲーム装置３の間で実行するアプリケーションの一例として通信ゲームを用いているが、短い文章をリアルタイムにやり取りしてコミュニケーションを行うチャット等、複数のゲーム装置３の間で他のアプリケーションを実行してもかまわない。

図４において、所定の通信ゲームを行う際、ゲーム装置３のユーザは、マッチメイキングサーバ２００に対して他のユーザとの組み合わせを設定するためのマッチメイキング要求を行う。マッチメイキング要求を行う際、ゲーム装置３は、当該マッチメイキング要求およびマッチメイキング要求するゲームに関する情報（ゲームの種類、モード、ゲームレベル等を示す情報）とともに、ゲーム装置３のユーザを示すユーザＩＤをマッチメイキングサーバ２００へ送信する。ここで、ユーザＩＤは、ユーザ識別が可能となるユニークな符号であればよく、例えばユーザ識別のための標識となる文字列であるアカウントＩＤでもかまわない。

マッチメイキングサーバ２００は、マッチメイキング要求したユーザの通報スコアを確認する。そして、マッチメイキングサーバ２００は、マッチメイキング要求されたゲームに対して既に作成されている待機部屋のうち、通報スコアに応じた待機部屋を選出し、当該待機部屋で待機しているユーザを示す待機リストをマッチメイキング要求元へ送信する。例えば、マッチメイキングサーバ２００は、通報スコアが第１の閾値Ｔ１未満の場合に通常の待機部屋（通常ギャザリング）を選出対象とし、通報スコアが第１の閾値Ｔ１以上の場合に隔離された待機部屋（専用ギャザリング）を選出対象とする。

次に、マッチメイキング要求したゲーム装置３のユーザは、受信した待機リストに基づいた待機部屋の状況を見て、新たに待機部屋を作成する場合、マッチメイキングサーバ２００に対して待機部屋作成要求を行う。待機部屋作成要求を行う際、ゲーム装置３は、当該待機部屋作成要求とともに、ユーザＩＤをマッチメイキングサーバ２００へ送信する。

マッチメイキングサーバ２００は、待機部屋作成要求したユーザの通報スコアを確認する。そして、マッチメイキングサーバ２００は、要求されたゲームに対して通報スコアに応じた待機部屋を作成して新たに登録する。例えば、マッチメイキングサーバ２００は、通報スコアが第１の閾値Ｔ１未満の場合に通常の待機部屋を新たに登録し、通報スコアが第１の閾値Ｔ１以上の場合に隔離された待機部屋を新たに登録する。

一方、上記所定の通信ゲームを行う他のゲーム装置３のユーザも、マッチメイキングサーバ２００に対して他のユーザとの組み合わせを設定するためのマッチメイキング要求を行う。このマッチメイキング要求を行う場合も、ゲーム装置３は、当該マッチメイキング要求およびマッチメイキング要求するゲームに関する情報とともに、ゲーム装置３のユーザを示すユーザＩＤをマッチメイキングサーバ２００へ送信する。そして、マッチメイキングサーバ２００は、マッチメイキング要求したユーザの通報スコアに応じた待機部屋を選出し、当該待機部屋で待機しているユーザを示す待機リストをマッチメイキング要求元へ送信する。

次に、マッチメイキング要求したゲーム装置３のユーザは、受信した待機リストに基づいた待機部屋の状況を見て、希望する待機部屋に入る場合、マッチメイキングサーバ２００に対して待機部屋参加要求を行う。待機部屋参加要求を行う際、ゲーム装置３は、当該待機部屋参加要求とともに、ユーザＩＤをマッチメイキングサーバ２００へ送信する。

マッチメイキングサーバ２００は、参加要求された待機部屋に要求元のユーザを登録する。そして、マッチメイキングサーバ２００は、新たにユーザが登録された待機部屋に参加している全ユーザに対して、当該全ユーザを示す参加者情報（例えば、参加者全員のユーザＩＤ）を送信する。なお、新たに待機部屋に登録されたユーザに対しては、当該待機部屋に登録されている当該ユーザ以外の参加者を示す参加者情報を送信してもよい。また、既に待機部屋に登録されていたユーザに対しては、新たに当該待機部屋に登録された参加者のみを示す参加者情報を送信してもよい。

次に、待機部屋に参加しているユーザは、所定の通信方式（例えば、ピアツーピア通信方式）を用いて互いに通信を行うことによって、通信ゲームを開始する。そして、通信ゲーム終了後、当該通信ゲームを行ったユーザに対して通報の機会が与えられる。ここで、上記通報は、通信ゲームを行った相手ユーザについて行うことができ、当該通信ゲームにおける相手の評価（不正行為の有無、マナーがよい、悪い等）を行うものである。ゲーム装置３のユーザが通報を行った場合、当該通報を行った相手のユーザＩＤと当該通報の理由とを示す情報がマッチメイキングサーバ２００へ送信される。

ユーザからの通報を受け取ったマッチメイキングサーバ２００は、当該通報毎に当該通報に対する通報スコアを算出する。なお、後述により明らかとなるが、通報スコアは、マッチメイキングサーバ２００において通報理由毎に予め定められている。そして、マッチメイキングサーバ２００は、通報されたユーザに対して既に設定されている通報スコアに、算出された通報スコアを加減算し、加減算された通報スコアを用いて当該ユーザの通報スコアを更新する。

次に、図５を参照して、通信ゲームのログを送信する際の動作の一例について説明する。図５において、マッチメイキングサーバ２００は、ゲーム装置３から待機部屋作成要求を受信した際、当該要求元を通信ゲームログの取得対象とするか否かを判定する。そして、マッチメイキングサーバ２００は、上記取得対象とする場合、ログ取得通知を上記要求元のユーザへ送信する。

また、マッチメイキングサーバ２００は、ゲーム装置３から待機部屋参加要求を受信した際、当該要求元を通信ゲームログの取得対象とするか否かを判定する。第１の例として、参加要求された待機部屋に上記取得対象となったユーザが含まれている場合、当該参加要求元のユーザも通信ゲームログの取得対象とし、ログ取得通知を当該参加要求元のユーザへ送信する。第２の例として、参加要求された待機部屋に既に参加しているユーザは上記取得対象ではないが、新たに参加要求したユーザを通信ゲームログの取得対象とする場合、当該待機部屋の参加者を全て通信ゲームログの取得対象とし、ログ取得通知を当該待機部屋の全ての参加者へ送信する。

ログ取得通知を受信したゲーム装置３は、通信ゲームを行った後、当該通信ゲームのログをログ保管サーバ３００に送信する。ここで、ゲーム装置３がログ保管サーバ３００に送信するログは、アプリケーション（通信ゲーム）で発生したイベント（動作、事象、操作等）が記録されたイベントデータや、通信ゲームにおけるプレイを再現するゴーストデータ等がある。なお、ログ取得通知を受信したゲーム装置３は、当該ゲーム装置３のログだけでなく、通信ゲームを行った相手ユーザがプレイしているログも同時に送信してもよい。また、上述から明らかなように、ログ取得対象となった通信ゲームは、当該通信ゲームをプレイしている全ユーザがログ取得通知を受け取ることになる。この場合、ログ取得対象となった通信ゲームをプレイしている全ユーザが、相手ユーザのログを含めて当該通信ゲームのログをログ保管サーバ３００に送信することになる。

ログ処理サーバ４００および／またはログ処理装置５００は、ログ保管サーバ３００に保管された通信ゲームの各ログを解析し、解析対象となった通信ゲームにおいて不正が行われていないか否かを判断する。そして、ログ処理サーバ４００および／またはログ処理装置５００は、通信ゲームにおいて不正が行われている場合、マッチメイキングサーバ２００へ通報が行われる。例えば、上記通報において、ログ処理サーバ４００および／またはログ処理装置５００は、不正を行ったユーザのユーザＩＤと当該通報の理由とを示す情報を、マッチメイキングサーバ２００へ送信する。

ログ処理サーバ４００が通信ゲームのログを解析する場合、当該ログによって示されている処理において当該通信ゲームであり得ないプレイ（例えば、あり得ない数のアイテムを使用している、移動できない空間を移動しているなど）が行われているか否かなど、予め定められた判定基準を自動的に解析することによって、ユーザが不正な行為を行っているか否かを判断する。また、ログ処理装置５００が通信ゲームのログを解析する場合、当該ログによって示されている処理を実機（例えば、ゲーム装置３と同様の能力を有する装置）を用いて解析（再現）して、ユーザが不正な行為を行っているか否かを判断する。ここで、ログ処理装置５００を用いたログ解析においては、通信ゲームを運営するオペレータ自身が当該ログを監視して、当該監視において不正行為の有無を判定してもかまわない。

なお、ログ取得対象となった通信ゲームをプレイしている全ユーザが、相手ユーザのログを含めて当該通信ゲームのログをログ保管サーバ３００に送信する場合、ログ処理サーバ４００および／またはログ処理装置５００は、送信されたログの整合性を確認することが可能となる。例えば、第１のゲーム装置３ａと第２のゲーム装置３ｂとの間で実行する通信ゲームがログ取得対象となった場合、ログ処理サーバ４００および／またはログ処理装置５００は、第１のゲーム装置３ａから取得した第１のゲーム装置３ａのログと第２のゲーム装置３ｂから取得した第１のゲーム装置３ａのログとの間の整合性を確認することが可能となる。また、ログ処理サーバ４００および／またはログ処理装置５００は、第２のゲーム装置３ｂから取得した第２のゲーム装置３ｂのログと第１のゲーム装置３ａから取得した第２のゲーム装置３ｂのログとの間の整合性も確認することが可能となる。したがって、通信ゲームのログ解析においては、特定ユーザのログだけでなく通信ゲームに参加した全ユーザのログが解析対象となるため、特定ユーザがログを改ざんして送信したとしても他のユーザから送信された当該特定ユーザのログとの整合性を確認することによって改ざんされたログを検出することができる。また、あるユーザが通信ゲームを途中で止めて通信ゲーム後にログを送信しなかった場合も、他のユーザから送信された当該あるユーザのログを解析することによって、途中で通信ゲームを止めたユーザを検出することができる。

また、ログ取得通知を受信したゲーム装置３は、ログ取得の対象となった通信ゲームを開始する前に当該通信ゲームの開始を示す情報を、ログ保管サーバ３００にそれぞれ送信してもよい。ここで、通信ゲームの開始を示す情報の一例として、当該通信ゲームに関する空ログが考えられる。このように、通信ゲームの開始を示す情報をログ保管サーバ３００に送信することによって、通信ゲーム開始後に当該通信ゲームを中断したユーザであっても当該情報がログ保管サーバ３００にアップされているために、ログ処理サーバ４００および／またはログ処理装置５００によるログ解析によってユーザが通信ゲームを中断したことを検出することができる。したがって、ログ処理サーバ４００および／またはログ処理装置５００では、通信ゲームの中断有無をユーザ評価の一要素として加えることができる。

ログ処理サーバ４００および／またはログ処理装置５００からの通報を受け取ったマッチメイキングサーバ２００は、当該通報毎に当該通報に対する通報スコアを算出する。そして、マッチメイキングサーバ２００は、通報されたユーザに対して既に設定されている通報スコアに、算出された通報スコアを加減算し、加減算された通報スコアを用いて当該ユーザの通報スコアを更新する。なお、通報スコアは、ユーザからの通報に対して、ログ処理サーバ４００および／またはログ処理装置５００からの不正行為の通報に対する通報スコアの絶対値を相対的に大きく設定してもかまわない。例えば、ユーザからの通報では虚偽の通報が行われる可能性があることに対して、ログ解析に基づいた通報は、その信用度が相対的に高くなるため、当該信用度に応じて通報スコアを設定することによって、通報スコアの信用度自体も高くすることが可能となる。

上述したように、通報スコアは、マッチメイキングサーバ２００において通信ゲームに参加するユーザを組み合わせる際に用いられているが、ユーザのアカウントを停止する場合の判断基準に用いることもできる。例えば、待機部屋の選出に用いる上記第１の閾値Ｔ１よりも相対的に大きい第３の閾値Ｔ３を設定し、通信ゲームの通報スコアが当該第３の閾値Ｔ３以上となったユーザを、当該通信ゲームに対するアカウントを停止する対象として抽出する。そして、アカウント停止対象となったユーザに対して、上記通信ゲームのログなどを所定の装置や運営者によって再解析するなど、所定の確認作業を行うことによって不正行為が確認された場合は、当該ユーザのアカウントを当該通信ゲームに関して停止することが考えられる。この場合、アカウントを停止するユーザのユーザＩＤと通信ゲームの種類とを示す情報を認証サーバ６００に通知することによって、認証サーバ６００においてアカウント停止処理を行ってもよい。なお、上述した手順では、アカウント停止対象となったユーザに対して、所定の確認作業を行った後にアカウント停止処置が行われる例を示したが、当該確認作業を行うことなく、通報スコアが第３の閾値Ｔ３以上となってアカウント停止対象となったユーザに対して、アカウントを停止する処置を即時に行ってもかまわない。

このように、ユーザ毎に算出される通報スコアに基づいて、通信ゲームにおける待機部屋の選択が可能となるため、通報スコアの優劣に応じて通信ゲームにおいてユーザを組み合わせることができる。そのため、通報スコアが相対的に優れているユーザと通報スコアが相対的に劣っているユーザとが組み合わされることを防止される。ここで、ユーザ毎に算出される通報スコアは、通信ゲームを行った相手ユーザの通報に基づいて算出されるため、マッチメイキングサーバ２００の処理負荷やサーバ運営者の作業負担を低減することができる。また、ユーザ毎に算出される通報スコアは、通信ゲームのログ解析に基づいて算出することも可能であるが、通信ゲームのログの一部が取得対象となるため、マッチメイキングサーバ２００の処理負荷やサーバ運営者の作業負担を低減しながら、ログ解析によって通報スコアの信用度を向上させることもできる。

次に、通信システム１において行われる処理の詳細を説明する。まず、図６〜図１０を参照して、処理において用いられる主なデータについて説明する。なお、図６は、ゲーム装置３のメインメモリ３２に記憶される主なデータおよびプログラムの一例を示す図である。図７は、マッチメイキングサーバ２００の記憶部２０３に記憶される主なデータおよびプログラムの一例を示す図である。図８は、記憶部２０３に記憶される通報スコアテーブルデータＤｍの一例を示す図である。図９は、記憶部２０３に記憶される通報ログ情報データＤｎの一例を示す図である。図１０は、記憶部２０３に記憶される通報スコア情報データＤｏの一例を示す図である。

図６に示すように、メインメモリ３２のデータ記憶領域には、操作データＤａ、ユーザＩＤデータＤｂ、パスワードデータＤｃ、デバイスＩＤデータＤｄ、通報相手データＤｅ、通報理由データＤｆ、参加者情報データＤｇ、ログ取得対象フラグデータＤｈ、ログデータＤｉ、および表示画像データＤｊ等が記憶される。なお、メインメモリ３２には、図６に示す情報に含まれるデータの他、実行するアプリケーションで用いるデータ等、処理に必要なデータが記憶される。また、メインメモリ３２のプログラム記憶領域には、通信プログラムを構成する各種プログラム群Ｐａが記憶される。

操作データＤａは、ユーザがゲーム装置３を操作した操作情報を示すデータである。例えば、操作ボタン等を操作したことを示す操作データは、ゲーム装置３が処理する時間単位（例えば、１／６０秒）毎に取得され、当該取得に応じて操作データＤａに格納されて更新される。

ユーザＩＤデータＤｂは、ゲーム装置３を使用するユーザの識別が可能となるユニークな符号（ユーザＩＤ）を示すデータであり、例えばユーザ識別のための標識となる文字列であるアカウントＩＤを示すデータである。パスワードデータＤｃは、ゲーム装置３を用いてネットワーク１００にログインする際に用いられるパスワードを示すデータである。

デバイスＩＤデータＤｄは、ゲーム装置３毎に識別が可能となるユニークな符号（デバイスＩＤ）を示すデータであり、例えばデバイス識別のための標識となる改変不可能な文字列を示すデータである。そして、デバイスＩＤデータＤｄには、ゲーム装置３に対して予め設定されているデバイスＩＤが格納されている。

通報相手データＤｅは、ユーザが通報する際の通報相手を示すデータであり、例えば当該通報相手のユーザＩＤを示すデータである。通報理由データＤｆは、ユーザが通報する際に選択した通報理由を示すデータである。

参加者情報データＤｇは、通信ゲームを行う際に、当該通信ゲームの参加者を示すデータであり、例えば当該通信ゲームに参加する参加者全員のユーザＩＤを示すデータである。

ログ取得対象フラグデータＤｈは、マッチメイキングサーバ２００から通信ゲームのログを取得する対象に指定された際にオンに設定されるログ取得対象フラグを示すデータである。なお、ログ取得対象フラグは、後述するゲームアプリケーションを起動する際、オフに初期化される。ログデータＤｉは、通信ゲームを行った際のログを示すデータであり、当該通信ゲームに参加した全ユーザのログが格納される。

表示画像データＤｊは、オブジェクト、文字、および背景等配置した画像を生成して表示部３９に表示するためのデータである。

図７に示すように、記憶部２０３のデータ記憶領域には、通報スコアテーブルデータＤｍ、通報ログ情報データＤｎ、通報スコア情報データＤｏ、通常部屋情報データＤｐ、および隔離部屋情報データＤｑ等が記憶される。なお、記憶部２０３には、図７に示す情報に含まれるデータの他、マッチメイキングサーバ２００で行う処理に必要なデータ等が記憶される。また、記憶部２０３のプログラム記憶領域には、上記処理を実現するための各種プログラム群Ｐｂが記憶される。

図８に示すように、通報スコアテーブルデータＤｍは、ユーザから通報された通報理由それぞれに応じて、予め設定された通報スコアを示すデータである。例えば、ユーザからの通報理由が「不正行為」である場合、通報スコアが＋２に設定されている。ユーザからの通報理由が「マナーが悪い」である場合、通報スコアが＋１に設定されている。ユーザからの通報理由が「うますぎる」や「下手すぎる」である場合、通報スコアが０に設定されている。そして、ユーザからの通報理由が「マナーがよい」である場合、通報スコアが−１に設定されている。

このように、図８に示した一例では、通信ゲームに関する通報理由の劣悪度合に応じて、劣悪度合が高いほど大きな値に通報スコアが設定されている。また、通信ゲームにおいて優良な相手であった場合の通報では、通報スコアが負の値に設定されており、不正行為なくマナーのよいゲームプレイを行った場合に自身の通報スコアを下げることが可能となり、各ユーザに優良なプレイを推奨する対策にもなり得る。さらに、図８に示した一例では、通報スコアが０に設定されている通報理由も設定されている。後述により明らかとなるが、ユーザは、複数の選択肢から選択することによって通報理由を選択することが可能である。一方、ユーザがゲームの熟練者や初心者である場合等、ユーザのプレイレベルに起因して通報されることが考えられる。つまり、相手のゲームプレイが劣悪であった場合の通報理由のみ選択可能に構成した場合、本来通信ゲームの相手に対する劣悪さが通報理由ではない場合であっても、劣悪であったことが原因となった通報理由が通報されてしまう。したがって、劣悪さにも優良さにも起因しない理由が通報理由であった場合、通報スコアに影響しない通報理由を選択肢に含ませることによって、ユーザからの誤通報を防止することが可能となる。

なお、このような効果を期待しない場合、通報理由に応じて設定される通報スコアは、正の値だけ、正の値と零との組み合わせ、または正の値と負の値との組み合わせでもかまわない。このような通報スコアの設定であっても、劣悪度合に応じた通報スコアの設定が可能であるため、後述するマッチメイキング処理において、通信ゲームに対する劣悪度合に応じたユーザの層別が可能となる。

図９に示すように、通報ログ情報データＤｎは、ユーザからマッチメイキングサーバ２００に通報された通報ログをそれぞれ示すデータである。例えば、通報ログ情報データＤｎは、通報者のユーザＩＤおよびデバイスＩＤと、被通報者のユーザＩＤおよびデバイスＩＤと、通報者が通報した通報理由とを、通報毎に示すデータである。

図１０に示すように、通報スコア情報データＤｏは、ユーザ毎に設定されている通報スコアを示すデータである。例えば、通報スコア情報データＤｏは、デバイスＩＤ、通報スコア、および当該通報スコアの最新更新日を、ユーザ毎に示すデータである。

通常部屋情報データＤｐは、ゲーム毎に設定されている通常の待機部屋に関するデータであり、通常の待機部屋の数および種別等とともに、それぞれの待機部屋で待機しているユーザを示すデータである。隔離部屋情報データＤｑは、ゲーム毎に設定されている隔離された待機部屋に関するデータであり、隔離された待機部屋の数および種別等とともに、それぞれの待機部屋で待機しているユーザを示すデータである。ここで、「隔離」とは、通常の待機部屋に対して隔離された環境であることを示しており、通報スコアが上記第１の閾値Ｔ１以上のユーザは、隔離された待機部屋のみ利用可能となる。

なお、上述した説明では、通常の待機部屋用の通常部屋情報データＤｐと隔離された待機部屋用の隔離部屋情報データＤｑとをそれぞれ設定しているが、１つの待機部屋用のデータを用いてもかまわない。例えば、上記１つの待機部屋用のデータにおいて、通常の待機部屋か隔離された待機部屋かを区別するフラグ（例えば、通常の待機部屋の場合にオフに設定され、隔離された待機部屋の場合にオンに設定されるフラグ）を設定し、当該フラグによって上記通常部屋情報データＤｐと隔離部屋情報データＤｑとを区別して運用してもかまわない。

次に、図１１〜図１８を参照して、ゲーム装置３およびマッチメイキングサーバ２００において行われる処理の詳細を説明する。なお、図１１は、ゲーム装置３において実行される処理の一例を示すフローチャートである。図１２は、図１１におけるステップ４４のゲーム参加処理の一例を示すサブルーチンである。図１３は、図１１におけるステップ５２の通報処理の一例を示すサブルーチンである。図１４は、マッチメイキングサーバ２００において実行される処理の一例を示すフローチャートである。図１５は、図１４におけるステップ９２の待機リスト送信処理の一例を示すサブルーチンである。図１６は、図１４におけるステップ９４の待機部屋作成処理の一例を示すサブルーチンである。図１７は、図１４におけるステップ９６の待機部屋参加処理の一例を示すサブルーチンである。図１８は、図１４におけるステップ９８の通報スコア算出処理の一例を示すサブルーチンである。ここで、図１１〜図１８に示すフローチャートにおいては、通信システム１における処理のうち、通報スコアが算出される処理やログが取得される処理について主に説明し、これらの処理と直接関連しない他の処理については詳細な説明を省略する。また、図１１〜図１８では、ＣＰＵ３１１が実行する各ステップを「Ｓ」と略称する。

ゲーム装置３の電源が投入されると、ゲーム装置３のＣＰＵ３１１は、ＲＯＭ／ＲＴＣ１３に記憶されている起動用のプログラムを実行し、これによってメインメモリ３２等の各ユニットが初期化される。そして、外部メモリ４５等に記憶された通信プログラムがメインメモリ３２に読み込まれ、ＣＰＵ３１１によって当該プログラムの実行が開始される。図１１〜図１３に示すフローチャートは、以上の処理が完了した後に行われる処理を示すフローチャートである。

図１１において、ＣＰＵ３１１は、ネットワーク１００にログインする処理を行い（ステップ４１）、次のステップに処理を進める。例えば、ＣＰＵ３１１は、ユーザＩＤデータＤｂが示すユーザＩＤ、パスワードデータＤｃが示すパスワード、およびデバイスＩＤデータＤｄが示すデバイスＩＤを用いて、ネットワーク１００にログインする処理を行う。ネットワーク１００に接続されている認証サーバ６００は、ログインの際に送信されたユーザＩＤおよびパスワードを用いてアカウント認証を行い、当該認証結果を送信元（ゲーム装置３）に送信する。なお、本実施例においては、認証サーバ６００は、ネットワーク１００の利用者のユーザＩＤおよびパスワードとともに、ログインに用いられたゲーム装置３のデバイスＩＤをユーザＩＤに関連付けて管理する。

次に、ＣＰＵ３１１は、認証サーバ６００から認証結果を待ち（ステップ４２）、アカウント認証によってログイン権利が確認された場合、次のステップ４３に処理を進める。

ステップ４３において、ＣＰＵ３１１はゲームアプリケーションを起動する。そして、ＣＰＵ３１１は、ゲーム参加処理を行い（ステップ４４）、次のステップに処理を進める。以下、図１２を参照して、上記ステップ４４において行われるゲーム参加処理について説明する。

図１２において、ＣＰＵ３１１は、上記ステップ４４で起動したゲームを他のユーザも参加する通信ゲーム形式で行うために、マッチメイキングサーバ２００にマッチメイキング要求を送信する（ステップ６１）。なお、ＣＰＵ３１１は、マッチメイキング要求を送信する際、マッチメイキング要求するゲームに関する情報（ゲームの種類、モード、ゲームレベル等を示す情報）とともに、ゲーム装置３のユーザを示すユーザＩＤ（ユーザＩＤデータＤｂが示すユーザＩＤ）をマッチメイキングサーバ２００へ送信する。そして、ＣＰＵ３１１は、マッチメイキングサーバ２００から送信される待機リストを待ち（ステップ６２）、待機リストを受領した場合、次のステップ６３に処理を進める。

ステップ６３において、ＣＰＵ３１１は、受領した待機リストに基づいて、現時点における待機部屋の状況を表示部３９に表示し、次のステップに処理を進める。ここで、マッチメイキングサーバ２００は、マッチメイキング要求したユーザの通報レベルに応じた待機リストをマッチメイキング要求元に送信している。具体的には、マッチメイキングサーバ２００は、マッチメイキング要求したユーザの通報レベルが第１の閾値Ｔ１未満である場合、通常の待機部屋の数および種別等とともに、通常の待機部屋でそれぞれ待機しているユーザを示す待機リストを送信する。一方、マッチメイキングサーバ２００は、マッチメイキング要求したユーザの通報レベルが第１の閾値Ｔ１以上である場合、隔離された待機部屋の数および種別等とともに、隔離された待機部屋でそれぞれ待機しているユーザを示す待機リストを送信する。したがって、上記ステップ６３において、ゲーム装置３の表示部３９には、ユーザの通報レベルが第１の閾値Ｔ１未満の場合に通常の待機部屋の状況が表示され、ユーザの通報レベルが第１の閾値Ｔ１以上の場合に隔離された待機部屋の状況が表示されることになる。

次に、ＣＰＵ３１１は、ステップ４４で起動した通信ゲームに参加するか否かを判断する（ステップ６４）。例えば、ＣＰＵ３１１は、操作データＤａを参照して、通信ゲームに参加する操作をユーザが行ったと判断した場合、当該通信ゲームに参加すると判断する。そして、ＣＰＵ３１１は、通信ゲームに参加する場合、次のステップ６５に処理を進める。一方、ＣＰＵ３１１は、通信ゲームに参加しない場合、上記ステップ６２に戻って処理を繰り返す。

ステップ６５において、ＣＰＵ３１１は、待機部屋を新たに作成するか否かを判断する。例えば、ＣＰＵ３１１は、操作データＤａを参照して、待機部屋を新たに作成する操作をユーザが行ったと判断した場合、当該待機部屋を作成すると判断する。そして、ＣＰＵ３１１は、待機部屋を新たに作成する場合、次のステップ６６に処理を進める。一方、ＣＰＵ３１１は、待機部屋を新たに作成しない場合、次のステップ６７に処理を進める。

ステップ６６において、ＣＰＵ３１１は、マッチメイキングサーバ２００に待機部屋作成要求を送信し、次のステップ６７に処理を進める。なお、ＣＰＵ３１１は、待機部屋作成要求を送信する際、待機部屋を作成するゲームに関する情報（ゲームの種類、モード、ゲームレベル等を示す情報）とともに、ゲーム装置３のユーザを示すユーザＩＤ（ユーザＩＤデータＤｂが示すユーザＩＤ）をマッチメイキングサーバ２００へ送信する。

ステップ６７において、ＣＰＵ３１１は、既に作成されている待機部屋に入るか否かを判断する。例えば、ＣＰＵ３１１は、操作データＤａを参照して、待機部屋に入る操作をユーザが行ったと判断した場合、当該待機部屋に入ると判断する。そして、ＣＰＵ３１１は、待機部屋に入る場合、次のステップ６８に処理を進める。一方、ＣＰＵ３１１は、待機部屋に入らない場合、次のステップ６９に処理を進める。

ステップ６８において、ＣＰＵ３１１は、マッチメイキングサーバ２００に待機部屋参加要求を送信し、次のステップ６９に処理を進める。なお、ＣＰＵ３１１は、待機部屋参加要求を送信する際、上記ステップ６３において表示された待機部屋から選択された参加要求する待機部屋に関する情報とゲーム装置３のユーザを示すユーザＩＤ（ユーザＩＤデータＤｂが示すユーザＩＤ）とを、マッチメイキングサーバ２００へ送信する。

ステップ６９において、ＣＰＵ３１１は、マッチメイキングサーバ２００から参加者情報およびログ取得通知を受信し、次のステップに処理を進める。ここで、マッチメイキングサーバ２００は、新たなユーザが待機部屋に登録された場合、当該待機部屋に参加している全ユーザに対して、当該全ユーザを示す参加者情報（例えば、参加者全員のユーザＩＤ）を送信している。一例として、マッチメイキングサーバ２００は、既に待機部屋に登録されていたユーザに対しては、新たに当該待機部屋にユーザが登録される毎に、新たに登録されたユーザを示す参加者情報を送信する。また、マッチメイキングサーバ２００は、新たに待機部屋に登録されたユーザに対しては、当該待機部屋に既に登録されているユーザを示す参加者情報を送信する。また、マッチメイキングサーバ２００は、待機部屋が作成された際、および待機部屋に登録される際、当該待機部屋をログ取得対象とした場合は、当該待機部屋に登録されているユーザに対してログ取得通知を送信している。上記ステップ６９においては、このようにマッチメイキングサーバ２００が参加者情報および／またはログ取得通知を送信した場合に受信する処理を行う。そして、ＣＰＵ３１１は、受信した参加者情報を用いて、参加者情報データＤｇを更新する。また、ＣＰＵ３１１は、ログ取得通知を受信した場合、ログ取得対象フラグをオンに設定して、ログ取得対象フラグデータＤｈを更新する。

次に、ＣＰＵ３１１は、通信ゲームを開始するか否かを判断する（ステップ７０）。通信ゲームを開始する条件としては、例えば、通信ゲームを開始する条件が満たされたこと（例えば、参加者の数が所定の人数に到達、参加者募集後に所定時間が経過）や、ユーザが通信ゲームを開始する操作を行ったこと等がある。ＣＰＵ３１１は、通信ゲームを開始しない場合に上記ステップ６５に戻って処理を繰り返し、通信ゲームを開始する場合に当該サブルーチンによる処理を終了する。

図１１に戻り、上記ステップ４４のゲーム参加処理の後、ＣＰＵ３１１は、上記ステップ４４において参加した通信ゲームがログ取得対象か否かを判断する（ステップ４５）。例えば、ＣＰＵ３１１は、ログ取得対象フラグデータＤｈが示すログ取得対象フラグがオンに設定されている場合、上記通信ゲームがログ取得対象であると判断する。そして、ＣＰＵ３１１は、上記通信ゲームがログ取得対象である場合、次のステップ４６に処理を進める。一方、ＣＰＵ３１１は、上記通信ゲームがログ取得対象でない場合、次のステップ４７に処理を進める。

ステップ４６において、ＣＰＵ３１１は、ログ保管サーバ３００に通信ゲームが開始されたことを示すログを送信し、次のステップ４７に処理を進める。例えば、ＣＰＵ３１１は、空ログと通信ゲームの参加者を示すユーザＩＤ（ゲーム装置３のユーザＩＤを含む）とを送ることによって、通信ゲームが開始されたことと当該通信ゲームの参加者とをログ保管サーバ３００に通知する。なお、上記ステップ４６で送信する空ログは、通信ゲームの開始を示す情報の一例であり、当該通信ゲームの開始を示すことが可能なものであれば他のデータを送信してもかまわない。

ステップ４７において、ＣＰＵ３１１は、起動されたゲームアプリケーションに基づいて、ゲーム処理を行い、次のステップに処理を進める。なお、上記ステップ４７では、参加者情報データＤｇが示す参加者情報に基づいて、当該参加者情報が示す他のゲーム装置３と通信しながら当該他のゲーム装置３のユーザが参加する通信ゲームが実行される。また、ＣＰＵ３１１は、上記ステップ４７のゲーム処理におけるログを、他の参加者のログも含めてログデータＤｉに記録する。

次に、ＣＰＵ３１１は、ゲームを終了するか否かを判断する（ステップ４８）。ゲームを終了する条件としては、例えば、ゲームを終了させる条件が満たされたこと（例えば、ゲームオーバ）や、ユーザがゲームを終了する操作を行ったこと等がある。ＣＰＵ３１１は、ゲームを終了しない場合に上記ステップ４７に戻って処理を繰り返し、ゲームを終了する場合に次のステップ４９に処理を進める。

ステップ４９において、ＣＰＵ３１１は、上記ステップ４４において参加した通信ゲームがログ取得対象か否かを判断する。例えば、ＣＰＵ３１１は、ログ取得対象フラグデータＤｈが示すログ取得対象フラグがオンに設定されている場合、上記通信ゲームがログ取得対象であると判断する。そして、ＣＰＵ３１１は、上記通信ゲームがログ取得対象である場合、次のステップ５０に処理を進める。一方、ＣＰＵ３１１は、上記通信ゲームがログ取得対象でない場合、次のステップ５１に処理を進める。

ステップ５０において、ＣＰＵ３１１は、ログ保管サーバ３００に上記ステップ４７において実行された通信ゲームのログを送信し、次のステップ５１に処理を進める。例えば、ＣＰＵ３１１は、ログデータＤｉが示すゲームログと通信ゲームの参加者を示すユーザＩＤ（ゲーム装置３のユーザＩＤを含む）とを送ることによって、通信ゲームのログと当該通信ゲームの参加者とをログ保管サーバ３００に送信する。

ステップ５１において、ＣＰＵ３１１は、通報を行うか否かを判断する。例えば、ＣＰＵ３１１は、上記通信ゲームが終了した際、当該通信ゲームに関する通報処理を行うことを示す通報ボタンを表示部３９に表示する。そして、ＣＰＵ３１１は、操作データＤａを参照して、表示部３９に表示された通報ボタンを選択する操作をユーザが行ったと判断した場合、通報を行うと判断する。そして、ＣＰＵ３１１は、通報を行う場合、次のステップ５２に処理を進める。一方、ＣＰＵ３１１は、通報を行わない場合、当該フローチャートによる処理を終了する。

ステップ５２において、ＣＰＵ３１１は、通報処理を行い、当該フローチャートによる処理を終了する。以下、図１３を参照して、上記ステップ５２において行われる通報処理について説明する。

図１３において、ＣＰＵ３１１は、通報相手を選択し（ステップ８１）、次のステップに処理を進める。例えば、ＣＰＵ３１１は、参加者情報データＤｇが示す参加者に基づいて、終了した通信ゲームに参加していた他のユーザのリストを表示部３９に表示して、ユーザに通報相手の選択を促す。そして、ＣＰＵ３１１は、操作データＤａを参照して、ユーザが入力部３８を用いて選択したユーザ（通報相手）を抽出し、当該ユーザを示すユーザＩＤを用いて通報相手データＤｅを更新する。

次に、ＣＰＵ３１１は、通報理由を選択し（ステップ８２）、次のステップに処理を進める。例えば、ＣＰＵ３１１は、予め設定されている複数の通報理由を表示部３９に表示して、ユーザに通報理由の選択を促す。ユーザに選択を促す通報理由の選択肢は、図８に示したように、一例として「不正行為」、「マナーが悪い」、「うますぎる」、「下手すぎる」、「マナーがよい」等が考えられる。そして、ＣＰＵ３１１は、操作データＤａを参照して、ユーザが入力部３８を用いて選択した通報理由を抽出し、当該通報理由を用いて通報理由データＤｆを更新する。

次に、ＣＰＵ３１１は、通報情報をマッチメイキングサーバ２００に送信し（ステップ８３）、当該サブルーチンによる処理を終了する。例えば、ＣＰＵ３１１は、通報相手データＤｅが示す通報相手のユーザＩＤと通報理由データＤｆが示す通報理由とを示す情報を用いて、通報情報をマッチメイキングサーバ２００へ送信する。

なお、上述したフローチャートでは、通信ゲームの終了直後に当該通信ゲームの参加者を通報相手とした通報が可能となる例を用いたが、他のタイミングで通報可能にしてもいいし、他の通報相手を通報対象としてもかまわない。例えば、通報が行えるタイミングは、上記通信ゲームが終了した後であれば、いつでも通報可能に構成してもかまわない。また、通報相手は、自身がプレイした通報ゲームの参加者でなくてもかまわない。例えば、ゲームに関する特定のユーザ（例えば、当該ゲームの得点ランキングに入っているユーザや通報ランキングに入っているユーザ）を通報相手として、上記通報情報を送信可能に構成してもかまわない。

図１４において、マッチメイキングサーバ２００の制御部２０２は、ゲーム装置３からマッチメイキング要求を受領したか否かを判断する（ステップ９１）。そして、制御部２０２は、マッチメイキング要求を受領した場合、次のステップ９２に処理を進める。一方、制御部２０２は、マッチメイキング要求を受領していない場合、次のステップ９３に処理を進める。

ステップ９２において、制御部２０２は、マッチメイキング要求を送信した送信元のゲーム装置３に待機リストを送信する処理を行い、次のステップ９３に処理を進める。以下、図１５を参照して、上記ステップ９２において行われる待機リスト送信処理について説明する。

図１５において、制御部２０２は、マッチメイキング要求した要求元のデバイスＩＤを取得して（ステップ１０１）、次のステップに処理を進める。例えば、制御部２０２は、マッチメイキング要求を送信したゲーム装置３から送信されたユーザＩＤのアカウント認証を認証サーバ６００に問い合わせるとともに、ユーザＩＤに対応するデバイスＩＤを要求する。そして、制御部２０２は、ユーザＩＤのアカウント認証を認証サーバ６００に確認し、ログイン権利が確認された場合、当該ユーザＩＤに対応するデバイスＩＤを取得する。

なお、アカウント認証処理については、マッチメイキングサーバ２００にアクセスする前段階で既に行われている（例えば、ステップ４１、ステップ４２）ため、当該アクセスの都度行わなくてもかまわない。この場合、マッチメイキングサーバ２００が認証サーバ６００と直接通信することは不要となり、マッチメイキングサーバ２００にアクセスしたゲーム装置３のデバイスＩＤについても当該ゲーム装置３から直接取得すればよい。なお、以下の説明においては、マッチメイキングサーバ２００にアクセスする毎にマッチメイキングサーバ２００がアカウント認証を認証サーバ６００に問い合わせるとともに、ユーザＩＤに対応するデバイスＩＤを要求する例を用いる。

次に、制御部２０２は、上記ステップ１０１で取得したデバイスＩＤに対応する通報スコアＮＳを抽出し（ステップ１０２）、次のステップに処理を進める。例えば、制御部２０２は、通報スコア情報データＤｏを参照して、上記ステップ１０１で取得したデバイスＩＤに対応する通報スコアＮＳを抽出する。

次に、制御部２０２は、上記ステップ１０２で抽出した通報スコアＮＳが第１の閾値Ｔ１未満か否かを判断する（ステップ１０３）。そして、制御部２０２は、通報スコアＮＳが第１の閾値Ｔ１未満である場合、次のステップ１０４に処理を進める。一方、制御部２０２は、通報スコアＮＳが第１の閾値Ｔ１以上である場合、次のステップ１０５に処理を進める。

ステップ１０４において、制御部２０２は、通常の待機部屋の待機リストを送信し、当該サブルーチンによる処理を終了する。例えば、制御部２０２は、通常部屋情報データＤｐを参照し、マッチメイキング要求されたゲームにおいて、通常の待機部屋の数および種別等とともに、当該通常の待機部屋に登録されているユーザを示す待機リストを作成して、マッチメイキング要求した要求元のゲーム装置３へ当該待機リストを送信する。

一方、ステップ１０５において、制御部２０２は、隔離された待機部屋の待機リストを送信し、当該サブルーチンによる処理を終了する。例えば、制御部２０２は、隔離部屋情報データＤｑを参照し、マッチメイキング要求されたゲームにおいて、隔離された待機部屋の数および種別等とともに、当該隔離された待機部屋に登録されているユーザを示す待機リストを作成して、マッチメイキング要求した要求元のゲーム装置３へ当該待機リストを送信する。

図１４に戻り、ステップ９３において、制御部２０２は、ゲーム装置３から待機部屋作成要求を受領したか否かを判断する。そして、制御部２０２は、待機部屋作成要求を受領した場合、次のステップ９４に処理を進める。一方、制御部２０２は、待機部屋作成要求を受領していない場合、次のステップ９５に処理を進める。

ステップ９４において、制御部２０２は、待機部屋作成処理を行い、次のステップ９５に処理を進める。以下、図１６を参照して、上記ステップ９４において行われる待機部屋作成処理について説明する。

図１６において、制御部２０２は、待機部屋作成要求した要求元のデバイスＩＤを取得して（ステップ１１１）、次のステップに処理を進める。例えば、制御部２０２は、待機部屋作成要求を送信したゲーム装置３から送信されたユーザＩＤのアカウント認証を認証サーバ６００に問い合わせるとともに、ユーザＩＤに対応するデバイスＩＤを要求する。そして、制御部２０２は、ユーザＩＤのアカウント認証を認証サーバ６００に確認し、ログイン権利が確認された場合、当該ユーザＩＤに対応するデバイスＩＤを取得する。

次に、制御部２０２は、上記ステップ１１１で取得したデバイスＩＤに対応する通報スコアＮＳを抽出し（ステップ１１２）、次のステップに処理を進める。例えば、制御部２０２は、通報スコア情報データＤｏを参照して、上記ステップ１１１で取得したデバイスＩＤに対応する通報スコアＮＳを抽出する。

次に、制御部２０２は、上記ステップ１１２で抽出した通報スコアＮＳが第１の閾値Ｔ１未満か否かを判断する（ステップ１１３）。そして、制御部２０２は、通報スコアＮＳが第１の閾値Ｔ１未満である場合、次のステップ１１４に処理を進める。一方、制御部２０２は、通報スコアＮＳが第１の閾値Ｔ１以上である場合、次のステップ１１５に処理を進める。

ステップ１１４において、制御部２０２は、待機部屋作成要求した要求元に対して当該要求元が要求したゲームの待機部屋として通常の待機部屋を用意し、当該待機部屋に当該要求元のユーザを登録して、次のステップ１１６に処理を進める。例えば、制御部２０２は、待機部屋作成要求されたゲームにおいて新たに通常の待機部屋を用意し、当該待機部屋に上記要求元のユーザＩＤを登録して、通常部屋情報データＤｐを更新する。これによって、通常部屋情報データＤｐには、待機部屋作成要求されたゲームにおいて、当該要求元が待機している新たな通常の待機部屋が、当該要求元のユーザＩＤとともに登録されることになる。

一方、ステップ１１５において、制御部２０２は、待機部屋作成要求した要求元に対して当該要求元が要求したゲームの待機部屋として隔離された待機部屋を用意し、当該待機部屋に当該要求元のユーザを登録して、次のステップ１１６に処理を進める。例えば、制御部２０２は、待機部屋作成要求されたゲームにおいて新たに隔離された待機部屋を用意し、当該待機部屋に上記要求元のユーザＩＤを登録して、隔離部屋情報データＤｑを更新する。これによって、隔離部屋情報データＤｑには、待機部屋作成要求されたゲームにおいて、当該要求元が待機している新たな隔離された待機部屋が、当該要求元のユーザＩＤとともに登録されることになる。

ステップ１１６において、制御部２０２は、上記ステップ１１４またはステップ１１５において作成した待機部屋を用いて行われる通信ゲームを、ログ取得対象とするか否かを判断する。そして、制御部２０２は、上記通信ゲームをログ取得対象とする場合、次のステップ１１７に処理を進める。一方、制御部２０２は、上記通信ゲームをログ取得対象としない場合、当該サブルーチンによる処理を終了する。第１の例として、制御部２０２は、待機部屋作成要求したユーザの通報スコアＮＳが第２の閾値Ｔ２以上である場合、当該ユーザが待機している待機部屋を用いて行われる通信ゲームをログ取得対象とする。第２の例として、制御部２０２は、待機部屋作成要求したユーザが待機している待機部屋を用いて行われる通信ゲームをログ取得対象とするか否かを、ランダム選択によって決定する。第３の例として、制御部２０２は、上記第１の例および第２の例を組み合わせてログ取得対象とするか否かを判断する。一例として、制御部２０２は、待機部屋作成要求したユーザの通報スコアＮＳが第２の閾値Ｔ２未満の場合に当該ユーザが待機している待機部屋を用いて行われる通信ゲームをログ取得対象とせず、当該通報スコアＮＳが第２の閾値Ｔ２以上の場合に当該待機部屋を用いて行われる通信ゲームをログ取得対象とするか否かをランダム選択によって決定する。他の例として、制御部２０２は、待機部屋作成要求したユーザの通報スコアＮＳが第２の閾値Ｔ２未満の場合に当該ユーザが待機している待機部屋を用いて行われる通信ゲームをログ取得対象とするか否かをランダム選択によって決定し、当該通報スコアＮＳが第２の閾値Ｔ２以上の場合に当該待機部屋を用いて行われる通信ゲームを必ずログ取得対象とする。

ステップ１１７において、制御部２０２は、待機部屋作成要求したゲーム装置３にログ取得通知を送信し、当該サブルーチンによる処理を終了する。例えば、制御部２０２は、待機部屋作成要求したユーザが待機している待機部屋をログ取得対象に設定して、当該待機部屋が管理されている通常部屋情報データＤｐまたは隔離部屋情報データＤｑを更新する。そして、制御部２０２は、待機部屋作成要求したゲーム装置３に、作成した待機部屋を用いた通信ゲームがログの取得対象であることを示すログ取得通知を送信する。

図１４に戻り、ステップ９５において、制御部２０２は、ゲーム装置３から待機部屋参加要求を受領したか否かを判断する。そして、制御部２０２は、待機部屋参加要求を受領した場合、次のステップ９６に処理を進める。一方、制御部２０２は、待機部屋参加要求を受領していない場合、次のステップ９７に処理を進める。

ステップ９６において、制御部２０２は、待機部屋参加処理を行い、次のステップ９７に処理を進める。以下、図１７を参照して、上記ステップ９６において行われる待機部屋参加処理について説明する。

図１７において、制御部２０２は、待機部屋参加要求した要求元のデバイスＩＤを取得して（ステップ１２１）、次のステップに処理を進める。例えば、制御部２０２は、待機部屋参加要求を送信したゲーム装置３から送信されたユーザＩＤのアカウント認証を認証サーバ６００に問い合わせるとともに、ユーザＩＤに対応するデバイスＩＤを要求する。そして、制御部２０２は、ユーザＩＤのアカウント認証を認証サーバ６００に確認し、ログイン権利が確認された場合、当該ユーザＩＤに対応するデバイスＩＤを取得する。

次に、制御部２０２は、待機部屋参加要求したユーザを、参加要請された待機部屋に登録し（ステップ１２２）、次のステップに処理を進める。例えば、制御部２０２は、参加要請された待機部屋に待機部屋参加要求したユーザのユーザＩＤを登録して、当該待機部屋を管理している通常部屋情報データＤｐまたは隔離部屋情報データＤｑを更新する。これによって、通常部屋情報データＤｐまたは隔離部屋情報データＤｑには、待機部屋参加要求されたゲームにおいて、参加要請された待機部屋に参加要求元のユーザＩＤが登録されることになる。

次に、制御部２０２は、参加者情報を送信し（ステップ１２３）、次のステップに処理を進める。例えば、制御部２０２は、上記ステップ１２２において新たなユーザが待機部屋に登録された場合、当該待機部屋に参加している全ユーザのゲーム装置３に対して、当該全ユーザを示す参加者情報（例えば、参加者全員のユーザＩＤ）を送信する。なお、マッチメイキングサーバ２００は、既に待機部屋に登録されていたユーザのゲーム装置３に対しては、新たに登録されたユーザのみを示す参加者情報を送信してもよい。また、マッチメイキングサーバ２００は、新たに待機部屋に登録されたユーザのゲーム装置３に対しては、当該待機部屋に既に登録されているユーザのみを示す参加者情報を送信してもよい。

次に、制御部２０２は、参加要請された待機部屋がログ取得対象か否かを判断する（ステップ１２４）。例えば、制御部２０２は、参加要請された待機部屋を管理している通常部屋情報データＤｐまたは隔離部屋情報データＤｑを参照して、当該待機部屋がログ取得対象に設定されているか否かを判断する。そして、制御部２０２は、参加要請された待機部屋がログ取得対象である場合、次のステップ１２５に処理を進める。一方、制御部２０２は、参加要請された待機部屋がログ取得対象でない場合、次のステップ１２６に処理を進める。

ステップ１２５において、制御部２０２は、待機部屋参加要求したゲーム装置３にログ取得通知を送信し、当該サブルーチンによる処理を終了する。例えば、制御部２０２は、待機部屋参加要求したゲーム装置３に、参加要請した待機部屋を用いた通信ゲームがログの取得対象であることを示すログ取得通知を送信する。

一方、ステップ１２６において、制御部２０２は、上記ステップ１２１で取得したデバイスＩＤに対応する通報スコアＮＳを抽出し、次のステップに処理を進める。例えば、制御部２０２は、通報スコア情報データＤｏを参照して、上記ステップ１２１で取得したデバイスＩＤに対応する通報スコアＮＳを抽出する。

次に、制御部２０２は、参加要請された待機部屋を用いて行われる通信ゲームを、ログ取得対象とするか否かを判断する（ステップ１２７）。そして、制御部２０２は、上記通信ゲームをログ取得対象とする場合、次のステップ１２８に処理を進める。一方、制御部２０２は、上記通信ゲームをログ取得対象としない場合、当該サブルーチンによる処理を終了する。なお、上記ステップ１２７においてログ取得対象とするか否かを判断する方法例は、待機部屋作成要求したユーザの通報スコアＮＳが用いられる例が、上記ステップ１２６で抽出した待機部屋作成要求したユーザの通報スコアＮＳが用いられることを除いて、上記ステップ１１６における処理と同様であるため、ここでは詳細な説明を省略する。

ステップ１２８において、制御部２０２は、参加要請された待機部屋に登録されている全ユーザのゲーム装置３にログ取得通知を送信し、当該サブルーチンによる処理を終了する。例えば、制御部２０２は、待機部屋参加要求されたユーザを登録した待機部屋をログ取得対象に設定して、当該待機部屋が管理されている通常部屋情報データＤｐまたは隔離部屋情報データＤｑを更新する。そして、制御部２０２は、当該待機部屋に登録されている全ユーザのゲーム装置３に、参加している待機部屋を用いた通信ゲームがログの取得対象であることを示すログ取得通知を送信する。

図１４に戻り、ステップ９７において、制御部２０２は、他の装置（ゲーム装置３、ログ処理サーバ４００、ログ処理装置５００等）から通報を受領したか否かを判断する。そして、制御部２０２は、通報を受領した場合、次のステップ９８に処理を進める。一方、制御部２０２は、通報を受領していない場合、次のステップ９９に処理を進める。

ステップ９８において、制御部２０２は、通報スコア算出処理を行い、次のステップ９９に処理を進める。以下、図１８を参照して、上記ステップ９９において行う通報スコア算出処理について説明する。

図１８において、制御部２０２は、受領した通知がユーザからの通報（ゲーム装置３からの通報）か否かを判断する（ステップ１３１）。そして、制御部２０２は、ユーザからの通報である場合、次のステップ１３２に処理を進める。一方、制御部２０２は、ユーザからの通報でない場合、次のステップ１３７に処理を進める。

ステップ１３２において、制御部２０２は、通報を行った通報者および通報された被通報者のデバイスＩＤを取得して、次のステップに処理を進める。例えば、制御部２０２は、通報したゲーム装置３から送信されたユーザＩＤ（すなわち、通報者のユーザＩＤ）のアカウント認証を認証サーバ６００に問い合わせるとともに、ユーザＩＤに対応するデバイスＩＤを要求する。また、制御部２０２は、認証サーバ６００に対して、通報されたユーザを示すユーザＩＤ（すなわち、被通報者のユーザＩＤ）に対応するデバイスＩＤを要求する。そして、制御部２０２は、通報者のユーザＩＤのアカウント認証を認証サーバ６００に確認し、ログイン権利が確認された場合、通報者のユーザＩＤおよび被通報者のユーザＩＤにそれぞれ対応するデバイスＩＤを取得する。

次に、制御部２０２は、通報された通報情報を通報ログ情報データＤｎに登録し（ステップ１３３）、次のステップに処理を進める。例えば、図９に示すように、制御部２０２は、ゲーム装置３から通報された通報情報（通報者のユーザＩＤおよびデバイスＩＤ、被通報者のユーザＩＤおよびデバイスＩＤ、通報理由）を通報ログ情報に追加して、通報ログ情報データＤｎを更新する。

次に、制御部２０２は、通報された通報情報が既に通報されているものか否かを判断する（ステップ１３４）。そして、制御部２０２は、通報された通報情報が既に通報されているものではない場合、次のステップ１３５に処理を進める。一方、制御部２０２は、通報された通報情報が既に通報されているものである場合、次のステップ１３７に処理を進める。第１の例として、制御部２０２は、通報ログ情報データＤｎを参照して、受領した通報情報の通報者が当該通報情報の被通報者に対して既に通報している場合、受領した通報情報が既に通報されているものと判断する。第２の例として、通報ログ情報データＤｎを参照して、受領した通報情報の通報者が当該通報情報の被通報者に対して既に所定回数以上通報している場合、受領した通報情報が既に通報されているものと判断する。第３の例として、通報ログ情報データＤｎを参照して、受領した通報情報の通報者が当該通報情報の被通報者に対して所定期間以内に通報している場合、受領した通報情報が既に通報されているものと判断する。なお、受領した通報情報が既に通報されているものと判断された場合、当該通報された通報情報を通報ログ情報データＤｎに登録しなくてもかまわない。

ステップ１３５において、制御部２０２は、受領した通報の通報理由に応じた通報スコアを取得して、次のステップに処理を進める。例えば、制御部２０２は、通報スコアテーブルデータＤｍ（図８参照）を参照して、受領した通報の通報理由に応じた通報スコアを取得する。

次に、制御部２０２は、被通報者の通報スコアを算出して（ステップ１３６）、次のステップ１３７に処理を進める。例えば、制御部２０２は、通報スコア情報データＤｏ（図１０参照）を参照して、受領した通報における被通報者のデバイスＩＤに対応する通報スコアに、上記ステップ１３５で取得した通報スコアを加算する。そして、制御部２０２は、加算後の通報スコアを用いて、通報スコア情報データＤｏの当該デバイスＩＤに対応する通報スコアを更新する。

なお、上記ステップ１３４〜ステップ１３６の処理では、マッチメイキングサーバ２００側で通報者と被通報者との組み合わせが同じ通報について有効／無効を判定し、有効な通報に対して通報スコアの更新を行っている。しかしながら、通報を行うゲーム装置３側で通報を制限してもかまわない。例えば、ゲーム装置３において、上記ステップ１３４の処理の判断基準において無効と判断されるような、通報者と被通報者との組み合わせが同じ通報については当該通報が作成されないようにしてもかまわない。この場合、マッチメイキングサーバ２００側で通報の有効／無効を判定する必要がないため、上記ステップ１３４の判定処理が不要となる。

ステップ１３７において、受領した通知がログ処理結果による通報（ログ処理サーバ４００またはログ処理装置５００からの通報）か否かを判断する。そして、制御部２０２は、ログ処理結果による通報である場合、次のステップ１３８に処理を進める。一方、制御部２０２は、ログ処理結果による通報でない場合、当該サブルーチンによる処理を終了する。

ステップ１３８において、制御部２０２は、ログ処理結果に基づいて通報された被通報者のデバイスＩＤを取得して、次のステップに処理を進める。例えば、制御部２０２は、ログ処理サーバ４００またはログ処理装置５００から通報された被通報者を示すユーザＩＤ（すなわち、被通報者のユーザＩＤ）に対応するデバイスＩＤを認証サーバ６００に要求する。そして、制御部２０２は、認証サーバ６００から被通報者のユーザＩＤに対応するデバイスＩＤを取得する。

次に、制御部２０２は、受領した通報の通報理由に応じた通報スコアを取得して（ステップ１３９）、次のステップに処理を進める。一例として、制御部２０２は、通報スコアテーブルデータＤｍを参照して、受領した通報の通報理由に応じた通報スコアを取得する。他の例として、制御部２０２は、ユーザからの通報による通報スコアより十分に大きい値をログ処理結果に基づいた通報専用の通報スコアとして予め設定しており、当該設定された通報スコアを取得する。

次に、制御部２０２は、被通報者の通報スコアを算出して（ステップ１４０）、当該サブルーチンによる処理を終了する。例えば、制御部２０２は、通報スコア情報データＤｏを参照して、受領した通報における被通報者のデバイスＩＤに対応する通報スコアに、上記ステップ１３９で取得した通報スコアを加算する。そして、制御部２０２は、加算後の通報スコアを用いて、通報スコア情報データＤｏの当該デバイスＩＤに対応する通報スコアを更新する。

なお、上記ステップ１３７〜ステップ１４０の処理の説明においては、ログ処理サーバ４００またはログ処理装置５００からの通報に応じて、被通報者の通報スコアがカウントアップされる例を用いたが、当該通報に応じて被通報者の通報スコアが減算または初期化されてもかまわない。この場合、ログ処理サーバ４００またはログ処理装置５００におけるログ解析において、ユーザが不正な行為を行っていないと判定された場合、当該解析結果を示すデータをログ処理結果としてマッチメイキングサーバ２００へ送信する。そして、当該ログ処理結果を受領したマッチメイキングサーバ２００は、通報スコア情報データＤｏを参照して、受領した通報における被通報者のデバイスＩＤに対応する通報スコアから所定数減算または当該通報スコアを所定値（例えば、０）に初期化して、減算または初期化後の通報スコアを用いて、通報スコア情報データＤｏの当該デバイスＩＤに対応する通報スコアを更新する。このように、ログ解析の結果によって、ユーザの通報スコアを減算または初期化してもかまわない。

図１４に戻り、ステップ９９において、制御部２０２は、通報スコアをカウントアップした最新更新日が所定日数前となっているデバイスＩＤの通報スコアがあるか否かを判断する。例えば、制御部２０２は、通報スコア情報データＤｏに記載されている通報スコアカウントアップ最新更新日を参照して、当該最新更新日が所定日数前（例えば、７日前）になっているデバイスＩＤの通報スコアの有無を確認する。そして、制御部２０２は、最新更新日が所定日数前となっているデバイスＩＤの通報スコアがある場合、次のステップ１００に処理を進める。一方、制御部２０２は、最新更新日が所定日数前となっているデバイスＩＤの通報スコアがない場合、当該フローチャートによる処理を終了する。

ステップ１００において、制御部２０２は、最新更新日が所定日数前となっている通報スコアを初期化して、当該フローチャートによる処理を終了する。例えば、制御部２０２は、通報スコア情報データＤｏに記載されている通報スコアカウントアップ最新更新日が所定日数前になっている通報スコアを全て所定値（例えば、０）に初期化し、当該最新更新日を全て初期化した日にして、通報スコア情報データＤｏを更新する。

このように、通信システム１では、ユーザからの通報に基づいて、通信ゲームをプレイする組み合わせが決定されるため、善良なユーザが不正な行為を行う可能性のあるユーザと組み合わせられることを防止することを実現しながら、サーバの処理負荷およびサーバ運用者の作業負荷を低減することができる。また、通信システム１では、通信ゲームにおけるマッチメイキングの際に当該通信ゲームのログを取得するか否かの判断が行われ、当該判断結果に基づいて当該ログが取得されるため、通信ゲームにおけるマッチメイキング状況に応じた効率のよい当該通信ゲームのログ収集が可能となる。

なお、上述した説明では、マッチメイキング処理において第１の閾値Ｔ１以上か否かによってユーザを２つの群に層別し、同じ群に属するユーザ同士を組み合わせる例を用いたが、ユーザを３つ以上の群に層別してもかまわない。例えば、第１の閾値Ｔ１より小さい第４の閾値Ｔ４を新たに設定して、通報スコアＮＳが第４の閾値Ｔ４未満の第１の群、通報スコアＮＳが第４の閾値Ｔ４以上で第１の閾値Ｔ１未満の第２の群、および通報スコアＮＳが第１の閾値Ｔ１以上の第３の群にユーザを層別し、同じ群に属するユーザ同士を組み合わせる。

また、マッチメイキング処理において、ユーザを３つ以上の群に層別する場合、マッチメイキング処理において異なる群に属するユーザ同士を組み合わせてもかまわない。例えば、上述した第１の群、第２の群、および第３の群にユーザを層別する場合、第１の群のユーザを同じ第１の群または第２の群のユーザと組み合わせ、第３の群のユーザを同じ第３の群のユーザまたは第２のユーザと組み合わせる。つまり、マッチメイキング処理において、ある群に属するユーザと当該ある群に分類される通報スコアに対して最も大きな差を有する通報スコアが分類される群を少なくとも除いた群に属するユーザ（典型的には、分類される通報スコアの大きさが近い群（例えば、隣接する群）のユーザ同士）とが組み合わせられる。このような組み合わせであっても、通報スコアのレベルが相対的に大きく異なるユーザ（例えば、第１の群、第２の群、第３の群にユーザを層別する場合の第１の群のユーザと第３の群のユーザ）が組み合わせられることがないため、善良なユーザが不正を行う可能性が高いユーザと組み合わせられることを防止することができる。

また、上述した処理では、通報スコアのカウントアップが所定日数前から現時点までないユーザを対象として、当該通報スコアを初期化している。このように、実時間を条件として通報スコアを初期化することによって、ゲーム装置３が売却されたり譲り渡されたりした場合であっても、ユーザが他のユーザに手渡してから所定日数が経過することによって当該ゲーム装置３に設定されている通報スコアが初期化されるため、前のユーザの通報スコアの設定が次のユーザに引き継がれることを防止することができる。このような効果を期待しない場合、他の態様によってユーザの通報スコアを初期化してもかまわない。一例として、通報スコアの対象となっている通信ゲーム（アプリケーション）が所定回数行われる間に通報スコアのカウントアップがないユーザを対象として、当該通報スコアを初期化する。他の例として、通報スコアの対象となっている通信ゲーム（アプリケーション）が実行されている累積時間が所定時間になるまでの間に通報スコアのカウントアップがないユーザを対象として、当該通報スコアを初期化する。このように、実時間だけでなく通信ゲーム（アプリケーション）を行った回数や時間を条件として、ユーザの通報スコアを初期化してもかまわない。

また、上述した処理では、ゲーム装置３のユーザが通報する際、通報理由を示す情報がマッチメイキングサーバ２００に送信され、当該通報理由に相当する通報スコアがマッチメイキングサーバ２００によって設定されるが、送信元側で通報スコアを設定してもかまわない。すなわち、ゲーム装置３のユーザが通報する際、通報理由に相当する通報スコアがゲーム装置３によって設定され、当該通報スコアを示す情報がマッチメイキングサーバ２００に送信されてもかまわない。

また、上述した処理では、通信ゲームが終了した時点で当該通信ゲームに参加していたゲーム装置３それぞれからゲームログがログ保管サーバ３００へ送出されるが、他のタイミングでゲームログが送出されてもかまわない。例えば、ログ取得対象フラグデータＤｈが示すログ取得対象フラグがオンに設定されている場合、上記ステップ４７におけるゲーム処理中において所定の周期で、当該ゲーム処理に関するゲームログがゲーム装置３それぞれからログ保管サーバ３００へ送出されてもかまわない。

また、上述した説明では、１人のユーザが１台のゲーム装置３を操作する前提でゲーム装置３同士をマッチメイキングする例を用いており、これによってユーザ同士がマッチメイキングされることになる。しなしながら、上記実施例は、複数のユーザが１台のゲーム装置３を操作する環境であっても適用することができる。例えば、複数のユーザが１台のゲーム装置３を操作する環境でユーザ同士をマッチメイキングする場合、デバイスＩＤの代わりにアカウント認証されたユーザＩＤだけを用いてマッチメイキングすれば、当該環境であってもユーザ同士のマッチメイキングが可能であることは言うまでもない。

また、上述した説明では、ログ取得対象が待機部屋単位で設定されるため、当該待機部屋に属している全てのユーザを対象にしてログ取得であるか否かが設定される。しかしながら、上記ログ取得対象は、待機部屋に属している一部のユーザ（１人または２人以上）に設定してもかまわない。この場合、当該待機部屋を用いた通信ゲームでは、当該通信ゲームに参加した一部のユーザのログを取得することになるが、当該ユーザから取得するログに通信ゲームに参加した全てのユーザのログが含まれているために、同様のログ解析が可能となる。

また、上述した説明では情報処理をゲーム装置３およびマッチメイキングサーバ２００で行う例を用いたが、上記情報処理における処理ステップの少なくとも一部を他の装置で行ってもかまわない。例えば、ゲーム装置３がさらに他の装置（例えば、別のサーバ、他のゲーム装置、他の携帯端末）と通信可能に構成されている場合、上記情報処理における処理ステップは、さらに当該他の装置が協働することによって実行してもよい。一例として、他の装置において、ゲーム処理における仮想世界の生成や当該仮想世界を用いたゲーム処理が行われ、当該ゲーム処理の結果がゲーム装置３の表示部３９に表示されることも考えられる。また、マッチメイキングサーバ２００で行われている処理の一部をゲーム装置３や他の装置で行うことも考えられる。このように、上記情報処理における処理ステップの少なくとも一部を他の装置で行うことによって、上述した情報処理と同様の処理が可能となる。また、上述した情報処理は、少なくとも１つの情報処理装置とサーバとにより構成される通信システムに含まれる１つのプロセッサまたは複数のプロセッサ間の協働により実行されることが可能である。また、上記実施形態においては、ゲーム装置３のＣＰＵ３１１やマッチメイキングサーバ２００の制御部２０２が所定のプログラムを実行することによって、上述したフローチャートによる処理が行われたが、ゲーム装置３が備える専用回路やマッチメイキングサーバ２００が備える専用回路によって上記処理の一部または全部が行われてもよい。

また、上述した情報処理で用いられる処理順序、設定値、判定に用いられる条件等は、単なる一例に過ぎず他の順序、値、条件であっても、本実施例を実現できることは言うまでもない。

また、上記通信プログラム（ゲームプログラム）は、外部メモリ４５等の外部記憶媒体を通じてゲーム装置３に供給されるだけでなく、有線または無線の通信回線を通じてゲーム装置３に供給されてもよい。また、上記プログラムは、ゲーム装置３内部の不揮発性記憶装置に予め記録されていてもよい。なお、上記プログラムを記憶する情報記憶媒体としては、不揮発性メモリの他に、ＣＤ−ＲＯＭ、ＤＶＤ、あるいはそれらに類する光学式ディスク状記憶媒体、フレキシブルディスク、ハードディスク、光磁気ディスク、磁気テープ、などでもよい。また、上記プログラムを記憶する情報記憶媒体としては、上記プログラムを記憶する揮発性メモリでもよい。このような記憶媒体は、コンピュータ等が読み取り可能な記録媒体ということができる。例えば、コンピュータ等に、これらの記録媒体のプログラムを読み込ませて実行させることにより、上述で説明した各種機能を提供させることができる。

以上、本発明を詳細に説明してきたが、前述の説明はあらゆる点において本発明の例示に過ぎず、その範囲を限定しようとするものではない。本発明の範囲を逸脱することなく種々の改良や変形を行うことができることは言うまでもない。本発明は、特許請求の範囲によってのみその範囲が解釈されるべきであることが理解される。また、当業者は、本発明の具体的な実施形態の記載から、本発明の記載および技術常識に基づいて等価な範囲を実施することができることが理解される。また、本明細書において使用される用語は、特に言及しない限り、当該分野で通常用いられる意味で用いられることが理解されるべきである。したがって、他に定義されない限り、本明細書中で使用される全ての専門用語および技術用語は、本発明の属する分野の当業者によって一般的に理解されるのと同じ意味を有する。矛盾する場合、本明細書（定義を含めて）が優先する。

本発明に係る通信システム、通信プログラム、情報処理装置、サーバ、および通信方法は、新規な通信システム、通信プログラム、情報処理装置、サーバ、および通信方法を提供することができ、複数の装置間で所定の情報処理等を行う通信システム、通信プログラム、情報処理装置、サーバ、および通信方法等として有用である。

１…通信システム
３…ゲーム装置
３１…情報処理部
３１１…ＣＰＵ
３１２…ＧＰＵ
３１３…ＶＲＡＭ
３２…メインメモリ
３３…外部メモリＩ／Ｆ
３５…データ保存用内部メモリ
３６…無線通信モジュール
３７…ローカル通信モジュール
３８…入力部
３９…表示部
１００…ネットワーク
２００…マッチメイキングサーバ
２０１…通信部
２０２…制御部
２０３…記憶部
３００…ログ保管サーバ
４００…ログ処理サーバ
５００…ログ処理装置
６００…認証サーバ

Claims (14)

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

Images