JP5923201B1 - 情報処理装置、及び、ゲームプログラム - Google Patents

Abstract

【課題】ユーザーの生活スタイルに適したマッチングを行なう。【解決手段】本発明に係る情報処理装置は、各ユーザーが利用することのできる複数サービスに含まれるゲームサービスにおいて、１日に複数設定された所定時間帯に行われる多人数参加型ゲームの進行を制御するゲームサービス制御部と、各ユーザーの１日分のサービス利用状況に関するデータを複数日に亘って収集することによって生成された各ユーザーのサービス利用情報を記憶する記憶部と、前記多人数参加型ゲームが行われる度に各ユーザーの前記サービス利用情報を参照することにより、１日のうちの当該多人数参加型ゲームが行われる所定時間帯での各ユーザーのサービス利用状況に基づいて、当該多人数参加型ゲームを同一時間帯にプレイできる複数のユーザーをマッチングするマッチング処理部を備える。【選択図】図１

Description

本発明は、情報処理装置、及び、ゲームプログラムに関する。

多人数参加型ゲームへの参加を希望するユーザーの中から同時にゲームプレイできる複数のユーザーを選択してマッチングを行なうマッチング処理と、そのマッチングされた各ユーザーがプレイする多人数参加型ゲームの進行を制御するゲーム進行処理と、を実行する情報処理装置が知られている（たとえば、特許文献１）。

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

このような情報処理装置では、多人数参加型ゲームが行われる時間帯を１日のうちに複数設定しておき、それぞれの時間帯にプレイさせる複数ユーザーをマッチングする場合がある。かかる場合には、ユーザーの生活スタイルは考慮されずにマッチングが行われていた。そのため、マッチングされたユーザーの中には、マッチングが行われたにも拘わらず、ゲームが行われる時間帯によっては自己の生活スタイルに合わず不都合となってしまい、そのゲームに参加できないユーザーも存在することになる。その結果、ユーザー参加率の低下を招き、多人数参加ゲームの興趣をそいでしまう一因となっていた。
本発明は、このような事情に鑑みてなされたものであり、その目的とするところは、ユーザーの生活スタイルに適したマッチングを行なうことにある。

上記課題を解決するための本発明の主たる発明は、
各ユーザーが利用することのできる複数サービスに含まれるゲームサービスにおいて、１日に複数設定された所定時間帯に行われる多人数参加型ゲームの進行を制御するゲームサービス制御部と、
各ユーザーの１日分のサービス利用状況に関するデータを複数日に亘って収集することによって生成された各ユーザーのサービス利用情報を記憶する記憶部と、
前記多人数参加型ゲームが行われる度に各ユーザーの前記サービス利用情報を参照することにより、１日のうちの当該多人数参加型ゲームが行われる所定時間帯での各ユーザーのサービス利用状況に基づいて、当該多人数参加型ゲームを同一時間帯にプレイできる複数のユーザーをマッチングするマッチング処理部と、
を備えたことを特徴とする情報処理装置である。
本発明の他の特徴については、本明細書及び添付図面の記載により明らかにする。

サービス提供システム１の全体構成例を示す図である。 サーバー装置１０の機能上の構成を示すブロック図である。 イベント時間帯を説明するための図である。 ゲームサービス情報のデータ構造例を示す図である。 ユーザー情報のデータ構造例を示す図である。 キャラクター情報のデータ構造例を示す図である。 エントリー情報のデータ構造例を示す図である。 マッチング情報のデータ構造例を示す図である。 チーム情報のデータ構造例を示す図である。 マイゲーム情報のデータ構造例を示す図である。 所有キャラクター情報のデータ構造例を示す図である。 サービス利用情報のデータ構造例を示す図である。 ユーザー端末２０の機能上の構成を示すブロック図である。 マッチングについての動作例を説明するためのフローチャートである。 各ユーザーのサービス利用頻度について説明する図である。

本明細書及び添付図面の記載により、少なくとも以下の事項が明らかとなる。
即ち、各ユーザーが利用することのできる複数サービスに含まれるゲームサービスにおいて、１日に複数設定された所定時間帯に行われる多人数参加型ゲームの進行を制御するゲームサービス制御部と、
各ユーザーの１日分のサービス利用状況に関するデータを複数日に亘って収集することによって生成された各ユーザーのサービス利用情報を記憶する記憶部と、
前記多人数参加型ゲームが行われる度に各ユーザーの前記サービス利用情報を参照することにより、１日のうちの当該多人数参加型ゲームが行われる所定時間帯での各ユーザーのサービス利用状況に基づいて、当該多人数参加型ゲームを同一時間帯にプレイできる複数のユーザーをマッチングするマッチング処理部と、
を備えたことを特徴とする情報処理装置である。
このような情報処理装置によれば、ユーザーのサービス利用情報を用いることで、１日におけるサービス利用状況からユーザーの生活スタイルが推測できるため、所定時間帯に多人数参加型ゲームに参加し易い生活スタイルを持つ複数ユーザーをマッチングする等、ユーザーの生活スタイルに適したマッチングを行なうことが可能となる。

また、かかる情報処理装置であって、
前記マッチング処理部は、各ユーザーの前記サービス利用情報を参照することにより、各々の前記所定時間帯に、サービスを利用する傾向のある複数のユーザー、及び、サービスを利用する傾向のない複数のユーザー、の少なくとも一方をマッチングする、こととしてもよい。
このような情報処理装置によれば、１日におけるサービス利用状況から所定時間帯でのサービス利用傾向が特定できるため、その傾向に合わせて公平なマッチングを行なうことが可能となる。

