以下、図面を参照して本発明の実施形態について詳細に説明する。以下に説明する実施形態においては、本発明が、所定競技の試合の結果を予想してオンラインでの投票を可能とするシステムに適用される。投票により予想が的中したユーザは、例えば当せん金等の何らかの価値を有するものを受け取ることができる。本発明が適用される競技は、2以上の競技主体により試合が行われるタイプの競技であって、当該国の法律等において投票が許可されているものであれば特に限定されない。そのような競技の例として、スポーツがある。スポーツの例として、サッカー、バスケットボール、野球、テニス等が挙げられる。所定競技の他の例として、スポーツ以外のゲームがある。ゲームの例として、コンピュータゲーム、ビデオゲーム、ボードゲーム等が挙げられる。競技主体は、競技を行う主体である。競技主体の例として、チーム、プレーヤー、ペア等が挙げられる。投票によって、競技主体に関する何かを予想することが一般的である。例えば、勝利する方の競技主体や、各競技主体が獲得するスコア等が予想可能である。以下では、サッカー及びバスケットボールの試合の結果に投票可能なスポーツ振興くじに本発明が適用された場合の実施形態について説明する。また以下では、日本のプロリーグに所属するチーム同士が対戦する試合についてくじが販売される場合について主に説明する。しかしながら、例えば日本以外の国のプロリーグに所属するチーム同士が対戦する試合、互いに異なる国に所属するプロチーム同士が対戦する国際試合、又は互いに異なる国の代表チーム同士が対戦する国際試合について、本発明が適用されてもよい。
[1.第1実施形態]
[1-1.投票システムの構成]
先ず、本実施形態に係る投票システムSの構成及び機能概要について、図1及び図2を用いて説明する。図1は、本実施形態に係る投票システムSの概要構成の一例を示す図である。
図1に示すように、投票システムSは、センターサーバ1と、複数のユーザ端末2と、を備える。センターサーバ1と各ユーザ端末2とは、ネットワークNWを介して互いに接続される。ネットワークNWは、例えばインターネット、専用通信回線(例えば、CATV(Community Antenna Television)回線)、移動体通信網(基地局等を含む)、及びゲートウェイ等により構築されている。
センターサーバ1は、投票サイトに関する各種処理を実行する。投票サイトは、スポーツ振興くじを販売するウェブサイトである。投票サイトを利用することで、各ユーザは、サッカーやバスケットボールの試合の結果に対して投票することができる。投票サイトに関する処理として、センターサーバ1は、例えばユーザが投票するための処理を実行したり、くじの対象となる試合に関する情報を提供したりする。ユーザが購入可能なくじの種類の例として、複数試合勝利チーム選択方式、複数試合得点選択方式、単一試合得点選択方式等が挙げられる。複数試合勝利チーム選択方式は、予め定められた数の試合(例えば5試合、13試合等)のそれぞれについて勝利する方のチームを予想する方式である。複数試合得点選択方式は、予め定められた複数の試合(例えば、2試合、3試合等)のそれぞれについて、両チームそれぞれの得点若しくは両チーム間の得点差を予想する方式である。単一試合得点選択方式は、単一の試合について、両チームそれぞれの得点若しくは両チーム間の得点差を予想する方式である。本実施形態においては、主として単一試合得点選択方式について説明する。なお、単一試合得点選択方式を、1試合予想ともいう。センターサーバ1が提供する情報としては、例えばくじの対象となる試合の一覧、各試合の詳細な情報、及びその他の情報がある。試合の一覧の例として、対応するくじの販売締切まで間もない試合の一覧、対応するくじが現在販売中の試合の一覧、日程別の試合の一覧等がある。サッカーとバスケットボールとで、試合の一覧を表示する画面が別々に存在してもよい。各試合の詳細な情報の例として、基本情報、オッズ情報、過去データ、及びくじ結果が挙げられる。基本情報は、例えば、くじの対象の試合で対戦するチームの過去の対戦成績、その対戦チームそれぞれの直近所定数の試合の結果、対象の試合のスターティングメンバー等のうち、少なくとも一つを含んでもよい。オッズ情報は、くじで投票可能な両チームの得点の組み合わせ若しくは両チーム間の得点差それぞれの現在のオッズを含んでもよい。過去データは、対象の試合で対戦するチームの過去の対戦において比較的に多かった得点の組み合わせ若しくは得点差の一覧を含んでもよい。くじ結果は、情報提供先のユーザが対象の試合のくじでの選択状況、くじの結果、得点の組み合わせ若しくは得点差ごとの確定したオッズのうち、少なくとも一つを含んでもよい。
センターサーバ1は、更にくじの購入を促すための処理を実行する。例えば、センターサーバ1は、各ユーザについて、サッカーチーム又はバスケットボールチームのうち、そのユーザが応援するチームを推定してもよい。そして、センターサーバ1は、ユーザが応援するチームが行う試合を示す投票推奨試合情報を、そのユーザのユーザ端末2へ送信してもよい。投票推奨試合情報は、対象の試合で対戦する両チームを識別する情報(例えばチーム名、愛称、マーク等)を少なくとも含んでもよい。投票推奨試合情報は、対象の試合のくじの購入(投票)をユーザに促す情報を含んでもよいし含まなくてもよい。ユーザ端末2は、受信した投票推奨試合情報を画面に表示する。投票推奨試合情報は、例えば試合の一覧を表示する画面に表示されてもよいし、その他の画面に表示されてもよい。ユーザは、ユーザ端末2を操作することにより、投票推奨試合情報により示される試合のくじで投票するための画面を表示させることができる。ユーザが応援する蓋然性があるチームにより行われる試合に関する情報が表示されるので、その試合のくじの購入をユーザに促すことができる。
図2は、投票推奨試合情報の表示例を示す図である。図2に示す1試合予想トップ画面100は、サッカー及びバスケットボールの両方を含む1試合予想の入り口であると言うことができる画面である。1試合予想トップ画面100は、例えばサッカー及びバスケットボールそれぞれに専用の1試合予想トップ画面へのリンクを含んでもよい。また、1試合予想トップ画面100は、対応するくじの販売締切が間近である試合の一覧を含んでもよい。更に1試合予想トップ画面100は、投票推奨試合一覧110を含む。投票推奨試合一覧110は、例えば複数の投票推奨試合情報111を含む。各投票推奨試合情報は、対象の試合で対戦するチームそれぞれの名称を含む。また、投票推奨試合情報111は、対戦するチームの何れがホームチームで何れがアウェーチームであるかを示す情報を含んでもよい。ホームチームは、対象の試合が行われる競技場を本拠とするチームである。アウェーチームは、ホームチームではない方のチームである。また、投票推奨試合情報111は、対戦するチームそれぞれの現在の順位を含んでもよい。また、投票推奨試合情報111は、対象の試合の競技がサッカーであるか又はバスケットボールであるかを示す情報(例えば、アイコン、スポーツ名等)を含んでもよい。また、投票推奨試合情報111は、対象の試合のくじの販売締切日時を含んでもよい。図2の例では、3個の投票推奨試合情報111が表示されている。ユーザは、例えばスワイプすることにより、現在表示されている投票推奨試合情報111以外の投票推奨試合情報を表示させることが可能であってもよい。スワイプとは、タッチパネルの画面に指を付けながら、その指を或る方向に移動させる行為である。
また、ユーザは、各投票推奨試合情報111に関連付けて所定の操作することにより、その投票推奨試合情報111により示される試合のくじに対応する投票画面を表示させることが可能である。例えば投票推奨試合情報111をタップすることにより投票画面が表示される。タップとは、タッチパネルの画面の或る箇所に指で触れてその後その指を画面から離す行為である。投票画面には、投票可能な得点の組み合わせ若しくは得点差としての選択肢ごとに、投票領域が表示される。各投票領域は、対応する得点の組み合わせ若しくは得点差、現在のオッズ、口数入力欄、マイナスボタン、プラスボタン、及び払戻想定金額が表示されてもよい。口数入力欄は、購入するくじの数(口数)をユーザが入力するための領域である。マイナスボタンは、口数入力欄に表示されている口数を1減少させるためのボタンである。プラスボタンは、口数入力欄に表示されている口数を1増加させるためのボタンである。ユーザは、口数入力欄に直接口数を入力してもよいし、マイナスボタンやプラスボタンを押下することにより、口数入力欄に口数を入力してもよい。払戻想定金額は、当せんしたときにユーザに払い戻されることが想定される金額として、口数入力欄に表示されている口数及び現在のオッズで計算した金額である。投票画面には、更にカート追加ボタンが表示される。カート追加ボタンは、口数入力欄に1口以上の口数を入力した選択肢にユーザが投票することを指定して、対象のくじをその口数分、所定のカートに入れる(または追加する)ためのボタンである。このカートは、オンラインショッピングにおけるショッピングカートに類似する機能を有する。ユーザがこのカートを選択すると、カートに入れられたくじの一覧が画面に表示される。このときに所定の操作をすることにより、ユーザは、カートに入れられているくじを購入することができる。すなわち、実際に投票が行われる。
各ユーザ端末2は、投票サイトを利用可能なユーザにより利用される携帯可能な端末装置である。ユーザ端末2の例として、パーソナルコンピュータ、スマートフォン、タブレット式コンピュータ等の携帯情報端末、携帯電話機、PDA(Personal Digital Assistant)、セットトップボックス等が挙げられる。ユーザ端末2が携帯用の端末装置である場合、そのユーザ端末2には、投票サイト専用のアプリケーションがインストールされてもよい。このアプリケーションを利用して、ユーザは、くじを購入したり、くじや試合に関する情報を閲覧したりすることができる。このアプリケーションは、例えばセンターサーバ1又は所定のアプリケーション配信プラットフォームからダウンロード可能であってもよい。また各ユーザ端末2には、ウェブブラウザがインストールされていてもよい。ウェブブラウザを利用して、ユーザはくじの購入等が可能であってもよい。
[1-2.センターサーバの構成]
次に、センターサーバ1の構成について、図3及び図4を用いて説明する。図3は、本実施形態に係るセンターサーバ1の概要構成の一例を示すブロック図である。図3に示すように、センターサーバ1は、システム制御部11と、システムバス12と、入出力インタフェース13と、記憶部14と、通信部15と、を備えている。システム制御部11と入出力インタフェース13とは、システムバス12を介して接続されている。
システム制御部11は、CPU(Central Processing Unit)11a、ROM(Read Only Memory)11b、RAM(Random Access Memory)11c等により構成されている。
入出力インタフェース13は、記憶部14及び通信部15とシステム制御部11との間のインタフェース処理を行う。
記憶部14は、例えば、ハードディスクドライブ等により構成されている。この記憶部14には、例えば会員DB14a、チームDB14b、お気に入りチームDB14c、試合DB14d、くじDB14e、オッズDB14f、くじ結果DB14g、閲覧履歴DB14h、購入履歴DB14i、応援チームDB14j等のデータベースが記憶されてもよい。「DB」は、データベースの略語である。なお、本実施形態においては、サッカーに関する情報とバスケットボールに関する情報とが同一のデータベースに記憶されているが、別々のデータベースに記憶されてもよい。
図4は、データベースに記憶される情報の一例を示す図である。会員DB14aには、投票サイトを利用可能なユーザに関する会員情報が、ユーザごとに記憶される。具体的に、会員DB14aには、会員情報として、ユーザID、氏名、住所、電話番号、電子メールアレス等が、互いに関連付けて記憶される。ユーザIDは、ユーザを識別する識別情報である。
チームDB14bには、日本国内のプロサッカーリーグ及びプロバスケットボールリーグそれぞれに所属する各チームに関するチーム情報が記憶される。具体的に、チームDB14bには、チーム情報として、競技種別、チームID、チーム名、本拠地名等が、互いに関連付けて記憶されてもよい。競技種別は、対象のチームの競技がサッカー及びバスケットボールの何れであるかを示す情報である。チームIDは、対象のチームを識別する識別情報である。本拠地名は、対象のチームが本拠とする場所の地名を示す。チームが本拠とする場所は、そのチームが本拠とする競技場がある場所であってもよい。本拠地名は、例えば都市名又は市区町村名で示されてもよい。
お気に入りチームDB14cには、プロサッカーリーグ又はプロバスケットボールリーグに所属するチームのうち、ユーザのお気に入りとしてそのユーザにより登録されたチームに関する情報が、ユーザと競技との組み合わせごとに記憶される。ユーザは、投票サイトを利用して、お気に入りのチームを登録することができる。具体的に、お気に入りチームDB14cには、ユーザID、競技種別、及びお気に入りチームID等が、互いに関連付けて記憶されてもよい。ユーザIDは、対象のユーザを示す。競技種別は、対象の競技を示す。お気に入りチームIDは、対象のユーザが対象の競技でお気に入りに登録したチームのチームIDである。1人のユーザに対して複数のお気に入りチームIDが記憶されてもよい。
試合DB14dには、サッカー及びバスケットボールの試合に関する試合情報が、試合ごとに記憶される。具体的に、試合DB14dには、試合情報として、競技種別、試合ID、試合日、試合開始時刻、ホームチームID、アウェーチームID等が、互いに関連付けて記憶されてもよい。競技種別は、対象の試合の競技が、サッカー及びバスケットボールの何れであるかを示す。試合IDは、対象の試合を識別する識別情報である。試合日は、対象の試合が行われる日である。試合開始時刻は、対象の試合が開始される時刻である。ホームチームIDは、対象の試合に出場するホームチームのチームIDである。アウェーチームIDは、対象の試合に出場アウェーチームのチームIDである。
くじDB14eには、各くじに関する基本的な情報を示すくじ情報が記憶される。具体的に、くじDB14eには、くじ情報として、競技種別、くじID、試合ID、ホームチームID、アウェーチームID、販売期間等が、互いに関連付けて記憶されてもよい。競技種別は、対象のくじが対応する試合の競技が、サッカー及びバスケットボールの何れであるかを示す。くじIDは、対象のくじを識別する識別情報である。試合IDは、対象のくじで投票の対象となる試合を示す。ホームチームIDは、対象の試合に出場するホームチームのチームIDである。アウェーチームIDは、対象の試合に出場アウェーチームのチームIDである。販売期間は、対象のくじが販売される期間を示す。例えば、対象の試合の一週間前からその試合の開始時刻の所定時間前までの間に、くじが販売されてもよい。
オッズDB14fには、試合の結果としてくじで投票可能な選択肢に対する最新のオッズが、くじと選択肢との組み合わせごとに記憶される。具体的に、オッズDB14fには、くじID、選択肢情報及びオッズ等が、互いに関連付けて記憶されてもよい。くじIDは、対象のくじを示す。選択肢情報は、対象の選択肢を示す。サッカーの場合、選択肢は、ホームチームの得点とアウェーチームの得点との組み合わせであってもよい。具体的に、サッカーの選択肢情報は、得点の組み合わせとして、例えば「0-0」、「0-1」、「0-2」、「0-3」、「1-0」、「1-2」、「1-3」、「1-4」、「2-0」、「2-1」、「2-2」、「2-3」、「3-0」、「3-1」、「3-2」、「3-3」、「ホームチームが4点以上獲得してホームチーム勝利」、「アウェーチームが4点以上獲得してアウェーチーム勝利」のうち何れかを示してもよい。ここで、「ホームチームが4点以上獲得してホームチーム勝利」は、ホームチームが4点以上を獲得してホームチームが勝利する得点の組み合わせであれば、何れの組み合わせであってもよいことを示す。「アウェーチームが4点以上獲得してアウェーチーム勝利」は、アウェーチームが4点以上を獲得してアウェーチームが勝利する得点の組み合わせであれば、何れの組み合わせであってもよいことを示す。バスケットボールの場合、選択肢は、ホームチームの得点とアウェーチームの得点との差であってもよい。具体的に、バスケットボールの選択情報は、例えば「1~3点差でホームチーム勝利」、「4~6点差でホームチーム勝利」、「7~9点差でホームチーム勝利」、「10~12点差でホームチーム勝利」、「13~15点差でホームチーム勝利」、「16~18点差でホームチーム勝利」、「19~22点差でホームチーム勝利」、「23点差以上でホームチーム勝利」、「1~3点差でアウェーチーム勝利」、「4~6点差でアウェーチーム勝利」、「7~9点差でアウェーチーム勝利」、「10~12点差でアウェーチーム勝利」、「13~15点差でアウェーチーム勝利」、「16~18点差でアウェーチーム勝利」、「19~22点差でアウェーチーム勝利」、「23点差以上でアウェーチーム勝利」のうち何れかを示してもよい。オッズDB14fに記憶される各オッズは、現時点で最新又は最終のオッズであってもよい。例えば、センターサーバ1は、現在販売中の各くじについて、オッズを管理する所定のサーバ装置から定期的に最新のオッズを取得してもよい。そしてセンターサーバ1は、取得されたオッズでオッズDB14fのオッズを更新してもよい。
くじ結果DB14gには、くじの結果を示すくじ結果情報が、くじごとに記憶される。具体的に、くじ結果DB14gには、くじ結果情報として、競技種別、くじID、試合ID、ホームチーム得点、アウェーチーム得点、及び結果情報等が、互いに関連付けて記憶されてもよい。競技種別は、対象のくじが対応する試合の競技が、サッカー及びバスケットボールの何れであるかを示す。くじIDは、対象のくじを示す。試合IDは、対象のくじで投票の対象となる試合を示す。ホームチーム得点は、対象の試合でホームチームが実際に獲得した得点を示す。アウェーチーム得点は、対象の試合でアウェーチームが実際に獲得した得点を示す。結果情報は、対象の試合の結果として、投票可能な選択肢の中から的中した選択肢を示す情報である。具体的に、結果情報は、くじDB14eに記憶される選択肢情報と同様に、得点の組み合わせ又は得点差を示してもよい。
閲覧履歴DB14hには、ユーザによる投票サイトの閲覧の履歴が記憶される。具体的に、閲覧履歴DB14hには、何れかのユーザ端末2が投票サイトのページを表示するごとに、閲覧ログとして、閲覧日時、閲覧者ID、及びURL(Uniform Resource Locator)等が、互いに関連付けて記憶されてもよい。閲覧日時は、対象のページがユーザ端末2の画面に表示された日時を示す。閲覧者IDは、対象のページを表示したユーザ端末2のユーザのユーザIDである。URLは、対象のページを識別する情報である。表示されたページが、特定の試合の詳細を表示する画面のページである場合、ページのURLは、その試合の試合IDを含んでもよい。また、このURLは、その試合で行われる競技がサッカー及びバスケットボールのうち何れであるかを示す競技種別を含んでもよい。更に、このURLは、表示された画面の種類(例えば、基本情報、オッズ情報、過去データ、又はくじ結果)を示す情報を含んでもよい。
購入履歴DB14iには、ユーザによるくじの購入の履歴が記憶される。この購入履歴は、試合の結果に対する投票の履歴でもある。具体的に、購入履歴DB14iには、何れかのユーザがくじを購入するごとに、購入ログとして、購入番号、購入者ID、購入日時、くじID、投票情報、及び口数等が、互いに関連付けて記憶されてもよい。購入番号は、対象の購入を識別する情報である。購入者IDは、くじを購入したユーザのユーザIDである。購入日時は、くじが購入された日時を示す。くじIDは、購入されたくじを示す。投票情報は、試合について予め定められた選択肢としての複数の結果のうち、ユーザが何れの結果に対して投票したかを示す。具体的に、投票情報は、くじDB14eに記憶される選択肢情報と同様に、得点の組み合わせ又は得点差を示してもよい。口数は、対象のくじが購入された個数を示す。
応援チームDB14jには、各ユーザが応援するチームに関する情報が記憶される。具体的に、応援チームDB14jには、ユーザと競技との組み合わせごとに、ユーザID、競技種別、及び応援チームID等が、互いに関連付けて記憶されてもよい。ユーザIDは、対象のユーザを示す。競技種別は、対象の競技を示す。応援チームIDは、対象のユーザが対象の競技で応援するチームのチームIDである。1人のユーザに対して複数の応援チームIDが記憶されてもよい。応援チームDB14jは、ユーザが応援するチームをセンターサーバ1が推定することに基づいて更新される。
記憶部14には、更に、オペレーティングシステム、DBMS(Database Management System)、サーバプログラム等の各種プログラムが記憶されている。サーバプログラムは、投票サイトに関する処理をシステム制御部11に実行させるプログラムである。サーバプログラムは、例えば、他の装置からインターネットNWを介して取得されるようにしてもよいし、磁気テープ、光ディスク、メモリカード等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしてもよい。
通信部15は、例えばネットワークインタフェースカード等により構成されている。通信部15は、ネットワークNWを介して、ユーザ端末2と接続し、これらの装置との通信状態を制御する。
[1-3.システム制御部の機能概要]
次に、センターサーバ1におけるシステム制御部11の機能概要について、図5及び図6を用いて説明する。図5は、センターサーバ1のシステム制御部11の機能ブロックの一例を示す図である。システム制御部11は、CPU11aが、サーバプログラムに含まれる各種プログラムコードを読み出し実行することにより、図5に示すように、情報取得部1101、推定部1102、及び送信部1103等として機能する。
情報取得部1101は、投票サイトを利用するユーザに関するユーザ情報を取得する。このユーザ情報は、例えば各チームに関する所定の情報と組み合わせることにより、ユーザが何れかのチームを応援する可能性があることを特定し得る情報であってもよい。また、ユーザ情報は、そのユーザと、予め定められた複数のチームのうち少なくとも何れか一のチームと、を関連付けて示す情報であってもよい。例えば、ユーザ情報は、そのユーザ情報により示されるユーザが、そのユーザ情報により示されるチームを応援する可能性があることを示す情報であってもよい。予め定められた複数のチームは、例えば投票サイトでくじが販売される又は販売される可能性がある試合に出場するチーム又は出場する可能性があるチームであってもよい。例えば、予め定められた複数のチームは、プロサッカーリーグに所属する全チーム、又はプロバスケットボールリーグに所属する全チームであってもよい。ここで、ユーザ情報は、ユーザに関連付けられるチームを示す情報として、特定のチーム自体を示す情報又は特定の試合を示す情報とユーザが関連付けられることを示してもよい。試合には2以上の競技主体が出場する。サッカー及びバスケットボールの試合では、2チームが出場する。従って、特定の試合を示す情報は特定の2チームを示す情報でもある。
ユーザ情報は、ユーザが投票サイトを利用してとった行動の履歴を示す行動履歴であってもよい。より具体的に、この行動履歴は、ユーザがとった行動が、予め定められた複数のチームのうち何れのチームに関連するものであるかを特定可能に示すものであってもよい。例えば、行動履歴は、投票サイトの閲覧履歴及びくじの購入履歴の少なくとも何れか一方を含んでもよい。
本実施形態においては、情報取得部1101は、行動履歴として閲覧履歴を取得する。具体的に、情報取得部1101は、ユーザが何れかの試合についての情報を閲覧したかを示す閲覧ログを取得してもよい。閲覧ログが取得される対象となる試合の情報から、投票推奨試合情報が除外されてもよい。ユーザは、そのユーザ自身が応援するチームが出場する試合に関する情報を見る蓋然性がある。閲覧ログが取得される対象となる試合の情報は、例えば試合の結果の予想に用いられる情報又は予想に用いることが可能な情報であってもよい。試合の結果の予想に用いられる情報は、例えば基本情報、オッズ情報、過去データ、くじ結果等の情報であってもよい。くじを購入する行為は、そのくじの対象となる試合に出場するチームのうち、少なくとも何れか一方のチームをユーザが応援する意味合いを含む可能性がある。そのくじの購入の前に、ユーザは、対象の試合に関する情報を見て、何れの選択肢に投票するかを予想する蓋然性がある。また、たとえ最終的にはくじを購入しないとしても、ユーザは、対象の試合に関する情報を見て試合の結果を予想する蓋然性がある。例えば、ユーザは、過去の対戦成績を見ることで、何れのチームが勝利しそうであるかを予想したり、オッズを見ることで、何れの選択肢が的中しやすいかを考えたり、過去の試合における得点を見ることにより、両チームが何点獲得するかを予想したり、過去の試合におけるくじの結果を見ることで、何れのチームが勝利するか若しくは両チームが何点獲得するかを予想したりすることが考えられる。
閲覧ログの取得対象となる情報の閲覧日時が、対象の試合の状態や対象のくじの販売状態等によって限定されてもよいし、限定されなくてもよい。例えば、情報取得部1101は、閲覧日時が試合の開始前である閲覧ログのみを取得してもよいし、閲覧日時が試合の開始前であるかに関係なく閲覧ログを取得してもよい。また、情報取得部1101は、閲覧日時が、くじの販売締切前である閲覧ログのみを取得してもよいし、閲覧日時がくじの販売締切前であるかに関係なく閲覧ログを取得してもよい。
推定部1102は、情報取得部1101により取得されたユーザ情報に基づいて、予め定められた複数のチームのうち、ユーザが応援するチームを推定する。前述したように、ユーザ情報は、特定のユーザと特定のチームとを関連付けて示す情報であり得る。そのため、推定部1102は、例えば対象のユーザに関連付けられたチームを、そのユーザが応援するチームであると推定してもよい。
ユーザ情報として行動履歴を用いる場合、推定部1102は、対象のユーザがとった行動に関連するチームを、そのユーザが応援するチームであると推定してもよい。行動履歴は、特定のユーザがこれまでにとった複数の行動を示し得る。そこで、推定部1102は、ユーザが特定のチームについて所定の行動とった回数が多いほど、そのユーザがそのチームを応援すると推定する蓋然性を高くしてもよい。例えば、推定部1102は、行動の頻度が高いほど、そのユーザがそのチームを応援すると推定する蓋然性を高くしてもよい。行動の頻度は、所定の期間内にユーザがとった行動の回数であってもよい。所定の期間の長さは、例えば6ヶ月、1年、2年等であってもよい。推定部1102は、行動の回数若しくは頻度が所定の閾値以上である1又は複数のチームを、ユーザが応援するチームとして推定してもよい。或いは、推定部1102は、行動の回数若しくは頻度が最も多いチーム、又は行動の回数若しくは頻度が多い順に所定数のチームを、ユーザが応援するチームとして推定してもよい。或いは、推定部1102は、予め定められた複数のチームの中で、行動の回数若しくは頻度が相対的に高い1又は複数のチームを、ユーザが応援するチームとして推定してもよい。
また、推定部1102は、行動がとられた日から今日までに経過した期間の長さが短いほど、その行動に関連付けられたチームをユーザが応援する蓋然性に対してその行動が寄与する度合いを高くしてもよい。ユーザが応援するチームは、時間が経過するにつれて変化する可能性がある。そのため、より新しい行動であるほど、その行動がユーザの現在の意思を反映している蓋然性が高い。推定部1102は、例えば直近1ヶ月以内の各行動を1回の行動とみなし、3ヶ月前から1ヶ月前までの間の各行動を0.7回の行動とみなし、6ヶ月前から3ヶ月前までの間の各行動を0.5回の行動とみなし、1年前から6ヶ月前までの間の各行動を0.3回の行動とみなしてもよい。
行動履歴として閲覧履歴を用いる場合、推定部1102は、予め定められた複数のチームのうち何れのチームが行う試合に関してユーザが試合に関する情報を閲覧したかに基づいて、そのユーザが応援するチームを推定してもよい。例えば、推定部1102は、各チームについて、そのチームが出場する試合の情報をユーザが閲覧した回数若しくは頻度に基づいて、そのユーザが応援するチームを推定してもよい。また、推定部1102は、ユーザが試合の情報を閲覧した日から今日までに経過した期間の長さが短いほど、閲覧された試合に出場するチームをユーザが応援する蓋然性に対してその閲覧が寄与する度合いを高くしてもよい。
図6は、ユーザが応援するチームの推定例を示す図である。推定部1102は、例えばユーザXが応援するチームを推定する。そこで、情報取得部1101は、図6に示すように、ユーザXの閲覧履歴2010を取得する。閲覧履歴2010は、閲覧ログ2011、2012及び2013等を含む。閲覧ログ2011は、チームAとチームBが対戦する試合の詳細情報の画面が閲覧されたことを示す。閲覧ログ2012は、チームCとチームBが対戦する試合の詳細情報の画面が閲覧されたことを示す。閲覧履歴2013は、チームDとチームAが対戦する試合の詳細情報の画面が閲覧されたことを示す。全体として、全チームのうち、チームAが出場する試合の情報が閲覧された回数が最も多い。従って、推定部1102は、ユーザXはチームAを応援すると推定してもよい。
各ユーザが応援するチームを推定するタイミングは特に限定されない。例えば、推定部1102は、定期的にバッチで全ユーザについて応援するチームを推定してもよい。或いは、推定部1102は、ユーザ情報に変化があったときに又はユーザ情報が追加されたときに、リアルタイムで、そのユーザ情報に関連付けられたユーザについて、応援するチームを推定してもよい。
送信部1103は、それぞれ試合の結果に投票可能な複数の試合のうち、推定部1102により推定されたチームが行う試合に関する投票推奨試合情報を、ユーザ端末2へ送信する。例えば、投票サイト内にある複数の画面の中で、投票推奨試合情報が表示される画面の種類が予め定められていてもよい。例えば1試合予想の対象の試合の一覧を表示する画面に、投票推奨試合情報が表示されてもよい。送信部1103は、ユーザ端末2から対象の画面の要求を受信することに応じて、その画面を表示するためのウェブページをユーザ端末2へ送信してもよい。このとき、送信部1103は、そのウェブページに投票推奨試合情報を含ませてもよい。これにより、送信部1103は、例えば図2に示すように、ユーザ端末2の画面に投票推奨試合情報を表示させる。送信部1103は、現在くじの購入可能な試合の中から、推定部1102により推定されたチームが行う試合を抽出してもよい。また、推定部1102は、将来にくじの販売が予定されている試合の中から、推定部1102により推定されたチームが行う試合を抽出してもよい。抽出される試合は、その試合を行うチームのうち少なくとも一のチームが、ユーザが応援すると推定されたチームであればよい。
送信部1103は、投票推奨試合情報をユーザ端末2が表示している際におけるユーザの操作に応じて、その投票推奨試合情報により示される試合の結果を投票するための投票画面を表示することが可能なように、投票推奨試合情報を送信してもよい。例えば、送信部1103は、投票推奨試合情報に関連付けて、その投票推奨試合情報により示される試合の投稿画面へのリンクをウェブページに埋め込んでもよい。この場合、画面に表示された投票推奨試合情報をユーザが選択することで、ユーザ端末2は投票画面を表示する。
互いに異なる複数の競技それぞれについて推定部1102によりユーザが応援するチームが推定された場合、送信部1103は、それらの競技のうち少なくとも一の競技について推定されたチームが行う試合について、投票推奨試合情報を送信してもよい。
本実施形態において、送信部1103は、1試合予想の対象となる試合について投票推奨試合情報を送信する。すなわち、単一試合得点選択方式のくじの対象である試合について投票推奨試合情報が送信される。しかしながら、送信部1103は、複数試合勝利チーム選択方式又は複数試合得点選択方式のくじの対象である複数の試合のうち、少なくともユーザが応援すると推定されたチームが出場する試合について、その試合を示す投票推奨試合情報を送信してもよい。
[1-4.投票システムの動作]
次に、投票システムSの動作について、図7及び図8を用いて説明する。センターサーバ1のシステム制御部11は、サーバプログラムに含まれる各種コードに従って、図7及び図8に示す処理を実行する。
図7は、本実施形態に係るセンターサーバ1のシステム制御部11により実行される応援チーム推定処理の一例を示すフローチャートである。例えば、所定期間(例えば1日、1週間、1ヶ月等)が経過するたびに、システム制御部11は、ユーザと競技との全組み合わせそれぞれについて、応援チーム推定処理を実行してもよい。この場合、システム制御部11は、各応援チーム推定処理を実行する際に、対象となるユーザを選択するとともに、サッカー及びバスケットボールのうち、対象となる競技を選択してもよい。
図7に示すように、情報取得部1101は、閲覧履歴DB14hから、選択ユーザによる選択競技の閲覧ログを取得する(ステップS101)。例えば、情報取得部1101は、選択ユーザのユーザIDを閲覧者IDとして含む閲覧ログのうち、画面のURLが、選択競技を示す競技種別、及び試合の詳細画面を示す情報を含む閲覧ログを検索してもよい。このとき、情報取得部1101は、閲覧日時が直近の所定期間内である閲覧ログを検索してもよい。次いで、推定部1102は、選択競技のプロリーグに所属する各チームの閲覧スコアを0に設定する。閲覧スコアは、情報の閲覧回数に相当する。また、推定部1102は、重み合計を0に設定する(ステップS102)。
次いで、推定部1102は、番号iを1に設定する(ステップS103)。次いで、推定部1102は、閲覧ログiから、選択ユーザが詳細画面を閲覧した試合に出場するチームとして、ホームチーム及びアウェーチームを特定する(ステップS104)。閲覧ログiは、ステップS101で取得された閲覧ログのうち、i番目の閲覧ログである。推定部1102は、例えば閲覧ログiに含まれるURLから試合IDを取得する。推定部1102は、この試合IDに関連付けて試合DB14dに記憶されているホームチームID及びアウェーチームIDを取得する。次いで、推定部1102は、閲覧ログiに含まれる閲覧日から今日までの日数に対応する重みを取得する(ステップS105)。この重みは、ユーザがチームを応援する蓋然性に対する寄与度に相当する。推定部1102は、例えば日数が短いほど重みを大きくしてもよい。次いで、推定部1102は、ステップS104で特定されたホームチームの閲覧スコアに重みを加算して、この閲覧スコアを更新する。また、推定部1102は、アウェーチームの閲覧スコアに重みを加算して、この閲覧スコアを更新する。また、推定部1102は、重み合計に重みを加算して、重み合計を更新する(ステップS106)。
次いで、推定部1102は、番号iが、ステップS101で取得された閲覧ログの数未満であるか否かを判定する(ステップS107)。番号iが閲覧ログの数未満である場合(ステップS107:YES)、推定部1102は、番号iを1増加させて(ステップS108)、処理はステップS104に進む。
一方、番号iが閲覧ログの数未満ではない場合(ステップS107:NO)、推定部1102は、各チームの閲覧スコアを重み合計で除算することにより、各チームの応援度を計算する(ステップS109)。次いで、推定部1102は、選択競技のプロリーグに所属するチームのうち、応援度が所定の閾以上である1又は複数のチームを、応援チームに決定する(ステップS110)。次いで、推定部1102は、選択ユーザのユーザIDと選択競技を示す競技種別とに関連付けて応援チームDB14jに既に記憶されている応援チームIDを全て削除する。そして、推定部1102は、決定された応援チームのチームIDを応援チームIDとして、選択ユーザのユーザIDと選択競技を示す競技種別とに関連付けて応援チームDB14jに記憶させて(ステップS111)、応援チーム推定処理は終了する。
図8は、本実施形態に係るセンターサーバ1のシステム制御部11により実行される情報提供処理の一例を示すフローチャートである。例えば、ユーザ端末2から投票推奨試合情報を含む画面の要求を受信するごとに、システム制御部11は情報提供処理を実行してもよい。ユーザ端末2からの要求は、例えば要求された画面のURL、及びそのユーザ端末2のユーザのユーザID等を含んでもよい。
図8に示すように、送信部1103は、要求された画面の主たる情報を生成する(ステップS201)。例えば、要求された画面が1試合予想トップ画面である場合、送信部1103は、チームDB14b、試合DB14d及びくじDB14e等を参照して、くじの販売締切までの時間が所定時間未満である試合の一覧を、主たる情報として生成してもよい。
次いで、送信部1103は、応援チームDB14jから、画面を要求してきたユーザのユーザIDに関連付けられた応援チームIDを取得する(ステップS202)。ここで、送信部1103は、要求された画面が1試合予想トップ画面である場合、関連付けられた競技種別がサッカー及びバスケットボールの何れかを示すかにかかわらず、応援チームIDを取得してもよい。要求された画面がサッカー用の画面である場合、送信部1103は、サッカーを示す競技種別に関連付けられた応援チームIDを取得してもよい。要求された画面が、バスケットボール用の画面である場合、送信部1103は、バスケットボールを示す競技種別に関連付けられた応援チームIDを取得してもよい。
次いで、送信部1103は、くじDB14eから、現在販売中のくじのくじ情報を取得する(ステップS203)。例えば、送信部1103は、現在日時を販売期間に含むくじ情報を取得する。
次いで、送信部1103は、現在販売中のくじが対応する試合のうち、画面を要求してきたユーザが応援するチームが出場する試合を特定する(ステップS204)。例えば、送信部1103は、ステップS203で取得されたくじ情報の中から、ホームチームID及びアウェーチームIDの何れかが応援チームIDと一致するくじ情報を抽出してもよい。そして、送信部1103は、抽出されたくじ情報から試合IDを取得してもよい。
次いで、送信部1103は、ユーザが応援するチームが出場する試合の投票推奨試合情報を生成する(ステップS205)。例えば、送信部1103は、ステップS204で取得された各試合IDに基づいて、試合DB14dから対象となる試合の試合情報を取得してもよい。また、送信部1103は、抽出されたくじ情報に含まれるホームチームID及びアウェーチームIDに基づいて、ホームチーム及びアウェーチームそれぞれのチーム情報をチームDB14bから取得してもよい。送信部1103は、抽出したくじ情報、取得した試合情報及びチーム情報に基づいて、試合ごとに投票推奨試合情報を生成する。
次いで、送信部1103は、主たる情報、及び投票推奨試合情報を含むウェブページを生成する(ステップS206)。このとき、送信部1103は、各投票推奨試合情報について、その推奨情報により示される試合の投票画面のURLを生成する。送信部1103は、生成されたURLを含むリンクをウェブページに追加する。次いで、送信部1103は、生成されたウェブページをユーザ端末2へ送信して(ステップS207)、情報提供処理は終了する。
以上説明したように、本実施形態によれば、センターサーバ1が、予め定められた複数のチームのうち2以上のチーム同士でそれぞれ行われる複数の試合それぞれについて該試合の結果に投票可能な投票サイトを利用するユーザに関するユーザ情報を取得する。また、センターサーバ1が、取得されたユーザ情報に基づいて、複数のチームのうち、ユーザが応援するチームを推定する。また、センターサーバ1が、複数の試合のうち、推定されたチームが行う試合に関する投票推奨試合情報を、そのユーザのユーザ端末2へ送信する。この処理によれば、ユーザに関する情報に基づいて、そのユーザが応援するチームが推定される。結果に投票可能な試合のうち、応援すると推定されるチームが行う試合に関する投票推奨試合情報が、そのユーザのユーザ端末2に送信される。そして、ユーザ端末2からユーザに対してその投票推奨試合情報が提示される。ユーザは、複数の試合の中で、そのユーザ自身が応援するチームが行う試合の結果に投票したいと考える可能性が高い。従って、投票推奨試合情報を送信することで、投票したい試合をユーザが見つけ出すことを容易にすることができる。
ここで、ユーザ情報は、ユーザと、複数のチームのうち何れか少なくとも一のチームと、を関連付けて示すものであってもよい。この場合、ユーザと少なくとも一のチームとを関連付けて示すユーザ情報が推定に用いられる。従って、ユーザが何れのチームを応援する可能性があるかを特定することができる。
ここで、ユーザ情報は、ユーザが投票サイトを利用してとった行動の履歴であって、その行動が、複数のチームのうち何れのチームに関連するものであるかを示す行動履歴を含んでもよい。この場合、何れかのチームに関連してユーザがとった行動について、そのチームを示す行動の履歴が推定に用いられる。従って、ユーザが何れのチームについて応援する可能性あることを示す行動をとったかを特定することができる。
ここで、センターサーバ1が、複数のチームのうち何れかのチームに関連してユーザが行動した回数が多いほど、そのチームが、ユーザが応援するチームとして推定される蓋然性を高くしてもよい。この場合、複数のチームの中で、応援する可能性あることを示す行動をとった回数が多いチームであるほど、ユーザが応援するチームとして推定される蓋然性を高くすることができる。
また、センターサーバ1が、複数のチームのうち何れのチームが行う試合に関してユーザが試合に関する情報を閲覧したかに基づいて、応援するチームを推定してもよい。この場合、何れのチームが行う試合についてユーザが情報を閲覧したかを示す閲覧履歴が、推定に用いられる。ユーザは、そのユーザが応援するチームが行う試合に関する情報を閲覧する可能性があるので、この閲覧履歴に基づいて、ユーザが応援するチームを推定することができる。
[2.第2実施形態]
次に、図9乃至図11を参照して第2実施形態について説明する。以下に説明する点を除き、第2実施形態は第1実施形態と同一であってもよい。本実施形態においても、ユーザが応援するチームを推定するためのユーザ情報として行動履歴が用いられる。その一方で、本実施形態においては、行動履歴として、閲覧履歴ではなく、くじの購入履歴が用いられる。
従って、情報取得部1101は、購入履歴を取得する。例えば、情報取得部1101は、1試合予想のくじの購入履歴を取得する。しかしながら、情報取得部1101は、複数試合勝利チーム選択方式又は複数試合得点選択方式のくじの購入履歴を取得してもよい。
推定部1102は、情報取得部1101により取得された購入履歴に基づいて、ユーザが応援するチームを推定する。具体的に、推定部1102は、予め定められた複数のチームのうち何れのチームが行う試合に対して前記ユーザが投票したかに基づいて、そのユーザが応援するチームを推定してもよい。例えば、推定部1102は、各チームについて、そのチームが出場する試合のくじをユーザが購入した回数若しくは頻度に基づいて、そのユーザが応援するチームを推定してもよい。また、推定部1102は、ユーザがくじを購入した日から今日までに経過した期間の長さが短いほど、くじが購入された試合に出場するチームをユーザが応援する蓋然性に対してその閲覧が寄与する度合いを高くしてもよい。
図9は、ユーザが応援するチームの推定例を示す図である。情報取得部1101は、図9に示すように、ユーザXの購入履歴3010を取得する。購入履歴3010は、購入ログ3011、3012及び3013等を含む。購入ログ3011は、チームFとチームGが対戦する試合のくじが購入されたことを示す。購入ログ3012は、チームGとチームHが対戦する試合のくじが購入されたことを示す。購入履歴3013は、チームIとチームGが対戦する試合のくじが購入されたことを示す。全体として、全チームのうち、チームGが出場する試合のくじが購入された回数が最も多い。従って、推定部1102は、ユーザXはチームGを応援すると推定してもよい。
推定部1102は、くじの購入により、試合について選択肢として予め定められた複数の結果のうち、ユーザが何れの結果に投票したかに基づいて、そのユーザが応援するチームを推定してもよい。投票対象の試合に出場するチームのうち何れのチームをユーザが応援するかが、そのユーザによる投票先に影響する場合がある。より具体的に、ユーザは、応援する方のチームにとってより有利な結果となるように、投票先とする結果を選択する可能性がある。すなわち、ユーザは、応援する方のチームを贔屓目に見る可能性がある。例えば或るチームについて、敗北よりも、引き分け若しくはそのチームの勝利の方が、そのチームにとって有利である。また、引き分けよりもそのチームの勝利の方が、そのチームにとって有利である。また例えば、或る試合に出場するホームチームが獲得する得点を、その試合に出場するアウェーチームが獲得する得点で減算することにより得点差を計算したと仮定する。この得点差の値が高いほど、ホームチームにとって有利である。
例えば、推定部1102は、ユーザによる投票先とされた結果と、選択肢として予め定められた複数の結果のうち、現実となる可能性が相対的に高い結果として定められた結果と、に基づいて、そのユーザが応援するチームを推定してもよい。試合に出場するチームのうち何れか一方をユーザが応援する場合、可能性が高い結果よりも、応援するチームが有利となる結果にユーザが投票する可能性がある。この場合、投票先とされた結果と可能性が高い結果との間に相違が生じる。応援するチームに対するユーザの愛着が強いほど、結果の相違は大きくなるかもしれない。可能性が高い結果よりも、投票先とされた結果の方がホームチームにとって有利である場合、推定部1102は、ユーザはそのホームチームを応援すると推定し、又はそのホームチームを応援すると推定される蓋然性を高くしてもよい。可能性が高い結果よりも、投票先とされた結果の方がアウェーチームにとって有利である場合、推定部1102は、ユーザはそのアウェーチームを応援すると推定し、又はそのアウェーチームを応援すると推定される蓋然性を高くしてもよい。或る結果が現実となる可能性を示す情報は、その結果のオッズであってもよい。現実となる可能性が相対的に高い結果として定められた結果は、例えば、最人気の結果であってもよい。最人気の結果は、オッズが最低の結果である。
推定部1102は、ユーザによる投票先とされた結果が現実となる可能性に基づいて、ユーザが応援するチームを推定してもよい。投票先とされた結果と可能性が高い結果との間に相違がある場合、対象の試合に出場したチームのうち、可能性が高い結果よりも有利な結果に投票された方のチームをユーザが応援している可能性がある。ここで、ユーザによる投票先とされた結果が現実となる可能性が低いほど、応援すると推定されるチームに対してユーザの愛着が強い可能性がある。そこで、推定部1102は、ユーザによる投票先とされた結果が現実となる可能性が低いほど、可能性が高い結果よりも有利な結果に投票された方のチームをユーザが応援すると推定する蓋然性を高くしてもよい。例えば、推定部1102は、投票先とされた結果のオッズが高いほど、より有利な結果に投票された方のチームをユーザが応援すると推定する蓋然性を高くしてもよい。また例えば、推定部1102は、投票先とされた結果のオッズと最人気の結果のオッズとの差が大きいほど、より有利な結果に投票された方のチームをユーザが応援すると推定する蓋然性を高くしてもよい。或いは、推定部1102は、可能性が高い結果よりも有利な度合いが高いほど、より有利な結果に投票された方のチームをユーザが応援すると推定する蓋然性を高くしてもよい。応援すると推定されるチームに対してユーザがより贔屓目に結果を予想するほど、ユーザはそのチームに対してユーザの愛着が強い可能性がある。有利な度合いは、例えばホームチームとアウェーチームとの間の得点差が、可能性が高い結果と比較して何点有利であるかであってもよい。
図10は、ユーザが応援する蓋然性を決定する方法の一例を示す図である。図9に示すように、ユーザXの購入履歴3010は、購入ログ3011等を含む。購入ログ3011は、チームFとチームGが対戦する試合のくじが購入されたことを示す。ユーザXは、2対0でチームFが勝利する結果に投票した。この結果に対応するオッズは27.0倍である。この試合のくじにおいて、最人気の結果の予想は、0対1でチームGが勝利する結果である。この結果のオッズは1.5倍である。最人気の結果に対して、ユーザXが投票した結果は、チームFの方に3点有利である。そこで、推定部1102は、この試合については、ユーザXがチームFを応援する蓋然性を、チームGを応援する蓋然性よりも高くしてもよい。
図11は、本実施形態に係るセンターサーバ1のシステム制御部11により実行される応援チーム推定処理の一例を示すフローチャートである。図11において、図7と同一の処理については同一の符号が付されている。
図11に示すように、先ず情報取得部1101は、購入履歴DB14iから、選択ユーザによる選択競技の購入ログを取得する(ステップS301)。例えば、情報取得部1101は、選択ユーザのユーザIDを購入者IDとして含む購入ログを取得する。このとき、情報取得部1101は、購入日時が直近の所定期間内である購入ログを取得してもよい。次いで、推定部1102は、選択競技のプロリーグに所属する各チームの購入スコアを0に設定する。購入スコアは、くじの購入回数に相当する。また、推定部1102は、重み合計を0に設定する(ステップS302)。
次いで、推定部1102は、番号iを1に設定する(ステップS303)。次いで、推定部1102は、購入ログiから、選択ユーザが購入したくじに対応する試合に出場するチームとして、ホームチーム及びアウェーチームを特定する(ステップS304)。購入ログiは、ステップS101で取得された購入ログのうち、i番目の購入ログである。推定部1102は、例えば購入ログiからくじIDを取得する。推定部1102は、このくじIDに関連付けてくじDB14eに記憶されているくじ情報から、ホームチームID及びアウェーチームIDを取得する。次いで、推定部1102は、購入ログiに含まれる購入日から今日までの日数に対応する時期重みを取得する(ステップS305)。推定部1102は、例えば日数が短いほど時期重みを大きくしてもよい。次いで、推定部1102は、重み合計に時期重みを加算して、重み合計を更新する(ステップS306)。
次いで、推定部1102は、ユーザが購入したくじについて、最人気の結果の予想における得点差を取得する(ステップS307)。例えば、推定部1102は、購入ログiのくじIDに関連付けてオッズDB14fに記憶されている各オッズを取得する。推定部1102は、取得されたオッズの中で最低のオッズを特定する。推定部1102は、購入ログiのくじIDと最低のオッズとに関連付けてオッズDB14fに記憶されている選択肢情報を取得する。推定部1102は、この選択肢情報から得点差を特定する。選択競技がサッカーである場合、推定部1102は、選択肢情報からホームチーム及びアウェーチームそれぞれの得点を特定する。推定部1102はホームチームの得点からアウェーチームの得点を減算することにより、得点差を計算してもよい。選択競技がバスケットボールである場合、推定部1102は、選択肢情報から得点差の範囲を特定する。推定部1102は、例えばこの得点差の範囲の下限値を、得点差として特定してもよい。次いで、推定部1102は、ユーザによる投票先の結果における得点差を取得する(ステップS308)。例えば、推定部1102は、購入ログiに含まれる投票情報から、ステップS307と同様の方法で得点差を特定する。
次いで、推定部1102は、オッズ差を計算する(ステップS309)。例えば、推定部1102は、購入ログiに含まれるくじIDと投票情報との組み合わせと一致するくじIDと選択肢情報との組み合わせに関連付けてオッズDB14fに記憶されたオッズを取得する。推定部1102は、このオッズから、最人気の結果の予想のオッズを減算することにより、オッズ差を計算してもよい。
次いで、推定部1102は、ユーザが投票した結果において、最人気の結果の予想よりも有利な方のチームの贔屓度を決定する(ステップS310)。例えば、ユーザによる投票先の結果における得点差から、最人気の結果の予想における得点差を減算することにより、得点差ずれを計算してもよい。この得点差ずれが正の値である場合、ホームチームの方に有利である。得点差ずれが負の値である場合、アウェーチームの方に有利である。得点差ずれが0である場合、何れのチームも有利ではない。推定部1102は、オッズ差が大きいほど、有利な方のチームの贔屓度を高くしてもよい。次いで、推定部1102は、ユーザが投票した結果において、最人気の結果の予想よりも不利な方のチームの贔屓度を決定する(ステップS311)。例えば、推定部1102は、オッズ差が大きいほど、不利な方のチームの贔屓度を低くしてもよい。得点差ずれが0である場合、推定部1102は、ホームチーム及びアウェーチームの両方に同一の贔屓度を決定してもよい。なお、サッカーにおいては、選択肢として「ホームチームが4点以上獲得してホームチーム勝利」、及び「アウェーチームが4点以上獲得してアウェーチーム勝利」がある。この場合、得点差を計算することができない。そこで、推定部1102は、ユーザによる投票先の結果及び最人気の結果それぞれが、ホームチームの勝利、アウェーチームの勝利、及び引き分けのうち何れを示しているかを用いて、贔屓度を決定してもよい。
次いで、推定部1102は、ホームチーム及びアウェーチームそれぞれの投票重みを計算する(ステップS312)。例えば、推定部1102は、それぞれのチームの贔屓度に時期重みを乗算して、投票重みを計算してもよい。次いで、推定部1102は、ホームチーム及びアウェーチームそれぞれの購入スコアに、それぞれの投票重みを加算することにより、それらの購入スコアを更新する(ステップS313)。
次いで、推定部1102は、番号iが、ステップS301で取得された購入ログの数未満であるか否かを判定する(ステップS314)。番号iが購入ログの数未満である場合(ステップS314:YES)、推定部1102は、番号iを1増加させて(ステップS315)、処理はステップS304に進む。
一方、番号iが購入ログの数未満ではない場合(ステップS314:NO)、推定部1102は、各チームの購入スコアを重み合計で除算することにより、各チームの応援度を計算する(ステップS316)。次いで、推定部1102は、応援度が所定の閾以上であるチームを、応援チームに決定する(ステップS110)。次いで、推定部1102は、決定された応援チームのチームIDを、選択ユーザのユーザIDと選択競技を示す競技種別とに関連付けて応援チームDB14jに記憶させて(ステップS111)、応援チーム推定処理は終了する。
以上説明したように、本実施形態によれば、ユーザ情報は、試合の結果に対する投票の履歴を示す購入履歴を含む。また、センターサーバ1が、複数のチームのうち何れのチームが行う試合の結果に対してユーザが投票したかに基づいて、応援するチームを推定する。この処理によれば、何れのチームが行う試合についてユーザが投票したかを示す購入履歴が推定に用いられる。ユーザは、そのユーザが応援するチームが行う試合の結果に投票する可能性があるので、この購入履歴に基づいて、ユーザが応援するチームを推定することができる。
ここで、センターサーバ1が、ユーザの投票先として購入履歴により示される結果、及び複数の結果のうち、現実となる可能性が相対的に高い結果として定められた結果に基づいて、応援するチームを推定してもよい。この場合、ユーザが投票を行った試合について、何れの結果にユーザが投票したかと、実現可能性が高い結果とに基づいて、応援するチームが推定される。或る試合に出場する複数のチームのうち一部のチームをユーザが応援する場合、ユーザが投票先として選択する結果は、ユーザが特定のチームを応援することの影響を受ける場合がある。そのため、ユーザが投票先として選択する結果と実現可能性が高い結果とが相違する場合がある。従って、ユーザが応援するチームを推定することができる。
[3.第3実施形態]
次に、図12乃至図13を参照して第3実施形態について説明する。以下に説明する点を除き、第2実施形態は第1実施形態又は第2実施形態と同一であってもよい。本実施形態においても、ユーザ情報として行動履歴が用いられる。本実施形態においては、行動履歴として、閲覧履歴及び購入履歴の両方が用いられる。従って、情報取得部1101は、閲覧履歴及び購入履歴を取得する。
推定部1102は、情報取得部1101により取得された閲覧履歴及び購入履歴に基づいて、ユーザが応援するチームを推定する。例えば、推定部1102は、ユーザが情報を閲覧した試合を行うチームと、ユーザが投票を行った試合を行うチームと、で共通するチームの中から、そのユーザが応援すると推定されるチームを決定してもよい。これにより、推定精度を高めることができる。ユーザが或るチームを応援する場合、そのユーザは、応援するチームに関する情報を閲覧するとともに、そのチームが出場する試合のくじを購入する可能性がある。推定部1102は、例えば予め定められた複数のチームの中で、情報の閲覧の回数若しくは頻度が相対的に高い1又は複数のチームと、くじの購入回数若しくは頻度が相対的に高い1又は複数のチームと、で共通するチームを、そのユーザが応援するチームとして推定してもよい。
図12は、ユーザが応援するチームの推定例を示す図である。図12に示すように、或るユーザYの閲覧履歴2020は、閲覧ログ2021、2022及び2023等を含む。閲覧ログ2021は、チームAとチームBが対戦する試合の詳細画面が閲覧されたことを示す。閲覧ログ2022は、チームCとチームAが対戦する試合の詳細画面が閲覧されたことを示す。閲覧履歴2023は、チームBとチームDが対戦する試合の詳細画面が閲覧されたことを示す。全体として、全チームのうち、チームA及びBの何れかが出場する試合の情報が閲覧された回数が最も多い。一方、ユーザYの購入履歴3020は、閲覧ログ3021、3022及び3023等を含む。購入ログ3021は、チームAとチームEが対戦する試合のくじが購入されたことを示す。購入ログ3022は、チームEとチームBが対戦する試合のくじが購入されたことを示す。購入履歴3023は、チームBとチームDが対戦する試合のくじが購入されたことを示す。全体として、全チームのうち、チームB及びEの何れかが出場する試合のくじが購入された回数が最も多い。共通するチームはチームBである。従って、推定部1102は、ユーザYはチームBを応援すると推定してもよい。
図13は、本実施形態に係るセンターサーバ1のシステム制御部11により実行される応援チーム推定処理の一例を示すフローチャートである。図13において、図7と同一の処理については同一の符号が付されている。
図13に示すように、システム制御部11は、選択ユーザの閲覧履歴に基づいて、選択競技の各チームの応援度を計算する(ステップS401)。例えば、システム制御部11は、図7に示すステップS101~S109を実行してもよい。次いで、推定部1102は、ステップS401で計算された応援度が所定の閾値以上であるチームを、第1応援候補に決定する(ステップS402)。
次いで、システム制御部11は、選択ユーザの購入履歴に基づいて、選択競技の各チームの応援度を計算する(ステップS403)。例えば、システム制御部11は、図11に示すステップS301~S316を実行してもよい。次いで、推定部1102は、ステップS403で計算された応援度が所定の閾値以上であるチームを、第2応援候補に決定する(ステップS404)。なお、ステップS402で用いられる閾値とステップS404で用いられる閾値とは、同値であってもよいし異なる値であってもよい。
次いで、推定部1102は、第1応援候補と第2応援候補とで共通するチームを、応援チームに決定する(ステップS405)。次いで、推定部1102は、決定された応援チームのチームIDを、選択ユーザのユーザIDと選択競技を示す競技種別とに関連付けて応援チームDB14jに記憶させて(ステップS111)、応援チーム推定処理は終了する。
以上説明したように、本実施形態によれば、ユーザ情報は、試合に関する情報の閲覧の履歴を示す閲覧履歴、及び試合の結果に対する投票の履歴を示す購入履歴を含む。また、センターサーバ1が、ユーザが試合情報を閲覧した試合を行うチームと、ユーザが投票した試合を行うチームと、で共通するチームの中から、ユーザが応援すると推定されるチームを決定する。この処理によれば、ユーザにより情報が閲覧された試合を行い且つユーザが結果に投票した試合を行うチームの中から、ユーザが応援すると推定されるチームが決定される。両方の履歴を用いることで、応援するチームの推定精度を高めることができる。
[4.第4実施形態]
次に、図14を参照して第4実施形態について説明する。以下に説明する点を除き、第4実施形態は、第1実施形態~第3実施形態の何れかと同一であってもよい。本実施形態においては、ユーザ情報として、お気に入りの情報が用いられる。
情報取得部1101は、予め定められた複数のチームのうち、ユーザによりお気に入りとして登録されたチームを示すお気に入り情報を取得する。本実施形態において、お気に入り情報は、お気に入りチームDB14cに記憶されるお気に入りチームIDであってもよい。
推定部1102は、情報取得部1101により取得されたお気に入り情報に基づいて、ユーザが応援するチームを推定する。例えば、推定部1102は、お気に入りチームIDにより示されるチームを、ユーザが応援するチームであると推定してもよい。ユーザがお気に入りに登録したチームは、そのユーザが応援するチームである蓋然性が高い。
図14は、本実施形態に係るセンターサーバ1のシステム制御部11により実行される応援チーム推定処理の一例を示すフローチャートである。図14において、図7と同一の処理については同一の符号が付されている。
図14に示すように、情報取得部1101は、お気に入りチームDB14cから、選択ユーザのユーザIDと選択競技を示す競技種別との組み合わせに関連付けられたお気に入りチームIDを取得する(ステップS501)。次いで、推定部1102は、取得されたお気に入りチームIDにより示されるチームを応援チームに決定する(ステップS502)。次いで、推定部1102は、決定された応援チームのチームIDを、選択ユーザのユーザIDと選択競技を示す競技種別とに関連付けて応援チームDB14jに記憶させて(ステップS111)、応援チーム推定処理は終了する。
以上説明したように、本実施形態によれば、ユーザが応援するが故にお気に入りに登録されたチームを特定することができる。
[5.第5実施形態]
次に、図15を及び図16を参照して第5実施形態について説明する。以下に説明する点を除き、第5実施形態は、第1実施形態~第4実施形態の何れかと同一であってもよい。本実施形態においては、ユーザ情報として、そのユーザの住む場所を示す情報が用いられる。
情報取得部1101は、ユーザが住む場所を示す情報を取得する。ユーザが住む場所を示す情報は、住所であってもよいし、ユーザの住所地がある市区町村、都道府県、地方、若しくはその他の種類の地域を示す情報であってもよい。
情報取得部1101は、更に予め定められた複数のチームそれぞれが本拠とする場所を示す情報を取得してもよい。本拠とする場所を示す情報は、例えば本拠地として本拠となる競技場若しくは事務所の住所自体であってもよいし、その本拠地がある市区町村、都道府県、地方等、若しくはその他の種類の地域を示す情報であってもよい。
推定部1102は、ユーザが住む場所と、複数のチームそれぞれが本拠とする場所と、に基づいて、そのユーザが応援するチームを推定する。例えば、推定部1102は、ユーザが住む場所と本拠地との位置関係に基づいて推定を行ってもよい。推定部1102は、ユーザが住む場所から本拠地までが相当程度に近いと考えられるチームを、そのユーザが応援するチームとして推定してもよい。その理由は、ユーザの地元にあるチームをそのユーザが応援する蓋然性が高いからである。推定部1102は、ユーザの住所地がある区域と、各チームの本拠地がある区域とを特定してもよい。例えば、日本が、市区町村単位、都道府県単位、地方単位、若しくは東西で複数の区域に分けられてもよい。推定部1102は、ユーザの住所地がある区域と同一区域に本拠地があるチームを、ユーザが応援するチームであると推定してもよい。或いは、推定部1102は、ユーザの住所地がある区域と同一区域に本拠地があるか若しくは隣接する区域に本拠地があるチームを、ユーザが応援するチームであると推定してもよい。或いは、推定部1102は、ユーザの住所地がある区域から本拠地がある区域までに通過する区域の数が所定数未満であるチームを、ユーザが応援するチームであると推定してもよい。或いは、推定部1102は、ユーザの住所地から本拠地までの距離が所定距離未満であるチームを、ユーザが応援するチームであると推定してもよい。
図15は、ユーザが応援するチームの推定例を示す図である。図15に示すように、ユーザXは川崎市に住んでいる。チームDB14bには、各チームの本拠地名が記憶されている。例えば、チームAの本拠地は大阪府である。チームBの本拠地は柏市である。チームCの本拠地は横浜市である。チームDの本拠地は旧浦和市に相当する地域である。チームEの本拠地は川崎市である。チームFの本拠地は仙台市である。ユーザが応援するチームの本拠地を、ユーザが住む市区町村内に限定する場合、推定部1102は、川崎市に本拠地があるチームEをユーザXが応援すると推定してもよい。
図16は、本実施形態に係るセンターサーバ1のシステム制御部11により実行される応援チーム推定処理の一例を示すフローチャートである。図16において、図7と同一の処理については同一の符号が付されている。
図16に示すように、情報取得部1101は、会員DB14aから、選択ユーザのユーザIDに関連付けられた住所を取得する(ステップS601)。次いで、情報取得部1101は、チームDB14bから、選択競技を示す競技種別に関連付けられた各チームの本拠地名を取得する(ステップS602)。次いで、推定部1102は、選択ユーザの住所地がある区域内に本拠地があるチームを、応援チームに決定する(ステップS603)。例えば、推定部1102は、ユーザの住所名に基づいて、ユーザの住所地がある区域を特定する。また、推定部1102は、本拠地名に基づいて、各チームの本拠地がある区域を特定する。推定部1102は、ユーザの住所地がある区域と本拠地の区域とが一致するチームを、応援チームに決定する。次いで、推定部1102は、決定された応援チームのチームIDを、選択ユーザのユーザIDと選択競技を示す競技種別とに関連付けて応援チームDB14jに記憶させて(ステップS111)、応援チーム推定処理は終了する。
以上説明したように、本実施形態によれば、ユーザ情報は、ユーザが住む場所を示す情報を含む。また、センターサーバ1が、ユーザが住む場所と、複数のチームそれぞれが本拠とする場所と、に基づいて、応援するチームを推定する。この処理によれば、ユーザが住む場所を示す情報が推定に用いられる。ユーザは、ユーザの地元又はその地元から比較的に近い場所を本拠とするチームを応援する可能性があるので、ユーザが応援するチームを推定することができる。
[6.第6実施形態]
次に、第6実施形態について説明する。以下に説明する点を除き、第6実施形態は、第1実施形態~第5実施形態の何れかと同一であってもよい。本実施形態においては、ユーザ情報として、閲覧履歴、購入履歴、お気に入りのチームの情報、住所を示す情報のうち、何れか2種類以上の情報が用いられる。従って、情報取得部1101は、対象となる2種類以上の情報それぞれを取得する。
本実施形態において、推定部1102は、取得された2種類以上の情報を総合的に勘案して、ユーザが応援するチームを取得する。例えば、推定部1102は、各情報の重要性に応じた重みをその情報に付与する。例えば、他の情報と比較して、お気に入りのチームの情報の重要性が相対的に高いかもしれない。その理由は、好きなチームをユーザがお気に入りに登録する蓋然性が高いからである。また、閲覧履歴よりも購入履歴の方の重要性が高いかもしれない。その理由は、試合に関する情報を閲覧する行為よりも、金銭を支払って投票する行為の方が、ユーザにとってハードル高い行為であるからである。
取得されるユーザ情報に閲覧履歴及び購入履歴の少なくとも何れか一方が含まれる合、前述したように、推定部1102は各チームについて応援度を計算してもよい。推定部1102は、各チームの応援度に、閲覧履歴又は購入履歴に対応した重みを乗算することで、閲覧履歴又は購入履歴に対応する各チームのスコアを計算してもよい。ユーザ情報にお気に入りのチームの情報が含まれる場合、推定部1102は、例えばユーザがお気に入りに登録したチームに、0よりも大きい所定のスコアを付与し、ユーザがお気に入りに登録していないチームに、スコアとして0を付与してもよい。ユーザ情報にユーザが住む場所の情報が含まれる場合、推定部1102は、例えば所定の条件に基づいてユーザの住所地から本拠地が近いと判定されるチームに、0よりも大きい所定のスコアを付与し、その他のチームに、スコアとして0を付与してもよい。或いは、推定部1102は、ユーザの住所地から本拠地までの距離又は区域数に応じて、各チームにスコアを付与してもよい。
推定部1102は、各チームについて全スコアを合計し、合計スコアが最も高いチーム、合計スコアが高い順に所定数のチーム、若しくは合計スコアが所定の閾値以上であるチームを、ユーザが応援するチームであると推定してもよい。
[7.第7実施形態]
次に、図17及び図18を参照して第7実施形態について説明する。以下に説明する点を除き、第7実施形態は、第1実施形態~第6実施形態の何れかと同一であってもよい。本実施形態においては、ユーザ情報として、対象となる競技とは異なる競技でユーザが応援すると推定されたチームの本拠がある場所を示す情報が用いられる。そのため、本実施形態においては、複数の競技について、ユーザが応援するチームを推定することが前提であってもよい。
複数の競技のうち一部の競技については、第1実施形態~第6実施形態で説明したようなユーザ情報、すなわち、行動履歴、お気に入りのチームの情報、又はユーザが住む場所の情報からでは、そのユーザが応援するチームを推定することができないか、又は推定精度に疑問が生じる場合がある。例えば、そのユーザの閲覧履歴又は購入履歴が無い場合、その履歴から応援するチームを推定することは不可能である。また、情報の閲覧回数又はくじの購入回数が少ない場合、応援するチームの推定自体は可能であるかもしれないが、その推定精度は低くなる。また、ユーザがお気に入りに登録したチームがない場合、お気に入りの情報からの推定は不可能である。また、ユーザの住所地に本拠地が近いチームが存在しない場合、ユーザが住む場所の情報からの推定は難しい。
その一方で、或る競技についてユーザが特定のチームを応援している場合、そのチームが本拠とする場所に比較的に近い場所を本拠とする別の競技のチームを、そのユーザが応援している可能性がある。その理由は、ユーザは、その場所がある地域に何らかの思い入れがある可能性があるからである。例えば、ユーザが過去に住んでいた地域や訪れたことがある地域のチームを、そのユーザが応援する可能性がある。或いは、単純に、ユーザは、応援するチームの本拠がある地域の別のチームを好きになるかもしれない。こうして、何れかの競技についてユーザが応援するチームを推定することができれば、そのチームの情報に基づいて、別の競技についてユーザが応援するチームを推定することができる場合がある。例えば、或る競技についてユーザが投票サイトを然程利用していないことにより、その競技についてユーザの行動履歴やお気に入りのチームの情報がない一方で、別の競技についてユーザが投票サイトを或る程度の頻度以上利用している場合に、有効であると考えられる。
以降においては、サッカー及びバスケットボールのうち何れか一方を第1競技とする。サッカー及びバスケットボールのうち、第1競技ではない方の競技を、第2競技とする。本実施形態においては、2競技についてユーザが応援するチームの推定が行われるが、3競技以上の競技について推定が行われてもよい。
本実施形態において、情報取得部1101は、第1競技及び第2競技それぞれについて、ユーザ情報を取得し又は取得を試みる。推定部1102は、情報取得部1101によりユーザ情報が取得された競技について、そのユーザ情報に基づいて、ユーザが応援するチームを推定し又は推定を試みる。ここで、第1競技については、応援するチームを推定することができた一方で、第2競技については、応援するチームを推定することができないと判定されたと仮定する。
情報取得部1101は、第1競技についてユーザが応援すると推定部1102により推定されたチームが本拠とする場所を示す情報を取得する。この情報は、第5実施形態において説明した情報と同じ情報であってもよい。
推定部1102は、情報取得部1101により取得された情報により示される場所と、第2競技を行う予め定められた複数のチームそれぞれが本拠とする場所と、に基づいて、それら複数のチームのうち、ユーザが応援するチームを推定する。例えば、ユーザが住む場所が、第1競技についてユーザが応援すると推定されたチームが本拠とする場所に変わったことを除き、推定部1102は、第5実施形態の場合と同様に、第2競技についてユーザが応援するチームを推定してもよい。
図17は、ユーザが応援するチームの推定例を示す図である。例えば、閲覧履歴及び購入履歴に基づいて、ユーザが応援するチームを推定するものとする。図17に示すように、サッカーのプロリーグに所属しているチームは、チームA~F等である。推定部1102は、閲覧履歴及び購入履歴に基づいて、サッカーについてユーザXがチームAを応援すると推定した。チームAの本拠地は大阪府である。一方、バスケットボールについて、ユーザXの閲覧履歴及び購入履歴の何れも記憶されていない。バスケットボールのプロリーグに所属するチームは、チームJ~チームO等である。チームJの本拠地は秋田市である。チームKの本拠地は茨城市である。チームLの本拠地は大阪府である。チームMの本拠とは川崎市である。チームNの本拠地は名古屋市である。チームOの本拠地は島根市である。ユーザが応援するチームの本拠地を、同一市区町村内に限定する場合、推定部1102は、大阪府に本拠地があるチームLをユーザXが応援すると推定してもよい。
図18は、本実施形態に係るセンターサーバ1のシステム制御部11により実行される応援チーム推定制御処理の一例を示すフローチャートである。例えば、所定期間が経過するたびに、システム制御部11は、各ユーザについて、応援チーム推定制御処理を実行してもよい。この場合、システム制御部11は、各応援チーム推定制御処理を実行する際に、対象となるユーザを選択する。
図18に示すように、先ず推定部1102は、番号jを1に設定する(ステップS701)。次いで、推定部1102は、選択競技を競技jに設定する(ステップS702)。競技jは、投票サイトでくじの購入が可能な競技のうちj番目の競技である。次いで、情報取得部1101は、選択競技について、応援チーム推定処理で用いるユーザ情報があるか否かを判定する(ステップS703)。ユーザ情報として必要な情報は、応援チーム推定処理の内容に依存する。ユーザ情報として閲覧履歴又は購入履歴が用いられる場合、情報取得部1101は、選択ユーザのユーザIDと選択競技を示す競技種別との組み合わせに関連付けられた閲覧ログ又は購入ログを、閲覧履歴DB14h又は購入履歴DB14iから検索してもよい。情報取得部1101は、閲覧ログの数が所定数(例えば、3個、5個等)以上であるか否かを判定してもよい。また、情報取得部1101は、購入ログの数が所定数以上であるか否かを判定してもよい。ユーザ情報としてお気に入りの情報が用いられる場合、情報取得部1101は、選択ユーザのユーザIDと選択競技を示す競技種別との組み合わせに関連付けられた応援チームIDがお気に入りチームDB14cに記憶されているか否かを判定してもよい。
ユーザ情報がある場合(ステップS703:YES)、システム制御部11は、選択競技について応援チーム推定処理を実行する(ステップS704)。応援チーム推定処理は、例えば第1実施形態~第6実施形態で説明されたような処理であってもよい。
ユーザ情報がない場合(ステップS703:NO)、又はステップS704の後、推定部1102は、番号jが、くじを購入可能な競技数未満であるか否かを判定する(ステップS705)。番号jが競技数未満である場合(ステップS705:YES)、推定部1102は、番号jを1増加させて(ステップS706)、処理はステップS702に進む。
一方、番号jが競技数未満ではない場合(ステップS705:NO)、推定部1102は、番号jを1に設定する(ステップS707)。次いで、推定部1102は、競技jについて、ステップS704の応援チーム推定処理で応援チームが決定されたか否かを判定する(ステップS708)。
応援するチームが決定されていなかった場合(ステップS708:NO)、推定部1102は、競技j以外の他の競技についてステップS704の応援チーム推定処理で決定された応援チームの本拠地名を、チームDB14bから取得する(ステップS709)。次いで、情報取得部1101は、競技jを示す競技種別に関連付けられた各チームの本拠地名を、チームDB14bから取得する(ステップS710)。次いで、推定部1102は、他の競技について決定された応援チームの本拠地がある区域内に本拠地がある競技jのチームを、応援チームに決定する(ステップS711)。例えば、推定部1102は、本拠地名に基づいて、各チームの本拠地がある区域を特定する。推定部1102は、他の競技の応援チームの本拠地がある区域と本拠地の区域とが一致するチームを、応援チームに決定する。次いで、推定部1102は、決定された応援チームのチームIDを、選択ユーザのユーザIDと競技jを示す競技種別とに関連付けて応援チームDB14jに記憶させる(ステップS111)。
応援チームが決定されていた場合(ステップS708:YES)、又はステップS111の後、推定部1102は、番号jが、くじを購入可能な競技数未満であるか否かを判定する(ステップS712)。番号jが競技数未満である場合(ステップS712:YES)、推定部1102は、番号jを1増加させて(ステップS713)、処理はステップS708に進む。一方、番号jが競技数未満ではない場合(ステップS712:NO)、応援チーム推定制御処理は終了する。
以上説明したように、本実施形態によれば、センターサーバ1が、ユーザ情報に基づいて、第1競技を行う複数のチームのうち、ユーザが応援するチームを推定する。また、センターサーバ1が、第1競技についてユーザが応援すると推定されたチームが本拠とする場所を示す情報を取得する。また、センターサーバ1が第1競技についてユーザが応援すると推定されたチームが本拠とする場所と、第2競技を行うの複数のチームそれぞれが本拠とする場所と、に基づいて、第2競技を行う複数のチームのうち、ユーザが応援するチームを推定する。ユーザは、互いに同じ区域又は比較的に近い区域に本拠がある複数のチームを応援する可能性がある。そのため、第1競技についてユーザが応援するチームを、ユーザ情報を用いて推定することができれば、第2競技については、たとえユーザ情報を用いなかったとしても、ユーザが応援するチームを推定することができる。