また、かかる情報処理装置であって、
前記記憶部は、既に行われた前記多人数参加型ゲームでユーザーが得た過去のゲーム成績を、各ユーザーに対応付けて記憶し、
前記マッチング処理部は、各ユーザーの過去のゲーム成績、及び、各々の前記所定時間帯での各ユーザーのサービス利用状況に基づいて、各々の前記所定時間帯に行われる前記多人数参加型ゲームを同一時間帯にプレイできる複数のユーザーをそれぞれマッチングする、こととしてもよい。
このような情報処理装置によれば、ユーザーの過去のゲーム成績も併せて用いることで、ユーザーの実力に合わせて公平なマッチングを行なうことが可能となる。

また、かかる情報処理装置であって、
前記記憶部は、各ユーザーの１日分のサービス利用状況に関するデータを複数週間に亘って収集することによって生成されたサービス利用情報、及び、既に行われた前記多人数参加型ゲームでユーザーが獲得したゲームポイントを、各ユーザーに対応付けて記憶し、
前記マッチング処理部は、
各ユーザーの前記サービス利用情報を参照して、前記多人数参加型ゲームが行われる曜日毎の各所定時間帯における各ユーザーのサービス利用頻度をカウントし、
各ユーザーの前記サービス利用頻度、及び、各ユーザーが過去に獲得した前記ゲームポイントを用いて、前記多人数参加型ゲームが行われる曜日の所定時間帯に貢献できる潜在能力を示す各ユーザーのポテンシャル値を算出し、
各ユーザーの前記ポテンシャル値に基づいて、曜日毎の各所定時間帯に行なわれる前記多人数参加型ゲームを同一時間帯にプレイできる複数のユーザーをそれぞれマッチングする、こととしてもよい。
このような情報処理装置によれば、ユーザーのポテンシャル値を用いることで、多人数参加型ゲームが行われる曜日毎の各所定時間帯に貢献できる潜在能力をユーザー毎に数値化できるため、それぞれの時間帯に貢献できる潜在能力に合わせて公平なマッチングを行なうことが可能となる。

次に、コンピューターに、
各ユーザーが利用することのできる複数サービスに含まれるゲームサービスにおいて、１日に複数設定された所定時間帯に行われる多人数参加型ゲームの進行を制御するゲームサービス制御処理と、
各ユーザーの１日分のサービス利用状況に関するデータを複数日に亘って収集することによって生成された各ユーザーのサービス利用情報を記憶部に記録する記録処理と、
前記多人数参加型ゲームが行われる度に各ユーザーの前記サービス利用情報を参照することにより、１日のうちの当該多人数参加型ゲームが行われる所定時間帯での各ユーザーのサービス利用状況に基づいて、当該多人数参加型ゲームを同一時間帯にプレイできる複数のユーザーをマッチングするマッチング処理と、
を実行させることを特徴とするゲームプログラムである。
このようなゲームプログラムによれば、ユーザーの生活スタイルに適したマッチングを行なうことが可能となる。

＝＝＝実施形態＝＝＝
＜＜サービス提供システム１の構成＞＞
図１は、サービス提供システム１の全体構成の一例を示す図である。サービス提供システム１は、ネットワーク２（例えば、インターネット等）を介して様々なサービスをユーザーに提供するものであり、サーバー装置１０と、複数のユーザー端末２０と、を含んで構成される。

本実施形態に係るサービス提供システム１は、アバターサービス、メッセージサービス、ゲームサービス等の各種サービスをユーザーに提供することができる。アバターサービスでは、ユーザーは、ユーザーの分身（アバターと呼ばれる）を作成したり、そのアバターのデザインを変更したりすることができる。メッセージサービスでは、ユーザーは、メッセージを作成したり、そのメッセージをユーザー間でやりとりしたりすることができる。ゲームサービスでは、ユーザーは、複数種類のゲームの中からいずれかを選択して、ゲームプレイを行なうことができる。

このゲームサービスにおいてユーザーに提供可能なゲームの中には、定期的にイベントを所定期間に亘って開催するゲームが含まれている。このイベントでは、イベントゲームが行われる所定の時間帯が、１日のうちに複数設定されている。そして、各々の時間帯になると、多人数参加型のイベントゲームが行われる。イベントゲームに参加するユーザーは、所定人数（例えば、２０人）で構成されるいずれかのチームに所属する。イベントゲームでは、チームに所属する各ユーザーに共通の対戦相手となるエネミーキャラクターが出現するため、チーム内の各ユーザーはそのエネミーキャラクターへの攻撃を次々と行なう。エネミーキャラクターを倒すことができれば、ゲームポイントを獲得することができる。

またイベントゲームでは、チーム毎に出現するエネミーキャラクターとの対戦を競い合う相手チーム（つまり、同時にゲームプレイできる複数ユーザー）がマッチングされ、マッチングされたチーム同士により、相手チームよりも多くのゲームポイントを獲得することを目的とするチーム対戦が行われる。そして、このマッチングでは、イベントゲームの利用状況のみならず、各種サービスの利用状況から各ユーザーの生活スタイルが推測され、その時間帯にゲームに参加し易い生活スタイルを持つユーザーを多く含むチーム同士をマッチングしたり、その時間帯にゲームに参加し難い生活スタイルを持つユーザーを多く含むチーム同士をマッチングしたりする等、ユーザーの生活スタイルに適したマッチングを行なうことが可能となる。

＜＜サーバー装置１０の構成＞＞
図２は、サーバー装置１０の機能上の構成を示すブロック図である。サーバー装置１０は、システム管理者等が各種サービスを運営・管理する際に利用する情報処理装置（例えば、ワークステーションやパーソナルコンピューター等）である。サーバー装置１０は、ユーザー端末２０から各種コマンドを受信すると、ユーザー端末２０上で動作可能なゲームプログラム・各種データや、ユーザー端末２０の規格に合わせたマークアップ言語（ＨＴＭＬ等）で作成されたＷｅｂページ等を送信する。本実施形態におけるサーバー装置１０は、制御部１１と、記憶部１２と、入力部１３と、表示部１４と、通信部１５を有している。

制御部１１は、各部間のデータの受け渡しを行うと共に、サーバー装置１０全体の制御を行うものであり、ＣＰＵ（Central Processing Unit）が所定のメモリに格納されたプログラムを実行することによって実現される。本実施形態における制御部１１は、少なくとも、アバターサービス制御部１１１と、メッセージサービス制御部１１２と、ゲームサービス制御部１１３と、エントリー処理部１１４と、マッチング処理部１１５と、サービス利用情報生成部１１６と、画面データ生成部１１７を備えている。

アバターサービス制御部１１１は、アバターサービスに関する各種処理を実行する機能を有している。本実施形態におけるアバターサービス制御部１１１は、ユーザー端末２０からのアバター作成要求を受け付けた際に、ユーザーの操作入力に従ってアバターを作成する制御を行ない、アバター変更要求を受け付けた際には、ユーザーの操作入力に従ってアバターのデザインを変更する制御を行なう。

メッセージサービス制御部１１２は、メッセージサービスに関する各種処理を実行する機能を有している。本実施形態におけるメッセージサービス制御部１１２は、送信側のユーザー端末２０からのメッセージ送信要求を受け付けることにより、受信側のユーザー端末２０に対してメッセージを送信する制御を行なう。

ゲームサービス制御部１１３は、各種ゲームプログラムに従ってゲームの進行を制御する機能を有している。本実施形態におけるゲームサービス制御部１１３は、ユーザーに対して提供可能な各種ゲームのうち、定期的に開催されるイベントが設定されたゲームにおいて、そのイベントが開催されるイベント期間中にイベントゲームの進行を制御する。イベントが開催されると、そのイベント期間中にイベントゲームが毎日行われる。このイベントゲームが行われる時間帯（以下、「イベント時間帯」とも呼ぶ）は、１日のうちに複数設定されている。図３は、イベント時間帯を説明するための図である。本実施形態では、図３に示すように、１日のうち、５時から１３時までが第１イベント時間帯、１３時から２０時までが第２イベント時間帯、２０時から２３時までが第３イベント時間帯として設定されている。そして、第１イベント時間帯のうち、１２時から１３時までがメイン時間帯、それ以外はサブ時間帯として設定されている。第２イベント時間帯では、１９時から２０時までがメイン時間帯となり、それ以外はサブ時間帯となる。第３イベント時間帯では、２２時から２３時までがメイン時間帯となり、それ以外はサブ時間帯となる。本実施形態におけるゲームサービス制御部１１３は、メイン時間帯に特別イベントゲームの進行を制御し、サブ時間帯には通常イベントゲームの進行を制御する。特別イベントゲームでは、マッチングされた相手チームと獲得ゲームポイントを競い合うチーム対戦が行われる。通常イベントゲームでは、チーム対戦ではなく、チーム単独での個別対戦が行われる。なお、特別イベントゲームでは、通常イベントゲームよりも多くのゲームポイントを獲得できるように設定されている。

エントリー処理部１１４は、イベントにおけるエントリーに関する各種処理を実行する機能を有している。本実施形態におけるエントリー処理部１１４は、イベントへの参加を希望するユーザーの参加登録を受け付ける。

マッチング処理部１１５は、イベントにおけるマッチングに関する各種処理を実行する機能を有している。本実施形態におけるマッチング処理部１１５は、エントリーされた複数ユーザーのそれぞれをいずれかのチームに所属させ、チームに所属する各ユーザーのイベント時間帯でのサービス利用状況に基づいて、そのイベント時間帯に互いに競い合う相手チームをマッチングする。すなわち、イベントゲームにおいてチーム対戦を同時プレイする相手となる複数ユーザーが、イベント時間帯でのサービス利用状況に基づいてマッチングされることになる。本実施形態では、イベント時間帯のうちのメイン時間帯に行われるチーム対戦の際に、マッチング処理が行われる。

サービス利用情報生成部１１６は、サービス利用状況からユーザーの生活スタイルを把握するためのサービス利用情報を生成する機能を有している。本実施形態におけるサービス利用情報生成部１１６は、各ユーザーの１日分のサービス利用状況に関するデータを複数日に亘って収集することによって、各ユーザーのサービス利用情報を生成する。

画面データ生成部１１７は、ゲーム画面をユーザー端末２０に表示させるための画面データを生成する処理を実行する機能を有している。本実施形態における画面データ生成部１１７は、ゲーム画面に対応する画面データとしてＨＴＭＬデータを生成する。

記憶部１２は、システムプログラムが記憶された読み取り専用の記憶領域であるＲＯＭ（Read Only Memory）と、制御部１１による演算処理のワーク領域として使用される書き換え可能な記憶領域であるＲＡＭ（Random Access Memory）とを有しており、例えば、フラッシュメモリやハードディスク等の不揮発性記憶装置によって実現される。本実施形態における記憶部１２は、アバターサービス情報記憶部１２１と、メッセージサービス情報記憶部１２２と、ゲームサービス情報記憶部１２３と、ユーザー情報記憶部１２４を有している。

アバターサービス情報記憶部１２１には、アバターサービスに関する情報であるアバターサービス情報が記憶されている。このアバターサービス情報には、標準アバター情報や衣装情報が含まれている。標準アバター情報には、基本パーツである標準アバターを識別するためのアバターＩＤに対応付けて、少なくとも、アバター名、アバター画像が設定されている。衣装情報には、標準アバターの衣装を識別するための衣装ＩＤに対応付けて、少なくとも、衣装名、衣装画像が設定されている。

メッセージサービス情報記憶部１２２には、メッセージサービスに関する情報であるメッセージサービス情報が記憶されている。このメッセージサービス情報には、メッセージを識別するためのメッセージＩＤに対応付けて、少なくとも、送信元のユーザーＩＤ、送信先のユーザーＩＤ、メッセージ送受信日時、メッセージ内容を示すテキスト情報が設定されている。

ゲームサービス情報記憶部１２３には、ゲームサービスに関する情報であるゲームサービス情報が記憶されている。図４は、ゲームサービス情報のデータ構造例を示す図である。このゲームサービス情報には、ゲームサービスを識別するためのゲームＩＤに対応付けて、少なくとも、ゲーム名、ゲーム種類、ゲーム関連情報が設定されている。なお、ゲーム関連情報のデータ構造については、追って詳述する。

ユーザー情報記憶部１２４には、ユーザーに関する情報であるユーザー情報が記憶されている。図５は、ユーザー情報のデータ構造例を示す図である。このユーザー情報には、ユーザーを識別するためのユーザーＩＤに対応付けて、少なくとも、ユーザー名、ログイン情報、アバター情報、マイゲーム情報、サービス利用情報が設定されている。ログイン情報は、サービス提供システムへのログイン状態を示す情報である。アバター情報は、ユーザーが標準アバターと衣装を組み合せることによって作成した自己のアバターに関する情報である。マイゲーム情報は、ユーザーによって「マイゲーム」に設定されゲームサービスに関する情報である。サービス利用情報は、ユーザーのサービス利用状況を示す情報である。なお、マイゲーム情報及びサービス利用情報のデータ構造については、追って詳述する。

入力部１３は、システム管理者等が各種データ（例えば、アバター情報やゲーム情報等）を入力するためのものであり、例えば、キーボードやマウス等によって実現される。

表示部１４は、制御部１１からの指令に基づいてシステム管理者用の操作画面を表示するためのものであり、例えば、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）等によって実現される。

通信部１５は、ネットワーク２を介してユーザー端末２０との間で各種情報の送受信を行うための送受信部として機能するものであり、例えば、ＮＩＣ（Network Interface Card）等によって実現されるものである。

＜ゲーム関連情報＞
ここでは、複数種類のゲームサービスのうち、イベントを開催するゲームサービスのゲーム関連情報について説明する。このゲーム関連情報には、キャラクター情報、エントリー情報、マッチング情報、チーム情報が含まれている。

図６は、キャラクター情報のデータ構造例を示す図である。キャラクター情報は、ゲームで用いられるキャラクターに関する情報である。このキャラクター情報には、キャラクターＩＤに対応付けて、少なくとも、キャラクター名、キャラクター画像、レアリティ、及び、最大攻撃力、最大防御力、最大体力、初期攻撃力、初期防御力、初期体力等の能力パラメーターが設定されている。

図７は、エントリー情報のデータ構造例を示す図である。エントリー情報は、イベントに参加登録されたユーザーに関する情報である。このエントリー情報には、エントリーＩＤに対応付けて、少なくとも、エントリーされた参加ユーザーのユーザーＩＤ、ユーザーがイベントゲームで用いるユーザーキャラクターのキャラクターＩＤが設定されている。

図８は、マッチング情報のデータ構造例を示す図である。マッチング情報は、マッチングされたチームに関する情報である。このマッチング情報には、マッチングＩＤに対応付けて、互いに競い合う相手となる２つのチームのチームＩＤが設定されている。

図９は、チーム情報のデータ構造例を示す図である。チーム情報は、複数ユーザーによって構成されたチームに関する情報である。このチーム情報には、チームＩＤに対応付けて、少なくとも、チーム名、所属ユーザー、ゲームポイント、勝利数（対戦数）が設定されている。所属ユーザーは、チームに所属する各ユーザーのユーザーＩＤを示す情報である。ゲームポイントは、今回のイベントで現時点までにチームが獲得したポイント量（各ユーザーが獲得したポイント量の合計）を示すパラメーター情報である。勝利数は、今回のイベントで現時点までにイベントゲームにてエネミーキャラクターに勝利した回数を示す情報である。対戦数は、今回のイベントで現時点までにエネミーキャラクターと対戦した回数を示す情報である。

＜マイゲーム情報＞
ここでは、ユーザーによって「マイゲーム」に設定された複数のゲームサービスのうち、イベントを開催するゲームサービスのマイゲーム情報について説明する。このマイゲーム情報には、図１０に示すように、今回のイベント成績（現時点におけるゲームポイント、勝利数）、前回のイベント成績（過去のゲームポイント、勝利数）、ゲームログイン情報、レベル、所有キャラクター情報等が含まれている。ゲームログイン情報は、ゲームサービスへのログイン状態を示す情報である。レベルは、現時点におけるユーザーのレベルを示す情報である。所有キャラクター情報は、ユーザーが所有するキャラクター（以下、「所有キャラクター」とも呼ぶ）に関する情報である。図１１は、所有キャラクター情報のデータ構造例を示す図である。この所有キャラクター情報には、所有キャラクターのキャラクターＩＤに対応付けて、少なくとも、現時点におけるレベル、攻撃力、防御力、体力等の各種パラメーターが設定されている。

＜サービス利用情報＞
図１２は、サービス利用情報のデータ構造例を示す図である。このサービス利用情報は、ユーザーが各種サービスを利用する度に記録されるログ情報を、ユーザー毎に蓄積したデータである。本実施形態におけるサービス利用情報には、ログＩＤに対応付けて、ユーザーがログインしたログイン日時、ユーザーがログアウトしたログアウト日時、ユーザーが利用した利用サービス等が、ユーザー毎に設定されている。このサービス利用情報を用いることで、例えば、朝早い時間帯にサービスを利用する傾向のあるユーザーであることや、夜遅い時間帯にサービスを利用する傾向のあるユーザーであること等、ユーザーのサービス利用状況から日々の生活スタイルを推測することができる。

＜＜ユーザー端末２０の構成＞＞
図１３は、ユーザー端末２０の機能上の構成を示すブロック図である。ユーザー端末２０は、ユーザーが所持し利用することができる情報処理装置（例えば、タブレット端末、携帯電話端末、スマートフォン等）である。ユーザー端末２０は、Ｗｅｂブラウザ機能を有しているため、サーバー装置１０から送信されたＷｅｂページ（ゲーム画面等）を画面表示することができる。本実施形態におけるユーザー端末２０は、ユーザー端末２０全体の制御を行う端末制御部２１と、各種データ・プログラムを記憶する端末記憶部２２と、ユーザーが操作入力を行うための端末操作部２３と、ゲーム画面・操作画面を表示する端末表示部２４と、サーバー装置１０との間で情報通信を行う端末通信部２５を有している。

＜＜サービス提供システム１の動作＞＞
＜ユーザー利用情報生成＞
本実施形態におけるサービス利用情報生成部１１６は、それぞれのユーザー端末２０から送信される各ユーザーのサービス利用状況に関するデータを受信する度に、図１２に示すサービス利用情報のデータ更新を行なう。以下では、ユーザー利用情報の生成について具体的に説明する。

例えば、ユーザー端末２０は、ユーザーによってログイン操作が行われ、アバター作成又は衣装変更するための操作が行われると、かかる操作情報に基づきアバター作成又は衣装変更を要求するコマンド（アバター処理要求）を、サーバー装置１０に送信する。また、ユーザー端末２０は、ユーザーによってログイン操作が行われ、メッセージを送信又は受信するための操作が行われると、かかる操作情報に基づきメッセージの送信又は受信を要求するコマンド（メッセージ処理要求）を、サーバー装置１０に送信する。また、ユーザー端末２０は、複数のマイゲームの中からいずれかのゲームが選択され、そのゲームへのログイン操作がユーザーによって行われると、かかる操作情報に基づきゲームへのログインを要求するコマンド（ゲーム処理要求）を、サーバー装置１０に送信する。

サーバー装置１０は、このようにしてユーザー端末２０から送信されたアバター処理要求、メッセージ処理要求、ゲーム処理要求など、各種の処理要求を受信する度に、サービス利用情報生成部１１６にサービス利用情報のデータ更新を行なわせる。すなわち、サービス利用情報生成部１１６は、各種の処理要求と共に受信したユーザーＩＤに基づき、図５に示すユーザー情報を参照することにより、そのユーザーのサービス利用情報を特定する。そして、サービス利用情報生成部１１６は、その特定されたサービス利用情報の必要項目についてデータ更新を行なう。

このようにサービス利用情報生成部１１６は、イベント開催前の複数週間に亘り各ユーザーの１日分のサービス利用状況に関するデータを収集することによってサービス利用情報を生成する。本実施形態では、イベント開催前の少なくとも直近４週間に亘ってデータ収集が行われる。

＜マッチング＞
ここでは、本実施形態におけるサービス提供システム１のマッチングに関する動作例について、図１４及び図１５を用いて説明する。図１４は、マッチングについての動作例を説明するためのフローチャートである。図１５は、各ユーザーのサービス利用頻度について説明する図である。

先ず、マッチング処理部１１５は、制御部１１に内蔵されるタイマーによってカウントすることで、イベントゲームが行われる時間帯の所定時間前に設定された準備時刻になったか否かを判定する（ステップＳ１０１）。本実施形態では、イベント時間帯のうちのメイン時間帯に行なわれる特別イベントゲーム（チーム対戦）のためにマッチングが行われるので、メイン時間帯の１時間前に準備時刻が設定されている。そのため、例えば、第１イベント時間帯においては、メイン時間帯が１２時から１３時に設定されているので（図３参照）、準備時刻である１１時になったか否かが判定されることになる。そして、未だ準備時刻になっていないと判定された場合は（ステップＳ１０１：ＮＯ）、その時刻になるまで待機する。その一方で、準備時刻になったと判定された場合には（ステップＳ１０１：ＹＥＳ）、次のステップＳ１０２へ処理を進める。

次いで、マッチング処理部１１５は、各ユーザーによるサービスの利用頻度をそれぞれカウントする（ステップＳ１０２）。本実施形態では、図１２に示すサービス利用情報を用いることにより、各チームに所属する各ユーザーのサービス利用頻度がそれぞれカウントされる。

具体的には、図１５に示すように、特別イベントゲーム（チーム対戦）が行われる曜日毎の各イベント時間帯における各ユーザーのサービス利用頻度がカウントされる。ここでは、月曜日の第１イベント時間帯のうちのメイン時間帯でのサービス利用頻度を「ａ」、月曜日の第２イベント時間帯のうちのメイン時間帯でのサービス利用頻度を「ｂ」、月曜日の第３イベント時間帯のうちのメイン時間帯でのサービス利用頻度を「ｃ」、・・・、日曜日の第２イベント時間帯のうちのメイン時間帯でのサービス利用頻度を「ｔ」、日曜日の第３イベント時間帯のうちのメイン時間帯でのサービス利用頻度を「ｕ」として変数を設定する。そして例えば、月曜日の第１イベント時間帯のうちのメイン時間帯でのサービス利用頻度「ａ」をカウントする場合、マッチング処理部１１５は、図１２に示すサービス利用情報を参照して、イベント開催前の直近４週間のうち、毎週月曜日の第１イベント時間帯のうちのメイン時間帯でのサービス利用頻度をユーザー毎にカウントする。その結果、全ての月曜日の第１イベント時間帯のうちのメイン時間帯に、いずれのサービスも利用されていなかった場合は、「ａ」に０を代入する（つまり「ａ＝０」となる）。いずれか１週だけ月曜日の第１イベント時間帯のうちのメイン時間帯に、少なくとも１回いずれかのサービスが利用された場合は、「ａ」に１を代入する（つまり「ａ＝１」となる）。いずれか２週だけ月曜日の第１イベント時間帯のうちのメイン時間帯に、少なくとも１回いずれかのサービスが利用された場合は、「ａ」に２を代入する（つまり「ａ＝２」となる）。いずれか３週だけ月曜日の第１イベント時間帯のうちのメイン時間帯に、少なくとも１回いずれかのサービスが利用されていた場合は、「ａ」に３を代入する（つまり「ａ＝３」となる）。全ての月曜日の第１イベント時間帯のうちのメイン時間帯に、少なくとも１回いずれかのサービスが利用されていた場合は、「ａ」に４を代入する（つまり「ａ＝４」となる）。このようにして、すべての変数「ａ」〜「ｕ」に対して０〜４のいずれかの数値が代入されることにより、特別イベントゲーム（チーム対戦）が行われる曜日毎の各イベント時間帯（各メイン時間帯）における各ユーザーのサービス利用頻度がカウントされることになる。

このことによって、このイベントが設定された当該ゲームサービスの利用状況のみならず、その他のゲームサービス、アバターサービス、メッセージサービス等、すべてのサービスの利用状況から、ユーザーの生活スタイルを推測することができる。つまり、イベント時間帯（メイン時間帯）にいずれかのサービスを利用する傾向のあるユーザーであれば、そのイベント時間帯（メイン時間帯）に特別イベントゲーム（チーム対戦）に参加し易い生活スタイルを持つユーザーであると推測することが可能となる。また逆に、イベント時間帯（メイン時間帯）にいずれのサービスも利用しない傾向のあるユーザーであれば、そのイベント時間帯（メイン時間帯）に特別イベントゲーム（チーム対戦）に参加し難い生活スタイルを持つユーザーであると推測することが可能となる。

図１４に戻り、次いで、マッチング処理部１１５は、各ユーザーのポテンシャル値をそれぞれ算出する（ステップＳ１０３）。このポテンシャル値とは、イベントゲーム（チーム対戦）が行われる曜日のイベント時間帯（メイン時間帯）に貢献できる潜在能力を数値化したものである。本実施形態では、ユーザーのサービス利用頻度、及び、ユーザーの前回のイベント成績（ここでは、ユーザーが過去に獲得したゲームポイント）を用いることにより、各チームに所属する各ユーザーのポテンシャル値がそれぞれ算出される。

例えば、月曜日の第１イベント時間帯のうちのメイン時間帯でのマッチング時には、過去の獲得ゲームポイントを「ｐｔ」とし、曜日毎の各イベント時間帯（各メイン時間帯）でのサービス利用頻度を「ａ」〜「ｕ」とすると、ポテンシャル「ｐｏ」は、以下の算出式により求めることができる。

なお、過去の獲得ゲームポイント「ｐｔ」は、図１０に示すマイゲーム情報を参照することによって特定することができる。また、曜日毎の各イベント時間帯（各メイン時間帯）でのサービス利用頻度「ａ」〜「ｕ」は、上述したステップＳ１０２の処理によって求めることができる。

このような算出式を用いることによって、特別イベントゲーム（チーム対戦）が行われる曜日毎の各イベント時間帯（各メイン時間帯）における各ユーザーのポテンシャル値「ｐｏ」が算出されることになる。

次いで、マッチング処理部１１５は、各チームのポテンシャル値をそれぞれ算出する（ステップＳ１０４）。チームのポテンシャル値は、そのチームに所属する各ユーザーのポテンシャル値を合算したものである。本実施形態では、各チームが２０人のユーザーによって構成されているため、各チームのポテンシャル値「ＰＯ」は以下の算出式により求めることができる。

次いで、マッチング処理部１１５は、各チームのポイント獲得能力値をそれぞれ算出する（ステップＳ１０５）。ポイント獲得能力値とは、特別イベントゲーム（チーム対戦）でゲームポイントを獲得できるだろうと見込まれるチーム力の高さを数値化したものである。本実施形態では、チームのポテンシャル値、及び、チームの前回のイベント成績（ここでは、チームの過去に獲得したゲームポイント）を用いることにより、各チームのポイント獲得能力値がそれぞれ算出される。そして、チームの過去の獲得ゲームポイントを「ＰＴ」とし、係数を「α」とすると、ポイント獲得能力値「Ｘ」は、以下の算出式により求めることができる。

なお、チームの過去の獲得ゲームポイント「ＰＴ」は、チーム内の各ユーザーの過去の獲得ゲームポイント「ｐｔ」を合算することによって求めることができる。また、係数「α」は予め決定された定数となる。

次いで、マッチング処理部１１５は、特別イベントゲーム（チーム対戦）で互いに競い合う相手チームを決定する（ステップＳ１０６）。本実施形態では、チームのポイント獲得能力値、及び、チームの勝利数を用いることにより、相手チームが決定される。チームのポイント獲得能力値は、上述したステップＳ１０５の処理によって求めることができる。また、チームの勝利数は、図９に示すチーム情報を参照することによって特定することができる。なお、チームの勝利数については、特別イベントゲームの勝利数のみを用いても良い。また、チームのポイント獲得能力値のみを用いて相手チームを決定しても良い。

具体的には、先ず、本実施形態におけるマッチング処理部１１５は、各チームの勝利数に基づき、マッチング候補となる相手チームを決定する。例えば、勝利数が同程度のチームがマッチング候補として決定される。そして次に、マッチング処理部１１５は、マッチング候補となるチーム内で、各チームのポイント獲得能力値「Ｘ」を比較することによって、特別イベントゲーム（チーム対戦）で互いに競い合う相手チームを決定する。例えば、比較の結果、ポイント獲得能力値「Ｘ」が近い数値を持つチーム同士をマッチングする。これにより、そのイベント時間帯に参加し易い生活スタイルを持つユーザーを多く含むチーム同士、及び、そのイベント時間帯に参加し難い生活スタイルを持つユーザーを多く含むチーム同士の少なくとも一方がマッチングされることになる。

次いで、マッチング処理部１１５は、次のイベント時間帯が残っているか否かを判定する（ステップＳ１０７）。そして、かかる判定が肯定された場合は（ステップＳ１０７：ＹＥＳ）、ステップＳ１０１の処理に戻り、それ以降の処理が繰り返し行われる。その一方で、かかる判定が否定された場合には（ステップＳ１０７：ＮＯ）、この処理を終了する。

以上のとおり、本実施形態に係るサービス提供システム１によれば、各チームに所属する各ユーザーのサービス利用情報を用いてマッチング処理が行われることによって、１日のうちのイベントゲーム（特別イベントゲーム）が行われるイベント時間帯（メイン時間帯）での各ユーザーのサービス利用状況に基づき、イベントゲーム（特別イベントゲーム）で獲得ゲームポイントを競い合うチーム（イベントゲームを同時プレイできる複数ユーザー）がマッチングされる。これにより、ユーザーのサービス利用状況から生活スタイル（可処分時間）が推測できるため、イベント時間帯にイベントゲームに参加し易い生活スタイルを持つ複数ユーザーをマッチングする等、ユーザーの生活スタイルに適したマッチングを行なうことが可能となる。その結果として、ユーザーの参加率を上昇させることができるため、多人数参加型のイベントゲームの興趣を向上させることが可能となる。

＝＝＝その他の実施形態＝＝＝
上記の実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物も含まれる。特に、以下に述べる実施形態であっても、本発明に含まれるものである。

＜イベントゲーム＞
上記の本実施形態では、イベントゲームが、イベント時間帯のうちのメイン時間帯に行なわれる特別イベントゲーム（チーム対戦）と、イベント時間帯のうちのサブ時間帯に行なわれる通常イベントゲーム（チーム単独での個別対戦）とから構成される場合を例に挙げて説明したが、本発明はこれに限定されるものではない。例えば、イベントゲームが、イベント時間帯のうちのメイン時間帯に行なわれる特別イベントゲームのみから構成されても良い。
また上記の本実施形態では、イベントゲームが１日に複数回行われる場合を例に挙げて説明したが、本発明はこれに限定されるものではない。例えば、毎週月曜は１２時〜１３時、毎週火曜日は１９時〜２０時といったように、曜日毎に（１日毎に）異なる時間帯にイベントゲームを行なっても良い。また例えば、イベント開催期間中において、１日に１回だけイベントゲームを行なっても良いし、２日に１回だけイベントゲームを行なっても良い。ただし、このときのイベント時間帯は、１日のうちの限られた短時間（例えば１時間）に設定される。

＜マッチング＞
上記の本実施形態におけるマッチング処理では、イベントゲームがチーム単位（団体）で行われ、イベントゲームのうちの特別イベントゲームを行なうチーム（複数ユーザー）をマッチングする場合を例に挙げて説明したが、本発明はこれに限定されるものではない。例えば、イベントゲームがユーザー単位（個人）で行われ、特別イベントゲームを行なうユーザー同士（複数ユーザー）をマッチングする場合にも、かかるマッチング処理を適用しても良い。

＜サービス利用頻度＞
上記の本実施形態では、準備時刻になったと判定された場合に（図１４のステップＳ１０１：ＹＥＳ）、各ユーザーのサービス利用頻度をカウントすること（図１４のステップＳ１０２）を例に挙げて説明したが、本発明はこれに限定されるものではない。例えば、準備時刻よりも前に任意のタイミングでサービス利用頻度をカウントしても良い。
また上記の本実施形態では、イベント開催前の直近４週間でのサービス利用情報を参照して、サービス利用頻度をユーザー毎にカウントする場合を例に挙げて説明したが、本発明はこれに限定されるものではない。例えば、イベント開催前の１年間でのサービス利用頻度をカウントしても良い。また例えば、過去に同一のイベントが開催された期間でのサービス利用頻度をカウントしても良い。

＜応援依頼＞
上記の本実施形態では、チームに所属する或るユーザーが他のユーザーに対して応援依頼を行なうことも可能である。この際、チームに所属する各ユーザーのサービス利用情報を参照することにより、チームに所属する複数ユーザーのうち、イベント時間帯にイベントゲームに参加し易い生活スタイルを持つと推測される他のユーザーに対して、応援依頼を行なっても良い。

具体的には、ユーザー端末２０は、依頼元となるユーザーの操作により応援依頼ボタンが選択されると、応援依頼要求をサーバー装置１０へ送信する。サーバー装置１０は、ユーザー端末２０から送信された応援依頼要求を受信すると、図９に示すチーム情報に基づき依頼元のユーザーが所属するチームを特定し、その特定されたチームに所属する各ユーザーのサービス利用情報（図１２参照）を参照する。そして、サーバー装置１０は、各ユーザーのサービス利用情報に基づき、そのイベント時間帯にサービス利用頻度の高い他のユーザーを、そのチームに所属する複数ユーザーの中から選択する。そして、サーバー装置１０は、その選択された他のユーザーのユーザー端末２０に対して、特別イベントゲーム（チーム対戦）に参加可能であることを示す参戦情報を、メッセージ送信する。

＜サーバー装置＞
上記の本実施形態では、サーバー装置の一例として１台のサーバー装置１０を備えたサービス提供システム１を例に挙げて説明したが、これに限らず、サーバー装置の一例として複数台のサーバー装置１０を備えたサービス提供システム１としても良い。すなわち、複数台のサーバー装置１０がネットワーク２を介して接続され、各サーバー装置１０が各種処理を分散して行うようにしてもよい。例えば、アバターサービスサーバー、メッセージサービスサーバー、ゲームサービスサーバー、ユーザー管理サーバー等を含むサービス提供システム１を用いても良い。

＜情報処理装置＞
上記の本実施形態におけるサービス提供システム１では、ゲームプログラムに基づきサーバー装置１０及びユーザー端末２０を協働させて各種情報処理を実行する場合を例に挙げて説明したが、これに限定されるものではなく、情報処理装置としてのユーザー端末２０単体、または、サーバー装置１０単体が、ゲームプログラムに基づき上記の各種情報処理を実行するようにしてもよい。
また、情報処理装置としての機能の一部をユーザー端末２０が担う構成としてもよい。この場合には、サーバー装置１０及びユーザー端末２０が情報処理装置を構成する。
なお、情報処理装置はプロセッサー及びメモリを備えるコンピューターの一例である。

１ サービス提供システム、２ ネットワーク、１０ サーバー装置、１１ 制御部、１２ 記憶部、１３ 入力部、１４ 表示部、１５ 通信部、２０ ユーザー端末、２１ 端末制御部、２２ 端末記憶部、２３ 端末入力部、２４ 端末表示部、２５ 端末通信部、１１１ アバターサービス制御部、１１２ メッセージサービス制御部、１１３ ゲームサービス制御部、１１４ エントリー処理部、１１５ マッチング処理部、１１６ サービス利用情報生成部、１１７ 画面データ生成部、１２１ アバターサービス情報記憶部、１２２ メッセージサービス情報記憶部、１２３ ゲームサービス情報記憶部、１２４ ユーザー情報記憶部

Claims (2)

1. 各ユーザーが利用することのできる各種サービスに含まれるゲームサービスにおいて、１日に複数設定された所定時間帯に行われる多人数参加型ゲームの進行を制御するゲームサービス制御部と、
   各ユーザーによる前記各種サービスの利用のうち、前記ゲームサービスの利用のみならず、前記ゲームサービス以外の他のサービスの利用に基づき、各ユーザーの１日分のサービス利用状況に関するデータを複数週間に亘って収集することによって生成された各ユーザーのサービス利用情報、及び、既に行われた前記多人数参加型ゲームで各ユーザーが獲得したゲームポイントを記憶する記憶部と、
   各ユーザーの前記サービス利用情報を参照して、前記多人数参加型ゲームが行われる曜日毎の各所定時間帯における各ユーザーの各種サービスの利用頻度をカウントし、
   各ユーザーの前記各種サービスの利用頻度、及び、各ユーザーが過去に獲得した前記ゲームポイントを用いて、前記多人数参加型ゲームが行われる曜日の所定時間帯における各ユーザーのポテンシャル値を算出し、
   各ユーザーの前記ポテンシャル値に基づいて、曜日毎の各所定時間帯に行なわれる前記多人数参加型ゲームを同一時間帯にプレイできる複数のユーザーをそれぞれマッチングするマッチング処理部と、
   を備えたことを特徴とする情報処理装置。
2. コンピューターに、
   各ユーザーが利用することのできる各種サービスに含まれるゲームサービスにおいて、１日に複数設定された所定時間帯に行われる多人数参加型ゲームの進行を制御するゲームサービス制御処理と、
   各ユーザーによる前記各種サービスの利用のうち、前記ゲームサービスの利用のみならず、前記ゲームサービス以外の他のサービスの利用に基づき、各ユーザーの１日分のサービス利用状況に関するデータを複数週間に亘って収集することによって生成された各ユーザーのサービス利用情報、及び、既に行われた前記多人数参加型ゲームで各ユーザーが獲得したゲームポイントを記憶部に記録する記録処理と、
   各ユーザーの前記サービス利用情報を参照して、前記多人数参加型ゲームが行われる曜日毎の各所定時間帯における各ユーザーの各種サービスの利用頻度をカウントし、
   各ユーザーの前記各種サービスの利用頻度、及び、各ユーザーが過去に獲得した前記ゲームポイントを用いて、前記多人数参加型ゲームが行われる曜日の所定時間帯における各ユーザーのポテンシャル値を算出し、
   各ユーザーの前記ポテンシャル値に基づいて、曜日毎の各所定時間帯に行なわれる前記多人数参加型ゲームを同一時間帯にプレイできる複数のユーザーをそれぞれマッチングするマッチング処理と、
   を実行させることを特徴とするゲームプログラム。

Images